No announcement yet.

Error messages are not Queued?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Error messages are not Queued?

    Using Mirth 3.7.0 and source MLLP HL7 V2 receiver with a single HTTP Sender destination. This sender connects to a Rest endpoint and performs a POST. The post then replied with either OK 200 or some BadRequest 400 code.
    I'm running a Response Transformer (Msg Template sert to Raw) as follows:

    if (msg != "") {
    	var o = JSON.parse(msg);
    	if (o.success){	    
    		responseStatus = SENT
    	} else {
    		responseStatus = QUEUED;
    		responseStatusMessage = o.errorMessage;	     
    } else {			
    		responseStatus = QUEUED;
    		responseStatusMessage = "No response was recived, possiably service is down.";	
    This works quite well in that any response that is not o.success are marked as 'QUEUED', and are then queued as expected.

    Where my question lies is can I have my o.success == false set to ERROR rather than QUEUED so it is obvious to those looking in the dashboard that an error has occurred, however, I still want the message to be queue.

    What I want is an ERROR+QUEUED, is that possible?

    Personally, I don't understand why ERROR messages are not continued to be queued. In my experience message order tends to matter a lot and having message skipped is rarely desirable.


  • #2
    The message status can only be in one state. The QUEUED status indicates that the message has encountered a recoverable problem (either because of an unsuccessful dispatch, or for your own reasons in the response transformer) and should be retried. The ERROR status indicates that the message has encountered an irrecoverable problem and should not be retried.

    ERROR messages are not retried by design, because that is the difference between the QUEUED and ERROR statuses. When queuing is enabled, messages are typically not set to ERROR. They are set to QUEUED by default.

    There are only a few cases where the message status is explicitly set to ERROR. For example if your response is HL7 v2.x, you have Validate Response on, and there's a problem with the HL7 ACK (like a failure ACK code). The Web Service Sender sets the status to ERROR if a SOAP Fault is returned by the server. The TCP Sender sets the status to ERROR if you have "Queue on Response Timeout" turned off and a socket timeout is encountered. The JavaScript Writer sets the status to ERROR if the script cannot be compiled or there is an error executing the script.

    So if the status is being set to ERROR, it's likely either because you have queuing turned off, or because you are explicitly setting the status to ERROR in a response transformer.

    Note that you can also set the "responseErrorMessage" variable in the response transformer, which will also save error content for the message. That will flag a Processing Error for the message, and in the message browser you will see "Processing" under the Errors column. That error content will also be visible in the content pane below. You can also search on messages with errors with the Advanced search settings. Also, you can enable the Send Attempts column in the message browser, to view how many times a message has been retried.

    So even if the message is QUEUED, you can still easily see what error (if any) is associated with the most recent send attempt.
    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.


    • #3
      Thank you for your reply narupey, I can see you're a hard worker over these forums, well done!

      So I think I am coming around to the idea that if message ordered matters then you want to always QUEUE and completely avoid ERROR.

      It's really just a learning curve as the HL7 integration engine I used to use "HL7 Connect" would always queue and any error would stop the interface and leave that last errored message at the front of the queue.

      Here with Mirth that errored message is removed from the queue and I'm still not sure how I would get it back to the front of the queue once the root issue is worked on and fixed.

      The best I can come up with is to stop the channel on any error, by script, and then have a pre-created second identical started channel which I can then manually send the now fixed error message to. This allows that message to leave Mirth ahead of the other messages queued on the first now stopped channel. But all this seem like a lot of work for what I thought would be standard practice. Maybe I'm missing something.

      My main goal is to avoid all errors in my response Transformer javascript, but that feels like a programmer guaranteeing he will never create a bug, something I'm not confident of.

      On a slightly different point, you mentioned "you can also set the "responseErrorMessage" variable in the response transformer". I was using the 'responseStatusMessage' instead and it seems to behave in the same way. Can you elaborate on how the two might be different?

      Thanks again for your help, very knowledgable !
      Last edited by Angus Millar; 02-28-2019, 09:38 PM. Reason: Typo