How to set userData for error in Tcl snippet

[Kyley Jex]

Within an HL7 xlate I’d like to error the message for those fields that do a table lookup and the value is not found in the table.  Below is the snippet of Tcl code that provide in a COPY action.  It works correctly to ERROR the message, but I’d like to set the userData as the reason error message.

Code:

lassign $xlateInVals input_1
set tvalue [tbllookup 0004.tbl $input_1]
if {[string equal $tvalue “”]} {
   error “$input_1 is invalid for Patient Class”
} else {
   set xlateOutVals [list $tvalue]
}

Can I set the userData from the Tcl snippet?  or do I have to CALL a TclProc?

Cheers,

Kyley

Topic

[Jim Kosloskey]

Check out the XPMERROR command in the Reference Guide.

Also, you will need to change the Error: entry on the Xlate Action (it defaults to skip) to Error to get the message sent to the Error DB.

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

[Russ Ross]

Here is a TPS code snipet example from my level 3 exam of putting a reason in the USER metadata:

Code:

       # If we get here, the SSN is either missing of zero

           # *ANYTIME* you send a mesasge to the Error Database on purpose,
           # *ALWAYS* put the reason why in the USER meta data field.
           # The ERROR return forces a Tcl error and thereby forces the
           # message to the error database.  So, a user must be able to
           # distiquish between real and forced errors.

           msgmetaset $mh USERDATA “$myname: PID field 19 SSN ($SSN) is either missing or zero!”

I also have a callable xlt proc I posted at the following URL that illustrates how to put information in the USER metadata during xlate, which is very similar but uses xpmmetaset instead of msgmetaset :

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

Russ Ross
RussRoss318@gmail.com

[Kyley Jex]

How do I get the message handle ($mh) in the Tcl Pre Proc for the COPY action?  I realize that if the Tcl is in a file as a function, then I can use:

Code:

keylget args MSGID mh

… but if it’s just within the COPY Action Pre Proc can it be done?

[Jim Kosloskey]

You cannot get the current message ID (handle) inside the Xlate.

You can do things to the current mesage content and metadata via xpm commands.

What is it you are trying to do? Is this related to ERRORing out the message?

If so re-read my previous post.

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

[Charlie Bursell]

Converting Russ’ example:

xpmmetaset $xlateId USERDATA “$myname: PID field 19 SSN ($SSN) is either missing or zero!”

[Russ Ross]

The URL I posted shows how to use xpmmetaset in a callable xlate TCL proc.

I wasn’t sure if you wanted to do it via TPS or XLT so I was attempting to direct you to an example of doing it both ways.

Russ Ross
RussRoss318@gmail.com

[Kyley Jex]

Thank you for your responses, it has been helpful to understand more about the XPM architecture and API.  However, I’m still unable to set the user data for the error that I’m generating.

The error does get generated in the Error DB with “msgState: Tcl callout abort (303)”, but the msgUserData is not set.  Here is the latest Tcl that I’m using:

Code:

lassign $xlateInVals input_1
set tvalue [tbllookup 0004.tbl $input_1]
if {[string equal $tvalue “”]} {
   set errMsg “$input_1 is invalid for Patient Class”
   xpmmetaset $xlateId USERDATA $errMsg
   xpmerror $xlateId action “action error $errMsg”
} else {
   set xlateOutVals [list $tvalue]
}

Is what I’m trying to do generally a good practice?  or would this be better handled some other way?

[Jim Kosloskey]

Normally If we have a value in the inbound that is not located in a lookup table, we either place a fixed value indicating the error in the outbound field or we put the inbound value in the outbound field.

The Xlate TABLE Action does not allow for preserving the inbound to the outbound on failure. That has been requested but has not yet been delivered.

However, there are work-arounds. One could check the result of the TABLE Action by checking the outbound field with an IF to see if it has the default value (that is what is returned when the value is not found in the Table) and then COPY the inbound to the outbound.

We have a proc that does the Table lookup. It provides for us to dynamically name the Table rather than hard code it (anoterh enhancement that has been requested) and it allows us to preserve the inbound.

I have never seen the literal associated with the xpmerror Tcl extension get placed in the message. I think it goes to the log. Would be nice if it also populated the USERDATA – however, what gets errored as a result of xpmerror is the inbound message I believe and I don’t think the Xlate model allows for any modification of the inbound message but then the authors of the Xlate could make it do anything they want I think.

I am pretty sure that the xpm commands only address the outbound message (outbound from the Xlate I mean) so I don’t think xpmmetaset for USERDATA (or any other metadata) would ever show up in the errored message because it is the inbound message that is errored.

If you want to error the inbound message AND have the USERDATA reflect the reason for the error, then I think you will need to do you edits for validity pre Xlate.

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

[Kyley Jex]

Thanks for the explanation.

If what you describe is true, then what is the value of xpmmetaset?  So if you error the message, it sounds as if none of the metadata will ever be attached to the message.  That seems to be a defect.

What is the process to submit a defect in the xpm api?  I would like to see this functionality in the next release.

I understand that a possible work around would be to handle the validation of the message as either a pre/post proc to the xlate — but then all validation/error reporting has to be a proc and not easily done within the xlate (non-programmers will be creating xlate).

[Charlie Bursell]

The thing is you changed the metadata in the message to be sent from the xlate engine.  Problem is you errored it prior to it being sent.  So what you errored is what you got in.

[Kyley Jex]

How is that different than validating and setting the USERDATA in a pre proc?

[Charlie Bursell]

In the pre-proc you returned the disposition list to engine so it was able to change the message structure in memory.  When you error from xlate it just goes to error database.

One of many reasons I almost never error from within a translate.

[Kyley Jex]

It is helpful to know that 1) difference between erroring in pre-proc vs. xlate and 2) that your practice is to not error from translate.

I assume that this is the same for post-proc?  Also, is the post-proc message the inbound message or the output of the xlate?

[Author]

Replies