Partilhar via


WF4 Changes Between Beta 1 and Beta 2

Hi all, I’m Matt Winkler, a PM on the WF team and occasional guest blogger here on the endpoint.  I wanted to take a moment to highlight some of the interesting new things in WF4 in Beta 2.  For more info on Beta 2, please check out this page.

The goals of a milestone like Beta 2 are two fold: 1.) to react to customer feedback that we’ve received on previous releases and 2.) stabilize and lock down the product to get ready to ship.  While the items in #1 will be most visible, the team has done a lot of work stabilizing the product, and I feel pretty good about the Beta 2 release.

What are the big changes?

Activity Hierarchy  Changes

For those of you who thought it was a little weird that we talked about writing activities, but having to derive (ultimately) from WorkflowElement in order to write them, this change is for you.  Here’s a snapshot of the activity hierarchy in Beta 1:

WorkflowElement

We heard that feedback loud and clear and have made a few changes to how the activity hierarchy is factored:

image

The key changes are:

  • WorkflowElement goes away, and is replaced with Activity .  Activity is the root type for all units of execution within the world of WF
  • Addition of ActivityWithResult which is the base for the Expression activities
  • Addition of AsyncCodeActivity.   We got a lot of feedback that people liked what we were doing integrating asynchronous programming within activities but that there was still a fair amount of work in order to hook those up.  AsyncCodeActivity is some nice sugar that makes it pretty easy to write an activity that takes advantage APIs that surface a Begin/End pair using the asynchronous programming model.

Runtime and Hosting

Validation has been improved for activity authors to write code within CacheMetadata() to validate the activity tree.  CacheMetadata() is also the one stop shop for customizing behaviors that were previously spread through methods like OnGetArguments(), GetConstraints(),  and GetActivities()

Make it easier to use ActivityAction by introducing DelegateArguments to pass data into and out of an ActivityAction.  In Beta 1, this required using an object of type Variable<T> that was assigned to a property named Argument.

In the ‘under the hood’ category, the team has made improvements to Persistance, Durable timer and tracking which should provide a better runtime experience for the WF4 developer.

Last on the runtime front, dynamic update was a feature that had made its debut in Beta 1, but was removed again between Beta 1 and Beta 2 - and will not be present in the RTM release. 

And, within hosting, WorkflowInstance was renamed to WorkflowApplication based on Beta 1 feedback from users.

Activities

The messaging activities are the key component for integrating WF and WCF together.  Based on customer feedback we’ve made improvements to:

  • Correlation
    • XPath can now be generated from ParametersContent
    • CorrelationQuery and AdditionalCorrelations have been merged into a collection called CorrelationInitializers.   Also, we’ve reduced the need for CorrelationHandles all over the place by improving the CorrelationScope and having an implicit correlation handle.
  • Parameters support
    • We’ve removed the *Parameters activities and merged that into the Send and Receive activities.  You can now use the Content property to support MessageContent (primarily for untyped Message or MessageContract ) and ParametersContent (which is for the more RPC style list of name value pairs).

We’ve also refactored the semantics around the error handling activities to behave similar to a “throw” in a C# catch block. The most visible aspect of this change is the addition of the Rethrow activity.

Lastly, the InvokePowershell activity is no longer shipped as part of the .NET Framework. Fear note, for it is not gone; it has been moved to the SDK samples, joining other quite useful activities.

 

Interop Activity

The Interop activity is a key component for WF4 workflows, allowing you to continue to leverage activities built in WF3.  We’ve made improvements to the way that validations and transactions are handled within the Interop activity to more fully support WF3 activities.

Designer

I plan on having a whole post specifically around that, but we’ve done a fair bit of work to address feedback that we’ve received, namely:

  • Expand in place support
    • This makes it easy expand an activity within the canvas without having to drill into it.  This also lets you collapse activities when you don’t want to see all of the detail
  • Imports designer
    • No more fully qualified type names within expressions
  • Text of flowchart lines for FlowDecision and FlowSwitch
    • This is a nice usability / readability fix for the Flowchart, making it easier to see which cases and conditions the lines leading from decision shapes are for.

We received a lot of great feedback from folks about Beta1, and we’ve had a few usability studies done here in Redmond which have provided additional feedback that have shaped the work that we’ve done on the designer.  Additionally, we’ve done work to clean up the object model to make it easier to rehost and customize the design experience. There have also been a number of key stability improvements and bug fixes to the expression editing experience which was a little rough in Beta 1.

If there are other resources you are looking for, let us know!

Comments

  • Anonymous
    January 07, 2010
    Testing to see if my comment will go through. Don't think my last one did?