Introduction to Windows Workflow Foundation technology (based on. NET Framework 4.5)

Introduction to Windows Workflow Foundation technology (based on. NET Framework 4.5)

Transferred from: http://www.cpiso.cn/jsyj/ghxx/2014/5/15/459.shtml

Microsoft Windows Workflow Foundation (WF) is an extensible framework for developing workflow solutions on the Windows platform. The Windows Workflow Foundation also provides APIs and tools for developing and executing workflow-based applications. Windows Workflow Foundation provides a single, unified model for creating end-to-end solutions that span multiple categories of applications, including human workflow and system workflow.
The Windows Workflow Foundation is a broad and common workflow framework that is designed for scalability from bottom to top and at every level. The Windows Workflow Foundation-based solution consists of interconnected components that are supported by Microsoft. NET code and run in the host application. Just like creating a Web page visually in a custom environment, you need to develop the steps for a specific workflow in the visual designer, and add code-behind workflow components to implement rules and define business processes.
The Windows Workflow Foundation has a strong advantage in building workflow processes.
1. The Windows Workflow Foundation provides a highly abstracted and visualized business processing model that can be easily used and understood, regardless of whether it is a developer or a business domain expert.
2. Windows Workflow Foundation can easily change the business processing rules associated with it and do not have to recompile.
3. The Windows Workflow Foundation programming model enables developers to build a set of testable kernel collections that can be used in multiple programs.
Windows Workflow Foundation is a program that specifically controls workflow, provides frameworks, models, workflow engines,. NET managed APIs, runtime services, and Microsoft Visual Studio for development workflows Integrated visual designers and debuggers that use Windows Workflow Foundation to build and execute workflows that span both client and server side, and that can be executed within all types of. NET applications.
The core of Windows Workflow Foundation is a set of activities activities, which are typically created in the host program. They run workflows through the workflow engine, manage the state of the workflow, and communicate with the workflow through the run-time service. A host program can be any type of program that, when developing a workflow project, first creates a workflow engine in the host program, then loads the various required services in the engine, and finally starts the specified workflow through the engine and generates an instance of the workflow.
The data exchange between the host program and the workflow is through the communication service, and the communication channel can be designed by itself, and some interfaces are defined so that the host program and some special Activity in Windows Workflow Foundation Activities use event-passing parameters to communicate and exchange data, as well as to communicate through external events and persistence. When a workflow instance runs, it can be accompanied by a number of services that are pluggable, that is, these services are designed to meet the needs of different workflow running instances, and thus accompany the instance to run.
The Load Workflow Persistence service (persistenceservice) moves the workflow instance out of the workflow engine, into the persistent media, and from the media to the workflow engine. The WorkflowPersistenceService class is a service that uses a database to persist workflow state, and the instance uses Unload mode to load the WorkflowPersistenceService service into the engine. When the memory of the instance is moved out and saved to the database, the engine uses the Getworkflow method, which can be loaded and returned by the WorkflowPersistenceService service to the instance that is stored in the database, and the instance uses the Load method to trigger the engine's WorkflowLoaded event.
Tracking workflow and its node state is a core feature of the workflow platform the Tracking service provided by Windows Workflow Foundation tracks the execution state of the workflow, and there are various state changes during the workflow execution Tracking These status change information can be logged to the database and a query port is provided. In addition, the loading of custom services is implemented in the encapsulation class, which is responsible for the startup of the workflow engine and the uniqueness of the workflow engine.
When developing a workflow system, the Windows Workflow Foundation makes program semantics more declarative and accurate, making it easy for users to model applications close to the actual process and embedding Windowsworkflow in the runtime server. The more complex the process, the simpler the process for designing and implementing it, the easier it is to change the process dynamically, and the less code the user needs to write and maintain. The Windows Workflow Foundation Runtime provides a managed execution environment for the workflow program, as well as duration, reliability, suspend/resume, transaction, and compensation characteristics for the program.
1 Overview of the WINDOWS workflow conceptual
1.1 WINDOWS Workflow Overview
A workflow is a model that uses activity as the base unit to describe the actual process. Workflows provide a way to describe the order of execution and dependencies between multiple short-run or long-running tasks. This work runs through the model from beginning to end, and activities can be performed manually or by system functions.
1.1.1 Workflow run-time engine
Each running workflow instance is created and maintained by the in-process runtime engine, and the host process interacts with it in the following three ways:
Workflowinvoker, which invokes the workflow as if it were a method.
Workflowapplication, which is used to explicitly control the execution of a single workflow instance.
WorkflowServiceHost, which is used for message-based interactions in multi-instance scenarios.
Each of these classes is packaged as an activity instance responsible for execution at the core activity runtime. Multiple active instance objects can be run concurrently in an application domain.
Each of the three host interaction objects above is created from the activity tree called the Workflow program. Custom hosts that use these types or are packaged for active instances can be in any of the console applications, form-based applications, Windows Services, ASP. NET sites, and Windows Communication Foundation (WCF) Services A workflow is executed within a Windows process.
Workflow components in the host process (Figure 1)

1.1.2 Interaction between Workflow components
Demonstrate how workflow components interact with each other (Figure 2)

In, the Workflowinvoker class of the Invoke () method is used to invoke several workflow instances. Workflowinvoker is used for lightweight workflows that do not need to be managed by the host, and workflows that need to be managed by the host, such as Bookmark recovery, must be executed using Run () instead. The next workflow instance is called without waiting for a workflow instance to complete, and the run-time engine supports running multiple workflow instances at the same time. The workflow called is as follows:
A Sequence activity that contains the WriteLine child activity. The parent activity of Variable is a child activity bound to inargument.
A custom activity that invokes ReadLine. Returns the outargument of the ReadLine activity to the Invoke invoke () method.
A custom activity derived from the CodeActivity abstract class. CodeActivity can access run-time features such as traces and properties using the Codeactivitycontext provided as arguments to the Execute (Codeactivitycontext) method.
1.2 WINDOWS Workflow Fundamentals Concept
1.2.1 Workflows and activities
A workflow is a structured collection of operations that make up a process model. Each action in the workflow is modeled as an activity. The host uses Workflowinvoker to invoke the workflow (as if it were a method), Workflowapplication is used to explicitly control the execution of a single workflow instance, and the WorkflowServiceHost Used for message-based interactions in multi-instance scenarios to enable interaction with the workflow. Because the steps of a workflow are defined as the hierarchy of activities, the topmost activity in the hierarchy can be thought of as defining the workflow itself. This hierarchy model replaces the explicit Sequentialworkflow and Statemachineworkflow classes in previous versions. The activity itself can be developed as a collection of other activities (using the activity class as the basis, typically with XAML definitions), or a custom creation using the CodeActivity or Nativeactivity class, which can use the runtime for data access. The latter exposes the workflow run-time scope to the active author. Activities developed using the CodeActivity and Nativeactivity classes are created using the CLR-compliant language, such as C #.
1.2.2 Activity Data Model
Activities use the types shown in the following table to store and share data. (table 1)

1.2.3 Workflow Runtime
The workflow runtime is the environment in which the workflow executes. Workflowinvoker This is the simplest way to execute a workflow. The host uses Workflowinvoker for the following operations:
1. Call the workflow synchronously.
2. Provide input to the workflow or retrieve output from it.
3. Add an extension for active use.
Activityinstance is a thread-safe proxy that the host can use to interact with the runtime. The host uses activityinstance for the following operations:
1. Get an instance by creating an instance or loading an instance from an instance store.
2, receive the instance lifecycle event notification.
3, control workflow execution.
4. Provide input to the workflow or retrieve output from it.
5. Sends a continuation signal to the workflow and passes the value to the workflow.
6. Save the workflow data.
7. Add an extension for active use.
An activity obtains permissions to access the workflow runtime environment, such as Nativeactivitycontext or Codeactivitycontext, by using the appropriate Activitycontext derived classes. These elements use this class to parse parameters and variables in order to schedule child activities and implement a variety of other purposes.
1.2.4 Service
Workflows provide a natural way to implement and access loosely coupled services using message activities. Message activity is built on WCF to complete the input and output of workflow data. You can group message activities together to model any message exchange pattern that you want.
1.2.5 Persistent, unloaded, and long-running workflows
Windows Workflow simplifies the process of authoring long-running reactive programs by providing the following features:
Access to external input activities.
Ability to create Bookmark objects that can be recovered by the host listener.
The ability to save the workflow data and unload the workflow, and then reload and reactivate the workflow as a response to restoring the Bookmark object in a particular workflow.
The workflow continues to execute the activity until there are no activities to be performed or all currently executing activities are waiting for input. In the latter case, the workflow is in an idle state. Typically the host unloads the workflow into an idle state and overloads it to continue execution when the message is received. WorkflowServiceHost provides functionality for this feature and provides a scalable uninstall policy. If you use mutable state data or other data that cannot be saved in an execution block, the activity can use Nopersisthandle to indicate to the host that it should not be saved. Workflows can also use the Persist activity to explicitly save their data to persistent storage media.
1.3 WINDOWS Workflow Architecture
Windows Workflow Foundation (WF) promotes the abstraction level of developing long-running interactive applications. The work unit is encapsulated as an activity. The active runtime environment provides functionality for flow control, exception handling, error propagation, state data saving, loading from memory, and unloading in-progress workflows, traces, and transaction flows.
1.3.1 Activity Architecture
Activities are developed as CLR types, either derived from activity, codeactivity or asynccodeactivity, or derived from a corresponding nativeactivity, Activity<tresult, that returns a value. >, codeactivity<tresult> asynccodeactivity<tresult> or nativeactivity<tresult> variants. By developing activities that derive from activity, users can combine pre-existing activities to quickly create units of work that are executed in a workflow environment. On the other hand, CodeActivity supports authoring execution logic in managed code by using Codeactivitycontext primarily for accessing activity parameters. Asynccodeactivity is similar to codeactivity except that it can be used to implement asynchronous tasks. By developing activities that derive from Nativeactivity, users can access the runtime through Nativeactivitycontext to implement functions such as scheduling children, creating bookmarks, invoking asynchronous work, registering transactions, and so on.
1.3.2 Activity Context
Activitycontext is the workflow runtime interface of the activity author, providing access to many run-time features. The following example defines an activity that creates a bookmark using the execution context (a mechanism that allows an activity to register a continuation point in its execution that can be recovered by the host that passes data into the activity).
1.3.3 Activity life cycle
The active instance is in the executing state when it starts. Unless an exception occurs, the activity remains in this state until all child activities and all other pending work (such as a Bookmark object) have been completed, and the activity is converted to the Closed state. The parent of the active instance can request that the child be canceled, and if the child can be canceled, the child is completed when it is in the Canceled state. If an exception is thrown during execution, the runtime pushes the activity into the Faulted state and propagates the exception up to the active parent chain. The following is a list of the three completion statuses for an activity:
Closed: The activity has completed its work and exited.
Canceled: The activity has gracefully abandoned its work and exited. When this state is entered, the work is not explicitly rolled back.
Error: An activity has encountered an error and exits without completing its work.
When you save or unload an activity, the activity remains in a executing state.
2 Workflow Scenarios
2.1 Document approval process
This use case combines the functionality of many WF4.0 and WCF. Use these two techniques to achieve the approval of a file. Includes a client application that submits files, approves files, approves process management applications to facilitate communication between clients, and executes rules for the approval process. There are 3 types of approval workflows in this use case:
1, a simple approval process
2, a quorum approval process
3, a complex approval process
The process architecture diagram is as follows (Figure 3):

From the client view, the approval process has the following functions:
1, in the client can request a user
2. The WCF service on the client side calls the WCF services on the server.
3, a unique user ID is returned to the client, at which time the users can open an approval process.
4, the client can initiate an approval document for simple, quorum or complex approval procedures.
5. After the client's interface approval button is clicked, a workflow instance is started in the Client Workflow Service host.
6, the work flow to the server to send an approval request.
7, the service side itself also initiates a workflow, responding to the approval process.
8. Once the approval workflow of the service end is executed, the result is sent back to the client.
9, the client displays the result.
10. The client receives an approval request and can respond to the approval requirement at any time.
11. WCF services hosted on the client can receive approval requirements from the server.
12. Present the documents of the review.
13. The user may approve or reject the document.
14. The WCF client sends a response back to the server.

From a server-side perspective, the approval process functions as follows:
1, the client requests to participate in the approval process.
2, the service side of the WCF service can accept client requests
3. Generate a unique ID for the client. Store user information in the database.
4. The unique ID is sent back to the user.
5. Accept the approval request and execute the approval process
6, received a request for approval, open a new workflow.
7. Depending on the type of request (simple, quorum, or complex), different workflow activities are performed.
8. The related send and receive activities are used to send requests for approval to the client for review and wait for the response to be received.
9. The results of this approved workflow are sent to the client.

Example:
1, start the server after the start of four clients, and complete connection with the server (Figure 4)

Figure 5:

2. Apply for user (three types of user) respectively
See Figure 6

3. Create a complex document approval process
See Figure 7

4, a user after the submission of B, C will receive audit tasks, you can choose to agree and veto
See Figure 8

5, B, C agreed, the approval task will be sent to D
See Figure 9

6, D after the submission of approval, a will receive feedback, the approval process is over
See Figure 10

Introduction to Windows Workflow Foundation technology (based on. NET Framework 4.5)