Automation – Orchestrator Back to Basics – Use Cases Spotlight (4 of 5)

This is post #4 out of 5 in the “Orchestrator – Back to Basics – Use Cases” series, full series posts are located here:

• #1 : Alert Remediation, where automation is used to monitor specific situations, and react automatically. This is also the introduction post to the series.
• #2 : Maintenance tasks, where recurring tasks are being handled in a consistent and automated manner, triggered manually or when a specific condition is met
• #3 : Provisioning and Change Management Automation, where automation handles backend processing or user requests from a service catalog or any provisioning process worth automating in your context
• #4 : Cross-technology integration . Here automation can be used to integrate otherwise silo’d technologies, or help in better together and migration scenarios (integrate a monitoring solution to a manager of manager, or into a ticketing solution) (this post!)
• #5 : “Miscellaneous” scenarios, like dynamic resource allocation, and new user onboarding as examples

Use Case #4 : Cross-technology integration

This post will demonstrate how automation can help integrate multiple technologies together in IT organizations. This is particularly needed in situations like these:

• When the solutions need to participate in a common end to end process, such as sending alerts to create tickets
• When the solutions need to participate In the same process, such as using two monitoring solutions, with one acting as the manager of manager and receiving alerts from the first one. It could be a temporary situation while moving to a single monitoring solution, or it could be more of a long term situation, if the “ outbound” monitoring solution has proven its value and will keep feeding into the manager of manager’s existing processes.

Scenario #1 : Simple ticketing connector

This example showcases what a simple Operations Manager to Service Manager connector would look like. This is really for illustration purposes, as a connector between these two specific components already exists out of the box! But the same principles would apply if you wanted to create a ticketing connector to BMC Remedy or ServiceNow.

3 Runbooks can be used to handle simple connectivity between the two systems:

• Runbook waiting for new alerts in Operations Manager to create tickets in Service Manager

Looking more closely at this Runbook, we can see how each activity is being configured:

Only new alerts are being monitored, and in this case we chose to only create tickets on critical alerts. A common alternative is to filter on a custom field, named “Send to ticketing” for example (Operators can right-click on alerts in Operations Manager, and update this field. The Runbook would then pick up the alert and create the ticket).

The second activity “converts” fields between the two systems, based on their default naming or on the alert properties. In this example, the incident impact is derived from the alert severity, and the urgency depends on the source environment (based on the domain name). Again, these are just examples.

The ticket (incident) is then created. Since Service Manager has a specific class for Operations Manager-incident, we use this one to benefit from out of box views.

Finally, the Runbook “tags” the OM alert with the ID of the ticket which was just created. This will be useful in the two other Runbooks, when we need to update the alert of the ticket.

• Runbook waiting for closed alerts in Operations Manager to update tickets already forwarded to Service Manager – This is not something all organizations want, as technically closing an alert might be different than closing the associated incident from an ITIL process perspective.

More specifically, this Runbook monitors alerts updated to a closed state:

Using the “TicketID” property from the alert, it finds the right incident and updates it to a resolved state:

• Runbook waiting for closed tickets in Service Manager, to close the associated alert in Operations Manager as well – This is the “bidirectionnal connector” approach, that most organizations are generally looking for.

Looking more closely, this Runbook is just monitoring recently resolved Operations Manager-generated incidents, and then finds the associated Operations Manager alert to close it.

Note : This last Runbook is monitoring closed incidents, assuming it’s only at this stage that we may want to close the alert in Operations Manager. Depending on how you implement ITIL processes, you might want to monitor resolved incidents instead. This is an easy change in the first activity of the Runbook. Only other change you might have to do is update an additional property when incidents are resolved by the second Runbook (to avoid a situation where the second Runbook sets an incident to a resolved state, and triggers the third Runbook!)

Scenario #2 : Advanced manager of manager connector

For this example, we will now look at a connection between System Center Operations Manager and IBM NetCool. A base connector could be built using the method defined in Use Case #1, and using the Operations Manager and NetCool integration packs, both available as a download on the Microsoft website.

Now, while the previous set of three Runbooks can theorically work, implementing it will quickly raise questions like these:

• Will I lose alerts if my NetCool server is not responding to new/updates alerts requests, or if the Operations Manager server is not processing bidirectionnal alert resolution?
• Will I lose alerts if my NetCool server is not processing imcoming requests quickly enough (alert storm)?

Well, the previous Runbooks could be enhanced to handle these additional requirements, and here is an example for the “new outbound alert” (first Runbook in Use Case #1 earlier in this post)

We could now have a first Runbook monitoring new and updated alerts in Operations Manager, and storing them in a custom database:

And then a second Runbook can query this custom database and attempt to successively create/update alerts in two NetCool servers (a primary and secondary).

Finally, a third Runbook – not represented here - could do some daily/weekly cleanup in the custom database.

Another item not represented here is the mapping between Operations Manager and NetCool alert properties. This could happen with “Map Published Data” activities, just like we did in Use Case #1. In reality, the mapping would likely be a subroutine (child runbook), as it grows to match your needs, and as it handles exception (like management packs properties that are potentially different from one MP to another).

I hope these screenshots gave you an idea how far you could go in making these connectors more bullet proof. You may or may not require all these features depending on your needs. On a side note, should you require fully baked connector Runbooks including features like database and high availability, it’s worth noting that our partner Kelverion provides such a solution.

• Previous post in the series : #3 : Provisioning and Change Management Automation, where automation handles backend processing or user requests from a service catalog or any provisioning process worth automating in your context
• Next post in the series : #5 : “Miscellaneous” scenarios, like dynamic resource allocation, and new user onboarding as examples