Messages not routing with proc in place

[Scott Smith]

I am using 5.6 on AIX.

Topic

[Bob Richardson]

Greetings,

I do not see any return of your dispList list of message handles.

There is a commented out line – part of your debug?

Anyway, a good coding practice is to set the dispList variable to null

at the top of your proc and return its contents just before the last line

in your proc.  If you don’t return this list of message dispositions you get leaky handles and of course the engine doesn’t know what to do with these messages.

In running the tester always check the “leak detection” box – a good habit to get into for testing tcl, xlates, whatever.  By running your code you should see leaking handles warning messages idisplayed by the tester.

[Scott Smith]

Thanks Bob.

I fixed that error, now I getting

[0:TEST] ‘CONTINUE’ (returned by ‘tpsfilterdoccw_tbl ‘) does not match { }

[0:TEST] ‘message0’ (returned by ‘tpsfilterdoccw_tbl ‘) does not match { }

I don’t think I have seen this one before, do you know what it means?

[Bob Richardson]

Scott,

     You need to change the “set” command to “lappend” for your

variable dispList.  The engine expects a list of “disposition message handle”.

      This will fix the problem.

      Enjoy.

      BobR

[Scott Smith]

Bob,

It  must be one of those weeks.  I changed both “sets” to lappend and now I get the “bogus msgStrId…: error.  

Could it have something to with that I am killing the message by default and if it is found in table to continue the msg?

[Bob Richardson]

Scott,

If you are killing the message by default, you need to unset the dispList

variable and reset it to your continue dispostion.  Yes, if you killed the message first then you cannot continue it.

Logic like so:

set dispList {}  ;#create and initialize to the empy set

run {   lappend dispList “KILL $mh”  ;#default disposition

         

         (after some logic you decide to continue this message)

          unset dispList

          lappend dispList “CONTINUE $mh”

[before exiting proc]

         return $dispList

Check the flow of control in your procedure – desk check – run a message through the logic manually and see what happens to it.

I hope this proves useful for you.

BobR

[Michael Hertel]

Scott, can I make two suggestions?

1) Forget about using dispList

2) As you step thru the proc and you know you want to kill the message, return a kill there, otherwise let the message fall thru the rest of the logic and end with a continue.

Code:

proc tpsfilterdoccw_tbl { args } {

  keylget args MODE mode              ;# What mode are we in
 
  switch -exact — $mode {
      start {
return “” ;# Perform special init functions
      }

      run {
keylget args MSGID mh

set msg [msgget $mh]

set fieldSeparator [crange $msg 3 3]

set OBRsegment [getHL7Segment $msg OBR]

set drNumber [lindex [split [getHL7Field $OBRsegment 16 $fieldSeparator] ^] 0]
  set drNumber [crange $drNumber 0 3]

if {[cequal [tbllookup tblphysicians_cw $drNumber] KILL]} {
return “{KILL $mh}”
}

shutdown {
# Doing some clean-up work
}

default {
error “Unknown mode ‘$mode’ in tpsfilterdoccw_tbl”
return “”                   ;# Dont know what to do
}
  }

  return “{CONTINUE $mh}”

}

[Scott Smith]

Mike,

I like those.  I was trying to use a already proc and modify it.  That looks much better.

And Bob thanks for the debugging help – I finally got it going.

[Tom Rioux]

One thing I would suggest with Michael’s code is to get rid of the “getHL7Segment” commands.  As Charlies always preaches, stay away from looping, which is what I believe this command does.  Replace it with an “lsearch” command.  You should be able to find many good examples on here of how to use this command.

Thanks…

Tom Rioux

Baylor Health Care

[Author]

Replies