, I described how the Management Service runs what we call “workflows” in Service Manager and then I provided an example for you to
. In this post, I want to describe some more detailed and important aspects of how workflows run in Service Manager. There are some subtle differences and key points that are important to understand for those of you coming from an Operations Manager background or that are planning to write workflows from scratch instead of using our MP authoring tools.
First of all, starting in Beta 2 you will be able to install multiple Service Manager management servers in a single Service Manager management group. For those of you coming from an Operations Manager background – this means that Service Manager supports a “multi-RMS” topology where each management server in a Service Manager management group is a “root” management server. All this really means is that every management server in Service Manager has all three services on it – Management, Management Configuration, and Data Access. Having multiple Data Access services has obvious benefits for redundancy of access to the database and scaling out the middle tier. Having multiple Management Configuration services and Management services in a single management group might blow your mind though if you are coming from Operations Manager. Here’s why…
Let’s say you have a workflow looking for incidents that change their priority to high and when that happens you want to send an email to someone. You want this workflow to run on only one server at a time in Service Manager. Otherwise, the email recipient would receive multiple emails for the same event. To make sure that a workflow runs on exactly one server in Service Manager, we do a little bit of magic in the targeting system by changing the HealthServiceManagesEntity relationship of certain singleton objects to be managed by whichever Management Service is the active workflow execution service at the time. We will provide a mechanism to retarget workflows from one server to another. More on that later…
One other thing to keep in mind is that you can (and should!) import Operations Manager MPs into Service Manager to extend the model-based database so you can sync inventory between Operations Manager and Service Manager. When you do this, we need to make sure that monitoring workflows that may be defined in these MPs don’t run on Service Manager.
The result of this is a few things to note when you are authoring workflows for Service Manager:
1. Workflows in Service Manager must target a class on the ScopedInstanceTargetClass table in the ServiceManager database. You can view the class IDs by running this query:
FROM ManagedType, ScopedInstanceTargetClass
WHERE ManagedType.ManagedTypeId = ScopedInstanceTargetClass.ManagedTypeID
You can tell which computer is currently running the workflows for each class by running this query:
VERY IMPORTANT! -
Because all of these classes are abstract, you should create your own class in your MP that derives from one of these classes and then target all of your workflows to your class.
All Group and Queue Discovery workflows that populate the groups and queues should target the singleton classes that derive from Microsoft.SystemCenter.ConfigItemGroup and System.WorkItemGroup respectively. Microsoft.SystemCenter.ConfigItemGroup is contained in the Microsoft.SystemCenter.InstanceGroup.Library MP and System.WorkItemGroup is located in the System.WorkItem.Library MP. When you create a group or queue class you need to set Singleton="true", Hosted="false", and Abstract="false".
For example, here is the All Change Requests queue which derives from System.WorkItemGroup.
All business process workflows should target a class which derives from Microsoft.SystemCenter.WorkflowTarget. This class is located in the Microsoft.SystemCenter.Library MP. Just as with groups and queues, when you create your derived class, you need to set Singleton="true", Hosted="false", and Abstract="false". Here is an example of the workflow target class defined in the incident library MP:
All of the workflows in Service Manager for incident management are targeted to this class.
The remaining two classes that workflows can be targeted at are really more for internal system purposes and should not be used: Microsoft.SystemCenter.InternalWorkflowTarget and Microsoft.SystemCenter.LinkingFramework.LinkingFrameworkTarget.
2. All workflows must have the attribute Remotable="true" set (or leave the attribute off since the default is true).
3. You can add classes to the ScopedInstanceTargetClass table, but they may only be
classes. Workflows targeted at Hosted classes will not run.
If you add a class to the ScopedInstanceTargetClass table, you will need to do the following series of actions to apply the change:
· Stop all Management and Management Configuration services on all management servers.
· Delete all the files and folders in the <product installation directory>Health Service State directory on all management servers. The <product installation directory> is %Program Files%Microsoft System CenterService Manager 2010 by default.
· Start all Management and Management Configuration services on all management servers.