4.2 HP ServiceCenter/Service Manager

HP ServiceCenter® and HP Service Manager® do not require ORB software to integrate. However, it is necessary to create an adapter for each instance of ServiceCenter and Service Manager on the network.

The HP ServiceCenter and HP Service Manager adapters have the exact same functionality as the previously named Peregrine Systems ServiceCenter adapter.

4.2.1 Integrating ServiceCenter and Service Manager

To integrate to ServiceCenter or Service Manager:

  1. Perform the required customizations to the ServiceCenter server and restart the SOAP Server.

    For instructions, see Section 4.2.2, Configurations for ServiceCenter and Service Manager.

  2. Create an adapter for each instance of a ServiceCenter or Service Manager on the network.

    For instructions, see Section 5.1, Creating an Adapter. Also see Table A-18, HP ServiceCenter and HP Service Manager Adapter Properties.

    Have available the following information:

    • The host name of the ServiceCenter or Service Manager instance

    • The port that the ServiceCenter or Service Manager listens on (default is 12700)

    • The user name and password for a valid user account on ServiceCenter or Service Manager

    The HP ServiceCenter v6.2 requires the use of the /OperationsCenter_install_path/database/examples/ServiceCenterRel62Configuration.xml file.

    The HP Service Manager requires the use of the /OperationsCenter_install_path/database/examples/ServiceManagerConfiguration.xml file.

    The HP Service Manager 9.3 requires the use of the /OperationsCenter_install_path/database/examples/ServiceManagerConfiguration_9.3.xml file.

  3. Customize the integration to surface new modules and define alarm operations in the adapter’s configuration XML file.

    For information about defining or customizing modules in the configuration XML file, see Section 4.2.3, Defining Modules and Alarm Operations.

4.2.2 Configurations for ServiceCenter and Service Manager

Operations Center ServiceCenter adapters use the ServiceCenter/Service Manager’s Web Services interface to send requests to and receive data from the ServiceCenter/Service Manager server. The adapter uses a polling technique to refresh alarm data.

Configuring the ServiceCenter WSDL

For efficiency, the ServiceCenter adapter uses a time stamp to return alarm data for items that changed since the previous poll. Configure the ServiceCenter WSDL definition for the Web Services interface to include this time stamp field.

To configure the WSDL to allow external access to Operations Center required fields:

  1. Using the ServiceCenter client, open the System Navigation dialog box.

  2. Click Menu Navigation > Toolkit to expand them.

  3. Double-click WSDL Configuration to open the External Access Definition dialog box.

  4. Click Search.

    A list of ServiceCenter tables configured for external access displays.

    The adapter must have access to the following tables:

    ServiceCenter Table

    Operations Center Module

    ServiceCenter Web Service

    cm3r

    Change

    ChangeManagement.wsdl

    device

    Inventory

    ConfigurationManagement.wsdl

    incidents

    Service

    ServiceDesk.wsdl

    probsummary

    Incident

    IncidentManagement.wsdl

  5. Click the Data Policy tab.

  6. In the cm3r, device, incidents, and probsummary tables, locate the sysmodtime field and perform the following changes:

    • Set the API Caption column value to sysmodtime.

    • Set the Exclude column value to False.

    • Set the API Data Type column value to DateTimeType.

    • Save the changes for all tables.

  7. In the incidents table, delete the StringType value that is entered for the API Data Type column for the following fields and then save the changes:

    • Description

    • Resolution

    • Update.action

  8. In the probsummary table, locate the Status field and perform the following changes:

    1. Set the API Caption column value to Status.

    2. Set the Exclude column value to False.

    3. Save the changes.

  9. Click the Allowed Actions tab.

  10. In the incidents table where Allowed Actions is equal to Clone, set the Action Names column to Clone.

    This ensures the ServiceDesk.wsdl generates correctly.

  11. Restart the ServiceCenter server.

    For instructions, see Manually Starting the Operations Center Server and Starting the Operations Center Server in UNIX in the Operations Center 5.0 Server Installation Guide.

  12. Configure the adapter (in the ServiceCenter Port property) to send its SOAP requests to the port specified in the system:port_number command in ServiceCenter’s sc.ini file.

    For information about troubleshooting SOAP traffic, see Debugging SOAP Messages.

    For more information about the ServiceCenter Port property, see the Table A-18, HP ServiceCenter and HP Service Manager Adapter Properties.

Configuring the Service Manager WSDL

For any Service Manager fields referenced in the adapter’s configuration XML file, Service Manager must be configured to expose those fields in ServiceManager through its External Access Definition WSDL Configuration feature.

To configure the WSDL to allow external access to Operations Center required fields:

  1. Using the Service Manager client, open the System Navigation dialog box.

  2. Click Menu Navigation > Tailoring to expand them.

  3. Double-click WSDL Configuration to open the External Access Definition dialog box.

  4. Click Search.

    A list of Service Manager tables configured for external access displays.

    For the example configuration XML files that ships with Operations Center, the adapter must have access to the following tables

    Service Manager Table

    Operations Center Module

    ServiceCenter Web Service

    Change/cm3r

    Change

    ChangeManagement.wsdl

    Device/device

    Configuration

    ConfigurationManagement.wsdl

    Incident/probsummary

    Incident

    IncidentManagement.wsdl

    Interaction/incidents

    Service

    ServiceDesk.wsdl

  5. Click the desired Service Manager table.

  6. Click the Fields tab.

  7. In the adapter’s configuration.xml file, verify each Service Manager field referenced between the <field> and </field> xml for each module is listed in the appropriate Service Manager table.

    Examples of the configuration files are located in the /OperationsCenter_install_path/database/examples directory. Make a copy of the appropriate xml file before customizing. The customized configuration file must be specified in the adapter’s Configuration File property. See Table A-18, HP ServiceCenter and HP Service Manager Adapter Properties.

  8. If a field is missing, do the following:

    1. Click the blank entry at the bottom of the table in the Field column.

    2. Select the field to add from the drop-down list.

    3. Click in the Caption field.

    4. Specify the caption. This must match the case-sensitive field name specified in the adapter’s configuration XML file.

    5. For the sysmodtype field, click in the Type column, and specify DateTimeType.

  9. Repeat Step 5 to Step 8 for each table needed.

  10. Configure the adapter (in the Service Manager Port property) to send its SOAP requests to the port specified in the system:port_number command in Service Manager’s sm.ini file.

    For information about troubleshooting SOAP traffic, see Debugging SOAP Messages.

    For more information about the he Service Manager Port adapter property, see the Table A-18, HP ServiceCenter and HP Service Manager Adapter Properties.

Debugging SOAP Messages

To debug SOAP messages, optionally start another instance of the ServiceCenter server. This is described in the “Debugging SOAP messages” or “SOAP Messages” section of the ServiceCenter and Service Manager help and partially printed below for reference.

To debug SOAP messages:

  1. At the command line, enter one of the following:

    • For ServiceCenter:

      scenter -apiserver:unique_port_number -debughttp -log:../logs/debug.log
      

      where -apiserver:unique_port_number identifies a port where only this process runs, and ‑log:../logs/debug.log defines a path to store the logs (/logs/debug.log are examples).

      Normally, all ServiceCenter processes for a particular installation use parameter values from sc.ini in the ServiceCenter RUN directory, and all share the sc.log file that is specified in sc.ini. Manually starting a new ServiceCenter instance with a different log parameter value in the command line causes one ServiceCenter process to run in isolation and produce separate debug output.

      Select a port number that is not likely to be used by other running process.

    • For Service Manager:

      sm -apiserver:unique_port_number -debughttp:1 -log:../logs/debug.log
      

      where -apiserver:unique_port_number identifies a port where only this process runs, and ‑log:../logs/debug.log defines a path to store the logs (/logs/debug.log are examples).

      Normally, all Service Manager processes for a particular installation use parameter values from sm.ini in the Service Manager RUN directory, and all share the sc.log file that is specified in sm.ini. Manually starting a new Service Manager instance with a different log parameter value in the command line causes one Service Manager process to run in isolation and produce separate debug output.

      Select a port number that is not likely to be used by other running process.

  2. Recreate the problem you are trying to debug.

  3. Search the RECV.LOG file for the incoming message.

  4. Search the SEND.LOG file for the outgoing response.

    For example, to start a ServiceCenter server on port 12700 and record the log output in the /logs/scsoap.log file, enter the following command:

    scenter -apiserver:12700 -log:../logs/scsoap.log
    

    This example configures the adapter to send its SOAP requests to port 12700.

    If the SOAP server is not running or loses its connection, in Operations Center the condition indicator for the adapter changes to CRITICAL (red) and the following message displays:

    Could not connect to ServiceCenter while testing the connection by loading URL: http://servername:12700/IncidentManagement.wsdl: Connection refused.
    

4.2.3 Defining Modules and Alarm Operations

The flexibility of HP’s ServiceCenter/Service Manager API allows the modules and alarm operations surfaced by the adapter to be customized as required using the adapter’s configuration and hierarchy XML files.

Figure 4-3 ServiceCenter Adapter Default Hierarchy

Operations Center uses a configuration.xml file to specify how the adapter interacts with the ServiceCenter/Service Manager Soap server to return information about requested modules. These files define:

  • The modules represented as elements in the adapter hierarchy

  • An alarm severity mapping

  • A mapping of standard alarm fields

  • Any custom alarm or element operations

By default, the configuration.xml define access for the Change, Incident, Inventory, and Service modules.

Whereas, the hierarchy.xml file specifies the hierarchical structure for each module. By default, module information is grouped by Assigned to, Severities, and Status values.

Customizing the configuration.xml file requires an understanding of SOAP requests and XML, as well as ServiceCenter/Service Manager security and APIs.

The following sections provide details on defining and customizing module declarations to surface elements and alarms:

Specifying Modules to Define Elements and Retrieve Alarms

The adapter uses ServiceCenter/Service manager modules, defined with module tags, to retrieve records and convert them into alarms in Operations Center. Each defined module displays as an element under the adapter.

To define a new module:

  1. In a text editor, open the /OperationsCenter_install_path/database/examples/ServiceCenterConfiguration.xml or ServiceManagerConfiguration.xml file (or ServiceManagerConfiguration_9.3.xml for Service Manager 9.3).

  2. Define the new module and setup properties.

    <module name="ModuleName" enable="true">

    <properties>

    </properties>

    </module>

    It is recommended to start with an existing and working example (copy and paste the Configuration module example provided in the default configuration.xml file) and modify when creating a new module.

    For information about the Module XML Structure, see Understanding the Module XML Structure.

    For information about the XML tags used, see Module XML Tags Reference.

  3. Inside a formula tag, use fields and severities tags to define how ServiceCenter/Service Manager fields are to be mapped to Operations Center alarms and define severities.

    For information on defining alarm fields and severities, see Mapping Alarm Fields and Severities

  4. Inside a soap tag, configure the SOAP request.

    For information on defining the connection between ServiceCenter/Service Manager and Operations Center, see Configuring the SOAP Request.

  5. Inside an operations tag, configure both required and optional operations.

    pollKeys and getPollRecords tags are used to define required operations necessary to return a specific set of data. Other operations are often used to define right-click operations on alarms.

    For more information about configuring operations, see Setting Up Required Operations and Defining Custom Alarm Operations.

  6. Save the file.

  7. Restart any adapters that use the configuration XML file.

Understanding the Module XML Structure

The following is the XML structure used by each module definition:

<module name="moduleName" enable="true"> <properties> <formula> <fields></fields> <severities></severities> </formula> <soap> <endpoint></endpoint> <namespace></namespace> <server></server> <port></port> <username></username> <password></password> <operations></operations> </soap> </properties></module>

Tags inside the formula tag are used to define the ServiceCenter/Service Manager fields used to populate Operations Center alarms as well as set their severity. Tags inside the soap tag are used to setup a SOAP connection between the ServiceCenter/Service Manager server and Operations Center as well as define required and optional operations.

For more information about module XML tags, see Module XML Tags Reference.

Mapping Alarm Fields and Severities

Setting subelements for the formula tag, in the configuration.xml file, allows you to map ServiceCenter/Service Manager fields to adapter alarms and specify severities.

Defining Alarm Fields

The fields tag predefines the ServiceCenter/Service Manager fields that are used for adapter alarm fields. The following 5 field definitions are required for normalization:

  • status: The field used by the severities mapping tag.

  • lastUpdate: The field used for the alarm time stamp when last updated. Allows Managed Object to query for newly updated records only.

  • key: The field used for the alarm identifier.

  • description: The field used for the description of the alarm.

  • assignedTo: The field indicating person the alarm is assigned to.

Each file must map to a valid Service Manager field. The name of the ServiceCenter/Service Manager field appears as a value of the associated fields subtag. For example,

<fields>

<status>Status</status>

<lastUpdate>sysmodtime</lastUpdate>

<key>ConfigurationItem</key>

<description>AssetTag</description>

<assignedTo>Assignment</assignedTo>

</fields>

NOTE:When mapping the ServiceCenter/Service Manager fields, spaces are removed from the field name where necessary.

To verify how Service Manager fields are mapped using the above example:

  1. Open up the ServiceCenter/Service Manager client and create a new connection.

    Note this example is using the Configuration Management Dashboard in the Service Manager client application.

  2. Select the Administration perspective.

  3. On the System Navigator tab collapse the Connection > Favorites and Dashboards > Configuration Management > All PCs node.

  4. Select any one of the nodes that appears, right-click on the node and select Open.

    A new Configuration Item tab appears for the item.

  5. In the Configuration Item tab, notice the available fields that can be mapped to Operations Center, including the Status, ConfigurationItem, AssetTag and Assignment fields defined in the previous example.

  6. To locate the sysmodtime field that was mapped to the lastUpdate tag in the above example, open the Detail Data tab. Search for sysmodtime by using Ctrl+F in the window.

Mapping Severities

The severities tag predefines how ServiceCenter/Service Manager data is mapped to alarm severities.

All resulting data from the status tag is parsed and evaluated based on the text specified in the severities declarations, and an alarm status is specified any condition is met.

In the example below, if Available, available, Installed, installed, Reserved, reserved, Transfer, or transfer is found anywhere in the status data, the resulting alarm has a severity of OK:

<severities>

<item fromRE="Available" toSeverity="OK"/>

<item fromRE="available" toSeverity="OK"/>

<item fromRE="Installed" toSeverity="OK"/>

<item fromRE="installed" toSeverity="OK"/>

<item fromRE="Reserved" toSeverity="OK"/>

<item fromRE="reserved" toSeverity="OK"/>

<item fromRE="Transfer" toSeverity="OK"/>

<item fromRE="transfer" toSeverity="OK"/>

<item fromRE="Warehouse" toSeverity="MINOR"/>

<item fromRE="warehouse" toSeverity="MINOR"/>

<item fromRE=".*" toSeverity="MAJOR"/>

</severities>

NOTE:A regular expression can be used in defining the fromRE attribute, as in the last declaration in the example above.

Configuring the SOAP Request

Declarations inside the soap tag configure the connection with the ServiceCenter/Service Manager for data requests.

For example:

<soap>

<endpoint>root.soap.endpoint.prefix/SM/PWS/ConfigurationManagement.wsdl</endpoint>

<namespace>root.soap.namespace</namespace>

<server>ConfigurationManagement</server>

<port>ConfigurationManagement</port>

<username>adapter.username</username>

<password>adapter.password</password>

</soap>

The endpoint tag indicates the WSDL (Web Service Definition Language) file, available in ServiceCenter/Service Manager, used to map to the data we are interested in on the Service Manager Client Dashboard.

Use the endpoint tag to specify the appropriate WSDL file that contains the operations needed to retrieve the data that you want. The WSDL files map respectively to the Favorites and Dashboards items from the ServiceCenter/Service Manager Client as shown in Table 4-1.

Table 4-1 WSDL File Mappings to the ServiceCenter/Service Manager Favorites and Dashboards

WSDL File

ServiceCenter/Service Manager Dashboard

ConfigurationManagement.wsdl

Configuration Management

ChangeManagement.wsdl

Change Management

IncidentManagement.wsdl

Incident Management

ProblemManagement.wsdl

Problem Management

ServiceLevelManagement.wsdl

Service Level Management

ServiceDesk.wsdl

Service Desk

Substitution properties, defined by property tags, contain the SOAP parameters needed to construct ServiceCenter/Service Manager Web services requests for polling or invoking operations on the ServiceCenter/Service Manager server. By default, the configuration.xml files define four of these properties. Define additional properties as required.

Table 4-2 Default Substitution Properties

Property

Sets…

root.soap.xmlns

The Soap namespace declarations required to submit Soap requests to the ServiceCenter or Service Manager server.

root.soap.envelope

The Soap envelope XML syntax.

root.soap.endpoint.prefix

The host and port of the ServiceCenter or Service Manager Soap server.

root.soap.namespace

The ServiceCenter or Service Manager Web service namespace.

Setting Up Required Operations

Operations are configured inside an operations tag in the soap tag and include both required and optional operations. The required operations are defined using the following tags:

  • pollKeys

  • getPollRecords

Optional operations are defined by using an operation tag and are useful in defining right-click operations on alarms that perform an action in ServiceCenter/Service Manager.

The following sections provide details on setting up mandatory operations as well as optional operations:

Using the pollKeys Tag

The pollKeys tag retrieves the keys for a particular set of data. Typically, operations available for use are found in the WSDL file with names in the format of Retrieve<something>KeysList and are nested within a WSDL port (indicated by a portType tag). Often the WSDL port name is the same as the name of the WSDL file.

For example, inside the WSDL file, is the following operation:

<operation name="RetrieveDeviceKeysList">

That is nested inside of a WSDL port called ConfigurationManagement:

<portType name="ConfigurationManagement">

We can define this RetrieveDeviceKeysList operation in the configuration XML file in the name tag sub-element of the pollKeys tag, such as:

<operations> <pollKeys> <name>RetrieveDeviceKeysList</name> <envelope>{root.soap.envelope}</envelope> <body> <![CDATA[ <RetrieveDeviceKeysListRequest {root.soap.xmlns}> <model> <keys></keys> <instance> <sysmodtime>&gt;={formula.poll.from.time}</sysmodtime> </instance> </model> </RetrieveDeviceKeysListRequest> ]]> </body> <response>&gt;RetrieveDeviceKeysListResponse</response> <instance> <container>keys</container> <typeattribute>type</typeattribute> </instance> <date> <initial>01/01/1900 00:00:00</initial> <format>MM/dd/yyyy HH:mm:ss</format> </date> </pollKeys></operations>

In this configuration XML example, RetrieveDeviceKeysListRequest is used:

  • In the CDATA portion of the body tag and is indicated by the message attribute of the input tag for the definition of the RetrieveDeviceKeysList operation in ConfigurationManagement.wsdl file.

  • To obtain the value of RetrieveDeviceKeysListResponse (note the &gt; that precedes the RetrieveDeviceKeysListResponse text) and is indicated to us by the message attribute of the output tag for the definition of the RetrieveDeviceKeysList operation in ConfigurationManagement.wsdl file.

Note that in the CDATA section of the body tag there is the following which indicates that we are looking for all records in service manager that have a sysmodtime greater or equal to (indicated by &gt;=) whatever is passed from the adapter as {formula.poll.from.time}:

<instance> <sysmodtime>&gt;={formula.poll.from.time}</sysmodtime> </instance>

The value to compare against need not be sysmodtime. However, sysmodtime is widely used in ServiceCenter/Service Manager.

Using the getPollRecords Tag

The getPollRecords tag is used to specify the operation to get the records, after the getPollRecords tag has set the operation for retrieving the keys. Typically, operations available for use are found in the WSDL file with names in the format of Retrieve<something>List and are nested within a WSDL port (indicated by a portType tag). Often the WSDL port name is the same as the name of the WSDL file.

For example, inside the WSDL file, is the following operation:

<operation name="RetrieveDeviceList">

That is nested inside of a WSDL port called ConfigurationManagement:

<portType name="ConfigurationManagement">

We can define this RetrieveDeviceList operation in the configuration XML file in the name tag sub-element of the getPollRecords tag, such as:

</operations> <getPollRecords> <name>RetrieveDeviceList</name> <envelope>{root.soap.envelope}</envelope> <body> <![CDATA[ <RetrieveDeviceListRequest {root.soap.xmlns}> <model> {formula.poll.keys} </model> </RetrieveDeviceListRequest> ]]> </body> <response>&gt;RetrieveDeviceListResponse</response> <instance> <container>instance</container> <typeattribute>type</typeattribute> </instance> <key> <container>keys</container> <instance>ConfigurationItem</instance> </key> </getPollRecords></operations>

Since we used the RetrieveDeviceKeysList operation in the previous section example, we looked in the WSDL file for an operation of the name RetrieveDeviceList to use for the getPollRecords. Following the same procedure, we reference RetrieveDeviceList defined under the ConfigurationManagement port, and see that RetrieveDeviceList goes for the name tag, RetrieveDeviceListRequest and RetrieveDeviceListResponse go for the CDATA portion and the response tags respectively.

Default Alarm Operations

By default, the configuration XML files include standard alarm operations. Because these operations call ServiceCenter/Service Manager SOAP operations, they might not be functional, depending on account permissions defined on the ServiceCenter or Service Manager server.

Table 4-3 Default Operation Definitions in the Configuration File

Module

Menu

Operation

Description

Change

Change Lifecycle

Approve

Approves the change ticket and updates ticket status to Approved.

Close

Closes the change ticket and updates ticket status to Closed.

Deny

Denies the change ticket and updates ticket status to Denied.

Move To Next Phase

Moves the change ticket to the next step in the change process.

Reopen

Reopens the change ticket and updates ticket status to reopened.

Retract

Pulls the change ticket.

Inventory

Device Lifecycle

Delete

Removes the device ticket.

Incident

Incident Lifecycle

Close

Closes the incident ticket and updates ticket status to Closed.

Create

Creates a new incident. Prompts the user for incident information.

This operation can be modified to work with element property information. For more information about creating an incident prefilled with element property information, see Section 4.2.5, Creating a ServiceCenter or Service Manager Ticket with Element Information.

Reopen

Reopens the closed incident ticket and updates status to Reopened.

Resolve

Resolves the incident ticket and updates status to Resolved.

Resolve Prompted

Resolves the incident ticket and updates status to Resolved. Prompts the user for fix type and resolution code.

Incident Update

Assignee Info

Changes assignee information and updates status to Updated. Prompts the user for update description, assignee name, and assignment.

Contact Name

Changes contact information and updates status to Updated. Prompts the user for update description and contact name.

Service

Call Lifecycle

Close

Closes the service ticket and changes ticket status to Closed.

Create

Creates a change ticket. Prompts the user for change ticket information.

NO Script can be used to define alarm operations. For example, to prompt a user input. For more information about using NOC Script in configuration.xml files, see Section 4.2.4, Defining User Prompts using NOC Script.

Defining Custom Alarm Operations

Custom operations are defined in the configuration.xml file after required operation tags by using the operation and menu tags. They are mainly used to create right-click operations that perform an action in Operations Center and in ServiceCenter/Service Manager.

For example, in the default ServiceManagerConfiguration.xml file, the following operation is defined for the Inventory module. Defined just after the getPollRecords tag, it follows the same procedure as described the previous sections, and has a response tag and the CDATA section in the body tag that are used the same way as in getPollRecords or pollKeys. In addition, it uses a menu tag to indicate the sequence of menu items and sub-menus to get to perform the operation:

<operation name="Delete Device Record" enable="true"> <menu>Service Manager|Device Lifecycle|Delete</menu> <name>DeleteDevice</name> <response>&gt;DeleteDeviceResponse</response> <envelope>{root.soap.envelope}</envelope> <body> <![CDATA[ <DeleteDeviceRequest {root.soap.xmlns}> <model> <keys> <ConfigurationItem>{alarm.ConfigurationItem}</ConfigurationItem> </keys> <instance> </instance> </model> </DeleteDeviceRequest> ]]> </body> <message> <container>messages</container> <entry>cmn:message</entry> </message></operation>

The menu tag, <menu>Service Manager|Device Lifecycle|Delete</menu>, creates a right-click operation from alarms that nests the following menu option sequence: Service Manager > Device Lifecycle > Delete. When Delete is selected, the DeleteDevice operation is performed on the ServiceCenter/Service Manager server.

Module XML Tags Reference

For more information about XML content and structure, see the HP ServiceCenter or HP Service Center Soap documentation.

Table 4-4 ServiceCenter XML Tags for Module Definition

Tag

Defines…

body

The tag that wraps a Soap poll query request.

date

The initial value and format of the sysmodtime inserted for the Soap request.

endpoint

The module’s Web service WSDL file URL on the ServiceCenter or Service Manager Soap servers. The Axis Soap processor uses this URL to retrieve the WSDL.

envelope

The standard envelope headers for the Soap request.

fields

The mapping of module alarm fields to Operations Center alarm columns. The following tags are required for normalization:

status
lastUpdate
key
description
assignedTo

A mapping is required for each module.

formula

The tag that wraps fields and severities definitions.

getPollRecords

The query Soap request to retrieve the data records referenced by the keys returned by the pollKeys request. The contents are the same as those for the pollKeys tab.

instance

The WSDL container and data type of the data returned by the query.

name

The name of the Web service operation name as defined in the module’s WSDL.

namespace

The ServiceCenter or Service Manager namespace URL for its Web service WSDL definition.

menu

Defines the menu and submenu text for the alarms operation.

operation

Web service operations exposed by the ServiceCenter or Service Manager Web services API that can be invoked for an alarm and/or element. The operation tag contains menu and prescript tags.

operations

The Web service Soap operations available for the defined module. A polling technique retrieves data from the ServiceCenter or Service Manager module. These operations are used to poll and update the Operations Center alarm display and provide additional Web service operations for alarms and elements. The operations tag contains pollKeys, getPollRecords, and operation tags.

password

The associated password for ServiceCenter’s or Service Manager’s Web service authentication security requirements.

pollKeys

A query to obtain a list of keys of module records changed since the last poll time. The initial query retrieves all module records contained in the ServiceCenter or Service Manager database. Subsequent queries use the sysmodtime to retrieve only those records that changed since the last poll query. The pollKeys tag contains name, envelope, body, response, instance, and date tags to generate a Soap request that executes the query and to describe the Soap response for this query.

port

The tag name within the associated WSDL file for the Web services Soap port.

prescript

A NOC Script segment to execute before sending the generated Soap request to the ServiceCenter or Service Manager Soap server.

properties

Each module tag requires one properties tag definition. Each properties tag must contain a formula and soap tag definition.

response

The WSDL response tag for this operation.

server

The tag name within the associated WSDL file for the Web services Soap server.

severities

The mapping of the defined Modules status to Operations Center’ alarm severities.

soap

Contains endpoint, namespace, server, port, username, password, and operations tags required to define a Soap request and response.

username

The user name and associated password for ServiceCenter’s or Service Manager’s Web service authentication security requirements.

4.2.4 Defining User Prompts using NOC Script

Use NOC Script to prompt for input before sending Soap operation requests to the ServiceCenter or Service Manager Soap server. Define any necessary NOC Script using the operation and prescript tags in the associated configuration XML file.

Figure 4-4 The Custom User Prompt Dialog box for Incident Update Contact Name Operation

When using NOC Script in a configuration XML file, the NOC Script code must be inside a CDATA delimiter within the prescript tag.

By default, the configuration XML files defines several user prompts as part of operation definitions.

For more information about NOC Script, see the Operations Center 5.0 Scripting Guide.

4.2.5 Creating a ServiceCenter or Service Manager Ticket with Element Information

Use NOC Script to retrieve property information from any element and use it to create a ServiceCenter Incident ticket.

In the following implementation, we modify the Create Incident script normally used for alarms and create a Create Incident operation for elements that allows users to create a new incident record in the ServiceCenter or Service Manager server for any element in the Elements hierarchy.

For more information about the default Create Incident operation definition, see Table 4-3, Default Operation Definitions in the Configuration File)

To create a custom operation to create ServiceCenter/Service Manager tickets:

  1. Create an operation definition that is applicable to all Operations Center elements that run a NOC Script.

    For this implementation, the default Create Incident operation from the configuration XML file can be modified (or reused to create a new script) by updating the property references for element properties which are always prefixed with element. instead of an alarm. prefix.

    For more information about defining custom operations, see the Operations Center 5.0 Server Configuration Guide.

  2. Access the operation definition in the Explorer pane under Administration > Server > Operation Definitions.

  3. Right-click Operation Definitions, then select Create Operation.

  4. Enter the following code in the Operation field to call the SCOperationScript.fs file found in the /OperationsCenter_install_path/database/scripts/ServiceCenter or /OperationsCenter_install_path/database/scripts/ServiceManager directory:

    load("ServiceCenter/SCOperationScript.fs");
    

    The SCOperationScript.fs script locates the ServiceCenter or Service Manager adapter and invokes the module operation. An operation prescript usually detects whether the operation was invoked from an Element or Alarm and populates the ServiceCenter Soap request with appropriate information. The script can be used with IDK and non-IDK elements.

  5. Enter the following code in the Operation field to call a default operation as defined in the ServiceCenterConfiguration.xml or ServiceManagerConfiguration.xml file (or ServiceManagerConfiguration_9.3.xml (for Service Manager 9.3)), then click Apply:

    • For HP ServiceCenter enter:

      executeOperation("Adapter: HP ServiceCenter(r)","Incident","Create Incident");

    • For HP Service Manager enter:

      executeOperation("Adapter: HP Service Manager(r)","Incident","Create Incident");

    The first argument is the name of the adapter as displayed in Operations Center. The second argument is the module name as specified in the module tag. The third argument is the operation name as specified in the operation tag.

    When this operation is performed on an element, the Create Incident operation opens a Create Incident dialog and pre‑fills element property information as required.

  6. Click Create.