Michele Leroux Bustamante, IDesign

Zoiner Tejada, TejadaNET

March 2009

Windows Workflow Foundation (WF or, Workflow) is Microsoft’s technology platform for building workflow-enabled applications. The platform includes a set of tools for designing and managing workflows, a programming model for implementing workflow logic, a rules engine, and a workflow runtime execution engine. Workflow technology can be employed in a wide range of application scenarios – the most common of which are listed in Table 1.

Table 1: Common production application scenarios for Workflow

This whitepaper summarizes the value proposition for scenarios that involve the coordination of presentation flow.

Coordinating Presentation Flow

Model View Controller (MVC) is a popular pattern for separating presentation layer, business logic and presentation flow from one another. This pattern engenders discipline in developers, forcing them to decouple these aspects of the application – making it easier to adjust and reuse logic related to presentation flow. State machine workflows are a natural choice as the controller within an MVC pattern.

When user interface navigation is overly complex, changes frequently, or follows a wizard pattern – the workflow designer can help to provide visibility into the presentation flow and any modifications made. Since Workflow can be hosted in any managed Windows application, this pattern can be applied to Windows Forms and WPF client applications, or in ASP.NET web applications. The benefits to using workflow for controlling the presentation flow include:

• Decoupling presentation from business and UI sequencing logic by having the workflow drive the user interface.
• Make complex logic easier to verify by making explicit the possible actions that can be taken from the current user interface's state.
• Simplifying the process of updating presentation logic by replacing code with models.
• Presentation Flow Architecture

The architecture for coordinating presentation flow relies on the premise that the Workflow runtime can be hosted within any managed process, including those associated with the presentation layer as opposed to supporting the middle tier.  A single workflow instance is responsible for what the user sees in the presentation tier.  As the user navigates the user interface, actions they take such as clicking a button raise events to the workflow instance (for example, via local services). As the workflow state is advanced, the application or the workflow is responsible for presenting a new interface to the user according to the new state of the workflow. Figure 1 shows this general architecture for using workflow to coordinate this type of presentation flow.

Figure 1: Presentation flow architecture

Presentation flow can be implemented in Windows Forms, Windows Presentation Foundation and even ASP.NET. The only true requirement is that the user interface process also be able to host the workflow runtime. At the core of a presentation flow architecture is a state machine workflow – each state typically a one-to-one relationship with a particular user interface component such as a WPF window or an ASP.NET page. As the user interacts with the user interface, the workflow instance is advanced to a new state resulting in the presentation of a new window or page.

In addition to their conceptual compatibility, state machines also offer three technical reasons that make them well suited to the task of presentation flow. First, state machines have the ability to reset to another state even if that state is not directly accessible from the current state. This means that the user interface can support actions beyond the typical sequential Next and Previous actions – such as those to restart the workflow from the beginning, or jump back some number of steps. Second, state machines make it possible to dynamically build a user interface that correctly presents what the user can do from the current state. Finally, because states can be nested, a particular event common to all states can be centrally defined responded to from multiple states. This means global events (those not directly tied to a state) such as cancelling the workflow are supported.

The user interface flow can be controlled by the state machine workflow in various ways. The logic for updating the user interface based on state can be decoupled from the workflow such that the client application is responsible for presenting the appropriate user interface as workflow state changes. In this case, there can be a local service that is called by the presentation layer, the workflow instance is then notified of the event (for example, the Next event) and updates its state accordingly, and a notification is sent back to the client application (possibly through a CallExternalMethod activity) so that the client can update the user interface. This interaction is shown in Figure 2.

Figure 2: Decoupled architecture for presenting the user interface based on workflow state

As an alternative, the workflow can be made responsible for also showing the appropriate user interface in response to state changes. Figure 3 illustrates this architecture.

Figure 3: Workflow responsible for presenting user interface based on workflow state

In both cases, Workflow persistence can play an important role – allowing users to close the application and later on resume where they left off. The next two sections will explore these two architectures in the context of ASP.NET and Windows client applications, respectively.

ASP.NET Presentation Flow

Web sites and enterprise web applications can often have a large number of content pages – some of which may require coordination of presentation flow in the form of a wizard. In some cases, wizards can reuse pages or present them in a different order to the user. It can be cumbersome to manage the navigation rules for each page within the code for each page, particularly if it is reused in different contexts. Visualizing page flow and abstracting the navigation logic from each page can improve overall manageability and flexibility of the site or application.

Figure 4 illustrates an example with a series of pages that an ASP.NET application might present to handle user registration for a newsletter. The first page prompts the user for their topics of interest, the second prompts for their e-mail format preference, and the final page asks for their name and e-mail address.

Figure 4: ASP.NET pages collecting newsletter registration details in a wizard

The next section will describe the implementation architecture when using Workflow to control presentation flow.

Implementation Architecture

Figure 5 illustrates the state machine workflow design representative of the wizard shown in Figure 4. Each page is represented by a state. Supported events for each state indicate navigation between pages for Previous, Next and Finish buttons.

Figure 5: State machine workflow for the page flow illustrated in Figure 4

The logical flow for this scenario is as follows:

• When the workflow is initialized, state begins as Page1. The application redirects to Page1 after evaluating the workflow’s initial state.
• From Page1, the user navigates by clicking Next. This triggers an event that initializes the workflow and calls the Next event handler which advances the workflow to Page2 state.
• The application detects the new state and redirects to Page2.
• From Page2, Previous or Next can be selected by the user, resulting in a new state and similar behavior to redirect accordingly.
• From Page3, if the user selects Finish the workflow ends and navigation is complete.

The code to redirect to each page can be contained within the workflow itself, or the application can inspect the new workflow state and handle the redirection. In either case, navigation is not hard-coded into each page – instead some reusable logic encapsulates navigation based on workflow state traversal. For this to work, the workflow must execute on the page’s request thread instead of asynchronously. This is achieved by configuring the workflow runtime to use the Manual Scheduler Service.

Figure 6 illustrates a possible architecture for this scenario.

Figure 6: ASP.NET presentation flow architecture

To minimize the startup cost for each page request, an instance of the Workflow Runtime is stored in the ASP.NET cache. When a user visits the first page in the workflow, a new workflow instance is created and the identifier for the instance is stored in the user’s session state for later use. As users interact with pages in the wizard, the code to handle each request retrieves the Workflow Runtime from the cache, requesting the workflow instance stored for the user session.

Persistence services are enabled so that the workflow instance can be retrieved despite worker process recycling or the presence of a web farm – resuming execution where the user left off.

Event handlers in each page rely on a local service to raise the appropriate event to the workflow instance. Since the manual scheduler is used this is a blocking call that will allow the workflow to advance state and return control to the page. If the workflow does not handle the redirect, when control returns the page (or, some central processing logic for all pages) can handle the redirect based on the new workflow state.

Windows Client Presentation Flow

Windows applications that present a large number of screens, or that involve wizard-driven UI can also benefit from decoupling navigation logic into a Workflow. There may also be complex business rules that should be executed for each state in the wizard, and these can be completely encapsulated into the workflow. In fact, one of the benefits of state machine workflows is that you can visualize the top level flow of navigation and drill down into each state to view a sequential workflow representation of more complex logic.

Figure 7 illustrates the success path for a dialog-based installation program built with WPF. Each dialog either collects information from the user or presents information about the status of the installation with a familiar wizard-style experience for the end user.

Figure 7: A series of dialogs in a WPF installation program

The next section will describe the implementation architecture for this scenario. In this case this will involve both state machine and sequential workflow, since each workflow state will handle logic for that stage in the installation.

Implementation Architecture

The installation program is a WPF application that hosts the workflow runtime. The executable itself does not directly hold logic for configuring and performing the installation. Instead, it bootstraps the installation process by kicking off a workflow instance and then waiting for it to complete before exiting. The workflow is responsible for presenting each screen as a modal dialog, executing installation logic before and after each dialog is presented, and waiting for user input before advancing to a new state. Since the workflow holds all the business logic, there is no need for the host application to interact with the workflow using local services.

Figure 8 illustrates the top level state machine workflow describing the outer flow of the installation program and the dialogs associated with each state if applicable.

Figure 8: Activity Execution Displays Windows Forms

Each state contains a workflow sequence with business logic for that particular state in the installation. You can drill down into each state to view each sequence, and drill up using the breadcrumb control as shown in Figure 9.

Figure 9: Workflow sequence for the ExecInstall state

One of the benefits of using workflow for this installation scenario is that it becomes possible to model how to handle an error that happens during the installation. In this case, any files copied must be removed if the installation is cancelled, to return the system to its state prior to installation. A workflow can include compensating logic for any part of a workflow – via a CompensatableSequenceActivity like InstallOrRollback from Figure 9 – to respond to an exception. Figure 10 illustrates selecting the compensation handler view of a CompensatableSequenceActivity, and Figure 11 illustrates this view. The compensation handler is executed if an exception occurs during the ExecInstall activity – and will remove copied files from the file system.

Figure 10: Selecting the view for a CompensatableSequenceActivity

Figure 11: A CompensationHandlerActivity with rollback code

Common Questions

Q. Can I use the same workflow to drive the logic for both ASP.NET and Windows clients?

Yes. The ability to define the logic for presentation flow once and use it to drive the presentation of both ASP.NET web pages and Windows client applications is possible by creating a single workflow. The primary difference between these two models is the threading models used by the host to both run the workflow as well as process the user’s interactions. In the ASP.NET scenario you would have to plug in the ManualWorkflowSchedulerService so that workflow executes on the same thread as the page request. Otherwise the workflow executes asynchronously and other than polling from the browser, there is no way to update the current page or redirect to a new page as a result of a new workflow state.

In the Windows client scenario, is possible to use either scheduling service. If the DefaultWorkflowSchedulerService is used the workflow does not run on the UI thread and additional code is required to facilitate communication between the main application and the workflow – in particular to respond to state changes that trigger new UI. If the ManualWorkflowSchedulerService is used the workflow runs on the UI thread. In this case workflow activities can display modal dialogs to advance UI. This removes the need to coordinate interactions between the application and workflow.

Q. Is it a good idea to show modal dialogs from a workflow used for Windows client navigation?

Showing modal dialogs from a workflow implies that when a dialog is closed, the workflow advances and ultimately shows a new dialog. This can result in unwanted flicker as one dialog closes and another is presented – but this type of presentation style is generally accepted in applications such as installation programs. A business application usually requires a smooth transition between dialogs and so the extra effort to implement communication between the UI thread and the workflow is worth the effort. Events raised from the workflow can pass data to the main application which in turn presents the appropriate UI based on workflow state and data.

Q. What are performance implications for using workflow in an ASP.NET application?

When Workflow is used in the context of a long-running process, the overhead of loading the workflow instance for a page request is not an immediate concern. When Workflow is used synchronously to drive page navigation, this overhead is more noticeable. Web sites that have very complex UI navigation may find the trade off of performance is offset by the benefit of visualizing page flow in the Workflow Designer. With the release of .NET 4.0, optimizations to the Workflow Runtime will make this an even more viable option.

Q. Why use Workflow instead of ASP.NET MVC implementation?

MVC is a natural fit for ASP.NET page flow however it does not provide the visualization features of the Workflow Designer . For very complex UI navigation Workflow may be preferred. 

Q. How are pages kept in sync with the Workflow if the user hits the Back button?

Each page can include a view state variable that holds the Workflow instance identifier and the state that the page was loaded from. With this, when a user navigates backward and posts back, the view state can be used to load the correct workflow and either advance the state to the view state value, or notify the user that they are in error – according to application requirements.