Configuring WebSphere Adapter for SAP for high availability using Websphere Message Broker

This article shows you how to configure WebSphere Adapter for SAP (here after called SAP Adapter) with Websphere Message Broker (hereafter called Message Broker) in an active-active high availability (HA) solution. The article also shows you how to set up a shared queue to handle a Transaction ID (TID) store.

Matu Agarwal (matu.agarwal@in.ibm.com), Software Engineer, WebSphere Adapters team, IBM

Photo of Matu AgarwalMatu Agarwal is a Software Engineer on the WebSphere Adapters team at the IBM Software Lab in Bangalore, India, where he works in Development and Customer Support. He has a Bachelor of Technology degree in Computer Science and Engineering from Harcourt Butler Technological Institute in Kanpur, and has four years of IT experience working with various Java technologies including JCA. You can contact Matu at matu.agarwal@in.ibm.com.



Ribu Rajan (ribu_rajan@in.ibm.com), Software Engineer, WebSphere Message Broker Support team, IBM  

Photo of Ribu Rajan Ribu Rajan is a Software Engineer on the WebSphere Message Broker Level-3 Support team with IBM India. He has a degree in Computer Science and a higher diploma in Software Engineering, and he holds certifications in Java, Microsoft .NET, and WebSphere Application Server. He has four years of IT experience, and has worked with the WebSphere Application Server Services team and with WebSphere Message Broker Post-GA Test team. You can contact Ribu at ribu_rajan@in.ibm.com.



Ritesh Srivastava (ritessri@in.ibm.com), Software Engineer, Messaging team, IBM

Photo of Ritesh SrivastavaRitesh Srivastava is a System Software Engineer on the WebSphere Message Broker Post-GA Test team at the IBM Software Lab in Bangalore, India. He holds a Bachelors degree in Electronics and has five years experience in software testing and automation. You can contact Ritesh at ritessri@in.ibm.com.



21 March 2012

Also available in Chinese

Introduction

An active-active high-availability (HA) solution keeps two or more systems online at all times, so that applications and users can continue to work without interruption in case of any failure. You can set up IBM® WebSphere® Message Broker for HA by having multiple instances of the broker in an active-active configuration. Then if a broker crashes, another broker with the same applications running takes over to ensure continuous availability of the applications without any administrative intervention required. HA is of course essential in many scenarios such as those involving critical databases, financial transactions, and electronic commerce.

Prerequisites

To configure and deploy the module, you will need:

  • WebSphere Message Broker V7
  • WebSphere Adapter for SAP Software V7
  • Access to an SAP system with pre-configured IDoc/BAPI processing
  • Server machines with the required broker installations
  • A basic understanding of Message Broker and SAP Adapter. For more information on the two products, Resources at the bottom of the article.

Message Broker support for HA

Storing the TID store in a shared queue is not supported in Message Broker V6.1, because each broker has a separate TID store. Therefore if SAP Adapter delivers en event and the connection fails before the update is complete, SAP will attempt to redeliver the message to the other broker. Since the brokers have separate TID stores, the second broker could redeliver the event , even though the first broker has already processed it. Therefore Message Broker V6.1 could not guarantee once-only delivery.

HA setup for SAP Adapter on Message Broker V6.1
HA setup for SAP Adapter on Message Broker V6.1

Resolving the event duplication problem using Message Broker V7

Message Broker V7 supports a shared queue as the TID store, which enables the TID stores of two or more brokers to be configured on a single remote queue manager. Since all brokers read from a single TID store, Message Broker can ensure transaction integrity and avoid duplicate event delivery in the case of a connection failure.

HA setup for SAP Adapter on Message Broker V7
HA setup for SAP Adapter on Message Broker V7

Setting up SAP Adapter for HA

The scenario below uses two broker instances installed on separate server machines to achieve high availability. The queue manager used to maintain the TID store is a shared queue installed on a separate server machine. Therefore if one broker goes down, the other one will remain active and provide continuous availability. The scenario uses the following servers:

  • Server 1 -- Hosts remote queue manager SAPQM with the TID store and a SVRCONN channel
  • Server 2 -- Hosts Broker BRK1 with SAP message flow deployed and pointing to a CLNTCONN channel of remote queue manager SAPQM
  • Server 3 -- Hosts Broker BRK2 with SAP message flow deployed and pointing to a CLNTCONN channel of remote queue manager SAPQM

Creating a common TID store on Server 1

To achieve high availability, set up a shared queue for the SAP adapter event store on this Server 1. As explained earlier, the brokers will be configured to use a remote queue manager to persist the TID store for SAP transactional RFC (tRFC) data. With this configuration, two SAP message flows deployed to two different brokers can share the same TID store on the remote queue manager, and can therefore operate as a single RFC server. This configuration is essential if the SAP message flows have been configured with the same RFC Program ID.

To enable the two brokers to use the TID store in the remote queue manager, complete the following steps, which you can do either by using WebSphere MQ Explorer or by running the commands in WebSphere MQ runmqsc. This article uses commands for Microsoft® Windows®.

  1. Create the queue manager SAPQM:
    CRTMQM SAPQM
  2. Create the queue SYSTEM.BROKER.ADAPTER.PROCESSED to act as the shared TID store used by remote brokers:
    DEFINE QLOCAL('SYSTEM.BROKER.ADAPTER.PROCESSED')
  3. Create the server channel for the remote brokers to communicate with SAPQM. SAPBRKCHL is the channel name:
    DEFINE CHANNEL ('SAPBRKCHL') CHLTYPE (SVRCONN) TRPTYPE(TCP)
  4. Start the channel:
    START CHANNEL ('SAPBRKCHL')
  5. Create the client definition file AMQCLCHL.TAB:
    DEFINE CHANNEL ('SAPBRKCHL') CHLTYPE (CLNTCONN) CONNAME('myhost.ibm.com(1414)') TRPTYPE(TCP) QMNAME(QMGR)
    1. SAPBRKCHL -- SVRCONN channel name created in Step 3.
    2. myhost.ibm.com -- Hostname of server where shared queue manager is defined -- Server 1 in this example.
    3. 1414 -- Default listener port number where the listener is running on the queue manager SAPQM.
    4. QMGR -- Queue manager name, SAPQM.
  6. On Windows, you can find this file at
    C:\Program Files\IBM\WebSphere MQ\Qmgrs\QMGR_NAME\@ipcc\AMQCLCHL.TAB.
    Move this file to Server 2 and Server 3 and put it in a directory accessible to brokers BRK1 and BRK2.

Creating the SAP adapter Input node and configuring the inbound message flow

  1. Before creating and configuring the broker instance on Server 2 and Server 3, make sure your SAP Adapter message flow is ready.
  2. Run the Adapter Connection wizard for the SAP Adapter inbound scenario (ALE inbound interface) and create the message set for the IDoc (ORDERS05).
  3. Provide the RFCProgramId configured on the SAP end, on which IDoc would be sent to SAP Adapter.
  4. Name the SAPInput node created as SAPHA.inadapter.
  5. Configure the message flow to send the Idoc received by SAP Adapter to MQ queue.

For more information on creating and configuring SAP adapter node on Broker, see Resources at the bottom of the article.

Configuring broker instances and connecting them to TID store

Server 2

  1. Create a broker BRK1:
    mqsicreatebroker BRK1 -i [Serviceuserid] -a [Password] -q [BrokerQueueManager]
  2. Start the broker BRK1:
    mqsistart BRK1
  3. Configure broker BRK1 to pick the required JAR files to connect to SAP:
    1. Configure the JARs URL:
      mqsichangeproperties BRK1 -c EISProviders -o SAP -n jarsURL -v C:\SAP_JCO
    2. Configure nativeLibs:
      mqsichangeproperties BRK1 -c EISProviders -o SAP -n nativeLibs -v C:\SAP_JCO
      • Filepath -- sapjco3.jar and sapjco3.dll is copied at C:\SAP_JCO
    3. Restart BROKER BRK1
    4. Confirm that the broker properties have been set:
      mqsireportproperties BRK1 -c EISProviders -o SAP -r
  4. Connect the broker BRK1 to Toolkit.
  5. Create execution group SAPEG1 for broker BRK1.
  6. Create a configurable service for BRK1 to read the TID store in the remote queue manager:
    1. Create configurable service for BRK1:
      mqsicreateconfigurableservice BRK1 -c SAPConnection -o SAPHA.inadapter
      • AdapterNodeName -- The SAP adapter node is SAPHA.inadapter
    2. mqsichangeproperties BRK1 -c SAPConnection -n sharedTidStoreClientDefinitionFile, sharedTidStoreQmgr -v [PathToClientDefinitionFile],[RemoteQueueManagerName]
      • [PathToClientDefinitionFile] -- AMQCLCHL.TAB, which is copied from Server 1.
      • [RemoteQueueManagerName] -- SAPQM
    3. Restart broker BRK1.
    4. Confirm that the broker properties have been set as specified by the above steps:
      mqsireportproperties BRK1 -c SAPConnection -o SAPHA.inadapter -r
  7. Ensure that configuration for Server1 is ready, so that the TID store is ready for BRK1.
  8. Deploy the SAP message flow to SAPEG1
  9. After you have completed these steps, verify that the broker is using the queue on the remote queue manager by inspecting the user trace. If the setup was successful, a BIP3470 message is issued, specifying the queue manager that the broker is using as the TID store.

Server 3

For Server 3, use the same command as with Server 2 to create and configure broker BRK2. Then deploy the same message flow created earlier on SAPEG2. To confirm that the broker is using the TID store remotely, check the event log for a BIP3470 message.

Testing the message flow

  1. Make sure that all broker instances (BRK1 and BRK2 ) have the message flow in an active state listening for the IDoc.
  2. Send the IDoc from SAP to the configured RFC ProgramId.
  3. Go to the MQ queue mentioned in the message flow and verify that it received the IDoc sent from SAP. One of brokers would receive the IDoc from SAP.
  4. For testing purposes, stop the current broker instance (BRK1), which received the IDoc. The message flow deployed on Broker BRK2 should now receive any further IDocs.
  5. Send another IDoc from SAP to the configured RFC ProgramId. Go to the MQ queue mentioned in the message flow and verify that the IDoc was received by BRK2.

Important: In this article, you used two brokers to create an active-active HA configuration. Of course, more broker instances can be added as required, and if one of the broker instance crashes, the application will remain up and listen for IDocs. But in this article, there is a point of failure if the SAPQM queue manager goes down, as there is no backup for it. To add redundancy for this queue manager, you need to add a multi-instance queue manager -- for details, see Resources at the bottom of the article.

Troubleshooting

Check the points below to avoid common problems

  1. SVRCONN channel is up and running.
  2. Brokers on both servers have access to client channel definition file.
  3. Broker points to correct SAP JCO files.
  4. Values for sharedTidStoreClientDefinitionFile and sharedTidStoreQmgr are correct.
  5. To verify properties values on each broker, use the command mqsireportproperties [BROKERNAME] -c SAPConnection -o [ADAPTERNODE] -r
  6. For more details, see system logs, Event Viewer, or user or system traces.

Conclusion

High availability implementations build redundancy into a cluster to eliminate single points of failure. This article described an active-active high-availability configuration for WebSphere Message Broker and WebSphere Adapter for SAP Software, in which all broker instances are active at all times, and any one of them can receive an event.

Acknowledgement

The authors would like to thank to Ramkumar Ramalingam from the WebSphere Adapters Development team, and Devipriya Selvarajan from the WebSphere Technical Enablement team for their help in reviewing this article.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=804227
ArticleTitle=Configuring WebSphere Adapter for SAP for high availability using Websphere Message Broker
publish-date=03212012