Here is a detailed description on one of the most simple solutions for achieving a parity between ASP.NET and Windows Workflow (WF). In this way it is possible to leverage the capacity of Windows Workflow’s visual logic for designing the page-flow based on user preferences. Without Windows Workflow, enforcing page flow would not be possible.

This article covers the three main tasks that are involved in building the solution: establishing the Workflow side, writing a middle bit—a service layer— that comprises of the complete interface, and building the ASP.NET side. After that,. A step by step guide that describes the way to create a solution. It is important to instal Visual Studio 2005, this is the Web Application project for Visual Studio 2005 and also for the .NET Framework 3.0, that includes the Windows Workflow.

The way in which Windows Workflow communicates with ASP.NET

All the aspects of a Workflow are activities. An activity connects and communicates with the outside world through a Workflow Service. The activity intimates the service about its requirements. For instance, it might ask a service the details regarding the user’s name and email address, after which it response is awaited. The ASP.NET code responds to all the events fired from this service, this process redirects the user to an appropriate web page that includes the input fields for the name and address. When the user enters the appropriate information; the data is submitted back to the server. ASP.NET fires an event that intimates the Workflow service that a response is available. In this situation, the relevant data is stored in a simple dictionary and is passed between Windows Workflow, ASP.NET and the service layer in serialized format.

Let us have a look at the service layer first, as the code involved in it requires most work.

The Service Layer

The Workflow activities communicate with things outside the Workflow with the use of Workflow Services. A Workflow service is described by its interface. In this case, an interface is required that involves with one method and one event. The Workflow activities will connect with the interface method to request data, and subscribe to the interface event in order to know when data has been received.

Here’s an IGenericInformationService interface that resembles to a Workflow service. This interface provides most of the factors that are required by the Workflow for operating smoothly.

[ExternalDataExchange]
   public interface IGenericInformationService
   {
      string InformationName
      { get; set; }
   
      event EventHandler 
         InformationReceived;
   
      void RequestInformation( string informationName );
   }

The preceding interface is comprised of one event, one property and one method, that makes it a very simple yet efficient service that includes everything required to request and receive information. However you must note that this interface is used solely by the Workflow, the Workflow is not really aware about what happens within the implemented version of the RequestInformation method or what code fires the InformationReceived event.

It is important to supply an implementation of the above mentioned interface. In addition to the implementation of IGenericInformationService, the GenericInformationService class also adds another event, InformationRequested and another method called SubmitInformation. In this case, both Windows workflow and the ASP.NET code will use this class; the Workflow will call RequestInformation and then it will wait for the InformationReceived event. ASP.NET will also wait for the InformationRequested event and will call SubmitInformation when the user has filled in the information.

It is important to note that the InformationReceived event uses a GenericInformationEventArgs class, defined as:

[Serializable]
   public class GenericInformationEventArgs
      : ExternalDataEventArgs
   {
      Dictionary _propertyBag;
   
      public Dictionary PropertyBag
      {
         get { return _propertyBag; }
         set { _propertyBag = value; }
      }
   
      public GenericInformationEventArgs( Guid instanceId, 
         Dictionary propertyBag )
         : base( instanceId )
      {
         _propertyBag = propertyBag;
      }
   }

GenericInformationEventArgs is a simple class that exposes a property bag or Dictionary and extends the ExternalDataEventArgs class defined in System, Workflow, Activities.

The Workflow Side

Everything in a Workflow is based on activities. In order to control the page flow with Workforce it is possible to create activities that ask for information, activities that perform some logic based upon the returned data and activities that wait for data. The activities use a Workflow service to request and receive data. The Workflow navigates with an existing service called the ExternalDataExchangeService. This also contains other services, and one of them will be GenericInformationService described in the previous section.

The ASP.NET Side

The ASP.NET application will make the use of GenericInformationService to wait for an event (the InformationRequested event). This signifies that the Windows workforce is requesting information. On the basis of the InformationName, it will decide about the page that is to be displayed to the user. When the user has filled the appropriate information in the appropriate page, the information will be submitted back to the service through the SubmitInformation method.