Выбор, который на самом деле не связан с технологиями
Когда организация начинает обсуждать событийно-ориентированную архитектуру в Salesforce, разговор слишком быстро переходит к теме «Platform Events или CDC?», как будто это вопрос выбора инструментов. На самом деле это совершенно другой вопрос: какая сторона в интеграции является источником истины, что разрешено ей потерять и кто несет затраты, если сообщение приходит поздно, дублируется или не приходит вовсе.
Краткий ответ: Change Data Capture подходит, когда внешняя система должна знать, что Salesforce обновил запись, и нет необходимости обертывать это бизнес-логикой. Пользовательские Platform Events подходят, когда нужно опубликовать значимое бизнес-событие — «клиент обновил тариф», а не «поле Status__c изменилось». Неправильный выбор не заметен в день запуска; он проявляется, когда кто-то пытается восстановить произошедшее после частичного сбоя и обнаруживает отсутствие надежного способа получить информацию.
Тот, кто ищет широкую картину интеграций Salesforce за пределами событий, найдет ее в Руководстве по архитектуре CRM.
Три вопроса, определяющие архитектуру до написания кода
Прежде чем выбрать механизм, необходимо ответить на три вопроса. Пропуск любого из них является наиболее частой причиной того, что интеграционные проекты застревают на этапе тестирования.
Кто владелец данных? Если Salesforce является источником истины для записи клиента, то исходящие события из Salesforce (Platform Event или CDC) — естественное направление. Если владельцем является ERP-система, верно обратное, и Salesforce должен потреблять события, а не публиковать их для той же сущности.
Что можно потерять? Уведомление для управленческой панели может потерять одно сообщение без ущерба. Обновление кредитного лимита до одобрения сделки — нет. Это различие определяет, достаточно ли «выстрелил и забыл» или необходим механизм подтверждения и мониторинга расхождений (Reconciliation).
Что происходит, если сообщение приходит дважды? Platform Events гарантируют доставку «как минимум один раз», а не «точно один раз». Если ответ «не знаем», решение еще не готово к производству, независимо от чистоты кода.
Platform Events против CDC — таблица принятия решений
| Критерий | Пользовательский Platform Event | Change Data Capture |
|---|---|---|
| Что публикуется | Определенное бизнес-событие (настраиваемая полезная нагрузка) | Изменение исходной строки (до/после) |
| Кто строит логику | Разработчик Salesforce, во время триггера или Flow | Платформа, автоматически для любого определенного DML |
| Связь со схемой | Низкая — полезная нагрузка контролируется издателем | Высокая — любое изменение структуры объекта влияет на потребителя |
| Подходит, когда... | Нужно опубликовать бизнес-намерение ("заказ подтвержден") | Нужна грубая синхронизация данных между системами |
| Стоимость поддержки | Выше в начале (создание полезной нагрузки и логики) | Низкая в начале, высокая при изменении структуры объекта |
| Сохранение данных (Retention) | Согласно конфигурации лицензии (часы до дней) | Согласно конфигурации лицензии, обычно то же, что и для Platform Events |
| Рекомендуемый объем | События домена со средней частотой | Изменения на уровне строки, включая высокую частоту |
Практическое правило: если потребителю события нужно понимать «почему» это произошло, а не только «что» произошло, то нужен пользовательский Platform Event. Если потребителю нужна только актуальная копия данных, CDC экономит целый уровень разработки.
Ordering, Replay и Idempotency: три понятия, которые превращают теорию в стабильное производство
Это не вопросы для поздней стадии проекта — они определяют структуру потребителя с самого первого дня.
Ordering (порядок). Platform Events отправляются в порядке публикации внутри одной темы, но нагрузка и частичные сбои могут нарушить порядок получения на стороне потребителя. Практическое решение: прикреплять к каждому событию отметку версии или порядковый номер из исходной записи и позволять потребителю отклонять событие, версия которого ниже последней уже обработанной.
Replay (повторное воспроизведение). Каждое событие получает Replay ID. Потребитель, который отключается, должен сохранить последний успешно обработанный Replay ID — не в памяти, а в надежном месте (Custom Object, внешняя таблица) — и продолжить с этого места после восстановления. Зависимость от того, что «система начнет сначала», работает только в пределах окна Retention, а за его пределами события теряются.
Idempotency (идемпотентность). Каждый потребитель должен идентифицировать уже обработанное событие, обычно по уникальному идентификатору транзакции, отправляемому в полезной нагрузке. Без этого автоматическая повторная попытка на стороне отправителя — или ручное повторное воспроизведение после сбоя — приводит к двойному обновлению, созданию дублирующей записи или, в худшем случае, двойному списанию.
Этот недостаток почти никогда не проявляется на демонстрации. Он проявляется при нагрузке, при реальном сетевом сбое или изменении в производственной среде, и тогда стоимость исправления включает в себя также и исправление данных. Организации, сталкивающиеся с аналогичной проблемой на уровне автоматизации, найдут дополнительный анализ в Техническом долге Salesforce в Flow и Apex.
Пример: розничная сеть с 40 филиалами и отдельной системой управления запасами
Предположим, гипотетическая розничная сеть «Северный ритейл» использует Salesforce Sales Cloud для команд продаж в 40 филиалах и отдельную ERP-систему, которая управляет запасами в реальном времени. До сих пор каждый заказ, закрытый в Salesforce, передавался в ERP через запланированное задание, которое выполнялось каждые 15 минут — решение, из-за которого менеджеры иногда видели устаревшие данные о запасах и подтверждали заказы на товары, которых уже не было в наличии.
Архитектурная команда решила публиковать пользовательский Platform Event с именем Order_Confirmed__e при каждом подтверждении заказа, с полезной нагрузкой, включающей уникальный идентификатор транзакции, список товаров и количество. ERP-система слушает это событие и обновляет запасы в течение нескольких секунд, проверяя идентификатор транзакции на соответствие таблице уже обработанных транзакций — чтобы предотвратить двойное списание, если событие придет дважды.
Кроме того, был настроен ночной процесс Reconciliation, который сравнивает общее количество подтвержденных заказов в Salesforce с общим количеством обновлений, полученных в ERP, и предупреждает о расхождениях выше определенного порога. Причина: даже при правильной Idempotency требуется раннее обнаружение длительного сбоя сети, а не только уверенность в том, что событие «точно дошло». Результат: время обновления сократилось с 15 минут до менее одной минуты, а количество случаев ошибочных данных о запасах заметно снизилось в течение месяца после внедрения.
Этот сценарий иллюстрирует ключевой принцип: ценность создается не только «переходом к событиям», а сочетанием четкого бизнес-события, проверки на дубликаты на стороне потребителя и процесса мониторинга, который выявляет расхождения до того, как они превратятся в жалобу клиента.
Распространенные риски и профилактические меры
| Риск | Как проявляется на практике | Профилактическая мера |
|---|---|---|
| Публикация события при каждом изменении поля | Дневной лимит событий превышается в течение нескольких дней | Публиковать значимые бизнес-события домена, а не технические события при каждом DML |
| Отсутствие проверки на дубликаты на стороне потребителя | Повторная попытка или воспроизведение создают дублирующие записи или обновления | Прикреплять уникальный идентификатор транзакции и проверять его перед каждой операцией |
| Зависимость от порядка поступления | Старое обновление перезаписывает более новое обновление | Прикреплять метку версии и отклонять события, более старые, чем последняя обработанная версия |
| Отсутствие сохранения Replay ID | После сбоя потребителя события между сбоем и окном Retention теряются | Сохранять Replay ID в надежном месте и запускать автоматическое повторное воспроизведение при перезапуске |
| CDC на объекте, часто меняющем структуру | Каждое изменение поля нарушает работу внешнего потребителя без предупреждения | Определить явный контракт данных и заранее сообщать об изменениях схемы |
| Отсутствие бизнес-мониторинга, только технический мониторинг | Интеграция "зеленая", но фактический остаток или заказы не совпадают | Добавить ежедневный процесс Reconciliation, который сравнивает бизнес-результаты между системами |
Контрольный список перед началом разработки событийного уровня
- ☐ Для каждого события есть четкий владелец: кто публикует и кто является бизнес-владельцем данных
- ☐ Определена и задокументирована фиксированная структура полезной нагрузки, а не структура, меняющаяся с каждым Sprint
- ☐ Выбор между пользовательским Platform Event и CDC сделан в соответствии с бизнес-целями или необработанными изменениями
- ☐ У каждого потребителя есть уникальный идентификатор транзакции и проверка на дубликаты (Idempotency)
- ☐ Определена обработка порядка по метке версии, а не по порядку поступления
- ☐ Replay ID сохраняется в надежном месте, и процесс восстановления определен и протестирован
- ☐ Существует бизнес-мониторинг (Reconciliation) в дополнение к техническому мониторингу очереди сообщений
- ☐ Протестированы сценарии нагрузки и частичного сбоя, а не только «счастливый путь»
- ☐ Суточный лимит событий (публикация + доставка) проверен на соответствие ожидаемому объему в производстве
- ☐ Определен операционный владелец для реагирования при обнаружении расхождения в Reconciliation
Как измерить эффективность архитектуры
| Область | Что измеряется | Частота проверки |
|---|---|---|
| Надежность доставки | Процент успешно доставленных событий без повторных попыток, и процент успешных после повторных попыток | Непрерывно |
| Разногласия Reconciliation | Разница между записями, подтвержденными источником, и записями, полученными назначением | Ежедневно |
| Задержка сквозной передачи (Latency) | Время между бизнес-событием и фактическим обновлением у потребителя | Непрерывно |
| Использование лимита событий | Процент от суточной квоты, фактически использованной | Еженедельно |
| Предотвращенные дубликаты | Количество событий, идентифицированных как дубликаты и заблокированных до выполнения | Еженедельно |
Рекомендуется выбрать не более трех-четырех показателей для первой версии и измерять их относительно базового уровня, собранного до перехода к событийной архитектуре, — а не относительно общего ощущения, что «теперь это быстрее».
Для планирования более широкой организационной структуры многочисленных интеграций следует также рассмотреть паттерны интеграции Salesforce и их влияние на Single Org против Multi Org архитектуру Salesforce, так как решение по событиям иногда пересекает организационные границы.
Заключение
Выбор между Platform Events и CDC — это не технический вопрос, который кратко рассматривается в начале проекта; он определяет, кто является источником истины, что разрешено потерять и как система ведет себя в случае сбоя. Организация, которая заранее планирует Ordering, Replay и Idempotency, и добавляет уровень бизнес-сверки (Reconciliation) в дополнение к техническому мониторингу, получает интеграцию, способную выдерживать нагрузку и частичные сбои. Организация, которая пропускает эти шаги, получает систему, которая кажется работоспособной при тестировании, но незаметно ломается в продуктовой среде, обычно без того, чтобы кто-либо заметил, пока ущерб уже не нанесен.
Организации, желающие получить поддержку в создании надежного событийного уровня в Salesforce, могут связаться с нами через сервис архитектуры CRM.