To protect your data when using the New Era of Networks Adapter for SAP R/3 with Business APIs (BAPIs), it is important to understand the operations that occur during an adapter transaction.

An adapter transaction consists of eight operations:

1. The adapter gets the message from the input queue.

2. The adapter processes the inbound message.

3. The adapter delivers the message to SAP.

4. SAP processes the message.

5. SAP delivers the response message to the adapter.

6. The adapter processes the response message.

7. The adapter puts the response message on the output queue.

8. The adapter commits the get from the input queue and the put to the output queue.

Failure can occur during any of the eight operations, but is handled differently in each operation, as described below.

1. Failure while the adapter gets the message from the input queue

This can happen if the adapter loses its connection to the queue. In this case the adapter shuts down, and the message remains on the queue. The message is reprocessed when the adapter is restarted and is able to reestablish its connection to the queue.

2. Failure while the adapter processes the inbound message

This usually happens if the message is poorly formed or the message is of an unknown type. If the message is of an unknown type, the adapter will not know how to parse it. In this case, after the message is successfully written to the fail queue, it is removed from the input queue (that is, the get from the input queue is committed). The adapter user is responsible for monitoring and processing messages written to the fail queue.

3. Failure while the adapter delivers the message to SAP

This can happen if the adapter loses its connection to SAP while it is delivering a message. In this case the adapter shuts down, and the message remains on the queue. The message is reprocessed when the adapter is restarted and is able to reestablish its connection to the queue.

Failure can also occur if the message being delivered is not recognized by SAP - for example, if the BAPI referenced in the message is not recognized by SAP. In this case the message is written to the fail queue, and the input message is removed from the input queue (that is, the get from the input queue is committed).

4. Failure while SAP processes the message

This can happen if the SAP server fails while a BAPI is being processed. If this happens, the adapter shuts down. The message remains on the queue, and it is reprocessed when the adapter is restarted and is able to reestablish its connection to the queue and to SAP.

Reprocessing the message will not pose a data integrity risk if SAP had not committed the data to the SAP database before failure. However, if SAP fails after committing the message to the database, there is a data integrity risk when the message is reprocessed. You will need to build logic in SAP to ignore the message when it is re-delivered.

5. Failure while SAP delivers the response message to the adapter

This can happen if the connection between SAP and the adapter is lost while SAP is sending the response message to the adapter. In this case, the adapter shuts down. The message remains on the input queue, and will be reprocessed when the adapter is restarted and is able to reestablish its connection to the queue. You will need to build logic in SAP to ignore the message when it is re-delivered.

6. Failure while the adapter processes the response message

This can occur if the BAPI returns data that the adapter is unable to deserialize into the expected content model. In this event, the incoming message is written to the fail queue. When this is successful, the message is removed from the input queue (that is, the get from the input queue is committed).

7. Failure while the adapter puts the response message on the output queue

This can occur if the adapter loses its connection to the output queue during transmission. In this case, the adapter shuts down. The message remains on the input queue. You will need to build logic into SAP to ignore the message at re-delivery when the adapter restarts and reestablishes its connection to the queues and to SAP.

8. Failure while the adapter commits messages to the queues

When the response message has been placed the output queue, the commit get and commit put are submitted to the input and output queues. In the unlikely event of a failure between the commit of the get and the put, the input message is removed, but the response message is not written to the output queue. You will need to add auditing logic to correlate the messages dispatched by SAP with the messages received by the target system.

Failure during multiple message transactions

The scenarios defined above describe single message transactions. Additional precautions must be taken for multiple message transactions. BAPI function calls do not necessarily commit data to the database. Several BAPI messages may be delivered to SAP before data is committed. The indicator to commit data may come either through delivery of a "BAPI commit work" message to the adapter, or a message delivered to the adapter with the BAPI commit flag set to true. If the BAPI commit flag is set to true, the adapter calls the BAPI commit work function after it delivers the message to SAP. Since the Adapter has no control over the contents or processing of the data in SAP, and since the adapter is not able to keep track of messages which were delivered to SAP before the commit work was issued, the adapter cannot institute any recovery processes on its own. You must implement these recovery processes in SAP according to business logic.