BPM 观点:管理规则项目版本:在 WebSphere Operational Decision Management V7.5 中引入分支

在本文中,我将使用 3 个需要在并发的规则项目版本上工作的常见开发场景,目的有两个:第一,我将介绍使用 WebSphere® JRules V7.1 中的可用工具以最佳方式处理这些场景的策略,第二,我将介绍 WebSphere Operational Decision Manager V7.5 Decision Center 中新的项目分支功能,展示此功能如何显著简化规则项目维护任务。 本文来自于 IBM Business Process Management Journal 中文版

Pierre Berlandier, 高级技术人员, IBM

Pierre Berlandier 在过去 15 年中一直致力于 ILOG 服务工作,在此期间,他帮助 ILOG 客户相继利用了规则编程范式的几个具体表现,从专家系统到实时智能代理,再到现在的业务规则应用程序。



2012 年 3 月 12 日

规则项目版本控制用例

在规则集首次部署到生产环境中和规则项目进入维护阶段之前,管理一个规则项目的多个版本通常是没有必要的。在此之后,需要使用项目版本来处理错误修复和重大项目重组的异常情况,并支持针对规则服务的持续并发增强。这些场景的细节如下:

  • 错误修复:在此场景中,更新一组规则集并将其升级到 QA 环境(或者可能甚至生产环境),而事实证明,这些更新在决策服务中引入了一个缺陷。在升级规则集与检测到缺陷的时间间隔中,可能已在规则创作环境中开始了另一个批的规则更新。在开始修复缺陷之前,规则创作者必须能够访问提供已升级的有缺陷规则集的有效项目版本。
  • 规则项目重组:在此场景中,是在 IT 规则开发环境中实现了针对规则集的一次重大技术更新,本例中的规则集为 WebSphere ILOG JRules V7.1(以下简称 JRules)中的 Rule Studio 或 WebSphere Operational Decision Management V7.5(以下简称 Decision Management)的 Rule Designer。举例而言,这种类型的更新包含规则集参数或规则流中的一项更改,以及 eXecution 对象模型 (eXecution Object Model, XOM) 中的一项更改所导致的业务对象模型 (XOM) 重组。在 IT 方面准备和测试此技术更新期间,生产规则集的维护必须继续进行,因此需要使用规则项目的两个并发的有效版本。
  • 并发规则服务增强:对基于规则的复杂决策服务的变更请求并不总是按顺序依次进行。它们可能来自参与决策的不同业务部门,每个业务部门都有针对其版本的具体日程安排,且每个业务部门都有各自的复杂性。因此,规则创作者需要能够在规则项目的不同区域中并发地编写规则,而在给定时间点仅发布一部分更改。

使用 JRules V7.1 管理规则项目版本

使用 Rule Team Server (RTS) V7.1,规则存储库维护着给定规则项目的单个有效状态(“最新项目状态”)。这使得并发规则项目版本的管理成为了一种非标准操作。但是,JRules 提供了一个产品功能和技术面板,该面板能够与一些定义明确的手动流程相结合,使用户能够模拟并发版本或满足对版本的需要。

以下各节将介绍这些功能和技术,展示如何将它们应用于我们的 3 个规则项目版本用例。

使用 RTS 基线

RTS 提供了两种不同类型的基线:开发 基线和部署 基线。前者允许用户在任何时候创建并发项目状态的快照。后者在 RuleApp 部署流程中一个可选步骤中创建。图 1 给出了来自 RTS 的基线管理页面。基线类型在表的 Deployment 列中表明。

图 1. RTS 基线
RTS 基线

创建之后,基线可用作一种历史引用,可根据指导浏览它们的内容。但更有趣的是用于管理多个项目版本的用途:

  • 现有基线的内容可更新,
  • 开发基线的内容可还原。

更新基线

默认的 RTS 配置是在一种 “冻结” 状态下创建基线,在这种状态下,基线的内容无法修改。理想情况下,它们应该终身保持该状态,因为它们的最初用途是将一个标记与一个已知且可证明的项目状态相关联。但是,一旦解冻,基线内容就可以更新,进而视为规则项目的一个有效版本。

要解冻基线,从 Manage Baselines 页面选择想要的基线,然后单击 Unfreeze(参见图 1)。将基线解冻后,您就可以逐个规则地更新它的内容,方法如下:

  1. 首先浏览一个规则的历史记录,选择应该复制到基线的规则版本。在我们的示例中,部署基线 loanvalidation-1.0.0 目前使用了 checkCreditScore 规则的 1.1 版。假设我们现在希望让基线使用 1.2 版。要使用此版本此,请从历史记录中选中它,如图 2 中所示。
    图 2. 更改基线版本
    更改基线版本
  2. 单击 Update Baseline(s),选择您希望将规则版本 1.2 添加到给定基线中,如图 3 中所示。
    图 3. 将新规则版本添加到基线
    A将新规则版本添加到基线
  3. 选择 loanvalidation-1.0.0 基线,如图 4 中所示。
    图 4. 选择要更新的基线
    选择要更新的基线
  4. 您现在已让 loanvalidation-1.0.0 使用规则的 1.2 版,而不是最初的 1.1 版,如图 5 中所示。
    图 5. 更新的版本
    更新的版本

通过重复此顺序,您可以使用想要的规则版本更新基线。您可以使用此方法在部署基线上执行快速错误修复:对于需要修复的每个规则,可以从基线还原规则版本,然后根据需要编辑规则,再次使用编辑的规则更新基线。完成并测试修复结果后,基线可冻结并重新部署到 QA 环境中。

此方法适用于应用于有限数量的规则和主要涉及规则中的简单值更改的快速、定义良好的补丁。对持续规则创作的影响很有限,因为只有需要修复的规则才会从基线还原。

还原开发基线

开发基线的一个主要功能是,它们可还原,这意味着基线的内容会覆盖当前项目状态的内容。您可以使用此功能来处理和编辑以前的项目状态,方法如下:

  1. 创建一个捕获当前项目状态的开发基线。
  2. 还原想要的开发基线并执行想要的更新、单元测试和部署。
  3. 完成后,创建一个捕获更新的项目状态的新基线。
  4. 最后,还原在第 1 步中创建的与当前项目状态有关联的基线。

与更新基线一样,您可以使用此方法进行故障修复。这种情况不涉及任何解冻工程,并且因为您使用的是当前的项目状态,因此所有规则都可一次获取,这方便了更新流程。因此,此方法可能更适合更重大的错误修复。

主要缺点在于,在修复缺陷的过程中,不能执行任何新规则创作操作,因为当前的项目状态反映了项目的历史版本。

使用 RuleStudio 同步

Rule Studio 中的同步机制是 Eclipse 中的规则项目与 RTS 存储库中的规则项目之间的桥梁。在规则项目的生命周期中,同步机制通常用于执行所有项目元素的全面发布(从 Rule Studio 到 RTS)或全面更新(从 RTS 到 Rule Studio),很少会涉及到对具体规则元素的任何有效选择或合并。主要的同步场景如下所示:

  • 在 Rule Studio 中完成了规则项目的初始设计后,项目会发布到 RTS,使之可供业务用户使用。
  • 当需要重组规则项目技术元素时(例如 BOM 更新、规则流更改等),会从 RTS 的 Rule Studio 中创建项目,执行想要的重组操作,最后将项目发布回 RTS。

这种类型的重组采用一种快速操作,在该操作完成之前,所有业务策略维护工作都会暂停。不幸的是,并不总是这样,尤其是在大型且复杂的规则项目上:重组可能是一个很长的操作,包含新 XOM 和 BOM 的设计和测试,而且生产维护必须继续并行进行。

所以,无需在需要重组时停止维护,可允许 Rule Studio 中的规则项目一直独立存在于 RTS 版本中,直到重组的项目准备好部署,如图 6 所示。

图 6. 使用 Rule Studio 管理规则项目版本
使用 Rule Studio 管理规则项目版本

请注意,此方法的主要问题是,Rule Studio 中的对比操作基于规则的 XML 序列化形式(如图 7 中所示),这使合并操作变得很脆弱,并且常常需要使用 IT 和业务资源。为了减轻合并的负担,采用增量式同步代替在末尾完整地同步可能是一种不错的做法。

图 7. Rule Studio 中的 BRL 对比
Rule Studio 中的 BRL 对比

使用 RTS 数据源

RTS Web 应用程序使用一个数据源来连接规则存储库数据库。您可以使用一个配置变量来更改数据源名称(该名称默认为 jdbc/ilogDataSource),这意味着您可以轻松地将 RTS 应用程序与不同的规则存储库实例相关联。

您因此拥有同一个规则项目的两个或更多副本,它们可独立地存在于两个独立的规则存储库中。各个项目之间的关系通过每个项目元素的 UUID 来建立和维护,这个 UUID 在元素的整个生命周期中保持不变。

您可以使用此方法来管理业务用户实现的并发规则项目增强。在 图 8 中所示的示例中,PROD RTS 表示被视为事实来源的规则存储库。在某个时刻,业务需要对其业务策略执行一项重大更改,这需要时间来分析、定义和测试,可能影响许多现有的规则。

要支持这种新开发,可使用一个独立的规则存储库 DEV RTS,通过 Rule Studio 同步将规则系统的当前状态导出到该存储库中。新开发完成后,会再次使用 Rule Studio 同步将这些状态发布回 PROD RTS。与上一节中介绍的重组相反,两个项目的合并通常更简单,因为不存在针对项目 BOM 或其他技术工件的底层更改。

图 8. 利用多个 RTS 数据源
利用多个 RTS 数据源

这种管理规则项目增强的方法的缺点是,每个不同的项目实例需要受不同的 RTS 数据库支持。

请注意,如果惟一的需求是拥有同一个规则项目的多个副本,并且 RTS 中的业务用户将把它们用作沙盒,但该内容从不会实际合并到生产项目,那么您可以在 Rule Studio 中创建项目副本并将这些副本发布到 RTS。Rule Studio 中的复制操作将负责更改项目元素的 UUID,因此在 RTS 中拥有项目的多个副本不会发生元素冲突。


使用 WebSphere Operational Decision Management V7.5 管理规则项目版本

在上一节中,您了解了处理规则项目版本的多种策略,每种策略适用于一种不同的用途。但是,每种策略都有一个缺点,需要复杂且容易出错的操作序列,这归因于一个基本的问题:RTS 不支持在其项目上使用分支的概念。

WebSphere Operational Decision Management V 7.5 在决策中心中引入了一种原生的分支功能(ex-RTS),为各种项目版本控制需求提供了直观的解决方案。

决策中心中的项目分支

分支是使用决策中心时不可或缺的一个部分。在开始任何工作之前,您需要选择目标规则项目,以及您希望在该规则项目中使用的分支。图 9 给出了决策中心的主页,您可以在其中进行此选择。

图 9. 决策中心主页
决策中心主页

默认情况下,一个规则项目只有一个分支,也就是 “主要” 分支。用户随时都可以从 “使用的分支” 创建一个子分支,只需在 Current action 菜单中选择 Create subbranch 操作,如图 10 中所示。

图 10. 创建子分支
创建子分支

当您需要合并并发项目分支时,Merge Branches 操作提供了一种用户友好的方式来执行合并操作。指定要对其执行合并的分支后,决策中心会显示要合并的区别集,提议要执行的可能操作(更换一个分支、更换另一个分支或什么都不做),如图 11 中所示。您可以选择想要的合并方向,以限制显示的区别集。

图 11. 合并分支操作
合并分支操作

如图 12 中所示,为每个工件提供了一个详细的区别视图,以协助合并任务的完成,并允许细粒度的区别管理。

图 12. 合并区别的细节
合并区别的细节

这关系到决策中心中的分支管理操作的范围。通过特意限制操作集,分支管理可尽可能保持非技术性,以便业务用户轻松使用和理解。

基线的概念在决策中心中仍然存在,但基线现在是项目状态的只读快照(基线无法再解冻)。基线的作用是表示:

  • 开发基线的一个指定的还原点,类似于 SCCS 的标记版本。
  • 一个可靠的部署状态,可用于通过不同的规则环境(从测试到生产)干净地进行升级。

管理错误修复

决策中心的分支功能使错误修复变得非常简单。假设一个新规则集版本的升级是通过创建一个名为 loanvalidation-1.0.0 的部署基线从主要分支发起的。

  1. 如果在升级到 QA 期间在规则中发现了一个缺陷,那么规则创作者可以将部署基线复制到某个分支,如图 13 中所示,并开始使用该分支来修复缺陷。
    图 13. Manage Subbranches and Baselines 页面的 Deployment baseline 部分
    Manage Subbranches and Baselines 页面的 Deployment baseline 部分
  2. 修复完成后,您需要定义一个新的 RuleApp,以便从新的分支进行部署,而不是从主要分支部署。Decision Management V7.5 中的规则集定义包含应该从中提取规则集的项目版本的规范。如图 14 中所示,该版本可是一个基线(比如 loanvalidation-1.0.0),也可是一个分支(比如 loanvalidation-1.0-bugfix)。对于我们的示例,我们将选择后者。
    图 14. 选择项目版本
    选择项目版本
  3. 您可以在错误修复分支上执行更多修复迭代,直到该版本准备好发布到生产环境中。在这时,要完成的最后一个任务是将来自错误修复分支的更改合并到主要分支。可使用 Merge Branches 操作完成此任务,如前面的 图 11 上所示。在本例中,我们将选择使用 Only to 'main' Branch 选项作为方向。

图 15 演示了这 3 个步骤。

图 15. 管理错误修复流程
管理错误修复流程

管理并发规则服务增强

项目分支也大大简化了对规则服务的并发增强。当提交对业务策略的一项更改时,您可以创建一个分支来实现和单元测试变更请求。当您准备好部署更改后,您可以将更新的项目元素合并回主要分支,部署更新的 RuleApp 后会创建一个部署基线。

图 16. 并发规则服务增强流程
并发规则服务增强流程

RTS 中引入的规则项目安全性概念现在在分支级别上进行管理。在包含来自多个 LOB 或业务组的业务策略的大型项目中,这支持事实现细粒度的安全保护,为某些组专门分配分支(例如图 16 中的 pricingeligibility)。

图 17 显示了决策中心中新的分支安全性选项。

图 17. 决策中心中的分支安全性选项
决策中心中的分支安全性选项

管理规则项目重组

规则项目重组(例如,包括更改 BOM)仍然是一个在规则设计器(以前称为 Rule Studio)和决策中心中一项共同的任务,类似于前面介绍的 JRules V7.1 重组流程。

决策中心中的合并操作不包括 BOM 或规则集参数。因此,在给定分支上对这些工件的更新必须通过规则设计器中的同步操作来完成。

重组流程按如下方式完成:

  1. 创建一个要作为临时生产分支的分支,以支持持续维护。
  2. 在规则设计器中,从决策中心项目的主要分支创建一个规则项目。
  3. 执行规则项目重组。在此期间,将通过临时生产分支来处理所有项目维护工作。在重组完成之前,主要分支上应该没有任何活动。
  4. 当重组完成时,将规则设计器项目与决策中心项目的主要分支同步,覆盖主要分支的内容。
  5. 将临时生产分支合并回主要分支。
图 18. 决策中心中的重组流程
决策中心中的重组流程

此场景中的主要优势是,合并操作使用了特定于规则的区别,而不是基于 BRL 格式的一般性文本区别,如前面的 图 7 中所示。


结束语

尽管分支的概念通常具有技术性,并且植根于软件开发文化中,但 WebSphere Operational Decision Management V7.5 的决策中心组件会尽力向业务用户隐藏其复杂性,为用户提供在管理基于规则的决策服务过程中实现最高敏捷性所需的能力。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=801495
ArticleTitle=BPM 观点:管理规则项目版本:在 WebSphere Operational Decision Management V7.5 中引入分支
publish-date=03122012