Auf dieser Seite
Zwei Unternehmen haben jeweils ein Feld namens „active“. Für das eine bedeutet es, dass eine Person im vergangenen Jahr etwas gekauft hat. Für das andere bedeutet es, dass ein Dienstleistungsvertrag noch gilt. Ein gemeinsamer Connector kann beide Felder korrekt übertragen. Eine gemeinsame Regel, die sie als denselben Geschäftszustand behandelt, kann für eines der Unternehmen falsch sein. Das ist ein Beispiel und kein Bericht aus einer Einführung.
Eine Diskussion über gemeinsam genutzte Plattformen und lokale Einführung beschreibt ein Unternehmen, das einen großen Teil seiner Infrastruktur wiederverwendet und dennoch viel Arbeit in den Umgebungen einzelner Kund:innen leistet. Die Prozentangaben gelten nur für dieses Unternehmen. Die allgemeine Architekturfrage lautet, wo gemeinsame Abläufe enden und lokale Bedeutung beginnt.
Trenne den Transportvertrag vom Geschäftsvertrag
Ein Transportvertrag kann Folgendes festlegen: bei der Quelle authentifizieren, geänderte Datensätze lesen, Kennungen erhalten, sicher wiederholen und Fehler sichtbar machen. Diese Abläufe können einmal implementiert und wiederholt getestet werden. Sie sind wertvoll, weil jede Integration einen verlässlichen Datenweg braucht.
Ein Geschäftsvertrag legt fest, welcher Datensatz maßgeblich ist, was ein Status bedeutet, wann eine Aktion zulässig ist und wer einen Fehler korrigieren darf.
- Gemeinsamer Transport Identität · Wiederholung · Ereignis-ID
liefert ein gültiges Ereignis
- Lokale Richtlinie Bedeutung · Einwilligung · Zeitpunkt
entscheidet, ob eine Aktion zulässig ist
- Autorisierte Aktion Schreibvorgang · Audit
hält das Ergebnis fest
Dieser Geschäftsvertrag hängt vom Workflow ab. Er kann dieselbe Quelle und dasselbe Zielsystem wie bei einem anderen Unternehmen nutzen und trotzdem eine andere Entscheidung verlangen.
Betrachte eine Verbindung zwischen Store und E-Mail-Plattform. Die Plattform kann Ereignisübernahme, Duplikaterkennung und einen Audit-Verlauf bereitstellen. Die zuständige Workflow-Stelle muss festlegen, ob „abonniert“ die Erlaubnis für einen bestimmten Marketingzweck bedeutet, ob ein Kauf eine Warenkorberinnerung unterdrückt und wie sich eine Änderung der Einwilligung auf bereits geplante Nachrichten auswirkt. Das sind keine Connector-Funktionen, die sich anhand von Feldnamen erraten lassen.
Die hier illustrierte Tajo-Zuordnung kopiert drei Felder direkt. Eine Entscheidung fehlt: Keine Zeile definiert die Erlaubnis für Marketing. Wiederverwendbarer Transport spart Arbeit. Die zuständige Person muss trotzdem festlegen, welcher Status welche Aktion erlaubt. Eine klare Feldzuordnung macht diese Lücke sichtbar, schließt sie aber nicht.
Sync vor dem Start prüfen
Synchronisiere Aktualisierungen der Kundendaten mit meiner E-Mail-Plattform.
Kundensynchronisierung
| Quellfeld | Zielfeld | Regel |
|---|---|---|
email | EMAIL | Direkt |
first_name | FIRSTNAME | Direkt |
last_name | LASTNAME | Direkt |
Synthetische Vorschau bestanden
3 Felder zugeordnet · Keine Schreibvorgänge im Zielsystem
Illustratives Layout auf Grundlage von Tajos Zuordnungswerkzeugen. Eine synthetische Vorschau und ein gespeicherter Entwurf aktivieren keinen Sync.
| Gemeinsame Ebene | Lokale Ebene |
|---|---|
| Authentifizierung und Token-Erneuerung | Welche Instanz auf diesen Workflow zugreifen darf |
| Ereignisübertragung und Wiederholungen | Welches Ereignis den geschäftlichen Zustandswechsel auslöst |
| Stabile Kennungen und Duplikaterkennung | Welche Datensätze dieselbe reale Kundin oder denselben Kunden meinen |
| Protokollierung und Wiederherstellungsmechanismen | Wer einen umstrittenen Zustand wie und mit welcher Lösung klärt |
| Vertragsvalidierung | Was Feldwerte bedeuten und wann sie eine Aktion auslösen dürfen |
Die Tabelle beschreibt eine Gestaltungsgrenze und behauptet nicht, dass sich jede Implementierung so sauber aufteilen lässt.
Wiederverwendung scheitert, wenn sie Meinungsunterschiede verbirgt
Eine allgemeine Plattform erhält oft für jede Ausnahme ein Konfigurationsfeld. Anfangs scheint das die Wiederverwendung zu bewahren. Später weiß niemand mehr, ob eine Einstellung eine technische Option, eine rechtliche Vorgabe oder eine geschäftliche Entscheidung ist. Der gemeinsame Kern wird zur Fernsteuerung von Entscheidungen, für die er nicht zuständig ist.
Suche nach einer stabilen Invariante. „Dasselbe Quellereignis niemals zweimal auf denselben Zieldatensatz anwenden“ kann in einer gemeinsamen Engine liegen. „Einen Rabatt senden, sobald eine Kundin aktiv wird“ lässt sich erst gemeinsam umsetzen, wenn „aktiv“, die zulässige Zielgruppe und die Angebotsrichtlinie eine zuständige Stelle haben. Die Engine kann eine freigegebene Richtlinie ausführen, aber keine erfinden.
Das hilft auch bei der Wartung. Ändert sich eine API, kann das Plattformteam den Adapter und seine Tests aktualisieren. Ändert sich die Definition einer berechtigten Kundschaft, kann die Geschäftsverantwortung die Richtlinie und Testfälle aktualisieren, ohne auf eine Änderung des Transports zu warten. Eine klare Grenze bringt jede Änderung zu der Person, die dafür zuständig ist.
Wiederverwende Abläufe, ohne Bedeutung einzuebnen
Manche lokalen Regeln verursachen zusätzliche Kosten. Eine Plattform ohne wiederverwendbare Verträge wird zu einer Sammlung maßgeschneiderter Skripte. Identifiziere zuerst wiederholte Mechanismen, bevor du wiederholte Bedeutungen abstrahierst. Ein gut gestalteter gemeinsamer Baustein kann ein typisiertes Prädikat, Ereigniszeit und Aktionsgrenze entgegennehmen, während die geschäftliche Definition des Prädikats lokal bleibt.
Teste die Grenze anhand realer Fälle. Nimm ein normales Ereignis, ein Duplikat, eine verspätete Korrektur und eine widerrufene Berechtigung. Frage, welche Ebene für die jeweilige Reaktion zuständig ist. Lässt sich ein Fehler keiner Stelle zuordnen, verbirgt die Abstraktion die Verantwortung. Muss bei einem neuen Unternehmen ein gemeinsamer „active“-Wert mehrere sachfremde Bedeutungen annehmen, ist der gemeinsame Typ zu weit gefasst.
Der ergänzende Artikel zur Einführung prüft, ob eine Fähigkeit in einem Live-Workflow funktioniert. Hier geht es darum, was sich einmal entwickeln lässt, ohne die Bedeutung des Workflows auszulöschen.
Die Schnittstelle zwischen Ebenen sollte deutlich genug sein, um eine falsche Annahme zurückzuweisen. Eine gemeinsame Engine kann vor einer Aktionsanfrage Ereignis-ID, Quellenzeitpunkt, handelnde Instanz und erklärten Zweck verlangen. Der lokale Workflow liefert die Richtlinie, die entscheidet, ob die Aktion zulässig ist. Fehlt der Zweck, muss die Engine die Anfrage ablehnen. Ist die Richtlinie mehrdeutig, muss die lokale Zuständigkeit sie klären. So bleibt Wiederverwendung möglich, ohne die Geschäftsverantwortung allgemeinem Code zu überlassen. Dokumentiere den Vertrag mit einem akzeptierten und einem zurückgewiesenen Beispiel und teste beide bei jeder Änderung an einer der Ebenen.
Ein wiederverwendbarer Connector sollte es leichter und sicherer machen, lokale Bedeutung auszudrücken und auszuführen. Er darf unterschiedliche Zusagen nicht gleich erscheinen lassen, nur weil ihre Felder denselben Namen haben.
Häufig gestellte Fragen
Was sollte eine Integrationsplattform üblicherweise wiederverwenden?
Stabile Abläufe wie Authentifizierungsmuster, Transport, Idempotenz, Wiederholungen, Protokollierung und Vertragsprüfungen lassen sich oft gemeinsam nutzen, wenn die zugrunde liegenden Anforderungen übereinstimmen.
Was sollte für jedes Unternehmen spezifisch bleiben?
Die Bedeutung der Felder, Zuständigkeit für die Quelle, Einwilligungsregeln, Zeitvorgaben und die Frage, wer auf einen Status reagieren darf, müssen für das jeweilige Unternehmen und den Workflow festgelegt werden.
Wie lässt sich diese Grenze testen?
Versuche, einen neuen Workflow mit bestehenden Bausteinen auszudrücken. Verändert das die geschäftliche Bedeutung oder versteckt es Ausnahmen in allgemeiner Konfiguration, lass die Logik lokal und mach die Schnittstelle eindeutig.