ITIL defines a process as a structured set of activities designed to accomplish a specific set of objectives. System Center Service Manager 2012 takes this definition to heart and puts a significant emphasis on Activities. Although the topic of managing activities is not officially covered by ITIL or MOF, it is indeed a discussion we tend to always have with our clients. By leverage activities within Service Manager, clients are able to more effectively manage Change and Service Request processes.
As our clients explore more with activities, they begin to realize that System Center Service Manager has a few shortcomings when it comes to displaying parent Work Item information in relation to activities. This is especially true when it comes to Notification Subscriptions and SCSM Console Views.
For example, when receiving an e-mail with regards to a Manual Activity assigned to an analyst, it is important for that analyst to see information about the Activity and the Parent Work Item, for context. Below is an example of what information would be important for an analyst:
When setting up an E-mail Template for an Activity, it is not clear to the user on how to make this happen. Fortunately, there are a few blogs that explain how you might accomplish this. Some suggest leveraging the “Contains Activity” relationship. Unfortunately, there are significant issues with this relationship:
Along the same lines, another example is listing Activities within a SCSM Console View. Again, it is extremely important to include info about the Parent Work Item in order to give context to the Activity. Unfortunately, there is no way, out of the box, to do this.
We, at Cireson, have thought up an elegant solution to the challenges above. The solution can be broken up into three different parts:
The Management Pack is the heart of the entire solution. There are numerous ways these challenges could have been overcome. We designed the Management Pack around the following principles:
The Management Pack includes the following elements:
Both the Manual and Review Activity classes were extended with the following properties and relationships:
The ParentWI_ID is only leveraged as a way for Notification Subscriptions to know that the Activity Management workflows have finished running, before they send out e-mail notifications. Otherwise, there is a good chance that the first Activity under a SR/CR will fire off its’ e-mail notification before the Activity Management workflows have finished processing. This property could just as easily been a Boolean, etc. It is important to note that we are not leveraging this property, or any other extended properties to populate the content of notification subscriptions or views. That is left to the relationships (see below).
Relationship: (Cireson) Activity References Parent Work Item
The (Cireson) Activity References Parent Work Item relationship provides all of the necessary content for both SCSM Views and Notification Subscriptions. There are a couple of important things to note about this relationship:
Manual Activity (Affected User, AssignedTo User, Parent Work Item) Type Projection
This type projection is necessary for combining all of the relevant relationships for SCSM Views containing activities. There are a couple of things to note with regards to this type projection:
The workflows are what drives the population of properties and relationships. We can develop these workflows to leverage SCSM Workflows, Orchestrator Runbooks, or SMA Runbooks. For simplicity sakes, I’m going to show you how to set this up within Orchestrator.
Our Initiation Runbook is going to look like the following:
1.) Monitor for new MAs (SCSM Monitor Object)
Nothing special with this Monitor. We are looking for any new Manual or Review activities.
2.) Get Parent Work Item (.NET Script)
This is the magic behind identifying the Parent Work Item for the Activity. This script needs to account for an Activity that is nested under multiple layers of Parallel and Sequential activities.
[UPDATE] Anton Gritsenko made some great suggestions about optimizing the script above via twitter. These optimizations will improve overall performance and make the script capable for multi-language. I will follow this post with another to go into detail on what those optimizations are.
3.) Get Parent Work Item Info (Invoke Runbook)
The Get Parent Work Item Info runbook’s main purpose is to collect any class specific properties and relationships that are necessary. In this case, the only information we really need to collect is the “Affected User” relationship to the Parent Service Request.
It is important to note, that the reason why we split out the Get SR Affected User function into its own Runbook is due to the fact that if by chance there was not an “Affected User”, we still would want for the Get Parent Work Item Info to run the “Return SR Info” and finish out the Runbook. If we did not create this additional invoke, then once no Affected User is returned after the Get Related Users to SR activity, the Runbook will stop, and the Return SR Info activity will never run.
4.) Update Activity (Invoke Runbook)
The Update Activity (Invoke Runbook) mains purpose is to Update the MA (ParentWI_ID property) and establish the necessary relationships to Affected User and the new (Cireson) Activity References Parent WorkItem relationship.
There is nothing special at this point. When setting up your activity view, make certain you are selecting the appropriate Combination Class:
In order for E-mail Notifications to work correctly, it is important to realize that the above workflow needs to finish before the appropriate relationships are established. If an Activity is created, goes to “In Progress” and an E-mail Notification fires off before the Orchestrator Runbooks have a chance to establish the relationships, then that initial e-mail will be missing all of the necessary information. In order to resolve this issue, we need something to indicate whether the Runbooks have completed for an activity, before e-mails are fired off.
The way to go about this is to leverage the ParentWI_ID extended property. We need to setup a Notification Subscription to look for this property and to ONLY send an e-mail if this property ‘Exists’. So the conditions we are looking for are as follows:
This will need to be done for both MA and RA. So you are looking at a total of 4 different Notification Subscriptions.
And there you have it. A solution that enables users to leverage out of the box features (SCSM Views and SCSM Notification Subscriptions) with a little help from Orchestrator and Powershell.
The MP (unsealed) and Runbook can both be found on Microsoft’s Technet Gallery.
Please send us any feedback regarding this post @teamcireson and/or directly to me @vbpav.
Disclaimer: Any code provided is “AS-IS” with no warranties. Please test before implementing any of these concepts, scripts, runbooks, or MPs into Production environments.