Windows Workflow Changes Direction: Write New Workflows with .NET 4.0 in Mind
You can tweak your 3.0/3.5 workflows to make the transition to Windows Workflow Foundation (WF) 4.0 a little easier. These guidelines limit the scenarios in which there's no corresponding feature in 4.0.
- Create custom activities. Create custom activities instead of code-beside logic in a CodeActivity. There's no CodeActivity in WF 4.0. Remember that the custom activity model also changes, so it's best to move complex code out of the activity into utility libraries or services.
- Scope tightly. 4.0 variables are more constrained than 3.0 dependency properties. They no longer use the property bag/dependency property approach but instead are scoped vertically. Choose a variable in a parent activity set retrieved by child activities rather than directly retrieving data from a
sibling activity.
- Use Windows Communication Foundation (WCF) messaging when there's a choice. The Data Exchange Service (DES) model goes away in WF 4.0: there's no external event model; external communications is through WCF; and WCF interactions will be considerably easier in WF 4.0. For workflows that might transition to 4.0, write them in WF 3.5, and use the Send and Receive activities. However, if you don't yet have WCF in your application or organization, implementing it in WCF 3.5 may be onerous. In this case, use events, and assume you'll rewrite around the new communications approach.
- Perform initialization logic in the Activity.Execute method. The signaling model changes in WF 4.0, and there's no Activity.Initialize event. Any setup should be done in the Activity.Execute method.
- Use WorkflowInstance.EnqueueOnIdle for queuing. If you're doing manual queuing, which is relatively uncommon, you should use the EnqueueOnIdle method, as this will be the only queuing model supported going forward.
- Be careful with data. The tracking and persistence databases are likely to change significantly between 3.5 and 4.0. Holding data only in tracking is hazardous, unless you prepare a strategy for extracting data, such as when a workflow completes. If you're using rules for simple data retrieval for values that should be set outside the workflow, consider holding this data in a configuration file or database.
Note that these are preliminary suggestions. Check out my blog for pointers towards Microsoft's formal guidance, as well as tools (as they become available) that will help you transition workflows.