Can we have two xlates on the same thread?

[Tom Gilbert]

I see we can have multiple pros so was wondering if you can have multiple xlates for one thread?  Is there away to work around this if this is not possible?

Topic

[James Cobane]

Tom,

I’m not sure I understand your question correctly, but you can have any number of Xlates routed to the same outbound thread (from the same source thread or different source threads).  You can route the same message through multiple Xlates to the same destinatin thread or multiple destinations.  It is all dependent on what your need is and is fundamental to Cloverleaf.  For example:

source1 –myXlate1–> dest1

           –myXlate2–> dest1

           –myXlate3–> dest2

source2 –myXlate4–> dest1

           –myXlate5–> dest2

and so on….

Hope this helps.

Jim Cobane

Henry Ford Health

[Tom Gilbert]

Here is an example of what I am trying to do…

fr_thread1

  xlate_to_thread2

     proc1

     proc2

     xlate1

     xlate2

I know there is a way to select multiple procs and set the order in which to run.

I do not see a way to select xlate1 and xlate2 to be on the same route message.

I was wondering if it is possible and how it can be done…

[James Cobane]

Tom,

Are you saying that you want your IB message to go through your procs, then xlate1, and then the output from xlate1 to go through xlate2 (serially)?

    IB msg –> proc1–>proc2 –> xlate1 –> xlate2 –> OB msg

Or are you saying that you want the IB message to go through the procs and then go through both xlate1 & xlate2 (in parallel)?

[David Barr]

You can’t have more than one xlate per route, but you can have more than one route per thread, and you can route messages to yourself. So, you can do something like this:

fr_thread1

 xlate_to_thread1

    proc1

    proc2

    xlate1

 xlate_to_thread2

    xlate2

The tricky part is that you’d have to use a fancy trxid determination proc to route the message through the first route on the first pass and the second route on the next pass.  Also, you’d need an outbound data proc that returns the message with an OVER disposition if the source of the message is not thread1.

So it is possible but probably not advisable.  Another option is to do it something like this:

fr_thread1

 xlate_to_thread2

    proc1

    proc2

    xlate1

thread2

 xlate_to_thread3

    xlate2

In this case you could use an intermediate thread so that there would be two routes between your source and your destination. You’d have to use the same trick in thread2 of using an outbound data proc that returns the messages with a disposition of OVER in order for the messages to go through the second route.

[Jim Kosloskey]

Jim Cobane,

You are on 5.8 right?

Doesn’t that release have the ability to stack Xlates on a single route such that the outbound message from xlate1 becomes the inbound message for xlate2 and so on?

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

[Scott Folley]

5.8 does have the ability to “stack translates”.  The route detail required to do this is different than the previous versions.  There is still an Xlate detail but the stacked translate happens in the “Chain” detail.  Using that you can achieve what you are looking for but in any version prior to 5.8 you really can’t do it in one thread.

[James Cobane]

Jim K.,

Yes, as Scott and I indicated, 5.8 does have the capability to “chain” and “branch” translations.  We haven’t leveraged this functionality yet, and while it is kinda cool, it also could be interesting to trouble-shoot/test; (i.e. if an outbound message looks wrong, which Xlate broke it?)

Thanks,

Jim Cobane

Henry Ford Health

[Jim Kosloskey]

Jim,

Good point regarding troubleshooting. I did not see the previous mention of this stack capability so I apologize if I was asking about something already covered.

I guess experimentation with the Xlate EO Config might help but that generates a lot of noise (necessary when needed but maybe excessive for the prupose of deteriming the state of the message).

Maybe this is the time for the engine to put out pre and post Xlate message dumps in the Log if EO Config set to a proper level.

If not already in there might need to be added.

Of course one could always do the message dump in each Xlate controlled by a switch of some sort – but I think it is nicer if it is part of the EO Config capability.

If and when we get to 5.8 or beyond here, I have on my wish list to understand the new Xlate potentials better.

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

[Author]

Replies