Scenario 1: Business partner and relationship processing in a single flow

You must set the Transaction mode property appropriately on an SAPRequest node when you are processing in a single message flow.

This scenario is one of two examples that illustrate the concepts that are described in SAP BAPI transaction commit; see also Scenario 2: Order create and query application processing with two flows.

In this scenario, a message flow is used to create a business partner, and a new relationship with an existing partner by using two BAPI calls:
BAPI_BUPA_CREATE_FROM_DATA
BAPI_BUPR_RELATIONSHIP_CREATE
The message flow consists of two SAPRequest nodes with the Transaction mode property set to Yes on both nodes to allow commit or rollback in case of exceptions. When the Transaction mode property is set to Yes, the message flow's final commit takes place at the end of the flow when the adapter requests SAP to commit the order.
Diagram showing how the SAPRequest nodes in a message flow interact with the SAP server. The diagram is described in the following steps.
  1. An application triggers the transactional flow that creates the business partner.
  2. The SAPRequest node submits a BUPA creation and returns the business partner number. The commit happens when the message flow completes because the node participates in a message flow level transaction.
  3. The second SAPRequest node attempts to create a relationship between an existing business partner and the new business partner; however, SAP has not yet committed the creation of the new business partner to the database.

    If the same adapter is used for both BAPIs, the adapter ensures a single connection to SAP because both nodes have to participate in the same logical work unit. The single connection means that the BUPA creation is visible to the relationship update call (3 in the diagram), even though the flow transactionality has yet to initiate the commit.

    If the Transaction mode property were set to Yes on the create BUPA call, but No on the create relationship call, the adapter would need to use two different connections to SAP; that is, the transactional properties of the connections would be different. The create relationship call would therefore fail because the new business partner would not be visible until the message flow and the transactional commit have completed.

  4. The MQOutput node puts an MQ message on the output queue pending transactional commit.
  5. The message flow completes and the integration node begins to commit all the resources involved in that flow, including SAP (5 in the diagram). The updates are committed in SAP.

This scenario illustrates the ability of the integration node to use its transactional control of the message flow to provide the necessary information to the SAPRequest nodes to carry out related processing, even though the external SAP system is committing the work asynchronously.