About a year ago I wrote some software for Microsoft that included a Web application that drove workflow to create a Word document filled with specific (and dynamic) information. It was interesting combining workflow with ASP.NET as there are things you have to do in addition to the normal workflow hosting. For one thing, workflow persistence is mandatory because the workflows would be considered long-running. For another, you can't use the typical thread management as you'd be tying up IIS threads. I didn't write about this in my workflow book since it wasn't part of the typical workflow thought process at the time, which perhaps was too limiting on my part. I liked the demos I created for that book, but prior to its release, the workflow community did see workflow more related to Windows Forms or WPF applications.
Now that we have ASP.NET MVC 2, WF 4, and a host of new technologies, it's time for me to dig in a little. I also edited Dino's terrific Web architecture book, Microsoft® .NET: Architecting Applications for the Enterprise, and am editing his awesome upcoming MVC book, tentatively entitled "Programming Microsoft® ASP.NET MVC". (If you already own every MVC book out there, trust me you'll want this one too...very "internals" oriented). I'd love to work out an example prescriptive site or two just to put some of this stuff into practice.
So, open kimono time... The only way to learn this stuff is to DO this stuff. So I came up with an idea. I'd wondered about combining workflow in a Web application using SMTP to authorize things. That is, imagine an enterprise-class Web application that forwards authorization requests to a manager for approval. The request could be anything, but I'll pick....oh...vacation authorization. So you go to the HR site, place a demand for vacation time, and the application forwards your manager the request. The e-mail has an embedded link that fires up the app in the manager's browser, they click yes or no, and the system notifies you of their decision. I'm sure everyone but me has written this, but I thought it made for a good scenario to work with MVC 2 and WF 4. We'll see about working in the Silverlight once the foundational components are in place. I say that only because SL can do some really powerful UI's, and this scenario ain't it. But it might make a good seque into RIA services. (!)
What I write here is raw stuff. Maybe it's well architected and maybe things should be refactored. That's fine...I'm playing with concepts more than anything. If you see glaring omissions or errors, by all means comment! We all learn more that way.
The first thing I see I'm going to need to do is determine the difference between traditional WF persistence and something I'm seeing called "workflow instance store." Is one perferred for Web apps? I honestly don't know yet, but I'll research it a bit and report back. It'll matter because I'll create a SQL Server 2008 database and need to run the appropriate scripts (both sets of which are provided with Visual Studio 2010). I'm starting here because, to me, the app is there to serve the data, not the other way around. I'll design a rudimentary database, just enough to support my scenario, and then layer over that LINQ code to interface with the application service layer. That, then, drives the user interface, at least for this scenario.
So, next time I'll describe the differences in WF persistence and design a small database to support this application scenario. If anyone reading this has questions or comments, all are welcome. :)
Categories: .NET General