WF 4.0 changes

Rick Garibay has two very interesting posts on the changes that WF 4.0 will bring and the impact on existing WF 3.5 apps:

Copy of some important points:

  • WF developers should stop using custom code activities and opt for custom activities instead.
  • In WF 4.0, all aspects of an activity are represented as XAML. Most importantly, this includes variables within each activity which are bound as input/output parameters from one activity to another. This is a significant change from 3.5 because variables are no longer scoped at the global workflow level, but instead are scoped to the activity level.
  • Should we continue to build composable service-oriented applications with WF 3.5 or bite the bullet and build on early WF 4.0 bits? Well, according to Cliff Simpkins, Office 14 is shipping with 3.5, and if Microsoft is willing to invest this heavily in 3.5 in a brand new product that hasn’t shipped, you can imagine that it should be suitable for LOB applications as well as the enterprise.

PDC 2008: WF and Oslo Resources

  • TL17: WF 4.0: A First Look, Kenny Wolf
  • TL23: A Lap around “Oslo”, Douglas Purdy, Vijaye Raji
  • TL27: “Oslo”: The Language, Don Box, David Langworthy
  • TL06: WCF 4.0: Building WCF Services with WF in Microsoft .NET 4.0, Ed Pinto
  • TL18: “Oslo”: Customizing and Extending the Visual Design Experience, Don Box, Florian Voss
  • TL28: “Oslo”: Repository and Models, Chris Sells
  • BB18: “Dublin”: Hosting and Managing Workflows and Services in Windows Application Server, Dan Eshner
  • TL21: WF 4.0: Extending with Custom Activities, Matt Winkler
  • TL36: Microsoft .NET Framework: Declarative Programming Using XAML, Rob Relyea, Daniel Roth
  • BB47: SharePoint 2007: Advanced Asynchronous Workflow Messaging, Alex Malek
  • BB27: .NET Services: Orchestrating Services and Business Processes Using Cloud-Based Workflow, Moustafa Ahmed
  • TL31: “Oslo”: Building Textual DSLs, Chris Anderson, Giovanni Della-Libera 

    Combining WF 4.0, “Dublin”, and “Oslo”: A figure

    An application can use workflows, services, and models together, combining WF 4.0, “Dublin”, and “Oslo”

    Source: Workflows, Services, and Models

    Workflow (WF) Screencasts

    1. Your first sequential workflow
    2. Your first state machine workflow
    3. Running workflows in your .NET applications: Matt covers the basic steps to host workflows in your applications.  He covers the basic hosting steps in a console application, then jump in and run a workflow in an ASP.NET application. 
    4. Using persistence services in WF: Matt presents the basics of add persistence services into the workflow runtime using code or configuration.  Additionally, to show off the power of this feature in Windows WF, he uses two different host processes sharing a persistence store: the first host starts a workflow and then it persists, while the second host picks up the workflow after its configured delay and resumes the processing.
    5. Using the WCF Receive Activity in a workflow: Learn how to use the Receive activity in your workflows to implement WCF services as workflows. In addition, see how to use the WorkflowServiceHost class to host your workflow as a service.
    6. Using the WCF Send activity in Windows Workflow Foundation: Matt Milner presents  the basics of using the Send activity to consume a service from a workflow using WCF. 
    7. Creating Custom Activities:Matt Milner presents  the basics of creating custom leaf activities including how to use Dependency Properties to make your properties bindable.

    Link – Synchronous call of a workflow from an activity

    Jon Flanders provides an example where an activity creates and calls syncronously another workflow by using a custom service.

    Arbitrary loops (GOTO activities) in sequential workflows

    The following BPMN diagram presents a situation where there is an arbitrary loop with two entry points (one before Task A and one before Task B) and one exit point (after Task C). In situations like that it is not possible to implement this loop with a WhileActivity, because the WhileActivity works only with well-structured loops (i.e. those that have one entry and one exit point).

    BPMN diagram with arbitrary loop

    In many cases, it is possible to implement a loop like that with a StateMachineWorkflow. However, in order to implement this loop inside a SequentialWorkflow, we must exploit the rather obscure EventHandlingScopeActivity.

    According to the official documentation, “… an EventHandlingScopeActivity activity executes its main child activity concurrently with an EventHandlersActivity activity. Each EventDrivenActivity within the EventHandlersActivity might execute many times or not at all”.

    According to Scott Allen, “… the EventHandlingScope activity is similar to a Listen activity in that it can have multiple branches waiting for events in parallel. We can view these branches by right-clicking the activity and selecting “View Events”. The primary difference between this activity and a Listen activity is that this event continues to listen for all events until its main child activity (the default view) finishes execution. Imagine we are setting up a workflow that will count employee votes over a period of 30 minutes. We could set the main child activity of the EventHandlingScope activity as a Delay activity, with a 30-minute timeout. We can then place event handling activities in the event branches that listen for Yes and No votes. This activity will continue to listen for the Yes and No events until the Delay activity completes in 30 minutes.”

    The idea is to setup the appropriate event handlers and raise the events from inside (by emulating the receipt of an external event). A mathematically concrete presentation (by C. Ouyang, M. Dumas, S. Breutel, and A.H.M. ter Hofstede) of this technique can be found here and here.

    The main child activity contains two activities: Raises the starting event and waits for the end event. For the example above we need to setup two event handlers. A rule of thumb is that we need one event handler for each activity that has two or more input flows.

    The first event handler contains Task A and raises the event for the second event handler.

    The second event handler contains the Task B activity and an IfElseActivity, which represents the first gateway of the diagram. Now, the IfElseActivity checks the first condition (a==1) and if true, we raise the event captured by the first event handler. If false, we execute Task C and invoke a second IfElseActivity, which represents the second gateway. This IfElseActivity checks the second condition (b==2) and if true, we raise the event captured by the second event handler, otherwise we raise the event that ends the activity (the event that the main child activity listens to).

    A sample project containing the workflow of the above diagram can be downloaded from here.