Should I use a state machine or a sequence workflow in WF?

Question

I have a repeatable business process that I execute every week as part of my configuration management responsibilities. The process does not change: I download change details into Excel, open the spreadsheet and copy out details based on a macro, create a Word document from an agenda template, update the agenda with the Excel data, create PDFs from the Word document, and email them out.

This process is very easily represented in a sequence workflow and that's how I have it so far, with COM automation to handle the Excel and Word pieces automatically. The wrench in the gears is that there is a human step between "create agenda" and "send it out," wherein I review the change details and formulate questions about them, which are added to the agenda. I currently have a Suspend activity to suspend the workflow while I manually do this piece of the process.

My question is, should I rewrite my workflow to make it a state machine to follow a best practice for human interaction in a business process, or is the Suspend activity a reasonable solution?

Answer 1

No, I don't think that you have to use a state machine for this workflow. But, I propose to change the Suspend activity because:

The SuspendActivity activity temporarily stops the execution of the current workflow. Typically, you use the SuspendActivity activity to reflect an error condition that requires attention by an administrator.

When a workflow instance is suspended, an error is logged. You can specify a message string to accompany the error to help the administrator diagnose the problem with the SuspendActivity Error property. A suspended workflow instance can still receive messages that are queued up until the workflow is restarted. All the state information for the workflow instance is saved and is reinstated when the instance is resumed (using Resume).

Source: MSDN

The typical way for adding a human task in a workflow (either sequence or state machine) is to define an External Data Exchange interface and use a HandleExternalEvent activity (and possibly a CallExternalMethod activity). For more details, please see the following articles:

• Building State Machines with Windows Workflow Foundation
• Simple Human Workflow with Windows Workflow Foundation

Answer 2

Update: Panos makes a good point about Suspend Activity. I agree it has a different purpose in the workflow automaton.

If you feel you are worrying more about workflow transitioning between various states, then state machine workflow is ideal. Otherwise, sequence is just fine.

The main problem you should be trying to solve is that the workflow should not tie up a thread while waiting for the human interaction (thread agility). If the workflow is idled and persisted during that time (like using SqlWorkflowPersistenceService), it should not be a problem.