Workflow Overview

Applies To: System Center 2012 - Service Manager

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

A workflow consists of two pieces: a data source subscription and a workflow reference. The data source subscription helps filter objects into the workflow for processing.

Windows Workflow Foundation-based binaries are used by management groups when they are referenced by management packs. Parameters can be passed from the management pack to the workflow instance when the workflow is created by Service Manager. Enterprise management objects (EMO) are processed by the subscription reference and then sent to the workflow reference. The workflow reference translates the properties that are defined by the EMO to parameters defined by the workflow reference and then the workflow is executed.

Data Source Subscriptions

Subscriptions are data sources that provide items for the workflow. These data sources target a specific type of enterprise management object (EMO). There are two types of subscriptions, instance subscriptions and periodic subscriptions.

Instance Subscription

Instance subscriptions target a type of object that constrains what will be evaluated by the subscription. The targeted instances are additionally filtered by specified criteria. An instance subscription is triggered by an add, remove, or delete operation. These operations work with instances directly. The add operations causes the subscription to trigger when an instance of the target type is created. The update operation triggers when an instance is updated. The delete operation triggers when an instance is marked for deletion.

An instance subscription can target a relationship type instead of targeting an EMO type. However, when the instance subscription targets a relationship type, only the add and remove operations work. When targeting a relationship type, the source and target of that relationship is available for use by criteria and by the workflow reference.

The InstanceTypeSubscription class represents an instance subscription. When you create an instance of this class, you must specify the type of operation that will trigger the subscription, the type identifier of the object to target, and the criteria XML string.

Periodic Subscription

A periodic subscription executes the workflow at a specified time interval and uses criteria to designate which instances are sent to the workflow.

The TimerTypeSubscription class represents a periodic subscription. When you create an instance of this class, you must specify the schedule to use. This is accomplished either by passing in an XML string that represents the schedule or a Schedule object instance.

There are three types of schedule objects you can use when configuring the periodic subscription. The following table describes each.

Schedule Type Description

SimpleReccuringSchedule

Triggers at an integer value of seconds, minutes, days, or months.

WeeklyDailySchedule

Triggers on a specific day of the week, each week.

WeeklyMultipleDaysSchedule

Triggers on multiple days of the week, each week.

After you have configured the schedule, you can check the ScheduleXml property to see what the XML equivalent of that schedule would resemble.

Subscription Filter Criteria

An EMO is processed through a subscription by its trigger. You can attach criteria to the trigger to filter out unwanted instances. For example, you can use criteria to filter out objects whose properties do not contain specific values. You could also use criteria to filter out instances that are or are not part of a specific relationship. When you use an instance subscription, the criteria will filter out unwanted items after they have been triggered by the operation. When you use a periodic subscription, criteria will designate which objects to send to the workflow.

If you omit criteria for an instance subscription, all objects that triggered the operation are sent to the workflow. If you omit criteria for a periodic subscription, every EMO is sent to the workflow.

Workflow Reference

The workflow reference works together with the subscription component. The subscription initially processes an item. The item must pass the criteria check, if applicable. Then the item is sent to the workflow. The workflow is created, configured, and executed on the server according to the workflow settings.

To create a workflow reference, you can initialize a new instance of the WorkflowSubscription class. This class has two main parts that you must identify: the Microsoft .NET assembly that has your workflow and the class type in the assembly that is a workflow activity. The AssemblyName property is the name of the .dll file that defines your workflow. Note that it does not include the .dll extension. For example, if your assembly file name was MyWorkflowAssembly.DLL, you would use MyWorkflowAssembly. The WorkflowTypeName property is the namespace and class name of the workflow class. The workflow class is any Activity defined in your assembly.

Parameters

Workflow parameters are defined in the workflow reference. These workflow parameters must match any parameters defined by the workflow activity. The identifier of the parameter on the workflow reference must match the name of a DependencyProperty property that is defined by the workflow activity class. The parameter also specifies which kind of property it will be mapped to. Only a few .NET types are used with the workflow system. These .NET types are defined by the WorkflowParameterType enumeration. For more information about property types, see Model.

Each parameter on the workflow reference also has a query string associated with it. This query string should return a value from the EMO that will be sent to the workflow instance. The type of value from the EMO must match the type defined by the parameter. Once the parameter is defined, it can be added to the Parameters property of the workflow.

Install and Debug

A management pack defines a workflow. However, the workflow binary cannot be installed with the management pack or packaged in a management pack bundle. You must manually install the workflow binary on the management group server. Simply copy your workflow binary to the Service Manager install directory. When the server initiates your workflow, it will look for the binary there.

If you want to debug your workflow, you can add a call to the Launch method on the Debugger class, as provided by the Microsoft .NET Framework, somewhere in your activity. After you add this call, you can attach a debugger to the workflow so that you can then step through it.

See Also

Other Resources

Workflow
Scenario: Defining Workflows
Scenario: Coding a Workflow