The .NET Endpoint : Workflow

Getting started with Windows Server AppFabric

AppFabric Team — Mon, 30 Nov 2009 22:40:00 GMT

In a previous post we introduced Windows Server AppFabric, a set of extensions to the Windows Application Server that “make it easier to build, scale and manage Web and composite applications that run on Internet Information Services (IIS).” AppFabric enhances the Application Server role in Windows by providing some features out of the box that customers previously have had to build by themselves. These include a scalable distributed cache and features for managing WCF and WF services. In this post I’m going to give you some tips for getting started with the service and workflow management features of AppFabric.

First, if you haven’t already done so, install AppFabric. You’ll find a pointer to the download page on the Windows Server AppFabric Development Center site. Keep this site handy. This is the main site for AppFabric and is where you will find the latest news as well as links to samples, tutorials, and the support forum.

Find the link to the download page on the Dev Center site. Follow that link and take a few minutes to download and read the installation guide and release notes. Install any prerequisite software and Windows hotfixes that you may be missing. The prereqs include .NET 4 Beta 2 and Windows PowerShell v2. If you’re running on Windows Vista SP2 or Windows Server 2008 SP2 you’ll need to uninstall PowerShell v1 and download and install v2. Windows 7 and Windows Server 2008 R2 include PowerShell v2 by default. See the installation guide for details.

On the download page find the Setup package for your machine’s operating system and architecture, and run the Setup wizard. We’ll use only the service and workflow management features of AppFabric for now so we require only the Worker feature to be installed, but install and configure the distributed cache features if you will use those later.

The Dev Center site links to a tutorial that walks you through deploying, configuring, monitoring, and managing a WF service. The tutorial does a nice job introducing most of the service and workflow management features of AppFabric and is well worth the time to go through. The first version of the tutorial has you use the IIS Manager tools for the exercises, while the second version has you complete the tasks using PowerShell cmdlets and scripts. The tutorial comes with a sample application that you will deploy using the Web Deployment Tool. You’ll hear us highlight this tool quite a bit as we talk about managing IIS hosted services. The tool is powerful for synchronizing applications and IIS settings from one machine to another.

If you just want to see some of the features in action, though, you can create a simple workflow service project in Visual Studio 2010 and run it in IIS. Create a new project using the WCF Workflow Service Application template. This will give you a workflow service with a GetData operation that receives a message and sends a response. On the project properties, view the Web tab and configure the application to run in IIS instead of the Visual Studio Development Server. If you’re running Visual Studio elevated as an administrator and you have the IIS 6 Management Compatibility feature of IIS installed you can create a new virtual directory directly from the Web tab. Otherwise, use IIS Manager to create the virtual directory, pointing it to the root directory of your Visual Studio project. (This is where you’ll find the web.config and XAMLX files.)

Once you have your application running in IIS you can see and manage its services with AppFabric. Open IIS Manager and expand the tree. Click on the root node and find the Application Server Extensions for .NET 4 modules in the center features pane. With those modules you can view service activity on the Dashboard, view endpoints, and configure services. Go back to your project in Visual Studio and add a Delay activity at the end of your workflow to keep instances alive for a few minutes so you can watch them go from the Active to Idle states in the Persisted WF Instances section of the Dashboard and see the instances show up in the WF Instance History section as they complete.

AppFabric adds some powerful features to the Windows Application Server. Install the Beta 1 and go through the tutorials to learn about the features in depth, or try a simple scenario on your own to get familiar with the features. If you run into any problems or have feedback to share with us please do so in our forum or via our Connect page.

Developing and Managing Services with Windows Server AppFabric

Cliff Simpkins — Tue, 17 Nov 2009 19:30:00 GMT

Today at PDC we are excited to introduce the Windows Server AppFabric Beta 1. AppFabric evolves the existing application server capabilities of Windows Server to make it easier to build, scale and manage Web and composite applications that run on Internet Information Services (IIS).

For Web applications, AppFabric provides caching capabilities to provide high-speed access, scale, and high availability to application data These capabilities are based on the technology previously code named “Velocity.”

For composite applications, AppFabric makes it easier to build and manage services built using Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF). These capabilities are based on the technology previously code named “Dublin.”

This first post provides an introduction to developing and managing WF services with AppFabric. Download the Beta 1 release at http://msdn.microsoft.com/appfabric.

Introduction to AppFabric

The benefits of having service-based applications, often referred to as SOA, to create systems based on autonomous services have been articulated in several MSDN articles. WCF is the technology that enables this, and in turn has been integrated with other Microsoft developer technologies such as ADO.NET Data Services, WCF rich Internet applications (RIA) services and WCF REST services. In .NET Framework 4, WCF has been deeply integrated with an improved WF runtime enabling you to build WCF services that are implemented with WF.

Whatever technology that you use to build and compose services together, you face challenges based on these questions:. “When building server applications what features of the platform can I take advantage of that light up my application and enable me to focus more on the business?” “Having built this application, where is the best place to test this, to run this in production, and how do I manage it?”

This post focuses on how Windows Server AppFabric, combined with the .NET Framework 4, addresses these challenges, with particular emphasis on WF services.

Developing WF Services

Depending on the architecture of your application, typically you build services focused on the middle tier. For example, ADO.NET Data Services are suited for the data access tier and can be composed together with other services in the middle tier. For an overview of WF services in .NET 4, read the Aaron’s overview of WCF in .NET 4 on MSDN. In the middle tier, WF services are an ideal technology, since they are strongly focused on using declarative approaches for composing services for your business. For additional reading on WCF Services, David Chappell’s ‘The Workflow Way’ provides an excellent introduction to the topic.

The key values that WF Services bring to service authoring are:

Long-running applications that wait for external input for activation such as messages, thereby using resources efficiently.
A single or sequential flow control programming model while handling the complexity of multiple async I/O calls. For example, by using a parallel activity in your WF Service you can coordinate multiple calls to other services allowing the WF runtime to take care of all the async message calls and marshaling the data back to your service.
Coordination of messages to workflow instances with the use of message correlation. WF Services in .NET Framework 4 provide content-based correlation that enables you to query the content of a message for unique information to identify the specific workflow instance the message relates to. This enables long-running scenarios being able to activate a specific workflow instance when clients send messages.
Consistent WCF and WF instrumentation integrated with Event Tracing for Windows (ETW). The WCF and WF runtimes now both emit ETW events for tracing and tracking to provide detailed monitoring and diagnostics. Using ETW provides greater performance, thereby having less impact on your applications.
An expressive set of workflow activities for authoring business process. Here the Flowchart activity is extremely powerful by enabling you to more closely match the typically graphical representation of a business process drawn using Visio, for example, with the implementation of the business in code using the Flowchart.
A simple extensibility model for workflow activities, enabling you to define your own library of business domain activities. These can be included into the Workflow Designer in Visual Studio 2010, enabling developers to more quickly build business WF services.

Hosting and Managing Services

Regardless of the technology used to build your service, where and how you run your services introduces a number of options. Today you can host your services in a process created by the Windows Process Activation service (WAS) in IIS, a Windows service or a self-hosted executable. This provides a mechanism for activating workflows, but is only one part of a broader hosting picture for providing a suitable environment to run your production applications. Typically there are other platform service requirements that as a developer you would like to take advantage of, such as application state storage (persistence), instrumentation for health monitoring, caching, and other capabilities that provide scalability and reliability to deployed applications. Windows Server as an application server today provides services you can take advantage of such as MSMQ for message queuing, and the event log for diagnostics.

Windows Server AppFabric builds on the application server capabilities in Windows Server to 1) host and manage your WCF and WF Services and 2) provide a distributed in-memory data cache. AppFabric provides a set of common services that your applications can take advantage of thereby allowing you as a developer to concentrate on building solutions that solve key business problems. These common services are focused on enhancing Windows Server’s WCF and WF Service hosting capabilities, and making it easier to manage these services. Additionally the distributed cache introduces rich scale-out capabilities for applications built using .NET Framework.

Persisting WF Services

The key scenarios this enables are;

Reliability – The ability to persist (save) workflow state and reliably resume workflow instances that have been idle for a defined time interval.
Availability – The recovery of saved workflow state when an application, process, or computer terminates unexpectedly.
Scalability – The ability to unload idle workflow instances from memory to efficiently use resources, the capability of retrying to load workflow instances when a message arrives on a different computer in the host farm, and gracefully handling retries when there is a lock on the instance.

Windows Server AppFabric provides a Windows service called the Workflow Management service (WMS) that manages instances in the persistence store. AppFabric can install a SQL Server persistence store for your WF Services which the WMS monitors to enable the scenarios above. AppFabric also supports other store solutions as well.

Monitoring

The key scenarios this enables are;

Health monitoring – How well is my app running? The ability to see expected healthy events occur within your service to know that it is still operational.
Troubleshooting – What has failed with my app? The ability to quickly diagnose failures within your service and either correct these or provide a developer with further detailed information.

Windows Server AppFabric provides a Windows service called the Event Collector service that captures health and failure events from your services and writes these to a SQL Server monitoring store, or another store built to leverage the pluggable AppFabric monitoring solution. This provides analytical data about your applications. You can either take advantage of rich UI tooling integrated into IIS Manager to view these events in the monitoring store, or build your own reporting using SQL Server Reporting Services or another data analysis solution, to view this data.

Process Hosting

The key scenarios this enables are:

Efficiently using computer resources by hosting services in the Windows Process Activation Service (WAS) in IIS. IIS and the WF runtime are deeply integrated. For example, if IIS decides to recycle a process due to memory constrains it will communicate with the WF Service to ensure that a graceful shutdown occurs, thereby allowing the service to be restarted in another process or on another computer by the WMS.
Auto-start to “warm-up” services hosted in IIS. When the computer starts, or when IIS starts, services can be pre-warmed, thereby reducing the latency on the first message.

By integrating the WF runtime deeply with the IIS/WAS process activation model, WF Services are ideally suited to being hosted in IIS/WAS and benefit from the rich hosting capabilities that IIS/WAS provide.

Distributed Caching

Distributed, service-oriented applications often require support for a large number of users, and high performance, throughput, and short response time. Services are increasingly moving “far away” from their underlying data stores and in many cases those data stores are “expensive” to access due to both technical and licensing costs. As a result, developers are increasingly forced to find alternatives to continually accessing the physical data store and often turn to caching to meet these challenges.

Windows Server AppFabric provides a distributed, in-memory, application cache for developing scalable, available, and high-performance applications. The caching capabilities fuse memory across multiple computers to give applications a single unified cache view that can be easily scaled-out by simply adding more computers on demand.

Some key caching features provided by Windows Server AppFabric include:

Caching any serializable CLR object and providing access through simple cache APIs
Enterprise scale: tens to hundreds of computers
Configurable to run as a service accessed over the network
Dynamic scale-out by adding new nodes
High availability through backup copies
Automatic load-balancing
Seamless integration with ASP.NET with an ASP.NET Session State Provider (better perf and scale and no more sticky routing!)
Integration with administration and monitoring tools such as Windows PowerShell, Event Tracing for Windows, and System Center.

Tooling

The tooling support for services in Windows Server AppFabric will be covered in more detail by future posts. Integrating tooling into IIS Manager provides a familiar management, control, and monitoring experience for the IT professional managing applications in a production environment or the developer troubleshooting deployed applications. In addition, AppFabric provides an extensive set of Windows PowerShell commands to enable you to script the capabilities in the UI.

Summary

This post describes the key benefits of building WF Services with Visual Studio 2010 and .NET Framework 4, and the benefits of hosting these in Windows Server and managing and scaling them with AppFabric.

The deep integration of WCF and WF provides an intuitive approach for developing declarative WF Services. WF Services make it possible to build long-running services that take advantage of the service coordination support provided by the workflow runtime, enabling you to use workflow to solve key business problems.

Windows Server AppFabric adds improved hosting capabilities to Windows Server to efficiently host all your WCF services, including WF Services. Additionally, AppFabric provides common services that help you as a developer build scalable Web and composite applications.

Downloads

You can download Visual Studio 2010 Beta 2 from the Visual Studio 2010 page on MSDN.

You can download Windows Server AppFabric Beta 1 from AppFabric page on MSDN.

New Beta 2 docs to help with code migration (from .NET 3.x and .NET 4 Beta 1)

Cliff Simpkins — Mon, 02 Nov 2009 16:06:08 GMT

Fresh on the heels of the beta 2 release of .NET 4/Visual Studio 2010, the team has been working on supplemental documentation to help you out with evaluation and adoption of WCF and WF in .NET 4.

Last week, two sets of documentation went live:

WF4 Migration Guidance: The WF team updated the documents to .NET Beta 2. We posted the documents up to the Downloads site mid last week.
B1->B2 Breaking Changes: The team also created a document that outlines the breaking changes between Beta 1 and Beta 2 of the .NET Framework 4.

We have a couple of new migration guidance documents in their final authoring/reviewing stages, and I hope to have them published out to the Downloads site by the time PDC comes around.

It’s exciting times having the second beta bits out, seeing what folks are doing with the new capabilities in .NET 4, and hearing from some customers that they are planning on taking advantage of the ”Go Live” License that is available with the Beta 2 release.

At any rate – happy Monday all – enjoy the docs and the new beta! If you’re heading to PDC and want to grab lunch with someone from the team while at the event, remember to drop me a note. BTW – I saw the shirts for the event last week – they look real nice!

WF4 Changes Between Beta 1 and Beta 2

mwinkle — Tue, 20 Oct 2009 05:25:50 GMT

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:

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

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!

All WCF, WF, and ‘Dublin’ sessions live on PDC site; 5 Weeks to Go!

Cliff Simpkins — Wed, 14 Oct 2009 17:01:09 GMT

We’re five weeks out from PDC09, and the rest of our sessions went live last week. I know I posted a couple weeks ago about PDC and sessions that went live, but I wanted to let folks know about the four new sessions – to help you maximize your experience around the Connected Framework technologies!

This looks to be a great event, as the team dives in deep on the enhancements coming with .NET 4, and discussing some of the thoughts around what’s to come next.

PDC Sessions of Note
The below list is a refresh of the one I posted a couple weeks ago, with additions marked out.

The larger team will be delivering the following seven sessions:

In addition to the sessions being done by the team, WCF comes up in several other sessions of note at the event:

On the Floor of the Event
As an update, we have confirmed that we will have a small 20-seat theatre in the Framework and Tools lounge area. In the theatre area, we’ll be doing a series shorter ‘chalk talks’, discussing more special interest topics. There are some real gems being planned for discussion; we’re looking forward to hearing your thoughts.

I’ll post up any additional notes as we come up on the event. And, as a reminder, drop a note if you want to catch up with someone from the team while at PDC. Let me know what you would like to discuss, and I’ll reach out to the team that will be in LA and try to connect you with someone so you can coordinate schedules.

Hope to see y’all in LA!
Cliff

The team is getting ready for PDC; are you?

Cliff Simpkins — Tue, 29 Sep 2009 21:19:03 GMT

The 2009 Professional Developers Conference (PDC) is less than a couple months away, and the team is starting to create content and demos for the event. The team has been working with PDC event management over the last couple months to secure sessions and space at the event; and I wanted to share with you how the event is shaping up, as well as make a plug for our sessions.

The event will deliver a lot of really great material, as well as provide you with access to folks who are writing the code. We hope you can make it down to Los Angeles in November for the event.

PDC Sessions Of Note

So far, four sessions are currently live on the PDC event website:

In addition to the sessions being done by the team, WCF comes up in several other sessions of note at the event:

We are working very hard to not present the same content as last year.

For WF, we’re building upon last year’s introductions to WF4 to expose more of the underlying architecture of the new WF runtime, really giving you a view into how different the new runtime is…and demonstrating how workflow services work in the new Windows Application Server technology (codename ‘Dublin’).

For WCF, we heard you loud and clear that there wasn’t enough WCF content. This year, we have a session focusing on the WCF enhancements coming in .NET 4, in addition to the sessions covering how WCF is used with HPC Server, Silverlight, and covering advances in ADO.NET Data Services (which is built upon WCF).

And, last but not least, last year’s PDC introduced the technology called ‘Dublin’ – and it’s been a hot topic for customers ever since PDC. This year, we dive deeper into how ‘Dublin’ lights up WCF and WF applications and where we’re going with the technology.

We have a few more excellent sessions in the pipeline covering technology futures; and I’ll post the updated list up here when the next batch of sessions goes live.

On the Floor of the Event

Beyond sessions, speakers and other team members will be at the event in the lounge area for Framework and Tools, both to hang out and chat with you about the technologies, as well as working a couple booths in the lounge area to show the technologies in action.

Anyone attending PDC is encouraged to stop down to the lounge and say hello. Bring your questions or just share your thoughts on the technologies; we truly love meeting our customers – and your comments and questions do have direct impact on the shape of the future platform. If there’s someone in particular you would like to connect with, let me know – I’m happy to share folks’ lounge schedules as we come up on the event and schedules are finalized…just let me know who you’re looking to connect with or a particular topic you want to drill down on.

We are currently working on getting a small 20-seat chalk-talk area in the lounge area again this year to do smaller, more niche discussions. We’ll post more on that topic here in the coming weeks, as well, as we make progress on that front.

Pre-PDC Workshops

And, lastly, it’s worth noting that Michele Leroux Bustamante will be running a pre-PDC workshop covering the Microsoft Technology Roadmap, helping workshop attendees understand how the many technologies that make up the .NET Framework fit together – from A-W (Azure to Azure). ^_^

There is also a FREE Windows 7 Developer Boot Camp pre-PDC workshop that is open to anyone (whether attending PDC or not) as long as there is room.

Not registered? There’s still room!

There’s still room at the event, and I hear they have a $300 discount for folks registering before October 13 (and there’s also a significant discount for students and employees of academic institutions). And there is still plenty of hotel availability around the convention center as of a couple weeks ago (when I registered). A couple of the closest hotels were full, but there are still plenty of quality ones about.

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

Tracking Participants in .NET 4 Beta 1

.NET Connected Framework Team — Wed, 15 Jul 2009 02:11:33 GMT

Hello! My name is Miguel Susffalich and I work in the Connected Framework team. In previous posts we have showed an Introduction to Workflow Tracking and a deep dive into Tracking Profiles in .NET 4 Beta 1.

In this post we will explain how Tracking Participants work and how they are used to process and store the Tracking Records emitted from the workflow. We will also cover the out of box Event Tracing for Windows (ETW) Tracking Participant and how to use it to view Tracking Records in Event Viewer.

You can also try out the following samples for a more hands on experience with Tracking in .NET 4 Beta 1. Throughout this blog post, we will be using several examples contained in these resources:

1) WCF and WF samples for .NET 4 Beta 1

2) ETW tracking participant sample

Tracking Participant Overview

As mentioned in the Introduction to Workflow Tracking, in WF 4 there are 3 main components to the tracking infrastructure:

1) Tracking Records are emitted from the Workflow Runtime.

2) Tracking Profiles let you subscribe to Tracking Records in a declarative, flexible manner.

3) Tracking Participants listen to the Tracking Records being emitted from the runtime directly and process them in whatever way they choose to. This includes writing to a specific output (e.g. File, Console, ETW), processing/aggregating the records, or any other combination that might be required.

In WF 4, multiple tracking participants can consume the tracking events simultaneously. Each tracking participant can be associated with a different tracking profile.

Tracking Participants are used to get the tracking data emitted from the workflow and store it into different mediums. Likewise, any post processing on the Tracking Records can also be done within the Tracking Participant. In future posts we will cover the full extensibility of the Tracking infrastructure provided in WF 4, including writing Custom Tracking Participants.

Next we will look at the out of box Tracking Participant included in .Net 4 Beta 1; the ETW Tracking Participant.

Out of box ETW Tracking Participant

In .NET 4, we ship an out of box Event Tracing for Windows (ETW) Tracking Participant which writes the Tracking Records to ETW. The ETW Tracking Participant writes these records to an ETW session in a very efficient manner with minimal impact to the app’s performance.

One of the advantages of using this tracking participant is the tracking records can be viewed in the Windows Event Viewer, alongside your application and system logs.

The ETW tracking participant is configured in the web.config as follows

<system.web>

</system.web>

<system.serviceModel>

<add name="EtwTrackingParticipant"

type="System.Activities.Tracking.EtwTrackingParticipant, System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

profileName="HealthMonitoring_Tracking_Profile"/>

</participants>

</tracking>

</trackingComponents>

</behavior>

</serviceBehaviors>

</behaviors>

</system.serviceModel>

</configuration>

In ETW, events are written to the ETW session through a Provider Id. The Provider Id that the ETW Tracking Participant uses for writing the Tracking Records to ETW is defined in the diagnostics section of the web.config (under <system.serviceModel><diagnostics>):

<system.serviceModel>

…

By default, the ETW Tracking Participant uses a default Provider ID when one has not been specified.

Tracking Participants are declared in the <system.serviceModel><tracking><participants> section. Each tracking participant can have a profile associated with it to specify the tracking records it has subscribed to:

<system.serviceModel>

…

<add name="EtwTrackingParticipant"

type="System.Activities.Tracking.EtwTrackingParticipant, System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

profileName="HealthMonitoring_Tracking_Profile"/>

</participants>

</tracking>

…

Once they have been declared, the Tracking Participants can be added to the service behavior. This will add the selected Tracking Participants to the Workflow instance’s extensions, so that they begin to receive the Tracking Records.

For this, we simply use the same name with which the Tracking Participant was declared in the previous step:

</trackingComponents>

</behavior>

</serviceBehaviors>

</behaviors>

A graphical representation of the flow of Tracking data through the ETW Tracking Participant would be as follows:

Once the tracking data reaches the ETW Session, it can be consumed in a number of ways. One of the most useful ways to consume these events is through Event Viewer, a common Windows tool used for viewing logs and traces from applications and services.

Consuming Tracking data from the ETW Tracking Participant in Event Viewer

Events that are written to the ETW session by the ETW Tracking Participant can be consumed through Event Viewer (when using the default Provider ID). This allows for rapidly viewing the Tracking Records that have been emitted by the workflow.

To enabling viewing the Tracking Records in Event Viewer:

1) Open Event Viewer (eventvwr.exe)

2) Navigate to “Application and Services Logs”-> “Microsoft” -> “WCF” -> “WF-Development”

3) Right-click and enable View -> “Show Analytic and Debug logs”

4) Enable the log

In the ETW Tracking Participant Sample, the workflow simulates to have an error, and the ETW Tracking Participant is used to trace the issue. The tracking events are displayed in the Event Viewer below:

All the Tracking Records have ETW event IDs ranging from 100-112. Other event IDs (200-225) are used for other types of tracing such as WCF Traces. In future posts we will cover correlating tracing and tracking events for a full end-to-end view of the monitoring data.

Tracking Records emitted through the ETW Tracking Participant also appear with the appropriate severity level in Event Viewer. This way it is easy to identify any warnings or errors with the execution of the workflow.

With the ETW Tracking Participant and its integration with Event Viewer, consuming Tracking Records is fast and easy in .Net 4 Beta 1.

What’s Next

In future posts we will cover writing Custom Tracking Participants and emitting Custom Tracking Records. In the meantime, we look forward to your feedback on our samples and Hands on Labs:

1) WCF and WF samples for .NET 4 Beta 1

2) ETW tracking participant sample

WF 3.5 Hands On Labs Updated

Cliff Simpkins — Wed, 01 Jul 2009 03:39:18 GMT

The ten Windows Workflow Foundation (WF) hands-on labs were updated today on Microsoft download center for your coding enjoyment!

These ten labs were initially posted when WF was new to the world and .NET 3.0 was hot off the presses. This past winter, the product management team worked with David Starr to get the labs converted to .NET 3.5 and Visual Studio 2008, make the manuals consistent, and bring the VB.NET code up par to follow the same best practices as the C# code.

Once installed, you will have the following labs installed on your machine:

WF01: Getting Started with WF
WF02: Creating Custom Activities with WF
WF03: Hosting Workflows in WF
WF04: Creating State Machine Workflows in WF
WF05: Communicating with the Host Application for WF
WF06: WF and Web Services
WF07: Creating Rules Driven Workflow in WF
WF08: Transactional Behavior in WF
WF09: Modifying Workflow Models at Runtime with Workflow Change in WF
WF10: Embedding the Workflow Designer for WF

About half the labs saw some significant updating and clean-up – and they should yield a greatly improved experience for the learner; we applied feedback from HOL participants who took the labs at our events and provided an evaluation. The second half of the labs were more simply migrated and cleaned up for consistency.

But wait! There’s more! :)

While we were at it, we added an eleventh lab to the mix. Because the labs were developed before the new WCF activities were introduced, we dug into the excellent Visual Studio 2008 training kit done by the DPE folks, we updated and cleaned up the lab that walked a user through using the new WCF Send and Receive activities for WF in .NET 3.5:

WF11: Workflow Enabled Services and Other New Features in the .NET Framework 3.5

The product management team will be making three additional hands-on labs available in the near future: unit testing WF workflows (currently available on MSDN Virtual Labs), unit testing WCF services, and advanced context management in WF 3.5 (built by Matt Milner, and unveiled at TechEd 2009 North America). All three labs have scored pretty well at events, and we’re looking forward to sharing them with you for direct download.

We hope that you find these updated labs useful; and, as always, welcome your feedback and comments.

Enjoy!
- Cliff

Workflow Tracking Profiles in .NET 4.0 Beta 1

.NET Connected Framework Team — Fri, 19 Jun 2009 20:56:01 GMT

Last week we introduced the new Workflow Tracking features in .NET 4.0. In this post we’ll do a deep dive into tracking profiles and explain how to use them to track workflow execution in a flexible way.

Tracking Profile Overview

Tracking profiles let you subscribe to events that are emitted by the runtime when the state of a Workflow instance changes. Depending on your monitoring needs you may craft a profile that is very coarse, subscribing to a small set of high level state changes on a Workflow. On the other hand you may create a very granular profile whose output is rich enough to reconstruct the execution later. Tracking profiles can satisfy these extreme scenarios and anything in between.

Tracking profiles manifest themselves in one of two ways. You can create tracking profiles programmatically in .NET or configure them as XML elements in the <system.serviceModel> section of a standard .NET configuration file. This post covers configuration based profiles. Here is an example tracking profile in .NET 4.0 Beta 1:

<system.serviceModel>

…

</states>

</workflowInstanceQuery>

</workflow>

</trackingProfile>

</profiles>

</tracking>

…

</system.serviceModel>

Tracking Profile Structure

Tracking profiles are structured as declarative subscriptions to events, or tracking queries that let you “query” the Workflow Runtime for specific event records. There are a handful of query types that let you subscribe to different classes of events. Here are the most common query types that you can try out in .NET 4.0 Beta 1:

· WorkflowInstanceQuery – Use this to track Workflow instance lifecycle changes like Started and Completed.

· ActivityQuery – Use this to track lifecycle changes of the activities that make up a Workflow instance. For example, you may want to keep track of every time the “Send E-Mail” activity completes within a Workflow instance.

· FaultPropagationQuery – Use this to track the handling of faults that occur within an activity. This event occurs each time a FaultHandler processes a fault.

· UserTrackingQuery – Use this to track events that you define in your code activities. There will be a follow up to this post that shows you how to create user tracking records.

Variable Extractions

When tracking the execution of a Workflow it is often useful to extract data. This provides additional context when consuming the tracking records post execution. Tracking profiles make this easy. In .NET 4.0 you can extract variables from any activity in a Workflow. The following example activity query comes from the monitoring hands on lab that shipped with the WCF and WF samples for .NET 4.0 Beta 1. It shows how to extract the “StockSymbol” variable whenever the “GetStockPrice” activity completes.

</states>

</variableQueries>

</activityQuery>

</activityQueries>

Annotations

Annotations in Workflow 4.0 let you arbitrarily tag tracking records with a value that can be configured after build time. For example, you might want several tracking records across several Workflows to be tagged with “Data Center” == “Contoso Data Center”. This makes it easy to find all records with this tag when querying tracking records later. To accomplish this, you would add an annotation to a tracking query like this:

</states>

</annotations>

</activityQuery>

</activityQueries>

What’s Next

In the next post in the series, we will talk about the extensibility of Workflow tracking in .NET 4.0. This topic will dive into the following concepts:

· Programmatically emit your own tracking events by creating UserTrackingRecords.

· Programmatically consume events within the runtime by creating custom TrackingParticipants.

· Programmatically create tracking profiles in .NET.

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)

Introduction to Workflow Tracking in .NET Framework 4.0 Beta1

.NET Connected Framework Team — Fri, 12 Jun 2009 04:01:05 GMT

By now you must be aware of the significantly enhanced Windows Workflow Foundation (WF) scheduled to be released with .Net Framework 4.0. The road to WF 4.0 and .Net Framework 4.0 Beta1 documentation for WF can give you more details. Being a member of the team responsible for the development of the WF tracking feature, I am excited to discuss the components that constitute this feature. In a nutshell, tracking is a feature to gain visibility into the execution of a workflow. The WF tracking infrastructure instruments a workflow to emit records reflecting key events during the execution. For example, when a workflow instance starts or completes tracking records are emitted. Tracking can also extract business relevant data associated with the workflow variables. For example, if the workflow represents an order processing system the order id can be extracted along with the tracking record. In general, enabling WF tracking facilitates diagnostics or business analytics over a workflow execution. For people familiar with WF tracking in .Net 3.0 the tracking components are equivalent to the tracking service in WF 3. In WF 4.0 we have improved the performance and simplified the programming model for WF tracking feature.

A high level view of the tracking infrastructure is shown below

The primary components of the tracking infrastructure are

1) Tracking records emitted from the Workflow runtime.

2) Tracking Profile to filter tracking records emitted from a workflow instance.

3) Tracking Participants that subscribe for tracking records. The tracking participants contain the logic to process the payload from the tracking records (e.g. they could choose to write to a file).

The Workflow tracking infrastructure follows the observer pattern. The workflow instance is the publisher of tracking records and subscribers of the tracking records are registered as extensions to the workflow. These extensions that subscribe to tracking records are called tracking participants. Tracking participants are extensibility points that allow a workflow developer to consume tracking records and process them. The tracking infrastructure allows the application of a filter on the outgoing tracking records such that a participant can subscribe to a subset of the records. The mechanism to apply a filter is through a tracking profile.

The workflow runtime is instrumented to emit tracking records to follow the execution of a workflow instance. The types of tracking records emitted are

· Workflow instance tracking records: Workflow instance records describe the life cycle of the workflow instance. For instance a record is emitted when the workflow starts or completes.

· Activity tracking records: Activity tracking records are emitted when a workflow activity executes. These records indicate the state of a workflow activity (i.e. an activity is scheduled, activity completes or fault is thrown).

· Bookmark resumption tracking record: A bookmark resumption record tracks any bookmark that is successfully resumed

· User tracking records. A workflow author can create custom tracking records within a custom workflow activity and emit them within the custom activity. Custom tracking records can be populated with data to be emitted along with the records.

Out of the box in WF 4.0 we provide an ETW (Event Tracing for Windows) based tracking participant. The ETW tracking participant writes the tracking records to an ETW session. The participant is configured on a workflow service by adding a tracking specific behavior in a config file. Enabling ETW tracking participant allows tracking records to be viewed in the event viewer. Details of using the ETW based tracking participant will be covered in a future post. The SDK sample for ETW based tracking is a good way to get familiar with WF tracking using the ETW based tracking participant.

In future posts we will discuss the WF tracking feature in depth. Topics covered will include tracking profiles and tracking records, ETW tracking participant, writing custom tracking participants, variable extractions and unified tracking and tracing.

Migration Guidance for the WF Developer

Cliff Simpkins — Fri, 05 Jun 2009 19:32:10 GMT

This morning, I’m pleased to announce that the team has posted four initial Windows Workflow Foundation (WF) migration guidance documents to help current WF developers evaluate the new WF programming model that is being introduced in .NET Framework 4.

The documents were written by the PM team to help describe the relationship between the existing WF technology that was introduced in .NET 3.0 (defined as the types in the System.Workflow.* namespaces; referred to in the documents as WF3 for simplicity and brevity) and the new WF technology that is being released in .NET 4 (the System.Activities.* namespaces; referred to in the documents as WF4). The team explains how to think of WF features within the two programming models, and the choices you have as a user or a potential user of workflow technology in .NET 4.

Because this is a very broad topic, we’ve broken up what was initially going to be a single paper into about eight. There is an overview document and [currently] seven papers that take the form of either higher level guidance and cookbook papers. Today’s initial release introduces the higher-level guidance documents, with the cookbooks to be released in the coming weeks.

As the documents are updated, we will be releasing them to the WF Migration Guidance download on the MS Download Center, and the accompanying source code will be posted on a WF Migration Guidance project on the MSDN Code Gallery.

The document list looks like the following:

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

The papers will continue to be grown and updated as we move towards the RTM release – to address a larger number of usage scenarios, and to address any changes that happen between pre-releases. We’ve been working on the documents over the last month, and think that they provide some good initial thoughts on how to approach the technology; and we hope that you find them helpful

The team will be supporting feedback and requests for the documents and accompanying sample code in the WF 4 forum on MSDN. I’m told the feature PMs will be creating a thread for each document to make it easier to provide feedback and for the PMs to respond – we should have more information on that in the next few days.

Workflow 4.0 Templates

.NET Connected Framework Team — Tue, 02 Jun 2009 06:58:58 GMT

This blog post introduces the Project and Item templates for Workflow 4.0. It also clarifies as to how the Workflow 3.0 templates are still available for users to create projects and then upgrade them to the 4.0 Framework.

We are putting in a deep though into what kind of templates do users want? Do they help users get kick started with the kind of application they typically want to create? How much setting changes the user might have to do for his applications? Is it an accurate reflection of the OM? Do we have too many/too less templates? So what do you think? What would you prefer to see/not to see? Are the names intuitive enough? Please let us know so that we can update them in time for the VS 2010 release.

Thanks,

Kushal.

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!