Resend to Inbound thread

[Rick Martin]

On occasion I need to use SMAT to resend inbound orders into the inbound thread.  I have a couple of problems/questions with this that hopefully some of you have already resolved.

First, the inbound thread uses a modified version of hl7_ack.tcl in its IB Data TPS in order to ACK the incoming messages.  The problem is that when I resend into that thread I really don’t want the other system to get an ACK for a message they didn’t originate.  Is there a way in that proc to know the message was a resend so I can suppress the ACK?

Second, if the thread is not currently connected (Opening instead of Up), the first message will get processed, but will wait to send the ACK, and not process any more of the resent messages.  At least that’s what I think is happening.

Thanks, Rick

Topic

[Jim Kosloskey]

Rick,

Have you thought of resending the messages from SMAT to a file then using the Resend (Inbound post-TPS) option in the Thread Control->Full->Resend control of the Netmonitor?

That way you can bypass any Inbound TPS processing. Of course if there are any wanted inbound TPS procs (like EBCDIC/ASCII) you would lose their contribution.

If this can be a regular situation, you might just want to define a second ib thread which you only start when you need to resend and only have the needed Inbound Tps procs.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Rick Martin]

Jim,

Thanks – I thought about the alternate thread without the ACK tps, but hadn’t thought about saving to a file and resending to the IB post.  I’ll give that a shot next time I need to try a resend.

Rick

[James Cobane]

Rick,

Another ‘trick’ is to up the message priority on the ‘resend’ window; the default is 5120, so raise it above that and then click the resend.  I believe that should send it through without generating acks.

Hope this helps.

Jim Cobane

Henry Ford Health

[David Caragay]

Hi Jim,

Do you know why increasing the priority would skip the ack proc processing?  Seems to me there would not be a relationship between the two.

[James Cobane]

Dave,

I don’t recall why increasing the priority allows the bypassing of the ack generation procedure; it’s just one of the those things I remember and use.  Not much help, I know.

Jim Cobane

Henry Ford Health

[Nathan Martin]

From the ACK script we are currently using:

Code:

#This logic prevents an ACK for resends if the
#Priority of resends is NOT 5120
set priority [msgmetaget $mh PRIORITY]
if !{[cequal $priority 5120]} {
      return “{CONTINUE $mh}”
}

[David Caragay]

Nathan,

If the code you posted is from your actual inbound tps ack proc that would explain why changing the priority would cause the ack not to be sent.  Is this an inhouse developed tps ack proc?  If it is a delivered proc, what is the name?   This logic is not included in our ack procs (custom) so I’m guessing it was introduced some time ago in a delivered Quovadx ack proc.   If this is the case, changing priority may or may not skip ack processing, depending on how the ack procs are written.

[Nathan Martin]

RawHl7Ack.tcl (with matching proc name)

Inbound, delivered I’m sure, or gleaned from the mailing list.  It precedes my time.  (I did remove a superfluous x1c from the end of the ack it generates.)

For fun, here is a very simple script that resends inbound messages and takes advantage of the message priority trick to avoid flooding ack’s back to the connected system.  Used for testing, mostly.

Code:

#!/bin/ksh
# Resend new-line delimited file, inbound side.
# Args:  {new-line file} {thread name} {process name}
# NOTE:  File should be full path or relative to process’ work directory.
# WARNING:  Use with caution.

hcicmd -p $3 -c “$2 resend ib data 5119 $1 nl” 2>&1

[David Caragay]

Nathan,

Looks like that rawhl7ack.tcl has been around for quite a few years.  Interesting way to avoid creating an ack.  We don’t include this code fragment in our tcl ack procs but maybe we’ll consider it in the future.  Thanks for the infomation.

[Author]

Replies