Tutorial: Create a Workflow Application with ASP.NET

Article
03/05/2010

When hosting a Workflow application in ASP.NET there are several things to consider; specifically, creating the Workflow Runtime, managing page flow, and persisting and retrieving data. This tutorial walks you through a series of steps to create a basic workflow library and a Web site that runs and interacts with workflows. This tutorial demonstrates the following Workflow topics:

Creating the Workflow Runtime.
Adding services to the Workflow Runtime.
Communication between the workflow and the host application.
Storing and retrieving Workflow tracking information.
Workflow persistence.
Manual workflow scheduling.

In this application, the workflow runtime will be created at application start, and will be stored in the Application collection. The page will then reference the runtime via this collection; this way, the entire Web application will use the same runtime instance.

When the runtime is created in the Application_Start event handler, services for tracking, scheduling, persistence, and host communication are added. The scheduling and host communication services will be accessed via GetService when they are needed, but the tracking and persistence services work with no further interaction with the host application.

Communication between the host application and the workflows is accomplished in three ways:

Parameters are passed from the application into the workflow when it is created. These parameters are sent as arguments to the call to CreateWorkflow.
Messages are sent from the host application to the running workflows using a local communication service.
Messages are sent from the workflows to the host application indirectly, via the tracking infrastructure. The workflow stores information about itself to a SQL database using the TrackData method. This tracking data is then retrieved by the host via a SqlTrackingQuery. This method is used instead of the communication service, because in a stateless ASP application there will be no running user code to handle events generated by the workflow.

This application uses the out-of-box SqlWorkflowPersistenceService to persist idle workflows. Apart from adding the persistence service to the runtime, no further user code is needed for persisting workflows; the runtime will persist, unload, and reload workflows automatically as needed once the service is in place.

Due to the requirements of ASP applications, the application needs to run workflows in its own process. The default workflow scheduling service cannot be used because it runs workflows in their own process. Instead, this tutorial uses the ManualWorkflowSchedulerService to drive workflow execution.

The application that you will build in this tutorial is a loan approval simulator. The first part of the application allows the user to create a loan request. When a loan request is entered, a new workflow instance is created and started. Once started, the workflow records tracking information, then idles and is persisted to a database and unloaded, and the runtime waits for a message from the application. The second part of the application allows the user to view existing loan requests (via retrieving tracking information). The user can also mark existing loan requests as approved or declined; this sends a message to the associated workflow via the workflow runtime. When the runtime receives the message for the workflow, the workflow is reloaded; the workflow then receives the message using a HandleExternalEventActivity. The workflow then records whether or not the loan was approved (via the workflow tracking infrastructure), and then completes.

You will need Internet Information Services installed to complete this tutorial. You will also need Microsoft SQL Server or MSDE for workflow tracking and persistence.