Key Concepts in Workflow Manager 1.0
Updated: October 26, 2012
This topic provides an overview of Workflow Manager 1.0 key concepts.
Workflow Management Service
Workflow Client API
Workflow Management Service
Workflow Manager 1.0 exposes a REST-based service endpoint for publishing, managing, and running workflows. All communications to interact with workflow definitions and their instances is done over HTTP(S).
For more information about workflow management, see Server Management.
Workflow Client API
The Workflow Client API, packaged in Microsoft.Workflow.Client.dll, is a set of .NET-based classes that can be used to publish, manage, and run workflows. It provides a first-class set of APIs that abstract away the internal HTTP traffic to the Workflow Management Service.
An Activity is a named entity that contains the building blocks of the workflow’s functionality. An activity will typically be composed from other activites, either custom activities created by the developer, or activities provided in the Microsoft.Activities namespace.
An Activity is represented in the Workflow Client API by the ActivityDescription class. A fundamental member of this class is the Xaml property that represents a XAML-based definition of the Activity.
A Workflow is a named entity that represents a workflow which can be activated or started. It is represented in Client API by the WorkflowDescription class. Two key properties of this class are:
ActivityPath - specifies which Activity will be used as the implementation body for this Workflow.
ActivationFilter - defines the characteristics of messages which can activate an instance of this Workflow.
A Workflow Instance is an entity that represents an instance of a particular Workflow. It is created in one of two ways:
Explicitly, by calling StartWorkflow API to start a new instance of a particular Workflow.
Implicitly, by using PublishNotification API to publish a message that matches ActivationFilter of a given Workflow. Please note that a single message can match ActivationFilters of zero, one or many Workflows. One new workflow instance for each matched Workflows will be instantiated as a result of publishing such a message.
After a Workflow Instance is created it is represented in Client API by WorkflowInstanceInfo class.
A scope is a named and securable container for Activities, Workflows, Instances, configuration and child Scopes.. It also provides a boundary for multi-tenancy and messaging (notifications). Scopes can be created and modified using the Workflow Client API. It is represented in the Client API by the T:Microsoft.Workflow.Client.ScopeInfo class.
When Workflow is installed only the root scope is pre-created and it cannot be deleted. Additional scopes can be created as needed. Multiple level of nesting scopes is supported. Workflows and activities should be deployed to a scope below the root scope.
An Activity xaml can reference and use other Activities that belong either to the same scope, to the parent scope or to any ancestor scope, excluding the root scope.
A Workflow can be defined by using an activity either from the same scope, from the parent scope or from any ancestor scope, excluding the root scope.
A Scope’s security and other configuration settings are inherited by all its child scopes.
A scope is a naming boundary. Names of each named entities (Activities, Workflows and child Scopes) must be unique only within the Scope these entities belong to.
A scope is also a target of PublishNotification API, which means that a single message passed to PublishNotification can activate only workflows that belong to the target scope.
Workflow doesn’t mandate any specific semantic for child Scopes. It is up to the users of Workflow to decide what the scope structure appropriate to a given application is.
For example, and ISV that develops OnlineCollaborationSolution could create top level scopes to represent tenants of OnlineCollaborationSolution application, such as Contoso, Fabrikam and Litware. OnlineCollaborationSolution can allow their tenants to create entities that would be represented as nested scopes in the Resource Model, as shown in the following diagram.
Workflow instances can be created and resumed via notification messages. Messages published to a Scope will fan-out and be delivered asynchronously to all workflow instances that match the filter, as defined by the workflow.
For more information about messaging in workflow, see Messaging.
DynamicValue is a dynamic data structure that can be used for passing complex data into a workflow, manipulating data within a workflow, or passing data out of a workflow as JSON.
For more information about DynamicValue, see Understanding Dynamic Value.