tbllookup within Alert

[Greg Eriksen]

We have a tcl proc called “alertTrigger.tcl” that is supposed to be used in Alerts to allow us to pass various values to the tclMail package to customize the to list, subject, message body, etc. of alert emails.

Topic

[Michael Hertel]

Could you post your proc and post the results of:

ls -li /quovadx/qdx5.4/integrator/clotest1/Tables/alertTrigger_emails.tbl

[Greg Eriksen]

Hi Michael,

The result of the command is:

221418 -rw-r

---

  1 hci      staff           534 Jun 12 13:22 /quovadx/qdx5.4/integrator/clotest1/Tables/alertTrigger_emails.tbl

I’m not sure how much we “own” the entire alertTrigger.tcl proc, but the section covering the customization we asked for is:

       #build final email list

set final_email_list “”

       foreach email $emails {

   if {[string first “@” $email] >= 0} {

#found “@” sign, this is an email address

lappend final_email_list $email

   } else {

#do table lookup and append each additional email address

set table_emails [tbllookup /quovadx/qdx5.4/integrator/clotest1/Tables/alertTrigger_emails.tbl $email]

foreach new_email [split $table_emails] {

   lappend final_email_list $new_email

}

   }

}

The variable $emails is one of the parameters passed into the proc when it is called.  In this instance it contains 2 items, my email address and a lookup string “cbordList”.  Because the latter doesn’t contain the “@” sign, it is supposed to be used as the value for the table lookup.  From the hcitcl prompt, a lookup to the table with this string returns the 2 additional email addresses I expect.  I had inserted an echo statement after the else in the above and confirmed that the variable $email is getting set to “cbordList” prior to the lookup.  I’ve tried the path both with and without backslash escaping the forward slashes, and the original code didn’t have an absolute or relative path, just the table name.

Your request for the command caused me to pay attention to the permissions on the table file, and I did notice that they were not the same for that table as the others in the directory.  I used chmod to make it match the others so that the output from your command is now:

221418 -rw-rw-r–   1 hci      staff           534 Jun 12 13:22 /quovadx/qdx5.4/integrator/clotest1/Tables/alertTrigger_emails.tbl

Then I killed and started the monitor daemon, recreated the conditions that cause the alert to trigger, but I still see the same “unable to load table” error in the log.  Is boucing the monitor daemon enough, or do I need to stop and start the entire engine process in order for it to be able to find the table?

[Michael Hertel]

Try this:

set table_emails [tbllookup alertTrigger_emails $email]

There was a bug about using .tbl I’ll look for info on it.

Let me know if it works and I’ll get back to you on the bug.

[Michael Hertel]

I found something in the old archives…

It’s from 2004…:

Date:  Thu, 30 Dec 2004 15:35:45 -0600

Author:  “Charlie Bursell” <charlie.bursell@quovadx.com>

Subject:  RE: Table Lookup in Alerts

Body:  This is a multi-part message in MIME format.

---

=_NextPart_000_0015_01C4EE85.3B8528A0

Content-Type: text/plain;

charset=”iso-8859-1″

Content-Transfer-Encoding: 7bit

RE: Table Lookup in AlertsHowever, if Table Lookups are something you need

to do via Tcl from the Alerts, let me know and I’ll provide you a

work-around.

Charlie

---

Original Message

---

From: bounce-clovertech-586@ajax.quovadx.com

[mailto:bounce-clovertech-586@ajax.quovadx.com]On Behalf Of

Mark.E.Thompson@HealthPartners.Com

Sent: Thursday, December 30, 2004 2:19 PM

To: Technical Issues

Subject: [clovertech] RE: Table Lookup in Alerts

As confirmed by Quovadx Support:

When using a Tcl proc in an alert action type of Tcl, the proc will fail

if it contains a table lookup. The same proc will work if it is called with

an exec action. For example, if I have a proc named alert_test that

contains a table lookup, the action {tcl alert_test} with fail with an

“[aler:aler:ERR /0: hcimonitord] Tcl error: unable to load table

‘mytable.tbl'” error, but the action {exec {hcitcl -c ‘alert_test’}} works

fine. This has been confirmed on 5.3 (no revs) — not sure if it is true on

other versions.

-Mark

[Anonymous]

Greg,

try the following:

1. based on the error, tcl script could not find the path for the tbl file or permission may not be correct.

  try changing +x for +gu

2. check your environment variables as well.

    env | grep

   you will see what is setup out there.

Reggie

[Greg Eriksen]

Wow, thanks for all the responses.  It had looked like I maybe needed Charlie’s workaround (whatever that is), but I tried out all of your suggestions.

Reggie, I modified the permissions you recommended, but no go.  And I had been thinking along the same lines as you about it being a problem with environment settings between me running both the lookup and the entire alertTrigger proc successfully from hcitcl, and the Monitor Daemon not being able to.  So I had inserted the following lines at the start of the proc:

#

global env

echo rootdir: $env(HCIROOT)

eval [exec $env(HCIROOT)/sbin/hcisetenv -root tcl $env(HCIROOT) clotest1]

setHciDirs

#

It didn’t seem to cause any new errors, but it didn’t help either.

Michael, I removed the “.tbl” extension from the table name being referenced in the proc, and tried it with and without the path, but no change in the error when called by the alert.

Finally, I thought I would have to hear from Charlie what his workaround was, but the bottom of the original archive email posting from Mark seemed to be saying that a tcl proc with a tbllookup would work from an alert if the “alert action” defined was “exec” rather than “tcl”.  My first attempts at this made the error disappear from the site daemons log, but I didn’t get any emails produced either.  The “exec” action seems to automatically add an ampersand “&” at the end of the action, thus making it a background process.  As such, the echo statements I’d inserted in the proc were no longer displaying in the log, so I couldn’t tell how much of the proc was actually being run anymore.  After much trial and error, it eventually sunk in that I had to surround the entire string (proc name + 7 parameters) with the single quotes after the “hcitcl -c”.  When I define the action for the alert as the following, it now works:

{exec {hcitcl -c ‘alertTrigger “grege@mmc.org cbordList” “WARNING – to_cbord exceeded queue count” “The to_cbord connection has exceeded queue maximum.” “gemini.mmc.org” “mmc.org” “” “”‘}

I don’t know if this was in fact Charlie’s workaround or if he had something else, but my thanks go out especially to Michael for remembering and digging up that old posting from the archive.  I was getting nowhere with this, and while there’s about a day-and-a-half of my life I’ll never get back due to this particular undocumented monitor daemon quirk, at least it didn’t end up in me committing seppuku.

[Greg Eriksen]

Charlie Bursell found and sent me a substitute proc (tblGet) for the tbllookup function that will work within a regular “tcl action” from an Alert.

[Keith McLeod]

Anyone have a modification to this tblGet proc from Charlie that supports the original value if checked?  It tends to work nicely when used in tcl based alerts and doesn’t require a bounce of the monitor daemon when modifying any of the tables being used.

The only issue I have found is the support of Keep Original Value instead of default. Some instances this would be helpful. Thoughts?

[Keith McLeod]

Think I got it…

Added to this section:

# Get default value

   set dflt [TioGetDefault 1]

   set passThru [TioGetPassThrough 1]

# If the value does not exist, Just return default

   if {![TioExists 1 $val $side] && $passThru == 1} {

       return $val

   } else {

       return $dflt

   }

This appears to do the trick.  If there is a better way, I appreciate the guidance/advice.

[Keith McLeod]

Not quite.  If there is a default value even though it is not checked, it will copy it.  Guess it needs a little more tweaking.

[Keith McLeod]

This looks to be working…

   # Get default value

   set dflt [TioGetDefault 1]

   set passThru [TioGetPassThrough 1]

   # If the value does not exist, Just return default

   #if {![TioExists 1 $val $side]} {return $dflt}

   if {![TioExists 1 $val $side] && $passThru == 1} {

       return $val

   } elseif {![TioExists 1 $val $side] && $passThru == 0} {

       return $dflt

   }

[Author]

Replies