当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

使用 WebSphere Message Broker 支持 IBM Sterling Selling and Fulfillment Suite 与 WebSphere Commerce 的并行集成

Cong Ren, 软件开发人员, IBM

Cong Ren 是 IBM Software Group 位于多伦多的 IBM Canada Lab 的一名软件开发人员。他于 2011 年加入 Sterling Integration Development（Sterling 集成开发部），曾使用多种服务集成技术参与了 Sterling Commerce 和 WebSphere Commerce 的整体集成工作。在以前的工作中，他曾致力于 WebSphere Application Server 的安装、开发和测试。他拥有多伦多大学的计算机科学学士学位。

James Tang, 集成开发经理, IBM

James Tang 拥有与软件开发和项目生命周期相关的多个职位的工作经验。他的职责包括收集需求、设计和实现方案。他目前在多伦多的 IBM Canada Lab 担任 Sterling Commerce 的集成开发经理。该团队的使命是整合 IBM 的智慧商务产品组合，通过孵化 (incubation) 和原型制作为我们的客户创建最好的商务解决方案。

Leho Nigul, 解决方案架构师, IBM

Leho Nigul 是 IBM Canada Lab 的一名经验丰富的软件开发人员和解决方案架构师。他在 WebSphere Commerce、WebSphere Application Server、WebSphere Portal 和 Rational Application Developer 等产品的工作中曾多次担任技术领导和架构师的角色。Leho 拥有在蒙特利尔的 McGill University 的计算机工程学士学位，以及多伦多的 Schulich School of Business 的商业管理硕士学位。

Barbara Wong, 顾问软件开发人员, IBM

Barbara Wong 是就职于多伦多的 IBM Canada Lab 的一名软件开发人员。她于 2011 年加入 Sterling Integration Development（Sterling 集成开发部），参与了 Sterling 和 WebSphere Commerce 的整体集成工作，在这项工作中，她使用了 WebSphere Message Broker 和 WebSphere Enterprise Service Bus。在以前的工作中，她曾致力于 WebSphere Application Server Installation Factory 开发、WebSphere Commerce 开发、DB2 开发、系统验证测试和开发。她拥有 University of Waterloo 的数学学士学位。

Barbara Wong, 顾问软件开发人员, IBM

James Chung, 软件工程师, IBM

James Chung 是位于多伦多的 IBM Canada Lab 的 WebSphere Commerce 和 Sterling Integration 开发团队合作的一名软件开发人员。

简介： 本文将介绍如何使用 WebSphere Message Broker 集成外部 Distributed Order Management 解决方案（比如 IBM® Sterling Selling and Fulfillment Suite）与 WebSphere® Commerce。并行集成 WebSphere Commerce 与 SSFS 使您能够充分利用这两种产品的的强大功能。

标记本文！

发布日期： 2012 年 1 月 30 日
级别： 中级
原创语言： 英文
访问情况： 655 次浏览
评论：

简介

IBM Sterling Selling and Fulfillment Suite (SSFS) 是最先进的订单和库存管理产品。SSFS 使您能够控制复杂的供应链流程，包括采购、汇总、管理和监视所有渠道的订单；管理客户仓库设施的库存、运营以及劳动力资源；保持流程和库存的完全可见性。

WebSphere Commerce 在电子商务解决方案领域中是一个行业领导者。电子商务不再仅仅是在线展示和销售产品。它应该提供跨所有客户接触点的、集成的、无缝的智慧购物体验。它应该跨多个业务渠道提供丰富、相关的、个性化的体验。但最终，其目的是利用您的品牌力量实现更大效益，并为您的客户提供一致的品牌价值。

并行集成 WebSphere Commerce 和 SSFS 使您能够充分利用这两种产品的的强大功能。

可以利用面向服务架构 (SOA) 的原理，通过使用 Enterprise Service Bus (ESB) 来实现并行集成。IBM 提供了三种 ESB 实现方法：WebSphere ESB、WebSphere Message Broker（以下称为 Message Broker）和 WebSphere DataPower SOA 设备。具体 ESB 技术的选择取决于您的特定需求、整体 IT 环境和可用的技能。

使用 WebSphere ESB 实现 WebSphere Commerce 和 SSFS 的并行集成在 WebSphere Commerce 信息中心已有大量记录。

本文展示了使用 Message Broker 作为 ESB 技术的一个并行集成解决方案。

回页首

示例应用程序文件

本文提供了一个您可以下载的 Project Interchange 档案文件 WCToSSFSMediationModule.zip。它包含一个完全配置的集成流程和消息样本，您随时可使用它进行部署和运行。您可以将该文件导入到您的工作区，浏览应用程序，然后从 WebSphere Message Broker Toolkit 中部署和运行它。

回页首

概述

任何 ESB 集成解决方案的重要部分都包括以下任务：

确定您必须连接的服务接口。
定义或选择正确的传输机制，
建立相应服务接口之间的适当传输流。

本文所描述的场景连接 WebSphere Commerce 的订单和库存服务接口以及 SSFS 相应的订单和库存服务接口。使用开放应用程序组 (Open Applications Group, OAGIS) 消息结构来定义 WebSphere Commerce 的服务接口。SSFS 使用自定义 XML 架构来表示 SSFS 服务的数据。因此，作为 Message Broker 消息流的一部分，您必须将 WebSphere Commerce 数据表示形式转换为 SSFS 的数据表示形式。ESB 层为 WebSphere Commerce 和 SSFS 之间的相关概念建立正确的映射。

本文假设 SOAP over HTTP 连接在 WebSphere Commerce 端，而 JMS 连接在 SSFS 端。

回页首

订单提交

从订单和库存管理的角度来看，订单提交场景可概括如图 1 所示。

图 1. 订单提交流程的数据流

如图 1 所示，作为该业务场景的一部分，您必须执行以下步骤：

将一个产品项添加到购物车。
检查库存跟踪系统中的可用库存。
为订单提交准备购物车中的产品项。
在库存系统中保留库存。
提交购物车的订单。
在订单管理系统中启动订单处理。

如您所见，步骤 2、步骤 4 和步骤 6 需要在 WebSphere Commerce 和 SSFS 之间进行消息交换。本文将描述如何使用 Message Broker 逻辑来实现这些操作的消息流。

从概念上讲，库存相关的信息流和订单相关的信息流是分开的。这样做是为了实现解决方案的模块化。从业务场景的角度来看，来自每个流的消息都可以参与相同或不同的业务场景。

检查可用库存流

如前所述，在本文中，我们假设通过 SOAP over HTTP 协议来完成 WebSphere Commerce 和 Message Broker 之间的通信。因此，来自 WebSphere Commerce 的请求会通过 SOAPInput 节点进入消息流。

图 2. GetInventoryAvailability 请求流的 WebSphere Message Broker 实现

在流的起始部分，您必须确定在 Message Broker 所接收的消息中指定哪项操作，可以在 InventoryServices 子流中根据检测传入消息中的操作名称来确定该操作。基于操作名称将消息路由到相应的节点，然后对其进行进一步的处理。在这个示例中，只需检测可用库存请求，并将相应的消息路由到 FindInventory_SetFunctionName 节点。该节点是 JMS 标头节点，您必须在此处指定在 SSFS 端调用的相应操作函数，用该函数处理可用库存请求（ApplicationProperties 消息字段中的 TargetFunctionName）。

此时，JMS 标头被添加到消息中，但它仍然必须将消息的内容转换成 SSFS 可以理解的数据结构。在这之前，需要保存 WebSphere Commerce 特定的 XPath 表达式，以后您可以在消息流中重用这个表达式。这是在 SetExpressionToLocalEnviornment 节点中实现的，该节点也是您暂时在本地环境中存放 XPath 表达式的值的地方。表达式的形式是扩展的 XPath 表示法，它在转换过程中被用作查询语言，根据一定的选择条件（如 ItemID 号）检索传入消息树的各个部分。

现在，您可以执行消息数据转换。这是在 GetInventoryAvailabilityToFindInventoryInput_Transformation 节点上完成的。此节点的目的是将可用库存请求数据的 WebSphere Commerce 表示形式转换为 SSFS 表示形式。由于该信息的 WebSphere Commerce 表示形式和 SSFS 的表示形式均使用了 XML，所以您可以使用 XSL 代码来实现数据转换。

除了转换消息的负载，您还必须设置相关的 JMS ID，确保对 SSFS 的请求可以与相应的响应匹配。要做到这一点，可以使用 SetSOAPReplyIdToJMSCorrelId 节点将 JMS 相关 ID 设置为来自 WebSphere Commerce 的原始 SOAP 请求的 SOAP ID。该方法将原始的 SOAP 请求 ID 绑定到了相应的 JMS 消息 ID。

此时，您差不多可以将请求发送给 SSFS，但您还需要将 XPath 表达式的值（您已经在本地环境中保存该值）保存在一个更持久的位置，如 WebSphere MQ 队列。这可以在节点 JMS MQ Transform、SetMQProperties 和 MQ Output 上完成。JMS MQ Transform 节点将 MQMD 标头添加到消息树，然后 SetMQProperties 用它来填充 MQMD Message ID 属性。表达式也创建在本地环境的消息树中的 XMLNSC 域内。设置好 Message ID 和 XMLNSC 域之后，MQ Output 会将消息发送给 SSFSMediation_LocalStorage_D 本地队列。

图 3. GetInventoryAvailability 响应流的 WebSphere Message Broker 实现

当 SSFS 处理来自 WebSphere Commerce 的请求时，它通过 FindInventory JMS Input 节点进行回复（图 3）。此时，您必须执行三项任务：

检索 WebSphere Commerce 所需的 XPath 表达式的值（在消息从 WebSphere Commerce 传输到 SSFS 的过程中，这个值存储在一个队列中）。
将回复从 SSFS XML 格式转换成 WebSphere Commerce 可以理解的 XML 格式。
确保您正确地匹配 SSFS 响应和来自 WebSphere Commerce 的原始请求。

第一项要完成的任务是从本地 WebSphere MQ 队列中检索表达式的值。与表达式相关的信息存储在原始 SOAP Reply ID 所对应的键下面，在我们的示例中，该键也对应于 JMS Correlation ID。通过以下节点执行检索任务：

SetJMSMsgIdToJMSCorrelId：需要它来使用与 JMS 相关 ID 相同的值来填充 JMS 消息 ID。
JMS MQ Transform1：这使消息从 JMS 转换为 MQ 格式。
GetExpressionFromQueue：需要它来真正从队列中检索值。

第二项要完成的任务是，使用 XSL 转换，将数据表示从 SSFS 转换到 WebSphere Commerce。这个任务被封装在 XSL 转换节点FindInventoryToShowInventoryAvailability_Transform。

对于第三个任务，您需要做的就是将 SOAP 响应消息的 SOAP ID 设置为与 JMS ID 相同的值。这在 PutSOAPReplyId 节点中完成。然后，回复被发送到 WebSphere Commerce。

库存保留流

如图 4 所示，库存保留流类似于上面所述的可用库存流。显著的区别是 ActionCodeFilter 节点，该节点用于区分两个操作：保留库存和取消库存保留。

图 4. 库存保留流的 WebSphere Message Broker 实现

在 XSLT 转换节点 ProcessInventoryRequirementToReserveAvailableInventoryInput_Transformation 中捕获的实际转换逻辑是不同的，因为您在转换不同业务功能所需的数据消息。

库存保留流和可用库存流之间的最后一个差异是，您并不需要存储（和检索）表达式的值，因为不需要相应的表达式来实现 WebSphere Commerce 和 SSFS 之间的适当数据转换。这个流中的所有其他操作实际上与可用库存流是相同的。

订单处理流

如上所述，订单服务被表示为一个单独的消息流。这样做主要是为了实现逻辑上的分离和部署的灵活性。类似于库存消息，订单相关的消息使用 SOAP Input 节点进入 Message Broker 运行时，如图5所示。

图 5. 订单处理流的 WebSphere Message Broker 实现

您可以使用 OrderServices 子流来隔离不同订单相关函数的处理。在此示例中，我们只支持 “process order（处理订单）” 函数。此函数对应的消息被路由到 CreateOrder_SetFunctionName 节点，在该节点处设置在 SSFS 上调用正确的操作所需的等效目标函数的名称（ApplicationProperties 消息字段中的 TargetFunctionName）。

与库存消息流类似，您可以使用 SetSOAPReplyIdToJMSCorrelId 节点确保已将 JMS Correlation ID 的值设置为与来自 WebSphere Commerce 的原始 SOAP 请求 ID 相同。

接下来，确保已在消息中设置的操作是 “TransferOrder”，并在 ProcessOrderToCreateOrder_Transformation 节点上执行相应的 XSL 转换，将数据表示形式从 WebSphere 转换为 SSFS。一旦完成转换，就为通过 JMS Output 节点将该消息发送到 SSFS 做好了准备。

图 6. 订单处理响应流的 WebSphere Message Broker 实现

如图 6 所示，必须转换 SSFS 的答复，以请求 WebSphere Commerce 端的确认消息。该操作是在 CreateOrderToAcknowledgeOrder_Transformation 节点中通过相应的 XSL 逻辑完成的。执行转换后，请确保消息中设置了正确的 SOAP 回复 ID。这里所使用的实现方法与库存保留流部分所描述的方法相同。

回页首

导入和设置示例

为了实现和运行本文所描述的消息流，需要在 WebSphere Commerce、SSFS 和 Message Broker 上进行相应的配置。以下各节将探讨与每个产品相关的每个独立配置。在执行配置步骤之前，您必须完成以下组件的安装：

IBM WebSphere Message Broker Toolkit Version 7.0
IBM DB2® Universal Database Version 9.7
IBM WebSphere Application Server Version 7.0
IBM WebSphere Commerce Version 7.0 with Feature Pack 3
IBM Sterling Selling and Fulfillment Suite Version 9.1

回页首

为 WebSphere Message Broker 配置 WebSphere Commerce

配置 WebSphere Commerce 所需要的步骤与基于 WebSphere ESB 的集成类似。有一点不同，该消息的 URL 值并不是指向 WebSphere ESB 中介模块，其 URL 值如下：

外部库存系统：

http://<full_hostname>:<port_number>/webapp/wcs/component/inventory/
 services/InventoryServices

外部订单系统：

http://<full_hostname>:<port_number>/webapp/wcs/component/order/
 services/OrderServices

<full_hostname> 是完整的主机名（包括域名），或部署了 WebSphere Message Broker 流的系统的 IP 地址。<port_number> 是队列管理器的服务侦听器运行所需的 HTTP 端口。您可以使用以下命令在 Message Broker 的命令控制台上检索端口号：

mqsireportproperties <broker_name> -e <execution_group> -o HTTPConnector 
 -n port

<broker_name> 和 <execution_group> 是部署流的代理和执行组的名称。

回页首

为 Message Broker 配置 SSFS

与 WebSphere Commerce 类似，与 Message Broker 相关的 SSFS 配置步骤也与基于 WebSphere ESB 的集成相似，这已记录在 WebSphere Commerce 信息中心。然而，在执行以下指示时需要考虑几个事项：

在 WebSphere ESB 的上下文中，借助基于 Web 服务的连接功能和构建于 WebSphere Application Server（以下简称 Application Server）之上的面向服务集成，它从 Application Server 继承了大部分名称空间，利用它们通过引导端口号查找名称服务。

与 WebSphere ESB 不同，Message Broker 并不是一个 Web 服务提供者，并没有运行任何服务器；相反，它使用消息队列实现通信。对于要建立的外部连接，您需要在 Java™ Naming and Directory Interface (JNDI) 名称空间中创建管理对象，这样外部 JMS 应用程序和 SSFS 就可以查找接受管理的对象，从而连接到 WebSphere MQ，并访问 MQ 目标，发送或接收消息。对于在 SSFS 中定义的通过 JMS 实现的所有入站 API 调用（从第一个 Generic JMS 节点到 API 节点的代码行），某些参数的值需要针对 Message Broker（以及您的现有环境）进行调整。特别是，您必须更新 Provider URL 和 Initial Context Factory，以便匹配绑定文件的位置和 SSFS 所配置的上下文工厂类型。参见表 1 中的示例。

表 1. 在 SSFS 中定义的通过 JMS 实现的所有入站 API 调用的参数值

参数	值
Sub Service Name	WC_findInventory WC_reserveAvailableInventory WC_createOrder WC_multiApi
Queue Name	SSFSAPIsImport_SEND_D
Provider URL	file:/opt/mqm/filebinding/
Initial Context Factory	File
QCF Lookup	SSFSAPIsImport_QCF
Transactional	Selected
Initial Threads	5
Selector	TargetFunctionName='findInventory' TargetFunctionName='reserveAvailableInventory' TargetFunctionName='createOrder' TargetFunctionName='multiApi'
Default reply-to queue Name	SSFSAPIsImport_RECEIVE_D

对于在 SSFS 中定义的通过 JMS 实现的所有出站 API 调用（从 API 节点到 Generic JMS 节点的所有行），对 SSFS 使用了一种机制，将 SSFS 中的数据变化通知 WebSphere Commerce。在 Message Broker 的上下文中，您必须调整 Provider URL 和 Initial Context Factory 参数。参见表 2 中的示例。

表 2. 在 SSFS 中定义的通过 JMS 实现的所有出站 API 调用的参数值

参数	值
Queue Name
Time to Live (seconds)	10
Provider URL	File:/opt/mqm/filebinding/
Initial Context Factory	File
QCF Lookup	SSFSAPIsImport_QCF
Persistent	Selected
Needs Compression	Not Selected
Commit of this message depends on parent transaction	Selected
Enable JMS Security	Not Selected

Sterling Commerce Real-Time Availability Monitor (RTAM) 用于生成可用库存数据负载 CSV 文件，以实现批量更新，并为库存调整生成 SyncInventoryAvailability 服务请求。用于配置 RTAM for WebSphere ESB 的步骤同样适用于 Message Broker。在为组织加载规则之前，您必须将 MadisonRoot 组织设置为一个维护自己的库存的 Inventory Organization，如下所示：
1. 转到 Application Platform > Participant Modeling > Participant Setup。
2. 搜索并转到 MadisonRoot 的详细信息。
3. 在组织详细信息中，转到 Roles&Participation 选项卡 > Advanced Attributes 选项卡 > Inventory 选项卡。
4. 选择 Inventory Information Available 和 This Organization Is a inventory organization 并单击 Save。

如果您在 Default 组织下创建了库存项，您必须在执行前面的步骤之后重置所有库存详细信息。

回页首

配置 WebSphere Message Broker

Message Broker 是 IBM WebSphere 产品组合中的一个轻量的、高级的集成代理，无论何种平台、协议或数据格式，它都能够跨多种环境整合来自大量不同应用程序的业务数据。换句话说，它可以凭借其先进的 ESB 功能在异构系统之间实现应用程序连接和业务数据转换。

如果将 Message Broker 运行时作为 WebSphere Commerce 和 SSFS 之间的 ESB，使其正常运作所需的配置步骤可拆分为如下：

创建 WebSphere Message Broker Queue Manager。
创建 Broker and Execution Group。
创建队列。
建立并配置 JMS 管理的对象。

有关 Message Broker 的更多信息，请参阅 IBM Education Assistant for WebSphere Message Queue V7 或 IBM Redbook: WebSphere Message Broker Basics.

创建 WebSphere Message Broker Queue Manager

启动 IBM WebSphere MQ Explorer。
右键单击 Queue Managers 文件夹并选择 New > Queue Manager。
在 Create Queue Manager 向导中：
1. 输入 MB7QMGR 作为 Queue Manager Name 并单击 Next。
2. 在下一个面板中，保留默认设置，单击 Next。
3. 在 “Queue Manager Enter configuration options” 面板中，选择 Create server-connection channel 选项，如图 7 所示，并单击 Next。假设 WebSphere Commerce 和 SSFS 在不同的计算机上，您必须选择此选项，以启用 TCP/IP 的队列管理器的远程管理。
  
  图 7. Creating the server-connection channel 选项
4. 在 Queue Manager Enter listener options 面板上，选择 Create listener configured for TCP/IP 选项，如图 8 所示，并输入您想用作侦听器端口的端口号。默认值是 1414。单击 Next。
  
  图 8. 创建侦听器
5. 成功创建 Message Broker 队列管理器 MB7QMGR 之后，选择它的 Listeners，如图 9 所示。成功创建队列管理器 MB7QMGR 后，转到 MB7QMGR > Advanced > Listeners。
  
  图 9. 选择侦听器
6. 在 Listeners 窗口的右侧，右键单击侦听器 LISTENER.TCP 并选择 Properties。在 General 属性下的左侧，将 IP 地址 字段修改为运行侦听器的完整主机名（图 10）。它是安装和运行 Message Broker 的计算机的名称。
  
  图 10. LISTENER.TCP 的属性
7. 单击 Apply，然后单击 OK。

创建 Broker and Execution Group

启动 IBM WebSphere MQ Explorer。
右键单击 Broker 文件夹并选择 New > Local Broker。
在 Create Broker Wizard 面板中：
1. 输入值 MB7BROKER 作为 New Broker Name，如图 11 所示，并单击 Next。
  
  图 11. 输入新的 Broker 名称
2. 在如图 12 所示的下一个面板中，输入您之前创建的队列管理器的名称 (MB7QMGR)。保留所有其他设置的默认值，并单击 Finish。请注意，在 Windows® 上，您必须拥有管理员访问权限才可以使用 WebSphere Message Broker Toolkit 或 WebSphere Message Broker Explorer 创建代理。在新建代理时，您可能会看到提示，系统会接受具有管理员权限的用户，或者要求输入一个管理员用户 ID 和密码。
  
  图 12. 新建代理

创建队列

启动 IBM WebSphere MQ Explorer。
右键单击 Queues 文件夹并选择 New > Local Queue，如图 13 所示。有关其他队列的更多信息，请参阅 WebSphere MQ 队列。

图 13. 启动本地队列创建向导
在 Create a Local Queue 面板上，输入队列的名称，如图 14 所示。所有其他字段都使用默认设置。单击 Finish。共创建了四个队列，每个队列都有惟一的名称。队列名称见以下第 4 步。

图 14. 创建队列
为以下每个队列重复上述第 1 至 3 步：
1. SSFSAPIsImport_SEND_D：存储从 WebSphere Commerce 到 SSFS 的请求消息。
2. SSFSAPIsImport_RECEIVE_D：存储从 SSFS 到 WebSphere Commerce 的响应消息。将响应消息看作是对那些存储在 SSFSAPIsImport_SEND_D 中的请求消息的回复。
3. SSFSAPIsImport_SEND_D：存储从 SSFS 发起到 WebSphere Commerce 的同步消息。例如，在 SSFS 端的库存变更必须与 WebSphere Commerce 同步。
4. SSFSMediation_LocalStorage_D：仅由 Message Broker 使用的本地存储，用于中继消息属性。例如，从请求流到回复流都使用 SOAPRelyId。

建立并配置 JMS 管理的对象

在任何应用程序都可以从 Java Naming and Directory Interface (JNDI) 检索接受管理的对象之前，您必须首先创建那些接受管理的对象，并进行相应的配置。

启动 IBM WebSphere MQ Explorer。
在 WebSphere MQ Explorer Navigator 面板的左边，右键单击 JMS Administered Objects 并选择 Add Initial Context，如图 15 所示，启动对象的配置进程。

图 15. 启动配置进程
在 Add Initial Context 面板中，设置以下属性：
1. 选择 File system选项为 JNDI namespace location。
2. “JNDI Service Provider Factory class” 被设置为默认值 com.sun.jndi.fscontext.RefFSContextFactory。
3. 浏览到您想存储 JNDI Namespace Location 绑定文件的目录，如图 16 所示。例如， C:\Program Files (x86)\ibm\WebSphere MQ\MB_FileBindings。您将文件系统指定为 JNDI 名称空间位置，因为绑定文件将被存储在本地文件系统上。
  
  图 16. 连接详细情况
4. 单击 Next。
5. 选择 Connect immediately on finish 选项，并单击 Finish。
6. 在完成时，您将看见在每个 JNDI 名称空间位置的 JMS Administered Objects 下面创建了两个目录，Connection Factories 和 Destinations（参见图 17）。
  
  图 17. 在 WebSphere MQ JMS 中的两类 JMS 管理的对象
右键单击 Connection Factories 并选择 New > Connection Factory。遵循 GUI 面板并设置以下属性：
1. 在 “Enter the details of the connection factory” 面板中，将 Name 字段设置为 SSFSAPIsImport_QCF，并且将 Messaging Provider 设置默认值 WebSphere MQ，如图 18 所示，并单击 Next。
  
  图 18. 创建 Connection Factory
2. 在 “Select the type of connection factory” 面板中，将 Type 字段设置为 Queue Connection Factory，如图 19 所示，并单击 Next。
  
  图 19. 指定连接工厂的类型
3. 将 Transport 字段设置为 MQ Client，如图 20 所示，并单击Next。
  Bindings 选项在此处无效，因为，只有使用连接工厂的 JMS 应用程序 (SSFS) 与队列管理器位于同一台计算机上时才能使用传输。由于此处使用的 JMS 应用程序在远程计算机上，MQ Client 是更合适的选项。
  
  图 20. 设置 Transport 字段
4. 使用在 “Enter the details of the object you want to create” 面板中提供的默认信息，单击 Next。
5. 在 General 选项卡下（图 21），双击您已设置的属性。
  
  图 21. 为每个相应的字段验证所有的值
6. 在 Connection 选项卡下，选择 Base queue manager，如图 22 所示。这是您的默认队列管理器 MB7QMGR。鉴于使用连接工厂的 JMS 应用程序 (SSFS) 在远程机器上，您必须在 Connection list 字段中将默认 localhost 值配置为实际主机名，并在括号中注明其端口号，使 JMS 应用程序可以建立连接。保留 “Connect options” 字段的默认值 Standard 并单击 Finish。
  
  图 22. 建立连接
右键单击 Destinations 并选择 New > Destination。按照 GUI 面板上的指示操作，并为您刚才在 Create the Queues 部分下面所创建的每个队列（SSFSMediation_LocalStorage_D queue 除外）设置以下属性：
1. 在 Name 字段中输入队列名称，如图 23 所示，并单击 Next。
  
  图 23. 创建目标
2. 使用该面板中的默认值，并单击 Next。
3. 在 General 选项卡下，选择您的默认队列管理器 MB7QMGR，并在 Queue 字段中输入队列名称，如图 24 所示。保留所有其他设置为默认值，并单击 Finish。
  
  图 24. 在 General 选项卡中指定队列管理器的名称和队列名称
4. 为以下每个队列重复步骤 A 到 C 的步骤：
  - SSFSAPIsExport_RECEIVE_D
  - SSFSAPIsImport_RECEIVE_D
  - SSFSAPIsImport_SEND_D
  请注意，上面的列表中缺少了 SSFSMediation_LocalStorage_D 队列，因为远程 JMS 应用程序并不使用它。其惟一用途是用于本地存储。

有关创建和部署 BAR 文件的更多信息，请参阅 WebSphere Message Broker V7 信息中心。

回页首

结束语

在本文中，您已了解到，WebSphere Commerce 和 Sterling Selling and Fulfillment Suite 的并行集成将带来 “一加一等于五” 的效果，让您可以充分利用两个最先进产品的价值。WebSphere Message Broker 提供了一个可靠并且高度可伸缩的的机制来实现该集成。

回页首

下载