IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope: Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  WebSphere  >

集成 WebSphere Business Integration Server V4.3 组件创建独立业务集成环境

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别： 初级

Stuart C. Jones (stuartjones@us.ibm.com), 业务集成解决方案专家, IBM

2004 年 12 月 01 日

本文描述了如何集成 WebSphere Business Integration Server V4.3 的三个组件（WebSphere Business Integration Message Broker、WebSphere InterChange Server 和 WebSphere MQ Workflow）来形成一个独立的业务集成环境。并将重点放在这三个组件集成的几个可能机制之一上，这取决于项目需求及实施者的偏好。

引言

虽然完成 IBM® WebSphere® Business Integration Server 组件集成的不同机制都已形成文档，但那些文档散布在许多发行物上且分布在不同的地方。本文的目的就是要描述这些组件是如何集成在一起的，并向您提供详细的文档资源。

本文包含一个存在于现实生活中的客户方案——客户需要由每个组件提供的功能。此客户有这样的想法（当然不是正确的）：这些组件不能协同工作。通过展示 WebSphere Business Integration Server 组件可以协调的共同工作，我们既可以更正那种组件分离的错误印象，也可以展示使用适当的组件用于适当的任务是至关重要的。 此外，该方法遵循将所涉及组件分离的体系结构最佳实践，在这个最佳实践中，各种（相关）功能彼此分离并通过最适合的组件来处理。

本文没有包含构件。这样做的目的是让您直接地实现出这个过程，从而获取如何直接构造这类环境的知识和经验。





回页首


目标环境


图 1. 要构造的环境
图 1 流程图. 要构造的环境

上图中应该注意的要点：

  • 这个环境的主要（控制）路径是 WebSphere InterChange Server 的协作（collaboration）。
  • 协作使用 WebSphere Business Integration Adapter 连接其它组件。在这个环境中使用四个不同的 WebSphere Business Integration Adapters：JText (file) Adapter、JDBC (database) Adapter、WebSphere MQ Integrator Broker Adapter 以及 WebSphere MQ Workflow Adapter。这些连接被在协作内调用的服务所调用。
  • WebSphere Business Integration Message Broker 及 WebSphere MQ Workflow 是协作所调用的服务。WebSphere Business Integration Message Broker 提供验证服务，WebSphere MQ Workflow 系统提供面向人员（staff-oriented）的数据修复能力。
  • 在此描述的方案涉及 JText 和 JDBC Adapter 的使用。这些 Adapter 的实现并未在此文中描述（他们的实现相当直接且有良好的组织文档）。




回页首


问题描述

这个环境的实现包含六个步骤：

  1. 选择并提供适合于问题需求的协作。 对这里描述的问题，可能要从头构造一个协作或是重用现有协作。在本例中，我们重用现有协作。然而，这个协作缺少一步——调用基于人员（staff-oriented）的工作流程。要添加这个额外的步骤，因此就要描述它。
  2. 业务对象的选择。 正如上面提到的，这个问题使用现有协作。为尽量减少协作中的重复工作，本文使用一般的业务对象，该业务对象已普遍的为协作所定义。这里使用的是 X12 Electronic Data Interchange (EDI) 业务对象。其它组件需要“应用程序特定业务对象 (ASBO)”。
  3. 适配器元对象规格说明。 一些在方案中使用的适配器需要元对象来决定适配器操作的方式。您需要理解并设置这些元对象。
  4. 配制合适的适配器。
  5. 定义代理消息流。 这是一个简化的消息流（为示范所用）。
  6. 定义业务流程。




回页首


协作

在此示范中所使用的协作是一个现有协作，名为：HIPAA837Prof。有两个理由选择此协作。首先，此示范是为 healthcare 客户所用，他们想观察 EDI 数据结构的使用。此协作使用 EDI 837 结构（业务对象名为 X12_U1_837）。其次，这个协作有一个（主要的）合适的在服务调用方面的结构。参阅图 1，在这个环境中 WebSphere InterChange Server 中有一个输入，有四个与其他组件的交互。HIPAA837Prof 协作提供这四个交互中的三个，因此为实现提供了良好基础。

采取的第一个动作是取得这个协作模板的一份副本，所以原协作模板仍保留完整。在 WebSphere InterChange Server System Manager 中放置模板的一份副本，然后在副本的协作上进行改变。在下文中将代称以 HIPAA837Prof，当然您可以给定其它名字。在这个协作中要进行两项更改：

  • 在 HIPAA837Prof 协作中的第一个更改是使用复合的处理循环设计处理 EDI 837 记录。由于并不需要这个处理循环，所以将其从协作中去除。

    由于要使用协作而却要去除一个主要处理路径，这看起来是一种浪费，所以记得重用是这里的关键。目标是找到一些协作的可重用组件，而这进行的很顺利。您可以参见图 2 中的原协作，它显示 HIPAA837Prof 协作中的 SYNC LOGIC 方案：
    图 2. 处理 HIPAA 消息子图
    图 2 流程图. 处理 HIPAA 消息子图

    您可以看到"处理 HIPAA 消息"子图中修改后的协作方案，从主路径中去除相应的错误路径（图 3）：


图 3. 更改后的协作主路径
图 3. 更改后的协作主路径

假设这只是有可能，因为协作组件（处理消息及利用我们项目需要的服务调用）并不是这个处理路径的组件。

  • 第二个修改是附加的第四个交互（协作所需要的）。既然这个协作已经提供了四个所需要的服务调用中的三个，现在缺少这第四个调用，它调用 WebSphere MQ Workflow。添加第四个服务调用及其周边逻辑是非常直接的，因为 IBM 协作包含额外的正为此准备的空操作动作：允许简单的添加这样的附属物。他们通常被标记为：Additional Processing N，“N”是一些整数值（因为在每个协作中有许多空操作动作）。对这个协作来说，您可以使用空操作动作，Additional Processing 3 如下图所示（见图 4）：

    图 4. 在协作内调用 WebSphere MQ Workflow
    图 4 流程图. 在协作内调用 WebSphere MQ Workflow

    在 WebSphere Business Integration Message Broker 被调用执行消息检查后调用这个额外处理。这一步的目的是确定消息是否被已被标记为无效。如果消息是无效的，WebSphere Business Integration Message Broker 调用面向人员的 WebSphere MQ Workflow 处理来修复该消息。消息的状态是由 SerializerKey 变量的值来表示，“Y”代表有效消息，“N”代表无效消息。

    要创建协作中的这个方案，完成以下步骤：

    1. 在协作中打开标记为 Additional Processing 3 的方案。使用 Process Designer 工具构建方案（与图 4 中所示相同）。
    2. 在 Workflow Test 动作中，包含清单 1 中的代码。Workflow Test 检查 SerializerKey 字段，该字段从消息代理的服务调用中返回。


      清单 1. 测试消息代理的响应，决定是否调用 WebSphere MQ Workflow
      								
                
{
   sTemp = processingBusObj.getString("Content.SerializerKey").trim();
   if ( sTemp.equals("N") )
       { bBranch = true; }
   else
       { bBranch = false; }
    ToWorkflowBusObj.copy(processingBusObj);
}


      ASBO 中的 Valid 字段被映射到 Generic Business Object（GBO）（ X12_U1_837）中的 Content.SerializerKey 字段。SerializerKey 字段随机采取，所以它就不会在这个方案中的其它地方被使用。这个字段有一个“N”或“Y”值，它被用来设置布尔类型的变量：bBranch 的值。最后一个步骤是确保如果那个路径被去除的话在工作流环境可以得到业务对象输出。
    3. 要依靠 bBranch 变量的值来构造分支目的节点。如果 bBranch 值为“true”那么就调用 WebSphere MQ Workflow，否则就不调用。使用 MQ Workflow 的 WebSphere Business Integration Adapter 调用 WebSphere MQ Workflow。
    4. 如果调用了 WebSphere MQ Workflow 的服务调用，那么在返回上就需要附加步骤。需要确保工作流环境对数据所作的任何改变被复制回由主处理路径所使用的业务对象内。添加一个动作并包含清单 2 中的代码来完成这个步骤。


      清单 2. 从 WebSphere MQ Workflow 将响应复制到当前业务对象
      								
                
{
  processingBusObj.copy(ToWorkflowBusObj);
  ToBusObj.copy(ToWorkflowBusObj); 
}

  • 最后，重新编译协作模板使更改奏效。右键单击 System Manager 中的 collaboration，然后点击 Compile。
  • 一个最后注意事项，上面所示 Java™ 代码是作者将自定义 Java 代码放置在协作中的第一个尝试。有两种方法来做这件事。第一个方法是阅读 InterChange Server and Toolkit > Development > Collaboration 上的 Collaboration Development Guide，它给出了所有在环境中能得到的 API 的详细说明。第二个方法是研究现有协作代码，然后复制其现有代码。本示范即使用了后一种解决方法。复制现有代码总是要比自己构造要简单的多。

或许从这里取得的主消息是改变协作使其通过本身提供定制信息处理并不是特别困难。当想要提供某一概念的示范或证据时，这应该始终是第一位的。





回页首


业务对象

所选择的协作使用的普通业务对象（Generic Business Object）是 X12_U1_837 业务对象。它是一个大型的、有继承关系的对象，所以这里就不予展示。这个 BO 被包含在 HIPAA837Prof 协作模板中，该模板被包含在 IBM “Health Insurance Portability and Accountability Act (HIPAA)” 解决方法集中。

在方案中使用的 ASBO 保持尽可能的简单——没有必要使其复杂。示范场景不需要指定特定的复杂功能，所以没有必要进行过于复杂的工作。示范需要四个 ASBO：为文件所用的、为数据库所用的、为代理所用的以及为工作流所用的。除 Message Broker 外，其它的 ASBO 都是相同的，均表示为 healthcare 声明。他们包含以下字符串字段：

  • Userid
  • ClaimRefNumber -- 该 ASBO 的唯一标识符
  • Name
  • Address
  • City
  • Postcode
  • Country
  • TransactionType -- 对象中描述的所需类型
  • Provider
  • ClaimAmount

第四个 ASBO（为代理所用的）包含一个附加字符串字段——Valid，在上文中提到过。它被用来指示声明数据的有效性。在消息流部分介绍这个字段的设置。简而言之，为示范之目的，通常没有必要使得业务对象太大或过于复杂。如果这样（业务对象太大或过于复杂）使得他们难于（也就是说，存在出错的可能）构造，而且会感觉用户接口不是很好。

从 GBO 映射到 ASBO

将 ASBO 中的字段映射到 GBO 中的字段，按如下方法：

  • Userid < -- > X12_U1_837.Content.Userid
  • ClaimRefNumber < -- > X12_U1_837.Content.TracerId
  • Name < -- > X12_U1_837.Content.Message.L1000A.N2.Name
  • Address < -- > X12_U1_837.Content.Message.L2010AA.N3.Address_Information
  • City < -- > X12_U1_837.Content.Message.L2010AA.N4.City_Name
  • Postcode < -- > X12_U1_837.Content.Message.L2010AA.N4.Postal_Code
  • Country < -- > X12_U1_837.Content.Message.L2010AA.N4.Country_Code
  • TransactionType < -- > X12_U1_837.Content.Message.BHT.Transaction_Type_Code
  • Provider < -- > X12_U1_837.Content.Message.L2000A.PRV.Reference_Identification
  • ClaimAmount < -- >
    X12_U1_837.Content.Message.L2000A.L2000B.L2300.CLM.Monetary_Amount
  • Valid < -- > X12_U1_837.Content.SerializerKey

构造从 ASBO 到 GBO（反之亦然）实现转换的映射是很简单的操作，在此并不提及。





回页首


消息流

在这个环境中使用 WebSphere Business Integration Message Broker 来对消息进行有效性检查。这是为什么在此处使用 Message Broker 的部分原因。如果这是一个大型示范，那么也要为适当的方法处理消息使用代理。然而，示范连接性和交互是本文的主要目的，所以使用简单的消息流。有效性检查非常简单，只是对一些 ASBO 中 Claim Amount 的范围检查。消息流显示于图 5 中：


图 5. 消息流
图 5 数据流程图. 消息流

要为这个消息流构造三个路径：

  • 提供审查路径——位于消息流顶端。消息流的这个分支总是要执行（只要输入消息成功的被解析）并且激活验证，该验证是一个通过消息流的特定消息——即使看起来没有给 InterChange Server 返回任何东西。添加 Compute 节点（本例中称作 AddTrackData）向消息中插入一些合适的信息。在清单 3 中使用 Extended Structured Query Language (ESQL)。您或许选择包含其它信息于其中。



    清单 3. 向消息中添加审查数据
    						
            
	SET OutputRoot.XML.MBClaim.Track = 'Message passed 
		through validation routine';
	SET OutputRoot.XML.MBClaim.POSTCODE = '00000';


  • 添加 Filter 节点来测试声明的数量。包含清单 4 中的 ESQL 来进行适合的测试。如果声明数量少于 100,000，那么消息就被认为是有效的并成功返回到调用 Adapter：


    清单 4. 在 WebSphere Business Integration Message Broker 消息流中测试声明数量
    						
            
	IF (Body.MBClaim.CLAIM < 100000) THEN RETURN TRUE;
		ELSE RETURN FALSE;
		END IF;

  • 如果声明数量大于（或等于）100,000，那么即使消息仍可以成功的返回到调用 Adapter，也被认为是无效的。添加 Compute 节点（Invalid Claim，在图 5 中）并包含图 5 中的 ESQL 来设置适当的应答信息。


    清单 5. 为回应 WebSphere InterChange Server Collaboration 而设置适当的消息字段
    						
            
	CALL CopyMessageHeaders();
	CALL CopyEntireMessage();
	SET OutputRoot.MQMD.CorrelId = InputRoot.MQMD.MsgId;
	SET OutputRoot.MQMD.Feedback = MQFB_APPL_FIRST + 2;
	SET OutputRoot.MQMD.MsgType = MQMT_REPORT;
	SET OutputRoot.XML.MBClaim.VALID = 'N';


    如果声明数量少于 100,000，那么消息就被认为是有效的并成功返回到调用 Adapter。包含 Compute 节点（图 5 中 SetReply）并包含清单 6 中的 ESQL 来设置应答消息的合适值。

清单 6. 为回应 WebSphere InterChange Server Collaboration 而设置适当的消息字段
				
        
	CALL CopyMessageHeaders();
	CALL CopyEntireMessage();
	SET OutputRoot.MQMD.CorrelId = InputRoot.MQMD.MsgId;
	SET OutputRoot.MQMD.Feedback = MQFB_APPL_FIRST + 2;
	SET OutputRoot.MQMD.MsgType = MQMT_REPORT;
	SET OutputRoot.XML.MBClaim.VALID = 'Y';
	SET OutputRoot.XML.MBClaim.POSTCODE = '00000';

假设这是一个非常直接的消息流，而且消息检查并不十分严格。这是十分慎重的。本文的目的是示范 WebSphere InterChange Server 可以调用消息流，而它的回应可以被返回且可以遵照行事。另外，我们遵循保持组件的简洁明快这个原则。





回页首


业务流程

如果上面消息流的返回值显示为无效消息，那么我们需要调用 staff 函数来修改这个消息并使其返回至协作。因此，我们需要 staff-oriented 流程，执行它我们就可以看到数据，根据需要改变它，然后返回协作。这可能是最简单的业务流程，只由一个动作组成（从协作中输入然后返回到协作中）。在 WebSphere Business Integration Modeler 中对其进行了模型化，整个业务流程显示于图 6 中。


图 6. 调用用户检查服务的业务流程
图 6 流程图. 调用用户检查服务的业务流程

这个流程导出到 WebSphere MQ Workflow，并运行于提供的 WebSphere MQ Workflow Client 中——为尽量简化之目的。输入和输出数据都是相同的，如图 7 所示：


图 7. 输入和输出数据
图 7. 输入和输出数据

正如所看到的，这符合前面提到的应用程序规格说明业务对象。





回页首


WebSphere Business Integration Adapters

本文最复杂的部分留在最后。现在我们已经有了业务对象、协作、消息流以及流程，现在是把所有东西串在一起的时候了。我们可以使用 WebSphere Business Integration Adapters 来完成此项操作。要使用四个适配器：

  • WebSphere Business Integration Adapter for JDBC
  • WebSphere Business Integration Adapter for JText
  • WebSphere Business Integration Adapter for WebSphere MQ Integrator
  • WebSphere Business Integration Adapter for WebSphere MQ Workflow

清单中前两个适配器有着很直接的配置，所以没有在本文中描述。后两个适配器有些复杂，所以下面对他们的配置进行讲解。

WebSphere Business Integration Adapter for WebSphere MQ Integrator

这个适配器所需要的能力是取得业务对象并将其转变成合适的 MQ 消息，将消息放置在合适的队列中使得代理可以监听，等待响应的生成然后将响应消息转变成合适的响应业务对象。

因此，在这里我们使用适配器同步代理的请求。在这个环境中还可以使用其它应用模式，如事件处理和异步请求／应答——这些在 WebSphere Business Integration Adapter 手册中提及，在左侧窗口的 Adapters > Adapters > Technology 中。

这是我们需要采取的一系列步骤，来实现同步请求／应答交互模式，从 WebSphere InterChange Server 到 WebSphere Business Integration Message Broker：

  1. 安装、配置适配器。
  2. 构造合适的业务对象。其中的一些已经在上文中业务对象的讨论中提到了。这个适配器环境需要附加的业务对象，我们已经知道是：元对象。
  3. 确保代理中的消息流构造一个合适的适配器可以处理的应答。

安装、配置适配器
本文假设您已经完成适配器的安装过程。安装这个适配器与安装其它的适配器一样都是直接且没有困难的。其中有一步可能不同，不像其它组件， 适配器并不被 Windows XP 所支持，而这个示范正是在这样一个环境上安装的。要绕过这个限制，将适配器安装代码设置为 Windows 2000 兼容模式操作。需要这样做是因为安装过程中的 OS 级别检查很难检查到。

依照下列步骤配置代理适配器：

  1. 或是简单的配置适配器，或是使用您可以得到的另一个适配器，打开 Connector Configurator 编辑适配器配置。
  2. 选择 Connector Specific 选项卡，然后设置下列参数：
    • 设置 Channel 属性为 WebSphere MQ 队列管理器中的 WebSphere MQ SVRCONN 通道名，该管理器为消息代理服务。
    • 设置端口属性为 WebSphere MQ 队列管理器监听器监听端口
    • 设置 DatahandlerConfigMO 为 MO_DataHandler_DefaultXMLConfig。这意味着适配器处理的 ASBo 是作以 XML 格式进行串行化及解析的。
    • 设置 ConfigurationMetaObject 参数为适配器元对象的名字。这个元对象在下文描述。
    • 设置 ReplyToQueue 参数为将要放置在 MQMD 中的 WebSphere MQ 响应队列的名字。初始消息的 ReplyToQ 字段。队列名字以 URL 格式表示，如下：
      队列： //队列管理器名/队列名
    • 设置 InputQueue 参数为队列名，适配器将监听此对列并取得响应消息。在本示范方案中， ReplyToQueue 的值与 InputQueue 相同。假设 ReplyToQueue 的规格说明也是两个必须属性中的一个，他们同步代理请求。
  3. 在 Standard Properties 选项卡下，设置 DeliveryTransport 参数为 IDL。由于这个适配器是在同步模式才进行操作的，且没有事件处理，所以选择 IDL 传输。这保存了需要配置的数量，特别是在 WebSphere MQ 层次上。

构造合适的业务对象
仍需要为适配器创建两个附加业务对象（BO）。

  • 为代理创建高层（high-level）业务对象。 发送给代理的数据格式是 XML。之所以使用这种方式，是因为它是最直接的将数据取得给代理的机制——而并不需要使用更加复杂的 MRM（Message Repository Manager）定义。XML 数据处理器是适配器中的组件，它将 BO 转换为串行的 XML（反之亦然），并且它需要特定的 BO 结构层次来支持。需要这个的理由是 XML 文档可能需要除业务数据及名字之外的信息——如 XML 声明。诸如此类的信息在高层 BO 中指定。所以，要使用高层 BO（图 8）。
    图 8. 在适配器中 XML 处理的高层业务对象
    图 8 屏幕抓图. 在适配器中 XML 处理的高层业务对象


    在上面的例子中，父 BO 称作 XMLDocument_MBClaim（在窗口的标题栏中所看到的）实际的业务对象称作 MBClaim，在窗口的第一行显示。XML 元素名是从 Application Specific Info 中派生而来，如上图所示的窗口右侧。这些名字的通信通常引用代理中的数据元素。假设本例没有指定附加 XML 信息，所以这是一个很简单的父业务对象。
    在 数据处理器指导中对此有描述（在左侧窗口中选择 Adapters > Development > Data handler）。在适配器规格说明指导中没有关于它的信息。
  • 创建元对象，控制适配器的操作。 需要这个元对象，因此适配器可以知道该对出入消息做些什么。需要处理每一个业务对象，BO_verb 名有个 BO 属性。所以，有一个称作 XMLDocument_MBClaim_Create 的属性来处理上面的业务对象和创建 “verb”（所使用的那一个）。与这个属性相关联的 Application Specific Information 将包含一系列名称／值对来表示输入消息被转换为业务对象的方式。这个字符串如以下形式：

    InputQueue=queue: //WBRK_QM/REPLY;InputFormat=MQSTR;OutputQueue=queue://W
    BRK_QM/REQUEST?targetClient=1;OutputFormat=MQSTR;ResponseTimeout=600000

    解释如下：
    • 代理中适配器的入站消息，在 Connector Specific 属性中提供的监听队列名，如上文所述。当接收到消息时，队列名和消息格式（MQMD.Format）与元对象中的属性进行比较。当找到符合之对象，Data Handler 知道哪个业务对象创建哪个恰当的动词。所以，当以 MQSTR 消息格式在 REPLY 对流中接收了一个消息时，名为 XMLDocument_MBClaim 的 BO 被用来创建动词。
    • 对适配器出站信息队列名显示该往哪里发送出站信息以及消息格式是什么。它也指出了并不需要 MQRFH2——规格说明上指定 targetClient=1（这意味着最终目标是 MQ 而不是 JMS）。最后的参数是 ResponseTimeout 值。牢记有两个参数来表示与代理的同步交互。一个是 ReplyToQueue 属性，另一个是 ResponseTimeout。它是以毫秒为单位的，我们将其设置为十分钟。

确保消息流构造合适的应答
为使得同步模式内的适配器操作与适配器同步，需要适当的配置消息代理消息流来返回适配器消息的正确格式。与此相关的内容在 WebSphere Business integration Message Broker 的相关章节有所阐述，总结如下：

  • 消息必须被返回至被适配器监听的队列管理器和队列中。消息流开发人员必须与适配器开发人员合作来相应的配置两个系统。
  • 适配器线程等待特定消息，此消息的 MQMD.CorrelId 被设置为请求消息中的 MQMD.MsgId。在代理部分的 ESQL 对此有所展示。
  • MQMD.Format 字段必须与在元对象中预期并指定的格式相符，如上文中所描述的。对示范环境来说，输入的消息格式被设置为 MQSTR（被适配器）并把此内容复制到位于代理中的输出消息中。
  • MQMD.MsgType 必须被设置为 MQMT_REPORT。在上文代理部分 ESQL 中已对此展示过。
  • 为表明执行是成功的及业务对象数据已经改变，MQMD.Feedback 被设置为 MQFB_APPL_FIRST + 2。另外，原始输入消息可以返回给协作。不同的可以被设置的返回代码在适配器文档中有所陈述。

WebSphere Business Integration Adapter for WebSphere MQ Workflow

示范环境的最后一块是 WebSphere MQ Workflow Adapter 的安装。WebSphere MQ Workflow 业务处理可以通过以下方法开始：在 Workflow 中放置特定格式的消息。回应（在处理的最后阶段）被放置在被工作流适配器所监视的回应队列中。

对此适配器需要进行三个配置：

  1. 安装、配置适配器。
  2. 构造适当的业务对象。与代理适配器一样，工作流适配器也需要建立元对象。
  3. 确保工作流过程与适配器配置是一致的。

安装、配置适配器
本文假设您已经完成适配器的安装过程。安装这个适配器与安装其它的适配器一样都是直接且没有困难的。其中有一步可能不同，不像其它组件，适配器并不被 Windows XP 所支持，而这个示范正是在这样一个环境上安装的。要绕过这个限制，将适配器安装代码设置为 Windows 2000 兼容模式操作。需要这样做是因为安装过程中的 OS 级别检查很难检查到。

依照下列步骤配置工作流适配器：

  1. 或是简单的配置适配器，或是使用您可以得到的另一个适配器，打开 Connector Configurator 编辑适配器配置。
  2. 选择 Connector Specific 选项卡，然后设置下列参数：
    • 在同步模式下使用适配器。消息将被传递给消息流，适配器将等待回应。还有，既然在适配器中没有使用时间处理，您就可以使用 IDL 作为适配器的传输机制。
    • 设置 OutputQueue 属性为 FMC.FMCGRP.EXE.XML。这将使用工作流队列为工作流传递请求。
    • 指定合法的用户和密码以允许适配器可以连接到工作流系统。设置 ApplicationUserID 为 ADMIN、 ApplicationPassword 为 password。这些是默认的用户／密码设置。
    • 设置 ReplyToQueue 属性为 MQWFCONN.REPLYTO。工作流过程将使用这个队列来应答适配器。适配器执行同步请求，因此需要应答队列。
  3. 选择 Standard Properties 标签页设置 DeliveryTransport 属性为 IDL。

构造业务对象
要调用工作流过程，您需要构造 XML 消息并将其放在特定的队列中。调用正确的队列是适配器配置的工作，如上文中所述。为请求和应答构造 XML 消息是有方法办得到的：主要是通过适当的元对象的构造。

这里有两点需要考虑：

  • 适配器依靠与 Workflow 环境交互的类型需要不同类型的元对象。可能需要源于 Workflow Process Template、Workflow Container、Workflow Process Instance 以及 Workflow Activity 的信息。在示范环境中，我们初始化一个新的实例并等待（同步地）它的完成。我们只需要处理模板上的信息，所以只需要一套元数据业务对象。
  • Workflow 环境可以容纳不同的处理实例输入输出数据结构，而协作却不能。这意味着需要唯一的父对象来保持与 Workflow 处理交互中所使用的输入输出数据结构。当调用映射时，GBO 被复制到 ASBO 组件的输入数据结构中，Workflow 处理在返回时将 ASBO 组件的输出数据结构复制到 GBO 中。

    这个机制与在 Message Broker Adapter 中所使用的机制大不相同。

需要的业务对象结构是包含元数据对象、输入对象以及相当数量输出对象的高级对象。在顶级对象 Business Object Level Application 的 General 选项卡内提供了元对象规格说明，如图 9 所示：


图 9. 工作流适配器业务对象的 BO Level Application Specific Information
图 9 部分屏幕截图. 工作流适配器业务对象的 BO Level Application Specific Information

应用程序特定信息提供了对元对象的引用，它包含了 Workflow Process Template Configuration 信息， cw_mo_wfptcfg（参见图 9）。包含这个信息的对象是 TemplateConfig。如我们在下图中看到的，在顶级业务对象中有一个子对象 TemplateConfig （图 10）。


图 10. 工作流适配器业务对象中的子对象
图 10 部分屏幕截图. 工作流适配器业务对象中的子对象

在图 10 中显示的另两个对象是输入输出业务对象。顶级业务对象的展开图如图 11 所示。输入对象是高级对象中第一个非元对象（例如，位于 TemplateConfig 之后的那一个）接下来的便是输出对象。由于工作流使用的输入输出数据格式是 XML，所以我们需要 XML 元素名的规格说明。在图 11 右侧的 Application Specific Information 字段中显示有此信息。


图 11. 展开工作流适配器业务对象中的子对象
图 11 部分屏幕截图. 展开工作流适配器业务对象中的子对象

假设处理模板值没有被全部输入到对象定义当中（作为应用程序指定信息或默认值）。如果每个处理实例的信息都相同，那就有可能指定默认值并完成。然而，我们需要有一个唯一处理实例 ID。所以，虽然 TemplateConfig 有一些默认指定值，但所有值都要由 GBOtoASBO 映射来指定（参见图 12 中的视图）。


图 12. GBOtoASBO 映射视图
图 12. GBOtoASBO 映射视图

注意大部分值都被设置为常量，但 ProcessInstanceName 是自定义值，实际上是 ClaimRefNumber 和时间戳（timestamp）的混合值。

确保工作流过程与适配器配置兼容
在建模环境中，业务对象传递给工作流中提供的信息要匹配于定义于业务过程中的信息。确保要达到提到的这两点：





回页首


运行范例

要运行该范例，必须输入一些业务对象。JText Adapter 接收输入的对象并启动协作实例。调用 Message Broker 然后是 Workflow -- 依靠于输入消息的内容以及消息流所采取的动作。然后数据被返回到协作中并被写进数据库以及输出到文件中。

使用以下组件运行范例：

  • 输入对象，适合于 JText Adapter。这些对象的例子：
    • FileClaim:Create:scjones:ABC001:Stuart Jones:54
    • NorthRoad:NewYork:10345:USA:03:CGNA:106984:0000001\
    对于本例，":" 被用作为字段分隔符，"\" 是 BO（BODelimiter）结束符。这些对象需要 ASBO 和动词作为结构中的前两个字段，如上文中所展示的。
  • JText Adapter 接收这个对象然后通过 WebSphere MQ 通信传递给 WebSphere InterChange Server。
  • WebSphere InterChange Server 将传递 BO 给 Broker Adapter，它将调用监听队列的消息流。假设声明数量（claim amount）（倒数第二个字段）是 106984，那么 Valid 字段将被设置为“N”，因此将运行工作流处理。
  • 要运行工作流处理需要有被 WebSphere MQ Workflow 支持的 Workflow 客户端。它提供了框架环境并去除了对特定客户端处理工作的需要。客户端允许查看、编辑、返回协作中的数据。Workflow 客户端的安装很直接，所以不在这里展示（Workflow 客户端的安装请参见 WebSphere MQ Workflow Library）。
  • 然后更新数据库与文件。可以通过任何可以查看文件及数据库表的工具来检查结果。

因为以这种方式构造示范环境，所以就不需要其它组件。否则将有损于我们已经展示的内容。





回页首


结束语

本文的目的是展示如何在 WebSphere Business Integration Server 组件之间使用简单的交互模式实现集成。一旦搭建起这个简单的环境，就有可能以此为基准进行扩展并构造更复杂的交互模式。

在这个环境中，我们使用了所有的三个服务器组件加四个 WebSphere Business Integration Adapter（尽管这里我们只讨论了其中的两个）、XML 数据处理器以及 WebSphere Business Integration Modeler。我们可以为 WebSphere InterChange Server、Message Broker 添加环境，当然也可以添加 Workflow 的运行时客户端。整个环境将运行在 IBM Thinkpad T40 系列机器上。

希望本文能够使读者明白，使用 WebSphere Business Integration Server 包中的所有组件构建定制的示范并不是十分困难。

尽管这些步骤也许不是很简单，但却很直接。可以在相当短的时间内构造一个上面这样的示范。作者也是从头开始，并没有许多复杂部分（协作的更改、代理、工作流适配器）的知识背景，却能在四天内构造出这个示范。

如果需要对这个主题有任何更进一步的建议或需要更多的材料的话，请直接与作者联系。



参考资料



关于作者

Author photo

Stuart C. Jones 是 World Wide Technical Sales 小组的业务集成解决方案专家。他的职责包括整个 IBM 业务集成产品组合，他也协助客户去理解 IBM 业务集成产品，向他们展示如何使用这个架构去解决业务问题。




对本文的评价

太差！ (1)
需提高 (2)
一般；尚可 (3)
好文章 (4)
真棒！(5)

建议？







回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可，请勿转载。如果您希望转载，请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM      隐私条约      联系 IBM      使用条款