Configuration connection _scm and _data via MessageService
The MessageService is a message-based data transmission system in which producers of messages have them transported via so-called ConsumerQueues to any subscribers where they can be further processed. ConsumerQueues are uniquely defined by the MessageContext and the MessageQueue.
ConsumerQueues can be configured either via the admin console (the configuration is not saved) or in the configuration file message.xml.
A ConsumerQueue can be added using the following entry in message.xml:
<Call name ="addConsumerQueue"> <Arg> <New class ="com.ebd.hub.services.message.ConsumerQueue"> <Arg>Context</Arg > <Arg>Queue</Arg > </New> </Arg></Call>Context corresponds here to the MessageContext, queue to the MessageQueue. In addition, paths can also be taken across several IntegrationServers by defining so-called routes.
►NOTE◄ First the receiving _data instance must activate the remote interface. This means that it has to be configured on the port on which the _data instance should receive messages from other _data instances.
The following entry must be in the message.xml file:
<Call name ="enableRemoteInterface"> <Arg>IP - address</Arg> <Arg type ="int">Port</Arg></Call>IP – address is the IP address of the interface to which the reception should be restricted, or 0.0.0.0, if no such restriction should exist. Port is the port to be used where this _data instance should receive messages.
ConsumerQueues must be defined with the same context and queue on both the receiving and the sending side.
On the sending side, a route must now be defined which specifies that for a specific queue with a specific context, the message should not be processed locally, but forwarded to another _data instance.
For routes, the following entries can be made in the message.xml.
<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>The individual parameters have the following meaning:
|
Value |
Meaning |
|
context |
The name of the MessageContext. |
|
queue |
The name of the MessageQueue. |
|
hostname |
The hostname of the remote Remoteinterfaces. |
|
port |
The remote Remoteinterfaces port. |
Example scenario:
A _scm instance (IP: 192.168.0.5) will exchange data with a _data instance (IP:192.168.0.3). We recommend that the prefix _PROD and _TEST is included in the names of contexts and queues to distinguish between test and production systems. In this example, the prefix _TEST is used.
Extract from the configuration file message.xml of the _scm instance:
... <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>...Firstly, the enableRemoteInferface entry enables the receipt of messages from other _data instances.
With addRoute, it is specified that the messages for the consumer queue with the Context name: SCM_TEST and Queue name: SCM2DATA_TEST should be sent to the server with the IP:192.168.0.3. Then the two ConsumerQueues for sending and receiving messages are defined. For profiles that should send data from _scm to the remote _data, an outgoing message path must be configured.
Example of sending messages from _scm to _data:
Context name and Queue name (1) must correspond to the entry in the message.xml (here SCM_TEST:SCM2Data_TEST), because a route is defined for these values. The Message type (3) indicates whether the messages are sent synchronously, asynchronously or persistently. In the case of a synchronous message, the profile waits until the target profile has finished processing successfully or with errors. If the timeout set here is exceeded, the response path terminates with an error, even though the target control may end successfully later. With asynchronous or persistent messages, the profile does not wait for the target profile. Instead, the response path ends successfully once the data has been transferred. But the message itself has a limited lifetime here. If it is not accepted by the target profile after this time, it is deleted. The time set here is the maximum lifetime of the message. If value 0 is set, the default of 6 hours applies.
The Profile name specifies which profile is to be started on the remote site, (e.g. here FROM_SCM). This profile must exist on the remote side with this name and must have message set as the incoming agent.
For this scenario, the configuration file on the _data side should contain the following entries:
... <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>...First, the entry enableRemoteInferface enables the receipt of messages from other _data instances.
With addRoute, it is specified that the messages for ConsumerQueue with Context name: SCM_TEST and Queue name: DATA2SCM_TEST should be sent to the server with the IP:192.168.0.5. Then the ConsumerQueues for sending and receiving messages are defined.
Profiles that want to send messages from _data to _scm must define an outgoing message agent:
The profile on the scm side (here FROM_DATA) must exist on the _scm side and have message set as the incoming agent:
Advanced configuration for data feedback from _data to _scm
Normally, outgoing routes that call profiles on a remote _data via routes do not return any data. However, profile calls via the event action 'Call profile' or via a portal require data to be returned from the profile.
When calling a profile on the local _scm system, either the custom class de.lobster.scm.dw.util.CronPassBackDataResponse (see also: SCM:de.lobster.scm.dw.util.CronPassBackDataResponse) or the custom class de.lobster.scm.dw.util.CronPassBackDataResponseUTF8 (see also CronPassBackDataResponseUTF8) is used in the outgoing path.
To return data from the remote _data to the _scm system, the following must be configured:
1.) The file Lobster_data.api.ext.jar must be present on the remote _data when the _data is started in the directory ./extlib. (please contact _scm support with the mail address support.pro@lobster.de to get this file). This library contains classes that can then be used in _data.
2.) A ConsumeQueue must be defined on the remote _data, which contains a consumer with the class de.lobster.scm.dw.util.ExtendedCallProfileSubscriber:
Entry 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.) A ConsumeQueue and a route must be defined on the _scm system:
Entry in message.xml _scm:
... <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>...The ConsumeQueue is required to process messages with the specified context and queue. The route specifies to which _data the message should be sent. In this configuration the IP address of the remote _data from the example is used. Of course this has to be adjusted accordingly.
4.) In the outgoing path of the local _scm-profile, the custom class de.lobster.scm.dw.util.CallProfileAndPassBackDataResponse (see also CallProfileAndPassBackDataResponse (_data-Responder)) can now be used.
The Additional parameters are used to specify the ConsumerQueue and the profile name.
Here context:SCM_TEST, queue:CALL_PROFILE and the remote profile DATA_AN_SCM, which must have the same name on the remote _data.
5.) The profile on the remote _data (here DATA_AN_SCM) must not have message set as the incoming agent, so that the profile of the consumer de.lobster.scm.dw.util.ExtendedCallProfileSubscriber is called and not by the standard message consumer service. It is therefore also possible to call up cron profiles, which, for example, execute database queries to return data. The profile on the remote _data must also return XML data. Since the XML structures of _scm in the remote _data are not available via custom templates, it makes sense to create the source structure in the _scm system and then transfer it to the remote _data by exporting from the _scm system and importing the profile.
6.) Now the custom classes CronPassBackDataResponse and CronPassBackDataResponseUTF8 can be used in the outgoing path of the profile on the remote _data (here DATA_AN_SCM) similar to a local profile call. To register custom classes on the remote data and display them in the selection box, the file .\etc\admin\datawizard\customresponse.properties can be used to add the entries:
de.lobster.scm.dw.util.CronPassBackDataResponse
de.lobster.scm.dw.util.CronPassBackDataResponseUTF8