Tivoli Service Automation Manager and Cloud Computing
This chapter describes how various Tivoli products can be integrated with Tivoli Service Automation Manager to support the delivery of Cloud Computing solutions.
This chapter contains the following topics:
12.1 Cloud Computing overview
The automation of service delivery in Cloud Computing requires that several capabilities be integrated. In a Cloud environment, each layer of the infrastructure may be virtualized (for example the core infrastructure, the runtime platform, or the software used to run any actual business services). As a result, Cloud service providers must be able to trace observed symptoms as they affect hosted applications to their actual causes and trigger the appropriate remediation based on contracted levels of service.
Automated remediation, based not only on the triggering event but also on contracted service levels, is a core differentiator between Cloud Computing and traditional models for Event Management. When the performance of some service component is degraded, the effect on the hosted application must be evaluated against the customer’s entitlements, which might vary depending on the level of service for which the customer has paid. A decline in performance of the overall application might appear severe in absolute terms, but might not be sufficiently severe that it exceeds the contracted service-level agreement (SLA) between the provider and the customer. An integrated solution that combines service performance metrics, tracing of events to their effects on hosted applications, and automated remediation based on defined service levels is a key component of Cloud Computing services delivery.
We divide the discussion into the following sections:
•Setup and prerequisites for the scenario, which lists and describes the products used for the implementation and gives pointers to installation instructions for each. The base installation of the products that are used is beyond the scope of this publication. See 12.4, “Scenario overview” on page 327.
•Defining a service using Tivoli Service Automation Manager, with which service administrators can create service definitions and the execution flows that are required for automated delivery of each service and service level. See 12.5, “Creating the service definition” on page 328.
•Measuring the health of the hosted application or business service using IBM event management and monitoring tools, which includes determining the service components to monitor, configuring the monitors, and ensuring that detected events are correctly correlated with affected services. See 12.6, “Monitoring the business service” on page 351.
•Creation and activation of automated remediation actions to ensure that contracted service levels are maintained. See 12.7, “Triggering automated service delivery” on page 369.
12.2 Products involved
The products involved in this scenario are as follows:
•IBM Tivoli Composite Application Manager for Transactions 7.2.0.1
•IBM Tivoli Monitoring V6.2.2 FP2
•IBM Tivoli Netcool/OMNIbus V7.2.1
•IBM Tivoli Provisioning Manager V7.1.1 (bundled with Tivoli Service Automation Manager)
•IBM Tivoli Service Automation Manager V7.2 FP3
The middleware products used in this scenario, which all implement Application Response Measurement (ARM), are as follows:
•WebSphere Application Server
•IBM HTTP Server with the WebSphere plug-in (ARM is implemented by the plug-in)
•DB2 Enterprise Server Edition
We describe how each of these tools can be integrated within the context of Cloud Computing. We also discuss the tool-specific customizations to enable the automation detection, tracing, and remediation of Service-Affecting Events (SAE).
 
Additional integration with IBM Tivoli Usage and Accounting Manager: Another product that you can integrate in this scenario is IBM Tivoli Usage and Accounting Manager. This integration can provide service usage reporting and enable accurate billing. An example of this for Energy Management is discussed in Chapter 4, “Managing business service with energy and environment” on page 63.
12.3 Benefits
The scenario has the following benefits:
•Better response time to resolve a performance issue
•Provisioning new virtual servers without any human interaction based on defined policies
12.4 Scenario overview
This scenario requires that certain products already be installed and configured. The prerequisites are as follows:
•An instance of Tivoli Service Automation Manager
•Integrated monitoring and event management using IBM Tivoli Monitoring and Tivoli Netcool/OMNIbus
•A web-based business service to monitor. Although this scenario could apply to non-web-based applications by changing the selection of monitoring agents used and their configurations, the use case we demonstrate is that of a web-based business service hosted in a cloud. We use the WebSphere Application Server benchmarking application Trade, which is a full J2EE application encompassing multiple application tiers (web/UI, business logic, persistence) and components, and provides a fuller demonstration of the scenario’s applicability to real-world usage.
Because of the selection of IBM Tivoli Composite Application Manager for Transactions, an important aspect is that the application (or the middleware components used to host it) implement ARM, which is an open standard for the generation and collection of transaction processing times. The standard includes APIs for both C and Java and is published by the Open Group. It is located at the following address:
 
Important: The REST API that is used to integrate Tivoli Netcool/OMNIbus and Tivoli Service Automation Manager is not supported in Tivoli Service Automation Manager. A REST API is supported in Tivoli Service Automation Manager 7.2.1, but because at the time of writing this book Tivoli Service Automation Manager 7.2.1 was not available, we used Tivoli Service Automation Manager 7.2 in this integration scenario.
To implement this scenario in an officially supported way, use Tivoli Service Automation Manager 7.2.1 and the REST API as documented for Tivoli Service Automation Manager 7.2.1. You can use the instructions in this chapter as a template for implementing your solution in Tivoli Service Automation Manager 7.2.1, but you must adapt the scripts and the overall solution for your specific environment and for Tivoli Service Automation Manager 7.2.1. Implementing your own solution exactly as described here means you cannot migrate to Tivoli Service Automation Manager 7.2.1.
12.5 Creating the service definition
We start the scenario by describing how to create the service definition on Tivoli Service Automation Manager.
12.5.1 Using the Tivoli Service Automation Manager REST interface
Tivoli Service Automation Manager has several mechanisms to enable integration with external systems. One mechanism is the Web Service facility. This mechanism allows external systems to access the offering catalog by using a Representational State Transfer (REST) interface.
By using the REST interface, for example, you can access the offering catalog and submit a new catalog request, which can start a new provisioning or even take an action in a server.
To use the REST interface, you must define the object structures in the Integration Framework. However, Tivoli Service Automation Manager already provides a set of object structures that are used by the user interface. Be sure that you do not change these object structures, otherwise, the Tivoli Service Automation Manager user interface might stop work.
More details about the object structure are in Deployment Guide Series: Maximo Asset Management V7.1, SG24-7640.
Figure 12-1 on page 329 shows the Tivoli Service Automation Manager objects that are ready to use. To see the list of Tivoli Service Automation Manager objects, open the Object Structures application (click Go to → Integration → Object Structures) and filter for the following object structure:
PMZHBR1_*
Figure 12-1 Tivoli Service Automation Manager object structures
These Tivoli Service Automation Manager object structures are the interface that is used to perform the following tasks:
•Create and update requests.
•Query for data structures.
12.5.2 Understanding the request creation object
The object structure used to create or update a request is PMZHBR1_PMSCMRCREATE. The source objects for this object structure are shown in Figure 12-2.
Figure 12-2 Source Objects definition
Each of these objects has a relationship that is represented by the Parent Object column. The attributes for each of these objects can be located using the Database configuration Application (click Go To → System Configuration → Platform Configuration → Database Configuration). Figure 12-3 shows an example of attributes of the PMSCMR object.
Figure 12-3 List of attributes of the PMSCMR object
12.5.3 Obtaining the resource pool name
Before submitting a request for new provisioning, you need the available resource pool name. To obtain this information, use a web service. to see the list of available web services, open the Web Services Library application (click Go to → Integration → Web Services Library). Press Enter to show all available Web Services. See Figure 12-4.
Figure 12-4 List of available Web Services
The web service PMRDPBCAPI can be used to query the available resource pool. A method named pmrdpbcapigetAvailablePoolList returns information about each defined resource pool. See Figure 12-5 on page 331.
Figure 12-5 Method used to query the available resource pools
To access the information in the web service, a simple request XML statement is required (Example 12-1), and the response is in XML also (Example 12-2).
Example 12-1 Request XML
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:q0="http://www.ibm.com/maximo"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<q0:pmrdpbcapigetAvailablePoolList
creationDateTime="2010-06-10T14:56:42Z"
maximoVersion="7115"
messageID="193" />
</soapenv:Body>
</soapenv:Envelope>
Example 12-2 Response XML
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<pmrdpbcapigetAvailablePoolListResponse
creationDateTime="2010-06-10T10:57:11-05:00"
transLanguage="EN" baseLanguage="EN"
messageID="1276185431062621164"
xmlns="http://www.ibm.com/maximo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PMRDPBCPOOLSMboSet>
<PMRDPBCPOOLS>
<NAME>Xen Local Disk</NAME>
<ID>/cloud/rest/pools/0/</ID>
<PLATFORMTYPE>Xen</PLATFORMTYPE>
</PMRDPBCPOOLS>
<PMRDPBCPOOLS>
<NAME>System p LPAR</NAME>
<ID>/cloud/rest/pools/1/</ID>
<PLATFORMTYPE>LPAR</PLATFORMTYPE>
</PMRDPBCPOOLS>
<PMRDPBCPOOLS>
<NAME>VMware System x</NAME>
<ID>/cloud/rest/pools/3/</ID>
<PLATFORMTYPE>VMware</PLATFORMTYPE>
</PMRDPBCPOOLS>
</PMRDPBCPOOLSMboSet>
</pmrdpbcapigetAvailablePoolListResponse>
</soapenv:Body>
</soapenv:Envelope>
The resource pools available in the environment is shown between the following tags:
<PMRDPBCPOOLS> </PMRDPBCPOOLS>
The information required for the next step is the string in the <ID> tag.
12.5.4 Obtaining the images list
A REST-based method is used to obtain the list of images in a resource pool. To access the information, an HTTP GET method must be issued in the REST interface. Example 12-3 shown a URL of a REST interface.
 
Note: The URL is an example only and might change based on the specifics of your Tivoli Service Automation Manager environment.
Example 12-3 URL used to obtain the images list
https://itsam72.ral.ibm.com:9443/ilrest/rest/os/TPV01IMGLIBENTRYMSTR?_format=json&_compact=1
To access the REST interface, a user ID and password must be provided. The default user ID is maxadmin. The response for the URL is in json format. See Example 12-4.
Example 12-4 Images list
{
"QueryTPV01IMGLIBENTRYMSTRResponse": {
"rsStart": 0,
"rsCount": 1,
"rsTotal": 1,
"TPV01IMGLIBENTRYMSTRSet": {
"ILIMAGE": [
{
"COLLECTION": false,
"CONFIGSWAPSPACE": false,
"CREATED": "2010-06-10T05:30:01-04:00",
"CREATOR": "MAXADMIN",
"GUESTOSTYPE": "Unknown",
"HYPERVISOR": "VMware",
"IMAGEFORMAT": "None",
"IMAGEID": 1,
"IMAGELIBRARYID": 1,
"NAME": "LinuxTemplate",
"OWNER": "MAXADMIN",
"POOL_ID": "/cloud/rest/pools/3/",
"REPOSITORYID": 1,
"REPOSITORYNAME": "NFS Repository",
"REPOSITORYTYPE": "NFS",
"SOFTWARESTACKID": 9487,
"STATE": "Created",
"TPIMAGEID": 9489,
"TYPE": "Master",
"UPDATED": "2010-06-10T05:30:01-04:00",
"UPDATER": "MAXADMIN",
"VERSION": "1",
"VIRTUALSERVERTEMPLATEID": 9414,
"VIRTUALSERVERTEMPLATEMINID": 9410,
"TPIMAGE": [
{
"ID": 9489,
"IMAGE_TYPE_ID": 1,
"NAME": "LinuxTemplate"
}
],
"TPSOFTWARESTACK": [
{
"ID": 9487,
"NAME": "LinuxTemplate"
}
],
"TPVIRTUALSERVERTEMPLATE": [
{
"ID": 9410,
"TPRESOURCEREQUIREMENT": [
{
"HOW_MANY": 9,
"NAME": "Minimum Disk Space",
"RESOURCE_SIZE": 9.0,
"RESOURCE_TYPE_ID": 2
},
{
"HOW_MANY": 102,
"NAME": "Minimum Memory",
"RESOURCE_SIZE": 102.0,
"RESOURCE_TYPE_ID": 6
},
{
"HOW_MANY": 1,
"NAME": "Minimum CPU",
"RESOURCE_SIZE": 1.0,
"RESOURCE_TYPE_ID": 3
}
]
},
{
"ID": 9414,
"TPRESOURCEREQUIREMENT": [
{
"HOW_MANY": 10,
"NAME": "Recommended Disk Space",
"RESOURCE_SIZE": 10.0,
"RESOURCE_TYPE_ID": 2
},
{
"HOW_MANY": 102,
"NAME": "Recommended Memory",
"RESOURCE_SIZE": 102.0,
"RESOURCE_TYPE_ID": 6
},
{
"HOW_MANY": 1,
"NAME": "Recommended CPU",
"RESOURCE_SIZE": 10.0,
"RESOURCE_TYPE_ID": 3
}
]
}
],
"ILIMAGE": [
]
}
]
}
}
}
12.5.5 Creating a new catalog request
A catalog request is the beginning of the process to provision a new server. The process consists of defining the Catalog Request with basic information and the item that represents the action of this request. The first step of the process creates a request in draft status and as a result, a list of unique identifiers that will be used in the second part of the process to update the request with all the necessary information to the action.
The process consists of three steps:
1. Create a catalog request (PMSCMR Object Instance).
2. Obtain the unique identifiers.
3. Update the request with required information.
The REST interface is used to create and update the request. The PMZHBR1_PMSCMRCREATE object structure is used to create the request. As mentioned before, the object instance PMSCMR is a source of this object. The method used to input the data into the REST interface must be HTTP POST.
Example 12-5 is a URL for the REST interface.
 
Note: The URL can change, based on the specifics of your Tivoli Service Automation Manager environment.
Example 12-5 URL to create the Catalog Request
https://itsam72.ral.ibm.com:9443/maxrest/rest/os/PMZHBR1_PMSCMRCREATE?_format=json&_compact=1&SITEID=PMSCRTP&ORGID=PMSCIBM&REQUESTEDBY=CLOUDADMIN&REQUESTEDFOR=&DESCRIPTION=Create%20Project%20with%20VMware%20Servers&ENDDATE=2010-06-22&PMSCMRLINE.1.CLASSSTRUCTUREID=8100210&PMSCMRLINE.1.ITEMNUM=PMRDP_0201A&PMSCMRLINE.1.ITEMSETID=PMSCS1&PMSCMRLINE.1.ORDERUNIT=EACH&PMSCMRLINE.1.LINETYPE=SRMOFF&PMSCMRLINE.1.QTY=1
The Table 12-1 shows the URL attributes that are used in this environment.
Table 12-1 Object Parameters
Attribute
Value
Comment
https://itsam72.ral.ibm.com:9443/maxrest/rest/os/PMZHBR1_PMSCMRCREATE
<hostname>
<IP>
The host name and IP of the Tivoli Service Automation Manager server
_format
json
This is the only acceptable value
_compact
1
This is the only acceptable value
SITEID
PMSCRTP
The site defined in the Tivoli Service Automation Manager. To see the site name, open the Organizations application (Go To → Administration → Organizations)
ORGID
PMSCIBM
The organization defined in the Tivoli Service Automation Manager. To see the organization name, open the Organizations application (Go To → Administration → Organizations)
REQUESTEDBY
CLOUDADMIN
The requester ID for this service. The requester must be defined in the environment.
REQUESTEDFOR
<offering description>
The offering description. Do not use spaces here.
ENDDATE
date
The end date for this project. (yyyy-mm-aa)
PMSCMRLINE.1.CLASSSTRUCTUREID
8100210
This value is optional. If you do not know the CLASSSTRUCTUREID, remove this attribute.
PMSCMRLINE.1.ITEMNUM
PMRDP_0201A
Represents the offering name in the catalog. To see all offerings, open the offerings application (Go To → Service Request Manager catalog → Service Inventory → Offerings
PMSCMRLINE.1.ITEMSETID
PMSCS1
Item Set defined for the offering.
MSCMRLINE.1.ORDERUNIT
EACH
Order unit by which the offering is requested.
PMSCMRLINE.1.LINETYPE
SRMOFF
Line type for the offering. The only acceptable value is SRMOFF.
PMSCMRLINE.1.QTY
1
Number of requests
After posting the HTTP, the return is similar to Example 12-6.
Example 12-6 Catalog request response, in json format
{
"CreatePMZHBR1_PMSCMRCREATEResponse": {
"rsStart": 0,
"rsCount": 1,
"rsTotal": 1,
"PMZHBR1_PMSCMRCREATESet": {
"PMSCMR": {
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:27-04:00",
"DESCRIPTION": "Start Server vm009042171039",
"ENTERBY": "MAXADMIN",
"ENTERDATE": "2010-06-24T00:04:28-04:00",
"HISTORYFLAG": false,
"MRDATE": "2010-06-24T00:04:28-04:00",
"MRID": 69,
"MRNUM": "1093",
"MRSTATUSSEQ": 240,
"ORGID": "PMSCIBM",
"PMSCSDSCMAPID": 69,
"PRIORITY": 1,
"REQUESTEDBY": "PMRDPCAUSR",
"SITEID": "PMSCRTP",
"STATUS": "DRAFT",
"STATUSDATE": "2010-06-24T00:04:28-04:00",
"TOTALCOST": 0.0,
"TYPE": "STANDARD",
"PMSCMRLINE": [
{
"CHARGESTORE": false,
"CLASSIFICATIONID": "PMRDP_SR_VS_MTG \ PMRDP_SR_CREATE_PROJECT_VMWARE_SERVER",
"CLASSSTRUCTUREID": "8100210",
"COMMODITY": "VSERVER",
"COMMODITYGROUP": "SRVAUTOM",
"COMPLETE": false,
"CURRENCYCODE": "USD",
"DESCRIPTION": "Create Project with VMware Servers",
"DIRECTREQ": true,
"ENTEREDASTASK": false,
"EXCHANGERATE": 1.0,
"INSPECTIONREQUIRED": true,
"ISDISTRIBUTED": false,
"ITEMNUM": "PMRDP_0201A",
"ITEMSETID": "PMSCS1",
"LINECOST": 0.0,
"LINECOST1": 0.0,
"LINETYPE": "SRMOFF",
"MKTPLCITEM": false,
"MRLINEID": 68,
"MRLINENUM": 1,
"ORDERUNIT": "EACH",
"ORGID": "PMSCIBM",
"PARTIALISSUE": true,
"QTY": 1.0,
"UNITCOST": 0.0,
"PDSPEC": [
{
"ASSETATTRID": "PMRDPCLCPR_DESCRIPTION",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 925,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 7,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 376,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCPR_PERSONGROUP",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 926,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 18,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 388,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCPR_PROJECTACCOUNT",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 927,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 1,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 369,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCPR_PROJECTID",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 928,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 6,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 375,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCPR_PROJECTNAME",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 929,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 5,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 374,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCPR_SERVERQTY",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 930,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 8,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 377,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ALNVALUE": "RDPVS",
"ASSETATTRID": "PMRDPCLCPR_SERVICEDEFINITIONNUM",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 931,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 3,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 372,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCPR_SERVICEDEFINITIONREVISION",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 932,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 2,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"NUMVALUE": 2.0,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 371,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCPR_SERVICEINSTANCEID",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 933,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 1,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 370,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCVS_MEMORY",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 934,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 9,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"MEASUREUNITID": "MBYTE",
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 378,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCVS_NUMBER_CPUS",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 935,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 10,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 379,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCVS_NUMBER_PCPUS",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 936,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 11,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 380,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCVS_RESGRPNAME",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 937,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 17,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 386,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCVS_RESGRPNUM",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 938,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 16,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 385,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCVS_STORAGE_SIZE",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 939,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 12,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 381,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLCVS_SWAP_SIZE",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 940,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 14,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 383,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ALNVALUE": "VMware",
"ASSETATTRID": "PMRDPCLCVS_TYPE",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 941,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 19,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 389,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLSWS_IMAGEID",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 942,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 13,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 382,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLSWS_MONITORING",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 943,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 15,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 384,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ASSETATTRID": "PMRDPCLSWS_SWIDS",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 944,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 17,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 387,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ALNVALUE": "CANPROJECT",
"ASSETATTRID": "PMRDPCLVSRV_DELETE_MPNUM",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 945,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 21,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 391,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ALNVALUE": "NEWPROJECT",
"ASSETATTRID": "PMRDPCLVSRV_MPNUM",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:28-04:00",
"CLASSSPECID": 946,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 4,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 373,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
},
{
"ALNVALUE": "NOTIFYPENDINGDELETEPR",
"ASSETATTRID": "PMRDPCLVSRV_NOTIFY_MPNUM",
"CHANGEBY": "MAXADMIN",
"CHANGEDATE": "2010-06-24T00:04:29-04:00",
"CLASSSPECID": 947,
"CLASSSTRUCTUREID": "8100210",
"DISPLAYSEQUENCE": 20,
"ITEMNUM": "PMRDP_0201A",
"MANDATORY": false,
"ORGID": "PMSCIBM",
"PDOWNERID": 69,
"PDSPECID": 390,
"REFOBJECTID": 68,
"REFOBJECTLINENUM": 1,
"REFOBJECTNAME": "PMSCMRLINE"
}
]
}
]
}
}
}
}
All these parameters represent the definitions of the request. You can see the request in the Maximo console as draft status by opening the View Catalog Requests application (Go To → Service Request Manager Catalog → View Catalog Requests). Press Enter to list all the requests. See Figure 12-6.
Figure 12-6 List of Catalog requests
By opening the request, you see the details of your request (Figure 12-7) and the items added (Figure 12-8).
Figure 12-7 Details of the request
Figure 12-8 Items added in the request
The items represent the offering of the request. Each offering has the required parameters that must be provided before changing the status of the request.
Click the item to see the details, as shown in Figure 12-9.
Figure 12-9 Required parameters for the offering
12.5.6 Updating the request with the required information
The request now must receive the attributes to provision a new virtual machine. The process to update the request is the same as to create it. However, for now, you must input all the attributes in the REST interface.
The URL in Example 12-7 on page 346 can be used to update the request with all the attributes. All attributes between the opening and closing angle brackets (< >) in the example must be changed for the correspondent value. The information about each attribute is in Table 12-2 on page 347.
 
Note: The URL is an example only and can change based on the specifics of your Tivoli Service Automation Manager environment.
Example 12-7 Updating the request with the required information
https://itsam72.ral.ibm.com:9443/maxrest/rest/os/PMZHBR1_PMSCMRCREATE/69?_format=json&MRID=69&STATUS=WAPPR&PMSCMRLINE.1.MRLINEID=68&PMSCMRLINE.1.COMMODITY=VSERVER&PMSCMRLINE.1.COMMODITYGROUP=SRVAUTOM&PMSCMRLINE.1.DESCRIPTION=Create%20Project%20with%20VMware%20Servers&PMSCMRLINE.1.PDSPEC.1.ALNVALUE=Request%20using%20REST%20API&PMSCMRLINE.1.PDSPEC.1.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.1.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.1.ASSETATTRID=PMRDPCLCPR_DESCRIPTION&PMSCMRLINE.1.PDSPEC.1.SECTION=&PMSCMRLINE.1.PDSPEC.1.PDSPECID=4375&PMSCMRLINE.1.PDSPEC.2.ALNVALUE=ITSO&PMSCMRLINE.1.PDSPEC.2.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.2.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.2.ASSETATTRID=PMRDPCLCPR_PERSONGROUP&PMSCMRLINE.1.PDSPEC.2.SECTION=&PMSCMRLINE.1.PDSPEC.2.PDSPECID=4387&PMSCMRLINE.1.PDSPEC.3.ALNVALUE=ITSOProject&PMSCMRLINE.1.PDSPEC.3.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.3.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.3.ASSETATTRID=PMRDPCLCPR_PROJECTNAME&PMSCMRLINE.1.PDSPEC.3.SECTION=&PMSCMRLINE.1.PDSPEC.3.PDSPECID=4373&PMSCMRLINE.1.PDSPEC.4.NUMVALUE=1&PMSCMRLINE.1.PDSPEC.4.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.4.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.4.ASSETATTRID=PMRDPCLCPR_SERVERQTY&PMSCMRLINE.1.PDSPEC.4.SECTION=&PMSCMRLINE.1.PDSPEC.4.PDSPECID=4376&PMSCMRLINE.1.PDSPEC.5.NUMVALUE=1024&PMSCMRLINE.1.PDSPEC.5.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.5.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.5.ASSETATTRID=PMRDPCLCVS_MEMORY&PMSCMRLINE.1.PDSPEC.5.SECTION=&PMSCMRLINE.1.PDSPEC.5.PDSPECID=4377&PMSCMRLINE.1.PDSPEC.6.NUMVALUE=1&PMSCMRLINE.1.PDSPEC.6.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.6.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.6.ASSETATTRID=PMRDPCLCVS_NUMBER_CPUS&PMSCMRLINE.1.PDSPEC.6.SECTION=&PMSCMRLINE.1.PDSPEC.6.PDSPECID=4378&PMSCMRLINE.1.PDSPEC.7.NUMVALUE=5&PMSCMRLINE.1.PDSPEC.7.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.7.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.7.ASSETATTRID=PMRDPCLCVS_NUMBER_PCPUS&PMSCMRLINE.1.PDSPEC.7.SECTION=&PMSCMRLINE.1.PDSPEC.7.PDSPECID=4379&PMSCMRLINE.1.PDSPEC.8.ALNVALUE=%2Fcloud%2Frest%2Fpools%2F3%2F&PMSCMRLINE.1.PDSPEC.8.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.8.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.8.ASSETATTRID=PMRDPCLCVS_RESGRPNUM&PMSCMRLINE.1.PDSPEC.8.SECTION=&PMSCMRLINE.1.PDSPEC.8.PDSPECID=4384&PMSCMRLINE.1.PDSPEC.9.NUMVALUE=5&PMSCMRLINE.1.PDSPEC.9.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.9.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.9.ASSETATTRID=PMRDPCLCVS_STORAGE_SIZE&PMSCMRLINE.1.PDSPEC.9.SECTION=&PMSCMRLINE.1.PDSPEC.9.PDSPECID=4380&PMSCMRLINE.1.PDSPEC.10.NUMVALUE=1.000&PMSCMRLINE.1.PDSPEC.10.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.10.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.10.ASSETATTRID=PMRDPCLCVS_SWAP_SIZE&PMSCMRLINE.1.PDSPEC.10.SECTION=&PMSCMRLINE.1.PDSPEC.10.PDSPECID=4382&PMSCMRLINE.1.PDSPEC.11.NUMVALUE=1&PMSCMRLINE.1.PDSPEC.11.REFOBJECTID=260&PMSCMRLINE.1.PDSPEC.11.REFOBJECTNAME=PMSCMRLINE&PMSCMRLINE.1.PDSPEC.11.ASSETATTRID=PMRDPCLSWS_IMAGEID&PMSCMRLINE.1.PDSPEC.11.SECTION=&PMSCMRLINE.1.PDSPEC.11.PDSPECID=4381
Table 12-2 information about the attributes
Attribute
Value
Comment
https://itsam72.ral.ibm.com:9443/maxrest/rest/os/PMZHBR1_PMSCMRCREATE/69?
Host name, IP address, and MRID
MRID is the PMSCMR unique identifier. In the Example 12-6 on page 336, the MRID is 69.
_json
json
-
MRID
MRID
The PMSCMR unique identifier
STATUS
WAPPR
This is the status Waiting on Approval. This status will start the process workflow.
PMSCMRLINE.1.MRLINEID
PMSCMRLINE.1.MRLINEID
The PMSCMRLINE unique identifier
PMSCMRLINE.1.COMMODITY
VSERVER
The value defined in the Tivoli Service Automation Manager
PMSCMRLINE.1.COMMODITYGROUP
SRVAUTOM
The value defined in the Tivoli Service Automation Manager
PMSCMRLINE.1.DESCRIPTION
description
The description of the project
Note: The following attributes represent each object inside the array PDSPEC in the Example 12-6 on page 336. Objects inside array PDSPEC is represented by brackets. To update the objects, change the signal % in the following attributes to the sequential number. The quantity of objects can vary for each offering.
PMSCMRLINE.1.PDSPEC.%.ALNVALUE
PMSCMRLINE.1.PDSPEC.%.NUMVALUE
ALNVALUE - String value
NUMVALUE - Numeric value
The value to be set for the attribute
PMSCMRLINE.1.PDSPEC.%.REFOBJECTID
The REFORBJECTID of the object
-
PMSCMRLINE.1.PDSPEC.%.REFOBJECTNAME
PMSCMRLINE
The object in reference. This is the only acceptable value
PMSCMRLINE.1.PDSPEC.%.ASSETATTRID
The name of the attribute
The list of the attributes can be found in the HTTP response.
PMSCMRLINE.1.PDSPEC.%.SECTION
Usually null
The section for a group of attributes. This is usually null.
PMSCMRLINE.1.PDSPEC.$.PDSPECID
unique value
-
Using the HTTP response from Example 12-6 on page 336, the parameters are listed in Example 12-8.
Example 12-8 HTTP response
MRID=69
STATUS=WAPPR
PMSCMRLINE.1.MRLINEID=68
PMSCMRLINE.1.COMMODITY=VSERVER
PMSCMRLINE.1.COMMODITYGROUP=SRVAUTOM
PMSCMRLINE.1.DESCRIPTION=Create%20Project%20with%20VMware%20Servers
PMSCMRLINE.1.PDSPEC.1.ALNVALUE=Request%20using%20REST%20API
PMSCMRLINE.1.PDSPEC.1.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.1.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.1.ASSETATTRID=PMRDPCLCPR_DESCRIPTION
PMSCMRLINE.1.PDSPEC.1.SECTION=
PMSCMRLINE.1.PDSPEC.1.PDSPECID=376
PMSCMRLINE.1.PDSPEC.2.ALNVALUE=ITSO
PMSCMRLINE.1.PDSPEC.2.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.2.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.2.ASSETATTRID=PMRDPCLCPR_PERSONGROUP
PMSCMRLINE.1.PDSPEC.2.SECTION=
PMSCMRLINE.1.PDSPEC.2.PDSPECID=388
PMSCMRLINE.1.PDSPEC.3.ALNVALUE=ITSOProject
PMSCMRLINE.1.PDSPEC.3.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.3.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.3.ASSETATTRID=PMRDPCLCPR_PROJECTNAME
PMSCMRLINE.1.PDSPEC.3.SECTION=
PMSCMRLINE.1.PDSPEC.3.PDSPECID=374
PMSCMRLINE.1.PDSPEC.4.NUMVALUE=1
PMSCMRLINE.1.PDSPEC.4.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.4.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.4.ASSETATTRID=PMRDPCLCPR_SERVERQTY
PMSCMRLINE.1.PDSPEC.4.SECTION=
PMSCMRLINE.1.PDSPEC.4.PDSPECID=377
PMSCMRLINE.1.PDSPEC.5.NUMVALUE=1024
PMSCMRLINE.1.PDSPEC.5.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.5.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.5.ASSETATTRID=PMRDPCLCVS_MEMORY
PMSCMRLINE.1.PDSPEC.5.SECTION=
PMSCMRLINE.1.PDSPEC.5.PDSPECID=378
PMSCMRLINE.1.PDSPEC.6.NUMVALUE=1
PMSCMRLINE.1.PDSPEC.6.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.6.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.6.ASSETATTRID=PMRDPCLCVS_NUMBER_CPUS
PMSCMRLINE.1.PDSPEC.6.SECTION=
PMSCMRLINE.1.PDSPEC.6.PDSPECID=379
PMSCMRLINE.1.PDSPEC.7.NUMVALUE=5
PMSCMRLINE.1.PDSPEC.7.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.7.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.7.ASSETATTRID=PMRDPCLCVS_NUMBER_PCPUS
PMSCMRLINE.1.PDSPEC.7.SECTION=
PMSCMRLINE.1.PDSPEC.7.PDSPECID=380
PMSCMRLINE.1.PDSPEC.8.ALNVALUE=%2Fcloud%2Frest%2Fpools%2F3%2F
PMSCMRLINE.1.PDSPEC.8.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.8.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.8.ASSETATTRID=PMRDPCLCVS_RESGRPNUM
PMSCMRLINE.1.PDSPEC.8.SECTION=
PMSCMRLINE.1.PDSPEC.8.PDSPECID=385
PMSCMRLINE.1.PDSPEC.9.NUMVALUE=5
PMSCMRLINE.1.PDSPEC.9.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.9.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.9.ASSETATTRID=PMRDPCLCVS_STORAGE_SIZE
PMSCMRLINE.1.PDSPEC.9.SECTION=
PMSCMRLINE.1.PDSPEC.9.PDSPECID=381
PMSCMRLINE.1.PDSPEC.10.NUMVALUE=1.000
PMSCMRLINE.1.PDSPEC.10.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.10.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.10.ASSETATTRID=PMRDPCLCVS_SWAP_SIZE
PMSCMRLINE.1.PDSPEC.10.SECTION=
PMSCMRLINE.1.PDSPEC.10.PDSPECID=383
PMSCMRLINE.1.PDSPEC.11.NUMVALUE=1
PMSCMRLINE.1.PDSPEC.11.REFOBJECTID=68
PMSCMRLINE.1.PDSPEC.11.REFOBJECTNAME=PMSCMRLINE
PMSCMRLINE.1.PDSPEC.11.ASSETATTRID=PMRDPCLSWS_IMAGEID
PMSCMRLINE.1.PDSPEC.11.SECTION=
PMSCMRLINE.1.PDSPEC.11.PDSPECID=382
 
Note: You do not need to use all the ASSETATTRID from the offerings.
After the HTTP POST is performed, the return is a JSON response that can be used as a confirmation that the REQUEST has been updated.
To check the status of the request, open the View Catalog Requests application (Go To → Service Request Manager Catalog → View Catalog Requests), as shown in Figure 12-10.
Figure 12-10 List of Catalog Requests
Open the Catalog Request and verify whether the parameters were updated correctly. See Figure 12-11 on page 350.
Figure 12-11 The list of parameters updated
After approval of this request, a service request is created to perform the transaction. To see the request, open the Service Requests application (Go To → Service Desk → Service Requests), as shown in Figure 12-12:
Figure 12-12 Example of Service Request in progress
When provisioning is finished, the service request status is changed to Resolved.
12.6 Monitoring the business service
Event Management and Monitoring (EMM) includes many types of monitoring such as measuring of both IT and non-IT infrastructure health, detecting component outages or degradations, and monitoring IT resource utilization. In a Cloud Computing environment, however, you must be capable of monitoring both the underlying IT infrastructure and the business services and applications that run on top of them, particularly with regards to the quality of service delivery.
12.6.1 Selecting monitoring agents
Because we are concerned primarily with service delivery and specifically with ensuring that contracted service levels are achieved, this scenario uses IBM Tivoli Composite Application Manager for Transactions as the primary monitoring component, in conjunction with IBM Tivoli Monitoring. IBM Tivoli Composite Application Manager for Transactions includes three types of monitoring capabilities:
•Internet Service Monitoring, which measures the performance and availability of various network services against defined service level parameters
•Response Time, which provides automated measurements of HTTP and HTTPS service response time
•Transaction Tracking, which tracks user transactions through a composite application and measures the time each application component spends handling the transaction
For this scenario, we deployed the Internet Service Monitoring and Transaction Tracking components of IBM Tivoli Composite Application Manager for Transactions. Internet Service Monitoring executes HTTP and other service requests, and measures performance and availability against user-defined service levels; Transaction Tracking traces each transaction through the business service and identifies any bottlenecks which may be impacting service levels.
12.6.2 Configuring Internet Service Monitoring
To configure Internet Service Monitoring to probe and measure service availability and performance, you must use the Tivoli Enterprise Portal component of IBM Tivoli Monitoring:
1. In the Tivoli Enterprise Portal Client, click ISM Configuration icon. See Figure 12-13.
Figure 12-13 Accessing the ISM Configuration in the Tivoli Enterprise Portal
2. In the dialog box, click the Create Profile icon at the top left to create a new profile. See Figure 12-14.
Figure 12-14 Creating a new Internet Service Monitoring profile
3. In the dialog window that opens, select a name for your application. This application name refers to the name of the monitored business service; you enter it at several points during component configuration.
 
Important: Be sure to use the same name for the application throughout the scenario.
For our scenario, we enter TradeApplication as our application name.
After creating the profile, create monitoring elements. Each element represents an instance of a service that must be monitored and includes details about the application protocol to use, timeout, poll interval, and service level thresholds, among other parameters. The configurable parameters vary according to the type of monitoring element being created.
To create an element, perform the following steps:
1. Select your profile by clicking it.
2. Select the type of monitor from the menu in the “Add monitor type to profile” pane.
3. Click Add, as shown in Figure 12-15.
Figure 12-15 Adding a new HTTP monitoring element to the ISM profile
Configuring an HTTP monitoring element
The most basic way of monitoring a web application is to use an HTTP (or HTTPS, if supported by the application) monitoring element. Figure 12-16 shows the selection of HTTP as the monitoring element type.
This section details how to configure the element in more detail.
After adding a new HTTP element, a panel shows the list of all HTTP elements within the same profile, including any that already exist, at the top. If you click an element to select it, the element details are at the bottom. See Figure 12-16.
Figure 12-16 HTTP Element Configuration for Internet Service Monitoring
Although we describe the most commonly used parameters for an HTTP monitor element, other less commonly used parameters and parameters for other types of Internet Service Monitoring elements are not covered. For those, see the IBM Tivoli Composite Application Manager for Transactions User’s Guide, which provides a full reference for all monitor attributes:
To create an HTTP element, enter information (from left to right) in the columns at the top of the configuration window: the host name or IP address of the HTTP server (which can be a cluster address, such as a Virtual IP, also known as a VIP), the URI path of the page to be requested, and a short description. For the purposes of this scenario, we have made the description the same as the page URI path, which facilitates correlating events later. See Figure 12-17.
Figure 12-17 Basic configuration details for HTTP element
In the lower part of the pane are several tabs:
•Advanced, which has more detailed configuration parameters
•Parameters, which are the parameters to be passed in as part of the request, such as with a form
•Proxy Details, in case the monitored service must be accessed through a proxy server
•Regexp, which you use to check returned content for the presence (or absence) of one or more regular expressions
•SLC, in which you configure the service level classification parameters. These are used to assign a service level to the monitored service based on aspects such as response time, protocol-specific return codes, and the presence or absence of particular regular expressions
We describe the configuration of the Advanced and SLC tabs only at this point. For many basic HTTP probe configurations, you may not need to change any values in the Advanced tab at all from the defaults. Figure 12-18 shows that we have modified only the timeout and poll values.
Figure 12-18 Advanced configuration details for HTTP element
The timeout parameter controls how long the probe will wait for a response from the server before giving up; the poll parameter controls the interval between requests. Both values are in seconds. The value for poll obviously is greater than that for timeout.
Configuring service level classification
In many ways, the SLC tab is the most important one for any Internet Service Monitoring element, because it is in this tab that you configure the thresholds that are used to determine the service level classification assigned to each request cycle. The available classifications are GOOD, MARGINAL, and FAILED in decreasing order of service quality. Therefore, Internet Service Monitoring users must be careful about what values they select and should revisit monitor configurations periodically to be sure they reflect actual target service levels.
The Internet Service Monitoring configuration divides service level classification into condition groups, which are themselves divided into individual conditions. Each condition group is associated with a service level classification; the conditions within the group are combined together (using AND) for purposes of evaluation, and if all evaluate to true, the associated classification is assigned to the monitored service.
For an HTTP monitoring element, three condition groups are configured by default, although you can add or delete groups as needed. The first group checks HTTP response codes; the second and third groups both check the total time to complete the request, including the time to receive the full response from the server. Most users need a minimum to modify the time thresholds for the second and third groups. The second group, if true, results in a service level classification of FAILED; the third results in a classification of MARGINAL. Figure 12-19 shows the values we used for our element.
Figure 12-19 Service level classification configuration details for HTTP element
The configuration shown in Figure 12-19 on page 355 results in the following evaluation flow:
1. If the HTTP status code is not one of 200, 301, or 302, then classify the service level as FAILED and stop the request.
2. If the total time to send the request and receive the full response (including time for nameservice lookups and handshaking, if applicable) is greater than 0.2 seconds, classify the service level as FAILED and stop.
3. If the total time is greater than 0.1 seconds, classify the service level as MARGINAL and stop.
4. If none of the preceding three conditions (technically condition groups in Internet Service Monitoring) applies, then classify the service level as GOOD.
Distributing the profile to monitoring agents
With most Tivoli Enterprise Monitoring Agents, you only need to distribute situations to them, because situations determine the monitoring thresholds, which trigger the raising of events. But when deploying BM Tivoli Composite Application Manager for Transactions, you must also distribute monitoring profiles which define the additional configuration details that are required to monitor your application correctly. For Internet Service Monitoring, you do this within the same configuration window that you used to create the profile and monitoring element.
You may distribute profiles in two ways using the ISM configuration window:
•Distribute a single profile to one or more deployed agents.
•Distribute one or more profiles to a single deployed agent.
The exact mechanics for the two ways are similar but not exactly identical. We demonstrate both methods for profile distribution.
To distribute a single profile to one or more agents, select the profile by clicking it in the profile list pane at the left. See Figure 12-20, which shows the distributing of a single profile to one or more deployed Internet Service Monitoring agents. To the right is the list from which you can select monitor element types to add; below that are two lists showing the agents that are available for profile distribution and those to which this particular profile has already been distributed.
Figure 12-20 Distributing single profile
In Figure 12-20 on page 356, we have already distributed our profile to a single agent, TI0003-sys9:IS. If we had additional Internet Service Monitoring agents deployed in our infrastructure to which we had not yet distributed this profile, they would appear in the list on the left under Available Systems. Simply select any agents to be targeted for distribution from the Available Systems list, then click the button containing the arrow pointing to the right to move those agents into the Deployed Systems list. After you click either OK or Apply, the profile is distributed to the agents selected.
To distribute one or more profiles to a single selected deployed agent, click the top-level Profiles node in the profile list on the left. At the right, agents that are deployed in your infrastructure are listed. Select the agent to which you want to distribute profiles. Figure 12-21 shows a list of those profiles (on the left) that are available for distribution; on the right is a list of those profiles that are already distributed to this particular agent.
Figure 12-21 Distribution of profiles to a selected Internet Service Monitoring agent
To deploy a profile to the selected agent, simply move it from the Available Profiles list to the Deployed Profiles list and click Apply.
Because distributed profiles are stored as XML files at the agents to which they have been deployed, this method is also useful if those files should become corrupted or deleted. If you select an agent from the list at the top of the window and then click Resync Agent, IBM Tivoli Monitoring will redeploy all profiles previously distributed to that agent, overwriting any locally stored profiles and restoring the agent to the specified configuration.
12.6.3 Configuring Transaction Tracking
The Transaction Tracking component of IBM Tivoli Composite Application Manager for Transactions enables the tracing of a service transaction through each tier of the composite application. Although Internet Service Monitoring can emulate the user experience and measure adherence to contracted service levels, Transaction Tracking enables you to identify how much time a transaction is being handled at each tier and thereby identify which component or inter-component communication may be responsible for any service degradation. Combined with Internet Service Monitoring, Transaction Tracking provides a powerful platform for the management of business services.
The steps are as follows:
1. To configure Transaction Tracking, you must create an application configuration and then specify the types of transactions that belong to the application. You then associate this application’s transactions with a distribution profile and distribute it to Transaction Collector agents. All of this configuration is done in the Application Management Configuration Editor, which you access by clicking Application Management Configuration Editor in the Tivoli Enterprise Portal toolbar, as shown in Figure 12-22.
Figure 12-22 Accessing the Application Management Configuration Editor
The Application Management Configuration Editor is installed as part of the Application Management Console, which is a subcomponent of both Transaction Tracking and Response Time. The editor, shown in Figure 12-23 on page 359, is similar to the one that is used to configure Internet Service Monitoring.
Figure 12-23 Application Management Configuration Editor window
On the left is a navigator tree, containing all configured applications. By default, applications are supplied, corresponding to each middleware application that Transaction Tracking is capable of monitoring. All transactions belonging to these included applications are associated with a distribution profile named Default.
Figure 12-24 shows the editor window with the Default profile selected on the left under the application IBM DB2 and All DB2 Subtransactions through ARM.
Figure 12-24 Editor window with the Default profile selected
2. On the right, you see that this particular profile is not distributed to any managed systems (agents). Click the Transactions tab for this profile to see the transactions that are associated with the profile. See Figure 12-25.
Figure 12-25 Transactions associated with Default profile
3. You can also see the profile configuration by selecting Profiles from the drop-down menu at the top of the navigator pane, and then selecting a profile. Note in Figure 12-25 that, although we have navigated to the profile Default under the application IBM DB2, this profile includes transactions from many other applications also. Any profile can contain transactions that are part of multiple applications. The distribution of a profile to a particular Transaction Collector means that the agent will collect those transactions matching those configured for the profile, and in certain cases, multiple applications may submit their transaction data through ARM to the same Transaction Collector agent.
4. To configure Transaction Tracking for our application, use the following steps:
a. Be sure that Applications is selected in the drop-down menu above the navigator.
b. Click the top-level Applications node in the navigator.
c. Click Create New Application. See Figure 12-26 on page 361.
Figure 12-26 Create New Application
In 12.6.2, “Configuring Internet Service Monitoring” on page 351, we first created a profile that we called TradeApplication. Be sure to use the same name for the application name in Transaction Tracking.
5. After creating your application, create the transactions belonging to that application. In the navigator, select your application, and then click Create, which is now the Create New Transaction button (Figure 12-27).
Figure 12-27 Create New Transaction
6. In the Create Transaction window that opens, enter the details for your new transaction, which include the application name (this is already be selected for you, but you may select a different application from the drop-down menu), the transaction name, a description (this is not required), the agent type (because we are not using Response Time, the only option is Transaction Tracking), and the transaction type.
Figure 12-28 shows the values we use for capturing transaction metrics from the WebSphere plug-in for IBM HTTP Server.
Figure 12-28 New transaction details for IBM HTTP Server transactions
7. After clicking OK to create the transaction, make sure your new transaction is selected in the navigator and then click the Filter tab in the pane on the right. In this pane, you configure the filter that is used to determine which transactions to collect and which not to collect. Keep in mind that most ARM-enabled middleware components send all transaction metrics to the Transaction Collector, even those that you do not need. Therefore, use your filter to capture those transactions that you really need. Capturing transactions that have unimportant measurements wastes resources in terms of both load on the monitoring infrastructure and space used to store historical transaction data in the Tivoli Data Warehouse.
The filters you apply for a given transaction can vary among monitored components and among applications. In our scenario, we are filtering based on the URI path of requests sent to IBM HTTP Server and handled by the WebSphere plug-in. As the Transaction Collector receives metrics, it must determine whether the transaction is being reported by the correct component and whether the transaction has the correct path. The next window shows how we configure this information for the trade application and IBM HTTP Server using the WebSphere plug-in. See Figure 12-29 on page 363.
Figure 12-29 Filter configuration for WebSphere plug-in transactions
8. The ApplicationName parameter is set to IBM Webserving Plugin, which is the value automatically inserted into the request metric information by the plug-in. Each ARM-enabled application inserts its own value, which can be used to identify transaction data as coming from that component. Because IBM Tivoli Composite Application Manager for Transactions includes a robust set of default transactions, you can browse these to get examples of how to capture transactions from a variety of middleware and application products.
Because we are gathering data from the WebSphere plugin, any requests to any URIs the plugin is configured to handle will be tracked and reported, but we only want data about those requests for the Trade application. We use the URI parameter with a value of /trade* to capture only transaction data pertaining to requests that have a path beginning with that string. On the right side, note that the Type is set to Include. It is also possible to use Exclude to filter out certain requests, but that is not useful in this particular case.
Although we do not describe details of the process here, you may also use the same URI filter when capturing request metrics from the application server itself, which in this scenario is WebSphere Application Server. In addition to the WebSphere Plugin URLs transaction, we configured several other transactions for TradeApplication, and Figure 12-30 shows the full list used in this scenario.
Figure 12-30 Transactions configured for TradeApplication
9. After creating the transaction and defining the filters, you must configure how the transaction data is reported by the Collector. Be sure that you can correctly identify transactions as belonging to the same composite application or business service and use the data to generate events that can be correlated. You configure the reporting individually for each transaction as you create it. After you have created your filters, click the Reporting tab and enter values for the following items:
 – Application name: Enter exactly the same name as you used when creating the application and the Internet Service Monitoring profile.
 – Transaction name: How you configure this parameter can vary greatly depending how you identify service requests for the given application. Be sure to examine the set of transactions that are included with the product for examples. For web services, however, a good default is to use the value $URI$ for both the web server and application server layer, because this value can be used to track the request most readily as it is handed off. We use this value for both WebSphere Plugin URLs and WebSphere URLs via ARM.
 – Server name: For this parameter, we use $Hostname$ for all of our transactions, which will be dynamically evaluated to the host name of the server that is reporting the transaction. This is probably a good default to use unless you have specific requirements otherwise. If you have a complex WebSphere topology, for example, with multiple application servers, you may need to include
 – Component name: This scenario uses the value $ApplicationName$ for all transactions other than WebSphere Plugin URLs, for which we use $ApplicationGroup$. Note that this value does not necessarily evaluate to the name of your application for most middleware components, it evaluates to the name of the middleware product, for example IBM DB2 Universal Database™. Again, in more complex environments, you may choose to use other properties to populate this or other fields to assist in transaction identification and tracking. For WebSphere Application Server, version 6.1, the list of available properties and their meanings are at the following address:
See the appropriate product documentation for your middleware components to see what other properties might be available for populating any of the other fields. Dynamic properties must always be enclosed in single dollar signs, for example:
$ApplicationName$
Figure 12-31 shows the settings configured for the WebSphere Plugin URLs transaction within TradeApplication.
Figure 12-31 Transaction reporting configuration for WebSphere Plugin URLs
 
Note: We have used ARM instrumentation for DB2, and WebSphere Application Server and IBM Tivoli Composite Application Manager for Transactions as the transaction monitoring solution in this scenario. Alternatively, you may use the IBM Tivoli Composite Application Manager for Application Diagnostics product as the monitoring solution. This product can be used for WebSphere monitoring and transaction tracking (including JDBC tracking which will cover DB2). See the IBM Tivoli Composite Application Manager for Application Diagnostics library for more information about this product:
Distributing the Transaction Tracking configuration
After creating your application and set of transactions, you must create a profile for distribution, associate the transactions with it, and then distribute the profile to deployed Transaction Collector agents:
1. Click Apply to save any changes you have made to the configuration, and then select Profiles from the drop-down menu above the navigator pane in the Application Management Configuration Editor. Click Create New Profile to create the new distribution profile, as shown in Figure 12-32.
Figure 12-32 Create new profile
2. Enter the profile details in Figure 12-33.
Figure 12-33 New profile details
 
Note: We use the same name for our profile as we used for the application. Doing so is not necessary, and in many production environments, it might not even be advisable. Although we do this in our scenario, in production, particularly where you might have multiple Transaction Collectors deployed and firewalls separating security zones, you might want several transactions distributed through profiles to some collectors and not to others. Keep in mind the requirements of your particular application deployment topology when designing your Transaction Tracking profiles.
3. After creating the profile, add transactions to it and then distribute the profile. To add transactions, select the profile in the navigator (this is done by default immediately after creating the profile) and then, in the pane to the right, click the Transactions tab. Click Add to open the Transaction Selection window, shown in Figure 12-34.
Figure 12-34 Add transaction to Transaction Tracking profile
4. As you can see in Figure 12-34, newly created profiles do not include any transactions. After clicking Add, the Transaction Selection window opens. Only those applications containing transactions not already added to the profile are displayed (if all the transactions in an application are already part of the profile, the application is not shown at all). Click the twisty next to the application containing the transactions to be added and then click one or more transactions. You can press Ctrl+Select and Shift+Select to select multiple transactions as in most other list selection applications.
Figure 12-35 on page 367 shows that we have selected all the transactions within TradeApplication to be added to our profile.
Figure 12-35 Transaction selection for addition to a profile
5. Click OK to add the selected transactions to your profile, and then distribute the profile. Click the Distribution tab to see a familiar pair of lists. See Figure 12-36.
Figure 12-36 Application Management Configuration Editor profile distribution
6. Select the targeted agents for distribution from the Available Managed Systems list and move them to the Assigned list by clicking the left arrow button. Click Apply or OK to complete your Transaction Tracking configuration (if you click Apply you still need to click OK to exit the Application Management Configuration Editor). If you click Apply and then return to the Transactions tab, you see that all your transactions are labelled as Started. You may stop or start collection of metrics for any or all associated transactions from this window.
 
Note: Be aware that the Started label can be deceptive; by default, a new profile and any associated transactions are both in a Started state (just as with newly created IBM Tivoli Monitoring situations), but until the profile has been distributed to agents through the window shown in Figure 12-36, the status for the transactions will show as Started* (the asterisk is a visual clue that the profile has not been distributed to any agents yet, and you still need to do that task).
Configuring monitored applications for ARM
The method to enable the collection of ARM metrics varies widely between applications and is outside the scope of this book. Configuration details for many of the more common applications and platforms are in the IBM Tivoli Composite Application Manager for Transactions documentation at:
You may have to perform one important step, however, particularly if you are using a distributed Transaction Collector deployment in which multiple applications must report their metrics to a single Transaction Collector. Each monitored application, whether or not it reports to a local or remote Transaction Collector, must have an instance of the Transaction Collector installed locally. This Transaction Collector may not be used to collect the metrics from reporting applications, but it is still required to serve as a profile distribution endpoint as shown in Figure 12-36 on page 367. The installation of the Transaction Collector also provides the ARM client libraries used by the monitored application and includes a configuration file, which can be used to specify a remote Transaction Collector agent for metrics reporting. This file is in the following location:
$CANDLE_HOME/tmaitm6/arm/armconfig.xml
In the path, $CANDLE_HOME is the root installation directory for IBM Tivoli Monitoring on the system. Update the file by adding the XML element (or modifying the existing element):
<ttconnectionstring>tcp:collector_hostname_or_address:collector_port</ttconnectionstring>
Note that collector_hostname_or_address is the host name or IP address of the remote Transaction Collector host and collector_port is the port on which the Transaction Collector is listening (5455 by default). The monitored application must be restarted after this file is updated. Full documentation about updating this file is at the following address:
12.7 Triggering automated service delivery
This section describes how to use the monitoring components to detect an impact to service delivery and trigger a remediation action by requesting a service instance from Tivoli Service Automation Manager.
12.7.1 Detecting a service event
Detecting events affecting service levels requires two steps, both pertaining to event-slot mappings to enable proper correlation in Tivoli Netcool/OMNIbus:
•Updating the Event Integration Facility configuration for existing situations in IBM Tivoli Monitoring
•Updating the Event Integration Facility probe rules files to incorporate mappings for IBM Tivoli Composite Application Manager for Transactions
Situation configuration
For this scenario, we use two situations, both of which are included with IBM Tivoli Composite Application Manager for Transactions. One situation checks for a service-level failure based on Internet Service Monitoring; the other checks for a transaction slowdown at a particular application tier. In real-world production usage, expect to use more complex configurations, perhaps requiring more situations, but those uses are still derived from the same basic model, which is detect a service-level failure and identify the component causing the failure.
In our scenario, which is meant to represent a software as a service (SaaS) cloud, we detect a service level failure for a web-based business service. then correlate that with a component-level failure with regards to configured response time thresholds; the correlation of the two events then triggers the service request to Tivoli Service Automation Manager. Although this scenario is relatively simple, it demonstrates a flow that can be used to maintain service levels through near-real-time automated remediation. In real-world usage, additional monitoring agents, such as those for operating systems or IBM Tivoli Composite Application Manager for Application Diagnostics, might also be used to detect issues with the underlying middleware or to detect events which could be used to identify and remediate more fine-grained capacity issues:
The steps are as follows:
1. Modify the event slot mappings for two situations, both of which are created when you install the application support for IBM Tivoli Composite Application Manager for Transactions:
a. Open the Situation Editor in the Tivoli Enterprise Portal,
b. Navigate to the situation Internet Service Monitoring → KIS_Element_SLA_Failed.
c. Click the EIF tab and be sure that the Forward Events to an EIF Receiver check box is selected.
d. Select the appropriate severity (we have used Critical) and EIF Receiver, as shown in Figure 12-37 on page 370.
Figure 12-37 Basic EIF configuration for situation
2. Click EIF Slot Customization. This next section assumes that you have used the tedgen utility to update your slot mapping XML file and configured your Tivoli Enterprise Portal Server to use the updated file. If you have not, the instructions for doing so are in the IBM Tivoli Monitoring documentation:
The instructions are identical for IBM Tivoli Monitoring 6.2.2 fixpack 1 and fixpack 2, so the instructions for the link are valid for either version. Previous versions of tedgen do require a Tivoli Enterprise Console. As of IBM Tivoli Monitoring 6.2.2 fixpack 1, the tedgen utility is part of the tools distribution and no longer requires that you have a Tivoli Enterprise Console installation.
After you start the EIF Slot Customization window, you see a box at the top showing the currently selected event class for mapping the situation event (Figure 12-38), and below that you see currently mapped slots. Beside the box showing the class is a button you can use to select another event class; click that button to change the class.
Figure 12-38 EIF Slot Customization
3. Click the button to the right of the Event class name (Figure 12-38 on page 370 shows the cursor over this button) to open the window (shown in Figure 12-39) that lists available event classes.
Figure 12-39 Select Event Class dialog for Situation EIF Slot Customization
4. Every situation starts with the assigned default Omegamon_Base class. The classes are organized hierarchically in the tree with the various agent-specific base classes listed alphabetically.
In the class navigator, select KIS_Base → ITM_KIS_SERVICE_INSTANCE_STATISTICS and click OK. Initially you may not see much difference in the list of mapped slots, with the Extended slots pane empty. In the EIF Slot Customization window, be sure the Map all attributes check box is selected. See Figure 12-40.
Figure 12-40 Map all attributes
The Extended slots pane is populated with the class-specific slots, which you can use to map specific attributes onto slots. In this scenario, we do not customize the mappings any further; the purpose is to enable the mapping so that all slots are populated when the event is submitted through the Event Integration Facility.
5. Save the Event Integration Facility configuration by clicking OK. Return to the main situation definition tab and click Advanced, then set the situation display item to Description from the selection menu. Click OK, then click Apply to save the situation configuration.
6. Perform the same steps for the Transaction Tracking situation except for setting the display item. Although you may set this item (and setting it is good practice generally when creating or configuring situations), it is not required for the integration to work. You are still in the Situation Editor at this point, if not, open it again. Navigate to the situation Transaction Reporter → Slow_Transactions and click the EIF tab. Follow the same steps as for the previous situation, ensuring that the Forward Event to an EIF Receiver check box is selected and that the appropriate EIF Receiver is listed under Assigned EIF Receivers. Next, open the EIF Slot Customization window and click the button to select the event class. For the Transaction Reporter situation, select the KTO_Base → ITM_Aggregates class. See Figure 12-41.
Figure 12-41 Event class selection for situation Slow_Transactions
7. Make sure the Map all attributes check box is selected and save your configuration. Be aware that, when configuring the severity used when forwarding events through the Event Integration Facility, we used a lower severity for Slow_Transactions than for KIS_Element_SLA_Failure. The situation by itself might not indicate a service failure, whereas the second situation does in our scenario, and so we assigned the severities to indicate the relative impact.
By default, both situations are distributed to all installed agents of the appropriate type; although you may change the distribution, you must have only a single Transaction Reporter (KTO) agent deployed in your infrastructure.
Updating the Tivoli Netcool/OMNIbus configuration
We next discuss modifying the probe rules files used by the Event Integration Facility probe to process incoming events before passing them on to the Tivoli Netcool/OMNIbus ObjectServer:
1. Before performing the update, perform the integration steps to create the rules files and modify the ObjectServer database appropriately for IBM Tivoli Composite Application Manager for Transactions. To do this, extract the contents of the integrations package to a directory on your ObjectServer system. This directory tree should be navigable and writeable by the user under whom the ObjectServer runs. After extracting the contents, you see four subdirectories:
tivoli@tbsm421:/root/itcamftx> ls
dla omnibus tbsm tcr
2. Update the permissions on the directory tree to ensure that your Tivoli Netcool/OMNIbus user can write to the tree:
tbsm421:~/itcamftx # chown tivoli:tivoli *
tbsm421:~/itcamftx # chmod -R g+rw
In our example, the ObjectServer is installed and runs as the user tivoli; this user belongs to the group that is also named tivoli.
3. Navigate to the omnibus subdirectory. The integration package includes the .baroc files, defining the classes for most of the IBM Tivoli Composite Application Manager for Transactions agents. However, two are absent:
 – Those for the Internet Service Monitoring agent and the Transaction Reporter agent.
 – Those are the two which are most important for our purposes.
They are both installed in the $CANDLE_HOME/tables/HTEMS_NAME/TECLIB directory on your Hub Tivoli Enterprise Monitoring Server (where HTEMS_NAME is the name of your Monitoring Server) and are called kis.baroc and kto.baroc, respectively. Copy them both to the same omnibus subdirectory where you extracted the integration package on your ObjectServer system. Then, as your ObjectServer user (tivoli in our scenario), execute the following commands in Example 12-9.
Example 12-9 Execute the commands
tivoli@tbsm421:~> cd /itcamftx_integration_dir/omnibus/
tivoli@tbsm421:/root/itcamftx/omnibus> ./omnibusUpdater.sh -b kis.baroc kt3.baroc kt4.baroc kt5.baroc kt6.baroc kto.baroc -u objserv_admin_user -p password
In the example, itcamftx_integration_dir is the directory into which you extracted the contents of the integration package, objserv_admin_user is the name of an ObjectServer superuser or user with the appropriate permissions to modify the ObjectServer database schema, and password is the password for the admin user.
This command updates the alerts.status table in the ObjectServer database to include specific columns for IBM Tivoli Composite Application Manager for Transactions, and create rules files specific to each event class, which are then included in the main tivoli_eif.rules file for the Event Integration Facility Probe.
We next describe further manual modifications we make to those rules files to populate the new alerts.status columns appropriately for our scenario.
Modifying the Event Integration Facility rules files
If you examine your tivoli_eif.rules file, you see that an additional set of lines has been inserted to include the newly created rules files. See Example 12-10.
Example 12-10 Additional set of lines
# including the rules file generated by the omnibusUpdater script.
include "/opt/IBM/tivoli/netcool/omnibus/probes/linux2x86/custom_mapping.rules"
 
# including the rules file generated by the omnibusUpdater script.
include "/opt/IBM/tivoli/netcool/omnibus/probes/linux2x86/kis.rules"
 
# including the rules file generated by the omnibusUpdater script.
include "/opt/IBM/tivoli/netcool/omnibus/probes/linux2x86/kt3.rules"
 
# including the rules file generated by the omnibusUpdater script.
include "/opt/IBM/tivoli/netcool/omnibus/probes/linux2x86/kt4.rules"
 
# including the rules file generated by the omnibusUpdater script.
include "/opt/IBM/tivoli/netcool/omnibus/probes/linux2x86/kt5.rules"
 
# including the rules file generated by the omnibusUpdater script.
include "/opt/IBM/tivoli/netcool/omnibus/probes/linux2x86/kt6.rules"
 
# including the rules file generated by the omnibusUpdater script.
include "/opt/IBM/tivoli/netcool/omnibus/probes/linux2x86/kto.rules"
We modify the kis.rules and kto.rules files:
1. Open the kis.rules file with an editor. The file contains a series of conditionals, which check the class of the received event and process the slot values appropriately. Find the stanza that begins with the following lines:
if( match($ClassName, "ITM_KIS_SERVICE_INSTANCE_STATISTICS"))
{
2. At the end of this stanza before the closing brace, add the following lines:
@CAM_Application_Name = $profile
@CAM_Profile_Name = $profile
@CAM_Response_Time = $totaltime
@CAM_Transaction_Name = $situation_displayitem
@Node = $host
Remember that the $situation_displayitem for situation events of this class contain the probe element Description attribute, which we set previously to be the same as the URI path that is used in the probe request.
3. Save the kis.rules file and open the kto.rules file for editing. At the bottom of this file, add the following stanza in its entirity:
if (match($ClassName, "ITM_Aggregates"))
{
if(regmatch($enclosing_server, "'(.*)'"))
{
$enclosing_server = extract($enclosing_server, "'(.*)'")
}
 
if(regmatch($enclosing_component, "'(.*)'"))
{
$enclosing_component = extract($enclosing_component, "'(.*)'")
}
 
if(regmatch($total_time, "'(.*)'"))
{
$total_time = extract($total_time, "'(.*)'")
}
 
@CAM_Application_Name = $enclosing_application
@CAM_Details = $enclosing_component
@CAM_Profile_Name = $enclosing_application
@CAM_Response_Time = $total_time
@CAM_Transaction_Name = $aggregate
@Node = $enclosing_server
}
4. Save this file and either send a SIGHUP signal to the Event Integration Facility probe or restart it to force a reload of the rules files.
12.7.2 Triggering the service instance request
Now we describe configuring the Tivoli Netcool/OMNIbus ObjectServer to automate generating the request to Tivoli Service Automation Manager. We address two primary tasks:
•Creating a simple procedure to call a script which communicates with Tivoli Service Automation Manager,
•Creating a simple trigger which will run the procedure based on the correlation of the two events received.
Creating the procedure
Execution of external tasks is done in Tivoli Netcool/OMNIbus by means of procedures, which can either execute SQL statements or external commands. In our scenario, we use the latter type of procedure. We use a simple procedure such as shown in Figure 12-42 on page 376.
Figure 12-42 Edit procedure
This procedure simply calls the tsamService.sh script, passing in as arguments the name of the Tivoli Service Automation Manager service to execute and the name of the hosted application for which the service is to be executed.
Creating the trigger
For this scenario, we create the trigger manually in Tivoli Netcool/OMNIbus, but that is not the only approach. Starting with the release of version 7.3 of Tivoli Netcool/OMNIbus, IBM Tivoli Netcool/OMNIbus users receive IBM Tivoli Netcool/Impact with a limited use license (such as data access to only Tivoli products), and we believe that many users are more likely to use Tivoli Netcool/Impact to create their automations. Another approach is to create yet a third situation in IBM Tivoli Monitoring. You can use a correlated situation to evaluate both of the other situations we described, then send only the single event to Tivoli Netcool/OMNIbus. We however, found this approach less robust and less applicable to production uses, in which users are more likely to want to compare the specific event attributes for correlation purposes.
Our trigger, which we created as a timer trigger set to fire once every minute, has the basic logic shown in Example 12-11.
Example 12-11 Basic logic
begin
-- Find service element failures matched by tx slowdown traceable to a service component
for each row txslowdown in alerts.status where
txslowdown.AlertGroup = 'ITM_Aggregates'
and txslowdown.Type = 20 and txslowdown.Acknowledged = 0
and (txslowdown.CAM_Application_Name + txslowdown.CAM_Transaction_Name) in
(select CAM_Application_Name + CAM_Transaction_Name from alerts.status where AlertGroup = 'ITM_KIS_SERVICE_ELEMENT_FAILURE' and Type = 20 )
begin
--You could use SupressEscl just as well here
set txslowdown.Acknowledged = 1;
--Rememeber that CAM_Details contains the name of the failing component, such as IBM_HTTP_Server
execute execute_tsam_service( txslowdown.CAM_Details, txslowdown.CAM_Application_Name );
end
end;
The trigger checks for unacknowledged transaction slowdowns corresponding to a known service failure, acknowledges the slowdown event, and then requests a new service component instance from Tivoli Service Automation Manager. If the transaction slowdown event cannot be matched with a known service failure, no action is taken.
12.8 Summary
Figure 12-43 shows the quick summary for this integration.
Figure 12-43 Quick summary
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.16.137.108