Announcement

Collapse
No announcement yet.

Error routing message to channel id when downstream paused or stopped.

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

  • Error routing message to channel id when downstream paused or stopped.

    Hi All,

    I'm getting the following message when I pause or stop a specific channel which is sent from an upstream Mirth channel.

    ERROR (com.mirth.connect.server.userutil.VMRouter:114): Error routing message to channel id: 4066ca9d-14bc-4c5c-8a73-6c1c642bf032
    com.mirth.connect.donkey.server.channel.ChannelExc eption


    The destination is a Javascript writer with the following code:

    Code:
    //edit this first line to indicate the actual destination channel
    var sDestinationChannel = 'CDX_POI_RAD_Outbound_To_DB';
    
    
    // Unlike the TD Destination Template, for each message processed, this channel forwards
    // a variable number of messages to its destination
    //for each (var sHL7 in $('splitMessages'))
    for each (var sHL7 in SplitRADMessageOnReportNoMap())
    {
    	router.routeMessage(sDestinationChannel, sHL7);
    }
    the SplitRADMessageOnReportNoMap() function just returns an array of messages that were created from the original by splitting on ORC.1. That part works fine. The destination connector works fine, so long as the downstream destination is active and running.

    The issue is, if I pause the downstream channel that receives these split up messages one at a time, I get the error noted above. The sending channel/destination doesn't register any kind of problem and marks the message as sent in the dashboard. The messages are essentially lost in the ether and the only way to get them back is to reprocess the entire run of messages over timespan in which the downstream destination was stopped.

    I've tried all combinations of Queue settings (always, on error, wait for previous), I've switched around the order of the upstream destination connectors, all to no avail.

    I tried using
    Code:
    router.routeMessageByChannelID
    in which case, the exception is not thrown, but the message is still "sent" to nowhere.

    All other destination connectors on the upstream channel are Channel Writers vs. Javascript writers and they queue as expected when the downstream channels are paused or stopped. It's only this one JS writer.

    I'm at a loss on this one.

  • #2
    You have to check the Response that you get from router.routeMessage to see if it completed successfully.

    Here is the JavaDoc. http://javadocs.mirthcorp.com/connec.../VMRouter.html

    The downstream channel not being started is actually the example given for a reason it could fail.

    You might want to consider setting a deploy/start dependancy of the upstream channel on the downstream channel to make it more difficult for the upstream to be running while the downstream is down.

    You've got a few choices in what to do after routeMessage fails.
    • If you have destination queuing turned on, you can queue the message from your javascript writer so it will try again on its own.
    • You can throw an exception.
    • You can return an Error response.
    • You can attempt to start the downstream channel using ChannelUtil and try again.

    Comment


    • #3
      The sending channel/destination doesn't register any kind of problem and marks the message as sent in the dashboard.
      That is because you are not handling response in the JS writer. You have to code around that fail state by adding either
      Code:
      return SENT
      or
      Code:
      return ERROR
      based on the condition at the end of the JS script.

      However, If I were you I would remove that router.routeMessage from JS writer, and use a channel writer instead. To control data flow, I would use a Filter. router.routeMessage does a silent routing.
      HL7v2.7 Certified Control Specialist!

      Comment


      • #4
        Originally posted by agermano View Post
        You have to check the Response that you get from router.routeMessage to see if it completed successfully.

        Here is the JavaDoc. http://javadocs.mirthcorp.com/connec.../VMRouter.html

        The downstream channel not being started is actually the example given for a reason it could fail.

        You might want to consider setting a deploy/start dependancy of the upstream channel on the downstream channel to make it more difficult for the upstream to be running while the downstream is down.

        You've got a few choices in what to do after routeMessage fails.
        • If you have destination queuing turned on, you can queue the message from your javascript writer so it will try again on its own.
        • You can throw an exception.
        • You can return an Error response.
        • You can attempt to start the downstream channel using ChannelUtil and try again.
        Ahh thank you. I come at this having kind of inherited the code. I'm familiar with most of the system, but not this part. Also, I'm a Mirth newbie.

        How would I find an example of how to catch the error and queue the message if an error was returned?

        Thanks.

        Comment


        • #5
          Code:
          try 
          {
          //your script
          }
          catch (e) {
          responseStatus=QUEUED;
          }
          
          return responseStatus;
          HL7v2.7 Certified Control Specialist!

          Comment

          Working...
          X