Mirth Connect with Microsoft Azure Queue Storage

Mirth Connect is the Swiss Army knife of open source integration engines with specific Healthcare support for HL7 message integration (though it works just as well when dealing with many types of data formats outside of HL7). Windows Azure enables you to build, deploy, scale and manage applications across a global network of Microsoft-managed data centers.

Mirth Connect uses the concept of channels and queues to ingest, filter, transform and send messages from one system to another. It has built in support for many protocols such as file systems, FTP sites, databases and web services. In this blog post I’m going to demonstrate how we can extend the built-in capabilities to use Mirth Connect to send messages directly to a Windows Azure Queue:

Windows Azure Queue storage is a service for storing large numbers of messages that can be accessed from anywhere in the world via authenticated calls using HTTP or HTTPS. A single queue message can be up to 64KB in size, a queue can contain millions of messages, up to the 100TB total capacity limit of a storage account.

By pairing an on-premise or cloud hosted the instance of Mirth Connect with Azure queues we are able to scale by having one or more instances (or channels within an instance) of Mirth Connect pushing messages to the queue while having an independent number of queue consumers receiving messages and performing business activities on them. We are also able to eliminate a single point of constraint and failure providing greater resiliency.

 In this blog, we will do the following:

  • Create a new Destination Connector in your Mirth Connect Channel
  • Create a transformer that will have steps to
    (a) base 64 encode the payload and
    (b) create the Azure Authorization token
  • Configure the HTTP Sender connector for Microsoft Azure Queue Storage

1. Create a new Destination Connector

Take your existing channel and under the Destinations tab clicks the “New Destination” from the menu on the left side under the heading “Channel Tasks(or edit an existing destination you have already created). Change the “Connector Type” to “HTTP Sender“. You should end up with something that looks like this:

mirth-azure-queue-1

2. Create the Transformer

 

  1. Click the “Edit Transformer” button on the left side of the screen under the “Channel Tasks” heading.
  2. Change the outbound message template of the Transformer to be “XML” and place the following content in the template area so it looks like the image below. This is the exact format that the Microsoft Azure Queue Storage Web Service needs to make sure it is exact: mirth-azure-queue-2

3. Create the Transformer Step to Base 64 Encode the MessageText Payload

  • First, click the “Add New Step” button on the left side of the screen under the “Transformer Tasks” heading.
  • Change the type of the transformer to “JavaScript” by double clicking on the word “Mapper” located in the third column with the heading “Type” and choosing the last option “JavaScript“.
  • The payload for the content needs to be base 64 encoded. We can do that in Mirth Connect by utilizing the encode64String from org.apache.commons.codec.binary.Base64 package that comes with the out of the box Mirth Connect installation.
  • Place the following code in the content area for the transformer which will take a variable called “CONTENT” (you should change this to be appropriate for your content variable) and base 64 encode it and place it into the “MessageText” element of the XML:

3. Create the Authentication Headers Transformer Step

Windows Azure requires a specific Authorization Header to authenticate each request using a Hash-based Message Authentication Code (HMAC) constructed from the request and computed by using the SHA256 algorithm and then encoded by using Base64 encoding.

 

  1. To create a transformer step to populate the “MessageText” in the payload. First, click the “Add New Step” button on the left side of the screen under the “Transformer Tasks” heading.
  2. Change the type of the transformer to “JavaScript” by double clicking on the word “Mapper” located in the third column with the heading “Type” and choosing the last option “JavaScript“.
  3. Place the following code in the content area for the transformer. You should replace the “account”, “key” and “path” variables with your own Windows Azure credentials and queue name (the ones in the code below are for testing with the Azure SDK on your local machine).This will populate the variables that we will use in the actual HTTP Sender headers:
  4. Save the changes to the transformer and return to the Channel Editor screen.

 

4. Configure the HTTP Sender

Make the following changes to the HTTP Sender:

  1. Change the URL to the location of the web service. The format should be: HTTP://<storage account>.queue.core.windows.net/<queue>
  2. You should enable Persistent Queues
  3. Set the headers as shown in the image below. You will need “x-ms-version”, “x-ms-date” and “Authorization”. The values for these headers are calculated and populated in the transformer step you just completed above.
  4. Set the Content Type to “text/xml”
  5. Set the Content to “${message.encodedData}”
  6. Check your settings against the image below:
    mirth-azure-queue-3
Talk to us
Posted in:

Leave a Reply