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

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

• Salesforce во внешние системы
• Внешние системы в Salesforce
• Организация Salesforce — организация Salesforce

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

• Избегайте ненужной репликации данных. Если данные не должны находиться в Salesforce, подумайте о виртуализации данных с Salesforce Connect. Увеличение объема данных в организации в конечном итоге приводит к увеличению объема данных, что может отрицательно сказаться на производительности и добавить техническую задолженность. Если ваши данные уже находятся в Salesforce и вам нужны во внешней системе, избегайте копирования их во внешнюю систему без крайней необходимости. Вместо этого предоставьте внешней системе доступ к данным посредством Salesforce API.
• Используйте MuleSoft или другие решения Enterprise Service Bus (ESB) или Extract-Transform-Load (ETL), если они доступны и являются частью существующего ландшафта. Поскольку эти инструменты созданы для поддержки миграции и трансформации данных, они часто имеют мощные возможности, позволяющие повторно использовать интеграции на предприятии, поддерживать более сильное управление и централизовать управление интеграциями. В этом руководстве, где бы ни была рекомендована MuleSoft Anypoint, подумайте, будет ли достаточно существующего решения ESB/ETL.
• Гармонизируйте данные из разных источников с Data 360 и Data Cloud One. С помощью модели данных Customer 360, разрешающей способности при опознавании, объединения данных и других функций Data 360 объединяет данные из Salesforce и других внешних систем в объединенное представление вашего клиента. С помощью Data Cloud One пользователи других организаций Salesforce могут безопасно открывать данные, общедоступные виртуально из Data 360, через пространства данных.
• Перемещение данных между организациями посредством действий и активаций Data 360. После приема данных из разных организаций в Data 360 действия и активации данных могут синхронизировать данные с другой организацией. Этот метод может быть очень полезен для интеграций с организациями Marketing Cloud.
• Извлечение и перемещение данных посредством MuleSoft Anypoint. MuleSoft Anypoint можно использовать для извлечения данных из Data 360 посредством Connect API и Data Graph API и их перемещения в другую организацию Salesforce. Без Data 360 MuleSoft Anypoint можно также использовать, когда данные нужно переместить между организациями, не реплицируя в Data 360.
• Соблюдайте осторожность, если вы выбираете создание посредством исходящих сообщений. Salesforce продолжит поддерживать исходящие сообщения в рамках текущих функциональных возможностей, но не планирует осуществлять дальнейшие инвестиции в эту технологию.
• Лицензия пользователя интеграции с профилем «Только API» всегда рекомендуется для всех интеграций. Salesforce также рекомендует использовать приложения внешних клиентов (в пользу связанных приложений или входа SOAP) в качестве корректно разрешенных схем AuthN и AuthZ для всех интеграций.

Прежде чем начать работу с доступными инструментами интеграции данных, необходимо учитывать несколько общих рекомендаций при выборе инструмента. Как обычно в архитектуре, на каждый бизнес-вызов не существует директивного ответа. Если вы произнесли слова «это зависит» при выборе интеграции, значит, вы находитесь в правильном месте.

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

*Дополнительно требуется для сценариев использования событий сбора данных о массовых изменениях

**Дополнительно требуется для сценариев использования массовых событий платформы

***Подходит в ситуациях, когда бизнес-логика может выполняться в веб-обозревателе.

Легенда столбца:

• Доступно: хорошо работает для большинства способов использования
• Не идеально: возможно, но рассмотрим альтернативный инструмент
• Недоступно: поддержка в ближайшие 12 месяцев не планируется

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

Веб- компоненты Lightning обычно используются для интеграций процессов, но они могут выполнять выноски посредством функций JavaScript, поэтому данные могут быть задействованы в этих транзакциях.

Поток Salesforce можно использовать для оркестрации внешних выносок посредством внешних служб или действий Apex. Salesforce Flow сам по себе не считается отдельным инструментом интеграции данных.

Мастер импорта данных и Data Loader могут использоваться для синхронизации, импорта и миграции данных. Хотя команды Data Loader могут также использоваться для автоматизации импорта и экспорта данных, интерфейс командной строки предназначен только для Windows, и ни один из этих инструментов не является рекомендуемой базой для стратегии интеграции данных. Вместо этого используйте их для дополнения стратегии управления данными и их обслуживания.

Команды данных Salesforce CLI могут использоваться для обработки записей в вашей организации. Доступны команды, помогающие импортировать и экспортировать данные посредством Bulk API и SObject Tree Save API, а также выполнять простые операции CRUD над отдельными записями посредством REST API. Salesforce CLI сам по себе не считается отдельным инструментом интеграции данных.

OmniStudio Data Mapper можно использовать в качестве декларативного инструмента ETL для перемещения данных между объектами Salesforce и структурами данных JSON. Хотя интерфейс REST создается автоматически для каждого интерфейса Data Mapper, предоставляя декларативный способ перемещения данных из внешних систем в объекты Salesforce, Data Mapper не является отдельной базой для стратегии интеграции данных. Действия Data Mapper доступны в процедурах интеграции OmniStudio.

Dataloader.io - это еще один инструмент загрузки данных для Salesforce, поддерживаемый платформой MuleSoft Anypoint Platform, позволяющий быстро и безопасно импортировать, экспортировать и удалить неограниченные объемы данных для предприятия. Dataloader.io не является рекомендуемой базой для стратегии интеграции данных.

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

• Низкокодированные инструменты для исходящих интеграций
• Гибридные инструменты для исходящих интеграций
• Инструменты Pro-Code для исходящих интеграций

При реализации возможностей заказ на связанные продукты должен быть создан в системе ERP компании или системе управления заказами.

Изменение сбора данных По мере обновления записей возможности, изменение сбора данных публикует события изменений, содержащие обновления объектов. События изменения используются клиентом по подключению CometD (или посредством коннектора MuleSoft) и используются для обновления ERP клиента или системы управления заказами. События изменений могут быть обогащены, чтобы всегда содержать коды внешних записей или другие данные из объекта (например, регион), необходимые для интеграции. Потоки событий изменения для нескольких объектов можно объединить в каналы для упрощенной подписки и обработки потоков (чтобы можно было подписаться на один поток и обработать его вместо многих).

Внешние службы При наличии веб-службы, поддерживающей спецификацию OpenAPI 2.0 или 3.0, операции и службы могут быть отображены в Salesforce как Внешняя служба. Операции API (например, создание заказа) можно вызвать как вызываемое действие в потоке, созданном посредством Flow Builder, когда этап возможности меняется на «Реализовано».

Heroku Connect Heroku Connect обычно используется для синхронизации базы данных Heroku Postgres и Salesforce. Если клиент использует Heroku Postgres в качестве транзакционного магазина источника истины, записи и изменения из Salesforce в Heroku Postgres можно синхронизировать посредством Heroku Connect. Там можно использовать потоковые коннекторы Heroku для публикации этих изменений в Apache Kafka и отправки их в качестве событий в последующие приложения, включая ERP или систему управления заказами.

Процедура интеграции OmniStudio При отправке заказа Omniscript, оркеструющий процесс, может опубликовать сведения о заказе в коннектор ERP или MuleSoft. Сообщение может быть выполнено либо напрямую посредством Omniscript (клиентский), либо косвенно посредством процедуры интеграции (серверный). Если система ERP выдает ошибку проверки, пользовательский интерфейс Omniscript должен уведомить пользователя, а при необходимости перевести и контекстуализировать ошибку для пользователя.

Salesforce Connect/ Внешние объекты В Salesforce можно создать поток, запущенный записью, который вставляет запись в связанный внешний объект (связанные внешние объекты) при изменении этапа возможности на « Реализовано». Поскольку это смешанная транзакция, во избежание ошибок добавьте элемент приостановления на ноль секунд между обновлением возможности и вставкой связанного внешнего объекта, чтобы закрыть один контекст транзакции до запуска нового.

* Дополнительно необходимо для сценариев массового использования.

**Тестирование и развертывание — это возможность создания в более низкой среде и развертывания посредством Metadata API, пакетов или наборов изменений в производственной среде.

При реализации возможностей заказ на связанные продукты должен быть создан в системе ERP или управления заказами компании.

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

Исходящие сообщения После настройки исходящих сообщений можно определить бизнес-правило, запущенное обновлением возможности для отправки SOAP-сообщения по HTTP(S) на указанный URL-адрес конечной точки, на котором размещен слушатель. Сообщение будет содержать поля, указанные при создании исходящего сообщения. Если сведения в объекте изменяются после постановки уведомления в очередь, но до его отправки, будут доставлены только обновленные сведения, а сообщения останутся в очереди до их успешной отправки или до истечения 24 часов. Через 24 часа сообщения удаляются из очереди. Если система ERP требует дополнительных данных, можно передать sessionId в исходящих сообщениях, чтобы внешняя система могла отправить запрос обратного вызова.

События платформы Вы можете определить событие платформы, содержащее настраиваемую полезную нагрузку с данными, необходимыми для создания записей во внешней системе. Поскольку события платформы не публикуются автоматически при изменении записи, необходимо опубликовать событие посредством Apex, Salesforce Flow или конструктора процессов, когда этап возможности меняется на «Реализовано». Внешняя служба прослушивает канал событий платформы посредством CometD (или коннектор MuleSoft) и создает соответствующие записи во внешней системе.

Salesforce Connect/ Внешние объекты (с настраиваемыми адаптерами Apex) Решение на основе Salesforce Connect/ Внешние объекты не идеально подходит для сценария использования, требующего только синхронизации данных. Однако, это решение может применяться в случаях, когда пользователям в Salesforce нужно видеть и потенциально взаимодействовать с данными из внешней системы, а данные не могут быть реплицированы в Salesforce. Если ERP или система управления заказами не поддерживает протоколы Odata или GraphQL, рабочая группа разработчика может использовать инфраструктуру коннекторов Apex для записи классов Apex, обрабатывающих связь с внешней системой посредством поддерживаемого протокола.

Data 360 Решение, основанное на Data 360, идеально подходит для тех случаев, когда нам нужны согласованные данные из разных источников в одном хранилище данных. Его также можно использовать, когда нам нужно реплицировать данные из одной организации Salesforce в несколько организаций Salesforce или в другие внешние системы, используя Data 360 в качестве центра обработки данных. Когда возможность реализована и обновлена в исходной организации, данные возможности будут синхронизированы с Data 360, где их можно реплицировать в других системах, включая организации Salesforce, используя разные механизмы, например, действия, активации и API. Таким же образом, возможность может быть передана без репликации данных в других организациях Salesforce посредством Data Cloud One. Однако Data Cloud One не поддерживает платформы, не принадлежащие Salesforce.

* Включение Shield Platform Encryption изменяет некоторые алгоритмы, см. Общие рекомендации Shield Platform Encryption.

**Тестирование и развертывание — это возможность создания в более низкой среде и развертывания посредством Metadata API, пакетов или наборов изменений в производственной среде.

При реализации возможностей заказ на связанные продукты должен быть создан в системе ERP или управления заказами компании.

Настраиваемый Apex Вы можете создать триггер Apex и средство обработки триггеров в возможности, которое выполняет вызов ERP или системы управления заказами при изменении этапа возможности на « Реализовано». Обратите внимание, что при выполнении выносок из триггера или после выполнения операции DML необходимо использовать метод, обозначенный будущим или доступным для очереди. Выноска в триггере удерживает подключение к базе данных открытым на протяжении всего срока действия выноски. Все коды Apex связаны ограничениями Apex Governor и API, которые постоянно пересматриваются.

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

MuleSoft Anypoint MuleSoft Anypoint предоставляет управление API корпоративного уровня. MuleSoft Anypoint может создавать API для предоставления доступа чтения (и/или записи) к данным Salesforce и многих других корпоративных систем. Существует много готовых коннекторов для упрощения внедрения, и компании могут также создавать и публиковать собственные коннекторы. Эти API можно развернуть в Anypoint с помощью гибких политик безопасности, поддерживающих централизованное управление и управление. Ограничений по объему транзакций нет, если API имеет соответствующий размер для пикового использования (согласно vCores).

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

• Низкокодированные инструменты для входящих интеграций
• Гибридные инструменты для входящих интеграций
• Инструменты Pro-Code для входящих интеграций

*Тестирование и развертывание — это возможность создания в более низкой среде и развертывания посредством Metadata API, пакетов или наборов изменений в производственной среде.

Контакт обновляется в системе ERP организации. Эти контактные данные нужно обновить в Salesforce.

Heroku Connect Heroku Connect обычно используется для синхронизации базы данных Heroku Postgres и Salesforce. Если система ERP не использует Heroku Postgres в качестве магазина транзакций, этот сценарий использования невозможен. Если Heroku Postgres используется, изменения, внесенные в таблицы Postgres, могут быть синхронизированы с объектами в Salesforce посредством Heroku Connect.

Процедура интеграции OmniStudio После обновления системой ERP записи контакта процедура интеграции OmniStudio с действием загрузки Data Mapper и действием ответа может быть вызвана посредством REST API, созданного Data Mapper. Сначала действие загрузки Data Mapper отправляет полезные данные JSON или XML, которые используются для обновления записей контактов на основе поля «Внешний код» или посредством ключа вставки. Если простой ответ в JSON является единственным ожидаемым, действие ответа может отправить обратно любую актуальную информацию из предыдущих действий, чтобы обозначить успех или неудачу. Если система ERP ожидает определенного ответа, трансформация Data Mapper или действие извлечения могут использоваться для создания ответа JSON или XML с дополнительными функциями декларативного добавления данных, созданных в триггерах обновлением записи контакта. Основной проблемой данного сценария является совпадение: Несколько вызовов для одновременного обновления одной записи контакта вызовут проблемы, поскольку API существует непосредственно в Salesforce.

Salesforce Connect / External Objects Salesforce Connect и внешние объекты не рекомендуются для данного сценария использования, поскольку сценарий требует репликации данных в Salesforce. При наличии ранее существовавшей интеграции Salesforce Connect, встроенной в ERP, можно настроить коннектор Odata 4.0 для поддержки сбора данных о внешних изменениях, если ERP может поддерживать сбор данных об изменениях. Кроме того, необходимо настроить в Salesforce подписку на поток изменений из ERP посредством Public/Sub API.

*Дополнительно необходимо для массовых случаев использования.

**Тестирование и развертывание — это возможность создания в более низкой среде и развертывания посредством Metadata API, пакетов или наборов изменений в производственной среде.

Контакт обновляется в системе ERP организации. Эти контактные данные нужно обновить в Salesforce.

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

Salesforce Connect/ Внешние объекты (с настраиваемыми адаптерами Apex) Это решение не применяется в сценарии использования, требующем репликации данных. Это решение применимо, если вам нужно, чтобы пользователи в Salesforce видели сведения из внешней системы, которые не должны или не могут быть реплицированы в Salesforce, а внешняя система не может поддерживать стандартные протоколы, например, Odata или GraphQL. См. Сценарий использования: Исходящая интеграция с использованием гибридных инструментов для примера сценария использования для настраиваемого адаптера Apex.

Data 360 При обновлении контакта во внешних системах, например, ERP, обновления контакта могут быть синхронизированы с Data 360 либо посредством готовых коннекторов, либо посредством API и инструментов прокодирования, например, MuleSoft. На контакт можно также ссылаться в Data 360 посредством механизма нулевого копирования (доступно на некоторых платформах). Как только данные появятся в Data 360, разные готовые механизмы интеграции могут использоваться для синхронизации данных с другими организациями Salesforce. Данные можно открыть посредством ссылки посредством Data Cloud One. Данные можно также реплицировать посредством активаций и других API посредством готовых коннекторов или с помощью инструментов прокодирования, например, платформы MuleSoft Anypoint.

*Применяются ограничения и назначения запросов API.

**Bulk API имеют аспекты поведения повторной попытки, а некоторые API предлагают защиту отката посредством параметра allOrNone (например, см. параметры allOrNone в запросах составных и коллекций)

***Включение Shield Platform Encryption изменяет некоторые алгоритмы, см. Общие рекомендации Shield Platform Encryption.

****Тестирование и развертывание обозначают возможность создания в более низкой среде и развертывания посредством Metadata API, пакетов или наборов изменений в производстве.

*****Комплексные API поддерживают многообъектную поддержку.

Контакт обновляется в системе ERP организации. Эти контактные данные нужно обновить в Salesforce.

Настраиваемые веб- службы Apex REST и SOAP Вы можете создать веб- службу посредством кода Apex, которая может выполнять операции CRUD (создание, чтение, обновление, удаление) над объектом «Контакт». Данная служба будет вызываться посредством SOAP или REST из внешней системы (ERP).

MuleSoft Anypoint Цель MuleSoft Anypoint - предоставить управление API корпоративного уровня. MuleSoft Anypoint предлагает большой набор готовых коннекторов, которые можно использовать для интеграции с многими системами ERP, включая SAP, Oracle EBS, Oracle ERP и NetSuite. Вы можете создать поток для прослушивания событий в этих системах ERP (в данном случае, при создании нового контакта). Когда поток запускается, он использует коннектор Salesforce для создания новой записи контакта (или обновления, если контакт уже существует). Кроме того, можно интегрировать с другими системами, если транзакция репликации включает синдикацию контакта с другими системами. При необходимости, можно использовать язык соотнесения и трансформации (DataWeave) для выполнения сложной логики и расчетов в качестве информационных потоков в нескольких разрозненных системах. Проверка подлинности по этим системам может быть выполнена посредством многих разных механизмов проверки подлинности, например, базовой проверки подлинности и OAuth. Ограничений по объему транзакций нет, если поток был надлежащим образом размерирован для его максимального использования (измеряется в vCores).

Собственные Salesforce API После завершения (или сразу после) транзакции обновления в системе ERP можно выполнить операцию обновления и вставки объекта «Контакт» посредством SOAP API или выполнить ИСПРАВЛЕНИЕ к Contact sObjects REST API в организации Salesforce.

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

*Тестирование и развертывание — это возможность создания в более низкой среде и развертывания посредством Metadata API, пакетов или наборов изменений в производственной среде

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

События платформы не подходят для интеграции данных из одной организации Salesforce в другую, поскольку они не могут «прослушивать» одно и то же событие между организациями. Настраиваемый Apex также не является рекомендованным подходом для такого типа интеграции.

Крупное предприятие работает в нескольких бизнес-единицах (BUs). Каждый BU имеет собственную организацию Salesforce. Отдельный клиент имеет дело с несколькими бизнес-единицами предприятия и, таким образом, имеет данные об организациях и возможностях в нескольких организациях. Предприятию нужен доступ к агрегированному представлению всех данных об организациях и возможностях во всех BU в одной организации.

Примечание: Все решения ниже проектных для наименьшего объема репликации данных, в соответствии с выноской No1.

Данные об организациях и возможностях Data 360 из разных организаций Salesforce можно принимать в Data 360 посредством готовых коннекторов Salesforce. Они также могут быть агрегированы и согласованы (при необходимости). Как только данные агрегируются в Data 360, они доступны в других организациях Salesforce посредством Data Cloud One без репликации данных.

Heroku Connect Для каждой отдельной организации BU можно использовать Heroku Connect для синхронизации изменений из Salesforce в единой базе данных Heroku Postgres. В этом сценарии двусторонняя синхронизация не включена, только синхронизация из Salesforce в Postgres. Потом в Heroku Connect можно включить поставщика Odata и выбрать таблицы, которые нужно отобразить в качестве внешних объектов в организации Salesforce, где нужно агрегированное представление. В Salesforce вы определяете внешний источник данных, указывающий на поставщика Odata в Heroku.

MuleSoft Anypoint MuleSoft Anypoint предоставляет управление API корпоративного уровня. MuleSoft Anypoint API можно настроить так, чтобы он считывал сведения из нескольких связанных организаций Salesforce посредством коннектора Salesforce с несколькими подключениями к организациям. Поток MuleSoft может запросить разные организации Salesforce и вернуть определенную структуру, расширенную или пополненную другими сторонними сведениями, при необходимости. При вызове API он выполнит все соответствующие выноски организации Salesforce (в данном примере запрос сведений об организации и возможности), чтобы данные могли быть обработаны потребителем (вероятно, пользовательский интерфейс). Проверка подлинности по этим системам может быть выполнена посредством разных механизмов проверки подлинности, включая базовую проверку подлинности и OAuth. Ограничений по объему транзакций нет, если поток был корректно размерирован для его максимального использования (измеряется в vCores или Cores).

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

Salesforce Connect с межорганизационным адаптером Межорганизационный адаптер Salesforce Connect не подходит для этого сценария, поскольку все организации или возможности из удаленных организаций будут отображаться в центральной организации как разные объекты. Например, невозможно добавить общую сумму для «Стоимости всех возможностей» во всех организациях.

Сценарий выборочных обновлений по организации: Торговый представитель, используя организацию А Salesforce, должен просматривать и обновлять данные обращений из организации Б Salesforce и добавлять комментарии к родительскому обращению в организации Б Salesforce во время работы в организации А. Данные не должны реплицироваться в организацию А.

Heroku Connect Вы можете использовать тот же подход, что описан в сценарии агрегации данных выше. Однако необходимо включить CRUD для внешнего объекта через коннектор Odata и записать изменения обратно в Heroku Postgres.

MuleSoft Anypoint MuleSoft Anypoint предоставляет управление API корпоративного уровня. Вы можете использовать тот же подход, что описан в сценарии агрегации данных выше.

Собственные Salesforce API используют именованные регистрационные данные и вызывают собственные Salesforce API для чтения и обновления данных в связанной организации Salesforce. Компонент должен быть создан для отображения данных.

Salesforce Connect с межорганизационным адаптером Возможность просмотра данных во внешнем объекте (а также редактирования данных, если для внешнего объекта включен CRUD) поддерживается посредством межорганизационного адаптера Salesforce. Взаимосвязи также поддерживаются между внешними объектами, поэтому можно связать с родительским обращением во внешнем объекте. Тем не менее, создание взаимосвязей — это процесс, выполняемый сегодня вручную и преобразующий существующий тип данных в тип данных взаимосвязи. Кроме того, оптимизации, выполненные в Service Cloud для более эффективной работы с обращениями, не попадают в удаленную организацию каскадом. Salesforce настоятельно рекомендует протестировать межорганизационный адаптер и оценить преимущества работы с внешними объектами по сравнению со стандартными объектами для вашего сценария использования.

Перекрестная организация синхронизации данных: Если организация клиента обновляется в одной из бизнес-единиц организации Salesforce, другие объекты организации Salesforce «Организация» должны обновляться для сохранения последовательности сведений об организации.

Данные Data 360 Data 360 могут использоваться для репликации данных из одной организации в другую организацию Salesforce. Данные организаций из одной организации Salesforce можно принимать в Data 360 посредством готовых коннекторов Salesforce. Мы можем использовать механизмы активации данных, например, пакетная активация, действия над данными в близком к реальному режиме времени или активации на основе API, а также для переноса данных из Data 360 в организацию Salesforce.

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

MuleSoft Anypoint MuleSoft Anypoint предоставляет управление API корпоративного уровня. Вы можете настроить приложение Mule с Flow Designer в MuleSoft Anypoint для прослушивания событий стандартного и настраиваемого объекта, чтобы запустить автоматически запущенный поток в Salesforce. Когда приложение Mule запускается, оно может вызвать коннектор Anypoint для Salesforce для связи с любым количеством организаций Salesforce. В этом случае, когда запись организации обновляется в одной организации Salesforce, приложение Mule может обновить записи организации в связанных организациях Salesforce. Каждая связанная организация Salesforce будет иметь уникальный этап обновления, встроенный в общий поток приложений в MuleSoft. Проверка подлинности по этим системам может быть выполнена посредством разных механизмов проверки подлинности, включая базовую проверку подлинности и OAuth. Нет ограничений по объему транзакций, если поток был надлежащим образом размерирован для его максимального использования (измеряется в vCores или Cores).

Собственные Salesforce API Replication API (операции getUpdated, getDeleted) могут использоваться для синхронизации данных между организациями, но этот метод не рекомендуется.

Salesforce Connect с межорганизационным адаптером Вы можете использовать потоки, запущенные записью, и внешние объекты для синхронизации некоторых данных между организациями Salesforce. Например, обновление записи организации в организации А инициирует поток, который потом обновляет соответствующую запись во внешнем объекте «Организация», который записывает эти обновления в запись организации в организации Б. Это требует корректного использования семантики потока во избежание смешанных транзакций DML. Также помните, что правила проверки и потоки в организации Б будут запущены аналогично изменениям, внесенным нашими REST/SOAP API.

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

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