As you can see from Listing 7-24, configuring each of the two LineAggregators to which the
CustomerLineAggregator delegates are based upon the same configuration that you used previously.
The only difference is you have a delegation step in front of them.
When you execute the job, you're able to read in the two different record formats, parse them into
their respective domain objects, and print them out into two, different record formats. A sample of the
results of this job is shown in Listing 7-25.
Listing 7-25. Results of Running the copyJob Job with Multiple Record Formats
Warren Q. Darrow, 8272 4th Street, New York IL 76091
1165965 had a transaction of 51.43 on 01/22/2011
Ann V. Gates, 9247 Infinite Loop Drive, Hollywood NE 37612
Erica I. Jobs, 8875 Farnam Street, Aurora IL 36314
8116369 had a transaction of -14.83 on 01/21/2011
8116369 had a transaction of -45.45 on 01/21/2011
8116369 had a transaction of -74.60 on 01/21/2011
8116369 had a transaction of 48.55 on 01/22/2011
8116369 had a transaction of 98.53 on 01/21/2011
The ability to process multiple records from a single file is a common requirement in batch
processing. However, this example assumes that there was no real relationship between the different
records. What if there is? The next section will look at how to read multiline records into a single item.
In the last example, you looked at the processing of two different record formats into two different,
unrelated items. However, if you take a closer look at the file format you were using, you can see that the
records you were reading were actually related (as shown in the output of the job). While not related by a
field in the file, the transaction records are the transaction records for the customer record above it.
Instead of processing each record independently, doesn't it make more sense to have a Customer object
that has a collection of Transaction objects on it?
To make this work, you will need to perform a small bit of trickery. The examples provided with
Spring Batch use a footer record to identify the true end of a record. Although convenient, many files
seen in batch do not have that trailer record. With your file format, you run into the issue of not knowing
when a record is complete without reading the next row. To get around this, you can implement your
own ItemReader that adds a bit of logic around the customerFileReader you configured in the previous
section. Figure 7-3 shows the flow of logic you will use within your custom ItemReader.