Seite 03 / 08 · Verarbeitungskette

Sechs Stufen, kein Handanlegen

Zwischen Eingang und Zielsystem liegen sechs Stufen. Jede übergibt ihren Zustand an die nächste, jede hinterlässt einen Journal-Eintrag — und keine verlangt eine Bedienung. Was scheitert, blockiert nicht den Rest des Stapels.

01

Eingang sichten und Dokumente belegen

Der Lauf sichtet den Eingangs-Kanal und nimmt höchstens fünf Dokumente pro Durchgang. Jedes wird per Blob-Lease für 60 Sekunden belegt — das ist der Automatik-Verkehrsregler: zwei parallele Läufe greifen sich nie dasselbe Dokument, und stürzt ein Lauf ab, wird das Dokument nach Ablauf von selbst wieder frei.

Batch-Größe 5 Lease 60 s, verlängerbar belegt → übersprungen, nicht abgebrochen
02

Klassifizieren, splitten, beschriften CLASSIFIER

Nur die ersten Seiten gehen an den Klassifikator. Für jedes erkannte Teildokument werden dessen Seiten als eigenes PDF in den Ausgabe-Container geschrieben — in einen Pfad aus Klassifikatorname und Dokumentart — und mit zwei Metadaten versehen: der erkannten Kategorie und ihrer Konfidenz. Im Erfolgsfall wird die Quelle freigegeben und gelöscht; der Lease wird währenddessen aktiv verlängert, weil die Klassifikation länger dauern kann als seine Frist.

Ablagepfad
<Ausgabeordner> / <Klassifikatormodell> / <Dokumentart> / <Datei>.pdf
Blob-Metadaten
AnalysedCategory = Dokumentart · CategoryConfidence = 0.00–1.00
03

Modell finden RECOGNIZER

Die Extraktion sucht sich ihr Modell selbst: aus dem Ablagepfad liest sie den Klassifikatornamen, aus den Blob-Metadaten die Dokumentart — und wählt damit genau das Erkennungsmodell, das für diese Kombination konfiguriert ist. Dieser Griff ist der eigentliche Übergabepunkt zwischen den Modulen und Thema von Seite 06. Was geschieht, wenn für die erkannte Dokumentart kein Modell existiert, steht auf Fehlendes Modell.

04

Analysieren und auf Zielfelder mappen

Das Dokument geht an die Engine des Modells — klassisch trainierte Feldextraktion oder ein von NexoGraph Document Processing autorisierter Analyzer. Felder und Tabellenzellen werden auf die konfigurierten Zielfeldnamen gemappt und als Ergebnisdatensatz gespeichert; Roh-JSON und Original wandern in den Analyse-Container. Ein Inhalts-Hash je Dokument dient als Sparbremse: taucht derselbe Inhalt erneut auf, wird das gespeicherte Ergebnis wiederverwendet statt neu analysiert.

Document Intelligence NexoGraph Document Processing Dedup per Inhalts-Hash
05

An alle Ziele zustellen

Das Ergebnis geht gleichzeitig an alle registrierten Endpunkt-Adapter — Dokumentenmanagement und beliebig viele REST-Ziele gleichberechtigt. Nicht konfigurierte Ziele melden sauber „übersprungen“, erwartbare Fehler melden „gescheitert“; keiner wirft den Lauf um. Jeder Adapter schreibt seine eigene Journal-Stufe.

06

Abschließen — oder wiederholbar liegen lassen

Dokument und Analyse-JSON wandern nach final/ — aber nur, wenn kein als Pflicht markiertes Ziel gescheitert ist. Andernfalls bleibt alles liegen und ist per POST /RetryEndpoint ohne erneute Analyse wiederholbar. Die Entscheidung über die Ablage trifft der Lauf, nicht ein einzelner Adapter.

Was den Lauf nicht stoppt
check_circle
Ein defektes Dokument bekommt einen Journal-Endzustand — der Batch läuft weiter.
check_circle
Ein bereits belegtes Dokument wird übersprungen, nicht als Fehler behandelt.
check_circle
Ein leerer Batch bleibt sichtbar: er wird als eigener Journal-Eintrag protokolliert, statt kommentarlos zu enden.
check_circle
Selbst ein Ausfall des Journals stoppt die Verarbeitung nicht — er wird geloggt, nicht eskaliert.