1. InforFlow2.1功能简介

InforFlow2.1是遵循由国际工作流管理联盟制定的工作流管理规范而实现的工作流中间件产品。InforFlow2.1由可独立运行的工作流引 擎以及图形化的流程设计器构成。工作流引擎是工作流管理系统的核心，负责实例化流程定义，根据流程定义驱动业务流程的运行，根据定义及运行时的动态信息计算任务分配条件，分配任务，根据对实际的流程控制请求完成对流程的动态回退、跳转等控制操作，负责发起对应用程序的调用，接收来自应用系统的调用请求，负责发起对应用程序插件的调用。流程设计器基于Eclipse框架实现，完成流程的图形化定义，使得开发人员与业务人员轻松完成对业务流程的分析与设计过程。

2. 强大的流程建模能力

流程建模能力的强弱是工作流产品区别于普通办公自动化系统的因素之一。企业中所存在的业务流程是企业生产、经营过程的反映，必然涉及多部门、多角色的人员之间的分工协作，有些业务流程的运行甚至是跨级别、跨地域、跨季度的在时间与空间上都跨度极广的复杂过程。若支持这样的业务流程，必然要求工作流产品具有极强的流程建模能力。

InforFlow2.1工作流元模型基于WfMC规范实现，是对业务流程所具有的共性的完善的抽象。InforFlow2.1在对支持复杂业务流程的分层建模、复杂任务分配方式以及应付易变的业务过程方面都具有独到之处，使之可以轻松应付这些复杂性，降低了应用系统的开发难度，也减轻了开发人员的工作量。

2.1 工作流元模型

InforFlow所支持的工作流元模型如下图所示：

图1.InforFlow的工作流元模型

包就像一个容器，一个包中包含了多个业务相关的流程定义以及这些流程运行时所需要的资源，调用的应用程序，所使用的相关数据。包将这些信息包容在一些，使得对业务流程的描述更加清晰。

一个包可以含多个流程定义，每个流程定义都是一个可独立运行的完整的业务流程。一个流程包含一个开始节点、一个结束节点以及多个活动节点。开始节点定义了流程唯一的入口点，结束节点定义了流程唯一的出口点，而活动节点的实现类型有五种，分别为：无实现活动、Tool活动、子流程活动、块活动、路由活动。

当一个活动的实现类型是“Tool类型”时，活动可包含一个或者多个应用程序，当为活动增加应用程序时，需要指明对应此应用程序的形参的输入参数，即实参集，实参可以从活动的所包含的相关数据中取。

当一个活动的实现类型是“子流程类型”时，此活动可以引用其它的流程定义。同应用程序的定义相同，也需要定义对应此流程的形参的实参集，实参可以从活动的所包含的相关数据中取。此外，还需要指明流程的执行方式（同步还是异步）。在异步执行的情况下，活动的执行持续到子流程的过程实例初始化后。在同步执行的情况下，在子流程实例被初始化后，活动将被挂起。在这个流程实例运行终止后，活动被恢复。在子流程完成时，在调用与被调用流程间可能要使用返回参数。

下面的两个图以两级嵌套流程为例分别描述了同步子流程与异常子流程的运行状况：

图2.同步子流程运行过程

图3.异步子流程运行过程

当一个活动的实现类型是“块活动类型”时，此活动可以引用一个活动集。和子流程实现不同的是，不必为块活动定义实参集，执行方式等。
块活动的运行状况如下图所示：

图4.块活动运行过程

当实现类型是“无实现类型”时，需要手工来控制工作流活动，并且其实现必须使用明确的信号通知工作流管理系统。

路径活动（虚活动）即没有执行者，也没有应用程序。并且路径活动的运行对流程相关数据，或者应用程序数据没有任何影响。

2.2 任务分配方式

流程中某个节点的工作由谁来做，反映了相应的这个人对任务处理的权限。在实际的应用系统中，对执行人任务处理权限的定义可能会非常的复杂，需要与业务系统紧密结合，才能定义出符合特定业务需求的人员权限。例如，在银行信贷审批系统中，可能需要定义某人(具有某种角色的人)可以审批的信贷额度；在制造业的采购计划制定流程中，可能需要视采购金额的不同而由具有不同权限的人进行审批；甚至在某些办公系统中，要求定义时并不确定由哪些人来做，而是在运行时由流程上一节点的执行直接指定下一步由谁来做。

在InforFlow中，我们可以定义节点的执行人为由符合以下条件的人进行处理：
直接指定执行人 运行时将任务直接分配给指定的人员由属于某个部门的人处理 运行时将由属于此部门的某一个人或所有人进行处理由具有某种角色的人的处理 运行时将由拥有此角色的某一个人或所有人进行处理定义任务分配条件表达式，由符合表达式的某一个人或所有人处理其中，使用任务分配条件表达式，InforFlow可以将应用系统自身的权限系统方便的集成进来，并在任务分配时有效的利用这些信息，从而极大的扩展了InforFlow的任务分配方式，在应用系统权限设计良好的情况下，可以满足几乎所有任务分配的需求。

例如，仍以上面列举的需求为例，在银行信贷审批系统中，人员有审批额度这种权限，则可以定义某个节点由执行人审批额度大于流程实例所申请的额度的人进行处理；我们也可以定义某个节点由流程实例的发起人进行处理，或者由另外一个节点的相同的执行人进行处理。

我们也可以定义，执行人表达式为一个变量，此变量代表了一个人(或一个组织)，变量的值是在流程实例的运行过程中由上一步节点的执行人动态指定的。

2.3 使用操作与业务单元分离流程逻辑与业务逻辑

InforFlow2.1扩展了XPDL对应用程序的定义，将应用程序分为“业务单元”与“操作”两种类型。业务单元反映了某个活动节点要“做什么”，操作反映了此活动节点对流程有什么样的控制权限，例如“批准”、“否决”、“打回”等等。业务单元与操作都是某种类型的应用程序，但是将这两个概念区分开来，可以帮助开发人员构建出耦合性更低，业务组件对流程运行过程的依赖性更小的应用系统出来，从而真正使得所开发的流程可变、易变。从形式上来看，业务单元可以由工作流引擎发起调用，而操作则是由应用系统控制发起对工作流引擎的控制方法的调用。

3. 强大的流程控制能力

3.1 静态流程控制

静态流程控制是指工作流引擎严格按照业务流程的定义驱动业务流程实例的运行。InforFlow可以支持串型、并型、循环等工作流模式的运行，其中并型模式又可支持同步分叉、选择分叉、同步合并、选择合并等并型流程运行策略。同时，在节点的输出转移上可以定义转移条件，可以实现基于条件的路由。如果运行时工作流引擎发现所有输出转移上转移条件都不满足，则可以根据对默认转移路径的定义，驱动流程按默认路径运行。

3.2 动态流程控制

InforFlow可以支持串型、同步分叉、选择分叉、同步合并、选择合并、循环等静态定义的工作流模式，同时也支持任务的动态回退、跳转等由应用系统在运行时动态决定的控制方式。

任务的动态回退使得用户可以将任务退回到已经经过的任意一个活动实例上去，由活动原先的执行人重新执行此项活动。任务动态回退的流程图示如下图所示：

图5.任务回退示意图

任务的跳转使得用户可以决定流程下一步不按照预先定义好的流程运行，而是按自己所指定的目标节点运行。使用跳转功能，可以实现对紧急事项的处理，也可以实现对流程控制的灵活性要求比较高的业务流程。流程跳转的示意图如下所示：

图6.任务跳转示意图

3.3 使用插件增强流程控制能力

使用流程事件插件使得InforFlow工作流引擎对流程的控制更加细腻，更加灵活。在流程实例、活动实例、工作项状态发生改变的任一时刻，InforFlow允许应用系统以插件的形式扩展其业务上所需要的功能。InforFlow所支持的插件示意如下图所示：

图7.InforFlow的可扩展架构

使用事件插件的一个场景是利用插件来获取、修改流程相关数据的值。当业务单元完成对业务对象的处理后，可以由插件从业务数据库中获取所定义的流程相关数据的值。由于某些相关数据会影响流程的运行过程，因此，也可以在适当的时刻在插件中修改相关数据的值，以获取所希望的流程运行路径。

当然，也可以使用插件以发送mail的形式实现对任务处理人的任务到达通知，或者当流程运行结束时，及时通知流程的申请人，以提醒业务人员做进一步的处理。