PUNKT-ZU-PUNKT
Direkte Verbindungen sind nicht das Problem.
Eine einzelne direkte Schnittstelle kann die einfachste und beste Lösung sein. Das Risiko entsteht, wenn Regeln, Fehlerbehandlung und Verantwortlichkeiten mit jeder Verbindung anders gelöst werden.
Jede Schnittstelle kennt ihre eigenen Regeln: Feldzuordnung, Statuslogik und Fehlerbehandlung werden pro Verbindung individuell umgesetzt. Änderungen lassen sich dadurch immer schwerer überblicken.
Abhängigkeiten werden erst bei Änderungen sichtbar: Eine kleine Anpassung im Quellsystem kann mehrere Empfänger betreffen. Ohne gemeinsamen Vertrag bleibt oft unklar, welche Auswirkungen wirklich zu prüfen sind.
Betrieb wird zum Wissen einzelner Personen: Wenn Monitoring, Wiederanlauf und Supportweg nicht klar geregelt sind, hängt die Fehlerbehebung schnell an wenigen erfahrenen Teammitgliedern.
Die Frage ist daher nicht „Punkt-zu-Punkt oder Middleware?“, sondern: Bleibt die Integration auch bei Fehlern und Änderungen beherrschbar?
ROBUSTE INTEGRATION
Vier Dinge sollten unabhängig vom Integrationsmuster klar sein.
Ob direkte API, Middleware, Event oder Batch: Für den Betrieb braucht jede relevante Schnittstelle dieselben grundlegenden Antworten.
- Klare Systemverantwortung: Welches System ist für welche Information führend – und welches Team verantwortet Änderungen?
- Nachvollziehbarer Datenvertrag: Welche Daten werden übertragen, was bedeuten sie und welche fachlichen Regeln gelten?
- Explizite Fehlerwege: Welche Fehler können auftreten, wer übernimmt und wann darf automatisch wiederholt werden?
- Betrieb und Änderungen: Wie werden Monitoring, Support, Versionierung und spätere Anpassungen organisiert?
BEISPIEL
Ein Auftragsstatus klingt einfacher, als er im Betrieb ist.
Ein Quellsystem liefert einen Status an Salesforce. Solange alles funktioniert, wirkt die Verbindung trivial. Relevant wird die Architektur erst bei Abweichungen.
Diese Fälle sehen technisch ähnlich aus, brauchen aber unterschiedliche Verantwortliche und unterschiedliche nächste Schritte.
- Was passiert, wenn das Zielsystem nicht erreichbar ist?
- Was passiert, wenn Salesforce den Auftrag nicht kennt?
- Was passiert, wenn ein Pflichtfeld fehlt?
- Wie werden doppelte Nachrichten erkannt?
Weitere Schritte (1)
- Was passiert bei einem fachlich unzulässigen Status?
- Quelle
- Vertrag
- Verarbeitung
- Salesforce
- Monitoring
- Retry oder Eskalation
- Owner
VOR DER UMSETZUNG
Fragen, die vor der ersten Nachricht geklärt sein sollten.
Viele Betriebsprobleme lassen sich vermeiden, wenn die wichtigsten Entscheidungen bereits vor der Implementierung sichtbar sind.
WIEDERANLAUF
Wiederholen – aber nicht blind.
Nach einem technischen Fehler ist „noch einmal senden“ nicht automatisch sicher. Vor einem Wiederanlauf sollte klar sein, welche Nachrichten betroffen sind und ob die Ursache wirklich behoben wurde.
Ein Wiederanlauf ist eine kontrollierte Betriebsaktion – kein unsichtbarer Retry.
- Umfang begrenzen
Nur die tatsächlich betroffenen Nachrichten und den relevanten Zeitraum auswählen.
- Ursache prüfen
Sicherstellen, dass der ursprüngliche Fehler behoben oder fachlich geklärt ist.
- Nebenwirkungen ausschließen
Prüfen, ob Duplikate, Reihenfolge oder bereits verarbeitete Nachrichten berücksichtigt werden müssen.
- Wiederanlauf freigeben
Nur dann erneut verarbeiten, wenn Umfang, Wirkung und Verantwortung geklärt sind.
BETRIEBSGRUNDLAGE
Was zu einer betreibbaren Schnittstelle dokumentiert sein sollte.
Quell- und Zielsystem
Welche Systeme sind beteiligt und welches System ist für welche Information führend?
Datenvertrag
Welche Felder, Bedeutungen, Statuswerte und Pflichtangaben gelten?
Fehlerklassen
Welche technischen und fachlichen Fehler sind bekannt und wie werden sie behandelt?
Wiederanlauf
Welche Fälle dürfen wiederholt werden und welche Prüfungen müssen vorher erfolgen?
Weitere Prüfkriterien (3)
Monitoring
Woran erkennen Teams, dass Nachrichten fehlen, hängen bleiben oder abgelehnt wurden?
Verantwortung
Welche Teams übernehmen Quelle, Integration, Zielsystem und Support?
Änderungsweg
Wie werden neue Versionen, Kompatibilität und Rücknahme von Änderungen organisiert?
Wie solche Entscheidungen dauerhaft nachvollziehbar bleiben, zeigt Integrationsentscheidungen dokumentieren: Ein Decision Log für Architektur und Betrieb.
NÄCHSTE SCHRITTE
So bringen Sie bestehende Schnittstellen unter Kontrolle.
01
Kritische Verbindungen auswählen
Nicht alle Schnittstellen gleichzeitig analysieren. Beginnen Sie mit Verbindungen, die häufig geändert werden oder im Betrieb regelmäßig Probleme verursachen.
02
Vertrag und Verantwortung sichtbar machen
Daten, Semantik, Owner, Fehlerklassen und Supportweg gemeinsam dokumentieren.
03
Fehlerwege testen
Nicht nur den Happy Path prüfen. Technische Fehler, fachliche Ablehnung und Wiederanlauf bewusst testen.
04
Änderungen kontrollieren
Versionen, Kompatibilität und Rollback beziehungsweise Rücknahme in den normalen Änderungsprozess aufnehmen.
FEHLERBEHANDLUNG
Häufige Fragen zu Salesforce-Integration
Ist Punkt-zu-Punkt grundsätzlich eine schlechte Architektur?
Nein. Eine direkte Verbindung kann für einen klar begrenzten Anwendungsfall völlig sinnvoll sein. Problematisch wird sie, wenn Verträge, Fehlerwege und Verantwortung uneinheitlich oder unsichtbar bleiben.
Wann lohnt sich Middleware?
Wenn mehrere Systeme dieselben Integrationsaufgaben teilen, zentrale Transformation, Routing oder Monitoring sinnvoll werden oder sich direkte Abhängigkeiten sonst stark vervielfachen. Middleware ist aber kein Selbstzweck.
Wann darf eine Nachricht automatisch erneut verarbeitet werden?
Nur wenn klar ist, dass der Fehler vorübergehend war und die erneute Verarbeitung keine fachlichen Nebenwirkungen erzeugt. Fachliche Fehler sollten nicht blind wiederholt werden.
Was gehört mindestens in einen Schnittstellenvertrag?
Daten und Semantik, Systemverantwortung, Fehlerverhalten, Wiederanlauf, Versionierung und die wichtigsten Betriebsannahmen.
Quellen und weitere Informationen
Für weiterführende Informationen zu Salesforce-Integration, APIs und Betriebsmodellen sind insbesondere diese Quellen hilfreich:
- Salesforce Architects – Data Integration with SalesforceGeprüft am
Unterstützt Salesforce-Integrationsmuster, Entscheidungsleitfäden und Betriebsprinzipien; Plattform- und Musterempfehlungen vor Veröffentlichung erneut prüfen.
- Salesforce Architects – Integration Decision GuidesGeprüft am
Unterstützt Salesforce-Integrationsmuster, Entscheidungsleitfäden und Betriebsprinzipien; Plattform- und Musterempfehlungen vor Veröffentlichung erneut prüfen.
- Salesforce Architects – Integration PatternsGeprüft am
Unterstützt Salesforce-Integrationsmuster, Entscheidungsleitfäden und Betriebsprinzipien; Plattform- und Musterempfehlungen vor Veröffentlichung erneut prüfen.
Themen dieses Beitrags
SO KÖNNTE ES IM ALLTAG AUSSEHEN
Drei Ansichten, die Integrationsbetrieb nachvollziehbar machen.
Fiktive Arbeitsbereiche zeigen Entscheidung, Abhängigkeiten und den nächsten Betriebsschritt. Redaktionelle Illustrationen, keine Live-Produktscreenshots.
Fehlerbearbeitung · nächsten Schritt zuordnen
Eigenes Fehlerboard: Fachliche Ablehnung mit Verantwortung und konkretem nächsten Schritt.
Mit dem Finger wischen oder mit gedrückter Maustaste ziehen. Alternativ die Bildauswahl oder Pfeiltasten nutzen.
Bild 1 von 3: Fehlerbearbeitung · nächsten Schritt zuordnen
Passend weiterlesen
Salesforce Standard oder Custom? Eine Entscheidung mit Augenmaß
Standard, Low-Code oder Custom: Die technisch einfachste Lösung ist nicht automatisch die beste. Entscheidend ist, welche Variante den fachlichen Bedarf erfüllt und auch später noch verständlich, testbar und wartbar bleibt. Der Vergleich sollte deshalb nicht nur auf Entwicklungsaufwand schauen, sondern auch auf Abhängigkeiten, Berechtigungen, Betrieb und spätere Änderungen.
Beitrag lesen
Angebote in Salesforce: Welche Revenue-Lösung passt?
Ob Standardfunktionen, CPQ oder eine umfassendere Revenue-Lösung sinnvoll sind, hängt nicht zuerst vom Produktnamen ab. Entscheidend ist, wie Produkte, Preise, Freigaben, Verträge und nachgelagerte Systeme heute zusammenspielen. Je klarer diese Regeln und Systemgrenzen vorab sind, desto leichter lässt sich der passende Lösungsumfang wählen.
Beitrag lesen
Integrationsentscheidungen dokumentieren: Ein Decision Log für Architektur und Betrieb
Ein Integrationsdiagramm zeigt, welche Systeme verbunden sind. Ein Decision Log hält zusätzlich fest, warum eine bestimmte Variante gewählt wurde, welche Alternativen geprüft wurden und unter welchen Annahmen die Entscheidung gilt. So bleibt die Begründung auch dann nachvollziehbar, wenn sich Systeme, Volumen oder Verantwortlichkeiten später verändern.
Beitrag lesen