Workflow Management Service

The Workflow Management Service (WMS) is a Windows service that provides the following management services for workflow service instances:

• Activation of workflow service instances. The WMS activates workflow service instances in an instance store when the instances become activatable. A workflow service instance in an instance store is considered activatable if the instance becomes runnable and a service host that matches the instance is not running on the local computer. The following list has reasons for an instance to become runnable:

  • The instance is unloaded and persisted while waiting for a delay activity to complete and the delay activity completes.

  • The service host shuts down while the instance is loaded.

  • The instance has an expired instance lock on it.

• Execution of user control commands. An instance control provider for an instance store adds commands that it receives from Windows PowerShell instance-control cmdlets to a queue in the instance store. This queue is created and maintained by the instance control provider. The WMS retrieves the commands from the queue, executes them, and then deletes commands from the queue if the command execution is successful.

The rest of the topic explains these services in detail. To learn about installation and configuration of the WMS, see Installing and Configuring the Workflow Management Service.

Activation of Workflow Service Instances

By default, the WMS automatically discovers instance stores that it needs to monitor for activatable workflow instances. It does so by scanning through Web.config files at the root, site, and application levels during the service startup and when one of these configuration files is changed. You can also specify particular instance stores that you want the WMS to monitor instead of having it discover instance stores automatically.

The WMS creates an InstanceStore object and subscribes for the HasActivatableWorkflowEvent for each instance store it discovers. An instance store raises the HasActivatableWorkflowEvent when it finds an activatable workflow instance in the store. After this, the instance store stops monitoring until the QueryActivatableWorkflowsCommand is called one time on the store.

When the WMS receives the HasActivatableWorkflowEvent, it executes the QueryActivatableWorkflowsCommand against the instance store to obtain activation parameters that it uses to create a workflow host.

Then, the WMS invokes the Service Management Service supported by the application that contains the service whose instance needs to be activated and passes activation parameters to it. AppFabric automatically adds the Service Management Service, a WCF service, to all applications that have the serviceManagement attribute enabled. The Service Management Service exposes a Service Activation Endpoint, which the WMS accesses by using the address it constructs by using site name, virtual application path, and well-known Service Activation Endpoint address. The WMS uses net.pipe binding for this endpoint. See Service Management Service for more information about this service.

The Service Management Service activates a workflow service host by using activation parameters it receives from the WMS. The service host creates an instance store (such as the SQL Workflow Instance Store) and invokes a method on the store to load the workflow service instance from the instance store into memory.

Warning

The WMS instantaneously picks up any changes to SQL Workflow Instance Store (SWIS) behaviors and corresponding instance store definitions in configuration files and starts monitoring those stores. However, an application will continue to use the instance store that was specified in the SWIS behavior in the old version of the configuration file until the application domain recycles. The application domain is recycled after the time period specified by the delayNotificationTimeout attribute of the httpRuntime element. For example, if the delayNotificationTimeout is set to 5000 (<httpRuntime delayNotificationTimeout = "5000" />), the application domain is not recycled for another 5000 seconds.

Warning

If you disable applications or application pools that contain 1000 or more services in total, the WMS may not activate any activatable service instances anymore. The workaround is to suspend instances of services that belong to these applications/application pools before deactivating or disabling applications/application pools.

Execution of User Control Commands

When you issue a command against a workflow service instance by using a Windows PowerShell cmdlet, an instance control provider adds the command to a command queue in the instance store used by the service. The command queue is maintained by the instance control provider.

The WMS automatically discovers instance stores that it needs to monitor for commands. It does so by scanning through Web.config files at the root, site, and application levels during the startup and when one of these configuration files is changed. The WMS creates an instance control provider for each instance store it discovers and polls the provider for commands at regular intervals. Specifically, the WMS invokes the BeginTryReceive method on an instance control provider to receive commands

The instance control provider in turn retrieves a command, but does not delete it from the command queue in the instance store and returns the command to the WMS. The provider places a lock with a short expiration time on the command in the command queue.

The WMS then invokes an appropriate method of the Instance Control Endpoint (ICE) exposed by the workflow service host to execute the command against the target workflow service instance. The WMS requires that the instance control endpoint enable a net.pipe binding and have the transport security enabled. The WMS constructs an endpoint address by combining the site name, virtual service path, and the well-known ICE path. The instance control provider provides the site name and the virtual service path information. The ICE binding is hardcoded to the net.pipe binding.

If the command execution succeeds, the WMS invokes the Complete method on the instance control provider, and the provider removes the command from the command queue. If the command execution fails, the WMS invokes the Abandon method on the instance control provider about the failure, and it is up to the provider to decide whether to remove the command from the command queue or to keep the command in the command queue for additional retries. The instance control provider for the SQL Workflow Instance Store tries a command five times before removing the command from the command queue. If the WMS crashes during the execution of a command, the lock will eventually expire, and the command may be picked up by the same WMS instance or another WMS instance later.

If the Microsoft Distributed Transaction Coordinator (MSDTC) is enabled and the MSDTC enabled inbound and outbound communication, instance control commands are executed in a transactional manner. For example, if you suspend a workflow service instance, the status is displayed in IIS Manager or returned from cmdlet as Suspended immediately after the command has been processed. However, if the MSDTC is disabled or is not properly configured, instance control commands are executed in a non-transactional manner. In this case, the status of the instance will not be updated to Suspended until the instance is unloaded and is persisted in the instance store because the instance has been idle for longer than the specified period of time (Unload on idle setting). Note that if you change MSDTC settings, you will need to restart the WMS so that the service picks up the updated MSDTC settings.

Tip

If you notice that one or more instance control commands remain in pending state longer that you expect, you should check whether the WMS is running on each server in the server farm. If the instance is currently running on a particular server (as per the monitoring information) and a control command issued for that instance is not being executed, you need to check if the WMS is running on the server.

Warning

The Workflow Management Service uses transacted commands if the "Allow Inbound" and "Allow Outbound" DTC settings are enabled. If you are disabling DTC, ensure that you also explicitly disable these settings so that non-transactional commands will be used.

Support for Server Farm Environments

Typically each node in a server farm runs one WMS instance. A WMS instance can monitor multiple instance stores. A node can run multiple WMS instances under different Windows identities. We recommend that you run only one WMS instance for an instance store on a node. If you run multiple WMS instances on the same node monitoring the same instance store, you may run into scalability issues.

An instance that ran on one node earlier might be picked up by the WMS on another node and be activated on that node. This would help with balancing the workload for WMS across the server farm.

When you issue a control command for a workflow instance, that workflow instance may or may not be running anywhere in the farm. WMS delivers the command to the computer running the workflow or instructs the local computer to load the workflow and execute the command. This enables you to issue commands to instances without knowing on which computer the instance is running.

Dependent Features

The following points apply to the Workflow Management Service (WMS):

• The WMS activates and executes commands against instances of workflow services that are hosted using WorkflowServiceHost in the IIS/WAS environment only. The WMS does not support workflow services hosted using a different host or in a different hosting environment.

• The WMS activates instances of workflow services that use an instance store for durable state persistence.

• The WMS activates instances of workflow services that belong to an application that provides the Service Management Service. The WMS uses the Service Management Service to activate a service host that in turn will load an instance from the instance store.

• The WMS requires the net.pipe binding to be added to the site and the net.pipe protocol to be enabled on the application that contains the service. The WMS logs an error in the event log if the net.pipe protocol is not enabled on application.

• The WMS requires a workflow service instance to expose an instance control endpoint (ICE). The WMS uses this endpoint to issue commands such as Suspend and Resume to workflow service instances.

• The WMS works with any instance store that ships with an instance store provider and an instance control provider.

• The WMS requires an instance store to raise the HasActivatableWorkflowsEvent when an instance becomes activatable.

Note

For security-related information about WMS, see Security Configuration for Persistence Stores.

Security

The Workflow Management Service (WMS) needs to connect to the Instance Control Endpoint (ICE) exposed by a workflow service host to control workflow service instances and the Service Management Endpoint exposed by a Web application to start a workflow service host and then load workflow service instances. The AS_Administrators group has access to both these endpoints. The Security Identifier (SID) of the AppFabric Workflow Management Service is a member of this group. Therefore, you do not need to add the account under which the WMS is running to the AS_Administrators group explicitly.

The following list provides guidelines for securing instance stores and configuration files that the WMS uses:

• The WMS reads configuration information including connection strings from configuration files into memory. The WMS does not process encrypted connection strings at this time, so the connection string have to be in simple text format. A malicious user could gain access to any sensitive information (such as user name and password in a connection string) from memory. Therefore, you should not specify sensitive information in a connection string defined in a configuration file.

  We recommend that you use integrated Windows authentication for connection strings stored in Web.config files. If you cannot use integrated Windows authentication and you specify user name and password in a connection string defined in a Web.config file, set appropriate ACLs (Access Control Lists) on the configuration files. Make sure that the AS_Administrators group has access to Web.config files that the WMS needs to access. You must be aware that setting ACLs does not stop a malicious user from accessing connection string information from memory though.

• Enable encrypted SQL communication by adding “;Encrypt=yes” to the SQL connection string. If you are using SqlConnectionStringBuilder class to build a connection string, set the Encrypt property to true. See https://go.microsoft.com/fwlink/?LinkID=187283 for details about enabling encrypted communication at the server. A malicious user can manipulate or run commands against the SQL Server database if you don’t have the communication between your application and SQL Server secured.

• A command queue does not maintain any credential information. A user that is a member of the AS_Administrators group, which is mapped to the WorkflowAdministrators SQL role, has the right to control all instances in the instance store, and not any specific type of instances. Therefore, instances that are not intended to be controlled by different users should be stored in different instance stores, and the WorkflowAdministrators SQL role for these instance stores should be mapped to different Windows groups.

• Every time a Web.config file is modified, the WMS reads the file and checks if store definitions have been added or removed from the file. To prevent unauthorized users from triggering the WMS file processing, we recommend that you restrict write access to Web.config files.

• Depending on the tracking level, the AppFabric monitoring feature gathers data at large rates. We recommend that you do not collocate the monitoring and persistence stores in the same database. This way an overflow of the monitoring store does not affect the persistence subsystem.

The following table describes the SQL roles that secure access to the command queue and the persistence database. The content in this table applies only to the SQL Workflow Instance Store.

SQL Role	Description	Windows Group
WorkflowAdministrators	A member of this role can enqueue commands (add commands) to the command queue, which is part of the persistence database. A user who wants to control instances (for example, by using Windows PowerShell cmdlets) must be a member of this role.	AS_Administrators
WorkflowManagementServiceUsers	A member of this role can dequeue (retrieve commands) from the command queue. The account under which the WMS runs must be a member of this role so that the WMS can retrieve commands stored in the command queue.	AS_Administrators
WorkflowActivationUsers	A member of this role can activate workflow service instances that are persisted in the persistence database and are ready to run.	AS_Administrators
InstanceStoreObservers	A member of this role can query the instance store for instances and retrieve commands from the command queue in the store.	AS_Administrators and AS_Observers
InstanceStoreUsers	A member of this role can load and save instances. The load and save actions are performed by a service host that runs a workflow. If the instances of a service Service1 persist in instance store Store1 then the application pool AppPool1 that runs the service host must run under an identity that has User rights on Store1.	IIS_USRS

For scenario-based security guidance for persistence, see Security Configuration for Persistence Stores.

See Also

Concepts

Security Configuration for Persistence Stores
Installing and Configuring the Workflow Management Service