Standard-Ablauf

Der Standard-Ablauf der Phase 2 ist das Parsen der empfangenen Daten in die Quellstruktur und damit die Erzeugung des Quellbaums. Zudem kann der Parser die eingelesenen Daten in sogenannte Datenblätter aufspalten. Jeder Parser (je nach Dokumentenart) verhält sich hier leicht anders, lesen Sie sich bitte deshalb die Abschnitte Parsen und Wann beginnt der Parser ein neues Datenblatt? durch. Dort ist auch der Sinn von Datenblättern erklärt (z. B. kann man die Antwortwege in Phase 6 mit einer zusätzlichen Option einmal pro Datenblatt betreten, statt nur einmal pro Profillauf).

Im Folgenden werden zusätzlich optionale Abweichungen dieses Verarbeitungsflusses vorgestellt.

Hinweis: Auch wenn die folgend beschriebenen Zwischen-Phasen logisch und vom Zeitablauf her zur Phase 2 gehören, finden Sie deren Konfiguration in der GUI auf der Seite Basis-Daten.

Unbekannte und ignorierte Daten-Segmente

Kommen in Eingangsdateien Daten an, die mit der vorhandenen Quellstruktur nicht geparst werden können, dann gehen diese Daten erst einmal verloren (ohne einen Fehler des Profil-Jobs auszulösen).

Es ist aber möglich solche Daten zu loggen, auszuwerten und gegebenenfalls nachzubearbeiten. Siehe hierzu Abschnitt Unknown Segment Log Listener.

Umgebungsprüfung

Klassen für die Umgebungsprüfung (Environment Check) prüfen, ob bestimmte Bedingungen in der Systemumgebung erfüllt sind, bevor ein Job gestartet wird. Das Ergebnis der Umgebungsprüfung ist ein logischer Wert (true/false). Wenn die Prüfung den Wert false liefert, wird die Backupdatei angelegt und der Job suspendiert. Bei true wird der Job gestartet.

In dem Fall, dass der Job suspendiert wurde, liefert die Klasse zusätzlich einen Ganzzahlwert, der die Sekunden bis zu einem neuen Start angibt. Nach dieser Wartezeit wird erneut die Umgebungsprüfung durchgeführt und je nach Ergebnis der Job gestartet oder weiter suspendiert. Wenn der Job ausgeführt wird, erfolgt das mit der ursprünglichen Backupdatei, die beim ersten Lauf gesichert wurde. Die Quelldaten werden also nicht erneut vom Quellsystem abgeholt. Wenn im Fall false der nächste Lauf in 2147483647 (Integer.MAX_VALUE) Sekunden erfolgen soll, wird der Job dauerhaft suspendiert und die Backupdatei gelöscht.

Das Ziel dieses Features ist es, bei Nichtverfügbarkeit eines externen Systems die Verarbeitung zu verzögern, bis das System wieder verfügbar ist, um zu verhindern, dass der Job mit einer Fehlermeldung endet.

Hinweis: Die Umgebungsprüfung ist für kurzzeitige Umgebungsprobleme vorgesehen, nicht um tausende von Jobs über Tage auflaufen zu lassen. Die immer neuen Versuche belasten das System erheblich.

Preparser

Es gibt Situationen, in denen eine Eingangsdatei nicht durch einen Standard-Parser geparst werden kann.

• In der Datei sind zusätzliche Steuerzeichen, die der Parser nicht erwartet/erlaubt.

• Die Datei enthält Bytes, die in keinem bekannten Encoding vorkommen. Dateien enthalten Bytes. Erst wenn ein Encoding angewendet wird, werden daraus Zeichen. Jedes Encoding enthält nur einen definierten Satz von Bytekombinationen. Treten Bytekombinationen in der Datei auf, für die das Encoding kein Zeichen zuordnet, ist die Wandlung der Bytes in Zeichen fehlerhaft.

• Das Quellformat verwendet unübliche Zeichenfolgen als Record- oder Feld-Trenner. Um das Format überhaupt richtig in Datensätze und Felder zu trennen, müssen die Trennzeichenfolgen vorverarbeitet werden.

• Das Quellformat verwendet Umschreibungen für Umlaute usw. Umlaute und andere Sonderzeichen wurden vom Quellsystem als Escape-Folge umschrieben, sollen aber im Zielformat wieder als Umlaute usw. geschrieben werden.

• Spezielle Formate, die mit keinem der verhandenen Parser eingelesen werden können.

Die vier ersten Fälle entsprechen einer Reparatur-Situation, in der eine geringe Datenqualität verbessert werden soll. Die Lösung ist hier oft der mitgelieferte EncodingPatcher oder der EncodingPatcherWithRegexReplacement.

Postparser

Hinweis: Sie können natürlich einen Preparser und einen Postparser verwenden, auch wenn das in der Praxis kaum relevant sein wird.

Analog zum Preparser kann ein so genannter Postparser dem Parser nachgeschaltet werden. In dieser Klasse können Manipulationen an dem vom Parser erstellten Quellbaum vorgenommen werden. Die Klasse wird vom System aufgerufen, nachdem der Parser den Quellbaum erstellt hat. Mit Hilfe einer solche Klasse können beispielsweise noch Änderungen an bereits geparsten Daten, wie z. B. die Ersetzung von Umlauten vorgenommen werden.

Arbeiten mit rein binären Eingangsdaten

Wenn die Eingangsdatei nicht ausschließlich Zeichen mit einem definierten Character-Encoding enthält, sondern binäre, kodierte oder verschlüsselte Daten, kann sie nicht geparst werden. Es ist jedoch möglich, diese Eingangsdatei wie empfangen, also unverändert, im Antwortweg zu versenden oder zu speichern. Eine Verarbeitung bestimmter Einzelinformationen aus dieser Datei mithilfe des Profils ist dabei nicht in der gewohnten Weise möglich. Beispiele: PDF-Dateien, Bild-Dateien (JPG, TIFF, GIF, usw.), MS-Word-Dokumente.

Profile, können als Datenpumpe arbeiten, also Dateien in der Phase 1 von einer Quelle entgegennehmen oder abholen und dann in Phase 6 an ein Ziel senden. Mit der selektierten Checkbox Kein Mapping werden die Phasen 2 bis 5 übersprungen. In der Phase 6 kann die Eingangsdatei dann wie empfangen versendet werden. Weil Phase 2 übersprungen wird, wird der Parser nicht ausgeführt. Weil aber auch Phase 3 (Mapping) übersprungen wird, stehen in den Antwortwegen keine Profil-Variablen zur Verfügung, sondern nur die System-Variablen. Falls Sie die Phasen 2-5 benötigen, benutzen Sie Checkbox Daten-Routing.