Java Reference
In-Depth Information
public UserRegistration process(UserRegistration input) throws Exception {
String zipCode = stripNonNumbers(input.getZip());
String telephone = stripNonNumbers(input.getPhoneNumber());
String state = StringUtils.defaultString(input.getState());
if (isTelephoneValid(telephone) && isZipCodeValid(zipCode)
&& isValidState(state)) {
input.setPhoneNumber(telephone );
return input;
return null;
The class is a parameterized type. The type information is the type of the input, as well as the type of
the output. The input is what's given to the method for processing, and the output is the returned data
from the method. Because you're not transforming anything, in this example the two parameterized
types are the same.
Once this process has completed, there's a lot of useful information to be had in the Spring Batch
metadata tables. Issue the following query on your database:
Among other things, you'll get back the exit status of the job, how many commits occurred, how
many items were read, and how many items were filtered. So if the preceding job was run on a batch
with a 100 rows, each item was read and passed through the processor, and it found 10 items invalid (it
returned null 10 times), the value for the filter_count column would be 10. You could see that a 100
items were read from the read_count . The write_count column would reflect that 10 items didn't make it,
and would show 90 .
Chaining Processors Together
Sometimes you might want to add extra processing that isn't congruous with the goals of the processor
you've already set up. Spring Batch provides a convenience class, CompositeItemProcessor , which
forwards the output of the filter to the input of the successive filter. In this way, you can write many,
singly focused ItemProcessor s and then reuse them and chain them as necessary.
<bean id="compositeBankCustomerProcessor"
<property name="itemProcessors">
<bean ref = "creditScoreValidationProcessor" />
<bean ref="salaryValidationProcessor" />
<bean ref="customerEligibilityProcessor" />
The example created a very simple workflow. The first ItemProcessor will take an input of
whatever's coming from the ItemReader configured for this job, presumably a Customer object. It will
check the credit score of the Customer and, if approved, forward the Customer to the salary and income
validation processor. If everything checks out there, the Customer will be forwarded to the eligibility
processor, where the system is checked for duplicates or any other invalid data. It will finally be
Search WWH ::

Custom Search