Should the vendor flush their interface?

[Chris Blair]

Dear Techies,

Can I get a sanity check here before bring this up with the vendor? I’ve been testing a new TCP/IP interface and it’s been very spotty. I’d send it an HL7 message and wait, and send it again and wait, and again and again. And then, all of a bunch of acknowledgements all at once.

It turned up the noise on the engine output, and I see all of the acknowledgment messages strung together in the hex dump and then it seems that Cloverleaf is gracefully breaking up each ACK and processing them seperately.

I’m thinking that they’re acks are building up in their outbound buffer and then when it gets full, it gets dumped to me all at once. Does that sound right to you?

Would the alternative be to keep track of multiple outbound messages using tcl and a database and just match up each ack as it comes in. It would sure make it difficult to build in any kind of a timeout of the outbound message. Has anyone gone down that path?

Thanks.

Topic

[Jim Kosloskey]

Chris,

It would be my opinion the receiving system is not managing their buffer properly.

That could be in the buffer they receive the messages (in other words they wait until they get a buffer full condition before processing the messages) and that introduces the possibility of seeming to get a short message.

Or it could be as you suspect they are not sending the acknowledgment(s) until the outbound buffer is full.

In any case, that is not the way things are desired and the receiving system should figure out where their problem is and fix it in my opinion.

I think you are quite sane.

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

[John Hamilton]

IF you just send one message and wait until forever, do you get the ACK ?

Or will the remote system always wait until it has X ack to send before it sends thems.

[Chris Blair]

It looks like I may be getting a short message. In the hex dump of ACKs, it looks like I’m getting about 4.5 messages, but in the next dump I don’t get the rest of the last message. I’m guessing the vendor lost it.

Here’s another piece to the puzzle. When they send me an order, they start waiting for an ACK. The IE transmits the ACK and they’ve confirmed via a software sniffer that the message is sent back to the system. But, they’ll keep sending the same order until eventually they see their ack. They’re using Intersystems Cache’, but it’s not clear how involved with TCP buffers that software gets.

John, I turned off the auto-resend. I’ll send one message per hour and report back when I get my response(s). It’s been 20 minutes since I sent my first one.

[Jim Kosloskey]

Chris,

I think that used to be MUMPS.

It has been a long time since I had anything to do with MUMPS but my dim recollection is device handling was not up to snuff.

Whatever, the other pieces of information you gave indicate to me they are not properly managing their buffers.

They need to fix it – there is not much you can do (IMHO).

What is the name of the vendor and the software product? Maybe others have had experience with the vendor and can assist.

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

[Michael Hertel]

In your dump, are the ack messages wrapped with and ?

[Chris Blair]

It’s a VHA package called HLO. They’re documentation says that do not support synchronous responses, but IHS tweaked the package to make it work. I think that may be the source of our problems.

Michael, each message does have those encapsulation characters. The only thing that I don’t see that I expected to see what a new-line character after the final segment carriage return.  I don’t think that’s an issue, but maybe their software would use that to trigger a buffer flush…?

[Michael Hertel]

Could be…

[Robert Milfajt]

Chris, I worked as a programmer for VHA for 10 years (many years ago) and am quite familiar with MUMPS/Cache.  If you want to send me the code off-line, I can take a peak at it and tell you where it might be going wrong.

With MUMPS (commands in parenthesis), you open (O) the port when you start the interface, use (U) it to write (W) and read (R) from, and close (C) it when you are stopping the interface.  The rest of the communication is handled at the OS level.  

What version of Cache and OS are you running?

Bob

rmilfajt@nmff.org

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Chris Blair]

Thanks Bob, I appreciate your offer. It’s actually another company that handles the MUMPS/Cache end so I’ll have to see what they want to do.

Did you have consistent success using MUMPS to perform synchronous replies? I’m starting to fom the impression, that’s its better to have 2 one-way pipes.

And to finally answer John’s question, I never get a response unless them I repeatedly send them the message.

[Jim Kosloskey]

Chris,

I don’t think you want an asynchronous message delivery technique for acknowledgments (one thread for messages another for acknowledgments).

I think that is a guarantee of lost messages.

Doing it that way relies on the parties managing their buffers properly and as you can see the other side is having trouble doing that.

It appears absolute that the way they have things configured/programmed now relies on a full buffer before any processing takes place.

I took a quick look at the Cache Web Page and it appears synchronous message delivery should be accomplishable within the Cache product.

If it were me, I would set the expectations that I will send a message and wait for a reply, they will turn their port around upon receipt of one message and send a reply. Then I will send the next message and so on…

Anything less is a problem they need to rectify.

Try posting in a separate post on here with the specific vendor and product name to see if anyone in the community has experience with this vendor and product.

You might also ask the vendor if they have clients they know are using Cloverleaf(R) with which they are interfacing.

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

[Robert Milfajt]

I agree 100% with Jim.  I have seen five separate MUMPS systems and their code successfully deal with sychronous communication.  Those systems are the VA HL7 package, MIDAS, SunQuest/Misys lab, IDX and Epic.

Get it to work the right way and your maintenance life will be so much easier.

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Chris Blair]

Sorry for the delayed response, I took some vacation.

I appreciate all the expert advice, I will definately heed your warning.

Thanks again!

[Author]

Replies