IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Services and service-related functions > Access external services with adapters > Configure and using adapters > IBM WebSphere Adapters > SAP Software > SAP interfaces > BAPI interfaces > Inbound processing

Synchronous and asynchronous RFC

For BAPI inbound processing, you can specify that the processing be handled synchronously (in which both the client application and the adapter must be available during processing) or asynchronously (in which the adapter does not have to be available when the client application invokes the function call). In synchronous processing, the client application waits for a response from the adapter. In asynchronous processing, the client application does not wait for a response.

The BAPI interface has two sets of activation specification properties (one for synchronous RFC and one for asynchronous RFC), which you use to set up inbound processing. You specify values for the properties with the external service wizard or through the administrative console.

The sequence of processing actions that result from an inbound request differ, depending on the selection you make during configuration from the SAP Remote Function Call (RFC) type list.


Synchronous RFC

If you select Synchronous RFC (the default) during configuration, the following processing steps occur:

  1. The adapter starts event listeners, which listen for an RFC-enabled function event (which you specified with the RFCProgramID property) on the SAP server.

  2. The RFC-enabled function event is pushed to the adapter by way of the event listeners.

  3. The adapter resolves the operation and business object name using the received RFC-enabled function name.

  4. The adapter sends the business object to an endpoint in a synchronous manner.

  5. The adapter receives the response business object from the endpoint.

  6. The adapter maps the response business object to an RFC-enabled function and returns it to the SAP server.

The adapter does not listen for events until the endpoint is active and available.


Asynchronous transactional RFC

If you select Asynchronous Transactional/Queued RFC during configuration, the following processing steps occur:

  1. A client on the SAP server invokes an RFC-enabled function call on the adapter.

    To send the RFC-enabled functions from a queue on the SAP server, the client program on the SAP server delivers the events to a user-defined outbound queue.

    A transaction ID is associated with the call.

    The calling program on the SAP server does not wait to see whether the call to the adapter was successful, and no data is returned to the calling program.

  2. The RFC-function call is placed on a list of functions to be delivered.

    You can see the event list by entering transaction code SM58 on the SAP server.

  3. The RFC-function call is invoked on the adapter. If the adapter is not available, the call remains in the list on the SAP system, and if the scheduler in SAP is configured, then the call is repeated at regular intervals until it can be processed by the adapter.

    If the scheduler is not configured, you need to process it manually.

    Figure 1. An RFC-enabled function call is invoked on the adapter.

    When the SAP server successfully delivers the call event, it removes the function from the list.

  4. If you selected Ensure once-only event delivery, the adapter sets the transaction ID in the event persistent table.

    This is to ensure the event is not processed more than once.

  5. The adapter resolves the operation and business object name using the received RFC-enabled function name.

  6. The adapter sends the business object to an endpoint.

    Figure 2. The adapter stores the TID, converts the function to a business object, and delivers the business object to the endpoint.

    If you are sending functions from a user-defined queue on the SAP server, the functions are delivered in the order in which they exist on the queue. You can see the contents of the queue by entering the transaction code SMQ1 on the SAP server.

  7. If the delivery is successful, and if you selected Ensure once-only event delivery, the adapter removes the transaction ID from the event persistent table.

    If there is a failure when the adapter attempts to deliver the business object, the transaction ID remains in the event table. When another event is received from the SAP server, the following processing occurs:

    1. The adapter checks the transaction ID.

    2. If the event matches an ID in the table, the adapter processes the failed event once.

      In other words, it does not send the event with the duplicate ID, ensuring that the event is processed only once.

Inbound processing for the BAPI interface