| Oracle® Enterprise Manager Connectors Installation and Configuration Guide 10g Release 4 (10.2.0.4) Part Number E10323-06 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Connectors Installation and Configuration Guide 10g Release 4 (10.2.0.4) Part Number E10323-06 |
|
|
PDF · Mobi · ePub |
The Oracle Management Connector for BMC Remedy Service Desk integrates BMC Remedy Service Desk v7 with Enterprise Manager. Using this connector, you can create, update, close, or reopen a ticket based on alerts in Enterprise Manager.
This chapter provides the following information for setting up and configuring the Remedy Service Desk Connector:
Introduction to the Remedy Service Desk Connector
Prerequisites
Installing and Uninstalling the Remedy Service Desk Connector
Configuring the Remedy Service Desk Connector
Creating Remedy Tickets
Navigating Between Remedy and Enterprise Manager
Using Default Templates
Enabling SSL for HTTPS
Remedy Service Desk Connector Tips
The Remedy Service Desk Connector integrates Enterprise Manager with Remedy Service Desk through either an HTTP or HTTPS connection. You can create, update, close, or reopen tickets based on only the following types of alerts in Enterprise Manager:
Metric alerts
Availability alerts (includes alerts for Up, Down, Blackout Started, Blackout Ended, Agent Unreachable, and Agent Unreachable Resolved)
Note that the term ticket refers to a Remedy incident.
The following sections explain various Remedy Service Desk Connector concepts that you must understand before you start using the Remedy Service Desk Connector.
Whenever an alert is triggered or changes in state in Enterprise Manager, the Remedy Service Desk Connector can automatically open or update a ticket. You can specify the set of alerts for which tickets must be opened and the alert severity for which this should happen.
You can do this in Notification Rules, the user-defined rules that define the criteria by which notifications should be sent for alerts.
See Also:
"Configuring Notifications" in Oracle Enterprise Manager Advanced Configuration GuideAfter the ticket is opened, any subsequent update of the alert, such as a change in alert severity, updates the ticket. After the alert is cleared (severity is set to Clear), you can optionally close the alert.
See Also:
Section 3.5.1, "Automatically Creating a Ticket"From the Enterprise Manager console, you can manually open a Remedy ticket based on an open alert in Enterprise Manager. The Remedy Service Desk Connector populates the ticket with details based on the alert and the ticket template selected.
See Also:
Section 3.5.2, "Manually Creating a Ticket"Ticket templates are XML transformation style sheets that transform Enterprise Manager alerts to a ticket format before the requests are sent to Remedy Service Desk. A ticket template specifies how Enterprise Manager alert attributes can populate the fields of a Remedy ticket.
In Auto Ticketing, a notification method is created for each registered ticket template. The selected notification method determines which ticket template is used when a notification is sent out to the Connector. In the case of manual ticketing, you have to select a ticket template before submitting a request to create the ticket.
The Remedy Service Desk Connector includes some out-of-box default ticket templates. You may want to customize the templates to suit your needs.
See Also:
Section 3.7, "Using Default Templates"The grace period provides you with a configuration to prevent the creation of a large number of tickets for frequently reoccurring alerts. For alerts that occur frequently within a relatively short time interval, it is often desirable to open and maintain a ticket that tracks each occurrence of the alert instead of separate tickets each time.
For recurring alerts, the grace period is a time period during which reoccurrences of the same alert update (or re-open) an existing ticket for the alert, rather than create a new ticket.
For example, an alert triggers and a ticket is opened for it. If the grace period is one hour and the alert is cleared at 10:00 a.m., and if the same alert retriggers before 11:00 a.m. (one-hour grace period), the original ticket will be updated/reopened.
Note:
In Remedy, after a ticket is set to a Closed status, it cannot be reopened. Consequently, an alert that re-triggers within the grace period cannot reopen the ticket but only annotate it. If you want to reopen a ticket for alert occurrences that fall within the grace period, set the ticket status to Resolved instead of Closed when the alert clears. This enables the Remedy Service Desk Connector to reopen the ticket if the same alert reoccurs within the grace period.Before using Remedy Service Desk Connector, ensure that you meet the following prerequisites:
Remedy Service Desk IT Service Management 7.0.03 with the latest Incident Management patch, ÒIT Service Management Patch 008Ó is installed and configured.
Remedy Service Desk web services are up and running. See Section 3.9.3, "Web Service Details for Default Templates".
The Remedy Service Desk connector is packaged as a single jar file, remedy_service_desk_connector.jar, that you can deploy by using Enterprise Manager emctl command.
There can only be one ticketing connector in Oracle Enterprise Manager. Before proceeding to the next section, do the following:
Click the Setup link in the upper right corner of the Oracle Enterprise Manager console.
Click the Management Connectors link in the left column of the Overview of Setup page.
Remove any ticketing connector you may have.
Perform the following steps to install the connector:
Copy remedy_service_desk_connector.jar to $ORACLE_HOME/sysman/connector on the server hosting your OMS. For multiple OMSes, you need to copy the .jar file for all OMSes.
Run the following emctl command on all OMSes if you have a multi-OMS environment:
$ORACLE_HOME/bin/emctl extract_jar connector <jarfile> <connector_name>
This extracts the .jar file to this folder:
$ORACLE_HOME/sysman/connector/Remedy_Service_Desk_Connector/
For example:
emctl extract_jar connector remedy_service_desk_connector.jar "Remedy Service Desk Connector"
Deploy the connector by running the following emctl command. You only need to run this step on one OMS.
$ORACLE_HOME/bin/emctl register_connector connector <connectorType.xml> <server> <port> <database sid> <username> <oracleHome>
For example:
emctl register_connector connector $ORACLE_HOME/sysman/connector/Remedy_Service_Desk_Connector/RemedyDeploy.xml $emHost $dbPort $dbSID sysman $ORACLE_HOME
The Remedy Service Desk Connector should now appear in the Management Connector page.
Registering the Ticket Template
There are three default templates:
Remedy_DefaultCategory_AutoResolve.xsl
Remedy_DefaultCategory_AutoClose.xsl
Remedy_DefaultCategory.xsl
Run the following command as a user with execute privilege on emctl and the ability to read the ticket template:
$ORACLE_HOME/bin/emctl register_ticket_template connector <ticketTemplate.xsl> <server> <port> <database sid/service name for RAC DB> <username> <password> <connectorTypeName> <connectorName> <templateName> <description>
Note:
You need to run this command for every Remedy template that is shipped as part of the connector. For multiple OMS installations, you need to run this command only once from any of the OMSes.Example 3-1 Ticket Template Registration
emctl register_ticket_template connector Remedy_DefaultCategory_AutoResolve.xsl $emHost $dbPort $dbSID sysman $sysmanPwd "Remedy Service Desk Connector" "Remedy Service Desk Connector" "Auto Resolve Template" "This template creates a ticket with priority based on event severity and auto resolve"
Table 3–1 provides descriptions for the parameters shown in the emctl command above.
| Parameter | Description |
|---|---|
|
|
Fully qualified name of the ticket template file. The file resides in the Connector home directory:
Oracle recommends that you use intuitive names since there might be notification methods created with the same names, and you have to choose one of them when you use the Auto Ticketing feature. Use If the file is in a different directory, provide the complete path for the file. |
|
|
Host name of the Enterprise Manager repository. |
|
|
Listener port of the repository. |
|
|
Repository database instance ID or service name if you are using RAC database as the repository. |
|
|
Specify |
|
|
Password for |
|
|
Specify |
|
|
Specify |
|
|
Intuitive name for the ticket template that will be displayed in Enterprise Manager. |
|
|
Short description for the ticket template. This description is also displayed in Enterprise Manager. |
As Super Administrator, from the Enterprise Manager console, click Setup.
The Overview of Setup page appears.
Click Management Connectors in the left pane.
The Management Connectors page appears. For the Remedy Service Desk Connector row, the Configured column should be blank, as shown in Figure 3–1.
Note:
A check mark instead indicates that the Connector is already configured.Click the Configure icon for the Remedy Service Desk Connector.
The General tab of the Configure Management Connector page appears, as shown in Figure 3–2.
Provide the required settings. See "General Settings" for details.
Click OK.
The Management Connectors page reappears. The row for the Remedy Service Desk Connector should have a check mark in the Configured column.
Optional: To check for the available ticket templates, click the configure icon again.
Click the Ticket Templates tab.
All out-of-box ticket templates should appear in the table.
If any of the ticket templates are missing, you can register them using the emctl command from the ORACLE_HOME/bin directory, where ORACLE_HOME is the Oracle home directory of OMS.
If you choose HTTPS as the protocol to establish a connection between Remedy and Enterprise Manager, see "Enabling SSL for HTTPS" on page 3-38.
The following sections explain how to provide various configuration details.
The Remedy Service Desk Connector communicates with the Service Desk through their Web services. Mandatory fields are indicated by an asterisk ( * ).
Web Service End Points — End points to createTicket, updateTicket, and getTicket web services exposed by Remedy Service Desk. See Section 3.9.3, "Web Service Details for Default Templates" for additional information.
You need to import HelpDesk_Query_Service_getIncident.def into your Remedy instance for a getTicket operation. By default on the Enterprise Manager Management Connector page, the web service endpoint for getTicket appears as HPD_IncidentInterface_get_WS. If you want to use the Remedy_DefaultCategory_AutoResolve.xsl template, you need to import HPD_IncidentInterface_CustomWS.def. Back up HPD_IncidentInterface_WS web service before importing.The *def files are located here:$ORACLE_HOME/sysman/connector/Remedy_Service_Desk_Connector
Remedy Username — User with the privilege to create, update, and query tickets in Remedy.
Remedy Password — Password associated with the supplied Remedy user.
Authentication — String that a Remedy administrator sets for additional security. Applies only if the Remedy Administrator has configured it on the Remedy AR server (optional).
Locale — Language of the Remedy system (optional).
Time Zone — Time zone of the Remedy AR System Server (optional).
Ticket Number — Enter a valid ticket number if you want to test the connection when you save the configuration.
If you do not enter a ticket number, no message appears on the Management Connectors page after you click OK and the configuration is saved.
If you specify the correct Web service end points and enter a valid ticket number, the following message appears on the Management Connectors page after you click OK:
"Connection test succeeded. The configuration was saved."
If you have not previously saved the connector configuration and enter an invalid ticket number, the following message appears on the Management Connectors page after you click OK:
"Connection test failed. The configuration was saved."
If you have saved the connector configuration before, specify incorrect Web service end points, and specify either a valid or invalid ticket number, the following message appears on the Management Connectors page after you click OK:
"Connection test failed. The configuration was not saved."
Web Console settings are required if you want the Connector to provide links to Remedy Service Desk tickets created by Enterprise Manager in the context of an alert.
To enable this functionality, provide the following Web console settings.
Enable web console — Check this box to enable launching of the Remedy ticket page within context from Enterprise Manager.
ARServer Name — Remedy AR Server name.
HelpDesk Case Form Name — Remedy form name that the Remedy Web Services (you configured the connector to use) is based on. The Remedy default Service Desk Web services, for example, use the form HPD:IncidentInterface.
Web Server — The name or IP address of the server that hosts Remedy Mid-Tier.
The following sections provide information about registering, removing, replacing, and adding ticket templates.
You need to register ticket templates before they are recognized in Enterprise Manager. For Auto Ticketing, a notification method is created for each registered ticket template and a ticket is created and updated based on the ticket template associated with the selected notification method. For manual ticketing, registered ticket templates are available for selection.
All registered ticket templates are displayed in the Configure Management Connector Ticket Templates page. To register additional ticket templates that you create, see Section 3.3.1, "Installing the Connector".
See Also:
Table 3–1, " emctl Parameters" on page 3-5Click a template name to view the XSLT code for the template.
The ticket templates are in XSLT format. A basic knowledge of XSLT is required to understand the code.
To remove a template, do the following:
Important:
If the template you delete has a notification rule associated with it, ticketing will not work for this particular notification rule after the deletion.Select the template and click Remove.
At the prompt, confirm the removal.
Before you exit the page, click OK for the deletion to take effect.
Note:
Unless you click OK before you exit, the template is not deleted. The next time you go to the Ticket Template page, the templates reappear.Though the ticket template is removed from the Enterprise Manager repository, it is still available on OMS in the Connector home directory. You can re-register the ticket template later if required.
You can create tickets automatically or manually. The following sections explain how to create both types.
Perform the following steps to automatically create a ticket:
Review Section 3.7, "Using Default Templates".
Select an appropriate ticket template with the desired mapping of Enterprise Manager alert fields to the Remedy ticket fields.
If you do not have a ticket template that satisfies your requirement, create one and register it.
Create a notification rule using the following steps:
Important:
Do not select more than one ticket template for this notification rule.From the Enterprise Manager console, click Preferences.
In the left pane, under Notification, click Rules, then Create.
In the Create Notification Rule General page, specify the rule name, a description, and the targets for which this rule should apply.
In the Create Notification Rule Availability page, select the availability states for which you want to create tickets.
In the Create Notification Rule Metrics page, select the metrics and their associated alert severities for which you want to create and update tickets.
Ensure that you select all relevant alert severities if you want to update the ticket when the alert severity changes. For example, to open a ticket for a critical alert on the CPU Utilization(%) metric and the ticket is to be updated if the CPU Utilization(%) changes to warning or clear severity, in the notification rule select Critical, Warning, or Clear severities for the CPU Utilization(%) metric.
In the Create Notification Rule Methods page, choose the ticket template from the Advanced Notification Methods table, as shown in Figure 3–3.
In the table, registered ticket templates appear as Java Callback type notification methods under the same name as the ticket template's file name.
See Also:
"Configuring Notifications" in Oracle Enterprise Manager Advanced Configuration GuideThe following process occurs after you create the notification rule for your alerts:
A notification is sent to the Remedy Service Desk Connector when a metric alert triggers that matches your rule. The Remedy Service Desk Connector creates/updates a ticket according to the ticket template as set in the notification rule.
The ticket is created or updated on the Remedy Ticket system.
In Enterprise Manager, the alert annotation is updated. A comment is added to the Metric Details page of the alert to indicate that a ticket was created or updated, along with the ticket ID and ticket page URL.
A ticket is updated if there is an existing active ticket for an alert. Figure 3–4 shows the ticket in the Remedy console, and Figure 3–5 shows the alert as displayed in Enterprise Manager.
Perform the following steps to manually create a ticket:
After a metric alert occurs, go to the associated metric details page for the alert. To access this page, click the alert message in the Enterprise Manager console, as shown in Figure 3–6.
Click the Create/View Ticket link in the Related Links section.
The Create Ticket page appears if no active ticket exists for the alert.
Select a ticket template and then click Submit, as shown in Figure 3–7.
If you do not see the desired template, you can register one using the emctl command. See Section 3.4.2.1, "Registering Ticket Templates".
If creating or updating the ticket is successful, the ticket ID appears in the Last Comment column of the Alert History table for the metric alert.If the Web console settings are configured and enabled, the ticket ID appears as a link to the ticket page in the Remedy Service Desk.
Note:
You cannot manually update the ticket using the Remedy Service Desk Connector. You need to manually update the ticket in Remedy for any subsequent alert change, or you can include the metric in a notification rule.The following sections explain how to switch from one console to the other.
From a ticket page, click the link in the Notes field to the Alert Details page in the ticket message body, as shown in Figure 3–8. This action takes you to the Enterprise Manager console login page. After you provide the Enterprise Manager user name and password, you are forwarded to the alert related to this ticket.
Note:
The Enterprise Manager user whose name you specify should at least have
View privileges on the target on which the alert was raised.In the Enterprise Manager console, click the alert message to go to the metric details page for the alert.
In the Alert History table, locate the ticket ID link in the Last Comment column.
(If not found) Click the icon in the Details column to get more information about the alert.
On the page that appears, locate the ticket ID in the Alert Details table.
Click the ticket ID link. You are forwarded to the Remedy Web console login page.
Provide valid Remedy account details.
The ticket page associated with this alert is displayed.
Note:
If you do not use the Remedy Web console, uncheck the Enable web console option in the Web Console Settings section so that ticket ID is shown in plain text. Otherwise, it is displayed as a link that does not work.This section provides details on the default ticket templates shipped along with the Remedy Service Desk Connector. The ticket templates specify the mappings between Enterprise Manager alert attributes and Remedy ticket attributes.
All out-of-box templates cause the following actions to occur when a you create a ticket for an alert:
Write alert information to Description (Remedy ticket description).
Set the Remedy ticket summary based on the alert message. On update, the ticket summary field is updated to include the latest alert message information.
The out-of-box templates are as follows:
Remedy_DefaultCategory_AutoResolve.xsl
Remedy_DefaultCategory_AutoClose.xsl
Remedy_DefaultCategory.xsl
Remedy_DefaultCategory_AutoResolve.xsl
The Remedy_DefaultCategory_AutoResolve.xsl template sets the ticket status to Resolved when the event severity value becomes clear. When the same event with a Critical or Warning severity occurs within the grace period time, the following occurs:
The ticket is reopened.
The status field is set as Assigned.
The ticket Summary, Notes, Work Info Summary, and Work Info Notes fields are updated with the latest event information. If you leave an incident as resolved, the Incident Management application closes the incident after 15 days. See the BMC Remedy Service Desk: Incident Management 7.0 User's Guide for more information.
Remedy_DefaultCategory_AutoClose.xsl
The Remedy_DefaultCategory_AutoClose.xsl template ets the ticket status to Closed when the event severity value becomes Clear. After the Ticket Status is closed, it cannot be reassigned to other values. When the same event with critical or warning severity occurs within the grace period time, the following occurs:
The ticket is not reopened.
The status field remains Closed, but the ticket Summary, Notes, Work Info Summary, and Work Info Notes fields are updated with the latest event information.
Note:
Oracle recommends that you do not select Remedy_DefaultCategory_AutoClose.xsl if you want tickets to be reopened when a critical or warning event has occurred within the grace period.The Remedy_DefaultCategory.xsl template does not close the ticket when the event severity value becomes clear. When the same event with a Critical or Warning severity occurs within the grace period time, the ticket Summary, Notes, Work Info Summary, and Work Info Notes fields are updated with the latest event information.
Table 3–2 and Table 3–3 illustrate the creation of a ticket using Remedy_DefaultCategory_AutoResolve.xsl. This illustration will help you to read a ticket template. In the tables, * denotes a literal string and ** indicates if the attribute applies.
Ticket creation mappings are the same for Remedy_DefaultCategory_AutoResolve.xsl, Remedy_DefaultCategory_AutoClose.xsl, and Remedy_DefaultCategory.xsl.
Table 3–2 shows Remedy ticket attributes and corresponding Enterprise Manager alert values for ticket creation mappings.
Table 3-2 Ticket Creation Mappings (for all templates)
| Remedy Ticket Attributes | Enterprise Manager Alert Attributes | Value |
|---|---|---|
|
Assigned_Group |
Blank |
|
|
Assigned_Group_Shift_Name |
Blank |
|
|
Assigned_Support_Company |
Blank |
|
|
Assigned_Support_Organization |
Blank |
|
|
Assignee |
Blank |
|
|
Categorization_Tier_1 |
Blank |
|
|
Categorization_Tier_2 |
Blank |
|
|
Categorization_Tier_3 |
Blank |
|
|
CI_Name |
Blank |
|
|
Closure_Manufacturer |
Blank |
|
|
Closure_Product_Category_Tier1 |
Blank |
|
|
Closure_Product_Category_Tier2 |
Blank |
|
|
Closure_Product_Category_Tier3 |
Blank |
|
|
Closure_Product_Model_Version |
Blank |
|
|
Closure_Product_Name |
Blank |
|
|
Department |
Blank |
|
|
First_Name |
HDUser |
User name provided in the "Remedy Username" field during the configuration. |
|
Impact |
Severity |
|
|
Last_Name |
HDUser |
|
|
Lookup_Keyword |
Blank |
|
|
Manufacturer |
Blank |
|
|
Product_Categorization_Tier_1 |
Blank |
|
|
Product_Categorization_Tier_2 |
Blank |
|
|
Product_Categorization_Tier_3 |
Blank |
|
|
Product_Model_Version |
Blank |
|
|
Product_Name |
Blank |
|
|
Reported_Source |
"Systems Management" * |
|
|
Resolution |
Blank |
|
|
Resolution_Category_Tier_1 |
Blank |
|
|
Resolution_Category_Tier_2 |
Blank |
|
|
Resolution_Category_Tier_3 |
Blank |
|
|
Service_Type |
"Infrastructure Event" * |
|
|
Status |
New * |
|
|
Action |
CREATE * |
|
|
Create_Request |
Blank |
|
|
Summary |
Message |
|
|
Notes |
EMUser — Notification rule owner when the ticket is created through auto-ticketing, and is the Enterprise Manager log-in user when the ticket is created through manual-ticketing. TargetName TargetType MetricColumn — Name of the metric, such as CPU Utilization (%). MetricName — Category of the metric. For the CPU Utilization (%) metric, this would be 'Load.' KeyColumn ** — For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyColumn is 'Tablespace Name.' KeyValues ** — For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity. Severity CollectionTime TargetHost NotificationRuleName EventPageURL — URL to the metric details page in the context of the alert. |
Values from the alert context. |
|
Urgency |
Severity |
|
|
Work_Info_Summary |
Message |
|
|
Work_Info_Notes |
Message, Severity |
|
|
Work_Info_Type |
"Incident Task/Action" * |
|
|
Work_Info_Date |
Blank |
|
|
Work_Info_Source |
"System Assignment" * |
|
|
Work_Info_Locked |
Blank |
|
|
Work_Info_View_Access |
"Public" * |
|
|
Middle_Initial |
Blank |
Table 3–3 shows Remedy ticket attributes and corresponding Enterprise Manager alert attributes and values for Remedy_DefaultCategory_AutoResolve.xsl mappings.
Table 3-3 Ticket Updates (Remedy_DefaultCategory_AutoResolve.xsl Mappings)
| Remedy Ticket Attributes | Enterprise Manager Alert Attributes | Value |
|---|---|---|
|
Categorization_Tier_1 |
Blank |
|
|
Categorization_Tier_2 |
Blank |
|
|
Categorization_Tier_3 |
Blank |
|
|
Closure_Manufacturer |
Blank |
|
|
Closure_Product_Category_Tier1 |
Blank |
|
|
Closure_Product_Category_Tier2 |
Blank |
|
|
Closure_Product_Category_Tier3 |
Blank |
|
|
Closure_Product_Model_Version |
Blank |
|
|
Closure_Product_Name |
Blank |
|
|
Company |
"Internal" * |
|
|
Summary |
Message, Severity |
|
|
Notes |
EMUser — Notification rule owner when the ticket is created through auto-ticketing, and is the Enterprise Manager log-in user when the ticket is created through manual-ticketing. TargetName TargetType MetricColumn — Name of the metric, such as CPU Utilization (%). MetricName — Category of the metric. For the CPU Utilization (%) metric, this would be 'Load.' KeyColumn ** — For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyColumn is 'Tablespace Name.' KeyValues ** — For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity. Severity CollectionTime TargetHost NotificationRuleName EventPageURL — URL to the metric details page in the context of the alert. |
. |
|
Impact |
Severity |
|
|
Incident_Number |
TicketId — The connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web Service to identify the ticket that must be updated. |
|
|
Manufacturer |
Blank |
|
|
Product_Categorization_Tier_1 |
Blank |
|
|
Product_Categorization_Tier_2 |
Blank |
|
|
Product_Categorization_Tier_3 |
Blank |
|
|
Product_Model_Version |
Blank |
|
|
Product_Name |
Blank |
|
|
Reported_Source |
"Systems Management" * |
|
|
Resolution |
Severity |
If severity is Clear |
|
Resolution_Category |
Blank |
|
|
Resolution_Category_Tier_2 |
Blank |
|
|
Resolution_Category_Tier_3 |
Blank |
|
|
Resolution_Method |
Blank |
|
|
Service_Type |
"Infrastructure Event" * |
|
|
Status |
Severity |
|
|
Status_Reason |
Severity |
If severity is Clear, set the Status_Reason to "Automated Resolution Reported." |
|
Urgency |
Severity |
|
|
Action |
CREATE * |
|
|
Work_Info_Summary |
Message |
|
|
Work_Info_Notes |
Severity |
|
|
Work_Info_Type |
"Incident Task/Action" * |
|
|
Work_Info_Date |
Blank |
|
|
Work_Info_Source |
"System Assignment" * |
|
|
Work_Info_Locked |
"No" * |
|
|
Work_Info_View_Access |
"Public" * |
Use the mapping table (Table 3–2) as a reference to read the XSLT file in Example 3–2.
Example 3-2 Remedy_DefaultCategory_ AutoResolve.xsl Source Code with Annotations
?xml version='1.0' encoding='UTF-8'?>
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:ns0="http://xmlns.oracle.com/sysman/connector/tt"
targetNamespace="http://xmlns.oracle.com/sysman/connector/tt"
elementFormDefault="qualified">
<!-- This template creates an incident type ticket within Remedy Service Desk with default settings. On update, the worklog is updated with the latest event message and severity information. The ticket is set to status Resolved if the associated alert has cleared. Ticket can be reopend if a severity occured with in the grace period. If the ticket is not reopened for 15 days, ticket will be closed by incident management.
-->
<xsl:template match="ns0:EventModel">
<xsl:choose>
<xsl:when test="normalize-space(ns0:TicketId) = ''">
<urn:HelpDesk_Submit_Service xmlns:urn="urn:HPD_IncidentInterface_ Create_WS">
<!-- EDIT THE TAG VALUES BELOW TO CHANGE HOW A TICKET IS FILLED
DURING TICKET CREATION. REFER TO THE REMEDY SERVICE DESK MANUAL
FOR DESCRIPTION OF THESE HELPDESK SUPPORT DATAFIELDS-->
<urn:Assigned_Group/>
<urn:Assigned_Group_Shift_Name/>
<urn:Assigned_Support_Company/>
<urn:Assigned_Support_Organization></urn:Assigned_Support_Organization>
<urn:Assignee/>
<urn:Categorization_Tier_1/>
<urn:Categorization_Tier_2/>
<urn:Categorization_Tier_3/>
<urn:CI_Name/>
<urn:Closure_Manufacturer/>
<urn:Closure_Product_Category_Tier1/>
<urn:Closure_Product_Category_Tier2/>
<urn:Closure_Product_Category_Tier3/>
<urn:Closure_Product_Model_Version/>
<urn:Closure_Product_Name/>
<urn:Department/>
<urn:First_Name><xsl:value-of select="ns0:HDUser"/></urn:First_Name>
<xsl:choose>
<!-- EM Critical -->
<xsl:when test="ns0:SeverityCode = '25'">
<urn:Impact>1-Extensive/Widespread</urn:Impact>
</xsl:when>
<!-- EM Warning-->
<xsl:when test="ns0:SeverityCode = '20'">
<urn:Impact>2-Significant/Large</urn:Impact>
</xsl:when>
<!-- Unreachable Start -->
<xsl:when test="ns0:Severity = 'Unreachable Start'">
<urn:Impact>1-Extensive/Widespread</urn:Impact>
</xsl:when>
<!-- Agent Unreachable Start -->
<xsl:when test="ns0:Severity = 'Agent Unreachable Start'">
<urn:Impact>1-Extensive/Widespread</urn:Impact>
</xsl:when>
<!-- Blackout Start -->
<xsl:when test="ns0:Severity = 'Blackout Start'">
<urn:Impact>2-Significant/Large</urn:Impact>
</xsl:when>
<!-- Metric Error Start-->
<xsl:when test="ns0:Severity = 'Metric Error Start'">
<urn:Impact>2-Significant/Large</urn:Impact>
</xsl:when>
<xsl:otherwise>
<urn:Impact>3-Moderate/Limited</urn:Impact>
</xsl:otherwise>
</xsl:choose>
<urn:Last_Name><xsl:value-of select="ns0:HDUser"/></urn:Last_Name>
<urn:Lookup_Keyword/>
<urn:Manufacturer/>
<urn:Product_Categorization_Tier_1/>
<urn:Product_Categorization_Tier_2/>
<urn:Product_Categorization_Tier_3/>
<urn:Product_Model_Version/>
<urn:Product_Name/>
<urn:Reported_Source>Systems Management</urn:Reported_Source>
<urn:Resolution/>
<urn:Resolution_Category_Tier_1/>
<urn:Resolution_Category_Tier_2/>
<urn:Resolution_Category_Tier_3/>
<urn:Service_Type>Infrastructure Event</urn:Service_Type>
<urn:Status>New</urn:Status>
<urn:Action>CREATE</urn:Action>
<urn:Create_Request/>
<urn:Summary>
<xsl:value-of select="ns0:Message"/>
</urn:Summary>
<urn:Notes>
Ticket created by Oracle Enterprise Manager Remedy Service Desk Connector.
-------------------------------------------------------------------------
EM User: <xsl:value-of select="ns0:EMUser"/>
Event Information:
Target Name: <xsl:value-of select="ns0:TargetName"/>
Target Type: <xsl:value-of select="ns0:TargetType"/>
Metric Column: <xsl:value-of select="ns0:MetricColumn"/>
Metric Name: <xsl:value-of select="ns0:MetricName"/>
<xsl:choose>
<xsl:when test="normalize-space(ns0:KeyColumn) != ''">
Key Column: <xsl:value-of select="ns0:KeyColumn"/>
Key Values: <xsl:value-of select="ns0:KeyValues"/>
</xsl:when>
</xsl:choose>
Severity: <xsl:value-of select="ns0:Severity"/>
Collection Time: <xsl:value-of select="ns0:CollectionTime"/>
Target Host: <xsl:value-of select="ns0:TargetHost"/>
<xsl:choose>
<xsl:when test="normalize-space(ns0:NotificationRuleName) != ''">
Notification Rule: <xsl:value-of select="ns0:NotificationRuleName"/>
</xsl:when>
</xsl:choose>
URL: <xsl:value-of select="ns0:EventPageURL"/>
</urn:Notes>
<xsl:choose>
<!-- EM Critical -->
<xsl:when test="ns0:SeverityCode = '25'">
<urn:Urgency>1-Critical</urn:Urgency>
</xsl:when>
<!-- EM Warning-->
<xsl:when test="ns0:SeverityCode = '20'">
<urn:Urgency>2-High</urn:Urgency>
</xsl:when>
<!-- Unreachable Start -->
<xsl:when test="ns0:Severity = 'Unreachable Start'">
<urn:Urgency>1-Critical</urn:Urgency>
</xsl:when>
<!-- Agent Unreachable Start -->
<xsl:when test="ns0:Severity = 'Agent Unreachable Start'">
<urn:Urgency>1-Critical</urn:Urgency>
</xsl:when>
<!-- Blackout Start -->
<xsl:when test="ns0:Severity = 'Blackout Start'">
<urn:Urgency>2-High</urn:Urgency>
</xsl:when>
<!-- Metric Error Start-->
<xsl:when test="ns0:Severity = 'Metric Error Start'">
<urn:Urgency>2-High</urn:Urgency>
</xsl:when>
<xsl:otherwise>
<urn:Urgency>3-Medium</urn:Urgency>
</xsl:otherwise>
</xsl:choose>
<urn:Work_Info_Summary>
<xsl:value-of select="ns0:Message"/>
</urn:Work_Info_Summary>
<urn:Work_Info_Notes>
Incident created by Oracle Enterprise Manager Remedy Service Desk Connector based on an alert with <xsl:value-of select="ns0:Severity"/> severity. Message: <xsl:value-of select="ns0:Message"/>
</urn:Work_Info_Notes>
<urn:Work_Info_Type>Incident Task / Action</urn:Work_Info_Type>
<urn:Work_Info_Date/>
<urn:Work_Info_Source>System Assignment</urn:Work_Info_Source>
<urn:Work_Info_Locked/>
<urn:Work_Info_View_Access>Public</urn:Work_Info_View_Access>
<urn:Middle_Initial/>
</urn:HelpDesk_Submit_Service>
</xsl:when>
<xsl:otherwise>
<urn:HelpDesk_Modify_Status_Service xmlns:urn="urn:HPD_IncidentInterface_WS">
<urn:Categorization_Tier_1></urn:Categorization_Tier_1>
<urn:Categorization_Tier_2></urn:Categorization_Tier_2>
<urn:Categorization_Tier_3></urn:Categorization_Tier_3>
<urn:Closure_Manufacturer></urn:Closure_Manufacturer>
<urn:Closure_Product_Category_Tier1></urn:Closure_Product_Category_Tier1>
<urn:Closure_Product_Category_Tier2></urn:Closure_Product_Category_Tier2>
<urn:Closure_Product_Category_Tier3></urn:Closure_Product_Category_Tier3>
<urn:Closure_Product_Model_Version></urn:Closure_Product_Model_Version>
<urn:Closure_Product_Name></urn:Closure_Product_Name>
<urn:Company>Internal</urn:Company>
<urn:Summary>
<xsl:value-of select="ns0:Message"/>
</urn:Summary>
<urn:Notes>
Ticket updated by Oracle Enterprise Manager Remedy Service Desk Connector
-----------------------------------------------------------------------
EM User: <xsl:value-of select="ns0:EMUser"/>
Event Information:
Target Name: <xsl:value-of select="ns0:TargetName"/>
Target Type: <xsl:value-of select="ns0:TargetType"/>
Metric Column: <xsl:value-of select="ns0:MetricColumn"/>
Metric Name: <xsl:value-of select="ns0:MetricName"/>
<xsl:choose>
<xsl:when test="normalize-space(ns0:KeyColumn) != ''">
Key Column: <xsl:value-of select="ns0:KeyColumn"/>
Key Values: <xsl:value-of select="ns0:KeyValues"/>
</xsl:when>
</xsl:choose>
Severity: <xsl:value-of select="ns0:Severity"/>
Collection Time: <xsl:value-of select="ns0:CollectionTime"/>
Target Host: <xsl:value-of select="ns0:TargetHost"/>
<xsl:choose>
<xsl:when test="normalize-space(ns0:NotificationRuleName) != ''">
Notification Rule: <xsl:value-of select="ns0:NotificationRuleName"/>
</xsl:when>
</xsl:choose>
URL: <xsl:value-of select="ns0:EventPageURL"/>
</urn:Notes>
<xsl:choose>
<!-- EM Critical -->
<xsl:when test="ns0:SeverityCode = '25'">
<urn:Impact>1-Extensive/Widespread</urn:Impact>
</xsl:when>
<!-- EM Warning-->
<xsl:when test="ns0:SeverityCode = '20'">
<urn:Impact>2-Significant/Large</urn:Impact>
</xsl:when>
<!-- Unreachable Start -->
<xsl:when test="ns0:Severity = 'Unreachable Start'">
<urn:Impact>1-Extensive/Widespread</urn:Impact>
</xsl:when>
<!-- Agent Unreachable Start -->
<xsl:when test="ns0:Severity = 'Agent Unreachable Start'">
<urn:Impact>1-Extensive/Widespread</urn:Impact>
</xsl:when>
<!-- Blackout Start -->
<xsl:when test="ns0:Severity = 'Blackout Start'">
<urn:Impact>2-Significant/Large</urn:Impact>
</xsl:when>
<!-- Metric Error Start-->
<xsl:when test="ns0:Severity = 'Metric Error Start'">
<urn:Impact>2-Significant/Large</urn:Impact>
</xsl:when>
<xsl:otherwise>
<urn:Impact>3-Moderate/Limited</urn:Impact>
</xsl:otherwise>
</xsl:choose>
<urn:Incident_Number>
<xsl:value-of select="ns0:TicketId"/>
</urn:Incident_Number>
<urn:Manufacturer></urn:Manufacturer>
<urn:Product_Categorization_Tier_1></urn:Product_Categorization_Tier_1>
<urn:Product_Categorization_Tier_2></urn:Product_Categorization_Tier_2>
<urn:Product_Categorization_Tier_3></urn:Product_Categorization_Tier_3>
<urn:Product_Model_Version></urn:Product_Model_Version>
<urn:Product_Name></urn:Product_Name>
<urn:Reported_Source>Systems Management</urn:Reported_Source>
<xsl:choose>
<xsl:when test="ns0:Severity = 'Clear'">
<urn:Resolution>Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared</urn:Resolution>
</xsl:when>
<xsl:when test="ns0:Severity = 'Agent Unreachable Clear'">
<urn:Resolution>Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared</urn:Resolution>
</xsl:when>
<xsl:when test="ns0:Severity = 'Blackout End'">
<urn:Resolution>Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared</urn:Resolution>
</xsl:when>
<xsl:when test="ns0:Severity = 'Metric Error End'">
<urn:Resolution>Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared</urn:Resolution>
</xsl:when>
<xsl:when test="ns0:Severity = 'Unreachable Clear'">
<urn:Resolution>Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared</urn:Resolution>
</xsl:when>
<xsl:otherwise>
<urn:Resolution></urn:Resolution>
</xsl:otherwise>
</xsl:choose>
<urn:Resolution_Category/>
<urn:Resolution_Category_Tier_2/>
<urn:Resolution_Category_Tier_3/>
<urn:Resolution_Method/>
<urn:Service_Type>Infrastructure Event</urn:Service_Type>
<!--<urn:Status>Assigned</urn:Status>-->
<xsl:choose>
<xsl:when test="ns0:Severity = 'Clear'">
<urn:Status>Resolved</urn:Status>
</xsl:when>
<xsl:when test="ns0:Severity = 'Agent Unreachable Clear'">
<urn:Status>Resolved</urn:Status>
</xsl:when>
<xsl:when test="ns0:Severity = 'Blackout End'">
<urn:Status>Resolved</urn:Status>
</xsl:when>
<xsl:when test="ns0:Severity = 'Metric Error End'">
<urn:Status>Resolved</urn:Status>
</xsl:when>
<xsl:when test="ns0:Severity = 'Unreachable Clear'">
<urn:Status>Resolved</urn:Status>
</xsl:when>
<xsl:when test="ns0:GracePeriodCheckMade = 'Yes'">
<urn:Status>Assigned</urn:Status>
</xsl:when>
<xsl:otherwise>
<urn:Status>Assigned</urn:Status>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="ns0:Severity = 'Clear'">
<urn:Status_Reason>Automated Resolution Reported</urn: Status_Reason>
</xsl:when>
<xsl:when test="ns0:Severity = 'Agent Unreachable Clear'">
<urn:Status_Reason>Automated Resolution Reported</urn: Status_Reason>
</xsl:when>
<xsl:when test="ns0:Severity = 'Blackout End'">
<urn:Status_Reason>Automated Resolution Reported</urn: Status_Reason>
</xsl:when>
<xsl:when test="ns0:Severity = 'Metric Error End'">
<urn:Status_Reason>Automated Resolution Reported</urn: Status_Reason>
</xsl:when>
<xsl:when test="ns0:Severity = 'Unreachable Clear'">
<urn:Status_Reason>Automated Resolution Reported</urn: Status_Reason>
</xsl:when>
<xsl:otherwise>
<urn:Status_Reason></urn:Status_Reason>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<!-- EM Critical -->
<xsl:when test="ns0:SeverityCode = '25'">
<urn:Urgency>1-Critical</urn:Urgency>
</xsl:when>
<!-- EM Warning-->
<xsl:when test="ns0:SeverityCode = '20'">
<urn:Urgency>2-High</urn:Urgency>
</xsl:when>
<!-- Unreachable Start -->
<xsl:when test="ns0:Severity = 'Unreachable Start'">
<urn:Urgency>1-Critical</urn:Urgency>
</xsl:when>
<!-- Agent Unreachable Start -->
<xsl:when test="ns0:Severity = 'Agent Unreachable Start'">
<urn:Urgency>1-Critical</urn:Urgency>
</xsl:when>
<!-- Blackout Start -->
<xsl:when test="ns0:Severity = 'Blackout Start'">
<urn:Urgency>2-High</urn:Urgency>
</xsl:when>
<!-- Metric Error Start-->
<xsl:when test="ns0:Severity = 'Metric Error Start'">
<urn:Urgency>2-High</urn:Urgency>
</xsl:when>
<xsl:otherwise>
<urn:Urgency>3-Medium</urn:Urgency>
</xsl:otherwise>
</xsl:choose>
<urn:Action>MODIFY</urn:Action>
<urn:Work_Info_Type>Incident Task / Action</urn:Work_Info_Type>
<urn:Work_Info_Date/>
<urn:Work_Info_Source>System Assignment</urn:Work_Info_Source>
<xsl:choose>
<xsl:when test="ns0:Severity = 'Clear'">
<urn:Work_Info_Notes>
Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared.</urn:Work_Info_Notes>
</xsl:when>
<xsl:when test="ns0:Severity = 'Agent Unreachable Clear'">
<urn:Work_Info_Notes>
Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared.</urn:Work_Info_Notes>
</xsl:when>
<xsl:when test="ns0:Severity = 'Blackout End'">
<urn:Work_Info_Notes>
Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared.</urn:Work_Info_Notes>
</xsl:when>
<xsl:when test="ns0:Severity = 'Metric Error End'">
<urn:Work_Info_Notes>
Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared.</urn:Work_Info_Notes>
</xsl:when>
<xsl:when test="ns0:Severity = 'Unreachable Clear'">
<urn:Work_Info_Notes>
Incident resolved by Oracle Enterprise Manager because the associated alert has been cleared.</urn:Work_Info_Notes>
</xsl:when>
<xsl:when test="ns0:GracePeriodCheckMade = 'Yes'">
<urn:Work_Info_Notes>
Ticket reopened because the associated alert re-triggered at <xsl:value-of select="ns0:Severity"/> severity within the grace period. Message: <xsl:value-of select="ns0:Message"/> </urn:Work_Info_Notes>
</xsl:when>
<xsl:otherwise>
<urn:Work_Info_Notes>
Ticket updated due to change in severity of the associated alert. Severity: <xsl:value-of select="ns0:Severity"/> Message: <xsl:value-of select="ns0:Message"/>.
</urn:Work_Info_Notes>
</xsl:otherwise>
</xsl:choose>
<urn:Work_Info_Locked>No</urn:Work_Info_Locked>
<urn:Work_Info_View_Access>Public</urn:Work_Info_View_Access>
<urn:Work_Info_Summary>
<xsl:value-of select="ns0:Message"/>
</urn:Work_Info_Summary>
</urn:HelpDesk_Modify_Status_Service>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:transform>
The tables in this section map the fields in all out-of-box ticket templates shipped with the Remedy Service Desk Connector.
Remedy_DefaultCategory_AutoClose.xsl
In the tables, * denotes a literal string and ** indicates if the attribute applies.
Table 3-4 Ticket Updates (Remedy_DefaultCategory_AutoClose.xsl)
| Remedy Ticket Attributes | Enterprise Manager Alert Attributes | Value |
|---|---|---|
|
Categorization_Tier_1 |
Blank |
|
|
Categorization_Tier_2 |
Blank |
|
|
Categorization_Tier_3 |
Blank |
|
|
Closure_Manufacturer |
Blank |
|
|
Closure_Product_Category_Tier1 |
Blank |
|
|
Closure_Product_Category_Tier2 |
Blank |
|
|
Closure_Product_Category_Tier3 |
Blank |
|
|
Closure_Product_Model_Version |
Blank |
|
|
Closure_Product_Name |
Blank |
|
|
Company |
"Internal" * |
|
|
Summary |
Message |
|
|
Notes |
EMUser — Notification rule owner when the ticket is created through auto-ticketing, and is the Enterprise Manager log-in user when the ticket is created through manual-ticketing. TargetName TargetType MetricColumn — Name of the metric, such as CPU Utilization (%). MetricName — Category of the metric. For the CPU Utilization (%) metric, this would be 'Load.' KeyColumn ** — For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyColumn is 'Tablespace Name.' KeyValues ** — For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity. Severity CollectionTime TargetHost NotificationRuleName EventPageURL — URL to the metric details page in the context of the alert. |
|
|
Impact |
Severity |
|
|
Manufacturer |
Blank |
|
|
Product_Categorization_Tier_1 |
Blank |
|
|
Product_Categorization_Tier_2 |
Blank |
|
|
Product_Categorization_Tier_3 |
Blank |
|
|
Product_Model_Version |
Blank |
|
|
Product_Name |
Blank |
|
|
Reported_Source |
"Systems Management" * |
|
|
Resolution |
Blank |
|
|
Resolution_Category |
Blank |
|
|
Resolution_Category_Tier_2 |
Blank |
|
|
Resolution_Category_Tier_3 |
Blank |
|
|
Resolution_Method |
Blank |
|
|
Service_Type |
"Infrastructure Event" * |
|
|
Status |
New * |
|
|
Urgency |
Severity |
|
|
Action |
"MODIFY" * |
|
|
Work_Info_Summary |
Message |
|
|
Work_Info_Notes |
Message, Severity |
|
|
Work_Info_Type |
"Incident Task/Action" * |
|
|
Work_Info_Date |
Blank |
|
|
Work_Info_Source |
"System Assignment" * |
|
|
Work_Info_Locked |
Blank |
|
|
Work_Info_View_Access |
"Public" * |
|
|
Incident_Number |
TicketId — The connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated. |
In the tables, * denotes a literal string and ** indicates if the attribute applies.
Table 3-5 Ticket Updates (Remedy_DefaultCategory_AutoClose.xsl)
| Remedy Ticket Attributes | Enterprise Manager Alert Attributes | Value |
|---|---|---|
|
Categorization_Tier_1 |
Blank |
|
|
Categorization_Tier_2 |
Blank |
|
|
Categorization_Tier_3 |
Blank |
|
|
Closure_Manufacturer |
Blank |
|
|
Closure_Product_Category_Tier1 |
Blank |
|
|
Closure_Product_Category_Tier2 |
Blank |
|
|
Closure_Product_Category_Tier3 |
Blank |
|
|
Closure_Product_Model_Version |
Blank |
|
|
Closure_Product_Name |
Blank |
|
|
Company |
"Internal" * |
|
|
Summary |
Message |
|
|
Notes |
EMUser — Notification rule owner when the ticket is created through auto-ticketing, and is the Enterprise Manager log-in user when the ticket is created through manual-ticketing. TargetName TargetType MetricColumn — Name of the metric, such as CPU Utilization (%). MetricName — Category of the metric. For the CPU Utilization (%) metric, this would be 'Load.' KeyColumn ** — For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyColumn is 'Tablespace Name.' KeyValues ** — For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity. Severity CollectionTime TargetHost NotificationRuleName EventPageURL — URL to the metric details page in the context of the alert. |
|
|
Impact |
Severity |
|
|
Manufacturer |
Blank |
|
|
Product_Categorization_Tier_1 |
Blank |
|
|
Product_Categorization_Tier_2 |
Blank |
|
|
Product_Categorization_Tier_3 |
Blank |
|
|
Product_Model_Version |
Blank |
|
|
Product_Name |
Blank |
|
|
Reported_Source |
"Systems Management" * |
|
|
Resolution |
Blank |
|
|
Resolution_Category |
Blank |
|
|
Resolution_Category_Tier_2 |
Blank |
|
|
Resolution_Category_Tier_3 |
Blank |
|
|
Resolution_Method |
Blank |
|
|
Service_Type |
"Infrastructure Event" * |
|
|
Status |
If the grace period test has already been done and the alert is still within the grace period, reopen the ticket by setting the ticket to the Assigned status. Otherwise, set the status Assigned. |
|
|
Urgency |
Severity |
|
|
Action |
"MODIFY" * |
|
|
Work_Info_Summary |
Message |
|
|
Work_Info_Notes |
Message, Severity |
|
|
Work_Info_Type |
"Incident Task/Action" * |
|
|
Work_Info_Date |
Blank |
|
|
Work_Info_Source |
"System Assignment" * |
|
|
Work_Info_Locked |
"No" * |
|
|
Work_Info_View_Access |
"Public" * |
|
|
Incident_Number |
TicketId — The connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated. |
If the out-of-box ticket templates do not satisfy your requirements, you can modify them. To do this, Oracle recommends that you use one of the existing templates as the base template. Copy this ticket template to a new file, modify, and register the new ticket template.
In most cases, when you modify the ticket template, you might only be changing the mappings. The following examples illustrate this point:
Example 3-3 Creating a Template to Mark the <Company/> Element to MyCompany
To create a template to mark the category to MyCompany, modify the following attribute in the template:
<urn:Company>MyCompany</urn:Company>
Example 3-4 Altering the Message Type
If you only want the alert message to appear as ticket summary instead of both message and severity, modify the following attribute:
<urn:Summary><xsl:value-of select="ns0:Message"/></urn:Summary>
The templates are highly customizable. Oracle recommends that only users with advanced knowledge of XSLT make complex changes.
You can use notification rules as a filter to associate proper ticket templates with alerts. You can have as many tickets templates as you want. One notification rule can have only one ticket template.
The out-of-box templates are based on the default HPD:IncidentInterface_Create,HPD:IncidentInterface forms. If the new ticket templates you define are based on these forms, Customizing Ticket Templates applies.
However, if you use a different form, you need to define a new ticket template.
Table 3–6 provides the Enterprise Manager fields that you can map when using the default Remedy Service Desk Web services:
Table 3-6 Enterprise Manager Attributes
| Data Fields | Description |
|---|---|
|
EMUser |
|
|
HDUser |
Service Desk user registered with the Connector; this is the same as the user name specified for the WS authentication. |
|
TicketID |
Identifies the ticket associated with the current alert (available after ticket creation). |
|
ConnectorID |
Identifies the connector that processed the event and issued the ticket creation or ticket update. This is the ID for the Remedy Service Desk Connector. |
|
TargetType |
Type of target that the alert is associated with, such as |
|
TargetName |
Name of the target that the alert is associated with. For example, |
|
MetricColumn |
Name of the metric that triggered the alert. For example, CPU Utilization(%). |
|
MetricName |
Category of the metric. For example, |
|
KeyColumn |
For metrics that monitor a set of objects, the KeyColumn indicates the type of object monitored. For example, for the Tablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name'. |
|
KeyValues |
Key values associated with a key value base alert. For metrics that monitor a set of objects, the KeyValues indicates the specific object that triggered the severity. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity. |
|
Message |
Description of the alert. For example, CPU Utilization is 100%, crossed warning (80) or critical (95) threshold. |
|
Severity |
Severity of the alert: |
|
CollectionTime |
Timestamp of an alert occurrence. |
|
EventPageURL |
URL to the alert details page of the alert. |
|
NotificationRuleName |
Name of the notification rule that generated the notification during auto-ticketing. |
|
TargetTimezone |
Timezone of the target associated with the alert. |
|
GracePeriodCheckMade |
Value |
|
TargetHost |
Name of the server hosting the target that generated the alert. |
Format for Creating Ticket Templates
To create ticket templates for custom Remedy forms, adhere to the following format:
<?xml version='1.0' encoding='UTF-8'?> <xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ns0="http://xmlns.oracle.com/sysman/connector/tt" targetNamespace="http://xmlns.oracle.com/sysman/connector/tt" elementFormDefault="qualified"> <!-- This template creates an incident type ticket with default categorization (Category: Default, Type:Default, Item:Default), and low priority. On update, the description and message fields are updated, and the ticket is closed if the associated alert has cleared. --> <xsl:template match="ns0:EventModel"> <xsl:choose> <xsl:when test="normalize-space(ns0:TicketId) = ''"> *[Insert your mappings from EMModel into your custom Create Ticket Webservice SOAP Document] * </xsl:when> <xsl:otherwise> * [Insert your mappings from EMModel schema into your Custom Update Ticket Webservice SOAP Document]* </xsl:otherwise> </xsl:choose> </xsl:template> </xsl:transform>
Follow the instructions provided in this section if you choose HTTPS as the protocol to establish a connection between the Remedy AR server and Enterprise Manager.
Generate a certificate request file for the Remedy AR server and send it to the Certificate authority, such as VeriSign.
Note:
The certificate request file is dependent on the Web server that Remedy uses.After you get the certificate, import it to the Web server that Remedy uses. The import mechanism varies depending on the Web server that the Remedy Service Desk uses.
Note:
Oracle Wallet Manager is available at$ORACLE_HOME/bin on OMS. See the Oracle Application Server Administrator's Guide for details.Do the following on Enterprise Manager:
As Super Administrator, create a wallet using the following orapki utility command at the OMS host:
orapki wallet create -wallet client -auto_login
Note:
orapki is available at $ORACLE_HOME/bin on OMS.Add the trusted certificate to the wallet by entering the following command:
orapki wallet add -wallet client -trusted_cert -cert verisignCert.cer
To view the content of the wallet, enter the following command:
orapki wallet display -wallet client
Ensure that ewallet.p12 is available.
In Oracle Wallet Manager, open the client certificate ewallet.p12.
Go to Select Trusted Certificates and select Operations on the main menu.
Select Export All Trusted Certificates.
Save the file as certdb.txt.
Place the file certdb.txt in the connector home root directory ($OMS_HOME/sysman/connector).
If the file certdb.txt already exists in the root directory, open the file and add the contents of your certdb.txt to the existing content.
You need to import HelpDesk_Query_Service_getIncident.def into your Remedy instance for a getTicket operation. By default on the Enterprise Manager Management Connector page, the web service endpoint for getTicket appears as HPD_IncidentInterface_get_WS. If you are not importing HelpDesk_Query_Service_getIncident.def, you need to modify the web service name in the web service endpoint with your custom web service name.
If you want to use the Remedy_DefaultCategory_AutoResolve.xsl template, you need to import HPD_IncidentInterface_CustomWS.def. Back up the HPD_IncidentInterface_WS web service before importing. You can get this file from the $ORACLE_HOME/sysman/connector/Remedy_Service_Desk_Connector directory.
Now Java SSL can use this file for communication between Enterprise Manager and the Remedy AR server in HTTPS mode.
See Also:
For information on creating a wallet, see "Creating and Viewing Oracle Wallets with orapki" in the Oracle Database Advanced Security Administrator's Guide, 10g Release 2 (10.2).This section provides various tips that might help you to use Remedy Service Desk Connector effectively.
Oracle recommends that you use HTTPS as the protocol for the communication between Enterprise Manager and Remedy AR server.
Use HTTP only if a secure connection is not required and the data can be transferred in clear text between the two systems.
|
 Copyright © 2008, Oracle. All rights reserved. Legal Notices |
|