| Author |
Message
|
| jrsetters |
 Posted: Tue Aug 28, 2012 10:03 am Post subject: Is it possible to force a message to exit a flow? |
 |
|
Acolyte
Joined: 24 Aug 2011
Posts: 72
Location: Cincinnati, OH
|
One of the configurable properties of the GenericHL7Out node is the maximum number of retry attempts the node will make before exiting the flow.
In most cases we want this number to be very high, ie the receiving system is down, the port is closed and so forth.
However if we receive an HL7 NAK from the server, we don't want to try and send that message over and over again. We want to log the event and move on to the next message in the inbound queue.
The maximum number of retries is stored in the message tree under InputLocalEnvironment.HL7."RetryLimit". In the case of a NAK, I can set this variable from our high limit down to 2 or 5. However once it reaches the end point in the flow, the HL7 Node attempts it again and it resets the variable to whatever it is configured with.
Is there a strategy for getting past this? I can easily tell whether or not I have a NAK by looking in the message tree. When I see one I'd either want to set the retry limit very low for that message only or just force it to exit the flow. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Aug 28, 2012 10:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You typically exit a message flow by propagating to an unconnected terminal, or by causing a transformation node to not propagate anything at all (i.e. using RETURN FALSE in ESQL). |
|
| Back to top |
|
|
| jrsetters |
| Posted: Tue Aug 28, 2012 10:23 am Post subject: |
|
|
Acolyte
Joined: 24 Aug 2011
Posts: 72
Location: Cincinnati, OH
|
| I don't know if it is particular to the GenericHL7Node or if I need to approach it differently. If I try to propagate to RETURN False using a compute node after the HL7 node it will propagate properly (ie no data out of the compute node) but the HL7 node will go ahead and make another attempt and keep doing so until it hits the limit that is set within its properties or makes a successful connection. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 28, 2012 10:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| jrsetters |
| Posted: Tue Aug 28, 2012 10:48 am Post subject: |
|
|
Acolyte
Joined: 24 Aug 2011
Posts: 72
Location: Cincinnati, OH
|
I just verified it by debugging, even if I suppress all of the output, that GenericHL7Node is going to retry until it hits its limit. Its almost like it operates independent of the rest of the flow.
If I put breakpoints around it, the messages from the MQInput node go in one time but the GenericHL7Output node will continue to spit out the message until it gets a successful ACK from the receiving system.
Uggh. I've worked on a logging and notification subflow for almost a month for these outbound HL7 interfaces, and this is the last thing I can't get to work. Otherwise it does everything we want. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 28, 2012 10:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Presumably there's a technical reason involving the HL7 data or the transport in use.
Again, a PMR should provide you either an explanation of this or a solution.
Or perhaps someone who's used these will come along with a more positive suggestion. |
|
| Back to top |
|
|
| jrsetters |
| Posted: Tue Aug 28, 2012 11:56 am Post subject: |
|
|
Acolyte
Joined: 24 Aug 2011
Posts: 72
Location: Cincinnati, OH
|
| Would it be very bad to use a THROW to get out of the message flow? |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Aug 29, 2012 2:54 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Can you provide a description of your flow (Nodes, and connections) e.g. [MQInput] --> [Compute] etc...
Can you explain at which point you are seeing the InputLocalEnvironment.HL7."RetryLimit" value? And at what point are you trying to set it to a lower value to cause less retries? |
|
| Back to top |
|
|
| jrsetters |
| Posted: Wed Aug 29, 2012 5:07 am Post subject: |
|
|
Acolyte
Joined: 24 Aug 2011
Posts: 72
Location: Cincinnati, OH
|
We enqueue from a topic where mapped HL7 messages are published. The first thing we do is throw a copy to a journal queue (we want to replace this with a database at some point). We then send it tot he Flow order node which first sends a copy of the message into the AddTimeStamp subflow. This will generate a time stamp followed by the actual message in a .log file on the server.
It then passes to the GenericHL7Node which attempts to send to the configured IP and Port. The retry limit is also a property here. The terminals on the node are Failure, Out, and Retry. When an positive Acknowledgement or an AR (badly formatted header) NAK is received, the ACK is propagated to the Failure terminal. We route that tot he inbound on the AddTimeStamp sublfow that will timestamp the ACK/NAK and insert it into the log file.
When most other conditions are encountered: no ack received, AE (data error) NAK, host not available etc the original message will propagate to either OUT or RETRY. In either case the InputLocalEnvironment.HL7."RetryLimit" will be present and contain the value. At that point it is again routed tot he AddTimeStamp subflow which uses a series of Filters and Computes to generate appropriate time stamps in the log file and to create email alerts when certain conditions are met (such as 25 attempts).
When certain conditions are present (found in the error table for the node http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.healthcare.doc/ha00170.htm) we perform different actions. On communication issues (codes SENDHL7 and TIMEOUT) we want the flow to keep retrying the message until communication is restored). On others, such as ACKAE we want the flow to skip the message after 5 retries and move to the next message. The thought being we want to hold message processing up when there is a communication issue, but not if there is a simple error in a single message.
It was in there, off of the ACKAE, ACKERROR, or ACKPARSEEROR conditions that I tried to reset the environmental variable to '5'. This value was retained through the end of the flow. However another OUT/RETRY is generated from the GenericHL7Node and the environmental variable is reset to the older high value.
FWIW I added a new filter node yesterday off of the ACKAE path in the AddTimeStamp and simply did this:
CREATE FILTER MODULE AddTimeStamp_StopRetry
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
DECLARE hl7 NAMESPACE 'urn:hl7-org:v2xml';
DECLARE Processchk BOOLEAN;
DECLARE flag INT;
SET flag = COALESCE(LocalEnvironment.HL7."RetryCount", '');
If flag <= 4 THEN
SET Processchk = 'TRUE';
ELSE
THROW USER EXCEPTION VALUES('Exceeded Maximum Attempts on NAK-AE');
END IF;
RETURN Processchk;
END;
END MODULE;
This does stop the processing of the message and the flow will move onto the next one. I am just not sure if there are any other repercussions for doing so.
 [/img] |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Aug 29, 2012 5:45 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
I have never used the HL7 node so take this with a grain of salt...
Is it possible to set the 'retry limit' or the node to 0, and then manually perform retries by resending any messages that need retrying back to the input terminal? You'll obviously need to keep your own 'retry count' in the Environment and will have to decide whether the message should be retried based on your own logic.
My guess is that the HL7 node has some kind of internal loop which from the looks of it cant be changed at runtime (Setting a value in the LocalEnvironment AFTER the node definitely wont do anything...). I dont know enough about the Broker internal to tell you if its a good idea to THROW your own exception to stop the flow invocation. |
|
| Back to top |
|
|
|
|
