Opalis 6.3: Getting Started with the Service Manager Integration Pack
Overview
If you are going to work with System Center Service Manager via the Opalis Service Manager Integration Pack, then you had better learn how to interact with Service Manager Activities.
But what exactly is an Activity? There exists some confusing terminology that we need to resolve before we go any further into this topic. In Opalis a workflow icon in the Designer used to be named an “Object” (and in fact the docs and the GUI still use this terminology). However, since the acquisition the term “Activity” seems to have gained favor as a name for these pre-programmed goodies. So, for example, the Opalis Service Manager Integration Pack contains 13 “Opalis Workflow Activities” as shown below:
Where things get confusing is that Service Manager also has a construct referred to as an “Activity” and wouldn’t you know it… it’s important you know how these work with Opalis “Workflow Activities”. These “Work Item Activities” are a key part of Service Manager because they define the actual work that gets done as a standard IT process is carried out… by people or automation. “Work Item Activities” can be seen in a few places in the Service Manager GUI. Here is a screen capture of two Work Item Activities that are part of a parent Change Request Work Item.
Notice how the Work Item Activities are sequenced (0,1,2,3..). This defines the order in which this work is to be carried out. In the example just provided, Sequence 0 is a “Review Activity” that gets approval to provision a VM while sequence “1” is the actual provisioning step itself.
From this point forward I’ll use the following naming convention:
| Activity Type | Terminology in Blog Post |
| Opalis Workflow Activity | “Workflow Activity” |
| Service Manager Activity | “Work Item Activity” |
Well, now that we have that out of the way let me explain why this is so important. Work Item Activities are sort of the “Launching Point” for work that needs to be done. That work could be an approval (done via a Service Manager Work Item Review Activity) or perhaps a Work Item Manual Activity if human interaction is required. Also, one can create custom Work Item Activities in Service Manager using the Service Manager Authoring Interface. As far as Opalis is concerned, being able to run automation against Work Item Activities is key because it defines how Opalis is to run automation in the context of the process it supports.
Additionally, when a process needs to change (as they invariably do from time to time) one doesn’t want to have to edit an Opalis workflow. All one has to do is change the required sequence of activities. You don’t want the Work Item Review Activity (an approval step) in your workflow? No problem. Remove and and the Opalis workflow won’t wait on an approval to kick off. This means that changes in process can be performed by a non-IT Pro person… perhaps a process administrator working in Service Manager.
This approach also encourages customers to think in terms of building an “automation library” of Opalis workflows that map to Service Manager Work Item Activities. The more of these you build the more automated your IT process become. Then when new processes are developed all one has to do is draw from the pool of Service Manager Work Item Activities. Said another way, when a “process person” builds out a new Change Request Template in Service Manager they don’t have to worry about mapping Work Item Activities to Opalis workflows. They just build out the Change Request Template drawing from the pool of available Service Manager Work Item Activities… some of which will trigger Opalis workflows. Every process they build is automatically optimized to make use of the pool of available automation in Opalis!
Very cool…
So how does this all work?
A Change Request in Service Manager is a great way to start. I won’t go into details on how one authors a Change Request in Service Manager… but I recognize how uninspiring it is for me to say this. So I would ask that you take the time to watch a brief video Travis Wright (from the System Center Service Manager team) and I recorded at TechEd EMEA in November of 2010. Now when you watch this remember that Travis and I had a LONG day, but the point we make here is pretty solid. Watch the first part of the video until Travis passes the demo to me and then hit the PAUSE…
So once one know something they want to automate they simply create a Service Manager Work Item Activity Class that provides a place for the data needed by an Opalis workflow. Then the authoring in Opalis begins. Resume the video and watch the rest of the presentation (comical moment and all) for an example of the remaining steps. Rather than focus on this specific workflow, however, I want to show the key pieces of how interaction of the workflow with Service Manager is facilitated.
It all starts with a “Monitor Object” Workflow Activity in Opalis:
“Monitor Object” allows for an Opalis workflow author to watch Service Manager for new or updated records that match a given filter condition. In the example shown below we are watching for a Service Manager Work Item Activity to change state to “In Progress” (hence Updated is checked). Notice how “Class” is a custom Work Item Activity Class in Service Manager… this is the class created to trigger the Opalis workflow. So we really are doing an extra layer of filtering by selecting the “Class” to match the Work Item Activity class we created to trigger this automation.
The “trick” here is understanding how the Monitor works. Basically it’s a poller with a filter and ANY object in Service Manager that satisfies the filter condition will trigger the monitor. So we need a way to “gate out” future requests that match the conditions specified in the filter. Otherwise we might wind up re-processing objects that are currently processing! This can easily be done using link-level logic in Opalis. All one has to do is set a property in Service Manager that indicates the Opalis is working with the request. In this example I choose the “Stage” property and set it to “Initiate” when I start processing. If I do this then I know any Work Item Activity that triggers the workflow should NOT have “Stage” = “Initiate”. So I just filter any such triggers out using link-level logic as shown below:
Changing properties in any given Work Item Activity is very simply. There is a specific Workflow Activity just for this purpose called “Update Activity”:
This Workflow Activity in Opalis allows one to select a Work Item Activity Class in Service Manager, and update properties (such as “Status” or “Stage”) to values you select. Information (such as the GUID of the object one wants to update in Service Manager) are generally provided via downstream Opalis Workflow Activities via a Published Data subscription:
In a similar fashion, one can “Get” the contents of a Work Item Activity (if you know it’s GUID, which again one would get via Published Data subscription).
This would typically be needed only if there was a change in the Work Item and the information on the Opalis databus needed to be refreshed.
There is one final point worth noting. Frequently one needs to be able to get to a parent of a Work Item Activity. Remember at the start of this blog post that I showed a Change Request with two Work Item Activities it contained? Well, what if we needed to update the parent Change Request? In the video whose link I offered earlier you can actually watch (near the end of the recording) how I query Service Manager to get this information. Basically, there is a Workflow Activity in Opalis called “Get Relationship” that has a great many uses… and finding the parent of a Work Item Activity is one of them..
This Workflow Activity asks for a parent Object Class and the class that is “Related” to it. For example, we want to find all the “Change Requests” related to “Automatically Provision VM” in Service Manager. The Workflow Activity returns the parent and child classes as well as their GUIDs so one can then query using the GUID.
Did you notice how “Update Activity” and “Get Activity” could probably be replaced by “Update Object” and “Get Object” in your workflow? That’s right! The “Get Object” and “Update Object” are very generic Workflow Activities. Other Workflow Activities (such as “Get Relationship”, “Update Activity” and “Get Activity”) are specifically defined to support a given function. In this case because Activity Management is so important we made a separate set of Workflow Activities (with custom icons, etc) to underscore this importance to workflow authors. There is no wrong way and if you have built your workflows using the generic Workflow Activities that’s fine… just remember that in the future we’ll no doubt be looking at adding additional Specific Activities and your suggestions are very welcome!