Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows)

In the last two posts 101 and 102, I went pretty deep in some areas. I want to step back and do some more tutorial stuff. So the first question out of the gate is what is Workflow itself and where might you use it? In a nutshell, a Workflow describes and automates a Business Process. It can be described as a "reactive" program which tends to contain some traits:

1. Workflow declared as a set of Activities
2. Coordinates people and software
3. Has real-world control flow
4. Runs reliably and durably
5. Tolerates dynamic change

A Workflow is typically designed by a Process Designer using Business Process Analysis, Modeling, and Definition tools. That Process Definition is fed into a Workflow Management System. The WMS will have Users, Applications and Administrators/Supervisors. The WMS will present that Process Definition visually in some form and launch applications.

From looking at workflows, we see that some challenges are present. Unlike non-reactive programs, workflows tend to be long-running and stateful. It may take 20 days for an order to be shipped for instance. There usually needs to be some controls to allow a person to override or skip a step in the workflow. Finally, we must be able to see into the workflow and see what state its in and visualizing control flow. Workflow is used in many scenarios like:

• Business Process Management (BPM)
• Document Lifecycle Management (Sharepoint, K2)
• BizTalk Orchestration
• Sales Management
• Line of Business Apps
• Many others...

Enter Windows Workflow (WF). Unlike K2 and Sharepoint, WF is not a Workflow Management system or product. It is instead, a general purpose framework for building workflow into your own applications. It ships as part of the .NET Framework 3.0, and ships with both Vista and Longhorn Server. It is installable on Windows XP SP2 and Win2K3. Since WF is baked into Vista and later systems, and is a general framework, it is a single workflow execution engine for all Windows platforms. Indeed, products like K2, Sharepoint, BizTalk, and may others have been changed to be built on WF. The are a lot of extensibility points in WF so you can build it into your app but the point bears repeating: it's not a workflow management product and thus you are responsible for hosting it.

Now, time for some WF concepts. Workflows are a Set of Activities. Workflows (or more properly workflow instances) run inside a host process, which can be any AppDomain, from a console app to a Windows Service and anything in-between. Developers are encouraged to build their own Custom Activities. WF itself, comes with an extensive set of Activities in its Base Activity Library. WF also has a Runtime Engine that executes workflows and handles state management. WF also allows an extensible set of activities to be added for things like Persistence, Tracking, and Communication. The model is quite flexible, as except for certain minimal services that must have a default implementation, it's an opt-in model and you only add services you need, keeping the WF Runtime light. Finally, WF has a Visual Designer that manifests in Visual Studio, but since its a general framework, you can create your own domain-specific designer as I am doing for Collateral Management.

There are two main kinds of workflows in WF: Sequential and State Machine. Sequential workflows are like flowcharts and are structured, step-by-step (maybe that's why they're called sequential!) but can and usually do contain branching. They are good for automation scenarios. Meanwhile, State machine workflows are reactive and event-driven. They transition from state to state based on events, usually triggered externally.

A Workflow in WF is an instance of a class but also can be represented in XAML. There are several Workflow Authoring Modes:

1. Markup-Only (Declarative)
2. Markup and Code
3. Code Only
4. Application-Generated

I am going to leave a discussion of authoring modes until later. Now, looking again at Activities, they have been called "resumable program statements." They are the building blocks of a workflow, as the basic Activities are the basic steps in a workflow. A Composite Activity is an Activity that contains other Activities. Since an Activity is a class, you build one as follows:

1. Derive from an existing Activity or from the base Activity class
2. Override Execute()
3. Add Properties/Dependency Properties

I talked about Hosting the WF Runtime in Part 101. Again, its a lightweight execution environment for workflows or as they are called "WF Programs." To be lightweight and allow ultimate flexibility, it must be hosted in an AppDomain, which can be a console app, Windows Service, Web Service, ASP.NET, Avalon app, etc. And again, the services are pluggable. Hosting and running a workflow is fairly simple:

using(WorkflowRuntime workflowRuntime = new WorkflowRuntime()) { // Factory method WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof (FirstWorkflow.SayHello)); instance.Start(); // do your stuff here } }
  

I am going to leave off there for now. Next part, I will dive deeper into hosting the runtime and services. Please do drop a note on how this article is - is it helpful?