web stats
Turn off channel destination but leave source on - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Thread Tools Display Modes
Old 05-09-2012, 07:06 PM
chris_merris chris_merris is offline
What's HL7?
Join Date: May 2012
Posts: 2
chris_merris is on a distinguished road
Default Turn off channel destination but leave source on

Hi everyone,

My company is a healthcare software vendor evaluating Mirth to replace a homegrown interface solution. We receive multiple interface feeds from each hospital that uses our product.

One question about channel control:
Is it possible to stop a channel from sending messages to its destination(s), while leaving the channel source active (and receiving/queueing up messages in the Mirth database)?

We have a multi-tier product where the messages ultimately end up in a database, but when the database goes down, or is not ready to receive messages, we need the ability to continue to receive and queue them in Mirth until the database is back up or ready to receive the messages.

In all the examples I've found so far, the channel can only be on or off, meaning both the source and destination ends can never be set independently of each other.

Reply With Quote
Old 05-10-2012, 04:08 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road

The source and destination connectors basically act as separate hubs for a message. Each hub can have its own filter, so that you can choose to discard/filter a message at either step of the message flow. So, it would be possible and relatively easy to have filter code on a destination that attempts to connect to a database, and discards the message if it wasn't able to connect.

However, that's probably not what you want; you want to basically hold the message in a queue if there's a drop in connectivity, and then continue processing after the database is back up.

This is where persistent queuing comes in. Mirth's LLP, TCP, HTTP, and SOAP (web service) Sender connectors have options to queue a message in the event that the send failed. However, the Database and JavaScript Writer connectors don't have this feature. So, an easy solution for that is to set up two channels, an "inbound" and an "outbound". The inbound channel receives the messages (optionally does any filtering/transforming), and sends to the outbound channel with persistent queues (with an LLP Sender for example).

At this point, the outbound channel attempts to write the message to the database. If the write was successful, then a SUCCESS Response will be written to the response map for that destination. If the write failed, then obviously that Response will have a status of FAILURE. So next, you would go into the postprocessor, which runs after all destinations have been processed. If your database destination has a response status of SUCCESS, then you would create your own, custom Response object (let's call it ACK) and place it in the response map. Otherwise, don't create anything. Then, on the LLP Listener source connector, you would choose to "respond from" your custom ACK response. When the outbound channel receives a message, instead of automatically sending back a standard HL7 ACK, it will wait until after the postprocessor runs, and then send your custom ACK back to whatever client sent the message. If the ACK response was never created, then the source connector won't send a response back.

What this means is that the inbound channel will send to the outbound channel via LLP, and queue the message up if it doesn't receive an ACK back from the outbound channel. Meanwhile, the outbound channel will receive messages via LLP, but only send an ACK back if it was able to successfully process the Database Writer destination. If connectivity goes down and the outbound channel isn't able to connect to the database, then the inbound channel will just send the same message over and over again (while possibly at the same time continuing to receive messages from the client) until it receives an ACK. When connectivity resumes and the outbound channel starts sending back ACKs, then all the messages in the inbound channel's queue will process through, in order of initial arrival.

Look here for an example of how to do this with an FTP File Writer:

Reply With Quote
Old 05-10-2012, 06:33 AM
chris_merris chris_merris is offline
What's HL7?
Join Date: May 2012
Posts: 2
chris_merris is on a distinguished road
Default Thanks

Thanks so much for that helpful response. I really appreciate the help.

Reply With Quote

channel, channel status, destination, settings, source connector

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT -8. The time now is 01:55 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Mirth Corporation