This blog deals with the kind of validations that we had to perform on the incoming file and how we created Generic Java program that is used across all the interfaces to avoid duplication of efforts. This approch has been divided into two blogs. The 1st one describes the structure of Message type used after content conversion & describes the patterns of the incoming file.
Listed below are some of the factors against which I had to validate the incoming files:
–> Hierarchical validation
–> Field level validation
–> Does mandatory child of a parent exists
–> Are header and trailer records present?
–> Is any unknown Transaction Type present?
–> Check whether desired number of fields occur for a transaction type
–> Are all mandatory fields present?
–> Check if the same person is sending a duplicate file
–> Are date/time fields coming in the correct format?
–> Do text fields (mandatory/optional) come within double codes?
–> By mistake are numeric/decimal fields coming within double codes?
–> Check if field exceeds the maximum allowed length?
Before converting the flat file to a hierarchical structure we need to perform these validations to check the accuracy of data. All the errors in the file are captured in ERR_REASON node. If the incoming file has an error the STATUS node is set to 1 else it is set to 0.
The output of the File adapter content conversion is being stored in the Data type shown below. The input and output of the Java-mapping program would be the same structure with ERR_REASON, FILE_TYPE and STATUS segments populated after the java mapping is executed.
For using this Validation program, we need to specify the structure of the incoming file. The incoming file can have structures S78, which in turn can have Childs S68 and S72. The S68 node can in turn have S72 as its child. We need to specify this information in the interface specific class of the Generic Validation program. The representation of the above scenario can be well understood by the diagram shown below:
There might be another scenario where the structure of incoming file might be as shown below. Here the parent has only one child and that child is a mandatory child of that parent.
Every incoming file would contain a header and trailer record. The HEADER record would contain the FILE TYPE in it. After validating the FILE TYPE in the header segment, it is passed on to the FILE_TYPE element in the Message Type. This is required for treating different File Types as per their individual processing logic after validating the file. The TRAILER record contains RECORD_COUNT field that gives the total number of records in the file excluding header and trailer records.