Integrating OMi (Operations Manager i) with ServiceNow

We have delivered Micro Focus solutions and migrated "Operations Manager for Windows" (OMW) to the innovative new OMi for a number of customers. In most of these cases, the requirement was also to integrate ServiceNow—a request that has been growing in popularity. In each case where JDS has provided OMi to ServiceNow integration, it has proven successful and satisfying for our customers.
OMi has been tested over time, built on a firm foundation. It is robust in design and suitable for every known event and service model situation possible. The possibilities are endless and the GUI is customisable—and as for the designs provided out-of-the-box, they are a fully featured event and service model, driven to work well from the operations and support personnel perspectives.
The integration with ServiceNow is relatively straightforward and simple. It requires a little groovy script programming knowledge. Generally speaking, someone who has an intermediate breadth in JavaScripting can sufficiently develop a connector script. The script is set under the Connected Servers option in the managed scripts.
There are some examples provided; one in particular is the "LogFile Adapter", and with the use of the OMi extensibility guide, these examples can easily translate into useful real-world cases.
You will need to create an account in ServiceNow and enable the "Web service access" role to be allowed to make Web service API protocol calls. Additionally, you will need an account in OMi in order for ServiceNow to interact with OMi WebServices.
Once the OMi connected server to ServiceNow is enabled, Event Forwarding rules can be tailored to use simple event filtering. These filters are used to select and automate events for forwarding and synchronisation with the Connected Server. As an additional option, the integration allows you to right-click on an event and manually transfer it to ServiceNow for incident creation and synchronisation.
With this sample filter shown here, the selection is made when an event matches the filter as a critical event with any lifecycle state that has the priority either set to highest, high, or unknown will be forwarded.
In ServiceNow, it's good practice to have an import table where a transformation map is executed, thereby transforming the forwarded event values to matching values in the ServiceNow incident table. A ServiceNow Business Rule can also be applied to further shape the event data before it's inserted into the incident table.
An example of an import table containing the event data fields we want to transform is below:
Here is an example of a transformation map source field for “description”. The target is set for the incident table to match on the target field “description”.
The incident table can be modified to include the OMi event ID field and be transformed similarly as the description example as shown above. This is important so that the incident can be identified easily as originating from OMi. A Business Rule can check for this field if it contains a GUID value. If an event ID GUID exists in the incident omi_id field, the Business Rule advanced actions can be triggered based on the conditions to sync any changes to the incident back to the event in OMi.
The change of the incident Status, Priority, Assigned to, Description, Cause, Work Notes (Annotation), etc. can match that from the ServiceNow incident back to the event’s fields in OMi.
Once the incident in ServiceNow is closed, a Business Rule can trigger the closure of the event and provide:
- The Work Notes to the event annotation
- Resolution notes to the solutions field
- Resolution code to the description field back to the event in OMi
In ServiceNow, when we solve the incident and close it, the incident that was created by the OMi integration will then note the state is set to Closed.
The incident Work Notes are required each time an update to the incident is made and are also added.
Upon incident closure, you are required to populate the incident resolution fields.
After the operator submits and updates the incident, the Business Rule for an OMi generated incident is triggered to then sync the incident details back to the Event and closes it.
The event is closed by an outgoing WebService request from ServiceNow Business Rule that call a REST Message with an xml payload in a REST POST to OMi.
The Solution here is updated by the incident’s resolution information.
Event annotation is updated by the incident’s Work Notes.
Event history details showing the flow of updates to the event that occurred.
In summary, keeping the event in sync with ServiceNow ticketing system is relatively simple. OMi can forward events to an external event processing server via Connected Servers. This clearly makes integrating event management systems with ticketing systems an all-round solid solution to tracking events and incidents. Some JavaScripting is required, along with an in-depth OMi and ServiceNow product knowledge.
JDS has several consultants on the team with this combination of skills and knowledge, and we would be happy to discuss implementing a similar solution for your organisation at any time.
Our team on the case
Tech tips from JDS

What is the difference between a Vulnerability Scan and a Penetration Test?
Read More

Manual Security Testing vs Automated Scanning?
Read More

Five Reasons Why Your Organisation Should Be Penetration Testing
Read More

Mastering Modal Dialog Boxes
Read More

Understanding your Customer Journeys in Salesforce with AppDynamics
JDS Australia works with numerous customers who utilise the force.com platform as the primary interface for their end users ...
Read More

Implementing Salesforce monitoring in Splunk
Read More

Browser Console
Read More

Glide Variables
Read More

Understanding Database Indexes in ServiceNow
Read More

Fast-track ServiceNow upgrades with Automated Testing Framework (ATF)
Read More

ServiceNow Catalog Client Scripts: G_Form Clear Values
Read More

Is DevPerfOps a thing?
Read More

Monitoring Atlassian Suite with AppDynamics
Read More

5 quick tips for customising your SAP data in Splunk
Read More

How to maintain versatility throughout your SAP lifecycle
Read More

How to revitalise your performance testing in SAP
Read More

How to effectively manage your CMDB in ServiceNow
Read More

ServiceNow and single sign-on
Read More

How to customise the ServiceNow Service Portal
Read More

Integrating a hand-signed signature to an Incident Form in ServiceNow
Read More

Integrating OMi (Operations Manager i) with ServiceNow
Read More

Implementing an electronic signature in ALM
Read More

Service portal simplicity
Read More

Static Variables and Pointers in ServiceNow
Read More

Citrix and web client engagement on an Enterprise system
Read More

Understanding outbound web services in ServiceNow
Read More

How to record Angular JS Single Page Applications (SPA)
Read More

Calculating Pacing for Performance Tests
Read More

Vugen and GitHub Integration
Read More

Filtered Reference Fields in ServiceNow
Read More

ServiceNow performance testing tips
Read More

Monitor Dell Foglight Topology Churn with Splunk
Read More

Straight-Through Processing with ServiceNow
Read More

Splunk: Using Regex to Simplify Your Data
Read More

ServiceNow Choice List Dependencies
Read More

Recycle Bin for Quality Center
Read More

Agile Performance Tuning with HP Diagnostics
Read More

Understanding LoadRunner Virtual User Days (VUDs)
Read More

Problems recording HTTPS with VuGen
Read More

Generating custom reports with Quality Center OTA using Python
Read More

Asynchronous Communication: Scripting For Cognos
Read More

How to fix common VuGen recording problems
Read More