工作流引擎
工作流引擎（Workflow Engine ）
目录 |
工作流引擎是指workflow（工作流）作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。
例如开发一个系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性（模块化和结构化）和弹性（容易根据实际业务逻辑的变化作出程序上的变动，例如决策权的改变、组织结构的变动和由于业务方向的变化产生的全新业务逻辑等等）。 Workflow 引擎解决的就是这个问题：如果应用程序缺乏强大的逻辑层，势必变得容易出错（信息的路由错误、死循环等等）。
就好比一辆汽车，外表做得再漂亮，如果发动机有问题就只是一个摆设。应用系统的弹性就好比引擎转速方面的性能，加速到100 公里需要1 个小时（业务流程发生变动需要进行半年的程序修改）还能叫好车吗？引擎动不动就熄火（程序因为逻辑的问题陷入死循环）的车还敢开吗？
Workflow 关注的是如何缩短流程闲置时间，从而提高企业的业务处理能力并使企业能够关注于真正对企业有意义的增值业务上。从建立企业神经系统的角度也许更能理解两者的区别。传统软件不能解决工作流的问题，例如ERP关注的是企业的资源配置，但不可能解决资源传输过程中的损耗和降低传输（流程）的成本；同样workflow也不能完全解决传统管理软件所能解决的问题，例如对生产管理的MRP 系统所能解决的生产过程控制通过workflow很难实现。但一个好的传统软件如果希望能自动化地在整个企业中应用起来，必须有一个强大的逻辑层，用以解决信息传递的逻辑判断和自动流转，这个时候就需要workflow的平台。
今天的很多优秀的工作流解决方案集成了短信息、页面服务、目标管理、文件管理和其他一些操作系统才提供的服务。
工作流参考模型确定了工作流管理系统的基本架构。该架构是开发工作流软件时应当采纳的系统模型，当然，一个工作流管理系统也可以不遵循这个模型标准，或只实现这个模型的一部分，但事实证明，这个模型结构是目前最为合理的。
系统的核心部分是工作流引擎，引擎是驱动流程流动的主要部件，它负责解释工作流流程定义，创建并初始化流程实例，控制流程流动的路径，记录流程运行状态，挂起或唤醒流程，终止正在运行的流程，与其他引擎之间通讯等等工作。WfMC没有针对引擎的实现提供具体的标准，因为对引擎做过多的约束并没有多大的现实意义。
一个工作流管理系统可以包含一个或多个引擎，并通过API向外部提供五个方面的功能服务，这些功能分别为：
- 接口1－流程定义的导入导出
- 接口2－同客户端应用程序和工作列表处理程序之间的交互
- 接口3－软件工具和应用程序的调用
- 接口4－不同工作流管理系统之间的协同工作
- 接口5－管理和监视功能
接口1－流程定义的导入导出
许多不同厂商提供的工具可以进行工作流流程的分析、建模、描述和归档等工作。这些工具需要识别公共的流程交换格式，以支持在这些不同的产品之间传送工作流程流程定义。接口1便定义了这样的交换格式。此外，接口1还定义了设计环境与运行环境之间交换的规范，以使不同的建模工具产生的流程定义可以输入到不同的工作流产品的运行环境中。 为了提供一个访问和描述工作流定义的公共方法，需要引入一个工作流元数据模型（meta－data Model），这个模型确定了流程定义中用到的一般的实体，这些实体都有不同的属性，不同厂商开发的工具可以根据公共的交换形式向工作流运行环境传送这些模型，传送可以通过API实现，也可以通过批量（Batch）传送实现。
元模型提供了流程定义交换中用到的基本的实体及其属性，这些都是工作流流程的组成部分，这些实体包括：
- 工作流流程定义
- 工作流流程活动
- 过渡信息（Transition Information）
- 工作流参与者
- 组织模型
- 工作流应用程序
- 工作流相关类型
- 工作流相关数据
- 系统和环境数据
- 数据类型和表达式
流程定义的交换
在不同的系统之间传递流程定义数据可能需要不同的机制，但在所有的情况下，流程定义数据的表达必须是一致的，这些表达包括一些公共的对象、关系及其属性。
接口２与接口３：
工作流管理系统必须提供同用户之间交互的通道，以便用户参与到系统的运行中。接口2主要完成这方面的功能。
WfMC在关于接口2 的规范中定义了工作流管理系统必须提供的类型、数据结构、API和错误代码，并以C语言头文件的形式提供。接口2所提供的功能大致可以分为一下五个方面：
* 1、 会话的建立和与撤销；
- 2、 获取工作流流程定义及状态；
- 3、 工作流流程实例的操作，如创建、挂起、终止流程，获取和设置流程属性等；
- 4、 工作流活动实例的操作，如获取和设置活动的属性，改变活动的状态等；
- 5、 工作列表（worklist）及工作项（workitem）的操作，如获取工作列表，处理工作项等。
通过这些功能，用户可以完成与工作流管理系统之间交互的所有任务：登录系统、打开自己的工作列表、处理自己的工作任务、将完成的任务提交给系统、将自己的任务转交给其他用户等等。
工作流系统在运行过程中有时需要调用外部应用程序，以完成系统不能完成的工作（比如，发送Email或传真，扫描文件等），或者与其他系统集成到一起。此时可以通过接口3来完成。
接口3的功能同接口2的功能大部分是相同的，因此，这两个接口有融合的趋势。接口3主要规定了调用外部应用程序的函数规范，以及外部应用程序返回数据的格式。
接口4－不同工作流管理系统之间的协同工作
在企业级的工作流系统中，流程往往需要跨越多个服务器或系统，比如应用于跨国公司或大型集团公司的工作流系统经常会有这种的需求，此时就需要服务器或系统之间进行通讯，交换流程控制信息和流程定义等数据，以实现流程跨地域运行。WfMC在规范中以C函数的形式提供了这些控制的定义，其中包括以下几个方面的功能：
- 1、创建流程实例；
- 2、获取流程实例状态；
- 3、获取和设置流程实例属性；
- 4、启动或终止流程实例；
- 5、改变流程实例的状态；
- 6、改变流程实例的属性；
- 7、更新流程实例。
服务器或系统之间信息交换的格式有多种，例如：文件、数据库表、E-mail或直接通过网络传送的数据流等等。
接口5－管理和监视功能
此接口提供给用户管理和监控系统的运行状态、查看系统运行的历史记录的功能。WfMC在此接口的规范中定义了各种审计信息的数据格式，这些格式包括：
- 1. 流程实例（Process Instance）审计信息：包括创建、启动流程实例和子流程实例的审计数据；流程实例状态变化的审计数据；流程实例属性变化的审计数据；
- 2. 活动实例（Activity Instance）审计信息：包括活动实例状态变化的审计数据；活动实例属性变化的审计数据；
- 3. 工作项（Workitem）审计信息：包括工作项状态变化的审计数据；工作项分配合重新分配的审计数据；工作项属性变化的审计数据；
- 4. 远程操作审计信息：包括开始和停止会话（Session）的审计数据；远程创建流程实例和远程改变流程实例状态的审计数据；远程获取和设置流程实例属性的审计数据；会话管理的审计数据；
- 5. 流程定义审计信息；
- 6. 扩展的审计信息及专用的审计信息。
这些审计数据在系统运行时刻由系统自动记录在数据库或文件中，可通过系统提供的API进行统计和查询，或者通过系统工具导出到系统外部。
另外，此接口还要提供系统管理与流程控制的功能，如：系统流程数据的备份和恢复，用户管理，流程管理等等。
通过这五个接口，工作流管理系统可以同外部的软件工具进行交互，这些工具可以由同一厂商提供，也可以由不同的厂商提供，但前提是这些工具都必须遵循WfMC的规范。用户也可以有充分的选择空间来决定哪一厂商的产品，或者自己开发属于哪一个接口的工具。
这五个接口一般通过API的形式提供给用户或软件开发商，这些API称为WAPI（Workflow API），也有厂商将API封装成组件形式提供，以简化开发难度、降低成本并提高效率。
可以用下面的图来表示这五个接口的作用：
工作流引擎主要功能之一帮助用户适应流程多变性的需要的，给客户带来价值就是在于流程发生变化时的易维护性和低成本，工作流引擎就像是汽车的发动机，一个汽车即使再漂亮，没有强劲的引擎支撑也能难成为一辆好车，工作流引擎的几个关键因素如下：
- 1、 适合东方流程特性、易用的流程设计器
包括各种环节特性、路径定义、时限定义、流程关联、参与人员（主办、协办、阅知）、表单权限、各种特殊权限等等。各种流程特性可以用工具通过简单易用的方式定义出来。
- 2、 高性能、高稳定性的流程引擎
如果工作流引擎只是用于少数人玩玩的情况，大可不必那么严谨，工作流引擎对于大规模数据量、并发访问、各种流程逻辑的支撑能力非常关键，因此高性能和高稳定性是非常关键的。E8.Net工作流引擎的高性能和高稳定性在大量实际的案例中得到了证实。
- 3、 工作流应用的快速开发架构
单纯的工作流引擎对于用户来说是没有意义的，就像司机拿着发动机不知道要做什么一样，因此好的工作流引擎的关键因素之一是提供终端应用系统的快速开发能力，这样对于软件提供者和软件应用者是双赢的局面。
- 4、 强大的业务扩展能力
工作流引擎帮助应用软件提供者很好的处理了流程逻辑的实现，可是如何支撑业务能力的扩展也是关键因素之一，比如：流程设计是由用户通过流程设计器去定义的，那如何实现各种未知流程下的统计信息呢？比如E8.Net工作流曾经开发过的物流配送系统，用户定义了各种未知流程同时又能统计各个配送点当月的配送量。
好的工作流引擎的关键因素远不止这几点，目前工作流引擎产品层出不穷，可是真正的区别是在于末端需求的实现能力和实现成本。