Workflow Configuration Files

A Windows Workflow Foundation host application can use a configuration file to control the behavior of a WorkflowRuntime object.

Creating Configuration Sections

To use a configuration file to configure the workflow runtime engine, you first must create a .config file for your application (app.config) or web service (web.config). In this configuration file, create a configuration section as shown in the following XML code.

<configuration>
    <configSections>
        <section name="WorkflowRuntime" type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken 31bf3856ad364e35" />
    </configSections>
</configuration>

Defining the Configuration Sections

Your configuration file can contain multiple configuration sections, but only one section can be used when you instantiate a WorkflowRuntime object.

After the configuration section has been declared, add the configuration information that the runtime will use for that section. Note that the name of the section tag matches the name given in the name attribute that is specified in the previous example. For this example, the section tag is WorkflowRuntime.

<WorkflowRuntime Name="SampleApplication">
    <CommonParameters>
        <add name="ConnectionString" value="Initial Catalog=WorkflowStore;Data Source=localhost;Integrated Security=SSPI;" />
    </CommonParameters>
    <Services>
        <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" maxQueuedWorkItems="20"/>
        <add type="System.Workflow.Runtime.Hosting.SharedConnectionWorkflowTransactionService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />    
        <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" UnloadOnIdle="false"/>
    </Services>
</WorkflowRuntime>

The WorkflowRuntime configuration section has a single attribute. Name is used to specify the name of this WorkflowRuntime. The name is used in output to distinguish this runtime from other runtimes that may be running on the system, for example, in performance counters.

The configuration section contains two nested elements. The CommonParameters element defines any parameters that are used globally across multiple services, for example ConnectionString when using the SharedConnectionWorkflowCommitWorkBatchService. The second element lists the individual services that are configured for this workflow runtime engine. If a service takes additional configuration parameters, these may be included as attributes, as shown with the maxQueuedWorkItems and UnloadOnIdle attributes in the previous example.

Using the Configuration File

The configuration file controls the behavior of a WorkflowRuntime object. You can programmatically add services when you create an instance of a WorkflowRuntime object or you can use a configuration file as demonstrated in this topic. To use a configuration section defined in a configuration file, pass the name of the configuration section as a parameter to the WorkflowRuntime constructor.

The following example demonstrates how to create a WorkflowRuntime instance by using the WorkflowRuntime configuration section created earlier.

WorkflowRuntime runtime = new WorkflowRuntime("WorkflowRuntime");

Additional configuration options

The following sections describe how you can use configuration files to enable certain functionality in your workflow, such as recommitting a work batch or logging workflow data.

Enabling retries for work batches

For services that commit work batches to persistence stores, such as DefaultWorkflowCommitWorkBatchService and SqlWorkflowPersistenceService, you can enable them to retry their transaction by setting the EnableRetries property as shown in the following example:

<WorkflowRuntime Name="SampleApplication" UnloadOnIdle="false">
    <CommonParameters>
        <add name="ConnectionString" value="Initial Catalog=WorkflowStore;Data Source=localhost;Integrated Security=SSPI;" />
        <add name="EnableRetries" value="True" />
    </CommonParameters>
    <Services>
        <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" EnableRetries="False" /> 
     </Services>
</WorkflowRuntime>

Notice that the EnableRetries property can be set at either a global level (as shown in the CommonParameters section) or for individual services that support EnableRetries (as shown in the Services section). In this example, all services that support EnableRetries will enable that functionality, except SqlWorkflowPersistenceService.

The following services support EnableRetries:

  • DefaultWorkflowCommitWorkBatchService
  • SharedConnectionWorkflowCommitWorkBatchService
  • SqlWorkflowPersistenceService
  • SqlTrackingService

For more information, see the EnableRetries property on each of the classes previously listed.

For general information about retrying work batch transactions, see Batching State Information in Workflows.

Enabling Workflow Logging

Using the configuration file, you can output Windows Workflow Foundation logging information to aid in debugging scenarios. Windows Workflow Foundation uses the configuration format introduced in the .NET Framework 2.0. An example of enabling logging information for several Windows Workflow Foundation namespaces is as follows.

<system.diagnostics>
    <switches>
        <add name="System.Workflow LogToFile" value="1" />
        <add name="System.Workflow.Runtime" value="All" />
        <add name="System.Workflow.Runtime.Hosting" value="All" />
        <add name="System.Workflow.Runtime.Tracking" value="All" />
        <add name="System.Workflow.Activities" value="All" />
        <add name="System.Workflow.Activities.Rules" value="All" />       
    </switches>
</system.diagnostics>

In this example, the first add node enables logging to a file. The file is created in your host application directory using the name WorkflowTrace.log. The other option is to enable logging to a TraceListener by setting the name parameter equal to "System.Workflow LogToTraceListener". When you set this, Windows Workflow Foundation will enumerate each TraceListener created within your host application and send all logging information to them.

The remaining lines in the example shown earlier enable you to specify the namespaces to capture logging information for as well as the amount of information that is traced. The following table lists the possible values for the value attribute.

Value Description

All

Logs all messages received

Off

Does not log any messages

Critical

Logs only messages that are deemed critical

Error

Logs critical and error messages

Warning

Logs critical, error, and warning messages

Information

Logs critical, error, warning, and information messages

Verbose

Logs critical, error, warning, information, and verbose messages

See Also



Copyright © 2007 by Microsoft Corporation. All rights reserved.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft