Salesforce-Integrationsarchitektur: Muster, die wirklich skalieren

Das gewählte Integrationsmuster, nicht das Tool, entscheidet, ob Salesforce-Daten sauber bleiben oder im Synchronisationschaos enden. Point-to-Point-Verbindungen sind schnell gebaut und schnell kaputt. Middleware und ereignisgesteuerte Muster kosten anfangs mehr, überstehen aber auch das dritte, vierte und zehnte angebundene System. Die meisten Integrationsprobleme gehen auf diese frühe Architekturentscheidung zurück, nicht auf Salesforce selbst.

Warum scheitern die meisten Salesforce-Integrationen?

Zwei Systeme teilen selten dasselbe Datenmodell. Salesforce denkt in Accounts, Contacts und Opportunities, ein ERP in Kundenstammdaten und Verkaufsaufträgen. Jede Integration muss diese Formen in Einklang bringen, und Teams, die diesen Schritt überspringen, schrauben am Ende Felder an Salesforce-Objekte, um abzubilden, was das andere System sendet. Sechs Monate später weiß niemand mehr, warum Custom_ERP_ID__c existiert oder was passiert, wenn es leer ist.

Die Lösung ist kein Tool, sondern ein kanonisches Datenmodell: Legen Sie fest, was ein "Account" über Ihre Systeme hinweg bedeutet, bevor Sie einen einzigen Integrationsflow schreiben, und bauen Sie die Transformationslogik um diese Definition herum, statt das zuletzt angebundene System das Schema diktieren zu lassen.

Point-to-Point oder Middleware: Welches Muster passt?

Point-to-Point-Integrationen, also ein direkter API-Aufruf von Salesforce an System B, sind sinnvoll für eine oder zwei Verbindungen mit einfachen, stabilen Daten. Sobald Sie drei oder mehr Systeme integrieren, wird Point-to-Point zu einem nicht mehr wartbaren Geflecht: Jede neue Verbindung vervielfacht die Stellen, an denen ein Feld-Mapping aus dem Takt geraten kann.

Eine Middleware- oder ESB-Schicht, etwa MuleSoft, Boomi oder ein schlankerer eigener Message Broker, bündelt Transformation und Routing, sodass Salesforce mit einer Integrationsschicht spricht statt direkt mit fünf nachgelagerten Systemen. Das ist eine echte Infrastrukturinvestition, die Sie Integrationslandschaften vorbehalten sollten, die tatsächlich wachsen, nicht einer einzelnen einmaligen Synchronisation.

Wie gehen Sie mit Echtzeit- und Batch-Daten um?

Nicht alles muss sofort synchronisiert werden, und jede Integration als Echtzeit zu behandeln, ist genau der Weg, auf dem Teams ohne jeden Nutzen ihre Salesforce-API-Limits aufbrauchen. Eine nützliche Faustregel:

• Nutzen Sie Platform Events oder Change Data Capture für alles, was ein Benutzer sofort sehen muss, etwa Auftragsstatus oder Updates zu Support-Cases.
• Nutzen Sie geplante Batch-Jobs und die Bulk API für große, nicht dringende Mengen, etwa den nächtlichen Finanzabgleich.
• Vermeiden Sie Polling-Schleifen, die die REST API per Timer aufrufen, nur weil das einfacher zu bauen ist. Sie verschwenden API-Aufrufe und erhöhen die Latenz gegenüber ereignisgesteuerten Alternativen.

Change Data Capture wird zu wenig genutzt: Es veröffentlicht Änderungsereignisse auf Feldebene für Standard- und Custom-Objekte, ohne dass Sie eigene Trigger bauen müssen, um Änderungen zu erkennen.

Wie verhindern Sie doppelte Datensätze und fehlgeschlagene Synchronisationen?

Jede Integration wiederholt irgendwann eine Anfrage, sei es durch ein Timeout oder einen Job in der Warteschlange, der zweimal läuft. Ist Ihre Integration nicht idempotent, erzeugt diese Wiederholung eine doppelte Opportunity oder zählt eine Kennzahl doppelt. Die Lösung ist ein stabiles External-ID-Feld am Salesforce-Objekt in Kombination mit Upsert-Aufrufen auf diese ID statt blinder Create-Aufrufe.

Die Fehlerbehandlung verdient dieselbe Sorgfalt wie der Normalfall. Fehlgeschlagene Datensätze sollten mit genug Kontext für die erneute Verarbeitung in einer Dead-Letter-Queue oder einem Fehlerprotokoll landen, statt lautlos zu verschwinden, weil ein einzelner Datensatz in einem Batch von 200 die Validierung nicht bestanden hat.

MuleSoft oder eine selbst gebaute Integrationsschicht?

MuleSoft rechnet sich bei vielen Systemen, einem eigenen Integrationsteam und Konnektoren, die genau zu Ihrem Vorhaben passen. Eine selbst gebaute Schicht aus Apex, einer Message Queue und einem schlanken Orchestrierungsdienst ist für eine Handvoll klar definierter Integrationen durch gezielte Entwicklungsarbeit oft günstiger umzusetzen, verlagert die langfristige Wartung aber auf Ihr eigenes Engineering-Team.

Es ist eine Abwägung zwischen Bauen und Kaufen, die von der Zahl der Integrationen abhängt und davon, wie schnell Ihre Systemlandschaft wächst. Diese Entscheidung verdient einen Blick von außen, bevor Sie sich festlegen, und genau hier kommen die Integrationsleistungen von Tekunda ins Spiel: Wir helfen Teams, das Muster zu wählen und umzusetzen, das zu ihrer tatsächlichen Roadmap passt, nicht das, das in einer Hersteller-Demo einfach aussah.

FAQ

Was ist der Unterschied zwischen Platform Events und Change Data Capture?

Platform Events sind selbst definierte Nachrichten, die Sie explizit aus Apex oder einem Flow veröffentlichen, während Change Data Capture automatisch Ereignisse ausgibt, wenn sich Datensätze von Standard- oder Custom-Objekten ändern, ohne eigene Veröffentlichungslogik.

Brauche ich MuleSoft, um Salesforce mit anderen Systemen zu integrieren?

Nein. MuleSoft ist eine Option unter mehreren, darunter Boomi, Informatica oder eine selbst gebaute Middleware-Schicht. Die richtige Wahl hängt davon ab, wie viele Systeme Sie verbinden und wer die Integration langfristig pflegt.

Wie vermeide ich es, an die Salesforce-API-Limits zu stoßen?

Verarbeiten Sie große Datenmengen als Batches über die Bulk API statt mit REST-Aufrufen pro Datensatz, nutzen Sie Platform Events oder Change Data Capture statt Polling, und bündeln Sie zusammengehörige Aufrufe, wo die API Composite Requests unterstützt.

Wie authentifiziert man eine Drittanbieter-Integration am sichersten bei Salesforce?

Nutzen Sie eine Connected App mit OAuth 2.0, beschränken Sie die Berechtigungen auf das, was die Integration braucht, und wechseln Sie Zugangsdaten nach einem festen Zeitplan, statt sich auf ein einziges langlebiges Token zu verlassen.