Seitenhistorie

...

Ein EOMS besteht aus 2 Haupteinheiten: Dem EOMS-Core sowie den EOMS-Workern. Das Zusammenspiel zwischen dem EOMS-Core und den EOMS-Worker wird später in dem Kapitel Core - Worker detailliert behandelt. Die Anbindung an externe Systeme (z.B. Spooler) erfolgt über das EOMS-Core. Beachten Sie, dass das EOMS nur einwandfrei arbeiten kann, wenn sowohl die Anbindung an externe Systeme, wie auch das EOMS selbst ordnungsgemäß konfiguriert sind. Wie das EOMS richtig konfiguriert wird entnehmen Sie u.a. dem Abschnitt über die Konfigurationen für Core und Worker.

Abbildung A: Vereinfachter Aufbau des EOMS mit Anbindung an den Spooler.

EOMS-Core

Das EOMS-Core stellt das Herzstück des EOMS dar. Es dient zum Monitoring der Worker und empfängt Jobs von Auftrags-Systemen (da das EOMS vor allem auf die Zusammenarbeit mit dem Spooler konzipiert ist, wird in dieser Dokumentation exemplarisch die Kopplung mit dem Spooler beschrieben), die es an die EOMS-Worker weitergibt. Zwischen dem EOMS-Core und dem Spooler findet kein Austausch der zu verarbeitenden Daten statt, sondern das EOMS-Core nimmt lediglich die Beschreibung der zu verarbeitenden Jobs vom Spooler entgegen. Die Kommunikation zwischen dem EOMS-Core und dem Spooler läuft standardmäßig direkt zwischen Spooler und EOMS ( seit Version 1.2, Abb. A (2) ). Das EOMS unterstützt aber auch weiterhin die indirekte Kommunikation über den Messaging-Server Apache ActiveMQ (JMS-Provider), es wird aber die direkte Kommunikation empfohlen. Wie Sie den Kommunikationsweg konfigurieren können, entnehmen Sie dem Artikel über die Anbindung des Spoolers. Beachten Sie jedoch, dass in zukünftigen Versionen die indirekte Kommunikation über ActiveMQ eventuell nicht mehr unterstützt wird.

Die Interaktion mit dem EOMS-Core verläuft über die grafische Benutzeroberfläche. Rufen Sie dazu im Browser den Link zum Tomcat-Server auf: <protocol>://<ip>:<port>/omsinvoker. Standard: http://localhost:8080/omsinvoker

EOMS-Worker

Die EOMS-Worker führen vom EOMS-Core empfangene Jobs aus Abb. A (4). Jeder Worker besitzt eine List of Task der von ihm verarbeitbaren Jobs. Worker können nur Jobs ausführen, die in ihrer List of Task definiert sind. Ist ein Worker also zur Verarbeitung der Tasks "ReportWriter" und "copy" befähigt, so werden vom EOMS-Core nur Jobs an den Worker weitergegeben, bei denen diese Prozesse ausgeführt werden sollen (die List of Task ist nicht bindend, d.h. es kann auch passieren, dass Worker einen Job erhalten, den Sie nicht verarbeiten können. In diesem Fall verweigern sie die Bearbeitung und das EOMS-Core vergibt den Job automatisch neu). Die Anbindung der Worker an das EOMS-Core erfolgt über eine lose Kopplung der Worker an das EOMS-Core. Es besteht also keine direkte bidirektionale Verbindung zwischen EOMS-Core und EOMS-Workern. Stattdessen erfragen EOMS-Worker in fest definierten Zeitintervallen (Standard: 1s) vom EOMS-Core, ob offene Jobs vorliegen, die mit seiner List of Task übereinstimmen. In diesem Fall vergibt das EOMS-Core den offenen Job (inklusive Job-ID) an den Worker. Standardmäßig kann ein Worker nicht mehr als 1 Job gleichzeitig bearbeiten (gilt für OMS-Worker). Worker können aber auch so konfiguriert werden, dass sie mehrere Jobs parallel bearbeiten (für den Einsatz auf Multicore-Maschinen, siehe dazu "Konsumenten" in Konfiguration von Workern). Nachdem der Worker den Jobauftrag vom EOMS-Core enthalten hat, nimmt dieser direkten Kontakt zur Spooler (oder anderen Systemen) per HTTP auf und erfragt und empfängt mit Hilfe der Job-ID die zugehörigen Daten (z.B. Rohdokumente) über die Input-Schnittstelle des Spoolers. Auf diesen Daten werden dann vom Worker die angeforderten Prozesse ausgeführt (z.B. ReportWriter). Die genaue Abfolge der Prozesse, die von einem Worker ausgeführt werden, lassen sich mit RCML beschreiben. Diese sehr mächtige XML-basierte Beschreibungssprache erlaubt auch die Einbindung von Skriptsprachen wie JavaScript und ermöglicht somit nahezu unbegrenzte Prozessdefinitionen. Lesen Sie dazu den Abschnitt über RCML Kompendium. Nach erfolgreicher Beendigung des Jobs sendet der Worker das Resultat zurück an den Spooler (nur OMS-Worker, siehe Typen von Workern).

Worker können auch über Fileshare mit dem Spooler interagieren. Diese Methode ist allerdings obsolet; es wird die Kommunikation über HTTP empfohlen.

Typen von Workern

Es existieren 2 verschiedene Arten von EOMS-Workern:
 

Der OMS-Worker bildet den Standardtyp des EOMS und dient zur Lastverteilung von Jobprozessen aus dem Spooler, während EOMS-Input-Worker zur Kommunikation mit dem EOMS-Input-Server von DOCXDOC konzipiert sind. Der AKI-Worker wird in der Version 1.3 des EOMS nicht mehr unterstützt. AKI-Worker werden nur bis Version 1.2.4 unterstützt. Mehr zu AKI-Workern finden Sie in der Dokumentation für das EOMS 1.2.

Die einzelnen Workertypen werden detailliert in der Worker-Dokumentation beschrieben. In dieser Einführung wird der OMS-Worker beschrieben, da dieser den typischen Einsatzzweck des EOMS implementiert. Zwar dienen die einzelnen Workertypen unterschiedlichen Einsatzzwecken, konzeptuell unterscheiden sich die verschiedenen Worker allerdings nur gering. Die Spezialisierung eines Workers geschieht ausschließlich über seine RCML. 

Ablauf eines Jobs

Im Folgenden soll nun der typische Ablauf eines Jobs vom Eingang des Jobs im EOMS bis zu seiner Terminierung detailliert beschrieben werden (spezifisch für OMS-Worker). 

Abbildung B: Abarbeitung eines Jobs aus dem Spooler durch das EOMS.

...

Die Bearbeitung eines Jobs durch das EOMS verläuft chronologisch in folgenden Schritten (bei Kommunikation von EOMS und Spooler über HTTP, siehe dazu auch Core - Worker):
 

...

...