Integration Patterns Overview (Übersicht über Integrationsmuster)
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. Wir haben diese Inhalte aus vielen erfolgreichen Implementierungen destilliert.
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 den Leitfaden zur Musterzusammenfassung und Musterauswahl. Architekten und Entwickler sollten diese Musterdetails und bewährten Vorgehensweisen während der Entwurfs- und Implementierungsphase eines Salesforce-Integrationsprojekts anwenden.
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, aber diese Integration fällt nicht in den Geltungsbereich dieses Dokuments.
Mustervorlage
Jedes Integrationsmuster folgt einer konsistenten Struktur. Durch diese Struktur können Muster einfacher verglichen und relevante Informationen gefunden werden.
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
| 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 Salesforce Platform gespeicherte Daten werden erstellt oder aktualisiert, um Aktualisierungen aus einem externen System widerzuspiegeln und wenn Änderungen von Salesforce 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, sodass 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 Daten anzeigen, suchen und ändern muss, die in einem externen System gespeichert sind. 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. Daten: 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. Virtuell: 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 anhand des Zeitpunkts an: Synchron oder Asynchron. Synchron: Blockierungs- und Echtzeitanforderungen sind Anforderungs-/Antwortvorgänge. Das Ergebnis wird über diesen Vorgang sofort an den Anrufer zurückgegeben. Asynchron: Anforderungen ohne Blockierung, Warteschlange oder nachrichtenbasierte Anforderungen werden nahezu in Echtzeit durch einen unidirektionalen Vorgang aufgerufen. Die Ergebnisse und etwaige Fehler werden durch Aufrufen anderer Einbahnvorgä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:
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 mithilfe des Salesforce-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. Während Middleware für komplexe Transformationen weiterhin bevorzugt wird, ist die Salesforce Platform ausgereift. OmniStudio-Integrationsverfahren, die Flow-Datenzuordnung und Apex mit modernen Mustern sind für moderate Transformationen geeignet. |
| 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 asynchrone Funktionen in Form von Datenerfassung und Plattformereignissen ändern mit der Pub/Sub-API. 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. Ein Mediator stellt sicher, dass die richtige Botschaft den richtigen Verbraucher erreicht. |
| 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:
Die native Salesforce-Flow-Orchestrierung bietet lang andauernde Prozesse mit mehreren Schritten und Hintergrund-, interaktiven und MuleSoft-Schritten. Die nativen Funktionen können ohne Middleware orchestriert werden, indem die integrierte Phasenverwaltung und die Zuweisungsweiterleitung verwendet werden. Es wird empfohlen, alle komplexen systemübergreifenden Orchestrierungen auf Middleware-Ebene zu implementieren, um Salesforce-Zeitüberschreitungen und -Obergrenzen zu vermeiden, 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 diese Kriterien von der Middleware-Ebene oder vom Endpunkt erfüllt werden. Die Nachrichtenweiterleitung kann jedoch auch in Apex codiert werden. |
| Extrahieren, Umwandeln und Laden | Extrahieren, transformieren und laden (Extract, Transform and Load, ETL) bezieht sich auf einen Prozess, der Folgendes umfasst:
Salesforce unterstützt 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.
|
Zusätzlich zu diesen Integrationstools bieten MuleSoft und Informatica die Grundlage für eine moderne, leistungsstarke Integrationsstrategie. Beide befinden sich im selben Ökosystem, lösen jedoch unterschiedliche architektonische Herausforderungen. Führende Unternehmen stellen diese Plattformen gleichzeitig bereit, um ein umfassendes Framework für „bessere Zusammenarbeit“ zu erstellen, das das gesamte Spektrum der Daten- und Anwendungsanforderungen abdeckt.
MuleSoft ist die führende Integrationsplattform von Salesforce. Dadurch können Organisationen Anwendungen, Daten und Geräte lokal und Cloud-Umgebungen miteinander verbinden. MuleSoft bietet der IT die Tools, um Daten systemübergreifend freizugeben, skalierbare Integrations- und Automatisierungs-Frameworks zu entwickeln und differenzierte, verbundene Erfahrungen in kürzester Zeit zu erstellen. Sie kann auch eine Kernorganisation mit einer Anypoint-Instanz in einem API-Katalog verbinden, um MuleSoft-APIs für den Aufruf in Apex, Flow und Agentforce als Aktionen verfügbar zu machen. Anypoint Exchange verfügt über eine Reihe vorgefertigter Salesforce-Konnektoren.
Informatica ist eine führende Plattform für die Verwaltung und Integration von Unternehmensdaten. Sie hilft Organisationen beim Sammeln, Verwalten, Integrieren und Analysieren von Daten aus verschiedenen Quellen. Es verwendet ETL-Prozesse (Extract, Transform, Load), um die verbundenen, zuverlässigen Daten bereitzustellen, die für moderne Analysen und autonome AI-Agenten erforderlich sind.
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:
|
| 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, um diese Apex-Proxy-Klasse auszuführen und den Remote-Aufruf mithilfe von Anmeldeinformationen mit Namen auszuführen. Für Lightning-Seiten muss die Salesforce-Anwendung angepasst werden. |
| HTTP-Callout-Aktion in Flow | Gut | Diese Lösung ermöglicht synchrone ausgehende REST-Aufrufe deklarativ über Flow ohne Apex und ohne den vollständigen Registrierungsprozess für externe Services. Sie eignet sich gut für die deklarative Implementierung, wenn keine vollständige OpenAPI-Spezifikation verfügbar ist. |
| 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
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 Fehlerverarbeitung. 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, verarbeiten Sie die Identitätsbestimmung auf Integrationsebene, insbesondere wenn keine Garantie dafür besteht, dass Salesforce den Anruf nur einmal aufruft.
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. Für die private und sichere Kommunikation unterstützt Salesforce auch Salesforce Private Connect über die Hyperforce Platform. 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. Verwenden Sie Anmeldeinformationen mit Namen, um den Endpunkt und die erforderliche Authentifizierung zu definieren, und implementieren Sie keinen eigenen Authentifizierungsmechanismus. |
| Apex SOAP-Callouts | Der Endpunkt muss HTTP-Aufrufe empfangen können. Salesforce muss über das öffentliche Internet auf den Endpunkt zugreifen können. Für die private und sichere Kommunikation unterstützt Salesforce auch Salesforce Private Connect über die Hyperforce Platform. 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. Die Webservicestandards, die derzeit von Salesforce für Apex SOAP-Callouts unterstützt werden, lauten:
|
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 | Systembeschreibung |
|---|---|
| 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 Abstimmung | X | ||
| gRPC-Unterstützung (für die Pub/Sub-API) | X |
Beispiel
Ein Versorgungsunternehmen verwendet Salesforce und verfügt über ein separates System, das Kundenabrechnungsinformationen enthält. Im Rahmen des Bestellvorgangs müssen neue Abrechnungsaccounts im Abrechnungssystem erstellt werden. Salesforce sollte die Rechnungskontonummer im Rahmen des Auftragsaktivierungsprozesses berücksichtigen. Das Unternehmen verfügt über eine vorhandene REST-API, die die Erstellung eines Abrechnungsaccounts ermöglicht und die Abrechnungsaccountnummer als Antwort zurückgibt.
Diese Anforderung kann mit folgendem Ansatz gelöst werden.
- Salesforce verwendet die HTTP-API des Abrechnungsaccounts als externen Service oder Flow-HTTP-Callout. Wenn das Abrechnungssystem nur SOAP-basierte Services und keine HTTP-APIs bereitstellt, sollte für die Nutzung von SOAP-Services nur eine Apex Proxy-Klasse verwendet werden.
- Kundeninformationen werden an das externe HTTP-API-Objekt übergeben.
- Der externe Service oder HTTP-Flow-Callout gibt die Antwort der HTTP-API zurück, die in Salesforce-Objekten gespeichert werden kann.
In diesem Beispiel wird Folgendes veranschaulicht: - Der Kundenstatus wird mit einer Accountnummer verfolgt, die im Salesforce-Accountobjekt gespeichert ist.
- Anschließend verarbeitet der Anrufer die Antwortnachricht.
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 mithilfe der Salesforce Pub/Sub-API anhören, 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:
|
| 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. Anschließend synchronisiert die Anwendung die Änderungen im ERP-System. |
| Ereignisweiterleitung | Best (mit AWS-Integrationen) | Die Salesforce-Ereignisweiterleitung bietet eine serverlose Low-Code-Echtzeitintegration, mit der Ereignisse der Salesforce Platform-Ereignisse und der Datenerfassung (CDC) direkt an Amazon EventBridge übertragen werden können. Salesforce-Ereignisweiterleitungen senden diese Ereignisse von Salesforce an Amazon Web Services (AWS) und erreichen einen durchgängigen Ereignis-Flow, indem sie Ereignisse zurück an Salesforce senden. Mit der Ereignisweiterleitung können Ereignisse nativ an AWS übertragen werden, ohne eine Integrationsanwendung schreiben zu müssen. |
| 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:
|
| 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 | Suboptimal | Dies ist eine veraltete Integrationsweise und kann verwendet werden, wenn der Remote-Prozess über ein Einfüge- oder Aktualisierungsereignis aufgerufen wird. Salesforce bietet diese Flow-gesteuerte Funktion für ausgehende Nachrichten, um SOAP-Nachrichten an Remote-Systeme zu senden, 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. Dies ist eine veraltete Art der Integration. Alle neuen Lösungen sollten Flow mit der Pub/Sub-API verwenden. |
| 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 mit Anmeldeinformationen mit Namen 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.
In diesem Szenario:
- Ein Remote-System abonniert das Plattformereignis.
- Eine Aktualisierung oder Einfügung erfolgt für einen bestimmten Satz von Datensätzen in Salesforce.
- Ein Salesforce-Flow wird ausgelöst, wenn eine Reihe von Bedingungen erfüllt ist.
- Dieser Flow erstellt ein Plattformereignis.
- Der Remote-Listener empfängt die Ereignismeldung und stellt sie in eine lokale Warteschlange.
- 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. |
| 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 |
|
| Apex Callouts mit Anmeldeinformationen mit Namen |
|
| Datenerfassung ändern / Plattformereignisse |
|
Ü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.
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 mit Anmeldeinformationen mit Namen | 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.
|
| 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 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 zum Abrufen vergangener Ereignismeldungen Pub/Sub-APIs, um einen Kanal zu abonnieren.
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:
|
| 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 |
|
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 | Systembeschreibung |
|---|---|
| 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 mit Anmeldeinformationen mit Namen | 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:
|
| 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. Es enthält keine Details über die Ä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 mit Anmeldeinformationen mit Namen | 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 Abstimmung | X (erforderlich für Streaming-API) | ||
| gRPC-Unterstützung (für die Pub/Sub-API) | X |
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 kann gRPC und HTTP2 unterstützen, sodass Salesforce Pub/Sub-APIs zum Abonnieren von Plattformereignissen verwendet werden können.
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:
- Die Integrationstools (z. B. ESB) abonnieren das Salesforce Platform-Ereignis über die Pub/Sub-API.
- 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 mithilfe von OAuth 2.0 mit einer verbundenen Anwendung 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. |
| Data 360 und Datenaktionen und -aktivierungen | Best | Daten 360 | Verschieben Sie Daten mithilfe von Data 360-Aktionen und -Aktivierungen zwischen Organisationen. Nachdem Daten aus verschiedenen Organisationen in Data 360 aufgenommen wurden, können Datenaktionen und Aktivierungen die Daten mit einer anderen Organisation synchronisieren. Dieser Ansatz kann für Integrationen in Marketing Cloud-Organisationen sehr nützlich sein. |
| Data 360, Datendiagramme und Connect-APIs | Best | Daten 360 | Extrahieren und verschieben Sie Daten mit MuleSoft Anypoint. MuleSoft Ein Nypoint kann verwendet werden, um Daten aus Data 360 mithilfe der Connect-API und der Datendiagramm-API zu extrahieren und in eine andere Salesforce-Organisation zu verschieben. Ohne Data 360 kann MuleSoft Anypoint auch verwendet werden, wenn Daten zwischen Organisationen verschoben werden müssen, ohne dass sie in Data 360 repliziert werden. |
| API für zusammengesetzte Diagramme | Best | Salesforce | Mit der Ressource für zusammengesetzte Diagramme können Sie Vorgänge für zusammengesetzte Diagramme senden. Diese Ressource ist in der REST-API-Version 50.0 und höher verfügbar. Die API für zusammengesetzte Diagramme kann bis zu 75 Diagramme in einer Nutzlast und maximal 500 Knoten in einem Diagramm unterstützen. |
| 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 finden Sie in der Data Loader-Dokumentation. |
| 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.
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:
- Das externe 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 Einheiten. 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 erstellt Programme, die Folgendes bewirken:
- Lesen Sie eine Steuertabelle, um die letzte Laufzeit des Auftrags zu bestimmen, und extrahieren Sie alle anderen erforderlichen Steuerwerte.
- Verwenden Sie die obigen Steuerwerte als Filter und fragen Sie das Quelldatenset ab.
- Wenden Sie vordefinierte Verarbeitungsregeln an, einschließlich Validierung, Anreicherung usw.
- Verwenden Sie die verfügbaren Konnektoren/Umwandlungsfunktionen des ETL-Tools, um das Ziel-Datenset zu erstellen.
- Schreiben Sie das Datenset in Salesforce-Objekte.
- Wenn die Verarbeitung erfolgreich ist, aktualisieren Sie die Steuerwerte in der Steuertabelle.
- 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 |
|
| "Lesen" aus Salesforce mithilfe eines Drittanbieter-ETL-Systems |
|
| Schreiben in Salesforce |
|
| 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.
- Für den authentifizierten API-Zugriff auf die Salesforce-API ist eine Lightning Platform-Lizenz mit mindestens 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 zur Implementierung dieses Musters sind traditionelle ETL-Tools wie Informatica oder MuleSoft. Es ist wichtig, dass die ausgewählten Middleware-Tools die Salesforce Bulk-API unterstützen.
Middleware sollte den zuletzt erfolgreich verarbeiteten Zeitstempel intern oder extern für Wasserzeichen speichern können. Dieser zuletzt erfolgreich verarbeitete Zeitstempel sollte verwendet werden, um die Änderungen seit der letzten erfolgreichen Ausführung zu nutzen.
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) | ||
| gRPC-Unterstützung (für die Pub/Sub-API) | X |
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, bei der es sich um eine REST-API handelt und die zusammengesetzte Anforderungen unterstützt. Dies kann von Remote-Systemen für folgende Zwecke verwendet werden:
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. |
| API für zusammengesetzte Diagramme | Best | Mit der Ressource für zusammengesetzte Diagramme können Sie Vorgänge für zusammengesetzte Diagramme senden. Diese Ressource ist in der REST-API-Version 50.0 und höher verfügbar. Die API für zusammengesetzte Diagramme kann bis zu 75 Diagramme in einer Nutzlast und maximal 500 Knoten in einem Diagramm unterstützen. |
| REST-API | Best | Barrierefreiheit: Salesforce bietet eine REST-API, die Remote-Systeme für folgende Zwecke verwenden können:
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. Die Bulk-API 2.0 verarbeitet Batches immer parallel und unterstützt den seriellen Modus nicht. Das bedeutet, dass:
|
| GraphQL-API | Best | Für Remote-Aufrufszenarien mit komplexen Lesevorgängen mit mehreren Objekten und ausgewählten Feldern ist GraphQL eine bessere Option als die REST-API. |
| 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:
|
| 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/
Da Plattformereignisse SObjects sind, werden standardmäßige SOAP-API-Vorgänge unterstützt. |
| SOAP-API | Suboptimal | Barrierefreiheit: Salesforce bietet eine SOAP-API, die Remote-Systeme für folgende Zwecke verwenden können:
Generierte WSDL: Salesforce bietet zwei WSDLs für Remote-Systeme:
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. Für SOAP sind umfangreiche Knowledge über das Salesforce-Objektmodell, die API-Mechanismen und die Verarbeitung von SOAP-Nachrichten erforderlich. Diese zusätzlichen Faktoren machen REST gegenüber SOAP vorzuziehen. |
| 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.
Gilt nicht für Plattformereignisse, da die Logik zum Vorabeinfügen von Transaktionen beim Verbraucher in einer ereignisgesteuerten Architektur nicht angewendet wird. Verwenden Sie die SOAP-API, die REST-API oder die Bulk-API 2.0, um eine Salesforce-Organisation über ein aufgetretenes Ereignis zu benachrichtigen. Für SOAP sind umfangreiche Knowledge über das Salesforce-Objektmodell, die API-Mechanismen und die Verarbeitung von SOAP-Nachrichten erforderlich. Diese zusätzlichen Faktoren machen REST gegenüber SOAP vorzuziehen. |
| 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 in einer ereignisgesteuerten Architektur nicht angewendet wird. 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-Systemabfrage in Salesforce über die REST-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 Pub/Sub-API-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 sollte OAuth 2.0 für die Authentifizierung und Autorisierung verwenden. Der Client muss die HTTP-Autorisierungskopfzeile mit dem entsprechenden Wert wie einem OAuth-Zugriffstoken festlegen. 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: Erstellen Sie einen benutzerdefinierten Mechanismus für Wiederholungen, 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 | Salesforce unterstützt Transport Layer Security-Protokolle (TLS 1.2 oder höher). Die Schlüssellänge muss mindestens 128 Bit betragen. |
| 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 wird empfohlen, dass Clients, die die REST-API aufrufen, das OAuth-Token anschließend zwischenspeichern und erneut verwenden, um die Leistung zu maximieren, statt für jeden Aufruf ein neues OAuth-Token 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 |
|
| 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 | Systembeschreibung |
|---|---|
| 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 |
|
| Bulk-API 2.0 | Weitere Informationen finden Sie unter Randleiste für Datenvolumen. |
| Plattformereignisse |
|
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) | ||
| gRPC-Unterstützung (für die Pub/Sub-API) | X |
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. Sie stellen auch dauerhafte Themen mit einem Zeitfenster von 72 Stunden sicher. Dieses Fenster garantiert, 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
- Pub/Sub API (basierend auf gRPC und HTTP/2) für eine effiziente Nutzung von Plattformereignissen
- Eine Lightning-Komponente
- Eine als statische Ressource enthaltene JavaScript-Bibliothek
Skizze
Im folgenden Diagramm wird veranschaulicht, wie die Pub/Sub-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. Weitere Details finden Sie im Pub/Sub API Developer Guide.
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 einen Apex-Auslöser, der 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 die Pub/Sub-API, 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:
|
| Data 360 und Zero Copy | Best | Wenn ein Datensatz in externen Systemen wie ERP aktualisiert wird, können die Datensatzaktualisierungen mit Data 360 synchronisiert werden, entweder mithilfe der vorkonfigurierten Konnektoren oder mithilfe von APIs und Pro-Code-Tools wie MuleSoft. Datensätze können auch in Data 360 mit dem Zero-Copy-Mechanismus referenziert werden (auf einigen Plattformen verfügbar). Sobald Daten in Data 360 verfügbar sind, können verschiedene vorkonfigurierte Integrationsmechanismen zum Synchronisieren der Daten mit anderen Salesforce-Organisationen verwendet werden. Auf Daten kann mit Data Cloud One per Verweis zugegriffen werden. Daten können auch mithilfe von Aktivierungen und anderen APIs mit vorkonfigurierten Konnektoren oder mit Pro-Code-Tools wie der MuleSoft Anypoint Platform repliziert werden. Hinweis: Daten in Data 360 können nicht bearbeitet werden. Verwenden Sie Salesforce Connect, wenn dies erforderlich ist. |
| Data 360, Data Cloud One und Salesforce | Best | Harmonisieren Sie Daten aus verschiedenen Quellen mit Data 360 und Data Cloud One. Über das Customer 360-Datenmodell, die Identitätsbestimmung, den Datenverbund und andere Funktionen konsolidiert Data 360 Daten aus Salesforce und anderen externen Systemen in einer einheitlichen Ansicht Ihres Kunden. Mit Data Cloud One können Benutzer in anderen Salesforce-Organisationen sicher auf virtuell freigegebene Daten aus Data 360 zugreifen. Hinweis: Daten in Data 360 können nicht bearbeitet werden. Verwenden Sie Salesforce Connect, wenn dies erforderlich ist. |
| 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:
- Der Browser führt einen AJAX-Aufruf aus, der wiederum eine Aktion für den entsprechenden externen Objektadapter ausführt.
- Der Adapter übersetzt die Aktion in eine Odata-Anforderung und sendet über die Integrations- und Serviceebenen eine HTTP GET-Anforderung an das Remote-System.
- Das Remote-System gibt eine JSON-Antwort über die Integrations- und Serviceebenen an Salesforce zurück.
- 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 Salesforce 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. |
| Lightning-Komponenten | 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:
- Externe Objekte verhalten sich wie benutzerdefinierte Objekte, einige Funktionen sind jedoch für externe Objekte nicht verfügbar. Weitere Informationen finden Sie unter Überlegungen zur Salesforce-Kompatibilität für Salesforce Connect.
- Externe Objekte können sich auf die Berichtsleistung auswirken. Weitere Informationen finden Sie unter Berichtsüberlegungen zu Salesforce Connect.
- Weitere Überlegungen zur Verwendung von Salesforce Connect-Adaptern finden Sie unter Überlegungen zu Salesforce Connect – Alle Adapter.
- Informationen zum Verwenden eines organisationsübergreifenden Adapters finden Sie unter Überlegungen zu Salesforce Connect – organisationsübergreifender Adapter.
- Wenn Sie die Verwendung eines Odata Adapters in Betracht ziehen, lesen Sie Überlegungen zu Salesforce Connect – Odata 2.0 und 4.0 Adaptern.
- Wenn Sie einen benutzerdefinierten Apex Adapter verwenden möchten, lesen Sie Überlegungen zu Salesforce Connect – Benutzerdefinierter Adapter.
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 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 |
|---|---|
| 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 Salesforce Platform-REST-API für den Zugriff auf Daten, die in anderen Salesforce-Organisationen gespeichert sind. 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 | ||
| gRPC-Unterstützung (für die Pub/Sub-API) | 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 Nachschlagebeziehungstypen 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
- Salesforce-Hilfe: Nur API-Zugriff für Integrationsbenutzer erteilen
- Übersicht über die Pub/Sub-API
- SOAP API Developer Guide (SOAP-API-Entwicklerhandbuch)
- REST API Developer Guide (REST-API-Entwicklerhandbuch)
- Streaming API Developer Guide
- Entwicklerhandbuch für Bulk-API 2.0 und Bulk-API
- Apex Developer Guide
- SOQL- und SOSL-Referenz
- Kurzreferenz für Salesforce-Entwicklerobergrenzen und -zuteilungen
- Entwicklerhandbuch für Plattformereignisse
- Salesforce Connect (Hilfe und Schulung)
- Apex Developer Guide: Salesforce Connect
- Grundlegendes zu Salesforce Connect
- Dauer der Nachricht für Plattformereignisse
- Entwicklerhandbuch für Anmeldeinformationen mit Namen
- Apex Developer Guides: Verwenden von Anmeldeinformationen mit Namen
- Anmeldeinformationen mit Namen (Hilfe und Schulung)
- Grundlegendes zu Anmeldeinformationen mit Namen
- Private Connect (Hilfe und Schulung)
- Grundlegendes zu Private Connect
Trailhead
- Große Datenvolumen
- Grundlagen von Plattformereignissen
- Grundlagen der Datenerfassung ändern
- Schnelleinstieg: Salesforce Connect
Salesforce geht zu schnelleren und ereignisgesteuerten Architekturen über. Die Migration von alten Integrationstools ist nun erforderlich, um sicher und skalierbar zu bleiben. Viele ältere Tools verwenden veraltete Protokolle wie SOAP oder Long Polling (CometD), die mit der effizienten gRPC-basierten Bereitstellung der Pub/Sub-API oder der Automatisierungsleistung von Flow Builder nicht Schritt halten können. Überprüfen Sie zunächst Ihre vorhandenen Integrationen, um hartcodierte Abhängigkeiten zu finden. Dies ist besonders wichtig, da Salesforce damit beginnt, Funktionen wie Salesforce-to-Salesforce (vollständig eingestellt bis Spring '27) und veraltete Authentifizierungsmethoden einzustellen. Verwenden Sie bei der Planung Ihrer Migration den Ansatz "Flow first" für interne Geschäftslogik und den Ansatz "Pub/Sub-first" für externe Datenströme. Dadurch erhalten Sie eine flexible, entkoppelte Architektur, die für die Datenanforderungen der heutigen AI-gestützten Plattform bereit ist.
Der login() in der Salesforce SOAP-API wird eingestellt. Sie ist bereits in API v65.0 und höher nicht verfügbar. In neuen Salesforce-Organisationen ist die login() standardmäßig deaktiviert und bestehende Organisationen benötigen die neue Berechtigung "Beliebige API-Authentifizierung verwenden", um sie weiterhin verwenden zu können. Die harte Frist endet in der Version Summer '27, wenn Salesforce die login() für alle API-Versionen (31.0 bis 64.0) vollständig einstellt.
| Produkt | Status | Vorgeschlagene Alternative | Migrationsstrategie |
|---|---|---|---|
| Ausgehendes Messaging | Veraltet (unterstützt) | Flow- und Plattformereignisse | Ersetzen Sie diese Option durch durch Flow-ausgelöste Plattformereignisse, um eine bessere Logik für Wiederholungen und eine moderne Authentifizierung zu erhalten. |
| Prozessgenerator | Ende der Unterstützung | Flow Builder | Verwenden Sie das Tool "Zu Flow migrieren", um vorhandene Prozesse zu konvertieren und komplexe Logik für die Leistung zu refaktorieren. |
| Salesforce-zu-Salesforce | Einstellung Spring '27 | Salesforce Connect oder die Pub/Sub-API | Umstellung auf Salesforce Change Datenerfassung, Salesforce Connect oder Pub/Sub API mit MuleSoft |
| Streaming-API | Veraltet (unterstützt) | Pub/Sub-API | Wechseln Sie zur Pub/Sub-API, um gRPC zu nutzen, das einen höheren Durchsatz und eine vereinfachte Abonnementverwaltung bietet. |
SOAP-API-login() | Alt (wird bis Juni 2027 unterstützt) | OAuth 2.0-Flows | Wechseln Sie mit externen Client-Anwendungen zu OAuth2.0. |
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 nginx 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 (MuleSoft, 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: Salesforce hat seine Authentifizierungsarchitektur umgestaltet, indem es ein zweistufiges Modell für Anmeldeinformationen mit Namen eingeführt hat, das die Bedenken zwischen Konnektivität und Identität klar voneinander trennt. Verwenden Sie dies, wenn Sie Callouts über Apex vornehmen, und vermeiden Sie die Erstellung Ihres eigenen Authentifizierungsprotokolls. Dies gewährleistet auch Erweiterbarkeit und mehr Sicherheit. Externe Anmeldeinformationen bilden die Grundlage dieses Modells. Sie speichern die tatsächlichen Authentifizierungsdetails und unterstützen einen umfangreichen Satz an Protokollen, einschließlich OAuth 2.0-Client-Anmeldeinformationen, JWT-Bearer und AWS Signature V4, während sie auch definieren, wie Prinzipale zugeordnet werden: entweder als einzelner benannter Prinzipal (für alle Benutzer freigegeben) oder als benutzerbasierter Prinzipal (wobei sich jeder Benutzer mit seiner eigenen Identität authentifiziert). Anmeldeinformationen mit Namen fungieren wiederum als Endpunktebene – sie definieren den Callout-URL und verweisen auf externe Anmeldeinformationen, um den Authentifizierungs-Handshake zu verarbeiten und die Endpunktkonfiguration sauber von der Anmeldeinformationenverwaltung zu trennen. Zum Aktivieren von Flows für die benutzerbasierte Authentifizierung ordnen Administratoren Berechtigungssätze dem entsprechenden Prinzipal für externe Anmeldeinformationen zu und stellen so sicher, dass nur Benutzer mit der richtigen Berechtigungssatzzuweisung Callouts unter ihrer eigenen Identität aufrufen können. Dieses zweistufige Design vereinfacht nicht nur die sichere Callout-Konfiguration, sondern bietet Architekten auch viel mehr Flexibilität und Kontrolle darüber, wie Integrationen in Salesforce-verbundenen Systemen authentifiziert werden. Weitere Details finden Sie in der Dokumentation zu Anmeldeinformationen mit Namen.
- OAuth 2.0: OAuth 2.0 ist ein branchenübliches Autorisierungs-Framework, mit dem Benutzer einer Drittanbieteranwendung eingeschränkten Zugriff auf ihre geschützten Ressourcen gewähren können, ohne ihre Anmeldeinformationen (z. B. 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 in der OAuth 2.0-Dokumentation. Für Endpunkte mit strenger OAuth 2.1-Konformität ist eine dritte Architekturklasse (External Auth Identity Provider) verfügbar, um die Interaktion mit dem IDP 2.1-konform zu verwalten.
- 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 finden Sie in der Dokumentation zu Private Connect.
Mit dem Salesforce-Ereignis-Bus mit Plattformereignissen, der 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 21 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 Verma ist Technische Architektin bei Salesforce und spezialisiert sich auf Lösungsarchitektur und 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.