Downtime Exchange between OMi and Service Manager

Operations Manager i (OMi) enables you to forward downtimes (also known as outages) from OMi to Service Manager (SM), and from SM to OMi. The downtime defined in OMi is converted to an incident in SM, and vice versa.

Integration Overview

The downtime integration between OMi and SM includes information exchanges in both of the following directions:

• SM > OMi. When you create a downtime RfC (request for change) in SM, the RfC includes the CI that is under change and a start and end date/time of the downtime. If you do not want to waste effort with false alarms in your operations center, and do not want to have these times included in service availability reports, you can set up the integration so that these RfCs are translated to downtimes in OMi.

  In this scenario, you install a data flow probe on the CMDB:

  • If you use OMi's RTSM as CMDB, install the data flow probe provided on the OMi installation media.

  • If you use UCMDB as CMDB, install the data flow probe as described in the UCMDB documentation. In this case, the synchronization must also be done from UCMDB to OMi, additionally to synchronizing SM with UCMDB. The RfC creates a planned downtime CI in the CMDB, and the data flow probe DFP1 sends the planned downtime CI to OMi to create a downtime.

• OMi > SM. When you define downtimes using OMi , the help desk should be aware of such operational downtimes: After you set up the integration, downtimes in OMi trigger events, which create corresponding incidents in SM.

  In this scenario, when a downtime starts, OMi generates an event. Using the event forwarding mechanism, the event generates an incident in SM. When the downtime ends, an event is sent to close the downtime incident.

A single downtime can be defined on more than one CI. In the case of OMi > SM, a separate event is sent for each CI in downtime.

Prerequisites

Supported Platforms

To set up the downtime integration, you must meet the following prerequisites:

• Service Manager 9.31 and higher.

• UCMDB 10.01 or higher with content pack 12 or higher.

• Before deploying the adapter, verify that CP11 or higher is installed. If it is not, install the content pack.

• If the adapter is installed on the RTSM, and the adapter is working behind a reverse proxy, the DPS must have the correct certificates installed to send requests to the reverse proxy.

If you are using a UCMDB as a CMS, make sure that the CMS integration is set up. When it is set up, it serves as the global ID generator.

Global ID Generator

If you are using OMi's RTSM you need to configure the RTSM to be the global ID generator, to enable the downtime integration:

1. Access the following location with your browser: http://<DPS name>:21212/jmx-console/HtmlAdaptor?action=inspectMBean&name=UCMDB:service=Multiple CMDB Instances Services

2. In the setAsGlobalIdGenerator() method, fill the customerID parameter with the value of 1, and click Invoke.

Step 1: Send OMi Downtime Events to SM

To enable OMi to send downtime definitions to SM, follow these steps:

1. Access the following location in OMi:

   Administration > Setup and Maintenance > Infrastructure Settings > Foundations > Downtime

2. Change the value of the Downtime Send Event parameter to true.
3. Restart your OMi services on all Gateway Servers and Data Processing Servers.

This procedure generates events in OMi. After performing it, make sure you edit and enable the Automatically forward "downtime started" and "downtime ended" events to Trouble Ticket System event forwarding rule to forward downtime-start and downtime-end events to the SM server that should be specified in the alias connected server called "Trouble Ticket System". For details on event forwarding and connected servers, see the OMi Administration Guide.

Downtime events use the following formats:

• Downtime Start

Event field	OMi Downtime
Severity	Normal
Category	Downtime Notification
Title	Downtime for <CI Type><Affected CI Name>started at <Downtime Start Time>
Key	<OMi Downtime ID>:<Affected CI ID>:downtime-start
SubmitCloseKey	False
OutageStartTime	<Downtime Start Time>
OutageEndTime	<Downtime End Time>
CiName	<Affected CI Name>
CiId	<Affected CI Global ID>
CiHint	GUCMDB:<Affected CI Global ID>|UCMDB:<Affected CI ID>
HostHint	GUCMDB:<Related Host Global ID>|UCMDB:<Related Host ID>
EtiHint	downtime:start

• Downtime End

Event field	OMi Downtime
Severity	Normal
Category	Downtime Notification
Title	Downtime for <CI Type><Affected CI Name> ended at < Downtime End Time>
Key	<OMi Downtime ID>:<Affected CI ID>:downtime-stop
SubmitCloseKey	true
CloseKeyPattern	<OMi Downtime ID>:<Affected CI ID>:downtime-start
EtiHint	downtime:end
LogOnly	true

Step 2: Integrate SM Downtimes with OMi

To enable downtimes defined in SM to be sent to OMi, again, you need to distinguish between the two cases of where the CMDB is:

If you are using OMi's RTSM as CMDB, no further steps are required. See also Point to point integration.

If you are using an external UCMDB, you need to install the DFP2 in the OMi deployment. See also Integration using a Universal Configuration Management Database (UCMDB)

Important: 

• Following the initial integration, a large amount of data may be communicated from SM to OMi. It is highly recommended that you perform this procedure during off-hours, to prevent negative impact on system performance.

• The integration consists of two parts: SM > CMS/UCMDB, and CMS/UCMDB > OMi adapter. You should configure both parts of the integration as one flow, without a significant time lag between setting up the two parts. If you set up the SM > CMSUCMDB part, and then wait a long time before setting up the CMS/UCMDB > OMi adapter part, the number of downtimes communicated to OMi initially may be extremely high.

Create a new integration point as follows:

1. Create the integration point credentials:

   1. Access the Data Flow Probe Setup on your OMi or UCMDB depending on whether you use OMi's RTSM or use a CMS.

      Note You do not need a probe to perform this integration. Nevertheless you create credentials using the Data Flow Probe Setup tab.

   1. Click Add domain or probe, and enter a name and description of your choice.

   2. Expand the submenus and select HTTP protocol.

   3. Click the + sign (Add new connection details) and enter the OMi Gateway host name, Port 80, and the OMi username and password. Leave the Trust fields blank. When you are done, click OK to save the credentials.

2. Create a new integration point:

   1. If you have OMi, do the following on your OMi. If you use a CMS, do the following on your CMS:

      Navigate to Administration > RTSM Administration > Data Flow Management > Integration Studio

   2. Click New Integration Point, enter a name and description of your choice, and select BSMDowntimeAdapter/SM scheduled Downtime Integration into BSM.

   3. Enter the following information for the adapter: OMi Gateway hostname and port, the integration point credentials you just created, communication protocol, and the context root (if you have a non-default context root).

   4. Click OK, then click the Save button above the list of the integration points.

3. You can use the Statistics tab in the lower pane to track the number of downtimes that are created or updated. By default, the integration job runs every minute. If a job has failed, you can open the Query Status tab and double-click the failed job to see more details on the error.

   If there is an authentication error, verify the OMi credentials entered for the integration point.

   If you receive an unclear error message with error code, this generally indicates a communication problem. Check the communication with OMi. If no communication problem is found, restart the MercuryAS process.

   A failed job will be repeated until the problem is fixed.