web stats
Force message to Error - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 03-14-2012, 12:43 PM
jlockhart jlockhart is offline
OBX.2 Kenobi
 
Join Date: Dec 2010
Location: Rochester, NY
Posts: 58
jlockhart is on a distinguished road
Default Force message to Error

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
Reply With Quote
  #2  
Old 03-14-2012, 06:12 PM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 4,086
narupley is on a distinguished road
Default

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

Code:
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.
Reply With Quote
  #3  
Old 03-16-2012, 07:17 AM
DBE DBE is offline
OBX.1 Kenobi
 
Join Date: Sep 2011
Posts: 31
DBE is on a distinguished road
Default

Hello,

I have the same need. I opened a suggestion of improvement: [#MIRTH-2063] Choose the status of the message.
Reply With Quote
  #4  
Old 03-16-2012, 07:46 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 4,086
narupley is on a distinguished road
Default

Quote:
Originally Posted by DBE View Post
Hello,

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

Quote:
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...
Reply With Quote
  #5  
Old 03-16-2012, 08:05 AM
DBE DBE is offline
OBX.1 Kenobi
 
Join Date: Sep 2011
Posts: 31
DBE is on a distinguished road
Default

Quote:
Originally Posted by narupley View Post
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:
Quote:
When this setting is on, only successful ACK codes will allow a message to be marked as processed.
I answered too:
Quote:
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.

Last edited by DBE; 03-16-2012 at 08:15 AM.
Reply With Quote
  #6  
Old 03-16-2012, 08:53 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 4,086
narupley is on a distinguished road
Default

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.
Reply With Quote
  #7  
Old 03-16-2012, 09:04 AM
DBE DBE is offline
OBX.1 Kenobi
 
Join Date: Sep 2011
Posts: 31
DBE is on a distinguished road
Default

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.
Reply With Quote
  #8  
Old 03-16-2012, 09:29 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 4,086
narupley is on a distinguished road
Default

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

Quote:
Originally Posted by narupley View Post
You can put this in your destination transformer:

Code:
$c('messageId',messageObject.getId());
And this in your postprocessor:

Code:
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..
Reply With Quote
  #9  
Old 05-22-2014, 01:07 PM
mby01 mby01 is offline
Mirth Newb
 
Join Date: Jan 2014
Posts: 6
mby01 is on a distinguished road
Default

Quote:
Originally Posted by narupley View Post
The easiest way is just to throw an exception from a filter/transformer:

Code:
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.
Folks, apologies for raising this old thread from the dead but I just wanted to check if this is still the recommended way of putting a message into error status from a transform?

The suggested method (i.e. throw-ing an error) works well in the sense that it forces the message into error status. Unfortunately the error message in the log can be a little difficult to work with since the error message I "throw" is kinda buried inside the error text. For example:

Quote:
Transformer error
ERROR MESSAGE: Error evaluating transformer
com.mirth.connect.server.MirthJavascriptTransforme rException:
CHANNEL: Test Upload
CONNECTOR: sourceConnector
SCRIPT SOURCE: TRANSFORMER
SOURCE CODE:
34: var dir = "";
35:
37: var ret = upl.Upload(data);
38: if (ret != "1") {
39: throw "ERROR: File not uploaded (" + ret +")";
40: }
41:
42: channelMap.put('ret', ret);
43: logger.info(ret);
LINE NUMBER: 39
DETAILS: ERROR: File not uploaded (0)
at 2d52abe6-bf71-46fa-bec7-8103c777f032:39 (doTransform)
at 2d52abe6-bf71-46fa-bec7-8103c777f032:46 (doScript)
at 2d52abe6-bf71-46fa-bec7-8103c777f032:48
at com.mirth.connect.server.transformers.JavaScriptFi lterTransformer$FilterTransformerTask.call(JavaScr iptFilterTransformer.java:134)
at com.mirth.connect.server.transformers.JavaScriptFi lterTransformer$FilterTransformerTask.call(JavaScr iptFilterTransformer.java:100)
at java.util.concurrent.FutureTask.run(FutureTask.jav a:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
The custom error message I threw ("ERROR: File not uploaded ...") is buried in the middle there. Not a show-stopper by any means, just a bit messy since I was hoping to give this to a non-technical person to keep an eye on but I'm worried all the other stuff in the error message will confuse her.

BTW, I want to avoid sending errors to another "error" channel since there will be many channels similar to the one above, and each one will have to have it's own "error" channel.

Any thoughts or tips?

Thanks!
Reply With Quote
  #10  
Old 05-22-2014, 01:15 PM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 4,086
narupley is on a distinguished road
Default

In 3.x you can actually return a Response object from a JavaScript Writer. In that object you specify the error message directly, so it can be whatever you want:

Code:
return new Response(ERROR, 'message', 'status message', 'custom error');
For any other connector, you can modify the error for a destination in the response transformer:

Code:
responseErrorMessage = 'whatever';
__________________
Step 1: JAVA CACHE...DID YOU CLEAR

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.
Reply With Quote
Reply

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 -7. The time now is 07:35 PM.


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