Как правило, при внедрении Salesforce его нужно интегрировать с другими приложениями. Хотя каждый сценарий интеграции уникален, существуют общие требования и проблемы, которые должны решить разработчики и архитекторы.
Данный документ описывает стратегии (в виде схем) для данных распространенных сценариев интеграции. Каждая схема описывает структуру и подход для определенного сценария, а не детализирует конкретную реализацию. В этом документе вы найдете:
- Ряд схем, учитывающих ключевые сценарии интеграции «архетипа»
- Матрица выбора, которая поможет определить, какая схема больше всего соответствует вашему сценарию
- Советы и рекомендации по интеграции
Цель и область применения
Данный документ предназначен для конструкторов и архитекторов, которым требуется интеграция Salesforce Platform с другими приложениями на предприятии. Это содержимое представляет собой перегонку многих успешных внедрений архитекторов и партнеров Salesforce.
Чтобы ознакомиться с возможностями интеграции и параметрами, доступными для широкомасштабного внедрения приложений на основе Salesforce, ознакомьтесь со сводкой по схемам и руководством по выбору схем. Архитекторы и разработчики должны учитывать эти сведения о схеме и рекомендации на этапе разработки и внедрения проекта интеграции Salesforce.
При правильном внедрении эти схемы позволяют как можно быстрее добраться до производства и получить максимально стабильный, масштабируемый и необслуживаемый набор приложений. Собственные архитекторы-консультанты Salesforce используют эти схемы в качестве отправных точек во время архитектурных экспертиз и активно их поддерживают и улучшают.
Как и во всех схемах, это содержимое охватывает большинство сценариев интеграции, но не все. Хотя Salesforce разрешает интеграцию пользовательского интерфейса (UI), например, перемешивания, такая интеграция выходит за рамки данного документа.
Шаблон схемы
Каждая схема интеграции соответствует последовательной структуре. Это обеспечивает согласованность информации, предоставляемой в каждой схеме, а также упрощает сравнение схем.
Имя
Идентификатор схемы, который также обозначает тип интеграции, содержащийся в схеме.
Контекст
Общий сценарий интеграции, рассматриваемый схемой. Контекст предоставляет сведения о том, чего хотят добиться пользователи и как приложение будет поддерживать требования.
Проблема
Сценарий или проблема (выраженная в виде вопроса), для решения которой предназначена схема. Просматривая схемы, ознакомьтесь с этим разделом, чтобы быстро понять, подходит ли схема для вашего сценария интеграции.
Силы
Ограничения и обстоятельства, затрудняющие решение указанного сценария.
Решение
Рекомендуемый способ решения сценария интеграции.
Эскиз
Диаграмма последовательности UML, отображающая способ обработки сценария решением.
Результаты
Объясняет сведения о том, как применить решение к сценарию интеграции и как он разрешает силы, связанные с этим сценарием. Данный раздел также содержит новые проблемы, которые могут возникнуть в результате применения схемы.
Боковые панели
Дополнительные разделы, связанные со схемой, содержащие ключевые технические проблемы, варианты схемы, характерные проблемы схемы и т. д.
Пример
Сквозной сценарий, описывающий способ использования схемы проектирования в реальном сценарии Salesforce. В примере объясняются цели интеграции и способ внедрения схемы для достижения этих целей.
Сводка схемы
Следующая таблица содержит схемы интеграции, содержащиеся в этом документе.
Список шаблонов удаленный вызов процесса - запрос и ответ
| Шаблоны | Сценарий |
|---|---|
| Удаленный вызов процесса: запрос и ответ | Salesforce вызывает процесс в удаленной системе, ожидает завершения этого процесса, а потом отслеживает состояние на основе ответа из удаленной системы. |
| Удаленный вызов процесса: пожар и забвение | Salesforce вызывает процесс в удаленной системе, но не дожидается завершения процесса. Вместо этого удаленный процесс получает и принимает запрос, а потом передает управление обратно в Salesforce. |
| Пакетная синхронизация данных | Данные, хранимые в платформе Lightning, создаются или обновляются для отображения обновлений из внешней системы, а также при отправке изменений из платформы Lightning во внешнюю систему. Обновления в любом направлении выполняются пакетно. |
| Удаленный вызов | Данные, хранимые в Salesforce Platform, создаются, извлекаются, обновляются или удаляются удаленной системой. |
| Обновление пользовательского интерфейса на основе изменений данных | Пользовательский интерфейс Salesforce должен обновляться автоматически в результате изменения данных Salesforce. |
| Виртуализация данных | Salesforce открывает внешние данные в режиме реального времени. Это устраняет необходимость сохранения данных в Salesforce и последующей сверки данных между Salesforce и внешней системой. |
Шаблонный подход
Схемы интеграции в настоящем документе подразделяются на три категории:
-
Интеграция данных—Эти схемы рассматривают требование синхронизации данных, находящихся в двух или более системах, чтобы обе системы всегда содержали своевременные и значимые данные. Интеграция данных часто является самым простым типом интеграции, но требует надлежащих методов управления информацией, чтобы сделать решение устойчивым и эффективным с точки зрения затрат. Такие методы часто включают аспекты основного управления данными (MDM), управления данными, мастеринга, устранения дублирования, создания потока данных и другие.
-
Интеграция процесса: схемы в этой категории определяют необходимость использования бизнес-процессом двух или более приложений для выполнения задачи. При внедрении решения для этого типа интеграции запускающее приложение должно вызывать через границы процесса другие приложения. Обычно эти схемы также включают как оркестрацию (где одна заявка является центральным «контролером»), так и хореографию (где заявки являются многосторонними, а центрального «контролера» нет). Эти интеграции часто требуют сложных требований к дизайну, тестированию и обработке исключений. Кроме того, такие составные приложения обычно более требовательны к базовым системам, поскольку они часто поддерживают долгосрочные транзакции и возможность составления отчетов или управления состоянием процесса.
-
Виртуальная интеграция—Шаблоны в этой категории учитывают необходимость просмотра, поиска и изменения данных, хранящихся во внешней системе. При внедрении решения для этого типа интеграции запускающее приложение должно вызывать другие приложения и взаимодействовать с их данными в режиме реального времени. Этот тип интеграции устраняет необходимость репликации данных в системах и означает, что пользователи всегда взаимодействуют с последними данными.
Выбор оптимальной стратегии интеграции для системы не является простым делом. Существует много аспектов для рассмотрения и много инструментов, которые можно использовать, при этом некоторые инструменты более подходят для определенных задач, чем другие. Каждая схема учитывает определенные критические области, включая возможности каждой из систем, объем данных, обработку сбоев и транзакционность.
Руководство по выбору схемы
Матричные таблицы выбора содержат схемы и их ключевые аспекты, чтобы определить, какая схема больше всего соответствует вашим требованиям интеграции. Шаблоны классифицируются посредством следующих измерений.
| Аспект | Описание |
|---|---|
| Тип | Указывает стиль интеграции: Процесс, данные или виртуальный.
|
| Сроки | Указывает стиль интеграции: Процесс, данные или виртуальный.
|
Интеграция Salesforce с другой системой
Данная таблица содержит схемы и их ключевые аспекты, позволяющие определить наиболее подходящую схему при интеграции из Salesforce в другую систему.
| Тип | Сроки | Ключевая схема для рассмотрения |
|---|---|---|
| Интеграция процесса | Синхронно | Удаленный вызов процесса: запрос и ответ |
| Интеграция процесса | Асинхронный | Удаленный вызов процесса: пожар и забвение |
| Интеграция данных | Синхронно | Удаленный вызов процесса: запрос и ответ |
| Интеграция данных | Асинхронный | Обновление пользовательского интерфейса на основе изменений данных |
| Виртуальная интеграция | Синхронно | Виртуализация данных |
Интеграция другой системы в Salesforce
Данная таблица содержит схемы и их ключевые аспекты, которые помогут вам определить схему, наиболее подходящую вашим требованиям при интеграции из другой системы в Salesforce.
| Тип | Сроки | Ключевая схема для рассмотрения |
|---|---|---|
| Интеграция процесса | Синхронно | Удаленный вызов |
| Интеграция процесса | Асинхронный | Удаленный вызов |
| Интеграция данных | Синхронно | Удаленный вызов |
| Интеграция данных | Асинхронный | Пакетная синхронизация данных |
Термины и определения промежуточного программного обеспечения
Данная таблица содержит некоторые ключевые термины, связанные с промежуточным программным обеспечением, и их определения для данных схем.
| Термин | Определение |
|---|---|
| Обработка событий | Обработка событий — это получение идентифицируемого экземпляра в назначенном получателе («обработчик»). Ключевые процессы, связанные с обработкой событий, включают:
Помните, что средство обработки событий может в конечном итоге переслать событие клиенту события. Распространенные способы использования этой функции с промежуточным программным обеспечением могут быть расширены путем добавления популярной возможности «публикация/подписка» или «публикация/суб». В сценарии публикации/подписки промежуточная программа перенаправляет запросы или сообщения активным подписчикам событий данных из активных публикаторов событий данных. Эти потребители с активными слушателями могут потом извлечь события по мере их публикации. В интеграциях Salesforce, использующих промежуточные программы, промежуточный уровень принимает управление обработкой событий. Он собирает все актуальные события, синхронные или асинхронные, и управляет распространением во всех конечных точках, включая Salesforce. Или эта возможность может быть достигнута посредством корпоративной платформы сообщений Salesforce посредством шины событий с событиями платформы. |
| Преобразование протокола | Преобразование протокола обычно является программным приложением, которое преобразует стандартный или собственный протокол одного устройства в протокол, подходящий другому устройству для обеспечения совместимости. В контексте промежуточного программного обеспечения подключение к определенной целевой системе может быть ограничено протоколом. В таких случаях формат сообщения должен быть преобразован в формат целевой системы, в которой можно извлечь полезные данные, или инкапсулирован в него. Это также называется туннелированием. Salesforce не поддерживает преобразование собственных протоколов, поэтому считается, что любые такие требования соответствуют промежуточному программному уровню или конечной точке. |
| Перевод и трансформация | Трансформация — это возможность соотнесения одного формата данных с другим для обеспечения совместимости между различными интегрированными системами. Обычно процесс включает переформатирование сообщений в пути в соответствии с требованиями отправителя или получателя. В более сложных случаях одно приложение может отправить сообщение в собственном собственном формате, а два или более других приложения могут получить копию сообщения в собственном собственном собственном формате. Инструменты перевода и трансформации промежуточного программного обеспечения часто содержат возможность создания фасадов обслуживания для устаревших или других нестандартных конечных точек. Эти фасады обслуживания позволяют отображать эти конечные точки в качестве адресных для обслуживания. В интеграциях Salesforce считается, что любые такие требования соответствуют промежуточному программному уровню или конечной точке. Трансформация данных может быть закодирована в Apex, но мы не рекомендуем ее из соображений обслуживания и производительности. |
| Очередь и буферизация | Очередь и буферизация обычно зависят от асинхронной передачи сообщений, в отличие от архитектуры запроса-ответа. В асинхронных системах очереди сообщений предоставляют временное хранилище, когда целевая программа занята или подключение нарушено. Кроме того, большинство асинхронных промежуточных программных систем предоставляют постоянное хранилище для резервирования очереди сообщений. Ключевым преимуществом процесса асинхронного сообщения является то, что если приложение получателя по каким-либо причинам не сработает, отправители могут продолжить работу без изменений. Отправленные сообщения просто накапливаются в очереди сообщений для последующей обработки при перезапуске получателя. Salesforce предоставляет только явную возможность постановки в очередь в виде исходящих сообщений на основе бизнес-правил. Для предоставления истинной очереди сообщений для других сценариев интеграции, включая оркестрацию, хореографию процессов и качество обслуживания, требуется промежуточное программное решение. |
| Синхронные транспортные протоколы | Протоколы синхронной транспортировки ссылаются на протоколы, поддерживающие действия, в которых «один поток в абоненте отправляет сообщение запроса, блокирует ожидание ответа, а потом обрабатывает ответ... Поток запроса, ожидающий ответа, подразумевает наличие только одного невыполненного запроса или что канал ответа для этого запроса является личным для этого потока». |
| Асинхронные транспортные протоколы | Асинхронные транспортные протоколы ссылаются на протоколы, поддерживающие действия, когда «одна цепочка в абоненте отправляет сообщение запроса и настраивает обратный вызов ответа. Отдельный поток прослушивает сообщения с ответами. При получении ответного сообщения поток ответа вызывает соответствующий обратный вызов, который восстанавливает контекст абонента и обрабатывает ответ. Этот подход позволяет нескольким невыполненным запросам предоставлять общий доступ к одной цепочке ответов». |
| Маршрутизация посредника | Маршрутизация медиации — это спецификация сложного «потока» сообщений из компонента в компонент. Например, многие решения на основе промежуточного программного обеспечения зависят от системы очереди сообщений. Хотя некоторые реализации позволяют предоставлять логику маршрутизации посредством самого уровня службы сообщений, другие зависят от клиентских приложений для предоставления сведений о маршрутизации или разрешения смешивания обеих парадигм. В таких сложных случаях посредничество со стороны промежуточного программного обеспечения упрощает разработку, интеграцию и проверку. ординатор [Посредник] мог убедиться, что правильное сообщение попадает к соответствующему потребителю». |
| Хореография процесса и оркестрация обслуживания | Хореография процессов и оркестрация обслуживания являются каждой формой «композиции обслуживания», где координируется любое количество конечных точек и возможностей.
Разница между хореографией и сервисной оркестрацией заключается в следующем:
Части хореографии бизнес-процессов можно создать в бизнес-процессах Salesforce или с помощью Apex. Рекомендуем внедрять все сложные оркестрации в промежуточном программном слое из-за значений времени ожидания Salesforce и контролирующих ограничений, особенно в решениях, требующих истинной обработки транзакций. |
| Транзакционность (шифрование, подписание, надежная доставка, управление транзакциями) | Транзакционность можно определить как возможность поддержки глобальных транзакций, охватывающих все необходимые операции с каждым обязательным ресурсом. Транзакционность подразумевает поддержку всех четырех свойств КИСЛОТЫ, атомарность, согласованность, изолированность, долговечность, где атомарность гарантирует все или ничего результаты для единицы работы (транзакции).
Salesforce является транзакционной организацией, но не может участвовать в распределенных транзакциях или транзакциях, инициированных за пределами Salesforce. Поэтому предполагается, что для решений, требующих сложных многосистемных транзакций, транзакционность и связанные механизмы отката/компенсации внедряются на промежуточном уровне программного обеспечения. |
| Маршрутизация | Маршрутизацию можно определить как определение сложного потока сообщений из компонента в компонент. В современных решениях на основе служб такие потоки сообщений могут основываться на нескольких критериях, включая заголовок, тип содержимого, правило и приоритет.
В интеграциях Salesforce считается, что любые такие требования соответствуют промежуточному программному уровню или конечной точке. Маршрутизация сообщений может быть закодирована в Apex, но мы не рекомендуем ее из соображений обслуживания и производительности. |
| Извлечение, трансформация и загрузка | «Извлечение, трансформация и загрузка» (ETL) — это процесс, включающий:
Salesforce теперь также поддерживает сбор данных об изменении, то есть публикацию событий изменений, представляющих изменения в записях Salesforce. С помощью сбора данных об изменении клиент или внешняя система получает изменения записей Salesforce практически в режиме реального времени. С помощью этой информации клиент или внешняя система может синхронизировать соответствующие записи во внешнем хранилище данных. |
| Длительный опрос | Долгий опрос, также называемый программированием кометы, эмулирует информационный всплыв от сервера к клиенту. Подобно обычному опросу, клиент подключается и запрашивает информацию с сервера. Однако, вместо отправки пустого ответа, если информация недоступна, сервер держит запрос и дожидается получения информации (событие). Сервер потом отправляет полный ответ клиенту. Затем клиент немедленно отправляет повторный запрос сведений. Клиент постоянно поддерживает подключение к серверу, поэтому он всегда ожидает ответа. Если сервер истекает, клиент подключается повторно и начинает сначала. Salesforce Streaming API использует протокол Bayeux и CometD для длительных опросов.
|
Контекст
Salesforce используется для отслеживания интересов, управления ожидаемыми продажами, создания возможностей и сбора сведений о заказе, преобразующих интересы в интересы клиентов. Но система Salesforce не содержит и не обрабатывает заказы. После сбора сведений о заказе в Salesforce заказ создается в удаленной системе, которая управляет завершением заказа.
При внедрении этой схемы Salesforce вызывает удаленную систему для создания заказа, а потом дожидается успешного завершения. В случае успеха удаленная система синхронизирует ответ со статусом заказа и номером заказа. В рамках той же транзакции Salesforce обновляет номер заказа и статус внутренне. Номер заказа используется в качестве внешнего ключа для последующих обновлений удаленной системы.
Проблема
Когда событие происходит в Salesforce, как запустить процесс в удаленной системе, передать требуемую информацию в этот процесс, получить ответ из удаленной системы, а потом использовать эти данные ответа для внесения обновлений в Salesforce?
Силы
Ниже перечислены усилия, предпринимаемые при применении решений на основе данной схемы.
- Требует ли вызов удаленной системы, чтобы Salesforce дождался ответа, прежде чем продолжить обработку? Вызов удаленной системы является синхронным запросом-ответом или асинхронным запросом?
- Если вызов удаленной системы синхронный, должна ли Salesforce обрабатывать ответ как часть той же транзакции, что и первичный вызов?
- Размер сообщения маленький или большой?
- Основывается ли интеграция на возникновении определенного события, например, нажатие кнопки в пользовательском интерфейсе Salesforce или события на основе DML?
- Способна ли удаленная конечная точка отвечать на запрос с низкой задержкой? Сколько пользователей, вероятно, будут выполнять эту транзакцию в пиковый период?
Решение
Данная таблица содержит решения данной проблемы интеграции.
| Решение | Подгонка | Комментарии |
|---|---|---|
| Внешние службы вызывают вызов REST API | Лучшее | Внешние службы позволяют вызывать внешнюю службу, размещенную в декларативном режиме (код не требуется). Эту функцию лучше использовать при соблюдении следующих условий:
|
| Salesforce Lightning — компонент или страница Lightning инициирует синхронную выноску Apex REST или SOAP.</ Если удаленная конечная точка создает риск высокой задержки ответа (применимые ограничения см. в документации по последним ограничениям здесь), рекомендуется асинхронная выноска, также называемая продолжением, во избежание попадания в ограничения регулятора синхронных транзакций Apex. |
Лучшее | Salesforce позволяет израсходовать WSDL и создать итоговый класс Apex. Этот класс предоставляет необходимую логику для вызова удаленной службы. Salesforce также позволяет вызывать службы HTTP (REST) посредством стандартных методов GET, POST, PUT и DELETE. Инициированное пользователем действие на странице Lightning потом вызывает действие контроллера Apex, которое потом выполняет этот прокси-класс Apex для выполнения удаленного вызова. Страницы Lightning требуют настройки приложения Salesforce. |
| Синхронный триггер, вызываемый при изменении данных Salesforce, выполняет асинхронную выноску Apex SOAP или HTTP. | Неоптимально | Триггеры Apex можно использовать для выполнения автоматизации на основе изменений данных записи. Класс прокси Apex может быть выполнен в результате операции DML посредством триггера Apex. Однако, все вызовы, выполненные из контекста триггера, должны выполняться асинхронно из инициирующего события. Поэтому данное решение не рекомендуется для данной проблемы интеграции. Это решение лучше подходит для схемы «Удаленный вызов процесса: пожар и забвение». |
| Пакетное задание Apex выполняет синхронную выноску Apex SOAP или HTTP. | Неоптимально | Вы можете осуществлять вызовы удаленной системы из пакетного задания. Это решение позволяет выполнять пакетные удаленные процессы и обрабатывать ответ из удаленной системы в Salesforce. Однако, данный пакет имеет ограничения по количеству вызовов. Дополнительную информацию см. в разделе «Ограничения регулятора». Заданный пакетный запуск может выполнять несколько контекстов транзакций (обычно в интервалах 200 записей). Ограничения управляющего сбрасываются для каждого контекста транзакции. |
Эскиз
Данная диаграмма иллюстрирует синхронный удаленный вызов процесса посредством вызовов Apex.
Вызов Salesforce на удаленную систему
В этом сценарии:
- Действие инициируется на странице Lightning (например, нажатие кнопки).
- Обозреватель (посредством клиентского контроллера в случае компонента Lightning) выполняет HTTP POST, который, в свою очередь, выполняет действие над соответствующим контроллером Apex.
- Контроллер вызывает фактический вызов удаленной веб-службы.
- Ответ из удаленной системы возвращается в контроллер Apex. Контроллер обрабатывает ответ, обновляет данные в Salesforce при необходимости и повторно обрабатывает страницу.
В случаях, когда последующее состояние должно отслеживаться, удаленная система возвращает уникальный идентификатор, сохраненный в записи Salesforce.
Результаты
Применение решений, связанных с этой схемой, позволяет использовать инициированные событиями удаленные вызовы процессов, в которых Salesforce обрабатывает обработку.
Механизмы вызова
Механизм вызова зависит от решения, выбранного для внедрения этой схемы.
| Механизм вызова | Описание |
|---|---|
| Расширенная внешняя служба, встроенная в поток или Компонент Lightning или Контроллеры Apex |
Используется, когда удаленный процесс запускается как часть комплексного процесса, использующего пользовательский интерфейс, и результат должен отображаться или обновляться в записи Salesforce. Например, отправка оплаты кредитной картой во внешний шлюз оплаты и результаты оплаты немедленно возвращаются и отображаются пользователю. |
| Триггеры Apex | Используются в основном для вызова удаленных процессов посредством выносок Apex из событий, инициированных DML. Дополнительную информацию об этом механизме вызова см. в схеме Удаленный вызов процесса - пожар и забвение. |
| Пакетные классы Apex | Используется для вызова удаленных процессов в пакете. Дополнительную информацию об этом механизме вызова см. в схеме Удаленный вызов процесса - пожар и забвение. |
Обработка и восстановление ошибок
Важно добавить стратегию обработки ошибок и восстановления как часть общего решения.
-
Обработка ошибок: при возникновении ошибки (исключения или коды ошибок возвращаются абоненту) абонент управляет обработкой ошибок. Например, сообщение об ошибке, отображаемое на странице конечного пользователя или регистрируемое в таблице, требующей дальнейших действий.
-
Восстановление: изменения не будут зафиксированы в Salesforce до получения успешного ответа абонентом. Например, статус заказа не обновляется в базе данных до получения ответа, указывающего на успех. При необходимости абонент может повторить операцию.
Рекомендации по созданию эффективных систем
Импотентные возможности гарантируют безопасность повторных вызовов. Если импотентность не внедрена, повторные вызовы одного сообщения могут привести к разным результатам, что может привести к проблемам целостности данных. Возможные проблемы включают создание повторяющихся записей или повторную обработку транзакций.
Важно убедиться, что вызываемая удаленная процедура неэффективна. Если вызов выполняется посредством пользовательского интерфейса, нам нужно позаботиться об импотентности на уровне интеграции, особенно если нет гарантии, что Salesforce позвонит только один раз.
Наиболее типичным методом создания идемпотентного приемника является отслеживание повторов на основе уникальных идентификаторов сообщений, отправленных клиентом. Для отправки уникального кода сообщения необходимо настроить веб-службу Apex или вызовы REST.
Кроме того, операции, создающие записи в удаленной системе, должны проверить наличие повторов перед вставкой. Проверьте, передав уникальный код записи из Salesforce. Если запись существует в удаленной системе, обновите запись. В большинстве систем эта операция называется операцией обновления и вставки.
Рекомендации по безопасности
Любой вызов удаленной системы должен поддерживать конфиденциальность, целостность и доступность запроса. Ниже перечислены рекомендации по безопасности, характерные для использования вызовов Apex SOAP и HTTP в этой схеме.
-
Односторонний SSL включен по умолчанию, но двусторонний SSL поддерживается сертификатами, подписываемыми самостоятельно и центром сертификации, чтобы поддерживать подлинность клиента и сервера.
-
Чтобы упростить код Apex и настроить проверенные выноски, укажите именованные регистрационные данные в конечной точке выноски.
-
Рекомендуем использовать OAUTH 2.0 в качестве механизма проверки подлинности для интеграции во внешние системы.
-
При необходимости рекомендуем использовать односторонние хэши или цифровые подписи с помощью методов класса крипто Apex для обеспечения целостности запроса.
-
Удаленная система должна быть защищена путем внедрения соответствующих механизмов брандмауэра. См. Рекомендации по безопасности.
-
Salesforce в настоящее время не поддерживает WS-Security. Хотя он не создает нативно эти сложные заголовки WS-Security или автоматически внедряет их из входящего WSDL, их можно создать и внедрить вручную, создав настраиваемые классы Apex для обработки заголовков SOAP и маркеров безопасности для входящих запросов.
Боковые панели
Нет.
Своевременность
В этой связи важное значение имеет своевременность. Обычно:
- Запрос обычно вызывается из пользовательского интерфейса, поэтому процесс не должен заставлять пользователя ждать.
- Salesforce имеет настраиваемое время ожидания вызовов из Apex до 120 секунд.
- Завершение удаленного процесса выполняется своевременно, чтобы завершить его в пределах ограничения времени ожидания Salesforce и в пределах ожиданий пользователя.
- Внешние вызовы подчиняются ограничениям управляющего синхронными транзакциями Apex, поэтому убедитесь в уменьшении риска мгновенного выполнения более 50 транзакций, которые выполняются более пяти секунд каждая. В дополнение к обеспечению производительности внешней конечной точки, варианты уменьшения риска истечения срока действия включают:
- Установка времени ожидания внешней выноски на пять секунд.
- Использование продолжения в компонентах Lightning для обработки долгосрочных транзакций
Объемы данных
Данная схема используется в основном для небольших объемов действий в реальном времени, из-за небольших значений времени ожидания и максимального размера запроса или ответа для решения вызова Apex. Не используйте эту схему в действиях пакетной обработки, в которых полезные данные содержатся в сообщении.
Поддержка конечной точки и стандартов
Возможности и стандартная поддержка конечной точки зависят от выбранного решения.
| Решение | Рекомендации по конечной точке |
|---|---|
| Выноски HTTP Apex | Конечная точка должна иметь возможность принимать вызовы HTTP. Система Salesforce должна иметь доступ к конечной точке посредством общедоступного Интернета. Для личных и безопасных коммуникаций Salesforce теперь также начал безопасно поддерживать Salesforce Private connect посредством платформы Hyperforce. Дополнительную информацию см. в разделе Salesforce Private Connect.
Вы можете использовать выноски Apex HTTP для вызова служб REST посредством стандартных методов GET, POST, PUT, DELETE и PATCH. |
| Выноски Apex SOAP | Конечная точка должна иметь возможность принимать вызовы HTTP. Система Salesforce должна иметь доступ к конечной точке посредством общедоступного Интернета. Для личных и безопасных коммуникаций Salesforce теперь также начал безопасно поддерживать Salesforce Private connect посредством платформы Hyperforce. Дополнительную информацию см. в разделе Salesforce Private Connect.
Данное решение требует совместимости удаленной системы со стандартами, поддерживаемыми Salesforce. На момент написания статьи стандарты веб-служб, поддерживаемые Salesforce для выносок Apex SOAP:
|
Управление штатом
При интеграции систем ключи важны для постоянного отслеживания состояния. Есть два варианта.
- Salesforce сохраняет основной или уникальный ключ удаленной системы для удаленной записи.
- Удаленная система сохраняет уникальный код записи Salesforce или другой уникальный ключ.
Существуют конкретные рекомендации по обработке ключей интеграции, в зависимости от системы, содержащей основную запись, как показано в следующей таблице.
| Основной | Система Описание |
|---|---|
| Salesforce | Удаленная система сохраняет Salesforce RecordId или какой-либо другой уникальный ключ из записи. |
| Удаленная система | Вызов удаленного процесса возвращает уникальный ключ из приложения, и Salesforce сохраняет это значение ключа в уникальном поле записи. |
Сложные сценарии интеграции
В некоторых случаях решение, предписанное этой схемой, может требовать реализации нескольких сложных сценариев интеграции. Лучше всего использовать промежуточное программное обеспечение или вызвать составную службу Salesforce. Эти сценарии включают:
- Оркестрация бизнес-процессов и правил с использованием сложной логики потока
- Агрегация вызовов и их результатов в вызовах нескольких систем
- Трансформация как входящих, так и исходящих сообщений
- Поддержание целостности транзакций в вызовах нескольких систем
Правительственные ограничения
Дополнительную информацию об ограничениях Apex см. в разделе «Управляющие и ограничения выполнения» в Руководстве разработчика Apex.
Промежуточные возможности
Следующая таблица выделяет желательные свойства системы промежуточного программного обеспечения, участвующей в этой схеме.
| Свойство | Обязательно | Желательно | Не обязательно |
|---|---|---|---|
| Обработка событий | X | ||
| Преобразование протокола | X | ||
| Перевод и трансформация | X | ||
| Очередь и буферизация | X | ||
| Синхронные транспортные протоколы | X | ||
| Асинхронные транспортные протоколы | X | ||
| Маршрутизация посредника | X | ||
| Хореография процесса и оркестрация обслуживания | X | ||
| Транзакционность (шифрование, подписание, надежная доставка, управление транзакциями) | X | ||
| Маршрутизация | X | ||
| Извлечение, трансформация и загрузка | X | ||
| долгий опрос | X |
Пример
Коммунальная компания использует Salesforce и использует отдельную систему, содержащую сведения о выставлении счета клиентам. В процессе заказа необходимо создать новые организации для выставления счета в системе выставления счета, а Salesforce должна отображать номер организации для выставления счета в процессе активации заказа. У них есть существующая веб-служба, которая позволяет создать организацию для счета и возвращает номер организации для счета в качестве ответа.
Это требование может быть выполнено с помощью следующего подхода.
- Salesforce использует службу выставления счета WSDL из класса прокси Apex.
- Выполните класс прокси-сервера Apex со сведениями о клиенте, переданными во внешнюю веб-службу из настраиваемого контроллера Apex или внешней службы.
- Затем настраиваемый контроллер анализирует значения возврата из выноски Apex и сохраняет эту информацию в объекте salesforce.
Данный пример показывает, что:
- Состояние клиента отслеживается посредством номера организации, сохраненного в объекте организации Salesforce.
- Последующая обработка ответного сообщения абонентом
Контекст
Salesforce используется для отслеживания интересов, управления ожидаемыми продажами, создания возможностей и сбора сведений о заказе, преобразующих интересы в интересы клиентов. Однако, как часть процессов управления заказом, в системе выставления счетов для заказа необходимо создать организацию для счета.
При внедрении этой схемы Salesforce вызывает удаленную систему для создания организации выставления счета, но не дожидается успешного завершения вызова. Удаленная система может по желанию обновить Salesforce посредством новой организации для счета, созданной в отдельной транзакции.
Проблема
Когда событие происходит в Salesforce, как запустить процесс в удаленной системе и передать требуемую информацию этому процессу, не дожидаясь ответа из удаленной системы?
Силы
Ниже перечислены усилия, предпринимаемые при применении решений на основе данной схемы.
- Требует ли вызов удаленной системы, чтобы Salesforce дождался ответа, прежде чем продолжить обработку? Вызов удаленной системы синхронный или асинхронный?
- Если вызов удаленной системы синхронный, должен ли ответ быть обработан Salesforce как часть той же транзакции, что и вызов?
- Размер сообщения небольшой?
- Основывается ли интеграция на возникновении определенного события, например, нажатие кнопки в пользовательском интерфейсе Salesforce или события на основе DML?
- Обязательна ли гарантированная доставка сообщений из Salesforce в удаленную систему?
- Способна ли удаленная система участвовать в интеграции первого контракта, в которой Salesforce указывает контракт? В некоторых вариантах решений (например, исходящие сообщения) Salesforce указывает контракт, внедряемый удаленной конечной точкой системы.
- Поддерживает ли конечная точка или шина обслуживания предприятия (ESB) длительный опрос?
- Предпочтительны ли методы декларативной конфигурации настраиваемой разработке Apex? В этом случае решения, например, события платформы, предпочтительнее выносок Apex.
Решение
Следующая таблица содержит решения данной проблемы интеграции.
| Решение | Подгонка | Комментарии |
|---|---|---|
| События платформы под управлением потока | Лучшее | Декларативно создавайте потоки для внедрения событий платформы. Рекомендуемое решение - это когда удаленный процесс вызывается из события вставки или обновления. События платформы - это сообщения о событиях (или уведомления), отправляемые и получаемые приложениями для выполнения дальнейших действий. События платформы упрощают процесс передачи изменений и реагирования на них без написания сложной логики. Один или несколько подписчиков могут прослушать одно и то же событие и выполнить действия. Например, программная система может отправлять события, содержащие сведения о картриджах чернил принтера. Подписчики могут подписаться на события для мониторинга уровня чернил принтера и размещения заказов на замену картриджей с низким уровнем чернил. Внешние приложения могут прослушивать сообщения о событиях, подписавшись на канал посредством CometD. Приложения платформы, например, компоненты Lightning, могут подписываться на сообщения о событиях и с помощью CometD. Здесь также можно использовать Salesforce PubSub Api, основанный на gRPC и HTTP/2. Salesforce также поддерживает потоки, запущенные событиями платформы, что эффективно позволяет создавать слушателя посредством интерфейса Flow Builder. Этот тип потока запускается автоматически при публикации определенного сообщения о событии платформы в шине событий Salesforce. |
| Pub/Sub API | Лучшее | Pub/Sub API - это рекомендованный способ для внешних потребителей использовать события в шине событий. Public/Sub API на основе gRPC:
Событие платформы, определенное в Salesforce, становится доступным для внутренних и внешних потребителей. |
| Изменение сбора данных | Лучшее | Сбор данных об изменении (CDC) публикует события для изменений в записях Salesforce, соответствующих операциям создания, обновления, удаления и отмены удаления. Включение сбора данных об изменении (CDC) в Salesforce - чисто декларативный процесс, не требующий кода Apex. Сообщения-уведомления отправляются в шину событий, на которую клиенты могут подписаться посредством Public/Sub API или триггеров Apex. Системы, управляемые событиями, упрощают связь между распределенными корпоративными системами, повышают масштабируемость и предоставляют данные в реальном времени. Например, если сведения о заказе находятся в системе ERP и Salesforce, вы можете транслировать события изменения заказа из Salesforce в приложение интеграции. Затем приложение синхронизирует изменения в системе ERP |
| Процедуры интеграции Omnistudio | Хорошо | Используйте процедуры интеграции Omnistudio для декларативной автоматизации взаимодействий данных между Salesforce и внешними сторонними приложениями. Процедуры интеграции обрабатывают сложные трансформации данных, вызовы API и автоматизацию под управлением событий, а также могут выполнять несколько действий в одном вызове сервера. Используйте процедуры интеграции, если во время выполнения не требуется взаимодействие с пользователем, и вы хотите:
Подробнее о процедурах интеграции см. здесь. |
| События платформы под управлением настройки | Хорошо | Аналогично событиям платформы под управлением потока, но события создаются триггерами или классами Apex. Публиковать и потреблять события платформы можно посредством Apex или API. События платформы интегрируются с Salesforce Platform посредством триггеров Apex. Триггеры - это потребители событий на Salesforce Platform, которые прослушивают сообщения о событиях. Если внешнее приложение использует API или собственное приложение Salesforce использует Apex для публикации сообщения о событии, запускается триггер этого события. Триггеры выполняют действия в ответ на уведомления о событии. |
| Исходящие сообщения под управлением потока | Подгонка | Рекомендуемое решение для этого типа интеграции - когда удаленный процесс вызывается из события вставки или обновления. Salesforce предоставляет управляемую потоком возможность исходящих сообщений, которая позволяет отправлять сообщения SOAP в удаленные системы, запущенные операцией вставки или обновления в Salesforce. Эти сообщения отправляются асинхронно и не зависят от пользовательского интерфейса Salesforce. Исходящее сообщение отправляется в определенную удаленную конечную точку. Удаленная служба должна иметь возможность участвовать в интеграции первого контракта, где Salesforce предоставляет контракт. По получении сообщения, если удаленная служба не отвечает положительным подтверждением, Salesforce пытается отправить сообщение, предоставляя форму гарантированной доставки. |
| Настраиваемый компонент Lightning, инициирующий асинхронную выноску Apex SOAP или HTTP | Неоптимально | Это решение обычно используется в сценариях на основе пользовательского интерфейса, но требует настройки. Кроме того, решение должно обрабатывать гарантированную доставку сообщения в коде. Подобно решению для удаленного вызова процесса: шаблонное решение запроса и ответа, определяющее использование компонента Lightning вместе с выноской Apex. Разница в том, что в этой схеме Salesforce не дожидается завершения запроса, прежде чем передать управление пользователю. После получения сообщения удаленная система отвечает и указывает на получение сообщения, а потом асинхронно обрабатывает сообщение. Удаленная система возвращает управление Salesforce перед началом обработки сообщения, поэтому Salesforce не нужно ждать завершения обработки. |
| Триггеры Apex сделают Apex SOAP или HTTP асинхронной выноской | Неоптимально | Триггеры Apex можно использовать для выполнения автоматизации на основе изменений данных записи. Класс прокси Apex может быть выполнен в результате операции DML посредством триггера Apex. Однако, все вызовы, выполненные из контекста триггера, должны выполняться асинхронно. |
| Триггеры Apex сделают Apex SOAP или HTTP асинхронной выноской | Неоптимально | Вызовы удаленной системы могут выполняться из пакетного задания. Это решение позволяет выполнять пакетные удаленные процессы и обрабатывать ответы из удаленной системы в Salesforce. Однако, существуют ограничения количества вызовов для данного пакетного контекста. Дополнительную информацию см. в разделе «Краткий справочник по ограничениям и назначениям разработчиков Salesforce».
|
Эскиз
Следующая диаграмма иллюстрирует вызов из Salesforce в удаленную систему, в которой создание или обновление операций над записью инициирует вызов.
В этом сценарии:
- Удаленная система подписывается на событие платформы.
- Обновление или вставка выполняется для определенного набора записей в Salesforce.
- Поток Salesforce запускается при выполнении ряда условий.
- Этот поток создает событие платформы.
- Удаленный слушатель получает сообщение о событии и размещает сообщение в локальной очереди.
- Приложение очереди перенаправляет сообщение в удаленное приложение для обработки.
В случае, если удаленная система должна выполнять операции против Salesforce, можно внедрить дополнительную операцию обратного вызова.
Результаты
Применение решений, связанных с данной схемой, позволяет:
- Вызовы удаленных процессов, инициированные пользовательским интерфейсом, в которых результат транзакции может отображаться конечному пользователю
- Вызовы удаленного процесса, инициированные событием DML, в которых результат транзакции может быть обработан процессом вызова
Механизмы вызова
Механизм вызова зависит от решения, выбранного для внедрения этой схемы.
| Механизм вызова | Описание |
|---|---|
| Поток | Используются процессными и настраиваемыми решениями. События запускают процесс Salesforce, который потом может опубликовать событие платформы для подписки удаленной системой. |
| Pub / Sub API | Public/Sub API предоставляет единый интерфейс для публикации и подписки на события платформы, включительно с событиями мониторинга событий в реальном времени, и событиями сбора данных об изменении. На основе gRPC и HTTP/2 Public/Sub API эффективно публикует и предоставляет двоичные сообщения о событиях в формате Apache Avro. |
| Изменение сбора данных | Сбор данных об изменении Salesforce публикует события изменений, которые представляют изменения в записях Salesforce. Изменения включают создание новой записи, обновления существующей записи, удаление записи и отмену удаления записи. |
| Компонент Lightning и контроллеры Apex | Используется для асинхронного вызова удаленного процесса посредством выноски Apex. |
| Исходящие сообщения под управлением потока | Используется только для решения службы исходящих сообщений. События создания и обновления DML инициируют бизнес-правила Salesforce, которые потом могут отправить сообщение в удаленную систему. |
| Триггеры Apex | Используются для событий платформы под управлением триггера и вызова отдаленных процессов, используя выноски Apex из событий, инициированных DML. |
| Пакетные классы Apex | Используется для вызова удаленных процессов в пакетном режиме. |
Обработка и восстановление ошибок
Стратегия обработки ошибок и восстановления должна рассматриваться как часть общего решения. Оптимальный метод зависит от выбранного решения.
| Решение | Стратегия обработки и восстановления ошибок |
|---|---|
| Поток |
|
| Выноски Apex |
|
| Сбор данных об изменении (CDC) / События платформы |
|
Рекомендации по созданию эффективных систем
События платформы публикуются в шине только один раз. Повторная попытка со стороны Salesforce не предпринимается. ESB должен запросить повтор событий. В повторе код повтора события платформы остается неизменным, и ESB может попробовать повторяющиеся сообщения на основе кода повтора.
Идемпотентность важна для исходящих сообщений, поскольку она асинхронна и попытки запускаются, когда положительного подтверждения не получено. Таким образом, удаленная служба должна уметь обрабатывать сообщения из Salesforce неактивным способом.
Исходящие сообщения отправляют уникальный код на сообщение, и этот код остается неизменным для любых попыток. Удаленная система может отслеживать повторяющиеся сообщения на основе этого уникального кода. Уникальный код записи для каждой обновляемой записи также отправляется и может использоваться для предотвращения создания повторов записей.
Невероятные рекомендации по созданию в схеме «Удаленный вызов процесса: запрос и ответ» также применимы к этой схеме.
Рекомендации по безопасности
Любой вызов удаленной системы должен поддерживать конфиденциальность, целостность и доступность запроса. В зависимости от выбранного решения применяются разные рекомендации по безопасности.
| Решение | Рекомендации по безопасности |
|---|---|
| Выноски Apex | Вызов удаленной системы должен поддерживать конфиденциальность, целостность и доступность запроса. Ниже перечислены рекомендации по безопасности, характерные для использования вызовов Apex SOAP и HTTP в этой схеме.
|
| Сбор данных об изменении (CDC) / События платформы | Для событий платформы внешняя система подписчика должна иметь возможность авторизации в Salesforce Streaming API. События платформы соответствуют существующей модели безопасности, настроенной в организации Salesforce. Чтобы подписаться на событие, пользователю нужен доступ для чтения к объекту события. Для публикации события пользователю нужно полномочие «Создание» для объекта события. |
См. Рекомендации по безопасности.
Боковые панели
Нет.
Своевременность
Своевременность в меньшей степени зависит от схемы «огонь и забвение». Управление возвращается клиенту немедленно или после положительного подтверждения успешной передачи удаленной системе. При использовании исходящих сообщений Salesforce подтверждение должно произойти в течение 24 часов (это может быть продлено до семи дней); в противном случае срок действия сообщения истекает. Для событий платформы Salesforce отправляет события в шину событий и не ожидает подтверждения или подтверждения от подписчика. Если подписчик не забирает сообщение, он может запросить повтор события посредством кода ответа события. Сообщения о массовых событиях хранятся 72 часа (три дня). Чтобы извлечь прошлые сообщения о событиях, используйте клиенты CometD для подписки на канал.
Объемы данных
Рекомендации по объему данных зависят от выбранного решения. Ограничения каждого решения см. в разделе «Краткий справочник по ограничениям Salesforce».
Поддержка конечной точки и стандартов
Возможности и стандартная поддержка конечной точки зависят от выбранного решения.
| Решение | Рекомендации по конечной точке |
|---|---|
| Выноски Apex SOAP | Конечная точка должна иметь возможность обрабатывать вызов веб-службы посредством HTTP. Система Salesforce должна иметь доступ к конечной точке посредством общедоступного Интернета. Данное решение требует совместимости удаленной системы со стандартами, поддерживаемыми Salesforce. На момент написания статьи стандарты веб-служб, поддерживаемые Salesforce для выносок Apex SOAP:
|
| Выноски HTTP Apex | Конечная точка должна иметь возможность принимать вызовы HTTP и быть доступной в общедоступном Интернете в Salesforce. Выноски HTTP Apex можно использовать для вызова служб RESTful посредством стандартных методов GET, POST, PUT и DELETE. |
| Сбор данных об изменении (CDC) / События платформы |
|
Управление штатом
При интеграции систем уникальные идентификаторы записей важны для постоянного отслеживания состояния. Например, если запись создана в удаленной системе, у вас есть два варианта.
- Salesforce сохраняет основной или уникальный ключ удаленной системы для удаленной записи.
- Удаленная система сохраняет уникальный код записи Salesforce или другой уникальный ключ.
Следующая таблица содержит рекомендации по управлению штатами по следующей схеме.
| Основной | Система Описание |
|---|---|
| Salesforce | Удаленная система должна хранить Salesforce RecordId или другой уникальный ключ в записи Salesforce. |
| Удаленная система | Salesforce должен сохранить ссылку на уникальный идентификатор в удаленной системе. Поскольку процесс асинхронный, сохранение этого уникального идентификатора не может быть частью исходной транзакции. Salesforce должен предоставить уникальный код в вызове удаленного процесса. Затем удаленная система должна перезвонить в Salesforce для обновления записи в Salesforce посредством уникального идентификатора удаленной системы посредством уникального идентификатора Salesforce. Обратный вызов подразумевает определенную обработку состояния в удаленном приложении для сохранения уникального идентификатора Salesforce для этой транзакции, чтобы использовать ее для обратного вызова после завершения обработки или сохранения уникального идентификатора Salesforce в записи удаленной системы. |
Сложные сценарии интеграции
Каждое решение в этой схеме имеет разные рекомендации для сложных сценариев интеграции, например, трансформации и оркестрации процесса.
| Решение | Рекомендации |
|---|---|
| Выноски Apex | В определенных случаях, решения, предписанные этой схемой, требуют внедрения нескольких сложных сценариев интеграции, наиболее подходящих для использования промежуточного программного обеспечения или вызова Salesforce составной службы. Эти сценарии включают:
|
| Сбор данных об изменении (CDC) / События платформы | Учитывая статический, декларативный характер событий, в Salesforce невозможно выполнить сложные сценарии интеграции, например, агрегацию, оркестрацию или трансформацию. Удаленная система или промежуточная программа должны обрабатывать данные типы операций. |
| Процедуры интеграции OmniStudio | Процедуры интеграции (OmniStudio) предоставляют серверную оркестрацию без гражданства для координации нескольких базовых служб во время выполнения сложных декларативных трансформаций данных. Этапы цепочки процедур интеграции, например, действия HTTP, извлечение/трансформация/загрузка DataRaptor, набор значений, цикл/If и матричные поиски для нормализации, обогащения, агрегации и соотнесения полезных данных между контрактами пользовательского интерфейса и разрозненными API. Они поддерживают надежное управление временем выполнения, например, условное ответвление, пагинацию, время ожидания, повторные попытки, обработку частичных сбоев и продолжение ошибок, а также оптимизацию производительности, например, кэширование сервера и формирование ответа. IP-адреса можно вызывать синхронно из OmniScript или без заголовка посредством REST, включив многоразовые версионные «фасады интеграции», скрывающие заднюю сложность от каналов. |
Правительственные ограничения
В связи с многопользовательским характером Salesforce Platform существуют ограничения для исходящих выносок. Ограничения определяются типом исходящего вызова и временем вызова.
Ограничения и назначения, применяемые к событиям платформы, см. в Руководстве разработчика событий платформы.
Надежная служба сообщений
Надежные службы сообщений пытаются решить проблему гарантии доставки сообщения в удаленную систему, в которой отдельные компоненты ненадежны. Метод обеспечения получения сообщения удаленной системой зависит от выбранного решения.
В случае сбора данных об изменении Salesforce типы событий изменений предоставляются для обработки особых ситуаций, например, сбора изменений, не обнаруженных на серверах приложений Salesforce, или обработки больших загрузок изменений.
В некоторых случаях Salesforce отправляет события пробела вместо событий изменения, чтобы сообщить подписчикам об ошибках или при невозможности создания событий изменения. Событие пробела содержит сведения об изменении заголовка, например, тип изменения и код записи. Он не содержит сведений об изменении, например, полей записи. Для более эффективного сбора изменений события переполнения создаются для отдельных транзакций, превышающих порог. Дополнительную информацию см. здесь.
| Решение | Рекомендации по использованию надежных сообщений |
|---|---|
| Выноски Apex | Salesforce не предоставляет явной поддержки надежных протоколов службы сообщений (например, WS-ReliableMessaging). Рекомендуем отдаленной конечной точке, получающей сообщение Salesforce, внедрить надежную систему службы сообщений, например, JMS или MQ. Данная система обеспечивает полную комплексную гарантированную доставку в удаленную систему, которая в конечном итоге обрабатывает сообщение. Однако, эта система не обеспечивает гарантированную доставку из Salesforce в удаленную конечную точку, которую она вызывает. Гарантированная доставка должна выполняться посредством настроек Salesforce. Необходимо внедрить конкретные методы, например, обработку положительного подтверждения из отдаленной конечной точки в дополнение к настраиваемой логике повтора. |
| Сбор данных об изменении (CDC) / События платформы | События платформы пытаются предоставить надежную службу сообщений, временно сохраняя сообщения о событиях в шине событий. Подписчики могут наверстать упущенное в сообщениях о событиях, воспроизводя сообщения из шины событий посредством кода повтора сообщений о событиях. Шина события является распределенной системой и не имеет таких гарантий, как транзакционная база данных. Таким образом, Salesforce не может предоставить синхронный ответ для запроса на публикацию события. События находятся в очереди и буферизируются, а Salesforce пытается опубликовать события асинхронно. В редких случаях сообщение о событии может не сохраняться в распределенной системе во время первичных или последующих попыток. Это значит, что события не доставляются подписчикам и не подлежат восстановлению. |
Промежуточные возможности
Следующая таблица выделяет желательные свойства системы промежуточного программного обеспечения, участвующей в этой схеме.
| Свойство | Обязательно | Желательно | Не обязательно |
|---|---|---|---|
| Обработка событий | X | ||
| Преобразование протокола | X | ||
| Перевод и трансформация | X | ||
| Очередь и буферизация | X | ||
| Синхронные транспортные протоколы | X | ||
| Асинхронные транспортные протоколы | X | ||
| Маршрутизация посредника | X | ||
| Хореография процесса и оркестрация обслуживания | X | ||
| Транзакционность (шифрование, подписание, надежная доставка, управление транзакциями) | X | ||
| Маршрутизация | X | ||
| Извлечение, трансформация и загрузка | X | ||
| долгий опрос | X (обязательно для событий платформы) |
Вариант решения: события платформы: Алгоритм публикации и транзакции
Когда сообщения о событиях платформы публикуются немедленно, публикация событий не учитывает границы транзакций процесса публикации. Сообщения о событиях могут быть опубликованы до завершения транзакции или даже в случае сбоя транзакции. Этот алгоритм может привести к проблемам, когда подписчик ожидает найти данные, которые обязуется выполнить транзакция публикации. Данные могут отсутствовать при получении подписчиком сообщения о событии. Чтобы решить эту проблему, задайте алгоритм публикации события платформы «Опубликовать после обязательства» в определении события. Алгоритмы публикации, которые можно задать в определении события платформы:
- Публикация после обязательства, чтобы сообщение о событии было опубликовано только после успешного подтверждения транзакции. Выберите этот параметр, если подписчики полагаются на данные, подтверждаемые транзакцией публикации. Например, процесс публикует сообщение о событии и создает запись задачи. Второй процесс, подписанный на событие, запускается и ожидает найти запись задачи. Другая причина выбора этого алгоритма - нежелание публиковать сообщение о событии в случае сбоя транзакции.
- Опубликуйте немедленно, чтобы сообщение о событии было опубликовано при выполнении вызова публикации. Выберите этот параметр, если вы хотите опубликовать сообщение о событии, вне зависимости от успеха транзакции. Также выберите этот параметр, если публикатор и подписчики независимы, а подписчики не зависят от данных, предоставленных публикатором. Например, алгоритм немедленной публикации подходит для события, используемого для регистрации. Данный параметр позволяет подписчику получать сообщение о событии до подтверждения данных транзакцией публикатора.
Пример
Телекоммуникационная компания хочет использовать Salesforce в качестве основы для создания организаций посредством процесса создания интересов для возможностей. Заказ создается в Salesforce, когда возможность закрыта и реализована, но базовая система ERP является основной для данных. Заказ должен быть сохранен в записи возможности Salesforce, а статус возможности изменен, чтобы указать, что заказ был создан.
Ниже перечислены применяемые ограничения.
- Только декларативная разработка может быть реализована.
- Вам не требуется немедленное уведомление о номере заказа после преобразования возможности в заказ.
- Организация использует ESB, поддерживающий протокол CometD и способный подписаться на события платформы.
Этот пример лучше всего внедрить посредством событий Salesforce Platform, но он требует, чтобы ESB подписался на событие платформы.
Со стороны Salesforce:
- Создайте поток для запуска события платформы (например, когда статус возможности меняется на «Закрыто и реализовано»).
- Создайте событие платформы, публикующее сведения о возможности.
Со стороны удаленной системы:
- ESB подписывается на событие Salesforce Platform посредством протокола CometD.
- ESB получает одно или несколько уведомлений о том, что возможность должна быть преобразована в заказ.
- ESB перенаправляет сообщение в базовую систему ERP, чтобы создать заказ.
- После создания заказа в системе ERP отдельный поток перезванивает в Salesforce посредством SessionId в качестве маркера проверки подлинности. Обратный вызов обновляет возможность с номером заказа и статусом. Вы можете выполнить этот обратный вызов посредством документированных шаблонных решений, например, событий Salesforce Platform, Salesforce SOAP API, REST API или веб-службы Apex.
Данный пример иллюстрирует следующее.
- Выполнение удаленного процесса, вызываемого асинхронно
- Сквозная гарантированная доставка
- Последующий обратный вызов Salesforce для обновления состояния записи
Контекст
Вы переносите внедрение CRM в Salesforce и хотите:
- Извлеките и трансформируйте организации, контакты и возможности из текущей системы CRM и загрузите данные в Salesforce (исходный импорт данных).
- Извлекайте, трансформируйте и загружайте данные для выставления счетов клиентов в Salesforce из удаленной системы на еженедельной основе (постоянно).
- Извлеките сведения о действиях клиента из Salesforce и импортируйте их в локальное хранилище данных еженедельно (на постоянной основе).
Проблема
Как импортировать данные в Salesforce и экспортировать данные из Salesforce, учитывая, что эти импорт и экспорт могут помешать операциям конечного пользователя в часы работы и задействовать большие объемы данных?
Силы
При применении решений на основе данной схемы необходимо учитывать разные силы:
- Должны ли данные храниться в Salesforce? В противном случае, существуют другие варианты интеграции, которые может и должен учитывать архитектор (например, соотнесения).
- Если данные должны храниться в Salesforce, следует ли обновлять данные в ответ на событие в удаленной системе?
- Следует ли обновлять данные по расписанию?
- Поддерживают ли данные основные бизнес-процессы?
- Существуют ли требования к аналитике (отчетности), на которые влияет доступность этих данных в Salesforce?
Решение
Следующая таблица содержит разные решения этой проблемы интеграции.
| Решение | Подгонка | Основной компонент данных | Комментарии |
|---|---|---|---|
| Репликация посредством стороннего инструмента ETL | Лучшее | Удаленная система | Если внешней системе нужно отправить большой объем данных в Salesforce, используйте сторонний инструмент ETL, позволяющий выполнять сбор данных об изменении по сравнению с исходными данными. Инструмент реагирует на изменения в исходном наборе данных, трансформирует данные, а потом вызывает Salesforce Bulk API для выдачи операторов DML. Это также можно внедрить посредством Salesforce REST API, если количество записей меньше. |
| Репликация посредством стороннего инструмента ETL | Хорошо | Salesforce | Использование стороннего инструмента ETL, позволяющего выполнять сбор данных об изменениях по сравнению с наборами данных ERP и Salesforce. В этом решении Salesforce является источником данных, и вы можете использовать сведения о времени/статусе в отдельных строках для запроса данных и фильтрации целевого набора результатов. Это можно реализовать посредством пакетного API 2.0 или стандартных REST API (если количество записей меньше ). |
| Мастер импорта данных и приложение Data Loader | Подгонка | Salesforce / Внешняя система | Мастер импорта данных и приложение Data Loader могут использоваться для импорта, экспорта и миграции данных. Хотя команды Data Loader также могут быть созданы для автоматизации импорта и экспорта данных, интерфейс командной строки предназначен только для Windows. Ни один из этих инструментов не является рекомендуемой базой для стратегии интеграции данных. Они должны дополнять стратегию управления данными и их обслуживания. Дополнительную информацию о Data Loader см. здесь. |
| Удаленный вызов | Неоптимально | Удаленная система | Удаленная система может вызывать Salesforce посредством одного из API и выполнять обновления данных по мере их появления. Однако это приводит к значительному постоянному движению между двумя системами. Больше внимания следует уделять обработке ошибок и блокировке. Эта схема может привести к постоянным обновлениям, что может повлиять на производительность конечных пользователей. |
| Удаленный вызов процесса | Неоптимально | Salesforce | Система Salesforce может вызывать удаленные системы и обновлять данные по мере их появления. Однако это приводит к значительному постоянному движению между двумя системами. Больше внимания следует уделять обработке ошибок и блокировке. Эта схема может привести к постоянным обновлениям, что может повлиять на производительность конечных пользователей. |
Эскиз
Следующая диаграмма иллюстрирует последовательность событий в этой схеме, где Salesforce является основным объектом данных.
Диаграмма ниже иллюстрирует последующую синхронизацию событий в близком к реальному режиме времени, где Salesforce является основным объектом данных.
Результаты
Вы можете интегрировать данные, полученные извне, в Salesforce в следующих сценариях:
- Внешняя система является основной для данных: Salesforce является потребителем данных, предоставляемых одной исходной системой или несколькими системами. В этом сценарии обычно существует хранилище данных или маркер данных, агрегирующий данные до импорта данных в Salesforce.
- Salesforce является основным объектом данных — Salesforce — это система записи для определенных объектов, а клиентские приложения Salesforce по сбору данных об изменении могут быть проинформированы об изменениях в данных Salesforce.
В типичном сценарии интеграции Salesforce группа внедрения выполняет одно из следующих действий:
- Внедрите сбор данных об изменении в исходном наборе данных.
- Внедрите набор вспомогательных структур базы данных, известных как таблицы управления, в промежуточную локальную базу данных.
Инструмент ETL потом используется для создания программ, которые будут:
- Прочитайте таблицу управления, чтобы определить время последнего выполнения задания и извлечь любые другие нужные значения управления.
- Используйте указанные выше управляющие значения в качестве фильтров и запросите исходный набор данных.
- Примените предопределенные правила обработки, включительно с проверкой, обогащением и т. д.
- Используйте доступные коннекторы/возможности трансформации инструмента ETL для создания целевого набора данных.
- Запишите набор данных в объекты Salesforce.
- При успешной обработке обновите управляющие значения в таблице управления.
- Если обработка не удается, обновите таблицы управления значениями, которые включают перезапуск и выход.
Примечание: Рекомендуем создавать таблицы управления и связанные структуры данных в среде, к которой у инструмента ETL есть доступ, даже если доступ к Salesforce недоступен. Это обеспечивает адекватный уровень устойчивости. Система Salesforce должна рассматриваться в качестве инструмента, а инфраструктура ETL является центром.
Чтобы инструмент ETL получил максимальную выгоду от возможностей синхронизации данных, учитывайте следующее:
- Сцепите и упорядочите задания ETL, чтобы обеспечить целостный процесс.
- Используйте первичные ключи из обеих систем для соответствия входящих данных.
- Используйте определенные методы API для извлечения только обновленных данных.
- При импорте дочерних записей во взаимосвязи «Основная — подробная» или «Поиск» сгруппируйте импортированные данные посредством родительского ключа в источнике, чтобы избежать блокировки. Например, при импорте данных контактов сгруппируйте данные контактов по ключу родительской организации, чтобы максимальное количество контактов для одной организации можно было загрузить в одном вызове API. Отказ от группировки импортированных данных обычно приводит к загрузке первой записи контакта и последующим записям контакта для этой организации в контексте вызова API.
- Любая обработка после импорта, например, триггеры, должна обрабатывать данные только выборочно.
- Если ваш сценарий предполагает большие объемы данных, следуйте рекомендациям из этого модуля Trailhead Рекомендации для развертываний с большими объемами данных .
Обработка и восстановление ошибок
Стратегия обработки ошибок и восстановления должна рассматриваться как часть общего решения. Оптимальный метод зависит от выбранного решения.
| Расположение ошибки | Стратегия обработки и восстановления ошибок |
|---|---|
| Чтение из Salesforce посредством сбора данных об изменении |
|
| «Чтение» для Salesforce посредством сторонней системы ETL |
|
| Запись в Salesforce |
|
| Внешняя основная система | Ошибки должны обрабатываться в соответствии с рекомендациями основной системы. |
Рекомендации по безопасности
Любой вызов удаленной системы должен поддерживать конфиденциальность, целостность и доступность запроса. В зависимости от выбранного решения применяются разные рекомендации по безопасности.
- Лицензия платформы Lightning с полномочиями пользователя не менее «API Only» обязательна для разрешения доступа проверенного API к Salesforce API.
- Рекомендуем использовать стандартное шифрование для обеспечения безопасности доступа к паролю.
- Используйте протокол HTTPS при выполнении вызовов Salesforce API. При необходимости можно также прокси-трафик к Salesforce API посредством локального решения безопасности.
См. Рекомендации по безопасности.
Боковые панели
Нет.
Своевременность
Своевременность не имеет большого значения в этой схеме. Однако, необходимо позаботиться о создании интерфейсов, чтобы все пакетные процессы завершались в указанном пакетном окне.
Как и во всех пакетных операциях, настоятельно рекомендуем изолировать исходные и целевые системы во время окон пакетной обработки. Загрузка пакетов в рабочие часы может привести к спору, что приведет либо к сбою обновления пользователя, либо, что более важно, к сбою пакетной загрузки (или частичной пакетной загрузки).
Для организаций, осуществляющих глобальные операции, одновременное выполнение всех пакетных процессов может оказаться невозможным, поскольку система может постоянно использоваться. Методы сегментации данных, использующие типы записей и другие критерии фильтрации, могут использоваться для избежания споров по данным в этих случаях.
Управление штатом
Вы можете внедрить управление состоянием посредством суррогатных ключей между двумя системами. Если вам нужен любой тип управления транзакциями в организациях Salesforce, рекомендуем использовать схему Удаленного вызова посредством Apex.
Стандартная оптимистичная блокировка записи происходит на платформе, и любые обновления, выполненные посредством API, требуют, чтобы пользователь, редактирующий запись, обновил запись и инициировал транзакцию. В контексте Salesforce API оптимистическая блокировка обозначает процесс, в котором:
- Salesforce не поддерживает состояние записи, редактируемой определенным пользователем.
- После прочтения оно записывает время извлечения данных.
- Если пользователь обновляет запись и сохраняет ее, Salesforce проверяет, обновил ли запись другой пользователь за промежуток времени.
- Если запись была обновлена, система уведомляет пользователя о произведенном обновлении и пользователь должен извлечь последнюю версию записи, прежде чем продолжить обновления.
Промежуточные возможности
Наиболее эффективными внешними технологиями, используемыми для внедрения этой схемы, являются традиционные инструменты ETL. Важно, чтобы выбранные инструменты промежуточного программного обеспечения поддерживали Salesforce Bulk API.
Важно, но не важно, чтобы инструменты промежуточного программного обеспечения поддерживали функцию getUpdated(). Эта функция предоставляет наиболее близкое к стандартному внедрение возможности сбора данных об изменении на Salesforce Platform.
Следующая таблица выделяет желательные свойства системы промежуточного программного обеспечения, участвующей в этой схеме.
| Свойство | Обязательно | Желательно | Не обязательно |
|---|---|---|---|
| Обработка событий | X | ||
| Преобразование протокола | X | ||
| Перевод и трансформация | X | ||
| Очередь и буферизация | X | ||
| Синхронные транспортные протоколы | X | ||
| Асинхронные транспортные протоколы | X | ||
| Маршрутизация посредника | X | ||
| Хореография процесса и оркестрация обслуживания | X | ||
| Транзакционность (шифрование, подписание, надежная доставка, управление транзакциями) | X | ||
| Маршрутизация | X | ||
| Извлечение, трансформация и загрузка | X | ||
| Долгое голосование | X (обязательно для сбора данных об изменении Salesforce) |
Пример
Коммунальная компания использует пакетный процесс на основе центрального процессора, который назначает потенциальных клиентов отдельным торговым представителям и группам. Эти сведения нужно импортировать в Salesforce на ежедневной основе.
Клиент решил внедрить сбор данных об изменениях в исходных таблицах посредством коммерчески доступного инструмента ETL. Решение работает следующим образом:
- Подобно cron планировщик выполняет пакетное задание, которое назначает потенциальных клиентов пользователям и группам.
- После выполнения пакетного задания и обновления данных инструмент ETL распознает эти изменения посредством сбора данных об изменении. Инструмент ETL компилирует изменения из хранилища данных.
- Коннектор ETL использует Salesforce REST API для загрузки изменений в Salesforce.
Контекст
Salesforce используется для отслеживания интересов, управления ожидаемыми продажами, создания возможностей и сбора сведений о заказе, преобразующих интересы в интересы клиентов. Система Salesforce создает заказы внутри компании, а потом перенаправляет эти данные во внешнюю систему выставления счетов для инициализации и активации. Заказы выставления счета управляются внешней (удаленной) системой. Эта удаленная система должна обновить статус заказа в Salesforce при изменении заказа или объекта для выставления счета в статусе системы выставления счета.
Проблема
Как удаленная система подключается и проверяет подлинность в Salesforce для уведомления Salesforce о внешних событиях, создания записей и обновления существующих записей?
Силы
При применении решений на основе данной схемы необходимо учитывать разные силы:
- Цель удаленного вызова Salesforce для уведомления Salesforce о событии, произошедшем извне посредством архитектуры, управляемой событиями? Или цель выполнения операций CRUD над определенными записями? Если вы используете архитектуру, управляемую событиями, поставщик событий (удаленный процесс) отделяется от потребителя событий Salesforce.
- Требует ли вызов Salesforce, чтобы удаленный процесс дождался ответа, прежде чем продолжить обработку? Удаленные вызовы Salesforce всегда являются синхронными запросами-ответами, хотя удаленный процесс может отклонить ответ, если он не нужен для имитации асинхронного вызова.
- Каждая транзакция выполняется в отношении одного объекта Salesforce или нескольких связанных объектов?
- Какой формат сообщения (например, SOAP или REST или оба по HTTP)?
- Размер сообщения относительно маленький или большой?
- Если удаленная система поддерживает SOAP, может ли удаленная система участвовать в подходе «первый контракт», когда Salesforce диктует контракт? Это обязательно при использовании SOAP API, для которого поставляется предопределенный WSDL.
- Обязательна ли обработка транзакций?
- Насколько вы терпимы к настройке в Salesforce?
Решение
Данная таблица содержит разные решения данной проблемы интеграции.
| Решение | Подгонка | Комментарии |
|---|---|---|
| Составной API | Лучшее | Salesforce предоставляет составной API, который в основном является REST API и поддерживает составные запросы. Это может использоваться удаленными системами для:
Синхронный API: после выполнения вызова API удаленное клиентское приложение дожидается получения ответа от службы. Поведение транзакции/обязательства: по умолчанию составной API не позволяет добиться частичного успеха, если некоторые записи помечены ошибками. Это можно изменить, пометив флажок «все или ничего» как false, что позволит добиться частичного успеха. Обработка ошибок: Правильная обработка ошибок должна изучать текст ответа, а не только коды статуса HTTP. Составная конечная точка отвечает кодом статуса 200 HTTP, даже если внутри текста ответа отображается, что один из вложенных запросов не удался и транзакция должна была быть откатана. |
| REST API | Лучшее | Доступность—Salesforce предоставляет REST API, который удаленные системы могут использовать для:
Синхронный API: после выполнения вызова API удаленное клиентское приложение дожидается получения ответа от службы. REST API учитывает безопасность объекта и поля, настроенную в Salesforce на основе профиля зарегистрированного пользователя. REST открывает ресурсы (объекты/объекты) в качестве URI и использует HTTP-глаголы для определения операций CRUD над этими ресурсами. В отличие от SOAP, REST API не требует предопределенного контракта, использует XML и JSON для ответов и использует свободный ввод. REST API облегчен и предоставляет простой метод взаимодействия с Salesforce. Его преимущества включают простоту интеграции и разработки, а также отличный выбор для использования в мобильных и веб-приложениях. Поведение транзакции/обязательства: по умолчанию каждая запись рассматривается как отдельная транзакция и фиксируется отдельно. Ошибка изменения одной записи не приводит к откату других изменений записи. Этот алгоритм можно изменить на алгоритм «все или ничего». Используйте составные ресурсы REST API для выполнения ряда обновлений в одном вызове API. Bulk Data: любая операция над данными, содержащая более 2 000 записей, является хорошим кандидатом на успешное создание, выполнение и управление асинхронным бизнес-правилом, использующим инфраструктуру Bulk API 2.0. |
| Bulk API 2.0 | Лучше для пакетных операций | Bulk API 2.0 - это современный усовершенствованный API Salesforce для обработки крупномасштабных операций с данными. Bulk API 2.0 на основе REST предоставляет программную возможность асинхронной вставки, обновления, запроса или удаления больших наборов данных в организации Salesforce. Он создан для повышения эффективности при необходимости загрузки больших объемов данных в Salesforce или выполнения пакетных запросов к данным организации. В отличие от Bulk API 1.0, Bulk API 2.0 всегда обрабатывает пакеты параллельно и не поддерживает последовательный режим. Это означает, что:
Каждый пакет в Bulk API 2.0 обрабатывается как собственная транзакция. Это означает:
Хотя SOAP API можно также использовать для обработки большого количества записей, он становится менее оптимальным, если наборы данных содержат от сотен тысяч до миллионов записей. Это связано с относительно высокими накладными расходами и более низкими эксплуатационными характеристиками.
|
| Pub/Sub API | Лучшее |
Public/Sub API - это рекомендованный способ публикации событий в шине событий внешними публикаторами. Pub/Sub API - это API на основе gRPC, позволяющий внешним системам публиковать события платформы. The Pub/Sub API:
Событие платформы, определенное в Salesforce, становится доступным для внутренних и внешних потребителей. |
| События платформы | Лучшее |
События платформы определяются так же, как и объекты Salesforce. События платформы могут быть опубликованы посредством разных механизмов, например, REST API, Bulk API и SOAP API.
Публикация события посредством REST API аналогична созданию записи Salesforce. Формат конечной точки: POST /services/data/vXX.X/sobjects/EventName__e/
Bulk API поддерживает только операции создания и вставки. События в пакете публикуются в шине событий Salesforce асинхронно во время обработки пакетного задания. Поскольку события платформы являются SObjects, поддерживаются стандартные операции SOAP API. |
| SOAP API | Подгонка |
Доступность—Salesforce предоставляет SOAP API, который удаленные системы могут использовать для:
Синхронный API: после выполнения вызова API удаленное клиентское приложение дожидается получения ответа от службы. Асинхронные вызовы Salesforce не поддерживаются. Созданный WSDL: Salesforce предоставляет два WSDL для удаленных систем:
Безопасность: клиент, выполняющий SOAP API, должен иметь действительный вход и получить сеанс для выполнения вызовов API. API учитывает безопасность объекта и поля, настроенную в Salesforce на основе профиля зарегистрированного пользователя. Поведение транзакции/обязательства: по умолчанию каждый вызов API позволяет добиться частичного успеха, если некоторые записи помечены ошибками. Данное действие может быть изменено на алгоритм «Все или ничего», при котором все результаты откатываются в случае возникновения ошибки. Транзакцию невозможно охватить несколькими вызовами API. Чтобы преодолеть это ограничение, один вызов API может повлиять на несколько объектов. |
| Веб-службы Apex | Неоптимально |
Методы класса Apex могут быть открыты в качестве методов веб-службы для внешних приложений. Этот метод является альтернативой SOAP API и обычно используется только при соблюдении следующих дополнительных требований.
Польза от использования веб-сервиса Apex должна соотноситься с дополнительным кодом, который необходимо поддерживать в Salesforce. Не применимо к событиям платформы, поскольку логика предварительной вставки транзакций у клиента не применяется в архитектура под управлением событий. Чтобы уведомить организацию Salesforce о наступлении события, используйте SOAP API, REST API или Bulk API 2.0. |
| Службы Apex REST | Неоптимально |
Класс Apex может быть открыт как ресурсы REST, соотнесенные с определенными URI-адресами посредством определенного HTTP-глагола (например, POST или GET).
Составные ресурсы REST API можно использовать для выполнения нескольких обновлений в одной транзакции. В отличие от SOAP, клиент не должен использовать определение услуги/контракт (WSDL) и создавать заглушки клиента. Удаленная система требует только возможности формирования HTTP-запроса и обработки возвращенных результатов (XML или JSON). Не применимо к событиям платформы, поскольку логика предварительной вставки транзакций у клиента не применяется в архитектура под управлением событий. Чтобы уведомить организацию Salesforce о наступлении события, используйте SOAP API, REST API или Bulk API 2.0. |
Эскиз
Следующие диаграммы иллюстрируют последовательность событий при внедрении данной схемы посредством REST API для уведомлений из внешних событий или SOAP API для запроса объекта Salesforce. Последовательность событий одинакова при использовании REST API.
Удаленный системный запрос Salesforce посредством SOAP API
Удаленное системное уведомление Salesforce посредством событий посредством REST API
Результаты
В архитектуре под управлением событий удаленная система вызывает Salesforce посредством SOAP API, REST API или Bulk API 2.0 для публикации события в шине событий Salesforce. Публикация события уведомляет всех подписчиков. Подписчики событий могут находиться на Salesforce Platform, например, в потоках, или компонентах Lightning, триггерах Apex. Подписчики на события также могут быть внешними для Salesforce Platform, например, подписчики CometD.
При работе напрямую с объектами Salesforce решения, связанные с данной схемой, позволяют:
- Удаленная система вызывает Salesforce API для запроса базы данных и выполнения операций с одним объектом (создание, обновление, удаление и т. д.).
- Удаленная система для вызова составных ресурсов Salesforce REST API для выполнения ряда операций объекта.
- Удаленная система вызова настраиваемых Salesforce API (служб), поддерживающих многообъектные транзакционные операции и настраиваемую логику обработки до/после публикации.
Механизмы вызова
Механизм вызова зависит от решения, выбранного для внедрения этой схемы.
| Механизм вызова | Описание |
|---|---|
| SOAP API | Удаленная система использует Salesforce Enterprise или Partner WSDL для создания клиентских заглушек, которые, в свою очередь, используются для вызова стандартного SOAP API. |
| REST API | Удаленная система должна пройти проверку подлинности перед доступом к любой службе Apex REST. Удаленная система может использовать OAuth 2.0 или проверку подлинности имени пользователя и пароля. В любом случае клиент должен задать заголовок HTTP авторизации с соответствующим значением (маркер доступа OAuth или код сеанса можно приобрести посредством вызова SOAP API). Удаленная система потом создает вызовы REST (HTTP-запросы) с соответствующими глаголами и обрабатывает возвращенные результаты (поддерживаются форматы данных JSON и XML). |
| Веб-служба Apex | Удаленная система использует настраиваемую веб-службу Apex WSDL для создания клиентских заглушек, которые, в свою очередь, используются для вызова настраиваемой веб-службы Apex. |
| Служба Apex REST | Согласно REST API, URI ресурса и применимые глаголы определяются посредством примечаний @RestResource, @HttpGet и @HttpPost. |
| Bulk API 2.0 | Bulk API 2.0 является API на основе REST, поэтому применяются те же механизмы вызова, что и REST API. |
| REST API для вызова потока | Используйте REST API для вызова конечной точки настраиваемых вызываемых действий для вызова автоматически запущенного потока. |
Обработка и восстановление ошибок
Стратегия обработки ошибок и восстановления должна рассматриваться как часть общего решения.
- Обработка ошибок: все методы удаленного вызова, стандартные или настраиваемые API, требуют, чтобы удаленная система обрабатывала любые последующие ошибки, например, время ожидания и управление повторными попытками. Промежуточные программы могут использоваться для предоставления логики обработки и восстановления ошибок.
- Восстановление — необходимо создать настраиваемый механизм повторной попытки, если этого требуют требования к качеству обслуживания. В данном случае важно обеспечить императивные характеристики дизайна. Событие платформы позволяет подписчикам использовать код повтора для извлечения сообщений в течение определенного периода времени после публикации этих сообщений.
Рекомендации по созданию эффективных систем
Импотентные возможности гарантируют безопасность повторных вызовов и не будут иметь негативных последствий. Если идемпотентность не внедрена, повторные вызовы одного сообщения могут привести к разным результатам, что может привести к проблемам целостности данных, например, созданию повторяющихся записей, повторной обработке транзакций и т. д.
Удаленная система должна управлять несколькими (повторяющимися) вызовами, в случае ошибок или истечения срока действия, во избежание повторных вставок и избыточных обновлений (особенно при запуске последующих триггеров и бизнес-правил). Хотя некоторые из этих ситуаций можно управлять в Salesforce (особенно в настраиваемых службах SOAP и REST), мы рекомендуем, чтобы удаленная система (или промежуточное программное обеспечение) управляла обработкой ошибок и идеальным дизайном.
Рекомендации по безопасности
В зависимости от выбранной схемы, применяются разные рекомендации по безопасности. Во всех случаях платформа использует права доступа зарегистрированного пользователя (например, параметры профиля, правила общего доступа, наборы полномочий и т. д.). Кроме того, ограничения IP-адресов профиля могут использоваться для ограничения доступа к API для определенного диапазона IP-адресов.
| Решение | Рекомендации по безопасности |
|---|---|
| SOAP API | alesforce поддерживает протоколы SSL и TLS. Длина ключа должна составлять не менее 128 бит. Удаленная система должна войти с помощью действительных регистрационных данных для получения кода сеанса. Если удаленная система уже использует действительный код сеанса, она может вызвать API без четкого входа. Это используется в схемах обратного вызова, описанных ранее в этом документе, где предыдущее исходящее сообщение Salesforce содержало код сеанса и код записи для последующего использования. Рекомендуем клиентам, вызывающим SOAP API, кэшировать и повторно использовать код сеанса для повышения производительности, а не получать новый код сеанса для каждого вызова. |
| REST API | Рекомендуем удаленной системе создать OAuth Trust для авторизации. Вызовы REST могут быть выполнены на определенных ресурсах посредством глаголов HTTP. Можно также осуществлять вызовы REST с действительным кодом сеанса, которые могли быть получены другими способами (например, извлечены посредством вызова SOAP API или предоставлены посредством исходящего сообщения). Рекомендуем клиентам, вызывающим кэш REST API и повторно использующим код сеанса, повысить производительность, а не получать новый код сеанса для каждого вызова. |
| Веб-служба Apex | Рекомендуем удаленной системе создать OAuth Trust для авторизации. |
| Служба Apex REST | Рекомендуем удаленной системе создать OAuth Trust для авторизации. |
| Bulk API 2.0 | Рекомендуем удаленной системе создать OAuth Trust для авторизации. |
См. Рекомендации по безопасности.
Боковые панели
Нет.
Своевременность
SOAP API и Apex web service API синхронизированы. Ниже перечислены применяемые сроки ожидания.
- Время ожидания сеанса — время ожидания сеанса истекает при отсутствии действий на основе параметра времени ожидания сеанса организации Salesforce.
- Время ожидания запроса: каждый запрос SOQL имеет индивидуальное ограничение времени ожидания 120 секунд.
Объемы данных
Рекомендации по объему данных зависят от выбранного решения и типа связи.
| Решение | Тип сообщения | Ограничения |
|---|---|---|
| SOAP API или REST API | Синхронно |
|
| Bulk API 2.0 | Асинхронный | Bulk API 2.0 оптимизирован для асинхронного импорта и экспорта больших наборов данных. Любая операция над данными, содержащая более 2 000 записей, является хорошим кандидатом на Bulk API 2.0 для успешной подготовки, выполнения и управления асинхронным бизнес-правилом, использующим инфраструктуру Bulk. Задания с менее 2 000 записей должны содержать «пакетные» синхронные вызовы в REST (например, составной) или SOAP. Bulk API 2.0 синхронизируется при отправке пакетного запроса и связанных данных. Фактическая обработка данных происходит асинхронно. Дополнительные сведения об ограничениях API и пакетной обработки см. в разделе Ограничения. |
Поддержка конечной точки и стандартов
Возможности и стандартная поддержка конечной точки зависят от выбранного решения.
| Решение | Рекомендации по конечной точке |
|---|---|
| SOAP API | Удаленная система должна быть способна внедрить клиента, который может вызвать Salesforce SOAP API на основе формата сообщения, предопределенного Salesforce. Удаленная система (клиент) должна участвовать в реализации первого контракта, когда контракт поставляется Salesforce (например, Enterprise или Partner WSDL). |
| REST API | Удаленная система должна быть способна внедрить клиент REST, который вызывает службы REST Salesforce и обрабатывает результаты XML или JSON. |
| Веб-служба Apex | Удаленная система должна быть способна внедрить клиента, который может вызывать сообщения SOAP предопределенного формата, как определено Salesforce. Удаленная система должна участвовать во внедрении с первым кодом, когда контракт поставляется Salesforce после внедрения веб-службы Apex. Каждая веб-служба Apex использует собственный WSDL. |
| Служба Apex REST | Применяются те же рекомендации по конечной точке, что и REST API. |
Управление штатом
При интеграции систем ключи важны для текущего отслеживания состояния, например, если запись создается в удаленной системе, для поддержки текущих обновлений этой записи. Существует два варианта:
- Salesforce сохраняет основной или уникальный ключ удаленной системы для удаленной записи.
- Удаленная система сохраняет уникальный код записи Salesforce или другой уникальный ключ. Ниже перечислены конкретные рекомендации по обработке ключей интеграции в синхронной схеме.
| Основной | system Описание |
|---|---|
| Salesforce | В этом сценарии удаленная система хранит Salesforce RecordId или какой-либо другой уникальный ключ из записи. |
| Удаленная система | В этом сценарии Salesforce сохраняет ссылку на уникальный идентификатор в удаленной системе. Поскольку процесс синхронный, ключ может быть предоставлен как часть той же транзакции посредством полей внешнего кода. |
Сложные сценарии интеграции
Каждое решение в этой схеме имеет разные рекомендации при обработке сложных сценариев интеграции, например, трансформации и оркестрации процесса.
| Решение | Рекомендации |
|---|---|
| SOAP API или REST API | SOAP API и REST API предоставляют простые транзакции для объектов. Сложные сценарии интеграции, например, агрегация, оркестрация и трансформация, не могут выполняться в Salesforce. Эти сценарии должны обрабатываться удаленной системой или промежуточным программным обеспечением, предпочтительным методом которого является промежуточное программное обеспечение. |
| Веб-служба Apex или служба Apex REST | Настраиваемые веб-службы могут предоставлять функции кросс-объектов, настраиваемую логику и более сложную поддержку транзакций. Это решение следует использовать осторожно, и всегда нужно учитывать пригодность промежуточного программного обеспечения для любой трансформации, оркестрации и логики обработки ошибок. |
Правительственные ограничения
В связи с многопользовательским характером Salesforce Platform существуют ограничения при использовании API.
| Решение | Ограничения |
|---|---|
| SOAP API, REST API и настраиваемые Apex API |
|
| Bulk API 2.0 | Дополнительную информацию см. на боковой панели «Объемы данных». |
| События платформы |
|
Надежная служба сообщений
Надежные службы сообщений пытаются решить проблему гарантии доставки сообщения в удаленную систему, где отдельные компоненты сами могут быть ненадежными. Salesforce SOAP API и REST API синхронизированы и не предоставляют явной поддержки для любых надежных протоколов службы сообщений, как таковых (например, WS-ReliableMessaging).
Мы рекомендуем удаленной системе внедрить надежную систему службы сообщений, чтобы обеспечить успешное управление сценариями ошибок и времени ожидания. Публикация событий платформы из внешних систем зависит от Salesforce API, поэтому применяются те же рекомендации для SOAP API и REST API.
Промежуточные возможности
Данная таблица выделяет желательные свойства системы промежуточного программного обеспечения, участвующей по следующей схеме:
| Свойство | Обязательно | Желательно | Не обязательно |
|---|---|---|---|
| Обработка событий | X | ||
| Преобразование протокола | X | ||
| Перевод и трансформация | X | ||
| Очередь и буферизация | X | ||
| Синхронные транспортные протоколы | X | ||
| Асинхронные транспортные протоколы | X | ||
| Маршрутизация посредника | X | ||
| Хореография процесса и оркестрация обслуживания | X | ||
| Транзакционность (шифрование, подписание, надежная доставка, управление транзакциями) | X | ||
| Маршрутизация | X | ||
| Извлечение, трансформация и загрузка | X (для пакетов/пакетов) |
Пример
Компания по производству полиграфических принадлежностей и услуг использует Salesforce в качестве основы для создания и управления принадлежностями и заказами принтеров. Записи активов Salesforce, представляющие принтеры, периодически обновляются статистикой использования печати (статус чернил, уровень бумаги) из локальной системы управления принтерами (PMS), которая регулярно отслеживает принтеры на клиентских сайтах. По достижении заданного значения порога (например, низкий статус чернил или низкий/пустой уровень бумаги менее 30%) несколько приложений/процессов (переменная), заинтересованных в событии, получают уведомления, отправляются электронные предупреждения или предупреждения Chatter и создается запись заказа. PMS сохраняет код Salesforce (Salesforce является основным в записи актива).
Ниже перечислены ограничения:
- PMS может участвовать в интеграции первого контракта, когда Salesforce предоставляет контракт, а PMS действует в качестве клиента (потребителя) службы Salesforce (определенной посредством Enterprise или Partner WSDL).
- В Salesforce не должно быть настраиваемых разработок.
Этот пример лучше внедрить посредством Salesforce SOAP API или REST API для публикации событий и декларативной автоматизации (Flow) в Salesforce. Основной причиной использования событий платформы является переменная и неконечное количество подписчиков; однако, для простых обновлений конечного списка записей, например, заказов, используйте SOAP или REST API для обновления записей.
В Salesforce:
- Определите событие платформы в Salesforce, чтобы содержать данные уведомлений, поступающие из PMS.
- Создайте поток, инициированный уведомлением о событии принтера. Процесс обновляет актив принтера и создает заказ (посредством автоматически запущенного потока).
- Загрузите Enterprise или Partner WSDL и предоставьте его удаленной системе.
В удаленной системе:
- Создайте клиентскую заглушку в Enterprise или Partner WSDL.
- Проверьте подлинность в Salesforce (посредством веб-сервера OAuth или процесса проверки подлинности маркера носителя) с помощью регистрационных данных пользователя интеграции.
- После события статуса принтера PMS вызывает API для создания события платформы статуса принтера (со статистикой использования принтера). Шина события Salesforce уведомляет подписчика потока и всех других подписчиков.
При использовании событий платформы шина событий позволяет проигрывать события в течение 72 часов для массовых событий платформы. Публикация этих событий посредством промежуточного программного решения может помочь внедрить обработку ошибок со стороны публикации. Однако, обработка ошибок может быть внедрена на стороне подписчика, если вам нужна более высокая надежность.
Данный пример иллюстрирует следующее:
- Внедрение синхронного API-клиента Salesforce (потребитель).
- Обратный вызов Salesforce для публикации события платформы (согласно ранее покрытым схемам событий платформы запрос/ответ).
Контекст
Salesforce используется для управления обращениями клиентов. Представитель службы поддержки разговаривает по телефону с клиентом, работающим над обращением. Клиент производит оплату, и представителю службы поддержки необходимо увидеть обновление в приложении Salesforce в реальном времени из приложения обработки оплаты, указывающее на успешную оплату непогашенной суммы заказа.
Проблема
Каким образом пользователь может получать уведомления в пользовательском интерфейсе Salesforce при возникновении события в системе Salesforce без обновления экрана и потенциальной потери работы?
Силы
При применении решений на основе данной схемы необходимо учитывать разные силы:
- Требуются ли данные для выполнения действий в Salesforce?
- Можно ли создать настраиваемый слой пользовательского интерфейса для просмотра этих данных?
- Будет ли у пользователя доступ для вызова настраиваемого пользовательского интерфейса?
Решение
Рекомендуем использовать события платформы, обеспечивающие события Salesforce в близком к реальному режиме времени. События платформы предоставляют структурированную, гибкую полезную нагрузку, не зависящую от объекта Salesforce. Он также обеспечивает долговременные темы с окном повтора 72 часа. Это обеспечивает доступность событий, даже если автономный потребитель становится доступным позже. Данное решение состоит из следующих компонентов :
- Триггер Apex или потоки с логикой публикации события платформы по теме
- Тема, позволяющая опубликовать событие из триггера Apex или потока
- Реализация протокола Байё на основе JavaScript (в настоящее время CometD), которая может использоваться пользовательским интерфейсом
- Компонент Lightning
- Библиотека JavaScript, добавленная в качестве статического ресурса
Эскиз
Следующая диаграмма иллюстрирует, как Streaming API может быть внедрен для потоковой передачи уведомлений в пользовательский интерфейс Salesforce. Эти уведомления запускаются изменениями записей в Salesforce.
Обновление пользовательского интерфейса в Salesforce, запущенное изменением данных
Результаты
Пособия
Применение решения, связанного с данной схемой, имеет следующие преимущества:
- Устраняет необходимость написания настраиваемых механизмов опроса
- Устраняет необходимость инициированного пользователем цикла отзывов
Неподдерживаемые требования
Решение имеет следующие ограничения:
- Доставка уведомлений не гарантируется.
- Порядок уведомлений не гарантируется.
- Уведомления не создаются на основе изменений записей, внесенных Bulk API.
Рекомендации по безопасности
Стандартная безопасность организации Salesforce соблюдается. Рекомендуется использовать протокол HTTPS для подключения к Streaming API. См. Рекомендации по безопасности
Боковые панели
Оптимальное решение включает создание настраиваемого пользовательского интерфейса в Salesforce. Необходимо учитывать соответствующий контейнер пользовательского интерфейса, который можно использовать для отображения настраиваемого пользовательского интерфейса. Поддерживаемые обозреватели перечислены в Руководстве разработчика Streaming API
Пример
Телекоммуникационная компания использует Salesforce для управления обращениями клиентов. Менеджеры по обслуживанию клиентов хотят получать уведомления об успешном закрытии обращения одним из представителей службы поддержки.
Внедряя решение, предписанное данной схемой, клиент должен:
- Создайте PushTopic триггера Apex, отправляющий событие платформы при сохранении обращения со статусом «Закрыто» и разрешением «Успешно».
- Создайте настраиваемый пользовательский интерфейс, доступный менеджерам по обслуживанию клиентов. Данный пользовательский интерфейс подписывается на шину событий для потребления событий платформы.
- Внедрите логику в настраиваемый пользовательский интерфейс, отображающий предупреждения, созданные представителями службы поддержки этого менеджера.
Контекст
Salesforce используется для отслеживания интересов, управления ожидаемыми продажами, создания возможностей и сбора сведений о заказе, преобразующих интересы в интересы клиентов. Однако, Salesforce не является системой, содержащей или обрабатывающей заказы. Заказы управляются внешней (удаленной) системой. Но торговые представители хотят просматривать и обновлять сведения о заказе в режиме реального времени в Salesforce без необходимости изучения или использования внешней системы.
Проблема
Как в Salesforce просматривать, искать и изменять данные, хранящиеся вне системы Salesforce, не перемещая данные из внешней системы в Salesforce?
Силы
При применении решений на основе данной схемы необходимо учитывать разные силы:
- Вы хотите создать декларативную/интенсивную исходящую интеграцию или сопоставление пользовательского интерфейса в Salesforce?
- У вас есть большой объем данных, которые вы не хотите копировать в организацию Salesforce?
- Требуется ли доступ к небольшим объемам данных удаленной системы одновременно?
- Нужен ли доступ к последним данным в режиме реального времени?
- Храните ли вы данные в облаке или в офисной системе, но хотите ли вы отобразить или обработать эти данные в организации Salesforce?
- Есть ли у вас проблемы с местопребыванием данных для хранения определенных типов данных в Salesforce?
Решение
Следующая таблица содержит разные решения этой проблемы интеграции.
| Решение | Подгонка | Комментарии |
|---|---|---|
| Salesforce Connect | Лучшее | Используйте Salesforce Connect для доступа к данным из внешних источников вместе с данными Salesforce. Извлекайте данные из таких систем, как SAP, Microsoft, Oracle и других облачных систем, например, Snowflake, в режиме реального времени, не создавая копию данных в Salesforce. Salesforce Connect соотносит таблицы данных во внешних системах с внешними объектами в вашей организации. Внешние объекты аналогичны настраиваемым объектам, но соотносятся с данными, расположенными за пределами организации Salesforce. Salesforce Connect использует оперативное подключение к внешним данным, чтобы всегда поддерживать актуальность внешних объектов. Доступ к внешнему объекту извлекает данные из внешней системы в режиме реального времени. Salesforce Connect позволяет:
Для доступа к данным, хранящимся во внешней системе посредством Salesforce Connect, можно использовать один из следующих адаптеров:
|
| Запрос и ответ | Неоптимально |
Используйте API веб-службы Salesforce для выполнения ситуативных запросов данных для доступа и обновления внешних системных данных. Это решение включает следующие подходы:
Используйте Salesforce SOAP API. Настраиваемая страница или кнопка синхронно инициирует выноску Apex REST/SOAP. В Salesforce можно израсходовать WSDL и создать итоговый класс Apex. Этот класс предоставляет необходимую логику для вызова удаленной службы. Инициированное пользователем действие на странице потом вызывает действие контроллера Apex, выполняющее этот прокси-класс Apex для выполнения удаленного вызова. Страницы требуют настройки приложения Salesforce. Используйте Salesforce REST API. Настраиваемая страница или кнопка инициирует выноску Apex HTTP (служба REST) синхронным образом. В Salesforce можно вызывать службы HTTP посредством стандартных методов GET, POST, PUT и DELETE. Дополнительные сведения об этом решении см. в разделе «Удаленный вызов процесса: запрос и ответ». |
Эскиз
Следующая диаграмма иллюстрирует, как можно использовать Salesforce Connect для извлечения данных из внешней системы посредством адаптера Odata.
В этом сценарии:
- Обозреватель выполняет вызов AJAX, который, в свою очередь, выполняет действие над соответствующим адаптером внешнего объекта.
- Адаптер переводит действие в запрос Odata и отправляет запрос HTTP GET в удаленную систему посредством уровней интеграции и служб.
- Удаленная система возвращает ответ JSON в Salesforce посредством уровней интеграции и служб.
- Ответ переводится с Odata во внешний объект и снова отображается в обозревателе.
Результаты
Применение решений, связанных с этой схемой, позволяет инициировать пользовательский интерфейс для отображения результата транзакции конечному пользователю.
Механизмы вызова
Механизм вызова зависит от решения, выбранного для внедрения этой схемы.
| Механизм вызова | Описание |
|---|---|
| Внешние объекты | Salesforce Connect соотносит внешние объекты Salesforce с таблицами данных во внешних системах. Вместо копирования данных в организацию Salesforce Connect открывает данные по запросу и в режиме реального времени. Несмотря на то, что данные хранятся вне организации, Salesforce Connect обеспечивает безупречную интеграцию с платформой Lightning. Внешние объекты доступны инструментам Salesforce, например, глобальный поиск, взаимосвязи поиска, ленты записей и мобильное приложение Salesforce. Внешние объекты также доступны для запросов Apex, SOSL, SOQL, Salesforce API и развертывания посредством Metadata API, наборов изменений и пакетов. |
| Компоненты освещения | Используется, когда удаленный процесс запускается как часть комплексного процесса, использующего пользовательский интерфейс, и результат должен отображаться или обновляться в записи Salesforce. Например, процесс, отправляющий платежи кредитной картой во внешний шлюз оплаты и немедленно возвращающий результаты оплаты, отображаемые пользователю. Интеграция, запущенная из событий пользовательского интерфейса, обычно требует создания настраиваемых компонентов Lightning. |
Обработка ошибок
Важно добавить обработку ошибок в общее решение. При возникновении ошибки (исключения или коды ошибок возвращаются абоненту) абонент управляет обработкой ошибок. Salesforce Connect Validator - это бесплатный инструмент для выполнения некоторых распространенных запросов и обнаружения типов ошибок и причин сбоев.
Пособия
Ниже перечислены некоторые преимущества использования решения Salesforce Connect:
- Это решение не использует хранилище данных в Salesforce.
- Пользователям не нужно беспокоиться о регулярной синхронизации данных между внешней системой и Salesforce.
- Декларативная настройка, которую можно быстро выполнить посредством Odata или межорганизационного адаптера, либо посредством минимального кода с настраиваемым адаптером Apex.
- Пользователи могут получать доступ к внешним данным с такими же функциями, как и к настраиваемым объектам в виде внешних объектов.
- Возможность выполнения интегрированного поиска в подключенной внешней системе посредством глобального поиска.
- Возможность запуска отчетов, открывающих внешние данные из облачных и локальных источников. См. рекомендации по составлению отчетов ниже.
Рекомендации Salesforce Connect
Решение Salesforce Connect имеет следующие рекомендации:
- Внешние объекты ведут себя как настраиваемые объекты, но некоторые функции недоступны для внешних объектов. Дополнительную информацию см. в разделе Рекомендации по совместимости Salesforce для Salesforce Connect.
- Внешние объекты могут повлиять на производительность отчета. Дополнительную информацию см. в разделе «Рекомендации по отчетам для Salesforce Connect».
- Дополнительные рекомендации по использованию адаптеров Salesforce Connect см. в разделе «Рекомендации по Salesforce Connect: все адаптеры».
- Если вы планируете использовать межорганизационный адаптер, см. Рекомендации по Salesforce Connect — межорганизационный адаптер.
- Если вы планируете использовать адаптер Odata, см. Рекомендации по Salesforce Connect: адаптеры Odata 2.0 и 4.0.
- Если вы планируете использовать настраиваемый адаптер Apex, см. раздел «Рекомендации по Salesforce Connect: настраиваемый адаптер».
Рекомендации по безопасности
Решения для этой схемы должны соответствовать стандартной безопасности организации Salesforce. Рекомендуем использовать протокол HTTPS для подключения к любой удаленной системе. Дополнительную информацию см. в разделе Рекомендации по безопасности
Если вы используете коннектор Odata, убедитесь в понимании особых алгоритмов, ограничений и рекомендаций для подделки межсайтовых запросов (CSRF) во внешних источниках данных Odata. Дополнительную информацию см. в разделе «Рекомендации CSRF по адаптерам Salesforce Connect — Odata 2.0 и 4.0».
Боковые панели
Нет.
Своевременность
В этой связи важное значение имеет своевременность. Ниже перечислены рекомендации.
- Запрос обычно вызывается из пользовательского интерфейса, поэтому процесс не должен заставлять пользователя ждать.
- В зависимости от доступности внешней системы и подключения к ней, извлечение внешних данных может занять много времени. Salesforce использует настраиваемое максимальное значение времени ожидания ответа от внешней системы, составляющее 120 секунд.
- Завершение удаленного процесса должно выполняться своевременно и в пределах ограничения времени ожидания Salesforce и в пределах ожиданий пользователей.
Объемы данных
Данная схема используется в основном для небольших объемов действий в реальном времени, из-за небольших значений времени ожидания и максимального размера запроса или ответа для решения вызова Apex. Не используйте эту схему в действиях пакетной обработки, в которых полезные данные содержатся в сообщении.
Поддержка конечной точки и стандартов
Возможности и поддержка стандартов для конечной точки зависят от выбранного решения.
| Решение | Рекомендации по конечной точке |
|---|---|
| Salesforce Connect | Odata API — используйте протокол открытых данных для доступа к данным, хранящимся вне системы Salesforce. Внешние данные должны быть открыты посредством производителей Odata. Другие API — используйте инфраструктуру коннекторов Apex для разработки собственного настраиваемого адаптера, если другие доступные адаптеры не подходят для ваших нужд. Настраиваемый адаптер может получать данные из любого источника. Например, некоторые данные можно извлечь из Интернета посредством выносок, в то время как другие данные можно манипулировать или даже создавать программным способом. Connect to Salesforce — использует Lightning Platform REST API для доступа к данным, хранящимся в других организациях Salesforce. Подключение посредством промежуточного программного обеспечения Connect via Middleware — Экосистема партнера Salesforce Connect тесно сотрудничала с Salesforce, чтобы их промежуточные шлюзы открывали конечные точки Odata из их службы, чтобы Salesforce мог с ними связываться без написания дополнительного кода. |
| Запрос и ответ | Выноски Apex SOAP - Конечная точка должна иметь возможность принимать вызов веб-службы посредством HTTP. Выноски HTTP Apex - Конечная точка должна иметь возможность принимать вызовы HTTP. Вы можете использовать выноски Apex HTTP для вызова служб RESTful посредством стандартных методов GET, POST, PUT и DELETE |
Управление штатом
При интеграции систем ключи важны для постоянного отслеживания состояния. Например, если запись создается в удаленной системе, обычно записи нужен некий идентификационный ключ для поддержки текущих обновлений. Существует два варианта хранения ключей.
- Salesforce сохраняет основной или уникальный ключ для удаленной записи.
- Удаленная система сохраняет уникальный код записи Salesforce или другой уникальный ключ. Ниже перечислены конкретные рекомендации по обработке ключей интеграции в синхронной схеме.
| Основная система | Описание |
|---|---|
| Salesforce | Удаленная система сохраняет либо код записи Salesforce, либо другой уникальный ключ из записи. |
| Удаленная система | Вызов удаленного процесса возвращает уникальный ключ из приложения, и Salesforce сохраняет это значение ключа в уникальном поле записи. |
Сложные интеграции
В некоторых случаях решение, предписанное этой схемой, может требовать реализации сложного сценария интеграции. Эти сценарии часто решаются посредством промежуточного программного обеспечения.
- Агрегация вызовов и их результатов в вызовах нескольких систем
- Трансформация как входящих, так и исходящих сообщений
- Поддержание целостности транзакций в вызовах нескольких систем
- Другие действия оркестрации процессов между Salesforce и внешней системой
Управляющие ограничения
Для разных адаптеров применяются разные ограничения. Дополнительные сведения см. в разделе Общие ограничения для Salesforce Connect.
Промежуточные возможности
Следующая таблица выделяет желательные свойства системы промежуточного программного обеспечения, участвующей в этой схеме.
| Свойство | Обязательно | Желательно | Не обязательно |
|---|---|---|---|
| Обработка событий | X | ||
| Преобразование протокола | X | ||
| Перевод и трансформация | X | ||
| Очередь и буферизация | X | ||
| Синхронные транспортные протоколы | X | ||
| Асинхронные транспортные протоколы | X | ||
| Маршрутизация посредника | X | ||
| Хореография процесса и оркестрация обслуживания | X | ||
| Транзакционность (шифрование, подписание, надежная доставка, управление транзакциями) | X | ||
| Маршрутизация | X | ||
| Извлечение, трансформация и загрузка | X | ||
| Длительный опрос | X |
Взаимосвязи внешних объектов
Внешние объекты поддерживают стандартные взаимосвязи поиска, использующие 18-значный код записи Salesforce для связывания связанных записей. Однако данные, хранящиеся вне организации Salesforce, часто не содержат этих кодов записей. Поэтому для внешних объектов доступны два специальных типа взаимосвязей поиска: внешние поиски и непрямые поиски.
Данная таблица содержит типы взаимосвязей, доступные внешним объектам.
| Взаимосвязь | Разрешенные дочерние объекты | Разрешенные родительские объекты | Родительское поле для сопоставления записей |
|---|---|---|---|
| Поиск | Стандартный, настраиваемый, внешний | Стандартный, настраиваемый | 18-значный код записи Salesforce |
| Внешний поиск | Стандартный, настраиваемый, внешний | Внешний | Стандартное поле «Внешний код» |
| Непрямой поиск | Внешний | Стандартный, настраиваемый | Выберите настраиваемое поле с атрибутами «Внешний код» и «Уникальное» |
Рекомендации по использованию большого объема данных для Salesforce Connect: адаптеры Odata 2.0 и 4.0
Если ваша организация достигает ограничений по частоте доступа к внешним объектам, выберите параметр «Большой объем данных» в связанных внешних источниках данных. При этом большинство ограничений пропускаются, но применяются некоторые особые алгоритмы и ограничения. Дополнительную информацию см. в разделе Рекомендации по использованию High Data Volume для Salesforce Connect
Пейджирование под управлением клиента и сервера для Salesforce Connect: адаптеры Odata 2.0 и 4.0
Обычно запросы Salesforce Connect внешних данных имеют большой набор результатов, разбитый на более мелкие пакеты или страницы. Вы решаете, каким поведением страницы управлять: внешней системой (серверной) или адаптером Odata 2.0 или 4.0 для Salesforce Connect (клиентской). Поле «Пагинация под управлением сервера» во внешнем источнике данных определяет необходимость использования страницы под управлением клиента или сервера. При включении серверного создания страниц для внешнего источника данных Salesforce игнорирует запрошенные размеры страниц, включая стандартный размер пакета queryMore() в 500 строк. Пакеты определяются страницами, возвращенными внешней системой, но каждая страница не может превышать 2000 строк. Однако ограничения для адаптеров Odata для Salesforce Connect действуют до сих пор.
Пример
Компания-производитель использует Salesforce для управления обращениями клиентов. Агенты службы поддержки хотят получить доступ к сведениям о заказе в реальном времени из резервной системы ERP, чтобы получить полное представление о клиенте без необходимости изучения и ручного запуска отчетов в ERP.
Внедряя решение, предписанное данной схемой, следует:
- Настройте внешний источник данных посредством конечной точки Odata. Удаленное приложение может содержать собственную поддержку Odata. В других приложениях основные поставщики интеграции, например, Dell Boomi, Informmatica, Jitterbit, MuleSoft и Progress Software, совместно с Salesforce в Salesforce Connect создали адаптеры.
- Укажите Salesforce Connect в конечной точке Odata либо напрямую, либо посредством промежуточного программного решения.
- Синхронизируйте таблицы внешней базы данных с внешними объектами в Salesforce. Когда пользователь открывает страницу с данными из этих внешних объектов, Salesforce Connect выполняет выноски в реальном времени в ваши фоновые приложения.
Документация разработчика
-
Справка Salesforce: Предоставление пользователям интеграции доступа только к API
-
Краткий справочник по ограничениям и назначениям разработчиков Salesforce
-
Руководство разработчика Apex: Salesforce Connect
Trailhead
Чтобы быть эффективными участниками корпоративного портфолио, все приложения должны быть созданы и интегрированы с соответствующими механизмами безопасности. Современные ИТ-стратегии используют сочетание локальных и облачных служб.
Хотя интеграция облачных служб обычно сосредоточена на веб-службах и связанной авторизации, подключение локальных и облачных служб часто создает дополнительные сложности. Данный раздел описывает инструменты безопасности, техники и рекомендации Salesforce.
Обратный прокси-сервер
Обратный прокси-сервер — это сервер, расположенный перед веб-серверами и пересылающий запросы клиентов (например, веб-обозреватель) на эти веб-серверы. Обратные прокси-серверы обычно внедряются для повышения безопасности, производительности и надежности.
Это тип прокси-сервера, который извлекает ресурсы от имени клиента с одного или нескольких серверов. Эти ресурсы потом возвращаются клиенту, как если бы они исходили из самого прокси-сервера. В отличие от прокси-сервера, который является посредником для связи связанных клиентов с любым сервером, обратный прокси-сервер является посредником для связи связанных серверов с любым клиентом.
В внедрениях Salesforce такая служба обычно предоставляется посредством продукта внешнего шлюза. Например, можно использовать варианты с открытым исходным кодом, например, Apache HTTP, lighttpd и nginix. Коммерческие продукты включают IBM WebSeal и Computer Associates SiteMinder. Эти продукты можно легко настроить для прокси-сервера и управления всеми исходящими запросами Salesforce от имени внутреннего запросчика.
Шифрование
Некоторые предприятия требуют шифрования выбранных транзакций или полей данных между комбинацией локальных и облачных приложений. Если ваша организация должна придерживаться дополнительных требований к соответствию, вы можете внедрить альтернативы, включительно с:
-
Локальные службы коммерческого шлюза шифрования, включая собственные Salesforce, CipherCloud, IBM DataPower, Computer Associates. В каждом решении механизм шифрования или шлюз вызывается на границе транзакции посредством отправки и получения зашифрованной полезной нагрузки или при шифровании или расшифровке определенных полей данных до выполнения запроса HTTP(S).
-
Облачные параметры, например, шифрование платформы Salesforce Shield. Shield Platform Encryption предоставляет вашим данным совершенно новый уровень безопасности, сохраняя при этом критически важные функции платформы. Выбранные данные шифруются в дежурном режиме посредством расширенной системы формирования ключей. Вы можете защитить данные более надежно, чем когда-либо прежде. Дополнительную информацию см. в онлайн-справке Salesforce.
Специализированная поддержка протокола WS-*
Чтобы выполнить требования протоколов безопасности (например, WS-*), рекомендуем следующие варианты.
-
Шлюз безопасности/XML: внедрите регистрационные данные WS-Security (IBM WebSeal или Datapower, уровень7, TIBCO и т. д.) в сам поток транзакций. Этот метод не требует изменений веб-служб на уровне приложения или вызовов веб-служб от Salesforce. Вы также можете повторно использовать этот метод в установке Salesforce. Однако, он требует дополнительного проектирования, конфигурации, тестирования и обслуживания для управления соответствующим внедрением WS-Security в существующий подход шлюза безопасности.
-
Шифрование на транспортном уровне: шифрование канала связи посредством ограничений двустороннего SSL и IP-адресов. Хотя этот метод не внедряет протокол WS-* напрямую сам по себе, он обеспечивает безопасность канала связи между локальными приложениями и Salesforce без передачи имени пользователя и пароля. Он также не требует изменений классов, созданных Salesforce. Однако могут потребоваться некоторые локальные изменения веб-служб (в самом приложении или на уровне промежуточного программного обеспечения/ЭСУ).
-
Настраиваемая разработка Salesforce: добавьте заголовки WS-Security к исходящему запросу SOAP посредством служебной программы WSDL2Apex. Таким образом создается класс Apex, подобный Java, из файла WSDL, используемого для вызова внутренней службы. Хотя этот подход не требует изменений в серверных веб-службах или дополнительных компонентах в ДЗ, он требует:
- повышенные усилия по сборке и тестированию
- относительно сложный и ручной процесс ручного кодирования атрибутов WS-Security (включая сериализацию XML в коде Apex)
- более высокие долгосрочные усилия по обслуживанию
Примечание: Последний вариант не рекомендуется из-за сложности и риска, что такие интеграции требуют периодических проверок на основе регулярных обновлений Salesforce.
Другие рекомендации по безопасности
-
Именованные регистрационные данные: Именованные регистрационные данные, предназначенные для защиты и упрощения проверенных выносок API во внешних системах, определяют URL-адрес конечной точки выноски и ее обязательные параметры проверки подлинности в одном определении. Чтобы упростить код Apex и настроить проверенные выноски, укажите именованные регистрационные данные в качестве конечной точки выноски. Дополнительные сведения см. здесь.
-
OAUTH 2.0: OAuth 2.0 — это стандартная отраслевая инфраструктура авторизации, позволяющая пользователям предоставлять ограниченный доступ к защищенным ресурсам стороннему приложению без предоставления общего доступа к регистрационным данным (например, пароли). Вместо прямого обмена паролями пользователь утверждает запрос маркера доступа, который потом используется приложением для доступа к данным пользователя с сервера ресурсов. Этот процесс отделяет клиентское приложение от удостоверения пользователя и пароля, повышая безопасность, предоставляя временный «ключ» для доступа к ресурсам. Дополнительную информацию см. здесь.
-
Private Connect: При интеграции организации Salesforce с приложениями, размещенными в сторонних облачных службах, важно иметь возможность безопасной отправки и получения трафика HTTP/s. С помощью Private Connect повысьте безопасность интеграций Amazon Web Services (AWS), настроив полностью управляемое сетевое подключение между организацией Salesforce и виртуальным частным облаком AWS (VPC). Потом перенаправьте кросс-облачный трафик через подключение, а не через общедоступный интернет, чтобы уменьшить подверженность внешним угрозам безопасности. Private Connect доступен в партнерстве с AWS посредством функции AWS PrivateLink. Private Connect является двусторонним: можно инициировать как входящий, так и исходящий трафик. С помощью входящих подключений можно отправлять трафик в Salesforce посредством стандартных API. А с помощью исходящих подключений можно отправлять трафик из Salesforce посредством таких функций, как выноски Apex, внешние службы и внешние объекты. Дополнительную информацию о VPC см. здесь.
Шина событий Salesforce с событиями платформы, сбором данных об изменении (CDC) и Public /Sub API позволяет предприятиям создавать архитектуры стиля, управляемого событиями (EDA).
EDA отделяет потребителей сообщений о событиях (подписчиков) от производителей сообщений о событиях (публикаторов), обеспечивая большую масштабность и гибкость. Конкретные схемы рассматриваются в настоящем документе как часть существующей структуры схемы, которая сравнивает и сопоставляет связанные альтернативы или варианты. Однако, получение целостного понимания архитектуры, управляемой событиями, и способа взаимодействия схем может помочь вам выбрать подходящую схему для ваших нужд.
Халид Мохаммед является выдающимся архитектором в профессиональных службах Salesforce. С момента прихода в Salesforce в 2015 году он использовал свой обширный опыт в области Enterprise Application and Architecture, отточенный в многочисленных трансформациях клиентов до работы в Salesforce. Халид возглавляет Совет по архитектуре доставки, а также признан сертифицированным техническим архитектором.
Гуляль Кумар является архитектором программного обеспечения в Salesforce, специализируется на архитектуре данных и интеграции. Имея более 20 лет опыта в интеграции и API, программах модернизации, безопасности и инициативах AIML, он предоставляет богатый опыт. Гуляль привержен продвижению инициатив по трансформации бизнеса, повышению безопасности и устойчивости, содействию совершенству архитектуры и руководству инициативами AIML в различных областях.
Сушант является техническим архитектором в Salesforce, специализируется на архитектуре решений и комплексной поставке платформ Salesforce. Имея глубокий опыт в управлении платформами, разработке приложений, интеграции и DevOps, он руководил многочисленными программами трансформации клиентов в разных отраслях. Sushant стремится стимулировать качество доставки и масштабируемые архитектурные результаты.