在 IBM Operational Decision Management 中实现高级规则治理

本文将介绍基于规则的规则治理设计模式。该设计模式可以应用于所有版本的 IBM® Operational Decision Management,以提高决策中心治理的灵活性和能效。您可以基于该模式构建自己的实现,也可以与作者联系,获得有关 IBM 规则治理资产的详细信息。 本文来自于 IBM Business Process Management Journal 中文版

Nigel T. Crowther, 高级 IT 顾问, IBM

Nigel T. Crowther 是 IBM Software Services 中负责 WebSphere BPM Practice 的一名高级 IT 顾问,专攻业务规则。他在设计和开发业务规则与业务流程管理系统方面有 10 多年的经验,在 IT 领域有 25 年的经验。Nigel 参与过所有业务领域的工作,他的工作重点主要在财务系统上。Nigel 于 2009 年因 ILOG 收购而加入 IBM。



2013 年 8 月 22 日

引言

本文将介绍高级治理解决方案的 IBM ODM 治理框架。本文基于可配置的 Java 业务逻辑(如规则治理产品示例所示)提供了常用规则治理实现的一个灵活替代方案。我们将展示,使用规则(而不使用 Java)治理更改流程可在 ODM 中提高高级治理的能效和灵活性。

对于更改活动的治理,我们建议您查看一下ODM V8.5 中新增的治理功能。


规则治理示例

产品示例中提供的治理扩展的架构如 图 1 所示。本示例的核心是会话控制器,它根据状态提供访问权限。决策中心提供了一个自定义会话控制器,名为 WorkflowSessionController,它扩展了 IlrDefaultSessionControllerWorkflowSessionController 替代诸如 checkUpdatecheckCreatecheckDelete 之类的方法来执行治理操作。

该架构的限制如下:

  • 状态库权限由嵌入到决策中心 EAR 中的文本配置文件控制。如果不重新部署 EAR,则无法应用配置更改。
  • 采用 Java 实现自定义业务逻辑。由于实现和测试 Java 更改非常昂贵,因此可能需要与每个新版本的 ODM API 合并。此外,还需要针对节点的每个更改来重新部署决策中心 EAR。
  • 项目访问是通过组合两个不同的角色概念来控制的:功能角色和项目角色。这可能会导致角色激增。有关此内容的详细信息,请参阅 分配角色 部分。
图 1. 规则治理 ODM 产品示例的架构
规则治理 ODM 产品示例的架构

基于规则的规则治理

考虑以下场景:如果您将 EAR 文件中的治理逻辑委派给一个决策服务(如 图 2 所示),会出现什么情况。

图 2. 规则治理决策服务
规则治理决策服务

图 2 中的架构假定决策中心与决策服务器位于相同的应用程序服务器上,以便允许进行本地 POJO (Plain Old Java Object) 调用。另一个方法是将 J2SE 规则引擎嵌入到决策中心 EAR 中。如果决策中心没有访问决策服务器的权限,则会使用该方法。

治理决策服务和治理会话控制器之间的参数接口是通过常规的规则集签名模式来实现的。该模式能够更改规则模型 (.brmx),无需重新部署决策中心 EAR。使用映射到规则模型的 Excel 动态域来构建对象模型。有关常规规则集签名模式的详细信息,请参阅 WebSphere Operational Decision Management V7.5 的常规规则集签名模式简介,第 1 部分

治理规则流

治理决策服务中的规则流如 图 3 所示。它分为六个子流,这些子流很大程度上与会话控制器方法是相对应的。

图 3. 治理规则流
治理规则流

六个子流的用途如下所示:

  • Roles:返回功能角色
  • Status:返回提供产品当前状态的状态转换
  • Permissions:确定角色产品的创建/更新/删除权限
  • Committed:发生提供提交前和提交后状态的通知消息
  • Validation:验证规则和规则元数据并返回错误。
  • StyleCheck:对规则进行样式检查并返回警告。

在以下小节中,我们将查看这些操作。


角色

决策中心中的角色权限适用于所有项目。定义项目访问权限的方法是为每个项目和功能创建组合角色。例如,对于 Tester 的功能,项目 LoanValidation 将生成 TesterLoanValidation 角色。两个名为 LoanValidation 和 Annuity 的项目和两个名为 Tester 和 Author 的功能将生成以下组合角色:

  • AuthorLoanValidation
  • TesterLoanValidation
  • AuthorAnnuity
  • TesterAnnuity

我们将为 TesterLoanValidation 角色分配一个访问 LoanValidation 项目的 tester。此外,还将为 TesterAnnuity 角色分配一个访问 Annuity 项目的 tester。并为 TesterLoanValidation 和 TesterAnnuity 角色分配允许访问这两个项目的一个 tester。

对许多项目采用该方法可能会导致角色激增。例如,6 个功能角色和 10 个项目将需要 60 个角色。

一个简单的方法是拆分项目角色和功能角色,然后限制决策中心安全模型只对项目角色进行操作,并且限制治理决策服务只能对功能角色进行操作。图 4 演示了功能角色和项目角色的分离。

图 4. 角色的分离
角色的分离

项目角色和功能角色的实现非常简单。只需在决策中心中分配项目角色即可,如 图 5图 6 所示。

图 5. 为 LoanValidation 项目分配项目角色
为 LoanValidation 项目分配项目角色
图 6. 为 Annuity 项目分配项目角色
为 Annuity 项目分配项目角色

在规则治理中分配功能角色,如 图 7 所示。现在,项目访问由决策中心确定,功能访问由下一部分所述的规则治理权限规则确定。

图 7. 在规则治理中分配功能角色
在规则治理中分配功能角色

权限

如上一小节所述,我们使用决策中心安全模型来确定项目访问并委派对规则治理的细粒度访问权限。这样做不仅允许我们将功能角色与项目角色分离,还允许我们分配细粒度访问权限。例如,您可以根据规则状态、文件夹、规则名称和过期日期来限制访问。

图 8 中,允许作者在 newdefinedcancelled 状态中更改决策表属性,但只能在 new 状态中更改规则主体 (definition)。

图 8. 权限决策表
权限决策表

状态

图 9 中的图显示了规则作者的状态转换。在 图 10 所示的决策表中实现转换。

图 9. 状态转换图
状态转换图
图 10. 决策表中定义的状态转换
决策表中定义的状态转换

您可以看出,在图 10 的第一行中,新创建的规则被设置为 new 状态。在第二行中,作者被限制为从 new 转到 definedcancelled 状态。


验证规则

治理验证规则制定了谁可以做什么,并阻止在发生错误时提交规则。图 11 显示了一个治理验证规则,该规则阻止作者测试他自己的规则。当某个用户同时被分配了 Tester 和 Author 角色时,可能会出现这种情况。作者测试他或她自己的规则是不可取的行为,因为这违背了 “四眼 (four eyes)” 原则。

图 11. 阻止作者测试他或她自己的规则的规则
阻止作者测试他或她自己的规则的规则

图 12 中的治理验证规则阻止用户在不使用文档的情况下提交规则。

图 12. 阻止作者不使用文档进行保存的规则
阻止作者不使用文档进行保存的规则

样式检查规则

样式检查规则将会检查可能存在的问题而不是错误。和验证规则不同,样式规则并不阻止用户保存规则,而只是创建一个警告消息。由作者以及最终的审稿人来决定是否应该采纳警告建议。图 13 显示了实施命名标准的一个样式规则。该标准要求规则名称以大写字符开头,后跟一个或多个小写字符或数字。

图 13. 实施命名标准的样式规则
实施命名标准的样式规则

如果某个名称违反了这个惯例,则会在 Warnings 属性字段中显示一条警告消息。在 图 14 中,用户输入了一个包含美元符号的无效规则名称。这由 图 13 中的名称验证规则进行检测,并将结果写入 Warnings 属性字段。

图 14. 警告消息
警告消息

为了进一步突出显示此问题,Rule Explorer 视图中会显示一个警告符号,而且警告消息将会位于工具提示中,如 图 15 所示。

图 15. Rule Explorer 中的警告标志
Rule Explorer 中的警告标志

样式规则的其他示例如下:

  • 列名称的命名标准
  • 决策表最大行数限制
  • 决策表单元值最大长度限制
  • 决策表中数值的阈值

图 16、图 17、图 18 和图 19 中分别显示了这些规则的示例。

图 16. 检查决策表是否包含无效列名的样式规则
检查决策表是否包含无效列名的样式规则
图 17. 检查决策表是否包含太多行的样式规则
检查决策表是否包含太多行的样式规则
图 18. 检查决策表单元值是否超过 16 个字符的样式规则
检查决策表单元值是否超过 16 个字符的样式规则
图 19. 检查更改是否在阈值限制之外的样式规则
检查更改是否在阈值限制之外的样式规则

提交的规则

提交的规则在 onCommit 事件上调用,用于确定是否应该设置通知。通知可以是电子邮件、SMS 或对数据库进行的写入操作。图 20 显示了一个从 NewDefined 的状态转换,用于触发一封电子邮件。触发规则如图 21 所示。

图 20. 电子邮件通知
电子邮件通知
图 21. 电子邮件通知规则
电子邮件通知规则

IBM ODM 规则治理资产

本文中所述的所有功能以及更多功能都是在 IBM 规则治理资产中实现的。该资产为高级治理实现提供了一个可自定义的治理解决方案。有关详细信息以及如何获得该资产,请与作者联系。


结束语

本文介绍了一个基于规则的规则治理设计模式,该模式使用业务规则(而不是 Java)来提高决策服务器治理实现的灵活性和能效。


致谢

作者想感谢 Pierre Berlandier 和 Jonathon Carr 对本文的审阅。

参考资料

学习

  • developerWorks BPM 专区:获取有关 IBM BPM 解决方案的最新技术资源,包括下载、演示程序、文章、教程、事件、网络广播以及更多内容。
  • IBM BPM 期刊:从这个季度性期刊中获取有关 BPM 解决方案的最新文章和专栏,这里还提供了 Kindle 和 PDF 版本。
  • IBM developerWorks 中国 WebSphere 专区:为使用 WebSphere 产品的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库,包含 2000 多份技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。

获得产品和技术

讨论

条评论

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=941856
ArticleTitle=在 IBM Operational Decision Management 中实现高级规则治理
publish-date=08222013