Inter-Siter Routing with Cloverleaf 5.8

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,

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.

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

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.

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,

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

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.

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.

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.

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.

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.