Sechs Muster, mit denen Architekt:innen Ausfälle bei Salesforce-Integrationen verhindern

Wählen Sie das Muster passend zur Last, entscheiden Sie sich für asynchrone und ereignisgesteuerte Entwürfe, wenn Volumen oder Kopplungsrisiko hoch sind, sichern Sie Identitäten mit Named Credentials und eng gefassten OAuth-Berechtigungen, und überlassen Sie Orchestrierung, Wiederholungen und Transformation einer Middleware statt selbst gebautem Apex-Code. Platform Events, Change Data Capture und Data Cloud decken die meisten entkoppelten Szenarien mit hohem Volumen ab, während Named Credentials und moderne OAuth-Abläufe jede Verbindung nachvollziehbar halten. Führen Sie vor dem nächsten Integrationsstart eine fünfminütige Musterprüfung des aktuellen Entwurfs durch. Dabei kommt fast immer mindestens eine Stelle zum Vorschein, an der ein synchroner Aufruf stillschweigend eine Aufgabe erledigt, die eigentlich einem Ereignis zusteht.

Kurz gefasst:

• Nutzen Sie ereignisgesteuerte Muster wie Platform Events oder Change Data Capture für entkoppelte Szenarien mit hohem Volumen, um synchrone Aufrufe zu reduzieren und die Skalierbarkeit zu verbessern.
• Führen Sie vor der Umsetzung eine fünfminütige Musterprüfung durch, um synchrone Aufrufe zu erkennen, die besser durch ereignisbasierte Integrationen ersetzt werden, besonders bei hoher Last.
• Entscheiden Sie sich standardmässig für asynchrone Integrationsverfahren, ausser die Nutzerin oder der Nutzer wartet aktiv auf eine sofortige Rückmeldung. So vermeiden Sie Probleme mit Governor Limits und Sperrfehler auf Datensätzen.
• Bevorzugen Sie Datenvirtualisierung über Salesforce Connect für veränderliche externe Daten, die nicht in Salesforce gespeichert werden müssen, oder replizieren Sie Daten, die häufig in Berichten und Flows gebraucht werden.
• Setzen Sie umfassende Sicherheitspraktiken um: Zugangsdaten in Named Credentials hinterlegen, OAuth-Berechtigungen minimieren, Token regelmässig wechseln und Remote Site Settings auf vertrauenswürdige Domains beschränken.

Inhaltsverzeichnis

• Was sind die zentralen Salesforce-Integrationsmuster?
• Wie wählen Sie das richtige Integrationsmuster?
• Synchron oder asynchron integrieren?
• Replikation oder Virtualisierung: Welche Datenstrategie gewinnt?
• Welche Sicherheitsmassnahmen braucht jede Integration?
• Wie bauen Sie robuste, beobachtbare Integrationen?
• Wann lohnt sich Middleware statt nativer Salesforce-Werkzeuge?
• Was gehört auf die Integrations-Checkliste von Architekt:innen?
• Unsere Sicht darauf, woran Integrationsprojekte wirklich scheitern
• Wie Ampersand Labs Salesforce-Integrationsprojekte unterstützt
• Quellen
• FAQ

Was sind die zentralen Salesforce-Integrationsmuster?

Die Architektur von Salesforce-Integrationen gliedert sich in drei Kategorien: Prozess, Daten und virtuell. Jede löst ein anderes Problem, und die falsche Wahl ist der mit Abstand häufigste Grund für fragile Integrationen, die unter Last zusammenbrechen.

Prozessintegration verbindet Geschäftsprozesse über Systemgrenzen hinweg, meist um einen Ablauf nahezu in Echtzeit am Laufen zu halten. Datenintegration kopiert oder synchronisiert Datensätze zwischen Systemen, sodass jedes seine eigene konsistente Kopie hat. Virtuelle Integration verzichtet ganz aufs Kopieren und fragt stattdessen das Quellsystem bei Bedarf ab. Die Architekturdokumentation von Salesforce beschreibt diese three-way split and a selection matrix, die jede Kategorie konkreten Mustern zuordnet. Es lohnt sich, das Dokument während jeder Entwurfssitzung offen zu halten.

Innerhalb dieser drei Kategorien decken sechs Muster fast alles ab, was Sie bauen werden:

• Request and Reply: ein synchroner Aufruf, bei dem der Aufrufer blockiert, bis eine Antwort kommt, typischerweise über REST oder SOAP. Ideal für Abfragen an der Oberfläche, die in weniger als einer Sekunde eine Antwort brauchen, etwa eine Bonitätsprüfung beim Checkout. Fehlerbild: Zeitüberschreitungen schlagen bis zur Nutzerin durch, wenn das nachgelagerte System langsam ist.
• Fire and Forget: der Aufrufer sendet eine Nachricht und macht weiter, ohne auf eine Bestätigung zu warten. Gut für Protokollierung, Benachrichtigungen oder alles, wo der Aufrufer das Ergebnis nicht sofort kennen muss. Fehlerbild: stiller Nachrichtenverlust, wenn es keine Bestätigung oder Wiederholungsschicht gibt.
• Batch Data Sync: grosse Datenmengen bewegen sich nach Zeitplan, meist nachts, über die Bulk API. Passt für Abgleiche mit dem Data Warehouse oder Altsystemen, wo Nahezu-Echtzeit nicht nötig ist. Fehlerbild: teilweise fehlgeschlagene Stapel, die zwei Systeme bis zum nächsten Lauf auseinanderlaufen lassen.
• Remote Call-In: ein externes System ruft Salesforce auf, oft über die REST API oder Apex-REST-Endpunkte, um Datensätze zu lesen oder zu schreiben. Verbreitet bei mobilen Apps oder Partnerportalen. Fehlerbild: Governor Limits werden gerissen, wenn externe Systeme die Obergrenzen pro Transaktion nicht respektieren.
• Datenvirtualisierung: Salesforce fragt Daten eines externen Systems bei Bedarf ab, statt eine Kopie zu speichern, typischerweise über Salesforce Connect und OData oder eigene Adapter. Passt, wenn Daten sich zu häufig ändern, um sie repliziert zu halten, oder wenn Speicherkosten und Duplikate ein Thema sind. Fehlerbild: das gesamte Nutzungserlebnis leidet, sobald die Antwortzeit des externen Systems nachlässt.
• Publish and Subscribe: ein Ereignis wird einmal veröffentlicht, und beliebig viele Abonnenten greifen es auf, über Platform Events, Change Data Capture oder die Pub/Sub API. Das ist das Muster für Benachrichtigungen von einem an viele, etwa wenn fünf nachgelagerte Systeme im Moment eines Abschlusses informiert werden sollen. Fehlerbild: Abonnenten fallen hinter das Aufbewahrungsfenster der Ereignisse zurück und verpassen Nachrichten endgültig.

Die Salesforce blog’s own guidance on aligning patterns to use cases nennt einen Punkt, den man ruhig wiederholen darf: Ereignisgesteuerte Ansätze blockieren den Aufrufer nicht und kommen mit Parallelität deutlich besser zurecht als synchrone Aufrufe, sobald das Volumen steigt. Genau zu diesem Muster greifen die meisten Architekt:innen zu spät, nämlich erst, nachdem eine synchrone Integration bereits einen Vorfall in der Produktion verursacht hat.

Wie wählen Sie das richtige Integrationsmuster?

Prüfen Sie jede Integrationsentscheidung entlang von sechs Dimensionen, bevor Sie eine Zeile Code schreiben: Zeitanforderungen, Datenhoheit, Datenvolumen, Transaktionsbedarf, Fehlerverhalten und Latenz-SLA. Wer diesen Schritt überspringt, baut sechs Monate später einen Ereignisbus nachträglich in etwas ein, das als synchroner Aufruf entstanden ist.

Zeitanforderungen klären, ob der Geschäftsprozess ein Ergebnis sofort braucht oder eine Verzögerung verträgt. Eine Preisauskunft beim Checkout ist etwas anderes als eine monatliche Provisionsberechnung. Datenhoheit klärt, welches System die verbindliche Quelle ist. Wenn Salesforce für den Preiskatalog nicht führend ist, replizieren Sie ihn nicht nach Salesforce in der Hoffnung, er bleibe aktuell. Datenvolumen, teils als LDV (Large Data Volumes) bezeichnet, entscheidet, ob Sie Bulk API und asynchrone Jobs brauchen statt transaktionaler Verfahren.

Transaktionsbedarf betrifft die Frage, ob eine Operation als Ganzes gelingen oder scheitern muss. Fehlerverhalten klärt, was passiert, wenn ein nachgelagertes System nicht erreichbar ist. Wird der Datensatz für einen erneuten Versuch eingereiht, sieht die Nutzerin einen Fehler, oder geht der Datensatz verloren? Die Latenz-SLA ist die Obergrenze für eine akzeptable Antwortzeit, und sie soll aus dem Geschäft kommen, nicht daraus, was sich bequem bauen lässt.

Einige Szenarien lassen sich sauber zuordnen:

• Ein Aussendiensttechniker, der vor dem Einsatz den Lagerbestand in Echtzeit prüft, braucht Request and Reply oder, bei hohem Volumen, Datenvirtualisierung über Salesforce Connect.
• Ein gewonnener Abschluss, der eine Slack-Benachrichtigung, eine ERP-Bestellung und eine Markierung in der Marketing-Automation auslösen soll, passt zu Publish and Subscribe mit Platform Events, da drei getrennte Systeme dasselbe Signal brauchen.
• Eine nächtliche Aktualisierung des Produktkatalogs aus einem ERP-System gehört in einen Batch-Abgleich über die Bulk API, nicht in einen Echtzeitaufruf bei jedem Speichern.
• Ein Partnerportal, das während der Geschäftszeiten Leads nach Salesforce schreibt, ist ein Fall für Remote Call-In, abgesichert über eine eng gefasste Connected App.

Für den Workshop hält eine kurze Checkliste das Gespräch am Boden: Wie lautet die Latenz-SLA, in Sekunden oder Stunden? Wem gehört der Datensatz nach dieser Transaktion? Welches Tagesvolumen ist zu erwarten? Was passiert im Fehlerfall: erneuter Versuch, Alarm oder Verwerfen? Braucht es eine garantierte einmalige Zustellung, oder ist der Umgang mit Duplikaten nachgelagert vertretbar? Beantworten Sie diese fünf Fragen, bevor Sie den Musterkatalog aufschlagen, und die richtige Wahl liegt meist auf der Hand.

Synchron oder asynchron integrieren?

Entscheiden Sie sich standardmässig für asynchron, ausser jemand wartet aktiv am Bildschirm auf das Ergebnis. Diese eine Regel verhindert die meisten Probleme mit Governor Limits und Sperren, auf die Architekt:innen nach dem Go-live stossen.

Synchrone Integrationen wirken einfacher zu bauen, und genau deshalb greifen Teams selbst dann dazu, wenn der Geschäftsfall es gar nicht verlangt. Salesforce nennt in der eigenen Auswertung häufiger Architekturfehler die übermässige Abhängigkeit von synchronen Aufrufen als wiederkehrendes Fehlermuster, meist weil niemand vor dem Bau die tatsächliche SLA geprüft hat. Ein synchroner Aufruf, der eine Salesforce-Transaktion blockiert, während er auf eine langsame externe API wartet, riskiert das Erreichen des CPU-Zeitlimits. Und wenn dieses externe System zusätzlich auf dieselben Datensätze zurückschreibt, entstehen Sperrkonflikte, die sich unter Last als zufällige UNABLE_TO_LOCK_ROW-Fehler zeigen.

Die Entkopplung sieht fast immer gleich aus: Nehmen Sie den Schreibvorgang vom kritischen Pfad. Veröffentlichen Sie ein Platform Event, statt direkt aufzurufen, lassen Sie es von einem Abonnenten asynchron verarbeiten, und geben Sie den Nutzenden eine sofortige Bestätigung statt eines Ladekreisels. Change Data Capture eignet sich gut, wenn Sie auf Änderungen an Datensätzen reagieren wollen, ohne für jedes Objekt Trigger-Logik zu schreiben, denn es veröffentlicht Änderungsereignisse automatisch auf Basis des Abonnements. Die Pub/Sub API ist der neuere, auf Protocol Buffers basierende Kanal, der Veröffentlichen und Abonnieren im grossen Massstab unterstützt, und sie ist der empfohlene Weg für Ereignisströme mit hohem Durchsatz.

Ein paar Faustregeln bewähren sich in den meisten Projekten:

• Wenn jemand am Bildschirm auf das Ergebnis wartet, ist synchron vermutlich richtig.
• Wenn drei oder mehr Systeme dasselbe Ereignis kennen müssen, schlägt Publish and Subscribe drei getrennte Punkt-zu-Punkt-Aufrufe.
• Wenn das Volumen unvorhersehbar ansteigen kann, fängt eine asynchrone Lösung mit Warteschlange die Spitze ab; synchron läuft einfach in die Zeitüberschreitung.
• Wenn die Verfügbarkeit des externen Systems schlechter ist als die von Salesforce, darf dessen Ausfall Salesforce nicht mitreissen.

Praxistipp: Behalten Sie Ihr API-Aufrufbudget im Blick, wenn Sie Ereignisse über den REST-API-Endpunkt veröffentlichen statt nativ über Apex oder Flow. In der Community wird darauf hingewiesen, dass über die API veröffentlichte Ereignisse auf Ihr tägliches API-Limit angerechnet werden, native Veröffentlichungswege dagegen nicht. Dieser Unterschied fällt stark ins Gewicht, sobald Sie täglich Tausende Ereignisse veröffentlichen.

Replikation oder Virtualisierung: Welche Datenstrategie gewinnt?

Kopieren Sie Daten nach Salesforce, wenn sie innerhalb der Plattform schnell, abfragbar und auswertbar sein müssen. Lassen Sie sie extern und fragen Sie bei Bedarf ab, wenn sie sich zu häufig ändern, um synchron gehalten zu werden, oder wenn eine Kopie zu Compliance-Problemen führt.

Replikation bedeutet, eine Kopie externer Daten als Salesforce-Datensätze zu speichern, aktualisiert nach Zeitplan oder über Ereignisse. Das ist richtig für alles, was Nutzende in Salesforce auswerten oder in Flows und Validierungsregeln referenzieren, da virtualisierte Daten das nicht immer nativ unterstützen. Virtualisierung über Salesforce Connect und externe Objekte verzichtet auf die Kopie und fragt das Quellsystem direkt ab. Das passt zu grossen Katalogen, die sich ständig ändern, etwa der Echtzeit-Preistabelle eines Distributors, wo eine synchron gehaltene Kopie dauernde Sync-Jobs bedeuten würde, die Aktualität gegen Speicherkosten ausspielen.

Zero-Copy-Ansätze gehen noch weiter. Die Salesforce-Hinweise zu Data-360-Integrationsmustern beschreiben Aufnahmemodi, mit denen Data Cloud Daten am Ort referenziert, statt sie über jedes verbundene System hinweg zu duplizieren. Das zählt, wenn ein Data Warehouse und Salesforce denselben Kundendatensatz brauchen, ohne zu zwei Quellen der Wahrheit zu werden.

Die Hoheit über Stammdaten muss geklärt sein, bevor der erste Sync-Job geschrieben wird, nicht danach. Legen Sie vorab fest, welches System für welche Entität führend ist, für Kunden, Produkte und Preise, und halten Sie das als Schema-Vertrag fest, den beide Teams abnehmen. Die Logik zur Dublettenvermeidung gehört an den Punkt der Datenaufnahme, nicht in einen Aufräumjob sechs Monate später, wenn doppelte Accounts bereits jeden nachgelagerten Bericht verfälscht haben.

Ein paar praktische Leitplanken:

• Behandeln Sie das Schema als Vertrag zwischen den Systemen; eine geänderte Feldart auf einer Seite sollte eine Freigabe verlangen, nicht bloss ein Deployment.
• Nutzen Sie Salesforce Connect für lesestarke externe Daten mit toleranter Latenz, statt sie zu replizieren.
• Greifen Sie zu Data Cloud, wenn Sie ein einheitliches Kundenprofil über viele Quellsysteme brauchen, nicht als Allzweckersatz für ETL.
• Holen Sie Middleware ins Spiel, sobald die Transformationslogik zwischen Systemen so komplex wird, dass Apex zu einer nicht mehr wartbaren Zuordnungsschicht würde.

Für Ladevorgänge mit grossen Datenmengen stimmen Sie die Stapelgrössen der Bulk API auf rund 200 Datensätze ein und passen Sie sie an die Parallelitätsgrenzen des nachgelagerten Systems an, denn pushing too hard against a partner’s ingestion rate verschiebt den Engpass nur, statt ihn zu lösen.

Welche Sicherheitsmassnahmen braucht jede Integration?

Speichern Sie keine einzigen Zugangsdaten im Code, halten Sie jede OAuth-Berechtigung so eng wie möglich, und wechseln Sie Token nach Zeitplan, nicht erst, wenn etwas kaputtgeht. Das ist die Grundlinie, und Integrationen, die sie überspringen, tauchen später in Vorfallsberichten auf.

Named Credentials gibt es, damit Sie nie eine Endpunkt-URL oder ein Authentifizierungs-Token fest in Apex schreiben. Sie bündeln die Verbindungsdaten und überlassen Salesforce den OAuth-Handshake, womit ein Token-Wechsel auch kein Code-Deployment mehr braucht. External Client Apps sind der moderne Ersatz für die alte Connected-App-Konfiguration, und Salesforce hat mit dem Release Spring '26 stark auf die Migration älterer Setups gedrängt. Von der Community gepflegte security best-practice references halten unmissverständlich fest, dass fest verdrahtete Geheimnisse und zu breit gefasste OAuth-Berechtigungen die beiden häufigsten Befunde in Sicherheitsprüfungen von Integrationen sind.

Speziell zu OAuth: Fassen Sie die Berechtigungen genau auf das, was die Integration braucht, nicht breiter. Nutzen Sie den JWT-Bearer-Flow für Server-zu-Server-Integrationen, bei denen niemand interaktiv authentifiziert. Nutzen Sie PKCE für jeden öffentlichen Client, etwa eine mobile App, wo ein Client Secret nicht sicher abgelegt werden kann. Wechseln Sie Token nach einem festgelegten Zeitplan, statt langlebige Token unbegrenzt aktiv zu lassen.

Ein breit anerkanntes Branchenmuster: Integrationen, die Zugangsdaten über benannte Verbindungen zentral ablegen statt inline im Code, verzeichnen deutlich weniger Vorfälle durch geleakte oder veraltete Token, weil der Wechsel zur Konfigurationsänderung wird statt zum Code-Deployment.

Über die Identität hinaus runden ein paar Netzwerk- und Compliance-Massnahmen die Liste ab:

• Beschränken Sie Remote Site Settings auf genau die Domains, die eine Integration braucht, keine Platzhalter.
• Verfolgen Sie Ablaufdaten von Zertifikaten zentral; ein abgelaufenes Zertifikat, das über Nacht still eine Integration lahmlegt, gehört zu den häufigsten selbst verschuldeten Ausfällen.
• Verschlüsseln Sie personenbezogene Daten bei der Übertragung und im Ruhezustand, überall dort, wo die Integration sie berührt.
• Dokumentieren Sie Datenflüsse für die DSGVO oder vergleichbare Regelwerke, besonders wenn Personendaten zwischen Systemen eine Landesgrenze überschreiten.

Wie bauen Sie robuste, beobachtbare Integrationen?

Gehen Sie davon aus, dass jeder nachgelagerte Aufruf irgendwann fehlschlägt, und entwerfen Sie Wiederholungen, Alarme und Idempotenz vor dem Gutfall, nicht nach dem ersten Ausfall.

Die Wiederholungsstrategie sollte exponentiell mit Zufallsabweichung zurückstufen, statt in festen Abständen zu wiederholen und dabei alle gleichzeitig auf das ausgefallene System einzuschlagen und den Ausfall zu verschlimmern. Ein typisches Muster: Wiederholung nach 2 Sekunden, dann nach 4, dann nach 8, jeweils mit einem kleinen zufälligen Versatz, begrenzt auf ein definiertes Maximum, bevor aufgegeben wird. Circuit Breaker stellen die Aufrufe eines nachgelagerten Systems ganz ein, sobald es wiederholt ausgefallen ist, und geben ihm Luft zur Erholung, statt es mit Wiederholungen aus jeder abhängigen Integration zu überfluten. Dead-Letter-Queues fangen alles auf, was seine Wiederholungen aufgebraucht hat, sodass fehlgeschlagene Nachrichten geprüft und manuell erneut verarbeitet werden, statt zu verschwinden.

Idempotenz zählt genau in jenen Fällen am meisten, in denen Wiederholungen auftreten: Wird eine Nachricht zweimal verarbeitet, weil eine Bestätigung verloren ging, darf die zweite Verarbeitung keinen doppelten Datensatz erzeugen. Transaktions-IDs, die jede Nachricht begleiten und empfangsseitig gegen eine Eindeutigkeitsbedingung geprüft werden, sind die übliche Lösung. Die Ereignisarchitektur von Salesforce unterstützt das gut: Wiederholbare Ereignisse mit Replay-IDs erlauben es einem Abonnenten, der Nachrichten verpasst hat, ab einem bekannten Punkt aufzuholen, statt zu raten, was verloren ging.

Beobachtbarkeit schliesst den Kreis. Zentrale Protokollierung über alle Systeme der Integrationskette hinweg, verteiltes Tracing, damit eine einzelne Transaktion durchgehend nachvollziehbar bleibt, und Dashboards für Fehlerrate, Latenzperzentile und Warteschlangenlänge gehören ab Tag eins in den Entwurf, nicht nachträglich nach dem ersten Produktionsvorfall.

Eine kurze Betriebsliste, die sichtbar bleiben sollte:

• Wiederholen mit exponentiellem Zurückstufen und Zufallsabweichung, begrenzt auf eine vernünftige maximale Versuchszahl.
• Aufgebrauchte Wiederholungen mit Alarm in eine Dead-Letter-Queue leiten, nicht still verwerfen.
• Jeder Nachricht eine eindeutige Transaktions-ID mitgeben und diese nachgelagert als Eindeutigkeitsbedingung durchsetzen.
• Fehlerrate, p95-Latenz und Warteschlangenlänge als feste Kennzahlen verfolgen, nicht nur die Verfügbarkeit.

Praxistipp: Testen Sie Ihre Wiederholungs- und Dead-Letter-Logik in einer Staging-Umgebung, indem Sie einen nachgelagerten Mock mitten im Lauf bewusst abschalten. Die meisten Teams merken erst während eines echten Ausfalls, dass ihre Rückstufungslogik nicht funktioniert, und das ist der denkbar schlechteste Zeitpunkt dafür.

Wann lohnt sich Middleware statt nativer Salesforce-Werkzeuge?

Greifen Sie zu Middleware, also einer Integrationsplattform (iPaaS), einem Enterprise Service Bus oder einem API-Gateway, sobald Orchestrierung über mehr als zwei Systeme, Protokollübersetzung oder zentrale Regeldurchsetzung ins Spiel kommen. Native Salesforce-Werkzeuge leisten für sich genommen viel, waren aber nie als Orchestrierungsschicht für einen Ablauf über fünf Systeme gedacht.

Middleware verdient ihren Platz durch eine klare Reihe von Aufgaben: Orchestrierung mehrerer nachgelagerter Aufrufe in festgelegter Reihenfolge, Protokollvermittlung, wenn ein System SOAP spricht und ein anderes REST oder ein Protokoll für Nachrichtenwarteschlangen, Drosselung zum Schutz von Systemen mit geringerer Kapazität als Salesforce, Transformation von Nutzlasten zwischen unvereinbaren Datenmodellen und Regeldurchsetzung wie Ratenbegrenzung oder Authentifizierungsprüfungen, einheitlich über alle Integrationen hinweg statt in jeder einzeln nachgebaut.

Native Salesforce-Integration über Platform Events, Apex REST oder eine direkte Connected App reicht für einfache Punkt-zu-Punkt-Verbindungen zwischen zwei Systemen, wo diese Orchestrierungskomplexität gar nicht besteht. Sobald ein drittes System dazukommt oder sich die Transformationslogik über mehrere Apex-Klassen zieht, nur um eine Nutzlast umzuformen, ist das das Signal, die Logik in die Middleware zu verlagern, statt sie in der Org wuchern zu lassen.

APIs nach Verantwortung zu schichten zahlt sich aus, je mehr Integrationen dazukommen. System-APIs kapseln ein einzelnes Backend-System hinter einer stabilen Schnittstelle. Prozess-APIs setzen mehrere System-APIs zu einer fachlichen Operation zusammen. Experience-APIs bereiten Daten für einen bestimmten Kanal auf: mobil, Web, Partnerportal. Dokumentationen zur API-First-Integrationsarchitektur beschreiben diese Schichtung als den Unterschied zwischen Integrationen, die über Projekte hinweg wiederverwendet werden, und solchen, die bei jedem neuen Abnehmer von Grund auf neu entstehen.

• Nutzen Sie middleware, wenn drei oder mehr Systeme für einen einzigen Geschäftsprozess koordiniert zusammenspielen müssen.
• Bleiben Sie nativ, wenn die Integration eine einfache Verbindung zwischen zwei Systemen mit geringem Volumen ist.
• Schichten Sie APIs nach System, Prozess und Experience, um die Wiederverwendung in künftigen Projekten zu maximieren.

Was gehört auf die Integrations-Checkliste von Architekt:innen?

Eine Entwurfsprüfung, die Verantwortlichkeiten, Rollback und Überwachung von Anfang an auslässt, produziert später einen Vorfall. Eine gründliche Checkliste vor dem Start der Umsetzung lohnt sich für Integrationsprojekte in vollem Umfang.

Punkte der Entwurfsprüfung: Dokumentieren Sie die groben Anforderungen und die geschäftliche SLA, bevor Sie ein Muster wählen. Halten Sie für jede nicht triviale Entscheidung einen Architecture Decision Record fest, synchron oder asynchron, Replikation oder Virtualisierung, damit die Begründung Personalwechsel überdauert. Legen Sie für jedes eingebundene System klare Verantwortung fest, inklusive der Frage, wer bei einer Störung alarmiert wird. Definieren Sie einen Rollback-Plan vor dem Deployment, nicht während eines Vorfalls.

Punkte der CI/CD-Prüfung: Automatisieren Sie Tests der OAuth-Redirect-URIs, damit eine Konfigurationsänderung die Authentifizierung in der Produktion nicht still zerstört. Prüfen Sie Ablaufdaten von Zertifikaten in der Pipeline und nicht per manueller Kalendererinnerung, denn die Identitätsänderungen in Spring '26 haben das certificate lifecycle management a first-class operational concern gemacht statt einer Nebensache. Prüfen Sie als Freigabekriterium beim Deployment, ob jeder externe Endpunkt korrekt antwortet, und fangen Sie so eine falsch konfigurierte Named Credential ab, bevor sie die Nutzenden erreicht.

Runbooks für die Überwachung: Legen Sie fest, was einen Alarm auslöst, wer ihn erhält und welches die ersten drei Schritte zur Fehlersuche sind, schriftlich vor dem Go-live und nicht improvisiert während des ersten Ausfalls.

• Halten Sie für jede im Entwurf getroffene Musterwahl einen Architecture Decision Record fest.
• Führen Sie automatisierte OAuth- und Zertifikatsprüfungen als Freigabekriterium beim Deployment durch, nicht von Hand.
• Legen Sie für jedes eingebundene System eine namentliche Verantwortung und einen Eskalationsweg fest.
• Schreiben Sie den Rollback-Plan vor dem ersten Deployment, nicht nach dem ersten Fehlschlag.

Unsere Sicht darauf, woran Integrationsprojekte wirklich scheitern

Die meisten Integrationsfehler, die uns bei Audits begegnen, gehen auf Entscheidungen zurück, die damals vernünftig wirkten: aus Tempogründen synchron bauen, wegen knapper Termine auf Architecture Decision Records verzichten oder für eine schnelle Integration Token fest verdrahten statt sauber zu verwalten. Nichts davon ist Unwissen. Es sind kleine, für sich genommen vertretbare Abkürzungen, die sich aufsummieren.

Der Musterkatalog und die Sicherheitscheckliste in diesem Beitrag sind praktische Prüfungen, die wir in Integrationsprojekten einsetzen, von unkomplizierten ERP-Abgleichen bis zu Ereignisarchitekturen über mehrere Systeme. Wenn Senior-Leute früh im Architekturgespräch dabei sind und nicht erst bei der Übergabe, lassen sich voreilige synchrone Aufrufe vor dem Deployment abfangen. Ein typisches Projekt läuft über Audit, dann Plan, dann Umsetzung, dann laufender Support, und der grösste Nutzen zeigt sich meist schon im Audit, wo die Lücke zwischen dem, was ein System leisten sollte, und dem, was es tatsächlich tut, sichtbar wird.

Wenn Sie vor einer alten Integration stehen, der niemand mehr ganz traut, oder vor einem neuen Projekt, bei dem die Musterwahl noch unklar ist, dann ist genau das der richtige Moment für eine externe Architekturprüfung, bevor weiterer Code auf einem unklaren Fundament entsteht.

, Davide Morotti

Wie Ampersand Labs Salesforce-Integrationsprojekte unterstützt

Die richtige Integrationsarchitektur gleich beim ersten Mal zu bauen kostet weniger, als eine synchrone, fest verdrahtete Lösung zu entwirren, wenn sie bereits produktiv und tragend ist. Projekte zu Salesforce-Integration und API-Entwicklung profitieren davon, wenn Senior-Architekt:innen ab dem ersten Workshop dabei sind und nicht erst nach der Vertragsunterschrift. So lassen sich Fehler bei der Musterwahl früh erkennen statt erst in der Produktion.

Ein typisches Projekt kann ein Audit der bestehenden Integrationslandschaft umfassen, einen Machbarkeitsnachweis für riskante Musterentscheidungen, die Umsetzung und laufenden Support, damit die Architektur wartbar bleibt, wenn neue Systeme dazukommen. Zu den Leistungen können Systemintegrationen, API-Entwicklung, Interims-CTO-Support, CI/CD- und Sicherheitsaudits sowie KI-Automatisierung für Abläufe rund um Salesforce-Daten gehören.

Wenn sich eine bestehende Integration brüchig anfühlt oder Sie eine neue entwerfen und vor dem ersten Code ein zweites erfahrenes Augenpaar auf die Musterwahl werfen lassen möchten, starten Sie auf der Seite Systemintegration & API-Entwicklung. Dort sehen Sie, wie ein Projekt aus Audit und Umsetzung zugeschnitten wird.

Quellen

• three-way split and a selection matrix
• Salesforce blog’s own guidance on aligning patterns to use cases
• security best-practice references
• certificate lifecycle management a first-class operational concern

FAQ

Was sind die besten Werkzeuge für Salesforce-Integrationen?

Platform Events, Change Data Capture und die Pub/Sub API decken die meisten ereignisgesteuerten Szenarien ab, während Named Credentials und Salesforce Connect für sichere Verbindungen und Datenvirtualisierung sorgen. Für die Orchestrierung über mehr als zwei Systeme ist eine Integrationsplattform (iPaaS) oder ein API-Gateway den nativen Werkzeugen allein in der Regel überlegen.

Was sind bewährte Praktiken für die Salesforce-Entwicklung in Integrationsprojekten?

Entwerfen Sie entlang eines Rahmens zur Musterwahl, bevor Sie Code schreiben, entscheiden Sie sich für alles jenseits einfacher Verbindungen zwischen zwei Systemen standardmässig für asynchrone Verfahren, und sichern Sie jede Zugangsberechtigung über Named Credentials, statt Token fest zu verdrahten. Bauen Sie Idempotenz und Wiederholungslogik von Anfang an ein, statt sie nach dem ersten Ausfall in der Produktion nachzurüsten.

Wie verbinden Sie Salesforce mit einer anderen Salesforce-Org?

Für die Integration zwischen zwei Orgs kommen meist Platform Events oder Change Data Capture zum Einsatz, um nahezu in Echtzeit zu synchronisieren, oder die Bulk API für geplante Stapelübertragungen grösserer Datenmengen. Named Credentials auf beiden Orgs, kombiniert mit einer Connected App oder External Client App per OAuth, halten die Verbindung sicher, ohne Geheimnisse fest zu verdrahten.

Worin unterscheiden sich Change Data Capture und Platform Events?

Change Data Capture veröffentlicht automatisch Änderungsereignisse, sobald Datensätze eines abonnierten Objekts angelegt, aktualisiert, gelöscht oder wiederhergestellt werden, ganz ohne eigene Trigger-Logik. Platform Events sind selbst definierte Ereignisse, die Sie aus Apex, Flow oder einem externen System ausdrücklich für jedes beliebige Geschäftsereignis veröffentlichen, nicht nur für Änderungen an Datensätzen.

Wann sollten Sie Salesforce Connect statt Datenreplikation nutzen?

Nutzen Sie Salesforce Connect, wenn sich externe Daten zu häufig ändern, um eine synchrone Kopie aktuell zu halten, oder wenn eine Kopie Fragen zu Speicher oder Compliance aufwirft. Replizieren Sie stattdessen, wenn Nutzende die Daten in Salesforce auswerten oder in Flows und Validierungsregeln referenzieren müssen, was virtualisierte Objekte nicht vollständig unterstützen.

Empfohlen

• Systemintegration & API-Entwicklung Zürich
• KI-Automatisierung & Workflow-Agenten Zürich