# architect Entscheidungsleitfäden (decision-guides) - Full Documentation # Asynchrone Verarbeitung Verwenden Sie diese Anleitung, um den richtigen Ansatz für die asynchrone Verarbeitung von Salesforce für jeden Anwendungsfall auszuwählen. ## Leitfadenübersicht Dieser Leitfaden hilft Ihnen, den richtigen Ansatz für Ihre asynchronen Verarbeitungsanforderungen auf der Salesforce Platform zu bewerten. Es wird jeder Ansatz erläutert und es werden die Stärken und Einschränkungen der einzelnen Ansätze erläutert. Die meisten Ansätze sind auf eine Produktfunktion abgestimmt, einige Ansätze verwenden jedoch mehrere Funktionen in Abstimmung. Der Leitfaden enthält Anwendungsfälle, in denen hervorgehoben wird, wann die einzelnen Ansätze verwendet werden sollten. Die asynchrone Verarbeitung bietet zwei wesentliche Vorteile für Ihre Architektur. Erstens wird die Skalierbarkeit erhöht, da für asynchrone Prozesse höhere Obergrenzen gelten. Zweitens werden asynchrone Anforderungen in ihren eigenen Threads ausgeführt, sodass Benutzer andere Arbeiten ausführen können, während die asynchronen Aufgaben im Hintergrund ausgeführt werden. Beachten Sie, dass sich dieser Leitfaden ausschließlich auf die Auswahl einer asynchronen Verarbeitungstechnologie in Salesforce Platform konzentriert. Weitere Ressourcen zur Unterstützung Ihres Entscheidungsprozesses sind im [Abschnitt "Ressourcen](#ressourcen)" aufgeführt. ## Produkte im Geltungsbereich dieses Handbuchs
Salesforce Platform Bei der Salesforce Lightning Platform handelt es sich um eine umfassende AI-gestützte Plattform, die Mitarbeiter, autonome AI-Agenten, Unternehmensdaten und Anwendungen in einem einzigen, vertrauenswürdigen System zusammenführt, um die Produktivität und die Kundenerfahrung zu steigern. Durch die Verbindung von Customer 360-Anwendungen, Data Cloud und Slack für eine durchgängige Automatisierung kann ein "Agentenunternehmen" erstellt werden.
In diesem Dokument werden keine Technologien in anderen Ökosystemen wie MuleSoft, Informatica, Commerce Cloud, Tableau und Marketing Cloud behandelt. ## Takeaways - **Vergewissern Sie sich vor der Verwendung der asynchronen Verarbeitung, dass Ihre Anwendungsfälle dem Muster entsprechen.** Asynchrone Muster weisen kein SLA auf, unterliegen mehreren Reglermechanismen, können Kapazitätsobergrenzen basierend auf Lizenzen definieren und aufgrund der begrenzten Beschaffenheit der Ressourcen, die der asynchronen Infrastruktur innerhalb der Salesforce Platform zugewiesen sind, zu Verarbeitungsverzögerungen führen. Beachten Sie diese Einschränkungen, wenn Sie die asynchrone Verarbeitung in Szenarien verwenden, in denen ein Benutzer eine Antwort vom System benötigt, bevor er mit seiner Arbeit fortfahren kann. - **Die asynchrone Verarbeitung mit Salesforce ist keine Lösung für grenzenlose Skalierungsanforderungen.** Die Salesforce Platform kann nicht unbegrenzt skaliert werden und asynchrone Muster unterliegen Einschränkungen. Bei der asynchronen Verarbeitung werden Threads verwendet, die die Kontextinformationen enthalten, die eine CPU zum Ausführen eines Streams von Anweisungen benötigt. Threads können parallel ausgeführt werden. Die Anzahl der verfügbaren Threads in einer CPU ist begrenzt. Daher verfügt die Plattform über Mechanismen, um ihre verfügbaren Threads so effizient wie möglich zu verwenden. Der [Flow-Kontrollmechanismus](/docs/architect/de-de/fundamentals/guide/async-fundamentals#flow-steuerung) der Plattform verhindert, dass Organisationen zu viele Threads verwenden und sich negativ auf andere Organisationen auswirken. Der [Algorithmus für die faire Nutzung](/docs/architect/de-de/fundamentals/guide/async-fundamentals#faire-nutzung) der Plattform steuert auch die Anzahl der Threads, die in einer Organisation für jeden bestimmten Nachrichtentyp verfügbar sind. - **Berücksichtigen Sie Ereignisse, die zu extremen Belastungen führen können.** Stellen Sie beim Entwerfen asynchroner Prozesse sicher, dass sie Arbeitslastspitzen und -lupen vorhersehbar verwalten können. Überlegen Sie, wie Ihre Implementierung mit unerwarteten Ereignissen wie Stromausfällen und Design-Sicherungen umgeht, die Datenverlust oder Funktionsverlust minimieren. ## Produktvergleich In dieser Tabelle sind die Tools aufgeführt, die für die asynchrone Verarbeitung mit Salesforce verfügbar sind. In dieser Tabelle finden Sie Informationen zu den wichtigsten Merkmalen der einzelnen Tools während Ihres Entscheidungsprozesses. Unter [Anwendungsfälle](#anwendungsfälle) und [Entscheidungspunkte](#entscheidungspunkte) finden Sie Hilfe bei der Auswahl der richtigen Tools für Ihre Architektur.
Ansatz Beschreibung Erforderliche Fertigkeiten Lizenzen und Obergrenzen
Queueable Apex Wird für Prozesse verwendet, die langfristige Datenbankvorgänge oder Callouts für externe Webservices beinhalten. Der warteschlangenfähige Apex bietet Funktionen wie Auftrags-IDs, Unterstützung für nicht primitive Typen und Auftragsverkettung. Pro-Code Die Anzahl der Lizenzen kann die Obergrenzen erhöhen.
Batch Apex Erstellen Sie komplexe, langfristige Prozesse, die Millionen von Datensätzen umfassen, indem Sie Ihren Datensatz aufteilen und in überschaubare Blöcke verarbeiten. Pro-Code Die Anzahl der Lizenzen kann die Obergrenzen erhöhen.
Geplantes Apex Führen Sie Apex zu einem geplanten Zeitpunkt aus, der durch einen Cron-Ausdruck definiert ist. Obwohl es sich bei der Planung von Apex über den Ausdruck cron um einen asynchronen Prozess handelt, wird der zugrunde liegende Code synchron ausgeführt, wenn der Auftrag gestartet wird. Pro-Code Die Anzahl der Lizenzen kann die Obergrenzen erhöhen.
Apex-Fortsetzungs-Callouts Führen Sie Callouts aus Apex-Methoden aus, die in einem synchronen Transaktionskontext ausgeführt werden. Pro-Code Nein
Asynchroner Pfad (durch Datensätze ausgelöste Flows) Führen Sie einen Vorgang aus, den Sie selbst ausführen möchten. Vermeiden Sie gemischte DML-Fehler, die auftreten, wenn Sie einen Wert in einem verwandten Datensatz aktualisieren, der nicht Teil des Datensatzes ist, der einen Flow ausgelöst hat. Low-Code Anzahl und Typ der Lizenzen können die Obergrenzen erhöhen.
Geplanter Pfad (nach Commit-Flows) Ausführen zu einem dynamisch geplanten Zeitpunkt nach einem auslösenden Ereignis, beispielsweise wenn ein Datensatz erstellt, aktualisiert oder gelöscht wird. Low-Code Anzahl und Typ der Lizenzen können die Obergrenzen erhöhen.
Geplante Flows Führen Sie einen Flow im Hintergrund zu einer angegebenen Zeit und mit wiederholter Häufigkeit (täglich, wöchentlich oder einmal) aus, um Aktionen für einen Datensatzbatch auszuführen. Low-Code Anzahl und Typ der Lizenzen können die Obergrenzen erhöhen.
Plattformereignisauslöser Koppeln Sie Salesforce lose mit externen Systemen und kommunizieren Sie zwischen asynchronen Komponenten innerhalb der Salesforce Platform. Low-Code + Pro-Code Für Anwendungsfälle von Plattformereignissen mit hohem Volumen ist eine Add-On-Lizenz erforderlich
Datenerfassung ändern Erfassen und verarbeiten Sie Änderungsereignisse asynchron, nachdem die Datenbanktransaktion übernommen wurde. Pro-Code Für die Skalierung oberhalb der Basiszuteilung ist eine Add-On-Lizenz erforderlich.
Bulk API Fügen Sie viele Datensätze asynchron ein, aktualisieren, aktualisieren, einfügen, abfragen oder löschen Sie sie und verarbeiten Sie die Ergebnisse später. Pro-Code Es gibt Obergrenzen.
Lightning Aktionen Ermöglichen Sie es Lightning-Seiten, mit dem Server zu interagieren, ohne Benutzer zu zwingen, die Seite vollständig zu aktualisieren. Low-Code Nein
## Entscheidungspunkte Diese Tabelle enthält eine Übersicht der Punkte, die Sie bei der Entscheidung für das zu verwendende asynchrone Tool berücksichtigen sollten.
Erforderliche Fertigkeiten Einige der in diesem Handbuch beschriebenen Tools erfordern Code, während andere deklarativ konfiguriert werden können. Überlegen Sie sich bei Ihren Optionen, über welche Fertigkeiten Ihre Teammitglieder verfügen. Beachten Sie, dass Sie Ihre Lösungen in Zukunft möglicherweise ändern müssen, selbst wenn Entwickler für Ihre erste Implementierung verfügbar sind (beispielsweise über einen Implementierungspartner). Wenn Ihrem Wartungsteam Entwickler fehlen, kann eine Low-Code-Option besser passen.
Typ der erzwungenen Plattformobergrenzen Legen Sie fest, welche Obergrenzen für die Ausführung gelten. Überlegen Sie beim Entwerfen Ihrer Lösungen genau, wie das Volumen und die Häufigkeit von Transaktionen auf die Obergrenzen für den gewählten Ansatz pro Tag angerechnet werden. Berechnen Sie die Anzahl der Hinrichtungen, die jeden Tag erfolgen. Stellen Sie sicher, dass die berechneten Werte innerhalb der mit Ihren ausgewählten Tools verknüpften Obergrenzen liegen.
Latenz Bestimmen Sie, wie schnell die Verarbeitungsergebnisse auf der Plattform verfügbar sein sollen. Bei einigen Ansätzen sind die Änderungen nahezu sofort, bei anderen hingegen in Minuten oder Stunden.
## Anwendungsfälle Wenn Sie ein Tool für die asynchrone Verarbeitung auswählen, sollten Sie zunächst die Anforderungen und verfügbaren Ressourcen Ihrer Organisation auswerten. Ihr Ziel ist es, das oder die Tools auszuwählen, die die Implementierungs- und Wartungskosten minimieren, aber dennoch die Skalierbarkeit gewährleisten und die Wahrscheinlichkeit von Obergrenzenverstößen minimieren. Dieses Ziel hängt von den zuvor beschriebenen technischen Überlegungen und der Zusammensetzung Ihres Teams ab. Stellen Sie sich einen asynchronen Bestellprozess in Salesforce vor. Wenn ein Auftrag gespeichert wird, wird eine Meldung an ein externes Lagerverwaltungssystem mit speziellen Anweisungen zum Verpacken und Versenden eines Artikels ausgelöst. Der Benutzer, der den Auftrag erteilt, benötigt keine sofortige Antwort vom Lagerverwaltungssystem, sodass die Anforderung asynchron gesendet werden kann. Durch die asynchrone Verarbeitung kann der Benutzer seine Arbeit fortsetzen, ohne auf eine Antwort warten zu müssen. In diesem Anwendungsfall können Sie die Implementierung mit Apex in Erwägung ziehen. Dieser Ansatz funktioniert nur, wenn Sie Apex-Entwickler in Ihrem Team haben, die Ihre Pro-Code-Lösung verwalten können. Andernfalls ist ein deklarativer Ansatz sinnvoller. Beachten Sie außerdem, dass für verschiedene Tools unterschiedliche [Obergrenzen](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) gelten. In dieser Tabelle werden allgemeine Anwendungsfälle in der Spalte ganz links gefolgt von einer Beschreibung aufgeführt. In der Spalte _Erste Wahl_ finden Sie den typischsten Ansatz, der verwendet wird, um einen solchen Anwendungsfall zu erfüllen, sowie die Gründe für den Ansatz Erste Wahl. Verwenden Sie dies als Ausgangspunkt für Ihre Analyse – der Ansatz der ersten Wahl weist möglicherweise Einschränkungen auf, die für Ihren Anwendungsfall nicht funktionieren.
Anwendungsfall Beschreibung Ansatz der ersten Wahl Begründung
Hochleistungsfähige Batchverarbeitung Jede Automatisierung, die Tausende oder Millionen von Datensätzen effizient verarbeiten muss Batch-Apex Batch Apex bietet umfangreiche APIs für die Anbindung an die Plattform und für die Rohgeschwindigkeit.
Datenbereinigungsauftrag Ein Auftrag, der routinemäßig oder nach Bedarf ausgeführt wird und Daten bereinigt. Beispiele hierfür sind die Duplizierung, die Adressüberprüfung oder die Datenkonsolidierung. Batch-Apex Batch Apex bietet umfangreiche APIs für die Anbindung an die Plattform und für die Rohgeschwindigkeit.
Nächtlicher Rollup-Auftrag Auftrag, der Rollup-Daten am Ende eines Geschäftstags berechnet. Batch-Apex Batch Apex bietet umfangreiche APIs für die Anbindung an die Plattform und für die Rohgeschwindigkeit.
Durch Datensatz ausgelöste Logik Führen Sie Logik als Reaktion auf eine Datensatzaktualisierung aus. Variiert Lesen Sie unseren Leitfaden zur begleitenden Entscheidung, Record Triggered Events Automation. Sie enthält eine Entscheidungsstruktur für asynchrone Anwendungsfälle, einschließlich warteschlangenfähigen Apex, Batch Apex, geplanten Apex, geplanten Flows, asynchronen Pfad-Flows und Datenerfassung ändern.
Eskadierende Aktualisierungen durch ein Objektdiagramm Ermöglicht es einem Benutzer, die Speicheraktion schnell abzuschließen, indem kaskadierende Aktualisierungen an anderen Objekten zurückgestellt werden, um sie asynchron auszuführen. Warteschlangenfähiger Apex Der warteschlangenfähige Apex verfügt über leistungsstarke Verkettungsfunktionen, mit denen eine Aktualisierungskette durch Logik in eine Reihe asynchroner Transaktionen unterteilt werden kann.
Datensatzspezifische geplante Verarbeitung Automatisierung zu einem zukünftigen dynamischen Datum, das für den Datensatz spezifisch ist (z. B. 3 Tage vor einem Schlusstermin). Flow mit einem geplanten Pfad Geplante Pfade bieten Flow eine einzigartige Stärke, da die Plattform automatisch die Planung, Stornierung und Neuplanung dieser Pfade übernimmt, wenn sich die Daten des Datensatzes ändern.
Mehrere langsame externe Services parallel aufrufen Während einer synchronen Ausführung werden mehrere externe Services parallel aufgerufen, um die Gesamtausführungszeit zu optimieren. Callouts für Apex-Fortsetzungen Wenn Sie zulassen, dass mehrere langsam ausgeführte Callouts parallel ausgeführt werden, wird die Gesamtzeit zum Abschließen der Arbeit minimiert.
Datenmigration von Datensätzen aus einem externen System Verschieben Sie große Datensatzmengen aus einem externen System in die Salesforce Platform. Entweder einmalig oder regelmäßig geplant. Bulk- API Dies ist der effizienteste und grenzenschonendste Ansatz für die Datenmigration.
Ausführen zusätzlicher Logik auf einem externen System Feuer-und-Vergessen-Muster, bei dem ein externes System über ein Ereignis auf der Plattform benachrichtigt wird und dieses System dann das Ereignis asynchron verarbeiten kann. Plattformereignisse oder Datenerfassung ändern Ein Pub-Sub-Modell funktioniert hier am besten und ermöglicht es dem externen System, das Ereignis zu verarbeiten, wenn es bereit ist. Weitere Details zu diesem Muster finden Sie unter Ereignisgesteuerte Architektur.
Die Tabelle "Anwendungsfälle" ist ein Leitfaden für den am besten geeigneten Ansatz für jeden Anwendungsfall. Sie müssen jedoch überprüfen, ob die First Choice-Technologie den spezifischen Anforderungen Ihres Anwendungsfalls entspricht. Legen Sie insbesondere fest, ob der gewählte Ansatz die Obergrenzen für Ihre Organisation einhalten kann. Sobald Sie einen Kandidatenansatz für Ihren Anwendungsfall identifiziert haben, kann der [Leitfaden zu den](/docs/architect/de-de/fundamentals/guide/async-fundamentals) Grundlagen der asynchronen Verarbeitung die Lösung vollständig überprüfen. ## Ressourcen Diese zusätzlichen Ressourcen können Ihnen bei der Entscheidung helfen: - Tauchen Sie tief in jede der asynchronen Plattformtechnologien ein: [Grundlagen der asynchronen Verarbeitung](/docs/architect/de-de/fundamentals/guide/async-fundamentals) - Auswahl zwischen Apex und Flow für Datensatzauslöser: [Automatisierung von durch Datensätze ausgelösten Ereignissen](/docs/architect/de-de/decision-guides/guide/record-triggered) - Informationen zu asynchronen Integrationsmustern: [Ereignisgesteuerte Architektur](/docs/architect/de-de/decision-guides/guide/event-driven) # Bestimmen der Automatisierung von Agenten und traditionellen Workflows Mit Agentforce können Unternehmen nun neue Paradigmen für automatisiertes Arbeiten freischalten, die sich nicht einfach auf Regeln reduzieren lassen. Zu diesen neuen Funktionen zählen die Lösung von Kundenabsichten aus unstrukturierten Unterhaltungen, die systemübergreifende Koordination von Prozessen mehrerer Parteien und die Reaktion auf betriebliche Bedingungen in Echtzeit. Agentische Workflows verwenden eine Automatisierung, die darauf ausgelegt ist, auf Ergebnisse hinzuarbeiten, statt vordefinierte Schritte auszuführen. Um diese Anforderung zu erfüllen, ist eine Plattform erforderlich, die über das gesamte Spektrum der Automatisierungskomplexität hinweg funktioniert, und ein Framework, das anzeigt, wo die einzelnen Funktionen hinpassen. Agentforce kombiniert die Einstein Trust Layer, das Argumentationsmodul, das Agentenskript, Flow, Apex und Data 360 in einer einzigen einheitlichen Plattform. Diese Kombination verarbeitet alles – von der einfachen Automatisierung von Datensatzauslösern bis hin zur komplexen Orchestrierung von mehreren Agenten über Sprach-, Bildverarbeitungs-, Dokument- und Echtzeittelemetrie hinweg. MuleSoft erweitert diese Plattform um die MuleSoft-Struktur, -Governance und -systemübergreifende Orchestrierung, die zum Verbinden von Agenten-Workflows in einem Unternehmen erforderlich sind. Agentforce Operations (zuvor Agentforce Supply Chain) wendet diese Funktionen auf die spezifischen Anforderungen von Betriebs- und Fertigungsprozessen an. ## Leitfadenübersicht Dieser Leitfaden stellt das Framework für Orchestrierungsdichten und Richtlinien für fundierte Entscheidungen in dieser Produktlandschaft vor. Das Framework bietet Architekten einen wiederholbaren Ansatz, um mithilfe von Dichtestufen für Anwendungsfälle der intelligenten Automatisierung auf Salesforce Platform die richtigen Tools und Muster auszuwählen. ## Produkte im Umfang | Produkt | Beschreibung | | :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agentforce | [Agentforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5) ist die Salesforce-Plattform zum Erstellen und Bereitstellen von AI-Agenten. Über Apex und Data 360 werden dynamisch fundierte Aktionen in Echtzeit ausgelöst. | | Agentenskript | [Agentenskript](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html) ist eine deklarative domänenspezifische Sprache, die im Agentforce Builder zum Definieren von Workflows, Geschäftsregeln und Unterhaltungslogik für Agenten verwendet wird. | | Agentforce Raster | Bei [Agentforce Grid](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5) handelt es sich um eine native AI-ähnliche Oberfläche ohne Code, mit der AI-Workflows schnell und skalierbar konzipiert und operationalisiert werden können. | | Agentforce-Vorgänge | Bei [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5) (zuvor Agentforce Supply Chain) handelt es sich um eine AI-gestützte Orchestrierungsplattform für die gemeinschaftliche Workflow-Verwaltung, die Back-Office-Geschäftsprozesse optimieren und automatisieren soll. | | MuleSoft | [MuleSoft](/docs/architect/de-de/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html) ist eine umfassende, einheitliche und offene Plattform für die Unternehmensintegration und die Verwaltung von Agenten. Durch API-geführte Konnektivität und MuleSoft Agent Fabric und Agent Broker dient es als Integrationsgewebe, Governance-Ebene und systemübergreifende Orchestrierungsgrundlage für die Verbindung von Agenten-Workflows im gesamten Unternehmen. | | Flows und Apex | [Salesforce Flow](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5) ist ein leistungsstarkes Zeigen-und-Klicken-Automatisierungstool zum visuellen Erstellen komplexer Geschäftsprozesse ohne Code. [Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm) ist eine proprietäre, objektorientierte Programmiersprache für die Salesforce Platform, ähnlich wie Java. Sie wird verwendet, um benutzerdefinierte Geschäftslogik zu erstellen, Prozesse zu automatisieren und die zentralen CRM-Funktionen über deklarative Tools hinaus zu erweitern. | ## Takeaways Agentforce stellt einen grundlegenden Wandel bei der Arbeit auf Salesforce Platform dar – von der regelbasierten Automatisierung hin zu rationalisierungsbasierten Workflows. Architekten müssen bewusste, fundierte Entscheidungen darüber treffen, wo Agenten hinpassen, wie sie zusammengesetzt sind und was sie orchestrieren, um ihr Potenzial zu entfalten. Die folgenden Grundsätze bieten eine wiederholbare Richtlinie für agentische Entscheidungen. - **Verwenden Sie das richtige Tool für die richtige Aufgabe.** Verwenden Sie die Orchestrierungsdichte auf der Grundlage des Ausführungspfads, des Modalitätsmix und der Zielkomplexität, um die am besten geeignete Lösung zu bestimmen. - Verwenden Sie die **traditionelle Automatisierung** mit Flows und Apex für regelbasierte deterministische Arbeiten, bei denen das Ergebnis vollständig durch einen Satz von Regeln begrenzt und definiert werden kann. Die traditionelle Automatisierung führt zu einem statischen Ausführungspfad, der vorhersehbare und wiederholbare Ergebnisse garantiert und für die Überprüfbarkeit entscheidend ist. Wählen Sie die traditionelle Automatisierung für Aufgaben, die eine strenge Einhaltung und Einhaltung gesetzlicher Vorschriften erfordern. - Verwenden Sie **Agentforce Grid** für Anwendungsfälle für Massenrückschlüsse mit geringer bis mittlerer Orchestrierungskomplexität. Dieses Muster verwendet generative Argumentation in einem einzigen Schritt, um Daten für ein hohes Volumen an CRM-Datensätzen zu klassifizieren, zu bewerten oder zusammenzufassen und so eine Ausführung mit hohem Durchsatz und sofortiger Überprüfbarkeit zu gewährleisten. - Verwenden Sie **Agentforce mit Agentenskript** für Aufgaben mit offenen Zielen, bei denen das gewünschte Ergebnis bekannt ist, der genaue Ausführungspfad jedoch nicht zum Zeitpunkt des Entwurfs angegeben werden kann. Wenden Sie dieses Muster auf Anforderungen an, für die Argumentation über den geführten Determinismus erforderlich ist, um vorhersehbare und rückverfolgbare Ergebnisse zu gewährleisten. - Verwenden Sie **Agentforce Operations**, um gemeinschaftliche Geschäftsprozesse mit AI-fähiger Verwaltung für Lieferketten-Workflows zu optimieren und zu automatisieren. - **Vermeiden Sie die Anwendung von Agenten-Workflows auf Anwendungsfälle mit geringer Orchestrierungsdichte**. Werten Sie Kompromisse zwischen traditioneller und agentischer Automatisierung für funktionale und nicht funktionale Anforderungen aus. Die herkömmliche Automatisierung kann die für Ihren Anwendungsfall erforderliche Skalierung, Zuverlässigkeit und Leistung bieten. - **Verwenden Sie einen Ansatz** vom Typ "Agentenautomatisierungs-Hybrid", bei dem Agentforce und die traditionelle Automatisierung mit Flows und Apex kombiniert werden, wenn diese Synergie einen größeren Nutzen bietet als die Verwendung der Agentenautomatisierung oder der traditionellen Automatisierung allein. ## Entscheidungspunkte Das Salesforce sObject ist traditionell der primäre Einstiegspunkt für die Datensatzautomatisierung. Das System führt eine Logik anhand von Regeln aus, die unmittelbar nach einem Ereignis der Datenmanipulationssprache (DML) wie Einfügen, Aktualisieren oder Löschen beginnt. Um zwischen Tools für eine effiziente [durch Datensätze ausgelöste Automatisierung](/docs/architect/de-de/decision-guides/guide/record-triggered.html) zu wählen, wurde [die Automatisierungsdichte](/docs/architect/de-de/decision-guides/guide/record-triggered#automation-density.html) als Mittel zur Messung der Komplexität des Systems eingeführt, wobei die Automatisierungsmenge, das Datensatzvolumen und die Abhängigkeitsstreuung berücksichtigt werden. Die herkömmliche Automatisierung wird durch die umfangreiche Vorarbeit eingeschränkt, die erforderlich ist, um Daten in ein strukturiertes, schemakonformes und regelbasiertes Konstrukt zu integrieren. Die Agentenautomatisierung aktualisiert die herkömmliche Automatisierung mithilfe von Benutzerabsichten oder unstrukturierten Daten als Eingabe, bei denen Argumente angewendet werden können, um ein gewünschtes Ergebnis zu erzielen. Architekten müssen entscheiden, wann sie probabilistische Argumente für multimodale unstrukturierte Daten verwenden und wann sie geführte, deterministische Workflows erzwingen, um das Risiko unvorhersehbarer Ergebnisse zu minimieren. Wenn sich die Anforderung von der Ausführung regelbasierter Schritte zur Argumentation hin zu Ergebnissen verschiebt, benötigen Architekten ein standardisiertes Framework, um die Argumentationstiefe und die Zielkomplexität der vorgeschlagenen Lösung zu bewerten. ### Orchestrierungsdichte Die Orchestrierungsdichte ist die Maßeinheit für die Komplexität in einem Agenten-Workflow. Drei Faktoren bestimmen die Orchestrierungsdichte: Ausführungspfad, Zielkomplexität und Modalitätsmix. Während die Automatisierungsdichte die physische Komplexität der Regeln und des Volumens des Systems misst, misst die Orchestrierungsdichte die Argumentationskomplexität des Pfads des Agenten zu einem Ziel. Verwenden Sie die Dichte der zusammengesetzten Orchestrierung, um Ihre Designanforderungen auszuwerten und dem Architekturstandard zuzuordnen. - **Ausführungspfad**: Der Grad, in dem der Workflow zum Zeitpunkt des Entwurfs vollständig umrissen und angegeben werden kann. Ein vollständig angegebener Workflow bedeutet, dass der Workflow jede Verzweigung und jedes Ergebnis definiert, was zu einem vorbestimmten Ausführungspfad führt. Ein nicht spezifizierter Workflow weist einen Pfad auf, der während der Laufzeit durch Überlegungen zu Kontextdaten und Anweisungen entstehen kann. - **Zielkomplexität**: Die Anzahl der unterschiedlichen Ergebnisse, Entscheidungspunkte und Pfadvariationen, die der Workflow zur Laufzeit auflösen muss. Ein Workflow mit geringer Komplexität verarbeitet eine einzelne in sich geschlossene Aufgabe mit einem vorbestimmten Ergebnis, während ein Ziel mit hoher Komplexität mehrere Phasen mit konkurrierenden oder in Konflikt stehenden Zielen mit Randfällen umfasst, die zum Zeitpunkt des Designs nicht zu erwarten sind. - **Modalitätsmix**: Der Bereich der Eingabetypen, die ein Workflow verarbeiten muss, und die Ausgabeformulare, die er erstellen muss. Ein Mix mit niedriger Modalität liest CRM-Standardfelder und generiert Datensatzaktualisierungen. Eine mittlere Modalität verwendet eine Kombination aus strukturierten CRM-Feldern und statischen, unstrukturierten Daten wie E-Mail-Nachrichten oder Kundenvorgangsabschriften, um Datensatzaktualisierungen zu erstellen. Ein Mix mit hoher Modalität verwendet dynamische Echtzeit-Streams wie Live-Audio oder Telemetrie und generiert multimodale Ausgaben über mehrere externe Systeme hinweg. ![Framework-Diagramm 'Orchestration Density' (Orchestrierungsdichte), in dem der Ausführungspfad, die Zielkomplexität und die Modalitäts-Mix-Achsen angezeigt werden](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png) ### Faktorsequenzierung Zum Bestimmen der entsprechenden Orchestrierungsdichteebene müssen der Ausführungspfad, die Zielkomplexität und der Modalitätsmix sequenziell ausgewertet werden. Untersuchen Sie zunächst den Ausführungspfad. Wenn ein Pfad vollständig angegeben werden kann, beginnen Sie mit der traditionellen Automatisierung. Die Verwendung einer agentischen Lösung, nur um einen deterministischen Pfad ohne Begründung zu orchestrieren und auszuführen, ist ein Anti-Pattern. Dies führt zu einer Vermehrung von Agenten (übermäßige, nicht verwaltete AI-Agentenvermehrung) und zu Agentenrückgängen (minderwertige, unnötige AI-generierte Ausgabe), was zu schlechten Werterträgen führt. Bewerten Sie bei teilweisen oder nicht spezifizierten Pfaden weiterhin die Zielkomplexität. Wenn die Zielkomplexität genau definiert ist, bestimmte Knoten entlang des Pfads jedoch probabilistische Auswertungen benötigen, sollten Sie ggf. Agenten über Flow oder Apex anrufen, um die spezifische lokalisierte Anforderung zu erfüllen. Wenn für die Schritte im Ausführungspfad eine oder mehrere AI-gesteuerte Anforderungen für eine große Menge an Datensätzen erforderlich sind, sollten Sie stattdessen Agentforce Grid in Betracht ziehen. Raster unterstützt mehrstufige, blattbasierte Workflows über mehrere AI- oder Agentenspalten. Sie eignet sich am besten für die zeilenorientierte Massenausführung. Durch diesen Ansatz wird sichergestellt, dass der Workflow hochleistungsfähig und überprüfbar bleibt und probabilistische Argumente nur dann aufgerufen werden, wenn der Pfad nicht vordefiniert werden kann. Wenn die Komplexität der Ziele mit konkurrierenden Dimensionen zunimmt (z. B. die Ermittlung einer Auszahlung von Versicherungsansprüchen zusammen mit der Betrugserkennung, die Einhaltung von Policen und die Kundenzufriedenheit) und nicht spezifizierte Ausführungspfade, sollten Sie Agentforce mit Agentenskript als geführten Determinismus in Ihrer Automatisierung berücksichtigen. Verwenden Sie MuleSoft Fabric und Agent Broker für unternehmensübergreifende Anwendungsfälle, die Salesforce und Drittanbietersysteme betreffen. Evaluieren Sie abschließend den Modalitätsmix, um die erforderlichen technischen Funktionen wie die multimodale Verbindung oder die spezielle Integration zu identifizieren. Der Modalitätsmix fungiert als Funktionsauswahl und nicht als Dichterechner. Es hilft Ihnen, die Infrastruktur zu bestimmen, die für die Verarbeitung der Eingabe- und Ausgabeform der Lösung erforderlich ist, ohne ihre grundlegende Orchestrierungslogik zu ändern. ### Die Dichteauswahlmatrix Verwenden Sie diese Matrix, um den Architekturstandard für Ihre Agentenautomatisierung zu bestimmen. Wählen Sie den Ansatz aus, der Ihr Automatisierungsproblem löst, um die traditionelle und die Agentenautomatisierung in Einklang zu bringen. - **Traditionelle Automatisierung (geringe Orchestrierungsdichte):** Verwenden Sie die traditionelle Automatisierung, wenn der Prozess durch eine Datensatzänderung ausgelöst wird, die Daten strukturiert sind, die Logik regelbasiert und vordefiniert ist und das Ergebnis vorhersehbar sein muss (z. B. Standardpreisberechnungen oder Erstellung automatischer Aufgaben). - **Agentforce Grid (niedrige bis mittlere Orchestrierungsdichte):** Verwenden Sie Agentforce Grid, wenn AI-Aufgaben in Massenvorgängen über vorhandene Datensätze hinweg verarbeitet werden müssen (fassen Sie beispielsweise die letzten 50 Kundenvorgänge für jeden Account in dieser Liste zusammen, berechnen Sie die Stimmungsbewertung und behalten Sie die Bewertung im Kundenvorgangsfeld bei). - **Hybridorchestrierung (High-Order Augmented Automation):** Verwenden Sie die hybride Orchestrierung, wenn Sie einen komplexen durchgängigen Geschäftsprozess automatisieren (z. B. die Anspruchsverarbeitung oder die Einarbeitung), der die Planungsfunktionen von AI, aber die Transaktionsintegrität von Flow und Apex erfordert. - **Agentforce Agent Script (High Intent Complexity):** Verwenden Sie Agentenskript, wenn der Einstiegspunkt unstrukturiert ist (z. B. Chat, E-Mail und Voice) und die Lösung eine Unterhaltung oder die Fähigkeit erfordert, mehrdeutige Benutzeranforderungen zu verarbeiten. | Dichtestufe | Ausführungspfad | Zielkomplexität | Modalitätsmix | Architektonischer Standard | | :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Niedrig** | Vollständig spezifiziert | **Niedrig:** Eine einzelne enthaltene Aufgabe mit vordefinierten Ergebnissen. | **Einzelne Modalität:** Liest und schreibt strukturierte Salesforce-Objektdatensätze. | Durch einen Datensatz ausgelöste Automatisierung. Wenn der Anwendungsfall mindestens eine Argumentationsaufgabe aufweist, verwenden Sie Agentische Aktionen im Workflow. | | **Niedrig – Mittel** | Vollständig oder teilweise angebbar | **Niedrig:** Reihe von Schritten mit vordefinierten Ergebnissen. | **Gemischte Modalitäten:** Die Eingabe oder Ausgabe kann eine Mischung aus strukturierten und unstrukturierten Daten aufweisen. | Verwenden Sie Agentforce Grid Batch Inferences für Massenaufgaben in vorhandenen Datensätzen mit agentischer Aktion. | | **Mittel** | Vollständig oder teilweise angebbar. Der Ausführungspfad ist vordefiniert, Zwischenschritte müssen jedoch begründet werden. | **Mittel:** Serie von Apex oder Flow-basierten Schritten mit variablen Ergebnissen. | **Gemischte Modalitäten:** Die Eingabe oder Ausgabe kann eine Mischung aus strukturierten und unstrukturierten Daten mit geringem Volumen aufweisen. | Hybrid (Agentforce + Apex / Flow): Verwenden Sie Agentforce für Argumentation und Planung mit hoher Dichte, Agentenskript für geführten Determinismus und Apex/Flow für die Orchestrierung. | | **Hoch** | Teilweise oder nicht spezifizierbar. Das Ziel ist vordefiniert, Zwischenschritte erfordern jedoch Laufzeitkontext und Benutzerabsicht. | **Hoch:** Mehrere konkurrierende Ziele mit hohem Argumentationsbedarf erfordern deterministische Ergebnisse. | **Gemischte Modalitäten:** Die Eingabe oder Ausgabe kann eine Mischung aus strukturierten und unstrukturierten Daten mit hohem Volumen aufweisen, die in Echtzeit eingehen. | Verwenden Sie das Agentenskript, um deterministische Steuerung und Argumentation in Einklang zu bringen. Verwenden Sie MuleSoft Agent Fabric für Drittanbieter-MCPs oder A2A für die komplexe Zusammenarbeit mit mehreren Agenten. | ## Produktvergleich | Kapazität | Traditionelle Automatisierung (Flow/Apex) | Agentforce Raster | Agentforce | Agentforce mit Agentenskript | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Logiktyp und Determinismus** | **Deterministisch:** Verwendet eine feste Wenn-dann-anders-Logik. Der Ausführungspfad ist basierend auf dem Datensatzstatus zu 100 % vorhersehbar. | **Gemischt:** Deterministisch über strukturierte Schritte, während einzelne AI-Schritte probabilistisch sein können. | **Probabilistisch:** Verwendet Multiturn-Überlegungen, um den besten Weg zu einem Ziel zu bestimmen. | **Geführter Determinismus:** Verwendet Überlegungen zum Planen des Pfads und ermöglicht die Ausführung für deterministische Knotenpfade. | | **Liefergeschwindigkeit** | **Empfohlen (Flow):** Visuelle Tools ermöglichen das schnelle Erstellen von durch einen Datensatz ausgelöster Logik ohne Code. | **Empfohlen für die Automatisierung von sich wiederholender AI:** Schnellste Möglichkeit, AI-Logik auf vorhandene Datensatzgruppen anzuwenden, ohne neue Flows zu erstellen. | **Empfohlen:** Zur Konfiguration von Unteragenten (zuvor Themen), Anweisungen und Fertigkeitszuordnung für eine bestimmte Domäne oder ein bestimmtes Problem. | **Empfohlen:** Für die erweiterte Zuordnung von zustandsbasierten Diagrammen und Kantenlogik. | | **Eingabemodalität** | **Empfohlen nur für strukturierte:** Beschränkt auf CRM-Felder und zugehörige Datensatzsammlungen. | **Empfohlen für "Semistrukturiert":** Verarbeitet Massentext (Beschreibungen, Abschriften) aus Datensatzfeldern. | **Empfohlen für Multimodal:** Verarbeitet natürliche Sprache, Stimme und Sehvermögen (unstrukturierte Daten). | **Für hohe Dichte empfohlen:** Synthesiert multimodale Eingaben mit Echtzeit-Systemstatusdaten. | | **Begründungstiefe (Planung)** | **Nicht verfügbar:** Logik ist zwingend erforderlich. Sie kann Schritte nicht dynamisch "denken" oder planen. Daten können jedoch an Agenten gesendet werden. | **Niedrig:** Rückschluss in einem Schritt, der auf einen Datensatz angewendet wird (Batch-AI). | **Mittel/Hoch:** Verwendet Argumentationsschleifen (Reason-Act-Observe), um komplexe Intents aufzulösen. | **Geregelt:** Die Argumentation beschränkt sich auf die Navigation in einem vordefinierten Diagramm der Geschäftsstatus. | | **Modularität und Wiederverwendbarkeit** | **Empfohlen:** Standardmäßig modular über Subflows und Apex Klassen. | **Begrenzt:** Die Logik ist in der Regel an die jeweilige Rasterzeile gebunden. Spalten-Setups und Workflows mit Vorlagen können im gesamten Zeilensatz wiederverwendet werden. | **Verfügbar:** Fertigkeiten (Flows/Apex) werden in verschiedenen Unteragenten (zuvor Themen) und verbundenen Agenten wiederverwendet. | **Empfohlen:** Knoten im Agentendiagramm sind diskrete, wiederverwendbare Funktionseinheiten. | | **Transaktions- und DML-Steuerung** | **Empfohlen (Apex):** Vollständige Kontrolle über Speicherpunkte, Rollbacks und Massenvorgänge. | **Verfügbar:** Jede Zeile wird unabhängig verarbeitet, sodass der Ausführungsumfang pro Datensatz gilt. | **Begrenzt:** Aktionen werden als einzelne, entkoppelte Schritte in einer Sitzung ausgeführt. | **Empfohlen:** Verwendet Flow- und Apex-Knoten, die als deterministische Anker für alle DML dienen. Die Unterstützung der verteilten Transaktionssteuerung für Agenten ist begrenzt. | | **Mehrdeutigkeitsverarbeitung** | **Nicht verfügbar:** Erfordert vordefinierte Pfade. Unerwartete Eingaben führen zu Fehlern oder statischen Fehlern. | **Begrenzt:** Die Ausgabequalität hängt von der Kontextbildung der Eingabeaufforderung ab. Der Workflow kann nicht interaktiv um Klärung bitten. | **Empfohlen:** Verarbeitet "unbekannte" Zustände, indem Fragen gestellt oder alternative Fertigkeiten ausgewählt werden. | **Verfügbar:** Verwendet "Fallback-Knoten", um Argumentationsfehler oder Prozess-Timeouts zu verwalten. | | **Sichtbarkeit und Governance** | **Empfohlen:** Der Flow-Auslöser-Explorer bietet eine visuelle Zuordnung aller durch einen Datensatz ausgelösten Logik. | **Verfügbar:** Die rasterbasierte Benutzeroberfläche bietet klare Einblicke in Ergebnisse auf Zeilenebene und unterstützt die Überprüfbarkeit von Ausgaben. | **Verfügbar:** Überwachungsprotokolle bieten Transparenz darüber, wie der Agent Entscheidungen getroffen hat. | **Fachwissen erforderlich:** Erfordert die Überwachung der Diagrammtraversierung und der LLM-Rückschlussprotokolle. | | **Leistung und Skalierung** | **Empfohlene** Optimierung für die synchrone Datensatzverarbeitung mit hohem Volumen. | **Empfohlen** Verarbeitet AI-Aufgaben in großen Datenvolumen effizient. | **Latenzabhängig** von der Rückschlusszeit; für Massenaktualisierungen mit hoher Dichte ungeeignet. | **Mittel** Geeignet für komplexe langfristige Aufgaben, hat jedoch einen höheren Overhead. | ## Anwendungsfälle Diese Tabelle enthält allgemeine Empfehlungen für die am besten geeigneten Anwendungen. | Anwendungsfall | Beschreibung | Best-Fit | Begründung | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Datensatzverarbeitung** | Die Automatisierung, die durch ein DML-Ereignis in einem strukturierten Salesforce-Objekt ausgelöst wird, bei dem jede Verzweigung und jedes Ergebnis zum Zeitpunkt des Entwurfs vollständig definiert werden kann. | Verwenden Sie "Durch Datensatz ausgelöster Flow". Dies ist eine traditionelle Automatisierung mit geringer Dichte. | Geringe Orchestrierungsdichte. Einzelne Modalität (strukturierte CRM-Felder) und ein einzelnes enthaltenes Ziel mit einem vorhersehbaren, überprüfbaren Ausführungspfad. | | **Transaktionssteuerung mit komplexer Logik** | Automatisierung, die Speicherpunkte, Rollbacks, Teil-Commits oder massensichere Datenmanipulationen über große Datensatzvolumen hinweg erfordert. | Verwenden Sie Apex für die traditionelle deterministische Automatisierung mit geringer Dichte. | Geringe Orchestrierungsdichte. Apex bietet vollständige Kontrolle über die Transaktionsintegrität, die Deduplizierung teurer Berechnungen und die Zwischenspeicherung auf Plattformebene – Funktionen, die in Flow nicht verfügbar sind. | | **Mittelkomplexe Logik innerhalb eines strukturierten Prozesses** | Automatisierung, bei der der Gesamtprozess regelbasiert ist, einzelne Schritte jedoch Berechnungen oder Datenänderungen erfordern, die über die deklarativen Funktionen hinausgehen. | Verwenden Sie Flow mit aufrufbarem Apex für deterministische Logik mit geringer Dichte. | Geringe Orchestrierungsdichte. Flow fungiert als Orchestrierungsebene. Aufrufbares Apex kapselt hochkomplexe Vorgänge als wiederverwendbare, massensichere Komponenten. | | **Geplante und zeitliche Verarbeitung** | Automatisierung, die zu einem dynamisch berechneten zukünftigen Datum in Bezug auf ein Datensatzereignis ausgeführt werden muss. | Verwenden Sie die traditionelle Automatisierung (durch Datensätze ausgelöste Flows) für die deterministische Verarbeitung mit geringer Dichte. | Geringe Orchestrierungsdichte. [Flow-geplante Pfade](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5) bieten eine automatische Planung, Stornierung und Neuplanung, wenn sich Datensatzdaten ändern, was in Apex-Auslösern nicht nativ verfügbar ist. | | **Rückschluss auf Massendatensätze** | Wenden Sie einen einzelnen AI-Überlegungenschritt einheitlich auf einen großen Satz vorhandener Datensätze an, um eine Klassifizierung, Zusammenfassung oder Bewertung zu generieren. | Verwenden Sie "Agentforce Grid" für Batch-Rückschlüsse und zum Verwenden von sich wiederholenden Agentenfunktionen in großem Umfang. | Mittlere Orchestrierungsdichte. Batch-Rückschluss mit einzelner Modalität im Maßstab: Der Agent liest strukturierte Datensatzfelder und schreibt eine einheitliche Ausgabe in jeden Datensatz zurück. Geringe Zielkomplexität mit einem sich wiederholenden Rückschlussmuster. | | **Unstrukturierte Eingabeauflösung** | Automatisierung, bei der es sich bei dem Eingangspunkt um eine Anforderung, E-Mail oder Unterhaltung mit natürlicher Sprache handelt, die interpretiert, klassifiziert und durch Argumentation aufgelöst werden muss. | Verwenden Sie Agentforce für die unstrukturierte Eingabeauflösung mit mittlerer Dichte. | Mittlere Orchestrierungsdichte. Gemischte Modalität: Der Agent verwendet unstrukturierte Unterhaltungseingaben und erstellt dann Textantworten oder strukturierte Datensatzaktualisierungen. Für das Ziel muss der Benutzer-Intent über eine begrenzte Reihe von Ergebnissen hinweg aufgelöst werden. | | **Mittelkomplexe Logik innerhalb eines probabilistischen Prozesses** | Automatisierung, bei der der Gesamtprozess regelbasiert ist, für einzelne Schritte jedoch AI-Funktionen wie Zusammenfassung oder RAG-Abruf erforderlich sind. | Verwenden Sie "Flow mit aufrufbarem Apex" und "Aufforderungsvorlagen" für deterministische Prozesse mit geringer Dichte, die AI-Funktionen erfordern. | Mittlere Orchestrierungsdichte. Flow fungiert als Orchestrierungsebene, während [Aufforderungsvorlagen](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api), [Agentforce Serviceagent und Agentforce Employee](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5) als aufrufbare Aktionen angezeigt werden. | | **Geführte Prozessorchestrierung** | Automatisierung in mehreren Schritten, bei der der Abschluss einer Aktion zusätzliche Aktionen auslöst | Verwenden Sie [Agentenskript mit Aktionen](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining) für nicht angegebene Ausführungspfade mit hoher Dichte, die eine geführte Prozessorchestrierung erfordern. | Hohe Orchestrierungsdichte – gemischte Modalität zwischen Eingabe und Ausgabe. Konkurrierende Ergebnisse und Edge-Kundenvorgänge, die zum Zeitpunkt der Entwicklung nicht vollständig antizipiert werden können. Das Agentenskript bietet geführten Determinismus. | | **Systemübergreifende Prozessorchestrierung** | Automatisierung zur Koordinierung eines aus mehreren Schritten bestehenden Geschäftsprozesses über mehrere Backend-Systeme hinweg, bei denen kein einzelnes System Inhaber des durchgängigen Flows ist | Verwenden Sie die MuleSoft-Prozess-API mit Agent Broker für die systemübergreifende Orchestrierung mittlerer bis hoher Dichte. | Hohe Orchestrierungsdichte: Prozess-APIs kapseln komplexe Geschäftslogik aus mehreren Schritten, sodass Agenten die Orchestrierung hinter Vorgängen wie Auftragsverarbeitung oder Inventarprüfungen nicht verstehen müssen. Der [Agentenmakler](https://www.mulesoft.com/ai/agent-broker) sequenziert die erforderlichen Agenten und Tools dynamisch und ruft sie über ein einziges Ziel in natürlicher Sprache auf. | | **Backend-Systemabstraktion** | Orchestrierung, bei der Agenten mit veralteten Systemen, Datenbanken oder SaaS-Drittanbieterplattformen ohne native Agentforce-Konnektivität interagieren müssen. | Verwenden Sie MuleSoft mit dem MCP-Konnektor, um ältere Systeme zu umschließen und Modellkontext bereitzustellen. | Mittlere Orchestrierungsdichte. System-APIs bieten eine sichere, abstrahierte Schnittstelle zu Datensatzsystemen und stellen sicher, dass Agenten-Workflows von der Backend-Komplexität entkoppelt sind. Der MCP-Konnektor wandelt MuleSoft-Anwendungen in MCP-kompatible Server um, um sie sofort zu finden und aufzurufen. | | **Dokumentverarbeitung mit hohem Volumen und Verarbeitung von Ausnahmen** | Automatisierung, die eingehende strukturierte und halbstrukturierte Dokumente liest, interpretiert und mit vorhandenen Datensätzen abgleicht – Verarbeitung von Abweichungen, Teilübereinstimmungen und Ausnahmen mit angemessenen manuellen Eingriffen. | Verwenden Sie Agentforce Operations für die Dokumentverarbeitung mit mittlerer Dichte und Intent-gesteuertem hohem Volumen. | Mittlere Orchestrierungsdichte mit halbstrukturierter Eingabemodalität. Zielkomplexität, die durch Abgleichsregeln, Ausnahmepfade und Genehmigungsschwellenwerte pro Dokument gesteuert wird. Erfordert Überlegungen pro Datensatz und keine einheitliche Rückschlussfolgerung in einer Runde. | | **Anbieterübergreifende Orchestrierung mehrerer Agenten** | Die Automatisierung erfordert die Zusammenarbeit zwischen spezialisierten Agenten, die auf verschiedenen Plattformen oder Anbietern basieren. | Verwenden Sie MuleSoft mit dem A2A-Konnektor und Agent Fabric für die Orchestrierung mehrerer Agenten in verschiedenen Systemen. | Mittlere bis hohe Orchestrierungsdichte. Der A2A-Konnektor ermöglicht Workflows für mehrere Agenten mit Peer-zu-Peer-Agenten, unabhängig davon, wo die einzelnen Agenten erstellt oder gehostet werden. | | **Konvertierung unstrukturierter Dokumente in Workflows** | Automatisierung, bei der in unstrukturierten Quellen definierte betriebliche Prozesse (SOPs, Lieferantenregeldokumente oder Prozessdiagramme) ohne manuelle Codierung in ausführbare agentische Workflows konvertiert werden müssen. | Verwenden Sie Agentforce Operations für die Konvertierung unstrukturierter Dokumente mit hoher Dichte in Workflows. | Hohe Dichte mit einem hohen Modalitätsmix bei Eingabe. Erfasst PDFs, Word-Dokumente und bildbasierte Diagramme. Die Zielkomplexität wird durch den Umfang und die Verzweigung des aufgenommenen Prozesses bestimmt. Der Ausführungspfad kann zum Zeitpunkt des Entwurfs nicht angegeben werden. | | **Mehrparteienorchestrierung** | Automatisierung bei der koordinierten Einarbeitung externer Personen – Erfassung der erforderlichen Daten, Überprüfung der Einhaltung, Verwaltung von Genehmigungen und Aktualisierung von Datensatzsystemen über viele gleichzeitige Einarbeitungsverfolgungen hinweg. | Verwenden Sie Agentforce Operations für die Orchestrierung von mehreren beteiligten Personen mit mittlerer bis hoher Dichte. | Mehrere voneinander abhängige Überprüfungs- und Genehmigungsschritte müssen nacheinander aufgelöst werden, bevor die Einarbeitung abgeschlossen wird. Der Modalitätsmix umfasst strukturierte Datensätze, unstrukturierte Dokumente und Kommunikation mit externen Parteien. | | **Prognose der Vermögenswertintervention** | Automatisierung, bei der ein Prognosemodul Echtzeit-Telemetrie aufnimmt, um drohende Ausfallbedingungen zu identifizieren, und eine koordinierte Back-Office-Antwort in mehreren Schritten auslöst. | Verwenden Sie Agentforce Operations und Agentforce für die Fertigung für die Intervention von Vermögenswerten mit hoher Dichte. | Data Cloud verarbeitet die IoT-Telemetrie und Anomalieerkennung mit hoher Modalität. Anschließend orchestriert Agentforce Operations den Back-Office-Workflow für mittlere Modalitäten – die Verwaltung von Außendienstdatensätzen, Inventardaten und Kundenkommunikation – und löst den Prozess durchgängig auf. | | **Kommunikationsverwaltung für Lieferanten in großem Umfang** | Die Automatisierung verwaltet fortlaufende strukturierte und halbstrukturierte Kommunikation über einen großen Lieferantenstamm hinweg – einschließlich Auftragsbestätigungen, Lieferdatumsänderungen und Ausnahmebenachrichtigungen. | Verwenden Sie Agentforce Operations for Batch Inferences (Agentforce-Vorgänge für Batch-Rückschlüsse) für eine Kommunikationsverwaltung für Lieferanten mittlerer Dichte. | Verwenden Sie Agentforce Grid für die Batch-Verarbeitung, wenn die Kommunikation lieferantenübergreifend einheitlich ist. Wenn Antworten kontextbezogene Überlegungen pro Lieferantenbeziehung erfordern, eskalieren Sie mit Agentforce Operations auf mittlere Dichte. | | **Leadverwaltung (Hochgeschwindigkeits-, intelligente Weiterleitung)** | Automatisierung, die Echtzeit-Marketingantworten aufnimmt, AI-Bewertungen und Data Cloud-Anreicherungen zur Qualifizierung verwendet und Flows für die schnelle, intelligente Zuweisung und Weiterleitung hochwertiger Leads an das entsprechende Vertriebsteam verwendet. | Verwenden Sie die traditionelle Automatisierung (Flow) + Data Cloud und AI für die intelligente High-Density-Leadweiterleitung. | Erfordert eine hohe Geschwindigkeit (Geschwindigkeit bis Lead < 1 Minute) und eine komplexe, datengesteuerte Weiterleitung basierend auf der AI-Leadbewertung, der Auftragsebene und dem Aktivitätsverlauf. Verwendet Flows für schnelle, deterministische Zuweisungslogik, ergänzt durch probabilistische AI und Data Cloud für die Leadqualifizierung und -anreicherung. | | **Lead Nurturing (Leadpflege**) | Fördert Leads mit geringer Bewertung, bis sie für eine Vertriebsunterhaltung bereit sind. | Verwenden Sie den Lead-Pflegeagenten, um Leads mit geringer Qualität für die Automatisierung mittlerer bis hoher Dichte anzusprechen und zu verbessern. | Sendet personalisierte Multi-Touch-E-Mails, die auf Leaddaten und Kundenerfolgsgeschichten basieren. Sie verarbeitet E-Mail-Antworten und verwendet Flow für die Übergabe. | | **Qualifizierung eingehender Leads** | Qualifiziert und pflegt eingehende Leads mit höherer Bewertung autonom. | Verwenden Sie den Lead-Pflegeagenten, um Leads zu qualifizieren und einzubinden. | Führt ausgehende Multi-Touch-E-Mails, Besprechungsbuchungen, Fragen und Antworten zu Produkten und Widerspruchsbearbeitungen aus. Sie kann im Modus "Als Verkäufer senden" ausgeführt werden und sendet E-Mails über den zugewiesenen Leadinhaber. | ## Anwendungsfallzuordnung ![Diagramm zur Kundenvorgangszuordnung mit verschiedenen Automatisierungsszenarien über Orchestrierungsdichteebenen hinweg](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png) ## Nicht funktionale Überlegungen **Latenz** Synchrone durch einen Datensatz ausgelöste Flows werden innerhalb der Plattformtransaktion ausgeführt und in Millisekunden abgeschlossen. Die Agentforce-Rückschlusszeit ist vom Atlas Reasoning Engine abhängig und wird mit der Tiefe der Argumentation und der Modalitätskomplexität skaliert. Agentforce eignet sich nicht für die synchrone Datensatzverarbeitung mit hohem Volumen, wenn die Latenz eine primäre Einschränkung ist. **Kosten** Die Argumentationskosten eines Agenten-Workflows müssen mit dem Geschäftswert des Ergebnisses verglichen werden. Bei Aufgaben mit hohem Volumen und geringer Orchestrierungsdichte, bei denen ein deterministischer Pfad vorhanden ist, ist die herkömmliche Automatisierung oder das Agentforce Grid möglicherweise wirtschaftlicher als ein durchgängiger agentischer Workflow. Stellen Sie sicher, dass das Design das richtige Wiederholungsmuster mit expliziten Obergrenzen für die maximale Wiederholung und Unterbrechungen berücksichtigt. Diese Leitplanke begrenzt das Risiko der Kostenüberschreitung bei der Massenverarbeitung. **Obergrenzen** Werten Sie Agenten-Workflows mit hohem Volumen im Vergleich zu täglichen Plattformobergrenzen für die asynchrone Ausführung aus. Agentforce Grid-Batchvorgänge folgen den standardmäßigen Plattformtransaktionsobergrenzen. Beachten Sie bei der Automatisierung von Salesforce-Objekten die tägliche Gesamtanzahl der DML-Vorgänge, da Salesforce die Verwaltung gemeinsamer Ressourcen in einer Umgebung mit mehreren Mandanten und [Obergrenzen](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm?_ga=2.244979463.387753096.1774889755-1655953164.1772207150) erzwingt, um zu verhindern, dass Automatisierungen gemeinsam genutzte Ressourcen monopolisieren. **Überprüfbarkeit und Compliance** Die traditionelle Automatisierung erstellt vollständig überprüfbare Ausführungsprotokolle über Flow-Auslöser-Explorer und Apex Protokolle. Agentforce durchgängige oder hybride Muster erzeugen Argumentationsprotokolle, die Transparenz in die Entscheidungsfindung von Agenten bieten, deren Interpretation jedoch Fachwissen erfordert. Der geführte Determinismus über das Agentenskript ist das empfohlene Muster für regulierte Branchen, in denen die vollständige Überprüfbarkeit der Ausführung eine Compliance-Anforderung ist. **Eskalation** Agentische Workflows, die mit hoher Dichte ausgeführt werden, sollten explizite menschliche Genehmigungs- oder Eskalationstores für Aktionen mit irreversiblen Folgen wie Finanztransaktionen, behördlichen Einreichungen oder Lieferantenverpflichtungen enthalten. Bedingte Steuerelemente für Agentenskripts bieten den Mechanismus zum deterministischen Erzwingen dieser Gates in einem ansonsten agentenbasierten Workflow. ## Verwandte bewährte Vorgehensweisen **Priorisieren Sie die Einfachheit Ihres Orchestrierungsdesigns.** Beginnen Sie mit der minimalen Orchestrierungsebene, mit der das Ziel erreicht werden kann, validieren Sie es unter realer Last und wiederholen Sie es. Jeder zusätzliche Agent, jede Übergabe oder Abhängigkeit in Ihrer Kette führt zu einer neuen Oberfläche, die zu inkonsistentem Verhalten führen kann. Beginnen Sie in Ihrem angebbaren Ausführungspfad an Knoten, an denen Argumentation erforderlich ist, mit dem Einbetten eines Agenten. Befolgen Sie die bewährten Vorgehensweisen zum Erstellen von Agenten in Agentforce. Vermeiden Sie es, zahlreiche Unteragenten (zuvor "Themen") zu packen und Anweisungen niemals aufzublähen. Agenten, die in Automatisierungsanwendungsfällen bereitgestellt werden, können es sich leisten, schlank zu sein, da sie nicht die einzige Oberfläche sind. Wählen Sie den richtigen Primitiven für die Verkettung aus. Ein Orchestrierungsmuster (Delegationsmuster) hat eine strengere Kontrolle über die Ausführungsreihenfolge und kann Teilaufgaben an Spezialisten delegieren. Vermeiden Sie choreographierte Muster (Übergabemuster). Wenn Sie ein Übergabedesign implementieren müssen, geben Sie dem empfangenden Agenten das Ziel, den Kontext und den Status an, damit er globale und nicht lokale Ziele optimieren kann. **Vermeiden Sie Aktionen oder umfangreiche Tools**. Aktionen sind der Ort, an dem die Argumentation der Agenten realisiert wird, und ihr Design bestimmt, ob sie zuverlässige Ergebnisse oder Fehler zur Folge haben. Jede Aktion muss eine strukturierte, beobachtbare Antwort zurückgeben, mit der der AI-Agent die nächste Unterhaltung planen kann. Wenn mehrere Aktionen (und unterschiedliche Ausgabekonstrukte) dieselbe Aufgabe ausführen, ist der Agent nicht mehr in der Lage, das richtige Tool für den Auftrag zu finden oder auszuwählen. Es kann dazu führen, dass der Agent Nuancen übersieht. Wenn sich Aktionsdefinitionen überschneiden, besteht das Risiko einer falschen Klassifizierung. Stellen Sie sicher, dass Ihre Aktionsbibliothek überprüft, versioniert und mit dem Umfang "Unteragent (zuvor Thema)" konform ist. **Definieren Sie beobachtbare Ziele.** Definieren Sie das Ziel als beobachtbares Ergebnis und nicht nur als Verfahren. Ein vages Ziel lädt zur Agentenabwanderung ein. Vergrößerung um einen angebbaren Ausführungspfad. Verwenden Sie das Agentendiagramm mit hybrider Argumentation, um das Ziel als Diagrammknoten mit explizitem Status zu modellieren. Die Laufzeit verfolgt die aktuelle Position des Agenten im Workflow und stellt sie nach tangentialen Eingaben wieder her. Das Ziel geht nicht verloren, wenn er zusätzliche Informationen im Kontextfenster erhält. **Testen und auswerten**. Implementieren Sie ein zuverlässiges Test- und Evaluierungs-Framework, um die Argumentation probabilistischer Knoten und die Ausgabe von Agentenautomatisierungen zu validieren. Überprüfen Sie Ausführungspfade mit einem erwarteten Ergebnispfad, um sicherzustellen, dass das Modell das richtige Ergebnis erzielt. Verhindern Sie stille Fehler, wenn ein Agent fälschlicherweise einen Erfolg meldet oder in eine Endlosschleife oder eine nicht behebbare Schleife gerät, indem Sie die Ergebnisse in Ausführungsschritten bestätigen. Verwenden Sie [die Sitzungsverfolgung](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5), um Turn-by-Turn-Interaktionen, Ausführungen des Argumentationsmoduls, Aktionen, Eingabeaufforderungen und Gateway-Ausgaben, Fehlermeldungen und endgültige Antworten zu untersuchen. ## Ressourcen
Agentforce Traditionelle Automatisierung Integration
**Über den Autor** Arvind Palaniswamy ist ein Software-Engineering-Architekt im Büro des Chefarchitekten "Well-Architected Team". Er mag es, komplexe Systeme in ihren einfachsten Formen mit ersten Prinzipien zu erstellen. Er versteht Engineering, Operations und Business durch jahrzehntelange Erfahrung und MS/MBA(Kellogg) Ausbildung. # Data 360-Bereitstellung Salesforce Data 360 ist eine auf [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/) basierende Datenplattform, die Salesforce- und externe Daten in einer klaren, vollständigen und vertrauenswürdigen 360-Grad-Ansicht jedes Kunden oder Accounts vereinheitlicht. Unternehmen betreiben aufgrund von Fusionen und Übernahmen, regionalen Vorgängen, Funktionstrennung oder historischen Gründen oft mehrere Salesforce-Organisationen. Architekten müssen verschiedene Entscheidungen zu Data 360 treffen, die sich alle auf die Verwaltung, Compliance, Kosten, Latenz und die Skalierbarkeit von AI und organisationsübergreifenden Plattformfunktionen auswirken. ## Leitfadenübersicht Dieser Leitfaden bietet einen Rahmen für Bereitstellungsentscheidungen mit Data 360\. Zu diesen Entscheidungen zählen: - Auswählen einer einzelnen Startseitenorganisation im Vergleich zu einer Konfiguration mit mehreren Organisationen - Bereitstellen mehrerer unabhängiger Data 360-Instanzen - Verwenden von Data Cloud One zum Vereinheitlichen von Organisationen in einer einzelnen Instanz - Zusammenarbeit zwischen unabhängigen Data 360-Instanzen, die die Datenfreigabe zwischen Data 360-Organisationen verwenden Data 360 wird automatisch in jeder Produktionsorganisation bereitgestellt, die eine Data 360-Lizenz erhält. Data Cloud One ist die Multi-Organisations-Konnektivitätsarchitektur von Salesforce, die es einer einzelnen Startseite ermöglicht, die Data 360-Instanz zu hosten, während sich andere Salesforce-Organisationen als Begleitorganisationen verbinden. Die Entscheidung, welche Organisation über die Data 360-Lizenz verfügt und somit zu einer Data 360-Startorganisation wird, ist eine wichtige architektonische Entscheidung mit langfristigen Konsequenzen. Die Bereitstellung von Salesforce Data 360 ist eine grundlegende architektonische Entscheidung. Sie bestimmt, wie das Unternehmen Kundendaten vereinheitlicht, Unternehmensführung erzwingt und wichtige Plattformfunktionen aktiviert, insbesondere AI, Agentforce und Analysen in der gesamten Organisation. Durch die Verankerung eines Clusters von Organisationen an einer einzelnen Data 360-Datei erhalten Sie ein einheitliches Datenmodell, eine zentralisierte Verwaltung und die Bereitschaft für unternehmensweite AI. Begleitorganisationen können auf freigegebene Metadaten und Funktionen zugreifen, als wären die Daten lokal. Im Gegensatz dazu sind mehrere unabhängige Data 360-Instanzen geeignet, wenn behördliche, Compliance- oder Autonomieanforderungen die Zentralisierung verhindern. Die Datenfreigabe zwischen Data 360-Organisationen ermöglicht eine selektive Zusammenarbeit ohne Kopieren zwischen diesen Instanzen. Diese Entscheidung beeinflusst, wer die Datenverwaltung steuert, wo sich Daten befinden, wie Plattformfunktionen aktiviert werden und wie reibungslos künftige Integrationen und AI-Initiativen skaliert werden können. Selbst für Organisationen, die derzeit nicht über Data 360 verfügen, kann es wichtig sein, ihre Architekturen zukunftssicher zu gestalten, indem eine Strategie für das Hinzufügen von Data 360-Zugriff entwickelt wird. Salesforce-Funktionen in Vertrieb, Service, Marketing, Commerce, Branchen und Agentforce basieren zunehmend auf Data 360\. Organisationen, die diese Plattformfunktionen verwenden möchten, müssen ihre eigenen Data 360 bereitstellen oder sich als Begleitorganisationen mit einer freigegebenen Data 360 verbinden. Dieser Leitfaden hilft Architekten, eine Bereitstellungsstrategie zu entwickeln, die Einfachheit, unternehmensweite Konsistenz, Compliance und Skalierbarkeit in Einklang bringt und sicherstellt, dass die Organisation Data 360 für Customer 360, AI und plattformübergreifende Innovationen sicher nutzen kann. Verwenden Sie diese Anleitung, um zu bestimmen, welche Organisationen Data 360 benötigen und ob Data Cloud One oder die Datenfreigabe zwischen Data 360-Organisationen verwendet werden soll. Diese Strategie schafft eine solide Grundlage für eine Data 360-zentrierte Zukunft. ## Produkte im Umfang
Salesforce Platform-Logo Salesforce Data 360 ist die hyperskalierbare Echtzeit-Datenplattform von Salesforce, die Daten aus beliebigen Quellen (CRM, Web, Mobilgeräten oder externen Data Lakes) in einem einzigen handlungsrelevanten Kundenprofil harmonisiert und vereinheitlicht. Als wichtige Komponente der Customer 360 Platform unterstützt sie AI, Analysen und personalisierte Erfahrungen in Vertrieb, Service und Marketing.
## Takeaways - **Jede Organisation sollte den Zugriff auf eine Data 360-Instanz planen.** Jede Organisation muss entweder eine Data 360-Startorganisation hosten oder eine Begleitorganisation sein, die über Data Cloud One verbunden ist. - **Denken Sie unternehmensweit, nicht organisationsübergreifend.** Vermeiden Sie einseitige Branchenentscheidungen, die isoliert getroffen werden. Idealerweise sollte eine Unternehmensarchitektur oder ein Datenverwaltungsrat gemeinsam über die Bereitstellungsstrategie entscheiden. Prognostizieren Sie immer zukünftige AI- und Analyseanforderungen, die von breiten, vereinheitlichten Datensets abhängen. - **Planen Sie Governance und Eigenverantwortung frühzeitig.** Legen Sie fest, ob Data 360 zentral (Exzellenzcenter-Modell) oder an Geschäftsbereiche delegiert werden soll. Definieren Sie Rollen für Administratoren, Sicherheitsteams und Compliance-Leads. Vermeiden Sie Mehrdeutigkeiten, da unklare Inhaberschaft problematisch sein kann. - **Zur Erinnerung: Die Bereitstellung ist an eine Lizenzierung gebunden.** Die Organisation, in der die Data 360-Lizenz erworben wird, bestimmt, wo Data 360 bereitgestellt wird, und der Standort dieser Organisation bestimmt die Region. - **Kennen Sie die Überlegungen zur Unterstützung von Datenquellen.** Achten Sie genau darauf, welche Regionen für verschiedene öffentliche Clouds und Zero-Copy-Datenquellen unterstützt werden. Ermitteln Sie außerdem, ob Private Connect für Ihren Sicherheitsstatus erforderlich ist, um eine Verbindung mit diesen Datenquellen herzustellen, und ob regions- oder regionsübergreifende Verbindungen unterstützt werden. - **Bereitstellung basierend darauf, ob Sie über eine Einzelorganisation oder mehrere Organisationen verfügen.** Stellen Sie Data 360 für Kunden mit einer einzelnen Organisation in Ihrer vorhandenen Produktionsorganisation bereit, um die schnellste Wertschöpfungszeit zu erzielen. Minimieren Sie für Kunden mit mehreren Organisationen die Komplexität, indem Sie möglichst wenige Data 360-Instanzen erstellen, idealerweise mithilfe der Konfiguration von Data Cloud One. - **Verwenden Sie** **mehrere Data 360-Instanzen nur bei Bedarf.** Mehrere Instanzen sollten nur verwendet werden, wenn dies aufgrund von Compliance, Residenz oder Organisationsautonomie erforderlich ist. Verwenden Sie in diesen Fällen die [Datenfreigabe](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5) zwischen Data 360-Organisationen, um eine sichere Zusammenarbeit zu ermöglichen. - **Setzen Sie die Datenfreigabe zwischen Data 360-Organisationen für die Zusammenarbeit ein, nicht für benutzerdefinierte ETL-Pipelines.** Geben Sie bestimmte Objekte (DMOs, berechnete Statistiken, Segmente) über Datenfreigaben frei. Denken Sie daran, dass Tags nicht freigegeben werden und der Verbrauch der Quellorganisation in Rechnung gestellt wird. - **Kurze Abkürzungen vermeiden.** Erstellen Sie nicht mehrere Data 360-Organisationen für Proof of Concepts (POCs) ohne einen langfristigen Plan. Stimmen Sie Pilotprogramme und frühe Bereitstellungen auf Ihre unternehmensweite Bereitstellungsstrategie ab. ## Entscheidungspunkte Werten Sie jede Bereitstellungsentscheidung (Auswahl zwischen Data Cloud One, Datenfreigabe zwischen Data 360-Organisationen oder Bezeichnung der Startseite) anhand dieser übergreifenden Überlegungen aus.
Überlegung Warum es wichtig ist Beispielszenarien
Datenresidenz und Compliance Legt fest, wo Daten gespeichert und verarbeitet werden. Regulatorische Regeln können bestimmte Regionen oder mehrere Instanzen erfordern. Eine globale Bank stellt einen Data 360-Mandanten in einer Salesforce-Organisation mit Standort in Frankfurt zur Einhaltung der DSGVO bereit. Sie stellen einen weiteren Mandanten in einer Organisation in Virginia für ihre US-Division bereit.
Governance und Sicherheit Identifizieren Sie einen Administrator und die Inhaberschaft von Data 360, einschließlich Richtlinienverwaltung und Delegierungsstrategien. Ein multinationaler Konzern mit starker zentraler IT erstellt eine dedizierte Heimorganisation, die von einem Exzellenzzentrum verwaltet wird.
Autonomie vs. Zentralisierung Unterschiedliche Führungskräfte wünschen sich möglicherweise eine separate Inhaberschaft der Daten. Die Autonomie bevorzugt mehrere Data 360-Organisationen. Die Zentralisierung bevorzugt Data Cloud One. Eine Holdinggesellschaft mit unabhängigen Tochtergesellschaften ermöglicht es jedem BU, seine eigenen Data 360-Daten auszuführen.
Latenz und Leistung Wirkt sich auf die Abfragegeschwindigkeit und -erfahrung aus, insbesondere für Begleitorganisationen, die regionsübergreifend mit einem Data 360-Mandanten verbunden sind. Ein Vertriebsteam in London, das Daten von einem Data 360-Mandanten in den USA abfragt, sieht möglicherweise eine höhere Latenz.
Integrationskomplexität Mehr Data 360-Mandanten = mehr Pipelines, APIs und Middleware. Die Konsolidierung vereinfacht die Integration. Ein Händler vermeidet das Erstellen von 10 ETL-Pipelines, indem er sie in einer Data Cloud One-Konfiguration konsolidiert.
Zero Copy Data Source Region (Zero Copy-Datenquellenregion) Die regionsübergreifenden Zugriffsanforderungen für einige Konnektoren können die Region oder den Standort Ihrer Data 360-Organisation einschränken. Ein Unternehmen verfügt über eine Snowflake-Instanz in der Region AWS eu-west-1. Sie können Zero Copy verwenden, um Daten mit einer Data 360 in ihrer Region zu verknüpfen, Zero Copy jedoch nicht, um eine Data 360 in der Region der USA zu verknüpfen.
Regionsübergreifende Private Connect-Kompatibilität Manchmal hängt die Unterstützung von Private Connect davon ab, ob sich die Datenquelle in derselben Region wie der Data 360-Mandant befindet. Ein Unternehmen verfügt über eine Snowflake-Instanz in der Region aws-east-1, die per Zero-Copy mit Data 360 verbunden werden soll. Sie können nur dann eine Private Connect-Netzwerkverbindung herstellen, wenn sich die Data 360-Startorganisation in derselben Region befindet.
Kosten und Lizenzierung Jeder Data 360-Mandant hat zusätzliche Kosten. Die Konsolidierung in weniger Instanzen optimiert die Ausgaben. Ein Gesundheitsanbieter reduziert die Lizenzkosten, indem er Data Cloud One anstelle mehrerer unabhängiger Data 360-Instanzen verwendet.
Künftige Skalierbarkeit Bereitstellungsentscheidungen schaffen heute die Grundlage für Wachstum. Ein SaaS-Unternehmen beginnt mit einer einzelnen Data 360-Instanz, plant jedoch, mit der Übernahme von Tochtergesellschaften mit Salesforce-Organisationen auf Data Cloud One zu expandieren.
Unternehmensweite AI-Bereitschaft Für AI-Funktionen und Agentforce ist in jeder Organisation ein verbundener Data 360-Mandant erforderlich. Bereitstellungsentscheidungen wirken sich darauf aus, wie AI-Modelle im gesamten Unternehmen trainiert und aktiviert werden. Ein Finanzdienstleistungsunternehmen vereinheitlicht Daten in Data Cloud One, sodass seine Einstein AI-Modelle auf unternehmensweite Kundendaten zugreifen können.
## Anwendungsfälle Es gibt drei wichtige Anwendungsfälle, die Entscheidungen für die Data 360-Bereitstellung erfordern: - Auswählen der Startorganisation - Anwenden einer Strategie für mehrere Organisationen - Freigeben von Daten zwischen Data 360-Organisationen ### Auswählen der Startorganisation Wenn Sie eine Data 360-Lizenz erwerben, wird die Data 360-Instanz in der Salesforce-Organisation bereitgestellt, die dieser Lizenz zugeordnet ist. Diese Organisation wird als Data 360-Startorganisation bezeichnet. Die Startseitenorganisation ist der Anker für Ihre Data 360-Instanz. Dies beinhaltet Folgendes: - Verwaltung der Data 360-Speicherung und -Berechnung (in der bei der Bereitstellung ausgewählten Region). - Anwendung von Verwaltungs-, Governance- und Sicherheitsrichtlinien - Leistung der Datenaufnahme, Harmonisierung, Identitätsbestimmung, Segmentierung und Aktivierung In Szenarien mit mehreren Organisationen verwaltet die Startseite die zentrale Data 360-Instanz für andere Salesforce-Begleitorganisationen. **Die Heimatorganisation:** - Bestimmt den geografischen Standort Ihrer Data 360-Instanz. - Legt fest, wer Inhaber und Verwalter Ihrer Data 360-Instanz ist. Administratoren in Ihrer Data 360-Startorganisation können auf alle in Data 360 aufgenommenen Daten zugreifen. - Steuert die zugehörigen Organisationsverbindungen in einer Data Cloud One-Konfiguration. - Legt die Grundlage für Ihre Unternehmensdatenstrategie fest. Sie später zu ändern, ist schwierig und störend. Weitere Informationen zu Data 360-Startorganisationen finden Sie unter [Data 360-Integrationsmuster und -praktiken](/docs/architect/de-de/fundamentals/guide/data360_integration_patterns_and_practices). #### Entscheidung: Vorhandene Organisation oder Neue Organisation als Heimatorganisation? Die erste wichtige Entscheidung besteht darin, Data 360 in einer vorhandenen Produktionsorganisation bereitzustellen oder eine neue, dedizierte Organisation zu erstellen, die als Ausgangsorganisation fungiert. Entscheidungsdiagramm mit vorhandener Organisation und neuer Organisation als Startseite **Option A: Bereitstellen von Daten 360 in einer vorhandenen Organisation** **Funktioniert am besten für:** Kunden mit einer einzelnen Salesforce-Organisation oder Kunden mit mehreren Organisationen, die bereits über eine zentrale Organisation verfügen, in der die meisten Geschäftsprozesse ausgeführt werden. Diagramm mit Data 360-Bereitstellung in vorhandener Organisation - **Positiv:** - Einfachster Pfad: Data 360 wird dort bereitgestellt, wo sich Ihre CRM-Daten befinden. - Sofortiger Zugriff auf lokale Vertriebs-, Service- und Marketingdaten. - Es ist keine zusätzliche Integration erforderlich. - Weniger zu verwaltende Lizenzen und Umgebungen. - Beschleunigt die frühzeitige Akzeptanz, Pilotprogramme und Produktionsanwendungsfälle. - **Kontra:** - Kann die Governance oder die technischen Schulden einer vorhandenen Organisation übernehmen. - Wenn keine einzelne "Hauptorganisation" vorhanden ist, kann die Auswahl einer solchen Organisation zu Inhaberschaftsdebatten führen. - Die Leistung ist an den Standort der Organisation gebunden und entspricht möglicherweise nicht den Anforderungen der unternehmensweiten Residenz. - Wenn mehrere Geschäftseinheiten unterschiedliche Organisationen verwenden, kann die lokale Bereitstellung zu einer Fragmentierung führen, wenn sie nicht mit Data Cloud One gekoppelt ist. **Beispiel:** Ein SaaS-Unternehmen mit einer Salesforce-Organisation stellt Data 360 in dieser Organisation bereit, um Kundenabonnement- und Supportdaten zu vereinheitlichen. **Option B: Bereitstellen von Daten 360 in einer neuen, dedizierten Organisation** **Funktioniert am besten für:** Kunden mit mehreren Salesforce-Organisationen, die sich nicht auf eine einzelne Hauptorganisation ausrichten können, oder Unternehmen mit einem starken Center of Excellence-Modell. Diagramm mit Data 360-Bereitstellung in einer neuen dedizierten Organisation - **Positiv:** - Sauberes Design für die Unternehmensführung ohne übernommene Organisationskomplexitäten. - Zentrale Steuerung über mehrere Geschäftsbereiche hinweg. - Flexibilität bei der Auswahl einer Region anhand der Compliance-Anforderungen. - Funktioniert als neutrale "Shared Service"-Organisation, die nicht an eine Geschäftseinheit gebunden ist. - Einrichten für die künftige Data Cloud One-Architektur (Startorganisation mit mehreren Begleitorganisationen). - **Kontra:** - Kunden müssen eine neue Salesforce-Organisation lizenzieren, in der Data 360 bereitgestellt werden soll. - Zusätzliche Integration erforderlich, um die Organisation über eine Data Cloud One-Begleitverbindung mit einer Data 360 zu verbinden. - Kann Verwaltungsaufwand verursachen (Benutzerverwaltung, Sicherheit, Identität). - Verlangsamte Wertschöpfungszeit im Vergleich zur Bereitstellung in einer vorhandenen Produktionsorganisation. **Beispiel:** Ein multinationales Finanzdienstleistungsunternehmen erstellt eine dedizierte Startseitenorganisation zur Bereitstellung von Data 360\. Alle Organisationen der Geschäftseinheit (Einzelhandel, Vermögen, Geschäftsbankwesen) verbinden sich als Begleitorganisationen über Data Cloud One. **Entscheidungskriterien**
Überlegung Vorhandene Organisation als Startorganisation (bevorzugte Standardeinstellung) Neue Organisation als Heimatorganisation (Alternative)
Einfachheit Aufbauend auf der vorhandenen Benutzer- und Datenstruktur für eine schnellere Einrichtung.
Data 360 ist standardmäßig in die Startseite integriert.
Erfordert die Lizenzierung und Einrichtung einer neuen Salesforce-Organisation sowie zusätzlichen Verwaltungsaufwand für ihre Verwaltung
Time-to-Value (Zeit bis zum Wert) Sofortige Verwendung lokaler CRM-Daten Eine langsamere Steigerung und Integration ist erforderlich.
Governance Übernimmt das grundlegende Governance-Modell der vorhandenen Organisation – vorhandene Benutzer und Berechtigungssätze (möglicherweise akzeptabel, wenn die Organisation bereits zentral ist). Sauberes Blatt für die Unternehmensführung. Ideal für COE-geführte Modelle.
Compliance Residenz, die an die Region der vorhandenen Organisation gebunden ist Flexibilität bei der Auswahl einer Region unabhängig von vorhandenen Organisationen
Leistung Beste Leistung für lokale CRM-Abfragen Abhängig von der Konnektivität der Begleitorganisation, unabhängig davon, ob es sich um dieselbe Region oder eine Region mit den anderen Organisationen handelt
Künftige Skalierbarkeit Funktioniert gut in Kombination mit Data Cloud One. Schwerer zu verschieben, wenn die falsche Organisation ausgewählt wurde Einfache Skalierung mit Data Cloud One. Entwickelt für Neutralität.
Kosten Geringere inkrementelle Kosten Höherer Overhead durch zusätzliche Umgebungen
#### Empfehlungen Grundsätzlich gilt: Verwenden Sie eine vorhandene Hauptorganisation als Ausgangsorganisation, um den anfänglichen Aufwand zu minimieren und die Akzeptanz zu beschleunigen. Erstellen Sie nur dann eine neue, dedizierte Startseitenorganisation, wenn Ihre langfristige Governance- oder Compliance-Strategie dies erfordert. Das Erstellen einer neuen, dedizierten Startseitenorganisation ist für größere Unternehmen mit einem Center of Excellence (COE) eine gängige Wahl. **Umgebung einer einzelnen Organisation** Stellen Sie Data 360 in Ihrer vorhandenen Produktionsorganisation bereit. Dies maximiert die Einfachheit und den sofortigen Wert. Dadurch wird unnötiger Integrationsaufwand vermieden. **Umgebung für mehrere Organisationen** Wählen Sie bevorzugt eine Ihrer wichtigsten Organisationen aus, in der Regel die, in der der Großteil Ihres Unternehmens ausgeführt wird, oder die Organisation, die als zentralisiertes CRM fungiert, um als Ausgangsorganisation zu fungieren. Dadurch wird die Komplexität reduziert, der Setup-Aufwand minimiert und Sie können den Wert von Data 360 schnell realisieren. Durch die Verwendung einer vorhandenen Hauptorganisation werden zudem die Kosten und der Integrationsaufwand für die Verwaltung einer neuen Umgebung vermieden. **Berücksichtigen einer neuen, dedizierten Heimorganisation** Das Erstellen einer Startseitenorganisation bietet Flexibilität und Neutralität, jedoch mit einer langsameren Wertschöpfung in diesen Fällen. - Wenn Ihre Organisation über ein starkes Center of Excellence (CoE) verfügt und die Unternehmensführung von Organisationen der Geschäftseinheit getrennt werden soll. - Wenn keine einzelne vorhandene Organisation aufgrund von Compliance- oder Organisationseinschränkungen geeignet ist. ### Anwenden einer Strategie für mehrere Organisationen #### Die Herausforderung für mehrere Organisationen Unternehmen betreiben oft mehrere Salesforce-Organisationen – und dies ist kein Edge-Kundenvorgang, sondern die Norm. Im Februar 2024 führten bereits etwa 19.000 Salesforce-Kunden mehr als eine Salesforce-Organisation aus. Warum passiert das? - **Übernahmen und Fusionen:** Neu erworbene Unternehmen verfügen über eigene Salesforce-Instanzen. - **Regionale Vorgänge:** Getrennte Organisationen für EU, Nordamerika, Asien-Pazifik usw., oft zur Einhaltung der Datenresidenzgesetze. - **Funktionale Trennung:** Verschiedene Geschäftseinheiten (z. B. Retail Banking, Vermögensverwaltung, Versicherungen) unterhalten ihre eigenen Organisationen, um Autonomie zu gewährleisten. - **Regulatorische oder Sicherheitsisolation:** Bestimmte Branchen legen aus Compliance-Gründen logisch unterschiedliche Organisationen fest. - **Historische oder technische Gründe:** Im Laufe der Zeit häufen Kunden organisch mehrere Organisationen an. Jeder Grund ist einzeln sinnvoll, aber zusammen ergeben sie eine Fragmentierung der Daten. Ohne verbindende Ebene verfügt jede Organisation nur über eine Teilansicht des Kunden. Die architektonische Herausforderung: Wie vereinheitlichen Sie Daten organisationsübergreifend in einer einzigen Informationsquelle und beachten dabei Compliance-, Governance- und Autonomieanforderungen? --- #### Data Cloud One Data Cloud One ist die Multi-Organisations-Konnektivitätsarchitektur von Salesforce, mit der mehrere Salesforce-Organisationen eine einzelne Data 360-Instanz gemeinsam nutzen können. Dies ist das empfohlene Muster für Unternehmen mit mehreren Salesforce-Organisationen. In einem beliebigen Data Cloud One-Cluster wird eine Salesforce-Organisation als Ausgangsorganisation festgelegt, die die Data 360-Instanz hostet. Andere Salesforce-Organisationen verbinden sich als Begleitorganisationen und verwenden die zusammengeführten Daten und Metadaten aus Data 360 der Startseitenorganisation. Diagramm mit Data Cloud One-Architektur **Funktionsweise von Data Cloud One** - **Datenaufnahme und -vereinheitlichung (Startorganisation)** - Die gesamte Konfiguration der Datenaufnahme (Salesforce CRM, externe Quellen, Streaming, Batch) erfolgt nur über die Startseite. - Der Data 360-Mandant, der an die Startseitenorganisation gebunden ist, führt die Identitätsbestimmung, Harmonisierung, Modellierung und Vereinheitlichung in vertrauenswürdigen Kundenprofilen aus. - Data 360-Verwaltung, Governance-Richtlinien, Tagging und Maskierung werden zentral über die Startseitenorganisation angewendet. - **Datenbereichsarchitektur** - In der Startseite werden Daten in Datenbereichen organisiert, die als logische Container für Daten, Metadaten und Prozesse fungieren. - Unternehmen können Datenbereiche für Marken, Regionen oder Geschäftsbereiche erstellen. - Freigabe von Datenbereichen: In der Startseite werden bestimmte Datenbereiche selektiv für Begleitorganisationen freigegeben. Dadurch wird sichergestellt, dass nur die relevanten Daten (und die zugehörigen Metadaten) in die richtigen Organisationen fließen. - **Metadatenfreigabe** Begleitorganisationen erhalten Metadatendefinitionen von der Startseite, einschließlich Datenmodellobjekten (DMOs), vereinheitlichtem Profilschema, berechneten Statistiken, Segmenten [und mehr](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5). Diese werden nativ in der Begleitorganisation angezeigt, als ob es sich um lokale Vermögenswerte handelte, sie sind jedoch mit der Startseite verknüpft. - **Funktionen in Organisationen vom Typ "Startorganisation" im Vergleich zu Begleitorganisationen** Der Funktionszugriff unterscheidet sich je nach Startseite und Begleitorganisation. Begleitorganisationen können keine Daten aufnehmen oder vereinheitlichen und sind bei der Aufnahme, Modellierung und Vereinheitlichung auf die Startseite angewiesen. Begleitorganisationen können auf Data 360-Daten zugreifen, um Data 360-gestützte Plattformfunktionen bereitzustellen, und sie können lokale Statistiken, Segmente und Flows auf der Grundlage der freigegebenen, vertrauenswürdigen Daten erstellen. In der Zukunftsvision können sie auch auf Aktivierungsfunktionen zugreifen.
Kapazität Home Org (Startorganisation) Begleitorganisation
Konnektoren konfigurieren, Datenströme erstellen, Daten aufnehmen oder Verbunddaten erstellen ✅ ❌
Harmonisieren und Vereinheitlichen Erstellen und Ausführen von Datentransformationen und Identitätsbestimmung ✅ ❌
Steuern von sicheren Daten mit Datenbereichen und Berechtigungen ✅ ✅
Erstellen von Segmenten und Prognosen für Einstein Studio-Modelle ✅ ✅
Aktivierungen von Everywhere, Datenaktionen ✅ ✅
Plattformfunktionen: Eingabeaufforderungsgenerator, Flows, Berichte, Anreicherung [und mehr](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) ✅ ✅
Data 360-gestützte Funktionen: Prospecting Center, Sales- und Service Cloud-Funktionen, Agentforce und mehr ✅ ✅
- **Plattformfunktionsparität** Aus Sicht von Benutzern und Generatoren gibt es nach der Freigabe der Metadaten einige funktionale Unterschiede zwischen Startseiten- und Begleitorganisationen in Bezug auf die Verwendung der Salesforce Platform-Funktionen. Eine Liste der unterstützten Funktionen finden Sie unter [Data 360-Funktionen in Begleitorganisationen](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5). - Sobald Metadaten verfügbar sind, können Salesforce Platform-Funktionen wie Flows, Berichte, Eingabeaufforderungsgenerator, Dashboards und andere plattformeigene Tools in Start- und Begleitorganisationen verwendet werden. - Data 360-gestützte Funktionen wie Agentforce, das Prospecting Center, Sales Cloud Einstein und Service Cloud AI-Funktionen funktionieren auch problemlos in Heim- und Begleitorganisationen. Einige Funktionen sind möglicherweise auf dem Weg zur vollständigen Kompatibilität. Das übergeordnete Ziel besteht jedoch darin, für alle cloudübergreifenden Funktionen, die von Data 360 abhängen, die Funktionsparität zwischen Startseiten- und Begleitorganisationen zu gewährleisten. - **Verbrauchsmodell** Alle Aktivitäten der Begleitorganisation (Abfragen, Segmentausführungen, durch Data 360 ausgelöste Flows, AI-Nutzung, Einstein Trust Layer-Protokollierung usw.) verbrauchen Data 360-Guthaben aus der Startseite. Verbrauchs-Flows in eine Richtung: Gutschriften werden zentralisiert, in Rechnung gestellt und mit der Gutschriftszuteilung der Heimatorganisation abgeglichen. Sie können jedoch einen Drilldown ausführen, um zu sehen, wie viele Gutschriften jede einzelne Organisation in Digital Wallet verwendet hat. - **Designprinzip: Horizontale Konstruktion** Das horizontale Konstrukt in Data 360 ist ein grundlegendes Designprinzip, das hauptsächlich über Data Cloud One implementiert wird und es ermöglicht, dass sich eine einzelne Data Cloud-Instanz über mehrere, unterschiedliche Salesforce CRM-Organisationen erstreckt. Ziel ist es, dass jede neue veröffentlichte Funktion ohne zusätzliche Einrichtung in Heim- und Begleitorganisationen funktioniert. Diese Funktion stellt sicher, dass Data Cloud One nicht nur eine Datenarchitektur ist, sondern ein grundlegendes Element der Salesforce Platform. --- #### Entscheidung: Mehrere Datenorganisationen im Vergleich zu freigegebenen Daten 360 (Data Cloud One) Unternehmen mit mehreren Organisationen müssen auswählen, wie und wo Data 360 in ihrem Ökosystem platziert werden soll. Möchten sie unabhängige Data 360-Organisationen in jeder Organisation bereitstellen oder Data Cloud One verwenden, um Organisationen unter einer einzigen Startseite zu vereinheitlichen? **Option A: Mehrere unabhängige Data 360-Organisationen** Jede Salesforce-Organisation stellt ihre eigene Data 360-Instanz bereit. **Positiv:** - **Autonomie:** Jede Geschäftseinheit oder Region steuert ihre eigenen Data 360. - **Einfachheit in jeder Organisation:** Governance, Sicherheit und Anpassungen sind lokalisiert. - **Einhaltung gesetzlicher Vorschriften:** Dies ist nützlich, wenn eine strikte behördliche Trennung erforderlich ist (beispielsweise dürfen Daten keine Grenzen überschreiten). **Kontra:** - **Datensilos:** Vereinheitlichte Profile können organisationsübergreifend nicht erreicht werden. - **Höhere Kosten:** Jede Instanz erfordert Lizenzierung, Verwaltung und Integration. Kunden nehmen dieselben Quelldaten schließlich mehrfach in mehreren verschiedenen Organisationen auf. - **Doppelte Arbeit:** Die Identitätsbestimmung, Segmentierung und Anreicherung müssen in jeder Data 360-Instanz wiederholt werden. **Option B: One Shared Data 360 (Data Cloud One-Cluster)** Eine einzelne Data 360-Lösung wird in einer Startseite bereitgestellt, während andere Salesforce-Organisationen als Begleitorganisationen verbunden sind. **Positiv:** - **Single Source of Truth (SSOT):** Alle Organisationen verwenden ein einheitliches Datenmodell. - **Kosteneffizienz:** Verwalten Sie nur eine Data 360-Lizenz und -Infrastruktur. - **Einheitliche Unternehmensführung:** Zentral angewendete Richtlinien, Sicherheits- und Compliance-Kontrollen. - **Organisationsübergreifende Anreicherung:** Greifen Sie organisationsübergreifend auf harmonisierte Profile, Statistiken und Segmente zu. - **AI-Bereitschaft:** Ein unternehmensweites Datenset ermöglicht eine bessere Schulung und Aktivierung von AI-Modellen. - **Zukunftssicher:** Das Hinzufügen neuer Begleitorganisationen ist einfach, da keine neuen Data 360-Organisationen erforderlich sind. **Kontra:** - **Zusätzliche Zubereitung:** One Data 360 erfordert eine Planung für die Verbindung zwischen Organisation und Zuhause. - **Überlegungen zur Latenz:** Begleitorganisationen in verschiedenen Regionen sehen möglicherweise langsamere Abfragen. - **Komplexe Governance:** Wenn jede Organisation unterschiedliche Anpassungsanforderungen hat, kann die detaillierte Verwaltung komplex sein. **Option C: Mehrere Data Cloud One-Cluster** **Manchmal** kann es aufgrund von Governance, Compliance oder anderen Geschäftsanforderungen unpraktisch sein, jede Organisation zusammenzufassen. Dies kann dazu führen, dass eine Hybridlösung implementiert werden muss, in der das Unternehmen mehrere Data 360-Organisationen betreibt, von denen jede die Ausgangsorganisation für einen anderen Cluster von Begleitorganisationen ist. **Beispiel:** Ein multinationales Unternehmen verfügt über Salesforce-Organisationen in verschiedenen Regionen, darunter Europa, die USA und Asien. Zur Einhaltung der Verordnungen zur regionalen Datenresidenz stellen sie für jede separate Region eine Data 360 bereit. **Entscheidungskriterien**
Überlegung Mehrere unabhängige Data 360-Organisationen One Shared Data 360 (Data Cloud One)
Autonomie Hohe Autonomie für jede Organisation oder Geschäftseinheit Zentralisierte Verwaltung, weniger Autonomie pro Organisation
Compliance Nützlich, wenn eine strenge Trennung erforderlich ist (z. B. regionale Gesetze) Funktioniert am besten, wenn die Residenz die Zentralisierung zulässt
Kosten Höhere Lizenzierungs- und Administratorkosten Kosteneffizienter; eine Lizenz für viele Organisationen
Governance Fragmentiert; Richtlinien unterscheiden sich je nach Organisation Zentralisierte, organisationsübergreifend konsistente Richtlinien
Datensilos Jede Organisation mit eigener Ansicht Kein Unternehmen 360 Vereinheitlichtes Datenset, keine Duplizierung
AI/Analysen Beschränkt auf die Daten der einzelnen Organisationen Unternehmensweite Modelle mit höherer Genauigkeit
Komplexität Mehr zu verwaltende Instanzen, mehr Integrationen Einfachere Architektur, weniger bewegliche Teile
Leistung Bestens geeignet für Anwendungsfälle innerhalb der Organisation Potenzielle Erhöhung der Latenz mit Zugriff auf Begleitorganisationen
--- #### Empfehlungen **Bevorzugtes Muster: Data Cloud One** Wenn Sie die Verwaltung vereinfachen und die Kosten in Unternehmen mit mehreren Organisationen optimieren möchten, verwenden Sie eine einzelne Startseite mit verbundenen Begleitorganisationen. **Wann mehrere Data 360-Organisationen verwendet werden:** Verwenden Sie mehrere Data 360-Organisationen nur dann, wenn dies aufgrund der Compliance, der Residenz oder der Organisationsautonomie unbedingt erforderlich ist (beispielsweise wenn europäische Vorgänge aufgrund von Vorschriften vollständig von US-amerikanischen Vorgängen getrennt bleiben müssen). **Auswählen der Startseite in Data Cloud One:** Ziehen Sie zunächst eine Ihrer wichtigsten Organisationen in Betracht, in der Regel eine Ihrer Hauptorganisationen. Die Bereitstellung von Data 360 dort kann die Komplexität minimieren und den frühen Wert maximieren. Sie sollten nur dann eine dedizierte Startseitenorganisation erstellen, die von einem COE-Team verwaltet wird, wenn keine vorhandene Organisation geeignet ist. **Allgemeines Prinzip:** Minimieren Sie in Umgebungen mit mehreren Organisationen die Anzahl der Data 360-Organisationen. Bevorzugen Sie Data Cloud One als Standardmuster, um Duplikate zu reduzieren, die AI-Bereitschaft zu aktivieren und die Verwaltung zu vereinfachen. ### Freigeben von Daten zwischen Data 360-Organisationen #### Die Notwendigkeit der Datenfreigabe Obwohl Data Cloud One für die meisten Unternehmen der empfohlene Ansatz ist, gibt es Szenarien, in denen Kunden mehrere Data 360-Instanzen bereitstellen müssen, darunter: - **Regionale Compliance.** Ein multinationaler Einzelhändler stellt eine Data 360 in der EU und eine weitere in den USA bereit. Die Data 360-zu-Data 360-Datenfreigabe ermöglicht es dem Unternehmen, Statistiken aus lokalen Daten zu erstellen und die Statistik dennoch für die US-Zentrale freizugeben. - **Zusammenarbeit der Geschäftseinheit.** Ein Konglomerat führt separate Data 360-Organisationen für Einzelhandel und Versicherungen aus. Durch die Datenfreigabe zwischen Data 360-Organisationen können Benutzer auf eine einzelne, vertrauenswürdige Datenquelle zugreifen, ohne sie verschieben oder kopieren zu müssen. Bei der Datenfreigabe zwischen Data 360-Organisationen erhält die Versicherungsorganisation das Segment "High-Value Customer" (Kunden mit hohem Wert) des Einzelhandels für gezielte Cross-Selling-Kampagnen. - **Fusionen und Übernahmen.** Eine Muttergesellschaft erwirbt eine Tochtergesellschaft mit eigenem Data 360\. Durch die Beibehaltung kurzfristiger Datensilos werden die Datensicherheit und die SSOT-Integrität gewahrt. Gleichzeitig ermöglicht die Freigabe von Daten zwischen zwei Data 360-Instanzen die notwendige Zusammenarbeit während der Umstellung. - **Verbund-Führungskraft-Dashboards.** Eine multinationale Streuung über Kontinente stellt einzelne Data 360-Organisationen pro Region bereit. Führungskräfte möchten eine Verbundansicht der vierteljährlichen Leistung. Jede regionale Data 360-Anwendung gibt aggregierte berechnete Statistiken für eine "Führungsorganisation" frei und ermöglicht so unternehmensweite Berichte. #### Funktionsweise der Datenfreigabe Wenn mehrere Data 360-Organisationen vorhanden sind, erfolgt die Zusammenführung nicht automatisch. Mit der Datenfreigabe von Data 360 zu Data 360 können Kunden bestimmte Objekte zwischen Data 360-Instanzen ohne Duplikate oder benutzerdefinierte Pipelines freigeben. Hierbei handelt es sich um einen Mechanismus zur Freigabe von Nullkopie-Metadaten, der für die Zusammenarbeit zwischen Data 360-Organisationen entwickelt wurde. - Jede Data 360 wird in ihrer eigenen Heimatorganisation bereitgestellt. - Administratoren können eine Datenfreigabe erstellen – eine Gruppierung bestimmter Objekte, die sie freigeben möchten. - Der Zugriff auf die ausgewählten Daten wird für Data 360 einer Zielorganisation freigegeben, wobei die Objekte wie lokal definiert angezeigt werden. Nur der Zugriff wird freigegeben, die zugrunde liegenden Daten verbleiben in der Quelldatei Data 360. - Tags werden nicht freigegeben. Nur die Rohobjekte werden zur Verfügung gestellt. Die Zielorganisation muss bei Bedarf alle Governance-, Betriebs- oder AI-Tags erneut anwenden. #### Wichtige Unterschiede zu Data Cloud One - In Data Cloud One verwenden mehrere Begleitorganisationen eine einzelne Data 360-Instanz. Plattformfunktionen wie Agentforce, das Center für potenzielle Kunden und Tableau Next werden mit denselben zugrunde liegenden Daten ausgeführt, um Konsistenz zu gewährleisten. - Bei der Datenfreigabe zwischen Data 360-Organisationen verfügt jede Organisation über ihre eigenen Data 360-Funktionen. Funktionen wie Agentforce in Organisation A und Organisation B funktionieren jeweils unabhängig von ihrer lokalen Instanz. Es erfolgt keine automatische Freigabe. Es müssen bewusste Datenfreigaben erstellt werden, um nur an bestimmten Objekten zusammenzuarbeiten. #### Vor- und Nachteile der Datenfreigabe zwischen Data 360-Organisationen
Faktor Pros Nachteile
Datenresidenz Unterstützt die regionale Trennung und ermöglicht gleichzeitig die Zusammenarbeit. Die Verwaltung mehrerer Data 360-Organisationen entfällt nicht.
Datenduplizierung Nullkopie; keine Duplizierung von Objekten. Erfordert eine bewusste Auswahl von Objekten für die Aufnahme in jede Datenfreigabe.
Governance Die Freigabe erfolgt explizit und bewusst (Objektebene). Es werden keine Tags oder Richtlinien verwendet. Die Zielorganisation muss die Governance erneut anwenden.
Komplexität Ermöglicht die selektive Zusammenarbeit ohne Zentralisierung. Erfordert die Verwaltung mehrerer Data 360-Organisationen und Datenfreigaben.
**AI/Analytics** Regionale AI/Analysen möglich; Statistiken können organisationsübergreifend freigegeben werden. Keine unternehmensweite AI, es sei denn, Daten werden bewusst freigegeben.
**Plattformfunktionen** Die Data 360-gestützten Funktionen jeder Organisation werden unabhängig ausgeführt. Keine automatische Freigabe. Duplizierungsrisiko, wenn nicht sorgfältig geplant.
Kosten Kann den Bedarf an ETL-Pipelines reduzieren. Für mehrere Data 360-Organisationen fallen weiterhin Kosten an. Verbraucht Gutschriften für Datenabfragen und die Datenfreigabe.
#### Entscheidungskriterien
Überlegung Data Cloud One (für mehrere Organisationen bevorzugt) Datenfreigabe zwischen Data 360-Organisationen
Single Source of Truth (Einzelne Quelle der Wahrheit) Ja, alle Organisationen verwenden ein gemeinsames Datenmodell. Nein, jede Data 360 verfügt über ein eigenes Datenmodell.
Compliance Funktioniert nur, wenn die Residenz die Zentralisierung zulässt. Wird benötigt, wenn Residenzgesetze die Zentralisierung verhindern.
Governance Zentralisiert, konsistent. Verbunden; bewusste Freigaben auf Objektebene.
Komplexität Weniger bewegliche Teile, einfacher. Komplexer: Erfordert Konfigurationsdatenfreigaben und mehrere Datenorganisationen.
AI/Analysen Unternehmensweite AI-Modelle. Regionale AI. Geben Sie Statistiken selektiv frei.
Plattformfunktionen "Shared Data 360" bedeutet, dass alle Funktionen konsistent zu Hause + Begleiter funktionieren. Funktionen werden in jeder Data 360 unabhängig ausgeführt. Die Freigabe muss explizit sein.
#### Empfehlungen **Wenn Ihr Unternehmen über mehrere Data 360-Organisationen verfügt** - Verwenden Sie die Datenfreigabe zwischen Data 360-Organisationen, um zwischen ihnen zusammenzuarbeiten, statt benutzerdefinierte Pipelines zu erstellen oder Daten zu duplizieren. - Geben Sie bestimmte Objekte (DMOs, berechnete Statistiken, Segmente) frei, indem Sie Datenfreigaben erstellen und sie Zielorganisationen erteilen. - Tags werden nicht freigegeben. Die empfangende Organisation muss Tags erneut anwenden, um die Verwaltung, die Klassifizierung oder die AI-Anreicherung zu gewährleisten. **Datenfreigabe zwischen Data 360-Organisationen verwenden** - Erfüllung gesetzlicher Anforderungen, die eine Zentralisierung verhindern. - Aufrechterhalten der Geschäftseinheitsautonomie bei gleichzeitiger Aktivierung der selektiven Zusammenarbeit. - Bereitstellen von Verbund-Führungskraft-Dashboards in mehreren Regionen. - Überbrücken von M&A-Szenarien, in denen eine Konsolidierung nicht sofort möglich ist. **Sorgfältig entwerfen** Behandeln Sie die Data 360-zu-Data 360-Datenfreigabe als Verbundstrategie und nicht als Ersatz für Data Cloud One. - Verwenden Sie die objektspezifische Freigabe. - Vermeiden Sie eine Überfreigabe. - Passen Sie Datenfreigaben an Geschäfts- und Compliance-Anforderungen an. #### Merken Die Planung Ihrer Datenstrategie für die Data 360-Bereitstellung ist eine wichtige, langfristige architektonische Entscheidung, die unternehmensweit und nicht organisationsübergreifend getroffen werden muss. Diese frühe strategische Entscheidung bestimmt, wie Kundendaten vereinheitlicht, wie die Unternehmensführung erzwungen wird und wie wichtige Plattformfunktionen – insbesondere AI und Analysen – organisationsweit skaliert werden. Planen Sie Governance- und Inhaberschaftsmodelle im Voraus und vermeiden Sie kurzfristige Abkürzungen, die später zu Fragmentierung und erhöhter Komplexität führen. ## Ressourcen [Was ist Customer 360?](https://www.salesforce.com/products/what-is-customer-360/) [Data 360-Integrationsmuster und -praktiken](/docs/architect/de-de/fundamentals/guide/data360_integration_patterns_and_practices) [Data 360-Architektur](/docs/architect/de-de/fundamentals/guide/data-360-architecture) [Data 360-Sicherheitsarchitektur](/docs/architect/de-de/fundamentals/guide/data360_security_architecture) **Über die Autoren** Kunal Goyal ist Director of Product Management bei Salesforce und konzentriert sich auf die Weiterentwicklung der Architektur und Skalierbarkeit von mehreren Organisationen in Data 360\. Seit 2017 hat er mehrere Initiativen und Produkte mit Schwerpunkt auf organisationsübergreifender Zusammenarbeit und mandantenübergreifendem Systemdesign geleitet. Kunal ist einer der Architektur-Leads für bewährte Vorgehensweisen in Data 360 und Produktinhaber für Data Cloud One, Setup, Bereitstellung und Administratorerfahrungen. Erin Wagner Tidwell ist technische Hauptautorin und Inhaltsdesignerin für Data 360\. Sie arbeitet seit 2013 bei Salesforce und ist bestrebt, Data 360 durch klare, konsistente und genaue technische Dokumentation und Kommunikation in der Anwendung leichter verständlich zu machen. Yugandhar Bora ist Software Engineering Architekt bei Salesforce und spezialisiert sich auf die Datenarchitektur innerhalb der Plattform für Daten- und Intelligenzanwendungen. Er leitet Initiativen des Enterprise Architecture Review Board (EARB), die sich auf die Datenverwaltung und vereinheitlichte Datenmodelle konzentrieren, und trägt gleichzeitig zu automatisierten Plattformbereitstellungslösungen bei. Samarpan Jain ist Principal Architect bei Salesforce und spezialisiert sich auf Commerce Cloud, Plattformintegration und organisationsübergreifende Architektur. Als einer der am längsten beschäftigten Mitarbeiter von Salesforce leitet er wichtige Initiativen wie die Einhaltung der Vorschriften für die Datenresidenz für Behördenkunden und Data 360-Nutzungsattributionssysteme. # Data 360-Interoperabilität Unternehmen speichern Daten häufig in Salesforce und anderen externen Data Lakes (z. B. _Snowflake_, _Google BigQuery_, _Databricks_, _Redshift_ oder Objektspeicher wie _Amazon S3_). Die Isolierung von Daten über mehrere Systeme hinweg stellt Unternehmen vor eine Herausforderung, die den vollen Wert ihrer Daten nutzen möchten, um AI-gestützte Erfahrungen zu ermöglichen. Salesforce _Data 360_ ist die grundlegende Intelligence-Ebene, die jeder Agentforce AI Agent verwendet, um zum richtigen Zeitpunkt auf den richtigen Kontext zuzugreifen. Architekten, die daran arbeiten, Daten über mehrere Data Lakes hinweg zusammenzuführen, stehen vor wichtigen architektonischen Entscheidungen hinsichtlich der besten Integration dieser Daten. _Data 360_ bietet mehrere Optionen für die Datenintegration, die jeweils verschiedene Vor- und Nachteile bieten. ## Leitfadenübersicht Dieser Leitfaden bietet ein Framework, um zu bewerten, welches Muster Ihren Anforderungen an Latenz, Kosten, Skalierbarkeit, Governance und Komplexität bei der Integration von Daten am besten entspricht. So können Sie auswählen, wann die Datenaufnahme, die Zero Copy-Datenverbundorganisation oder ein hybrider Ansatz verwendet werden soll. Der Leitfaden hilft Ihnen auch bei der Auswahl zwischen verschiedenen Methoden der Datenaufnahme und der Datenzuordnung, von denen jede einen anderen Bedarf erfüllt. Die Integration externer Data-Lake-Häuser in _Data 360_ erfordert eine sorgfältige Abwägung der Kompromisse zwischen Datenaktualisierung, Governance und Pipeline-Effizienz. Wenn Sie beispielsweise Live-Abfragen des Datenverbunds Zero Copy verwenden, wird die Aktualität der Daten maximiert, die Pipeline-Effizienz kann jedoch reduziert werden, wenn mehr Daten über das Netzwerk fließen. Für die meisten realen Implementierungen ist die Kombination von Aufnahme und Verbund in einem Ökosystem mit mehreren Cloud-Seehäusern der optimale Weg. Dieser hybride Ansatz gewährleistet eine skalierbare, gesteuerte und interoperable Architektur, die operative Arbeitslasten mit geringer Latenz (z. B. Echtzeitpersonalisierung und Betrugserkennung) und analytische Arbeitslasten (z. B. behördliche Berichte und Analysen historischer Trends) unterstützt. In diesem Leitfaden können Sie bestimmen, wie Sie mit einer geeigneten Strategie durch diese Kompromisse navigieren. ## Wichtige Takeaways - Die **Datenaufnahme** kopiert Daten in Salesforce _Data 360_ und erstellt geregelte, kanonische Datenmodelle. Dies ist ideal für folgende Fälle: - **Erstellen Sie eine umfassende Customer 360.** Auf diese Weise können Sie unterschiedliche Quellen vereinheitlichen und in ein einzelnes, vertrauenswürdiges Profil umwandeln. - **Erfüllen Sie die strenge Einhaltung gesetzlicher Vorschriften.** Auf diese Weise können Sie eine überprüfbare, zentralisierte Kopie erstellen, sodass der Datenzugriff und die Herkunft genau gesteuert werden können. - Die **Zero Copy Federation** fragt externe Quellen in Echtzeit ohne Duplikate ab, wodurch die Echtzeitpersonalisierung, Live-Dashboards und die schnelle Einarbeitung von Quellen ermöglicht werden. Dieser Ansatz bietet zwei primäre Optionen, es gibt jedoch Kompromisse, die ausgeglichen werden müssen: - **Live-Abfrage:** Verwenden Sie dies für interaktive Analysen und Echtzeit-Daten-Dashboards, die auf externen Datenplattformen (z. B. _Snowflake_, _BigQuery_, _Redshift_ oder _Databricks_) vorhanden sind. Dadurch können Sie langsame, kostspielige Datenduplikate vermeiden, indem Sie die Abfrageverarbeitung an das Quellsystem übertragen und nur die erforderlichen Ergebnisse zurückgeben. Dieser Ansatz ist für seltene oder Ad-hoc-Abfragen optimiert, bei denen die Aktualität entscheidend ist. Sie eignet sich für geringe Arbeitslasten _mit Abfrage pro Sekunde_ (Abfragekosten können bei hoher QPS deutlich ansteigen). - **Zwischenspeicherung (beschleunigte Abfrage):** Verwenden Sie dies für häufige Datenabfragen, die sich nicht oft ändern. Bei beschleunigten Abfragen wird ein lokaler Cache beibehalten, der in konfigurierbaren Abständen (15 Minuten bis 7 Tage) aktualisiert wird, wodurch wiederholte Quelltreffer reduziert werden. Dieser Ansatz gleicht die Dashboard-Leistung und die Kosten, die Segmentierung und die BI-Arbeitslasten aus, wenn leicht veraltete Ergebnisse akzeptabel sind. Dies eignet sich nicht für die Entscheidungsfindung im Sekundenbereich. - **Dateiverbund:** Verwenden Sie dies für die Batch-Verarbeitung im großen Umfang und für die AI-Modellschulung für Daten im Data Lake Ihrer Cloud (z. B. _S3_ oder _ADLS_). Dieser Ansatz vermeidet eine langsame und kostspielige Aufnahme, da Dateien direkt in offenen Tabellenformaten abgefragt werden, wodurch massive ETL-Datensets und Data Science-Arbeitslasten freigesetzt werden. - **Hybridmodelle** kombinieren die Aufnahme für _vereinheitlichte Profile_ mit Verbund für die Aktualisierung, wodurch Omnikanal-Engagement, Agentforce-gesteuerte Aktionen und AI/ML-Training unterstützt werden. ### Wichtige Überlegungen - **Verwenden Sie eine Hybridarchitektur.** Die Kombination von Datenaufnahme und Verbund ist häufig erforderlich. - Verwenden Sie die _Datenaufnahme_ für wichtige Daten für kanonische Datenmodelle und die Kernverwaltung. - Verwenden Sie _Nullkopie_ für alle anderen Datenverbünde, um die Aktualität aufrechtzuerhalten und den operativen Aufwand beim Erstellen und Verwalten von Datenaufnahmepipelines zu minimieren. - **Die Datenaufnahmehäufigkeit ist wichtig.** Wählen Sie die Häufigkeit basierend auf Geschäftswert, Latenzanforderungen und betrieblicher Komplexität aus. - Verwenden Sie _Echtzeit_ für zeitkritische Workflows (z. B. Personalisierung, Live-Dashboards und Agentforce-Aktionen). - Verwenden Sie _nahezu in Echtzeit_ für mäßig dringende Prozesse (z. B. Kampagnen und Betriebsberichte). - Verwenden Sie die Batch-Erstellung für historische oder Low-Velocity-Datensets. - **Vergleichen Sie Verbundmuster mit Latenz und Leistung.** Wählen Sie die Option aus, die Ihren Zugriffsmustern und Anforderungen an Aktualität, Leistung und Kosten am besten entspricht. - Verwenden Sie die _Live-Abfrage_ für betriebliche Dashboards und Echtzeitpersonalisierungen, bei denen eine geringe Latenz entscheidend ist. - Verwenden Sie _Caching (Beschleunigte Abfrage)_, wenn Abfragen häufig sind und leicht veraltete Ergebnisse akzeptabel sind, was zu einem ausgewogenen Verhältnis zwischen Leistung und Kosten beiträgt. - Verwenden Sie den _Dateiverbund_ für umfangreiche Analysen oder Batch-Arbeitslasten, die sich ideal für historische oder weniger zeitkritische Datensets eignen. - **Anpassen der Unternehmensführung an die Anforderungen an die Datenresidenz.** - Verwenden Sie _die Aufnahme_, wenn die zentrale Verwaltung wichtig ist. - Verwenden Sie _den Verbund_, wenn die dezentrale Verwaltung zulässig ist, und erzwingen Sie gleichzeitig eine strenge Verwaltung an der externen Quelle. - Verwenden Sie _Nullkopie_ in Bezug auf Richtlinien auf Quellebene (z. B. _Sicherheit auf Zeilenebene_ und Datenmaskierung). - **Priorisieren Sie die Aufnahme für hochwertige Workflows.** Wenden Sie die Aufnahme selektiv auf wichtige Prozesse an (z. B. Identitätsbestimmung, behördliche Berichte und operative Aktivierung). - **Kosten und Komplexität treiben Entscheidungen voran.** Die Aufnahme in Echtzeit kann teuer und komplex sein. Daher ist es für Architekten wichtig, die Kosten für die Einarbeitung, Speicherung und Umwandlung von Daten mit den Kosten für die direkte Abfrage über _Nullkopie_ abzuwägen. Die Auswahl des richtigen Integrationsmusters – _Datenaufnahme_, _Nullkopie_ oder _Hybridansatz_ – wirkt sich direkt auf Latenz, Governance, betriebliche Effizienz und Kosten auf mehreren Cloud-Plattformen aus. Diese Entscheidung bestimmt, wie Echtzeitstatistiken, AI-gestützte Aktivierung und personalisiertes Engagement zuverlässig und skalierbar bereitgestellt werden. ## Produktvergleich In dieser Tabelle werden die Muster für die _Datenaufnahme_ und _Nullkopie_ in Salesforce _Data 360_ verglichen, wobei der Fokus auf Funktionen, Kompromissen und Vorteilen sowie Anwendungsfällen und Ergebnissen für Unternehmen liegt. Verwenden Sie dies als Referenz für die Entwicklung hybrider Multi-Cloud-Datenplattformen, die Leistung, Kosten und Compliance in Einklang bringen.
Mustertyp Modus/Tool Vorteile Überlegungen Ergebnisse
Datenaufnahme Echtzeit:
  • Aufnahme von Latenzzeiten im Sekundenbereich über Aufnahme-APIs mit CDC-Unterstützung.
  • Kontinuierliche Streaming-Pipelines.
  • Bietet sofortige Statistiken
  • Umfasst Anwendungsfälle für Operationen und Personalisierungen mit geringer Latenz
  • Unterstützt ereignisgesteuerte Workflows
  • Hohe Kosten
  • Komplexe Architektur
  • Systemanforderungen für Quellen mit geringer Latenz
  • Quellen mit hohem Volumen können zu übermäßigem Streaming führen, was zu gesättigten Pipelines führt
  • I/O-intensiv
  • Selektive Felder und Filter können helfen, den Overhead zu reduzieren
Agentforce:
  • Echtzeitbenachrichtigungen zu Betrug, Einzelhandelspersonalisierung und betrieblichen Warnungen
Analysen:
  • Sekundenschnelle Dashboards und KPI-Überwachung
Compliance:
  • Kontinuierliche Kundendatensatzaktualisierungen für regulierte Workflows
Streaming:
  • Micro-Batch-Aufnahme alle 1–3 Minuten über native Konnektoren
  • Gleicht Kosten im Vergleich zur Frische aus
  • Einfachere Architektur als in Echtzeit
  • Unterstützt inkrementelle Aktualisierungen
  • Leichte Latenz
  • Für wichtige Entscheidungen im Sekundenbereich möglicherweise nicht geeignet
  • Batchgröße wirkt sich auf Speicher/Berechnung aus
  • Moderate I/O
  • Geeignet für vorhersehbare, sich wiederholende Aktualisierungsmuster
  • Fensteraggregation kann zur Reduzierung der Verarbeitungslast beitragen
Agentforce:
  • Rechtzeitige Kampagnenauslöser und Nahezu-live-Engagement
Analysen:
  • Empfehlungsmodule und Dashboards in Echtzeit
Compliance:
  • Häufige Aktualisierungen mit Überprüfbarkeit
Batch:
  • Stellt geplante Ladevorgänge mit großem Volumen über Konnektoren oder APIs bereit.
  • Unterstützt Objektspeicher und ETL/ELT-Pipelines.
  • Unterstützt Kosteneffizienz für massive Datensets
  • Einfache Implementierung der Funktionen
  • Bietet Zuverlässigkeit für historische Analysen
  • Datenlatenz
  • Für zeitkritische Vorgänge ungeeignet
  • I/O-intensiv während Lastfenstern
  • Netzwerkdurchsatz kann zu Engpässen bei großen Dateien werden
  • Geeignet für historische Aggregations- oder regulierte Berichts-Workflows
Agentforce:
  • IT-Support-Tickets (Jira/ServiceNow) und aggregierte Workflows
Analysen:
  • Historische Analyse und Trendauswertung
Compliance:
  • Regulatorische Berichte und Aggregation von Patienten-/Anspruchsdaten
Zero Copy Live-Abfrage:
  • Bietet direkte Abfragen auf externen Systemen und schreibgeschütztes Schema ohne Datenduplizierung
  • Bietet maximale Frische
  • Minimaler Speicheraufwand
  • Unterstützt operative Statistiken in Echtzeit
  • Abhängig von der Quellleistung
  • Hohes Abfragevolumen kann sich auf die Latenz auswirken
  • Geeignet für Abfragen mit Prädikat-Pushdown und Aggregation zur Minimierung von E/A
  • Vermeiden der Verwendung ungefilterter Abfragen für massive Datensets
Agentforce:
  • Dynamische Workflows, die an Live-Aktivitäten angepasst werden
Analysen:
  • Operative Dashboards und Live-Berichte
Compliance:
  • Berücksichtigt Sicherheit auf Zeilenebene und Maskierung an der Quelle
Beschleunigte Abfrage (Zwischenspeicherung):
  • Stellt zwischengespeicherte lokale Kopien für Verbundabfragen bereit, die zwischen 15 Minuten und 7 Tagen konfiguriert werden können.
  • Bietet optimierte Abfrageausführung
  • Verringert die Latenz
  • Geringere Kosten als bei sich wiederholenden Live-Abfragen
  • Verbessert die Leistung bei häufigen Zugriffsmustern
  • Cache-Verwaltung erforderlich
  • Staleness hängt von Cache-Intervallen ab
  • Geeignet für Hochfrequenzabfragen
  • Nicht für Entscheidungen im Sekundenbereich geeignet
  • Die inkrementelle Aktualisierung unterstützt nur das Einfügen von Aktualisierungen. Gelöschte Datensätze werden nicht aus dem Cache entfernt.
  • Erfordert regelmäßig eine manuelle vollständige Aktualisierung, damit der Cache mit der Quelle synchron bleibt
Agentforce:
  • Voraggregierte Engagementkennzahlen für schnelle Entscheidungen
Analysen:
  • BI-Dashboards, Segmentierung und analytische Berichte
Compliance:
  • Konsistent geregelte Dashboards mit Überwachungsprotokollen
Dateiverbund:
  • Bietet direkten Zugriff auf große historische Datensets in Objektspeichern oder Lakes (z. B. S3, Iceberg, Google BigQuery und Redshift).
  • Verarbeitet Datensets in großem Umfang
  • Minimaler Speicherplatzbedarf in Data 360
  • Unterstützt AI/ML-Arbeitslasten
  • Schreibgeschützt
  • Abfrageleistung hängt vom Durchsatz des externen Systems ab
  • Geeignet für chargenintensive, durchsatzintensive Aufträge
  • Nicht für Echtzeit-Dashboards geeignet
Agentforce:
  • Nicht typisch (batchlastig)
Analysen:
  • ML/AI-Schulung, historische Analysen und Berichte auf Petabyte-Skala
Compliance:
  • Steuert den Zugriff auf externe Datensets ohne Duplikate
## Data 360-Integrationsmuster Es gibt drei primäre Integrationsmuster für Data 360: die Datenaufnahme, die Zero-Copy-Datenzuordnung und einen hybriden Ansatz. ### Datenaufnahme Bei der _Datenaufnahme_ werden Daten physisch in _Data 360_ kopiert und vollständig verwaltet, im Gegensatz zu _Nullkopie,_ bei der die Daten an der Quelle verbleiben. Anders ausgedrückt: Die Berechnung von Transformationen erfolgt in _Data 360_, das eine zentralisierte Verwaltung und Überwachung bietet. #### Anwendungsfälle für die Datenaufnahme Verwenden Sie die _Datenaufnahme_, um kanonische, geregelte Datensets in Salesforce _Data 360_ zu speichern und die Compliance und die betriebliche Kontrolle zu gewährleisten. Verwenden Sie die Aufnahme, wenn vollständige Kontrolle, Überprüfung und Rückverfolgbarkeit erforderlich sind. Die Datenaufnahme ist ideal für regulierte oder hochwertige Workflows, bei denen die zentrale Berechnung und Verwaltung entscheidend sind. Die Aufnahme eignet sich zum Aufbau einer vertrauenswürdigen Grundlage für die Identitätsbestimmung, behördliche Berichte und geschäftskritische AI-gestützte Workflows und Kundenengagement. Übersicht über die Datenaufnahme #### Methoden zur Datenaufnahme Die Methoden zur _Datenaufnahme_ können variieren, je nachdem, welchen Konnektor Sie zur Aufnahme Ihrer Daten verwenden. Einige Konnektoren bieten eine Vielzahl von Aufnahmemethoden, während andere nur im Batch- oder Streaming-Modus arbeiten. Eine vollständige Liste der _Data 360-_Konnektoren und verfügbaren Methoden finden Sie unter [Data 360: Integrationen und Konnektoren](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5). - **Echtzeit:** - Ermöglicht die Aufnahme im Sekundenbereich mithilfe der _Datenerfassung (CDC)_ - Geeignet für zeitkritische Workflows (z. B. Betrugserkennung, Personalisierung und betriebliche Dashboards) - Verfügt über Push-Transformationen und Aggregationen in _Data 360_, wodurch die nachgelagerten Ein- und Ausgänge reduziert und die Berechnungsnutzung optimiert wird - Unterstützt die Verwendung von inkrementeller CDC zum Minimieren der Datenvermischung - **Streaming:** - Bietet Aufnahme alle 1–3 Minuten in kleinen Schritten - Wägt Frische und Kosten ab - Geeignet für die Kampagnenorchestrierung, die Interaktion beinahe live und für operative Berichte - Unterstützt die Verwendung von Micro-Batchs zum Steuern von E/A-Spitzen - Aggregiert Daten an der Quelle (sofern möglich), um Übertragungsvolumen zu reduzieren und den Speicher zu optimieren - **Batch (Geplante Lasten):** - Stellt die regelmäßige Aufnahme großer Datensets bereit (z. B. stündlich, täglich und wöchentlich) - Bietet Kosteneffizienz und Zuverlässigkeit für historische Datensets, behördliche Berichte und Compliance-Anwendungsfälle - Stellt sicher, dass sich das Gebietsschema in derselben Region wie der Quellspeicher befindet, um die Leistung zu steigern und die Kosten zu optimieren #### Architect Playbook (Playbook für Architekten) - **Anwendungsfälle für die Datenaufnahme:** - **Generieren von zusammengeführten Customer 360-Profilen.** Erstellen Sie eine einzige Datenquelle für Kundenidentitäten und -attribute. - **Verwalten Sie Datensets zur Einhaltung gesetzlicher Vorschriften.** Erzwingen Sie die Verwaltung, Abstammung und Überprüfbarkeit für sensible Daten. - **Kampagnenorchestrierung zentralisieren.** Stellen Sie sicher, dass Marketing, Vertrieb und Service alle über konsistente, vertrauenswürdige Datensets funktionieren. - **Gestaltungspraxis:** - Passen Sie die Batch-Aufnahme für historische oder latenzarme Anforderungen an (z. B. Archivberichte oder regelmäßige Snapshots). - Verwenden Sie CDC- oder Streaming-APIs, um die Aktualität für Betriebs- und Personalisierungs-Workflows aufrechtzuerhalten und Aktualisierungen nahezu in Echtzeit sicherzustellen. - Steuern Sie das Speicher- und Berechnungswachstum, indem Sie inkrementelle Lasten anwenden, um Kosten und Effizienz zu optimieren (anstatt ganze Datensets neu zu laden). - Passen Sie Aufnahme-Pipelines an die Rechenlokalität und die inkrementelle Verarbeitung an, um die Netzwerk-I/O zu reduzieren. - Wenden Sie Transformationen in _Data 360 an_, um unnötige Verschiebungen von Rohdaten zu vermeiden. - **Überlegungen zu Kosten:** - Die **Echtzeitaufnahme** weist die höchsten Rechen- und Pipeline-Kosten auf, was für hochwertige, zeitkritische Workflows (z. B. Personalisierung, operative Dashboards oder Agentforce-gesteuerte Aktionen) gerechtfertigt sein kann. - Die **Streaming-Aufnahme** weist moderate Rechen- und Speicherkosten auf, die für häufige Aktualisierungen geeignet sein können, die leichte Verzögerungen vertragen (z. B. Kampagnenorchestrierung oder Betriebsberichte). - Die **Batch-Aufnahme** hat geringere Rechenkosten und einen vorhersehbaren Speicherplatz, der für historische Datensets oder Aktualisierungen mit geringer Häufigkeit geeignet ist. Die Aufnahme von Batch-Daten aus Salesforce-Organisationen mit bestimmten Konnektoren ist kostenlos. - **Aktualisierungsmodus** Ermöglicht Ihnen die Auswahl des Modus _"Inkrementelle Aktualisierung_", der die Gesamtaufnahme- und Berechnungskosten reduziert. Bei Salesforce wird empfohlen, nach Möglichkeit _eine inkrementelle Aktualisierung_ zu verwenden, um die Effizienz über alle Aufnahmetypen hinweg zu optimieren. - Die **Kosten** werden auch durch das E/A-Volumen von der Quelle zu _Data 360_ beeinflusst. Die Optimierung von Batchgrößen, Partitionen und regionaler Ausrichtung reduziert die Übertragungskosten und verbessert die Leistung. - **Branchenszenarien:** - **Finanzen:** Aufnahme-Datensets sind erforderlich, um _Ihren Kunden zu_ _kennen_, Geldwäsche zu bekämpfen und Betrug zu erkennen, wenn Überprüfbarkeit und Compliance nicht verhandelbar sind. - **Gesundheitswesen:** Verwenden Sie die Aufnahme für die Patientenidentitätsbestimmung und HIPAA-konforme Datensätze, wodurch sichere, vereinheitlichte Ansichten ermöglicht werden. - **Einzelhandel:** Konsolidieren Sie _POS-_, E-Commerce- und Treueprogrammdaten in vereinheitlichten Profilen für die Segmentierung und Personalisierung. - **Telecom:** Unterstützen Sie Abwanderungsprävention und Nutzungsanalysen mit kanonischen, geregelten Abonnentendaten. #### Entscheidungskriterien für die Datenaufnahmemethode | Funktion | Echtzeitaufnahme | Streaming-Aufnahme | Batchaufnahme | | :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Latenz und Frische** | Enthält die Aufnahme von Latenzzeiten im Sekundenbereich über Aufnahme-APIs mit Unterstützung der _Datenerfassung (CDC)_. Bietet kontinuierliche Streaming-Pipelines. Geeignet für operative Anwendungsfälle mit geringer Latenz. | Enthält die Aufnahme von Micro-Batch alle 1–3 Minuten über native Konnektoren. Unterstützt inkrementelle Aktualisierungen. Es wird eine leichte Latenz erwartet. | Es wird eine Datenlatenz erwartet. Lässt geplante Ladevorgänge mit großem Volumen zu. Bietet regelmäßige Aufnahme (stündlich, täglich und wöchentlich). Nicht für zeitkritische Vorgänge geeignet. | | **Primäre Anwendungsfälle** | Ideal für Anwendungsfälle mit geringer Latenz und Personalisierung. Wird für zeitkritische Workflows verwendet. Unterstützt ereignisgesteuerte Workflows. Wird für Echtzeitbetrugswarnungen und operative Warnungen verwendet. | Geeignet für mäßig dringende Prozesse. Wird für die Kampagnenorchestrierung, die Interaktion beinahe live und für operative Berichte verwendet. Wird für zeitnahe Kampagnenauslöser verwendet. | Kosteneffizient für massive Datensets. Zuverlässig für historische Analysen. Wird für historische Aggregations- oder regulierte Berichts-Workflows verwendet. Geeignet für historische oder Low-Velocity-Datensets. | | **Architekturkomplexität und I/O** | Enthält hohe Kosten und komplexe Architektur. Erfordert Quellsysteme mit geringer Latenz. I/O-intensiv. Quellen mit hohem Volumen können zu gesättigten Pipelines führen. | Verfügt über eine einfachere Architektur als in Echtzeit. I/O ist moderat. Geeignet für vorhersehbare, wiederholte Aktualisierungsmuster. Die Batchgröße wirkt sich auf den Speicher und die Berechnung aus. | Einfach zu implementieren. I/O-intensiv bei Lastfenstern. Der Netzwerkdurchsatz kann bei großen Batches zu einem Engpass werden. | | **Überlegungen zu Kosten** | Enthält die höchsten Rechen- und Pipeline-Kosten. Nur für hochwertige zeitkritische Workflows geeignet. | Enthält moderate Berechnungs- und Speicherkosten. Bietet einen ausgewogenen Ansatz für Kosten und Frische. Geeignet für häufige Aktualisierungen, die leichte Verzögerungen vertragen. | Niedrigere Rechenkosten und vorhersehbarer Speicher. Empfohlen für historische Datensets oder Aktualisierungen mit geringer Häufigkeit. Die Aufnahme über interne Salesforce-Pipelines ist kostenlos. | | **Designpraktiken** | Verwenden Sie die inkrementelle CDC, um die Datenvermischung zu minimieren. Filtern und verwenden Sie selektive Felder, um den Overhead zu reduzieren. | Verwenden Sie Micro-Batchs zum Steuern von E/A-Spitzen. Ziehen Sie die Aggregation mit Fenstern in Betracht, um die Verarbeitungslast zu reduzieren. | Wird für Archivberichte oder regelmäßige Snapshots verwendet. Stellen Sie zur Kostenoptimierung sicher, dass sich die Berechnungslokalität in derselben Region wie der Quellspeicher befindet. | ### Zero Copy Data Federation (Zero Copy-Datenverbund) #### Zero Copy-Anwendungsfälle Verwenden Sie _Nullkopie_ für Echtzeitabfragen externer Systeme ohne Datenduplizierung, um Agilität, Aktualität und skalierbaren Zugriff auf große oder vorübergehende Datensets zu ermöglichen. Sie eignet sich für Live-Dashboards, explorative Analysen, AI/ML-Modellschulungen und Echtzeit-Kundenengagement direkt über Salesforce _Data 360_. Zero Copy Data Federation – Übersicht #### Nullkopiemethoden Bei Verwendung von _Nullkopie_ müssen Architekten zwischen drei verfügbaren Datenverbundmethoden wählen, von denen jede ihre eigenen Kompromisse zwischen Aktualität, Leistung und Kosten bietet. - **Live-Abfrage** - Führt Abfragen direkt gegen externe Systeme (z. B. _Snowflake_, _Google BigQuery_, _Redshift_, _Databricks_ usw.) ohne Datenduplizierung aus. - Minimiert die Datenbewegung über das Netzwerk und reduziert die Ein- und Ausgänge bei der Salesforce _Data 360_-Berechnung. Dies ist optimal, wenn Prädikate und Aggregationen nach unten verschoben werden können. - Geeignet für Echtzeitstatistiken und betriebliche Dashboards mit geringer Latenz. - Abhängig von der Leistung des externen Systems. - **Zwischenspeicherung (beschleunigte Abfrage)** - Speichert temporär zwischengespeicherte Kopien von Verbunddaten in Salesforce _Data 360_. - Reduziert wiederholte Abfragekosten und Latenz für häufig aufgerufene Datensets mit konfigurierbarer Dauer (Minuten bis Tage). - Die Daten werden nicht dauerhaft kopiert oder vollständig verwaltet. Daher wird die Aktualisierung über geplante Aktualisierungen aus der Quelle verwaltet. - _Die inkrementelle Aktualisierung_ unterstützt nur das Einfügen von Aktualisierungen. Gelöschte Datensätze werden nicht aus dem Cache entfernt. - Führen Sie regelmäßig eine vollständige Aktualisierung aus, um sicherzustellen, dass der Cache mit der Quelle synchron bleibt. - **Hinweis:** Der _Snowflake-_Konnektor unterstützt die Funktion _Entladen_, die die Beschleunigungsraten durch Verwendung eines von Snowflake initiierten Staging-Buckets erhöht. Dies ist standardmäßig aktiviert, kann jedoch durch Bearbeiten der Verbindung deaktiviert werden. - **Dateiverbund** - Bietet direkten schreibgeschützten Zugriff auf umfangreiche Datensets in Objektspeichern (z. B. _S3_ und _GCS_ mit _Iceberg_). - Geeignet für AI/ML-Arbeitslasten, historische Analysen und Berichte auf Petabyte-Skala, ohne Daten verschieben zu müssen. - Die Abfrageleistung hängt stark vom Objektformat, der Partitionierung und der Netzwerk-I/O ab. Große Scans können erhebliche E/A-Werte generieren, wenn sie nicht optimiert sind. #### Architect Playbook (Playbook für Architekten) - **Anwendungsfälle** - **Echtzeitpersonalisierung und adaptive Workflows** bieten dynamische Angebote, Empfehlungen und Next-Best-Aktionen, wenn sich das Kundenverhalten ändert. - **Live-Dashboards und operative Analysen** unterstützen geschäftskritische Dashboards und KPIs direkt aus externen Lagerhäusern. - **AI/ML-Modelltraining mit großen externen Datensets** nutzt Daten im Petabyte-Bereich aus Data Lakes und Lagerhäusern, ohne sie per Dateiverbund zu verschieben. - **Branchenszenarien** - **Einzelhandel/Medien:** Aktivieren Sie personalisierte Empfehlungen und Kundenengagement in Echtzeit, indem Sie Clickstream- oder Inhaltsinteraktionsdaten verknüpfen. - **Finanzen:** Führen Sie Betrugserkennung und Risikobewertung nahezu in Echtzeit aus, indem Sie externe Lagerhäuser abfragen, ohne sensible Daten zu duplizieren. - **Tech/Enterprise:** Unterstützen Sie cloudübergreifende Berichte, IT-Service-Dashboards und betriebliche Analysen, wenn sich Datensets in mehreren Systemen befinden. - **Designpraktiken** - **Live-Abfrage** - Wird für Abfragen mit hoher QPS und geringer Latenz verwendet, wenn die Aktualisierung wichtig ist. - Übertragen Sie Prädikate und Aggregationen an das externe System, um die Datenverlagerung über das Netzwerk zu reduzieren. - Vermeiden Sie Abfragen, die unnötig große Datenvolumen scannen. - Ziehen Sie stattdessen den Partitionszuschnitt und Filter in Betracht. - **Dateiverbund** - Greifen Sie ohne Aufnahme auf Datensets im Petabyte-Bereich in Objektspeichern zu. - Minimieren Sie Latenz- und Ausgangskosten, indem Sie den Objektspeicher in derselben Cloud-Region wie die Salesforce-Berechnung aufbewahren. - Verwenden Sie partitionierte Spaltenformate (Parquet/ORC) und Pushdown-Filter, um die E/A- und Netzwerkübertragung zu reduzieren. - Nutzen Sie den Pushdown für Abfragen und Prädikate, um Daten an der Quelle zu filtern und zu aggregieren, wodurch die Datenbewegung reduziert wird. - Vermeiden Sie regionsübergreifenden Datenzugriff – es sei denn, er ist unbedingt erforderlich –, da er I/O, Latenz und Kosten erhöht. - **Zwischenspeicherung (beschleunigte Abfrage)** - Zwischenspeichern häufig aufgerufener Datensets, um Kosten und Leistung in Einklang zu bringen. - Konfigurieren Sie Aktualisierungsintervalle, um die Frische im Vergleich zu den Abfragekosten auszugleichen. - **Compliance:** Erzwingen Sie die Governance an der Quelle, indem Sie Richtlinien zur _Sicherheit auf Zeilenebene_ und Maskierung direkt in Verbundsystemen nutzen. - Im Folgenden finden Sie einige bewährte Vorgehensweisen für einheitliches RLS und Maskierung über Plattformen hinweg: - **Verwenden Sie eine zentralisierte Unternehmens-ID.** Ordnen Sie Benutzer und Einheiten in Salesforce _Data 360_ einer eindeutigen, zentralisierten Unternehmenskennung zu, die Identitäten in externen Systemen entspricht. - **Angleichen von Sicherheitsrichtlinien.** Stellen Sie sicher, dass die Richtlinien für die Sprachausgabe und Maskierung in Verbundsystemen basierend auf der zugeordneten Identität angewendet werden. Dadurch wird die Compliance beim Abfragen externer Daten beibehalten. - **Standardisieren Sie Identitätsschemas.** Verwalten Sie konsistente Identitätsattribute (E-Mail, Benutzer-ID, Kunden-ID usw.) über alle Datenquellen hinweg, um Inkonsistenzen und Zugriffsverletzungen zu vermeiden. - **Überlegungen zu Kosten** - **Live-Abfrage:** Im Pay-per-Query-Modell fallen bei der Berechnung des externen Lake House Kosten an, die zu Spitzen mit hohem QPS führen können. Dies eignet sich für frischigkeitskritische Anwendungsfälle, in denen der Wert größer als die Kostenvariabilität ist. - **Beschleunigte Abfrage (Zwischenspeicherung):** Diese Methode senkt die Abfragekosten (im Vergleich zur _Live-Abfrage)_, indem Treffer im Quellsystem reduziert werden. Sie erhöht jedoch die Kosten für die Aufnahme von Batch-Daten beim Füllen und Aktualisieren des Cache. Dies eignet sich für häufig aufgerufene Datensets. - **Dateiverbund:** Dies ist die günstigste Speicheroption als Daten im Objektspeicher. Die Abfragekosten hängen jedoch von der Dateigröße, der Partitionierung und dem Zuschnitt ab. Dies eignet sich für historische oder Massendaten im Petabyte-Maßstab. #### Entscheidungskriterien für Nullkopiemethode | Entscheidungspunkt | Live-Abfrage | Zwischenspeicherung (beschleunigte Abfrage) | Dateiverbund | | :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Datenquellenstandort** | Externe Data-Lake-Häuser (z. B. _Snowflake_, _Google BigQuery_, _Redshift_ und _Databricks_) | Externe Data-Lake-Häuser (z. B. _Snowflake_, _Google BigQuery_, _Redshift_ und _Databricks_) | Objektspeicher oder Cloud-Data-Lakes (z. B. _S3_, _ADLS_ und _GCS_), die häufig Open-Table-Formate wie _Iceberg_ verwenden. | | **Zweck/Anwendungsfall** | Geeignet für interaktive Analysen und Echtzeit-Dashboards. Geeignet für Echtzeitpersonalisierung und dynamische Workflows. | Geeignet für häufige Abfragen, aber leicht veraltete Ergebnisse sind akzeptabel. Geeignet für BI-Dashboards und Segmentierung. | Geeignet für die Batchverarbeitung im großen Umfang und für AI/ML-Modellschulungen. Geeignet für historische Analysen und Berichte auf Petabyte-Skala. | | **Frisch/Latenz** | Bietet maximale Aktualität Führt Abfragen direkt in Echtzeit aus. Unterstützt Entscheidungen innerhalb von Sekunden, wenn das Quellsystem für Abfragen mit geringer Latenz und effektivem Pushdown für Prädikate optimiert ist. | Wird verwendet, wenn leicht veraltete Ergebnisse akzeptabel sind. Die Aktualisierung hängt vom Cache-Intervall ab, das zwischen 15 Minuten und 7 Tagen konfiguriert werden kann. | Geeignet für chargenintensive, durchsatzintensive Aufträge. Nicht für Echtzeit-Dashboards geeignet. | | **Zugriffsmuster** | Geeignet für seltene oder Ad-hoc-Abfragen, bei denen die Aktualität entscheidend ist und das Abfragevolumen gering ist. Die Kosten steigen bei hoher QPS erheblich an. Daher ist es wichtig, die Zwischenspeicherung (beschleunigte Abfrage) auszuwerten, wenn die Abfragehäufigkeit hoch ist. | Geeignet für Szenarien mit hoher Lesehäufigkeit. Verbessert die Leistung bei häufigen Zugriffsmustern. | Bietet *nur Lesezugriff*. Geeignet für Datensets im Petabyte-Bereich ohne Aufnahme. | | **Leistungstreiber** | Stark von der Leistung des externen Quellsystems abhängig. Geeignet für den Fall, dass Prädikate und Aggregationen an die Quelle übertragen werden können. | Verringert die Latenz im Vergleich zu wiederholten Live-Abfragen. Die Leistung hängt von der Cache-Verwaltung und den Intervallen ab. | Die Leistung hängt stark vom Objektformat, der Partitionierung und dem externen Systemdurchsatz ab. Verwenden Sie partitionierte, spaltenförmige Formate (Parquet/ORC). | | **Kostenauswirkungen** | Hierbei handelt es sich um ein Pay-per-Query-Modell. Daher fallen bei externen Lake House-Berechnungen Kosten an. Dies ist für seltene Abfragen kosteneffektiv, kann jedoch bei hohem QPS-Volumen zu hohen Ausgaben führen. | Die Kosten sind niedriger als bei wiederholten Live-Abfragen. Dadurch müssen die externen Quellen nicht mehr wiederholt abgefragt werden, es werden jedoch Cache-Speicher und Aktualisierungs-Overhead hinzugefügt. | Dies ist die günstigste Speicheroption. Bei AWS-Setups mit derselben Region (z. B. _S3_ in US-Ost-1 mit einem _Data Cloud-_Mandanten, der sich ebenfalls in US-Ost-1 befindet) werden die Gutschriften für die Zeilen, auf die zugegriffen wird, nicht verbraucht. Regions- oder Cloud-übergreifende Konfigurationen (z. B. _Azurblau_, _GCS_ oder verschiedene _AWS-_Regionen) führen zu einem Gutschriftsverbrauch für die Zeilen, auf die zugegriffen wird. Die Abfragekosten hängen auch von der Dateigröße, der Partitionierung und der Optimierung des Prädikat-Pushdowns ab. | | **Wichtige Überlegungen** | Vermeiden Sie ungefilterte Abfragen, die unnötig große Datenvolumen scannen. | Für diesen Ansatz ist eine Cache-Verwaltung erforderlich. Nicht für Entscheidungen im Sekundenbereich geeignet. | Die Abfrageleistung hängt stark von der Optimierung über Partitionierung und Pushdown-Prädikate ab. | ### Hybridansatz Mit hybriden Architekturen können Architekten wichtige Datensets in _Data 360_ verankern und gleichzeitig Verbundabfragen für Aktualität, reduzierte Duplikate und skalierbaren Zugriff auf große externe Datensets nutzen. Bei diesem Ansatz werden die Anforderungen an E/A, Berechnungslokalität, Kosten und Compliance abgewogen. #### Hybride Anwendungsfälle Verwenden Sie einen hybriden Ansatz für ausgewogene Verwaltung, Aktualität und betriebliche Effizienz, indem Sie Datenaufnahme und Nullkopie kombinieren, um handlungsrelevante Statistiken in Echtzeit bereitzustellen. Verwenden Sie die Aufnahme für hochwertige, regulierte Datensets, bei denen Rückverfolgbarkeit, RLS und Maskierung erforderlich sind, und die Zuordnung für vorübergehende Datensets oder Datensets mit hohem Volumen, bei denen Aktualität und Leistung entscheidend sind. Hybridansatz – Übersicht #### Architect Playbook (Playbook für Architekten) - **Anwendungsfälle** - **Omnikanal-Engagement:** Kombinieren Sie historische Kundendaten mit Echtzeitverhalten, um konsistente, kontextbezogene Erfahrungen bereitzustellen. - **AI/ML-Pipelines:** Trainieren Sie Modelle für zusammengestellte kanonische Datensets und reichern Sie sie mit Roh- oder Echtzeitsignalen aus externen Quellen an. - **Kombinierte Compliance- und Agilitätsanforderungen:** Wenden Sie strenge Governance-Vorschriften für sensible Daten an und eine Verbundorganisation für betriebliche Agilität. - **Branchenszenarien** - **Einzelhandel:** Verwenden Sie die _Integration_ für die Identitätsbestimmung und die Profilvereinheitlichung und _die Zuordnung_ für Echtzeitangebote und Personalisierung. - **Gesundheitswesen:** Verwalten Sie goldene Patientenakten per _Integration_, während Sie _eine Verbundverbindung für_ IoT-Geräteströme und Sensordaten verwenden, um einen unmittelbaren Kontext zu erhalten. - **Financial Services:** Nehmen Sie regulierte Daten in einen konformitätsgesteuerten See auf, während Sie _den Verbund_ für externe Abfragen zur Betrugserkennung und Risikoüberwachung verwenden. - **Designpraktiken** - **Anker-Governance mit Aufnahme:** Nehmen Sie hochwertige oder regulierte Daten in kanonische Modelle auf, um Trust und Compliance zu gewährleisten. - **Verbund für Frische verwenden:** Ermöglicht es externen Lake Houses, Datenzugriff in Echtzeit oder in großem Umfang ohne Duplikate bereitzustellen. - **Balance Cost vs Performance (Saldokosten im Vergleich zur Leistung):** Profilarbeitslasten, um zu bestimmen, wann _die Aufnahme_ im Vergleich zum _Verbund_ verwendet werden soll, wodurch unnötige Speicher- und Abfragekosten minimiert werden. - **Anwenden der mehrschichtigen Unternehmensführung:** Erzwingen Sie die zentralisierte Verwaltung für aufgenommene Daten und nutzen Sie gleichzeitig die Sicherheitssteuerungen für Verbundsysteme (z. B. RLS und Maskierung). - **Hinweis:** Wenn Sie hybride Pipelines entwerfen, ist es wichtig, die inkrementelle Aufnahme historischer Datensets sicherzustellen und Aggregationen oder Filter an Verbundquellen zu übertragen, um die E/A- und Berechnungsnutzung zu optimieren. - **Überlegungen zu Kosten** - Wägen Sie die Gesamtkosten im Vergleich zur Leistung ab, indem Sie die _Aufnahme_ für Compliance- oder wichtige Daten mit dem _Verbund_ kombinieren, wenn eine Aktualisierung erforderlich ist. - Berücksichtigen Sie die E/A- und Berechnungsverteilung beim Mischen von _Aufnahme_ und _Verbund_. Verwenden Sie die Zwischenspeicherung (beschleunigte Abfrage) für Verbunddatensets mit hohem Lesezugriff, um die Rechenkosten für wiederholte Abfragen in Quellsystemen zu reduzieren. - Verwenden Sie diese Regel, um die Entscheidung über die Aufnahme im Vergleich zum Verbund festzulegen: Wenn häufig auf Daten zugegriffen wird, sich diese jedoch selten ändern, ist die _beschleunigte Abfrage_ in der Regel kostengünstiger. Wenn sich die Daten jedoch häufig ändern (bezogen auf die Zugriffshäufigkeit), ist die _Live-Abfrage_ oder -_Aufnahme_ besser geeignet. Hier einige Kostenbeispiele: - **Beschleunigungsgewinne:** Ein Dashboard, das aus 1 Million Datensätzen erstellt und täglich mit etwa 10.000 Änderungen aktualisiert wird, wird 20 Mal pro Tag angezeigt. Die _Beschleunigungskosten_ belaufen sich auf etwa 600 Gutschriften/Monat im Vergleich zu 4.200 Gutschriften/Monat für _Live-Abfragen_. - **Live-Abfrage gewinnt:** Segmente, die 20 Mal pro Tag veröffentlicht werden und Daten verwenden, die sich alle 30 Minuten ändern. _Live-Abfragen_ kosten etwa ~4.200 Credits/Monat im Vergleich zu ~28.800 Credits/Monat für die _Beschleunigung_ bei dieser Aktualisierungshäufigkeit. ## Leitfaden zur Anwendungsfallentscheidung Sehen wir uns einige gängige Archetypen genauer an, die die Anwendung dieser Logik veranschaulichen. - **Der Archetyp "Single Source of Truth" (Einzelne Datenquelle): Zentralisieren und Verwalten** - **Szenario:** Sie müssen kompatible, vereinheitlichte _Customer 360_ Profile für Ihr gesamtes globales Unternehmen erstellen. Die Daten stammen aus einem Dutzend verschiedener Systeme, müssen strenge _DSGVO-_ und _CCPA-_Vorschriften einhalten und dienen als Quelle der Wahrheit für alle Marketing- und Serviceinteraktionen. - **Empfohlenes Muster:** **Datenaufnahme.** Hier stehen Governance, Trust und Kontrolle im Vordergrund. Die Aufnahme der Daten in _Data 360_ ist die einzige Möglichkeit, ein vollständig überprüfbares, kanonisches Profil zu erstellen, das von den Quellsystemen isoliert ist. - **Der Archetyp "Echtzeitstatistiken": Analysieren ohne Verschieben** - **Szenario:** Ihr Data Science-Team muss Erkundungsabfragen für eine massive, ständig aktualisierte Transaktionstabelle in _Snowflake_ ausführen. Gleichzeitig möchte Ihr Führungsteam ein Live-_BI-_Dashboard, das auf denselben Daten basiert. Das tägliche Verschieben von Petabyte Daten ist langsam und teuer. - **Empfohlenes Muster:** **Zero Copy Federation.** Die Priorität liegt dabei auf Geschwindigkeit, Agilität und Kosteneffizienz im richtigen Maßstab. Mit _Zero Copy_ können Sie die Leistungsfähigkeit Ihres vorhandenen Data Warehouse für Echtzeitabfragen nutzen, ohne den Aufwand und die Latenz der Datenduplizierung zu erhöhen. - **Der Archetyp "Hybridintelligenz": Verwalten des Kerns, Zusammenführen des Kerns** - **Szenario:** Sie möchten Ihre verwalteten, aufgenommenen Kundenprofile mit Echtzeit-Verhaltenssignalen (z. B. Website-Klicks) aus einem Data Lake anreichern. Sie benötigen die Stabilität des Kernprofils, aber die Unmittelbarkeit der Live-Daten, um die sofortige Personalisierung zu unterstützen. - **Empfohlenes Muster:** **Ein hybrider Ansatz.** Verwenden Sie die _Datenaufnahme_, um einen stabilen, geregelten Kern für Ihre Kundendaten zu erstellen. Verwenden Sie _Nullkopie_, um die volatilen Echtzeit-"Edge"-Daten zu verknüpfen und dann zur Abfragezeit miteinander zu verknüpfen, um eine vollständige, sekundengenaue Ansicht zu erhalten. ## Der Weg nach vorn Bei der Unternehmensdatenstrategie geht es nicht mehr darum, ein einzelnes Integrationsmuster auszuwählen, sondern darum, kontrollierte Flexibilität in einem interoperablen Datenökosystem zu entwickeln. Der richtige Ansatz ordnet jedes Quellsystem dem Muster zu, das seinen Anforderungen an Aktualität, Verwaltung, Kosten und Zugriff am besten entspricht: - Nehmen Sie geschäftskritische, regulierte Datensets in Salesforce _Data Cloud_ auf, um Compliance, Identitätsbestimmung und betriebliche Workflows zu gewährleisten. - Verbinden Sie Daten über _Nullkopie_ für Live-, explorative und AI-gestützte Analysen, ohne Speicher zu duplizieren. - Anwenden von _Caching (beschleunigte Abfrage)_ zum Reduzieren der Quellsystemlast und des Guthabenverbrauchs bei hoher Abfragehäufigkeit und niedriger Datenänderungshäufigkeit Salesforce _Data 360_ in _Hyperforce_ bietet Widerstandsfähigkeit und Skalierbarkeit für mehrere Regionen. Das offene Lake House mit _Iceberg-_Tabellen ermöglicht die Berechnungstrennung und Interoperabilität mit Plattformen wie _Snowflake_, _Databricks_ und _S3 Iceberg, die_ das Rückgrat eines wirklich interoperablen Multi-Cloud-Datenökosystems bilden. Während sich Datenökosysteme weiterentwickeln, müssen wir kontinuierlich zwischen Aktualität, Kosten, Leistung und Compliance abwägen, um die architektonische Agilität aufrechtzuerhalten. Daher ist es wichtig, Ihre Plattform zukunftssicher zu gestalten, indem erfasste, geregelte Daten mit Verbundzugriff vereinheitlicht werden. Dies ermöglicht Echtzeitintelligenz, AI-Aktivierung und Personalisierung im Unternehmensbereich über Clouds, Regionen und Geschäftsdomänen hinweg. Beachten Sie, dass Lösungen für die einheitliche Größe für die meisten Unternehmen nicht geeignet sind. Die optimale Strategie ordnet das richtige Muster dem richtigen Geschäftstreiber zu. ## Über die Autoren **Yugandhar Bora** ist Software-Entwickler bei Salesforce und hat sich auf die Datenarchitektur innerhalb der Plattform für Daten- und Intelligenzanwendungen spezialisiert. Er leitet Initiativen des _Enterprise Architecture Review Board (EARB)_, die sich auf Datenverwaltung und vereinheitlichte Datenmodelle konzentrieren und gleichzeitig zu automatisierten Plattformbereitstellungslösungen beitragen. **Jan Fernando** ist Principal Architect im _Office of the Chief Architect (OCA)_ bei Salesforce und seit 2012 bei Salesforce tätig. Vor seiner Tätigkeit beim OCA war er über ein Jahrzehnt in der _Plattformorganisation_ tätig, wo er mehrere wichtige Technologietransformationen leitete. # Datenintegration in Salesforce Es gibt eine Vielzahl von Möglichkeiten, auf Daten zwischen Salesforce und externen Systemen zuzugreifen, sie zu synchronisieren und freizugeben. Aber nicht jedes Tool ist für Ihr jeweiliges Projekt geeignet. Dieser Leitfaden führt Sie durch die Landschaft der Datenintegrationstools, die von Salesforce verfügbar sind. Sie bietet auch Empfehlungen für die Tools (oder Kombinationen von Tools), die für einen bestimmten Anwendungsfall am besten geeignet sind, sowie Anleitungen zu Tools, die für bestimmte Szenarien vermieden werden sollten. ## Leitfadenübersicht Dieser Entscheidungsleitfaden konzentriert sich auf Integrationen auf Datenebene, die Salesforce betreffen. Insbesondere deckt sie die folgenden Datenintegrationsanwendungsfälle ab: - Salesforce für externe Systeme - Externe Systeme für Salesforce - Salesforce-Organisation zu Salesforce-Organisation Dies ist nur ein Teil der Integrationsherausforderungen, mit denen Salesforce-Architekten konfrontiert sind. Daher planen wir, weitere Entscheidungsleitfäden hinzuzufügen, die sich auf die ereignisgesteuerte Integration konzentrieren, effektive Workflows für Kunden oder Mitarbeiter mithilfe der Prozessintegration erstellen usw. Schließlich ist es wichtig zu beachten, dass viele der hier beschriebenen Tools und Ansätze verwendet werden können, um Integrationsherausforderungen im gesamten Unternehmen zu lösen. Solche Anwendungen sprengen jedoch den Umfang dieses Leitfadens. ## Takeaways - **Vermeiden Sie unnötige Datenreplikationen.** Sofern sich die Daten nicht unbedingt in Salesforce befinden müssen, sollten Sie stattdessen die Datenvirtualisierung mit Salesforce Connect in Erwägung ziehen. Mehr Daten in Ihrer Organisation führen letztlich zu größeren Datenvolumen, was sich negativ auf [die Leistung](/docs/architect/de-de/well-architected/guide/reliability.html#scalability-and-capacity-planning) auswirken und zu höheren technischen Schulden führen kann. Wenn sich Ihre Daten bereits in Salesforce befinden und Sie sie in einem externen System benötigen, sollten Sie vermeiden, sie in ein externes System zu kopieren, sofern dies nicht unbedingt erforderlich ist. Lassen Sie das externe System stattdessen über die Salesforce-APIs auf die Daten zugreifen. - **Verwenden Sie MuleSoft oder andere Enterprise Service Bus-Lösungen (ESB) oder ETL-Lösungen (Extract-Transform-Load), sofern verfügbar und Teil Ihrer vorhandenen Landschaft.** Da diese Tools entwickelt wurden, um die Datenmigration und -transformation zu unterstützen, verfügen sie oft über leistungsstarke Funktionen, mit denen Sie Integrationen im gesamten Unternehmen wiederverwenden, eine stärkere Unternehmensführung aufrechterhalten und die Verwaltung von Integrationen zentralisieren können. Überlegen Sie in dieser Anleitung, wo immer MuleSoft Anypoint empfohlen wird, ob Ihre vorhandene ESB/ETL-Lösung ausreicht. - **Harmonisieren Sie Daten aus verschiedenen Quellen mit Data 360 und Data Cloud One.** Über das Customer 360-Datenmodell, die Identitätsbestimmung, den Datenverbund und andere Funktionen konsolidiert Data 360 Daten aus Salesforce und anderen externen Systemen in einer einheitlichen Ansicht Ihres Kunden. Mit [Data Cloud One](/docs/architect/de-de/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one) können Benutzer in anderen Salesforce-Organisationen sicher über Datenbereiche auf Daten zugreifen, die virtuell aus Data 360 freigegeben wurden. - Verschieben Sie Daten zwischen Organisationen mithilfe von **Data 360-Aktionen und -Aktivierungen.** Nachdem Daten aus verschiedenen Organisationen in Data 360 aufgenommen wurden, können Datenaktionen [und Aktivierungen](/docs/architect/de-de/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound) die Daten mit einer anderen Organisation synchronisieren. Dieser Ansatz kann für Integrationen in Marketing Cloud-Organisationen sehr nützlich sein. - Extrahieren und verschieben Sie Daten mit **MuleSoft Anypoint.** MuleSoft Anypoint kann verwendet werden, um Daten aus Data 360 mithilfe der Connect-API und der Datendiagramm-API zu extrahieren und in eine andere Salesforce-Organisation zu verschieben. Ohne Data 360 kann MuleSoft Anypoint auch verwendet werden, wenn Daten zwischen Organisationen verschoben werden müssen, ohne dass sie in Data 360 repliziert werden. - **Gehen Sie mit Bedacht vor, wenn Sie sich für die Erstellung mit ausgehendem Messaging entscheiden.** Salesforce wird ausgehendes Messaging im Rahmen der aktuellen Funktionskapazitäten weiterhin unterstützen, plant jedoch keine weiteren Investitionen in diese Technologie. - **Für alle Integrationen wird immer die Integrationsbenutzerlizenz mit dem Profil "Nur API" empfohlen.** Salesforce empfiehlt zudem die Verwendung von externen Client-Anwendungen (zugunsten verbundener Anwendungen oder SOAP-Anmeldung) als ordnungsgemäß autorisierte AuthN- und AuthZ-Muster für alle Integrationen. ## Allgemeine Überlegungen zur Auswahl von Datenintegrationstools Bevor Sie sich mit den verfügbaren Datenintegrationstools vertraut machen, sollten Sie bei der Auswahl eines Tools einige allgemeine Überlegungen berücksichtigen. Wie bei der Architektur üblich, gibt es nicht jede präskriptive Antwort auf jede geschäftliche Herausforderung. Wenn Sie bei Integrationsentscheidungen die Worte "es kommt darauf an" ausgesprochen haben, sind Sie an der richtigen Stelle.
Zu berücksichtigender Bereich Allgemeine Fragen
Vorhandene Tools und Landschaft Gibt es eine vorhandene ESB- oder ETL-Lösung? Verfügen die beteiligten Daten über gesetzliche oder Compliance-Anforderungen? Wo befinden sich die Systeme, die Sie integrieren möchten (in der Cloud oder vor Ort)?
Datenfluss (Zeiteinteilung, erwartete Benutzererfahrung, Richtung) Müssen die Daten synchron oder asynchron verschoben werden oder können sie als Batch oder Plan erstellt werden? Ist ein Datenabgleich erforderlich? Welches System sollte die Quelle der Wahrheit sein? Was ist die Datenquelle? Was ist das Ziel? Ist eine Benutzerinteraktion erforderlich? Muss der Benutzer das Ergebnis der Integration sehen? Was sind die Anforderungen an die Verarbeitung von Ausnahmen (Wiederholen, Benachrichtigen, Fehlschlagen)? Wie eng sollten Systeme gekoppelt sein?
Implementierung Wie hoch ist der Aufwand für Nicht-Salesforce-Systeme? Welche Teams sind für die Bereitstellung von Integrationen verantwortlich? Welche Tools verwenden sie bevorzugt?
Wartbarkeit Von welchen Teams wird erwartet, dass sie die Integration pflegen? Welche Fertigkeiten verfügen sie derzeit? Welche Fertigkeiten benötigen sie in Zukunft? Wie hoch sind die Gesamtbetriebskosten im Laufe der Zeit? Wie wichtig ist die Fähigkeit zum Testen, Debuggen und zur Fehlerbehebung mit Low- oder Pro-Code-Tools?
Datenvolumen Wie viele Daten sind an der Integration beteiligt? Arbeiten Sie mit Large Data Volumes (LDV)? Wie häufig werden Änderungen per Massenvorgang vorgenommen? Welche Auswirkungen haben Singleton-Aktualisierungen? Wie oft werden sie auftreten?
Obergrenzen Müssen die Daten einer komplexen Transformation unterzogen werden? Müssen die Daten aus mehreren Quellsystemen kombiniert werden? Wie oft erfolgt eine Integration pro Benutzer? Wie viele Benutzer insgesamt? Haben Sie für Massendatenladungen im Voraus geplant (Beispiel: anfängliches Laden von Daten für eine neue Instanz)?
## Produktvergleich Im Folgenden finden Sie eine allgemeine Übersicht über die für die Datenintegration verfügbaren Tools und einige Überlegungen, mit der Auswertung der einzelnen Optionen zu beginnen. Die folgenden Abschnitte enthalten ausführliche Anwendungsfälle und Details zu den Funktionen dieser Tools.
Von Salesforce zum externen System Vom externen System zu Salesforce Ausführung Zusätzliche Lizenz erforderlich
Apex Aktionen Verfügbar Verfügbar Serverseitig Nein
Datenerfassung ändern Verfügbar Nicht verfügbar Serverseitig Nein*
Benutzerdefiniertes Apex (REST- und SOAP-Webservices) Verfügbar Verfügbar Serverseitig Nein
Externe Services Verfügbar Nicht verfügbar Serverseitig Nein
Heroku Connect Verfügbar Verfügbar Serverseitig Ja
Daten 360 Verfügbar Verfügbar Serverseitig Ja
MuleSoft Anypoint Verfügbar Verfügbar Serverseitig Ja
Native Salesforce-APIs Nicht verfügbar Verfügbar Serverseitig Nein
OmniScript Verfügbar Verfügbar Clientseitig*** Ja
OmniStudio-Integrationsverfahren Verfügbar Verfügbar Serverseitig Ja
Ausgehendes Messaging Nicht ideal Nicht verfügbar Serverseitig Nein
Plattformereignisse Verfügbar Verfügbar Serverseitig Nein**
Salesforce Connect / Externe Objekte Verfügbar Verfügbar Serverseitig Ja
[\*Für Anwendungsfälle der Ereigniserfassung bei Änderungen mit hohem Volumen erforderliches Add-On](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm) [\*\*Add-On für Anwendungsfälle von Plattformereignissen mit hohem Volumen erforderlich](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) \*\*\*Geeignet in Situationen, in denen es in Ordnung ist, dass Geschäftslogik im Webbrowser ausgeführt wird. Spaltenlegende: - **Verfügbar**: Funktioniert für die meisten Anwendungsfälle - **Nicht ideal**: Möglich, aber erwägen Sie ein alternatives Tool - **Nicht verfügbar**: Keine Pläne für Support in den nächsten zwölf Monaten ### Weitere Tools zum Verschieben von Daten in und aus Salesforce Es gibt andere Tools, die einige Aspekte einer Datenebenenintegration unterstützen, jedoch nicht als primäres Mittel zur Lösung von Integrationsproblemen angesehen werden dürfen. Sehen wir uns diese Tools jetzt kurz an. **Lightning Web Components** werden in der Regel für Prozessintegrationen verwendet, sie können jedoch Callouts mithilfe von JavaScript-Funktionen vornehmen, sodass Daten an diesen Transaktionen beteiligt sein könnten. Mit **dem Salesforce-Flow** können externe Callouts mit externen Services oder Apex-Aktionen orchestriert werden. Salesforce-Flow allein gilt nicht als eigenständiges Datenintegrationstool. **Der Datenimport-Assistent** kann zum Synchronisieren, Importieren und Migrieren von Daten verwendet werden. Data Loader-Befehle können auch skriptbasiert ausgeführt werden, um den Import und Export von Daten zu automatisieren. Die [Befehlszeilenschnittstelle](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm) ist jedoch nur für Windows vorgesehen und keines dieser Tools ist eine empfohlene Grundlage für eine Datenintegrationsstrategie. Verwenden Sie sie stattdessen als Ergänzung zu Ihrer Datenverwaltungs- und Wartungsstrategie. Mit [**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm)-Datenbefehlen können Sie Datensätze in Ihrer Organisation bearbeiten. Es sind Befehle verfügbar, mit denen Sie Daten mit der Bulk-API und der SObject Tree Save API importieren und exportieren und einfache CRUD-Vorgänge für einzelne Datensätze mit der REST-API ausführen können. Die Salesforce CLI allein gilt nicht als eigenständiges Datenintegrationstool. **OmniStudio Data Mapper** kann als deklaratives ETL-Tool verwendet werden, um Daten zwischen Salesforce-Objekten und JSON-Datenstrukturen zu verschieben. Obwohl für jede Datenzuordnungsschnittstelle automatisch eine REST-Schnittstelle erstellt wird, die eine deklarative Möglichkeit zum Verschieben von Daten aus externen Systemen in Salesforce-Objekte bietet, ist Data Mapper allein keine empfohlene Grundlage für eine Datenintegrationsstrategie. Datenzuordnungsaktionen sind in OmniStudio-Integrationsverfahren verfügbar. [**Dataloader.io**](http://dataloader.io/) ist ein weiteres Datenladetool für Salesforce, das auf der Anypoint Platform von MuleSoft basiert und Ihnen das schnelle und sichere Importieren, Exportieren und Löschen unbegrenzter Datenmengen für Ihr Unternehmen ermöglicht. Dataloader.io ist keine empfohlene Grundlage für eine Datenintegrationsstrategie. ## Salesforce zu externen Systemen (Ausgehende Integration) Bei ausgehenden Integrationen von Salesforce können Sie verschiedene Arten von Tools in Betracht ziehen: Low-Code, Pro-Code oder ein Hybrid. In den folgenden Abschnitten finden Sie Anleitungen für jeden dieser Werkzeugtypen und Beispiellösungen. - [Tools mit niedrigem Code für ausgehende Integrationen](#low-code-tools-für-ausgehende-integrationen-von-salesforce) - [Hybridtools für ausgehende Integrationen](#hybridtools-für-ausgehende-integrationen-von-salesforce) - [Pro-Code-Tools für ausgehende Integrationen](#pro-code-tools-für-ausgehende-integrationen-von-salesforce) ### Low-Code-Tools für ausgehende Integrationen von Salesforce
Anleitung Lizenzierung Zeitpunkt Volumen und Skalierung Lieferung & Wartung Datenschutz und Sicherheit
Anwendungszeitpunkt Zusätzliche Lizenz Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen) Unterstützung von mehreren Objekten LDV/Masse Testen und Bereitstellen** Debugging Eingebautes Fehlerverarbeitungs-/Wiederholungsverhalten Kann mit im Leerlauf verschlüsselten Daten verwendet werden Authentifizierungsprotokoll
Datenerfassung ändern Wenn Sie in Salesforce vorgenommene Änderungen auf Datensatzebene in einem externen System veröffentlichen müssen und keine benutzerdefinierte Nutzlast benötigen. Erforderlich Asynchron Nein Nein Ja Mit Pro-Code-Tools Ja Ja OAuth
Externe Services Wenn Sie einen Prozess mit Flow, Apex, Einstein Bots oder OmniStudio orchestrieren, werden die APIs des externen Systems mit OpenAPI-Spezifikationen beschrieben. Nicht erforderlich Sync Ja Nein Ja Mit Pro-Code-Tools Nein N/A Anmeldeinformationen mit Namen
Heroku Connect Wenn Sie Ihre Daten mit bidirektionaler Synchronisierung erweitern möchten, um mobile und andere Anwendungen in Heroku zu aktivieren, und Sie möchten, dass die Daten auch in Salesforce repliziert werden. Erforderlich Asynchron Ja Ja Nein Mit Proficode-Tools Ja Ja, über Shield Connect OAuth
OmniStudio-Integrationsverfahren Wenn Sie Daten ohne Benutzerinteraktion umwandeln und die Leistung durch Verarbeitung auf dem Server statt im Browser verbessern müssen. Erforderlich Beides Ja Ja Ja Deklarative Unterstützung Ja Ja Anmeldeinformationen mit Namen
Salesforce Connect / Externe Objekte Wenn Daten auf der Salesforce-Benutzeroberfläche angezeigt werden sollen, die Daten jedoch in einem externen System gespeichert werden sollen. Daten werden nicht in Salesforce repliziert. Erforderlich Sync Nein Ja* Ja Mit Pro-Code-Tools und deklarativer Verfolgung Nein N/A Anmeldeinformationen mit Namen
* Für Odata Adapter, die älter als Version 4.01 sind, gelten Callout-Obergrenzen. Weitere Details finden Sie unter Überlegungen zur Odata Callout Rate Limit (Obergrenze für Odata-Callouts). ** Testen und Bereitstellen bezieht sich auf die Möglichkeit, in einer niedrigeren Umgebung zu erstellen und über die Metadaten-API, Pakete oder Änderungssets in der Produktion bereitzustellen.
### Anwendungsfall: Ausgehende Integration mit Low-Code-Tools > Wenn Opportunities gewonnen wurden, muss ein Auftrag für die zugeordneten Produkte im ERP-System oder Auftragsverwaltungssystem des Unternehmens erstellt werden. **Datenerfassung ändern** Wenn Opportunity-Datensätze aktualisiert werden, veröffentlicht die Datenerfassung ändern Änderungsereignisse, die die Aktualisierungen an den Objekten enthalten. Die Änderungsereignisse werden auf Kundenseite über eine CometD-Verbindung (oder über einen MuleSoft-Konnektor) verwendet und zum Aktualisieren des ERP- oder Auftragsverwaltungssystems des Kunden verwendet. Änderungsereignisse können so angereichert werden, dass immer externe Datensatz-IDs oder andere Daten aus dem Objekt (z. B. Region) enthalten sind, die für die Integration erforderlich sind. Änderungsereignisströme für mehrere Objekte können zu _Kanälen_ kombiniert werden, um die Abonnement- und Stream-Verarbeitung zu vereinfachen (so können Sie einen Stream abonnieren und verarbeiten statt viele). **Externe Services** Wenn Sie über einen Webservice verfügen, der die OpenAPI 2.0- oder 3.0-Spezifikation unterstützt, können Sie die Vorgänge und Services in Salesforce als externen Service bereitstellen. Die API-Vorgänge (beispielsweise "Auftrag erstellen") können in einem mit Flow Builder erstellten Flow als aufrufbare Aktion aufgerufen werden, wenn die Phase der Opportunity zu "Gewonnen" geändert wird. **Heroku Connect** Heroku Connect wird in der Regel verwendet, um eine Heroku Postgres-Datenbank und Salesforce synchron zu halten. Wenn der Kunde Heroku Postgres als Transaktionsspeicher für die Quelle der Wahrheit verwendet, können Sie die Datensätze und die Änderungen von Salesforce zu Heroku Postgres mit Heroku Connect synchronisieren. Von dort aus können Sie Heroku Streaming-Konnektoren verwenden, um diese Änderungen in Apache Kafka zu veröffentlichen und als Ereignisse an nachgelagerte Anwendungen zu senden, einschließlich des ERP- oder Auftragsverwaltungssystems. **OmniStudio-Integrationsverfahren** Wenn ein Auftrag gesendet wird, kann das OmniScript, das den Prozess orchestriert, die Auftragsdetails an einen ERP- oder MuleSoft-Konnektor senden. Der Post kann entweder direkt vom OmniScript (clientseitig) oder indirekt über ein Integrationsverfahren (serverseitig) ausgeführt werden. Wenn das ERP-System einen Validierungsfehler auslöst, muss die OmniScript-Benutzeroberfläche den Benutzer benachrichtigen und den Fehler bei Bedarf übersetzen und kontextualisieren. **Salesforce Connect / Externe Objekte** Sie können einen durch einen Datensatz ausgelösten Flow in Salesforce erstellen, der einen Datensatz in die zugehörigen externen Objekte einfügt, wenn die Phase der Opportunity zu "Gewonnen" geändert wird. Da es sich um eine [gemischte Transaktion](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1) handelt, fügen Sie zwischen der Opportunity-Aktualisierung und dem oder den zugehörigen externen Objekten ein Pausenelement für null Sekunden hinzu, damit Sie einen Transaktionskontext schließen, bevor Sie einen neuen starten. ### Hybridtools für ausgehende Integrationen von Salesforce
Anleitung Lizenzierung Zeitpunkt Volumen und Skalierung Lieferung & Wartung Datenschutz und Sicherheit
Anwendungszeitpunkt Zusätzliche Lizenz Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen) Unterstützung von mehreren Objekten LDV/Masse Testen und Bereitstellen** Debugging Eingebautes Fehlerverarbeitungs-/Wiederholungsverhalten Kann mit im Leerlauf verschlüsselten Daten verwendet werden Authentifizierungsprotokoll
Apex Aktionen Wenn Sie Callouts an ein anderes System über den Salesforce-Flow automatisieren möchten. Ein Entwickler kann eine Apex-Klasse schreiben, die ein Flow aufrufen kann, oder Sie können eine vordefinierte Lösung aus AppExchange herunterladen. Nicht erforderlich Beides Ja Nein Ja Mit Pro-Code-Tools Nein Ja Mehrere
Ereignisweiterleitungen Wenn Sie Plattformereignisse und Ereignisse der Datenerfassung über Salesforce an Amazon EventBridge senden müssen. Ereignisweiterleitungen stellen nur eine Verbindung mit AWS Eventbridge her Nein Asynchron Ja Nein Ja Ja Ja Ja HTTP/1.1 mit TLS
Ausgehendes Messaging Wenn Sie SOAP-Nachrichten über HTTP(S) an einen angegebenen Endpunkt mit garantiertem Empfang senden müssen, wenn er durch eine Workflow-Regel ausgelöst wird. Nicht erforderlich Asynchron Nein Nein Ja Deklarative Unterstützung Ja Ja Bidirektionales TLS
Plattformereignisse Wenn Sie eine benutzerdefinierte, strukturierte Nutzlast für Änderungen nahezu in Echtzeit in Salesforce oder einem externen System benötigen. Nicht erforderlich* Asynchron Ja Nein Ja Mit Pro-Code-Tools Ja Ja OAuth
Salesforce Connect / Externe Objekte (mit benutzerdefinierten Apex Adaptern) Wenn Daten auf der Salesforce-Benutzeroberfläche angezeigt werden sollen, die Daten jedoch in einem externen System gespeichert werden sollen, das keine Standardprotokolle wie Odata oder GraphQL verwenden kann. Erforderlich Beides Ja Ja Ja Mit Pro-Code-Tools Nein N/A Mehrere
Daten 360 Wenn Sie harmonisierte Daten aus verschiedenen Quellen in einem Datenspeicher wünschen oder Ihre Daten in andere Salesforce-Organisationen oder andere externe Systeme replizieren möchten. Erforderlich Beides Ja Ja Ja Ja Ja Ja Mehrere
[\* Add-On](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) für Anwendungsfälle mit hohem Volumen erforderlich. \*\* Testen und Bereitstellen bezieht sich auf die Möglichkeit, in einer niedrigeren Umgebung zu erstellen und über die [Metadaten-API](https://developer.salesforce.com/docs/metadata-coverage/), Pakete oder Änderungssets in der Produktion bereitzustellen. ### Anwendungsfall: Ausgehende Integration mit Hybridtools > Wenn Opportunities gewonnen wurden, muss ein Auftrag für die zugeordneten Produkte im ERP- oder Auftragsverwaltungssystem des Unternehmens erstellt werden. **Apex Aktionen** Ein durch einen Datensatz ausgelöster Flow, der auf dem Opportunity-Status basiert, kann automatisch ausgelöst werden, wenn eine Opportunity gewonnen wird. Der Flow führt eine aufrufbare Aktion aus, die einen externen Callout verwendet, um den Auftrag an das Auftragsverwaltungssystem oder die ERP-Lösung zu senden. Einreichungen mit hohem Volumen und Aufträge mit mehreren Sites werden von Apex Batch- und Warteschlangenmechanismen verarbeitet. **Ausgehende Nachrichten** Nach dem [Einrichten ausgehender Nachrichten](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm) können Sie eine durch die Opportunity-Aktualisierung ausgelöste Workflow-Regel definieren, um eine SOAP-Nachricht über HTTP(S) an einen angegebenen Endpunkt-URL zu senden, der den Listener hostet. Die Nachricht enthält die Felder, die bei der Erstellung der ausgehenden Nachricht angegeben wurden. Wenn sich die Informationen im Objekt ändern, nachdem die Benachrichtigung in die Warteschlange gestellt wurde, aber bevor sie gesendet wird, werden nur die aktualisierten Informationen zugestellt und die Nachrichten bleiben in der Warteschlange, bis sie erfolgreich gesendet wurden oder bis sie 24 Stunden alt sind. Nach 24 Stunden werden Nachrichten aus der Warteschlange verworfen. Wenn das ERP-System zusätzliche Daten benötigt, können Sie die sessionId in ausgehenden Nachrichten übergeben, damit das externe System eine Rückmeldungsanfrage senden kann. **Plattformereignisse** Sie können ein Plattformereignis definieren, das die benutzerdefinierte Nutzlast mit den zum Erstellen der Datensätze im externen System erforderlichen Daten enthält. Da Plattformereignisse bei der Datensatzänderung nicht automatisch veröffentlicht werden, müssen Sie das Ereignis über Apex, Salesforce-Flow oder Prozessgenerator veröffentlichen, wenn die Phase der Opportunity zu "Gewonnen" geändert wird. Ein externer Service hört den Plattformereigniskanal mit CometD (oder einem MuleSoft-Konnektor) und erstellt die entsprechenden Datensätze im externen System. **Salesforce Connect / Externe Objekte (mit benutzerdefinierten Apex Adaptern)** Eine auf Salesforce Connect / Externe Objekte basierende Lösung ist für einen Anwendungsfall, der lediglich eine Datensynchronisierung erfordert, nicht perfekt geeignet. Diese Lösung kann jedoch in Fällen angewendet werden, in denen Benutzer innerhalb von Salesforce Daten aus dem externen System anzeigen und potenziell mit ihnen interagieren müssen und die Daten nicht in Salesforce repliziert werden können. Wenn das ERP- oder Auftragsverwaltungssystem keine Odata oder GraphQL Protokolle unterstützt, kann das Entwicklungsteam das [Apex Connector Framework](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm) verwenden, um Apex Klassen zu schreiben, die die Kommunikation mit dem externen System über ein unterstütztes Protokoll abwickeln. **Data 360** Eine auf Data 360 basierende Lösung eignet sich perfekt für Anwendungsfälle, in denen harmonisierte Daten aus verschiedenen Quellen in einem Datenspeicher benötigt werden. Sie kann auch verwendet werden, wenn Daten aus einer Salesforce-Organisation in mehrere Salesforce-Organisationen oder in andere externe Systeme mit Data 360 als Datenzentrum repliziert werden müssen. Wenn eine Opportunity gewonnen und in der Quellorganisation aktualisiert wird, werden Opportunity-Daten mit Data 360 synchronisiert, wo sie in anderen Systemen, einschließlich Salesforce-Organisationen, mit unterschiedlichen Mechanismen wie Aktionen, Aktivierungen und APIs repliziert werden können. Ebenso kann auf eine Opportunity verwiesen werden, ohne die Daten in anderen Salesforce-Organisationen mit Data Cloud One zu replizieren. Data Cloud One unterstützt jedoch keine Nicht-Salesforce-Plattformen. ### Pro-Code-Tools für ausgehende Integrationen von Salesforce
Anleitung Lizenzierung Zeitpunkt Volumen und Skalierung Lieferung & Wartung Datenschutz und Sicherheit
Anwendungszeitpunkt Zusätzliche Lizenz Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen) Unterstützung von mehreren Objekten LDV/Masse Testen und Bereitstellen** Debugging Eingebautes Fehlerverarbeitungs-/Wiederholungsverhalten Kann mit im Leerlauf verschlüsselten Daten verwendet werden Authentifizierungsprotokoll
Benutzerdefinierter Apex Wenn Sie mehr Funktionen benötigen, als in Low-Code-Tools verfügbar sind. Nicht erforderlich Beides Ja Ja Ja Mit Pro-Code-Tools Nein Ja* Mehrere
Externe Services Die Integration aus Code in externe System-APIs wird mit OpenAPI-Spezifikationen beschrieben. Nicht erforderlich Sync Ja Nein Ja Mit Pro-Code-Tools Nein N/A Mehrere
MuleSoft Anypoint Wenn Sie eine einzelne einheitliche Lösung auf Unternehmensebene zum Erstellen, Orchestrieren und Verwalten Ihrer Integrationen benötigen, wenn Sie eine veraltete Punkt-zu-Punkt-Architektur ersetzen müssen oder wenn Sie API-Verwaltungsunterstützung benötigen. Erforderlich Beides Ja Ja Ja Mit Pro-Code-Tools Nein Ja* Mehrere
\* Durch Aktivieren der Shield Platform Encryption werden bestimmte Verhaltensweisen geändert, weitere Details finden Sie unter [Allgemeine Shield Platform Encryption Überlegungen](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5). \*\* Testen und Bereitstellen bezieht sich auf die Möglichkeit, in einer niedrigeren Umgebung zu erstellen und über die [Metadaten-API](https://developer.salesforce.com/docs/metadata-coverage/), Pakete oder Änderungssets in der Produktion bereitzustellen. ### Anwendungsfall: Ausgehende Integration mit Pro-Code-Tools > Wenn Opportunities gewonnen wurden, muss ein Auftrag für die zugeordneten Produkte im ERP- oder Auftragsverwaltungssystem des Unternehmens erstellt werden. **Benutzerdefiniertes Apex** Sie können einen Apex-Auslöser und einen oder mehrere Auslöser-Handler für die Opportunity erstellen, die einen Callout an das ERP- oder Auftragsverwaltungssystem senden, wenn die Phase der Opportunity zu "Gewonnen" geändert wird. Beachten Sie, dass Sie eine Methode verwenden müssen, die als future oder queueable gekennzeichnet ist, wenn Sie Callouts über einen Auslöser oder nach dem Ausführen eines DML-Vorgangs vornehmen. Ein Callout in einem Auslöser hält die Datenbankverbindung während der Lebensdauer des Callouts offen. Der gesamte Apex Code ist an [Apex Governor und API Limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm) gebunden, die laufend überarbeitet werden. **Externe Services** Wenn das externe ERP- oder Auftragsverwaltungssystem des Unternehmens über eine OpenAPI-Spezifikation definiert ist, können die Callouts für die Services, die in der Methode future oder im warteschlangenfähigen Auftrag ausgeführt werden, vereinfacht werden. Die registrierten externen Services können direkt über Apex aufgerufen werden, ohne dass Sie Boilerplate-Code schreiben müssen. Im Beispiel kann der Callout zum Erstellen des Auftrags vom externen Service verarbeitet werden. **MuleSoft Anypoint** MuleSoft Anypoint bietet API-Verwaltung auf Unternehmensebene. MuleSoft Anypoint kann APIs erstellen, um Lese- und/oder Schreibzugriff auf Daten für Salesforce und viele andere Unternehmenssysteme zu ermöglichen. Es sind [viele vorgefertigte Konnektoren verfügbar](https://www.mulesoft.com/platform/cloud-connectors), um die Implementierung zu vereinfachen, und Unternehmen können auch ihre eigenen Konnektoren erstellen und veröffentlichen. Diese APIs können in Anypoint mit flexiblen Sicherheitsrichtlinien bereitgestellt werden und unterstützen die zentrale Verwaltung und Verwaltung. Es gibt keine Einschränkungen für das Transaktionsvolumen, solange die API für ihre maximale Auslastung (gemessen in vCores) entsprechend dimensioniert wurde. ## Externe Systemdaten an Salesforce (Eingehende Integration) Bei eingehenden Integrationen in Salesforce können Sie verschiedene Arten von Tools in Betracht ziehen: Low-Code, Pro-Code oder ein Hybrid. In den folgenden Abschnitten finden Sie Anleitungen für jeden dieser Werkzeugtypen und Beispiellösungen. - [Tools mit niedrigem Code für eingehende Integrationen](#low-code-tools-für-eingehende-integrationen-in-salesforce) - [Hybridtools für eingehende Integrationen](#hybridtools-für-eingehende-integrationen-in-salesforce) - [Pro-Code-Tools für eingehende Integrationen](#pro-code-tools-für-eingehende-integrationen-in-salesforce) ### Low-Code-Tools für eingehende Integrationen in Salesforce
Anleitung Lizenzierung Zeitpunkt Volumen und Skalierung Lieferung & Wartung Datenschutz und Sicherheit
Wann zu verwenden Zusätzliche Lizenz Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen) Unterstützung für mehrere Objekte LDV/Bulk Testen und Bereitstellen* Debugging Integriertes Fehlerverarbeitungs-/Wiederholungsverhalten Kann mit im Leerlauf verschlüsselten Daten verwendet werden Authentifizierungsprotokoll
Heroku Connect Wenn Sie Ihre Daten mit bidirektionaler Synchronisierung erweitern möchten, um mobile und andere Anwendungen in Heroku zu aktivieren, und Sie möchten, dass die Daten auch in Salesforce repliziert werden. Erforderlich Asynchron Ja Ja Nein Mit Pro-Code-Tools Ja Ja, über Shield Connect OAuth
OmniStudio-Integrationsverfahren Wenn Sie Daten aus Drittanbieterquellen ohne Benutzerinteraktion importieren und umwandeln müssen. Erforderlich Beides Ja Ja Ja Deklarative Unterstützung Nein Ja Anmeldeinformationen mit Namen
Salesforce Connect / Externe Objekte Wenn Daten auf der Salesforce-Benutzeroberfläche angezeigt werden sollen, die Daten jedoch in einem externen System gespeichert werden sollen, das Standardprotokolle wie Odata oder GraphQL verwenden kann. Erforderlich Sync Ja Ja Ja Mit Pro-Code-Tools Nein N/A Mehrere
\* Testen und Bereitstellen bezieht sich auf die Möglichkeit, in einer niedrigeren Umgebung zu erstellen und über die [Metadaten-API](https://developer.salesforce.com/docs/metadata-coverage/), Pakete oder Änderungssets in der Produktion bereitzustellen. ### Anwendungsfall: Eingehende Integration mit Low-Code-Tools > Ein Kontakt wird im ERP-System der Organisation aktualisiert. Diese Kontaktinformationen müssen in Salesforce aktualisiert werden. **Heroku Connect** Heroku Connect wird in der Regel verwendet, um eine Heroku Postgres-Datenbank und Salesforce synchron zu halten. Sofern das ERP-System Heroku Postgres nicht als Transaktionsspeicher verwendet, ist dieser Anwendungsfall nicht möglich. Wenn Heroku Postgres verwendet wird, können in den Postgres-Tabellen vorgenommene Änderungen mit Objekten in Salesforce mit Heroku Connect synchronisiert werden. **OmniStudio-Integrationsverfahren** Nachdem das ERP-System den Kontaktdatensatz aktualisiert hat, kann über die von Data Mapper generierte REST-API ein OmniStudio-Integrationsverfahren mit einer Aktion zum Laden von Datenzuordnungen und einer Antwortaktion aufgerufen werden. Zunächst sendet eine Aktion vom Typ "Datenzuordnung laden" eine JSON- oder XML-Nutzlast, die zum Aktualisieren und Einfügen der Kontaktdatensätze anhand eines Felds vom Typ "Externe ID" oder über einen [Aktualisieren und Einfügen](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio) verwendet wird. Wenn eine einfache Antwort in JSON alles ist, was erwartet wird, kann eine Antwortaktion alle relevanten Informationen aus den vorherigen Aktionen zurücksenden, um auf Erfolg oder Fehler hinzuweisen. Wenn das ERP-System eine bestimmte Antwort erwartet, kann eine Datenzuordnungstransformations- oder -extraktionsaktion verwendet werden, um eine JSON- oder XML-Antwort mit zusätzlichen Funktionen zu generieren, die deklarativ Daten enthalten, die durch die Kontaktdatensatzaktualisierung in Auslösern generiert wurden. Die Hauptherausforderung bei diesem Szenario ist die Gleichzeitigkeit: Mehrere Aufrufe zur gleichzeitigen Aktualisierung desselben Kontaktdatensatzes führen zu Problemen, da die API direkt in Salesforce vorhanden ist. **Salesforce Connect / Externe Objekte** Salesforce Connect und externe Objekte werden für diesen Anwendungsfall nicht empfohlen, da das Szenario speziell die Datenreplikation in Salesforce erfordert. Wenn Sie über eine bereits vorhandene Salesforce Connect-Integration verfügen, die für das ERP entwickelt wurde, können Sie den OData 4.0-Konnektor so konfigurieren, dass die Datenerfassung externer Änderungen unterstützt wird, sofern das ERP die Datenerfassung von Änderungen unterstützen kann. Außerdem müssen Sie in Salesforce konfigurieren, dass der Änderungs-Stream über die ERP-API über die Pub/Sub-API abonniert wird. ### Hybridtools für eingehende Integrationen in Salesforce
Anleitung Lizenzierung Zeitpunkt Volumen und Skalierung Lieferung & Wartung Datenschutz und Sicherheit
Wann zu verwenden Zusätzliche Lizenz Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen) Unterstützung für mehrere Objekte LDV/Bulk Testen und Bereitstellen** Debugging Integriertes Fehlerverarbeitungs-/Wiederholungsverhalten Kann mit im Leerlauf verschlüsselten Daten verwendet werden Authentifizierungsprotokoll
Plattformereignisse Wenn Sie eine benutzerdefinierte, strukturierte Nutzlast für Änderungen nahezu in Echtzeit in Salesforce oder einem externen System benötigen. Nicht erforderlich* Asynchron Ja Nein Ja Mit Pro-Code-Tools Ja Ja OAuth
Salesforce Connect / Externe Objekte (mit benutzerdefinierten Apex Adaptern) Wenn Daten auf der Salesforce-Benutzeroberfläche angezeigt werden sollen, die Daten jedoch in einem externen System gespeichert werden sollen, das keine Odata 2.0/4.0-Protokolle verwenden kann. Erforderlich Beides Ja Ja Ja Mit Pro-Code-Tools Nein N/A Mehrere
Daten 360 Wenn Sie harmonisierte Daten aus verschiedenen Quellen in einem Datenspeicher wünschen oder Ihre Daten aus anderen Salesforce-Organisationen oder anderen externen Systemen replizieren möchten. Data 360 unterstützt auch die Virtualisierung für einige Plattformen. Erforderlich Beides Ja Ja Ja Nein Ja Ja Mehrere
\* [Add-On](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) für Anwendungsfälle mit hohem Volumen erforderlich. \*\* Testen und Bereitstellen bezieht sich auf die Möglichkeit, in einer niedrigeren Umgebung zu erstellen und über die [Metadaten-API](https://developer.salesforce.com/docs/metadata-coverage/), Pakete oder Änderungssets in der Produktion bereitzustellen. ### Anwendungsfall: Eingehende Integration mit Hybridtools > Ein Kontakt wird im ERP-System der Organisation aktualisiert. Diese Kontaktinformationen müssen in Salesforce aktualisiert werden. **Plattformereignisse** Benutzerdefinierter Code in einem externen System veröffentlicht ein Plattformereignis, wenn der Kontaktdatensatz im ERP-System aktualisiert wird. Ein Auslöser, Prozess oder Flow in Salesforce kann das Plattformereignis abonnieren und das entsprechende(n) Salesforce-Objekt(e) aktualisieren, wenn ein Ereignis verarbeitet wird. Das Plattformereignis kann einfach als Signal fungieren, dass eine Änderung im ERP-System des Kunden stattgefunden hat, ohne Daten zu enthalten, oder es kann die tatsächlichen Daten enthalten, die zum Aktualisieren des Salesforce-Objekts erforderlich sind. **Salesforce Connect / Externe Objekte (mit benutzerdefinierten Apex Adaptern)** Diese Lösung ist in einem Anwendungsfall, der einen Datenabgleich erfordert, nicht anwendbar. Diese Lösung ist anwendbar, wenn Benutzer in Salesforce Informationen aus einem externen System anzeigen müssen, die in Salesforce nicht repliziert werden dürfen oder können, und das externe System keine Standardprotokolle wie Odata oder GraphQL unterstützt. Siehe [Anwendungsfall: Ausgehende Integration mit Hybridtools](#anwendungsfall-ausgehende-integration-mit-hybridtools) für einen Beispielanwendungsfall für einen benutzerdefinierten Apex-Adapter. **Data 360** Wenn ein Kontakt in externen Systemen wie ERP aktualisiert wird, können die Kontaktaktualisierungen mit Data 360 synchronisiert werden, entweder mithilfe von vorkonfigurierten Konnektoren oder mithilfe von APIs und Pro-Code-Tools wie MuleSoft. Kontakt kann auch in Data 360 mit dem Zero-Copy-Mechanismus referenziert werden (auf einigen Plattformen verfügbar). Sobald Daten in Data 360 verfügbar sind, können verschiedene vorkonfigurierte Integrationsmechanismen zum Synchronisieren der Daten mit anderen Salesforce-Organisationen verwendet werden. Auf Daten kann mit Data Cloud One per Verweis zugegriffen werden. Daten können auch mithilfe von Aktivierungen und anderen APIs mit vorkonfigurierten Konnektoren oder mit Pro-Code-Tools wie der MuleSoft Anypoint Platform repliziert werden. ### Pro-Code-Tools für eingehende Integrationen in Salesforce
Anleitung Lizenzierung Zeitpunkt Volumen und Skalierung Lieferung & Wartung Datenschutz und Sicherheit
Wann zu verwenden Zusätzliche Lizenz Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen) Unterstützung für mehrere Objekte LDV/Bulk Testen und Bereitstellen**** Debugging Integriertes Fehlerverarbeitungs-/Wiederholungsverhalten Kann mit im Leerlauf verschlüsselten Daten verwendet werden Authentifizierungsprotokoll
Benutzerdefinierte Apex REST & SOAP Web Services Wenn Sie mehr Funktionen benötigen, als von den nativen API-Endpunkten bereitgestellt werden, beispielsweise die objektübergreifende Verarbeitung oder andere komplexe Logik. Nicht erforderlich Beides Ja Ja Ja Mit Pro-Code-Tools Nein Ja*** Mehrere
MuleSoft Anypoint Wenn Sie eine einzelne einheitliche Lösung auf Unternehmensebene zum Erstellen, Orchestrieren und Verwalten Ihrer Integrationen benötigen, wenn Sie eine veraltete Punkt-zu-Punkt-Architektur ersetzen müssen oder wenn Sie API-Verwaltungsunterstützung benötigen. Erforderlich Beides Ja Ja Ja Mit Pro-Code-Tools Nein Ja*** Mehrere
Native Salesforce-APIs Wenn Sie mehr Kontrolle benötigen oder über eine Pro-Code-Fertigkeit verfügen, um Integrationen über die REST-API, die SOAP-API, die Bulk-API oder GraphQL-APIs oder gRPC zu erstellen. Nicht erforderlich* Beides Ja***** Ja Ja Mit Pro-Code-Tools Ja** Ja*** Mehrere
\* Es gelten [API-Anforderungsobergrenzen und -zuteilungen](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm). \*\* Bulk-APIs weisen Aspekte des Wiederholungsverhaltens auf und eine Reihe von APIs bieten _Rollback-_Schutz über die Einstellung allOrNone (siehe beispielsweise [allOrNone-Parameter in](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm) Composite- und Inkassoanforderungen). \*\*\* Durch das Aktivieren der Shield Platform Encryption werden bestimmte Verhaltensweisen geändert, weitere Details finden Sie unter [Allgemeine Shield Platform Encryption Überlegungen](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5). \*\*\*\*Testen und Bereitstellen bezieht sich auf die Möglichkeit, in einer niedrigeren Umgebung zu erstellen und über die [Metadaten-API](https://developer.salesforce.com/docs/metadata-coverage/), Pakete oder Änderungssets in der Produktion bereitzustellen. \*\*\*\*\*\*Zusammengesetzte APIs unterstützen mehrere Objekte. ### Anwendungsfall: Eingehende Integration mit Pro-Code-Tools > Ein Kontakt wird im ERP-System der Organisation aktualisiert. Diese Kontaktinformationen müssen in Salesforce aktualisiert werden. **Benutzerdefinierte Apex REST- und SOAP-Webservices** Sie können einen Webservice mithilfe von Apex-Code erstellen, der CRUD-Vorgänge (create, read, update, delete) für das Kontaktobjekt ausführen könnte. Dieser Service wird über SOAP oder REST vom externen System (dem ERP) aufgerufen. **MuleSoft Anypoint** Der Zweck von MuleSoft Anypoint besteht darin, die API-Verwaltung auf Unternehmensebene bereitzustellen. MuleSoft Anypoint bietet eine [große Reihe vorgefertigter Konnektoren](https://www.mulesoft.com/platform/cloud-connectors), die Sie in viele ERP-Systeme integrieren können, darunter SAP, Oracle EBS, Oracle ERP und NetSuite. Sie können einen Flow erstellen, um Ereignisse in diesen ERP-Systemen zu überwachen (in diesem Fall, wenn ein neuer Kontakt erstellt wird). Wenn der Flow gestartet wird, verwendet er den Salesforce-Konnektor, um einen neuen Kontaktdatensatz zu erstellen (oder einen zu aktualisieren, wenn der Kontakt bereits vorhanden ist). Darüber hinaus ist es möglich, den Kontakt in andere Systeme zu integrieren, wenn die Abgleichstransaktion die Synchronisierung des Kontakts in andere Systeme beinhaltet. Bei Bedarf können Sie die Zuordnungs- und Transformationssprache (DataWeave) verwenden, um komplexe Logik und Berechnungen als Informationsflüsse über mehrere verschiedene Systeme hinweg auszuführen. Die Authentifizierung für diese Systeme kann über viele verschiedene Authentifizierungsmechanismen wie die Basisauthentifizierung und OAuth erfolgen. Es gelten keine Einschränkungen hinsichtlich des Transaktionsvolumens, solange der Flow für seine Spitzenauslastung (gemessen in vCores) richtig dimensioniert wurde. **Native Salesforce-APIs** Wenn (oder unmittelbar nach) Abschluss der Aktualisierungstransaktion im ERP-System ein Vorgang zum Aktualisieren und Einfügen des Kontaktobjekts über die SOAP-API oder ein [PATCH](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) mit der REST-API für Contact sObjects in der Salesforce-Organisation ausgeführt wird. ## Integrationen von Salesforce in Salesforce Das Salesforce-zu-Salesforce-Produkt hat sein Lebensende erreicht. Salesforce to Salesforce hat es Partnern, die zusammenarbeiten, erleichtert, an gemeinsame Kunden zu verkaufen und sie zu unterstützen. Salesforce wird jedoch in mehr Innovationen bei anderen Tools investieren. Für die Freigabe von Daten zwischen Salesforce-Organisationen werden künftig die folgenden Ansätze empfohlen. ### Tools für die organisationsübergreifende Datenintegration
Anleitung Kosten Zeitpunkt Volumen und Skalierung Lieferung & Wartung Datenschutz und Sicherheit Zu implementierende Tools
Anwendungszeitpunkt Zusätzliche Lizenz Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen) Unterstützung von mehreren Objekten LDV/Masse Testen und Bereitstellen* Debugging Eingebautes Fehlerverarbeitungs-/Wiederholungsverhalten Kann mit im Leerlauf verschlüsselten Daten verwendet werden Authentifizierungsprotokoll Niedriger Code → Pro Code
Heroku Connect Wenn Sie Ihre Daten mit bidirektionaler Synchronisierung über Salesforce-Organisationen hinweg erweitern und auch den Zugriff auf die Daten über mobile und andere Anwendungen aktivieren möchten, die auf Heroku ausgeführt werden Erforderlich Asynchron Ja Ja Nein Mit Pro-Code-Tools Ja Ja, über Shield Connect OAuth Low Code (Niedriger Code)
MuleSoft Anypoint Wenn Sie eine einzelne einheitliche Lösung für Unternehmen zum Erstellen, Orchestrieren und Verwalten Ihrer Integrationen benötigen, wenn Sie eine veraltete Punkt-zu-Punkt-Architektur ersetzen müssen oder wenn Sie API-Verwaltungsunterstützung benötigen Erforderlich Beides Ja Ja Ja Mit Pro-Code-Tools Nein Ja** Mehrere Pro-Code
Native Salesforce-APIs Wenn Salesforce oder Heroku Connect keine Option sind oder Sie eine komplexere Verarbeitung benötigen Nicht erforderlich Beides Nein Ja Ja Mit Pro-Code-Tools Nein Ja** Mehrere Pro-Code
Datenerfassung ändern Wenn Sie in Salesforce vorgenommene Änderungen auf Datensatzebene in einem externen System veröffentlichen müssen und keine benutzerdefinierte Nutzlast benötigen. Erforderlich Asynchron Nein Nein Ja Mit Pro-Code-Tools Ja Ja OAuth
Salesforce Connect mit organisationsübergreifendem Adapter Wenn Benutzer in einer Organisation Datensätze in einer anderen Organisation ohne Datenreplikation anzeigen oder bearbeiten sollen Erforderlich Asynchron Ja Ja Ja Mit Pro-Code-Tools N/A N/A Mehrere Low Code (Niedriger Code)
Daten 360 Wenn Sie möchten, dass Benutzer in einer Organisation Datensätze in einer anderen Organisation mit in Data 360 abgeglichenen Daten anzeigen oder bearbeiten können. Erforderlich Beides Ja Ja Ja Mit Pro-Code-Tools Ja Ja Mehrere Hybrid
\* Testen und Bereitstellen bezieht sich auf die Möglichkeit, in einer niedrigeren Umgebung zu erstellen und über die [Metadaten-API](https://developer.salesforce.com/docs/metadata-coverage/), Pakete oder Änderungssets in der Produktion bereitzustellen \*\* Durch das Aktivieren der Shield Platform Encryption werden bestimmte Verhaltensweisen geändert, weitere Details finden Sie unter [Allgemeine Shield Platform Encryption Überlegungen](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5). _Plattformereignisse sind nicht optimal für die Integration von Daten aus einer Salesforce-Organisation in eine andere, da sie nicht zwischen Organisationen für dasselbe Ereignis "zuhören" können. Benutzerdefiniertes Apex ist auch kein empfohlener Ansatz für diese Art der Integration._ ### Anwendungsfall: Verbinden mehrerer Salesforce-Organisationen > Ein großes Unternehmen ist über mehrere Geschäftseinheiten hinweg tätig. Jede BU verfügt über eine eigene Salesforce-Organisation. Ein einzelner Kunde bearbeitet mehrere Geschäftseinheiten des Unternehmens und verfügt somit über Account- und Opportunity-Daten in mehreren Organisationen. Das Unternehmen muss auf eine aggregierte Ansicht aller Account- und Opportunity-Daten über alle BUs in einer einzigen Organisation zugreifen. _Hinweis: Alle nachstehenden Lösungen sind auf die geringste Menge an Datenreplikationen ausgelegt, entsprechend [Takeaway #1](#takeaways)._ Mit vorkonfigurierten Salesforce-Konnektoren können **Data 360-**Account- und Opportunity-Daten aus verschiedenen Salesforce-Organisationen in Data 360 aufgenommen werden. Sie können auch aggregiert und harmonisiert werden (falls erforderlich). Sobald Daten in Data 360 aggregiert wurden, kann in anderen Salesforce-Organisationen mit Data Cloud One ohne Datenreplikation darauf zugegriffen werden. **Heroku Connect** Sie können Heroku Connect für die einzelne Organisation der einzelnen Kundendienstmitarbeiter verwenden, um Änderungen aus Salesforce in einer einzelnen Heroku Postgres-Datenbank zu synchronisieren. In diesem Szenario ist die bidirektionale Synchronisierung nicht aktiviert, sondern nur die Synchronisierung von Salesforce mit Postgres. Anschließend können Sie in Heroku Connect den Odata Anbieter aktivieren und die Tabellen auswählen, die in der Salesforce-Organisation, in der Sie eine aggregierte Ansicht anzeigen möchten, als externe Objekte angezeigt werden sollen. In Salesforce definieren Sie eine externe Datenquelle, die auf den Odata Anbieter in Heroku verweist. **MuleSoft Anypoint** MuleSoft Anypoint bietet API-Verwaltung auf Unternehmensebene. Eine MuleSoft Anypoint-API kann so konfiguriert werden, dass sie Informationen aus mehreren zugehörigen Salesforce-Organisationen mit dem Salesforce-Konnektor mit mehreren Verbindungen zu den Organisationen liest. Der MuleSoft-Flow kann die verschiedenen Salesforce-Organisationen abfragen und eine bestimmte Struktur zurückgeben, die bei Bedarf erweitert oder mit anderen Drittanbieterinformationen angereichert wird. Wenn die API aufgerufen wird, nimmt sie alle entsprechenden Salesforce-Organisations-Callouts vor (in diesem Beispiel werden Account- und Opportunity-Informationen abgefragt), damit die Daten vom Verbraucher verarbeitet werden können (wahrscheinlich eine Benutzeroberfläche). Die Authentifizierung für diese Systeme kann über eine Vielzahl von Authentifizierungsmechanismen erfolgen, einschließlich der Basisauthentifizierung und OAuth. Es gelten keine Einschränkungen hinsichtlich des Transaktionsvolumens, solange der Flow für seine Spitzenauslastung (gemessen in vCores oder Cores) richtig dimensioniert wurde. **Native Salesforce-APIs**-Abfragevorgänge können für jede der relevanten Organisationen ausgestellt werden, insbesondere über die Salesforce Bulk API 2.0, die sich gut zum effizienten Extrahieren von Tausenden von Datensätzen eignet. Sie können die Abfrageergebnisse aus jeder Organisation einzeln abrufen und sie mit einer benutzerdefinierten Anwendung oder Middleware entsprechend den Kundenanforderungen aggregieren. **Salesforce Connect mit organisationsübergreifendem Adapter** Der organisationsübergreifende Salesforce Connect-Adapter ist in diesem Szenario nicht besonders geeignet, da Accounts oder Opportunities aus Remote-Organisationen alle in der zentralen Organisation als _unterschiedliche_ Objekte angezeigt werden. Beispielsweise gibt es keine Möglichkeit, eine Gesamtsumme für die Beträge aller Opportunities in allen Organisationen zu addieren. **Selective Updates Cross-Org Scenario (Selektives Aktualisieren organisationsübergreifendes Szenario):** Ein Vertriebsmitarbeiter, der Salesforce-Organisation A verwendet, muss Kundenvorgangsdaten aus Salesforce-Organisation B anzeigen und aktualisieren und Kundenvorgangskommentare zum übergeordneten Kundenvorgang in Salesforce-Organisation B hinzufügen, während er in Organisation A arbeitet. Daten dürfen nicht in Organisation A repliziert werden. **Heroku Connect** Sie können denselben Ansatz verwenden, der im obigen _Szenario für die Datenaggregation_ beschrieben ist. Sie müssen jedoch CRUD für das externe Objekt über den Odata Konnektor aktivieren und die Änderungen in Heroku Postgres zurückschreiben. **MuleSoft Anypoint** MuleSoft Anypoint bietet API-Verwaltung auf Unternehmensebene. Sie können denselben Ansatz verwenden, der im obigen _Szenario der Datenaggregation_ beschrieben ist. **Native Salesforce-APIs** verwenden Anmeldeinformationen mit Namen und rufen die nativen Salesforce-APIs auf, um Daten in der zugehörigen Salesforce-Organisation zu lesen und zu aktualisieren. Eine Komponente muss so konzipiert sein, dass die Daten angezeigt werden. **Salesforce Connect mit organisationsübergreifendem Adapter** Die Möglichkeit, Daten in einem externen Objekt anzuzeigen (und die Daten zu bearbeiten, wenn Sie CRUD für das externe Objekt aktiviert haben), wird über den organisationsübergreifenden [Salesforce-Adapter](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5) unterstützt. Beziehungen werden auch zwischen externen Objekten unterstützt, sodass Sie eine Verknüpfung mit dem übergeordneten Kundenvorgang im externen Objekt herstellen können. Das Erstellen von Beziehungen ist jedoch heute ein manueller Prozess, bei dem Sie einen vorhandenen Datentyp in einen Beziehungsdatentyp konvertieren. Darüber hinaus werden Optimierungen, die in Service Cloud vorgenommen wurden, um Kundenvorgänge effektiver zu bearbeiten, nicht in die Remote-Organisation übertragen. Salesforce empfiehlt dringend, den organisationsübergreifenden Adapter zu testen und die Kompromisse bei der Arbeit mit externen Objekten im Vergleich zu Standardobjekten für Ihren Anwendungsfall auszuwerten. **Organisationsübergreifende Datensynchronisierung**: Wenn ein Account für einen Kunden in einer der Salesforce-Unternehmenseinheiten der Organisation aktualisiert wird, müssen die Accountobjekte der anderen Salesforce-Organisation aktualisiert werden, um konsistente Accountinformationen zu erhalten. **Data 360** Data 360 kann zum Abgleichen von Daten von einer Organisation in eine andere Salesforce-Organisation verwendet werden. Accountdaten aus einer Salesforce-Organisation können mit vorkonfigurierten Salesforce-Konnektoren in Data 360 aufgenommen werden. Es können auch Datenaktivierungsmechanismen wie Batch-Aktivierung, Datenaktionen nahezu in Echtzeit oder API-basierte Aktivierungen verwendet werden, um die Daten aus Data 360 in die Salesforce-Organisation zu verschieben. **Heroku Connect** Sie können denselben Ansatz verwenden, der im obigen _Szenario für die Datenaggregation_ beschrieben ist. Sie müssen jedoch die bidirektionale Synchronisierung aktivieren und Sie müssen Salesforce Connect nicht mehr aktivieren, da durch die bidirektionale Synchronisierung alle Organisationen auf dem neuesten Stand bleiben, wenn Änderungen an der Postgres-Tabelle vorgenommen werden. **MuleSoft Anypoint** MuleSoft Anypoint bietet API-Verwaltung auf Unternehmensebene. Sie können mit Flow Designer in MuleSoft Anypoint [eine Mule-Anwendung konfigurieren](https://docs.mulesoft.com/design-center/about-designing-a-mule-application), um auf standardmäßige und benutzerdefinierte Objektereignisse zu achten und einen automatisch gestarteten Flow in Salesforce zu starten. Wenn die Mule-Anwendung ausgelöst wird, kann sie den Anypoint-Konnektor für Salesforce aufrufen, um mit einer beliebigen Anzahl von Salesforce-Organisationen zu kommunizieren. Wenn in diesem Anwendungsfall ein Accountdatensatz in einer Salesforce-Organisation aktualisiert wird, kann die Mule-Anwendung Accountdatensätze in den zugehörigen Salesforce-Organisationen aktualisieren. Jede zugehörige Salesforce-Organisation verfügt über einen eindeutigen Aktualisierungsschritt, der in den gesamten Anwendungs-Flow in MuleSoft integriert ist. Die Authentifizierung für diese Systeme kann über verschiedene Authentifizierungsmechanismen erfolgen, einschließlich der Basisauthentifizierung und OAuth. Es gelten keine Einschränkungen für das Transaktionsvolumen, solange der Flow für seine Spitzenauslastung (gemessen in vCores oder Cores) richtig dimensioniert wurde. **Native Salesforce-APIs** Die [Replikations-API](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (getUpdated, getDeleted operations) kann zum Synchronisieren von Daten zwischen Organisationen verwendet werden. Dieser Ansatz wird jedoch nicht empfohlen. **Salesforce Connect mit organisationsübergreifendem Adapter** Sie können durch Datensätze ausgelöste Flows und externe Objekte verwenden, um einige Daten zwischen Salesforce-Organisationen synchron zu halten. Wenn Sie beispielsweise einen Accountdatensatz in Organisation A aktualisieren, wird ein Flow ausgelöst, der dann den übereinstimmenden Datensatz im externen Objekt "Account" aktualisiert, wodurch diese Aktualisierungen in den Accountdatensatz in Organisation B geschrieben werden. Dies erfordert die ordnungsgemäße Verwendung der Flow-Semantik, um [gemischte DML-Transaktionen](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1) zu vermeiden. Beachten Sie außerdem, dass Validierungsregeln und Flows in Organisation B auf die gleiche Weise ausgelöst werden, wie wenn Änderungen durch unsere REST/SOAP-APIs vorgenommen werden. ## Schlussbemerkungen Beachten Sie diese Anleitung und beziehen Sie sich darauf, wenn Sie eine neue Datenintegration mit Salesforce planen. Es empfiehlt sich immer, den vollständigen Umfang der für Sie verfügbaren Optionen zu verstehen und zu erfahren, wie sie zu Ihrem speziellen Anwendungsfall passen. ### Teilen Sie uns Ihre Meinung mit Helfen Sie uns sicherzustellen, dass wir die für Sie relevantesten Elemente veröffentlichen. [Nehmen Sie an unserer Umfrage](https://sfdc.co/J0cWb) teil, um Feedback zu diesem Inhalt zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten. # Durch Datensätze ausgelöste Automatisierung Die Salesforce Platform hat ihre Automatisierungsarchitektur kontinuierlich weiterentwickelt, um die Anforderungen komplexer Geschäftsprozesse zu erfüllen. Frühere Generationen – Workflow-Regeln und Prozessgenerator – boten die ersten Schritte in der ereignisgesteuerten Logik, erweiterten die Automatisierungsfunktionen für ereignisgesteuerte Logik und erweiterten die Reichweite auf eine breitere Palette von Generatoren. Diese Entwicklung hat zu einer leistungsstarken, konsolidierten Architektur geführt, die sich auf zwei komplementäre Säulen konzentriert: Durch Datensätze ausgelöster Flow und Apex-Auslöser. ## Leitfadenübersicht In diesem Dokument finden Sie den Rahmen und die Richtlinien, um fundierte Entscheidungen beim Entwerfen von Auslöserautomatisierungen zu treffen. Sie gleicht Anwendungsfallanforderungen mit drei wichtigen Entscheidungspunkten ab, die Sie bei der Auswahl des richtigen Ansatzes für die Automatisierung unterstützen, die durch Änderungen an Salesforce-Datensätzen ausgelöst wird. ## Produkte im Umfang
Flow Salesforce Flow ist ein leistungsstarkes Zeigen-und-Klicken-Automatisierungstool, mit dem Benutzer komplexe Geschäftsprozesse, Bildschirme und Logik visuell mit Flow Builder erstellen können, ohne Code schreiben zu müssen. Sie automatisiert Aufgaben wie Datenaktualisierungen, das Senden von E-Mails und das Führen von Benutzern und bietet Flexibilität durch Typen wie Bildschirm-Flows (Benutzerinteraktion) und Ausgelöste Flows (Datensatz-/geplante Ereignisse).
Apex Salesforce Apex ist eine proprietäre, objektorientierte Programmiersprache für die Salesforce Platform, die ähnlich wie Java zum Erstellen von benutzerdefinierter Geschäftslogik, Automatisieren von Prozessen und Erweitern der zentralen CRM-Funktionen über deklarative Tools hinaus verwendet wird.
## Takeaways Die Erstellung einer durch Datensätze ausgelösten skalierbaren, wartungsfreundlichen und leistungsfähigen Automatisierung auf der Salesforce Platform erfordert einen disziplinierten, von der Architektur geführten Ansatz. Die Auswahl zwischen Flow und Apex und die Implementierung der einzelnen Elemente richten sich nach einem klaren Satz von Prinzipien. Diese Punkte fassen diese Prinzipien zusammen und dienen als grundlegende Regeln für das moderne Automatisierungsdesign. - **Wählen Sie basierend auf der Salesforce-Objektautomatisierungsdichte das richtige Tool für den Auftrag aus.** - Verwenden Sie "Durch Datensätze ausgelöster Flow" für Salesforce-Objekte für Automatisierungen mit **niedriger Dichte**. - Erweitern Sie die Logik des durch einen Datensatz ausgelösten Flows um Invocable Apex für Automatisierungen **mittlerer Dichte**. - Verwenden Sie Apex-Auslöser für Salesforce-Objekte für Automatisierungen mit **hoher Dichte**. - **Gehen Sie beim Auslösen asynchroner Prozesse mit Bedacht vor.** Diese Regel gilt unabhängig davon, ob Sie asynchrone Prozesse in einem durch einen Datensatz ausgelösten Flow aufrufen oder einen warteschlangenfähigen Auftrag aus Apex in die Warteschlange stellen. Auch wenn dieses Muster für das Abladen von Arbeit verlockend sein kann, kann es komplexe Fehlerbehandlungsszenarien einführen und das Risiko erhöhen, die Obergrenzen zu erreichen. - **Verwenden Sie einen Einstiegspunkt pro Salesforce-Objekt.** Verwenden Sie für ein bestimmtes Salesforce-Objekt einen Mechanismus als Einstieg in die Automatisierung. Versuchen Sie, zu vermeiden, dass Flow- und Apex-Auslöser als Einstiegspunkte für dasselbe Objekt miteinander kombiniert werden. ## Entscheidungspunkte Es gibt drei Hauptentscheidungspunkte, die berücksichtigt werden sollten: - Deklarative und programmgesteuerte Implementierung - Automatisierungsdichte - Die Dichteauswahlmatrix ### Deklarative und programmgesteuerte Implementierung Flow und Apex verwenden gemeinsame grundlegende Funktionen. Jedes Tool kann Datensätze abfragen, bedingte Logik ausführen, Variablen zuweisen und DML-Vorgänge wie das Erstellen, Aktualisieren und Löschen von Datensätzen ausführen, die in einer angegebenen Reihenfolge ausgeführt werden. Diese funktionale Überschneidung bedeutet jedoch nicht, dass die Werkzeuge austauschbar sind. Bei der architektonischen Entscheidung geht es nicht darum, _ob_ eine Aufgabe gelöst werden kann, sondern _wie_ sie durchgeführt wird und welche langfristigen Auswirkungen sie auf die Leistung, Skalierbarkeit und Wartungsfähigkeit hat. Flows zeichnen sich durch klare und schnelle Implementierung für einfache Prozesse aus, während Apex die für komplexe Lösungen erforderliche granulare Kontrolle und Rohleistung bietet. ### Automatisierungsdichte Bei der **Automatisierungsdichte** handelt es sich um die Belastung eines bestimmten Salesforce-Objekts. Sie dient als Heuristik, um die optimale Implementierung des Objekts zu bestimmen. Mit zunehmender Automatisierungsdichte steigt die Wahrscheinlichkeit, dass Transaktionsobergrenzen überschritten werden. Berechnen Sie die Automatisierungsdichte, indem Sie drei spezifische Dimensionen von Volumen und Komplexität untersuchen: - **Automatisierungsmenge:** Die Rohanzahl eindeutiger Metadateneinträge für die Automatisierung (Flows, Auslöseraktionen usw.), die während eines einzelnen DML-Ereignisses (Data Manipulation Language) ausgeführt werden. - **Datensatzvolumen:** Die Datensätze pro Transaktion, die über API-Ladungen oder die Verarbeitung schwerer Batches verarbeitet werden, wobei die Leistung entscheidend wird. - **Abhängigkeitsverbreitung:** Eine Maßeinheit für die durch den anfänglichen CRUD-Vorgang ausgelösten nachgelagerten DML-Vorgänge. Sie quantifiziert die Tiefe des Diagramms, in dem eine Aktualisierung zu Aktualisierungen an verwandten Objekten führt (z. B. Kundenvorgang → Account → Kontakt → benutzerdefiniertes Rollup). Dimensionen der Automatisierungsdichte Wenn der Umfang und die Komplexität Ihrer Salesforce-Anwendung zunehmen, können Sie sich für einen einzigen primären Einstiegspunkt entscheiden – entweder durch Datensätze ausgelöster Flow oder Apex Triggers. Vermeiden Sie die Partitionierung von Automatisierungen über mehrere Mechanismen in einem einzelnen Salesforce-Objekt, da dies zu einer schlechten Wartungsfähigkeit und einer fragmentierten Verwaltung führt. ### Die Dichteauswahlmatrix Verwenden Sie diese Matrix, um den erforderlichen Architekturstandard für Ihr Salesforce-Objekt zu bestimmen. - **Durch Datensätze ausgelöster Flow** ist die bevorzugte Lösung für eine niedrige Automatisierungsdichte. Sie bietet ein ausgewogenes Verhältnis zwischen Leistung und Zugänglichkeit, das sich ideal für einfache und voneinander unabhängige Automatisierungen eignet. - **Das Hybridmuster (Record-Triggered Flow with Invocable Apex)** ist eine leistungsstarke und wartbare Wahl für Automatisierungen mittlerer Dichte mit steigender Komplexität. Durch dieses Muster können Teams die geordnete Choreografie im deklarativen Flow beibehalten und gleichzeitig rechenintensive Vorgänge an Apex delegieren, um den barrierefreien Zugriff mit der Leistung abzugleichen. - **Apex Auslöser** bieten die notwendigen Bausteine für eine solide architektonische Grundlage, um Automatisierungen mit hoher Dichte zu unterstützen. Die Leistung, die granulare Steuerung sowie die objektorientierte Abstraktion und Polymorphie von Apex eignen sich besser, um die Komplexität und den Umfang dieser Szenarien zu bewältigen.
Dichtestufe Automatisierungsmenge Datenvolumen (Batchgröße) Abhängigkeitszersiedelung Architektonischer Standard
Niedrig < 15
Automatisierungen
Standard
Benutzergesteuerte Benutzeroberflächeninteraktionen oder kleine API-Lastungen (1–200 Datensätze)
Diskret
In sich geschlossene Logik. 0–1 nachgelagerte DML-Vorgänge für dasselbe Objekt oder ein verwandtes Objekt.
Durch einen Datensatz ausgelöster Flow
Mittel 15–30
Automatisierungen
Mittel
Standardmäßige Batchverarbeitung (mit Logik, die eine sorgfältige Massenverarbeitung erfordert)
Gekoppelt
"Übergeordnet/Untergeordnet" aktualisiert 2–4 nachgelagerte DML-Vorgänge. Rekursionsrisiko
Hybridmuster
Flow + aufrufbares Apex
Hoch > 30
Automatisierungen
Hoch
Große Datenvolumen mit Massen-API-Last (2.000 – 10.000+ Datensätze)
Komplex und rekursiv
Diagramm mit tiefer Abhängigkeit (5+ nachgelagerte DML-Vorgänge). Risiko von Dreiecksrekursionsschleifen
Apex-Auslöser-Metadaten-Framework
Bei Architekturentscheidungen in der Praxis müssen Sie alle Dimensionen der Automatisierungsdichte zusammen abwägen. Berücksichtigen Sie den potenziellen künftigen Umfang bei der Auswahl eines Automatisierungsmechanismus für ein bestimmtes Salesforce-Objekt. Beachten Sie auch die tägliche Gesamtanzahl der DML-Vorgänge, da Salesforce die Verwaltung gemeinsamer Ressourcen in einer Umgebung mit mehreren Mandanten und [Obergrenzen](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm) erzwingt, um zu verhindern, dass Automatisierungen gemeinsam genutzte Ressourcen monopolisieren. Salesforce-Objekte mit einem hohen täglichen DML-Volumen erfordern eine sorgfältige Automatisierungsauswahl. Beispielsweise sind die asynchronen Obergrenzen für die CPU-Zeit (60.000 ms) und die Heap-Größe (12 MB) höher als die synchronen Obergrenzen. Darüber hinaus muss die organisationsweite 24-Stunden-Obergrenze für asynchrone Ausführungen – berechnet auf das 250.000- oder 200-fache Ihrer Benutzerlizenzen – die gesamte tägliche DML in Ihren Architekturentwurf einbeziehen, um Laufzeitausnahmen zu vermeiden. ## Produktvergleich Durch Datensätze ausgelöster Flow ist das wichtigste deklarative Tool der Plattform für die durch Datensätze ausgelöste Automatisierung. Die Benutzerfreundlichkeit von Flow und die integrierten Plattformsicherungen ermöglichen es Teams, einfach skalierbare und zuverlässige Lösungen zu erstellen. Dies ist die ideale Wahl für die meisten Teams, die Lösungen auf der Salesforce Platform erstellen. Apex ist die proprietäre, stark typisierte, objektorientierte Programmiersprache der Plattform. Verwenden Sie Apex für Salesforce-Objekte mit hoher Automatisierungsdichte und für Anwendungsfälle, die eine hohe Leistung, komplexe Logik oder genaue Kontrolle über Transaktionen erfordern. Diese Matrix bietet einen direkten Vergleich von Flow und Apex zwischen wichtigen Architekturfunktionen, um die Entscheidungsfindung zu unterstützen.
Kapazität Durch einen Datensatz ausgelöster Flow Apex Trigger
Liefer- und Wartungsgeschwindigkeit Empfohlen
Über die visuelle Benutzeroberfläche von Flow Builder können Administratoren und andere deklarative Generatoren Automatisierungen schneller erstellen und ändern als Apex Code schreiben, testen und bereitstellen. Diese Oberfläche ermöglicht es einem breiteren Spektrum von Teammitgliedern, Geschäftswerte zu liefern, und reduziert die Abhängigkeit von spezialisierten Entwicklerressourcen für einfache Aufgaben.
Fachwissen erforderlich
Für die Implementierung, den Test und die Wartung des Codes benötigt Apex entsprechend qualifizierte Softwareentwickler.
Modularität Verfügbar
Durch Datensätze ausgelöste Flows sind standardmäßig modular. Statt monolithischer Logik erstellen Teams diskrete Flows für bestimmte Anforderungen und choreographieren sie zusammen mit dem Flow-Auslöser-Explorer. Diese Modularität ermöglicht eine isolierte Änderung und einfache Erweiterung, wodurch die langfristigen Betriebskosten erheblich reduziert werden.
Verfügbar
Apex ist nach Design in Funktionsmodule unterteilt. Jede Apex-Klasse soll ein einzelnes Funktionsmodul implementieren.
Sichtbarkeit und Governance Empfohlen
Der visuelle Charakter von Flow bietet eine intuitive Darstellung der Geschäftslogik. Der Flow-Auslöser-Explorer bietet eine konsolidierte Ansicht aller Flows in einem Objekt, sodass Architekten und Administratoren einfacher verstehen, steuern und Fehler beheben können, ohne Code lesen zu müssen.
Fachwissen erforderlich
Die Verwendung eines Metadaten-Frameworks zum Organisieren von Auslösern ist vorteilhaft. Apex erfordert jedoch ein diszipliniertes Entwicklungsteam, um den Code organisiert und wartbar zu halten.
Hochleistungsfähige Massendatenverarbeitung Nicht empfohlen
Bei komplexen Logiken oder großen Datenmengen besteht ein erhöhtes Risiko, dass Obergrenzen erreicht werden.
Empfohlen
Apex Code wird näher an den Kernservices der Plattform ausgeführt und bietet Entwicklern mehr Kontrolle über die Abfrageoptimierung, die Datenverarbeitung und die algorithmische Effizienz. Dies führt zu mehr Leistung und Skalierbarkeit, insbesondere in komplexen Szenarien mit großen Datenmengen.
Robuste Logik und Datenstrukturen Verfügbar
Das Element "Flowtransformation" kann bei einigen komplexen Verarbeitungsaufgaben hilfreich sein. Dem Flow fehlen jedoch native Zuordnungs- und Set-Datenstrukturen, was die komplexe Datenverarbeitung umständlich und rechenineffizient macht.
Empfohlen
Apex bietet vollständigen Zugriff auf Karten-, Satz- und Programmschleifen für hocheffiziente und sichere Datenbearbeitungen. Als Programmiersprache mit vollem Funktionsumfang bietet Apex zudem Zugriff auf komplexe logische Konstrukte, Datenstrukturen und Designmuster, mit denen komplexe Geschäftsprobleme wartungsfreundlich und effizient gelöst werden können. Apex enthält eine umfangreiche Standardbibliothek mit erweiterten Funktionen (z. B. BusinessHours, Crypto), die derzeit in deklarativen Tools nicht verfügbar sind.
Transaktionssteuerung Nicht verfügbar
Der Flow bietet keinen Zugriff auf "Database.savepoint", "Database.rollback" oder teilweise erfolgreiche DML-Vorgänge für teilweise Transaktions-Commits oder -Rollbacks.
Verfügbar
Apex bietet vollständige und detaillierte Kontrolle über die Transaktionsintegrität und komplexe Fehlerbehebungsszenarien.
E-Mail-Verteilung Empfohlen
Das Senden vorkonfigurierter E-Mail-Benachrichtigungen über einen durch einen Datensatz ausgelösten Flow ist einfach und skalierbar. Benutzerdefinierte E-Mail-Benachrichtigungen können zur Laufzeit erstellt und verteilt werden. Für benutzerdefinierte E-Mails gelten die täglichen Obergrenzen für den Versand von E-Mails.
Verfügbar
Apex kann benutzerdefinierte E-Mail-Nachrichten generieren und senden. Für alle über Apex gesendeten E-Mails gelten die täglichen Obergrenzen für den E-Mail-Versand.
Anwendung von Plattformsicherungen Empfohlen
Der Flow enthält integrierte Schutzmaßnahmen wie automatische Massenverarbeitung und automatische Wiederholungen. Diese Sicherungen erhöhen die Bewertungsgeschwindigkeit und verhindern Leistungseinbußen, die andernfalls eine komplexe manuelle Codierung erfordern.
Manuelle Implementierung erforderlich
Schutzmaßnahmen wie die Massenverarbeitung müssen explizit codiert werden (beispielsweise das Verwalten von Sammlungen und das Vermeiden von SOQL in Schleifen). Automatische Wiederholungen sind nicht nativ für Auslöser und erfordern eine komplexe benutzerdefinierte Logik.
Asynchrone Verarbeitung Verfügbar
Flow bietet einfache Mechanismen für Automatisierungen, die eine separate Transaktion in einem asynchronen Pfad erfordern. Für diese Automatisierungen gelten tägliche Obergrenzen.
Verfügbar
Apex ermöglicht die vollständige Kontrolle über die Datenerfassung ändern und warteschlangenfähige Ereignisse, die von einem entkoppelten Auslöserabonnenten verarbeitet werden.
Geplante Verarbeitung Empfohlen
Die geplanten Pfade des Flows bieten eine einzigartige und leistungsstarke Planungsfunktion (z. B. "3 Tage vor Schlusstermin auslösen"). Diese Funktion beinhaltet die automatische Stornierung und Neuplanung, wenn sich die Daten des Datensatzes ändern. Für diese Automatisierungen gelten tägliche Obergrenzen.
Nicht verfügbar
Ein Apex Auslöser kann ein zeitliches, datensatzspezifisches Ereignis mit automatischer Stornierung nicht nativ planen. Geplantes Apex ist zwar vorhanden, es handelt sich jedoch um einen grundlegend anderen Mechanismus, der zu einem bestimmten Zeitpunkt ausgeführt wird und nicht während der Verarbeitung eines einzelnen Datensatzes als Teil eines Auslösers geplant wird.
Ordnung und Choreografie Verfügbar
Mit dem Flow-Auslöser-Explorer können Administratoren eine relative Ausführungsreihenfolge für mehrere Flows desselben Objekts definieren.
Verfügbar
Ein Auslöser-Framework bietet genaue Kontrolle über die genaue Reihenfolge der Automatisierungen.
Aktualisierungen desselben Datensatzfelds Verfügbar (vor dem Speichern)
Durch einen Datensatz ausgelöster Flow ist die leistungsfähigste deklarative Option zum Aktualisieren des auslösenden Datensatzes vor dem anfänglichen DML-Commit.
Verfügbar (vor dem Speichern)
Apex bietet das leistungsstärkste Angebot mit minimalem Overhead.
Objektübergreifende CRUD Verfügbar (nach dem Speichern)
Flow eignet sich für einfache objektübergreifende DML-Vorgänge mit geringer Komplexität.
Verfügbar (nach dem Speichern)
Apex bietet eine überlegene Kontrolle über die Deduplizierung, Fehlerbehandlung und Leistung für objektübergreifende DML-Vorgänge.
Duplizierung teurer Berechnungen Verfügbar
Flow zeichnet sich durch die Beseitigung redundanter Abfragen und DML-Anweisungen durch automatische Massenverarbeitung aus. Der Status kann jedoch nicht zwischen verschiedenen Flow-Auslösern oder über mehrere Aufrufe desselben Flows innerhalb einer Transaktion zwischengespeichert oder freigegeben werden. Diese Einschränkung kann in extremen Leistungsszenarien wichtig werden.
Empfohlen
Apex bietet Mechanismen zum Deduplizieren teurer Vorgänge. Entwickler können die transaktionale Zwischenspeicherung mithilfe statischer Eigenschaften und Variablen und die Zwischenspeicherung auf Plattformebene mithilfe des Plattform-Cache nutzen, um Daten zu speichern und wiederzuverwenden. Diese Techniken sind wichtig, um den Verbrauch von Obergrenzen für Transaktionen wie SOQL-Abfragen zu reduzieren und eine hohe Leistung und Skalierbarkeit zu gewährleisten.
Benutzerdefinierte Fehlerverarbeitung Verfügbar
Das Element CustomError kann einen Speichervorgang blockieren und dem Benutzer eine Meldung anzeigen.
Empfohlen
Die Methode addError() bietet flexible Fehlermeldungen auf Feldebene und bedingte Fehlermeldungen.
## Anwendungsfälle Wenn Sie am besten betonen möchten, wie Sie die Entscheidungspunkte als Orientierung für Ihre Entscheidungen verwenden, sollten Sie die folgenden Anwendungsfälle und die zugehörigen Analysepunkte in Betracht ziehen. ### Am besten geeignete Empfehlungen Diese Tabelle enthält allgemeine Empfehlungen für allgemeine Anwendungsfälle, die auf den vorgestellten Funktionen basieren. Letztlich werden Sie zusätzliche Überlegungen berücksichtigen, um eine optimale Anpassung an Ihre speziellen Szenarien zu finden, wie sie beispielsweise im Abschnitt "_Verwandte bewährte Vorgehensweisen_" dieses Dokuments enthalten sind. Dort erfahren Sie mehr darüber, wann eine bestimmte Kombination aus Flow und Apex den besten Ansatz bietet.
Anwendungsfall Beschreibung Best-Fit Begründung
Hochleistungsfähige Batchverarbeitung Jede Automatisierung, die Tausende von Datensätzen effizient verarbeiten muss Apex Apex bietet umfangreiche APIs für die Anbindung an die Plattform und für die Rohgeschwindigkeit.
Komplexe Datenverarbeitung Szenarien, in denen erweiterte Datenmanipulationen erforderlich sind Apex Apex stellt Datenstrukturen wie "Karte" und "Satz" bereit, die in Flow nicht nativ verfügbar sind und für das Schreiben von performantem Code mit Massensicherheit entscheidend sein können.
Transaktionssteuerung Kontrollmechanismen wie Speicherpunkte, Rollbacks und Teil-Commits Apex Apex bietet Zugriff auf Mechanismen wie Database.savepoint und Database.rollback und kann teilweise erfolgreiche DML-Vorgänge verarbeiten.
Hochentwickelte benutzerdefinierte Validierung Datenvalidierung über mehrere Felder in einem Datensatz hinweg Apex Flow kann zwar mit dem Element "CustomError" ein Speichern verhindern, ist jedoch nicht in allen Flow-Typen verfügbar, einschließlich Subflows. Die Apex addError()-Methode stellt mehrere feldspezifische Fehlermeldungen bereit, die einem Datensatz jederzeit während der Auslöserverarbeitung hinzugefügt werden können.
Mittelkomplexe Logik in einem einfachen Prozess Logik- und Datenmanipulation mit moderater Komplexität, vereinfacht durch eine Standardbibliothek erweiterter Funktionen, die als Teil eines unkomplizierten Prozesses erfolgt Flow + Apex Durch einen Datensatz ausgelöster Flow fungiert als Orchestrierungsebene, während hochkomplexe Vorgänge in aufrufbarem Apex gekapselt sind.
Einfache bis mittelkomplexe Logik Datenmanipulation mit geringer bis mittlerer Komplexität mit Auslöseraktualisierungen an den primären und verwandten Datenobjekten Flow Flow ist in der Regel die Option, die aufgerufen werden kann, da er auf einem deklarativen Modell basiert, das sowohl für Administratoren als auch für Entwickler zugänglich ist.
Benachrichtigungen und ausgehende Nachrichten Senden von ausgehenden E-Mails und Nachrichten Flow Mit Flow können E-Mail-Benachrichtigungen und ausgehende Nachrichten zu Datensatzänderungen einfach und hochgradig skaliert werden.
Geplante Verarbeitung Automatisierung zu einem zukünftigen dynamischen Datum (z. B. 3 Tage vor einem Schlusstermin) Flow Geplante Pfade bieten Flow eine einzigartige Stärke, da die Plattform automatisch die Planung, Stornierung und Neuplanung dieser Pfade übernimmt, wenn sich die Daten des Datensatzes ändern.
### Skalierbare Verarbeitung: Asynchrone Anwendungsfälle in der Tiefe Die Skalierbarkeit ist eine wichtige Überlegung beim Entwerfen Ihrer Implementierung. Wenn die Geschäftslogik einer durch einen Datensatz ausgelösten Automatisierung komplex, langfristig oder mit hohen Datenvolumen verbunden wird, werden die zentralen Obergrenzen der Salesforce Platform zu einer architektonischen Einschränkung. Vorgänge wie Massendatenaktualisierungen, komplexe API-Callouts oder schwere Berechnungen erhöhen das Risiko, dass Obergrenzen überschritten werden, beispielsweise die CPU-Gesamtzeit oder die Anzahl der DML-Anweisungen innerhalb einer einzelnen Datenbanktransaktion. Ein Fehler in einem synchronen Auslöser aufgrund einer Obergrenzenausnahme führt dazu, dass die gesamte Speichertransaktion des Benutzers zurückgesetzt wird, was zu einer schlechten Benutzererfahrung und potenziellem Datenverlust führt. Dieses inhärente Risiko erfordert ein Architekturmuster, um komplexe Arbeiten abzuladen. Die asynchrone Automatisierung wird in diesem Fall unerlässlich. Mithilfe asynchroner Mechanismen können Architekten die Arbeit mit langem oder hohem Volumen effektiv von der primären synchronen Datensatzspeichertransaktion entkoppeln. Speichert den Vorgang schnell und zuverlässig, während die schwere Verarbeitung an eine separate, von der Plattform verwaltete Transaktion delegiert wird, die später ausgeführt wird. Die Entkopplung verbessert die Stabilität, verhindert Transaktionsfehler und ist entscheidend für die Erstellung skalierbarer Unternehmensanwendungen. Die Plattform bietet hierfür mehrere spezielle Tools, die jeweils unterschiedliche Vorteile und Kompromisse hinsichtlich Zuverlässigkeit, Volumen und Komplexität bieten. ### Asynchroner Pfad des Flows Der Pfad "Asynchron ausführen" in einem durch einen Datensatz ausgelösten Flow bietet den einfachsten Mechanismus für die asynchrone Logik "auslösen und vergessen". Dieser Pfad wird in einer separaten Transaktion ausgeführt, nachdem die ursprüngliche Datensatzspeichertransaktion erfolgreich in die Datenbank übernommen wurde. - **Idealer Anwendungsfall**: Dies eignet sich gut für Aufgaben, die keine sofortige Ausführung oder benutzerdefinierte Fehlerbehandlung erfordern. Beispiele sind das Senden einer E-Mail-Benachrichtigung, das Erstellen einer Folgeaufgabe oder das Senden eines einfachen Callouts an ein externes System. - **Einschränkungen**: Dieser Mechanismus hat dieselben Obergrenzen für tägliche Flows wie andere asynchrone Flow-Interviews. Sie ist nicht für die Verarbeitung extrem hoher Volumen ausgelegt. ### Datenerfassung ändern (CDC) Bei der Datenerfassung für Änderungen handelt es sich um ein skalierbares und robustes Muster mit hohem Durchsatz für die Verarbeitung asynchroner Logik, die durch eine Datensatzänderung in Szenarien mit hohem Volumen ausgelöst wird. In diesem Modell besteht die einzige Verantwortung des Auslösers darin, den Datensatz synchron zu speichern. Anschließend veröffentlicht die Plattform eine detaillierte Ereignismeldung, die die Änderungen des Datensatzes an einem Ereignis-Bus mit hohem Volumen enthält. Dieses Änderungsereignis wird von einem separaten, dedizierten Apex-Auslöser abonniert. Sie führt komplexe, langfristige oder asynchrone Arbeit aus. - **Vorteil**: Durch dieses Muster wird der asynchrone Prozess von der anfänglichen Benutzertransaktion entkoppelt. Ein Fehler bei der asynchronen Verarbeitung führt nicht dazu, dass der Datensatzspeicher des Benutzers wiederhergestellt wird. Das Muster bietet auch einen dauerhaften Ereignis-Stream, den mehrere interne Abonnenten oder externe Systeme nutzen können, und Ereignisse können bis zu 72 Stunden lang wiedergegeben werden, was eine hohe Widerstandsfähigkeit bietet. - **Einschränkungen**: CDC-Ereignismeldungen enthalten nicht den vorherigen Status des Datensatzes, was einer Apex `Trigger.oldMap` entspricht. Die Ereignisnutzlast enthält die neuen Feldwerte, jedoch nicht die Werte, von denen sie geändert wurden. Dies macht es schwierig, Logik basierend auf einer bestimmten Statusumstellung zu implementieren (beispielsweise nur dann auszuführen, wenn die `Status__c` von "Ausstehend" zu "Genehmigt" geändert wurde). Sie können dies abmildern, indem Sie den Feldverlauf des Objekts im Ereignisabonnenten abfragen. Dies erhöht jedoch die Komplexität des Prozesses und die Feldverlaufsverfolgung ist möglicherweise für das betreffende Feld nicht verfügbar. Dies kann die Arten von Automatisierung einschränken, die Sie auf CDC ausladen können. CDC kann standardmäßig für maximal fünf Salesforce-Objekte aktiviert werden. Organisationen, die mehr benötigen, können eine Add-On-Lizenz erwerben, die diese Obergrenze entfernt und die Zuteilungen für die Ereigniszustellung erhöht. ### Warteschlangenfähiger Apex über einen Auslöser Die direkte Warteschlange für einen warteschlangenfähigen Apex-Auftrag über einen Auslöser sollte als riskantes Muster betrachtet werden, das nur verwendet wird, wenn Apex Steuerung erforderlich ist (z. B. für komplexe Logik oder benutzerdefinierte Wiederholungsmechanismen) und CDC keine praktikable Option ist. Wenn Queueable Apex erforderlich ist, muss die Implementierung die entsprechenden Schutzmaßnahmen enthalten: - **Einschränkungsprüfungen**: Der Code muss die Anzahl der Aufträge überprüfen, die bereits in der Transaktion in die Warteschlange gestellt wurden, bevor versucht wird, einen weiteren hinzuzufügen. ``` if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... } ``` - **Kontextbewusstsein**: Der Code muss erkennen, ob er in einem asynchronen Kontext ausgeführt wird, beispielsweise einem Batchauftrag (`System.isBatch()`), und sein Verhalten ändern, um die strengere Obergrenze von einem Auftrag pro Transaktion in diesem Kontext einzuhalten. ### Überlegungen zu Einschränkungen für ausgelöstes asynchrones Apex Das Aufrufen von asynchronem Apex über einen synchronen Auslöser birgt Stabilitätsrisiken. Um Auswirkungen auf Organisationsebene (z. B. Überschreiten von Obergrenzen) zu vermeiden, erfordert dieses Muster ein strenges Design und Tests. - Die tägliche Obergrenze für asynchrone Apex-Ausführungen (`Batch`, `Queueable`, `@Future`) wird organisationsweit freigegeben (in der Regel 250 000 oder eine Berechnung anhand von Benutzerlizenzen). Bei einem Massenvorgang mit 20.000 Datensätzen wird ein Auslöser in 200 Blöcken ausgeführt, was zu 100 separaten Auslöseraufrufen führt – noch mehr, wenn die Massenvorgangsgröße weniger als 200 Datensätze beträgt. Wenn jeder Aufruf einen asynchronen Auftrag in die Warteschlange stellt, kann ein erheblicher Teil der täglichen Obergrenze aus einer einzelnen Datenladung verbraucht werden. Dieser Verbrauch kann andere wichtige Geschäftsprozesse asynchroner Ressourcen potenziell aussterben lassen. - Die Obergrenzen für die Warteschlange für Aufträge sind je nach Kontext drastisch unterschiedlich. Bei einem Auslöser, der durch eine Benutzeraktion auf der Benutzeroberfläche ausgelöst wird (eine _synchrone_ Transaktion), können bis zu 50 warteschlangenfähige Aufträge in die Warteschlange gestellt werden. Bei einem Auslöser, der innerhalb der `execute`-Methode einer Batch-Apex-Klasse ausgelöst wird (eine _asynchrone_ Transaktion), kann jedoch nur ein warteschlangenfähiger Auftrag in die Warteschlange gestellt werden. Wenn dieser Unterschied nicht berücksichtigt wird, ist dies ein häufiger und wichtiger Fehlerpunkt, der bei Vorgängen mit großen Daten zu `LimitException` führt. - Ein Anti-Pattern stellt das Aufrufen von Planbarem Apex (`System.schedule`) oder Batch Apex (`Database.executeBatch`) direkt über einen Auslöserkontext dar. Diese Methoden sind nicht für den Aufruf im Auslöserkontext vorgesehen. Dies führt zu einem schnellen Verbrauch Ihrer asynchronen Apex Zuteilung, was zu Einschränkungen führt. ### Auswählen des richtigen asynchronen Musters Jeder asynchrone Mechanismus weist spezifische Kompromisse hinsichtlich Leistung, Obergrenzen und Zuverlässigkeit auf. Anhand dieser Entscheidungsstruktur können Sie in diesen Optionen navigieren und den richtigen Mechanismus für Ihren Anwendungsfall auswählen. Entscheidungsstruktur für asynchrones Muster ### Die Alternative für geplante Aufträge Wie aus dem Diagramm hervorgeht, besteht die beste architektonische Wahl oft darin, einen durch einen Auslöser aufgerufenen Prozess vollständig zu vermeiden, wenn Sie mit DML-Vorgängen mit hohem Volumen konfrontiert sind, die Datenerfassung jedoch nicht verwenden können (möglicherweise aufgrund von Objektobergrenzen). Verwenden Sie stattdessen einen geplanten Prozess. Dies kann entweder ein geplanter Flow oder geplanter Apex sein. Erforderliche Schritte sind: 1. Führen Sie eine einfache kostengünstige Aktualisierung im synchronen Auslöser aus. Legen Sie beispielsweise ein `Status__c`-Feld auf "Verarbeitung ausstehend" fest oder fügen Sie einen verwandten Datensatz mit niedrigen Kosten ein, beispielsweise einen Chatter Post, um anzugeben, dass der Datensatz verarbeitet werden muss. 2. Erstellen Sie einen geplanten Auftrag, entweder einen geplanten Flow oder geplanten Apex, der regelmäßig ausgeführt wird, beispielsweise alle 15 Minuten oder stündlich. 3. Lassen Sie den geplanten Auftrag für alle Datensätze im Status "Ausstehend" abfragen, führen Sie die komplexe Logik in einem kontrollierten Kontext mit hohem Volumen aus und aktualisieren Sie dann die verarbeiteten Datensätze. Dieses Muster entkoppelt die schwere Verarbeitung vollständig vom synchronen Speichern des Benutzers, unterliegt nicht der Obergrenze von einem Auftrag pro Transaktion eines ausgelösten Batches und bietet eine hochgradig skalierbare und regelbare Lösung für Nicht-Echtzeitanforderungen. Wenn die Latenz eines geplanten Auftrags für die Geschäftsanforderungen nicht akzeptabel ist und Sie weiterhin CDC oder eine ausgelöste Warteschlange nicht verwenden können, deutet dies auf eine erhebliche architektonische Inkongruenz hin. An dieser Stelle müssen verschiedene Mechanismen in Betracht gezogen werden. Die erneute Bewertung des Designs der Kernanwendung kann zu bestimmten Schlussfolgerungen führen, beispielsweise: - Erwerb des Add-Ons zum Entfernen der CDC-Objektobergrenzen. - Die geschäftliche Anforderung, festzustellen, ob die Verarbeitung nahezu in Echtzeit wirklich ein "Must-have" ist oder ob die Latenz eines geplanten Auftrags ein akzeptabler Kompromiss für die Plattformstabilität ist, wird grundlegend herausgefordert. ## Nicht funktionale Überlegungen Zusätzlich zu den Entscheidungspunkten müssen Sie nicht funktionale Überlegungen wie Komplexität und Standards berücksichtigen. ### Komplexität Der Komplexitätsgrad einer Implementierung ist Teil der Gesamtbetriebskosten einer Lösung und ihrer Fähigkeit, sich an sich ändernde Geschäftsanforderungen anzupassen. Komplexität kann sich auf jede Implementierung auswirken, wenn bewährte Vorgehensweisen nicht befolgt werden. Im Abschnitt "_Verwandte bewährte Vorgehensweisen_" dieses Dokuments finden Sie Empfehlungen zur Reduzierung der Komplexität Ihrer Lösung, einschließlich der folgenden Muster: - Hybridmuster: Aufrufbares Apex für komplexe Logik im Flow - Verwenden eines Metadaten-Frameworks für Apex-Auslöser - Mega-Flows im Vergleich zu mehreren Flows ### Prozesse und Standards Die Dokumentation ist so wichtig wie die Automatisierung selbst. Sie gewährleistet nicht nur die Wartbarkeit, sondern ist auch für AI und agentenbasierte Tools entscheidend. Mithilfe der Dokumentation können Sie Ihre Geschäftsprozesse verstehen und verwalten. **Im Flow** - Richten Sie eine konsistente Benennungskonvention für alle Elemente und Variablen ein. - Verwenden Sie das Feld "Beschreibung" für den Flow, um seinen allgemeinen Zweck, seine Auslösekriterien und sein beabsichtigtes Ergebnis zu erläutern. - Verwenden Sie das Feld Beschreibung für jedes einzelne Element (z. B. `Get Records`, `Action`, `Transform`). Diese Vorgehensweise ist die beste Möglichkeit, Intent zu vermitteln. Dies ist besonders wichtig für aufrufbare Aktionen und Subflows, bei denen die Beschreibung der primäre Ort ist, um die komplexe Logik zu erklären, die von der Aktion ausgeführt wird. **In Apex** - Kommentieren Sie Ihren Code deutlich, um zu erklären, _warum_ Ihre Logik dahintersteckt, und nicht nur, _was_. - Stellen Sie bei Verwendung eines metadatengesteuerten Frameworks sicher, dass Ihre Metadatensätze ein für Menschen lesbares Beschreibungsfeld enthalten und ausfüllen, um zu erläutern, was jede Handler-Klasse vornimmt und wann sie ausgeführt werden soll. DevOps- und Quellcodeverwaltung ist Teil eines ausgereiften Entwicklungslebenszyklus. Verwenden Sie immer ein Quellcodeverwaltungstool wie Git für Salesforce-Projekte. Sowohl Apex-Klassen als auch Salesforce-Flows sind Metadaten, die Ihre Geschäftslogik definieren. Sie müssen versioniert und verwaltet werden. Im Kontext der Verwaltung von durch Datensätze ausgelösten Automatisierungen bietet eine moderne DevOps-Pipeline wesentliche Vorteile. - **Automatische Qualitätsprüfungen:** Tools wie [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) können so konfiguriert werden, dass sie automatisch in Ihrer Pipeline ausgeführt werden. Statische Analysen können problematische Muster in beiden Automatisierungstools erkennen, bevor sie höhergestuft werden, und Probleme wie ineffiziente `Get Records` in einer Flow-Schleife oder `SOQL` in einer Apex-Schleife kennzeichnen, die häufige Ursachen für Leistungseinbußen sind. - **Regressionsprävention:** Wenn Ihre Automatisierungsdichte steigt, kann eine Änderung an einer Flow- oder Apex-Klasse unbeabsichtigte Konsequenzen für andere Automatisierungen im selben Objekt haben. Eine zuverlässige DevOps-Teststrategie, bei der automatisierte Apex-Tests anhand vorgeschlagener Änderungen ausgeführt werden, ist die zuverlässigste Methode, um sicherzustellen, dass eine neue Flow-Version die vorhandene Apex-Logik nicht beschädigt (und umgekehrt). - **Zusammenarbeit und Sichtbarkeit:** Die Quellcodeverwaltung ist die "einzige Quelle der Wahrheit". Dadurch können Administratoren und Entwickler parallel an der Automatisierung für dasselbe Objekt arbeiten. Es bietet auch einen unschätzbaren Prüfpfad: Wenn ein Produktionsprozess fehlschlägt, können Sie sofort sehen, _wer_ die Automatisierung geändert hat, _wann_ sie geändert wurde und – über Commit-Meldungen –, _warum_ sie geändert wurde. Teams mit einer Mischung aus Administratoren und Entwicklern bietet das [DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) eine vereinheitlichte Oberfläche, mit der alle diese Schritte choreographiert werden können, sodass jeder im Team auf einen skalierbaren, auf Quellcodeverwaltung basierenden Entwicklungsprozess zugreifen kann. Diese kombinierte Disziplin der Dokumentation und DevOps gewährleistet die langfristige Integrität und Wartungsfähigkeit Ihrer Organisation, was jedem Architekten und Administrator zugute kommt, der Ihnen folgt. ## Verwandte bewährte Vorgehensweisen Die oben stehende Entscheidungsanleitung wird am besten vor der Planung Ihrer Implementierung verwendet. Es soll Ihnen bei der Auswahl des besten Produkts für Ihre Anwendungsfälle helfen. Nach der Produktauswahl ist es wichtig, die vorhandenen bewährten Vorgehensweisen für Ihre Implementierung zu verstehen. ### Ausnutzen des Hybridmusters: Aufrufbares Apex für komplexe Logik im Flow Das Prinzip _"Ein Tool pro Objekt_" ist für die Verwaltung der Automatisierung mit hoher Dichte wichtig. Sie sollten es jedoch nicht als binäre Auswahl zwischen einem rein deklarativen oder einem rein programmgesteuerten Stapel interpretieren. Ein effektiveres und pflegeleichteres Architekturmuster nutzt ein Hybridmodell: Positionieren Sie "Durch Datensatz ausgelöster Flow" als Orchestrierungsebene, während Sie hochkomplexe Vorgänge in "Aufrufbarer Apex" kapseln. Hybrides Musterdiagramm #### Orchestrierungsebene: Flow Durch einen Datensatz ausgelöster Flow dient als Orchestrierungsebene für den Geschäftsprozess. Er ist Inhaber der Eingabekriterien und des Ausführungskontexts (das _Was_ und _Wann_). Durch Beibehaltung der Entscheidungslogik und der Weiterleitung innerhalb dieser Ebene bleibt die Prozesstopologie der Architektur transparent und kann über den Flow-Auslöser-Explorer verwaltet werden, wodurch verhindert wird, dass wichtige Geschäftslogik im Code verdeckt wird. #### Die komplexe Komponente: Aufrufbares Apex Ein häufiges Beispiel für eine komplexe Komponente ist die Implementierung von Service Level Agreement-Berechnungen (SLA) für Kundenvorgangsdatensätze. Da das Objekt "BusinessHours" und die zugehörige Logik, die für genaue Berechnungen ohne Arbeitszeiten und Feiertage wichtig sind, in Flow nicht nativ zugänglich sind, wird eine spezielle Apex-Klasse verwendet. Diese Klasse, die oft als `ServiceLevelAgreementCalculator` bezeichnet wird, wurde mit einer einzigen statischen Methode entwickelt, die mit `@InvocableMethod` gekennzeichnet ist, um die verstrichenen Geschäftszeiten zu berechnen, zu bestimmen, ob das SLA "Innerhalb des Ziels" oder "Verletzt" lautet, und eine strukturierte Ausgabe zurückzugeben. Dieser Ansatz fasst die komplexe Hochleistungslogik in Apex zusammen und ermöglicht ihre nahtlose Ausführung und Integration in die deklarative Orchestrierungsebene eines durch einen Datensatz ausgelösten Flows. Sobald die Apex `ServiceLevelAgreementCalculator` definiert ist, kann sie in einem durch einen Datensatz ausgelösten Flow verwendet werden: Dieses Muster zeigt eine strikte Trennung der Bedenken. Die deklarative Ebene wird zum Verwalten des Transaktionslebenszyklus und der Orchestrierung verwendet, während Code für die Ausführung mit hoher Komplexität verwendet wird. Indem Code als funktionales Dienstprogramm und nicht als Grundlage behandelt wird, halten wir Leistung und Wartungsfreundlichkeit in Einklang. #### Wichtige Gewinne mit dem Hybridmuster **Modularität**: Die Entscheidung weicht von der Besonderheit der Verwendung von Apex oder Flow für den gesamten Prozess ab. Stattdessen kapselt die Architektur komplexe Logik in diskrete, massensichere und unabhängig testbare Einheiten. Diese Einheiten fungieren als wiederverwendbare Komponenten, die von der deklarativen Ebene verbraucht werden, und stellen sicher, dass die Automatisierung skaliert wird, ohne dass die architektonische Planung kompliziert wird. **Wiederverwendbarkeit**: Die Logik ist vom Auslöserereignis getrennt. Eine gut gestaltete Code-Einheit (z. B. ein `InvocableMethod`) wird einmal geschrieben, jedoch über mehrere Eingangspunkte hinweg verwendet: Durch Datensätze ausgelöste Flows, Bildschirm-Flows oder externe Integrationen. Durch diese Code-Wiederverwendung entfällt die redundante Entwicklung. **Wartbarkeit**: Die Prozess-Flow-Logik bleibt im deklarativen Flow sichtbar und verwaltbar. Durch diese Zentralisierung wird der Debugging-Overhead drastisch reduziert und sichergestellt, dass die Ausführungsreihenfolge des Systems deterministisch und transparent ist. #### Einschränkungen und Kompromisse des Hybridmusters Das hybride Modell der Verwendung von aufrufbarem Apex aus Flow ist zwar leistungsfähig, aber kein Ansatz für alle. Architekten müssen sich der spezifischen Einschränkungen und Kompromisse bewusst sein, bevor sie sich auf eine Hybridlösung festlegen. - **Keine Unterstützung vor dem Speichern**: Dies ist die wichtigste Einschränkung. Aufrufbare Aktionen sind nur im Kontext nach dem Speichern verfügbar (Flows für Aktionen und verwandte Datensätze). Sie können nicht im leistungsstarken Kontext vor dem Speichern verwendet werden (Flows für schnelle Feldaktualisierungen). Daher kann dieses Muster nicht zum Delegieren von Feldaktualisierungen desselben Datensatzes verwendet werden. Erledigen Sie diese leistungsstarke Arbeit mit nativen Flow-Elementen in einem Flow vor dem Speichern oder in einem Apex-Auslöser vor dem Kontext. - **Keine Unterstützung nach dem Rückgängigmachen der Löschung:** Der durch einen Datensatz ausgelöste Flow unterstützt derzeit den Kontext nach dem Rückgängigmachen des Löschens nicht. Wenn für ein Salesforce-Objekt eine geschäftliche Anforderung besteht, die Automatisierung auszuführen, wenn ein Datensatz aus dem Papierkorb wiederhergestellt wird, ist ein Apex-Auslöser die einzige Lösung. - **Leistungs-Overhead in Szenarien mit hohem Volumen:** Der Übergang von der Flow-Laufzeit zur Apex-Laufzeit ist kein Nullkostenvorgang. Obwohl sie im Allgemeinen schnell ist, ist der Vorgang, bei dem Sie von der Laufzeit des Flows aus in eine aufrufbare Aktion wechseln, nicht so rechenschnell wie die native Ausführung, die vollständig in einem Apex Auslöser verbleibt. Für die meisten Automatisierungen mittlerer Dichte ist dieser Micro-Overhead ein vernachlässigbarer und lohnender Kompromiss für die verbesserte Barrierefreiheit. Bei extrem leistungsstarken Szenarien mit hohem Volumen bietet ein reines Apex-Framework jedoch einen Vorteil bei der Berechnungsgeschwindigkeit. ### Strategien für die veraltete Automatisierung Während die Heuristik der Automatisierungsdichte eine definitive Orientierungshilfe für neuere Greenfield-Architekturen bietet, ist die Realität in Salesforce-Unternehmensumgebungen oft differenzierter. In ausgereiften Organisationen finden sich häufig durch Datensätze ausgelöste Flows und Apex-Auslöser, die mit demselben Salesforce-Objekt arbeiten. Dieses Szenario unterscheidet sich von dem zuvor erläuterten hybriden Muster: Dabei sind die Flows und Apex Auslöser weder gekoppelt noch für die Zusammenarbeit ausgelegt. Diese Koexistenz ist oft das Ergebnis sich entwickelnder Plattformfunktionen oder veralteter technischer Schulden. Obwohl dies ein tolerierter Betriebszustand ist, müssen Architekten ihn als berechneten Kompromiss und nicht als Endzustand behandeln. Die fragmentierte Orchestrierung verursacht einen erheblichen Verwaltungs- und Wartungsaufwand, wodurch Entwicklungs-, Test- und Vorfallsbearbeitungsaktivitäten uneinheitlich und umständlich werden. Dies führt zu einer erhöhten Time to Resolution (TTR) und betrieblichen Komplexität. - Halten Sie sich bei neuen Salesforce-Objekten an das Prinzip der Automatisierungsdichte als primäre Anleitung. - Bewerten Sie bei vorhandenen Salesforce-Objekten mit hybrider Bilanz und doppeltem Apex-Auslöser und durch einen Datensatz ausgelösten Flow-Eingangspunkten die Dichte und konzipieren Sie dann den Refaktor in einen aufrechterhaltenswerten Hybridzustand. - Bei geringer Dichte werden durch Refaktor-Apex ausgelöste Flows durch einen Datensatz ausgelöst und die Ausführungsreihenfolge angegeben, wodurch sie an einen einzigen Automatisierungs-Eingangspunkt gelangen. - Bei mittlerer Dichte fließen komplexe Mega-Flows in eine Teilmenge von Flows mit der richtigen Ausführungsreihenfolge ein. Führen Sie Apex-Auslöser nur dann ein, wenn dies unbedingt erforderlich ist, z. B. zur Unterstützung nach dem Rückgängigmachen des Kontexts. - Bei hoher Dichte bevorzugen Sie die Implementierung von Apex Auslösern. ### Verwenden eines Metadaten-Frameworks für Apex-Auslöser Wenn die Geschäftsprozesse einer Organisation auf der Salesforce Platform reifen, steigen zwangsläufig das Volumen und die Komplexität der durch Datensätze ausgelösten Automatisierung. Eine grundlegende bewährte Vorgehensweise besteht darin, _einen Apex-Auslöser pro Salesforce-Objekt_ beizubehalten. Diese Regel ist wichtig, da die Plattform die Ausführungsreihenfolge mehrerer Auslöser für dasselbe Objekt für dasselbe Ereignis nicht garantiert. Diese Einschränkung kann zu nicht deterministischem Verhalten, Rassenbedingungen und schwierig zu debuggenden Problemen führen. Die Einhaltung des Prinzips _eines Auslösers_ stellt jedoch eine architektonische Herausforderung dar: wie Sie alle Geschäftslogiken, die über diesen zentralen Einstiegspunkt aufgerufen werden, verwalten und orchestrieren können, und zwar auf eine wartungsfreundliche und skalierbare Weise. #### Die Einschränkungen von Classic-Auslöser-Handlern Die erste Entwicklung dieser Architektur war das Classic-Auslöser-Handler-Muster. Bei diesem Ansatz delegiert der einzelne Apex-Auslöser seine gesamte Logik an eine entsprechende Handler-Klasse (beispielsweise `OpportunityTriggerHandler`). Diese Methode trennt die Logik von der Auslöserdatei und bietet Entwicklern deterministische Kontrolle über die Ausführungsreihenfolge innerhalb der Methoden der Handler-Klasse (z. B. `afterInsert()`). Obwohl dieses Muster eine Verbesserung darstellt, führt es häufig zu monolithischen Handler-Klassen. Im Laufe der Zeit wird die Klasse groß, schwer zu verwalten und schwer isoliert zu testen, da mehr Geschäftsanforderungen hinzugefügt werden. Die Ausführungsreihenfolge aller einzelnen Prozesse ist innerhalb einer einzelnen Methode hartcodiert, wodurch die Klasse anfällig für Zusammenführungskonflikte ist, was den Verwaltungs- und Wartungsaufwand in einer großen Unternehmensumgebung drastisch erhöht. #### Die Lösung: Ein metadatengesteuertes Auslöser-Framework Architekten wechseln zum **Metadaten-gesteuerten Auslöser-Framework**, um die Kernprobleme der Modularität und Orchestrierung zu lösen. Dies ist ein bedeutender architektonischer Sprung, der die Automatisierungslogik selbst von der Konfiguration _der Art_ und _Weise der_ Ausführung entkoppelt. Dieses Framework basiert auf drei wichtigen Vorteilen: - **Partitionierung:** Anstelle einer einzigen Handler-Klasse wird die Kerngeschäftslogik in kleine, atomare Apex-Klassen (beispielsweise eine `RecalculateAccountValues`-Klasse oder eine `NotifySalesLeads`-Klasse) unterteilt, wobei jede Klasse dem _Prinzip der einzelnen Verantwortung_ folgt. Durch diese Modularität können Logik einfacher isoliert getestet, debuggt und verstanden werden. - **Auftrag und Choreografie:** Der Ausführungsauftrag ist in Apex nicht mehr hartcodiert. Stattdessen wird er deklarativ durch Konfigurationsdatensätze definiert, die in der Regel in einem benutzerdefinierten Metadatentyp (z. B. `TriggerAction__mdt`) gespeichert sind. Dadurch können Administratoren Automatisierungsaktionen einfach neu anordnen, hinzufügen oder entfernen, indem sie einen Metadatensatz ändern, was keine Bereitstellung oder Codeänderung erfordert. - **Bypass-Funktion:** Das Framework bietet standardisierte, granulare Bypass-Funktionen. Jede Automatisierungsaktion kann über ihren Metadatensatz so konfiguriert werden, dass sie global deaktiviert oder für bestimmte Verwaltungsbenutzer durch Verweisen auf eine benutzerdefinierte Berechtigung umgangen wird. Der einzelne Apex-Auslöser für das Objekt fungiert dann nur noch als dynamischer Disponent. Sie enthält keine Geschäftslogik, sondern instanziiert stattdessen eine zentrale `MetadataTriggerHandler`. Dieser Handler fragt die benutzerdefinierten Metadatensätze ab, um die Ausführungsreihenfolge dynamisch zu bestimmen und die richtigen atomaren Apex-Klassen in der vorgegebenen Reihenfolge aufzurufen. Die Automatisierung wird unter einer einzigen, transparenten und regelbaren Ebene vereinheitlicht. ### Duplizieren teurer Vorgänge in der Transaktion Ein wichtiger Vorteil der Verwendung von Apex in einem robusten Framework ist die Möglichkeit, den Transaktionsstatus zu verwalten und die Leistung zu optimieren, da redundante Arbeit entfällt. Wenn sich Logik ansammelt, ist es üblich, dass unterschiedliche Automatisierungen innerhalb des Speicherauftrags dieselben teuren Vorgänge unabhängig ausführen, wodurch wertvolle Obergrenzen verbraucht und die DML-Vorgangszeit erhöht wird. Das Framework ist so konzipiert, dass es diesem Problem mit zwei primären Strategien begegnet: - **Gemeinsame Bundesstaatsverwaltung:** Im Rahmen einer einzelnen Apex-Transaktion werden statische Eigenschaften und Variablen zum Zwischenspeichern von Daten verwendet. Dadurch wird sichergestellt, dass ein teurer Vorgang wie eine `SOQL` für eine Konfigurationseinstellung nur einmal ausgeführt wird, selbst wenn die Automatisierungslogik mehrfach über verschiedene Datensätze oder Phasen des Auslösers hinweg aufgerufen wird. Der Verbrauch von Transaktionsobergrenzen wird erheblich reduziert. - **Plattform-Cache-Auslastung:** Verwenden Sie den Plattform-Cache, um zu vermeiden, dass die gesamte Datenbank nach bestimmten Daten abgefragt wird, um über die einfache Zwischenspeicherung innerhalb der Transaktion hinauszugehen. Dieser verwaltete Speicher-Cache eignet sich ideal zum Abrufen von Daten, die nicht primitiv sind, häufig in der Codebasis gelesen werden und im Laufe einer Transaktion unveränderlich sind (z. B. Profile, Rollen, Geschäftszeiten). Über die `Cache.CacheBuilder` überprüft das System zunächst den Cache und führt die Datenbankabfrage nur aus, wenn die Daten nicht vorhanden sind, was die Leistung und Skalierbarkeit maximiert. ### Verwenden vor dem Speichern für Aktualisierungen desselben Datensatzes Verwenden Sie immer eine Aktualisierung vor dem Speichern, wenn Ihre Automatisierung nur Feldwerte für den Datensatz ändern muss, der die Transaktion startet. Dies gilt für Schnellfeldaktualisierungen in Flow (die vor dem Speichern ausgeführt werden) und für Vor-Kontext-Logik in Apex Triggers (vor dem Einfügen, vor der Aktualisierung). Dieses Muster ist unabhängig vom verwendeten Tool leistungsfähig, da ein zweiter DML-Vorgang und ein rekursiver Speicherzyklus vermieden werden. Die Änderungen werden am Datensatz im Arbeitsspeicher vorgenommen, _bevor_ er in die Datenbank übernommen wird, und als Teil der ursprünglichen Transaktion gespeichert. Der Overhead eines zweiten Speichervorgangs, der andernfalls den gesamten Speicherauftrag erneut ausführen und die gesamte Automatisierung erneut auslösen würde, entfällt. ### Verhindern unkontrollierter Rekursionen Unkontrollierte Rekursion ist ein häufiger Fallstrick bei Auslösern nach der Aktualisierung, bei denen die Logik eines Auslösers eine DML-Aktualisierung ausführt, die wiederum dazu führt, dass derselbe Auslöser erneut ausgelöst wird. Dadurch wird eine Endlosschleife erstellt, die schließlich mit einer Ausnahme der Obergrenze endet. Obwohl statische boolesche Kennzeichnungen oder Sammlungen verarbeiteter Datensatz-IDs in der Vergangenheit verwendet wurden, um eine solche Rekursion zu verhindern, besteht ein genaueres und zuverlässigeres Muster darin, die Logik durch Vergleich von Feldwerten zwischen der neuen und der alten Version des Datensatzes selbst zu verbinden. Führen Sie die Logik nur dann aus, wenn sich ein bestimmtes interessierendes Feld tatsächlich geändert hat. Dadurch wird verhindert, dass der Auslöser seine Logik bei nachfolgenden DML-Vorgängen innerhalb derselben Transaktion ausführt, bei denen die wichtigen Daten unverändert bleiben. #### Steuern der Rekursion im durch einen Datensatz ausgelösten Flow Verhindern Sie in einem durch einen Datensatz ausgelösten Flow eine unkontrollierte Rekursion, indem Sie den Flow so festlegen, dass er nur ausgeführt wird, wenn der Datensatz aktualisiert wird, um die Bedingungsanforderungen zu erfüllen: Steuern der Rekursion im durch einen Datensatz ausgelösten Flow Wenn Sie eine Eingabekriterienformel in Ihrem Flow verwenden, können Sie eine Rekursion verhindern, indem Sie die globale Variable `$Record` (die die neuen Werte darstellt) mit der globalen Variable `$RecordPrior` (die die ursprünglichen Werte vor dem Speichern darstellt) vergleichen. Wenn Sie beispielsweise sicherstellen möchten, dass ein Flow nur ausgeführt wird, wenn sich das Feld "Betrag" für eine Opportunity geändert hat, verwenden Sie dies in den Eingabekriterien: ``` $Record.Amount != $Record__Prior.Amount ``` #### Steuern der Rekursion in Apex Vergleichen Sie Feldwerte aus der neuen Version des Datensatzes `Trigger.new` mit den Feldwerten aus der alten Version des Datensatzes `Trigger.oldMap`, um festzustellen, ob die gewünschte Änderung stattgefunden hat. Durch diesen Ansatz wird sichergestellt, dass die Automatisierung idempotent ist und nur bei Bedarf ausgeführt wird, wodurch das System effizienter wird und katastrophale rekursive Schleifen verhindert werden. ### Automatisierung umgehen Eine gut strukturierte Salesforce-Organisation erfordert einen konsistenten und zuverlässigen Mechanismus zur Umgehung der Automatisierung. Dies ist keine optionale Funktion, sondern eine zentrale betriebliche Voraussetzung für die Aufrechterhaltung der Datenintegrität und die Aktivierung von Verwaltungsaufgaben. Ein Bypass-Framework ist für einige Szenarien unerlässlich: - Beim Laden großer Datenmengen kann das Auslösen von Auslösern für jeden Datensatz den Prozess drastisch verlangsamen, zu Obergrenzenausnahmen führen und fehlerhafte zugehörige Datensätze und Benachrichtigungen erstellen. Über eine Umgehung können die Daten sauber und effizient eingefügt werden. - Ein Integrationsbenutzer muss möglicherweise Daten aus einem externen Datensatzsystem synchronisieren. Die Automatisierung, die normalerweise für eine vom Benutzer initiierte Änderung ausgelöst wird (z. B. Senden einer E-Mail oder Erstellen einer Aufgabe), kann unerwünscht oder redundant sein, wenn die Änderung von einem anderen System stammt. - Administratoren oder Supportmitarbeiter müssen möglicherweise Korrekturaktualisierungen an Datensätzen vornehmen. Mithilfe eines Bypass-Mechanismus können sie diese Änderungen vornehmen, ohne die standardmäßige Geschäftsautomatisierung auszulösen, was unbeabsichtigte Folgen haben könnte. **Benutzerdefinierte Berechtigungen**: Der moderne, skalierbare Standard zum Implementieren der Umgehungslogik sind benutzerdefinierte Berechtigungen. Diese sind älteren Methoden aus mehreren Gründen überlegen: - **Flexibilität:** Benutzerdefinierte Berechtigungen können Benutzern über Berechtigungssätze zugewiesen werden. Diese Vorgehensweise entspricht dem modernen Salesforce-Sicherheits- und -Zugriffsmodell und ermöglicht eine detaillierte und flexible Zuweisung. Eine Umgehung kann einem bestimmten Benutzer oder sogar vorübergehend mit einem bestimmten Ablaufdatum/einer bestimmten Ablaufzeit gewährt werden. - **Wartbarkeit:** Durch die Verwendung benutzerdefinierter Berechtigungen wird vermieden, dass Profile oder Benutzer hartcodiert werden. Wenn sich die Rolle eines Benutzers ändert oder ein neues Profil Umgehungszugriff benötigt, handelt es sich bei der Änderung um eine einfache Berechtigungssatzzuweisung und nicht um eine Code- oder Flow-Änderung, die eine Bereitstellung erfordert. - **Skalierbarkeit:** Benutzerdefinierte Berechtigungen bieten ein skalierbares Framework zum Verwalten von Ausnahmen in einer komplexen Benutzerbasis. Sie können Benutzern über Berechtigungssätze, Berechtigungssatzgruppen oder Profile zugewiesen werden. Ihre Zuordnung zu einem Berechtigungssatz oder Profil kann auch in Quellmetadaten dargestellt werden. **Implementierungsmuster**: Wenden Sie ein konsistentes Umgehungsmuster auf alle durch einen Datensatz ausgelösten Automatisierungen in der Organisation an. **Umgehen eines durch einen Datensatz ausgelösten Flows**: Die effizienteste Möglichkeit, einen Flow zu umgehen, besteht darin, zu verhindern, dass er überhaupt ausgeführt wird. Dies wird erreicht, indem den Eingabekriterien des Flows eine Bedingung hinzugefügt wird. - Legen Sie im Startelement des durch einen Datensatz ausgelösten Flows "Bedingungsanforderungen" auf "Formel wird ausgewertet" auf "Wahr" fest. - Integrieren Sie eine Überprüfung auf die benutzerdefinierte Berechtigung mithilfe der globalen Variablen `$Permission` in den Formelgenerator. Kombinieren Sie die Prüfung mit Ihren vorhandenen Eingabekriterien. - Formelmuster: ``` ( ) && NOT($Permission.Bypass_This_Flow) ``` - Durch dieses Muster wird sichergestellt, dass der Flow nur ausgeführt wird, wenn dem Benutzer die angegebene benutzerdefinierte Berechtigung _nicht_ zugewiesen ist. Diese Überprüfung wird durchgeführt, bevor das Flow-Interview überhaupt erstellt wird, was es zum leistungsfähigsten Ansatz macht. **Umgehen eines Apex Trigger Framework**: Integrieren Sie die Bypass-Logik in Apex direkt in das metadatengesteuerte Auslöser-Framework, um eine genaue Steuerung zu ermöglichen. - Der benutzerdefinierte Metadatentyp "`TriggerAction__mdt`" sollte ein Textfeld enthalten, beispielsweise "`BypassPermission__c`". - In der `MetadataTriggerHandler`-Klasse sollte der Code vor dem dynamischen Ausführen einer Aktion den Wert aus diesem Feld lesen. - Wenn das Feld ausgefüllt ist, verwendet der Handler die `FeatureManagement.checkPermission()`-Methode, um festzustellen, ob der aktuelle aktuelle Benutzer über die angegebene benutzerdefinierte Berechtigung verfügt. - Wenn `checkPermission()` true zurückgibt, überspringt der Handler diese spezifische Aktion und fährt mit der nächsten in der Sequenz fort. - Dieses Muster ist leistungsstark, da es sowohl eine globale Umgehung (wenn alle `TriggerAction__mdt` auf dieselbe Berechtigung verweisen) als auch eine detaillierte Umgehung pro Aktion (wenn unterschiedliche Datensätze auf unterschiedliche Berechtigungen verweisen oder einige gar keine Umgehungsberechtigung haben) ermöglicht. ### Mega-Flows im Vergleich zu mehreren Flows Es ist ein Anti-Pattern, um die gesamte Automatisierung eines Objekts in einem einzigen, massiven Mega-Flow zu konsolidieren. Die Konsolidierung in einem Flow im Vergleich zur Aufteilung der Logik in mehrere gut konditionierte Flows hat keine großen Auswirkungen auf die Leistung. Die wichtigsten Leistungssteigerungen stammen aus: - Verwenden von Flows vor dem Speichern für Feldaktualisierungen desselben Datensatzes. - Schreiben genauer Eintrittsbedingungen, um sicherzustellen, dass Flows nicht für Änderungen ausgeführt werden, die sich nicht auf ihren jeweiligen Anwendungsfall auswirken. Mit [dem Flow-Auslöser-Explorer](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer) können Sie jedem Flow für ein Objekt einen Auftragswert zuweisen, um eine sequenzielle Ausführungsreihenfolge zu gewährleisten. Flow-Auslöser-Explorer ## Ressourcen
Apex Flow Vorgänge
# Verwenden der richtigen Tools und Muster für ereignisgesteuerte Architekturen Ereignisgesteuerte Architekturen unterstützen die effiziente Produktion und Nutzung von Ereignissen, die System- oder Anwendungsstatusänderungen kommunizieren. Diese Architekturen ermöglichen flexible Verbindungen zwischen Systemen und Supportprozessen und Aktualisierungen nahezu in Echtzeit, die systemübergreifend funktionieren. Obwohl die Vorteile von ereignisgesteuerten Architekturen leicht zu erkennen sind, sind die Implementierungsdetails nicht immer so klar. Welche Funktionen müssen bei ereignisgesteuerten Architekturmustern berücksichtigt werden? Welche spezifischen Probleme lösen diese Muster? Welche besonderen Überlegungen gelten für Ihre Lösungen und welche Muster sind optimal, um sie anzugehen? ## Leitfadenübersicht In dieser Anleitung werden Muster vorgestellt, die zum Erstellen optimaler ereignisgesteuerter Architekturen bei der Arbeit mit Salesforce-Technologien verwendet werden. Darüber hinaus werden bei Salesforce verfügbare Eventing-Tools diskutiert und Tool-Empfehlungen für eine Auswahl von Anwendungsfällen bereitgestellt. Informationen zu Integrationen auf Datenebene in Salesforce finden Sie im [Data Integration Decision Guide](/docs/architect/de-de/decision-guides/guide/data-integration). ## Takeaways - **Verwenden Sie ereignisgesteuerte Architekturen für Prozesse, für die keine synchronen Antworten auf Anforderungen erforderlich sind.** Die in diesem Leitfaden beschriebenen Muster sind auf Datenkonsistenz, Skalierbarkeit und Wiederverwendung ausgelegt, wodurch die technische Verschuldung bei der Entwicklung der Anwendungslandschaft Ihrer Organisation auf ein Minimum reduziert wird. (Weitere Informationen finden Sie unter [Well-Architected – Reliability](/docs/architect/de-de/well-architected/guide/reliability.html).) - **Wenn MuleSoft oder eine andere Enterprise Service Bus-Lösung (ESB) Teil Ihrer vorhandenen Landschaft ist, verwenden Sie sie nach Möglichkeit.** Diese Lösungen wurden speziell für die Unterstützung von ereignisgesteuerten Architekturmustern entwickelt und verfügen über leistungsstarke Funktionen, mit denen Sie Integrationen in Ihrem gesamten Unternehmen wiederverwenden können. - **Verwenden Sie die Pub/Sub-API für künftige Veröffentlichungs-/Abonnementmuster, statt Ihre eigenen Ereignis-Handler mithilfe anderer APIs, einschließlich der Streaming-API, zu erstellen.** Da die Pub/Sub-API nun allgemein verfügbar ist, können Sie sie für neue Veröffentlichungs-/Abonnementmuster verwenden. Planen Sie, vorhandene Ereigniskommunikationen mit anderen Plattform-APIs wie der Streaming-API oder benutzerdefinierten Apex-Services zur Pub/Sub-API zu migrieren, sofern dies möglich ist. - **Plattformereignisse und die Datenerfassung (CDC) sind die bevorzugten Mechanismen zur Veröffentlichung von Datensatz- und Feldänderungen, die von anderen Systemen verwendet werden müssen.** Es wird davon abgeraten, PushTopic und generische Ereignisse für neue Implementierungen zu verwenden. Salesforce wird PushTopic und generische Ereignisse im Rahmen der aktuellen Funktionsfunktionen weiterhin unterstützen, plant jedoch keine weiteren Investitionen in diese Technologie. ## Produkte im Umfang
Salesforce Platform Bei der Salesforce Platform handelt es sich um eine umfassende AI-gestützte Plattform, die Mitarbeiter, autonome AI-Agenten, Unternehmensdaten und Anwendungen in einem einzigen, vertrauenswürdigen System zusammenführt, um die Produktivität und die Kundenerfahrung zu steigern. Durch die Verbindung von Customer 360-Anwendungen, Data Cloud und Slack für eine durchgängige Automatisierung kann ein "Agentenunternehmen" erstellt werden.
MuleSoft MuleSoft ist die führende Integrationsplattform von Salesforce, mit der Organisationen Anwendungen, Daten und Geräte lokal und Cloud-Umgebungen miteinander verbinden können. MuleSoft ist eine Plattform, die der IT die Plattformen bietet, um Daten systemübergreifend freizugeben, skalierbare Integrations- und Automatisierungs-Frameworks zu entwickeln und differenzierte, verbundene Erfahrungen zu schaffen – und zwar schnell.
## Entscheidungspunkte Ereignisgesteuerte Architekturen werden für Szenarien empfohlen, die Benachrichtigungen nahezu in Echtzeit erfordern, die Verarbeitungslast für Nachrichten mit hohem Volumen oder komplexe Nachrichten verteilen und Systeme wie IoT und Mobilgeräte integrieren, die Konnektivitätsresilienz durch Warteschlangen erfordern. EDAs sollten jedoch nicht für Prozesse implementiert werden, die sofortige synchrone menschliche Reaktionen erfordern, da sie für die asynchrone Ausführung konzipiert sind. Sie passen auch nicht gut, wenn sich Quelldaten so selten ändern, dass ein einfacheres Muster wie die Batchverarbeitung ausreichen würde. ### Einsatzmöglichkeiten einer ereignisgesteuerten Architektur Im Folgenden finden Sie verschiedene gängige Szenarien, die sich oft gut für eine ereignisgesteuerte Architektur eignen:
EntscheidungspunktAnleitung
Benachrichtigungen nahezu in EchtzeitEreignisgesteuerte Architekturmuster wie Veröffentlichen/Abonnieren, Fanout und Streaming funktionieren in der Regel gut in Szenarien, in denen mehrere Anwendungen nahezu in Echtzeit über Statusänderungen oder Datensatzaktualisierungen benachrichtigt werden müssen.
ParallelverarbeitungMuster wie Veröffentlichen/Abonnieren funktionieren in der Regel gut in Szenarien, in denen große Datenmengen oder hochkomplexe Nachrichten die Verarbeitungslast auf mehrere Systeme verteilen müssen.
Lesevorgänge mit hohem VolumenDie Muster "Übergebene Nachrichten" und "Warteschlange" werden häufig in Szenarien verwendet, in denen Organisationen Anstiege verzeichnen und das Volumen der produzierten Nachrichten die Fähigkeit der Abonnenten übersteigen kann, sie sofort zu verarbeiten.
Schreibvorgänge mit hohem VolumenDie Streaming- und Warteschlangenmuster funktionieren gut in vielen Szenarien, in denen Organisationen einen Anstieg der Anzahl der produzierten Nachrichten feststellen.
Senden derselben Daten an unterschiedliche SystemeWährend das Veröffentlichen/Abonnieren für Organisationen, die dieselben Daten an mehrere Systeme senden müssen, tendenziell eine recht häufige Lösung ist, können die meisten hier behandelten Muster darauf reagieren. Überprüfen Sie sie im Detail, um die beste Passform zu finden.
Häufige Einführung neuer Systeme oder GeräteDie Muster "Veröffentlichen/Abonnieren", "Streamen" und "Warteschlange" funktionieren in der Regel gut in Szenarien, in denen sich die gesamte Landschaft in einem Wandel befindet und regelmäßig neue Systeme und Geräte hinzugefügt werden. In diesem Szenario muss ein neues System oder Gerät lediglich Abonnent des Ereignis-Busses werden oder einer Warteschlange zugeordnet werden, um Nachrichten zu empfangen, statt eine benutzerdefinierte Punkt-zu-Punkt-Integration erforderlich zu machen.
IoT-GeräteDa IoT-Geräte in der Regel häufige Aktualisierungen bereitstellen und in einigen Szenarien auch eine Welle von Nachrichten generieren können, funktionieren die Streaming- und Warteschlangenmuster in der Regel gut, wenn sie in eine IT-Landschaft integriert werden.
Mobilgeräte und -systeme im Offline-ModusMobilgeräte, die in Bereichen mit minderwertigem oder nicht vorhandenem Internetzugang arbeiten müssen, oder Systeme, die zum Zeitpunkt der Nachrichtenzustellung offline sein können, profitieren vom Warteschlangenmuster, mit dem sie eine Verbindung zu ihren Warteschlangen herstellen und alle relevanten Nachrichten abrufen können, sobald sie wieder online sind.
Die meisten großen Organisationen verfügen über komplexe IT-Landschaften mit einer Kombination aus Systemen mit unterschiedlichen Funktionen. Es ist möglich oder wahrscheinlich, dass Ihre Organisation über veraltete Systeme verfügt, die keine ereignisgesteuerten Integrationen unterstützen. Möglicherweise gibt es auch Anwendungsfälle, in denen ereignisgesteuerte Integrationen keinen Sinn ergeben, selbst wenn sie von den Systemen unterstützt werden (z. B. SFTP-Dateiübertragungen von Drittanbietern). Wenn Sie einen Schritt zurückgehen und die IT-Landschaft Ihrer Organisation als Ganzes betrachten, werden Sie wahrscheinlich – genau wie bei anderen architektonischen Lösungen – eine Mischung aus Mustern verwenden, um verschiedene Szenarien zu unterstützen. Wenn Sie sich entscheiden, den ereignisgesteuerten Ansatz für Integrationen zu bevorzugen, sollten Sie ihn als ein anderes Tool in Ihrer Toolbox betrachten. Sie kann und sollte in den richtigen Szenarien verwendet werden, aber sie ist nicht ein Ansatz, der jedem System auferlegt werden muss. Durch die Entwicklung einer umfassenden Integrationsstrategie können Sie bestimmen, wann die in diesem Leitfaden beschriebenen Muster geeignet sein können, aber nicht. ### Wann keine ereignisgesteuerte Architektur verwendet werden sollte In vielen Szenarien sind ereignisgesteuerte Architekturen erforderlich. In einigen Szenarien funktionieren ereignisgesteuerte Architekturen auch dann, wenn sie nicht am besten passen. In einigen Szenarien sollten ereignisgesteuerte Architekturen jedoch einfach nicht verwendet werden. Im Folgenden finden Sie einige Fragen zu Entscheidungspunkten, mit denen Sie diese Szenarien identifizieren können:
EntscheidungspunktAnleitung/Fragen
GeschäftsanforderungenBesteht ein echter Geschäftsbedarf für eine der Funktionen, die im Abschnitt [When-to-use an event-driven-architecture] (#when-to-use-an-event-driven-architecture) beschrieben sind?
Technische AnforderungenPasst die Integration, die Sie entwerfen, offensichtlich zu einem anderen Muster, beispielsweise Datenvirtualisierung, Batch oder Anforderung/Antwort? Mit anderen Worten, versuchen Sie, einen Vierkantzapfen in ein rundes Loch zu passen?
Prozesse, bei denen Menschen auf Antworten warten müssenJede Integration, bei der ein Mensch auf eine Antwort vom Zielsystem wartet, eignet sich nicht für ereignisgesteuerte Architekturen, da sie für die asynchrone Ausführung konzipiert sind und keine Antwortzeit garantieren können. Überlegen Sie, ob solche Prozesse für Ihre Organisation optimal sind, bevor Sie technische Lösungen implementieren. Weitere Informationen finden Sie unter [Well-Architected – Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html).
Häufig geänderte QuelldatenWenn sich die Daten in Ihrem Quellsystem so selten ändern, dass regelmäßige Aktualisierungen ausreichend sind, können Sie Ihre Architektur wahrscheinlich vereinfachen, indem Sie [batch patterns] (https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) anstelle von ereignisgesteuerten Mustern verwenden.
ImplementierungsanforderungenUnterstützen die meisten an Ihrer Lösung beteiligten Systeme ereignisgesteuerte Architekturen? Was wäre erforderlich, um ereignisgesteuerte Architekturen mit Systemen zu verwenden, die sie nicht unterstützen (z. B. Upgrades, Anpassungen oder Middleware)? Welcher Aufwand wäre erforderlich, um diese Anforderungen zu erfüllen?
Messaging-StrukturstabilitätWie oft müssen sich Ihre Nachrichtenstrukturen ändern? Welche Systeme sind von einer solchen Änderung betroffen und wie sieht der Sanierungsprozess aus?
OrganisationsführungVerfügen Sie über eine Governance-Struktur, um sicherzustellen, dass alle Beteiligten über Änderungen an Nachrichtenstrukturen, Auslösern und anderen architektur- und prozessbezogenen Entscheidungen informiert sind und Einfluss darauf haben?
Erforderliche FertigkeitenVerfügen Ihre Mitarbeiter über Erfahrung mit ereignisgesteuerten Architekturen und wissen sie, wie sie sie unterstützen können?
## Anwendungsfälle Es gibt eine Vielzahl von ereignisgesteuerten Architekturmustern. Einige davon sind allgemeine Muster, die in Anwendungsfällen angewendet werden können, die keine besonderen Anforderungen außerhalb der Ereignissteuerung aufweisen. Entsprechende Informationen finden Sie unter [Wohlüberlegt – Zuverlässigkeit](/docs/architect/de-de/well-architected/guide/reliability.html). Andere Muster sind auf die hier diskutierten spezifischen Anwendungsfälle anwendbar, beispielsweise Integrationen mit großen Datenmengen oder Szenarien, die eine längere Nachrichtenaufbewahrung erfordern. ### Muster auf einen Blick In der folgenden Tabelle werden die Attribute der in diesem Dokument beschriebenen Muster verglichen. Verwenden Sie sie als Schnellreferenz, wenn Sie potenzielle Muster für einen bestimmten Anwendungsfall identifizieren müssen.
MusterNahezu in EchtzeitKopie einer eindeutigen NachrichtGarantiezustellungReduzieren der NachrichtengrößeUmwandeln von Daten
Veröffentlichen/Abonnieren✓✓✓
Fanout✓✓✓
Übergebene Nachrichten✓✓✓✓
Streaming✓✓✓
Warteschlange✓✓✓
### Tools für die ereignisgesteuerte Architektur Salesforce bietet mehrere Tools, mit denen Sie Ihre ereignisgesteuerten Anwendungsfälle bewältigen können. Diese Tabelle enthält eine allgemeine Übersicht über die verfügbaren Tools.
ToolBeschreibungErforderliche Fertigkeiten
MuleSoftBeliebige PunktplattformPlattform, die die Datenintegration mithilfe von API-Ebenen ermöglicht.Pro-Code
Salesforce Pub/Sub-KonnektorKonnektor für die Pub/Sub-API, der eine einzige Oberfläche für die Veröffentlichung und Abonnierung von Plattformereignissen, Ereignissen der Echtzeit-Ereignisüberwachung und Ereignissen der Datenerfassung von Änderungen bietet.Pro-Code
MuleSoft Anypoint JMS ConnectorKonnektor, der das Senden und Empfangen von Nachrichten an Warteschlangen und Themen für jeden Nachrichtenservice ermöglicht, der die Java Message Service-Spezifikation (JMS) implementiert.Pro-Code
MuleSoft Anypoint Apache Kafka ConnectorKonnektor zum Verschieben von Daten zwischen Apache Kafka und Unternehmensanwendungen und -services.Pro-Code
MuleSoft Anypoint Solace-KonnektorKonnektor für Solace PubSub+-Ereignisbroker mit nativer API-Integration mithilfe des JCSMP Java-SDKPro-Code
MuleSoft Anypoint MQ-KonnektorEin mandantenübergreifender Cloud-Messaging-Service, mit dem Kunden erweiterte asynchrone Nachrichten zwischen ihren Anwendungen ausführen können.Pro-Code
MuleSoft Anypoint-MQTT-KonnektorEine MuleSoft-Erweiterung, die mit dem Protokoll MQTT (Message Queuing Telemetry Transport) v3.x kompatibel ist.Pro-Code
MuleSoft Anypoint AMQP-KonnektorEin Konnektor, mit dem Ihre Anwendung Nachrichten mithilfe eines AMQP 0.9.1-kompatiblen Brokers veröffentlichen und konsumieren kann.Pro-Code
MuleSoft Anypoint Event-Driven (ASync)-APIBranchenunabhängige Sprache, die die Veröffentlichung von ereignisgesteuerten APIs unterstützt, indem sie in Ereignis-, Kanal- und Transportebenen unterteilt werden.Pro-Code
MuleSoft Anypoint MQMessaging-Service für mehrere Mandanten, mit dem Kunden erweiterte asynchrone Nachrichten zwischen ihren Anwendungen ausführen können.Pro-Code
MuleSoft Anypoint-DatenströmeDas in MuleSoft Anypoint verfügbare Framework zum Veröffentlichen und Abonnieren von Streaming-Daten.Pro-Code
Salesforce PlatformApache Kafka auf HerokuHeroku-Add-On, das Apache Kafka als Service mit vollständiger Plattformintegration in die Heroku-Plattform bereitstellt.Pro-Code
Datenerfassung ändernÄnderungsereignisprotokoll, das Änderungen an Salesforce-Datensätzen veröffentlicht. Zu den Änderungen zählen die Erstellung eines neuen Datensatzes, Aktualisierungen an einem vorhandenen Datensatz, das Löschen eines Datensatzes und das Rückgängigmachen der Löschung eines Datensatzes.Low-Code zu Pro-Code
Ausgehende NachrichtenAktionen, die XML-Nachrichten an externe Endpunkte senden, wenn Feldwerte in Salesforce aktualisiert werden.Low-Code
PlattformereignisseSichere und skalierbare Nachrichten, die benutzerdefinierte Ereignisdaten enthalten.Low-Code zu Pro-Code
Pub/Sub APIAPI, die Abonnements für Plattformereignisse, Ereignisse der Datenerfassung ändern und/oder Ereignisse der Echtzeit-Ereignisüberwachung aktiviert.Pro-Code
EreignisweiterleitungenErmöglicht die Übertragung von Plattformereignissen und Ereignissen der Datenerfassung von Salesforce an Amazon EventBridge. Beachten Sie, dass Ereignisweiterleitungen nur eine Verbindung mit AWS Eventbridge herstellen.Low-Code
### Veröffentlichen/Abonnieren Wenn ein wichtiger Datensatz den Status in einer Kernanwendung ändert – beispielsweise wird der Status eines Auftrags von "Verarbeitung" zu "Versandt" geändert –, benötigen mehrere andere Systeme wahrscheinlich eine Benachrichtigung nahezu in Echtzeit, um ihre jeweiligen Aufgaben ausführen zu können. Ein spezifischer Geschäftsbedarf ergibt sich, wenn das Volumen dieser Änderungen hoch ist und die Nachrichten komplex sind, was herkömmliche Punkt-zu-Punkt-Integrationen aufwändig und schwierig zu verwalten macht. Das Einrichten empfindlicher, benutzerdefinierter Verbindungen für jede einzelne abhängige Anwendung führt zu technischen Schulden und verhindert die schnelle Skalierbarkeit der Organisation. Zum Verwalten dieser häufigen Datensynchronisierungen ist ein zuverlässiger Integrationsansatz erforderlich, ohne das Quellsystem direkt mit jedem verbrauchenden System zu verknüpfen. #### Das Veröffentlichungs-/Abonnementmuster Das folgende Diagramm zeigt ein typisches Veröffentlichungs-/Abonnementmuster, bei dem mehrere Publisher und Abonnenten Daten über einen Ereignis-Bus freigeben. Dieses grundlegende Muster bildet die Grundlage für die spezifischeren Muster, die im Rest dieses Handbuchs zu finden sind. Einige wichtige Merkmale dieses Musters sind: - Es besteht keine direkte Verbindung zwischen Publishern und Abonnenten. Publisher senden Nachrichten einfach an einen Ereignis-Bus, der sie an jedes andere System sendet, das sie anhören möchte. - Das gleiche System kann sowohl ein Publisher als auch ein Abonnent sein. - Systeme können mehrere Ereignistypen veröffentlichen oder abonnieren. - Wie bei allen Mustern in dieser Anleitung fällt das Veröffentlichungs-/Abonnementmuster in eine allgemeine Integrationsmusterkategorie, die als Remote Procedure Invocation (RPI) bezeichnet wird oder einfach ["fire and forget".](/docs/architect/de-de/fundamentals/guide/integration-patterns#remote-prozessaufruf--fire-and-forget) Dieses Diagramm der Ebene 2 zeigt ein Beispiel für das Veröffentlichungs-/Abonnementmuster, das mehrere Publisher, mehrere Abonnenten und mehrere Ereignisse umfasst, die über Kanäle in einem Ereignis-Bus bereitgestellt werden. In diesem Muster kann dasselbe System sowohl ein Publisher als auch ein Abonnent sein und ein System kann mehrere Ereignisse abonnieren. #### Für das Veröffentlichungs-/Abonnementmuster relevante Tools
Ereignis-Flow und -VerhaltenÜberlegungen zur Nutzlast
Verfügbare ToolsErforderliche FertigkeitenVeröffentlichen überAbonnieren überWiederholungszeitraumNutzlaststrukturNutzlastobergrenzen
MuleSoftBeliebige PunktplattformPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce Pub/Sub-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint JMS ConnectorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint Apache Kafka ConnectorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint Solace-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint MQ-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint-MQTT-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint AMQP-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint Event-Driven (ASync)-APIPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint MQPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce PlatformApache Kafka auf HerokuPro-CodeAPIs, Datensatzänderungen in Heroku PostgresN/A1-6 WochenVom Benutzer definiertVom Benutzer definiert
Datenerfassung ändernLow-Code zu Pro-CodeDatensatzänderungenApex, APIs, Lightning Web Components (LWC)3 TageVordefiniert1 MB
Ausgehende Nachrichten*Low-CodeFlow- und Workflow-RegelnN/A24 StundenVom Benutzer definiert100 Benachrichtigungen pro Nachricht
PlattformereignisseLow-Code zu Pro-CodeAPIs, Apex, FlowApex, APIs, Flow, LWC3 TageVom Benutzer definiert1 MB
Pub/Sub APIPro-CodePub/Sub API oder APIs, Apex, FlowPub/Sub-API3 TageVom Benutzer definiert1 MB
Ereignisweiterleitungen**Low-CodePlattformereignisse, Datenerfassung ändernAPI3 TageVom Benutzer definiert1 MB
* Salesforce wird ausgehende Nachrichten weiterhin im Rahmen der aktuellen Funktionsfunktionen unterstützen, plant jedoch keine weiteren Investitionen in diese Technologie. **Ereignisweiterleitungen stellen nur eine Verbindung mit AWS Eventbridge her
### Fanout Wenn eine Organisation sofortige Aktualisierungen an einer großen Anzahl von Client-Anwendungen senden muss, beispielsweise Push-Benachrichtigungen oder SMS-Nachrichten an Mobilgeräte, wird der herkömmliche Prozess der Erstellung eindeutiger Übertragungen für jeden einzelnen Empfänger schnell zu einem Engpass bei der Skalierbarkeit. Der Kerngeschäftsbedarf besteht in diesem Fall in der schnellen und leistungsstarken Verteilung einer einzelnen Information wie einer Accountbenachrichtigung oder einer wichtigen Serviceänderungsanzeige an zahlreiche Endpunktanwendungen gleichzeitig. Ein optimierter Ansatz, um diese Anforderung zu erfüllen, besteht darin, alle Nachrichten durch eine einzelne Warteschlange weiterzuleiten, die als zentraler Punkt der Ereignisinformationen für alle verbrauchenden Systeme fungiert. Dieser Ansatz verbessert die Leistung, da viele separate Nachrichtenkopien nicht mehr verwaltet werden müssen. #### Das Fanout-Muster Mit dem Fanout-Muster werden Nachrichten über eine einzige Nachrichtenwarteschlange an ein oder mehrere Ziele (d. h. an hörende Clients oder Abonnenten) zugestellt. Abonnenten rufen dieselbe Nachricht aus der Warteschlange ab und nicht ihre eigene eindeutige Kopie. (Beachten Sie, dass dies zwar die Leistung verbessert, es jedoch auch erschweren kann, zu überprüfen, ob ein bestimmter Abonnent die Nachricht erhalten hat.) Dieses Dokumentations- und Implementierungsdiagramm der Ebene 3 zeigt ein Beispiel für das Fanout-Muster. Es zeigt ein Ereignis, 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 Abonnentensystem verfügt über mehrere Services, die dasselbe Ereignis aus der Nachrichtenwarteschlange empfangen. #### Für das Fanout-Muster relevante Tools
Ereignis-Flow und -VerhaltenÜberlegungen zur Nutzlast
Verfügbare ToolsErforderliche FertigkeitenVeröffentlichen überAbonnieren überWiederholungszeitraumNutzlaststrukturNutzlastobergrenzen
MuleSoftMuleSoft Anypoint JMS ConnectorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce Pub/Sub-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint Apache Kafka ConnectorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint Solace-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint MQ-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint-MQTT-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint AMQP-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint MQPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce PlatformApache Kafka auf HerokuPro-CodeAPIs, Datensatzänderungen in Heroku PostgresN/A1-6 WochenVom Benutzer definiertVom Benutzer definiert
Datenerfassung ändernLow-Code zu Pro-CodeDatensatzänderungenApex, APIs, Lightning Web Components (LWC)3 TageVordefiniert1 MB
PlattformereignisseLow-Code zu Pro-CodeAPIs, Apex, FlowApex, APIs, Flow, LWC3 TageVom Benutzer definiert1 MB
Pub/Sub APIPro-CodePub/Sub API oder Apex, APIs, FlowPub/Sub-API3 TageVom Benutzer definiert1 MB
Ereignisweiterleitungen*Low-CodePlattformereignisse, Datenerfassung ändernAPI3 TageVom Benutzer definiert1 MB
* Ereignisweiterleitungen senden nur Daten an AWS Eventbridge
### Übergebene Nachrichten Einige Ereignisszenarien zeichnen sich durch einen erheblichen Nachrichtenvolumenzustrom aus, der die Kapazität von Synchronisierungs- und Transformationsprozessen zu überfordern droht, oder durch eine komplexe Logik aus mehreren Schritten, die zum Verarbeiten und Umwandeln von Ereignisdaten erforderlich ist. Einige Beispiele: - **Saisonale Volumenspitzen:** Es kann zu Volumenspitzen kommen, die Online-Händler erleben, wenn eine Auswahl ihrer Produkte "in der Saison" ist. Wenn viele Kunden gleichzeitig Käufe tätigen, kann die Anzahl der generierten Ereignisse vorübergehend die Kapazität der Synchronisierungs- und Transformationsprozesse überschreiten. Weitere Informationen finden Sie unter [Well-Architected – Reliability](/docs/architect/de-de/well-architected/guide/reliability.html#scalability-and-capacity-planning). - **Kundenvorgangs- oder Anspruchsverwaltung:** Bei servicebasierten Unternehmen kann es bei Ausfällen zu einem Anstieg der Anzahl der Kundenvorgänge oder Ansprüche kommen. - **Komplexe Datentransformationen:** Organisationen, die komplexe Logik zum Umwandeln von Nachrichten benötigen, sind oft besorgt darüber, dass Ereignisse schneller generiert werden, als sie umgewandelt werden können. #### Das Muster für übergebene Nachrichten Dieses Muster löst die Herausforderung, dass Nachrichten schneller generiert werden, als sie umgewandelt werden können. Durch die Integration einer Streaming-Nachrichtenplattform und die Segmentierung der Nachrichtenverarbeitungslogik in dedizierte Komponenten wird sichergestellt, dass große Mengen an Nachrichten und erforderliche Datenmanipulationen zuverlässig verarbeitet werden können. Das Muster "Übergebene Nachrichten" funktioniert, indem die Verarbeitungslogik für Nachrichten in mehrere Komponenten unterteilt wird: - Eine Komponente übernimmt die Nachrichtenweiterleitung, bestimmt erforderliche Transformationen und das endgültige Ziel. - Ein separater Satz von Komponenten verarbeitet verschiedene Ebenen der Nachrichtentransformation (z. B. Feldzuordnungen, Objektbeziehungen usw.). - Die letzte Komponente schreibt die letzte geänderte Nachricht aus. In diesem Dokumentations- und Implementierungsdiagramm der Ebene 3 ist ein Beispiel für einen Prozess-Flow für das übergebene Nachrichtenmuster dargestellt, der einen Publisher, einen Abonnenten und eine Nachricht enthält. Die Nachricht ist in mehrere Teile unterteilt, die einzeln umgewandelt und dann vor dem Senden an den Abonnenten erneut zusammengesetzt werden. #### Für das Muster der übergebenen Nachrichten relevante Tools
Ereignis-Flow und -VerhaltenÜberlegungen zur Nutzlast
Verfügbare ToolsErforderliche FertigkeitenVeröffentlichen überAbonnieren überWiederholungszeitraumNutzlaststrukturNutzlastobergrenzen
MuleSoftMuleSoft Anypoint Apache Kafka ConnectorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce Pub/Sub-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce PlatformApache Kafka auf HerokuPro-CodeAPIs, Datensatzänderungen in Heroku PostgresN/A1-6 WochenVom Benutzer definiertVom Benutzer definiert
Datenerfassung ändernLow-Code zu Pro-CodeDatensatzänderungenApex, APIs, Lightning Web Components (LWC)3 TageVordefiniert1 MB
PlattformereignisseLow-Code zu Pro-CodeAPIs, Apex, FlowApex, APIs, Flow, LWC3 TageVom Benutzer definiert1 MB
Pub/Sub APIPro-CodePub/Sub API oder APIs, Apex FlowPub/Sub-API3 TageVom Benutzer definiert1 MB
Ereignisweiterleitungen*Low-CodePlattformereignisse, Datenerfassung ändernAPI3 TageVom Benutzer definiert1 MB
* Ereignisweiterleitungen senden nur Daten an AWS Eventbridge
### Streaming Einige Produzenten generieren einen kontinuierlichen Stream von Ereignissen. Ein häufiges Beispiel ist das Medien-Streaming, bei dem Benutzerinteraktionen berücksichtigt werden, die natürlicherweise als diskrete Ereignisse auftreten. Mehrere Systeme müssen gleichzeitig auf dasselbe Benutzerverhalten reagieren, ohne die zentrale Streaming-Erfahrung zu blockieren. Beachten Sie die Ereignisse für eine Musik-Streaming-Plattform. Dazu zählen beispielsweise: - Verfolgen von gestarteten/angehaltenen/übersprungenen Ereignissen - Abhören von Sitzungsereignissen mit Zeitstempeln - Wiedergabelistenerstellung/-änderungsereignisse - Social-Sharing-Ereignisse - Herunterladen zum Offline-Hören #### Das Streaming-Muster Im Streaming-Muster greifen Abonnenten auf jeden Ereignisstrom zu und verarbeiten die Ereignisse in der genauen Reihenfolge, in der sie empfangen werden. An jeden Abonnenten werden eindeutige Kopien jedes Nachrichtenstroms gesendet, wodurch teilnehmerspezifische Inhalte bereitgestellt und identifiziert werden können, welche Abonnenten welche Streams erhalten. Dieses Dokumentations- und Implementierungsdiagramm der Ebene 3 zeigt ein Beispiel für das Streaming-Muster, das einen Stream der veröffentlichten Ereignisse darstellt. Abonnenten, die die Streams abhören, erhalten sie und verarbeiten sie entsprechend. #### Für das Streaming-Muster relevante Tools
Ereignis-Flow und -VerhaltenÜberlegungen zur Nutzlast
Verfügbare ToolsErforderliche FertigkeitenVeröffentlichen überAbonnieren überWiederholungszeitraumNutzlaststrukturNutzlastobergrenzen
MuleSoftMuleSoft Anypoint-DatenströmePro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce Pub/Sub-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint Apache Kafka ConnectorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce PlatformApache Kafka auf HerokuPro-CodeAPIs, Datensatzänderungen in Heroku PostgresN/A1-6 WochenVom Benutzer definiertVom Benutzer definiert
Pub/Sub APIPro-CodePub/Sub API oder APIs, Apex FlowPub/Sub-API3 TageVom Benutzer definiert1 MB
#### Gestreamte Ereignisauftragsverwaltung Damit ein Stream sinnvoll ist, müssen alle seine Ereignisse und die zugehörigen Nachrichten in der richtigen Reihenfolge vorliegen. Wenn Sie die Daten in einem Stream aus unterschiedlichen Systemen beziehen, müssen Sie zusätzliche Anordnungslogik als Teil des Designprozesses integrieren. ### Warteschlange Warteschlangenanwendungsfälle sind allgegenwärtig. Beispiele: - **Internetverbindung geringer Qualität:** Außendienstorganisationen oder andere Organisationen, in denen Teams mit Mobilgeräten in Bereichen mit minderwertigem oder zeitweiligem Internetzugang arbeiten müssen, profitieren von der Warteschlange, da die Anwendungen auf diesen Geräten eine Verbindung zu ihren Warteschlangen herstellen und alle relevanten Nachrichten abrufen können, wenn die Verbindung wiederhergestellt ist. - **Nachrichtenpufferung:** Wenn das Nachrichtenvolumen gelegentlich die Verarbeitungskapazität eines Abonnenten überschreitet und eine erhöhte Latenz keine zusätzlichen Probleme verursacht, können Warteschlangen ein Puffer sein, um überschüssige Nachrichten zu speichern und Datenverluste zu verhindern. - **Transportmanagement:** Logistikorganisationen, die ihre Flotten überwachen müssen, können dieses Muster verwenden, um die Routen anzuzeigen, die jedes Fahrzeug nahezu in Echtzeit fährt, und sicherzustellen, dass die Fahrer so effizient wie möglich sind. - **IoT-Geräte:** Hersteller verwenden häufig Systeme, die schnelle Datenströme generieren, und diese können sich nachgelagert auf zusätzliche Systeme auswirken. Dieses Muster kann verwendet werden, um Sequenzen von Ereignissen zu identifizieren, die ein Eingreifen des Menschen erfordern, bevor katastrophale Fehler auftreten, die sich über mehrere Systeme erstrecken. #### Das Warteschlangenmuster Im Warteschlangenmuster senden Produzenten Nachrichten an Warteschlangen, die die Nachrichten so lange speichern, bis sie von Abonnenten abgerufen werden. Die meisten Nachrichtenwarteschlangen folgen der FIFO-Anordnung (First-in, First-out) und löschen jede Nachricht, nachdem sie abgerufen wurde. Jeder Abonnent verfügt über eine eindeutige Warteschlange, die zusätzliche Setup-Schritte erfordert, jedoch die Zustellung garantiert und identifiziert, welche Abonnenten welche Nachrichten erhalten haben. Dieses Dokumentations- und Implementierungsdiagramm der Ebene 3 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. #### Für das Warteschlangenmuster relevante Tools
Ereignis-Flow und -VerhaltenÜberlegungen zur Nutzlast
Verfügbare ToolsErforderliche FertigkeitenVeröffentlichen überAbonnieren überWiederholungszeitraumNutzlaststrukturNutzlastobergrenzen
MuleSoftMuleSoft Anypoint MQPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce Pub/Sub-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint Apache Kafka ConnectorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint MQ-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint-MQTT-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
MuleSoft Anypoint AMQP-KonnektorPro-CodeAPIsAPIsWie konfiguriertVom Benutzer definiertKeine
Salesforce PlatformApache Kafka auf HerokuPro-CodeAPIs, Datensatzänderungen in Heroku PostgresN/A1-6 WochenVom Benutzer definiertVom Benutzer definiert
Datenerfassung ändernLow-Code zu Pro-CodeDatensatzänderungenApex, APIs, Lightning Web Components (LWC)3 TageVordefiniert1 MB
PlattformereignisseLow-Code zu Pro-CodeAPIs, Apex, FlowApex, APIs, Flow, LWC3 TageVom Benutzer definiert1 MB
Pub/Sub APIPro-CodePub/Sub API oder APIs, Apex, FlowPub/Sub-API3 TageVom Benutzer definiert1 MB
Ereignisweiterleitungen*Low-CodePlattformereignisse, Datenerfassung ändernAPI3 TageVom Benutzer definiert1 MB
* Ereignisweiterleitungen senden nur Daten an AWS Eventbridge
#### Speicher- und Speicherverwaltung Aufgrund der Asynchronität des Warteschlangenmusters kann es zu einer längeren Verzögerung zwischen dem Hinzufügen einer Nachricht zu einer Warteschlange und dem Abruf dieser Nachricht kommen. Warteschlangen benötigen Speicherplatz oder Speicherplatz, um ihre Nachrichten speichern zu können. Daher können sie nicht unbegrenzt wachsen. Das bedeutet, dass ein Abonnent, der auf unbestimmte Zeit offline ist, einen Fehler verursachen kann, wenn sich genügend Nachrichten in der Warteschlange ansammeln. Die Nachrichtenpufferung kann den gleichen Effekt haben, wenn die Verarbeitungszeiten der Abonnenten zu lang werden, was dazu führt, dass sich große Mengen an Nachrichten in ihren Warteschlangen ansammeln. Führen Sie eine gründliche Analyse des Speicherbedarfs für alle Nachrichtenwarteschlangen durch und entwerfen Sie bei Bedarf Prozesse, die Warteschlangen bereinigen und deaktivieren, wenn Nachrichten nicht innerhalb einer festgelegten Zeit abgerufen werden oder wenn sie ein vorbestimmtes Volumen erreichen. ## Nicht funktionale Überlegungen Zusätzlich zu den in den vorherigen Abschnitten aufgeführten funktionalen Überlegungen gibt es auch nicht funktionale Überlegungen, die bei Ihrer Entscheidung berücksichtigt werden sollten. ### Migration von Punkt-zu-Punkt-Integrationen Selbst wenn Sie vollkommen davon überzeugt sind, dass eine ereignisgesteuerte Architektur für Ihre Organisation geeignet ist, beginnen Sie möglicherweise mit einer Landschaft, die bereits eine große Anzahl von Punkt-zu-Punkt-Integrationen aufweist. Es kann schwierig sein, Fördermittel für ein Projekt zu erhalten, um alle Ihre Integrationen auf einmal zu ersetzen, und es kann nicht einmal möglich sein, eine ereignisgesteuerte Architektur direkt mit einigen alten Systemen zu verwenden. In diesen Szenarien können Sie die Migration zu einer locker gekoppelten Architektur schrittweise vornehmen, indem Sie zunächst die geschäftskritischsten Anwendungen konvertieren und dann andere Systeme konvertieren, wenn sie in künftigen Projekten aktualisiert oder ersetzt werden. Dieser Ansatz erleichtert das Hinzufügen neuer Anwendungen zum Ereignis-Bus und ermöglicht es Ihrer gesamten IT-Landschaft, skalierbar und widerstandsfähig zu bleiben, da Systeme im Laufe der Zeit immer mehr hinzugefügt werden. ### Kompromisse in lose gekoppelten Systemen Als Architekten wissen wir, dass jede Architektur Kompromisse mit sich bringt. Eine ereignisgesteuerte Architektur ist keine Ausnahme. Obwohl eine Landschaft voller lose gekoppelter Systeme hochgradig skalierbar und widerstandsfähig ist, gibt es auch einige Kompromisse zu beachten: - **Gesamtintegrationsstrategie:** Unabhängig von den Tools und Mustern, für die Sie sich entscheiden, ist es wichtig, zunächst eine Strategie für die gemeinsame Nutzung von Daten in den verschiedenen Systemen Ihrer Organisation zu erstellen. Diese Strategie sollte die Ziele Ihrer Organisation für ihre Daten, die Art und Weise, wie Daten freigegeben und Muster verwendet werden können, sowie Datenquellen, Ziele, Strukturen und Inhaberschafts- und Zugriffsanforderungen enthalten. - **Unterstützung für ältere Systeme:** Ihre Organisation verfügt möglicherweise über veraltete Systeme, die einfach keine ereignisgesteuerten Architekturmuster unterstützen. Auch wenn es möglich ist, Übergangslösungen zu erstellen (beispielsweise mit einem Prozess, der als Durchleitung fungiert, indem Ereignisse abonniert und die Ausgabe dann über eine andere Datenübertragung an das Zielsystem gesendet wird), sollten Sie in diesem Fall möglicherweise andere Integrationsmethoden in Betracht ziehen. - **Strukturänderungen an Nachrichten:** Sobald die ursprüngliche Nachrichtenstruktur definiert und zwischen Herausgebern und Abonnenten vereinbart wurde, kann es schwierig sein, sie zu ändern, insbesondere wenn die Abonnenten extern sind. Es gibt mehrere Möglichkeiten, dieses Problem zu beheben. Sie können versionierte Endpunkte verwenden. Stellen Sie jedoch sicher, dass Sie für jede Version einen klaren Lebenszyklus definieren und kommunizieren, damit Ihre Entwickler nicht zu viele Versionen gleichzeitig pflegen müssen. Wenn Apache Kafka in Heroku Teil Ihrer Landschaft ist, können Sie auch eine Schemaregistrierung oder ein ähnliches Tool in Betracht ziehen. Stellen Sie jedoch sicher, dass es auch von den anderen Systemen in Ihrer Landschaft unterstützt wird (und verwendet wird). - **Mangelnde Sichtbarkeit zwischen Publishern und Abonnenten:** In den meisten ereignisgesteuerten Architekturmustern ist den Herausgebern der Status ihrer Abonnenten nicht bekannt. Wenn ein Publisher also eine wichtige Nachricht sendet, während alle Abonnenten offline sind, wird die Nachricht möglicherweise nie zugestellt. Sie können dieses Problem beheben, indem Sie die Funktionen für die erneute Wiedergabe nutzen oder redundante Abonnenten hinzufügen, die auf separaten Servern für alle wichtigen Nachrichten ausgeführt werden. - **Leistungsengpässe:** Wenn eine ereignisgesteuerte Architektur skaliert wird, kann der Ereignis-Bus zu einem Engpass für die Nachrichtenzustellung werden, wenn er überfordert ist, da zu viele Publisher versuchen, zu vielen Abonnenten gleichzeitig Nachrichten zu senden. Sie können dies beheben, indem Sie den dem Ereignis-Bus zugewiesenen Speicher und die Verarbeitungsressourcen erhöhen oder mehrere Ereignis-Busse verwenden, um verschiedene Nachrichtentypen parallel zu verarbeiten. ## Verwandte bewährte Vorgehensweisen Beachten Sie zusätzlich zu den bereits bereitgestellten Anleitungen auch die folgenden bewährten Vorgehensweisen. ### Implementieren von ereignisgesteuerten Architekturen Bevor Sie eine ereignisgesteuerte Architektur implementieren, sollten Sie überlegen, ob Sie überhaupt eine Architektur verwenden müssen. Im vorherigen Abschnitt werden allgemeine Geschäftsszenarien beschrieben, die für jedes ereignisgesteuerte Architekturmuster gut geeignet sind. Weitere Informationen finden Sie unter [Well-Architected – Reliability](/docs/architect/de-de/well-architected/guide/reliability.html) (Wohlüberlegt – Zuverlässigkeit). Lesen Sie die Herausforderungen, die beim Implementieren von ereignisgesteuerten Architekturen zu berücksichtigen sind, um zu ermitteln, ob die Muster, die Sie im Kopf haben, für Ihre spezifischen Anwendungsfälle am besten geeignet sind. Beachten Sie, dass die meisten der in diesem Handbuch behandelten Szenarien Integrationen beinhalten. Ereignisgesteuerte Architekturen können jedoch auch verwendet werden, um Nachrichten innerhalb einer einzelnen Salesforce-Organisation zu senden, beispielsweise mithilfe von Plattformereignissen. Beachten Sie beim Entwerfen von Prozessen, die Plattformereignisse als internes Messaging-System verwenden, alle anwendbaren [Ereigniszuteilungsobergrenzen](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm). ### Vermeiden von Antimustern Anti-Patterns in ereignisgesteuerten Architekturen stammen häufig aus der Verwendung von Ereignissen als Übergangslösung für die interne Kommunikation in einer Salesforce-Organisation. Allgemeine Anti-Patterns sind: - **Veröffentlichen von Ereignissen aus Apex-Auslösern, die demselben Ereignisobjekt zugeordnet sind:** Dies führt zu einer unendlichen Auslöseschleife. - **Veröffentlichung von Ereignissen aus Apex vor Abschluss einer DML-Transaktion:** Wenn eine Transaktion fehlschlägt und zurückgesetzt wird, werden alle veröffentlichten Ereignisse, die das Verhalten "Sofort veröffentlichen" aufweisen, nicht in das Wiederherstellungsverhalten einbezogen. - **Veröffentlichen von Ereignissen in Flow zur Orchestrierung der nachfolgenden Automatisierung:** Die beste Möglichkeit, Logik über mehrere Automatisierungen hinweg zu koordinieren, besteht darin, [Subflows](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm) oder [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm) zu verwenden. - **Erstellen von Laufzeitabhängigkeiten:** Veröffentlichen Sie keine Ereignisse, um die Kommunikation zwischen Paketen zu erleichtern, ohne die richtigen [Schritte](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8) zum Beseitigen von Laufzeitabhängigkeiten zu ergreifen. - **Unnötig große Nutzlasten:** Beim Senden von Anforderungen ist es am besten, möglichst wenige Daten in der Nutzlast zu senden und zu empfangen. Jede Aktion eines Benutzers kann potenziell zu mehreren Anforderungen führen. Es ist wichtig, dass diese effizient verarbeitet werden. Das Senden von mehr Daten als erforderlich kann zu einem langsamen Transport und einer längeren Verarbeitungszeit beitragen. - **Unselektive Verarbeitung von Anwendungsereignissen:** Wenn mehrere Komponenten auf ein Anwendungsereignis hören, sollten Entwickler sicherstellen, dass der Ereignis-Handler nur dann ausgeführt wird, wenn dies tatsächlich gewünscht und nützlich ist. In der Lightning Konsole können beispielsweise Komponenten, die auf nicht fokussierten Registerkarten enthalten sind, weiterhin zugehört werden, auch wenn sie nicht sichtbar sind. Ein Entwickler kann verschiedene Techniken verwenden, beispielsweise ein Dienstprogrammelement im Hintergrund als einzigen Listener verwenden oder getEnclosingTabId() aufrufen, um zu bestimmen, ob diese Instanz der Komponente auf der Registerkarte "Fokussiert" enthalten ist, um sicherzustellen, dass jedes Ereignis nur zum vorgesehenen Zeitpunkt verarbeitet wird. - **Bei falscher Verwendung von Plattformereignissen wird das Veröffentlichungsverhalten wie folgt geändert:** Plattformereignisse weisen zwei Veröffentlichungsverhaltensweisen auf: Sofort veröffentlichen und Nach Commit veröffentlichen. Es kann nützlich sein, Plattformereignisse in Echtzeit für Anwendungsfälle wie die Protokollierung zu verwenden, bei denen Sie das Protokollierungsereignis veröffentlichen möchten, unabhängig davon, ob die Transaktion erfolgreich ist und übernommen wird. Verwenden Sie jedoch "Sofort veröffentlichen" sehr vorsichtig bei Plattformereignissen in Echtzeit. Ereignisse können von Abonnenten innerhalb derselben Transaktion verwendet werden und zu Zeilensperren oder anderen Rassebedingungen führen. ### Entwerfen effektiver Ereignisse Bei der Implementierung einer ereignisgesteuerten Architektur besteht einer der Schlüssel zum Erfolg darin, Standards für die Gestaltung der Ereignisse selbst festzulegen. Die Spezifika variieren je nach Anwendungsfällen Ihrer Organisation. Im Folgenden finden Sie jedoch einige allgemeine Richtlinien: - **Bestimmen Sie die optimale Struktur für Ihre Ereignisnutzlasten.** Während kleinere Nachrichtengrößen die Verarbeitungszeiten reduzieren, kann es zu Leistungseinbußen kommen, wenn Abonnenten mit massiven Nachrichtenmengen bombardiert werden. Möglicherweise müssen Sie Ihre Nutzlastgrößen und -strukturen wiederholen, um die richtige Balance zu finden. MuleSoft und ähnliche ESB-Tools bieten die Möglichkeit, benutzerdefinierte Nutzlasten in den Ihren Ereignissen zugeordneten Nachrichten zu entwerfen, wodurch Sie Datenstrukturen visualisieren und die Leistung auf Abonnentenseite verbessern können. (Weitere Informationen finden Sie unter [Well-Architected – Reliability](/docs/architect/de-de/well-architected/guide/reliability.html).) - **Überlegen Sie sich Ihre Prozesse durchgängig.** Stellen Sie sicher, dass Sie keine "Endlosschleife"-Szenarien erstellen, die nach der Einführung der Integrationen schwierig aufzuspüren sein können. Ein Beispiel hierfür wären zwei Systeme, die Ereignisse veröffentlichen, wenn Datensätze aktualisiert werden, und gleichzeitig die Ereignisse des jeweils anderen überwachen, wodurch zusätzliche veröffentlichte Ereignisse ausgelöst werden, wenn sie verarbeitet werden. Sie können diese Art von Anti-Pattern beheben, indem Sie beiden Systemen Logik hinzufügen, die sicherstellt, dass Änderungen, die infolge eines verbrauchten Ereignisses vorgenommen werden, nicht zur Veröffentlichung eines neuen Ereignisses führen. Sie sollten auch sicherstellen, dass alle Ihre Ereignisse, ihre zugehörigen Auslöser und die untergeordneten Systeme dokumentiert sind, die möglicherweise betroffen sind. Verwenden Sie diese Dokumentation als Referenz während Designsitzungen, um Endlosschleifen und ähnliche Szenarien so früh wie möglich zu erkennen. (Weitere Informationen finden Sie unter [Well-Architected – Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html).) - **Verwenden Sie systemübergreifend allgemeine Benennungskonventionen.** Konsistente Benennungskonventionen sind eine bewährte Vorgehensweise für die gesamte Softwareentwicklung, einschließlich ereignisgesteuerter Architekturen. Nehmen Sie sich Zeit, um eine Reihe von Standards für Ereignisnamen, Strukturen, zugeordnete Objekte und Fehlerbehandlungsprozesse zu dokumentieren, um die Konsistenz zwischen Systemen sicherzustellen. (Weitere Informationen finden Sie unter [Well-Architected – Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html).) ## Ressourcen
MusterRessourcen
Veröffentlichen/AbonnierenSalesforce Well-Architected – Zuverlässigkeit
Salesforce Well-Architected – Operational Excellence (Salesforce gut entwickelt – Operational Excellence)
Blogpost: Erzielen von architektonischer Effizienz mit Ereignisweiterleitungen
Blogpost: Ankündigung der Pub/Sub-API allgemein verfügbar
Blogpost: Wechsel von RESTful zu EVENTful
Blogpost: Ereignisgesteuerte Architekturen und die AsyncAPI-Spezifikation
Video: Anleitung zum Veröffentlichen/Abonnieren von Mustern
FanoutBlogpost: Arbeiten innerhalb der Zustellungsobergrenzen für Plattformereignisse
Video: Anleitung zu Fanout-Mustern
Übergebene NachrichtenVideo: Anleitung zum Muster für übergebene Nachrichten
StreamingBlogpost: Entwerfen von Schreibvorgängen mit hohem Volumen in Salesforce
Video: Anleitung zu Streaming-Mustern
Dokumentation: Streaming in Mule-Anwendungen
WarteschlangeBlogpost: Entwerfen von Schreibvorgängen mit hohem Volumen in Salesforce
Blogpost: Entwerfen von Zahlungsarchitekturen mit Evented-APIs
Video: Anleitung zum Warteschlangenmuster
# Erste Schritte mit Data 360-Entscheidungsleitfäden In diesem Abschnitt finden Sie praktische Anleitungen für wichtige architektonische Entscheidungen zu Salesforce Data 360, einschließlich Bereitstellungsstrategien, Multi-Organisations-Konnektivität und Integrationsmustern. Verwenden Sie diese Anleitungen, um effektive Datenarchitekturen zu entwerfen und zu implementieren, die Kundendaten vereinheitlichen und AI-gestützte Funktionen aktivieren. --- ## Data 360-Bereitstellung Die [Data 360-Bereitstellung](/docs/architect/de-de/decision-guides/guide/data-360-provisioning) umfasst grundlegende Entscheidungen bei der Bereitstellung von Salesforce Data 360: - **Auswahl der Startseitenorganisation**: Legen Sie fest, ob Data 360 in einer vorhandenen Produktionsorganisation bereitgestellt oder eine dedizierte Organisation erstellt werden soll, wobei die Governance, die Compliance und die Zeit bis zur Wertschöpfung zu berücksichtigen sind. - **Strategie für mehrere Organisationen**: Wählen Sie zwischen mehreren unabhängigen Data 360-Instanzen oder verwenden Sie Data Cloud One, um mehrere Salesforce-Organisationen zu vereinheitlichen und so Autonomie, Compliance und Kosten in Einklang zu bringen. - **Data Cloud One-Architektur**: Aktivieren Sie mehrere Begleitorganisationen, um eine einzelne Data 360-Instanz mit zentraler Verwaltung, Metadatenfreigabe und Funktionsparität organisationsübergreifend freizugeben. - **Datenfreigabe zwischen Data 360-Organisationen**: Verwenden Sie die Zero-Copy-Datenfreigabe zwischen unabhängigen Instanzen für regionale Compliance-, Geschäftseinheitenzusammenarbeit- oder Verbundführungs-Dashboards. - **Überlegungen zur Bereitstellung**: Faktoren für Datenresidenz, Governance-Modelle, Latenz, Integrationskomplexität, Kosten und AI-Bereitschaft für unternehmensweite Bereitstellungen. Hilft Architekten beim Entwerfen von Bereitstellungsstrategien, die Einfachheit, Unternehmenskonsistenz, Compliance und Skalierbarkeit für Customer 360, AI und plattformübergreifende Innovationen gewährleisten. --- ## Data 360-Interoperabilität Die [Data 360-Interoperabilität](/docs/architect/de-de/decision-guides/guide/data-360-interoperability) bietet ein Framework für die Integration von Data 360 in externe Plattformen und Data Lakes: - **Datenaufnahmemuster**: Echtzeit-, Streaming- und Batch-Aufnahme zur Erstellung von kanonischen Datensets, die sich ideal für Customer 360, Compliance und zentralisierte Unternehmensführung eignen. - **Zero-Copy Data Federation (Zero-Copy-Datenverbund)**: Live-Abfrage, beschleunigte Abfrage (Zwischenspeicherung) und Dateiverbund-Methoden für den Zugriff auf externe Systeme in Echtzeit ohne Duplikate, wodurch Personalisierung, Dashboards und AI/ML-Arbeitslasten aktiviert werden. - **Hybridansatz**: Kombinieren Sie die gesteuerte Aufnahme für zentrale Datensets mit der Zero-Copy-Verbundorganisation für Aktualität und Skalierbarkeit und unterstützen Sie so das Omnikanal-Engagement, Agentforce Aktionen und Unternehmensanalysen. - **Beschlussrahmen**: Werten Sie Kompromisse in Bezug auf Latenz, Kosten, Skalierbarkeit, Governance und Komplexität aus, um das richtige Integrationsmuster pro Datenquelle auszuwählen. - **Architekten-Playbooks**: Branchenspezifische Anleitungen, Designpraktiken und Kostenüberlegungen für Finanz-, Gesundheits-, Einzelhandels- und Telekommunikationsszenarien. Leitet Architekten bei der Balance zwischen Datenaktualisierung, Governance und Pipeline-Effizienz an, um skalierbare, interoperable und AI-fähige Datenarchitekturen zu erstellen, die sowohl operative als auch analytische Arbeitslasten unterstützen. # Erste Schritte mit Integrationsentscheidungsleitfäden In diesem Abschnitt finden Sie praktische Anleitungen zur Auswahl der richtigen Datenintegrationstools und -ansätze für Salesforce. Sie deckt ausgehende Integrationen, eingehende Integrationen und organisationsübergreifende Szenarien ab und unterstützt Architekten beim Entwerfen und Implementieren von Datenebenenintegrationen, die Leistung, Wartungsfähigkeit und Kosten in Einklang bringen. --- ## Datenintegration in Salesforce Die [Datenintegration in Salesforce](/docs/architect/de-de/decision-guides/guide/data-integration) bietet einen umfassenden Überblick über Salesforce-Datenintegrationstools und bewährte Vorgehensweisen: - **Integrationstool-Landschaft**: Übersicht über Salesforce-Datenintegrationstools, einschließlich Low-Code-, Hybrid- und Pro-Code-Optionen, mit Anleitungen zur Auswahl des richtigen Tools für bestimmte Anwendungsfälle. - **Ausgehende Integrationen**: Methoden zum Senden von Daten aus Salesforce an externe Systeme, einschließlich Datenerfassung ändern, externer Services, Heroku Connect, OmniStudio-Integrationsverfahren, Salesforce Connect, MuleSoft Anypoint und benutzerdefinierter Apex-Lösungen. - **Eingehende Integrationen**: Ansätze zum Integrieren externer Daten in Salesforce mit Anleitungen zur Datenreplikation im Vergleich zur Virtualisierung und zur Verwendung der einzelnen Tools. - **Organisationsübergreifende Integrationen**: Empfohlene Methoden zum Freigeben von Daten zwischen Salesforce-Organisationen, einschließlich MuleSoft Anypoint, Heroku Connect, nativer Salesforce-APIs, Datenerfassung ändern und Salesforce Connect mit organisationsübergreifendem Adapter, einschließlich Anleitungen zum Ersetzen veralteter Salesforce-zu-Salesforce-Implementierungen. - **Beschlussrahmen**: Wichtige Überlegungen zur Auswahl von Integrationstools, beispielsweise vorhandene Tools und Landschaft, Datenflussanforderungen (Zeiteinteilung, Richtung, erwartete Benutzererfahrung), Implementierungskomplexität, Wartbarkeit, Datenvolumen und Plattformobergrenzen. Ermöglicht Architekten die Auswahl der richtigen Integrationstools und -muster für jedes Szenario, minimiert unnötige Datenreplikationen, nutzt vorhandene ESB/ETL-Lösungen und gewährleistet skalierbare, wartbare Integrationen, die mit den Prinzipien der Unternehmensarchitektur in Einklang stehen. # Erste Schritte mit Plattformentscheidungsleitfäden In diesem Abschnitt finden Sie praktische Anleitungen für wichtige architektonische Entscheidungen zu Salesforce Platform-Funktionen. Sie umfasst asynchrone Verarbeitung, durch Datensätze ausgelöste Ereignisse, Formularerstellung, Automatisierung von Agenten und traditionellen Workflows, ereignisgesteuerte Architektur und schrittbasierte asynchrone Frameworks, die Architekten beim Entwerfen skalierbarer, wartungsfreundlicher und leistungsstarker Plattformlösungen unterstützen. --- ## Asynchrone Verarbeitung Die [asynchrone Verarbeitung](/docs/architect/de-de/decision-guides/guide/async-processing) bietet Anleitungen zu Tools und Ansätzen für asynchrone Vorgänge in Salesforce: - **Tools für die asynchrone Verarbeitung**: Vergleich von warteschlangenfähigem Apex, geplantem Apex, Plattformereignisauslösern, Datenerfassung ändern, geplanter Pfad (nach Commit-Flows) und asynchroner Pfad (durch Datensätze ausgelöste Flows) mit Anleitungen zu geeigneten Anwendungsfällen. - **Serverseitige asynchrone Verarbeitung**: Muster für langfristige Datenbankvorgänge, externe Callouts und die Verarbeitung von Datensätzen mit großem Volumen. - **Clientseitige asynchrone Verarbeitung**: Techniken wie Apex Continuation Callouts und clientseitige asynchrone Verarbeitung, die in Browsern oder mobilen Anwendungen ausgeführt werden können. - **Beschlussrahmen**: Ziehen Sie die Validierung von Anwendungsfällen, die Skalierbarkeit, das Verständnis, wann Transaktionen wirklich asynchron sind, die Überwachung und die Verarbeitung von Ereignissen mit extremer Belastung in Betracht. - **Bewährte Vorgehensweisen und Anti-Patterns**: Anleitung für die ordnungsgemäße Verwendung, einschließlich ausgehender Integrationen, Überwachung und Vermeidung häufiger Fallstricke. Ermöglicht es Architekten, skalierbare, zuverlässige und wartbare asynchrone Muster zu implementieren und so Fallstricke zu vermeiden, die die Leistung beeinträchtigen. --- ## Erstellen von Formularen [In "Formulare erstellen](/docs/architect/de-de/decision-guides/guide/build-forms)" erhalten Architekten Anleitungen zu Salesforce-Formularerstellungsoptionen: - **Formularerstellungstools**: Vergleich von dynamischen Formularen, Bildschirm-Flow, OmniStudio, Bildschirm-Flow mit Lightning Web Components (LWC) und LWC, einschließlich Fertigkeiten und Lizenzüberlegungen. - **Beschlussrahmen**: Berücksichtigen Sie Objektauswirkung, Formularumfang, Navigation, Standort (Anwendung, Mobilgerät, Web), Benutzeroberfläche und Testautomatisierung. - **Anleitung zur Werkzeugauswahl**: Empfehlungen von einfachen Datensatzlayouts bis hin zu mehrseitigen Assistenten und Formularen mit Branding für Kunden. - **Kombinationsmuster**: Anleitung zum Kombinieren von Tools, z.B. Bildschirm-Flow-Navigation mit LWC-Stil. - **Erweiterte Funktionen**: Im Detail werden Funktionen und Einschränkungen beschrieben, um die Auswahl des Tools zu unterstützen. Hilft Architekten, den richtigen Ansatz für die Formularerstellung für ihre spezifischen Anforderungen an Benutzeroberfläche, Funktionen und Integration auszuwählen. --- ## Bestimmen der Automatisierung von Agenten und traditionellen Workflows Die [Bestimmung der Agenten-](/docs/architect/de-de/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html) und traditionellen Workflow-Automatisierung bietet ein Framework für die Auswahl zwischen der traditionellen Automatisierung und Agentforce mit dem Framework für die Orchestrierungsdichte: - **Orchestrierungsdichte-Framework**: Wertet die Automatisierungskomplexität anhand des Ausführungspfads (vollständig vorgebbar vs. nicht vorgebbar), der Zielkomplexität (Einzelaufgabe vs. konkurrierende Ziele) und des Modalitätsmix (strukturierte vs. multimodale Eingaben) aus. - **Produktlandschaft**: Vergleich von Flows, Apex, Agentforce, Agentenskript, Agentforce Grid, Agentforce Operations und MuleSoft für verschiedene Automatisierungsszenarien. - **Dichteauswahlmatrix**: Orchestrierungsdichtestufen (niedrig, mittel, hoch) werden Architekturstandards zugeordnet, von durch Datensätze ausgelöster Automatisierung über hybride Orchestrierung bis hin zu geführtem Determinismus mit Agentenskript. - **Beschlussrahmen**: Sequenzieller Evaluierungsprozess: Untersuchen Sie zuerst den Ausführungspfad, dann die Zielkomplexität und dann den Modalitätsmix, um das richtige Tool zu bestimmen. - **Hilfestellung für Anwendungsfälle**: Spezifische Empfehlungen für die traditionelle Automatisierung (regelbasiert, deterministisch), Agentforce Grid (Aufgaben mit Massen-AI), hybride Orchestrierung (komplexe durchgängige Prozesse) und Agentenskript (unstrukturierte Einstiegspunkte mit Argumentationsbedarf). Ermöglicht es Architekten, fundierte Entscheidungen im gesamten Automatisierungsspektrum zu treffen, und gleicht Argumentationsfunktionen mit deterministischer Steuerung für skalierbare, überprüfbare und wartbare Lösungen aus. --- ## Ereignisgesteuerte Architektur Die [ereignisgesteuerte Architektur](/docs/architect/de-de/decision-guides/guide/event-driven) bietet eine umfassende Anleitung zu Salesforce-Tools und -Mustern für Eventing: - **Eventing-Tools**: Übersicht über Plattformereignisse, Datenerfassung ändern, Pub/Sub-API, MuleSoft Anypoint, Streaming-API und Integrationsüberlegungen. - **Ereignisgesteuerte Muster**: Enthält Veröffentlichungs-/Abonnement-, Fanout-, übergebene Nachrichten, Streaming- und Warteschlangenmuster für verschiedene ereignisgesteuerte Anwendungsfälle. - **Integration in MuleSoft**: Verwenden von Anypoint-Konnektoren (Pub/Sub, JMS, Kafka, Solace, MQ, MQTT, AMQP) für Unternehmensarchitekturen. - **Plattformereignisse und Datenerfassung ändern**: Anleitung zu bevorzugten Mechanismen für die Veröffentlichung von Datensatz- und Feldänderungen mit Migration von PushTopic/Generic Events. - **Implementierungsmuster**: Bewährte Vorgehensweisen für Skalierbarkeit, Konsistenz, Fehlerbehandlung und Überwachung. Ermöglicht es Architekten, skalierbare, nahezu echtzeitgesteuerte Systeme zu entwerfen, die mehrere Systeme effizient verbinden. --- ## Schrittbasiertes asynchrones Framework Das [schrittbasierte asynchrone Framework](/docs/architect/de-de/decision-guides/guide/step-based-async-framework) bietet ein Framework für die modulare, skalierbare asynchrone Auftragsverarbeitung: - **Framework-Architektur**: Zu den Komponenten zählen warteschlangenfähiges Apex, Finalizer, geplanter Flow, Apex Cursors, aufrufbare Aktionen und Slack-Integrationen. - **Schrittbasierte Verarbeitung**: Breaks arbeiten in unabhängige Schritte, die ausgeführt, wiederholt und neu gestartet werden können, mit gemeinsamer Governance und operativer Sichtbarkeit. - **Implementierungsanleitung**: Muster für die Oberfläche "Schritt", "Schrittprozessor", "Aufrufbare Apex-Ebene", "Verzögerungsverarbeitung" und "Benachrichtigungen". - **Bewährte Vorgehensweisen**: Empfohlen, wenn die meisten Informationen in CRM vorhanden sind, für Arbeitslasten mit hohem Volumen und für die hierarchische oder baumbasierte Datensatzverarbeitung; Hinweise, wann sie nicht verwendet werden sollten. - **Funktionen auf Unternehmensebene**: Governance, Compliance, Statusverteilung, Fortschrittsverfolgung, SLA-Überwachung, Fehlerdiagnose und Protokollierung auf Auditebene. Bietet Architekten eine skalierbare Alternative zu monolithischen Batchaufträgen und verketteten asynchronen Aufrufen und unterstützt Salesforce-Arbeitslasten mit hohem Volumen bei voller betrieblicher Transparenz. --- ## Durch Datensätze ausgelöste Automatisierung Die [durch Datensätze ausgelöste Automatisierung](/docs/architect/de-de/decision-guides/guide/record-triggered) bietet das Framework zum Entwerfen der durch Datensätze ausgelösten Automatisierung auf Salesforce Platform: - **Werkzeugauswahl**: Verwenden von durch einen Datensatz ausgelösten Flows im Vergleich zu Apex-Auslösern, gestützt auf die Automatisierungsdichte (niedrig, mittel, hoch) und die Auswahlmatrix für die Dichte. - **Automatisierungsdichte**: Wie Sie die Automatisierungsmenge, das Datensatzvolumen und die Streuung der Abhängigkeiten bewerten, um Flow-, Hybrid- (Flow mit aufrufbarem Apex) oder Apex-Auslöser auszuwählen. - **Eintrittspunkte und Governance**: Ein Einstiegspunkt pro Salesforce-Objekt; Anleitung zu Eintrittsbedingungen, Rekursionssteuerung und geordneter Ausführung. - **Asynchroner Aufruf**: Wann und wie asynchrone Prozesse aus durch einen Datensatz ausgelösten Flows oder Apex aufgerufen werden können, mit Vorsicht bei der Fehlerbehandlung und Obergrenzen. - **Bewährte Vorgehensweisen**: Muster für die Massenverarbeitung, hybrides Flow-Apex-Design und Vermeidung häufiger Fallstricke bei der Auslöserautomatisierung. Ermöglicht Architekten das Entwerfen einer skalierbaren, wartungsfreundlichen und leistungsfähigen durch Datensätze ausgelösten Automatisierung, die an Plattformstandards ausgerichtet ist. # Erstellen von Formularen Es gibt mehrere Optionen zum Erstellen von Formularen auf der Agentforce 360 Platform und sie umfassen ein Kontinuum von Low-Code- bis hin zu Pro-Code-Ansätzen. An einem Ende des Kontinuums können dynamische Formulare im Lightning-Anwendungsgenerator und Bildschirm-Flows in Flow Builder für Low-Code-Lösungen verwendet werden. Zum anderen wird für Pro-Code-Lösungen das Lightning Web Component Framework (LWC) verwendet. Innerhalb des Kontinuums können Tools auf verschiedene Weise mit Bildschirm-Flows gemischt werden, die um LWCs und kundenorientierte Formulare erweitert werden, die mit OmniStudio erstellt wurden. ## Leitfadenübersicht In diesem Leitfaden werden ein Entscheidungs-Framework und Anleitungen zum Erstellen von Formularen für Benutzeroberflächenlösungen vorgestellt. Insbesondere werden ein Dutzend Laufzeiten und nicht funktionale Entscheidungspunkte verwendet, um die beste Technologie für einen bestimmten Anwendungsfall auszuwählen. ## Takeaways - **Verwenden Sie beim Erstellen von Layouts zum Erstellen/Bearbeiten/Anzeigen von Lightning-Seiten dynamische Formulare.** Künftig wird empfohlen, _dynamische Formulare_ im _Lightning App Builder_ zu verwenden, um Datensatz-Detailseiten zu konfigurieren. - **Wenn Sie ein Formular für ein Objekt erstellen, erstellen oder bearbeiten müssen, verwenden Sie _Lightning Pages_ und _Dynamische Formulare_.** Dies ist die einfachste Möglichkeit, Formulare auf der Agentforce 360 Platform zu erstellen. Sie bietet auch zusätzliche Funktionen (z. B. Kontrolle der Feldsichtbarkeit). - **Wenn Sie ein mehrseitiges Formular oder einen Assistenten erstellen und keine strengen UX- oder Branding-Anforderungen haben, verwenden Sie einen Bildschirm-Flow.** Bildschirm-Flows bieten ein lineares Navigations-Framework für die Orchestrierung mehrerer Formulare. Sie können LWCs verwenden, um Ihr eigenes Framework für die Navigation zwischen Formularen zu erstellen. Es wird jedoch empfohlen, Flow die Arbeit zu überlassen, damit Sie sich auf die Formulare selbst konzentrieren können, statt sich auf den Formularstatus zu konzentrieren. - **Wenn Sie zusätzliche Logik oder Aktionen zur Unterstützung des Formulars benötigen, verwenden Sie einen Bildschirm-Flow, OmniStudio oder LWCs.** Jedes dieser Tools bietet unterschiedliche Möglichkeiten, Ihre Lösung zu verbessern, indem sie über das Erstellen oder Bearbeiten eines einzelnen Datensatzes hinaus erweitert wird. In diesem Fall kann sich der Begriff _eher_ auf erweiterte Logik (z. B. Verzweigung oder Iteration) oder auf Aktionen wie die Integration in externe Systeme, das Senden von E-Mails oder das Übertragen von Benachrichtigungen an die mobile Anwendung eines Benutzers beziehen. - **Wenn Sie über komplexe UX-Anforderungen verfügen oder mehr als die Benutzeroberflächensichtbarkeit dynamisch verwalten müssen, verwenden Sie LWC oder OmniScript.** Für Anforderungen, die durch die Verwendung von Themen und spaltenbasierten Layouts erfüllt werden können, können Sie Ihre Formulare direkt in einem Low-Code-Generator erstellen. Die genaue Kontrolle über den Stil Ihres Formulars erfordert jedoch die Flexibilität von LWC. Wenn Sie ein Branchenkunde sind und ein perfektes Branding benötigen oder über komplexe hierarchische Daten verfügen, verwenden Sie OmniStudio, mit dem Sie Formulare auf Verbraucherebene erstellen können, die komplexe Geschäftslogik und Datentransformationen verarbeiten können. - **Wenn Sie die Testautomatisierung bereitstellen müssen, verwenden Sie LWC.** Sie können Einheitentests für jede LWC schreiben, unabhängig davon, wo Sie sie einbetten. Dadurch können Sie eine zuverlässigere Teststrategie erstellen, die Massentests mit mehreren Datensätzen sowie negative Tests umfassen kann. - **Sie sind nicht an "entweder/oder"-Entscheidungen gebunden.** Sie können mehrere Optionen kombinieren, um die beste Lösung für Ihre Anwendungsfälle zu finden (wenn Sie beispielsweise das integrierte Navigationssystem von Flow und die volle Flexibilität bei der Gestaltung von LWC benötigen, können Sie sie zusammen verwenden). ## Tools im Umfang Die folgenden Tools werden häufig zum Implementieren und Erweitern von Formularerfahrungen verwendet. ### Werkzeugbeschreibungen
Dynamische Formulare Dynamische Formulare im Salesforce Lightning App Builder unterteilen monolithische Datensatzdetailkomponenten in einzelne konfigurierbare Felder und Abschnitte. Mit dieser Funktion können Administratoren flexible und leistungsstarke Seiten erstellen, indem sie Felder an einer beliebigen Stelle platzieren und Sichtbarkeitsregeln verwenden, um Komponenten basierend auf Benutzerprofilen, Geräten oder Daten anzuzeigen oder auszublenden, was die Übersichtlichkeit der Seiten reduziert.
Bildschirm-Flow Bei einem Salesforce-Bildschirm-Flow handelt es sich um ein interaktives Automatisierungstool in Flow Builder, das Benutzereingaben erfordert, um benutzerdefinierte schrittweise Geschäftsprozesse zu durchlaufen. Im Gegensatz zu automatisierten Hintergrund-Flows bieten Bildschirm-Flows eine assistentenähnliche Benutzeroberfläche, um Daten zu erfassen, Informationen anzuzeigen oder Aktionen über Lightning-Seiten, Schaltflächen oder benutzerdefinierte Anwendungen auszuführen, ohne Code schreiben zu müssen.
OmniStudio Salesforce OmniStudio ist eine Low-Code-Suite mit Tools, die für die schnelle Erstellung geführter, branchenspezifischer digitaler Erfahrungen und komplexer Geschäftsprozesse konzipiert wurden. Damit können Entwickler mithilfe von Komponenten zum Ziehen und Ablegen wie FlexCards und OmniScripts pixelgenaue Benutzeroberflächen erstellen (z. B. geführte Workflows und dynamische Dashboards). Mit OmniStudio können Sie deklarativ LWCs erstellen.
Lightning Web Components Bei Salesforce Lightning Web Components handelt es sich um leichte benutzerdefinierte HTML-Elemente, die mit HTML, CSS und modernem JavaScript erstellt wurden und für die native Ausführung in Browsern konzipiert wurden, um die Leistung der Salesforce-Benutzeroberfläche zu verbessern. Sie ermöglichen es Entwicklern, benutzerdefinierte Benutzeroberflächen zu erstellen, die zusammen mit Aura-Komponenten vorhanden sind, was die Entwicklung durch Branchenstandards und ein detailliertes Komponenten-Ökosystem erhöht.
### Werkzeugfertigkeiten und Lizenzanforderungen In dieser Tabelle werden die Tools beschrieben, die zum Erstellen von Formularen über Salesforce verfügbar sind, sowie die erforderlichen Fertigkeiten und Lizenzüberlegungen. **Hinweis:** In einem späteren Abschnitt werden die spezifischen Funktionen, die für jedes Tool unterstützt werden, genauer erläutert, wie Sie zwischen klickbasierten Tools und codebasierten Tools auswählen und wann sie kombiniert werden.
Konfiguration Zusätzliche Lizenzanforderungen
Dynamische Formulare Low Code (Niedriger Code) Keine
Bildschirm-Flow Low Code (Niedriger Code) Keine
OmniStudio Low Code + Pro Code Branchenpaket
Bildschirm-Flow plus Lightning Web Components Low Code + Pro Code Keine
Lightning Web Components Pro-Code Keine
## Entscheidungspunkte Beim Treffen von Produkt- und Werkzeugauswahlen sind eine Reihe von Entscheidungspunkten zu beachten. In dieser Tabelle werden verschiedene Entscheidungspunkte beschrieben und allgemeine Anleitungen bereitgestellt.
Entscheidungspunkt Anleitung
Anwendungsfallkategorien für die Laufzeit
Formularumfang und Navigation Legen Sie fest, ob alle Felder in Ihrem Formular logisch auf einen einzelnen Bildschirm passen oder ob Benutzer zwischen mehreren Bildschirmen navigieren können müssen.
Standort Geben Sie die Position(en) an, an der bzw. den Sie das Formular einbetten möchten. Dies kann von einer Salesforce-Anwendung über eine mobile Anwendung bis hin zu einer externen Website reichen.
Steuerfeld Identifizieren Sie die Aktionen oder Logik, die im Hintergrund ausgeführt werden müssen, während Benutzer mit Ihrem Formular interagieren, einschließlich Datentransformationen und Integrationen in externe Systeme.
Validierung Ermitteln Sie, ob Sie zusätzliche Eingabevalidierungsanforderungen haben, die über die von Salesforce bereitgestellte Standardvalidierung auf Systemebene hinausgehen.
Interaktionsdesign Identifizieren Sie die Arten von Interaktionen oder Bedingungen, die dynamische Antworten in Ihrem Formular auslösen sollen.
Stil Bestimmen Sie den Grad der Komplexität, der für Ihren gewünschten Stil und Ihre CSS-Anforderungen erforderlich ist.
Layout Identifizieren Sie die Layoutanforderungen Ihres Formulars (beispielsweise die erforderliche Anzahl an Spalten, Registerkarten und Akkordeons) und die Möglichkeit, sich wiederholende Datenblöcke anzuzeigen.
Übersetzung Legen Sie fest, ob Ihr Formular für andere Sprachen lokalisiert werden muss.
Nicht funktionale Überlegungen
Sicherheit Legen Sie fest, ob Ihr Formular den Zugriff des Benutzers vor der Ausführung bestimmter Vorgänge überprüfen soll, ob Sie steuern möchten, wer auf das Formular zugreifen kann und ob Sie steuern möchten, wo das Formular eingebettet werden kann.
Objektauswirkung Legen Sie fest, ob Ihr Formular für ein einzelnes Objekt oder für mehrere Objekte verwendet werden soll.
Benutzeroberflächentestautomatisierung Legen Sie fest, ob Ihr Formular für Ihre DevOps-Prozesse automatisierten Einheitentests oder automatisierten durchgängigen Tests unterzogen werden muss.
Kennzahlen Legen Sie fest, wie Sie die Nutzung Ihres Formulars verfolgen möchten, einschließlich Seitenaufrufen, der für das Formular aufgewendeten Zeit, Abschlussraten und Erfolgsraten.
Paketerstellung und Bereitstellung Legen Sie fest, wie Sie Ihr Formular verteilen oder bereitstellen möchten, nachdem es erstellt wurde.
**Hinweis:** In nachfolgenden Entscheidungsvergleichstabellen gibt es eine Handvoll Werte, die einem beliebigen Werkzeug-Funktionspaar zugeordnet sind: - **Verfügbar:** Das Tool/die Funktion funktioniert mit grundlegenden Überlegungen. - **Nicht verfügbar:** Es ist nicht geplant, innerhalb der nächsten zwölf Monate Support hinzuzufügen. - **Nicht ideal:** Dieses Tool/diese Funktion kann funktionieren, ist jedoch nicht das optimale Tool. - **Nicht zutreffend:** Das Tool gilt nicht für den jeweiligen Anwendungsfall. ## Anwendungsfälle Verwenden Sie diese Szenarien, um Tooling-Auswahlen anhand von Umfang, Umfang und betrieblichen Anforderungen zu vergleichen. ### Formularumfang und Navigation Wenn Sie alle Ihre Benutzereingaben über ein Formular mit einem einzigen Bildschirm abrufen können, beginnen Sie mit "Dynamische Formulare". Beachten Sie, dass dynamische Formulare auf Datensatzseiten die Funktion "Pfad" verwenden können, um mehrstufige Geschäftsprozesse zu unterstützen. #### Zu stellende Fragen - Benötigen Sie einen einzelnen Bildschirm oder muss der Benutzer zwischen mehreren Bildschirmen navigieren, um eine Aufgabe zu erledigen? - Möchten Sie, dass Ihren Benutzern beim Ausfüllen Ihres Formulars visuell angezeigt wird, wie weit sie im Prozess sind? Müssen Ihre Benutzer die Informationen auf jedem Bildschirm in einer bestimmten Reihenfolge ausfüllen oder sollten sie nach Bedarf zwischen den Bildschirmen wechseln können? Wenn Sie mehr Funktionen benötigen, als dynamische Formulare bieten, hängt die Auswahl zwischen Flow, OmniStudio und LWC von einigen zusätzlichen Fragen ab: - Ist es in Ordnung, unten in Ihrem Formular eine Navigationsleiste anzuzeigen? Wenn die Bildschirm-Flow- und OmniScript-Navigationserfahrung eine unerwünschte Benutzeroberfläche bereitstellt, neigen Sie zu LWC. - Was muss hinter dem Formular auftreten? Wenn das Verhalten von einem Administrator konfiguriert werden muss, verwenden Sie einen Flow. Verwenden Sie für komplexe Beziehungen mit mehreren Objekten _OmniScript_ oder _LWC_.
Einzelbildschirm Formular mit mehreren Bildschirmen Fortschrittsindikatoren Schnellnavigation zwischen Schritten/Bildschirmen
Dynamische Formulare Verfügbar Nicht verfügbar Verfügbar Nicht verfügbar
Bildschirm-Flow Verfügbar Verfügbar Verfügbar Nicht verfügbar
OmniStudio Verfügbar Verfügbar Verfügbar Verfügbar
Bildschirm-Flow + LWC Verfügbar Verfügbar Verfügbar Verfügbar
LWC Verfügbar Nicht ideal Nicht ideal Nicht ideal
Wenn Sie Flow oder OmniStudio auswählen, müssen Sie möglicherweise auch eine LWC erstellen, um die richtige Benutzeroberfläche zu erreichen. Wenn Sie bereits eine Lightning-Webkomponente erstellen, um den Stil Ihres Formulars richtig festzulegen, sollten Sie überlegen, ob [diese Komponente in einen Flow](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow) eingebettet werden muss. **Navigation im Assistentenstil** Wenn Ihre Lösung jedoch wie ein Assistent aussieht, bei dem der Benutzer zwischen mehreren Bildschirmen navigiert, sollten Sie Flow oder OmniStudio in Betracht ziehen. Flows und OmniStudio verfügen über ein integriertes Navigationsmodell, sodass Sie keine aneinandergereihten LWCs erstellen und verwalten müssen. Die Navigation erfolgt linear mit vorwärts beweglichen Aktionen, rückwärts beweglichen Aktionen und einem Mechanismus zum Speichern des Formulars für später. Sie können auch ein Formular mit nichtlinearer Navigation erstellen, wenn es Ihren Zwecken entspricht. OmniStudio bietet einen wichtigen Navigationsvorteil, da Fortschrittsindikatoren aus der Standardnavigation bereitgestellt werden, die Schritte im Formular anzeigen. In der Schrittansicht wird automatisch angezeigt, wo sich ein Benutzer in einem Formular mit mehreren Schritten befindet. Im Gegensatz zu Flow können Benutzer durch Klicken auf verschiedene Schritte im Formular zwischen Bildschirmen wechseln. Unabhängig davon, ob Sie Formulare mit einem oder mehreren Bildschirmen erstellen, ist es wichtig, sicherzustellen, dass Ihre Formulare optimiert sind, damit Ihre Benutzer einfach darin navigieren können. ### Formfaktor Wenn Sie ein Formular in eine Lightning Standard-Datensatzseite einbetten, funktionieren alle Tools, die verglichen werden. Dynamische Formulare sind derzeit jedoch nur auf dem Desktop verfügbar. Wenn Sie eine Erfahrung bereitstellen möchten, die es Benutzern ermöglicht, von anderen Standorten aus auf Formulare zuzugreifen, sollten Sie möglicherweise alternative Optionen in Betracht ziehen. #### Zu stellende Fragen - Benötigen Benutzer Zugriff auf das Formular über Desktops, Mobilgeräte oder beides? - Sollten Benutzer von überall in Ihrer Anwendung aus über eine Dienstprogrammleiste auf das Formular zugreifen können? - Möchten Sie Schnellaktionen aktivieren, damit Benutzer Ihr Formular ausfüllen können, ohne die Seite verlassen zu müssen, auf der sie sich gerade befinden? - Muss Ihr Formular auf einer externen Website verfügbar sein?
Lightning-Datensatzseite Lightning-Startseite oder -Anwendungsseite Aura Experience Cloud-Sites LWR Experience Cloud-Sites Eingebettete Snap Dienstprogrammleiste Objektspezifische Aktion Globale Aktion Mobile Salesforce-Anwendung* Field Service Mobile Mobiles SDK Externe Sites und Anwendungen Benutzerdefinierte LWC
Dynamische Formulare Verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar
Bildschirm-Flow Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Nicht verfügbar Verfügbar Verfügbar** Nicht verfügbar Nicht verfügbar Verfügbar
OmniStudio Verfügbar Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar Verfügbar Nicht verfügbar Nicht verfügbar Verfügbar Nicht verfügbar Nicht verfügbar Verfügbar Verfügbar
Bildschirm-Flow + LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Nicht verfügbar Verfügbar Nicht verfügbar Nicht verfügbar Nicht ideal Verfügbar
LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar Verfügbar Nicht verfügbar Nicht verfügbar Verfügbar Verfügbar
* Flows und Lightning-Webkomponenten werden in der mobilen Salesforce-Anwendung unterstützt, jedoch nicht alle Möglichkeiten zum Einbetten von Flows und Lightning-Webkomponenten (z. B. werden objektspezifische Aktionen auf Mobilgeräten unterstützt, Dienstprogrammleistenelemente jedoch nicht).

**Die mobile Salesforce Field Service-Anwendung enthält die Datenerfassung – eine auf dem Flow-Modul basierende Lösung für die Offline-Erstverarbeitung mit einer dedizierten Offline-Laufzeit, die die neuesten Flow-Funktionen unterstützt. Die Anwendung enthält auch die alten Field Service Mobile-Flows, die auf einem älteren benutzerdefinierten Offline-Modul ausgeführt werden und viele der neuesten Flow-Funktionen nicht unterstützen.
Da Datensatzkontext erforderlich ist, wird die Funktion "Dynamische Formulare" nur auf Lightning-Datensatzseiten unterstützt. Dynamische Formulare werden jedoch auf Experience Cloud-Seiten nicht unterstützt. Sie können Flows erstellen, die einen Datensatzkontext erfordern, oder Flows, die global funktionieren. Anders ausgedrückt: Sie können Flows an einer Vielzahl von Stellen einbetten. Bei Flows im Datensatzkontext können Standorte Folgendes umfassen: Lightning-Datensatzseiten, Experience Cloud-Datensatzseiten, objektspezifische Aktionen oder Bereitstellungen von Aktionen und Empfehlungen. Bei globalen Flows können Standorte Folgendes umfassen: Dienstprogrammleiste, andere Lightning- oder Erfahrungsgenerator-Seiten, Snap oder externe Anwendungen. Derzeit werden Flows nicht als globale Aktionen unterstützt. Sie können _Flows_ jedoch als Übergangslösung in eine _Aura-_Komponente einschließen. Mit OmniStudio können Sie zusammengesetzte FlexCards und OmniScripts erstellen, die Sie _fast_ überall platzieren können, wo Sie einen Flow platzieren können. Sie können jedoch nicht in Pakete aufgenommen werden. LWC bietet ein hohes Maß an Wiederverwendbarkeit für die Erstellung von Komponenten, die über Metadaten in Salesforce-, Communities- und Open-Source-Projekten Zielen zugeordnet werden können. Mit [Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html) können LWC-Komponenten auch in Ihre eigene Website eingebettet werden. Lightning Out on External Sites LWC-Komponenten können Flows auch mit der Komponente [Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation) starten. OmniStudio zeichnet sich durch die Bereitstellung von Inhalten für externe Sites über die OmniOut-Funktion aus. Mit OmniStudio und OmniOut können Sie Ihre OmniScript-Formulare und FlexCard-Komponenten zu Standardkomponenten kompilieren und sie dann außerhalb der Plattform auf Sites oder in Anwendungen von Drittanbietern ausführen. Derzeit wird keine der in diesem Handbuch behandelten Formulartechnologien offiziell in Mobile SDK-Vorlagen unterstützt. Wenn das Mobile SDK für Ihren Anwendungsfall wichtig ist, empfiehlt es sich, Ihr Formular nativ in Ihrer mobilen Anwendung zu erstellen oder eine Visualforce-Seite zu erstellen, wobei der Formfaktor zu berücksichtigen ist. ### Logik Dynamische Formulare sind perfekt, wenn Sie die Werte in Ihrem Formular verwenden müssen, um einen Datensatz zu erstellen oder zu aktualisieren. Sie müssen Flow, OmniStudio oder LWC für Funktionen nutzen, die außerhalb dieses Geltungsbereichs liegen. Dazu zählen das Erstellen von Entscheidungs- oder Iterationsebenen oder das Generieren von Slack-Posts oder -E-Mails mithilfe der Eingaben aus dem Formular. #### Zu stellende Fragen - Welche Aktionen oder Logiken müssen im Hintergrund ausgeführt werden? - Müssen Sie Werte aus einem verwandten Datensatz verwenden? - Muss Ihr Formular seine Vorgänge innerhalb einer einzelnen Transaktion oder transaktionsübergreifend abschließen? - Müssen Sie in externe Systeme integriert werden? - Welche Anforderungen stellen Sie an Wiederverwendbarkeit und Modularität?
Protokoll und Aktionen Hierarchische Datenverwaltung Arbeiten innerhalb einer Transaktion Transaktionsübergreifendes Arbeiten Integration Modulares Design und Wiederverwendung Verpackung
Dynamische Formulare Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Verfügbar
Bildschirm-Flow Verfügbar Nicht verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
OmniStudio Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Nicht verfügbar
Bildschirm-Flow + LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
Der Flow bietet Standardaktionen zum Posten in Slack, Senden von E-Mails und Interagieren mit Quip-Dokumenten. Für diese Vorgänge müssen Sie keinen Code schreiben. LWC bietet umfangreiche Interaktionen mit einzelnen Datensätzen und verwandten Objekten über Wire-Adapter, die mit der [Benutzeroberflächen-API](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm) interagieren. LWC kann auch mit mehreren Datensätzen interagieren, indem der Wire für [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html) verwendet wird. LWC Interaction via Wire Adapters OmniStudio verwendet Integrationsverfahren und die Datenzuordnung, um Daten (externe und interne Daten von Salesforce) abzurufen und umzuwandeln. Dank zahlreicher codefreier Funktionen können Datensets mit verschiedenen Beziehungsebenen vereinfacht und erweitert werden. Flow, OmniStudio und LWC können alle in Apex integriert werden. Auf diese Weise können Sie ohne Weiteres Lücken in der von Ihnen ausgewählten Lösung schließen. Wenn Sie beispielsweise Datensätze aus einem LWC filtern möchten, können Sie den Wire-Adapter für Apex verwenden, um komplexe SOQL-Abfragen zu erstellen. Wenn Sie von klickbasierten Artikeln beeinflusst werden, sollten Sie Flow oder OmniStudio als praktikable Alternative zu einem Apex-Steuerfeld für Ihre serverseitigen Anforderungen verwenden. Sie sollten auch überlegen, ob Sie Aktionen sofort übernehmen oder auf einen bestimmten Teil Ihres Formulars zurückstellen möchten. Dies ist besonders relevant, wenn Sie ein mehrseitiges Formular verwenden. Mit Flow können Eingaben aus mehreren Formularen (Flow-Bildschirmen) ganz einfach kombiniert und später im Assistenten (Flow) verwendet werden, um bestimmte Vorgänge auszuführen. Genau so wird das Entwerfen von Flows empfohlen. Führen Sie am Ende Aktionen aus (falls Benutzer zwischen Bildschirmen hin- und herwechseln, um ihre Antworten zu ändern). #### Steuervorgänge Transaktionen und [Obergrenzen](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) sind integraler Bestandteil der Agentforce 360 Platform. Wenn Ihr Anwendungsfall ziemlich einfach ist, ist es möglicherweise nicht so wichtig, die Transaktion zu steuern, bei der ein bestimmter Vorgang auftritt. Es gibt jedoch einige Anwendungsfälle, in denen Sie mehrere Vorgänge in einer einzelnen [Transaktion](/docs/architect/de-de/fundamentals/guide/architecture-basics#transaktionen) kombinieren möchten, statt sie transaktionsübergreifend auszuführen. Hier einige Beispiele: - **Rollback:** Angenommen, Ihr Formular erstellt mehrere Datensätze im Hintergrund. Wenn die Erstellung eines dritten Datensatzes fehlschlägt, sollten die ersten beiden Datensätze zurückgesetzt werden? Wenn jede Ihrer Aktionen unabhängig voneinander ist, können Sie sie als separate Transaktionen ausführen. Wenn sie jedoch voneinander abhängig sind – und Sie möchten, dass die anderen durch das Fehlschlagen einer Transaktion ebenfalls wiederhergestellt werden –, sollten Sie sie als einzelne Transaktion implementieren. Wenn sich Ihr Formular im Flow befindet, können Sie das Element "Rückmeldung" im Pfad "Fehler" verwenden, um Ihre Transaktion zurückzusetzen und die Datenintegrität sicherzustellen. - **Nachgelagerte Auswirkungen auf die Obergrenzen für Gouverneure:** Wenn Ihr Formular einen Datensatz erstellt oder aktualisiert, ist es wichtig, die nachgelagerten Auswirkungen dieses Vorgangs zu berücksichtigen: - Welche Prozesse, Workflow-Regeln, Flow-Auslöser, Apex-Auslöser oder anderen Elemente innerhalb des Speicherauftrags können basierend auf den vorgeschlagenen Datensatzänderungen ausgelöst werden? - Wie wirken sich diese kollektiven Änderungen auf die Obergrenzen aus, die innerhalb dieser Transaktion verbraucht werden? - Wenn eine bestimmte Datensatzänderung zu vielen nachgelagerten Änderungen führen kann, die sich auf Ihre Obergrenzen auswirken, sollten Sie diese Datensatzänderung möglicherweise innerhalb ihrer eigenen Transaktion isolieren. - **Batchverarbeitung:** Möglicherweise müssen Sie mehrere Aktualisierungen zusammen als Batch ausführen (auch innerhalb eines Benutzeroberflächenkontexts). Angenommen, Ihr Formular mit mehreren Bildschirmen durchläuft eine große Gruppe von Datensätzen. Statt nach jedem Bildschirm eine Datensatzaktualisierung zu übernehmen – warten Sie, bis Sie die Aktualisierungen für alle Datensätze erfasst haben – und senden Sie dann eine Anforderung zur Aktualisierung aller Datensätze. Wenn Sie dynamische Formulare zum Erstellen oder Bearbeiten eines Datensatzes verwenden, führen Sie nur einen Vorgang aus und dieser Vorgang ist immer der Start einer neuen Nettotransaktion. Wenn Sie einen Bildschirm-Flow erstellen, haben Sie erhebliche Kontrolle darüber, was in einer bestimmten Transaktion vorkommt. Bildschirme und lokale Aktionen fungieren als Grenzen zwischen Transaktionen. Im Folgenden finden Sie eine allgemeine Zusammenfassung der Verwaltung von Transaktionen innerhalb der Bildschirm-Flow-Architektur. 1. Der Endbenutzer interagiert mit einem Bildschirm und klickt dann auf **Weiter**. 2. Der Client postet eine Eingabeanforderung an die API. 3. Die API empfängt die Anforderung und öffnet eine Transaktions- und Datenbankverbindung. Anschließend ruft die API das Flow-Modul auf, um die Anforderung aufzurufen. 4. Das Flow-Modul übernimmt die Funktion und folgt dem entsprechenden Pfad in der Flow-Definition, bis es auf einen Bildschirm oder einen lokalen Aktionsknoten gelangt. Anschließend gibt das Modul Informationen zu diesem Knoten an die API zurück. 5. Die API erstellt ein Antwortobjekt, das die Details des nächsten Bildschirms enthält, der dargestellt werden soll, und gibt dieses Objekt an den Client zurück. Zu diesem Zeitpunkt werden Datenbankänderungen übernommen (gemäß der [Ausführung des Speicherauftrags](/docs/architect/de-de/fundamentals/guide/architecture-basics#datenbankmanipulation)) und die Datenbankverbindung und die Transaktion werden geschlossen. 6. Der Client verwendet die API-Antwort, um den nächsten Bildschirm darzustellen, mit dem der Benutzer interagiert. 7. Beginnen Sie mit Schritt 1 und wiederholen Sie den Vorgang. Anders ausgedrückt: Bildschirme _brechen_ Transaktionen ab. In diesem Fall werden alle ausstehenden Aktionen oder DML übernommen, die vorherige Transaktion wird geschlossen und eine neue Transaktion beginnt. multi-screen flow Beachten Sie, dass die spezifischen Designelemente (die Vorgänge, die Sie in eine bestimmte Transaktion gruppieren) Ihnen überlassen sind. Hier einige Beispiele: screen flow with separate transactions - Zu Beginn wird ein Flow angezeigt, der Eingaben über mehrere Bildschirme hinweg erfasst und dann mehrere Aktionen innerhalb einer Transaktion ausführt. - Der nächste Flow führt jeden Vorgang in einer separaten Transaktion aus. - Flows können auch "Datensätze zurücksetzen" verwenden, um eine gesamte Transaktion zurückzusetzen, wenn ein einzelner Vorgang innerhalb einer Reihe von Datenbankvorgängen fehlschlägt. Screen Flow with multiple create records Angenommen, Sie verfügen über einen Flow, der Datensätze erstellt, aktualisiert und dann zusätzliche Datensätze erstellt (im nächsten Flow dargestellt). Wenn in diesem Szenario die ersten beiden Elemente erfolgreich sind und das letzte fehlschlägt, werden die entsprechenden Datensätze weiterhin durch die ersten beiden DML-Vorgänge erstellt und aktualisiert, das dritte jedoch nicht. Screen Flow with Rollback Mithilfe des Elements "Datensätze zurücksetzen" können Sie sicherstellen, dass die gesamte Transaktion zurückgesetzt wird, wenn alle drei Vorgänge zusammen ausgeführt werden müssen (wie im endgültigen Flow dargestellt). **Hinweis:** Weitere Details finden Sie unter [Flows in Transaktionen](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) und [Flow-Massenverarbeitung in Transaktionen](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm). Ihre Fähigkeit, die Transaktion über eine LWC zu steuern, basiert auf den zugrunde liegenden Services, die die LWC zum Ausführen ihrer Vorgänge verwendet. Wenn Sie die Lightning-Datensatz-Basiskomponente verwenden, erfolgt der zugrunde liegende Vorgang (Erstellen oder Aktualisieren des Datensatzes) beim Senden des Formulars innerhalb einer eigenständigen Transaktion. Im Allgemeinen gelten die folgenden Regeln: - Jeder Benutzeroberflächen-API-Aufruf ist innerhalb einer eigenen Transaktion isoliert. - Wenn Sie mehrere Vorgänge innerhalb einer einzelnen Transaktion ausführen müssen, senden Sie die Eingaben an eine serverseitige Technologie (beispielsweise ein Apex-Steuerfeld oder einen Flow). Beachten Sie, dass die regulären Transaktionsregeln für diese Technologie weiterhin gelten. #### Externe Integrationen Flow, OmniStudio und LWC unterstützen Plattformereignisse (für [ereignisgesteuerte Architektur](/docs/architect/de-de/decision-guides/guide/event-driven)) und API-Integrationen. Zusätzlich zu benutzerdefiniertem Apex Code verfügen Flow und OmniStudio über deklarative Supportmechanismen, die auch in APIs integriert werden können. Wenn Sie eine Verbindung mit einer MuleSoft-API oder einem RPA-Bot herstellen müssen, verwenden Sie MuleSoft-Services, da dadurch ein externer Service generiert wird. External integrations via MuleSoft Wenn die API über ein OpenAPI-Schema verfügt, erstellen Sie einen externen Service. External Integrations via OpenAPI Verwenden Sie für alle anderen Instanzen die Funktion "**HTTP-Callout**" (mit Unterstützung externer Services) in Flow oder die **HTTP-Aktion** in OmniStudio. External integrations via HTTP OmniStudio verfügt über eine Vielzahl von Integrationsfunktionen, die externe Systeme mithilfe von Integrationsverfahren aufrufen können, um Daten über die Datenzuordnung umzuwandeln. Unabhängig davon, ob Sie benutzerdefinierten Apex Code oder einen externen Service für die Implementierung verwenden, ist ein **Callout** weiterhin ein Callout. Folgendes müssen Sie wissen. - Die Verarbeitung eines Callouts kann viel Zeit in Anspruch nehmen. - Wenn ein Callout synchron ausgeführt wird, wird er ausgeführt, während eine Datenbanktransaktion geöffnet ist. - Salesforce erlaubt es Ihnen nicht, eine Datenbanktransaktion offen zu halten, wenn Datenbankvorgänge ausstehen. Beachten Sie, dass die Haupteinschränkung die Gefahr besteht, dass Daten in einem inkonsistenten Zustand verbleiben, was auftritt, wenn Sie einen **Erstellungs-**, **Aktualisierungs-** oder **Löschvorgang** ausführen und dann einen **Callout** innerhalb derselben Transaktion ausführen. Dieses Muster ist aufgrund der dritten oben genannten Überlegung, die aufgrund der ersten beiden Überlegungen vorhanden ist, nicht zulässig. In Flow können Sie diese Einschränkung umgehen, indem Sie die Transaktion unterbrechen. Zur Erinnerung: Bildschirme und lokale Aktionen führen den Browserkontext wieder ein. Wenn Sie mit externen Callouts arbeiten, können Sie zwar Bildschirme und lokale Aktionen verwenden, es wird jedoch empfohlen, die **Transaktionssteuerung** in den aufrufbaren erweiterten Einstellungen zu aktivieren. Mit der Transaktionssteuerung können Sie die Transaktion automatisch beenden, bevor ein Callout erfolgt. Wählen Sie zum Aktivieren der Transaktionssteuerung im Abschnitt "**Erweitert"** der aufgerufenen Aktion die Option "**Immer eine neue Transaktion starten**" aus. External Integrations via Callouts LWC vereinfacht die Auswirkungen von Callouts auf die Transaktion. Führen Sie Ihre Datenvorgänge mit dem Lightning Data Service (LDS) aus und verwenden Sie dann ein Apex-Steuerfeld, um den externen Callout vorzunehmen. Da der LDS-Aufruf innerhalb seiner eigenen Transaktion (separat vom Apex-Callout) isoliert ist, schützen Sie sich vor daraus resultierenden Dateninkonsistenzen. #### Wiederverwendbarkeit und Modularität Dynamische Formulare unterstützen die Wiederverwendung nicht. Jede ist mit einer bestimmten Lightning-Datensatzseite für ein bestimmtes Objekt verknüpft. Sie können diese Lightning-Datensatzseite jedoch mehreren Anwendungen, Profilen usw. zuweisen. Ähnlich wie beim Schreiben von Bibliotheken, Dienstprogrammen und Komponenten, die über mehrere Komponenten hinweg verwendet werden können, können Sie auch beim Erstellen von Flows ähnliche Designmuster anwenden, indem Sie die Leistungsfähigkeit von **Subflows** nutzen. Speichern Sie dazu Ihre Flows in kleineren, modularen Buckets und rufen Sie sie dann über andere Flows mit dem Element "**Subflow**" auf. Wenn Ihr Design dies erfordert, können Sie einen Flow erstellen, der alleine und als Subflow nützlich ist. OmniStudio ist von Natur aus auf Modularität ausgelegt. Datenzuordnungen, OmniScripts, FlexCards und Integrationsverfahren werden unabhängig voneinander erstellt, können jedoch auch austauschbar verwendet werden. FlexCards können auch als LWC-Komponenten erstellt werden, die in andere LWCs, OmniScripts, Datensatzseiten und Experience Cloud-Sites eingebettet werden können. Bildschirm-Flows, OmniScripts und Lightning-Webkomponenten können für die Wiederverwendung erstellt und an verschiedenen Orten eingebettet werden, einschließlich externer Sites und Lightning Out-Anwendungen. Wenn Sie Ihre Lösungen so gestalten, dass sie zusammengesetzt werden können, profitieren Sie auch von Anpassungsfähigkeit und Stabilität. ### Validierung Alle Technologien, die zum Erstellen oder Aktualisieren von Datensätzen verwendet werden, müssen sich an die Validierung auf Systemebene halten, unabhängig davon, ob es sich um klassische Validierungsregeln oder benutzerdefinierte Validierungen handelt, die in einen Apex Auslöser integriert sind. Unabhängig davon, welche Technologie Sie zum Ausführen von Datensatzänderungen verwenden, muss jede Änderung den Speicherauftrag durchlaufen. Das bedeutet, dass Datensatzänderungen zusätzlich zu Validierungsregeln auch durch eine Reihe von Flows vor oder nach dem Speichern, Vor- oder Nachauslösern, Eskalationsregeln, Zuweisungsregeln usw. verarbeitet werden. **Hinweis:** Wenn Sie dies noch nicht getan haben, überprüfen Sie die Apex[-Ausführungsreihenfolge](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) und markieren Sie sie mit einem Lesezeichen. #### Zu stellende Fragen - Verfügt Ihr Formular über zusätzliche Anforderungen, die über die Validierung auf Systemebene hinausgehen? - Müssen Sie Pflichtfelder oder schreibgeschützte Felder dynamisch im Formular festlegen?
Berücksichtigen der Validierung auf Systemebene Benutzerdefinierte Validierung auf Feldebene speziell für dieses Formular Validierung auf benutzerdefinierter Feldebene
Dynamische Formulare Verfügbar Nicht verfügbar Nicht verfügbar
Bildschirm-Flow Verfügbar Nicht verfügbar Nicht verfügbar
OmniStudio Verfügbar Verfügbar Verfügbar
Bildschirm-Flow + LWC Verfügbar Verfügbar Verfügbar
LWC Verfügbar Verfügbar Verfügbar
In der Regel sind Eingaben in einem Flow-Bildschirm oder OmniScript-Schritt nicht gebunden, sodass das Formular selbst nicht nativ an die Validierung auf Systemebene gebunden ist, die einem bestimmten Objekt zugeordnet ist. Die Werte, die Sie zum Erstellen oder Aktualisieren von Datensätzen verwenden, werden jedoch in der Speicherreihenfolge verarbeitet, d. h., sie durchlaufen die Validierung auf Systemebene des Objekts. **Hinweis:** Nicht alle Bildschirm-Flow-Komponenten unterstützen die Eingabevalidierung. Ähnlich wie bei Seitenlayouts können Sie mit dynamischen Formularen die **Erforderlichkeit** und den **schreibgeschützten** Status auf Seitenebene festlegen. Beachten Sie, dass Sie Einstellungen auf Systemebene nicht überschreiben können. Flow bietet Flexibilität beim Anpassen der Formulareingabevalidierung. Mehrere Überprüfungen werden auf Client-Ebene durchgeführt (z. B. Kennzeichnen fehlender Pflichtfelder und Datentypüberprüfungen sowie kompatible Formeln innerhalb von Eingabevalidierungsregeln). Als zusätzliche Sicherheitsebene wird die Eingabevalidierung auch auf dem Server ausgewertet. Wenn ein Benutzer auf **Weiter** klickt, sendet Flow die Eingaben erneut zur Validierung an den Server. Wenn ungültige Eingaben zurückgegeben werden, wird die Navigation blockiert und der entsprechende Fehler wird angezeigt. Der Server validiert die Eingaben, indem er Folgendes überprüft: - Die **Erforderlichkeitseinstellung** der Eingabe oder ob der eingegebene Wert mit dem zugrunde liegenden Datentyp kompatibel ist. - Die benutzerdefinierte Validierung der Eingabe. Sie müssen einen _booleschen_ Formelausdruck und eine Fehlermeldung angeben, die angezeigt werden soll, wenn der Formelausdruck nicht erfüllt ist. - Die benutzerdefinierte Validierung der zugrunde liegenden Komponente. Wenn Sie eine benutzerdefinierte LWC für einen Flow erstellen, müssen Sie der Methode validate() Ihren eigenen Validierungscode hinzufügen. Sie können Benutzer auch über die Komponente "**Nachricht"** in Bildschirm-Flows benachrichtigen, was jedoch nicht verhindert, dass ein Benutzer zu anderen Seiten navigiert oder zum nächsten Schritt in einem geführten Flow übergeht. Der _Fehlerstatus_ in der Komponente "**Meldung**" wird am besten auf speziellen Fehlerbildschirmen verwendet, die über einen Fehlerpfad ausgelöst werden, wenn die Navigation deaktiviert ist. OmniStudio bietet eine zuverlässige Fehler- und Validierungsverarbeitung über die Aktion "[Fehler festlegen](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5)" in Kombination mit [Bedingten Ansichten](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) und der Komponente "[Messaging](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5)". Bei LWC führen die meisten Basiskomponenten ihre eigenen clientseitigen Validierungen aus (beispielsweise berücksichtigt Lightning-Datensatzform die System-, nicht jedoch die Seitenebenenanforderungen). Für Ihre benutzerdefinierten Komponenten können Sie Build Your Own Validierungsmechanismen erstellen. Beachten Sie, dass Felder, für die Benutzer Daten eingeben müssen, am Anfang Ihrer Formulare angezeigt werden sollten. Validieren Sie Benutzereingaben auf Client-Seite, bevor Formulare gesendet werden (sofern möglich). ### Interaktionsdesign Statische Formulare sind veraltet. Heute liegt der Fokus auf der dynamischen Aktualisierung von Formularen mit den richtigen Eigenschaften und Werten für einen _bestimmten_ Benutzer zu einer _bestimmten_ Zeit an einem _bestimmten_ Ort. Sehen wir uns einmal genauer an, was über Salesforce-Tools zum Erstellen von Formularen möglich ist. #### Zu stellende Fragen - Welche Arten von Interaktionen oder Bedingungen sollten dynamische Antworten in Ihrem Formular auslösen? - Müssen Sie Vorgänge außerhalb des Bildschirms (im Hintergrund) ausführen, während Ihr Formular ausgefüllt wird? - Müssen Sie Felder als **sichtbar**, **erforderlich**, **schreibgeschützt** oder **deaktiviert** festlegen oder die Formatierung anhand von Formulareingaben ändern?
Ausführen von Off-Screen-Datenvorgängen Bedingte Werte und Berechnungen Bedingte Sichtbarkeit Bedingte Anforderung Bedingte Formatierung Bedingter schreibgeschützter Status Bedingter deaktivierter Status
Dynamische Formulare Nicht verfügbar Nicht verfügbar Verfügbar Nicht verfügbar Verfügbar Nicht verfügbar Nicht verfügbar
Bildschirm-Flow Verfügbar Verfügbar* Verfügbar Verfügbar Nicht verfügbar Verfügbar Verfügbar
OmniStudio Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
Bildschirm-Flow + LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
* Beschränkt auf Komponenten, die eine Ressourcenauswahl und kein statisches Kontrollkästchen verwenden
**Auf reaktiven Bildschirmen** wird die Bildschirm-Flow-Interaktivität aktiviert. Durch die Reaktivität können einzelne Komponenten auf einem Flow-Bildschirm miteinander kommunizieren, was Bildschirm-Flows leistungsfähiger macht. **Ausführen von Off-Screen-Datenvorgängen** Bildschirm-Flows bieten einen deklarativen Ansatz zum Abrufen von Daten auf demselben Bildschirm über **Bildschirmaktionen**. Mit Bildschirmaktionen können Sie automatisch gestartete Flows bei jeder Änderung auf dem Bildschirm oder wenn ein Benutzer auf eine Komponente vom Typ "**Aktionsschaltfläche**" klickt, auslösen. Sie können automatisch gestartete Flow-Ergebnisse demselben Bildschirm zuordnen, wodurch Benutzer nicht mehr zu einem anderen Bildschirm navigieren müssen. LWC bietet eine vollständige Reihe von Wire-Adaptern, die Zugriff auf Salesforce-Daten bieten, um Daten in Formularkomponenten dynamisch auszufüllen, wodurch Entwickler Datensätze über Apex-Steuerfelder **aktualisieren**, **löschen** und **erstellen** können. Lightning Web Components Off-Screen Data Operations **Sichtbarkeit** Die Sichtbarkeit kann in allen Formularerstellungstools dynamisch gesteuert werden. Dynamische Formulare, Flow Builder und OmniStudio beheben dies mithilfe von Komponentensichtbarkeitsfunktionen. Sie können Felder deklarativ **ein-** oder **ausblenden**, die auf anderen Werten im Formular basieren oder darauf, ob der Benutzer das Formular auf einem Mobilgerät ausfüllt. - Dynamische Formulare steuern die Sichtbarkeit anhand von Datensatzfeldwerten, Nachschlagefeldern und Formfaktoren. - Mit Flow können Sie eine Sichtbarkeitsregel auf anderen Bildschirmeingaben sowie anderen Ressourcen basieren, die zuvor im Flow ausgefüllt wurden (z. B. Formeln oder Werte aus anderen Datensätzen). - **Gerätebasierte Regeln:** Dies ist möglicherweise nicht von Anfang an offensichtlich. Sie können jedoch eine Formel verwenden, um ein bestimmtes Feld **ein-** oder **auszublenden**, wenn sich der Benutzer auf einem Mobilgerät befindet. Schreiben Sie eine Flow-Formel, die den Wert der globalen Variablen **$User.UIThemeDisplayed** überprüft. Wenn der Wert **Theme4t** lautet, füllt der Benutzer das Formular mithilfe der mobilen Salesforce-Anwendung aus. - **Andere Ressourcen auswerten:** Manuelle Variablen- und Formelverweise werden nur auf dem Server ausgewertet. Das bedeutet, dass der Wert, den diese Ressource beim ersten Rendern des Bildschirms aufweist, dem Wert entspricht, den sie aufweist, bis Sie zu einem anderen Bildschirm navigieren. Während der Navigation sendet die Flow-Laufzeit eine Anforderung an das Flow-Modul (den Server) und gibt die neuesten manuellen Variablen- und Formelwerte zurück. Wenn Sie erwarten, dass Ihre Sichtbarkeitsregel aktualisiert wird, während der Benutzer einen einzelnen Bildschirm durchläuft (z. B. onblur), müssen Sie sicherstellen, dass Sie nur auf Werte aus den anderen Komponenten auf dem Bildschirm verweisen. - Mit OmniStudio können Sie Komponenten bedingt **ein-** oder **ausblenden**, indem Sie die Eigenschaft "**Bedingte Ansicht**" einrichten. Sie können jedoch nicht mehr als eine Eigenschaft vom Typ "Bedingte Ansicht" für eine Eingabe hinzufügen. **Bedingte Eingabezustände** Wenn Sie andere Eigenschaften dynamisch steuern müssen (z. B. ob ein Feld **erforderlich**, **deaktiviert** oder **schreibgeschützt** ist), gibt es einige Optionen. LWC bietet vollständige, reaktive Kontrolle über Ihren Eingabestatus. Mit reaktiven Bildschirm-Flow-Komponenten können Sie Komponentenattribute (z. B. **schreibgeschützt**, **deaktiviert** und **erforderlich**) für Standardkomponenten, die sie unterstützen, dynamisch steuern, während OmniStudio das gesamte Spektrum komponentenspezifischer Attribute unterstützt. Wenn Sie aufgrund Ihrer Anforderungen Flow benötigen und die Komponente einen bestimmten Attributstatus nicht unterstützt, können Sie eine einbettbare LWC erstellen, um einen dynamischen Eingabestatus zu erreichen. Wenn Sie andere Eigenschaften dynamisch steuern müssen (z. B. ob ein Feld **erforderlich** oder **schreibgeschützt** ist), verwenden Sie LWC kurzfristig, da Sie die vollständige Kontrolle haben. Dies gilt insbesondere, wenn Sie maßgeschneiderte Anforderungen für die Handhabung von onblur oder onclick haben. **Reaktive LWCs in Bildschirm-Flows** Wenn Sie Lightning-Webkomponenten erstellen, die auf andere Komponenten in einem Bildschirm-Flow reagieren und sie ändern können, lesen Sie den Leitfaden zu den [bewährten Lightning-Webpraktiken für Bildschirm-Flows](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows), um sicherzustellen, dass Ihre Komponenten in das Flow-Laufzeitmodul integriert werden und wie vorgesehen funktionieren.
Standardmäßige Ereignisverarbeitung(Unschärfe, Fokus) Benutzerdefinierte Ereignisverarbeitung
Dynamische Formulare Nicht verfügbar Nicht verfügbar
Bildschirm-Flow Nicht verfügbar Nicht verfügbar
OmniStudio Nicht verfügbar Verfügbar*
Bildschirm-Flow + LWC Verfügbar Verfügbar
LWC Verfügbar Verfügbar
* Die OmniStudio-Standardlaufzeit unterstützt Pub/Sub nicht, Windows postMessage jedoch nicht
Bei benutzerdefinierten Ereignissen ist LWC die einzige Option, wenn einige Ihrer Eingaben (oder das gesamte Formular) mit einem anderen Element auf der Seite kommunizieren müssen. - Verwenden Sie die [Benutzeroberfläche CustomEvent](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events), um innerhalb derselben DOM-Struktur zu kommunizieren. - Verwenden Sie zum DOM-übergreifenden Kommunizieren den [Lightning Messaging Service](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel). - Wenn Lightning Messaging Service für Ihren Ziel-Container [nicht unterstützt wird](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations), verwenden Sie das Modul "Pub/Sub". #### Zusätzliche Ressourcen für das Interaktionsdesign - Detailliertere Informationen finden Sie im _Lightning Web Components Dev Guide_ unter [Communicate with Events](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) and [Communicate Across the DOM](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub) (Mit Ereignissen kommunizieren). - Informationen zu OmniStudio finden Sie unter [Mit OmniScript über eine Lightning Webkomponente kommunizieren.](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5) ### Stil Um die beste Benutzererfahrung zu bieten, müssen Sie sicherstellen, dass Ihr Formularstil mit dem Rest der Anwendung oder Site, auf der er eingebettet wird, konsistent ist. Dies kann die Verwendung von Standardvorlagen bedeuten, die von Salesforce bereitgestellt werden, oder die Erstellung eines benutzerdefinierten CSS, das jedes Pixel im Design verwendet, um ein schärferes Erscheinungsbild zu bieten. #### Bildschirm-Flow-Gestaltungsüberschreibungen Administratoren können einen begrenzten Satz an Bildschirm- und Komponentenstilüberschreibungen (z. B. Farben, Rahmen und Schaltflächenerscheinungen) für den Bildschirmcontainer oder für einzelne Komponenten konfigurieren. Diese Überschreibungen werden nach Themen und Branding angewendet, wodurch Generatoren gezielte visuelle Anpassungen vornehmen können, ohne dass sich dies auf den Rest der Anwendung auswirkt. Gestaltungsüberschreibungen sind für lokalisierte visuelle Ausnahmen vorgesehen (z. B. Hervorhebung eines Bestätigungsbildschirms oder Hervorhebung einer bestimmten Handlungsaufforderung). Sie sind kein vollständiges Gestaltungssystem. Sie bieten keine Kontrolle auf CSS-Ebene und sind nicht für die Wiederverwendung auf Bildschirmen oder Flows vorgesehen. Aus architektonischer Sicht sollte der Stil der folgenden Präzedenzreihenfolge folgen: 1. **Themen und Branding:** Lightning-Themen, Erfahrungsgenerator-Brandingsätze oder LWR-Site-Themen 2. **Überschreibungen des Flow-Stils:** Gezielte Bildschirm- oder Komponentenanpassungen 3. **Benutzerdefinierte Komponenten (LWC):** wenn pixelgenaue Steuerung oder wiederverwendbare Designmuster erforderlich sind Die Verwendung von Themen und Designsystemen trägt dazu bei, sicherzustellen, dass der Stil im Laufe der Zeit konsistent, skalierbar und einfach zu pflegen bleibt. #### Zu stellende Fragen - Wie anspruchsvoll ist Ihr gewünschter Stil und CSS? - Sie benötigen einen benutzerdefinierten, pixelgenauen Stil oder Standardthemen?
Direkter Stil Organisations- und Erfahrungsgeneratorthemen Pixel-perfekter Stil
Dynamische Formulare Nicht verfügbar Verfügbar Nicht verfügbar
Bildschirm-Flow Nicht verfügbar Verfügbar Verfügbar**
OmniStudio Verfügbar* Nicht verfügbar Verfügbar
Bildschirm-Flow + LWC Nicht verfügbar Verfügbar Verfügbar
LWC Nicht verfügbar Verfügbar Verfügbar
* Nur FlexCards

** Bestimmte Stilattribute können für Bildschirmkomponenten konfiguriert werden, jedoch nicht für CSS-Überschreibungen.
FlexCards ist das einzige Produkt in diesem Handbuch, mit dem Sie den Stil und das Layout der Benutzeroberfläche, die Sie im Tool erstellen, deklarativ steuern können (z. B. Ränder und Innenabstände, Typografie, Farben usw.). Dynamische Formulare und Flows berücksichtigen deklarative Themenfunktionen. Wenn Sie zusätzliche Kontrolle benötigen (über die Unterstützung von [Salesforce-Themen](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), [Erfahrungsgenerator-Brandingsätzen](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm) oder [LWR Experience Cloud-Sites](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm) hinaus), sollten Sie eine programmgesteuerte Lösung in Betracht ziehen. Teams, die mit CSS vertraut sind, haben mehrere Optionen: - Flows und Lightning-Webkomponenten übernehmen [Standarddesigntoken](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm). - OmniScripts und FlexCards enthalten die anpassbare Unterstützung des Designsystems über [Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5). - Mit LWC können Sie Ihre eigenen Komponenten schreiben und deren HTML und CSS vollständig steuern. Wenn möglich, sollten Sie Themen und Designsysteme verwenden, um ein einheitliches Erscheinungsbild für alle Ihre Inhalte zu gewährleisten. **Hinweis:** Lightning-Komponenten können in Flows eingebettet werden. Wenn Sie das Erscheinungsbild Ihres Formulars pixelgenau steuern möchten, aber auch die anderen Vorteile von Flows (z. B. das Navigationsmodell) nutzen möchten, können Sie das Beste aus beiden Welten herausholen. Das gleiche Prinzip gilt für OmniScripts und FlexCards. ### Layout Die Auswahl eines guten Layouts ist entscheidend für das Entwerfen optimierter Formulare, die eine schnelle und effiziente Dateneingabe ermöglichen und die Datenintegrität erhöhen. #### Zu stellende Fragen - Wie können Sie Formularlayouts strukturieren, um die Benutzererfahrung zu optimieren? - Wie können Sie Benutzern vorhandene Daten so präsentieren, dass sie leichter neue Daten in Ihre Formulare eingeben können?
2 Spalten 4 Spalten Jenseits von 4 Spalten Wiederholen von Datenblöcken Registerkartencontainer Akkordeonbehälter
Dynamische Formulare Verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Verfügbar Verfügbar
Bildschirm-Flow Verfügbar Verfügbar Nicht verfügbar Verfügbar Nicht verfügbar Verfügbar
OmniStudio Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar* Verfügbar
Bildschirm-Flow + LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
* Registerkarten können verwendet werden, wenn Daten in eine FlexCard in ein OmniScript eingebettet werden
Dynamische Formulare unterstützen zweispaltige Layouts, die in einzelne Abschnitte in Feldern unterteilt werden können. Diese Abschnitte können in Komponenten (z. B. Registerkarten und Akkordeons) platziert werden, um organisierte und benutzerfreundliche Layouts zu erstellen. Flows können auch mithilfe der Komponente "**Abschnitt"** dargestellt werden. Sie können bis zu vier Spalten und eine unbegrenzte Anzahl von Abschnitten auf dem Flow-Bildschirm hinzufügen. Die Komponente "Abschnitte" reagiert auch auf die Bildschirmbreite und funktioniert daher auch auf kleineren Bildschirmen. Sie bietet Ihnen die Möglichkeit, die bedingte Sichtbarkeit auf den gesamten Abschnitt anzuwenden, was die Massenanwendung der Sichtbarkeit auf mehrere Felder innerhalb des Abschnitts vereinfacht. **Flow-Abschnitte** unterstützen auch Spaltenüberschriften und bieten eine Akkordeon-ähnliche Erfahrung, bei der Benutzer den gesamten Abschnitt durch Klicken auf die Bezeichnung ausblenden können. OmniScripts verfügen über eine Vielzahl von Layoutoptionen zum Anzeigen von Feldern und Daten. Sie können Datenabschnitte mit bis zu 12 Spalten erstellen, einschließlich bedingt ausblendbarer Akkordeons. Mit LWC können Sie Lightning-record-\[edit\|view]-form und das unterstützende Lightning\[input\|output]-Feld verwenden, um das Layout zu steuern. Die einzigen Layouteinschränkungen stammen aus HTML und CSS. Die Komponente **Lightning-Datensatzform** berücksichtigt die Abschnittskonfiguration im zugeordneten Seitenlayout (wenn ein Abschnitt beispielsweise im Seitenlayout zweispaltig ist, ist er auch in der Komponente zweispaltig). ### Translation Wenn Benutzer in verschiedenen Regionen oder Sprachen auf Ihr Formular zugreifen können müssen, müssen Sie sicherstellen, dass das Tool, das Sie zum Erstellen verwenden, Ihre Lokalisierungsanforderungen erfüllt. **Hinweis:** Insbesondere bei Formularen beinhalten Lokalisierungsanforderungen in der Regel die Übersetzung von Textelementen in andere Sprachen. #### Zu stellende Fragen - Wird Ihr Formular in mehreren Ländern oder Regionen verwendet? - Muss der Text in Ihrem Formular in andere Sprachen übersetzt werden?
Im Generator eingegebene Bezeichnungen Bezeichnungen im Code
Dynamische Formulare Verfügbar* Nicht verfügbar
Bildschirm-Flow Verfügbar Verfügbar
OmniStudio Verfügbar Verfügbar
Bildschirm-Flow + LWC Verfügbar Verfügbar
LWC Nicht anwendbar Verfügbar
* Nur Feldabschnittsüberschriften
Wenn Sie benutzerdefinierte Felder lokalisieren, berücksichtigen dynamische Formulare die übersetzten Bezeichnungen. Dynamische Formulare berücksichtigen auch alle [benutzerdefinierten Bezeichnungen,](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5) die Komponentenbezeichnungen und Attributen im Lightning-Anwendungsgenerator zugewiesen sind. Der Flow unterstützt die Übersetzung von benutzerdefinierten Bezeichnungen für alle standardmäßigen und benutzerdefinierten Bildschirmkomponenten über die Übersetzungsworkbench. Sie können Bezeichnungen, Hilfetext und Fehlermeldungen für die folgenden Bildschirmkomponenten lokalisieren: - Text - Langer Textbereich - Nummer - Währung - Kontrollkästchen - Optionsfelder - Auswahlliste - Mehrfachauswahlliste - Kontrollkästchen Gruppenkennwort - Datum - Datum/Uhrzeit Für vorkonfigurierte Aktionen (z. B. "E-Mail senden" oder "Bei Chatter posten") gibt es keine integrierte Übersetzungsunterstützung. Es gibt jedoch eine Übergangslösung. Wenn Sie eine [benutzerdefinierte Bezeichnung](https://help.salesforce.com/articleView?id=cl_about.htm) zum Definieren der übersetzten Bezeichnungen verwenden, können Sie bei der Konfiguration in Flow Builder in der Aktion oder Komponente auf diese benutzerdefinierte Bezeichnung verweisen. Dazu müssen Sie eine Flow-Formel erstellen, die auf die benutzerdefinierte Bezeichnung verweist, und dann an den entsprechenden Stellen in Ihrem Flow auf diese Formel verweisen. OmniScripts verwenden benutzerdefinierte Bezeichnungen für Übersetzungen. Weitere Informationen finden Sie in [diesem Hilfedokument](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm), um sicherzustellen, dass Ihre OmniScripts mehrsprachig sind. Bei LWC übernehmen bestimmte Basiskomponenten automatisch Übersetzungen der Felder, Hilfetexte und Validierungsmeldungen des zugeordneten Objekts, wenn sie in der Übersetzungsworkbench konfiguriert sind (z. B. Lightning-Datensatzform). Wenn Sie neue übersetzbare Bezeichnungen in Ihren Code einfügen müssen, sind benutzerdefinierte Bezeichnungen die richtige Wahl. Deklarieren Sie die benötigte benutzerdefinierte Bezeichnung und importieren Sie sie dann aus dem Umfangsmodul "`@salesforce/label`" in Ihre Komponente. ## Nicht funktionale Überlegungen In diesem Abschnitt können Sie Sicherheits-, Qualitäts- und Betriebseinschränkungen vor der Implementierung bewerten. ### Sicherheit Sicherheit ist ein komplexes Thema. Beim Erstellen von Formularen gibt es einige Überlegungen, die möglicherweise nicht offensichtlich sind. Auf der grundlegenden Ebene müssen Sie sicherstellen, dass das Formular im richtigen Kontext ausgeführt wird und dass die Benutzer über die Berechtigungen verfügen, die sie für die Arbeit mit den zugrunde liegenden Daten benötigen. Darüber hinaus können Sie auch zusätzliche Maßnahmen ergreifen, um potenziell bösartigen Code oder URLs aus Rich-Text-Feldern zu entfernen, bestimmte Benutzer am Zugriff auf das Formular zu hindern oder Einschränkungen hinsichtlich der Standorttypen festzulegen, an denen Administratoren das Formular in Zukunft potenziell einbetten können. Dokumentieren Sie Ihre Sicherheitsanforderungen sorgfältig, bevor Sie ein Tool auswählen. Weitere Anleitungen zu diesem Dokumentationstyp finden Sie in der Salesforce [Well-Architected Security Policy Template](/docs/architect/de-de/resources/guide/security-policy-template). #### Zu stellende Fragen - Soll das Formular den Zugriff des Benutzers überprüfen, bevor bestimmte Vorgänge ausgeführt werden? - Sollten Sie Benutzereingaben bereinigen? - Möchten Sie steuern, wer auf das Formular zugreifen kann? - Möchten Sie steuern, wo das Formular eingebettet werden kann?
Erhöhen von Benutzerberechtigungen Steuern, wer Zugriff hat Zulässige Standorte einschränken
Dynamische Formulare Nicht verfügbar Verfügbar Nicht verfügbar
Bildschirm-Flow Verfügbar Verfügbar Nicht verfügbar
OmniStudio Nicht verfügbar Verfügbar Nicht verfügbar**
Bildschirm-Flow + LWC Verfügbar Verfügbar Nicht verfügbar
LWC Verfügbar* Verfügbar Verfügbar
* Erfordert Apex

**OmniScripts können zwar keine angegebenen Zielstandorte aufweisen, FlexCards jedoch schon.
#### Erhöhen von Benutzerberechtigungen Wenn ein Programm im **Benutzerkontext** ausgeführt wird, erzwingt Salesforce eine Reihe von Zugriffsprüfungen, einschließlich der Überprüfung der Feldebenensicherheit, der CRUD-Berechtigungen und des Datensatzzugriffs auf der Grundlage der Freigaberegeln Ihrer Organisation (beispielsweise können Benutzer nur dann ein Formular zur Kundenvorgangsaktualisierung ausführen, wenn sie Kundenvorgänge aktualisieren können, die entsprechende Feldebenensicherheit und Zugriff auf den betreffenden Datensatz haben). Was geschieht, wenn Benutzer einen bestimmten Vorgang ausführen können sollen, wenn sie Ihr Formular verwenden, jedoch nicht über ein anderes Formular oder eine andere Interaktion? Hier kommt **der Systemkontext** ins Spiel! Mit **dem Systemkontext** können Sie die Berechtigungen eines Benutzers für die Dauer der Sitzung erhöhen (beispielsweise muss der Benutzer den Zugriff auf das Kundenvorgangsobjekt nicht aktualisieren, um das Formular zur Kundenvorgangsaktualisierung erfolgreich auszufüllen). Dies ist besonders für nicht authentifizierte Communities nützlich. Statt Gastbenutzern potenziell gefährliche Funktionen zu gewähren, legen Sie fest, dass Ihr Formular im Systemkontext ausgeführt wird. Systemkontext sollte nur verwendet werden, wenn dies unbedingt erforderlich ist. Wenn ein Formular im Systemkontext ausgeführt wird, umgeht jeder CRUD-Vorgang die Sicherheits- und Freigabekomponenten auf Objekt- und Feldebene. Außerdem hat der Systemkontext keine Auswirkungen darauf, wer von Salesforce als _Akteur_ betrachtet wird (der Name, der im Feld "**Zuletzt geändert von**" angezeigt wird). Für jeden Vorgang, den Ihr Formular ausführt (z. B. eine Kundenvorgangsaktualisierung), ist der _Akteur_ der aktuelle Benutzer (auch wenn das Formular in einem anderen Kontext ausgeführt wird). **Hinweis:** Dynamische Formulare, OmniScripts und Lightning-Webkomponenten werden immer im Benutzerkontext ausgeführt und es gibt keine Möglichkeit, dieses Verhalten zu überschreiben. Bildschirm-Flows werden standardmäßig im Benutzerkontext ausgeführt. Sie können sie jedoch so festlegen, dass sie im Systemkontext ausgeführt werden. Sie können entscheiden, ob der Flow Zugriff auf alle Daten erteilen oder den Zugriff auf Datensatzebene erzwingen soll. - Wenn Sie eine Lightning-Komponente in einen Flow einbetten, der im Systemkontext ausgeführt wird, überschreibt der Flow den Kontext der Komponente nicht. Wenn Sie Benutzerzugriffsprüfungen umgehen müssen, verwenden Sie den Flow, um diese Vorgänge auszuführen und die entsprechenden Daten an die Lightning-Komponente weiterzugeben. Einige vorkonfigurierte Komponenten (z. B. "Nachschlagen") können nicht im Systemkontext verwendet werden. - Wenn Ihr Flow Apex-Aktionen aufruft, sind andere Nuancen beteiligt. - Wenn die Apex-Klasse auf "_Freigabe übernommen_" festgelegt ist, wird sie im Systemkontext mit Freigabe ausgeführt, unabhängig davon, wie der Flow festgelegt ist. - Wenn die Klasse keine explizite Freigabedeklaration aufweist, wird sie im Systemkontext ohne Freigabe ausgeführt, unabhängig davon, wie der Flow festgelegt ist. - Wenn die Klasse _mit oder ohne Freigabe_ festgelegt ist, wird der Kontext des Flows überschrieben. **Abfragen von Datensätzen im Systemkontext mit Experience Cloud-Sites** Wenn Sie einen Flow im Systemkontext auf einer Experience Cloud-Site ausführen (insbesondere wenn er nicht authentifiziert ist), speichern Sie nur bestimmte Felder in Ihren Elementen vom Typ "**Datensätze abrufen**". Wenn Sie mit Flow arbeiten und die Ergebnisse eines Elements vom Typ "**Datensätze abrufen**" an einen Subflow, eine aufrufbare Aktion oder eine Lightning-Komponente übergeben, werden möglicherweise alle Felder aus diesem Objekt von den Entwicklertools des Browsers überprüft. Trotz Ihrer Absichten werden Experience Cloud-Benutzern dadurch möglicherweise Felder zur Verfügung gestellt. Geben Sie diese spezifischen Felder in den Elementen vom Typ "**Datensätze abrufen**" an, um sicherzustellen, dass bei aktiviertem Systemkontext nur die richtigen Felder angezeigt werden. **Hinweis:** Die OmniScript-Logik wird clientseitig ausgeführt. Dadurch können Angreifer die erwartete Ausführung eines OmniScripts ändern und Antworten auf Aufrufe von Integrationsverfahren, Datenzuordnungen und Apex-Methoden über die Entwicklertools des Browsers anzeigen. Wenn Sie OmniScript verwenden, ist es wichtig, Geschäftslogik serverseitig auszuführen (sofern möglich) und Eingabevalidierungsregeln für alle Apex-Methoden zu implementieren, die über die Anmerkung [@InvocableMethod](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5) verfügbar gemacht werden. **Sanitäreingaben** Verwenden Sie die Eingabebereinigung, um Ihre Organisation vor schlechten Akteuren zu schützen. Angenommen, Sie verfügen über eine Eingabe in einem öffentlich zugänglichen Formular, das einem **Rich-Text**-Feld in Ihrer Organisation zugeordnet werden kann. Möglicherweise sollten Sie die Automatisierung aktivieren, die HTML entfernt, die schädliche URLs ausblenden kann. Es ist nicht ideal, die Bereinigung auf Formularebene zu implementieren, da Sie möglicherweise über eine beliebige Anzahl von Quellen verfügen, die in diese Felder schreiben. Erstellen Sie einen Flow für die **schnelle Feldaktualisierung (Vor dem Speichern)** oder verwenden Sie einen vorhandenen **Apex-Auslöser**, um mögliche HTML-Elemente, die in das Formular eingegeben werden können, zu entfernen oder zu ändern. #### Bewährte Vorgehensweisen - Lassen Sie zu, dass Flows in ihrem Standardkontext ausgeführt werden (es sei denn, Sie müssen den Zugriff des aktuellen Benutzers für einen bestimmten Vorgang erhöhen). - Vermeiden Sie die Ausführung von Flows im Systemkontext für Gastbenutzer. Erstellen Sie Berechtigungssätze mit eingeschränktem Feldzugriff und weisen Sie sie dem Profil des Experience Cloud-Gastbenutzers zu. - Wenn Sie Datensätze in Systemkontextausführungs-Flows auf Experience Cloud-Sites abfragen, speichern Sie nur die Felder, die Sie im Element "**Datensätze abrufen**" oder "**Aufrufbare Aktionen"** benötigen. - Wenn ein Flow eine Vielzahl von Vorgängen ausführt, für die kein erhöhter Zugriff erforderlich ist, verwenden Sie Subflows, um die Vorgänge zu isolieren, die im Systemkontext ausgeführt werden sollten. - Wenn Sie ein Formular in eine externe Webseite einbetten, muss es möglicherweise **Rich-Text**-Feldern zugeordnet werden, um potenzielle Phishing-Angriffe zu verhindern. Bereinigen Sie dazu Benutzereingaben, um HTML mithilfe eines **Flows für schnelle Feldaktualisierungen** oder **Apex Triggers** zu entfernen. #### Zusätzliche Hinweise - OmniScripts, FlexCards und LWCs werden standardmäßig im Benutzerkontext ausgeführt. - LWCs werden standardmäßig im Benutzerkontext ausgeführt. - Flows werden im Benutzerkontext ausgeführt. Sie können sie jedoch mithilfe eines Apex-Steuerfelds überschreiben. - Vorgänge, die innerhalb der Benutzeroberflächen-API ausgeführt werden, werden im Benutzerkontext ausgeführt. - Vorgänge, die mit einem Apex Steuerfeld ausgeführt werden, hängen von der jeweiligen Klasse ab. Um diese Vorgänge im Systemmodus auszuführen, legen Sie die **Apex-Klasse** mit oder ohne Freigabe fest. #### Zugriffssteuerung Wenn Sie steuern möchten, wer auf ein Formular zugreifen kann, überprüfen Sie den Container, in den das Formular eingebettet ist (beispielsweise können Sie Lightning-Seiten zuweisen, damit sie für bestimmte Anwendungen, Datensatztypen oder Profile verfügbar sind). Wenn bestimmte Eingaben vertraulich sind, können Sie mithilfe von Sichtbarkeitsregeln weiter steuern, was wem angezeigt wird. Diese Funktion gilt für dynamische Formulare und Bildschirm-Flows. Sie können [einen Flow einschränken](https://help.salesforce.com/articleView?id=flow_distribute_security.htm) auf bestimmte Profile oder Berechtigungssätze (ähnlich wie Apex-Klassen- oder Visualforce-Seiten). Flows sind standardmäßig uneingeschränkt. Das bedeutet, dass jeder Benutzer mit der Benutzerberechtigung "**Flows ausführen**" darauf zugreifen kann. Wenn Sie OmniStudio verwenden, können Sie eine Berechtigungsprüfung für [Apex-Klassen](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5) konfigurieren, bei der Benutzer expliziten Zugriff auf die Apex-Klasse benötigen, die Remote-Aktionen über OmniScript-, FlexCard-, Classic Card- oder REST-APIs verwaltet. **Hinweis:** Berechtigungsprüfungen für Apex-Klassen gelten nur für Apex-Klassen. Es empfiehlt sich auch, Berechtigungen auf Profilebene für [Integrationsverfahren und Datenzuordnungen](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5) festzulegen. #### Bewährte Vorgehensweisen für die Zugriffssteuerung - Wenn Sie Gastbenutzern einen Flow zur Verfügung stellen, sollten Sie nur Gastbenutzerprofilzugriff auf die Flows gewähren, die sie unbedingt benötigen. Es ist möglich, Gastbenutzerprofilen **"Flows ausführen**" hinzuzufügen. Diese Vorgehensweise kann jedoch riskant sein. - Gehen Sie beim Arbeiten mit Flows, die im Systemkontext ausgeführt werden, mit Bedacht vor. Sie sollten diese Flows auf einen bestimmten Satz von Benutzern beschränken, da sie weniger Überprüfungen und Abwägungen zum Schutz Ihrer Daten aufweisen. - Stellen Sie sicher, dass jedes OmniScript, das Apex in einer Gastbenutzer-Community ausführt, in der Apex-Klassendefinition **mit Freigabe** aufgeführt ist. - Weisen Sie für Gastbenutzerprofile nur die Apex-Klassen zu, die Gastbenutzer aufrufen können sollen. Durch diese Vorgehensweise wird verhindert, dass Gastbenutzern versehentlich zusätzliche Geschäftslogik angezeigt wird. Bei LWCs können Sie die Berechtigungszuweisungen des aktuellen Benutzers überprüfen, um zu überprüfen, ob er über eine bestimmte Standard- oder benutzerdefinierte Berechtigung verfügt. Sie können Salesforce-Berechtigungen direkt in **JavaScript** aus den `@salesforce/userPermission`- und `@salesforce/customPermission` importieren. Sie können auch Apex verwenden, um Berechtigungen zu überprüfen. #### Einbetten von Steuerelementen LWCs sind nur an einem bestimmten Ort verfügbar, nachdem sie als gültiges [Ziel](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) hinzugefügt wurden (beispielsweise können Sie eine Komponente auf Datensatzseiten und nicht als Dienstprogrammleistenelement verfügbar machen). Sobald ein Bildschirm-Flow aktiviert ist, ist er an allen Orten verfügbar, an denen Bildschirm-Flows unterstützt werden. Flow Builder unterstützt mehrere Typen von Flows mit Bildschirmen. Der prominenteste Typ ist **Bildschirm-Flow**. Es gibt jedoch einige andere spezialisierte Typen, die auf bestimmte Standorte beschränkt sind (beispielsweise unterstützt die **Field Service Mobile-Anwendung** nur **Field Service Mobile-Flows)**. Dies ähnelt **Kontaktanforderungs-Flows**, die nur in Experience Cloud unterstützt werden. Unabhängig vom Flow-Typ hat die Person, die den Flow erstellt, keine Kontrolle darüber, wo der Flow eingebettet ist. Flows sind an allen Standorten verfügbar, an denen dieser bestimmte Flow-Typ unterstützt wird. Wenn Sie Salesforce-Branchen verwenden, gibt es in Bezug auf OmniScript einige Einschränkungen.Es ist nicht möglich, ein Ziel für ein OmniScript anzugeben. Sie können jedoch ein Ziel für die FlexCards angeben, die Sie einbetten möchten. ### Benutzeroberflächentestautomatisierung Bei Salesforce gibt es mehrere durchgängige Testautomatisierungstools (beispielsweise [Salesforce UTAM](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam)), mit denen Sie simulieren können, wie ein Benutzer mit Ihren Formularen interagiert. Sie können Tests für jede standardmäßige oder benutzerdefinierte Benutzeroberfläche schreiben, einschließlich Lightning-Seiten und Bildschirm-Flows. **Hinweis:** Diese Testtypen können die Ausgaben für die ausgeführten Methoden nicht überprüfen. Beachten Sie dies beim Konfigurieren Ihrer Anforderungen an die Benutzeroberflächentestautomatisierung. #### Zu stellende Fragen - Benötigen Sie automatisierte Tests für Ihre Formulare? - Welche Arten von Tests planen Sie durchzuführen? - Welche Granularität ist für Testautomatisierungen erforderlich?
Einheitentests Durchgängige Automatisierung
Dynamische Formulare Nicht verfügbar Verfügbar*
Bildschirm-Flow Nicht verfügbar Verfügbar*
OmniStudio Verfügbar* Verfügbar*
Bildschirm-Flow + LWC Verfügbar* Verfügbar*
LWC Verfügbar Verfügbar
* Erfordert Code
**Berücksichtigen der Anforderungen an die Testautomatisierung auf der Benutzeroberfläche** **Einheitentests** bieten eine detaillierte Automatisierung und Validierung, die mit den CI/CD-Standardsystemen und -Tools der Branche in Einklang steht, die die Geschäftslogik, JavaScript-Steuerelemente und -Ausgaben bestimmter Komponenten testen. Wenn Sie sich für einen Low-Code-Ansatz entscheiden, können Sie keine Tests selbst erstellen. Salesforce testet jedoch alle durchgängigen Angebote sorgfältig. Wenn die Methoden Ihrer Komponente komplex sind, können Sie sie einzeln per SMS senden, indem Sie die Methoden in dedizierte JavaScript-Dateien einfügen. Dadurch können Sie sie in eine LWC importieren und dann in einen **Jest-Test (beispielsweise** importieren Sie { sort } aus 'c/utils';). Sie können eine No-Code-Lösung aus einem ISV verwenden, eine benutzerdefinierte Testautomatisierungslösung erstellen oder ein Open-Source-Test-Framework (z. B. Selenium WebDriver oder WebdriverIO) für die durchgängige Automatisierung verwenden. Diese Lösungen sind für alle Interaktionen auf der Salesforce-Benutzeroberfläche gültig (beispielsweise ein dynamisches Formular auf einer Lightning-Seite, ein Bildschirm-Flow auf einer Dienstprogrammleiste oder eine Lightning-Webkomponente in einem Schnellaktions-Flow). ### Kennzahlen Nachdem Sie Ihr Formular in einer Produktionsumgebung bereitgestellt haben, müssen Sie sicherstellen, dass es effektiv verwendet wird. Je nach Anwendungsfall kann dies bedeuten, dass Sie verfolgen können, wie oft Ihr Formular ausgefüllt wurde, bis der durchschnittliche Benutzer das Formular ausfüllt, bevor er seine Informationen sendet. Es ist wichtig, dass Sie Ihre nachverfolgbaren KPIs identifizieren, bevor Sie ein Tool auswählen. #### Zu stellende Fragen - Müssen Sie die Formularnutzung verfolgen? - Welche KPIs können bestimmen, ob das Formular effektiv verwendet wird?
Seitenaufrufe Zeitaufwand für Formular Verfolgen des Formularabschlusses Verfolgen der Erfolgsrate
Dynamische Formulare Verfügbar** Nicht verfügbar Nicht verfügbar Nicht verfügbar
Bildschirm-Flow Verfügbar Verfügbar* Verfügbar Verfügbar
OmniStudio Verfügbar Verfügbar* Verfügbar Verfügbar
Bildschirm-Flow + LWC Verfügbar Verfügbar* Verfügbar Verfügbar
LWC Verfügbar** Verfügbar* Verfügbar Verfügbar
*Verfügbar, wenn die paketbasierte OmniStudio-Laufzeit aktiviert ist** Verfügbar durch Verfolgen der Nutzung übergeordneter Lightning-Seiten
Verwenden Sie Low-Code-Tools, um die Nutzung und Akzeptanz von Formularen insgesamt zu verfolgen. Dynamische Formulare und Bildschirm-Flows können über vorkonfigurierte benutzerdefinierte Berichte verfolgt werden. Berichte zur Bildschirm-Flow-Verfolgung bieten jedoch zusätzliche Granularität. Wenn Sie die LWC-Nutzung verfolgen müssen, hängt die vorkonfigurierte Verfügbarkeit davon ab, wo Sie die LWC verwenden. Wenn sie sich auf einer Lightning-Seite befindet, gelten alle verfügbaren Elemente zur Verfolgung der Nutzung von Lightning-Seiten auch für Ihre Lightning-Seiten. Dies gilt auch für LWCs, die in Flows eingebettet sind. Dynamische Formulare können nicht vorkonfiguriert verfolgt werden. Sie können jedoch die Nutzung der übergeordneten Lightning Seite über [Lightning Nutzungsobjekte](https://help.salesforce.com/articleView?id=lex_usage_reports.htm) verfolgen. Verwenden Sie zum Verfolgen von Lightning Standardseiten den benutzerdefinierten Bericht "Kennzahlen für **Lightning-Nutzung nach Seite**". Verwenden Sie für benutzerdefinierte Lightning-Seiten den benutzerdefinierten Bericht **Users with Lightning Usage by FlexiPage Metrics**. Mit Flows können Sie die Akzeptanz für bestimmte Formulare verfolgen. Verwenden des **Beispiel-Flow-Berichts: Bildschirm-Flows** zum Beantworten der folgenden Fragentypen: - Wie hoch ist die Abschlussrate für dieses Formular? Ist es derzeit gut angenommen? - Wie lange dauert das Ausfüllen dieses Formulars? - Auf welchem Bildschirm verbringen Benutzer die meiste Zeit? - Wie oft navigieren Benutzer zu vorherigen Bildschirmen? - Wie oft treten Fehler auf? Wenn der Standardbericht Ihre Anforderungen nicht erfüllt, können Sie ihn duplizieren und Änderungen vornehmen oder mit dem Bericht "**Bildschirm-Flows**" einen neuen Bericht Build Your Own erstellen. Wenn Sie die paketbasierte OmniScript-Laufzeit verwenden, können Sie auch den [Service OmniStudio für die](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5) Vlocity-Verfolgung verwenden. Dieser Service verfolgt alle Arten von Ereignissen (beispielsweise können Sie die Zeit verfolgen, die zum Abschließen der Schritte erforderlich ist, in einem OmniScript, wodurch Prozessverbesserungen identifiziert werden können). **Hinweis:** Es gibt keine vorkonfigurierte Option zum Verfolgen einer LWC, die nicht in einen Bildschirm-Flow, ein OmniScript oder eine Lightning-Seite eingebettet ist. Sie können jedoch mithilfe von Apex eine benutzerdefinierte Lösung erstellen. ### Paketerstellung und Bereitstellung Möglicherweise sind Sie mit der Verwendung von Änderungssets oder dem **DevOps Center** vertraut, um Ihre Lösung in Testumgebungen oder in der Produktion bereitzustellen. Diese Bereitstellungsoptionen unterstützen dynamische Formulare, Flows und LWCs vollständig. OmniStudio benötigt jedoch ein separates Tool, die [IDX Workbench](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5). #### Zu stellende Fragen - Wie möchten Sie das Formular bereitstellen? - Muss das Formular an mehrere Salesforce-Organisationen verteilt werden?
Verwaltete Pakete der ersten Generation (1GP) Verwaltete Pakete der zweiten Generation (2GP) Entsperrte Pakete Änderungssets DevOps Center
Dynamische Formulare Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
Bildschirm-Flow Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
OmniStudio Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar* Nicht verfügbar*
Bildschirm-Flow + LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
LWC Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
* Verwenden Sie die IDX-Workbench, um OmniStudio-Lösungen in anderen Organisationen bereitzustellen.
Wenn Sie ein ISV oder Partner sind und planen, Ihre Lösung für die Verteilung auf AppExchange zu bündeln, sollten Sie sich Dynamische Formulare, Flows und LWCs ansehen. Beachten Sie, dass OmniStudio die Paketerstellung nicht unterstützt. ### Navigieren im Low-Code-Kontinuum zu Pro-Code Dieser Leitfaden soll Ihnen zeigen, welche Funktionen und Anpassungsebenen über dynamische Formulare, Bildschirm-Flows, OmniStudio und LWC verfügbar sind. Low-Code to Pro-Code Continuum Hier finden Sie eine allgemeine Übersicht. - Wenn es um das Erstellen von Formularen geht, ist LWC die robusteste und anpassbarste Option, verfügt jedoch über die wenigsten vorhandenen Leitplanken. Daher ist es wichtig, dass Sie Ihre Komponenten unter Berücksichtigung von [Sicherheit](/docs/architect/de-de/well-architected/guide/trust.html) und [Skalierbarkeit](/docs/architect/de-de/well-architected/guide/reliability.html#scalability-and-capacity-planning) erstellen. - Dynamische Formulare sind die am wenigsten flexible Option, es gibt jedoch viel weniger Möglichkeiten für Fehltritte. - Flow und OmniStudio liegen leicht in der Mitte. Sie sind leistungsfähiger als dynamische Formulare, aber sie sind nicht ganz auf der LWC-Ebene. Sie verfügen jedoch über weniger Leitplanken als dynamische Formulare und sind schwerer zu knacken als benutzerdefinierter Code. Sie werden feststellen, dass mehrere Tools Ihren Anforderungen entsprechen. Wenn ja, hängt die Entscheidung letztlich davon ab, welches Tool für Ihr Team am besten geeignet ist. Weitere Informationen zu zusätzlichen Aspekten finden Sie in den folgenden [Entscheidungsleitfäden für Architekten](/docs/architect/de-de/decision-guides). #### Zu stellende Fragen - Wenn Sie Tools vergleichen, ist es wichtig, zu bewerten, wie viel Fachwissen Ihr Team in Bezug auf die einzelnen Tools hat? - Wie viele Ihrer Entwickler sind mit LWC oder JavaScript vertraut? - Gibt es Entwickler in Ihrem Team, die Experten für Flow Builder sind oder Interesse an weiteren Informationen bekundet haben? Obwohl wir nicht auf spezifische Details eingehen, finden Sie hier ein paar weitere Informationen dazu, wie diese speziellen Tools mit den Bewertungen, die wir bisher behandelt haben, in Beziehung stehen. **Zustellungsdelegation** Beachten Sie, dass selbst wenn einige Ihrer Anforderungen LWC erfordern, nicht die gesamte Lösung mit LWC erstellt werden muss. Es ist wichtig zu bestimmen, wie Sie Ihre Lösung modular erstellen können. Dazu müssen Sie angeben, welche Teile eine codierte LWC erfordern und welche nicht. Die Teile, für die kein LWC erforderlich ist, sollten mit einer Low-Code-Lösung erstellt werden. Bei Flow und LWC gibt es verschiedene Komponenten (z. B. reaktive Bildschirmkomponenten und Bildschirm-Flow), die auf demselben Bildschirm miteinander synchronisiert werden können, um neue Tools für Architekten, Administratoren und Entwickler freizugeben. Entwickler können nun zielgerichtete, modulare Komponenten erstellen, die in der gesamten Organisation wiederverwendet werden können, was zur Steigerung der Teamproduktivität beiträgt. Dadurch können Entwickler Zeit sparen, indem sie eine Kombination aus standardmäßigen und benutzerdefinierten Flow-Komponenten verwenden, um eine Formdynamik zu erreichen, wodurch sie sich mehr auf die Lösung neuer Herausforderungen konzentrieren können. Mit der Einführung von reaktiven Komponenten in Flow gab es nie einen günstigeren Zeitpunkt, um Flow und LWC beim Erstellen von Formularen zu kombinieren. **Langfristige Inhaberschaft und Wartungsfähigkeit** Wenn Sie ein Formular mit mehreren Schritten erstellen, beginnen Sie mit Flow oder einer Kombination aus Flow und LWC. Wenn es sich bei dem Team, das das Formular verwaltet, um ein Low-Code-Team handelt, stellen Sie sicher, dass die Lösung für Ihre vorgesehene Zielgruppe so konfigurierbar und erweiterbar wie möglich ist. Unabhängig vom gewählten Tool ist es wichtig, Ihre Lösung in [zusammensetzbare](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity) Einheiten zu organisieren, um die Stabilität und Wartungsfähigkeit zu verbessern. ### Leistung Leistungsüberlegungen zu dynamischen Formularen, Bildschirm-Flows, OmniStudio oder LWC basieren auf dem Framework, in dem sich die Technologien befinden. Technologien, die auf LWC basieren, übertreffen in der Regel die auf Aura basierenden Technologien. Aufgrund mehrerer Kernfunktionen, die nativ in Web-Engines (und nicht über Framework-Abstraktionen in JavaScript) implementiert sind, bietet die LWC verbesserte Leistungsvorteile. Wie können wir diese Leistungsvorteile für unsere Formulartechnologien bei Salesforce nutzen? Sehen wir uns das genauer an. - Dynamische Formulare (in Lightning-Seiten-Metadaten integriert) basieren auf einer LWC-Stapel-Grundlage, die es uns ermöglicht, mehrere lang erwartete Funktionen zu implementieren. Dynamische Formulare verwenden ein progressives Rendering, das die Ladezeit für Seiten mit einer großen Anzahl von Feldern verbessert. - Bildschirm-Flows basieren auf LWC. Die meisten der einzelnen vorkonfigurierten Komponenten wurden nun mit Ausnahme der Komponenten "**Datei hochladen**" und "**Bild"** in LWC konvertiert. Während das Flow-Team den Flow-Laufzeit-Client (und die meisten seiner Komponenten) in LWC konvertiert hat, müssen Kunden ihre Aura-Bildschirmkomponenten weiterhin in LWC konvertieren. Beachten Sie, dass Salesforce in Bildschirm-Flows nur LWC-Komponenten im Framework für **reaktive Komponenten** unterstützt. Weitere Informationen finden Sie im Trailhead Modul [Lightning Web Components for Aura Developer](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers). Wenn Sie eine benutzerdefinierte Komponente für einen Bildschirm-Flow (oder einen anderen Container) erstellen möchten, wählen Sie LWC! - Es sind verschiedene Versionen von OmniStudio verfügbar. Als langjähriger Kunde verwenden Sie möglicherweise **Angular**. Alle Neukunden sollten LWC-basierte OmniScripts und FlexCards verwenden. Es wird auch empfohlen, bestehende Kunden von Angular zu migrieren. - LWC basiert auf LWC. ## Ressourcen
Dynamische Formulare Aufschlüsseln Ihrer Datensatzdetails mit dynamischen Formularen
Hilfe zum Lightning-Anwendungsgenerator
Bildschirm-Flow Verwenden von Bildschirm-Flows zur Interaktion mit Benutzern
- Automatisieren von Aufgaben mit Flows
OmniStudio - OmniStudio
- OmniScripts
IDX Workbench Desktop-Anwendung
- Newport Design System
Anpassen von OmniScripts und FlexCards mit dem Newport Design System
LWC - Lightning Web Components
- Lightning Aura Components Developer Guides
- Lightning Web Components für Aura-Entwickler