Workflow Foundation Usage Patterns. Part II.

Before I continue describing WF usage patterns, small personal announcement: I'm changing this blog's title from "Thoughts on Architecture" to simply "Technical Blog". This seems to be more prudent, since I am not always discussing software architecture and am not even an architect anymore (my new job title is development manager, but enough about me).

Workflow In Business Layer

When we follow the principles of layered architecture, we usually end up with two types of objects in the business layer: entities and workflows. Entities, of course, map more or less directly to domain entities - products, orders, claims, or what have you. Workflows, on the other hand, manipulate entities in order to implement specific business process. For example, business process of registering new customer may include creation of Client, Address, and CreditCard entities, validation of the last two, transmission of a welcome email, etc. Of course, there are many ways to skin the cat, but typically you would employ some sort of business workflow object.

What attracted me to implement business workflows using WF was the ability to compose workflows from custom activities. We often had a situation where the same process had to be customized for different partners. In the example above, a customer may belong to a partner which does not require credit card validation. Engineers used to create new version of business workflow by copy-pasting relevant method in the class and tweaking it. My idea was to create a set of basic WF activities that represent pieces of the process, then combine them together using WF designer rather than C#.

Contrary to the pattern I described in the previous post, this one doesn't represent a long-running process and workflow instances are never persisted to database. Another side benefit is simplified maintenace due to improved readability: it's much easier to understand the logic by looking at workflow designer than raw code. Workflows become, in a sense, a live technical documentation of the system, on the par with unit tests and Visual Studio class diagrams.

There are a couple of caveats with this approach. First of all, beware of performance penalty from using WF and be sure to stress-test your system. In my case, business workflow executed as part of a batch process, not web application, so I didn't have to worry about user experience. Second, keep in mind that WF world is very asynchronous, so you can't really treat the workflow like just another procedure call. You create workflow instance, assign input parameters and start it. If you want to get the results back from that instance, you need to do extra work with the runtime.

PatternShare Is Gone

I used to keep a link to PatternShare community website on the sidebar of this blog. It turns out, the site (which was maintained by PnP team) is no longer active. The reason I am blogging about this is because we spent a full hour on PnP Summit today discussing the fate of PatternShare. The key question was where PnP should be spending its efforts: on embedding relevant patterns in its tools (application blocks, factories, guidances) or educating people by writing books and creating new version of PatternShare? There were plenty of arguments on both sides. I think the consensus opinion is that education is important, but even if PnP provides the books, there is no guarantee that people will educate themselves. Programmers are more likely to use free tools. But does good tool make bad coders smarter? Or does it make them more dangerous?

I still think design patterns should be taught in colleges...

Workflow Foundation Usage Patterns. Part I.

Today during Patterns and Practices Summit Ted Neward gave a presentation on Windows Workflow Foundation. One of the points he made is that although "Workflow" as a programming concept is fairly old (arguably older than object-oriented programming), WF as a product has been out for less than a year. Thus, it is premature to talk about best practices and proven patterns.

I agree with Ted, and in this post I'd like to share my experience designing real-life systems that take advantange of WF. As an architect, I had to choose the niche for this shiny new technology. It wasn't an easy task, because WF represents extremely flexible and universal concept. On the other hand, it is a new technology, so I wanted to minimize the risk and not use WF as a cornerstone of the system. Instead, it should be pluggable, something that's easy to turn off.

Job Orchestration

Imagine an application that prepares and sends a file to several business partners, then waits for response files and processes them. Even assuming fully automated file upload/download, the whole thing can take hours or days. My original approach was to write separate jobs that handle individual tasks, such as preparing request file, processing response file, upload, and download. It worked, but it was difficult to reconstruct the business process from individual job results. In other words, we know that a job has executed successfully, but business users wanted to know where do we stand in the larger process.

In order to solve this problem, I used WF's ability to implement long-running workflows. I represent a process with a workflow that contains the sequence of job launch activities. After a job is launched, workflow idles and is persisted to SQL data storage using SqlWorkflowPersistenceService. When job completes execution, it sends a signal to workflow runtime, which loads correct WorkflowInstance from SQL and resumes it. Note that workflow itself doesn't contain any code whatsoever and can be written in pure XAML - it represents a logical sequence of jobs.

Business users were particularly pleased to see the Visio-style diagram of the workflow which clearly showed what's completed, what's running, and what's pending. For this I used the ability of WorkflowView control to save itself as an image.

[To be continued]