В этой статье рассматриваются некоторые скрытые препятствия, с которыми сталкиваются разработчики при разработке решения, использующего 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.