API disconnecting and reconnecting

[Ray Mullen]

Hi ,

Just looking for a few opinions from other cloverleaf users. We are currently implementing a new interface that will pick up hl7 lab messages and route to other application. 99 % of our interfaces are configured as tcpip or hl7 mlp_tcpip and all work well.

This new interface (which we are currently testing) has been configured by the supplier to disconnect and only reconnect when messages are available to send which means that our interface thread for this new interface is constantly in an “opening state” as the new supplier’s api is constantly disconnecting when it has finished sending a message.

The supplier has said that this is quite common but not one of our existing live tcpip interfaces works this way. All our interfaces are constantly up and only go to opening if the connection is lost e.g the api is disconnected.

I can see this interface being a problem in the future. During testing, when I cant make a connection it is hard to know where the problem lies, as the thread will only be up while messages are going through.

I would prefer to have this new API connected and UP at all times, but just looking for opinions from others?

Thanks in advance

ray

Topic

[Jim Kosloskey]

Ray,

We insist our connections be persistent. That is we do not agree with this nonsense of connecting and disconnecting with each message or even staying connected only as long as there are messages to send.

To me this is indicative of ‘old school’ telecommunications – like we used to have to do 30 years ago due to machine, network, and software constraints. This should not be necessary in today’s world in my opinion.

We too have many vendors that claim this should not be a problem. We pressure them to find an alternative and in many cases they just happen to find an ‘obscure’ configuration option that accomplishes what we need.

By the way if you are not uncomfortable with naming the vendor and product please do so the rest of us can be aware of this potential issue with this vendor.

My position is stick to your guns!!

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

[Ray Mullen]

Jim Many thanks for your reply.  I hopefully will not be forced to accept this api in its current state. It is great to get others opinions, hopefully they will come around to changing this api for me, i’ll keep you posted if they do.

[Troy Morton]

We have an application which has similar strange behaivor.

[Max Drown (Infor)]

We have several that do not stay connected. They connect to send data and then disconnect.

-- Max Drown (Infor)

[Ray Mullen]

Hi Thanks for the replies, I feel that the best way to have the interface is persistent and not disconnecting and reconnecting after each message , it makes much more sense this way. Even for monitoring the threads it is much easier.  

thanks again

[Russ Ross]

I had this problem with a BizTalk interface to cloverleaf this last year.

Like Jim said we do our best to not allow such non-persistant interfaces and make that an expectation.

However, I too have been faced with a non-persistant interface challenge when told it was a inherant design flaw of the interface itself (BizTalk in this case).

I don’t know if there really was a design flaw or there was a lack of knowing how to use the product.

We worked together to band aid the darn thing by generating a connect message that will get sent after 60 seconds whenever there is no connection.

This was a good enough compromise for this interface because it stayed connected once a message was sent but wouldn’t connect until the first message was sent.

Russ Ross
RussRoss318@gmail.com

[Bob Richardson]

Greetings,

Russ, when you say “connect message” is this a case of pulsing out a dummy message to keep the TCP socket up and running or do you send something more exotic at a lower level?

I ask as our organization is looking at BIZTALK to do some revenue interfaces and of course want someone to support it…!!

Thanks in advance for your response.

[Russ Ross]

When I say connect message, a mocked up dummy HL7 connect message is sent by BizTalk across the interface.

In my specific case this was an allergy interface that sends ADT^A60 messages to cloverleaf where the word “CONNECT” was placed in MSH-10 which I look for and filter out those messages preroute.

My story to share about BizTalk was the people that had access to the BizTalk piece of the integration kept telling me it was designed as a web service interface tool and not a real-time persistant tool.

In any event they only new how to use it for web services integrations thus my work around.

The integration engineer was literally told he had to use BizTalk and pretty much hated it.

At least I assumed he hated it when he told me he would rather write the interface from scratch than have to use it.

Ironically I worked with one of their team members years ago who wrote a TCP/IP real-time interface from scratch for DMS and they had that in their back pocket to drop in place.

I was told the consulting group had a conflict of interset causing a bias towards the less suitable BizTalk solution.

I suggested if BizTalk was being chosen for the business rules then use it for that and use something better for the interface data movement.

The group this mandate was coming from was used to web services and had little or no experience with what a real-time persistant interface was.

For a while they thought I was making things up when I told them what a real-time persistant interface was because they had never heard of such a thing; I’m not kidding.

I’m not certain but the HL7 standard might specify that an interface be persistant and when I hented at that as a standard and that it was definetly a hospital wide standard by adoption that seemed to help satisfy them to put the effort into a real-time persistant solution even though they still wondered if I was making this stuff up.

They didn’t even want to use cloverleaf and do most everything point to point but were unable to get BizTalk to do a real-time persistant interface to any commercial down stream systems like Cerner or Centricity.

They knew I did this all the time and as a last resort used me to figure out a way to make it work.

I observed after getting them around this one they have used my work around and gone back to their point to point practices.

It is ashamed they wish to be another silo within the enterprise but we have so much more integration work flowing in than we have people to satisfy the demands.

By the way, I found using hcitcptest at the command prompt to be very helpful to test the various message senarious that BizTalk had to be jury rigged to do such as:

– resend message if no ACK received in time out period

– send email/pages when NAK occurs

– cycle BizTalk interface and have it connect when message are queued

– cycle BizTalk interface and have it connect when no messages are queued

– cycle cloverleaf side of the interface when BizTalk had no messages queued and have it connect

The guys I worked with seemed to have difficulty at first getting BizTalk to use a single dedicated port.

I tried multi-server to help see if my suspicion about web services behavior was correct and that partly functioned but they worked with me to overcome until we got the normal one port dedicated server working.

My co-worker Jim Kosloskey shared with me that other hospitals have been dissapointed with BizTalk and knew of at least one that tossed it in the trash can.

I have not had direct hands on usage with BizTalk, but would proably cringe at the thought of doing another BizTalk interface.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies