使用 Web 服务在 IBM Business Process Manager 中实现协商过程

学习如何使用 IBM Business Process Manager 中的秘密代理 (UCA)、处理器和 Web 服务来实现与外部系统的协商过程。BPM 流程将公开一个可被另一个系统调用的 Web 服务。直到获得批准或遭到拒绝,协商才会停止。 本文来自于 IBM Business Process Management Journal 中文版

Mohamed Jawahar Husain, 软件工程师, IBM

Jawahar Husain 的照片Jawahar Husain 是 IBM 印度软件实验室的一名软件工程师。他是 Developer Services 团队的一名成员,负责为众多合作伙伴和客户提供应用程序基础架构和业务集成解决方案方面的咨询。Jawahar 擅长的领域包括 Java/J2EE、WebSphere Application Server、Process Server、MQ、Message Broker 和 BPM。



Gowdhaman Jayaseelan, 集成架构师, IBM

Gowdhaman Jayaseelan 的照片Gowdhaman Jayaseelan 从事 IT 行业已有超过 12 年的时间,他是一名应用程序集成架构师和 IBM Software Group 中 Worldwide WebSphere Business Partner Team 的 WebSphere Cast Iron 与 BPM 咨询师。他目前的职责是组建 WebSphere CoEs、Tech Talks、Sales Plays 等,推广业务合作伙伴在 IBM BPM 与 WebSphere Cast Ironconsultant 中的技术社区。他擅长的领域包括 WebSphere ESB、WebSphere Adapters、WebSphere Process Server、WebSphere MQ 和 WebSphere CastIron。



2013 年 5 月 21 日

简介

本文向您展示了如何使用 IBM Business Process Manager (IBM BPM) 在业务活动中实现协商过程。不同实体之间的协商对于业务流程的关闭至关重要。我们提供的示例场景是一个简单的贷款处理系统,但在日常的业务通信中,也可以使用类似的设计。这里使用的一些关键设计技术包括:如何在一个与 IBM BPM 进行通信的外部系统中实现这个过程,业务对象的状态维护,以及两方以上的协商。


业务场景

我们将要使用的场景如下:

  • 一家金融机构,比如银行,根据客户的定期存款最多可以贷出 100,000 美元(假设客户的定期存款超过 100,000 美元)。
  • 如果请求的贷款少于 100,000 美元,那么贷款请求会自动获得批准。否则会将请求递交给审批人员进行进一步复核和审批。
  • 审批人员可决定采取以下行动之一:审批、拒绝或协商。如果审批人员希望进行协商,那么将使用新的最大贷款数量和支持说明来更新贷款请求,并以此作为一个新的提议。
  • 贷款申请人现在可以接受或反对这个提议。这次协商将持续到审批人接受或拒绝贷款请求为止。

技术概览

本文并没有专注于表示逻辑 (presentation logic),而是重点介绍了用于外部系统与处理引擎之间的沟通的设计模式。下面对技术流进行了说明:

  • 申请人通过用户界面提交一份贷款请求表单,其中包含姓名、地址、联系方式、固定存款帐号、请求的贷款额度等,该界面使用了默认的 IBM BPM Coach。
  • 一个自动化决策网关将会检查所请求的贷款额是否少于 100,000 美元。如果请求少于 100,000 美元,那么请求将会获得自动批准;否则会将请求指派给经理/审批人,由他决定是批准、拒绝还是协商该请求。
  • 审批人应采取相应的措施,如果他决定进行协商,那么将使用新的最大贷款数量和说明来更新贷款请求,而且贷款申请人会获得通知。
  • IBM BPM 运行时等待贷款申请人通过一个中间的消息传递事件来做出响应。
  • 申请人需要响应由审批人提出的新提议。为了演示 IBM BPM 中秘密代理 (UCA) 与中间消息事件功能的用法,我们假设贷款申请人可以使用外部应用程序进行协商。外部应用程序与 IBM BPM 运行时之间的交互使用了 Web 服务。因此,我们将重点介绍交互,而不是外部应用程序的用户界面。
  • 在本文中,我们将使用 SOAP 客户端(SOAPUI 或 Rational Application Developer Web Services Explorer)将 Web 服务请求传递给 IBM BPM 运行时。贷款申请人通过 Web 服务调用将响应发送给审批人。申请人的响应被路由到审批人,这种循环将继续,直到审批人接受或拒绝贷款请求。

关键概念

  • 用户任务是以人为中心的活动,要求人参与流程并提供主张和完成活动。用户应该有权访问相应的活动,如果活动有效,那么用户必须在流程流转到下一活动之前完成相应的活动。
  • 网关用于根据某些条件划分或聚合多条执行路径。
  • 中间的消息传递事件用于建模一个流程(处于执行状态)与外部事件(通过 Web 服务调用或 Java™ Messaging Service 触发)之间发生的事件。
  • 中间的消息传递事件必须附加到一个 UCA 上。从外部系统收到消息时,UCA 必须初始化中间过程。消息可以通过 JMS 或 Web 服务触发。
  • UCA 与 Web 服务处理器对于定义参数、路由和消息传输是必需的。

业务场景的实现

业务场景的实现包含以下高级任务:

  1. 定义业务流程。
  2. 定义业务对象。
  3. 定义和实现活动。
  4. 测试应用程序。

本文中以 可下载的 .twx 文件 的形式提供场景实现。在继续本文中的步骤之前,请下载这个 .twx 文件并将其导入 IBM BPM V7.5.1 或其更高版本中,然后才能继续后面的操作。

请注意:该应用程序已经在 IBM BPM V7.5.1 和 IBM BPM V8 上测试过。


定义业务流程

在将 twx 文件导入 Process Center 之后,在 Process Designer 中打开 Banking-Solution (BANKING) 应用程序。在左侧的窗格中,单击 Processes 并查看名为 BankingSolution 的业务流程定义 (BPD)。我们将在 定义和实现活动 一节中讲述如何实现 BPD。

下面的内容将描述如何实现场景。


定义业务对象

本文为这个应用程序定义了两个业务对象。您可以在 Process Designer 中的 Data 下找到它们。这两个业务对象分别是 LoanRequest 和 StatusUpdates。

申请人使用 LoanRequest 对象来提交请求。

表 1. LoanRequest 业务对象、其字段和数据类型。
字段类型
RequestIdInteger
FDAccountNoInteger
NameString
AddressString
BirthDataDate
LoanAmountDecimal

StatusUpdates 用于持久保存审批人与贷款申请人之间的历史和通信记录。RequestId 用作关联标识符,惟一地标识 IBM BPM 运行时中的当前流程实例。RequestAmount 表示申请人请求的贷款金额,而 ProposedAmount 表示银行准备提供的贷款金额。状态可以为接受、拒绝或协商。

表 2. StatusUpdates 业务对象、其字段和数据类型。
字段类型
RequestIdInteger
RequestAmountDecimal
ProposedAmountDecimal
CommentString
StatusString
CustomerUpdatesString

申请人使用 LoanRequest 对象提交贷款请求。

定义活动使用的变量

业务流程包含三个私有变量:

  • LoanRequestData 变量是一个用于贷款请求提交的 LoanRequest 业务对象。
  • Status 是一个 StatusUpdates 数组,其中的每个对象包含每次协商的细节。
  • NegotiateCount 是一个 Integer,其中包含已经发生的协商的总次数。

单击 BankingSolution 流程图中的 Variables 选项卡,查看变量,如图 1 中所示:

图 1. 私有变量定义图
私有变量定义图

定义和实现活动

本节内容描述了 BPMN。图 2 举例说明了示例应用程序中使用的完整的活动流程。下面的内容描述了每个泳道、活动以及它们的实现。

图 2. 显示完整活动流程的业务流程定义
业务流程定义图

一共定义了三个泳道:System、Manager 和 Applicant。System 泳道用于自动活动,比如初始化。选择一个泳道。在 Process Designer 底部的 Behavior 下方选择用户组,组中的用户希望访问泳道中的活动。本文不会讲述创建用户和组的步骤。然而,应该将 Manager 泳道指派给其中包含有权处理请求的经理所在的组,将 Applicant 泳道指派给包含固定存款帐号所有人的组。

参考下面的 Information Center 主题,了解关于创建用户与组并将它们指派给泳道的更多信息:创建并管理组向 BPD 添加泳道

实现 LoanRequest 活动

流程中的第一个活动是 LoanRequest 活动。该活动接收来自申请人的请求。输入数据是一个 LoanRequest 对象。双击 LoanRequest 活动会显示 LoanRequest Human 服务。双击 LoanRequest Coach 将显示 Coach,如图 3 中所示。

图 3. LoanRequest Coach
LoanRequest Coach

请注意,RequestId 并不是由申请人填写,而是稍后由系统自动填写,并在通知中提供给申请人。

初始化 RequestId

  • 下一个活动是 Initialize RequestId。这是 System 泳道内的一个自动活动,以脚本形式实现。单击 Implementation 属性,在 区域中可以看到以下代码。
清单 1. Initialize_RequestId
var temprequestId;
temprequestId=Math.floor(Math.random()*100000);
tw.local.LoanRequestData.RequestId=temprequestId;

这段代码用于生成一个随机的整数值,然后将它指派给 LoanRequestData 对象的 RequestId。

验证贷款请求金额

Validate Amount 是一个决策网关活动,用于检查贷款请求金额是否超过 100,000 美元。出于演示的目的,这个金额是硬编码的。在实际的场景中,应该根据申请人的固定存款金额来检查这个条件。

图 4. Validate Amount 决策网关,用于检查贷款请求金额是否超过 100,000 美元
检查贷款金额的决策网关

如果金额大于 100,000 美元,请求将会初始化协商。如果请求金额小于 100,000 美元,请求将被自动批准,而申请人也会收到通知。

实现协商活动

Manager 泳道中的 Negotiate 活动是 Human 服务,而 LoanRequestData 和 Status 分别是它的输入和输出。运行应用程序时,您可以看到 RequestId 和 RequestAmount 已设置好了,因为我们已经将它们初始化。

ProposedAmount 是审批人准备授予申请人的贷款金额。此时可以提供意见,而状态字段应该包含以下值之一:Approve、Reject 和 Negotiate。ProposedAmount、Comment 与 Status 只是输入字段。其他字段是只读的。在开始协商之前,需要初始化用于协商的 Status 对象。为此,请选择 Initialize Negotiation,然后选择 Properties 选项卡中的 Implementation 区域。您将在 Script Object 区域中看到以下代码:

清单 2. 初始化 StatusUpdates
tw.local.Status[tw.local.NegotiateCount].RequestId=tw.local.LoanRequestData.RequestId;
tw.local.Status[tw.local.NegotiateCount].RequestAmount=tw.local.
LoanRequestData.LoanAmount;

状态变量是一个 StatusUpdates 对象的清单。清单中的每个数组索引都代表审批人与贷款申请人之间的一次通信,如图 5 中所示。稍后,我们将使用 StatusUpdates 对象说明协商的运行时行为。

图 5. 检查人/经理用于验证请求的协商过程指导
协商过程

Review 网关活动会检查贷款请求的状态,如下所示:

  • 如果状态为 Approved 或 Rejected,则初始化 Applicant 泳道中的 Notify 活动。
  • 如果状态为 Negotiate,则初始化 Update 活动。
  • Update 活动就是邮报评论活动的一个占位符。在这个示例中,该活动是作为一个模拟器实现的。您可以根据自己的业务要求来实现这个活动。
图 6. 用于检查审批人的决策的决策网关
用于检查审批人的决策的决策网关

Status 变量数组中的第一个索引包含审批人提供的 Proposed Amount、Comment 和 Status。现在需要在列表中初始化第二个对象,让它保存来自申请人的数据。NegotiateCount 的初始值为 0,而现在将增加 1 并使用 requestId 进行初始化。新的请求数量需要申请人从外部资源进行提交。

这也可以使用 Coach 的方式实现,但本文的目的是演示外部过程如何调用中间活动以便让多个应用程序可以异步地进行通信。这次初始化是在 Initialize Customer 活动中执行的,如清单 3 中 Script Object 下的代码所示。

清单 3. 初始化 Customer 活动
ttw.local.NegotiateCount=tw.local.NegotiateCount+1;
tw.local.Status[tw.local.NegotiateCount]=new tw.object.StatusUpdates();
tw.local.Status[tw.local.NegotiateCount].RequestId=tw.local.
LoanRequestData.RequestId;

创建消息传递中间事件

下一步骤是创建一个中间的消息传递事件,用于从外部资源接收 RequestId、RequestAmount 与 Applicant Status。收到的值将被保存在 Status list 对象中,并重定向至 Negotiate 活动,审批人将再次声明该活动,以便对其进行检查。

图 7. 用于在收到来自申请人的更新时触发下一个活动的中间消息传递事件。
中间消息传递事

实现秘密代理

在本节内容中,我们将讲述用于连接消息并将消息路由至消息传递事件的组件。单击 BANKING-SOLUTION 下的 Implementation。一共定义了四个组件,如图 8 中所示:

  • a) 用于 Customer 的 UCA 处理器
  • b) 用于 Customer 的 UCA
  • c) 用于 Customer 的 Web 服务处理器
  • d) LoanServices

请参考下面的图。

图 8. 实现 WebServices 与 UCA 的组件
实现 WebServices 与 UCA 的组件

创建 UCA 处理器

您需要创建一个 UCA 并将它附加到一个中间消息事件。但在创建秘密代理之前,您需要创建一个处理器,用它来定义参数和路由数据。在这个示例中,所有的工件都已创建完毕。请单击 Banking-Solution 下的 Implementation,然后选择 UCA Handler for customer。我们一共定义了三个变量,如图 9 中所示。这些数据将被路由至消息传递事件。

图 9. UCA 处理器中定义的变量
UCA 处理器中定义的变量

单击 Diagram 选项卡,找到如图 10 中所示的 Start 与 End 活动。

图 10. UCA 图
UCA 图

上面的流程显示,传入的数据被不做任何修改地路由给消息传递事件。

实现 UCA

  • 单击 Banking-Solution 下的 Implementation,然后选择 UCA for customer
  • 在 Details 区域中,注意 UCA Handler for Customer 服务被附加到了用于客户的 UCA,如图 11 中所示。
图 11. 将 UCA 处理器附加到 UCA
将 UCA 处理器附加到 UCA

将 UCA 附加到中间的消息传递事件

本节内容说明了外部系统如何触发中间的消息传递事件。

打开在 BPD 中创建的消息传递事件,查看 UCA Handler 参数的映射方式,如图 12 中所示。

图 12. 将 UCA 附加到消息传递事件
将 UCA 附加到消息传递事件

这种实现中最重要的概念是关联 id 的映射。在图 12 中可以看到,RequestId 旁边的选项按钮被选中。这意味着,此变量被选中作为关联 id。

那么关联是如何发挥其作用的呢?在任意给定的时间,可能有数百个过程正在运行,有数百个外部活动正通过 Web 服务或 JMS 调用 UCA。传入的数据如何将自身附加到相应的过程?通过关联 id 可以做到这一点。过程中的变量应该已经初始化并映射到某个传入的字段,即关联 id。如果两个值匹配,那么其他字段也将被设置,并触发下一个活动。


实现 Web 服务和 Web 服务处理器

现在可以通过 Web 服务或 JMS 调用 UCA。通过 JMS 发送消息更简单一些,因为在将具有预定义格式的消息放入事件队列后,就会触发 UCA。在我们的示例中,将会分析如何使用 Web 服务调用 UCA。

创建 UCA 处理器时,我们还需要创建一个 Web 服务处理器来定义参数与路由。

  1. Implementation 下,选择 WS Handler for Customer。我们已经定义了三个变量:WSRequestId、WSRequestAmount 和 WSComments。
  2. 选择 Diagram 选项卡。您可以看到 Invoke UCA 活动调用了 UCA for Customer UCA,如图 13 中所示。
    图 13. Web 服务处理器
    Web 服务处理器
    WS Handler 字段被映射到 UCA Handler 字段,如图 14 中所示。
    图 14. WS Handler 参数映射
    WS Handler 参数映射
  3. 最后需要实现 Web 服务。在 Implementation 下选择 LoanServices Web 服务。
  4. Operations 下单击 Add,然后选择 WS Handler for Customer。该操作名为 LoanApplication,如图 x 中所示。
  5. 这将自动生成一个 WSDL,而它的链接显示在 Behavior 下,如图 15 中所示。
    图 15. 显示最终调用用户调用的 WSDL 的 Web 服务实现
    Web 服务实现,具有最终用户为了触发 UCA 而使用的 WSDL URL。
  6. 单击 WSDL URL,并检查操作和参数定义。这些内容应该与 Web 服务处理器中定义的内容相匹配。

测试应用程序

测试应用程序要完成的步骤如下所示:

  1. 在 BPD 的右上方单击 Run Process 按钮,回放 BPD。
  2. 提供 LoanRequest 活动的细节,并请求一个大于 100,000 美元的贷款金额。
  3. 您将看到 Negotiate 活动被初始化。声明这次活动,将生成的 RequestId 记录下来。
  4. 提供一个经过协商的金额,并将 Status 字段设置为 Negotiate
  5. 完成活动。
  6. 完成 Update 过程。您可以看到,该过程现在一直在等待消息传递事件。
  7. 在 Rational Application Developer 或 IBM Integration Designer 中运行一个 Web 服务客户端,比如 SoapUI 或 Eclipse Web Services Explorer。提供 WSDL 链接,并使用字段 WSRequestIdWSRequestAmountWSComments 提交一个 SOAP 请求。提交请求之后,协商过程将会返回到 Negotiate 活动。
  8. 协商仍将继续,直到审批人将状态修改为 Approved 或 Rejected 为止。

在进行一系列通信后,Negotiate 页面看起来应该类似于图 x:

测试场景
测试场景

这次协商显示,请求的金额为 150,000 美元,但经理只批准了 110,000 美元。申请人反对,请求 140,000 美元。这次,审批人将金额放宽到了 120,000 美元。最后,申请人请求 130,000 美元,而经理也批准了这个金额。


结束语

本文实现了一个样例应用程序(已在 下载 中提供),您可以将它用作一个实现协商过程(使用 Web 服务与外部资源进行通信)的模型。本文举例说明了多层(比如 Web 服务、UCA 与消息传递事件)之间的数据流动。


下载

描述名字大小
样例应用程序BankingSolution.twx488KB
文本文件textfiles.zip14KB

参考资料

学习

获得产品和技术

讨论

条评论

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=930693
ArticleTitle=使用 Web 服务在 IBM Business Process Manager 中实现协商过程
publish-date=05212013