Resends with protocol UPOC

[Travis Alexander]

I’m having issues with a ‘Write TPS’.  PROTO isn’t a valid disposition for that UPOC.  I’m having difficulty trying to figure out how one is suppose to trigger a write failure and have Cloverleaf resend the message.  The user guide says this:

“If a protocol write fails, it can be re-queued to the outbound post-TPS queue for a number of retries before the write is considered to have failed.  SENDFAIL controls additional retries if TRYAGAIN is set.”

I can’t find reference to SENDFAIL or TRYAGAIN to say how to trigger them.  Is it a meta data flag?

Travis Alexander

Laboratory Integration & Implementation Services

Mayo Medical Laboratories

Phone: 619-808-7934

alexander.travis@mayo.edu

Topic

[Jonathan Hamilton]

You can’t use PROTO in the UPoC Write TPS.  You can only use CONTINUE to indicate the message was delivered successfully and move on to State 14 (Send OK TPS), or you can use ERROR.  The ERROR disp is a little different than all of the other TPS stacks as it will put the message back into the OB Post TPS Queue for re-processing.

For our custom protocols we typically use the ERROR disp to requeue the message, issue a shutdown command for the thread, then 20 minutes later an alert restarts the thread to attempt redelivery of the failed message.

I normally do not use the Retries setting in NetConfig, instead I do all error handling in my Tcl code.  But I believe if you set the retries to 3 after the third attempt with ERROR, the message would go to the Send Fail TPS for processing, then the next message would begin processing (depending on Send Fail’s code, if any).

[Nathan Martin]

Too bad.  The documentation (QDX 5.3) says that PROTO and SEND would work:

PROTO Places on outbound post-TPS queue.

SEND Places on inbound post-TPS queue.

I spent some time working on a Write UPOC designed to feed an oubound query through an external program and send back a response message.  I had to give up and switch to http-client protocol.

An http proc can create and OVER the query response.

Now, besides being able to send the response mesage back in a timely fashion, I can use recover33-style procs and not lose any query messages if the external program dies.  (I do end up having to recreate the reply as a data type after the kill_ob_save, but it works well enough.)

Thanks,

Nathan

[Author]

Replies