Асинхронная обработка повышает масштабируемость, позволяя увеличить ограничения для контекста. Асинхронные запросы выполняются в собственных цепочках за кадром, поэтому пользователи могут продолжить работу на стороне клиента, поскольку асинхронные задачи выполняются в фоновом режиме.

Salesforce Lightning Platform предлагает различные асинхронные технологии, которые можно использовать для решения заданного сценария использования. Каждая технология имеет преимущества и ограничения, которые необходимо учитывать при выборе подхода для каждого сценария использования.

При выборе технологии для внедрения необходимо учитывать три важные рекомендации:

1. Асинхронная обработка - не лучший подход для каждой проблемы. Может возникнуть соблазн считать любой процесс, не требующий прямого взаимодействия с пользователем, хорошим кандидатом на асинхронную обработку, но есть некоторые недостатки. Во-первых, асинхронные процессы не имеют SLA, что означает отсутствие гарантии завершения асинхронного процесса в течение заданного периода времени. Во-вторых, нет гарантии последовательной задержки ответа. Если асинхронный процесс завершается в течение определенного промежутка времени, последующий процесс может занять другое время. Поэтому, даже если пользователь не ожидает ответа напрямую, асинхронная обработка может не подойти для вашего сценария, если у вас есть последующие процессы, зависящие от ответа, или если вы обеспокоены, что чрезмерное время ответа может привести к потере синхронизации данных с данными во внешней системе.
2. Существуют разные способы обработки асинхронных запросов на Salesforce Platform, поэтому убедитесь в выборе оптимального подхода. Технологии, поддерживающие асинхронную обработку на Salesforce Platform, работают по-разному «под капотом», а некоторые были созданы для вполне определенных способов использования.
3. Если технология асинхронна со стороны клиента, это не обязательно значит, что вся комплексная обработка выполняется параллельно. В зависимости от выбранного варианта, сообщения клиента могут иногда сериализироваться на сервере.

Если вы используете неправильные технологии или неправильные комбинации технологий для работы, могут произойти непредвиденные последствия, которые сведут на нет преимущества асинхронной обработки. В настоящем руководстве содержатся разъяснения и рекомендации, а также потенциальные недостатки и антисхемы для различных сценариев асинхронного использования вместе с обоснованием этих рекомендаций. Он также предоставляет важные данные о том, как различные методы асинхронного внедрения работают и регулируются на Salesforce Platform.

Если вы принимаете решение о том, какую технологию использовать, существует специальное Руководство по решению асинхронной обработки, которое предоставляет быстрое соотнесение типичных способов использования с наиболее подходящей технологией.

Платформа Salesforce Lightning - это комплексная платформа на основе искусственного интеллекта, которая объединяет сотрудников, автономных агентов на основе искусственного интеллекта, данные компании и приложения в единую надежную систему для повышения производительности и качества обслуживания клиентов. Он позволяет создать "агентское предприятие", подключив приложения Customer 360, Data Cloud и Slack для комплексной автоматизации.

Данный документ не охватывает технологии в других экосистемах, например, MuleSoft, Informmatica, Commerce Cloud, Tableau и Marketing Cloud.

Отметим, что данное руководство посвящено исключительно асинхронной обработке в рамках Salesforce Lightning Platform. Если вам нужна информация об асинхронных схемах интеграции, ознакомьтесь с разделом Архитектура под управлением событий.

• Прежде чем использовать асинхронную обработку, убедитесь, что сценарии использования соответствуют схеме. Асинхронные схемы не имеют SLA, подчиняются нескольким управляющим механизмам, могут иметь ограничения нагрузки, определенные на основе лицензирования, и могут привести к задержкам обработки из-за ограниченного характера ресурсов, выделяемых на асинхронную инфраструктуру в Salesforce Platform. Примите во внимание эти ограничения при использовании асинхронной обработки в сценариях, когда пользователю требуется ответ от системы, прежде чем он сможет продолжить работу.
• Асинхронная обработка с помощью Salesforce не позволяет удовлетворять безграничные потребности масштабирования. Salesforce Platform не бесконечно масштабируется, и асинхронные схемы по-прежнему имеют ограничения. Асинхронная обработка использует потоки, содержащие контекстную информацию, необходимую процессору для выполнения потока инструкций. Потоки могут выполняться параллельно. Количество доступных потоков в любом процессоре ограничено, поэтому платформа использует механизмы, обеспечивающие максимально эффективное использование доступных потоков. Механизм управления потоками платформы предотвращает использование слишком большого количества потоков и негативное влияние на другие организации. Алгоритм добросовестного использования платформы управляет количеством цепочек, доступных организации для каждого отдельного типа сообщений.
• Знайте, когда транзакции действительно асинхронны. Некоторые схемы архитектуры выполняются асинхронно. Однако, другие процессы ведут себя асинхронно на стороне клиента или обозревателя, но сериализуют запросы на стороне сервера, которые потом подчиняются ограничениям синхронного управления.
• Чтобы создать крупномасштабные исходящие интеграции из Salesforce Platform, используйте события платформы и надежное промежуточное программное обеспечение вместо выносок посредством асинхронного Apex. Поскольку в платформе доступно конечное количество асинхронных потоков, исходящие интеграции посредством асинхронного Apex имеют ограниченную масштабируемость. Если в вашей организации есть исходящие интеграции, связанные с большими объемами сообщений, превышающие количество доступных потоков и имеющие длительное время обработки, использование асинхронного Apex неизбежно приведет к задержкам.
• Обязательно внедрите мониторинг при использовании асинхронной обработки. С помощью мониторинга можно обнаружить проблемы как можно раньше и исправить их до возникновения серьезных инцидентов производительности.
• Учитывайте события, которые могут привести к экстремальным нагрузкам. При создании асинхронных процессов убедитесь, что они могут предсказуемо управлять скачками загруженности и затишьями. Подумайте, как ваше внедрение обрабатывает непредвиденные события, например, перебои с электропитанием, и создайте гарантии, предотвращающие потерю данных или функциональность.

При выборе метода серверной асинхронной обработки рекомендуем сначала оценить требования организации и доступные ресурсы. Ваша цель - выбрать подход, который минимизирует затраты на внедрение и обслуживание, обеспечивая масштабируемость и минимизируя вероятность нарушений ограничения. Данная цель зависит от технических рекомендаций, изложенных в следующих разделах, а также от состава рабочей группы. Например, подумайте, есть ли в вашей рабочей группе разработчики Apex, которые могут обслуживать ваше прокодированное решение. В противном случае, декларативный подход может иметь больше смысла. Помните также, что разные наборы ограничений могут применяться к разным инструментам.

Рассмотрим сценарий использования процесса асинхронного заказа в Salesforce. Когда заказ сохраняется, он запускает сообщение внешней системе управления складом со специальными инструкциями по упаковке и отправке элемента. Пользователю, размещающему заказ, не нужен немедленный ответ от системы управления складом, поэтому запрос может быть отправлен асинхронно. Асинхронная обработка позволяет пользователю продолжить работу без задержек.

Рекомендации по архитектуре:

• Сколько параллельных процессов необходимо?
• Как параллельный процесс будет взаимодействовать друг с другом?
• Сколько запросов SOQL будет выполнено в каждом процессе?
• Сколько операций DML будет выполнено в каждом процессе?
• Как долго будет выполняться каждый процесс?
• Насколько чувствительны процессы к конкретному времени?

Многопользовательская архитектура Salesforce Platform изолирует и параллельно поддерживает разные требования многих клиентов (организаций). Все асинхронные методы Apex, описанные в данном руководстве, выполняются в рамках одной асинхронной инфраструктуры в Salesforce Platform. Они используют инфраструктуру очереди сообщений, которая регулируется двумя основными механизмами внедрения: контролем потока и справедливым использованием.

Механизмы управления потоками и добросовестного использования предотвращают использование одним клиентом слишком большого количества ресурсов сервера и не оставляют достаточно ресурсов для остальных клиентов. Хотя важно понимать, как работают эти механизмы, ваше главное преимущество должно заключаться в том, что выполнение рекомендаций по асинхронной обработке, например, описанных в следующих разделах, значительно уменьшает вероятность возникновения проблем с ними.

Механизм управления потоками платформы предотвращает заполнение одной организацией заданного типа сообщений, что использует слишком много потоков и негативно влияет на другие организации. Прежде чем инфраструктура добавит новые записи в очередь, связанную с типом сообщения, она проверяет первые несколько тысяч существующих записей в очереди. Если большинство существующих записей связано с этой же организацией, и в этой организации уже есть записи в рабочих цепочках, новые добавленные записи перемещаются в конец очереди. Этот процесс называется повторная очередь. Повторная очередь обычно происходит с процессами Batch Apex и Bulk API, поскольку они часто одновременно вставляют большое количество записей в свои очереди.

Механизм добросовестного использования платформы реализует систему на основе уровней. Система обеспечивает получение каждой организацией на Salesforce Platform достаточной доли времени на обработку данного типа сообщений, включительно с типами сообщений «Будущее», «В очереди» и «Пакетное сообщение». Если одна организация доминирует в данном типе сообщения в то же время, когда другие организации ожидают выполнения работы над этим же типом сообщения, алгоритм добросовестного использования уменьшает количество цепочек, доступных организации для этого определенного типа сообщения.

Преимущество использования асинхронных методов Apex в том, что некоторые контролирующие ограничения, например, ограничения запросов SOQL и ограничения размера кучи, выше. Однако не полагайтесь слишком сильно на эти методы. Из-за ограниченных ресурсов, выделяемых на асинхронную инфраструктуру, активное использование Future, Queable и Batch Apex может привести к задержкам обработки, которые вытекают из ограничений, основанных на добросовестном использовании и контроле потока.

Исходящие выноски, использующие асинхронный Apex, учитываются в ограничении асинхронного Apex. В настоящее время ежедневное ограничение составляет 250 000 или 200-кратное количество соответствующих лицензий пользователя, в зависимости от того, что больше. Это ограничение может быть проблемой для сценариев массового использования. При превышении ограничения асинхронные задания Apex и связанные исходящие выноски не будут выполнены.

Кроме того, поскольку платформа имеет конечное количество доступных асинхронных потоков, исходящие интеграции посредством асинхронного Apex имеют ограниченную масштабируемость. Любые массовые исходящие интеграции, превышающие количество доступных потоков, могут иметь длительное время обработки и привести к задержкам.

Для сценариев массового использования рассмотрите данные альтернативные подходы. Вызовы API с этими подходами учитываются в ежедневном ограничении запросов API, что значительно превышает ежедневное ограничение асинхронных Apex. Таким образом, эти подходы являются более масштабируемыми. Обратите внимание, что существуют физические ограничения количества параллельных запросов, которые может обработать любой процессор.

• Запланированное извлечение среднего программного обеспечения. Избегайте задержек, связанных с массовыми заданиями исходящей интеграции, используя промежуточное программное обеспечение для извлечения данных по расписанию вместо их переноса посредством асинхронного Apex. Промежуточные программы, например, MuleSoft Anypoint Platform, могут синхронно использовать SOAP API или REST API, чтобы избежать незначительных задержек. Промежуточные программы также могут использовать собственный Bulk API для больших объемов данных.

• Извлечение промежуточного программного обеспечения посредством уведомления о событии платформы. Вместо постановки в очередь асинхронного Apex Future, Queableable или Batch для выполнения исходящих интеграций можно использовать события платформы. Событие платформы может либо доставить исходящие сведения самостоятельно, либо научить промежуточный инструмент извлекать требуемые сведения посредством собственного API и доставлять их в конечное место назначения. Ни один из этих подходов не подчиняется задержкам, которым подвергается асинхронный Apex. Однако, ограничения событий платформы продолжают применяться.

С помощью Queueable Apex можно асинхронно запускать процессы Apex, включающие обширные операции базы данных или выноски внешних веб-служб. Чтобы использовать Queueable Apex, внедрите интерфейс Queable, а потом добавьте задание в очередь заданий Apex. Этот метод обеспечивает фоновое выполнение асинхронного задания Apex в собственном изолированном потоке и не задерживает выполнение основной логики Apex. Каждое поставленное в очередь задание выполняется при появлении системных ресурсов.

Apex в очереди представляет эволюцию асинхронного Apex. Он предлагает функции, недоступные будущим методам Apex, включая:

• Коды заданий: При отправке задания посредством вызова метода System.enqueueJob метод возвращает код нового задания. Этот код можно использовать для идентификации задания. Чтобы отслеживать ход выполнения, просмотрите страницу заданий Apex в настройках Salesforce или запросите объект AsyncApexJob.
• Поддержка непростых типов: Классы очереди могут содержать переменные участников непримитивных типов данных, например, sObjects или настраиваемые типы Apex.
• Поддержка цепочки заданий: Задания, доступные в очереди, можно сцепить, запустив второе задание из выполняемого задания. Этот метод поможет вам обработать сценарии, связанные с зависимостями процесса.
• Контроль максимальной глубины: Задания очереди с максимальной глубиной стека можно настроить, чтобы цепочки заданий не привели к неожиданной рекурсии.
• Подписи повторов: Задания в очереди предоставляют дополнительную подпись для обнаружения и удаления повторяющихся заданий.
• Настраиваемая задержка: Вы можете определить задержку до 10 минут до выполнения задания в очереди.
• Окончатели транзакций: Вы можете вложить последовательность действий после к заданию «В очереди» и предпринять соответствующие действия на основе его результата. Например, завершитель транзакций может повторно поставить в очередь задание «В очереди», которое не удалось выполнить из-за необработанного исключения, до пяти раз.

Salesforce использует инфраструктуру на основе очереди для обработки асинхронных процессов. Эта очередь используется для баланса загруженности запросов в организациях. Чтобы обеспечить максимально эффективное использование этой очереди в организации:

• Избегайте создания очереди будущих методов или методов очереди напрямую в действиях, созданных большими объемами действий конечного пользователя или вызовов API интеграции. Такой подход может быстро исчерпать ежедневные ограничения асинхронного Apex, что приведет к серьезным последствиям для бизнеса.
• Избегайте создания очереди из нескольких асинхронных действий на синхронное действие. Если из одного синхронного действия в очередь попадает несколько асинхронных методов, асинхронные действия часто выполняются одновременно и способствуют спору о блокировке строки и/или ошибкам времени ожидания блокировки строки.
• Избегайте добавления большого количества будущих методов или методов очереди к асинхронной очереди.
• Убедитесь, что будущие методы и методы, доступные в очереди, выполняются как можно быстрее. Чем дольше будущий метод выполняется, тем больше вероятность задержки запросов за ним в очереди. Чтобы обеспечить быстрое выполнение пакетных заданий, минимизируйте время выноски веб-служб, настройте запросы, используемые в будущих методах, и оптимизируйте любые другие автоматизации объектов, включая процессы конструктора процессов, бизнес-правила, потоки и триггеры Apex.
• Протестируйте асинхронные методы в масштабе. Используйте среду, генерирующую максимальное количество методов, которые должны обрабатываться. Это тестирование помогает определить, возникнут ли проблемы с производительностью или ограничениями в производственной среде. Также рассмотрите влияние на совокупные ежедневные ограничения.
• Используйте методы пакетного Apex вместо будущих или «В очереди» для обработки большого количества записей. Пакетный Apex может обрабатывать сложные, длительные процессы, выполняемые в отношении тысяч записей, и может быть запланирован на выполнение в нерабочее время, когда появляется больше ресурсов.

Используйте запланированный Apex для выполнения в указанное время и с повторяющейся частотой, как определено выражением cron. Хотя действие планирования Apex посредством выражения cron является асинхронным процессом, основной код выполняется синхронно при запуске задания. Запланированный Apex идеально подходит для ежедневного или еженедельного обслуживания.

• Одновременно можно иметь только 100 запланированных заданий Apex. Во избежание этого ограничения рекомендуем использовать поток, запущенный расписанием, который вызывает код Apex вместо использования запланированного Apex.
• Рекомендуем проявлять крайнюю осторожность при планировании занятия по триггеру. Вы должны быть уверены, что триггер не добавит больше запланированных классов, чем ограничение. В частности, рекомендуем использовать пакетные обновления API, мастера импорта, пакетные изменения записей посредством пользовательского интерфейса и все случаи одновременного обновления нескольких записей.
• Для разовых задач, которые должны быть запланированы до 10 минут в будущем, используйте отложенное задание «В очереди». Этот подход не учитывается в ограничении 100 запланированных заданий.
• Запланированный Apex выполняется в синхронном контексте с синхронными ограничениями.
• Определите продолжительность выполнения запланированного задания. Долгосрочное задание может накладываться на начало следующего запланированного задания.
• Salesforce планирует выполнение класса в указанное время. Фактическое выполнение может быть отложено в зависимости от доступности услуги. Задания, запланированные на выполнение во время простоя обслуживания службы, будут запланированы на выполнение после повторного запуска службы.
• Используйте System.scheduleBatch для планирования пакетных заданий, а не для выполнения запланированного задания с единственной целью создания очереди пакетного задания.

Исторически синхронные выноски из метода Apex, выполняемого в контексте синхронной транзакции Apex, например контроллер Visualforce или контроллер компонентов Lightning, подпадали под ограничение параллельности Apex в отношении долгосрочных запросов. Начиная с выпуска Winter ’19 синхронные выноски больше не считаются долгосрочными. Хотя продолжения Apex изначально создавались как решение синхронных выносок, которые привели к длительным запросам, они также дают некоторые дополнительные преимущества.

• Одно синхронное действие может выполнять не более трех действий продолжения. Предыдущее продолжение должно быть завершено до выполнения нового действия продолжения.
• Каждое действие продолжения может выполнять не более трех выносок, которые выполняются параллельно.
• После завершения всех выносок, выполненных действием продолжения, платформа вызывает метод обратного вызова продолжения для обработки результатов.

Хотя продолжения выполняются асинхронно относительно исходного синхронного действия, существуют ключевые отличия между продолжениями Apex и другими асинхронными техниками Apex, например, будущие методы, очередь или пакет. Ключевые отличия:

• Продолжения не ставятся в очередь.
• Продолжения не влияют на ежедневное ограничение асинхронного выполнения Apex.
• Продолжения переключают контекст потока на сервере приложений с тяжелого потока платформы Apex на легкий поток, выполняющий только выноски. В целях выполнения выносок, которые могут продолжаться до 120 секунд, продолжения предлагают значительную экономию памяти сервера приложений.
• Изначально продолжения могли выполняться только из удаленного вызова Visualforce JavaScript. Тем не менее, в выпуске Summer ’19 продолжения были официально добавлены в фреймворк компонентов Lightning, что исключило необходимость в Visualforce.

События платформы - это реализация Salesforce Platform архитектуры, управляемой только событиями. Дополнительные сведения о компонентах, связанных с этим типом архитектуры, см. в Руководстве архитектора по архитектуре на основе событий.

События платформы и триггеры/потоки событий платформы часто являются отличной альтернативой запуску асинхронного Apex. Они также являются отличным способом вызова внеплатформенной обработки. Например, можно использовать сочетание перенаправлений событий Amazon Web Services (AWS) и событий платформы для вызова функций бессерверных компьютеров в AWS Lambda. Работа, выполняемая относительно быстро и без выносок (невозможных из триггера события платформы или потока), является отличным кандидатом для сочетания события/триггера платформы или события/потока.

События, опубликованные в шину посредством публикации после подтверждения, предоставляются в порядке и могут быть обработаны триггером или потоком в отдельном синхронном контексте. Контекст синхронный и применяет все синхронные контролирующие ограничения. Тщательно выберите размер пакета триггера события платформы/потока, чтобы избежать достижения ограничений.

• Поскольку события публикуются в шине событий, они доступны для потребителей. В случае триггеров событий (Apex или flow) эти события отправляются в доступные синхронные потоки на уровне приложения (по одному потоку на триггер/поток события). Обратите внимание, что данный процесс не содержит SLA.
• При добавлении операций публикации в очередь результат процесса постановки в очередь сохраняется в объекте Database.SaveResult. Эти записи обозначают только успешность операции создания очереди. Чтобы получить итоговый результат события, опубликованного в шине событий, внедрите обратный вызов публикации Apex. С помощью этой дополнительной информации можно принимать решения о дальнейших действиях, например, попытка повторной публикации неудачных событий.
• Хотя события платформы не ограничены асинхронным Apex, у них есть собственные наборы управляющих ограничений. Если у вас возникнут проблемы с ограничениями, вы можете включить расширенные показатели использования событий, чтобы определить, используют ли определенные события больше выделенных средств, чем предполагалось. Если вам нужна большая производительность по триггерам событий, используйте параллельные подписки для обработки событий одновременно, а не в одном потоке. С помощью параллельных подписок можно масштабировать триггеры событий платформы Apex для обработки больших объемов событий. Параллельные подписки доступны для настраиваемых массовых событий платформы, но не для стандартных событий или событий изменений.
• События платформы имеют два варианта поведения публикации:
  • Опубликовать немедленно: События публикуются непосредственно во время транзакции до окончательного подтверждения базы данных. События, опубликованные таким образом, не гарантированно публикуются в порядке.
  • Публикация после обязательства: События публикуются в момент успешного завершения транзакции базы данных. События, опубликованные таким образом, гарантированно публикуются в порядке.

Рекомендуем использовать параметр «Опубликовать немедленно» для сценариев использования (например, журналирование), когда событие журнала должно быть опубликовано независимо от успеха и обязательства транзакции или сбоя и отката. Можно немедленно опубликовать событие платформы, израсходованное триггером события платформы. Триггер события платформы потом конкурирует за блокировку строки базы данных с транзакцией, ее опубликовавшей. Прежде чем немедленно опубликовать события платформы, тщательно просмотрите все дизайны, чтобы избежать этого сценария.

Асинхронные потоки предоставляют низкокодовые альтернативы асинхронному Apex. Как и в других формах асинхронной обработки, они выполняются в фоновом режиме при наличии ресурсов. Асинхронные потоки также не имеют соглашений об уровне обслуживания и могут иметь непредсказуемое время ожидания.

Запланированные пути выполняются в указанное время на основе триггера cron. Они выполняются при создании, обновлении или удалении записей и предоставляют детализированный контроль над временем выполнения автоматизации относительно изменения записи. (Пример: отправка сообщения эл. почты пользователю за час до выполнения задачи.) В отличие от будущих методов Apex, которые ограничены максимум 50 методами, добавленными в очередь синхронной транзакции, запланированные действия потока в данный момент не имеют ограничения по максимальной очереди на транзакцию. Однако, существует конфигурация размера пакета в определении запланированного пути, которая позволяет некоторый контроль над количеством записей, обрабатываемых запланированным выполнением потока пути.

Асинхронные пути могут быть добавлены в потоки, запущенные записью. Они выполняются в фоновом режиме и не задерживают выполнение транзакции, изначально инициировавшей поток. Вы можете использовать асинхронный путь для выполнения длительной операции или любой операции, которую хотите выполнить в свое время. Асинхронные пути могут помочь избежать ошибок смешанного DML, возникающих при необходимости обновления значения в связанной записи, не являющейся частью записи, инициировавшей поток.

Примечание: Исходящие сообщения являются устаревшей функцией, а события платформы (описанные в предыдущем разделе) являются более современным подходом и предлагают большую гибкость. События платформы - это рекомендуемая схема Salesforce для интеграции под управлением событий.

Исходящие сообщения предоставляют средство асинхронной исходящей связи посредством SOAP API. При настройке в Salesforce определение исходящего сообщения создает SOAP WSDL, который может использоваться внешним поставщиком веб-служб. Исходящие сообщения могут быть запущены из бизнес-правил, процессов конструктора процессов или триггеров потока после сохранения Lightning. Исходящее сообщение SOAP может содержать не более 100 уведомлений. Каждое уведомление содержит код объекта и ссылку на связанные данные sObject. Если информация в основном объекте меняется после постановки уведомления в очередь, но до его отправки, доставляются только последние данные, а не промежуточные изменения.

Когда слушатель исходящего сообщения (веб-служба, настроенная посредством созданного WSDL) получает сообщение, он использует добавленные сведения кода сеанса для вызова API платформы Lightning для обновления записи в Salesforce, запустившей исходящее сообщение.

• Исходящие сообщения не обрабатываются посредством асинхронной инфраструктуры на основе очереди в Salesforce, выполняющей такие действия, как будущие методы, Apex очереди, Batch Apex, Bulk API и прочие. Вместо этого записи хранятся локально в объекте OutboundMessage. Сообщения отправляются и пробуются повторно посредством локального запланированного фонового процесса.
• Сообщения не отправляются синхронно, когда действие исходящего сообщения выполняется инициирующей автоматизацией (например, триггер потока после сохранения). Вместо этого, они остаются в объекте OutboundMessage до успешной отправки или до отмены после 24 часов неудачной доставки.
• Во избежание бесконечного цикла исходящих сообщений убедитесь, что пользователь, обновляющий объекты, не имеет полномочия «Отправка исходящих сообщений».

Email-to-Case обычно работает синхронно. Существует ограничение четырех синхронных потоков для обработки входящих запросов Email-to-Case. Синхронная форма средства обработки поддерживает подключение к входящему почтовому серверу Salesforce (MTA), который получает электронное сообщение. Однако, существуют причины, по которым функция Email-to-Case может обрабатываться асинхронно:

• На функцию Email-to-Case распространяются ограничения по потокам, в частности, 10 цепочек обработки на сервер приложения: четыре потока для синхронной обработки и шесть потоков для асинхронной обработки.
• Если синхронное средство обработки эл. почты превышает 15 секунд времени выполнения, этот конкретный адрес службы эл. почты помечается как асинхронный в течение 30 минут. Последующие запросы обработчика для этого адреса службы приводят к сообщению, попавшему в очередь для MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, вместе со ссылкой на содержимое электронной почты.
• Если синхронный поток уже используется для определенной организации и адреса службы, дополнительные запросы для этого адреса службы асинхронно ставятся в очередь.
• Если синхронно обрабатываемое сообщение эл. почты возвращает ошибку, например, время ожидания блокировки строки, запрос сохраняется и ставится в очередь асинхронно.
• Если цепочки синхронных средств обработки недоступны, запрос ставится в очередь асинхронно.

• При настройке функции Email-to-Case существует параметр «Дедублирование», но он не дублирует вложения до завершения обработки сообщения эл. почты. Эта дедупликация экономит место в базе данных, но не уменьшает время обработки электронной почты. Однако можно повысить производительность, реализовав настраиваемое средство обработки сообщений Apex Email-to-Case. Это внедрение не влияет на контролирующие ограничения, но оно предоставляет обработчику доступ к сообщению эл. почты и всем его вложениям до подтверждения в базе данных. Этот доступ позволяет вычислять контрольные суммы для всех добавленных вложений и удалять ненужные, включая повторы, известные изображения подписей или нежелательные типы файлов.
• Обязательство вложения электронной почты в Salesforce Files ответственно за большую часть времени обработки электронной почты. По мере увеличения количества ответов на контакт или из контакта и увеличения цепочки сообщений эл. почты время обработки каждого сообщения эл. почты также увеличивается. Если параметр «Ответить только новым содержимым» не выбран, цепочки сообщений эл. почты будут расти с каждым ответом. Поэтому рекомендуем использовать средство обработки Apex Email-to-Case с логикой, реализующей дедупликацию вложения на момент обработки.
• Несмотря на вызов триггеров Apex в рамках обработки, средства обработки Email-to-Case исключены из параллельного ограничения Apex.

Чтобы обрабатывать большие объемы записей асинхронно, рекомендуем использовать один из следующих методов.

Вы можете использовать пакет Apex для создания сложных, длительных процессов, в которых участвуют тысячи записей. Пакетный Apex работает путем деления набора записей и обработки его управляемыми фрагментами. Например, можно создать решение для архивирования, выполняемое в ночное время и добавляющее в архив записи более поздней даты. Или можно создать операцию очистки данных, которая рассматривает все организации и возможности на ежедневной основе и выполняет любые необходимые обновления на основе набора предопределенных критериев.

• Пакетный Apex лучше всего обрабатывает большие объемы данных, поскольку асинхронный Apex имеет более высокие ограничения, чем синхронный Apex. Пакетный Apex также работает более эффективно, когда обрабатывает больше элементов на пакет, поскольку использует пакетные операции, которые несут меньшие накладные расходы от управления очередями. Поэтому, во избежание запуска механизма управления потоком посредством заполнения очереди и во избежание исчерпания ежедневного ограничения асинхронного Apex, не создавайте пакеты с небольшими размерами области или с быстрым временем обработки.
• Избегайте создания очереди пакетных заданий напрямую из действий, созданных большими объемами действий конечного пользователя или вызовов API интеграции. Этот метод может быстро исчерпать очередь Flex. Если вы планируете вызвать пакетное задание из триггера, необходимо гарантировать, что триггер не добавит больше пакетных заданий, чем ограничение.
• Пакетный Apex ограничен максимум пятью одновременными потоками, что ограничивает его производительность гораздо больше, чем будущие методы или Apex в очереди.
• Пакетные задания с большими объемами данных должны быть запланированы на выполнение в непиковые часы, чтобы высвободить ресурсы для процессов, требующих ответов в реальном времени или близком к реальному.
• При вызове System.scheduleBatch платформа планирует выполнение задания в указанное вами время. Фактическое выполнение происходит в это время или позже, в зависимости от доступности службы.
• Планировщик выполняется в системном контексте. Выполняются все классы, независимо от наличия или отсутствия полномочия на выполнение класса у пользователя, запланировавшего выполнение.
• Все запланированные ограничения Apex применяются к пакетным заданиям, запланированным посредством System.scheduleBatch. После постановки пакетного задания в очередь (со статусом «Удержание» или «Очередь») применяются все ограничения пакетных заданий, и задание больше не учитывается в запланированных ограничениях Apex.
• В пакетном задании с повторяющимся расписанием рекомендуем продумать правильный алгоритм, если предыдущее задание продолжает выполняться при запуске нового задания.
• Пакетные задания, поставленные в очередь от синхронных транзакций Apex, используют очередь Flex. Очередь flex ограничена до 100 элементов в любой момент. Если транзакция пытается добавить больше записей, платформа создает ошибки и не отправляет пакетное задание.
• Выноски и другие нетранзакционные операции из пакетных заданий должны соответствовать неэффективным рекомендациям по созданию. Пакетные задания, поставленные в очередь до простоя обслуживания Salesforce, остаются в очереди. После окончания простоя обслуживания и предоставления доступа к системным ресурсам пакетные задания, поставленные в очередь, выполняются. Если пакетное задание выполняется при простое, пакетное выполнение откатывается и перезапускается после восстановления обслуживания. Поскольку методы выполнения могут выполняться несколько раз, любые нетранзакционные операции, например, выноски, могут быть повторены.
• Рекомендуем настроить пакетное задание для поднятия событий BatchApexErrorEvent для обработки сценариев ошибок и исключений.

Поток, запущенный расписанием - это поток, запланированный на выполнение в указанное время и с повторяющейся частотой (ежедневно, еженедельно или один раз) для выполнения действий над пакетом записей. (Пример: обновление поля во всех случаях со статусом «Открыто» в 2 часа ночи.) Запланированные потоки выполняются посредством триггерного механизма cron и обрабатываются пакетно.

• Поток, запущенный расписанием, выполняет 200 записей на вызов, но будет выполняться с несколькими параллельными потоками при наличии более 200 записей.
• Потоки, запущенные расписанием, выполняются в синхронном контексте с синхронными ограничениями.
• В настоящее время невозможно управлять количеством записей, обработанных в запланированном вызове потока. Если выполнение рассчитано более чем на 200 записей, существует реальная опасность ошибок параллельного Apex.

Bulk API основан на принципах REST и оптимизирован для работы с большими наборами данных. Вы можете использовать его для асинхронной вставки, обновления, обновления, вставки, запроса или удаления многих записей и последующей обработки результатов. Salesforce Platform обрабатывает запрос в фоновом режиме. В отличие от этого, SOAP API и REST API используют синхронные запросы и оптимизированы для клиентских приложений в реальном времени, обновляющих несколько записей за раз. Вы можете использовать оба этих API для обработки многих записей, но если наборы данных содержат сотни тысяч записей, они менее практичны. Асинхронная инфраструктура Bulk API предназначена для упрощения и повышения эффективности обработки данных от нескольких тысяч до миллионов записей.

Самый простой способ использования Bulk API - включить его для обработки записей в Data Loader посредством CSV-файлов. С помощью Data Loader не нужно создавать собственное клиентское приложение. Иногда уникальные требования требуют создания настраиваемого приложения.

В Salesforce Platform доступны два Bulk API.

• Bulk API 2.0 - это новый API. Он обеспечивает упрощенный и удобный в использовании бизнес-правило и является центром усовершенствований.
• Исходный Bulk API все еще полностью поддерживается, но больше не расширяется. Рекомендуем использовать Bulk API 2.0 при возможности.

Дополнительные сведения об ограничениях API см. в разделе Ограничения Bulk API и Bulk API 2.0.

См. данное руководство при создании или рассмотрении асинхронной обработки на Salesforce Platform. Рекомендуем всегда понимать весь диапазон доступных вариантов и их соответствие конкретному сценарию использования. Прежде чем вносить изменения в текущую архитектуру, рекомендуем тщательно оценить текущий ландшафт, особенно если текущее решение хорошо работает.