ACK messages ending up in the error database.

[Robert Denny]

We have some issues with new interfaces. Some get errors related to ACKs.

does any have information, or know of a configuration setting that can remove these errors? We are always having to go in a delete them from the error database.

REPLY

   msgClass          : ENGINE

   msgState          : Unsupported Trxid (101)

   msgPriority       : 5120

   msgRecoveryDbState: 3

   msgFlags          : 0x8002

   msgMid            : [0.0.42825112]

   msgSrcMid         : midNULL

   msgSrcMidGroup    : midNULL

   msgOrigSrcThread  : t_ecardio_ord

   msgOrigDestThread : f_epic_card_ord

   msgSrcThread      : t_ecardio_ord

   msgDestThread     : f_epic_card_ord

   msgXlateThread    :

   msgSkipXlate      : 0

   msgSepChars       :

   msgNumRetries     : 0

   msgGroupId        : 0

   msgDriverControl  :

   msgRecordFormat   :

   msgRoutes         :

   msgUserData       :

   msgStaticIsDirty  : 0

   msgVariableIsDirty: 0

   msgTimeStartIb    : 1433186737.866(12:25:37)

   msgTimeStartOb    : 1433174045.169(08:54:05)

   msgTimeCurQueStart: 0.000(16:00:00)

   msgTimeTotalQue   : 0.000

   msgTimeRecovery   : 1433186737.867(12:25:37)

   msgEoConfig       : 0x(nil)

   msgData (BO)      : 0x0xf6b15110

   message           : ‘MSH|^~&|EPIC|GSR||ECARDIO|20150601122535|13406|ORM^O01|122821|x0dMSA|AA|Px00’

Topic

[Sergey Sevastyanov]

Robert,

This looks like malformed ACK. It has messages ORM instead of ACK.

I don’t see msgType. Is the uppercase “REPLY” in the beginning a value of msgType that you didn’t paste?

Is your sending thread waiting for replies?

Depending on your settings (Waiting for reply checkbox) this message either treated as a reply or as inbound message.

If it is treated as ACK I wonder that Unsupported TrxID is causes by wrong message type. I am not sure how CL processes ACKs (if it cares about the message type in MSH). I looked at old recover.tcl and it seems it doesn’t care about MSH segment, only MSA. If it is still the case then ACK or ORM shouldn’t make any difference.

If it is treated as an inbound message then you may not have a route defined for ORM^O01.

I would ask your provider to change ACK type to ACK and see if this helps.

[James Cobane]

I suspect that because this is an ORM vs. ACK, it is hitting the error database because you likely don’t have a route configured for an ORM message in your route replies set-up.  Or you aren’t handling a non ACK message in your reply handling procs.

Jim Cobane

Henry Ford Health

[Max Drown (Infor)]

You need to kill the ACKs unless you intend to route them back, which is rare.

Under the thread properties, the Outbound tab, make sure Await Replies is checked, and then configure an ACK-handling proc in TPS Inbound Reply. The simplest proc is hcitpsmsgkill which just confirms an ACK was received for flow control, however you can use cl_check_ack or any custom proc for examining and handling different types of responses. The key point is that your proc must kill the ACKs when it is done with it, unless you intend to route the ACK somewhere instead.

-- Max Drown (Infor)

[Robert Denny]

I think its because we do not have the kill reply configured with this interface.

we will set that up and see if these errors go away.

thanks to everyone who offered a suggestion on this topic. 😀

[Robert Milfajt]

My experience here says if you make sure the thread has outbound only checked on the inbound tab, then you won’t try to route replies, which is why you’re getting the Trxid error in the first place.

Hope this help,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[James Cobane]

I believe the ‘Outbound Only’ option only handles (ignores) the messages that come in when the engine isn’t expecting a reply.  If the engine is awaiting a reply, anything that comes in is treated as such and needs to be dealt with (either via Route Replies or proc).

Jim Cobane

Henry Ford Health

[Max Drown (Infor)]

That is correct, Jim.

-- Max Drown (Infor)

[Robert Denny]

We have not received any ACKs in the error database for that first example.

Today we did get one on an outbound thread for an outgoing ADT message.

On that feed we had the kill replies proc configured on the inbound replies section of OUTBOUND Tab.

We did not have the OUTBOUND only option selected. We did try selecting that option and will see if we get any more in the next few dates.

We seem to get one or two a week on that thread and it is a very busy thread, so most ACKs are processed without error.

[Author]

Replies