The .NET Endpoint : Activities

Migration Guidance for the WF Developer (Beta 1 - Part 2)

Cliff Simpkins — Wed, 22 Jul 2009 02:41:46 GMT

About six weeks ago, the WF team published up the first four WF3->WF4 migration guidance documents, aimed at helping WF developers prepare and think about the new WF object model runtime.

Today, we published the next three documents in the series to the WF4 Migration Guidance document set. With today’s release, we begin moving from the general guidance and start to present cookbook material, addressing more specific scenarios and presenting code.

WF Migration Overview (Already Live)
Overview of the document collection and an initial starting place for the WF3 developer
WF Migration: Best Practices for WF3 Development (Already Live)
How to design WF3 artifacts so they are more easily migratable to WF4
WF Guidance: Rules (Already Live)
Discussion of how to bring rules-related investments forward into .NET 4
WF Guidance: State Machine (Already Live)
Discussion of WF4 control flow modeling in the absence of a StateMachine activity
WF Migration Cookbook: Custom Activities (Now Live!)
Examples and instructions for redesigning WF3 custom activities on WF4
WF Migration Cookbook: Workflows (Now Live!)
Examples and instructions for redesigning WF3 workflows on WF4
WF Migration Cookbook: Workflow Services (Now Live!)
Examples and instructions for redesigning WF3 workflow services on WF4
WF Migration Cookbook: Advanced Custom Activities (Coming Soon)
Examples and instructions for redesigning advanced WF3 custom activities on WF4

As I mentioned in the last post about the documents, these documents are initial draft releases that the team is releasing to you. For these, they are all written for the object model and features that are part of Beta 1. We will be updating the documents as additional releases of .NET 4 are publicly released, and the documents will address further scenarios with each release.

Also – again – the team will be supporting feedback and requests for the documents and accompanying sample code in the WF 4 forum on MSDN.

Happy reading!
Cliff

Sequential and Flowchart modeling styles

lwelicki — Fri, 12 Jun 2009 20:16:16 GMT

WF 4 ships with an activity palette that consists of many activities – some of these are control flow activities that represent the different modeling styles developers can use to model their business process. Sequence and Flowchart are a couple of modeling styles we ship in WF 4. In this post, we will present these modeling styles, learn what they are, when to use what, and highlight the main differences between them.

Sequential modeling style

A sequential workflow executes a set of contained activities in sequential order. The Sequence activity in WF 4 allows you to model workflows in the sequential modeling style. A Sequence contains a collection of activities that are scheduled in the order in which they have been added to the collection. Hence, the order of execution of the activities is predictable.

You can add any activity to a Sequence – control flow procedural constructs like ForEach, If, Switch, While, DoWhile; or parallel constructs like Parallel and ParallelForEach to model parallel execution of logic; or any other activity we provide in the WF 4 activity palette (or your own custom activity or a third party activity).

The next figure shows a Vacation Approval workflow modeled as a sequential workflow using the Sequence activity and other activities. In this workflow, we first check if the employee has enough available days, wait for his manager approval, and finally update his vacation information in the company’s HR database. The activity highlighted in the orange box (Get Manager Approval) is actually a While activity (collapsed in the main Sequence) that executes another Sequence of activities (AskForApproval) while the approvedByManager variable value is False.

Workflows modeled using the sequential modeling style are easy to understand and author. They can be used to model simple to moderately complex processes. Since procedural activities have strong parity with procedural statements in imperative programming languages, you can use this type of workflows to model almost any type of process. Sequential workflows are also a good fit to model simple processes with no human interactions (e.g. services).

As the complexity of the process increases, the workflow will become more complex. In comparison to code, with workflows, you will get the benefit of visually looking at your process and visual debugging, however, you may want to factor out the logic into re-usable custom activities to improve the readability of large workflows.

Sequential Modeling Style and Sequence Activity

Sequence is not a requirement to create workflows that use the sequential modeling style. As we will explain later in this post, any activity in WF 4 can be the root of a workflow. Therefore, we can create a workflow that does not contain a Sequence but still uses the sequential modeling style and procedural activities. In the figure below, we have a workflow that has as a ForEach as root activity that prints all the items in a list of strings with a length higher than 5.

Flowchart

Flowchart is a well known and intuitive paradigm to visually represent business processes. Business Analysts, Architects and Developers use often flowcharts as common language to express process definitions and flow of logic.

Since the release of WF 3, customers have given us feedback about what they like and don’t like. One common point of feedback from customers using WF3 was that “we want the simplicity of Sequence, Parallel, etc. but the flexibility of StateMachine.” When we dug deeper to get at the scenario behind this sentiment, we found that customers have a process (or a portion of a process) that is often quite sequential in nature but which requires “loopbacks” under certain circumstances (for some customers the circumstances are “exceptional” in nature while for other customers they are “expected” but it really doesn’t matter to this discussion). The FlowChart activity is new in WF 4 and it squarely addresses this (rather large) class of scenarios. Flowchart is a very powerful construct since it provides the simplicity of sequence plus the ability of looping back to a previous point of execution, which is quite common in real life business processes to simulate re-try of logic when handling external input.

A Flowchart contains a set of nodes and arcs. The nodes are FlowNodes – which contain activities or special common constructs such as a 2-way decision or a multi-way switch. The arcs describe potential execution paths through the nodes. The WF 4 Flowchart has a single path of execution; that is, it does not support split/join semantics that would enable multiple interleaved paths of execution.

The next figure shows a simplified recruiting process modeled using a Flowchart. In this case after a résumé is received, references are checked. If references are good, the process continues, otherwise the résumé is rejected. The next step verifies that the candidate skills are a good match for the position offered. If the candidate is a good match, then she will be offered a position. If she is not a good match for this position but interesting for future opportunities, the resume is saved in a database and a rejection letter is sent. Finally, if the candidate is not a good match, she is sent a rejection letter.

Flowchart modeling style is great to represent processes that are sequential in nature (with a single path of execution), but have loops to previous states. They use a very well known approach for modeling processes (based on “boxes and arrows”) and allow representing processes in a very visual manner. Control of flow is dominated by the transitions between the nodes and by two first-class branching activities (FlowDecision and FlowSwitch). Flowchart is a good fit to model processes with human interactions (e.g. human workflows).

Using Sequence and Flowchart together

WF 3 had a notion of a root activity. Only root activities could be used as the top level activity in a WF 3 workflow. WF 4 does not have a similar restriction. There is no notion of a root activity any more. Any activity can be the root of a workflow.

Let me explain this in more detail… Activities are a unit of work in WF. Activities can be composed together into larger Activities. When an Activity is used as a top-level entry point, we call it a "Workflow", just like Main is simply another function that represents a top level entry point to CLR programs. Hence, there is nothing special about using Sequence or Flowchart as the top level activity; and they can be composed at will.

The next figure shows a Flowchart inside a Sequence. The workflow below has three activities: a composite activity that does some work, a Flowchart (highlighted in green) and finally another composite activity that does some more work.

The same can be also done in a Flowchart. The next figure shows a Flowchart that has a Sequence (highlighted in green), a FlowDecision, and then two WriteLine activities for the True and False paths of the decision.

Beyond Sequence and Flowchart

WF 4 simplified activity authoring story makes easier writing your own custom composite activities to model any control of flow approach of your choice. In future posts, we will show how to write your own custom activities and designers.

Conclusion

In this post we have presented the Sequential and Flowchart modeling styles. We learned that Sequence is used for modeling sequential behavior and that Flowchart is used to model processes with a single path of execution and loops to previous states. We also learned that Sequence and Flowchart can be combined and used together as any other existing activity.

The following table shows the main differences between Sequence and Flowchart.

Sequence	Flowchart
Order of execution is explicit, close to imperative/code	Order of execution expressed as a graph with nodes and arcs
Loopbacks are represented combining control of flow activities (e.g. While + If)	First class modeling of loopbacks
Parity with imperative / procedural	Parity with boxes and arrows diagrams
Activities are executed in sequential order	Activities are executed in the order dictated by the arrows between them
Simple process / no human interaction (e.g. services)	Complex processes / human interactions (e.g. human workflows / state machine scenarios)
The flow of the process is not visually obvious	Control of flow is visual, dominated by Boolean decisions (FlowDecision) or Switch (FlowSwitch)

A Tour on the WF4 Activity Palette

lwelicki — Fri, 29 May 2009 09:03:37 GMT

WF4 beta 1 ships with a comprehensive set of activities (more than 35) that you can use to author your workflows or to create your own custom activities. This post will give you a quick tour through the activity palette and introduce you to the key characteristics of the out of the box activities.

Activities are the unit of work in a workflow program. Activities in WF4 have a signature and body. The signature of an activity is defined in terms of its public arguments. These public arguments define the data flow into and out of an activity. The body of an activity is a chunk of execution logic that may execute over multiple pulses of work. This logic can be expressed declaratively in terms of other activities or with imperative code.

Quick note: As you may have noticed, the activities in the toolbox are not sorted alphabetically. This is something that we are aware of and that will be fixed in the next Beta. For Beta1, if this bothers you, you can simply right-click in the toolbox and choose "Sort Items Alphabetically" and it will sort the items for you for easy discoverability.

Procedural

Procedural activities provide a mechanism to model sequential control flow using concepts you know from standard procedural languages like C# or VB like if, assign, while, etc. Procedural activities include the basic building blocks to represent sequential behavior, including control of flow, method invocation on CLR objects, collection manipulation, and error handling. It also covers advanced scenarios like parallel activities, transaction management, compensation, cancellation, and persistence. The table below contains all the activities in the procedural category. The words in bold in the description of each activity represent its most important arguments.

Activity	Description	Designer
*Collection Management*
AddToCollection<T>	Adds an Item to a Collection.
RemoveFromCollection<T>	Removes an Item from a Collection.
ClearCollection<T>	Clears a Collection, removing all items stored in it.
ExistsInCollection	Verifies if an Item exists in a Collection. If the item exists, its Result argument will yield True.
*Control of Flow*
If	The If activity selects a child activity for execution based on the value of a Boolean expression. If the Boolean expression Condition yields True (and “Then” activity is configured), the “Then” activity is scheduled. If the expressions yields False (and “Else” activity is set), the “Else” expression is scheduled.
DoWhile	Executes its Body until the Condition evaluates to True. The Body will be executed at least once.
ForEach / ForEach<T>	ForEach activity contains a list of Values and a Body. At runtime, the list is iterated and the body is executed for each value in the list.
Pick	The Pick Activity provides event-based control flow modeling in WF. The only valid children for a Pick activity are PickBranches. At the beginning of a Pick execution, all the Trigger activities from all its Branches are scheduled. When the first Trigger completes its corresponding Action activity is scheduled, and all other Trigger activities are canceled.
PickBranch	PickBranch represents a branch in a Pick. It consists of a Trigger and Action. PickBranch can only be added to a Pick activity.
Sequence	The Sequence activity allows for the execution of one or more Activities in order.
Switch<T>	Switch activity is similar to switch statement in C#. It contains an Expression and a set of Cases (each case has a key and an activity). After the expression is evaluated, the Switch activity looks for a Case with a key that matches the result of the expression and if found, it schedules the activity associated with that Case.
While	The While activity executes it's Body while a Boolean Condition is True.
*Parallel Execution*
Parallel	Parallel activity allows parallel execution of its children. It operates by scheduling each WorkflowElement in its Branches collection at the beginning of its execution. It completes when all of its Branches complete or when its CompletionCondition property evaluates to true.
ParallelForEach / ParallelForEach<T>	The ParallelForEach activity enumerates the elements of a collection(Values) and executes an Activity for each element of the collection, in a similar way than the ForEach activity does. The main difference is that the embedded statement is executed in a parallel fashion. Just like the Parallel Activity, ParallelForEach has a CompletionCondition, so that the ParallelForEach activity could complete early if the evaluation of the CompletionCondition returns true. The CompletionCondition is evaluated after each iteration is completed.
*Error Handling*
TryCatch	TryCatch activity is similar to the try..catch construct in C#: all activities in the Try block are executed and if an exception occurs, it will schedule the Catch block that best matches that exception (if no matching catch is found, the workflow is aborted). All Catch blocks are contained in a collection called Catches. TryCatch activity also has a Finally block that is executed after the Try (and any eventual Catch). A note on unhandled exceptions: TryCatch provides exception handling at the workflow level. When an unhandled exception is thrown, the workflow is aborted and therefore the Finally block won’t be executed. This behavior is consistent with C#.
Catch<T>	Represents one catch block to be used in a TryCatch activity. If an exception is thrown within a Try Element, the TryCatch will attempt to find a matching Catch element based on the type of the thrown exception. Catch<T> can only be used inside a TryCatch activity
Throw	Throw activity throws an exception within a workflow. Throw activity has an Exception property that contains the exception that will be thrown at execution time.
*Utilities*
Assign	The Assign activity assigns the value of its Value argument to its To argument. The types of both arguments must be compatible. This compatibility is verified at runtime.
Delay	Delay Activity, as its name suggests, will block the current workflow execution path for a Duration specified by user. After the duration expires, the workflow continues execution as expected. The duration of the delay is set using a TimeSpan.
InvokeMethod / InvokeMethod<T>	InvokeMethod is the activity that allows you to call an existing CLR instance or static method. To invoke a method all you need to do is provide the owner of the method (TargetType for static methods, TargetObject for instance methods), the MethodName, and its Parameters. InvokeMethod supports the following method invocation scenarios: · Public instance and static methods · Parameter passing by value and by reference · Support for parameter arrays · Support for generic parameters · Asynchronous method invocation
WriteLine	Writes text to the configured output console. Writing beyond the System.Console WriteLine has a TextWriter argument can be configured to write to different outputs. For example, we can configure the TextWriter property to send the text to an ASP.NET page. If the TextWriter is not set, it will be set by default to the System Console.
Advanced (Cancellation, Compensation, Transactions, and Persistence)
CancellationScope	The CancellationScope activity consists of two main parts, the Body and the CancelHandler. The body is the code path that normally executes. If the activity gets canceled, then the cancel handler is called.
CompensatableActivity	CompensableActivity is used to define a potentially long running activity with accompanying Compensation and Confirmation logic. Compensation allows the user to specify corrective action to be taken on an activity based upon activity which occurs after the successful completion of the Body of the activity.
Compensate	Compensate is used to explicitly invoke the compensation handler of a CompensableActivity.
Confirm	Confirm is used to explicitly invoke the confirmation handler of a CompensableActivity.
Persist	Persists the workflow instance. Persistence will be done using the configuration of the WorkflowInstance that is being executed (this activity doesn’t have any arguments).
TransactionScopeActivity	The TransactionScopeActivity provides the mechanism for initializing a new transaction, making the transaction handle ambient (a workflow execution property) and calling complete on the transaction once the Body of the TransactionScope activity has completed. TransactionScopeActivity supports “Requires” semantics. If there is already an ambient transaction it is used, else a new one is created. Nested transaction scopes: TransactionScopeActivity can be nested in another TransactionScopeActivity. A TransactionScopeActivity nested in another TransactionScopeActivity will use the existing transaction.

Flowchart

Flowchart is a new modeling style that we have introduced in WF4. Flowchart is a well known and intuitive paradigm to visually represent business processes. Business Analysts, Architects and Developers use often flowcharts as common language to express processes.

Flowchart is a very powerful construct since it provides the simplicity of sequence plus the ability of looping back to a previous point of execution. All this is conveyed using a very well known conceptual paradigm that is common across several disciplines beyond computer science!

Activity	Description	Designer
Flowchart	This is the root for a Flowchart. Since Flowchart is an activity like any other, it can be composed inside any container activity. For example, we can add a Flowchart inside of a Sequence or a Flowchart inside another Flowchart. The green ball in the image at the right represents the start node of the Flowchart.
FlowDecision	FlowDecision models conditional forks within a Flowchart. It can be seen as the equivalent of the procedural If activity in the Flowchart world. This activity contains a Boolean expression Condition. If the expression evaluates to “True”, the true path is executed (otherwise, the false path is scheduled).
FlowSwitch	FlowSwitch activity selects a next node depending on the value of an expression. FlowSwitch can be seen as the equivalent of the procedural Switch activity in the Flowchart world.

Messaging

The WF4 Messaging Activities are designed to support message-oriented workflows and provide better integration of messaging into workflows. They enable workflows to send data out to other systems and receive data from other systems. These activities can be composed together and along with correlation can model many complex Message Exchange Patterns.

Activity	Description	Designer
Receive	Models one way receive of a message. It can receive data of the following types: Message, DataContract types, XmlSerializable types, and MessageContracts.
ReceiveAndSendReply	This activity template represents a correlated Receive activity and SendReply activity. By using this template you can wait for an incoming message and then send a reply to the sender. Since the Receive and the SendReply are inside a sequence, you can add any activity between them.
Send	Models one way send of a message. It can receive data of the following types: Message, DataContract types, XmlSerializable types, and MessageContracts. This activity can be used in two ways: 1. Client: this activity can be used to send a request to a service. This is equivalent to a WCF client calling a service operation. No contract inference is performed on the client side. 2. On the server side the Send activity can be used to send a reply to a previous Receive. In this case the Send and Receive activities must have the same OperationName, Action and CorrelationHandle.
SendAndReceiveReply	This activity template represents a correlated Send activity and ReceiveReply activity. By using this template you can send a message and then wait for a reply from the destination. Since the Send and the ReceiveReply activities are inside a sequence, you can add any activity between them.

PowerShell

PowerShell activities, as their name imply, allow invoking PowerShell cmdlets (commandlets) and scripts from WF programs.

Please note that while these activities are included by default in the Beta1 toolbox, they will not be available in the final RTM bits when we release. This is because .NET Framework does not allow taking a dependency on a technology that does not ship in the framework. We're working on a longer term strategy here since many customers have requested PowerShell activities. For RTM, you will find these activities in the SDK samples instead.

Activity

Description

Designer

InvokePowerShell

Invokes a PowerShell cmdlet that does not have a return value. InvokePowerShell can be used to invoke simple cmdlets and scripts. We can also pass parameters and input objects to the cmdlet. After execution, the activity provides a set of errors (if any occurred).

InvokePowerShell<T>

An activity that invokes and retrieves the resultant output from a PowerShell cmdlet. This flavor of the activity has all the same arguments than the non-generic version plus an InitializationAction.

The InitializationAction is used to map the results of the execution of the cmdlet to variables in our workflows.

Migration

WF 3.x and 4.0 can exist side by side, but you can also use WF 3.x activities in WF4 workflows using the Interop activity.

Activity

Description

Designer

Interop

The Interop activity is a WF4 activity that wraps a WF3 activity (a non-abstract CLR type that derives from System.Workflow.ComponentModel.Activity) thus allowing the WF3 activity to be used in WF4 workflows. Note that the WF3 activity can be a single leaf activity, or an entire compiled workflow (tree of activities).

The Interop activity bridges the WF4 and WF3 activity execution models, facilitates data flow across the interop boundary, and enables persistence and tracking of WF3 activity instances within WF4 workflow instances.

The Interop activity allows WF developers to move to the WF4 model in an incremental fashion:

· Quickly experiment with WF4 using existing WF3 activity artifacts

· Wrap WF3 activities the developer isn’t ready to redesign on the WF4 model

· Wrap WF3 activities for which the developer doesn’t own or possess the source code (e.g. they purchased the activity from a third party)

Wrapping up

It’s been a long tour, hasn't it? And this is just the beginning! There are a lot of new exciting features in WF4 and we are eager to share them with you in future posts.

This post is an introduction to the activities that we are shipping in the activities toolbox. If you want to see these activities in action, please check our WF samples. A good starting point are the samples under the folder %SamplesRoot%\WF\Built-InActivities.

We are keenly interested in understanding your scenarios and ideas, and helping you accomplish your goals on WF4. We’d appreciate your feedback (both positive and critical), and we look forward to continued dialogue about the activities that you would like to see in WF toolbox. We look forward to hearing from you!

The Road to 4 – WF Changes between Beta 1 and CTP

Cliff Simpkins — Sat, 02 May 2009 01:30:00 GMT

I can’t believe it’s been a few months since my post on the Road to WF 4, and the expected impact of the new workflow model. It’s been a busy few months as the team develops and builds toward .NET 4; as we hosted an MVP Summit here in Redmond; and worked with TAP customers around using WF 4; and a few small scale shuffling around of job roles (one reason why you may not have seen much from me around updates on Channel9 and MSDN). And then, of course, there’s getting ready for TechEd in a couple weeks – we have some excellent presentations in store for Los Angeles, but I’ll circle back to that at the end of this article. All of that being said, I don't believe you're here for my digressions…

The team has been busy coding away since our conversations at the PDC in October. Soon, we will be releasing a public build of Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF), which will be made available with the beta 1 build of .NET 4 and Visual Studio 2010 <and before you ask: I don't know when the beta will be posted>. Starting with this release, the WCF and WF builds will be part of the all-up VS2010 public drops, and the new System.Xaml.dll is provided within the box, as opposed to out.

At the highest level, the beta includes a great number of enhancements: additional features have been added; the designer looks and performs better; and the codebase is much more stable. What I'd like to do is take a rather quick walk along the workflow-specific features new to the beta and point out some of the highlights, which we will explore in greater detail as we come upon the beta 1 release. To be clear, this particular entry is geared to the .NET developer that had attended the PDC or had the opportunity to evaluate the WCF/WF/’Dublin’ VPC that was distributed at the PDC and watch the recorded PDC sessions. My next blog entry will talk to the WF 3.x developer, and introduce the new workflow model being released as WF 4.

To begin on the CTP -> Beta 1 delta discussion, let's start with the building blocks of workflows - activities – and wind our way into the core.

The activity team has made several improvements that will immediately pop to anyone who worked with the CTP bits provided at the PDC: more out-of-the-box (OOTB) activities, clean up of the activities you saw in the CTP, API improvements in the activity object model that make it easy to write custom activities, and support for VB expressions end to end.

Base Activity Library

Out-of-the-box, the new workflow designer in beta 1 will ship with a larger set of OOTB activities than was available in the CTP's designer palette. These new activities include the following:

Parallel: The parallel activity, which allows you to interleave the execution of activities along multiple paths, makes a triumphant return with a WF 4 designer. As an aside to those who used the parallel activity in WF 3, it’s important to note that the activity scheduling/queuing behavior changed in WF 4. We’ll get a much more detailed follow-up post on this topic next when Beta 1 comes out.
ParallelForEach: The beauty of the OOTB activities is they do about what you would expect. In Beta 1, this new activity allows you to perform a parallel series of operations upon an object collection. Unlike the Replicator activity in .NET 3, the ParallelForEach activity (and ForEach activity) allows you to model this behavior in a fully declarative fashion.
Pick: The pick activity can perhaps be best thought of an equivalent to the listen activity from the current WF model or similar to a BPEL pick. The activity has a series of branches, with a defined trigger/event and execution steps. We expect that the combination of Pick with the WF 4 flowchart model’s capability to define free form activity transitions to become a popular design pattern.
Collection Manipulation Activities: The Beta 1 release adds four activities (ClearCollection, AddToCollection, RemoveFromCollection, and ExistsInCollection) that allow you to manipulate object collections.
Service Activities: This will be discussed in a ‘What’s new in WCF Beta 1’ blog post that I will try to get out after TechEd, but it’s important to note that we’ve greatly improved the WCF activities in the beta.

In addition to the new activities highlighted above, the beta simplifies the visual presentation of other activities to take up less real estate on the designer. Feedback we received from folks who saw and used the PDC bits was that they didn’t want too much information on the activity shape, so more information for the OOTB activities has been moved back to the property grid to make the workflow designer surface more readable without having to use the resizer.

On the topic around what’s not in the box, there are a number of activities that had been discussed at the PDC that you won’t find in the VS2010 beta 1 download, these include generic activities to interact with resources such as a database, with the file system, and with SharePoint. While it’s pretty clear that these won’t make it into the Framework 4 release, we are trying to find other ways to release them. For example, the beta 1 SDK includes a policy activity to interact with WF 3 rules sets. For those that don’t show up in the SDK, we are evaluating an option of making the activities available as a separate downloade post-Beta 1, but the location and timing of that is still being determined.

Two other major WF 4 activities that were discussed at PDC, a new state machine activity and a new forward chaining ruleset activity, will not be available with the VS2010 beta 1 release – and we will cover each of these topics in greater depth in the next month. At this point, a new forward chaining rules engine won’t be ready for the .NET 4 timeframe, and will probably see a CTP release post-VS2010 to gather feedback and to allow customers the opportunity to evaluate the direction we are considering. It’s important to note that we are working to ensure integration with the WF 3 rules engine will be possible in a number of ways, though; one example of integration back to the WF 3 rules engine is the SDK sample activity I mentioned above, For the state machine, we are unable to include a new state machine activity in WF 4, but our work with TAP customers leads us to expect that using a combination of the new FlowChart + Pick activities should satisfy a large majority of the current scenarios that folks are currently using the state machine activity for (again, we can and will dive into this as a follow-up post), and we look forward to getting customer feedback on the capabilities and limitations of using FlowChart + Pick once the beta is released.

Activity Authoring Experience

The object model has changed between the PDC CTP release and Beta 1. While the core concepts have essentially remained the same, the class names have shifted a bit, and a couple new classes have been added into the mix. For most WF developers, there are really four activity classes that you will work with. Moving from the class with the fewest knobs to turn to the class that gives you full control, the activity classes are as follows:

Activity: Used when creating a composite activity – an activity who’s execution is entirely expressed as a composition of other activities. Activities that you create from the Activity type can be designed in a declarative fashion (using XAML) and don’t allow for any imperative code. From a conceptual perspective, when authoring a “workflow” (in this case, defined as connecting a series of activities together), you are essentially authoring a derived “Activity” class.
CodeActivity: Used when creating an activity that implements a custom Execute method, and is designed for short-running chunks of work.
NativeActivity: Used when creating an activity that has full access to the core of the WF runtime features such scheduling child activities and manipulating bookmarks. This is intended as the type of last resort, and we don’t expect many folks to inherit from this type.
WorkflowElement: This is the abstract base type that all activities derive from.

The inheritance model among these four classes is presented below. In addition to the above, the beta release adds the generic WorkflowElement<T> class, which is useful for building expression activities (as an example of where this is used - the collection activities, mentioned above, inherit from the CodeActivity<T> class), and this is a topic for another blog post.

For most tasks, you will find that much of the custom activities authoring experience is the same between the CTP and Beta 1 builds. As we’ve been building WF 4, we have been doing usability work with customers and early adopters of WF 4 to improve the custom activity authoring experience (e.g., Beta 1 sees improvements around how developers interact with the ActivityExecutionContext), and look forward to your feedback from Beta 1 to make further refinements as we continue to progress towards RTM.

Before I move on to the designer experience, one other activity class that deserves a quick mention is the DynamicActivity. DynamicActivity allows you to add arguments (both InArgs and OutArgs) around what is essentially loose XAML – and use that within your workflows without requiring the XAML to be compiled – allowing for assembly of activities into a higher-level abstraction without having to create/develop additional custom activities. This is also something that will be worth digging into a bit deeper in a much more technical blog post as we dive in deeper into WF 4 activity development.

Designer Experience for Activities and Workflows

As you sit down and start to work with the beta 1 bits to design activities and workflows, there are a few items that really jump out at you:

IntelliSense and syntax-coloring: The expression editor within the property grid (and when editing argument and property values on the designer surface) within the Workflow designer experience now supports IntelliSense. As you type out your expressions (in VB), you get drop-downs and auto-complete capabilities as you type out your expressions to work with Strings and TimeSpans. This new expression editor can also be used in your own custom activities!
Performance: As you would expect between a CTP (alpha build) and a beta 1 release, the experience with the designer is much more stable and much more performant.
Variable and argument designer: The visual presentation of the variable and argument boxes has changed slightly. Responding to feedback from the CTP designer, the team improved the boxes to make it easier for users to know the scope level of available variables.
Improved bread crumb trail: Based on feedback on the PDC CTP, as well as feedback from usability studies performed by the team, the breadcrumb trail should now be more intuitive.

The improvements should make the experience much more pleasurable and approachable than that available in the CTP.

Unified XAML Stack

This was a point that received a lot of discussion at PDC. With everything being in one Visual Studio and .NET build, this is now being delivered out of the box!

Tracking and Tracing Improvements

Tracking and tracing in WF 4 has changed quite a bit to improve performance and flexibility. In .NET 4, WCF and WF use much of the same tracking and tracing models, which provide consistency for .NET developers using both technologies, and makes it much easier to develop and host workflow services. WF 4 introduces the capability for WF developers to do use Event Tracing for Windows (ETW). This is an improvement that comes from the unification of the WCF and WF tracking, and is designed to provide more control to the folks managing a WF host at runtime while minimizing the performance overhead when tracking is enabled. This should provide tracking and tracing capabilities that developers and IT Pros can have more control over – specifying what to track, when to track it, and the level of verbosity to track. The beta builds upon the functionality released in the CTP, adding refinement and enhancements to tracking in WF:

Improved ETW Integration: Beta 1 provides .NET developers with the capability to In WF 4, this adds the ETWTracking Participant to write tracking records to an ETW session. With the addition of this feature, the corresponding SQLTracking participant has been removed from WF 4 in Beta 1
End to End (E2E) Tracing With WCF: Beta 1 adds support to ensure that traces are emitted to tie together a request from a WCF service to a WF instance, allowing for a unified debugging experience for workflow services.
Tracking Profile Config Elements: The tracking profile in the .config file now uses the configuration elements instead of XAML.
OptOut Model: In the PDC bits, developers had to explicitely mark variables and arguments for tracking (opt in model). Based on customer feedback, this has been changed to track all variables/arguments in a workflow unless the workflow or activity developer specifically suppresses tracking for a variable or argument.
Tracking Filtering: In WF 3, logging was an all-or-nothing event, the new functionality; with WF 4, more control is provided to extend and configure the runtime logging environment.

Work continues as we complete the designer and tighten down performance, but we feel that the code is in a state where customers can begin to seriously prototype their solutions on the new WF model and evaluate if it meets their needs. To help you do that, another big effort with this beta milestone is around helping you understand what the new WF model is, and how you can use it to workflow-enable your applications and services.

Supporting Material - Information You Can Use

Lastly, the team has put in a lot of effort around adding quality documentation and samples. With the CTP bits, the PDC session recordings and the hands on labs were perhaps the best place developers could go while experimenting with the bits. With beta 1, developers evaluating the beta release have a much better experience:

When you press F1, online help is available to let you know what can be done
The beta 1 SDK adds 63 new code samples (bringing us up to 88 SDK code samples), which do an excellent job of demonstrating how to accomplish more atomic tasks
The hands on labs are being updated to beta 1, and they will be incorporating feedback received from those who ran the PDC labs

In addition to the above, we will be releasing a few additional items via the blog and the WF 4 Dev Center: David Chappell is writing a new whitepaper that introduces folks to The Workflow Way in .NET 4, the WF team is working on WF 3.x to WF 4 migration guidance documents that will help WF 3 developers understand the impact and options available with WF 4, and we will start doing blog posts and webcasts in the next month to aide developers in evaluating WF 4 – with some aimed at existing WF developers (discussing how existing WF developers should think about the new WF model) and others assuming no prior WF experience (simply introducing the new concepts and features).

And, at TechEd, there is opportunity for folks to discuss what’s coming:

There will be some folks from the WCF and WF team showing off WF 4 and VS2010 at the booth – I will be among the motley crew working the station, and would love to catch up
Aaron Skonnard will be doing a session on WCF and WF in .NET 4
Michele Leroux Bustamante and Zoiner Tejada will be doing a precon on WCF and WF 4, and the new ‘Dublin’technology extensions for Windows Server – enhancements that remove the need for WCF and WF developers from having to building a custom host (how cool is that?)
Zoiner Tejada will also be doing an interactive theatre session on his company’s experience as a WF 4 TAP customer – and the migration from WF 3.5 to WF 4 using the ‘Dublin’ extensions.

Wow! Deep Breath

I really hope that this is useful for you as you start to think about Visual Studio 2010 and .NET 4. I’m in the process of writing a complementary post around the WCF changes between the CTP and beta 1, which I hope to have up and posted by mid-week (May 6th-ish). I’ll then be taking a break from the writing while at TechEd (if you’re at the event, feel free to visit the booth and say hi), and then dive back into the word processor to pull together a ‘WF 4 for the .NET 3.5 developer’ to highlight changes since .NET 3.x.

There’s a problem with doing these really long posts – they’re hard to work into the work week. :)

Note: Thanks to Jurgen Willis, Kavita Kamani, Vikram Desai, and Bob Schmidt for their invaluable feedback and help on this entry.