New interface kills some messages

[Gena Gill]

I have a perplexing issue.  

I’ve created an interface to send ADT messages to an IP address and port 5001 to an .ASP provider.  When I turn the interface on, all of the messages that I want are sending to the .ASP.  The problem is that if I turn on that interface, A02, A03, and A05 messages STOP going to several other interfaces pointed to an IP’s and ports that are “in-house”.    One of the affected interfaces is RAW, the other has a translation.

As soon as I stop sending messages to this .ASP ip address, then the A02, A03, and A05 messages will start processing again to the in-house interfaces.  

None of these are sending to the same port numbers.  Is there a “range” of acceptable ports?  We wondered if this port #5001 that the .ASP has asked us to send to could be outside of an acceptable range.

Any ideas?

Topic

[John Hamilton]

I suspect it is a routing issue in your system configuration.

Are you stopping just the outbound thread or are you stopping the process and removing the new thread then restarting things.  Or are you just stopping the thread that you suspect is the the problem.

I have used and still use port from 4000 all the way to 45000 with no issues to date.

To get you more details on what the issue is i would need to see your NetConfig file with and with the problem.  Email me if you wish me to look at it.

[Jim Kosloskey]

Gena,

For the non .ASP integrations, are only A02, A03, and A05 Event Type messages being routed or are there other Event Type messages being routed as well and only the A02, A03, A05 Event Type messages are being affected?

I typically like to use ports above 10000 and outside the ephemeral range.

Are the messages not being delivered being held in the Recovery DB? If so in what state?

Have you turned up the EO and viewed the process log(s) to see if there is any indication as to what might be happening?

Jim Kosloskey

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

[Gena Gill]

For the non-ASP’s, I’m sending all ADT message types.  For the ASP one, I’m sending everything but A05, A28, and A31.

Everything in the Recovery DB, and when watching the process logs, appear normal.  The only way to see the problem is on the back end

when the patients aren’t being Discharged/Transferred or when running multiple saves and comparing the messages at each step.

Here’s the plan…  I’ve now completely deleted that thread, and tomorrow will re-build it from scratch.  Before I turn it on, I will stop and start all of the processes that were affected.  Last week, I was only bouncing the process that this new thread was on and the process that was sending.  I’m also about due to re-initialize the database (windows server), and may do that before setting all of this back up again.  On our windows engine, I always seem to have problems when I’ve been doing a lot of building and testing, and that’s the case this time.  I don’t have that problem on our Cloverleaf engine that’s on our Unix server.

I appreciate the help!

[Jim Kosloskey]

Gena,

I hope all goes well.

I am just curious, if you have a Unix Cloverleaf(R) why would you have Cloverleaf(R) on Windows?

Thanks,

Jim Kosloskey

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

[Gena Gill]

Jim

We had a Unix Cloverleaf engine, then when we implemented our core vendor solution, they provided interfaces through Cloverleaf on Windows as part of their solution.

[Gena Gill]

Thanks to Jim’s wonderful help!

Yes, the problem was that I was crossing processes with the translation and it was confusing everything.  As soon as I sent the ADT in a RAW state over to the receiving thread in a different process, then translated the message while sending to the thread for the application, doing the translation in that new process, it worked without affecting any of the other threads.

Thanks again for all of your help.

[Author]

Replies