主动-主动高可用性 (HA) 解决方案保持两个或更多的系统始终联机，即便出现任何故障，应用程序和用户也能继续正常工作，不会出现出现中断。您可以在一个主动-主动配置中使用多个代理实例，设置 IBM® ">WebSphere® Message Broker 的高可用性。如果一个代理崩溃，另外一个运行相同应用程序的代理将取而代之，确保应用程序的连续可用性，完全不需要任何管理干预。当然，高可用性在很多场景中都极其重要，例如涉及关键数据库、财务交易和电子商务的场景。
先决条件
为了配置和部署模块，您需要具备：
WebSphere Message Broker V7 WebSphere
Adapter for SAP V7 软件 通过预先配置的 IDoc/BAPI 处理来访问 SAP 系统 安装了必要的代理的服务器 对 Message Broker 和 SAP Adapter 有基本
认识。
Message Broker 高可用性支持
Message Broker V6.1 不支持在共享队列中存储 TID 存储，因为每个代理都具有一个独立的 TID 存储。因此，如果 SAP Adapter 交付了一个事件，并在完成更新之前断开连接，那么 SAP 会尝试重新将消息交付至另外一个代理。由于代理具有独立的 TID 存储，因此第二个代理将重新交付事件，即便第一个代理已经对事件进行了处理。正因如此，Message Broker V6.1 无法保证仅有一次的交付。
Message Broker V6.1 上的 SAP Adapter 高可用性设置
利用 Message Broker V7 解决重复事件问题
Message Broker V7 支持将共享队列作为 TID 存储，运行在单独一个远程队列管理器中配置两个或更多代理的 TID 存储。由于所有代理均读取同一个 TID 存储，因此 Message Broker 就能够确保事务完整性，在发生连接故障时避免出现重复的事件交付。
Message Broker V7 上的 SAP Adapter 高可用性设置
SAP Adapter 高可用性设置
下面的场景使用了两个代理实例，这两个示例分别安装在不同的服务器上，用于实现高可用性。用来维护 TID 存储的队列管理器是安装在另外一台服务器上的一个共享队列。因此，如果一个代理发生故障，另一个代理仍将保持活动状态，以便提供连续可用性。该场景使用以下服务器：
服务器 1 -- 托管远程队列管理器 SAPQM 及 TID 存储和一个 SVRCONN 信道 服务器 2 -- 托管代理 BRK1，部署了 SAP 消息流，指向远程队列管理器 SAPQM 的一个 CLNTCONN 信道 服务器 3 -- 托管代理 BRK2，部署了 SAP 消息流，指向远程队列管理器 SAPQM 的一个 CLNTCONN 信道
在服务器 1 上创建通用 TID 存储
要实现高可用性，则需要先在服务器 1 中为 SAP 适配器事件存储设置一个共享队列。如前文所述，代理将配置为使用远程队列管理器，保持 SAP 事务 RFC (tRFC) 数据的 TID 存储。利用这样的配置，部署在两个不同代理上的两个 SAP 消息流即可共享远程队列管理器上的相同 TID 存储，因此可以作为单独一个 RFC 服务器运行。如果 SAP 消息流是使用相同的 RFC 程序 ID 进行配置的，那么这种配置非常重要。