Browse DevX
Sign up for e-mail newsletters from DevX


Working with Windows Workflow Foundation in ASP.NET : Page 3

Using Windows WF, you can create processor flow-based workflows and host them in any type of .NET application. ASP.NET developers face a unique set of issues that can benefit from workflows, such as maintaining state and page navigation.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Implementing the Controller Logic
Next you need to implement the controller logic as an HttpHandler. To construct the controller, all you need to do is create a class called WorkflowControllerHandler that implements the IHttpHandler interface. So far, nothing you've seen is specially related to Windows WF—this is functionality native to ASP.NET (see this article for more information).

In the WorkflowControllerHandler class, the IHttpHandler interface method called ProcessRequest handles a Web request from the ASP.NET application. Here, you need to obtain a reference to a static workflow runtime instance, setup the event handlers for the workflow, and kick off the workflow execution. Before starting a workflow instance, you need to check to see if the request's query string values contain a GUID representing a workflow instance ID. If the ID is present, you know that an instance is already running, so you can obtain a reference to that instance, and continue execution. If the ID is not present, you need to create a new instance and begin the execution process by calling the StartWorkflow method of the workflow runtime.

After starting an instance, the event handlers will manage communications to and from the workflow. Because the purpose of this article is not to cover local communication services, I will not go into great detail on that subject here. Rather, I will cover the high level details, and again, how this might work in an ASP.NET application. To facilitate the communication process, you'll need several .NET interfaces that represent the messages sent to and from the workflow and host. You will find these in the WorkflowClassLibrary project in the sample code provided with this article. You'll also find classes that implement these interfaces and the respective functionality necessary for the workflow to function.

Take another look at the web.config file. Notice that next to the ASPNetThreadingService element discussed earlier, there will be three elements representing the communication service classes:

<add type="Workflow.RuntimeServices.GetNameService, Workflow.Library, Version=, Culture=neutral, PublicKeyToken=c4620ae819b5257e"/> <add type="Workflow.RuntimeServices.GetEmailService, Workflow.Library, Version=, Culture=neutral, PublicKeyToken=c4620ae819b5257e"/> <add type="Workflow.RuntimeServices.SendDataService, Workflow.Library, Version=, Culture=neutral, PublicKeyToken=c4620ae819b5257e"/>

Also present is an element that instructs the workflow runtime to use the SqlStatePersistenceService. This additional service persists a workflow's state to a SQL Server database between page requests. You must create this database manually ahead of time, but Microsoft provides the SQL scripts to do this. You'll find them in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Windows Workflow Foundation\SQL folder. Like the threading model service, you could have added these services programmatically, but doing it in the configuration cuts down on code and provides flexibility even after the code is in production. Also in the web.config is a line that adds an HttpModule that supports the Windows WF runtime in ASP.NET, and a line setting up the HttpHandler controller discussed earlier. As you can see, there is a lot going on in the configuration file.

In conclusion, Windows WF provides developers with an extremely versatile and extensible framework on which to develop workflow based applications. Implementing business processes has and will continue to be an important application of technology. Unless you are a technology services firm or ISV, software is there to support the business and its processes. With a tool such as Windows WF developers can approach process development with a new sense of ease and flexibility.

Todd Kitta currently works for Oakwood Systems Group, a technology solutions provider in St. Louis, MO. He is a Senior Consultant focusing on Microsoft technologies, mainly custom development. Todd enjoys learning about and building software with emerging technologies and writing for his EAI and Workflow blog. He's the author of the soon-to-be-released book Professional Windows Workflow Foundation.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date