作者：唐笑秋 (xiaoqiut@cn.ibm.com), 软件工程师, IBM
FileNet BPM 与 Web Service 集成（Process Orchestration）简介
IBM FileNet Business Process Management（BPM）作为业内领先的业务流程管理解决方案，提供了一系列的技术与工具来帮助企业灵活地设计、实现、管理及优化业务流程，从而通过自动化及流水线的业务流程来提高企业的决策能力、工作效率和处理性能，减少周期时间。同时，FileNet BPM 还具有强大的与外部系统集成的功能，使得企业可以有效地利用已有资源来加快开发及简化部署，其中，BPM 与 Web Services 的集成（Process Orchestration）更是非常重要的一个市场需求。
我们可以看到，随着 SOA 的不断发展，Web Services 成为了构建 SOA 的理想模块。它由一组协议和标准构成，这些协议和标准定义了一个 Web Service 怎样被发布、发现以及实施。但是，简单的一个 Web Service 或是接口并不能意味着 SOA，能够通过 Web Services 的集成与协作来提供更高质量的服务才是 SOA 的一个实质，而 FileNet BPM 正提供了这样的灵活机制来构建 SOA 。它利用 Web Services 的相关技术使得业务流程可以很轻松地调用已有的外部 Web Service 来为工作流服务，同时也能够将业务流程本身作为 Web Service 对外发布，使得其他应用可以利用 BPM 工作流来完成自己的任务。在 FileNet BPM 中，这种动态地集成 Web Services 从而实现端到端及协作式的自动化业务流程的能力即被称为 Process Orchestration 。
FileNet BPM 与 Web Services 集成的基本原理及主要功能
在接下来的这一章节里，我们将会对 FileNet BPM 与 Web Services 集成的原理作一个简单介绍，并列出实现工作流调用外部 Web Service 以及将工作流作为 Web Service 供外部使用这两个交互方面所用到的三种 Web Services 系统功能。
FileNet BPM 与 Web Services 集成的原理简介
在了解 FileNet BPM 与 Web Services 集成的原理之前，我们需要简单了解下有关于 XML Web Services 的一些基本定义。
所谓 XML Web Services，是指通过 SOAP 协议并利用 XML 格式在 Web 上来传输数据的服务架构，它是一种面向服务的体系结构，具有良好的系统平台异构性和语言独立性。 FileNet BPM 正是采用了这种 XML Web Services 的相关技术来实现 Process Orchestration 。一个 XML Web Service 是使用 WSDL 文件进行说明并通过 UDDI 进行注册的，下面，我们即简单介绍下这些在 FileNet BPM 中也涉及到的基本概念。
- 简单对象访问协议（SOAP）：XML Web Services 的通信协议，是一种基于 XML，用于在分布式环境中交换信息的简单协议。 FileNet BPM 中的工作流与 Web Service 交互的消息就是通过这种协议进行封装与传输的。
- Web 服务描述语言（WSDL）：用于定义 Web Service 的 XML 文档，可以通过明确的表示法制定请求消息必须包含的内容以及响应消息的格式。由于它是基于 XML 的，与编程语言无关，因此适用于说明各种 XML Web Service 接口。 FileNet BPM 通过使用这种语言，可以实现与各种外部系统更加广泛的协作。
- 通用描述、发现与集成（UDDI）：相当于 Web Services 的黄页，提供了发现以及发布 Web Services 的方法。 UDDI 的目录条目是由第三方提供的服务以及这些服务的调用方式，FileNet BPM 中也是通过 UDDI 注册来发现 Web Service，从而实现与其它机构发布的 Web Service 进行交互的功能。
在 FileNet BPM 中，当工作流需要与 Web Service 交互时，会通过其底层的模块来利用上述协议实现对消息的封装以及可靠性传输。下图则是对集成原理的一个总体概括。
图 1. FileNet BPM 与 Web Service 交互原理图
从图 1 中可以看到，Component Integrator 控制了 FileNet BPM 与 XML Web Service 的交互，而这两者间的通信对于工作流管理者或是用户来说都是透明的，我们只需在 Application Engine 的流程任务管理器（Process Task Manager，PTM）上去配置并启动对应 region 的 Component Manager 即可。图中所示的 WS-Adapter 和 WS-Listener 都是 Component Integrator 的一部分，它们分别负责处理工作流对外部 Web Service 的请求以及由外部向 Web Service 工作流发起的请求。而对于 FileNet BPM 实现创建、修改和管理自动化业务流程的核心引擎 Process Engine 来说，它提供了一个 WSRequest 队列来专门处理关于 Web Service 的请求。当工作流需要与 Web Service 交互时，系统就会自动将工作项目路由到这个队列中，这些工作项目会暂时存放在一个 WSPending 表中来等待 Web Service 的响应。
FileNet BPM 中的工作流与 Web Service 的通信是通过 XML 完成的，正如上面的描述，整个交互过程对于使用者来说都是完全透明的。 FileNet BPM 提供的流程设计器（Process Designer，PD）能够自动地解析 WSDL 文件中定义的操作的输入输出参数，因此，我们需要关注的仅仅是所要调用的操作及交互中涉及到的数据域，而没有必要去真正了解 XML 。基于 FileNet BPM 这一通用性强、稳定性高并封装良好的设计原理，用户可以非常方便、容易地实现工作流与 Web Services 的交互，从而丰富并优化业务流程。
FileNet BPM 提供的 Web Services 功能
为实现 Process Orchestration，FileNet BPM 提供了以下三种 Web Services 系统功能：
- Invoke 功能
- Receive 功能
- Reply 功能
Invoke 功能是工作流用于调用 Web Services 的方法。工作流可以利用 FileNet BPM 提供的这一功能来从所选合作伙伴链接（Partner Link）中请求外部提供的已定义好的服务，实现与外部 Web Services 的交互。可以这样说，只要有外部提供的可使用的 Web Services，我们就可以根据业务需求在工作流的任一位置调用这一功能。当系统发现工作流中的某一步使用了该功能时，就会自动地把工作项目路由到 WSRequest 队列中，而 Invoke 功能正是被处理成了这个队列中的一个操作，从而通过这一操作来完成对 Web Service 的调用。应用示例 1 即是对如何使用 Invoke 功能的详细讲解。
Receive 与 Reply 功能则都是用于实现将工作流设计为 Web Service 对外提供的。其中，Receive 功能可以被看成是工作流的一个入口，当外部请求被监听到时，系统会通过这一功能来自动启动 Web Service 工作流。而 Reply 则能够将工作流处理后的信息返回给发起请求的外部应用，它与 Invoke 功能类似，也是作为 WSRequest 队列中的一个操作来实现的。对于设计一个 Web Service 工作流来说，Receive 功能是必不可少的，它与 Reply 功能可以是一对一的关系，也可以是一对多的关系。应用示例 2 即对如何使用这两个功能来实现工作流对外提供 Web Service 作出了讲解
实际应用示例 1 ——工作流调用外部 Web Service
在本章节，我们将给出一个具体的应用案例来说明在 FileNet BPM 系统中，工作流是如何实现调用外部 Web Service 这一功能的，同时，我们还会在最后的解决方案小结中对操作的主要流程及可能的问题作相关总结。
我们所提出的应用场景是基于使用信用卡支付来订购图书这一简单流程的。当某图书订购中心的客户想要订购图书时，首先需要提交购书申请，包括自己的个人信息、信用卡相关信息、想要购买的图书信息等。然后中心审查员会审核欲购图书的信息是否有效，若无效（如欲购图书无货），则直接拒绝客户的订购请求并给出拒绝原因；若有效，则会通过中心的业务员去提交一个正式的订单，并调用信用卡中心提供的用于支付的 XML Web Service 来验证客户是否具有支付权限和能力。业务员会根据信用卡中心返回的信息来决定是否批准订单，若客户无支付能力，则业务员会拒绝订单；若信用卡中心返回有效信息，则业务员会批准订单并通知送递员在三天之内把图书送递到客户手中。客户收到图书后的一周以内，需要向业务员提交已收到的信息确认，从而完成整个订购图书的流程，如图 2 所示。
图 2. 应用场景流程图（调用外部 Web Service）
通过上面的描述，我们可以清楚地看到，整个流程中涉及到了与外部 Web Service 的交互，即调用信用卡中心对外提供的已存在的支付验证功能，这一服务在现实生活中也是非常普遍与必不可少的。因此，在接下来的工作流实现中，如何调用已有的一个 Web Service 将是我们所要关注的主要环节，而对于其他的设计环节，我们只会作简单的介绍以求使读者能够有一个整体的认识。
鉴于 FileNet BPM 流程设计浅显易懂及形象化的优点，我们可以按照图 2 中的流程图非常容易地通过使用 Process Designer 托拽图标来得到如下所示的工作流：
上图只是给出了这个工作流的各个步骤及走向，我们仍有以下几个方面需要在流程配置控制台（Process Configuration Console，PCC）上作具体定义：
- 工作队列（Work Queues）建立
- 用户及权限设置
- 操作（Operations）定义
首先，在 PCC 上相应的 region 下，我们会新建四个工作队列，即 Customer（客户），Checker（审查员），Clerk（业务员）以及 Operator（送递员）。对于每个工作队列，我们需要在其属性中的 Security 和 Operations 里去分别设置用户及权限、相关操作和操作的输入输出参数。下表所示即为每个队列所要设置的内容。
| 工作队列 | 用户组权限设置 | 操作定义 |
| Customer | Query/Process | 无 |
| Checker | Query/Process | SubmitOrder（审查员判断书籍信息是否有效，若有效，则向业务员提交订单申请，如无效，则拒绝客户请求） |
| Clerk | Query/Process | ApproveOrder（业务员接到订单申请后，计算总价并生成订单号）; ChangeOrderStatus（业务员根据订单信息及信用卡中心返回的支付信息，更改订单状态） |
| Operator | Query/Process | BookDelivery（根据业务员批准的订单信息将书籍送递给客户，更改订单状态为 Delivery） |
需要指出，所定义操作的输入和输出参数是通过不同的读写权限来区分的。我们可以这样理解：Read 权限相当于操作的输入，Write 权限相当于通过该操作后的输出，而同时具有读写权限则相当于该操作可以对输入的参数进行修改然后输出。下图即为一个操作定义的实现示例：
OperationDef.jpg |
接下来，我们需要回到Process Designer的工作流定义上来配置以下几点：
- 工作流属性设置：主要是设置工作流数据域
- 每一步骤的目标用户设置，显示数据或操作设定以及用于路由的Responses设置
- 两步骤间的路由条件定义
工作流属性中的数据域（Data Fields）实际上是定义了每一步骤中目标用户所能看到的条目，同时也是为所调用的 PCC 中定义的操作指定与输入输出参数对应的表达式。在工作流数据域定义之后，我们以图 3 所示工作流中的第二步 CheckBooks 为例，用下图简单说明一下怎样设置目标用户、操作及路由响应等属性。
下面，我们将开始重点说明这个案例中最具代表性的一步，即调用信用卡中心提供的 Web Service 来作支付验证。
从图 6 可知，当我们需要调用外部 Web Service 的某一功能来为自己的工作服务时，可以通过托拽 Web Service Palette 中的 Invoke 图标到工作流中并配置相关属性来实现。在图中左边的属性（Properties）面板中，Partner Link这一项是调用 Web Service 的重要属性，它指定了 Web Service 所提供的 WSDL URL，通过 WSDL 文件中定义的 Web Service 供外部使用的接口，我们可以调用该 Web Service 中允许的一系列操作。而要在工作流属性中定义 Partner Link 并找到与所调 Web Service 相对应的 WSDL URL，则首先需要在 PCC 中的 region 属性中进行 UDDI 注册。
图 7 所示即为 UDDI 注册，其中的 Inquiry URL 是外部 Web Service 给定的，在本例中即是由信用卡中心所提供。添加到列表后，需要点击右上角的Validate图标进行格式验证，同时可以不选择图 7 下方所示的选项来限制 PD 定义 Partner Link 时只能使用 UDDI 注册列表中的条目。
回到 PD 上的工作流属性面板，图 8 和图 9 给出了 Partner Link 的定义过程。
图 8. 定义 Partner Link
图 9. 点击浏览已 UDDI 注册的 Web Services
完成以上几步后，我们就可以在 Invoke 步骤的属性中选择这个定义好的 Partner Link 以及其所提供的 WSDL 文件中定义的操作（本例中为 authorizePayment 操作）。如果设计者认为已完成工作流定义，则可点击 PD 面板上的 Validate 图标来对所设计的工作流进行验证。工作流验证通过后，我们可以启动一个工作流的实例来看看是否能够成功调用 Web Service 。当业务员完成为客户生成订单号的操作后，工作流进入到调用信用卡中心提供的 Web Service 这一步。此时，进入流程管理平台（Process Administrator）找到对应的工作流，然后点击 Open Tracker 图标即可跟踪当前工作流的执行状态。从图 10 可知，工作流停在了调用 Web Service 这一步，同时，我们可以通过命令行的方式（vwtool -> count #）来查看工作项目在每个队列中的数目，如图 11 所示。不难发现，工作流停在 WSRequest(0) 不能被处理的原因是因为我们还没有在 Application Engine 的 Process Task Manager 上去启动 WSRequest(0) 。从前面的原理简介中可以知道，FileNet BPM 为调用 Web Service 所提供的 Invoke 功能是被处理成 WSRequest 这个 Web Service 队列中的一个操作的，因此它是工作流与 Web Service 交互的关键。按照图 12 所示新建 Component Manager 并启动 WSRequest(0) 后，工作流即可成功获得 Web Service 返回的信息（本例中的返回为 authorize_payment: INVALID），进行到下一步去等待业务员选择 Reject 来拒绝订单。
图 10. 进入 Process Tracker 跟踪工作流
图 11. 使用 vwtool 命令查看状态
图 12. 新建 Component Manager 并启动 WSRequest(0)
上一小节中，我们对工作流调用外部 Web Service 的案例给出了详细的解决方案，下图则是对这一解决方案中如何调用 Web Service 的具体步骤总结。按照这样的步骤，只要我们有可用的 Web Service，就可以成功地将其集成在工作流中任意需要调用它的地方。
另外，对于调用 Web Service 的这一步，在进行 Validate 时一般来说有可能会出现以下几个错误：
分析可知，错误 1 是由于设计者的疏忽，没有为 Invoke 这一步指定 Partner Link 所造成的；错误 2 则是因为没有指定调用的 Web Service 所提供的操作；错误 3 表明在定义 Partner Link 时，没有指定具体的 WSDL URL（比如，当前有一个名为 abc 的 Partner Link，但设计者却没有通过浏览 Web Service 来指定具体的 WSDL 文件）；错误 4 则是最常见的一个错误，即没有为调用的 Web Service 操作中的输入输出参数指定对应的工作流数据域（如图 6 中绿色框里的各项没有指定的话，就会出现这个错误）。
实际应用示例 2 ——工作流对外提供 Web Service
除了调用外部 Web Service 以外，工作流本身也可以作为一个 Web Service 为其它工作流或是外部系统提供服务。下面，我们将在上一章节应用场景的基础上，给出一个简单的例子来说明怎样设计一个 Web Service 工作流并利用其它工作流对其进行调用。
对于图书订购中心的客户，当他决定购买某一书籍前，需要先对该书籍在此订购中心的信息进行了解，如价格、折扣及返回积分等。客户的此类请求首先会被提交到中心管理员那里，然后通过管理员返回想要获得的图书信息。这一查询的流程需要以 Web Service 的形式对外提供，从而使客户能够：
- 在订购中心专门提供的主页上发起图书信息查询请求调用这一流程；
- 通过启动另外一个工作流来调用这一图书信息查询流程。
图 15. 应用场景流程图（工作流对外提供 Web Service）
基于上一章中对工作流设计的详细描述，这一节我们就只关注如何将工作流设计成一个 Web Service 。
一个工作流要对外成为一个 Web Service，需要在工作流中包含 FileNet BPM 提供的 Receive 和 Reply 两个 Web Services 功能，如下图所示工作流定义。
根据之前的介绍可知，图 16 中的 Receive 步骤是用于监听外部请求从而启动整个工作流的，而 Reply 步骤则是把工作流中产生的信息返回给发送请求的工作流或外部系统。这两个步骤的属性中都需要指定 Partner Link 和相应的操作及参数。但和前面介绍的调用 Web Service 的 Invoke 步骤不同，这里的 Partner Link 的类型应该是 Receive/Reply 而不是 Invoke，而且我们只需要定义一个供外部调用的 Process Port Type 即可。另一方面，Receive 和 Reply 属性中的操作及参数定义是分别用于指定这个 Web Service 工作流的输入和输出的。图 17 和 18 分别给出了图 16 所示 Web Service 工作流中的 Partner Link 定义及两个主要步骤的属性配置。
图 17. 为提供 Web Service 的工作流定义 Partner Link
图 18. Receive 和 Reply 步骤属性配置
工作流定义完成后，我们需要对该工作流进行传输（Transfer），这是使其能够提供 Web Service 的必需步骤。
下面，我们会用图 19 中的工作流来简单调用上面定义的这个提供 Web Service 的工作流，从而验证该工作流能够成功地作为 Web Service 供外部使用。
调用内部工作流提供的 Web Service 和外部 Web Service 的操作是类似的，只是在定义 Invoke 的 Partner Link 时，可以直接通过搜索工作流名字在浏览 Web Service 工作流的界面上获得其对应的 WSDL URL 。同时，可以看到，图 19 所示 Invoke 属性中选择的操作及输入输出参数正是在图 18 中 Receive 和 Reply 属性设置里定义的。
新建对应 region 的 Component Manager 并启动 WSRequest 队列后，我们可以启动测试工作流。在调用 Web Service 时，提供该 Web Service 的工作流会自动启动，WSRequest 队列将出现成功处理 Invoke 方法的信息，同样，在 Web Service 工作流返回信息给测试工作流时，WSRequest 队列也将会出现成功处理 Reply 方法的信息。
如果我们想要把 Web Service 工作流提供给外部使用，一般需要对其进行发布。发布一个 Web Service 工作流的先决条件是要在 PCC 中的 region 属性里先添加一个可用的 UDDI 注册到列表中，然后进入 Publish to UDDI 窗口来发布定义好的提供 Web Service 的工作流，如图 20 所示。
如果想要在不发布工作流的情况下将其提供给外部用户调用，则可以直接将已传输的 Web Service 工作流的 WSDL URL 提供给用户。 WSDL URL 的构造方法为：http://[AE Server]:[port]/Workplace/P8BPMWSBroker/wscp[connection point name]/wc/[Workflow Name]/ [Workspace ID]?wsdl 。我们可以根据构造好的 URL，在 IE 中打开该工作流的 WSDL 定义文件进行查看。
在设计工作流使其对外提供 Web Service 时需要注意以下几点：
- 想要作为 Web Service 对外提供的工作流，其名字是不能包含空格的；
- 为了使工作流能够在外部将其作为 Web Service 进行调用时自动启动，需要把 Receive 这一关键步骤放在 LaunchStep 之后的第一步；
- 由于 Web Service 工作流是在外部调用时自动启动的，因此不能在该工作流中指定 F_Originator（工作流发起者），它将被作为无效用户来处理；
- 必须先对工作流进行传输，才能将其作为 Web Service 使用。
下图即是对如何将工作流定义成为 Web Service 的具体步骤总结。
图 21. 工作流对外提供 Web Service 的操作总结
  |
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15082138/viewspace-605286/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/15082138/viewspace-605286/
276
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
