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:
- The adapter starts event listeners, which listen for an RFC-enabled
function event (which you specified with the RFCProgramID property)
on the SAP server.
- The RFC-enabled function event is pushed to the adapter by way
of the event listeners.
- The adapter resolves the operation and business object name using
the received RFC-enabled function name.
- The adapter sends the business object to an endpoint in a synchronous
manner.
- The adapter receives the response business object from the endpoint.
- 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:- 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.
- 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
- 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.
- 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.
- The adapter resolves the operation and business object name using
the received RFC-enabled function name.
- 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.
- 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:
- The adapter checks the transaction ID.
- 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.