Opalis 6.3: CMDB Automation with System Center Service Manager and Opalis
You shouldn’t be shocked to discover that System Center Service Manager has a CMDB. A CMDB is at the beating heart of any Service Desk solution… a very basic definition of Change Management is the process which maintains the CMDB. Service Manager provides for various ways one can build an initial set of data in the CMDB and maintain this information over time as part of standard IT processes. This includes connectors between Service Manager and Configuration Manager, Operations Manager and/or Active Directory. Customers that own these solutions can literally be up and running with a rich and self-sustaining CMDB in a matter of minutes.
…but that’s not the end of the story. It’s just the beginning. That’s because Opalis provides for extensive CMDB automation via the System Center Service Manager Integration Pack. It can easily support the following scenarios:
- Periodic import of data (from a variety of sources) into the Service Manager CMDB.
- Updating of the CMDB as part of a Change Request. Example: Adding/updating a CI when a new Hyper-V VM is provisioned.
- Performing queries of the CMDB to support sophisticated processes. Example: Finding all VM CIs > 30 days so they can be retired.
- Querying for relationships in the CMDB to support sophisticated processes. Example: Show me all the open Incidents associated with a Business Service CI.
Now clearly some (not all) of these functions can be performed in the Service Manager GUI itself, which is great. The focus in Opalis is on making this available to automation as well. So when a workflow author is building a workflow and needs CMDB information about CIs or Relationships between CIs that information is at their fingertips.
The Opalis System Center Service Manager Integration Pack has a handful of Workflow Activities that can manipulate Service Manager CI Objects and Relationships in the CMDB.
Create/Get/Update allow a Workflow Author to create/query/update CI Objects and their properties. This works for both the “out of the box” standard CI objects as well as objects created by custom classes one might add to Service Manager via a custom MP authored in the Service Manger Authoring interface.
“Monitor Object” likewise works against any class for a CI in the CMDB. It enables you to watch for new or updated CIs and trigger an Opalis workflow. For example, you could monitor the Windows Computer Class for new VMs and run a custom process to interact with them and collect data from to augment the CI record. The possibilities are endless… well perhaps not endless but you get the point.
A CMDB is more than just CI records… it’s also a collection of relationships. The Integration Pack provides three ways to interact with Relationships: Get Relationship, Create Relationship and Delete Relationship that can be used to query/create/remove relationships between CIs.
In particular, “Get Relationship” is super useful because it permits you to query the CMDB to understand how CIs relate to one another. For example, one could query for all the Windows Computer CIs related to a given Change Request. The “Get Relationship” activity would provide a relationship GUID (or multiple GUIDS if there were more than one relationship) to all the related objects. This means one can essentially understand how the CMDB is laid out as you process changes in Opalis workflows.
So let’s create a simple workflow that automates importing CI data into the CMDB.
This workflow would take a file (such as a CSV file) and on regular basis defined by “Monitor Date/Time” parse this data via a “Map Published Data” activity. The resulting data is populated into a Service Manager CMDB CI and a relationship is build connecting the new CI to a parent CI.
The data source is actually irrelevant. It simply needs to be mapped into a format meaningful for the CMDB. For example, suppose the data existed in a Web Service somewhere on the Internet rather than a text file. The resulting workflow would be strikingly similar:
Notice the same basic structure? However, rather than parsing a text file a SOAP based web service is queried, an XSLT style sheet is applied to the output data, an XML XPath query is performed to extract data from the transformed XML. Again, the data is mapped so it’s more meaningful to the CMDB and the resulting objects/relationships are created.
The CMDB can also be used as a data source to support processes. For example, the workflow below is used to check the CMDB for expired VMs, save them off and update the CI record to indicate the VM has been retired:
Notice how the CMDB query is easy to compose and produces a list that is parsed to every downstream workflow activity. The Opalis databus supports multi-value data, so if the “Get Expired VM List” workflow activity returned 30 VMs then the downstream workflow activities would run once for each VM (unless the list was filtered by link-level logic… very powerful).
All taken into consideration, the combination of the Service Manager Connectors plus Opals and the Integration Pack for Service Manager make for a compelling combination. Imagine a world where integrating with your Service Desk is a skill within reach of an IT Pro and not a programmer…