CCMDB V7.2.1: New launch-in-context technology
This chapter, which is the final scenario of this part, describes the launch-in-context (LIC) technology that is available with CCMDB V7.2.1.
CCMDB V7.2.1 enables new LIC technology that addresses certain client requirements with the existing technology. The current LIC technology will continue to be available in CCMDB V7.2.1 along with the new technology.
This chapter contains the following topics:
23.1 Scenario overview and benefits
Launch-in-context (LIC) allows integration of various Tivoli products, increasing operational productivity and reducing cost of ownership of these products. Although this feature is powerful with the current implementation, the products must create product-to-product agreement for launching URLs, with every change or new release LIC must by synchronized and revisited. In addition, the launches must be manually configured.
The new LIC technology provides the following benefits:
•Better utilization of the existing products: You can use multiple Tivoli products in their environment, each providing information. Using the new LIC technology, you see a comprehensive view to help with decision-making and can be used to solve issues, thus providing more value for investments.
•Fast time to value: You do not have to configure launch points manually. Also, you do not have to go to each product to view the information that is related to some component in the environment. The new LIC technology provides a single repository from where each product can fetch all information quickly without any configurations.
•Navigation across products using launch points: LIC enables a common cross product registration mechanism for launch points thus providing integration point for all CI-related products. This benefit enhances the operational experience across the Tivoli products, each having information related to the CI.
Many integration scenarios contain the need for LIC, in the following examples:
•Business Service Impact analysis through Incident and Availability Management
•Change Lifecycle Management
•IBM Tivoli Monitoring with Systems Director Monitoring
•IBM Tivoli Network Manager for IP Edition with Systems Director Monitoring
To explain this need, consider the “sub-scenario” example of a Link Failure at Edge of Network:
1. Service operator analyzes the event and evaluates service impact in Tivoli Business Service Manager.
2. Service Operator validates the problem in IBM Tivoli Monitoring.
3. Service Operator opens ticket and assigns to Network Operator.
4. Network Operator views network event in IBM Tivoli Netcool/OMNIbus.
5. Network Operator views network topology in IBM Tivoli Network Manager.
6. Network Operator assigns ticket to Network Subject Matter Expert (SME).
7. SME views network data in IBM Tivoli Network Manager for IP Edition.
As shown in Figure 23-1, by using the new LIC technology, one can seamlessly navigate across various products, instead of going to each launch entry of the product and navigating.
Figure 23-1 Navigation across products
|
Note: IBM Director, TADDM and CCMDB are initial adopters of the new LIC technology. The products explained in the demo are yet to adopt this technology. The example is given only to show users how the LIC would work with the new technology.
|
23.2 Components of the new LIC technology
The components involved in the new LIC technology are as follows:
•Data Integration Services (DIS) component handles multiple naming contexts for resources through enhanced reconciliation with a centralized database of resources and all their naming contexts and naming attributes.
•Context Menu Service (CMS) component manages a centralized registry of LIC entries and can build the context menus for resources using the naming information in DIS.
•Operational Management Products (OMP) register their naming context for resources that they manage with DIS and use the CMS to build context menus for those resources in the OMP user interfaces.
Figure 23-2 on page 702 illustrates these components that are used in the new LIC technology.
Figure 23-2 LIC components
23.3 Naming and Reconciliation Service
Naming and Reconciliation Service helps OMPs get and set attributes that CMS uses. It provides a common “CDM-aware” data source for all OMPs and CMS to use. It also provides basis for common language across products.
An OMP stores attributes it “knows” about a resource through DIS. CMS uses DIS to look up the attributes (resource context filters). See Figure 23-3.
Figure 23-3 Naming
Reconciliation is a fundamental and critical function of DIS. DIS can “reconcile” resource information that is provided by multiple OMPs. DIS identifies a resource as being the same when reported by two separate OMPs. Reconciliation then merges the attributes that are provided by multiple OMPs. See Figure 23-4.
Figure 23-4 Reconciliation
23.4 Context Menu Services
The use of CMS decouples OMPs from each other for LIC. As additional OMPs are instrumented to use CMS to build their context menus, these OMPs are able to launch into the CCMDB CI applications with no updates required to CCMDB and with no product-to-product interlock between the launching OMP and the OMP into which the launch-into is performed (CCMDB).
The use of CMS allows launching products to determine launch points at run time. When the user selects the launch point, the other product UI starts with context (or previously started UI gets new context), which is dynamic without “hard wiring.” The launched product can provide integrations without waiting for synchronization with the launching products’ release schedule.
The use of CMS in CCMDB V7.2.1 provides the following capabilities:
•Ability to launch into the CCMDB CI applications from any OMP that adopts DIS and CMS.
•Ability to launch from the CCMDB CI applications into any OMP that adopts DIS and CMS.
23.5 Deployment and configuration of DIS/CMS
This section describes deployment and configuration of DIS/CMS:
23.5.1 Deployment components
The following components are included for this integration:
•The TADDM DIS/CMS Integration Package is a TADDM Interim Fix Package that can be used for the following tasks:
– Creating the database tables that are required for DIS and CMS.
– Importing and registering resources from TADDM into DIS.
– Registering CMS Launch Entries for launching into TADDM from other OMPs, such as CCMDB.
•The Base Services Installer provides functions for configuring the TPAE environment to integrate with DIS and CMS and optionally for creating the DIS and CMS tables in the Maximo Database.
•The CI Applications CMS Integration PSI Package configures the CCMDB CI Applications to support the following launch directives:
– Launching out from the CI Applications to other OMPs (such as TADDM) that have registered launch entries with CMS
– Launching into the CI Applications from other OMPs
23.5.2 Options for creating the CMS and DIS tables
The DIS and CMS tables are shared resources with which multiple Tivoli products can integrate. Based on the Tivoli products that you have deployed and the installation sequence of those products, you have three options to deploy the DIS and CMS as follows:
•The DIS and CMS tables have already been set up. In this case, configure the Base Services Installer and the TADDM DIS/CMS Integration Package to use the already-created tables.
•Use the Base Services Installer to create the DIS and CMS tables in the Maximo Database along with the other CCMDB and Tivoli Process Automation Engine tables. In this option, configure the TADDM DIS/CMS Integration Package to load resources and launch entries into those tables in the Maximo Database.
•Use scripts in the TADDM DIS/CMS Integration Package to create the tables. In this option, use the Base Services Installer to configure the Tivoli Process Automation Engine Environment to use the tables setup by TADDM.
|
CCMDB and TADDM deployment considerations:
•DIS and CMS tables must be in the same database. TADDM does not support an environment where the DIS and CMS tables are created in separate databases. CCMDB support for CMS-based LIC depends on TADDM registering resources in DIS. Therefore, you must not use the Base Services Installer functions that allow the Tivoli Process Automation Engine environment to be configured to connect to DIS and CMS in separate databases. On the panel labeled “Data Integration Service Database Information,” you must always select the check box labeled “Use the same database for both data integration and context menu services.”
•CCMDB and TADDM do not support CMS LIC using SQL Server. TADDM does not support SQL Server. CCMDB support for CMS-based LIC depends on TADDM registering resources in DIS. Therefore, you must use DB2 or Oracle as the databases for the DIS and CMS tables. You may not select the Base Services Installer option labeled “Deploy data integration and context menu services into the same database that you created for the product” on the panel labeled “Data Integration Service and Context Menu Service Deployment Options” if you have configured the Maximo Database to use SQL Server.
|
23.5.3 Deployment scenarios
Users performing a base installation of CCMDB V7.2.1 or upgrading an existing CCMDB version to CCMDB V7.2.1 have several options related to DIS/CMS deployment:
•Set up DIS and CMS tables in the database used by CCMDB and configure Tivoli Process Automation Engine to use those tables.
•Configure Tivoli Process Automation Engine to use a previously deployed DIS and CMS.
•Defer or skip DIS and CMS setup and configuration.
•Set up DIS/CMS or configure Tivoli Process Automation Engine for DIS and CMS after installing or upgrading to V7.2.1. After installing or upgrading CCMDB V7.2.1, the user may need the ability to set up Tivoli Process Automation Engine for DIS and CMS. Again, because of the TADDM dependency, a customer may need to initially defer the DIS and CMS setup. This capability allows them to add this integration subsequent to point in time where CCMDB V7.2.1 is upgraded or base installed.
Set up DIS and CMS tables in the database used by CCMDB and configure Tivoli Process Automation Engine to use those tables
This option can be used if the DIS and CMS databases have not previously been deployed by another Tivoli product or OMP. In this scenario, the DIS and CMS Tables are stored in the Maximo Database. For this, first install or upgrade CCMDB before running the TADDM DIS/CMS Integration Package to load launch entries into CMS and resources into DIS:
1. Run the Base Services Installer that is available with CCMDB V7.2.1.
2. In the Base Services Installer UI on the “Data Integration Service and Context Menu Service Deployment Options” panel, select the Deploy data integration and context menu services into the same database that you created for the product option.
3. From the “Run Configuration Step” panel, select the Deploy application files manually later check box.
4. After the Base Services Installer completes, use the Process Solution Installer (PSI) GUI to install the CI Applications CMS Integration PSI Package.
This package is located in the pmp sub-directory of the product installation directory and is named cci_cms_lic_7.2.1.0.zip file. From the Package Options panel, ensure that the Defer Maximo Application Redeployment and Defer the Update of the Maximo Database check boxes are not selected.
5. Run the TADDM DIS/CMS Integration Package to populate the CMS Registry database with TADDM Launch Into Entries and to register actual configuration item resources into DIS.
6. Import CI Types and Actual CIs into CCMDB using Tivoli Integration Composer (corresponding to the resources registered into DIS by the TADDM DIS/CMS Integration Package in step 5).
Configure Tivoli Process Automation Engine to use a previously deployed DIS and CMS
If CCMDB is being added on or upgraded in an environment where another product (or the customer) has set up the DIS and CMS databases, this option can be used. Connection information about the existing DIS and CMS databases can be collected and Tivoli Process Automation Engine specific actions (such as registration of Launch Into entries for CCMDB) can be initiated against the current DIS and CMS.
In this scenario, the DIS and CMS Tables are not created in the Maximo Database. The Base Services Installer configures the Tivoli Process Automation Engine environment to use a database already set up by another product to hold the DIS and CMS tables. Two typical scenarios that clients have, where DIS and CMS is already deployed, are as follows:
•CCMDB installed after TADDM creates DIS and CMS tables
•CCMDB installed after another IBM product creates DIS and CMS tables
CCMDB installed after TADDM creates DIS and CMS tables
In this typical scenario, the Base Services Installer configures the Tivoli Process Automation Engine environment to use a database already set up by TADDM to hold the DIS and CMS tables.
The steps are as follows:
1. Run the TADDM DIS/CMS Integration Package to create the DIS and CMS tables (these must be in the same database and only support DB2/Oracle).
2. Run the TADDM DIS/CMS Integration Package to populate the CMS Registry database with TADDM Launch Into Entries and to register actual configuration item resources into DIS.
3. Run the Base Services Installer that comes with the CCMDB 721 product.
4. In the Base Services Installer UI on the “Data Integration Service and Context Menu Service Deployment Options” panel, select the to Configure data integration and context menu services for this product using a previously deployed data integration and context menu service instance option.
5. On the subsequent “Data Integration Service Database Information” panel, select the Use the same database for both data integration and context menu services check box. On that panel, specify the database connection properties for the DIS/CMS database that you created using the TADDM DIS/CMS Integration Package.
6. From the Run Configuration Step panel, select the Deploy application files manually later check box.
7. After the Base Services Installer completes, use the IBM Process Solution Installer (PSI) GUI to install the CI Applications CMS Integration PSI package. This package is located in the pmp sub-directory of the product installation directory and is named cci_cms_lic_7.2.1.0.zip. From the Package Options panel, ensure that the Defer Maximo Application Redeployment and Defer the Update of the Maximo Database check boxes are not selected.
8. Import CI Types and Actual CIs into CCMDB using Tivoli Integration Composer (corresponding to the resources registered into DIS by the TADDM DIS/CMS Integration Package in step 2 on page 706).
CCMDB installed after another IBM product creates DIS and CMS tables
This scenario is similar to the scenario in “CCMDB installed after TADDM creates DIS and CMS tables” on page 706, with the exception that another product (other than TADDM) has already created the DIS and CMS Tables when CCMDB is installed or upgraded. The deployment steps from that scenario are reused with the following exceptions:
•Step 1 on page 706 is not required because the DIS and CMS Tables have already been created.
•In step 5 on page 706, the DB connection properties specified must be for those that are associated with the DIS and CMS database created previously by another IBM product.
Defer or skip DIS and CMS setup and configuration
The default option is to set up CCMDB to take advantage of DIS and CMS. However, an option exists to install or upgrade CCMDB without this support. CCMDB has a dependency on TADDM to register resources with NRS. This option is required to enable the LIC using CMS. The customer installing or upgrading CCMDB may not have already upgraded or installed TADDM at the required V7.2.1 level.
Based on your requirements, you might need to install or upgrade CCMDB and elect to defer the configuration of DIS or CMS until a later time. For example, you might want to coordinate the deployment of DIS and CMS in your organization to a variety of IBM products on a deployment schedule separate from the schedule for rolling out configuration and change management in CCMDB. You can do this by electing to defer DIS and CMS configuration.
The steps are as follows:
1. Run the Base Services Installer.
2. In the Base Services Installer UI on the “Data Integration Service and Context Menu Service Deployment Options” panel, select the Defer or skip data integration and context menu services setup and configuration option.
3. In the “Run Configuration Step” panel, do not select the Deploy application files manually later check box.
4. At a later time, when you want to deploy data integration and context menu services within CCMDB, rerun the Base Services Installer.
5. The Base Services Installer detects that data integration and context menu services have not been configured, and displays the “Data Integration Service and Context Menu Service Deployment Options” panel.
6. From this panel, you may continue using one of the previously described deployment scenarios.
23.6 CMS Registry Loader externals
To support launch-into Tivoli Process Automation Engine applications from other products using CMS, those Tivoli Process Automation Engine applications must be registered as launch points in the CMS Registry. Tivoli Process Automation Engine provides a common program for performing this registration. The CMS Registry Loader is a command-line interface program for loading launch entry definitions for Tivoli Process Automation Engine applications into the CMS Registry.
The CMS Registry Loader provides the following functions:
•Creating and updating launch entries in CMS.
•Listing currently registered launch entries in CMS.
•Removing launch entries from CMS.
•Validating launch entry XML files.
23.6.1 Reasons to use CMS Registry Loader
The CMS Registry Loader is typically used internally during deployment of a Tivoli Process Automation Engine product. You manually invoke this program if necessary. The reasons to use CMS Registry Loader are as follows:
•Update the host or port for the Maximo application. You modify the launch entry XML file (or files) for the currently registered launch entries to correct the host or port and then use the CMS Registry Loader create action to modify the launch entries in CMS with the updated host/port.
•Debug CMS-based LIC If you are having problems with launching into or out of Tivoli Process Automation Engine applications using CMS. The CMS Registry Loader list action can then be used to debug the problem. This action displays information about currently registered launch entries.
•Create new launch entries for other Tivoli Process Automation Engine-based applications.
23.6.2 Syntax
The CMS Registry Loader is deployed in the bin directory of the base services installation directory (by default, this is IBMSMPin) and is implemented through the following scripts:
•registryLoader.bat for Windows-based administrative workstations
•registryLoader.sh for UNIX-based administrative workstations
An example of running the script is as follows:
registryLoader.bat(.sh)
-action create|remove|list|validate
<action-specific parameter>
Supported actions
Each invocation of the registryLoader script must specify the -action parameter, which identifies the action to be performed. Support actions are defined in Table 23-1 on page 709.
Table 23-1 Supported actions
|
Action
|
Description
|
|
create
|
Creates and updates launch entries in CMS.
|
|
list
|
Displays currently registered launch entries.
|
|
remove
|
Removes launch entries from CMS.
|
|
validate
|
Validates a launch entry XML file.
|
Supported parameters
Based on the action specified using the -action parameter, additional parameters are required. These parameters are defined in Table 23-2.
Table 23-2 Supported parameters
|
Parameter
|
Description
|
Supported action
|
|
-xmlfile <path-to-launch-entry-xml>
|
Identifies the launch entry XML file that defines the launch entries to be created, updated, or validated.
|
create
validate
|
|
-bundle <path-to-nls-bundle-dir>
|
Identifies the directory containing the resource bundle properties files that contain the localized information for the launch entries being created or updated.
|
create
|
|
-applid <application-id-of-entries-to-remove>
|
Removes from CMS any launch entries whose CMS owner is set to the specified application identifier.
|
remove
|
|
-dbuser <CMS-database-userid>
|
Optional. Specifies the user ID used to access the CMS database. If not provided, the user ID collected by the Base Services Installer is used.
|
create
remove
list
|
|
-dbpwd <CMS-database-userid>
|
Optional. Specifies the password used to access the CMS database. If not provided, the password collected by the Base Services Installer is used.
|
create
remove
list
|
Launch entry XML file
A CMS launch entry defines the application URL, substitutable URL parameters, filters, and localized information (display name and description) for a cross-product launch in context point.
A launch-entry XML file is an XML file that contains a collection of CMS launch entries that are associated with a single application identifier. The application identifier is used to group a collection of launch entries belonging to an application or product.
All the launch entries in a single launch entry XML file will have the same application identifier.
Launch entries can be grouped into a hierarchical fashion using the XML tags in the launch entry XML file. This permits the creation of nested sub-menus.
An XML schema descriptor is shipped with the base services installer. This XSD is used to validate the contents of the launch entry XML file.
Creating or updating launch entries
The create action of the CMS Registry Loader is used to create or update CMS launch entries. The key input is the launch entry XML file which is specified using the -xmlfile parameter.
Inside the launch entry XML file, the AppId attribute specifies the application identifier of the launch entries to create. If launch entries already exist with the specified application identifier in CMS, those entries are first removed and then the entries defined in the remainder of the launch entry XML file are created in CMS. Therefore, the create action can be used multiple times to, in effect, replace the currently registered launch entries associated with a particular application identifier.
In addition to the -xmlfile parameter, you must also specify the -bundle parameter, which identifies the directory containing the resource bundle properties files containing localized information for the launch entries contained in the launch entry XML file.
The create action is typically driven from a PSI Package during installation of a product to install the CMS launch entries associated with a product. You use it to modify currently registered launch entries or to add new launch points for other Tivoli Process Automation Engine applications. A sample invocation is as follows:
registryLoader.bat -action create -xmlfile c:CCICMSLaunchEntries.xml bundle c:CCI_Properties
Listing currently registered launch entries
The list action lists information about all the currently registered launch entries in CMS. This action can be useful when debugging issues that are associated with CMS-based LIC scenarios. Information about all registered launch entries is printed to standard output. A sample invocation is as follows:
registryLoader.bat -action list
Removing currently registered launch entries
The remove action of the CMS Registry Loader is used to remove all the launch entries associated with a specific application identifier from CMS. The key input is the applid parameter which specifies the application identifier of the launch entries that are to be removed.
The remove action is typically reserved for invocation by product uninstaller programs or PSI Packages. It permits products to remove the product launch entries from CMS, so that launches into the product being uninstalled are no longer available through CMS. A sample invocation is as follows:
registryLoader.bat -action remove -applid com.ibm.ism.cci.app.ci
Validating a launch entry XML file
The validate action of the CMS Registry Loader is used to validate a launch entry XML file for well-formedness and for adherence to the XML schema associated with launch entry XML files. The action requires the -xmlfile parameter which specifies the path to the launch entry XML file to be validated.
You should use this command if you are making customizations to a launch entry XML file or creating new launch entry XML files. Validation is also performed automatically when the create action is specified. A sample invocation is as follows:
registryLoader.bat -action validate -xmlfile c:CCICMSLaunchEntries.xml
23.6.3 LIC using TADDM
This section describes an LIC scenario from CCMDB into TADDM.
The first step involved is the setting up of the TADDM and CCMDB servers. After TADDM 7.2.1 is installed, use TADDM Integration Package to register the TADDM launch points.
TADDM Integration Package provides utilities for the following items:
•Creating the CMS and DIS Database tables.
•Register CMS launch entries for launching in to TADDM.
•Register resources in DIS.
Perform the following steps to complete the DIS/CMS setup:
1. Run TADDM DIS/CMS Integration Package to create the DIS and CMS tables.
2. Run the TADDM DIS/CMS Integration Package to populate the CMS Registry database with TADDM Launch Into Entries and to register resources in DIS.
3. Run the Base Services Installer (BSI) with the CCMDB 7.2.1Payload.
4. Select the BSI option to configure DIS/CMS for Tivoli Process Automation Engine and specify the DB connection properties for the DIS/CMS databases.
5. CMS and DIS binaries are extracted and CMS servlet filter is configured.
6. Use the PSI GUI to install the CCI LIC package to enable the CCMDB-specific support for CMS LIC.
The MAXIMO EAR is rebuilt and redeployed.
7. Import CI Types and Actual CIs into CCMDB using the Tivoli Integration Composer.
8. Promote the CIs.
Test the LIC function as follows:
1. Click Go To → IT Infrastructure → Configuration Items.
2. Select one of the CIs that you had promoted earlier and click the Details Menu of the Actual Configuration Item. See Figure 23-5 on page 712.
Figure 23-5 Details Menu of the Actual Configuration Item
3. Use the View Change History Report and View Details panels to launch into TADDM CI. You may also select the LIC items from the Select Action menu of the CI.
4. Click View Change History Report to open the TADDM authentication window as shown in Figure 23-6.
Figure 23-6 TADDM authentication window
After providing the required credentials, the change history is listed as shown in Figure 23-7.
Figure 23-7 Change history
The View Details panel from CCMDB is shown in Figure 23-8.
Figure 23-8 View Details panel
23.7 Summary
Figure 23-9 shows the quick summary of this integration.
Figure 23-9 Quick summary
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.