# architect Diagrammes de référence (reference-diagrams) - Full Documentation # Activation par lot Data 360 et architecture d'actions pilotées par l'événement Activation par lot Salesforce Data 360 et architecture d'action pilotée par l'événement ## Description Diagramme représentant Salesforce Data 360 dans une solution complète pour les activations marketing. Transformez vos données en actions immédiates avec Salesforce Data 360. En exploitant les connecteurs prêts à l'emploi et les plates-formes de maison Data Lake sans interopérabilité de copie, vous éliminez les mouvements de données complexes et accédez directement à l'exécution. Cette connexion transparente agit comme une couche d'unification et d'activation dynamique à travers toutes les plates-formes fédérées, déclenchant les activations, les actions intelligentes et en temps réel requises pour devenir une entreprise entièrement Agentic. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/620837ec-bb08-4f1e-af26-1164fc5f789c) - [Image](https://sf-archs.cdn.salesforce-experience.com/cms/delivery/media/MCJU43MZY5WRELXAAIBCYP5NIT6A?channelId=0apHs000000y0QG&oid=00DHs000003Wrxy) # Agentforce Roadmap Agentforce roadmap - un exemple de feuille de route montrant les composants de déploiement pour l'IA à travers une implémentation Salesforce Customer 360 ## Description Une feuille de route montrant les étapes de déploiement des fonctionnalités Agentforce dans une implémentation Salesforce Customer 360. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/1d9723f0-0835-4dc2-9cbb-01b2e97c91e8) - [Image](https://architect.salesforce.com/ns-assets/legacy/generativeairollout.png) # Algorithme d'utilisation équitable Apex par lot algorithme d'utilisation équitable Apex par lot - montre comment l'algorithme d'utilisation équitable garantit que chaque organisation sur la plate-forme Salesforce reçoit une «part équitable» du temps de traitement sur un type de message donné. Dans cet exemple, l'organisation 1 domine le type de message Apex par lot, tandis que l'organisation 2 a des processus d'attente de même type de message. En conséquence, l'algorithme a réduit le nombre de threads disponibles pour l'organisation 1. ## Description montre comment l'algorithme d'utilisation équitable garantit que chaque organisation sur Salesforce Platform reçoit une « part équitable » du temps de traitement sur un type de message donné. Dans cet exemple, l'organisation 1 domine le type de message Apex par lot, alors que l'organisation 2 a des processus d'attente de même type de message. Par conséquent, l'algorithme a réduit le nombre de threads disponibles pour l'organisation 1. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/d23a6022-45df-4632-9d0d-f646dee6eaa0) - [Image](https://architect.salesforce.com/ns-assets/legacy/fairusage.png) # Architecture d'implémentation Customer Zero Data 360 Architecture d'implémentation Customer Zero Data 360 ## Description Un diagramme de bout en bout montrant Salesforce Data 360 tel qu'implémenté dans Salesforce en tant que notre programme Customer Zero. Salesforce Data 360 sert de couche centrale d'intelligence et de gouvernance, unifiant les données d'entreprise via la fédération Zero Copy avec des systèmes externes Snowflake et AWS tout en préservant Trust et sémantique. Cette fondation de données prête pour l'IA unifiée propulse l'activation Agentforce 360\. Elle permet aux agents riches en raisonnement, l'enrichissement CRM et l'automatisation inter-clouds avec des flux de données sécurisés et sensibles aux politiques à travers toutes les fonctions métiers, transformant ainsi l'organisation en entreprise agentique. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/af215946-127b-4b47-95b9-a7c158be351b) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/sfdc_customer_zero_implementation.png) # Architecture d'intégration de données sans copie entre Salesforce Data 360 et AWS Architecture d'intégration de données sans copie entre Salesforce Data 360 et AWS ## Description Diagramme montrant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à divers services de données AWS, ainsi que la puissante interopérabilité Zero Copy avec AWS Redshift et S3. Cette architecture permet aux organisations d'intégrer et d'unifier de façon transparente les données à travers les plates-formes fédérées, en fournissant une couche d'unification et d'activation centrale qui est essentielle pour la transformation en véritable entreprise Agentic. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/04991364-85c0-45e6-b5de-553367fbb473) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-aws.png) # Architecture d'intégration de données sans copie entre Salesforce Data 360 et Databricks Schémas d'intégration de données sans copie entre Salesforce Data 360 et Databricks ## Description Diagramme représentant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à Databricks Delta Lake house Platform en utilisant l'interopérabilité Zero Copy. Cette architecture permet aux organisations d'intégrer et d'unifier de façon transparente les données à travers les plates-formes fédérées, en fournissant une couche d'unification et d'activation centrale qui est essentielle pour la transformation en véritable entreprise Agentic. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/e74f6e22-ce6d-4b6d-a258-76ddb8f73f4e) - [Image](https://sf-archs.cdn.salesforce-experience.com/cms/delivery/media/MCBDXPMJDI2VCTRKXXYRHJCFANPQ?channelId=0apHs000000y0QG&oid=00DHs000003Wrxy) # Architecture d'intégration de données sans copie entre Salesforce Data 360 et GCP Architecture d'intégration de données sans copie entre Salesforce Data 360 et GCP ## Description Diagramme représentant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à divers services Google Cloud Platform. Salesforce Data 360 unifie les données et pilote l'action. Il inclut des connecteurs prêts à l'emploi pour l'intégration à divers services Google Cloud Platform avec la puissante interopérabilité Zero Copy avec Google BigQuery et Google Cloud Storage. Cette architecture permet aux organisations d'intégrer et d'unifier de façon transparente les données à travers les plates-formes fédérées, en fournissant une couche d'unification et d'activation centrale qui est essentielle pour la transformation en véritable entreprise Agentic. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/4661f0e4-e86a-409b-9a98-8301cbbca74f) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-gcp.png) # Architecture d'intégration de données sans copie entre Salesforce Data 360 et Snowflake Architecture d'intégration de données sans copie entre Salesforce Data 360 et Snowflake ## Description Diagramme représentant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à Snowflake Data Lake House Platform en utilisant l'interopérabilité Zero Copy. Cette architecture permet aux organisations d'intégrer et d'unifier de façon transparente les données à travers les plates-formes fédérées, en fournissant une couche d'unification et d'activation centrale qui est essentielle pour la transformation en véritable entreprise Agentic. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/b02236c2-f3f4-4de8-b13b-35f67fd5390d) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-snf.png) # Architecture d'organisation unique Single org architecture (architecture d'organisation unique) : diagramme détaillant une stratégie d'organisation unique prenant en charge les unités commerciales internationales. ## Description Diagramme détaillant une stratégie d'organisation unique prenant en charge plusieurs unités commerciales. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/92edbe8d-18b8-4998-a851-7d1e815ea7d5) - [Image](https://architect.salesforce.com/ns-assets/legacy/singleorgarchitecture.png) # Architecture de la solution de gestion de la fidélité Architecture de solution de gestion de la fidélité : un diagramme d'architecture qui présente les produits et les capacités directement impliqués dans une solution de gestion de la fidélité. ## Description Diagramme d'architecture qui présente les produits et les capacités directement impliqués dans une solution de gestion de la fidélité. Cela inclut Commerce, Sales, Service et Analytics. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/217c76c7-b8c4-44ed-aade-a7ae3fb8df0a) - [Image](https://architect.salesforce.com/ns-assets/legacy/loyalty-management-solution-architecture.png) # Architecture de solution Les diagrammes d'architecture de solution illustrent les détails de conception technique et d'implémentation de solutions spécifiques, montrant comment les composants, les services et les intégrations fonctionnent ensemble pour répondre aux exigences métiers. Ces diagrammes présentent aux architectes et aux développeurs une vue détaillée des interactions système, des flux de données et des modèles architecturaux. Ils servent de modèles pour l'implémentation, aidant les équipes à comprendre les relations des composants, les points d'intégration et les dépendances techniques au sein d'une solution. Cette section contient 7 diagrammes de référence associés à l'architecture de solution : | Nom du diagramme | Description | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | [Architecture d'intégration de données sans copie entre Salesforce Data 360 et GCP](/docs/architect/fr-fr/reference-diagrams/guide/data360-gcp) | Diagramme représentant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à divers services Google Cloud Platform. | | [Architecture d'intégration de données sans copie entre Salesforce Data 360 et AWS](/docs/architect/fr-fr/reference-diagrams/guide/aws-data-360) | Diagramme représentant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à divers services de données AWS. | | [Architecture d'intégration de données zéro copie entre Salesforce Data 360 et Snowflake](/docs/architect/fr-fr/reference-diagrams/guide/snf-data-360) | Diagramme représentant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à Snowflake Data Lake House Platform. | | [Architecture d'intégration de données sans copie entre Salesforce Data 360 et Databricks](/docs/architect/fr-fr/reference-diagrams/guide/data360-databricks) | Diagramme représentant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à Databricks Delta Lake house Platform. | | [Architecture d'implémentation Customer Zero Data 360](/docs/architect/fr-fr/reference-diagrams/guide/sfdc-customer-zero-implementation) | Un diagramme de bout en bout montrant Salesforce Data 360 tel qu'implémenté dans Salesforce en tant que notre programme Customer Zero. | | [Activation par lot Data 360 et architecture d'action pilotée par l'événement](/docs/architect/fr-fr/reference-diagrams/guide/data360-actions-activations) | Diagramme représentant Salesforce Data 360 dans une solution complète pour les activations marketing. | | [Architecture de solution de gestion de la fidélité](/docs/architect/fr-fr/reference-diagrams/guide/loyalty-management-solution-architecture) | Diagramme d'architecture qui présente les produits et les capacités directement impliqués dans une solution de gestion de la fidélité. | # Boxcarring dans JavaScript Remoting boxcarring dans le remoting javascript - montre comment plusieurs requêtes de remoting JavaScript peuvent être émises en même temps, ou «boxcar'ed» dans une seule requête HTTP à la plate-forme principale Salesforce. Sur la plate-forme, chacun des boxcars (c'est-à-dire une action de remoting JavaScript séparée) sera traité en série et dans l'ordre dans un contexte de transaction synchrone Apex séparé. ## Description montre comment plusieurs requêtes distantes JavaScript peuvent être émises en même temps, ou « boxcar » dans une seule requête HTTP à la plate-forme principale Salesforce. Sur la plate-forme, chacun des wagons couverts (c'est-à-dire une action distante JavaScript séparée) sera traité en série et dans l'ordre dans un contexte de transaction synchrone Apex séparé. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/ef9e594d-58c5-4554-97c8-0147f2f14bc2) - [Image](https://architect.salesforce.com/ns-assets/legacy/jsremotingboxcarring.png) # Boxcarring dans les actions Lightning boxcarring dans les actions Lightning - montre comment plusieurs actions Lightning peuvent être émises en même temps, ou «boxcar'ed» dans une seule requête XHR à la plate-forme principale Salesforce. Chacun des wagons couverts par la requête XHR sera traité en série et dans l'ordre dans un contexte de transaction séparé. ## Description montre comment plusieurs actions Lightning peuvent être émises en même temps, ou « boxcar'ed » dans une seule requête XHR à la plate-forme principale Salesforce. Chaque wagon couvert de la requête XHR sera traité de façon sérielle et dans l'ordre dans un contexte de transaction séparé. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/6f6709ed-d1e7-446a-8385-286c2771be85) - [Image](https://architect.salesforce.com/ns-assets/legacy/lightningactionboxcarring.png) # Carte des capacités Les cartes des capacités offrent une représentation visuelle des capacités commerciales et techniques, illustrant comment différents produits et services contribuent aux objectifs de l'organisation. Ces diagrammes aident les architectes et les parties prenantes à comprendre la relation entre les moteurs métiers, les capacités et la pile technologique sous-jacente. Ils servent d'outils de planification stratégique qui permettent une meilleure adéquation entre les objectifs métiers et la mise en œuvre technique. Cette section contient 4 diagrammes de référence associés aux cartes de capacité : | Nom du diagramme | Description | | --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | [Carte des capacités commerciales](/docs/architect/fr-fr/reference-diagrams/guide/business-capability-map) | Une carte des capacités d'un modèle pour représenter les moteurs métiers et les capacités avec un positionnement produit de haut niveau. | | [Carte des capacités techniques Data 360](/docs/architect/fr-fr/reference-diagrams/guide/data-360-technical-capability-map) | Une carte des capacités montrant les capacités techniques de Data 360 et le mix produit impliqué dans leur prise en charge. | | [Carte des capacités de gestion de la fidélité](/docs/architect/fr-fr/reference-diagrams/guide/loyalty-management-capability-map) | Une carte des capacités montrant les services de gestion de la fidélité avec un positionnement produit de haut niveau. | | [Center of Excellence](/docs/architect/fr-fr/reference-diagrams/guide/center-of-excellence) | Un diagramme détaillant comment un Centre d'excellence (CoE) relie les parties prenantes exécutives et l'informatique. | # Carte des capacités commerciales Carte des capacités métiers : un modèle de carte des capacités qui présente les moteurs et les capacités métiers avec un positionnement produit de haut niveau. ## Description Une carte des capacités d'un modèle pour représenter les moteurs métiers et les capacités avec un positionnement produit de haut niveau. ## Liens téléchargeables : - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/business-capability-map.webp) # Carte des capacités de gestion de la fidélité Carte des capacités de gestion de la fidélité : une carte des capacités qui montre les services de gestion de la fidélité avec un positionnement produit de haut niveau. Elle inclut des capacités telles que Administration de la fidélité, Traitement et Analytics. ## Description Une carte des capacités montrant les services de gestion de la fidélité avec un positionnement produit de haut niveau. Il inclut des capacités telles que Loyalty Administration, Processing et Analytics. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/d41ccba2-71ea-449a-8497-ea95396102b4) - [Image](https://architect.salesforce.com/ns-assets/legacy/loyalty-management-capability-map.png) # Carte des capacités techniques Data 360 Carte des capacités techniques de Data 360 : une carte des capacités qui montre les capacités techniques de Data 360 et la combinaison de produits impliqués dans leur prise en charge. Elle inclut des capacités telles que Data Lakehouse, Traitement des Big Data, Connecteurs de données, Transformations, Modèles et Source unique de vérité. ## Description Une carte des capacités montrant les capacités techniques de Data 360 et le mix produit impliqué dans leur prise en charge. Il inclut des capacités telles que Data Lakehouse, Traitement des Big Data, Connecteurs de données, Transformations, Modèles et Source unique de vérité. ## Liens téléchargeables : - [Image](https://architect.salesforce.com/ns-assets/legacy/data360technicalcapabilitymap.png) # Centre d'excellence center of excellence - Diagramme montrant comment un Centre d'excellence (CoE) relie les parties prenantes exécutives et les TI. Il montre comment les capacités fonctionnelles et techniques de leadership sont essentielles pour un CoE. ## Description Diagramme montrant comment un Centre d'excellence (CoE) relie les parties prenantes exécutives et l'informatique. Il souligne comment les capacités fonctionnelles et techniques de leadership sont essentielles pour un Conseil de l'Europe. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/59956c3b-3c73-469b-87a4-44c6dad948e5) - [Image](https://architect.salesforce.com/ns-assets/legacy/centerofexcellenceoperatingmodel.png) ## Introduction Les diagrammes sont un outil essentiel et un élément clé du travail architectural. Ils nous permettent de communiquer de nombreuses idées différentes à de nombreux types de parties prenantes. Les diagrammes aident les équipes de livraison à rester alignées, en servant de source unique de vérité sur les réalités des implémentations et des produits. Les diagrammes sont également essentiels pour permettre aux parties prenantes de prendre les bonnes décisions en matière d'achat et de technologie. **Les diagrammes doivent toujours :** - Lire de gauche à droite et de haut en bas, le plus près possible - Transmettez un message concis, avec un éventail d'informations approprié pour faciliter la lecture - Utiliser les [composants standard Salesforce Diagrams](/docs/architect/fr-fr/reference-diagrams/guide/kit-of-parts), y compris des cartes et un en-tête avec une description claire décrivant le contenu, la portée et l'objet du diagramme ## Portée du diagramme La portée d'un diagramme doit se limiter aux informations critiques à transmettre pour un sujet spécifique. Tout élément qui n'est pas nécessaire pour capturer le message que vous souhaitez communiquer doit être exclu. Plusieurs diagrammes peuvent (et doivent) être créés pour capturer divers concepts, afin de communiquer plus clairement et d'affiner le contenu du diagramme. - Définir les informations/messages critiques que vous devez transmettre à votre audience - Classer les étendues logiques afin de concentrer les informations pour capturer le message - Identifier le ou les types de diagramme les plus appropriés à utiliser en tant que modèles ## Types de diagramme Salesforce Diagrams a défini nos types de diagramme les plus utiles/populaires afin de vous aider à utiliser des modèles et à comprendre les conventions de diagramme. Nos ressources actuelles sont classées comme suit : ### Cartes des capacités - Capturer la combinaison de propriétés et les capacités clés pertinentes incluses dans une solution - Mettre l'accent sur les fonctionnalités, les moteurs métiers et les valeurs ✨ Recherche de cartes de capacité dans la [galerie d'architecture](/reference-diagrams/guide/section-capability-map) de référence ### Paysages système - Capturer les produits et/ou les systèmes techniques impliqués dans une implémentation donnée - Mettre en évidence les propriétés, les aspects spécifiques des propriétés et les connexions entre les propriétés ✨ Recherchez des exemples et des modèles de paysage système dans la [galerie Architecture de référence](/reference-diagrams/guide/section-system-landscape) ### Architectures de solutions - Inclure des produits ou des technologies avec une intégration, un comportement et/ou des fonctionnalités - Mettre l'accent sur les connexions détaillées et/ou les aspects de communication entre les propriétés ✨ Retrouvez des exemples et des modèles d’architecture de solution dans la [galerie Architecture de référence](/reference-diagrams/guide/section-solution-architecture) ### Interaction / Processus / Flux - Capturer les étapes temporelles, les flux de données ou les interactions requis pour prendre en charge un processus - Mettre en évidence et clarifier (avec la numérotation séquencée) l'ordre des aspects/propriétés ✨ Retrouvez des exemples et des modèles de diagrammes d'interaction, de processus et de flux dans la [galerie Architecture de référence](/reference-diagrams/guide/section-interaction-process-flow) ### Modèles de données / ERD - Capturer des entités (objets), des relations et des concepts pour des implémentations de métadonnées ✨ Recherchez des exemples et des modèles de modèle de données dans la [Galerie de modèles](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html) de données Consultez des exemples de types de diagramme dans la [galerie d'architecture](/diagrams) de référence ou dans notre [galerie de modèles](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html) de données dédiée. Utilisez un modèle pour créer rapidement et aisément un diagramme adapté à votre cas d'utilisation. ## Étapes de création d'un diagramme : - Définissez la **portée** du message que vous devez transmettre : - _Pensez à votre audience, aux propriétés/aspects que vous devez représenter, aux informations nécessaires pour capturer le message et à ce qui peut être exclu_ - Assurez-vous qu'il y a un **en-tête** avec un **titre** clair et une **description** concise et réfléchie qui capture l'objet, la portée et le message de votre diagramme Assurez-vous que l'en-tête contient un titre clair et une description concise et réfléchie qui reflète l'objet, la portée et le message de votre diagramme - Utilisez des **cartes** pour capturer les propriétés (systèmes, concepts, entités, etc.) - Capturer les détails des propriétés ou les principaux aspects / capacités si nécessaire dans **les attributs Carte** Attributs de carte - Représenter les relations nécessaires avec les **connecteurs** entre les propriétés de votre carte Connecteurs - Incorporer des **icônes de carte** lorsque cela est utile, disponible et/ou approprié Icônes Carte - Utiliser les **pieds de** page et les **icônes de pied** de page pour capturer d'autres aspects clés des propriétés Icônes de pied de page Pour plus d'informations et les meilleures pratiques, consultez la [page Composants standard](/docs/architect/fr-fr/reference-diagrams/guide/kit-of-parts). **Vous avez une entrée ou des questions sur les diagrammes Salesforce ?** S'il vous plaît faites-nous part de vos pensées [ici](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link). ## Composants standard Les composants standard facilitent l'élaboration, la personnalisation et la réutilisation de diagrammes cohérents et de haute qualité. Ce style professionnel est utilisé pour tous les modèles de diagramme Salesforce, et est disponible dans nos outils partenaires pour schématiser des cas d'utilisation :
Lucidchart Lucidchart Elements.cloud Éléments Miro Miro Google Slides Google Slides

Recherchez des exemples d'utilisation de composants dans la [galerie Architecture de référence](https://architect.salesforce.com/diagrams#reference-architecture-gallery) ## Meilleures pratiques Les sections suivantes présentent les meilleures pratiques détaillées pour l'[en-tête](#en-tête), [les cartes](#cartes), [les icônes](#icônes) et [les connecteurs](#connecteurs) inclus dans les composants standard. ## En-tête En-tête du diagramme L'en-tête doit être présent sur tous les diagrammes et inclure : - Un titre qui peut être rapidement compris par votre audience - Une description claire de ce que le diagramme couvre, son but et son intention - (facultatif) votre logo ou nom de société pour transmettre l'auteur - (facultatif) une Clé pour clarifier les icônes, dessins ou symboles utilisés en tant que classifications La taille doit occuper au moins 10 % de la hauteur du diagramme et 100 % de la largeur. La taille de police de la description doit être au moins égale à la moitié de la taille du titre. Une Clé doit être incluse lors de l'utilisation d'icônes, de connecteurs, de couleurs, etc., qui ne sont pas spécifiées avec des titres sur le diagramme lui-même. La clé doit être regroupée en lignes paires si possible. ## Cartes Toutes les propriétés de votre diagramme doivent être représentées par une carte. Les cartes peuvent être redimensionnées et avoir des remplissages transparents ou colorés. Plusieurs sections de la carte présentent des variantes que vous pouvez utiliser pour représenter différents concepts dans votre diagramme. ### **Anatomie des cartes** Un exemple de carte est ci-dessous, avec les différentes sections décrites. Le seul contenu de la Carte requis est le Titre. Les autres sections peuvent être utilisées selon les besoins pour des cas d'utilisation spécifiques. Anatomie des cartes **Icône Carte** Les icônes de carte sont des actifs visuels représentant la propriété de la carte **Titre de la carte** Le titre de la carte est un nom de carte qui peut être rapidement compris, capturant la propriété, la zone ou le concept que la carte représente **Attributs de carte** Les attributs de carte sont des détails textuels sur la propriété, représentés sous forme de liste et utilisés lorsque vous devez capturer et transmettre plusieurs points de données **Pied de page** Le pied de page de la carte fournit des caractéristiques supplémentaires de la propriété. Exemples : Noms de package/ d'objet/ d'API, Propriété, Capacités, etc. **Icônes de pied de page de carte** La section Icônes de pied de page permet aux actifs visuels d'afficher des informations supplémentaires sur la propriété. Par exemple, canaux, services partagés, capacités, etc. Les icônes de pied de page doivent être incluses / expliquées dans votre clé de diagramme. ### **Variations de carte** L'utilisation de différentes sections fournit différentes variantes de carte pour différentes utilisations. Vous pouvez mélanger et mapper l'anatomie des cartes si nécessaire pour créer ces variations dans vos diagrammes. Voir exemples ci-dessous : Carte réduite Carte détaillée Carte détaillée avec pied de page Pour des idées sur l'utilisation de ces variantes, consultez la [Galerie d'architecture](https://architect.salesforce.com/diagrams#reference-architecture-gallery) de référence. Utilisez la possibilité d'ajuster la taille et la couleur de vos cartes si nécessaire pour différencier les types et créer des diagrammes clairs et compréhensibles. ## **Containers** Les cartes peuvent également agir en tant que conteneurs, c'est-à-dire des regroupements pour plusieurs propriétés. Vous pouvez imbriquer des cartes dans une autre carte pour représenter les relations hiérarchiques ou classer les propriétés associées si nécessaire. Conteneurs ## **Icônes** Les diagrammes Salesforce fournissent une série de logos de produit Salesforce de base ainsi que des icônes supplémentaires pour représenter les propriétés et d'autres zones de votre diagramme. Icônes Vous trouverez des exemples d'utilisation d'icônes dans la [galerie Architecture de référence](https://architect.salesforce.com/diagrams#reference-architecture-gallery) _Pour d'autres icônes, voir les [icônes Lightning Design System.](https://www.lightningdesignsystem.com/icons/)_ ## Connecteurs Les connecteurs doivent toujours utiliser des lignes de connexion coudées et être droits dans la mesure du possible pour plus de lisibilité. Connecteurs et pilules **Les connecteurs** représentent une étape de relation, d'intégration ou de processus entre deux cartes. Les styles de ligne indiquent un type de connexion différent et doivent être représentés dans votre clé de diagramme. Les points de terminaison indiquent la direction d'un connecteur d'intégration ou de processus. Les points de terminaison indiquent également la cardinalité et l'ordinalité dans un connecteur de relation. **Les pilules** sont utilisées pour fournir des détails sur les connexions. Consultez [Architecture de solution](/docs/architect/fr-fr/reference-diagrams/guide/section-solution-architecture) et diagrammes de [flux de processus](/docs/architect/fr-fr/reference-diagrams/guide/section-interaction-process-flow) d'interaction pour des exemples d'utilisation de pilules. ## Accessibilité Dans le monde, environ [1,3 milliard de](https://www.salesforce.com/company/legal/508_accessibility/#:~:text=Product%20Accessibility%20Status&text=Around%20the%20world%2C%20approximately%201.3,global%20economy%20that%20includes%20everyone.) personnes vivent avec une forme de handicap, soit 15 % de la population mondiale. L'accessibilité consiste à rendre votre diagramme compréhensible pour tous vos visualiseurs. Deux zones de focus particulières peuvent faciliter l'accès à vos diagrammes : l'optimisation pour les lecteurs d'écran et l'utilisation appropriée du contraste des couleurs. Vous trouverez plus de ressources sur la conception pour l'accessibilité dans le [blog Salesforce Design](https://medium.com/salesforce-ux/tagged/accessibility). **Lecteurs d'écran** Un lecteur d'écran est une application logicielle qui lit à haute voix les termes d'un fichier, d'une application ou d'un site Web. Un lecteur d'écran peut lire les diagrammes pour les personnes qui ne peuvent pas les voir clairement. Le meilleur format pour la compatibilité du lecteur d'écran est PDF (Portable Document Format). Contrairement aux images et aux applications non accessibles, les fichiers PDF sont accessibles par les lecteurs d'écran pour lire les mots, les formes et les couleurs. L'exportation de vos diagrammes au format PDF lors du partage avec d'autres utilisateurs peut améliorer l'accessibilité. **Contraste de couleur** Augmenter le contraste de couleur est une autre façon d'aider votre diagramme à être plus accessible. Les personnes seront plus en mesure de reconnaître et de lire vos diagrammes lorsqu'ils respectent les [Web Content Accessibility Guidelines (WCAG) minimum de contraste](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html) de couleur d'avoir un ratio de 4,5:1 entre la couleur d'arrière-plan derrière le texte et la couleur du texte lui-même. Exemple de palette de couleurs pour afficher le contraste suggéré Chaque couleur du [système Salesforce](https://medium.com/salesforce-ux/the-salesforce-color-system-c7c6b5b9c577) est associée à un chiffre, compris entre 0 et 100. Lorsque vous choisissez des couleurs pour vos diagrammes, assurez-vous que la couleur d'arrière-plan derrière le texte est supérieure ou inférieure d'au moins 50 points à la couleur du texte. Par exemple, si votre couleur d'arrière-plan est 80, la couleur du texte ne doit pas dépasser 30. Vous pouvez également utiliser la règle des 50 points si nécessaire pour les bordures et les contours. **Vous avez une entrée ou des questions sur les diagrammes Salesforce ?** S'il vous plaît faites-nous part de vos pensées [ici](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link). # Composants Web Lightning Opérations de données hors écran Composants Web Lightning hors opérations de données d'écran - Il s'agit d'un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre l'utilisation d'adaptateurs wire pour accéder aux données Salesforce afin de remplir dynamiquement les composants d'un formulaire, et permet aux développeurs de mettre à jour, de supprimer et de créer des enregistrements via des contrôleurs Apex. ## Description Voici un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre l'utilisation d'adaptateurs wire pour accéder aux données Salesforce afin de remplir dynamiquement les composants d'un formulaire, et permet aux développeurs de mettre à jour, de supprimer et de créer des enregistrements via des contrôleurs Apex. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/286abef0-8c38-4981-a7dc-71e3f92ca3de) - [Image](https://architect.salesforce.com/ns-assets/legacy/off-screen-data-operations.png) # Contrôle de réclamation Contrôle de réclamation : indique qu'un événement est publié lors de la modification d'un enregistrement. Le corps du message de l'événement est stocké dans un magasin de données séparé, tandis que l'en-tête, qui contient un contrôle de réclamation, est transmis à un abonné. L'abonné utilise ensuite le contrôle de réclamation pour récupérer le corps du message lorsqu'il est prêt à traiter l'information si nécessaire. ## Description affiche un événement publié lors de la modification d'un enregistrement. Le corps du message de l'événement est stocké dans un magasin de données séparé, tandis que l'en-tête, qui contient un contrôle de réclamation, est transmis à un abonné. L'abonné utilise ensuite le contrôle de réclamation pour récupérer le corps du message lorsqu'il est prêt à traiter les informations si nécessaire. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0699a470-11ca-4291-88d6-a6399142a1ca) - [Image](https://architect.salesforce.com/ns-assets/legacy/templateseventdrivenarchitecturediagrams-claimcheck.png) # Fanout fanout : montre un événement publié et écrit dans une file d'attente unique lorsqu'un enregistrement est modifié via une interaction utilisateur, un flux ou une tâche par lot. Le système abonné a plusieurs services qui reçoivent le même événement de la file d'attente des messages ## Description affiche un événement publié et écrit dans une file d'attente unique lorsqu'un enregistrement est modifié via une interaction utilisateur, un flux ou une tâche par lot. Le système abonné a plusieurs services qui reçoivent le même événement de la file d'attente des messages ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/80ce7121-e2a0-4c86-92a1-15140d388030/edit?invitationId=inv_8da9e008-0615-4dec-a066-94789bd46ffd&page=t6tmerEcqDBv#) - [Image](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-fanout.png) # Feuille de route des capacités Capability roadmap (feuille de route des capacités) : une feuille de route visuelle qui rationalise la planification et la budgétisation des ressources en regroupant les capacités et en identifiant l'ordre d'implémentation, les dépendances et la valeur. ## Description Une feuille de route visuelle qui rationalise la planification et la budgétisation des ressources en regroupant les capacités et en identifiant l'ordre d'implémentation, les dépendances et la valeur. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/12103374-8b95-49bb-b7ad-b0f8154ccec6) - [Image](https://architect.salesforce.com/ns-assets/roadmap-business-capability.png) # Feuille de route des composants feuille de route des composants : une feuille de route visuelle qui optimise la planification des ressources et la budgétisation en identifiant les fonctionnalités du système, les fonctionnalités pertinentes, l'ordre d'implémentation, les délais et les dépendances des parties prenantes. ## Description Une feuille de route visuelle qui optimise la planification des ressources et la budgétisation en identifiant les fonctionnalités système, les fonctionnalités pertinentes, l'ordre d'implémentation, les délais et les dépendances des parties prenantes. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/2ca75fbd-af2e-45fd-a636-01255f1fb0cf) - [Image](https://architect.salesforce.com/ns-assets/roadmap-technology-component.png) # Feuille de route des fonctionnalités Fiche de route des fonctionnalités : une feuille de route visuelle qui améliore la collaboration entre les équipes commerciales et techniques en identifiant l'ordre d'implémentation des fonctionnalités, les dépendances et les fonctionnalités supplémentaires à des fins de planification. ## Description Une feuille de route visuelle qui améliore la collaboration entre les équipes commerciales et techniques en identifiant l'ordre d'implémentation des fonctionnalités, les dépendances et les fonctionnalités supplémentaires à des fins de planification. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/8e43258e-b21b-4525-87bf-8e5ba96f4032) - [Image](https://architect.salesforce.com/ns-assets/roadmap-business-feature.png) # Feuille de route système Système de feuille de route : diagramme de feuille de route qui simplifie la planification des ressources et la budgétisation. ## Description Un diagramme de feuille de route qui simplifie la planification des ressources et la budgétisation en identifiant l'ordre d'implémentation du système, les dépendances, les zones fonctionnelles et les fonctionnalités pertinentes pour les parties prenantes. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/ead3af9a-ddc2-492a-a8c9-7ab3943fabd7) - [Image](https://architect.salesforce.com/ns-assets/roadmap-technology-system.png) # Flux de personnalisation des clients Flux de personnalisation client : affiche les interactions temporelles impliquées dans le flux d'informations de bout en bout, depuis les interactions des clients sur le site Experience Cloud jusqu'à l'automatisation back-end dans Marketing Cloud et Slack. MuleSoft orchestre les intégrations à des systèmes back-end, Slack connecte tous les membres de l'équipe et Marketing Cloud boucle la boucle avec le parcours client. ## Description affiche les interactions temporelles impliquées dans le flux d'informations de bout en bout, depuis les interactions des clients sur le site Experience Cloud jusqu'à l'automatisation back-end dans Marketing Cloud et Slack. MuleSoft orchestre les intégrations à des systèmes back-end, Slack connecte tous les membres de l'équipe et Marketing Cloud boucle la boucle avec le parcours client. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/b13e3166-d3a1-4621-b275-242638f3f9af) - [Image](https://architect.salesforce.com/ns-assets/legacy/customerpersonalizationflow.png) # Flux de processus d'interaction Les diagrammes de flux de processus d'interaction illustrent la séquence des interactions, des flux de données et des étapes de processus entre les composants système, les services et les utilisateurs. Ces diagrammes aident les architectes et les développeurs à comprendre comment les différentes parties d'un système communiquent, comment les événements se propagent à travers l'architecture et comment les processus asynchrones et synchrones sont orchestrés. Ils fournissent une documentation essentielle pour comprendre le comportement du système, identifier les blocages et optimiser les flux de processus. Cette section contient 16 diagrammes de référence associés au flux de processus d'interaction : | Nom du diagramme | Description | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Intégrations externes à Apis avec des schémas Openapi](/docs/architect/fr-fr/reference-diagrams/guide/external-integrations-to-apis-with-openapi-schemas) | Exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre des intégrations externes utilisant des API avec des schémas OpenAPI. | | [Intégrations externes via Http](/docs/architect/fr-fr/reference-diagrams/guide/external-integrations-via-http) | Exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre les intégrations externes utilisant des protocoles HTTP. | | [Intégrations externes via des robots MuleSoft Apis et Rpa](/docs/architect/fr-fr/reference-diagrams/guide/external-integrations-via-mulesoft-apis-and-rpa-bots) | Exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre des intégrations externes utilisant des API MuleSoft et des robots RPA. | | [Lightning sur des sites externes](/docs/architect/fr-fr/reference-diagrams/guide/lightning-out-on-external-sites) | Exemple d'architecture de solution du guide de décision Building Forms montrant comment les composants LWC peuvent être incorporés à des sites externes. | | [Interaction des composants Web Lightning via des adaptateurs Wire](/docs/architect/fr-fr/reference-diagrams/guide/lightning-web-components-interaction-via-wire-adapters) | Exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre comment les composants Web Lightning interagissent en utilisant des adaptateurs wire. | | [Composants Web Lightning Opérations de données hors écran](/docs/architect/fr-fr/reference-diagrams/guide/lightning-web-components-off-screen-data-operations) | Exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre les opérations de données hors écran pour les composants Web Lightning. | | [Surveillance Apex asynchrone via une requête personnalisée](/docs/architect/fr-fr/reference-diagrams/guide/asynchronous-apex-monitoring-via-custom-query) | Affiche les composants impliqués dans le suivi du statut des processus asynchrones et l'affichage des résultats des tâches par lot et des tâches planifiées. | | [Traitement asynchrone via des événements de plate-forme](/docs/architect/fr-fr/reference-diagrams/guide/asynchronous-processing-via-platform-events) | Montre le fonctionnement du traitement asynchrone avec les événements de plate-forme. Les événements publiés dans le bus sont consommés par les abonnés pour traitement. | | [Algorithme d'utilisation équitable Apex par lot](/docs/architect/fr-fr/reference-diagrams/guide/batch-apex-fair-usage-algorithm) | Montre comment l'algorithme d'utilisation équitable garantit que chaque organisation sur Salesforce Platform reçoit une « part équitable » des ressources de traitement par lot. | | [Mise en file d'attente du message Apex par lot](/docs/architect/fr-fr/reference-diagrams/guide/batch-apex-message-re-enqueueing) | Montre comment le mécanisme de contrôle de flux de Salesforce Platform empêche une organisation d'inonder la file d'attente par lot en mettant les messages en file d'attente lorsque les limites sont dépassées. | | [Boxcarring dans JavaScript Remoting](/docs/architect/fr-fr/reference-diagrams/guide/boxcarring-in-javascript-remoting) | Montre comment plusieurs requêtes distantes JavaScript peuvent être émises en même temps, ou « boxcar » dans une seule requête XHR pour améliorer les performances. | | [Boxcarring dans Lightning Actions](/docs/architect/fr-fr/reference-diagrams/guide/boxcarring-in-lightning-actions) | Montre comment plusieurs actions Lightning peuvent être émises en même temps, ou "boxcar'ed" dans une seule requête XHR pour optimiser les appels réseau. | | [Contrôle de réclamation](/docs/architect/fr-fr/reference-diagrams/guide/claim-check) | Affiche un événement publié lors de la modification d'un enregistrement. Le corps du message de l'événement est stocké dans une base de données et seule une référence est transmise via le bus de message. | | [Flux de personnalisation client](/docs/architect/fr-fr/reference-diagrams/guide/customer-personalization-flow) | Affiche les interactions temporelles impliquées dans le flux d'informations de bout en bout depuis les interactions des clients jusqu'aux systèmes de livraison en passant par les moteurs de personnalisation. | | [Fanout](/docs/architect/fr-fr/reference-diagrams/guide/fanout) | Affiche un événement publié et écrit dans une file d'attente unique lorsqu'un enregistrement est modifié via une interaction utilisateur, avec plusieurs abonnés qui traitent l'événement. | | [Middleware Pull via la notification d'événement de plate-forme](/docs/architect/fr-fr/reference-diagrams/guide/middleware-pull-via-platform-event-notification) | Montre comment utiliser des événements de plate-forme pour livrer des intégrations sortantes ou instruire un outil middleware pour extraire des données de Salesforce. | | [Tirage planifié middleware](/docs/architect/fr-fr/reference-diagrams/guide/middleware-scheduled-pull) | Montre comment Middleware peut envoyer des requêtes synchrones à l'API SOAP ou à l'API REST afin de limiter les délais associés au traitement en temps réel. | | [Messages transmis](/docs/architect/fr-fr/reference-diagrams/guide/passed-messages) | Affiche un exemple de flux de processus pour le modèle Messages transmis qui inclut un éditeur, un abonné et un message passant entre les composants. | | [Publier S'abonner](/docs/architect/fr-fr/reference-diagrams/guide/publish-subscribe) | Affiche le modèle Publier/S'abonner et inclut plusieurs éditeurs, plusieurs abonnés et plusieurs courtiers de messages. | | [Publier S'abonner Copie unique](/docs/architect/fr-fr/reference-diagrams/guide/publish-subscribe-unique-copy) | Affiche un événement publié lorsqu'un enregistrement est modifié via une interaction utilisateur, un flux ou une tâche par lot, chaque abonné recevant une copie unique de l'événement. | | [Streaming](/docs/architect/fr-fr/reference-diagrams/guide/streaming) | Affiche un flux d'événements en cours de publication. Les abonnés qui écoutent les flux reçoivent les événements en temps réel. | | [Mise en file](/docs/architect/fr-fr/reference-diagrams/guide/queuing) d'attente | Affiche un exemple de modèle File d'attente qui représente un événement publié et écrit dans une file d'attente, les abonnés traitant les événements dans l'ordre. | | [Intégrations OmniStudio](/docs/architect/fr-fr/reference-diagrams/guide/omnistudio-integrations) | Exemple d'architecture de solution du guide de décision Building Forms pour les modèles d'intégration OmniStudio et la manipulation des données. | # Hiérarchie des rôles Salesforce Hiérarchie des rôles Salesforce : un exemple de hiérarchie d'organisations, qui capture un sous-ensemble de rôles afin de clarifier la structure métier, les personnes et les autorisations pour un cas d'utilisation spécifique ## Description Diagramme représentant un exemple de hiérarchie d'organisations, capturant un sous-ensemble de rôles afin de clarifier la structure métier, les personnes et les autorisations pour un cas d'utilisation spécifique. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/4fe3cd5e-0ccf-4ffd-9f7c-a418ce615c67) - [Image](https://architect.salesforce.com/ns-assets/legacy/salesforcerolehierarchy1.png) # Intégrations externes à Apis avec les schémas Openapi Intégrations externes à apis avec des schémas openapi - Ceci est un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre une connexion à une source de données externe via un service externe et une API qui utilise le schéma OpenAPI. ## Description Voici un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre une connexion à une source de données externe via un service externe et une API qui utilise le schéma OpenAPI. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/eb980d4b-a51a-4489-b337-5ada5997fdfb) - [Image](https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrationsopenapi.png) # Intégrations externes via des robots MuleSoft Apis et Rpa Intégrations externes via des robots mulesoft apis et rpa : voici un exemple de diagramme d'architecture de solution du guide Building Forms Decision Guide qui montre les connexions à la fois à une API MuleSoft et à un robot RPA, via MuleSoft Services, qui génère un Service externe dans Salesforce. ## Description Voici un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre les connexions à une API MuleSoft et à un robot RPA, via MuleSoft Services, qui génère un service externe dans Salesforce. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/3f05f273-5828-472f-bb35-cadeae52d4a7) - [Image](https://architect.salesforce.com/ns-assets/legacy/integrations-mulesoft.png) # Intégrations externes via Http Intégrations externes via http : cet exemple de diagramme d'architecture de solution du guide de décision Building Forms montre une connexion à une source de données externe via un appel externe HTTP dans Flux et une action HTTP dans OmniStudio. ## Description Voici un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre une connexion à une source de données externe via un appel externe HTTP dans Flux et une action HTTP dans OmniStudio. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/161cc130-341d-4c6d-84dc-00ca6aa00462) - [Image](https://architect.salesforce.com/ns-assets/legacy/integrations-callouts.png) # Intégrations Omnistudio Intégrations OmniStudio : il s'agit d'un exemple d'architecture de solution du guide de décision Building Forms pour OmniStudio qui manipule le JSON sous-jacent. Il est ensuite mappé avec des objets Salesforce ou des données externes en utilisant des outils tels que DataRaptor et des procédures d'intégration. Les procédures DataRaptor et d'intégration sont deux composants clés pour connecter vos formulaires OmniStudio à des données internes et externes à Salesforce. ## Description Il s'agit d'un exemple d'architecture de solution du guide de décision Building Forms pour OmniStudio qui manipule le JSON sous-jacent, qui est ensuite mappé avec des objets Salesforce ou des données externes en utilisant des outils tels que DataRaptor et des procédures d'intégration. DataRaptor et les procédures d'intégration sont deux composants clés pour connecter vos formulaires OmniStudio à des données internes et externes à Salesforce. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/cb0eb20b-da86-4dac-a3fc-bff5ac387165) - [Image](https://architect.salesforce.com/ns-assets/legacy/object-impact.png) # Interaction des composants Web Lightning via des adaptateurs Wire Interaction des composants Web Lightning via des adaptateurs wire - Il s'agit d'un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre comment LWC offre des interactions enrichies avec des enregistrements uniques et des objets associés grâce à l'utilisation d'adaptateurs wire qui interagissent avec l'API Interface utilisateur. En arrière-plan, Salesforce fait le gros du travail en vérifiant les paramètres de sécurité au niveau du champ, les autorisations et les paramètres de partage. Il récupère également les métadonnées des objets et les informations sur le thème et la présentation. ## Description Voici un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre comment LWC offre des interactions enrichies avec des enregistrements uniques et des objets associés en utilisant des adaptateurs wire qui interagissent avec l'API Interface utilisateur. En arrière-plan, Salesforce effectue le gros du travail en vérifiant les paramètres de sécurité au niveau du champ, les autorisations et les paramètres de partage. Il récupère également les métadonnées d'objet et les informations sur le thème et la présentation. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/9f72aafa-6293-4954-b090-3418e27b19da) - [Image](https://architect.salesforce.com/ns-assets/legacy/controller.png) # Lightning sur les sites externes Lightning out sur des sites externes - Ceci est un exemple d'architecture de solution du guide de décision Building Forms montrant comment les composants LWC peuvent être incorporés à l'intérieur d'un site Web externe via Lightning Out. Pour configurer une application Lightning Out, incluez la bibliothèque JavaScript Lightning Out dans la page sur le serveur d'origine. Ajoutez ensuite un balisage qui charge votre application Lightning Out et ses composants. Votre application Lightning Out initialise sur une connexion sécurisée et est insérée dans le DOM de la page. ## Description Il s'agit d'un exemple d'architecture de solution du guide de décision Building Forms montrant comment les composants LWC peuvent être incorporés à l'intérieur d'un site Web externe via Lightning Out. Pour configurer une application Lightning Out, insérez la bibliothèque JavaScript Lightning Out dans la page du serveur d'origine. Ajoutez ensuite un balisage qui charge votre application Lightning Out et ses composants. Votre application Lightning Out s'initialise sur une connexion sécurisée et est insérée dans le DOM de la page. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/ecd1a401-ee27-4f75-86f5-d5a1cabb1a4d) - [Image](https://architect.salesforce.com/ns-assets/legacy/location.png) # Message Apex par lot Re mise en file d'attente Mise en file d'attente de messages Apex par lot - montre comment le mécanisme de contrôle de flux de Salesforce Platform empêche une organisation d'inonder le type de message Apex par lot. Avant d'ajouter de nouvelles entrées à la file d'attente Apex par lot, l'infrastructure voit que toutes les entrées existantes sont associées à l'organisation 1, qui contient également des entrées dans des threads de travailleurs (organisation 1). Elle déplace ensuite les entrées de l'organisation 1 vers le fond de la file d'attente et priorise les entrées du formulaire Org 2. ## Description montre comment le mécanisme Contrôle de flux de Salesforce Platform empêche une organisation d'inonder le type de message Apex par lot. Avant d'ajouter de nouvelles entrées à la file d'attente Apex par lot, l'infrastructure voit que toutes les entrées existantes sont associées à l'organisation 1, qui contient également des entrées dans les threads worker (organisation 1). Il déplace ensuite les entrées depuis l'organisation 1 vers le fond de la file d'attente et priorise les entrées de l'organisation 2. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/d23a6022-45df-4632-9d0d-f646dee6eaa0) - [Image](https://architect.salesforce.com/ns-assets/legacy/messagere-enqueueing.png) # Messages transmis Messages transmis : montre un exemple de flux de processus pour le modèle Messages transmis qui inclut un éditeur, un abonné et un événement. L'événement est divisé en plusieurs parties, chacune transformée individuellement, puis réassemblée avant d'être envoyée à l'abonné ## Description affiche un exemple de flux de processus pour le modèle Messages transmis qui inclut un éditeur, un abonné et un événement. L'événement est divisé en plusieurs parties, chacune transformée individuellement, puis remontée avant d'être envoyée à l'abonné ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/1216b5f7-a2f7-444c-a695-73422c43a87b) - [Image](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-passedmessages.png) # Middleware Pull via la notification d'événement de plate-forme middleware pull via une notification d'événement de plate-forme : montre comment utiliser des événements de plate-forme pour livrer des intégrations sortantes ou instruire un outil middleware pour extraire les informations requises via une API native et les livrer à leur destination finale. ## Description montre comment utiliser des événements de plate-forme pour livrer des intégrations sortantes ou instruire un outil middleware d'extraire les informations requises via une API native et de les livrer à leur destination finale. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/1eee6c2f-056c-4ba4-a1ad-e78099066d46) - [Image](https://architect.salesforce.com/ns-assets/legacy/pemiddlewarepull.png) # Mise en file d'attente queuing : montre un exemple de modèle Queuing qui représente un événement publié et écrit dans une file d'attente lorsqu'un enregistrement est modifié. Les abonnés reçoivent des copies de l'événement de leurs files d'attente associées et effectuent les mises à jour appropriées dans leurs propres enregistrements. ## Description affiche un exemple de modèle File d'attente qui représente un événement publié et écrit dans une file d'attente lorsqu'un enregistrement est modifié. Les abonnés reçoivent des copies de l'événement depuis leur file d'attente associée et effectuent les mises à jour appropriées dans leurs propres enregistrements. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0cef151e-5b48-4237-bbe4-a774eee152ab) - [Image](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-queuing.png) ## Introduction Ce document présente une vue d'ensemble de la notation et des conventions relatives aux diagrammes des relations des entités (ERD) Salesforce pour vous aider à interpréter clairement les modèles de données produits disponibles dans la [galerie de modèles](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html) de données. Un ERD, également appelé modèle de données, est une représentation graphique d'un système d'information. Il montre les relations entre les personnes, les objets, les lieux, les concepts et les événements de ce système. C'est un modèle logique qui transmet la structure fonctionnelle des données. Dans les ERD Salesforce, les entités sont généralement mappées avec un objet de la base de données Salesforce. ## Entités Une entité est une chose ou un objet important, réel ou conceptuel, sur lequel l'information doit être connue ou détenue. sample data model entity Les entités sont représentées dans les diagrammes sous forme de cases avec des coins arrondis. Chaque case d'entité fournit généralement deux étiquettes (le cas échéant) : - Le nom logique de l'entité (p. ex. « Entité Salesforce » dans l'exemple présenté ici). Cela peut correspondre à l'étiquette au singulier de l'objet Salesforce représenté, mais pas toujours. - Le nom d'API « physique » ou le nom du développeur de l'objet dans votre organisation Salesforce (p. ex. « _Nom d'API_ » dans l'exemple). Généralement, pour des objets de package géré, le nom d'API répertorié dans le diagramme n'inclut pas l'espace de noms du package géré (« vlocity_ins\** », par exemple), sauf si Salesforce ou Industry Cloud utilise plusieurs packages gérés. La fin du nom d'API des objets de package géré indique le type d'objet personnalisé utilisé : « \*\*c » pour les objets personnalisés habituels et les paramètres personnalisés, « \*\*mdt » pour les métadonnées personnalisées, « \*\*x » pour les objets externes. Les cases d'entité peuvent également répertorier un ou plusieurs attributs représentatifs des attributs de cette entité. Un attribut est précédé d'un caractère « # » ou « - ». - Un « # » indique un attribut qui fait partie de la clé unique logique de l'entité. Dans l'exemple de diagramme, « Attribut de clé utilisateur » est considéré comme la clé primaire utilisateur de l'entité. - Un « • » indique un attribut non clé. ### Mise en forme de l'entité Chaque diagramme de relation d'entité illustre le modèle de données Salesforce du point de vue d'un cloud spécifique tel que Sales Cloud, Service Cloud ou Marketing Cloud. La palette de couleurs du diagramme reflète le nuage en évidence. Tous les clouds Industry tels que Financial Service Cloud, Health Cloud et Media Cloud utilisent le même schéma de couleurs Industry. La couleur d'une entité donnée sur le diagramme a également une signification spécifique. La couleur du nuage de focus est indiquée en utilisant sa couleur de marque Salesforce, avec quelques exemples ci-dessous. sample data model clouds La section suivante examinera les différentes mises en forme d'entité en référence à l'exemple de légende Sales Cloud ci-dessous : sample data model entities legend ### Entité Cloud Une entité avec les couleurs du focus cloud représente un objet fourni avec la licence de ce cloud. ### Entité associée Une entité avec un remplissage blanc et une bordure noire représente un objet fourni avec une licence différente de celle de focus Cloud et qui n'est pas étendue par la licence focus Cloud. Les entités Compte et Contact affichées dans un ERD Sales ou Service Cloud, par exemple, sont affichées en blanc avec une bordure noire, car ces objets sont disponibles avec une licence de plate-forme. ### Entité associée étendue Une entité avec un remplissage gris clair et une bordure noire représente un objet fourni avec une licence différente de celle du focus Cloud, mais le focus Cloud étend cet objet. Par exemple, Commerce Cloud étend l'objet de base Product2 avec des champs supplémentaires. Les extensions comprennent des champs, des relations et des types d'enregistrement supplémentaires. ### Entité externe Les entités sans frontière sont virtuelles. Utilisées dans un diagramme, ces cases reconnaissent l'existence d'une entité dans le modèle logique du domaine, mais l'entité n'est pas implémentée en tant qu'objet physique dans Salesforce. Les données de cette entité devraient être accédées via des appels d'API externes ou Salesforce Connect dans la solution déployée. ### Entité Type d'enregistrement Les entités avec une bordure en tirets sont modélisées en tant que types d'enregistrement dans Salesforce. Dans l'exemple présenté ici, les sous-types Compte professionnel, Compte de facturation, Compte consommateur et Compte de service ont une bordure en tirets, car ils sont mappés avec les types d'enregistrement livrés avec le package géré Communications Cloud. sample data model record type notation ### Entité conceptuelle Les entités avec une bordure en pointillés sont virtuelles. Ni les types d'enregistrement ni un objet séparé ne sont utilisés pour différencier ces sous-types dans la solution Salesforce. Ces sous-types représentent logiquement un concept du domaine qui aide à illustrer la fonctionnalité du modèle de données. ### Entités Supertype et Sous-type Un sous-type d'entité est la définition d'un sous-ensemble de ses occurrences. Lorsqu'un ensemble de sous-types est ajouté dans une entité supertype, l'entité supertype représente les attributs et les relations communs, tandis que les entités sous-types affichent les attributs et les relations spécifiques au sous-type. Dans la notation du diagramme, les sous-types sont mutuellement exclusifs, ce qui signifie que tout enregistrement unique doit appartenir à un seul sous-type. sample subtype relationships Les sous-types peuvent avoir des sous-types imbriqués qui différencient davantage les occurrences. Les sous-types des diagrammes sont logiques, mais ils peuvent être mappés avec une représentation physique de l'une des trois façons suivantes. La solidité de la bordure de l'entité du sous-type définit comment le sous-type est implémenté dans le modèle de données Salesforce. sample supertype Les entités de sous-type avec une bordure continue ont un objet réel qui suit les occurrences de ce sous-type. Dans l'exemple présenté ici, le sous-type Utilisateur externe de Contact a une bordure solide, car les Contacts enregistrés en tant qu'Utilisateurs externes sont suivis avec un enregistrement dans l'objet Utilisateur. sample subtype contact object ## Relations Une relation est une association nommée et significative entre deux entités. sample relationships Les marques et le texte sur ou autour des lignes décrivent la cardinalité, le caractère facultatif et le sens de la relation. ### Cardinalité relationnelle sample relationships legend La cardinalité indique le nombre relatif d'occurrences de chaque côté de la relation. Dans la notation, les extrémités d'une ligne de relation indiquent la cardinalité de la relation à cette extrémité. Une patte d'oie à une extrémité indique que de nombreuses occurrences d'entité à cette extrémité peuvent être associées à chaque occurrence à l'extrémité opposée. L'absence de patte d'oie à une extrémité indique qu'au plus une occurrence d'entité à cette extrémité peut être associée à une occurrence donnée à l'autre extrémité. ### Relations parent-enfant Salesforce prend en charge deux types de [champ de relation](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/field_types.htm#i1435823) : les champs de référence et les champs parent-enfant (alias principal-détails). Les champs Parent-Enfant sont semblables à des références obligatoires, mais ils appliquent un couplage supplémentaire entre les entités associées. Les enregistrements du côté multiple de la relation sont supprimés en cascade lorsque l'enregistrement parent est supprimé. De plus, la visibilité des enregistrements de détail est contrôlée par la visibilité de l'enregistrement parent. Pour illustrer la différence entre une relation enfant-parent et une relation de référence, les DRE Salesforce empruntent la notation diamant à UML. Un diamant du côté singulier d'une relation signifie que l'entité de ce côté joue le rôle principal dans la relation. L'entité du côté multiple d'une telle relation est le détail ou l'entité enfant et peut être considérée comme contenue dans l'entité parente. ### Facultatif des relations L'option indique si la relation est requise ou non pour une occurrence à chaque extrémité. En tant que concept, l'optionnalité est étroitement liée à la cardinalité et la notation reflète cette proximité. L'option est indiquée à chaque extrémité d'une relation par un cercle ou une barre en travers de la ligne à l'autre extrémité de la relation. Pourquoi à l'autre bout de la relation ? Pour inclure la marge d'optionnalité du même côté de la ligne que la cardinalité. Du côté multiple (c’est-à-dire patte d’oie) de la relation, il y a presque toujours un cercle sur la ligne. Cela signifie qu'il peut y avoir de zéro à plusieurs occurrences du côté multiple de la relation pour chaque occurrence du côté singulier de la relation. Du côté singulier de la relation, un cercle et une barre indiquent une relation facultative pour l'entité située du côté patte d'oie de la relation. Le cercle et la barre signifient qu'il peut y avoir zéro ou une occurrence du côté singulier de la relation pour chaque occurrence du côté multiple. Alternativement, du côté singulier de la relation, les barres doubles indiquent une relation requise pour l'entité du côté multiple de la relation. Les barres doubles signifient qu'il doit y avoir une et une seule occurrence du côté singulier de la relation pour chaque occurrence du côté multiple. Le caractère facultatif d'une relation peut être indiqué comme obligatoire, même si la relation physique sous-jacente dans Salesforce est facultative. Par exemple, le champ AccountId dans Contact est physiquement une relation facultative, mais si vous ignorez Contacts privés, la relation directe d'un Contact à un Compte est logiquement requise. L'indicateur d'optionnalité est utilisé avec précaution. Dans la plupart des cas, le caractère facultatif indiqué dans la DRE reflète le caractère facultatif sous-jacent de la relation. ### Sens des relations sample relationships meaning Au-delà de la cardinalité et de l'optionnalité, chaque relation entre deux entités exprime une signification particulière qui distingue cette relation des autres relations entre les deux mêmes entités. Les noms de fin de relation, tels que « partie de » et « composée de » dans le diagramme ci-dessus, définissent la nature de la relation. sample relationships meaning Lorsque vous combinez la cardinalité, l'optionnalité et les noms de fin d'une relation, ils peuvent être utilisés pour former une phrase qui décrit la relation. De gauche à droite : Chaque (peut/doit) être (un et un seul / un ou plusieurs) . De droite à gauche : Chaque (peut/doit) être (un et un seul / un ou plusieurs) . Par exemple, sample relationships meaning De gauche à droite : « Chaque contact doit être principalement un contact pour un seul et unique compte. » De droite à gauche : « Chaque Compte peut être représenté principalement par un ou plusieurs Contacts. » ### Code couleur des relations Les lignes de relation ont un code couleur. Les relations ajoutées par le cloud en focus pour le diagramme sont dessinées dans une couleur. Les lignes noires représentent une relation fournie avec une licence différente de celle du focus Cloud. sample relationships color ### Relations récursives Les relations peuvent exister entre deux occurrences de la même entité. C'est ce qu'on appelle une relation récursive. Une ligne de relation courbe est utilisée pour indiquer des relations récursives. sample recursive relationships ### Relations mutuellement exclusives sample mutual exclusive relationships Généralement, les DRE Salesforce excluent la plupart des règles métiers pour se concentrer sur la structure du modèle de données, mais une relation mutuellement exclusive est une règle métier qui est informative pour la structure. Une relation mutuellement exclusive indique qu'une seule des relations incluses dans l'arc sera utilisée pour une occurrence donnée. Notez que deux, trois relations ou plus peuvent participer à la même relation mutuellement exclusive. Une phrase décrivant la relation mutuellement exclusive présentée ici pourrait être la suivante : « Chaque entité peut être une instance d'une et d'une seule Première autre entité ou d'une et d'une seule Deuxième autre entité. » sample mutual exclusive relationships Notez que dans les DRE Salesforce, une ligne de relation rompue qui passe par l'arc ne fait pas partie de la relation mutuellement exclusive. ## Conventions de présentation Les DRE produits Salesforce officiels respectent les conventions de présentation pour plus de lisibilité. Ces conventions de présentation comprennent les suivantes : - Les lignes de relation doivent toujours être droites. - Les lignes de relation doivent être tracées verticalement ou horizontalement. Dans de rares cas où cela n'est pas possible, utilisez une ligne droite sur une diagonale. - Afin de garder les lignes de relation droites, les cases d'entité peuvent être redimensionnées (plus hautes ou plus larges) pour fournir un point de destination aux relations entre les deux entités. Les entités les plus importantes (qui ont plus de relations atterrissant sur elles) sont affichées en plus grand sur le diagramme renforçant leur importance. - Tout au long d’une même DRE, les pattes d’oie sur les relations doivent être toujours à gauche et/ou en haut de la ligne de relation (présentation à l’envers) – ou toujours à droite et/ou en bas de la ligne de relation (présentation à droite et à l’envers). Cette convention apporte de la clarté, car elle aboutit à des entités similaires réunies dans la même zone du diagramme, ce qui est utile pour comprendre les entités. L'utilisation de la présentation à l'envers entraîne l'affichage de diagrammes à l'envers avec des entités enfants au-dessus ou à gauche des entités parentes. Cependant, cela garantit que les entités les plus spécifiques du diagramme se situent en haut à gauche du diagramme, ce qui rend les diagrammes plus distincts et reconnaissables. L'utilisation de la convention de présentation côté droit entraîne la présence des mêmes entités communes en haut à gauche de chaque diagramme, mais les entités enfants sont sous ou à droite des entités parentes. En respectant étroitement ces conventions de présentation, vous obtenez un diagramme clair et facile à lire. Assurez-vous de consulter la [galerie de modèles](https://developer.salesforce.com/docs/platform/data-models/guide) de données Salesforce qui suit cette norme. # Paysage du système de détail Retail system landscape : paysage système montrant une solution B2C Commerce et Marketing, indiquant la combinaison de produits Salesforce et d'autres technologies impliquées dans l'implémentation. Il inclut des capacités telles que Marketing Automation, Gestion des interactions, Catalogue de produits et Segmentation. ## Description Un paysage système montrant une solution B2C Commerce et Marketing, indiquant la combinaison de produits Salesforce et d'autres technologies impliquées dans l'implémentation. Il inclut des capacités telles que l'automatisation du marketing, la gestion des interactions, le catalogue de produits et la segmentation. ## Liens téléchargeables : - [Image](https://architect.salesforce.com/ns-assets/legacy/retailsystemlandscapetemplate.png) # Paysage du système Marketing Customer 360 data 360 marketing - a example system landscape - a Customer 360 Architecture montrant comment différents composants d'une solution Salesforce intégrée communiquent entre eux en utilisant des connecteurs natifs ## Description Un paysage système pour une implémentation Customer 360. Il montre comment différents composants d'une solution Salesforce intégrée communiquent entre eux en utilisant des connecteurs natifs. Il inclut des capacités telles que l'entrée de données, la résolution de l'identité, la segmentation et l'activation. ## Liens téléchargeables : - [Image](https://architect.salesforce.com/ns-assets/legacy/data360marketing.png) # Paysage système Les diagrammes de paysage système offrent une vue complète de l'écosystème technologique d'une organisation, illustrant les relations entre les produits Salesforce, les systèmes externes et les points d'intégration. Ces représentations visuelles aident les architectes à comprendre la topologie complète du système, à identifier les dépendances et à planifier des implémentations stratégiques. Ils servent de documentation essentielle aux parties prenantes pour visualiser comment les différents composants interagissent au sein d'une architecture Customer 360 et soutenir les objectifs métiers. Cette section contient 5 diagrammes de référence associés au paysage système : | Nom du diagramme | Description | | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Customer 360 Marketing System Landscape](/docs/architect/fr-fr/reference-diagrams/guide/data-360-marketing) | Un paysage système pour une implémentation Customer 360 Architecture. | | [Agentforce System Landscape](/docs/architect/fr-fr/reference-diagrams/guide/einstein-system-landscape) | Un paysage système capturant la combinaison de produits Salesforce et d'autres systèmes technologiques disponibles avec Agentforce. | | [Retail System Landscape](/docs/architect/fr-fr/reference-diagrams/guide/retail-system-landscape) | Un paysage système montrant une solution B2C Commerce et Marketing, indiquant la combinaison de produits Salesforce et d'autres technologies impliquées dans l'implémentation. | | [Hiérarchie des rôles Salesforce](/docs/architect/fr-fr/reference-diagrams/guide/salesforce-role-hierarchy) | Exemple de hiérarchie d'organisations, capture d'un sous-ensemble de rôles afin de clarifier la structure métier, les relations du personnel et les modèles d'accès. | | [Architecture d'organisation unique](/docs/architect/fr-fr/reference-diagrams/guide/single-org-architecture) | Diagramme détaillant une stratégie d'organisation unique prenant en charge plusieurs unités commerciales. | # Paysage système Agentforce Agentforce system landscape - paysage système qui capture la combinaison de produits Salesforce et d'autres systèmes technologiques disponibles avec Agentforce. ## Description Un paysage système capturant la combinaison de produits Salesforce et d'autres systèmes technologiques disponibles avec Agentforce. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/28e332b9-b4d5-4780-8220-12e097f0dc58) - [Image](https://architect.salesforce.com/ns-assets/legacy/einsteingptsystemlandscape-einsteingptsystemlandscape.png) # Plan de publication Agentforce Plan de publication Agentforce - Diagramme détaillant les produits livrables pour une version initiale de projet d'IA générative. ## Description Un diagramme détaillant les livrables d'une version initiale du projet Agentforce. Il comprend des étapes telles que Définition du projet, Configurer et tester, Version pilote et Version bêta. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/241905d5-9a36-451d-952a-e43390349502) - [Image](https://architect.salesforce.com/ns-assets/legacy/releaseanddelivery.png) # Publier S'abonner publier abonner : affiche le modèle Publier / S'abonner et inclut plusieurs éditeurs, plusieurs abonnés et plusieurs événements livrés via des canaux dans un bus d'événement. Dans cet exemple, le même système peut être à la fois un éditeur et un abonné et un système peut s'abonner à plusieurs événements ## Description affiche le modèle Publier / S'abonner et inclut plusieurs éditeurs, plusieurs abonnés et plusieurs événements livrés via des canaux dans un bus d'événement. Dans cet exemple, un même système peut être à la fois éditeur et abonné, et un système peut s'abonner à plusieurs événements ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/f3ec8204-a571-456e-bb5f-e7018e8368ee) - [Image](https://architect.salesforce.com/ns-assets/legacy/publish_subscribe.png) # Publier S'abonner Copie unique publier abonner copie unique - montre un événement publié lorsqu'un enregistrement est modifié via une interaction utilisateur, un flux ou une tâche par lot. Les abonnés reçoivent leurs propres copies uniques des événements et effectuent les mises à jour appropriées sur leurs propres enregistrements. Dans ce schéma, le canal de messagerie est informé de tous les abonnés et crée des copies d'événement pour chacun d'eux, ce qui permet aux abonnés de relire les événements si nécessaire ## Description affiche un événement publié lorsqu'un enregistrement est modifié via une interaction utilisateur, un flux ou une tâche par lot. Les abonnés reçoivent leurs propres copies uniques des événements et effectuent les mises à jour appropriées dans leurs propres enregistrements. Dans ce schéma, le canal de messagerie connaît tous les abonnés et crée des copies d'événements pour chacun d'eux, ce qui permet aux abonnés de rejouer les événements si nécessaire. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/101c6c86-ab4c-406d-ac27-4e472fb33b5c) - [Image](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-publish-subscribel3.png) # Roadmap Les diagrammes de feuille de route aident les organisations à planifier et à visualiser l'implémentation stratégique des capacités, des composants, des fonctionnalités et des systèmes au fil du temps. Ces diagrammes permettent aux architectes et aux chefs de projet de rationaliser la planification des ressources, d'optimiser la budgétisation et d'améliorer la collaboration entre les équipes commerciales et techniques. Ils présentent une vue claire de l'ordre d'implémentation, des dépendances et des priorités, et aident les parties prenantes à comprendre l'approche progressive de livraison de solutions Salesforce complexes. Cette section contient 6 diagrammes de référence liés aux feuilles de route: | Nom du diagramme | Description | | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Feuille de route des capacités](/docs/architect/fr-fr/reference-diagrams/guide/capability-roadmap) | Une feuille de route visuelle qui rationalise la planification et la budgétisation des ressources en regroupant les capacités et en identifiant l'ordre d'implémentation, les dépendances et la valeur. | | [Feuille de route des composants](/docs/architect/fr-fr/reference-diagrams/guide/component-roadmap) | Une feuille de route visuelle qui optimise la planification des ressources et la budgétisation en identifiant les fonctionnalités système, les fonctionnalités pertinentes, l'ordre d'implémentation, les délais et les dépendances des parties prenantes. | | [Feuille de route de fonctionnalité](/docs/architect/fr-fr/reference-diagrams/guide/feature-roadmap) | Une feuille de route visuelle qui améliore la collaboration entre les équipes commerciales et techniques en identifiant l'ordre d'implémentation des fonctionnalités, les dépendances et les fonctionnalités supplémentaires à des fins de planification. | | [Agentforce Release Plan](/docs/architect/fr-fr/reference-diagrams/guide/generative-ai-release-plan) | Diagramme détaillant les livrables d’une version initiale de projet d’IA générative. | | [Agentforce Roadmap](/docs/architect/fr-fr/reference-diagrams/guide/generative-ai-roadmap) | Exemple de feuille de route montrant les composants de déploiement de l'IA à travers une implémentation Salesforce Customer 360. | | [Feuille de route système](/docs/architect/fr-fr/reference-diagrams/guide/system-roadmap) | Simplifiez la planification des ressources et la budgétisation en identifiant l'ordre d'implémentation du système, les dépendances et les priorités des fonctionnalités. | # Streaming streaming : affiche un flux d'événements en cours de publication. Les abonnés qui écoutent les flux les reçoivent et les traitent en conséquence. ## Description affiche un flux d'événements en cours de publication. Les abonnés qui écoutent les flux les reçoivent et les traitent en conséquence. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/13f15b6c-0b36-4048-b2ec-88e5137c6c0b) - [Image](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-streaming.png) # Surveillance Apex asynchrone via une requête personnalisée Surveillance Apex asynchrone via une requête personnalisée - affiche les composants impliqués dans le suivi du statut des processus asynchrones et l'affichage des résultats dans un outil de surveillance externe. ## Description affiche les composants impliqués dans le suivi du statut des processus asynchrones et l'affichage des résultats dans un outil de surveillance externe. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/0e147ab0-49e9-4875-b5c7-581e6db15cff) - [Image](https://architect.salesforce.com/ns-assets/legacy/asynchronousprocessingdecisionguide-customquery.png) # Tirage planifié Middleware intergiciel extraction planifiée - montre comment Middleware peut effectuer des requêtes synchrones à l'API SOAP ou l'API REST afin de minimiser les délais associés aux tâches d'intégration sortantes à haut volume. Les données sont extraites de la plate-forme Salesforce sur une base planifiée, au lieu de la plate-forme push les données via Apex asynchrone. ## Description montre comment Middleware peut envoyer des requêtes synchrones à l'API SOAP ou à l'API REST afin de limiter les délais associés aux tâches d'intégration sortantes à haut volume. Les données sont extraites de Salesforce Platform sur une base planifiée, au lieu que la plate-forme envoie automatiquement les données via Apex asynchrone. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/b1c1dd9f-114f-4827-a238-960d840bbc1a) - [Image](https://architect.salesforce.com/ns-assets/legacy/middlewarescheduledpull.png) # Traitement asynchrone via des événements de plate-forme Traitement asynchrone via des événements de plate-forme : montre le fonctionnement du traitement asynchrone avec des événements de plate-forme. Les événements publiés dans le bus sont livrés dans l'ordre via publish after commit, puis traités en masse par un flux dans un contexte synchrone séparé. ## Description montre le fonctionnement du traitement asynchrone avec les événements de plate-forme. Les événements publiés dans le bus sont livrés dans l'ordre via Publier après l'engagement, puis traités en masse par un flux dans un contexte synchrone séparé. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/73e12d46-2c45-4d7c-bcf4-a2ca7596ed4c) - [Image](https://architect.salesforce.com/ns-assets/legacy/platformevents.png)