Multiple Record Formats
Up to this point you have been looking at a customer file that contains a collection of customer records.
Each record in the file has the exact same format. However, what if you received a file that had customer
information as well as transaction information? Yes, you could implement a single custom
LineTokenizer. However there are two issues with this approach.
1. Complexity : If you have a file that has three, four, five, or more line formats—
each with a large number of fields—this single class can get out of hand
2. Separation of concerns : The LineTokenizer is intended to parse a record. That's
it. It should not need to determine what the record type is prior to the parsing.
With this in mind, Spring Batch provides another LineMapper implementation: the
org.springframework.batch.item.file.mapping.PatternMatchingCompositeLineMapper . The previous
examples used the DefaultLineMapper, which provided the ability to use a single LineTokenizer and a
single FileSetMapper. With the PatternMatchingCompositeLineMapper, you will be able to define a Map
of LineTokenizers and a corresponding Map of FieldSetMappers. The key for each map will be a pattern
that the LineMapper will use to identify which LineTokenizer to use to parse each record.
Let's start this example by looking at the updated input file. In this case, you still have the same
customer records. However, interspersed between each customer record is a random number of
transaction records. To help identify each record, you have added a prefix to each record. Listing 7-19
shows the updated input file.
Listing 7-19. The Updated customerInputFile
CUST,Warren,Q,Darrow,8272 4th Street,New York,IL,76091
CUST,Ann,V,Gates,9247 Infinite Loop Drive,Hollywood,NE,37612
CUST,Erica,I,Jobs,8875 Farnam Street,Aurora,IL,36314
In the file shown in Listing 7-19, you have two comma-delimited formats. The first consists of the
standard customer format you have been working to up to now with the concatenated address number
and street. These records are indicated with the prefix CUST. The other records are transaction records;
each of these records, prefixed with the TRANS, prefix, are also comma-delimited, with the following
1. Account number : The customer's account number.
2. Date : The date the transaction occurred. The transactions may or may not be
in date order.
3. Amount : The amount in dollars for the transaction. Negative values symbolize
debits and positive amounts symbolize credits.
Listing 7-20 shows the code for the Transaction domain object.