正如语言是人之间的沟通方式一样，数据是IT系统之间的沟通方式，语言之间的沟通总是最有效的，数据交互却未必，因为IT系统里的数据除了让计算机理解外重要的是还需要人理解。在这篇文章里，我们将讨论工作流系统里的数据，从数据角度分析工作流数据的分类以及不同的应用场景。

一、工作流系统的应用场景

在正式开始对工作流数据的讨论之前，首先对工作流系统的应用场景进行讨论是必要的，因为工作流数据脱离不开工作流系统这个大的上下文。目前，工作流系统的应用主要有两种方式：

1、    将工作流系统嵌入到业务系统中使用。此时工作流系统作为内部组件对业务系统进行流程逻辑的横切。试想一个需要多人处理的电力缴费流程，在引入工作流系统之前，我们需要为每个业务表单设置一个状态位，以此来进行业务处理状态的跟踪。如果流程固定，那么这样做并没有什么不好，例如财务软件、海关报关软件等，它们的流程虽然复杂但是不常改变，此时就没有必要引入工作流系统。但是对于另外一些情况，例如制造业的订单处理、库存管理、政府的协同办公等，流程经常需要定制修改，此时如果继续由业务系统自己处理流程逻辑那么成本将会很高。

2、    使用工作流系统进行业务系统的集成。在上规模的企业里，很多流程会涉及到不同的业务功能，例如报价、订单审核、资产核准、绩效评估等，这些流程经常会跨越不同的部门和业务系统。因为不同企业都有自己所采用的业务系统、组织机构以及最佳的业务协作方法，所以这些流程基本上也随企业而异。工作流系统此时扮演的就是集成角色，由其通过定制流程将这些业务系统撮合起来，实现企业内各部门、客户间的信息流动和协作。

在第一种应用场景下，工作流系统作为业务系统的内部横切组件出现，作为横切组件，工作流数据仅仅包括与流程逻辑相关的数据以及其他必需数据，这些数据包括工作流控制数据、工作流相关数据以及需要通过流程传递的业务数据。

在第二种应用场景下，由于不同业务系统之间的数据传递很大程度上依靠工作流系统，所以这些数据被封装为SDO在不同WEB服务间传递，需要注意的是，这些数据并不在工作流系统中存储。

        在下面的工作流数据分类中，我们将详细分类这些工作流数据。

二、工作流数据的分类

提到工作流数据，就不得不提业务数据。作为最直接的区分，我们将存储于业务系统中的数据称为业务数据，将存储于工作流系统中的数据称为工作流数据。根据WFMC定义，我们将工作流数据分为工作流控制数据和工作流相关数据。

1、  工作流控制数据。指被工作流系统管理的系统数据，这些数据包括了与流程实例和任务实例相关的执行数据，例如流程实例的状态、执行时间等信息、任务实例的执行者、执行时间、状态、紧急程度等。

2、  工作流相关数据。指与业务流程相关的数据。工作流相关数据又具体分为3种：

·         影响流程实例执行的业务数据。在WFMC中，这个数据被描述为：工作流系统通过该数据来确定流程实例的流转条件，并选择下一个将执行的任务，这些数据可以被业务系统访问并修改。例如报销流程中的“报销金额”，这个数据会决定该流程的审批路径；再例如为任务设置的超时时间，这个数据会触发任务的取消。实质上这些数据就是工作流系统需要依赖于进行流程流转的业务数据。

·         契合业务的关联数据。指工作流系统与业务系统进行关联的数据，例如特定于WEB系统，工作流系统会在每个流程实例里保持有导航至对应业务表单的URL。

·         传递作用的业务数据。当流程跨越多个业务模块时，需要在模块间传递数据，此时会利用工作流系统进行传递，会在工作流系统里暂时存储这些业务数据。

那么，工作流数据有哪些应用场景呢？

三、工作流数据与业务上下文

工作流数据最重要的职责之一就是为业务系统的不同应用场景建立起与之对应的业务上下文。

什么是业务上下文？

我们知道，IT系统是对企业现实业务的映射。在一个翻译公司的典型业务场景中，校对人员对翻译人员提交的翻译文档进行审校，此时，校对人员持有翻译人员翻译后的文档，他需要对该文档进行检查，产生新的审校文档并反馈翻译人员的翻译质量。那么，映射到IT系统里，校对人员的任务通常对应于一张需要处理的业务表单，业务表单里会展现他进行当前工作所需要的数据：翻译文档、翻译人员信息、该校对工作的紧急程度等，另外，在这张表单里，他所能进行的操作也根据他此时的职责作出了行为限定：例如他可以上传新的校对后的文档，但是不能删除已有的翻译文档等。如下图1所示，业务表单实质上反映的是此刻我们能获取哪些数据以及能够如何处理这些数据，我们把它称之为业务上下文，可以看到，在IT系统里，业务上下文实质上等于数据加上行为。

企业业务由一系列相互关联的业务场景组成，这些业务场景对应于IT系统里的业务上下文，而业务上下文的本质则是数据加上行为。数据和行为的不同决定了业务上下文的差别。这与现实中的工作相符，人们根据获取/处理信息的不同，担负不同的职责。 

图 1与应用场景对应的业务上下文

工作流数据如何建立业务上下文呢？看一个简单的例子。

在实际应用工作流系统进行开发时，我们经常会碰到这样的问题：同一流程中的不同任务对业务数据拥有不同的权限，如下图6-9所示。

图 6‑9与流程相关的业务数据权限

上图中，在执行请假申请任务时，申请者可以编辑请假人、天数和原因3个字段；而到审批任务时，审批者增加了一个可编辑的审批意见字段，但其余3个字段变化为只读字段。我们将这类问题统称为与流程相关的业务数据权限控制。

产生这类问题的原因是什么呢？原因就在于在一个业务流程里，不同的任务具有不同的业务上下文。如下图6-10所示，不同的任务展现不同的数据，并具有不同的行为。

图 6‑10任务与业务上下文

在IT系统的设计实现中，数据的建模是通过领域模型实现的。在工作流系统的嵌入式应用中，流程实例即是通过与领域模型相关联实现与业务契合的。那么，图6-10可以进一步泛化为图6-11，流程中任务通过获取领域模型不同的部分实现业务上下文的界定。

图 6‑11领域模型与业务上下文

在大部分的业务流程建模中，一个流程模型只与一个领域模型关联。

那么，回到最初的问题上，如何处理此类权限问题呢？答案非常明了：由领域模型实现对业务上下文的切分，工作流系统通过契合业务的关联数据与业务上下文挂接，保持工作流系统的单一职责。

图 6‑12流程相关的业务数据权限控制

如上图6-12所示，我们在业务系统里引入业务权限角色的概念，通过该角色隔离开工作流系统与业务数据权限，即我们认为业务数据权限的管理属于业务系统范围（由业务系统具体实现），更进一步，我们认为其属于领域模型的职责范围。在定义好业务系统的权限角色后，我们通过任务级别的工作流变量将流程中的具体任务与业务权限角色绑定，这样就实现了流程任务与业务数据权限的挂接。

在上面的例子中，我们看到的是利用关联业务的工作流数据界定任务级别的业务上下文，这是一种最简单的工作流数据应用场景。在不同应用中，我们可以看到，工作流数据一个重要的职责就是为业务流程里的任务/流程建立业务上下文，实现数据的聚合。在简单的应用场景里，对一个流程实例而言，这些数据可能只对应于一个领域模型；对流程实例里的一个任务实例而言，这些数据对应于领域模型的一个切面。复杂一些的情况，业务上下文需要跨越多个领域模型甚至多个业务系统，这时我们可以看到，通过工作流系统能够显著降低业务系统建模的复杂性，因为这些数据聚合工作可以有效分派给工作流系统承担。同时，我们需要保持工作流系统的单一职责，工作流系统只保存与业务数据进行关联的关联数据、必需的业务传递数据以及自身的执行数据。

图 6‑29跨系统的业务上下文

四、工作流数据与数据分析

工作流数据的第2个应用场景是对业务流程执行进行数据分析，这部分的数据主要是工作流控制数据。这一部分正受到越来越多的重视，是未来工作流系统的发展方向。

图 6‑48外部环境从流程实例拉数据进行分析

这里有两个典型的应用例子：

例子1在对报销流程进行分析时，我们发现大部分的报销金额都低于500元，然而这些报销流程却都要经过很多环节，在与客户确认后，我们将低于500元的报销限定于部门内部审批即可，这样对个人来说大大加快了报销过程，对公司来说则省下了很多的办公成本。

例子2，在制造流程里，很重要的一点是需要控制流程的节拍时间，即流程里各个任务的完成时间要一致，如果有一项任务的时间多于其他任务，那么很快就会形成瓶颈，造成在制品的大量积压，前续的任务完成很快，中间忙死，后续任务执行者却无事可做，更重要的是，不能对客户进行快速交付。

五、工作流数据与流程路由

最后一种应用场景非常常见，这部分数据即影响流程实例执行的业务数据，直接上图：

这部分影响路由的一定是业务数据，它们保存到工作流系统里对流程路由产生影响。这种影响不限于任务的选择，还包括的任务的执行条件、任务的完成条件、基于数据的任务触发等。

六、工作流数据小结

总结一下，作为区分，我们将存储于业务系统中的数据称为业务数据，将存储于工作流系统中的数据称为工作流数据。

工作流数据分为两种：工作流控制数据和工作流相关数据。其中工作流相关数据又分为3种：影响流程实例执行的业务数据、契合业务的关联数据和传递作用的业务数据。

工作流数据的应用场景：为流程/任务建立业务上下文，这部分数据主要是契合业务的关联数据和传递作用的业务数据，这是工作流数据最重要的职责之一；数据分析，这部分数据主要是工作流控制数据，这是未来工作流的发展方向；影响流程路由，这部分数据人如其名，是影响流程实例执行的业务数据。

实际应用中，我们一定要保持工作流系统的单一职责，例如划分任务权限这个需求，一定需要业务系统自行实现权限的界定，工作流数据仅仅进行挂接。