Unklare Kundenzuordnungen brauchen einen festen Klärungsweg

Kann eine Integration den Kunden eines Vorgangs nicht zuverlässig zuordnen, sollte dieser Fall bearbeitbar bleiben. Dazu gehören eine zuständige Rolle, die nötigen Informationen und ein kontrollierter Rückweg in die Verarbeitung. Ein Fehlerprotokoll und die Aufforderung, später erneut zu senden, reichen für eine fachlich ungeklärte Identität nicht aus.

Microsoft nennt bei mehrstufigen Abläufen auch manuelle Eingriffe mit nachvollziehbarem Fehlergrund. Unser Beispiel wartet vor dem Schreiben ins Ziel.

Ein offener Fall braucht ein sichtbares Ergebnis

Im vollständig erfundenen Beispiel soll die Projektanfrage R-28 einen Projektentwurf im ERP erzeugen. Für den CRM-Kunden C-508 fehlt eine bestätigte Zuordnung. Die zuständige Person klärt, dass das vorhandene ERP-Kundenkonto K-410 verwendet werden soll. Die folgende Tabelle beschreibt den gewünschten Ablauf.

Ein Name auf einer Liste darf nicht allein die Auswahl des Kunden bestimmen. Die Bearbeitung muss den Anlass, den geprüften Quellenstand, die bisherige und gewählte Zuordnung sowie die Entscheidungsbegründung zusammenhalten. Zugriff auf solche Fälle erhält nur die dafür berechtigte Rolle.

Die Korrektur muss den aktuellen Stand berücksichtigen

Zwischen Anzeige und Bestätigung können Daten oder Rechte verändert worden sein. Prüfen Sie vor der Fortsetzung die aktuelle Berechtigung und ob das gewählte Kundenkonto noch verwendet werden darf. OWASP verlangt eine Berechtigungsprüfung bei jeder Anfrage. Eine bereits geöffnete Bearbeitungsmaske ersetzt diese Prüfung nicht.

Auch zwei gleichzeitig bearbeitende Personen dürfen keine unbemerkten widersprüchlichen Entscheidungen speichern. Veränderte Grundlagen oder ein bereits gelöster Fall müssen bei der Bestätigung erkannt werden. Falls die Voraussetzungen nicht mehr passen, bleibt der Vorgang zur erneuten Klärung offen.

Eine Wiederholung darf keinen zweiten Projektentwurf erzeugen

Alle Versuche bleiben mit derselben Projektanfrage verbunden. Das erfordert zusätzlich eine geeignete Absicherung im Ziel, etwa eine idempotente Anlage, die bei derselben Wiederholung keinen zusätzlichen Entwurf erzeugt, oder eine im Ziel durchgesetzte eindeutige externe Referenz mit verlässlicher Ergebnisabfrage. Die Vorgangskennung allein verhindert keine Doppelanlage.

Fehlt nach dem Schreiben die Antwort, wird zunächst das Ergebnis des vorhandenen Vorgangs geklärt. AWS weist darauf hin, dass ein Timeout bereits eingetretene Nebenwirkungen nicht ausschließt. Bis zur Klärung darf ein unbekannter Ausgang nicht als sicher fehlgeschlagen behandelt und durch einen beliebigen neuen Auftrag ersetzt werden.

Den manuellen Weg auf die nötigen Fälle begrenzen

Eine eindeutige, geprüfte Zuordnung kann automatisch verarbeitet werden. Nicht jeder Datensatz braucht eine menschliche Freigabe. Für die übrigen Fälle müssen Bearbeitungszuständigkeit, vereinbarte Reaktionszeit und Eskalation sichtbar sein; eine wachsende Liste ohne Besitzer löst das Problem nicht.

Unser Beispiel hält vor der Projektanlage an. Wurde bereits etwas beim falschen Kunden angelegt, braucht es eine eigene fachliche Korrektur mit Blick auf die entstandenen Verknüpfungen.

Quellen

• Microsoft — Compensating Transaction pattern

• OWASP — Authorization Cheat Sheet

• AWS — Timeouts, retries, and backoff with jitter