AMQP Publish / Subscribe Functionality

This page explains how the MIStudio (or TransSECS) components use AMQP 0-9-1 (RabbitMQ) for publish/subscribe messaging, and what configuration steps are needed for queues, routing keys, and logging.

Each running instance of the application (for example, a project named GEMHost or ForwardingGEMHost) connects to a RabbitMQ broker and publishes or subscribes to topics using the built-in topic exchange:

• Exchange: `amq.topic`
• Routing keys: dot-separated hierarchical names

(for example, `gemhost.variables.ceid.completed`)

The publish/subscribe pattern allows multiple independent components or tools to exchange messages without tight coupling:

• Publishers send data to an exchange using a routing key.
• Subscribers create queues bound to that exchange, specifying which routing keys they want to receive.

Each project instance should have a dedicated queue to receive messages. The queue name normally matches the project name:

• Project GEMHost → Queue GEMHost
• Project ForwardingGEMHost → Queue ForwardingGEMHost

This ensures isolation between independent projects or tools.

To receive all messages under a project’s namespace, bind the queue using a wildcard binding on the topic exchange:

• Binding key:

`gemhost.#`

  (or `forwardinggemhost.#` for ForwardingGEMHost)

This will deliver any routing key beginning with that prefix (e.g., `gemhost.variables.*`, `gemhost.events.*`, etc.).

Example binding command (RabbitMQ Management UI → *Queues → Add Binding*): ```

Exchange: amq.topic Routing key: gemhost.# Queue: GEMHost

````

When the application starts, it generates two text files listing the routing keys that are used internally:

• AMQP_Publish_TagList.txt — all routing keys the application *publishes*
• AMQP_Subscribe_TagList.txt — all routing keys the application *subscribes* to

Each entry in AMQP_Subscribe_TagList.txt will cause the application to create and bind a queue corresponding to that routing key. These files are helpful for verifying which topics are active and for setting up external consumers or test tools.

AMQP activity is logged by the AMQPLogger, configured in your `log4j2.xml` file.

Example configuration: ```xml <!– AMQP Logger –> <Logger name=“com.ergotech.vib.servers.amqp” level=“debug” additivity=“false”>

  <AppenderRef ref="AMQPLogFile"/>

</Logger> ````

At the debug level, this logger shows “happy path” activity:

* Connections established and disconnected * Messages successfully published (routing key and size) * Messages received and delivered to subscribers

For deeper inspection (message bodies), enable trace level:

```xml <Logger name=“com.ergotech.vib.servers.amqp” level=“trace” additivity=“false”>

  <AppenderRef ref="AMQPLogFile"/>

</Logger> ```

If you prefer quieter logs, reduce the level:

* info — lifecycle only * warn — only warnings * error — errors and exceptions only

Logs are written to AMQP.log (and rolled daily to `AMQP-yyyy-MM-dd.log.gz`).

By ensuring your queue and binding match the project’s routing key pattern, all published messages will be routed correctly and logged for easy verification.