Business Service Management

Home > Integration Scenarios > Integrating TBSM 3.1 and TBSM 4.2 - An ESDA Solution

Integrating TBSM 3.1 and TBSM 4.2 - An ESDA Solution

This white paper provides information about integrating IBM® Tivoli® Business Systems Manager (TBSM) 3.1 and TBSM 4.2.

Overview

The IBM® Tivoli® Business Systems Manager (TBSM 3.1) ESDA feature is designed as an aid for representing TBSM 3.1 Business System folders in an IBM Tivoli Business Service Manager (TBSM 4.2) system. This feature utilizes the External Service Dependency Adapter (ESDA) capabilities of TBSM 4.2 to accomplish this task. The TBSM 4.2 feature incorporates knowledge of the TBSM 3.1 database schema that would not generally be known to a customer trying to develop this capability on their own.

This paper discusses 3 main topics:

• Installing and Configuring the TBSM 3.1 ESDA feature
• Comparing the 3.1 and 4.2 models
• Exploiting TBSM 4.2 - Enhanced Executive Dashboard

Terminology

Table 1 includes definitions of several key concepts from TBSM 3.1 and TBSM 4.2.

Table 1: Key concepts for TBSM 3.1 and TBSM 4.2

Description

In its default form, the TBSM 3.1 ESDA feature discovers business system folders and creates corresponding services in the TBSM 4.2 system. Dependencies are created in TBSM 4.2 to reproduce the business system folder hierarchy that exists in TBSM 3.1. For business system folder shortcuts, a single 4.2 service is created. The multiple contexts that the shortcuts represent become additional dependencies in version 4.2. This behavior can be modified and this topic is covered in more detail later in this paper.

It is important to note that business system resources are not collected from the TBSM 3.1 system for representation as version 4.2 services. Business system resources represent a broad range of classes of TBSM 3.1 physical resources, and there are potentially large volumes of these resources. This feature is focused only at the business system folder level, and attempts to create a service model that is primarily of interest to executives, business service owners, or business application owners.

To retrieve the TBSM 3.1 service model, a data source is defined by this ESDA feature. It must be configured to access an existing TBSM 3.1 database server. In addition, a data fetcher is added to TBSM 4.2 that periodically gets status data for the business systems from the TBSM 3.1 database and reflects the status on the TBSM 4.2 services.

Users of this package should be familiar with TBSM 3.1. Configuration requires some administrative authority in the TBSM 3.1 Console. Knowledge of the TBSM 4.2 ESDA feature is required to understand how the service model is built from the queries against the TBSM 3.1 database. Finally, familiarity with the TBSM 4.2 Console is needed to take full advantage of the service model created by this feature.

Installing and Configuring the TBSM 3.1 ESDA Feature

This paper is supplemented with a set of attachments that are used to install and configure the TBSM 3.1 ESDA feature. These attachments include the following items:

• A set of files with the extension "update" that is used to set up the optional launch capability for the TBSM 3.1 Web Console
  
  
• A set of icons used to represent the TBSM 3.1 business services in the TBSM 4.2 service model
  
  
• A set of scripts that can be used with the TBSM 4.2 rad_radshell utility to configure the service model to be created by the TBSM 3.1 ESDA feature

The following information should be noted prior to beginning the installation:

Several TBSM 4.2 environment variables are referenced in this paper, including:

• TBSM_HOME: Home directory for TBSM utilities and other product files

• TBSM_DATA_SERVER_HOME: Home directory for TBSM 4.2 data server

• TBSM_DASHBOARD_SERVER_HOME: Home directory for TBSM 4.2 dashboard server

• TIP_HOME: Home directory for TBSM 4.2 Tivoli Integrated Portal installation

When referencing the environment variables on Windows® systems, use the syntax %variable%. On UNIX® and Linux® systems use the syntax $variable. This paper uses only the variable name with no variable indicators when no platform context is indicated.

On Windows systems, the environment variables are set by the installer. On UNIX and Linux systems, you must source TBSM setup scripts to set the environment variables. Switch to the TBSM installation directory (default /opt/IBM/tivoli/tbsm). Run the following commands on the TBSM Data server and Dashboard server, or run both if the servers are on the same system. Note the period mark (.) followed by a space for sourcing the scripts:

• . bin/setupTBSMData.sh **(Data server only)

• . bin/setupTBSMDash.sh **(Dashboard server only) **

Directory specifications in the installation instructions use the UNIX and Linux style forward slash separator (/). For Windows systems, be sure to replace all forward slashes with the backward slash ().

Always make a backup copy of any file being updated or replaced by these installation instructions.

Add icons for TBSM 3.1 services

The icon images used for business systems in TBSM 3.1 are used for the services created in TBSM 4.2. The following update only adds new files to the target directories.

1. Switch to TBSM_DASHBOARD_SERVER_HOME/icons directory.
   
   
2. From the attachments, copy the TBSM31_bussys_svg.gif. icon file
   
   
3. Switch to the svg subdirectory.
   
   
4. From the attachments, copy the TBSM31_bussys.svg icon file.

Default configuration

The default configuration creates the templates to be used for TBSM 3.1 services. TBSM31_Model **is the primary template and contains the ESDA rule for retrieving the service instances from the TBSM 3.1 database. The TBSM31_Status template defines a rule for determining the status of a 4.2 service based on the results of a data fetcher that runs against the 3.1 database.

As noted earlier, this default configuration collapses the TBSM 3.1 shortcut folders into a single 4.2 service instance. In addition the default configuration creates the data source and data fetcher used to retrieve data from the TBSM 3.1 database. It also creates one or more seed services, based on the TBSM 3.1 top level business systems that are to be reflected in 4.2.

Preparing for the default configuration

The following information is required to configure the TBSM 3.1 ESDA feature:

• The host name or IP address of the TBSM 3.1 database server system, and the port number being used by the database server, if not the default for Microsoft® SQL Server

• A user ID and password that can access the TBSM 3.1 database

• The host name or IP address of the TBSM 3.1 Console server system, and the port number if the default TBSM 3.1 value is not being used

• The ID, display name, and description of the top level TBSM 3.1 business systems to be added to the TBSM 4.2 service model. The display name and description are available from the TBSM 3.1 Console. An Administrator can turn on the cid:id display in the TBSM 3.1 tooltips function using the Administrator Preferences window. Then the cid:id are available by hovering over a business system with the mouse pointer. The id values are required, while the cid is not required because only LOB resources are retrieved from TBSM 3.1.

Default configuration - Templates, data source, and data fetcher

The first step in the default configuration is to define the templates to be used for TBSM 3.1 based services and the data source and data fetcher used to access the TBSM 3.1 database. Run the following steps to begin the default configuration for the TBSM 3.1 ESDA feature.

1. Edit the tbsm31esda_config.radsh attachment file. Look for all occurrences of the string "CONFIGURATION REQUIRED" and follow the instructions in the comments to configure the settings.
   
   
2. From the directory containing the modified attachment file, run the following command:
   
   Windows systems: type tbsm31esda_config.radsh | %TBSM_HOME%\bin\rad_radshell.bat
   
   UNIX and Linux systems: cat tbsm31esda_config.radsh | $TBSM_HOME/bin/rad_radshell
   
   
3. See 2.3.2, "Create services for TBSM 3.1 business system folder shortcuts", for an alternate configuration for the template.
   
   Important: The template configurations are mutually exclusive, so only one can be applied to a single TBSM 4.2 system. To switch configurations, first remove any services and templates created with the previous configuration. See 2.4, "Removing the templates, services, data source, and data fetcher", for more information.

Verify the results by looking for the following in the Service Navigation portlet of the TBSM 4.2 Service Administration page:

• Templates navigation view: templates named TBSM31_Model and TBSM31_Status

• Data navigation view: a data source named TBSM

• Data Fetcher navigation view: a data fetcher named TBSM_AlertStatus

• If the expected results are not seen, see section 5 "Troubleshooting".

Tips for using ESDAs in TBSM 4.2

The behavior of services with ESDA rules is controlled by a special set of properties. ESDA services must become "invalidated" in order for the ESDA rules to run. Even then ESDA rules are only run when a service is expanded in the tree view or when a canvas view requires the dependencies of a service in order to show the complete view.

By default, the services created by running the ESDA rules included in this feature are automatically invalidated every 60 seconds. This means that there is minimal delay in detecting when business system folders have been added and deleted in TBSM 3.1. However, it means more execution of the SQL queries in the ESDA rules, and thus more overhead for the TBSM 4.2 server.

See Figure 1 for an illustration of how to access the ESDA properties and change the invalidation period from the Template editor page.

Figure 1. Setting the Invalidation Period for ESDA services

Important: The services tree in TBSM 4.2 does not automatically add and remove services from nodes that are expanded or have been expanded. One of these nodes could be a TBSM 3.1 based service that has been invalidated and will be adding or removing services when the ESDA rule is next run. It is necessary to refresh the 4.2 services tree and click the expand button again to drive the ESDA rules for such an "expanded" node.

See the TBSM 4.2 Service Configuration Guide for detailed information about working with ESDAs.

Tips for using data fetchers in TBSM 4.2

Data fetchers have various properties that can be set to tune the performance and to make the behavior more like the standard event processing behavior for the Omnibus events. By default, each data fetcher caches 100 rows retrieved by the last run of the fetcher. This number can be set to more closely match the amount of rows actually being retrieved.

On the next fetch of the data, the results are compared to the cached results and only changed rows are processed. The idea is to limit the number of rows that must be compared to the incoming status rules that use the fetcher across all the templates.

This behavior is not well suited for this feature, as the services created by ESDA rules might not yet exist when the data fetcher starts running. Thus the data fetcher in this feature uses a filtering expression to ensure all rows of data are processed on each call of the data fetcher, keeping the status from TBSM 3.1 as current as possible. This disables the default caching that typically occurs for a TBSM 4.2 data fetcher.

The data fetcher is coded as efficiently as possible, but will likely retrieve more business systems instances from TBSM 3.1 than there are corresponding services in TBSM 4.2. A small amount of data is retrieved for each row, and only one rule is defined to use the data fetcher, so the performance should not be adversely affected.
See the TBSM 4.2 Service Configuration Guide for detailed information about working with data fetchers.

Default configuration: Seed services

The second step in the default configuration is to define the seed services to be created in TBSM 4.2. These services correspond to the top level TBSM 3.1 business systems that you want to display in the TBSM 4.2 service model. Run the following steps to complete the default configuration for the TBSM 3.1 ESDA feature:

1. Edit the tbsm31esda_selected_seeds.radsh attachment file. Look for the string "CONFIGURATION REQUIRED" and follow the instructions in the comments.
   Select only top level TBSM 3.1 business systems that are to be represented in TBSM 4.2. The id and the display name are required for the TBSM 3.1 business system (LOB) folders to be retrieved. The TBSM 3.1 description can be used, or any preferred text can be specified. The business system folders specified in this file must not be business system folder shortcuts or business system resources.
   
   Important: It can be beneficial to start with a single business system folder to verify that the feature is installed and configured correctly. Later, you can run the script as many times as necessary to add additional top level business systems.
   
   
2. From the directory containing the modified attachment file, run the following command:
   
   Windows systems: type tbsm31esda_selected_seeds.radsh | %TBSM_HOME%\bin\rad_radshell.bat
   
   UNIX and Linux systems: cat tbsm31esda_selected_seeds.radsh | $TBSM_HOME/bin/rad_radshell
   
   
3. See 2.3.3, "Include all top level business system folders", for an alternate configuration for the seed services.
   
   Important: The seed configurations are mutually exclusive, so only one can be applied to a single TBSM 4.2 system. To switch configurations, first remove any services created with the previous configuration. See 2.4, "Removing the templates, services, data source, and data fetcher", for more information.

Using the TBSM 4.2 Console, open the Service Administration page and select the Services navigation view in the Service Navigation portlet. Verify that the seed services that were specified in the configuration are displayed at the root level of the service tree.

If the expected results are not displayed, see section 5 "Troubleshooting".

Optional Configurations

The following sections document the optional configurations that can be performed for the TBSM 3.1 ESDA feature, including the following configurations:

• Launching the TBSM 3.1 Web Console

• Create services for TBSM 3.1 business system folder shortcuts

• Include all top level business system folders

Launching the TBSM 3.1 Web Console

This optional feature adds an action and right-click menu option for launching the TBSM 3.1 Web Console. The cid/id information, as well as the target console server, is configured with each TBSM 3.1 service that is represented in TBSM 4.2. The TBSM 3.1 Business Impact view is launched by default.

The menu item is available as a submenu item of the Integrations menu and will only be enabled for TBSM 3.1 services collected by the ESDA feature. The first launch to the Web Console requires you to log in. If the browser with the Web Console is left open, each subsequent launch uses the same Web Console session and adds additional views.

Important: The following configuration steps can touch several TBSM 4.2 product files. Be sure to make backup copies of the files prior to merging the changes for the launch capability.

To add the Launch capability, complete the following steps:

1. This first step makes the action available for use by TBSM 4.2 menus. Switch to the TBSM_DATA_SERVER_HOME/av/xmlconfig directory. Edit the canvasOpenURLActions.xml file and merge the changes from the canvasOpenURLActions.xml.update attachment file as follows:
   
   
   1. Locate the </canvasConfig> tag: This is the matching end tag for <canvasConfig> and should be at or near the bottom of the file.
      
      
   2. Copy the content of the canvasOpenURLActions.xml.update file immediately above the </canvasConfig> tag. The openURLAction with name="LaunchTBSM31" should now be the last action before the </canvasConfig> tag.
      
      
2. The action will now be added to the Launch to submenu in TBSM 4.2. From TBSM_DATA_SERVER_HOME/av/xmlconfig, edit the canvasDynamicSubMenuActions.xml file. Merge the changes from the canvasDynamicSubMenuActions.xml.update attachment file as follows:
   
   
   1. Locate the <dynamicSubMenuAction> tag with the "name" attribute set to "IntegrationTools".
      
      
   2. Locate the matching end tag </dynamicSubMenuAction>.
      
      
   3. Copy the content of the canvasDynamicSubMenuActions.xml.update attachment file immediately above the end tag located in step b.
      
      
3. This step makes the attributes required to enable the menu item available to the view definitions. Only the following views should be updated, and only if you want to launch the TBSM 3.1 Web Console from the view. For any view definition not updated, the menu item is displayed, but is always disabled.
   
   
   • ViewDefinition_BasicRelationships.xml
     
     
   • ViewDefinition_BusinessImpact.xml
     
     
   • ViewDefinition_BusinessImpactAll.xml
     
     
   • ViewDefinition_Concentric.xml
     
     
   • ViewDefinition_CustomView.xml
     
     
   • ViewDefinition_GIS.xml
     
     
   • ViewDefinition_Grid.xml
     
     
   • ViewDefinition_Relationships.xml
     
     From TBSM_DATA_SERVER_HOME/av/xmlconfig, edit each view that will support the launch. Merge the changes from the ViewDefinition_.xml.update attachment file as follows:
     
     
   1. Locate the </dataTypeMapping> tag: This is the matching end tag for <dataTypeMapping>.
      
      
   2. Copy the content of the ViewDefinition_.xml.update attachment file immediately above the </dataTypeMapping> tag. The new cid, id, consoleServer, and consoleServerPort fields should now be included in the dataTypeMapping definition.
      
      
4. Restart the TBSM 4.2 Data server to pick up the modifications:
   
   
   • Windows systems:
     
     
     1. From Administrative Tools, open the Services window.
        
     2. Right-click "Tivoli Business Service Manager - TBSMProfile_Port_17310", and select Restart.
        
        
   • UNIX and Linux systems:
     
     
     1. cd to $TIP_HOME/profiles/TBSMProfile/bin
        
        
     2. Enter ./stopServer.sh server1 -username tipadminuser -password _tipadminpassword
        
        where _tipadminuser and tipadminpassword must be replaced with the Tivoli Integrated Portal administrative user and password for the TBSM 4.2 configuration
5. Enter ./startServer.sh server1

To verify that the launch action has been added do the following steps:

1. From the TBSM 4.2 Console, open the Service Administration page and select the Services navigation view in the Service Navigation portlet.
   
   
2. Click on a service created from a TBSM 3.1 business system.
   
   
3. In the View Service tab that displays the canvas view, right-click one of the services displayed in the canvas view.
   
   
4. Verify that the Launch to menu includes a submenu item called Launch TBSM 3.1.
   
   
5. If the menu item is enabled, click it to verify that the TBSM 3.1 Web Console is launched.
   
   
6. If the menu item is not shown, not enabled, or does not launch the TBSM 3.1 Web Console, see section 5 "Troubleshooting".

Create services for TBSM 3.1 business system folder shortcuts

This optional configuration should be used when business system folder shortcuts are to be represented in TBSM 4.2 as distinct services. This might be necessary if shortcut folders in TBSM 3.1 have unique properties, especially properties that can affect the status. This includes, for example, Percentage Based Threshold (PBT) rules and instance level thresholds. The assumption is that the business system behaves differently when being managed in multiple contexts through the use of shortcuts.

In this configuration, when a shortcut is encountered, a distinct 4.2 service is created, with an attribute that defines the id of the source business system folder in TBSM 3.1. When this newly created service retrieves its child business systems, the source id is used, because in TBSM 3.1, only the source business system folder has links to child business systems.

Important: This configuration must not be applied to a system that already has the default configuration defined (see 2.2.2, "Default configuration - Templates, data source, and data fetcher"). The same template names are used and will result in conflicts when trying to import this configuration. Remove the TBSM 3.1 templates and any services created by this ESDA feature before updating the configuration to allow shortcuts. See 2.4, "Removing the templates, services, data source, and data fetcher", for more information.

Preparation for this configuration is the same as for the default configuration. See 2.2.1, "Preparing for the default configuration", to make sure that all the required information has been gathered before you begin.

Run the following steps to configure the TBSM 3.1 ESDA feature to support shortcuts:

1. Edit the tbsm31esda_config_shortcuts.radsh attachment file. Look for all occurrences of the string "CONFIGURATION REQUIRED" and follow the instructions in the comments to configure the settings.
   
   
2. From the directory containing the modified attachment file, execute the following command:
   
   Windows systems: type tbsm31esda_config_shortcuts.radsh | %TBSM_HOME%\bin\rad_radshell.bat
   
   UNIX and Linux systems: cat tbsm31esda_config_shortcuts.radsh | $TBSM_HOME/bin/rad_radshell

Verify the results by looking for the following items in the Service Navigation portlet of the TBSM 4.2 Service Administration page:

• Templates navigation view: Templates named TBSM31_Model and TBSM31_Status

• Data navigation view: A data source named TBSM

• Data Fetcher navigation view: A data fetcher named TBSM_AlertStatus

If the expected results are not displayed, see section 5 "Troubleshooting".

Include all top level business system folders

This configuration defines a single seed service that is the root of the TBSM 3.1 service model. All TBSM 3.1 top level services are automatically discovered by running the ESDA rule against this top level seed. This single seed is called TBSM31_Systems by default.

Important: This configuration should not be applied to a system that is already using selected TBSM 3.1 services, which is the default implementation (see 2.2.3, "Default configuration - Seed services"). Remove any previously defined seed services before proceeding. See 2.4, "Removing the templates, services, data source, and data fetcher" for more information.

Run the following steps to configure the TBSM 3.1 ESDA feature to automatically retrieve all top level business system folders:

1. Edit the tbsm31esda_single_seed.radsh attachment file. No configuration is required unless you want to change the display name for the single seed service.
   
   
2. From the directory containing the modified attachment file, run the following command:
   
   Windows systems: type tbsm31esda_single_seed.radsh | %TBSM_HOME%\bin\rad_radshell.bat
   
   UNIX and Linux systems: cat tbsm31esda_single_seed.radsh | $TBSM_HOME/bin/rad_radshell

If the expected results are not displayed, see section 5 "Troubleshooting".

Removing the templates, services, data source, and data fetcher

If the default configuration has been installed for the templates, and is not satisfactory, the templates, services, data source, and data fetcher that are created must be removed before changing the configuration. This would also be the case if you are switching from an optional configuration back to the default configuration.
If the only configuration change is to modify which seed services will be used, then only the service instances need to be removed.

The following steps outline how to remove the services, templates, data fetcher, and data source added by this feature:

Log in to the TBSM 4.2 console and select the Service Administration page for all the following tasks.

Service instances:

1. In the Service Navigation portlet, select the Services navigation view.
   
   
2. Click the Delete button ( ) to display the Delete Instances page.
   
   
3. Select all instances with names of the form TBSM31_LOB:nn and click the Delete button ( ).

Important: If the single top level seed is no longer needed, delete the instance named TBSM31_Systems as well.

The following items should only be deleted if the configuration is being changed from the default, collapsed shortcuts, to the optional, supporting shortcuts, or vice versa. If the only change is the configuration for the seed services, these items should be retained.

Templates:

1. In the Service Navigation portlet, select the Templates navigation **view.
   
   
2. Click the Delete ( ) button to display the Delete Templates page.
   
   
3. Select the TBSM31_Model and TBSM31_Status templates and click the Delete button ( ).

Data fetcher:

1. In the Service Navigation portlet, select the Data Fetcher navigation view.
   
   
2. Right-click the row containing the TBSM_AlertStatus data fetcher *and select *Delete from the context menu.

Data source:

1. In the Service Navigation portlet, select the Data navigation view.
   
   
2. Right-click the row containing the TBSM data source and select Delete from the Context menu.

Comparing the TBSM 3.1 and 4.2 models

This section provides more detail on how the TBSM 3.1 business systems are represented in TBSM 4.2. Several screen captures are used to show the differences between the two models. While some instructions might be included in this paper about how to view the model in 3.1 and 4.2, it is assumed that the reader is familiar with the consoles provided with each product.

For more information on using the TBSM 3.1 Console, refer to TBSM 3.1 publication Introducing the Consoles

For more information on using the TBSM 4.2 Console, refer to the following TBSM 4.2 publications:

• Service Configuration Guide

• Customization Guide

Business Systems tree → Service Model hierarchy

Figure 2: TBSM 3.1 Business Systems tree

See Figure 2 for an example of a TBSM 3.1 Business Systems tree. The following list defines the resources shown in the tree.

Business Systems: This is the root of the Business Systems tree. It does not show any status and is not reflected as a service in the default configuration for 4.2.

Email, InternetBanking, Payroll: These are the top level business systems. These are the candidates to be configured for the 3.1 ESDA feature as top level services in TBSM 4.2.

DBServers, NetworkServers: These are child business systems of Email. Because these business systems are both folders, they are automatically added as dependent services of Email in the 4.2 service model created when using this feature.

OS001, OS002, OS004, OS005: These are business system resources. Services are not created for these business systems in TBSM 4.2. These represent TBSM 3.1 physical resources, as indicated by the icon, which is the TBSM 3.1 icon used for an operating system.

MyResources - admin: This is a TBSM 3.1 Critical Resource List (CRL) for user "admin". While CRLs are business system folders, they are not valid for configuration as top level services. If the optional configuration is used to include all top level business systems (see 2.3.3, "Include all top level business system folders"), the CRLs are skipped automatically.

Figure 3 shows the same business systems, now as services in a TBSM 4.2 service model. The default configuration of the ESDA feature has been applied in this case, with business systems Email, InternetBanking, and Payroll configured as seed services.

The icon for business system folders has been carried forward to TBSM 4.2 to help identify services based on TBSM 3.1 business systems. Notice only the folders and child folders are present and there are no business system resources.

Figure 3: TBSM 4.2 service model based on TBSM 3.1 business systems

The topology view from TBSM 3.1 provides similar capability to the TBSM 4.2 canvas view. Figure 4 shows a side-by-side comparison of the 3.1 and 4.2 models in graphical form.

Figure 4: Side by side - TBSM 3.1 topology and TBSM 4.2 canvas views

Business system folder shortcuts

The most interesting decision to be made when configuring the TBSM 3.1 ESDA feature for TBSM 4.2 is in regards to the treatment of business system folder shortcuts. Shortcuts are intended for a TBSM 3.1 customer to define a business system that is reusable as a dependency in other business contexts. TBSM 3.1 takes it one step further and allows these shortcuts to have distinct properties, most notably the threshold settings and Percentage Based Threshold (PBT) rules that can affect propagation. By default, the shortcuts have the same properties as the source business system from which they were created.

TBSM 3.1 has the following method of handling shortcuts:

• A shortcut has a link to the business system from which it was created.

• Shortcuts have no unique child business systems. The link to the source business system is used to determine child business systems. A source business system and all of its related shortcuts always have the same child business systems.

• By default, a shortcut inherits all properties from its source business system. These are modifiable per shortcut, allowing, for example, different propagation thresholds for a shortcut.

Default configuration - shortcuts are collapsed

By default, this TBSM 3.1 ESDA feature simplifies the handling of shortcuts by only creating a 4.2 service for the non-shortcut business systems. When a shortcut is encountered by the ESDA rules, a 4.2 dependency is created from the parent service to the service that was created for the source business system. Thus, a business system with two shortcuts in TBSM 3.1 becomes a service in 4.2 that has three parent services, one for the source business system, and one for each shortcut.
Consider the TBSM 3.1 Payroll business system shown in Figure 5.

Figure 5: TBSM 3.1 business system tree with shortcuts

The CheckPrinting business system was originally defined as a child business system of the California business system folder. *The business system was then "reused" under *NewYork and NorthCarolina, resulting in two business system folder shortcuts (notice the icon that denotes a shortcut: ).

Figure 6: TBSM 4.2 default handling of shortcuts

Figure 6 shows the resulting service model in TBSM 4.2. Notice that the tree looks the same, but the canvas view tells what is really happening; there is one service with three parents.

Optional configuration - create 4.2 services for shortcuts

Using the optional configuration described in 2.3.2, "Create services for TBSM 3.1 business system folder shortcuts", business system folder shortcuts can be created as distinct services in TBSM 4.2. With this configuration, the unique status of shortcuts will be reflected in 4.2. On the downside, duplicate display names are likely to appear in the 4.2 service model, with no visual designation of which services represent shortcuts. However, after the shortcut becomes a service in 4.2, it really no longer matters that it was a shortcut in 3.1, as no special behavior is attached to it in 4.2.

Important: Internally, the ESDA rule recognizes by a separate id attribute that the service was a 3.1 shortcut. This is necessary in order to retrieve the dependencies for the service from 3.1, but the resulting model shows no evidence of this internal handling of the "shortcut" service.

Figure 7: TBSM 3.1 shortcuts with different status

The default configuration is designed with the assumption that the shortcuts reflect only reuse of the business system, without the complexity of configuring each shortcut to have different properties.

In the example illustrated by Figure 7, the CheckPrinting business system has been defined to propagate status differently for each context in which it is being used. With the default configuration of this TBSM 3.1 ESDA feature, you see all the contexts (parents) for CheckPrinting, but only the status for the non-shortcut copy of CheckPrinting will ever be shown in the 4.2 service model. Thus a Red status is not reflected in TBSM 4.2 for this case, as illustrated in Figure 8.

Figure 8: TBSM 4.2 service model with shortcuts collapsed
By using the optional configuration for handling shortcuts, the 4.2 service model can look very much like the 3.1 model, as illustrated in Figure 9.

Figure 9: TBSM 4.2 service model with option to retain shortcuts

Business Impact

TBSM 3.1 supports a Business Impact view that is designed to show operators how a particular outage is affecting the overall business. The basic design is a "bottom up" view starting from a resource or business system and traversing up the hierarchy of ancestors to show how the starting resource affects different business systems. This is one of the signature functions of TBSM 3.1.

The TBSM 4.2 Business Impact view starts from a selected service and displays a "bottom up" relationship view, thus showing how the service impacts the services above it in the service model. Only services that are not in a normal state are shown in the view. An alternative "Business Impact All" view shows all services impacted by the starting service, including services that are in a normal state.

It is important to note that the TBSM 3.1 Business Impact view content is determined by a database stored procedure. It is designed to handle physical resources as well as business systems, and there is special logic to deal with business system resources and business system folder shortcuts.

With business system resources not a consideration for this TBSM 4.2 feature, the 4.2 Business Impact view is much simpler. It is a customized version of the 4.2 BasicRelationships view that specifies the view be built by looking only "up" through the dependencies hierarchy. The number of levels is set artificially high to try and ensure that the full range of business impact is included.

Figure 10 shows an example of a TBSM 3.1 Business Impact view. It is displayed using the TBSM 3.1 "HyperView", which is a graphical presentation designed to show large numbers of objects. It has been filtered to show resources with a status of Yellow or worse.

Figure 10: TBSM 3.1 Business Impact view

The TBSM 4.2 Business Impact view, shown in Figure 11, is a similar view. By default, because shortcuts have been collapsed, the view is a bit simpler. Also note that the 4.2 view is designed to automatically hide any services that are Green, thus showing only the degraded services.

Important: A Business Impact view that has only Green services in TBSM 4.2 will be empty.

Figure 11: TBSM 4.2 Business Impact view

Exploiting TBSM 4.2 - Enhanced Executive Dashboard

Now that the installation and configuration of the TBSM 3.1 ESDA feature is complete, and the resulting 4.2 service model has been explored, it is time to talk about exploiting the many features of TBSM 4.2 with the new services.

Because the focus of this feature is to bring high level TBSM 3.1 business system folders into the 4.2 service model, the target audience is business and IT executives, as well as business system and application owners. TBSM 3.1 introduced an Executive Dashboard feature, along with an Application Programming Interface that customers can use to retrieve executive service data for their own Web applications. Figure 12 shows examples of the TBSM 3.1 Executive Dashboard display.

Figure 12: TBSM 3.1 Executive Dashboard sample displays

Using the capabilities of TBSM 4.2, an enriched Executive Dashboard can be created. It can be highly customized to the needs of a specific enterprise. There are two main areas of improvement in 4.2 that allow this to be accomplished:

Data integration:

• Built-in Service Level Agreement (SLA) data

• Integration with external data sources

Visualization:

• Customizable canvas views

• Customizable scorecards

Figure 13 shows a customized Web page for a fictional internet banking service. The following sections describe how TBSM 4.2 can be used to create this page, resulting in a greatly improved Executive Dashboard.

Figure 13: TBSM 4.2 customized Web page for an Internet Banking service

Preparation

The first steps for building the customized Internet Banking page are defining templates to be used for the data integration rules and defining the executive user that views the instances associated with these templates.

Defining the data integration templates

For the example Internet Banking page, rules will be created to process the external data that measures the health of our fictional Internet Banking service model. The rules are different for the lower level services than the containing parent services, and thus two templates are required.

For this example, create the following two templates:

TBSM31_InternetBankingChild: This template will have rules to process external events and calculate attributes indicating the health of the dependent services

TBSM31_InternetBankingParent:This template will have rules that aggregate the values from the child template rules to provide overall health information for the high level service

For now, provide only the name and, optionally, a description. The icon is not really relevant, as these templates are not primary templates in this example. The templates just need to exist at this point so that the viewing privileges can be assigned for the executive user that will be defined in the next section.

Defining the executive user

The next step in building the Executive Dashboard for TBSM 4.2 is to define the executive user. A TBSM 4.2 user with the role "iscadmins" is required to perform this task. After it is created, this executive user is given the authority to view only service instances relevant to this executive's portion of the business. Customized Web pages, like the one shown in Figure 13, can be created specifically for access by this new executive user.

The following list outlines the steps for adding the new executive user ibank:

1. Log in to the TBSM 4.2 console with a user ID that has the "iscadmins" role.
   
   
2. In the task list on the left side of the TBSM 4.2 Console, expand the Users and Groups folder and select Manage Users.
   
   
3. In the Search for Users pane, select the Create button.
   
   
4. In the User ID field, enter ibank.
   
   
5. Complete the other fields with the values you want.
   
   
6. To complete creating the user ibank, select the Create button.
   
   
7. From the Users and Groups folder, select Administrative User Roles.
   
   
8. Select the Add button, and type ibank into the User field.
   
   
9. Press Ctrl and click the tbsmReadOnlyUser and ncw_admin roles.
   
   
10. To save the new user, select OK, and then select Save.

Refer to the TBSM 4.2 Administrator's Guide for more information on maintaining users, groups, and roles.

The user ibank must now be given the privilege to view only the instances related to Internet Banking. This limits the contents of the service tree that can be viewed by ibank to the relevant services, which ultimately defines the content of the customized Internet Banking dashboard. See Figure 14 for an illustration of using the Security tab of the Template editor page to assign the RAD - View Instance privilege to all instances of the child template for the Internet Banking example. Repeat this same security assignment for the parent template.

The privileges can also be assigned on a per-service instance basis. This example assumes the child and parent templates are only assigned to services that are related to Internet Banking. This simplifies the process and also allows the appropriate security privilege to automatically be assigned to new service instances when they are tagged with the Internet Banking child or parent template.

Figure 14: Assigning security privileges for instances tagged with a template

Data Integration

TBSM 4.2 has data integration capabilities that were not available in TBSM 3.1. Built into the TBSM 4.2 product is the ability to access and display data, like Key Performance Indicators (KPIs) and Key Quality Indicators (KQIs), from external data sources. Rules can be created to process this external event data and assign status and attributes to the services that were created with this ESDA feature.

In addition, Service Level Agreement rules can be assigned to the templates associated with the services that were created with this ESDA feature. Refer to the TBSM 4.2 Service Configuration Guide for details on how to use the SLA features of TBSM 4.2. This paper does not cover SLA in any more detail, but the standard SLA attributes can be plugged into the same custom views and scorecards that are described herein.

The focus of this paper is the integration of external data into the TBSM 4.2 product to enrich the views and scorecards that can be created. In the following example, there is a fictional database that contains Key Performance Indicators for the business services in this fictional service model. Table 2, "Example KPI data for integration with TBSM 4.2 services", shows the layout of the example KPIData SQL table.

Table 2: Example KPI data for integration with TBSM 4.2 services

See the Appendix for SQL code that can be used to create the sample table and sample data used by the Internet Banking example.

Adding the data source and data fetcher

The first step in integrating with an external data source is to define it for use by TBSM 4.2. In this example, a data source called KPI is created.

1. Log in to the TBSM 4.2 console with a user ID that has administration roles. This should be any user that you added to the TBSM 4.2 group tbsmAdmins.
   
   
2. From the task list on the left side of the TBSM 4.2 Console, expand the Administration folder and select Service Administration.
   
   
3. From the Service Navigation portlet, select the Data navigation view.
   
   
4. To create a new data source, select the Create icon ( ) .
   
   
5. See Figure 15 for an example of how to fill in the data source information.
   
   
6. Test the connection to the data source and make any necessary corrections.
   
   
7. Save the data source.

You now define one or more data fetchers that use the data source. In this example, a data fetcher called KPI_InternetBanking is created.

1. Log in to the TBSM 4.2 console with a user ID that has administration roles. This should be any user that you added to the TBSM 4.2 group tbsmAdmins.
   
   
2. From the task list on the left side of the TBSM 4.2 Console, expand the Administration folder and select Service Administration.
   
   
3. From the Service Navigation portlet, select the Data Fetcher navigation view.
   
   
4. To create a new data fetcher, select the Create icon ( ).
   
   
5. See Figure 16 for an example of how to fill in the data fetcher information. In this case the fetcher gets all the columns from the KPIData table. This fetcher polls at least every 2 minutes and waits no longer than 5 minutes between fetches.
   
   
6. To get a preview of the KPI data that will be fetched, select the View Data button.
   
   
7. Save the data fetcher.

See the TBSM 4.2 Service Configuration Guide for detailed information on adding data sources and data fetchers.

Figure 15: Example of defining the KPI data source

Figure 16: Example of defining the KPI_InternetBanking data fetcher

Adding rules to process data fetcher events

The integration of the KPI data with the TBSM 4.2 service instances is completed by creating various rules that are applied when the data fetcher polls and finds new event data. In the Internet Banking example, the rules will match based on the name of the service. After each applicable rule is applied, the affected services contain attributes corresponding to the rule names, with values based on the rule calculation.

The rules will exist on either a "parent" template or a "child" template, with the parent rules aggregating the values from the child templates. In the Internet Banking example, shown in Figure 13, service InternetBanking is the parent service, while the child services are the regions designated by Northeast, Northwest, Southeast, *and *Southwest.

This paper does not attempt to explain all aspects of defining rules in TBSM 4.2. See the TBSM 4.2 Service Configuration Guide for detailed information on creating rules.

Table 3 contains sample rule definitions that were created for the child template in order to produce the Internet Banking executive scorecard.

Table 3: Template rules defined for child services of InternetBanking

Note that many of these rules in Table 3 permit the setting of the overall status of a service based on user-defined thresholds for each rule output value. This provides greater flexibility in choosing what metrics actually determine the status for a service.

Table 4 contains sample rule definitions that were created for the parent template in order to produce the Internet Banking executive scorecard. Most of these just aggregate the attribute values for the rules defined in the child template.

Table 4: Template rules for parent service InternetBanking

Notes on assigning templates and setting identification fields

TBSM 4.2 allows for multiple templates to be assigned to a service instance, with a single template defined as the primary. When assigning the templates containing the rules in Table 3 and Table 4, be sure not to change the primary template. The primary template is defined by the ESDA feature and must not be modified. Figure 17 is a screen capture of the correct Template assignment for the InternetBanking parent service. __

Figure 17: Proper template assignment for parent service InternetBanking

The identification fields must also be set properly for Incoming Status rules to be applied to the correct resources. The TBSM 3.1 business systems become services with instance names based on the TBSM 3.1 id value. This is the only means for ensuring uniqueness, because TBSM 3.1 does not enforce unique names for business systems.

For external data sources, like the example KPIData table, the service name is likely the key identifier. TBSM 4.2 supports the correlation of the rules based on varying values by the setting of the Identification Fields. In Figure 18, the top image shows the default settings for the child template rule matching, while the bottom image shows the modifications that are needed to make the rules match based on service name. Note that the identification field for the incoming status rule
TBSM31IncomingStatusRule1 on the TBSM31_Status template remains unchanged.

Figure 18: Setting the Identification Fields for child template rules

Visualization

TBSM 4.2 supports the following highly customizable means of visualizing the status and KPI data:

• Custom view definitions

• Custom static canvases

• Custom service trees

Each of these is covered in detail in the following TBSM 4.2 publications:

• Service Configuration Guide

• Customization Guide

The following sections give an overview of how these visualization techniques could be used with the Internet Banking example.

Custom view definitions

TBSM 4.2 comes with a default set of view definitions. Using one of these default view definitions, you can build a customized view to show, for example, details of the KPI data being fetched from an external data source. You can also change the behavior of the view definition, deciding, for example how many levels up and down to show in the view, and whether or not to display certain templates.

Figure 19 is an example of a view that shows transaction and health details for the Internet Banking service model. This is more of an operator view, but could be useful in providing details to an IT Executive.

Figure 19: Custom view definition showing KPI data

The following basic outline shows how to create this custom view definition:

1. Open the default BasicRelationships view for one of the TBSM 3.1 services that has been added to the 4.2 system; InternetBanking in this example.
   
   
2. Edit the view definition by selecting the Edit View Definition button ( ) You must be in the "full" canvas client in order to edit views. See the TBSM 4.2 Service Configuration Guide for more information.
   
   
3. Click the Save As New button and provide a name for the custom view.
   
   
4. Select the Edit View Definition button ( ) again to edit the new view. Switch to the Visuals tab to modify how the services are to be displayed.
   
   
5. From the Service Template drop-down list, select TBSM31_Model, which is one of the templates defined by the TBSM 3.1 ESDA feature. It is also the primary template, which dictates which services are affected by the visual customization.
   
   
6. From the Type drop-down list, select FiveElementPrototype in order to match the illustration in Figure 19.
   
   
7. See Figure 20 for how the values are set to build the view that is illustrated in Figure 19_._ Note the use of the syntax @AttributeName. This is required to assign an attribute that is defined by a template rule that is not from the primary template; the child or parent template in this case. The drop-down attribute list only shows attributes from the primary template. See Table 3 and Table 4 for the attributes (rule names) used in this example.

Figure 20: Setting the attributes for a custom view definition

Important: The cache for the KPI data fetcher needs to be cleared for the new view definition to display the KPI data. Because the data fetcher was already running before the templates were assigned, the services are not updated with the KPI data unless the cache is cleared. This is because TBSM 4.2 only processes changed data rows, by default. It might be better to disable the data fetcher and perform the fetches manually while working with the Internet Banking example. See the TBSM 4.2 Service Configuration Guide for more information on working with data fetchers.

Custom static canvases

A custom static canvas is designed to show a fixed set of visual elements with no dynamic change in content. Contrast that with the custom view definition described in the previous section, which applies visual customization to a view that is created dynamically, based on a starting service and its dependencies.

With a custom static canvas, specific service instances are selected to be displayed in the view. Status and other attribute values that are shown are kept up-to-date, but no other service instances are dynamically added or removed from the view.

In addition to the visual elements (known as Indicators) that represent the service instances, other decorations can be added to a custom static canvas, including these items:

• Text fields

• Graphics, for example a logo. User defined graphics can be added to the selection palette.

• Boxes and connecting lines

• Background color

Figure 21 illustrates a custom static canvas built for the Internet Banking example.

Figure 21: Example of a custom static canvas

The following basic outline shows how to create the custom static canvas illustrated in Figure 21:

1. From the task list on the left side of the TBSM 4.2 Console, expand the Administration folder and select Service Administration.
   
   
2. From the Service Navigation portlet, select the Custom Canvases navigation view.
   
   
3. Select the Create button ( ) to create a new custom static canvas.
   
   
4. Select the Indicators tab. Size the window so that all the indicators are displayed.
   
   
5. Select the speedometer style gauge and click on the blank canvas to position the gauge.
   
   
6. A wizard is displayed to walk you through the configuration of the indicator. First, select the InternetBanking service instance. On the second page of the wizard, set the values as indicated in Figure 22. Note the use of the syntax @AttributeName. This is required to assign an attribute that is defined by a template rule that is not from the primary template; the child or parent template in this case. The drop-down attribute list only displays attributes from the primary template .
   
   
7. To complete the settings for the gauge, click the Finish button.
   
   
8. Click the Decoration tab to complete adding the logo and the text field. Refer to the TBSM 4.2 Service Configuration Guide for more information on using the Inspector tool to further customize the visual elements. For this example, the inspector is required to set the "Active Accounts" text that is displayed in the custom static canvas shown in Figure 21.
   
   
9. To save the view, click the Save button ( ) on the toolbar. When prompted, enter a name, for example ActiveAccounts.

Figure 22: Settings for gauge in custom static canvas

Refer to the TBSM 4.2 Service Configuration Guide for detailed information on creating custom static canvases.

Custom service trees

TBSM 4.2 also allows for the creation of customized service trees by using the Tree Template editor. These trees can show numeric values, text values, or graphics that represent the numeric values. The display of the tree is controlled by TBSM 4.2 policy code, which can also be customized to perform additional formatting for the values in the tree.

Tree Template Editor

In the beginning of "Exploiting TBSM 4.2 - Enhanced Executive Dashboard", a customized Web page was shown as the goal for an Executive Dashboard (see Figure 13). The top half of this page shows a customized service tree (also known as a customized scorecard), which requires a customized tree template. The following steps show how this customized tree template was created:

1. From the task list on the left side of the TBSM 4.2 Console, expand the Administration folder and select Service Administration.
   
   
2. From the Service Navigation portlet, select the Services navigation view.
   
   
3. Select the Tree Template Editor button ( ) to access the Tree Template editor.
   
   
4. To the left of the "Tree Template Name" label, select the Create button ( ) to add a new tree template. Enter the name InternetBankingTree to match the example used in this paper.
   
   
5. After the window refreshes, select the new tree template name from the drop-down list.
   
   
6. See the TBSM 4.2 Service Configuration Guide for complete details on how to use the tree template editor. Figure 23 illustrates the general layout of the editor window. Highlighted areas include the custom column names, the templates from which attributes are obtained, and the assignment of attributes to columns.
   
   
7. Be sure to set the display attributes for both the parent and child templates by selecting each template in the Active Template list.

Figure 23: Tree template editor example settings

Tree Template policy

To realize the full capability of the customized service trees, it might be necessary to update the policy that is run when the service tree is displayed. This policy controls the basic display behavior for the columns in the tree. For example, you can substitute the green, yellow, and red indicators based on a numeric attribute displayed in the tree. Another default behavior is to display a percent sign (%) in columns where the name includes a percent sign.

In the target tree template shown in Figure 13, there are several customizations to the policy that are based on the column names and the numeric values, including these items:

• Negative values are displayed in red in the Trend column

• The Transactions column changes large numeric values to be expressed with the M and K suffixes

• The Cost column displays the values with a preceding dollar sign ($)

• The Health column uses the green, yellow, and red indicators

See the Appendix for a listing of the policy that was modified to display the custom service tree. The policy can be edited using the Edit Policy button found on the Tree Template editor that is described in the previous section. The TBSM 4.2 Dashboard and Data servers might have to be restarted to pick up the policy changes for all services.

Creating the custom scorecard page

Now that the various pieces are created, the last step is to create a page for the executive user that becomes that executive's Executive Dashboard. A user with roles "iscadmins, tbsmAdminUser, and ncw_admin" are required to create this page.
The following steps are required to complete the custom Web page for executive user ibank:

1. Log in to the TBSM 4.2 console with a user ID that has the roles "iscadmins", "tbsmAdminUser", and "ncw_admin".
   
   
2. From the task list on the left side of the TBSM 4.2 Console, expand the Settings folder and select Page Management.
   
   
3. Select the New Page button.
   
   
4. From the Choose a Portlet window, select the radio button next to the portlet named Service Tree. Note that the user creating this page, in addition to having the role of "iscadmins", must also have the "tbsmAdminUser" role in order to see the TBSM portlets in the portlet selection list.
   
   
5. Select the OK button to exit the Choose a Portlet window. The new page with the default service tree is displayed.
   
   
6. In the row of buttons on the toolbar in the upper right corner of the page (beneath Save and Cancel), click the Horizontal split button ( ). This splits the page horizontally so that another portlet can be added.
   
   
7. From the Choose a Portlet window, select the radio button next to the portlet named Inline Frame. Note that the user creating this page, in addition to having the role "iscadmins", must also have the "ncw_admin" role in order to see the Inline Frame portlet in the portlet selection list.
   
   
8. Select the OK button to exit the Choose a Portlet window. The new page with the default service tree at the top and the default URL at the bottom is displayed.
   
   
9. Select the Save button in the upper right corner of the page.
   
   
10. In the Page name field, enter Internet Banking. Note the default location of the page in the Page location field or use the Location button to open a window that lets you move the page to the top of the navigation tree or under any existing folder.
    
    
11. Select Roles with Access to This Page, then select the Add button. From the list of roles, select "tbsmReadOnlyUser", which will match the role given to the user ibank. Note that a unique role could be defined and assigned to user ibank and to this page if other TBSM users should not be allowed to view the page.
    
    
12. To complete the creation of the Internet Banking page, click Save.

At this point the page should be displayed in the TBSM 4.2 console, as shown in Figure 24. These final steps complete the customization of the page:

1. Locate the edit icons for each portlet in the page. The red boxes in Figure 24 illustrate where the edit icons are located.
   
   
2. Click the edit icon, then click Edit Defaults for the Service Tree portlet. To see the customized service tree, select InternetBankingTree from the Tree Template drop-down list.
   
   
3. Click Save when the updates are complete.
   
   
4. Now log out and log in with executive user ibank. The task list on the left side of the TBSM 4.2 Console should include a navigation element for "Internet Banking". You might have to expand one or more folders depending on the location you defined for the page.
   
   
5. Click the edit icon for the Inline Frame portlet. Specify a value for the URL field. In this example, a popular financial Web page was selected.

The customized Web page shown in Figure 13 should now be displayed.

Figure 24: Creating a new page to contain the custom scorecard

Troubleshooting

Table 5 lists common problems that might be encountered while configuring and using the TBSM 3.1 ESDA feature. Possible solutions are listed in the second column, and are references to the information found in Table 6.

Table 5: Common problems

Table 6 contains possible solutions for the common problems. The first column contains an identifier for the solution and the second column has the details.

Table 6: Solutions

Summary

The TBSM 3.1 ESDA feature provides rules that retrieve high level TBSM 3.1 business system folders and create service instances in TBSM 4.2. This helps preserve the customer investment in building the TBSM 3.1 business systems tree by reflecting at least the executive level business systems in a TBSM 4.2 service model. In addition, the TBSM 3.1 status can be reflected on the 4.2 services. Thus, TBSM 3.1 and TBSM 4.2 can be run in parallel and will stay consistent with regards to the high level service content and status.

Beyond simply reproducing the TBSM 3.1 high level service model, this feature exposes the model to all the many capabilities that TBSM 4.2 has to offer. By exploiting the SLA, data integration, and visualization capabilities of 4.2, TBSM 3.1 executive users can be provided with a greatly enriched Executive Dashboard.

Appendix

Sample SQL Data for Internet Banking Example

The following SQL code can be used to create the sample KPIData table and insert several rows of sample KPI data in the PostgreSQL database that is installed by TBSM4.2. This SQL code should be applied against a database named KPI to match the example in this paper.

--
-- Create Table
--
CREATE TABLE KPIData (
       servicename	 VARCHAR(50) NOT NULL,	  
       kpitype           VARCHAR(50) NOT NULL, 
       kpivalue		 INTEGER NOT NULL	 
);

--
-- Insert sample data
--
INSERT INTO KPIData values('Northeast', 'Active', 1500);
INSERT INTO KPIData values('Northwest', 'Active', 700);
INSERT INTO KPIData values('Southeast', 'Active', 1000);
INSERT INTO KPIData values('Southwest', 'Active', 1200);

INSERT INTO KPIData values('Northeast', 'New', 25);
INSERT INTO KPIData values('Northwest', 'New', 15);
INSERT INTO KPIData values('Southeast', 'New', 35);
INSERT INTO KPIData values('Southwest', 'New', 5);

INSERT INTO KPIData values('Northeast', 'Closed', 45);
INSERT INTO KPIData values('Northwest', 'Closed', 10);
INSERT INTO KPIData values('Southeast', 'Closed', 5);
INSERT INTO KPIData values('Southwest', 'Closed', 8);

INSERT INTO KPIData values('Northeast', 'Transactions', 450000);
INSERT INTO KPIData values('Northwest', 'Transactions', 1000234);
INSERT INTO KPIData values('Southeast', 'Transactions', 50000);
INSERT INTO KPIData values('Southwest', 'Transactions', 183456);

INSERT INTO KPIData values('Northeast', 'Down', 50);
INSERT INTO KPIData values('Northwest', 'Down', 15);
INSERT INTO KPIData values('Southeast', 'Down', 100);
INSERT INTO KPIData values('Southwest', 'Down', 600);

Numerical Formula Rule

Table 3, "Template rules defined for child services of InternetBanking", defined the rule Health as a Numerical Formula rule that uses a policy. Following is the policy that was created for the example used in this paper. Look for comments containing "TBSM 3.1 ESDA Feature".

/* Policy for Calculating Status

Variables Received:

InstanceNode: contains the different attribute values.
ServiceInstance: contains properties of the instance.
PeerArray and SiblingPeerArray: PeerArray is a List of all instance
  objects of the same template as ServiceInstance. SiblingPeerArray
  is a List of all instance objects of the same template that share a
  common parent with ServiceInstance. The attributes of the Peers
  are accessed via PeerArray[i].StateModelNode.<AttributeName>.Value.

Variables Set by the policy:

Status: the Number corresponding to the new status of the attribute.

An example one-line policy to obtain the product of two attributes
in this template is:

Status = InstanceNode.RawAttribute1.Value * InstanceNode.RawAttribute2.Value;

If you want to update peers, add the line:
UpdatePeers = "true"; or
UpdateSiblingPeers = "true";
This will trigger the peers (or sibling peers) to recalculate their status
 in light of the status change of this instance.
 */

/* TBSM 3.1 ESDA Feature -- begin                                    */
/* If the account trend is negative and the cost of the down time    */
/* exceeds $10000, health value is bad (2).                          */
if ( ( InstanceNode.AccountTrend.Value < 0 ) and ( InstanceNode.CostOfDownTime.Value > 10000 ) )
{
  Status = 2;
}
/* If either, but not both, bad conditions exist, then the health is */
/* marginal (1).                                                     */
else
{
  if ( ( InstanceNode.AccountTrend.Value < 0 ) or ( InstanceNode.CostOfDownTime.Value > 10000 ) )
  {
    Status = 1;
  }
  /* All is good.                                                      */
  else
  {
    Status = 0;
  }
}
/* TBSM 3.1 ESDA Feature -- end                                 */

Tree Template Display

In the section entitled "Tree Template policy" on page 5, customization was described that formats the service tree display. Following is the content of file TBSM_DATA_SERVER_HOME/policy/RAD_GetTreeColumnValue.ipl, which is the policy that was modified in order to format the custom service tree. Look for comments containing "TBSM 3.1 ESDA Feature". This policy should be edited using the Edit Policy button found on the Tree Template editor.

//******************************************************* {COPYRIGHT-TOP-RM} ***
// Licensed Materials - Property of IBM
//
// "Restricted Materials of IBM"
//
// 5724-C51
// (C) Copyright IBM Corp. 2008 All Rights Reserved.
//
// US Government Users Restricted Rights - Use, duplication, or
// disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
//******************************************************* {COPYRIGHT-END-RM} ***
/*
Input variables: 
  value: the value of the rule being updated
     (for State,Time,Events columns it's an image tag)
  columnName: the name of the column which is having a value updated
  columnAttribute: the name of the rule being updated
  id: the id of the instance being updated
  ServiceInstance: the service instance object

Variable to set:
  VALUE (can be a number or an html string to get shown in the tree)

   To set VALUE to be one of the standard status icons, you can
   use one of the following html expressions
   VALUE = "<img src=/ibm/sla/images/critical_status.png name=critical>"
   VALUE = "<img src=/ibm/sla/images/major_status.png name=major>"
   VALUE = "<img src=/ibm/sla/image/minor_status.png name=minor>"
   VALUE = "<img src=/ibm/sla/images/warning_status.png name=warning>"
   VALUE = "<img src=/ibm/sla/images/indeterminate_status.png name=indeterminate>"
   VALUE = "<img src=/ibm/sla/images/clear_status.png name=clear>"

  Example: Show red, bold text if column name is ResponseTime and value 
           of the rule is greater than 10:

   if (columnName = 'ResponseTime' && value > 10) {
      VALUE = '<font color="red"> <b> ' + value + '</b></font>';
    }


*/  

VALUE = value;

/* TBSM 3.1 ESDA Feature -- begin */
	if (columnName="Trend") {

    if (value < 0) {
      VALUE = "<font color='red'>" + value + "</font>";
		} 
  }

  if (columnName = "Health") {
    if (value = 0) {
      icon = "/ibm/sla/images/clear_status.png";
    }
    if (value = 1) {
      icon = "/ibm/sla/images/minor_status.png";
    }
    if (value = 2) {
      icon = "/ibm/sla/images/critical_status.png";
    } 
    VALUE = "<img src=" + icon + ">";
  }

  if (columnName = "Cost") {
    VALUE = "$"+int(value);
  }
  
  if (columnName = "Transactions")
  {
	if ( value > 1000000 ) {
		VALUE = float((int(value / 1000))/1000)+"M";
                               }
        else {
	if ( value > 1000 ) {
          	VALUE = float((int(value / 100))/10)+"K"; 
                               }
        }
  }

/* TBSM 3.1 ESDA Feature -- end */

References

• IBM Tivoli Business Systems Manager Version 3.1, Introducing the Consoles, __SC32-9086-00

• IBM Tivoli Business Service Manager Version 4.2, Service Configuration Guide, SC23-6041-02

• IBM Tivoli Business Service Manager Version 4.2, Customization Guide, SC23-6042-02

• IBM Tivoli Business Service Manager Version 4.2, Administrator's Guide , SC23-6040-02

For TBSM 4.2 publications, use a web browser to access:
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc/welcome.htm

For TBSM 3.1 publications, use a web browser to access:
http://publib.boulder.ibm.com/tividd/td/BusinessSystemsManager3.1.html

Attachments

The following attachments are available for download with this paper:

• canvasDynamicSubMenuActions.xml.update

• tbsm31esda_config.radsh

• ViewDefinition_.xml.update

• canvasOpenURLActions.xml.update

• tbsm31esda_config_shortcuts.radsh

• tbsm31esda_selected_seeds.radsh

• tbsm31esda_single_seed.radsh

• TBSM31_bussys_svg.gif

• TBSM31_bussys.svg

Please read the copyright and notices statement for this information.