Konfiguration Verbindung _pro und _data über MessageService
Beim MessageService handelt es sich um ein nachrichtenbasiertes Datenübertragungssystem, bei dem Erzeuger von Nachrichten (Producer) diese über sogenannte ConsumerQueues zu eventuell vorhandenen Abonnenten (Subscriber) transportieren lassen, wo sie weiterverarbeitet werden können. ConsumerQueues werden über den MessageContext und der MessageQueue eindeutig definiert.
ConsumerQueues können entweder über die Admin-Konsole (dabei erfolgt keine Speicherung der Konfiguration) oder in der Konfigurationsdatei message.xml konfiguriert werden.
Eine ConsumerQueue kann über folgenden Eintrag in message.xml hinzugefügt werden:
<Call name ="addConsumerQueue"> <Arg> <New class ="com.ebd.hub.services.message.ConsumerQueue"> <Arg>Context</Arg > <Arg>Queue</Arg > </New> </Arg></Call>Context entspricht hierbei dem MessageContext, Queue der MessageQueue.
Darüber hinaus können auch Wege über mehrere IntegrationServer hinweg beschritten werden, indem man sogenannte Routes definiert.
Dabei ist folgendes zu beachten:
Zunächst muss die empfangende _data Instanz das RemoteInterface aktivieren. Das heißt, dass konfiguriert werden muss, auf welchen Port die _data Instanz Nachrichten anderer _data Instanzen empfangen soll.
Dazu muss folgender Eintrag in der Datei message.xml stehen:
<Call name ="enableRemoteInterface"> <Arg>IP - address</Arg> <Arg type ="int">Port</Arg></Call>IP - address ist hierbei die IP-Adresse des Interfaces, auf die der Empfang eingeschränkt sein soll, oder 0.0.0.0, wenn keine solche Einschränkung existieren soll. Port ist der zu verwendende Port, auf dem diese _data-Instanz Nachrichten empfangen soll.
Sowohl auf der empfangenden Seite, als auch auf der sendenden Seite müssen die ConsumerQueues mit gleichem Kontext und gleicher Queue definiert sein.
Auf der sendenen Seite muss nun eine Route definiert sein, die angibt, dass für eine bestimmte Queue mit einem bestimmten Kontext die Nachricht nicht lokal verabeitet, sondern an eine andere _data-Instanz weitergeleitet werden soll.
Für Routen können folgender Einträge in die message.xml vorgenommen werden.
<Call name ="addRoute"> <Arg>Context</Arg> <Arg>Queue</Arg> <Arg> <New class ="com.ebd.hub.services.message.Target"> <Arg>hostname</Arg> <Arg type ="int">port</Arg> </New> </Arg></Call>Dabei haben die einzelnen Parameter die folgende Bedeutung:
|
Wert |
Bedeutung |
|
context |
Der Name des MessageContext. |
|
queue |
Der Name der MessageQueue. |
|
hostname |
Der Hostname des entfernten Remoteinterfaces. |
|
port |
Der Port des entfernten Remoteinterfaces. |
Beispielszenario:
Eine Lobster Data Platform / Orchestration-Instanz (IP: 192.168.0.5) soll Daten mit einer _data Instanz (IP:192.168.0.3) austauschen.
Wir empfehlen zur besseren Unterscheidung von Test und Produktivsystemen in den Namen von Kontexten und Queues den Prefix _PROD und _TEST mit aufzunehmen.
In diesem Beispiel wird der Prefix _TEST verwendet.
Auszug aus der Konfigurationsdatei message.xml der Lobster Data Platform / Orchestration-Instanz:
... <Call name="enableRemoteInterface"><Arg>0.0.0.0</Arg><Arg type="int">8020</Arg></Call> <Call name="addRoute"> <Arg>SCM_TEST</Arg> <Arg>SCM2DATA_TEST</Arg> <Arg> <New class="com.ebd.hub.services.message.Target"> <Arg>192.168.0.3</Arg> <Arg type="int">8020</Arg> </New> </Arg> </Call> <Call name="addConsumerQueue"> <Arg> <New class="com.ebd.hub.services.message.ConsumerQueue"> <Arg>SCM_TEST</Arg> <Arg>SCM2DATA_TEST</Arg> </New> </Arg> </Call> <Call name="addConsumerQueue"> <Arg> <New class="com.ebd.hub.services.message.ConsumerQueue"> <Arg>SCM_TEST</Arg> <Arg>DATA2SCM_TEST</Arg> </New> </Arg> </Call>...Zunächst ermöglicht der Eintrag enableRemoteInferface den Empfang von Nachrichten anderer _data Instanzen.
Mit addRoute wird angegeben, dass für die ConsumerQueue mit Kontext: SCM_TEST und Queue: SCM2DATA_TEST die Nachrichten an den Server mit der IP:192.168.0.3 gesendet werden sollen.
Anschließend werden die beiden ConsumerQueues zum Senden und Empfangen von Nachrichten definiert.
Für Profile, die Daten von Lobster Data Platform / Orchestration an den entfernten _data schicken sollen, muss ein Ausgangsweg Message konfiguriert sein.
Beispiel Nachrichten Senden von Lobster Data Platform / Orchestration zu _data:
Kontext Name und Queue Name (1) müssen dem Eintrag in der message.xml entsprechen (hier SCM_TEST:SCM2Data_TEST), da für diese Werte eine Route definiert ist.
(3) gibt an, ob die Nachrichten Synchron, Asychron oder Persistent gesendet werden.
( Bei synchroner Message wartet das Profil so lange, bis das Zielprol seine Verarbeitung erfolgreich oder mit Fehler beendet hat. Wird dabei die hier eingestellte Zeitüberschritten, bricht dieser Antwortweg mit Fehler ab, obwohl vielleicht das Zielprol später erfolgreich endet
Bei asynchroner bzw. persistenter Message wartet das Profil nicht auf das Zielprofil sondern nach Übergabe der Daten endet der Antwortweg erfolgreich. Die Message selbst hat hier aber eine endliche Lebenszeit. Konnte sie nach dieser Zeit nicht vom Zielprofil angenommen werden, wird sie gelöscht.
Die hier eingestellte Zeit ist die maximale Lebenszeit der Message. Wenn Wert 0 eingestellt ist gilt der Default von 6 Stunden.)
Der Profil-Name gibt an, welches Profil auf der entfernten Seite angestoßen werden soll. (hier heißt das Profil z.B. FROM_SCM) Dieses Profil muss auf der entfernten Seite mit diesem Namen vorhanden sein und als Eingangsagent Message gesetzt haben.
Die Konfigurationsdatei auf der _data-Seite müsste für dieses Szenario folgende Einträge enthalten:
... <Call name="enableRemoteInterface"><Arg>0.0.0.0</Arg><Arg type="int">8020</Arg></Call> <Call name="addRoute"> <Arg>SCM_TEST</Arg> <Arg>DATA2SCM_TEST</Arg> <Arg> <New class="com.ebd.hub.services.message.Target"> <Arg>192.168.0.5</Arg> <Arg type="int">8020</Arg> </New> </Arg> </Call> <Call name="addConsumerQueue"> <Arg> <New class="com.ebd.hub.services.message.ConsumerQueue"> <Arg>SCM_TEST</Arg> <Arg>SCM2DATA_TEST</Arg> </New> </Arg> </Call> <Call name="addConsumerQueue"> <Arg> <New class="com.ebd.hub.services.message.ConsumerQueue"> <Arg>SCM_TEST</Arg> <Arg>DATA2SCM_TEST</Arg> </New> </Arg> </Call>...Zunächst ermöglicht der Eintrag enableRemoteInferface den Empfang von Nachrichten anderer _data Instanzen.
Mit addRoute wird angegeben, dass für die ConsumerQueue mit Kontext: SCM_TEST und Queue: DATA2SCM_TEST die Nachrichten an den Server mit der IP:192.168.0.5 gesendet werden sollen.
Anschließend werden die beiden ConsumerQueues zum Senden und Empfangen von Nachrichten definiert.
Profile, die vom _data Nachrichten an Lobster Data Platform / Orchestration schicken möchten, müssen einen Ausgangsweg Message definieren:
Das Profil auf der scm Seite (hier FROM_DATA) muss auf der Lobster Data Platform / Orchestration-Seite vorhanden sein und als Eingangsagent Message gesetzt haben:
Erweiterte Konfiguration für Datenrückmeldung vom Lobster_data nach Lobster Data Platform / Orchestration
Im Normalfall liefern Ausgangswege, die auf einem entfernten _data über Routen Profile aufrufen, keine Daten zurück.
Profilaufrufe über die Ereignisaktion "Profil aufrufen" oder über ein Portal erwarten jedoch, dass vom Profil Daten zurückgeliefert werden sollen.
Dazu wird bei einem Profilaufruf auf dem lokalen Lobster Data Platform / Orchestration-System im Ausgangsweg entweder die eigene Klasse de.lobster.scm.dw.util.CronPassBackDataResponse (siehe auch: CronPassBackDataResponse (_data-Responder) ) oder die eigene Klasse de.lobster.scm.dw.util.CronPassBackDataResponseUTF8 (siehe auch CronPassBackDataResponseUTF8 ) verwendet.
Um nun vom entfernten _data Daten an das Lobster Data Platform / Orchestration-System zurückzuliefern, muss folgendes konfiguriert werden:
1.) Die Datei Lobster_data.api.ext.jar muss auf dem entfernteren _data beim Start des _data im Verzeichnis ./extlib vorhanden sein. (bitte wenden Sie sich an den Lobster Data Platform / Orchestration-Support mit der Mail-Adresse support.pro@lobster.de, um diese Datei zu erhalten)
Diese Bibliothek enthält Klassen, die dann auf dem _data verwendet werden können.
2.) Auf dem entfernten _data muss eine ConsumeQueue definiert werden, die einen Consumer mit der Klasse de.lobster.scm.dw.util.ExtendedCallProfileSubscriber enthält:
Eintrag in message.xml _data:
... <Call name="addConsumerQueue"> <Arg> <New class="com.ebd.hub.services.message.ConsumerQueue"> <Arg>SCM_TEST</Arg> <Arg>CALL_PROFILE</Arg> <Call name="addConsumer"> <Arg>de.lobster.scm.dw.util.ExtendedCallProfileSubscriber</Arg> <Arg>consume</Arg> </Call> </New> </Arg> </Call>...3.) Auf dem Lobster Data Platform / Orchestration-System muss eine ConsumeQueue und eine Route definiert werden:
Eintrag in message.xml von Lobster Data Platform / Orchestration:
... <Call name="addConsumerQueue"> <Arg> <New class="com.ebd.hub.services.message.ConsumerQueue"> <Arg>SCM_TEST</Arg> <Arg>CALL_PROFILE</Arg> </New> </Arg> </Call> <Call name="addRoute"> <Arg>SCM_TEST</Arg> <Arg>CALL_PROFILE</Arg> <Arg> <New class="com.ebd.hub.services.message.Target"> <Arg>192.168.0.3</Arg> <Arg type="int">8020</Arg> </New> </Arg> </Call>...Die ConsumeQueue wird benötigt, um Nachrichten mit dem angegeben Kontext und Queue verarbeiten zu können.
Die Route gibt an, an welchen _data die Nachricht gesendet werden soll.
In dieser Konfiguration wird die IP-Adresse des entfernten _data aus dem Beispiel verwendet. Natürlich ist diese entsprechend anzupassen.
4.) Im Ausgangsweg des lokalen Lobster Data Platform / Orchestration-Profils kann nun die eigene Klasse de.lobster.scm.dw.util.CallProfileAndPassBackDataResponse (siehe auch CallProfileAndPassBackDataResponse (_data-Responder)) verwendet werden.
Über die zusätzlichen Parameter werden die ConsumerQueue und der Profilname angegeben.
Hier Kontext:SCM_TEST, Queue:CALL_PROFILE und das entfernte Profil DATA_AN_SCM, das auf dem entfernten _data auch genau so heißen muss.
5.) Das Profile auf dem entfernten _data (hier DATA_AN_SCM) darf als Eingangsagent nicht Message gesetzt haben, damit das Profil vom Consumer de.lobster.scm.dw.util.ExtendedCallProfileSubscriber gerufen wird und nicht vom Consumer des Standard-Message-Service.
Es ist dadurch auch möglich, Cron-Profile aufzurufen, die z.B. Datenbankabfragen ausführen um Daten zurückzuliefern. Das Profil auf dem entfernten _data muss auch XML-Daten zurückliefern.
Da die XML-Strukturen von Lobster Data Platform / Orchestration im entfernten _data nicht über eigene Vorlagen zur Verfügung stehen, ist es sinnvoll die Ausgangsstruktur im Lobster Data Platform / Orchestration-System zu erstellen und dann über Export vom Lobster Data Platform / Orchestration-System und Import des Profils auf dem entfernten _data zu übertragen.
6.) Nun können im Ausgangsweg des Profils auf dem entfernten _data (hier DATA_AN_SCM) die eigenen Klassen CronPassBackDataResponse und CronPassBackDataResponseUTF8 analog zu einem lokalen Profilaufruf verwendet werden.
Um eigene Klassen auf dem entfernten data zu registieren und in der Auswahlbox anzeigen zu lassen, kann die Datei .\etc\admin\datawizard\customresponse.properties um die Einträge:
de.lobster.scm.dw.util.CronPassBackDataResponse
de.lobster.scm.dw.util.CronPassBackDataResponseUTF8
erweitert werden.