Wwf

Windows Workflow Foundation Ch. Vishwa Mohan Freelance Software Consultant & Corporate Trainer

Table of Contents Introduction to Workflow Foundation Workflow Activities Workflows & Workflow Runtime Building Sequential Workflows Communication with the Host Custom Activities State Machine Workflows Using Transactions Web Services and Workflows WCF Services and Workflows Policies and Rule Sets Updating Workflows Dynamically Windows Workflow Foundation Services Embedding the Workflow Designer

Introduction to Workflow Foundation

WWF Overview Windows Workflow Foundation (WWF) is the programming model, engine, and tools for quickly building workflow-enabled applications on Windows. Workflow provides a model where you can define and execute processes using a set of building blocks called activities . Some of the scenarios of Windows Workflow Foundation includes: Enabling work-flow within the line of business applications. User-interface page flows. Document-centric workflow. Human workflows. Composite workflows for Service-oriented applications. Business rule-driven workflows. Workflow for systems management. WWF provides a consistent and familiar development experience. The WWF API provides fully support for VB.NET and C#. A specialized workflow compiler and debugger to debug within workflow. A graphical workflow designer. Facility to develop your workflow completely in code or in markup. Windows Workflow Foundation is a framework , not a language . It is cable to correctly handle persistence and compensation .

Workflow Overview A workflow is a set of elemental units called activities that are stored as a model that describes real-world processes. Workflows provides a way of describing the order of execution and dependent relationships between pieces of short-or long running work. Here activities might be executed by people or by system functions. Every running workflow instance is created and maintained by an in-process runtime engine referred to as the Workflow Runtime Engine . There can be several workflow runtime engines within an application domain . Also each instance of the runtime engine can support multiple workflow instances running concurrently. ( Here workflow runtime deals scheduling these instances ). When a workflow model is compiled, it can be executed inside any windows process includes: ( Because a workflow hosted in a process ). Console application. Windows Forms based applications. Windows Services. ASP.NET Web Sites ASP.NET Web Services. A workflow can easily communicate with its host application.

Host Process Windows Workflow Foundation Runtime Engine A Workflow An Activity Runtime Services Base Activity Library Custom Activity Library Visual Designer WWF Architecture Key Concepts: Workflows are set of activities . Workflows run within a HostProcess . Developers can build their own custom activity libraries . Components: Base Activity Library : Out-of-box activities and base for custom activities. Runtime Engine : Workflow execution and State management Runtime Services : Hosting flexibility and communication. Visual Designer : Graphical and code based construction.

What is an Activity ? Activities are the elemental unit of a workflow. An activity can perform a single action ( Eg: Writing a value to DB or sending an email ) or it can be a composite activity and consists of set of activities. Activities have two types of behavior: Runtime : It specifies the actions upon execution. Design Time : It controls the appearance of the activity and its interaction while being displayed within the designer. Activities are executed according to given flow path . When all the activities are finished running, the working flow instance is completed its execution. WWF framework consists a library of in-built activities also provides the mechanism for you to create your own activities; so it enables extensibility & reusability between workflows. Some of the framework in-built activities are: CallExternalMethodActivity IfElseActivity, IfElseBranchActivity CodeActivity FaultHandlersActivity, etc…,

Workflow Rules & Conditions WWF can implement business logic as either rule or conditions . Conditions are used by one of the following activities to control activity execution. IfElseBranchActivity ConditionedActivityGroup WhileActivity ReplicatorActivity Here conditions are expressed as declarative or defined in code . Declarative conditions are created as code DOM statements in the “ .rules” file. Code-based conditions reference a method in the workflow’s code file that returns its result through Result property. Rules , like conditions , are expressed as code DOM statements, and are collected in the rules XML file. Here Rules include a condition statement and collection of actions which are performed based on the Result of the conditions. Rules are collected into rule sets , which support both simple sequential execution of rules , and sophisticated forward-chaining of rules . Rule sets are executed by the PolicyActivity activity.

Fault Handling Exceptions that occur in activities are handled asynchronously by workflow runtime engine in a process called fault handling . Exceptions are scheduled in a queue to be handled later. If the exception type matches the one that is handled by a particular FaultHandlerActivity activity, that activity will handle the exception. All the unhandled exceptions is bubbled up through parent activities until it ultimately causes the termination of workflow instance.

Building Host to Run Workflows The WWF runtime engine is responsible for creating and maintaining running workflow instances. The runtime engine will be executed inside a host process . The default mechanism for initializing WWF is to use the WorkflowRuntime class. WorkflowRuntime wfRuntime = new WorkflowRuntime( ); Once runtime instance is created you can subscribe for events those are raised by runtime engine also can configure any services used by runtime engine. wfRuntime. WorkflowCompleted += OnWorkflowCompleted; wfRuntime. WorkflowTerminated += OnWorkflowTerminated; //Now add the services used by runtime. wfRuntime. AddService (new SqlTrackingService(conn)): Finally, create and start workflow instance. WorkflowInstance instance = wfRuntime. CreateWorkflow (typeof(MyWorkflow)); instance. Start() ; To remove the service from runtime you can use RemoveSerice() method. Make sure runtime service is stopped ( i.e., not executing ). runtime. RemoveService (SqlTrackingService);

Creating Workflow By Code To create a Workflow programmatically as follows: Create a console application in Visual Studio. Add the following libraries to references of your project. System.Workflow.Activities System.Workflow.ComponentModel System.Workflow.Runtime Add a class file to your project and name the file as HelloWorld.cs . Now name the class name as HelloWorld and derived it from SequentialWorkflowActivity . class HelloWorld : SequentialWorkflowActivity { } In this class, declare a private variable of type CodeActivity . private CodeActivity helloWorldActivity; Now define a public constructor in this class and initialize CodeActivity instance in this constructor also associate code handler and add it to workflow. this.helloWorldActivity = new System.Workflow.Activities. CodeActivity (); this.helloWorldActivity. Name = "HelloWorldActivity"; this.helloWorldActivity. ExecuteCode += new EventHandler(this. My HelloWorld); Finally implement the MyHelloWorld event handler in your class: private void My HelloWorld(object sender, EventArgs e) { } The complete code inside your workflow class Constructor is : this. CanModifyActivities = true ; this. Name = "MyHelloWorldWorkflow"; this.helloWorldActivity = new System.Workflow.Activities. CodeActivity (); this.helloWorldActivity. Name = "HelloWorldActivity"; this.helloWorldActivity. ExecuteCode += ne w EventHandler(this.HelloWorld); this.Activities. Add (this. helloWorldActivity ); this. CanModifyActivities = false ;

Creating Workflow By Code The next step in creating and executing workflow is load your workflow by workflow runtime and execute it. In your project Program.cs file, within the main function create instance of WorkflowRuntime and create workflow instance as follow: using ( WorkflowRuntime workflowRuntime = new WorkflowRuntime () ) { AutoResetEvent waitHandle = new AutoResetEvent ( false ); workflowRuntime. WorkflowCompleted += delegate(object sender, WorkflowCompletedEventArgs e) { waitHandle.Set(); }; WorkflowInstance instance = workflowRuntime. CreateWorkflow (typeof(HelloWorldApp.HelloWorld)); instance. Start (); waitHandle.WaitOne(); }

Creating Workflow By Markup In addition to programmatically developing workflow, WWF also allows declarative way to create workflows by using XAML . These markup files can be compiled into a workflow type and loaded directly into the workflow runtime engine at runtime. In addition they can also be compiled into a workflow type with code-behind files. You can also use rules & rule conditions in markup. With the help of this markup language, in addition to creating workflows, you can also persist workflows by using WorkflowPersistanceService . When programmatic workflows are serialized with the WorkflowMarkupSerializer , they become workflow markup.

Creating Workflow By Markup The basic structure of the workflow markup contains the root node , followed by the child activities in that workflow as nested sub elements. Here root node represents the type of workflow (Eg: Sequential, State Machine). Each element in the workflow is represented as nodes of either composite activities or the workflow itself. Each element in a workflow markup file corresponds to a workflow component. XAML also provides the ability to insert procedural code within a workflow markup using the x:Code directive element. ( Code must be in CDATA section). If you use custom activities in your workflow markup code, then you need to reference the custom activity assembly in markup code as follows: < SequentialWorkflowActivity x: Class ="XAMLWorkflow.Workflow1" x: Name ="Workflow1" xmlns:ns0="Assembly=CustomActivityAssembly”> <ns0: CustomActivity x: Name ="CustomActivity1"/> </ SequentialWorkflowActivity > To start workflow instance from markup file create XmlReader object contain markup file and pass it to CreateWorkflow() method of WorkflowRuntime . Finally call Start() method on WorkflowInstance object. The IfElseActivity is represented in markup by the <IfElseActivity> element. Example of code in markup file: < CodeActivity x:Name="codeActivity1“ ExecuteCode=“MyMethod"> <x:Code><![ CDATA [ void MyMethod(object sender, EventArgs e) { } ]]></x:Code> </ CodeActivity >

Introduction to Activities Everything in a workflow is an activity . In WWF the activity is just a class that ultimately derived from the Activity class. Activity class defines a number of overridable methods (Eg: Cancel , Dispose, HandleFault, Execute ) and the most important of these methods is the Execute() . override ActivityExecutionStatus Execute ( ActivityExecutionContext context ) { return ActivityExecutionStatus.Closed ; } When the runtime schedules the activity for execution, the Execute() method is ultimately called. ( Here you can write your custom code ). The Execute() method return type is ActivityExeuctionStatus ( AES ). This enumeration values represents the status of activity instance within workflow instance. The possible values of ActivityExecutionStatus enumeration are: Initializing Executing Canceling Closed Compensating Faulting These values used by runtime to determine whether the activity has completed successfully, is still processing or one of the other possible states.

Activities Types There are two main types of Activities: Simple Activities : Activities those are derived from Activity class can be thought of as callable functions ( i.e., Execute , Cancel, etc.,) from the workflow. Composite Activities : Activities that are derived from CompositeActivity class. These activities are container for other activities. These activities design time behavior is considerable different from Simple activities. ( Eg: ParallelActivity, IfElseActivity, ListenActivity ). Like workflow, an activity can be sequential or it can be event-driven .

Predefined Activities The WWF framework provides several predefined activities. These activities provides functionality for control flow, conditions, event handling, state management and communication with application and services. All these activities are defined in System.Workflow.Activities namespace. The naming conversions for activities is to append Activity to activity name. The below is a list of WWF defined in built activities listed alphabetical order: CallExternalMethodActivity CancellationHandlerActivity CodeActivity CompensatableSequenceActivity CompensatableTransactionScopeActivity CompensateActivity CompensationHandlerActivity ConditionedActivityGroup DelayActivity

Predefined Activities The below is a list of WWF defined in built activities listed alphabetical order: EventDrivenActivity EventHandlersActivity EventHandlingScopeActivity FaultHandlerActivity FaultHandlersActivity HandleExternalEventActivity IfElseActivity, IfElseBrachActivity InvokeWebServiceActivity InvokeWorkflowActivity ListenActivity ParallelActivity PolicyActivity ReplicatorActivity

Predefined Activities The below is a list of WWF defined in built activities listed alphabetical order: SequenceActivity SetStateActivity StateActivity StateFinalizationActivity StateInitializationActivity SuspendActivity SynchronizationScopeActivity TerminateActivity ThrowActivity TransactionScopeActivity WebServiceFaultActivity WebServiceInputActivity WebServiceOutputActivity WhileActivity

Activity Execution Model An activity may go through six different states it its lifetime: An activity goes to initialized state when the Workflow runtime calls the activities Initialize() method. AEC created here. Next runtime calls the Exeucte() method of activity. Here your activity enters into Executing state. Primary functionality performed here at this stage. It can return any one of the values of AES enumerator. An activity is put into the Canceling state by a parent activity explicitly, or because an exception in executing activity. The Closed state is the last and final state of an activity . From Closed states if your business logic demands it can goes to Compensating sate and return back to Closed state. If an exception is thrown during executing, compensating and canceling state then transmit to Faulting state. An activity can’t move from Closed state to Executing state. An activity may only close when all children activities are either in their Closed or Initialized states.

Activity Execution Context Every activity has an activity execution context that represents the execution environment of the activity. An ActivityExecutionContext (AEC) is the execution environment that is created for an activity when the host application calls the Start() method. The ActivityExecutionContext (AEC) provides a composite activity with the ability to execute ( ExecuteActivity() ) or Cancel ( CancelActivity() ) a child activity. It can also close itself through the CloseActivity() method. Remaining all other activity states are controlled by the workflow runtime. The AEC has a property called ExecutionContextManager that enables it to generate new AECs. These AECs are generated every time a parent activity, such as a WhileActivity , ReplicatorActivity , or ConditionedActivityGroup activity, runs its child activities more than once. Certain composite activities, such as ReplicatorActivity , WhileActivity activities, create multiple instances of their child activities during execution, and each child activity has its own execution context that it runs in. Every activity also transitions through various states during its lifetime. Some transitions are controlled by the workflow runtime engine , while others can be user controlled.

Activity Properties There are two types of activity properties: Meta Properties: These properties are immutable at runtime, so the properties must be set to a literal value at design time. (Eg: Name property of Activity). Instance Properties: These properties can be set at design time, or the property can be bound to instance data. ( Eg: Error string on a SuspendActivity ). If the property is bound to instance data, in which case the actual value is not determined until runtime. These properties can also be modified directly during workflow execution. The dependency properties provide a centralized repository of a workflow's state. It is basically a hash table. An attached property is one the property is defined in one class/activity but used on another activity or class. These properties are specialized form of dependency properties . Here you need to register the property. To register an attached property you can use RegisterAttached() method of the DependencyProperty class.

Activity Companion Classes Activity also have companion classes: The additional features are added to activities via attributes . [ ToolboxItem (typeof(ActivityToolboxItem))] [ Designer (typeof(MyDesigner))] p ublic partial class MyActivity : Activity { } Activity Designer Validator CodeGenerator Serializer

Workflows You can write workflows directly in code , in markup or combination of both . WWF enables model-driven workflow development , providing natural design visibility and hiding system-level concerns such as transactions , state management , and concurrency control . The two primary facets of programming workflows: Designing workflows and their activities. Using workflows in your application. A Workflow is simply a list of activities . Each workflow instance is uniquely identified by its InstanceId property. This is a GUID and that can be assigned by the runtime. The class responsible for executing workflow is the WorkflowRuntime class. You can access your specific workflow from the runtime by using the GetWorkFlow( guid ) method of the WorkflowRuntime Class. There are two types of Workflows available in WF. Sequential Workflows State Machine Workflows Data-driven Workflows Workflow itself is just another type of activity.

Workflow Runtime A Workflow doesn’t exists on its own. A workflow is always executed within the context of workflow runtime . This runtime support is available by instantiating the WorkflowRuntime class. The workflow runtime contains methods to construct instances of workflows. There are six various CreateWorkflow() methods used to construct the workflow instances, These methods returns the workflow instance object. In addition runtime also contains methods for reloading a workflow instance and enumerating all running instances. To start running your workflow, you need to call Start() method from the returned WorkflowInstance object. Because sequential workflow doesn’t rely on an external event to run, it begins immediately. The workflow runtime also supports number of events that are raised while workflows are executing. The events are: WorkflowCreated : Raised when new workflow instance is constructed. WorkflowIdled : Raised when a workflow is awaiting input. WorkflowCompleted: This event is raised when the workflow has finished.

Events Raised by WWF Runtime The following table lists the events that can be raised by the Workflow runtime engine that pertain to the workflow runtime engine itself are: ServicesExceptionNotHandled Started Stopped The following events are the workflow instance events that can be raised by the workflow runtime engine . WorkflowAborted WorkflowCompleted WorkflowCreated WorkflowIdled WorkflowLoaded WorkflowPersisted WorkflowResumed WorkflowStarted WorkflowSuspended WorkflowTerminated WorkflowUnloaded

Passing Parameters to Workflow Passing parameters to workflow is some what different. To pass parameters by storing them in a dictionary of name-value pairs and when you construct workflow you pass through this dictionary. Dictionary <string, object> parms = new Dictionary <string, object>(); params . Add (“OrderID”, 12345); WorkflowInstance myWorkflow = wfRuntime. CreateWorkflow (typeof( MyWorkflow ), parms ); In name-value pair, the name should match to any one of the public property of workflow. When the name doesn’t correspond to any one of public property on the workflow, then an exception will be thrown. Once parameters passed to workflow you need to link these parameters to activities . The process of linking is called binding . A bindable property is displayed in the property grid within Visual Studio. By double-clicking on the bind icon on this property grid display a dialog box allows you to select an appropriate property to link to this property.

Returning Result from Workflow When a workflow finishes its execution, the workflow runtime raises the WorkflowCompleted event. For this completed event handler the contextual information about the workflow is passed. It contains the data from that workflow. private void MyWorkflowCompleted(object sender, EventArgs e) { WorkflowCompletedEventArgs we = e as WorkflowCompletedEventArgs; KeyValuePair <string, object> parms = we. OutputParameters ; //By iterating params you will get the multiple return values from workflow. }

Characteristics of Workflow In workflows, Tracking is the ability to specify and capture information about workflow instances and store that information as the instances execute. WWF provides the SqlTrackingService , it stores the collected tracking information in SQL database. In addition you can also write your own tracking service also. When a new workflow is created, the tracking service requests a tracking channel to be associated with that workflow. All tracking information from the workflow is then sent to this tracking channel. The tracking service can track three types of events: Workflow Instance Events, Activity events User Events. In addition you can also configure type and amount of information that your service wants to receive for a particular workflow instance or type of workflow by providing a tracking profile .

Characteristics of Workflow Activities can be a compensatable activity. Compensation is the act of undoing any actions that were performed by a successfully completed compensatable activity because of an exception in a workflow. WWF framework simplifies the process of creating stateful, long-running , persistent workflow applications. The workflow runtime engine manages workflow execution and enables workflows to remain active for long periods of time and survive application restarts. This durability is the key tenet of WWF. Workflows, activities, and rules can be serialized and deserialized . The serialization enables the workflow in workflow markup files, and view their properties, fields , and events in a workflow designer. WWF provides default serialization capabilities for standard activities, or you can create your own serializer for custom activities. WWF enables you to dynamically update your workflow instance and declarative rules during runtime. Before activities are scheduled for execution, you can change expected behavior, flow control and so on.

Serialization in Workflow The WWF framework provides a serialization support that is used to serialize and deserialize workflows. WWF provides default serialization capabilities for standard activities, or you can create your own serializer for custom activities. By default, a workflow is serialized to workflow markup . Workflow markup is the serialized form of object hierarchies. With DesignerSerializer attribute; specify custom serializer to custom activity. WWF infrastructure provides the following classes to support serialization WorkflowMarkupSerializer ActivityMarkupSerializer CompositeActivityMarkupSerializer The serializers for activities or any other custom serializers for custom activities must inherit from WorkflowMarkupSerializer class. ActivityMarkupSerializer class inherits from WorkflowMarkupSerializer . This serializer is used to serialize all basic activities ( i.e., not composite activities ). CompositeActivityMarkupSerializer derived from ActivityMarkupSerializer class provides serialization for composite activities.

Services in Workflow The workflow runtime engine uses many services when a workflow instance runs. Some of the services the runtime engine uses are: Persistence Service Scheduling Service Transaction Service Tracking Service These service components are pluggable, which allows applications to provide these services in ways that are unique to their execution environment. In addition, Workflow provided services you can also create custom services to extend the workflow foundation platform by deriving from base service classes . Host processes can communicate with workflows by exchanging the data through custom local communication services . Local communication services implement user-defined interfaces that defines methods & events that will be passed between the workflow and the host process Host processes can also interact with a specific activity in a specific workflow instance by using a unique ID that is passed between the host process and the workflow as an event argument. This is known as correlation .

Workflow Performance Monitoring You can monitor workflow performance by using Performance ( Perfmon.exe ) on Windows XP or Vista. By using this performance monitor tool , you can configure performance counters to record performance data and set system alerts to notify you when a specified counter's value is above or below defined threshold. WWF provides a set of performance counters with the WWF performance object that you can use to track the performance of the workflow runtime as it executes workflow instances. Some of the performance counters are: Workflows Completed Workflows Created Workflows Created/sec Workflows Executing Workflows In Memory WWF performance counters are enabled by default. You can disable them by either setting the EnablePerformanceCounters attribute to false in a workflow configuration file, or changing it programmatically in the WorkflowRuntimeSection class property EnablePerformanceCounters . <?xml version="1.0"?> <configuration> <configSections> <section name=" CustomWorkflowRuntimeSettings " type=“xxx" /> </configSections> < CustomWorkflowRuntimeSettings Name="Workflow1" EnablePerformanceCounters ="false">  </CustomWorkflowRuntimeSettings> </configuration>

Workflow Configuration Files WWF host application can use configuration files to control the behavior of a WorkflowRuntime object. Within the configuration file crate a configuration section as shown below: <configuration> < configSections > < section name =“ MyWFRuntimeConfig " type ="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken 31bf3856ad364e35" /> </ configSections > </configuration> Your configuration file can contain multiple configuration sections only one section is used during instantiation of WorkflowRuntime. In this configuration, we are defining the services , when you create an instance of a WorkflowRuntime object these services are added to runtime. ( Next slide ) In addition to this configuration file we will add services programmatically also.

Workflow Configuration Files Once the configuration section has declared now add the configuration information section to your configuration file as shown below: < MyWFRuntimeConfig Name="SampleApplication"> < CommonParameters > <add type ="ConnectionString" type =“SQL Connstring values" /> </ CommonParameters > < Services > <add type ="DefaultWorkflowSchedulerService" maxQueuedWorkItems ="20"/> <add type ="SharedConnectionWorkflowTransactionService” /> <add type ="SqlWorkflowPersistenceService” UnloadOnIdle ="false"/> </ Services > </ MyWFRuntimeConfig > The CommonParameters element defines any parameters that are used globally across multiple services. In your host application, while creating runtime object pass name of the configuration section as a parameter to the WorkflowRuntime constructor. WorkflowRuntime runtime = new WorkflowRuntime(" MyWFRuntimeConfig ");

Enable Workflow Logging Using the configuration file, you can output WWF logging information: < system.diagnostics > <switches> <add name="System.Workflow LogToFile" value=“All" /> <add name="System.Workflow.Runtime" value="All" /> <add name="System.Workflow.Runtime.Hosting" value="All" /> <add name="System.Workflow.Runtime.Tracking" value="All" /> <add name="System.Workflow.Activities" value="All" /> <add name="System.Workflow.Activities.Rules" value="All" /> </switches> </ system.diagnostics > The first add node enables logging to a file. The file is created in your host application directory using the name WorkflowTrace.log . The other option is to enable logging to a TraceListener by setting the name parameter equal to " System.Workflow LogToTraceListener ".

Wwf

More Related Content

What's hot

Viewers also liked

Similar to Wwf

More from Vishwa Mohan

Recently uploaded

Wwf

Editor's Notes