SAP BAPI transaction commit

When the SAP adapter is used with the BAPI interface, you must consider certain factors when you design transactional flows.

You can configure message flows to be transactional so that updates to resources such as databases can be coordinated; changes are committed or rolled back together within the same transaction. This transactional coordination can be extended to external system updates, such as SAP databases, when you use the BAPI interface with SAPRequest nodes.

Information about the state of in-flight transactions is held in IBM® MQ queues, which means that IBM App Connect Enterprise must have access to IBM MQ when it is processing these messages. To enable this, ensure that either an IBM MQ client or an IBM MQ server is installed on the same computer as the integration node. By default, the Transaction mode property of the SAPInput node is set to Yes, and the Transaction mode property of the SAPRequest node is set to Automatic, which means that it uses the value that is set on the input node that drives the message flow. If you do not require the nodes in the flow to be transactional, you can set the Transaction mode property to No, in which case access to IBM MQ is not required. For more information about using IBM MQ with IBM App Connect Enterprise, see Installing IBM MQ.

The SAP adapter can control whether it waits for SAP to commit the updates synchronously, or issues a commit and returns while the SAP commit happens asynchronously. You can determine this behavior by using the Use wait parameter before calling BAPI commit parameter on the Configure Objects pane of the Adapter Connection wizard. The adapter relies on the transactionality setting of the message flow to determine whether to issue the commit call.

BAPIs with implicit commit

In earlier releases of SAP, some BAPIs were coded with a commit. From SAP Release 4.0A onwards, it is more effective for BAPIs to issue a separate BAPI_TRANSACTION_COMMIT to force the update, instead of doing commit work. By using this method, BAPI calls can be made before the work is committed as a batched unit of work. To find out if a BAPI is coded with a commit, see the documentation for the BAPI.

Message flow transactionality

When the Transaction mode property on the SAPRequest node is set to Yes, the adapter is instructed to issue the SAP commit on completion of the message flow in line with other database commits. You can set the Use wait parameter before calling BAPI commit parameter in the Adapter Connection wizard that determines whether the commit is synchronous or asynchronous.

If the Transaction mode property on the SAPRequest node is set to No, the adapter does not issue an SAP commit and the parameter that you set on the Adapter Connection wizard has no relevance. However, the commit can still be issued as part of a BAPI work unit COMMIT verb (to which the property on the wizard does apply) or a call to the BAPI_TRANSACTION_COMMIT (to which the property on the wizard does not apply).

The following rules apply when you set the Transaction mode property on the SAPRequest node.
  • Set Transaction mode to No if the following conditions apply:
    • The BAPIs already have commits
    • A BAPI_TRANSACTION_COMMIT is called by an SAPRequest node
    • A BAPI work unit includes a BAPI_TRANSACTION_COMMIT or the COMMIT verb is added on the Configure Objects pane of the Adapter Connection wizard

    If the BAPIs are coded with commits and you set Transaction mode to Yes, the BAPI is called as part of the same transaction as those from other SAPRequest nodes in the same flow and using the same adapter. Therefore, any BAPIs that were called previously in this message flow are committed.

  • Set Transaction mode to Yes if the following conditions apply:
    • The BAPI needs to be committed (that is, the BAPI is not coded with a commit)
    • The BAPI work unit needs to be committed and does not include a BAPI_TRANSACTION_COMMIT or the COMMIT verb

    If you set Transaction mode to No, the BAPI is not committed now or at the end of the message flow; it is not guaranteed ever to be committed.

The following scenarios illustrate the visibility of the updates made to an SAP system, and show how to use the adapter to avoid uncertainty when data is being committed by an external system.