Les intégrations Salesforce modernes doivent prendre en charge bien plus que le simple échange de données. Ils sont censés piloter l'expérience client en temps réel, coordonner les actions entre plusieurs systèmes et fonctionner de façon fiable à l'échelle de l'entreprise, le tout en respectant des exigences strictes de sécurité et de conformité. Le choix de la bonne approche d'intégration est donc une décision architecturale critique, pas un détail d'implémentation. Prenons un scénario d'entreprise courant. Un client effectue un achat dans une application mobile, déclenchant un contrôle d'éligibilité en temps réel pour une offre personnalisée. Parallèlement, les données des transactions doivent être enregistrées dans un système ERP, les attributs des clients mis à jour dans Salesforce et les analytiques transmises à un lac de données, sans introduire de latence, de duplication des données ou de risque de conformité. De tels scénarios sont désormais typiques dans les environnements Salesforce modernes, où Salesforce fonctionne rarement de façon isolée et doit s'intégrer de façon transparente à un écosystème élargi d'applications et de plates-formes de données. Ce guide existe pour aider les architectes et les développeurs à concevoir ces intégrations avec clarté et confiance. Au lieu de se concentrer sur les implémentations de point à point, il présente une série de modèles d'intégration éprouvés qui répondent à des scénarios d'entreprise récurrents, tels que l'orchestration de processus, la synchronisation des données et l'accès aux données en temps réel. Chaque modèle met l'accent sur l'intention architecturale, les compromis et les modèles d'exécution, ce qui permet aux équipes de prendre des décisions de conception informées, adaptées et durables. Dans ce document, vous trouverez :

• Modèles d'intégration qui représentent des « archétypes » d'entreprise communs dans les scénarios de processus, de données et d'accès virtuel
• Un cadre de sélection de schéma pour aider à identifier l'approche appropriée basée sur l'intention d'intégration et le calendrier d'exécution
• Considérations pratiques sur l'évolutivité, la résilience, la gouvernance et la sécurité
• Meilleures pratiques tirées des implémentations Salesforce et Data 360 réelles L'objectif de ce document est de fournir un langage architectural partagé pour l'intégration, en aidant les équipes à concevoir des solutions qui concilient performance, flexibilité et Trust tout en s'alignant avec les données de l'entreprise et les stratégies de gouvernance.

Ce document s'adresse aux concepteurs et aux architectes qui doivent intégrer les données d'autres applications de leur entreprise à Salesforce Data 360 (anciennement Data Cloud). Ce contenu est une distillation de nombreuses implémentations réussies par des architectes et partenaires Salesforce. Pour vous familiariser avec les capacités d'intégration et les options disponibles pour l'adoption à grande échelle de Data 360, lisez les sections Résumé du schéma et Guide de sélection de schéma ci-dessous . Les architectes et les développeurs doivent prendre en compte ces détails de schéma et les meilleures pratiques pendant la phase de conception et d'implémentation des projets d'interaction de données dans Data 360. S'ils sont correctement implémentés, ces modèles permettent d'accéder à la production le plus rapidement possible et d'utiliser l'ensemble d'applications le plus stable, évolutif et sans maintenance possible. Les architectes-conseils Salesforce utilisent ces modèles comme points de référence lors des examens architecturaux, et les entretiennent et les améliorent activement. Comme avec tous les schémas, ce contenu couvre la plupart des scénarios d'intégration, mais pas tous. Salesforce autorise par exemple l'intégration d'interface utilisateur (interface utilisateur), mais cette intégration n'entre pas dans le champ d'application de ce document.

Chaque modèle d'intégration suit une structure cohérente. Cela permet de fournir des informations cohérentes dans chaque modèle et facilite également la comparaison.

• Nom: L'identificateur du modèle qui indique également le type d'intégration contenu dans le modèle.
• Contexte : Le scénario d'intégration global que le schéma traite. Contexte fournit des informations sur ce que les utilisateurs tentent d'accomplir et sur le comportement de l'application pour satisfaire aux exigences.
• Problème : Exprimé sous forme de question, c'est le scénario que le schéma est conçu pour résoudre. Lisez cette section pour comprendre si le schéma convient à votre scénario d'intégration.
• Forces : Les contraintes et les circonstances qui rendent le scénario énoncé difficile à résoudre.
• Solution : La méthode recommandée pour résoudre le scénario d'intégration.
• Croquis : Un diagramme de séquence UML qui montre comment la solution répond au scénario.
• Résultats : Explique comment appliquer la solution à votre scénario d'intégration et comment elle résout les forces associées à ce scénario. Cette section présente également les nouveaux défis qui peuvent survenir suite à l'application du schéma.
• Barres latérales : Sections supplémentaires liées au modèle qui contiennent des problèmes techniques clés, des variantes du modèle, des préoccupations spécifiques au modèle, etc.
• Exemple : Un scénario du monde réel qui décrit l'utilisation du modèle de conception dans un scénario Salesforce réel. L'exemple explique les objectifs d'intégration et comment implémenter le schéma pour atteindre ces objectifs.

Utilisez ce tableau comme table des matières pour les modèles d'intégration contenus dans ce document.

Les modèles d'intégration de ce document sont classés en trois catégories : données, processus et intégrations visuelles.

Les modèles d'intégration de données dans Data 360 traitent du mouvement et de la synchronisation des données entre les systèmes afin de garantir que Data 360 et les plates-formes externes contiennent des informations cohérentes, opportunes et fiables. Ces modèles gèrent généralement des flux de données à grande échelle et à haut volume, et s'appuient sur des pipelines gouvernés qui appliquent des règles de cohérence de schéma, de suivi de lignage et de mastering.

• Les modèles d'ingestion par lot représentent la couche fondamentale de l'intégration des données d'entreprise. L'ingestion de données en masse à partir de services de stockage cloud tels que AWS S3, Azure Blob ou Google Cloud Storage permet de charger périodiquement des jeux de données historiques volumineux dans Data 360 pour la résolution de l'identité, la segmentation et les analytiques. De la même façon, l'ingestion en masse à partir de Salesforce Clouds, tels que Sales, Service ou Marketing Cloud, utilise des connecteurs natifs et des flux de données pour intégrer les données CRM dans la couche de données unifiée, garantissant harmonisation et continuité entre les systèmes d'engagement.
• Les modèles d'ingestion en continu et en temps réel étendent cette fonctionnalité en capturant des données d'événements à grande vitesse. L'ingestion pilotée par l'événement via l'API Ingestion permet aux systèmes externes de diffuser en continu l'activité des clients dans Data 360. L'ingestion en temps réel du comportement Web et mobile capture les données de flux de clics et d'interaction directement depuis les points de contact numériques pour favoriser une personnalisation immédiate. La synchronisation CRM en temps quasi réel via les API Streaming permet de refléter rapidement les attributs des clients et les mises à jour du consentement dans tous les systèmes. L'ingestion de flux d'événements à partir de plates-formes de messagerie telles que Amazon Kinesis ou Confluent MSK prend en charge les pipelines à haut débit continus, alignant Data 360 avec les architectures d'événements d'entreprise.
• Unified Multi-Org Data Platform with Data Cloud One illustre davantage l'intégration de données, en fournissant un environnement consolidé pour unifier les données de plusieurs organisations Salesforce et sources externes sous une gouvernance et une couche sémantique communes. Cela permet aux organisations d'obtenir une cohérence des données à l'échelle de l'entreprise, des modèles de données partagés et des analytiques évolutives.
• Dans la phase d'activation, les modèles d'activation par lot suivent le même principe d'intégration de données. Les segments organisés dans Data 360 sont exportés dans des tâches planifiées vers des plates-formes marketing et publicitaires en aval, telles que Marketing Cloud, Meta Ads ou Google Ads, où ils déclenchent l'exécution de campagnes. De la même façon, les jeux de données peuvent être exportés vers des cibles de stockage Cloud pour alimenter les pipelines d'analyses externes et de science des données. Dans tous ces cas d'utilisation, Data 360 agit en tant que source de vérité pour les données clients synchronisées et organisées.

Les modèles d'intégration de processus dans Data 360 impliquent le déclenchement ou l'orchestration de processus métiers à travers les systèmes en temps quasi réel. Ces modèles permettent à Data 360 de participer activement aux workflows d'entreprise, en activant des réponses contextuelles et l'activation dynamique des données.

• L'activation basée sur l'API à la demande active des scénarios d'engagement en temps réel. Grâce à l'API Connect, les applications personnalisées peuvent interroger ou activer des profils clients directement depuis Data 360 dans le cadre de processus opérationnels, par exemple une console d'agent récupérant des connaissances de profil unifiées pendant une interaction avec un client. La Récupération complète du profil client via l'API Data Graph prend en charge les applications composites et les microservices qui dépendent de l'accès piloté par l'API au graphique complet des entités d'un client, ce qui permet des expériences dynamiques sans segments pré-étape.
• Les actions de données en temps réel poussent plus loin cette approche d'intégration en activant une réactivité immédiate. Lorsqu'un signal client, par exemple un achat, une soumission de formulaire ou un événement de seuil, est détecté, Data 360 peut déclencher des actions telles que la mise à jour d'un enregistrement CRM, l'invocation d'un webhook externe ou le lancement d'un workflow d'offre personnalisée. Ces schémas incarnent une véritable orchestration des processus, reliant l'Intelligence client en temps réel à l'exécution opérationnelle automatisée.

Les modèles d'intégration virtuelle dans Data 360 permettent d'accéder en direct à des sources de données externes ou fédérées sans copier ni dupliquer physiquement les données. Elles sont essentielles pour les entreprises qui ont besoin d'informations gouvernées et à jour au moment de la requête tout en limitant les mouvements de données.

• Inbound Zero Copy Data Federation (External Platforms-to-Data 360) permet à des systèmes externes, tels que des entrepôts de données ou des lacs de données, de partager des jeux de données avec Data 360 via des connexions sécurisées et régies (par exemple, Snowflake Secure Data Sharing). Cela permet à Data 360 d'accéder virtuellement à des données externes et de les exploiter, préservant ainsi leur fraîcheur et éliminant les réplications inutiles.
• Outbound Zero Copy Data Sharing (Data 360-to-External Platforms) permet à Data 360 d'exposer des jeux de données organisés pour la consommation externe, tels que la modélisation IA, l'intelligence économique ou les analytiques avancées, via des mécanismes sécurisés de fédération de données et de requête live. Choisir la meilleure stratégie d'intégration pour votre système n'est pas anodin. Il y a de nombreux aspects à prendre en compte et de nombreux outils qui peuvent être utilisés, certains outils étant plus appropriés que d'autres pour certaines tâches. Chaque modèle traite de domaines critiques spécifiques, notamment les capacités de chaque système, le volume de données, le traitement des échecs et la transactionnalité.

Lors de la sélection d'un modèle d'intégration, commencez par répondre à deux questions fondamentales qui déterminent la conception et le comportement globaux de l'intégration. Qu'est-ce que vous intégrez ? — Processus, Données ou Accès virtuel Cette dimension définit l'objectif principal de l'intégration.

• Les intégrations de processus se concentrent sur l'orchestration des workflows métiers et la coordination des actions entre les systèmes.
• Les intégrations de données se concentrent sur la synchronisation, l'enrichissement ou la propagation de données entre les systèmes.
• Les intégrations virtuelles se concentrent sur l'accès aux données externes en temps réel sans les copier ni les conserver dans Salesforce ou Data 360. Comprendre cette intention permet de déterminer le niveau d'orchestration, de mouvement des données et de couplage requis entre les systèmes.
• Comment doit-elle être exécutée ? — La méthode Synchrone ou Asynchrone définit le modèle d'exécution de l'intégration.
• Les intégrations synchrones sont en temps réel et bloquantes, où l'appelant attend une réponse immédiate, couramment utilisées pour des scénarios pilotés par l'utilisateur ou de validation.
• Les intégrations asynchrones ne sont pas bloquantes et découplées, conçues pour gérer les processus d'échelle, longs, les tentatives et les volumes de données élevés. Ensemble, ces deux dimensions (intention d'intégration et calendrier d'exécution) fournissent un cadre clair et cohérent pour sélectionner le modèle d'intégration approprié tout en équilibrant l'expérience utilisateur, l'évolutivité et la résilience opérationnelle. Note : Une intégration peut nécessiter un middleware externe ou une solution d'intégration (par exemple, Bus de service d'entreprise) selon les aspects qui s'appliquent à votre scénario d'intégration.

Le tableau ci-dessous répertorie les modèles et leurs aspects clés pour vous aider à déterminer le modèle le plus adapté à vos besoins lorsque votre intégration se fait depuis Salesforce vers un autre système.

Le tableau ci-dessous répertorie les schémas et leurs principaux aspects pour vous aider à déterminer le schéma le plus adapté à vos besoins lorsque votre intégration s'effectue depuis un autre système vers Salesforce.

Le tableau ci-dessous répertorie quelques termes clés liés au middleware et leurs définitions par rapport à ces modèles.

L'ingestion de données est la première étape et la plus critique du cycle de vie des données de Salesforce Data 360. C'est ainsi que les informations brutes de plusieurs systèmes externes (CRM, ERP, Web, mobiles ou API tierces) entrent sur la plate-forme et font partie d'une vue client unifiée. Le mode d'ingestion approprié dépend des besoins de l'entreprise :

• Volume de données : quantité de données qui se déplacent à la fois
• Latence — Quelle doit être l'actualisation des données
• Capacités système source - comment le système peut connecter et livrer des données Data 360 prend en charge plusieurs modes d'ingestion pour répondre à ces besoins : par lot pour les chargements à haut volume, streaming pour les mises à jour en temps quasi réel, basé sur l'événement pour l'immédiateté transactionnelle et ingestion Zero Copy pour un accès instantané aux données externes sans les déplacer physiquement. Ensemble, ces modèles garantissent que chaque signal client, qu'il s'agisse d'un événement d'achat, d'un journal de flux de clics ou d'une mise à jour de fidélité, est transmis dans Data 360 de façon efficace, sécurisée et dans les délais appropriés afin d'optimiser les analytiques de confiance et les expériences pilotées par l'IA.

Les modèles d'ingestion par lot sont l'épine dorsale de l'intégration de données à grande échelle dans Data 360. Ils sont optimisés pour les scénarios dans lesquels les données sont traitées en masse, généralement de façon planifiée ou périodique, plutôt que de façon continue. Ces modèles sont les plus adaptés pour :

• Chargement de données historiques pour initialiser la plate-forme avec des enregistrements d'entreprise existants
• Synchronisation régulière avec des systèmes d'enregistrement tels que des ERP, des entrepôts de données ou des bases de données propriétaires
• Utilisez des cas où l'actualisation en temps réel n'est pas critique, mais la cohérence, l'exhaustivité et l'auditabilité sont L'ingestion par lot offre des performances prévisibles et une simplicité opérationnelle, ce qui en fait un choix de confiance pour les entreprises qui gèrent des téraoctets de données structurées ou semi-structurées. Data 360 fournit une série de connecteurs prêts pour la production et globalement disponibles qui prennent en charge l'ingestion par lot en natif. Ces connecteurs rationalisent la configuration de l'intégration, réduisent le développement ETL personnalisé, et garantissent la qualité et la sécurité des données à chaque importation. Le tableau ci-dessous présente les connecteurs les plus souvent utilisés pour l'ingestion par lot à l'échelle de l'entreprise.

Context

Ce schéma est conçu pour les scénarios d'entreprise qui impliquent l'ingestion de volumes importants de données structurées, telles que des fichiers CSV ou Parquet, et d'actifs non structurés à partir de lacs de données centralisés ou de dépôts de fichiers planifiés. Les sources de données comprennent généralement des plates-formes de stockage cloud telles que Amazon S3, Google Cloud Storage (GCS) et Microsoft Azure Blob Storage, où les fichiers sont périodiquement livrés dans le cadre de pipelines de données en amont ou d'exportations par lot.

Problème

Comment une organisation peut-elle établir un processus fiable, sécurisé et à haut débit pour ingérer des jeux de données volumineux, basés sur des fichiers, depuis sa plate-forme de stockage cloud principale vers Data 360 à un rythme prévisible et récurrent, sans sacrifier la gouvernance, l'évolutivité ou les performances ?

Forces

L'ingestion massive de jeux de données basés sur des fichiers dans Data 360 n'est pas un simple exercice de transfert de données, mais un défi architectural façonné par les contraintes d'échelle, de gouvernance et de plate-forme.

Volume et échelle des données : Les connecteurs d'ingestion Data 360 sont optimisés pour la fiabilité et la gouvernance, pas pour un débit en masse arbitraire. Par exemple, le connecteur Amazon S3 prend en charge jusqu'à 100 millions de lignes ou 50 Go par objet, selon la première limite atteinte. Pour les entreprises qui ont des jeux de données historiques contenant des milliards d'enregistrements, cette frontière devient une contrainte de conception clé. Une approche à fichier unique, par lift-and-shift devient rapidement impossible, nécessitant des stratégies intelligentes de partitionnement, de segmentation et d'orchestration des données pour atteindre l'échelle sans atteindre les limites du connecteur.

Définition et maintenance du schéma : Data 360 nécessite des définitions de schéma explicites pour chaque pipeline d'ingestion afin de garantir l'intégrité sémantique et structurelle. Dans le cas d'une ingestion S3, un fichier csv doit définir des en-têtes de colonne et une seule ligne de données représentative. Ce fichier agit en tant que contrat canonique entre le système source, c'est-à-dire le stockage cloud, et Data 360. Tout désalignement (dans les noms de champ, les types de données ou l'encodage) peut entraîner des échecs d'ingestion ou une corruption silencieuse des données. La gestion de ce fichier de schéma dans le contrôle de version et l'application automatique de la validation via des workflows CI/CD ou de gouvernance des données devient une meilleure pratique pour les environnements de production.

Conventions de nommage strictes : Data 360 applique des règles strictes de nommage d'objets et de champs pour maintenir la cohérence dans le graphique des métadonnées.

• Les noms d'objet doivent commencer par une lettre et ne peuvent inclure que des lettres, des chiffres ou des traits de soulignement.
• Les noms de champ doivent suivre les mêmes modèles. Les fichiers qui enfreignent ces conventions, par exemple les champs contenant des espaces, des caractères spéciaux ou des symboles non pris en charge, échouent à la validation du schéma pendant l'ingestion. Les entreprises doivent mettre en œuvre des processus d'hygiène des données préalables à l'ingestion afin d'assainir et de normaliser les structures de fichiers entrants.

Schéma d'authentification et de sécurité : Chaque connexion à un stockage externe doit respecter les normes de sécurité et de conformité de niveau entreprise.

• L'authentification est généralement gérée via l'accès AWS/clés secrètes ou l'authentification par fournisseur d'identité (IdP) fédéré.
• Les rôles IAM doivent être délimités pour appliquer le moindre privilège, en autorisant uniquement l'accès en lecture aux chemins de stockage spécifiés.
• Pour un accès sécurisé, les adresses IP sortantes doivent être directement ajoutées à la liste d'autorisations du système source. Ces contrôles en couches garantissent que chaque transfert de fichier fonctionne dans un périmètre zéro Trust et auditable, en équilibrant la conformité de l'entreprise avec la flexibilité requise pour l'ingestion à grande échelle.

Solution

Le tableau ci-dessous présente des solutions à ce problème d'intégration.

Croquis

Ce diagramme illustre la séquence des étapes d'ingestion des données depuis le stockage Cloud vers Data 360

Dans ce scénario :

• L'administrateur configure une connexion au stockage cloud via l'interface de configuration de Data 360 (en spécifiant l'authentification, les détails du compartiment, les rôles IAM et la liste blanche).
• L'interface de configuration de Data Cloud s'authentifie à Cloud Storage Platform, en vérifiant les identifiants et l'accès.
• L'administrateur crée un flux de données dans Data 360, liant le flux de données à l'objet/dossier dans Cloud Storage et définissant la planification de l'ingestion.
• À la planification du déclencheur, le flux de données demande des fichiers sources (par exemple, CSV, Parquet) depuis Cloud Storage Platform.
• Cloud Storage Platform livre des fichiers, y compris les fichiers valides requis schema_sample.csv et d'autres fichiers de données conformes aux conventions de nommage.
• Le flux de données transfère des fichiers vers l'environnement intermédiaire interne dans Data 360.
• Data 360 Pipeline traite les fichiers : Utilise la définition de schéma de schema_sample.csv Valide la structure, les noms de champ et divise la charge si elle dépasse les seuils d'ingestion (100 millions de lignes/50 Go par fichier). Si des fichiers volumineux sont détectés, une étape de partitionnement préalable au traitement (notifiée à l'administrateur pour la prochaine exécution) est effectuée en externe.
• Les enregistrements sont importés depuis Staging dans un objet lac de données (DLO).
• Si nécessaire et que les données sont partitionnées, utilisez le nœud append dans une transformation de données batch pour combiner plusieurs objets lac de données.
• Data 360 consigne les réussites/échecs, met à jour le statut de surveillance et indique que les données sont prêtes pour le mappage, l'harmonisation et l'unification.

Résultats

L'application de ce schéma permet d'ingestion sécurisée, planifiée et à grande échelle de fichiers structurés ou non structurés à partir de plates-formes de stockage cloud d'entreprise dans Data 360. Le processus est automatisé, évolutif et résilient. Il livre des données brutes dans des objets lac de données (DLO) qui servent de base d'harmonisation et de mappage avec le Customer 360 Data Model.

Mécanismes d'ingestion

Le mécanisme d'ingestion dépend du connecteur et de la stratégie de planification définis dans Data 360.

Gestion et récupération des erreurs

Le traitement des erreurs et la récupération sont essentiels pour garantir la fiabilité des opérations d'ingestion à haut volume.

• Détection des erreurs : Chaque exécution de flux de données consigne les erreurs d'ingestion (par exemple, inadéquation du schéma, corruption de fichiers ou infractions au nommage) dans Data 360 Monitoring. Les administrateurs peuvent réviser et retraiter les lots échoués.
• Mécanisme de recouvrement: Data 360 maintient le pointage pour s'assurer que les lots échoués ne corrompent pas les ingestions précédentes. Les récupérations peuvent être configurées après avoir corrigé des problèmes sources (par exemple des fichiers CSV malformés).
• Validation du schéma: Le fichier schema_sample.csv définit les types de données et la structure. Toute modification déclenche une validation afin d'éviter une dérive silencieuse du schéma entre les exécutions.

Considérations relatives à la conception impotente

L'ingestion est idempotente par conception - le retraitement du même fichier n'entraîne pas de duplication des enregistrements. Les stratégies clés comprennent :

• Empreinte digitale du fichier : Data 360 calcule des sommes de contrôle pour identifier et ignorer les fichiers précédemment traités.
• Ingestion transactionnelle : Les données sont intermédiaires et engagées dans l'objet lac de données uniquement lorsque le traitement de tous les enregistrements réussit.
• Ajouter vs. Remplacer : Selon la logique métier, les flux peuvent ajouter ou remplacer entièrement l'objet lac de données cible, ce qui garantit des résultats déterministes et empêche le chevauchement partiel des données.

Considérations relatives à la sécurité

La sécurité fait partie intégrante du pipeline d'ingestion, de l'authentification au cryptage et au contrôle d'accès.

• Authentification et autorisation : Les connecteurs utilisent l'infrastructure d'intégration sécurisée de Salesforce, exploitant les identifiants nommés et les identifiants externes pour l'authentification sans révéler de secrets.
• Cryptage : Les données sont cryptées en transit (TLS 1.2+) et au repos (AES-256).
• Contrôles réseau : Les systèmes de stockage sources (p. ex. les compartiments S3) doivent ajouter des adresses IP Data 360 à la liste d'autorisations.
• Alignement de conformité : Prend en charge les infrastructures de protection des données d'entreprise telles que GDPR, HIPAA et les directives FFIEC lorsqu'elles sont associées à des clés gérées par le client (CMK).
• Auditabilité : Chaque tâche d'ingestion et accès aux identifiants est consigné pour la traçabilité et les rapports de conformité.

Menus latéraux

Opportunité

La rapidité dépend de la planification de l'ingestion et du volume de données.

• Les jeux de données d'entreprise volumineux (100M+ lignes) peuvent nécessiter un partitionnement pour l'ingestion parallèle.
• La latence d'ingestion typique varie de minutes à quelques heures, selon la taille du fichier et la complexité de la transformation.
• Pour l'ingestion en temps quasi réel, des connecteurs Data 360 Streaming ou basés sur l'API peuvent compléter le modèle basé sur le fichier.

Volumes de données

• Convient parfaitement à l'ingestion par lots périodique à haut volume.
• Chaque objet traité via le connecteur S3 prend en charge jusqu'à 100 millions de lignes ou 50 Go par fichier.
• Pour des systèmes à l'échelle du pétaoctet, utilisez le partitionnement des données et l'orchestration multiflux.

Prise en charge des capacités et des normes des points de terminaison

La capacité et la prise en charge standard du point de terminaison dépendent de la solution que vous choisissez.

Gestion des états

L'état est suivi à travers les flux de données et leur horodatage de dernière exécution réussie.

• Data 360 conserve automatiquement les états de synchronisation et les décalages, garantissant que seuls les fichiers nouveaux ou modifiés sont traités lors des exécutions suivantes.
• Lors de l'intégration à des outils ETL externes, des identificateurs de fichier uniques (par exemple, des UUID ou des horodatages) sont recommandés pour éviter les doublons.

Scénarios d'intégration complexes

Dans les architectures d'entreprise avancées, ce schéma peut s'intégrer à :

• Middleware ETL Pipelines (p. ex. Informatica, MuleSoft) : pour orchestrer le prétraitement, la validation et le partitionnement de fichiers avant la transmission à Data 360.
• Workflows IA/ML : les données d'objet lac de données traitées peuvent être publiées via un objet modèle de données pour modéliser des environnements d'entraînement ou des index RAG via des cibles d'activation Data 360.
• Systèmes transactionnels : les objets modèle de données harmonisés peuvent déclencher des mises à jour en aval dans Salesforce CRM ou des systèmes externes via des Actions de données ou des Événements de plate-forme.

Exemple

Une institution financière internationale stocke les données des clients et des transactions dans un lac de données AWS S3, où les fichiers Parquet partitionnés sont générés la nuit par région (États-Unis, UE et APAC). L'équipe d'architecture de données configure plusieurs flux de données dans Data 360, chacun connecté à un dossier régional, avec un schema_sample.csv partagé garantissant des en-têtes et des types de données cohérents dans toutes les partitions. Les planifications d'ingestion nocturne chargent automatiquement les données dans des objets lac de données, après quoi les Transformations de données par lot ajoutent toutes les partitions régionales dans un objet lac de données Customer_Transactions_DLO unifié. Ce jeu de données harmonisé est ensuite mappé avec le Customer 360 Data Model, ce qui permet d'activer les analytiques en aval et l'IA. L'approche fournit une ingestion automatisée et fiable à partir du lac de données existant, applique une authentification forte et un cryptage alignés sur les politiques informatiques de l'entreprise, et fournit une fondation modulaire évolutive qui prend en charge l'expansion future et l'évolution du schéma.

Context

Un cas d'utilisation principal et critique pour Data 360 est l'unification des données clients dans l'écosystème Salesforce. Ce schéma couvre l'ingestion native de données à partir des plates-formes Salesforce principales : Sales Cloud et Service Cloud (collectivement Salesforce CRM) et Marketing Cloud Engagement. Les sources comprennent des objets CRM standard et personnalisés (par exemple, Compte, Contact, Requête, Opportunité) et des extensions de données Marketing Cloud Engagement qui contiennent des événements d'engagement, des envois d'e-mails et des données de suivi.

Problème

Comment une organisation peut-elle ingérer efficacement et de façon fiable des objets CRM standard et personnalisés et des extensions de données Marketing Cloud Engagement dans Data 360 afin d'utiliser les données pour élaborer des profils clients unifiés (résolution de l'identité, Customer 360), tout en maintenant les performances, la gouvernance et une interruption minimale des systèmes sources ?

Forces

Les connecteurs natifs simplifient la tâche, mais plusieurs forces opérationnelles et architecturales doivent être gérées :

• Autorisations sources complètes : Un utilisateur connecté dédié (compte d'intégration) doit disposer des autorisations de lecture appropriées au niveau de l'objet et au niveau du champ. L'incapacité d'attribuer les ensembles d'autorisations requis (par exemple, un ensemble d'autorisations de connecteur Data 360 prédéfini) est une cause fréquente d'échec de l'ingestion.
• Modes d'actualisation des données et coût : Les connecteurs prennent en charge les modes d'actualisation complet et delta/incrémentiel. Les actualisations complètes sont plus lourdes en performances et crédits ; les extractions delta réduisent la charge, mais dépendent d'un suivi fiable des modifications dans le système source.
• Schéma personnalisé et mappage de champs : Les instances CRM contiennent souvent des objets/champs personnalisés. Un mappage précis des schémas et la gestion des champs personnalisés (noms, types) sont requis pour éviter les erreurs de mappage ou les dérives sémantiques.
• Paquets de données de démarrage vs. Mappage personnalisé : Les paquets de données de démarrage accélèrent l'intégration en présélectionnant des objets/champs typiques, mais les organisations fortement personnalisées auront besoin de définitions de flux sur mesure.
• Limites en débit et en API : Les limites en API d'organisation source et les taux d'extraction Marketing Cloud limitent l'agressivité avec laquelle vous pouvez planifier des actualisations.
• Conventions relatives à l'hygiène des données et au nommage : Les noms de champ source, le comportement nul et les types de données doivent être normalisés avant l'ingestion afin d'éviter les problèmes de mappage en aval.
• Sécurité et moindre privilège : Le connecteur s'appuie sur l'authentification sécurisée et doit respecter les modèles IAM à moindre privilège, l'auditabilité et les contrôles réseau.

Solution

Le tableau ci-dessous présente des solutions à ce problème d'intégration.

Croquis

Ce diagramme illustre la séquence des étapes d'ingestion des données depuis le stockage Cloud vers Data 360

Dans ce scénario :

• L'administrateur provisionne les utilisateurs de l'intégration et attribue des ensembles d'autorisations de connecteur dans les organisations sources.
• L'administrateur configure les connecteurs dans la Configuration de Data 360 (se connecte à Salesforce CRM et Marketing Cloud via OAuth/application connectée).
• L'administrateur crée des flux de données en sélectionnant des objets et des extensions de données, choisit l'actualisation complète ou delta, et définit des planifications.
• À l'exécution planifiée, Data 360 demande des jetons de schéma et delta à la ou aux sources.
• Les systèmes sources renvoient des enregistrements (delta ou charge utile complète). Marketing Cloud peut fournir des extractions, CRM peut renvoyer des résultats JSON/Query.
• Data 360 met en scène les fichiers dans sa zone intermédiaire sécurisée interne et les valide par rapport au schéma mappé.
• Si la validation échoue, l'erreur est consignée dans les journaux d'ingestion, l'administrateur est alerté et l'engagement est interrompu. Si la validation réussit, Data 360 engage atomiquement les enregistrements dans l'objet lac de données cible.
• Les journaux de surveillance et d'audit sont mis à jour avec le lignage, la durée d'exécution, le nombre de lignes et l'utilisation des identifiants. Alertes envoyées aux administrateurs en cas de déclenchement de seuils ou d'erreurs.

Résultats

Les principales données de relation client et d'engagement marketing sont ingérées dans Data 360 en tant qu'objets lac de données (DLO). Cela renvoie :

• Jeu de données unifié contenant des profils, des requêtes, des opportunités et des métriques d'e-mail/engagement.
• Fondation pour la résolution de l'identité et la construction de profils Individu unifié.
• Préparation opérationnelle à l'harmonisation, à l'enrichissement, à la modélisation et à l'activation de l'IA en aval tout en préservant la gouvernance et l'auditabilité.

Mécanismes d'ingestion

Le mécanisme d'ingestion dépend du connecteur et de la stratégie de planification définis dans Data 360.

Gestion et récupération des erreurs

Le traitement des erreurs et la récupération sont essentiels pour garantir la fiabilité des opérations d'ingestion à haut volume.

• Journaux par exécution : Chaque exécution de flux de données fournit des détails de réussite/échec et des erreurs au niveau de la ligne.
• Retries & Checkpointing : Les exécutions échouées peuvent être ré-essayées après avoir corrigé des problèmes sources ou de schéma ; Data 360 utilise la sémantique d'étape et d'engagement atomique.
• Alertes : Configurez des alertes en cas de dérive du schéma, d'échecs répétés ou d'écarts de séquence delta.

Considérations relatives à la conception impotente

L'ingestion est idempotente par conception - le retraitement n'entraîne pas de doublons dans les enregistrements. Les stratégies clés comprennent :

• Détection des modifications : Les extractions Delta s'appuient sur des indicateurs de changement du système source (LastModifiedDate / capture des données de changement du système). Vérifiez que la source fournit des horodatages/indicateurs fiables.
• Déduplication : Utilisez des clés métiers uniques (par exemple Contact.ExternalId) pour dédupliquer ou mettre à jour/insérer dans des objets lac de données.
• Engagement transactionnel : Les enregistrements sont intermédiaires et engagés uniquement lorsque le traitement par lot est terminé avec succès.

Considérations relatives à la sécurité

La sécurité fait partie intégrante du pipeline d'ingestion, de l'authentification au cryptage et au contrôle d'accès.

• Authentification et autorisation : Les connecteurs utilisent l'infrastructure d'intégration sécurisée de Salesforce, exploitant les identifiants nommés et les identifiants externes pour l'authentification sans révéler de secrets.
• Cryptage : Les données sont cryptées en transit (TLS 1.2+) et au repos (AES-256).
• Contrôles réseau : Les systèmes de stockage sources (p. ex. les compartiments S3) doivent ajouter des adresses IP Data 360 à la liste d'autorisations.
• Alignement de conformité : Prend en charge les infrastructures de protection des données d'entreprise telles que GDPR, HIPAA et les directives FFIEC lorsqu'elles sont associées à des clés gérées par le client (CMK).
• Auditabilité : Chaque tâche d'ingestion et accès aux identifiants est consigné pour la traçabilité et les rapports de conformité

Menus latéraux

Opportunité

La rapidité dépend de la planification de l'ingestion et du volume de données.

• La cadence idéale dépend des besoins de l'entreprise : toutes les heures pour les déclencheurs marketing en temps quasi réel, toutes les nuits pour les rapprochements importants.
• Les modes delta réduisent la charge et le coût ; les actualisations complètes sont plus lourdes et utilisées pour les chargements initiaux ou les changements de schéma majeurs.

Volumes de données

• Les connecteurs CRM sont optimisés pour les jeux de données transactionnels et à volume moyen (millions d'enregistrements).
• Pour des volumes historiques extrêmement importants, tenez compte de l'ETL intermédiaire pour partitionner et charger par étapes.

Prise en charge des capacités et des normes des points de terminaison

La capacité et la prise en charge standard du point de terminaison dépendent de la solution que vous choisissez.

Gestion des états

• État du connecteur : Les flux de données conservent les derniers horodatages de synchronisation réussis et les décalages delta.
• Principale stratégie clé : Préférez des identifiants métiers cohérents (ID externes) afin que le rapprochement en aval et les mises à jour/insertions soient déterministes.

Scénarios d'intégration complexes

Dans les architectures d'entreprise avancées, ce schéma peut s'intégrer à :

• Topologies hybrides : Combinez l'ingestion CRM à la diffusion en continu (événements de plate-forme) pour des mises à jour en temps quasi réel.
• Orchestration middleware : Utilisez les outils MuleSoft ou ETL lorsque l'orchestration, l'enrichissement ou la préingestion de transformation complexe est requis.
• Boucles de commentaires d'activation : Les objets modèle de données harmonisés peuvent déclencher des mises à jour en aval des systèmes sources via des Actions de données ou des API de plate-forme (attention avec les contrôles SoD).

Exemple

Un distributeur multinational regroupe les métriques d’engagement Comptes, Contacts, Requêtes, Opportunités et Marketing Cloud dans Data 360 pour créer une vue client unifiée. Le paquet de données Starter initialise les principaux objets Ventes et Service, tandis que l'équipe étend le modèle avec des champs personnalisés tels que Loyalty_Membershipc et Customer_Tierc pour capturer le contexte de fidélité. Les flux de données CRM sont exécutés toutes les heures en mode delta, et Marketing Cloud Engagement est synchronisé quotidiennement en utilisant des extractions delta pour les événements d'engagement. Ces jeux de données sont traités via des objets lac de données et la résolution de l'identité, ce qui génère un profil client unifié qui combine CRM et signaux d'engagement pour piloter la personnalisation et les modèles IA en aval.

Ces modèles sont conçus pour les scénarios où les millisecondes sont importantes, c'est-à-dire lorsque les interactions, les transactions ou les signaux des clients doivent déclencher une connaissance ou une action immédiate. Ils vont au-delà de l'ingestion par lot planifiée traditionnelle pour activer le flux de données piloté par l'événement, où les informations sont traitées dès leur génération. Dans l'écosystème Salesforce Data 360, le « temps réel » n'est pas un mode unique, mais un continuum de modèles de latence. D'un côté, la synchronisation en temps quasi réel, où les mises à jour des systèmes d'enregistrement (tels que CRM ou ERP) sont reflétées dans Data 360 en quelques secondes ou minutes. De l'autre côté, la véritable capture d'événements en temps réel, où les signaux comportementaux côté client, tels que les clics, les achats ou les interactions mobiles, sont ingérés et activés en millisecondes. Pour les architectes, la distinction est plus que sémantique. Il définit la conception des pipelines, l'invocation des API et la prise de décisions en aval. La sélection du modèle approprié (synchronisation en temps quasi réel ou ingestion d'événements en continu) garantit que le système atteint les objectifs de latence opérationnelle de l'entreprise tout en préservant l'intégrité des données, l'évolutivité et la gouvernance.

Context

Ce schéma permet à n'importe quel système externe, par exemple une application personnalisée, une plate-forme Internet des objets (IoT), un système de point de vente (POS) ou un service tiers, d'envoyer automatiquement par programmation des données d'événements dans Data 360 en temps quasi réel lorsque des événements discrets se produisent.

Problème

Comment un développeur peut-il envoyer de façon fiable des enregistrements uniques ou de petits lots asynchrones d'événements depuis une application externe vers Data 360 avec une faible latence afin que les données soient rapidement disponibles pour le traitement, la segmentation et l'activation ?

Forces

Ce schéma offre une faible latence et un meilleur contrôle du développeur, mais introduit plusieurs contraintes techniques et dépendances opérationnelles :

• Dépendance du développeur : Nécessite un effort de développeur pour implémenter des clients d'API REST authentifiés et une logique d'erreur/réessai. Ce n'est pas un connecteur par pointer-cliquer.
• Schéma strict en écriture : L'API Ingestion applique automatiquement le schéma en écriture. Un schéma précis doit être défini et chargé dans la configuration du connecteur. Toutes les charges utiles doivent être conformes ou rejetées.
• Modes d'interaction double : Le même connecteur prend en charge le streaming (JSON) pour les mises à jour à faible latence, enregistrement par enregistrement, et le transfert en masse (CSV) pour les synchronisations périodiques plus importantes. Les architectes doivent choisir par cas d'utilisation.
• Authentification et sécurité : Les appels doivent être authentifiés via une application connectée Salesforce en utilisant OAuth 2.0 (p. ex. flux de porteur JWT pour serveur à serveur). La gestion des jetons, la rotation et les étendues de moindre privilège sont obligatoires.
• Visibilité opérationnelle : Les développeurs et les équipes de plate-forme doivent mettre en œuvre une surveillance des codes de réponse, des tentatives, des files d'attente en lettres mortes et des alertes de dérive de schéma.
• Graphique en temps réel requis : Pour une véritable activation instantanée (segmentation instantanée, mappage d'objets modèle de données en temps réel), l'objet modèle de données (DMO) cible doit faire partie du graphique de données en temps réel, sinon les événements traversent un pipeline à latence légèrement plus élevée.

Solution

Le tableau ci-dessous présente des solutions à ce problème d'intégration.

Croquis

Ce diagramme illustre la séquence des étapes d'ingestion des données depuis l'API Ingestion vers Data 360

Dans ce scénario :

• Le système externe demande l'authentification via OAuth/JWT au serveur d'authentification.
• Le serveur d'authentification renvoie le jeton d'accès au système externe.
• Le système externe envoie la requête POST d'ingestion de données à l'API Ingestion Data 360 avec autorisation et charge de travail JSON.
• L'API Ingestion valide le schéma de requête et l'authentification via le module Staging & Validation.
• En cas d'échec du schéma/de l'authentification :
• Erreur renvoyée dans Système externe.
• Refus consigné pour surveillance et alerte.
• Une fois la validation réussie :
• Enregistrements mis en scène et engagés dans Objet lac de données (DLO).
• Succès consigné pour la surveillance.
• Si cette option est activée, les données sont propagées vers le Graphique de données en temps réel (DMO) qui déclenche des workflows en aval.
• Sinon, les données sont traitées par lot standard ou pipeline à latence plus élevée.
• L'API Ingestion confirme le succès du système externe.
• Les composants de surveillance alertent l'administrateur sur les files d'attente en lettres mortes, les taux de rejet ou les problèmes de latence.

Résultats

Les données d'événements externes sont ingérées dans des objets lac de données Data 360 à faible latence. Lorsque l'objet modèle de données cible fait partie du graphique en temps réel, les données sont disponibles pour la segmentation instantanée, les workflows des agents, les modèles IA et l'activation opérationnelle. Cela permet de répondre rapidement aux événements provenant de n'importe quel système connecté.

Mécanismes d'ingestion

Le mécanisme d'ingestion dépend du connecteur et de la stratégie de planification définis dans Data 360.

Gestion et récupération des erreurs

• Erreurs (de synchronisation) immédiates : Réponses 4xx pour des erreurs de schéma/authentification — le client doit corriger la charge utile ou le jeton et réessayer.
• Échecs transitoires (asynchrones) : Réponses 5xx : le client essaie avec un recul exponentiel et de la gigue.
• File d'attente lettre morte (DLQ) : Les échecs persistants sont renvoyés dans DLQ pour inspection manuelle et relecture.
• Surveillance : Suivez le taux de rejet du schéma, les échecs d'authentification, les percentiles de latence et le backlog DLQ. Alerte sur les seuils.

Considérations relatives à la conception impotente

• Clé d'immunité : Chaque événement doit inclure une clé d'identité/ID de message unique.
• Mettre à jour/insérer une stratégie : Utilisez des clés métiers (ExternalId) pour éviter les doublons lors des relectures.
• Fenêtre Dedup : L'architecte doit définir des fenêtres de déduplication et de rétention pour le suivi de l'idempotence.

Considérations relatives à la sécurité

La sécurité fait partie intégrante du pipeline d'ingestion, de l'authentification au cryptage et au contrôle d'accès.

• Authentification : OAuth 2.0 (porteur JWT) recommandé pour serveur à serveur. Limitez les étendues uniquement à l'ingestion.
• Cryptage : TLS 1.2+ pour le transport; Data 360 applique automatiquement le cryptage au repos.
• Moins de privilège : Les identifiants de l'application connectée ont des droits minimums. Permutez les secrets et les journaux d'accès aux instruments.
• Gouvernance de la charge de travail : Insérez des indicateurs de consentement/consommation dans les métadonnées des événements; appliquez les stratégies ABAC/CEDAR immédiatement après l'ingestion.
• Contrôles IP / Private Connect : Si nécessaire, limitez l'accès via des listes d'autorisations ou utilisez Private Connect pour la mise en réseau privée.

Menus latéraux

Opportunité

La rapidité dépend de la planification de l'ingestion et du volume de données. Le JSON en continu renvoie une latence de la seconde à la seconde selon le traitement et la configuration du graphique. Le fichier CSV en masse est de minutes à heures. Choisissez en fonction des accords commerciaux.

Volumes de données

La taille des événements individuels doit être petite (< quelques Ko). Pour les producteurs à haut débit, vous pouvez utiliser un traitement par lot chez le producteur ou une mémoire tampon en continu (Kafka/Kinesis) avant d'appeler l'API.

Gestion des états

• Schéma de version : Maintenir la version du schéma dans les métadonnées d'événements et utiliser la gestion des versions du connecteur lors de la mise à jour du contrat OAS.
• Décalages de connecteur : Data 360 gère la sémantique d'engagement. Les producteurs doivent suivre les clés d'idempotence et la dernière séquence réussie pour une relecture sécurisée.

Scénarios d'intégration complexes

Dans les architectures d'entreprise avancées, ce schéma peut s'intégrer à :

• Couche de validation Edge : Utilisez un middleware pour traduire des formats de producteur hétérogènes vers le contrat OAS requis, effectuer une limitation de taux et un pré-enrichissement.
• Architectures hybrides : Combinez l'API d'ingestion pour les événements et les connecteurs pour le rapprochement en masse.
• Activation de l'agent : Les événements mappés avec des objets modèle de données en temps réel peuvent déclencher des workflows Agentforce et des modèles Einstein pour la prise de décision automatisée.

Exemple

Une chaîne de magasins de détail diffuse des événements d'achat de point de vente (POS) dans Data 360 inReal-Time pour favoriser l'engagement immédiat des clients. Chaque magasin exécute un composant serveur léger qui collecte les transactions, les enrichit avec des métadonnées d'emplacement et d'appareil, et publie en toute sécurité des événements JSON en utilisant OAuth du porteur JWT avec des clés d'idempotency pour éviter les doublons. Un administrateur définit la structure de l'événement en chargeant un schéma OAS pour le point de vente et en configurant le connecteur d'API Ingestion. Les événements entrants sont ingérés dans l'objet lac de données pos_sale, mappés avec l'objet modèle de données Vente et ajoutés au graphique en temps réel. Ainsi, les achats de grande valeur sont détectés instantanément, ce qui déclenche des workflows VIP dans Agentforce et met à jour la segmentation des clients pour piloter la personnalisation en temps réel.

Context

Ce schéma permet de capturer des données d'interaction utilisateur précises et volumineuses, telles que des vues de page, des clics sur des boutons, des impressions de produits et des lectures vidéo, à partir de sites Web et d'applications mobiles en temps réel. Elle est fondamentale pour offrir une personnalisation instantanée, où chaque interaction numérique peut influencer dynamiquement l'expérience utilisateur et favoriser l'engagement.

Problème

Comment une entreprise peut-elle capturer et traiter un flux continu d'événements comportementaux à partir de propriétés numériques, couvrant des millions d'interactions utilisateur par minute, et rendre ces données immédiatement disponibles dans Data 360 pour piloter la segmentation, la personnalisation et l'activation en temps réel ?

Forces

Ce cas d'utilisation introduit plusieurs défis de conception qui nécessitent une architecture d'ingestion à faible latence spécialement conçue :

• Débit extrême : Les sites Web ou les applications mobiles à fort trafic peuvent émettre des millions d'événements par minute. La couche d'ingestion doit évoluer horizontalement pour gérer ce volume sans perte d'événement ni contre-pression, ce qui garantit une latence constante sous des charges de pointe.
• Instrumentation côté client : Contrairement aux intégrations pilotées par le serveur, ce modèle dépend des kits de développement côté client. Une balise JavaScript (Salesforce Interactions SDK) doit être incorporée à chaque page, ou un kit de développement natif intégré à des applications mobiles. Cela nécessite un déploiement client robuste, la gestion des versions et la gouvernance du schéma d'événements.
• Traitement des événements à faible latence : Les actions de l'utilisateur, telles que « ajouter au panier d'achat » ou « lecture vidéo », doivent atteindre Data 360 en quelques secondes, ce qui permet l'activation en temps réel et des réponses contextuelles (par exemple, des offres ciblées, des recommandations personnalisées).
• Harmonisation et résolution de l'identité des données : Les événements capturés contiennent souvent des identifiants anonymes (cookies, ID d'appareil, jetons de session). Pour piloter les cas d'utilisation Customer 360, ils doivent être mappés avec des profils connus via la résolution de l'identité de Data 360 et harmonisés avec le Customer 360 Data Model.

Solution

L'approche recommandée consiste à utiliser le connecteur Salesforce Marketing Cloud Personalization, un encours en continu entièrement géré et natif conçu pour l'ingestion comportementale à haut débit.

Croquis

Ce diagramme illustre la séquence des étapes d'ingestion des données de canaux Mobile et Web dans Data 360

Dans ce scénario :

• Déployez le kit de développement dans des canaux Web ou mobiles (capture de l'interaction utilisateur).
• Configurez SDK avec des contrôles d'ID de locataire, d'environnement et de consentement.
• Diffusez les événements JSON capturés (métadonnées + attributs) au point de terminaison en continu Marketing Cloud.
• Dans Configuration de Data 360, créez et configurez le connecteur de personnalisation pour le locataire.
• Ingérez des événements dans un objet lac de données et mappez l'objet lac de données → objet modèle de données dans Data 360.
• Activez l'objet modèle de données dans le graphique en temps réel pour une activation immédiate.
• Surveillez la latence, la conformité du schéma, les indicateurs de consentement, le débit, les taux d'erreur.
• Déployez en production et surveillez en permanence.

Résultats

Un flux continu et à faible latence d'événements comportementaux circule depuis les canaux numériques vers Data 360. En quelques secondes, chaque action utilisateur devient disponible pour la segmentation en temps réel, la modélisation prédictive ou la personnalisation déclenchée, ce qui permet des expériences clients réellement adaptatives.

Mécanismes d'ingestion

Le mécanisme d'ingestion dépend du connecteur et de la stratégie de planification définis dans Data 360.

Gestion et récupération des erreurs

• Tolérance aux défauts en couches : Implémentez des mécanismes de validation et de nouvel essai à plusieurs niveaux : les kits de développement client gèrent les échecs temporaires avec un recul exponentiel, tandis que la couche d'ingestion utilise des files d'attente durables et des pipelines rejouables pour éviter la perte de données.
• Schéma et gouvernance des données : Versionnez et validez des schémas d'événements en continu. Les événements non valides ou évolutifs sont acheminés vers une File d'attente de refus de schéma ou de lettre morte pour un tri et une relecture sécurisés.
• Idempotence et déduplication : Utilisez des identificateurs d'événement stables et mettez à jour/insérer la sémantique pour garantir un traitement en une seule fois, même pendant les tentatives ou les relectures.
• Automatisation de la surveillance et du recouvrement : La surveillance continue du débit, de la latence et des taux d'erreur déclenche des workflows de récupération automatisés, qui garantissent une faible latence, une livraison fiable et des résultats de personnalisation en temps réel cohérents.

Considérations relatives à la conception impotente

• Chaque événement doit porter une clé d'identité ou un ID de message unique afin de permettre la duplication des soumissions en aval.
• Utilisez des clés métiers (p. ex. sessionID + eventTimestamp + userID) pour identifier les doublons.
• Définissez une période de déduplication (par exemple 24 heures) pendant laquelle les événements dupliqués sont ignorés ou filtrés.
• Utilisez des stratégies de mise à jour/insertion au besoin (par exemple, mettez à jour les compteurs ou les indicateurs au lieu d'insérer des doublons).

Considérations relatives à la sécurité

La sécurité fait partie intégrante du pipeline d'ingestion, de l'authentification au cryptage et au contrôle d'accès.

• Cryptage du transport : TLS 1.2+ pour toutes les connexions SDK → service de streaming.
• Cryptage des données au repos dans Data 360 et le flux marketing.
• SDK respecte les indicateurs de consentement utilisateur (RGPD/CCPA) et supprime le suivi si le consentement est refusé.
• Authentification du trafic SDK : assurez-vous que seuls les locataires/clients approuvés peuvent diffuser des événements.
• Métadonnées : chaque événement doit inclure l'ID source, l'horodatage, la version du schéma, l'ID de session, la clé d'idempotence.
• Accès à moindre privilège : Points de terminaison et connecteurs SDK limités à l'étendue d'ingestion d'événements; permutez régulièrement les identifiants.
• Classification des données : Annoter les informations d'identification personnelle dans les charges de travail d'événements, appliquer des politiques immédiatement après l'ingestion

Menus latéraux

Opportunité

• La rapidité dépend de l'activité de l'utilisateur et de la configuration de la diffusion en continu des événements.
• Généralement, les événements capturés via le kit de développement Salesforce Interactions SDK et livrés via le flux Marketing Cloud Personalization atteignent une latence de moins de 2 secondes à environ 2 secondes avant d'être disponibles dans le graphique en temps réel Data 360.
• Cela permet la segmentation, la personnalisation et l'activation quasi instantanées dans les sessions utilisateur actives.

Volumes de données

Les événements comportementaux individuels (par exemple, clic, affichage, ajout au panier d'achat) sont légers, généralement de 1 à 5 Ko par charge utile. Pour des propriétés numériques à grande échelle, attendez-vous à des milliers à des millions d'événements par minute. Pour garantir le débit et la résilience :

• Utilisez les mécanismes intégrés de traitement par lot et de nouvel essai du kit de développement pour les pages à fort trafic.
• Déchargez le traitement en rafale dans la couche tampon Marketing Cloud.
• Surveillez le débit d'ingestion et les ratios d'erreur en utilisant le tableau de bord des métriques du connecteur.

Gestion des états

Chaque événement inclut des métadonnées pour le contrôle d'état et de version :

• Schéma de version : Incorporez la version du schéma à chaque événement ; versionnez le Connecteur de personnalisation lors de la mise à jour du schéma.
• Gestion de la lecture : Les événements qui échouent en raison de problèmes réseau transitoires sont automatiquement réessayés par le kit de développement avec un backoff exponentiel.
• Clés Idempotency : Des identifiants uniques (sessionId + eventType + timestamp) garantissent que les événements rejoués ne créent pas de doublons dans Data 360.
• Gestion des décalages : Data 360 suit les validations réussies. Tous les événements non traités sont remis en file d'attente par le connecteur jusqu'à leur ingestion réussie.

Scénarios d'intégration complexes

Ce schéma s'intègre de façon transparente dans les architectures d'entreprise avancées :

• Couche d'enrichissement Edge : Ajoutez un middleware (par exemple, un proxy inverse ou une fonction sans serveur) pour injecter un contexte supplémentaire, par exemple une géolocalisation, un type d'appareil ou des métadonnées de campagne, avant que les événements atteignent Marketing Cloud.
• Hybride (Streaming + Lot) : Utilisez le connecteur Marketing Cloud pour des flux en temps réel et combinez-le à des tâches ETL par lot (par exemple, des données de commande) pour le rapprochement en aval.
• Activation de l'agent : Les événements mappés avec des objets modèle de données en temps réel peuvent déclencher Personnalisation Einstein, des workflows Agentforce ou des prises de décision pilotées par l'IA pour adapter l'expérience numérique dans le moment présent.
• Gouvernance multilocataire : Utilisez des indicateurs de consentement et des métadonnées sensibles aux locataires pour appliquer la confidentialité et la conformité dans des environnements multimarques ou multirégions.

Exemple

Une entreprise mondiale de commerce électronique fournit des recommandations de produits personnalisés et des contenus dynamiques aux acheteurs qui naviguent activement sur www.retailx.com, une application à page unique basée sur React. En utilisant le kit de développement Salesforce Interactions côté client, le site capture les vues de page, les clics sur les produits, les actions de panier d'achat et les interactions vidéo en temps réel. Ces événements transitent par le flux d'événements Marketing Cloud Personalization et le connecteur Personalization dans des objets lac de données Data 360, où ils sont modélisés dans des objets modèle de données et incorporés dans le graphique en temps réel. Grâce à cette architecture, les signaux comportementaux sont instantanément disponibles pour la segmentation, la personnalisation pilotée par Einstein et l'activation Agentforce, ce qui permet des expériences client réactives et en session

Context

Pour de nombreux processus critiques de l'entreprise, il est essentiel de garder Data 360 parfaitement aligné avec les toutes dernières mises à jour des systèmes CRM de base. Les équipes du service client, des ventes et du marketing dépendent d'informations à jour pour prendre des décisions, déclencher des parcours et activer l'automatisation. Ce schéma fournit un mécanisme qui permet de synchroniser les modifications apportées aux principaux objets Salesforce CRM, tels que Contact, Compte et Requête, dans Data 360 avec un délai minimal, sans l'inefficacité ou la latence des interrogations par lot fréquentes.

Problème

Comment Data 360 peut-elle maintenir un état presque parfaitement synchronisé avec les principaux objets Salesforce CRM, en s'assurant que les analytiques en aval, la segmentation et l'activation pilotée par l'IA fonctionnent toujours sur les données les plus récentes disponibles ?

Forces

Ce schéma introduit plusieurs contraintes techniques et considérations architecturales :

• Architecture pilotée par l'événement : La synchronisation doit être réactive, pilotée par des événements de modification dans l'organisation source CRM plutôt que par des tâches par lot périodiques.
• Prise en charge sélective des objets : Les objets Salesforce standard et personnalisés ne prennent pas tous en charge la diffusion en temps réel. Les architectes doivent référencer la liste des objets pris en charge pendant la conception afin d'éviter les écarts.
• Accès et autorisations : L'activation de la diffusion en continu nécessite d'attribuer l'autorisation système « Activer les autorisations pour CRM Streaming » à l'utilisateur de l'intégration dans l'organisation source.
• Actualisation des données vs. Coût de traitement : Bien que la synchronisation en temps quasi réel améliore la réactivité, un débit d'événement excessif peut nécessiter une mise à l'échelle horizontale et des mécanismes robustes de reprise après erreur.
• Sécurité et intégration de la couche de confiance : Toutes les données d'événements doivent être conformes aux infrastructures Trust et Security de Salesforce (cryptées en transit, validées pour la conformité du schéma et traitées dans les limites Trust de l'organisation).

Solution

L'approche recommandée consiste à utiliser le connecteur Salesforce CRM avec Streaming (Capture des données modifiées) activé. Lors de la création d'un flux de données pour un objet CRM pris en charge (par exemple Contact), les administrateurs peuvent basculer vers l'option « Activer la diffusion en continu ». Sous le capot, la plate-forme de Capture des données de modification (CDC) de Salesforce publie un message ChangeEvent chaque fois qu'un enregistrement est créé, mis à jour, supprimé ou non supprimé dans l'organisation CRM source. Le connecteur Data 360 CRM s'abonne à ces événements CDC et applique en temps quasi réel les modifications correspondantes à l'objet lac de données (DLO) mappé dans Data 360. Cela garantit une synchronisation continue entre CRM et Data 360 avec une intervention manuelle minimale.

Croquis

Ce diagramme illustre la séquence des étapes d'ingestion des données depuis CRM vers Data 360 en temps quasi réel

Dans ce scénario :

• La modification est effectuée dans Salesforce CRM (créer/mettre à jour/supprimer/annuler la suppression).
• CDC publie un ChangeEvent dans le Bus d'événement Salesforce interne.
• Le connecteur Data 360 CRM s'abonne au Bus d'événement en utilisant un curseur de relecture durable.
• La charge de travail des événements est validée pour le schéma, les autorisations et l'intégrité des données.
• Data 360 écrit l'événement validé dans l'objet lac de données mappé.
• Si cette option est activée, les objets modèle de données mappés sont mis à jour en temps quasi réel, ce qui favorise la segmentation et l'activation.

Résultats

Data 360 maintient un miroir synchronisé en continu des données CRM clés. Cela active :

• Déclencheurs en temps réel (par exemple, le parcours est lancé lors de la création d'une requête).
• Segmentation à jour (p. ex. déplacer les clients vers le segment « Gold » lors d'un changement de statut du compte).
• Analyses et personnalisation plus précises basées sur le contexte CRM live.

Mécanismes d'ingestion

Le mécanisme d'ingestion de ce schéma est géré en natif via le connecteur Salesforce CRM avec la Capture des données de modification (CDC) activée. Data 360 agit en tant qu'abonné au flux d'événements CDC, garantissant une synchronisation fiable et à faible latence entre l'organisation CRM source et Data 360.

Gestion et récupération des erreurs

• Reprise automatique des défauts : Le connecteur CRM résout automatiquement les erreurs transitoires de réseau ou de plate-forme en utilisant un backoff exponentiel et achemine les échecs persistants vers la file d'attente des lettres mortes (DLQ) pour la relecture.
• Résilience du schéma et de l'authentification : Les incohérences de schéma sont mises en quarantaine dans la File d'attente de refus du schéma pour examen par l'administrateur, tandis que des erreurs d'authentification ou d'autorisation déclenchent des tentatives contrôlées et des alertes via Data 360 Monitoring.
• Continuité garantie des événements : Les ReplayID durables garantissent l'absence de perte d'événements pendant les temps d'arrêt du connecteur. Les événements manqués sont réhydratés via des fenêtres de relecture ou des tâches de resynchronisation par lot.
• Intégrité des données et commande : L'idempotence intégrée (RecordID + SequenceNumber) empêche les doublons, et ChangeEventHeader.sequenceNumber préserve l'ordre des événements correct pour chaque enregistrement CRM.

Considérations relatives à la conception impotente

• Unicité des événements : Chaque événement CDC porte un ReplayID et ChangeEventHeader.entityName pour la déduplication déterministe.
• Mettre à jour/insérer une stratégie : Implémentez une logique UPSERT basée sur l'ID d'enregistrement pour vous assurer que les événements répétés ne créent pas de doublons.
• Gestion de la lecture : Utilisez le curseur de relecture du connecteur pour reprendre à partir du dernier décalage engagé en cas de pannes transitoires.
• **Évolution du schéma : **Gérez une version de schéma dans les métadonnées d'événements et mettez à jour les mappages d'objet lac de données lorsque le schéma CRM change.

Considérations relatives à la sécurité

La sécurité fait partie intégrante du pipeline d'ingestion, de l'authentification au cryptage et au contrôle d'accès.

• Encryption and Trust : Tous les événements sont transmis en utilisant TLS 1.2+ et stockés cryptés au repos dans Data 360.
• Contrôle d'accès : Seuls les connecteurs authentifiés qui disposent des autorisations d'intégration appropriées peuvent s'abonner à des canaux CDC.
• Validation du schéma : Chaque charge utile d'événement est validée par rapport au schéma d'objet lac de données avant l'ingestion.
• Propagation du consentement : Le consentement et les métadonnées de classification des données circulent en aval avec chaque événement afin de préserver la confidentialité et la conformité (RGPD, CCPA).
• Gouvernance opérationnelle : Les événements sont consignés, audités et surveillés pour détecter les anomalies de relecture, de rejet de schéma et de débit via Data 360 Trust Layer.

Menus latéraux

Opportunité

• Les événements CDC sont traités en temps quasi réel, généralement dans les secondes qui suivent la modification du CRM.
• La latence peut varier selon le volume d'événements et le débit du connecteur, mais Data 360 garantit une disponibilité inférieure à la minute pour les objets pris en charge.

Volumes de données

• Chaque charge utile d'événement est légère (~1 à 5 Ko).
• Pour des objets à taux de modification élevé tels que Requête ou Contact, assurez-vous que les limites en débit correspondent aux allocations d'événements Salesforce CDC.

Gestion des états

Chaque événement inclut des métadonnées pour le contrôle d'état et de version :

• ID de lecture : Utilisé pour la récupération d'événements séquentiels.
• Schéma de version : Gérez les métadonnées de version pour gérer les changements de contrat.
• Clés Idempotency : Dupliquer les relectures entre les tentatives.
• Décalage de l'engagement : Data 360 conserve l'état d'engagement après chaque lot d'événements réussi.

Scénarios d'intégration complexes

Ce schéma s'intègre de façon transparente dans les architectures d'entreprise avancées :

• Hybride (Streaming + Lot) : Utilisez CDC pour les mises à jour delta et les tâches en masse pour les actualisations complètes.
• Streaming inter-organisations : Plusieurs organisations sources peuvent diffuser dans le même locataire Data 360, unifié via des mappages d'objets modèle de données.
• Activation de l'agent : Les mises à jour d'objets en temps réel déclenchent des automatisations Einstein ou Agentforce.
• Acheminement des événements : Un middleware (par ex. MuleSoft ou Relais d'événements) peut enrichir ou acheminer les messages CDC avant l'ingestion.

Exemple

Une banque mondiale souhaite s'assurer que les modifications apportées aux données des clients dans Salesforce Sales Cloud se reflètent instantanément dans Data 360.Lorsque l'adresse d'un Contact est mise à jour dans Sales Cloud, le mécanisme de Capture des données de modification publie un ContactChangeEvent.Le Connecteur Data 360 CRM consomme cet événement, applique la mise à jour à l'objet lac de données Customer et met automatiquement à jour tous les profils Customer 360 associés. Cela déclenche une Einstein Next Best Action pour vérifier la nouvelle adresse, c'est-à-dire compléter la boucle de commentaire dans les secondes qui suivent la modification CRM d'origine.

Context

Les entreprises numériques modernes s'appuient sur des plates-formes de streaming d'événements en temps réel telles que Amazon Kinesis Data Streams et Amazon MSK (Managed Streaming for Apache Kafka) pour capturer des flux de données continus à partir d'applications distribuées, d'appareils Internet des objets et de systèmes transactionnels. Data 360 permet l'ingestion directe depuis ces plates-formes via des connecteurs natifs et internes, ce qui élimine la nécessité de solutions ETL personnalisées ou basées sur un middleware. Ce modèle est conçu pour l'ingestion de données à haut débit et à faible latence, qui alimente les connaissances en temps quasi réel, la personnalisation et l'activation pilotée par l'IA.

Problème

Comment une entreprise peut-elle connecter en toute sécurité et efficacement Data 360 à des rubriques AWS Kinesis ou AWS MSK Kafka pour ingérer en permanence des données structurées d'événements et de profils, en garantissant la conformité, l'évolutivité et la gouvernance du schéma ?

Forces

Ce schéma introduit de multiples considérations architecturales et opérationnelles :

• Disponibilité du connecteur natif : Salesforce fournit des connecteurs natifs globalement disponibles pour Amazon Kinesis et Amazon MSK. Ces connecteurs offrent une prise en charge interne et éliminent la nécessité de pipelines basés sur une API personnalisée.
• Authentification et sécurité : Chaque connecteur nécessite une authentification au niveau AWS.
• Pour Kinesis, cela utilise Clé d'accès AWS et Clé secrète, régies par des stratégies IAM.
• Pour MSK, l'authentification peut être configurée via Clé/Secret d'accès ou OpenID Connect (OIDC).
• Définition du schéma : Data 360 nécessite un schéma pour interpréter la charge de travail en continu. Pour Kinesis, le fichier de schéma est chargé lors de la configuration de la connexion, définissant la structure des événements et les mappages de champs.
• Source de configuration :
• Le connecteur Kinesis s'abonne à un nom de flux Kinesis spécifique.
• Le connecteur MSK s'abonne à une rubrique Kafka dans le cluster MSK.
• Accès réseau : Pour des environnements sécurisés, les connecteurs peuvent être configurés avec l'acheminement PrivateLink ou VPC, ce qui garantit qu'aucune donnée ne traverse l'Internet public.
• Gouvernance opérationnelle : Le débit en continu, la validation du schéma et les événements d'authentification sont surveillés au sein de Data 360 Trust Layer, ce qui garantit la conformité et la traçabilité.

Solution

La solution exploite les connecteurs Amazon Kinesis natifs ou Amazon MSK dans Data 360.

Croquis

Ce diagramme illustre la séquence des étapes d'ingestion des données de plates-formes d'événements telles que Kafka et Kinesis dans Data 360 en temps quasi réel

Dans ce scénario :

• Les applications ou les appareils publient des événements dans Kinesis Stream ou MSK Topic.
• Le connecteur Data 360 s'authentifie en utilisant des identifiants AWS ou un jeton OIDC.
• Le connecteur interroge ou s'abonne continuellement au flux.
• Les événements sont organisés, validés pour le schéma et la stratégie, puis engagés dans Objet lac de données (DLO).
• S'ils sont mappés, les objets modèle de données (DMO) sont mis à jour en temps quasi réel pour l'activation.
• La couche de surveillance suit les métriques, les rejets de schéma et la latence.

Résultats

Ingestion continue et à faible latence de données structurées directement depuis AWS Kinesis ou MSK dans Data 360. Les données sont immédiatement disponibles pour :

• Résolution de l'identité
• Segmentation en temps réel
• Activation IA Einstein
• Déclencheurs pilotés par Agentforce Élimine la dépendance à l'ETL par lot, en activant des architectures basées sur le flux alignées avec les conceptions pilotées par les événements d'entreprise.

Mécanismes d'ingestion

Gestion et récupération des erreurs

• Récupérations automatiques : Les connecteurs réessayent les erreurs transitoires de réseau ou de plate-forme avec un backoff exponentiel.
• Refus de schéma : Les charges utiles non valides sont acheminées vers la file d'attente de rejet du schéma pour examen par l'administrateur.
• DLQ Replay : Les échecs persistants sont capturés dans des files d'attente en lettres mortes pour être retraités.
• Contrôle de l'immunité : Les clés d'événement ou les numéros de séquence garantissent la déduplication et l'ingestion ordonnée.
• Surveillance de l'intégration : Tous les échecs, tentatives et métriques de débit sont exposés dans les tableaux de bord Data 360 Monitoring.

Considérations relatives à la conception impotente

• Unicité et suivi des événements : Chaque événement est attribué à une clé unique déterministe (par exemple, PartitionKey + SequenceNumber pour Kinesis, ou Rubrique + Partition + Offset pour MSK) pour garantir l'ingestion exacte une fois.
• Contrôle du connecteur : Les connecteurs Data 360 conservent le dernier décalage traité ou numéro de séquence pour reprendre l'ingestion en toute sécurité après des échecs ou un redémarrage.
• Déduplication et logique UPSERT : Pendant les validations d'objet lac de données, les événements dupliqués sont détectés et ignorés. Les enregistrements valides sont mis à jour en utilisant la clé unique pour plus de cohérence.
• Contrôle de lecture et de récupération : Les événements échoués ou retardés sont rejoués à partir des décalages stockés via les files d'attente Lettre morte et Relecture, ce qui garantit une récupération fiable sans duplication.

Considérations relatives à la sécurité

La sécurité fait partie intégrante du pipeline d'ingestion, de l'authentification au cryptage et au contrôle d'accès.

• Authentification : Sécurisez l'échange d'identifiants en utilisant des stratégies AWS IAM ou OIDC.
• Cryptage : Données cryptées en transit (TLS 1.2+) et au repos (AES-256) dans Data 360.
• Contrôle d'accès : Rôles de moindre privilège appliqués ; connecteurs limités à des flux/rubriques spécifiques.
• Gouvernance : Métadonnées de lignage et de classification appliquées à chaque enregistrement pour une traçabilité totale.
• Sécurité réseau : Vous pouvez également déployer dans des sous-réseaux privés en utilisant AWS PrivateLink.

Menus latéraux

Opportunité

• Traitement en temps quasi réel : Les connecteurs CDC et streaming traitent les événements en quelques secondes après les modifications de la source, garantissant généralement une actualisation des données inférieure à la minute.
• Latence déterministe : Le décalage de bout en bout dépend du débit source, de la mise en lot des événements et des conditions réseau, mais Data 360 garantit une latence prévisible pilotée par le contrat de niveau de service pour les objets pris en charge.
• Échelle élastique : Le pipeline d'ingestion s'adapte automatiquement lorsque le volume d'événements est élevé, préservant ainsi l'actualité même pendant les pics de données.
• Visibilité opérationnelle : Les tableaux de bord de surveillance exposent le décalage des événements, les horodatages d'engagement et le statut de relecture pour l'assurance de latence et le dépannage.

Volumes de données

• Charges utiles légères : Les événements CDC ou streaming individuels sont compacts (1 à 5 Ko de taille typique), optimisés pour les mises à jour à haute fréquence.
• Objets à fort changement : Pour les entités volatiles (p. ex. requête, contact, commande), les architectes doivent s'assurer que les allocations du CDC et le débit des événements correspondent aux taux de mise à jour attendus.
• Flux parallèles : Data 360 prend en charge l'ingestion de flux multiples pour l'échelle horizontale entre des volumes d'objets importants ou plusieurs organisations sources.
• Traitement de la contre-pression : Les mécanismes de laminage intégrés maintiennent la stabilité de l'ingestion sous charge sans laisser tomber les événements.

Gestion des états

Chaque événement inclut des métadonnées pour le contrôle d'état et de version :

• Relecture et suivi décalé : Chaque événement contient des métadonnées d'ID de lecture et de séquence, ce qui permet la livraison commandée et la récupération basée sur un point de contrôle.
• Schéma de version : Les balises de version dans les en-têtes d'événement garantissent un traitement rétrocompatible lorsque les schémas sources évoluent.
• Clés Idempotency : Chaque événement inclut une transaction ou une clé de validation unique, ce qui permet à Data 360 de dupliquer les relectures et les tentatives en toute sécurité.
• Atomic Commit : Le pipeline d'ingestion marque les compensations comme terminées uniquement lorsque les engagements en aval dans les objets lac de données réussissent, ce qui garantit la cohérence.

Scénarios d'intégration complexes

Ce schéma s'intègre de façon transparente dans les architectures d'entreprise avancées :

• Ingestion hybride : Combinez le CDC pour les deltas incrémentiels à des flux de données en masse pour des actualisations complètes, en préservant la fraîcheur et l'exhaustivité.
• Streaming inter-organisations : Plusieurs organisations CRM ou ERP peuvent publier dans le même locataire Data 360, unifié via le mappage d'objets modèle de données et l'alignement de l'ontologie.
• Enrichissement des événements : Un middleware (par exemple, MuleSoft, Relais d'événements) peut enrichir, filtrer ou acheminer les données en continu avant qu'elles atteignent Data 360.
• Activation de l'IA et de l'agent : Les mises à jour en temps réel déclenchent une automatisation en aval, par exemple des prédictions Einstein ou des réponses Agentforce, dans les secondes qui suivent l'événement d'origine.

Exemple

Une entreprise de vente au détail mondiale utilise AWS Kinesis pour diffuser les données des points de vente et des interactions Web.Le connecteur Kinesis de Data 360 s'authentifie via des identifiants IAM et ingère en permanence des événements dans un objet lac de données Transaction.Chaque enregistrement est validé par un schéma, enrichi de métadonnées et immédiatement propagé au DMO Client.En quelques secondes, les modèles IA Einstein mettent à jour les segments clients et Agentforce déclenche des recommandations Next-Best-Offre en temps réel — réalisant ainsi une boucle de personnalisation entièrement pilotée par l'événement.

Zero Copy est plus qu'une méthode d'intégration, c'est un changement fondamental dans la façon dont les données d'entreprise se déplacent, ou plutôt ne se déplacent pas. Traditionnellement, l'intégration de données nécessitait de copier de grands volumes d'enregistrements via des pipelines ETL, créant des magasins de données redondants, des délais de synchronisation et des défis de gouvernance. Zéro copie élimine tout cela. Dans ce modèle, Data 360 se connecte directement à des plates-formes de données externes telles que Snowflake et Databricks, en lisant et en activant en toute sécurité les données en place, sans jamais les déplacer ni les dupliquer. Le résultat est un pont transparent entre votre maison de lac de données d'entreprise et l'écosystème Salesforce, offrant un accès instantané, une réduction des frais opérationnels et une gouvernance des données renforcée.

Les capacités de copie zéro entrante permettent à Data 360 d'interroger et d'harmoniser les données externes à la source (telles que les profils clients, les transactions ou les données de produits) stockées dans Snowflake ou Databricks. Au lieu d'ingérer des fichiers, Data 360 établit une connexion sécurisée et sensible aux métadonnées qui exploite les définitions de schéma et les stratégies de sécurité existantes dans l'entrepôt externe.

• Fédération directe : Data 360 lit les données en place via des requêtes sécurisées et optimisées sans réplication.
• Gouvernance unifiée : Les données restent soumises au cadre de sécurité, de contrôle d'accès et de conformité du système source.
• Efficacité opérationnelle : Élimine les duplications de frais généraux et de stockage ETL, réduisant ainsi les coûts et la complexité.
• Préparation en temps réel : Active l'harmonisation à la demande : dès que les données sont mises à jour dans Snowflake, elles peuvent être immédiatement activées dans Data 360.

Context

Les entreprises modernes pilotées par les données gèrent des pétaoctets de données clients, de transactions et de télémétrie dans des plates-formes lac de données à l'échelle du cloud telles que Snowflake et Databricks. Ces environnements sont la source unique de preuve pour les analytiques, l’IA et la conformité. Data 360 introduit Zero CopyData Federation, qui permet à Data 360 d'interroger et d'utiliser directement des jeux de données externes en place, sans copier, transformer ni stocker des données redondantes. Ce schéma permet aux organisations d'étendre le tissu Customer 360 à leur infrastructure existante d'entrepôt de données ou de Lakehouse, en réalisant une unification et une activation en temps réel avec zéro duplication, zéro latence et zéro compromis sur la gouvernance.

Problème

Comment les entreprises peuvent-elles exploiter des jeux de données enrichis déjà organisés dans Snowflake, Databricks ou des formats lac ouvert tels que Apache Iceberg — pour la segmentation, la résolution de l'identité et l'activation dans Data 360 — sans les coûts, la latence et les frais généraux de gouvernance des pipelines ETL ou du mouvement des données physiques ?

Forces

Ce schéma introduit de multiples considérations architecturales, de sécurité et de performance :

Réseau et sécurité

• Data 360 doit établir une connexion sécurisée et privée avec l'entrepôt externe ou Lakehouse.
• Généralement configuré en utilisant Salesforce Private Connect ou PrivateLink/VPC Peering, ce qui garantit que le trafic ne quitte jamais le réseau contrôlé du client.
• Les systèmes externes doivent ajouter les adresses IP Data 360 à la liste d'autorisations et appliquer le cryptage TLS 1.2+.

Authentification et contrôle d'accès

• Prend en charge l'authentification par paire de clés, OAuth 2.0 ou la délégation Trust basée sur le fournisseur d'identité (Data 360 agissant en tant que client de confiance)
• Le contrôle d'accès basé sur le rôle (RBAC) dans le système externe applique l'accès avec le moindre privilège à l'exécution de requêtes.

Performances et dépendance au calcul

• La fédération de requêtes envoie automatiquement l'exécution SQL vers le bas dans Snowflake ou Databricks, en exploitant leurs clusters de calcul.
• Les performances et l'échelle de coût avec la charge de requête externe - la latence de segmentation et le coût sont liés à la configuration du calcul externe.

Normes évolutives : Fédération de fichiers

• Un modèle de nouvelle génération, Fédération de fichiers, exploite les formats de tableau ouverts tels que Apache Iceberg ou Delta Lake, permettant à Data 360 de lire directement depuis le stockage d'objets (par ex. Amazon S3, Azure ADLS, Google Cloud Storage).
• En contournant la couche de calcul source, Fédération de fichiers réduit considérablement la latence et le coût des charges de travail analytiques lourdes en lecture tout en préservant l'intégrité du schéma.

Gouvernance et conformité

• Les données ne quittent jamais la plate-forme source. Les stratégies de conformité, de cryptage et de rétention restent appliquées à l'origine.
• Tous les attributs de métadonnées, de lignage et de consentement se propagent dans la Trust Layer de Data 360 pour garantir une traçabilité de bout en bout.

Solution

L'approche recommandée consiste à utiliser des connecteurs Zero Copy natifs pour Snowflake, Databricks ou Fédération de fichiers dans Data 360.

Croquis

Le diagramme ci-dessous montre comment configurer une connexion zéro copie et créer des objets lac de données externes dans Data 360.

Dans ce scénario :

• L'administrateur configure une connexion Zero Copy dans la Configuration de Data 360 (Snowflake, Databricks ou Fédération de fichiers).
• L'authentification sécurisée et l'acheminement réseau sont établis (Private Connect / OAuth / Paire de clés).
• L'administrateur crée un flux de données en sélectionnant la source externe, en parcourant les bases de données live, les schémas et les tableaux.
• Au lieu de copier des données, Data 360 crée un objet lac de données externe (Objet lac de données), un pointeur de métadonnées référençant le tableau live ou le fichier Iceberg.
• Les objets lac de données externes sont mappés avec des entités Customer 360 (p. ex., Client, Transaction, Produit).
• Data 360 interroge la source en place pendant la segmentation, l'activation ou le calcul des connaissances.
• Tous les accès, lignages de requêtes et métadonnées sont audités dans Data 360 Trust Layer.

Résultats

• Les données externes sont conservées dans Snowflake, Databricks ou S3, pas d'ETL, pas de duplication, pas de stockage supplémentaire.
• Data 360 obtient un accès en temps réel et en lecture aux données de l'entreprise pour la résolution de l'identité, les connaissances calculées et l'activation.
• Les organisations gardent un contrôle total dans leurs cadres de gouvernance, de cryptage et de conformité existants.
• Ce schéma permet une véritable architecture Zero Copy, combinant les performances de l'accès local à la gouvernance du stockage fédéré.

Mécanismes d'appel

Le mécanisme d'appel dépend de la solution choisie pour implémenter ce schéma.

Gestion et récupération des erreurs

• Reprise automatique et restauration des requêtes : La connectivité transitoire ou les expirations de requête sont automatiquement ré-essayées en utilisant un backoff exponentiel.
• Isolation de la non concordance du schéma : Les modifications apportées au schéma source (p. ex. nouvelles colonnes) sont consignées dans la file d'attente de rejet du schéma. Les administrateurs peuvent remapper ou actualiser les métadonnées du schéma.
• Basculement de l'authentification : Si les identifiants expirent, Data 360 tente une nouvelle connexion en utilisant des jetons d'actualisation stockés ou des stratégies de rotation de clé.
• Détection de la disponibilité du calcul : Si le cluster Snowflake ou Databricks est interrompu, Data 360 suspend les tâches de fédération et tente de nouveau de le faire lorsque le calcul reprend.
• Surveillance de l'intégration : Toutes les métadonnées d'intégrité de la connexion, de latence des requêtes et de lignage visibles dans les tableaux de bord Data 360 Monitoring.

Considérations relatives à la conception impotente

• Déterminisme de requête : Les requêtes fédérées utilisent une sémantique cohérente pour les clichés instantanés afin de garantir des lectures stables et répétitives pendant la segmentation ou l'activation.
• Versionnement DLO externe : Chaque requête fédérée inclut des métadonnées de schéma et d'horodatage pour le suivi de lignage.
• Accès sans décalage : Comme Zero Copy est en lecture seule, il ne s'appuie pas sur les décalages d'événements. La cohérence est appliquée via les garanties ACID du système externe (Snowflake/Delta Lake).
• Gestion des dérives de schéma : Maintenir les mappages de schémas avec version dans Data 360 ; actualiser les métadonnées d'objet lac de données externe sur l'évolution de la source.

Considérations relatives à la sécurité

La sécurité fait partie intégrante du modèle de fédération – sans compromis de Trust ou de conformité.

• Cryptage : Tous les échanges de données utilisent le protocole TLS 1.2+ ; les entrepôts externes cryptent au repos en utilisant AES-256.
• Contrôle d'accès : Les tableaux externes sont accédés via des rôles de moindre privilège avec des autorisations en lecture seule.
• Isolement du réseau : Les routes Private Connect ou VPC empêchent toute exposition aux points de terminaison publics.
• Flux de données régi : Les métadonnées de lignage, de consentement et de classification sont transmises dans Data 360 Trust Layer pour l'application des politiques.
• Auditabilité : Chaque requête fédérée et événement d'accès au schéma est consigné pour la traçabilité de la conformité (RGPD, CCPA, HIPAA).

Menus latéraux

Opportunité

• Les requêtes sont exécutées en direct sur l'entrepôt ou le stockage externe, ce qui garantit une visibilité en temps réel du dernier état des données.
• Les exécutions de segmentation ou d'activation reflètent les modifications à la seconde près dans les tableaux Snowflake, Databricks ou Iceberg soutenus par S3.
• La latence des requêtes dépend du niveau de performance du système source, généralement de quelques secondes à plusieurs dizaines de secondes par requête.
• Idéal pour les charges de travail analytiques et IA exigeant un accès aux données « frais, pas copié ».

Volumes de données

• Prend en charge les jeux de données à l'échelle du pétaoctet stockés nativement dans Snowflake ou Databricks sans réplication.
• Data 360 récupère uniquement les résultats, pas les jeux de données bruts, ce qui réduit les coûts réseau et de calcul.
• Fédération de fichiers optimise les analyses volumineuses grâce à l'élagage des partitions et au pushdown des colonnes.
• Évolue linéairement avec la capacité de calcul de l'entrepôt et la couche d'orchestration de requêtes fédérées de Data 360.

Gestion des états

• Les objets lac de données externes conservent les métadonnées de connexion, de schéma et de version dans Data 360.
• L'évolution du schéma est gérée automatiquement via des cycles d'actualisation des métadonnées.
• Le lignage des requêtes inclut l'horodatage, l'identité de l'utilisateur et des métriques d'exécution pour la traçabilité.
• Aucune ingestion ni compensation n'est maintenue, la cohérence est héritée des garanties ACID de la source externe.

Scénarios d'intégration complexes

• Mode hybride : Combinez Zero Copy (pour la fédération live) avec l'ingestion (pour les jeux de données historiques).
• Accès inter-entrepôts : Data 360 peut fédérer à partir de plusieurs locataires Snowflake ou Databricks dans une seule organisation.
• Interopérabilité IA/BI : Les systèmes externes (p. ex. SageMaker, Tableau, Power BI) peuvent interroger les profils enrichis de Data 360 via la copie Zero inverse.
• Extension Fédération de fichiers : Les entreprises qui adoptent les formats lac ouvert (Iceberg/Delta) peuvent unifier les données structurées et non structurées dans un seul modèle fédéré.

Exemple

Une entreprise financière internationale stocke toutes les données transactionnelles et d'interaction dans Snowflake, tout en conservant les attributs des clients et les événements marketing dans Data 360. En utilisant la fédération de données Zero Copy, Data 360 se connecte en toute sécurité à Snowflake via Private Connect.Lorsqu'une tâche de segmentation est exécutée, par exemple « Les clients qui ont dépensé plus de 10 000 € au cours des 30 derniers jours, Data 360 envoie automatiquement la requête à Snowflake, récupère les résultats agrégés et active instantanément ces profils dans Journey Builder. Aucune réplication ou ETL requise. Cet exemple utilise une intelligence fédérée en temps réel, unifiée dans l'écosystème des données d'entreprise.

La copie zéro sortante étend le même principe à l'inverse. Au lieu d'exporter ou de copier des jeux de données depuis Data 360, des systèmes externes comme Snowflake peuvent interroger directement Data 360, le traitant comme une source fédérée d'Intelligence client enrichie.

• Fédération inverse : Les analytiques externes ou les plates-formes IA peuvent accéder aux données de profil unifié de Data 360 sans les extraire.
• Activation des données à la source : Les équipes commerciales peuvent exploiter les connaissances là où résident déjà les données, que ce soit pour la modélisation IA, la génération de rapports ou la personnalisation des clients.
• Interopérabilité sans latence : Aucune exportation par lot ni tâche de synchronisation. Les connaissances circulent instantanément entre les plates-formes.
• Sémantique cohérente : Les deux systèmes partagent la même ontologie et les mêmes mappages de schémas. Par conséquent, le contexte et la signification sont préservés dans les écosystèmes. Zero copy redéfinit le rôle de Data 360 d'un référentiel de données à une couche d'activation sémantique. Elle permet aux organisations de conserver les données à l'endroit exact où elles se trouvent, dans des entrepôts gouvernés et hautement performants, tout en conservant toute leur valeur dans les limites Trust de Salesforce. Ce schéma s'aligne sur les architectures modernes de maillage de données et natives de l'IA : les données restent décentralisées, mais l'intelligence devient unifiée. Les architectes peuvent désormais élaborer des pipelines d'activation plus rapides, plus légers et plus conformes, sans aucune copie.

Context

Les entreprises modernes opèrent de plus en plus dans des écosystèmes de données multi-plate-formes, où Salesforce Data 360 pilote des profils clients unifiés et l'activation, tandis que les entrepôts de données d'entreprise tels que Snowflake ou Databricks servent d'ossature analytique pour la science des données, l'apprentissage machine et les charges de travail BI. La capacité Partage sortant Zero Copy de Salesforce Data 360 relie ces environnements de façon transparente, ce qui permet un accès gouverné, sécurisé et en temps réel aux données Data 360 harmonisées directement dans Snowflake ou Databricks, sans réplication ni ETL. Cela permet aux analystes et aux scientifiques des données d'interroger, de visualiser et de modéliser sur les mêmes données live et approuvées qui propulsent l'activation du marketing, des ventes et du service.

Problème

Comment une entreprise peut-elle exposer en toute sécurité et efficacement les profils clients unifiés et les métriques calculées de Data 360 (par exemple, Valeur de durée de vie, Risque de résiliation) à des systèmes analytiques externes, sans copier les données, rompre la gouvernance ou introduire une latence via les pipelines ETL inverses traditionnels ?

Forces

Ce schéma introduit de multiples considérations architecturales, de gouvernance et opérationnelles :

• Sécurité régie : L'accès aux données Data 360 doit être contrôlé, précis et auditable. Le partage Zero Copy utilise un accès explicite au niveau de l'objet, ce qui garantit que seuls les objets modèle de données (DMO) et les objets connaissances calculées (CIO) approuvés sont disponibles pour les consommateurs désignés.
• Sélection d'objet explicite : Les administrateurs organisent les données à partager via un Partage de données, en sélectionnant explicitement les objets à exposer. Cela préserve la gouvernance et réduit l'exposition aux risques.
• Configuration bilatérale : Data 360 et l'entrepôt externe nécessitent une configuration. Data 360 définit la Cible de partage de données (Snowflake/Databricks), alors que le système de réception doit accepter et instancier le partage.
• Modèle de fédération de requêtes : Une fois acceptée, la plate-forme externe interroge les données Data 360 live et régies via des vues fédérées, éliminant ainsi les tâches d'extraction ou les cycles d'actualisation manuels.
• Évolution des normes ouvertes : Des approches émergentes comme Fédération de fichiers exploitent les formats de tableau ouverts (par exemple, Apache Iceberg) pour activer l'accès en lecture seule à la couche de stockage, ce qui améliore l'évolutivité, les performances et l'interopérabilité entre les architectures multicloud.

Solution

La solution exploite le Partage de copie zéro natif de Salesforce Data 360 avec des plates-formes de données telles que Snowflake ou Databricks.

Croquis

Le diagramme ci-dessous illustre un appel depuis Salesforce Data 360 vers une plate-forme de données externe.

Dans ce scénario :

• L'administrateur Data 360 définit un Partage de données comprenant les objets Client unifié et Connaissances calculées.
• Une cible de partage de données (compte Snowflake ou Databricks) est enregistrée avec des identifiants sécurisés et des stratégies de gouvernance.
• Data 360 publie le partage ; les administrateurs Snowflake/Databricks l'acceptent.
• Les données partagées sont affichées sous forme de tableaux sécurisés en lecture seule dans l'entrepôt.
• Les analystes, les outils de BI ou les pipelines ML interrogent les données client live et unifiées sans les copier ni les synchroniser.
• Tous les accès sont audités dans les journaux de gouvernance de Data 360 Trust Layer et d'entrepôt.

Résultats

• Les entrepôts externes obtiennent un accès en temps réel et interrogeable aux données Data 360 harmonisées.
• Élimine les pipelines ETL inverses, réduisant ainsi la charge opérationnelle et la latence.
• Active la formation IA/ML, la modélisation prédictive et la BI avancée directement sur des données unifiées.
• Maintient l'absence de duplication, une gouvernance solide et un contrôle d'accès sécurisé par conception.
• Termine la boucle bidirectionnelle Zero Copy, dans laquelle la fédération entrante et le partage sortant coexistent sous un modèle de gouvernance unique.

Mécanismes d'appel

Le mécanisme d'appel dépend de la solution choisie pour implémenter ce schéma.

Gestion et récupération des erreurs

• Récupérations de connexion : Essais automatisés en cas d'échec de connexion ou d'authentification transitoire entre Data 360 et l'entrepôt.
• Validation du partage : Les configurations de partage non valides ou non autorisées sont mises en quarantaine dans une file d'attente de révision de l'administrateur.
• Surveillance de l'intégrité de la synchronisation : **** Data 360 expose le statut de partage en direct, la latence des requêtes et les journaux d'accès via des tableaux de bord Monitoring.
• Révocation de l'accès : Les administrateurs peuvent révoquer des partages instantanément, désactivant l'accès aux deux extrémités sans copie de données résiduelle.
• Piste d'audit régie : Toutes les modifications de configuration et d'accès sont consignées pour vérification de la conformité.

Considérations relatives à la conception impotente

• Identification de partage cohérente : Chaque paire Partage de données et Cible de partage de données a un identifiant unique, ce qui garantit une gouvernance exacte et une traçabilité de l'accès.
• Vues immuables : Les objets de données partagés sont en lecture seule. Les consommateurs ne peuvent pas muter l'état, ce qui garantit des résultats déterministes et la conformité.
• Cycle de vie de partage atomique : La publication, la révocation et les mises à jour de partage sont des opérations atomiques, entièrement terminées ou annulées.
• Cohérence de lecture : Lorsque les données Data 360 sont actualisées, les requêtes côté entrepôt renvoient toujours le dernier cliché instantané cohérent, ce qui élimine les lectures périmées.

Considérations relatives à la sécurité

La sécurité sous-tend chaque aspect du partage de copie zéro :

• Authentification: Mutual Trust établi en utilisant OAuth 2.0, échange de clés privées ou fédération d'identité (OIDC).
• Cryptage: Données cryptées en transit (TLS 1.2+) et au repos (AES-256).
• Contrôle d'accès: Les autorisations au niveau de l'objet appliquent automatiquement l'accès avec le moindre privilège, régi par Data 360 Trust Layer.
• Sécurité réseau: Les échanges de données se font via des liens réseau privés tels que Salesforce Private Connect ou les API Secure Data Exchange.
• Métadonnées de gouvernance: Chaque objet partagé inclut des attributs de lignage, de classification et de consentement pour une traçabilité totale et la conformité réglementaire.

Menus latéraux

Opportunité

• Disponibilité en temps réel : Les données partagées reflètent l'état le plus récent de Data 360 sans délais de réplication.
• Fraîcheur de la requête : Les modifications apportées aux objets modèle de données ou aux DSI se propagent instantanément aux vues d'entrepôt partagées.
• Élasticité des performances : Le pushdown des requêtes s'adapte dynamiquement aux ressources de calcul de l'entrepôt.
• Surveillance : Les tableaux de bord live exposent des métriques de performance de latence et de requête partagées pour l'assurance opérationnelle.

Volumes de données

• Partage évolutif : Prend en charge le partage de données granulaires au niveau de l'objet ou du domaine complet, selon les besoins analytiques.
• Performances de requête optimisées : Snowflake/Databricks met intelligemment en cache les données partagées afin de réduire la latence.
• Efficacité de stockage : Zéro duplication élimine les coûts de stockage redondants.
• Option Fédération de fichiers : Pour des jeux de données à l'échelle du pétaoctet, le partage direct basé sur Iceberg contourne le calcul et accélère l'accès.

Gestion des états

• Évolution du schéma : Les schémas contrôlés par version garantissent la compatibilité lorsque le modèle Data 360 évolue.
• Suivi de l'état d'accès : États de partage actifs/inactifs conservés dans Data 360 pour la gouvernance du cycle de vie.
• Synchronisation des métadonnées : Les mises à jour des définitions d'objet partagé sont automatiquement reflétées dans les catalogues d'entrepôts en aval.
• Garantie d'État immuable : Les vues d'entrepôt représentent toujours un état cohérent et temporel des données Data 360.

Scénarios d'intégration complexes

• Mode hybride : Combinez Zero Copy (pour la fédération live) avec l'ingestion (pour les jeux de données historiques).
• Accès inter-entrepôts : Data 360 peut fédérer à partir de plusieurs locataires Snowflake ou Databricks dans une seule organisation.
• Interopérabilité IA/BI : Les systèmes externes (p. ex. SageMaker, Tableau, Power BI) peuvent interroger les profils enrichis de Data 360 via la copie Zero inverse.
• Extension Fédération de fichiers : Les entreprises qui adoptent les formats lac ouvert (Iceberg/Delta) peuvent unifier les données structurées et non structurées dans un seul modèle fédéré.

Exemple

Les analyses inter-clouds permettent aux organisations de combiner des données Salesforce Data 360 régies avec des jeux de données natifs sur des plates-formes telles que Snowflake et Databricks pour offrir une vue analytique complète et complète. Grâce à l'accès multilocataire, différentes unités commerciales peuvent consommer en toute sécurité des tranches de données organisées et contrôlées par la politique via des partages séparés sans dupliquer les données. Les scientifiques des données peuvent ensuite effectuer un apprentissage IA et machine fédéré en entraînant des modèles directement sur des profils clients unifiés dans des environnements Snowflake ML ou Databricks MLflow. Tout au long de ce processus, les capacités intégrées de lignage, de gouvernance et d'audit garantissent que l'accès et l'utilisation des données restent conformes aux politiques d'entreprise et aux exigences réglementaires telles que le RGPD et HIPAA.

Data Cloud One permet aux organisations qui ont plusieurs organisations Salesforce (par exemple, en raison d'unités commerciales, de régions, de gammes de produits ou d'acquisitions) de partager une instance Data 360 unique et centrale. Cette organisation agit en tant qu'« organisation d'origine », alors que d'autres organisations, appelées « organisations d'accompagnement », peuvent accéder à ces données unifiées et agir en conséquence, sans effort minimal, sans code personnalisé et avec des contrôles de gouvernance complets.

Context

Les entreprises gèrent souvent plusieurs organisations Salesforce (par exemple, une pour les ventes, une pour le service, une autre pour le marketing ou des régions distinctes). Chaque organisation peut avoir ses propres données, configuration et processus. Avant Data Cloud One, chaque organisation nécessitait sa propre configuration Data 360 ou un code personnalisé complexe pour partager des données entre les organisations. Data Cloud One simplifie la tâche en autorisant une seule organisation « d'accueil » avec Data 360 et plusieurs organisations « d'accompagnement » qui se connectent via une configuration à faible code et le partage de métadonnées.

Problème

Comment une entreprise peut-elle permettre une utilisation cohérente des données Customer 360 unifiées (ingérées, harmonisées et gérées par Data 360 de l'organisation d'origine) dans toutes ses organisations Salesforce (afin que les ventes, le marketing, le service, etc., utilisent tous les mêmes données sous-jacentes), tout en évitant la duplication des efforts, le codage personnalisé, les instances Data 360 séparées par organisation et les écarts de gouvernance ?

Forces

Ce schéma introduit de multiples considérations architecturales, de sécurité et de performance :

• Complexité multi-organisations: L'organisation de chaque unité commerciale peut avoir des données, des objets personnalisés, une sécurité et des processus différents. Il est difficile de maintenir des vues unifiées cohérentes.
• Duplication et coût: L'exécution d'une instance Data 360 séparée par organisation entraîne une configuration supplémentaire, une gouvernance supplémentaire, des licences supplémentaires et le risque de silos de données.
• Gouvernance et contrôles de partage de données: Vous devez déterminer les données que chaque organisation partenaire peut afficher et utiliser. Vous ne pouvez pas simplement partager « tout » sans risque de gouvernance.
• Vitesse de configuration: Les équipes marketing, commerciales ou de service ne peuvent pas attendre des semaines avant qu'un code personnalisé rende les données inter-organisations disponibles, elles ont besoin de solutions de configuration par clic.
• Résidence des données, considérations régionales: Si les organisations d'origine et d'accompagnement résident dans des régions différentes, des contraintes légales ou réglementaires peuvent exister concernant l'emplacement de stockage ou le partage des données.

Solution

Le tableau ci-dessous présente diverses solutions à ce problème d'intégration.

Croquis

Le diagramme ci-dessous illustre la séquence des événements dans ce schéma, où Salesforce est le maître des données.

Dans ce scénario :

• Administrateur à domicile : créez un espace de données et définissez Partage de données (sélectionnez DMO/CIO, segments).
• Administrateur à domicile : créer Cible de partage de données pour les organisations compagnes et configurer Trust (client OAuth, ID d'organisation autorisés).
• Administrateur d'accueil : publiez Partage de données sur cible, joignez des stratégies ABAC (CEDAR) et des contrôles de cryptage/clé (CMK si nécessaire).
• Administrateur de l'organisation compagne : reçoit l'invitation, valide le mappage d'identité et accepte le partage.
• Organisation Compagnon: Data Cloud One Bridge provisionne un utilisateur Data Cloud One et applique la visibilité Ensembles d'autorisations et Espace de données.
• Applications d'organisation complémentaire (flux / Einstein / Apex): Interrogez un graphique de données ou appelez les API Data Cloud One pour lire des objets modèle de données ou des segments partagés.
• Activation: L'organisation compagne déclenche l'activation ou réécrit via des actions de données (si autorisé).

Résultats

• Une source unique de vérité pour les données clients (Client 360) dans toutes les organisations connectées — pas d'instances Data 360 redondantes.
• Les organisations compagnes peuvent accéder à des données unifiées et aux fonctionnalités pilotées par Data 360 en quelques minutes, pas en semaines de codage personnalisé.
• Partage de données contrôlé. Seuls les espaces de données autorisés sont partagés, ce qui préserve la sécurité et la gouvernance tout en permettant l'agilité métier.
• Les fonctions commerciales (ventes, service, marketing) fonctionnent sur la même fondation de données unifiée, ce qui permet des métriques, une activation et des connaissances cohérentes dans l'ensemble de l'entreprise.

Mécanismes d'appel

Le mécanisme d'appel dépend de la solution choisie pour implémenter ce schéma.

Gestion et récupération des erreurs

• Résilience de synchronisation inter-organisations : Data Cloud One essaie automatiquement les tâches de synchronisation échouées entre les organisations d'accueil et les organisations d'accompagnement en utilisant un backoff exponentiel pour les erreurs transitoires de réseau ou de plate-forme.
• Isolement partiel du lot : Les lots d'enregistrements échoués sont mis en quarantaine dans une File d'attente de nouvelle tentative au sein de l'organisation d'origine jusqu'à ce que le rapprochement réussisse, ce qui évite la divergence des données.
• Gouvernance du rejet du schéma : Les incohérences de schéma ou de mappage sont acheminées vers la file d'attente de refus du schéma pour examen et correction par l'administrateur.
• Continuité de lecture et de reprise : Chaque tâche de synchronisation conserve des points de contrôle décalés afin de permettre la reprise de la réplication depuis le dernier engagement réussi sans duplication.
• Surveillance intégrée : Tous les échecs, tentatives et métriques de reprise sont capturés dans le tableau de bord Trust Layer Monitoring pour la visibilité et l'assurance d'accord de niveau de service.

Considérations relatives à la conception impotente

• Clés d'idée-force déterministes : Chaque événement de synchronisation porte une clé unique (ID d'organisation + ID d'enregistrement + Numéro de version) pour garantir un traitement unique.
• Sécurité de lecture : Les événements dupliqués ou rejoués sont filtrés au moment de l'engagement, ce qui garantit des mises à jour cohérentes en aval des objets modèle de données et du DSI.
• Sémantique de validation atomique : Les organisations compagnes marquent les données comme engagées uniquement après des écritures en aval réussies, préservant ainsi l'intégrité transactionnelle inter-organisations.
• Résolution des conflits : Les mises à jour multisources suivent une logique de fusion en dernière écriture ou pilotée par une politique, en préservant la lignage et la cohérence.
• Persistance du point de contrôle : Les tâches de synchronisation conservent les décalages et l'état des derniers traitements dans la Trust Layer pour une récupération et une relecture sécurisées.

Considérations relatives à la sécurité

• Authentification forte : Les connexions entre les organisations d'accueil et les organisations d'accompagnement utilisent OAuth 2.0 mutuelles avec des jetons à rotation automatique gérés via des applications connectées.
• Autorisation granulaire : Les organisations compagnes peuvent accéder uniquement à des espaces de données, des objets modèle de données ou des DSI spécifiques explicitement partagés via des stratégies de partage de données régies.
• Cryptage partout : Les données sont cryptées en transit (TLS 1.2+) et au repos (AES-256) dans les organisations domestiques et les organisations complémentaires.
• Principe du moindre privilège : Les utilisateurs de l'intégration sont limités aux objets requis. Aucune autorisation administrative ou au niveau système n'est propagée.
• Visibilité d'audit et de conformité : Tous les événements de synchronisation, les modifications de schéma, les mises à jour d'identifiants et les autorisations d'accès sont consignés dans Data 360 Trust Layer pour une traçabilité totale.
• Isolation du réseau privé : En option, Salesforce Private Connect ou Private Link garantit la réplication des données uniquement sur des canaux internes sécurisés.

Menus latéraux

Opportunité

• La synchronisation entre les organisations d'accueil et les organisations d'accompagnement est effectuée en temps quasi réel, généralement quelques secondes après une modification des données dans l'organisation source.
• L'architecture Zero Copy garantit que les données partagées peuvent être instantanément interrogées dans toutes les organisations participantes, sans délai de réplication ni de lot.
• Les tâches d'activation et de segmentation reflètent automatiquement les toutes dernières mises à jour de n'importe quelle organisation connectée, préservant ainsi la fraîcheur opérationnelle.
• La latence de bout en bout est déterministe et régie par le pipeline d'orchestration de Data Cloud One, ce qui garantit une actualité inter-organisations cohérente, même en charge.

Volumes de données

• Conçu pour la synchronisation des données multi-locataires à grande échelle entre les régions et les unités commerciales, capable de gérer des milliards d'enregistrements par organisation.
• Les données sont référencées, pas dupliquées, ce qui réduit l'empreinte de stockage tout en préservant l'interrogation globale.
• Les deltas en continu et le compactage des métadonnées optimisent la bande passante et engagent les frais généraux pour les objets à taux de modification élevé (par exemple, Contact, Commande).
• Évolue horizontalement entre plusieurs organisations compagnes avec l'équilibrage de charge adaptatif et l'orchestration via la Trust Layer.

Gestion des états

• Chaque jeu de données synchronisé conserve le lignage des métadonnées, la version et le contexte de propriété de l'organisation pour garantir une traçabilité de bout en bout.
• La persistance des points de contrôle capture les décalages de dernière synchronisation entre les organisations, ce qui permet une récupération sans duplication.
• La gestion des versions de schéma et l'alignement sémantique entre les organisations sont automatiquement régis par les Trust Layers.
• Aucune réinitialisation manuelle de l'état n'est requise. L'état de synchronisation est conservé via le service d'orchestration Data Cloud One.

Scénarios d'intégration complexes

• Fédération inter-organisations : Active l'interrogation et l'activation transparentes entre plusieurs locataires ou régions Data 360 dans un modèle de gouvernance unifié.
• Synchronisation hybride : Combine la réplication en temps quasi réel pour les mises à jour transactionnelles et la synchronisation planifiée pour les données en masse ou archivistiques.
• Gouvernance multirégionale : Prend en charge le partage de données géographiquement distribué tout en respectant les frontières de résidence, de consentement et de conformité.
• Activation de l'IA et de l'automatisation : Les données synchronisées propulsent instantanément Einstein AI, Agentforce ou des modèles ML personnalisés entre les organisations, ce qui permet une intelligence inter-organisations en temps réel.

Exemple

Une organisation de vente au détail mondiale possède trois organisations Salesforce : une pour Consumer Retail, une pour Premium Brands et une autre pour International Markets. Ils provisionnent Data 360 dans l'organisation Consumer Retail (ce qui en fait l'organisation d'origine). Avec Data Cloud One, ils configurent des connexions compagnes avec les organisations Premium Brands et International Markets. Ils partagent uniquement les espaces de données appropriés (par exemple, « Customer 360 – Retail Profiles » et « Customer 360 – Premium Profiles ») avec chaque organisation partenaire. Dans l'organisation Premium Brands, les équipes marketing peuvent afficher des profils clients unifiés, élaborer des segments basés sur des connaissances calculées (par exemple, une valeur de durée de vie client supérieure) et déclencher des automatisations marketing, le tout piloté par l'instance Data 360 de l'organisation d'origine, sans code personnalisé ni duplication des données.

L'activation des données permet de donner vie à la valeur de Salesforce Data 360. Il s'agit du processus qui consiste à récupérer les données unifiées, enrichies et régies qui vivent sur la plate-forme et à les faire fonctionner dans l'ensemble de l'entreprise. En pratique, cela signifie fournir en toute sécurité des segments organisés, des connaissances calculées et des attributs contextuels depuis Data 360 vers les systèmes qui interagissent avec les clients, que ce soit l'automatisation marketing, les consoles de service, l'activation des ventes, les analytiques ou les modèles IA. D'un point de vue technique, les modèles d'activation définissent le déplacement de ces données : quels canaux sont déclenchés, quelles transformations ou quels mappages sont effectués, et comment les politiques sont appliquées en cours de route. Ces schémas ne se limitent pas à l'exportation de données, ils consistent à orchestrer des flux de données en temps réel et sensibles aux politiques qui génèrent des résultats métiers mesurables. Chaque itinéraire d'activation transforme le Customer 360 en actif opérationnel en direct. Il propulse la personnalisation, la prise de décision prédictive et l'apprentissage continu à chaque point de contact.

L'activation par lot reste la méthode la plus utilisée et la plus éprouvée sur le plan opérationnel pour exporter des données depuis Data 360. Il fonctionne selon une cadence planifiée, en publiant à intervalles réguliers des segments d'audience ou des ensembles d'attributs prédéfinis sur des plates-formes en aval. Ce modèle est idéal pour les workflows marketing et d'engagement qui s'appuient sur une diffusion d'audience cohérente et à haut volume plutôt que sur des mises à jour instantanées. Les cas d'utilisation typiques comprennent l'alimentation de parcours par e-mail, de campagnes de publipostage ou de chargements d'audience sur des réseaux publicitaires numériques. Chaque exécution d'activation extrait le segment qualifié du graphique de profil unifié de Data 360, applique des stratégies de gouvernance et de consentement, et transmet en toute sécurité la sortie au système cible. D'un point de vue architectural, l'activation par lot offre une approche prévisible, auditable et économique de la distribution des données, en équilibrant la simplicité opérationnelle et la fiabilité au niveau de l'entreprise. C'est l'épine dorsale de l'exécution de campagnes à grande échelle, où les données appropriées, livrées à temps et sous contrôle, génèrent un impact métier mesurable.

Context

Les marketeurs modernes opèrent sur plusieurs canaux d'engagement (e-mail, publicité, mobile et Web), chacun exigeant des audiences clients précises, opportunes et personnalisées. Data 360 sert de fondation unifiée pour ces audiences, en combinant les données clients de chaque système dans des segments riches et actionnables. L'activation par lot est le schéma d'activation le plus souvent utilisé pour exporter ces segments depuis Data 360 vers des plates-formes marketing ou publicitaires en aval. Les destinations typiques comprennent Marketing Cloud Engagement, Google Ads, Meta Custom Audiences ou LinkedIn Ads, où les campagnes peuvent être exécutées directement contre ces audiences organisées.

Problème

Comment une équipe marketing peut-elle prendre une audience précisément définie, élaborée à partir de données unifiées et enrichies dans Data 360, et la rendre disponible pour activation dans des systèmes marketing ou publicitaires externes ? Prenons par exemple le segment : « Les clients importants qui n'ont pas acheté au cours des 90 derniers jours, mais qui se sont récemment engagés sur le site Web. » Les marketeurs doivent s'assurer que cette audience est transférée avec précision, enrichie avec des attributs pertinents (par exemple, niveau de fidélité, région ou CLV prédit), et actualisée à intervalles réguliers pour maintenir la pertinence et l'efficacité des campagnes.

Forces

Plusieurs facteurs techniques et opérationnels déterminent le schéma d'activation par lot :

• Mappage d'identité : Une diffusion précise de l'audience nécessite de mapper l'ID d'individu unifié de Data 360 avec l'identificateur correspondant dans le système de destination, par exemple une Clé d'abonné dans Marketing Cloud ou un e-mail haché pour les plates-formes publicitaires numériques. Cela garantit une correspondance précise et élimine les erreurs de ciblage.
• Sélection et enrichissement d'attributs : Les marketeurs doivent aller au-delà des ID et inclure des données de profil supplémentaires (telles que le prénom, le statut de fidélité, le CLV ou d'autres attributs personnalisés) pour activer la personnalisation et les analytiques en aval.
• Configuration de la plate-forme cible : Chaque destination doit être enregistrée dans Data 360 en tant que cible d'activation, y compris les détails de connexion, l'authentification et les mappages de champs de données. Cette configuration unique définit la connectivité sécurisée et détermine quels systèmes peuvent recevoir des données activées.
• Gouvernance et conformité : L'activation des données doit respecter les métadonnées de consentement, les politiques de confidentialité (par exemple, RGPD ou CCPA) et les autorisations marketing stockées dans le profil unifié. L'activation consciente du consentement garantit que les données sont utilisées uniquement à des fins autorisées.
• Planification et performance : Les activations sont souvent planifiées tous les jours ou toutes les heures pour tenir les audiences en aval informées. Le système doit gérer efficacement les volumes importants et les actualisations incrémentielles sans duplication ni perte de données.

Solution

Le processus d'activation par lot dans Data 360 suit un workflow guidé qui réduit les frictions techniques pour les marketeurs tout en préservant la gouvernance et l'évolutivité :

Croquis

Voici le résumé des étapes :

• Élaborer un segment : Un marketeur ou un analyste crée un segment en utilisant un outil de segmentation visuelle, combinant des filtres à travers n'importe quel objet de données unifié.
• Créer une activation : Ils sélectionnent le segment comme source et choisissent une destination préconfigurée (telle que Marketing Cloud ou Google Ads).
• Définir la charge utile : L'identifiant du contact et d'autres attributs de profil sont choisis pour l'exportation d'audience et la génération de rapports.
• Livraison planifiée : L'activation est planifiée pour être exécutée une fois ou de façon récurrente, ce qui permet de tenir l'audience de la destination informée.
• Exécution : Au déclencheur, Data 360 interroge le segment, élabore la charge utile, applique des filtres pour le consentement et envoie automatiquement le résultat au système de destination.

Résultats

• Les segments d'audience ciblés et enrichis de Data 360 sont disponibles directement sur les plates-formes marketing et publicitaires en aval.
• Les audiences sont automatiquement actualisées et synchronisées avec les toutes dernières données clients unifiées, ce qui maintient la pertinence des campagnes en temps réel.
• Les marketeurs peuvent utiliser ces audiences activées comme sources d'entrée pour des parcours Marketing Cloud, des campagnes par e-mail ou des audiences personnalisées dans des plates-formes publicitaires numériques telles que Google Ads, Meta ou LinkedIn Ads.
• Chaque exécution d'activation maintient la lignée de bout en bout, garantissant la conformité, la traçabilité et la cohérence entre Data 360 et les systèmes externes.
• Les utilisateurs professionnels peuvent offrir des expériences hautement personnalisées pilotées par les données, pilotées par une vue Customer 360 complète et approuvée.

Mécanismes d'appel

Le mécanisme d'appel dépend de la plate-forme de destination et de la configuration de la cible d'activation.

Gestion et récupération des erreurs

• Isolation des défauts au niveau du travail : Chaque exécution d'activation est exécutée en tant que tâche distincte et traçable dans la couche d'orchestration Data 360. Les exécutions échouées sont automatiquement mises en quarantaine sans impact sur les autres activations ou définitions de segment.
• Récupération par lot partielle : Si certains enregistrements échouent à l'exportation (p. ex., en raison de différences d'identifiants ou de limites en taux d'API), le système les essaie en utilisant des files d'attente delta incrémentielles avec une restauration exponentielle et parallèle.
• Erreurs de validation de schéma : Lorsque les attributs de charge utile sortants ne correspondent plus au schéma cible (par exemple, un attribut supprimé ou un champ renommé), la tâche achemine les enregistrements affectés vers la File d'attente de refus du schéma pour examen par l'administrateur.
• Relecture et reprise du support : Chaque tâche d'activation conserve un jeton de point de contrôle, qui capture le dernier lot réussi. Lors de la récupération, le traitement reprend à partir du point de contrôle, ce qui garantit l'absence de duplication ou de perte de données.
• Surveillance globale : Tous les événements d'activation, toutes les tentatives et toutes les métriques de livraison sont consignés dans Trust Layer Monitoring, ce qui active le suivi des accords de niveau de service, l'analyse des causes premières et les alertes automatisées via les API Event Monitoring.

Considérations relatives à la conception impotente

• Clés d'activation déterministes : Chaque exécution d'activation utilise une clé d'identabilité composée, combinant ID de segment, ID d'activation et ID de système cible, pour garantir une livraison unique.
• Replay Detection : Le service d'activation Data 360 inspecte les charges utiles entrantes par rapport aux hachages de tâches précédents afin de détecter et de supprimer les relectures.
• Atomic Export s'engage : Les charges utiles sont engagées dans le système cible uniquement après une confirmation d'écriture réussie, ce qui empêche les mises à jour partielles ou le double comptage.
• Résolution de l'identité cohérente : Comme les activations dépendent d'ID unifiés (p. ex. Individu unifié), les relectures ou tentatives ciblent toujours le même enregistrement doré, ce qui maintient la cohérence sémantique.
• Persistance de l'état d'activation : La couche d'orchestration conserve les métadonnées d'état d'activation (horodatages, codes de statut et jetons de séquence) pour un retraitement déterministe si nécessaire.

Considérations relatives à la sécurité

• Authentification forte : Chaque cible d'activation (par exemple Marketing Cloud, Ads ou CRM) utilise OAuth 2.0 avec une rotation de jeton et une étendue spécifique au locataire pour empêcher l'exportation non autorisée de données.
• Gouvernance au niveau de l'attribut : Seuls les attributs approuvés du Profil unifié sont éligibles pour l'activation, appliquée par les stratégies de partage de données et les modèles d'activation.
• Cryptage en transit et au repos : Toutes les charges utiles sont cryptées en utilisant TLS 1.2+ pendant le transfert et AES-256 au repos dans Data 360 et la plate-forme cible.
• Consentement et application des politiques : Les tâches d'activation respectent les Objets de consentement et les Stratégies de données stockées dans la Trust Layer de Data 360. Les enregistrements sans métadonnées de consentement valides sont automatiquement exclus de l'exportation.
• Audit et consignation de la conformité : Chaque exécution d'activation capture qui l'a initiée, quelles données ont été envoyées et vers quelle destination, ce qui permet d'accéder à des parcours d'audit réglementaire complets (RGPD, CCPA) dans le tableau de bord Trust Layer.
• Accès à moindre privilège : Les utilisateurs de l'intégration de chaque cible sont limités à des étendues spécifiques à l'activation, sans privilège administratif ni accès en écriture à des systèmes non associés.

Menus latéraux

Opportunité

• Conçu pour les exportations par lot planifiées ou en temps quasi réel (latence minutes à heures).
• Prend en charge les actualisations temporelles alignées sur les calendriers de campagne.
• Les tâches d'activation peuvent être séquencées avec des marqueurs de préparation des données pour garantir l'actualisation des données.
• Convient mieux aux scénarios d'activation non interactifs dans lesquels la précision des données l'emporte sur l'immédiateté.

Volumes de données

• Gère les jeux de données à grande échelle (millions d'enregistrements par exécution).
• Évolue horizontalement à travers le partitionnement des segments et les canaux d'exportation parallèles.
• Utilise le traitement par lots basé sur des segments pour éviter les expirations et optimiser le débit.
• Idéal pour les pipelines de données d'entreprise dans lesquels l'exhaustivité des données est essentielle.

Gestion des états

• Gère les objets d'état d'activation qui enregistrent les ID de tâche, les horodatages et les jetons de séquence.
• Utilise le checkpointing pour la redémarrabilité et la reprise après défaut.
• Les définitions de segment avec version garantissent la reproductibilité entre les cycles d'activation.
• Active la traçabilité des lignages entre le segment source, les attributs d'objet modèle de données et les charges utiles cibles.

Scénarios d'intégration complexes

• S'intègre de façon transparente à Salesforce CRM, Marketing Cloud et à des systèmes externes via des connecteurs prédéfinis.
• Prend en charge les activations multicibles, qui distribuent simultanément des données à différentes destinations (par exemple CRM + Ads).
• Peut déclencher des workflows composés, par exemple une exportation par lot suivie d'un appel d'API en aval ou d'un score IA.
• Gère gracieusement l'évolution du schéma via la couche de gouvernance du modèle de données.

Exemple

Une enseigne de distribution mondiale souhaite réengager les clients inactifs des 90 derniers jours. En utilisant Data 360, l'architecte de données définit un segment « Consommateurs dormants » enrichi avec l'historique des achats, le niveau de fidélité et les métadonnées de consentement. La tâche d'activation par lot est exécutée tous les soirs, ce segment est automatiquement envoyé à Marketing Cloud Engagement pour déclencher une campagne par e-mail personnalisée « Vous nous manquez » et à Ad Studio pour le reciblage. La tâche exploite la livraison idempotente, ce qui évite les doublons entre les tentatives, et tous les événements sont consignés dans la Trust Layer pour la conformité aux audits.

Context

Les entreprises ont souvent besoin d'un mécanisme régi pour exporter des données unifiées ou segmentées depuis Salesforce Data 360 vers un format de fichier standard (par exemple, CSV ou Parquet) pour l'archivage, la conformité ou l'intégration en aval. Ce modèle permet l'exportation de stockage Data 360 vers le cloud, ce qui permet aux données clients de confiance de circuler en toute sécurité dans des lacs de données d'entreprise ou des pipelines d'analyse hébergés sur Amazon S3, Azure Blob ou Google Cloud Storage (GCS). Les cas d'utilisation typiques comprennent :

• Archivage périodique des jeux de données clients consentis pour la rétention réglementaire.
• Exportation de segments organisés pour des charges de travail analytiques non-Salesforce (par exemple Tableau, Databricks ou Power BI).
• Activation de modèles d'apprentissage machine externes qui nécessitent des fichiers CSV ou Parquet structurés en entrée.

Problème

Comment une organisation peut-elle exporter un segment ou un jeu de données organisé depuis Data 360 vers un compartiment de stockage cloud (par exemple Amazon S3), de manière régie, sécurisée et automatisée, tout en maintenant les contrôles d'intégrité et de conformité du schéma ? Par exemple, une équipe de conformité peut avoir à : « Extrayez tous les clients actifs dans la région de l’UE avec un consentement valide et exportez les données toutes les semaines vers un emplacement S3 pour un audit externe et des rapports. » Cela nécessite un pipeline d'exportation répétitif et sensible aux stratégies qui garantit le format de fichier, les autorisations d'accès et le calendrier de livraison appropriés, sans intervention manuelle ni mouvement de données non régi.

Forces

Plusieurs facteurs opérationnels et architecturaux régissent ce modèle d'exportation :

• Authentification et autorisation: Les exportations doivent respecter le modèle IAM du fournisseur de cloud (par exemple, Rôles IAM AWS ou Principals de service Azure) pour s'assurer que seuls les systèmes autorisés peuvent écrire dans le compartiment cible.
• Alignement du schéma: Le schéma sortant doit correspondre à la structure et au format attendus du système cible (CSV, Parquet ou JSON).
• Confidentialité des données et consentement: Les jeux de données exportés doivent exclure tous les enregistrements qui ne contiennent pas de métadonnées de consentement valides.
• Planification et fraîcheur: De nombreuses exportations sont périodiques (quotidiennes, hebdomadaires ou mensuelles) et doivent correspondre aux cycles d'actualisation des données d'entreprise.
• Gouvernance & Monitoring: Chaque exportation doit pouvoir être auditée avec une visibilité complète de la lignée, ce qui garantit la conformité avec la rétention des données et les mandats réglementaires (p. ex. RGPD, CCPA).

Solution

Le modèle Activation de l'exportation de fichiers réutilise les mêmes connecteurs de stockage cloud sécurisés utilisés pour l'ingestion, mais configurés pour la sortie des données. Les administrateurs enregistrent d'abord la plate-forme de stockage cloud (par exemple Amazon S3, Azure Blob Storage ou GCS) en tant que cible d'activation dans Data 360. Les utilisateurs configurent et exécutent ensuite un workflow d'activation pour exporter le segment de leur choix vers le chemin de stockage de fichiers désigné.

Croquis

Voici le résumé des étapes.

• Sélectionner un segment : Un analyste ou un gestionnaire de données choisit le segment unifié à exporter.
• Créer une activation : Ils créent une nouvelle tâche Activation et sélectionnent la cible Cloud Storage enregistrée.
• Définir la charge utile : Spécifiez le schéma d'exportation, la liste d'attributs et le format de fichier (par exemple, CSV).
• Planifier l'exportation : Choisissez une planification unique ou récurrente.
• Exécuter la tâche : Data 360 génère et livre en toute sécurité le fichier au chemin du compartiment désigné.
• Surveiller et vérifier : Les résultats et les journaux sont examinés dans la Trust Layer pour la validation et la conformité.

Résultats

• Les segments d'audience ciblés et enrichis de Data 360 sont disponibles directement sur les plates-formes marketing et publicitaires en aval.
• Les audiences sont automatiquement actualisées et synchronisées avec les toutes dernières données clients unifiées, ce qui maintient la pertinence des campagnes en temps réel.
• Les marketeurs peuvent utiliser ces audiences activées comme sources d'entrée pour des parcours Marketing Cloud, des campagnes par e-mail ou des audiences personnalisées dans des plates-formes publicitaires numériques telles que Google Ads, Meta ou LinkedIn Ads.
• Chaque exécution d'activation maintient la lignée de bout en bout, garantissant la conformité, la traçabilité et la cohérence entre Data 360 et les systèmes externes.
• Les utilisateurs professionnels peuvent offrir des expériences hautement personnalisées pilotées par les données, pilotées par une vue Customer 360 complète et approuvée.

Mécanismes d'appel

Le mécanisme d'appel dépend de la plate-forme de stockage cloud cible et de la configuration d'activation.

Gestion et récupération des erreurs

• Isolement au niveau de l'emploi : Chaque exportation est exécutée en tant que tâche discrète. Les tâches échouées sont mises en quarantaine et rejugées indépendamment.
• Réessai de fichier partiel : Si certains lots ne sont pas chargés (p. ex., en raison d'interruptions du réseau), le système essaie de nouveau ces segments en utilisant un backoff exponentiel.
• Traitement des écarts de schéma : Toute dérive de schéma ou incohérence de champ achemine les enregistrements vers la File d'attente de rejet du schéma pour examen.
• Point de contrôle et reprise : Les tâches d'exportation conservent les métadonnées des points de contrôle, ce qui permet de reprendre sans duplication depuis la dernière écriture réussie.
• Surveillance intégrée : Les échecs et les tentatives sont consignés dans le tableau de bord Trust Layer pour la visibilité et la conformité SLA.

Considérations relatives à la conception impotente

• Clés d'exportation déterministes : Chaque tâche d'exportation inclut un ID unique composé de ID de segment + ID de cible + Horodatage.
• Sécurité de lecture : Les exécutions de tâches dupliquées sont détectées en utilisant des hachages de tâches et ignorées afin d'éviter les exportations redondantes.
• Garantie d'écriture atomique : Data 360 n'engage les fichiers dans le compartiment cible qu'une fois l'exécution complète et la validation de la somme de contrôle terminée.
• Versions cohérentes du schéma : Les définitions d'exportation sont contrôlées par version pour garantir la cohérence du schéma entre les exécutions.
• Persistance du point de contrôle : Les tâches d'exportation conservent l'état de récupération déterministe et de retraitement si nécessaire

Considérations relatives à la sécurité

• Authentification forte : Les connecteurs Cloud utilisent OAuth 2.0, des rôles IAM ou des principaux de service pour les écritures authentifiées.
• Cryptage partout : Les données sont cryptées en transit (TLS 1.2+) et au repos (AES-256).
• Exportation consciente du consentement : Seuls les enregistrements avec un consentement valide sont exportés, appliqués par les stratégies Trust Layer.
• Principe du moindre privilège : Les utilisateurs exportateurs et les comptes de service sont limités à leurs chemins de stockage désignés.
• Consignation d'audit complète : Chaque exportation enregistre des métadonnées, y compris l'initiateur, le schéma, la destination et l'horodatage des rapports de conformité.

Menus latéraux

Opportunité

• Conçu pour une activation immédiate pilotée par l'événement avec une latence inférieure à la seconde.
• Idéal pour les scénarios qui nécessitent une personnalisation instantanée, une recommandation ou une prise de décision.
• Fonctionne en mode streaming : les déclencheurs sont déclenchés dès que des modifications de données qualifiantes se produisent dans Data 360.
• Garantit une réactivité continue sans attendre les planifications par lot ou le recalcul du segment.

Volumes de données

• Gère les jeux de données à grande échelle (millions d'enregistrements par exécution).
• Évolue horizontalement à travers le partitionnement des segments et les canaux d'exportation parallèles.
• Utilise le traitement par lots basé sur des segments pour éviter les expirations et optimiser le débit.
• Idéal pour les pipelines de données d'entreprise dans lesquels l'exhaustivité des données est essentielle.

Gestion des états

• Chaque action d'événement conserve son propre jeton d'événement et ID de relecture pour le traitement idempotent.
• Prend en charge la persistance du point de contrôle pour reprendre à partir du dernier événement engagé en cas d'échec transitoire.
• Inclut une logique de déduplication intégrée et des fenêtres de lecture pour garantir une sémantique d'activation exacte une fois.
• Les résultats des actions (réussite/échec) sont consignés en temps réel et exposés via le tableau de bord d'observabilité Trust Layer.

Scénarios d'intégration complexes

• Intègre directement aux flux Salesforce, aux événements de plate-forme Einstein 1 ou aux webhooks externes pour des chaînes de réponse instantanées.
• Peut déclencher des automatisations en aval, par exemple des mises à jour instantanées d'enregistrement CRM, un score IA ou des envois de messages Marketing Cloud.
• Prend en charge l'orchestration composable: les déclencheurs d'événements peuvent appeler des Actions Data 360, des invocations Apex, ou des API externes.
• Conçu pour les modèles d'entreprise agentsiques et adaptatifs dans lesquels des réponses sensibles au contexte doivent se produire instantanément.

Exemple

Une entreprise de vente au détail mondiale doit livrer une exportation hebdomadaire de son segment « Membres de fidélité actifs » pour l'analyse dans Databricks. L'administrateur Data 360 configure Amazon S3 en tant que cible d'activation et planifie une exportation CSV hebdomadaire vers le chemin d's3://enterprise-analytics/loyalty/weekly_exports/. La tâche d'exportation est exécutée tous les dimanches, générant un fichier filtré par consentement avec plus de 2M enregistrements. Tous les événements, définitions de schéma et lignage sont enregistrés dans le tableau de bord Trust Layer, ce qui garantit la transparence, l'auditabilité et la conformité.

L'activation basée sur l'API à la demande est une approche en temps réel pilotée par les événements qui permet de rendre les connaissances Data 360 actionnables dès qu'elles sont utiles, sans attendre les tâches par lot ou les exportations planifiées. Au lieu de publier des segments prédéfinis sur une cadence fixe, ce modèle permet aux systèmes externes, aux applications Salesforce ou aux agents IA d'appeler directement les API Data 360 pour récupérer ou activer des segments d'audience, des attributs clients ou des connaissances spécifiques à la demande. Ce modèle est conçu pour des expériences interactives basées sur un déclencheur, par exemple lorsqu'un utilisateur se connecte à un portail, qu'un agent ouvre un enregistrement client ou qu'un Copilot IA initie une requête Next Best Action. Au lieu de dépendre d'exportations précalculées, le système interroge ou active dynamiquement les données régies les plus récentes de Data 360 inReal-Time. L'avantage clé est l'immédiateté et la précision:

• Chaque appel d'API accède à l'Intelligence client la plus récente dans le graphique de profil unifié et sensible au consentement de Data 360.
• Les activations sont idempotentes et auditables, conformes aux exigences de Trust et de conformité de l'entreprise.
• Les intégrations peuvent être déclenchées directement depuis des flux Salesforce, Apex ou des systèmes externes via des API de plate-forme Einstein 1, des API Connect ou des API d'activation. Cette approche prend en charge les cas d'utilisation où la latence et la personnalisation sont les plus importantes, par exemple :
• Déclenchement d'une offre produit personnalisée pendant un appel de service.
• Générer des audiences de campagne dynamiques basées sur des événements comportementaux live.
• Alimentation des décisions en temps réel dans des modèles IA ou ML qui fonctionnent au moment de l'engagement.

Context

Les entreprises doivent souvent exposer des connaissances Data 360 harmonisées et en temps réel dans des applications personnalisées, telles que des portails Web internes, des applications mobiles ou des expériences Web avec des partenaires. Ce schéma permet aux développeurs d'élaborer des solutions sécurisées, centrées sur l'interface utilisateur, qui consomment et affichent des données clients unifiées avec Salesforce CRM et d'autres systèmes contextuels, le tout via un accès gouverné et basé sur l'API. Les cas d'utilisation typiques comprennent :

• Incorporation de connaissances Data 360 à des tableaux de bord internes des employés ou à des applications mobiles.
• Création de portails partenaires ou concessionnaires avec la visibilité des clients et des transactions.
• Intégration de données Data 360 dans des applications Web tierces ou des couches d'expérience.
• Affichage de recommandations personnalisées en temps réel pilotées par Data 360 et Einstein 1.

Problème

Comment un développeur peut-il élaborer une application personnalisée et orientée interface utilisateur qui accède et affiche en toute sécurité des données Data 360 harmonisées, souvent avec d'autres sources de données Salesforce, sans dupliquer ni exporter des informations confidentielles ? Par exemple, une entreprise peut avoir besoin d'élaborer un portail client qui affiche des profils clients unifiés, des interactions et des connaissances calculées à partir de Data 360. Cela nécessite une couche d'API unique, sécurisée et performante qui peut piloter l'expérience frontale, gérer l'authentification et garantir la gouvernance, tout en éliminant la complexité du modèle de données interne de Data 360.

Forces

De multiples considérations architecturales et opérationnelles influencent ce schéma :

• Accès UI-Centric : L'objectif principal est d'exposer des données dans des expériences frontales personnalisées (web ou mobile), pas d'effectuer des extractions par lot ou des synchronisations back-end.
• Passerelle sécurisée : L'API choisie doit servir de point d'entrée sécurisé et évolutif pour les applications et les utilisateurs authentifiés, en appliquant des contrôles d'accès de niveau entreprise.
• Contexte des données unifiées : Les applications doivent pouvoir combiner de façon transparente des données Data 360 (par exemple, des profils unifiés, des connaissances calculées) avec des données CRM, ERP ou d'objet personnalisé.
• Developer Simplicity : Les API doivent renvoyer des charges de travail prêtes pour la présentation qui réduisent le traitement back-end ou le mappage de schéma dans la couche client.
• Gouvernance et observation : Tous les accès doivent transiter par des canaux de confiance et auditables, avec un lignage clair, l'authentification et l'application des politiques.

Solution

La solution consiste à utiliser l'API REST Salesforce Connect comme passerelle d'intégration principale pour élaborer des applications personnalisées pilotées par les données au-dessus de Data 360. L'API Connect fournit un accès RESTful aux données Salesforce, y compris les profils harmonisés, les segments et les connaissances calculées de Data 360, sous des formats de réponse optimisés pour la consommation d'interface utilisateur (basés sur JSON, légers et adaptés aux appareils mobiles). Les développeurs s'authentifient via une application connectée, obtiennent des jetons OAuth 2.0 et appellent des ressources de l'API Connect telles que /query, /Chatter ou /data pour exposer des données unifiées directement dans leurs interfaces d'application. En arrière-plan, l'API Connect sert de fondation de transport pour d'autres API — telles que l'API Query, l'API Data Graph et les API Einstein 1 Platform — permettant aux développeurs de combiner plusieurs sources de données sous un même schéma d'accès unifié.

Croquis

Voici le résumé des étapes.

• Enregistrer l'application connectée : définissez les étendues OAuth et les autorisations d'API pour l'authentification de l'application externe.
• Obtenir le jeton d'accès : l'application externe effectue l'authentification OAuth 2.0 pour recevoir un jeton d'accès Data 360.
• Invoquer l'API Connect : l'application passe des appels d'API REST pour récupérer des données de profil, de segment ou de connaissances unifiées.
• Restitution des données dans l'interface utilisateur : les réponses sont analysées et présentées aux utilisateurs dans un portail de marque ou une interface mobile.
• Traitement des erreurs et des jetons d'actualisation : les applications implémentent une logique de nouvelle tentative et une actualisation automatique des jetons pour la continuité de la session.
• Accès Surveillance et Audit - Tous les appels d'API sont consignés dans la Trust Layer pour plus de visibilité et de conformité.

Résultats

Les développeurs peuvent créer des applications sécurisées et personnalisées étroitement intégrées à Data 360. Ces applications peuvent :

• Exposer des profils et des connaissances clients harmonisés en temps réel.
• Affichez les données Data 360 avec des objets CRM ou personnalisés via des API unifiées.
• Tirez parti de contrôles d'authentification, d'autorisation et d'audit cohérents via la Trust Layer.
• Offrez aux utilisateurs professionnels ou aux partenaires un accès transparent et régi à Intelligence client fiable à travers les expériences.

Mécanismes d'appel

Le mécanisme d'appel dépend de la plate-forme de stockage cloud cible et de la configuration d'activation.

Gestion et récupération des erreurs

• Demande de limitation : Retire et essaie automatiquement les appels d'API sous les limites de taux.
• Protection contre les dérives de schéma : utilise la découverte de métadonnées de schéma GraphQL ou REST pour s'adapter aux modifications du schéma.
• Gestion de l'expiration des jetons : les applications actualisent automatiquement les jetons OAuth pour éviter les interruptions de session.
• Isolation des défauts d'API : les appels d'API échoués sont consignés et réessayés sans impact sur les sessions simultanées.
• Confiance Layer Observability − Les taux de réussite/échec d ' API et les journaux d ' accès sont visibles dans le tableau de bord Trust Layer.

Considérations relatives à la conception impotente

• ID de requête déterministes: Chaque requête d'API inclut un ID de corrélation pour un traitement sans risque de relecture.
• En-têtes de validation du cache : Les en-têtes ETag et Last-Modified empêchent les récupérations de données redondantes.
• Opérations de lecture atomique : L'API Connect garantit que chaque réponse reflète un cliché instantané cohérent des données unifiées.
• Protection contre la lecture : les appels d'API dupliqués sont filtrés en utilisant des signatures de requête et des horodatages.

Considérations de sécurité

• Authentification OAuth 2.0 : Tous les appels d'API utilisent des jetons d'accès OAuth sécurisés et de courte durée via des applications connectées.
• Accès à moindre privilège : Les étendues d'API sont limitées aux objets et aux champs nécessaires.
• Cryptage partout : TLS 1.2+ en transit ; cryptage AES-256 au repos pour les réponses mises en cache ou stockées.
• Accès aux données conscient du consentement: Data 360 garantit que tous les enregistrements récupérés respectent les politiques de consentement et de gouvernance.
• Consignation d'audit complète : Chaque interaction d'API est enregistrée avec les métadonnées utilisateur, application et horodatage dans la Trust Layer.

Menus latéraux

Opportunité

• Conçu pour l'accès API en temps réel et à faible latence.
• Idéal pour les applications interactives qui nécessitent une restitution immédiate des données.
• Prend en charge les temps de réponse aux requêtes quasi instantanés via des sources Data 360 mises en cache et indexées.
• Aucune dépendance aux planifications par lot ou aux cycles d'activation asynchrones.

Volumes de données

• Optimisé pour les cas d'utilisation interactifs récupérant des jeux de données de petite à moyenne taille (par exemple, profils, connaissances ou transactions récentes).
• Gère les résultats paginés avec grâce à la pagination basée sur le curseur.
• Non destiné aux exportations en masse à haut volume, utilisez des modèles d'exportation par lot ou de fichier pour des jeux de données volumineux.

Gestion des états

• Les applications conservent un état de session léger avec des jetons OAuth et un cache local.
• L'API Connect prend en charge les requêtes conditionnelles et l'actualisation partielle pour plus d'efficacité.
• Les réponses d'API incluent des marqueurs de version pour la cohérence du schéma entre les versions.

Scénarios d'intégration complexes

• Combinez l'API Connect à l'API Data Graph pour des requêtes sémantiques dans plusieurs domaines.
• Intégrez à Einstein 1 Copilot ou aux API IA pour des expériences prédictives et conversationnelles.
• Utilisez-les aux côtés des composants Experience Cloud ou Web Lightning pour le développement d'interfaces utilisateur hybrides.
• Étendez-vous via MuleSoft pour orchestrer l'enrichissement des données ou des références système externes en temps réel.

Exemple

Une multinationale d'assurances crée un portail en libre-service pour les clients, qui permet aux assurés d'afficher leur profil unifié, les déclarations récentes et les offres personnalisées. L'application frontale basée sur eact s'authentifie via OAuth 2.0 et récupère les données en utilisant l'API REST Connect et l'API Data Graph. Toutes les données sont affichées en temps réel, sensibles au consentement et régies par la couche Trust Data 360. Les développeurs surveillent les appels d'API et les pistes d'audit directement dans Salesforce, ce qui garantit une conformité et une observabilité totales.

Context

Les entreprises ont de plus en plus besoin d'accéder instantanément à un profil client complet pour les systèmes de décision en temps réel, tels que les consoles de service, les moteurs de recommandation ou les plates-formes de personnalisation.Ce modèle permet aux applications de récupérer des vues précalculées et unifiées des données d'un client en temps quasi réel en utilisant l'API Data Graph de Data 360, qui fournit des temps de réponse inférieurs à la seconde pour des expériences interactives. Les cas d'utilisation typiques comprennent :

• Affichage d'une vue client complète au sein d'un Customer Service ou Sales Console.
• Alimentation des recommandations « Next Best Action » ou « Next Best Offer » basées sur l’IA.
• Offrir des expériences Web ou mobiles hyper personnalisées au chargement de la page.
• Prise en charge de la prise de décision en session dans des environnements d'agent ou en libre-service.

Problème

Comment une application peut-elle récupérer instantanément une vue client complète, précalculée et unifiée, au lieu d'exécuter des requêtes lentes et multi-objets à l'exécution ? Par exemple, un moteur de personnalisation Web doit charger le contexte client complet (données démographiques, préférences, transactions et connaissances calculées) en quelques millisecondes pour sélectionner une offre personnalisée. Les requêtes relationnelles traditionnelles peuvent nécessiter plusieurs jointures et entraîner une latence inacceptable. Cela nécessite une API qui fournit des données de profil dénormalisées et prêtes à l'emploi, récupérables via une référence clé unique, combinant rapidité, exhaustivité et gouvernance.

Forces

Plusieurs facteurs opérationnels et de performance influencent ce modèle :

• Vitesse : Le temps de réponse doit être en temps quasi réel. L'API doit renvoyer un profil complet en quelques millisecondes pour prendre en charge les interactions synchrones.
• Exhaustivité : La réponse doit inclure tous les attributs pertinents, les relations et les connaissances calculées, idéalement dans une seule charge utile.
• Efficacité de référence : Les profils doivent pouvoir être récupérés via des identifiants tels que customerId, contactKey ou email, ce qui élimine les requêtes à plusieurs étapes.
• Actualisation des données vs. Latence : Certains cas d'utilisation préfèrent les données précalculées (mises en cache) pour plus de rapidité ; d'autres nécessitent des données live, acceptant une latence plus élevée.
• Gouvernance et sécurité : L'accès doit rester régi par des stratégies Salesforce Trust Layer, garantissant le respect des règles de visibilité et de consentement des données.

Solution

La solution consiste à utiliser l'API Salesforce Data Graph pour récupérer des vues clients précalculées et dénormalisées stockées en tant qu'enregistrements Data Graph. Un Data Graph est une vue sémantique matérialisée qui combine plusieurs objets modèle de données (DMO) (tels que Individu, Transaction et ProductInterest) dans un enregistrement en lecture seule unique, souvent représenté sous forme de blob JSON. Les développeurs peuvent utiliser des points de terminaison REST tels que : GET /api/v1/dataGraph/{dataGraphEntityName}/{id} pour récupérer un enregistrement complet par son identifiant unique. Pour des scénarios dynamiques, l'API prend en charge un paramètre live=true qui contourne le cache matérialisé, en exécutant une requête en temps réel à travers Data 360, en échangeant une latence minimale contre les données les plus récentes. Cela permet aux développeurs de sélectionner entre les récupérations de profil instantanées (mises en cache) et à jour (en direct) selon les besoins de l'entreprise.

Croquis

Voici un résumé du flux d'implémentation :

• Define Data Graph : les architectes de données créent un Data Graph qui modélise une vue client unifiée à travers plusieurs objets modèle de données.
• Enregistrer l'application connectée : les développeurs configurent les identifiants OAuth pour un accès API sécurisé.
• Invoquer l'API Data Graph : l'application émet une requête GET avec le nom et l'ID d'enregistrement Data Graph.
• Réponse du processus : l'API renvoie une représentation JSON complète du profil client.
• Rendu ou Act : l'application consommatrice (interface utilisateur ou moteur) utilise les données unifiées pour la personnalisation, les recommandations ou les actions de service.
• Surveiller et ajuster - Les métriques de performance et les journaux d'accès sont examinés dans la console d'observabilité Trust Layer.

Résultats

Les applications peuvent désormais récupérer instantanément un profil client complet et pré-joint, ce qui permet des interactions en temps réel telles que la personnalisation, le service et l'automatisation des décisions. Ce schéma garantit :

• Temps de réponse inférieur à la seconde pour la prise de décision instantanée.
• Récupération de données cohérente et régie alignée sur le modèle sémantique Data 360.
• Logique d'application simplifiée : aucune jointure, aucun rapprochement de schéma.
• Accès traçable et conforme via la Trust Layer pour l'audit et l'observabilité.

Mécanismes d'appel

Le mécanisme d'appel dépend de la plate-forme de stockage cloud cible et de la configuration d'activation.

Gestion et récupération des erreurs

• Retour gratuit : si les requêtes live échouent ou dépassent les seuils d'expiration, restaurez automatiquement les récupérations Data Graph en cache.
• Gestion du délai d'expiration : implémentez une nouvelle logique et un disjoncteur pour les appels d'API soumis à une charge élevée.
• Traitement des ID non valides – renvoient les réponses standard 404 Not Found pour les clés de profil inexistantes. Gérez-les avec élégance dans l'interface utilisateur.
• Validation de version du schéma : validez les métadonnées de version du graphique de données afin d'éviter les incohérences lorsque le schéma évolue.
• Intégration de l’observabilité : consignez toutes les erreurs, tentatives et latences dans les tableaux de bord Trust Layer pour la surveillance des accords de niveau de service.

Considérations relatives à la conception impotente

• Clés déterministes : chaque récupération de profil utilise un ID stable (p. ex. IndividualId) qui garantit des requêtes prévisibles et sans risque de relecture.
• Cohérence du cache : utilisez l'en-tête ETag ou Last-Modified pour les récupérations conditionnelles et la validation du cache.
• Récupération atomique : chaque réponse d'API représente un cliché instantané cohérent de l'enregistrement Data Graph matérialisé.
• Protection contre la lecture : assurez-vous que les applications clientes détectent les récupérations dupliquées via des ID de corrélation et des horodatages.

Considérations relatives à la sécurité

• Authentification forte – OAuth 2.0 via des applications connectées applique automatiquement l'accès sécurisé basé sur un jeton.
• Récupération consciente du consentement - Seuls les attributs consentis sont renvoyés; les filtres de consentement sont automatiquement appliqués par la Trust Layer.
• Gouvernance au niveau du champ : l'accès aux attributs est contrôlé via les métadonnées et les définitions de stratégie de Data 360.
• Cryptage en transit et au repos : toutes les réponses sont cryptées avec TLS 1.2+ et AES-256.
• Audit et traçabilité : chaque événement de récupération de profil est consigné avec des identifiants, des horodatages et le contexte de la stratégie.

Menus latéraux

Opportunité

• Conçu pour la récupération instantanée.
• Prend en charge les requêtes live pour des données à jour avec une latence légèrement plus élevée (sub-seconde).
• Optimisé pour la prise de décision synchrone et les applications interactives.
• Élimine la nécessité d'une activation préalable au lot ou d'un recalcul de segment.

Volumes de données

• Idéal pour les références à enregistrement unique ou les petits ensembles (dizaines à centaines) par requête.
• Non optimisé pour la récupération en masse à grande échelle. Utilisez des API Batch ou Query pour les lectures à haut volume.
• Utilise la mise en cache et la pré-matérialisation évolutives horizontales pour plus de rapidité.

Gestion des états

• Maintient un accès léger et sans apatride ; chaque requête est indépendante.
• Prend en charge la mise en cache des en-têtes pour une récupération sans risque de relecture.
• Les applications peuvent conserver un espace cache local ou un espace de stockage de session à court terme afin de réduire les références répétées.

Scénarios d'intégration complexes

• Intègre de façon transparente à Einstein 1, à l'API Connect et à MuleSoft pour des expériences de données composées.
• Peut piloter des systèmes agents (par ex. Copilot ou des moteurs de raisonnement IA) qui nécessitent une sensibilisation instantanée et contextuelle.
• Combiné à des actions de données pour des déclencheurs en temps réel lors de la récupération ou d'un changement d'état.
• Permet la personnalisation à grande échelle sans compromettre les performances ou la gouvernance.

Exemple

Une plate-forme d'e-commerce mondiale utilise l'API Data Graph de Data 360 pour récupérer en temps réel des profils clients unifiés pour son moteur de recommandation. Lorsqu'un utilisateur se connecte, l'application invoque le point de terminaison Data Graph pour récupérer le UnifiedCustomerProfile de ce client, en renvoyant des attributs démographiques, des signaux comportementaux et des connaissances calculées dans une charge de travail JSON unique. Le moteur de personnalisation consomme cette réponse en quelques millisecondes pour déterminer et afficher la « Next Best Offer » pendant la session active. Toutes les requêtes sont régies et consignées par la Couche Trust, ce qui garantit la visibilité, l ' application des politiques et le respect des règles dans l ' ensemble de l ' interaction.

Les actions de données en temps réel activent l'activation instantanée des données clients dès qu'elles changent dans Data 360. Au lieu d'attendre les exportations par lot planifiées, ces actions envoient automatiquement des mises à jour, des connaissances ou des déclencheurs directement à Salesforce ou à des systèmes externes en quelques millisecondes. Lorsque le statut, le consentement ou la métrique d'engagement d'un client est mis à jour dans Data 360, ce signal peut immédiatement alimenter des offres personnalisées, déclencher des automatisations Service Cloud ou mettre à jour les niveaux de fidélité, afin de garantir que chaque expérience client reflète la vérité la plus récente et unifiée. Ce modèle est idéal pour les cas d'utilisation sensibles à l'impact et à la latence, tels que les expériences Web personnalisées, les alertes de détection de fraude, les recommandations Next Best Action ou les mises à jour CRM en temps réel. Il réduit l'écart entre les connaissances des données et l'action commerciale, transformant les données unifiées en intelligence instantanée.

Context

Les expériences numériques modernes et les workflows opérationnels nécessitent des actions immédiates et contextuelles dès qu'un événement se produit, par exemple, mettre à jour un enregistrement client pendant un Checkout, ajuster l'inventaire lorsqu'un retour est scanné ou offrir une promotion personnalisée dès qu'un utilisateur abandonne un panier d'achat. Les actions de données en temps réel permettent aux systèmes d'invoquer, d'enrichir et d'agir sur des profils Data 360 unifiés et des connaissances calculées avec une latence inférieure à la seconde, ce qui permet la personnalisation interactive, l'automatisation opérationnelle et la prise de décision instantanée.

Problème

Comment des applications, des flux d'interaction d'interface utilisateur ou des middlewares peuvent-ils appeler Data 360 à l'exécution pour lire, calculer ou mettre à jour un profil unifié unique ou déclencher une action (par exemple envoyer une offre, mettre à jour CRM, démarrer un workflow) avec une faible latence, une forte cohérence et des contrôles de gouvernance, sans attendre les tâches par lot planifiées ou les pipelines lourds ?

Forces

Plusieurs forces techniques, opérationnelles et de gouvernance façonnent ce schéma :

• Exigence de faible latence : Les appels doivent être effectués en quelques secondes ou en quelques secondes pour préserver un bon niveau d'expérience utilisateur ou respecter les accords de niveau de service opérationnels.
• Résolution déterministe de l'identité : Les requêtes doivent être résolues avec le profil Individu unifié correct (enregistrement doré) de façon fiable et rapide.
• Autorisation précise : Les appels en temps réel doivent appliquer des stratégies au niveau de l'attribut et des contrôles de consentement à la demande.
• Minimalisme de la charge de travail : Les charges utiles en temps réel doivent être petites et ciblées (profil unique ou petit ensemble d'attributs) afin de réduire la latence et les coûts.
• Expérience du développeur : Les API doivent être adaptées aux développeurs (REST/gRPC/GraphQL), avec des schémas clairs et des contrats stables pour l'utilisation en production.
• Auditabilité et traçabilité : Chaque action en temps réel doit être consignée avec le lignage, l'identité de l'utilisateur et les décisions de politique de conformité.

Solution

La solution recommandée est d'utiliser l'interface Actions de données en temps réel (API + SDK) de Data 360 combinée à la mise en cache des bords et à un minimum de transformations de calcul si nécessaire. Les intégrations invoquent un point de terminaison d'actions de données pour lire ou écrire des attributs de profil, calculer des connaissances ou initier des orchestrations. Les contrôles de stratégie en temps réel (CEDAR) et le masquage dynamique sont appliqués au point d'application de la politique avant le renvoi de la charge utile ou l'exécution de l'action.

Croquis

Voici le résumé des étapes.

• Le client (interface utilisateur / middleware / point de vente) envoie des requêtes Action de données authentifiées avec des identifiants et un type d'action.
• La passerelle API valide les limites en jetons, en taux et en transferts vers le service d'action Data 360.
• Action Service résout l'identificateur → ID d'individu unifié (cache du chemin rapide ; repli vers la référence Graphique).
• L'application des politiques (PDP) évalue les politiques CEDAR en utilisant les attributs de PEP et le contexte de la demande.
• Si autorisé, Action Service lit tous les attributs/connaissances de profil requis et effectue des transformations légères.
• Action Service renvoie la réponse de façon synchrone (par exemple, jeton d'offre, attribut mis à jour) ou met en file d'attente l'orchestration asynchrone et renvoie l'accusé de réception.
• Tous les événements, décisions et charges utiles sont consignés dans Trust Layer et éventuellement transmis à SIEM.

Résultats

• Les applications reçoivent un accès immédiat, régi par la politique, aux lectures/écritures de profil unifié et aux déclencheurs d'action avec une latence de la seconde à la seconde.
• La personnalisation en temps réel, la prise de décision et les workflows opérationnels (p. ex. offres, assistance de l'agent, mises à jour d'inventaire) sont activés sans délai par lot.
• Toutes les actions peuvent être auditées, sont sensibles au consentement et appliquent automatiquement le masquage au niveau de l'attribut pour préserver la confidentialité et la conformité.

Mécanismes d'appel

Le mécanisme d'appel dépend de la plate-forme de destination et de la configuration de la cible d'activation.

Gestion et récupération des erreurs

• Erreurs synchrones : Renvoyez des codes d'erreur structurés avec des messages lisibles par l'utilisateur et des jetons d'idempotence.
• Nouvelle tentative transitoire : Les clients doivent réessayer les requêtes idempotentes avec un recul exponentiel sur les réponses 429/5xx.
• Traitement des refus de politique : Les refus renvoient des codes de motif clairs ; les données confidentielles ne sont jamais renvoyées en cas d'échec de la stratégie.
• Échecs d'orchestration asynchrone : Les tâches d'orchestration sont déplacées vers DLQ et rejouables. Une API de statut de tâche permet aux clients d'interroger ou de recevoir des rappels.
• Stratégies de repli : Si la résolution de l'identité échoue, renvoyez une erreur déterministe et éventuellement une mesure corrective suggérée (par exemple, exiger externalId).

Considérations relatives à la conception impotente

• Clé d'immunité : Les clients fournissent une clé d'idempotence (UUID + espace de noms client) pour les actions de mutation.
• Clés déterministes : Utilisez des clés composées (UnifiedIndividualId + ActionType + TimestampWindow) pour détecter les doublons.
• Récupérations sécurisées : Concevez des actions tolérant les effets secondaires ou effectuez des mises à jour/insertions au lieu d'insertions aveugles.
• Protection contre la lecture : Maintenez les clés d'idempotence traitées et TTL-les après la fenêtre métier pour éviter les relectures.
• Apatridie : Gardez les actions synchrones sans état d'apatridie si possible, et maintenez un état minimal pour les workflows asynchrones.

Considérations relatives à la sécurité

• Authentification : OAuth 2.0 (porteur JWT ou mTLS pour les comptes de service); jetons de courte durée et rotation de l'actualisation.
• Autorisation : Le point de décision de politique applique automatiquement le contrôle d'accès basé sur l'attribut (CEDAR) et les contrôles de consentement par requête.
• Transport & Storage Encryption : TLS 1.2+ en transit; AES-256 au repos pour tous les fragments mis en cache ou journaux d'audit.
• Moins de privilège : Clients d'API limités à des autorisations minimales ; rôles séparés pour la lecture et l'écriture et l'orchestration.
• Réduction des données : Renvoyez uniquement les attributs demandés et consentis ; appliquez le masquage dynamique pour PII/PHI.
• Contrôles réseau : Vous pouvez également exiger des appels à partir de réseaux privés (Private Connect, listes d'autorisations IP) pour des actions à haut risque.
• Audit et surveillance : Consignez les métadonnées des requêtes, les décisions stratégiques, l'identité du demandeur et les hachages de réponse dans Trust Layer et SIEM.

Menus latéraux

Opportunité

• Conçu pour les latences moyennes dans la plage inférieure à la seconde et inférieure à une seconde pour les actions synchrones.
• Les caches Edge (TTL court) et les connaissances précalculées réduisent les allers-retours.
• Les parcours asynchrones fournissent un accusé de réception quasi instantané avec un traitement en arrière-plan pour les tâches lourdes.

Volumes de données

• Optimisé pour les interactions à enregistrement unique ou par petits lots (1 à 100 enregistrements).
• Pas destiné aux exportations en masse : utilisez l'activation par lot pour les volumes importants.
• Le débit élevé utilise la réutilisation de la mise en commun/connexion et des files d'attente d'orchestration parallèles.

Gestion des états

• Modèle de requête apatride pour les appels synchrones ; état d'action minimal persistant pour les subventions/transactions.
• Invalidation du cache pilotée par les événements de modification : assurez-vous que les TTL et les signaux d'invalidation gardent le cache à jour.
• Les tâches d'orchestration conservent un état durable (jobId, statut, tentatives) stocké dans la Trust Layer.

Scénarios d'intégration complexes

• Assistance de l'agent : Référence de profil en temps réel + propension calculée renvoyée à la console de service en moins de seconde pour les agents.
• POS / Edge Devices: Kit de développement local + action de données occasionnelle pour valider des promotions ou le statut de fidélité.
• Flux hybrides : Synchronisez Action de données pour l'orchestration Décision + asynchrone afin de mettre à jour les systèmes en aval et de déclencher des campagnes.
• Intergiciel tiers : Les passerelles MuleSoft ou API peuvent servir de médiateur pour l'authentification, enrichir le contexte et appliquer des contrôles de stratégie supplémentaires.

Exemple

Une application mobile de vente au détail détermine si un coupon instantané personnalisé doit être affiché lorsqu’un consommateur touche Checkout en invoquant l’action de données d’**éligibilité à l’**offre dans le contexte de l’adresse e-mail et du panier d’achat du consommateur. La requête est validée par la passerelle d'API et transmise au service d'action de données, qui résout l'e-mail vers un ID d'individu unifié en utilisant un accès cache, vérifie le consentement marketing via le PDP, et évalue l'éligibilité en fonction de la valeur de durée de vie du client et de la récence d'achat récente. Si le consommateur est éligible, le service renvoie un jeton de coupon signé et consigne la décision. Lorsque l'émission d'un coupon nécessite une réservation d'inventaire, une orchestration asynchrone est déclenchée pour réserver l'inventaire et notifier les systèmes CRM. L'application affiche immédiatement le coupon, tandis que les mises à jour en aval sont terminées en arrière-plan et que la Trust Layer capture un journal d'audit complet pour la gouvernance et la conformité.

• Connecteurs et intégration
• Web & Mobile SDK
• Ingestion en temps réel inférieure à la seconde
• Bring Your Own Lake (Requête zéro copie)
• Bring Your Own Lake (fichier sans copie)
• Graphiques de données
• Activation : Engagement MC
• Activation : Personnalisation MC
• Activation : B2C Commerce
• Partage de données (copie nulle)
• Activation : Stockage de fichiers
• Actions de données
• Actions de données en temps réel sub-second
• Plate-forme d'activation externe