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.