Généralement, lorsque vous implémentez Salesforce, vous devez l'intégrer à d'autres applications. Bien que chaque scénario d'intégration soit unique, il existe des exigences et des problèmes communs que les développeurs et les architectes doivent résoudre.

Ce document décrit les stratégies (sous forme de schémas) pour ces scénarios d'intégration courants. Chaque schéma décrit la conception et l'approche d'un scénario particulier plutôt que de détailler une implémentation spécifique. Dans ce document, vous trouverez :

• Un certain nombre de modèles qui répondent à des scénarios d'intégration « archétype » clés
• Une matrice de sélection pour déterminer le modèle le plus adapté à votre scénario
• Conseils et meilleures pratiques d'intégration

Objet et portée

Ce document s'adresse aux concepteurs et aux architectes qui doivent intégrer Salesforce Platform à d'autres applications de leur entreprise. 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 d'applications basées sur Salesforce, lisez Résumé du schéma et guide de sélection de schémas. Les architectes et les développeurs doivent tenir compte des détails et des meilleures pratiques ci-dessous pendant la phase de conception et d'implémentation d'un projet d'intégration Salesforce.

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. Bien que Salesforce autorise l'intégration de l'interface utilisateur (UI), les mashups, par exemple, sortent du cadre de ce document.

Modèle de modèle

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.

Context

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 comment l'application se comportera pour satisfaire aux exigences.

Problème

Le scénario ou le problème (exprimé en tant que question) que le schéma est conçu pour résoudre. En examinant les schémas, lisez cette section pour déterminer rapidement 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 de bout en bout 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.

Récapitulatif du schéma

Le tableau ci-dessous répertorie les modèles d'intégration contenus dans ce document.

Liste de modèles remote-process-invocation--request-and-reply

Schéma Approche

Les modèles d'intégration de ce document sont classés en trois catégories :

• Intégration de données : ces modèles répondent à la nécessité de synchroniser les données qui résident dans deux systèmes ou plus afin que les deux systèmes contiennent toujours des données pertinentes et en temps opportun. L'intégration de données est souvent le type d'intégration le plus simple à implémenter, mais nécessite des techniques de gestion de l'information appropriées pour rendre la solution durable et rentable. Ces techniques comprennent souvent des aspects de gestion des données principales (MDM), de gouvernance des données, de mastering, de déduplication, de conception de flux de données, etc.

• Intégration de processus : les modèles de cette catégorie répondent à la nécessité pour un processus métier d'exploiter deux applications ou plus pour réaliser sa tâche. Lorsque vous implémentez une solution pour ce type d'intégration, l'application déclenchante doit appeler d'autres applications à travers les limites du processus. Généralement, ces modèles incluent aussi bien l'orchestration (où une application est le « contrôleur » central) que la chorégraphie (où les applications sont à plusieurs participants et où il n'y a pas de « contrôleur » central). Ces intégrations nécessitent souvent des exigences complexes de conception, de test et de traitement des exceptions. De plus, ces applications composites sont généralement plus exigeantes pour les systèmes sous-jacents, car elles prennent souvent en charge des transactions de longue durée et la capacité de générer des rapports ou de gérer l'état du processus.

• Intégration virtuelle : les modèles de cette catégorie répondent à la nécessité pour un utilisateur d'afficher, de rechercher et de modifier des données stockées dans un système externe. Lorsque vous implémentez une solution pour ce type d'intégration, l'application déclenchante doit appeler d'autres applications et interagir en temps réel avec leurs données. Ce type d'intégration élimine le besoin de réplication des données entre les systèmes et signifie que les utilisateurs interagissent toujours avec les données les plus récentes.

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é.

Guide de sélection

Les tableaux matriciels de sélection répertorient les modèles et leurs aspects clés pour vous aider à déterminer le modèle le plus adapté à vos exigences d'intégration. Les modèles sont classés en utilisant ces dimensions.

Intégration de Salesforce à un autre système

Le tableau ci-dessous répertorie les modèles et leurs principaux aspects 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.

Intégration d'un autre système à Salesforce

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.

Termes et définitions du middleware

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

Context

Vous utilisez Salesforce pour suivre les pistes, gérer votre pipeline, créer des opportunités et capturer les détails des commandes qui convertissent les pistes en clients. Cependant, le système Salesforce ne contient ni ne traite les commandes. Une fois les détails de la commande capturés dans Salesforce, la commande est créée dans le système distant, qui gère la commande jusqu'à sa conclusion.

Lorsque vous implémentez ce schéma, Salesforce appelle le système distant pour créer la commande, puis attend la réussite. En cas de succès, le système distant répond de façon synchrone avec le statut et le numéro de la commande. Dans le cadre de la même transaction, Salesforce met à jour le numéro et le statut de la commande en interne. Le numéro de commande est utilisé comme clé étrangère pour les mises à jour ultérieures du système distant.

Problème

Lorsqu'un événement se produit dans Salesforce, comment initier un processus dans un système distant, transmettre les informations requises à ce processus, recevoir une réponse du système distant, puis utiliser ces données de réponse pour effectuer des mises à jour dans Salesforce ?

Forces

Tenez compte des forces ci-dessous lors de l'application de solutions basées sur ce schéma.

• L'appel au système distant nécessite-t-il que Salesforce attende une réponse avant de poursuivre le traitement ? L'appel au système distant est-il une requête-réponse synchrone ou une requête asynchrone ?
• Si l'appel au système distant est synchrone, Salesforce doit-il traiter la réponse dans le cadre de la même transaction que l'appel initial ?
• La taille du message est-elle petite ou grande ?
• L'intégration est-elle basée sur l'occurrence d'un événement spécifique, par exemple un clic sur un bouton dans l'interface utilisateur de Salesforce, ou sur des événements basés sur DML ?
• Le point de terminaison distant peut-il répondre à la requête avec une faible latence ? Combien d'utilisateurs sont susceptibles d'exécuter cette transaction pendant une période de pointe ?

Solution

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

Croquis

Ce diagramme illustre une invocation de processus distant synchrone utilisant des appels Apex.

Appel Salesforce à un système distant

Diagramme de téléchargement

Dans ce scénario :

• Une action est initiée dans la page Lightning (par exemple, un clic sur un bouton).
• Le navigateur (via un contrôleur côté client dans le cas d'un composant Lightning) effectue un POST HTTP qui effectue à son tour une action sur le contrôleur Apex correspondant.
• Le contrôleur invoque l'appel réel au service Web distant.
• La réponse du système distant est renvoyée au contrôleur Apex. Le contrôleur traite la réponse, met à jour les données dans Salesforce si nécessaire et restitue de nouveau la page.

Dans les cas où l'état suivant doit être suivi, le système distant renvoie un identifiant unique stocké dans l'enregistrement Salesforce.

Résultats

L'application des solutions associées à ce schéma permet d'invoquer des processus distants initiés par un événement dans lesquels Salesforce gère le traitement.

Mécanismes d'appel

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

Traitement et récupération des erreurs

Il est important d'inclure une stratégie de gestion des erreurs et de récupération dans la solution globale.

• Gestion des erreurs : lorsqu'une erreur se produit (des exceptions ou des codes d'erreur sont renvoyés à l'appelant), l'appelant gère le traitement des erreurs. Par exemple, un message d'erreur affiché sur la page de l'utilisateur ou consigné dans un tableau nécessitant une action supplémentaire.

• Récupération : les modifications ne sont pas engagées dans Salesforce tant que l'appelant n'a pas reçu une réponse positive. Par exemple, le statut de la commande n'est pas mis à jour dans la base de données tant qu'une réponse indiquant la réussite n'a pas été reçue. Si nécessaire, l'appelant peut réessayer l'opération.

Considérations relatives à la conception impotente

Les capacités inempotentes garantissent la sécurité des invocations répétées. Si l'idempotency n'est pas implémentée, les invocations répétées du même message peuvent avoir des résultats différents, ce qui peut entraîner des problèmes d'intégrité des données. Les problèmes potentiels comprennent la création d'enregistrements dupliqués ou le traitement en double des transactions.

Il est important de s'assurer que la procédure distante appelée est idempotente. Si l'appel est passé par l'interface utilisateur, nous devons nous occuper de l'idempotence au niveau de la couche d'intégration, en particulier si rien ne garantit que Salesforce appelle une seule fois.

La méthode la plus typique de construction d'un récepteur idempotent consiste à suivre les doublons en fonction des identifiants de message uniques envoyés par le consommateur. Le service Web Apex ou les appels REST doivent être personnalisés pour envoyer un ID de message unique.

De plus, les opérations qui créent des enregistrements dans le système distant doivent vérifier les doublons avant l'insertion. Vérifiez en transmettant un ID d'enregistrement unique de Salesforce. Si l'enregistrement existe dans le système distant, mettez-le à jour. Dans la plupart des systèmes, cette opération est appelée opération de mise à jour/insertion.

Considérations de sécurité

Tout appel à un système distant doit préserver la confidentialité, l'intégrité et la disponibilité de la demande. Les considérations de sécurité suivantes sont spécifiques à l'utilisation d'appels SOAP Apex et HTTP dans ce schéma.

• Le protocole SSL unidirectionnel est activé par défaut, mais le protocole SSL bidirectionnel est pris en charge avec des certificats auto-signés et signés par une autorité de certification afin de préserver l'authenticité du client et du serveur.

• Pour rationaliser votre code Apex et simplifier la configuration des appels externes authentifiés, spécifiez un identifiant nommé dans le point de terminaison d'appel externe.

• Envisagez d'utiliser OAUTH 2.0 comme mécanisme d'authentification pour l'intégration à des systèmes externes.

• Si nécessaire, pensez à utiliser des hachages unidirectionnels ou des signatures numériques en utilisant les méthodes de classe Apex Crypto pour garantir l'intégrité des requêtes.

• Le système distant doit être protégé en mettant en œuvre les mécanismes de pare-feu appropriés. Consultez Considérations relatives à la sécurité.

• Actuellement, Salesforce ne prend pas en charge WS-Security. Bien qu'il ne génère pas nativement ces en-têtes WS-Security complexes ni ne les applique automatiquement à partir d'un WSDL entrant, vous pouvez les construire et les implémenter manuellement en créant des classes Apex personnalisées pour gérer les en-têtes SOAP et les jetons de sécurité pour les requêtes entrantes.

Barres latérales

Aucun.

Délais

L'opportunité revêt une importance considérable dans ce schéma. Généralement :

• La requête est généralement invoquée depuis l'interface utilisateur. Par conséquent, le processus ne doit pas faire attendre l'utilisateur.
• Salesforce a un délai d'expiration configurable allant jusqu'à 120 secondes pour les appels depuis Apex.
• L'exécution du processus distant est effectuée en temps voulu pour respecter la limite d'expiration de Salesforce et les attentes des utilisateurs.
• Les appels externes sont soumis aux limites du gouverneur des transactions synchrones Apex. Par conséquent, veillez à limiter le risque d'instanciation de plus de 50 transactions exécutées pendant plus de cinq secondes chacune. Outre la performance du point de terminaison externe, les options pour limiter le risque d'expiration comprennent :
  • Définissez l'expiration de l'appel externe sur cinq secondes.
  • Utilisation d'une continuation dans Lightning Components pour gérer les transactions à long terme

Volumes de données

Ce schéma est utilisé principalement pour les activités en temps réel à faible volume, en raison des faibles valeurs d'expiration et de la taille maximale de la requête ou de la réponse pour la solution d'appel Apex. N'utilisez pas ce modèle dans les activités de traitement par lot dans lesquelles la charge de travail des données est incluse dans le message.

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 d'État

Lors de l'intégration de systèmes, les clés sont importantes pour le suivi d'état continu. Il y a deux options.

• Salesforce stocke la clé de substitution primaire ou unique du système distant pour l'enregistrement distant.
• Le système distant stocke l'ID d'enregistrement unique Salesforce ou une autre clé de substitution unique.

Le traitement des clés d'intégration fait l'objet de considérations spécifiques, selon le système qui contient l'enregistrement principal, comme indiqué dans le tableau ci-dessous.

Scénarios d'intégration complexes

Dans certains cas, la solution prescrite par ce schéma peut nécessiter l'implémentation de plusieurs scénarios d'intégration complexes. Il est préférable d'utiliser un middleware ou de demander à Salesforce d'appeler un service composé. Ces scénarios comprennent :

• Orchestration de processus métiers et de règles impliquant une logique de flux complexe
• Agrégation des appels et de leurs résultats entre les appels à plusieurs systèmes
• Transformation des messages entrants et sortants
• Maintien de l'intégrité transactionnelle entre les appels à plusieurs systèmes

Limites du gouverneur

Pour plus d'informations sur les limites Apex, voir Execution Governors and Limits in the Apex Developer Guide.

Capacités middleware

Le tableau ci-dessous met en évidence les propriétés souhaitables d'un système middleware qui participe à ce schéma.

Exemple

Une entreprise de services publics utilise Salesforce et a un système séparé qui contient les informations de facturation des clients. Dans le cadre du processus de commande, de nouveaux comptes de facturation doivent être créés dans le système de facturation et Salesforce doit refléter le numéro de compte Billing dans le processus d'activation de la commande. Ils ont un service Web existant qui permet de créer un compte de facturation et renvoie le numéro du compte de facturation en tant que réponse.

Cette exigence peut être satisfaite avec l'approche suivante.

1. Salesforce consomme le service de compte de facturation WSDL à partir d'une classe proxy Apex.
2. Exécutez la classe proxy Apex avec les informations clients transmises au service Web externe depuis un contrôleur Apex personnalisé ou un service externe.
3. Le contrôleur personnalisé analyse ensuite les valeurs renvoyées par l'appel externe Apex et stocke ces informations dans l'objet salesforce.

Cet exemple montre que :

• L'état du client est suivi avec un numéro de compte stocké dans l'objet Compte Salesforce.
• Traitement ultérieur du message de réponse par l'appelant

Context

Vous utilisez Salesforce pour suivre les pistes, gérer votre pipeline, créer des opportunités et capturer les détails des commandes qui convertissent les pistes en clients. Cependant, dans le cadre des processus de gestion des commandes, un compte de facturation doit être créé dans le système de facturation de la commande.

Lorsque vous implémentez ce schéma, Salesforce appelle le système distant pour créer le compte de facturation, mais n'attend pas la fin de l'appel. Le système distant peut éventuellement mettre à jour Salesforce avec le nouveau compte de facturation créé dans une transaction séparée.

Problème

Lorsqu'un événement se produit dans Salesforce, comment initier un processus dans un système distant et transmettre les informations requises à ce processus sans attendre une réponse du système distant ?

Forces

Tenez compte des forces ci-dessous lors de l'application de solutions basées sur ce schéma.

• L'appel au système distant nécessite-t-il que Salesforce attende une réponse avant de poursuivre le traitement ? L'appel au système distant est-il synchrone ou asynchrone ?
• Si l'appel au système distant est synchrone, la réponse doit-elle être traitée par Salesforce dans le cadre de la même transaction que l'appel ?
• La taille du message est-elle petite ?
• L'intégration est-elle basée sur l'occurrence d'un événement spécifique, par exemple un clic sur un bouton dans l'interface utilisateur de Salesforce, ou sur des événements basés sur DML ?
• La livraison garantie de messages depuis Salesforce vers le système distant est-elle une exigence ?
• Le système distant peut-il participer à une intégration Priorité au contrat dans laquelle Salesforce spécifie le contrat ? Dans certaines variantes de solution (par exemple, la messagerie sortante), Salesforce spécifie un contrat que le point de terminaison système distant implémente.
• Le point de terminaison ou le bus de service Enterprise (ESB) prend-il en charge les longues interrogations ?
• Les méthodes de configuration déclaratives sont-elles préférées au développement Apex personnalisé ? Dans ce cas, les solutions telles que les événements de plate-forme sont préférées aux appels externes Apex.

Solution

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

Croquis

Le diagramme ci-dessous illustre un appel depuis Salesforce vers un système distant dans lequel la création ou la mise à jour d'opérations dans un enregistrement déclenche l'appel.

Diagramme de téléchargement

Dans ce scénario :

1. Un système distant s'abonne à l'événement de plate-forme.
2. Une mise à jour ou une insertion est effectuée dans un ensemble d'enregistrements donné dans Salesforce.
3. Un flux Salesforce se déclenche lorsqu'un ensemble de conditions est rempli.
4. Ce flux crée un événement de plate-forme.
5. L'écouteur distant reçoit le message d'événement et le place dans une file d'attente locale.
6. L'application en file d'attente transmet le message à l'application distante pour traitement.

Dans le cas où le système distant doit effectuer des opérations contre Salesforce, vous pouvez implémenter une opération de rappel facultative.

Résultats

L'application des solutions associées à ce schéma permet de:

• Invocations de processus distants initiées par l'interface utilisateur dans lesquelles le résultat de la transaction peut être affiché pour l'utilisateur
• Invocations de processus distant initiées par un événement DML dans lesquelles le résultat de la transaction peut être traité par le processus appelant

Mécanismes d'appel

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

Traitement et récupération des erreurs

Une stratégie de traitement des erreurs et de reprise doit être envisagée dans le cadre de la solution globale. La meilleure méthode dépend de la solution que vous choisissez.

Considérations relatives à la conception impotente

Les événements de plate-forme sont publiés une seule fois dans le bus. Aucune nouvelle tentative n'est effectuée du côté de Salesforce. C'est à l'ESB de demander que les épreuves soient rejouées. Lors d'une relecture, l'ID de relecture de l'événement de plate-forme reste inchangé et l'ESB peut essayer les messages dupliqués en fonction de l'ID de relecture.

L'identité est importante pour la messagerie sortante, car elle est asynchrone et les tentatives sont initiées lorsqu'aucun accusé de réception positif n'est reçu. Par conséquent, le service distant doit pouvoir gérer les messages de Salesforce de façon idempotente.

La messagerie sortante envoie un ID unique par message et cet ID reste inchangé pour toute tentative. Le système distant peut suivre les messages dupliqués en fonction de cet ID unique. L'ID d'enregistrement unique de chaque enregistrement mis à jour est également envoyé et peut être utilisé pour empêcher la création d'enregistrements dupliqués.

Les considérations de conception idempotentes du schéma Invocation de processus distant - Demande et réponse s'appliquent également à ce schéma.

Considérations de sécurité

Tout appel à un système distant doit préserver la confidentialité, l'intégrité et la disponibilité de la demande. Différentes considérations de sécurité s'appliquent, selon la solution que vous choisissez.

Consultez Considérations relatives à la sécurité.

Barres latérales

Aucun.

Délais

L'actualité est moins un facteur dans le schéma d'incendie et d'oubli. Le contrôle est restitué au client immédiatement ou après confirmation positive d'une transmission réussie au système distant. Avec la messagerie sortante Salesforce, l'accusé de réception doit avoir lieu dans les 24 heures (ce délai peut être étendu à sept jours), sinon le message expire. Pour des événements de plate-forme, Salesforce envoie les événements au bus d'événement et n'attend pas une confirmation ou un accusé de réception de l'abonné. Si l'abonné ne sélectionne pas le message, il peut demander à rejouer l'événement en utilisant l'ID de réponse à l'événement. Les messages d'événement à haut volume sont stockés pendant 72 heures (trois jours). Pour récupérer les messages d'événements passés, utilisez des clients CometD pour vous abonner à un canal.

Volumes de données

Les considérations relatives au volume de données dépendent de la solution que vous choisissez. Pour connaître les limites de chaque solution, consultez la référence rapide Salesforce Limits.

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 d'État

Lors de l'intégration de systèmes, les identifiants d'enregistrement uniques sont importants pour le suivi d'état permanent. Par exemple, si un enregistrement est créé dans le système distant, vous avez deux options.

• Salesforce stocke la clé de substitution primaire ou unique du système distant pour l'enregistrement distant.
• Le système distant stocke l'ID d'enregistrement unique Salesforce ou une autre clé de substitution unique.

Le tableau ci-dessous répertorie les considérations relatives à la gestion de l'État dans ce schéma.

Scénarios d'intégration complexes

Chaque solution de ce schéma a des considérations différentes pour des scénarios d'intégration complexes tels que la transformation et l'orchestration de processus.

Limites du gouverneur

En raison de la nature multilocataire de la plate-forme Salesforce, les appels externes sortants sont limités. Les limites dépendent du type d'appel sortant et de l'heure de l'appel.

Pour connaître les limites et les allocations applicables aux événements de plate-forme, consultez le Platforms Events Developer Guide.

Messagerie fiable

La messagerie fiable tente de résoudre le problème de la garantie de la livraison d'un message à un système distant dans lequel les composants individuels ne sont pas fiables. La méthode de réception d'un message par le système distant dépend de la solution que vous choisissez.

Dans le cas de la Capture des données de modification Salesforce, des types d'événement de modification sont fournis pour gérer des situations spéciales, par exemple capturer les modifications qui ne sont pas détectées dans les serveurs d'application Salesforce ou gérer de fortes charges de modifications.

Dans certains cas, Salesforce envoie des événements Écart au lieu d'événements de modification pour informer les abonnés des erreurs ou s'il n'est pas possible de générer des événements de modification. Un événement gap contient des informations sur la modification dans l'en-tête, par exemple le type de modification et l'ID d'enregistrement. Il ne contient pas de détails sur la modification, notamment les champs d'enregistrement. Pour capturer plus efficacement les modifications, des événements de dépassement sont générés pour les transactions uniques qui dépassent un seuil. Pour plus d'informations, veuillez consulter ici.

Capacités middleware

Le tableau ci-dessous met en évidence les propriétés souhaitables d'un système middleware qui participe à ce schéma.

Variante de solution : événements de plate-forme : Comportement de publication et transactions

Lorsque les messages d'événement de plate-forme sont immédiatement publiés, la publication d'événements ne respecte pas les limites de transaction du processus de publication. Les messages d'événement peuvent être publiés avant la fin de la transaction ou même si une transaction échoue. Ce comportement peut entraîner des problèmes lorsqu'un abonné s'attend à trouver des données que la transaction de publication engage. Les données peuvent ne pas être présentes lorsque l'abonné reçoit le message d'événement. Pour résoudre ce problème, définissez le comportement de publication de l'événement de plate-forme sur Publier après l'engagement dans la définition de l'événement. Les comportements de publication que vous pouvez définir dans une définition d'événement de plate-forme sont les suivants :

• Publier après l'engagement pour publier le message d'événement uniquement lorsqu'une transaction est engagée avec succès. Sélectionnez cette option si les abonnés dépendent des données que la transaction de publication engage. Par exemple, un processus publie un message d'événement et crée un enregistrement de tâche. Un deuxième processus abonné à l'événement est déclenché et attend de retrouver l'enregistrement de la tâche. Une autre raison pour laquelle vous choisissez ce comportement est lorsque vous ne souhaitez pas publier le message d'événement en cas d'échec de la transaction.
• Publiez immédiatement pour publier le message d'événement lors de l'exécution de l'appel de publication. Sélectionnez cette option si vous souhaitez publier le message d'événement, que la transaction réussisse ou non. Choisissez également cette option si l'éditeur et les abonnés sont indépendants et que les abonnés ne dépendent pas des données engagées par l'éditeur. Par exemple, le comportement de publication immédiate convient à un événement utilisé à des fins de consignation. Avec cette option, un abonné peut recevoir le message d'événement avant l'engagement des données par la transaction de l'éditeur.

Exemple

Une entreprise de télécommunications souhaite utiliser Salesforce comme front-end pour créer des comptes en utilisant le processus piste-à-opportunité. Une commande est créée dans Salesforce lorsque l'opportunité est fermée et gagnée, mais le système ERP back-end est le principal des données. La commande doit être enregistrée dans l'enregistrement de l'opportunité Salesforce et le statut de l'opportunité doit changer pour indiquer que la commande a été créée.

Les contraintes suivantes s'appliquent.

• Seul le développement déclaratif peut être mis en œuvre.
• Il n'est pas nécessaire de notifier immédiatement le numéro de commande après la conversion de l'opportunité en commande.
• L'organisation a un ESB qui prend en charge le protocole CometD et peut s'abonner à des événements de plate-forme.

Cet exemple est préférable d'utiliser des événements de plate-forme Salesforce, mais nécessite que l'ESB s'abonne à l'événement de plate-forme.

Du côté de Salesforce :

• Créez un flux pour initier l'événement de plate-forme (par exemple, lorsque le statut de l'opportunité change en Close-Won).
• Créez un événement de plate-forme qui publie les détails de l'opportunité.

Côté système distant :

• L'ESB s'abonne à l'événement de plate-forme Salesforce en utilisant le protocole CometD.
• L'ESB reçoit une ou plusieurs notifications indiquant que l'opportunité doit être convertie en commande.
• L'ESB transmet le message au système ERP back-end pour que la commande puisse être créée.
• Une fois la commande créée dans le système ERP, un thread séparé rappelle Salesforce en utilisant SessionId comme jeton d'authentification. Le rappel met à jour l'opportunité avec le numéro de commande et le statut. Vous pouvez effectuer ce rappel en utilisant des solutions de schéma documentées, telles que des événements de plate-forme Salesforce, l'API SOAP Salesforce, l'API REST ou un service Web Apex.

Cet exemple montre ce qui suit.

• Implémentation d'un processus distant invoqué de façon asynchrone
• Livraison garantie de bout en bout
• Rappel ultérieur à Salesforce pour mettre à jour l'état de l'enregistrement

Context

Vous déplacez votre implémentation CRM vers Salesforce et souhaitez :

• Extrayez et transformez les comptes, les contacts et les opportunités du système CRM actuel, puis chargez les données dans Salesforce (importation initiale des données).
• Extrayez, transformez et chargez des données de facturation client dans Salesforce à partir d'un système distant sur une base hebdomadaire (en continu).
• Extrayez les informations sur l'activité des clients de Salesforce et importez-les dans un entrepôt de données sur site sur une base hebdomadaire (en continu).

Problème

Comment importer des données dans Salesforce et exporter des données hors de Salesforce, en tenant compte du fait que ces importations et exportations peuvent interférer avec les opérations des utilisateurs pendant les heures ouvrables et impliquer de grandes quantités de données ?

Forces

Il existe diverses forces à prendre en compte lors de l'application de solutions basées sur ce schéma :

• Les données doivent-elles être stockées dans Salesforce ? Sinon, il existe d'autres options d'intégration qu'un architecte peut et doit prendre en compte (les mashups, par exemple).
• Si les données doivent être stockées dans Salesforce, les données doivent-elles être actualisées en réponse à un événement dans le système distant ?
• Les données doivent-elles être actualisées à une fréquence planifiée ?
• Les données prennent-elles en charge les processus métiers principaux ?
• Existe-t-il des exigences en matière d'analyse (rapports) qui sont impactées par la disponibilité de ces données dans Salesforce ?

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 principal des données.

Diagramme de téléchargement

Le diagramme suivant illustre la synchronisation ultérieure des événements en temps quasi réel, où Salesforce est le maître des données.

Résultats

Vous pouvez intégrer des données provenant de sources externes à Salesforce dans les scénarios suivants :

• Le système externe est le principal des données : Salesforce est un consommateur de données fournies par un système source unique ou plusieurs systèmes. Dans ce scénario, il est courant d'avoir un entrepôt de données ou un datamart qui agrège les données avant leur importation dans Salesforce.
• Salesforce est le maître des données : Salesforce est le système d'enregistrement de certaines entités et les applications clientes Capture des données de modification Salesforce peuvent être informées des modifications apportées aux données Salesforce.

Dans un scénario d'intégration Salesforce typique, l'équipe d'implémentation effectue l'une des opérations suivantes :

• Implémentez la capture des données de modification dans le jeu de données source.
• Implémentez une série de structures de base de données de support, appelées tableaux de contrôle, dans une base de données intermédiaire sur site.

L'outil ETL est ensuite utilisé pour créer des programmes qui vont :

1. Lisez un tableau de contrôle pour déterminer l'heure de dernière exécution de la tâche et extraire les autres valeurs de contrôle requises.
2. Utilisez les valeurs de contrôle ci-dessus comme filtres et interrogez le jeu de données source.
3. Appliquez des règles de traitement prédéfinies, notamment la validation, l'enrichissement, etc.
4. Utilisez les connecteurs et les capacités de transformation disponibles de l'outil ETL pour créer le jeu de données de destination.
5. Écrivez le jeu de données dans des objets Salesforce.
6. Si le traitement réussit, mettez à jour les valeurs de contrôle dans le tableau de contrôle.
7. Si le traitement échoue, mettez à jour les tableaux de contrôle avec des valeurs qui activent un redémarrage et une sortie.

Note: Nous recommandons de créer les tableaux de contrôle et les structures de données associées dans un environnement auquel l'outil ETL a accès, même si l'accès à Salesforce n'est pas disponible. Cela fournit des niveaux adéquats de résilience. Salesforce doit être traité comme un rayon dans ce processus et l'infrastructure ETL est la plate-forme.

Pour qu'un outil ETL puisse bénéficier au maximum des capacités de synchronisation des données, tenez compte des points suivants :

• Enchaînez et séquencez les tâches ETL pour fournir un processus cohérent.
• Utilisez les clés primaires des deux systèmes pour mapper les données entrantes.
• Utilisez des méthodes d'API spécifiques pour extraire uniquement les données mises à jour.
• Si vous importez des enregistrements enfants dans une relation principal-détails ou de référence, regroupez les données importées en utilisant leur clé parente à la source pour éviter le verrouillage. Par exemple, si vous importez des données de contact, assurez-vous de regrouper les données de contact par clé de compte parent afin de charger le nombre maximal de contacts pour un seul compte dans un seul appel d'API. L'échec du regroupement des données importées entraîne généralement le chargement du premier enregistrement de contact et l'échec des enregistrements de contact suivants pour ce compte dans le contexte de l'appel d'API.
• Tout traitement postérieur à l'importation, par exemple les déclencheurs, ne doit traiter les données que de façon sélective.
• Si votre scénario implique des volumes de données importants, suivez les meilleures pratiques de ce module Trailhead Best Practices for Deployments with Large Data Volumes
.

Traitement et récupération des erreurs

Une stratégie de traitement des erreurs et de reprise doit être envisagée dans le cadre de la solution globale. La meilleure méthode dépend de la solution que vous choisissez.

Considérations de sécurité

Tout appel à un système distant doit préserver la confidentialité, l'intégrité et la disponibilité de la demande. Différentes considérations de sécurité s'appliquent, selon la solution que vous choisissez.

• Une licence Lightning Platform avec au moins les autorisations utilisateur « API uniquement » est requise pour autoriser l'accès API authentifié à l'API Salesforce.
• Nous recommandons d'utiliser le cryptage standard pour sécuriser l'accès par mot de passe.
• Utilisez le protocole HTTPS pour passer des appels aux API Salesforce. Vous pouvez également proxyer le trafic vers les API Salesforce via une solution de sécurité sur site, si nécessaire.

Consultez Considérations relatives à la sécurité.

Barres latérales

Aucun.

Délais

L'actualité n'a pas d'importance significative dans ce schéma. Cependant, il faut veiller à concevoir les interfaces de sorte que tous les processus par lot soient terminés dans une fenêtre de lot désignée.

Comme avec toutes les opérations par lot, nous recommandons vivement de prendre soin d'isoler les systèmes source et cible pendant les fenêtres de traitement par lot. Le chargement de lots pendant les heures ouvrables peut entraîner des conflits, entraînant l'échec de la mise à jour d'un utilisateur ou, plus important encore, l'échec d'un chargement par lot (ou d'un chargement partiel par lot).

Pour les organisations qui ont des opérations mondiales, il peut être impossible d'exécuter tous les processus par lot en même temps, car le système peut être continuellement utilisé. Des techniques de segmentation des données utilisant des types d'enregistrement et d'autres critères de filtrage peuvent être utilisées pour éviter les conflits de données dans ces cas.

Gestion d'État

Vous pouvez implémenter la gestion des états en utilisant des clés de substitution entre les deux systèmes. Si vous avez besoin d'un type de gestion des transactions entre les entités Salesforce, nous recommandons d'utiliser Apex comme modèle d'appel à distance.

Le verrouillage d'enregistrement optimiste standard se produit sur la plate-forme, et toutes les mises à jour effectuées en utilisant l'API nécessitent que l'utilisateur, qui modifie l'enregistrement, actualise l'enregistrement et initie sa transaction. Dans le contexte de l'API Salesforce, le verrouillage optimiste désigne un processus dans lequel :

• Salesforce ne conserve pas l'état d'un enregistrement modifié par un utilisateur spécifique.
• À la lecture, il enregistre l'heure à laquelle les données ont été extraites.
• Si l'utilisateur met à jour l'enregistrement et l'enregistre, Salesforce vérifie si un autre utilisateur a mis à jour l'enregistrement entre-temps.
• Si l'enregistrement a été mis à jour, le système notifie l'utilisateur qu'une mise à jour a été effectuée et l'utilisateur doit récupérer la dernière version de l'enregistrement avant de procéder à ses mises à jour.

Capacités middleware

Les technologies externes les plus efficaces utilisées pour implémenter ce schéma sont les outils ETL traditionnels. Il est important que les outils middleware choisis prennent en charge l'API de transfert en masse Salesforce.

Il est utile, mais pas essentiel, que les outils middleware prennent en charge la fonction getUpdated(). Cette fonction fournit l'implémentation la plus proche de la capacité standard de capture des données de modification sur Salesforce Platform.

Le tableau ci-dessous met en évidence les propriétés souhaitables d'un système middleware qui participe à ce schéma.

Exemple

Une entreprise de services publics utilise un processus par lot basé sur l'ordinateur central qui attribue des prospects à des commerciaux individuels et à des équipes. Ces informations doivent être importées dans Salesforce chaque nuit.

Le client a décidé d'implémenter la capture des données de modification dans les tableaux sources en utilisant un outil ETL disponible dans le commerce. La solution fonctionne comme suit :

• Un planificateur de type cron exécute une tâche par lot qui attribue des prospects aux utilisateurs et aux équipes.
• Après l'exécution de la tâche par lot et la mise à jour des données, l'outil ETL reconnaît ces modifications par capture des données modifiées. L'outil ETL regroupe les modifications du magasin de données.
• Le connecteur ETL utilise l'API REST Salesforce pour charger les modifications dans Salesforce.

Context

Vous utilisez Salesforce pour suivre les pistes, gérer votre pipeline, créer des opportunités et capturer les détails des commandes qui convertissent les pistes en clients. Le système Salesforce crée les commandes en interne, puis envoie automatiquement ces données au système de facturation externe pour provisionnement et activation. Les commandes de facturation sont gérées par un système externe (à distance). Ce système distant doit mettre à jour le statut de la commande dans Salesforce lorsque le statut de la commande ou de l'entité de facturation change.

Problème

Comment un système distant se connecte-t-il et s'authentifie-t-il à Salesforce pour notifier Salesforce d'événements externes, créer des enregistrements et mettre à jour des enregistrements existants ?

Forces

Il existe diverses forces à prendre en compte lors de l'application de solutions basées sur ce schéma :

• L'appel distant à Salesforce a-t-il pour but de notifier Salesforce d'un événement qui s'est produit en externe en utilisant une architecture pilotée par l'événement ? Ou bien l'objectif est d'effectuer des opérations CRUD sur des enregistrements spécifiques ? Si vous utilisez une architecture pilotée par l'événement, le producteur d'événement (le processus distant) est découplé du consommateur d'événement Salesforce.
• L'appel à Salesforce nécessite-t-il que le processus distant attende une réponse avant de poursuivre le traitement ? Les appels distants à Salesforce sont toujours des requêtes-réponses synchrones, bien que le processus distant puisse abandonner la réponse s'il n'est pas nécessaire de simuler un appel asynchrone.
• Chaque transaction fonctionne-t-elle avec un seul objet Salesforce ou plusieurs objets associés ?
• Quel est le format du message (par exemple, SOAP ou REST, ou les deux sur HTTP) ?
• La taille du message est-elle relativement petite ou grande ?
• Si le système distant est compatible SOAP, le système distant peut-il participer à une approche axée sur le contrat, dans laquelle Salesforce dicte le contrat ? Elle est requise lorsque notre API SOAP est utilisée, pour laquelle un WSDL prédéfini est fourni.
• Le traitement des transactions est-il requis ?
• Dans quelle mesure tolérez-vous la personnalisation dans Salesforce ?

Solution

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

Croquis

Les diagrammes ci-dessous illustrent la séquence des événements lorsque vous implémentez ce modèle en utilisant l'API REST pour les notifications d'événements externes ou l'API SOAP pour interroger un objet Salesforce. La séquence des événements est identique lors de l'utilisation de l'API REST.

Interrogation système distante de Salesforce via l'API SOAP

Système distant notifiant Salesforce avec des événements via l'API REST

Résultats

Dans une architecture pilotée par l'événement, le système distant appelle Salesforce en utilisant l'API SOAP, l'API REST ou l'API de transfert en masse 2.0 pour publier un événement dans le bus d'événement Salesforce. La publication d'un événement notifie tous les abonnés. Les abonnés aux événements peuvent être sur Salesforce Platform tels que des flux, ou des composants Lightning, des déclencheurs Apex. Les abonnés aux événements peuvent également être externes à Salesforce Platform, par exemple des abonnés CometD.

Lors de l'utilisation directe d'objets Salesforce, les solutions associées à ce schéma permettent de :

• Le système distant appelle les API Salesforce pour interroger la base de données et exécuter des opérations sur un seul objet (créer, mettre à jour, supprimer, etc.).
• Le système distant qui appelle les ressources composées de l'API REST Salesforce pour effectuer une série d'opérations sur des objets.
• Système distant pour appeler des API Salesforce (services) personnalisées qui peuvent prendre en charge les opérations transactionnelles multi-objets et la logique de traitement préalable/post personnalisé.

Mécanismes d'appel

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

Traitement et récupération des erreurs

Une stratégie de traitement des erreurs et de reprise doit être envisagée dans le cadre de la solution globale.

• Gestion des erreurs : toutes les méthodes d'appel distant, API standard ou personnalisées, nécessitent que le système distant gère les erreurs ultérieures, telles que les expirations et la gestion des tentatives. Middleware peut être utilisé pour fournir la logique de traitement des erreurs et de récupération.
• Récupération : un mécanisme de nouvelle tentative personnalisé doit être créé si les exigences de qualité de service l'exigent. Dans ce cas, il est important de garantir des caractéristiques de conception idempotentes. L'événement de plate-forme permet aux abonnés d'utiliser l'ID de relecture pour récupérer les messages pendant une période donnée après leur publication.

Considérations relatives à la conception impotente

Les capacités inempotentes garantissent que les invocations répétées sont sûres et n'ont aucun effet négatif. Si l'idempotency n'est pas implémentée, les invocations répétées du même message peuvent entraîner des résultats différents, ce qui peut entraîner des problèmes d'intégrité des données, par exemple la création d'enregistrements dupliqués, le traitement des transactions en double, etc.

Le système distant doit gérer les appels multiples (dupliqués) en cas d'erreur ou d'expiration, afin d'éviter les insertions dupliquées et les mises à jour redondantes (en particulier si des déclencheurs en aval et des règles de workflow sont déclenchés). Bien qu'il soit possible de gérer certaines de ces situations dans Salesforce (en particulier dans le cas de services SOAP et REST personnalisés), nous recommandons que le système distant (ou middleware) gère le traitement des erreurs et la conception idempotente.

Considérations de sécurité

Différentes considérations de sécurité s'appliquent, selon la solution de schéma choisie. Dans tous les cas, la plate-forme utilise les droits d'accès de l'utilisateur connecté (par exemple, paramètres de profil, règles de partage, ensembles d'autorisations, etc.). De plus, des restrictions IP de profil peuvent être utilisées afin de restreindre l'accès à l'API pour une plage d'adresses IP spécifique.

Consultez Considérations relatives à la sécurité.

Barres latérales

Aucun.

Délais

L'API SOAP et l'API de service Web Apex sont synchrones. Les expirations suivantes s'appliquent :

• Expiration de la session : la session expire en l'absence d'activité basée sur le paramètre d'expiration de session de l'organisation Salesforce.
• Expiration de la requête : chaque requête SOQL a une limite d'expiration individuelle de 120 secondes.

Volumes de données

Les considérations relatives au volume de données dépendent de la solution et du type de communication que vous choisissez.

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 d'État

Lors de l'intégration de systèmes, les clés sont importantes pour le suivi continu de l'état, par exemple si un enregistrement est créé dans le système distant, afin de prendre en charge les mises à jour continues de cet enregistrement. Il existe deux options :

• Salesforce stocke la clé de substitution primaire ou unique du système distant pour l'enregistrement distant.
• Le système distant stocke l'ID d'enregistrement unique Salesforce ou une autre clé de substitution unique. Il existe des considérations spécifiques pour gérer les clés d'intégration dans ce schéma synchrone.

Scénarios d'intégration complexes

Chaque solution de ce schéma a des considérations différentes lors de la gestion de scénarios d'intégration complexes tels que la transformation et l'orchestration de processus.

Limites du gouverneur

En raison de la nature multilocataire de la plate-forme Salesforce, l'utilisation des API est limitée.

Messagerie fiable

Une messagerie fiable tente de résoudre le problème de la garantie de la livraison d'un message à un système distant où les composants individuels eux-mêmes peuvent ne pas être fiables. L'API SOAP Salesforce et l'API REST sont synchrones et ne prennent en charge explicitement aucun protocole de messagerie fiable en soi (par exemple, WS-ReliableMessaging).

Nous recommandons que le système distant implémente un système de messagerie fiable pour garantir la gestion des scénarios d'erreur et d'expiration. La publication d'événements de plate-forme à partir de systèmes externes s'appuie sur des API Salesforce. Par conséquent, les mêmes considérations s'appliquent à l'API SOAP et à l'API REST.

Capacités middleware

Le tableau ci-dessous met en évidence les propriétés souhaitables d'un système middleware qui participe à ce schéma :

Exemple

Une entreprise de fournitures et de services d'impression utilise Salesforce en tant que frontal pour créer et gérer des fournitures et des commandes d'imprimantes. Les enregistrements d'actifs Salesforce représentant des imprimantes sont périodiquement mis à jour avec des statistiques d'utilisation de l'impression (statut d'encre, niveau de papier) à partir du système de gestion des imprimantes (PMS) sur site, qui surveille régulièrement les imprimantes sur les sites clients. Lorsqu'une valeur de seuil définie est atteinte (par exemple, statut d'encre bas ou niveau de papier faible/vide inférieur à 30%), plusieurs applications/processus (variable) intéressés par l'événement sont notifiés, des alertes par e-mail ou Chatter sont envoyées, et un enregistrement Commande est créé. Le PMS stocke l'ID Salesforce (Salesforce est le principal enregistrement d'actif).

Les contraintes suivantes s'appliquent :

• Le PMS peut participer à une intégration Priorité au contrat, dans laquelle Salesforce fournit le contrat et le PMS agit en tant que client (consommateur) du service Salesforce (défini via le WSDL Enterprise ou Partner).
• Il ne devrait pas y avoir de développement personnalisé dans Salesforce.

Cet exemple est préférable d'utiliser l'API SOAP Salesforce ou l'API REST pour publier des événements, et l'automatisation déclarative (flux) dans Salesforce. La principale raison d'utiliser des événements de plate-forme est le nombre variable et non-défini d'abonnés. Cependant, pour de simples mises à jour d'une liste finie d'enregistrements tels que des commandes, utilisez SOAP ou l'API REST pour mettre à jour les enregistrements.

Dans Salesforce :

• Définissez un événement de plate-forme dans Salesforce pour inclure les données de notification provenant du PMS.
• Créez un flux déclenché par la notification d'événement d'imprimante. Le processus met à jour l'actif de l'imprimante et crée une commande (en utilisant un flux lancé automatiquement).
• Téléchargez le WSDL Enterprise ou Partner et fournissez-le au système distant.

Dans le système distant :

• Créez un stub client à partir du WSDL Enterprise ou Partner.
• Authentifiez-vous à Salesforce (via un serveur Web OAuth ou un flux de jetons du porteur) en utilisant les identifiants de l'utilisateur de l'intégration.
• Lors d'un événement de statut d'imprimante, le PMS appelle l'API pour créer l'événement de plate-forme de statut d'imprimante (avec des statistiques d'utilisation d'imprimante). Le bus d'événement Salesforce notifie l'abonné au flux et tous les autres abonnés.

Lorsque vous utilisez des événements de plate-forme, le bus d'événement permet de relire les événements pendant 72 heures pour les événements de plate-forme à haut volume. La publication de ces événements en utilisant une solution middleware peut aider à incorporer le traitement des erreurs du côté de la publication. Cependant, vous pouvez implémenter le traitement des erreurs côté abonnement si vous avez besoin d'une plus grande fiabilité.

Cet exemple montre les éléments suivants :

• Implémentation d'un client d'API synchrone Salesforce (consommateur).
• Un rappel à Salesforce pour publier un événement de plate-forme (conforme aux modèles d'événement de plate-forme de requêtes/réponses précédemment couverts).

Context

Vous utilisez Salesforce pour gérer les requêtes des clients. Un agent du service client est au téléphone avec un client qui travaille sur une requête. Le client effectue un paiement, et l'agent du service client doit afficher une mise à jour en temps réel dans l'application Salesforce depuis l'application de traitement du paiement, indiquant que le client a réglé avec succès le montant restant de la commande.

Problème

Lorsqu'un événement se produit dans Salesforce, comment l'utilisateur peut-il être notifié dans l'interface utilisateur de Salesforce sans avoir à actualiser son écran et risquer de perdre du travail ?

Forces

Il existe diverses forces à prendre en compte lors de l'application de solutions basées sur ce schéma :

• Les données utilisées doivent-elles être stockées dans Salesforce ?
• Peut-on élaborer une couche d'interface utilisateur personnalisée pour afficher ces données ?
• L'utilisateur aura-t-il accès à l'invocation de l'interface utilisateur personnalisée ?

Solution

La solution recommandée pour résoudre ce problème d'intégration est d'utiliser des événements de plate-forme qui garantissent un événement en temps quasi réel dans Salesforce. Les événements de plate-forme offrent une charge de travail structurée et flexible indépendante de tout objet Salesforce. Il garantit également la durabilité des rubriques avec une fenêtre de relecture de 72 heures. Cela garantit la disponibilité des événements même si un consommateur hors ligne devient disponible plus tard. Cette solution est composée des composants suivants :

• Déclencheur Apex ou Flux avec une logique de publication d'un événement de plate-forme sur une rubrique
• Une rubrique qui permet de publier un événement depuis Déclencheur Apex ou Flux
• Une implémentation basée sur JavaScript du protocole Bayeux (actuellement CometD ) qui peut être utilisée par l'interface utilisateur
• Un composant Lightning
• Une bibliothèque JavaScript incluse en tant que ressource statique

Croquis

Le diagramme ci-dessous illustre comment l'API Streaming peut être implémentée pour diffuser des notifications dans l'interface utilisateur de Salesforce. Ces notifications sont déclenchées par des changements d'enregistrement dans Salesforce.

Mise à jour de l'interface utilisateur dans Salesforce déclenchée par une modification des données

Résultats

Prestations

L'application de la solution associée à ce schéma présente les avantages suivants:

• Élimine la nécessité d'écrire des mécanismes d'interrogation personnalisés
• Élimine la nécessité d'une boucle de rétroaction initiée par l'utilisateur

Exigences non prises en charge

La solution présente les limitations suivantes :

• La remise des notifications n'est pas garantie.
• L'ordre des notifications n'est pas garanti.
• Les notifications ne sont pas générées à partir des modifications apportées aux enregistrements par l'API de transfert en masse.

Considérations de sécurité

La sécurité au niveau de l'organisation Salesforce standard est respectée. Il est recommandé d'utiliser le protocole HTTPS pour vous connecter à l'API Streaming. Consultez Considérations de sécurité

Barres latérales

La solution optimale consiste à créer une interface utilisateur personnalisée dans Salesforce. Il est impératif de prendre en compte un conteneur d'interface utilisateur approprié qui peut être utilisé pour restituer l'interface utilisateur personnalisée. Les navigateurs pris en charge sont répertoriés dans le Streaming API Developer Guide

Exemple

Une entreprise de télécommunications utilise Salesforce pour gérer les requêtes des clients. Les responsables du service client souhaitent être notifiés lorsqu'une requête est fermée avec succès par l'un de leurs agents de service client.

En implémentant la solution prescrite par ce schéma, le client doit :

• Créez un déclencheur Apex PushTopic qui envoie un événement de plate-forme lorsqu'une requête est enregistrée avec un Statut « Fermé » et une Résolution « Réussi ».
• Créez une interface utilisateur personnalisée disponible pour les responsables du service client. Cette interface utilisateur s'abonne au bus d'événement pour consommer des événements de plate-forme.
• Implémentez une logique dans l'interface utilisateur personnalisée qui affiche les alertes générées par les agents du service client de ce responsable.

Context

Vous utilisez Salesforce pour suivre les pistes, gérer votre pipeline, créer des opportunités et capturer les détails des commandes qui convertissent les pistes en clients. Cependant, Salesforce n'est pas le système qui contient ou traite les commandes. Les commandes sont gérées par un système externe (à distance). Cependant, les commerciaux souhaitent afficher et mettre à jour les informations en temps réel sur les commandes dans Salesforce sans avoir à apprendre ni à utiliser le système externe.

Problème

Dans Salesforce, comment afficher, rechercher et modifier des données stockées hors de Salesforce, sans déplacer les données depuis le système externe vers Salesforce ?

Forces

Il existe diverses forces à prendre en compte lors de l'application de solutions basées sur ce schéma :

• Voulez-vous élaborer une intégration sortante déclarative/par pointer-cliquer ou un mashup d'interface utilisateur dans Salesforce ?
• Vous avez un volume de données important que vous ne souhaitez pas copier dans votre organisation Salesforce ?
• Avez-vous besoin d'accéder simultanément à de petites quantités de données système distantes ?
• Avez-vous besoin d'accéder en temps réel aux toutes dernières données ?
• Vous stockez vos données dans le cloud ou dans un système back-office, mais vous souhaitez afficher ou traiter ces données dans votre organisation Salesforce ?
• Vous avez des problèmes de résidence des données pour stocker certains types de données dans Salesforce ?

Solution

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

Croquis

Le diagramme suivant illustre comment vous pouvez utiliser Salesforce Connect pour extraire des données d'un système externe en utilisant un adaptateur Odata.

Dans ce scénario :

1. Le navigateur exécute un appel AJAX qui exécute à son tour une action sur l'adaptateur d'objet externe correspondant.
2. L'adaptateur traduit l'action en requête OData et envoie une requête GET HTTP au système distant via les couches Integration et Services.
3. Le système distant renvoie une réponse JSON à Salesforce via les couches Integration et Services.
4. La réponse est traduite depuis Odata dans un objet externe et renvoyée au navigateur.

Résultats

L'application des solutions associées à ce schéma permet des invocations initiées par l'interface utilisateur dans lesquelles le résultat de la transaction peut être affiché pour l'utilisateur final.

Mécanismes d'appel

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

Traitement des erreurs

Il est important d'inclure le traitement des erreurs dans la solution globale. En cas d'erreur (des exceptions ou des codes d'erreur sont renvoyés à l'appelant), l'appelant gère le traitement des erreurs. Salesforce Connect Validator est un outil gratuit qui permet d ' exécuter des requêtes courantes et de noter les types d ' erreur et les causes d ' échec.

Prestations

Voici quelques avantages de l'utilisation d'une solution Salesforce Connect :

• Cette solution ne consomme pas de stockage de données dans Salesforce.
• Les utilisateurs n'ont pas à se soucier de la synchronisation régulière des données entre le système externe et Salesforce.
• Une configuration déclarative qui peut être réalisée rapidement avec OData, ou un adaptateur inter-organisations, ou en utilisant un code minimal avec un adaptateur Apex personnalisé.
• Les utilisateurs peuvent accéder à des données externes avec les mêmes fonctionnalités que les objets personnalisés sous forme d'objets externes.
• Possibilité d'effectuer une recherche fédérée dans le système externe connecté en utilisant la recherche globale.
• Possibilité d'exécuter des rapports qui accèdent à des données externes à partir de sources cloud et sur site. Consultez les considérations relatives aux rapports ci-dessous.

Considérations relatives à Salesforce Connect

La solution Salesforce Connect présente les considérations suivantes :

• Les objets externes se comportent comme des objets personnalisés, mais certaines fonctionnalités ne sont pas disponibles pour les objets externes. Pour plus d'informations, voir Considérations relatives à la compatibilité Salesforce Connect
• Les objets externes peuvent impacter les performances des rapports. Pour plus d ' informations, voir Considérations relatives aux rapports Salesforce Connect
• Pour plus d'informations sur l'utilisation des adaptateurs Salesforce Connect, voir Considérations relatives à Salesforce Connect - Tous les adaptateurs.
• Si vous envisagez d'utiliser un adaptateur inter-organisations, consultez Considérations relatives à Salesforce Connect - adaptateur inter-organisations.
• Si vous envisagez d'utiliser un adaptateur Odata, consultez Considérations relatives à Salesforce Connect - adaptateurs Odata 2.0 et 4.0.
• Si vous envisagez d'utiliser un adaptateur Apex personnalisé, consultez Considérations relatives à Salesforce Connect - Adaptateur personnalisé.

Considérations de sécurité

Les solutions pour ce modèle doivent respecter la sécurité standard au niveau de l'organisation Salesforce. Il est recommandé d'utiliser le protocole HTTPS pour se connecter à n'importe quel système distant. Pour plus d'informations, consultez Considérations de sécurité

Si vous utilisez un connecteur Odata, assurez-vous de comprendre les comportements spéciaux, les limitations et les recommandations pour la falsification de requête inter-site (CSRF) dans les sources de données externes Odata. Pour plus d'informations, voir Considérations relatives à CSRF pour Salesforce Connect — adaptateurs Odata 2.0 et 4.0.

Barres latérales

Aucun.

Délais

L'opportunité revêt une importance considérable dans ce schéma. Tenez compte des points suivants :

• La requête est généralement invoquée depuis l'interface utilisateur. Par conséquent, le processus ne doit pas faire attendre l'utilisateur.
• Selon la disponibilité et la connexion au système externe, la récupération des données externes peut prendre du temps. Salesforce a une valeur d'expiration maximale configurable de 120 secondes pour attendre une réponse du système externe.
• L'exécution du processus distant doit se faire dans les délais impartis et dans les délais prescrits par Salesforce et dans les attentes des utilisateurs.

Volumes de données

Ce schéma est utilisé principalement pour les activités en temps réel à faible volume, en raison des faibles valeurs d'expiration et de la taille maximale de la requête ou de la réponse pour la solution d'appel Apex. N'utilisez pas ce modèle dans les activités de traitement par lot dans lesquelles la charge de travail des données est incluse dans le message.

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

La prise en charge des capacités et des normes du point de terminaison dépend de la solution que vous choisissez.

Gestion d'État

Lors de l'intégration de systèmes, les clés sont importantes pour le suivi d'état continu. Par exemple, si un enregistrement est créé dans le système distant, il a généralement besoin d'une sorte de clé d'identification pour prendre en charge les mises à jour en cours. Deux options permettent de stocker les clés.

• Salesforce stocke la clé de substitution primaire ou unique de l'enregistrement distant.
• Le système distant stocke l'ID d'enregistrement unique Salesforce ou une autre clé de substitution unique. Il existe des considérations spécifiques pour gérer les clés d'intégration dans ce schéma synchrone.

Intégrations complexes

Dans certains cas, la solution prescrite par ce schéma peut nécessiter l'implémentation d'un scénario d'intégration complexe. Ces scénarios sont souvent résolus en utilisant un middleware.

• Agrégation des appels et de leurs résultats entre les appels à plusieurs systèmes
• Transformation des messages entrants et sortants
• Maintien de l'intégrité transactionnelle entre les appels à plusieurs systèmes
• Autres activités d'orchestration de processus entre Salesforce et le système externe

Limites applicables

Différentes limites s'appliquent à différents adaptateurs. Pour plus de détails, voir Limites générales de Salesforce Connect .

Capacités middleware

Le tableau ci-dessous met en évidence les propriétés souhaitables d'un système middleware qui participe à ce schéma.

Relations des objets externes

Les objets externes prennent en charge les relations de référence standard, qui utilisent l'ID d'enregistrement Salesforce à 18 caractères pour associer des enregistrements associés. Cependant, les données stockées hors de votre organisation Salesforce ne contiennent souvent pas ces ID d'enregistrement. Par conséquent, deux types spéciaux de relations de référence sont disponibles pour des objets externes : les références externes et les références indirectes.

Le tableau ci-dessous récapitule les types de relation disponibles pour des objets externes.

Considérations relatives au volume de données élevé pour Salesforce Connect - adaptateurs Odata 2.0 et 4.0

Si votre organisation atteint les limites en taux en accédant à des objets externes, vous pouvez sélectionner l'option Volume de données élevé dans les sources de données externes associées. Cela permet de contourner la plupart des limitations tarifaires, mais certains comportements spéciaux et certaines limitations s'appliquent. Pour plus d ' informations, voir Considérations relatives au volume de données élevé pour Salesforce Connect

Paging pilotée par le client et pilotée par le serveur pour Salesforce Connect - adaptateurs Odata 2.0 et 4.0

Il est fréquent que les requêtes Salesforce Connect de données externes contiennent un jeu de résultats volumineux divisé en plus petits lots ou pages. Vous choisissez si le comportement de pagination est contrôlé par le système externe (piloté par le serveur) ou par l'adaptateur Odata 2.0 ou 4.0 pour Salesforce Connect (piloté par le client). Le champ Pagination pilotée par le serveur de la source de données externe spécifie si la pagination pilotée par le client ou pilotée par le serveur est utilisée. Si vous activez la pagination pilotée par le serveur dans une source de données externe, Salesforce ignore les tailles de page demandées, y compris la taille de lot queryMore() par défaut de 500 lignes. Les pages renvoyées par le système externe déterminent les lots, mais chaque page ne peut pas dépasser 2000 lignes. Cependant, les limites des adaptateurs Odata pour Salesforce Connect restent applicables.

Exemple

Une entreprise de fabrication utilise Salesforce pour gérer les requêtes des clients. Les agents du service client souhaitent accéder aux informations en temps réel sur les commandes depuis le système ERP back-office pour obtenir une vue complète du client sans avoir à apprendre et à exécuter manuellement des rapports dans le système ERP.

En implémentant la solution prescrite par ce schéma, vous devez :

• Configurez votre source de données externe avec un point de terminaison Odata. Votre application distante peut inclure la prise en charge native d'Odata . Pour d'autres applications, les principaux fournisseurs d'intégration tels que Dell Boomi, Informatica, Jitterbit, MuleSoft et Progress Software se sont associés à Salesforce sur Salesforce Connect pour élaborer des adaptateurs.
• Pointez Salesforce Connect vers le point de terminaison OData, soit directement, soit via une solution middleware.
• Synchronisez vos tableaux de base de données externes avec des objets externes dans Salesforce. Lorsqu'un utilisateur accède à une page contenant les données de ces objets externes, Salesforce Connect passe des appels externes en temps réel à vos applications back-end.

Documentation du développeur

• Aide de Salesforce : Octroi de l'accès API uniquement aux utilisateurs de l'intégration

• SOAP API Developer Guide

• REST API Developer Guide

• Streaming API Developer Guide

• Bulk API 2.0 et Bulk API Developer Guide

• Apex Developer Guide

• Référence SOQL et SOSL

• Référence rapide sur les limitations et allocations Salesforce Developer

• Platform Events Developer Guide

• Apex Developer Guide: Salesforce Connect

Trailhead

• Volumes de données importants

• Basiques des événements de plate-forme

• Modification Capture des données

• Démarrage rapide : Salesforce Connect

Pour être des membres efficaces du portefeuille d'entreprises, toutes les applications doivent être créées et intégrées aux mécanismes de sécurité appropriés. Les stratégies informatiques modernes emploient une combinaison de services sur site et basés sur le cloud.

Bien que l'intégration de services cloud à cloud se concentre généralement sur les services Web et les autorisations associées, la connexion de services sur site et cloud introduit souvent une complexité accrue. Cette section décrit les outils, les techniques et les considérations spécifiques à Salesforce.

Reverse Proxy Server

Un proxy inverse est un serveur qui se trouve devant des serveurs Web et transmet les requêtes client (par exemple un navigateur Web) à ces serveurs Web. Les proxy inverses sont généralement implémentés pour renforcer la sécurité, les performances et la fiabilité.

C'est un type de serveur proxy qui récupère des ressources au nom d'un client à partir d'un ou de plusieurs serveurs. Ces ressources sont ensuite renvoyées au client comme si elles provenaient du serveur proxy lui-même. Contrairement à un proxy forward, qui est un intermédiaire permettant à ses clients associés de contacter n'importe quel serveur, un proxy reverse est un intermédiaire permettant à ses serveurs associés d'être contactés par n'importe quel client.

Dans les implémentations Salesforce, un tel service est généralement fourni via un produit passerelle externe. Par exemple, des options de source ouverte telles que Apache HTTP, lighttpd et nginix peuvent être utilisées. Les produits commerciaux comprennent IBM WebSeal et Computer Associates SiteMinder. Ces produits peuvent être aisément configurés pour proxy et gérer toutes les requêtes Salesforce sortantes au nom du demandeur interne.

Cryptage

Certaines entreprises exigent que les transactions ou les champs de données sélectionnés soient cryptés entre une combinaison d'applications sur site et basées sur le cloud. Si votre organisation doit respecter des exigences de conformité supplémentaires, vous pouvez mettre en œuvre des alternatives, notamment :

• Services de passerelle de cryptage commercial sur site, y compris les propres de Salesforce, CipherCloud, IBM DataPower, Computer Associates. Pour chaque solution, le moteur de cryptage ou la passerelle est invoqué à la frontière de la transaction en envoyant et en recevant une charge utile cryptée, ou en cryptant ou en décryptant des champs de données spécifiques avant l'exécution de la requête HTTP(S).

• Options basées sur le cloud, telles que Salesforce Shield Platform Encryption. Shield Platform Encryption offre à vos données une toute nouvelle couche de sécurité tout en préservant les fonctionnalités critiques de la plate-forme. Les données que vous sélectionnez sont cryptées au repos en utilisant un système de dérivation de clé avancé. Vous pouvez protéger vos données avec plus de sécurité que jamais. Pour plus d'informations, consultez l'aide en ligne de Salesforce.

Support de protocole WS-* spécialisé

Pour répondre aux exigences des protocoles de sécurité (tels que WS-*), nous recommandons les alternatives ci-dessous.

• Passerelle Sécurité/XML : injectez les identifiants WS-Security (IBM WebSeal ou Datapower, Layer7, TIBCO, etc.) dans le flux de transaction lui-même. Cette approche ne nécessite aucune modification des services Web au niveau de l'application ou des invocations de services Web de Salesforce. Vous pouvez également réutiliser cette approche dans l'ensemble de l'installation de Salesforce. Cependant, il nécessite une conception, une configuration, des tests et une maintenance supplémentaires pour gérer l'injection appropriée de WS-Security dans l'approche de passerelle de sécurité existante.

• Cryptage au niveau du transport : cryptez le canal de communication en utilisant des restrictions SSL et IP bidirectionnelles. Bien que cette approche n'implémente pas directement le protocole WS-* en soi, elle sécurise le canal de communication entre les applications sur site et Salesforce sans transmettre de nom d'utilisateur et de mot de passe. Elle ne nécessite pas non plus de modification des classes générées par Salesforce. Cependant, certaines modifications des services Web sur site peuvent être nécessaires (dans l'application elle-même ou dans la couche middleware/ESB).

• Développement personnalisé Salesforce : ajoutez des en-têtes WS-Security à la requête SOAP sortante via l'utilitaire WSDL2Apex. Cela génère une classe Apex de type Java à partir du fichier WSDL utilisé pour invoquer le service interne. Bien que cette approche n'exige aucune modification des services Web back-end ou des composants supplémentaires dans la DMZ, elle nécessite :

  • une augmentation des efforts de build et de test
  • un processus relativement complexe et manuel pour coder manuellement les attributs WS-Security (y compris la sérialisation XML dans le code Apex)
  • un effort de maintenance à long terme plus élevé

Note: La dernière option n'est pas recommandée en raison de sa complexité et du risque que de telles intégrations nécessitent des examens périodiques basés sur des mises à jour régulières de Salesforce.

Autres considérations de sécurité

• Identifiants nommés : Destinée à sécuriser et à simplifier les appels d'API authentifiés à des systèmes externes, un identifiant nommé spécifie l'URL d'un point de terminaison d'appel et ses paramètres d'authentification requis dans une seule définition. Pour rationaliser votre code Apex et simplifier la configuration des appels externes authentifiés, spécifiez un identifiant nommé en tant que point de terminaison d'appel externe. Pour plus de détails, voir ici.

• OAUTH 2.0 : OAuth 2.0 est une infrastructure d'autorisation standard de l'industrie qui permet à un utilisateur d'accorder un accès limité à ses ressources protégées à une application tierce sans partager ses identifiants (tels que des mots de passe). Au lieu d'un échange direct de mot de passe, l'utilisateur approuve une demande de jeton d'accès, que l'application utilise ensuite pour accéder à ses données à partir d'un serveur de ressources. Ce processus sépare l'application cliente de l'identité et du mot de passe de l'utilisateur, ce qui renforce la sécurité en fournissant une « clé » temporaire, spécifique au périmètre, pour accéder aux ressources. Pour plus d'informations, voir ici.

• Private Connect : Lorsque vous intégrez votre organisation Salesforce à des applications hébergées sur des services cloud tiers, il est essentiel de pouvoir envoyer et recevoir du trafic HTTP/s en toute sécurité. Avec Private Connect, renforcez la sécurité de vos intégrations Amazon Web Services (AWS) en configurant une connexion réseau entièrement gérée entre votre organisation Salesforce et votre Cloud privé virtuel (VPC) AWS. Acheminez ensuite votre trafic inter-clouds via la connexion au lieu d'Internet public afin de réduire l'exposition aux menaces de sécurité extérieures. Private Connect est disponible en partenariat avec AWS via une fonctionnalité appelée AWS PrivateLink. Private Connect est bidirectionnelle : vous pouvez initier un trafic entrant et sortant. Avec les connexions entrantes, vous pouvez envoyer du trafic dans Salesforce en utilisant les API standard. Avec les connexions sortantes, vous pouvez envoyer du trafic hors de Salesforce via des fonctionnalités telles que les appels externes Apex, les Services externes et les Objets externes. Pour plus d'informations sur le VPC, veuillez cliquer ici.

Le bus d'événement Salesforce avec événements de plate-forme, capture des données de modification (CDC) et l'API Pub /Sub permet aux entreprises de créer des architectures de style pilotées par l'événement (EDA).

Une EDA dissocie les consommateurs de messages d'événement (abonnés) des producteurs de messages d'événement (éditeurs), ce qui augmente l'échelle et la flexibilité. Des modèles spécifiques sont traités dans ce document dans le cadre de la structure existante qui compare et compare les alternatives ou options associées. Cependant, une compréhension globale de l'architecture pilotée par l'événement et de l'interaction des modèles peut vous aider à sélectionner le modèle adapté à vos besoins.

Khalid Mohammed est un éminent architecte leader au sein des Services professionnels de Salesforce. Depuis qu’il a rejoint Salesforce en 2015, il a mis à profit sa vaste expertise dans les applications et l’architecture d’entreprise, s’est affiné à travers de nombreuses transformations client avant d’occuper son poste chez Salesforce. Khalid dirige le Conseil d'architecture de livraison et est également reconnu comme un architecte technique certifié leader.

Gulal Kumar est architecte en génie logiciel chez Salesforce, spécialisé dans l'architecture de données et d'intégration. Avec plus de 20 ans d'expérience dans l'intégration et les API, les programmes de modernisation, la sécurité et les initiatives AIML, il apporte une riche expertise. Gulal s’est engagé à faire progresser les initiatives de transformation métier, à renforcer la sécurité et la résilience, à promouvoir l’excellence en architecture et à piloter des initiatives AIML dans divers domaines.

Sushant est architecte technique chez Salesforce, spécialisé dans l'architecture de solutions et la livraison de bout en bout de plates-formes Salesforce. Doté d’une expertise approfondie en gouvernance de plate-forme, en développement d’applications, en intégration et en DevOps, il a dirigé de nombreux programmes de transformation client à travers les secteurs d’activité. Sushant s'engage à favoriser l'excellence de la livraison et des résultats architecturaux évolutifs.