Unsupported Transaction IDs

[Darren Tomlinson]

i am having ADT messages (in a test system) going into the error database.

Topic

[Steve Carter]

May not be much help, but have you looked at the process log?  Unsupported TrxID doesn’t always mean what it says.  If there’s more to the problem, the process log should give you a little more insight.

Steve

[Darren Tomlinson]

can you be a little more specific on that please

[Darren Tomlinson]

here is what i see…

01/16/2008 08:28:56

[xlt :rout:ERR /0:CareManager_xlate] No routes defined for TrxId ‘ADT_A34’

Engine idle — 01/16/2008 08:29:07

[Scott Lee]

I don’t know if this is your problem or not, but when we set up our wild card routes we use a pipe “|” between the values like this…

Code:

ADT_A(01|02|03|04|05|06|07|08|11|13|17|35|36)

Not sure how it would interpret the comma?

[Steve Carter]

I can’t remember the specific cases.  However, the errorDB will report an unsupported TrxID, but the process log will show the error as something else.  ‘Unable to load xlate’ comes to mind, but I don’t think that’s right.

I’m not sure what you’re problem may be.  I’ve used wildcard routing in a similar fashion without any issues.

Sorry I couldn’t help.

Steve

[Darren Tomlinson]

the use of the different wild card style, ie (01|13|34) i cant see as being the issue, because A01s, A02s etc, go through most of the time.  there are instances where they do not though.

i might be mixing up terminologies, but i got the “xlt :rout:ERR /0:CareManager_xlate] No routes defined for TrxId ‘ADT_A34’ ” from “Log file for process CareManager”.  is that what you are referring to as the process log?

[Scott Lee]

I see now the square brackets with the commas so that probably works.  I’ve always used the parens and pipes so that caught my eye.

If some messages are going, some are not, then I might look more closely at the translations?  What are you doing in the xlates?  I see the 17s and 34s are raw… is there a TCL proc there?

Can you show us the metadata for one of these messages in the error database?

Are these going to a real destination or are they routed back into the engine?

[Charlie Bursell]

You shouls *ALWAYS* verify your regexp whne using wildcards!

You state a regexp like:  

ADT_A(01|02|03|04|05|06|07|08|11|13|17|35|36)

which I would code like:

ADT_(A((0[1-9])|(1[137])|(3[56])))

In tcl or hcitcl I would then do something like:

set regexp {ADT_(A((0[1-9])|(1[137])|(3[56])))}

for {set i 1} {$i < 40} {incr i} {    set ADT ADT_A[format %02d $i]    if {![regexp — $regexp $ADT]} {echo $ADT FAILED} } All of the ones I want should pass and all of the others should fail

[John Hamilton]

Can I suggest you do as Charlie suggest.s

Pull your transaction out into a tcl prompt and test them.

I think the results you get will surprise you a lot.

I’m pretty sure those are not the results you were expecting.

But even at that I’m not sure why the ADT_A34 would have failed one of the above expersions should have covered it.

So first get them tested and working as desired the come back to the Invalid transaction.

[Darren Tomlinson]

the A34 raw translation has no tcl.  therefore, if it is erroring out, i cannot be translation based.

also note, i have other threads that have long routes like this, and so far, have had no problems with them.

[Scott Lee]

Great idea Charlie…

Code:

hcitcl>set regexp {ADT_A[10,12]}
ADT_A[10,12]

hcitcl>for {set i 1} {$i < 40} {incr i} {   set ADT ADT_A[format %02d $i]   if {![regexp -- $regexp $ADT]} {echo $ADT FAILED} } ADT_A30 FAILED ADT_A31 FAILED ADT_A32 FAILED ADT_A33 FAILED ADT_A34 FAILED ADT_A35 FAILED ADT_A36 FAILED ADT_A37 FAILED ADT_A38 FAILED ADT_A39 FAILED hcitcl>

It may not be the only problem, but it’s definitely a problem.   😀

[Michael Hertel]

You might want to check the A17/A34 route and see if wildcard is actually checked. If it is, did you bounce the process after making the change?

[Darren Tomlinson]

i think i am more lost now than before.  in my Cloverleaf training, using the ADT_A[10,12] was how i was taught.  i see that if you run that through tcl, that it interprets it askew and would in theory verify 01-29 somehow.  if that were the case, i would think i would be complaining about messages that i do not want getting through.  

why do you assume that the software reads the expression the exact same way as tcl?

why does tcl only fail on 30-39?

also note, i am somewhat new to cloverleaf, so i realize that i have alot to learn.  we are also running v5.3 on AIX5.2

[Darren Tomlinson]

the A17/34 wild card was checked.  all of these route were defined originally and never changed.  the initial bounce of the process should have initialized all of it at once.

this is making my brain hurt.

on the upside, we might get the record for thread lenght in this forum…

[Rick Brown]

Please post the output from the message in the error database:

Curious to see if the message is data or ack message.

hcidbdump -e -m -L -c

To get the message ID you can list what is in the error database by typing hcidbdump -e

This output will give us more info to go on..

[Charlie Bursell]

Darren:

I do not believe you were taught to configure a Wildcard route as you ststed above, at least not at a Quovadx class.  Perhaps you mis-remembered what was taught?

We *ALWAYS* teach that Wildacrd uses the smae regular expression engine as Tcl.  What you have defined is not a valid regular expression

Get Brent’s latest Tcl book and read the chapter on regular expressions.

[Nathan Martin]

Does the wild card expression have to match the whole transaction id?


tcl>set regexp {ADT_A(10|12)}

tcl>for {set i 1} {$i < 40} {incr i} {
[code]
tcl>set regexp {ADT_A(10|12)}

tcl>for {set i 1} {$i < 40} {incr i} {

[Darren Tomlinson]

i did the dump.  here is what i got…

$ hcidbdump -e -m 0.0.2444961 -L -c

msg: 0x3000003c

   msgType           : DATA

   msgClass          : ENGINE

   msgState          : Unsupported Trxid (101)

   msgPriority       : 5120

   msgRecoveryDbState: 3

   msgFlags          : 0x8002

   msgMid            : [0.0.2444961]

   msgSrcMid         : midNULL

   msgSrcMidGroup    : midNULL

   msgOrigSrcThread  : Ser_ndADT_Rcv3

   msgOrigDestThread :

   msgSrcThread      : Ser_ndADT_Rcv3

   msgDestThread     :

   msgXlateThread    :

   msgSkipXlate      : 0

   msgSepChars       :

   msgNumRetries     : 0

   msgGroupId        : 0

   msgDriverControl  :

   msgRecordFormat   :

   msgRoutes         :

   msgUserData       :

   msgStaticIsDirty  : 0

   msgVariableIsDirty: 0

   msgTimeStartIb    : 1200505170.918

   msgTimeStartOb    : 1200505145.686

   msgTimeCurQueStart: 0.000

   msgTimeTotalQue   : 0.001

   msgTimeRecovery   : 1200505170.925

   msgEoConfig       : 0x0

   msgData (BO)      : 0x30000120

   message           : ‘MSH|***i’ took out the patient data on purpose***x0d’

xlate error

…so does that mean there is a problem with the translation then, not the trx_id?  if so, how do i figure it out from here?

My Level 1 training was through McKesson, not Quovadx.  Actually, i am coming to texas next week for Level 2 from Quovadx.

Further note, i now have a few messages from a different process that are in State 101 where the route is set up as static…further making it seem to be a translation issue.

[David Barr]

Darren Tomlinson wrote:

i think i am more lost now than before.

[James Cobane]

Darren,

Is this the actual data in the message(‘MSH|***i’ took out the patient data on purpose***x0d’), because this would bomb for an invalid TRXID, as there isn’t an event type (i.e. ADT^A01, etc) in MSH:9.  If this is not the actual data message( assuming you had edited it for posting), then the ‘xlate error’ message would indicate that there is something happening in the Xlate.  I would dump the message to a file, and run it through the testing tool using the appropriate Xlate; you should see the error occur in the tester.

Jim Cobane

Henry Ford Health

[Darren Tomlinson]

the ‘MSH|***i’ took out the patient data on purpose***x0d’ i put in on purpose for posting.  you know, HIPAA and all…

1) if i save the messages from the error database and run that file through the testing tool, they do not fail.

2) if i resend an errored message from our HIS system, it has gone through on a second try.

3) the one errored message was from a thread that was being sent raw with no xlate, so i dont think it is an issue with an xlate

i changed over my routes to a style like ADT_A(01|02).  we shall see if any more error out…

[Chris Williams]

Here is a good, single page, cheat sheet I found for regular expressions:

http://www.night-ray.com/regex.pdf” class=”bbcode_url”>http://www.night-ray.com/regex.pdf

[Chris Williams]

Darren,

You need to post only the MSH segment which does not have any patient identifiable data in it.  Specifically, what is in MSH-9 on the inbound message? You should see something like |ADT^A08|.

Nobody has asked, but what do you have set up for “Trx id determination Format” on the Inbound tab of your inbound thread? It is the value that is returned from here that the regular expression in the Route Detail must match. When it doesn’t match any of the routes, you get “Unsupported Trxid”.  This is also where the ADT^AXX gets converted to ADT_AXX. Whether you have an xlate really has nothing to do with it.

[Mark Thompson]

You might want to check the format of your regular expression.  Unless I am reading the documentation wrong, stuff inside a square brack represents all the things that match a single character.  So

ADT_A[10,12] will match ADT_A1 ADT_A0 ADT_A, ADT_A1 (again) or ADT_A2.  It does’t matter what comes after these (so all the ADT_A10 – A19 and A20 – A29 work).

If you just want ADT_A10 or ADT_A12, try something like ADT_A1[02]

- Mark Thompson
HealthPartners

[Darren Tomlinson]

“Trx id determination Format” is defined as 2.2 HL7.  so that is not it.

Note that so far, after switching the routes to ADT_A(01|02) style, nothing has errored out as of yet…

[Bala Pisupati]

Can you check and see if the Xlate has been configured with the right variant.

Open the Xlate and go to file -> reconfigure and see if the format you picked for inbound or outbout is ok.

I know it sounds simple but sometimes that might work. Good Luck  😉

[Bala Pisupati]

Can you check and see if the Xlate has been configured with the right variant.

Open the Xlate and go to file -> reconfigure and see if the format you picked for inbound or outbout is ok.

I know it sounds simple but sometimes that might work. Good Luck  😉

[Author]

Replies