关键词 业务规则引擎;工作流;业务对象;装备保障管理系统
二十一世纪,只有高度信息化的军队才能在未来战争之中占据有利地位,这在上世纪末及本世纪初的几场战争之中得到了证明。因而,借助于信息产业高度发展的成果来建设自身,已经成为建设我军的一个重要手段。在这样的大前提下,如何利用现代化信息技术,监控武器装备数量和质量的变化、提高装备维护、维修效能,就成为装备保障管理系统的主要任务。
图1 装备送修申请流程
通过调研分析,装备保障管理系统的用户主要由两类用户组成,一类是由总装、军区、师旅团、部队等四级组成的装备使用用户,另一类是由有关院校、研究所、训练机构、修理厂等组成的装备保障用户。系统主要包括装备质量信息采集、维护计划申请、汇总、报批、任务下达、装备进厂、交接、修理(试修)、检验、验收、出厂、结算和保修等管理工作。系统中所有的管理过程依靠装备信息及其所代表的装备在不同的装备使用用户和保障用户之中流动来加以实现。以系统这中典型的装备送修申请为例,这一管理过程可以表示为图1。另外,根据不同装备的种类、型号,系统之中的管理过程以及管理过程涉及的用户也各不相同。
根据上述分析,我们认为系统的难点在于三点:①系统包含大量的用户,使用什么样的技术将众多用户之间的协作表示为一个有机的整体; ②系统包含由各种不同种类、型号引起的大量、各不相同的管理过程,如何将这些管理过程合并、简化;③系统如何应对将来用户和装备变化带来的管理过程的变化。
工作流管理系统(WFMS)主要用于完成企事业单位业务过程的完全或部分的自动化,它根据的一定的过程规则集将业务所需的文档,信息或任务从一个参与处理的活动结点传递到下一个参于活动结点[2]。它将业务过程描述为一系统由活动组成的流程;整个系统可以抽象为系统S(A,U,F,M,E)。其中A指代一组对文档、信息或任务进行加工的活动的集合;U是系统之中完成相应活动的用户集;F是工作流程集,每个流程FX是活动{AX,...| AX ∈A}组成的有序序列;M是流程定制器,它是从A到F的映射,它能够将现有业务过程定制成表示为FX的工作流;E是工作流引擎,它能够在事件驱动之下对F之中的流程进行解释执行。一条典型的工作流,在运行时可以表示为图2。
图2 工作流引擎执行流F1(A1,A2,A3,A4)时的示意图
对照装备维护管理系统与工作流管理系统,我们可以发现两者之中至少有两处可以类比:①装备维护管理系统之中的业务管理过程实际上就是与装备相关的信息在不同的业务处理活动之间的流动,而工作流管理系统是数据在不同的活动之间流动;②装备维护管理系统之中的用户执行相应的活动对收到的信息加以处理,这与工作流管理系统之中用户执行相应的活动对收到数据加以处理相同。也就是说,装备维护管理系统之中的业务过程、用户、业务信息处理可以用工作流管理系统之中的流、用户、活动来表示。
基于以上分析,我们就可以将整个装备维护管理系统抽象为一个工作流管理系统的实例IS(A,U,F,M,E)。其中A定义为{AX|如质量信息采集、维护的计划申请、汇总、报批、任务下达、装备进厂、交接、修理(试修)、检验、验收、出厂、结算和保修等对装备信息加以处理的活动};U即为系统之中两类用户的集合,由它们在相应的计算机上完成对装备信息加以处理的活动;F是业务流程的集合,其为A的成员的有序集;M是业务流程定义器,它能够根据不同的装备种类、型号,将系统之中的业务流程使用A定义的活动映射成F的实例。E就是上述的工作流管理系统之中的工作流引擎的一个具体实例。图3表示了整个系统执行一个简单业务流程(由部队申请、师部汇总、军区批准等活动组成)时的情况。
图3 工作流表示的装备保障管理系统运行时的示意图
使用工作流管理系统可以较好的表示装备管理系统,但是本系统仍然有两个较为严重的问题。①系统之中需要依据不同装备种类、型号来定制不同的工作流。因而,工作流数量众多,导致工作流引擎的负担重,定义工作流的工作量巨大。更重要的是,当系统之中需引入新的装备种类和型号之后就需要定义新的工作流,维护量较大。②系统之中活动结点对未来的变化封闭或自动化程度低、大部分需要人工进行处理。如:不同的装备,其质量的评价标准是不同的,如果将这些评价处算法在活动结点处编码自动完成,则活动结点在不更改编码的情况下不能处理新的装备型号。如果将其更改为人工处理,则系统的自动化程度低。为解决上述两个问题,我们需要引入其它的技术来简化工作流的数量、提高应对变化的能力。
根据上述分析,我们可以看出造成工作流数量众多的原因,是因为系统需要依据装备的类别和型号来单独定义工作流。系统之中必然有许多相似的工作流,某些流程之中去掉一些结点就是另外一条流程。如:流程F1{A1,A3,A5,A7,A8},流程F2{A1,A3,A7,A8},F3{A1,A7,A8},虽然F1比F2多出一个活动A5,F2又比F3多出一个活动A3,但是它们之中的活动的相对顺序是相同的。统计发现,如果我们将类似F1、F2、F3的流程都归结为F1,则系统之中的流程数量将减少95%以上。要实现这一目标就要求活动结点具备一定的智能性,它能够跳过其不需要处理的装备。但是使用硬编码的方法来实现这一目标是不适宜的,因为硬编码会使将来流程的变化和新的装备加入成为不可能。结合“2”中的问题②指出的活动结点需要增加应对变化的需要,我们需要使用一种新的技术来增加活动的智能性且不能伤害系统应对变化的能力。我们引入业务规则引擎技术来解决上述问题。
那么,什么是业务规则引擎呢?首先,它是嵌入应用程序的一个应用组件,它的任务是把当前提交给引擎的数据对象与加载在引擎中的、用规则语言书写的业务规则进测试和比对,激活那些符合当前数据状态的业务规则,根据规则语言书的逻辑,对数据对象加以修改或触发相应的应用程序的操作[3]。它包括匹配器,执行器,工作存储器,规则容器等功能模块,其工作原理如图4。其具体内容可参阅参考文献[3]。
图4 规则引擎结构图
在装备管理系统的活动结点处使用规则引擎,我们就可以为系统之中引入必要的智能性,从而解决“2”中所提出的两个问题。可以书写类似如图5的规则语言代码来跳过不必处理的装备类别或者加入如自动评价装备质量的能力。
图5 用于跳过某些装备类别和评价装备质量的规则代码
当有新装备加入、管理流程变更、信息处理算法变更时,我们只需更改上述的规则代码即可,从而大大加强了系统应对变化的能力。
图6 装备维护管理系统功能结构图
基于上述成果,我们使用.Net Workflow框架和ILog Rule Engine for .Net实现了装备维护管理系统。系统使用.Net WF组织业务流程,将Ilog Rule Engine 部署在活动节点来增加系统应对变化的能力。系统的整个功能结构如图6。它共分为五大部分: ①基础数据,用于维护系统之中所有的装备、用户等基础数据,系统使用这些基本数据来生成工作流之中所传递的业务对象(Business Object),当这些业对象传递到活动节点时,首先由规则引擎加以处理,然后返回给系统的其它部分。②业务活动,包括装备质量信息采集、维护计划申请、汇总、报批、任务下达、装备进厂、交接、修理/试修、检验、验收、出厂、结算和保修等基本业务处理环节。这些活动通过人机交互对规则引擎处理后的业务对象加以处理,每次处理完成之后只需点击“进行下一步处理”按钮即可。③业务流程定制,由系统管理员根据业务流程,使用业务活动之中的活动生成工作流,同时指定该工作流传输的业务对象(BO)。如果需要,也可同时编辑工作流之中每个活动节点处的规则代码,这些规则代码只能对本工作流指定的业务对象加以操作或执行某些指定的应用程序操作。④待办事务,本功能提供所有流入到本节点处的工作流任务,只需点击相应的任务,系统即可调用相应的业务活动对此任务加以处理。⑤系统维护与设置,包括数据的备份与恢复,权限设置,加密设置等维护功能。
工作流和规则引擎技术的结合为装备维护管理系统的实现提供了较为理想的技术平台。与基于传统工作流技术的系统相比,它减少工作流的数量,因而减少工作流定义的工作量,使系统维护的工作量大大减少。更重要是,它提高了系统应对变化的能力,从而延长系统的生命周期,大大提高了系统的效益、投资比。但是也应看到使用上述技术带来的问题:①系统开发之中要考虑工作流与规则引擎的协同工作,从而增加了系统开发的难度;②系统更改管理流程时,需要同时考虑相应规则代码的改变,提高了对系统维护人员能力的要求。
[1] Boris Lublinsky, Didier Le Ti, Realization Workflow and Business Rule On SOA, InfoQ, 2007.11
[2] WMC, WorkFlow, Management Coalition Terminology and Glossary [EB/OL]. http://www.wfmc.rog, 1999.9
[3] Collen MacClintock, Werner Eberling, ILog JRules Technical White Paper, ILog Ltd, 2002.5
[4] Ronald G.Ross, Principles of the Business Rule Approach, China Machine Press, 2004
[5] 李春芳等,基于业务规则的工作流模型,计算机工程与应用, 2006.26