业务规则管理新技术随着业务规则的出现应运而生，它包括规则的查询、规则生命周期管理、版本管理以及规则模板等的管理。像数据从程序中分离一样，它使业务规则也同样从程序中分离。业务规则管理，使规则成为企业重要的财富。由此可见，业务规则语言的表述通俗易懂，即使普通用户也能实现对规则的完全控制。
BRM在技术上为业务应用的实施团队提供了更大的灵活性。由于让专业开发人员专注在复杂任务的开发，而让业务分析人员和策略管理者担负较简单的规则制订和修改任务，业务实施团队能够更迅速、更有效地应对企业内外与业务或技术环境相关的各种变化。此外，跨IT和业务部门的决策速度也可以加快，新规则的部署时间也进一步缩短。
业务规则管理系统的引入，使应用系统结构及其维护方式发生了巨大的改变：基于业务规则的方法将大大缩短系统的开发时间；更加适应系统业务逻辑的变化；开发者可以直接使用业务规则的技术而无需了解过多的实现细节；大大减少了编程的工作量，减少了编程错误，使开发者更加关注系统本身的业务需求；基于业务规则的开发方法还模糊了系统需求分析、设计和编程的界限，业务规则库介于用户界面和数据库之间，系统具有更好的灵活性，基于业务规则的系统开发比定制开发更能节省费用，同时能满足用户的个性化需求。
业务规则和规则管理中的核心技术是业务规则引擎技术。从字面亦可理解，业务规则引擎其实就是规则的触发器。依靠业务规则引擎，调用相应的应用程序对业务规则队列和队列中的数据和对象做出相应的处理。
BRM是一种很好的实践方案，但是它需要借助企业级的业务规则管理系统(如ILOGJRules)来实现。
(3) BRM - Worknow&BPS的特点1) BRM - Workflow&BPS的技术特点。
①基于J2EE体系结构的标准服务。遵循J2EE体系结构规范的、适合于分布式异构环境的标准服务平台。通过网上申报审批系统提供的标准服务，为企业提供各类电子政务支持。
②基于WfMC标准的工作流引擎。通过内置规则处理引擎以及基于图形化界面表示的工作流定制工具，降低工作流的定义难度，同时使得工作流程配置更加灵活。
③基于业务规则管理的业务处理。
④基于XML标准的数据交换标准。通过应用XML技术，规范当前各级政府部门之间的数据交换标准，从而实现广域网上的、各级政府应用之间的互联互通。
2) BRM - Workflow&BPS的功能特点。
①基于Web的多级审批。通过Web方式，既可以部署在专网，也可以部署在互联网，通过中心机房集中数据、应用，其他各方用户无需重复建设，只需通过终端PC即可使用。
②支持复合流程。既支持从企业到县市，再到省、国家的主体流程，也支持各级单位内部审批的子流程。
③多种审批方式。既支持串联审批，也支持并联审批；支持自动审批方式。
④安全的体系结构。通过使用CA认证系统以及系统内置的用户安全认证机制，为网上申报审批系统提供完备的安全体系结构。
(4) BRM - Workflow&BPS的功能1)流程与审批建模：包括图形化拖拉建模方式（支持自定义）、流转控制表单定制（支持自定义）、审批格式表单定制（支持自定义）、流转规则定义（支持自定义）、审批规则定义（支持自定义）、流程图丰富方便的人性化展现方式、流程及其流转规则的管理等内容。
2)流程运行：包括单一流程的运行过程控制和多个流程的运行控制。
3)流程监控：包括对流程运行的监控，提供丰富方便的人性化展现方式。
二、流程与审批建模
1．流程
流程是指公文流转的次序或程序，构成流程的主要成分为：公文流转的内容，即公文“流转控制表单”+“审批申请格式表单”；流程中的节点，用来控制公文流向的节点；连接各节点的线段。
由于审批申请材料数量大、易变并将不断增加，所以对于审批申请材料需要电子化、规范化，即需要定义规范的“审批申请格式表单”，提供给审批申请者在网上填写和提交。
由于审批申请材料的上述特性，所以审批申请材料本身不可能作为流转规则的判断依据，需要通过对形形色色、成百上千的审批申请材料进行抽象形成控制流转的数据模型，即“流转控制表单”。
“流转控制表单”和“审批申请格式表单”是“公文流转与审批”最基础的数据模型。其中，“审批申请格式表单”量大、易变并将不断增加，应该给用户有选择自己定义的权利，一般称“表单定制”。“流转控制表单”应该基本固定、长期使用。
“流转控制表单”是否具有自定义功能其实不重要。
“流转控制表单”+“审批申请格式表单”是流程中流转的内容。实际上，数据也许并没有正式流转，可能只是对相关角色分配相应的数据访问权限，这和具体的数据库设计有关，如果是多个机构分别有多个数据库，相关数据可能需要从一个数据库流转到另一个数据库。
流程建模的另外一个基础工作是需要将流程中的节点和线段预先进行规范定义，将预先定制好的节点和线段放在一个窗体内，使图形化拖拉方式的流程建模十分方便、简洁。由于系统可能面临数量众多的审批节点，所以，要达到流程简洁清晰，应该能够分层次的表达流程，比如，对于一个审批部门，在总图上应该可以选择只表示为一个节点，也可以选择放开节点，如果节点或线段内部还要细分，则可以通过进一步打开来获得。
2．节点和线段定义
节点的定义其实包含了审批机构与角色的定义，我们把参与审批的各个机构分别用节点表示。一个图形节点+标签（标签为部门或角色名称）可以通过两种方式实现：一是把需要用到的节点和线段预先都做好；二是做几类通用的节点和线段。标签为空白，用的时候需要定义一下标签。
机构和角色的层次必须可以支持足够用的多层，如机构、机构内再分部门、部门内再分小组、小组内再分角色。
3．流转控制表单定义
上面已经描述了“流转控制表单”及其作用，流转控制表单是在对各类审批流程及公文共性的基础上进行的抽象定义，该表单基本固定，可以长期使用；它是流程控制规则定义及流程运行的依据。
流转控制表单应该包括所有与流程控制有关的一切属性，包括审批申请提交者、提交时间、审批结果规定期限、审批者及其审批状态（通过、拒绝、处理中、已经超时）等。
流转控制表单如表15 -4 -2所示。
表中，审批者A为土地，B为环保，C为卫生，D为消防，E为计委。
4．流程定义及控制基本原理（流转控制表单的作用）
下面我们通过流程的一个抽象节点，来描述流程定义及控制基本原理以及流转控制表单在流程定义及控制中的作用，如图15 -4 -7所示。
1)流程节点n是前续节点的后续节点。
2)有A、B、C、D、E5个前续节点有可能将流转内容（“流转控制表单”+“审批申请格式表单”）流转到本节点。
3)流程节点n在激活前处于睡眠状态。
4)流程节点n的前置规则可以根据流转控制表单的属性进行定义，当前置规则满足时本节点激活。
5)流程节点n激活将进行审批处理。
6)流程节点n的审批处理将改变流转控制表单的属性。
7)流程节点n的后置规则可以根据流转控制表单的属性进行定义，流转内容将根据后置规则确定对1、2、3、4、5的流向。
8)流程节点n是后续节点的前续节点。
流程定义过程如下。
1)根据具体的业务规则定义各个节点的前置规则和后置规则。
2)将有前后关系节点连接起来。
3)流程的运行则将在各节点的前置处理规则和后置处理规则控制下进行。
5．审批申请格式表单及自动审批基本原理
审批申请格式表单由审批提交者使用，由流程管理人员定义和维护。
审批提交者提交的公文可以分为格式和非格式两类，对于非格式公文的审批只能采用人工方式进行审批。
对于审批申请格式表单，通过业务规则管理系统可以实现审批自动化，基本原理如下。
1)对象“审批申请格式表单”在一个时间段内具有相对固定的属性。
2)审批执行者的人工审批过程其实就是对对象属性的判断和决策过程。审批执行者可以根据需要将部分或全部审批过程定义成为审批规则放到规则库中，系统将根据规则自动进行操作。
例如，审批职能部门×，对审批申请格式表单中的A、B、C、D、E项进行审批，审批申请格式表单如图15 -4 -8所示。
图15 -4 -8审批申请格式表单上述过程如果是大量、经常发生的，审批执行者就完全有理由将上述过程形成规则增加到规则库中，让系统代替人工完成上述工作。
这样的设计和实现将方便系统的灵活使用，可以采取两种方式：一种是人工审批一段时间后将成熟固定的审批业务交给机器完成；另一种是人工和机器结合工作，人工操作后机器自动复核，或者机器审批人工复核。
其审批规则如图15 -4 -9所示。
6．公文流转与审批实举例
基本建设项目并联审批流程图如图15 -4 -10所示。
流程过程如下。
1)立项阶段办结周期为10个工作日（相关窗口同步进行受理，手续内部递送）。
2)申请项目转正阶段办结周期为5个工作日（未按规定交纳规定费用者除外）。
3)申领二证，即建设用地规划许可证、建设工程规划许可证。
4)立项阶段报批项目文本。A报批项目书：申请、地形图。B报批可行性：申请、编制的可行性报告。
5)投资计划。如用地批复、施工图。根据上面的例子，给出如下公文流转与审批实例图示，如图15 -4 -11所示。其中审批规则支持用户自定义。
三、BRM - WorkfiOW&BPS实施策略与步骤
BRM - Worknow&BPS的设计、开发的总体策略是：充分利用技术优势，在业务规则管理系统的构件产品基础上，结合BRM - Workfiow&BPS的总体目标进行开发。
目前国外已经有比较多的基于业务规则的信息系统，国内相关的产品还是很少。具有代表性的是ILOG公司的ILOG JRules规则管理信息系统。它的系统结构大致如图15 -4 -12所示。
ILOG公司的产品具有完备的功能，较强的可靠性，可定制性和可扩展性。该系统中可以将规则自动部署为J2EE、J2SE、Java或Web服务应用程序，能够自动检查规则，甚至可以通过Web浏览器编写、阅读和更新规则。在ILOG的业务规则语言框架中，定义了3种规则语言：业务操作语言(BAL) -使用自然语言语法编写规则；技术规则语言(TRL) -采用伪代码形式编写规则；ILOG规则语言(1RL) -使用类似于Java或XML的语法编写规则。在规则库中，具有规则版本控制、权限管理、规则历史记录、锁定机制等一系列的功能。在规则库实现上，采用直接绑定XML文档的方法。引用Radian Guaranty公司的首席信息官Liz Sbuttleworth的话说：“我们之所以选择ILOG JRulcs，一是因为其丰富的用户界面，二是因为其业务方法赋予了用户强大的定制功能。此外，IlOG JRules的出色性能与可扩展性也是我们所看重的。”
以ILOG产品为例，具体的实施策略与开发计划如表15 -4 -4所示。
四、基于ILOG构件的开发
ILOG JRules是面向Java环境的完整的业务规则管理系统(BRMS)。它提供了所有必要的工具，用于对整个企业的业务规则进行管理，包括组织和存储业务规则、执行业务规则、规则库和规则语言。
1．组织和存储业务规则
组织和存储业务规则包括规则建模( modeling)、规则编写、规则测试、规则部署和规则维护。
2．执行业务规则执行业务规则
有规则库机制、规则引擎。前者用于组织和存储业务规则，后者用于执行这些规则。
通过ILOG JRules，应用程序开发人员可以将基于规则(RuleBased)的编程和面向对象的编程结合起来，在新的和现有应用程序中添加业务规则处理功能。
ILOG JRules提供一种规则引擎。关键的业务规则将从应用程序源代码中分离出来，转换成可执行格式，由规则引擎执行。这些分离出来的业务规则可以被BRMS管理。规则引擎可以容纳数千条规则，每秒能够触发几十万条规则的执行。
使用ILOG JRules，可以在不牺牲任何关键(mission - critical)系统的重要特性（如可扩展性和集成性）的前提下，迅速开发和维护这些应用系统。另外，ILOGJRules加强了IT部门的灵活性和工作效率，提高了客户满意度，让IT部门能够迅速应对企业内外业务或技术环境的变化。
ILOG JRules提供了一套基于一组基础类之上的Java应用程序编程接口(APl)。
借助这些API，用户可以对业务规则应用程序的各个方面进行定制。
使用ILOG JRules，企业可以方便地使策略管理者、业务分析人员和应用程序开发人员共同合作，实现业务规则的共享、组织、执行和管理。这些功能都是通过以下的ILOG JRules组件实现的。
(1) Rule Builder
Rule Builder提供了图形用户界面(GUI)和若干个编辑器用于编写业务规则，创建业务对象模型( Business Object Model，BOM)。BOM将业务规则的自然语言语法映射到底层应用程序对象上（如Java型对象、XML型对象或Web Services对象）。
(2) Web Rule Builder
Web Rule Builder让用户能使用Web浏览器编辑规则。
(3)规则库(Repository)
规则库提供存储、组织和管理业务规则所需的工具和机制。
(4)规则语言(Rule Language)
规则语言为以自然语言语法编写业务规则并在规则引擎中执行这些规则提供必需的语言支持。
(5)规则引擎(Rule Engine)
规则引擎实现了关键业务规则从程序源代码的分离。它被集成到了业务规则应用程序中，用来执行组合在规则集中( ruleset)的业务规则。规则引擎采用了一种称为执行对象模型( eXecution Object Model，XOM)的技术，它定义了规则会使用到和作用到的应用程序类( Class)。XOM使用绑定机制，使规则引擎可以访问不同类型的对象，包括Java对象和XML数据。
(6)应用程序编程接口(APl)