# architect Entscheidungsleitfäden (decision-guides) - Full Documentation

<!-- document id=cbb9ab7bd226be501de49bbea2d5eb7fbe9f620925a286ff0d3f1cf3c0f21986 url=/architect/next/de-de/decision-guides/guides/async-processing.md -->

## 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

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td>Bei der <a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Lightning Platform</a> 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.</td>
    </tr>
  </tbody>
</table>

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.

<table style="border-color:white;overflow-x:scroll;">
  <thead>
    <tr>
      <th>Ansatz</th>
      <th>Beschreibung</th>
      <th>Erforderliche Fertigkeiten</th>
      <th>Lizenzen und Obergrenzen</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Queueable Apex</b></td>
      <td>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.</td>
      <td>Pro-Code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Die Anzahl der Lizenzen kann die Obergrenzen erhöhen.</a></td>
    </tr>
    <tr>
      <td><b>Batch Apex</b></td>
      <td>Erstellen Sie komplexe, langfristige Prozesse, die Millionen von Datensätzen umfassen, indem Sie Ihren Datensatz aufteilen und in überschaubare Blöcke verarbeiten.</td>
      <td>Pro-Code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Die Anzahl der Lizenzen kann die Obergrenzen erhöhen.</a></td>
    </tr>
    <tr>
      <td><b>Geplantes Apex</b></td>
      <td>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.</td>
      <td>Pro-Code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Die Anzahl der Lizenzen kann die Obergrenzen erhöhen.</a></td>
    </tr>
    <tr>
      <td><b>Apex-Fortsetzungs-Callouts</b></td>
      <td>Führen Sie Callouts aus Apex-Methoden aus, die in einem synchronen Transaktionskontext ausgeführt werden.</td>
      <td>Pro-Code</td>
      <td>Nein</td>
    </tr>
    <tr>
      <td><b>Asynchroner Pfad (durch Datensätze ausgelöste Flows)</b></td>
      <td>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.</td>
      <td>Low-Code</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Anzahl und Typ der Lizenzen können die Obergrenzen erhöhen.</a></td>
    </tr>
    <tr>
      <td><b>Geplanter Pfad (nach Commit-Flows)</b></td>
      <td>Ausführen zu einem dynamisch geplanten Zeitpunkt nach einem auslösenden Ereignis, beispielsweise wenn ein Datensatz erstellt, aktualisiert oder gelöscht wird.</td>
      <td>Low-Code</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Anzahl und Typ der Lizenzen können die Obergrenzen erhöhen.</a></td>
    </tr>
    <tr>
      <td><b>Geplante Flows</b></td>
      <td>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.</td>
      <td>Low-Code</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Anzahl und Typ der Lizenzen können die Obergrenzen erhöhen.</a></td>
    </tr>
    <tr>
      <td><b>Plattformereignisauslöser</b></td>
      <td>Koppeln Sie Salesforce lose mit externen Systemen und kommunizieren Sie zwischen asynchronen Komponenten innerhalb der Salesforce Platform.</td>
      <td>Low-Code + Pro-Code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm">Für Anwendungsfälle von Plattformereignissen mit hohem Volumen ist eine Add-On-Lizenz erforderlich</a></td>
    </tr>
    <tr>
      <td><b>Datenerfassung ändern</b></td>
      <td>Erfassen und verarbeiten Sie Änderungsereignisse asynchron, nachdem die Datenbanktransaktion übernommen wurde.</td>
      <td>Pro-Code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm">Für die Skalierung oberhalb der Basiszuteilung ist eine Add-On-Lizenz erforderlich.</a></td>
    </tr>
    <tr>
      <td><b>Bulk API</b></td>
      <td>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.</td>
      <td>Pro-Code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.260.0.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_bulkapi.htm">Es gibt Obergrenzen.</a></td>
    </tr>
    <tr>
      <td><b>Lightning Aktionen</b></td>
      <td>Ermöglichen Sie es Lightning-Seiten, mit dem Server zu interagieren, ohne Benutzer zu zwingen, die Seite vollständig zu aktualisieren.</td>
      <td>Low-Code</td>
      <td>Nein</td>
    </tr>
  </tbody>
</table>

## Entscheidungspunkte

Diese Tabelle enthält eine Übersicht der Punkte, die Sie bei der Entscheidung für das zu verwendende asynchrone Tool berücksichtigen sollten.

<table>
  <tbody>
    <tr>
      <td><b>Erforderliche Fertigkeiten</b></td>
      <td>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.</td>
    </tr>
    <tr>
      <td><b>Typ der erzwungenen Plattformobergrenzen</b></td>
      <td>Legen Sie fest, welche <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">Obergrenzen</a> 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.</td>
    </tr>
    <tr>
      <td><b>Latenz</b></td>
      <td>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.</td>
    </tr>
  </tbody>
</table>

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

<table>
  <thead>
    <tr>
      <th>Anwendungsfall</th>
      <th>Beschreibung</th>
      <th>Ansatz der ersten Wahl</th>
      <th>Begründung</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Hochleistungsfähige Batchverarbeitung</b></td>
      <td>Jede Automatisierung, die Tausende oder Millionen von Datensätzen effizient verarbeiten muss</td>
      <td>Batch-<b>Apex</b></td>
      <td>Batch Apex bietet umfangreiche APIs für die Anbindung an die Plattform und für die Rohgeschwindigkeit.</td>
    </tr>
    <tr>
      <td><b>Datenbereinigungsauftrag</b></td>
      <td>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.</td>
      <td>Batch-<b>Apex</b></td>
      <td>Batch Apex bietet umfangreiche APIs für die Anbindung an die Plattform und für die Rohgeschwindigkeit.</td>
    </tr>
    <tr>
      <td><b>Nächtlicher Rollup-Auftrag</b></td>
      <td>Auftrag, der Rollup-Daten am Ende eines Geschäftstags berechnet.</td>
      <td>Batch-<b>Apex</b></td>
      <td>Batch Apex bietet umfangreiche APIs für die Anbindung an die Plattform und für die Rohgeschwindigkeit.</td>
    </tr>
    <tr>
      <td><b>Durch Datensatz ausgelöste Logik</b></td>
      <td>Führen Sie Logik als Reaktion auf eine Datensatzaktualisierung aus.</td>
      <td><i>Variiert</i></td>
      <td>Lesen Sie unseren Leitfaden zur begleitenden Entscheidung, <a href="/docs/architect/de-de/decision-guides/guide/record-triggered">Record Triggered Events Automation</a>. 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.</td>
    </tr>
    <tr>
      <td><b>Eskadierende Aktualisierungen durch ein Objektdiagramm</b></td>
      <td>Ermöglicht es einem Benutzer, die Speicheraktion schnell abzuschließen, indem kaskadierende Aktualisierungen an anderen Objekten zurückgestellt werden, um sie asynchron auszuführen.</td>
      <td>Warteschlangenfähiger <b>Apex</b></td>
      <td>Der warteschlangenfähige Apex verfügt über leistungsstarke Verkettungsfunktionen, mit denen eine Aktualisierungskette durch Logik in eine Reihe asynchroner Transaktionen unterteilt werden kann.</td>
    </tr>
    <tr>
      <td><b>Datensatzspezifische geplante Verarbeitung</b></td>
      <td>Automatisierung zu einem zukünftigen dynamischen Datum, das für den Datensatz spezifisch ist (z. B. 3 Tage vor einem Schlusstermin).</td>
      <td><b>Flow</b> mit einem geplanten Pfad</td>
      <td>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.</td>
    </tr>
    <tr>
      <td><b>Mehrere langsame externe Services parallel aufrufen</b></td>
      <td>Während einer synchronen Ausführung werden mehrere externe Services parallel aufgerufen, um die Gesamtausführungszeit zu optimieren.</td>
      <td>Callouts für <b>Apex</b>-Fortsetzungen</td>
      <td>Wenn Sie zulassen, dass mehrere langsam ausgeführte Callouts parallel ausgeführt werden, wird die Gesamtzeit zum Abschließen der Arbeit minimiert.</td>
    </tr>
    <tr>
      <td><b>Datenmigration von Datensätzen aus einem externen System</b></td>
      <td>Verschieben Sie große Datensatzmengen aus einem externen System in die Salesforce Platform. Entweder einmalig oder regelmäßig geplant.</td>
      <td><b>Bulk</b>- <b>API</b></td>
      <td>Dies ist der effizienteste und grenzenschonendste Ansatz für die Datenmigration.</td>
    </tr>
    <tr>
      <td><b>Ausführen zusätzlicher Logik auf einem externen System</b></td>
      <td>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.</td>
      <td><b>Plattformereignisse</b> oder <b>Datenerfassung ändern</b></td>
      <td>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 <a href="/docs/architect/de-de/decision-guides/guide/event-driven">Ereignisgesteuerte Architektur</a>.</td>
    </tr>
  </tbody>
</table>

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)

<!-- document id=7f2fe4a877fbc0ff7b792550b2ef1d74f5b76dd815f4ee838ab8a694ceb22628 url=/architect/next/de-de/decision-guides/guides/data-360-provisioning.md -->

## Übersicht

Salesforce Data 360 ist eine auf <a href="https://www.salesforce.com/platform/public-cloud-infrastructure/">Hyperforce</a> 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 sich nicht nur zwischen einer einzelnen Home-Organisation und einer Konfiguration mit mehreren Organisationen entscheiden, sondern auch entscheiden, ob sie mehrere unabhängige Data 360-Instanzen bereitstellen, Data Cloud One verwenden möchten, um Organisationen unter einer einzelnen Instanz zu vereinheitlichen, oder zwischen unabhängigen Data 360-Instanzen zusammenarbeiten möchten, indem sie Daten zwischen Data 360s freigeben (Data 360-zu-Data 360-Datenfreigabe). Diese Entscheidungen wirken sich auf die Verwaltung, Compliance, Kosten, Latenz und die Skalierbarkeit von AI- und organisationsübergreifenden Plattformfunktionen aus.

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 Home-Organisation ermöglicht, die Data 360-Instanz zu hosten, während andere Salesforce-Organisationen als Begleitorganisationen verbunden sind. 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 Art und Weise, wie Sie Salesforce Data 360 bereitstellen, ist eine grundlegende architektonische Entscheidung, da sie bestimmt, wie das Unternehmen Kundendaten vereinheitlicht, die Unternehmensführung erzwingt und wichtige Plattformfunktionen, insbesondere AI, Agentforce und Analysen, organisationsweit aktiviert. Durch die Verankerung eines Clusters von Organisationen an einer einzelnen Data 360-Datei werden ein einheitliches Datenmodell, eine zentralisierte Verwaltung und die unternehmensweite AI-Bereitschaft bereitgestellt. Gleichzeitig können Begleitorganisationen auf freigegebene Metadaten und Funktionen zugreifen, als ob die Daten lokal wären. Im Gegensatz dazu sind mehrere unabhängige Data 360-Instanzen geeignet, wenn behördliche, Compliance- oder Autonomieanforderungen die Zentralisierung verhindern, wobei die Datenfreigabe zwischen Data 360-Organisationen eine selektive Zusammenarbeit ohne Kopieren zwischen diesen Instanzen ermöglicht.

Für Architekten ist diese Entscheidung entscheidend. Sie definiert, 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 Architektur zukunftssicher zu gestalten, indem Sie künftig eine Strategie für das Hinzufügen von Data 360-Zugriff entwickeln. 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 nutzen kann. Es hilft Ihnen bei der Auswahl der Organisationen, in denen Sie Data 360 bereitstellen, und bei der Auswahl zwischen Data Cloud One und der Datenfreigabe zwischen Data 360-Organisationen. So schaffen Sie eine solide Grundlage, die Ihr Unternehmen in eine Data 360-zentrierte Zukunft bringt.

---

## Überlegungen zur Bereitstellung

Jede Bereitstellungsentscheidung – ob Sie zwischen Data Cloud One und der Datenfreigabe zwischen Data 360-Organisationen auswählen oder welche Organisation als "Startorganisation" festgelegt werden soll – sollte anhand der folgenden übergreifenden Überlegungen bewertet werden:

<table>
<tr>
<th>Überlegung</th>
<th>Warum es wichtig ist</th>
<th>Beispielszenarien</th>
</tr>
<tr>
<td><strong>Datenresidenz und Compliance</strong></td>
<td>Legt fest, wo Daten gespeichert und verarbeitet werden. Regulatorische Regeln können bestimmte Regionen oder mehrere Instanzen erfordern.</td>
<td>Eine globale Bank stellt einen Data 360-Mandanten in einer Salesforce-Organisation mit Standort in Frankfurt für die Einhaltung der DSGVO und einen weiteren in einer Organisation in Virginia für ihren US-Geschäftsbereich bereit.</td>
</tr>
<tr>
<td><strong>Governance und Sicherheit</strong></td>
<td>Wer ist Inhaber und Verwalter von Data 360? Sollten Policen zentral verwaltet oder pro Geschäftseinheit delegiert werden?</td>
<td>Ein multinationaler Konzern mit starker zentraler IT erstellt eine dedizierte Heimorganisation, die von einem Exzellenzzentrum verwaltet wird.</td>
</tr>
<tr>
<td><strong>Autonomie vs. Zentralisierung</strong></td>
<td>Unterschiedliche Führungskräfte wünschen sich möglicherweise eine separate Inhaberschaft der Daten. Die Autonomie bevorzugt mehrere Data 360s; die Zentralisierung bevorzugt Data Cloud One.</td>
<td>Eine Holdinggesellschaft mit unabhängigen Tochtergesellschaften ermöglicht es jedem BU, seine eigenen Data 360-Daten auszuführen.</td>
</tr>
<tr>
<td><strong>Latenz &amp; Leistung</strong></td>
<td>Wirkt sich auf die Abfragegeschwindigkeit und -erfahrung aus, insbesondere für Begleitorganisationen, die regionsübergreifend mit einem Data 360-Mandanten verbunden sind.</td>
<td>Ein Vertriebsteam in London, das Daten von einem Data 360-Mandanten in den USA abfragt, sieht möglicherweise eine höhere Latenz.</td>
</tr>
<tr>
<td><strong>Integrationskomplexität</strong></td>
<td>Mehr Data 360-Mandanten = mehr Pipelines, APIs und Middleware. Die Konsolidierung vereinfacht die Integration.</td>
<td>Ein Händler vermeidet das Erstellen von 10 ETL-Pipelines, indem er sie in einer Data Cloud One-Konfiguration konsolidiert.</td>
</tr>
<tr>
<td><strong>Null-Kopierdatenquellenbereich</strong></td>
<td>Zero Copy-Konnektoren weisen möglicherweise regionsübergreifende Zugriffsanforderungen auf, die einschränken, in welchen Regionen sich Ihre Data 360 befinden kann.</td>
<td>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.</td>
</tr>
<tr>
<td><strong>Regionsübergreifende Private Connect-Kompatibilität</strong></td>
<td>In einigen Fällen hängt die Unterstützung von Private Connect davon ab, ob sich die Datenquelle in derselben Region wie der Data 360-Mandant befindet.</td>
<td>Ein Unternehmen verfügt über eine Snowflake-Instanz in der Region aws-east-1, mit der es eine Verbindung per Zero Copy herstellen möchte. Sie können nur dann eine Private Connect-Netzwerkverbindung herstellen, wenn sich die Data 360-Startorganisation in derselben Region befindet.</td>
</tr>
<tr>
<td><strong>Kosten &amp; Lizenzierung</strong></td>
<td>Jeder Data 360-Mandant hat zusätzliche Kosten. Die Konsolidierung in weniger Instanzen optimiert die Ausgaben.</td>
<td>Ein Gesundheitsanbieter reduziert die Lizenzkosten, indem er Data Cloud One anstelle mehrerer unabhängiger Data 360-Instanzen verwendet.</td>
</tr>
<tr>
<td><strong>Künftige Skalierbarkeit</strong></td>
<td>Bereitstellungsentscheidungen schaffen heute die Grundlage für Wachstum.</td>
<td>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.</td>
</tr>
<tr>
<td><strong>Unternehmensweite AI-Bereitschaft</strong></td>
<td>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.</td>
<td>Ein Finanzdienstleistungsunternehmen vereinheitlicht Daten in Data Cloud One, sodass seine Einstein AI-Modelle auf unternehmensweite Kundendaten zugreifen können.</td>
</tr>
</table>

### Wichtige Überlegungen

<ul>
<li><strong>Die Bereitstellung ist an Lizenzen gebunden:</strong> Data 360 wird in der Organisation bereitgestellt, in der die Data 360-Lizenz erworben wird, und die Region richtet sich nach dem Standort dieser Organisation zum Zeitpunkt der Bereitstellung.</li>

<li><strong>Halten Sie Ihre Optionen offen, indem Sie für Data 360 planen</strong>, auch wenn Sie es jetzt nicht benötigen. Entscheidungen, die Sie jetzt treffen, können Ihnen den Weg ebnen, wenn Sie Data 360 implementieren, um später Plattformfunktionen wie Agentforce zu unterstützen.</li>

<li><strong>Kunden mit einer einzigen Organisation</strong>: Stellen Sie Data 360 in Ihrer vorhandenen Produktionsorganisation bereit, um die schnellste Wertschöpfungszeit zu erzielen.</li>

<li><strong>Kunden mit mehreren</strong> Organisationen: Minimieren Sie die Komplexität, indem Sie möglichst wenige Data 360-Instanzen erstellen, idealerweise mithilfe der Konfiguration von Data Cloud One.</li>

<li><strong>Mehrere Data 360-Instanzen</strong> sollten nur verwendet werden, wenn dies aufgrund von Compliance, Residenz oder Organisationsautonomie erforderlich ist. Verwenden Sie in diesen Fällen die Datenfreigabe zwischen Data 360-Organisationen, um eine sichere Zusammenarbeit zu ermöglichen.</li>

<li><strong>Null-Kopierdatenquellen</strong>: 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.</li>

<li><strong>Governance und Autonomie</strong> sind zentrale Konzepte: Entscheiden Sie, ob Data 360 zentral verwaltet werden soll (Exzellenzcenter-Modell) oder ob einzelne Geschäftsbereiche separat verwaltete Data 360-Instanzen benötigen.</li>
</ul>

---

## Abschnitt 1: Provisioning Data 360 – Auswählen der Startorganisation

### 1.1 Was ist eine Data 360-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.
<img style="border:1px solid #e5e5e5;float:right;width:35%;margin:1rem 2rem 1rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Home Org.png" alt="Entscheidungsdiagramm mit Data 360-Startorganisation" />
Die Startseitenorganisation ist der Anker für Ihre Data 360-Instanz. Hier gilt Folgendes:

- Data 360-Speicher und -Berechnung werden verwaltet (in der bei der Bereitstellung ausgewählten Region).
- Verwaltungs-, Governance- und Sicherheitsrichtlinien werden angewendet.
- Datenaufnahme, Harmonisierung, Identitätsbestimmung, Segmentierung und Aktivierung werden durchgeführt.

In Szenarien mit mehreren Organisationen verwaltet die Startseitenorganisation die zentrale Data 360-Instanz für andere Salesforce-Organisationen vom Typ "Begleiter".

Warum die Heimatorganisation wichtig ist:

- Er bestimmt den geografischen Standort Ihrer Data 360-Instanz.
- Sie bestimmt, 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.
- Sie steuert die Verbindungen der Begleitorganisation in einer Data Cloud One-Konfiguration.
- Sie bildet die Grundlage für Ihre Unternehmensdatenstrategie – sie später zu ändern ist schwierig und störend.

### 1.2 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 "Startorganisation" fungiert.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Existing_Org_vs_New_Dedicated_Org.png" alt="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äfte ausgeführt werden.

<img style="border:1px solid #e5e5e5;float:right;width:45%;margin:1rem 2rem 1rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_an_existing.png" alt="Diagramm mit Data 360-Bereitstellung in vorhandener Organisation" />

- **Profis**:

  - Einfachster Pfad: Data 360 wird dort bereitgestellt, wo sich Ihre CRM-Daten bereits befinden.
  - Sofortiger Zugriff auf lokale Vertriebs-, Service- und Marketingdaten.
  - 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 technische Verschuldung 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.

<img style="border:1px solid #e5e5e5;float:right;width:45%;margin:1rem 2rem 1rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_new_dedicated_org.png" alt="Diagramm mit Data 360-Bereitstellung in einer neuen dedizierten Organisation" />

- **Profis**:

  - 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 Organisation für die Bereitstellung von Data 360. Alle Geschäftseinheitenorganisationen (Einzelhandel, Vermögen, Geschäftsbanken) verbinden sich als Begleitorganisationen über Data Cloud One.

#### Entscheidungskriterien

<table>
<tr>
<th>Überlegung</th>
<th>Vorhandene Organisation als Startorganisation (bevorzugte Standardeinstellung)</th>
<th>Neue Organisation als Heimatorganisation (Alternative)</th>
</tr>
<tr>
<td><strong>Einfachheit</strong></td>
<td>Baut auf der vorhandenen Benutzer- und Datenstruktur auf, um die Einrichtung zu beschleunigen. Data 360 ist standardmäßig in die Startseitenorganisation integriert.</td>
<td>Erfordert die Lizenzierung und Einrichtung einer neuen Salesforce-Organisation sowie zusätzlichen Verwaltungsaufwand für ihre Verwaltung.</td>
</tr>
<tr>
<td><strong>Zeit bis zum Wert</strong></td>
<td>Sofortige Verwendung lokaler CRM-Daten.</td>
<td>Langsamere Rampe; Integration erforderlich.</td>
</tr>
<tr>
<td><strong>Governance</strong></td>
<td>Übernimmt das grundlegende Governance-Modell der vorhandenen Organisation – vorhandene Benutzer und Berechtigungssätze. Dies kann in Ordnung sein, wenn die Organisation bereits zentral ist.</td>
<td>Clean Slate für Governance; ideal für CoE-geführte Modelle.</td>
</tr>
<tr>
<td><strong>Compliance</strong></td>
<td>Residenz, die an die Region der vorhandenen Organisation gebunden ist.</td>
<td>Flexibilität bei der Auswahl einer Region unabhängig von vorhandenen Organisationen.</td>
</tr>
<tr>
<td><strong>Leistung</strong></td>
<td>Beste Leistung für lokale CRM-Abfragen.</td>
<td>Abhängig von der Konnektivität der Begleitorganisation, unabhängig davon, ob es sich um dieselbe Region oder um eine Region mit den anderen Organisationen handelt.</td>
</tr>
<tr>
<td><strong>Künftige Skalierbarkeit</strong></td>
<td>Funktioniert gut, wenn es mit Data Cloud One gekoppelt ist; später ist es schwieriger, eine Schicht zu verschieben, wenn die falsche Organisation ausgewählt ist.</td>
<td>Einfache Skalierung mit Data Cloud One ; auf Neutralität ausgelegt.</td>
</tr>
<tr>
<td><strong>Kosten</strong></td>
<td>Geringere inkrementelle Kosten.</td>
<td>Höherer Overhead durch zusätzliche Umgebungen.</td>
</tr>
</table>

### 1.3 Empfehlungen

Grundsätzlich gilt: Verwenden Sie eine vorhandene Hauptorganisation als "Startorganisation", 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. Die Erstellung einer neuen, dedizierten Heimorganisation 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 Organisation, in der der Großteil Ihres Unternehmens ausgeführt wird, oder die Organisation, die bereits als zentralisiertes CRM fungiert. 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**

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. In diesen Fällen bietet die Erstellung einer neuen Heimorganisation Flexibilität und Neutralität – allerdings mit einer langsameren Wertschöpfung.

---

## Abschnitt 2: Strategie für mehrere Organisationen und Data Cloud One

### 2.1 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 die EU, Nordamerika, den asiatisch-pazifischen Raum usw., oft zur Einhaltung der Datenresidenzgesetze.
- **Funktionale Trennung:** Verschiedene Geschäftseinheiten (z. B. Retail Banking, Wealth Management, Insurance) unterhalten ihre eigenen Organisationen, um die Autonomie zu gewährleisten.
- **Regulatorische oder Sicherheitsisolation:** Bestimmte Branchen legen aus Compliance-Gründen logisch unterschiedliche Organisationen fest.
- **Historische/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?

---

### 2.2 Was ist 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. Es ist das empfohlene Muster für Unternehmen mit mehreren Salesforce-Organisationen.

In Data Cloud One-Clustern wird eine Salesforce-Organisation als "Startorganisation" 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.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies Data 360 DC One.png" alt="Diagramm mit Data Cloud One-Architektur" />

#### Funktionsweise von Data Cloud One

<ol>
<li><strong>Datenaufnahme und -vereinheitlichung (Startorganisation)</strong><br/>
   <ul>
   <li>Die gesamte Konfiguration der Datenaufnahme (Salesforce CRM, externe Quellen, Streaming, Batch) erfolgt ausschließlich über die Startseitenorganisation.</li>
   <li>Der an die Startseitenorganisation gebundene Data 360-Mandant führt die Identitätsbestimmung, Harmonisierung, Modellierung und Vereinheitlichung in vertrauenswürdigen Customer 360 Profilen aus.</li>
   <li>Data 360-Verwaltung, -Governance-Richtlinien, -Tagging und -Maskierung werden zentral über die Startseitenorganisation angewendet.</li>
   </ul>
</li>

<li><strong>Datenbereichsarchitektur</strong><br/>
   <ul>
   <li>In der Startseitenorganisation werden Daten in Datenbereiche organisiert, die als logische Container für Daten, Metadaten und Prozesse fungieren.</li>
   <li>Unternehmen können Datenbereiche für Marken, Regionen oder Geschäftsbereiche erstellen.</li>
   <li>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.</li>
   </ul>
</li>

<li><strong>Metadatenfreigabe</strong><br/>
   Begleitorganisationen erhalten Metadatendefinitionen von der Startseite, einschließlich Datenmodellobjekten (DMOs), vereinheitlichtem Profilschema, berechneten Statistiken, Segmenten <a href="https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5">und mehr</a>. Diese werden nativ in der Begleitorganisation angezeigt, als ob es sich um lokale Vermögenswerte handelte, sie sind jedoch tatsächlich mit der Startseitenorganisation verknüpft.</li>

<li><strong>Aufträge, die in der häuslichen Organisation zu erledigen sind, im Vergleich zu Begleitorganisationen</strong></li>  
   Der Funktionszugriff unterscheidet sich zwischen Startseite und Begleitorganisationen. Begleitorganisationen können keine Daten aufnehmen oder vereinheitlichen und sind bei der Aufnahme, Modellierung und Vereinheitlichung auf die Startseitenorganisation 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.

<table>
<tr>
<th>Kapazität</th>
<th>Home Org (Startorganisation)</th>
<th>Begleitorganisation</th>
</tr>
<tr>
<td>Konnektoren <strong>verbinden</strong> Konnektoren konfigurieren, Datenströme erstellen, Daten aufnehmen oder verknüpfen</td>
<td>✅</td>
<td>❌</td>
</tr>
<tr>
<td><strong>Harmonisieren und Vereinheitlichen</strong> Erstellen und Ausführen von Datentransformationen und Identitätsbestimmung</td>
<td>✅</td>
<td>❌</td>
</tr>
<tr>
<td><strong>Steuern von</strong> sicheren Daten mit Datenbereich und Berechtigungen</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Segmente, Statistiken und Einstein Studio-Modelle für <strong>Segment- und Prognoseerstellung</strong></td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td><strong>Aktivieren von Everywhere</strong>-Aktivierungen, Datenaktionen</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Eingabeaufforderungsgenerator für <strong>Plattformfunktionen</strong>, Flows, Berichte, Anreicherung <a href="https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5">und mehr</a></td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Center für potenzielle Kunden <strong>mit Data 360</strong>-Funktionen, Sales- und Service Cloud-Funktionen, Agentforce und mehr</td>
<td>✅</td>
<td>✅</td>
</tr>
</table>

<li><strong>Plattformfunktionsparität</strong><br/>
   	Aus Sicht von Benutzern und Generatoren gibt es nach der Freigabe der Metadaten einige funktionale Unterschiede zwischen der Startseite und Begleitorganisationen in Bezug auf die Verwendung der Salesforce Platform-Funktionen. Eine Liste der unterstützten Funktionen finden Sie unter <a href="https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5">Data 360-Funktionen in Begleitorganisationen</a>.<br/>
   <ul>
   <li>Sobald Metadaten verfügbar sind, funktionieren Salesforce Platform-Funktionen wie Flows, Berichte, Eingabeaufforderungsgenerator, Dashboards und andere plattformeigene Tools in Start- und Begleitorganisationen.</li>
   <li>Data 360-gestützte Funktionen wie Agentforce, das Prospecting Center, Sales Cloud Einstein und Service Cloud AI-Funktionen funktionieren auch problemlos in Start- und Begleitorganisationen. Einige Funktionen sind möglicherweise auf dem Weg zur vollständigen Kompatibilität. Das übergeordnete Ziel besteht jedoch darin, die Funktionsparität zwischen Startseiten- und Begleitorganisationen für alle Cloud-übergreifenden Funktionen zu gewährleisten, die von Data 360 abhängen.</li>
   </ul>
</li>

<li><strong>Verbrauchsmodell</strong><br/>
   Bei allen Aktivitäten der Begleitorganisation (Abfragen, Segmentausführungen, durch Data 360 ausgelöste Flows, AI-Nutzung, Protokollierung der Einstein Trust Layer usw.) werden Data 360-Gutschriften aus der Startseite verwendet. Verbrauchs-Flows in eine Richtung: Gutschriften werden zentralisiert, abgerechnet 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.</li>

<li><strong>Designprinzip: Horizontale Konstruktion</strong><br/>
   Data Cloud One ist ein horizontales Konstrukt der Salesforce Platform – ähnlich wie Sandbox-Instanzen. Ziel ist es, dass jede neue Funktion, die Salesforce veröffentlicht, ohne zusätzliche Einrichtung in Startseiten- und Begleitorganisationen funktioniert. Dadurch wird sichergestellt, dass Data Cloud One nicht nur eine Datenarchitektur ist, sondern auch ein grundlegendes Element der Salesforce Platform.</li>
</ol>

---

### 2.3 Entscheidung: Mehrere unabhängige Data 360s im Vergleich One Shared Data 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 in jeder Organisation unabhängige Data 360s bereitstellen oder Data Cloud One verwenden, um Organisationen unter einer einzigen Startseitenorganisation zu vereinheitlichen?

#### Option A: Mehrere unabhängige Data 360s

Jede Salesforce-Organisation stellt ihre eigene Data 360-Instanz bereit.

**Profis**:

- **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 (z. B. dürfen Daten keine Grenzen überschreiten).

**Kontra**:

- **Datensilos:** Customer 360 kann organisationsübergreifend nicht erreicht werden.
- **Höhere Kosten**: Jede Instanz erfordert Lizenzierung, Verwaltung und Integration. Kunden nehmen dieselben Quelldaten am Ende mehrfach auf, um eine vollständige C360-Ansicht in mehreren verschiedenen Organisationen zu erhalten.
- **Doppelte Arbeit:** Die Identitätsbestimmung, Segmentierung und Anreicherung müssen in jeder Data 360 wiederholt werden.

#### Option B: One Shared Data 360 (Data Cloud One-Cluster)

Eine einzelne Data 360 wird in einer Startseitenorganisation bereitgestellt, während andere Salesforce-Organisationen als Begleitorganisationen verbunden sind.

**Profis**:

- **Single Source of Truth (SSOT):** Alle Organisationen verwenden dasselbe einheitliche Datenmodell.
- **Kosteneffizienz:** Nur eine Data 360-Lizenz und -Infrastruktur zu verwalten.
- **Einheitliche Unternehmensführung:** Richtlinien, Sicherheits- und Compliance-Kontrollen werden zentral angewendet.
- **Organisationsübergreifende Anreicherung:** Begleitorganisationen können auf harmonisierte Profile, Statistiken und Segmente zugreifen.
- **AI-Bereitschaft:** Unternehmensweites Datenset ermöglicht eine bessere Schulung und Aktivierung von AI-Modellen.
- **Zukunftssicher:** Das Hinzufügen neuer Begleitorganisationen ist ganz einfach. Neue Data 360s sind nicht erforderlich.

**Kontra**:

- **Zusätzliche Zubereitung:** Erfordert Planung für die Verbindung von Organisation zu Organisation.
- **Überlegungen zur Latenz:** Begleitorganisationen in verschiedenen Regionen sehen möglicherweise langsamere Abfragen.
- **Komplexe Governance:** Wenn jede Organisation sehr unterschiedliche Anpassungsanforderungen hat, kann die detaillierte Verwaltung komplex sein.

#### Option C: Mehrere Data Cloud One-Cluster

In einigen Fällen 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 360s betreibt, von denen jede die Startseitenorganisation für einen anderen Cluster von Begleitorganisationen ist.

#### Beispiel:

Ein multinationales Unternehmen verfügt über Salesforce-Organisationen in einer Vielzahl von 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

<table>
<tr>
<th>Überlegung</th>
<th>Mehrere unabhängige Data 360s</th>
<th>One Shared Data 360 (Data Cloud One )</th>
</tr>
<tr>
<td><strong>Autonomy</strong></td>
<td>Hohe Autonomie für jede Organisation oder Geschäftseinheit.</td>
<td>Zentrale Verwaltung, weniger Autonomie pro Organisation.</td>
</tr>
<tr>
<td><strong>Compliance</strong></td>
<td>Nützlich, wenn eine strikte Trennung erforderlich ist (z. B. regionale Gesetze).</td>
<td>Funktioniert am besten, wenn die Residenz die Zentralisierung zulässt.</td>
</tr>
<tr>
<td><strong>Kosten</strong></td>
<td>Höhere Lizenz- und Administratorkosten.</td>
<td>Kosteneffizienter; eine Lizenz für viele Organisationen.</td>
</tr>
<tr>
<td><strong>Governance</strong></td>
<td>Fragmentiert; Richtlinien unterscheiden sich je nach Organisation.</td>
<td>Zentralisierte, organisationsübergreifend konsistente Richtlinien.</td>
</tr>
<tr>
<td><strong>Datensilos</strong></td>
<td>Jede Organisation hat ihre eigene Ansicht, keine Enterprise 360.</td>
<td>Vereinheitlichtes Datenset, keine Duplizierung.</td>
</tr>
<tr>
<td><strong>AI/Analytics</strong></td>
<td>Beschränkt auf die Daten der einzelnen Organisationen.</td>
<td>Unternehmensweite Modelle mit höherer Genauigkeit.</td>
</tr>
<tr>
<td><strong>Komplexität</strong></td>
<td>Mehr zu verwaltende Instanzen, mehr Integrationen.</td>
<td>Einfachere Architektur, weniger bewegliche Teile.</td>
</tr>
<tr>
<td><strong>Leistung</strong></td>
<td>Ideal für Anwendungsfälle innerhalb der Organisation.</td>
<td>Der Zugriff auf Begleitorganisationen kann zu Latenz führen.</td>
</tr>
</table>

---

### 2.4 Empfehlungen

**Bevorzugtes Muster:** **Data Cloud One**

Standardmäßig wird eine einzelne Startseitenorganisation mit verbundenen Begleitorganisationen für Unternehmen mit mehreren Organisationen verwendet.  
Dadurch wird eine unternehmensweite Customer 360 erstellt, die Verwaltung vereinfacht und die Kosten optimiert.

**Wann mehrere Data 360s verwendet werden:**

Nur wenn Compliance, Residenz oder Organisationsautonomie dies unbedingt erfordern. Beispielsweise wenn europäische Betriebe aufgrund von Vorschriften vollständig von US-amerikanischen Betrieben 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, in der die meisten Geschäfte ausgeführt werden. Die Bereitstellung von Data 360 dort kann die Komplexität minimieren und den frühen Wert maximieren.

Nur wenn keine vorhandene Organisation geeignet ist, sollten Sie eine dedizierte Heimorganisation erstellen, die von einem Exzellenzcenter-Team verwaltet wird.

**Allgemeines Prinzip:**

Minimieren Sie in Umgebungen mit mehreren Organisationen die Anzahl der Data 360s. Bevorzugen Sie Data Cloud One als Standardmuster, um Duplikate zu reduzieren, die AI-Bereitschaft zu aktivieren und die Verwaltung zu vereinfachen.

---

## Abschnitt 3: Mehrere Data 360s und Datenfreigabe zwischen Data 360-Organisationen

### 3.1 Was ist die Datenfreigabe zwischen Data 360-Organisationen?

Obwohl Data Cloud One für die meisten Unternehmen der empfohlene Ansatz ist, gibt es Szenarien, in denen Kunden möglicherweise mehrere Data 360-Instanzen bereitstellen müssen. Sobald mehrere Data 360s vorhanden sind, erfolgt die Vereinheitlichung nicht mehr 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 360s entwickelt wurde.

#### Funktionsweise

- Jede Data 360 wird in ihrer eigenen Home-Organisation 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. Die zugrunde liegenden Daten verbleiben in der Quelldatei Data 360; nur der Zugriff wird freigegeben.
- 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.

#### Schlüsselunterschied zu Data Cloud One

- In Data Cloud One verwenden mehrere Begleitorganisationen eine einzelne Data 360-Instanz. Plattformfunktionen (Agentforce, Prospecting Center, Tableau Next usw.) werden alle mit denselben zugrunde liegenden Daten ausgeführt, um Konsistenz zu gewährleisten.
- Wenn Sie die Datenfreigabe zwischen Data 360-Organisationen verwenden, verfügt jede Organisation über ihre eigenen Data 360. 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.

---

### 3.2 Anwendungsfälle für die Datenfreigabe zwischen Data 360-Organisationen

**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 (z. B. Treue-KPIs) zu aggregieren, die für die US-Zentrale freigegeben werden, während Rohdaten lokal bleiben.

**Zusammenarbeit der Geschäftseinheit:**  
Ein Konglomerat führt separate Data 360s für Einzelhandel und Versicherungen aus. Durch die Datenfreigabe zwischen Data 360s können Benutzer auf eine einzelne, vertrauenswürdige Datenquelle zugreifen, ohne sie verschieben oder kopieren zu müssen. Mit der Datenfreigabe zwischen Data 360-Organisationen erhält die Versicherungsorganisation das Segment "High Value Customer" des Einzelhandels für gezielte Cross-Selling-Kampagnen.

**Fusionen und Übernahmen:**  
Eine Muttergesellschaft erwirbt eine Tochtergesellschaft mit eigenem Data 360. Da zwei Instanzen verwaltet werden müssen, werden durch das Beibehalten kurzfristiger Datensilos 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 hinweg stellt einzelne Data 360s 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.

#### Vor- und Nachteile der Datenfreigabe zwischen Data 360-Organisationen

<table>
<tr>
<th>Faktor</th>
<th>Pros</th>
<th>Nachteile</th>
</tr>
<tr>
<td><strong>Datenresidenz</strong></td>
<td>Unterstützt die regionale Trennung und ermöglicht gleichzeitig die Zusammenarbeit.</td>
<td>Es müssen nicht mehrere Data 360 verwaltet werden.</td>
</tr>
<tr>
<td><strong>Datenduplizierung</strong></td>
<td>Nullkopie; keine Duplizierung von Objekten.</td>
<td>Erfordert eine bewusste Auswahl von Objekten für die Aufnahme in jede Datenfreigabe.</td>
</tr>
<tr>
<td><strong>Governance</strong></td>
<td>Die Freigabe erfolgt explizit und bewusst (Objektebene).</td>
<td>Es werden keine Tags oder Richtlinien verwendet. Die Zielorganisation muss die Governance erneut anwenden.</td>
</tr>
<tr>
<td><strong>Komplexität</strong></td>
<td>Ermöglicht die selektive Zusammenarbeit ohne Zentralisierung.</td>
<td>Erfordert die Verwaltung mehrerer Data 360s und Datenfreigaben.</td>
</tr>
<tr>
<td><strong>AI/Analytics</strong></td>
<td>Regionale AI/Analysen möglich; Statistiken können organisationsübergreifend freigegeben werden.</td>
<td>Keine unternehmensweite AI, es sei denn, Daten werden bewusst freigegeben.</td>
</tr>
<tr>
<td><strong>Plattformfunktionen</strong></td>
<td>Die Data 360-gestützten Funktionen jeder Organisation werden unabhängig ausgeführt.</td>
<td>Keine automatische Freigabe – Duplizierungsrisiko, wenn nicht sorgfältig geplant.</td>
</tr>
<tr>
<td><strong>Kosten</strong></td>
<td>Kann den Bedarf an ETL-Pipelines reduzieren.</td>
<td>Für mehrere Data 360 fallen weiterhin Kosten an. Verbraucht Gutschriften für Datenabfragen und die Datenfreigabe.</td>
</tr>
</table>

#### Entscheidungskriterien

<table>
<tr>
<th>Überlegung</th>
<th>Data Cloud One (für mehrere Organisationen bevorzugt)</th>
<th>Datenfreigabe zwischen Data 360-Organisationen</th>
</tr>
<tr>
<td><strong>Einzelne Quelle der Wahrheit</strong></td>
<td>✅ Ja – alle Organisationen verwenden denselben DC.</td>
<td>❌ Nein – jede Data 360 verfügt über ein eigenes Datenmodell.</td>
</tr>
<tr>
<td><strong>Compliance</strong></td>
<td>Funktioniert nur, wenn die Residenz die Zentralisierung zulässt.</td>
<td>Wird benötigt, wenn Residenzgesetze die Zentralisierung verhindern.</td>
</tr>
<tr>
<td><strong>Governance</strong></td>
<td>Zentralisiert, konsistent.</td>
<td>Verbunden; bewusste Freigaben auf Objektebene.</td>
</tr>
<tr>
<td><strong>Komplexität</strong></td>
<td>Weniger bewegliche Teile, einfacher.</td>
<td>ore complex (Erzkomplex): Erfordert Konfigurationsdatenfreigaben und mehrere Data 360s.</td>
</tr>
<tr>
<td><strong>AI/Analytics</strong></td>
<td>Unternehmensweite AI-Modelle.</td>
<td>Regionale AI; Statistiken können selektiv freigegeben werden.</td>
</tr>
<tr>
<td><strong>Plattformfunktionen</strong></td>
<td>"Shared Data 360" bedeutet, dass alle Funktionen auf der Startseite + "Begleiter" einheitlich funktionieren.</td>
<td>Funktionen werden in jeder Data 360 unabhängig ausgeführt. Die Freigabe muss explizit sein.</td>
</tr>
</table>

### 3.3 Bewährte Vorgehensweisen

**Wenn Ihr Unternehmen über mehrere Data 360s 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.
- Beachten Sie, dass Tags nicht freigegeben werden. Die empfangende Organisation muss Tags erneut anwenden (z. B. Governance, Klassifizierung, AI-Anreicherung).

**Wann verwenden Sie die Datenfreigabe zwischen Data 360-Organisationen?**

- 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**

Die Freigabe muss bewusst und objektspezifisch sein. Vermeiden Sie "Überfreigabe" – gleichen Sie Datenfreigaben an die Geschäfts- und Compliance-Anforderungen an. Behandeln Sie die Data 360-zu-Data 360-Datenfreigabe als Verbundstrategie und nicht als Ersatz für Data Cloud One.

---

## Zusammenfassung

<ol>
<li><strong>Jede Organisation sollte für den Zugriff auf eine Data 360 planen</strong><br/>
   <ul>
   <li>Für alle Salesforce Platform-Funktionen – von Sales Cloud über Service Cloud bis Agentforce – ist künftig eine Data 360-Konnektivität erforderlich. Jede Organisation muss entweder eine Data 360-Startorganisation hosten oder eine über Data Cloud One verbundene Begleitorganisation sein.</li>
   </ul>
</li>

<li><strong>Unternehmensweit denken, nicht organisationsübergreifend</strong><br/>
   <ul>
   <li>Vermeiden Sie einseitige Branchenentscheidungen, die isoliert getroffen werden.</li>
   <li>Die Bereitstellung sollte kollektiv entschieden werden, idealerweise von einer Unternehmensarchitektur oder einem Datenverwaltungsrat. Prognostizieren Sie immer zukünftige AI- und Analyseanforderungen, die von breiten, vereinheitlichten Datensets abhängen.</li>
   </ul>
</li>

<li><strong>Datensilos minimieren</strong><br/>
   <ul>
   <li>Bevorzugen Sie die Bereitstellung von Data 360 in einer vorhandenen Hauptorganisation, um Einfachheit und Geschwindigkeit zu gewährleisten.</li>
   <li>In Umgebungen mit mehreren Organisationen ist Data Cloud One das Standardmuster zum Vereinheitlichen von Organisationen unter einer Data 360.</li>
   <li>Stellen Sie mehrere Data 360s nur bereit, wenn dies für Compliance, Residenz oder Organisationsautonomie unbedingt erforderlich ist.</li>
   </ul>
</li>

<li><strong>Gezieltes Entwerfen, wenn Sie mehrere Data 360s ausführen müssen</strong><br/>
   <ul>
   <li>Richten Sie die Datenfreigabe zwischen Data 360-Organisationen für die Zusammenarbeit ein, nicht für benutzerdefinierte ETL-Pipelines.</li>
   <li>Geben Sie bestimmte Objekte (DMOs, berechnete Statistiken, Segmente) über Datenfreigaben frei.</li>
   <li>Zur Erinnerung: Tags werden nicht freigegeben und der Verbrauch wird der Quellorganisation in Rechnung gestellt.</li>
   </ul>
</li>

<li><strong>Governance und Eigenverantwortung frühzeitig planen</strong><br/>
   <ul>
   <li>Legen Sie fest, ob Data 360 zentral verwaltet (Exzellenzcenter-Modell) oder an Geschäftsbereiche delegiert werden soll. Definieren Sie Rollen für Administratoren, Sicherheitsteams und Compliance-Leads.</li>
   <li>Vermeiden Sie Mehrdeutigkeiten: Unklare Inhaberschaft ist eine häufige Quelle von Reibungen.</li>
   </ul>
</li>

<li><strong>Kurzfristige Tastenkombinationen vermeiden</strong><br/>
   <ul>
   <li>Verwenden Sie nicht mehrere Data 360s für POCs ohne einen langfristigen Plan – dies führt später zu störenden Konsolidierungsarbeiten.</li>
   <li>Stimmen Sie stattdessen Pilotprogramme und frühe Bereitstellungen auf Ihre unternehmensweite Bereitstellungsstrategie ab.</li>
   </ul>
</li>
</ol>

Diese Bereitstellungsentscheidungen sind wichtig, da sich die Salesforce Platform zu einem Data 360-First-Modell entwickelt, bei dem jede Funktion, von der Kundensegmentierung bis zur AI-Agentenbildung, davon abhängt. Die Entscheidungen, die Sie heute treffen, werden die Grundlage dafür schaffen, wie effektiv Ihr Unternehmen Kundendaten vereinheitlicht, wie schnell Sie neue Salesforce-Funktionen einführen und wie sicher Sie KI in Ihrem Unternehmen skalieren können. Um erfolgreich zu sein, müssen Sie sorgfältig vorsorgen, Doppelarbeit minimieren, die Compliance-Anforderungen einhalten, bewusst regieren und langfristig denken. Letztlich ist die Bereitstellung von Data 360 der erste Schritt, damit Daten, AI und CRM als eine zusammengehörige Plattform funktionieren.

#

## Über die Autoren

Kunal Goyal ist Director of Product Management bei Salesforce und konzentriert sich auf die Weiterentwicklung der Architektur und Skalierbarkeit mehrerer Organisationen in Data 360. Seit 2017 hat er mehrere Initiativen und Produkte geleitet, die sich auf organisationsübergreifende Zusammenarbeit und mandantenübergreifendes Systemdesign konzentrieren. 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. Sie ist bestrebt, Data 360 durch klare, konsistente und genaue technische Dokumentation und Kommunikation in der Anwendung leichter verständlich und 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.

<!-- document id=7691c7a1c4901a0e6b223617afa92f0e688e76e619efa97cf562565d3c6a2bea url=/architect/next/de-de/decision-guides/guides/data-360-interoperability.md -->

## Übersicht

Unternehmen speichern Daten häufig in Salesforce und anderen externen Data Lakes wie Snowflake, Google BigQuery, Databricks, Redshift oder Cloud-Speicher wie Amazon S3. Diese Isolierung von Daten in unterschiedlichen Quellsystemen stellt eine Herausforderung für Unternehmen dar, die die volle Leistungsfähigkeit ihrer Daten nutzen möchten.

Architekten, die daran arbeiten, Daten über mehrere Data Lakes hinweg zusammenzuführen, stehen vor wichtigen architektonischen Entscheidungen, wie sie diese Daten am besten integrieren können. Data 360 bietet mehrere Optionen für die Datenintegration, von denen jede unterschiedliche Vor- und Nachteile bietet.

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 Lakehouses 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, da Sie mehr Daten über das Netzwerk übertragen. Daher ist für die meisten realen Implementierungen eine Kombination aus Aufnahme und Verbund innerhalb eines Mehr-Cloud-Lakehouse-Ökosystems der optimale Weg. Dieser hybride Ansatz gewährleistet eine skalierbare, gesteuerte und interoperable Architektur, die nahtlos sowohl operative Arbeitslasten mit geringer Latenz wie Echtzeitpersonalisierung und Betrugserkennung als auch analytische Arbeitslasten wie behördliche Berichte und Analysen historischer Trends unterstützt. In diesem Entscheidungsleitfaden erfahren Sie, wie Sie in diesen Kompromissen navigieren und die richtige Strategie auswählen.

## Takeaways

- **Datenaufnahme:** Kopiert Daten in Salesforce Data 360 und erstellt so geregelte kanonische Datenmodelle. Ideal für folgende Fälle:
  - **Erstellen einer umfassenden Customer 360:** Vereinheitlichen und transformieren Sie ungleiche Quellen in ein einzelnes, vertrauenswürdiges Profil.
  - **Erfüllen Sie die strenge Einhaltung gesetzlicher Vorschriften:** Erstellen Sie eine überprüfbare, zentralisierte Kopie, in der der Datenzugriff und die Herkunft streng gesteuert werden können.
- **Nullkopieverbund:** Fragt externe Quellen in Echtzeit ohne Duplikate ab und ermöglicht so die Echtzeitpersonalisierung, Live-Dashboards und die schnelle Einarbeitung von Quellen. Zwei primäre Optionen mit Kompromissen, die Sie abwägen müssen:
  - **Live & Caching (Beschleunigte Abfrage):** Ideal für interaktive Analysen und Echtzeit-Dashboards zu Daten, die sich auf externen Datenplattformen wie Snowflake, Google BigQuery, Redshift oder Databricks befinden. Vermeidet langsame, kostspielige Datenduplizierungen, indem die Verarbeitung auf das Quellsystem verschoben wird.
  - **Dateiverbund:** Bestens geeignet für die Batch-Verarbeitung im großen Umfang und für AI-Modellschulungen zu Daten in Ihrem Cloud-Data-Lake (S3, ADLS). Vermeidet eine kostspielige und langsame Aufnahme, indem Dateien in offenen Tabellenformaten direkt abgefragt werden und so umfangreiche Datensets für ETL- und Data Science-Arbeitslasten freigeschaltet werden.
- **Hybrid Model:** Kombinieren Sie die Aufnahme von zusammengeführten Profilen mit Verbundenheit für mehr Aktualität, unterstützen Sie Omnikanal-Engagement, Agentforce Aktionen und AI/ML-Schulungen.

### Wichtige Überlegungen

- **Hybridarchitektur:** Die Kombination von Datenaufnahme und Datenverbund ist häufig erforderlich.

  - Verwenden Sie "Datenaufnahme" für wichtige Daten für kanonische Datenmodelle und die Kernverwaltung.
  - Führen Sie alle anderen Daten über Zero Copy zusammen, um den operativen Aufwand beim Erstellen und Verwalten der Aufnahmedatenpipelines zu minimieren.

- **Wichtige Datenaufnahmehäufigkeit:** Wählen Sie die Häufigkeit basierend auf Geschäftswert, Latenzanforderungen und betrieblicher Komplexität aus.

  - Verwenden Sie Echtzeit für zeitkritische Workflows (Personalisierung, Live-Dashboards, Agentforce-Aktionen).
  - Nahezu in Echtzeit für mäßig dringende Prozesse (Kampagnen, Betriebsberichte).
  - Batch für historische oder Low-Velocity-Datensets.

- **Abgleichen des Verbundmusters mit Latenz und Leistung:** Wählen Sie das aus, das Ihren Zugriffsmustern und den 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 die Zwischenspeicherung (beschleunigte Abfrage), wenn Abfragen häufig sind, aber leicht veraltete Ergebnisse akzeptiert werden, was Leistung und Kosten ins Gleichgewicht bringt.
  - 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 zentralisierte Verwaltung entscheidend ist.
  - Verwenden Sie einen Verbund, bei dem eine dezentrale Governance zulässig ist, und erzwingen Sie gleichzeitig eine strenge Governance an der externen Quelle. Zero Copy berücksichtigt Richtlinien auf Quellebene wie Sicherheit auf Zeilenebene und Datenmaskierung.

- **Priorisieren der Aufnahme für hochwertige Workflows:** Wenden Sie die Aufnahme selektiv auf wichtige Prozesse wie die Identitätsbestimmung, behördliche Berichte und die operative Aktivierung an.

- **Kosten und Komplexität bestimmen die Entscheidung:** Die Aufnahme in Echtzeit kann teuer und komplex sein. Architekten sollten die Kosten für die Einarbeitung, Speicherung und Umwandlung von Daten mit den Kosten für die direkte Abfrage über Zero Copy abwägen.

Die Auswahl des richtigen Integrationsmusters – Datenaufnahme, Nullkopie oder hybrider Ansatz – 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 können.

## Produktvergleich

In dieser Tabelle finden Sie einen technischen Vergleich der Muster für die Datenaufnahme und Nullkopie in Salesforce Data 360 mit Fokus auf Funktionen, Kompromissen und Vorteilen sowie Anwendungsfällen und Ergebnissen für Unternehmen. Architekten können dies als Referenz für die Entwicklung hybrider Multi-Cloud-Datenplattformen verwenden, die Leistung, Kosten und Compliance in Einklang bringen.

<table>
  <thead>
    <tr>
      <th align="left" valign="top" width="8%">Mustertyp</th>
      <th align="left" valign="top" width="15%">Modus / Tool</th>
      <th align="left" valign="top" width="12%">Vorteile</th>
      <th align="left" valign="top" width="32%">Überlegungen</th>
      <th align="left" valign="top" width="33%">Ergebnisse</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="left" valign="top"><strong>Datenaufnahme</strong></td>
      <td align="left" valign="top"><strong>Echtzeit:</strong> Latenzaufnahme im Sekundenbereich über Aufnahme-APIs mit CDC-Unterstützung. Kontinuierliche Streaming-Pipelines.</td>
      <td align="left" valign="top">- Sofortige Statistiken<br>- Ideal für Anwendungsfälle mit geringer Latenz und Personalisierung<br>- Unterstützt ereignisgesteuerte Workflows</td>
      <td align="left" valign="top">- Hohe Kosten<br>- Komplexe Architektur<br>- Erfordert Quellsysteme mit niedriger Latenz<br>- Quellen mit hohem Volumen können zu übermäßigem Streaming führen, was zu gesättigten Pipelines führt<br>- I/O intensiv<br>- Ziehen Sie selektive Felder und Filter in Betracht, um den Overhead zu reduzieren</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Echtzeitbetrugswarnungen, Einzelhandelspersonalisierung, operative Warnungen<br><strong>Analysen:</strong><br>- Sekundenschnelle Dashboards, KPI-Überwachung<br><strong>Compliance:</strong><br>- Kontinuierliche Kundendatensatzaktualisierungen für regulierte Workflows</td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top"><strong>Streaming:</strong>Aufnahme von Micro-Batch alle 1–3 Minuten über native Konnektoren</td>
      <td align="left" valign="top">- Ausgewogene Kosten im Vergleich zur Frische<br>- Einfachere Architektur als in Echtzeit<br>- Unterstützt inkrementelle Aktualisierungen</td>
      <td align="left" valign="top">- Leichte Latenz<br>- Kann für wichtige Entscheidungen im Sekundenbereich nicht geeignet sein<br>- Batchgröße wirkt sich auf Speicher/Berechnung aus<br>- I/O ist moderat<br>- Am besten für vorhersehbare, wiederholte Aktualisierungsmuster<br>- Ziehen Sie die Aggregation mit Fenstern in Betracht, um die Verarbeitungslast zu reduzieren</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Rechtzeitige Kampagnenauslöser, Nahezu-Live-Engagement<br><strong>Analysen:</strong><br>- Empfehlungsmodule, Dashboards in Echtzeit<br><strong>Compliance:</strong><br>- Häufige Aktualisierungen mit Überprüfbarkeit</td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top"><strong>Batch:</strong> Geplante Ladevorgänge mit großem Volumen über Konnektoren oder APIs. Unterstützt Objektspeicher und ETL/ELT-Pipelines.</td>
      <td align="left" valign="top">- Kosteneffizient für massive Datensets<br>- Einfach zu implementieren<br>- Zuverlässig für historische Analysen</td>
      <td align="left" valign="top">- Datenlatenz<br>- Für zeitkritische Vorgänge ungeeignet<br>- I/O intensiv bei Lastfenstern<br>- Der Netzwerkdurchsatz kann bei großen Dateien zu einem Engpass werden<br>- Bestens geeignet für historische Aggregations- oder regulierte Berichts-Workflows</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- IT-Support-Tickets (Jira/ServiceNow), aggregierte Workflows<br><strong>Analysen:</strong><br>- Verlaufsanalyse, Trendauswertung<br><strong>Beschwerde:</strong><br>- Regulatorische Berichte, Patienten-/Anspruchsdatenaggregation</td>
    </tr>
    <tr>
      <td align="left" valign="top"><strong>Zero Copy</strong></td>
      <td align="left" valign="top"><strong>Live-Abfrage:</strong>Direkte Abfragen auf externen Systemen; Schema beim Lesen; keine Datenduplizierung</td>
      <td align="left" valign="top">- Maximale Frische<br>- Minimaler Speicheraufwand; unterstützt Echtzeit-Statistiken zum Betrieb</td>
      <td align="left" valign="top">- Abhängig von der Quellleistung<br>- Hohes Abfragevolumen kann sich auf die Latenz auswirken<br>- Ideal für Abfragen mit Prädikat-Pushdown &amp; Aggregation zur Minimierung von E/A<br>- Vermeiden ungefilterter Abfragen bei massiven Datensets</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Dynamische Workflows zur Anpassung an Live-Aktivitäten<br><strong>Analysen:</strong><br>- Operative Dashboards, Live-Berichte<br><strong>Compliance:</strong><br>- Berücksichtigt Sicherheit auf Zeilenebene und Maskierung an der Quelle</td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top"><strong>Beschleunigte Abfrage (Caching):</strong> Lokale Kopien für Verbundabfragen zwischengespeichert. Konfigurierbar von 15 min bis 7 Tagen. Optimierte Abfrageausführung</td>
      <td align="left" valign="top">- Verringert die Latenz<br>- Geringere Kosten als wiederholte Live-Abfragen<br>- Verbessert die Leistung bei häufigen Zugriffsmustern</td>
      <td align="left" valign="top">- Cache-Verwaltung erforderlich<br>- Staleness hängt vom Cache-Intervall ab<br>- Am besten für hochfrequente Abfragen<br>- Nicht geeignet für Entscheidungen im Sekundenbereich</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Voraggregierte Engagementkennzahlen für schnelle Entscheidungen<br><strong>Analysen:</strong><br>- BI-Dashboards, Segmentierung, analytische Berichte<br><strong>Compliance:</strong><br>- Konsistente regulierte Dashboards mit Überwachungsprotokollen</td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top"><strong>Dateiverbund:</strong>Direkter Zugriff auf große historische Datensets in Objektspeichern oder Lakes (S3, Iceberg, Google BigQuery, Redshift).</td>
      <td align="left" valign="top">- Verarbeitet Datensets mit massivem Umfang<br>- Minimaler Speicherplatz in Data 360<br>- Unterstützt AI/ML-Arbeitslasten</td>
      <td align="left" valign="top">- Schreibgeschützt<br>- Die Abfrageleistung hängt vom externen Systemdurchsatz ab<br>- Optimiert für chargenintensive, durchsatzintensive Aufträge<br>- Nicht für Echtzeit-Dashboard geeignet</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- (Nicht typisch – batchlastig)<br><strong>Analysen:</strong><br>- ML/AI-Training, historische Analysen, Berichte auf Petabyte-Skala<br><strong>Compliance:</strong><br>- Gesteuerter Zugriff auf externe Datensets ohne Duplizierung</td>
    </tr>
  </tbody>
</table>

## Data 360-Integrationsmuster

### Datenaufnahme

Bei der Datenaufnahme werden die Daten physisch in Data 360 kopiert und vollständig verwaltet, im Gegensatz zu Zero Copy, wo die Daten an der Quelle verbleiben. Die Berechnung von Transformationen erfolgt in Data 360, was eine zentralisierte Verwaltung und Überprüfung ermöglicht.

#### Anwendungsfälle für die Datenaufnahme

Verwenden Sie die Datenaufnahme, um kanonische, geregelte Datensets in Salesforce Data 360 zu speichern, um die Compliance und die betriebliche Kontrolle zu gewährleisten. Verwenden Sie die Aufnahme, wenn vollständige Kontrolle, Überprüfung und Rückverfolgbarkeit erforderlich sind. Ideal für regulierte oder hochwertige Workflows, bei denen die zentrale Berechnung und Verwaltung entscheidend sind.

Die Aufnahme eignet sich am besten, um eine vertrauenswürdige Grundlage für die Identitätsbestimmung, behördliche Berichte und geschäftskritische AI-gestützte Workflows und Kundenengagement zu schaffen.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360  Ingestion.png" alt="Übersicht über die Datenaufnahme" />

#### Methoden zur Datenaufnahme

Die Methoden zur Datenaufnahme 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. Siehe [Data 360: Integrationen und Konnektoren](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5) für eine vollständige Liste der Data 360-Konnektoren und ihrer verfügbaren Methoden.

- **Echtzeit**
  - Aufnahme im Sekundenbereich mithilfe von Streaming-Pipelines oder der Datenerfassung ändern (CDC).
  - Ideal für zeitkritische Workflows (Betrugserkennung, Personalisierung, betriebliche Dashboards).
  - Übertragen Sie Transformationen und Aggregationen in Data 360, um die nachgelagerten Ein- und Ausgänge zu reduzieren und die Rechennutzung zu optimieren. Verwenden Sie die inkrementelle CDC, um die Datenvermischung zu minimieren.
- **Streaming**
  - Aufnahme alle 1–3 Minuten in kleinen Schritten.
  - Gleicht Frische und Kosten aus und eignet sich für die Kampagnenorchestrierung, die Interaktion beinahe live und für operative Berichte.
  - Verwenden Sie Micro-Batchs zum Steuern von E/A-Spitzen. Aggregieren Sie Daten nach Möglichkeit an der Quelle, um das Übertragungsvolumen zu reduzieren und den Speicher zu optimieren.
- **Batch (Geplante Ladungen)**
  - Regelmäßige Aufnahme großer Datensets (stündlich, täglich, wöchentlich).
  - Kosteneffizient und zuverlässig für historische Datensets, behördliche Berichte und Compliance-Anwendungsfälle.
  - Stellen Sie sicher, dass die Gebietsschemata in derselben Region wie der Quellspeicher liegen, um die Leistung und die Kosten zu optimieren.

#### Architect Playbook (Playbook für Architekten)

- **Anwendungsfälle für die Datenaufnahme**
  - **Zusammengeführte Customer 360 Profile generieren:** Erstellen einer einzigen Datenquelle für die Identität und Attribute von Kunden.
  - **Verwalten von Datensets zur Einhaltung gesetzlicher Vorschriften:** Erzwingung von Governance, Abstammung und Überprüfbarkeit für sensible Daten.
  - **Kampagnenorchestrierung zentralisieren:** Sicherstellen, dass Marketing, Vertrieb und Service alle über konsistente, vertrauenswürdige Datensets funktionieren.
- **Designpraktiken**
  - Bevorzugen Sie die Batch-Aufnahme für historische oder latenzarme Anforderungen, beispielsweise 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, statt ganze Datensets neu zu laden, um Kosten und Effizienz zu optimieren.
  - 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**
  - **Echtzeitaufnahme:** Höchste Rechen- und Pipeline-Kosten; gerechtfertigt für hochwertige, zeitkritische Workflows wie Personalisierung, betriebliche Dashboards oder Agentforce Aktionen.
  - **Streaming-Aufnahme:** Moderate Rechen- und Speicherkosten; geeignet für häufige Aktualisierungen, die leichte Verzögerungen tolerieren können, beispielsweise Kampagnenorchestrierung oder operative Berichte.
  - **Batch-Aufnahme:** Geringere Rechenkosten, vorhersehbarer Speicherplatz; am besten für historische Datensets oder Aktualisierungen mit geringer Häufigkeit. Die Aufnahme von Batch-Daten aus Salesforce-Organisationen mit bestimmten Konnektoren ist kostenlos.
  - **Aktualisierungsmodus:** Durch Auswahl des Modus "Inkrementelle Aktualisierung" werden die Gesamtaufnahme- und Berechnungskosten reduziert. Es 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:** Nehmen Sie Datensets auf, die für die Kenntnis Ihres Kunden, die Bekämpfung der Geldwäsche und die Betrugserkennung erforderlich sind, wobei Überprüfbarkeit und Compliance nicht verhandelbar sind.
  - **Gesundheitswesen:** Verwenden Sie die Aufnahme für die Patientenidentitätsbestimmung und HIPAA-konforme Datensätze, um sichere, vereinheitlichte Ansichten zu ermöglichen.
  - **Einzelhandel:** Konsolidieren von Point of Sale (POS), E-Commerce und Treueprogrammdaten in vereinheitlichten Profilen zur Segmentierung und Personalisierung
  - **Telecom:** Unterstützen Sie Abwanderungsprävention und Nutzungsanalysen mit kanonischen, geregelten Abonnentendaten.

#### Entscheidungskriterien für die Datenaufnahmemethode

<table>
<thead>
<tr>
<th>Funktion</th>
<th>Echtzeitaufnahme</th>
<th>Streaming-Aufnahme</th>
<th>Batchaufnahme</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Latenz und Frische</strong></td>
<td>Aufnahme von Latenzzeiten im Sekundenbereich über Aufnahme-APIs mit Unterstützung der Datenerfassung (CDC). Bietet kontinuierliche Streaming-Pipelines. Ideal für operative Anwendungsfälle mit geringer Latenz.</td>
<td>Micro-Batch-Aufnahme alle 1–3 Minuten über native Konnektoren. Unterstützt inkrementelle Aktualisierungen. Es wird eine leichte Latenz erwartet.</td>
<td>Es wird eine Datenlatenz erwartet. Geplante Ladungen mit großem Volumen. Regelmäßige Aufnahme (stündlich, täglich, wöchentlich). Für zeitkritische Vorgänge ungeeignet.</td>
</tr>
<tr>
<td><strong>Primäre Anwendungsfälle</strong></td>
<td>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.</td>
<td>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.</td>
<td>Kosteneffizient für massive Datensets. Zuverlässig für historische Analysen. Wird für historische Aggregations- oder regulierte Berichts-Workflows verwendet. Bestens geeignet für historische Datensets oder Datensets mit geringer Geschwindigkeit.</td>
</tr>
<tr>
<td><strong>Architekturkomplexität und I/O</strong></td>
<td>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.</td>
<td>Einfachere Architektur als in Echtzeit. I/O ist moderat. Bestens geeignet für vorhersehbare, wiederholte Aktualisierungsmuster. Die Batchgröße wirkt sich auf den Speicher/die Berechnung aus.</td>
<td>Einfach zu implementieren. I/O-intensiv bei Lastfenstern. Der Netzwerkdurchsatz kann bei großen Batches zu einem Engpass werden.</td>
</tr>
<tr>
<td><strong>Überlegungen zu Kosten</strong></td>
<td>Höchste Rechen- und Pipeline-Kosten. Nur für hochwertige, zeitkritische Workflows gerechtfertigt.</td>
<td>Moderieren Sie Berechnungs- und Speicherkosten. Bietet einen ausgewogenen Ansatz für Kosten und Frische. Geeignet für häufige Aktualisierungen, die leichte Verzögerungen vertragen.</td>
<td>Geringere Rechenkosten und vorhersehbarer Speicher. Empfohlen für historische Datensets oder Aktualisierungen mit geringer Häufigkeit. Die Aufnahme über interne Salesforce-Pipelines ist kostenlos.</td>
</tr>
<tr>
<td><strong>Designpraktiken</strong></td>
<td>Verwenden Sie die inkrementelle CDC, um die Datenvermischung zu minimieren. Filtern und verwenden Sie selektive Felder, um den Overhead zu reduzieren.</td>
<td>Verwenden Sie Micro-Batchs zum Steuern von E/A-Spitzen. Ziehen Sie die Aggregation mit Fenstern in Betracht, um die Verarbeitungslast zu reduzieren.</td>
<td>Bevorzugen Sie dies für Archivberichte oder regelmäßige Snapshots. Stellen Sie sicher, dass die Berechnungslokalität in derselben Region wie der Quellspeicher liegt, um die Kosten zu optimieren.</td>
</tr>
</tbody>
</table>

### Zero Copy Data Federation (Zero Copy-Datenverbund)

#### Zero Copy-Anwendungsfälle

Verwenden Sie Zero Copy 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 am besten für Live-Dashboards, explorative Analysen, AI/ML-Modellschulungen und Echtzeit-Kundenengagement direkt über Salesforce Data 360.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360 Zero Copy.png" alt="Zero Copy Data Federation – Übersicht" />

#### Nullkopiemethoden

Bei Verwendung von Zero Copy müssen Architekten sich zudem zwischen drei verfügbaren Datenverbundmethoden entscheiden, von denen jede ihre eigenen Kompromisse zwischen Frische, Leistung und Kosten bietet.

- **Live-Abfrage**
  - Führt Abfragen direkt gegen externe Systeme (Snowflake, Google BigQuery, Redshift, Databricks usw.) ohne Datenduplizierung aus.
  - Optimal, wenn Prädikate und Aggregationen nach unten geschoben werden können, wodurch die Datenbewegung über das Netzwerk minimiert und die Ein-/Ausgaben für den Salesforce Data 360-Berechnungsvorgang reduziert werden.
  - Bestens 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 Latenzzeiten für häufig aufgerufene Datensets mit konfigurierbarer Dauer (Minuten bis Tage).
  - Die Daten werden nicht dauerhaft kopiert oder vollständig verwaltet. Die Aktualisierung wird über geplante Aktualisierungen aus der Quelle verwaltet.
- **Dateiverbund**
  - Bietet direkten schreibgeschützten Zugriff auf umfangreiche Datensets in Objektspeichern (z. B. S3, GCS mit Iceberg).
  - Ideal 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 generieren, wenn sie nicht optimiert sind.

#### Architect Playbook (Playbook für Architekten)

- **Anwendungsfälle**
  - **Echtzeitpersonalisierung und adaptive Workflows:** Stellen Sie dynamische Angebote, Empfehlungen und Next-Best-Aktionen bereit, wenn sich das Kundenverhalten ändert.
  - **Live-Dashboards und Betriebsanalysen:** Stellen Sie geschäftskritische Dashboards und KPIs direkt aus externen Lagerhäusern bereit.
  - **AI/ML-Modelltraining mit großen externen Datensets:** Nutzen Sie Petabyte-Skalierungsdaten aus Data Lakes und Lagerhäusern mithilfe des Dateiverbunds, ohne sie 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, bei denen 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 Partitionszuschnitte und Filter in Betracht.
  - **Dateiverbund**
    - Greifen Sie ohne Aufnahme auf Datensets im Petabyte-Bereich in Objektspeichern zu.
    - Behalten Sie den Objektspeicher in derselben Cloud-Region wie Salesforce compute bei, um Latenz- und Ausgangskosten zu minimieren.
    - 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 und so die Datenbewegung zu reduzieren.
    - Vermeiden Sie bei Bedarf regionsübergreifenden Datenzugriff, da er die Ein-/Ausgabe, die Latenz und die 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 Sicherheitsrichtlinien auf Zeilenebene und Maskierungsrichtlinien direkt in Verbundsystemen nutzen. Im Folgenden finden Sie bewährte Vorgehensweisen für einheitliches RLS und Maskierung über mehrere Plattformen hinweg.
    - **Verwenden einer zentralisierten Unternehmens-ID:** Ordnen Sie Benutzer und Einheiten in Salesforce Data 360 einer eindeutigen, zentralisierten Unternehmenskennung zu, die Identitäten in externen Systemen entspricht.
    - **Ausrichten von Sicherheitsrichtlinien:** Stellen Sie sicher, dass Sicherheits- und Maskierungsrichtlinien auf Zeilenebene in Verbundsystemen basierend auf der zugeordneten Identität angewendet werden. Dadurch wird die Compliance beim Abfragen externer Daten beibehalten.
    - **Standardisieren von 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:** Pay-per-Query-Modell: Kosten fallen bei der Berechnung externer Lakehouse-Rechner an und können bei hoher QPS in die Höhe schnellen. Ideal für frischekritische Anwendungsfälle, in denen der Wert größer ist als die Kostenvariabilität.
  - **Beschleunigte Abfrage (Zwischenspeicherung):** Senkt die Abfragekosten im Vergleich zur Live-Abfrage, indem Treffer im Quellsystem reduziert werden, erhöht jedoch die Kosten für die Batch-Datenaufnahme beim Füllen und Aktualisieren des Cache. Bestens geeignet für häufig aufgerufene Datensets.
  - **Dateiverbund:** Günstigste Speicheroption als Daten im Objektspeicher, die Abfragekosten hängen jedoch von der Dateigröße, der Partitionierung und dem Zuschnitt ab. Ideal für historische Daten oder Massendaten im Petabyte-Bereich.

#### Entscheidungskriterien für Nullkopiemethode

<table>
<thead>
<tr>
<th>Entscheidungspunkt</th>
<th>Live-Abfrage</th>
<th>Zwischenspeicherung (beschleunigte Abfrage)</th>
<th>Dateiverbund</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Datenquellenstandort</strong></td>
<td>Externe Data Lakehouses (Snowflake, Google BigQuery, Redshift, Databricks).</td>
<td>Externe Data Lakehouses (Snowflake, Google BigQuery, Redshift, Databricks)</td>
<td>Objektspeicher oder Cloud-Data-Lakes (S3, ADLS, GCS) verwenden häufig offene Tabellenformate wie Iceberg.</td>
</tr>
<tr>
<td><strong>Zweck/Anwendungsfall</strong></td>
<td>Ideal für interaktive Analysen und Echtzeit-Dashboards. Bestens geeignet für Echtzeitpersonalisierung und dynamische Workflows.</td>
<td>Am besten geeignet für häufige Abfragen, aber leicht veraltete Ergebnisse. Geeignet für BI-Dashboards und Segmentierung.</td>
<td>Bestens geeignet für die Batchverarbeitung im großen Umfang und für AI/ML-Modellschulungen. Ideal für historische Analysen und Berichte auf Petabyte-Skala.</td>
</tr>
<tr>
<td><strong>Frisch/Latenz</strong></td>
<td>Maximale Aktualität; Abfragen werden direkt in Echtzeit ausgeführt. Unterstützt Entscheidungen in Sekundenschnelle.</td>
<td>Etwas veraltete Ergebnisse sind akzeptabel. Die Aktualisierung hängt vom Cache-Intervall ab, das zwischen 15 Minuten und 7 Tagen konfiguriert werden kann.</td>
<td>Optimiert für chargenintensive, durchsatzintensive Aufträge. Nicht für Echtzeit-Dashboards geeignet.</td>
</tr>
<tr>
<td><strong>Zugriffsmuster</strong></td>
<td>Ideal für seltene oder Ad-hoc-Abfragen. Wird für Abfragen mit hoher Qualität (Abfrage pro Sekunde) und geringer Latenz verwendet, bei denen die Aktualität entscheidend ist.</td>
<td>Ideal für Szenarien mit hoher Lesehäufigkeit. Verbessert die Leistung bei häufigen Zugriffsmustern.</td>
<td>Schreibgeschützter Zugriff. Geeignet für Datensets im Petabyte-Bereich ohne Aufnahme.</td>
</tr>
<tr>
<td><strong>Leistungstreiber</strong></td>
<td>Stark von der Leistung des externen Quellsystems abhängig. Optimiert, wenn Prädikate und Aggregationen in die Quelle übertragen werden können.</td>
<td>Verringert die Latenz im Vergleich zu wiederholten Live-Abfragen. Die Leistung hängt von der Cache-Verwaltung und dem Intervall ab.</td>
<td>Die Leistung hängt stark vom Objektformat, der Partitionierung und dem externen Systemdurchsatz ab. Verwenden Sie partitionierte, spaltenförmige Formate (Parquet/ORC).</td>
</tr>
<tr>
<td><strong>Kostenauswirkungen</strong></td>
<td>Pay-per-Query-Modell. Die Kosten fallen bei der Berechnung externer Lakehouse-Instanzen an. Kostengünstig für seltene Abfragen, aber die Ausgaben können bei hohem Query per Second-Volumen (QPS) steigen.</td>
<td>Geringere Kosten als bei wiederholten Live-Abfragen. Verringert die Notwendigkeit, die externe Quelle wiederholt abzufragen. Fügt Cache-Speicher und Aktualisierungs-Overhead hinzu.</td>
<td>Günstigste Speicheroption. Die Abfragekosten hängen von der Dateigröße und der Partitionierung ab.</td>
</tr>
<tr>
<td><strong>Wichtige Überlegungen</strong></td>
<td>Vermeiden Sie ungefilterte Abfragen, die unnötig große Datenvolumen scannen.</td>
<td>Erfordert die Cache-Verwaltung. Nicht für Entscheidungen im Sekundenbereich geeignet.</td>
<td>Die Abfrageleistung hängt stark von der Optimierung über Partitionierung und Pushdown-Prädikate ab.</td>
</tr>
</tbody>
</table>

### Hybridansatz

Mit hybriden Architekturen können Architekten wichtige Datensets in Data 360 für eine zentralisierte Verwaltung verankern und 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.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Copy of Hybrid.png" alt="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, schließen Sie sich jedoch für die betriebliche Agilität zusammen.
- **Branchenszenarien**
  - **Einzelhandel:** Verwenden Sie die Aufnahme für die Identitätsbestimmung und die Profilvereinheitlichung. Verbinden Sie sie für Echtzeitangebote und Personalisierungen.
  - **Gesundheitswesen:** Verwalten Sie goldene Patientenakten über die Aufnahme, während Sie IoT-Geräteströme und Sensordaten verknüpfen, um einen unmittelbaren Kontext zu erhalten.
  - **Financial Services:** Nehmen Sie regulierte Daten in einen konformitätsgesteuerten See auf, während Sie externe Abfragen zur Betrugserkennung und Risikoüberwachung verknüpfen.
- **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öglichen Sie es externen Lakehouses, Datenzugriff in Echtzeit oder in großem Umfang ohne Duplikate bereitzustellen.
  - **Balance Cost vs. Leistung:** Profilieren Sie Arbeitslasten, um zu entscheiden, was im Vergleich zum Verbund aufgenommen werden soll, wodurch unnötige Speicher- oder Abfragekosten minimiert werden.
  - **Anwenden der mehrschichtigen Unternehmensführung:** Erzwingen Sie die zentralisierte Verwaltung für aufgenommene Daten und nutzen Sie gleichzeitig die eigenen Sicherheitssteuerungen von Verbundsystemen (z. B. RLS, Maskierung).
  - Stellen Sie beim Entwerfen von hybriden Pipelines sicher, dass historische Datensets inkrementell aufgenommen werden, und übertragen Sie Aggregationen oder Filter an Verbundquellen, um die E/A- und Berechnungsnutzung zu optimieren.
- **Überlegungen zu Kosten**
  - Optimieren Sie die Gesamtkosten im Vergleich zur Leistung, 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 zum Reduzieren der Rechenkosten in Quellsystemen wiederholter Abfragen die Zwischenspeicherung (beschleunigte Abfrage) für Verbunddatensets mit hohem Lesezugriff.

## Leitfaden zur Anwendungsfallentscheidung

Im Folgenden finden Sie allgemeine Archetypen, die die Anwendung dieser Logik veranschaulichen.

1. **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 vertrauenswürdige Quelle für alle Marketing- und Serviceinteraktionen.
   - **Empfohlenes Muster:** **Datenaufnahme.** Die Priorität liegt auf Governance, Trust und Kontrolle. 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.
2. **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 zu langsam und teuer.
   - **Empfohlenes Muster:** **Zero Copy Federation.** Priorität haben Geschwindigkeit, Agilität und Kosteneffizienz im richtigen Maßstab. Zero Copy ermöglicht es Ihnen, die immense Leistungsfähigkeit Ihres vorhandenen Data Warehouse für Echtzeitabfragen zu nutzen, ohne den Aufwand und die Latenz der Datenduplizierung zu erhöhen.
3. **Der Archetyp "Hybridintelligenz": Verwalten des Kerns, Zusammenführen des Kerns**
   - **Szenario:** Sie möchten Ihre verwalteten, aufgenommenen Kundenprofile mit Echtzeit-Verhaltenssignalen (wie 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 den stabilen, geregelten Kern Ihrer Kundendaten zu erstellen. Verwenden Sie dann Zero Copy, um die volatilen Echtzeit-"Edge"-Daten zu verknüpfen und sie zur Abfragezeit 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. Die Auswahl der richtigen Datenintegrationsmethode für jedes Quelldatensystem auf der Grundlage der Geschäftsanforderungen führt häufig zu einem hybriden Ansatz, der die Stärken der Datenaufnahme und der Datenverknüpfung kombiniert.

- Nehmen Sie geschäftskritische, geregelte Datensets in Salesforce Data 360 auf, um Compliance, Identitätsbestimmung und betriebliche Workflows zu gewährleisten.
- Verbinden Sie Daten über Zero Copy für Live-, explorative und AI-gestützte Analysen, ohne Speicherplatz zu duplizieren.

Salesforce Data 360 in Hyperforce bietet Widerstandsfähigkeit und Skalierbarkeit für mehrere Regionen. Das offene Lakehouse mit Iceberg-Tabellen ermöglicht die Berechnungstrennung und Interoperabilität mit Plattformen wie Snowflake, Databricks und S3 Iceberg und bildet das Rückgrat eines wirklich interoperablen Datenökosystems mit mehreren Clouds.

Während sich Datenökosysteme weiterentwickeln, halten Sie Aktualisierung, Kosten, Leistung und Compliance kontinuierlich im Gleichgewicht, um die architektonische Agilität aufrechtzuerhalten. Sorgen Sie dafür, dass Ihre Plattform zukunftssicher ist, indem Sie erfasste, geregelte Daten mit Verbundzugriff vereinheitlichen. Dies ermöglicht Echtzeitintelligenz, AI-Aktivierung und Personalisierung im Unternehmensbereich über Clouds, Regionen und Geschäftsdomänen hinweg.

Lösungen, die für alle geeignet sind, eignen sich für die meisten Unternehmen nicht. Die optimale Strategie ordnet das richtige Muster dem richtigen Geschäftstreiber zu.

## Über die Autoren

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.

Jan Fernando ist Principal Architect im Büro des Chief Architect bei Salesforce. Seit 2012 ist er bei Salesforce tätig und verfügt über umfangreiche Erfahrungen aus seiner Zeit im Startup-Ökosystem. Bevor er in das Büro des Chefarchitekten eintrat, verbrachte er über ein Jahrzehnt in der Plattformorganisation, wo er mehrere wichtige Technologietransformationen leitete.

<!-- document id=e071ec6a3af2f5750dbd9e8c944e75d4c5270be353ae7c75782f6895ac14e1ae url=/architect/next/de-de/decision-guides/guides/data-integration.md -->

## Leitfadenübersicht

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.

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/reliable#leistung) 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.

<table>
    <thead>
        <tr>
            <th>Zu berücksichtigender Bereich</th>
            <th>Allgemeine Fragen</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Vorhandene Tools und Landschaft</td>
            <td>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)?</td>
        </tr>
        <tr>
            <td>Datenfluss (Zeiteinteilung, erwartete Benutzererfahrung, Richtung)</td>
            <td>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?</td>
        </tr>
        <tr>
            <td>Implementierung</td>
            <td>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?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/de-de/well-architected/guide/intentional#wartungsfähigkeit">Wartbarkeit</a></td>
            <td>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?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/de-de/well-architected/guide/reliable#datenvolumen">Datenvolumen</a></td>
            <td>Wie viele Daten sind an der Integration beteiligt? Arbeiten Sie mit <a href="https://trailhead.salesforce.com/content/learn/modules/large-data-volumes">Large Data Volumes</a> (LDV)? Wie häufig werden Änderungen per Massenvorgang vorgenommen? Welche Auswirkungen haben Singleton-Aktualisierungen? Wie oft werden sie auftreten?</td>
        </tr>
        <tr>
            <td>Obergrenzen</td>
            <td>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 im Voraus für das Laden von Massendaten geplant (Beispiel: anfängliches Laden von Daten für eine neue Instanz)?</td>
        </tr>
    </tbody>
</table>

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

<table>
    <thead>
        <tr>
            <th></th>
            <th>Von Salesforce zum externen System</th>
            <th>Vom externen System zu Salesforce</th>
            <th>Ausführung</th>
            <th>Zusätzliche Lizenz erforderlich</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex Aktionen</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Nein</td>
        </tr>
        <tr>
            <td><strong>Datenerfassung ändern</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-no">Nicht verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Nein*</td>
        </tr>
        <tr>
            <td><strong>Benutzerdefiniertes Apex (REST- und SOAP-Webservices)</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Nein</td>
        </tr>
        <tr>
            <td><strong>Externe Services</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-no">Nicht verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Nein</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Ja</td>
        </tr>
        <tr>
            <td><strong>Daten 360</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Ja</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Ja</td>
        </tr>
        <tr>
            <td><strong>Native Salesforce-APIs</strong></td>
            <td class="guide-table-no">Nicht verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Nein</td>
        </tr>
        <tr>
            <td><strong>OmniScript</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-no">Clientseitig***</td>
            <td>Ja</td>
        </tr>
        <tr>
            <td><strong>OmniStudio-Integrationsverfahren</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Ja</td>
        </tr>
        <tr>
            <td><strong>Ausgehendes Messaging</strong></td>
            <td>Nicht ideal</td>
            <td class="guide-table-no">Nicht verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Nein</td>
        </tr>
        <tr>
            <td><strong>Plattformereignisse</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Nein**</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Externe Objekte</strong></td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Verfügbar</td>
            <td class="guide-table-ok">Serverseitig</td>
            <td>Ja</td>
        </tr>
    </tbody>
</table>

[\*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, die möglicherweise beim Verschieben von Daten in Salesforce und aus Salesforce beteiligt sind:

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

<table>
    <thead>
        <tr>
            <th></th>
            <th>Anleitung</th>
            <th>Lizenzierung</th>
            <th>Zeitpunkt</th>
            <th>Volumen und Skalierung</th>
            <th></th>
            <th>Lieferung &amp; Wartung</th>
            <th></th>
            <th></th>
            <th>Datenschutz und Sicherheit</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Anwendungszeitpunkt</strong></th>
            <th><strong>Zusätzliche Lizenz</strong></th>
            <th><strong>Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen)</strong></th>
            <th><strong>Unterstützung von mehreren Objekten</strong></th>
            <th><strong>LDV/Masse</strong></th>
            <th><strong>Testen und Bereitstellen**</strong></th>
            <th><strong>Debugging</strong></th>
            <th><strong>Eingebautes Fehlerverarbeitungs-/Wiederholungsverhalten</strong></th>
            <th><strong>Kann mit im Leerlauf verschlüsselten Daten verwendet werden</strong></th>
            <th><strong>Authentifizierungsprotokoll</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Datenerfassung ändern</strong></td>
            <td>Wenn Sie in Salesforce vorgenommene Änderungen auf Datensatzebene in einem externen System veröffentlichen müssen und keine benutzerdefinierte Nutzlast benötigen.</td>
            <td>Erforderlich</td>
            <td>Asynchron</td>
            <td>Nein</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Externe Services</strong></td>
            <td>Wenn Sie einen Prozess mit Flow, Apex, Einstein Bots oder OmniStudio orchestrieren, werden die APIs des externen Systems mit OpenAPI-Spezifikationen beschrieben.</td>
            <td>Nicht erforderlich</td>
            <td>Sync</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td>N/A</td>
            <td>Anmeldeinformationen mit Namen</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Asynchron</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td>Mit Proficode-Tools</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja, über Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>OmniStudio-Integrationsverfahren</strong></td>
            <td>Wenn Sie Daten ohne Benutzerinteraktion umwandeln und die Leistung durch Verarbeitung auf dem Server statt im Browser verbessern müssen.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Deklarative Unterstützung</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Anmeldeinformationen mit Namen</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Externe Objekte</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Sync</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja*</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools und deklarativer Verfolgung</td>
            <td>Nein</td>
            <td>N/A</td>
            <td>Anmeldeinformationen mit Namen</td>
        </tr>
        <tr>
            <td colspan="11">* Für Odata Adapter, die älter als Version 4.01 sind, gelten Callout-Obergrenzen. Weitere Details finden Sie unter <a href="https://help.salesforce.com/s/articleView?id=platform.odata_general_limits.htm&type=5">Überlegungen zur Odata Callout Rate Limit</a> (Obergrenze für Odata-Callouts). ** Testen und Bereitstellen bezieht sich auf die Möglichkeit, in einer niedrigeren Umgebung zu erstellen und über die <a href="https://developer.salesforce.com/docs/metadata-coverage/">Metadaten-API</a>, Pakete oder Änderungssets in der Produktion bereitzustellen.</td>
        </tr>
    </tbody>
</table>

### 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

<table>
    <thead>
        <tr>
            <th></th>
            <th>Anleitung</th>
            <th>Lizenzierung</th>
            <th>Zeitpunkt</th>
            <th>Volumen und Skalierung</th>
            <th></th>
            <th>Lieferung &amp; Wartung</th>
            <th></th>
            <th></th>
            <th>Datenschutz und Sicherheit</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Anwendungszeitpunkt</strong></th>
            <th><strong>Zusätzliche Lizenz</strong></th>
            <th><strong>Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen)</strong></th>
            <th><strong>Unterstützung von mehreren Objekten</strong></th>
            <th><strong>LDV/Masse</strong></th>
            <th><strong>Testen und Bereitstellen**</strong></th>
            <th><strong>Debugging</strong></th>
            <th><strong>Eingebautes Fehlerverarbeitungs-/Wiederholungsverhalten</strong></th>
            <th><strong>Kann mit im Leerlauf verschlüsselten Daten verwendet werden</strong></th>
            <th><strong>Authentifizierungsprotokoll</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex Aktionen</strong></td>
            <td>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.</td>
            <td>Nicht erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mehrere</td>
        </tr>
        <tr>
            <td><strong>Ereignisweiterleitungen</strong></td>
            <td>Wenn Sie Plattformereignisse und Ereignisse der Datenerfassung über Salesforce an Amazon EventBridge senden müssen. Ereignisweiterleitungen stellen nur eine Verbindung mit AWS Eventbridge her</td>
            <td>Nein</td>
            <td>Asynchron</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>HTTP/1.1 mit TLS</td>
        </tr>
        <tr>
            <td><strong>Ausgehendes Messaging</strong></td>
            <td>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.</td>
            <td>Nicht erforderlich</td>
            <td>Asynchron</td>
            <td>Nein</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Deklarative Unterstützung</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Bidirektionales TLS</td>
        </tr>
        <tr>
            <td><strong>Plattformereignisse</strong></td>
            <td>Wenn Sie eine benutzerdefinierte, strukturierte Nutzlast für Änderungen nahezu in Echtzeit in Salesforce oder einem externen System benötigen.</td>
            <td>Nicht erforderlich*</td>
            <td>Asynchron</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Externe Objekte (mit benutzerdefinierten Apex Adaptern)</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td>N/A</td>
            <td>Mehrere</td>
        </tr>
         <tr>
            <td><strong>Daten 360</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mehrere</td>
        </tr>
    </tbody>
</table>

[\* 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

<table>
    <thead>
        <tr>
            <th></th>
            <th>Anleitung</th>
            <th>Lizenzierung</th>
            <th>Zeitpunkt</th>
            <th>Volumen und Skalierung</th>
            <th></th>
            <th>Lieferung &amp; Wartung</th>
            <th></th>
            <th></th>
            <th>Datenschutz und Sicherheit</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Anwendungszeitpunkt</strong></th>
            <th><strong>Zusätzliche Lizenz</strong></th>
            <th><strong>Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen)</strong></th>
            <th><strong>Unterstützung von mehreren Objekten</strong></th>
            <th><strong>LDV/Masse</strong></th>
            <th><strong>Testen und Bereitstellen**</strong></th>
            <th><strong>Debugging</strong></th>
            <th><strong>Eingebautes Fehlerverarbeitungs-/Wiederholungsverhalten</strong></th>
            <th><strong>Kann mit im Leerlauf verschlüsselten Daten verwendet werden</strong></th>
            <th><strong>Authentifizierungsprotokoll</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Benutzerdefinierter Apex</strong></td>
            <td>Wenn Sie mehr Funktionen benötigen, als in Low-Code-Tools verfügbar sind.</td>
            <td>Nicht erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja*</td>
            <td>Mehrere</td>
        </tr>
        <tr>
            <td><strong>Externe Services</strong></td>
            <td>Die Integration aus Code in externe System-APIs wird mit OpenAPI-Spezifikationen beschrieben.</td>
            <td>Nicht erforderlich</td>
            <td>Sync</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td>N/A</td>
            <td>Mehrere</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja*</td>
            <td>Mehrere</td>
        </tr>
    </tbody>
</table>

\* 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

<table>
    <thead>
        <tr>
            <th></th>
            <th>Anleitung</th>
            <th>Lizenzierung</th>
            <th>Zeitpunkt</th>
            <th>Volumen und Skalierung</th>
            <th></th>
            <th>Lieferung &amp; Wartung</th>
            <th></th>
            <th></th>
            <th>Datenschutz und Sicherheit</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Wann zu verwenden</th>
            <th>Zusätzliche Lizenz</th>
            <th>Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen)</th>
            <th>Unterstützung für mehrere Objekte</th>
            <th>LDV/Bulk</th>
            <th>Testen und Bereitstellen*</th>
            <th>Debugging</th>
            <th>Integriertes Fehlerverarbeitungs-/Wiederholungsverhalten</th>
            <th>Kann mit im Leerlauf verschlüsselten Daten verwendet werden</th>
            <th>Authentifizierungsprotokoll</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Asynchron</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td>Mit Pro-Code-Tools</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja, über Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>OmniStudio-Integrationsverfahren</strong></td>
            <td>Wenn Sie Daten aus Drittanbieterquellen ohne Benutzerinteraktion importieren und umwandeln müssen.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Deklarative Unterstützung</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Anmeldeinformationen mit Namen</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Externe Objekte</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Sync</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td>N/A</td>
            <td>Mehrere</td>
        </tr>
    </tbody>
</table>

\* 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

<table>
    <thead>
        <tr>
            <th></th>
            <th>Anleitung</th>
            <th>Lizenzierung</th>
            <th>Zeitpunkt</th>
            <th>Volumen und Skalierung</th>
            <th></th>
            <th>Lieferung &amp; Wartung</th>
            <th></th>
            <th></th>
            <th>Datenschutz und Sicherheit</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Wann zu verwenden</th>
            <th>Zusätzliche Lizenz</th>
            <th>Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen)</th>
            <th>Unterstützung für mehrere Objekte</th>
            <th>LDV/Bulk</th>
            <th>Testen und Bereitstellen**</th>
            <th>Debugging</th>
            <th>Integriertes Fehlerverarbeitungs-/Wiederholungsverhalten</th>
            <th>Kann mit im Leerlauf verschlüsselten Daten verwendet werden</th>
            <th>Authentifizierungsprotokoll</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Plattformereignisse</strong></td>
            <td>Wenn Sie eine benutzerdefinierte, strukturierte Nutzlast für Änderungen nahezu in Echtzeit in Salesforce oder einem externen System benötigen.</td>
            <td>Nicht erforderlich*</td>
            <td>Asynchron</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Externe Objekte (mit benutzerdefinierten Apex Adaptern)</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td>N/A</td>
            <td>Mehrere</td>
        </tr>
        <tr>
            <td><strong>Daten 360</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mehrere</td>
        </tr>
    </tbody>
</table>

- [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

<table>
    <thead>
        <tr>
            <th></th>
            <th>Anleitung</th>
            <th>Lizenzierung</th>
            <th>Zeitpunkt</th>
            <th>Volumen und Skalierung</th>
            <th></th>
            <th>Lieferung &amp; Wartung</th>
            <th></th>
            <th></th>
            <th>Datenschutz und Sicherheit</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Wann zu verwenden</th>
            <th>Zusätzliche Lizenz</th>
            <th>Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen)</th>
            <th>Unterstützung für mehrere Objekte</th>
            <th>LDV/Bulk</th>
            <th>Testen und Bereitstellen****</th>
            <th>Debugging</th>
            <th>Integriertes Fehlerverarbeitungs-/Wiederholungsverhalten</th>
            <th>Kann mit im Leerlauf verschlüsselten Daten verwendet werden</th>
            <th>Authentifizierungsprotokoll</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Benutzerdefinierte Apex REST &amp; SOAP Web Services</strong></td>
            <td>Wenn Sie mehr Funktionen benötigen, als von den nativen API-Endpunkten bereitgestellt werden, beispielsweise die objektübergreifende Verarbeitung oder andere komplexe Logik.</td>
            <td>Nicht erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja***</td>
            <td>Mehrere</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja***</td>
            <td>Mehrere</td>
        </tr>
        <tr>
            <td><strong>Native Salesforce-APIs</strong></td>
            <td>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.</td>
            <td>Nicht erforderlich*</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja*****</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td class="guide-table-ok">Ja**</td>
            <td class="guide-table-ok">Ja***</td>
            <td>Mehrere</td>
        </tr>
    </tbody>
</table>

\* 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

<table>
    <thead>
        <tr>
            <th></th>
            <th>Anleitung</th>
            <th>Kosten</th>
            <th>Zeitpunkt</th>
            <th>Volumen und Skalierung</th>
            <th></th>
            <th></th>
            <th>Lieferung &amp; Wartung</th>
            <th></th>
            <th>Datenschutz und Sicherheit</th>
            <th></th>
            <th>Zu implementierende Tools</th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Anwendungszeitpunkt</strong></th>
            <th><strong>Zusätzliche Lizenz</strong></th>
            <th><strong>Synchronisierung (Anforderung/Antwort) oder Asynchronisierung (Auslösen/Vergessen)</strong></th>
            <th><strong>Unterstützung von mehreren Objekten</strong></th>
            <th><strong>LDV/Masse</strong></th>
            <th><strong>Testen und Bereitstellen*</strong></th>
            <th><strong>Debugging</strong></th>
            <th><strong>Eingebautes Fehlerverarbeitungs-/Wiederholungsverhalten</strong></th>
            <th><strong>Kann mit im Leerlauf verschlüsselten Daten verwendet werden</strong></th>
            <th><strong>Authentifizierungsprotokoll</strong></th>
            <th><strong>Niedriger Code → Pro Code</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>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</td>
            <td>Erforderlich</td>
            <td>Asynchron</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Nein</td>
            <td>Mit Pro-Code-Tools</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja, über Shield Connect</td>
            <td>OAuth</td>
            <td>Low Code (Niedriger Code)</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>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</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja**</td>
            <td>Mehrere</td>
            <td>Pro-Code</td>
        </tr>
        <tr>
            <td><strong>Native Salesforce-APIs</strong></td>
            <td>Wenn Salesforce oder Heroku Connect keine Option sind oder Sie eine komplexere Verarbeitung benötigen</td>
            <td>Nicht erforderlich</td>
            <td>Beides</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja**</td>
            <td>Mehrere</td>
            <td>Pro-Code</td>
        </tr>
        <tr>
            <td><strong>Datenerfassung ändern</strong></td>
            <td>Wenn Sie in Salesforce vorgenommene Änderungen auf Datensatzebene in einem externen System veröffentlichen müssen und keine benutzerdefinierte Nutzlast benötigen.</td>
            <td>Erforderlich</td>
            <td>Asynchron</td>
            <td>Nein</td>
            <td>Nein</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>OAuth</td>
            <td></td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect mit organisationsübergreifendem Adapter</strong></td>
            <td>Wenn Benutzer in einer Organisation Datensätze in einer anderen Organisation ohne Datenreplikation anzeigen oder bearbeiten sollen</td>
            <td>Erforderlich</td>
            <td>Asynchron</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td>N/A</td>
            <td>N/A</td>
            <td>Mehrere</td>
            <td>Low Code (Niedriger Code)</td>
        </tr>
        <tr>
            <td><strong>Daten 360</strong></td>
            <td>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.</td>
            <td>Erforderlich</td>
            <td>Beides</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mit Pro-Code-Tools</td>
            <td class="guide-table-ok">Ja</td>
            <td class="guide-table-ok">Ja</td>
            <td>Mehrere</td>
            <td>Hybrid</td>
        </tr>
    </tbody>
</table>

\* 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.

<!-- document id=6f5686b702cbe55c786431735a5f0ead955d3d58a9051fde1fd7f23a762fc517 url=/architect/next/de-de/decision-guides/guides/record-triggered.md -->

## Übersicht

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. In diesem Dokument finden Sie den Rahmen und die Richtlinien, um fundierte Entscheidungen beim Entwerfen von Auslöserautomatisierungen zu treffen.

## Produkte im Umfang

<table style="border:none">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Flow</td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Salesforce Flow</a> 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).</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Apex</td> 
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a> 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.</td>
    </tr>
  </tbody>
</table>

## 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

### 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).

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/automation-density.png" alt="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.

<table>
  <thead>
    <tr>
      <th scope="col" style="width:8%">Dichtestufe</th>
      <th scope="col" style="width:18%">Automatisierungsmenge</th>
      <th scope="col">Datenvolumen (Batchgröße)</th>
      <th scope="col">Abhängigkeitszersiedelung</th>
      <th scope="col">Architektonischer Standard</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Niedrig</b></td>
      <td><b>&lt; 15</b><br>
        Automatisierungen</td>
      <td><b>Standard</b><br>
        Benutzergesteuerte Benutzeroberflächeninteraktionen oder kleine API-Lastungen (1–200 Datensätze)</td>
      <td><b>Diskret</b><br>
        In sich geschlossene Logik. 0–1 nachgelagerte DML-Vorgänge für dasselbe Objekt oder ein verwandtes Objekt.</td>
      <td><b>Durch einen Datensatz ausgelöster Flow</b></td>
    </tr>
    <tr>
      <td><b>Mittel</b></td>
      <td><b>15–30</b><br>
        Automatisierungen</td>
      <td><b>Mittel</b><br>
        Standardmäßige Batchverarbeitung (mit Logik, die eine sorgfältige Massenverarbeitung erfordert)</td>
      <td><b>Gekoppelt</b><br>
        "Übergeordnet/Untergeordnet" aktualisiert 2–4 nachgelagerte DML-Vorgänge. Rekursionsrisiko</td>
      <td><b>Hybridmuster</b><br>
        Flow + aufrufbares Apex</td>
    </tr>
    <tr>
      <td><b>Hoch</b></td>
      <td><b>> 30</b><br>
        Automatisierungen</td>
      <td><b>Hoch</b><br>
        Große Datenvolumen mit Massen-API-Last (2.000 – 10.000+ Datensätze)</td>
      <td><b>Komplex und rekursiv</b><br>
        Diagramm mit tiefer Abhängigkeit (5+ nachgelagerte DML-Vorgänge). Risiko von Dreiecksrekursionsschleifen</td>
      <td><b>Apex-Auslöser-Metadaten-Framework</b></td>
    </tr>
  </tbody>
</table>
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.

<table>
  <thead>
    <tr>
      <th scope="col">Kapazität</th>
      <th scope="col">Durch einen Datensatz ausgelöster Flow</th>
      <th scope="col">Apex Trigger</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Liefer- und Wartungsgeschwindigkeit</b></td>
      <td><b>Empfohlen</b><br>
        Ü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.</td>
      <td><b>Fachwissen erforderlich</b><br>
        Für die Implementierung, den Test und die Wartung des Codes benötigt Apex entsprechend qualifizierte Softwareentwickler.</td>
    </tr>
    <tr>
      <td><b>Modularität</b></td>
      <td><b>Verfügbar</b><br>
        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.</td>
      <td><b>Verfügbar</b><br>
        Apex ist nach Design in Funktionsmodule unterteilt. Jede Apex-Klasse soll ein einzelnes Funktionsmodul implementieren.</td>
    </tr>
    <tr>
      <td><b>Sichtbarkeit und Governance</b></td>
      <td><b>Empfohlen</b><br>
        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.</td>
      <td><b>Fachwissen erforderlich</b><br>
        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.</td>
    </tr>
    <tr>
      <td><b>Hochleistungsfähige Massendatenverarbeitung</b></td>
      <td><b>Nicht empfohlen</b><br>
        Bei komplexen Logiken oder großen Datenmengen besteht ein erhöhtes Risiko, dass Obergrenzen erreicht werden.</td>
      <td><b>Empfohlen</b><br>
        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.</td>
    </tr>
    <tr>
      <td><b>Robuste Logik und Datenstrukturen</b></td>
      <td><b>Verfügbar</b><br>
        Das <a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Element "Flowtransformation</a>" 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.</td>
      <td><b>Empfohlen</b><br>
        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.</td>
    </tr>
    <tr>
      <td><b>Transaktionssteuerung</b></td>
      <td><b>Nicht verfügbar</b><br>
        Der Flow bietet keinen Zugriff auf "Database.savepoint", "Database.rollback" oder teilweise erfolgreiche DML-Vorgänge für teilweise Transaktions-Commits oder -Rollbacks.</td>
      <td><b>Verfügbar</b><br>
        Apex bietet vollständige und detaillierte Kontrolle über die Transaktionsintegrität und komplexe Fehlerbehebungsszenarien.</td>
    </tr>
    <tr>
      <td><b>E-Mail-Verteilung</b></td>
      <td><b>Empfohlen</b><br>
        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 <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">täglichen Obergrenzen für den</a> Versand von E-Mails.</td>
      <td><b>Verfügbar</b><br>
        Apex kann benutzerdefinierte E-Mail-Nachrichten generieren und senden. Für alle über Apex gesendeten E-Mails gelten die <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">täglichen Obergrenzen für den</a> E-Mail-Versand.</td>
    </tr>
    <tr>
      <td><b>Anwendung von Plattformsicherungen</b></td>
      <td><b>Empfohlen</b><br>
        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.</td>
      <td><b>Manuelle Implementierung erforderlich</b><br>
        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.</td>
    </tr>
    <tr>
      <td><b>Asynchrone Verarbeitung</b></td>
      <td><b>Verfügbar</b><br>
        Flow bietet einfache Mechanismen für Automatisierungen, die eine separate Transaktion in einem asynchronen Pfad erfordern. Für diese Automatisierungen gelten tägliche Obergrenzen.</td>
      <td><b>Verfügbar</b><br>
        Apex ermöglicht die vollständige Kontrolle über die Datenerfassung ändern und warteschlangenfähige Ereignisse, die von einem entkoppelten Auslöserabonnenten verarbeitet werden.</td>
    </tr>
    <tr>
      <td><b>Geplante Verarbeitung</b></td>
      <td><b>Empfohlen</b><br>
        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.</td>
      <td><b>Nicht verfügbar</b><br>
        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.</td>
    </tr>
    <tr>
      <td><b>Ordnung und Choreografie</b></td>
      <td><b>Verfügbar</b><br>
        Mit dem Flow-Auslöser-Explorer können Administratoren eine relative Ausführungsreihenfolge für mehrere Flows desselben Objekts definieren.</td>
      <td><b>Verfügbar</b><br>
        Ein Auslöser-Framework bietet genaue Kontrolle über die genaue Reihenfolge der Automatisierungen.</td>
    </tr>
    <tr>
      <td><b>Aktualisierungen desselben Datensatzfelds</b></td>
      <td><b>Verfügbar (vor dem Speichern)</b><br>
        Durch einen Datensatz ausgelöster Flow ist die leistungsfähigste deklarative Option zum Aktualisieren des auslösenden Datensatzes vor dem anfänglichen DML-Commit.</td>
      <td><b>Verfügbar (vor dem Speichern)</b><br>
        Apex bietet das leistungsstärkste Angebot mit minimalem Overhead.</td>
    </tr>
    <tr>
      <td><b>Objektübergreifende CRUD</b></td>
      <td><b>Verfügbar (nach dem Speichern)</b><br>
        Flow eignet sich für einfache objektübergreifende DML-Vorgänge mit geringer Komplexität.</td>
      <td><b>Verfügbar (nach dem Speichern)</b><br>
        Apex bietet eine überlegene Kontrolle über die Deduplizierung, Fehlerbehandlung und Leistung für objektübergreifende DML-Vorgänge.</td>
    </tr>
    <tr>
      <td><b>Duplizierung teurer Berechnungen</b></td>
      <td><b>Verfügbar</b><br>
        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.</td>
      <td><b>Empfohlen</b><br>
        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.</td>
    </tr>
    <tr>
      <td><b>Benutzerdefinierte Fehlerverarbeitung</b></td>
      <td><b>Verfügbar</b><br>
        Das Element CustomError kann einen Speichervorgang blockieren und dem Benutzer eine Meldung anzeigen.</td>
      <td><b>Empfohlen</b><br>
        Die Methode <code>addError()</code> bietet flexible Fehlermeldungen auf Feldebene und bedingte Fehlermeldungen.</td>
    </tr>
  </tbody>
</table>

## Anwendungsfälle

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

<table>
  <thead>
    <tr>
      <th scope="col">Anwendungsfall</th>
      <th scope="col">Beschreibung</th>
      <th scope="col" style="width:16%">Best-Fit</th>
      <th scope="col" style="width:38%">Begründung</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Hochleistungsfähige Batchverarbeitung</b></td>
      <td>Jede Automatisierung, die Tausende von Datensätzen effizient verarbeiten muss</td>
      <td>Apex</td>
      <td>Apex bietet umfangreiche APIs für die Anbindung an die Plattform und für die Rohgeschwindigkeit.</td>
    </tr>
    <tr>
      <td><b>Komplexe Datenverarbeitung</b></td>
      <td>Szenarien, in denen erweiterte Datenmanipulationen erforderlich sind</td>
      <td>Apex</td>
      <td>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.</td>
    </tr>
    <tr>
      <td><b>Transaktionssteuerung</b></td>
      <td>Kontrollmechanismen wie Speicherpunkte, Rollbacks und Teil-Commits</td>
      <td>Apex</td>
      <td>Apex bietet Zugriff auf Mechanismen wie Database.savepoint und Database.rollback und kann teilweise erfolgreiche DML-Vorgänge verarbeiten.</td>
    </tr>
    <tr>
      <td><b>Hochentwickelte benutzerdefinierte Validierung</b></td>
      <td>Datenvalidierung über mehrere Felder in einem Datensatz hinweg</td>
      <td>Apex</td>
      <td>Flow kann zwar mit dem Element "CustomError" ein Speichern verhindern, ist jedoch nicht in allen Flow-Typen verfügbar, einschließlich Subflows. Die Apex <code>addError()</code>-Methode stellt mehrere feldspezifische Fehlermeldungen bereit, die einem Datensatz jederzeit während der Auslöserverarbeitung hinzugefügt werden können.</td>
    </tr>
    <tr>
      <td><b>Mittelkomplexe Logik in einem einfachen Prozess</b></td>
      <td>Logik- und Datenmanipulation mit moderater Komplexität, vereinfacht durch eine Standardbibliothek erweiterter Funktionen, die als Teil eines unkomplizierten Prozesses erfolgt</td>
      <td>Flow + Apex</td>
      <td>Durch einen Datensatz ausgelöster Flow fungiert als Orchestrierungsebene, während hochkomplexe Vorgänge in aufrufbarem Apex gekapselt sind.</td>
    </tr>
    <tr>
      <td><b>Einfache bis mittelkomplexe Logik</b></td>
      <td>Datenmanipulation mit geringer bis mittlerer Komplexität mit Auslöseraktualisierungen an den primären und verwandten Datenobjekten</td>
      <td>Flow</td>
      <td>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.</td>
    </tr>
    <tr>
      <td><b>Benachrichtigungen und ausgehende Nachrichten</b></td>
      <td>Senden von ausgehenden E-Mails und Nachrichten</td>
      <td>Flow</td>
      <td>Mit Flow können E-Mail-Benachrichtigungen und ausgehende Nachrichten zu Datensatzänderungen einfach und hochgradig skaliert werden.</td>
    </tr>
    <tr>
      <td><b>Geplante Verarbeitung</b></td>
      <td>Automatisierung zu einem zukünftigen dynamischen Datum (z. B. 3 Tage vor einem Schlusstermin)</td>
      <td>Flow</td>
      <td>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.</td>
    </tr>
  </tbody>
</table>

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

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/async-pattern.png" alt="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

### 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 vs. Mehrere 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. Sie bietet zudem einen unschätzbaren Überprüfungspfad: 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 einen Datensatz ausgelöster Flow" als Orchestrierungsebene und kapseln Sie gleichzeitig hochkomplexe Vorgänge in "Aufrufbarer Apex".

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/hybrid-pattern.png" alt="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: Hier 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: die Verwaltung und Orchestrierung sämtlicher Geschäftslogiken, die über diesen zentralen Einstiegspunkt aufgerufen werden, auf wartbare 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:

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/recursion-flow.png" alt="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 vs. Mehrere 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.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/trigger-explorer.png" alt="Flow-Auslöser-Explorer">

## Ressourcen

<table>
  <thead>
    <tr>
      <th scope="col">Apex</th>
      <th scope="col">Flow</th>
      <th scope="col">Vorgänge</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Was ist Apex?</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_integration_intro.htm">Apex Dienstprogramme</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Informationen zur Automatisierung mit Salesforce-Flow</a></li>
          <li><a href="https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer">Kennenlernen des Flow-Auslöser-Explorers</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Element 'Flow-Transformation'</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html">Salesforce-Codeanalyse</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5">DevOps Center</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

<!-- document id=39221615b3a29cd5b73ec99a62ddee02f444e99c6541bc97f1431e27b3dd10df url=/architect/next/de-de/decision-guides/guides/event-driven.md -->

# Verwenden der richtigen Tools und Muster für ereignisgesteuerte Architekturen

## Übersicht

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?

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 – Throughput](/docs/architect/de-de/well-architected/guide/reliable#durchsatz).)

- **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

<table style="border:none;width:100%">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0">Bei der <a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Platform</a> 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.</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: MuleSoft logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/mulesoft-new.png" alt="MuleSoft"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/mulesoft/">MuleSoft</a> 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.</td>
    </tr>
  </tbody>
</table>

## 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:

<table style="width:100%">
<thead>
<tr><th scope="col">Entscheidungspunkt</th><th scope="col">Anleitung</th></tr>
</thead>
<tbody>
<tr><td><strong>Benachrichtigungen nahezu in Echtzeit</strong></td><td>Ereignisgesteuerte 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.</td></tr>
<tr><td><strong>Parallelverarbeitung</strong></td><td>Muster 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.</td></tr>
<tr><td><strong>Lesevorgänge mit hohem Volumen</strong></td><td>Die 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.</td></tr>
<tr><td><strong>Schreibvorgänge mit hohem Volumen</strong></td><td>Die Streaming- und Warteschlangenmuster funktionieren gut in vielen Szenarien, in denen Organisationen einen Anstieg der Anzahl der produzierten Nachrichten feststellen.</td></tr>
<tr><td><strong>Senden derselben Daten an unterschiedliche Systeme</strong></td><td>Wä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.</td></tr>
<tr><td><strong>Häufige Einführung neuer Systeme oder Geräte</strong></td><td>Die 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.</td></tr>
<tr><td><strong>IoT-Geräte</strong></td><td>Da 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.</td></tr>
<tr><td><strong>Mobilgeräte und -systeme im Offline-Modus</strong></td><td>Mobilgerä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.</td></tr>
</tbody>
</table>

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:

<table style="width:100%">
<thead>
<tr><th scope="col">Entscheidungspunkt</th><th scope="col">Anleitung/Fragen</th></tr>
</thead>
<tbody>
<tr><td><strong>Geschäftsanforderungen</strong></td><td>Besteht 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?</td></tr>
<tr><td><strong>Technische Anforderungen</strong></td><td>Passt 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?</td></tr>
<tr><td><strong>Prozesse, bei denen Menschen auf Antworten warten müssen</strong></td><td>Jede 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 – Process Design](/docs/architect/de-de/well-architected/guide/automated#prozessdesign).</td></tr>
<tr><td><strong>Häufig geänderte Quelldaten</strong></td><td>Wenn 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.</td></tr>
<tr><td><strong>Implementierungsanforderungen</strong></td><td>Unterstü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?</td></tr>
<tr><td><strong>Messaging-Strukturstabilität</strong></td><td>Wie oft müssen sich Ihre Nachrichtenstrukturen ändern? Welche Systeme sind von einer solchen Änderung betroffen und wie sieht der Sanierungsprozess aus?</td></tr>
<tr><td><strong>Organisationsführung</strong></td><td>Verfü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?</td></tr>
<tr><td><strong>Erforderliche Fertigkeiten</strong></td><td>Verfügen Ihre Mitarbeiter über Erfahrung mit ereignisgesteuerten Architekturen und wissen sie, wie sie sie unterstützen können?</td></tr>
</tbody>
</table>

## 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 – Interoperabilität](/docs/architect/de-de/well-architected/guide/composable#interoperabilität). 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.

<table style="width:100%">
<thead>
<tr><th scope="col">Muster</th><th scope="col">Nahezu in Echtzeit</th><th scope="col">Kopie einer eindeutigen Nachricht</th><th scope="col">Garantiezustellung</th><th scope="col">Reduzieren der Nachrichtengröße</th><th scope="col">Umwandeln von Daten</th></tr>
</thead>
<tbody>
<tr><td>Veröffentlichen/Abonnieren</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Fanout</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Übergebene Nachrichten</td><td>✓</td><td></td><td>✓</td><td>✓</td><td>✓</td></tr>
<tr><td>Streaming</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Warteschlange</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
</tbody>
</table>

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

<table style="width:100%">
<thead>
<tr><th scope="col"></th><th scope="col">Tool</th><th scope="col">Beschreibung</th><th scope="col">Erforderliche Fertigkeiten</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Beliebige Punktplattform</a></td><td>Plattform, die die Datenintegration mithilfe von API-Ebenen ermöglicht.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub-Konnektor</a></td><td>Konnektor 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.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Konnektor, 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.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Konnektor zum Verschieben von Daten zwischen Apache Kafka und Unternehmensanwendungen und -services.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace-Konnektor</a></td><td>Konnektor für Solace PubSub+-Ereignisbroker mit nativer API-Integration mithilfe des JCSMP Java-SDK</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ-Konnektor</a></td><td>Ein mandantenübergreifender Cloud-Messaging-Service, mit dem Kunden erweiterte asynchrone Nachrichten zwischen ihren Anwendungen ausführen können.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint-MQTT-Konnektor</a></td><td>Eine MuleSoft-Erweiterung, die mit dem Protokoll MQTT (Message Queuing Telemetry Transport) v3.x kompatibel ist.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP-Konnektor</a></td><td>Ein Konnektor, mit dem Ihre Anwendung Nachrichten mithilfe eines AMQP 0.9.1-kompatiblen Brokers veröffentlichen und konsumieren kann.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">MuleSoft Anypoint Event-Driven (ASync)-API</a></td><td>Branchenunabhängige Sprache, die die Veröffentlichung von ereignisgesteuerten APIs unterstützt, indem sie in Ereignis-, Kanal- und Transportebenen unterteilt werden.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Messaging-Service für mehrere Mandanten, mit dem Kunden erweiterte asynchrone Nachrichten zwischen ihren Anwendungen ausführen können.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">MuleSoft Anypoint-Datenströme</a></td><td>Das in MuleSoft Anypoint verfügbare Framework zum Veröffentlichen und Abonnieren von Streaming-Daten.</td><td>Pro-Code</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka auf Heroku</a></td><td>Heroku-Add-On, das Apache Kafka als Service mit vollständiger Plattformintegration in die Heroku-Plattform bereitstellt.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Datenerfassung ändern</a></td><td>Ä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.</td><td>Low-Code zu Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Ausgehende Nachrichten</a></td><td>Aktionen, die XML-Nachrichten an externe Endpunkte senden, wenn Feldwerte in Salesforce aktualisiert werden.</td><td>Low-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Plattformereignisse</a></td><td>Sichere und skalierbare Nachrichten, die benutzerdefinierte Ereignisdaten enthalten.</td><td>Low-Code zu Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>API, die Abonnements für Plattformereignisse, Ereignisse der Datenerfassung ändern und/oder Ereignisse der Echtzeit-Ereignisüberwachung aktiviert.</td><td>Pro-Code</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Ereignisweiterleitungen</a></td><td>Ermö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.</td><td>Low-Code</td></tr>
<tr><th scope="row"></th><td></td><td></td><td></td></tr>
</tbody>
</table>

### 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)

<!-- Image: Publish/subscribe pattern diagram (Level 2) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Publish - Subscribe L2.png" alt="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

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Ereignis-Flow und -Verhalten</th><th colspan="2" scope="colgroup">Überlegungen zur Nutzlast</th></tr>
<tr><th scope="col">Verfügbare Tools</th><th scope="col"></th><th scope="col">Erforderliche Fertigkeiten</th><th scope="col">Veröffentlichen über</th><th scope="col">Abonnieren über</th><th scope="col">Wiederholungszeitraum</th><th scope="col">Nutzlaststruktur</th><th scope="col">Nutzlastobergrenzen</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Beliebige Punktplattform</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint-MQTT-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">MuleSoft Anypoint Event-Driven (ASync)-API</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka auf Heroku</a></td><td>Pro-Code</td><td>APIs, Datensatzänderungen in Heroku Postgres</td><td>N/A</td><td>1-6 Wochen</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Datenerfassung ändern</a></td><td>Low-Code zu Pro-Code</td><td>Datensatzänderungen</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Vordefiniert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Ausgehende Nachrichten*</a></td><td>Low-Code</td><td>Flow- und Workflow-Regeln</td><td>N/A</td><td>24 Stunden</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_wsdl.htm">Vom Benutzer definiert</a></td><td>100 Benachrichtigungen pro Nachricht</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Plattformereignisse</a></td><td>Low-Code zu Pro-Code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-Code</td><td>Pub/Sub API oder APIs, Apex, Flow</td><td>Pub/Sub-API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Ereignisweiterleitungen**</a></td><td>Low-Code</td><td>Plattformereignisse, Datenerfassung ändern</td><td>API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><td colspan="8">* Salesforce unterstützt ausgehende Nachrichten weiterhin im Rahmen der aktuellen Funktionsfunktionen, plant jedoch keine weiteren Investitionen in diese Technologie. **Ereignisweiterleitungen stellen nur eine Verbindung mit AWS Eventbridge her</td></tr>
</tbody>
</table>

### 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.)

<!-- Image: Fanout pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Fanout L3.png" alt="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

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Ereignis-Flow und -Verhalten</th><th colspan="2" scope="colgroup">Überlegungen zur Nutzlast</th></tr>
<tr><th scope="col">Verfügbare Tools</th><th scope="col"></th><th scope="col">Erforderliche Fertigkeiten</th><th scope="col">Veröffentlichen über</th><th scope="col">Abonnieren über</th><th scope="col">Wiederholungszeitraum</th><th scope="col">Nutzlaststruktur</th><th scope="col">Nutzlastobergrenzen</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint-MQTT-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka auf Heroku</a></td><td>Pro-Code</td><td>APIs, Datensatzänderungen in Heroku Postgres</td><td>N/A</td><td>1-6 Wochen</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Datenerfassung ändern</a></td><td>Low-Code zu Pro-Code</td><td>Datensatzänderungen</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Vordefiniert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Plattformereignisse</a></td><td>Low-Code zu Pro-Code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-Code</td><td>Pub/Sub API oder Apex, APIs, Flow</td><td>Pub/Sub-API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Ereignisweiterleitungen*</a></td><td>Low-Code</td><td>Plattformereignisse, Datenerfassung ändern</td><td>API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><td colspan="8">* Ereignisweiterleitungen senden nur Daten an AWS Eventbridge</td></tr>
</tbody>
</table>

### Ü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 – Data Handling](/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung).

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

<!-- Image: Passed messages pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Passed Messages L3.png" alt="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

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Ereignis-Flow und -Verhalten</th><th colspan="2" scope="colgroup">Überlegungen zur Nutzlast</th></tr>
<tr><th scope="col">Verfügbare Tools</th><th scope="col"></th><th scope="col">Erforderliche Fertigkeiten</th><th scope="col">Veröffentlichen über</th><th scope="col">Abonnieren über</th><th scope="col">Wiederholungszeitraum</th><th scope="col">Nutzlaststruktur</th><th scope="col">Nutzlastobergrenzen</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka auf Heroku</a></td><td>Pro-Code</td><td>APIs, Datensatzänderungen in Heroku Postgres</td><td>N/A</td><td>1-6 Wochen</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Datenerfassung ändern</a></td><td>Low-Code zu Pro-Code</td><td>Datensatzänderungen</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Vordefiniert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Plattformereignisse</a></td><td>Low-Code zu Pro-Code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-Code</td><td>Pub/Sub API oder APIs, Apex Flow</td><td>Pub/Sub-API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Ereignisweiterleitungen*</a></td><td>Low-Code</td><td>Plattformereignisse, Datenerfassung ändern</td><td>API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><td colspan="8">* Ereignisweiterleitungen senden nur Daten an AWS Eventbridge</td></tr>
</tbody>
</table>

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

<!-- Image: Streaming pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Streaming - L3.png" alt="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

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Ereignis-Flow und -Verhalten</th><th colspan="2" scope="colgroup">Überlegungen zur Nutzlast</th></tr>
<tr><th scope="col">Verfügbare Tools</th><th scope="col"></th><th scope="col">Erforderliche Fertigkeiten</th><th scope="col">Veröffentlichen über</th><th scope="col">Abonnieren über</th><th scope="col">Wiederholungszeitraum</th><th scope="col">Nutzlaststruktur</th><th scope="col">Nutzlastobergrenzen</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">MuleSoft Anypoint-Datenströme</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka auf Heroku</a></td><td>Pro-Code</td><td>APIs, Datensatzänderungen in Heroku Postgres</td><td>N/A</td><td>1-6 Wochen</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-Code</td><td>Pub/Sub API oder APIs, Apex Flow</td><td>Pub/Sub-API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
</tbody>
</table>

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

<!-- Image: Queuing pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Queuing L3.png" alt="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

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Ereignis-Flow und -Verhalten</th><th colspan="2" scope="colgroup">Überlegungen zur Nutzlast</th></tr>
<tr><th scope="col">Verfügbare Tools</th><th scope="col"></th><th scope="col">Erforderliche Fertigkeiten</th><th scope="col">Veröffentlichen über</th><th scope="col">Abonnieren über</th><th scope="col">Wiederholungszeitraum</th><th scope="col">Nutzlaststruktur</th><th scope="col">Nutzlastobergrenzen</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/4.3/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint-MQTT-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP-Konnektor</a></td><td>Pro-Code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Wie konfiguriert</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Vom Benutzer definiert</a></td><td>Keine</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka auf Heroku</a></td><td>Pro-Code</td><td>APIs, Datensatzänderungen in Heroku Postgres</td><td>N/A</td><td>1-6 Wochen</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Vom Benutzer definiert</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Datenerfassung ändern</a></td><td>Low-Code zu Pro-Code</td><td>Datensatzänderungen</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Vordefiniert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Plattformereignisse</a></td><td>Low-Code zu Pro-Code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-Code</td><td>Pub/Sub API oder APIs, Apex, Flow</td><td>Pub/Sub-API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Ereignisweiterleitungen*</a></td><td>Low-Code</td><td>Plattformereignisse, Datenerfassung ändern</td><td>API</td><td>3 Tage</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Vom Benutzer definiert</a></td><td>1 MB</td></tr>
<tr><td colspan="8">* Ereignisweiterleitungen senden nur Daten an AWS Eventbridge</td></tr>
</tbody>
</table>

#### 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

### 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

### 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 – Interoperability](/docs/architect/de-de/well-architected/guide/composable#interoperabilität) (Wohlüberlegt – Interoperabilität). 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 [Wohlüberlegt – API-Verwaltung](/docs/architect/de-de/well-architected/guide/composable#api-management).)

- **Ü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 [Wohlüberlegt – Prozessdesign](/docs/architect/de-de/well-architected/guide/automated#prozessdesign).)

- **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 – Design Standards](/docs/architect/de-de/well-architected/guide/intentional#design-standards).)

## Ressourcen

<table style="width:100%">
<thead>
<tr><th scope="col">Muster</th><th scope="col">Ressourcen</th></tr>
</thead>
<tbody>
<tr><td>Veröffentlichen/Abonnieren</td><td><a href="/docs/architect/de-de/well-architected/guide/reliable#durchsatz">Salesforce Well-Architected – Durchsatz</a><br><a href="/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung">Salesforce Well-Architected – Data Handling (Salesforce gut durchdacht – Datenverarbeitung)</a><br><a href="/docs/architect/de-de/well-architected/guide/composable#interoperabilität">Salesforce Well-Architected – Interoperability (Salesforce gut entwickelt – Interoperabilität)</a><br><a href="https://medium.com/salesforce-architects/achieve-architectural-efficiency-with-event-relays-c8d4ec7f07af">Blogpost: Erzielen von architektonischer Effizienz mit Ereignisweiterleitungen</a><br><a href="https://medium.com/salesforce-architects/announcing-pub-sub-api-generally-available-3980c9eaf0b7">Blogpost: Ankündigung der Pub/Sub-API allgemein verfügbar</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/moving-from-restful-to-eventful/">Blogpost: Wechsel von RESTful zu EVENTful</a><br><a href="https://blogs.mulesoft.com/dev-guides/event-driven-architectures-asyncapi/">Blogpost: Ereignisgesteuerte Architekturen und die AsyncAPI-Spezifikation</a><br><a href="https://youtu.be/0WJjmmw1ryM">Video: Anleitung zum Veröffentlichen/Abonnieren von Mustern</a></td></tr>
<tr><td>Fanout</td><td><a href="https://developer.salesforce.com/blogs/2021/08/how-to-work-within-platform-events-delivery-limits">Blogpost: Arbeiten innerhalb der Zustellungsobergrenzen für</a> Plattformereignisse<br><a href="https://youtu.be/zSncRUcucEU">Video: Anleitung zu Fanout-Mustern</a></td></tr>
<tr><td>Übergebene Nachrichten</td><td><a href="https://youtu.be/U87nErhMuqw">Video: Anleitung</a> zum Muster für übergebene Nachrichten</td></tr>
<tr><td>Streaming</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Blogpost: Entwerfen von Schreibvorgängen mit hohem Volumen in Salesforce</a><br><a href="https://youtu.be/-_1CDUI40fY">Video: Anleitung zu Streaming-Mustern</a><br><a href="https://docs.mulesoft.com/mule-runtime/4.3/streaming-about">Dokumentation: Streaming in Mule-Anwendungen</a></td></tr>
<tr><td>Warteschlange</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Blogpost: Entwerfen von Schreibvorgängen mit hohem Volumen in Salesforce</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/event-payment-apis/">Blogpost: Entwerfen von Zahlungsarchitekturen mit Evented-APIs</a><br><a href="https://youtu.be/jQvSKbMRbh0">Video: Anleitung zum Warteschlangenmuster</a></td></tr>
</tbody>
</table>

<!-- document id=ece58ca4a2fc714fc9ced993ac6634e4e315170050eb70ab761704dc450b50f5 url=/architect/next/de-de/decision-guides/guides/get-started-data-360-decision-guides.md -->

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

<!-- document id=6522dc94fbb4bd45b6bfd8299161fb689decf8b0113fdc2f30686f3a9b83c18c url=/architect/next/de-de/decision-guides/guides/get-started-integration-decision-guides.md -->

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

<!-- document id=aa0677e769bf8feff40be22f92e601e0d9204dd6b945d95035b650b74b3d48bf url=/architect/next/de-de/decision-guides/guides/get-started-platform-decision-guides.md -->

# 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, ereignisgesteuerte Architektur und schrittbasierte asynchrone Frameworks, um Architekten beim Entwerfen skalierbarer, wartungsfreundlicher und leistungsstarker Plattformlösungen zu 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.

---

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

<!-- document id=781e43da38960b10d51fbde948d5643c0b0fdd6349a1dfde50a91cba0d4e1637 url=/architect/next/de-de/decision-guides/guides/build-forms.md -->

## Leitfadenübersicht

Möchten Sie Formulare auf der Salesforce Platform erstellen? Sie haben mehrere Optionen, die das gesamte Low-Code- bis Pro-Code-Kontinuum umfassen. Dynamische Formulare im Lightning-Anwendungsgenerator und Bildschirm-Flows in Flow Builder stehen für Low-Code. In der Mitte des Kontinuums können Sie Bildschirm-Flows mit LWCs erweitern und kundenorientierte Formulare mit OmniStudio erstellen. Und Pro-Code ist das LWC-Framework und seine ständig wachsende Bibliothek an Basiskomponenten.

Optionen sind großartig, aber wie bestimmen Sie, welche (oder welche Kombination) die richtige Option ist? Hier kommt dieser Leitfaden ins Spiel.

## Wichtige Takeaways

- **Takeaway #1: Verwenden Sie beim Erstellen von Layouts zum Erstellen/Bearbeiten/Anzeigen von Lightning-Seiten dynamische Formulare.** Möglicherweise stellen Sie fest, dass Seitenlayouts in den Vergleichstabellen in dieser Anleitung fehlen. Künftig sollten Sie dynamische Formulare im Lightning-Anwendungsgenerator verwenden, um Datensatz-Detailseiten zu konfigurieren. Im Abschnitt "[Seitenlayouts](#seitenlayouts)" finden Sie weitere Informationen dazu, warum sie nicht weiter verbessert werden sollen.
- **Takeaway #2: Wenn Sie ein Formular zum Erstellen oder Bearbeiten für genau ein Objekt erstellen müssen, beginnen Sie mit Lightning-Seiten und dynamischen Formularen.** Dies ist die einfachste Möglichkeit, Formulare auf der Salesforce Platform zu erstellen. Sie bietet auch einige zusätzliche Funktionen, beispielsweise die Möglichkeit, die Feldsichtbarkeit zu steuern. Wenn Ihre Anforderungen weiter fortgeschritten sind, lesen Sie weiter. Bildschirm-Flow, OmniStudio oder Lightning Web Components (LWC) sind möglicherweise besser geeignet.
- **Takeaway #3: Wenn Sie ein mehrseitiges Formular oder einen Assistenten erstellen und keine strengen Anforderungen an Benutzeroberfläche oder Branding haben, beginnen Sie mit einem Bildschirm-Flow.** Bildschirm-Flows bieten ein lineares Navigations-Framework für die Orchestrierung mehrerer Formulare zusammen. Sie können LWC verwenden, um Ihr eigenes Framework für die Navigation zwischen Formularen zu erstellen. Es wird jedoch empfohlen, Flow die harte Arbeit für Sie zu überlassen, damit Sie sich auf die Formulare selbst konzentrieren können, statt sich um den [Formularstatus](/docs/architect/de-de/well-architected/guide/engaging#formulare) zu kümmern.
- **Takeaway #4: Wenn Sie zusätzliche Logik oder Aktionen _hinter dem Formular_ benötigen, verwenden Sie einen Bildschirm-Flow, OmniStudio oder LWC.** Alle drei Tools bieten Möglichkeiten, mit denen Ihre Lösung mehr erledigen kann, als einen einzelnen Datensatz zu erstellen oder zu bearbeiten. Diese "Mehr" kann erweiterte Logik sein, beispielsweise Verzweigung oder Iteration, oder es können mehr Aktionen wie die Integration in externe Systeme, das Senden von E-Mails oder das Übertragen von Benachrichtigungen an die mobile Anwendung eines Benutzers sein.
- **Takeaway #5: Sie haben komplexe UX-Anforderungen? Sie müssen mehr als nur die Sichtbarkeit dynamisch verarbeiten? Verwenden Sie LWC oder OmniScript.** Wenn Ihre Anforderungen mit einfachen Themen und spaltenbasierten Layouts erreicht werden können, können Sie Ihre Formulare direkt in einem Low-Code-Generator erstellen. Für eine genauere Kontrolle über den Stil Ihres Formulars benötigen Sie die ultimative Flexibilität von LWC. Wenn Sie ein Branchenkunde sind und ein pixelgenaues Branding benötigen oder über komplexe hierarchische Daten verfügen, verwenden Sie OmniStudio, mit dem Sie Formulare für Verbraucher erstellen können, die komplexe Geschäftslogik und Datentransformationen verarbeiten können.
- **Takeaway #6: Wenn Sie eine Testautomatisierung benötigen, beginnen Sie mit Lightning Web Components.** Sie können Einheitentests für jede LWC schreiben, unabhängig davon, wo Sie sie einbetten möchten. Dadurch können Sie eine zuverlässigere Teststrategie erstellen, die Massentests mit mehreren Datensätzen und negative Tests umfassen kann. [Unter Salesforce Well-Architected – Test Strategy](/docs/architect/de-de/well-architected/guide/resilient#teststrategie) finden Sie weitere Informationen zum Erstellen von Tests, mit denen Sie nachvollziehen können, wie gut Ihre Formulare Ihren funktionalen und nicht funktionalen Anforderungen entsprechen.

Beachten Sie, dass Sie nicht zwischen einem Entweder-Oder wählen müssen – Sie können die Leistung mehrerer Optionen kombinieren. Wenn Sie beispielsweise das integrierte Navigationssystem von Flow und die volle Flexibilität bei der Gestaltung von LWC benötigen, verwenden Sie sie zusammen.

## Tools zum Erstellen von Formularen mit Salesforce

In der folgenden Tabelle sind die Tools zum Erstellen von Formularen mit Salesforce sowie die erforderlichen Fertigkeiten und Lizenzüberlegungen aufgeführt. Später werden die spezifischen Funktionen, die für die einzelnen Tools unterstützt werden, genauer erläutert. Außerdem erfahren Sie, wie Sie zwischen klickbasierten Tools und codebasierten Tools auswählen (und wann sie kombiniert werden):

<table>
  <colgroup>
    <col span="1" style="width: 40%;">
    <col span="1" style="width: 30%;">
    <col span="1" style="width: 30%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Erforderliche Fertigkeiten</th>
      <th scope="col">Zusätzliche Lizenzanforderungen</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Dynamische Formulare</b></td>
      <td>Low Code (Niedriger Code)</td>
      <td>Nein</td>
    </tr>
    <tr>
      <td><b>Bildschirm-Flow</b></td>
      <td>Low Code (Niedriger Code)</td>
      <td>Nein</td>
    </tr>
    <tr>
      <td><b>OmniStudio</b></td>
      <td>Low Code + Pro Code</td>
      <td>Erfordert Paket "Branchen"</td>
    </tr>
    <tr>
      <td><b>Bildschirm-Flow + Lightning Webkomponenten</b></td>
      <td>Low Code + Pro Code</td>
      <td>Nein</td>
    </tr>
    <tr>
      <td><b>Lightning Web Components</b></td>
      <td>Pro-Code</td>
      <td>Nein</td>
    </tr>
  </tbody>
</table>

## Entscheidungspunkte auf einen Blick

Die folgende Tabelle enthält eine Übersicht über die Entscheidungspunkte, die bei der Auswahl Ihrer Produkte berücksichtigt werden sollten, sowie Fragen, die Sie sich zu den einzelnen Produkten stellen sollten. Im weiteren Verlauf dieses Leitfadens werden wir jedes dieser Themen genauer untersuchen.

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 75%;">
  </colgroup>
  <tbody>
    <tr>
      <td><b>Objektauswirkung</b></td>
      <td>Legen Sie fest, ob Ihr Formular für ein einzelnes Objekt verwendet werden soll oder für mehrere Objekte verwendet werden muss.</td>
    </tr>
    <tr>
      <td><b>Formularumfang und Navigation</b></td>
      <td>Legen Sie fest, ob alle Felder in Ihrem Formular logisch auf einen einzelnen Bildschirm passen oder ob Benutzer zwischen mehreren Bildschirmen navigieren können sollen.</td>
    </tr>
    <tr>
      <td><b>Standort</b></td>
      <td>Geben Sie die Position(en) an, an der bzw. den Sie das Formular einbetten möchten. Dies kann von einer beliebigen Stelle in einer Salesforce-Anwendung bis hin zu einer mobilen Anwendung oder sogar einer externen Website reichen.</td>
    </tr>
    <tr>
      <td><b>Steuerfeld</b></td>
      <td>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.</td>
    </tr>
    <tr>
      <td><b>Validierung</b></td>
      <td>Bestimmen Sie, ob Sie zusätzliche Eingabevalidierungsanforderungen haben, die über die von Salesforce bereitgestellte Standardvalidierung auf Systemebene hinausgehen.</td>
    </tr>
    <tr>
      <td><b>Sicherheit</b></td>
      <td>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.</td>
    </tr>
    <tr>
      <td><b>Interaktionsdesign</b></td>
      <td>Identifizieren Sie die Arten von Interaktionen oder Bedingungen, die dynamische Antworten in Ihrem Formular auslösen sollen.</td>
    </tr>
    <tr>
      <td><b>Stil</b></td>
      <td>Bestimmen Sie den Grad der Raffinesse für Ihren gewünschten Stil und CSS.</td>
    </tr>
    <tr>
      <td><b>Layout</b></td>
      <td>Identifizieren Sie die Layoutanforderungen Ihres Formulars in Bezug auf die erforderliche Anzahl an Spalten, Registerkarten, Akkordeons und die Möglichkeit, sich wiederholende Datenblöcke anzuzeigen.</td>
    </tr>
    <tr>
      <td><b>Übersetzung</b></td>
      <td>Legen Sie fest, ob Ihr Formular in andere Sprachen lokalisiert werden muss.</td>
    </tr>
    <tr>
      <td><b>Benutzeroberflächentestautomatisierung</b></td>
      <td>Bestimmen, ob Ihr Formular für Ihre DevOps-Prozesse automatisierten Einheitentests oder automatisierten durchgängigen Tests unterzogen werden muss</td>
    </tr>
    <tr>
      <td><b>Kennzahlen</b></td>
      <td>Identifizieren der Möglichkeiten, wie Sie die Nutzung Ihres Formulars verfolgen möchten, einschließlich Seitenaufrufen, der für das Formular aufgewendeten Zeit, Abschlussraten und Erfolgsraten</td>
    </tr>
    <tr>
      <td><b>Paketerstellung und Bereitstellung</b></td>
      <td>Legen Sie fest, wie Sie Ihr Formular verteilen oder bereitstellen möchten, nachdem es erstellt wurde.</td>
    </tr>
  </tbody>
</table>

Im Folgenden finden Sie die Begriffe, die in den Vergleichstabellen zusammen mit ihren Definitionen verwendet werden:

- **Verfügbar:** Funktioniert gut mit grundlegenden Überlegungen.
- **Nicht ideal:** Kann funktionieren, ist aber nicht das optimale Tool.
- **Roadmap:** Geschätzte Unterstützung innerhalb der nächsten zwölf Monate (Juni 2025).
- **Zukunft**: Voraussichtliche Unterstützung über die nächsten zwölf Monate hinaus.
- **Nicht verfügbar:** Es ist nicht geplant, diese Funktion in den nächsten zwölf Monaten zu unterstützen.

## Anleitungen zu Entscheidungspunkten

Wie versprochen, beginnen wir mit einer Vielzahl von Vergleichspunkten und Funktionsunterschieden zwischen dynamischen Formularen, Bildschirm-Flows, OmniStudio, Bildschirm-Flows mit eingebetteten LWCs und dem LWC-Framework selbst.

### Objektauswirkung

Wenn Ihr Formular für ein einzelnes Salesforce-Objekt verwendet wird, funktionieren alle Tools, die verglichen werden. Bei objektübergreifenden oder objektunabhängigen Formularen wird es etwas komplizierter. Unter objektunabhängig verstehen wir Eingaben, die keinem Salesforce-Objekt zugeordnet sind. Möglicherweise stellt Ihr Formular eine Datenstruktur dar, die Sie an einen externen Service wie Stripe oder DocuSign senden. Oder Sie verwenden mehrere Eingaben in Ihrem Formular, um einen Wert zu berechnen, und übernehmen diesen Wert dann in die Datenbank.

#### Zu stellende Fragen:

- Für welche Objekte wird das Formular verwendet?
- Ist es nur ein Objekt oder gibt es mehrere Objekte?
- Arbeiten Sie mit bestimmten Objekten (z. B. Account, Kontakt, Opportunity, Lead und Kundenvorgang) oder muss Ihr Formular auch mit anderen Objekten funktionieren?

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Einzelnes Objekt</th>
      <th scope="col">Objektübergreifend</th>
      <th scope="col">Objektunabhängig</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
  </tbody>
</table>

Bei objektübergreifenden und objektunabhängigen Formularen sind Flow und OmniStudio solide Optionen. Die in Flow-Bildschirmen verfügbaren Komponenten sind von Natur aus agnostisch. Sie können also auswählen, was mit diesen Daten im Hintergrund geschehen soll. Verwenden Sie beispielsweise die in einem Formular eingegebenen Daten, um mehrere Datensätze im Hintergrund zu erstellen, oder verwenden Sie die Daten, um andere Aktionen auszuführen, beispielsweise Chatter-Posts zu generieren, Slack-Nachrichten zu senden, E-Mails zu senden oder eine Verbindung mit externen Services herzustellen.

In einfachen Fällen kann die Verwendung vorhandener LWC-Komponenten wie Lightning-Datensatzform eine einfache Möglichkeit sein, den Code zu reduzieren, der für eine zuverlässige Lösung erforderlich ist. In Szenarien, in denen mehrere Objekte beteiligt sind, bietet Flow jedoch umfassende Kontrolle über alle Objekte und macht es Entwicklern nicht mehr erforderlich, komplexe Beziehungen und Abhängigkeiten zu durchlaufen.

OmniStudio geht noch einen Schritt weiter und ist vollständig objektunabhängig: Es trennt die Form, die einem Benutzer angezeigt wird, vom zugrunde liegenden Datenmodell. Stattdessen bearbeitet OmniStudio die zugrunde liegende JSON, die dann Salesforce-Objekten (oder externen Daten) mit Tools wie [der Datenzuordnung](https://help.salesforce.com/s/articleView?id=sf.os_dataraptors.htm&type=5) und [Integrationsverfahren](https://help.salesforce.com/s/articleView?id=sf.os_omnistudio_integration_procedures_48334.htm&type=5) zugeordnet wird. "Datenzuordnung" und "Integrationsverfahren" sind zwei wichtige Komponenten für die Verbindung Ihrer OmniStudio-Formulare mit internen und externen Salesforce-Daten. Mithilfe von Ziehen-und-Ablegen-Elementen können Sie mit komplexen hierarchischen Daten in einem externen System arbeiten und die Daten dann entsprechend Ihren Anforderungen umwandeln, je nachdem, wohin die Daten gelangen sollen. Sie ermöglichen es Ihnen auch, Formeln zu verwenden, um Mathematik und Logik für Arrays oder Datenlisten auszuführen, ähnlich wie Apex.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-objectimpactnoheader.png" alt="OmniStudio Integrations">_OmniStudio Integrations_](/docs/architect/de-de/reference-diagrams/guide/omnistudio-integrations)

### Formularumfang und Navigation

Wenn Sie alle Ihre Benutzereingaben über ein Formular mit einem einzigen Bildschirm abrufen können, beginnen Sie mit "Dynamische Formulare". Dynamische Formulare auf Datensatzseiten können zwar die Funktion "Pfad" verwenden, um die verschiedenen Phasen Ihres Geschäftsprozesses locker darzustellen, passen jedoch möglicherweise nicht in die meisten Ihrer Anwendungsfälle.

#### 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 eine visuelle Darstellung angezeigt wird, wie weit sie beim Ausfüllen Ihres Formulars 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?

<table>
  <colgroup>
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Einzelbildschirm</th>
      <th scope="col">Formular mit mehreren Bildschirmen</th>
      <th scope="col">Fortschrittsindikatoren</th>
      <th scope="col">Navigation zwischen Schritten / Bildschirmen</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-no">Nicht ideal</td>
      <td class="guide-table-no">Nicht ideal</td>
      <td class="guide-table-no">Nicht ideal</td>
    </tr>
  </tbody>
</table>

Wenn Sie mehr Funktionen benötigen, als dynamische Formulare bieten, hängt die Auswahl zwischen Flow, OmniStudio und LWC auch von einigen anderen Fragen ab:

- Welche Fertigkeiten hat Ihr Team? Für eine administratorlastigere Organisation sollten Sie mit Flow beginnen. Wenn Sie über Branchenlösungen verfügen, Ihr Team bereits mit OmniStudio vertraut ist und Ihr Projekt strenge UX-Anforderungen hat, beginnen Sie mit OmniStudio.
- Ist es in Ordnung, unten in Ihrem Formular eine Navigationsleiste anzuzeigen? Wenn der Bildschirm-Flow und die OmniScript-Navigationserfahrung unerwünscht sind, neigen Sie zu LWC.
- Was muss hinter dem Formular geschehen? Wenn das Verhalten von einem Administrator konfiguriert werden muss, erstellen Sie einen Flow oder – bei grundlegenden Änderungen wie dem Ändern von Feldbezeichnungen – ein OmniScript. Erstellen Sie andernfalls für komplexe Beziehungen mit mehreren Objekten ein OmniScript oder eine LWC.
- Wenn Sie Flow oder OmniStudio auswählen, müssen Sie möglicherweise ohnehin 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 das [Einbetten dieser Komponente in einen Flow](https://developer.salesforce.com/docs/platform/lwc/guide/use-flow-embed-component.html) übertrieben ist.

Wenn Ihre Lösung hingegen 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. Ein großartiges Beispiel dafür, wie Sie Bildschirm-Flows verwenden, finden Sie im Paket "[Digital Store Audit](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FMkOtUAL)" von Salesforce Labs.

OmniStudio bietet einen wichtigen Navigationsvorteil, da Fortschrittsindikatoren aus der Standardnavigation bereitgestellt werden, die "Schritte" im Formular anzeigen. In dieser Schrittansicht wird automatisch angezeigt, wo sich ein Benutzer in einem bestimmten Formular mit mehreren Schritten befindet. Im Gegensatz zu Flow können Benutzer durch Klicken auf verschiedene Schritte des Formulars zwischen Bildschirmen springen.

Unabhängig davon, ob Sie Formulare mit einem einzelnen Bildschirm oder Formulare mit mehreren Bildschirmen erstellen, stellen Sie sicher, dass Ihre Formulare [optimiert](/docs/architect/de-de/well-architected/guide/engaging#formulare) sind, damit Ihre Benutzer einfach darin navigieren können.

### Standort

Wenn Sie ein Formular in eine Lightning Standard-Datensatzseite einbetten, funktionieren alle Tools, die verglichen werden, mit dem Vorbehalt, dass dynamische Formulare derzeit nur auf dem Desktop verfügbar sind. Wenn Sie jedoch 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 verwenden, 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?

<table>
  <colgroup>
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Lightning-Datensatzseite</th>
      <th scope="col">Lightning-Startseite oder -Anwendungsseite</th>
      <th scope="col">Aura Experience Cloud-Sites</th>
      <th scope="col">LWR Experience Cloud-Sites</th>
      <th scope="col">Eingebettete Snap</th>
      <th scope="col">Dienstprogrammleiste</th>
      <th scope="col">Objektspezifische Aktion</th>
      <th scope="col">Globale Aktion</th>
      <th scope="col">Mobile Salesforce-Anwendung**</th>
      <th scope="col">Field Service Mobile</th>
      <th scope="col">Mobiles SDK</th>
      <th scope="col">Externe Sites und Anwendungen</th>
      <th scope="col">Benutzerdefinierte LWC</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar***</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-no">Nicht ideal</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="14">* Flows können in LWR Experience Cloud-Sites eingebettet werden, müssen jedoch beachtet werden.<br>** Flows und LWCs werden in der mobilen Salesforce-Anwendung unterstützt, die mobile Salesforce-Anwendung unterstützt jedoch nicht alle Möglichkeiten, Flows und LWCs einzubetten. Objektspezifische Aktionen werden beispielsweise auf Mobilgeräten unterstützt, Dienstprogrammleistenelemente jedoch nicht.<br>*** Die Field Service Mobile-Anwendung unterstützt viele der neuesten Flow-Funktionen nicht, da sie von einem älteren Flow-Modul und der Bildschirm-Flow-Laufzeit entwickelt wurde. Sie weist spezielle Änderungen auf, damit sie offline funktioniert.</td>
    </tr>
  </tbody>
</table>

Da sie Datensatzkontext erfordern, werden dynamische Formulare nur auf Lightning-Datensatzseiten unterstützt. Dynamische Formulare werden jedoch auf Experience Cloud-Seiten nicht unterstützt. Diese Einschränkung gilt, da Experience Cloud das zugrunde liegende Framework nicht verwendet, von dem dynamische Formulare abhängen: Lightning-Seiten. Dies wird anhand von Anforderungen für dynamische Formulare in Experience Cloud ausgewertet.

Sie können Flows erstellen, die einen Datensatzkontext erfordern, oder Flows, die global funktionieren. Daher können Sie Flows an einer Vielzahl von Orten einbetten. Bei Flows mit Datensatzkontext kann es sich um eine Lightning-Datensatzseite, eine Experience Cloud-Datensatzseite, eine objektspezifische Aktion oder eine Bereitstellung von Aktionen und Empfehlungen handeln. Für den globalen Flow kann dies die Dienstprogrammleiste, andere Lightning- oder Erfahrungsgenerator-Seiten, ein Snap oder eine externe Anwendung sein. Flows werden derzeit nicht als globale Aktionen unterstützt. Als Übergangslösung können Sie den Flow jedoch in eine Aura-Komponente einschließen.

Mit OmniStudio können Sie zusammengesetzte FlexCards und OmniScripts erstellen, die Sie fast überall dort platzieren können, wo Sie einen Flow platzieren können. Sie können jedoch nicht als Paket erstellt werden.

LWC unterstützt ein hohes Maß an Wiederverwendbarkeit, da Sie Komponenten erstellen, die über Metadaten in Salesforce, Communities und sogar in Open-Source-Projekten Zielen zugeordnet werden können. Über [Lightning Out](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lightning_out) können LWC-Komponenten auch in die eigene Website eingebettet werden.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-locationnoheader.png" alt="Lightning Out auf externen Sites">_Lightning Out auf externen Sites_](/docs/architect/de-de/reference-diagrams/guide/lightning-out-on-external-sites)

Lightning-Webkomponenten werden derzeit nicht als Schnellaktionen (objektspezifisch oder global) unterstützt. Als Übergangslösung können Sie jedoch eine Lightning-Webkomponente in eine Aura-Komponente einschließen (ähnlich wie bei Flows). LWC-Komponenten können auch Flows mit der [Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation)-Komponente starten.

OmniStudio zeichnet sich durch die Bereitstellung von Inhalten auf externen Sites durch die OmniOut-Funktion aus. Mit OmniStudio und OmniOut können Sie Ihre OmniScript-Formulare und FlexCard-Komponenten zu Standardkomponenten kompilieren und sie außerhalb der Plattform auf Sites oder in Anwendungen von Drittanbietern ausführen.

Keine der in diesem Handbuch behandelten Formulartechnologien wird heute offiziell in Mobile SDK-Vorlagen unterstützt. Wenn das Mobile SDK für Ihren Anwendungsfall wichtig ist, sollten Sie Ihr Formular besser nativ in Ihrer mobilen Anwendung erstellen oder eine Visualforce-Seite erstellen, wobei die Salesforce Well-Architected [Formfaktor](/docs/architect/de-de/well-architected/guide/engaging#formfaktor)-Anleitung zu berücksichtigen ist.

**Fahrplanhinweis:** Das Mobile SDK-Team arbeitet aktiv an der Unterstützung von LWCs auf Visualforce-Seiten.

### Controller

Dynamische Formulare sind perfekt, wenn Sie die Werte in Ihrem Formular verwenden müssen, um einen Datensatz zu erstellen oder zu aktualisieren. Für alle darüber hinausgehenden Funktionen müssen Sie Flow, OmniStudio oder LWC verwenden. Diese Funktionen können eine Entscheidungsebene oder eine Iterationsebene umfassen oder die Generierung von Slack-Posts oder -E-Mails mithilfe der Eingaben aus dem Formular.

#### Zu stellende Fragen:

- Welche Aktionen oder Logiken möchten Sie im Hintergrund ausführen?
- Enthält Ihr Datenmodell hierarchische Daten?
- 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?

<table>
  <colgroup>
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Protokoll &amp; Aktionen</th>
      <th scope="col">Hierarchische Datenverwaltung</th>
      <th scope="col">Arbeiten innerhalb einer Transaktion</th>
      <th scope="col">Transaktionsübergreifendes Arbeiten</th>
      <th scope="col">Integration</th>
      <th scope="col">Modulares Design und Wiederverwendung</th>
      <th scope="col">Verpackung</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
  </tbody>
</table>

Der Flow bietet Standardaktionen für das Posten in Slack, das Senden von E-Mails und die Interaktion mit Quip-Dokumenten, sodass Sie für diese Vorgänge keinen Code schreiben müssen. LWC bietet umfassende Interaktionen mit einzelnen Datensätzen und verwandten Objekten durch die Verwendung von Wire-Adaptern, 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, wenn der Wire für [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html) verwendet wird.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-controllernoheader.png" alt="LWC-Interaktion über Wire-Adapter">_Lightning Web Components_](/docs/architect/de-de/reference-diagrams/guide/lightning-web-components-interaction-via-wire-adapters)

Wie oben erwähnt, verwendet OmniStudio Integrationsverfahren und Datenzuordnung, um Daten extern und intern in Salesforce einfach abzurufen und umzuwandeln. Dank zahlreicher codefreier Funktionen, die Sie verwenden können, können Sie Datensets mit verschiedenen Beziehungsebenen vereinfachen und erweitern.

**Fahrplanhinweis:** Flow wird bald die Möglichkeit zum Aktualisieren und Einfügen von Sammlungen von Datensätzen sowie zum Verwalten hierarchischer Daten unterstützen.

Flow, OmniStudio und LWC können alle in Apex integriert werden, sodass Sie Lücken in der von Ihnen ausgewählten Lösung ganz einfach schließen können. Wenn Sie beispielsweise Datensätze aus einem LWC filtern müssen, können Sie jederzeit den Wire-Adapter für Apex verwenden, um komplexe SOQL-Abfragen zu erstellen. Wenn Sie von dem klickbasierten Artikel überzeugt sind, sollten Sie Flow oder OmniStudio als brauchbare Alternativen zu einem Apex-Steuerfeld für Ihre serverseitigen Anforderungen in Betracht ziehen.

Eine sekundäre Frage hier ist, ob Sie Aktionen sofort übernehmen oder auf einen bestimmten Teil Ihres Formulars zurückstellen möchten. Dies ist besonders relevant, wenn Sie sich in einem mehrseitigen Formular befinden. Mit Flow können Eingaben aus mehreren Formularen (Flow-Bildschirmen) ganz einfach kombiniert und viel später im Assistenten (Flow) verwendet werden, um einige Vorgänge auszuführen. Es wird sogar empfohlen, Flows genau auf diese Weise zu entwerfen – also Aktionen am Ende auszuführen –, falls der Benutzer zwischen Bildschirmen hin- und herwechselt und seine Antworten ändert.

#### Steuern von Vorgängen

Transaktionen und [Obergrenzen](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) sind eine Lebenseinstellung auf Salesforce Platform. Wenn Ihr Anwendungsfall ziemlich einfach ist, ist es möglicherweise nicht so wichtig, zu steuern, in welcher Transaktion ein bestimmter Vorgang vorkommt. 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. Einige Beispiele:

- **Zurücksetzen oder nicht zurücksetzen**: Das ist die Frage. Angenommen, Ihr Formular erstellt mehrere Datensätze im Hintergrund. Wenn der dritte Datensatz nicht erstellt werden kann, sollten die ersten beiden Datensätze zurückgesetzt werden? Wenn jede Ihrer Aktionen unabhängig voneinander ist, können Sie sie in separaten Transaktionen ausführen. Wenn sie jedoch abhängig sind und Sie möchten, dass die anderen nicht ebenfalls zurückgesetzt werden, implementieren Sie sie in einer einzelnen Transaktion. Wenn sich Ihr Formular im Flow befindet, können Sie das Element "Rückmeldung" in einem Fehlerpfad verwenden, um Ihre Transaktion zurückzusetzen und die Datenintegrität sicherzustellen.
- **Nachgelagerte Auswirkungen auf die Obergrenzen**: Insbesondere wenn Ihr Formular einen Datensatz erstellt oder aktualisiert, sollten Sie die nachgelagerten Auswirkungen dieses Vorgangs berücksichtigen. Welche Prozesse, Workflow-Regeln, Flow-Auslöser, Apex-Auslöser oder anderen Elemente in der Speicherreihenfolge werden basierend auf dieser Datensatzänderung ausgelöst? Und wie wirken sich diese kollektiven Änderungen auf die Obergrenzen aus, die in dieser Transaktion verbraucht werden? Wenn eine bestimmte Datensatzänderung zu vielen nachgelagerten Änderungen führt, die sich auf Ihre Obergrenzen auswirken, sollten Sie diese Datensatzänderung in eine eigene Transaktion aufnehmen.
- **Batchverarbeitung**: Selbst in einem Benutzeroberflächenkontext müssen Sie möglicherweise mehrere Aktualisierungen zusammen als Batch vornehmen. 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 gesammelt 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 immer nur einen Vorgang aus und dieser Vorgang ist immer der Start einer neuen Nettotransaktion.

Beim Erstellen eines Bildschirm-Flows haben Sie erhebliche Kontrolle darüber, was in einer bestimmten Transaktion passiert. Bildschirme und lokale Aktionen fungieren als Grenzen zwischen Transaktionen. Im Folgenden finden Sie eine allgemeine Zusammenfassung der Verwaltung von Transaktionen in der Bildschirm-Flow-Architektur.

1. Der Endbenutzer interagiert mit einem Bildschirm und klickt dann auf **Weiter**.
2. Der Client postet eine Anforderung mit den Eingaben an die API.
3. Die API empfängt die Anforderung und eine Transaktion und eine Datenbankverbindung werden geöffnet. Die API ruft dann 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 einen Bildschirmknoten oder einen Knoten vom Typ "Lokale Aktion" erreicht. Das Modul gibt dann 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 (Hinweis auf die [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, auf dem der Benutzer interagieren kann.
7. Wiederholen Sie den Vorgang ab Schritt 1.

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 wird gestartet.

<br/>

<img style="border:1px solid #e5e5e5;float:left;width:50%;margin:1rem 2rem 1rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow1.png" alt="Multi-Screen-Flow">

Das richtige Design – welche Vorgänge Sie zu einer bestimmten Transaktion gruppieren – ist Ihr Anruf. Sehen wir uns einige Beispiele an.

<br/>

<img style="border:1px solid #e5e5e5;float:right;width:50%;margin:1rem 2rem 1rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow2.png" alt="Bildschirm-Flow mit separaten Transaktionen">

<br/>

Links sehen Sie einen Flow, der Eingaben über mehrere Bildschirme hinweg erfasst und dann mehrere Aktionen in einer Transaktion ausführt.

<br/>

Der Flow auf der rechten Seite führt jeden Vorgang in einer separaten Transaktion aus.

<br/>
Das Flow-Team hat kürzlich ein neues Element eingeführt: Mit dem Element "Datensätze zurücksetzen" können Sie eine gesamte Transaktion zurücksetzen, wenn ein einzelner Vorgang in einer Reihe von Datenbankvorgängen fehlschlägt.

<br/>

<img style="border:1px solid #e5e5e5;float:right;width:50%;margin:1rem 2rem 1rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow3.png" alt="Bildschirm-Flow mit mehreren Erstellungsdatensätzen">

<br/>
<br/>

Angenommen, Sie verfügen über einen Flow, der Datensätze erstellt, Datensätze aktualisiert und dann weitere Datensätze erstellt, wie im nächsten Flow auf der rechten Seite dargestellt.

<br/>

Wenn in diesem Szenario die ersten beiden Elemente erfolgreich sind und das letzte fehlschlägt, werden diese Datensätze weiterhin durch die ersten beiden DML-Vorgänge erstellt und aktualisiert, während das dritte nicht der Fall ist.

<br/>

<img style="border:1px solid #e5e5e5;float:left;width:50%;margin:1rem 2rem 1rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow4.png" alt="Bildschirm-Flow mit Rollback">

<br/>

Mithilfe des Elements "Datensätze zurücksetzen" können Sie sicherstellen, dass die gesamte Transaktion zurückgesetzt wird, wenn alle drei Vorgänge gleichzeitig ausgeführt werden müssen – wie im letzten Flow auf der linken Seite zu sehen.

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). Im Abschnitt "Automatisiert" von Salesforce Well-Architected wird dies auch unter "[Datenverarbeitung"](/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung) ausführlicher erläutert.

Ihre Fähigkeit, die Transaktion über eine LWC zu steuern, hängt von den zugrunde liegenden Services ab, die LWC zum Ausführen seiner Vorgänge verwendet. Wenn Sie die Basiskomponente "Lightning-Datensatzform" verwenden, wird der zugrunde liegende Vorgang (Erstellen oder Aktualisieren des Datensatzes) in einer eigenständigen Transaktion ausgeführt, sobald das Formular gesendet wird.

Im Allgemeinen gelten die folgenden Regeln:

- Jeder Benutzeroberflächen-API-Aufruf wird in eine eigene 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. Es gelten die regulären Transaktionsregeln für diese Technologie.

#### 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. Neben benutzerdefiniertem Apex Code unterstützen Flow und OmniStudio deklarative Mechanismen zum Integrieren einer API.

Wenn Sie eine Verbindung mit einer MuleSoft-API oder einem RPA-Bot herstellen müssen, verwenden Sie MuleSoft-Services. Dadurch wird ein externer Service generiert.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-mulesoftnoheader.png" alt="Externe Integrationen über MuleSoft">_-APIs und RPA-Bots_](/docs/architect/de-de/reference-diagrams/guide/external-integrations-via-mulesoft-apis-and-rpa-bots)

Wenn die API über ein OpenAPI-Schema verfügt, erstellen Sie einen externen Service.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-openapi-noheader.png" alt="Externe Integrationen über OpenAPI">_-Externe Integrationen in APIs mit OpenAPI-Schemas_](/docs/architect/de-de/reference-diagrams/guide/external-integrations-to-apis-with-openapi-schemas)

Verwenden Sie andernfalls die HTTP-Callout-Funktion in Flow oder HTTP-Aktion in OmniStudio. Der HTTP-Callout von Flow wird von externen Services unterstützt.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-callouts-noheader.png" alt="Externe Integrationen über HTTP">_Externe Integrationen über HTTP_](/docs/architect/de-de/reference-diagrams/guide/external-integrations-via-http)

OmniStudio verfügt über einen umfangreichen Satz an Integrationsfunktionen, die externe Systeme mit Integrationsverfahren aufrufen und die Daten mit der Datenzuordnung umwandeln können. (Weitere Informationen finden Sie unter [Objektauswirkung](#objektauswirkung))

Unabhängig davon, ob Sie ihn mit benutzerdefiniertem Apex oder einem externen Service implementieren, ist ein Callout ein Callout. Folgendes müssen Sie wissen.

1. Ein Callout kann lange dauern.
2. Wenn ein Callout synchron ausgeführt wird, wird er ausgeführt, während eine Datenbanktransaktion geöffnet ist.
3. Salesforce lässt Sie eine Datenbanktransaktion nicht offen, wenn Datenbankvorgänge ausstehen.

Die Haupteinschränkung, die Sie beachten sollten, besteht in der Gefahr sogenannter **_schmutziger Transaktionen_**, bei denen Sie einen Erstellungs-, Aktualisierungs- oder Löschvorgang ausführen und dann in derselben Transaktion einen Callout ausführen. Dieses Muster ist aufgrund von Überlegung Nr. 3 oben nicht zulässig, was natürlich aufgrund von Überlegung Nr. 1 und 2 vorhanden ist.

In Flow können Sie diese Einschränkung umgehen, indem Sie die Transaktion unterbrechen. Denken Sie daran, dass Bildschirme und lokale Aktionen den Browserkontext wieder einführen, wodurch die Transaktion unterbrochen wird. Obwohl Sie beim Arbeiten mit externen Callouts Bildschirme und lokale Aktionen verwenden könnten, wird empfohlen, die Transaktionssteuerung in den aufrufbaren erweiterten Einstellungen zu aktivieren. Die Transaktionssteuerung ist eine Funktion aufrufbarer Aktionen, mit der Sie die Transaktion automatisch beenden können, bevor ein Callout erfolgt. Sie können die Transaktionssteuerung aktivieren, indem Sie im Abschnitt "Erweitert" einer aufgerufenen Aktion Immer eine neue Transaktion starten auswählen.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow5.png" alt="Externe Integrationen über Callouts">  
Die Auswirkungen von Callouts auf die Transaktion sind mit LWC weniger kompliziert. Im Allgemeinen führen Sie Ihre Datenvorgänge mithilfe des Lightning Data Service (LDS) aus und verwenden dann ein Apex-Steuerfeld, um den externen Callout vorzunehmen. Dieses Design schützt Sie vor schmutzigen Transaktionen, da der LDS-Aufruf in einer eigenen Transaktion getrennt vom Apex Callout isoliert ist.

_Ausführlichere Anleitungen zu Apex Callouts, externen Services und Datenintegrationsfunktionen im Allgemeinen finden Sie im [Architektenhandbuch zur Datenintegration mit Salesforce](/docs/architect/de-de/decision-guides/guide/data-integration)._

#### Wiederverwendbarkeit und Modularität

Dynamische Formulare unterstützen die Wiederverwendung nicht. Jedes dynamische Formular 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 Sie Bibliotheken, Dienstprogramme und Komponenten schreiben können, die für die Verwendung in mehreren anderen Komponenten vorgesehen sind, können Sie beim Erstellen von Flows mit der Leistungsfähigkeit von **_Subflows_** ähnliche Designmuster anwenden. Speichern Sie Ihre Flows in kleineren, modulareren Buckets und rufen Sie sie dann mithilfe des Subflow-Elements aus anderen Flows auf. Wenn Ihr Design dies erfordert, können Sie einen Flow erstellen, der für sich steht und als Subflow eines anderen nützlich ist.

OmniStudio ist von Natur aus auf Modularität ausgelegt. Datenzuordnungen, OmniScripts, FlexCards und Integrationsverfahren werden unabhängig voneinander erstellt und können austauschbar verwendet werden. Darüber hinaus können FlexCards 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 [komposibel](/docs/architect/de-de/well-architected/guide/composable) sind, erhalten Sie zusätzliche Vorteile wie Anpassungsfähigkeit und Stabilität.

### Validierung

Alle Technologien, die zum Erstellen oder Aktualisieren eines Datensatzes verwendet werden, halten sich an die Validierung auf Systemebene – unabhängig davon, ob es sich um klassische Validierungsregeln oder eine in einen Apex-Auslöser integrierte benutzerdefinierte Validierung handelt. Unabhängig davon, welche Technologie Sie zum Ausführen einer Datensatzänderung verwenden, wird jede Änderung durch den Speicherauftrag ausgeführt. Das bedeutet, dass die Datensatzänderung zusätzlich zu Validierungsregeln durch eine beliebige Anzahl von Flows vor oder nach dem Speichern, vor oder nach Auslösern, Eskalationsregeln, Zuweisungsregeln usw. verarbeitet wird. Falls Sie dies noch nicht getan haben, stellen Sie sicher, dass Sie ein Lesezeichen setzen und sich mit der Apex[-Ausführungsreihenfolge](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) vertraut machen.

#### Zu stellende Fragen:

- Verfügt Ihr Formular über zusätzliche Anforderungen, die über die Validierung auf Systemebene hinausgehen?
- Müssen Sie festlegen, dass Felder im Formular dynamisch als Pflichtfelder oder schreibgeschützt festgelegt werden?

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Berücksichtigen der Validierung auf Systemebene</th>
      <th scope="col">Benutzerdefinierte Validierung auf Feldebene speziell für dieses Formular</th>
      <th scope="col">Validierung auf benutzerdefinierter Feldebene</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
  </tbody>
</table>

Eingaben in einem Flow-Bildschirm oder OmniScript-Schritt sind naturgemäß nicht gebunden, sodass das Formular selbst nicht nativ an die Validierung auf Systemebene gebunden ist, die einem bestimmten Objekt zugeordnet ist. Unabhängig davon, welche Werte Sie zum Erstellen oder Aktualisieren von Datensätzen verwenden, werden sie jedoch durch die Speicherreihenfolge verarbeitet, d. h., sie durchlaufen die Validierung auf Systemebene des Objekts. Beachten Sie jedoch, dass nicht alle Bildschirm-Flow-Komponenten die Eingabevalidierung unterstützen. Ab der Version Summer '24 sind die verbleibenden Bildschirmkomponenten, die die Eingabevalidierung nicht unterstützen, Optionsfelder, Auswahlliste, Mehrfachauswahlliste, Kontrollkästchengruppe und Auswahlsuche.

Genau wie Seitenlayouts können Sie mit dynamischen Formularen die Erforderlichkeit und den schreibgeschützten Status auf Seitenebene festlegen. Einstellungen auf Systemebene können jedoch nicht überschrieben werden.

Flow bietet Flexibilität bei der Anpassung der Validierung für die Eingaben eines Formulars. Während einige Überprüfungen im Client durchgeführt werden (beispielsweise das Kennzeichnen fehlender Pflichtfelder oder inkompatibler Werte), verhindert keine der clientseitigen Validierungen, dass der Benutzer versucht, zu navigieren. Die eigentliche Validierung erfolgt auf dem Server. Wenn ein Benutzer auf **Weiter** klickt, sendet Flow die Eingaben zur Validierung an den Server. Wenn Eingaben als ungültig zurückgegeben werden, wird die Navigation blockiert und der entsprechende Fehler wird angezeigt. Der Server validiert die Eingaben, indem er Folgendes überprüft:

1. Die Anforderungseinstellung der Eingabe oder ob der eingegebene Wert mit dem zugrunde liegenden Datentyp kompatibel ist.
2. Benutzerdefinierte Validierung für diese Eingabe: Verschiedene Standardkomponenten (Kontrollkästchen, Währung, Datum, Datum/Uhrzeit, langer Textbereich, Zahl, Kennwort und Text) unterstützen die benutzerdefinierte Validierung pro Bildschirm. Geben Sie einen booleschen Formelausdruck und eine Fehlermeldung an, die angezeigt werden sollen, wenn der Formelausdruck nicht erfüllt ist.
3. Benutzerdefinierte Validierung für die zugrunde liegende Komponente: Wenn Sie eine benutzerdefinierte LWC für einen Flow erstellen, fügen Sie der Methode validate() Ihren eigenen Validierungscode hinzu.

OmniStudio bietet umfangreiche 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 "[Bedingte 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)".

Auf der LWC-Seite führen die meisten Basiskomponenten ihre eigenen clientseitigen Validierungen durch. Beispielsweise berücksichtigt Lightning-Datensatzform die Systemebene, nicht jedoch die Seitenebene. Für Ihre benutzerdefinierten Komponenten können Sie Build Your Own Validierungsmechanismen erstellen.

Felder, für die Benutzer Daten eingeben müssen, sollten frühzeitig in Ihren Formularen angezeigt werden. Validieren Sie Benutzereingaben nach Möglichkeit auf Client-Seite, bevor Formulare gesendet werden. Weitere bewährte Vorgehensweisen zur Optimierung Ihrer Formulare finden Sie in der [Formularanleitung](/docs/architect/de-de/well-architected/guide/engaging#formulare) unter Salesforce Well-Architected – Engaging.

### Sicherheit

Sicherheit ist im Allgemeinen ein komplexes Thema. Beim Erstellen von Formularen gibt es eine Reihe von Überlegungen, über die Sie möglicherweise noch nicht einmal nachgedacht haben. Auf der grundlegenden Ebene sollten 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 jedoch auch zusätzliche Maßnahmen ergreifen, um potenziell bösartigen Code oder URLs aus Rich-Text-Feldern zu entfernen, zu verhindern, dass bestimmte Benutzer überhaupt auf das Formular zugreifen können, oder Einschränkungen hinsichtlich der Arten von Stellen festzulegen, an denen Administratoren das Formular in Zukunft potenziell einbetten können. Dokumentieren Sie Ihre Sicherheitsanforderungen sorgfältig, bevor Sie ein Tool auswählen. Die Salesforce Well-Architected [Security Policy Template](/docs/architect/de-de/resources/guide/security-policy-template) enthält Richtlinien für diese Art von Dokumentation.

#### 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?

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Erhöhen von Benutzerberechtigungen</th>
      <th scope="col">Steuern, wer Zugriff hat</th>
      <th scope="col">Zulässige Standorte einschränken</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar**</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar*</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="4">* Erfordert Apex<br>**OmniScripts können zwar keine angegebenen Zielstandorte aufweisen, FlexCards jedoch schon.</td>
    </tr>
  </tbody>
</table>

#### Erhöhen von Benutzerberechtigungen

Wenn etwas 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. Benutzer können also beispielsweise nur dann ein Formular zur Kundenvorgangsaktualisierung ausführen, wenn sie über die Möglichkeit zum Aktualisieren von Kundenvorgängen, die entsprechende Feldebenensicherheit und Zugriff auf den betreffenden Datensatz verfügen. Was geschieht jedoch, 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.

Der Systemkontext ist eine Möglichkeit, die Berechtigungen des aktuellen Benutzers für die Dauer der Sitzung zu erhöhen, sodass der Benutzer beispielsweise den Zugriff "Aktualisieren" auf das Kundenvorgangsobjekt nicht benötigt, um Ihr 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.

Natürlich ist der Systemkontext ein zweischneidiges Schwert und Sie sollten es nur bei Bedarf verwenden. Wenn ein Formular im Systemkontext ausgeführt wird, umgeht jeder einzelne CRUD-Vorgang die Objekt- und Feldebenensicherheit und -freigabe und nicht nur den spezifischen Vorgang, der Ihnen wichtig ist. Beachten Sie auch, dass der Systemkontext keine Auswirkungen darauf hat, wer Salesforce als Akteur betrachtet – der Name, der im Feld "Zuletzt geändert von" angezeigt wird. Für jeden Vorgang, den Ihr Formular ausführt, beispielsweise die Kundenvorgangsaktualisierung, ist der Akteur der aktuelle Benutzer, selbst wenn das Formular in einem anderen Kontext ausgeführt wird.

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 auswählen, ob der Flow Zugriff auf alle Daten erteilen soll oder ob er weiterhin Zugriff auf Datensatzebene wie die Freigabe erzwingt.

- 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, sollten Sie den Flow verwenden, um diese Vorgänge auszuführen und die entsprechenden Daten in die Lightning-Komponente oder aus ihr heraus zu übergeben. Einige vorkonfigurierte Komponenten (z. B. "Nachschlagen") können nicht im Systemkontext verwendet werden.
- Wenn Ihr Flow Apex-Aktionen aufruft, gibt es noch einige weitere Nuancen zu verstehen. Wenn die Apex-Klasse auf "übernommene Freigabe" festgelegt ist, wird sie im Systemkontext mit "Freigabe" ausgeführt, unabhängig davon, auf welche Einstellung der Flow festgelegt ist. Wenn die Klasse keine explizite Freigabedeklaration aufweist, wird sie im Systemkontext ohne Freigabe ausgeführt, unabhängig davon, auf welche Einstellung der Flow festgelegt ist. Wenn die Klasse auf with sharing oder without sharing 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 nicht authentifiziert**, sollten Sie nur bestimmte Felder in Ihren Elementen vom Typ "Datensätze abrufen" speichern. 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, können alle Felder aus diesem Objekt über die Entwicklertools des Browsers überprüft werden. Dadurch werden möglicherweise Felder für Benutzer Ihrer Experience Cloud-Site verfügbar, die Sie möglicherweise nicht beabsichtigen. Durch die Angabe spezifischer Felder in Ihren Elementen vom Typ "Datensätze abrufen" können Sie sicherstellen, dass auch bei aktiviertem Systemkontext nur die richtigen Felder angezeigt werden.

Beachten Sie, dass die OmniScript-Logik clientseitig ausgeführt wird. Dadurch können Angreifer die erwartete Ausführung eines OmniScripts ändern _und_ Antworten auf Aufrufe von Integrationsverfahren, Datenzuordnungen und Apex-Methoden mit den Entwicklertools des Browsers anzeigen. Wenn Sie OmniScript verwenden, sollten Sie nach Möglichkeit Geschäftslogik serverseitig ausführen und Eingabevalidierungsregeln für alle Apex-Methoden 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.

**Desinfektionseingaben:**

Wenn Sie Ihre Organisation vor schlechten Akteuren schützen möchten, sollten Sie auch die Eingabebereinigung in Betracht ziehen. Angenommen, Sie verfügen über eine Eingabe in einem öffentlich zugänglichen Formular, die einem Rich-Text-Feld in Ihrer Organisation zugeordnet werden könnte. Möglicherweise sollten Sie eine Automatisierung in Betracht ziehen, die HTML entfernt, die schädliche URLs verbergen könnte. Im Allgemeinen ist es nicht ideal, diese Bereinigung auf Formularebene zu implementieren, da Sie eine beliebige Anzahl von Quellen in diese Felder schreiben lassen könnten. Es wird empfohlen, einen Flow zur schnellen Feldaktualisierung (Vor dem Speichern) zu erstellen oder einen vorhandenen Apex-Auslöser für das Objekt zu verwenden, um potenzielle HTML-Elemente, die in das Formular eingegeben werden, zu entfernen oder zu ändern.

**_Bewährte Vorgehensweisen:_**

- _Lassen Sie Flows im Standardkontext ausgeführt werden, es sei denn, Sie müssen den Zugriff des aktuellen Benutzers für einen bestimmten Vorgang erhöhen._
- _Vermeiden Sie das Ausführen von Flows im Systemkontext für Gastbenutzer aus Sicherheitsgründen. Erstellen Sie stattdessen Berechtigungssätze mit eingeschränktem Feldzugriff, die dem Gastbenutzerprofil der Experience Cloud-Site zugewiesen sind._
- _Wenn Sie Datensätze in vom Systemkontext ausgeführten Flows auf Experience Cloud-Sites abfragen, speichern Sie nur die Felder, die Sie in Ihrem Element "Datensätze abrufen" oder "Aufrufbare Aktionen" benötigen._
- _Wenn ein Flow eine Vielzahl von Vorgängen ausführt und nicht alle einen erhöhten Zugriff erfordern, verwenden Sie Subflows, um die Vorgänge zu isolieren, die im Systemkontext ausgeführt werden sollten._
- _Wenn Sie planen, ein Formular in eine externe Webseite einzubetten, sollten Sie ggf. Benutzereingaben bereinigen, um HTML mithilfe eines Flows für schnelle Feldaktualisierungen oder Apex Triggers zu entfernen, wenn sie schließlich Rich Text-Feldern zugeordnet werden, um potenzielle Phishing-Angriffe durch schlechte Akteure zu verhindern._

#### Zusätzliche Hinweise:

- OmniScripts, FlexCards und LWCs werden standardmäßig im Benutzerkontext ausgeführt.
- LWCs werden standardmäßig im Benutzerkontext ausgeführt und Flows werden im Benutzerkontext ausgeführt. Sie können dies jedoch in einem Apex-Steuerfeld überschreiben.
- Über die Benutzeroberflächen-API ausgeführte Vorgänge werden im Benutzerkontext ausgeführt.
- Über ein Apex-Steuerfeld ausgeführte Vorgänge hängen von dieser Klasse ab. Wenn Sie diese Vorgänge im Systemmodus ausführen möchten, legen Sie die Apex-Klasse mit oder ohne Freigabe fest.

#### Zugriffssteuerung

Wenn Sie steuern müssen, wer auf Ihr Formular zugreifen kann, können Sie oft den Container anzeigen, in den das Formular eingebettet ist. Beispielsweise können Sie Lightning-Seiten zuweisen, die für bestimmte Anwendungen, Datensatztypen oder Profile verfügbar sind. Wenn bestimmte Eingaben in Ihrem Formular vertraulich sind, verwenden Sie Sichtbarkeitsregeln, um weiter zu 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 eine Apex Klasse oder Visualforce Seite. Flows sind standardmäßig uneingeschränkt. Das bedeutet, dass jeder Benutzer mit der Benutzerberechtigung "Flows ausführen" sie ausführen 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, um sicherzustellen, dass Benutzer expliziten Zugriff auf die Apex-Klasse benötigen, die die über eine OmniScript-, FlexCard-, Classic Card- oder REST-API aufgerufene Remote-Aktion verwaltet.

- Hinweis: Berechtigungsprüfungen für Apex-Klassen sind für neu erstellte Skripts standardmäßig aktiviert. Sie müssen jedoch für vorhandene Skripts manuell aktiviert werden.
- Beachten Sie außerdem, dass die Apex-Klassenberechtigungsprüfungen nur für Apex-Klassen gelten. Es wird empfohlen, Berechtigungen auf Profilebene auch 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.

Weitere Details und bewährte Vorgehensweisen zu Gastbenutzerberechtigungen finden Sie unter:

- [Bewährte Vorgehensweisen für den Gastbenutzerzugriff auf Datensätze](https://www.learnexperiencecloud.com/s/article/Guest-User-Record-Access-Development-Best-Practices#Pattern6)
- [Entwickeln sicherer Sites: Authentifizierte Benutzer und Gastbenutzer](https://developer.salesforce.com/docs/atlas.en-us.communities_dev.meta/communities_dev/communities_dev_security_authenticated_and_guest_users.htm)

**_Bewährte Vorgehensweisen:_**

- _Wenn Sie Gastbenutzern einen Flow bereitstellen, erteilen Sie dem Gastbenutzerprofil nur Zugriff auf die benötigten Flows. Obwohl es möglich ist, dem Gastbenutzerprofil "Flows ausführen" hinzuzufügen, wird dies als riskante Vorgehensweise erachtet._
- _Seien Sie besonders vorsichtig bei Flows, die im Systemkontext funktionieren. Es wird dringend empfohlen, diese Flows auf eine bestimmte Gruppe von Benutzern zu 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 "with sharing" aufweist._
- _ Weisen Sie in Ihrem Gastbenutzerprofil nur die Apex-Klassen zu, die Gastbenutzer aufrufen können sollen. Andernfalls besteht die Gefahr, 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. Direkt aus JavaScript können Sie Salesforce-Berechtigungen aus den Umfangsmodulen @salesforce/userPermission und @salesforce/customPermission importieren. Alternativ können Sie Apex verwenden, um dasselbe zu überprüfen.

#### Einbettungssteuerung

Lightning-Webkomponenten sind an einem bestimmten Ort nur verfügbar, wenn 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, unabhängig davon, ob er überall verfügbar sein soll oder nicht. Flow Builder unterstützt jedoch mehrere Flow-Typen mit Bildschirmen. Der Brot-und-Butter-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 – Sie haben es erraten. Dasselbe gilt für 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 werden kann. Der Flow ist an allen für diesen Flow-Typ unterstützten Standorten verfügbar.

Wenn Sie Salesforce-Branchen verwenden, gibt es in Bezug auf OmniScript einen kleinen Vorbehalt: Obwohl Sie kein Ziel für ein OmniScript selbst angeben können, können Sie eines für die FlexCards angeben, die Sie möglicherweise darin einbetten möchten.

### Interaktionsdesign

Statische Formen gehören der Vergangenheit an. Heute geht es darum, das Formular mit den richtigen Eigenschaften und Werten für diesen Benutzer dynamisch zu aktualisieren, diesmal an diesem Ort. Lassen Sie uns darüber sprechen, was in diesem Sinne für die Formularerstellungstools von Salesforce 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 während des Ausfüllens Ihres Formulars im Hintergrund ausführen?
- Müssen Sie Felder als sichtbar, erforderlich, schreibgeschützt oder deaktiviert festlegen oder die Formatierung anhand von Formulareingaben ändern?

<table>
  <colgroup>
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Ausführen von Off-Screen-Datenvorgängen</th>
      <th scope="col">Bedingte Werte und Berechnungen</th>
      <th scope="col">Bedingte Sichtbarkeit</th>
      <th scope="col">Bedingte Anforderung</th>
      <th scope="col">Bedingte Formatierung</th>
      <th scope="col">Bedingter schreibgeschützter Status</th>
      <th scope="col">Bedingter deaktivierter Status</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar**</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar*</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar**</td>
      <td class="guide-table-ok">Verfügbar**</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="8">* Beschränkt auf Komponenten, die eine Ressourcenauswahl und kein statisches Kontrollkästchen verwenden<br>**Eingeschränkte Beta-Version</td>
    </tr>
  </tbody>
</table>

Dank reaktiver Bildschirme ist die Bildschirm-Flow-Interaktivität nun Realität. Durch die Reaktivität können einzelne Komponenten auf einem Flow-Bildschirm miteinander kommunizieren, wodurch Bildschirm-Flows unendlich leistungsfähiger werden.

**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. Anschließend können Sie die Ergebnisse dieser automatisch gestarteten Flows demselben Bildschirm zuordnen, sodass Benutzer nicht mehr zu einem anderen Bildschirm navigieren müssen.

LWC bietet eine umfassende Palette von Wire-Adaptern, mit denen Sie auf Salesforce-Daten zugreifen können, um Daten in den Komponenten Ihres Formulars dynamisch auszufüllen, und ermöglicht es Entwicklern, Datensätze über Apex-Steuerfelder zu aktualisieren, zu löschen und zu erstellen.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-offscreendataoperations-noheader.png" alt="Vorgänge für Lightning-Webkomponenten außerhalb des Bildschirms"> _Datenvorgänge für Lightning-Webkomponenten außerhalb des Bildschirms_](/docs/architect/de-de/reference-diagrams/guide/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 mit Komponentensichtbarkeitsfunktionen. Damit können Sie Felder deklarativ anhand anderer Werte im Formular anzeigen oder ausblenden oder festlegen, ob sich der Benutzer auf einem Mobilgerät befindet.

- Mit dynamischen Formularen kann die Sichtbarkeit anhand von Datensatzfeldwerten, über Nachschlagefelder zugeordneten Datensätzen und Formfaktoren gesteuert werden.
- Mit Flow können Sie eine Sichtbarkeitsregel auf anderen Eingaben auf dem Bildschirm sowie anderen Ressourcen basieren, die zuvor im Flow ausgefüllt wurden, beispielsweise Formeln oder Werte aus anderen Datensätzen.
  - **Gerätebasierte Regeln:** Es ist nicht von Anfang an offensichtlich. Sie können jedoch eine Formel verwenden, um ein bestimmtes Feld anzuzeigen 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, befindet sich der Benutzer in der mobilen Salesforce-Anwendung.
  - **Auswerten anderer Ressourcen:** Manuelle Variablen- und Formelverweise werden nur auf dem Server ausgewertet. Welchen Wert diese Ressource also beim ersten Rendern des Bildschirms hat, ist der Wert, den sie hat, bis Sie zu einem anderen Bildschirm navigieren. Bei der Navigation sendet die Flow-Laufzeit eine Anforderung an das Flow-Modul (den Server) und erhält die neuesten Werte der manuellen Variablen und Formeln zurück. Wenn Sie erwarten, dass Ihre Sichtbarkeitsregel aktualisiert wird, während der Benutzer einen einzelnen Bildschirm durchläuft (z. B. onblur), stellen Sie sicher, dass Sie nur auf Werte aus den anderen Komponenten auf dem Bildschirm verweisen.
- Mit OmniStudio können Sie Komponenten bedingt anzeigen oder ausblenden, indem Sie eine Eigenschaft für 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, beispielsweise ob ein Feld erforderlich, deaktiviert oder schreibgeschützt ist, haben Sie einige Möglichkeiten. Erwartungsgemäß können Sie mit LWC Ihren Eingabestatus vollständig und reaktiv steuern. Mit reaktiven Bildschirm-Flow-Komponenten können Sie Komponentenattribute wie "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, beispielsweise ob ein Feld erforderlich oder schreibgeschützt ist, sollten Sie kurzfristig am besten LWC verwenden, wo Sie die volle 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 LWCs erstellen, die auf andere Komponenten in einem Bildschirm-Flow reagieren und sie ändern können, lesen Sie diesen Leitfaden zu [bewährten Vorgehensweisen für Bildschirm-Flows](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows), um sicherzustellen, dass Ihre Komponenten gut in das Flow-Laufzeitmodul integriert werden und wie erwartet in der Zukunft funktionieren.

<table>
  <colgroup>
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Standardmäßige Ereignisverarbeitung (Unschärfe, Fokus)</th>
      <th scope="col">Benutzerdefinierte Ereignisverarbeitung</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar*</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="3">* Die OmniStudio-Standardlaufzeit unterstützt Pub/Sub nicht, Windows postMessage jedoch nicht</td>
    </tr>
  </tbody>
</table>

Nun für benutzerdefinierte Ereignisse. Wenn einige Ihrer Eingaben oder das gesamte Formular mit etwas anderem auf der Seite kommunizieren müssen, ist LWC die einzige Option.

- 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 [**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 **Pub/Sub-Modul**.

#### Zusätzliche Ressourcen

- Weitere Details 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).
- Konsultieren Sie für OmniStudio "Mit OmniScript kommunizieren" aus einer Lightning-Webkomponente. [](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 der Stil Ihres Formulars mit dem Rest der Anwendung oder Site, auf der es eingebettet ist, konsistent ist. Dies kann alles bedeuten, von der Verwendung der von Salesforce bereitgestellten Standardvorlagen bis hin zur Erstellung von benutzerdefiniertem CSS, das jedes Pixel im Design vollständig nutzt, um ein schärferes Erscheinungsbild zu bieten.

#### Zu stellende Fragen:

- Wie anspruchsvoll ist Ihr gewünschter Stil und CSS?
- Benötigen Sie einen benutzerdefinierten, pixelgenauen Stil oder sind Sie mit Standardthemen einverstanden?

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Direkter Stil</th>
      <th scope="col">Organisations- und Erfahrungsgeneratorthemen</th>
      <th scope="col">Pixel-perfekter Stil</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-roadmap">Roadmap</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar*</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="4">*Nur Flexkarten</td>
    </tr>
  </tbody>
</table>

FlexCards ist das einzige in diesem Handbuch behandelte Produkt, mit dem Sie den Stil und das Layout der Benutzeroberfläche, die Sie im Tool erstellen, direkt deklarativ steuern können – unabhängig davon, ob es sich dabei um Ränder und Innenabstände, Typografie, Farben usw. handelt.

Dynamische Formulare und Flows berücksichtigen deklarative Themenfunktionen. Wenn Sie mehr Kontrolle darüber benötigen, was [Salesforce-Themen](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), [Erfahrungsgenerator-Brandingsätze](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) unterstützen, sollten Sie eine programmgesteuerte Lösung in Betracht ziehen.

Für Teams, die mit CSS vertraut sind, haben Sie mehrere Möglichkeiten:

- Flows und Lightning-Webkomponenten übernehmen [Standarddesigntoken](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm).
- OmniScripts und FlexCards unterstützen ein anpassbares Designsystem: [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 HTML und CSS vollständig steuern.

Es wird empfohlen, nach Möglichkeit Themen und Designsysteme zu verwenden, damit Ihr Erscheinungsbild einheitlich auf alle Ihre Inhalte angewendet wird.

Erinnerung: Lightning-Komponenten können in Flows eingebettet werden. Wenn Sie also das Erscheinungsbild Ihres Formulars pixelgenau steuern möchten, aber die anderen Vorteile von Flows wie das Navigationsmodell nutzen möchten, können Sie beides optimal nutzen. 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. Weitere Informationen zu diesem Thema finden Sie unter [Salesforce Well-Architected – Forms](/docs/architect/de-de/well-architected/guide/engaging#formulare).

#### Zu stellende Fragen:

- Wie können Sie das Layout Ihres Formulars verwenden, um die Benutzererfahrung zu optimieren?
- Wie können Sie Ihren Benutzern vorhandene Daten so präsentieren, dass sie leichter neue Daten in Ihre Formulare eingeben können?

<table>
  <colgroup>
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">2 Spalten</th>
      <th scope="col">4 Spalten</th>
      <th scope="col">Jenseits von 4 Spalten</th>
      <th scope="col">Wiederholen von Datenblöcken</th>
      <th scope="col">Registerkartencontainer</th>
      <th scope="col">Akkordeonbehälter</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar*</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="7">* Registerkarten können verwendet werden, wenn Daten in eine FlexCard in ein OmniScript eingebettet werden</td>
    </tr>
  </tbody>
</table>

Dynamische Formulare unterstützen zweispaltige Layouts und können in einzelne Abschnitte mit Feldern unterteilt werden. Diese Abschnitte können in Komponenten wie Registerkarten und Akkordeons platziert werden, um benutzerfreundliche und organisierte Layouts zu erstellen.

Flows können optional mithilfe der Komponente "Abschnitt" dargestellt werden. Mit Abschnitten können Sie bis zu vier Spalten und beliebig viele Abschnitte auf dem Flow-Bildschirm hinzufügen. Die Komponente reagiert auch auf die Bildschirmbreite, sodass sie auf kleineren Bildschirmen verwendet werden kann. Schließlich können Sie damit die bedingte Sichtbarkeit auf den gesamten Abschnitt anwenden, 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/CSS. Lightning-record-form berücksichtigt die Abschnittskonfiguration im zugeordneten Seitenlayout. Wenn ein Abschnitt beispielsweise im Seitenlayout zweispaltig ist, ist er in dieser Komponente zweispaltig.

### Translation

Wenn Benutzer in unterschiedlichen Regionen oder Sprachen auf Ihr Formular zugreifen können, müssen Sie sicherstellen, dass das Tool, das Sie zum Erstellen verwenden, Ihre Lokalisierungsanforderungen erfüllt. Weitere Anleitungen und Empfehlungen finden Sie unter [Salesforce Well-Architected – Localization](/docs/architect/de-de/well-architected/guide/compliant#lokalisierung). 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?

<table>
  <colgroup>
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Im Generator eingegebene Bezeichnungen</th>
      <th scope="col">Bezeichnungen im Code</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td class="guide-table-ok">Verfügbar*</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="3">* Nur Feldabschnittsüberschriften</td>
    </tr>
  </tbody>
</table>

Wenn Sie Ihre benutzerdefinierten Felder lokalisiert haben, werden diese übersetzten Bezeichnungen in dynamischen Formularen berücksichtigt. Dynamische Formulare berücksichtigen auch [benutzerdefinierte Bezeichnungen, die](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5) Sie Komponentenbezeichnungen und Attributen im Lightning-Anwendungsgenerator zugewiesen haben.

Mit der leistungsstarken Übersetzungsworkbench unterstützt Flow die Übersetzung von benutzerdefinierten Bezeichnungen für alle standardmäßigen und benutzerdefinierten Bildschirmkomponenten. Sie können die Bezeichnung, den Hilfetext und die Fehlermeldung der folgenden Bildschirmkomponenten lokalisieren: Text, langer Textbereich, Zahl, Währung, Kontrollkästchen, Optionsfelder, Auswahlliste, Mehrfachauswahlliste, Kontrollkästchengruppe, Kennwort, Datum/Uhrzeit.

Für vorkonfigurierte Aktionen wie "E-Mail senden" oder "Bei Chatter posten" gibt es keine integrierte Übersetzungsunterstützung. Es gibt jedoch eine Übergangslösung! Wenn Sie die übersetzten Bezeichnungen mit einer [benutzerdefinierten Bezeichnung](https://help.salesforce.com/articleView?id=cl_about.htm) definieren, können Sie bei der Konfiguration in Flow Builder in der Aktion oder Komponente auf diese benutzerdefinierte Bezeichnung verweisen. Erstellen Sie eine Flow-Formel, die auf die benutzerdefinierte Bezeichnung verweist, und verweisen Sie an den entsprechenden Stellen in Ihrem Flow auf diese Formel.

OmniScripts verwenden benutzerdefinierte Bezeichnungen für Übersetzungen. Lesen Sie [diese Hilfedokumentation](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm), um Ihre mehrsprachigen OmniScripts vorzubereiten.

Nun zu LWC. Bestimmte Basiskomponenten übernehmen automatisch Übersetzungen der Felder, Hilfetexte und Validierungsmeldungen des zugeordneten Objekts, wenn sie in der Übersetzungsworkbench konfiguriert wurden (z. B. Lightning-Datensatzform).

Wenn Sie neue übersetzbare Bezeichnungen in Ihren Code einfügen müssen, sind benutzerdefinierte Bezeichnungen immer noch der unbesungene Held. Deklarieren Sie die benötigte benutzerdefinierte Bezeichnung und importieren Sie sie dann aus dem Umfangsmodul @salesforce/label in Ihre Komponente.

### Benutzeroberflächentestautomatisierung

Es sind mehrere durchgängige Testautomatisierungstools verfügbar (z. B. Selenium), mit denen Sie simulieren können, wie der Benutzer mit Ihrem Formular interagiert. Sie können diese Tests für jede standardmäßige oder benutzerdefinierte Benutzeroberfläche schreiben, einschließlich Lightning-Seiten und Bildschirm-Flows. Beachten Sie jedoch, dass diese Testtypen die Ausgaben der einzelnen ausgeführten Methoden nicht überprüfen können. Beachten Sie dies, wenn Sie Ihre Anforderungen an die Automatisierung von Benutzeroberflächentests durchdenken.

#### Zu stellende Fragen:

- Benötigen Sie automatisierte Tests für Ihr Formular?
- Welche Arten von Tests müssen durchgeführt werden?
- Welche Granularitätsstufe benötigen Sie bei Ihren Testautomatisierungen?

<table>
  <colgroup>
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Einheitentests</th>
      <th scope="col">Durchgängige Automatisierung</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar*</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td>Nicht verfügbar</td>
      <td class="guide-table-ok">Verfügbar*</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar*</td>
      <td class="guide-table-ok">Verfügbar*</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar*</td>
      <td class="guide-table-ok">Verfügbar*</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="3">* Erfordert Code</td>
    </tr>
  </tbody>
</table>

Beachten Sie Ihre Anforderungen an die Automatisierung von Benutzeroberflächentests.

**Einheitentests** ermöglichen eine detailliertere Automatisierung und Validierung, die mit CI/CD-Standardsystemen und -Tools der Branche funktioniert. Dadurch können die Geschäftslogik der Komponenten, ihr JavaScript-Steuerfeld und ihre Ausgaben getestet werden. Wenn Sie ausschließlich Low-Code verwenden, können Sie keine Selbstautorisierungstests durchführen. Salesforce testet jedoch unsere durchgängigen Angebote sorgfältig.

Wenn die Methoden Ihrer Komponente so komplex sind, dass sie einzeln getestet werden sollen, legen Sie die Methoden in dedizierte JavaScript-Dateien fest. Auf diese Weise können Sie sie in eine LWC und in einen Jest-Test mit etwas wie `import { sort } from 'c/utils';` importieren.

Unter [Benutzeroberflächentestautomatisierung in Salesforce](https://developer.salesforce.com/blogs/2020/01/ui-test-automation-on-salesforce.html) finden Sie einen Vergleich der verschiedenen Optionen zum Erstellen einer durchgängigen Automatisierung in Salesforce. Es werden Überlegungen dazu angestellt, wann Sie eine No-Code-Lösung aus einem ISV verwenden, Build Your Own Custom Test Automation-Lösung erstellen oder ein Open-Source-Test-Framework wie Selenium WebDriver oder WebdriverIO verwenden sollten. Diese Lösungen sind für jede Benutzeroberflächeninteraktion in Salesforce gültig, unabhängig davon, ob es sich um ein dynamisches Formular auf einer Lightning-Seite, einen Bildschirm-Flow auf einer Dienstprogrammleiste oder eine LWC in einem Flow in einer Schnellaktion handelt.

### Kennzahlen

Nachdem Sie Ihr Formular in einer Produktionsumgebung bereitgestellt haben, sollten Sie sicherstellen, dass es effektiv verwendet wird. Abhängig von Ihrem Anwendungsfall kann dies alles bedeuten – von der einfachen Verfolgung der Häufigkeit des Ausfüllens bis hin zur Zeit, die Benutzer damit verbringen, sie auszufüllen, bevor sie ihre Informationen senden. Geben Sie vor der Auswahl eines Tools die KPIs an, die verfolgt werden sollen.

#### Zu stellende Fragen:

- Müssen Sie die Nutzung Ihres Formulars verfolgen?
- Welche KPIs bestimmen, ob Ihr Formular effektiv verwendet wird?

<table>
  <colgroup>
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Seitenaufrufe</th>
      <th scope="col">Zeitaufwand für Formular</th>
      <th scope="col">Verfolgen des Formularabschlusses</th>
      <th scope="col">Verfolgen der Erfolgsrate</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td class="guide-table-ok">Verfügbar**</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar*</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar*</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar*</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar**</td>
      <td class="guide-table-ok">Verfügbar*</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="5">* Verfügbar bei aktivierter paketbasierter OmniStudio-Laufzeit<br>** Verfügbar durch Verfolgen der Nutzung übergeordneter Lightning Seiten</td>
    </tr>
  </tbody>
</table>

Wenn Sie die Gesamtnutzung und Akzeptanz Ihres Formulars verfolgen müssen, beginnen Sie mit den Low-Code-Tools. Dynamische Formulare und Bildschirm-Flows können mit vorkonfigurierten benutzerdefinierten Berichtstypen verfolgt werden. Die Berichte zur Bildschirm-Flow-Verfolgung sind jedoch genauer. Wenn Sie die Nutzung einer LWC verfolgen müssen, hängt die vorkonfigurierte Verfügbarkeit davon ab, wo Sie diese LWC verwenden. Wenn sie sich auf einer Lightning-Seite befindet, gilt für Ihre Lightning-Seitennutzung alles, was zum Verfolgen der Lightning-Seitennutzung verfügbar ist. Dasselbe gilt für LWCs, die in Flows eingebettet sind.

Dynamische Formulare selbst 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 der Lightning-Standardseiten den benutzerdefinierten Berichtstyp "_Benutzer mit Lightning_-Nutzungskennzahlen nach Seite". Verwenden Sie für dieselben auf benutzerdefinierten Lightning-Seiten den benutzerdefinierten Berichtstyp "_Benutzer mit Lightning_-Nutzung nach FlexiPage-Kennzahlen".

Mit Flow können Sie die Akzeptanz Ihres spezifischen Formulars verfolgen (nicht nur die Seite, auf der es sich befindet). Verwenden Sie den Beispiel-Flow-Bericht: Bildschirm-Flows“ zum Beantworten von Fragen wie:

- Wie hoch ist die Abschlussrate für dieses Formular? Wird es gut angenommen?
- Wie lange dauert das Ausfüllen dieses Formulars?
- Auf welchem Bildschirm verbringen Benutzer die meiste Zeit?
- Wie oft navigieren Benutzer rückwärts?
- Wie oft treten Fehler auf?

Wenn der Standardbericht Ihre Anforderungen nicht erfüllt, duplizieren Sie ihn, um Ihre eigenen Änderungen vorzunehmen, oder erstellen Sie Build Your Own von Grund auf neu, indem Sie den Berichtstyp "_Bildschirm-Flows_" verwenden.

Wenn Sie die paketbasierte OmniScript-Laufzeit verwenden, können Sie den [Service "OmniStudio for Vlocity Tracking](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5)" verwenden. Dieser Service verfolgt alle Arten von Ereignissen. Beispielsweise können Sie die Zeit verfolgen, die zum Abschließen der Schritte in einem OmniScript benötigt wird, um Prozessverbesserungen zu identifizieren. Sie befindet sich auf der Roadmap des OmniStudio-Teams, um diesen Service in Standard-OmniStudio zu unterstützen.

Wenn Sie dasselbe für eine LWC verfolgen möchten, die nicht in einen Bildschirm-Flow, ein OmniScript oder eine Lightning-Seite eingebettet ist, gibt es keine vorkonfigurierte Option. Mit Apex können Sie eine benutzerdefinierte Lösung erstellen.

### Paketerstellung und Bereitstellung

Wenn Sie Ihre Lösung in höheren Umgebungen zum Testen oder Bereitstellen in der Produktion bereitstellen müssen, sind Sie möglicherweise daran gewöhnt, dafür Änderungssets oder DevOps Center zu verwenden. Dynamische Formulare, Flows und LWCs werden in diesen Bereitstellungsoptionen vollständig unterstützt. Für OmniStudio ist ein separates Tool erforderlich: [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 Ihr Formular bereitstellen?
- Wird Ihr Formular an mehrere Salesforce-Organisationen verteilt?

<table>
  <colgroup>
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Verwaltete Pakete der ersten Generation (1GP)</th>
      <th scope="col">Verwaltete Pakete der zweiten Generation (2GP)</th>
      <th scope="col">Entsperrte Pakete</th>
      <th scope="col">Änderungssets</th>
      <th scope="col">DevOps Center</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Dynamische Formulare</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar</td>
      <td>Nicht verfügbar*</td>
      <td>Nicht verfügbar*</td>
    </tr>
    <tr>
      <th scope="row">Bildschirm-Flow + LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
      <td class="guide-table-ok">Verfügbar</td>
    </tr>
    <tr>
      <td colspan="6">* Verwenden Sie die IDX-Workbench, um OmniStudio-Lösungen in anderen Organisationen bereitzustellen.</td>
    </tr>
  </tbody>
</table>

Wenn Sie ein ISV oder Partner sind und planen, ein Paket mit Ihrer Lösung für die Verteilung auf AppExchange zu erstellen, sollten Sie sich zunächst Dynamische Formulare, Flows und LWCs ansehen. OmniStudio unterstützt keine Paketerstellung.

## Zusätzliche Themen

### Navigieren im Low-Code-Kontinuum zu Pro-Code

Dieser Leitfaden soll Ihnen helfen, zu verstehen, welche Funktionen und Anpassungsebenen mit dynamischen Formularen, Bildschirm-Flows, OmniStudio und LWC möglich sind. Auf hohem Niveau:

<img align="left" style="border:1px solid #e5e5e5;float:left;width:50%;margin-right:2rem" src="https://architect.salesforce.com/ns-assets/guide-forms-lowcode-continuum.png" alt="Kontinuum von Low-Code zu Pro-Code">

<br>

- LWC ist die anpassbarste und robusteste Option zum Erstellen eines Formulars, verfügt jedoch über die wenigsten vorhandenen Leitplanken. Es liegt an Ihnen, eine Komponente so zu erstellen, dass [Sicherheit](/docs/architect/de-de/well-architected/guide/secure) und [Skalierbarkeit](/docs/architect/de-de/well-architected/guide/reliable#skalierbarkeit) gewährleistet sind.
- Dynamische Formulare sind am wenigsten flexibel, es gibt jedoch viel weniger Möglichkeiten für Fehltritte.
- Flow und OmniStudio befinden sich irgendwo in der Mitte – leistungsfähiger als dynamische Formulare, aber nicht ganz auf LWC-Ebene. Sie verfügen über weniger Leitplanken als dynamische Formulare, sind jedoch schwerer zu knacken als benutzerdefinierter Code.

Wenn mehrere Tools in die Rechnung passen, wird entschieden, welches Tool für Ihr Team das richtige ist. Andere [Architektenentscheidungsleitfäden](/decision-guides) enthalten zusätzliche Aspekte, die bei dieser Entscheidung berücksichtigt werden sollten.

Auf die Details dieser Aspekte wird hier nicht eingegangen, aber wir werden sie für die spezifischen Tools interpretieren, die dieses Dokument bewertet.

**Spezielle Fertigkeiten**: Wie viel Fachwissen hat Ihr Team in Bezug auf die Tools, die Sie vergleichen? Wie viele Macher sind mit LWC oder JavaScript vertraut? Wie sieht es mit Machern aus, die Flow Builder-Experten sind oder Interesse daran bekundet haben? Generell sind dynamische Formulare und Flow-Fertigkeiten für eine breitere Population von Personen, die Formulare erstellen, besser erreichbar. Dynamische Formulare sind das deklarativste Tool zum Erstellen von Formularen und werden immer einfacher zu erlernen sein als Flow. Das Flow-Team ist bestrebt, diese Messlatte so niedrig wie möglich zu halten. In Bezug auf die Komplexität befindet sich OmniStudio irgendwo zwischen Flow und LWC und bietet erhebliche Superkräfte beim Erstellen von Formularen.

**Zustellungsdelegation**: Nur weil einige Ihrer Anforderungen LWC erfordern, bedeutet das nicht, dass Ihre gesamte Lösung mit LWC erstellt werden muss. Überlegen Sie, wie Sie Ihre Lösung modular erstellen können, sodass die Teile, für die LWC erforderlich ist, und die Teile, für die keine LWC erforderlich ist, in einer Low-Code-Lösung erstellt werden. Dadurch wird die Effizienz eines vielfältigen Teams maximiert und sichergestellt, dass jeder Einzelne Probleme löst, die seiner Spezialisierung entsprechen.

Nun zu Flow und LWC. Mit reaktiven Bildschirmkomponenten können Bildschirm-Flow-Komponenten nun auf demselben Bildschirm miteinander kommunizieren und so eine völlig neue Werkzeugkiste für Architekten, Administratoren und Entwickler freischalten. Entwickler können nun zielgerichtete, modulare Komponenten erstellen, die in der gesamten Organisation wiederverwendet werden können, was die Produktivität für alle im Team steigert. Entwickler können sich auf die Lösung neuer Herausforderungen konzentrieren und Zeit sparen, indem sie eine Kombination aus standardmäßigen und benutzerdefinierten Flow-Komponenten verwenden, um eine Formdynamik zu erreichen. Mit reaktiven Komponenten in Flow gab es nie einen günstigeren Zeitpunkt, um Flow und LWC beim Erstellen Ihrer Formulare zu kombinieren.

**Wartbarkeit und langfristige Inhaberschaft**: Wenn Sie über ein Formular mit mehreren Schritten verfügen, sollten Sie mit Flow oder einer Kombination aus Flow und LWC beginnen. Wenn Sie über ein Low-Code-Team verfügen, das die Lösung verwaltet, sollten Sie überlegen, wie Sie die Lösung für diese Zielgruppe so konfigurierbar und erweiterbar wie möglich gestalten können. Unabhängig davon, welches Tool Sie auswählen, organisieren Sie Ihre Lösung in [zusammensetzbare](/docs/architect/de-de/well-architected/guide/composable) Einheiten, um die Wartungsfähigkeit und Stabilität zu verbessern.

### Seitenlayouts

Dynamische Formulare im Lightning-Anwendungsgenerator mit Lightning-Seiten werden künftig empfohlen, um Datensatz-Detailseiten zu konfigurieren. Es ist lange her, dass wir erweiterte Seitenlayouts haben, und dieser Trend wird sich fortsetzen. Folgender Grund:

- Dynamische Formulare sind flexibler. Sie können Felder und Abschnitte direkt im Lightning-Anwendungsgenerator an beliebiger Stelle platzieren, wo Sie Abschnitte, Registerkarten und Akkordeons nutzen können. Wie bei Komponenten auf der Lightning-Seite können Sie die Sichtbarkeit Ihrer Felder und Abschnitte steuern, ohne mehrere Seitenlayouts oder Datensatztypen definieren zu müssen.
- Mit den Komponenten "Akkordeon" und "Registerkarte" können Sie die Anzahl der anfänglich angezeigten Felder einschränken. Raten Sie, was das bedeutet? Schnellere Seitenladezeiten.
- Die Layoutverwaltung mit Lightning-Seiten ist einfacher, da Sie alles über Ihre Seiten im Lightning-Anwendungsgenerator verwalten können – unabhängig davon, ob es sich um den Inhalt der Seite handelt oder welche Benutzer Zugriff auf die Seite haben. Es ist nicht mehr erforderlich, Aktualisierungen an Ihrem Seitenlayout vorzunehmen, um Änderungen an Ihrer Lightning-Seite vorzunehmen. Ganz zu schweigen davon, dass Sie dank der leistungsstarken Sichtbarkeitsregeln nicht mehr mehrere Seiten (oder Seitenlayouts) erstellen müssen, um zu steuern, wer wann welche Felder sieht. Das bedeutet auch, dass Sie Benutzern nur eine Lightning-Seite zuweisen müssen, statt sowohl eine Lightning-Seite als auch ein Seitenlayout zuzuweisen.

Es wird empfohlen, nach Möglichkeit dynamische Formulare zu verwenden und nur bei Bedarf auf Seitenlayouts zurückzugreifen. Wie immer freuen wir uns über Feedback im [Ideenaustausch](https://ideas.salesforce.com/s/) zu den Verbesserungen, die für Ihre Organisation am effektivsten wären.

### Leistung

Alle Überlegungen zur Leistung in Bezug auf dynamische Formulare, Bildschirm-Flows, OmniStudio und LWC konzentrieren sich auf das Framework, auf dem diese Technologien selbst basieren. Die auf LWC basierenden (neben natürlich einer LWC) werden die auf Aura basierenden übertreffen. Das LWC-Framework bietet eine bessere Leistung, da die Kernfunktionen nativ in Webmodulen und nicht in JavaScript über Framework-Abstraktionen implementiert werden. Wenn Sie nicht vertraut sind, lesen Sie [diesen Blogpost](https://developer.salesforce.com/blogs/2018/12/introducing-lightning-web-components.html).

Bereits 2019 haben wir eine [Kundenvorgangsstudie](https://developer.salesforce.com/blogs/2019/06/case-study-dreamhouse-gains-speed-by-switching-to-lwc.html) durchgeführt, in der die Leistung der gleichen Funktionen in Aura mit der in LWC verglichen wurde. Durch die Konvertierung von DreamHouse von Aura in LWC wurde nicht nur die Entwicklungserfahrung viel besser an die aktuellen Web-Front-End-Entwicklungsstandards und -muster angepasst, sondern auch die Leistungssteigerungen waren erheblich. Labormessungen ergaben Gewinne im Bereich von **2,4 Prozent bis 24,7 Prozent** für Cold-Cache und Gewinne im Bereich von **31,83 Prozent bis** **63,32 Prozent** für Warm-Cache auf denselben beiden Seiten.

Welches Framework verwenden unsere Formulartechnologien? Anders ausgedrückt: Welche Formtechnologien profitieren von dieser überlegenen Leistung?

- Dynamische Formulare, die in die Metadaten von Lightning-Seiten integriert sind, basieren auf einer Grundlage, die den LWC-Stapel verwendet, wodurch einige lang angeforderte Funktionen implementiert werden können. Dynamische Formulare verwenden ein progressives Rendering, was zu einer verbesserten Seitenladezeit für Seiten mit einer großen Anzahl von Feldern führt.
- Bildschirm-Flows basieren auf LWC, wobei die meisten der einzelnen vorkonfigurierten Komponenten nun in LWC konvertiert wurden, mit Ausnahme von zwei vorkonfigurierten Komponenten: Datei hochladen und Bild. 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. Darüber hinaus unterstützt Salesforce nur LWC-Komponenten im neuen Framework für reaktive Komponenten in Bildschirm-Flows. Es gibt ein ausgezeichnetes Trailhead Modul, in dem erläutert wird, wie dies funktioniert: [Lightning Web Components für Aura-Entwickler](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers). Es versteht sich von selbst: Wenn Sie darüber nachdenken, eine benutzerdefinierte Komponente für einen Bildschirm-Flow oder einen anderen Container zu erstellen, sollten Sie immer LWC verwenden.
- Es sind einige Versionen von OmniStudio verfügbar. Wenn Sie ein langjähriger Kunde sind, verwenden Sie möglicherweise Angular. Wir empfehlen allen Neukunden, mit LWC-basierten OmniScripts und FlexCards zu beginnen und bestehende Kunden von Angular zu migrieren.
- LWC basiert auf ... Natürlich LWC. Das ist ein Freebie. 🤓

## Schlussbemerkungen

Als Architekt ist es wichtig, dass Sie alle Optionen, die Ihnen zur Verfügung stehen, genau kennen und wissen, wie Sie sie in Ihrem speziellen Anwendungsfall anwenden können. Beim Erstellen von Formularen in Salesforce reichen die Optionen von Low-Code (mit dynamischen Formularen im Lightning-Anwendungsgenerator, Bildschirm-Flows in Flow Builder und OmniScripts in OmniStudio) bis hin zu Pro-Code (mit dem LWC-Framework) mit einer Kombination aus Bildschirm-Flows oder OmniScripts und LWC in der Mitte. Beachten Sie diese Anleitung und verwenden Sie sie als Referenz, wenn Sie Formulare in Salesforce erstellen oder neu entwerfen möchten. Wenn Sie nach Anleitungen zum Entwerfen optimierter und hilfreicher Formulare suchen, lesen Sie [Salesforce Well-Architected: Engagierend](/docs/architect/de-de/well-architected/guide/engaging).

### Teilen Sie uns Ihre Meinung mit

Helfen Sie uns, sicherzustellen, dass wir das veröffentlichen, was für Sie am relevantesten ist: [Nehmen Sie an unserer Umfrage](https://forms.gle/FCFCES6vsRbKv4E29) teil, um Feedback zu diesen Inhalten zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten.

<!-- document id=0ca99476f7b266010e21ec98671031d5da96b70a6af7bf0ecdd816c3b218594d url=/architect/next/de-de/decision-guides/guides/step-based-async-framework.md -->

## Übersicht

Moderne Salesforce-Architekturen werden zunehmend durch asynchrone Verarbeitung unterstützt, nicht als Komfort, sondern als strategische Skalierungsanforderung. In den letzten Jahren haben wir immer mehr Unternehmen erlebt, die mit steigenden Datenvolumen, komplexen Integrationen mit mehreren Kontaktpunkten und der Zunahme autonomer Systeme rund um die Uhr zu kämpfen haben. All dies drängt Architekten dazu, asynchrone Systeme zu entwickeln.

Bei der asynchronen Verarbeitung in Salesforce müssen Sie oft Obergrenzen und Komplexität berücksichtigen. Diese Obergrenzen dienen als Leitplanken und architektonische Einschränkungen, die bei der Herstellung massensicherer, skalierbarer Systeme helfen. Auch wenn keine Plattformobergrenzen direkt zur Verwaltung der Komplexität dienen, können [Designmuster](https://refactoring.guru/design-patterns) dazu beitragen, Risiken in dieser Hinsicht zu minimieren. Intern überschreitet Salesforce oft die Grenzen der Plattform, um neue Funktionen zu testen und komplexe Geschäftsprozesse zu automatisieren. Es wurde ein Framework für die schrittbasierte asynchrone Verarbeitung entwickelt, um asynchrone Aufträge mit einer beliebigen Anzahl von Schritten auszuführen. Jeder Schritt kann unabhängig voneinander ausgeführt, wiederholt und neu gestartet werden. Dazu gehören freigegebene Steuerungen und vollständige betriebliche Transparenz durch die zentralisierte Protokollierung. In diesem Dokument werden die wichtigsten architektonischen Komponenten beschrieben: Warteschlangenfähiger Apex und Finalizer, geplanter Flow, Apex Cursors, aufrufbare Aktionen und Integrationen in Slack. Zusammen bieten diese Komponenten eine modulare, skalierbare und beobachtbare Architektur, die sich an sich ändernde Unternehmensanforderungen anpasst.

## Wichtige Takeaways

- Moderne Salesforce-Architekturen sollten einen asynchronen Ansatz verfolgen, um Skalierbarkeit, Widerstandsfähigkeit und betriebliche Transparenz zu erreichen.
- Die Aufteilung komplexer Arbeiten in unabhängig ausführbare Schritte ermöglicht eine vorhersehbare Leistung, sichere Wiederholungen, Prüfpunkte, Rollback und modulare Weiterentwicklung, ohne die Kern-Workflows neu zu entwickeln.
- Das Framework bietet eine skalierbare Alternative zu monolithischen und alternden Batchaufträgen, verketteten asynchronen Aufrufen und tief verschachtelten Flows und wurde für Arbeitslasten mit hohem Volumen entwickelt, die horizontal innerhalb von Salesforce ohne Orchestrierung außerhalb der Plattform skaliert werden müssen.
- Die deterministische und beobachtbare Ausführung gewährleistet Fortschrittsverfolgung, SLA-Überwachung, Fehlerdiagnose und Transparenz auf Überwachungsebene durch zentralisierte Protokollierung und Governance.
- Konzipiert für die Strenge von Unternehmen, einschließlich einheitlicher Governance, Compliance und verteilter Kontrolle über den Bundesstaat in langfristigen Geschäftsprozessen.

## Bewährte Vorgehensweisen für die Plattform

Bevor Sie die Anforderungen überprüfen, finden Sie hier einige Tipps und Tricks für die Verwendung eines solchen Frameworks. Überlegen Sie vor allem, welches System die einzige Quelle der Wahrheit ist. Wenn Ihre Salesforce-Organisation nur minimal von externen Daten abhängig ist, jedoch von Hunderten auf Millionen Datensätze skaliert werden muss, sollten Sie ein schrittbasiertes asynchrones Framework in Betracht ziehen.

Verwenden Sie dieses Framework**,** wenn:

- Die meisten (oder alle) Informationen, auf die reagiert werden soll, sind bereits in Ihrem CRM vorhanden.
- Die Kosten für die Wartung eines Auftrags vom Typ "Extract Transform Load (ETL)" zur Harmonisierung externer Daten sind zu hoch.
- Sie müssen die Verarbeitung einer großen Anzahl von Salesforce-Datensätzen nach einem festgelegten Zeitplan zurückstellen.
- Sie können die Verarbeitung in separate Schritte unterteilen. Beispielsweise können Sie einen hierarchischen oder strukturbasierten Satz von Datensätzen erstellen, insbesondere wenn das Datenvolumen in der Hierarchie oder Struktur aufgefächert wird.

Verwenden Sie dieses Framework **nicht** in folgenden Fällen:

- Für das Erstellen oder Aktualisieren von Datensätzen ist eine sofortige Neuberechnung erforderlich.
- Die Integration ist schwierig, da externe Systeme Primärdaten für Datensatzaktualisierungen hosten. (Überlegen Sie, ob aktualisierte Daten mit der Bulk-API an Salesforce übertragen werden sollen.)

Unter Berücksichtigung dieser Vorgehensweisen sollten wir unsere Anforderungen überprüfen und mit der Erstellung beginnen.

## Aufschlüsseln der Anforderungen

Beachten Sie die Problemanweisung:

> Überprüfen Sie bei einem Auftrag, der täglich ausgeführt werden muss, ob bestimmte Datensätze vorab festgelegte Kriterien für die weitere Verarbeitung erfüllen. Falls ja, starten Sie die Verarbeitungsaufträge. Die Verarbeitung von Datensätzen kann bedeuten, dass Daten aus mehreren externen Systemen abgerufen werden, um Berechnungen durchzuführen. Schritte in Aufträgen sollten Personen über Slack benachrichtigen, dass verarbeitete Datensätze zur Überprüfung bereit sind. Die Schritte sollten auch Benachrichtigungen an Manager und übergeordnete Positionen in der Rollenhierarchie basierend auf einer konfigurierbaren Verzögerung nach der ersten Benachrichtigungsrunde eskalieren.

Dieses Problem umfasst mehrere verschiedene Schritte, von denen einige unabhängig voneinander ablaufen können. Es gibt viele Möglichkeiten, die Arbeit aufzuteilen. Hier eine Gruppierung:

- Der Planer.
- Die Schrittoberfläche und konkrete Implementierungen, die Datensätze verarbeiten (unabhängig vom Verarbeitungstyp).
- Der Prozessor, der Schritte organisiert.
- Die vom Planer aufgerufene Apex Invocable.
- Der Benachrichtigungsteil. Wir verwenden das [Apex Slack SDK](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html).
  - Im Ausdruck "konfigurierbare Verzögerung" verbirgt sich etwas Komplexität. Diese Komplexität wird später in diesem Artikel beschrieben.

Im Folgenden finden Sie ein Diagramm mit Meinungsäußerungen für das integrierte Framework:

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/step-based-async-framework/step-processor.png" alt="Architekturdiagramm mit Flow-Planung, asynchroner Apex-Verarbeitung und verschiedenen möglichen Schrittimplementierungen" />
Nun schlüsseln Sie das Diagramm auf und erstellen Sie die Teile.

## Planung mit geplantem Flow

Der geplante Flow bietet als Planungsmechanismus mehrere Vorteile:

- Geplante Flows können als Metadaten in Pakete aufgenommen und bereitgestellt werden. Dies gilt nicht für Aufträge, die über Apex (oder über die Seite "Geplante Aufträge") geplant werden.
- Das Warteelement ist wichtig für Frameworks, die Callouts erfordern. Durch die Verwendung in Flow sind Callouts im Teil "Aufrufbar" des Frameworks nicht erforderlich.
- Die Planungsgranularität erfüllt die Anforderungen: Das Mindestintervall für geplante Flows beträgt täglich. Wenn Sie eine höhere Häufigkeit benötigen (z. B. stündlich), sollten Sie den geplanten Flow für diese Anforderung überdenken.

Eine weitere Überlegung beim Konfigurieren des geplanten Flows ist das Umgebungs-Gating. Fügen Sie vor dem Aufrufen der Apex-Aktion ein Entscheidungselement hinzu, das die `{!$Api.Enterprise_Server_URL_100}` auswertet. Dadurch wird sichergestellt, dass der Auftrag nur in den vorgesehenen Umgebungen ausgeführt wird, z. B. in UAT und Production. Dieses Muster ist wichtig, da Sandbox-Instanzen während des SDLC häufig aktualisiert oder neu erstellt werden und ein geplanter Flow ohne explizite Umgebungsprüfung versehentlich in Umgebungen ausgeführt werden könnte, in denen das Framework nicht ausgeführt werden soll. Durch die Verwendung des `contains`-Operators im Entscheidungselement wird das Setup widerstandsfähig gegen künftige Sandbox-Erstellungen oder URL-Änderungen.

Überlegen Sie abschließend, wie das Framework Fehler erfassen soll. Fügen Sie immer einen Fehlerpfad hinzu, wenn Flow eine beliebige Aktion aufruft. Beispielsweise können Sie Fehler mit [der](https://www.nebulalogger.com/) Aktion "Protokolleintrag hinzufügen" verdrahten. Der Nebelprotokollierer schreibt Protokolle in benutzerdefinierte Objekte. Daher sollten sich Kunden bewusst sein, dass Protokolldaten den Speicherplatz in der Organisation belegen. Protokolle werden standardmäßig 14 Tage in einer Organisation gespeichert und dann bereinigt. Dieser Aufbewahrungszeitraum kann konfiguriert werden. Der Nebelprotokollierer verwendet auch Plattformereignisse zum Veröffentlichen von Protokollen, sodass Protokolleinträge unabhängig von der Hauptdatenverarbeitungstransaktion gespeichert werden. Auf diese Weise wird sichergestellt, dass Fehler auch dann erfasst werden, wenn die primäre Flow- oder Apex-Aktion zurückgesetzt wird. Kunden sollten das erwartete Protokollvolumen und die Aufbewahrungsanforderungen auswerten, wenn sie das Hinzufügen eines Protokollierungs-Frameworks in Erwägung ziehen.

So sieht der Flow aus:

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/step-based-async-framework/scheduled-flow.png" alt="Der geplante Flow, der ein Entscheidungselement zum Ausführen oder Nichtausführen, ein Pausenelement zum Zulassen von Callouts und die zusammen mit dem Fehlerpfad &quot;Nebelprotokollierer&quot; aufgerufene Apex Invocable-Aktion enthält" />

Gehen wir nun zu den ersten Teilen des Apex Codes über, wobei die Planungsanforderung nun erfüllt ist.

## Erstellen einer Schrittoberfläche

Definieren einer `Step`:

```java
 public interface Step {
  void execute();
  void finalize();
  String getName();
  Boolean shouldRestart();
}
```

In diesem Artikel wird die `step` der Übersichtlichkeit halber als äußere Klasse angezeigt. Das Framework selbst ist flexibel. Teams können die Oberfläche und ihre Implementierungen mithilfe eines beliebigen Apex-Paketerstellungsmusters organisieren, sofern alle Schrittklassen auf dieselbe Oberfläche verweisen.

Zu den auf unserer Oberfläche definierten Methoden gibt es einige Hinweise:

- Die `execute` wird verbessert, wenn eine `State` (oder Schnittstelle) übergeben wird, um Daten zwischen Schritten zu orchestrieren, wenn es auf die Reihenfolge ankommt.
- `getName` kann anstelle eines `String` einen `System.Type` zurückgeben. Ziel ist es, der Orchestrierungsebene eine Möglichkeit zu geben, Schrittnamen zu protokollieren, ohne andere Eigenschaften offenzulegen.

Im Folgenden finden Sie die erste konkrete Implementierung, die zeigt, wie diese Teile zusammenpassen. Mit einer Ausnahme später wird empfohlen, warteschlangenfähigen Apex zu verwenden, um eine asynchrone Verarbeitung in Apex zu implementieren; Batch Apex ist in der Regel nicht erforderlich (und `@future` werden abgeraten). Warteschlangenfähiger Apex startet schnell und bietet mit Apex Cursors viele Vorteile gegenüber Batch Apex.

### Eine Apex Cursor-ähnliche Implementierung

[Apex Cursors](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cursors.htm) bieten eine moderne Alternative zum herkömmlichen Batch Apex Modell. Ähnlich wie bei der Batch-Verarbeitung kann eine Cursor-Implementierung Datensätze in Blöcken abrufen (bis zu 2.000 pro Batch). Cursors ermöglichen jedoch mehrere Abrufe innerhalb einer einzelnen Transaktion und ermöglichen so einen deutlich höheren Durchsatz für Vorgänge mit großem Volumen.

Wenn Teams Cursors als Teil dieses Frameworks übernehmen, sollten sie die aktuellen Einschränkungen bei Tests und der Mockability beachten. Das Cursorverhalten in Tests kann sich vom Produktionsverhalten unterscheiden. Daher ist es wichtig, Teststrategien zu entwerfen, die vermeiden, dass sich Cursorinterna auf sie verlassen, und stattdessen die Orchestrierungslogik an den Grenzen zu validieren. Im Zuge der Weiterentwicklung der Plattform werden sich diese Bereiche weiter verbessern, die zentrale Anleitung bleibt jedoch: Cursors bieten im Vergleich zu Batch Apex in vielen Anwendungsfällen eine höhere Leistung und einen geringeren Orchestrierungsaufwand.

Wenn Sie eine klare Grenze zwischen dem vom System bereitgestellten Cursor und Ihrem eigenen Code definieren möchten, sollten Sie beim Implementieren der `Step` eine Cursor-ähnliche Darstellung erstellen. Beachten Sie diesen Code:

```java
public inherited sharing abstract class CursorStep implements Step {
  private static final Integer MAX_CHUNK_SIZE = 2000;

  protected Cursor cursor;

  private Integer chunkSize = System.Limits.getLimitDMLRows();
  private Integer position = 0;

  protected abstract Cursor getCursor();
  protected abstract void innerExecute(List<SObject> records);

  public abstract String getName();

  public virtual CursorStep withChunkSize(Integer chunkSize) {
    this.chunkSize = chunkSize;
    return this;
  }

  public void execute() {
    this.cursor = this.cursor ?? this.getCursor();
    this.cursor.setFetchesPerTransaction(this.getFetchesPerTransaction());
    List<SObject> records = new List<SObject>();
    if (this.shouldAdvance()) {
      records = this.cursor.fetch(this.position, this.chunkSize);
      this.position += this.chunkSize;
    }
    this.innerExecute(records);
  }

  public virtual void finalize() {
    Logger.info('finished cursor step for ' + this.getName());
  }

  public virtual Boolean shouldRestart() {
    return this.position < this.cursor.getNumRecords();
  }

  protected virtual Integer getFetchesPerTransaction() {
    Integer maxRecordsPerFetchCall = 2000;
    if (this.chunkSize < maxRecordsPerFetchCall) {
      return this.chunkSize;
    }
    // Integer division rounds down
    // which is perfect for our use-case
    return this.chunkSize / maxRecordsPerFetchCall;
  }

  protected virtual Boolean shouldAdvance() {
    return true;
  }
}
```

Beachten Sie die `Cursor`-Klasse. Apex-Cursors sind `Database.Cursor`, aber unsere `Cursor`-Implementierung bietet uns Flexibilität hinsichtlich der Mängel von Cursors. Folgende Implementierung:

```java
public virtual without sharing class Cursor {
  private static final Integer MAX_FETCHES_PER_TRANSACTION = Limits.getLimitFetchCallsOnApexCursor();

  @TestVisible
  private static Integer maxRecordsPerFetchCall = 2000;

  private Integer cursorNumRecords;
  private Integer fetchesPerTransaction = MAX_FETCHES_PER_TRANSACTION;
  private final Database.Cursor cursor;

  public Cursor(
    String finalQuery,
    Map<String, Object> bindVars,
    System.AccessLevel accessLevel
  ) {
    try {
      this.cursor = Database.getCursorWithBinds(finalQuery, bindVars, accessLevel);
    } catch (FatalCursorException e) {
      Logger.newEntry(
        System.LoggingLevel.WARN,
        'Error creating cursor. This can happen if there' +
          ' are no records returned by the query: ' + e.getMessage()
      );
    }
  }

  public Cursor setFetchesPerTransaction(Integer possibleFetchesPerTransaction) {
    // Handle accidental round downs from Integer division
    if (possibleFetchesPerTransaction == 0) {
      return this;
    }
    if (possibleFetchesPerTransaction > MAX_FETCHES_PER_TRANSACTION) {
      Logger.newEntry(
        System.LoggingLevel.DEBUG,
        'Fetches per transaction: ' +
          possibleFetchesPerTransaction +
          ' exceeded platform max fetches per transaction: ' +
          MAX_FETCHES_PER_TRANSACTION +
          ', defaulting to platform max'
      );
      possibleFetchesPerTransaction = MAX_FETCHES_PER_TRANSACTION;
    }
    this.fetchesPerTransaction = possibleFetchesPerTransaction;
    return this;
  }

  @SuppressWarnings('PMD.EmptyStatementBlock')
  protected Cursor() {
  }

  public virtual List<SObject> fetch(Integer start, Integer advanceBy) {
    if (this.getNumRecords() == 0) {
      Logger.newEntry(
        System.LoggingLevel.DEBUG,
        'Bypassing fetch call, no records to fetch'
      );
      return new List<SObject>();
    }
    Integer localStart = start;
    List<SObject> results = new List<SObject>();
    while (
      Limits.getFetchCallsOnApexCursor() < this.fetchesPerTransaction &&
      results.size() < this.getNumRecords() &&
      localStart < start + advanceBy
    ) {
      Integer actualAdvanceBy = this.getAdvanceBy(localStart, advanceBy);
      results.addAll(this.cursor?.fetch(localStart, actualAdvanceBy) ?? new List<SObject>());
      localStart += actualAdvanceBy;
    }
    return results;
  }

  public virtual Integer getNumRecords() {
    this.cursorNumRecords = this.cursorNumRecords ?? this.cursor?.getNumRecords() ?? 0;
    return this.cursorNumRecords;
  }

  protected Integer getAdvanceBy(Integer start, Integer advanceBy) {
    Integer possibleFetchSize = Math.min(advanceBy, this.getNumRecords() - start);
    if (possibleFetchSize > maxRecordsPerFetchCall) {
      Logger.newEntry(
        System.LoggingLevel.DEBUG,
        'Fetch size: ' +
          possibleFetchSize +
          ' exceeded platform max fetch size of ' +
          maxRecordsPerFetchCall +
          ', defaulting to max fetch size'
      );
      possibleFetchSize = maxRecordsPerFetchCall;
    } else if (possibleFetchSize < 0) {
      possibleFetchSize = 0;
    }
    return possibleFetchSize;
  }
}
```

Für den Rest dieses Artikels werden die `sharing`-Deklarationen beim Verweis auf Apex-Klassen weggelassen. Stellen Sie in der Praxis sicher, dass Klassen der obersten Ebene explizit mit oder ohne Freigabe verwendet werden, um Ihrem Objektmodell und Ihren Berechtigungen gerecht zu werden.

Beachten Sie auch, dass unsere `Cursor`-Implementierung an die Plattform-`Database.Cursor` delegiert wird, wobei die zusätzlichen Vorteile als Nächstes diskutiert werden.

Zunächst die entsprechenden Tests:

```java
@IsTest
private class CursorTest {
  @IsTest
  static void itCapsAdvanceByArgument() {
    String accountName = 'helloWorld!';
    insert new Account(Name = accountName);
    String query = 'SELECT Name FROM Account WHERE Name = :bindVar0';
    Map<String, Object> bindVars = new Map<String, Object>{ 'bindVar0' => accountName };

    Cursor instance = new Cursor(query, bindVars, System.AccessLevel.SYSTEM_MODE);

    Assert.areEqual(1, instance.getNumRecords());
    Assert.areEqual(accountName, instance.fetch(0, 1000).get(0).get('Name'));
    Assert.areEqual(1, System.Limits.getApexCursorRows());
  }

  @IsTest
  static void itCapsMaxRecordsPerFetchCall() {
    Cursor.maxRecordsPerFetchCall = 20;
    Integer oneMoreThanMaxFetch = Cursor.maxRecordsPerFetchCall + 1;

    List<Account> accounts = new List<Account>();
    for (Integer i = 0; i < oneMoreThanMaxFetch; i++) {
      accounts.add(new Account(Name = 'Fetch ' + i));
    }
    insert accounts;

    Exception ex;
    List<SObject> results;
    Cursor instance = new Cursor(
      'SELECT Id FROM Account',
      new Map<String, Object>(),
      System.AccessLevel.SYSTEM_MODE
    );
    try {
      results = instance.fetch(0, oneMoreThanMaxFetch);
    } catch (System.InvalidParameterValueException e) {
      ex = e;
    }

    Assert.areEqual(null, ex?.getMessage());
    Assert.areEqual(2, Limits.getFetchCallsOnApexCursor());
    Assert.areEqual(oneMoreThanMaxFetch, results.size());
  }

  @IsTest
  static void itFetchesMultipleTimesPerTransactionWhenMoreThanMaxFetch() {
    Cursor.maxRecordsPerFetchCall = 20;
    List<Account> accounts = new List<Account>();
    Set<String> expectedFetchNames = new Set<String>();
    for (Integer i = 0; i < Cursor.maxRecordsPerFetchCall + 1; i++) {
      String accountName = 'Fetch' + i;
      expectedFetchNames.add(accountName);
      accounts.add(new Account(Name = accountName));
    }
    insert accounts;

    Integer oneMoreThanMaxFetch = Cursor.maxRecordsPerFetchCall + 1;
    Cursor instance = new Cursor(
      'SELECT Name FROM Account',
      new Map<String, Object>(),
      System.AccessLevel.SYSTEM_MODE
    );
    List<SObject> results = instance.setFetchesPerTransaction(2).fetch(0, oneMoreThanMaxFetch);

    Assert.areEqual(Cursor.maxRecordsPerFetchCall + 1, results.size());
    Assert.areEqual(2, Limits.getFetchCallsOnApexCursor());
    Set<String> actuallyFetchedNames = new Set<String>();
    for (Account account : (List<Account>) results) {
      actuallyFetchedNames.add(account.Name);
    }
    Assert.areEqual(expectedFetchNames, actuallyFetchedNames);
  }

  @IsTest
  static void itFetchesMultipleTimesPerTransaction() {
    Cursor.maxRecordsPerFetchCall = 1;
    insert new List<Account>{ new Account(Name = 'One'), new Account(Name = 'Two') };

    Cursor instance = new Cursor(
      'SELECT Id FROM Account',
      new Map<String, Object>(),
      System.AccessLevel.SYSTEM_MODE
    )
      .setFetchesPerTransaction(2);
    List<SObject> results = instance.fetch(0, 2);

    Assert.areEqual(2, instance.getNumRecords());
    Assert.areEqual(2, results.size());
    results = instance.fetch(2, 1);
    Assert.areEqual(0, results.size());
  }

  @IsTest
  static void fetchesCorrectAmountOfRecords() {
    List<Account> accounts = new List<Account>();
    for (Integer i = 0; i < 10; i++) {
      accounts.add(new Account(Name = 'Fetch ' + i));
    }
    insert accounts;

    Cursor instance = new Cursor(
      'SELECT Id FROM Account',
      new Map<String, Object>(),
      System.AccessLevel.SYSTEM_MODE
    )
      .setFetchesPerTransaction(10);
    List<SObject> results = instance.fetch(0, 2);

    Assert.areEqual(2, results.size(), '' + results);
    Assert.areEqual(1, Limits.getFetchCallsOnApexCursor());
  }

  @IsTest
  static void doesNotExceedPlatformMaxFetch() {
    List<Account> accounts = new List<Account>();
    for (Integer i = 0; i < 101; i++) {
      accounts.add(new Account(Name = 'Fetch ' + i));
    }
    insert accounts;

    Test.startTest();
    Cursor instance = new Cursor(
        'SELECT Id FROM Account',
        new Map<String, Object>(),
        System.AccessLevel.SYSTEM_MODE
      )
      .setFetchesPerTransaction(100);
    Integer counter = 0;
    List<SObject> results;
    while (counter <= 100) {
      results = instance.fetch(counter, counter + 1);
      counter++;
    }
    Test.stopTest();

    Assert.areEqual(101, counter);
    Assert.areEqual(0, results.size());
  }
}
```

Indem `Cursor` virtuell wird, können konkrete `CursorStep`-Implementierungen ohne `Database.Cursor` ausgeführt werden, wenn sie keinen großen Datensatz wiederholen müssen – ähnlich wie die Rückgabe eines `System.Iterable<T>` anstelle eines `Database.QueryLocator` in Batch Apex. Hier ein Beispiel:

```java
public abstract class CursorLikeImplementation extends CursorStep {
  private final Cursor cursorLike;

  public CursorLikeImplementation(List<SObject> previouslyRetrievedRecords) {
    this.cursorLike = new CursorLike(previouslyRetrievedRecords);
  }

  public override String getName() {
    return CursorLikeImplementation.class.getName();
  }

  public override Cursor getCursor() {
    return this.cursorLike;
  }

  private class CursorLike extends Cursor {
    private final List<SObject> records;

    public CursorLike(List<SObject> records) {
      super();
      this.records = records;
    }

    public override List<SObject> fetch(Integer position, Integer chunkSize) {
      // clone, to keep the underlying list type
      List<SObject> clonedRecords = this.records.clone();
      clonedRecords.clear();
      for (Integer i = position; i < this.getAdvanceBy(position, chunkSize); i++) {
        clonedRecords.add(this.records[i]);
      }
      return clonedRecords;
    }

    public override Integer getNumRecords() {
      return this.records.size();
    }
  }
}
```

Beachten Sie, dass diese Klasse ebenfalls abstrakt ist und die konkrete Implementierung von `innerExecute` Unterklassen überlässt.

Es gibt auch eine Alternative zur inneren Unterklasse `CursorLike`. Wenn Sie wissen, dass konkrete Versionen eines solchen Schritts andere Obergrenzen nicht überschreiten, können Sie `this.records` aus `CursorLike.fetch` zurückgeben und die übergeordnete `CursorStep.shouldRestart()` überschreiben, um false zurückzugeben. Dadurch können Sie eine Liste durchlaufen, die nur durch die Apex Heap-Obergrenze von 12 MB pro asynchroner Transaktion begrenzt ist.

### Weitere mögliche schrittweise Implementierungen

Unsere Cursor-basierte Implementierung bietet uns viel Flexibilität beim Paginieren großer Datenmengen. Die `Step` bietet uns die Flexibilität, Schritte aller Art zu beschreiben und zu kapseln.

Betrachten Sie einen Flow-basierten Schritt:

```java
public virtual class FlowStep implements Step {
  private final Invocable.Action specificFlow;

  private Boolean shouldRestart = false;

  public FlowStep(String specificFlowName, Map<String, Object> inputs) {
    this.specificFlow = Invocable.Action.createCustomAction('flow', specificFlowName);
    this.specificFlow.setInvocations(new List<Map<String,Object>>{ inputs });
  }

  public void execute() {
    List<Invocable.Action.Result> results = this.specificFlow.invoke();
    for (Invocable.Action.Result result : results) {
      if (result.isSuccess()) {
        Map<String, Object> outputParams = result.getOutputParameters();
        Object potentialShouldRestartValue = outputParams.get('shouldRestart');
        // Flow does not enforce Booleans being initialized
        //  so a null check is sadly necessary here
        if (potentialShouldRestartValue != null) {
          this.shouldRestart = this.shouldRestart ||
           Boolean.valueOf(potentialShouldRestartValue);
        }
      } else {
        List<String> errorMessages = new List<String>();
        for (Invocable.Action.Error error : result.getErrors()) {
          errorMessages.add(
            'Error code: ' + error.getCode() +
            ', error message: ' + error.getMessage()
          );
        }
        Logger.error(
          'An error occurred within your auto-launched flow:\n' +
            String.join(errorMessages, '\n\t')
        );
      }
    }
  }

  public virtual void finalize() {
    Logger.info(this.getName() + ' finished processing');
  }

  public String getName() {
    return FlowStep.class.getName() + ':' + this.specificFlow.getName();
  }

  public Boolean shouldRestart() {
    return this.shouldRestart;
  }
}
```

Da Flows keine Ausgabeparameter zurückgeben können, die einem Apex-definierten Typ entsprechen, wird vor der Verwendung nach einem `shouldRestart`-Ausgabeparameter gesucht.

Einige Schritte sind möglicherweise funktionsgekennzeichnet. Sie können Logik implementieren, um zu entscheiden, welche Schritte einbezogen werden sollen, oder einen No-op-Schritt für eine deaktivierte Funktion verwenden. Das [Muster "Null Object](https://refactoring.guru/introduce-null-object)" ist eine gängige Möglichkeit, die Komplexität innerhalb der Orchestrierungsebene zu reduzieren:

```java
@SuppressWarnings('PMD.EmptyStatementBlock')
public class NoOpStep implements Step {
  // The null object pattern is commonly implemented
  // as a singleton to reduce memory consumption
  public static final NoOpStep SELF {
    get {
      SELF = SELF ?? new NoOpStep();
    }
    private set;
  }

  public void execute() {
  }

  public void finalize() {
  }

  String getName() {
    return NoOpStep.class.getName();
  }

  Boolean shouldRestart() {
    return false;
  }
}
```

Es gibt nun einige Bausteine, mit denen wir arbeiten müssen. Sehen wir uns die Orchestrierungsebene an, die für das Durchlaufen von Schritten verantwortlich ist.

## Erstellen eines Schrittprozessors

Der Prozessor ist ein Wendepunkt in der Architektur. Wir müssen entscheiden, wer definiert, welche Schritte initialisiert werden und wo. Zu den Optionen zählen:

- Lassen Sie den Prozessor definieren, welche Schritte der Geschäftslogik zugeordnet werden. Diese Option ist einfach, wird jedoch zur besseren Lesbarkeit schlecht skaliert.
- Definieren Sie die Zuordnung mit benutzerdefinierten Metadaten (Custom Metadata, CMDT). Metadatenbeziehungsfelder unterstützen keine `ApexClass`, wodurch die Klassennamenschreibweise locker in Ihr Geschäftsprozess-Setup integriert wird. Sie können das Administratorrisiko reduzieren, indem Sie das Feld als Auswahlliste festlegen und den vorhandenen Typ validieren (`Type.forName()` oder `ApexClass` abfragen). Da CMDT-Datensätze jedoch keine Auslöser unterstützen, erfolgt die Validierung zur Laufzeit. Diese Route kann getestet werden. Administratoren können jedoch weiterhin nur CMDT-Datensätze in der Produktion erstellen.
- Definieren Sie die Zuordnung mit Datensätzen. Nicht-Administratoren können Schritte konfigurieren, Bereitstellungen werden jedoch schwieriger und Umgebungen können abweichen. Gehen Sie mit Bedacht vor.

Es gibt ein berühmtes Zitat aus [Clean Code](https://www.oreilly.com/library/view/clean-code-a/9780136083238/) über die Handhabung dieser besonderen Komplexität:

> Die Lösung dieses Problems besteht darin, die `switch`-Anweisung [zum Erstellen von Objekten] im Keller einer abstrakten Fabrik zu vergraben und sie niemals jemandem anzeigen zu lassen.

In diesem Sinne und da unsere aktuelle Anzahl an Schritten genau definiert ist und nicht zu groß wird, ist es in Ordnung, dass der Schrittprozessor auch die Fabrik für Schritte ist. Dadurch kann eine Enumeration zum Steuern der switch-Anweisung verwendet werden:

```java
public enum StepType {
   TYPE_ONE,
   TYPE_TWO,
   TYPE_THREE,
   TYPE_FOUR
   // etc ...
}
```

Und dann für unsere `StepProcessor`:

```java
public StepProcessor implements System.Queueable, System.Finalizer,
 Database.AllowsCallouts {
  private final List<Step> steps = new List<Step>();

  private Step currentStep;

  public StepProcessor setSteps(List<StepType> stepTypes) {
    for (StepType type : stepTypes) {
      switch on type {
        WHEN TYPE_ONE {
          this.addTypeOneSteps();
        }
        WHEN TYPE_TWO {
          this.addTypeTwoSteps();
        }
        // ... etc
      }
    }
    this.cleanSteps();
    return this;
  }

  public void execute(System.QueueableContext context) {
    this.currentStep = this.currentStep ?? this.steps.remove(0);
    if (context != null) {
      System.attachFinalizer(this);
      Logger.setAsyncContext(context);
    }
    Logger.info('Executing step ' + this.currentStep.getName());
    try {
      this.currentStep.execute();
    } catch (Exception e) {
      Logger.exception('Unexpected exception', e);
    }
    Logger.info('Finished executing step ' + this.currentStep.getName());
    Logger.saveLog();
  }

  public void execute(System.FinalizerContext context) {
    Logger.info('Executing finalizer for step ' + this.currentStep.getName());
    Logger.setAsyncContext(context);
    switch on context?.getResult() {
      when UNHANDLED_EXCEPTION {
        // see the note below about this logging paradigm
        Logger.warn(
          'Failed to run on step' + this.currentStep,
          context?.getException()
        );
      }
      when else {
        this.currentStep.finalize();
        if (this.currentStep.shouldRestart()) {
          this.kickoff();
        } else if (this.steps.isEmpty() == false) {
          this.currentStep = this.steps.remove(0);
          this.kickoff();
        } else {
          Logger.info('Finished executing steps');
        }
      }
    }
    Logger.info(
      'Finished executing finalizer for step ' +
        this.currentStep.getName()
    );
    Logger.saveLog();
  }

  public String kickoff() {
    return this.steps.isEmpty() ? null : System.enqueueJob(this);
  }

  private void cleanSteps() {
    for (Integer reverseIndex = this.steps.size() - 1;
      reverseIndex >= 0; reverseIndex--) {
      if (this.steps[reverseIndex] instanceof NoOpStep) {
        this.steps.remove(reverseIndex);
      }
    }
  }

  private void addTypeOneSteps() {
    this.steps.addAll(
      new List<Step> {
        new ExampleCursorStepOne(),
        new ExampleCursorStepTwo()
      }
    );
  }

  private void addTypeTwoSteps() {
    this.steps.addAll(
      new List<Step> {
        new FlowStep('
          ExampleInvocableName',
          new Map<String, Object>( 'exampleParameter' => true)
        ),
        new ExampleCursorStepThree()
      }
    );
  }
}
```

Die angezeigten Werksmethoden können wie `addTypeOneSteps()` Bedenken wie die Kennzeichnung von Funktionen delegieren. `cleanSteps()` führt eine einmalige Überprüfung der erfassten Schritte durch, um sicherzustellen, dass keine "leeren" Schritte vorhanden sind, bevor es wirklich asynchron wird. Das könnte wie folgt aussehen:

```java
private Step getStepOrDefault(String customPermissionName, Step defaultStep) {
  if (System.FeatureManagement.checkPermission(customPermissionName)) {
    return defaultStep;
  }

  return NoOpStep.SELF;
}
```

Die Fehlerbehandlung wurde seit der Erwähnung des Nebelprotokollierers im Abschnitt "Geplanter Flow" nicht mehr diskutiert. Das liegt daran, dass wir mit `System.Finalizer` die Protokollierung für alle Fehlerbedingungen abdecken können, ohne in jedem Schritt eine spezifische Fehlerbehandlung hinzuzufügen. Jeder `Step` konzentriert sich auf die Ausführung, während alle unzufriedenen Pfade protokolliert und neu geworfen werden, damit sie in Einheitentests angezeigt werden. Dies unterstützt die sichere Iteration und Warnungen auf Produktionsebene (mit dem [Slack Logger-Plugin für Nebula](https://github.com/jongpie/NebulaLogger/tree/main/nebula-logger/plugins/slack) für alle WARN- und ERROR-Protokolle).

Hinweis zur Fehlerprotokollierung: Die Übergabe der Schrittinstanz an Protokollmeldungen setzt ein Maß an Trust voraus, was in Protokollen sichtbar wird. Die Standard-`toString()` für Apex-Klassen enthält alle statischen und instanzspezifischen Eigenschaften in der Meldung. Dies kann wünschenswert sein oder vertrauliche Informationen preisgeben. Auch wenn Protokollierung und Sicherheit hier nicht im Mittelpunkt stehen, sollten Sie beachten, dass die Einhaltung einer Schnittstelle wie `Step` bei einigen Systemen auch das Erzwingen einer Überschreibung für `toString()` beinhalten kann.

```java
 public interface Step {
  void execute();
  void finalize();
  String getName();
  Boolean shouldRestart();
  String toString();
}
```

Bei einer solchen Methode müssen die einzelnen Objektersteller entscheiden, was gedruckt werden darf, was wünschenswert sein kann.

Auf Protokollierungsebenen: Auf `StepProcessor` wird `INFO` verwendet, die höchste Nicht-Fehler-Ebene. Wenn Sie in der Anwendung genauer werden, sollten die Protokollierungsebenen entsprechend reduziert werden. Bei einzelnen Schritten werden möglicherweise `DEBUG` für allgemeine Informationen verwendet, wobei `FINE`, `FINER` und `FINEST` für eine immer detailliertere Ausgabe reserviert sind. Protokollierung ist ebenso eine Kunst wie eine Wissenschaft, aber diese Prinzipien zu befolgen, hilft, Protokolle konsistent und nützlich zu halten.

### Umgang mit zusätzlicher Komplexität im Schrittprozessor

Bevor wir fortfahren, sollten wir kurz über die Entscheidung nachdenken, dass unser Schrittprozessor die Logik hosten soll, für die Schritte verwendet werden. Ziehen Sie in einer großen Codebasis in Erwägung, `StepProcessor` virtuell oder abstrakt zu gestalten, und lassen Sie Unterklassen bestimmte Schritte identifizieren, um eine ordnungsgemäße Trennung von Bedenken zu erreichen.

## Aufrufbare Apex-Ebene

Der Planer ruft schließlich Apex auf. Nach Abschluss des restlichen Setups kann der Abschnitt "Aufrufbares Apex" entscheiden, welche Schritte ausgeführt werden sollen, und die `List<StepType>` an den Prozessor übergeben:

```java
public class DailyJobExecutor {
  @InvocableMethod(label='Execute Daily Job')
  public static void executeJob() {
    Logger.info('Executing daily Job');

    List<StepType> correspondingTypes = new List<StepType>();
    // based on [business logic], determine which step types
    // should be included for any daily invocation

    if (correspondingTypes.isEmpty() == false) {
      try {
        new StepProcessor().setSteps(correspondingTypes).kickoff();
      } catch (Exception ex) {
        Logger.exception('Error starting job', ex);
      }
    }
  }

  Logger.saveLog();
}
```

Dies ist ein einfacher Teil der Gleichung: Verwenden Sie Datensätze, Daten oder Logik, um zu bestimmen, welche Schritttypen ausgeführt werden sollen. Die aufrufbare Aktion ist einfach, da die Komplexität an anderer Stelle gekapselt wurde. Wir haben uns auch vor unerwarteten Ausnahmen geschützt und jedes Stück für sich genommen einfach getestet.

## Umgang mit Verzögerungen vor dem Anruf von Slack

Das [Apex Slack-SDK](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html) liegt außerhalb des Geltungsbereichs dieses Artikels, aber ein potenzieller Haken an den Anforderungen besteht darin, Personen anhand einer konfigurierbaren Verzögerung nach oben in der Rollenhierarchie zu benachrichtigen. Auf dem Papier ist dies einfach und Sie könnten (richtig) `System.enqueueJob(this)` in der `StepProcessor` berücksichtigen. Bei [System.AsyncOptions](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_AsyncOptions.htm) bestand unsere anfängliche Neigung darin, die `enqueueJob`-Überlastung zu verwenden, um diese Anforderung zu erfüllen.

Derzeit beträgt die maximale Verzögerung über `System.AsyncOptions.MinimumQueueableDelayInMinutes` jedoch 10 Minuten. Da die Anforderung 120 Minuten beträgt, bleiben einige Optionen. Ein naiver Ansatz könnte wie folgt aussehen:

```java
public class ExampleDelayedNotifier implements Step {
  private final List<Slack.ChatPostMessageRequest> notifications = new List<Slack.ChatPostMessageRequest>();
  private final Slack.BotClient botClient = Slack.App
    .getAppByKey('some-slack-app-key')
    .getBotClientForTeam('slack team id');

  // account for the initial delay,
  // so 120 - 10 = 110
  private Integer delayMinutes = 110;

  public void execute() {
    if ( this.delayInMinutes > 0) {
      return;
    }

    Integer maximumAllowedCallouts = 100;
    while (this.notifications.isEmpty() == false && maximumAllowedCallouts > 0) {
      this.botClient.chatPostMessage(this.notifications.remove(0));
      maximumAllowedCallouts--;
    }
  }

  public void finalize() {
    this.delayInMinutes -= 10;
  }

  public String getName() {
    return ExampleDelayedNotifier.class.getName();
  }

  public Boolean shouldRestart() {
    return this.delayInMinutes > 0 || this.notifications.isEmpty() == false;
  }
}
```

In der Praxis würde die Verzögerung an diese Klasse weitergegeben, da die Verzögerung konfigurationsgesteuert ist.

Dieser Ansatz wird nur empfohlen, wenn Sie sicher sind, dass es immer nur einen verzögerten Benachrichtigungstyp gibt. Es werden 11 zusätzliche asynchrone Aufträge durchgebrannt, bevor gestartet wird (oder mehr, wenn die Verzögerung zunimmt). Diese Kosten können für einen Auftrag in Ordnung sein – nicht für viele. Außerdem müssen Sie der `Step`-Oberfläche eine Methode hinzufügen, damit der Prozessor bei jedem Schritt feststellen kann, wie lange vor dem Neustart gewartet werden muss, was zu zusätzlichen Störungen führt.

Dadurch bleiben uns zwei interessante Möglichkeiten:

- Sie können den verzögerten Schritt in Ihr vorhandenes Auftrags-Framework einfügen, wenn Sie bereits über einen in einem angemessenen Intervall geplanten Abstimmungsauftrag verfügen. Sie sollten auch damit einverstanden sein, dass die angegebene Verzögerung bis zu 15 Minuten später auftritt (15 Minuten sind das Mindestaktualisierungsintervall für einen Apex CRON-Ausdruck). Dies entspricht ungefähr dem Beispiel "Aufrufbares Apex". Die Planung erfolgt stattdessen über Apex. Anders ausgedrückt, Sie könnten dieselbe `Step` Architektur wiederverwenden, um Datensätze anhand eines Zeitstempels vom Typ "Start nach" zu verarbeiten und anhand einer Auswahlliste oder Mehrfachauswahllistenzuordnung zurück zu den zuvor angezeigten `StepType` zu entscheiden, welche Schritte verwendet werden sollen.
- Wenn Sie eine zusätzliche äußere Apex-Klasse definieren möchten, können Sie alternativ mithilfe von `System.scheduleBatch()` auf Batch Apex zurückgreifen (anders als warteschlangenfähiges Apex, das innere Klassen unterstützt, müssen Batch Apex Klassen äußere Klassen sein).

Sehen Sie sich das Beispiel für Batch Apex an. Obwohl Queueable Apex im Allgemeinen für Flexibilität und Kontrolle empfohlen wird, ist dies ein Fall, in dem Batch-Apex weiterhin die Oberhand behält:

```java
public class DelayedNotifier implements Database.Batchable<Object> {
  private final StepProcessor processor = new StepProcessor();

  public Iterable<Object> start(Database.BatchableContext bc) {
    return new List<Object>();
  }

  @SuppressWarnings('PMD.EmptyStatementBlock')
  public void execute(Database.BatchableContext bc, Object scope) {
    // we don't need to actually do anything in execute,
    //  we just need to start up the processor in finish
  }

  public void finish(Database.BatchableContext bc) {
    try {
      // you can imagine Notifier as an elided,
      // simpler version of the naive implementation
      // we showed above, now only focused on sending messages
      this.processor.setSteps(new List<Step>{ new Notifier() }).kickoff();
    } catch (Exception ex) {
      Logger.exception('Unexpected error', ex);
    } finally {
      Logger.saveLog();
    }
  }
}
```

Stellen Sie sich dann im `StepProcessor` vor, dass die zuvor angezeigte `addTypeOneSteps()` mit diesem verzögerten Schritt aktualisiert wird:

```java
public StepProcessor implements System.Queueable, System.Finalizer,
  Database.AllowsCallouts {
  // .... unchanged top of class elided

  private void addTypeOneSteps() {
    this.steps.addAll(
      new List<Step> {
        new ExampleCursorStepOne(),
        new ExampleCursorStepTwo(),
        new DelayedNotifierStep()
      }
    );
  }

  // ...

  private class DelayedNotifierStep implements Step {
    private final DelayedNotifier delayedNotifier = new DelayedNotifier();
    // again — in practice this value would also be passed in
    private final Integer delayInMinutes = 120;

    public void execute() {
      System.scheduleBatch(
        this.delayedNotifier,
        'Delayed notifier: ' + System.now().getTime(),
        this.delayInMinutes
      );
    }

    public void finalize() {
      Logger.debug('Nothing to finalize, batch scheduled');
    }

    public String getName() {
      return DelayedNotifierStep.class.getName();
    }

    public Boolean shouldRestart() {
      return false;
    }
  }
}
```

Obwohl wir normalerweise nicht so viel Hoop-Jumping empfehlen würden, wird diese Schrittverzögerung zu einem weiteren wiederverwendbaren Baustein. Bis längere Verzögerungen in Queueable Apex zulässig sind, stellt dies auch die einfachste Möglichkeit dar, diesen Effekt zu erzeugen (ohne einen Abfragemechanismus, wie diskutiert).

## Schlussfolgerung

Wir haben objektorientiertes Design verwendet, um die Anforderungen zu erfüllen, und ein System entwickelt, das skaliert und gleichzeitig die langfristigen Kosten für Gebäude und Wartung abwägt. Während die Schrittdeklaration und -instanziierung letztlich ihren Platz in der `StepProcessor` übersteigen können, gibt es hier wenig zusätzliche technische Schulden. Mit `FlowStep` können Administratoren und Entwickler gemeinsam entscheiden, wann No-Code- oder Pro-Code-Lösungen am sinnvollsten sind.

Durch die Verwendung der `System.Finalizer`-Schnittstelle im Queueable-Framework von Apex wurde zusammen mit Nebula Logger ein robustes, testbares System entwickelt, das uns auf unvorhergesehene Fehler hinweist, selbst wenn künftige Schritte keine explizite Protokollierung erfordern. Für uns ist dieses System ein glücklicher Zahlenschlag und reduziert Kosten und Komplexität. Außerdem erhalten wir wertvolle Statistiken zum Verhalten von Apex Cursors unter realen Arbeitslasten, wodurch wir unseren Ansatz optimieren und gleichzeitig die Funktion selbst verbessern können.

Indem komplexe Arbeitslasten mit hohem Volumen in modulare Ausführungsschritte zerlegt werden, wandelt das Framework für die schrittbasierte asynchrone Verarbeitung Plattformeinschränkungen in technische Vorteile um, die eine vorhersehbare Leistung, Beobachtbarkeit und Governance im Unternehmensmaßstab ermöglichen. Schritte können sowohl von Administratoren als auch von Entwicklern eingerichtet werden. In beiden Fällen können sich Schrittautoren auf die Einhaltung der grundlegenden Plattformobergrenzen (wie DML-Zeilen und abgerufene Abfragezeilen) konzentrieren, ohne sich Gedanken über die Skalierung jedes Schritts machen zu müssen.

## Pfad vorwärts

Damit dieses Muster in Unternehmensimplementierungen operationalisiert und übernommen werden kann, sollten Architekten:

- **Bewertung vorhandener Automatisierungen**, um Bereiche zu identifizieren, in denen die asynchrone Orchestrierung zur Leistungssteigerung und zur Verbesserung der Beobachtbarkeit beitragen kann.
- **Unterteilen Sie große Prozesse** in diskrete, unabhängig ausführbare Schritte mit klaren Verarbeitungszielen und diskreten Autorenpunkten (wie Flow oder Apex).
- **Definieren und gruppieren** Sie Schritttypen, um die Wiederverwendung und Standardisierung von Schritten über Geschäftseinheiten hinweg zu beschleunigen.
- **Pilotieren Sie den Ansatz** mit neuen Prozessen oder vorhandenen Automatisierungen. Sie werden überrascht sein, wie viele Edge-Kundenvorgänge Sie innerhalb von Schritten kostenlos finden, was Ihre integrierte Protokollierung und Beobachtbarkeit gewährleistet!

## Über den Autor

James Simone ist Principal Software Engineer bei Salesforce und verfügt über mehr als ein Jahrzehnt Erfahrung in der Arbeit an der Plattform. Er war Salesforce-Kunde – und Produktinhaber –, bevor er in die Entwicklung einstieg, und schreibt seit 2019 in [The Joys Of Apex](https://www.joysofapex.com/) technische Details zu Salesforce. Zuvor hat er Artikel im [Salesforce Developer Blog](https://developer.salesforce.com/content-archive?authors=James%20Simone&content-type=Blogs&language=English) und [im Salesforce Engineering Blog](https://engineering.salesforce.com/author/james-simone/) veröffentlicht.