Windows Workflow Foundation

Agenda What is Workflow? Workflow Types Fundamentals of Workflows Activities Custom Activities Types of Activities Workflow Framework How to Use Windows Workflow Foundation Windows Workflow and XAML Architecture Diagram Windows Workflow Runtime Hosting the Windows Workflow Runtime Runtime Services Creating Workflow-Enabled Services Modify Running Workflows WF in perspective of .NET 3.5 Summary Demos

What is Workflow? A workflow is the series of steps, decisions, and rules needed to complete a specific task. Example  Order food at the local pizza shop  Tell the cashier the type of pizza you want  The cashier passes this information to the cook  Who gathers ingredients and puts a pizza in the oven  The cook hands a finished pizza to the cashier  Who collects payment and completes the workflow by handing over your pizza The work flows , to the cashier, then to the cook, and then back again. * Programming Windows Workflow Foundation Practical WF Techniques and Examples using XAML and C#

Workflow Types Three types of workflows Sequential Workflows State Machine Workflows Rules-Driven Workflows

Workflow Types (contd) Sequential Workflow It progresses from one stage to next and cannot step back. Example: Flow Chart Based. State Machine Workflow It progresses from “State” to “State” and are more complex and can return to the previous point. Rules-Driven Workflow Implemented based on Sequential workflow. The rules dictate the progress of the workflow.

Activities Activities are the building blocks of workflows. All steps within a workflow are performed by executing an activity. All activities in WF derive from an Activity base class Activities define some common operations like “Execute” and “Cancel” Activities define some common properties like “Name” and “Parent”. Activities define some common events like “Executing” and “Closed”. Primitive activities in the library provides a foundation to build upon. Includes control flow operations like IfElseActivity, WhileActivity. Also includes activities to wait for events, to invoke Web Services, to execute a rules engine etc

Custom Activities Allows developers to extend the functionality of base activity library by creating custom activities to solve problems in their specific domain. All custom activities will also ultimately derive from the base Activity class The workflow engine makes no special distinction between activities written by Microsoft and custom activities written by third parties Example Pizza Order Case: “SendOrderToKitchen” or “NotifyCustomer” etc

Types of Activities Two types of activities Sequence Activities Event-Driven Activities

Sequence Activities A sequential workflow completes one activity and moves to the next, executing a sequence of consecutive steps. The “SequentialWorkflowActivity” class derives from the “SequenceActivity” class, which in turn derives from the CompositeActivity class. The “CompositeActivity” class provides the logic for an activity to contain one or more child activities. A sequential workflow will typically contain multiple children, and sequence activity provides the logic to execute child activities.

Sequence Activities (contd) The Sequence Activity iterates through its children in a forward-only direction, executing each child once and then moving to the next child. When the last child activity is complete, the sequence is finished. This doesn't mean a sequential activity cannot loop or branch, but it does mean execution always moves forward. There is no mechanism available to jump back to an arbitrary activity in the workflow.

Event-Driven Activities A state machine workflow is an event-driven workflow. The state machine workflow relies on external events to drive the workflow to completion. What is a State Machine? Elaborate in the Diagram shown below

Event-Driven Activities (contd) A transition moves the state machine to the next state. A transition can only occur in response to an event. Transitions don't have to move the state machine to a new state—a transition could loop back to the same state Each state can be activated after a predefined action has taken place; then, the engine executes the activities needed and stops after completion of the next state. There is no deterministic execution path between the steps because the Workflow does not execute in a chronological order

Workflow Framework WF is an extensible framework to deal with workflows in applications of any type. It is a set of classes and design tools that help you create and develop workflows into your applications. Just as the System.Windows namespace helps you create windows applications, the System.Workflow namespace will help you create workflows WF provides the base workflow classes for Sequential Workflows and State Machine Workflows

How to Use Windows Workflow Foundation Microsoft Visual Studio 2005 Extensions for Windows Workflow. Where as in Microsoft Visual Studio 2008 it is built in.

Windows Workflow and XAML eXtensible Application Markup Language (XAML, Pronounced as Zammel) XAML file are the valid XML files. It brings a declarative programming model to Windows Workflow. Designer can read/write XAML. XAML is not a technology specific to Windows Workflow, it also present in WPF, which declaratively constructs a rich user interface consisting of not only buttons and labels, but also animation storyboards etc

Architecture Diagram (contd) Top Layer At the top of the model is the location where developers build the code to run a workflow. This layer provides the out-the-box Activities, the model for the construction of custom Activities, and the engine to build rules. Middle Layer The Runtime layer ensures the execution aspects of the workflow and contains the mission-critical services required: for example, the state management and persistence service, the rules service that provides policy execution functionality, the scheduler service, and the tracking service. Bottom Layer The Hosting layer is the connecting link between the Workflow Foundation and the outside world and provides a package of services (Persistence, Timer, Tracking, Communication) needed to guarantee the control and management of the workflow.

Windows Workflow Runtime View the workflow activities as instructions, or opcodes, for a workflow processor to execute. In Windows Workflow, the processor is in the WF runtime. Workflow runtime provides common facilities for running and managing the workflows and can be hosted in any CLR application domain, be it a Windows Service, a Console, GUI or Web Application.

Hosting the Windows Workflow Runtime WF lives inside a handful of assemblies like System.Windows.Workflow.Runtime Like ASP.Net Runtime, the WF needs a host process to load, initialize and start its runtime before anything interesting can happen. WF will be useful in a variety of different hosts. We can host WF in a smart client application, a console application, or a Windows service, for instance.

Hosting the Windows Workflow Runtime (contd) Example  Create Instance of WorkflowRuntime  Calling Start() method of Runtime  Create the Worflow Instance  Executing the Workflow Instance Start( ) method  Worflow Completed then the Workflow Runtime fire Workflow Completed Event.

Hosting the Windows Workflow Runtime (contd)

Runtime Services WF assemblies provide important services to the workflow runtime. AddService allows us to make one or more services available to the runtime There are different types of Runtime Services are available Scheduling Service Transaction Service Persistence Service Tracking Service

Scheduling Service A scheduling service controls threads the runtime needs to execute workflows. The threads are separate from the host application because the workflows do not block any application thread and executes asynchronously. We can control the maximum number of workflows that runs simultaneously. Two types of scheduling services DefaultWorkflowSchedulerService  Asynchronously ManualWorkflowSchedulerService  Synchronously

Scheduling Service (contd) The “ DefaultWorkflowSchedulerService ” creates new threads to execute workflows. The “ ManualWorkflowSchedulerService ” is available when the host application is willing to donate threads to the workflow runtime. Denoating a thread to the Runtime is useful technique in server‑side applications, like ASP.NET web applications and web services. The ManualWorkflowSchedulerService forces the workflow instance to be run on the host instances thread so the host application is blocked until the workflow instance completes or becomes idle. This method is recommended when it is important to conserve the .Net thread pool, specifically when a workflow is instantiated by ASP.Net.

Transaction Service The purpose of the transaction service it to enable custom logic regarding the commitments of work batches (also known as Persistent Points) DefaultWorkflowCommitWorkBatchService. SharedConnectionWorkflowCommitWorkBatchService. Both “DefaultWorkflowTransactionService” and “SharedConnectionWorkflowTransactionService” inherit from “ WorkflowTransactionService ” which is the base transaction service class

Persistence Service This service saves the current state of the workflow. In workflows if state is not saved then user will lost the data and workflows would be terminated while in process. It is desirable to unload the process from the memory so that the resources are not held. It restarts the process from the same state getting from the persistence store from where it is saved. Example: user approval process is accomplished and workflow restarts from the persistent state.

Persistence Service (contd) It is useful in those scenarios where the activity may take long time getting a response, like waiting for an approval from a user. Default Runtime Service supplied with WF is “SQLStatePersistenceService”. The state is store in the SQL DB. If you are going to use this service you need to create the database and run the scripts mentioned below. SQLPersistenceService_Schema.sql SQLPersistenceService_Logic.sql It can be available at the following path “<windows>\Microsoft.Net\Framework\v3.0\Windows Workflow Foundation\SQL\EN”

Persistence Service (contd) The persistence service can be added to the runtime instance in two ways. Programmatically using code WorkflowRuntime workflowRuntime = new WorkflowRuntime(); SqlStatePersistenceService stateservice = new SqlStatePersistenceService("Data Source=localhost;Initial Catalog=WFState;Integrated Security=True"); workflowRuntime.AddService(stateservice); Using a section in App.config <WorkflowRuntime Name="SampleApplication" UnloadOnIdle="true"> <Services> <add type="System.Workflow.Runtime.Hosting.SqlStatePersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" ConnectionString="Data Source=localhost;Initial Catalog=WFState;Integrated Security=True;" /> </Services> </WorkflowRuntime>

Persistence Service (contd) There are different attributes that can be defined are OwnershipTimeoutSeconds  Loading instance for the specified period of time UnloadOnIdle  True means persist the workflow and unload it from memory LoadIntervalSconds  How frequently check for expired timers in workflow EnableRetries  True tells the service to retry persisting a workflow if it fails

Tracking Service This service is used to track the activity in the running workflows. A tracking service uses a tracking profile to filter the information it receives about a workflow The WF runtime can send information about workflow events, activity state changes, rule evaluations, and our own custom instrumentation data. The tracking service decides what it will do with the data it receives. The service could write tracking data to a log file, or save the data in a database. The tracking service can participate in transactions with the workflow runtime to ensure the information it records is consistent and durable. Provides things like when the workflow begins execution, when it ends, when each activity within the workflow is entered and exited.

Tracking Service (contd) The runtime sends three types of events to the tracking service. Workflow events Activity events User events

Tracking Service (contd) Workflow Events Workflow events describe the life cycle of the workflow instance. Created , Completed , Idle , Suspended , Resumed , Persisted , Unloaded , Loaded , Exception , Terminated , Aborted , Changed , and Started. Activity Events Activity events describe the life cycle of an individual activity instance. Activity-execution status events include Executing , Closed , Compensating , Faulting , and Canceling. User Tracking Events When creating the business logic for an activity, the activity author might want to track some business- or workflow-specific data. This can be achieved by calling any of the overloaded Activity.TrackData methods. The data tracked in this manner is sent to the tracking service as a User Tracking Event

Tracking Service (contd) Tracking information sounds like a useful feature for system administrators who want to analyze resource usage, but there are also tremendous business scenarios for tracking information, like record tracking number of open/closed invoices etc. Default tracking service provided by WF is “SQLTrackingService”. It requires a SQL database. If you are going to use this you need to create a database in SQL Server and run the specified scripts mentioned below Tracking_Schema.sql Tracking_Logic.sql It can be available at the following path “<windows>\Microsoft.Net\Framework\v3.0\Windows Workflow Foundation\SQL\EN”

Creating Workflow-Enabled Services In .NET 3.5 you can use WF and WCF together to create workflow-enabled services. This combination depends on two new WF activities. Send: Sends a request via WCF, then optionally waits for a response. A developer specifies the operation that should be invoked and the endpoint that at which that operation can be found. Receive: Receives an incoming request via WCF, then sends a response. The developer specifies just the operation that accept this incoming request. Receive is a composite activity. This activity can be used to cause a running workflow to wait for an incoming request, or a workflow that begins with a Receive activity can have a new instance created when a request arrives.

Modify Running Workflows Human workflow requires the ability to make changes on the fly. To allow this , WF include “ dynamic update ”. Using this a running instance of any workflow can be modified within safe, well-defined boundaries specified by its creator, then potentially save as a new workflow. A new activity can be inserted into the workflow. Or a rule condition changed for an IfElse or CAG activity.

WF in perspective of .NET 3.5 Basically a Model Driven Service Oriented Application. Model Driven means, creating a process model using workflows as the medium for creating those models Service Oriented means, you are exposing all the components of your application as service which are talking to each other using messages and services as the underline layer.

Summary Windows Workflow allows you to organize a set of activities into a workflow. Workflows can be sequential or state machines. You can create your own custom activities. Workflows can be hosted in a variety of host applications The Architecture of the Window Workflow Foundation. Four types of Runtime services provided to workflows. Workflow can make the application faster to build, quicker to change and easier to customize.

Windows Workflow Foundation

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to Windows Workflow Foundation (20)

More from Usman Zafar Malik (9)

Recently uploaded (20)

Windows Workflow Foundation

Editor's Notes