Recover upload and download transactions

When sending or receiving transaction data, if the client is down, there is a risk of losing the transaction data. To prevent loss of and to restore transaction data, EBICS Client supports transaction recovery for upload and download transactions.

Transaction recovery for upload transactions

The following example scenario illustrates transaction recovery mechanism for an upload transaction using the FUL order type:
  1. Twenty segments of transaction data are uploaded to the server.
  2. After ten segments are successfully uploaded, the client instance goes down.
  3. Once the client instance is restored, the client re-sends the transaction data from the point it was down. In this example, the client re-sends the eleventh segment of the transaction data.

If the segment received from the client after recovery is not synchronized with the existing segment at the server, the server returns the EBICS_TX_RECOVERY_SYNC event name. The event name EBICS_TX_RECOVERY_SYNC indicates that the server is synchronizing the segments in the transaction with the client. In the Timestamp column of the Event Viewer, you can view the difference in the timestamps of the segments that are uploaded before and after the transactions are recovered.

Persisting segment count

You can update the Persistence segment count system property value from the Administration menu of EBICS Client to persist the transaction data points in the client database. For example, if you set the Persistence segment count to five, after ten segments are uploaded to the server, two transaction data points (fifth and tenth) are persisted in the client database.

If the client instance goes down after the twelfth segment is uploaded to the server, the client re-sends the tenth segment of the transaction data. If the server has already received twelve segments of the transaction data, the server notifies the client to re-send from the thirteenth segment.

Transaction recovery for download transactions

The following example scenario illustrates transaction recovery for a download transaction using the FDL order type:
  1. Ten segments of transaction data are downloaded from the server.
  2. The client instance goes down after the sixth segment is downloaded and persisted in the database.
  3. Once the client instance is restored, the client sends a request to the server for the seventh segment.
The following example scenario illustrates transaction recovery for a download transaction using the FDL order type, when the client instance goes down during downloading of a segment:
  1. Ten segments of transaction data are downloaded from the server.
  2. The client instance goes down when the sixth segment is in the process of downloading from the server.
  3. Once the client instance is restored, the client re-sends a request to the server for the sixth segment.