使用项目读取器和写入器编写多个平面文件Spring Batch

Question

So I want to create 6 delimited reports , they all use the same data source and same table , the query is different for each , they all are also independent.

The way I have it setup right now I have 6 pojos , 6 row mappers , 6 item readers and 6 item writers and it works, is there a way simplify this without making it over complicated it,specially since the 6 item readers are the same except for the query.

Answer 1

We have spring boot application which has configuration file like this:

@Configuration
@EnableBatchProcessing(modular = true)
public class JobContextConfig {

    @Bean
    public ApplicationContextFactory job1Factory() {
        return new GenericApplicationContextFactory(Job1Config.class);
    }

    @Bean
    public ApplicationContextFactory job2Factory() {
        return new GenericApplicationContextFactory(Job2Config.class);
    }

    @Bean
    public ApplicationContextFactory job3Factory() {
        return new GenericApplicationContextFactory(Job3Config.class);
    }       
}

And application.properties with spring.batch.job.enabled: false so we control launch of jobs.

So we have separate context for each job, we start our jobs with launchers which react on amqp messages. Each job has configuration class which is isolated but we define reusable components in @JobScope and avoid duplication.

ie we have file import job and as last step it needs to delete file which is processed from directory. That is tasklet in @JobScope which means it is recreated for each job and it does cleanup, it is @Autowired in every job that needs it.

The other idea which we used on import job but with dynamic mapping of columns in csv is that we used Factory which is @JobScope and based on some criteria, lets say job parameter it is creating RowFieldSetMapper to use for that instance of job. But we had same job and same everything except of input csv file structure so that was ok for us.

If you have similar but not completely different reader , processor , writer I would agree that duplication is ok because it would be easier to read, figure out and maintain separate jobs. Use common sense to judge what would be better, readability and maintainability or having complicated mechanism but with less code duplication.