TBSM has the ability to present many different types of service views and a common request is to display that data on a geographical map. For predefined service instances this is a relatively simple job of defining the GIS attributes (Longitude and Latitude) along with the other service instance properties. However, for auto-populated services the set-up is a little more complex. This article will discuss the set-up of a GIS based view where services are auto-generated from OMNIbus alarms.
The Basic Scenario
Consider a scenario where network events are received from nationally located retail stores. The dashboard (service view) required is a geographical map of the country with icons indicating service degradation for specific locations.
TBSM can position a service on a GIS image using longitude and latitude coordinates associated with the service instance. So the challenge is to auto-generate a service instance from the event and assign the GIS coordinates to that instance.
Assuming the base TBSM infrastructure already exists, including the mechanism for the receipt of the network events (a probe) and they are being suitably formatted and inserted into the Netcool/OMNIbus ObjectServer, the event processing steps are as follows:
- Automatically create a service instance
- Identify and assign the GIS coordinates to the service instance
- Position the service instance on a service view based on the coordinates
- Ensure the service instance disappears once the problem is closed
These steps are discussed below.
Automatically creating a service instance
For the example a simple two tier service model was used, resulting in a parent service template “AnyRetail_National_Stores_Template” containing the service template for the individual stores “AnyRetail_Store_Template”.
The store template used a basic auto-population rule to create a store instance based on the “Location” field from the event. In this case the Location field included the name of the town of the affected store. The parent instance & display names were configured as the literal “AnyRetail”.
Identify and assign the GIS coordinates to the service instance
To correctly locate a service instance on a GIS image it must have values assigned to the Longitude and Latitude attributes. When manually defining a service instance these attributes are defined from the tab labelled Additional. For an auto-population service instance the assigning of values to the attributes must be automated. This can be achieved through the use of a custom policy.
It is likely that the GIS coordinates will need to be reference from an external source using event field values as a lookup. The example events have the town populated in the Location field, as per the figure below.
The location can be mapped to longitude and latitude coordinates in various ways, for example by a Probe lookup, OMNIbus ObjectServer automations or Impact policies within TBSM. Using an Impact policy does give the advantage of being able to integrate dynamically to external data. A number of web-sites exist that facilitate mapping town names or post codes to coordinates, however, accessing those sites directly from a policy may adversly affect performance. In this example a DB2 database was populated with the relevant data, and an Impact data type and data item configured to access the database and table, respectively. The unfiltered results from the data item are displayed below.
This data can be queried from an Impact policy, the returned values assigned to the Attributes object hash, specifically the Longitude and Latitude items within the hash, as demonstrated in the screenshot below.
The policy must be run by the autopopulate rule, defined from the Custom Configuration dialog. Select the Use Policy For Service Properties and the Edit policy link.
Finally, you may wish to set the template properties, from the Edit Properties link in the main template properties section. By default the autopopulated service instance is persistent. However, service instances can be automatically deleted once the associated event is deleted. Two properties control this behaviour, Persistify AutoPopulate Instances is a boolean value the disable or enables the automatic deletion and Invalidation Period (seconds) sets the time period between the event and instance deletion.
Note: The file $TBSM_HOME/etc/TBSM_sla.props does include example properties indicating that event field values can be used to populate the coordinate attributes, however these do not appear to work.
Position the service instance on a service view based on the coordinates
From the standard Service Availability page it is possible to display the default geographical map from the Service Viewer. Select the parent service instance from the Service Tree, and then the GIS option from dropdown menu in the Service Viewer. The default image is a world map. To change the map to something more suitable set the MapName property for the service template from the Additional tab. Do this for the parent service template. The figure below demonstrates the use of the European map shipped with the product.
Ensure the service instance disappears once the problem is closed
You may wish to create a specific view for the parent service instance. The advantage of this is that you can define specific properties and actions that apply to the view. For example the characteristics of the icons that represent the child service instances (the stores in the example) and visual threshold filters. The visual properties dialog is demonstrated below, and includes the visual threshold for making a service instance invisible once it is in a “green” state.
The view can be embedded within a new page to provide the “home-page” for a specific user. This may be suitable as a high-level dashboard. The final configuration results in a coloured icon displaying on the geographic map when the service for a specific store is degraded. To prevent clutter those icons are then removed once the problem has been resolved.
Creating such dashboards from TBSM can provide a very useful higlevel summary of service status and may assist identifing regional issues. As with any TBSM infrastructure, the ability to correctly map events to a service instance is vital, but once that ground work has been completed successfuly the geographical based service view can be very powerful.