Item Processors - Spring Batch - page 245

</beans:bean>
<beans:bean id="customerProcessor"
class="org.springframework.batch.item.adapter.ItemProcessorAdapter">
<beans:property name="targetObject" ref=”customerService”/>
<beans:property name="targetMethod" value=”getAccountExecutiveForCustomer”/>
</beans:bean>
<step id="copyFileStep">
<tasklet>
<chunk reader="customerFileReader" processor="accountExecutiveItemProcessor"
writer="outputWriter"
commit-interval="10"/>
</tasklet>
</step>
<job id="copyJob">
<step id="step1" parent="copyFileStep"/>
</job>
…
With the job configured to use your new ItemProcessor, the ItemProcessorAdapter, and your job
will call the CustomerServiceImpl with each Customer item you input and pass the returned
AccountExecutive object to the ItemWriter. As mentioned, the framework allows for an ItemProcessor to
accept one type as input and another as output.
The idea of applying a single action to an item within a transaction can be limiting in certain
situations. For example, if you have a set of calculations that need to be done on some of the items, you
may want to filter out the ones that don't need to be processed. In the next section, you will look at how
to configure Spring Batch to execute a list of ItemProcessors on each item within a step.
CompositeItemProcessor
You break up a step into three phases (reading, processing, and writing) to divide responsibilities
between components. However, the business logic that needs to be applied to a given item may not
make sense to couple into a single ItemProcessor. Spring Batch allows you to maintain that same
division of responsibilities within your business logic by chaining ItemProcessors within a step. In this
section, you will look at how to chain ItemProcessors within a single step using Spring Batch's
CompositeItemProcessor.
The org.springframework.batch.item.support.CompositeItemProcessor is an implementation of the
ItemProcessor interface that delegates processing to each of a list of ItemProcessor implementations in
order. As each processor returns its result, that result is passed onto the next processor until they all
have been called. This pattern occurs regardless of the types returned so if the first ItemProcessor takes
a String as input it can return a Product object as output as long as the next ItemProcessor takes a
Product as input. At the end, the result is passed to the ItemWriter configured for the step. It is
important to note that just like any other ItemProcessor, if any of the processors this one delegates to
returns null, the item will not be process further. Figure 8-2 shows how the processing within the
CompositeItemProcessor occurs.