Determining Destination Thread from Within Xlate

[Mark Carey]

Hi I have an xlate that is used in 2 different routes with 2 different desination threads, is there a way to see from within the xlate which destination thread is currently being used?  I need to do something different based on the destination but don’t want to maintain 2 separate xlates.

thanks,

Mark

Topic

[Russ Ross]

One thought that comes to mind is write a xlate TCL proc to retrive the destination thread name from the message metadata.

There is an example of accessing the user metadata I posted at this URL to get you some code and screen shots similar enough to help illustrate this conceputal approach:

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=1367&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=1367

Of course the metadata key you will use will be different than USERDATA like in my following statement:

Code:

set USERDATA_metadata [xpmmetaget $xlateId “USERDATA”]

According to the cloverleaf documentation you can see all the metadata keys if you ommit the specified key, which is USERDATA in my case so something like this

Code:

echo [xpmmetaget $xlateId]

Then pick the metadata key that looks like destination thread and see if that returns the correct destination thread name.

Then just use the output of the custom xlt TCL proc to set a temp variable in the xlate that can have an xlt if stament to determine what actions to invoke in the xlate.

Personally I see maintenance concerns with this approach and probably problems using the xlate testing tool but might work for a route test.

I don’t like the idea of an xlate being tied to the name of a destination thread.

In higher versions of cloverleaf, you can stack xlates so the base xlate can be used for both routes, and the deviations can be separate xlates stacked on the applicable route(s).

Jim Kosloskey recently reported to our team a finding that the tester in cloverleaf 6.0 that we use, unfortuantely gives a different result for stacked xlates than the actul interface does, so run thru an actual interface if unexpected outcomes appear in tester.

Russ Ross
RussRoss318@gmail.com

[Mark Carey]

Thank you, this was very helpful.  Was actually pretty simple.  We are using a chain and the script is used to send messages to different destinations, that required different data.  Here is what I put in place that worked.

set DESTCONN_metadata [xpmmetaget $xlateId “DESTCONN”]

set xlateOutVals $DESTCONN_metadata

Mark

[Russ Ross]

I love those happy endings.

Keep in mind that xlateOutVals is a list so returning a list instead of a string is advisable, for example:

Code:

set DESTCONN_metadata [xpmmetaget $xlateId “DESTCONN”]
set xlateOutVals [list $DESTCONN_metadata]

Since thread names don’t have spaces in them, both ways will likely work but eventually it will catch up with you elsewhere if you continue to treat xlateOutVals as a string and not a list.

I’m guilty of overlooking this point myself sometimes.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies