Die Zahl der Anwendungsfälle rund um Salesforce-Integration nimmt kontinuierlich zu. Mit MuleSofts leistungsstarker Integrationsplattform können Sie Daten aus beliebigen Systemen freischalten und integrieren. So schöpfen Sie die Stärken von Salesforce Customer 360 optimal aus und schaffen ein vollständig vernetztes digitales Erlebnis.
Dieser Blog beschreibt Best Practices für das Team, das das Thema Salesforce-Integration mit MuleSoft umsetzt.
Vorbereitung: Das Integrationsteam
Das Projektteam setzt sich typischerweise aus Salesforce- und MuleSoft-Entwickler:innen und -Architekt:innen zusammen.
Die MuleSoft-Expert:innen sollten die Salesforce Workbench kennen und sich mit Basics rund um Orgs, Objekten, Properties und Parent-Child-Beziehungen vertraut machen. Die Salesforce-Profis wiederum sollten Grundkenntnisse im Umgang mit MuleSoft erwerben und sich mit API-gestützter Konnektivität, API-Wiederverwendung und Salesforce-Integrationsmustern auseinandersetzen.
Salesforce-Integration: Best Practices
#1 Geschäftsanforderungen verstehen
Planen Sie Sessions, in denen die Kund:innen bzw. Business-Stakeholder gemeinsam mit den Salesforce- und MuleSoft-Teams die Projektanforderungen sammeln. In diesem Rahmen sollten Sie sich einen Überblick verschaffen über
- das zu lösende Problem
- die betrieblichen Anwendungsfälle und die entsprechenden Integration Use Cases
- die erforderlichen SLAs
- grundlegende Integrationsmuster
Folgende Punkte sollten während der Planungs- und Architekturphase des Projekts und vor Beginn der Aufwandsschätzung definiert werden:
- Was sind die Business Use Cases?
- Welche Datenelemente müssen integriert werden?
- Welche Integrationsmuster werden verwendet?
- Welche Systeme müssen angebunden werden?
- Welche Datenorchestrierungen und -transformationen braucht es?
- Welche Transformations-/Geschäftslogiken werden in Salesforce abgebildet, welche in MuleSoft?
#2 Klare Verantwortlichkeiten festlegen
Es ist wichtig zu unterscheiden, welche Daten und Integrationsanforderungen über Salesforce und welche über MuleSoft abgewickelt werden. Bestimmen Sie eindeutig, wo und wie die Daten fließen werden und wo die Datenumwandlung stattfinden soll.
Beispiel:
- MuleSoft ruft Daten von einem Drittanbietersystem ab, wandelt x, y, z Datenelemente um, konvertiert die Daten in JSON und sendet sie an Salesforce-Objekte bzw. aktualisiert sie dort.
- Salesforce automatisiert die Weiterverarbeitung der über MuleSoft erfassten Daten.
#3 Sicherheitseinstellungen für MuleSoft und Salesforce
Für die Integration von Salesforce mit MuleSoft gibt es mehrere Methoden, z.B. den von MuleSoft bereitgestellten Salesforce-Adapter, den Aufruf von MuleSoft-APIs über Salesforce oder Plattform-Events. Methodenunabhängig sollten Sie darauf achten, dass Sie die czu den Richtlinien Ihrer Organisation passende Sicherheitsstufe wählen.
Der Screenshot unten zeigt beispielhaft die für MuleSofts Salesforce Connector erforderlichen Sicherheitseinstellungen. Das OAuth 2.0-Verfahren ist sicherer als die Basisauthentifizierung.
Wenn Sie MuleSoft APIs über einen Salesforce-Code abrufen, wählen Sie ebenfalls die maximale Sicherheitsstufe. MuleSoft bietet eine hohe Bandbreite an Sicherheitsmechanismen.
Die Sicherheitsaspekte sollten sowohl vom Projektteam als auch von Stakeholdern bei den Kund:innen und den IT-Sicherheitsteams geprüft und genehmigt werden. Als Faustregel gilt: Wählen Sie die höchstmögliche Sicherheitsstufe.
#4 Mapping von Salesforce Orgs mit der MuleSoft-Umgebung
Bilden Sie mithilfe eines Diagramms die Verbindungen zwischen den beteiligten Mule-Umgebungen und Salesforce-Organisationen sowie anderen externen Systemen ab. Dies verdeutlicht den Datenfluss und deckt mögliche Probleme auf.
Im Beispieldiagramm unten hat eine Kundin nur drei MuleSoft-Umgebungen bei vier externen Salesforce-Systemen. Auf Basis solcher Grafiken lassen sich Strategien für die Interaktion der Systeme ableiten.
#5 Dokument für das Property-Mapping
Besonders wichtig ist das Erstellen eines Mapping-Dokuments, das die Eigenschaften von externen Systemen und Salesforce auflistet und zuordnet. Es definiert den Einsatzbereich für MuleSoft, Orchestrierungen und die Daten bzw. DataWeave-Transformationen.
Das Dokument sollte von den MuleSoft- und Salesforce-Expert:innen im Projektteam gemeinsam erstellt und von den wichtigsten Stakeholdern bzw. Kund:innen abgesegnet werden. Das gewährleistet die Vollständigkeit und Qualität der Daten.
Beispiel:
#6 Transformationslogiken zuordnen
Definieren Sie, welche Transformationslogik über MuleSoft und welche über Salesforce ausgeführt werden soll.
Sollen andere Systeme die MuleSoft-APIs wiederverwenden? Dann sollten die Transformationen in MuleSoft umgesetzt werden. Auf diese Weise empfangen alle Clients eine einheitlich transformierte Antwort. Außerdem können externe Systeme künftig leichter ausgetauscht werden.
#7 Business-Logik
Die Geschäftslogik sollte idealerweise in Salesforce angesiedelt sein. Wird sie in MuleSoft hinterlegt, muss bei einer Änderung der Geschäftslogik ggf. der Code bzw. das Deployment angepasst werden. In Salesforce kann die Geschäftslogik über die Admin-Setup-Screens gemanagt werden. Zudem können Salesforce-Entwickler:innen über benutzerdefinierte Metadaten konfigurierbare Schnittstellen einrichten, über die Business-Anwender:innen die Geschäftslogik ohne Programmierkenntnisse anpassen können.
Mögliche Metadaten-Setups in Salesforce sind: API-bezogen (Endpunkte, URLs, Versionen, Credentials usw.), Timeouts, Header, Content-Type usw. Sie sollten sauber in Salesforce konfiguriert bzw. externalisiert werden, damit sie leicht geändert werden können.
#8 Event-Logging
Zusätzlich zum regulären MuleSoft-Logging ( hauptsächlich für das technische Team) ist das Loggen wichtiger Events in Salesforce sinnvoll. Es geht hier nicht um Debug-Protokolle, sondern um die wichtigsten Events, die bei der (massenhaften) Datenübertragung über APIs auftreten. Dazu gehören der Empfang einer Anfrage, das Aufrufen externer Systeme, das Speichern der Daten in Salesforce, Verarbeitungsfehler etc. Für das Protokollieren wichtiger Events kann eine gängige Logging-Funktion verwendet werden, die über den Code aufgerufen wird.
Über dieses Ereignisprotokoll können Salesforce-Administratoren den aktuellen Status einsehen, die Aktivitäten der MuleSoft-APIs verfolgen und nachvollziehen, ob und in welcher Phase der Datenübertragung Probleme aufgetreten sind. Die aufgezeichneten Ereignisse können zudem unter dem entsprechenden Kund:innen-Account in Salesforce auch von nicht-technischen Anwender:innen eingesehen bzw. überwacht werden.
#9 Testen
Wie bei jedem digitalen Projekt sind Performancetests wichtig. Prüfen Sie die Antwortzeit und stellen Sie sicher, dass das SLA eingehalten wird. Testen Sie die Performance von MuleSoft und Servern mit echten Daten inkl. der Verarbeitung von Batch-Dateien. Sinnvoll sind hier automatisierte Tests z. B. mit Selenium.
Informieren Sie sich über unsere Lösungen rund um Salesforce-Integration.
