Funktionsweise des Programms
xSuite Interface enthält eine Reihe von Komponenten, die eigenständig und weitgehend parallel laufen. Die Konfiguration erfolgt in Form von ein oder mehreren Verarbeitungsszenarien und bestimmt maßgeblich, welche dieser Komponenten tatsächlich ausgeführt wird und gegebenenfalls auch, in wie vielen Ausprägungen diese Ausführung stattfindet. Im Sinne einer Lastverteilung kann der parallele Betrieb von Programminstanzen, auch über Rechnergrenzen hinweg, durchaus sinnvoll sein. Diese Programminstanzen führen somit gemäß der spezifischen Konfiguration nur bestimmte Komponenten aus.
Die primäre Komponente, aus der das Programm besteht, ist ein sogenannter Worker. Das Programm arbeitet nach dem EVA-Prinzip (Eingabe, Verarbeitung, Ausgabe). Dementsprechend existieren 3 elementare Arten von Workern:
Input-Worker: Worker für den Arbeitsschritt "Input" (Eingabe)
Process-Worker: Worker für den Arbeitsschritt "Process" (Verarbeitung)
Output-Worker: Worker für den Arbeitsschritt "Output" (Ausgabe)
Ein konfiguriertes Verarbeitungsszenario, das das Einlesen von Daten aus einem System, die anschließende inhaltliche Aufbereitung dieser Daten und die Ausgabe der Daten an ein oder mehrere Systeme beschreibt, benötigt standardmäßig mindestens jeweils eine Worker-Instanz vom Typ "Input", "Process" und "Output". Abhängig von der Konfiguration können auch mehrere Worker-Instanzen desselben Typs parallel an dem selben Szenario arbeiten oder eine einzelne Worker-Instanz sequenziell mehrere Szenarien bedienen.
Im Standard prüft ein Worker in definierten Zeitabständen, ob neue Daten existieren, die zu verarbeiten sind. Bei einem Input-Worker erfolgt diese Prüfung über die entsprechende Schnittstelle gegen das angebundene Fremdsystem. Nach dem erfolgreichen Einlesen liegen die Daten in der internen Verwaltungsdatenbank vor. Die Worker der nachfolgenden Process- und Output-Schritte können direkt gegen diese Datenbank abfragen, ob Daten aus dem vorigen Arbeitsschritt zur Weiterverarbeitung verfügbar sind.
Eine Abweichung von diesem Standardverhalten stellen Eingabeschnittstellen und Ausgabeschnittstellen vom Typ (REST-) Webservice dar. Diese Schnittstellen prüfen nicht eigenständig auf neue Daten, sondern warten darauf, dass ein externer Prozess eine Anfrage zur Übergabe neuer Eingabedaten oder zur Abholung bereitstehender Ausgabedaten sendet. Für diese Schnittstellen werden daher Webservice-Instanzen des Typs "Input" oder "Output" aktiviert. Bei der Eingabe erfolgt das anstelle eines Input-Workers. Bei der Ausgabe erfolgt dies hingegen ergänzend zu einer Output-Worker-Instanz, die programmintern dennoch benötigt wird.
Neben den Worker-Typen "Input", "Process" und "Output" existieren implizit noch weitere Worker-Typen:
Worker | Beschreibung |
|---|---|
Backup-Worker | Der Backup-Worker korrespondiert mit einem Input-Worker oder Input-Webservice und ist für das finale Aufräumen und Sichern der Eingabedaten zuständig. |
BatchUpdate-Worker | Das Programm arbeitet mit stapelorientierten Eingabedaten. Dies sind Eingabestapel, die abhängig von der Schnittstelle auch mehrere Dokumente enthalten können. Während Input-Worker und Backup-Worker jeweils einen kompletten Stapel als Ganzes verarbeiten, arbeiten Process-Worker und Output-Worker mit einzelnen Dokumenten. Somit können mehrere Instanzen dieser Worker parallel an den Daten desselben Stapels arbeiten. Der BatchUpdate-Worker dient der zeitnahen Aktualisierung des Status des übergeordneten Stapels, da die dokumentorientierten Worker-Instanzen keine Gesamtsicht auf die parallel laufenden Instanzen und den übergeordneten Stapel haben. |
Hinweis
Die dokumentbasierte Arbeitsweise des Output-Workers stellt eine funktionale Einschränkung gegenüber der vorigen Programmgeneration dar.
Während in der vorigen Programmgeneration ein Eingabestapel als zusammengehörige Einheit bis zur Ausgabe weitergegeben werden konnte, können nun nur Ausgabedaten generiert werden, die jeweils ein einzelnes Dokument umfassen.
Dies betrifft jedoch nur wenige Ausgabeformate und Ausgabesysteme. Darüber hinaus arbeiten die meisten Zielsysteme auch nur mit Dokumenten, anstatt mit Stapeln.
Neben den bereits genannten Arten können noch weitere Worker-Instanzen und Webservices aktiviert werden, die unabhängig von spezifischen Verarbeitungsszenarien laufen:
Worker / Webservice | Beschreibung |
|---|---|
Schedule-Worker | Der Schedule-Worker führt zeitgesteuert globale Funktionen aus, um z. B. allgemeine Aufräumarbeiten durchzuführen. |
Status-Webservice Config-Webservice | Der Status-Webservice und der Config-Webservice sind Back-End-Dienste für integrierte UI-Anwendungen. Diese Dienste dienen dem Monitoring des Verarbeitungsstatus und der Unterstützung bei der Konfiguration. |
xSuite Helix Proxy | Der xSuite Helix Proxy ist ein spezieller HTTP-Proxy-Server, der HTTP-Anfragen aus Fremdanwendungen an die xSuite Helix Cloud weiterleitet. Da diese Anwendungen in der Regel nicht von sich aus das verwendete Keycloak-Authentifizierungsverfahren unterstützen, liegt die wesentliche Aufgabe des Proxys darin, das benötigte Token vom Keycloak-Server abzurufen und in den HTTP-Kopfdaten der Anfragen zu ergänzen. |
Das folgende Diagramm bietet einen grafischen Überblick über die Programmarchitektur. Detaillierte Erläuterungen zu den hier dargestellten Elementen finden Sie unter Verarbeitungsschritte.
 |