所谓工作流(workflow)就是一系列相互衔接、自动进行的业务活动或任务,是经营过程的全部或部分自动化。当前工作流的研究与应用在我国主要侧重于工作流的实现技术。在动态变化的国际市场竞争环境中缺乏随机响应能力,因此工作流的智能性和动态性还有待提高。
因此,作者在对工作流过程元模型扩展的基础上,提出了一个智能动态工作流模型(intelligent and dynamic workflow model,IDWFM)。该模型在工作流中引入可扩展规则控制流程的智能动态流转,并且提出一个独立于工作流系统的流程规则协调器(flow-coordinator,FC)完成规则的解析。该协调器可以识别用户输入的信息,通过对输入信息以及规则的解析实现流程的智能选择以及动态运行。在FC的支持下,工作流管理系统的柔性和通用性也获得了提高。最后,通过一个具体的实例说明了基于IDWFM开发的工作流管理系统的动态性和智能性。
1 工作流过程元模型的扩展
工作流管理联盟(workflow management coalition)定义了一个工作流过程元模型,该模型通过活动(activity)、转移条件(transition conditions)、角色(role)、工作流相关数据(workflow relevant data)、被调应用(infoked application)5类元素描述工作流的组成及逻辑关系。该模型适于描述具有标准、稳定的流程输入和输出业务,以利于业务过程能够一致、准确、高效、可靠地执行。当前工作流专注于业务流程的表示,工作流元模型不支持流程动态生成以及智能流转的描述。为此,对原有的工作流过程元模型进行扩展,并做相应的变化,使得工作流中动态因素在元模型中更好地描述。图1为扩展后的工作流过程元模型。
在图1中,白色方框是工作流管理联盟的过程定义元模型,阴影部分为新引入的元素,分别是可扩展规则(extent rule)和规则引擎(rule engine)。可扩展规则主要包括路由规则、活动属性更改规则、自定义规则3种约束规则。这些规则是指流程运行过程中动态变化以及智能更改所必须遵守的约束条件。路由规则负责控制流程的走向;活动属性更改规则主要负责控制流程运行过程中工作流活动属性变化;自定义规则是指工作流运行中活动参与者自己定义的规则,通过它工作流系统可以实现全部或部分环节的自动运行、智能流转。活动参与者定义的规则包括上级定义的规则和用户自已定义的规则,前者定义的规则优先级高于后者。通过引入可扩展规则后所得到的新模型可以更好地描述工作流中动态变化的各个因素,实现工作流的动态性以及智能性。
规则引擎主要负责对扩展规则以及转移条件进行解释分析,并把分析判断的结果传递给工作流引擎。规则引擎根据需要调用流程规则并且对规则进行分析判断,根据分析的结果实现流程的动态变化和智能流转。
在工作流管理联盟定义的工作流过程元模型的基础上添加了可扩展规则和规则引擎后,该模型可更好地描述流程中的各动态因素,为建立业务流程提供充分的扩展性。基于添加了可扩展规则和规则引擎后元模型建立的工作流管理系统具有更强的动态性以及智能性。
2 基于扩展元模型的智能动态工作流模型
2.1 智能动态工作流模型形式化描述
智能动态工作流模型的形式化描述如下。
定义1 IDWFM={V,D,A,E}。式中,V为工作流的版本号;D=
定义2 αi={ID,Name,Tyi,Ri,ExA}为工作流活动。式中ID为活动的唯一标志;Name为活动名称;Tyi∈{Start,End,General Activity,Routing Activity,Auto Activity}为活动类型;ExA={N_Ai,V_Ai|i=1,2,...,n}为活动可扩展的属性集合,N_A为属性的名称,V_A为属性的值。通过定义活动中的可扩展属性就可以对活动的属性进行有效的描述。这些属性是动态可扩展的属性值,是动态可变的。当Tyi=General Activity时,Ri为空;当Tyi=Routing Activity时Rule表示路由规则,当Tyi=Routing Activity时Rule表示自定义规则。
定义3 e={ID,WFID,Name,Type,AF,AE}用于传递两个业务活动之间的数据信息和控制信息,是连接弧集合E的一个元素;式中,ID为连接弧的标识;WFID为连接弧所属流程ID;Name为连接弧的名称;Type为连接弧的类型;Type∈{Static,Dynamic},Type=Static表示连接弧在建模时建立;Type=Dynamic表示连接弧在流程运行时建立的是一个临时连接弧;AF和AE分别为连接弧的源活动和目标活动。
2.2 FC系统
传统的工作流产品提供一定的意见路由支持功能。但是它们存在着以下不足:①无法识别动态意见,无法根据流程中的信息项实现流程的动态变化、智能流转,并且这些只是提供了对意见路由的支持,功能比较单一。②传统工作流中的路由解析由工作流引擎负责,而且在建立模型的同时,路由规则已经固定好,无法实现规则的动态变化,而且当需求变化的时候,往往要对工作流模型做出调整。③规则的解析由工作流引擎负责,从而加大了引擎的负担,而且解析器的设计比较固定不容易更改。
基于上述原因,本文中提出一个独立于工作流系统的流程协调器(FC),FC系统独立于工作流系统,它与工作流系统共享同一个数据库,并且通过本身提供的交互接口与工作流引擎进行数据交换,结构如图2所示。
①规则设计器。规则设计器主要负责设计系统中用于约束、限制工作流动态因素变化所必须遵守的规则。当需求变化的时候,可以通过规则设计器修改规则达到对流程的设置,提高系统的柔性。
②意见字典设计器。业务主管签署的意见必须是计算机可识别的规范化的意见,业务主管只能从这些规范意见中进行选择,而不能随意地在意见栏内填写意见,从而“生产”出计算机无法识别的新意见。因此就必需建立意见字典,它用于存储意见标志和意见名称。通过意见字典设计器,可以相机进行添加意见以适应不同审批系统的实际需求。意见字典包含动态意见和路由意见两种。
③路由规则引擎。路由规则引擎负责解析流程的规则。通过对流程规则的解析完成工作流动态因素的动态更改,包括:流程活动属性的动态更改、动态添加、删除流程活动。路由规则引擎通过交互接口完成与工作流引擎的数据交换。通过加入路由引擎可以大大降低工作流引擎负担,也降低了工作流引擎的复杂度。
④交互接口。交互接口负责与工作流引擎进行数据的交换,它主要包括2个接口。
规则解析接口主要描述FC系统对工作流引擎提供的功能。其中Get Nexe Node Model ID函数主要是用于解析规则得到当前流程下一个活动,输入的参数分别为当前活动意见、流程模板ID、活动模板ID;EditNode函数负责更改活动属性,输入的参数依次为当前活动意见、流程模板ID、活动模板ID;IsHaveRul函数判断当前活动是否具有解析的规则,如果返回真则表示当前活动具有解析的规则调用上面两个函数,否则不调用路由规则引擎。
数据提取接口描述FC对外提供的数据获取功能。其中,Getopinion函数主要是获取意见列表,参数为流程模板ID.Getrul函数用来获得某个活动的规则,参数分别为流程模板ID和活动模板ID。以上接口中的函数可以根据需要进行扩展。
2.3 智能动态工作流模型体系结构
智能动态工作流模型结构如图3所示。
该模型右半部分是工作流管理联盟提出的工作流参考模型,左半部分是规则协调器。智能动态工作流模型与传统工作流模型的不同主要体现在任务表管理器工作流引擎,功能说明如下:
①任务表管理器。任务表管理器管理和维护任务表,引用规则协调器(即FC),提供用户界面,让用户便捷地选择意见。同时还可以自定义规则。用户在执行提交操作时,任务表管理器将检查用户是否完成必要的任务,是否签署了必要的意见。通过引用FC接口判断本结点是否具有解析规则。
②工作流引擎。工作流引擎通过FC系统的数据接口与其路由规则引擎进行交互,工作流中的一部分功能将由路由规则引擎负责。工作流引擎接受到任务后将根据条件对任务进行分配,如果当前结点需要对工作任务进行规则的解释分析,则工作流会把该任务分配给路由规则引擎,并把意见传送到规则协调器系统,由规则协调器中的路由规则进行解释分析,解释分析后把结果回送到工作流引擎,工作流引擎根据结果进行任务的分配。这样就实现了流程的智能流转。
从图3所示的模型看到,协调器系统与右半部分的工作流参考模型是相互独立的,两者之间通过数据接口相互联系,因此当同一个流程应用于其他的部门时,只需要通过协调器系统提供的设计器对意见字典和规则库进行更新,而不需要通过工作流系统进行更改,这样既可以非常便捷地实现工作流管理系统的移植,又提高了工作流管理系统的可移植性和通用性。
3 实例
FC系统的运行过程是和工作流引擎交互的过程,通过FC系统提供的数据接口进行数据的交换。本节以一个项目审批流程为例介绍流程动态智能流转的过程。图4为一个审批流程的流程图。
4 审批流程图
该流程的关键路径为:登记一岗位责任人审核一主管处长审核一局长审核一备案。而党委扩大会议为一个动态活动,它是在流程运行过程中动态添加的。流程中主管处长审核环节的审批时限是动态变化的。
假设审批输入的信息项如下。
审批项目名称:爆炸物品生产审批;生产产品:12#工业用炸药,数量:12t;紧急程度:紧急;意见字典为:同意生产、不同意生产。
审批系统规则包括审批环节和审批规则,其中审批环节有岗位责任人审核和主管处长审核。对应岗位责任人审核规则为:RP={1008,002,岗位责任人审核,上级指定规则,IF(超过时限流程自动通过,审批意见为:同意生产)}。对应主管处长审核规则为RA={1009,IF(事项类型为紧急)THEN环节中时限更改为1天}。RR={1010,add,IF(意见为同意生产并且物品的数量>10t)THEN增加党委扩大会议,主管处长审核环节)。
流程运行过程如下。
①当登记人员登记完后,提交申请,工作流引擎首先调用RulExplain中的IsHaveRul函数,函数返回false,这样FC系统将不进行工作,工作流引擎将负责解析流程模板,把任务发送给岗位责任人审核这个环节的任务处理人员。
②岗位责任人审核的处理人员得到任务后在任务处理界面进行审批,根据信息处理人员选择的意见为同意生产。如果在规定时限内审批,审批的过程为:提交任务后工作流引擎同样调用IsHaveRul函数,返回值为true,因此工作流引擎通过调用EditNode函数把任务发送给FC系统的路由规则引擎,引擎根据规则对主管处长审核这一环节的属性进更改完成后函数返回值为true,并把结果送给工作流引擎,引擎得到返回结果后再次进行任务的分配,把任务发送给下一个审批环节的处理人员。
③主管处长审核这一环节的处理人员得到任务后在规定的时限处理任务,选择同意生产,这样工作流引擎通过调用GetNexeNode函数把任务交给路由规则引擎进行规则的解析,得到增加的审批环节的信息并把结果返回给工作流引擎,工作流引擎根据结果把任务发送给新增加审批环节的任务处理人员。这样就完成了流程的智能动态的变化。
以此类推,流程逐步运行直到流程运行到最后。
流程在运行的过程中根据输入的信息项和用户输入的意见进行智能流转,自动调整流程的路径,实现了工作流的动态性以及智能性。
4 结论
通过对原有的工作流过程元模型进行扩展,引入新的元素,提高了元模型在流程动态性的描述。在该元模型的基础上提出了IDWF模型,该模型通过FC系统对规则的解析实现了流程的动态运行以及智能流转。此外引入FC系统的工作流管理系统具有很高的通用性和移植性。目前开发了基于IDWFM的动态审批系统并应用于某项目,具有很好的效果。
CIO之家 www.ciozj.com 公众号:imciow