xlate: unable to modify two Dest fields in Copy with tcl

[Peter Heggie]

In a COPY action, I’ve got two Source and two Destination fields:

Source

0(0).MSH(0).#9(0).[1]

0(0).EVN(0).#1(0)

Destination

0(0).MSH(0).#9(0)

0(0).EVN(0).#1(0)

Based on the two input values, I’ll set the output values; for three values in particular, I”ll change the values, for any other values I’ll basically pass the values through.

PreProc TCL:

set msgtype [lindex $xlateInVals 0]

set evntype [lindex $xlateInVals 1]

echo evntype $evntype

switch $msgtype {

 A09 { set msh9 “ADT^A03” ; set evn99 “A03” }

 A10 { set msh9 “ADT^A02” ; set evn99 “A02” }

 A28 { set msh9 “ADT^A08” ; set evn99 “A08” }

 default { set msh9 “ADT^$msgtype” ; set evn99 $evntype}

}

echo msh9 = $msh9

echo evn99 = $evn99

set xlateOutVals

]

echo $xlateOutVals

The echo output looks great, but the output message only has the first field (MSH9) updated – the EVN segment should have field 1 updated, but it remains null. What can I do to get the second Destination field to be updated? Or do I need a second COPY statement?

Thanks, Pete

Command output:

evntype A10

msh9 = ADT^A02

evn99 = A02

ADT^A02 A02

MESSAGE 1

0(0).MSH(0)  :  >|^~&|CROUSE|CHA8J0|LAB|LACNY|201104271620|J41134/CHPFOPBD|ADT^A02||P|2.3< 0(0).EVN(0)  :  >||201104271620<

Peter Heggie
PeterHeggie@crouse.org

Topic

[Jim Kosloskey]

If I recall COPY will only populate one destination. I think you need to use xmpstore (but then you will probably need to do a CALL Action not COPY).

However based on what I see in the Tcl I am not sure you need Tcl to do what you want – assuming you are on a Cloverleaf release that supports the IF Action.

A set off IFs with appropriate COPYs should do the trick.

Or you could get creative with a Table and put the MSH-9 values in there and have that return the values you want and use that.

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

[Chris Williams]

Try changing

Code:

set xlateOutVals [list $msh9 [string trim $evn99 ] ]

to

Code:

set xlateOutVals “[list $msh9] [list [string trim $evn99]]”

creates a single List Element. A List is string containing one or more List Elements separated by white space.

[Robert Kersemakers]

Hmmm…

I use a COPY to several destination fields all the time and it works like a charm. Also the list command you are using at the end is correct.

What I think happens here is that both the destination-fields are assigned to MSH-9: first field (ADT^A02) to MSG-9/0 and the second (A02) to MSG-9/1. So there is nothing left for EVN-1.

Can you try destination:

0(0).MSH(0).#9(0).[0]

0(0).EVN(0).#1(0).[0]

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Peter Heggie]

Thank you everyone for your help –

Hi Chris, I tried changing the set xlateOutVals statement to the longer form and it had no effect.

Hi Robert, I changed the Destination syntax to what you suggested and it worked, with and without the change to the set xlateOutVals statement.

Hi Jim, as a beginner in Cloverleaf interfacing, and as a lazy perfectionist, I struggle with deciding on the best strategy.

– Should I have two COPY actions, appropriate for setting two fields?

– Should I have a table, which will be more valuable if we add more msgtype changes? But do we need two tables? Or copy the table output value (partially) to the second destination? What if the EVN99 value is not the second part of the MSH9?

– Should we have a nested IF statement, and if so, should we first put the source value in a temporary variable, and then reference that variable in each IF condition (to reduce parsing overhead?)?

– Should we use one COPY statement with two destinations because we can get away with one action, and because the two values are related (by msgtype)?

I tend to like subroutines that streamline mainline code (visually it makes for easier maintenance), and I tend to avoid nested IFs because of the increased effort in keeping track of the nesting levels and it looks less appealing. I also tend to like tables because it keeps ‘custom’ code out of the ‘normal’ logic.

I’ll try a combination of a single table, with two destinations and a much smaller chunk of code that splits the table result into two values and sets the two destinations appropriately. I’m guessing it has to be in a Post-Proc?

Maybe something like this:

set xlateOutVals

Pete

Peter Heggie
PeterHeggie@crouse.org

[Peter Heggie]

ok, this is not working, as far as setting multiple destinations, but otherwise it works great.

Action:

TABLE

Source:

0(0).MSH(0).#9(0).[1]

Destination:

0(0).MSH(0).#9(0).[0]

0(0).EVN(0).#1(0).[0]

Post Proc Tcl:

echo $xlateInVals

set xlateOutVals

[string range [lindex $xlateInVals 0] 4 6] ]

echo $xlateOutVals

Output:

ADT^A02 {}

ADT^A02 A02

MESSAGE 1

0(0).MSH(0)  :  >|^~&|CROUSE|CHA8J0|LAB|LACNY|201104281043|J41134/CHPFOPBD|ADT^A02||P|2.3<

0(0).EVN(0)  :  >||201104281043<

The table value is correct, and the tcl is executed correctly with the correct input value, but the second destination is not populated. When I reverse the order of the destinations, to put the EVN99 first, then I get the value populated in the EVN99 but not the MSH9.

I may need a second action, or I could go back to the previous COPY action with the extra Tcl. Or maybe the list I’m making is not formatted correctly?

Pete

Peter Heggie
PeterHeggie@crouse.org

[Jim Kosloskey]

Peter,

If you prefer a table, I think this can be accomplished with one table.

If I understand your challenge correctly, you need to populate the Message Event component of MSH-9 (MSH-9.2) with a different value than the inbound message has in MSH-9.2 depending on the value in MSH-9.2 – and – you need to place the same value in the appropriate EVN field.

Since these will all be ADT Message Types, I suspect a table that contains the value for the inbound MSH-9.2 and what that value needs to be outbound will suffice – like this:

IN       OUT

A09    A03

A10    A02

A28    A08

Then do the lookup using 0(0).MSH(0).#9(0).[1] as the Source and 0(0).MSH(0).#9(0).[1]

as the destination (this will set the outbound MSH-9.2 component to the correct value).

Then COPY from the Outbound 0(0).MSH(0).#9(0).[1] (this should have a tilde ~ in front of the path in the source) to the outbound 0(0).EVN(0).#1(0).

If you prefer to have the result go to a temp variable that will work just 3 Actions instead of 2.

As far as parsing, it is my understanding that once you are in the Xlate the parsing is done so you don’t really incur additional parsing overhead.

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

[Peter Heggie]

Given a TABLE statement which works fine:

0(0).MSH(0).#9(0).[1] -> 0(0).MSH(0).#9(0)

which populates the destination with a value of ‘ADT^A02’,

It is interesting that the next statement, COPY, can copy the second subfield to the Destination:

0(0).MSH(0).#9(0).[1] -> 0(0).EVN(0).#1(0).[0]

but I can’t copy it if I’m using the target field as a source:

~0(0).MSH(0).#9(0).[1] -> 0(0).EVN(0).#1(0).[0]

I guess somehow it ‘knows’ that the up arrow ^ character in the target field is a string from a table, as opposed to the original subfield delimeter from the source message.

Peter Heggie
PeterHeggie@crouse.org

[Jim Kosloskey]

Peter,

What release of Cloverleaf?

There are some special things that happen with the MSH-9 filed that may be causing the issue,

It does not have anything to do with ‘knowing’ that the vallue in MSH-9.2 outbound came from a Table. At the time you are attempting to populate the EVN the Xlate has ‘forgotten’ about the Table lookup.

Rather I suspect that the issue is trying to use the outbound MSH-9 field as a source.

I will attempt to duplicate on my system and let you know.

I suspect you could use a temp variable for the result of your lookup then use the temp variable to populate the MSH-9.2 and the EVN.

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

[Peter Heggie]

Thanks Jim,

That did it. I used the following:

TABLE 0(0).MSH(0).#9(0).[1] -> 0(0).MSH(0).#9(0).[1]

COPY  ~0(0).MSH(0).#9(0).[1] -> 0(0).EVN(0).#1(0)

And the table was as you suggested. So thats good, I’m using a table to guard against future changes and I’m down to two statements, one for each destination.

Pete

Peter Heggie
PeterHeggie@crouse.org

[Peter Heggie]

I’m on release 5.8.0

I’ll try using a temp variable to see how it looks.

Peter Heggie
PeterHeggie@crouse.org

[Peter Heggie]

ok, yes that worked too:

TABLE

0(0).MSH(0).#9(0).[1] -> @msgtype

COPY

@msgtype -> 0(0).MSH(0).#9(0).[1] , 0(0).EVN(0).#1(0).[0]

Tcl: set xlateOutVals

[lindex $xlateInVals 0]]

This is good! Now which one should I use? Its probably a few milliseconds faster without the temporary variable and Tcl. If I thought I’d need that table output value again for some third destination, I’d use the above method with the Tcl.

Pete

Peter Heggie
PeterHeggie@crouse.org

[Jim Kosloskey]

Peter,

OK I am on 5.6.

Apparently the MSH-9 (at least MSH-9.2 outbound cannot be used as a source – at least that is what my testing showed.

The temp variable should function properly.

The one issue with using Tables is the knowledge of the effect of the Table is not in the Xlate – one must look into the Table to see what could be happening.

I do not reject the use of a Table because of the above but I do limit my use of a table to drive Xlate logic when I can use Xlate logic itself – I don’t have a problem with nested IFs but everyone needs to use the solution that best fits their needs.

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

[Peter Heggie]

ok – good to know about MSH9. Yes, I see the point about tables introducing complexity in maintenance/understanding; with nested IFs, everything is right in front of you.

Thanks, Pete

Peter Heggie
PeterHeggie@crouse.org

[Jim Kosloskey]

Peter,

What release of Cloverleaf?

There are some special things that happen with the MSH-9 filed that may be causing the issue,

It does not have anything to do with ‘knowing’ that the vallue in MSH-9.2 outbound came from a Table. At the time you are attempting to populate the EVN the Xlate has ‘forgotten’ about the Table lookup.

Rather I suspect that the issue is trying to use the outbound MSH-9 field as a source.

I will attempt to duplicate on my system and let you know.

I suspect you could use a temp variable for the result of your lookup then use the temp variable to populate the MSH-9.2 and the EVN.

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

[Jim Kosloskey]

Pete,

really no need for Tcl at all (use it if you like though).

Just 2 more COPYs will do the trick just as well.

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

[Author]

Replies