CL 5.8 – Inter-Site routing support.

[Craig Weldy]

I am currently on CL 5.6 and am looking to upgrade early next year.  I was looking over the 5.8 release notes and found this reference to the Inter-Site Routing Support.  Has anyone worked with 5.8 yet, and if so are you using this feature.

It is common knowledge that you “should not” route across process boundries and up until now you had to use 2 threads to connect from one site to another.  This has caused me many headacks since those that hold the purse strings don’t want to spend the money for thread licenses that just make the site more orderly.

I would like to make sure I understand exactly what this new feature means.

Site A:

   Threads:  

         inboundA        routes to outboundA1, outboundA2, outboundA3

         outboundA1

         outboundA2

         outboundA3

Site B:

   Threads:

        inboundB1      routes to outboundB1

        inboundB2      routes to outboundB2

        outboundB1

        outboundB2

Now, as I understand it, with the sites above and the new features, I can also route from inboundA to outboundB1 and likewise I can route from inboundB2 to outboundA3.

The other question is, if all of this works the way I outlined above, how does it look in the GUI?  Can you tell that the inbound threads from one site are conected to the outbound from the other site, or is it invisible in the GUI?

I will be at the conference in september and plan on looking closely at the new features then, but I was just way to excited over this issue to wait.  I fugured someone out there has at lease beta tested it.

I wait in anticipation!     😯     ❓     😯     ❓      😀

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

Topic

[Bob Richardson]

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

[Rob Abbott]

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.

Rob Abbott
Cloverleaf Emeritus

[Jim Kosloskey]

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

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

[Bob Richardson]

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.

[Jim Kosloskey]

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.

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

[Rob Abbott]

Hey Bob,

Quote:

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.

Rob Abbott
Cloverleaf Emeritus

[Michael Hertel]

Quote:

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

Quote:

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

So should this be used?

[James Cobane]

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

[Craig Weldy]

Thanks everyone for your input.  I am feeling pretty good about this feature and am looking forward to sitting down and checking it out at the Users Conference this year.

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

[Anonymous]

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

[Derrick Ray]

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.

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

[Mitchell Rawlins]

Quote:

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="https://usspvlclovertch2.infor.com/viewtopic.php?t=5615&highlight=intersite+routing&#8221; class=”bbcode_url”>https://usspvlclovertch2.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.

[Simone Heckmann]

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:

[Craig Weldy]

Simone,

    I agree with you that I love this new feature.  We just went live with 5.8.5 last Wednesday and so far so good.

    You had mentioned that you couldn’t remove the bad messge from the database, you should still be able to use the message id [0.0.0] to specifically locate and remove any message that is there.  I have not tried this yet in the new version but it always worked in the past.

    I have not run into the problem with the bad message yet, but my biggest issue is one that is know and in the release notes.  The problem that if you take down a thread with an inter-site routeing port, you can’t bring it back up right away because the OS has not released the port yet, and the whole process panics and shuts down.   I have just had to create a script that takes the thread down, waits for 10 min (the safe amount of time it takes to release the port on my system [AIX]) and then brings it back up.   With this I have been able to successfully deal with any hung threads I get from time to time without taking down whole process.

     But I am waiting for any word that there is a fix for this little challenge!  

😀

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

[Stefan Scholte]

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

[Bob Richardson]

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.

[Craig Weldy]

Stefan,  to answer your question, you should only use the inter-site routing if that is the best tool for the job.  For those of you with unlimited thread licenses, you will probably not use it, you can keep using the additional threads to pass data from site to site.  

If on the other hand you are paying for each thread license used, only having to use 2 licenses to pass data from an inbound thread in one site to an outbound thread in a second site, is much better than having to pay for 4 licenses to do the same thing.  Just the use of this new feature made me a superstar to by boss, since I was able to split my threads up between 5 sites instead of cramming them into 2, they process faster as a whole and I didn’t have to buy a bunch more licenses to make it happen.

Inter-site routing is just a tool, and like all tools it should only be used when it will solve a problem.  If I had unlimited licenses, I would probably not use it since there are some things about it that I need to work around, but these issues are small potatos compared with the solution it has provided for me.

Still needs some work, but I feel like they created this feature just for me!  Thanks guys!

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

[Author]

Replies