Force message to Error

[jlockhart]

Hello all,

Anyone aware of a way to do this:

In a Source Transformer step, I want to examine the contents of ORC.8, and if it is null, then force the message into an ERROR state, and not send.

Either that, or send it into another channel to handle errors/send emails, etc....

Thanks,

J

[narupley]

The easiest way is just to throw an exception from a filter/transformer:

throw('Error message here.');

Or as you said, you could route it to another channel in the case of an error, and then simply filter the message in the first channel rather than throwing an exception.

[DBE]

Hello,

I have the same need. I opened a suggestion of improvement: [#MIRTH-2063] Choose the status of the message.

[narupley]

Originally Posted by DBE

Hello,

I have the same need. I opened a suggestion of improvement: [#MIRTH-2063] Choose the status of the message.

I responded....

This all looks like expected behaviour to me...

A message is "sent" if it processed through a destination successfully. For a null Channel Writer for example, obviously nothing is "sent" anywhere, but the MessageObject status of SENT is still relevant.

The whole purpose of a filter is to do data validation and prevent unwanted messages from processing through, without throwing any errors. However, you can still force errors with a throw() call. if you have this filter on a Source connector and you're worried about what response is sent back to the inbound client, then the LLP Listener has built-in properties that you can set to send custom response codes/messages based on whether the message was successful, filtered, or in-error. Even if you're not using an LLP Listener, you can still create custom responses and respond from them on the Source connector.

I'm not sure what you mean by "In the LLP Sender connector, it is possible to choose the status of the message." Did you mean the LLP Listener? If so, then even on the LLP Listener, you don't choose the status of message; you only choose the HL7 MSA response code and message that is sent back to the inbound client. If you have a filter on an LLP Listener Source connector, and you're sending "AA" as the response code in all cases, then the inbound client will receive a successful ACK no matter what, but the message stored in your database will still have a status of FILTERED. This is good behaviour (not only for development but for auditing as well) in my opinion, and shouldn't be changed...

[DBE]

Originally Posted by narupley

I'm not sure what you mean by "In the LLP Sender connector, it is possible to choose the status of the message." Did you mean the LLP Listener? If so, then even on the LLP Listener, you don't choose the status of message; you only choose the HL7 MSA response code and message that is sent back to the inbound client.

In the LLP Sender, there is a parameter "Process HL7 ACK". Its tooltip is:

When this setting is on, only successful ACK codes will allow a message to be marked as processed.

I answered too:

I understand the current behaviour.

But, you do not think that it would be interesting to have somewhere the real number of sent messages?

Without changing the status of the stored messages, I think that it could be interesting to have the choice to disable the auto-incrementation of the counters and to
have functions to increment the counter by JavaScript code, in the channel.

[narupley]

In the LLP Sender, there's actually not a lot of freedom to dynamically choose the response status. You can choose to "process" the HL7 ACK, but really all that is doing is looking at the MSA.1; if it's AA, then the status is SENT, otherwise it's ERROR.

It sounds like we just have a difference in semantic opinions. Different developers and systems will have different definitions of what a truly "sent" message should be.

That said, you can take matters into your own hands by decrementing the sent statistic for the channel and even updating the actual status of the message in the database from SENT to something else, in the postprocessor script.

[DBE]

Thank you for your point of view .

I already tried (and succeeded) to change the status and to decrement the counter but it makes the channels too complicated.

[narupley]

No problem! That rings a bell actually... I think I helped someone else out with that before. I'll copy it here for convenience:

Originally Posted by narupley

You can put this in your destination transformer:

$c('messageId',messageObject.getId());

And this in your postprocessor:

if ($r('Destination 1').getStatus() == 'FAILURE' && $r('Destination 1').getMessage().indexOf('Unable to connect to destination') >= 0) {
	com.mirth.connect.server.controllers.DefaultMessageObjectController.create().updateMessageStatus(new java.lang.String(channelId),new java.lang.String($('messageId')),com.mirth.connect.model.MessageObject.Status.SENT);
	com.mirth.connect.server.controllers.DefaultChannelStatisticsController.create().decrementErrorCount(new java.lang.String(channelId));
}
return;

After a message has been processed, that script will check if it failed with a particular message (in this case, "Unable to connect to destination"). If so, then it will update the message status to "SENT" in the database, and decrement the error count for the channel statistics. So, if you send a transaction through and it fails with that message, the channel entry on the dashboard will still show an incremented "Sent" statistic instead of the "Errored" one. Furthermore, if you look at the messages for that channel, the failed message entry for the destination connector will show a status of "SENT" rather than "ERROR". You'll still see the error message in the "Errors" tab though.

There are a couple of caveats to this though.

One is that the error message will still show in the server log. That actually isn't so bad; actually I think it's a good idea to keep that in the logs for reference, rather than suppress it.

Another one is that if you have an alert set on the channel, it will still be triggered. So in the case of my example, alerts for ERROR-408s on that channel will still happen. Again though the easy way around this is to exclude that error code from the Error Matching Field of the alert. So, maybe I want codes 300 and 301 to still trigger out an alert, but not 408. Personally, I don't even use the built-in Alerts plugin anyway... not until they upgrade it in 3.0 =P

If you really don't want the error to be written to the server log as well, then that's not so easy to do. You'll probably have to compile the source code yourself and modify some of the controller objects, or extend log4j to add another, custom log level for your purposes. Doable, but it's probably not worth your time for what you're trying to accomplish...

That code updates ERROR messages to SENT, but obviously it can be modified to do the opposite..