Dieser Text wurde mit dem automatisierten Übersetzungssystem von Salesforce übersetzt. Nehmen Sie an unserer Umfrage teil, um Feedback zu diesem Inhalt zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten.

Wenn Sie Salesforce implementieren, müssen Sie es in der Regel in andere Anwendungen integrieren. Obwohl jedes Integrationsszenario einzigartig ist, müssen Entwickler und Architekten gemeinsame Anforderungen und Probleme lösen.

In diesem Dokument werden Strategien (in Form von Mustern) für diese gängigen Integrationsszenarien beschrieben. Jedes Muster beschreibt das Design und den Ansatz für ein bestimmtes Szenario, statt eine bestimmte Implementierung zu beschreiben. In diesem Dokument finden Sie Folgendes:

  • Eine Reihe von Mustern, die wichtige Integrationsszenarien vom Typ "Archetyp" ansprechen
  • Eine Auswahlmatrix, mit der bestimmt werden kann, welches Muster am besten zu Ihrem Szenario passt
  • Integrationstipps und bewährte Vorgehensweisen

Zweck und Umfang

Dieses Dokument richtet sich an Designer und Architekten, die Salesforce Platform in andere Anwendungen in ihrem Unternehmen integrieren müssen. Dieser Inhalt ist eine Zusammenfassung vieler erfolgreicher Implementierungen von Salesforce-Architekten und -Partnern.

Wenn Sie sich mit den Integrationsfunktionen und -optionen vertraut machen möchten, die für die umfassende Akzeptanz von Salesforce-basierten Anwendungen verfügbar sind, lesen Sie Musterübersicht und Musterauswahlhandbuch. Architekten und Entwickler sollten diese Musterdetails und bewährten Vorgehensweisen während der Entwurfs- und Implementierungsphase eines Salesforce-Integrationsprojekts berücksichtigen.

Wenn diese Muster ordnungsgemäß implementiert werden, können Sie so schnell wie möglich zur Produktion gelangen und über die stabilsten, skalierbarsten und wartungsfreien Anwendungen verfügen. Die eigenen beratenden Architekten von Salesforce verwenden diese Muster als Referenzpunkte bei Architekturüberprüfungen und pflegen und verbessern sie aktiv.

Wie bei allen Mustern deckt dieser Inhalt die meisten Integrationsszenarien ab, jedoch nicht alle. Salesforce ermöglicht zwar die Integration der Benutzeroberfläche (UI), Mashups beispielsweise, aber eine solche Integration fällt nicht in den Geltungsbereich dieses Dokuments.

Mustervorlage

Jedes Integrationsmuster folgt einer konsistenten Struktur. Dies sorgt für Konsistenz bei den in den einzelnen Mustern bereitgestellten Informationen und erleichtert zudem den Vergleich von Mustern.

Name

Der Musterkennzeichner, der auch den im Muster enthaltenen Integrationstyp angibt.

Context

Das allgemeine Integrationsszenario, auf das sich das Muster bezieht. Kontext enthält Informationen darüber, was Benutzer erreichen möchten und wie sich die Anwendung verhalten wird, um die Anforderungen zu erfüllen.

Problem

Das Szenario oder Problem (ausgedrückt als Frage), das bzw. das durch das Muster gelöst werden soll. Lesen Sie beim Überprüfen der Muster diesen Abschnitt, um schnell zu verstehen, ob das Muster für Ihr Integrationsszenario geeignet ist.

Kräfte

Die Einschränkungen und Umstände, die die Lösung des angegebenen Szenarios erschweren.

Lösung

Die empfohlene Lösung für das Integrationsszenario.

Skizze

Ein UML-Sequenzdiagramm, das Ihnen zeigt, wie die Lösung das Szenario angeht.

Ergebnisse

Erläutert, wie die Lösung auf Ihr Integrationsszenario angewendet wird und wie die mit diesem Szenario verbundenen Kräfte aufgelöst werden. Dieser Abschnitt enthält auch neue Herausforderungen, die durch die Anwendung des Musters auftreten können.

Randleisten

Zusätzliche Abschnitte zum Muster, die wichtige technische Probleme, Variationen des Musters, musterspezifische Bedenken usw. enthalten.

Beispiel

Ein durchgängiges Szenario, das beschreibt, wie das Designmuster in einem realen Salesforce-Szenario verwendet wird. Im Beispiel werden die Integrationsziele erläutert und erläutert, wie das Muster implementiert wird, um diese Ziele zu erreichen.

Musterübersicht

In der folgenden Tabelle sind die in diesem Dokument enthaltenen Integrationsmuster aufgeführt.

Liste der Muster remote-process-invocation--request-and-reply

Muster Szenario
Remote-Prozessaufruf – Anforderung und Antwort Salesforce ruft einen Prozess auf einem Remote-System auf, wartet auf den Abschluss dieses Prozesses und verfolgt dann den Status anhand der Antwort des Remote-Systems.
Remote-Prozessaufruf – Feuer und Vergessen Salesforce ruft einen Prozess in einem Remote-System auf, wartet jedoch nicht auf den Abschluss des Prozesses. Stattdessen empfängt und bestätigt der Remote-Prozess die Anforderung und übergibt dann die Kontrolle wieder an Salesforce.
Batch-Datensynchronisierung In Lightning Platform gespeicherte Daten werden erstellt oder aktualisiert, um Aktualisierungen aus einem externen System widerzuspiegeln und wenn Änderungen von Lightning Platform an ein externes System gesendet werden. Aktualisierungen in beide Richtungen erfolgen in Batch-Manier.
Remote-Anruf In Salesforce Platform gespeicherte Daten werden von einem Remote-System erstellt, abgerufen, aktualisiert oder gelöscht.
Benutzeroberflächenaktualisierung anhand von Datenänderungen Die Salesforce-Benutzeroberfläche muss aufgrund von Änderungen an Salesforce-Daten automatisch aktualisiert werden.
Datenvirtualisierung Salesforce greift in Echtzeit auf externe Daten zu. Dadurch müssen die Daten nicht mehr in Salesforce gespeichert und dann zwischen Salesforce und dem externen System abgeglichen werden.

Musteransatz

Die Integrationsmuster in diesem Dokument werden in drei Kategorien unterteilt:

  • Datenintegration: Diese Muster erfüllen die Anforderung, Daten zu synchronisieren, die sich in zwei oder mehr Systemen befinden, damit beide Systeme immer aktuelle und aussagekräftige Daten enthalten. Die Datenintegration ist oft die am einfachsten zu implementierende Art der Integration, erfordert jedoch geeignete Informationsverwaltungstechniken, um die Lösung nachhaltig und kosteneffizient zu gestalten. Solche Techniken umfassen oft Aspekte der Masterdatenverwaltung (Master Data Management, MDM), der Datenverwaltung, des Mastering, der Duplizierung, des Datenflussdesigns und andere.

  • Prozessintegration: Die Muster in dieser Kategorie berücksichtigen die Notwendigkeit, dass ein Geschäftsprozess zwei oder mehr Anwendungen nutzen muss, um seine Aufgabe zu erledigen. Wenn Sie eine Lösung für diesen Integrationstyp implementieren, muss die auslösende Anwendung über Prozessgrenzen hinweg zu anderen Anwendungen aufrufen. In der Regel umfassen diese Muster auch sowohl die Orchestrierung (wobei eine Anwendung das zentrale "Steuerfeld" ist) als auch die Choreografie (wobei Anwendungen mehrere Teilnehmer sind und es kein zentrales "Steuerfeld" gibt). Diese Integrationen erfordern oft komplexe Anforderungen an Design, Tests und die Verarbeitung von Ausnahmen. Darüber hinaus sind solche zusammengesetzten Anwendungen in der Regel anspruchsvoller für die zugrunde liegenden Systeme, da sie oft langfristige Transaktionen unterstützen und Berichte zum Prozessstatus erstellen oder verwalten können.

  • Virtuelle Integration: Die Muster in dieser Kategorie berücksichtigen die Notwendigkeit, dass ein Benutzer in einem externen System gespeicherte Daten anzeigen, durchsuchen und ändern muss. Wenn Sie eine Lösung für diesen Integrationstyp implementieren, muss die auslösende Anwendung andere Anwendungen aufrufen und in Echtzeit mit ihren Daten interagieren. Durch diese Art der Integration müssen Daten nicht mehr systemübergreifend repliziert werden, sodass Benutzer immer mit den neuesten Daten interagieren.

Die Auswahl der besten Integrationsstrategie für Ihr System ist nicht trivial. Es gibt viele Aspekte zu berücksichtigen und viele Tools, die verwendet werden können, wobei einige Tools für bestimmte Aufgaben besser geeignet sind als andere. Jedes Muster richtet sich an bestimmte kritische Bereiche, einschließlich der Funktionen der einzelnen Systeme, des Datenvolumens, der Fehlerverarbeitung und der Transaktionalität.

Musterauswahlhandbuch

In den Auswahlmatrixtabellen werden die Muster und ihre wichtigsten Aspekte aufgeführt, damit Sie bestimmen können, welches Muster Ihren Integrationsanforderungen am besten entspricht. Die Muster werden anhand dieser Dimensionen kategorisiert.

Aspekt Beschreibung
Typ Gibt den Integrationsstil an: "Prozess", "Daten" oder "Virtuell".
  • Prozess: Prozessbasierte Integrationen sind Möglichkeiten, die Verarbeitung von funktionalen Flows in zwei oder mehr Anwendungen zu integrieren. Diese Integrationen erfordern in der Regel ein höheres Maß an Abstraktion und Komplexität, insbesondere für Transaktionalität und Rollback.
  • Data: Datenintegrationen sind die Integration der von Anwendungen verwendeten Informationen. Diese Integrationen können vom einfachen Einfügen oder Aktualisieren oder Einfügen von Tabellen bis hin zu komplexen Datenaktualisierungen reichen, die referenzielle Integrität und komplexe Übersetzungen erfordern.
  • Virtual: Bei virtuellen Integrationen interagiert Salesforce mit Daten, die sich in einem externen System befinden, ohne die Daten in Salesforce replizieren zu müssen. Diese Art der Integration wird immer über ein Ereignis von der Salesforce Platform ausgelöst, beispielsweise eine Benutzeraktion, eine Suche oder eine Datensatzaktualisierung, was zu einer Datenintegration mit einer externen Quelle in Echtzeit führt.
Zeitpunkt Gibt den Integrationsstil an: "Prozess", "Daten" oder "Virtuell".
  • Synchronous: Blockierungs- und Echtzeitanforderungen sind Anforderungs-/Antwortvorgänge. Das Ergebnis wird über diesen Vorgang sofort an den Anrufer zurückgegeben.
  • Asynchron: Nicht blockierende, warteschlangen- oder nachrichtenbasierte Anforderungen werden durch einen Einbahnvorgang aufgerufen, der nahezu in Echtzeit erfolgt. Die Ergebnisse und etwaige Fehler werden durch Aufrufen anderer einseitiger Vorgänge zurückgegeben.Der Anrufer sendet daher die Anforderung und fährt fort, ohne auf eine Antwort zu warten.

Integration von Salesforce in ein anderes System

In dieser Tabelle sind die Muster und ihre wichtigsten Aspekte aufgeführt, damit Sie bestimmen können, welches Muster Ihren Anforderungen am besten entspricht, wenn Ihre Integration von Salesforce in ein anderes System erfolgt.

Typ Zeitpunkt Zu berücksichtigendes Schlüsselmuster
Prozessintegration Synchronous Remote-Prozessaufruf – Anforderung und Antwort
Prozessintegration Asynchron Remote-Prozessaufruf – Feuer und Vergessen
Datenintegration Synchronous Remote-Prozessaufruf – Anforderung und Antwort
Datenintegration Asynchron Benutzeroberflächenaktualisierung anhand von Datenänderungen
Virtuelle Integration Synchronous Datenvirtualisierung

Integration eines anderen Systems in Salesforce

In dieser Tabelle sind die Muster und ihre wichtigsten Aspekte aufgeführt, damit Sie das Muster ermitteln können, das Ihren Anforderungen am besten entspricht, wenn Ihre Integration von einem anderen System in Salesforce erfolgt.

Typ Zeitpunkt Zu berücksichtigendes Schlüsselmuster
Prozessintegration Synchronous Remote-Anruf
Prozessintegration Asynchron Remote-Anruf
Datenintegration Synchronous Remote-Anruf
Datenintegration Asynchron Batch-Datensynchronisierung

Middleware-Begriffe und -Definitionen

In dieser Tabelle sind einige wichtige Begriffe in Bezug auf Middleware und ihre Definitionen in Bezug auf diese Muster aufgeführt.

Term Definition
Ereignisverarbeitung Bei der Ereignisverarbeitung handelt es sich um den Empfang einer identifizierbaren Instanz bei einem angegebenen Empfänger ("Handler"). Zu den wichtigsten Prozessen bei der Ereignisverarbeitung zählen:

  • Identifizieren, wohin ein Ereignis weitergeleitet werden soll
  • Ausführen dieser Weiterleitungsaktion
  • Empfangen eines weitergeleiteten Ereignisses
  • Ausführen geeigneter Maßnahmen als Reaktion darauf, beispielsweise Schreiben in ein Protokoll, Senden eines Fehlers oder Wiederherstellungsprozesses oder Senden einer zusätzlichen Nachricht

Beachten Sie, dass der Ereignis-Handler das Ereignis letztlich an einen Ereignisverbraucher weiterleiten kann.

Allgemeine Verwendungen dieser Funktion mit Middleware können um die beliebte Funktion "veröffentlichen/abonnieren" oder "Pub/Sub" erweitert werden. In einem Veröffentlichungs-/Abonnementszenario leitet die Middleware Anforderungen oder Nachrichten von aktiven Datenereignis-Publishern an aktive Datenereignis-Abonnenten weiter. Diese Verbraucher mit aktiven Zuhörern können die Ereignisse dann bei der Veröffentlichung abrufen.
In Salesforce-Integrationen, die Middleware verwenden, übernimmt die Middleware-Ebene die Kontrolle über die Ereignisverarbeitung. Sie erfasst alle relevanten Ereignisse, synchron oder asynchron, und verwaltet die Verteilung an alle Endpunkte, einschließlich Salesforce.

Alternativ kann diese Funktion mit der Salesforce Enterprise Messaging Platform durch Verwendung des Ereignis-Busses mit Plattformereignissen erreicht werden.
Protokollkonvertierung Bei der Protokollkonvertierung handelt es sich in der Regel um eine Softwareanwendung, die das Standard- oder proprietäre Protokoll eines Geräts in das für ein anderes Gerät geeignete Protokoll konvertiert, um die Interoperabilität zu erreichen.

Im Kontext der Middleware kann die Verbindung mit einem bestimmten Zielsystem durch ein Protokoll eingeschränkt werden. In solchen Fällen muss das Nachrichtenformat in das Format des Zielsystems konvertiert oder in dieses gekapselt werden, in dem die Nutzlast extrahiert werden kann. Dies wird auch als Tunnelbau bezeichnet.
Salesforce unterstützt die native Protokollkonvertierung nicht. Daher wird davon ausgegangen, dass solche Anforderungen von der Middleware-Ebene oder vom Endpunkt erfüllt werden.
Übersetzung und Transformation Transformation ist die Möglichkeit, ein Datenformat einem anderen zuzuordnen, um die Interoperabilität zwischen den verschiedenen Systemen zu gewährleisten, die integriert werden. In der Regel werden Nachrichten unterwegs neu formatiert, um sie an die Anforderungen des Absenders oder Empfängers anzupassen. In komplexeren Fällen kann eine Anwendung eine Nachricht in ihrem eigenen nativen Format senden und zwei oder mehr andere Anwendungen können jeweils eine Kopie der Nachricht in ihrem eigenen nativen Format erhalten.

Middleware-Übersetzungs- und -Transformationstools enthalten oft die Möglichkeit, Servicefassaden für ältere oder andere nicht standardmäßige Endpunkte zu erstellen. Durch diese Servicefassaden können diese Endpunkte als serviceadressierbar angezeigt werden.

Bei Salesforce-Integrationen wird davon ausgegangen, dass solche Anforderungen von der Middleware-Ebene oder vom Endpunkt erfüllt werden. Die Transformation von Daten kann in Apex codiert werden, wird jedoch aus Wartungs- und Leistungsgründen nicht empfohlen.
Warteschlange und Pufferung Warteschlange und Pufferung basieren im Allgemeinen auf der asynchronen Nachrichtenweitergabe und nicht auf einer Architektur für Anforderungen und Antworten. In asynchronen Systemen stellen Nachrichtenwarteschlangen temporären Speicher bereit, wenn das Zielprogramm ausgelastet oder die Verbindung gefährdet ist. Darüber hinaus bieten die meisten asynchronen Middleware-Systeme persistenten Speicher zum Sichern der Nachrichtenwarteschlange.

Der Hauptvorteil eines asynchronen Nachrichtenprozesses besteht darin, dass die Absender nicht betroffen sein können, wenn die Empfängeranwendung aus irgendeinem Grund fehlschlägt. Die gesendeten Nachrichten werden einfach in der Nachrichtenwarteschlange für die spätere Verarbeitung kumuliert, wenn der Empfänger neu gestartet wird.
Salesforce bietet nur explizite Warteschlangenfunktionen in Form von workflowbasierten ausgehenden Nachrichten. Um eine echte Nachrichtenwarteschlange für andere Integrationsszenarien bereitzustellen, einschließlich Orchestrierung, Prozesschoreografie und Servicequalität, ist eine Middleware-Lösung erforderlich.
Synchrone Transportprotokolle Synchrone Transportprotokolle beziehen sich auf Protokolle, die Aktivitäten unterstützen, bei denen ein einzelner Thread im Aufrufer die Anforderungsnachricht sendet, blockiert, um auf die Antwortnachricht zu warten, und dann die Antwort verarbeitet....Der Anforderungs-Thread, der auf die Antwort wartet, bedeutet, dass nur eine ausstehende Anforderung vorhanden ist oder dass der Antwortkanal für diese Anforderung für diesen Thread privat ist.
Asynchrone Transportprotokolle Asynchrone Transportprotokolle beziehen sich auf Protokolle, die Aktivitäten unterstützen, bei denen "ein Thread im Anrufer die Anforderungsnachricht sendet und eine Rückmeldung für die Antwort einrichtet. Ein separater Thread lauscht auf Antwortnachrichten. Wenn eine Antwortnachricht eingeht, ruft der Antwort-Thread die entsprechende Rückmeldung auf, wodurch der Kontext des Anrufers wiederhergestellt und die Antwort verarbeitet wird. Durch diesen Ansatz können mehrere ausstehende Anforderungen einen einzelnen Antwort-Thread freigeben.“
Vermittlungsweiterleitung Die Vermittlungsweiterleitung ist die Spezifikation eines komplexen "Flows" von Nachrichten von Komponente zu Komponente. Beispielsweise sind viele Middleware-basierte Lösungen von einem Nachrichtenwarteschlangensystem abhängig. Während einige Implementierungen die Bereitstellung von Weiterleitungslogik durch die Messaging-Ebene selbst zulassen, sind andere auf Client-Anwendungen angewiesen, um Weiterleitungsinformationen bereitzustellen oder eine Kombination aus beiden Paradigmen zu ermöglichen. In solch komplexen Fällen vereinfacht die Mediation durch Middleware die Entwicklung, Integration und Validierung. ordinator [Mediator] könnte sicherstellen, dass die richtige Nachricht an den richtigen Verbraucher gelangt.“
Prozesschoreografie und Serviceorchestrierung Prozesschoreografie und Serviceorchestrierung sind jeweils Formen der "Servicekomposition", bei denen eine beliebige Anzahl von Endpunkten und Funktionen koordiniert werden.

Der Unterschied zwischen Choreografie und Serviceorchestrierung ist:
  • Choreografie kann als asynchroner Ansatz definiert werden, der es Prozessen ermöglicht, autonom zu arbeiten, wobei alle Probleme entfernt werden, die durch Abhängigkeiten verursacht werden, d. h. das Verhalten, das sich aus einer Gruppe interagierender einzelner Einheiten ohne zentrale Autorität ergibt.
  • Die Orchestrierung kann als synchroner Ansatz definiert werden, der die Ausführung einer Abfrage oder eines Prozesses ermöglicht, indem jedem Microservice die Möglichkeit gegeben wird, vom Orchestrierer zugewiesene Aufgaben zu implementieren. Hierbei handelt es sich um das Verhalten eines zentralen Leiters, der das Verhalten einzelner Einheiten koordiniert, die Aufgaben unabhängig voneinander ausführen.
Darüber hinaus zeigt eine Orchestrierung das vollständige Verhalten jedes Service an, während die Choreografie die Beschreibungen des Oberflächenverhaltens jedes Service kombiniert.
Teile von Geschäftsprozesschoreografien können in Salesforce-Workflows oder mithilfe von Apex erstellt werden. Es wird empfohlen, alle komplexen Orchestrierungen auf Middleware-Ebene zu implementieren, da Salesforce-Zeitüberschreitungswerte und -Obergrenzen gelten, insbesondere bei Lösungen, die eine echte Transaktionsverarbeitung erfordern.
Transaktionalität (Verschlüsselung, Signieren, zuverlässige Zustellung, Transaktionsverwaltung) Transaktionalität kann definiert werden als die Möglichkeit, globale Transaktionen zu unterstützen, die alle erforderlichen Vorgänge für jede erforderliche Ressource umfassen. Transaktionalität beinhaltet die Unterstützung aller vier ACID-Eigenschaften, Atomarität, Konsistenz, Isolation und Haltbarkeit, wobei Atomarität Alles-oder-nichts-Ergebnisse für die Arbeitseinheit (Transaktion) garantiert.

Salesforce ist zwar in sich transaktional, kann jedoch nicht an verteilten Transaktionen oder Transaktionen teilnehmen, die außerhalb von Salesforce initiiert wurden. Daher wird davon ausgegangen, dass für Lösungen, die komplexe Transaktionen mit mehreren Systemen erfordern, die Transaktionalität und die zugehörigen Rollback-/Kompensationsmechanismen auf Middleware-Ebene implementiert sind.
Weiterleitung Die Weiterleitung kann als Angabe des komplexen Nachrichtenflusses von Komponente zu Komponente definiert werden. In modernen Services-basierten Lösungen können solche Nachrichten-Flows auf einer Reihe von Kriterien basieren, einschließlich Kopfzeile, Inhaltstyp, Regel und Priorität.

Bei Salesforce-Integrationen wird davon ausgegangen, dass solche Anforderungen von der Middleware-Ebene oder vom Endpunkt erfüllt werden. Die Nachrichtenweiterleitung kann in Apex codiert werden, wird jedoch aus Wartungs- und Leistungsgründen nicht empfohlen.
Extrahieren, Umwandeln und Laden Extrahieren, transformieren und laden (Extract, Transform and Load, ETL) bezieht sich auf einen Prozess, der Folgendes umfasst:
  • Extrahieren von Daten aus den Quellsystemen. Dieser Prozess umfasst in der Regel Daten aus mehreren Quellsystemen sowie relationale und nicht relationale Strukturen.
  • Umwandeln der Daten an die betrieblichen Anforderungen, einschließlich Datenqualitätsstufen. Die Transformationsphase wendet in der Regel eine Reihe von Regeln oder Funktionen auf die extrahierten Daten aus der Quelle an, um die Daten zum Laden in das oder die Endziele abzuleiten.
  • Laden der Daten in das Zielsystem. Das Zielsystem kann sehr unterschiedlich sein – von Datenbank, Betriebsdatenspeicher, Data Mart, Data Warehouse oder anderen Betriebssystemen.
Die meisten ausgereiften ETL-Tools sind zwar nicht unbedingt erforderlich, bieten jedoch eine Funktion zur Datenerfassung von Änderungen. Bei dieser Funktion identifiziert das Tool Datensätze im Quellsystem, die sich seit der letzten Extraktion geändert haben, wodurch die Datensatzverarbeitung reduziert wird.

Salesforce unterstützt nun auch die Datenerfassung für Änderungen. Hierbei handelt es sich um die Veröffentlichung von Änderungsereignissen, die Änderungen an Salesforce-Datensätzen darstellen. Mit der Datenerfassung für Änderungen erhält der Client oder das externe System nahezu in Echtzeit Änderungen an Salesforce-Datensätzen. Mit diesen Informationen kann der Client oder das externe System entsprechende Datensätze in einem externen Datenspeicher synchronisieren.
Lange Abstimmung Bei langen Abfragen, auch Comet-Programmierung genannt, wird ein Informations-Push von einem Server an einen Client emuliert. Ähnlich wie bei einer normalen Abstimmung stellt der Client eine Verbindung her und fordert Informationen vom Server an. Statt jedoch eine leere Antwort zu senden, wenn keine Informationen verfügbar sind, hält der Server die Anforderung und wartet, bis Informationen verfügbar sind (ein Ereignis tritt auf). Der Server sendet dann eine vollständige Antwort an den Client. Der Client fordert dann sofort Informationen an. Der Client hält ständig eine Verbindung mit dem Server aufrecht, sodass er immer auf eine Antwort wartet. Wenn der Server eine Zeitüberschreitung aufweist, stellt der Client eine erneute Verbindung her und beginnt von vorne.

Die Salesforce Streaming-API verwendet das Bayeux-Protokoll und CometD für lange Abfragen.
  • Bayeux ist ein Protokoll zum Transport asynchroner Nachrichten, hauptsächlich über HTTP.
  • CometD ist ein skalierbarer HTTP-basierter Ereignisweiterleitungs-Bus, der ein AJAX-Push-Technologiemuster verwendet, das als Comet bekannt ist. Es implementiert das Bayeux-Protokoll.

Context

Sie verwenden Salesforce, um Leads zu verfolgen, Ihre Pipeline zu verwalten, Opportunities zu erstellen und Auftragsdetails zu erfassen, die Leads in Kunden konvertieren. Das Salesforce-System enthält oder verarbeitet jedoch keine Aufträge. Nachdem die Auftragsdetails in Salesforce erfasst wurden, wird der Auftrag im Remote-System erstellt, das den Abschluss des Auftrags verwaltet.

Wenn Sie dieses Muster implementieren, ruft Salesforce das Remote-System auf, um den Auftrag zu erstellen, und wartet dann auf den erfolgreichen Abschluss. Bei Erfolg antwortet das Remote-System synchron mit dem Auftragsstatus und der Auftragsnummer. Im Rahmen derselben Transaktion aktualisiert Salesforce die Auftragsnummer und den Status intern. Die Auftragsnummer wird als Fremdschlüssel für nachfolgende Aktualisierungen am Remote-System verwendet.

Problem

Wie initiieren Sie beim Auftreten eines Ereignisses in Salesforce einen Prozess in einem Remote-System, übergeben die erforderlichen Informationen an diesen Prozess, erhalten eine Antwort vom Remote-System und verwenden diese Antwortdaten dann, um Aktualisierungen in Salesforce vorzunehmen?

Kräfte

Beachten Sie beim Anwenden von Lösungen, die auf diesem Muster basieren, die folgenden Kräfte.

  • Muss Salesforce für den Aufruf des Remote-Systems auf eine Antwort warten, bevor die Verarbeitung fortgesetzt wird? Handelt es sich beim Aufruf des Remote-Systems um eine synchrone Anforderungsantwort oder eine asynchrone Anforderung?
  • Wenn der Anruf an das Remote-System synchron ist, muss Salesforce die Antwort als Teil derselben Transaktion wie den ursprünglichen Anruf verarbeiten?
  • Ist die Nachrichtengröße klein oder groß?
  • Basiert die Integration auf dem Auftreten eines bestimmten Ereignisses, beispielsweise eines Schaltflächenklicks auf der Salesforce-Benutzeroberfläche oder DML-basierter Ereignisse?
  • Kann der Remote-Endpunkt mit geringer Latenz auf die Anforderung antworten? Wie viele Benutzer werden diese Transaktion wahrscheinlich in einem Spitzenzeitraum ausführen?

Lösung

Diese Tabelle enthält Lösungen für dieses Integrationsproblem.

Lösung Fit Kommentare
Externe Services rufen einen REST-API-Aufruf auf Best Mit externen Services können Sie einen extern gehosteten Service deklarativ aufrufen (kein Code erforderlich). Diese Funktion wird am besten verwendet, wenn die folgenden Bedingungen erfüllt sind:
  • Der extern gehostete Service ist ein RESTful-Service und die Definitionen sind im OpenAPI 2.0- oder OpenAPI 3.0- oder YAML-Schemaformat verfügbar.
  • Die Anforderungs- und Antwortdefinitionen enthalten primitive Datentypen wie boolesch, datetime, double, integer, string oder ein Array primitiver Datentypen. Geschachtelte Objekttypen und Sendeparameter wie Kopfzeilen innerhalb der HTTP-Anforderungen werden unterstützt.
  • Die Transaktion kann über einen Flow aufgerufen werden.
Salesforce Lightning: Die Lightning-Komponente oder -Seite initiiert einen synchronen Apex REST- oder SOAP-Callout.</

Wenn für den Remote-Endpunkt das Risiko einer Reaktion mit hoher Latenz besteht (siehe Dokumentation zu den aktuellen Obergrenzen für die geltenden Obergrenzen), wird ein asynchroner Callout, auch als Fortsetzung bezeichnet, empfohlen, um zu vermeiden, dass synchrone Apex-Transaktionsobergrenzen erreicht werden. 		Best Salesforce ermöglicht es Ihnen, eine WSDL zu verwenden und eine resultierende Apex-Klasse für Proxys zu generieren. Diese Klasse bietet die erforderliche Logik zum Aufrufen des Remote-Service.

Salesforce ermöglicht es Ihnen auch, HTTP-Services (REST) mit den standardmäßigen GET-, POST-, PUT- und DELETE-Methoden aufzurufen.

Eine vom Benutzer initiierte Aktion auf einer Lightning-Seite ruft dann eine Apex-Steuerfeldaktion auf, die dann diese Apex-Proxy-Klasse ausführt, um den Remote-Aufruf auszuführen. Für Lightning-Seiten muss die Salesforce-Anwendung angepasst werden.
Ein synchroner Auslöser, der über Salesforce-Datenänderungen aufgerufen wird, führt einen asynchronen Apex SOAP- oder HTTP-Callout aus. Suboptimal Sie können Apex-Auslöser verwenden, um eine Automatisierung anhand von Datensatzdatenänderungen durchzuführen.

Eine Apex Proxy-Klasse kann als Ergebnis eines DML-Vorgangs mithilfe eines Apex Auslösers ausgeführt werden. Alle Aufrufe innerhalb des Auslöserkontexts müssen jedoch asynchron vom initiierenden Ereignis ausgeführt werden. Daher wird diese Lösung für dieses Integrationsproblem nicht empfohlen. Diese Lösung eignet sich besser für das Muster "Remote Process Invocation – Fire and Forget" (Aufruf und Vergessen des Remote-Prozesses).
Ein Apex Batchauftrag führt einen synchronen Apex SOAP- oder HTTP-Callout aus. Suboptimal Sie können Anrufe an ein Remote-System über einen Batchauftrag tätigen. Diese Lösung ermöglicht die Batch-Remote-Prozessausführung und -verarbeitung der Antwort vom Remote-System in Salesforce. Für einen bestimmten Batch gelten jedoch Obergrenzen für die Anzahl der Aufrufe. Weitere Informationen finden Sie unter Obergrenzen für Gouverneure.

Eine bestimmte Batchausführung kann mehrere Transaktionskontexte ausführen (in der Regel in Intervallen von 200 Datensätzen). Die Obergrenzen werden pro Transaktionskontext zurückgesetzt.

Skizze

In diesem Diagramm wird ein synchroner Remote-Prozessaufruf mit Apex-Aufrufen veranschaulicht.

Salesforce ruft Remote-System an

Salesforce ruft Remote-System an

Diagramm herunterladen

In diesem Szenario:

  • Auf der Lightning-Seite wird eine Aktion initiiert (z. B. durch Klicken auf eine Schaltfläche).
  • Der Browser (im Falle einer Lightning-Komponente über ein clientseitiges Steuerfeld) führt einen HTTP POST aus, der wiederum eine Aktion für das entsprechende Apex-Steuerfeld ausführt.
  • Das Steuerfeld ruft den eigentlichen Aufruf an den Remote-Webservice auf.
  • Die Antwort des Remote-Systems wird an das Apex-Steuerfeld zurückgegeben. Das Steuerfeld verarbeitet die Antwort, aktualisiert bei Bedarf die Daten in Salesforce und stellt die Seite erneut dar.

In Fällen, in denen der nachfolgende Status verfolgt werden muss, gibt das Remote-System einen eindeutigen Kennzeichner zurück, der im Salesforce-Datensatz gespeichert ist.

Ergebnisse

Die Anwendung der Lösungen für dieses Muster ermöglicht ereignisinitiierte Remote-Prozessaufrufe, bei denen Salesforce die Verarbeitung verarbeitet.

Anrufmechanismen

Der Aufrufmechanismus hängt von der Lösung ab, die zur Implementierung dieses Musters ausgewählt wurde.

Anrufmechanismus Beschreibung
Erweiterter externer Service, der in einen Flow eingebettet ist, oder

Lightning-Komponente oder

Apex Steuerfelder 		Wird verwendet, wenn der Remote-Prozess im Rahmen eines durchgängigen Prozesses mit der Benutzeroberfläche ausgelöst wird und das Ergebnis in einem Salesforce-Datensatz angezeigt oder aktualisiert werden muss. Beispielsweise werden die Zahlungsergebnisse sofort zurückgegeben und dem Benutzer angezeigt, wenn eine Kreditkartenzahlung an ein externes Zahlungs-Gateway gesendet wird.
Apex Auslöser Wird hauptsächlich zum Aufrufen von Remote-Prozessen mithilfe von Apex Callouts aus DML-initiierten Ereignissen verwendet. Weitere Informationen zu diesem Aufrufmechanismus finden Sie unter Muster Remote Process Invocation – Fire and Forget (Remote-Prozessaufruf – ausgelöst und vergessen).
Apex Batchklassen Wird zum Aufrufen von Remote-Prozessen im Batch verwendet. Weitere Informationen zu diesem Aufrufmechanismus finden Sie unter Muster Remote Process Invocation – Fire and Forget (Remote-Prozessaufruf – ausgelöst und vergessen).

Fehlerbehandlung und -behebung

Es ist wichtig, eine Strategie zur Fehlerbehandlung und -behebung als Teil der Gesamtlösung einzubeziehen.

  • Fehlerbehandlung: Wenn ein Fehler auftritt (Ausnahmen oder Fehlercodes werden an den Anrufer zurückgegeben), verwaltet der Anrufer die Fehlerbehandlung. Beispielsweise eine Fehlermeldung, die auf der Seite des Endbenutzers angezeigt oder in einer Tabelle protokolliert wird und weitere Maßnahmen erfordert.

  • Wiederherstellung: Änderungen werden erst dann an Salesforce übertragen, wenn der Anrufer eine erfolgreiche Antwort erhält. Beispielsweise wird der Auftragsstatus erst in der Datenbank aktualisiert, wenn eine Antwort eingegangen ist, die auf Erfolg hinweist. Bei Bedarf kann der Anrufer den Vorgang wiederholen.

Überlegungen zum idempotenten Design

Idempotente Funktionen garantieren, dass wiederholte Aufrufe sicher sind. Wenn Idempotenz nicht implementiert ist, können wiederholte Aufrufe derselben Nachricht unterschiedliche Ergebnisse haben, was möglicherweise zu Problemen mit der Datenintegrität führen kann. Mögliche Probleme sind die Erstellung doppelter Datensätze oder die doppelte Verarbeitung von Transaktionen.

Es ist wichtig, sicherzustellen, dass das aufgerufene Remote-Verfahren idempotent ist. Wenn der Anruf über die Benutzeroberfläche erfolgt, müssen wir auf der Integrationsebene auf die Identität achten, insbesondere wenn keine Garantie dafür besteht, dass Salesforce nur einmal anruft.

Die typischste Methode zum Erstellen eines idempotenten Empfängers besteht darin, Duplikate anhand eindeutiger Nachrichtenkennzeichner zu verfolgen, die vom Verbraucher gesendet werden. Apex-Webservice- oder REST-Aufrufe müssen angepasst werden, um eine eindeutige Nachrichten-ID zu senden.

Darüber hinaus müssen Vorgänge, die Datensätze im Remote-System erstellen, vor dem Einfügen auf Duplikate überprüft werden. Überprüfen Sie dies, indem Sie eine eindeutige Datensatz-ID von Salesforce übergeben. Wenn der Datensatz im Remote-System vorhanden ist, aktualisieren Sie den Datensatz. In den meisten Systemen wird dieser Vorgang als Upsert-Vorgang bezeichnet.

Sicherheitsüberlegungen

Bei jedem Anruf an ein Remote-System müssen die Vertraulichkeit, Integrität und Verfügbarkeit der Anforderung gewahrt bleiben. Die folgenden Sicherheitsüberlegungen beziehen sich speziell auf die Verwendung von Apex SOAP und HTTP-Aufrufen in diesem Muster.

  • Einweg-SSL ist standardmäßig aktiviert, aber bidirektionales SSL wird sowohl mit selbstsignierten als auch mit von einer Zertifizierungsstelle signierten Zertifikaten unterstützt, um die Authentizität von Client und Server aufrechtzuerhalten.

  • Geben Sie im Callout-Endpunkt Anmeldeinformationen mit Namen an, um Ihren Apex Code zu optimieren und die Einrichtung authentifizierter Callouts zu vereinfachen.

  • Ziehen Sie die Verwendung von OAUTH 2.0 als Authentifizierungsmechanismus für die Integration in externe Systeme in Betracht.

  • Verwenden Sie ggf. Einweg-Hashes oder digitale Signaturen mithilfe der Apex Crypto-Klassenmethoden, um die Integrität der Anforderung sicherzustellen.

  • Das Remote-System muss durch Implementierung der entsprechenden Firewall-Mechanismen geschützt werden. Siehe Sicherheitsüberlegungen.

  • Salesforce unterstützt WS-Security derzeit nicht. Obwohl diese komplexen WS-Security-Kopfzeilen nicht nativ generiert oder automatisch aus einer eingehenden WSDL erzwungen werden, können Sie sie manuell erstellen und implementieren, indem Sie benutzerdefinierte Apex-Klassen erstellen, um die SOAP-Kopfzeilen und Sicherheitstoken für eingehende Anforderungen zu verarbeiten.

Randleisten

Keine.

Pünktlichkeit

Aktualität ist in diesem Muster von erheblicher Bedeutung. In der Regel:

  • Die Anforderung wird in der Regel über die Benutzeroberfläche aufgerufen, sodass der Benutzer nicht warten muss.
  • Salesforce hat eine konfigurierbare Zeitüberschreitung von bis zu 120 Sekunden für Anrufe über Apex.
  • Der Abschluss des Remote-Prozesses wird zeitnah ausgeführt, sodass er innerhalb der Salesforce-Zeitüberschreitungsobergrenze und innerhalb der Erwartungen der Benutzer abgeschlossen wird.
  • Externe Aufrufe unterliegen den Obergrenzen für synchrone Apex-Transaktionen. Daher sollten Sie das Risiko minimieren, dass mehr als 50 Transaktionen instanziiert werden, die jeweils länger als fünf Sekunden ausgeführt werden. Neben der Leistung des externen Endpunkts stehen folgende Optionen zur Verfügung, um das Risiko einer Zeitüberschreitung zu minimieren:
    • Legen Sie die Zeitüberschreitung des externen Callouts auf fünf Sekunden fest.
    • Verwenden einer Fortsetzung in Lightning Components zum Verarbeiten langfristiger Transaktionen

Datenvolumen

Aufgrund der kleinen Zeitüberschreitungswerte und der maximalen Größe der Anforderung oder Antwort für die Apex-Anruflösung wird dieses Muster hauptsächlich für Echtzeitaktivitäten mit kleinem Volumen verwendet. Verwenden Sie dieses Muster nicht bei Batchverarbeitungsaktivitäten, bei denen die Datennutzlast in der Nachricht enthalten ist.

Unterstützung von Endpunktfunktionen und Standards

Die Funktionen und die Standardunterstützung für den Endpunkt hängen von der von Ihnen ausgewählten Lösung ab.

Lösung Überlegungen zu Endpunkten
Apex HTTP-Callouts Der Endpunkt muss HTTP-Aufrufe empfangen können. Salesforce muss über das öffentliche Internet auf den Endpunkt zugreifen können. Salesforce unterstützt nun auch Salesforce Private Connect über die Hyperforce Platform sicher für die private und sichere Kommunikation. Weitere Details finden Sie unter Salesforce Private Connect.

Sie können Apex HTTP-Callouts verwenden, um REST-Services mit den Standardmethoden GET, POST, PUT, DELETE und PATCH aufzurufen.
Apex SOAP-Callouts Der Endpunkt muss HTTP-Aufrufe empfangen können. Salesforce muss über das öffentliche Internet auf den Endpunkt zugreifen können. Salesforce unterstützt nun auch Salesforce Private Connect über die Hyperforce Platform sicher für die private und sichere Kommunikation. Weitere Details finden Sie unter Salesforce Private Connect.

Für diese Lösung muss das Remote-System mit den von Salesforce unterstützten Standards kompatibel sein. Zum Zeitpunkt des Schreibens wurden von Salesforce für Apex SOAP-Callouts folgende Webservicestandards unterstützt:
  • WSDL 1.1
  • SOAP 1.1
  • WSI-Basisprofil 1.1

Statusverwaltung

Bei der Integration von Systemen sind Schlüssel für die fortlaufende Statusverfolgung wichtig. Es gibt zwei Optionen.

  • Salesforce speichert den primären oder eindeutigen Ersatzschlüssel des Remote-Systems für den Remote-Datensatz.
  • Das Remote-System speichert die eindeutige Salesforce-Datensatz-ID oder einen anderen eindeutigen Ersatzschlüssel.

Je nachdem, welches System den Masterdatensatz enthält, gibt es spezifische Überlegungen zur Verarbeitung von Integrationsschlüsseln, wie in der folgenden Tabelle dargestellt.

Master System Beschreibung
Salesforce Das Remote-System speichert entweder die Salesforce RecordId oder einen anderen eindeutigen Ersatzschlüssel aus dem Datensatz.
Remote-System Der Aufruf des Remote-Prozesses gibt den eindeutigen Schlüssel aus der Anwendung zurück und Salesforce speichert diesen Schlüsselwert in einem eindeutigen Datensatzfeld.

Komplexe Integrationsszenarien

In bestimmten Fällen kann die nach diesem Muster vorgeschriebene Lösung die Implementierung mehrerer komplexer Integrationsszenarien erfordern. Dies wird am besten durch Verwendung von Middleware oder durch Aufrufen eines zusammengesetzten Service durch Salesforce erreicht. Zu diesen Szenarien zählen:

  • Orchestrierung von Geschäftsprozessen und Regeln mit komplexer Flow-Logik
  • Aggregation von Anrufen und deren Ergebnissen über mehrere Systeme hinweg
  • Transformation von eingehenden und ausgehenden Nachrichten
  • Aufrechterhalten der transaktionalen Integrität über mehrere Aufrufe hinweg

Obergrenzen

Informationen zu Apex Obergrenzen finden Sie im Apex Developer Guide unter Execution Governors and Limits (Ausführungsobergrenzen und -obergrenzen).

Middleware-Funktionen

In der folgenden Tabelle werden die wünschenswerten Eigenschaften eines Middleware-Systems hervorgehoben, das an diesem Muster teilnimmt.

Eigenschaft Obligatorisch Wünschenswert Nicht erforderlich
Ereignisverarbeitung X
Protokollkonvertierung X
Übersetzung und Transformation X
Warteschlange und Pufferung X
Synchrone Transportprotokolle X
Asynchrone Transportprotokolle X
Vermittlungsweiterleitung X
Prozesschoreografie und Serviceorchestrierung X
Transaktionalität (Verschlüsselung, Signieren, zuverlässige Zustellung, Transaktionsverwaltung) X
Weiterleitung X
Extrahieren, Umwandeln und Laden X
Lange Abfrage X

Beispiel

Ein Versorgungsunternehmen verwendet Salesforce und verfügt über ein separates System, das Kundenabrechnungsinformationen enthält. Im Rahmen des Bestellprozesses müssen neue Abrechnungsaccounts im Abrechnungssystem erstellt werden und Salesforce sollte die Abrechnungsaccountnummer im Rahmen des Auftragsaktivierungsprozesses berücksichtigen. Sie verfügen über einen vorhandenen Webservice, der die Erstellung eines Abrechnungsaccounts ermöglicht und die Abrechnungsaccountnummer als Antwort zurückgibt.

Diese Anforderung kann mit folgendem Ansatz gelöst werden.

  1. Salesforce verwendet die Abrechnungsaccount-Service-WSDL aus einer Apex Proxy-Klasse.
  2. Führen Sie die Apex Proxy-Klasse mit den Kundeninformationen aus, die über ein benutzerdefiniertes Apex-Steuerfeld oder einen externen Service an den externen Webservice übergeben werden.
  3. Anschließend analysiert das benutzerdefinierte Steuerfeld die Rückgabewerte aus dem Apex Callout und speichert diese Informationen im Salesforce-Objekt.

In diesem Beispiel wird Folgendes veranschaulicht:

  • Der Status des Kunden wird mit einer Accountnummer verfolgt, die im Salesforce-Accountobjekt gespeichert ist.
  • Nachfolgende Verarbeitung der Antwortnachricht durch den Anrufer

Context

Sie verwenden Salesforce, um Leads zu verfolgen, Ihre Pipeline zu verwalten, Opportunities zu erstellen und Auftragsdetails zu erfassen, die Leads in Kunden konvertieren. Im Rahmen der Auftragsverwaltungsprozesse muss jedoch ein Abrechnungskonto im Abrechnungssystem für den Auftrag erstellt werden.

Wenn Sie dieses Muster implementieren, ruft Salesforce das Remote-System auf, um den Abrechnungsaccount zu erstellen, wartet jedoch nicht auf den erfolgreichen Abschluss des Anrufs. Das Remote-System kann Salesforce optional mit dem neuen Abrechnungsaccount aktualisieren, der in einer separaten Transaktion erstellt wurde.

Problem

Wie initiieren Sie bei einem Ereignis in Salesforce einen Prozess in einem Remote-System und übergeben die erforderlichen Informationen an diesen Prozess, ohne auf eine Antwort des Remote-Systems zu warten?

Kräfte

Beachten Sie beim Anwenden von Lösungen, die auf diesem Muster basieren, die folgenden Kräfte.

  • Muss Salesforce für den Aufruf des Remote-Systems auf eine Antwort warten, bevor die Verarbeitung fortgesetzt wird? Ist der Anruf an das Remote-System synchron oder asynchron?
  • Wenn der Anruf an das Remote-System synchron ist, muss die Antwort von Salesforce als Teil derselben Transaktion wie der Anruf verarbeitet werden?
  • Ist die Nachrichtengröße klein?
  • Basiert die Integration auf dem Auftreten eines bestimmten Ereignisses, beispielsweise eines Schaltflächenklicks auf der Salesforce-Benutzeroberfläche oder DML-basierter Ereignisse?
  • Ist die garantierte Nachrichtenzustellung von Salesforce an das Remote-System eine Anforderung?
  • Kann das Remote-System an einer Integration vom Typ "Vertrag zuerst" teilnehmen, in der Salesforce den Vertrag angibt? In einigen Lösungsvarianten (z. B. ausgehende Nachrichten) gibt Salesforce einen Vertrag an, den der Remote-Systemendpunkt implementiert.
  • Unterstützt der Endpunkt oder der Enterprise Service Bus (ESB) lange Abfragen?
  • Werden deklarative Konfigurationsmethoden der benutzerdefinierten Apex Entwicklung vorgezogen? In diesem Fall werden Lösungen wie Plattformereignisse Apex Callouts vorgezogen.

Lösung

Die folgende Tabelle enthält Lösungen für dieses Integrationsproblem.

Lösung Fit Kommentare
Flow-gesteuerte Plattformereignisse Best Erstellen Sie Flows deklarativ, um Plattformereignisse zu implementieren. Die empfohlene Lösung besteht darin, dass der Remote-Prozess über ein Einfüge- oder Aktualisierungsereignis aufgerufen wird.

Plattformereignisse sind die Ereignisnachrichten (oder Benachrichtigungen), die Ihre Anwendungen senden und empfangen, um weitere Maßnahmen zu ergreifen. Plattformereignisse vereinfachen das Kommunizieren von Änderungen und das Reagieren darauf, ohne komplexe Logik schreiben zu müssen. Ein oder mehrere Abonnenten können dasselbe Ereignis anhören und Aktionen ausführen.

Beispielsweise kann ein Softwaresystem Ereignisse senden, die Informationen zu Druckertintenpatronen enthalten. Abonnenten können die Ereignisse abonnieren, um den Druckertintenstand zu überwachen und Aufträge zu erteilen, um Kartuschen mit niedrigem Tintenstand zu ersetzen.

Externe Anwendungen können Ereignismeldungen anhören, indem sie einen Kanal über CometD abonnieren. Plattformanwendungen wie Lightning-Komponenten können Ereignismeldungen auch mit CometD abonnieren. Hier kann auch die Salesforce PubSub-Api verwendet werden, die auf gRPC und HTTP/2 basiert.

Salesforce unterstützt auch durch Plattformereignisse ausgelöste Flows, wodurch die Erstellung eines Listeners über die Flow Builder-Schnittstelle effektiv möglich ist. Dieser Flow-Typ wird automatisch gestartet, wenn eine bestimmte Plattformereignismeldung im Salesforce-Ereignis-Bus veröffentlicht wird.
Pub/Sub-API Best Die Pub/Sub-API ist die empfohlene Möglichkeit für externe Verbraucher, die Ereignisse im Ereignis-Bus zu nutzen.

Die gRPC-basierte Pub/Sub-API:
  • Unterstützt die Veröffentlichung und das Abonnieren von Plattformereignissen aus externen Anwendungen
  • Ist bei ordnungsgemäßer Authentifizierung (OAuth-, JWT- oder Sitzungstoken) verfügbar

Sobald ein Plattformereignis in Salesforce definiert ist, wird es für interne und externe Verbraucher verfügbar.
Datenerfassung ändern Best Die Datenerfassung für Änderungen veröffentlicht Ereignisse für Änderungen in Salesforce-Datensätzen, die dem Erstellen, Aktualisieren, Löschen und Rückgängigmachen von Vorgängen entsprechen. Die Aktivierung der Datenerfassung für Änderungen in Salesforce ist ein rein deklarativer Prozess, für den kein Apex Code erforderlich ist.

Benachrichtigungsmeldungen werden an den Ereignis-Bus gesendet, den Clients über die Pub/Sub API oder Apex Auslöser abonnieren können. Ereignisgesteuerte Systeme optimieren die Kommunikation zwischen verteilten Unternehmenssystemen, erhöhen die Skalierbarkeit und stellen Echtzeitdaten bereit.

Wenn sich Auftragsinformationen beispielsweise in Ihrem ERP-System und Salesforce befinden, können Sie Auftragsänderungsereignisse von Salesforce an eine Integrationsanwendung streamen. Die Anwendung synchronisiert dann die Änderungen im ERP-System.
OmniStudio-Integrationsverfahren Gut Verwenden Sie OmniStudio-Integrationsverfahren, um Dateninteraktionen zwischen Salesforce und externen Drittanbieteranwendungen deklarativ zu automatisieren. Integrationsverfahren verarbeiten komplexe Datentransformationen, API-Aufrufe und ereignisgesteuerte Automatisierungen und können mehrere Aktionen in einem einzelnen Serveraufruf ausführen.

Verwenden Sie Integrationsverfahren, wenn während der Ausführung keine Benutzerinteraktion erforderlich ist und Sie:
  • Abrufen, Umwandeln und Senden von Daten zwischen Salesforce und externen Systemen
  • Verarbeiten auf den Server zum Verbessern der Leistung und Skalierbarkeit
  • Bündeln mehrerer Vorgänge in einer einzelnen Servertransaktion
  • Aktivieren der Datenzwischenspeicherung für häufig aufgerufene Informationen

Weitere Details zu Integrationsverfahren finden Sie hier.
Anpassungsgesteuerte Plattformereignisse Gut Ähnlich wie bei Flow-gesteuerten Plattformereignissen werden die Ereignisse jedoch durch Apex-Auslöser oder -Klassen erstellt. Sie können Plattformereignisse mithilfe von Apex oder einer API veröffentlichen und verwenden.

Plattformereignisse können über Apex-Auslöser in die Salesforce Platform integriert werden. Auslöser sind die Ereignisverbraucher auf der Salesforce Platform, die Ereignismeldungen anhören.

Wenn eine externe Anwendung die API oder eine native Salesforce-Anwendung Apex zum Veröffentlichen der Ereignismeldung verwendet, wird ein Auslöser für dieses Ereignis ausgelöst. Auslöser führen die Aktionen als Reaktion auf die Ereignisbenachrichtigungen aus.
Flow-gesteuertes ausgehendes Messaging Fit Die empfohlene Lösung für diesen Integrationstyp besteht darin, dass der Remote-Prozess über ein Einfüge- oder Aktualisierungsereignis aufgerufen wird. Salesforce bietet eine Flow-gesteuerte Funktion für ausgehende Nachrichten, mit der SOAP-Nachrichten an Remote-Systeme gesendet werden können, die durch einen Einfüge- oder Aktualisierungsvorgang in Salesforce ausgelöst werden. Diese Nachrichten werden asynchron gesendet und sind unabhängig von der Salesforce-Benutzeroberfläche.

Die ausgehende Nachricht wird an einen bestimmten Remote-Endpunkt gesendet. Der Remote-Service muss an einer Integration vom Typ "Vertrag zuerst" teilnehmen können, bei der Salesforce den Vertrag bereitstellt.

Wenn der Remote-Service nach Erhalt der Nachricht nicht mit einer positiven Bestätigung antwortet, versucht Salesforce erneut, die Nachricht zu senden, wobei eine Form der garantierten Zustellung angegeben wird.
Benutzerdefinierte Lightning-Komponente, die einen asynchronen Apex SOAP- oder HTTP-Callout initiiert Suboptimal Diese Lösung wird in der Regel in auf der Benutzeroberfläche basierenden Szenarien verwendet, muss jedoch angepasst werden. Darüber hinaus muss die Lösung die garantierte Zustellung der Nachricht im Code verarbeiten.

Ähnlich der Lösung für den Remote-Prozessaufruf: Anforderungs- und Antwortmusterlösung, die die Verwendung einer Lightning-Komponente zusammen mit einem Apex-Callout angibt. Der Unterschied besteht darin, dass Salesforce bei diesem Muster nicht auf den Abschluss der Anforderung wartet, bevor die Kontrolle an den Benutzer übergeben wird.

Nach Erhalt der Nachricht antwortet das Remote-System und gibt den Empfang der Nachricht an. Anschließend wird die Nachricht asynchron verarbeitet. Das Remote-System überträgt die Steuerung wieder an Salesforce, bevor es mit der Verarbeitung der Nachricht beginnt. Salesforce muss daher nicht auf den Abschluss der Verarbeitung warten.
Apex Triggers to make Apex SOAP or HTTP asynchronous callout (Apex löst asynchronen Callout aus) Suboptimal Sie können Apex-Auslöser verwenden, um eine Automatisierung anhand von Datensatzdatenänderungen durchzuführen.

Eine Apex Proxy-Klasse kann als Ergebnis eines DML-Vorgangs mithilfe eines Apex Auslösers ausgeführt werden. Alle innerhalb des Auslöserkontexts getätigten Aufrufe müssen jedoch asynchron ausgeführt werden.

Apex Triggers to make Apex SOAP or HTTP asynchronous callout (Apex löst asynchronen Callout aus) Suboptimal Anrufe an ein Remote-System können über einen Batchauftrag ausgeführt werden. Diese Lösung ermöglicht die Batch-Remote-Prozessausführung und die Verarbeitung der Antwort vom Remote-System in Salesforce. Die Anzahl der Aufrufe für einen bestimmten Batchkontext ist jedoch begrenzt. Weitere Informationen finden Sie in der Salesforce Developer Limits and Allocations Quick Reference.

Skizze

Im folgenden Diagramm ist ein Aufruf von Salesforce an ein Remote-System dargestellt, bei dem das Erstellen oder Aktualisieren von Vorgängen für einen Datensatz den Aufruf auslöst.

Salesforce ruft Remote-System an

Diagramm herunterladen

In diesem Szenario:

  1. Ein Remote-System abonniert das Plattformereignis.
  2. Eine Aktualisierung oder Einfügung erfolgt für einen bestimmten Satz von Datensätzen in Salesforce.
  3. Ein Salesforce-Flow wird ausgelöst, wenn eine Reihe von Bedingungen erfüllt ist.
  4. Dieser Flow erstellt ein Plattformereignis.
  5. Der Remote-Listener empfängt die Ereignismeldung und stellt sie in eine lokale Warteschlange.
  6. Die Warteschlangenanwendung leitet die Nachricht zur Verarbeitung an die Remote-Anwendung weiter.

Wenn das Remote-System Vorgänge für Salesforce ausführen muss, können Sie einen optionalen Rückmeldungsvorgang implementieren.

Ergebnisse

Die Anwendung der mit diesem Muster verbundenen Lösungen ermöglicht Folgendes:

  • Benutzeroberflächeninitiierte Remote-Prozessaufrufe, bei denen das Ergebnis der Transaktion dem Endbenutzer angezeigt werden kann
  • DML-Ereignis initiierte Remote-Prozessaufrufe, in denen das Ergebnis der Transaktion durch den aufrufenden Prozess verarbeitet werden kann

Anrufmechanismen

Der Aufrufmechanismus hängt von der Lösung ab, die zur Implementierung dieses Musters ausgewählt wurde.

Anrufmechanismus Beschreibung
Flow Wird sowohl von der prozess- als auch von der benutzerdefinierten Lösung verwendet. Ereignisse lösen den Salesforce-Prozess aus, der dann ein Plattformereignis für ein Remote-System zum Abonnement veröffentlichen kann.
Pub / Sub API Die Pub/Sub-API bietet eine einzige Oberfläche für die Veröffentlichung und Abonnierung von Plattformereignissen, einschließlich Ereignissen der Echtzeit-Ereignisüberwachung und Ereignissen der Datenerfassung. Basierend auf gRPC und HTTP/2 veröffentlicht und stellt die Pub/Sub-API Binärereignisnachrichten im Apache Avro-Format effizient bereit.
Datenerfassung ändern Die Salesforce Change Datenerfassung veröffentlicht Änderungsereignisse, die Änderungen an Salesforce-Datensätzen darstellen. 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.
Lightning-Komponenten- und Apex-Steuerfelder Wird verwendet, um einen Remote-Prozess mithilfe eines Apex Callouts asynchron aufzurufen.
Flow-gesteuertes ausgehendes Messaging Wird nur für die ausgehende Messaging-Lösung verwendet. "DML-Ereignisse erstellen und aktualisieren" löst die Salesforce-Workflow-Regeln aus, die dann eine Nachricht an ein Remote-System senden können.
Apex Auslöser Wird für auslösergesteuerte Plattformereignisse und den Aufruf von Remote-Prozessen mithilfe von Apex Callouts aus DML-initiierten Ereignissen verwendet.
Apex Batchklassen Wird zum Aufrufen von Remote-Prozessen im Batch-Modus verwendet.

Fehlerbehandlung und -behebung

Eine Fehlerbehandlungs- und -behebungsstrategie muss als Teil der Gesamtlösung betrachtet werden. Die beste Methode hängt von der von Ihnen ausgewählten Lösung ab.

Lösung Strategie zur Fehlerbehandlung und -behebung
Flow
  • Fehlerbehandlung: Unter bestimmten Bedingungen können Flows nicht vollständig verarbeitet werden. Wenn bei einem Prozess oder Flow-Interview ein Fehler auftritt, wird eine detaillierte E-Mail an den Administrator gesendet, der den Prozess oder Flow zuletzt geändert hat. Ändern Sie das Standardverhalten, indem Sie allen Elementen Fehlerpfade hinzufügen, die fehlschlagen können. Dieses Verhalten sollte verbessert werden, um benutzerdefiniertes Verhalten einzufügen, beispielsweise das Erstellen eines Kundenvorgangs oder das Schreiben von Fehlern in ein benutzerdefiniertes Objekt, das überwacht und verfolgt werden kann.
  • Wiederherstellung: Die Wiederherstellung ist in diesem Szenario komplexer. Es muss ein benutzerdefinierter Mechanismus für Wiederholungen erstellt werden, wenn dies aufgrund der Anforderungen an die Servicequalität erforderlich ist.
Apex Callouts
  • Fehlerbehandlung: Das Remote-System gibt den Aufruf des Endprozesses weiter, sodass der Callout nur Ausnahmen beim ersten Aufruf des Remote-Service verarbeitet. Beispielsweise wird ein Zeitüberschreitungsereignis ausgelöst, wenn keine positive Bestätigung vom Remote-Callout empfangen wird. Das Remote-System muss nachfolgende Fehler verarbeiten, wenn der ursprüngliche Aufruf zur asynchronen Verarbeitung weitergegeben wird.
  • Wiederherstellung: Die Wiederherstellung ist in diesem Szenario komplexer. Es muss ein benutzerdefinierter Mechanismus für Wiederholungen erstellt werden, wenn dies aufgrund der Anforderungen an die Servicequalität erforderlich ist.
Datenerfassung ändern / Plattformereignisse
  • Fehlerbehandlung: Die Fehlerbehandlung muss vom Remote-Service durchgeführt werden, da das Ereignis effektiv zur weiteren Verarbeitung an das Remote-System übergeben wird. Da dieses Muster asynchron ist, übernimmt das Remote-System die Warteschlangen-, Verarbeitungs- und Fehlerbehandlung für Nachrichten. Darüber hinaus werden Plattformereignisse nicht in Datenbanktransaktionen verarbeitet. Daher können veröffentlichte Plattformereignisse nicht innerhalb einer Transaktion zurückgesetzt werden.
  • Wiederherstellung: Da dieses Muster asynchron ist, muss das Remote-System Wiederholungen basierend auf den Servicequalitätsanforderungen initiieren. Die jedem Ereignis zugeordnete ID für die erneute Wiedergabe ist atomar und erhöht sich mit jedem veröffentlichten Ereignis. Diese ID kann verwendet werden, um den Stream aus einem bestimmten Ereignis erneut wiederzugeben (beispielsweise basierend auf dem zuletzt erfolgreich erfassten Ereignis). Plattformereignisnachrichten mit hohem Volumen werden 72 Stunden (drei Tage) lang gespeichert. Sie können vergangene Ereignismeldungen abrufen, wenn Sie CometD-Clients verwenden, um einen Kanal zu abonnieren.

Überlegungen zum idempotenten Design

Plattformereignisse werden nur einmal im Bus veröffentlicht. Auf Salesforce-Seite wird kein erneuter Versuch unternommen. Es ist Sache des ESB, die Wiederholung der Ereignisse zu beantragen. Bei einer erneuten Wiedergabe bleibt die ID des Plattformereignisses gleich und der ESB kann doppelte Nachrichten anhand der ID der erneuten Wiedergabe versuchen.

Identität ist für ausgehende Nachrichten wichtig, da sie asynchron ist und Wiederholungen initiiert werden, wenn keine positive Bestätigung eingeht. Daher muss der Remote-Service in der Lage sein, Nachrichten von Salesforce idempotent zu verarbeiten.

Ausgehende Nachrichten senden eine eindeutige ID pro Nachricht und diese ID bleibt bei Wiederholungen gleich. Das Remote-System kann doppelte Nachrichten anhand dieser eindeutigen ID verfolgen. Die eindeutige Datensatz-ID für jeden zu aktualisierenden Datensatz wird ebenfalls gesendet und kann verwendet werden, um die Erstellung doppelter Datensätze zu verhindern.

Die Überlegungen zum idempotenten Design im Muster "Remote Process Invocation – Request and Reply" (Remote-Prozessaufruf – Anforderung und Antwort) gelten auch für dieses Muster.

Sicherheitsüberlegungen

Bei jedem Anruf an ein Remote-System müssen die Vertraulichkeit, Integrität und Verfügbarkeit der Anforderung gewahrt bleiben. Je nach der von Ihnen ausgewählten Lösung gelten unterschiedliche Sicherheitsüberlegungen.

Lösung Sicherheitsüberlegungen
Apex Callouts Ein Anruf an ein Remote-System muss die Vertraulichkeit, Integrität und Verfügbarkeit der Anforderung wahren. Im Folgenden finden Sie Sicherheitsüberlegungen, die speziell für die Verwendung von Apex SOAP und HTTP-Aufrufen in diesem Muster gelten.
  • Einweg-SSL ist standardmäßig aktiviert, aber bidirektionales SSL wird sowohl mit selbstsignierten als auch mit von einer Zertifizierungsstelle signierten Zertifikaten unterstützt, um die Authentizität von Client und Server aufrechtzuerhalten.
  • Salesforce unterstützt WS-Security beim Generieren der Apex Proxy-Klasse nicht.
  • Verwenden Sie bei Bedarf Einweg-Hashes oder digitale Signaturen mithilfe der Apex Crypto-Klassenmethoden, um die Integrität der Anforderung sicherzustellen.
  • Das Remote-System muss durch Implementierung der entsprechenden Firewall-Mechanismen geschützt werden.
Datenerfassung ändern / Plattformereignisse Bei Plattformereignissen muss sich das abonnierende externe System bei der Salesforce Streaming-API authentifizieren können.

Plattformereignisse entsprechen dem vorhandenen Sicherheitsmodell, das in der Salesforce-Organisation konfiguriert ist. Zum Abonnieren eines Ereignisses benötigt der Benutzer Lesezugriff auf die Ereigniseinheit. Zum Veröffentlichen eines Ereignisses benötigt der Benutzer die Berechtigung "Erstellen" für die Ereigniseinheit.

Siehe Sicherheitsüberlegungen.

Randleisten

Keine.

Pünktlichkeit

Aktualität ist beim Muster "Feuer und Vergessen" weniger wichtig. Die Kontrolle wird entweder sofort oder nach positiver Bestätigung einer erfolgreichen Übergabe an das Remote-System an den Client zurückgegeben. Bei ausgehenden Salesforce-Nachrichten muss die Bestätigung innerhalb von 24 Stunden erfolgen (dies kann auf sieben Tage verlängert werden). Andernfalls läuft die Nachricht ab. Bei Plattformereignissen sendet Salesforce die Ereignisse an den Ereignis-Bus und wartet nicht auf eine Bestätigung oder Bestätigung des Abonnenten. Wenn der Abonnent die Nachricht nicht entgegennimmt, kann er anfordern, das Ereignis mithilfe der Ereignisantwort-ID erneut wiederzugeben. Ereignismeldungen mit hohem Volumen werden 72 Stunden (drei Tage) lang gespeichert. Verwenden Sie CometD-Clients, um einen Kanal zu abonnieren, um vergangene Ereignismeldungen abzurufen.

Datenvolumen

Die Überlegungen zum Datenvolumen hängen davon ab, welche Lösung Sie auswählen. Informationen zu den Obergrenzen der einzelnen Lösungen finden Sie in der Salesforce Limits-Schnellreferenz.

Unterstützung von Endpunktfunktionen und Standards

Die Funktionen und die Standardunterstützung für den Endpunkt hängen von der von Ihnen ausgewählten Lösung ab.

Lösung Überlegungen zu Endpunkten
Apex SOAP-Callouts Der Endpunkt muss einen Webserviceaufruf über HTTP verarbeiten können. Salesforce muss über das öffentliche Internet auf den Endpunkt zugreifen können. Für diese Lösung muss das Remote-System mit den von Salesforce unterstützten Standards kompatibel sein. Zum Zeitpunkt des Schreibens wurden von Salesforce für Apex SOAP-Callouts folgende Webservicestandards unterstützt:
  • WSDL 1.1
  • SOAP 1.1
  • WSI-Basisprofil 1.1
  • HTTP
Apex HTTP-Callouts Der Endpunkt muss HTTP-Aufrufe empfangen und über das öffentliche Internet von Salesforce aufgerufen werden können.

Apex HTTP-Callouts können zum Aufrufen von RESTful-Services mit den Standardmethoden GET, POST, PUT und DELETE verwendet werden.
Datenerfassung ändern / Plattformereignisse
  • Auslöser, Prozesse und Flows können Ereignisse abonnieren. Sie können Ereignisbenachrichtigungen erhalten, unabhängig davon, wie sie veröffentlicht wurden.
  • Verwenden Sie CometD, um Plattformereignisse eines externen Clients zu abonnieren. Implementieren Sie Ihren eigenen CometD-Client oder verwenden Sie den EMP-Konnektor, ein Open-Source-Tool, das von der Community unterstützt wird und alle Details zur Verbindung mit CometD und zum Anhören in einem Kanal implementiert. Salesforce sendet Plattformereignisse nacheinander in der Reihenfolge ihres Eingangs an CometD-Clients. Die Reihenfolge der Ereignisbenachrichtigungen basiert auf der ID der Ereignisse für die erneute Wiedergabe.

Statusverwaltung

Bei der Integration von Systemen sind eindeutige Datensatzkennzeichner für die fortlaufende Statusverfolgung wichtig. Wenn beispielsweise ein Datensatz im Remote-System erstellt wird, haben Sie zwei Möglichkeiten.

  • Salesforce speichert den primären oder eindeutigen Ersatzschlüssel des Remote-Systems für den Remote-Datensatz.
  • Das Remote-System speichert die eindeutige Salesforce-Datensatz-ID oder einen anderen eindeutigen Ersatzschlüssel.

In der folgenden Tabelle sind die Überlegungen zur Bundesstaatsverwaltung in diesem Muster aufgeführt.

Master System Beschreibung
Salesforce Das Remote-System muss entweder die Salesforce RecordId oder einen anderen eindeutigen Ersatzschlüssel im Salesforce-Datensatz speichern.
Remote-System Salesforce muss einen Verweis auf die eindeutige Kennung im Remote-System speichern. Da der Prozess asynchron ist, kann das Speichern dieser eindeutigen Kennung nicht Teil der ursprünglichen Transaktion sein.

Salesforce muss im Aufruf des Remote-Prozesses eine eindeutige ID angeben. Das Remote-System muss dann zu Salesforce zurückrufen, um den Datensatz in Salesforce mit der eindeutigen Kennung des Remote-Systems und der eindeutigen Salesforce-ID zu aktualisieren.

Die Rückmeldung impliziert die Verarbeitung eines bestimmten Status in der Remote-Anwendung, um die eindeutige Salesforce-Kennung für diese Transaktion zu speichern, die nach Abschluss der Verarbeitung für die Rückmeldung verwendet werden soll, oder die eindeutige Salesforce-Kennung wird im Datensatz des Remote-Systems gespeichert.

Komplexe Integrationsszenarien

Jede Lösung in diesem Muster hat unterschiedliche Überlegungen für komplexe Integrationsszenarien wie Transformation und Prozessorchestrierung.

Lösung Überlegungen
Apex Callouts In bestimmten Fällen müssen für nach diesem Muster vorgeschriebene Lösungen mehrere komplexe Integrationsszenarien implementiert werden, die am besten mit Middleware bereitgestellt werden oder Salesforce einen zusammengesetzten Service aufrufen lassen. Zu diesen Szenarien zählen:
  • Orchestrierung von Geschäftsprozessen und Regeln mit komplexer Flow-Logik
  • Aggregation von Anrufen und deren Ergebnissen über mehrere Systeme hinweg
  • Transformation von eingehenden und ausgehenden Nachrichten
  • Aufrechterhalten der transaktionalen Integrität über mehrere Aufrufe hinweg
Datenerfassung ändern / Plattformereignisse Da Ereignisse statisch und deklarativ sind, können in Salesforce keine komplexen Integrationsszenarien wie Aggregation, Orchestrierung oder Transformation ausgeführt werden. Das Remote-System oder die Middleware muss diese Vorgangstypen verarbeiten.
OmniStudio-Integrationsverfahren Integrationsverfahren (OmniStudio) bieten serverseitige Orchestrierung ohne Status, um mehrere Backend-Services zu koordinieren und gleichzeitig komplexe deklarative Datentransformationen durchzuführen.

Integrationsverfahren verketten Schritte wie HTTP-Aktionen, DataRaptor-Extraktion/-Umwandlung/Last, Werte festlegen, Schleife/Wenn und Matrix-Nachschlagevorgänge, um Nutzlasten zwischen Benutzeroberflächenverträgen und verschiedenen APIs zu normalisieren, anzureichern, zu aggregieren und zuzuordnen.

Sie unterstützen robuste Laufzeitsteuerungen wie bedingte Verzweigungen, Paginierung, Zeitüberschreitungen, Wiederholungen, die Verarbeitung von Teilfehlern und die Fortsetzung von Fehlern sowie Leistungsoptimierungen wie die serverseitige Zwischenspeicherung und die Antwortformung.

IPs können synchron über OmniScripts oder Headless über REST aufgerufen werden, wodurch wiederverwendbare versionierte "Integrationsfassaden" ermöglicht werden, die Backend-Komplexität vor Kanälen verbergen.

Obergrenzen

Aufgrund des mandantenfähigen Charakters der Salesforce Platform gelten Einschränkungen für ausgehende Callouts. Die Obergrenzen hängen vom Typ des ausgehenden Anrufs und dem Zeitpunkt des Anrufs ab.

Obergrenzen und Zuteilungen für Plattformereignisse finden Sie im Platforms Events Developer Guide.

Zuverlässiges Messaging

Zuverlässiges Messaging versucht, das Problem der Gewährleistung der Zustellung einer Nachricht an ein Remote-System zu lösen, bei dem die einzelnen Komponenten unzuverlässig sind. Die Methode zum Sicherstellen des Empfangs einer Nachricht durch das Remote-System hängt von der von Ihnen ausgewählten Lösung ab.

Im Falle von Salesforce Change-Datenerfassung werden Änderungsereignistypen bereitgestellt, um spezielle Situationen zu bewältigen, beispielsweise das Erfassen von Änderungen, die nicht auf den Salesforce-Anwendungsservern erfasst wurden, oder das Verarbeiten einer großen Anzahl von Änderungen.

In einigen Fällen sendet Salesforce anstelle von Änderungsereignissen Lückenereignisse, um Abonnenten über Fehler zu informieren oder wenn es nicht möglich ist, Änderungsereignisse zu generieren. Ein Lückenereignis enthält Informationen über die Änderung in der Kopfzeile, beispielsweise den Änderungstyp und die Datensatz-ID. Sie enthält keine Details zur Änderung, beispielsweise Datensatzfelder. Überlaufereignisse werden für einzelne Transaktionen generiert, die einen Schwellenwert überschreiten, um Änderungen effizienter zu erfassen. Weitere Informationen finden Sie hier.

Lösung Überlegungen zu zuverlässigem Messaging
Apex Callouts Salesforce bietet keine explizite Unterstützung für zuverlässige Messaging-Protokolle (z. B. WS-ReliableMessaging). Es wird empfohlen, dass der Remote-Endpunkt, der die Salesforce-Nachricht empfängt, ein zuverlässiges Messaging-System wie JMS oder MQ implementiert. Dieses System gewährleistet die vollständige durchgängige garantierte Zustellung an das Remote-System, das die Nachricht letztlich verarbeitet. Dieses System stellt jedoch keine garantierte Zustellung von Salesforce an den Remote-Endpunkt sicher, den es anruft.

Die garantierte Zustellung muss über Anpassungen an Salesforce abgewickelt werden. Es müssen bestimmte Techniken implementiert werden, beispielsweise die Verarbeitung einer positiven Bestätigung vom Remote-Endpunkt zusätzlich zur benutzerdefinierten Wiederholungslogik.
Datenerfassung ändern / Plattformereignisse Plattformereignisse versuchen, zuverlässige Nachrichten bereitzustellen, indem Ereignismeldungen vorübergehend im Ereignis-Bus beibehalten werden. Abonnenten können verpasste Ereignismeldungen nachholen, indem sie Nachrichten aus dem Ereignis-Bus mithilfe der ID der Ereignismeldungen erneut wiedergeben.

Der Ereignis-Bus ist ein verteiltes System und weist nicht dieselben Garantien wie eine Transaktionsdatenbank auf. Daher kann Salesforce keine synchrone Antwort für eine Ereignisveröffentlichungsanforderung bereitstellen. Ereignisse werden in die Warteschlange gestellt und zwischengespeichert und Salesforce versucht, die Ereignisse asynchron zu veröffentlichen. In seltenen Fällen wird die Ereignismeldung während der ersten oder nachfolgenden Versuche möglicherweise nicht im verteilten System beibehalten. Das bedeutet, dass die Ereignisse nicht an Abonnenten zugestellt werden und nicht wiederhergestellt werden können.

Middleware-Funktionen

In der folgenden Tabelle werden die wünschenswerten Eigenschaften eines Middleware-Systems hervorgehoben, das an diesem Muster teilnimmt.

Eigenschaft Obligatorisch Wünschenswert Nicht erforderlich
Ereignisverarbeitung X
Protokollkonvertierung X
Übersetzung und Transformation X
Warteschlange und Pufferung X
Synchrone Transportprotokolle X
Asynchrone Transportprotokolle X
Vermittlungsweiterleitung X
Prozesschoreografie und Serviceorchestrierung X
Transaktionalität (Verschlüsselung, Signieren, zuverlässige Zustellung, Transaktionsverwaltung) X
Weiterleitung X
Extrahieren, Umwandeln und Laden X
Lange Abfrage X (erforderlich für Plattformereignisse)

Lösungsvariante – Plattformereignisse: Veröffentlichungsverhalten und Transaktionen

Wenn Plattformereignisnachrichten sofort veröffentlicht werden, werden bei der Ereignisveröffentlichung die Transaktionsgrenzen des Veröffentlichungsprozesses nicht berücksichtigt. Ereignismeldungen können veröffentlicht werden, bevor die Transaktion abgeschlossen wird oder selbst wenn eine Transaktion fehlschlägt. Dieses Verhalten kann zu Problemen führen, wenn ein Abonnent erwartet, Daten zu finden, die von der Veröffentlichungstransaktion übernommen werden. Die Daten sind möglicherweise nicht vorhanden, wenn der Abonnent die Ereignismeldung erhält. Legen Sie zum Lösen dieses Problems das Veröffentlichungsverhalten von Plattformereignissen in der Ereignisdefinition auf Nach Commit veröffentlichen fest. Die Veröffentlichungsverhaltensweisen, die Sie in einer Plattformereignisdefinition festlegen können, lauten:

  • Nach Commit veröffentlichen, damit die Ereignismeldung erst veröffentlicht wird, nachdem eine Transaktion erfolgreich übernommen wurde. Wählen Sie diese Option aus, wenn Abonnenten auf Daten angewiesen sind, die von der Veröffentlichungstransaktion übernommen werden. Beispielsweise veröffentlicht ein Prozess eine Ereignismeldung und erstellt einen Aufgabendatensatz. Ein zweiter Prozess, der das Ereignis abonniert hat, wird ausgelöst und erwartet, dass der Aufgabendatensatz gefunden wird. Ein weiterer Grund für die Auswahl dieses Verhaltens ist, dass die Ereignismeldung nicht veröffentlicht werden soll, wenn die Transaktion fehlschlägt.
  • Sofort veröffentlichen, damit die Ereignismeldung veröffentlicht wird, wenn der Veröffentlichungsaufruf ausgeführt wird. Wählen Sie diese Option aus, wenn die Ereignismeldung unabhängig davon veröffentlicht werden soll, ob die Transaktion erfolgreich ist. Wählen Sie diese Option auch aus, wenn der Herausgeber und die Abonnenten unabhängig sind und die Abonnenten nicht auf die vom Herausgeber übernommenen Daten angewiesen sind. Beispielsweise eignet sich das sofortige Veröffentlichungsverhalten für ein Ereignis, das zu Protokollierungszwecken verwendet wird. Mit dieser Option erhält ein Abonnent möglicherweise die Ereignismeldung, bevor Daten durch die Publisher-Transaktion übernommen werden.

Beispiel

Ein Telekommunikationsunternehmen möchte Salesforce als Front-End für die Erstellung von Accounts im Lead-to-Opportunity-Prozess verwenden. Ein Auftrag wird in Salesforce erstellt, wenn die Opportunity geschlossen und gewonnen wurde, das Backend-ERP-System jedoch der Datenmaster ist. Der Auftrag muss im Salesforce-Opportunity-Datensatz gespeichert und der Opportunity-Status geändert werden, um anzugeben, dass der Auftrag erstellt wurde.

Folgende Einschränkungen gelten.

  • Nur deklarative Entwicklung kann implementiert werden.
  • Sie müssen die Auftragsnummer nicht sofort benachrichtigen, nachdem die Opportunity in einen Auftrag konvertiert wurde.
  • Die Organisation verfügt über einen ESB, der das CometD-Protokoll unterstützt und Plattformereignisse abonnieren kann.

Dieses Beispiel lässt sich am besten mithilfe von Salesforce Platform-Ereignissen implementieren, erfordert jedoch, dass der ESB das Plattformereignis abonniert.

Salesforce-seitig:

  • Erstellen Sie einen Flow, um das Plattformereignis zu initiieren (beispielsweise wenn der Opportunity-Status zu "Geschlossen und gewonnen" geändert wird).
  • Erstellen Sie ein neues Plattformereignis, das die Opportunity-Details veröffentlicht.

Auf der Remote-Systemseite:

  • Der ESB abonniert das Salesforce Platform-Ereignis mithilfe des CometD-Protokolls.
  • Der ESB erhält eine oder mehrere Benachrichtigungen, die angeben, dass die Opportunity in einen Auftrag konvertiert werden soll.
  • Der ESB leitet die Nachricht an das Backend-ERP-System weiter, damit der Auftrag erstellt werden kann.
  • Nachdem der Auftrag im ERP-System erstellt wurde, wird ein separater Thread mit der SessionId als Authentifizierungstoken zu Salesforce zurückgerufen. Die Rückmeldung aktualisiert die Opportunity mit der Auftragsnummer und dem Status. Sie können diese Rückmeldung mit dokumentierten Musterlösungen wie Salesforce Platform-Ereignissen, der Salesforce SOAP-API, der REST-API oder einem Apex Webservice vornehmen.

In diesem Beispiel wird Folgendes veranschaulicht.

  • Implementierung eines asynchron aufgerufenen Remote-Prozesses
  • Durchgängig garantierte Zustellung
  • Nachfolgende Rückmeldung an Salesforce zum Aktualisieren des Datensatzstatus

Context

Sie verschieben Ihre CRM-Implementierung zu Salesforce und möchten:

  • Extrahieren und transformieren Sie Accounts, Kontakte und Opportunities aus dem aktuellen CRM-System und laden Sie die Daten in Salesforce (Anfangsdatenimport).
  • Extrahieren, transformieren und laden Sie Kundenabrechnungsdaten wöchentlich (laufend) aus einem Remote-System in Salesforce.
  • Extrahieren Sie Informationen zur Kundenaktivität aus Salesforce und importieren Sie sie wöchentlich (laufend) in ein lokales Data Warehouse.

Problem

Wie importieren Sie Daten in Salesforce und exportieren Daten aus Salesforce, da diese Importe und Exporte die Vorgänge der Endbenutzer während der Geschäftszeiten beeinträchtigen und große Datenmengen beinhalten können?

Kräfte

Beim Anwenden von Lösungen auf der Grundlage dieses Musters sind verschiedene Kräfte zu berücksichtigen:

  • Sollen die Daten in Salesforce gespeichert werden? Andernfalls gibt es andere Integrationsoptionen, die ein Architekt in Betracht ziehen kann und sollte (beispielsweise Mashups).
  • Wenn die Daten in Salesforce gespeichert werden sollen, sollten die Daten als Reaktion auf ein Ereignis im Remote-System aktualisiert werden?
  • Sollen die Daten planmäßig aktualisiert werden?
  • Unterstützt die Daten primäre Geschäftsprozesse?
  • Gibt es Analyseanforderungen (Berichterstellung), die sich auf die Verfügbarkeit dieser Daten in Salesforce auswirken?

Lösung

Die folgende Tabelle enthält verschiedene Lösungen für dieses Integrationsproblem.

Lösung Fit Datenmaster Kommentare
Abgleich über das ETL-Tool eines Drittanbieters Best Remote-System Wenn ein externes System eine große Datenmenge an Salesforce senden muss, verwenden Sie ein Drittanbieter-ETL-Tool, mit dem Sie die Datenerfassung anhand von Quelldaten ausführen können.

Das Tool reagiert auf Änderungen am Quelldatenset, wandelt die Daten um und ruft dann die Salesforce Bulk-API auf, um DML-Anweisungen auszustellen. Dies kann auch mithilfe der Salesforce-REST-APIs implementiert werden, wenn die Anzahl der Datensätze geringer ist.
Abgleich über das ETL-Tool eines Drittanbieters Gut Salesforce Nutzen Sie ein Drittanbieter-ETL-Tool, mit dem Sie die Datenerfassung für Änderungen anhand von ERP- und Salesforce-Datensets ausführen können.

Bei dieser Lösung ist Salesforce die Datenquelle und Sie können Uhrzeit-/Statusinformationen in einzelnen Zeilen verwenden, um die Daten abzufragen und die Zielergebnismenge zu filtern. Dies kann mithilfe der Bulk-API 2.0 oder standardmäßiger REST-APIs (wenn die Anzahl der Datensätze geringer ist) implementiert werden.
Datenimport-Assistent und Data Loader Fit Salesforce / Externes System Der Datenimport-Assistent und Data Loader können zum Importieren, Exportieren und Migrieren von Daten verwendet werden. Data Loader-Befehle können zwar auch per Skript importiert und exportiert werden, die Befehlszeilenschnittstelle ist jedoch nur für Windows vorgesehen. Keines dieser Tools ist eine empfohlene Grundlage für eine Datenintegrationsstrategie. Stattdessen sollten sie Ihre Datenverwaltungs- und Wartungsstrategie ergänzen.

Weitere Informationen zu Data Loader finden Sie hier.
Remote-Anruf Suboptimal Remote-System Es ist möglich, dass ein Remote-System Salesforce mithilfe einer der APIs aufruft und Aktualisierungen an den Daten vornimmt. Dies führt jedoch zu einem erheblichen laufenden Datenverkehr zwischen den beiden Systemen.

Fehlerbehandlung und -sperre sollten stärker in den Vordergrund gestellt werden. Dieses Muster kann zu ständigen Aktualisierungen führen, was sich auf die Leistung der Endbenutzer auswirken kann.
Remote-Prozessaufruf Suboptimal Salesforce Salesforce kann ein Remote-System aufrufen und Aktualisierungen der Daten vornehmen, sobald sie auftreten. Dies führt jedoch zu einem erheblichen laufenden Datenverkehr zwischen den beiden Systemen.

Fehlerbehandlung und -sperre sollten stärker in den Vordergrund gestellt werden. Dieses Muster kann zu ständigen Aktualisierungen führen, was sich auf die Leistung der Endbenutzer auswirken kann.

Skizze

Das folgende Diagramm veranschaulicht die Abfolge der Ereignisse in diesem Muster, wobei Salesforce der Datenmaster ist.

Diagramm herunterladen

Das folgende Diagramm veranschaulicht die anschließende Synchronisierung von Ereignissen nahezu in Echtzeit, wobei Salesforce der Datenmaster ist.

Ergebnisse

In den folgenden Szenarien können Sie extern in Salesforce bezogene Daten integrieren:

  • Externes System ist der Datenmaster: Salesforce ist ein Verbraucher von Daten, die von einem einzelnen Quellsystem oder mehreren Systemen bereitgestellt werden. In diesem Szenario ist es üblich, über ein Data Warehouse oder einen Data Mart zu verfügen, das bzw. der die Daten aggregiert, bevor die Daten in Salesforce importiert werden.
  • Salesforce ist der Datenmaster: Salesforce ist das Datensatzsystem für bestimmte Entitäten und Client-Anwendungen der Salesforce-Datenänderungserfassung können über Änderungen an Salesforce-Daten informiert werden.

In einem typischen Salesforce-Integrationsszenario führt das Implementierungsteam eine der folgenden Aktionen aus:

  • Implementieren Sie die Datenerfassung für Änderungen im Quelldatenset.
  • Implementieren Sie eine Reihe unterstützender Datenbankstrukturen, die als Steuertabellen bezeichnet werden, in einer lokalen Zwischendatenbank.

Das ETL-Tool wird dann zum Erstellen von Programmen verwendet, die Folgendes bewirken:

  1. Lesen Sie eine Steuertabelle, um die letzte Laufzeit des Auftrags zu bestimmen, und extrahieren Sie alle anderen erforderlichen Steuerwerte.
  2. Verwenden Sie die obigen Steuerwerte als Filter und fragen Sie das Quelldatenset ab.
  3. Wenden Sie vordefinierte Verarbeitungsregeln an, einschließlich Validierung, Anreicherung usw.
  4. Verwenden Sie die verfügbaren Konnektoren/Umwandlungsfunktionen des ETL-Tools, um das Ziel-Datenset zu erstellen.
  5. Schreiben Sie das Datenset in Salesforce-Objekte.
  6. Wenn die Verarbeitung erfolgreich ist, aktualisieren Sie die Steuerwerte in der Steuertabelle.
  7. Wenn bei der Verarbeitung ein Fehler auftritt, aktualisieren Sie die Steuertabellen mit Werten, die einen Neustart und ein Beenden ermöglichen.

Notiz: Es wird empfohlen, die Steuertabellen und die zugehörigen Datenstrukturen in einer Umgebung zu erstellen, auf die das ETL-Tool Zugriff hat, selbst wenn kein Zugriff auf Salesforce verfügbar ist. Dies bietet ein angemessenes Maß an Widerstandsfähigkeit. Salesforce sollte in diesem Prozess wie eine Speiche behandelt werden und die ETL-Infrastruktur ist das Zentrum.

Damit ein ETL-Tool maximal von den Datensynchronisierungsfunktionen profitieren kann, sollten Sie Folgendes berücksichtigen:

  • Verketten und sequenzieren Sie die ETL-Aufträge, um einen zusammenhängenden Prozess bereitzustellen.
  • Verwenden Sie Primärschlüssel aus beiden Systemen, um eingehende Daten abzugleichen.
  • Verwenden Sie bestimmte API-Methoden, um nur aktualisierte Daten zu extrahieren.
  • Wenn Sie untergeordnete Datensätze in einer Master-Detail- oder Nachschlagebeziehung importieren, gruppieren Sie die importierten Daten mithilfe des übergeordneten Schlüssels an der Quelle, um eine Sperrung zu vermeiden. Wenn Sie beispielsweise Kontaktdaten importieren, gruppieren Sie die Kontaktdaten nach dem übergeordneten Accountschlüssel, damit die maximale Anzahl an Kontakten für einen einzelnen Account in einem API-Aufruf geladen werden kann. Wenn die importierten Daten nicht gruppiert werden, wird in der Regel der erste Kontaktdatensatz geladen und nachfolgende Kontaktdatensätze für diesen Account schlagen im Kontext des API-Aufrufs fehl.
  • Bei der Verarbeitung nach dem Import wie Auslösern sollten Daten nur selektiv verarbeitet werden.
  • Wenn Ihr Szenario große Datenvolumen umfasst, befolgen Sie die bewährten Vorgehensweisen aus diesem Trailhead-Modul Bewährte Vorgehensweisen für Bereitstellungen mit großen Datenvolumen
    • .

Fehlerbehandlung und -behebung

Eine Fehlerbehandlungs- und -behebungsstrategie muss als Teil der Gesamtlösung betrachtet werden. Die beste Methode hängt von der von Ihnen ausgewählten Lösung ab.

Fehlerstandort Fehlerbehandlung und -behebungsstrategie
"Lesen" aus Salesforce mithilfe der Datenerfassung ändern
  • Fehlerbehandlung: Die Fehlerbehandlung muss im Remote-Service durchgeführt werden, da das Ereignis effektiv zur weiteren Verarbeitung an das Remote-System übergeben wird. Da dieses Muster asynchron ist, übernimmt das Remote-System die Warteschlangen-, Verarbeitungs- und Fehlerbehandlung für Nachrichten. Außerdem werden Ereignisse der Datenerfassung ändern nicht in Datenbanktransaktionen verarbeitet. Daher können veröffentlichte Ereignisse nicht innerhalb einer Transaktion zurückgesetzt werden.
  • Wiederherstellung: Da dieses Muster asynchron ist, muss das Remote-System Wiederholungen basierend auf den Servicequalitätsanforderungen initiieren. Die jedem Ereignis der Datenerfassung "Ändern" zugeordnete ID für die erneute Wiedergabe ist atomar und erhöht sich mit jedem veröffentlichten Ereignis. Diese ID kann verwendet werden, um den Stream aus einem bestimmten Ereignis erneut wiederzugeben (beispielsweise basierend auf dem zuletzt erfolgreich erfassten Ereignis). Plattformereignisnachrichten mit hohem Volumen werden 72 Stunden (3 Tage) lang gespeichert. Sie können vergangene Ereignismeldungen abrufen, wenn Sie CometD-Clients verwenden, um einen Kanal zu abonnieren.
"Lesen" aus Salesforce mithilfe eines Drittanbieter-ETL-Systems
  • Fehlerbehandlung: Wenn während eines Lesevorgangs ein Fehler auftritt, implementieren Sie einen Wiederholungsversuch für Fehler, die nicht infrastrukturbezogen sind. Bei wiederholten Fehlern sollte die Standardverarbeitung mithilfe von Kontrolltabellen/Fehlertabellen im Kontext eines ETL-Vorgangs implementiert werden, um:
    • Protokollieren des Fehlers
    • Wiederholen des Lesevorgangs
    • Beenden bei Erfolg
    • Benachrichtigung senden
  • Wiederherstellung: Starten Sie den ETL-Prozess neu, um ihn nach einem fehlgeschlagenen Lesevorgang wiederherzustellen.
Wenn der Vorgang erfolgreich ist, jedoch fehlgeschlagene Datensätze vorliegen, sollte das Problem durch einen sofortigen Neustart oder eine anschließende Ausführung des Auftrags behoben werden. In diesem Fall ist ein verzögerter Neustart möglicherweise eine bessere Lösung, da er Zeit für die Triage und Korrektur von Daten bietet, die die Fehler verursachen könnten.
Schreiben in Salesforce
  • Fehlerbehandlung: Fehler, die während eines Schreibvorgangs auftreten, können auf eine Kombination von Faktoren in der Anwendung zurückzuführen sein. Die API-Aufrufe geben einen Ergebnissatz zurück, der aus den unten aufgeführten Informationen besteht. Diese Informationen sollten verwendet werden, um den Schreibvorgang (falls erforderlich) zu wiederholen.
    • Datensatz-Identifikationsinformationen
    • Erfolgs-/Fehlerbenachrichtigung
    • Eine Sammlung von Fehlern für jeden Datensatz
  • Wiederherstellung: Starten Sie den ETL-Prozess neu, um ihn nach einem fehlgeschlagenen Lesevorgang wiederherzustellen.
Wenn der Vorgang erfolgreich ist, jedoch fehlgeschlagene Datensätze vorliegen, sollte das Problem durch einen sofortigen Neustart oder eine anschließende Ausführung des Auftrags behoben werden. In diesem Fall ist ein verzögerter Neustart möglicherweise eine bessere Lösung, da er Zeit für die Triage und Korrektur von Daten bietet, die die Fehler verursachen könnten.
Externes Mastersystem Fehler sollten gemäß den bewährten Vorgehensweisen des Mastersystems behandelt werden.

Sicherheitsüberlegungen

Bei jedem Anruf an ein Remote-System müssen die Vertraulichkeit, Integrität und Verfügbarkeit der Anforderung gewahrt bleiben. Je nach der von Ihnen ausgewählten Lösung gelten unterschiedliche Sicherheitsüberlegungen.

  • Zum Zulassen des authentifizierten API-Zugriffs auf die Salesforce-API ist eine Lightning Platform-Lizenz mit mindestens "Nur API"-Benutzerberechtigungen erforderlich.
  • Es wird empfohlen, die Standardverschlüsselung zu verwenden, um den Kennwortzugriff zu schützen.
  • Verwenden Sie das HTTPS-Protokoll, wenn Sie Aufrufe an die Salesforce-APIs senden. Sie können den Datenverkehr bei Bedarf auch über eine lokale Sicherheitslösung an die Salesforce-APIs weiterleiten.

Siehe Sicherheitsüberlegungen.

Randleisten

Keine.

Pünktlichkeit

Aktualität ist in diesem Muster nicht von wesentlicher Bedeutung. Es ist jedoch darauf zu achten, dass die Schnittstellen so gestaltet sind, dass alle Batchprozesse in einem angegebenen Batchfenster abgeschlossen werden.

Wie bei allen Batch-orientierten Vorgängen wird dringend empfohlen, dass Sie während der Batch-Verarbeitungsfenster auf die Isolierung der Quell- und Zielsysteme achten. Wenn Batches während der Geschäftszeiten geladen werden, kann dies zu Streitigkeiten führen, was dazu führt, dass die Aktualisierung eines Benutzers fehlschlägt oder, was noch wichtiger ist, dass eine Batch-Last (oder eine Teil-Batch-Last) fehlschlägt.

Bei Organisationen mit globalen Vorgängen ist es möglicherweise nicht möglich, alle Batch-Prozesse gleichzeitig auszuführen, da das System ständig verwendet wird. In diesen Fällen können Datensegmentierungstechniken mit Datensatztypen und anderen Filterkriterien verwendet werden, um Datenstreitigkeiten zu vermeiden.

Statusverwaltung

Sie können die Statusverwaltung mithilfe von Ersatzschlüsseln zwischen den beiden Systemen implementieren. Wenn Sie eine beliebige Art der Transaktionsverwaltung über Salesforce-Einheiten hinweg benötigen, sollten Sie das Muster "Remote Call-In" (Remote-Aufruf) mit Apex verwenden.

Die standardmäßige optimistische Datensatzsperrung erfolgt auf der Plattform und alle über die API vorgenommenen Aktualisierungen erfordern, dass der Benutzer, der den Datensatz bearbeitet, den Datensatz aktualisiert und seine Transaktion initiiert. Optimistische Sperre bezieht sich im Kontext der Salesforce-API auf einen Prozess, bei dem Folgendes eintritt:

  • Salesforce behält nicht den Status eines Datensatzes bei, der von einem bestimmten Benutzer bearbeitet wird.
  • Beim Lesen wird die Uhrzeit aufgezeichnet, zu der die Daten extrahiert wurden.
  • Wenn der Benutzer den Datensatz aktualisiert und speichert, überprüft Salesforce, ob ein anderer Benutzer den Datensatz zwischenzeitlich aktualisiert hat.
  • Wenn der Datensatz aktualisiert wurde, benachrichtigt das System den Benutzer, dass eine Aktualisierung vorgenommen wurde, und der Benutzer sollte die neueste Version des Datensatzes abrufen, bevor er mit seinen Aktualisierungen fortfährt.

Middleware-Funktionen

Die effektivsten externen Technologien, die zur Implementierung dieses Musters verwendet werden, sind traditionelle ETL-Tools. Es ist wichtig, dass die ausgewählten Middleware-Tools die Salesforce Bulk-API unterstützen.

Es ist hilfreich, aber nicht kritisch, dass die Middleware-Tools die Funktion getUpdated() unterstützen. Diese Funktion bietet die Implementierung der standardmäßigen Datenerfassung für Änderungen auf Salesforce Platform.

In der folgenden Tabelle werden die wünschenswerten Eigenschaften eines Middleware-Systems hervorgehoben, das an diesem Muster teilnimmt.

Eigenschaft Obligatorisch Wünschenswert Nicht erforderlich
Ereignisverarbeitung X
Protokollkonvertierung X
Übersetzung und Transformation X
Warteschlange und Pufferung X
Synchrone Transportprotokolle X
Asynchrone Transportprotokolle X
Vermittlungsweiterleitung X
Prozesschoreografie und Serviceorchestrierung X
Transaktionalität (Verschlüsselung, Signieren, zuverlässige Zustellung, Transaktionsverwaltung) X
Weiterleitung X
Extrahieren, Umwandeln und Laden X
Lange Abstimmung X (erforderlich für die Salesforce Change Datenerfassung)

Beispiel

Ein Versorgungsunternehmen verwendet einen Mainframe-basierten Batch-Prozess, der potenzielle Kunden einzelnen Vertriebsmitarbeitern und Teams zuweist. Diese Informationen müssen jeden Abend in Salesforce importiert werden.

Der Kunde hat sich entschieden, die Datenerfassung für Änderungen in den Quelltabellen mithilfe eines handelsüblichen ETL-Tools zu implementieren. Die Lösung funktioniert wie folgt:

  • Ein Cron-ähnlicher Planer führt einen Batchauftrag aus, der potenzielle Kunden Benutzern und Teams zuweist.
  • Nachdem der Batchauftrag ausgeführt und die Daten aktualisiert wurde, erkennt das ETL-Tool diese Änderungen mithilfe der Datenerfassung. Das ETL-Tool führt die Änderungen aus dem Datenspeicher zusammen.
  • Der ETL-Konnektor verwendet die Salesforce-REST-API, um die Änderungen in Salesforce zu laden.

Context

Sie verwenden Salesforce, um Leads zu verfolgen, Ihre Pipeline zu verwalten, Opportunities zu erstellen und Auftragsdetails zu erfassen, die Leads in Kunden konvertieren. Das Salesforce-System erstellt die Aufträge intern und überträgt diese Daten dann zur Bereitstellung und Aktivierung an das externe Abrechnungssystem. Abrechnungsaufträge werden von einem externen (Remote-)System verwaltet. Dieses Remote-System muss den Auftragsstatus in Salesforce aktualisieren, wenn sich der Status des Auftrags oder der Abrechnungseinheit im Abrechnungssystem ändert.

Problem

Wie stellt ein Remote-System eine Verbindung mit Salesforce her und authentifiziert sich mit Salesforce, um Salesforce über externe Ereignisse zu informieren, Datensätze zu erstellen und vorhandene Datensätze zu aktualisieren?

Kräfte

Beim Anwenden von Lösungen auf der Grundlage dieses Musters sind verschiedene Kräfte zu berücksichtigen:

  • Ist der Remote-Aufruf an Salesforce der Zweck, Salesforce über ein extern aufgetretenes Ereignis mithilfe einer ereignisgesteuerten Architektur zu informieren? Oder ist der Zweck, CRUD-Vorgänge für bestimmte Datensätze auszuführen? Wenn Sie eine ereignisgesteuerte Architektur verwenden, wird der Ereigniserzeuger (der Remote-Prozess) vom Salesforce-Ereignisverbraucher getrennt.
  • Muss der Remote-Prozess beim Aufruf von Salesforce auf eine Antwort warten, bevor er die Verarbeitung fortsetzt? Remote-Aufrufe an Salesforce sind immer synchrone Anforderungsantworten, obwohl der Remote-Prozess die Antwort verwerfen kann, wenn sie nicht zur Simulation eines asynchronen Anrufs benötigt wird.
  • Funktioniert jede Transaktion für ein einzelnes Salesforce-Objekt oder mehrere verwandte Objekte?
  • Wie sieht das Format der Nachricht aus (z. B. SOAP oder REST oder beide über HTTP)?
  • Ist die Nachrichtengröße relativ klein oder groß?
  • Wenn das Remote-System SOAP-fähig ist, kann das Remote-System an einem Ansatz vom Typ "Vertrag zuerst" teilnehmen, bei dem Salesforce den Vertrag vorschreibt? Dies ist erforderlich, wenn unsere SOAP-API verwendet wird, für die eine vordefinierte WSDL bereitgestellt wird.
  • Ist eine Transaktionsverarbeitung erforderlich?
  • Inwieweit sind Sie gegenüber Anpassungen in Salesforce tolerant?

Lösung

Diese Tabelle enthält verschiedene Lösungen für dieses Integrationsproblem.

Lösung Fit Kommentare
Zusammengesetzte API Best Salesforce stellt eine zusammengesetzte API bereit, die im Grunde eine REST-API ist und zusammengesetzte Anforderungen unterstützt. Dies kann von Remote-Systemen für folgende Zwecke verwendet werden:
  • Senden Sie bis zu 25 Anforderungen in einem einzelnen Anruf.
  • Zum Abfragen, Erstellen und Ändern von Daten in der Salesforce-Organisation mithilfe von JSON-Anforderungen.

Synchrone API: Nach dem API-Aufruf wartet die Remote-Client-Anwendung, bis sie eine Antwort vom Service erhält.

Transaktions-/Commit-Verhalten: Die zusammengesetzte API ermöglicht standardmäßig keinen Teilerfolg, wenn einige Datensätze mit Fehlern gekennzeichnet sind. Dies kann geändert werden, indem die Kennzeichnung "Alles oder nichts" als "false" markiert wird, was einen Teilerfolg ermöglicht.

Fehlerbehandlung: Die richtige Fehlerbehandlung sollte den Antworttext untersuchen und nicht nur HTTP-Statuscodes. Ein zusammengesetzter Endpunkt antwortet mit dem HTTP-Statuscode 200, selbst wenn er im Antworttext anzeigt, dass eine der Teilanforderungen fehlgeschlagen ist und die Transaktion zurückgesetzt werden musste.
REST-API Best Barrierefreiheit: Salesforce bietet eine REST-API, die Remote-Systeme für folgende Zwecke verwenden können:
  • Veröffentlichen von Ereignissen zum Benachrichtigen Ihrer Salesforce-Organisation
  • Abfragen von Daten in Ihrer Organisation
  • Erstellen, Aktualisieren und Löschen von Daten
  • Abrufen von Metadaten zu Ihrer Organisation

Synchrone API: Nach dem API-Aufruf wartet die Remote-Client-Anwendung, bis sie eine Antwort vom Service erhält.

Die REST-API berücksichtigt die in Salesforce basierend auf dem Profil des angemeldeten Benutzers konfigurierte Objekt- und Feldebenensicherheit.

REST stellt Ressourcen (Einheiten/Objekte) als URIs bereit und verwendet HTTP-Verben, um CRUD-Vorgänge für diese Ressourcen zu definieren. Im Gegensatz zu SOAP benötigt die REST-API keinen vordefinierten Vertrag, verwendet XML und JSON für Antworten und weist eine lose Eingabe auf. Die REST-API ist leichtgewichtig und bietet eine einfache Methode für die Interaktion mit Salesforce. Zu den Vorteilen zählen die einfache Integration und Entwicklung und die Verwendung mit mobilen Anwendungen und Webanwendungen.

Transaktions-/Commit-Verhalten: Standardmäßig wird jeder Datensatz als separate Transaktion behandelt und separat übernommen. Wenn eine Datensatzänderung fehlschlägt, werden andere Datensatzänderungen nicht wiederhergestellt. Dieses Verhalten kann zu einem Alles-oder-nichts-Verhalten geändert werden. Verwenden Sie die zusammengesetzten REST-API-Ressourcen, um eine Reihe von Aktualisierungen in einem API-Aufruf vorzunehmen.

Bulk-Daten: Jeder Datenvorgang, der mehr als 2.000 Datensätze enthält, ist ein guter Kandidat für die Bulk-API 2.0, um einen asynchronen Workflow, der das Bulk-Framework verwendet, erfolgreich vorzubereiten, auszuführen und zu verwalten.
Bulk-API 2.0 Am besten für Massenvorgänge Die Bulk-API 2.0 ist die moderne, optimierte API von Salesforce für die Verarbeitung umfangreicher Datenvorgänge. Die REST-basierte Bulk-API 2.0 bietet eine programmgesteuerte Option zum asynchronen Einfügen, Aktualisieren, Abfragen oder Löschen großer Datensets in Ihrer Salesforce-Organisation. Sie ist auf Effizienz ausgelegt, wenn Sie große Datenmengen in Salesforce laden oder Massenabfragen für die Daten Ihrer Organisation ausführen müssen.

Im Gegensatz zur Bulk-API 1.0 verarbeitet die Bulk-API 2.0 Batches immer parallel und unterstützt den seriellen Modus nicht. Das bedeutet, dass:
  • Datensätze werden in mehreren Threads gleichzeitig verarbeitet
  • Es gibt keine Garantie für die Verarbeitungsreihenfolge zwischen Batches
  • Höhere Leistung, aber auch mögliche Sperrkonflikte

Jeder Batch in der Bulk-API 2.0 wird als eigene Transaktion verarbeitet. Das bedeutet:
  • Erfolgreiche Batches werden unabhängig übernommen
  • Fehlgeschlagene Batches wirken sich nicht auf erfolgreiche Batches aus
  • Standardmäßig gibt es kein Alles-oder-nichts-Verhalten für alle Aufträge

Obwohl die SOAP-API auch für die Verarbeitung einer großen Anzahl von Datensätzen verwendet werden kann, wird sie weniger optimal, wenn Datensets Hunderttausende bis Millionen von Datensätzen enthalten. Dies ist auf den relativ hohen Overhead und die geringeren Leistungseigenschaften zurückzuführen.
  • Ereignisgesteuerte Architektur: Plattformereignisse werden auf die gleiche Weise definiert wie Salesforce-Objekte. Das Veröffentlichen eines Ereignisses über die Bulk-API 2.0 entspricht dem Erstellen eines Salesforce-Datensatzes. Nur die Vorgänge zum Erstellen und Einfügen werden unterstützt. Ereignisse in einem Batch werden während der Verarbeitung des Batchauftrags asynchron im Salesforce-Ereignis-Bus veröffentlicht.
Pub/Sub-API Best Die Pub/Sub-API ist die empfohlene Möglichkeit für externe Publisher, Ereignisse im Ereignis-Bus zu veröffentlichen.

Die Pub/Sub-API ist eine gRPC-basierte API, mit der externe Systeme Plattformereignisse veröffentlichen können. Die Pub/Sub-API:
  • Unterstützt die Veröffentlichung und das Abonnieren von Plattformereignissen aus externen Anwendungen
  • Ist bei ordnungsgemäßer Authentifizierung (OAuth-, JWT- oder Sitzungstoken) verfügbar

Sobald ein Plattformereignis in Salesforce definiert ist, wird es für interne und externe Verbraucher verfügbar.
Plattformereignisse Best Plattformereignisse werden auf dieselbe Weise definiert wie Salesforce-Objekte. Plattformereignisse können mithilfe verschiedener Mechanismen wie REST-APIs, Bulk-APIs und SOAP-APIs veröffentlicht werden.

Das Veröffentlichen eines Ereignisses über die REST-API entspricht dem Erstellen eines Salesforce-Datensatzes.

Endpunktformat: POST /services/data/vXX.X/sobjects/EventName__e/
  • Inhaltstyp: application/json
  • Authentifizierung: Bearer-Token (OAuth)

Bei der Bulk-API werden nur die Vorgänge zum Erstellen und Einfügen unterstützt. Ereignisse in einem Batch werden während der Verarbeitung des Batchauftrags asynchron im Salesforce-Ereignis-Bus veröffentlicht.

Da Plattformereignisse SObjects sind, werden standardmäßige SOAP-API-Vorgänge unterstützt.
SOAP-API Fit Barrierefreiheit: Salesforce bietet eine SOAP-API, die Remote-Systeme für folgende Zwecke verwenden können:
  • Veröffentlichen von Ereignissen zum Benachrichtigen Ihrer Salesforce-Organisation
  • Abfragen von Daten in Ihrer Organisation
  • Erstellen, Aktualisieren und Löschen von Daten
  • Abrufen von Metadaten zu Ihrer Organisation
  • Ausführen von Dienstprogrammen zum Ausführen von Verwaltungsaufgaben

Synchrone API: Nach dem API-Aufruf wartet die Remote-Client-Anwendung, bis sie eine Antwort vom Service erhält. Asynchrone Aufrufe an Salesforce werden nicht unterstützt.

Generierte WSDL: Salesforce bietet zwei WSDLs für Remote-Systeme:
  • Enterprise WSDL: Stellt eine stark typisierte WSDL bereit, die für eine Salesforce-Organisation spezifisch ist.
  • Partner-WSDL: Enthält eine lose eingegebene WSDL, die nicht spezifisch für eine Salesforce-Organisation ist.

Sicherheit: Der Client, der die SOAP-API ausführt, muss über eine gültige Anmeldung verfügen und eine Sitzung abrufen, um API-Aufrufe ausführen zu können. Die API berücksichtigt die Objekt- und Feldebenensicherheit, die in Salesforce basierend auf dem Profil des angemeldeten Benutzers konfiguriert ist.

Transaktions-/Commit-Verhalten: Standardmäßig ermöglicht jeder API-Aufruf einen Teilerfolg, wenn einige Datensätze mit Fehlern gekennzeichnet sind. Dies kann zu einem Alles-oder-nichts-Verhalten geändert werden, bei dem alle Ergebnisse zurückgesetzt werden, wenn ein Fehler auftritt. Es ist nicht möglich, eine Transaktion über mehrere API-Aufrufe zu erstrecken. Um diese Einschränkung zu überwinden, kann sich ein einzelner API-Aufruf auf mehrere Objekte auswirken.
Apex Webservices Suboptimal Apex-Klassenmethoden können als Webservicemethoden für externe Anwendungen verfügbar gemacht werden. Diese Methode ist eine Alternative zur SOAP-API und wird in der Regel nur verwendet, wenn die folgenden zusätzlichen Anforderungen erfüllt sein müssen.
  • Vollständige transaktionale Unterstützung ist erforderlich (z. B. Account, Kontakt und Opportunity in einer Transaktion erstellen).
  • Vor dem Commit muss auf Salesforce-Seite eine benutzerdefinierte Logik angewendet werden.

Der Vorteil der Verwendung eines Apex Webservice muss gegen den zusätzlichen Code abgewogen werden, der in Salesforce verwaltet werden muss.

Gilt nicht für Plattformereignisse, da die Logik zum Vorabeinfügen von Transaktionen beim Verbraucher nicht in einer ereignisgesteuerte Architektur. Verwenden Sie die SOAP-API, die REST-API oder die Bulk-API 2.0, um eine Salesforce-Organisation über ein aufgetretenes Ereignis zu benachrichtigen.
Apex REST-Services Suboptimal Eine Apex-Klasse kann als REST-Ressourcen angezeigt werden, die bestimmten URIs mit einem definierten HTTP-Verb zugeordnet sind (z. B. POST oder GET).

Sie können zusammengesetzte REST-API-Ressourcen verwenden, um mehrere Aktualisierungen in einer einzelnen Transaktion auszuführen.

Im Gegensatz zu SOAP muss der Client keine Servicedefinition/Vertrag (WSDL) verwenden und keine Client-Stubs generieren. Das Remote-System benötigt nur die Möglichkeit, eine HTTP-Anforderung zu bilden und die zurückgegebenen Ergebnisse (XML oder JSON) zu verarbeiten.

Gilt nicht für Plattformereignisse, da die Logik zum Vorabeinfügen von Transaktionen beim Verbraucher nicht in einer ereignisgesteuerte Architektur. Verwenden Sie die SOAP-API, die REST-API oder die Bulk-API 2.0, um eine Salesforce-Organisation über ein aufgetretenes Ereignis zu benachrichtigen.

Skizze

Die folgenden Diagramme veranschaulichen die Abfolge der Ereignisse, wenn Sie dieses Muster entweder mithilfe der REST-API für Benachrichtigungen von externen Ereignissen oder der SOAP-API zum Abfragen eines Salesforce-Objekts implementieren. Die Reihenfolge der Ereignisse ist bei Verwendung der REST-API identisch.

Remote System Querying Salesforce Via SOAP API (Remote-Systemabfrage in Salesforce über SOAP-API)

Remote-System, das Salesforce mit Ereignissen über die REST-API benachrichtigt

Ergebnisse

In einer ereignisgesteuerten Architektur ruft das Remote-System Salesforce über die SOAP-API, die REST-API oder die Bulk-API 2.0 auf, um ein Ereignis im Salesforce-Ereignis-Bus zu veröffentlichen. Durch das Veröffentlichen eines Ereignisses werden alle Abonnenten benachrichtigt. Ereignisabonnenten können sich auf der Salesforce Platform befinden, beispielsweise Flows oder Apex-Auslöser für Lightning-Komponenten. Ereignisabonnenten können auch außerhalb der Salesforce Platform liegen, beispielsweise CometD-Abonnenten.

Wenn Sie direkt mit Salesforce-Objekten arbeiten, ermöglichen die mit diesem Muster verbundenen Lösungen Folgendes:

  • Das Remote-System ruft die Salesforce-APIs auf, um die Datenbank abzufragen und Einzelobjektvorgänge (Erstellen, Aktualisieren, Löschen usw.) auszuführen.
  • Das Remote-System zum Aufrufen der zusammengesetzten Salesforce-REST-API-Ressourcen zum Ausführen einer Reihe von Objektvorgängen.
  • Remote-System zum Aufrufen von benutzerdefinierten Salesforce-APIs (Services), die Transaktionsvorgänge mit mehreren Objekten und benutzerdefinierte Vor-/Nachbearbeitungslogik unterstützen können.

Anrufmechanismen

Der Aufrufmechanismus hängt von der Lösung ab, die zur Implementierung dieses Musters ausgewählt wurde.

Anrufmechanismus Beschreibung
SOAP-API Das Remote-System verwendet die Salesforce Enterprise- oder Partner-WSDL, um Client-Stubs zu generieren, die wiederum zum Aufrufen der standardmäßigen SOAP-API verwendet werden.
REST-API Das Remote-System muss sich authentifizieren, bevor auf einen Apex REST-Service zugegriffen werden kann. Das Remote-System kann OAuth 2.0 oder die Authentifizierung mit Benutzername und Kennwort verwenden. In beiden Fällen muss der Client die HTTP-Autorisierungskopfzeile mit dem entsprechenden Wert festlegen (ein OAuth-Zugriffstoken oder eine Sitzungs-ID kann über einen Anmeldeaufruf bei der SOAP-API abgerufen werden).

Anschließend generiert das Remote-System REST-Aufrufe (HTTP-Anforderungen) mit den entsprechenden Verben und verarbeitet die zurückgegebenen Ergebnisse (JSON- und XML-Datenformate werden unterstützt).
Apex Webservice Das Remote-System verwendet die benutzerdefinierte Apex Web Service WSDL, um Client-Stubs zu generieren, die wiederum zum Aufrufen des benutzerdefinierten Apex Web Service verwendet werden.
Apex REST-Service Gemäß der REST-API werden der Ressourcen-URI und die entsprechenden Verben mithilfe der Anmerkungen @RestResource, @HttpGet und @HttpPost definiert.
Bulk-API 2.0 Bei der Bulk-API 2.0 handelt es sich um eine REST-basierte API. Daher gelten dieselben Aufrufmechanismen wie bei der REST-API.
REST-API zum Aufrufen des Flows Verwenden Sie die REST-API, um einen Endpunkt für benutzerdefinierte aufrufbare Aktionen aufzurufen und einen automatisch gestarteten Flow aufzurufen.

Fehlerbehandlung und -behebung

Eine Fehlerbehandlungs- und -behebungsstrategie muss als Teil der Gesamtlösung betrachtet werden.

  • Fehlerbehandlung: Bei allen Remote-Aufrufmethoden, Standard- oder benutzerdefinierten APIs, muss das Remote-System alle nachfolgenden Fehler verarbeiten, beispielsweise Zeitüberschreitungen und die Verwaltung von Wiederholungen. Middleware kann verwendet werden, um die Logik für die Fehlerbehandlung und -behebung bereitzustellen.
  • Wiederherstellung: Es muss ein benutzerdefinierter Mechanismus für Wiederholungen erstellt werden, wenn dies aufgrund der Anforderungen an die Servicequalität erforderlich ist. In diesem Fall ist es wichtig, idempotente Designeigenschaften sicherzustellen. Mit dem Plattformereignis können Abonnenten die ID der erneuten Wiedergabe verwenden, um Nachrichten innerhalb eines bestimmten Zeitraums nach der Veröffentlichung dieser Nachrichten abzurufen.

Überlegungen zum idempotenten Design

Idempotente Funktionen garantieren, dass wiederholte Aufrufe sicher sind und sich nicht negativ auswirken. Wenn Idempotenz nicht implementiert ist, können wiederholte Aufrufe derselben Nachricht unterschiedliche Ergebnisse haben, was möglicherweise zu Problemen mit der Datenintegrität führen kann, beispielsweise zur Erstellung doppelter Datensätze, zur doppelten Verarbeitung von Transaktionen usw.

Das Remote-System muss bei Fehlern oder Zeitüberschreitungen mehrere (doppelte) Aufrufe verwalten, um doppelte Einfügungen und redundante Aktualisierungen zu vermeiden (insbesondere wenn nachgelagerte Auslöser und Workflow-Regeln ausgelöst werden). Es ist zwar möglich, einige dieser Situationen in Salesforce zu verwalten (insbesondere bei benutzerdefinierten SOAP- und REST-Services), es wird jedoch empfohlen, dass das Remote-System (oder die Middleware) die Fehlerbehandlung und das idempotente Design verwaltet.

Sicherheitsüberlegungen

Je nach gewählter Musterlösung gelten unterschiedliche Sicherheitsüberlegungen. In allen Fällen verwendet die Plattform die Zugriffsrechte des angemeldeten Benutzers (z. B. Profileinstellungen, Freigaberegeln, Berechtigungssätze usw.). Zusätzlich können IP-Einschränkungen für Profile verwendet werden, um den Zugriff auf die API für einen bestimmten IP-Adressbereich einzuschränken.

Lösung Sicherheitsüberlegungen
SOAP-API alesforce unterstützt die Protokolle "Secure Sockets Layer v3 (SSL)" und "Transport Layer Security (TLS)". Die Schlüssellänge muss mindestens 128 Bit betragen.

Das Remote-System muss sich mit gültigen Anmeldeinformationen anmelden, um eine Sitzungs-ID abzurufen. Wenn das Remote-System bereits über eine gültige Sitzungs-ID verfügt, kann es die API ohne explizite Anmeldung aufrufen. Dies wird in Rückmeldungsmustern verwendet, die weiter oben in diesem Dokument behandelt wurden, wobei eine vorangegangene ausgehende Salesforce-Nachricht eine Sitzungs-ID und eine Datensatz-ID für die spätere Verwendung enthielt.

Es wird empfohlen, dass Clients, die den SOAP-API-Cache aufrufen und die Sitzungs-ID wiederverwenden, um die Leistung zu maximieren, statt für jeden Aufruf eine neue Sitzungs-ID abzurufen.
REST-API Es wird empfohlen, dass das Remote-System einen OAuth Trust zur Autorisierung einrichtet. REST-Aufrufe können dann für bestimmte Ressourcen mithilfe von HTTP-Verben getätigt werden. Es ist auch möglich, REST-Aufrufe mit einer gültigen Sitzungs-ID zu tätigen, die möglicherweise auf andere Weise abgerufen wurde (beispielsweise durch Aufrufen der SOAP-API oder Bereitstellung über eine ausgehende Nachricht).

Es wird empfohlen, dass Clients, die den REST-API-Cache aufrufen und die Sitzungs-ID wiederverwenden, um die Leistung zu maximieren, statt für jeden Aufruf eine neue Sitzungs-ID abzurufen.
Apex Webservice Es wird empfohlen, dass das Remote-System einen OAuth Trust zur Autorisierung einrichtet.
Apex REST-Service Es wird empfohlen, dass das Remote-System einen OAuth Trust zur Autorisierung einrichtet.
Bulk-API 2.0 Es wird empfohlen, dass das Remote-System einen OAuth Trust zur Autorisierung einrichtet.

Siehe Sicherheitsüberlegungen.

Randleisten

Keine.

Pünktlichkeit

Die SOAP-API und die Apex Web Service API sind synchron. Folgende Zeitüberschreitungen gelten:

  • Sitzungs-Timeout: Die Sitzungs-Timeouts werden aufgrund der Sitzungs-Timeout-Einstellung der Salesforce-Organisation durch Zeitüberschreitungen unterbrochen, wenn keine Aktivität vorhanden ist.
  • Abfrage-Timeout: Für jede SOQL-Abfrage gilt eine individuelle Timeout-Obergrenze von 120 Sekunden.

Datenvolumen

Die Überlegungen zum Datenvolumen hängen davon ab, welche Lösung und welchen Kommunikationstyp Sie auswählen.

Lösung Kommunikationstyp Obergrenzen
SOAP-API oder REST-API Synchronous
  • SOAP-Anmeldung: Die SOAP-Anmeldeanforderungsgröße ist auf maximal 10 KB begrenzt. Sie können maximal 3.600 Aufrufe an die Funktion login() pro Benutzer und Stunde tätigen. Wenn Sie diese Obergrenze überschreiten, gibt die API einen Fehler zurück.
  • Erstellen, Aktualisieren, Löschen: Das Remote-System kann bis zu 200 Datensätze gleichzeitig erstellen, aktualisieren oder löschen. Es können mehrere Aufrufe getätigt werden, um mehr als insgesamt 200 Datensätze zu verarbeiten. Jede Anforderung ist jedoch auf 200 Datensätze in der Größe begrenzt.
  • BLOB-Daten: Sie können SObject-Basisinformationen, SObject-Zeilen oder SObject-Sammlungs-REST-Ressourcen verwenden, um BLOB-Daten in Salesforce-Standardobjekte einzufügen oder zu aktualisieren. Für die Ressourcen "SObject Basic Information" (Grundlegende SObject-Informationen) oder "SObject Rows" (SObject-Zeilen) beträgt die maximale Dateigröße für Uploads 2 GB für ContentVersion-Objekte und 500 MB für alle anderen berechtigten Standardobjekte. Bei Verwendung der SObject Collections-Ressourcen beträgt die maximale Gesamtgröße aller Dateien in einer einzelnen Anforderung 500 MB.
  • Abfrageergebnisgröße: Standardmäßig ist die Anzahl der Zeilen, die im Abfrageergebnisobjekt (Batchgröße) zurückgegeben werden und die in einem query()- oder queryMore()-Aufruf zurückgegeben werden, auf 500 festgelegt. Die maximale Anzahl der zurückgegebenen Zeilen beträgt 2.000. Sie können die Batchgröße explizit festlegen, es kann jedoch nicht garantiert werden, dass die angeforderte Batchgröße der tatsächlichen Batchgröße entspricht. Dies geschieht, um die Leistung zu maximieren. Wenn die Anzahl der zurückzugebenden Zeilen die Batchgröße überschreitet, verwenden Sie den API-Aufruf queryMore(), um mehrere Batches zu durchlaufen. Es gelten möglicherweise zusätzliche Regeln. Daher erhalten Sie weitere Informationen.
  • Ereignismeldung: Die maximale Ereignismeldungsgröße beträgt 1 MB. Das Veröffentlichen eines Ereignisses mithilfe der Salesforce-APIs wird auf Ihre standardmäßigen API-Obergrenzen angerechnet.
Bulk-API 2.0 Asynchron Die Bulk-API 2.0 ist für den asynchronen Import und Export großer Datensets optimiert.

Jeder Datenvorgang, der mehr als 2.000 Datensätze enthält, ist ein guter Kandidat für die Bulk-API 2.0, um einen asynchronen Workflow, der das Bulk-Framework verwendet, erfolgreich vorzubereiten, auszuführen und zu verwalten. Aufträge mit weniger als 2.000 Datensätzen sollten synchrone Aufrufe in REST (z. B. "Composite") oder SOAP "in Massenvorgängen" enthalten.

Die Bulk-API 2.0 ist synchron, wenn die Batch-Anforderung und die zugehörigen Daten gesendet werden. Die eigentliche Verarbeitung der Daten erfolgt asynchron. Weitere Informationen zu API- und Batchverarbeitungsobergrenzen finden Sie unter Obergrenzen.

Unterstützung von Endpunktfunktionen und Standards

Die Funktionen und die Standardunterstützung für den Endpunkt hängen von der von Ihnen ausgewählten Lösung ab.

Lösung Überlegungen zu Endpunkten
SOAP-API Das Remote-System muss in der Lage sein, einen Client zu implementieren, der die Salesforce SOAP-API basierend auf einem von Salesforce vordefinierten Nachrichtenformat aufrufen kann.

Das Remote-System (Client) muss an einer vertragsersten Implementierung teilnehmen, bei der der Vertrag von Salesforce bereitgestellt wird (z. B. Enterprise oder Partner WSDL).
REST-API Das Remote-System muss in der Lage sein, einen REST-Client zu implementieren, der definierte Salesforce-REST-Services aufruft und die XML- oder JSON-Ergebnisse verarbeitet.
Apex Webservice Das Remote-System muss in der Lage sein, einen Client zu implementieren, der SOAP-Nachrichten in einem vordefinierten Format aufrufen kann, wie von Salesforce definiert.

Das Remote-System muss an einer Code-First-Implementierung teilnehmen, bei der der Vertrag nach der Implementierung des Apex Webservice von Salesforce bereitgestellt wird. Jeder Apex Webservice verfügt über eine eigene WSDL.
Apex REST-Service Es gelten dieselben Endpunktüberlegungen wie für die REST-API.

Statusverwaltung

Bei der Integration von Systemen sind Schlüssel wichtig für die laufende Statusverfolgung, beispielsweise wenn ein Datensatz im Remote-System erstellt wird, um laufende Aktualisierungen an diesem Datensatz zu unterstützen. Es gibt zwei Optionen:

  • Salesforce speichert den primären oder eindeutigen Ersatzschlüssel des Remote-Systems für den Remote-Datensatz.
  • Das Remote-System speichert die eindeutige Salesforce-Datensatz-ID oder einen anderen eindeutigen Ersatzschlüssel. Für die Verarbeitung von Integrationsschlüsseln in diesem synchronen Muster gibt es spezifische Überlegungen.
Master System Beschreibung
Salesforce In diesem Szenario speichert das Remote-System entweder die Salesforce RecordId oder einen anderen eindeutigen Ersatzschlüssel aus dem Datensatz.
Remote-System In diesem Szenario speichert Salesforce einen Verweis auf die eindeutige Kennung im Remote-System. Da der Prozess synchron ist, kann der Schlüssel als Teil derselben Transaktion mit externen ID-Feldern bereitgestellt werden.

Komplexe Integrationsszenarien

Jede Lösung in diesem Muster hat unterschiedliche Überlegungen bei der Verarbeitung komplexer Integrationsszenarien wie Transformation und Prozessorchestrierung.

Lösung Überlegungen
SOAP-API oder REST-API Die SOAP-API und die REST-API ermöglichen einfache Transaktionen für Objekte. Komplexe Integrationsszenarien wie Aggregation, Orchestrierung und Transformation können in Salesforce nicht ausgeführt werden. Diese Szenarien müssen vom Remote-System oder von der Middleware verarbeitet werden, wobei Middleware die bevorzugte Methode ist.
Apex Webservice oder Apex REST Service Benutzerdefinierte Webservices können objektübergreifende Funktionen, benutzerdefinierte Logik und komplexere Transaktionsunterstützung bieten. Diese Lösung sollte mit Bedacht verwendet werden und Sie sollten immer die Eignung von Middleware für Transformations-, Orchestrierungs- und Fehlerbehandlungslogik berücksichtigen.

Obergrenzen

Aufgrund des mandantenfähigen Charakters der Salesforce Platform gelten bei der Verwendung der APIs Einschränkungen.

Lösung Obergrenzen
SOAP-API, REST-API und benutzerdefinierte Apex APIs
  • API-Anforderungsobergrenzen: Salesforce wendet eine Obergrenze für die Anzahl der API-Aufrufe pro 24-Stunden-Zeitraum an. Die Obergrenze basiert auf dem Salesforce-Editionstyp und der Anzahl der Lizenzen. Die Unlimited Edition bietet beispielsweise 5.000 API-Anforderungen pro Salesforce Platform-Lizenz und 24 Stunden. Weitere Informationen finden Sie unter Salesforce Developer Limits and Allocations Quick Reference.
  • API-Abfragecursorobergrenzen: Für einen Benutzer können bis zu 10 Abfragecursors gleichzeitig geöffnet sein. Andernfalls wird der älteste der 10 Cursors losgelassen. Wenn die Remote-Anwendung versucht, den freigegebenen Abfragecursor zu öffnen, wird ein Fehler angezeigt. Wenn Sie beispielsweise die Anmeldeinformationen für Integrationsbenutzer freigeben, müssen die maximalen Abfragecursors berücksichtigt werden. Wann immer möglich, sollte die Middleware die vollständige Abfrage abschließen, bevor eine andere Abfrage (seriell) ausgeführt wird, oder jede Anwendung sollte einen angegebenen Integrationsbenutzer verwenden. Alternativ muss die Middleware möglicherweise Anforderungen über mehrere Benutzer hinweg auf "Round Robin"-Art ausführen.
  • Obergrenzen für Anrufe: Unter Randleiste 'Datenvolumen' finden Sie Obergrenzen für die Erstellung, Aktualisierung und Abfrage.
Bulk-API 2.0 Weitere Informationen finden Sie unter Randleiste für Datenvolumen.
Plattformereignisse
  • Obergrenzen für Ereignisbenachrichtigungen: Für Plattformereignisse mit Standardvolumen können maximal 100.000 Ereignisse pro Stunde veröffentlicht werden. Für Plattformereignisse mit hohem Nutzungsvolumen können maximal 250.000 Ereignisse pro Stunde veröffentlicht werden. Verwenden Sie zum Überwachen der Ereignisnutzung mit hohem Volumen die Ressource "REST API limits".
  • Obergrenzen für die Größe von Ereignisnachrichten: Die maximale Größe von Ereignisnachrichten beträgt 1 MB. Das Veröffentlichen eines Ereignisses mithilfe der Salesforce-APIs wird auf Ihre standardmäßigen API-Obergrenzen angerechnet.

Zuverlässiges Messaging

Zuverlässiges Messaging versucht, das Problem der Gewährleistung der Zustellung einer Nachricht an ein Remote-System zu lösen, bei dem die einzelnen Komponenten selbst möglicherweise unzuverlässig sind. Die Salesforce SOAP-API und die REST-API sind synchron und bieten keine explizite Unterstützung für zuverlässige Messaging-Protokolle (z. B. WS-ReliableMessaging).

Es wird empfohlen, dass das Remote-System ein zuverlässiges Messaging-System implementiert, um sicherzustellen, dass Fehler- und Zeitüberschreitungsszenarien erfolgreich verwaltet werden. Die Veröffentlichung von Plattformereignissen aus externen Systemen basiert auf Salesforce-APIs. Daher gelten dieselben Überlegungen für die SOAP-API und die REST-API.

Middleware-Funktionen

In dieser Tabelle werden die wünschenswerten Eigenschaften eines Middleware-Systems hervorgehoben, das an diesem Muster teilnimmt:

Eigenschaft Obligatorisch Wünschenswert Nicht erforderlich
Ereignisverarbeitung X
Protokollkonvertierung X
Übersetzung und Transformation X
Warteschlange und Pufferung X
Synchrone Transportprotokolle X
Asynchrone Transportprotokolle X
Vermittlungsweiterleitung X
Prozesschoreografie und Serviceorchestrierung X
Transaktionalität (Verschlüsselung, Signieren, zuverlässige Zustellung, Transaktionsverwaltung) X
Weiterleitung X
Extrahieren, Umwandeln und Laden X (für Massen/Batch)

Beispiel

Ein Druckereibedarfs- und Serviceunternehmen verwendet Salesforce als Front-End zum Erstellen und Verwalten von Druckerbedarf und -aufträgen. Salesforce-Vermögenswertdatensätze, die Drucker darstellen, werden regelmäßig mit Drucknutzungsstatistiken (Farbstatus, Papierebene) aus dem lokalen Druckerverwaltungssystem (PMS) aktualisiert, das Drucker auf Client-Sites regelmäßig überwacht. Bei Erreichen eines festgelegten Schwellenwerts (z. B. niedriger Tintenstatus oder niedriger/leerer Papierstand von weniger als 30 %) werden mehrere Anwendungen/Prozesse (Variablen), die an dem Ereignis interessiert sind, benachrichtigt, E-Mail- oder Chatter-Benachrichtigungen gesendet und ein Auftragsdatensatz erstellt. Das PMS speichert die Salesforce-ID (Salesforce ist der Vermögenswert-Datensatzmaster).

Folgende Einschränkungen gelten:

  • Das PMS kann an einer Contract-First-Integration teilnehmen, bei der Salesforce den Vertrag bereitstellt und das PMS als Client (Verbraucher) des Salesforce-Service (definiert über die Enterprise- oder Partner-WSDL) fungiert.
  • Es sollte keine benutzerdefinierte Entwicklung in Salesforce vorhanden sein.

Dieses Beispiel lässt sich am besten mithilfe der Salesforce SOAP-API oder REST-API zum Veröffentlichen von Ereignissen und der deklarativen Automatisierung (Flow) in Salesforce implementieren. Der Hauptgrund für die Verwendung von Plattformereignissen ist die variable und nicht endliche Anzahl von Abonnenten. Wenn Sie jedoch eine endliche Liste von Datensätzen wie Aufträgen aktualisieren möchten, verwenden Sie SOAP oder die REST-API, um die Datensätze zu aktualisieren.

In Salesforce:

  • Definieren Sie ein Plattformereignis in Salesforce, das die aus dem PMS stammenden Benachrichtigungsdaten enthält.
  • Erstellen Sie einen Flow, der durch die Druckerereignisbenachrichtigung ausgelöst wird. Der Prozess aktualisiert den Druckervermögenswert und erstellt einen Auftrag (mit einem automatisch gestarteten Flow).
  • Laden Sie die Enterprise- oder Partner-WSDL herunter und stellen Sie sie dem Remote-System bereit.

Im Remote-System:

  • Erstellen Sie einen Client-Stub aus der Enterprise- oder Partner-WSDL.
  • Authentifizieren Sie sich mit den Anmeldeinformationen des Integrationsbenutzers bei Salesforce (über den OAuth-Webserver oder den Bearer-Token-Flow).
  • Beim Druckerstatusereignis ruft das PMS die API auf, um das Druckerstatus-Plattformereignis (mit Statistiken zur Druckernutzung) zu erstellen. Der Salesforce-Ereignis-Bus benachrichtigt Flow-Abonnenten und alle anderen Abonnenten.

Wenn Sie Plattformereignisse verwenden, können Sie mit dem Ereignis-Bus Ereignisse für Plattformereignisse mit hohem Volumen 72 Stunden lang erneut abspielen. Die Veröffentlichung dieser Ereignisse mithilfe einer Middleware-Lösung kann die Fehlerbehandlung auf der Veröffentlichungsseite unterstützen. Sie können die Fehlerbehandlung jedoch auf der abonnierenden Seite implementieren, wenn Sie eine höhere Zuverlässigkeit benötigen.

In diesem Beispiel wird Folgendes veranschaulicht:

  • Implementierung eines synchronen Salesforce-API-Clients (Verbraucher).
  • Eine Rückmeldung an Salesforce zum Veröffentlichen eines Plattformereignisses (abgestimmt auf zuvor abgedeckte Anforderungs-/Antwortplattformereignismuster).

Context

Sie verwenden Salesforce zum Verwalten von Kundenvorgängen. Ein Kundendienstmitarbeiter telefoniert mit einem Kunden, der an einem Kundenvorgang arbeitet. Der Kunde nimmt eine Zahlung vor und der Kundendienstmitarbeiter muss eine Echtzeitaktualisierung in der Salesforce-Anwendung über die Zahlungsabwicklungsanwendung sehen, die angibt, dass der Kunde den ausstehenden Betrag des Auftrags erfolgreich bezahlt hat.

Problem

Wie kann der Benutzer bei einem Ereignis in Salesforce auf der Salesforce-Benutzeroberfläche benachrichtigt werden, ohne seinen Bildschirm aktualisieren zu müssen und möglicherweise Arbeit zu verlieren?

Kräfte

Beim Anwenden von Lösungen auf der Grundlage dieses Musters sind verschiedene Kräfte zu berücksichtigen:

  • Müssen die Daten, auf die reagiert wird, in Salesforce gespeichert werden?
  • Kann eine benutzerdefinierte Benutzeroberflächenebene zum Anzeigen dieser Daten erstellt werden?
  • Hat der Benutzer Zugriff auf die benutzerdefinierte Benutzeroberfläche?

Lösung

Die empfohlene Lösung für dieses Integrationsproblem besteht in der Verwendung von Plattformereignissen, wodurch Ereignisse nahezu in Echtzeit in Salesforce gewährleistet werden. Plattformereignisse bieten eine strukturierte, flexible Nutzlast, die von Salesforce-Objekten unabhängig ist. Außerdem werden dauerhafte Themen mit einem Zeitfenster von 72 Stunden sichergestellt. Dadurch wird sichergestellt, dass Ereignisse auch dann verfügbar sind, wenn ein Offline-Verbraucher später verfügbar wird. Diese Lösung besteht aus den folgenden Komponenten:

  • Apex-Auslöser oder Flows mit einer Logik zum Veröffentlichen eines Plattformereignisses zu einem Thema
  • Ein Thema, mit dem Sie ein Ereignis über Apex Trigger oder Flow veröffentlichen können
  • Eine JavaScript-basierte Implementierung des Bayeux-Protokolls (derzeit CometD ), die von der Benutzeroberfläche verwendet werden kann
  • Eine Lightning-Komponente
  • Eine als statische Ressource enthaltene JavaScript-Bibliothek

Skizze

Im folgenden Diagramm wird veranschaulicht, wie die Streaming-API implementiert werden kann, um Benachrichtigungen an die Salesforce-Benutzeroberfläche zu streamen. Diese Benachrichtigungen werden durch Datensatzänderungen in Salesforce ausgelöst.

Benutzeroberflächenaktualisierung in Salesforce durch eine Datenänderung ausgelöst

Ergebnisse

Vorteile

Die Anwendung der auf dieses Muster bezogenen Lösung hat folgende Vorteile:

  • Es müssen keine benutzerdefinierten Abstimmungsmechanismen mehr geschrieben werden
  • Keine vom Benutzer initiierte Feedbackschleife erforderlich

Nicht unterstützte Anforderungen

Die Lösung weist die folgenden Einschränkungen auf:

  • Die Zustellung von Benachrichtigungen kann nicht garantiert werden.
  • Die Reihenfolge der Benachrichtigungen kann nicht garantiert werden.
  • Benachrichtigungen werden nicht aus Datensatzänderungen generiert, die von der Bulk-API vorgenommen wurden.

Sicherheitsüberlegungen

Die standardmäßige Sicherheit auf Salesforce-Organisationsebene wird eingehalten. Es wird empfohlen, das HTTPS-Protokoll zu verwenden, um eine Verbindung mit der Streaming-API herzustellen. Siehe Sicherheitsüberlegungen

Randleisten

Die optimale Lösung besteht darin, eine benutzerdefinierte Benutzeroberfläche in Salesforce zu erstellen. Sie müssen unbedingt einen geeigneten Benutzeroberflächen-Container verwenden, der zum Rendern der benutzerdefinierten Benutzeroberfläche verwendet werden kann. Unterstützte Browser sind im Streaming API Developer Guide aufgeführt.

Beispiel

Ein Telekommunikationsunternehmen verwendet Salesforce zum Verwalten von Kundenvorgängen. Die Kundendienstleiter möchten benachrichtigt werden, wenn ein Kundenvorgang von einem ihrer Kundendienstmitarbeiter erfolgreich abgeschlossen wird.

Bei der Implementierung der nach diesem Muster vorgeschriebenen Lösung sollte der Kunde:

  • Erstellen Sie ein Apex Trigger PushTopic, das ein Plattformereignis sendet, wenn ein Kundenvorgang mit dem Status "Geschlossen" und der Auflösung "Erfolgreich" gespeichert wird.
  • Erstellen Sie eine benutzerdefinierte Benutzeroberfläche, die Kundendienstleitern zur Verfügung steht. Diese Benutzeroberfläche abonniert den Ereignis-Bus, um Plattformereignisse zu nutzen.
  • Implementieren Sie Logik auf der benutzerdefinierten Benutzeroberfläche, die Benachrichtigungen anzeigt, die von den Kundendienstmitarbeitern dieses Managers generiert wurden.

Context

Sie verwenden Salesforce, um Leads zu verfolgen, Ihre Pipeline zu verwalten, Opportunities zu erstellen und Auftragsdetails zu erfassen, die Leads in Kunden konvertieren. Salesforce ist jedoch nicht das System, das Aufträge enthält oder verarbeitet. Aufträge werden von einem externen (Remote-)System verwaltet. Vertriebsmitarbeiter möchten jedoch Auftragsinformationen in Salesforce in Echtzeit anzeigen und aktualisieren, ohne sich mit dem externen System vertraut machen oder es verwenden zu müssen.

Problem

Wie können Sie in Salesforce außerhalb von Salesforce gespeicherte Daten anzeigen, durchsuchen und ändern, ohne die Daten aus dem externen System in Salesforce zu verschieben?

Kräfte

Beim Anwenden von Lösungen auf der Grundlage dieses Musters sind verschiedene Kräfte zu berücksichtigen:

  • Möchten Sie eine deklarative/ausgehende Zeigen-und-Klicken-Integration oder ein Benutzeroberflächen-Mashup in Salesforce erstellen?
  • Verfügen Sie über eine große Datenmenge, die Sie nicht in Ihre Salesforce-Organisation kopieren möchten?
  • Müssen Sie jederzeit auf kleine Mengen an Remote-Systemdaten zugreifen?
  • Benötigen Sie Echtzeitzugriff auf die neuesten Daten?
  • Speichern Sie Ihre Daten in der Cloud oder in einem Back-Office-System, möchten diese Daten jedoch in Ihrer Salesforce-Organisation anzeigen oder verarbeiten?
  • Haben Sie Bedenken hinsichtlich der Datenresidenz beim Speichern bestimmter Datentypen in Salesforce?

Lösung

Die folgende Tabelle enthält verschiedene Lösungen für dieses Integrationsproblem.

Lösung Fit Kommentare
Salesforce Connect Best Verwenden Sie Salesforce Connect, um zusammen mit Ihren Salesforce-Daten auf Daten aus externen Quellen zuzugreifen. Rufen Sie Daten aus Systemen wie SAP, Microsoft, Oracle und anderen Cloud-basierten Systemen wie Snowflake in Echtzeit ab, ohne eine Kopie der Daten in Salesforce zu erstellen.

Salesforce Connect ordnet externen Objekten in Ihrer Organisation Datentabellen in externen Systemen zu. Externe Objekte ähneln benutzerdefinierten Objekten, außer dass sie Daten zugeordnet sind, die sich außerhalb Ihrer Salesforce-Organisation befinden. Salesforce Connect verwendet eine Live-Verbindung zu externen Daten, um externe Objekte immer auf dem neuesten Stand zu halten. Beim Zugreifen auf ein externes Objekt werden die Daten aus dem externen System in Echtzeit abgerufen.

Salesforce Connect bietet Ihnen folgende Möglichkeiten:
  • Fragen Sie Daten in einem externen System ab.
  • Erstellen, aktualisieren und löschen Sie Daten in einem externen System.
  • Greifen Sie über Listenansichten, Detailseiten, Datensatz-Feeds, benutzerdefinierte Registerkarten und Seitenlayouts auf externe Objekte zu.
  • Definieren Sie Beziehungen zwischen externen Objekten und standardmäßigen oder benutzerdefinierten Objekten, um Daten aus verschiedenen Quellen zu integrieren.
  • Führen Sie Berichte (eingeschränkt) zu externen Daten aus.
  • Zeigen Sie die Daten in der mobilen Salesforce-Anwendung an.

Wenn Sie mit Salesforce Connect auf Daten zugreifen möchten, die auf einem externen System gespeichert sind, können Sie einen der folgenden Adapter verwenden:

  • Odata 2.0-Adapter oder Odata 4.0-Adapter: Verbindung mit Daten, die von einem beliebigen Odata 2.0- oder 4.0-Produzenten bereitgestellt werden.
  • Organisationsübergreifender Adapter: Stellt eine Verbindung mit Daten her, die in einer anderen Salesforce-Organisation gespeichert sind. Der organisationsübergreifende Adapter verwendet die standardmäßige Lightning Platform-REST-API. Im Gegensatz zu OData stellt der organisationsübergreifende Adapter direkt eine Verbindung mit einer anderen Organisation her, ohne dass ein Webservice zwischengeschaltet werden muss.
  • Über Apex erstellter benutzerdefinierter Adapter: Wenn die Odata und organisationsübergreifenden Adapter nicht für Ihre Anforderungen geeignet sind, entwickeln Sie Ihren eigenen Adapter mit dem Apex Connector Framework.
Anforderung und Antwort Suboptimal Verwenden Sie Salesforce-Webservice-APIs, um Ad-hoc-Datenanforderungen für den Zugriff auf externe Systemdaten und deren Aktualisierung zu senden. Diese Lösung umfasst die folgenden Ansätze:

Verwenden Sie die Salesforce SOAP-API. Eine benutzerdefinierte Seite oder Schaltfläche initiiert synchron einen Apex REST/SOAP-Callout. In Salesforce können Sie eine WSDL verwenden und eine resultierende Apex-Klasse für Proxys generieren. Diese Klasse bietet die erforderliche Logik zum Aufrufen des Remote-Service. Eine vom Benutzer initiierte Aktion auf einer Seite ruft dann eine Apex-Steuerfeldaktion auf, die diese Apex-Proxyklasse ausführt, um den Remote-Aufruf auszuführen. Die Seiten müssen angepasst werden.

Verwenden Sie die Salesforce-REST-API. Eine benutzerdefinierte Seite oder Schaltfläche initiiert synchron einen Apex HTTP-Callout (REST-Service). In Salesforce können Sie HTTP-Services mithilfe der standardmäßigen GET-, POST-, PUT- und DELETE-Methoden aufrufen.

Weitere Informationen zu dieser Lösung finden Sie unter Remote Process Invocation – Request and Reply (Remote-Prozessaufruf – Anforderung und Antwort).

Skizze

Im folgenden Diagramm wird veranschaulicht, wie Sie Salesforce Connect verwenden können, um Daten mithilfe eines Odata Adapters aus einem externen System abzurufen.

In diesem Szenario:

  1. Der Browser führt einen AJAX-Aufruf aus, der wiederum eine Aktion für den entsprechenden externen Objektadapter ausführt.
  2. Der Adapter übersetzt die Aktion in eine Odata-Anforderung und sendet über die Integrations- und Serviceebenen eine HTTP GET-Anforderung an das Remote-System.
  3. Das Remote-System gibt eine JSON-Antwort über die Integrations- und Serviceebenen an Salesforce zurück.
  4. Die Antwort wird aus Odata in ein externes Objekt übersetzt und dem Browser wieder angezeigt.

Ergebnisse

Die Anwendung der auf dieses Muster bezogenen Lösungen ermöglicht initiierte Aufrufe auf der Benutzeroberfläche, bei denen das Ergebnis der Transaktion dem Endbenutzer angezeigt werden kann.

Anrufmechanismen

Der Aufrufmechanismus hängt von der Lösung ab, die zur Implementierung dieses Musters ausgewählt wurde.

Anrufmechanismus Beschreibung
Externe Objekte Salesforce Connect ordnet externe Salesforce-Objekte Datentabellen in externen Systemen zu. Statt die Daten in Ihre Organisation zu kopieren, greift Salesforce Connect bei Bedarf und in Echtzeit auf die Daten zu. Obwohl die Daten außerhalb Ihrer Organisation gespeichert werden, bietet Salesforce Connect eine nahtlose Integration in die Lightning Platform. Externe Objekte sind für Salesforce-Tools wie die globale Suche, Nachschlagebeziehungen, Datensatz-Feeds und die mobile Salesforce-Anwendung verfügbar. Externe Objekte sind auch für Apex, SOSL, SOQL-Abfragen, Salesforce-APIs und die Bereitstellung über die Metadaten-API, Änderungssets und Pakete verfügbar.
Beleuchtungskomponenten Wird verwendet, wenn der Remote-Prozess im Rahmen eines durchgängigen Prozesses mit der Benutzeroberfläche ausgelöst wird und das Ergebnis in einem Salesforce-Datensatz angezeigt oder aktualisiert werden muss. Beispielsweise ein Prozess, bei dem Kreditkartenzahlungen an ein externes Zahlungs-Gateway gesendet werden und Zahlungsergebnisse, die dem Benutzer angezeigt werden, sofort zurückgegeben werden. Für die über Benutzeroberflächenereignisse ausgelöste Integration müssen in der Regel benutzerdefinierte Lightning Komponenten erstellt werden.

Fehlerbehandlung

Es ist wichtig, die Fehlerbehandlung als Teil der Gesamtlösung einzubeziehen. Wenn ein Fehler auftritt (Ausnahmen oder Fehlercodes werden an den Anrufer zurückgegeben), verwaltet der Anrufer die Fehlerbehandlung. Bei Salesforce Connect Validator handelt es sich um ein kostenloses Tool zum Ausführen einiger gängiger Abfragen und zum Erkennen von Fehlertypen und Fehlerursachen.

Vorteile

Die Verwendung einer Salesforce Connect-Lösung bietet folgende Vorteile:

  • Diese Lösung verwendet keinen Datenspeicher in Salesforce.
  • Benutzer müssen sich keine Gedanken über die regelmäßige Synchronisierung von Daten zwischen dem externen System und Salesforce machen.
  • Eine deklarative Einrichtung, die schnell mit Odata oder einem organisationsübergreifenden Adapter oder mit minimalem Code mit einem benutzerdefinierten Apex Adapter erreicht werden kann.
  • Benutzer können auf externe Daten mit weitgehend denselben Funktionen wie benutzerdefinierte Objekte in Form von externen Objekten zugreifen.
  • Möglichkeit, eine Verbundsuche im verbundenen externen System mithilfe der globalen Suche auszuführen.
  • Möglichkeit zum Ausführen von Berichten, die auf externe Daten aus Cloud- und lokalen Quellen zugreifen. Lesen Sie die Überlegungen zu Berichten unten.

Überlegungen zu Salesforce Connect

Die Salesforce Connect-Lösung hat folgende Überlegungen:

Sicherheitsüberlegungen

Lösungen für dieses Muster sollten die standardmäßige Sicherheit auf Salesforce-Organisationsebene einhalten. Es wird empfohlen, das HTTPS-Protokoll zu verwenden, um eine Verbindung mit einem Remote-System herzustellen. Weitere Details finden Sie unter Sicherheitsüberlegungen.

Wenn Sie einen Odata Konnektor verwenden, machen Sie sich mit den besonderen Verhaltensweisen, Einschränkungen und Empfehlungen für Cross-Site Request Forgery (CSRF) für externe Odata Datenquellen vertraut. Weitere Informationen finden Sie unter CSRF-Überlegungen zu Salesforce Connect – Odata 2.0- und 4.0-Adaptern.

Randleisten

Keine.

Pünktlichkeit

Aktualität ist in diesem Muster von erheblicher Bedeutung. Beachten Sie folgende Punkte:

  • Die Anforderung wird in der Regel über die Benutzeroberfläche aufgerufen, sodass der Benutzer nicht warten muss.
  • Je nach Verfügbarkeit und Verbindung mit dem externen System kann das Abrufen externer Daten lange dauern. Salesforce verfügt über einen konfigurierbaren maximalen Zeitüberschreitungswert von 120 Sekunden, um auf eine Antwort des externen Systems zu warten.
  • Der Abschluss des Remote-Prozesses sollte zeitnah und innerhalb der Salesforce-Zeitüberschreitungsobergrenze und innerhalb der Erwartungen der Benutzer erfolgen.

Datenvolumen

Aufgrund der kleinen Zeitüberschreitungswerte und der maximalen Größe der Anforderung oder Antwort für die Apex-Anruflösung wird dieses Muster hauptsächlich für Echtzeitaktivitäten mit kleinem Volumen verwendet. Verwenden Sie dieses Muster nicht bei Batchverarbeitungsaktivitäten, bei denen die Datennutzlast in der Nachricht enthalten ist.

Unterstützung von Endpunktfunktionen und Standards

Die Unterstützung von Funktionen und Standards für den Endpunkt hängt von der von Ihnen ausgewählten Lösung ab.

Lösung Überlegungen zu Endpunkten
Salesforce Connect OData APIs: Verwenden Sie das Open Data Protocol, um auf Daten zuzugreifen, die außerhalb von Salesforce gespeichert sind. Die externen Daten müssen über Odata Producer verfügbar gemacht werden.

Andere APIs: Verwenden Sie das Apex Connector Framework, um Ihren eigenen benutzerdefinierten Adapter zu entwickeln, wenn die anderen verfügbaren Adapter nicht für Ihre Anforderungen geeignet sind. Ein benutzerdefinierter Adapter kann Daten aus einer beliebigen Quelle abrufen. Beispielsweise können einige Daten über Callouts aus dem Internet abgerufen werden, während andere Daten programmgesteuert bearbeitet oder sogar generiert werden können.

Mit Salesforce verbinden: Verwendet die Lightning Platform-REST-API, um auf Daten zuzugreifen, die in anderen Salesforce-Organisationen gespeichert sind.

Verbinden über Middleware

Verbinden über Middleware: Das Salesforce Connect Partner-Ökosystem hat eng mit Salesforce zusammengearbeitet, um sicherzustellen, dass ihre Middleware-Gateways OData Endpunkte aus ihrem Service bereitstellen, damit Salesforce ohne zusätzlichen Code eine Verbindung mit ihnen herstellen kann.
Anforderung & Antwort Apex SOAP Callouts –

Der Endpunkt muss in der Lage sein, einen Webserviceaufruf über HTTP zu empfangen.

Apex HTTP Callouts –

Der Endpunkt muss HTTP-Aufrufe empfangen können.

Sie können Apex HTTP-Callouts verwenden, um RESTful-Services mit den Standardmethoden GET, POST, PUT und DELETE aufzurufen.

Statusverwaltung

Bei der Integration von Systemen sind Schlüssel für die fortlaufende Statusverfolgung wichtig. Wenn beispielsweise ein Datensatz im Remote-System erstellt wird, benötigt der Datensatz in der Regel eine Art Identifikationsschlüssel, um laufende Aktualisierungen zu unterstützen. Es gibt zwei Optionen zum Speichern von Schlüsseln.

  • Salesforce speichert den primären oder eindeutigen Ersatzschlüssel für den Remote-Datensatz.
  • Das Remote-System speichert die eindeutige Salesforce-Datensatz-ID oder einen anderen eindeutigen Ersatzschlüssel. Für die Verarbeitung von Integrationsschlüsseln in diesem synchronen Muster gibt es spezifische Überlegungen.
Mastersystem Beschreibung
Salesforce Das Remote-System speichert entweder die Salesforce-Datensatz-ID oder einen anderen eindeutigen Ersatzschlüssel aus dem Datensatz.
Remote-System Der Aufruf des Remote-Prozesses gibt den eindeutigen Schlüssel aus der Anwendung zurück und Salesforce speichert diesen Schlüsselwert in einem eindeutigen Datensatzfeld.

Komplexe Integrationen

In bestimmten Fällen kann die durch dieses Muster vorgeschriebene Lösung die Implementierung eines komplexen Integrationsszenarios erfordern. Diese Szenarien werden häufig mit Middleware gelöst.

  • Aggregation von Anrufen und deren Ergebnissen über mehrere Systeme hinweg
  • Transformation von eingehenden und ausgehenden Nachrichten
  • Aufrechterhalten der transaktionalen Integrität über mehrere Aufrufe hinweg
  • Andere Prozessorchestrierungsaktivitäten zwischen Salesforce und dem externen System

Obergrenzen

Für verschiedene Adapter gelten unterschiedliche Obergrenzen. Weitere Details finden Sie unter Allgemeine Obergrenzen für Salesforce Connect.

Middleware-Funktionen

In der folgenden Tabelle werden die wünschenswerten Eigenschaften eines Middleware-Systems hervorgehoben, das an diesem Muster teilnimmt.

Eigenschaft Obligatorisch Wünschenswert Nicht erforderlich
Ereignisverarbeitung X
Protokollkonvertierung X
Übersetzung und Transformation X
Warteschlange und Pufferung X
Synchrone Transportprotokolle X
Asynchrone Transportprotokolle X
Vermittlungsweiterleitung X
Prozesschoreografie und Serviceorchestrierung X
Transaktionalität (Verschlüsselung, Signieren, zuverlässige Zustellung, Transaktionsverwaltung) X
Weiterleitung X
Extrahieren, Umwandeln und Laden X
Lange Abstimmung X

Externe Objektbeziehungen

Externe Objekte unterstützen Standard-Nachschlagebeziehungen, die die 18-stellige Salesforce-Datensatz-ID verwenden, um verwandte Datensätze zuzuordnen. Daten, die außerhalb Ihrer Salesforce-Organisation gespeichert sind, enthalten diese Datensatz-IDs jedoch oft nicht. Daher sind für externe Objekte zwei spezielle Arten von Nachschlagebeziehungen verfügbar: externe Nachschlagevorgänge und indirekte Nachschlagevorgänge.

In dieser Tabelle sind die Beziehungstypen zusammengefasst, die für externe Objekte verfügbar sind.

Beziehung Zulässige untergeordnete Objekte Zulässige übergeordnete Objekte Übergeordnetes Feld für übereinstimmende Datensätze
Nachschlagen Standard, benutzerdefinierte, externe Standard, benutzerdefinierte Die 18-stellige Salesforce-Datensatz-ID
Externes Nachschlagen Standard, benutzerdefinierte, externe Extern Das Standardfeld "Externe ID"
Indirektes Nachschlagen Extern Standard, benutzerdefinierte Auswählen eines benutzerdefinierten Felds mit den Attributen "Externe ID" und "Eindeutig"

Überlegungen zu hohem Datenvolumen für Salesforce Connect – Odata 2.0- und 4.0-Adapter

Wenn Ihre Organisation beim Zugriff auf externe Objekte Ratenobergrenzen erreicht, sollten Sie die Option Hohes Datenvolumen für die zugeordneten externen Datenquellen auswählen. Dadurch werden die meisten Ratenobergrenzen umgangen, es gelten jedoch einige spezielle Verhaltensweisen und Einschränkungen. Weitere Informationen finden Sie unter Überlegungen zu hohem Datenvolumen für Salesforce Connect.

Clientgesteuerte und servergesteuerte Paginierung für Salesforce Connect – Odata 2.0- und 4.0-Adapter

Es ist üblich, dass Salesforce Connect-Abfragen von externen Daten eine große Ergebnismenge aufweisen, die in kleinere Batches oder Seiten unterteilt ist. Sie entscheiden, ob das Paginierungsverhalten durch das externe System (servergesteuert) oder durch den OData 2.0- oder 4.0-Adapter für Salesforce Connect (clientgesteuert) gesteuert werden soll. Das Feld "Servergesteuerte Paginierung" in der externen Datenquelle gibt an, ob die clientgesteuerte oder die servergesteuerte Paginierung verwendet werden soll. Wenn Sie die servergesteuerte Paginierung für eine externe Datenquelle aktivieren, ignoriert Salesforce die angeforderten Seitengrößen, einschließlich der standardmäßigen Batchgröße queryMore() von 500 Zeilen. Die vom externen System zurückgegebenen Seiten bestimmen die Batches. Jede Seite darf jedoch 2.000 Zeilen nicht überschreiten. Die Obergrenzen für die Odata Adapter für Salesforce Connect gelten jedoch weiterhin.

Beispiel

Ein Fertigungsunternehmen verwendet Salesforce zum Verwalten von Kundenvorgängen. Die Kundendienstagenten möchten auf die Echtzeit-Auftragsinformationen aus dem Back-Office-ERP-System zugreifen, um einen umfassenden Überblick über den Kunden zu erhalten, ohne sich damit vertraut machen und Berichte manuell im ERP ausführen zu müssen.

Wenn Sie die nach diesem Muster vorgeschriebene Lösung implementieren, sollten Sie:

  • Konfigurieren Sie Ihre externe Datenquelle mit einem Odata Endpunkt. Ihre Remote-Anwendung kann native Unterstützung für Odata enthalten. Für andere Anwendungen haben sich wichtige Integrationsanbieter wie Dell Boomi, Informatica, Jitterbit, MuleSoft und Progress Software mit Salesforce in Salesforce Connect zusammengetan, um Adapter zu erstellen.
  • Richten Sie Salesforce Connect direkt oder über eine Middleware-Lösung auf den Odata Endpunkt aus.
  • Synchronisieren Sie Ihre externen Datenbanktabellen mit externen Objekten in Salesforce. Wenn ein Benutzer auf eine Seite mit Daten aus diesen externen Objekten zugreift, sendet Salesforce Connect Callouts in Echtzeit an Ihre Backend-Anwendungen.

Entwicklerdokumentation

Trailhead

Alle Anwendungen müssen erstellt und in die entsprechenden Sicherheitsmechanismen integriert werden, um effektive Mitglieder des Unternehmensportfolios zu sein. Moderne IT-Strategien verwenden eine Kombination aus lokalen und Cloud-basierten Services.

Während sich die Integration von Cloud-zu-Cloud-Services in der Regel auf Webservices und die damit verbundene Autorisierung konzentriert, führt die Verbindung von lokalen und Cloud-Services oft zu einer erhöhten Komplexität. In diesem Abschnitt werden Sicherheitstools, -techniken und Salesforce-spezifische Überlegungen beschrieben.

Proxyserver umkehren

Ein Reverse-Proxy ist ein Server, der vor Webservern sitzt und Client-Anforderungen (z. B. Webbrowser) an diese Webserver weiterleitet. Reverse-Proxys werden in der Regel implementiert, um Sicherheit, Leistung und Zuverlässigkeit zu erhöhen.

Hierbei handelt es sich um einen Proxy-Servertyp, der Ressourcen im Namen eines Clients von einem oder mehreren Servern abruft. Diese Ressourcen werden dann an den Client zurückgegeben, als ob sie vom Proxy-Server selbst stammten. Im Gegensatz zu einem Weiterleitungs-Proxy, bei dem es sich um einen Vermittler für die zugehörigen Clients handelt, die mit einem Server in Kontakt treten, ist ein Reverse-Proxy ein Vermittler für die zugehörigen Server, die von einem beliebigen Client kontaktiert werden.

In Salesforce-Implementierungen wird ein solcher Service in der Regel über ein externes Gateway-Produkt bereitgestellt. Beispielsweise können Open-Source-Optionen wie Apache HTTP, lighttpd und nginix verwendet werden. Zu den kommerziellen Produkten zählen IBM WebSeal und Computer Associates SiteMinder. Diese Produkte können einfach so konfiguriert werden, dass alle ausgehenden Salesforce-Anforderungen im Namen des internen Anforderers proxymäßig verwaltet werden.

Verschlüsselung

In einigen Unternehmen müssen ausgewählte Transaktionen oder Datenfelder zwischen einer Kombination aus lokalen und Cloud-basierten Anwendungen verschlüsselt werden. Wenn Ihre Organisation zusätzliche Compliance-Anforderungen einhalten muss, können Sie Alternativen implementieren, darunter:

  • Lokale Gateway-Services für die kommerzielle Verschlüsselung, einschließlich der eigenen Salesforce-Services CipherCloud, IBM DataPower und Computer Associates. Für jede Lösung wird das Verschlüsselungsmodul oder Gateway an der Transaktionsgrenze aufgerufen, indem eine verschlüsselte Nutzlast gesendet und empfangen wird oder wenn bestimmte Datenfelder verschlüsselt oder entschlüsselt werden, bevor die HTTP(S)-Anforderung ausgeführt wird.

  • Cloud-basierte Optionen, beispielsweise Salesforce Shield Platform Encryption. Die Shield Platform Encryption bietet Ihren Daten eine völlig neue Sicherheitsebene und behält gleichzeitig wichtige Plattformfunktionen bei. Die von Ihnen ausgewählten Daten werden im Leerlauf mit einem erweiterten Schlüsselableitungssystem verschlüsselt. Sie können Ihre Daten sicherer als je zuvor schützen. Weitere Informationen finden Sie in der Salesforce-Online-Hilfe.

Spezielle WS-*-Protokollunterstützung

Um die Anforderungen von Sicherheitsprotokollen (wie WS-*) zu erfüllen, werden die folgenden Alternativen empfohlen.

  • Security/XML-Gateway: Fügen Sie WS-Security-Anmeldeinformationen (IBM WebSeal oder Datapower, Layer7, TIBCO usw.) in den Transaktionsstrom selbst ein. Für diesen Ansatz sind keine Änderungen an Webservices auf Anwendungsebene oder Webserviceaufrufen von Salesforce erforderlich. Sie können diesen Ansatz auch in der gesamten Salesforce-Installation wiederverwenden. Sie erfordert jedoch zusätzliches Design, Konfiguration, Tests und Wartung, um die entsprechende WS-Security-Injection in den vorhandenen Sicherheits-Gateway-Ansatz zu verwalten.

  • Verschlüsselung auf Transportebene: Verschlüsseln Sie den Kommunikationskanal mit bidirektionalen SSL- und IP-Einschränkungen. Dieser Ansatz implementiert das WS-*-Protokoll zwar nicht direkt, sichert jedoch den Kommunikationskanal zwischen den lokalen Anwendungen und Salesforce, ohne einen Benutzernamen und ein Kennwort weiterzugeben. Außerdem sind keine Änderungen an von Salesforce generierten Klassen erforderlich. Es können jedoch einige Änderungen an lokalen Webservices erforderlich sein (entweder in der Anwendung selbst oder auf Middleware-/ESB-Ebene).

  • Benutzerdefinierte Salesforce-Entwicklung: Fügen Sie der ausgehenden SOAP-Anforderung über das Dienstprogramm WSDL2Apex WS-Security-Kopfzeilen hinzu. Dadurch wird eine Java-ähnliche Apex-Klasse aus der WSDL-Datei generiert, die zum Aufrufen des internen Service verwendet wird. Für diesen Ansatz sind keine Änderungen an Backend-Webservices oder zusätzlichen Komponenten in der DMZ erforderlich, jedoch Folgendes:

    • Mehr Aufwand beim Erstellen und Testen
    • Ein relativ komplexer und manueller Prozess zum manuellen Codieren der WS-Security-Attribute (einschließlich XML-Serialisierung im Apex Code)
    • Höherer langfristiger Wartungsaufwand

Notiz: Die letzte Option wird aufgrund ihrer Komplexität und des Risikos, dass solche Integrationen regelmäßig auf der Grundlage regelmäßiger Aktualisierungen an Salesforce überprüft werden müssen, nicht empfohlen.

Andere Sicherheitsüberlegungen

  • Anmeldeinformationen mit Namen: Anmeldeinformationen mit Namen sollen authentifizierte API-Callouts in externen Systemen schützen und vereinfachen und geben den URL eines Callout-Endpunkts und seine erforderlichen Authentifizierungsparameter in einer Definition an. Geben Sie als Callout-Endpunkt Anmeldeinformationen mit Namen an, um Ihren Apex Code zu optimieren und die Einrichtung authentifizierter Callouts zu vereinfachen. Weitere Details finden Sie hier.

  • OAUTH 2.0: OAuth 2.0 ist ein branchenübliches Autorisierungs-Framework, mit dem ein Benutzer einer Drittanbieteranwendung eingeschränkten Zugriff auf seine geschützten Ressourcen gewähren kann, ohne seine Anmeldeinformationen (wie Kennwörter) freizugeben. Anstelle eines direkten Kennwortaustauschs genehmigt der Benutzer eine Zugriffstokenanforderung, mit der die Anwendung dann über einen Ressourcenserver auf die Daten des Benutzers zugreift. Bei diesem Vorgang wird die Client-Anwendung von der Identität und dem Kennwort des Benutzers getrennt, wodurch die Sicherheit erhöht wird, indem ein temporärer, umfangsspezifischer "Schlüssel" für den Zugriff auf Ressourcen bereitgestellt wird. Weitere Informationen finden Sie hier.

  • Private Connect: Wenn Sie Ihre Salesforce-Organisation in Anwendungen integrieren, die in Drittanbieter-Cloud-Services gehostet werden, ist es wichtig, HTTP/s-Datenverkehr sicher senden und empfangen zu können. Erhöhen Sie mit Private Connect die Sicherheit Ihrer Amazon Web Services-Integrationen (AWS), indem Sie eine vollständig verwaltete Netzwerkverbindung zwischen Ihrer Salesforce-Organisation und Ihrer AWS Virtual Private Cloud (VPC) einrichten. Leiten Sie dann Ihren cloudübergreifenden Datenverkehr über die Verbindung statt über das öffentliche Internet weiter, um die Gefährdung durch Sicherheitsbedrohungen von außen zu reduzieren. Private Connect ist in Partnerschaft mit AWS über eine Funktion namens AWS PrivateLink verfügbar. Private Connect ist bidirektional: Sie können eingehenden und ausgehenden Datenverkehr initiieren. Bei eingehenden Verbindungen können Sie Datenverkehr mithilfe der Standard-APIs an Salesforce senden. Und mit ausgehenden Verbindungen können Sie über Funktionen wie Apex Callouts, externe Services und externe Objekte Datenverkehr aus Salesforce senden. Weitere Informationen zu VPC finden Sie hier.

Mit dem Salesforce-Ereignis-Bus mit Plattformereignissen, Change Datenerfassung (CDC) und der Pub/Sub-API können Unternehmen ereignisgesteuerte Stilarchitekturen erstellen.

Ein EDA entkoppelt Ereignisnachrichten-Verbraucher (Abonnenten) von Ereignisnachrichten-Produzenten (Publishern), was eine größere Skalierung und Flexibilität ermöglicht. Bestimmte Muster werden in diesem Dokument als Teil der vorhandenen Musterstruktur behandelt, die zugehörige Alternativen oder Optionen vergleichen und kontrastieren. Wenn Sie jedoch ein ganzheitliches Verständnis der ereignisgesteuerten Architektur und des Zusammenspiels von Mustern erhalten, können Sie das richtige Muster für Ihre Anforderungen auswählen.

Khalid Mohammed ist ein herausragender Architekt der Professional Services von Salesforce. Seit seinem Wechsel zu Salesforce im Jahr 2015 hat er seine umfassende Expertise in den Bereichen Enterprise Application und Architecture genutzt und vor seiner Amtszeit bei Salesforce zahlreiche Kundentransformationen durchlaufen. Khalid leitet das Delivery Architecture Board und wird auch als führender zertifizierter technischer Architekt anerkannt.

Gulal Kumar ist Software-Engineering-Architekt bei Salesforce mit Schwerpunkt auf Daten- und Integrationsarchitektur. Mit über 20 Jahren Erfahrung in Integration und APIs, Modernisierungsprogrammen, Sicherheit und AIML-Initiativen bringt er eine Fülle von Expertise mit. Gulal hat sich verpflichtet, Initiativen zur Geschäftstransformation voranzutreiben, Sicherheit und Widerstandsfähigkeit zu erhöhen, Architekturexzellenz zu fördern und AIML-Initiativen in verschiedenen Bereichen voranzutreiben.

Sushant ist technischer Architekt bei Salesforce und spezialisiert sich auf die Lösungsarchitektur und die durchgängige Bereitstellung von Salesforce-Plattformen. Mit seiner umfassenden Expertise in den Bereichen Plattform-Governance, Anwendungsentwicklung, Integration und DevOps hat er zahlreiche branchenübergreifende Kundentransformationsprogramme geleitet. Sushant ist bestrebt, herausragende Bereitstellungsergebnisse und skalierbare Architekturergebnisse zu erzielen.