Inter-Siter Routing with Cloverleaf 5.8

[Joe Sellers]

Does anybody have any experieince with or documentation on the new Inter-Site routing feature in 5.8?  We’re looking at setting up a “router” site where we receive generic ADT/ORM/ORU/SIU feeds from our Cerner EMR and then forward them to various other sites for translation.  We’re trying to reduce the outbound traffic from Cerner, as well as simplify the Cerner route script management.  I’m wondering what makes the Inter-Site routing different than using traditional IP-to-IP routing between sites and what performance benfits there are, if any.

Thank you.

Topic

[James Cobane]

From the experimenting I have done with inter-site routing, you route to the destination (which is the final outbound thread), and not another inbound (to do additional routing/Xlation).

[Joe Sellers]

Yep, that makes perfect sense.  That’s what I’m seeing in my testing too.  Unfortunately, we were hoping ISR could be used to create the second scenario and reduce some of the load on the processor and NIC.  Perhaps a future enhancment…

Thanks!

[Jim Kosloskey]

Joe,

We don’t have 5.8 yet but we do what you propose in 5.6 using the localhost technique.

If I am not mistaken the new facility still utilizes TCP/IP prots under the covers so I am not sure there would be much difference from a consumption standpoint (we actually saw a significant improvement when I finally convinced the folks here to go to multi-site using the distribution technique you describe).

However, with the new facility couldn’t you simply OVER the message on the receiving thread then route from that thread to whereever? So you would have your public thread which is an outbound thread but all the messages get over’d to the inbound side and then routed from there.

Since I don’t have 5.8 yet I cannot try that to verify.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[David Barr]

Using “OVER” wasn’t working for me. We’re having Mckesson file a bug report with Lawson for us.

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=5615&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=5615

[Joe Sellers]

Thanks everyone for your help and suggestions.  For simplicity’s sake, we’ve decided to go with the tried and true method of inter-site routing over TCP/IP via localhost:port combinations.  With the desire to do additional routing and translation in the destination site, it seems as if we would be intorducing additional points of failure in the message flow with the new ISR feature.  Thanks again!

[Jim Kosloskey]

David,

Thanks for the reminder. This is definitely a bug in my opinion. Otherwise Synchronous exchanges could not take place reliably.

When I finally get a 5.8 environment (or later) with which to experiment I intend to check the facility out rather thoroughly and if this is not corrected at that time, I will add my bug report.

I see many potential additional benefits not the least of which is now that the MID is fully utilized, one should be able to trace a message by it’s MID throughout its enginge travels from arrival to final delivery.

So to have this working properly will be a benefit in my opinion. Once that happens, I will encourage my organization to not only make this the de-facto standard for architectural design but to re-filt existing integrations to leverage the capability.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[James Danley]

If you going to do inter site routing using OVER, make sure that your Destination Name is the same name as the destination thread’s name. And also set SOURCECONN to the same. Then the OVER will work.

James

James Danley | Learning Consultant, Principal
James.Danley@infor.com | http://www.infor.com

[Jim Kosloskey]

James,

Thank you – that is very informative and something I will note for when we get to a release that supports inter-site routing.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[David Barr]

James Danley wrote:

If you going to do inter site routing using OVER, make sure that your Destination Name is the same name as the destination thread’s name. And also set SOURCECONN to the same. Then the OVER will work.

James

(edit) I misunderstood this the first time. I’m testing it now.

[David Barr]

Ok, I got the OVER to work. Thanks to James for pointing out that thread names were the problem. The error I was getting was because the original source thread name in site1 didn’t exist in site2. By creating a dummy thread in site2 with no routes but the same name as the source thread in site1, I was able to get the OVER to work.

[Bob Richardson]

One and All:

I had the opportunity to beta test 5.8 a couple of years ago and due to the limitations of the public thread to do additional translate/route work my evaluation was “it is underwhelming”.   And so in the minority at the time.

We do extensive inter-site routing via the traditional localhost method as we have Epic systems installed at Allina and numerous interfaces want the data.   We had to site balance our loads and make available the original inbound data from Epic to these applications.   Hence the localhosting method.

Our shop is in the process of evaluating an upgrade to 5.8.4.0 (or 5.8.5.0)

in the next quarter.   We do plan to re-visit the inter-site routing function.

Keep those posts coming!   Thanks.

[Craig Weldy]

I think the real advantage of the inter-site routing in 5.8.5, is for the smaller shops that have to pay for each individual thread license.  I can’t justify 2 additional ($1,700 for each prod/test pair, plus yearly support) threads each time I want to just pass data to another site.  Because of this I have 90 threads packed into a single site.  

Now, instead of having to use 4 threads to get data from the inbound thread in site A to the outbound thread in site B, I only have to use 2.  

I am in the process of redesigning my site right now for my 5.8.5 upgrade and I am loving the fact that I can now split my installation up into 6 different sites.

I will be using the old method to split up my inbound adt (sends out to 30 outbound threads at this point) so that I can distribute the processing between different processes, but I will still be way ahead of where I was with no additional threads licenses used.

Craig Weldy
Senior Interface Analyst
Beacon Health System
South Bend, In, 46615

[Bob Richardson]

Ouch!!!   We would be paying through the nose at that rate for sure.

Ok… I now understand the significance of the inter-site routing feature.

Thanks for your perspective.

[Author]

Replies