CL 5.8 – Inter-Site routing support.

Greetings,

I did conduct a Beta test of CIS5.8 on an AIX UNIX 5.3 TL8 (now TL11) platform.  We have an unlimited license and have configured numerous site to site jump connections.   Ok…

I played with the inter-site routing and was a bit underwhelmed.

A destination receiver thread still needs to be created so that most likely will count against your limit.   Messages are held in the Recovery database – which is good.   However, I ran out of time to evaluate if we needed to send the “inter-site” route connection an ACK before the next message is sent.  There is no “auto resend” widgets to click on the inter-site thread.  So I don’t know if the inter-site guy just keeps sending and bypassing normal ack processing.  There is also some kludgy style (IMO) site level files to create (or got created?) – memory fails me a bit here.  

These were like the CLI files for TCP/IP multi-connections when you select “Save IP and Client Port to Driver Control”.

So… I would be somewhat hesitant here in getting too worked up about this inter-site routing feature until proven out in the field, that is, by us Cloverleaf customers.  

I would recommend that you build a case for buying more threads or get the unlimited license.   An investment for the future.  We started with one site and a dozen threads back in 1997 and now have 9 sites with 300 threads and climbing!!

Hope this helps.

Have a great day!

Bob Richardson

Sorry you were underwhelmed Bob but I for one am pretty excited about this feature.

On the destination site you make the thread “public” by specifying a port number that it will listen on for connections from other threads.

The icon will then have a “triangle” indicator on it that shows that this thread is public.

On the sending side you create a new “destination” instead of a new thread.  In the destination properties, you specify what host, site, and thread you want to route to.

You then create the route to the “destination”.  The destination icon looks a lot different from the rest of the icons, and is a placeholder indicating that the actual thread lives somewhere else.

Under the covers, all the handshaking is taken care of by the engine.  It uses the same protocol that a cross-process route does.  If you’re routing localhost, the performance impact is similar to that of a cross-process route.  

All this is done through the GUI and you don’t have to create or edit any files by hand.  All tracking files are created on the fly as needed.

I too am quite excited by this capability.

I am sure there will be some ‘tweaking’ necessary as it gets in use (almost all new funtionality -especially something this significant – needs enhance ment as it get in use).

So – when we move off of 5.6 to 5.8 or later, I will certainly encourage all our engineers here to work with that capability – and I won’t hesitate to ask for enhancements as we see the need (I already have one in mind – hint, hint Rob).

Rob,

Thanks for you input here!   I have no problem in backing off once the facts are known.   In the interests of seeking more knowlege here I have a question about the inter-site configuration.

Does the sending thread incorporate checks to verify that a message has been delivered successfully to the receiver?   Do we have guaranteed delivery of all messages especially in the event of a process crash or dropped server?

I was not able to demonstrate that capability during my Beta testing.

At your leisure…

Thanks.

Bob,

Those are excellent concerns and need to be fully evaluated.

Your advanced experience with 5.8 is valued and I urge you to continue to evaluate these functions as your schedule permits and keep the rest of us informed of your observations, etc.

I also urge others that get on 5.8 to evaluate what they can of the new features and let us all know your opinions.

I doubt we will be on 5.8 or post 5.8 sooner than anyone else but if there are any features to be evaluated on whatever release we nect migrate to, I will make an attempt to evaluate them.

Hey Bob,

Does the sending thread incorporate checks to verify that a message has been delivered successfully to the receiver?   Do we have guaranteed delivery of all messages especially in the event of a process crash or dropped server?

Yes – as you know guaranteed delivery is a cornerstone of our functionality.  As I mentioned inter-site routing uses the same protocol/handshaking that a cross-process route does.  I don’t think we’ve had any data loss on cross-process routes 🙂

I’ve also confirmed that a “destination” will NOT consume a thread for the thread-based license model.

It is common knowledge that you “should not” route across process boundries

It uses the same protocol that a cross-process route does

So should this be used?

Regarding the “It is common knowledge that you ‘should not’ route across process boundries” statement, I believe in older versions of Cloverleaf there may have been issues with threads communicating cross-process (sometimes transactions might sit in the post-xlate queue, and would need to bounce the IB process), but, this hasn’t been an issue for quite some time.  We have many cross-process threads (IB in process A, OB in process B) and run without issue.  Much of the reason for breaking out threads into configurations where IB & OB are in the same process is for granularity and modularity of the Xlate threads.

I think this inter-site threading will be a nice feature, as we have several instances of inter-site connections currently.

Jim Cobane

Henry Ford Health

Where does the processing take place? in the sending site/process or the site the destination is sending to?

Does anyone know if it’s possible to use inter-site routing to a public thread that’s an inbound thread?  So, for example in site A you route from thread1 to dest1 and in site B you have thread2 which is a public thread that can then route messages received via dest1 to other outbound threads.

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).

Site 1 Inbound —> destination (inter-site thread to Site 2 OutboundA)

       ( so that the transaction is sent directly to the OutboundA thread in Site 2.)

versus:

Site 1 Inbound —> Site 1 outbound (localhost) .. | .. Site 2 Inbound —> Site 2 OutboundA

       (which is how site-to-site is accomplished without the new intersite option)

It is possible using a fairly small upoc to get the second scenario to work.  I’ve posted code at <a href="http://clovertech.infor.com/viewtopic.php?t=5615&highlight=intersite+routing&#8221; class=”bbcode_url”>http://clovertech.infor.com/viewtopic.php?t=5615&highlight=intersite+routing.  It may not be the best approach, but at least it doesn’t require as strict a naming convention as other solutions that have been posted.

Hey, fellow intersite routers,

I love the new intersite routing feature and I use it quite often. However I encountered some limitations:

In the intersite routing scenario I usually have several sending systems delivering messages to one receiving system.

If one of the sending system causes trouble (e.g. send corrupted messages) I have no chance to stop this destination from delivering these messages to the OB-thread because destinations don’t have a “hold” function.

Also, if there are already corrupted messages from one intersite destination in the OB-thread’s queue, I have no way of kicking them out of the recovery database because I cannot select them.

They show up in the database dump, but the intersite destination they came from is not among the list of threads I can pick to filter these messages.

e.g.:

Command Issued: hcidbdump -r
Command status:0
Command output:

[code]
Command Issued: hcidbdump -r
Command status:0
Command output:

Hey fellow Cloverleaf users.

I have maybe a dumb question but I will ask it anyhow.

Why should I use the intersite routing feature if the destination on the other site can’t be used as an inbound thread.

with kind regards

Stefan Scholte

Greetings,

Ok… I have had a running battle with the Cloverleaf support folks on this inter-site routing feature having done a Beta evaluation of the 5.8.0 version over a year ago.

We use the tried but true method of local host connections where you can do exactly what you cannot do with the inter-site public thread on the receiving end.  You still have to configure and declare a public thread.

At the time of the Beta the Integrator would not attempt a resend of messages in the recovery database once the inter-site thread was back up either (we need to retest now as we are running 5.8.5 on AIX).

The concept of inter-site routing is promising but it needs more work to make it a truely configurable item without the necessity of creating custom solutions to get around its deficiencies.

A doubting Bob at this point but hopeful that Cloverleaf will get it right with its customers feedback.