The MessageService is a message-based data transmission system in which producers of messages have them transported via so-called message queues to any existing subscribers, where they can be processed. Messages can also be sent across multiple Integration Servers by defining so-called routes.

XML configuration

Important note: The availability of a service depends on the license purchased and whether the service has been registered in the configuration file ./etc/factory.xml of the Service Factory (changes require server restart!). There you will also find the responsible configuration file for a service, otherwise you can also edit the configuration file of the service directly in the GUI of the service (changes require a service restart!).

The following XML fragment with all possible basic settings can be used to configure the MessageService.

<Set name="defaultWaitTime">600000</Set>
<Set name="queueInterval">50</Set>

The parameters have the following meaning.

Parameter	Description
defaultWaitTime	The maximum time (in milliseconds) that a message will be held by the MessageService before it is discarded. When changed, it is valid for all subsequent messages.
queueInterval	The time to wait (in milliseconds) before undelivered asynchronous persistent messages are resent.

The following XML fragment adds a consumer queue to the MessageService.

<Call name="addConsumerQueue">
	<Arg>
		<New class="com.ebd.hub.services.message.ConsumerQueue">
			<Arg>Context</Arg>
			<Arg>Queue</Arg>	
			[possibly adding consumers]
		</New>
	</Arg>
</Call>

Adding a consumer to a consumer queue

The following XML fragment adds a consumer to a consumer queue.

<Call name="addConsumer">
	<Arg>classname</Arg>
	<Arg>methodname</Arg>
</Call>

This fragment must be inserted instead of the placeholder, which can be seen in the consumer queue above. "classname" is the class name of the class to act as consumer, "methodname" is the method to call in this class.

Activating the remote interface

This option enables the remote interface through which remote Integration Servers can deliver messages for which there was no local subscriber. The following XML fragment activates the remote interface.

<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.

Adding a remote route

The following XML fragment adds a remote route to a specific consumer queue. This sends messages with this context and this queue to the specified, remote Integration Server. The remote Integration Server must have an active remote interface.

<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 parameters have the following meaning.

Parameter	Description
context	The name of the message context.
queue	The name of the message queue.
hostname	The host name of the remote interface.
port	The port of the remote interface.

General settings

images/download/attachments/128385810/Services_15_2_EN-version-2-modificationdate-1726215348106-api-v2.png

(1) Activating the remote interface.

(2) Number of threads for processing messages.

(3) Corresponds to the XML parameter defaultWaitTime. This is the time that the message is held by the MessageService before it is discarded.

(4) Corresponds to the XML parameter queueInterval and is the time to wait to resend undelivered, asynchronous, persistent messages.

(5) Shows whether the Message Service is running via TLS. Following is the corresponding entry in the configuration file of the service.

<!--
Enable TLS for the remote interface. Please create and use your
own keystore. The one provided with the installation doesn't
contain a secure TLS certificate.
          
All Integration Servers that are going to connect this system
need to share the same certificate and private key
(i.e. keystore file)
          
Usage:
Parameter 1: Relative or absolute filename to the keystore file
Parameter 2: Password of the keystore (you can use obfuscation if preferred)
Parameter 3: Password of the Private Key (you can use obfuscation if preferred)
Parameter 4: 'true' if connecting peers need to do TLS-client authentication, 'false' otherwise
-->
<!-- 
<Call name="enableTLSHandling">
	<Arg>./etc/ms_tls_keystore.dat</Arg>
	<Arg>keystorepassword</Arg>
	<Arg>keypassword</Arg>
	<Arg type="boolean">false</Arg>
</Call>
-->

(6) The default port is "8020" and should not normally be changed. If you do change it, please be aware that this affects several places, e.g. the Transport Manager, the DMZ server, etc.

Routing definitions

images/download/attachments/128385810/Services_24_EN-version-1-modificationdate-1675149584977-api-v2.png

(1) The list of remote interfaces. Entries can be added, edited and removed via the context menu. See (2),

(2) Protocol, host name (or IP address) and port of the remote interface.

Defined consumer queues

images/download/attachments/128385810/Services_26_EN-version-1-modificationdate-1675149584968-api-v2.png

(1) List of the defined consumer queues. The display shows context, queue, number of consumers, the existence of a route definition and the number of messages that still have to be processed. An entry can be added, removed and edited via the context menu.

Modifying consumer queue

images/download/attachments/128385810/Services_27_EN-version-1-modificationdate-1675149584964-api-v2.png

(1) Context name and queue name.

(2) Use the context menu to remove and add a consumer.

(3) Use the context menu to remove and add routing definitions.

Log level dependencies

Changes to the log level of the LogService have no influence on the logging behaviour of the MessageService.

If the service is set to verbose mode, the following additional logging steps are performed.

When a message is sent.
When establishing a connection via the remote interface, the fact itself and the IP address of the request are recorded, regardless of whether a message is actually received or not.
When receiving a message via the remote interface. Information about the event itself and additional information, such as the number of received bytes, etc. are logged.
When adding a message to a message queue.