The System Center Platform in Service Manager Part 4: The System Center Management Service

First published on TECHNET on Aug 09, 2009

This is a continuation of the ‘The System Center Platform in Service Manager’ series.  Previous posts:

The System Center Platform in Service Manager Part 1: Introduction

The System Center Platform in Service Manager Part 2: The Model-Based Database

The System Center Platform in Service Manager Part 2: The Model-Based Database - Try It!

The System Center Platform in Service Manager Part 3: The System Center Data Access Service

The System Center Platform in Service Manager Part 3: The System Center Data Access Service – Try It!

The System Center Management Service is the worker service in the System Center platform.  It runs what we generically call ‘workflows’ (not to be confused with Windows Workflow Foundation workflows, although it can run those too).  These workflows can be Rules, Tasks, Monitors (not applicable to Service Manager), or Discoveries.  Each of these workflows is comprised of a series of reusable modules which can be combined together in various to form different workflows.  Workflows are typically comprised of a data source module, (optionally) a condition detection module, and an action module.  A really common structure of a workflow in Service Manager looks like this:

Each of these workflows is defined in a management pack.  Below is an example from the Service Manager activity library management pack.  This Rule workflow is triggered when a Reviewer is added to a Review Activity.  In response to this trigger, a Windows Workflow Foundation workflow is run.

<Rule ID="ServiceManager.ActivityManagement.ReviewerAddedRule" Enabled="true" Target="System.WorkItem.Activity.WorkflowTarget" Remoteable="true">

<Category>System</Category>

<DataSources>

<DataSource ID="DS" TypeID="Subscriptions!Microsoft.SystemCenter.CmdbInstanceSubscription.DataSourceModule">

<Subscription>

<InstanceSubscription Type="$MPElement[Name='Activity!System.Reviewer']$">

<AddInstance></AddInstance>

</InstanceSubscription>

<StartWatermark>1</StartWatermark>

<PollingIntervalInSeconds>10</PollingIntervalInSeconds>

<BatchSize>100</BatchSize>

</Subscription>

</DataSource>

</DataSources>

<WriteActions>

<WriteAction ID="WindowsWorkflow" TypeID="Subscriptions!Microsoft.EnterpriseManagement.SystemCenter.Subscription.WindowsWorkflowTaskWriteAction">

<Subscription>

<WindowsWorkflowConfiguration>

<AssemblyName>

Microsoft.EnterpriseManagement.ServiceManager.ActivityManagement.Workflows

</AssemblyName>

<WorkflowTypeName>

Microsoft.EnterpriseManagement.ServiceManager.ActivityManagement.Workflows.ReviewerVotedWorkflow

</WorkflowTypeName>

<WorkflowParameters>

<WorkflowParameter Name="InstanceId" Type="guid">$Data/BaseManagedEntityId$</WorkflowParameter>

</WorkflowParameters>

<RetryExceptions></RetryExceptions>

<RetryDelaySeconds>11</RetryDelaySeconds>

<MaximumRunningTimeSeconds>1500</MaximumRunningTimeSeconds>

</WindowsWorkflowConfiguration>

</Subscription>

</WriteAction>

</WriteActions>

</Rule>

The Management Service itself is a Windows service and its process name is healthservice.exe (the name is a carryover from the fact that this service originated in Operations Manager).

The Management Service doesn’t actually run the workflows directly though.  It actually runs the workflows in separate processes called System Center Management Service Host Processes.  The process name for these processes is MonitoringHost.exe (again, the name is a carryover from Operations Manager).

These workflows are run in a different process for a number of different reasons:

1) Process isolation – if one of these workflows were to crash, it would be bad if it took down the Management Service because then all other workflows would go down with it and it would not be possible to start new workflows without manual intervention to start the service again.

2) Workflow user identity flexibility – in some cases you may want to run a workflow as a different user identity.   The Management Service must always run as the same identity, but it can start other Host Processes as different user identities.

3) Management – The Management Service also watches over all the Host Processes.  If they run too long, or consume too much memory/ processor, the Management Service will terminate the offending Host Process so that it doesn’t impact other Host Processes or other processes running on the server.

In Service Manager these workflows are used for lots of different things such as:

·         Process workflows for incident, change, problem, configuration, and activity management

·         AD, SCCM, and OM connectors

·         Sending email notifications

·         Grooming

·         Group calculation

·         Management Pack Synchronization between Service Manager and the Data Warehouse

·         Data Warehouse jobs – Extract, Transform, Load

·         Data Warehouse schema deployment

·         Report deployment

So, now we have uncovered a couple more pieces of the architecture diagram (click to view full size):

In the next, post we’ll try out the Management Service by creating a simple workflow in a management pack .