Am Ende können Sie den Integrationsvertrag schreiben
Sie können eine Integration planen, die keine doppelten Aktionen, stillen Ausfälle oder unmöglich zu rekonstruierenden Kundendatensätzen erzeugt.
Eine Prompt kann entscheiden, was empfohlen werden soll, aber Integrationen verschieben echte Daten und Aktionen.
Eine Prompt kann entscheiden, was empfohlen werden soll, aber Integrationen verschieben echte Daten und Aktionen. Ein verzögerter Webhook, doppelte Lieferung, abgelaufene Anmeldeinformationen oder ein geändertes Schema können ein Kundenproblem verursachen, selbst wenn die Sprache des Agenten perfekt ist.
Validieren, handeln, aufzeichnen und wiederherstellen
Schlüsselbegriffe: Webhook, Idempotenz, Validierung und Dead-Letter oder Überprüfungswarteschlange
Wie man den Integrationsvertrag schreibt
Beschreiben Sie den Veranstaltungsvertrag
Listenquelle, Ereignisname, stabile Kennung, erforderliche Felder, Authentifizierung und erwartete Aktion.
Vor Duplikaten schützen
Notieren Sie die Ereigniskennung oder den Zustandsübergang, bevor Sie eine kundenorientierte Aktion ergreifen.
Sicheres Versagen wählen
Wenn die Validierung oder ein abhängiges Tool fehlschlägt, halten Sie den Fall zurück, benachrichtigen Sie den Verantwortliche und behalten Sie genügend Kontext bei, um es erneut zu versuchen.
Protokollieren Sie das Ergebnis
Erfassen Sie, wann das Ereignis aufgetreten ist, was validiert wurde, welche Aktion aufgetreten ist und alle Fehler oder Wiederholungsversuche.
Arbeitsfall: Verbinden Sie APIs und Webhooks mit Schutzmaßnahmen
Eine Webinar-Plattform sendet ein Registrierungsereignis an einen Client-Arbeitsbereich. Der Workflow validiert die Ereignissignatur, prüft eine stabile Registrierungskennung, erstellt oder aktualisiert den Kontakt und speichert die Quellereignis-ID.
Wenn das Ereignis erneut bereitgestellt wird, wird der Kontakt nicht zweimal in derselben Reihenfolge registriert. Wenn der Kontaktdatensatz nicht erstellt werden kann, tritt das Ereignis mit der ursprünglichen Payload-Referenz und einem benannten Verantwortliche in eine Überprüfungswarteschlange ein.
Der Agent kann später den verifizierten Registrierungskontext verwenden, aber die Integration selbst bleibt deterministisch und überprüfbar.
Angewandtes Labor
Brechen Sie die Integration, bevor ein Kunde dies tut
Bauen Sie einen kleinen Fehlerbaum um eine Schreibaktion herum. Das Ziel ist keine erfolgreiche Demo. Es ist ein Beweis dafür, dass Wiederholungen, Duplikate, schlechte Nutzlasten und verspätete Ereignisse keinen stillen Schaden verursachen können.
- Schritt 1
Definieren Sie den Veranstaltungsvertrag
Zeichnen Sie die Ereignis-ID, den Mieter, den Akteur, die Schemaversion, den Zeitstempel, das zulässige Ziel und die minimale Nutzlast auf. Lehnen Sie unbekannte Felder ab, anstatt sie leise durchzugeben.
- Schritt 2
Machen Sie das Schreiben idempotent
Speichern Sie einen Idempotenzschlüssel mit dem Ergebnis. Senden Sie dasselbe Ereignis zweimal und beweisen Sie, dass die zweite Anfrage das aufgezeichnete Ergebnis zurückgibt, ohne eine zweite Buchung, Nachricht oder ein CRM-Update zu erstellen.
- Schritt 3
Vier Ausfallmodi erzwingen
Führen Sie eine Zeitüberschreitung aus, nachdem der Anbieter das Schreiben, ein Out-of-Order-Ereignis, eine abgelaufene Anmeldeinformation und eine fehlerhafte Nutzlast akzeptiert hat. Notieren Sie, ob das System den Fall erneut versucht, pausiert, kompensiert oder an eine Person sendet.
- Schritt 4
Sich mit Beweisen absöhnen
Vergleichen Sie den Quelldatensatz, den Anbieterdatensatz, das Ereignisprotokoll und den vom Kunden sichtbaren Status. Schreiben Sie die Abfrage oder den Bericht, den ein Operator verwenden würde, um Meinungsverschiedenheiten zu finden und zu beheben.
Arbeitsvorlage
event_id: evt_1042
tenant_id: client_acme
actor: agent_followup_v3
schema_version: 2
idempotency_key: client_acme:booking:lead_781:2026-08-13
action: create_booking
expected_result: one booking and one audit record
failure_injected: provider timeout after acceptance
observed_result:
recovery_decision:
evidence_link:Vorzureichende Beweise
Reichen Sie den Ereignisvertrag, vier Testaufzeichnungen, die resultierenden Protokolle und eine Abstimmungsansicht ein. Eine Prosa-Behauptung, dass die Integration zuverlässig ist, ist kein Beweis.
Bestehen der Kriterien
- Ein wiederholtes Ereignis kann die Geschäftsaktion nicht wiederholen.
- Jeder Fehler endet in einem sichtbaren Zustand mit einem Besitzer.
- Protokolle identifizieren den Akteur und Mieter, ohne Geheimnisse preiszugeben.
Den Integrationsvertrag schreiben
Gehen Sie davon aus, dass jeder externe Anruf zweimal fehlschlagen kann.
Ein Timeout sagt Ihnen nicht, ob das Remote-System nichts getan hat oder die Aktion abgeschlossen hat und die Reaktion verloren hat. Design versucht es erneut, diese Mehrdeutigkeit zu umgehen. Halten Sie den Workflow-Status außerhalb des Modells bei und geben Sie jeder konsequenten Anforderung einen Idempotenzschlüssel oder einen anderen Duplikat-Kontrollmechanismus.
- Stellen Sie Timeouts und begrenzte Wiederholungen mit Backoff ein.
- Unterscheiden Sie sichere Wiederholungen, manuelle Überprüfung, Entschädigung und Terminalfehler.
- Testen Sie einen Absturz nach der externen Aktion, aber vor der lokalen Bestätigung.
Quellen, die für diese Prüfung verwendet werden
Bevor Sie weitermachen
- Schreiben Sie den Vertrag für ein Inbound-Event.
- Simulieren Sie doppelte Zustellung und fehlende Felder.
- Entscheiden Sie, was ein Mensch sieht, wenn die Integration nicht abgeschlossen werden kann.
- Das Ereignis hat eine stabile Kennung.
- Validierung geht vor kundenorientiertem Handeln.
- Doppelte Lieferung ist harmlos.
- Fehler bleiben sichtbar und im Besitz.
Lektionsfortschritt
Haben Sie diese Lektion abgeschlossen?
Speichern Sie Ihren Fortschritt auf diesem Gerät, damit Sie später leicht weitermachen können.
Noch nicht als abgeschlossen markiert.