As a staple part of the Netcool/Webtop product, which is now shipped as Netcool/OMNIbus Web GUI, the Map interactive graphical view feature has been around for a long time but a recent customer engagement reminded me how useful it can be when there is a need for a high-level or management style dashboard view.

If you are not familiar with them, Maps are applets that typically consist of a background image of some sort, overlaid with Map objects such as icons, text, buttons or monitor boxes.  The objects can be made active, in which case they are linked to an event filter and their appearance is changed to reflect the highest severity alert returned by the filter.

Whilst the visualisation capability of Maps and child objects themselves are pretty basic, the overall effect can be significantly enhanced through the use of SmartPage commands.  SmartPages are essentially static HTML pages that contain Web GUI specific SmartPage command mark-up. This mark-up enables Web GUI elements such as Maps or Active Event Lists to be embedded in a page, which means you can build a page that uses your standard company branding and styling whilst at the same time exploiting the functionality offered by the Web GUI visualisation elements.

Another nice feature of Web GUI is the Web GUI Administration API, or WAAPI for short.  This XML based API provides an alternative to administrating Web GUI via the Tivoli Integrated Portal and is particularly useful for carrying out automated tasks or bulk operations.

The WAAPI interface proved to be invaluable in the recent engagement where there was a requirement to build a hierarchy of Web GUI Maps to represent the component and application topology of a service.  With a service potentially consisting of multiple applications, each of which could rely on many components, creating the Web GUI elements by hand just wasn’t feasible.  As the relationship information between the services, applications and components was available from a configuration database it was possible to write some code that processed an extract of the configuration information, determined the service topologies and generated the WAAPI XML required to create and layout the necessary Web GUI Maps and Filters (some 2000+ entities in all).

The code was written in Perl and used Moose to encapsulate the various WAAPI method calls and objects, resulting in the following sort of syntax:

# Create a new WAAPI request
my $request = WAAPI::Request->new();

# Create a new Map
my $map = WAAPI::Map->new( name => $name );        

# Create a new method
my $method = WAAPI::Method->new( 
            methodName => 'map.createOrReplaceMap', 
            elements => [ $map ]);

# Create a Map Button
my $btn = WAAPI::Map::Button->new( 
            name     => $btn_name,
            label    => $btn_label,
            filter    => $filter,
            filtertype => 'global',
            target => '_self',
            type => 'rounded',
            font => 'Arial',
            size => 11);

# Add the Button to the map            
$map->add_element($btn);

# Add the method to the request
$request->add_method($method);

# Print out the resulting WAAPI XML
print $request->to_xml, "\n";

By using a Netcool/Impact policy to enrich incoming alerts and populate them with their respective CI details, it was then possible to visualise the impact an alert raised against a component had on the upstream applications and services.

Visits: 148