Initialize and Uninitialize are the markers for an activity's execution lifetime. For the rest of this paragraph any reference to an "activity instance" will have NOTHING to do with its CLR lifetime. Since workflows are unloaded and loaded numerous times during execution a single "activity instance" could actually have been executed through the use of dozens of CLR object instances of the activity. That said, before an "activity instance" will take part in any of the protocol signals it will be initialized; this includes the initialization of cloned activities which execute in new contexts. Once an "activity instance" is done taking part in the protocol it will have Uninitialize called.

See RuntimeModificationOfWorkflows for an example of how to use this function.

The WF runtime engine executes workflows by using runtime services. The runtime service model gives the host application the flexibility to provide various services to the WF runtime engine. This section describes the runtime services that are provided by WF and the out-of-box implementations of those services.

Function of the WorkflowCompiler type used to compile both XOML and code workflows.

Programming Windows Workflow Foundation by Scott Allen If you enjoyed this article, you'll enjoy the book even more! Order now from Packt Publishing and save 10%! The base activity library in Windows Workflow contains general-purpose activities for constructing workflows. There are activities for control flow, transaction management, local communication, web services, and more. These activities appear on the toolbox window of the workflow designer. Some of these activities, like the CodeActivity, are simple. The job of the CodeActivity is to execute a block of code. Other activities, like the PolicyActivity, are more complex. The PolicyActivity can evaluate prioritized rules with forward chaining. We can build powerful workflows using just the activities inside the base activity library.

A host can subscribe to the workflow runtime's WorkflowSuspended event and retrieve the error message using the Error property of the WorkflowSuspendedEventArgs parameter. Another property of this parameter is the WorkflowInstance property. A host can recommence execution using the Resume method of the WorkflowInstance class, or bring about a sad, but early ending with the Terminate method.

Like the Parallel activity, the Listen activity can contain multiple branches. Unlike the Parallel activity, the goal of a Listen activity is to finish just one branch. The branches of a Listen activity are Event Driven activities, and we must start the branches by waiting for an event (the first child must implement the IEventActivity interface). We'll see the Event driven activity in more detail when we cover state machine workflows.

All of the workflows we've examined so far have been sequential workflows. Windows Workflow also supports state machine workflows, which is where the activities in this section come into play.

State machine workflows are a good fit for modeling a process where decisions come from outside the workflow. When we make a decision, like closing a bug, we have a local communication service raise an event to the workflow. The workflow keeps track of which state it is in, and which states it can transition into from the current state. For instance, we might say that an open bug has to be assigned before it can be closed, but it can move from the open state directly to the deferred state. The first step in setting up a state machine is defining the states.

We've been through all of the activities in the Windows Workflow base activity library. We've seen event handling, local and remote communication, control flow, and more. As we outlined at the beginning, these activities are generic and general-purpose activities that can build powerful workflows and solve problems across a variety of business domains. However, WF allows us to build custom tailored activities to solve our business problems, and this will be our next topic to cover.

The primary reason for this service type is to enable custom error-handling logic. If the DefaultWorkflowCommitWorkBatchService service owns the transaction, because it created one when Current returns null (Nothing in Visual Basic), it can call the delegate more than once, creating a new transaction for each call. The most common example of this is to handle intermittent network problems or SQL cluster failovers. If the call to the CommitWorkBatchCallback throws an exception, WorkflowCommitWorkBatchService can catch this exception, start a new transaction, and call the delegate again. This gives a level of resilience to workflow instance execution that otherwise would cause workflows to terminate.

DefaultWorkflowSchedulerService creates and manages the threads that run workflow instances in an asynchronous manner on the workflow runtime engine and includes default support for having multiple workflow instances queued in the runtime thread pool. If no other workflow scheduler service instance is added to WorkflowRuntime, it uses the DefaultWorkflowSchedulerService by default.

See also: ManualWorkflowSchedulerService

One reason to use tis might be with generic parameters, something not supposted in XOML workflows. Use a custom serializer to enable this.

• Use state versus sequential workflows.

See SequentialVersusStateWorkflows for the details. Next time I will write about where to leave all the information/data required by the workflow.

So the next question is how much to put in a single workflow. This is basically a question of creating bit catch all workflows versus smaller granular workflows.

An alternative to spawning new workflows would be to modify the workflow at runtime adding the required steps. The main benefit would be that everything stays nice and contained in a single workflow making it easier to track but the drawback is that part of the workflow is designed in code removing the a major benefit of WF in that a picture is worth a thousand words.

Model your workflows after the real processes in your organization. If one process activates another take a good look if it is really part of the first process of more the result of it. Often it will turn out to be just a new resultant process that really should be a different depended workflow.

If you are using StateWorkflows you will need to set the WaitForIdle property to true. Failing to do so can result in events getting lost or similar unpredictable event reception.

Programming Windows Workflow Foundation by Scott Allen If you enjoyed this article, you'll enjoy the book even more! Order now from Packt Publishing and save 10%! The base activity library in Windows Workflow contains general-purpose activities for constructing workflows. There are activities for control flow, transaction management, local communication, web services, and more. These activities appear on the toolbox window of the workflow designer. Some of these activities, like the CodeActivity, are simple. The job of the CodeActivity is to execute a block of code. Other activities, like the PolicyActivity, are more complex. The PolicyActivity can evaluate prioritized rules with forward chaining. We can build powerful workflows using just the activities inside the base activity library.

A host can subscribe to the workflow runtime's WorkflowSuspended event and retrieve the error message using the Error property of the WorkflowSuspendedEventArgs parameter. Another property of this parameter is the WorkflowInstance property. A host can recommence execution using the Resume method of the WorkflowInstance class, or bring about a sad, but early ending with the Terminate method.

Like the Parallel activity, the Listen activity can contain multiple branches. Unlike the Parallel activity, the goal of a Listen activity is to finish just one branch. The branches of a Listen activity are Event Driven activities, and we must start the branches by waiting for an event (the first child must implement the IEventActivity interface). We'll see the Event driven activity in more detail when we cover state machine workflows.

All of the workflows we've examined so far have been sequential workflows. Windows Workflow also supports state machine workflows, which is where the activities in this section come into play.

State machine workflows are a good fit for modeling a process where decisions come from outside the workflow. When we make a decision, like closing a bug, we have a local communication service raise an event to the workflow. The workflow keeps track of which state it is in, and which states it can transition into from the current state. For instance, we might say that an open bug has to be assigned before it can be closed, but it can move from the open state directly to the deferred state. The first step in setting up a state machine is defining the states.

We've been through all of the activities in the Windows Workflow base activity library. We've seen event handling, local and remote communication, control flow, and more. As we outlined at the beginning, these activities are generic and general-purpose activities that can build powerful workflows and solve problems across a variety of business domains. However, WF allows us to build custom tailored activities to solve our business problems, and this will be our next topic to cover.

Depending on the object used to call GetService a number of RuntimeServices might not be returned, a null/Nothing is returned instead. This is the case with a ActivityExecutionContext which will not return any of the following: WorkflowSchedulerService, WorkflowPersistenceService, TrackingService, WorkflowCommitWorkBatchService, WorkflowLoaderService or the WorkflowRuntime itself.

For more information, see the HandleExternalEventActivity class, GeneratingCommunicationActivities, and UsingLocalServicesInWorkflows.

The ListenActivity cannot be used in state machine workflows.

            <add type="System.Workflow.Runtime.Hosting.ManualWorkflowSchedulerService, 

ManualWorkflowSchedulerService is used for synchronous execution of workflow instances. If this service is being used, the workflow instances are executed on the calling thread from the host application, thus blocking the execution of the host application until the workflow instance becomes idle.

When using ManualWorkflowSchedulerService in an WebService environment with the DelayActivity you need to set the UseActiveTimers of the ManualWorkflowSchedulerService to true and make sure the ASP.NET process is reloaded when IIS unloads it.

If you want to use the ManualWorkflowSchedulerService without the UseActiveTimers you are responsible for restarting a workflow after the DelayActivity has expired. To do so you need some kind of periodic event like a timer. The following example uses a Timer but as that is what the UseActiveTimers option actually does it is just an example of the sort of code you need to write.

        ManualWorkflowSchedulerService scheduler = new ManualWorkflowSchedulerService();

        ManualWorkflowSchedulerService scheduler = workflowRuntime.GetService<ManualWorkflowSchedulerService>();

        var workflows = workflowRuntime.GetLoadedWorkflows();

        foreach (var item in workflows)

See also: DefaultWorkflowSchedulerService

• A new management product code named System Center “Service Desk” will be delivered in the second half of 2007. This product will be using Windows Workflow Foundation and Office 2007 products as a basis for automating IT across people, process and technologies and will include a core set of software automated Microsoft Operations Framework (MOF) process workflows as part of the solution.

Well one of the most powerful features of Workflow Foundation is its capability to have long running workflows. Now long running workflows would not be very useful if the client application needs to keep its proxy alive for as long as it need to communicate with the workflow. Guess that would make "long running" a very relative thing. But with this technique all the client has to do is save the workflow instanceId somewhere, perhaps a database table, and it can reconnect to the same workflow at a later point in time.

    assemblies.Add(GetType(WorkflowServiceHost).Assembly)

Now this sucks big time if you ask me Sad. I would much rather have seen that you could specify the instanceId of the workflow to be created, just as you can with the WorkflowRuntime.CreateWorkflow() where a number of the overloads let you specify the workflows instanceId. I suppose it is possible to create a different context binding but that would be quite some work and, I assume, duplicate a lot of code already written my Microsoft. So let's hope they see the light and add MSMQ/ReceiveActivity intergration.

Using the designer end users can modify/create workflows.

Note that the designer was originally designed for developers so leaves something to be desired for end users. Although a lot can be done not everything is possible. Most notable adding custom properties to workflows and adding code. Also some UI parts, like the compensating/fault view, cannot be be changed or removed.

By default, the ReplicatorActivity activity finishes when all child activities have finished. You can use the UntilCondition property to stop execution of the ReplicatorActivity before the completion of the child activity instances. For more information about conditions, see Using Conditions in Workflows.

Consider the following scenario. You have long running, lets assume a year on average, and part of the workflow has to do with shipping products. And lets assume that the shipping is done by any one of a number op shippers and that this involves multiple steps, sort of a mini workflow itself, which are different for each shipper. Now you could add a big IfElseActivity with a branch for each possible shipper and be done with it. But now suppose the company starts doing business with a new shipper. So you go and add an branch to the IfElseActivity and implement the new shipper, no big deal. But all already running workflows are based upon the original workflow without the new shipper, so they cannot use the new shipper. And if the new shipper is a lot cheaper that means you have to explain why all the additional shipping costs are made

Collection of objects that actually do most of the work in WF. There are some required services that are always present, if the developer add one that is used otherwise a default is used. For example the DefaultWorkflowSchedulerService is the default implementation of the rquired WorkflowSchedulerService. Some other RuntimeServices are optional but provided out of the box like the SqlWorkflowPersistenceService. If not provided there is no default and this functionality is unavailable. The third kind of RuntimeServices is the custom RuntimeServices usually developed in combination with a custom workflow Activity. These services can use the WorkflowRuntimeService as a base class although this is not required and they can derive from another class is so desired. Use the WorkflowRuntime AddService function to configure the WorkflowRuntime.

Hosting the workflow runtime in a WorkflowServiceHost is nice but in all likelihood you will also need to configure the workflow runtime itself and add some WorkflowRuntimeService to it. So how to do this when you never actually create the workflow runtime yourself?

WorkflowServiceHost host = new WorkflowServiceHost(typeof(Workflow1));

          <workflowRuntime name="WorkflowServiceHostRuntime"

The StateWorkflow is the more fluid of the two. Basically the workflow is in a given state and waiting for events to move it into another state. This new target state can be every other state in the workflow. Normally this happens because an event is raised and the current state, or one of its parents knows how to handle the event and does so to trigger a state change. The workflow itself actually has another way, the SetStateQueue queue with a SetStateEventArgs argument to indicate the target state, which can be used to activate any other state, even if there is no event that has the new state as target. This makes state workflows very much like real live. After all how often are we not faced with issues that are not supposed to happen in the normal flow of things?

A SequentialWorkflow is a structured form of workflow where the possible sequence of things happening is for the most part defined in the workflow itself at design time. This type of workflow of usually best suited for very structured workflows like a number of computer systems talking to each other. Possibly after a user has determined the required criteria and committed to them.

The SetStateActivity can be used in state machine workflows only.

SqlTrackingQuery provides methods and properties that you can use in order to access certain kinds of tracking data stored in a SQL database by the SqlTrackingService. Access to this data is provided through SqlTrackingWorkflowInstance objects. You can call TryGetWorkflow to try to get a SqlTrackingWorkflowInstance for a specific workflow instance. You can call GetWorkflows to get a collection of SqlTrackingWorkflowInstance objects that correspond workflow instances that have tracking data that matches a set of query parameters contained in a SqlTrackingQueryOptions that is passed as a parameter to the method. See the SqlTrackingWorkflowInstance class for more information about the kind of tracking data available and see the SqlTrackingQueryOptions class for more information about the kind of queries that can be performed.

Workflow instances can contain timers, for example, if they have a DelayActivity. For workflows that contain timers, the SqlWorkflowPersistenceService records the time when the workflow's next timer will expire. The SqlWorkflowPersistenceService periodically polls the database, looking for workflows whose timers have expired. The frequency of the polling interval can be set using the SqlWorkflowPersistenceService constructor or via a configuration file.

The StateMachineWorkflowActivity is an activity container used to create workflows that follow a state machine model.

StateMachineWorkflowActivity activities that never complete are especially useful in processing long running business transactions. Consider a purchase order received by a supplier. The fact that the purchase order was fulfilled does not mean that the purchase order process is over. The goods that are part of the purchase order might be returned or the purchase order might be amended and have additional items added to it after the fulfillment. Sometimes there might be a requirement to keep the purchase order records for an extended period of time for legal or other purposes. The fact that a workflow does not finish just means that the workflow remains in an unloaded state. There may be a case for retiring the workflows, which means that after a set period of time the workflow instance may be forced to shut down.

WindowsWorkflowFoundation is basically a library consisting of an execution engine, a rules engine, a number of activities, a number of supporting runtime services and a designer allowing developers to design their workflows graphical in VisualStudio2005 (VS2005). In fact it even includes a graphical debugger allowing the developer to step through the workflow and even into the underlying .NET code. The engine is designed in such a way that the developer has a free choice between building the workflow as code constructs or in a declarative fashion using XAML. Either way he can use the graphical designer the same way, all that changes is the output. Because the runtime engine has the capability of parsing and executing the XAML itself we have tremendous flexibility in our workflows. There is no need to compile them at the same time as the rest of the application. This flexibility even goes further and the engine allows for the runtime alteration of the executing workflow, how about that for flexibility!

A workflow instance is considered Aborted when the WorkflowRuntime engine throws away the in-memory instance. This is done by calling WorkflowInstance.Abort. Aborted workflow instances can be resumed from their last persistence point by calling WorkflowInstance.Resume. Aborting workflows is only valid when there is a persistence service. Aborting workflows is used in extreme situations where applications decide to discard all the work that is done from the last persistence point till abort is called.

See RuntimeModificationOfWorkflows for an example of how to use this function.

• WorkflowsAndReflection
Using reflection to load workflows.
23-11-2009 15:33:20 - MauriceDeBeijer-80.126.16.139

Each WorkflowRuntime is hosted in a WorkflowRuntimeHost. This WorkflowRuntimeHost adds a number of WorkflowServices to the WorkflowRuntime enabling Activities to communicate with the outside world.

The WorkflowRuntime provides a number of services, all derived from WorkflowRuntimeService, for the executing Workflows:

• WorkflowSchedulerService
Workflow Scheduler Services manage how workflow instances are scheduled by the workflow runtime engine.
23-11-2009 15:33:20 - -80.126.16.139

• WorkflowStarted
Click to read this topic
23-11-2009 15:33:24 - -79.130.222.239

• WorkflowSuspended
add a one or paragraph summary or description of what's discussed here; put yours after 'Summary:'
23-11-2009 15:33:25 - 80.126.236.224

Using reflection to dynamically load an assembly and its workflows and execute them. If the assembly is not in the application path there is a risk that the WorkflowRuntime cannot load and execute all activities in the Workflow. So far the exact circumstances are unknown but activities contained in the WhileActivity, and probably other activities with SpawnedContexts, can cause problems.

Workflow Scheduler Services manage how workflow instances are scheduled by the workflow runtime engine, whether they are handled in an asynchronous or a manual synchronous mode. WF provides two out-of-box implementations for the WorkflowSchedulerService: DefaultWorkflowSchedulerService and ManualWorkflowSchedulerService.

The WorkflowServiceHost loads the workflow definition at the moment it starts listening for incoming requests. This workflow defintion is cached so if you are using XOML based workflows and change the XOML you will need to restart the hosting service to activate the new XOML. The reason for this is that the WCF interface defintion can be part of the workflow itself so changing the workflow could actually mean changing the public interface the WorkflowServiceHost is exposing.

http://msdn2.microsoft.com/en-us/library/system.servicemodel.workflowservicehost.aspx

The WF runtime engine requires a workflow transaction service. By default, it uses the DefaultWorkflowCommitWorkBatchService. The host application can choose to replace the DefaultWorkflowSchedulerService with SharedConnectionDefaultWorkflowCommitWorkBatchService or with a custom service.

Long running wokflows can be persisted to a store when idle and reloaded at a later date to continue the process. However the persisted workflow is bound to the exact type in the assembly. This means that replacing an assembly with a newer version can cause dehydrated workflows to become invalid and stop them from continuing. The solution is to keep all versions of the assemblies around for as long as there are active workflows referring to them.

If you need to migrate the existing workflows to the new model the best options seems to be to use DynamicWorkflows.

workflows.CookieContainer = New CookieContainer()

        Dim workflows As New workflows.Workflow1_WebService

        workflows.CookieContainer = New CookieContainer()

        workflows.Submit("Holiday", 1000.0)

        cookie = workflows.CookieContainer.GetCookies(New Uri(workflows.Url))(0)

        Dim workflows As workflows.Workflow1_WebService

        workflows = New workflows.Workflow1_WebService

        workflows.CookieContainer = New CookieContainer()

        workflows.CookieContainer.Add(cookie)

        Console.WriteLine(workflows.GetStatus())

XAML base workflows can either be loaded directly into the WorkflowRuntime CreateWorkflow function or they can be compiled using wfc.exe or the WorkflowCompiler class. If the root node has a x:Class attribute the XAML must be compiled before it can be used.

When you are using XAML based workflows with code beside you cannot use XAML activation. Instead you need to compile the XAML and code using the workflow compiler and use the type when activating the workflow. XAML activation can be used only with pure XAML workflows, ie workflows that only contain activities and do not add properties of any code.

The XML language used for workflows is actually the XAML language. Because applications bind to specific file extensions and there is a distinct difference in what you can do with WorkflowFoundation XAML versus PresentationFoundation XAML the decision was made to use XOML as the file extension for XML based workflows.

When using code based workflows with DeclarativeRules you can use an expression like: