Delete Batch (ICL) Processing and Error Reporting

When an application receives an BatchDelete event, it should:

  • Perform any work necessary to delete the selected batch (ICL)
  • Log any messages or result text to the deposit group message table
  • Return an pass or fail indication to Transaction Server

The BatchDelete event payload contains the identifier for the batch (ICL) that is being deleted and BatchDeletePayload containing the details for the delete. The applications use the payload to examine the inbound batch (ICL) being deleted, perform any necessary clean up, and generate messages that are included in the final delete report. All messages, results and informational text are added to the deposit group message table in the database. The application itself must put any information it requires in the deposit group message table. Table 1 shows the format of each row of the deposit group message table.

Applications can use the BatchDeletePayload from the Messaging API message to create the messages in the database. Several of the methods return information that is unique to the batch (ICL) and helpful to display in the messages. The BatchDeletePayload also has methods to make adding messages to the database easier. If they are used, make sure to supply a valid database connection before calling them. For example, addMessage requires a database connection before it is called.

Table 1 shows the methods that are available in BatchDeletePayload.

Table 1. BatchDeletePayload Methods
Getter Method Data Type Description
getBatchId ( ) PresentmentId Returns the identifier of the batch (ICL) being deleted
getBatchGroupId ( ) PresentmentGroupId Returns the batch (ICL) group identifier for the batch (ICL) being deleted
getTargetName ( ) String Returns the destinationId value from the scheduler XML for this event
getPayload ( ) String Returns the value that was specified in the ABSvcPayload parameter in the scheduler XML for this event
setConnection ( ) java.sql.Connection Supplies the BatchDeletePayload with a database connection it can use when accessing the database. This method must be called with a working database connection before calling the addMessage method.
addMessage ( ) String, String, String Adds a new message to the deposit group message table. It has the following parameters:
  • Product name
  • Message identifier
  • Message text
This method uses the batch (ICL) group ID, the batch (ICL) delete process name, and the next available message index fields to create the rest the deposit group message table entry.

Additionally, consider the following when logging messages:

  • Build the message text using National Language Support (NLS) text from a resource bundle
  • If the message text was built using NLS, use the optional message id parameter, which can be saved along with the message instance, to specify the NLS message ID
commit ( ) N/A Commits the current database work
rollback ( ) N/A Rolls back the current database work
close ( ) N/A Closes any resources consumed by this BatchDeletePayload instance. This method has the added effect of removing the reference to any supplied database connection.

Once the target application is finished analyzing the inbound batch (ICL) being deleted, it must indicate if it detected an delete error. Table 2 shows the return values for deleting an inbound batch (ICL).

Table 2. Delete Batch (ICL) Return Values
Return Value Description
false The application completed the delete operation successfully
true The application detected an unload error

The application notifies the caller whether the delete succeeded or failed as follows:

  1. Returns a Messaging API response with the return value in the payload
  2. Uses the return value as a return code

The Messaging API response is the preferred method for reporting the delete status. If a boolean value is not returned in the Messaging API payload, the Transaction Server detects this, adds a message stating that a return value was not received from the application, and proceeds as if no unload error was detected by the application.

Note: This is true only if there is no error code returned in the response. Reply time-outs are treated as delete failures.

Returning a return code is usually only used when the Messaging API message has a failure, such as a timeout waiting for a reply. If this method is used, the application can either include a return error message describing the failure or log it itself using the BatchDeletePayload. The Transaction Server automatically adds any error messages returned to the deposit group message table.