第1部分--使用WebLogic Platform 进行订单管理

　当对流程完成良好建模并不再更改时，现有的 IT 系统会工作良好。然而，现实中的业务随时都在变化，流程也变得越来越复杂，尤其是当 Internet 可以很容易地将内部系统和外部系统连接在一起时。业务流程管理（Business process management，BPM）能够帮助管理这一复杂而不断变化的流程。

当对流程完成良好建模并不再更改时，现有的 IT 系统会工作良好。然而，现实中的业务随时都在变化，流程也变得越来越复杂，尤其是当 Internet 可以很容易地将内部系统和外部系统连接在一起时。

业务流程管理（BPM）能够帮助管理这一复杂且不断变化的流程。操纵数据这一当今 IT 系统均能有效实施的概念，可以扩展到业务流程。通过使用工作流类型的技术，企业可以使用 BPM 系统来同时控制现有的应用程序、Web 服务和各个人工流程，或者构造或解构流程或子流程。

使用业务流程建模，我们可以对现有业务流程建模并衡量其有效性。这将帮助我们理解当前企业如何运作，并使我们可以发现需要改进的地方。它使得我们能够在实现所建议的改进之前对其进行测试，看它们能否达到预期效果。图 1 描述了在您的业务中如何实现 BPM。首先，需要分析和定义流程模型。这些业务流程可以通过一个流程引擎来构建和配置。然后，您就可以监控该业务流程。

　图 1

在这个系列中，我们将了解 WebLogic Integration 如何提供一个 BPM 解决方案。通过对现实中的一个涉及订单管理的例子的探究，我们将说明如何使用 WebLogic Integration 来对一个业务流程进行建模、执行和监控。

PD4J 和 WebLogic Integration
　WebLogic Integration 提供了一个健壮而完整的 BPM 解决方案。WebLogic Workshop 中的流程建模建立在 Process Definition for Java （PD4J）的基础之上。不同的组织正致力研究和制订 BPM 中的各个不同规范 -- Java Community Process (JCP) 致力于 Process Definition for Java (PD4J)，OASIS 则致力于 Business Process Execution Language for Web Service (WSBPEL 或 BPEL)。PD4J 已经在 JSR 207 中提出并构建在 JSR 175 中的 Java Language Metadata 技术上。后一个标准将为 J2EE 平台提供一个易用的语法，用于在源代码级描述业务流程。JSR 207 的目标是探索并标准化流程语言（如 BPEL）、Java 语言和 J2EE 平台之间的关系。

由于下一步的主要工作是定义 Java 流程标准，BEA 和 IBM 已通过紧密合作来建立一个称为 BPELJ 的新标准，并将其提交到 JSR 207 工作组。BPELJ 是 BPEL 和 Java 结合的产物，这两种语言可以一起使用来构建完整的业务流程应用程序。通过使 BPEL 和 Java 一起工作，BPELJ 让它们各自发挥自己特长。BPELJ 是通过到 BPEL 语言的扩展来实现的；因此，任何的 BPEL 流程都能够通过 BPELJ 来执行。通过标准化这些扩展，业务流程将通过 J2EE 平台实现真正的可移植和互操作。

BEA 领导着 JSR 207 的研究和制订，并且是 BPEL与 BPELJ 的联合制订者。除了 BPEL 的功能外，BEA 也将在下一个WebLogic Integration 主版本提供完全支持。即时，它将提供从在 PD4J 中编写的流程自动而无缝地迁移到 BPELJ 的体验。

在 WebLogic Intergration 中构建BPM的关键要素

WebLogic Integration 构建 BPM 解决方案的三个阶段为：

1. 流程的建模；

2. 流程的执行或自动化，基本上是构建和配置流程；

3. 流程分析，包括流程监控。

为了进行流程建模，WebLogic Integration 使用WebLogic Workshop，它具有很多图形化工具，可以在 WebLogic Workshop 环境，在设计和代码视图中构建、显示和更改业务流程模型。建模工具的诸多特性提供了同步和异步 Web 服务、分支、嵌套、循环、平行、分组和异常处理。

业务流程也与 WebLogic Control Framework 集成，后者支持数据库、文件、消息、服务代理和人工交互。WebLogic Workshop 提供的 Control Framework 是封装业务逻辑、访问企业资源（如数据库、消息队列和定时器）并将其作为 Web 服务提供的一种方式。使用 Control Framework，可以整合不同资源的数据和业务逻辑，并将它们用在一个业务流程中。

对于从 XML 到 Java 的转换，可以使用 XMLBean。XMLBean 是 WebLogic Workshop 中普遍使用的技术；它提供了非常简单的 XML 数据与 Java 类型之间的转换。XMLBean 有许多优点，且在不失去对原始 XML 结构的访问情况下，提供了XML 数据的一个基于 Java 对象的视图。使用 XMLBean，XML的文档完整性没有丢失。它们将整个 XML 文档实例当作整体来处理，而不是像其他的 API 那样将 XML 分开处理。我们将在 Workshop 中了解当一个 xsd 文件导入到 schemas 文件夹中时，XMLBean 是如何被创建以及如何可用到业务流程的。

对于 XML2XML、Java2XML、和 non-XML2non-XML 映射，可以使用 XQuery Transformation Mapper。XQuery Map提供了一种改造 Web 服务发送或接收的 XML 消息的方法。

WebLogic Integration 可实施在 WebLogic Workshop 中设计的流程的自动化。通过自动生成的 J2EE 代码，可完成流程构建。当在 WebLogic Workshop 中使用图形化工具设计业务流程时，源代码已经自动生成了，它按照 PD4J 来存储此流程。它被称作 JPD (Process Definition for Java)文件。您也可以在源视图中编辑 Java 代码。WebLogic Server用来构建和配置业务流程。WebLogic Workshop 有一个测试浏览器可以帮助测试流程。您可以执行那些保持状态信息的有状态流程、没有状态信息的无状态流程以及同步和异步流程。可以为某个业务流程生成一个 WSDL，因此可以使它作为 Web 服务激活。

流程分析提供了持续监控并实时收集统计数据。这在 BPM 中非常重要。服务级别协议(SLA)状态监控和历史流程报告生成信息由 BPM 工具提供。可以使用 WebLogic Integration 控制台来监控该流程。

现实中的例子

WebLogic Workshop可以用来对一个现实中的业务流程进行建模。它有一个设计视图，其中包含流程节点和控件面板。通过它们，您能够添加 Web 服务、客户请求、决策节点和Java 控件来模拟一个现实流程。当添加了这些组件后，Workshop 将在一个独立的选项卡中生成源代码和注释，以反映使用 PD4J 规范的流程逻辑。当对业务流程建模后，可以通过在 Workshop 中执行它来测试它。

在本系列的文章中，我们将探索一个真实的业务流程 ——Change Order Request（更改订单请求），该流程是在针对某厂商的 Order Management 业务流程中。我们将看到如何在 WebLogic Workshop 中使用图形化界面建立这个‘现实中业务流程’。

这个现实例子中所涉及的实际场景，是 PC 销售商销售可按单配置 PC。通过这个销售商购买东西的消费者想升级他已订购的 PC 上的光硬盘。这将导致从销售商向生产商发出生成更改请求。销售商发出请求来更改产品配置信息，要求在前面已经确认的订单上升级 PC 的硬盘。

订单更改流程有很多流程步骤和决策点。第一流程步骤是以 XML 形式接收来自销售商的订单更改请求。这个 XML 使用 RosettaNet Partner Interface Processes (PIPs) 完成订单更改。RosettaNet PIP 是 RosettaNet Implementation Framework 的一部分，并且是商业合作伙伴之间的标准化电子商务事务处理。事务处理格式的一致性对于缩短合作伙伴之间执行事务处理的时间是非常重要的，因此，每个 PIP 都伴随着一个消息指南和 XML 文档类型定义（DTD）。

当 ChangeOrder 因为所升级的硬盘而有一个新的配置来升级硬盘，我们需要检查这个配置对于 PC 是否有效。业务流程使用一个 Web 服务来检查配置的有效性。如果这个升级硬盘不能随着该 PC 订购，则配置无效，流程终止。如果配置有效，则业务流程继续下一步。

接下来的步骤是与制造商方面一起检查原始订单的状态。这将帮助跟踪 PC 正处于装配流程的什么地方。这个状态将使您了解它是否正处于添加硬盘的装配流程，这将意味着订单还可以发生变化；或者，如果它已经处于发运码头，这是订单是不能更改的。该状态保存在数据库中。在这一流程步骤中，需要激活数据库控件来检查订单的状态。如果这个订单不能更改，则流程结束。如果订单可以更改，这个更改将在基于 ERP 的系统上执行，或者可以写出到一个能加载到ERP 系统的文件。图 2 显示了更改订单请求流程步骤。我们将在 WebLogic Workshop 中使用这些步骤来创建该业务流程。

　图 2

创建一个业务流程的步骤
　首先需要创建一个应用程序。我们将这个应用程序命名为 orderChange。在这个应用程序中，我们创建一个名为 orderChange.jpd 的新流程。为了开始流程，我们需要再添加一个待接收的 ClientRequest。接下来添加一个 Web 服务验证。之后我们需要判断配置是否有效；因此，我们需要添加一个决策节点。为了检查订单状态，需添加订单状态数据控件。再次，我们必须决定订单状态是否允许我们继续流程。因此，我们需要添加另一个决策节点。流程的最后部分是要么将这个变化写入到能够加载到 SAP 订单执行系统的文件控件，要么直接写入SAP。最后一步是结束流程。

结束语
　我们将在这个系列中的下一篇文章中探究每一步骤的细节。第二篇文章将讨论流程的创建、客户请求和附加 Web 服务。第三章将讨论设计点和数据库控件的添加。第四篇将讨论如何写入到文件控件和结束流程。在最后一篇我们将了解如何在浏览器中测试业务流程以及如何监控流程。

第 2 部分--创建流程应用程序

　创建新应用程序和新流程
　当您开始在 WebLogic Integration 中对业务流程进行建模时，首先需要创建一个叫做orderChangeprocess 的业务流程应用程序，在该应用程序中创建业务流程 OrderChange.jpd。当您在 Design View（设计视图）中创建 orderChange.jpd 时，将只能看到 Start 和 Finish 节点。

创建客户请求来启动流程
　在 WebLogic Workshop 中有 5 种不同的启动业务流程的方法。

• 通过客户请求调用。
• 通过有返回值的客户请求同步调用。
• 订阅消息代理通道（message broker channel）并通过一个事件（定时器、e-mail、文件、适配器等）来启动。
• 同步订阅一个消息代理通道，并通过一个事件来启动。
• 通过几个客户请求或者订阅（事件选择）中的一个来调用。

在我们的例子中，发送了一个经过更改的 XML 文档来请求ChangeOrder。该XML 文档的格式为 RosettaNet PIP 3A8。我们称该文档为 orderchange.xsd。首先要将该 orderchange.xsd 添加到 schemas 文件夹，方法是将其导入到应用程序中。在您添加模式的同时，也创建了 XML Beans。我们将在下一节中详细探讨 XML Beans。

　当客户请求更改订单时，我们将调用 Client Request 来启动业务流程。为此，您需要创建一些方法和参数，客户将用它们来触发业务流程，这些方法和参数是在本节点的 General 和 Receive Data 设置中指定的。General Settings 指定了业务流程为客户提供的方法。客户可以调用 orderChange 方法来启动业务流程并向其发出请求。我们将该方法映射到键入的 XML —— orderchange.xsd 中。也就是说，从客户那里接收的消息必须含有对 XML Schema orderchange.xsd 有效的 XML。General Settings 选项卡会获得更新，以指出您已经成功地完成了方法名称和参数的指定：

　在 Receive Data 中为从客户那里接收到的 Order Change 请求指定一个变量，并在运行时为该变量赋值。您可以使用 Variable Assignment 模式或者 Transformation 模式。在这里，将把从客户那里接收到的 XML 消息直接赋给有相同数据类型的变量 orderChangexsd，如图 1 中所示。

　图 1

该 JPD 流程与下方所示类似：
　　@jpd:process process::
　　* <process name="orderchange">
　　* <clientRequest name="orderChangeRequest" method="orderChangeRequest"/>
　　* </process>::
　　它后面的代码与清单 1 中的类似。

添加 Web 服务

　下一步是调用 validateConfig Web 服务。您可以创建一个 Web 服务控件来调用这个 Web 服务。这里假设您已经为该服务定义了一个 WSDL。我们将通过 WSDL 创建该 Web 服务控件。第一步是将 WSDL 导入到 schemas 文件夹中。
　在将 WSDL 导入到业务应用程序的 schemas 文件夹的同时，也创建了 XML Bean。让我们先详细研究一下 XML Beans。

XML Beans
　XML Schema 是 XMLBeans 的起始点。XML Schema 规范提供了允许您表示数据的结构和约束的大量数据模型。在 XML Schema 中，您可以强制性地控制文档中数据的排列顺序以及约束特定值的方式（例如，价格必须大于 $150.00）。要在 Java 中做到这一点，就必须编写自定义代码。XMLBeans 接受这些模式约束。
　让我们查看清单 2 中所示的 outValidateConfig 的模式和 XML，看一下如何将它转换成 XMLBeans 。这是 validateConfig 服务的输出模式，它指出了配置有效与否，如果无效，则指出错误。
　您有一个复杂类型元素 outValidateConfig。在模式中，复杂类型指的是定义可包含子元素和属性的元素类型。复杂类型中所嵌套的序列元素列出了其子元素。由于 outValidateConfig 位于模式的顶部，所以其类型为全局类型。
　在一个复杂类型 outValidateConfig 中，可以使用简单类型（如 ConfigID）和复杂类型（如 Status）。这个简单类型是一个内置类型，它是模式规范的一部分。该规范中一共定义了 64 个内置类型。在编译 XML 模式时，由此产生的 API 是由两种类型组成的，其中一种类型是内置类型，它们在模式规范中映射那些 API，另一种类型是从用户派生的模式类型生成的。要编译 XML 模式，可以将该模式或者 WSDL 导入到 WebLogic Workshop 的 schemas 目录中，它将创建该 XMLBeans。
　编译后的 XML Schema 为您提供了两个生成的接口：OutValidateConfigDocument 和 outValidateConfigDocument.outValidateConfig。从模式的观点来看，生成的 outValidateConfig 接口表示了在该模式的 outValidateConfig 元素声明中看到的复杂类型。该复杂类型被转换成包含 4 个元素的序列，这 4 个元素是：Status、Error、ConfigID 和 ShipDate。outValidateConfig 接口提供诸如 getStatus 和 setStatus 方法来提取和设置 status 元素的值。
　outValidateConfigDocument 接口表示了 outValidateConfig 文档，该文档包含 outValidateConfig 根元素。XMLBeans 创建了一个特殊的“document”类型作为全局元素类型。文档类型为您提供了一个获取和设置基础类型值的方法，这里由 outValidateConfig 表示它。因为 outValidateConfig 是根元素，同时可以在模式中的任何其他地方对其进行引用，所以它被认为是一个全局元素。为了设置或获取用户定义类型的值，还提供了 get 和 set 方法。
　一旦有了 XMLBeans，就可以在 WSDL 中创建 Web 服务控件。为了做到这一点，您可以通过在 WSDL 中指定选项来添加一个 Web 服务控件。让我们来详细了解一下控件框架。

控件框架
　可以使用 WebLogic Workshop 8.1 的控件框架来轻松连接并使用数据库、后端系统（如 ERP 或者遗留系统）、定制或供应商应用程序，以及包含 Java 控件的 Web 服务。这些控件封装了其他控件，并添加了业务逻辑来创建作为业务流程一部分的可重用复合组件。

　图 2

BEA WebLogic Workshop 包含以下控件：

• Web 服务控件：可以将该控件从 WSDL 文件导入 Web 服务中，这些 WSDL 文件可以是本地或者从 UDDI 服务器上动态提取的。这些控件可以和任何 .NET 或者 Java Web 服务进行互操作。
• EJB 控件：EJB 控件包含用于 JNDI 查找、对象创建以及创建步骤的代码。EJB 可以通过控件对象来调用。
• Database 控件：企业数据库是通过 database 控件以 JDBC 的方式集成的。SQL Maps 允许您指出应该如何将其 Java 参数替换到查询中。
• JMS 控件：客户通过回调来监听这个 JMS 控件。该控件可以向队列发布和订阅消息。
• J2EE CA Adapter 控件：企业应用程序和遗留系统可以通过 J2EE CA 适配器来访问，它们是由 J2EE CA 控件控制的。J2EE CA 接口通过 XML 映射与 Java 集成在一起。
• Timer 控件：可以利用该控件对响应和请求的时序进行管理，它可以定时触发 Web 服务。这使它能够向客户发送状态更新、轮询数据源或者建立一个资源请求超时。

一旦创建了Web 服务控件，就需要在业务流程的定义中指定对 validateConfig Web 服务控件的调用。我们需要发送 validateConfig 方法指定的数据。为此，我们建立了从 orderchange.xsd 中接收到的数据到 validateConfig 的数据转换，如图 2 所示。数据转换的代码参见清单 3。在清单 4 中，orderchange.xsd 的模型元素被映射到 validateConfig 方法的模型元素：
　在清单 5 中，orderchange.xsd 中的 cstic 元素被映射到 validateConfig 方法的 cstic 元素。
　图 3 显示了该转换。

　结束语
　在下一篇文章中，我将探讨如何在业务流程中创建决策点和订单状态控件。在第 4 篇文章中，我将写入对文件的更改并结束该流程。在本系列的最后一篇文章中，我将讨论流程监控。

第3部分--使用WebLogic平台进行订单管理

　添加决策节点
　验证配置流程节点执行后会有两个结果——一个是产品有效而另一个是产品无效。为了决定如何处置这两个结果，需要在业务流程中添加一个决策节点。如果配置有效，流程将继续；否则，它将结束。单击面板中的Decision，然后拖拽决策节点到设计视图中的业务流程上就可以添加该节点，如图1所示。
　这个决策节点需要定义一个条件，这可以通过双击condition节点以调用决策构造器来进行。变量以缺省方式选择，当您根据XML文档中元素的值（也就是状态）来设计决策时，应该使用变量，该元素要根据XML Schema来验证。选择做出决策所依据的XML元素。为此，需要从outValidateConfig中选择属性状态。从运算符列表中选择=运算符，然后在Right Hand Expression字段中输入true。单击“添加”以加入刚创建的条件（BEA）-

data($outValidateConfig/ns:Status)= "true"

这样就完成了该节点的第一个条件的设计。图2显示如果validateConfig状态为真，则可以进入下一步；如果决策为假，则流程结束。在运行时，通过计算决策点的值来决定流程的路径。

添加数据库控件
　如果配置有效，则流程进入下一步，这通过数据库控件来执行。数据库控件是控件框架的一部分。（控件框架将在最后一篇文章中讨论）
　需要给流程添加一个数据库控件。数据库控件提供对包含某一特定AccountID的orderStatus数据库的访问。该控件将AccountID发送给数据库表ORDERSTATUS，后者发送应答以反映订单是否可修改。 可以从应用程序的数据库控件访问关系数据库。使用数据库控件可以发送SQL命令给数据库，SQL命令通过JDBC驱动程序访问数据库。必须指定WebLogic中配置的数据源，本例中是cgdatasource。数据库控件自动执行从数据库查询到Java对象的转换，因此用户可以方便地访问查询结果。
　首先创建一个名为record.java的新Java类。Record类是一个代表数据库内单个记录的Java对象。特别的是，它代表数据库中ORDERSTATUS表中的单个记录。下面是需要添加到record.java的代码：

创建一个查询ORDER STATUS表的数据库控件文件，然后返回一个包含查询结果的记录对象。这个数据库控件文件名为OrderStatus DB.jcx，JCX代表Java Control extension。JCX文件扩展WebLogic Workshop中预建的一个控件类。此处，它是com.bea.control.DatabaseControl类，该类提供了访问数据库的简单方法。BEA WebLogic Workshop提供的大多数内建控件可以定制——也就是说，当在项目中添加新的内建控件时， WebLogic Workshop生成一个扩展控件的JCX文件。在某些情况下——比如对于数据库控件或JMS控件——可以通过添加或编辑JCX文件中定义的方法来定制控件。WebLogic Workshop根据控件将要访问的EJB来定制EJB控件。

　现在，在数据库控件文件OrderStatus DB.jcx中添加一个名为getOrder Status的方法，然后在属性编辑器中给该方法添加一个SQL查询，如下所示：

在源代码视图中，代码显示通过传递AccountID，可从数据库表ORDERSTATUS (见清单1)中获得order_status。
　要将从客户接收的XML中的AccountID传递给数据库控件，需要用到转换。转换将接收到的XML中的AccountId与数据库控件发送的AccountId进行匹配。一旦获得订单状态，如清单1所示，它就可发送给流程中下一节点。

清单1 传递 AccountID 以获得order_status

添加另一个决策节点

　下一步是检查orderStatus结果是否允许修改订单。为此，插入另一个决策点。为了在此进行判定，需要使用Java方法而不是参数。要使用Java方法，如图3所示选择方法。在Java方法名中选择条件，如果条件返回的值是布尔型，如以下代码所示，则订单可修改。如果订单可修改，进入下一步；否则，停止该流程。

结束语
　本文介绍了如何添加第一个决策节点到流程中。该节点处理从验证配置 Web服务获得的两个结果，也即配置有效或是无效。如果配置有效，流程调用下一个节点，该节点是一个数据库控件。
　本文还介绍了创建和添加检查数据库订单状态的数据库控件的细节，这一订单状态决定了订单是否可以修改。然后，添加了一个决策节点以处理该数据库控件的输出结果。
　下一篇文章中，将介绍如果订单状态可以修改，如何将修改写入文件。这个修改之后将上载到一个像SAP的ERP系统中，然后，可以修改订单。在本系列的最后一篇文章中，将介绍这一流程如何执行和监控。

第4部分--如何将订单修改加入基于ERP的系统中

增加File控件

首先，让我们看看如何给流程添加文件控件。如果orderStatus允许订单修改，订单就可通过File控件写到文件中。还有一种方法是，您可在SAP中使用Application View控件来修改订单，如下所述。

File控件使得它容易读、写或附加到文件系统中的文件。还可以使用File控件来复制、重命名或删除文件。为了写入一个文件控件，可如图1所示给流程添加File 控件--ChangeorderFile。这会把一个XML文件写入到c:/bea目录，之后它可用于修改订单。一旦将XML文件写到该目录，就可使用它更新订单管理系统。

　图1 向流程中添加File 控件--ChangeorderFile

为SAP增加Application View控件

为了将订单修改写到SAP中，我们需要使用SAP适配器创建一个从WebLogic到SAP的集成解决方案。WLI中的集成框架基于J2EE Connector Architecture 1.0。WLI为了与EIS集成，提供了适配器、应用程序视图以及Application View控件。

SAP适配器提供了与SAP Business API (BAPI)的集成，您可以使用它把应用程序链接到SAP组件的接口。BAPI调用是同步的并且返回信息。这些信息要么是错误通知，要么是包含BAPI调用结果的式良好的XML文档。适配器还提供与Intermediate Document (IDoc)的集成。这些调用是异步的且不同步返回任何信息。第三个集成是远程函数调用（RFC，Remote Function Call）。在RFC调用中，应用程序建立起到SAP系统的连接（使用有效用户ID），然后发起一个对SAP函数的调用。RFC调用是同步的并通常返回信息。

用SAP适配器设计应用程序集成解决方案，必须先从BEA Web站点下载SAP Adapter，并从SAP Web站点下载SAP JCo。要从BEA WebLogic中向SAP下订单，您需要为Create Sales Order BAPI生成schema。该BAPI将易于在SAP中创建订单。

要为SAP Business Object（它将易于创建订单）生成schema，需要安装BEA Application Explorer。要创建schema，首先需要或是建立一个到 SAP 的新连接或是使用现有连接。对于新连接，必须命名该连接（比如，D7b）、应用服务器系统号码、客户号码、用户名以及密码。当连接SAP时，所有应用程序组件、IDoc 和 RFC 都将放入Application Explorer。我们特别想要为Change Sales Order BAPI 创建一个schema。通过右击BAPI 并创建请求和应答schema ，我们可达成此目的（参见图2）。这些schema 以及manifest.xml文件都保存在工作目录下。
　
　图2 请求和响应 schema

接下来，我们需要在SAP中定义RFC远程目标。必须定义SAP远程目标，这样SAP系统才可发送IDoc给适配器并应答RFC和BAPI。该SAP远程目标必须在创建应用程序视图之前进行定义。

现在，通过使用Application View Console 来创建应用程序视图。选择SAP适配器并创建一个新浏览连接。然后，需要配置您的服务带有或没有负载平衡。图3显示了没有负载平衡的SAP一个例子。为了测试服务，进入Application View Administration 页面并点击要测试服务旁边的Test链接。在Test Service窗口，从SAP请求中复制适当的XML字符串。当点击Test时，结果显示在Test Results窗口。

　图3 不带负载平衡的SAP例子

在创建了应用程序视图以发送和接收schema之后，可从应用程序视图创建一个控件。该SAP Application View 控件可在业务流程中使用。

为orderChange业务流程编码

本节我们将看看orderChange 业务流程的JDP，以及前几篇文章中创建的流程的不同部分的编码。让我们来看看详细内容。

启动流程:

我们已经了解了如何通过文件控件向目录写修改订单。XML文件可用于在任何订单管理系统中创建修改订单，我还展示了如何使用SAP适配器来连接SAP。我们查看了如何使用BEA Application Explorer来连接到SAP，以便创建请求和应答schema。我们了解了Application View Console如何使用这些schema，以及如何创建Application View。Application View可暴露于Weblogic Workshop以创建Application View 控件。Application View控件可在业务流程中使用，以在SAP中创建修改订单。

在下一篇也是最后一篇文章中，我们将了解将JPD流程转换成特定于WSBPEL的流程，以及WLI如何完成这一任务。我们将考察这一流程以了解它如何执行。我们还将了解监视流程的工具，并了解HP和SAP如何合作，以便在WLI中监视流程。

第5部分--使用WebLogic Platform创建业务流程模型进行订单管理

本系列文章的第1部分中，概要介绍了业务流程管理（business process management ，BPM）和该领域的规范。描述了订单修改的例子以及在WebLogic Integration中创建业务流程所需的步骤。在第2部分中，介绍了如何创建一个流程应用程序（orderChange）。在该应用程序中我创建了一个名为orderChange.jpd的新流程。为了启动该流程，我们增加了一个接收的ClientRequest，然后添加了Web服务验证配置。

在第3篇文章中，我加入了一个决策点来处理来自验证配置Web服务的结果。决策点有助于处理流程结果中的肯定和否定输出。然后，我给该流程添加了一个数据库控件，该控件检查要更改的订单的状态。最后，我添加了另一个决策点来处理数据库控件的结果。在上一篇文章中，我们介绍了如何将订单修改写入文件中，以及如何把该订单修改添加到基于ERP的系统（SAP）中。我们还分析了该流程的代码。

在本文中，我们将了解如何将创建的JPD文件公开为BPEL文件，以及如何执行这一流程，您还可以看到显示在WebLogic的Test Browser上的最终结果。我们还将了解如何在WLI中监控流程，以及如何使用惠普的OpenView来监控流程。

导出到BPEL

在以前的文章中，我们知道了如何在WLI中创建业务流程。它基于PD4J规范创建一个JPD文件。WLI gives允许用户通过BPEL导出器将该文件导出到WS-BPEL文件。

下面就是前述的JPD文件导出到BPEL后的结果：

合作伙伴信息如下：

流程启动：

作为ClientRequest的OrderChangeRequest：

JPD代码以注释形式出现：

调用validateConfig Web服务的流程：

第一个决策点用于确定配置是否有效：

调用订单状态数据库控件的流程：

第2个决策点用于确定订单是否可修改：

流程通过文件控件写文件：

执行流程

在执行流程时，可以在Test Browser中看到测试SOAP消息。执行时，可以看出它遍历了以下步骤：客户机请求；验证Web服务配置；第一个决策点；从数据库获取订单状态信息；第二个决策点；最后，将XML写入文件，流程结束。

显示了流程的验证配置节点。

显示了流程的最后一个节点，即写入文件。

监控流程

进行业务流程管理意味着要确保可以监控单个业务流程实例，以便确定它们在规定时间内完成。我们还希望收集性能指标，以改进和调优进程。可以通过WebLogic Workshop菜单中的WebLogic Integration Administration Console监控业务流程实例。在浏览器地址栏中输入 http://localhost:7001/wliconsole 这个URL。示例集成服务器的默认用户名和密码是weblogic/weblogic。单击Process Instance Monitoring，打开一个页面，进行以下操作(以下内容来自BEA)：

• 查看流程实例统计信息，包括每种状态（运行、挂起、异常终止、完成）的实例数。
• 查看选定实例的摘要或详细状态。
• 挂起、恢复或终止选定的实例。

通过HP Open View管理业务流程

前几节所述的对业务流程的管理需要包括以下能力：

• 当出现问题（管理出现异常）时，可以发出警报。例如，业务流程实例超出阈值，或者没有按照服务水平协议(service level agreement，SLA)完成，以及应用程序的某一部分出现错误。
• 使用业务流程视图、消息代理程序、消息代理程序通道、工作列表、适配器和事件生成器查看当前的业务流程状态，并能够追查详细的表征。我们需要给定流程实例的统计信息，以便知道：有多少实例已经完成、有多少实例正在运行、有多少实例在执行时违反了SLA、有多少实例已经终止、有多少实例已经异常终止，等等。
• 对业务流程及相关实体执行特定的操作，比如挂起一个进程或恢复一个挂起的进程。
• 能够实时监控关键的性能指标，如：业务进程的平均执行时间，业务进程成功率，适配器、消息通道和事件生成器的错误数。
• 接收前述性能指标的历史报告。

对于运行在WLI上的应用程序，前面所提到的大部分信息都可以在WLI执行引擎中得到，并且任一个外部程序都可以通过JMX Mbeans获得这些信息。这种信息可用性，与能够收集、分析信息并将信息以正确的形式呈现给正确的人的程序相结合，我们就可以管理业务程序了。

HP OpenView Smart Plug-in for WLI (WLI-SPI)插件就像胶水一样，将HP OpenView与WLI联系起来，使我们可以使用HP OpenView产品家族去管理WLI业务流程。在现有的HP OpenView管理系统中安装WLI-SPI之后，就可以通过工具，使用HP OpenView管理的全部功能来管理业务流程了。这些功能包括(以下内容来自DRC)：

• List Business Process Types（列出业务流程类型）、Instances（实例）、Adapters（适配器）、Event Generators（事件生成器）、Message Channels（消息通道）、System Archiver（系统档案库）及其相关属性。通过OV对以上各项执行管理操作。
• 实时监控业务流程的性能及其他相关指标。
• 在执行业务流程时通过通告监控关键性事件。比如，条件失败或违反性能SLA。
• 生成性能指标的历史报告。
• 能够定制SPI，使其包含特定于应用程序的监控和管理功能。

显示了如何使用HP Open View来监控业务流程。

结束语

在本文中，我们介绍了如何将JPD文件导入WS-BPEL文件，以及如何执行业务流程，并在Test Browser中查看结果。我们在Test Browser中看到了不同的流程节点是如何执行的。我们讨论了业务流程的管理。在WLI中可以通过WebLogic Integration Console进行监控。还可以使用HP Open View管理业务流程。HP Open View使用SPI通过JMX Beans管理WLI中的业务流程。

最后，要了解更多有关HP OpenView和BEA应用程序管理解决方案的信息，请访问http://openview.hp.com/bea站点。您会发现，BEA与HP OpenView的结合将为您提供更多的控制权和更大的灵活性，从而为您赢得竞争优势。

参考资料

• (BEA)WLI监控：http://dev2dev.bea.com/。
• (DRC) Kumar Pankaj的文章“Manage your business processes on BEA WebLogic Integration with the HP OpenView WLI-SPI”：http://devresource.hp.com/drc/columns/col0407a.jsp。