Phase 1
Eingangsagenten
In Phase 1 werden die Eingangsdaten von sogenannten Eingangsagenten empfangen. Kommen mehrere Eingangsagenten in Betracht, entscheidet das Profil-Scoring.
Backup und Unresolved
Wenn die Daten einem Profil zugeordnet werden konnten, wird ein Backup der Eingangsdateien und ein Job für dieses Profil erzeugt. Ansonsten landen die Dateien im Bereich Unresolved.
Virenscanner
Es ist möglich, an dieser Stelle eine Virenscanner-Java-Klasse auszuführen. Die Klasse wird immer gerufen, wenn eine Backup-Datei erzeugt wird oder eine Datei im Bereich Unresolved landet.
Es muss dazu eine von com.ebd.hub.datawizard.plugin.AbstractVirusCheck abgeleitete Klasse erstellt werden. Diese muss lediglich die zwei folgenden Methoden implementieren.
/*** Check file for virus** @param backup backup file* @throws Exception on any error*/public abstract void checkFile(File backup) throws Exception;/*** Check data for virus** @param data received data, most likely by AS2 (already encrypted)* @throws Exception on any error*/public abstract void checkData(byte[] data) throws Exception;In diesen beiden Methoden muss der Virenscanner mit den Daten aufgerufen werden und eine Exception auslösen, wenn die Daten verseucht sind. Eingebunden wird die Klasse in der Konfigurationsdatei ./etc/startup.xml (bzw. ./etc/startup_dmz.xml auf dem DMZ-Server) mit folgendem Eintrag.
<Set name="virusScanner">your_class_name_including_package</Set>Wichtiger Hinweis: Wir bieten eine Programmierschnittstelle (API), die es Ihnen erlaubt eigene Klassen in Java zu entwickeln. Dazu gibt es eine vertiefte Schulung. Bei Interesse wenden Sie sich bitte an unsere Mitarbeiter im Support bzw. im Vertrieb.
Thread Queues
Es kann unterschieden werden zwischen Eingangsagenten, die Jobs direkt abarbeiten und solchen, die diese in eine Thread Queue einstellen. Die abweichende Arbeitsweise wurde gewählt, um die Ausführung bei der ersten Gruppe zu den festgelegten Zeitpunkten sicherzustellen.
Jobs, die direkt verarbeitet werden
Jobs aller zeitgesteuerter Eingangsagenten. Hinweis: Die Option Parallelverarbeitung aktivieren erlaubt im zeitgesteuerten Eingangsagenten des Typs "HTTP" aber auch die Verarbeitung über eine Thread Queue.
Jobs des eventgesteuerten Eingangsagenten des Typs HTTP. Hinweis: Die Option Parallelverarbeitung aktivieren erlaubt hier aber auch die Verarbeitung über eine Thread Queue.
Jobs der zeitgesteuerten Eingangsagenten werden pro Profil sequentiell, Jobs der Eingangsagenten HTTP(S), Message und AS2 können pro Profil parallel abgearbeitet werden.
Jobs, die in einer Thread Queue abgelegt werden
Jobs aller anderer Eingangsagenten.
Die Einträge der Thread Queues werden von den ursprünglich empfangenden Profilen abgearbeitet. Die maximale Anzahl von verschiedenen Profilen, die gleichzeitig arbeiten, kann eingestellt werden. Das folgende Listing zeigt wie in der Konfigurationsdatei ./etc/startup.xml mit der Minimal- und Maximalwert eingestellt werden kann.
...<Set name="minBackgroundThreads">4</Set><Set name="maxBackgroundThreads">10</Set>...Arbeitsweise von Thread Queues
Im Regelfall werden Jobs zeitnah abgearbeitet, das heißt die Anzahl von Einträgen in den Thread Queues wird sehr klein sein (normalerweise sogar leer). Können die Einträge nicht schnell genug abgearbeitet werden, steigt die Anzahl der Einträge. Übersteigt die Anzahl einen Grenzwert, wird damit begonnen, die überzähligen Jobs auf die Festplatte auszulagern. Diese Jobs werden wieder eingelesen, sobald ein zweiter Grenzwert unterschritten wird. Wird das System heruntergefahren und es befinden sich noch Jobs in den Thread Queues, werden diese Jobs auf die Festplatte geschrieben. Nach einem Neustart werden diese Jobs dann wieder in die Thread Queues gestellt.
Erzeugt ein Profil einen Job, wird zunächst eine Jobnummer vergeben. Die Jobnummer ist eine aufsteigende, über alle Profile eindeutige Nummer. Anschließend werden die erhaltenen Daten zunächst in das Sicherungsverzeichnis ./datawizard/backup kopiert. Darunter gibt es eine Reihe kryptisch aussehender Verzeichnisnamen mit der Endung 7ff8. Jedem Profil ist ein Verzeichnis zugeordnet. In diesem Verzeichnis befinden sich die Dateien mit den Namen Job_<Jobnummer>, mit denen die Dateien verarbeitet wurden. Schlägt eine Verarbeitung fehl oder soll eine Verarbeitung erneut durchgeführt werden, kann der Benutzer aus diesen Sicherungsverzeichnissen die Daten in einem Neudurchlauf manuell erneut einlesen. Für jeden Job wird zusätzlich eine Datei mit dem Namen ENV_<Jobnummer> erzeugt, in der die Environmentvariablen gespeichert werden, die für einen Neudurchlauf benötigt werden. Hinweis: Siehe auch die Funktionen read env-file(a, b) und get path of backup-file(a,b,c) und die System-Variable VAR_SYS_BACKUP.
Beim Queueing passiert folgendes.
Im Verzeichnis ./datawizard/backup/queue/<node name> wird eine Datei erstellt. <node name> steht für MainIS bzw. den Namen des jeweiligen Nodes. Siehe Abschnitt Load Balancing.
Alle Thread Queues schreiben in das gleiche Verzeichnis, es wird nicht nach Priorität unterschieden. Jeder Thread-Queue-Eintrag entspricht also einer Datei.
Im Thread-Queue-Eintrag steht der Name des zugehörigen Profils sowie einen Verweis auf die zu verarbeitenden Daten. Die Daten selbst sind nicht enthalten.
Die Daten zum Thread-Queue-Eintrag befinden sich in ./datawizard/backup/queue/payload.
Handelt es sich bei einem Thread-Queue-Eintrag um einen manuellen Neustart eines gebackupten Jobs, wird auf den existierenden Payload unterhalb des Profilbackups verwiesen.
Zu Prioritätsänderungen im Profil siehe Abschnitt Thread Queue.
Manuell neugestartete Jobs haben nicht die Priorität des Profils, sondern die Priorität Hoch (+2).
Wenn ein Profil gelöscht wird, laufen die zugehörigen Thread-Queue-Einträge auf einen Fehler und werden dadurch gelöscht.
Standard-Ablauf der Phase 1
Der Standard-Ablauf der Phase 1 ist das Empfangen von Daten und das Erzeugen eines Jobs für das verarbeitende Profil.
File-Funktion in Phase 1
Optionale File-Funktionen ermöglichen bei der Verwendung von zeitgesteuerten Eingangsagenten, für eine eingehende Datei bestimmte Bedingungen zu definieren. Nur wenn diese Bedingungen erfüllt sind, wird ein Job für das Profil erzeugt und die Datei verarbeitet. Beispiele können Sie der Dokumentation der jeweiligen File-Funktions-Klassen entnehmen.
Nächste Jobnummer
Die nächste verfügbare Jobnummer kann mit zwei Methoden verwaltet werden. Verwenden des internen Speicherdienstes oder Ausführen einer Stored Procedure.
Interner Speicherdienst
Das ist die Standardoption. Hier müssen Sie nichts weiter tun.
Wenn Sie allerdings die Anzahl der Speicherdienst-Zugriffe verringern wollen, können Sie auf Batching umstellen (nicht möglich auf Load-Balancing-Systemen). Setzen Sie dazu folgende System-Properties.
|
hub.datawizard.doJobNrBatching=true |
In diesem Beispiel werden jeweils 100 Jobnummern geholt (werden im Speicher verwaltet). Sind diese Jobnummern verbraucht, werden weitere 100 geholt.
Stored Procedure
Wichtiger Hinweis: Wenn der Aufruf der Stored Procedure keine Jobnummer zurück liefert (z. B. weil die Datenbank hub nicht erreichbar ist), dann wird Lobster Integration beendet.
Eine Beispiel-Prozedur für verschiedene Datenbanken finden Sie in Datei ./conf/samples/db_sequence.sql. Speichern Sie die letzte Jobnummer in der verwendeten Tabelle der Prozedur, um doppelte Auftragsnummern zu vermeiden. Falls Sie die Beispiel-Prozedur verwenden, fügen Sie die folgende Option in der Konfigurationsdatei ./etc/startup.xml hinzu.
Allgemein:<Set name="sequenceProcedureCall">execute command</Set> (siehe jeweils in der Beispiel-Datei)Die Prozedur muss in der Datenbank (Schema) erstellt werden, die Lobster Integration für das (normale) Logging verwendet.
Wichtiger Hinweis: Wenn Sie eine MySQL-Datenbank verwenden, dann sollten Sie stattdessen folgende Sequenz benutzen, da dort Stored Procedures nicht thread-sicher sind.
create sequence getNextJobNr start with <start_value> increment by 1;Verwenden Sie für den Startwert <start_value> die aktuell höchste Jobnummer (evtl. auch etwas höher).
Fügen Sie dann die folgende Option in der Konfigurationsdatei ./etc/startup.xml hinzu.
<Set name="sequenceProcedureCall">SELECT NEXT VALUE FOR getNextJobNr</Set>Redis
Alternativ kann eine interne Redis-Datenbank verwendet werden. Fügen Sie dazu die folgende Option in der Konfigurationsdatei ./etc/startup.xml hinzu.
Man kann die letzte Jobnummer in die Redis-Datenbank übertragen, indem man vor dem Start des Integration Servers in die Konfigurationsdatei ./etc/jobnr.redis die aktuelle Jobnummer als einzige Zeile einträgt.
<Set name="sequenceProcedureCall">redis</Set>