Ack/Nak handling

[Michael Lacriola]

I have a situation where the vendor will Nak a HL7 message when “their” application cannot assign a value to it because of a broken database connection. There’s nothing wrong with the format of the message.

What I would like to do for this particular thread is: when I receive an “AR” in the MSA segment, I would love to put the outbound thread on hold and page someone on the first “AR”. That message would then go to the error DB (know how to do). I know how to page someone through a tps proc, know how to use the tps send ok and TPS inbound reply stacks. What I don’t think I can do is put that thread on hold from within the tps inbound reply.

Anyone have any ideas that would like to shoot my way?

Topic

[Michael Hertel]

I have to deal with an interface just as you describe.

Instead of erroring the message, I have a proc with the code below that runs under TPS inbound replies that runs before our generic ACK checker proc. I look for AR’s and kill the reply before the ACK checker has a chance to validate it. So the interface ‘times out’ on the Cloverleaf side and resends the message each time an AR is encountered. There is counting logic and I email “them” and me every 5 AR’s. You can page too.

When the next AA comes in, the counter resets. This way I don’t have to worry about it, “they do!” 😈

Code:

run {
keylget args MSGID mh
set msg [msgget $mh]
set response [vm_getHL7 $msg MSA 0 1]
if {[cequal $response AA]} {
set ARcnt 0
}
if {[cequal $response AR]} {
incr ARcnt
if {[expr $ARcnt % 5] < 1} { set notifylist "pgmmjh@vmmc.org pgmxyz@vmmc.org interfaceengine@abc.org" exec echo $msg | mail -s "$HciSite - ABC AR response(s) received $ARcnt" $notifylist } echo $module - ABC AR received - Message killedn$msgn return "{KILL $mh}" } lappend dispList "CONTINUE $mh" }

[Michael Lacriola]

Yes, something like that. I’m thinking that if await replies is on and timeout set to -1, when I receive the first AR, send an email and kill the reply using a KILL instead of KILLREPLY, my messages will  back up (which is what I want) because it will still wait for a valid reply.

Does this logic sound good? It will be reset once the thread is bounced or until I get a valid “AA” reply response.

[Michael Hertel]

Retries should = -1 (Under Outbound data) so it will resend the same message forever.

Timeout should be 30 or something greater than -1.

If you set Timeout for -1, then it will wait forever and not try to resend.

That’s bad. That’s why I watch my email and if I get more than 3 notices (15 AR’s @ 30 seconds each), I call ‘the other guys’ and ask them wassup?

I’ll attach the full proc if you want.

The logic is sound and works well for us.

-mh

[Michael Lacriola]

No, that’s ok, the code fragment you presented is fine. I having something similar in other areas. It’s making user that it resends the message forever until it gets an “AA” response that’s important. The other stuff is fluff.

Thanks for the input.

[Brian Goad]

MH,

Do you all use recover33 with that proc?

TIA,

Brian

[Michael Hertel]

Yes, this goes before the ack check proc.

Our’s is named tps_checkhl7_ack (or something like that).

It originally came from the recover33 procs.

-mh

[Dick Bly]

Michael, you can put a thread on hold from an inbound reply, but in order to start the data flowing again you must stop and start the thread. DO NOT release the hold with the GUI or the message that caused the hold will not be sebt until the thread is cycled.

do the KILL on the reply instead of the KILLREPLY to keep any further messages from being sent, then exec the hcicmd in the background using & at the end of the line to put the thread on hold. the thread will stop sending because of the KILL and then go to hold state.  will work on unix and windows.

[Author]

Replies