Java Reference
In-Depth Information
this.customerDao = customerDao;
}
}
As you can see in Listing 8-17, the CustomItemProcessor implements the ItemProcessor interface,
both accepting and returning a Customer object as the item. When the processor receives the item, it
looks up the customer by name and ZIP code and updates the item you received with the ID in the
database. The Customer is then returned to be processed by the next ItemProcessor, which in this case is
the AccountExecutiveItemProcessor shown in Listing 8-18.
Listing 8-18. AccountExecutiveItemProcessor
package com.apress.springbatch.chapter8;
import org.springframework.batch.item.ItemProcessor;
public class AccountExecutiveItemProcessor implements ItemProcessor<Customer, Customer> {
private AccountExecutiveDao accountExecutiveDao;
public Customer process(Customer customer) {
customer.setAccountExecutive(
accountExecutiveDao.getAccountExecutiveByCustomer(customer));
return customer;
}
public void setAccountExecutiveDao(AccountExecutiveDao accountExecutiveDao) {
this.accountExecutiveDao = accountExecutiveDao;
}
}
Same process, different domain. In the AccountExecutiveItemProcessor, you again take a Customer
object as input. However, this time you look up which AccountExecutive it's associated with and update
the item with the correct association. You then return the same Customer object to be written to your
output file.
The last piece of this puzzle from a code perspective is the two DAOs you used in the
ItemProcessors: the CustomerDao and the AccountExecutiveDao. In each case, you extend Spring's
JdbcTemplate to make accessing the database easier. All you need to do is define your query, inject the
parameters, and build a RowMapper implementation. Listing 8-19 has the CustomerDao's
implementation.
Listing 8-19. CustomerDao
package com.apress.springbatch.chapter8;
import java.sql.ResultSet;
import java.sql.SQLException;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.RowMapper;
Search WWH ::




Custom Search