Referenz: Session-Zustandsautomat¶

Eine Session verfolgt zwei Dinge unabhängig: wo sie ist in der Pipeline (current_stage) und wie es ihr geht (health). Diese Trennung ist der Grund, warum eine Session auf der Stufe checked sein und trotzdem durch Fehler blocked oder zum Bestätigen ready sein kann.

Stufen¶

current_stage durchläuft:

CREATED → UPLOADED → PARSED → TRANSFORMED → VALIDATED → CONFIRMED → APPROVED → EXPORTED

Automatisierte Stufen — parsed, transformed, checked — rücken nur vor, wenn ihr Ergebnis passed oder warnings ist. Bei errors rückt die Stufe nicht vor, sodass Sie korrigieren und ab dem Haltepunkt erneut laufen können.
Manuelle Stufen — confirmed, approved, exported — rücken bei Aktion immer vor, unabhängig vom Ergebnis.

Stufen-Ergebnisse¶

Jede Stufe hält ein Ergebnis in einer Pro-Stufen-Zusammenfassung fest:

Ergebnis	Bedeutung
`pending`	Nicht gestartet.
`running`	In Arbeit.
`passed`	Sauber abgeschlossen.
`warnings`	Mit Warnungen abgeschlossen.
`errors`	Fehlgeschlagen; blockiert den Fortschritt.

Pro Stufe speichert die Session das outcome, einen error_count, einen warning_count und einen updated_at-Zeitstempel — das treibt die Pro-Schritt-Einfärbung in der UI.

Optionale Sources und übersprungene Arbeit¶

Ist eine DataContract-Source optional und wird nicht geliefert, wird ein Transformer, der nur von ihr abhängt, als SKIPPED markiert statt fehlzuschlagen. Ein übersprungener Transformer zählt als erledigt, sodass die Stufen transformed und checked weiterhin passed erreichen und health ready werden kann. Beim Export wird die fehlende optionale Source unter omissions in datapackage.json und im export_report der Session aufgeführt. Eine fehlende erforderliche Source erzeugt weiterhin errors.

Health¶

health wird aus den Stufen und der aktuellen Stufe abgeleitet — nie direkt gesetzt. Die Ableitung in Prioritätsreihenfolge:

current_stage == exported → completed
ein Stufen-Ergebnis ist errors → blocked
ein Stufen-Ergebnis ist running → in_progress
ein Stufen-Ergebnis ist warnings → attention
current_stage in (checked, confirmed, approved) ohne Fehler/Warnungen → ready
noch keine Stufen erfasst → created
sonst → in_progress

Also: ein Fehler irgendwo macht die ganze Session blocked; Warnungen ohne Fehler machen sie attention; ein sauberer Lauf durch die Validierung macht sie ready zum Bestätigen.

Eine blockierte Session erneut ausführen¶

blocked verhindert, dass die Session vorwärts geht — nicht, dass sie erneut läuft. Bis zur Bestätigung können run, transform und check erneut gestartet werden, auch auf einer checked Session, deren Geschäftsregeln fehlgeschlagen sind. Nachdem eine Geschäftsregel, eine Entity-Regel, ein Transformer-Mapping oder ein Katalog korrigiert wurde: run (oder check) auf einer checked Session wiederholt die Entity-Validierung und die Geschäftsregeln; transform auf einer transformed oder checked Session wiederholt ab der Transformation. Die Session geht auf die Stufe vor der wiederholten zurück (checked → transformed, transformed/checked → parsed), bis der neue Lauf sein Ergebnis festhält; jeder Start wird als neuer Lauf in der Lauf-Historie festgehalten. Während die fehlgeschlagene Stufe erneut läuft, bleibt die Session blocked (ihr Stufeneintrag ist running mit previous_outcome: errors); die Blockade fällt erst, wenn der neue Lauf ein sauberes Ergebnis liefert, und kehrt zurück, wenn er erneut scheitert. confirm, approve und export bleiben gesperrt.

Warum das beim Prüfen zählt¶

Wenn Sie die Sessions-Liste öffnen, sagt Ihnen die Health-Spalte, was Aktion braucht (blocked / attention) versus was voranschreitet oder bereit ist. Die Stufe sagt, wie weit jede Lieferung gekommen ist. Zusammen können Sie viele Lieferungen auf einen Blick triagieren, ohne jede zu öffnen.