Windows Workflow Foundation Features and Principles

The previous sections described the tangible areas of the Windows Workflow Foundation platform. The following sections cover concepts and features at a higher level to help you gain a greater appreciation for what Windows Workflow Foundation has to offer. In turn, this should assist you in applying these concepts to workflow-related conversations and decisions in your organization.

Dynamic Update

Dynamic update describes the ability of Windows Workflow Foundation to modify a running workflow’s execution path. This opens up a new world of scenarios related to capturing missed requirements during development or allowing for exception cases where a process might need to behave differently than it normally would.

For example, consider an approval process that requires an additional round of approvals from analysts. Because business processes are at the forefront of workflow, and processes are sometimes dynamic, this is a very important feature of Windows Workflow Foundation.

Chapter 11 discusses dynamic update in depth and explains how to apply this concept to your workflows.

Designer Hosting

Designer hosting is a unique feature of Windows Workflow Foundation. It enables you to display the workflow designer in your own applications.

The hosted designer enables ISVs to develop workflow-related products on top of Windows Workflow Foundation and allows end users to manipulate visual processes. You might be thinking something like, “Wow, allowing a business user to modify software sounds dangerous!” Well, there is a little more to the story. The designer is completely customizable so that the level of interactivity between the workflow engine and the end user is completely in control of the application developer. You, as the developer, can decide which activities the user has access to and provide limitations to what the user can do during design time.

Imagine that a set of custom activities has been developed that pertains to a specific business problem domain, such as call-center administration. The call-center manager could open his or her workflow designer, which was either built internally or purchased from a third party, and then drag and drop prebuilt activities on to a visual design surface. This provides a great deal of flexibility to the business while ensuring that the user cannot get into too much trouble.

Chapter 11 covers designer hosting in greater detail, including technical implementation and example scenarios.

Extensibility

To ensure that Windows Workflow Foundation is able to meet the needs of various problem domains and specific technology requirements, the framework is extensible through and through. Essentially everything on the platform can be extended or enhanced, even down to customization of the look and feel of the workflow designer.

One of the more common scenarios for using Windows Workflow Foundation will probably be the development of new activities. Because activities are the building blocks of workflow solutions, they will likely be the most visible. In addition, because the out-of-the-box activities that ship with Windows Workflow Foundation are generic and do not relate to areas such as healthcare or law, custom activities will be developed to solve problems in these fields.

Runtime services are another great example of the extensibility of this platform. For example, if an organization requires workflows to persist themselves to XML rather than use the native SQL persistence service, you can develop this with the base classes provided.

Extensibility is not something that is applied to only one area of the framework. Therefore, this concept is reinforced throughout the book through examples and scenarios of how you can expand Windows Workflow Foundation.

Configuration

With the release of the .NET Framework in 2002, configuration became a first-class citizen. There are entire class libraries and runtime elements that support dynamic settings defined in XML files.

Windows Workflow Foundation configuration uses this same principle to allow developers greater flexibility in their workflow applications. A common configuration scenario is one where runtime services are defined and configured in an app.config or web.config file. The following is an example configuration file that adds the SQL tracking service to the workflow runtime. It is important to note that the ConnectionString key/value pair is used by the SqlTrackingService class that is referenced in the Services node:

  <?xml version="1.0" encoding="utf-8" ?> <configuration>   <configSections>     <section name="WorkflowConfig"      type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection,            System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral,            PublicKeyToken=31bf3856ad364e35" />   </configSections>   <WorkflowConfig Name="WorkflowConfig">     <CommonParameters>       <add name="ConnectionString"             value="Initial Catalog=WorkflowTracking;                   Data Source=localhost;Integrated Security=SSPI;" />     </CommonParameters>     <Services>       <add type="System.Workflow.Runtime.Tracking.SqlTrackingService,            System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral,            PublicKeyToken=31bf3856ad364e35"/>     </Services>   </WorkflowConfig> </configuration> 

Chapter 5 discusses configuration in more detail.

Workflow Monitoring

The Windows Workflow Foundation platform provides an extensive library of performance counters to assist in diagnosing performance issues in a production environment. Performance counters are pieces of code that expose key metrics related to processes execution. You can view the data that these pieces of code expose in the Windows Performance Monitor application. For example, Figure 3-6 shows the Performance Monitor displaying operating system metrics.

Figure 3-6

Performance counters are built on an extensible framework, which means that any application developer can create counters that generate meaningful data for custom applications. The Windows Workflow team has done just that. Table 3-3 lists a subset of the workflow performance counters.

Table 3-3: Workflow Performance Counters
Open table as spreadsheet

Counter	Description
Workflows Created	The number of workflows created on a system
Workflows Completed	The number of completed workflows on a system
Workflows Executing	The number of workflows currently executing
Workflows Persisted	The number of workflows that have been persisted

Chapter 12 covers the rest of the performance monitors and workflow monitoring scenarios.