Non-persistant Connection – Server

[Jared Parish]

I have a vendor (MedOne Hospital Physicians) sending HL7 messages to Cloverleaf 5.7 Rev1 (redhat).  They’re stating they are getting a “Connection actively refused” error after trying to send the next message in their queue.  I have my side setup as a PDL-TCPIP server and to ACK each message.

    I ask how their system is setup/programmed.  They stated that they start a new connect for each message, wait for an ACK, then close. Repeat. I changed the Auto-reconnect reopen time to a lower setting.  That seems to have help, but, didn’t resolve the issue.

Any Ideas?  Anybody worked with MedOne?  I don’t have a problem with any other inbound connect.

…off to review documentation.

- Jared Parish

Topic

[James Cobane]

Jared,

I would recommend changing your inbound connection to a multi-server configuration.  It is likely that they are not fully closing the connection before attempting to open it again.  By changing it to multi-server, you’ll allow them to connect again, even if the previous connection is still open (i.e. not fully closed).  You’ll need to modify your ack proc to ack back on the appropriate client connection.  Simply add the following line before before your return of the disposition list:

msgmetaset $obMsg DRIVERCTL [msgmetaget $mh DRIVERCTL]

(Assuming that $obMsg is the message handle of the reply you are sending back and $mh is the message handle of the inbound message)

I’ve had to do this on a few threads for some vendors.

Hope this helps.

Jim Cobane

Henry Ford Health

[Jared Parish]

James,

    That worked perfectly.  Thanks for your help.

Thanks very much,

- Jared Parish

[Richard Hart]

Hi Jared.

It may be an idea to close the connection after you’ve written the message, we are doing this now as we are testing the multi-server socket to see if it will replace the a Perl program that currently manages our mutli-socket interfaces.

This works for normal sockets, BUT, there is a (relatively) large overhead loading the PDL when the port reopens!

This can be accomplished, (in 5.6 and I guess higher) by ‘ticking’ the ‘Close after write’ box from the Thread Properties and using TCL to create a new message to close the connection.

eg

                   #

                   # Send a message to close the port after use

                   #

               set myMsgPortClose [msgcreate]

               set myDriverCtl {}

               keylset myDriverCtl CLOSE 1

               keylset myDriverCtl WRITEZERO 0

               msgmetaset $myMsgPortClose DRIVERCTL $myDriverCtl

              lappend myDispList “CONTINUE $myMsgPortClose”

[Paul Johnston]

Hi Jim ,

We are experiencing, I believe the same issue as Jared , and would like to try your solution .

I am not a expert in TCL . I have added your line in my code ( below) . Can you confirm I have the correct location. ?  Hopefully I have included enough of the code .

Code:

…..

#
# Now build the ACKNOWLEGEMENT message
#
   set ACK “MSH$fldsep$sepchar$fldsep$rx_appl$fldsep$send_fac$fldsep”
   append ACK “$send_appl$fldsep$rx_fac$fldsep$dttm$fldsep$fldsep$mtype$fldsep”
   append ACK “$rx_ID$fldsep$p_type$fldsep$version$fldsep${seq_no}r”
   append ACK “MSA$fldsep$ack_type$fldsep$rx_ID$fldsep${ack_msg}r”
   set obMsg [msgcreate -type reply]
   msgset $obMsg $ACK

# NEW    msgmetaset $obMsg DRIVERCTL [msgmetaget $ACK DRIVERCTL]    

#
# Continue original message and send response
# unless there was an error, then kill original
#

   if $ackflag {
       return “{CONTINUE $mh} {OVER $obMsg}”
   } else {
       return “{KILL $mh} {OVER $obMsg}”
   }

……

Thanks for your help .

[James Cobane]

Paul,

I think you need to change the line

msgmetaset $obMsg DRIVERCTL [msgmetaget $ACK DRIVERCTL]

 to

msgmetaset $obMsg DRIVERCTL [msgmetaget $mh DRIVERCTL]

to obtain the DRIVERCTL info from the original message.  Then, as long as you set the DRIVERCTL information prior to returning the disposition list, you should be good.

Jim Cobane

Henry Ford Health

[Paul Johnston]

Hi Jim ,

I have changed the line as you mentioned but I am not sure how to set the

DRIVERCTL information.  Do you have an example ?

Thanks again.

[James Cobane]

Hi Paul,

The line that you changed to:

msgmetaset $obMsg DRIVERCTL [msgmetaget $mh DRIVERCTL]

will value the DRIVERCTL metadata of the reply message you are sending out with the appropriate information.  It captures the DRIVERCTL information of the original inbound message (assuming the $mh is the message handle of the original inbound message) and sets the DRIVERCTL information of your outbound reply (assuming $obMsg is the message handle of the created reply) appropriately.  With this information, the engine will send the reply back out to the client port that the inbound message was originally sent on.  So, that should do the trick!

Hope this helps.

Jim Cobane

Henry Ford Health

[Paul Johnston]

Thanks again Jim ,

I understand the logic now with setting DRIVERCTL .

I have modifed our HL7 ACK tcl to include with the DRIVERCTL statement . It probably is working but after further investigation I believe we are experiencing a somewhat different issue.  I am examining it further.

Thanks for your help.

[Author]

Replies