Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

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.





2. Der Job verbleibt solange GEPLANT [SCHEDULED], bis sich ein geeigneter Worker für den Job meldet. Dazu muss der Worker den angeforderten Prozess für diesen Job beherrschen (er muss in seiner List of Task eingetragen sein). In diesem Fall soll im Job der Prozess "RW" für ReportWriter ausgeführt werden. In der List of Task des Workers ist dieser Prozess explizit aufgeführt, der Worker beherrscht also diesen Prozess (in seiner RCML ist dann der genaue Ablauf festgelegt). Das EOMS-Core vergibt dann den Job an den Worker und stellt den Jobstatus auf AKTIVIERT [ACTIVATED]. Der Job ist dann so lange gesperrt, bis das EOMS-Core Meldung des arbeitenden Workers erhält (bzw. automatisch die Bearbeitung abbricht).








3. Der vom EOMS-Core an den Worker übergebenen Jobinformation entnimmt der Worker auch, von welchem Auftrags-System er sich die Jobdaten, auf die der Prozess angewandt werden soll, abholen kann. Dies kann über verschiedene Wege geschehen, direkt oder indirekt. Im Folgenden wird exemplarisch die direkte Anbindung beschrieben, die auch empfohlen wird. Dabei kontaktiert der Worker das in den Jobinformationen angegebene Auftrags-System und übergibt bei der Anfrage die Job-ID. Das Auftrags-System übergibt dann alle zugehörigen Daten zur Bearbeitung an den Worker, behält die Daten aber weiterhin, falls die Bearbeitung durch den Worker abgebrochen und erneut aufgenommen werden muss.








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.