Appendix 9 - Batch tables

The process provides varied information to refer to in case of the need to check the results of an execution, for debugging or decision purposes. The first tool at disposal is to refer to the data automatically provided from Spring Batch, through its internal repository tables, where a series of information regarding the executions are stored.

An execution can be identified through the table batch_job_execution, which defines an instance of execution of the whole batch, the job_execution_id will be important to search the related steps, and the properties status and exit_code defines if the job successfully completed. In this particular case the codes will generally be on COMPLETED after a job execution is ended, unless an error outside the scope of the single steps outcomes occurs.

To check for the information involving the reading of a file, the table batch_step_execution contains the information regarding the single steps of the processes identified by a job_execution_id, the steps useful for debugging the file processing steps are the ones containing in the step_name column, the values "hpan-recovery" or "transaction-filter". The steps with the name containing "master-step" as a suffix define the general status of all the related files processed during the execution, while the ones with the "worker-step" suffix are related to a single file.

The status and exit_code are useful to determine the general outcome for a step, the first one simply refers to the general outcome, generally either referring to a COMPLETED or FAILED status, while the second property might indicate a more detailed code, as an example, if during the processing of a file the fault tolerance is configured, and some records are skipped, the exit status with reflect this condition with the COMPLETED_WITH_SKIPS exit code.

The table contains a series of columns containing useful information on the processed records: the read_count value details the number of successfully read lines, while the read_skip_count define the records that are skipped under the selected fault-tolerance policy. similarly, the write_count, write_skip_count and process_skip_count all retain a similar purpose in the filtering process and writing phases for the record. All the records that are in an error state, are included in the value for the rollback_count.

For the transaction filtering, the filter_count record is useful to keep track of how many transactions have been filtered, due to not matching the stored HPAN records. Filtered records are by default not included in the rollback count, as it's part of the business logic.

With the step_execution_id value, we can match the information for the related step in the batch_step_execution_context table, that contains the execution parameters in the short_context column. The workers steps context contains the processed file inside the JSON structure, under the "filename" property.

Further information about the Spring Batch repository entities, can be found in the Reference Manual