Fehlerbehandlung
Teil von Betrieb und Überwachung
Fehler mit ausreichendem Kontext protokollieren
Erfassen Sie Vorgang, Versuch, Schritt und bekannten Ausgang eines Workflow-Fehlers, ohne Geheimnisse oder unnötige Rohdaten mitzuschreiben.
Ein Fehlerereignis sollte den betroffenen Fall auffindbar machen, den fehlgeschlagenen Schritt benennen und zwischen bestätigtem und unbekanntem Ausgang unterscheiden. Dafür braucht es ausgewählte strukturierte Felder, keinen vollständigen Anfragekörper.
Fall und Versuch trennen
Ein Geschäftsfall kann mehrere technische Ereignisse erzeugen. Nutzen Sie eine stabile Vorgangskennung und eine separate Kennung für Ereignis oder Versuch. Erfassen Sie nur Felder, die die spätere Untersuchung braucht:
Feld / Untersuchungszweck
- Vorgangskennung
- Den fachlichen Fall finden.
- Ereignis- oder Versuchskennung
- Mehrere Versuche unterscheiden.
- Ereigniszeit und Workflow-Fassung
- Den Fehler zeitlich und einer Fassung zuordnen.
- Schritt und Zieloperation
- Den betroffenen Übergang bestimmen.
- Bekannter Ergebnisstatus und Fehlerklasse
- Beobachtung von Vermutung trennen.
- Bekannte Zielkennung
- Eine mögliche Wirkung im Zielsystem abgleichen.
- Nächster Bearbeitungszustand
- Erkennen, ob der Fall wartet oder zugewiesen wurde.
Die Feldliste ist ein Vorschlag, kein vorgeschriebenes Schema. Nicht jedes Feld liegt bei jedem Fehler vor. Fehlt nach einer gesendeten Anfrage die Antwort, protokollieren Sie Ergebnis unbekannt – nicht einen behaupteten Fehlschlag.
Empfohlene Felder für strukturierte Fehlerprotokollierung
- Vorgangskennung
- Zum Finden des fachlichen Falls
- Ereignis- oder Versuchskennung
- Unterscheidung mehrerer Versuche
- Ereigniszeit und Fassung
- Zeitliche und versionsbezogene Zuordnung
- Schritt und Zieloperation
- Bestimmung des betroffenen Übergangs
- Bekannter Ergebnisstatus
- Beobachtung von Vermutung trennen
Struktur und Korrelation nutzen
Feste Feldnamen und wenige verständliche Fehlerklassen erleichtern die Zusammenfassung nach Schritt und Ursache. Ein kurzer bereinigter Fehlertext kann ergänzen, was Felder nicht erklären. Ein Stacktrace allein zeigt der fachlichen Betreuung meist nicht, welcher Fall betroffen ist.
Geben eingesetzte Dienste Trace- oder Korrelationskennungen weiter, verbinden diese technische Schritte. Für einen Geschäftsfall bleibt die Vorgangskennung über getrennte Ausführungen hinweg nötig. Prüfen Sie, welche Kennungen Ihre Plattform tatsächlich liefert und wie sie weitergereicht werden.
Vertrauliche Inhalte begrenzen
Legen Sie erlaubte Logfelder und Lesezugriffe fest. Passwörter, Zugangstoken, Schlüssel sowie unnötige personenbezogene oder geschäftlich sensible Angaben dürfen nicht ungeprüft in technische Protokolle gelangen.
Prüfen Sie auch automatisch erfasste Header, URLs, Eingaben, Ausgaben und Ausnahmetexte. Ein Fallbezeichner kann selbst sensibel sein; verwenden Sie bei Bedarf eine pseudonyme Kennung mit geschützt verwahrter Zuordnung.
Fachlich Zuständige brauchen oft Fallkennung, Zustand und Korrekturgrund. Technische Betreuung braucht eher Schritt, Fehlerklasse und zulässige Antwortdetails. Geben Sie jeder Rolle nur den Kontext, den sie für ihre Aufgabe benötigt.
Testen Sie das Schema vor dem Einsatz mit harmlosen Beispielen: einer eindeutig zurückgewiesenen Übergabe und einer verlorenen Antwort. Prüfen Sie in der vorgesehenen Umgebung, ob beide Fälle auffindbar wären und ob Testgeheimnisse in Protokoll, Ausführungshistorie oder Alarmtext auftauchen.
