本文是对集成了业务流程管理、业务规则和商业智能的随需应变场景进行探索的系列文章中的第二篇，本文主要关注将业务规则集成到业务流程中的这种集成，并考察如何将业务规则集成到一家虚构的公司的业务流程中。

简介
这是对集成了业务流程管理（business process management，BPM）、业务规则（business rule）和商业智能（business intelligence）的随需应变场景进行探索的系列文章中的第二篇。本文主要关注将外部业务规则集成到业务流程中的这种集成，并考察在我们假想的公司 IFM 中如何将业务规则集成到业务流程。

在 上一篇文章中，CIO Christina White 听说了业务流程管理技术的诸多好处，因此让她的一个架构师 Greg Thomas 进行调查研究。Greg 发现，不仅通过将业务流程从应用程序逻辑移出到 BPM 引擎中可以带来巨大的利益，而且将最易变的逻辑转移到业务规则引擎中可以提供更大的灵活性，甚至允许业务分析员访问规则。Christina 认为定价问题非常适合作为他们第一次实施这种技术时所处理的问题。

本文主要关注在业务流程中规则的使用。首先我们简要地考察一下如何将外部数据源（例如规则引擎）与业务流程挂钩。然后我们将谈到一些特定的规则引擎，并展示如何分别使用这些规则引擎构造简单的定价规则。最后，我们再深入研究在本场景中用到的 WICS 组件，尤其是从业务流程中访问外部规则时用到的一些组件。

Christina 和 Greg 很快就被说服为 BPM 使用 WICS，因为使用 WICS 把外部应用程序和数据源连接到业务逻辑做起来比较容易。WebSphere Business Integrator Adapter 技术使得连接外部源（external source）成为可能。通常将 WICS 描述为一种 “hub-and-spoke（中心辐射型）” 架构，以 WebSphere InterChange Server 作为中心（hub），以连接外部应用程序和数据源的适配器作为辐条（spoke）。

很多遗留应用程序（例如 SAP）和数据源（例如文本文件、XML 和 JDBC）都可以使用 WBI Adapters。对于其他应用程序和数据源，可以编写定制的适配器。所有适配器都提供相同的基本功能：它们在 WICS 中业务流程所期望的格式与外部应用程序和数据源所要求的格式之间转换数据。

如上图所示，WICS 业务流程逻辑操作业务对象（Business Objects），而适配器这个组件则负责在业务对象与特定应用程序所支持的任何格式之间转换数据。Greg 很快就认识到可以使用一个定制的适配器来连接规则引擎和 WICS 业务流程。他注意到，对于所有适配器，面向 WICS 的接口基本上是一样的，但是每个适配器在其面向应用程序的接口方面却有所不同。对于规则引擎，面向应用程序的接口可以编写成它所暴露的任何 API。

WBI 提供了一个 Web 服务适配器，这种适配器可以把 WICS 业务流程连接到 Web 服务。在编写了必要的 Web 服务接口之后，可以非常容易地结合带有 Web 服务支持的规则引擎（例如 ILOG JRules）以及其他规则引擎来使用这种适配器。

了解规则
本系列的前一篇文章介绍了各种不同的规则引擎。其中提到的规则处理器类型包括简单型（simple）、数据中心型（data-centric）和面向事务型（transaction-oriented）。规则有很多种。在感知并响应（sense-and-respond ）规则引擎（Tivoli TEC）中，规则被指定作为对事件的响应。说明性（declarative）规则指定有何事发生，这与程序性（procedural）规则不同，后者指定“事情是如何发生的”。说明性规则表现了判定逻辑（decision-logic）规则引擎（Blaze、JRules 和 BRBeans）的特点。约束和关系规则在以数据为中心的事务性规则引擎（Versata）中占主导地位。解决方案空间（solution-space）约束规则在那些基于约束标准（JRules）从备选方案中计算出“最适合”结果的引擎中得以使用。Greg 只关注三种规则引擎：Versata、BRBeans 和 ILOG JRules。

Versata Logic Server 是 Versata 公司的产品。这里考虑的其他规则引擎都是“判定逻辑”规则引擎。与此相反，Versata 支持事务逻辑，并且是面向数据操作的。Versata 有一个功能完备的开发环境，但是没有基于 Web 的工具来修改规则。Versata 经常在由基于事务的和基于流程的规则逻辑组成的数据为中心的 Java 应用程序以及 Web 或应用程序 GUI 表示层中被用作生成器（generator）。

BRBeans 是 WebSphere Application Server Enterprise 的一个功能。BRBeans 运行时环境是以驻留在 WAS 中的一些 EJB 实现的，与这些 EJB 一起的还有一个用于调用规则的应用程序框架（framework）。BRBeans 是一种“判定逻辑”规则引擎。然而，它并不支持规则集（共享一个公共执行上下文的一组规则）。BRBeans 设计点（design point）将规则（应用程序用到的引用）与规则实现（一个 Java 类）区分开来。BRBeans 提供了一个规则管理应用程序（和 API），这种应用程序可以动态地将规则与特定的规则实现相关联，并且允许轻松地更新与规则相关的参数。

JRules 是一种“判定逻辑”推理规则引擎。它采用一种占资源很少的运行时环境，这种运行时环境可以与应用程序一起部署，它为可动态更新的规则提供储存库，应用程序可以使用 JRules API 从这个储存库中提出并触发规则。JRules 提供了一个功能完备的开发环境，该环境支持规则单元测试和基于规则的应用程序的代码生成。JRules 还为生成易于使用的、基于 Web 的用于修改规则的接口提供了工具。JRules 代码生成选项包括 J2EE（Web Service 和 EJB）和简单的 J2SE。

回忆前一篇文章，Christina 需要将 IFM 的遗留定价应用程序替换为一个新的、灵活的定价模型，后者考虑了很多参数；而商业人士也希望能够根据市场行情更改定价模型。Greg 认识到，当出现对定价过程的新需求时，他们可以使用 WBI 流程设计工具快速地更改流程流（process flow）。应用不同定价方程式的需求可以通过开发一个集成到定价业务流程中的业务规则引擎（Business Rules Engine）来满足。Greg 从建立简单的定价和提价（markup）模型开始。他的定价模型是一个动态定价算法，在这个算法中，只要利润率不变或增长，就采用相同的定价动作（提价或降价）

markupi+1 = markupi + delta*sign{profiti - profiti-1}*sign{markupi - markupti-1}

下一节将展示如何分别在 Greg 考虑的三种规则引擎（Versata、BRBeans 和 JRules）中创建动态定价规则。

使用 Versata 创建业务规则
下面 Versata Logic Studio IDE 的屏幕快照展示了在定价场景中用到的 Versata 业务对象。注意，Versata 业务对象在接口中看上像是数据库表，而规则看上去像是数据库 SQL。

图 1: 用于定价（提价）场景的 Versata 业务对象

下面的屏幕快照展示了在 Versata Logic Studio 的 Versata Rule Builder 功能中用于计算提价增量（markup delta）值的新值的算法。

图 2: Versata Rule Builder 中用于计算提价“增量（delta）”的 Versata 提价规则

Versata 支持业务对象之间的父/子关系，它具有从子对象属性到父对象属性的累积（rollup）功能（求和、计数，等等）和从父对象属性到子对象属性的复制（replication）功能。Versata 创建“备份”其业务对象的数据库表并生成实现由规则组成的数据操作的 Java 代码。Versata Logic Studio 支持使用 Versata Logic Server Rule Builder GUI 将定制的 Java 方法添加到它的生成的类中，但是大部分规则可以在不编写任何代码的情况下定义。

使用 BRBeans 创建业务规则
BRBeans 将 BRBeans 规则，即“在 BRBeans 框架中实现的业务规则”，与 BRBeans 规则“实现者（implementor）”，即实现业务规则的 Java 类区分开来。换句话说，BRBeans 规则定义或向 BRBeans 框架描述一条业务规则，而 BRBeans 规则实现者是在代码中实现这条规则。BRBeans 规则管理 GUI 允许定义 BRBeans 规则。BRBeans 并不直接支持规则实现者的开发，但是它的确可以定义实现类，所有实现者都可以在某个 BRBeans Java 包中继承这个实现类。BRBeans 还提供了一组大约 20 个预定义 BRBeans 规则实现者。预定义规则实现者往往局限于一定的范围。例如，这些实现者不支持像 “if (price * quantity * profit_percent >X) then do-something” 这样的简单规则。下 图在 BRBeans 规则管理 GUI 的下拉框中显示了这些内建的规则实现者的一部分。

图 3: 显示某些内建规则实现者的 BRBeans GUI

BRBeans 将规则定义分成四种类型：简单规则（simple rule）、分类器规则（classifier rule）、分类规则（classified rule）和情景规则（situational rule）。简单规则可以返回任何 Java 对象。分类器规则返回一个 Java String，该字符串的值指定一个类别（例如 “GOLD”、“SILVER” 或 “BRONZE”）。分类规则除了自己的名字之外，还有一个类别（classification），例如 GOLD、SILVER 或 BRONZE。同一组的分类规则都有相同的名字，但是每条规则各有不同的类别值。例如，您可以有一条 DISCOUNT 规则，它的类别为“SILVER”，这条规则返回一个 Java Long 型常量值 20，另一条 DISCOUNT 规则的类别为“SILVER”，返回常量值 10，还有一条 DISCOUNT 规则类别为“BRONZE” ，它返回一个常量值 5。分类规则永远不会从一个应用程序中直接触发。情景规则结合了一条分类器规则与一条分类规则。接着上面的例子，DISCOUNT 情景规则的分类器部分计算出一个类别，比如说“GOLD”，这将导致 BRBeans 框架调用类别为“GOLD”的分类规则，最终产生由该情景规则返回的一个 Java Long 值 20。

下面的规则管理 GUI 屏幕快照展示了定价规则的信息：实现该规则的 Java 类的类名，初始化参数（markup 和 delta 的初始值），以及 “firing”参数的来源，当触发器方法被调用（引起规则被触发）时，要将这些“firing”参数传递给规则。一旦规则被触发，firing 参数就通过一个 Java Object 数组传递给该规则。

图 4: BRBeans Rule Management GUI 中定价（提价）规则的定义

BRBeans 框架直接支持规则调用其他的规则。在 BRBeans 术语学中，被其他规则调用的规则称为从属规则（dependent rule）。BRBeans 框架在一条“父”规则的初始化方法中将所有从属规则的名字传递给该父规则，之后父规则在需要的时候调用从属规则。不过，用于计算提价（markup）的规则比较简单，因此不需要使用从属规则。

为 BRBeans 规则编写 Java 实现
如果应用程序对函数的调用没有得到某一个预定义规则实现者的支持，那么必须编写一个定制的 BRBeans 规则实现者。BRBeans 实现者是一个 Java 类，它实现了 Java 接口 com.ibm.websphere.brb.RuleImplementor，该接口包括一个初始化方法和一个触发（fire）方法。init 方法接受在 BRBeans 规则管理 GUI 中定义的初始化参数和任何从属规则的名字。“fire”方法接受来自客户机应用程序中触发器方法调用的 “firing”参数。fire 方法实现产生规则行为所必需的所有逻辑。下面的实例代码是从定价场景中 MARKUP 规则的 init 和 fire 方法摘录下来的。第一段摘录展示了处理初始参数的代码。第二段摘录展示了计算新值“delta”和新 markup 百分比的代码。

图 5: 在 BRBeans 规则实现者 init 方法中处理初始化参数

图 6: 计算新 markup 对老 markup 和 delta 的百分比，计算新 delta

在 ILOG JRules 中开发规则
JRules 规则开发环境支持三种规则格式：BAL(Business Analyst Language) —— 一种直观的 IF-THEN-ELSE 规则格式，TRL (Technical Rule Language) —— 一种强大的语言，由技术人员使用，还有一种 Decision Table 规则，在这种规则中输入和输出是以“决策表（decision table）”的形式指定的。

由于 IFM 定价规则十分简单，因此这些规则可以用一条 BAL 规则建模，该 BAL 规则使用一个输入 Pricing 信息资源和一个对象，该对象保存了先前的利润和提价信息。下面的图展示了在 JRules 规则生成器（rule builder）下测试实用程序中的对象模型和提价规则。

图 7: 在动态定价（提价）规则中使用的对象模型

图 8: 在 rule developer 测试环境下显示的 JRules BAL 中的动态定价规则

动态定价场景
动态定价场景的拓扑结构包括 WebSphere Portal Server、WICS、Analytics （将在本系列的下一篇文章中讨论）、一个规则引擎和一些用于将多个事物钩连在一起的 WBI Adapter。在门户前端进行了初始化的订购单消息启动定价过程。定价过程使用输入消息中的信息以及驻留在 Business Analytics 系统中的历史信息，将该信息传递给规则引擎，再在规则引擎中根据策略规则（policy rule）计算出订购单的提价。本场景还包括将这些规则所需的信息从输入消息转换成“规则业务对象”的一些映射。

WICS 中的业务流程
在本场景中，WICS 业务流程流（business process flow）通过将业务流程 BO 中的相关部分映射到一条规则 BO，然后将规则 BO 传递给规则适配器来触发外部规则。下面的 WICS Process Designer 屏幕快照展示了用于将来自订购单的信息映射到规则 BO，然后将其传递给规则适配器并处理结果的流程。

图 9: 到规则引擎的 WICS Business Process 连接

由于所有规则引擎适配器都共享一个公共接口并使用相同的 Rules 业务对象，因此从 WICS 中心的角度来看，这些规则引擎适配器是可互换的。从一个适配器切换至另一个适配器只需进行一次简单的选择，如下面的屏幕快照所示。

图 10: 为“规则引擎”端口选择一个规则引擎适配器

WebSphere Business Integration 规则业务对象
在规则引擎适配器中的规则业务对象是 VLS_versata_cw BO。该业务对象是基于 XML 的（也就是说，是从一个 DTD 定义创建而来的）。下面的表描述了这个业务对象。

图 11: VLS_versata_cw WebSphere Business Integration 规则业务对象的格式

属性	值
tableName	规则名或包含相关业务规则的 Versata 业务对象
tableId	在规则中用到的资源名称，或 Versata 业务对象的惟一键名和值
name
tableId
variableId	规则资源属性名和值，或 Versata 业务对象变量属性名和值
name
variableId
attribute	单个的返回值描述符
name
type
attribute

WBI 映射技术允许不同业务对象格式之间的自动转换。通常是由一个 WBI 适配器调用映射来转换 BO 格式的，但是在动态定价场景中，是从业务流程流中直接调用映射的。动态定价场景中用到的映射在输入定购单 BO 与规则 BO 之间进行转换。业务流程流调用映射将订单数据和分析性数据提取到规则 BO 中，然后经由规则引擎适配器端口传出 BO。当在规则引擎适配器端口上返回了产生的 BO 时，业务流程流调用映射将结果提取到定购单 BO 中。

接下来我们看看如何实现定制的 WBI 适配器，以便用该适配器将规则 BO 处理成用于 Versata、BRBeans 和 JRules 的规则。

在 WICS 业务流程中使用 Versata 规则
Versata 中任何东西看上去都像是一个关系数据库。规则看上去像是数据库 SQL 命令和围绕着业务对象组织的触发器，而业务对象像是一个数据库模式。Versata 直接支持关系数据库中的数据源。在一个典型的 Versata 实现中，Versata 被用作一个事务-规则应用程序的应用程序生成器和 GUI；而 Versata Logic Server 在运行中直接操作应用程序数据库，当数据被更改时就会触发这些规则。虽然对于直接关系访问来说这一点很有好处，但是它未必适合于一些要求集成多个系统的复杂的应用程序环境。由预先打包好的应用程序和各种平台上的遗留系统组成的那些环境要求使用先进的企业应用集成（Enterprise Application Integration）工具，例如 WebSphere Business Integration 产品家族中的企业应用集成工具。

WBI 适配器技术允许从业务流程流中访问驻留在 Versata 中的（Versata-hosted）业务规则结果。业务流程流将规则 BO 传递给定制的 WBI 规则引擎适配器。然后该适配器使用规则中的数据以及用于 Versata 业务对象的元数据来构造必需的查询和命令，以触发业务对象逻辑来计算提价和检索结果。

Versata VLS API 支持对 Versata 业务对象的结构（规则元数据）和内容（规则数据值）进行操作。Versata 适配器使用 Versata VLS Java API 来询问与输入 BO tableName 中指定的 Versata 业务对象相关的元数据，以决定如何用公式方式将数据请求（create / update / query）提供给 Versata Logic Server。下面的实例代码说明了业务对象元数据的使用，该代码检查业务对象中每个属性的元数据，以判定该属性是否为从一个特定数据对象检索数据时所需的惟一访问键（unique access key）的一部分。

图 12: 使用 VLS 元数据来判定对业务规则数据的惟一访问键

该适配器还使用 Versata VLS API 取出属性值到 Versata 业务对象并从这些对象中检索业务规则。注意，该 API 具有明确的数据库访问特色。

图 13: 访问 Versata 对象数据的 WBI 适配器代码

在 WICS 业务流程中使用 BRBeans 规则
和 Versata 适配器一样，BRBeans 适配器具有相同的接口，并使用相同的规则业务对象。BRBeans 适配器惟一不同的地方在于初始化和访问规则引擎框架的代码。

BRBeans 适配器中的初始化代码按照属性文件 BRBeans 所定义的那样建立 BRBeans 环境（主机、端口、规则 JNDI 信息和到 BRBeans “规则管理”框架的访问途径），该属性文件是在 Java 命令行参数中指定的。下面摘录了该初始化代码。

图 14: BRBeans WebSphere Business Integration 适配器的初始化代码

BRBeans 有一些特定的方法，用于调用每种类型的 BRBeans 规则：简单（simple）规则、分类器（classifier)规则或情景（situational）规则 ¹ 。BRBeans 规则管理 API 的确提供了区分简单规则和分类器规则的方法，但是 BRBeans 框架并不支持对情景规则的标识（identification），虽然它支持分类器规则的标识 ² 。只有用到简单规则和情景规则的时候，才可以使用 BRBeans API 来判断用于调用一条特定规则的正确触发器方法。BRBeans 要求为情景规则同时提供分类器规则和分类规则的名字，这样一来，如果一个给定的情景规则的分类器规则和分类规则具有相同的名字（也就是说，知道某一规则的名字就可以知道另一规则的名字），情景规则管理起来就更加容易。下面的实例代码调用了一个私有方法，该方法使用 BRBeans 规则管理器 API 来判断规则属于简单规则还是情景规则，然后调用适当的触发方法。

图 15: BRBeans 适配器中用于触发规则的 Java 代码。tableName 值和 tableId 值来自规则 BO

在 WICS 业务流程中使用 JRules 规则
JRules 支持向它的规则引擎提供 XML 文档输入。为了实现这一点，用户首先在一个 schema XSD 文件中定义规则中用到的 Java 类资源的格式，然后在规则执行期间使用 JRules API 和这个 schema XSD 将 XML 文档处理成资源。JRules 开发环境可以生成 J2SE 和 J2EE （Web 服务和 EJB）规则处理代码，因此适配器开发者可以选择实现。由于 JRules 运行时环境相对较小，因此我们甚至可以将它直接包含在适配器中。

以下代码表示用于在动态定价规则中用到的简单 Pricing 资源的 XSD 内容：

<schema ?gt;     <element name="productId" type="string"/>     <element name="profitPercent" type="double"/>     <element name="markupPercent" type = "double"/>     </schema>

以下代码表示用于一个实例 Pricing 对象的 XML 内容：

<Pricing>     <productId>A123</productId>     <profitPercent>25.0</profitPercent>     </Pricing>

接下来的内容
在本系列的下一篇文章中，我们将继续深入研究如何在 International Foods Market 公司的这些业务场景的上下文环境中将 BPM、业务规则和商业智能系统集成在一起的细节问题，到时候我们将主要关注商业智能系统的集成。

作者简介 John Medicke 是位于北卡莱罗纳州 Research Triangle Park 的 On Demand Solution Center 的首席架构师。在最近 7 年时间中，他一直从事解决方案开发领域的工作，所涉及的行业包括金融服务、零售、卫生保健、工业和政府。他是 Integrated Solutions with DB2 一书的作者，同时还在各种期刊上撰写了不少文章。可以通过 medicke@us.ibm.com 与 John 联系。

Feng-Wei Chen 在 IBM 位于北卡莱罗纳州的 Research Triangle Park 内工作。她是 Software Group On-Demand Solution Center 中的一名软件开发人员。她曾经参与过一些解决方案集成项目，参与和数据库系统及商业智能相关的解决方案的设计和架构也已经有三个年头了。可以通过 chenf@us.ibm.com 与 Feng-Wei 联系。

Margie Mago 在 IBM 位于北卡莱罗纳州的 Research Triangle Park 内工作。她是 Software Group On-Demand Solution Center 中的一名开发人员和解决方案架构师。自从加入该组织以来，她曾经参与过多个零售部门解决方案集成项目。可以通过 mmago@us.ibm.com与 Margie 联系。