Enhancing Activity Management with some Orchestrator and Powershell Magic

Activity Management in a Nutshell with some Orchestrator and Powershell Magic

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.

The Challenge

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:

• Activity ID
• Activity Title
• Parent Work Item ID
• Parent Work Item Title
• Parent Work Item Affected User
• Parent Work Item Support Group

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:

1.  You must edit the variable string with, “SeedRole”.
2. The available class properties are just limited to “Work Item”. (this is because the “target” class for the relationship is system.workitem.activity not system.workitem)
3. If the Activity is nested under a Parallel or Sequential Activity, then this relationship does not work at all. The E-mail will return info about the Parent Parallel or Sequential Activity, and not the Parent Service Request or Change Request.

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.

 The Solution

We, at Cireson, have thought up an elegant solution to the challenges above. The solution can be broken up into three different parts:

1.  The Management Pack
2. The Workflows
3. Making it all work

The Management Pack

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:

1. Views and E-mail Notifications are to be configured and ran from the native SCSM Console and SCSM itself (example: notifications should NOT be sent directly from Orchestrator)
2. Minimize (or eliminate) any editing of XML or E-mail Template variable strings.

The Management Pack includes the following elements:

 Activity Class Extensions

Both the Manual and Review Activity classes were extended with the following properties and relationships:

Property: ParentWI_ID

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:

1. The base reference class is System.Reference. This type of relationship will not balloon the SCSM Database, due to the fact that it does not have to build reference tables between two classes like “Hosting” or “Containment” base relationship classes do.
2. The “Source” of the relationship is the Activity while the “Target” is the Parent Work Item. This is important, because, when you select this relationship within the E-mail Template picker, you will have all properties available to you for the Work Item class and every other class derived by Work Item (SR, CR, etc.). This is opposite of how the “Contains Activity” relationship is setup. Its’ “Target” is the Activity, thus is why you are limited to Work Item and Activity class properties.
3. The “MaxCardinality” is set to 1 for the “Target”. This means, SCSM will only expect to see a single relationship between the Activity and the Parent Work Item. There can only be 1 Parent Work Item. This is important due to the fact that SCSM Views do not work with many to many relationships. This is one of the reasons why the relationship class “Contains Activity” cannot be used for SCSM Views.

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:

1. The “Affected User” alias is using the default System.WorkItemAffectedUser relationship. Out of the box, this relationship is not used. As a matter of fact, it is not even displayed on any of the Activity forms. Later on within the Activity Management workflows, we will establish this relationship with the Parent Work Item’s Affected User. Might as well take advantage of something that is there for us to use!
2. The “ParentWorkItem” alias is leveraging the Cireson.Relationship.ActivityReferencesParentWorkItem relationship. This will expose the “Work Item” generic class properties.
3. Both the “ParentSR” and “ParentCR” aliases above both leverage the Cireson.Relationship.ActivityReferencesParentWorkItem relationship. Note, however, that both of these are Type Constrained to their respective class. This will expose the “CR” and “SR” class properties.

The Workflows

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.

Making it all work

SCSM Views

There is nothing special at this point. When setting up your activity view, make certain you are selecting the appropriate Combination Class:

• (Cireson) Manual Activity (Affected User, AssignedTo User, Parent Work Item)
• (Cireson) Review Activity (Affected User, AssignedTo User, Parent Work Item)

E-mail Notifications

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:

• Scenario1
  • Changed From
    • Status != In-Progress
  • Changed To
    • Status = In-Progress
    • ParentWI_ID = Exists
• Scenario2
  • Changed From
    • ParentWI_ID != Exists
  • Changed To
    • ParentWI_ID = Exists
    • Status = In-Progress

This will need to be done for both MA and RA. So you are looking at a total of 4 different Notification Subscriptions.

Conclusion and the Orchestrator and Powershell Solution

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.

Good luck!

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.

Ready to transform your SCSM experience? View all of the exciting apps Cireson has to offer.