After a chat that got deeper into this issue, the real "issue" is that the ItemReader is being created once instead of once per REST call (aka once per execution of the job). To fix this, make the ItemReader step scoped. This will allow you to get a new instance of the reader with each run which also enables the ability to inject the file name base on job parameters.

From a code perspective, change this:

@Bean
public ItemReader<Person> reader() {

to this:

@Bean
@StepScope
public FlatFileItemReader<Person> reader() {

The reason for the return type change is that Spring Batch will automatically register ItemStreams for you. However when using @StepScope we only see the return you define. In this case, ItemReader doesn't extend/implement ItemStream so we don't know you're returning something we should be auto-registering. By returning FlatFileItemReader we can see all the interfaces/etc and can apply the "magic" for you.

I did read about AsyncItemProcessor and AsyncItemWriter, but I am not sure if that is something I should use in this scenario.

Yes, AsyncItemProcessor and AsyncItemWriter are suitable for your use case. The AsyncItemProcessor will execute the logic (your rest call) of the delegate ItemProcessor for an item on a new thread. Once the item completes, the Future of the result is passed to the AsynchItemWriter to be written. The AsynchItemWriter will then unwrap the Future and write the item. The advantage of these components is that you don't have to deal with Futures wrapping, unwrapping, etc yourself.

You can find:

• More details here: https://docs.spring.io/spring-batch/4.0.x/reference/html/spring-batch-integration.html#asynchronous-processors
• An example here: https://github.com/mminella/scaling-demos/blob/master/single-jvm-demos/src/main/java/io/spring/batch/scalingdemos/asyncprocessor/AsyncProcessorJobApplication.java

Hope this helps.