Setting Up and "OVER" Thread

[Joe Sellers]

I’d like to be able to take four inbound threads and route each of them through a unique xlate to a “middle” thread, where they would then be routed to the final destination thread through a common xlate.

Does anyone have a documentation snippet for setting up an “OVER” thread that they would be willing to share?  If so, would you also be willing to share your “OVER” proc?

Thanks.

Joe Sellers

Topic

[Jim Kosloskey]

Joe,

If you are on Cloverleaf 5.8 or 6.0 you may be able to use Xlate Chaining or Xlate Branching or dynamic rerouting via an Xlate to accomplish what you want.

I am not sure if all of the above is available in 5.8 but I know they are in 6.0.

Potentially save a thread and a need for a Tcl proc.

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

[Peter Heggie]

I’d love to see the OVER capability in the SEND OK and SEND FAIL procs. Thats when a point to point interface becomes an ESB. Each node performing some task, and passing the message on to the next node.

Right now I’m designing an interface where an inbound message goes through translation and then results in an email. Only after the email succeeds or not do I then want to update a database. I don’t want to update a database using tcl; I want to use a database protocol thread. I know the db protocol thread needs a little work in the area of error recovery, but its coming along. Most important is the requirement to have messages queue somewhere safely while the database is unavailable. When the database is available, the message will flow automatically, without manual intervention.

I can see where accessing a database in the middle of an interace, for data lookup or temporary storage, is required, and we do it here, but I think we will soon make a distinction between local databases like SQLite and network databases like SQL Server or Oracle. I think we will change, at some point, to reference only local databases like SQLite, in the middle of an interface, and only access network databases using database protocols.

Sorry to hijack this thread. I still think it would open up a whole new set of integration if we could OVER after protocol action.

Plus if you could do that, then that middle thread would have an inbound side with routing to another destination thread. The NetConfig would show three threads, with lines from thread 1 to thread 2, and a line from thread 2 to thread 3. So you could easily see the path of the interface.

If one used a SEND in the SEND OK procs, then you lose that visibility.

Peter Heggie

[Bob Richardson]

Greetings,

Jim, we are running 5.8.7.0 and, yes!  Xlate chaining, branching, and reroute are available.  We are just starting to take advantage of these features.

Just to inject here on desired features and functionality for the Integrator.

I urge everyone to submit such requests on INFOR’s website.

That is what we do here and some of them do make it to an official enhancement status (or in some cases fixes) for the next planned release or patch.

Enjoy.

[Joe Sellers]

We are on 5.8.6.  In my testing with “chaining”, it appears to allow you to link multiple xlates together on one route.  In my testing with “branching”, it appears to allow you to link multiple xlates together on the “pre-route” and then create separate “branch” routes to separate destinations, each utilizing the same or a different xlate.

My goal is to combine four inbound threads into a single feed and then have a secondary xlate applied to the combined feed.  This is necessary due to a shared xlt proc that is writing out to a file.  If the proc is applied on each of the four inbounds, they’re constantly fighting for write access to the file.

Thank you.

[Jim Kosloskey]

Joe,

Send me an email and I will share a proc I have which may do what you want.

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

[Joe Sellers]

Thanks Jim.  Your sample, along with what I pieced together from a couple of other posts, did the trick.  I now have this setup in test and am auditing the output.

As with anything, there are all kinds of “tweaks” possible, but the basic concept was accomplished with a TPS Outbound Data proc on the “middle” thread that creates a new message from it’s outbound message and “OVER’s” it back to the inbound data for further translation/routing to another thread(s).

I found a couple of examples where a msgcopy was used and one where the original message was simply reused after updating the SOURCECONN.  I played around with these options, but both throw the thread/intersite stats off and reusing the original message does not allow for delivery of an “intermediate” message from the “middle” thread.

Here’s the code from my proc that actually does the work.  I added an argument to control the disposition of the original message.  Jim had an argument in his code to control the use of the recovery database that I’ll likely add to my proc as well.

Code:

set over_mh [msgcreate -meta {USERECOVERDB true} [msgget $mh]]
lappend disp_list “OVER $over_mh”
lappend disp_list “$orig_msg_disp $mh”

Thanks everyone.

[Author]

Replies