Perhaps it would help if you think of each node in the ruleset as a kind of
"go-nogo" filter. You start with the events stream and then have a test for the
type of trap you are looking (Node up, Cisco link down, whatever). This is
important because you absolutely do not want to query the collection for every
trap the system sees -- you ill create a performance bottleneck that will drive
your system to its knees. From the trap setting you connect to a
QueryCollection node which checks for membership in that collection, using
origin or attribute 2 (for NetView traps) as appropriate. At this point only
those traps which match that criteria pass on to the next node. So here you
hang your next check, whatever that may be (isRouter?). Those events which
match that criteria pass on. Those that don't are thrown away. So you would
indeed have to add another branch if you want other processing for non-router
nodes.
If the logic gets too complicated you may want to consider making
sub-collections of your collection to simplify things.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
|