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.