Mirth Connect: Part 2 - Adding 🐰RabbitMQ

Schematic of Mirth Connect feeding HL7v2 messages into a RabbitMQ queue with multiple consumers

When your integration engine needs a memory

Mirth Connect is excellent at transforming and routing HL7v2 messages. What it's less good at is surviving downstream failures without losing messages. That's where RabbitMQ comes in. Adding a message queue between Mirth and its consumers makes the whole integration more durable.

Scalability

RabbitMQ handles high message volumes and supports clustering for increased throughput and redundancy. Paired with Mirth Connect, it removes the integration engine as a bottleneck: Mirth transforms messages and hands them off to the queue, and the queue absorbs load spikes that would otherwise back up into Mirth.

Reliability

RabbitMQ persists messages and requires delivery acknowledgments. If Mirth fails to process a message, the message stays in the queue and gets reprocessed when Mirth recovers. In healthcare integrations, losing a message isn't an acceptable failure mode.

Decoupling

The queue acts as a buffer between message producers and consumers. If Mirth goes down for maintenance, incoming messages continue flowing into RabbitMQ. When Mirth comes back up, it processes the queued messages in order. Producers never need to know that the consumer was temporarily unavailable.

Flexible Routing

RabbitMQ's exchange and queue model routes messages based on content or type. Different message types — ADT, ORU, SIU — can land in different queues, each consumed by different processors. This is cleaner than building all the routing logic inside Mirth channels.

Load Balancing

Multiple Mirth instances can consume from the same RabbitMQ queue, which distributes processing load across them. No single instance gets overwhelmed, and you can scale horizontally by adding consumers without changing the producer configuration.

Integration with Other Systems

RabbitMQ isn't limited to Mirth. Other systems in your healthcare infrastructure can produce or consume from the same queues. This turns RabbitMQ into a central messaging hub, which simplifies integration between systems that otherwise have no direct connection.

Enhanced Monitoring and Management

RabbitMQ ships with a management plugin that provides a web-based UI for monitoring broker health, viewing message rates, and managing queues and exchanges. In a production healthcare environment, that visibility is useful when something stops flowing.

RabbitMQ Setup

RabbitMQ is based on AMQP, not JMS. Client libraries bridge that gap: Java applications using the JMS API can talk to RabbitMQ through the RabbitMQ JMS client library, so you write against the JMS API and the library handles translation to AMQP under the hood.

Use the RabbitMQ Docker image to avoid a manual install and configuration.

Start the RabbitMQ container with name "some-rabbit", listening on port 5672, and serving the management interface on port 8081: docker run -d --hostname my-rabbit --name some-rabbit -p 8081:15672 -p 5672:5672 rabbitmq:3-management

To enable extra plugins like Topic Exchange: docker exec -it some-rabbit rabbitmq-plugins enable rabbitmq_jms_topic_exchange

To see a list of running plugins: docker exec -it some-rabbit rabbitmq-plugins list

Management Interface

With the container running, the management interface is available at:

Create a queue by navigating to the "Queues" tab and creating one named "myqueue". It should look something like this:

Updates To Mirth Connect

Import the latest RabbitMQ libraries — you need both the JMS client and the Java client — into a dedicated resource for use in your channels. As of version 4.0.1, there's a known issue with using these libraries in JMS connectors, so place them in custom-lib and set server.includecustomlib = true in mirth.properties. For example:

For documentation on the RabbitMQ JMS Client see:

Steps
1. Set your channel dependencies to include the resource containing the RabbitMQ jars.
2. Set your Destination Connector Type to: JMS Sender
3. Use JNDI: No
4. Load the ActiveMQ template
5. Set Connection Factory Class to:`com.rabbitmq.jms.admin.RMQConnectionFactory`
6. Set the brokerURL to:`failover:(tcp://localhost:5672)?maxReconnectAttempts=0`
7. Set Username to: guest
8. Set Password to: guest
9. Set Destination Type to: Queue
10. Set Destination Name to: myqueue
11. Deploy channel
12. Send a test message
13. Observe the message is sent with no errors
14. Observe in the RabbitMQ UI that "myqueue" has one message ready

Steps
1. Set your channel dependencies to include the resource containing the RabbitMQ jars.
2. Set your Destination Connector Type to: JMS Sender
3. Use JNDI: No
4. Load the ActiveMQ template
5. Set Connection Factory Class to:`com.rabbitmq.jms.admin.RMQConnectionFactory`
6. Set the brokerURL to:`failover:(tcp://localhost:5672)?maxReconnectAttempts=0`
7. Set Username to: guest
8. Set Password to: guest
9. Set Destination Type to: Queue
10. Set Destination Name to: myqueue
11. Deploy channel
12. Send a test message
13. Observe the message is sent with no errors
14. Observe in the RabbitMQ UI that "myqueue" has one message ready**

🎉 We did it! We have successfully integrated RabbitMQ with Mirth Connect all using docker. We can keep a clean setup that is portable and easy to maintain.

SharePostShare