构建业务流程

《构建业务流程》由会员分享，可在线阅读，更多相关《构建业务流程（8页珍藏版）》请在金锄头文库上搜索。

1、构建业务流程，第 2部分-WebLogic Integration 开发最佳实践文章工具推荐给朋友-打印文章时间：2004-12-22作者：Vijay Mandava, Anbarasu Krishnaswamy浏览次数：惡 本文关键字：本文是在 BEA WebLogic Integration 8.1 上构建业务流程的最佳实践中的第二篇。第一部分(WLDJ,第3卷，第6期)关注于团队开发和维护的最佳实践。在本文中，我们着重于创建具 有可伸缩性、可恢复性、异常处理、有保证的传送以及高性能的业务流程的最佳实践。本文适用于 WLI 应用程序的开发人员和设计人员。阅读本文的第一部分流程的版本控制最佳

2、实践指定流程文件的版本。原因很容易忽视版本控制，原因是流程无需任何版本就可以工作。但是对流程进行版本控制确实很 重要的，特别是对于那些长期运行的流程而言。升级一个流程时，如果流程没有指定版本，那么未 决(in-flight)实例要么终止，要么部署失败，这依赖于服务器的运行模式。如果服务器运行在迭代(iterative)模式，则流程中止，如果服务器运行在生产(production)模式，则部署失败。细节利用 WebLogic Workshop 的版本控制功能，您可以对业务流程进行更改，而无需中断任何当 前正在运行的流程实例。当您指定一个业务流程的版本时，您就创建了一个业务流程的子版本，该 流程共

3、享相同的公共URI (接口)作为其父流程。在运行时，被标记为活动的流程版本是那些被外 部客户端通过公共 URI 所访问的流程。您可以为业务流程指定版本，但不能为与该流程相关联的单独控件或者其他与业务流程相关的 组件(例如 schema 和转换)指定版本。当您指定一个业务流程的版本时，您也必须指定该流程 的子流程的版本，指定父流程的版本后，子流程的版本并不能被自动指定。所调用子流程的版本取 决于它所采用的版本策略。两个可用的策略分别是松散藕合（调用时确定版本）和紧密藕合（调用 父流程时设置版本）。这里要重点指出的是，版本之间的不同并不是彻头彻尾的，原因是所有的版本都是同一个接口 的不同实现。这也

4、就意味着，不同版本可以有相同的请求、回调方法（callback methods）以及静 态消息代理订阅（ static message broker subscriptions）。异常处理最佳实践为流程创建相应的异常处理。为所有流程创建全局异常处理。原因在业务流程的任何阶段出现已检查的或者未经检查的异常是很自然的事情。应当在业务流程中 对异常进行适当的处理。如果异常没有被显式地处理，那么该流程就可能中止且永远不会重试。这 也可能导致消息未被处理或者消息丢失。细节可以在三个级别上创建异常处理： 全局异常处理 针对一组节点 针对单个节点一般来说，异常会向上传播，从节点异常路径到组异常路径，再到全局

5、异常路径，直到它被处 理为止。换句话说，与节点相关的异常路径会首先执行，然后是与组相关的路径，再后是与起始节 点相关的路径（全局路径）。异常只会被处理一次，除非您的异常处理路径抛出一个异常；然后异 常会再次按照相同的顺序向上传播。对您的业务流程，您可以利用这种特性并创建满足特定异常处 理需要的异常路径逻辑。对于非事务性资源而言，可以在异常处理中进行补偿事务处理。恢复最佳实践在流程级和/或 JMS 队列级设置适当的 redelivery 属性。原因在流程中出现异常的地方，事务会回滚，同时流程可能会中止。如果没有设置合适的 redelivery 属性，那么用来启动流程的消息将被移到错误队列。移入错

6、误队列的消息将不会被业务流程再次进 行处理。相反，一个内部消息驱动 bean 将会读取该消息并调用该业务流程的全局异常处理。避免发生这种情况的一个推荐的方法是为 retry count 和 retry delay 都设置较高的值。细节流程级的属性是： Retry count:指定在第一次尝试执行业务流程失败后流程引擎应该试图执行该业务流程的次数。 Retry delay: 指定两次重试之间的时间间隔(以秒为单位)。确保重试次数和重试间隔合适。重试次数和重试间隔的乘积应该超过运行 JTA 恢复的时间。 如果需要调整重试次数和重试间隔，您可有以下的选择： 在您的 JPD 中认真设置 retry c

7、ount 和 retry interval。 为每个 JPD 工程(WebApp)的 async 和错误队列(error queues)设置 retry count 和 retryinterval 。注意这将会中断 JPD 上显式 retry 设置，但它是最容易的，也是推荐使用的方法。消息代理通道最佳实践最好使用 JMS header 值，而不是使用文档号。原因使用 header 值的速度远远快于使用一个文档元素，因为前者无需进行解析。细节消息代理通道和 Java Message Service (JMS) 主题有相似的属性，但它经过了优化，以便和WebLogic Integration流程、

8、控件和事件生成器(event generator) 起使用。我们推荐创建多个 通道(channel)，而不是让多个JPD用订阅筛选器(subscribtion filter)来监听单个通道。最佳实践创建业务流程来使用失效通道(dead letter channel)中的消息。原因如果该通道没有订阅者，或者由于筛选条件不满足而导致已注册的订阅者不匹配，那么该消息 被置入失效通道。如果该失效通道没有订阅者，置于该通道上的消息就会因被丢弃而丢失。细节当一个消息被发布到一个通道，同时未找到匹配的订阅者，则该消息会被重新发布到一个和该 通道类型相对应的失效通道。WebLogic Integration提

9、供了如下的失效通道： /deadletter/xml /deadletter/string /deadletter/rawData例如，一条发布到一个XML通道(即消息类型Type = xml的通道)的非匹配消息被发送 到 / deadletter/xml 通道。在设计时，当您创建 MB Publish 和 MB Subscription 控件时失效通道 是可用的。您的业务流程可以发布和订阅该失效通道。例如，当设计错误处理时您可以使用失效通 道您可以创建这样一个业务流程，它包含对失效通道的静态订阅和处理已发布到这些通道上的非 匹配消息的设计错误处理代码。WebLogic Integration

10、 Administration Console 中的 Message Broker 模块可让您对应用程序中的 所有 Message Broker 通道，包括失效通道进行监管。BP 事务边界最佳实践在进行流程设计的同时要记住事务边界( transaction boundaries)。原因流程中存在隐式的事务边界，它们将影响业务的行为。如果对其视而不见，它将导致无法预期 的结果。添加事务性边界将会为流程定义引入一个抑止点(quiescent point)。细节在 WebLogic Integration 中，流程在本质上是面向事务的。流程每步的执行都是在 JTA 事务 的环境中进行的。事务确保了一

11、个或者更多的操作将作为一个工作的最小单位来执行。如果事务处 理中的某个操作失败的话，那么所有的操作都将回滚，于是应用程序返回到其先前的状态。对业务 流程逻辑的设计决定了该流程是有状态的还是无状态的，于是也决定了给定流程环境中存在一个或 者多个事务处理。当您创建一个流程的时候，根据流程中放置基本构成元素(例如，control receive或者client receive)的位置而形成了隐式事务边界。在您添加流程节点的同时，流程中的事务边界会随着更改。 您也可以创建显式的事务边界，方法是选取相邻的节点并在一个与那些应用程序隐式创建的事务所 分开的事务中进行声明。流程所访问的资源也可以是事务处理的

12、一部分，这取决于资源的本质和提 供该访问的控件。可引入隐式事务边界的一些节点是： Event choice Parallel nodes Control receives无状态流程最佳实践最好用无状态流程，而不是有状态流程。原因有状态流程是作为实体 bean 而实现的，当存在抑止点时它们将被持久存储在数据库中。细节无状态流程是只在内存中执行的流程，并且不会在数据库中永久存储其状态。从技术上讲，它 被编译成一个无状态会话 bean。无状态流程所支持的业务情况涉及到短期运行的逻辑且有较高的性能需求。由于它不在数据库 中持久存储其状态，所以它对较低的延迟时间、较高的性能执行进行了优化。这里举一个示例

13、，一 个无状态流程异步接收来自客户端的消息，对消息进行转换，然后利用一个控件按照异步或者同步 模式将其发送给一个资源。另外一个示例是，一个无状态流程以一个消息代理订阅( message broker subscription)开始，对消息进行转换，并将其发布到另一个消息代理通道。现实中较为常用的情 形是对一个长期运行的业务事务进行建模。这可通过向通道发布消息将其构建为松散藕合的一组无 状态业务流程。由于无状态流程被编译成无状态会话bean，这就确保了数据成员只包含非特定实例 (non-instance-specific)数据。您不能显式地将一个流程配置为无状态的。在默认情况下，一个业务流程是无

14、状态的，直到您 向数据流中添加了任何的基本构成结构，譬如等待一个回复或者一条消息。这反过来强迫事务边界 和流程变为有状态的。因此，如果流程只运行在一个事务中的话，该流程就是无状态的。有状态流程有状态流程指的是运行在一个以上事务中的流程。这样的流程在数据库中有持久存储的状态， 并被编译成一个实体 bean。有状态流程所支持的业务情况涉及到复杂的、长期运行的逻辑，并且因此有特定的可靠性和恢 复需求。通过添加有状态节点或者强加事务边界逻辑的方式就能使一个流程变成有状态的流程(参 见事务边界)。例如，一个流程接收消息，进行转换，将其发送给一个业务伙伴，然后等待一个异 步响应，这样一个流程就是有状态流程

15、，因为“等待”的动作强加了一个事务边界。可引起抑止点的节点列表是： Control receive Event choice (起始节点除外) Parallel branching有些控件通常需要一个 control receive 并因此将会强制一个流程变成有状态的。这些控件的 一个部分列表包括： Worklist Timer 异步双向流程 JMS 订阅 消息代理订阅有状态流程由于其在数据库中有状态，所以其性能不及仅使用内存的(memory-only)无状态流程。然而，状态的持久存储往往是必要的，因为它可以确保：在系统停机的等待期间内，流程可以恢复并继续执行而不会丢失数据。在此等待期间内，系统资源会被有效的利用。在此期间，该实体 bean 可能会被钝化(passivated)，这将释放服务器上的内存。您不可以显示地将一个流程配置为有状态的。当位于流程顶部的流程起始节点有一个绿环时， 您就知道该流程何时是有状态的。并行节点最佳实践在使用并行节点之前，先要了解它们。原因使用并行节点可以隐式地改变流程的行为。并行节点可改变流程的事务处理行为和状态行为。 并行节点所谓的并行也仅仅是逻辑概念上的并行。细节 业务流程中的并行执行分支是逻辑上的并行；物理上它们是由业务流程引擎顺序执行的。