Import downtime data from an external source

If business management solutions (such as Service Manager, OM, or third party software) create downtime events when integrating with OMi, you may need to import downtime information from an external system. To import this downtime information, create a middle utility using the REST API to pull the events from the external source and post them to OMi.

When importing definitions from an external source, take into account both the import scope and mechanism.

Import Scope

Downtime properties may be different in different systems and software platforms. The common set of downtime properties includes scheduling information and configuration items. In OMi downtime, the mandatory fields are:

• Downtime Name
• CI ID
• Schedule
• Action

Imported events must be translated to match OMi downtime properties.

Import Mechanism

Importing downtimes into OMi is performed by an external utility with access to the formats and properties of the external source. This utility translates the external properties to correlate to the required and optional OMi downtime properties in XML format.

Import Example

The DTImport.zip file provides an example utility created using Java and Groovy in conjunction with the REST API.

The DTImport.zip file includes:

• DTImport.jar – Contains Java classes that run the Groovy script and provide script dependencies (mainly the HTTP client that is used to access the REST services).
• DTImport.bat – Runs the Java application and sends the OMi URL and user name and password.
• downtimeFiles folder – Contains XML files with the downtime definitions.
• DTImport.groovy – Groovy script that reads and posts the XML files to the OMi REST service.

The DTImport.bat file invokes the DTImport Java application with a defined integration folder (system property integ.home). The application reads all the Groovy scripts in the scripts folder and invokes them. The example DTImport.groovy script reads all the dt[n].xml files and uses the OMi REST service to create downtime in OMi. You can alter the contents of this file to create your own custom integrations.

Keep the following in mind when editing the file:

• To alter the logic of the utility, edit the Groovy script and run the batch file again. You do not need to build and compile the script.
• To change the integration directory, edit integ.home in the batch file.
• You can replace the DTImport.groovy script with any other script in the Scripts folder.
• Only add Groovy scripts with a main method to the Scripts folder.
• Only add well formatted XML files to the downtimeFiles folder.
• Use any scheduler (such as Windows Task Scheduler) to run the script.

To run the example:

1. Verify that the Java Runtime environment is installed on the client machine.

2. Extract the DTImport.zip file to the server on which you want to run the integration. This can be the OMi server, the external source, or any other server.

3. Edit the DTImport.bat file to update the OMi URL and credentials.

4. Edit the XML files in the downtimeFiles folder to update the downtime parameters you want to translate to match your system definitions. 

5. To enter an existing recipient ID:

   1. Enter the URL of the JMX console (https://localhost:29000) in a web browser.

   2. Enter your user name and password.

   3. Retrieve the recipient ID by executing Test Notification Service > showRecipients().

6. To enter existing CI IDs:

   1. Enter the URL of the DPS JMX console (http://<Data Processing Server name>:21212/jmx-console) in a web browser.]
   2. Enter your user name and password.
   3. Retrieve the CIIDs by executing Model Services > retrieveObjectsOfType. For example, if the CI is a Business application, enter business_application.
7. Run the batch file.