Opalis 6.3: System Center Service Manager Cross Service-Desk Interoperability

It’s only natural that a new Service Desk solution should have to interoperate with an existing Service Desk solution. The reason for this should be pretty obvious: Everyone in IT uses the Service Desk pretty much every day. So migrating is bound to present certain challenges as a new, modern system is built out and the older legacy system is spun down.

The traditional approach of addressing this change has been to build out the new system and then gradually migrate users off of the old system. However, IT processes don’t necessarily divide themselves up cleanly around people boundaries. For example, it’s not impossible to imagine a scenario where a user is an approver of a change in the old system but they have already moved to the new system. The solution has been to simple keep two solutions side-by-side on the desktop.

…and that approach brings into play a very old and sadly still prevalent integration mechanism: Copy/Paste between multiple windows.

Of course there are other scenarios other than migration where interoperability with an existing Service Desk might be involved. It’s not uncommon for large companies to have different Service Desk solutions (or even very primitive Trouble Ticket platforms that aren’t Service Desk solutions in the strictest sense) in use at the same time by different departments. Obvious issues with this type of solution aside, one big problem is how to integrate these platforms to support processes that span silos in IT.

…traditionally the way this is done is another old and sadly still prevalent integration mechanism: People talking on the phone, emails, etc.

Opalis and the Integration Pack for System Center Service Manager provides a great deal of capability in terms of addressing these challenges. Opalis features a publish/subscribe databus and this means that any system integrated with Opalis is likewise integrated at a data-level with any other solution integrated with Opalis. 

So let’s start with the Service Manager end of the connection. The Service Manager Integration pack consists of 13 workflow activities designed to interact with Service Manager and it’s related CMDB… by the way, there are other blog posts where the topic of CMDB automation is discussed in detail. These workflow activates work with the extensive “Foundation Activity Library” to provide a rich environment for building workflows that interact with Service Manager as well as other systems.

So what about the other end of the connection? Well, Opalis offers 20+ Integration Packs for 3rd party systems such as software from Hewlett-Packard, BMC, EMC, IBM, etc. The Integration Packs for these systems are likewise integrated with the Opalis databus so they can interoperate with the workflow activities for System Center Service Manager.

Let’s take a look at the workflow activities that are present in the BMC Remedy and BMC Atrium Integration Packs. These are separate Integration Packs in Opalis and must be individually loaded, but taken as a whole they allow an Opalis workflow author to interact with records in BMC Remedy ARS and the BMC Atrium CMDB.

Notice a similarity? Most Service Desk Integration Packs have like features in terms of their high-level functions. Most permit one to query/get/update/monitor records/objects. Most permit some level of interaction with the CMDB and CI object relationships. Note that with the Service Manager Integration Pack the query/get/update/monitor actions are built-into the generic workflow activities… there isn’t a separate Integration Pack for the CMDB as there is for BMC Atrium.

What Service Desk solutions does Opalis support? Like functionality to the System Center Service Manager Integration Pack is also available for CA USD, HP Service Manager, and HP Service Desk (now retired) as well as BMC Remedy/Atrium. So there is a very real opportunity to interoperate between Microsoft System Center Service Manager and these systems via Opalis.

What if your Service Desk solution isn’t on the list? What if you have a custom solution or a very old “trouble ticket” style solution you badly want to get rid of but can’t… even though the company that made it closed up shop a decade ago (believe it or not I have seen this scenario more than once)? Well there is hope because like I said, Opalis includes a “Foundation Activity Library” where more industry-standard integration mechanisms can be found: Database queries, web services, text files, etc. So look closely at your interop scenarios and see if there are ways to interact with your system using one of these mechanisms. It’s sometimes a shock to see how much you can do with very simple things.

Let’s look at the BMC Remedy Integration Pack and look at some workflow scenarios.

Here is a very simple scenario:

On a scheduled basis this would get a list of CIs from the BMC Atrium CMDB and create like objects in the System Center Service Manager CMDB. The data would be mapped using publish/subscribe links in the workflow. Notice how the workflow updates the CI in BMC Atrium to indicate that it’s been copied into Service Manager. This is so one can “tag” a CI in BMC Atrium so you don’t copy it again the next time the workflow is run. It’s really that simple.

How would you deal with a situation where you had different field values in the two solutions? for example, what if you had a field that read “Small”, “Medium” and “Large” and you wanted these CI attributes to read “Little”, “Moderate” and “Huge” in the Service Manager CMDB. There is a special Workflow Activity called “Map Published Data” that does just this:

This workflow activity takes as input a piece of published data and maps it to a lookup table. It them produces a new piece of published data that, using a published data subscription, can map the data into the new system. So our earlier “Small”, “Medium” and “Large” scenario looks something like this:

Pretty simple… now you know how to use the Opalis Integration Pack for System Center Service Manager to interact with Service Desk Objects, CIs and Relationships as well as map data into other Service Desk solutions. In some cases it may well take your time to document and understand the process than it will to implement the interop scenario!

By the way, if you are interested in CMDB automation as an expanded topic I have another blog post you can read: Opalis 6.3- CMDB Automation with System Center Service Manager and Opalis