Seitenhistorie
Hier soll nun etwas genauer auf das Zusammenspiel zwischen dem EOMS-Core und EOMS-Workern eingegangen werden. Wie bereits erwähnt fungiert das EOMS-Core als Steuerungszentrum, an dem sich auch die EOMS-Worker anmelden.
Abbildung A: Einfache Darstellung der Lastverteilung auf EOMS-Worker durch das EOMS-Core.
Das EOMS-Core verteilt also sämtliche eintreffende Jobs auf die bei ihm angemeldeten Worker. Dabei vergibt das EOMS-Core lediglich den Auftrag zur Jobausführung, der Datenaustausch findet ausschließlich zwischen Auftrags-System (z.B. Spooler) und dem zugewiesenen Worker statt (Vergleiche Aufbau des EOMS). Im Folgenden wird nun detailliert beschrieben, wie sich Worker am EOMS-Core registrieren und wie die Jobvergabe durch das EOMS-Core stattfindet.
1. Registrierung des Workers am Core
Nachdem ein Worker gestartet wurde (mit der jeweiligen .cmd), versucht dieser automatisch den Verbindungsaufbau zu dem in seiner eoms.invoker.client.properties-Datei angegebenen EOMS-Core. Dort wird die IP und der Port des Hostsystems angegeben Abb. B (1), die natürlich mit dem Port und der IP des EOMS-Core-Hostsystems übereinstimmen müssen Abb. B (2).
Abbildung B: Worker registriert sich beim EOMS-Core.
Bei erfolgreicher Registrierung ist der Worker als Worker des EOMS-Cores angemeldet und kann von diesem EOMS-Core Jobs empfangen.
Ausgabe des EOMS-Workers bei erfolgreicher Registrierung:
Der Worker wird dann auch im Worker-Monitor gelistet:
Hinweis |
---|
Schlägt die Registrierung des Workers am Core fehl, überprüfen Sie die Logfiles unter /logs. und beachten Sie die Hinweise zur Fehlerbehandlung. |
2. Empfang eines Jobs
Nach der Registrierung am EOMS-Core ist der Worker bereit, Jobs entgegenzunehmen.
Section |
---|
1. Das angebundene Auftrags-System meldet sich beim EOMS-Core und signalisiert einen neuen Job. Dabei übergibt das Auftrags-System seine Adressdaten an das EOMS-Core, damit später die Worker wissen, wo sie das Auftrags-System erreichen können (siehe 4.). Nach Empfang ist der Job als GEPLANT [SCHEDULED] für Worker freigegeben. Jobs werden chronologisch abgearbeitet, weshalb der Job allerdings erst vergeben wird, wenn keine aktuelleren Jobs mehr warten.
4. Hat der Worker die Jobdaten vom Auslieferungs-System erhalten, startet es die Ausführung des Prozesses aus seiner RCML-Spezifikation. Dazu vergleicht er den Eintrag in den Jobinformationen mit seiner List of Task, die in der worker.properties-Datei definiert ist. Der dort passende Eintrag wird in der worker.rcml-Datei aufgerufen und abgearbeitet (bei OMS-Workern). Näher auf RCML wird hier eingegangen. 5. Nach Abarbeitung des RCML-Prozesses schickt der Worker die fertigen Datenpakete zurück an das Auftrags-System. Die Übertragung erfolgt über die gleiche Schnittstelle wie bei der Übertragung von Auftrags-System zu Worker. Es erfolgt hier keine Statusmeldung an das Auftrags-System. Stattdessen meldet der Worker an das EOMS-Core, dass der Job terminiert ist. Das EOMS-Core setzt daraufhin den Status des Jobs von AKTIVIERT [ACTIVATED] auf BEENDET [TERMINATED]. Das Auftrags-System fragt in regelmäßigen Abständen die Status seiner Jobs ab und erfährt dadurch bei der nächsten Abfrage, dass bereits Resultate vorliegen und der Job abgefertigt ist. Das Auftrags-System gibt die Daten dann frei. Die Jobbearbeitung ist jetzt komplett abgeschlossen und der nächste Job kann verarbeitet werden. |
3. Abmeldung des Workers am Core
Um einen Worker herunterzufahren und ihn vom Core abzumelden genügt es, das Kommandofenster des Workers zu schließen. Das EOMS-Core registriert nach einer Latenzzeit beim nächsten Refresh selbstständig, dass der Worker nicht mehr aktiv ist. War dem Worker zur Zeit des Herunterfahren ein Job zugeteilt und der Worker konnte den Job nicht vollenden, so wird der Job vom EOMS-Core zurückgesetzt und erneut vergeben. Der Worker wird dann auch automatisch aus dem Worker-Monitor entfernt.