There are many really great things about using workflow as the logic behind your application. The one that really excites me is the visibility workflow gives you into what your application is doing.
Another great thing is that many types of applications are naturally workflows, and so using workflow for those applications is really a no-brainer. One of the most-often cited examples is page flow in ASP.NET. Moving a user from page to page in an ASP.NET application is really a workflow.
Now, until the ASP.NET team and WF team come out with something official in terms of integration, using WF as page-flow is going to be kind of ad hoc. Here is my take on one way to do this.
Here are the goals I had in mind when I built this sample (which is based partly on other applications I have built already using WF and ASP.NET).
1) The WF and the ASP.NET Pages should be unaware of each other. ASP.NET shouldn’t know it is being run by a workflow, and the workflow shouldn’t know it is being called from ASP.NET.
2) The ASP.NET model should be preserved. What I mean by this is that ASP.NET pages should be written using a control-based, data-bound methodology. I also am a big fan of ASP.NET 2.0 and all the work they have done to make building pages easier. Some other examples of using WF with ASP.NET I’ve seen make the pages go out of the regular model. IMO – there is a reason for the page model in ASP.NET and I wanted to try to preserve that model in my integration. So this means using server-side controls and events, along with data-binding.
Here is an overview of this sample. First – there is a state-machine based workflow. Although a sequential workflow would work, state-machine is really more appropriate for this scenario (see Dave Green’s post here about the two different models).
The workflow takes as parameters an OrderedDictionary and a string. The OrderedDictionary holds onto the real parameters. The reason I use an OrderedDictionary is to make the ASP.NET model easier to use. With declarative data sources in ASP.NET 2.0, generally the data source control takes care of processing the form data (and other data, like sessions or cookies) by using a ParameterCollection. The ParameterCollection is made up of Parameter objects which are responsible for extracting data from controls, the session object, or other objects. The data source control can then use this to actual perform CRUD operations. The idea is that the page can be written using the normal model – and then the parameters are gathered by the data source control, and rather than have the parameters processed by the data source, the parameters are passed into the workflow. My concept here is to let ASP.NET developers write pages using their regular model and then integrate with WF seamlessly.
So this could be done by using an existing datasource and extracting the parameters:
base._params = SqlDataSource1.SelectParameters.GetValues(HttpContext.Current, SqlDataSource1) as OrderedDictionary;
Or by manually packing up parameters into an OrderDictionary instance:
//manually create the parameters
this.Parameters = new OrderedDictionary();
this.Parameters.Add(TextBox1.ID, TextBox1.Text);
this.Parameters.Add(TextBox2.ID, TextBox2.Text);
The other parameter to the workflow is just a string. This is what I call the “command”. The concept is that the page will pass a “command” to the workflow, and then based on the way the workflow is written, the workflow will pass back to the page the next “command”. Based on the next command value, the integration layer between the pages and the workflow will redirect to the next page. The next page value is also based on configuration. The idea is that the configuration mapping will control what page is next in the flow, and that the workflow will just be passing back the next “command” which will then be mapped in configuration to a page. This keeps the workflow from knowing it is running a page flow and the page from knowing it is using a workflow.
After the workflow starts, it continues to live (placed in ASP.NET session) and then is invoked for the rest of the page flow. The workflow instance then waits for communication from the host (which is really implemented in a single class called WorkflowWrapper). These events (a custom activity based on HandleExternalEvent – generated using the wca.exe tool) also take an OrderedDictionary and a string. The events also use correlation; this is why the external data exchange interface only needs on event.
The CallExternalMethod activity passes back to the host (through the local service implementation) a DataSet, and the “next” command. The next command is used to redirect based on the configuration, and the DataSet is placed in ASP.NET Session. When the next page is executed (after the redirect) the page can extract the DataSet from ASP.NET Session (all the operations of each page is actually wrapped in a BasePage class implementation).
The other interesting thing about each ASP.NET page is that none of them directly calls the workflow or handle control events. The base page class does this. Rather than limit the kind of controls that each derived class can use, the base class overrides OnBubbleEvent, and then just extracts the control as an IButtonControl, which means this will work with Button, LinkButton, or ImageButton (to handle other kinds of controls that post-back this method would have to be modified).
The local service and the event activities are separated into a separate library – as is the workflow. To make this same example work with say a set of Windows Forms – there is just one line of code in the local service implementation that would need to be changed (the line that stores the result of the CallExternalMethod in the HttpContext.Items collection).
In this example – Default.aspx is the first page in the flow. It has two text boxes, the values of which get passed to the workflow. The next page is Page2.aspx and it gets two DataTables from the DataSet and uses it to bind a GridView and a DropDownList. The rest of the pages just flow – there isn’t any really functionality going on with them. If you go into the web.config – you can move pages around in the configuration and make the flow of the pages different.
I probably will have more to write about on this topic – so this is just the first post. I am interested in ideas of comments anyone has on this topic, so feel free to critique my design – as I said this is just my beginning thoughts on how to use WF with ASP.NET – my next task is to create a custom datasource control for WF specifically.
aspnetwfpageflowexample.zip (127.88 KB)
).
