Spring batch when use steps deciders and chunks

Question

I am starting to use Spring Batch and I have a question about when using steps, deciders and chunks.

Given the following input:

<UserAuthorizationEvent>
    <UserAuthorization>
        <Action>ADD</Action>
        <UserName>Name1</UserName>
        <!-- more properties here -->
    </UserAuthorization>
    <UserAuthorization>
        <Action>UPDATE</Action>
        <UserId>456</UserId>
        <UserName>NewName2</UserName>
        <!-- more properties here -->
    </UserAuthorization>
    <UserAuthorization>
        <UserId>789</UserId>
        <Action>DELETE</Action>
    </UserAuthorization>
    <!-- 1000 or more UserAuthorization here -->
</UserAuthorizationEvent>

For each of the <UserAuthorization> in the file, I will have different business rules to verify before executing a query on the database depending of the <Action>. (Example: for an ADD, verify that the UserName is unique in the database and that it is composed of only letters, or for a DELETE, verify that the id exists in the table)

Then the <Action> value will determine if I need to INSERT, UPDATE or DELETE a value in the database. (Action could have other values such as UPDATE_RIGHTS or RESET_PASSWORD)

What is the best to do ?

Do I define a job like that:

<job id="myJob" xmlns="http://www.springframework.org/schema/batch">
    <step id="step1">
        <tasklet>
            <chunk reader="itemReader" processor="itemProcessor" writer="itemWriter" commit-interval="2" />
        </tasklet>
    </step>
</job>

• The itemReader will read the xml file and return a <UserAuthorization> one at a time.
• The itemProcessor will be full of ifs to verify the business rules on the current item depending of its <Action> value
• The itemWriter will persist the item in the database. Do I need to add logics here too if I want to execute some more things before executing the queries?

By doing so, I fear that I am not using Spring batch correctly.

Is that the right thing to do?

Can I use several steps and deciders for implementing all the logic of the batch ? Do you have some examples ?

Answer 1

Use SB for this kind of problem is the right decision and you don't need more than a single step (for this use-case).

First solution:
Reader is trivial (use a StaxEventItemReader) and processor is useless (except you need to perform some business check).
The more interesting point is the writer because you have to:

1. Define a custom writer for each operation (AddItemWriter, UpdateItemWriter, DeleteItemWriter for example) where you perform the real write logic
2. Create a main writer (composed with specialized writer) where you dispatch writes to right writer based on <ACTION> tag value.

Second solution (maybe a bit more "complex"):

1. Standard StaxEventItemReader
2. Custom ItemProcessor convert from <UserAuthorization> to custom Action class encapsulate operation (AddUserAuth, DeleteUserAuth, UpdateUserAuth for example)
3. Define a custom writer for each operation (AddItemWriter, UpdateItemWriter, DeleteItemWriter for example) where you perform the real write logic
4. As main writer use a ClassifierCompositeItemWriter based on SubclassClassifier; this classifier dispatch to right writer using the class of custom Action created from processor

This solution is more (easily) extensible than solution one because you just need to create custom Action class - and the right writer - for a (new) action and writing is just a configuration matter.

Answer 2

Spring Batch looks like overkill here. But if used, I would expect the following division of labour:

• itemReader reads items from the input source, and returns the next item to process. This class must be thread safe.
• itemProcessor does nothing but return the input item. If there are business rules about the operation, they belong here. This class need not be thread safe, as it is invoked in its own thread. This class should not write to the database.
• itemWriter does the insert/update/delete and commits after chunksize operations.

Also, I suspect that ADD operations would not have a userId. This is usually allocated by the database when the record is inserted.