xlateId

[David Harrison]

Cloverleaf 5.6 on Solaris 10.

I have an xltp proc which I am using in a number of Xlates. I wanted to identify the calling Xlate so I echoed the xlateId variable within the xltp proc. Instead of the name of the Xlate I got

Topic

[Jim Kosloskey]

David,

That is a handle of the message being Xlated much like the handle you get in a Tps type proc.

There may be a global variable provided that names the Xlate but I don’t recall one.

I think the command to see the globals available is ‘info globals’. Use that inside an Xlate proc to see what is available. I think the return is an array or a list – whichever you can also echo out the name and the contnets with more code and determine if what you want is available.

If it is not available, this might be a good enchancement request.

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

[David Harrison]

Jim,

Thanks for the tip -I

[Rob Abbott]

this might be a little easier 🙂

Code:

proc showglobals {} {
foreach var [info globals] {
upvar $var $var

if [array exists $var] {
foreach idx [array names $var] {
set arr ${var}($idx)
echo “$arr = [set $arr]”
}
} else {
echo “$var = [set $var]”
}
echo “———————————————”
}
}

Rob Abbott
Cloverleaf Emeritus

[David Harrison]

I grant you it

[Simone Heckmann]

Hi,

I’ve tried to incorporate the xlateName into an xltp proc by reading the above mentioned global variable.

Code:

upvar _XIO_DefFileName defFileName
echo “defFileName = [array get defFileName]”
set xlateName $defFileName(xltLoadDef-recid)

This works perfectly fine in the testing tool.

Code:

Please Wait ……
Command Issued: hcixlttest -i -e latin1 -d 1 -f eof HL7_SY011_A01.xlt D:/Cloverleaf/cis5.8/integrator/_demo/testdaten
Command output:

defFileName = xltLoadDef-recid D:/Cloverleaf/cis5.8/integrator/_demo/Xlate/HL7_SY011_A01.xlt

However, deploying the same proc outside the testing tool returns an error:

Code:

errorInfo:
can’t read “defFileName(xltLoadDef-recid)”: no such variable
   while executing
“set xlateName $defFileName(xltLoadDef-recid) ”
   (procedure “HC_xlog” line 11)
   invoked from within
“HC_xlog 1”

defFileName =

…thus rendering the idea – neat as it is – useless.

Does anyone know how to fix this?

Maybe something wrong with the upvar stack level?

Greetings

Simone

[Charlie Bursell]

That is because _XIO_DefFileName  is a global and by default the tester runs in global mode while the engine does not.

Why upvar at all?  Simply access it as a global like:

global _XIO_DefFileName

set deffileName [array get _XIO_DefFileName ]

or better still

set defgileName [array get ::_XIO_DefFileName ]

[Simone Heckmann]

Nope, same result.

I think that global only exists in the xlate test tool.

I just tried route test an the variable wasn’t filled either.

So it’s not test vs. engine but rather xlateTest vs. rest of the world

Does anyone know of another way to access the name of the current xlate file from within an xltp?

Thanks for your assistance, Charlie!

[Charlie Bursell]

My bad here.  It looks like the tester makes Xio calls and the engine does not.  If you look at the file configIO.tlib in $HCIROOT/tcl/lib/cloverleaf you will see that the global is only set when the file is read by Xio calls.

The only other options I can think of are to read the info from the NetConfig or, simplier, in the route put a simple Tcl proc which puts the file name is the USERDATA meta field for that message

If I have time later I can explore other options

[Charlie Bursell]

For those of you that were trying to get the Xlate name from the _XIO_DefFileName  global I have an answer but not yet a solution

It seems the engine is using a different Tcl interpreter which is not made available to the user.  Therefore the global is available in test but not in the engine.  We have written a bug report on this as everyone agrees the tester and the engine should do the same thing the same way.

I don’t have a date for the fix release yet but at least we now know why

The work-around would be to put name in USERDATA or set as a global in a preproc

[Author]

Replies