Workflows

This includes items such as workflow design functionality, the different types of workflows, the infrastructure available to run the workflows, and the workflow development tools.

Types of Workflows

Two workflow types: sequential and state-machine.

Sequential Workflows

This type of workflow describes a process that has a beginning point, performs any number of actions in a given order, and then arrives at an end state.

State-Machine Workflows

State-machine jump around in their execution rather than move in an ordered manner. These jumps are triggered by events, and each jump is to a defined state. State-machine workflows start in a beginning state; move to and from any number of interim states; and then arrive in an end state, at which point the workflow instance is complete.

When to Use What

You might opt to use the sequential workflow by default because it is such a common way of thinking about the flow of processes. However, here are some instances where using the state-machine workflow type is the best option:

  • When events external to the workflow dictate the next step

  • When the order of work activities is not always the same or predictable

  • When human interaction is prevalent throughout the process

  • When you’re using a sequential workflow, and it becomes increasingly difficult to model all the possible execution paths (which may be a sign that you are using the wrong type of workflow)

Table 3-1: State-Machine Activity Classes
Open table as spreadsheet

Class

Description

EventDrivenActivity

Allows a workflow state to be executed based on the firing of an event external to the workflow instance.

SetStateActivity

Allows the explicit transition to a new workflow state.

StateActivity

Symbolizes a workflow state.

StateInitializationActivity

This activity can contain child activities that execute when a workflow state is entered.

StateFinalizationActivity

This activity can contain child activities that execute when a workflow state is ending.

Hosting

 Windows Workflow Foundation is not a standalone product, it needs a host application in which to run. A host can be any type of .NET software, such as a Windows Forms, ASP.NET, console, Windows Service, or web service application.

The Runtime Engine

The Windows Workflow Foundation runtime engine is what makes workflows go,essentially. What it isn’t, however, is a separate service or process. 【这句话说的很纠结】In fact, the workflow runtime engine runs in the same process as the host application.

Communication with the Host

There are communication methods that enable you to quickly and easily pass data in and out of a workflow, and more customizable methods that can handle external events and call methods outside a workflow instance’s context.

 

ASP.NET

The most glaring characteristic of web development is the fact that it is a stateless environment. This means that every request made by an end user is separate from any other request made by the same user. Web development platforms such as ASP.NET provide the infrastructure to deal with these issues using concepts such as Sessions and ViewState.

Another trait that sets web development apart from Windows development is the fact that the user has a different experience related to processing and UI interactivity. On the web, a page isn’t returned until it is processed and ready for viewing. In Windows, the UI is always visible even if something is going on in the background. In this case, developers generally perform long-running tasks asynchronously so that the UI appears to be responsive and the user is able to interact with the form even if other work is being done behind the scenes.

By default, workflow instances are started asynchronously and control is immediately returned to the host. Although this behavior may be desirable in a Windows application, you may not want this to occur in your ASP.NET applications. The workflow platform enables you to modify this type of behavior.

-------------------------------------------------------------------------

顺序工作流相关的Activity

并行 (ParallelActivity)、

事件驱动并行 (EventHandlingScopeActivity)、

数据驱动执行 (ConditionedActivityGroup)、

事件驱动分支 (ListenActivity)

强制性控制流模式:条件分支 (IfElseActivity) 和迭代（WhileActivity、ReplicatorActivity）。

WorkflowRuntime.GetLoadedWorkflows()的作用是取得当前内存中已加载所有工作流，没有把工作流加载到内存的作用。

使用workflowRuntime.CreateWorkflow()创建的新的工作流默认是加载到内存中的。

本以为对这工作流使用使用Start()方法会使工作流持久化到数据库中，实验发现并不这样的。

但是发现新创建工作流实例的在执start() 方法之后接着再执行ManualWorkflowSchedulerService.RunWorkflow()

会导致工作流从内存unload并持久化到数据库中，这点是需要注意的。

WorkflowRuntime.GetWorkflow(Guid guid)的作用是把指定的工作流加载到内存中，即使加载到内存中的工作流也不意味着已经运行。

ManualWorkflowSchedulerService对web工作流应用程序有着非常的作用，web工作流应用的工作流引擎运行于服务器，每个客户运行于不同线程。

ManualWorkflowSchedulerService.RunWorkflow(Guid guid)运行指定的工作流实例。

 WorkflowInstance.Start() VS ManualWorkflowSchedulerService.RunWorkflow()

MSDN:

WorkflowInstance.Start方法:开始执行工作流实例。

Start 将对此工作流实例的根活动调用 ExecuteActivity。如果 Start 遇到异常，则它将通过调用 Terminate，并使用异常的 Message 属性（作为终止原因传递）来终止此工作流实例。

ManualWorkflowSchedulerService.RunWorkflow方法:运行指定的工作流实例。

备注

这是使用当前线程来运行工作流的同步调用。在工作流空闲、挂起、完成、终止或中止之前，它不会返回。

--------------------------------------------------------------------------

“Start方法:开始执行工作流实例。”同“RunWorkflow方法:运行指定的工作流实例。”看似功能描述相同，其内函大相径庭。

Start用于启动工作流其内各活动的执行。workflowInstance.Start()常用于新建的工作流。

这里的Start是相对于：Resume()、Suspend()、Terminate()、Abort()...而言的。

RunWorkflow用于把工作流加载到当前线程中执行，说白了是主环境线程通过RunWorkflow调用实现了工作流执行的时所需要的外围环境。

RunWorkflow常用于触发工作流事件或于工作流通信之后调用的。其实对于工作流的所有操作只在调用RunWorkflow之后才能得到真正的运行，这就是所说的“同步调用”的副作用吧。

激发工作流事件时，并不需要主动加载工作流实例到内存，需要知道工作流实例的guid，只需要取得用户自定的xxxxEventService（实现有[ExternalDataExchange]属性标记的interface的类）的对象引用。

//取得工作流通信服务对象

var xxxxEventService = workflowRuntime.GetService<xxxxEventService>();

//激发工作流事件

xxxxEventService.RaiseEvent$$$$(guid,data);