Sterling B2B Integrator - Managing EBICS Transactions

Transaction Manager in the EBICS Server is responsible for maintaining the transaction states. It determines the segment that is required to generate the XML response message.

Transaction Manager handles the upload and download transaction flows and supports segmentation and recovery of order data.

Upload From a Subscriber (FUL)

The FUL order type is used to upload data to a bank.

The upload transaction comprises the following phases:

  • Initialization
  • Data Transfer

The user sends the upload (FUL) request to the bank. FUL is a bank-technical upload order type.

Important: For large FUL payloads, the Maximum Idle Time (MaxIdleTime) setting in the EBICS Server Service should be increased. If the MaxIdleTime setting is too low, the transaction could be cancelled before it completes. An appropriate setting for large FUL payloads is 300 minutes.
 

The EBICS Order Authorization service handles incoming order requests for the bank-technical upload order type. If an order has obtained the number of signatures required, this service forwards the order to the subscriber upload mailbox. Otherwise, this service retains the order data in the database until all the required number of signatures is obtained.

The handleEBICSRequest business process receives a user’s request. If the user’s request contains the last segment of the order data, it invokes the EBICSOrderAuthorizationProcessing business process asynchronously to unpack the order data and generate the following files:

Note: Unpacking order data includes decoding, decrypting, and decompressing the order data.
 
  • .DAT – Contains the unpacked order data in a user’s upload mailbox
  • .SIG – Contains the signature of the order data in a user’s upload mailbox
  • .PRM – Contains the order parameters in the user’s upload mailbox
  • .PSR – Contains a status report of asynchronous processing in the user’s download mailbox
Processing Initialization

A user initiates a transaction by submitting the requests containing information about the incoming order. Based on this information, the EBICS Server verifies the order type, performs the message replay test, verifies message authentication, and checks user authorization before accepting the request.

After successful verification of the order data, the bank generates a transaction ID and includes the ID in its response to the user.

Processing Data Transfer

When more than one segment is required to transfer order data, the bank performs message authentication, verifies the transaction, verifies the segment number and size. After the EBICS Server receives the last segment of the order data, the complete order data is forwarded to the EBICSOrderAuthorizationProcessing business process asynchronously and the transaction ends.

The EBICSOrderAuthorizationProcessing business process unpacks the order data and forwards it to the user upload mailbox. The EBICSOrderAuthorizationProcessing business process generates post processing report (PSR) and routes it to the user’s download mailbox. This business process also generates the .SIG and .PRM files to be forwarded to the user’s upload mailbox. An .err file is generated when EBICSOrderAuthorizationProcessing business process encounters an error, for example, an invalid electronic signature. Use the .err file to inspect an invalid order data file, if necessary.

Download From EBICS Server (FDL)

The FDL order type is used to download data from a bank.

The download transaction comprises the following phases:

  • Initialization
  • Data Transfer
  • Acknowledgement

A user submits the FDL order type to the bank. The user requests the download of the .PSR report to get the status of the FUL request. The user can also request to download valid file formats other than .PSR by using the FDL order type.

Important: For large FDL payloads, the Maximum Idle Time (MaxIdleTime) setting in the EBICS Server Service should be increased. If this setting is too low, the transaction could be cancelled before it completes. An appropriate setting for large FDL payloads is 300 minutes.
 
Processing Initialization

The bank verifies the message from the user. After the bank verifies the user’s request, the bank collects the order data from the user’s download mailbox based on the file format information in the request.

If more than one message matches the file format, the bank joins the contents of each message into a single order data and invokes the order data processor synchronously to pack the order data.

If the encoded form of the order data exceeds 1 MB, the order data is separated into segments. The first segment of the order data and the transaction ID is included in the response to the user.

Processing Data Transfer

The user sends the request for the next data segment. The bank authenticates the message, verifies the transaction, and the segment number and size.

In each transfer phase, the bank transfers all the segments until the last segment of the order data is included in its response to the user.

Processing Data Acknowledgement

After receiving the last segment of the order data from the bank, the user initiates the last phase, the acknowledgement request, to indicate that the data transfer has been successful.

If the bank receives a positive acknowledgement (receipt code=0) from the user, the bank moves the downloaded messages from the user download mailbox to the user archive mailbox. If the bank receives a negative acknowledgement from the user, the bank retains the downloaded messages in the user’s download mailbox.

If a user wants to download valid file formats other than the .PSR reports from the user’s archive mailbox, the user must specify a date range in the EBICS request. The user must ensure that the date range matches the drop date of the .DAT file when moved from the user’s download mailbox to the user’s archive mailbox.