Generate route

[Marian Michniak]

I’m trying to route a message to one of several interfaces without routing to all of them and then killing the message.

Has anyone used “Generate Route”?

Thanks

Topic

[Marian Michniak]

Hello

I see that my previous post isn’t very clear about my issues and what I am trying to do.

I have set up an interface using HTTP Client protocol.

First, I have an incoming tcp/ip interface sending X12 270 elibility transactions to Cloverleaf. I then wrap the 270 and post it to a 3rd party vendor using HTTP Client.

The 271 response comes back and sent back to Cerner via tcp/ip.

The issue that I am having is that this is all single threading. The 270 goes out and then the 271 has to come back before the next 270 goes out. The problem with this configuration is that many users are on this at the same time causing a bottleneck especially when some responses take a long time to return.

I tried a work around where I have created 10 HTTP Client interfaces. The inbound interface has raw routes to all 10 of these clients. The clients are numbered 0 thru 9.

I have created a tclproc to distribute the 270s into a different client using the last digit (0-9) of the control number in the 270. Basically, the proc is supposed kill the message to all of the clients except for the one that matched the control number.

The 271 then comes back and gets routed to the 271 oubound tcp/ip interface. All ten of the clients are routed to this interface.  

The process to send the message to the proper client is working but everything still acts as if it’s single threaded. I’ve tested with 4 nearly simultaneous message expecting to be logged into web services 4 times at the same time but it is still logging in once, wait for the 271 and logging in with the next 270.

Is there a way to configure this interface send simulataneously or does my solution look incorrect?

Basically the setup is:

                                      client 0

                                      client 1

                                      client 2

                                      client 3

                                      client 4

FROM_270                        client 5                        TO_271

                                      client 6

                                      client 7

                                      client 8

                                      client 9

 Thanks

[David Barr]

I suspect that the HTTP protocol driver isn’t multi-threaded. Each thread is probably blocking all of the other threads in the process until it gets a response. As a quick and dirty solution, you could try putting each of your clients in a separate process.

[Jim Kosloskey]

Marion,

Is your inbound tcp/ip source of the 270 synchronous or asynchronous message delivery? In other words does the source system wait for a X12 acknowledgment before sending the next 270 (it should if following the X12 standard)?

If so you will be limited by that action such that even if you could make multiple connections to your destination system you will only receive one 270 at a time from te source system.

Most 3rd party eligibility services also only allow one connection at a time and are also synchronous (unless it is a batch operation). If that is true with your vendor then even though it may look like you are making multiple connections only one at a time is being honored thus also ending up only handling one 270 at a time.

However, many services will do a partial synchronous partial asynchronous exchangve where the acknowledgment for the 270 is just simple validation (should be rather quick) and the 271 actually arrives over another connection and may be in any order. I have not seen this with Web based services too much as many of the Web Services weenies apparently can only think in terms of synchronous exchange.

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

[Bob Richardson]

Greetings,

We have been doing 270/271 HTTPS interfaces to two separate payers for the last several years and yes ! the reponses are single threaded, that is, one post, one response.

Our very high level solution was to set up separate processes that each contain ONE HTTPS client that services ONE 270 POST transaction.  The inbound routes to an intermediate “distributor” thread that decides which HTTPS service process gets the next 270.   All 271 responses are routed to a collection basket (another thread) that (in our case) ships off the responses to a multi-connect type TCP/IP thread on another site that then routes to the original sender of the 270 (again, in our case an Epic systems interface).  We only need three separate but equal processes at this time:  each payer has their own site to avoid consuming resources that would impact the other payer.

Note:  when the HTTPS POST is in progress the Cloverleaf process is tapping its foot as NO OTHER work is done UNTIL the POST arrives.

We use a TclCurl custom driver to do the POST work; and a TCL Inbound Reply TPS proc to handle the 271 response.  We do the latter due to one payer who can send back garbage like Java program code when they have an issue and we need to crank out a default 271 code 80 type response.

Anyway, I have attached a screen shot of one of our payer NetConfigs to give you an overall sense of what we did.  We have a site that decides which payer site gets a 270 based on examining the ISA08 field for payer identification and using a Trxid proc to route to the payer site.

I hope this helps you out.

PS: Ignore the “requeue” thread (AVLifs270REQ) which functions here to resbumit 270s whose responses indicate an issue at the payer like a timeout or service not available.  The Reply TPS decides who gets requeued and at what frequency.  Complexity to ignore at this time.

[Marian Michniak]

Jim / Bob

Cerner tells that their process is asynchronous. They can send multiple 270s in quick succession without having to wait for a 271. They can also take the 271s in whatever order they return. That was an issue in the beginning but have corrected that issue.

It looks my my configuration is similar to the one that you have posted. The onlyu difference is that I do not have any intermediate threads to do the routing to the different queues. I use the last digit in the ISA13 to determing which queue the 270 goes into.

Do you think that changing the inbound tcp interface to raw route to an intermediate before doing the routing?

I have attached my configuration. Please look at the interfaces in the lower left.

Thanks

[Marian Michniak]

Thanks for your help.

I have split the POST into different processes. Now my new problem is that I have to send the 271 back thru any one of the ten routes back to one reciever thread that will send the 271 out to Cerner. I tried to just route the 10 back to 1 interface and needless to say, it created a mess.

I’m guessing that I need to set up a multi server. Unfortunately, we don’t have any of these running on our engine.

Have you had a chance to set one up?

Thanks

[Author]

Replies