This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

What are best practices to generate a bad items file?Page Title Module

What are best practices to generate a bad items file?

Jun 25th, 2009, 01:51 AM

Hello,

What are best practices to generate a bad items file? I have several Jobs, that read a file (FlatFileItemReader) then these items may be processed and finally written in other file, on a data base, etc.

Then problem is I need to generate a .bad file with all the records with problems. That problems can be originated on the read, process o write part. And this file must contain the original flat record

I successful extract the original flat record when the problem is originated in the reader, using a skipListener and the FlatFileParseException. But when the problem isn't in the reader, but in the process or in the writer i don't know how to get the original flat record. I'm only have the object.

What is the best approach to resolve this problem? maybe implementing a custom FlatFileItemReader and put the original line in the StepContext? Or there is other trick?

Comment

I usually do something similar. I use my FieldSetMapper to generate two types of objects "records" and "errors". I let Spring Batch treat both types as "items", passing them to the processor and writer. Then i have a custom-coded composite writer that supports writing to two files. I use the composite writer to check whether the item is a "record" or an "error" and write it to the appropriate place.