Taking automatic actions based on predefined policies
This chapter provides an integration scenario for taking automatic actions based on predefined policies, when a problem is detected. This integration scenario is based on ITIL best practices, and covers the most commonly used solutions in this type of integration.
This chapter contains the following topics:
16.1 Scenario overview
This scenario describes how to take automatic actions and provide fixes based on predefined policies, when a problem is detected.
Following event analysis and enrichment, one of the following actions is automatically triggered:
•Create incident ticket using Tivoli Netcool/OMNIbus: Tivoli Service Request Manager integration
•Create request for change using Tivoli Netcool/Impact: Change and Configuration Management Database integration
•Run workflow using Tivoli Netcool/Impact: Tivoli Provisioning Manager integration
Tivoli Netcool/Impact acts as a decision maker and chooses the predefined action referring to its mapping table, as shown in Table 16-1.
Table 16-1 Overview of event mapping
|
Alert group
|
Action
|
Description
|
|
ITM_NT_Process
|
Create incident ticket
|
Incident ticket is automatically created after maintenance window check. If incident happens outside of maintenance window, event is enriched through a mapping table. Ticket number appears in Tivoli Netcool/OMNIbus Active Event List.
|
|
ITM_DB_Connection_Pools
|
Create request for change
|
Request for change is automatically created and CCMDB response plan is triggered by CCMDB escalation to fulfill change details. Request for change (RFC) number appears in Tivoli Netcool/OMNIbus Active Event List.
|
|
ITM_Garbage_Collection_Analysis
|
Run workflow
|
Workflow runs automatically and its identification number and status appears in Tivoli Netcool/OMNIbus Active Event List.
|
|
Note: These event mapping examples are not based on best practices.
|
16.2 Products involved
The products and product components involved in this scenario are as follows:
•IBM Tivoli Netcool/OMNIbus V7.2.1
•IBM Tivoli Netcool/OMNIbus Probe for Tivoli EIF
•IBM Tivoli Netcool/OMNIbus Gateway for Tivoli Service Request Manager
•IBM Tivoli Netcool/Impact V5.1.1
•IBM Tivoli Monitoring V6.2.2 FP2
•IBM Tivoli Monitoring and Tivoli Event Synchronization
•IBM Tivoli Service Request Manager V 7.2.0.1
•IBM Tivoli Change and Configuration Management Database V7.2.0.1
•IBM Tivoli Provisioning Manager V7.2
16.3 Benefits
This scenario has several benefits:
•For Operations Managers:
– Speeds mean-time-to-resolution by event enrichment.
– Improves decision making by predefined policies and minimum human intervention.
– Maximizes operational staff productivity.
•For Change Managers:
– Improves change management quality by predefined responses and change procedures.
•For IT Architects:
– Provides a fully integrated solution for automated event management.
16.4 Architectural diagram of the integration
Figure 16-1 shows the architectural diagram of this integration.
Figure 16-1 Architectural diagram of data integration
The diagram describes the system interactions, as follows:
•Event Integration Facility (EIF) interacts with EIF Probe which is connected to Tivoli Netcool/OMNIbus, to send monitoring situation details.
•Tivoli Netcool/Impact interacts with Tivoli Netcool/OMNIbus to read Object Server alerts.status table and to update this table with data processed by Tivoli Netcool/Impact policies.
•Tivoli Service Request Manager Gateway interacts with Tivoli Service Request Manager to create Incident Ticket and to get the ticket number.
•Tivoli Netcool/Impact interacts with CCMDB to create Request for Change and to get the RFC number. This interaction is also used for event enrichment as event enrichment mapping table resides in CCMDB.
•Tivoli Netcool/Impact interacts with Tivoli Provisioning Manager to run workflow and get the workflow status after its execution.
•Situation Update Forwarder (SUF) interacts with Tivoli Monitoring/Tivoli Composite Application Manager to update situation status.
16.5 Implementation steps
In this section, we discuss the steps required to implement this scenario.
16.5.1 Probe for Tivoli EIF
The Tivoli Netcool/OMNIbus Probe Tivoli EIF Linux English product enables IBM Tivoli Netcool/OMNIbus to receive alerts from other products that use EIF. In this integration, we use IBM Tivoli Monitoring and IBM Tivoli Composite Application Manager to send monitoring events.
Requirements
The following items must be installed:
•Object Server
•The probe-nonnative-base-3_0 package
•The Java 1.5 (supplied with Tivoli Netcool/OMNIbus) package
Installation
In this scenario, we use IBM Tivoli Netcool/OMNIbus V7.2.1. The instructions in this section for installing the IBM Tivoli Netcool/OMNIbus Probe for Tivoli EIF apply to this version.
Starting with Tivoli Netcool/OMNIbus V7.3, IBM Tivoli Netcool/OMNIbus Probe for Tivoli EIF is installed with the same installer as the core Tivoli Netcool/OMNIbus product. See “IBM Tivoli Netcool EIF Probe 9.0” on page 306 for more information.
Perform the following steps to install the probe:
1. Install the patches for non-native probe and EIF probe. For each patch, run the patch utility script:
$OMNIHOME/install/nco_patch -install <patchname>
In the script, <patchname> specifies the name of the patch you downloaded.
2. Copy the properties file:
cp <install_dir>/tivoli_eif.props $OMNIHOME/etc/PROBE_EIF.props
3. Edit the RulesFile and PortNumber as shown in Example 16-1
Example 16-1 PROBE_EIF.props example file
RulesFile : '$OMNIHOME/probes/linux2x86/tivoli_eif.rules'
PortNumber : 9998
4. Run the SQL provided by EIF probe to update the alert.status table with new fields needed for the data coming from IBM Tivoli Monitoring:
$OMNIHOME/bin/nco_sql -user <username> -password <password> -server <obj_serv> < $OMNIHOME/probes/linux2x86/tec_db_update.sql
The command has the following definitions:
username Specifies the name of user authorized to run Tivoli Netcool/OMNIbus
password Specifies the password associated with this user
obj_serv Specifies the name of ObjectServer instance to which the gateway will connect
We use the following command:
$OMNIHOME/bin/nco_sql -user netcool -password netcool -server NCOMS < $OMNIHOME/probes/linux2x86/tec_db_update.sql
|
Note: In this scenario, we use Process Agent. Because probe calls the correct version of Java when started through Process Agent, we add JAVA_HOME to the nco_p_tivoli_eif file and change the exec command line as follows:
JAVA_HOME=/opt/ibm/netcool/platform/linux2x86/jre_1.5.6/jre
exec $OMNIHOME/probes/$ARCH/nco_p_nonnative $JAVA_HOME/bin/java $NCO_JPROBE_JAVA_FLAGS -cp $CLASSPATH $NCO_JPROBE_JAVA_XFLAGS -DOMNIHOME="$OMNIHOME" $PROGRAM "$@"
|
For more information, see IBM Tivoli Netcool/OMNIbus Probe for Tivoli EIF Reference Guide, SC23-6072.
16.5.2 Tivoli Event Synchronization
The IBM Tivoli Monitoring V6.2.2 Tools, Multiplatform, English product is an IBM Tivoli Monitoring component that is used to send Tivoli Netcool/OMNIbus event updates back to Tivoli Enterprise Monitoring Server.
Installation
Installation of the Tivoli Event Synchronization is as follows:
1. Run the ESync2200<operating_system>.bin file in the tec subfolder.
We used the following command:
./ESync2200Linux.bin
The welcome window opens as shown in Figure 16-2.
Figure 16-2 Welcome window
2. Accept the terms of license agreement as shown in Figure 16-3 on page 421.
Figure 16-3 License Agreement
3. Specify the installation directory as shown in Figure 16-4.
Figure 16-4 Directory Name
4. Set the configuration values, as shown in Figure 16-5 on page 422 and in Figure 16-6 on page 422.
|
Tip: The debug level can be set to med or verbose to increase log details.
|
Figure 16-5 Configuration 1
Figure 16-6 Configuration 2
5. Set Tivoli Enterprise Monitoring Server access information as shown in Figure 16-7 on page 423.
|
Note: Be sure that you use the fully qualified host name that matches the ITMHostname field in the Event List.
|
Figure 16-7 Tivoli Enterprise Monitoring Server Configuration
6. Click Next to proceed and then click Finish to exit the installation wizard.
Configuration
Perform the following steps to configure the Tivoli Event Synchronization:
1. Configure the object server settings in the $OMNIHOME/etc/NCOMS.props file as shown in Example 16-2.
Example 16-2 NCOMS.props example for PA credentials
PA.Password: 'EHELAGBFBOFPFIGK'
PA.Username: 'root'
|
Notes:
•To run the event synchronization program from SQL automation scripts for sending synchronization events to the monitoring server, the Tivoli Netcool/OMNIbus event server must be running under process control.
•If the password is not blank, it should be encrypted by the following encryption utility and then PA.Password should be set to this encrypted value:.
$OMNIHOME/nco_pa_crypt
|
2. Restart the object server:
$OMNIHOME/bin/nco_pa_stop -process <obj_serv>
$OMNIHOME/bin/nco_pa_start -process <obj_serv>
3. Update the object server database schema by running the following command:
$OMNIHOME/bin/nco_sql -U <username> -P <password> -S <obj_serv> < <path_to_file>/itm_proc.sql
$OMNIHOME/bin/nco_sql -U <username> -P <password> -S <obj_serv> < <path_to_file>/itm_db_update.sql
$OMNIHOME/bin/nco_sql -U <username> -P <password> -S <obj_serv> < <path_to_file>/itm_sync.sql
4. Update the probe rules by replacing the original rules file with the file that is provided by event synchronization as follows:
cp <suf_install_dir>/omnibus/tivoli_eif.rules $OMNIHOME/probes/<arch>
The command has the following definitions:
suf_install_dir Specifies the folder where Tivoli Event Synchronization is installed.
arch Specifies the architecture of server where EIF probe is installed.
5. Restart the EIF probe:
nco_pa_stop -user netcool -password netcool -process ProbeEIF
nco_pa_start -user netcool -password netcool -process ProbeEIF
6. Configure event synchronization to send error events to the object server. Edit the <suf_install_dir>/omnibus/errorevent.conf file as shown in Example 16-3.
Example 16-3 errorevent.conf file example for EIF probe
ServerName=nci51demo.nci.ibm.com
ServerPort=9998
The example uses the following settings:
ServerName Specifies the name of server where EIF probe is running.
ServerPort Specifies the port listened by EIF probe.
7. Test the Tivoli Enterprise Monitoring Server connection by running the following command (and see Example 16-4):
<suf_install_dir>/bin/test.sh
Example 16-4 Testing connectivity
[root@nci51demo bin]# ./test.sh
Successfully connected to Tivoli Enterprise Monitoring Server ti0003-sys9.itso.ral.ibm.com
8. Run Situation Update Forwarder (SUF) by running the following command:
<suf_install_dir>/bin/startSUF.sh
For more information, see IBM Tivoli Monitoring Installation and Setup Guide, GC32-9407-03.
16.5.3 Event forwarding to Tivoli Netcool/OMNIbus
This step enables IBM Tivoli Monitoring to forward events to Tivoli Netcool/OMNIbus Probe for Tivoli EIF.
The configuration steps are as follows:
1. Configure Hub TEMS by running the following command:
$CANDLEHOME/bin/itmcmd config -S -t <tems_name>
In the command, tems_name is the name of monitoring server
2. Enter the EIF server host name and port during configuration as shown in Example 16-5.
Example 16-5 Event Integration Facility settings
Tivoli Event Integration Facility? [1=YES, 2=NO] (Default is: 1):
EIF Server Host Name or type 0 for "none" :(Default is: 0): nci51demo.nci.ibm.com
EIF Port? (Default is: 0): 9998
3. Restart Hub TEMS:
$CANDLEHOME/bin/itmcmd server stop <tems_name>
$CANDLEHOME/bin/itmcmd server start <tems_name>
16.5.4 Creating the mapping table and populating the data in CCMDB
In this step, we explain how to create the mapping table and populate the data in CCMDB.
The mapping table contains data for classification. Through this table, incident ticket and request for change is mapped to the correct item such as classification and owner group.
Other CCMDB data such as Change Window Calender, Configuration Item, and Response Plan have an important role for the scenario because they provide required information to other components.
Creating Change Window Calendars
We start by creating Change Window Calendars. These calenders specify maintenance windows that we check before incident ticket creation.
Perform the following steps:
1. With administrative permissions, log on to the CCMDB server.
2. In the Start Center window, click Go To → Change → Change Window Calendars.
3. Create a new Change Window Calendar:
a. Enter a Change Window Calendar Name, for example: WINDOW1
b. Enter description, for example: Change Window 1
c. Enter Start Date, for example 4/1/10
d. Enter End Date, for example 4/1/11
e. Save Calendar.
4. Click Select Action → Schedule Change Windows.
5. Change Duration to 8:00.
6. Click the first option button. Enter Every 1 day(s) at 00:00 time.
7. Click Preview. The Date Preview list (Figure 16-8) shows date information, similar to the following values:
4/2/10 00:00:00
4/3/20 00:00:00
Figure 16-8 Set Schedule Window1
8. Click OK to close the window.
Figure 16-9 Change Window Calendars
10. Create another new Change Window Calendar.
a. Enter Change Window Calendar Name, for example: WINDOW2
b. Enter description, for example: Change Window 2
c. Enter Start Date, for example 4/1/10
d. Enter End Date, for example 4/1/11
e. Save the Calendar.
11. Click Select Action → Schedule Change Windows.
12. Change Duration to 8:00.
13. Click the first option button. Enter Every 1 day(s) at time 12:00.
14. Click Preview. The Date Preview list shows information similar to the following values:
– 4/2/10 12:00:00
– 4/3/20 12:00:00
15. Click OK to close dialog box.
16. Click Save again to save change window.
Creating Configuration Items
Perform the following steps to create the Configuration Items:
1. Log on to the CCMDB server with administrative permission.
2. In the Start Center window, click Go To → IT Infrastructure → Configuration Items.
3. Click New CI in the toolbar to create a new configuration item.
4. Set Configuration Item Number field to TI003-SYS3.
5. Set Configuration Item Name field to TI0003-SYS3.
6. Set Classification field to CIROOT CI.COMPUTERSYSTEM CI.WINDOWSCOMPUTERSYSTEM.
7. In the Specifications section, set the Alphanumeric Value field for COMPUTERSYSTEM_NAME to TI0003-SYS3.
8. Set Service field to SHIPPING.
9. Set CI Location field to FACILITY.
10. Set Change Window to WINDOW1.
11. Set CI Owner to a valid person, for example MKIPEL.
Figure 16-10 Create Configuration Item
13. Repeat steps 3 on page 427 - 12 on page 427 to enter additional Configuration Items, listed in Table 16-2.
Table 16-2 Configuration Item list
|
Configuration Item number and name
|
Classification
|
Service
|
CI location
|
CI Owner
|
Change Window
|
COMPUTERSYSTEM_NAME
|
|
TI003-SYS3
|
CIROOT CI.COMPUTERSYSTEM CI.WINDOWSCOMPUTERSYSTEM
|
SHIPPING
|
OFFICEHQ
|
BENJAMINW
|
WINDOW1
|
TI003-SYS3
|
|
TI003-SYS14
|
CIROOT CI.COMPUTERSYSTEM CI.WINDOWSCOMPUTERSYSTEM
|
SUPPLYCH
|
OFFICEHQ
|
FINLEY
|
WINDOW2
|
TI003-SYS14
|
|
was60
|
CIROOT CI.COMPUTERSYSTEM CI.LINUXCOMPUTERSYSTEM
|
DISTRIBY
|
WEST
|
AMAN
|
WINDOW1
|
was60
|
Creating the Impact table
Perform the following steps to create the Impact table:
1. With administrative permission, log on to the CCMDB server.
2. In the Start Center window, click Go To → System Configuration → Platform Configuration → Database Configuration.
3. Create a new object:
a. Click New Object, on the toolbar.
b. Set Object field to IMPACTMAP.
c. Set Object description to Impact Map.
d. Check Main Object check box.
Figure 16-11 Create IMPACTMAP Object
5. Click Mark Row for Delete icon on the DESCRIPTION row.
6. Check that the status of the DESCRIPTION row indicates DELETE.
7. Click Save Object, on the toolbar.
8. Click Mark Row for Delete icon on the DESCRIPTION_LONGDESCRIPTION row.
9. Check that the status of the DESCRIPTION_LONGDESCRIPTION row indicates DELETE.
10. Click Save Object, on the toolbar.
11. Click New Row.
12. Set Attribute field to Changeclassification.
13. Click Save Object, on the toolbar.
Figure 16-12 ChangeClassification Attribute
14. Click New Row.
16. Click Save Object, on the toolbar.
Figure 16-13 incidentClassification Attribute
17. Click New Row.
19. Set Same as Object field to TICKET.
20. Set Same as Field field to IMPACT.
21. Click Save Object, on the toolbar.
Figure 16-14 Impact Attribute
22. Click New Row.
24. Press Tab key.
25. Set Same as Object field to TICKET.
26. Set Same as Field field to URGENCY.
27. Click Save Object, on the toolbar.
Figure 16-15 Urgency Attribute
28. Click New Row.
30. Press tab.
31. Set Same as Object field to PERSONGROUP.
32. Set Same as Field field to PERSONGROUP.
33. Click Save Object, on the toolbar.
Figure 16-16 Ownergroup Attribute
34. Click New Row.
36. Press tab.
37. Set Same as Object field to PERSONGROUP.
38. Set Same as Field field to PERSONGROUP.
39. Click Save Object, on the toolbar.
Figure 16-17 Classificationid Attribute
40. Click List tab.
41. Click Select Action → Manage Admin Mode.
42. Click Turn Admin Mode On.
43. In the Electronic Signature Authentication window, enter password of the currently logged on administrative user.
44. Enter a reason for change, for example: Impact Table Creation.
45. Click OK.
46. Click OK again to close system message dialog box.
48. When you see the message Successfully Set Admin Mode ON, click Close.
Figure 16-18 Turning Admin Mode ON
49. Click Select Action → Apply Configuration Changes.
50. In the Structural Database Configuration dialog box, select the Do you have a Current Backup check box.
51. Click Start Configuring the Database.
52. In the Electronic Signature Authentication dialog box, enter the password of the currently logged on administrative user.
53. Enter a reason for change, for example: Impact Table Creation.
54. Click OK.
55. Click OK again to close system message dialog box.
56. Wait for a couple of minutes, then click Refresh Status.
57. Click OK.
58. Click Select Action → Manage Admin Mode
59. Click Turn Admin Mode OFF.
60. Wait for a couple of minutes, and then click Refresh Status.
Figure 16-19 Turning Admin Mode off
Creating the Impact Application
Perform the following steps to create the Impact Application:
1. Log on to the CCMDB server with administrative permission.
2. In the Start Center window, click Go To → System. Configuration → Platform Configuration → Application Designer.
3. Click New Application Definition, on the toolbar.
4. Set Application field to IMPACTMAP.
5. Set Description field to Impact Map.
6. Set Main Object field to IMPACTMAP
7. Set Key Attribute field to IMPACTMAPID
8. Set Module Name to SD (Service Desk).
Figure 16-20 Create the Impactmap application
10. In the application designer application, drag the Classificationid field to the Impact field. See Figure 16-21.
Figure 16-21 Drag and Drop Classification ID
11. Click the Control Palette, on the toolbar.
12. Drag the Table Column icon from the Control Palette to the first column of table. Perform this step five more times. See Figure 16-22.
Figure 16-22 Application Designer Control Palette
13. Click the X icon on the top right corner of Control Palette to close.
Figure 16-23 Edit Properties Menu
15. In the Table Column Properties dialog box, set the Attribute field to CLASSIFICATIONID (press the Tab key to refresh the designer canvas). See Figure 16-24.
Figure 16-24 Set classificationid attribute.
16. Click the second table column.
17. In the Table Column Properties dialog box, set the Attribute field to CHANGECLASSIFICATION (press the Tab key to refresh the designer canvas).
18. Click the third table column.
19. In the Table Column Properties dialog box, set the Attribute field to INCIDENTCLASSIFICATION (press the Tab key to refresh the designer canvas).
20. Click the fourth table column.
21. In the Table Column Properties dialog box, set the Attribute field to IMPACT (press the Tab key to refresh the designer canvas)
22. Click the fifth table column.
23. In the Table Column Properties dialog box, set the Attribute field to URGENCY (press the Tab key to refresh the designer canvas)
24. Click the sixth table column.
25. In the Table Column Properties dialog box, set the Attribute field to OWNERGROUP (press the Tab key to refresh the designer canvas)
26. Click Save Application Definition, on the toolbar.
Populating the Impact table
Perform the following steps to populate the Impact table:
1. Log on to the CCMDB server with administrative permission.
2. In the Start Center window, click Go To → Service Desk → Impact Map.
3. Click the New Row.
4. Set ClassificationId to ITM_DB_CONNECTION_POOLS.
5. Set ChangeClassification to J2EEMDDB.
6. Set IncidentClassification to 21020307.
7. Set Impact to 1.
8. Set Urgency to 1.
9. Set Ownergroup to HARDWARE.
Figure 16-25 IMPACTMAP
11. Repeat the steps 1-10 to enter the values in Table 16-3 on page 441.
Table 16-3 Impact mapping
|
ClassificationID
|
Change
Classification |
Incident
Classification |
Impact
|
Urgency
|
Ownergroup
|
|
ITM_DB_Connection_Pools
|
J2EEMDDB
|
21020307
|
1
|
1
|
HARDWARE
|
|
ITM_Thread_Pools
|
J2EEMSRA
|
21020307
|
2
|
2
|
HARDWARE
|
|
ITM_Garbage_Collection_Analysis
|
J2EEMSRA
|
21020307
|
3
|
2
|
HARDWARE
|
|
ITM_NT_Process
|
4010304
|
1010103
|
2
|
1
|
HARDWARE
|
Column headings are as follows:
ClassificationID Specifies the alerts.status.AlertGroup value, which we map.
ChangeClassification Specifies CLASSSTRUCTURE.CLASSIFICATION.ID for RFC.
IncidentClassification Specifies CLASSANCESTOR.CLASSIFICATIONID for incident ticket.
Impact Specifies impact of incident. Value varies in 1 - 5 range.
Urgency Specifies urgency of incident. Value varies in 1 - 5 range.
Ownergroup Specifies ownergroup of RFC or incident ticket.
Creating the Actions
Perform the following steps to create the Actions. These actions are required to fulfill automatically RFC details.
1. Log on to the CCMDB server with administrative permission.
2. In the Start Center window, click Go To → System Configuration → Platform Configuration → Actions.
3. Click New Action, on the toolbar.
4. Set Action field to CHANGEDESCRIPTION1.
5. Set Object field to WOCHANGE.
6. Set Type field to Set Value.
7. Set Value field to Need of more powerful machine as it is under powered DB server.
8. Set Parameter/Attribute field to description.
9. Save the action, as shown in Figure 16-26.
Figure 16-26 New Action
10. Create the actions in Table 16-4.
Table 16-4 Actions
|
Action
|
Object
|
Type
|
Value
|
Parameter
|
|
CHANGEDESCRIPTION1
|
WOCHANGE
|
Set Value
|
'Need of more powerful machine as it is under powered DB server'
|
description
|
|
CHANGEREASONFORCHANGE1
|
WOCHANGE
|
Set Value
|
'HIGH DB2 UTIL'
|
reasonforchange
|
|
CHANGERISK1
|
WOCHANGE
|
Set Value
|
'No Risk'
|
risk
|
|
CHANGEESTDUR1
|
WOCHANGE
|
Set Value
|
2
|
estdur
|
|
CHANGEJUSTIFYPRIORITY1
|
WOCHANGE
|
Set Value
|
'BUSINESS CRITICAL'
|
justifypriority
|
|
CHANGEVERIFICATION1
|
WOCHANGE
|
Set Value
|
'VERIFIED'
|
verification
|
|
CHANGEWOPRIORITY1
|
WOCHANGE
|
Set Value
|
1
|
wopriority
|
11. Add all actions created with type Set Value in the previous step to CHANGEGROUP1 as member.
Creating the Escalations
Perform the following steps to create the Escalations, which are required to periodically run specific response plans:
1. Log on to the CCMDB server with administrative permission.
2. In the Start Center window, click Go To → System Configuration → Platform Configuration → Escalations
3. Click New Escalation, on the toolbar.
4. Set Applies To field to WOCHANGE
5. Set Schedule field as follows:
2m,*,*,*,*,*,*,*,*,*
6. Click New Row, in the Actions section.
7. Select the Apply Response Plan Action
8. Save the escalation.
9. Click Select Action → Validate
Figure 16-27 Escalations
Creating the Response Plans
Perform the following steps to create the Response Plans, which are containers that contain actions.
1. Log on to the CCMDB server with administrative permission.
2. In the Start Center window, click Go To → Service Level → Response Plans.
3. Click Create New Response Plan, on the toolbar.
4. Set Response Plan field to IMPACTRP1.
5. Set Ranking field to 10.
6. Set Description to Response Plan for IMPACT RFC.
7. Click the Conditions tab.
8. Set Classification field to PMCHG PMCHGSFW MDLEWARE J2EEMDDB
9. Click Response Actions Tab.
10. Click New Row on the Actions section.
11. Enter Action Change Description 1.
12. Repeat steps 9-10 for actions in Table 16-4 on page 442.
13. Save Response Plan.
14. Click Select Action → Change Status.
Figure 16-28 Response Plans
Creating the Work Flows
Perform the following steps to create the Work Flows:
1. Log on to the CCMDB server with administrative permission.
2. In the Start Center window, click Go To → System Configuration → Platform Configuration → Workflow Designer
3. Click New Process, on the toolbar.
4. Set Process field to CHANGERP.
5. Set Object Field to WOCHANGE.
6. Click the Connect Nodes icon.
7. When the mouse pointer turns into a yellow pen icon, click the Start1 Icon on the workflow canvas.
8. Drag a line and drop on STOP2 icon.
9. Double Click the line between START1 and STOP2 icon.
10. Enter action name in the Action field.
Figure 16-29 Set Workflow Action
12. Click Select Action → Enable Process
Figure 16-30 CHANGERP Workflow.
16.5.5 Tivoli Netcool/OMNIbus additional fields
For event enrichment, we must add more fields to the alerts.status table on Tivoli Netcool/Impact Object Server:
Example 16-6 impactFields.sql file
alter table alerts.status add CI VARCHAR(100);
alter table alerts.status add AffectedPerson VARCHAR(50);
alter table alerts.status add AffectedService VARCHAR(50);
alter table alerts.status add AssetLocSiteID VARCHAR(50);
alter table alerts.status add Impact INTEGER;
alter table alerts.status add Urgency INTEGER;
alter table alerts.status add OwnerGroup VARCHAR(50);
alter table alerts.status add HierarchyPath VARCHAR(50);
alter table alerts.status add Action VARCHAR(50);
go
2. Run the SQL file as shown in Example 16-7.
Example 16-7 Running the ImpactFields.sql file
[netcool@nci51demo sql]$ nco_sql -user netcool -password netcool < ImpactFields.sql
(0 rows affected)
16.5.6 Configuring Tivoli Service Request Manager to initialize application server
Perform the following steps to configure IBM Tivoli Service Request Manager to receive alerts from Tivoli Netcool/OMNIbus and web services requests from Tivoli Netcool/Impact:
1. Log on to the CCMDB server with administrative permission.
2. In the Start Center window, click Go To → System Configuration → Platform Configuration → System Properties
3. Configure Web Application URL and Integration Global Directory to match the address of your IBM Tivoli Service Request Manager application server:
a. Navigate to mxe.int.webappurl.
b. In the Global Value field, set the application server URL:
http://<server_ip>/meaweb
c. Select the value next to the mxe.int.webappurl check box.
d. Save the property and click Live Refresh.
e. Navigate to mxe.int.globaldir.
f. In the Global Value field, set the path of global directory to:
<websphere_application_installation_path>profilesAppSrv01axis2
g. Select the mxe.int.globaldir check box value.
h. Save the property and click Live Refresh.
4. Configure Tivoli Service Request Manager to receive journal entries:
a. Click menu Go To → Integration → Object Structures.
b. Search for specify Object Structure MXOSINCIDENT.
c. With the selected Object Structure, go to Action menu and select Generate Schema/View XML option.
d. Confirm the system message.
16.5.7 Tivoli Netcool/OMNIbus Gateway for Tivoli Service Request Manager
This product, IBM Tivoli Netcool/OMNIbus Gateway for Tivoli Service Request Manager (nco-g-tsrm-1_1) for Linux English, integrates Tivoli Netcool/OMNIbus with Tivoli Service Request Manager to open incidents using object server alerts.
Requirements
The following items must be installed:
•Object Server
•The omnibus-linux2x86-gateway-libngjava-1_0 patch
•The omnibus-linux2x86-gateway-libtal-1_2 patch
•The omnibus-linux2x86-gateway-nco-g-tsrm-1_1 patch
Installation
Perform the following steps:
1. Install the patches by running the following patch utility script for each patch:
$OMNIHOME/install/nco_patch -install <patchname>
In the utility, patchname specifies the name of the patch you downloaded in each case.
2. Install TAL API automations and gateway patches:
$OMNIHOME/bin/nco_sql -U <username> -P <password> -S <obj_serv> < $OMNIHOME/gates/tal/tal_automations.sql
$OMNIHOME/bin/nco_sql -U <username> -P <password> -S <obj_serv> < $OMNIHOME/gates/tsrm/tsrm.sql
We use the following commands:
$OMNIHOME/bin/nco_sql -user netcool -password netcool -server NCOMS < $OMNIHOME/gates/tal/tal_automations.sql
$OMNIHOME/bin/nco_sql -user netcool -password netcool -server NCOMS < $OMNIHOME/gates/tsrm/tsrm.sql
3. Copy the properties file (NCO_GATE.props) to the $OMNIHOME/etc folder:
cp <install_dir>/NCO_GATE.props $OMNIHOME/etc/GATE_TSRM.props
Configuration
Perform the following steps:
1. Edit the GATE_TSRM.props file to configure Tivoli Service Request Manager parameters:
a. Copy NCO_GATE.props file to the $OMNIHOME/etc folder:
cp <install_dir>/NCO_GATE.props $OMNIHOME/etc/GATE_TSRM.props
b. Edit the properties file as shown in Example 16-8.
Example 16-8 GATE_TSRM.props
Gate.TSRM.UserName : 'maxadmin'
Gate.TSRM.Password : 'maxadmin'
Gate.TSRM.PollTime : 30
Gate.TSRM.CreateTicketTemplate : '$OMNIHOME/gates/tsrm/create.xml.template'
Gate.TSRM.UpdateTicketTemplate : '$OMNIHOME/gates/tsrm/update.xml.template'
Gate.TSRM.QueryTicketTemplate : '$OMNIHOME/gates/tsrm/query.xml.template'
Gate.TSRM.JournalTemplate : '$OMNIHOME/gates/tsrm/journal.xml.template'
Gate.TSRM.URLList : 'http://9.42.171.198/meaweb/os/MXOSINCIDENT'
Gate.TSRM.TicketObjectName : 'MXOSINCIDENT'
Gate.TSRM.TimeZone : ''
Name : 'GATE_TSRM'
Gate.RdrWtr.TblReplicateDefFile : '$OMNIHOME/gates/tsrm/tsrm.rdrwtr.tblrep.def'
Gate.MapFile : '$OMNIHOME/gates/tsrm/tsrm.map'
Gate.StartupCmdFile : '$OMNIHOME/gates/tsrm/tsrm.startup.cmd'
Gate.TAL.NBScriptFileName : '$OMNIHOME/gates/tsrm/tsrm.script'
Gate.TAL.TTFilterClause : 'LogTicket=1'
2. Create a tool named Create Ticket. This tool changes the key field LogEvent to 1 (shown in Figure 16-31) so that IBM Tivoli Netcool/OMNIbus Gateway for Tivoli Service Request Manager gateway identifies and sends this alert forward.
Perform the following steps:
a. Open nco_config with administrative permission.
b. Access the Navigator menu and select the server name.
c. With administrative permission, connect at NCOMS.
d. Click Menu → Tools option.
Figure 16-31 Creating a tool in nco_config
f. Go to Menu → Menus → AlertsMenu.
g. Create a menu called CreateTicket that is associated with the CreateTicket tool.
3. Create an automation using triggers that will close an event when the corresponding incident has been closed:
a. Open nco_config with administrative permission.
b. Access Navigator menu and select NCOMS.
c. With administrative permission, connect at NCOMS.
d. Select the Automation → Triggers option.
e. Create a timer trigger. See Figure 16-32 on page 449.
Figure 16-32 Creating a trigger in nco_config
|
Tip: In the trigger configuration in Figure 16-32 on page 449, shows the following update clause:
“update alerts.status set Severity = 0 where Severity > 0 and TicketStatus = 'Closed';”
This clause can also be written as follows, which prevents the update from firing repetitively on the same event:
“update alerts.status set Severity = 0 where Severity > 0 and TicketStatus = 'Closed';”
|
4. Edit the $OMNIHOME/gates/tsrm/tsrm.map file to configure field mapping between alerts.status table fields and incident object fields. See Example 16-9.
Example 16-9 The tsrm.map example file
CREATE LOOKUP SeverityTable (
{3 , 3},
{4 , 2},
{5 , 1} )
DEFAULT = 4 ;
CREATE LOOKUP StatusTable (
{0 , 'RESOLVED'})
DEFAULT = '' ;
CREATE MAPPING StatusMap
(
'DESCRIPTION' = '@Identifier' ON INSERT ONLY,
'DESCRIPTION_LONGDESCRIPTION' = '@Summary' ON INSERT ONLY,
'EXTERNALSYSTEM' = 'EVENTMANAGEMENT',
'REPORTEDBY' = 'NETCOOL AUTOMATION',
'REPORTDATE' = TO_TIME('@FirstOccurrence') ON INSERT ONLY,
'REPORTEDPRIORITY' = Lookup('@Severity','SeverityTable'),
'STATUS' = Lookup('@Severity', 'StatusTable'),
'TTNumber' = '@TTNumber',
'CINUM' = '@CI',
'AFFECTEDPERSON' = '@AffectedPerson',
'COMMODITY' = '@AffectedService',
'ASSETSITEID' = '@AssetLocSiteID',
'IMPACT' = '@Impact',
'URGENCY' = '@Urgency',
'OWNERGROUP' = '@OwnerGroup',
'HIERARCHYPATH' = '@HierarchyPath'
);
CREATE MAPPING JournalMap
(
'Chrono' = '@Chrono',
'CREATEDATE' = TO_TIME('@Chrono'),
'DESCRIPTION' = 'NETCOOL JOURNAL ENTRY',
'DESCRIPTION_LONGDESCRIPTION' = TO_STRING('@Text1') + TO_STRING('@Text2') + TO_STRING('@Text3')
);
|
Tip: Observe the maximum field length in TSRM. If the length is not respected, the ticket cannot be opened and an error is generated in the GATE_TSRM.log file.
|
For more information n see IBM Tivoli Netcool/OMNIbus Gateway for TSRM, SC27-2703.
16.5.8 Tivoli Netcool/OMNIbus Process Agent control
Process Agent is a program that manages processes and services in a process control system. We use Process Agent for managing the object server, probe for EIF, and Tivoli Service Request Manager gateway.
Process agent is configured by the $OMNIHOME/etc/nco_pa.conf configuration file as shown in Example 16-10.
Example 16-10 The nco_pa.conf example file
nco_process 'MasterObjectServer'
{
Command '$OMNIHOME/bin/nco_objserv -name NCOMS -pa NCO_PA' run as 0
Host = 'nci51demo'
Managed = True
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 0
ProcessType = PaPA_AWARE
}
nco_process 'GateTSRM'
{
Command '$OMNIHOME/bin/nco_g_tsrm -name GATE_TSRM -propsfile $OMNIHOME/etc/GATE_TSRM.props' run as 0
Host = 'nci51demo'
Managed = True
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 3
ProcessType = PaPA_AWARE
}
nco_process 'ProbeEIF'
{
Command '$OMNIHOME/probes/nco_p_tivoli_eif -name PROBE_EIF -propsfile $OMNIHOME/etc/PROBE_EIF.props' run as 0
Host = 'nci51demo'
Managed = True
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 3
ProcessType = PaPA_AWARE
}
nco_service 'Core'
{
ServiceType = Master
ServiceStart = Non-Auto
process 'MasterObjectServer' NONE
process 'GateTSRM' 'MasterObjectServer'
process 'ProbeEIF' 'MasterObjectServer'
}
nco_service 'InactiveProcesses'
{
ServiceType = Non-Master
ServiceStart = Non-Auto
}
nco_routing
{
host 'nci51demo' 'NCO_PA' 'user' 'password'
}
After editing the configuration file perform the following steps:
1. Start the Process Agent:
sudo $OMNIHOME/bin/nco_pad -name NCO_PA
2. Start ProbeEIF:
nco_pa_start -user netcool -password netcool -process ProbeEIF
3. Start Tivoli Netcool/OMNIbus Gateway for Tivoli Service Request Manager gateway:
nco_pa_start -user netcool -password netcool -process GateTSRM
For more information about Process Agent, see IBM Tivoli Netcool/OMNIbus Administration Guide, SC23-6371.
16.5.9 The Tivoli Netcool/Impact project
In this step, we create a new Tivoli Netcool/Impact project and include the following data models:
•Data sources
•Data types
•Data items
•Links
Creating a new project
Perform the following steps to create a new project:
1. Log on to the Netcool/Impact server with administrative permission.
2. On the Projects tab, click New Project.
Figure 16-33 New Project
Creating data sources
Perform the following steps:
1. Inside the project, go to Data Sources and Types section and click New Data Source after selecting DB2 as source type.
2. Specify the connection settings for MAXDB as shown in Figure 16-34 on page 453.
Figure 16-34 Data source settings for MAXDB
Figure 16-35 Connection test
4. Click OK to return to the project.
5. Select ObjectServer as source type and click New Data Source.
6. Specify the connection settings for Object Server as shown in Figure 16-36.
Figure 16-36 Data source settings for NCOMS
7. Test the connection and click OK to return to project.
Creating data types
Follow these steps to create the Data Types:
1. Inside the project, go to the Data Sources and Types section and click Create a new data type of MAXDB, next to MAXDB.
2. Set Data Type Name field to CLASSANCESTOR.
3. Select MAXDB in the drop-down Data Source Name menu.
4. Set Base Label to CLASSANCESTOR and click Refresh.
5. Set primary key to CLASSANCESTORID by checking Key Field in the same row.
Figure 16-37 shows the data type settings.
Figure 16-37 Data type example for CLASSANCESTOR table
6. Click Save, and close the edit window.
7. Repeat the steps 1 - 6 to enter the values in Table 16-5.
Table 16-5 Data types
|
Data Type Name
|
Data Source Name
|
Base Label
|
Key Field
|
|
CLASSSTRUCTURE
|
MAXDB
|
CLASSSTRUCTURE
|
CLASSSTRUCTUREID
|
|
CISPEC
|
MAXDB
|
CISPEC
|
CISPECID
|
|
CI
|
MAXDB
|
CI
|
CIID
|
|
IMPACTMAP
|
MAXDB
|
IMPACTMAP
|
IMPACTID
|
|
PMCHGCWTP
|
MAXDB
|
PMCHGCWTP
|
PMCHGCWTPID
|
|
NCOMS_AllEvents
|
NCOMS
|
alerts.status
|
Identifier
|
|
Notes:
•When there is a change in the source table which data type refers to, you should refresh and save the data type.
•The CLASSANCESTOR table must be sorted by HIERARCHYLEVELS for a correct HierarchyPath assignment. Edit the Data Filter and Ordering part for this data type.
|
Creating the links
Perform the following steps to create the Links:
1. In the project, go to the Data Sources and Types section and click CISPEC data type.
2. Click the Dynamic Links tab.
3. Click New Link By Filter.
4. Select CI as the Target Data Type.
5. Set the Filter into target Data Type value to:
CINUM='%CINUM%'
6. Click OK to go back to data type window.
7. Click Save, and close this edit window.
8. Repeat steps 1 - 6 to enter the values in Table 16-6.
Table 16-6 Creating the Links
|
Source Data Type
|
Target Data Type
|
Filter into target Data Type
|
|
CISPEC
|
CI
|
CINUM='%CINUM%'
|
|
IMPACTMAP
|
CLASSANCESTOR
|
CLASSIFICATIONID='%INCIDENTCLASSIFICATION%'
|
|
IMPACTMAP
|
CLASSSTRUCTURE
|
CLASSIFICATIONID='%CHANGECLASSIFICATION%'
|
16.5.10 Tivoli Netcool/Impact Enrichment Policy for Incident Ticket
Perform the following steps to create an enrichment policy that enriches the event by using data gathered from CCMDB:
1. In the project, click Template → Custom and go to Policies → New Policy.
2. Edit the policy, as shown in Example 16-11.
Example 16-11 TSRM_Incident policy
@CI="Unknown";
@AssetLocSiteID="Unknown";
@AffectedService="Unknown";
@AffectedPerson="Unknown";
@Impact=1;
@Urgency=1;
@OwnerGroup="Unknown";
log("Start policy: TSRM_Incident");
CISPEC = GetByFilter('CISPEC', "(ALNVALUE='"+EventContainer.TECHostname+"')", false);
if (length(CISPEC) > 0)
{
CI=GetByLinks({"CI"},null,1,CISPEC);
if (length(CI) > 0)
{
@CI =""+CI[0].CINUM;
@AffectedService=""+CI[0].SERVICE;
@AffectedPerson=""+CI[0].PERSONID;
@AssetLocSiteID=""+CI[0].ASSETLOCSITEID;
PMCHGCWTP=GetByFilter('PMCHGCWTP', "(CALNUM='"+CI[0].PMCHGCWNUM+"')",false);
WindowNum=length(PMCHGCWTP);
if(WindowNum > 0)
{
Counter=0;
Maintenance=0;
EventTime=String(LocalTime(EventContainer.FirstOccurrence, "yyyy-MM-dd HH:mm:ss.S"));
while(Counter < WindowNum)
{
StartTime=String(PMCHGCWTP[Counter].STARTTIME);
EndTime=String(PMCHGCWTP[Counter].ENDTIME);
if((EventTime>=StartTime)&&(EventTime<=EndTime))
{
Maintenance=1;
Counter=WindowNum;
}
Counter=Counter+1;
}
if(Maintenance==1)
{
@Action="System is in maintenance mode, no action taken";
}
else
{
@Action="Incident ticket is created";
@LogTicket=1;
}
@Acknowledged=1;
}
}
}
IMPACT= GetByFilter('IMPACTMAP', "(CLASSIFICATIONID='"+EventContainer.AlertGroup+"')", false);
if(length(IMPACT) > 0)
{
PATH=GetByLinks({"CLASSANCESTOR"},null,10,IMPACT);
log(PATH);
PathLength=length(PATH);
Counter=0;
Path="";
while(Counter<PathLength)
{
if(Counter>0)
{
Path=" \ "+Path;
}
Path=PATH[Counter].ANCESTORCLASSID+Path;
Counter=Counter+1;
}
log("Classification Path is "+Path);
@Impact=IMPACT[0].IMPACT;
@Urgency=IMPACT[0].URGENCY;
@OwnerGroup=""+IMPACT[0].OWNERGROUP;
@HierarchyPath=Path;
}
ReturnEvent(EventContainer);
log("!!!!!!! End Of Executing Policy");
3. Rename the policy as TSRM_Incident and save it.
16.5.11 CCMDB Web Services
Perform the following steps to create web services in CCMDB:
1. Log on to the CCMDB server with administrative permission.
2. Navigate to Go To → System Configuration → Platform Configuration → WebServices Library.
3. Navigate to Select Actions → Create Web Service → Create WS from an Enterprise Service.
4. Select the source name EXTSYSTDI_MXChangeCreate and click Create.
5. In the List tab, go to EXTSYSTDI_MXChangeCreate.
6. Navigate to Select Action → Deploy Web Service. The following message is displayed:
Web Service is deployed for service EXTSYSTDI_MXChangeCreate
7. In the Operations section, click GenerateSchema/View XML.
8. In the View XML window, select and copy the XML data to a text editor.
Creating endpoint for Web Services
Perform the following steps to create the Web Services:
1. Navigate to Integration → Endpoint.
2. Create a new entry named IMPACT.
3. Set Handler value to WEBSERVICE.
4. Obtain the endpoint URL from the following file:
<websphere_application_installation_path>profilesAppSrv01axis2wsdlEXTSYSTDI_MXChangeCreate.wsdl
The URL is at the end of the file, and is similar to the following URL:
http://9.42.171.198/meaweb/services/EXTSYSTDI_MXChangeCreate
5. In the Property field, specify the endpoint URL from the previous step.
6. Obtain the soapAction value from the same WSDL file. The value is close to the end of the file on a line similar to the following line:
<soap12:operation soapAction="urn:processDocument" style="document" />
7. Set the SERVICENAME value to the service name in the WSDL file. For EXTSYSTDI_MXChangeCreate, use EXTSYSTDI_MXChangeCreateService.
8. Save your changes.
16.5.12 Tivoli Netcool/Impact Web Services DSA Policy for RFC
In this step, we compile WSDL file and create a web services policy that invokes CCMDB web service to create a request for change.
Compiling WSDL file
Perform the following steps to compile the WSDL file
1. Copy the following wsdl and schema folders from CCMDB server to Tivoli Netcool/Impact server:
<websphere_application_installation_path>profilesAppSrv01axis2wsdl
<websphere_application_installation_path>profilesAppSrv01axis2schema
2. Copy the following .xsd files to the wsdl folder in your Tivoli Netcool/Impact server:
schema/common/mos/MXOSCHANGE.xsd
schema/common/mbo/wochange.xsd
schema/common/meta/MXMeta.xsd
schema/service/MXOSCHANGEService.xsd
3. Edit the following .wsdl and .xsd files and replace the xsd:import and xsd:include paths according to the new paths in your Tivoli Netcool/Impact server as shown in Example 16-12.
Example 16-12 Changes in wsdl and xsd files
wsdl/EXTSYSTDI_MXChangeCreate.wsdl:
<xsd:import namespace="http://www.ibm.com/maximo" schemaLocation="MXOSCHANGEService.xsd"/>
schema/service/MXOSCHANGEService.xsd:
<xsd:include schemaLocation="MXMeta.xsd"/>
<xsd:include schemaLocation="MXOSCHANGE.xsd"/>
<xsd:include schemaLocation="wochange.xsd"/>
schema/common/mos/MXOSCHANGE.xsd:
<xsd:include schemaLocation="MXMeta.xsd"/>
schema/common/mbo/wochange.xsd:
<xsd:include schemaLocation="MXMeta.xsd"/>
4. Run the nci_compilewsdl command to compile the WSDL file and to produce a set of Java class files that contain a programmatic representation of the WSDL data:
$IMPACT_HOME/bin/nci_compilewsdl <package_name> <wsdl_file> <destination>
The command has the following definitions:
package_name Specifies name of the .jar file
wsdl_file Specifies the location of the WSDL file on the local file system.
destination Specifies the directory to which to copy the generated .jar file.
We use the following command:
$IMPACT_HOME/bin/nci_compilewsdl EXTSYSTDI_MXChangeCreate /home/netcool/wsdl/EXTSYSTDI_MXChangeCreate.wsdl $NCHOME/wslib
|
Notes:
•The Web Services Wizard is also capable of compiling the WSDL file. Instead of compiling the WSDL file as described in the previous step, you can select Provide a package name for the new client stub and enter Package Name as in Figure 16-39 on page 461.
•Current AXIS (Apache AXIS is an open source, XML-based web service framework) tools used in Netcool/Impact are unable to compile the WSDL files generated. After Netcool/Impact moves to the newer version of AXIS tools, the compilation of the WSDL file through URL will be supported.
|
Creating the Web Services Policy
We use Web Services Wizard to create our policy, as follows:
1. In the project, go to Wizards → Web Services.
Figure 16-38 Introduction
Figure 16-39 WSDL file and Client Stub
4. Select the web service, port type, and method, as shown in Figure 16-40.
Figure 16-40 Web Service name, port, and method
5. Expand the parameters and click OK after entering 1 as collection type size, as shown in Figure 16-41.
Figure 16-41 Web Service method parameters
6. Expand the parameters you want to add and fill in the default values. See Figure 16-42.
Figure 16-42 Web Service method parameters
Figure 16-43 Web Service method parameters
8. Check the End Point URL, as shown in Figure 16-44.
Figure 16-44 Web Service End Point
Figure 16-45 Summary and Finish
10. Newly created CCMDB_RFC policy is automatically open for editing. Add the section in Example 16-13 on page 468 to the beginning of the policy.
Example 16-13 Beginning of policy
@CI="Unknown";
@AssetLocSiteID="Unknown";
@OwnerGroup="Unknown";
log("Start policy: CCMDB_RFC");
CISPEC = GetByFilter('CISPEC', "(ALNVALUE='"+EventContainer.TECHostname+"')", false);
if (length(CISPEC) > 0)
{
CI=GetByLinks({"CI"},null,1,CISPEC);
if (length(CI) > 0)
{
@CI =""+CI[0].CINUM;
@AssetLocSiteID=""+CI[0].ASSETLOCSITEID;
}
}
IMPACT= GetByFilter('IMPACTMAP', "(CLASSIFICATIONID='"+EventContainer.AlertGroup+"')", false);
if(length(IMPACT) > 0)
{
ChangeClassification=GetByLinks({"CLASSSTRUCTURE"},null,1,IMPACT);
ClassificationID=""+ChangeClassification[0].CLASSSTRUCTUREID;
@OwnerGroup=""+IMPACT[0].OWNERGROUP;
}
11. To the end of the policy, add the section in Example 16-14.
Example 16-14 End of policy
@Action="RFC "+Extract(Extract(WSInvokeDLResult,5,"<"),1,">")+" is created";
@Acknowledged=1;
The final policy is shown in Example 16-15.
Example 16-15 CCMDB_RFC policy
//This policy generated by Impact Wizard.
//This policy is based on wsdl file at /home/netcool/wsdl/EXTSYSTDI_MXChangeCreate.wsdl
@CI="Unknown";
@AssetLocSiteID="Unknown";
@OwnerGroup="Unknown";
log("Start policy: CCMDB_RFC");
CISPEC = GetByFilter('CISPEC', "(ALNVALUE='"+EventContainer.TECHostname+"')", false);
if (length(CISPEC) > 0)
{
CI=GetByLinks({"CI"},null,1,CISPEC);
if (length(CI) > 0)
{
@CI =""+CI[0].CINUM;
@AssetLocSiteID=""+CI[0].ASSETLOCSITEID;
}
}
IMPACT= GetByFilter('IMPACTMAP', "(CLASSIFICATIONID='"+EventContainer.AlertGroup+"')", false);
if(length(IMPACT) > 0)
{
ChangeClassification=GetByLinks({"CLASSSTRUCTURE"},null,1,IMPACT);
ClassificationID=""+ChangeClassification[0].CLASSSTRUCTUREID;
@OwnerGroup=""+IMPACT[0].OWNERGROUP;
}
//Specify package name as defined when compiling WSDL in Impact
WSSetDefaultPKGName('EXTSYSTDI_MXChangeCreate'),
//Specify parameters
CreateMXOSCHANGEDocument=WSNewObject("com.ibm.www.maximo.CreateMXOSCHANGEDocument");
_CreateMXOSCHANGE=WSNewSubObject(CreateMXOSCHANGEDocument,"CreateMXOSCHANGE");
_MaximoVersion = '7.2.1';
_CreateMXOSCHANGE['MaximoVersion'] = _MaximoVersion;
_MessageID = '123456';
_CreateMXOSCHANGE['MessageID'] = _MessageID;
_TransLanguage = 'EN';
_CreateMXOSCHANGE['TransLanguage'] = _TransLanguage;
_BaseLanguage = 'EN';
_CreateMXOSCHANGE['BaseLanguage'] = _BaseLanguage;
//Handle special calendar type...
date = WSNewObject("java.util.GregorianCalendar");
_CreationDateTime = date;
_CreateMXOSCHANGE['CreationDateTime'] = _CreationDateTime;
_MXOSCHANGESet = WSNewSubObject(_CreateMXOSCHANGE,"MXOSCHANGESet");
_WOCHANGE_0_ = WSNewSubObject(_MXOSCHANGESet,"WOCHANGE");
_WOCHANGE_0_['TransLanguage'] = 'EN';
_WOCHANGE_0_['DeleteForInsert'] = '?';
_WOCHANGE_0_['Relationship'] = '?';
_WOCHANGE_0_['Action'] = WSNewEnum('com.ibm.www.maximo.ProcessingActionType','AddChange'),
_CINUM = WSNewSubObject(_WOCHANGE_0_,"CINUM");
_CINUM['StringValue'] = @CI;
_CINUM['Changed'] = true;
log(_CINUM['StringValue']);
_CLASSSTRUCTUREID = WSNewSubObject(_WOCHANGE_0_,"CLASSSTRUCTUREID");
_CLASSSTRUCTUREID['StringValue'] = ClassificationID;
_CLASSSTRUCTUREID['Changed'] = true;
log(_CLASSSTRUCTUREID['StringValue']);
_OWNERGROUP = WSNewSubObject(_WOCHANGE_0_,"OWNERGROUP");
_OWNERGROUP['StringValue'] = @OwnerGroup;
_OWNERGROUP['Changed'] = true;
log(_OWNERGROUP['StringValue']);
_SITEID = WSNewSubObject(_WOCHANGE_0_,"SITEID");
_SITEID['StringValue'] = @AssetLocSiteID;
_SITEID['Changed'] = true;
log(_SITEID['StringValue']);
WSParams = {CreateMXOSCHANGEDocument};
log(WSParams);
//Specify web service name, end point and method
WSService = 'EXTSYSTDI_MXChangeCreate';
WSEndPoint = 'http://9.42.171.198/meaweb/services/EXTSYSTDI_MXChangeCreate';
WSMethod = 'CreateMXOSCHANGE';
WSInvokeDLResult = WSInvokeDL(WSService, WSEndPoint, WSMethod, WSParams);
log("Response to Web Service call CreateMXOSCHANGE ...: " +WSInvokeDLResult);
@Action="RFC "+Extract(Extract(WSInvokeDLResult,5,"<"),1,">")+" is created";
@Acknowledged=1;
ReturnEvent(EventContainer);
log("!!!!!!! End Of Executing Policy");
12. Save your policy after you finish editing.
16.5.13 Tivoli Netcool/Impact policy for Tivoli Provisioning Manager workflow
In this step, we configure SOAP client for and create a new policy that invokes Tivoli Provisioning Manager workflow.
Configuring the SOAP Client
Perform the following steps to configure the SOAP Client:
1. Copy the contents of TIO_HOME/soapclient directory from the provisioning server to a folder created on the Tivoli Netcool/Impact server. We use the following command to copy the SOAP client:
scp -r /opt/IBM/tivoli/tpm/soapclient netcool@nci51demo:/home/netcool/SOAP
Example 16-16 The soapcli.sh file
JAVA_HOME=/opt/ibm/netcool/platform/linux2x86/jre_1.5.6/jre
TIO_HOME=/home/netcool/SOAP
export TIO_LIB="$TIO_HOME"/tpmlteSoap/lib
3. Save the soapcli.sh file.
Creating the workflow policy
Perform the following steps to create the workflow policy:
1. In the project, go to Policies and click Template → Custom, and then click New Policy.
2. Edit your policy, as shown in Example 16-17 on page 471.
Example 16-17 Workflow policy
Hostname=@TECHostname;
Command="/home/netcool/SOAP/tpmlteSoap/soapcli.sh";
Parameters={"maxadmin","maxadmin","http://9.42.171.32:8777/ws/pid/TpmLiteSoapService?wsdl","executeDeploymentRequest","Increase_Max_Heap_Size",Hostname,"20"};
TimeOut=60;
Response=JRExecAction(Command, Parameters, False, TimeOut);
WorkflowID=Trim(Extract(Response,1,":"));
Log("Sleeping");
JavaCall("java.lang.Thread",null,"sleep",{60000});
Log("Awake");
Parameters={"maxadmin","maxadmin","http://9.42.171.32:8777/ws/pid/TpmLiteSoapService?wsdl","isSuccessful",WorkflowID};
Response=JRExecAction(Command, Parameters, False, TimeOut);
Result=Trim(Extract(Response,1,":"));
if(Result=="true")
{
@Action="Provisioning workflow "+WorkflowID+" is succeeded";
@Acknowledged=1;
}
else
{
@Action="Provisioning workflow "+WorkflowID+" is failed";
}
ReturnEvent(EventContainer);
log("!!!!!!! End Of Executing Policy");
3. Rename the policy to TPM_Workflow and save it.
|
Note: In this example, we used the following values:
•The Increase_Max_Heap_Size workflow, which has two parameters: Hostname and Percentage. This workflow increases the max_heap_size as Percentage on the target Hostname.
•A value of 60 seconds as the waiting time between workflow execution and workflow result checking steps
|
Running JRExec server
JRExec is a runnable server component that is used by external commands or scripts from within a Tivoli Netcool/Impact policy. We use this server to run the soapcli.sh script.
Run the $NCHOME/impact/bin/nci_jrexec command to start JRExec server.
16.5.14 Tivoli Netcool/Impact event mapping
Perform the following steps to set Tivoli Netcool/OMNIbus Event Reader configuration to map specific events to specific policies:
1. In the project, click OMNIbus EventReader.
2. Click the Event Mapping tab.
3. Click New, next to New Mapping.
4. Set Filter Expression to the following value:
(AlertGroup = 'ITM_NT_Process') or (AlertGroup = 'ITM_Thread_Pools')
5. Select TSRM_Incident policy as Policy to Run.
6. Check Active.
7. Click OK.
8. Repeat steps 3 - 7 to enter the values in Table 16-7.
Table 16-7 Event mapping settings
|
Restriction Filter
|
Policy Name
|
Active
|
|
AlertGroup = 'ITM_DB_Connection_Pools'
|
CCMDB_RFC
|
Yes
|
|
ITM_Garbage_Collection_Analysis
|
TPM_Workflow
|
Yes
|
When complete, the event mapping setting looks similar to Figure 16-46.
Figure 16-46 Event Mapping
9. Click OK to return to project.
16.5.15 Edit Netcool/OMNIbus event list view
Perform the following steps to edit event list view:
|
AEL: In the figure, the native event list was used to show the monitor box and event list. You may also use the Web GUI Active Event List (AEL) for this purpose. AEL is the list of events that the user can configure to monitor the environment. With the help of certain tools, the user can work on the stored events and take actions. See Chapter 11, “WebGUI launch to IBM Tivoli Monitoring” on page 303 for details of Web GUI Active Event List (AEL).
|
Figure 16-47 The nco_event default view
2. Click View, in the All Events section.
3. Click Edit → Edit View.
4. Select CI, Action, TTNumber, and TicketStatus attributes and click Add.
5. Click Apply and then Close.
16.6 Scenario walk-through
In this section, we walk you through the scenario components.
This scenario starts with a Situation Event Console view in Tivoli Enterprise Portal. The operator views four critical situations in the Open status as shown in Figure 16-48.
Figure 16-48 Open Situations in Tivoli Enterprise Portal
In the background, the following operations occur:
1. Event Integration Facility running on IBM Tivoli Monitoring forwards these situations to Tivoli Netcool/OMNIbus Probe for Tivoli EIF.
2. Probe inserts the events in the alerts.status table of the object server after processing according to its rules file.
3. Tivoli Netcool/Impact/OMNIbus Event Reader service retrieves these new inserted events and map them according to Table 16-8.
Table 16-8 Mapping of events
|
Situation Name
|
Alert Group
|
Policy Name
|
|
NT_Process_CPU_Critical
|
ITM_NT_Process
|
TSRM_Incident
|
|
ITSM_WASDBConPoolUseMax
|
ITM_DB_Connection_Pools
|
CCMDB_RFC
|
|
ITSM_WASAvgHeapSizeAfterGC
|
ITM_Garbage_Collection_Analysis
|
TPM_Workflow
|
4. After mapping process, Tivoli Netcool/Impact Event Processor service runs the mapped policies and returns events back to the Tivoli Netcool/OMNIbus Object Server.
The operator switches to the Active Event List view and then observes that open events are automatically acknowledged after a while, as shown in Figure 16-49.
Figure 16-49 Processed Events in Tivoli Netcool/OMNIbus
The background events are as follows:
•First event triggers the incident ticket 1725. Most of the ticket fields are filled by data that is gathered from CCMDB as shown in Figure 16-50.
Figure 16-50 Automatic Incident Ticket
•Second event is acknowledged without action because TI0003-SYS3 system is in the maintenance window at the time that event occurs.
•Third event triggers the RFC C1101. Scheduled escalation runs the response plan actions and these actions populate RFC with predefined data. In the end, RFC 1101 is created, as shown in Figure 16-51.
Figure 16-51 Automatic Request for Change
•Fourth event triggers the Tivoli Provisioning Manager workflow. Tivoli Netcool/Impact policy calls the workflow and then waits for one minute to gather the workflow status. If it is successfully completed, event is acknowledged.
The operator switches back to the Situation Event List in Tivoli Enterprise Portal and then observes that situations are acknowledged, as shown in Figure 16-52.
Figure 16-52 Acknowledged Situations in Tivoli Enterprise Portal
16.7 Summary
Figure 16-53 shows the quick summary of this integration.
Figure 16-53 Quick summary
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.