设计和实现决策服务的最佳实践,第 2 部分: 集成 IBM Business Process Manager 与 IBM Operational Decision Management

本系列的 第 1 部分 介绍了使用 IBM® Business Process Manager Advanced 和 WebSphere® Operational Decision Management 设计和实现决策服务的一些最佳实践。本文将介绍不同的开箱即用的 BPM 和 ODM 集成功能,并推荐一种为长期生产解决方案带来更高的性能和灵活性的方法。 本文来自于 IBM Business Process Management Journal 中文版

Jerome Boyer, 高级技术人员, IBM

Jerome Boyer 是一位 IBM 专家,精通 BPMS、SOA 和 Complex Event Processing 部署中的 Enterprise Business Rule Management 系统。Jerome 作为首席 ILOG BRMS Architect 领导 IBM Software Services for WebSphere (ISSW) 项目。他在设计、管理和开发大规模企业 IT 解决方案方面有超过 20 年经验,涉及的行业包括电信、金融、保险和电子商务市场。他参与了业务规则部署方面的大多数 ILOG 项目的技术和架构评估。Jerome 还设计了用于收集实现 BPM 的最佳实践的 ISIS 方法。


developerWorks 投稿作者

2013 年 5 月 13 日

概述

本系列的 第 1 部分 重点介绍了 SOA 服务层中与 BPM 分离的决策服务,并使用了一种具有有限载荷的粗粒度接口。这样做的目的在于实现可重用性,避免让 BPM 使用者将所有数据都发送给决策服务。BPM 和 BRMS 的信息模型不同;BPM 充当工作流编排层,没有承载与它使用的服务相同的结构和定义。决策服务是一个可重用的服务,不是为单个使用者而设计的。BPM 仍然是一个使用者,因此需要将 IBM Business Process Manager (IBM BPM) 与 IBM Operational Decision Manager (IBM ODM) 集成在一起。本文将介绍不同的产品集成功能,并提供有关使用它们的时机的一些条件。架构师需要评估其功能需求和非功能需求,选择最佳的解决方案。

从 2010 年 6 月开始,IBM BPM 和 IBM ODM(以前的 ILOG JRules)提供了开箱即用的集成功能,实现了顺利的集成。但是,在实现这些集成之前,需要考虑一些约束条件。最重要的约束条件与两个产品所需的信息模型密切相关。在 第 1 部分 中可以看到,业务流程管理变量可处理流程活动之间的信息,使用 coach 向人们提供信息或从人们那里获取数据。大部分时间,决策服务需要采用一种不同的数据模型,这种模型使用面向对象的分析方法根据域模型调整而来,添加了实用程序方法和算法操作,获得了一个比 BPM 所用图表更复杂的数据图表。该模型的目的在于更有效地执行规则,改善规则创作体验。IBM BPM 流程应用程序使用 JavaScript 变量在流程活动之间传递数据,BPM Advance Integration Service (AIS) 使用一个服务数据对象来管理数据,ODM 将本机使用 XML,甚至会使用 OPJO 类。还需要使用数据映射和技术映射。

在过去三年中我们看到,从流程中外部化规则处理的需求更高,两个最常见的需求是数据验证和富决策活动。数据验证规则常常埋藏于屏幕逻辑内,但也需要验证在流程中收集的所有数据,然后才能将它们保存到后端系统。富决策活动包括知识和主题专家会制定数据决策所用的每个人类任务。人们常常将流程流路由规则(网关节点)视为要外部化到 BPMS 中的规则,但是,事实上这是一种很少见的使用情形。其中大部分路由规则都很简单,表示有限数量的规则,在本质上是静态的。在 IBM BPM 中使用 JavaScript 实现这种路由逻辑要简单和快捷得多。对于数据验证,需求可分离为以下两类:

  • 在将数据输入表单中后立即验证它,以在同一个 coach 中获得错误消息。
  • 在所有数据收集活动结束时,用户会在业务数据提交到后端或下游流程时验证数据。系统会将一个错误列表报告给用户,以便能够修复数据。

图 1 显示了一个业务流程定义示例,演示了数据输入活动和后面的正式数据验证步骤,这个步骤建模为嵌套的服务。

图 1. 含有数据验证调用的人类服务
含有数据验证调用的人类服务

对于 coach 中的数据验证,目前的常见方法是在 coach 中使用 JavaScript 实现结构规则或业务规则,约束数据模型或用户界面。以下示例可通过在 coach 中向小部件控件添加逻辑来实现。

  • 如果损失类型为汽车事故,则需要选择一辆被保险的汽车,而且还必须提供事故位置地址。
  • 如果损失类型为火灾,那么至少需要选择一种被保险的财产。

在 Coach Designer 内,开发人员可以使用其他字段上的条件控制元素可视性。图 2 在索赔类型上将一个条件定义为 accident,以显示一个相应的字段。

图 2. 使用其他字段值控制可视性
使用其他字段值控制可视性

查看上述这些规则,显然它们也需要包含在流程中的最终验证步骤中。数据验证规则的外部实现可供应用程序的其他部分或其他使用者重用。因此,这些约束规则可编码到两个地方:用户界面和 BRMS。事实上,在一些解决方案中,BRMS 可支持两种情形,我们将在本系列的第 3 部分中介绍。另外,由于这些是可执行的规则,所以重要的是不仅要考虑规则的条件,还要考虑操作部分和执行上下文。UI 中的操作是在字段级显示一个错误消息,这会导致 validate data 决策服务拒绝索赔,并在一个列表中累积发现的所有问题。

本文中提供的示例利用了 IBM BPM V8.0.1 Advanced 和 IBM ODM V8.0.1,但所提供的大部分方法都可用于两个产品的 7.5 版。

当在 Process Designer 中设计一个业务流程模型定义时,流程开发人员可使用不同的集成功能与出站服务(比如决策服务)交互。当前的功能包括 Web 服务集成、Java 集成、Advanced Integration Services 和 BPM JRules 决策服务。


基本的索赔处理场景

为了演示本文中提供的不同示例,我们将使用一个针对汽车保险的基本的索赔处理应用程序。该过程首先是一组用于输入索赔数据的 coach,然后第一个系统车道活动将验证索赔,向索赔处理人员(流程参与者)报告任何错误,然后进入资格鉴定和判决步骤流程,这些也属于决策服务。顺利的话,随后将进入索赔支付和索赔备案步骤。我们至少需要考虑两个决策服务:一个用于数据验证,另一个用于判决索赔。规则优势使我们能够在验证中识别大约 100 条规则,在宣布步骤中识别至少 500 条规则。业务流程定义和决策服务的开发可以并行执行,而且大部分时间都需要不同的开发人员技能集:业务流程分析师定义 BPMN 流程定义,而规则分析师(常常是精通知识获取技术和知识表达的知识工程师)处理规则发现、分析和实现。另外,在业务端,流程负责人常常与业务规则负责人不同;例如,索赔处理流程负责人不负责判决规则,这由判决部门负责,风险管理规则也是如此。

两个团队的并行开发需要同步化。信息模型定义和决策服务规范代表两个主要元素,限制了产品之间的集成。


JRules 决策服务

IBM Process Designer 包含一项特殊服务(在流程应用程序库的 Decision 项中),用于调用一个托管的透明决策服务 (HTDS)。HTDS 是一个预定义的 Web 应用程序,它使用 WSDL 公开规则集,并提供一组服务,比如决策服务元数据访问和使用 JMX MBean 协议的运行时统计。URL 与 RuleApp 和规则集路径相匹配:DecisionService/ws/ClaimProcessingRuleApp/ValidateClaimRules?wsdl。HTDS 使用了一个逻辑执行单元 (XU),它是规则引擎的容器,部署在自己的服务器上。服务器物理资源可根据性能目标和可伸缩性需求进行调整。HTDS 仅支持使用基于 HTTP 协议的 SOAP 的远程调用。截至 JRules V7.1.1,HTDS 仅支持 XSD 和一个基本的 Java™ 模型,但从 Decision Server V7.5 开始,它支持将域模型的 Java 项目打包到归档文件 (JAR) 中,与 RuleApp 一起部署,所以可以 HTDS 支持富 Java 模型。Java 模型处理拥有比 XML 更高的性能,可帮助开发人员更灵活的创建规则。

图 3. 使用 XU 的 HTDS 可供不同的应用程序使用,比如 BPM 流程应用程序
使用 XU 的 HTDS 可供不同的应用程序使用,比如 BPM 流程应用程序

查看图 3 的放大版。)

在 IBM WebSphere ODM V7.5 之前,规则集从客户端应用程序(决策服务实现)类加载器中获取它们的 Java XOM 定义。在 ODM V7.5 及更高版本中,Java XOM 存储在规则执行服务器持久性层,是一个和 RuleApp 一样的可管理工件。从 Rule Designer 开始,您可以选择规则项目,并将 XOM 部署到一个规则执行服务器实例。这是一个非常重要的增强,但它没有消除将规则集签名暴露给 SOA 服务的问题。架构师需要花费一些时间来确定此服务需要按原样公开还是通过一个服务集成组件公开。服务设计的粒度是良好的 SOA 采用率的主要考虑因素之一。对于同一个规则集,常常会提供多个不同的操作。这些操作定义是决策服务的服务规范的一部分。HTDS 不支持此架构。

在使用 HTDS 时,需要调整设置来控制已生成的 WSDL 很重要(具体来讲,需要控制不同的 XSD 的命名空间)。可以在 RES 控制台中设置这些选项,如图 4 所示。

图 4. 确保命名空间之间的一致性
确保命名空间之间的一致性

当某个 BPM 流程应用程序是使用者时,它要做的第一件事就是在 Process Designer 中配置 RES 服务器 URL,方法是在 Process App Settings 中添加一个服务器定义,将 ILOG Rules Server 设置为类型,并在默认字段中指定 RES 控制台服务器 URL(不包含 RES Web 上下文名称),如图 5 所示。

图 5. 设置 RES 服务器 URL
设置 RES 服务器 URL

下一步是使用流程应用程序库中的 Decision 项添加一个决策服务客户端(例如 ValidateClaimDS)。在画布上,拖放一个 JRules 决策服务,并将它连接到开始和结束节点,如图 6 所示。在 Implementation 选项卡中,指定您前面定义的服务器配置,然后单击 Connect。当连接成功时,RESDB 中定义的所有 RuleApps 都会公开在一个单选列表中。选择 RuleApp,然后选择决策服务客户端将调用的规则集。

图 6. 在 Process Designer 中定义一个决策服务客户端
在 Process Designer 中定义一个决策服务客户端

注意:此功能仅在将 RES 部署在 WebSphere Application Server 上时有效。

下一步是获得预期的规则业务对象模型的定义(参阅 第 1 部分 了解不同模型的更多信息)。类型定义可能与流程应用程序中或链接的工具包中定义的现有业务对象相冲突。事实上,专注于支持 coach 实现以及在流程活动之间传递数据的流程应用程序中常常包含业务对象定义,这与通过导入 WSDL 定义的业务对象不同。业务流程开发人员会与研究自己的规则业务对象 (RBO) 模型的规则开发人员并行调整此模型。使用惟一的模型很难,但存在这个可能。在大部分实现中,需要使用映射。Process Designer 中的新服务的输入和输出参数会使用流程应用程序中定义的流程变量,而不是导入的变量,因为这项本地服务必须由人类服务或 BPD 使用。图 7 演示了私有变量正在使用导入的服务类型,而公共变量正在使用流程应用程序类型。私有变量可用作 HTDS 的参数。

图 7. 使用业务对象的外部参数,使用已导入的模型的内部私有参数
使用业务对象的外部参数,使用已导入的模型的内部私有参数

查看图 7 的放大版。)

值得注意的是,JRules 决策服务的参数包括一个记录决策 ID 的字符串,在规则集参数上使用了包装器。决策 ID 用于将流程实例与 ODM Decision Warehouse 中使用的决策 ID 相关联,所以一个给定的索赔业务用户可获得所执行的规则名称。此功能有助于回答问题:为此流程实例执行了哪些规则?我更喜欢使用 claimNumberpolicyNumber 作为决策 ID,因为这些标识符是业务键。当一位呼叫中心代表接到索赔者的电话时,他或她使用索赔编号获取有关索赔的信息,也可获得在判决步骤中执行的规则,因为这些规则是从决策仓库和决策中心加载的。

数据模型映射在系统通道服务的实现内使用服务器端脚本完成,所以该图类似于图 8。

图 8. 决策服务客户端实现中的映射
决策服务客户端实现中的映射

每个服务器脚本都使用 JavaScript 执行映射。这是一段复杂的代码,可能成为一项真正的挑战,因为为规则处理准备数据可能涉及到从外部数据源加载。作为一个具体示例,coach 可支持输入策略编号,所以 ClaimBO 有一个属性 policyNumber(一个字符串),而规则处理中的 ClaimRBO 有一个 InsurancePolicy 引用,其中包含覆盖范围、免赔额、保险财产等。因此,准备 RBO 的步骤不仅仅是在两个复杂类型之间建立映射,还要从记录系统或数据访问层加载数据。事实上,这应该是集成层的工作。IBM BPM Advanced 支持使用 BPEL 或中介流的有效集成逻辑。

您需要将此集成功能用于快速演示和概念证明,或者在 BPM 流程应用程序和系统通道活动能够将所有数据发送到规则处理功能时使用。架构师和服务设计者更喜欢控制他们的业务服务接口定义,实现自己的数据访问。


单一模型开发

外部服务的一个问题是在 IBM BPM 中执行信息映射。事实上,通过在早期项目迭代中提前定义信息模型,可以限制数据映射的数量。不是每种类型都可以定义,但许多类型都是众所周知的,并且已经被定义:大部分 BPM 和 ODM 部署用于重新设计现有的业务应用程序,所以数据模型可能有一部分源于它们。Address、Customer、Person、LegalEntity 和 Coverage 等类型都具有明确的定义。Claim、InsurancePolicy 等类型可能在开发流程应用程序时并未全面定义;因此,它们的定义可能在项目实现过程中不断更改。定义良好的类型可使用从 BPM 工具包导入的现有 XSD 快速描述。您可以从 XSD 开发 WSDL,将它们导入 Process Designer 中,以便生成某个工具包中的业务对象。WSDL 不需要处于在线状态,文件 URL 很有效(例如 //localhost:/C:/workspaces/abrd-claim-ws/claim-model/src/wsdl/ClaimManagerModule.wsdl)。

第 1 部分 中可以看到,选择 UML => XSD => java bean 是一种为信息模型设计和生成代码的非常高效的方法。开发流程可能类似于图 9。

图 9. 定义业务对象的工具和元素
定义业务对象的工具和元素

从 XSD 使用 XJC JAXB 工具,您可以生成带有注释的 Java 类,并将它们加载到 Rule Designer 中,以便定义 BOM 和规则词汇表。这只是众多方法之一,不应将它视为惟一途径。在类需要使用业务逻辑时,建议拥有单纯的 Java 类。决策服务接口使用 JAXWS 注释定义作为 Java 接口,而且将生成 WSDL。WSDL 可导入到 Process Designer 中,以便在一个可重用的工具包中创建数据定义(业务对象)。此方法可在执行大量 coach 开发之前尽早使用。当一些业务对象未全面定义时,或者在服务生成者与 BPM 工作流之间存在具有很大差异的语义时,每个开发人员都可以开发他们自己的模型,BPM 开发人员需要在业务对象和 Service Exposition Model 之间实现映射。


Java 实现方法

最灵活的方法是将决策服务实现为一个 Java 模块,它并不比其他方法复杂。正如第 1 部分中的 实现决策服务 中所描述的那样,该方法是设计一个负责管理主要业务实体的模块(例如由 ClaimModule 管理的索赔)。业务接口的定义定义了决策服务操作(例如 validateClaimadjudicateClaim),如以下清单所示。

@WebService (name = "ClaimManagerService", targetNamespace = "http://abrd.org/claim/serv")
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL, 
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface ClaimManager {
	public Claim getClaimByNumber(String claimNumber);
	
	public void updateClaim(Claim claim);

	public void saveClaim(Claim claim);
	
	// -- Decision service operations	
	public ValidationResult validateClaim(Claim claim);
	public ValidationResult validateClaimByNumber(String claimNumber);
	
	public ValidationResult adjudicateClaim(Claim claim);
	public ValidationResult adjudicateClaimByNumber(String claimNumber);

该实现使用了 Java 和 RES API(参见 第 1 部分,获取有关的代码示例)。如上面的接口定义所示,可以为每个操作提供不同的参数来支持不同的使用者模型:从能发送所有数据的模型到仅发送主键的模型。该模型负责根据需要加载数据,这些数据中包括管理缓存、引用数据等。

@WebService(serviceName="ClaimManagerService",
		portName = "ClaimManagerPort",
		endpointInterface = "abrd.claim.services.ClaimManager",
		targetNamespace = "http://abrd.org/claim/serv")
public class ClaimManagerImpl implements ClaimManager{
….
public ValidationResult adjudicateClaim(Claim claim) {
		return claimProcessingDS.adjudicateClaim(claim);
	}

模块被打包为一个非常简单的 WAR,它仅有一个与 jrules-res-session-java.jar 有关的依赖关系和规则业务对象模型 JAR(在 WEB-INF/lib 下)。ant 目标如下所示:

<war destfile="${build.dir}/${war.name}" needxmlfile="false">
	<webinf dir="${src.webcontent}/WEB-INF" includes="*.xml" />		
	<classes dir="${build.classes}" /> 		
	<lib dir="${src.webcontent}/WEB-INF/lib">
		<include name="*.jar" />
	</lib>
	<fileset dir="${src.webcontent}">
		<include name="*.html"/>
	</fileset>
</war>

web.xml 引用了服务实现 Java 类,servlet 名称映射到 JAX-WS 注释中定义的服务名称。重要的是添加 resource-ref 元素来声明规则执行所需的 XU 连接工厂的 JNDI 名称,以及加载规则集所需的 RESDB 数据源。

<display-name>Claim Manager Module</display-name>
<servlet>
	<servlet-name>ClaimManagerService</servlet-name> 
	<servlet-class>abrd.claim.services.ClaimManagerImpl</servlet-class> 
</servlet>
<servlet-mapping>
	<servlet-name>ClaimManagerService</servlet-name> 
	<url-pattern>/serv</url-pattern> 
</servlet-mapping>
<welcome-file-list>
	<welcome-file>index.html</welcome-file>
</welcome-file-list>
<resource-ref>
	<res-ref-name>jdbc/resdatasource</res-ref-name>
	<res-type>javax.sql.DataSource</res-type>
	<res-auth>Container</res-auth>
	<res-sharing-scope>Unshareable</res-sharing-scope>
</resource-ref>
<resource-ref>
	<res-ref-name>eis/XUConnectionFactory</res-ref-name>
	<res-type>javax.resource.cci.ConnectionFactory</res-type>
	<res-auth>Application</res-auth>
	<res-sharing-scope>Unshareable</res-sharing-scope>
</resource-ref>

ra.xml 是资源适配器描述符文件,需要指向 RESDB 数据源。此文件位于 WEB-INF 下的 WAR 中。

<config-property-name>persistenceType</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>datasource</config-property-value>
</config-property>
        <config-property>
<config-property-name>persistenceProperties</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>JNDI_NAME=jdbc/resdatasource</config-property-value>
</config-property>

最后,在将 WAR 部署在 WebSphere Application Server 上时,确保已将它部署为 Web 服务,将 web.xml 中定义的资源引用链接到 WebSphere Application Server 中配置的 JNDI 名称,如图 10 所示。

图 10. 链接依赖的资源
链接依赖的资源

在 BPM 端,使用的方法是使用 Web 服务集成。WSDL URL 拥有以下结构:
<hostname>:<port>/<webappcontext>/<servlet_url_mapping>/<servicename>.wsdl

出于前面解释的原因,仍然需要模型之间的映射。如图 11 所示,可使用一个仅提供索赔编号的简单操作。该过程将索赔保存到记录系统中,并获取惟一 ID,判定或验证决策服务操作从这个后端加载数据。

图 11. Web 服务客户端配置
Web 服务客户端配置

目前提供的两种集成使用了部署在自己的远程服务器上的规则执行服务器,如 图 3 所示。此方法最为灵活,使开发人员能够实现一组丰富的决策服务操作,并提高了可重用性。数据缓存和数据加载可以使用 Java 实现进行调优。


SCA 集成:Advanced Integration Service 方法

AIS 是在 BPM 和 ODM 之间实现集成的另一个选项。在 Process Designer 中,开发人员使用库元素 Implementation > Advance integration service 定义高级集成服务,如图 12 所示。

图 12. Process Designer 中的 AIS
Process Designer 中的 AIS

该实现在 IBM Integration Designer 中完成,可使用 BPEL、中介流或 Java 实现。借助此集成类型,可以将 ODM 规则执行单元 (XU) 部署到应用程序集群服务器中的流程服务器上,如图 13 所示。任何使用 BPEL、中介流、JAX-WS 或 HTDS 的决策服务实现都可以一同部署在应用程序目标集群上。RES 控制台部署在支持集群中。

图 13. 位于同一位置的执行单元
位于同一位置的执行单元

当使用 IBM BPM 时,SCA 运行时和 BPEL 引擎等组件会添加到 AppTarget 集群中(位于一个 4 集群拓扑结构中),或者部署在用于服务模块的第五个集群中。在最后一种情况中,ODM XU 和 HTDS 部署在这个服务集群中。主要的原则是将规则引擎池和决策服务放在同一个 JVM 中。在这种情况下,此决策服务是一个 SCA 组件。更确切地讲,服务 SCA 模块被打包为 EAR,决策服务是其中的一个 JAR 文件。作为一个纯 Java 组件,在 SCA 外的其他组件中重用 Java 决策服务很容易。

当 XOM 基于 Java 时,集成开发人员需要将 SCA 中使用的服务数据对象映射到 Java Beans。决策服务操作的 Java 实现代码有一个 SDO 参数和 SDO 返回类型,如下所示。

public DataObject adjudicateClaim(DataObject claimSdo) {
     
// ..
     Claim aClaim = convertSDOClaim(claimSdo);
// RES session api code …
AdjudicationResult result = (AdjudicationResult) outputParameters.get(“result");
DataObject response = createSDOResponse("http://model.isis.ibm.com",
     result);

您可以使用 BOFactory API 实现您自己的映射,以便从 Java Bean 映射到 SDO。您需要掌握足够多的 DataObject API 知识。以下是将一个 SDO 索赔数据对象映射到一个索赔 RBO,并使用 BOFactory 创建一个结果 SDO 对象的代码示例。

Claim claim = new Claim();
claim.setClaimNumber(claimBO.getString("claimNumber"));
claim.setDateOfLoss(claimBO.getDate("dateOfLoss"));
// use DAO to access the insurance policy
InsurancePolicy policy = dao.loadInsurancePolicy(claimBO.getString("policyNumber"));
claim.setPolicy(policy);
// build response from ValidationResult RBO
com.ibm.websphere.bo.BOFactory boFactory = (com.ibm.websphere.bo.BOFactory) 
ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo/BOFactory");
DataObject validationResult = boFactory.create("http://abrd.org/claim/serv",
"validationResult");
validationResult.setBoolean("error", result.getError());
// ...

规则服务的 Java 实现使用 POJO RES 会话与规则引擎进行交互。此实现强制使用一个本地调用来处理规则,这是目前最有效的方法。当 XOM 基于 XSD 时,更好的实现方法是使用 BPEL。

图 14 演示了一个包,其中包含一个决策服务 Java 实现、索赔管理服务的一个 DCA 模块、一个用于本地访问不同的索赔数据库表的数据访问对象 (DAO),以及与 SCA 运行时和流程服务器 (BPEL) 位于相同节点上的 RES XU。

图 14. 将决策服务 Java 实现打包为 SCA 模块
将决策服务 Java 实现打包为 SCA 模块

本系列的第 3 部分将介绍一种将 SDO 用作 ODM 的 XOM(所以不需要映射)的方法。


Java 集成方法

IBM BPM 的一项有趣功能是定义您自己的 Java 集成的能力。定义 Java 集成的方法是定义一个 Java 类,这个类支持决策服务操作(比如验证索赔和判决索赔)的 Java 实现,如下所示。

publicclass ClaimDecisionService {
    protected RuleProcessingImpl rp;
	
    public ClaimDecisionService(){
    	rp= new RuleProcessingImpl();
    }
    
	public TWObject validateClaim(TWObject claimBO) { …
      public TWObject adjudicateClaim(TWObject claimBO) { …

有趣的部分是参数。方法参数和返回的类型只能是基本的 Java 包装器类(java.lang 包中的类)、jdom.Documentjdom.Element,或者 BPM 类型(比如 TWObjectTWList)。TWObject 表示流程应用程序或工具包中定义的复杂数据类型。当流程变量是一个列表时,将它映射为 teamworks.TWList。在此方法中,返回的类型在 Process Designer 中被声明为 ValidationResult,输入参数被声明为 Claim complex type

图 15. 参数被声明为复杂类型
参数被声明为复杂类型

当服务使用 Java XOM 时,实现类需要在 TWObject 和 Java bean 之间建立映射。该代码了使用 TWObjectFactoryTWObject API,如下面的代码所示。

TWObject result = null;
TWList issues=null;
try {
	result = TWObjectFactory.createObject();
	issues = TWObjectFactory.createList();
	result.setPropertyValue("issues",issues);
	// do mapping 
	Claim claim = new Claim();
	claim.setClaimNumber((String)claimBO.getPropertyValue("claimNumber"));
	claim.setType(ClaimType.fromValue((String)claimBO.getPropertyValue("type")));
	claim.setDateOfLoss((Date)claimBO.getPropertyValue("dateOfLoss"));
	// ..
	ValidationResult resultOut=rp.validateClaim(claim);
	// map result and claim
	for (Issue i: resultOut.getIssues()) {
		issues.addArrayData(i.getMessage());
	}
// …

TWObjectTWObjectFactory 定义位于文件夹 <was.home>/BPM/lombardi/lib 中的 pscInt.jar 中。

完成代码后,您需要将代码和所依赖的所有类打包在一个 JAR 中,然后选择 Library => File => Server File 将它上传到您的流程应用程序或工具包中。上传之后,您需要创建一个集成服务,可以使用面板中的 Java Integration,如图 16 所示。在定义属性中,可以指定您上传的 JAR 中包含的类,选择服务需要使用的方法。

图 16. 使用一个 Java 决策服务和一个 RES API 的 Java 集成
使用一个 Java 决策服务和一个 RES API 的 Java 集成

查看图 16 的放大版。)

在 Java 方法返回一个与 Java Bean 规范相关的复杂类时,勾选 Translate JavaBeans 很有帮助。此标志会导致集成层将返回的数据图表整理为一个 XML 文档,该文档可映射到 XMLElement 流程变量。

如上一个代码清单所示,该方法被委托给了规则处理类,这个类本身使用了 RES API(请参阅 第 1 部分 获取代码示例)。规则集部署在 RESDB 数据库中,RES 会话将访问部署在 Process Server 中的 XU。该拓扑结构与 图 13 中所示的拓扑结构相同。

此方法强制编码从 TWObjectTWList 到 Java bean 以及反方向的所有映射。该代码容易出错且很复杂。另一种方法是使用一个作为字符串传递的 JSON 文档或 XML 文档,或者使用一个作为参数和返回类型的 XMLElement,然后将它们整理到 Java bean 中(例如使用 JAXB)。另一个解决方案是使用 TWObject 作为一个 XOM 类。这将在本系列的第 3 部分中介绍。

规则执行服务器在 Process Server 中的联合部署可避免为远程调用序列化数据并提升性能。但是,为支持 Process Server 而定义的物理资源对于规则处理而言可能有些大材小用,并会影响解决方案的部署成本。


结束语

集成 IBM BPM 与 ODM 的推荐方法(提供了更高的性能、更严格的控制和更高的灵活性)是将决策服务用于一个使用 JAX-WS Web 服务技术和 Java XOM 公开的 Java 实现。借助此方法,您可以控制服务公开模型,实现粗粒度操作,让服务负责管理自己的数据访问战略。决策服务中的多个操作可在同一个规则集上实现。此方法非常适合面向对象的架构 (SOA),容易开发,而且可隔离测试。规则处理服务器是集中化的,可对云部署使用虚拟化。相同的 Java 代码可使用 RESTful 服务公开,所以协议的选择不会影响实现。

IBM BPM 拥有一个庞大的集成功能面板,集成方法的选择将取决于服务设计、实现方法和需求。在 IBM BPM 中,Web 服务使用是最灵活的、独立于服务器的部署模型。因为所有这些功能都非常容易使用,所以我建议设计每种集成功能的原型,以评估最适合您需求的功能:没有万能的功能。

再次声明,最敏感的主题是信息模型和如何重用一些更稳定的实体,而不是为您的问题定义实体。

在本系列的最后一部分中,我将介绍 RESTful 决策服务、服务数据对象 (SDO)、TWObject 和中介流。

参考资料

学习

获得产品和技术

讨论

条评论

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=929470
ArticleTitle=设计和实现决策服务的最佳实践,第 2 部分: 集成 IBM Business Process Manager 与 IBM Operational Decision Management
publish-date=05132013