Synchronous and asynchronous RFC

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

For diagrams that illustrate synchronous and asynchronous Remote Function Calls (RFC), see BAPI inbound scenarios.

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 Adapter Connection wizard.

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.
    Note: 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 server, and the call is repeated at regular intervals until it can be processed by 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.

    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 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 a failure occurs 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; it does not send the event with the duplicate ID, thereby ensuring that the event is processed only once.