В этой статье рассматриваются некоторые скрытые препятствия, с которыми сталкиваются разработчики при разработке решения, использующего Salesforce Streaming API, а также API Salesforce в целом.

1. Ограничения скорости

Начнем с того, что кажется наиболее очевидным, но в то же время неочевидным, подводным камнем Salesforce Streaming API — ограничение скорости. Salesforce документирует свои ограничения скорости на основе типа лицензии каждого арендатора здесь. Salesforce даже предоставляет конечную точку API для программного запроса этой информации в /vXX.X/limits/ под названием Ограничения.

Однако Salesforce часто заявляет, что использование протокола CometD позволяет обойти ограничения запросов API, поскольку арендаторы могут превысить 15 000 или даже 1 000 000 событий за один 24-часовой период. Получение этих событий не будет учитываться при расчете ежедневной квоты запросов API. Прочтите нашу предыдущую запись в блоге об уникальной структуре квот API-запросов на основе клиентов Salesforce здесь для получения дополнительной информации.

Действительно интересным аспектом ограничений является то, что Salesforce документирует отдельную квоту для каждого из перечисленных ниже типов:

  • События Daily Streaming API (версия API 36.0 и более ранние версии)
  • Ежедневные надежные события Streaming API (API версии 37.0 и выше)
  • Параллельные клиенты Streaming API (API версии 36.0 и более ранние)
  • Параллельные клиенты Durable Streaming API (API версии 37.0 и выше)
  • Ежедневные общие потоковые события (API версии 36.0 и более ранние)
  • Ежедневные надежные общие потоковые события (API версии 37.0 и выше)
  • Ежедневные мероприятия платформы стандартного объема, доставляемые клиентам CometD

2. Снова лимиты!

После разработки клиента Streaming API, который не сталкивается с предыдущими ограничениями скорости, разработчики обычно сталкиваются с аналогичной проблемой с PushTopics. Вот краткое описание того, что обычно означает каждая ошибка, которую разработчики получают, и как она влияет на реализацию:

Максимальное количество тем на одного арендатора

Salesforce разрешает только определенное количество объектов PushTopic для каждого арендатора. Это означает, что:

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

Максимальная длина запроса SOQL в поле Query записи PushTopic

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

Максимальная длина имени PushTopic

Это кажется бессмысленным, но это действительно существует! Представьте, что у арендатора есть общий настраиваемый объект с именем SomeCustomObjectName. Не забывайте, что Salesforce теперь будет добавлять суффикс __c к пользовательским объектам. Если бы разработчик хотел создать PushTopic для этого пользовательского объекта и отличить его от других тем, имя объекта SomeCustomObjectName__c было бы слишком длинным, поскольку оно превышает ограничение в 25 символов!

3. Пуш-темы снова!

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

  • Разработчик может запрашивать только один объект (тип SObject) для каждой темы. Это затрудняет разработчикам мониторинг большего количества объектов (стандартных или настраиваемых) в Salesforce, чем выбранное количество.

Пример запроса: SELECT Id, Name FROM Opportunities

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

Пример неподдерживаемого запроса: SELECT Id, AVG(AnnualRevenue) FROM Account

  • Нет поддержки полей текстовой области. Это означает, что разработчик должен убедиться, что точные имена и типы полей для каждого из их запросов не являются типом поля «Текстовая область». Наиболее распространенным и популярным полем в объектах Salesforce SObject является атрибут description, однако он по-прежнему не поддерживается в запросах SOQL.

4. Долговечность сообщений и 24-часовой срок хранения

Разработчики должны обратить внимание на то, как Salesforce сохраняет события для арендатора в течение 24 часов. Логика обработки потока событий для нескольких тем push имеет следующие оговорки:

  • Значения идентификатора воспроизведения уникальны для каждого потока событий. Обязательно сохраните значения канала подписки и идентификатора воспроизведения для каждого потока событий, чтобы постоянно обрабатывать события.
  • Не гарантируется, что значения идентификатора воспроизведения будут непрерывными для последовательных событий. Не полагайтесь на какое-либо числовое приращение для проверки событий потоковой передачи.
  • 24-часовой период хранения — это не скользящие 24 часа, а абсолютный период времени, поэтому клиенты должны обеспечить извлечение событий до окончания 24-часового периода хранения.
  • Кроме того, сохраненные replayId могут стать недействительными при сбросе срока хранения, поэтому не забудьте сбросить значения replayId по умолчанию:
  • -1: поток событий начнет извлекать события с настоящего времени и далее
  • -2: поток событий начнет извлекать события с начала 24-часового периода хранения.

5. Поддерживаемые объекты

Наконец, разработчики могут столкнуться с проблемой, которая может стать препятствием в зависимости от требований их приложения — Streaming API поддерживает все настраиваемые объекты, но поддерживает только подмножество стандартных объектов. Вот поддерживаемые стандартные объекты:

  • Счет
  • Кампания
  • Случай
  • Контакт
  • ContractLineItem
  • право
  • Вести
  • LiveChatTranscript
  • Возможность
  • Цитировать
  • QuoteLineItem
  • СлужбаНазначение
  • Контракт на обслуживание
  • Задача
  • заказ на работу
  • WorkOrderLineItem

Как упоминалось в нашем предыдущем сообщении в блоге об отслеживании активности в Salesforce, разработчики могут использовать структуру сбора данных об изменениях или общих событий, но они имеют аналогичные ограничения. Однако разработчики также могут просто запрашивать изменения, используя те же запросы SOQL, что и для объектов PushTopic, чтобы отслеживать только недавно измененные объекты. Вот пример запроса:

SELECT Id,Name FROM ApexPage WHERE SystemModstamp > 2019-02-20T00:00:00Z AND SystemModstamp <= 2019-02-21T00:00Z

Salesforce поддерживает поле IsDeleted для некоторых объектов, что позволяет приведенному выше запросу отслеживать удаленные объекты в дополнение к вновь созданным и обновленным. Это эквивалентно использованию любого из трех вариантов потоковой передачи, упомянутых ранее, кроме запроса SOQL, учитывающего дневную квоту арендатора.

API безоблачных событий

Kloudless предоставляет унифицированный API для подключения нескольких различных CRM-приложений к одной реализации. Вместо того, чтобы преодолевать все вышеперечисленные препятствия, попробуйте Kloudless Events API. Мы реализуем протокол CometD и обрабатываем все необходимые рукопожатия, сбросы соединений и обработку потоков. Мы также позволяем приложениям отслеживать изменения в объектах Salesforce, которые не поддерживает Streaming API. Отправьте нам электронное письмо, чтобы обсудить реализацию вашей интеграции, или зарегистрируйтесь, чтобы начать сегодня!

Автор и с разрешения Тимоти Лю.

Похожие статьи можно найти на kloudless.com/blog.