rbeckman-nextgen / test-mc6

0 stars 0 forks source link

Persistant queing not resending on AE. #1743

Closed rbeckman-nextgen closed 4 years ago

rbeckman-nextgen commented 4 years ago

I have a channel set up with a llp listener for hl7v2 message, then based off the hl7v2 message type (ADT, or SIU) i'm using the source transformer to route messages to either the ADT or SIU channels I have setup. The messages are then routed, the ADT and SIU channels are set up as Channel Reader for the source and LLP sender as the destination, with Use Persistent Queues set to yes.

the problem: When either the ADT or SIU channel receives a AE in the MSA, it does not try to resend.

Desired behavior:

The Hl7 v2 MLLP says that on AE (Application Error) messages must be resent indefinatly. only on AR (Application Rejected) should the messages be marked as errored and taken out of the queue because the receiving application has rejected the hl7 message. AE (Application error) means the receiving application is having a problem, which is not due to the messages being sent. The problem could be a data translation, or a critical problem like not being able to connect to a internal database. Thus nothing is wrong with the message, but the receiving application just can process it, so please try again. So can you please fix this so that an AE is always resent when persistant queue is turned on.

Other issue: which if solved could be a work around for this issue. how do I get the channels that use channel reader as the source to forward back the ACK messages to the channel that routed it? I have both a llp listener and a web service that if I could forward the AE back to the source they could resend the original message.

Imported Issue. Original Details: Jira Issue Key: MIRTH-1783 Reporter: jrice Created: 2011-03-11T14:19:16.000-0800

rbeckman-nextgen commented 4 years ago

MIRTH-1783 includes a proposal for this

Imported Comment. Original Details: Author: albertosaez Created: 2011-10-09T08:45:57.000-0700

rbeckman-nextgen commented 4 years ago

I do not agree, maybe you made a mistake?

If you'd take a look in the following document http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol2x_FT_2009-08-10.pdf you would see:

Imported Comment. Original Details: Author: dbe Created: 2012-10-11T00:55:53.000-0700

rbeckman-nextgen commented 4 years ago

In the real world, it's entirely up to the systems in question to decide whether or not messages should be rejected/resent/etc; rarely do systems abide strictly to the HL7 v2.x structure standards themselves, let alone ACK behaviour.

In any case, MIRTH-2118 will resolve this issue by allowing the user to determine exactly when a message gets queued.

Imported Comment. Original Details: Author: narupley Created: 2012-10-11T08:36:45.000-0700

rbeckman-nextgen commented 4 years ago

This is fixed as a side effect of MIRTH-2118. Now users can specify a response transformer to manually queue the message (rather than erroring it out) based on whatever criteria they want (like MSA.1).

Imported Comment. Original Details: Author: narupley Created: 2013-03-26T15:43:34.000-0700

rbeckman-nextgen commented 4 years ago

Tested the above use case using the newly implemented Response Transformer with queuing enabled. Created a javascript step in a destination's Response Transformer that checks for MSA 1.1 == AE and sets the responseStatus = QUEUED. Message queued as expected when an AE response was received.

Imported Comment. Original Details: Author: matts Created: 2013-04-01T15:09:24.000-0700