Workflow Manager 1.0 is a new server which introduces new capabilities for authoring, hosting and managing workflows. It provides managed host for executing and managing workflows. Manager 1.0 will take care of many of the challenges customers have today in managing their workflow artifacts, building out their hosting environment, configuring it for scale and high availability, managing a farm of machines running their applications, and so on.
- High Density & Multi-tenancy
- Workflow Artifact Management
- Tracking and Monitoring
- Instance Management
- Fully Declarative Authoring
- REST and Service Bus Messaging
The multi-tenant hosting capabilities provide for safe, high efficiency and high performance execution of workflow instances, as well as the ability to organize and manage tenants of the service.
The service also introduces new capabilities for managing your activities and workflows in the system. Clients can upload their activity and workflow definitions via a REST API or client library, and the service stores the artifacts in a scaled out, reliable repository. The service also manages the relationships among activity and workflow definitions and their versions, providing flexible artifact management capabilities for updating definitions, while ensuring the process integrity of running instances.
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).
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:
1. ActivityPath – specifies which Activity will be used as the implementation body for this Workflow.
2. 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:
1. Explicitly, by calling StartWorkflow API to start a new instance of a particular Workflow.
2. 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.
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. 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.
Each Activity, Workflow and Instance belongs to a single scope. An Activity and a Workflow belong to a Scope to which they were published to. An Instance belongs to the same scope as its Workflow.
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.
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.
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.
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.