# architect Referenzdiagramme (reference-diagrams) - Full Documentation # Abonnieren veröffentlichen Abonnement veröffentlichen: Zeigt das Muster "Veröffentlichen/Abonnieren" an und beinhaltet mehrere Publisher, mehrere Abonnenten und mehrere Ereignisse, die über Kanäle in einem Ereignis-Bus bereitgestellt werden. In diesem Beispiel kann dasselbe System sowohl ein Publisher als auch ein Abonnent sein und ein System kann mehrere Ereignisse abonnieren. ## Beschreibung zeigt das Muster "Veröffentlichen/Abonnieren" an und enthält mehrere Publisher, mehrere Abonnenten und mehrere Ereignisse, die über Kanäle in einem Ereignis-Bus zugestellt werden. In diesem Beispiel kann dasselbe System sowohl Publisher als auch Abonnent sein und ein System kann mehrere Ereignisse abonnieren. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/f3ec8204-a571-456e-bb5f-e7018e8368ee) - [Bild](https://architect.salesforce.com/ns-assets/legacy/publish_subscribe.png) # Agentforce Roadmap Agentforce-Roadmap – eine Beispiel-Roadmap mit Komponenten für die Einführung von AI in einer Salesforce Customer 360-Implementierung ## Beschreibung Eine Roadmap mit den Phasen für die Einführung von Agentforce-Funktionen in einer Salesforce Customer 360-Implementierung. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/1d9723f0-0835-4dc2-9cbb-01b2e97c91e8) - [Bild](https://architect.salesforce.com/ns-assets/legacy/generativeairollout.png) # Agentforce Systemlandschaft Agentforce Systemlandschaft: Eine Systemlandschaft, die die Kombination aus Salesforce-Produkten und anderen mit Agentforce verfügbaren Technologiesystemen erfasst. ## Beschreibung Eine Systemlandschaft, die die Kombination aus Salesforce-Produkten und anderen mit Agentforce verfügbaren Technologiesystemen erfasst. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/28e332b9-b4d5-4780-8220-12e097f0dc58) - [Bild](https://architect.salesforce.com/ns-assets/legacy/einsteingptsystemlandscape-einsteingptsystemlandscape.png) # Agentforce-Versionsplan Agentforce Release Plan (Agentforce-Veröffentlichungsplan): Ein Diagramm, in dem die Ergebnisse für eine erste Veröffentlichung eines Projekts mit generativer AI angegeben sind. ## Beschreibung Ein Diagramm, in dem die Ergebnisse für eine anfängliche Agentforce-Projektversion aufgeführt sind. Sie umfasst Phasen wie Projektdefinition, Konfigurieren und Testen, Pilotversion und Beta-Version. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/241905d5-9a36-451d-952a-e43390349502) - [Bild](https://architect.salesforce.com/ns-assets/legacy/releaseanddelivery.png) # Algorithmus für die faire Batch-Apex-Nutzung Batch Apex Fair Use algorithm (Algorithmus für die faire Nutzung von Batch-Apex): Hiermit wird gezeigt, wie der Fair-Use-Algorithmus sicherstellt, dass jede Organisation auf der Salesforce Platform einen "angemessenen Anteil" an der Verarbeitungszeit für einen bestimmten Nachrichtentyp erhält. In diesem Beispiel dominiert Organisation 1 den Apex-Nachrichtentyp für Batches, während Organisation 2 Warteprozesse desselben Nachrichtentyps aufweist. ## Beschreibung zeigt, wie der Fair-Use-Algorithmus sicherstellt, dass jede Organisation auf der Salesforce Platform einen "gerechten Anteil" an der Verarbeitungszeit für einen bestimmten Nachrichtentyp erhält. In diesem Beispiel dominiert Organisation 1 den Nachrichtentyp "Batch Apex", während Organisation 2 Warteprozesse desselben Nachrichtentyps aufweist. Daher hat der Algorithmus die Anzahl der Threads reduziert, die für Organisation 1 verfügbar sind. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/d23a6022-45df-4632-9d0d-f646dee6eaa0) - [Bild](https://architect.salesforce.com/ns-assets/legacy/fairusage.png) # Anspruchsprüfung Anspruchsprüfung: Zeigt an, dass ein Ereignis veröffentlicht wird, wenn ein Datensatz geändert wird. Der Nachrichtentext des Ereignisses wird in einem separaten Datenspeicher gespeichert, während die Kopfzeile, die eine Anspruchsprüfung enthält, an einen Abonnenten weitergegeben wird. Der Abonnent verwendet dann die Anspruchsprüfung, um den Nachrichtentext abzurufen, wenn er bereit ist, die Informationen bei Bedarf zu verarbeiten. ## Beschreibung zeigt ein Ereignis an, das veröffentlicht wird, wenn ein Datensatz geändert wird. Der Nachrichtentext des Ereignisses wird in einem separaten Datenspeicher gespeichert, während die Kopfzeile, die eine Anspruchsprüfung enthält, an einen Abonnenten weitergegeben wird. Der Abonnent verwendet dann die Anspruchsprüfung, um den Nachrichtentext abzurufen, wenn er bereit ist, die Informationen bei Bedarf zu verarbeiten. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0699a470-11ca-4291-88d6-a6399142a1ca) - [Bild](https://architect.salesforce.com/ns-assets/legacy/templateseventdrivenarchitecturediagrams-claimcheck.png) # Architektur der Lösung für die Treueverwaltung Architektur der Treueverwaltungslösung: Ein Architekturdiagramm, das die Produkte und Funktionen darstellt, die direkt an einer Treueverwaltungslösung beteiligt sind. ## Beschreibung Ein Architekturdiagramm, das die Produkte und Funktionen darstellt, die direkt an einer Treueverwaltungslösung beteiligt sind. Dies umfasst Commerce, Vertrieb, Service und Analytics. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/217c76c7-b8c4-44ed-aade-a7ae3fb8df0a) - [Bild](https://architect.salesforce.com/ns-assets/legacy/loyalty-management-solution-architecture.png) # Architektur einer einzelnen Organisation Architektur einer einzelnen Organisation: Ein Diagramm mit einer einzelnen Organisationsstrategie, die globale Geschäftseinheiten unterstützt. ## Beschreibung Ein Diagramm mit einer einzelnen Organisationsstrategie, die mehrere Geschäftseinheiten unterstützt. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/92edbe8d-18b8-4998-a851-7d1e815ea7d5) - [Bild](https://architect.salesforce.com/ns-assets/legacy/singleorgarchitecture.png) # Asynchrone Apex-Überwachung über benutzerdefinierte Abfrage asynchrone Apex-Überwachung über eine benutzerdefinierte Abfrage: Zeigt die Komponenten an, die an der Verfolgung des Status asynchroner Prozesse und der Anzeige der Ergebnisse in einem externen Überwachungstool beteiligt sind. ## Beschreibung zeigt die Komponenten an, die an der Verfolgung des Status asynchroner Prozesse und der Anzeige der Ergebnisse in einem externen Überwachungstool beteiligt sind. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/0e147ab0-49e9-4875-b5c7-581e6db15cff) - [Bild](https://architect.salesforce.com/ns-assets/legacy/asynchronousprocessingdecisionguide-customquery.png) # Asynchrone Verarbeitung über Plattformereignisse Asynchrone Verarbeitung über Plattformereignisse: Zeigt, wie die asynchrone Verarbeitung mit Plattformereignissen funktioniert. Die im Bus veröffentlichten Ereignisse werden nach dem Commit in der Reihenfolge über die Veröffentlichung zugestellt und dann in einem separaten synchronen Kontext per Massenvorgang durch einen Flow verarbeitet. ## Beschreibung zeigt, wie die asynchrone Verarbeitung mit Plattformereignissen funktioniert. Die im Bus veröffentlichten Ereignisse werden nach dem Commit in der Reihenfolge über die Veröffentlichung zugestellt und dann von einem Flow in einem separaten synchronen Kontext per Massenvorgang verarbeitet. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/73e12d46-2c45-4d7c-bcf4-a2ca7596ed4c) - [Bild](https://architect.salesforce.com/ns-assets/legacy/platformevents.png) # Batch Apex Message Re Enqueueing Wiedereinreihen von Apex-Batch-Nachrichten: Hiermit wird gezeigt, wie der Flow-Steuerungsmechanismus der Salesforce Platform verhindert, dass eine Organisation den Apex-Batch-Nachrichtentyp überschwemmt. Bevor der Apex-Batch-Warteschlange neue Einträge hinzugefügt werden, stellt das Framework sicher, dass alle vorhandenen Einträge der Organisation 1 zugeordnet sind, die auch Einträge in Arbeitsthreads (Organisation 1) aufweist. Anschließend werden Einträge aus Organisation 1 in die Warteschlange verschoben und Einträge aus Organisation 2 werden priorisiert. ## Beschreibung zeigt, wie der Flow-Steuerungsmechanismus der Salesforce Platform verhindert, dass eine Organisation den Apex-Nachrichtentyp für Batches überschwemmt. Bevor Sie der Batch Apex Warteschlange neue Einträge hinzufügen, stellt das Framework sicher, dass alle vorhandenen Einträge mit Organisation 1 verknüpft sind, die auch Einträge in Arbeits-Threads (Organisation 1) aufweist. Anschließend werden Einträge aus Organisation 1 in die Warteschlange verschoben und Einträge aus Organisation 2 priorisiert. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/d23a6022-45df-4632-9d0d-f646dee6eaa0) - [Bild](https://architect.salesforce.com/ns-assets/legacy/messagere-enqueueing.png) # Boxcarring in Javascript Remoting boxcarring in der JavaScript-Remoting-Funktion: Zeigt an, wie mehrere JavaScript-Remoting-Anforderungen gleichzeitig ausgestellt oder in einer einzelnen HTTP-Anforderung an die Salesforce Core Platform "boxcar'ed" werden können. Auf der Plattform wird jeder der Boxcars (d. h. eine separate JavaScript-Remoting-Aktion) seriell und in einem separaten Apex synchronen Transaktionskontext verarbeitet. ## Beschreibung zeigt, wie mehrere JavaScript-Remote-Anforderungen gleichzeitig ausgestellt oder in einer einzelnen HTTP-Anforderung an die Salesforce Core Platform "boxcar'ed" werden können. Auf der Plattform wird jeder der Boxcars (d. h. eine separate JavaScript-Remote-Aktion) seriell und in einem separaten Apex synchronen Transaktionskontext verarbeitet. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/ef9e594d-58c5-4554-97c8-0147f2f14bc2) - [Bild](https://architect.salesforce.com/ns-assets/legacy/jsremotingboxcarring.png) # Boxcarring in Lightning Aktionen boxcarring in Lightning Actions: Zeigt an, wie mehrere Lightning Aktionen gleichzeitig ausgestellt oder in einer einzelnen XHR-Anforderung an die Salesforce Core Platform "boxcar'ed" werden können. Jeder der Boxcars in der XHR-Anforderung wird seriell und in einem separaten Transaktionskontext verarbeitet. ## Beschreibung zeigt, wie mehrere Lightning-Aktionen gleichzeitig ausgegeben oder in einer einzelnen XHR-Anforderung an die Salesforce Core Platform "boxcar'ed" werden können. Jeder Boxcar in der XHR-Anforderung wird seriell und in einem separaten Transaktionskontext verarbeitet. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/6f6709ed-d1e7-446a-8385-286c2771be85) - [Bild](https://architect.salesforce.com/ns-assets/legacy/lightningactionboxcarring.png) # Center of Excellence Center of Excellence (Center of Excellence): Ein Diagramm, das zeigt, wie ein Center of Excellence (Center of Excellence, CoE) leitende Beteiligte und die IT miteinander verbindet und wie die funktionalen und technischen Führungsfunktionen für ein Center of Excellence (Center of Excellence, CoE) von zentraler Bedeutung sind. ## Beschreibung Ein Diagramm, das zeigt, wie ein Exzellenzcenter Führungskräfte und IT verbindet. Es wird hervorgehoben, wie wichtig funktionale und technische Führungsfunktionen für eine Kontaktaufnahme sind. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/59956c3b-3c73-469b-87a4-44c6dad948e5) - [Bild](https://architect.salesforce.com/ns-assets/legacy/centerofexcellenceoperatingmodel.png) # Customer 360 Marketing Systemlandschaft Data 360 Marketing – eine Beispielsystemlandschaft – eine Customer 360 Architecture, die zeigt, wie verschiedene Komponenten in einer integrierten Salesforce-Lösung mithilfe nativer Konnektoren miteinander kommunizieren ## Beschreibung Eine Systemlandschaft für eine Customer 360 Implementierung. Sie zeigt, wie verschiedene Komponenten in einer integrierten Salesforce-Lösung mithilfe von nativen Konnektoren miteinander kommunizieren. Sie enthält Funktionen wie Dateneingang, Identitätsbestimmung, Segmentierung und Aktivierung. ## Herunterladbare Links: - [Bild](https://architect.salesforce.com/ns-assets/legacy/data360marketing.png) # Data 360-Batch-Aktivierung und ereignisgesteuerte Aktionsarchitektur Salesforce Data 360-Batchaktivierung und ereignisgesteuerte Aktionsarchitektur ## Beschreibung Ein Diagramm, das Salesforce Data 360 in einer durchgängigen Lösung für Marketingaktivierungen darstellt. Wandeln Sie Ihre Daten mit Salesforce Data 360 in sofortige Aktionen um. Durch die Nutzung vorkonfigurierter Konnektoren und der Zero-Copy-Interoperabilität von Data-Lake-Hausplattformen können Sie komplexe Datenbewegungen vermeiden und direkt zur Ausführung gelangen. Diese nahtlose Verbindung fungiert als dynamische Vereinigungs- und Aktivierungsebene auf allen Verbundplattformen und löst die Aktivierungen und intelligenten Echtzeitaktionen aus, die erforderlich sind, um ein vollständig agentisches Unternehmen zu werden. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/620837ec-bb08-4f1e-af26-1164fc5f789c) - [Bild](https://sf-archs.cdn.salesforce-experience.com/cms/delivery/media/MCJU43MZY5WRELXAAIBCYP5NIT6A?channelId=0apHs000000y0QG&oid=00DHs000003Wrxy) # Data 360-Übersicht über die technischen Funktionen Data 360 Technical Capability Map (Übersicht über die technischen Funktionen von Data 360): Eine Übersicht über die technischen Funktionen von Data 360 und den Produktmix, der sie unterstützt, einschließlich Funktionen wie Data Lakehouse, Big Data Processing, Datenkonnektoren, Transformationen, Modellen und Single Source of Truth. ## Beschreibung Eine Funktionskarte, die die technischen Funktionen von Data 360 und den Produktmix anzeigt, der sie unterstützt. Sie enthält Funktionen wie Data Lakehouse, Big Data Processing, Datenkonnektoren, Transformationen, Modelle und Single Source of Truth. ## Herunterladbare Links: - [Bild](https://architect.salesforce.com/ns-assets/legacy/data360technicalcapabilitymap.png) # Einzelhandelssystemlandschaft Einzelhandelssystemlandschaft: Eine Systemlandschaft mit einer B2C Commerce- und Marketing-Lösung, die den Mix aus Salesforce-Produkten und anderen an der Implementierung beteiligten Technologien angibt und Funktionen wie Marketingautomatisierung, Interaktionsverwaltung, Produktkatalog und Segmentierung enthält. ## Beschreibung Eine Systemlandschaft mit einer B2C Commerce- und Marketing-Lösung, die den Mix aus Salesforce-Produkten und anderen an der Implementierung beteiligten Technologien angibt. Sie enthält Funktionen wie Marketingautomatisierung, Interaktionsverwaltung, Produktkatalog und Segmentierung. ## Herunterladbare Links: - [Bild](https://architect.salesforce.com/ns-assets/legacy/retailsystemlandscapetemplate.png) ## Einführung Diagramme sind ein wesentliches Werkzeug und ein wichtiger Teil der architektonischen Arbeit. Sie ermöglichen es uns, viele verschiedene Ideen an viele verschiedene Arten von Beteiligten zu kommunizieren. Diagramme helfen Zustellungsteams, auf dem Laufenden zu bleiben, indem sie als zentrale Informationsquelle über die Realitäten von Implementierungen und Produkten dienen. Diagramme sind auch eine wichtige Möglichkeit, Geschäftsbeteiligten die Möglichkeit zu geben, die richtigen Kaufentscheidungen und Technologieentscheidungen zu treffen. **Diagramme sollten immer:** - Lesen Sie so genau wie möglich von links nach rechts und von oben nach unten - Übermitteln einer Nachricht mit einem angemessenen Umfang an Informationen für die Lesbarkeit - Verwenden von [Salesforce Diagrams-Standardkomponenten](/docs/architect/de-de/reference-diagrams/guide/kit-of-parts), einschließlich Karten und einer Kopfzeile, mit einer klaren Beschreibung des Inhalts, Umfangs und Zwecks des Diagramms ## Diagrammumfang Der Umfang eines Diagramms sollte sich nur auf die wichtigen Informationen beschränken, die für ein bestimmtes Thema übermittelt werden sollen. Alles, was nicht erforderlich ist, um die Nachricht zu erfassen, die Sie kommunizieren möchten, sollte ausgeschlossen werden. Mehrere Diagramme können (und sollten) erstellt werden, um unterschiedliche Konzepte zu erfassen, um den Fokus von Diagramminhalten klarer zu kommunizieren und einzugrenzen. - Definieren Sie die wichtigen Informationen/Nachrichten, die Sie Ihrer Zielgruppe übermitteln müssen. - Klassifizieren logischer Geltungsbereiche, um den Fokus auf die Informationen zum Erfassen der Nachricht zu legen - Identifizieren der am besten geeigneten Diagrammtypen, die als Vorlagen verwendet werden sollen ## Diagrammtypen Salesforce Diagrams hat die nützlichsten/beliebtesten Diagrammtypen definiert, damit Sie Vorlagen einfach verwenden und Diagrammkonventionen verstehen können. Unsere aktuellen Ressourcen sind klassifiziert als: ### Kapazitätszuordnungen - Erfassen des Immobilienmix und der relevanten, in einer Lösung enthaltenen Schlüsselfunktionen - Fokus auf Funktionalität, Geschäftstreiber und Werte ✨ Suchen nach Funktionskarten in der [Referenzarchitekturgalerie](/reference-diagrams/guide/section-capability-map) ### Systemlandschaften - Erfassen der an einer bestimmten Implementierung beteiligten Produkte und/oder technischen Systeme - Konzentrieren Sie sich auf die Eigenschaften, bestimmte Eigenschaftsaspekte und Verbindungen zwischen Eigenschaften Beispiele und Vorlagen für die Systemlandschaft finden Sie in der [Referenzarchitekturgalerie](/reference-diagrams/guide/section-system-landscape) ### Lösungsarchitekturen - Einschließen von Produkten oder Technologien mit Integration, Verhalten und/oder Funktionen - Konzentrieren Sie sich auf die detaillierten Verbindungen und/oder Kommunikationsaspekte zwischen Eigenschaften Beispiele und Vorlagen für die Lösungsarchitektur finden Sie in der [Referenzarchitekturgalerie](/reference-diagrams/guide/section-solution-architecture) ### Interaktion / Prozess / Flows - Erfassen von zeitbasierten Schritten, Datenflüssen oder Interaktionen, die zur Unterstützung eines Prozesses erforderlich sind - Konzentrieren Sie sich auf die Reihenfolge der Aspekte/Eigenschaften und klären Sie sie (mit sequenzierter Nummerierung) ✨ Beispiele und Vorlagen für Interaktions-, Prozess- und Flow-Diagramme in der [Referenzarchitekturgalerie](/reference-diagrams/guide/section-interaction-process-flow) ### Datenmodelle / ERDs - Erfassen von Einheiten (Objekten), Beziehungen und Konzepten für Metadatenimplementierungen ✨ Finden von Datenmodellbeispielen und -vorlagen in der [Datenmodellgalerie](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html) Beispiele für Diagrammtypen finden Sie in der [Referenzarchitekturgalerie](/diagrams) oder in unserer dedizierten [Datenmodellgalerie](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html). Verwenden Sie eine Vorlage, um schnell und einfach ein Diagramm für Ihren Anwendungsfall zu erstellen. ## Schritte zum Erstellen eines Diagramms: - Definieren Sie den **Umfang** der Nachricht, die Sie übermitteln möchten: - _Überlegen Sie, welche Eigenschaften/Aspekte Sie darstellen müssen, welche Informationen zum Erfassen der Nachricht erforderlich sind und was ausgeschlossen werden kann._ - Stellen Sie sicher, dass eine **Kopfzeile** mit einem klaren **Titel** und einer prägnanten, durchdachten **Beschreibung** vorhanden ist, die Zweck, Umfang und Botschaft Ihres Diagramms erfasst. Stellen Sie sicher, dass eine Kopfzeile mit einem klaren Titel und einer prägnanten, durchdachten Beschreibung vorhanden ist, die Zweck, Umfang und Botschaft Ihres Diagramms erfasst. - Verwenden von **Karten** zum Erfassen der Eigenschaften (Systeme, Konzepte, Einheiten usw.) - Erfassen von Eigenschaftendetails oder wichtigen Aspekten / Funktionen nach Bedarf in **Kartenattributen** Kartenattribute - Darstellen von Beziehungen nach Bedarf zu **Konnektoren** zwischen Ihren Karteneigenschaften Konnektoren - Integrieren von **Kartensymbolen**, wo nützlich, verfügbar und/oder angemessen Kartensymbole - Verwenden von **Fußzeilen** und **Fußzeilensymbolen** zum Erfassen anderer wichtiger Eigenschaftenaspekte Fußzeilensymbole Weitere Details und bewährte Vorgehensweisen finden Sie auf der [Seite "Standardkomponenten](/docs/architect/de-de/reference-diagrams/guide/kit-of-parts)". **Haben Sie Eingaben oder Fragen zu Salesforce Diagrams?** Bitte teilen Sie uns [hier](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link) Ihre Gedanken mit. # Externe Integrationen in Apis mit Openapi-Schemas Externe Integrationen in Apis mit Openapi-Schemas – Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das eine Verbindung mit einer externen Datenquelle über einen externen Service und eine API zeigt, die das OpenAPI-Schema verwendet. ## Beschreibung Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das eine Verbindung mit einer externen Datenquelle über einen externen Service und eine API zeigt, die das OpenAPI-Schema verwendet. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/eb980d4b-a51a-4489-b337-5ada5997fdfb) - [Bild](https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrationsopenapi.png) # Externe Integrationen über Http Externe Integrationen über http: Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das eine Verbindung mit einer externen Datenquelle über einen HTTP-Callout in Flow und eine HTTP-Aktion in OmniStudio anzeigt. ## Beschreibung Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das eine Verbindung mit einer externen Datenquelle über einen HTTP-Callout in Flow und eine HTTP-Aktion in OmniStudio anzeigt. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/161cc130-341d-4c6d-84dc-00ca6aa00462) - [Bild](https://architect.salesforce.com/ns-assets/legacy/integrations-callouts.png) # Externe Integrationen über MuleSoft-Apis und Rpa-Bots Externe Integrationen über MuleSoft-APIs und RPA-Bots: Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das Verbindungen zu einer MuleSoft-API und einem RPA-Bot über MuleSoft-Services anzeigt, die einen externen Service in Salesforce generieren. ## Beschreibung Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das Verbindungen zu einer MuleSoft-API und einem RPA-Bot über MuleSoft-Services anzeigt, die einen externen Service in Salesforce generieren. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/3f05f273-5828-472f-bb35-cadeae52d4a7) - [Bild](https://architect.salesforce.com/ns-assets/legacy/integrations-mulesoft.png) # Fanout Fanout: Zeigt an, dass ein Ereignis veröffentlicht und in eine einzelne Warteschlange geschrieben wird, wenn ein Datensatz über eine Benutzerinteraktion, einen Flow oder einen Batchauftrag geändert wird. Das Abonnentensystem verfügt über mehrere Services, die dasselbe Ereignis aus der Nachrichtenwarteschlange empfangen. ## Beschreibung zeigt ein Ereignis an, das veröffentlicht und in eine einzelne Warteschlange geschrieben wird, wenn ein Datensatz über eine Benutzerinteraktion, einen Flow oder einen Batchauftrag geändert wird. Das Teilnehmersystem verfügt über mehrere Services, die dasselbe Ereignis aus der Nachrichtenwarteschlange empfangen ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/80ce7121-e2a0-4c86-92a1-15140d388030/edit?invitationId=inv_8da9e008-0615-4dec-a066-94789bd46ffd&page=t6tmerEcqDBv#) - [Bild](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-fanout.png) # Funktions-Roadmap Feature-Roadmap: Eine visuelle Roadmap, die die Zusammenarbeit zwischen Geschäfts- und technischen Teams verbessert, indem die Reihenfolge der Funktionsimplementierung, Abhängigkeiten und zusätzliche Funktionen für Planungszwecke identifiziert werden. ## Beschreibung Eine visuelle Roadmap, die die Zusammenarbeit zwischen Geschäfts- und technischen Teams verbessert, indem die Reihenfolge der Funktionsimplementierung, Abhängigkeiten und zusätzliche Funktionen für Planungszwecke identifiziert werden. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/8e43258e-b21b-4525-87bf-8e5ba96f4032) - [Bild](https://architect.salesforce.com/ns-assets/roadmap-business-feature.png) # Geschäftsfähigkeitskarte Geschäftsfähigkeitskarte: Eine Vorlagenfunktionskarte zum Darstellen von Geschäftstreibern und Funktionen mit Produktpositionierung auf höchster Ebene. ## Beschreibung Eine Vorlagenfunktionskarte zum Darstellen von Geschäftstreibern und Funktionen mit Produktpositionierung auf hoher Ebene. ## Herunterladbare Links: - [Bild](https://architect.salesforce.com/ns-assets/reference-architectures/business-capability-map.webp) # Implementierungsarchitektur für Data 360 Customer Zero Data 360 Customer Zero-Implementierungsarchitektur ## Beschreibung Ein durchgängiges Diagramm, das Salesforce Data 360 darstellt, wie es in Salesforce als Customer Zero-Programm implementiert ist. Salesforce Data 360 fungiert als zentrale Ebene für Intelligenz und Governance und vereinheitlicht Unternehmensdaten durch Zero Copy-Verbund mit externen Systemen wie Snowflake und AWS, wobei Trust und Semantik gewahrt bleiben. Diese vereinheitlichte, AI-fähige Datengrundlage unterstützt die Agentforce 360-Aktivierung. Sie ermöglicht Agenten mit umfangreichen Argumenten, die CRM-Anreicherung und die Cloud-übergreifende Automatisierung mit sicheren, richtlinienbewussten Datenflüssen über alle Geschäftsfunktionen hinweg und verwandelt die Organisation letztlich in ein Unternehmen für Agenten. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/af215946-127b-4b47-95b9-a7c158be351b) - [Bild](https://architect.salesforce.com/ns-assets/data360_ref_arch/sfdc_customer_zero_implementation.png) # Interaktion mit Lightning-Webkomponenten über Wire-Adapter Interaktion mit Lightning-Webkomponenten über Wire-Adapter – Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Building Forms Decision Guide, das zeigt, wie LWC umfassende Interaktionen mit einzelnen Datensätzen und verwandten Objekten durch die Verwendung von Wire-Adaptern bietet, die mit der Benutzeroberflächen-API interagieren. Im Hintergrund übernimmt Salesforce die komplizierte Arbeit, indem Einstellungen für die Feldebenensicherheit, Berechtigungen und Freigabeeinstellungen überprüft werden. Außerdem werden Objektmetadaten sowie Themen- und Layoutinformationen abgerufen. ## Beschreibung Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das zeigt, wie LWC umfassende Interaktionen mit einzelnen Datensätzen und verwandten Objekten durch die Verwendung von Wire-Adaptern bietet, die mit der Benutzeroberflächen-API interagieren. Im Hintergrund übernimmt Salesforce die komplizierte Arbeit, indem es die Einstellungen für die Feldebenensicherheit, Berechtigungen und Freigabeeinstellungen überprüft. Außerdem werden Objektmetadaten sowie Themen- und Layoutinformationen abgerufen. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/9f72aafa-6293-4954-b090-3418e27b19da) - [Bild](https://architect.salesforce.com/ns-assets/legacy/controller.png) # Interaktionsprozess-Flow Flussdiagramme für Interaktionsprozesse veranschaulichen die Abfolge von Interaktionen, Datenflüssen und Prozessschritten zwischen Systemkomponenten, Services und Benutzern. Anhand dieser Diagramme können Architekten und Entwickler nachvollziehen, wie verschiedene Teile eines Systems kommunizieren, wie sich Ereignisse durch die Architektur ausbreiten und wie asynchrone und synchrone Prozesse orchestriert werden. Sie bieten eine wichtige Dokumentation zum Verständnis des Systemverhaltens, zum Identifizieren von Engpässen und zum Optimieren von Prozess-Flows. Dieser Abschnitt enthält 16 Referenzdiagramme zum Interaktionsprozess-Flow: | Diagrammname | Beschreibung | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Externe Integrationen in Apis mit Openapi-Schemas](/docs/architect/de-de/reference-diagrams/guide/external-integrations-to-apis-with-openapi-schemas) | Ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das externe Integrationen mit APIs mit OpenAPI-Schemas anzeigt. | | [Externe Integrationen über Http](/docs/architect/de-de/reference-diagrams/guide/external-integrations-via-http) | Ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das externe Integrationen mithilfe von HTTP-Protokollen anzeigt. | | [Externe Integrationen über MuleSoft-Apis- und Rpa-Bots](/docs/architect/de-de/reference-diagrams/guide/external-integrations-via-mulesoft-apis-and-rpa-bots) | Ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das externe Integrationen mit MuleSoft-APIs und RPA-Bots anzeigt. | | [Lightning auf externen Sites](/docs/architect/de-de/reference-diagrams/guide/lightning-out-on-external-sites) | Eine Beispiellösungsarchitektur aus dem Building Forms Decision Guide, die zeigt, wie LWC-Komponenten auf externen Sites eingebettet werden können. | | [Interaktion von Lightning-Webkomponenten über Wire-Adapter](/docs/architect/de-de/reference-diagrams/guide/lightning-web-components-interaction-via-wire-adapters) | Ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für Formulare, das zeigt, wie Lightning Web Components mithilfe von Wire-Adaptern interagieren. | | [Lightning Webkomponenten außerhalb von Bildschirmdatenvorgängen](/docs/architect/de-de/reference-diagrams/guide/lightning-web-components-off-screen-data-operations) | Ein Beispieldiagramm der Lösungsarchitektur aus dem Entscheidungsleitfaden für Formulare, das Datenvorgänge außerhalb des Bildschirms für Lightning Webkomponenten anzeigt. | | [Asynchrone Apex Überwachung über benutzerdefinierte Abfrage](/docs/architect/de-de/reference-diagrams/guide/asynchronous-apex-monitoring-via-custom-query) | Zeigt die Komponenten an, die an der Verfolgung des Status asynchroner Prozesse und der Anzeige der Ergebnisse von Batchaufträgen und geplanten Aufträgen beteiligt sind. | | [Asynchrone Verarbeitung über Plattformereignisse](/docs/architect/de-de/reference-diagrams/guide/asynchronous-processing-via-platform-events) | Zeigt, wie die asynchrone Verarbeitung mit Plattformereignissen funktioniert. Die im Bus veröffentlichten Ereignisse werden von Abonnenten zur Verarbeitung verwendet. | | [Batch-Algorithmus für faire Apex-Nutzung](/docs/architect/de-de/reference-diagrams/guide/batch-apex-fair-usage-algorithm) | Zeigt, wie der Algorithmus für die faire Nutzung sicherstellt, dass jede Organisation auf der Salesforce Platform einen "gerechten Anteil" an Batchverarbeitungsressourcen erhält. | | [Batch Apex Message Re Enqueueing](/docs/architect/de-de/reference-diagrams/guide/batch-apex-message-re-enqueueing) | Zeigt, wie der Flow-Steuerungsmechanismus der Salesforce Platform verhindert, dass eine Organisation die Batch-Warteschlange überflutet, indem Nachrichten bei Überschreitung der Obergrenzen erneut in die Warteschlange gestellt werden. | | [Boxcarring in der Javascript-Remoting](/docs/architect/de-de/reference-diagrams/guide/boxcarring-in-javascript-remoting) | Zeigt an, wie mehrere JavaScript-Remote-Anforderungen gleichzeitig ausgestellt oder in einer einzelnen XHR-Anforderung "boxcar'ed" werden können, um die Leistung zu verbessern. | | [Boxcarring in Lightning Aktionen](/docs/architect/de-de/reference-diagrams/guide/boxcarring-in-lightning-actions) | Zeigt an, wie mehrere Lightning-Aktionen gleichzeitig ausgegeben oder in einer einzelnen XHR-Anforderung "boxcar'ed" werden können, um Netzwerkaufrufe zu optimieren. | | [Anspruchsprüfung](/docs/architect/de-de/reference-diagrams/guide/claim-check) | Zeigt ein Ereignis an, das veröffentlicht wird, wenn ein Datensatz geändert wird. Der Nachrichtentext des Ereignisses wird in einer Datenbank gespeichert und nur ein Verweis wird über den Nachrichten-Bus weitergeleitet. | | [Kundenpersonalisierungs-Flow](/docs/architect/de-de/reference-diagrams/guide/customer-personalization-flow) | Zeigt zeitbasierte Interaktionen an, die am durchgängigen Informationsfluss von Kundeninteraktionen über Personalisierungsmodule bis hin zu Bereitstellungssystemen beteiligt sind. | | [Fanout](/docs/architect/de-de/reference-diagrams/guide/fanout) | Zeigt, dass ein Ereignis veröffentlicht und in eine einzelne Warteschlange geschrieben wird, wenn ein Datensatz über eine Benutzerinteraktion geändert wird, wobei mehrere Abonnenten das Ereignis verarbeiten. | | [Middleware-Abruf über Plattformereignisbenachrichtigung](/docs/architect/de-de/reference-diagrams/guide/middleware-pull-via-platform-event-notification) | Zeigt, wie Sie Plattformereignisse verwenden können, um ausgehende Integrationen bereitzustellen, oder um ein Middleware-Tool anzuweisen, Daten aus Salesforce abzurufen. | | [Geplanter Pull für Middleware](/docs/architect/de-de/reference-diagrams/guide/middleware-scheduled-pull) | Zeigt, wie Middleware synchrone Anforderungen an die SOAP-API oder die REST-API senden kann, um Verzögerungen bei der Echtzeitverarbeitung zu minimieren. | | [Übergebene Nachrichten](/docs/architect/de-de/reference-diagrams/guide/passed-messages) | Zeigt ein Beispiel eines Prozess-Flows für das Muster "Weitergegebene Nachrichten", der einen Publisher, einen Abonnenten und eine Nachricht enthält, die zwischen Komponenten weitergegeben wird. | | [Abonnieren veröffentlichen](/docs/architect/de-de/reference-diagrams/guide/publish-subscribe) | Zeigt das Muster "Veröffentlichen/Abonnieren" an und umfasst mehrere Herausgeber, mehrere Abonnenten und mehrere Nachrichtenvermittler. | | [Eindeutige Abonnementkopie veröffentlichen](/docs/architect/de-de/reference-diagrams/guide/publish-subscribe-unique-copy) | Zeigt ein Ereignis, das veröffentlicht wird, wenn ein Datensatz über eine Benutzerinteraktion, einen Flow oder einen Batchauftrag geändert wird, wobei jeder Abonnent eine eindeutige Kopie des Ereignisses erhält. | | [Streaming](/docs/architect/de-de/reference-diagrams/guide/streaming) | Zeigt einen Stream der zu veröffentlichenden Ereignisse an. Abonnenten, die die Streams abhören, erhalten die Ereignisse in Echtzeit. | | [Queuing](/docs/architect/de-de/reference-diagrams/guide/queuing) | Zeigt ein Beispiel für das Warteschlangenmuster an, das zeigt, dass ein Ereignis veröffentlicht und in eine Warteschlange geschrieben wird, wobei Abonnenten Ereignisse in der Reihenfolge verarbeiten. | | [OmniStudio-Integrationen](/docs/architect/de-de/reference-diagrams/guide/omnistudio-integrations) | Eine Beispiel-Lösungsarchitektur aus dem Entscheidungsleitfaden für Formulare für OmniStudio-Integrationsmuster und Datenmanipulationen. | # Kapazitätsfahrplan Fähigkeits-Roadmap: Eine visuelle Roadmap, die die Ressourcenplanung und Budgetierung optimiert, indem Funktionen gruppiert und die Implementierungsreihenfolge, Abhängigkeiten und Werte identifiziert werden. ## Beschreibung Eine visuelle Roadmap, die die Ressourcenplanung und Budgetierung optimiert, indem Funktionen gruppiert und die Implementierungsreihenfolge, Abhängigkeiten und Werte identifiziert werden. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/12103374-8b95-49bb-b7ad-b0f8154ccec6) - [Bild](https://architect.salesforce.com/ns-assets/roadmap-business-capability.png) # Kapazitätskarte Kapazitätskarten bieten eine visuelle Darstellung der geschäftlichen und technischen Funktionen und veranschaulichen, wie unterschiedliche Produkte und Services organisatorische Ziele unterstützen. Diese Diagramme helfen Architekten und Beteiligten, die Beziehung zwischen Geschäftsfaktoren, Funktionen und dem zugrunde liegenden Technologiestapel zu verstehen. Sie dienen als strategische Planungstools, die eine bessere Abstimmung zwischen Geschäftszielen und technischer Implementierung ermöglichen. Dieser Abschnitt enthält 4 Referenzdiagramme zu Fähigkeitskarten: | Diagrammname | Beschreibung | | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | [Geschäftsfähigkeitskarte](/docs/architect/de-de/reference-diagrams/guide/business-capability-map) | Eine Vorlagenfunktionskarte zum Darstellen von Geschäftstreibern und Funktionen mit Produktpositionierung auf hoher Ebene. | | [Technische Daten 360-Übersicht](/docs/architect/de-de/reference-diagrams/guide/data-360-technical-capability-map) | Eine Funktionskarte, die die technischen Funktionen von Data 360 und den Produktmix anzeigt, der sie unterstützt. | | [Funktionskarte der Treueverwaltung](/docs/architect/de-de/reference-diagrams/guide/loyalty-management-capability-map) | Eine Fähigkeitskarte, die Treueverwaltungsservices mit einer allgemeinen Produktpositionierung anzeigt. | | [Center of Excellence](/docs/architect/de-de/reference-diagrams/guide/center-of-excellence) | Ein Diagramm, in dem erläutert wird, wie ein Exzellenzcenter Führungskräfte und IT verbindet. | # Karte mit den Funktionen der Treueverwaltung Funktionskarte für die Treueverwaltung: Eine Funktionskarte, die Services für die Treueverwaltung mit Produktpositionierung auf höchster Ebene anzeigt und Funktionen wie Treueverwaltung, Verarbeitung und Analytics enthält. ## Beschreibung Eine Fähigkeitskarte, die Treueverwaltungsservices mit einer allgemeinen Produktpositionierung anzeigt. Sie enthält Funktionen wie Treueverwaltung, Verarbeitung und Analytics. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/d41ccba2-71ea-449a-8497-ea95396102b4) - [Bild](https://architect.salesforce.com/ns-assets/legacy/loyalty-management-capability-map.png) # Komponenten-Roadmap Komponenten-Roadmap: Eine visuelle Roadmap, die die Ressourcenplanung und Budgetierung optimiert, indem sie Systemfunktionen, relevante Funktionen, Implementierungsreihenfolge, Zeitrahmen und Abhängigkeiten von Beteiligten identifiziert. ## Beschreibung Eine visuelle Roadmap, die die Ressourcenplanung und Budgetierung optimiert, indem Systemfunktionen, relevante Funktionen, Implementierungsreihenfolge, Zeitrahmen und Abhängigkeiten von Beteiligten identifiziert werden. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/2ca75fbd-af2e-45fd-a636-01255f1fb0cf) - [Bild](https://architect.salesforce.com/ns-assets/roadmap-technology-component.png) # Kundenpersonalisierungs-Flow Kundenpersonalisierungs-Flow: Zeigt zeitbasierte Interaktionen an, die am durchgängigen Informationsfluss beteiligt sind – von Kundeninteraktionen auf der Experience Cloud-Site bis hin zur Back-End-Automatisierung in Marketing Cloud und Slack. MuleSoft orchestriert Integrationen in Back-End-Systeme, Slack verbindet alle Teammitglieder und Marketing Cloud schließt den Kreislauf mit der Kunden-Journey. ## Beschreibung zeigt zeitbasierte Interaktionen an, die am durchgängigen Informationsfluss beteiligt sind, von Kundeninteraktionen auf der Experience Cloud-Site bis hin zur Back-End-Automatisierung in Marketing Cloud und Slack. MuleSoft orchestriert Integrationen in Backend-Systeme, Slack verbindet alle Mitglieder des Teams und Marketing Cloud schließt die Kunden-Journey. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/b13e3166-d3a1-4621-b275-242638f3f9af) - [Bild](https://architect.salesforce.com/ns-assets/legacy/customerpersonalizationflow.png) # Lightning auf externen Sites Lightning out on external sites (Lightning auf externen Sites): Dies ist eine Beispiellösungsarchitektur aus dem Building Forms Decision Guide, die zeigt, wie LWC-Komponenten über Lightning Out in eine externe Website eingebettet werden können. Fügen Sie zum Konfigurieren einer Lightning Out-Anwendung die Lightning Out JavaScript-Bibliothek auf der Seite des Ursprungsservers hinzu. Fügen Sie dann Markup hinzu, das Ihre Lightning Out-Anwendung und ihre Komponenten lädt. Ihre Lightning Out-Anwendung wird über eine sichere Verbindung initialisiert und in das DOM der Seite eingefügt. ## Beschreibung Dies ist eine Beispiellösungsarchitektur aus dem Decision Guide für Formulare, die zeigt, wie LWC-Komponenten über Lightning Out in eine externe Website eingebettet werden können. Fügen Sie zum Konfigurieren einer Lightning Out-Anwendung die Lightning Out JavaScript-Bibliothek auf der Seite des Ursprungsservers hinzu. Fügen Sie dann Markup hinzu, mit dem Ihre Lightning Out-Anwendung und ihre Komponenten geladen werden. Ihre Lightning Out-Anwendung wird über eine sichere Verbindung initialisiert und in das DOM der Seite eingefügt. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/ecd1a401-ee27-4f75-86f5-d5a1cabb1a4d) - [Bild](https://architect.salesforce.com/ns-assets/legacy/location.png) # Lightning Webkomponenten außerhalb des Bildschirms Datenvorgänge Lightning Web Components off screen data operations (Lightning-Webkomponenten außerhalb von Bildschirmdatenvorgängen): Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Building Forms Decision Guide, das die Verwendung von Wire-Adaptern für den Zugriff auf Salesforce-Daten zum dynamischen Ausfüllen der Komponenten eines Formulars zeigt und es Entwicklern ermöglicht, Datensätze über Apex-Steuerfelder zu aktualisieren, zu löschen und zu erstellen. ## Beschreibung Dies ist ein Beispieldiagramm der Lösungsarchitektur aus dem Decision Guide für die Erstellung von Formularen, das die Verwendung von Wire-Adaptern für den dynamischen Zugriff auf Salesforce-Daten zum Ausfüllen der Komponenten eines Formulars zeigt und es Entwicklern ermöglicht, Datensätze über Apex-Steuerfelder zu aktualisieren, zu löschen und zu erstellen. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/286abef0-8c38-4981-a7dc-71e3f92ca3de) - [Bild](https://architect.salesforce.com/ns-assets/legacy/off-screen-data-operations.png) # Lösungsarchitektur Lösungsarchitekturdiagramme veranschaulichen das technische Design und die Implementierungsdetails bestimmter Lösungen und zeigen, wie Komponenten, Services und Integrationen zusammenwirken, um Geschäftsanforderungen zu erfüllen. Diese Diagramme bieten Architekten und Entwicklern eine detaillierte Ansicht der Systeminteraktionen, Datenflüsse und Architekturmuster. Sie dienen als Blaupausen für die Implementierung und helfen Teams, Komponentenbeziehungen, Integrationspunkte und technische Abhängigkeiten innerhalb einer Lösung zu verstehen. Dieser Abschnitt enthält 7 Referenzdiagramme zur Lösungsarchitektur: | Diagrammname | Beschreibung | | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | [Null-Kopieren der Datenintegrationsarchitektur zwischen Salesforce Data 360 und GCP](/docs/architect/de-de/reference-diagrams/guide/data360-gcp) | Ein Diagramm, in dem Salesforce Data 360 vorkonfigurierte Konnektoren für die Integration in verschiedene Google Cloud Platform-Services verwendet. | | [Null-Kopieren der Datenintegrationsarchitektur zwischen Salesforce Data 360 und AWS](/docs/architect/de-de/reference-diagrams/guide/aws-data-360) | Ein Diagramm, in dem Salesforce Data 360 vorkonfigurierte Konnektoren für die Integration in verschiedene AWS Data Services verwendet. | | [Null-Kopieren der Datenintegrationsarchitektur zwischen Salesforce Data 360 und Snowflake](/docs/architect/de-de/reference-diagrams/guide/snf-data-360) | Ein Diagramm, in dem Salesforce Data 360 vorkonfigurierte Konnektoren für die Integration in die Snowflake Data Lake House Platform verwendet. | | [Null-Kopieren der Datenintegrationsarchitektur zwischen Salesforce Data 360 und Databricks](/docs/architect/de-de/reference-diagrams/guide/data360-databricks) | Ein Diagramm, in dem Salesforce Data 360 vorkonfigurierte Konnektoren für die Integration in die Databricks Delta Lake House Platform verwendet. | | [Data 360 Customer Zero-Implementierungsarchitektur](/docs/architect/de-de/reference-diagrams/guide/sfdc-customer-zero-implementation) | Ein durchgängiges Diagramm, das Salesforce Data 360 darstellt, wie es in Salesforce als Customer Zero-Programm implementiert ist. | | [Data 360-Batch-Aktivierung und ereignisgesteuerte Aktionsarchitektur](/docs/architect/de-de/reference-diagrams/guide/data360-actions-activations) | Ein Diagramm, das Salesforce Data 360 in einer durchgängigen Lösung für Marketingaktivierungen darstellt. | | [Lösungsarchitektur für die Treueverwaltung](/docs/architect/de-de/reference-diagrams/guide/loyalty-management-solution-architecture) | Ein Architekturdiagramm, das die Produkte und Funktionen darstellt, die direkt an einer Treueverwaltungslösung beteiligt sind. | # Middleware Scheduled Pull (Geplanter Middleware-Abruf) Geplanter Middleware-Abruf: Hier wird gezeigt, wie Middleware synchrone Anforderungen an die SOAP-API oder die REST-API senden kann, um Verzögerungen bei ausgehenden Integrationsaufträgen mit hohem Volumen zu minimieren. Die Daten werden planmäßig von Salesforce Platform abgerufen, statt dass die Plattform die Daten über asynchrones Apex überträgt. ## Beschreibung zeigt, wie Middleware synchrone Anforderungen an die SOAP-API oder die REST-API senden kann, um Verzögerungen bei ausgehenden Integrationsaufträgen mit hohem Volumen zu minimieren. Die Daten werden planmäßig von Salesforce Platform abgerufen, statt dass die Plattform die Daten über asynchrones Apex überträgt. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/b1c1dd9f-114f-4827-a238-960d840bbc1a) - [Bild](https://architect.salesforce.com/ns-assets/legacy/middlewarescheduledpull.png) # Middleware-Abruf über Plattformereignisbenachrichtigung Middleware-Abruf über Plattformereignisbenachrichtigung: Hier wird gezeigt, wie Sie Plattformereignisse verwenden können, um ausgehende Integrationen bereitzustellen, oder ein Middleware-Tool anweisen können, die erforderlichen Informationen über eine native API abzurufen und an das endgültige Ziel zu liefern. ## Beschreibung zeigt, wie Sie Plattformereignisse verwenden können, um ausgehende Integrationen bereitzustellen, oder um ein Middleware-Tool anzuweisen, die erforderlichen Informationen über eine native API abzurufen und an das endgültige Ziel zu liefern. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/1eee6c2f-056c-4ba4-a1ad-e78099066d46) - [Bild](https://architect.salesforce.com/ns-assets/legacy/pemiddlewarepull.png) # OmniStudio-Integrationen omniStudio integrations (OmniStudio-Integrationen): Dies ist eine Beispiellösungsarchitektur aus dem Decision Guide für OmniStudio zum Ändern der zugrunde liegenden JSON-Datei, die dann Salesforce-Objekten oder externen Daten mit Tools wie DataRaptor und Integrationsverfahren zugeordnet wird. DataRaptor und Integrationsverfahren sind zwei wichtige Komponenten zum Verbinden Ihrer OmniStudio-Formulare mit internen und externen Salesforce-Daten. ## Beschreibung Dies ist eine Beispiellösungsarchitektur aus dem Building Forms Decision Guide for OmniStudio manipulating based JSON (Entscheidungsleitfaden für Formulare erstellen für die Bearbeitung zugrunde liegender JSON), die dann Salesforce-Objekten oder externen Daten mit Tools wie DataRaptor und Integrationsverfahren zugeordnet wird. DataRaptor und Integrationsverfahren sind zwei wichtige Komponenten für die Verbindung Ihrer OmniStudio-Formulare mit internen und externen Salesforce-Daten. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/cb0eb20b-da86-4dac-a3fc-bff5ac387165) - [Bild](https://architect.salesforce.com/ns-assets/legacy/object-impact.png) # Publish Subscribe Unique Copy (Eindeutige Abonnementkopie veröffentlichen) Eindeutige Kopie des Abonnements veröffentlichen: Zeigt an, dass ein Ereignis veröffentlicht wird, wenn ein Datensatz über eine Benutzerinteraktion, einen Flow oder einen Batchauftrag geändert wird. Abonnenten erhalten ihre eigenen eindeutigen Kopien von Ereignissen und nehmen die entsprechenden Aktualisierungen an ihren eigenen Datensätzen vor. Nach diesem Muster sind alle Abonnenten im Nachrichtenkanal bekannt und es werden Ereigniskopien für jeden einzelnen erstellt, sodass Abonnenten Ereignisse bei Bedarf erneut abspielen können ## Beschreibung zeigt ein Ereignis an, das veröffentlicht wird, wenn ein Datensatz über eine Benutzerinteraktion, einen Flow oder einen Batchauftrag geändert wird. Abonnenten erhalten ihre eigenen eindeutigen Kopien von Ereignissen und nehmen die entsprechenden Aktualisierungen an ihren eigenen Datensätzen vor. Bei diesem Muster sind alle Abonnenten im Nachrichtenkanal bekannt und für jeden werden Ereigniskopien erstellt, sodass Abonnenten Ereignisse bei Bedarf erneut abspielen können. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/101c6c86-ab4c-406d-ac27-4e472fb33b5c) - [Bild](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-publish-subscribel3.png) # Roadmap Mithilfe von Roadmap-Diagrammen können Organisationen die strategische Implementierung von Funktionen, Komponenten, Funktionen und Systemen im Laufe der Zeit planen und visualisieren. Mit diesen Diagrammen können Architekten und Projektmanager die Ressourcenplanung optimieren, das Budget optimieren und die Zusammenarbeit zwischen Geschäfts- und technischen Teams verbessern. Sie bieten einen klaren Überblick über die Implementierungsreihenfolge, Abhängigkeiten und Prioritäten und helfen Beteiligten, den schrittweisen Ansatz zur Bereitstellung komplexer Salesforce-Lösungen zu verstehen. Dieser Abschnitt enthält 6 Referenzdiagramme für Roadmaps: | Diagrammname | Beschreibung | | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Fahrplan für Fähigkeiten](/docs/architect/de-de/reference-diagrams/guide/capability-roadmap) | Eine visuelle Roadmap, die die Ressourcenplanung und Budgetierung optimiert, indem Funktionen gruppiert und die Implementierungsreihenfolge, Abhängigkeiten und Werte identifiziert werden. | | [Komponenten-Roadmap](/docs/architect/de-de/reference-diagrams/guide/component-roadmap) | Eine visuelle Roadmap, die die Ressourcenplanung und Budgetierung optimiert, indem Systemfunktionen, relevante Funktionen, Implementierungsreihenfolge, Zeitrahmen und Abhängigkeiten von Beteiligten identifiziert werden. | | [Funktionsfahrplan](/docs/architect/de-de/reference-diagrams/guide/feature-roadmap) | Eine visuelle Roadmap, die die Zusammenarbeit zwischen Geschäfts- und technischen Teams verbessert, indem die Reihenfolge der Funktionsimplementierung, Abhängigkeiten und zusätzliche Funktionen für Planungszwecke identifiziert werden. | | [Agentforce-Versionsplan](/docs/architect/de-de/reference-diagrams/guide/generative-ai-release-plan) | Ein Diagramm mit Details zu den Ergebnissen für eine erste Veröffentlichung des Projekts für generative AI. | | [Agentforce Roadmap](/docs/architect/de-de/reference-diagrams/guide/generative-ai-roadmap) | Eine Beispiel-Roadmap mit Komponenten für die Einführung von AI in einer Salesforce Customer 360-Implementierung. | | [System Roadmap](/docs/architect/de-de/reference-diagrams/guide/system-roadmap) | Vereinfachen Sie die Ressourcenplanung und Budgetierung, indem Sie die Reihenfolge, Abhängigkeiten und Funktionsprioritäten der Systemimplementierung identifizieren. | ## Einführung Dieses Dokument bietet eine Übersicht über die Notation und Konventionen von Salesforce-Einheitenbeziehungsdiagrammen, damit Sie die in der [Datenmodellgalerie](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html) verfügbaren Produktdatenmodelle klar interpretieren können. Ein ERD, auch als Datenmodell bezeichnet, ist eine grafische Darstellung eines Informationssystems. Sie zeigt die Beziehungen zwischen Personen, Objekten, Orten, Konzepten und Ereignissen in diesem System an. Es handelt sich um ein logisches Modell, das die funktionale Struktur von Daten vermittelt. In Salesforce ERDs werden Einheiten in der Regel einem Objekt in der Salesforce-Datenbank zugeordnet. ## Einheiten Eine Einheit ist eine Sache oder ein Objekt von Bedeutung, unabhängig davon, ob es sich um eine reale oder konzeptionelle Einheit handelt, über die Informationen bekannt oder gespeichert werden müssen. sample data model entity Einheiten werden in den Diagrammen als Kästchen mit abgerundeten Ecken dargestellt. Jedes Einheitenfeld enthält in der Regel zwei Bezeichnungen (sofern zutreffend): - Der logische Name der Einheit (z. "Salesforce-Einheit" im hier gezeigten Beispiel). Dies kann der singulären Bezeichnung des dargestellten Salesforce-Objekts entsprechen, jedoch nicht immer. - Der "physikalische" API-Name oder Entwicklername des Objekts in Ihrer Salesforce-Organisation (z. "_API-Name_" im Beispiel). Bei Objekten mit verwalteten Paketen enthält der im Diagramm aufgeführte API-Name in der Regel nicht den Namespace des verwalteten Pakets ("vlocity_ins\*\*"), es sei denn, Salesforce oder Industry Cloud verwenden mehrere verwaltete Pakete. Das Ende des API-Namens für Objekte verwalteter Pakete gibt den Typ des verwendeten benutzerdefinierten Objekts an: "\*\*c" für reguläre benutzerdefinierte Objekte und benutzerdefinierte Einstellungen, "\*\*mdt" für benutzerdefinierte Metadaten und "\*\*x" für externe Objekte. Einheitenfelder können auch ein oder mehrere Attribute aufführen, die für die Attribute dieser Einheit repräsentativ sind. Einem Attribut wird entweder ein "#"- oder ein "-"-Zeichen vorangestellt. - Ein "#" gibt ein Attribut an, das Teil des logischen eindeutigen Schlüssels der Einheit ist. Im Beispieldiagramm wird "Benutzerschlüsselattribut" als primärer Benutzerschlüssel der Einheit betrachtet. - Ein "•" gibt ein Nicht-Schlüsselattribut an. ### Einheitenformatierung Jedes Einheitenbeziehungsdiagramm veranschaulicht das Salesforce-Datenmodell aus der Perspektive einer angegebenen Cloud wie Sales Cloud, Service Cloud oder Marketing Cloud. Das Farbschema des Diagramms spiegelt die Cloud im Fokus wider. Alle Branchen-Clouds wie Financial Service Cloud, Health Cloud und Media Cloud verwenden dasselbe Branchen-Farbschema. Die Farbe einer bestimmten Einheit im Diagramm hat auch eine bestimmte Bedeutung. Die Fokuswolkenfarbe wird anhand der Salesforce-Branding-Farbe angegeben, einschließlich einiger Beispiele unten. sample data model clouds Im folgenden Abschnitt werden die verschiedenen Einheitenformatierungen anhand der folgenden Sales Cloud-Beispiellegende erläutert: sample data model entities legend ### Cloud-Einheit Eine Einheit mit den Farben der Fokus-Cloud stellt ein Objekt dar, das mit der Lizenz für diese Cloud geliefert wird. ### Zugehörige Einheit Eine Einheit mit weißer Füllung und schwarzem Rahmen stellt ein Objekt dar, das über eine andere Lizenz als die Fokus-Cloud verfügt und nicht um die Fokus-Cloud-Lizenz erweitert wird. Account- und Kontakteinheiten, die beispielsweise in einem Sales- oder Service Cloud ERD-System angezeigt werden, werden weiß mit einem schwarzen Rahmen angezeigt, da diese Objekte mit einer Plattformlizenz verfügbar sind. ### Erweiterte verwandte Einheit Eine Einheit mit hellgrauer Füllung und schwarzem Rahmen stellt ein Objekt dar, das über eine andere Lizenz als die Fokus-Cloud verfügt. Die Fokus-Cloud erweitert dieses Objekt jedoch. Beispielsweise erweitert Commerce Cloud das Basisobjekt "Product2" um zusätzliche Felder. Erweiterungen enthalten zusätzliche Felder, Beziehungen und Datensatztypen. ### Externe Einheit Einheiten ohne Grenzen sind virtuell. Wenn diese Kästchen in einem Diagramm verwendet werden, wird die Existenz einer Einheit im logischen Modell für die Domäne bestätigt, die Einheit wird jedoch nicht als physisches Objekt in Salesforce implementiert. Es wird erwartet, dass über externe API-Aufrufe oder Salesforce Connect in der bereitgestellten Lösung auf die Daten für diese Einheit zugegriffen wird. ### Einheit "Datensatztyp" Einheiten mit gestricheltem Rahmen werden in Salesforce als Datensatztypen modelliert. Im hier gezeigten Beispiel weisen die Untertypen "Geschäftsaccount", "Rechnungsstellungsaccount", "Verbraucheraccount" und "Serviceaccount" einen gestrichelten Rahmen auf, da sie Datensatztypen zugeordnet sind, die mit dem verwalteten Communications Cloud-Paket bereitgestellt werden. sample data model record type notation ### Konzeptionelle Einheit Einheiten mit einem gepunkteten Rahmen sind virtuell. Weder Datensatztypen noch ein separates Objekt werden verwendet, um diese Untertypen in der Salesforce-Lösung zu unterscheiden. Diese Untertypen stellen logisch ein Konzept aus der Domäne dar, das die Funktionalität des Datenmodells veranschaulicht. ### Einheiten vom Typ "Supertyp" und "Untertyp" Ein Untertyp einer Einheit ist die Definition einer Teilmenge ihrer Vorkommen. Wenn ein Satz von Untertypen innerhalb einer Supertypeinheit hinzugefügt wird, zeigt die Supertypeinheit die allgemeinen Attribute und Beziehungen an, während die Untertypeinheiten Attribute und Beziehungen anzeigen, die für den Untertyp spezifisch sind. In der Diagrammnotation schließen sich Untertypen gegenseitig aus, d. h., jeder einzelne Datensatz muss einen einzelnen Untertyp aufweisen. sample subtype relationships Untertypen können verschachtelte Untertypen aufweisen, die die Vorkommen weiter unterscheiden. Untertypen in den Diagrammen sind logisch, können jedoch auf eine von drei Arten einer physischen Darstellung zugeordnet werden. Die Solidität des Rahmens der Untertypeinheit bestimmt, wie der Untertyp im Salesforce-Datenmodell implementiert wird. sample supertype Untertypeinheiten mit durchgezogenem Rahmen verfügen über ein tatsächliches Objekt, das die Vorkommen dieses Untertyps verfolgt. Im hier gezeigten Beispiel weist der Untertyp "Externer Benutzer" einen durchgezogenen Rahmen auf, da Kontakte, die als externe Benutzer registriert sind, mit einem Datensatz im Benutzerobjekt verfolgt werden. sample subtype contact object ## Beziehungen Eine Beziehung ist eine benannte, signifikante Zuordnung zwischen zwei Einheiten. sample relationships Die Markierungen und der Text in oder um die Zeilen beschreiben die Kardinalität, die Optionalität und die Bedeutung der Beziehung. ### Beziehungskardinalität sample relationships legend Kardinalität gibt die relative Anzahl der Vorkommnisse auf jeder Seite der Beziehung an. In der Notation geben die Enden einer Beziehungslinie die Kardinalität der Beziehung an diesem Ende an. Ein Krähenfuß an einem Ende gibt an, dass sich viele Einheitenvorkommen an diesem Ende auf jede Vorkommen am gegenüberliegenden Ende beziehen können. Das Fehlen eines Krähenfußes an einem Ende deutet darauf hin, dass sich höchstens eine Entität auf diesem Ende auf eine bestimmte Entität am anderen Ende beziehen kann. ### Über-/Unterordnungsbeziehungen Salesforce unterstützt zwei Arten von [Beziehungsfeldern](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/field_types.htm#i1435823): Nachschlagefelder und Felder vom Typ "Über-/Unterordnung" (auch Master-Detail-Felder genannt). Über-/Unterordnungsfelder sind wie erforderliche Nachschlagefelder, sie wenden jedoch eine zusätzliche Kopplung zwischen den zugehörigen Einheiten an. Datensätze auf der vielen Seite der Beziehung werden kaskadenartig gelöscht, wenn der übergeordnete Datensatz gelöscht wird. Auch die Sichtbarkeit der Detaildatensätze wird durch die Sichtbarkeit des übergeordneten Datensatzes gesteuert. Um den Unterschied zwischen einer untergeordneten und einer Nachschlagebeziehung zu veranschaulichen, entlehnen Salesforce ERDs die Diamantnotation aus UML. Ein Diamant auf der singulären Seite einer Beziehung bedeutet, dass die Einheit auf dieser Seite die Masterrolle in der Beziehung spielt. Die Entität auf der vielen Seite einer solchen Beziehung ist die Detail- oder untergeordnete Entität und kann als in der übergeordneten Entität enthalten angesehen werden. ### Beziehungsoptionalität Die Optionalität gibt an, ob die Beziehung für ein Auftreten an jedem Ende erforderlich ist oder nicht. Als Konzept ist die Optionalität eng mit der Kardinalität verbunden und die Schreibweise spiegelt diese Nähe wider. Die Optionalität wird an jedem Ende einer Beziehung durch einen Kreis oder Balken auf der anderen Seite der Beziehung angezeigt. Warum am anderen Ende der Beziehung? Um den optionalen Aufschlag auf derselben Seite der Linie wie die Kardinalität einzufügen. Auf der vielen (d. h. Krähenfuß-) Seite der Beziehung befindet sich fast immer ein Kreis auf der Linie. Das bedeutet, dass es für jedes Auftreten auf der singulären Seite der Beziehung Null-zu-Viele-Vorkommen auf der vielen Seite der Beziehung geben kann. Auf der singulären Seite der Beziehung geben ein Kreis und ein Balken eine optionale Beziehung für die Einheit auf der Krähenfußseite der Beziehung an. Der Kreis und der Balken bedeuten, dass es auf der singulären Seite der Beziehung für jedes Auftreten auf der vielen Seite null oder eins geben kann. Alternativ können auf der singulären Seite der Beziehung doppelte Balken eine erforderliche Beziehung für die Einheit auf der vielen Seite der Beziehung angeben. Die doppelten Balken bedeuten, dass es für jedes Auftreten auf der vielen Seite ein und nur ein Auftreten auf der singulären Seite der Beziehung geben muss. Die Optionalität einer Beziehung kann als erforderlich angezeigt werden, auch wenn die zugrunde liegende physische Beziehung in Salesforce optional ist. Beispielsweise ist das Feld AccountId für "Kontakt" physisch eine optionale Beziehung. Wenn Sie jedoch "Private Kontakte" ignorieren, ist die direkte Beziehung eines Kontakts zu einem Account logischerweise erforderlich. Die Optionalitätsanzeige wird sparsam verwendet. In den meisten Fällen spiegelt die im ERD angezeigte Optionalität die zugrunde liegende Optionalität der Beziehung wider. ### Beziehungsbedeutung sample relationships meaning Neben Kardinalität und Optionalität drückt jede Beziehung zwischen zwei Entitäten eine bestimmte Bedeutung aus, die diese Beziehung von anderen Beziehungen zwischen denselben beiden Entitäten unterscheidet. Beziehungsendnamen wie "Teil von" und "bestehen aus" im obigen Diagramm definieren die Art der Beziehung. sample relationships meaning Wenn Sie Kardinalität, Optionalität und Endnamen einer Beziehung kombinieren, können sie verwendet werden, um einen Satz zu bilden, der die Beziehung beschreibt. Von links nach rechts: Jeder (kann/muss) ist (ein und nur ein / ein oder mehrere) . Von rechts nach links: Jeder (kann/muss) ist (ein und nur ein / ein oder mehrere) . Beispiel: sample relationships meaning Von links nach rechts: "Jeder Kontakt muss in erster Linie ein Kontakt für einen und nur einen Account sein." Von rechts nach links: "Jeder Account kann in erster Linie durch einen oder mehrere Kontakte dargestellt werden." ### Beziehungsfarbcodierung Beziehungslinien sind farbcodiert. Beziehungen, die von der Cloud im Fokus für das Diagramm hinzugefügt wurden, werden in einer Farbe gezeichnet. Schwarze Linien stellen eine Beziehung dar, die eine andere Lizenz als die Fokus-Cloud aufweist. sample relationships color ### Rekursive Beziehungen Beziehungen können zwischen zwei Vorkommen derselben Einheit bestehen. Dies wird als rekursive Beziehung bezeichnet. Eine gekrümmte Beziehungslinie wird verwendet, um rekursive Beziehungen anzugeben. sample recursive relationships ### Sich gegenseitig ausschließende Beziehungen sample mutual exclusive relationships Salesforce ERDs schließen in der Regel die meisten Geschäftsregeln aus, um sich auf die Struktur des Datenmodells zu konzentrieren. Eine einander ausschließende Beziehung ist jedoch eine Geschäftsregel, die für die Struktur aussagekräftig ist. Eine einander ausschließende Beziehung gibt an, dass nur eine der verschiedenen im Arc enthaltenen Beziehungen für ein bestimmtes Auftreten verwendet wird. Beachten Sie, dass zwei, drei oder mehr Beziehungen an derselben einander ausschließenden Beziehung teilnehmen können. Ein Satz, der die hier gezeigte einander ausschließende Beziehung beschreibt, könnte wie folgt lauten: "Jede Einheit kann eine Instanz einer und nur einer ersten anderen Einheit oder einer und nur einer zweiten anderen Einheit sein." sample mutual exclusive relationships Beachten Sie, dass in Salesforce ERDs eine unterbrochene Beziehungslinie, die durch den Bogen verläuft, nicht Teil der einander ausschließenden Beziehung ist. ## Layoutkonventionen Offizielle Salesforce-Produkt-ERDs folgen Layoutkonventionen, um die Lesbarkeit zu verbessern. Zu diesen Layoutkonventionen zählen: - Beziehungslinien sollten immer gerade sein. - Beziehungslinien sollten vertikal oder horizontal gezeichnet werden. In seltenen Fällen, in denen dies nicht möglich ist, verwenden Sie eine gerade Linie in einer Diagonalen. - Um die Beziehungslinien gerade zu halten, können Einheitenboxen in ihrer Größe angepasst werden (größer oder breiter), um einen Zielort für die Beziehungen zwischen den beiden Einheiten bereitzustellen. Die wichtigeren Entitäten (auf denen mehr Beziehungen landen) werden im Diagramm größer angezeigt, was ihre Bedeutung unterstreicht. - Bei einem einzelnen ERD sollten sich die Krähenfüße für Beziehungen konsistent auf der linken und/oder oberen Seite der Beziehungslinie befinden (Upside-down-Layout) – oder konsistent auf der rechten und/oder unteren Seite der Beziehungslinie (Right-side-up-Layout). Diese Konvention bietet Klarheit, da ähnliche Einheiten im selben Bereich des Diagramms gesammelt werden, was für das Verständnis der Einheiten hilfreich ist. Die Verwendung des auf dem Kopf stehenden Layouts führt zwar dazu, dass Diagramme auf dem Kopf stehen, wobei untergeordnete Entitäten oberhalb oder links von übergeordneten Entitäten angezeigt werden. Dadurch wird jedoch sichergestellt, dass sich die spezifischen Entitäten im Diagramm in der oberen linken Ecke des Diagramms befinden, wodurch die Diagramme besser voneinander zu unterscheiden und wiederzuerkennen sind. Die Verwendung der Layoutkonvention auf der rechten Seite führt dazu, dass dieselben gängigen Entitäten in jedem Diagramm oben links angezeigt werden, untergeordnete Entitäten jedoch unterhalb oder rechts von übergeordneten Entitäten. Die genaue Einhaltung dieser Layoutkonventionen führt zu einem übersichtlichen und leicht lesbaren Diagramm. Überprüfen Sie die [Datenmodellgalerie](https://developer.salesforce.com/docs/platform/data-models/guide) auf die neuesten Salesforce-Datenmodelle, die diesem Standard entsprechen. # Salesforce-Rollenhierarchie Salesforce-Rollenhierarchie – eine Beispielorganisationshierarchie, die eine Teilmenge von Rollen erfasst, um Geschäftsstruktur, Personas und Berechtigungen für einen bestimmten Anwendungsfall zu verdeutlichen ## Beschreibung Ein Diagramm, das eine Beispielorganisationshierarchie darstellt und eine Teilmenge von Rollen erfasst, um die Geschäftsstruktur, Personas und Berechtigungen für einen bestimmten Anwendungsfall zu verdeutlichen. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/4fe3cd5e-0ccf-4ffd-9f7c-a418ce615c67) - [Bild](https://architect.salesforce.com/ns-assets/legacy/salesforcerolehierarchy1.png) ## Standardkomponenten Standardkomponenten erleichtern Ihnen das Erstellen, Anpassen und Wiederverwenden hochwertiger, konsistenter Diagramme. Dieser professionelle Stil wird für alle Salesforce-Diagrammvorlagen verwendet und ist in unseren Partnertools zum Diagrammieren von Anwendungsfällen verfügbar:
Lucidchart Lucidchart Elements.cloud Elemente Miro Miro Google Folien Google Folien

Beispiele für die Verwendung von Komponenten in der [Referenzarchitekturgalerie](https://architect.salesforce.com/diagrams#reference-architecture-gallery) ## Bewährte Vorgehensweisen In den folgenden Abschnitten werden ausführliche bewährte Vorgehensweisen für die in den Standardkomponenten enthaltenen [Kopfzeilen](#header), [Karten](#karten), [Symbole](#symbole) und [Konnektoren](#konnektoren) beschrieben. ## Header Diagrammkopfzeile Die Kopfzeile sollte in allen Diagrammen vorhanden sein und Folgendes enthalten: - Ein Titel, der von Ihrer Zielgruppe schnell verstanden werden kann - Eine klare Beschreibung dessen, was das Diagramm abdeckt, seinen Zweck und Intent - (optional) Ihr Logo oder Firmenname, um den Autor zu vermitteln - (optional) ein Schlüssel zur Verdeutlichung von Symbolen, Designs oder Symbolen, die als Klassifizierungen verwendet werden Die Größe sollte mindestens 10 % der Diagrammhöhe und 100 % der Breite einnehmen. Die Schriftgröße der Beschreibung sollte mindestens halb so groß sein wie der Titel. Ein Schlüssel sollte enthalten sein, wenn Symbole, Konnektoren, Farben usw. verwendet werden, die nicht mit Titeln im Diagramm selbst angegeben sind. Der Schlüssel sollte nach Möglichkeit in gerade Zeilen gruppiert werden. ## Karten Alle Eigenschaften Ihres Diagramms sollten mit einer Karte dargestellt werden. Karten können in ihrer Größe angepasst werden und transparente oder farbige Füllungen aufweisen. Es gibt mehrere Abschnitte der Karte, die Variationen bereitstellen, mit denen Sie verschiedene Konzepte in Ihrem Diagramm darstellen können. ### **Kartenanatomie** Eine Beispielkarte befindet sich unten mit den verschiedenen beschriebenen Abschnitten. Der einzige erforderliche Karteninhalt ist der Titel. Die anderen Abschnitte können bei Bedarf für bestimmte Anwendungsfälle verwendet werden. Kartenanatomie **Kartensymbol** Kartensymbole sind visuelle Datenbestände, die die Karteneigenschaft darstellen. **Kartentitel** Der Kartentitel ist ein Name für eine Karte, der schnell verstanden werden kann und erfasst, welche Eigenschaft, welchen Bereich oder welches Konzept die Karte darstellt. **Kartenattribute** Kartenattribute sind textbasierte Details zur Eigenschaft, die als Liste dargestellt und verwendet werden, wenn Sie mehrere Datenpunkte erfassen und übertragen müssen. **Kartenfußzeile** In der Fußzeile der Karte sind weitere Eigenschaften der Eigenschaft angegeben. Beispiele: Paket-/ Objekt-/ API-Namen, Inhaberschaft, Funktionen usw. **Kartenfußzeilensymbole** Im Abschnitt "Fußzeilensymbole" können visuelle Datenbestände zusätzliche Informationen zur Immobilie anzeigen. Beispiele: Kanäle, freigegebene Services, Funktionen usw. Fußzeilensymbole sollten in Ihrem Diagrammschlüssel enthalten/erläutert sein. ### **Kartenvariationen** Die Verwendung verschiedener Abschnitte bietet unterschiedliche Kartenvariationen für unterschiedliche Verwendungen. Sie können die Kartenanatomie nach Bedarf kombinieren und abgleichen, um diese Variationen in Ihren Diagrammen zu erstellen. Siehe Beispiele unten: Ausgeblendete Karte Detailkarte Detailkarte mit Fußzeile In der [Referenzarchitekturgalerie](https://architect.salesforce.com/diagrams#reference-architecture-gallery) finden Sie Ideen zur Verwendung dieser Variationen. Nutzen Sie die Möglichkeit, die Größe und Farbe Ihrer Karten nach Bedarf anzupassen, um Typen zu unterscheiden und klare, verständliche Diagramme zu erstellen. ## **Container** Karten können auch als Container fungieren, d. h. als Gruppierungen für mehrere Eigenschaften. Sie können Karten auf einer anderen Karte verschachteln, um hierarchische Beziehungen darzustellen oder zugehörige Eigenschaften nach Bedarf zu klassifizieren. Container ## **Symbole** Salesforce-Diagramme bieten einen grundlegenden Satz an Salesforce-Produktlogos sowie zusätzliche Symbole, die Eigenschaften und andere Bereiche in Ihrem Diagramm darstellen. Symbole Beispiele für die Verwendung von Symbolen finden Sie in der [Referenzarchitekturgalerie](https://architect.salesforce.com/diagrams#reference-architecture-gallery) _Weitere Symbole finden Sie in den [Lightning Design System-Symbolen.](https://www.lightningdesignsystem.com/icons/)_ ## Konnektoren Konnektoren sollten immer Winkelverbindungsleitungen verwenden und nach Möglichkeit gerade sein, um die Lesbarkeit zu verbessern. Konnektoren und Pillen **Konnektoren** stellen eine Beziehung, Integration oder einen Prozessschritt zwischen zwei Karten dar. Linienstile weisen auf einen anderen Verbindungstyp hin und sollten in Ihrem Diagrammschlüssel dargestellt werden. Endpunkte geben die Richtung eines Integrations- oder Prozesskonnektors an. Endpunkte geben auch Kardinalität und Gewöhnlichkeit in einem Beziehungskonnektor an. **Pillen** werden verwendet, um Details zu den Verbindungen bereitzustellen. Weitere Informationen zur Verwendung von Pillen finden Sie in den Diagrammen zur [Lösungsarchitektur](/docs/architect/de-de/reference-diagrams/guide/section-solution-architecture) und zum [Interaktionsprozess-Flow](/docs/architect/de-de/reference-diagrams/guide/section-interaction-process-flow). ## Barrierefreiheit Weltweit leben etwa [1,3 Milliarden](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.) Menschen mit einer Behinderung, was 15 % der Weltbevölkerung entspricht. Beim barrierefreien Zugriff geht es darum, Ihr Diagramm für alle Betrachter verständlich zu machen. Es gibt zwei spezielle Fokusbereiche, die Ihnen dabei helfen können, besser auf Ihre Diagramme zuzugreifen: die Optimierung für Bildschirmleseprogramme und die entsprechende Verwendung des Farbkontrasts. Weitere Ressourcen zur barrierefreien Gestaltung finden Sie im [Salesforce Design-Blog](https://medium.com/salesforce-ux/tagged/accessibility). **Bildschirmleseprogramme** Ein Bildschirmleseprogramm ist eine Softwareanwendung, die die Wörter in einer Datei, Anwendung oder Website vorliest. Bildschirmleseprogramme können Diagramme für Einzelpersonen lesen, die sie nicht klar sehen können. Das beste Format für die Bildschirmleseprogramm-Kompatibilität ist PDF (Portable Document Format). Im Gegensatz zu Bildern und nicht barrierefreien Anwendungen können Bildschirmleseprogramme auf PDFs zugreifen, um Wörter, Formen und Farben zu lesen. Wenn Sie Ihre Diagramme beim Freigeben für andere ins PDF-Format exportieren, kann der barrierefreie Zugriff verbessert werden. **Farbkontrast** Die Erhöhung des Farbkontrasts ist eine weitere Möglichkeit, damit Ihr Diagramm leichter zugänglich ist. Personen können Ihre Diagramme besser erkennen und lesen, wenn sie den minimalen Farbkontrast zwischen der Hintergrundfarbe hinter dem Text und der Farbe des Texts selbst erfüllen, der [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html) entspricht. Farbpalettenbeispiel zum Anzeigen des vorgeschlagenen Kontrasts Jeder Farbe im [Salesforce-Farbsystem](https://medium.com/salesforce-ux/the-salesforce-color-system-c7c6b5b9c577) ist eine Zahl zwischen 0 und 100 zugeordnet. Achten Sie bei der Auswahl der Farben für Ihre Diagramme darauf, dass die Hintergrundfarbe hinter dem Text mindestens 50 Punkte größer oder kleiner als die Farbe des Texts ist. Wenn Ihre Hintergrundfarbe beispielsweise 80 ist, sollte Ihre Textfarbe nicht höher als 30 sein. Ziehen Sie in Erwägung, die 50-Punkte-Regel nach Bedarf auch für Rahmen und Umrisse zu verwenden. **Haben Sie Eingaben oder Fragen zu Salesforce Diagrams?** Bitte teilen Sie uns [hier](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link) Ihre Gedanken mit. # Streaming Streaming: Zeigt einen Stream der zu veröffentlichenden Ereignisse an. Abonnenten, die die Streams abhören, erhalten sie und verarbeiten sie entsprechend. ## Beschreibung zeigt einen Stream der zu veröffentlichenden Ereignisse an. Abonnenten, die die Streams abhören, erhalten sie und verarbeiten sie entsprechend. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/13f15b6c-0b36-4048-b2ec-88e5137c6c0b) - [Bild](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-streaming.png) # System-Roadmap System-Roadmap: Ein Roadmap-Diagramm, das die Ressourcenplanung und Budgetierung vereinfacht. ## Beschreibung Ein Roadmap-Diagramm, das die Ressourcenplanung und Budgetierung vereinfacht, indem die Reihenfolge der Systemimplementierung, Abhängigkeiten, Funktionsbereiche und relevante Funktionen für Beteiligte identifiziert werden. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/ead3af9a-ddc2-492a-a8c9-7ab3943fabd7) - [Bild](https://architect.salesforce.com/ns-assets/roadmap-technology-system.png) # Systemlandschaft Systemlandschaftsdiagramme bieten einen umfassenden Überblick über das Technologie-Ökosystem einer Organisation und veranschaulichen die Beziehungen zwischen Salesforce-Produkten, externen Systemen und Integrationspunkten. Mithilfe dieser visuellen Darstellungen können Architekten die vollständige Systemtopologie verstehen, Abhängigkeiten identifizieren und strategische Implementierungen planen. Sie dienen Beteiligten als wichtige Dokumentation, um zu visualisieren, wie verschiedene Komponenten in einer Customer 360 Architektur interagieren, und unterstützen Geschäftsziele. Dieser Abschnitt enthält 5 Referenzdiagramme in Bezug auf die Systemlandschaft: | Diagrammname | Beschreibung | | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Customer 360 Marketing System Landscape](/docs/architect/de-de/reference-diagrams/guide/data-360-marketing) | Eine Systemlandschaft für eine Customer 360 Architecture-Implementierung. | | [Agentforce Systemlandschaft](/docs/architect/de-de/reference-diagrams/guide/einstein-system-landscape) | Eine Systemlandschaft, die die Kombination aus Salesforce-Produkten und anderen mit Agentforce verfügbaren Technologiesystemen erfasst. | | [Einzelhandelssystemlandschaft](/docs/architect/de-de/reference-diagrams/guide/retail-system-landscape) | Eine Systemlandschaft mit einer B2C Commerce- und Marketing-Lösung, die den Mix aus Salesforce-Produkten und anderen an der Implementierung beteiligten Technologien angibt. | | [Salesforce-Rollenhierarchie](/docs/architect/de-de/reference-diagrams/guide/salesforce-role-hierarchy) | Eine Beispielorganisationshierarchie, die eine Teilmenge von Rollen erfasst, um Geschäftsstruktur, Personalbeziehungen und Zugriffsmuster zu verdeutlichen. | | [Architektur einer einzelnen Organisation](/docs/architect/de-de/reference-diagrams/guide/single-org-architecture) | Ein Diagramm mit einer einzelnen Organisationsstrategie, die mehrere Geschäftseinheiten unterstützt. | # Übergebene Nachrichten Bestandene Nachrichten: zeigt ein Beispiel eines Prozess-Flows für das Muster "Bestandene Nachrichten", das einen Publisher, einen Abonnenten und ein Ereignis enthält. Das Ereignis ist in mehrere Teile unterteilt, die jeweils einzeln umgewandelt und dann vor dem Senden an den Abonnenten erneut zusammengesetzt werden. ## Beschreibung zeigt ein Beispiel eines Prozess-Flows für das Muster "Übergebene Nachrichten", das einen Publisher, einen Abonnenten und ein Ereignis enthält. Das Ereignis wird in mehrere Teile aufgeteilt, die jeweils einzeln umgewandelt und dann vor dem Senden an den Abonnenten erneut zusammengesetzt werden ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/1216b5f7-a2f7-444c-a695-73422c43a87b) - [Bild](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-passedmessages.png) # Warteschlange Warteschlange: Zeigt ein Beispiel für das Warteschlangenmuster, das anzeigt, dass ein Ereignis veröffentlicht und in eine Warteschlange geschrieben wird, wenn ein Datensatz geändert wird. Abonnenten erhalten Kopien des Ereignisses aus ihren zugeordneten Warteschlangen und nehmen die entsprechenden Aktualisierungen an ihren eigenen Datensätzen vor. ## Beschreibung zeigt ein Beispiel für das Warteschlangenmuster, das anzeigt, dass ein Ereignis veröffentlicht und in eine Warteschlange geschrieben wird, wenn ein Datensatz geändert wird. Abonnenten erhalten Kopien des Ereignisses aus ihren zugeordneten Warteschlangen und nehmen die entsprechenden Aktualisierungen an ihren eigenen Datensätzen vor. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0cef151e-5b48-4237-bbe4-a774eee152ab) - [Bild](https://architect.salesforce.com/ns-assets/legacy/eventdrivenarchitecturediagrams-queuing.png) # Zero-Copy-Datenintegrationsarchitektur zwischen Salesforce Data 360 und AWS Integrationsarchitektur für Nullkopiedaten zwischen Salesforce Data 360 und AWS ## Beschreibung Ein Diagramm, in dem Salesforce Data 360 vorkonfigurierte Konnektoren für die Integration in verschiedene AWS Data Services sowie die leistungsstarke Zero Copy-Interoperabilität mit AWS Redshift und S3 zeigt. Diese Architektur ermöglicht es Organisationen, Daten nahtlos über Verbundplattformen hinweg zu integrieren und zu vereinheitlichen und bietet eine zentrale Vereinheitlichungs- und Aktivierungsebene, die für die Umwandlung in ein echtes Agentenunternehmen unerlässlich ist. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/04991364-85c0-45e6-b5de-553367fbb473) - [Bild](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-aws.png) # Zero-Copy-Datenintegrationsarchitektur zwischen Salesforce Data 360 und Databricks Null-Kopie-Datenintegrationsmuster zwischen Salesforce Data 360 und Databricks ## Beschreibung Ein Diagramm, in dem Salesforce Data 360 vorkonfigurierte Konnektoren für die Integration in Databricks Delta Lake House Platform mit Zero Copy Interoperability verwendet. Diese Architektur ermöglicht es Organisationen, Daten nahtlos über Verbundplattformen hinweg zu integrieren und zu vereinheitlichen und bietet eine zentrale Vereinheitlichungs- und Aktivierungsebene, die für die Umwandlung in ein echtes Agentenunternehmen unerlässlich ist. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/e74f6e22-ce6d-4b6d-a258-76ddb8f73f4e) - [Bild](https://sf-archs.cdn.salesforce-experience.com/cms/delivery/media/MCBDXPMJDI2VCTRKXXYRHJCFANPQ?channelId=0apHs000000y0QG&oid=00DHs000003Wrxy) # Zero-Copy-Datenintegrationsarchitektur zwischen Salesforce Data 360 und GCP Integrationsarchitektur für Nullkopiedaten zwischen Salesforce Data 360 und GCP ## Beschreibung Ein Diagramm, in dem Salesforce Data 360 vorkonfigurierte Konnektoren für die Integration in verschiedene Google Cloud Platform-Services verwendet. Salesforce Data 360 vereinheitlicht Daten und steuert Maßnahmen. Sie verfügt über vorkonfigurierte Konnektoren für die Integration in verschiedene Google Cloud-Plattformservices sowie über die leistungsstarke Zero Copy-Interoperabilität mit Google BigQuery und Google Cloud Storage. Diese Architektur ermöglicht es Organisationen, Daten nahtlos über Verbundplattformen hinweg zu integrieren und zu vereinheitlichen und bietet eine zentrale Vereinheitlichungs- und Aktivierungsebene, die für die Umwandlung in ein echtes Agentenunternehmen unerlässlich ist. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/4661f0e4-e86a-409b-9a98-8301cbbca74f) - [Bild](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-gcp.png) # Zero-Copy-Datenintegrationsarchitektur zwischen Salesforce Data 360 und Snowflake Integrationsarchitektur für Nullkopiedaten zwischen Salesforce Data 360 und Snowflake ## Beschreibung Ein Diagramm, in dem Salesforce Data 360 vorkonfigurierte Konnektoren für die Integration in die Snowflake Data Lake House Platform mit Zero Copy Interoperability verwendet. Diese Architektur ermöglicht es Organisationen, Daten nahtlos über Verbundplattformen hinweg zu integrieren und zu vereinheitlichen und bietet eine zentrale Vereinheitlichungs- und Aktivierungsebene, die für die Umwandlung in ein echtes Agentenunternehmen unerlässlich ist. ## Herunterladbare Links: - [Lucid](https://lucid.app/lucidchart/editNew/b02236c2-f3f4-4de8-b13b-35f67fd5390d) - [Bild](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-snf.png)