Transactional behavior of WebSphere SAP Adapter

This article explains the transactional behavior of WebSphere SAP Adapter when used with IBM Business Process Manager and IBM Integration Bus. It also describes the transactional use of WebSphere SAP Adapter functions such as Wait on Commit, and Reset Property.

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.


developerWorks Contributing author
        level

Sowmya S. Grama (sowmyagrama@in.ibm.com), Level-3 Support Lead, WebSphere Adapters for SAP Software team , IBM

Photo of Sowmya GramaSowmya S. Grama is an L3 support lead and developer for IBM WebSphere Adapters for SAP Software and works at the IBM India Software Labs. She has seven years of experience in IBM working on different technologies and various products such as Adapters, Business Process Management suite of products, ITUAM, WebSphere Portal, and IBM Content Manager.



27 December 2013

Introduction

The IBM® WebSphere® Adapter for SAP Software (here after called the WebSphere SAP Adapter) supports local transactions but not global (XA) transactions, and therefore adding SAP transaction handling to client applications can be challenging. This article shows you how to easily implement complex SAP transactions using IBM Business Process Manager and IBM Integration Bus, enabling you to focus on business logic instead of on managing transactional contracts with the SAP system.

The article assumes that you have some knowledge of WebSphere SAP Adapter functions. For more information, see Resources at the bottom of the article.

A WebSphere SAP Adapter transaction using IBM Integration Bus

A message flow can run in a single transaction, which is started when data is received by an Input node, and can be committed or rolled back when all processing has completed. The SAPRequest node in the IBM Integration Bus Toolkit provides a Transaction Mode property that you can use to configure the SAP transaction.

Transaction Mode property

If you set the Transaction Mode property for the SAPRequest to Yes, then IBM Integration Bus tells the WebSphere SAP Adapter to invoke a SAP Commit call after completing the message flow.

Figure 1. Setting Transaction Mode property.
Transaction Mode property

If you set the Transaction Mode property to No, the WebSphere SAP Adapter does not invoke a Commit call. Setting this property to No is mainly used if your BAPI implementation has a implicit Commit call, or if you explicitly invoke BAPI_TRANSACTION_COMMIT in your message flow. Usually you need to set the Transaction Mode property to Yes or Automatic. If you set it to Automatic, the SAPRequest node uses the value set on the Input node that drives the message flow. For more information about the Transaction Mode property, see SAP BAPI transaction commit in the IBM Integration Bus information center.

Local coordinated transaction

You can configure message flows to be transactional so that they are executed under a single transaction. Changes should be committed only after the entire flow is executed, or rolled back in the case of any exception. The WebSphere SAP Adapter supports local transactions and you can configure a message flow with multiple SAPRequest nodes and other database nodes under the same transaction, which is called a local coordinated transaction.

As an example, consider a message flow to create and update bank account information by invoking a set of SAP BAPIs and Database nodes under a local transaction. Here is the scenario:

  1. Invoke BAPI for creating bank data: SAPRequestNode (BAPI_BANK_CREATE).
  2. Invoke DataUpdate node to update bank information in the database.
  3. Invoke BAPI to retrieve bank detail: SAPRequestNode (BAPI_BANK_GETDETAIL).
  4. Based on business logic, update the bank information using the respective BAPI.
  5. Invoke BAPI to updating the bank detail: SAPRequestNode (BAPI_BANK_CHANGE).
Figure 2. Local coordinated transaction
Local coordinated transaction

You can implement this scenario in two ways:

  • Set the Transaction Mode to Yes for all SAP and Database nodes that need to participate in this coordinated transaction.
  • Set the Transaction Mode for all of the nodes to Automatic, and set the Transaction mode to Yes for the Input node that drives this flow (in this scenario, MQInput node).

If any BAPI or Database node in the module fails, all changes up to that point should be rolled back. The WebSphere SAP Adapter leverages the transaction capability provided by IBM Integration Bus. The Transaction Manager coordinates the one-phase commit process, and enables the COMMIT to be called on SAP and the database only if all of the BAPI and Database nodes are executed successfully. Otherwise the entire scenario is rolled back.

WebSphere SAP Adapter transaction using IBM Business Process Manager

Here is a business scenario that demonstrates WebSphere SAP Adapter transaction behavior on IBM Business Process Manager. An organization needs a message flow that reads Employee Master Data from a legacy system and uses WebSphere SAP Adapter to upload it into two different SAP systems, one containing employee details and the other containing employee documents. They would like the transaction to commit only when updates to employee data is complete in all systems. The next section shows how the IBM Business Process Manager Transaction Behavior and Join Transaction properties can enable this scenario. The flow shows the interface to the legacy system, with Transactionality set to Global, and each WebSphere SAP Adapter outbound instance having the Join Transaction property set to True:

Figure 3. WebSphere SAP Adapter transaction setting in IBM Business Process Manager
user scenario

Setting Transactionality on the starter component of the flow means that this setting applies to all components in the flow. Setting it to Global means that all components participate in the transaction, and all WebSphere SAP Adapter outbound instances also participate in the Transaction. Setting the Join Transaction property to True means that the runtime has to wait for all components in the flow to complete before issuing a Commit or Rollback call.

Consider a case where the interface SAPOutboundInterface (Employee Details) and SAPImport (Employee Documents) has the Join Transaction Property set to True and False respectively. SAPOutboundInterface will not issue any Commit or Rollback calls until the transaction completes on all components in the flow, whereas the interface SAPImport will issue Commit or Rollback immediately after an update.

Setting the Join Transaction property

There are two ways to set the Join Transaction property:

  • In the last screen of the Adapter Discovery Wizard (also called Enterprise Metadata Discovery), which is titled "Specify service generation and deployment properties," use the checkbox to select Join Transaction:
    Figure 4. Join Transaction property using Adapter Discovery Wizard
    Join Transaction property using Adapter Discovery Wizard
  • You can also set it by adding the qualifier for the component in an assembly diagram. Select Properties => Details => Qualifiers tab => Add => Join Transaction:
    Figure 5. Join Transaction property using Qualifiers tab
    Join Transaction property using Qualifiers tab

Setting the Qualifier Transaction property

To set the Transaction property on the starter component, select Properties=-> Implementation => Qualifier tab => Transaction.

Figure 6. Transaction property for QOS
Transaction property for QOS

Capabilities and limitations when using Tx and non-Tx variants of WebSphere SAP Adapter with IBM Business Process Manager

With IBM Business Process Manager, the WebSphere SAP Adapter is available in two flavors: CWYAP_SAPAdapter_Tx.rar and CWYAP_SAPAdapter.rar. For more information, see the IBM Support Technote Transactional capabilities of WebSphere Adapter for SAP Software, which answers several questions regarding the function and use of these two flavors. It also describes the transactional behavior of the Adapter, and explains how it participates in global transactions in IBM Business Process Manager even though internally, it supports local transactions.

Other properties

Along with properties mentioned above, WebSphere SAP Adapter provides additional properties described below that can be useful for SAP transactional scenarios. These WebSphere SAP Adapter properties are available on both IBM Integration Bus and IBM Business Process Manager.

Wait on Commit property

WebSphere SAP Adapter supports a transaction property on BAPI and BAPI WorkUnit interfaces during outbound processing called Wait on Commit. It is a Boolean option that lets you specify whether the WebSphere SAP Adapter should wait for the processing to be completed and then call Commit, or call Commit immediately.

For outbound processing, this property specifies whether the Commit call from the Adapter should wait until all the time-critical updates to the SAP database have been completed. When this property is set to True, the Commit to call to SAP waits until all updates are completed and returned. If it is set to False, the Commit call returns immediately from the SAP database. This property is active only when you use the file CWYAP_SAPAdapter_Tx.rar. Generally, the Commit call is made after executing a business specific BAPI call. In such cases, if the BAPI definition on SAP has a implicit Commit call, then it takes precedence over the Adapter Commit call settings.

Reset property

When the adapter creates a client connection, some values are retrieved from SAP and cached in the connection. When an SAP administrator changes the flows on the SAP side or makes other modifications that cause these values to change, these cached values are not updated on the connection

To address this issue, WebSphere SAP Adapter now provides "Reset JCo Client after closing Connection Handle," which invokes the Reset method on the JCo client to ensure that changes on the SAP EIS are reflected in the client during an outbound transaction. This property is not required, and by default it is set to False. When the property is set to True, the Adapter invokes the Reset method on the JCo client to ensure that changes on the SAP EIS are reflected on the client during an outbound transaction. For more information, see the IBM Support Technote SAP response not constant when using WebSphere Adapter for SAP.

  • To use both of the above properties on IBM Integration Bus, ensure that the Transaction Mode property on the WebSphere SAPAdapter node is set to Yes.
  • To use both of the above properties on IBM Business Process Manager, ensure that you are using the file CWYAP_SAPAdapter_Tx.rar.

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=958306
ArticleTitle=Transactional behavior of WebSphere SAP Adapter
publish-date=12272013