Event Sensitive Help from the TEC Console

One of the most common requirements of any event management tool is to have some way of recording information about an event in order to help other operators understand what that event means to the business and what actions they should take.

Most organisations have highly sophisticated trouble ticketing systems like Remedy, Vantive etc, however most organisations only raise trouble tickets for the most critical events. These problems are then tracked and any resolutions recorded to help in future problem determination.

What happens to the other events that aren't so critical - but are nevertheless still problems. Generally information about these events are stored in flat files or more often than not in peoples heads. When the problem occurs again, unless you know where to look or whom to ask, an operator will have to learn all about that problem again.

Over the next couple of weeks I will present solutions for tackling this problem, for giving the operators the right information at the right time. The first solution will simply describe a mechanism that you can employ to display descriptions, resolutions and related information about a particular event. Next weeks solution will go further presenting a more advanced solution storing and retrieving information in from a database.

Simple Event Help

In this first solution all we're going to provide is a button on the TEC console which allows an operator to select a particular event, launch a Web Browser of some description (in this example we'll use Netscape but you could quite easily use Explorer or NeoPlanet or some such other browser) that contains an existing HTML file containing helpful information about that event.

Modifying the Event Console

Events are displayed in the Event Group, part of the Event Console - or EnterpriseClient (which is what the Event Console resource is known as). Like other aspects of Tivoli the EnterpriseClient can be modified using AEF (Application Extension Facility). AEF allows the modification of some existing dialogs, unfortunately the EnterpriseClient has various components that cannot be modifed at all. AEF can also be used to get information out of gadgets.

The first thing we need to understand is how exactly are we going to get the information about an event, in particular the class - as this will be our primary key.

The main console window is generated from the dialog egMessageList.

This can be retrieved by performing the following:

Within this dialog events are displayed in a Table Gadget, which contains rows of events and columns of event attributes (or slots). At the present time there is no way to access any of the information within a table through AEF, the best we can hope for is to get the row number of the table and the table name itself. This is used to find out which event has been selected, for instance the following DSL extract to acknowledge an event you'll see these three attributes being passed to the mod_event method ie

where $table_name holds the name of the table and $table_grp.MessageTable holds the row number of the selected event (or events).

As we cannot access the event details directly we need to find some other way of getting the data. Luckily Tivoli provide an internal mechanism for generating Trouble Tickets. This is the bare bones solution as most trouble ticketting system are completely different.

Internally a callback is provided called run_extern_cmd, that gets the data from the table for the selected row and passes it to an external script as environment variables. If we look at the existing menu item for Trouble Ticket you'll see this used

An additional fetaure of this method, is that you pass your own script to it to run rather than the standard TroubleTicket.sh ie replace the third argument with the name of your script eg

This is argument is then passed as ARGV1 to the ToubleTicket.sh script. From this you could ten invoke another script.

So taking all of these parts we can create a new button on the TEC ie

Now we've edited out DSL file we can now update the dialog

• First compile the DSL code

dsl egMessageList.dsl > egMessageList.d

• Now replace the old dialog with the new

wputdialog -r EnterpriseClient egMessageList < egMessageList.d

• Now closedown any open consoles and restart them

The new dialog looks like the following

Running Something External

Now we have our button, when we select an event and hit the Event Helper button, the script $BINDIR/TME/TEC/TroubleTicket.sh will be executed. This file by default is just a bunch of comments. To actually do something eg launch a web browser we need to add the relevant commands.

Getting Event Data

To begin with we'll just add the command 'env' > TroubleTicket.out, just to show the environment variables that are set.

The file created in $DBDIR contains the following list of environment variables - those relating to the Event have been highlighted

As you should be able to see all of the information about the event is available - including data from custom slots eg list (even though in the comments in the TroubleTicket.sh it says only a few key values are available!). You can therefore process all of the data in the event.

Often you will not know what slots are set for what events so the environment variable $SLOTS is very useful as it defines the names of all the slots available. Note here though that class is not defined as environment variable - instead it is held in the $CLASS_NAME variable.

Launching a Browser

Armed with the data now, you can do something like fire up a web browser (or notepad, or someother application). In the following example we'll fire up Netscape.

On NT

As the process that will launch the browser does not own the NT Window, you can't just run the app and hope it displays. There is however a Tivoli supplied command - wrunui that will allow you to display another application.

In out TroubleTicket.sh script we're going to modify it to fire up Netscape as follows

All this will do is launch Netscape with a pre-written HTML page (event_help.html) and it will focus on the target $CLASS_NAME eg

On Unix

Things are a little simpler on Unix, as we can address the desktop directly and as long as the current user of the desktop have allowed everyone to access their screen (eg xhost +) we should be able to display.

Again we need to modify the TroubleTicket.sh script as follows:

This will act exactly as before on NT