Announcement

Collapse
No announcement yet.

Turn off channel destination but leave source on

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Thanks,
    Chris

  • #2
    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:

    http://www.mirthcorp.com/community/f...76&postcount=2
    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

    Nicholas Rupley
    Work: 949-237-6069
    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


    - How do I foo?
    - You just bar.

    Comment


    • #3
      Thanks

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

      -Chris

      Comment

      Working...
      X