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

• Схемы интеграции, представляющие распространенные корпоративные «архетипы» в процессах, данных и сценариях виртуального доступа
• Инфраструктура выбора схемы, помогающая определить правильный подход на основе намерения интеграции и сроков выполнения
• Практическое руководство по масштабируемости, устойчивости, управлению и соображениям безопасности
• Рекомендации, заимствованные из реальных внедрений Salesforce и Data 360 Цель этого документа - предоставить общий архитектурный язык для интеграции, помогая группам разрабатывать решения, которые балансируют между производительностью, гибкостью и Trust, согласовывая со стратегиями корпоративных данных и управления.

Данный документ предназначен для конструкторов и архитекторов, которым требуется интеграция данных из других приложений на предприятии с Salesforce Data 360 (ранее Data Cloud). Это содержимое представляет собой перегонку многих успешных внедрений архитекторов и партнеров Salesforce. Чтобы ознакомиться с возможностями интеграции и параметрами, доступными для широкомасштабного внедрения Data 360, ознакомьтесь с разделами «Сводка схемы» и «Руководство по выбору схемы» ниже. Архитекторы и разработчики должны учитывать эти сведения о схеме и рекомендации на этапе разработки и внедрения проектов взаимодействия данных в Data 360. При правильном внедрении эти схемы позволяют как можно быстрее добраться до производства и получить максимально стабильный, масштабируемый и необслуживаемый набор приложений. Собственные архитекторы-консультанты Salesforce используют эти схемы в качестве отправных точек во время архитектурных экспертиз и активно их поддерживают и улучшают. Как и во всех схемах, это содержимое охватывает большинство сценариев интеграции, но не все. Хотя Salesforce разрешает интеграцию пользовательского интерфейса (пользовательского интерфейса), например, сопоставления, такая интеграция выходит за рамки данного документа.

Каждая схема интеграции соответствует последовательной структуре. Это обеспечивает согласованность информации, предоставляемой в каждой схеме, а также упрощает сравнение схем.

• Имя: Идентификатор схемы, который также обозначает тип интеграции, содержащийся в схеме.
• Контекст: Общий сценарий интеграции, рассматриваемый схемой. Контекст предоставляет сведения о том, чего пытаются достичь пользователи и как приложение поддерживает требования.
• Проблема: Выраженный как вопрос, этот сценарий создан для решения схемы. Прочитайте этот раздел, чтобы понять, подходит ли схема для вашего сценария интеграции.
• Силы: Ограничения и обстоятельства, затрудняющие решение указанного сценария.
• Решение: Рекомендуемый способ решения сценария интеграции.
• Рис.: Диаграмма последовательности UML, отображающая способ обработки сценария решением.
• Результаты: Объясняет сведения о том, как применить решение к сценарию интеграции и как он разрешает силы, связанные с этим сценарием. Данный раздел также содержит новые проблемы, которые могут возникнуть в результате применения схемы.
• Боковые панели: Дополнительные разделы, связанные со схемой, содержащие ключевые технические проблемы, варианты схемы, характерные проблемы схемы и т. д.
• Пример: Реальный сценарий, описывающий способ использования схемы проектирования в реальном сценарии Salesforce. В примере объясняются цели интеграции и способ внедрения схемы для достижения этих целей.

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

Схемы интеграции в этом документе разделены на три категории: данные, процессы и визуальные интеграции.

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

• Схемы пакетного принятия представляют собой базовый уровень адаптации корпоративных данных. Пакетный прием данных из облачных служб хранилища, например, AWS S3, Azure Blob или Google Cloud Storage, позволяет периодически загружать большие архивные наборы данных в Data 360 для разрешающей способности при опознавании, сегментации и аналитики. Таким же образом, пакетный прием из Salesforce Cloud, например, Sales, Service или Marketing Cloud, использует собственные коннекторы и потоки данных для переноса данных CRM в объединенный слой данных, обеспечивая гармонизацию и непрерывность в системах занятости.
• Потоковые потоки и схемы принятия в реальном времени расширяют их, собирая данные о быстром событии. Прием под управлением событий посредством API принятия позволяет внешним системам постоянно передавать активность клиентов в Data 360. Прием веб- и мобильного алгоритма в реальном времени собирает кликстрим и данные взаимодействия напрямую из цифровых точек касания для стимулирования немедленной персонализации. Синхронизация CRM в близком к реальному режиме времени посредством Streaming API обеспечивает быстрое отображение атрибутов клиентов и обновлений согласия в системах. Прием потока событий из платформ службы сообщений, например, Amazon Kinesis или Confluent MSK, поддерживает непрерывные высокопроизводительные ожидаемые продажи, выравнивая Data 360 с архитектурой событий предприятия.
• Объединенная многоорганизационная платформа данных с Data Cloud One является еще одним примером интеграции данных, обеспечивая объединенную среду для объединения данных из нескольких организаций Salesforce и внешних источников под общим управлением и семантическим слоем. Это позволяет организациям достигать согласованности данных в масштабах предприятия, общедоступных моделей данных и масштабируемой аналитики.
• На этапе активации схемы пакетной активации придерживаются того же принципа интеграции данных. Сегменты, созданные в Data 360, экспортируются в запланированных заданиях на последующие маркетинговые и рекламные платформы (например, Marketing Cloud, Meta Ads или Google Ads), где они инициируют выполнение кампании. Таким же образом, наборы данных можно экспортировать в цели облачного хранилища для подпитки внешней аналитики и конвейеров науки о данных. Во всех этих случаях использования Data 360 выступает в качестве источника истины для синхронизированных и проверенных данных клиентов.

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

• Активация на основе API по запросу включает сценарии занятости в реальном времени. С помощью Connect API настраиваемые приложения могут запрашивать или активировать профили клиентов напрямую из Data 360 как часть операционных процессов, например, консоль агента извлекает объединенные важные данные профиля во время взаимодействия с клиентом. Завершение извлечения профиля клиента посредством Data Graph API поддерживает составные приложения и микросервисы, зависящие от API-доступа к полному графику объекта клиента, позволяя динамические взаимодействия без предварительно поэтапных сегментов.
• Действия над данными в реальном времени способствуют дальнейшему продвижению этого подхода интеграции, включая немедленное реагирование. При обнаружении сигнала клиента (например, покупка, отправка формы или событие порога) Data 360 может инициировать действия (например, обновление записи CRM, вызов внешнего webhook или запуск персонализированного бизнес-правила предложения). Эти схемы воплощают истинную оркестрацию процессов, соединяя Аналитику клиентов в реальном времени с автоматическим операционным выполнением.

Шаблоны виртуальной интеграции в Data 360 предоставляют оперативный доступ к внешним или интегрированным источникам данных без физического копирования или дублирования данных. Они важны для предприятий, которым требуется управляемая, актуальная информация во время запроса при минимизации перемещения данных.

• Inbound Zero Copy Data Federation(External Platforms-to-Data 360) позволяет внешним системам (например, хранилищам данных или озерам данных) предоставлять общий доступ к наборам данных Data 360 посредством безопасных управляемых подключений (например, безопасный общий доступ к данным Snowflake). Это обеспечивает виртуальный доступ к внешним данным и работу с ними, сохраняя свежесть и исключая ненужную репликацию.
• Общий доступ к исходящим нулевым копиям данных (Data 360- to External Platforms) позволяет Data 360 открывать рекомендованные наборы данных для внешнего потребления, например, моделирование на основе искусственного интеллекта, бизнес-аналитика или расширенная аналитика, посредством безопасных механизмов интегрирования данных и оперативных запросов. Выбор оптимальной стратегии интеграции для системы не является простым делом. Существует много аспектов для рассмотрения и много инструментов, которые можно использовать, при этом некоторые инструменты более подходят для определенных задач, чем другие. Каждая схема учитывает определенные критические области, включая возможности каждой из систем, объем данных, обработку сбоев и транзакционность.

При выборе схемы интеграции начните с ответа на два фундаментальных вопроса, которые определяют общий дизайн и алгоритм интеграции. Что вы интегрируете? — Процесс, данные или виртуальный доступ Это измерение определяет основную цель интеграции.

• Интеграция процессов сосредоточена на организации бизнес-правил и координации действий в рамках всех систем.
• Интеграции данных сосредоточены на синхронизации, пополнении или распространении данных между системами.
• Виртуальные интеграции фокусируются на доступе к внешним данным в режиме реального времени без их копирования или сохранения в Salesforce или Data 360. Понимание этого намерения помогает определить уровень оркестрации, перемещения данных и связи, требуемый между системами.
• Как его нужно выполнить? — Синхронный или асинхронный метод определяет модель выполнения интеграции.
• Синхронные интеграции выполняются в режиме реального времени и блокируются, когда абонент ожидает немедленного ответа, обычно используемого для сценариев проверки или проверки подлинности пользователя.
• Асинхронные интеграции не блокируются и отделяются, предназначены для обработки масштаба, длительных процессов, попыток и больших объемов данных. В совокупности эти два аспекта - намерение интеграции и сроки выполнения - обеспечивают четкую и последовательную основу для выбора правильной схемы интеграции при обеспечении баланса между опытом пользователей, масштабируемостью и оперативной устойчивостью. Примечание: Интеграция может требовать внешнего промежуточного программного обеспечения или решения интеграции (например, Enterprise Service Bus), в зависимости от того, какие аспекты применяются к вашему сценарию интеграции.

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

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

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

Прием данных является первым и самым важным этапом жизненного цикла данных Salesforce Data 360. Таким образом, исходная информация из нескольких внешних систем (CRM, ERP, web, Mobile или сторонние API) попадает на платформу и становится частью объединенного представления клиента. Правильная схема приема зависит от того, что нужно бизнесу:

• Объем данных: сколько данных перемещается одновременно
• Задержка: насколько свежими должны быть данные
• Возможности исходной системы — способы подключения и доставки данных системой Data 360 поддерживает несколько режимов приема в соответствии с этими потребностями: пакетный для массовых загрузок, потоковый для обновлений в близком к реальному режиме времени, основанный на событиях для транзакционной немедленности и прием Zero Copy для мгновенного доступа к внешним данным без их физического перемещения. Вместе эти схемы обеспечивают эффективный, безопасный и своевременный поток каждого сигнала клиента, будь то событие покупки, журнал кликстрима или обновление лояльности, в Data 360 для поддержки надежной аналитики и взаимодействий на основе искусственного интеллекта.

Схемы пакетного приема являются основой крупномасштабной адаптации данных в Data 360. Они оптимизированы для сценариев, когда данные обрабатываются в пакете, обычно на запланированной или периодической основе, а не непрерывно. Данные схемы лучше всего подходят для:

• Загрузка архивных данных для инициализации платформы с существующими записями предприятия
• Регулярная синхронизация с такими системами записи, как ОПР, хранилища данных или собственные базы данных
• Использовать случаи, когда свежесть в реальном времени не является критической, но согласованность, полнота и проверяемость Пакетный прием обеспечивает предсказуемую производительность и операционную простоту, что делает его надежным выбором для предприятий, управляющих терабайтами структурированных или полуструктурированных данных. Data 360 предоставляет набор готовых к производству общедоступных коннекторов, поддерживающих пакетный прием собственными силами. Эти коннекторы упрощают настройку интеграции, уменьшают настраиваемую разработку ETL и обеспечивают качество и безопасность данных во время каждого импорта. В таблице ниже выделены наиболее распространенные коннекторы, используемые для пакетного приема в масштабах предприятия.

Контекст

Эта схема создана для корпоративных сценариев, связанных с приемом больших объемов структурированных данных, например, CSV-файлов или файлов паркета, а также неструктурированных активов из централизованных озер данных или запланированных перемещений файлов. Источниками данных обычно являются платформы облачного хранилища, например, Amazon S3, Google Cloud Storage (GCS) и Microsoft Azure Blob Storage, куда файлы периодически доставляются как часть первичных ожидаемых продаж данных или пакетного экспорта.

Проблема

Как организация может создать надежный, безопасный и высокопроизводительный процесс для приема массивных наборов данных на основе файлов из основной облачной платформы хранилища в Data 360 по предсказуемому, повторяющемуся расписанию, не жертвуя управлением, масштабируемостью или производительностью?

Силы

Интеграция массивных наборов данных на основе файлов в Data 360 — это не простое мероприятие передачи данных, это архитектурная задача, формируемая ограничениями масштаба, управления и платформы.

Объем и масштаб данных: Коннекторы приема Data 360 оптимизированы для надежности и управления, а не для произвольной пакетной производительности. Например, коннектор Amazon S3 поддерживает до 100 миллионов строк или 50 ГБ на объект, в зависимости от того, какое ограничение будет достигнуто раньше. Для предприятий с архивными наборами данных, содержащими миллиарды записей, эта граница становится ключевым ограничением проектирования. Метод подъема и смены одного файла быстро становится невозможным, что требует интеллектуальных стратегий разделения данных, фрагментации и оркестрации для достижения масштаба без ограничения коннекторов.

Определение и обслуживание схемы: Data 360 требует четких определений схемы для каждого ожидаемого приема, чтобы обеспечить семантические и структурные целостности. В случае принятия S3 CSV-файл должен определить заголовки столбцов и одну типичную строку данных. Этот файл действует как канонический контракт между исходной системой, т.е. облачным хранилищем и Data 360. Любое несоответствие — в именах полей, типах данных или кодировке — может привести к ошибкам принятия или повреждению скрытых данных. Сохранение этого файла схемы в управлении версиями и принудительная проверка посредством бизнес-процессов CI/CD или управления данными становится рекомендацией для производственных сред.

Конвенции о строгом наименовании: Data 360 применяет строгие правила наименования объектов и полей для обеспечения последовательности в графике метаданных.

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

Позиция проверки подлинности и безопасности: Каждое подключение к внешнему хранилищу должно соответствовать стандартам безопасности и соответствия предприятия.

• Проверка подлинности обычно выполняется посредством AWS Access/Секретные ключи или проверки подлинности интегрированного поставщика удостоверений (IdP).
• Роли IAM должны быть ограничены для применения наименьших привилегий, разрешая только доступ чтения к указанным путям хранилища.
• Для безопасного доступа исходящие IP-адреса должны быть напрямую добавлены в список разрешенных исходной системы. Эти многоуровневые элементы управления обеспечивают работу каждой передачи файлов в пределах контролируемого периметра zero Trust, балансируя между соответствием предприятия и гибкостью, необходимой для широкомасштабного приема.

Решение

Данная таблица содержит решения данной проблемы интеграции.

Эскиз

Эта диаграмма иллюстрирует последовательность этапов приема данных из облачного хранилища в Data 360

В этом сценарии:

• Администратор настраивает подключение к облачному хранилищу посредством интерфейса настройки Data 360 (указывая проверку подлинности, сведения о области, роли IAM и белый список).
• Интерфейс настройки Data Cloud проверяет подлинность посредством платформы облачного хранилища, проверяя регистрационные данные и доступ.
• Администратор создает поток данных в Data 360, связывая поток данных с объектом/папкой в облачном хранилище и определяя расписание приема.
• В триггере расписания поток данных запрашивает исходные файлы (например, CSV, паркет) из платформы облачного хранилища.
• Платформа облачного хранилища предоставляет файлы, включая обязательные действительные файлы schema_sample.csv и другие файлы данных, соответствующие правилам наименования.
• Поток данных передает файлы во внутреннюю среду этапирования в Data 360.
• Конвейеры Data 360 обрабатывают файлы: Использует определение схемы из schema_sample.csv Проверяет структуру, имена полей и разделяет нагрузку, если выше пороговые значения приема (100 миллионов строк/50 ГБ на файл). При обнаружении больших файлов выполняется этап разделения предварительной обработки (уведомление администратора для следующего выполнения).
• Записи импортируются из этапирования в объект озера данных (DLO).
• При необходимости и разделении данных используйте узел append в пакетной трансформации данных для объединения нескольких ООД.
• Data 360 регистрирует успех/сбой, обновляет статус для мониторинга и сигнализирует о готовности данных к соотнесению, гармонизации и объединению.

Результаты

Применение этой схемы обеспечивает безопасный, запланированный и широкомасштабный прием структурированных или неструктурированных файлов из корпоративных платформ облачного хранилища в Data 360. Процесс автоматизированный, масштабируемый и устойчивый — доставка исходных данных в объекты озера данных (DLO), которые служат основой для гармонизации и соотнесения с моделью данных Customer 360.

Механизмы принятия

Механизм приема зависит от коннектора и стратегии планирования, определенных в Data 360.

Обработка и восстановление ошибок

Обработка и восстановление ошибок имеют решающее значение для обеспечения надежности операций массового приема.

• Обнаружение ошибок: Каждый запуск потока данных регистрирует ошибки принятия (например, несоответствие схемы, повреждение файла или нарушения наименования) в мониторинге данных 360. Администраторы могут просматривать и повторно обрабатывать неудачные пакеты.
• Механизм восстановления: Data 360 поддерживает контрольную точку, чтобы предотвратить повреждение предыдущих приемов. Повторы можно настроить после исправления исходных проблем (например, неправильно сформированные CSV-файлы).
• Проверка схемы: Файл schema_sample.csv определяет типы и структуру данных. Любое изменение инициирует проверку, чтобы избежать скрытого отклонения схемы при выполнении.

Рекомендации по созданию эффективных решений

Прием осуществляется безупречно — повторная обработка одного файла не приводит к повторам записей. Ключевые стратегии включают:

• Дактилоскопия файла: Data 360 вычисляет контрольные суммы для идентификации и пропуска ранее обработанных файлов.
• Транзакционный прием: Данные поэтапны и передаются в ООД только после успешной обработки всех записей.
• Добавить по сравнению с Заменить: В зависимости от бизнес-логики, потоки могут дополнять или полностью заменять целевой ООД; это обеспечивает детерминистские результаты и предотвращает частичное наложение данных.

Рекомендации по безопасности

Безопасность является неотъемлемой частью процесса принятия, от проверки подлинности до шифрования и контроля доступа.

• Проверка подлинности и авторизация: Коннекторы используют инфраструктуру безопасной интеграции Salesforce, используя именованные регистрационные данные и внешние регистрационные данные для проверки подлинности без открытия секретов.
• Шифрование: Данные шифруются в пути (TLS 1.2+) и в дежурном режиме (AES-256).
• Элементы управления сетью: Исходные системы хранения (например, сегменты S3) должны содержать список разрешенных IP-адресов Data 360.
• Выравнивание соответствия: Поддерживает корпоративные инфраструктуры защиты данных, например, GDPR, HIPAA и рекомендации FFIEC, в сочетании с ключами под управлением клиента (CMK).
• Проверяемость: Каждое задание приема и доступ к регистрационным данным регистрируются для отслеживания и составления отчетов о соответствии.

Боковые панели

Своевременность

Своевременность зависит от расписания приема и объема данных.

• Крупные корпоративные наборы данных (строки 100M+) могут требовать разделения для параллельного приема.
• Типичная задержка приема составляет от минут до нескольких часов, в зависимости от размера файла и сложности трансформации.
• Для принятия в близком к реальному режиме времени потоковые коннекторы Data 360 или коннекторы на основе API могут дополнять файловую модель.

Объемы данных

• Лучше всего подходит для массового периодического пакетного приема.
• Каждый объект, обработанный посредством коннектора S3, поддерживает до 100 миллионов строк или 50 ГБ на файл.
• В системах петабайтного масштаба используйте разделение данных и многопотоковую оркестрацию.

Возможность конечной точки и поддержка стандартов

Возможности и стандартная поддержка конечной точки зависят от выбранного решения.

Управление государством

Состояние отслеживается посредством потоков данных и отметки времени последнего успешного выполнения.

• Data 360 автоматически поддерживает состояния синхронизации и смещения, обеспечивая обработку только новых или измененных файлов при последующих запусках.
• При интеграции с внешними инструментами ETL рекомендуется использовать уникальные идентификаторы файлов (например, UUID или временные отметки) во избежание дублирования.

Сложные сценарии интеграции

В расширенных корпоративных архитектурах эта схема может интегрироваться с:

• Промежуточные конвейеры ETL (например, Informmatica, MuleSoft): для организации предварительной обработки, проверки и разделения файлов перед передачей в Data 360.
• Бизнес-процессы искусственного интеллекта/ML: обработанные данные DLO могут быть опубликованы посредством DMO для моделирования учебных сред или индексов RAG посредством целей активации Data 360.
• Транзакционные системы: гармонизированные DMO могут инициировать последующие обновления в Salesforce CRM или внешних системах посредством действий над данными или событий платформы.

Пример

Глобальное финансовое учреждение хранит данные клиентов и транзакций в озере данных AWS S3, где разделенные файлы паркета создаются еженедельно по регионам (например, США, ЕС и APAC). Группа, работающая с архитектурой данных, настраивает несколько потоков данных в Data 360, каждый из которых подключен к региональной папке, с общим schema_sample.csv, обеспечивающим согласованные заголовки и типы данных во всех разделах. Ночные расписания приема автоматически загружают данные в DLO, после чего пакетные трансформации данных добавляют все региональные разделы в объединенный Customer_Transactions_DLO. Этот гармонизированный набор данных потом соотносится с моделью данных Customer 360, включая аналитику в нисходящем направлении и активацию искусственного интеллекта. Этот метод обеспечивает автоматический и надежный прием из существующего озера данных, внедряет надежную проверку подлинности и шифрование в соответствии с корпоративными ИТ-политиками и обеспечивает масштабируемую модульную основу, поддерживающую будущее расширение и развитие схемы.

Контекст

Основным и критическим способом использования Data 360 является объединение данных клиентов в экосистеме Salesforce. Эта схема охватывает нативный прием данных из базовых платформ Salesforce — Sales Cloud и Service Cloud (вместе Salesforce CRM) и Marketing Cloud Engagement. Источники включают стандартные и настраиваемые объекты CRM (например, организация, контакт, обращение, возможность) и расширения данных Marketing Cloud Engagement, содержащие события занятости, отправки электронной почты и отслеживание данных.

Проблема

Как организация может эффективно и надежно принимать стандартные и настраиваемые объекты CRM и расширения данных Marketing Cloud Engagement в Data 360, чтобы данные можно было использовать для создания объединенных профилей клиентов (разрешение при опознавании, Customer 360), сохраняя производительность, управление и минимальные сбои в исходных системах?

Силы

Собственные коннекторы упрощают работу, но необходимо управлять несколькими операционными и архитектурными силами:

• Комплексные исходные полномочия: Выделенный подключаемый пользователь (организация интеграции) должен иметь соответствующие полномочия на чтение объекта и поля. Неназначение обязательных наборов полномочий (например, готовый набор полномочий коннектора Data 360) является распространенной причиной сбоя приема.
• Режимы и стоимость обновления данных: Коннекторы поддерживают режимы полного и дельта/инкрементного обновления. Полные обновления более тяжелы для производительности и кредитов; извлечения дельты уменьшают нагрузку, но зависят от надежного отслеживания изменений в исходной системе.
• Соотнесение настраиваемых схем и полей: Экземпляры CRM часто содержат настраиваемые объекты/поля. Точное соотнесение схем и обработка настраиваемых полей (имена, типы) обязательны во избежание ошибок соотнесения или семантического отклонения.
• Начальные пакеты данных по сравнению с Настраиваемое соотнесение: Начальные пакеты данных ускоряют адаптацию, предварительно выбрав типичные объекты/поля, но сильно настроенным организациям потребуются готовые определения потока.
• Ограничения по производительности и API: Ограничения API исходной организации и частота извлечения Marketing Cloud ограничивают возможность активного планирования обновлений.
• Условия гигиены данных и наименования: Имена исходных полей, алгоритм null и типы данных должны быть нормализированы перед принятием, чтобы предотвратить проблемы соотнесения в нисходящем направлении.
• Безопасность и наименьшие права: Коннектор зависит от безопасной проверки подлинности и должен учитывать схемы IAM с наименьшими правами, возможность аудита и элементы управления сетью.

Решение

Данная таблица содержит решения данной проблемы интеграции.

Эскиз

Эта диаграмма иллюстрирует последовательность этапов приема данных из облачного хранилища в Data 360

В этом сценарии:

• Администратор инициализирует пользователей интеграции и назначает наборы полномочий коннектора в исходной организации (организациях).
• Администратор настраивает коннекторы в настройках Data 360 (подключается к Salesforce CRM и Marketing Cloud посредством OAuth/ связанного приложения).
• Администратор создает потоки данных, выбирая объекты и расширения данных, выбирает полное или дельта-обновление и устанавливает расписания.
• При запланированном выполнении Data 360 запрашивает схему и дельта-маркеры у источника (источников).
• Исходные системы возвращают записи (дельта или полная полезная нагрузка). Marketing Cloud может предоставлять извлечения; CRM может возвращать результаты JSON/Query.
• Data 360 этапирует файлы во внутренней безопасной области этапирования и проверяет их по соотнесенной схеме.
• Если проверка не удается, прием регистрирует ошибку, предупреждает администратора и прекращает обязательство. Если проверка успешна, Data 360 атомарно подтверждает записи в целевом ООД.
• Журналы мониторинга и аудита обновляются посредством строки, продолжительности выполнения, количества строк и использования регистрационных данных. Предупреждения, отправляемые администраторам при срабатывании порогов или ошибок.

Результаты

Базовые данные взаимосвязей с клиентами и занятости маркетинга принимаются в Data 360 как объекты озера данных (DLO). Данное действие возвращает:

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

Механизмы принятия

Механизм приема зависит от коннектора и стратегии планирования, определенных в Data 360.

Обработка и восстановление ошибок

Обработка и восстановление ошибок имеют решающее значение для обеспечения надежности операций массового приема.

• Журналы выполнения: Каждый запуск потока данных предоставляет сведения об успехе/сбое и ошибки на уровне строки.
• Повторные попытки и контрольная точка: Ошибочные запуски могут быть повторены после исправления проблем источника или схемы; Data 360 использует семантику этапирования и атомного подтверждения.
• Предупреждения: Настройте предупреждения для отклонения схемы, повторных сбоев или пробелов в дельта-последовательности.

Рекомендации по созданию эффективных решений

Прием идемпотентный по замыслу — повторная обработка его не приводит к повторам записей. Ключевые стратегии включают:

• Обнаружение изменений: Дельта-извлечения зависят от индикаторов изменения исходной системы (LastModifiedDate / сбор данных об изменении системы). Проверьте источник на наличие надежных отметок времени/флажков.
• Дублирование: Используйте уникальные бизнес-ключи (например, Contact.ExternalId) для обмана или обновления вставки в DLO.
• Транзакционное обязательство: Записи этапируются и фиксируются только после успешного завершения пакетной обработки.

Рекомендации по безопасности

Безопасность является неотъемлемой частью процесса принятия, от проверки подлинности до шифрования и контроля доступа.

• Проверка подлинности и авторизация: Коннекторы используют инфраструктуру безопасной интеграции Salesforce, используя именованные регистрационные данные и внешние регистрационные данные для проверки подлинности без открытия секретов.
• Шифрование: Данные шифруются в пути (TLS 1.2+) и в дежурном режиме (AES-256).
• Элементы управления сетью: Исходные системы хранения (например, сегменты S3) должны содержать список разрешенных IP-адресов Data 360.
• Выравнивание соответствия: Поддерживает корпоративные инфраструктуры защиты данных, например, GDPR, HIPAA и рекомендации FFIEC, в сочетании с ключами под управлением клиента (CMK).
• Проверяемость: Каждое задание приема и доступ к регистрационным данным регистрируются для отслеживания и составления отчетов о соответствии

Боковые панели

Своевременность

Своевременность зависит от расписания приема и объема данных.

• Идеальная каденция зависит от бизнес-потребностей — ежечасно для триггеров маркетинга в близком к реальному режиме времени, еженедельно для крупных сверок.
• Дельта-режимы уменьшают нагрузку и стоимость; полные обновления более интенсивны и используются для первичных загрузок или серьезных изменений схемы.

Объемы данных

• Коннекторы CRM оптимизированы для транзакционных и средних наборов данных (миллионы записей).
• Для получения экстремально больших архивных объемов рекомендуем использовать поэтапный ETL для поэтапного разделения и загрузки.

Возможность конечной точки и поддержка стандартов

Возможности и стандартная поддержка конечной точки зависят от выбранного решения.

Управление государством

• Состояние коннектора: Потоки данных сохраняют последние успешные отметки времени синхронизации и дельта-смещения.
• Стратегия основного ключа: Отдайте предпочтение последовательным бизнес-идентификаторам (внешним кодам), чтобы последующая сверка и обновления были детерминистскими.

Сложные сценарии интеграции

В расширенных корпоративных архитектурах эта схема может интегрироваться с:

• Гибридные топологии: Сочетайте прием CRM с потоковыми (события платформы) для обновлений в близком к реальному режиме времени.
• Промежуточная оркестрация: Используйте MuleSoft или инструменты ETL, когда требуется сложная оркестрация, обогащение или предварительный прием трансформации.
• Циклы отзывов об активации: Гармонизированные DMO могут инициировать обновления исходных систем в нисходящем направлении посредством действий над данными или API платформы (осторожно с элементами управления SoD).

Пример

Многонациональный ритейлер объединяет показатели занятости организаций, контактов, обращений, возможностей и Marketing Cloud в Data 360 для создания объединенного представления клиента. Начальный пакет данных инициализирует базовые объекты продаж и обслуживания, в то время как рабочая группа расширяет модель настраиваемыми полями, например, Loyalty_Membershipc и Customer_Tierc для сбора контекста лояльности. Потоки данных CRM выполняются ежечасно в режиме дельты, и Marketing Cloud Engagement синхронизируется ежедневно посредством извлечений дельты для событий занятости. Эти наборы данных обрабатываются посредством ООД и разрешающей способности при опознавании, что приводит к объединенному профилю клиента, сочетающему сигналы CRM и занятости для питания моделей персонализации и последующего искусственного интеллекта.

Эти схемы созданы для сценариев, где миллисекунды важны — когда взаимодействия с клиентами, транзакции или сигналы должны инициировать немедленные важные данные или действия. Они выходят за рамки традиционного запланированного пакетного приема и включают поток данных под управлением событий, где информация обрабатывается в момент создания. В экосистеме Salesforce Data 360 «в реальном времени» — это не отдельный режим, это непрерывный набор моделей задержки. На одном конце находится синхронизация почти в режиме реального времени, когда обновления из систем записи (например, CRM или ERP) отображаются в Data 360 в течение нескольких секунд или минут. С другой стороны, это настоящий сбор событий в реальном времени, когда клиентские поведенческие сигналы (например, щелчки, покупки или мобильные взаимодействия) принимаются и активируются за миллисекунды. Для архитекторов различие является более чем смысловым. Он определяет, как создаются ожидаемые продажи, как вызываются API и как принимаются решения на последующих этапах. Выбор правильной схемы — синхронизации в близком к реальному режиме времени или принятия потоковых событий — обеспечивает соответствие системы целям операционной задержки предприятия, сохраняя целостность данных, масштабируемость и управление.

Контекст

Данная схема позволяет любой внешней системе (например, настраиваемому приложению, платформе Интернета вещей (IoT), системе точек продаж (POS) или сторонней службе) программным способом переносить данные событий в Data 360 в режиме, близком к реальному, по мере наступления отдельных событий.

Проблема

Как разработчик может надежно отправлять отдельные записи или небольшие асинхронные пакеты событий из внешнего приложения в Data 360 с низкой задержкой, чтобы данные были быстро доступны для обработки, сегментации и активации?

Силы

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

• Зависимость разработчика: Требует усилий разработчика для внедрения проверенных клиентов REST API и логики ошибки/повтора попытки — это не интерактивный коннектор.
• Строгая схема записи: API принятия применяет схему при записи. Точная схема должна быть определена и загружена в конфигурацию коннектора; все полезные данные должны точно соответствовать или быть отклонены.
• Режимы двойного взаимодействия: Один и тот же коннектор поддерживает потоковую передачу (JSON) для обновлений с низкой задержкой по записи и пакетную (CSV) для больших периодических синхронизаций — архитекторы должны выбрать каждый сценарий использования.
• Проверка подлинности и безопасность: Вызовы должны быть проверены посредством связанного приложения Salesforce посредством OAuth 2.0 (например, JWT Bearer Flow для сервера). Управление маркерами, ротация и ограничения наименьших прав обязательны.
• Оперативная доступность: Разработчики и рабочие группы платформы должны внедрить мониторинг кодов ответов, повторов, очередей мертвых букв и предупреждений о сбое схемы.
• Требование к графику в реальном времени: Для истинной мгновенной активации (мгновенная сегментация, соотнесение DMO в реальном времени) целевой объект модели данных (DMO) должен быть частью графика данных в реальном времени; в противном случае события пересекают несколько более высокие ожидаемые продажи.

Решение

Данная таблица содержит решения данной проблемы интеграции.

Эскиз

Эта диаграмма иллюстрирует последовательность этапов приема данных из API принятия в Data 360

В этом сценарии:

• Внешняя система запрашивает проверку подлинности посредством OAuth/JWT с сервера проверки подлинности.
• Сервер проверки подлинности возвращает маркер доступа к внешней системе.
• Внешняя система отправляет запрос POST принятия данных в Data 360 Ingestion API с авторизацией и полезной нагрузкой JSON.
• API принятия проверяет схему запроса и проверку подлинности посредством модуля этапирования и проверки.
• При сбое схемы/проверки подлинности:
• Ошибка, возвращенная во внешнюю систему.
• Отклонение зарегистрировано для мониторинга и оповещения.
• При успешной проверке:
• Записи этапированы и подтверждены в объект озера данных (DLO).
• Успех зарегистрирован для мониторинга.
• Если включено, данные распространяются на график данных в реальном времени (DMO), запускающий бизнес-процессы в нисходящем направлении.
• В противном случае, данные обрабатываются посредством стандартного пакета или ожидаемых продаж с более высокой задержкой.
• API принятия подтверждает успех внешней системы.
• Компоненты мониторинга предупреждают администратора об очередях из мертвых писем, уровне отклонений или проблемах задержки.

Результаты

Данные внешних событий принимаются в ООД Data 360 с низкой задержкой. Если целевой DMO является частью графика в реальном времени, данные доступны для мгновенной сегментации, бизнес-правил агента, моделей искусственного интеллекта и операционной активации. Это позволяет быстро реагировать на события, исходящие из любой связанной системы.

Механизмы принятия

Механизм приема зависит от коннектора и стратегии планирования, определенных в Data 360.

Обработка и восстановление ошибок

• Немедленные ошибки синхронизации: 4xx ответов для ошибок схемы/аутентификации — клиент должен исправить полезные данные или маркер и повторить попытку.
• Переходные (асинхронные) сбои: 5xx ответов — клиент предпринимает попытки с экспоненциальным отступлением и дрожанием.
• Мертвая очередь (DLQ): Постоянные сбои приземляются в DLQ для проверки вручную и повтора.
• Мониторинг: Отслеживайте уровень отклонения схемы, сбои проверки подлинности, процентили задержки и накопившиеся DLQ. Предупреждение о порогах.

Рекомендации по созданию эффективных решений

• Ключ демпотентности: Каждое событие должно содержать уникальный ключ импотентности/код сообщения.
• Вставка стратегии: Используйте бизнес-ключи (ExternalId), чтобы избежать повторов.
• Окно отмены: Архитектор должен определить окна дедупликации и сохранность для отслеживания импотенции.

Рекомендации по безопасности

Безопасность является неотъемлемой частью процесса принятия, от проверки подлинности до шифрования и контроля доступа.

• Проверка подлинности: OAuth 2.0 (носитель JWT), рекомендуемый для межсерверного взаимодействия. Ограничьте области только приемом.
• Шифрование: TLS 1.2+ для транспортировки; Data 360 внедряет шифрование в дежурном режиме.
• Наименьшие привилегии: Регистрационные данные связанного приложения имеют минимальные права; ротация секретов и журналов доступа к прибору.
• Управление полезными данными: Добавьте флажки согласия/потребления в метаданные событий; примените политики ABAC/CEDAR сразу после приема.
• Элементы управления IP-адресами / Private Connect: При необходимости, ограничьте доступ посредством списков разрешенных или используйте Private Connect для личных сетей.

Боковые панели

Своевременность

Своевременность зависит от расписания приема и объема данных. Streaming JSON возвращает субсекундную-секундную задержку, в зависимости от обработки и конфигурации графика. Пакетный CSV-файл длится от нескольких минут до нескольких часов. Выберите на основе бизнес-SLA.

Объемы данных

Размеры отдельных событий должны быть небольшими (< несколько КБ). Для производителей с высокой производительностью рекомендуем пакетировать у производителя или использовать потоковый буфер (Kafka/Kinesis), прежде чем вызывать API.

Управление государством

• Версия схемы: Поддерживайте версию схемы в метаданных событий и используйте версию коннектора при обновлении контракта OAS.
• Смещения коннектора: Руководства Data 360 поддерживают семантику; производители должны отслеживать ключи импотентности и последнюю успешную последовательность для безопасного воспроизведения.

Сложные сценарии интеграции

В расширенных корпоративных архитектурах эта схема может интегрироваться с:

• Крайний слой проверки: Используйте промежуточные программы для перевода разнородных форматов производителей в обязательный контракт OAS, выполнения ограничения ставок и предварительного обогащения.
• Гибридные архитектуры: Сочетайте API принятия для событий и коннекторы для пакетной сверки.
• Активация агента: События, соотнесенные с DMO в реальном времени, могут запустить бизнес-процессы Agentforce и модели Einstein для автоматического принятия решений.

Пример

Торговая сеть транслирует события покупки в Data 360 в режиме реального времени, чтобы обеспечить немедленное вовлечение клиента. Каждый магазин запускает облегченный серверный компонент, который собирает транзакции, пополняет их расположением и метаданными устройства и безопасно публикует события JSON посредством OAuth носителя JWT с ключами импотенции для предотвращения повторов. Администратор определяет структуру события, загрузив схему OAS для точек продаж и настроив коннектор API принятия. Входящие события принимаются в pos_sale DLO, соотносятся с Sale DMO и добавляются в график в реальном времени. В результате ценные покупки обнаруживаются мгновенно, запуская VIP-бизнес-правила в Agentforce и обновляя сегментацию клиентов для стимулирования персонализации в реальном времени.

Контекст

Эта схема позволяет собирать большие объемы подробных данных о взаимодействии пользователей (например, просмотры страниц, нажатия кнопок, оттиски продуктов и видеопроигрывания) из веб-сайтов и мобильных приложений в режиме trueReal-Time. Это основа для предоставления моментальной персонализации, где каждое цифровое взаимодействие может динамически повлиять на взаимодействие пользователя и стимулировать занятость.

Проблема

Как предприятие может собрать и обработать непрерывный поток поведенческих событий из цифровых свойств, охватывающий миллионы взаимодействий пользователей в минуту, и сделать эти данные немедленно доступными в Data 360 для поддержки сегментации, персонализации и активации в реальном времени?

Силы

Этот сценарий использования представляет несколько проблем проектирования, требующих специально созданной архитектуры принятия с низкой задержкой:

• Экстремальная пропускная способность: Веб-сайты с высокой посещаемостью или мобильные приложения могут излучать миллионы событий в минуту. Слой приема должен масштабироваться по горизонтали, чтобы обрабатывать этот объем без потери события или противодавления, обеспечивая последовательную задержку при пиковых нагрузках.
• Приборы со стороны клиента: В отличие от интеграций, управляемых сервером, эта схема зависит от клиентских SDK. Маяк JavaScript (Salesforce Interactions SDK) должен быть встроен на каждую страницу или собственный SDK интегрирован в мобильные приложения. Это требует надежного развертывания клиентов, версии и управления схемами событий.
• Обработка событий с низкой задержкой: Действия пользователя (например, «добавить в корзину» или «воспроизведение видео») должны достичь Data 360 в течение нескольких секунд, включив активацию в реальном времени и контекстуальные ответы (например, целевые предложения, персонализированные рекомендации).
• Гармонизация данных и разрешающая способность при опознавании: Собранные события часто содержат анонимные идентификаторы (cookie-файлы, коды устройств, маркеры сеансов). Для питания сценариев использования Customer 360 они должны быть соотнесены с известными профилями посредством разрешающей способности при опознавании Data 360 и гармонизированы с моделью данных Customer 360.

Решение

Рекомендуем использовать коннектор персонализации Salesforce Marketing Cloud — нативный полностью управляемый потоковый конвейер, предназначенный для высокопроизводительного поведенческого приема.

Эскиз

Эта диаграмма иллюстрирует последовательность этапов приема данных из мобильных и веб-каналов в Data 360

В этом сценарии:

• Разверните SDK в веб- или мобильных каналах (сбор взаимодействия пользователя).
• Настройте SDK с помощью элементов управления кодом клиента, средой и согласием.
• Потоковые передачи собранных событий JSON (метаданные + атрибуты) в конечную точку потока Marketing Cloud.
• В настройках Data 360 создайте и настройте коннектор персонализации для клиента.
• Примите события в ООД и соотнесите ООД → DMO в Data 360.
• Включите DMO в графике в реальном времени для немедленной активации.
• Отслеживайте задержку, соответствие схемы, флажки согласия, производительность, уровень ошибок.
• Развертывание в производстве и постоянное отслеживание.

Результаты

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

Механизмы принятия

Механизм приема зависит от коннектора и стратегии планирования, определенных в Data 360.

Обработка и восстановление ошибок

• Слоистая отказоустойчивость: Внедрите многоуровневые механизмы проверки и повторной попытки — Customer SDK обрабатывают переходные сбои посредством экспоненциального резервирования, в то время как слой принятия использует долговечные очереди и воспроизводимые ожидаемые продажи для предотвращения потери данных.
• Управление схемами и данными: Версия и постоянная проверка схем событий; недопустимые или развивающиеся события перенаправляются в очередь отклонения схемы или мертвого письма для безопасной сортировки и повтора.
• Idempotency & Deduplication: Используйте стабильные идентификаторы событий и обновите семантику, чтобы гарантировать точную обработку даже во время попыток или повторов.
• Автоматизация мониторинга и восстановления: Постоянное отслеживание производительности, задержек и уровня ошибок запускает автоматические бизнес-процессы восстановления — обеспечивая низкую задержку, надежную доставку и последовательные результаты персонализации в реальном времени.

Рекомендации по созданию эффективных решений

• Каждое событие должно содержать уникальный ключ импотентности или код сообщения, чтобы дубликаты отправлений дублировались в нисходящем направлении.
• Используйте бизнес-ключи (например, sessionID + eventTimestamp + userID) при необходимости для идентификации повторов.
• Определите окно дедупликации (например, 24 часа), в течение которого повторяющиеся события игнорируются или фильтруются.
• При необходимости используйте стратегии обновления и вставки (например, обновление счетчиков или флажков вместо вставки повторов).

Рекомендации по безопасности

Безопасность является неотъемлемой частью процесса принятия, от проверки подлинности до шифрования и контроля доступа.

• Транспортное шифрование: TLS 1.2+ для всех подключений потоковой службы SDK →.
• Шифрование данных в дежурном режиме в Data 360 и маркетинговом потоке.
• SDK учитывает флажки согласия пользователя (GDPR/CCPA) и блокирует отслеживание отклонения согласия.
• Проверка подлинности трафика SDK: убедитесь, что только утвержденные клиенты/потребители могут транслировать события.
• Метаданные: каждое событие должно содержать код источника, отметку времени, версию схемы, код сеанса, ключ импотенции.
• Доступ с наименьшими правами: Конечные точки и коннекторы SDK ограничены областью принятия события; регулярно меняйте регистрационные данные.
• Классификация данных: Аннотирование персональных данных в полезных данных событий, внедрение политик сразу после приема

Боковые панели

Своевременность

• Своевременность зависит от действий конечного пользователя и конфигурации потоковых событий.
• События, собранные посредством Salesforce Interactions SDK и доставленные посредством потока персонализации Marketing Cloud, обычно достигают задержки от субсекунды до ~2 секунд, прежде чем стать доступными в графике в реальном времени Data 360.
• Это включает почти мгновенную сегментацию, персонализацию и активацию в активных сеансах пользователя.

Объемы данных

Отдельные поведенческие события (например, щелчок, просмотр, добавление в корзину) легкие — обычно от 1 до 5 Кб на полезные данные. Для масштабных цифровых свойств ожидайте от тысяч до миллионов событий в минуту. Для обеспечения производительности и устойчивости:

• Используйте встроенные механизмы пакетирования и повторной попытки SDK для страниц с высокой посещаемостью.
• Выгрузите обработку всплесков в буферный слой потока Marketing Cloud.
• Отслеживайте пропускную способность приема и коэффициенты ошибок посредством панели мониторинга показателей коннектора.

Управление государством

Каждое событие содержит метаданные для контроля состояния и версии:

• Версия схемы: Встройте версию схемы в каждое событие; добавьте версию коннектора персонализации при обновлении схемы.
• Обработка повтора: События, которые не выполняются из-за проблем транзиторной сети, автоматически перепроверяются SDK с экспоненциальной обратной связью.
• Ключи демпотентности: Уникальные идентификаторы (sessionId + eventType + отметка времени) предотвращают создание повторов в Data 360.
• Управление смещением: Data 360 отслеживает успешные обязательства; все необработанные события повторно попадают в очередь коннектора до успешного приема.

Сложные сценарии интеграции

Данная схема без труда интегрируется в продвинутые корпоративные архитектуры:

• Крайний слой обогащения: Добавьте промежуточное программное обеспечение (например, обратную прокси-функцию или функцию без сервера) для добавления дополнительного контекста, например, географию, тип устройства или метаданные кампании, прежде чем события достигнут Marketing Cloud.
• Hybrid(Streaming + Batch): Используйте коннектор Marketing Cloud для потоков в реальном времени и объедините его с пакетными заданиями ETL (например, данными заказа) для последующей сверки.
• Активация агента: События, соотнесенные с DMO в реальном времени, могут запустить персонализацию Einstein, бизнес-правила Agentforce или решение на основе искусственного интеллекта адаптировать цифровое взаимодействие в данный момент.
• Управление несколькими клиентами: Используйте флажки согласия и метаданные клиента для обеспечения конфиденциальности и соответствия в мультибрендовой или мультирегиональной среде.

Пример

Глобальная электронная торговая компания предоставляет покупателям персонализированные рекомендации по продуктам и динамическое содержимое, пока они активно просматривают www.retailx.com, одностраничное приложение на основе реакции. С помощью Salesforce Interactions SDK на стороне клиента сайт собирает просмотры страниц, нажатия на продукты, действия корзины и видео взаимодействия в реальном времени. Эти события проходят через поток событий Marketing Cloud Personalization и коннектор Personalization в Data 360 DLO, где они моделируются в DMO и включаются в график в реальном времени. Эта архитектура мгновенно предоставляет поведенческие сигналы для сегментации, персонализации под управлением Einstein и активации Agentforce, что позволяет адаптивным, сессионным взаимодействиям с клиентами

Контекст

Во многих важных для бизнеса процессах необходимо поддерживать идеальное соответствие Data 360 последним обновлениям в базовых системах CRM. Группы по обслуживанию клиентов, продажам и маркетингу зависят от актуальной информации для принятия решений, запуска путешествий и активации автоматизации. Эта схема предоставляет механизм синхронизации изменений ключевых объектов Salesforce CRM (например, контакта, организации и обращения) в Data 360 с минимальными задержками, без неэффективности или задержки частого пакетного опроса.

Проблема

Как Data 360 может поддерживать почти идеально синхронизированное состояние с ключевыми объектами Salesforce CRM, обеспечивая, чтобы последующая аналитика, сегментация и активация на основе искусственного интеллекта всегда работали с самыми актуальными доступными данными?

Силы

Эта схема накладывает ряд технических ограничений и архитектурных соображений:

• Архитектура, управляемая событиями: Синхронизация должна быть реактивной — вызванной событиями изменений в исходной организации CRM, а не периодическими пакетными заданиями.
• Выборочная поддержка объектов: Не все стандартные и настраиваемые объекты Salesforce поддерживают потоковую передачу в реальном времени. Архитекторы должны ссылаться на список поддерживаемых объектов во время проектирования, чтобы избежать пробелов.
• Доступ и полномочия: Включение потоковой передачи требует назначения пользователю интеграции в исходной организации полномочия системы «Включение полномочий для потоковой передачи CRM».
• Свежесть данных по сравнению с Стоимость обработки: Хотя синхронизация в близком к реальному режиме времени повышает оперативность, чрезмерная пропускная способность событий может потребовать горизонтального масштабирования и надежных механизмов восстановления ошибок.
• Интеграция уровней безопасности и доверия : Все данные событий должны соответствовать инфраструктурам Trust и Security Salesforce, зашифрованным в пути, проверенным на соответствие схеме и обработанным в пределах границы Trust организации.

Решение

Рекомендуем использовать коннектор Salesforce CRM с включенной функцией Streaming (сбор данных об изменении). При создании потока данных для поддерживаемого объекта CRM (например, контакт) администраторы могут переключить параметр «Включить потоковую передачу». Под капотом платформа Salesforce по сбору данных об изменении (CDC) публикует сообщение ChangeEvent при каждом создании, обновлении, удалении или отмене удаления записи в исходной организации CRM. Коннектор Data 360 CRM подписывается на эти события CDC и применяет соответствующие изменения к соотнесенному объекту озера данных (DLO) в Data 360 в близком к реальному режиме времени. Это обеспечивает непрерывную синхронизацию между CRM и Data 360 с минимальным ручным вмешательством.

Эскиз

Эта диаграмма иллюстрирует последовательность этапов приема данных из CRM в Data 360 в близком к реальному режиме времени

В этом сценарии:

• Изменения происходят в Salesforce CRM (создание/обновление/удаление/отмена).
• CDC публикует ChangeEvent во внутренней шине событий Salesforce.
• Коннектор Data 360 CRM подписывается на шину событий посредством прочного курсора воспроизведения.
• Полезная нагрузка события проверяется на наличие схемы, полномочий и целостности данных.
• Data 360 записывает проверенное событие в соотнесенный объект озера данных (DLO).
• При включении, соотнесенные объекты модели данных обновляются в близком к реальному режиме времени, активируя сегментацию и активацию.

Результаты

Data 360 поддерживает непрерывно синхронизированное зеркало ключевых данных CRM. Это позволяет:

• Триггеры в реальном времени (например, путешествие запускается при создании обращения).
• Актуальная сегментация (например, перемещение клиентов в сегмент «Золотой» после изменения статуса организации).
• Более точная аналитика и персонализация на основе оперативного контекста CRM.

Механизмы принятия

Механизм приема для этой схемы нативно управляется посредством коннектора Salesforce CRM с включенным сбором данных об изменении (CDC). Data 360 выступает в качестве подписчика на поток событий CDC, обеспечивая надежную синхронизацию с низкой задержкой между исходной организацией CRM и Data 360.

Обработка и восстановление ошибок

• Автоматическое восстановление ошибок: Коннектор CRM автоматически повторяет временные ошибки сети или платформы посредством экспоненциального резервирования и перенаправляет постоянные сбои в очередь мертвых букв (DLQ) для повтора.
• Устойчивость схемы и проверки подлинности: Несоответствия схемы закрываются на карантин в очереди отклонения схемы для проверки администратором, в то время как ошибки проверки подлинности или полномочий инициируют управляемые попытки и оповещения посредством мониторинга Data 360.
• Непрерывность гарантированного события: Долговечные ReplayID гарантируют отсутствие потери событий во время простоя коннектора; пропущенные события восстанавливаются посредством окон повтора или пакетных заданий повторной синхронизации.
• Целостность и порядок данных: Встроенная идемпотентность (RecordID + SequenceNumber) предотвращает повторы, а ChangeEventHeader.sequenceNumber сохраняет правильный порядок событий для каждой записи CRM.

Рекомендации по созданию эффективных решений

• Уникальность события: Каждое событие CDC содержит ReplayID и ChangeEventHeader.entityName для детерминистской дедупликации.
• Вставка стратегии: Внедрите логику UPSERT на основе кода записи, чтобы предотвратить создание повторов событий.
• Обработка повтора: Используйте курсор воспроизведения коннектора для возобновления с последнего принятого смещения в случае переходных сбоев.
• **Эволюция схемы: **Сохранение версии схемы в метаданных событий и обновление соотнесений ООД при изменении схемы CRM.

Рекомендации по безопасности

Безопасность является неотъемлемой частью процесса принятия, от проверки подлинности до шифрования и контроля доступа.

• Шифрование и доверие : Все события передаются посредством TLS 1.2+ и хранятся в зашифрованном виде в Data 360.
• Контроль доступа: Только проверенные коннекторы с соответствующими полномочиями интеграции могут подписываться на каналы CDC.
• Проверка схемы: Каждое полезное значение события проверяется по схеме ООД перед приемом.
• Распространение согласия: Метаданные согласия и классификации данных поступают в нисходящем направлении с каждым событием для сохранения конфиденциальности и соответствия (GDPR, CCPA).
• Оперативное управление: События регистрируются, проверяются и отслеживаются на наличие повторов, отклонений схемы и аномалий производительности посредством Data 360 Trust Layer.

Боковые панели

Своевременность

• События CDC обрабатываются в близком к реальному режиме времени, обычно в течение нескольких секунд после изменения в CRM.
• Задержка может меняться в зависимости от объема событий и производительности коннектора, но Data 360 гарантирует доступность подминуты для поддерживаемых объектов.

Объемы данных

• Каждое полезное значение события имеет небольшой вес (~1-5 Кб).
• Для объектов с высокой скоростью изменения, например, обращения или контакта, убедитесь, что ограничения производительности соответствуют распределениям событий Salesforce CDC.

Управление государством

Каждое событие содержит метаданные для контроля состояния и версии:

• Коды повтора: Используется для последовательного восстановления событий.
• Версия схемы: Ведение метаданных версии для управления изменениями контракта.
• Ключи демпотентности: Повторы повторов в попытках.
• Обязательство смещения: Data 360 сохраняет состояние обязательства после каждого успешного пакета событий.

Сложные сценарии интеграции

Данная схема без труда интегрируется в продвинутые корпоративные архитектуры:

• Hybrid(Streaming + Batch): Используйте CDC для дельта-обновлений и пакетные задания для полного обновления.
• Потоковая передача между организациями: Несколько исходных организаций могут передаваться одному клиенту Data 360, объединенному посредством соотнесений DMO.
• Активация агента: Обновления объектов в реальном времени запускают автоматизацию Einstein или Agentforce.
• Маршрутизация событий: Промежуточное ПО (например, MuleSoft или Event Relay) может пополнить или перенаправить сообщения CDC до приема.

Пример

Глобальный банк хочет обеспечить мгновенное отображение изменений данных клиентов в Salesforce Sales Cloud в Data 360.При обновлении адреса контакта в Sales Cloud механизм сбора данных об изменении публикует ContactChangeEvent.Коннектор Data 360 CRM использует это событие, применяет обновление к Customer DLO и автоматически обновляет все связанные профили Customer 360. Таким образом запускается Einstein Next Best Action для проверки нового адреса — завершения цикла отзывов в течение нескольких секунд после оригинального изменения CRM.

Контекст

Современные цифровые предприятия используют платформы потоковой передачи событий в реальном времени, например, Amazon Kinesis Data Streams и Amazon MSK (управляемый поток для Apache Kafka), для сбора непрерывных потоков данных из распространенных приложений, устройств IoT и транзакционных систем. Data 360 поддерживает прямой прием с этих платформ посредством собственных сторонних коннекторов, что исключает необходимость использования настраиваемых решений на основе ETL или промежуточного программного обеспечения. Эта схема предназначена для высокопроизводительного приема данных с низкой задержкой, включения важных данных в близком к реальному режиме времени, персонализации и активации на основе искусственного интеллекта.

Проблема

Как предприятию безопасно и эффективно подключить Data 360 к AWS Kinesis или темам AWS MSK Kafka для непрерывного приема структурированных данных событий и профилей, обеспечивая соответствие схеме, масштабируемость и управление?

Силы

Эта схема вводит несколько архитектурных и оперативных соображений:

• Доступность собственного коннектора: Salesforce предоставляет общедоступные нативные коннекторы для Amazon Kinesis и Amazon MSK. Эти коннекторы предлагают стороннюю поддержку и устраняют необходимость в настраиваемых ожидаемых продажах на основе API.
• Проверка подлинности и безопасность: Каждый коннектор требует проверки подлинности на уровне AWS.
• Для Kinesis это использует ключ доступа AWS и секретный ключ, управляемые политиками IAM.
• В MSK проверку подлинности можно настроить посредством ключа доступа/секрета или OpenID Connect (OIDC).
• Определение схемы: Data 360 требует схемы для толкования потоковой полезной нагрузки. В Kinesis файл схемы загружается во время настройки подключения, определяя структуру событий и соотнесения полей.
• Источник конфигурации:
• Коннектор Kinesis подписывается на определенное имя потока Kinesis.
• Коннектор MSK подписывается на тему Kafka в кластере MSK.
• Доступ к сети: Для безопасных сред коннекторы можно настроить посредством маршрутизации PrivateLink или VPC, гарантируя отсутствие пересечения данных в общедоступном Интернете.
• Оперативное управление: Пропускная способность потоковой передачи, проверка схемы и события проверки подлинности отслеживаются в Data 360 Trust Layer, обеспечивая соответствие и отслеживаемость.

Решение

Решение использует собственные коннекторы Amazon Kinesis или Amazon MSK в Data 360.

Эскиз

Эта диаграмма иллюстрирует последовательность этапов приема данных из платформ событий, например, Kafka и Kinesis, в Data 360 в близком к реальному режиме времени

В этом сценарии:

• Приложения или устройства публикуют события в потоке Кинезиса или теме MSK.
• Коннектор Data 360 проверяет подлинность посредством регистрационных данных AWS или маркера OIDC.
• Коннектор постоянно опрашивает поток или подписывается на него.
• События поэтапны, проверены для схемы и политики, потом зафиксированы в объекте озера данных (DLO).
• При соотнесении объекты модели данных (DMO) обновляются практически в режиме реального времени для активации.
• Уровень мониторинга отслеживает показатели, отклонения схемы и задержку.

Результаты

Непрерывный прием структурированных данных с низкой задержкой напрямую из AWS Kinesis или MSK в Data 360. Данные немедленно доступны для:

• Разрешающая способность при опознавании
• Сегментация в реальном времени
• Активация искусственного интеллекта Einstein
• Триггеры под управлением Agentforce Устраняет зависимость от пакетного ETL, включая архитектуры на основе потока, соответствующие корпоративным дизайнам событий.

Механизмы принятия

Обработка и восстановление ошибок

• Автоматические попытки: Коннекторы повторяют переходные ошибки сети или платформы с экспоненциальным отступлением.
• Отклонения схемы: Недопустимые полезные данные перенаправляются в очередь отклонения схемы для проверки администратором.
• Повтор DLQ: Постоянные сбои регистрируются в очередях мертвых букв для повторной обработки.
• Контроль демпотентности: Ключи событий или порядковые номера обеспечивают дедупликацию и упорядоченный прием.
• Интеграция мониторинга: Все сбои, попытки и показатели производительности появляются в панелях мониторинга мониторинга Data 360 Monitoring.

Рекомендации по созданию эффективных решений

• Уникальность и отслеживание событий: Каждому событию назначается детерминистский уникальный ключ (например, PartitionKey + SequenceNumber для Kinesis или Topic + Partition + Offset для MSK), чтобы обеспечить точный прием.
• Контрольная точка коннектора: Коннекторы Data 360 сохраняют последнее обработанное смещение или порядковый номер для безопасного возобновления приема после сбоев или перезагрузки.
• Дедупликация и логика UPSERT: Во время обязательств DLO повторы событий обнаруживаются и пропускаются; действительные записи вставляются посредством уникального ключа для поддержания последовательности.
• Управление повтором и восстановлением: Ошибочные или задержанные события проигрываются из сохраненных смещений посредством очередей «Мертвая буква» и «Повтор», обеспечивая надежное восстановление без дублирования.

Рекомендации по безопасности

Безопасность является неотъемлемой частью процесса принятия, от проверки подлинности до шифрования и контроля доступа.

• Проверка подлинности: Безопасный обмен регистрационными данными посредством политик AWS IAM или OIDC.
• Шифрование: Данные, зашифрованные в пути (TLS 1.2+) и в дежурном режиме (AES-256) в Data 360.
• Контроль доступа: Применение ролей с наименьшими правами; коннекторы, ограниченные определенными потоками/темами.
• Управление: Метаданные родословной и классификации, применяемые к каждой записи для полной отслеживаемости.
• Безопасность сети: По желанию, развертывание в личных подсетях посредством AWS PrivateLink.

Боковые панели

Своевременность

• Обработка в близком к реальному режиме времени: CDC и потоковые коннекторы обрабатывают события в течение нескольких секунд после изменений источника, обычно обеспечивая подминутную свежесть данных.
• Детерминистская задержка: Сквозное задержку зависит от производительности источника, пакетирования событий и условий сети, но Data 360 гарантирует предсказуемую задержку под управлением SLA для поддерживаемых объектов.
• Упругое масштабирование: Конвейеры принятия автоматически масштабируются под большим объемом событий, сохраняя своевременность даже во время пиковых всплесков данных.
• Оперативная доступность: Панели мониторинга мониторинга отображают задержку событий, отметки времени и статус повтора для обеспечения и устранения неполадок.

Объемы данных

• Легкие полезные данные: Отдельные CDC или потоковые события компактны (типичный размер от 1 до 5 Кб), оптимизированы для высокочастотных обновлений.
• Объекты с высокими изменениями: Для неустойчивых объектов (например, обращение, контакт, заказ) архитекторы должны обеспечить соответствие распределения CDC и производительности событий ожидаемой частоте обновления.
• Параллельные потоки: Data 360 поддерживает многопотоковое принятие для горизонтального масштабирования в больших объемах объектов или в организациях с несколькими источниками.
• Обработка противодавления: Встроенные механизмы дроссельной заслонки поддерживают стабильность приема под нагрузкой без сбрасывания событий.

Управление государством

Каждое событие содержит метаданные для контроля состояния и версии:

• Отслеживание повтора и смещения: Каждое событие содержит метаданные кода воспроизведения и последовательности, включительно с заказанной доставкой и восстановлением на основе контрольной точки.
• Версия схемы: Теги версий в заголовках событий обеспечивают обратно совместимую обработку при развитии исходных схем.
• Ключи демпотентности: Каждое событие содержит уникальную транзакцию или ключ подтверждения, что позволяет Data 360 безопасно дублировать повторы и попытки.
• Atomic Commit: Конвейеры приема помечают смещения завершенными только после успешного выполнения обязательств по ООД в нисходящем направлении, обеспечивая согласованность.

Сложные сценарии интеграции

Данная схема без труда интегрируется в продвинутые корпоративные архитектуры:

• Гибридный прием: Сочетайте CDC для инкрементных дельт с пакетными потоками данных для полного обновления, сохраняя свежесть и полноту.
• Потоковая передача между организациями: Несколько организаций CRM или ERP могут публиковать для одного клиента Data 360, объединенные посредством соотнесения DMO и выравнивания онтологии.
• Пополнение событий: Промежуточные программы (например, MuleSoft, Event Relay) могут пополнять, фильтровать или перенаправлять потоковые данные до достижения Data 360.
• Активация на основе искусственного интеллекта и агента: Обновления в реальном времени запускают автоматизацию в нисходящем направлении, например, прогнозы Einstein или ответы Agentforce, в течение нескольких секунд после исходного события.

Пример

Глобальное розничное предприятие использует AWS Kinesis для потоковой передачи данных о точках продаж и веб-взаимодействии.Коннектор Kinesis Data 360 проверяет подлинность посредством регистрационных данных IAM и непрерывно принимает события в DLO транзакций.Каждая запись проверяется по схеме, пополняется метаданными и немедленно распространяется в DMO клиента.В течение нескольких секунд модели Einstein AI обновляют клиентские сегменты, а Agentforce запускает рекомендации Next-Best-Offer в реальном времени — достигая полностью управляемого событиями цикла персонализации.

Zero Copy — это нечто большее, чем метод интеграции — это фундаментальный сдвиг в том, как перемещаются, а точнее, не перемещаются данные предприятия. Традиционно интеграция данных требовала копирования больших объемов записей посредством ожидаемых продаж ETL, создания избыточных хранилищ данных, задержек синхронизации и проблем управления. Нулевая копия удаляет все это. В этой модели Data 360 напрямую подключается к внешним платформам данных, например, Snowflake и Databricks, безопасно считывая и активируя данные на месте, не перемещая и не дублируя их. Результатом является безупречная связь между корпоративным центром обработки данных и экосистемой Salesforce, предоставляющая мгновенный доступ, меньшие операционные расходы и более сильное управление данными.

Возможности входящего нулевого копирования позволяют Data 360 запрашивать и гармонизировать внешние данные в источнике (например, профили клиентов, транзакции или данные продуктов), сохраненные в Snowflake или Databricks. Вместо приема файлов Data 360 устанавливает безопасное подключение с метаданными, использующее существующие определения схемы и политики безопасности на внешнем складе.

• Прямая федерация: Data 360 считывает данные посредством безопасных, оптимизированных запросов без репликации.
• Объединенное управление: Данные остаются под инфраструктурой безопасности исходной системы, контроля доступа и соответствия.
• Операционная эффективность: Устраняет дублирование ETL и хранилища, снижая стоимость и сложность.
• Готовность в реальном времени: Включает гармонизацию по запросу — в момент обновления данных в Snowflake они немедленно доступны для активации в Data 360.

Контекст

Современные предприятия, управляемые данными, управляют петабайтами данных клиентов, транзакций и телеметрии в облачных платформах Lakehouse данных, например, Snowflake и Databricks. Эти среды служат единым источником истины для аналитики, искусственного интеллекта и соответствия. Data 360 представляет Zero CopyData Federation, позволяя Data 360 напрямую запрашивать и использовать внешние наборы данных на месте, без копирования, трансформации или хранения избыточных данных. Эта схема дает возможность организациям расширить ткань Customer 360 в существующее хранилище данных или инфраструктуру Lakehouse — достигнув объединения и активации в реальном времени без дублирования, без задержки и без компромисса по управлению.

Проблема

Как предприятия могут использовать богатые наборы данных, уже созданные в Snowflake, Databricks или открытых форматах озера, например, Apache Iceberg, для сегментации, разрешающей способности при опознавании и активации в Data 360, без затрат, задержки и управления накладными расходами на ожидаемые продажи ETL или перемещение физических данных?

Силы

Эта схема вводит несколько рекомендаций по архитектуре, безопасности и производительности:

Сеть и безопасность

• Data 360 должна установить безопасное личное подключение к внешнему складу или озеру.
• Обычно настроено посредством Salesforce Private Connect или PrivateLink/VPC Peering, гарантируя, что трафик никогда не покидает контролируемую клиентом сеть.
• Внешние системы должны добавить в список разрешенных IP-адресов Data 360 и внедрить шифрование TLS 1.2+.

Проверка подлинности и управление доступом

• Поддерживает проверку подлинности пары ключей, OAuth 2.0 или делегирование Trust на основе поставщика удостоверений (IdP) (Data 360, действующий в качестве надежного клиента)
• Контроль доступа на основе роли (RBAC) во внешней системе применяет наименьший доступ к привилегиям для выполнения запроса.

Производительность и зависимость вычисления

• Федерация запросов внедряет выполнение SQL в Snowflake или Databricks, используя их вычислительные кластеры.
• Производительность и шкала стоимости с загрузкой внешнего запроса — задержка сегментации и стоимость связаны с конфигурацией внешнего компьютера.

Развивающиеся стандарты: Интеграция файлов

• Модель следующего поколения, интеграция файлов, использует открытые форматы таблиц, например, Apache Iceberg или Delta Lake, что позволяет Data 360 читать напрямую из хранилища объектов (например, Amazon S3, Azure ADLS, Google Cloud Storage).
• Минуя исходный вычислительный слой, интеграция файлов резко сокращает задержку и затраты на чтение больших аналитических нагрузок, сохраняя целостность схемы.

Управление и соблюдение

• Данные никогда не покидают исходную платформу — политики соответствия, шифрования и сохранности остаются внедренными в источнике.
• Все атрибуты метаданных, родословной и согласия распространяются на уровень Trust Data 360, чтобы обеспечить комплексное отслеживание.

Решение

Рекомендуемый метод - использование собственных коннекторов Zero Copy для Snowflake, Databricks или интеграции файлов в Data 360.

Эскиз

Следующая диаграмма иллюстрирует, как настроить подключение нулевой копии и создать внешние ООД в Data 360.

В этом сценарии:

• Администратор настраивает подключение Zero Copy в настройках Data 360 (Snowflake, Data Bricks или интеграция файлов).
• Установлены безопасная проверка подлинности и маршрутизация сети (Private Connect / OAuth / Key Pair).
• Администратор создает поток данных, выбирая внешний источник — просмотр оперативных баз данных, схем и таблиц.
• Вместо копирования данных Data 360 создает External DLO (Объект озера данных) — указатель метаданных, ссылающийся на оперативную таблицу или файл айсберга.
• Внешние ООД соотносятся с объектами Customer 360 (например, Customer, Transaction, Product).
• Data 360 запрашивает источник во время сегментации, активации или расчета важных данных.
• Все доступ, родословная запросов и метаданные проверяются в Data 360 Trust Layer.

Результаты

• Внешние данные остаются в Snowflake, Databricks или S3 — без ETL, дублирования, дополнительного хранилища.
• Data 360 получает доступ в режиме реального времени в режиме чтения к данным корпоративного масштаба для разрешающей способности при опознавании, вычисленных важных данных и активации.
• Организации поддерживают полный контроль в рамках существующих инфраструктур управления, шифрования и соответствия.
• Эта схема включает настоящую архитектуру Zero Copy, сочетающую производительность локального доступа с управлением интегрированным хранилищем.

Механизмы вызова

Механизм вызова зависит от решения, выбранного для внедрения этой схемы.

Обработка и восстановление ошибок

• Автоматическая обратная попытка и запрос: Переходное подключение или время ожидания запроса автоматически повторяются посредством экспоненциального резервирования.
• Изоляция несоответствия схемы: Изменения в исходной схеме (например, новые столбцы) регистрируются в очереди отклонения схемы; администраторы могут повторно соотнести или обновить метаданные схемы.
• Сбой проверки подлинности: Если срок действия регистрационных данных истекает, Data 360 пытается подключиться посредством сохраненных маркеров обновления или политик ротации ключей.
• Обнаружение доступности вычисления: Если кластер Snowflake или Databricks приостановлен, Data 360 приостанавливает задания интегрирования и выполняет повторную попытку после возобновления вычислений.
• Интеграция мониторинга: Все метаданные о работоспособности подключения, задержке запроса и последовательности доступны в панелях мониторинга мониторинга Data 360 Monitoring.

Рекомендации по созданию эффективных решений

• Детерминизм запроса: Федеративные запросы используют последовательную семантику снимков для обеспечения стабильных повторяемых чтений во время сегментации или активации.
• Внешняя версия DLO: Каждый интегрированный запрос содержит схему и метаданные отметок времени для отслеживания линий.
• Доступ без смещения: Поскольку Zero Copy доступна только для чтения, она не зависит от смещений событий - согласованность обеспечивается посредством гарантий ACID внешней системы (Snowflake/Delta Lake).
• Управление дрейфом схемы: Поддерживайте версионные соотнесения схем в Data 360; обновляйте внешние метаданные ООД об эволюции источников.

Рекомендации по безопасности

Безопасность является неотъемлемой частью модели федерации — обеспечение отсутствия компромисса в Trust или соответствии.

• Шифрование: Все обмены данными используют TLS 1.2+; внешние склады шифруют в дежурном режиме посредством AES-256.
• Контроль доступа: Внешние таблицы доступны посредством ролей с наименьшими полномочиями только для чтения.
• Изоляция сети: Маршруты Private Connect или VPC предотвращают доступ к общедоступным конечным точкам.
• Управляемый поток данных: Метаданные строки, согласия и классификации поступают в уровень Data 360 Trust для внедрения политики.
• Проверяемость: Каждое событие интегрированного запроса и доступа к схеме регистрируется для отслеживания соответствия (GDPR, CCPA, HIPAA).

Боковые панели

Своевременность

• Запросы выполняются в реальном времени относительно внешнего склада или хранилища, обеспечивая отображение последнего состояния данных в реальном времени.
• Выполнения сегментации или активации отображают досекундные изменения в таблицах Snowflake, Databricks или поддерживаемых S3 таблиц айсбергов.
• Задержка запроса зависит от уровня производительности исходной системы — обычно от секунд до десятков секунд на запрос.
• идеально подходит для аналитических нагрузок и нагрузок на основе искусственного интеллекта, требующих «свежего, а не скопированного» доступа к данным.

Объемы данных

• Поддерживает наборы данных в петабайтном масштабе, сохраненные в Snowflake или Databricks без репликации.
• Data 360 извлекает только результаты, а не исходные наборы данных, минимизируя затраты сети и вычисления.
• Интеграция файлов оптимизирует большие аналитические сканирования посредством обрезки разделов и выталкивания столбцов.
• Масштабы линейно с вычислительной емкостью склада и федеративным слоем оркестрации запроса Data 360.

Управление государством

• Внешние ООД сохраняют подключение, схему и метаданные версии в Data 360.
• Эволюция схемы управляется автоматически посредством циклов обновления метаданных.
• Родословная запроса содержит отметки времени, удостоверение пользователя и показатели выполнения для отслеживания.
• Статусный прием или смещения не поддерживаются — консистенция наследуется от гарантий КИСЛОТЫ внешнего источника.

Сложные сценарии интеграции

• Гибридный режим: Сочетайте Zero Copy (для оперативной федерации) с приемом (для архивных наборов данных).
• Доступ между складами: Data 360 может поступать от нескольких клиентов Snowflake или Databricks в одной организации.
• Интерактивность искусственного интеллекта/БИ: Внешние системы (например, SageMaker, Tableau, Power BI) могут запрашивать обогащенные профили Data 360 обратно посредством обратной нулевой копии.
• Расширение интеграции файлов: Предприятия, использующие форматы открытых озер (Айсберг/Дельта), могут объединять структурированные и неструктурированные данные в рамках одной федеративной модели.

Пример

Глобальное финансовое предприятие хранит все транзакционные данные и данные взаимодействия в Snowflake, сохраняя атрибуты клиентов и маркетинговые события в Data 360. Используя Zero Copy Data Federation, Data 360 безопасно подключается к Snowflake посредством Private Connect.Когда выполняется задание сегментации, например, «Клиенты с >$10K тратят за последние 30 дней, Data 360 проталкивает запрос вниз в Snowflake, извлекает агрегированные результаты и мгновенно активирует эти профили в Journey Builder. Репликация или ETL не нужны. Данный пример использует интегрированную интеллектуальную базу в реальном времени, объединенную в корпоративной экосистеме данных.

Исходящая нулевая копия расширяет этот же принцип в обратном порядке. Вместо экспорта или копирования наборов данных из Data 360 внешние системы, например, Snowflake, могут напрямую запрашивать Data 360, рассматривая его как федеративный источник обогащенного Аналитики клиентов.

• Обратная федерация: Внешняя аналитика или платформы на основе искусственного интеллекта имеют доступ к данным объединенного профиля Data 360 без их извлечения.
• Активация данных в источнике: Бизнес-группы могут использовать важные данные, где они уже находятся, будь то для моделирования на основе искусственного интеллекта, составления отчетов или персонализации клиентов.
• Без задержек совместимость: Пакетные экспорты и синхронизация заданий отсутствуют; важные данные мгновенно перемещаются между платформами.
• Последовательная семантика: Поскольку обе системы имеют одинаковую онтологию и соотнесение схем, контекст и значение сохраняются в экосистемах. Zero copy переопределяет роль Data 360 из хранилища данных в семантический уровень активации. Это позволяет организациям хранить данные именно там, где им и положено, — на управляемых высокопроизводительных складах, — но при этом открывать их полное значение в пределах Trust Salesforce. Эта схема соответствует современным сеткам данных и нативным архитектурам на основе искусственного интеллекта: данные остаются децентрализованными, но интеллект становится единым. Архитекторы теперь могут создавать ожидаемые продажи активации, которые будут более быстрыми, компактными и соответствующими требованиям, не требуют копирования.

Контекст

Современные предприятия все чаще работают в многоплатформенных экосистемах данных, где Salesforce Data 360 поддерживает объединенные профили клиентов и активацию, в то время как корпоративные хранилища данных, например, Snowflake или Databricks, служат аналитическими опорами для науки о данных, компьютерного обучения и загруженности BI. Возможность общего доступа «Нулевая копия исходящих данных» Salesforce Data 360 без труда соединяет эти среды, предоставляя управляемый, безопасный и оперативный доступ к гармонизированным данным Data 360 напрямую в Snowflake или Databricks, без репликации или ETL. Это позволяет аналитикам и специалистам по обработке данных запрашивать, визуализировать и моделировать на основе одних и тех же оперативных надежных данных, влияющих на активацию маркетинга, продаж и обслуживания.

Проблема

Как предприятию безопасно и эффективно предоставлять внешним аналитическим системам доступ к объединенным профилям клиентов Data 360 и вычисленным показателям (например, значение срока действия, риск оттока) без копирования данных, нарушения управления или внедрения задержки посредством традиционных обратных ожидаемых продаж ETL?

Силы

Эта схема вводит несколько архитектурных, управленческих и операционных рекомендаций:

• Управляемая безопасность: Доступ к данным Data 360 должен быть управляемым, детализированным и доступным для аудита. Общий доступ «Нулевая копия» использует явный доступ на уровне объекта, обеспечивая доступность назначенным потребителям только утвержденных объектов модели данных (DMO) и объектов вычисленных важных данных (CIO).
• Явный выбор объекта: Администраторы курируют общедоступные данные посредством общего доступа к данным, четко выбирая объекты для открытия. Это поддерживает управление и минимизирует риск.
• Двусторонняя конфигурация: Данные 360 и внешний склад требуют настройки. Data 360 определяет цель общего доступа к данным (Snowflake/Databricks), в то время как система получения должна принять и мгновенно предоставить общий доступ.
• Модель интегрирования запросов: После принятия, внешняя платформа запрашивает оперативные управляемые данные Data 360 посредством интегрированных представлений, исключая задания извлечения или циклы обновления вручную.
• Эволюция открытых стандартов: Новые подходы, например интеграция файлов, используют открытые форматы таблиц (например, Apache Iceberg) для включения доступа только для чтения на уровне хранилища — повышая масштабируемость, производительность и совместимость в мультиоблачных архитектурах.

Решение

Решение использует собственный общий доступ Zero Copy Salesforce Data 360 с такими платформами данных, как Snowflake или Databricks.

Эскиз

Следующая диаграмма иллюстрирует вызов Salesforce Data 360 на внешнюю платформу данных.

В этом сценарии:

• Администратор Data 360 определяет общий доступ к данным, включительно с объектами объединенного клиента и вычисленных важных данных.
• Цель общего доступа к данным (организация Snowflake или Databricks) регистрируется с безопасными регистрационными данными и политиками управления.
• Data 360 публикует общий доступ; администраторы Snowflake/Databricks принимают его.
• Общедоступные данные отображаются на складе как безопасные таблицы только для чтения.
• Аналитики, инструменты BI или ожидаемые продажи ML запрашивают оперативные объединенные данные клиентов без копирования или синхронизации.
• Все доступы проверяются в рамках Data 360 Trust Layer и журналов управления складом.

Результаты

• Внешние склады получают доступ к гармонизированным данным Data 360 в режиме реального времени.
• Устраняет обратные ожидаемые продажи ETL, снижая операционную нагрузку и задержку.
• Включает обучение на основе искусственного интеллекта/ML, прогнозируемое моделирование и расширенные BI напрямую на основе объединенных данных.
• Поддерживает нулевое дублирование, эффективное управление и безопасный по умыслу контроль доступа.
• Завершение двустороннего цикла «Нулевая копия», где входящее объединение и исходящий общий доступ сосуществуют в единой модели управления.

Механизмы вызова

Механизм вызова зависит от решения, выбранного для внедрения этой схемы.

Обработка и восстановление ошибок

• Повторы подключения: Автоматические попытки для временного подключения или сбоев проверки подлинности между Data 360 и складом.
• Общая проверка: Недопустимые или несанкционированные конфигурации общего доступа закрываются на карантин в очереди проверки администратором.
• Отслеживание состояния синхронизации: Data 360 отображает статус оперативного общего доступа, задержку запроса и журналы доступа посредством панелей мониторинга мониторинга мониторинга мониторинга мониторинга.
• Отмена доступа: Администраторы могут мгновенно отозвать общий доступ, выключив доступ с двух концов без остаточных копий данных.
• Контрольный журнал: Все изменения конфигурации и доступа регистрируются для проверки соответствия.

Рекомендации по созданию эффективных решений

• Последовательная идентификация общего доступа: Каждая пара «Общий доступ к данным» и «Цель общего доступа к данным» имеет уникальный идентификатор, обеспечивающий точное управление и отслеживаемость доступа.
• Неизменяемые представления: Общедоступные объекты данных доступны только для чтения; потребители не могут менять состояние, обеспечивая детерминистские результаты и соответствие.
• Жизненный цикл общего доступа: Публикация общего доступа, отзыв и обновления являются атомарными операциями, выполненными полностью или откатными.
• Консистенция повтора: Когда данные Data 360 обновляются, запросы склада всегда возвращают последний последовательный снимок, исключая устаревшие считывания.

Рекомендации по безопасности

Безопасность лежит в основе всех аспектов общего доступа к нулевой копии:

• Проверка подлинности: Mutual Trust, созданный посредством OAuth 2.0, обмена секретными ключами или федерации удостоверений (OIDC).
• Шифрование: Данные, зашифрованные в пути (TLS 1.2+) и в дежурном режиме (AES-256).
• Контроль доступа: Полномочия на уровне объекта обеспечивают доступ с наименьшими правами; управляются уровнем Trust Data 360.
• Безопасность сети: Обмен данными происходит посредством личных ссылок сети, например, Salesforce Private Connect или API безопасного обмена данными.
• Метаданные управления: Каждый общедоступный объект содержит атрибуты родословной, классификации и согласия для полного отслеживания и соответствия нормативным требованиям.

Боковые панели

Своевременность

• Доступность в реальном времени: Общедоступные данные отображают последнее состояние Data 360 без задержек репликации.
• Свежесть запроса: Изменения в DMO или CIO мгновенно распространяются на общедоступные представления склада.
• Эластичность производительности: Раскрытие запроса динамически адаптируется к вычислительным ресурсам склада.
• Мониторинг: Панели мониторинга в реальном времени предоставляют общий доступ к показателям задержки и производительности запроса для обеспечения функционирования.

Объемы данных

• Масштабируемый общий доступ: Поддерживает детализированный общий доступ к данным на уровне объекта или полного домена, в зависимости от аналитических потребностей.
• Оптимизированная производительность запроса: Snowflake/Databricks кэшируют общедоступные данные интеллектуально, чтобы минимизировать задержку.
• Эффективность хранения: Нулевое дублирование исключает избыточные затраты на хранение.
• Параметр интеграции файлов: В наборах данных в петабайтном масштабе прямой общий доступ на основе айсберга обходит вычисления и ускоряет доступ.

Управление государством

• Эволюция схемы: Схемы под управлением версии обеспечивают совместимость при развитии модели Data 360.
• Отслеживание состояния доступа: Активные/неактивные состояния общего доступа, поддерживаемые в Data 360 для управления жизненным циклом.
• Синхронизация метаданных: Обновления определений общедоступных объектов автоматически отображаются в каталогах складов в нисходящем направлении.
• Неизменяемая государственная гарантия: Представления склада всегда представляют последовательное состояние данных Data 360 во времени.

Сложные сценарии интеграции

• Гибридный режим: Сочетайте Zero Copy (для оперативной федерации) с приемом (для архивных наборов данных).
• Доступ между складами: Data 360 может поступать от нескольких клиентов Snowflake или Databricks в одной организации.
• Интерактивность искусственного интеллекта/БИ: Внешние системы (например, SageMaker, Tableau, Power BI) могут запрашивать обогащенные профили Data 360 обратно посредством обратной нулевой копии.
• Расширение интеграции файлов: Предприятия, использующие форматы открытых озер (Айсберг/Дельта), могут объединять структурированные и неструктурированные данные в рамках одной федеративной модели.

Пример

Кросс-облачная аналитика позволяет организациям объединять управляемые данные Salesforce Data 360 с собственными наборами данных в таких платформах, как Snowflake и Databricks, для предоставления полного, полного аналитического представления. С помощью многопользовательского доступа разные бизнес-единицы могут безопасно использовать рекомендованные и управляемые политикой сегменты данных посредством отдельных общих доступов без дублирования данных. Специалисты по обработке данных могут потом выполнять интегрированное искусственное интеллектуальное и компьютерное обучение, обучая модели напрямую в объединенных профилях клиентов в средах Snowflake ML или Databricks MLflow. На протяжении всего этого процесса встроенные возможности создания строк, управления и аудита обеспечивают соответствие всех доступов к данным и их использования политикам предприятия и нормативным требованиям, например GDPR и HIPAA.

Data Cloud One позволяет организациям с несколькими организациями Salesforce (например, из-за бизнес-единиц, регионов, товарных позиций или приобретений) предоставлять общий доступ к одному центральному экземпляру Data 360. Эта организация выступает в качестве «начальной организации», в то время как другие организации, называемые «организациями-компаньонами», имеют доступ к этим объединенным данным и могут обрабатывать их, не прилагая особых усилий, не используя настраиваемый код и все средства управления.

Контекст

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

Проблема

Как компания может обеспечить последовательное использование объединенных данных Customer 360, принимаемых, гармонизированных и управляемых Data 360 домашней организации, во всех организациях Salesforce (чтобы все они использовали одни и те же базовые данные), избегая при этом дублирования усилий, настраиваемого кодирования, отдельных экземпляров Data 360 на организацию и пробелов в управлении?

Силы

Эта схема вводит несколько рекомендаций по архитектуре, безопасности и производительности:

• Сложность нескольких организаций: В организации каждой бизнес-единицы могут быть разные данные, настраиваемые объекты, безопасность и процессы - поддерживать последовательные объединенные представления тяжело.
• Дублирование и стоимость: Выполнение отдельного экземпляра Data 360 на организацию означает дополнительную настройку, дополнительное управление, дополнительное лицензирование и риск хранения данных.
• Управление и управление общим доступом к данным: Вам нужно решить, какие данные может просматривать и обрабатывать каждая организация-компаньон - вы не можете просто предоставить общий доступ ко всему без риска управления.
• Скорость настройки: Группы по маркетингу, продажам или обслуживанию не могут неделями ждать, пока настраиваемый код предоставит доступ к данным межорганизационной организации, им нужны решения с нажатием кнопки «Настроить».
• Резиденция данных, региональные рекомендации: Если домашние организации и организации-компаньоны находятся в разных регионах, могут существовать юридические или нормативные ограничения относительно места хранения данных или способа их предоставления.

Решение

Следующая таблица содержит разные решения этой проблемы интеграции.

Эскиз

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

В этом сценарии:

• Администратор: создайте пространство данных и определите общий доступ к данным (выберите DMO/CIO, сегменты).
• Администратор: создайте цель общего доступа к данным для организации (организаций) компаньона и настройте Trust (клиент OAuth, разрешенные коды организации).
• Администратор: опубликуйте общий доступ к данным для цели; вложите политики ABAC (CEDAR) и элементы управления шифрованием/ключами (CMK, при необходимости).
• Администратор организации-компаньона: получает приглашение, проверяет соотнесение удостоверений и принимает общий доступ.
• Организация-компаньон: Data Cloud One Bridge инициализирует пользователя Data Cloud One и применяет доступность наборов полномочий и пространства данных.
• Приложения организации-компаньона (Flows / Einstein / Apex): Запросите график данных или вызовите Data Cloud One API для чтения общедоступных DMO или сегментов.
• Активация: Организация-компаньон запускает активацию или выполняет обратную запись посредством действий над данными (если это разрешено).

Результаты

• Единый источник истины для данных клиентов (Custer 360) во всех подключенных организациях — отсутствие избыточных экземпляров Data 360.
• Более быстрое время доступа к объединенным данным и функциям Data 360 в настраиваемом кодировании.
• Управляемый общий доступ к данным. Общий доступ предоставляется только к авторизованным пространствам данных, что обеспечивает безопасность и управление при одновременном повышении гибкости бизнеса.
• Бизнес-функции (продажи, обслуживание, маркетинг) функционируют на одном объединенном фундаменте данных, обеспечивая согласованные показатели, активацию и важные данные на предприятии.

Механизмы вызова

Механизм вызова зависит от решения, выбранного для внедрения этой схемы.

Обработка и восстановление ошибок

• Устойчивость межорганизационной синхронизации: Data Cloud One автоматически повторяет неудачные задания синхронизации между начальной организацией и организацией-компаньоном посредством экспоненциального резервирования для ошибок транзиторной сети или платформы.
• Частичная пакетная изоляция: Ошибочные пакеты записей помещаются на карантин в очереди повторных попыток в начальной организации до успешной сверки, предотвращая расхождение данных.
• Управление отклонением схемы: Несоответствия схемы или соотнесения перенаправляются в очередь отклонения схемы для проверки и исправления администратором.
• Повтор и возобновление непрерывности: Каждое задание синхронизации поддерживает смещенные контрольные точки, поэтому репликация может возобновиться после последнего успешного подтверждения без дублирования.
• Комплексный мониторинг: Все сбои, попытки и показатели восстановления собираются в панели мониторинга Trust Layer Monitoring для доступности и обеспечения SLA.

Рекомендации по созданию эффективных решений

• Детерминистские ключи демпотентности: Каждое событие синхронизации содержит уникальный ключ (код организации + код записи + номер версии), гарантирующий точную обработку.
• Безопасность повтора: Повторяющиеся или воспроизведенные события фильтруются во время подтверждения, обеспечивая последовательность последующих обновлений DMO и CIO.
• Atomic Commit Semantics: Организации-компаньоны помечают данные как принятые только после успешной последующей записи, сохраняя целостность транзакций между организациями.
• Разрешение конфликта: Мультиисточники обновлений следуют логике слияния под управлением последней записи или политики, сохраняя родословную и последовательность.
• Постоянство контрольной точки: Задания синхронизации сохраняют смещения последней обработки и состояние в слое Trust для безопасного восстановления и повтора.

Рекомендации по безопасности

• Сильная проверка подлинности: Подключения между начальной организацией и организацией-компаньоном используют взаимный OAuth 2.0 с автоматически ротируемыми маркерами, управляемыми посредством связанных приложений.
• Гранулированная авторизация: Организации-компаньоны имеют доступ только к определенным пространствам данных, DMO или CIO, явно общедоступным посредством управляемых политик общего доступа к данным.
• Повсеместное шифрование: Данные шифруются в пути (TLS 1.2+) и в дежурном режиме (AES-256), как на начальной странице, так и в организациях-компаньонах.
• Принцип наименьших прав: Пользователи интеграции ограничены только обязательными объектами; полномочия администратора или системы не распространяются.
• Доступность проверки и соответствия: Все события синхронизации, изменения схемы, обновления регистрационных данных и предоставление доступа регистрируются в слое Data 360 Trust для полной отслеживаемости.
• Изоляция частной сети: Дополнительные Salesforce Private Connect или Private Link обеспечивают репликацию данных только по защищенным внутренним каналам.

Боковые панели

Своевременность

• Синхронизация между начальной организацией и организацией-компаньоном происходит в близком к реальному режиме времени, обычно в течение нескольких секунд после изменения данных в исходной организации.
• Архитектура Zero Copy обеспечивает мгновенный запрос общедоступных данных во всех участвующих организациях — без задержек репликации или пакетирования.
• Задания активации и сегментации автоматически отображают последние обновления из любой подключенной организации, поддерживая оперативную свежесть.
• Сквозная задержка является детерминистской и регулируется ожидаемыми продажами оркестрации Data Cloud One, обеспечивая последовательную межорганизационную своевременность даже под нагрузкой.

Объемы данных

• Предназначена для синхронизации данных в гипермасштабных масштабах между регионами и бизнес-единицами с несколькими клиентами, способна управлять миллиардами записей на организацию.
• Данные ссылаются, а не дублируются, уменьшая выброс хранилища при сохранении глобальной доступности запросов.
• Потоковые дельты и уплотнение метаданных оптимизируют пропускную способность и накладывают обязательства для объектов с высокой скоростью изменения (например, контакт, заказ).
• Масштабируется горизонтально в нескольких организациях-компаньонах с адаптивной балансировкой нагрузки и оркестрацией посредством слоя Trust.

Управление государством

• Каждый синхронизированный набор данных поддерживает взаимосвязь метаданных, версию и контекст ответственности организации, чтобы обеспечить комплексное отслеживание.
• Постоянство контрольной точки собирает последние синхронизированные смещения между организациями, что позволяет восстановить данные без дублирования.
• Версии схемы и семантическое выравнивание в организациях автоматически регулируются слоями Trust.
• Сбросы состояния вручную не требуются — состояние синхронизации поддерживается посредством службы оркестрации Data Cloud One.

Сложные сценарии интеграции

• Межорганизационная федерация: Включает безупречный запрос и активацию в нескольких клиентах или регионах Data 360 в рамках единой модели управления.
• Гибридная синхронизация: Сочетает репликацию в близком к реальному режиме времени для транзакционных обновлений с запланированной синхронизацией для пакетных или архивных данных.
• Управление несколькими регионами: Поддерживает географически распределенный общий доступ к данным при соблюдении границ проживания, согласия и соответствия.
• Активация искусственного интеллекта и автоматизации: Синхронизированные данные мгновенно питают Einstein AI, Agentforce или настраиваемые модели ML в организациях — включив интеллект в реальном времени, межорганизационный интеллект.

Пример

Глобальная организация розничной торговли имеет три организации Salesforce: одну для Consumer Retail, одну для Premium Brands и одну для международных рынков. Они предоставляют Data 360 в организации Consumer Retail (что делает ее домашней организацией). С помощью Data Cloud One они настраивают сопутствующие подключения к премиальным торговым маркам и организациям международных рынков. Они используют только соответствующие пространства данных (например, Customer 360 — Retail Profiles и Customer 360 — Premium Profiles) с каждой сопутствующей организацией. В организации премиальных фирменных стилей маркетинговые группы могут просматривать объединенные профили клиентов, создавать сегменты на основе вычисленных важных данных (например, ценность срока действия премиального клиента) и запускать маркетинговые автоматизации — все на основе экземпляра Data 360 домашней организации без настраиваемого кодирования или дублирования данных.

Активация данных — это область, где значение Salesforce Data 360 действительно оживает. Это процесс получения объединенных, обогащенных и управляемых данных, живущих внутри платформы, и обеспечения их работы в бизнесе. На практике это означает безопасную доставку рекомендованных сегментов, вычисленных важных данных и контекстуальных атрибутов из Data 360 в системы, вовлекающие клиентов, будь то автоматизация маркетинга, сервисные консоли, возможность продаж, аналитика или модели на основе искусственного интеллекта. С технической точки зрения, схемы активации определяют, как эти данные перемещаются: какие каналы запускаются, какие трансформации или соотнесения происходят и как политики внедряются на пути. Эти схемы касаются не только экспорта данных, но и оркестрации потоков данных в реальном времени с учетом политики, которые определяют измеримые бизнес-результаты. Каждый маршрут активации превращает Customer 360 в оперативный актив — силовая персонализация, прогнозируемое принятие решений и постоянное обучение в каждой точке касания.

Пакетная активация остается самым распространенным и проверенным методом экспорта данных из Data 360. Он работает в запланированной каденции — публикует предопределенные сегменты аудитории или наборы атрибутов на последующих платформах через регулярные интервалы. Эта схема идеально подходит для бизнес-процессов маркетинга и занятости, которые зависят от последовательной массовой доставки аудитории, а не мгновенных обновлений. Типичными сценариями использования являются активация электронных путешествий, прямых почтовых кампаний или загрузки аудитории в цифровые рекламные сети. Каждый запуск активации извлекает соответствующий сегмент из графика объединенного профиля Data 360, применяет политики управления и согласия и безопасно передает вывод в целевую систему. Архитектурно пакетная активация предоставляет предсказуемый, проверяемый и эффективный подход к распространению данных — баланс между операционной простотой и надежностью корпоративного уровня. Это основа масштабного выполнения кампании, где правильные данные, доставленные вовремя и под контролем, дают ощутимое влияние на бизнес.

Контекст

Современные маркетологи работают в нескольких каналах занятости - электронной почте, рекламе, мобильном и веб-взаимодействии, каждый из которых требует точной, своевременной и персонализированной аудитории клиентов. Data 360 служит объединенной основой для этих аудиторий, объединяя данные клиентов из каждой системы в насыщенные, действенные сегменты. Пакетная активация - это наиболее распространенная схема активации, используемая для экспорта этих сегментов из Data 360 на маркетинговые или рекламные платформы в нисходящем направлении. Типичными целями являются Marketing Cloud Engagement, Google Ads, Meta Custom Audiences или LinkedIn Ads, где кампании могут выполняться напрямую против этих курируемых аудиторий.

Проблема

Как группа маркетинга может взять точно определенную аудиторию, созданную с использованием объединенных и обогащенных данных в Data 360, и предоставить к ней доступ во внешних маркетинговых или рекламных системах для активации? Например, рассмотрим сегмент: «Ценные клиенты, не покупавшие за последние 90 дней, но недавно задействовавшие веб-сайт». Маркетологи должны обеспечить корректное перемещение аудитории, пополнение ее соответствующими атрибутами (например, уровень лояльности, регион или прогнозируемый CLV) и регулярное обновление для поддержания актуальности и эффективности кампании.

Силы

Схема пакетной активации определяется несколькими техническими и операционными факторами:

• Соотнесение удостоверений: Точная доставка аудитории требует соотнесения кода объединенного отдельного лица Data 360 с соответствующим идентификатором в целевой системе, например, ключ подписчика в Marketing Cloud или хэшированная электронная почта для цифровых рекламных платформ. Это обеспечивает точное совпадение и исключает ошибки прицеливания.
• Выбор атрибутов и пополнение: Маркетологи должны выйти за рамки кодов и добавить дополнительные данные профиля (например, личное имя, статус лояльности, CLV или другие персонализированные атрибуты), чтобы включить персонализацию и аналитику в нисходящем направлении.
• Целевая конфигурация платформы: Каждое назначение должно быть зарегистрировано в Data 360 в качестве цели активации, включительно со сведениями о подключении, проверкой подлинности и соотнесениями полей данных. Эта одноразовая настройка определяет безопасное подключение и определяет, какие системы могут принимать активированные данные.
• Управление и соблюдение: Активация данных должна соответствовать метаданным согласия, политикам конфиденциальности (например, GDPR или CCPA) и маркетинговым полномочиям, сохраненным в объединенном профиле. Активация с согласием обеспечивает использование данных только для авторизованных целей.
• Планирование и производительность: Активации часто запланированы ежедневно или ежечасно, чтобы поддерживать актуальность аудитории в нисходящем направлении. Система должна эффективно обрабатывать большие объемы и инкрементные обновления без дублирования или потери данных.

Решение

Процесс пакетной активации в Data 360 следует пошаговому бизнес-правилу, которое минимизирует технические трения для маркетологов, сохраняя управление и масштабируемость:

Эскиз

Ниже указана сводка этапов:

• Создание сегмента: Маркетолог или аналитик создает сегмент посредством визуального инструмента сегментации, объединяя фильтры по всем объединенным объектам данных.
• Создать активацию: Они выбирают сегмент в качестве источника и выбирают готовую цель (например, Marketing Cloud или Google Ads).
• Определение полезной нагрузки: Идентификатор контакта и другие атрибуты профиля выбираются для экспорта аудитории и составления отчетов.
• Запланировать доставку: Активация запланирована на выполнение один раз или на регулярной основе, чтобы поддерживать актуальность аудитории в цели.
• Выполнение: При запуске Data 360 запрашивает сегмент, создает полезные данные, применяет фильтры для согласия и проталкивает результат в целевую систему.

Результаты

• Целевые, обогащенные сегменты аудитории из Data 360 доступны напрямую на последующих маркетинговых и рекламных платформах.
• Аудитории автоматически обновляются и синхронизируются с последними объединенными данными клиентов, сохраняя актуальность кампании в реальном времени.
• Маркетологи могут использовать эти активированные аудитории в качестве источников входа для путешествий Marketing Cloud, кампаний электронной почты или настраиваемых аудиторий в цифровых рекламных платформах, например, Google Ads, Meta или LinkedIn Ads.
• Каждый запуск активации сохраняет сквозную линию, обеспечивая соответствие, отслеживаемость и согласованность между Data 360 и внешними системами.
• Бизнес-пользователи могут предоставлять высокоперсонализированные, управляемые данными взаимодействия, поддерживаемые полным и надежным представлением Customer 360.

Механизмы вызова

Механизм вызова зависит от целевой платформы и конфигурации цели активации.

Обработка и восстановление ошибок

• Изоляция ошибки уровня задания: Каждый запуск активации выполняется как отдельное отслеживаемое задание в слое оркестрации Data 360. Неудачные запуски автоматически закрываются на карантин, не влияя на другие активации или определения сегментов.
• Частичное пакетное восстановление: Если определенные записи не экспортируются (например, из-за несоответствий идентификаторов или ограничений по частоте API), система повторяет их с помощью инкрементных дельта-очередей с экспоненциальным отступлением и параллельным восстановлением.
• Ошибки проверки схемы: Если исходящие атрибуты полезных данных больше не соответствуют целевой схеме (например, удаленный атрибут или переименованное поле), маршрутизация заданий влияет на записи в очередь отклонения схемы для проверки администратором.
• Поддержка повтора и возобновления: Каждое задание активации сохраняет маркер контрольной точки, собирая последний успешный пакет. После восстановления обработка возобновляется из контрольной точки, исключая дублирование или потерю данных.
• Комплексный мониторинг: Все события активации, попытки и показатели доставки регистрируются в Trust Layer Monitoring, включая отслеживание SLA, анализ первопричин и автоматическое оповещение посредством Event Monitoring API.

Рекомендации по созданию эффективных решений

• Детерминистские ключи активации: Каждый запуск активации использует составной ключ импотентности, сочетающий код сегмента, код активации и код целевой системы, чтобы гарантировать точную доставку.
• Обнаружение повтора: Служба активации Data 360 проверяет входящие полезные данные относительно предыдущих хэшей заданий для обнаружения и подавления повторов.
• Атомные обязательства экспорта: Полезные данные передаются в целевую систему только после успешного подтверждения записи, предотвращая частичные обновления или двойной счет.
• Последовательная разрешающая способность при опознавании: Поскольку активации зависят от объединенных кодов (например, объединенное отдельное лицо), повторы или попытки всегда нацелены на одну золотую запись, сохраняя смысловую последовательность.
• Постоянство состояния активации: Слой оркестрации сохраняет метаданные состояния активации - отметки времени, коды статусов и маркеры последовательности - для детерминистской повторной обработки при необходимости.

Рекомендации по безопасности

• Сильная проверка подлинности: Каждая цель активации (например, Marketing Cloud, Ads или CRM) использует OAuth 2.0 с ротацией маркера и масштабированием клиента для предотвращения несанкционированного экспорта данных.
• Управление на уровне атрибутов: Активации подлежат только утвержденные атрибуты из объединенного профиля, применяемые политиками общего доступа к данным и шаблонами активации.
• Шифрование в пути и в дежурном режиме: Все полезные данные шифруются посредством TLS 1.2+ во время передачи и AES-256 в дежурном режиме в Data 360 и целевой платформе.
• Согласие и применение политики: Задания активации учитывают объекты согласия и политики данных, сохраненные в слое Trust Data 360. Записи без действительных метаданных согласия автоматически исключаются из экспорта.
• Регистрация проверки и соответствия: Каждый запуск активации собирает, кто ее инициировал, какие данные были отправлены и куда они были направлены - включение полных контрольных журналов регулирования (GDPR, CCPA) в панели мониторинга уровня Trust
• Доступ с наименьшими правами: Пользователи интеграции для каждой цели ограничены областями активации — без административных полномочий или доступа записи к несвязанным системам.

Боковые панели

Своевременность

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

Объемы данных

• Обрабатывает крупномасштабные наборы данных (миллионы записей за запуск).
• Масштабирование по горизонтали посредством разделения сегментов и параллельных каналов экспорта.
• Использует пакетирование на основе фрагментов во избежание истечения срока действия и оптимизации производительности.
• идеально подходит для ожидаемых продаж данных корпоративного уровня, где полнота данных является критической.

Управление государством

• Обслуживает объекты состояния активации, записывающие коды заданий, отметки времени и маркеры последовательности.
• Использует контрольные точки для повторной запуска и восстановления ошибок.
• Версионные определения сегментов обеспечивают воспроизводимость в циклах активации.
• Включает отслеживание линии между исходным сегментом, атрибутами DMO и целевыми полезными нагрузками.

Сложные сценарии интеграции

• Безупречная интеграция с Salesforce CRM, Marketing Cloud и внешними системами посредством готовых коннекторов.
• Поддерживает многоцелевые активации, распространяя данные одновременно в разных местах назначения (например, CRM + Ads).
• Может инициировать составные бизнес-правила, например, пакетный экспорт с последующим вызовом API в нисходящем направлении или определением рейтингов на основе искусственного интеллекта.
• Обрабатывает эволюцию схемы изящно посредством слоя управления моделью данных.

Пример

Мировой розничный бренд хочет повторно привлечь неактивных клиентов за последние 90 дней. Используя Data 360, архитектор данных определяет сегмент «Неактивные покупатели», обогащенный журналом покупок, уровнем лояльности и метаданными согласия. Пакетное задание активации выполняется ночью, перенося этот сегмент в Marketing Cloud Engagement для запуска персонализированной кампании электронной почты «Нам вас не хватает» и в Ad Studio для повторной нацеливания. Задача использует неэффективную доставку, исключая дублирование при повторных попытках, и все события регистрируются в слое Trust для соответствия аудиту.

Контекст

Предприятиям часто требуется управляемый механизм для экспорта объединенных или сегментированных данных из Salesforce Data 360 в стандартный формат файла (например, CSV или Parquet) для архивирования, соответствия или последующей интеграции. Эта схема включает экспорт хранилища Data 360 в облачное хранилище, что позволяет надежным данным клиентов безопасно поступать в озера данных предприятия или ожидаемые продажи аналитики, размещенные в Amazon S3, Azure Blob или Google Cloud Storage (GCS). Типичные сценарии использования включают:

• Периодическое архивирование согласованных наборов данных клиентов для сохранности в регламенте.
• Экспорт рекомендованных сегментов для аналитических нагрузок, не связанных с Salesforce (например, Tableau, Databricks или Power BI).
• Включение внешних моделей компьютерного обучения, требующих структурированных CSV-файлов или файлов паркета в качестве вводных данных.

Проблема

Как организация может экспортировать контролируемый, безопасный и автоматизированный сегмент или набор данных из Data 360 в область облачного хранилища (например, Amazon S3), сохраняя целостность схемы и контроль соответствия? Например, группе по соблюдению может понадобиться следующее: «Извлеките всех активных клиентов в регионе ЕС с действительного согласия и экспортируйте данные еженедельно в расположение S3 для внешнего аудита и отчетности». Это требует повторяемых и политически осведомлённых экспортных ожидаемых продаж, которые обеспечивают корректный формат файла, полномочия доступа и расписание доставки, без ручного вмешательства или неуправляемого перемещения данных.

Силы

Эта схема экспорта определяется несколькими операционными и архитектурными факторами:

• Проверка подлинности и авторизация: Экспорты должны соответствовать модели IAM поставщика облачных технологий (например, «Роли AWS IAM» или «Основные компоненты службы Azure»), чтобы обеспечить возможность записи в целевой сегмент только авторизованными системами.
• Выравнивание схемы: Исходящая схема должна соответствовать ожидаемой структуре и формату целевой системы (CSV, паркет или JSON).
• Конфиденциальность данных и согласие: Экспортированные наборы данных должны фильтровать записи, не содержащие действительных метаданных согласия.
• Планирование и свежесть: Многие экспорты являются периодическими (ежедневными, еженедельными или ежемесячными) и должны соответствовать циклам обновления данных предприятия.
• Управление и мониторинг: Каждый экспорт должен быть аудируемым при полной видимости по линиям, обеспечивая соблюдение требований к сохранению данных и нормативных положений (например, GDPR, CCPA).

Решение

Схема активации экспорта файла повторно использует те же безопасные коннекторы облачного хранилища, которые используются для приема, но настроены для выхода данных. Сначала администраторы регистрируют платформу облачного хранилища (например, Amazon S3, Azure Blob Storage или GCS) в качестве цели активации в Data 360. Потом пользователи настраивают и выполняют бизнес-правило активации для экспорта нужного сегмента в указанный путь хранилища файлов.

Эскиз

Ниже указана сводка этапов.

• Выбрать сегмент: Аналитик или распорядитель данных выбирает объединенный сегмент для экспорта.
• Создать активацию: Они создают новое задание активации и выбирают зарегистрированную цель облачного хранилища.
• Определение полезной нагрузки: Укажите схему экспорта, список атрибутов и формат файла (например, CSV).
• Запланировать экспорт: Выберите одноразовое или повторяющееся расписание.
• Выполнить задание: Data 360 создает и безопасно доставляет файл в указанный путь области.
• Отслеживание и проверка: Результаты и журналы проверяются в слое Trust для проверки и соответствия.

Результаты

• Целевые, обогащенные сегменты аудитории из Data 360 доступны напрямую на последующих маркетинговых и рекламных платформах.
• Аудитории автоматически обновляются и синхронизируются с последними объединенными данными клиентов, сохраняя актуальность кампании в реальном времени.
• Маркетологи могут использовать эти активированные аудитории в качестве источников входа для путешествий Marketing Cloud, кампаний электронной почты или настраиваемых аудиторий в цифровых рекламных платформах, например, Google Ads, Meta или LinkedIn Ads.
• Каждый запуск активации сохраняет сквозную линию, обеспечивая соответствие, отслеживаемость и согласованность между Data 360 и внешними системами.
• Бизнес-пользователи могут предоставлять высокоперсонализированные, управляемые данными взаимодействия, поддерживаемые полным и надежным представлением Customer 360.

Механизмы вызова

Механизм вызова зависит от целевой платформы облачного хранилища и конфигурации активации.

Обработка и восстановление ошибок

• Изоляция уровня задания: Каждый экспорт выполняется как отдельное задание. Неудачные задания закрываются на карантин и пробуются самостоятельно.
• Частичная попытка файла: Если определенные пакеты не загружаются (например, из-за прерывания сети), система повторно использует экспоненциальные резервные копии.
• Обработка несоответствия схемы: Любое отклонение схемы или несоответствие полей перенаправляет записи в очередь отклонения схемы для проверки.
• Checkpoint & Resume: Задания экспорта сохраняют метаданные контрольной точки, что позволяет возобновить последнюю успешную запись без дублирования.
• Комплексный мониторинг: Ошибки и попытки регистрируются в панели мониторинга Trust Layer для доступности и соответствия SLA.

Рекомендации по созданию эффективных решений

• Детерминистские ключи экспорта: Каждое задание экспорта содержит уникальный код, состоящий из кода сегмента + код цели + отметка времени.
• Безопасность повтора: Повторы выполнения заданий обнаруживаются посредством хэшей заданий и пропускаются для предотвращения избыточных экспортов.
• Гарантия автоматической записи: Data 360 обязует файлы в целевом сегменте только после полного завершения и проверки контрольной суммы.
• Последовательная версия схемы: Определения экспорта контролируются версиями для обеспечения согласованности схемы во время выполнения.
• Постоянство контрольной точки: Экспорт заданий сохраняется для детерминистского восстановления и повторной обработки при необходимости

Рекомендации по безопасности

• Сильная проверка подлинности: Облачные коннекторы используют роли OAuth 2.0, IAM или сервисные субъекты для проверенных записей.
• Повсеместное шифрование: Данные шифруются как в пути (TLS 1.2+), так и в дежурном режиме (AES-256).
• Экспорт с согласием: Экспортируются только записи с действительным согласием, применяемые политиками Trust Layer.
• Принцип наименьших прав: Экспорт пользователей и учетных записей службы ограничен указанными путями хранения.
• Комплексная регистрация аудита: Каждые метаданные экспортных записей, включая инициатора, схему, цель и отметки времени для отчетов о соответствии.

Боковые панели

Своевременность

• Предназначен для немедленной активации под управлением событий с субсекундной задержкой.
• идеально подходит для сценариев, требующих мгновенной персонализации, рекомендации или принятия решения.
• Работает в потоковом режиме — триггеры запускаются, как только в Data 360 происходят соответствующие изменения данных.
• Обеспечивает постоянную оперативность, не дожидаясь пакетных расписаний или повторных расчетов сегментов.

Объемы данных

• Обрабатывает крупномасштабные наборы данных (миллионы записей за запуск).
• Масштабирование по горизонтали посредством разделения сегментов и параллельных каналов экспорта.
• Использует пакетирование на основе фрагментов во избежание истечения срока действия и оптимизации производительности.
• идеально подходит для ожидаемых продаж данных корпоративного уровня, где полнота данных является критической.

Управление государством

• Каждое действие события сохраняет собственный маркер события и код повтора для идемпотентной обработки.
• Поддерживает сохранение контрольной точки для возобновления от последнего события обязательства в случае временного сбоя.
• Содержит встроенную логику дедупликации и окна воспроизведения для обеспечения точной семантики активации.
• Результаты действий (успех/сбой) регистрируются в режиме реального времени и отображаются в панели мониторинга Trust Layer.

Сложные сценарии интеграции

• Интегрируется напрямую с потоками Salesforce, событиями платформы Einstein 1 или внешними вебхуками для цепочек мгновенных ответов.
• Может инициировать автоматизацию в нисходящем направлении, например, мгновенные обновления записей CRM, определение рейтингов на основе искусственного интеллекта или отправки сообщений Marketing Cloud.
• Поддерживает составную оркестрацию: триггеры событий могут вызывать действия Data 360, вызовы Apex или внешние API.
• Предназначено для агентских и адаптивных корпоративных схем, где контекстные ответы должны происходить мгновенно.

Пример

Глобальное розничное предприятие должно еженедельно экспортировать сегмент «Активные участники лояльности» для анализа в Databricks. Администратор Data 360 настраивает Amazon S3 в качестве цели активации и планирует еженедельный CSV-экспорт в путь s3://enterprise-analytics/loyalty/weekly_exports/. Задание экспорта выполняется каждое воскресенье, создавая отфильтрованный по согласию файл с записями 2M+. Все события, определения схемы и родословная записываются в панель мониторинга Trust Layer, обеспечивая прозрачность, проверяемость и соответствие.

Активация на основе API по запросу - это управляемый событиями подход в реальном времени, позволяющий активировать важные данные Data 360 в нужный момент, не дожидаясь пакетных заданий или запланированных экспортов. Вместо публикации готовых сегментов в фиксированной каденции, эта схема позволяет внешним системам, приложениям Salesforce или агентам искусственного интеллекта напрямую вызывать Data 360 API для извлечения или активации определенных сегментов аудитории, атрибутов клиентов или важных данных по запросу. Эта схема создана для интерактивных взаимодействий на основе триггеров, например, когда пользователь входит на портал, агент открывает запись клиента или второй пилот на основе искусственного интеллекта инициирует запрос Next-Best- Action. Вместо использования предварительно вычисленных экспортов система динамически запрашивает или активирует самые актуальные управляемые данные из Data 360 в режиме реального времени. Ключевым преимуществом является непосредственность и точность:

• Каждый вызов API открывает самый последний Аналитику клиентов в объединенном графике профиля Data 360 с согласием.
• Активации идемпотентны и проверяемы, соответствуют требованиям Enterprise Trust и соответствия.
• Интеграции можно запустить напрямую из потоков Salesforce, Apex или внешних систем посредством API платформы Einstein 1, Connect API или API активации. Этот метод поддерживает сценарии использования, где задержка и персонализация наиболее важны, например:
• Запуск персонализированного предложения продукта во время сервисного вызова.
• Создание динамических аудиторий кампаний на основе оперативных поведенческих событий.
• Лента решений в реальном времени в модели на основе искусственного интеллекта или ML, действующие в момент занятости.

Контекст

Предприятиям часто нужно публиковать согласованные важные данные Data 360 в реальном времени в настраиваемых приложениях, например, на внутренних веб-порталах, в мобильных приложениях или в веб-взаимодействии с партнерами. Эта схема позволяет разработчикам создавать безопасные, ориентированные на пользовательский интерфейс решения, которые потребляют и отображают объединенные данные клиентов наряду с Salesforce CRM и другими контекстуальными системами, используя управляемый и API-доступ. Типичные сценарии использования включают:

• Встраивание важных данных Data 360 во внутренние панели мониторинга сотрудников или мобильные приложения.
• Создание партнерских или дилерских порталов с доступностью клиентов и транзакций.
• Интеграция данных Data 360 в сторонние веб-приложения или слои взаимодействий.
• Отображение в реальном времени персонифицированных рекомендаций на основе Data 360 и Einstein 1.

Проблема

Как разработчик может создать настраиваемое приложение, ориентированное на пользовательский интерфейс, которое безопасно открывает и отображает гармонизированные данные Data 360, часто наряду с другими источниками данных Salesforce, без дублирования или экспорта конфиденциальной информации? Например, предприятию может понадобиться создать клиентский портал, отображающий объединенные профили клиентов, взаимодействия и вычисленные важные данные из Data 360. Это требует единого, безопасного и производительного уровня API, который может питать интерфейс, управлять проверкой подлинности и обеспечивать управление, отвлекая сложность внутренней модели данных Data 360.

Силы

На эту схему влияют многочисленные архитектурные и операционные соображения:

• Пользовательский интерфейс: Основная цель — опубликовать данные в настраиваемых интерфейсах (веб- или мобильных), а не выполнять пакетное извлечение или интерфейсную синхронизацию.
• Безопасный шлюз: Выбранный API должен служить безопасной и масштабируемой точкой входа для проверенных приложений и пользователей, внедряя средства управления доступом корпоративного уровня.
• Контекст объединенных данных: Приложения должны иметь возможность беспрепятственно сочетать данные Data 360 (например, объединенные профили, вычисленные важные данные) с данными CRM, ERP или настраиваемого объекта.
• Простота разработчика: API должны возвращать полезные данные презентации, которые минимизируют фоновую обработку или соотнесение схем в слое клиента.
• Управление и наблюдаемость Все доступы должны поступать через надежные, проверяемые каналы с четкой линией, проверкой подлинности и внедрением политик.

Решение

Решением является использование Salesforce Connect REST API в качестве основного шлюза интеграции для создания настраиваемых приложений на основе данных поверх Data 360. Connect API предоставляет RESTful-доступ к данным Salesforce, включительно с гармонизированными профилями Data 360, сегментами и вычисленными важными данными, в форматах ответов, оптимизированных для потребления пользовательского интерфейса (на основе JSON, легких и мобильных устройств). Разработчики проверяют подлинность посредством связанного приложения, получают маркеры OAuth 2.0 и вызывают ресурсы Connect API, например, /query, /chatter или /data, чтобы опубликовать объединенные данные напрямую в интерфейсах приложения. В фоновом режиме Connect API служит транспортной основой для других API — например, Query API, Data Graph API и API платформы Einstein 1, что позволяет разработчикам объединять несколько источников данных в одной объединенной схеме доступа.

Эскиз

Ниже указана сводка этапов.

• Регистрация связанного приложения — определение областей OAuth и полномочий API для проверки подлинности внешнего приложения.
• Получение маркера доступа — внешнее приложение выполняет проверку подлинности OAuth 2.0 для получения маркера доступа Data 360.
• Вызов Connect API — приложение выполняет вызовы REST API для извлечения данных объединенного профиля, сегмента или важных данных.
• Предоставление данных в пользовательском интерфейсе — ответы анализируются и отображаются пользователям на фирменном портале или в мобильном интерфейсе.
• Ошибки обработки и маркеры обновления — приложения внедряют логику повтора попытки и автоматическое обновление маркера для обеспечения непрерывности сеанса.
• Monitor & Audit Access: все вызовы API регистрируются в слое Trust для доступности и соответствия.

Результаты

Разработчики могут создавать безопасные настраиваемые фирменные приложения, тесно интегрированные в Data 360. Данные приложения могут:

• Показывать гармонизированные профили клиентов и важные данные в реальном времени.
• Отображение данных Data 360 вместе с CRM или настраиваемыми объектами посредством объединенных API.
• Использование последовательной проверки подлинности, авторизации и контроля проверки подлинности посредством Trust Layer.
• Предоставьте бизнес-пользователям или партнерам беспрепятственный управляемый доступ к надежному Аналитике клиентов во взаимодействиях.

Механизмы вызова

Механизм вызова зависит от целевой платформы облачного хранилища и конфигурации активации.

Обработка и восстановление ошибок

• Запрос дроссельной заслонки: Автоматически отключается и выполняет повторные вызовы API в пределах тарифа.
• Защита от сбоя схемы: Использует версию схемы GraphQL или обнаружение метаданных REST для адаптации к изменениям схемы.
• Управление истечением срока действия маркера — приложения обновляют маркеры OAuth автоматически во избежание прерываний сеанса.
• API-изоляция ошибки — неудачные вызовы API регистрируются и повторяются без влияния на параллельные сеансы.
• Наблюдаемость Trust Layer — уровни успеха/сбоя API и журналы доступа отображаются на панели мониторинга Trust Layer.

Рекомендации по созданию эффективных решений

• Коды детерминистских запросов: Каждый запрос API содержит код корреляции для безопасной для повтора обработки.
• Заголовки проверки кэша: Заголовки тегов и «Последнее изменение» предотвращают избыточное извлечение данных.
• Атомные операции чтения: Connect API обеспечивает отображение в каждом ответе последовательного снимка объединенных данных.
• Защита повтора — повторяющиеся вызовы API фильтруются посредством подписей запросов и отметок времени.

Рекомендации по безопасности

• Проверка подлинности OAuth 2.0: Все вызовы API используют безопасные кратковременные маркеры доступа OAuth посредством связанных приложений.
• Доступ с наименьшими правами: Области API ограничены только необходимыми объектами и полями.
• Повсеместное шифрование: TLS 1.2+ в пути; шифрование AES-256 в дежурном режиме для кэшированных или сохраненных ответов.
• Доступ к данным с согласием: Data 360 обеспечивает соответствие всех извлеченных записей политикам согласия и управления.
• Комплексная регистрация аудита: Каждое взаимодействие API записывается с метаданными пользователя, приложения и отметки времени в слое Trust.

Боковые панели

Своевременность

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

Объемы данных

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

Управление государством

• Приложения поддерживают облегченное состояние сеанса с маркерами OAuth и локальным кэшем.
• Connect API поддерживает условные запросы и частичное обновление для повышения эффективности.
• Ответы API содержат маркеры версий для согласованности схемы в выпусках.

Сложные сценарии интеграции

• Сочетайте Connect API с Data Graph API для семантического запроса в нескольких доменах.
• Интегрируйте с Einstein 1 Copilot или AI API для прогнозируемых диалоговых взаимодействий.
• Используйте вместе с Experience Cloud или Lightning Web Components для разработки гибридного пользовательского интерфейса.
• Расширьте посредством MuleSoft, чтобы организовать пополнение данных или поиск внешних систем в режиме реального времени.

Пример

Многонациональная страховая компания создает клиентский портал самообслуживания, позволяющий страхователям просматривать объединенные профили, недавние заявки-претензии и персонализированные предложения. Фронтальное приложение на основе действия проверяет подлинность посредством OAuth 2.0 и извлекает данные посредством Connect REST API и Data Graph API. Все данные отображаются в режиме реального времени, с согласия и управляются посредством слоя Trust Data 360. Разработчики отслеживают вызовы API и контрольные журналы непосредственно в Salesforce, обеспечивая полное соответствие и доступность для наблюдения.

Контекст

Предприятиям все чаще требуется мгновенный доступ к полному профилю клиента для систем принятия решений в реальном времени, например, сервисных консолей, механизмов рекомендаций или платформ персонализации.Эта схема позволяет приложениям извлекать предварительно вычисленные объединенные представления данных клиента в близком к реальному режиме времени посредством Data 360’s Data Graph API, предоставляя время ответа в промежуток секунды для интерактивных взаимодействий. Типичные сценарии использования включают:

• Отображение полного представления клиента в службе поддержки клиентов или Sales Console.
• Включение рекомендаций на основе искусственного интеллекта «Next Best Action» или «Next Best Offer».
• Предоставление гиперперсонализированных веб- или мобильных взаимодействий во время загрузки страницы.
• Поддержка принятия решений во время сеанса в среде агента или самообслуживания.

Проблема

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

Силы

На эту схему влияют несколько операционных и эксплуатационных факторов:

• Скорость: Время ответа должно быть близко к реальному. API должен вернуть полный профиль в течение миллисекунд для поддержки синхронных взаимодействий.
• Полнота: Ответ должен содержать все актуальные атрибуты, взаимосвязи и вычисленные важные данные — в идеале в одной полезной нагрузке.
• Эффективность поиска: Профили должны извлекаться посредством таких идентификаторов, как CustomerId, contactKey или электронная почта, исключая многоэтапные запросы.
• Свежесть данных по сравнению с Задержка: Некоторые сценарии использования предпочитают предварительно вычисленные (кэшированные) данные для скорости; другие нуждаются в оперативных данных, принимая более высокую задержку.
• Управление и безопасность: Доступ должен оставаться управляемым посредством политик Salesforce Trust Layer, обеспечивая соответствие правилам доступности данных и согласия.

Решение

Решением является использование Salesforce Data Graph API для извлечения предварительно вычисленных, ненормализованных представлений клиентов, сохраненных как записи Data Graph. График данных — это материализированное семантическое представление, объединяющее несколько объектов модели данных (DMO) (например, отдельное лицо, транзакция и ProductInterest) в одну запись только для чтения, часто представленную в виде шарика JSON. Разработчики могут использовать конечные точки REST, например: GET /api/v1/dataGraph/{dataGraphEntityName}/{id} для извлечения полной записи по ее уникальному идентификатору. В динамических сценариях API поддерживает параметр live=true, который пропускает материализованный кэш, выполняя запрос в реальном времени в Data 360, обменивая минимальную задержку на самые свежие данные. Это позволяет разработчикам выбирать между мгновенными (кэшированными) и мгновенными (оперативными) извлечениями профиля в зависимости от бизнес-потребностей.

Эскиз

Ниже указана сводка потока внедрения:

• Определение графика данных: архитекторы данных создают график данных, моделирующий объединенное представление клиента в нескольких DMO.
• Регистрация связанного приложения: разработчики настраивают регистрационные данные OAuth для безопасного доступа к API.
• Вызов API графика данных: приложение отправляет запрос GET с именем графика данных и кодом записи.
• Ответ процесса: API возвращает полное представление JSON профиля клиента.
• Рендер или акт: приложение-потребитель (пользовательский интерфейс или механизм) использует объединенные данные для персонализации, рекомендаций или действий по обслуживанию.
• Мониторинг и настройка: показатели производительности и журналы доступа проверяются посредством консоли наблюдения уровня доверия.

Результаты

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

• Время подсекундного ответа для принятия решения в данный момент.
• Последовательное управляемое извлечение данных, согласованное с семантической моделью Data 360.
• Упрощенная логика приложения — нет присоединений, сверки схем.
• Отслеживаемый и соответствующий требованиям доступ посредством Trust Layer для аудита и наблюдения.

Механизмы вызова

Механизм вызова зависит от целевой платформы облачного хранилища и конфигурации активации.

Обработка и восстановление ошибок

• Благодатные резервные копии — если оперативные запросы не выполняются или превышают пороговые значения времени ожидания, автоматически возвращаются к извлечениям кэшированного графика данных.
• Управление временем ожидания — Внедрите логику повторной попытки и выключателя для вызовов API при высокой нагрузке.
• Обработка недопустимых кодов — возврат стандартных ответов 404 «Не найдено» для несуществующих ключей профиля; обработка в пользовательском интерфейсе.
• Проверка версии схемы — проверка метаданных версии графика данных для предотвращения несоответствий при развитии схемы.
• Интеграция наблюдения — регистрируйте все ошибки, попытки и задержки в панелях мониторинга Trust Layer для мониторинга SLA.

Рекомендации по созданию эффективных решений

• Детерминистские ключи — при каждом извлечении профиля используется стабильный код (например, IndividualId), обеспечивающий предсказуемость и безопасность повтора запросов.
• Консистенция кэша — используйте заголовки ETag или Last-Modified для условного извлечения и проверки кэша.
• Атомное извлечение — каждый ответ API представляет последовательный снимок материализованной записи графика данных.
• Защита повтора — убедитесь, что клиентские приложения обнаруживают повторы извлечений посредством кодов корреляции и отметок времени.

Рекомендации по безопасности

• Сильная проверка подлинности — OAuth 2.0 посредством связанных приложений внедряет безопасный доступ на основе маркера.
• Извлечение согласия — возвращаются только атрибуты согласия; фильтры согласия применяются слоем Trust автоматически.
• Управление полем — доступ к атрибутам контролируется посредством метаданных Data 360 и определений политик.
• Шифрование в пути и в дежурном режиме – все ответы шифруются посредством TLS 1.2+ и AES-256.
• Аудит и отслеживаемость — каждое событие извлечения профиля регистрируется с идентификаторами, временными отметками и контекстом политики.

Боковые панели

Своевременность

• Предназначен для мгновенного извлечения.
• Поддерживает оперативные запросы для актуальных данных с несколько более высокой задержкой (подсекунда).
• Оптимизировано для синхронного принятия решений и интерактивных приложений.
• Устраняет необходимость предпакетной активации или повторного вычисления сегмента.

Объемы данных

• Идеально подходит для поисков одной записи или небольших наборов (от десятков до сотен) на запрос.
• Не оптимизировано для крупномасштабного пакетного извлечения; используйте пакетные API или API запроса для массовых чтений.
• Использует горизонтально масштабируемое кэширование и предварительную материализацию для скорости.

Управление государством

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

Сложные сценарии интеграции

• Безупречная интеграция с Einstein 1, Connect API и MuleSoft для составных взаимодействий данных.
• Может питать агентские системы (например, пилотные или интеллектуальные механизмы рассуждения), требующие мгновенного контекстуального понимания.
• В сочетании с Действиями над данными для триггеров в реальном времени при извлечении или изменении состояния.
• Включает персонализацию в масштабах без ущерба для производительности или управления.

Пример

Глобальная платформа электронной торговли использует Data 360’s Data Graph API для извлечения объединенных профилей клиентов в режиме реального времени для механизма рекомендаций. Когда пользователь входит в систему, приложение вызывает конечную точку графика данных для извлечения UnifiedCustomerProfile для этого клиента, возвращая демографические атрибуты, поведенческие сигналы и вычисленные важные данные в качестве одной полезной нагрузки JSON. Механизм персонализации использует этот ответ в миллисекундах для определения и отображения «Следующего лучшего предложения» во время активного сеанса. Все запросы управляются и регистрируются посредством Traft Layer, обеспечивая полную доступность, соблюдение политик и соответствие во взаимодействии.

Действия над данными в реальном времени включают мгновенную активацию данных клиентов в момент их изменения в Data 360. Вместо ожидания запланированных пакетных экспортов эти действия перенаправляют обновления, важные данные или триггеры напрямую в Salesforce или внешние системы за миллисекунды. Когда статус, согласие или показатель занятости клиента обновляется в Data 360, этот сигнал может немедленно активировать персонализированные предложения, запустить автоматизацию Service Cloud или обновить уровни лояльности, обеспечивая отображение каждой клиентской версии самой актуальной объединенной истины. Эта схема идеально подходит для эффективных, чувствительных к задержкам способов использования, например, персонализированных веб-взаимодействий, предупреждений об обнаружении мошенничества, рекомендаций Next-Best Action или обновлений CRM в реальном времени. Он устраняет разрыв между важными данными и бизнес-действиями, превращая объединенные данные в мгновенные интеллектуальные.

Контекст

Современные цифровые взаимодействия и операционные бизнес-процессы требуют немедленных контекстуальных действий в момент наступления события — например, обновление записи клиента во время Checkout, корректировка запаса при сканировании возврата или доставка персонализированной рекламной акции в тот момент, когда пользователь отказывается от корзины. Действия над данными в реальном времени позволяют системам вызывать, пополнять и обрабатывать объединенные профили Data 360 и вычисленные важные данные с промежуточной-секундной задержкой, обеспечивая интерактивную персонализацию, оперативную автоматизацию и мгновенное принятие решений.

Проблема

Как приложения, потоки взаимодействия пользовательского интерфейса или промежуточное программное обеспечение могут вызывать в Data 360 во время выполнения для чтения, вычисления или обновления одного объединенного профиля или для запуска действия (например, отправка предложения, обновление CRM, запуск бизнес-правила) с низкой задержкой, сильной согласованностью и управлением, не дожидаясь запланированных пакетных заданий или тяжелых ожидаемых продаж?

Силы

Эта схема определяется рядом технических, оперативных и управленческих факторов:

• Требование низкой задержки: Вызовы должны выполняться в диапазоне от субсекунды до нескольких секунд, чтобы сохранить хороший UX или соответствовать действующим соглашениям об уровне обслуживания.
• Детерминистская разрешающая способность при опознавании: Запросы должны быть решены в правильном профиле объединенного отдельного лица (золотая запись) надежно и быстро.
• Мелкозернистая авторизация: Вызовы в реальном времени должны внедрять политики на уровне атрибутов и проверки согласия во время запроса.
• Минимализм полезных данных: Полезные данные в реальном времени должны быть небольшими и сфокусированными (один профиль или небольшой набор атрибутов) для уменьшения задержки и стоимости.
• Взаимодействие разработчика: API должны быть удобны для разработчиков (REST/gRPC/GraphQL), содержать четкие схемы и стабильные контракты на производственное использование.
• Слух и отслеживаемость: Каждое действие в реальном времени должно быть записано с помощью строки, удостоверения пользователя и политических решений на соответствие.

Решение

Рекомендуем использовать интерфейс Data 360 «Действия над данными в реальном времени» (API + SDK) в сочетании с кэшированием граней и минимальными вычислительными трансформациями. Интеграции вызывают конечную точку действий над данными для чтения или записи атрибутов профиля, вычисления важных данных или запуска оркестраций. Проверка полисов в реальном времени (CEDAR) и динамическая маскировка применяются в точке внедрения полисов перед возвратом полезных данных или выполнением действия.

Эскиз

Ниже указана сводка этапов.

• Клиент (пользовательский интерфейс / промежуточное программное обеспечение / POS) отправляет проверенные запросы действий над данными с идентификаторами и типом действия.
• Шлюз API проверяет маркер, ограничения скорости и перенаправляет в службу действий Data 360.
• Служба действий разрешает идентификатор → Объединенный код отдельного лица (быстрый кэш пути; резервная копия поиска графика).
• Внедрение политики (PDP) оценивает политики CEDAR посредством атрибутов из PIP-кода и контекста запроса.
• Если это разрешено, служба действий считывает любые обязательные атрибуты профиля и выполняет световые трансформации.
• Служба действий возвращает ответ синхронно (например, маркер предложения, обновленный атрибут) или ставит в очередь асинхронную оркестрацию и возвращает подтверждение.
• Все события, решения и полезные данные регистрируются в Trust Layer и по желанию пересылаются в SIEM.

Результаты

• Приложения получают немедленный, управляемый политикой доступ к объединенным чтениям/записям профиля и триггерам действий с подсекундной-секундной задержкой.
• Персонализация в реальном времени, принятие решений и операционные бизнес-правила (например, предложения, помощь агента, обновления запаса) включены без задержек пакета.
• Все действия проверяются, осознают согласие и внедряют маскировку на уровне атрибутов для сохранения конфиденциальности и соответствия.

Механизмы вызова

Механизм вызова зависит от целевой платформы и конфигурации цели активации.

Обработка и восстановление ошибок

• Синхронные ошибки: Возврат структурированных кодов ошибок с читаемыми сообщениями и маркерами импотенции.
• Переходная попытка: Клиенты должны повторить идемпотентные запросы с экспоненциальным отступлением от ответов 429/5xx.
• Обработка отказа в полисах: Отказы возвращают четкие коды причин; конфиденциальные данные не возвращаются при сбое политики.
• Сбои синхронизации оркестрации: Задания оркестрации перемещаются в DLQ и доступны для воспроизведения; API статуса задания позволяет клиентам опрашивать или получать обратный вызов.
• Резервные стратегии: Если разрешающая способность при опознавании не удается, верните детерминистскую ошибку и, по желанию, предложенное исправление (например, требование externalId).

Рекомендации по созданию эффективных решений

• Ключ демпотентности: Клиенты предоставляют ключ идемпотентности (UUID + пространство имен клиента) для действий мутации.
• Детерминистские ключи: Используйте составные ключи (UnifiedIndividualId + ActionType + TimestampWindow) для обнаружения повторов.
• Безопасные попытки: Создайте действия, чтобы быть устойчивыми к побочным эффектам или выполнять обновления вставок вместо слепых.
• Защита от повтора: Сохраняйте обработанные ключи импотентности и TTL их после бизнес-окна во избежание повторов.
• Безгражданство: Поддерживайте синхронные действия без состояния, если возможно; сохраняйте минимальное состояние для асинхронных бизнес-процессов.

Рекомендации по безопасности

• Проверка подлинности: OAuth 2.0 (JWT Bearer или mTLS для организаций обслуживания); кратковременные маркеры и ротация обновления.
• Авторизация: Точка политического решения применяет управление доступом на основе атрибутов (CEDAR) и проверки согласия на запрос.
• Транспортировка и шифрование хранилища: TLS 1.2+ в пути; AES-256 в дежурном режиме для любых кэшированных фрагментов или журналов проверки.
• Наименьшие привилегии: Клиенты API ограничены минимальными полномочиями; роли разделены для чтения и записи и оркестрации.
• Минимизация данных: Возврат только запрошенных и согласованных атрибутов; применение динамической маскировки для персональных данных/PHI.
• Элементы управления сетью: По желанию, требуйте вызовы из личных сетей (Private Connect, списки разрешенных IP-адресов) для действий высокого риска.
• Аудит и мониторинг: Зарегистрируйте метаданные запроса, политические решения, идентификацию запросчика и хэши ответов в Trust Layer и SIEM.

Боковые панели

Своевременность

• Создается для средних задержек в диапазоне от субсекунды до низкой односекунды для синхронных действий.
• Краевые кэши (короткий TTL) и готовые важные данные уменьшают поездки в оба конца.
• Асинхронные пути предоставляют практически мгновенное подтверждение с фоновой обработкой для сложных задач.

Объемы данных

• Оптимизировано для взаимодействия одной записи или небольшого пакета (1–100 записей).
• Не предназначено для пакетного экспорта: используйте пакетную активацию для больших объемов.
• Высокая производительность использует объединение/повторное использование подключения и параллельные очереди оркестрации.

Управление государством

• Модель запроса без гражданства для синхронных вызовов; минимальное состояние действия сохранялось для предоставления/транзакций.
• Недействительность кэша, вызванная событиями изменений: убедитесь, что TTL и сигналы недействительности поддерживают свежесть кэша.
• Задания оркестрации поддерживают устойчивое состояние (jobId, статус, повторные попытки), хранимое в слое Trust.

Сложные сценарии интеграции

• Помощник агента: Поиск профиля в реальном времени + вычисленная склонность, возвращаемая на сервисную консоль в промежуточной секунде для агентов.
• Устройства POS / Edge: Локальный SDK + эпизодическое действие над данными для проверки рекламных акций или статуса лояльности.
• Гибридные потоки: Действие синхронизации данных для оркестрации «Решение + асинхронизация» для обновления систем в нисходящем направлении и запуска кампаний.
• Стороннее программное обеспечение: Шлюзы MuleSoft или API могут выполнять посредничество при проверке подлинности, пополнять контекст и внедрять дополнительные проверки полисов.

Пример

Розничное мобильное приложение определяет необходимость отображения персонализированного мгновенного купона при нажатии покупателем Checkout посредством вызова действия над данными о праве на предложение с контекстом электронной почты и корзины покупателя. Запрос проверяется шлюзом API и перенаправляется в службу действий над данными, которая решает электронное сообщение с объединенным кодом отдельного лица посредством кэширования, проверяет согласие на маркетинг посредством PDP и оценивает право на участие на основе ценности срока действия клиента и недавней некорректности покупки. Если покупатель имеет право, служба возвращает подписанный маркер купона и регистрирует решение. Если выдача купона требует резервирования запаса, запускается асинхронная оркестрация для резервирования запаса и уведомления систем CRM. Приложение немедленно отображает купон, в то время как обновления в нисходящем направлении выполняются в фоновом режиме, а Trust Layer записывает полный контрольный журнал на предмет управления и соответствия.

• Коннекторы и интеграция
• Web & Mobile SDK
• Подсекундный прием в реальном времени
• Bring Your Own Lake (запрос нулевой копии)
• Bring Your Own Lake (файл нулевой копии)
• Графики данных
• Активация: MC Engagement
• Активация: Персонализация MC
• Активация: B2C Commerce
• Общий доступ к данным (нулевая копия)
• Активация: Хранилище файлов
• Действия над данными
• Действия подсекунды данных в реальном времени
• Внешняя платформа активации