Spring批处理时使用步骤决策者和块

我开始使用Spring Batch，并且对使用步骤，决策者和区块时有疑问。Spring批处理时使用步骤决策者和块

鉴于以下输入：

<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>

对于每一个文件中的<UserAuthorization>的，我都会有不同的业务规则取决于<Action>对数据库执行查询前验证。（例如：对于ADD，验证用户名在数据库中是唯一的，并且它仅由字母组成，或者对于DELETE，验证该表是否存在于表中）

然后，<Action>值将确定是否我需要在数据库中插入，更新或删除一个值。（Action可能有其他值，如UPDATE_RIGHTS或RESET_PASSWORD）

最好做什么？

做我定义了一个工作等：

<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>

的itemReader将读取XML文件，并在同一时间返回<UserAuthorization>之一。
的ItemProcessor中将以饱满的if s到核实其取决于价值<Action>
的当前项目的业务规则itemWriter将在数据库中持久的项目。如果我想在执行查询之前执行更多的事情，是否也需要在这里添加逻辑？

通过这样做，我担心我没有正确使用Spring批处理。

这是正确的做法吗？

我可以使用几个步骤和决策者来实现批处理的所有逻辑吗？你有一些例子吗？

来源

2014-05-07 fluminis

使用SB来解决这类问题是正确的决定，您不需要多于一个步骤（对于这种用例）。

解决方案一：
Reader是微不足道的（使用StaxEventItemReader）和处理器是无用的（除非您需要执行一些业务检查）。
更有趣的一点是作家，因为你必须：

定义每个操作，其中，执行实际写逻辑
创建一个主作家定制写入（AddItemWriter, UpdateItemWriter, DeleteItemWriter例如）（由具有专门的写作者），根据<ACTION>标记值向右侧写入者发送写入数据。

解决方法二（也许有点更 “复杂”）：

标准StaxEventItemReader
定制ItemProcessor从<UserAuthorization>转换到自定义Action类封装操作（AddUserAuth, DeleteUserAuth, UpdateUserAuth例如）
为每个操作定义一个自定义写入器（例如，AddItemWriter, UpdateItemWriter, DeleteItemWriter），执行真正的写入逻辑
作为主要作者使用基于SubclassClassifier的ClassifierCompositeItemWriter;使用类定制Action的这个分类派遣到右笔者从处理器创建

该解决方案更（容易）扩展比的解决方案之一，因为你只需要创建自定义Action类 - 和正确的作家 - 为（新）行动和写作只是一个配置问题。

来源

2014-05-07 10:12:01

Spring Batch看起来像这里的矫枉过正。但如果使用了，我会期待以下分工：

itemReader从输入源读取项目，并返回要处理的下一个项目。这个类必须是线程安全的。
itemProcessor不做任何事情，只是返回输入项目。如果有关于操作的商业规则，它们就属于这里。这个类不需要是线程安全的，因为它是在它自己的线程中调用的。这个类不应该写入数据库。
itemWriter执行插入/更新/删除，并在chunksize操作后提交。

此外，我怀疑ADD操作不会有userId。插入记录时，通常由数据库分配。

来源

2014-05-07 09:20:12 kiwiron

对于添加操作的id完全正确，我编辑问题。我在这里试图简化输入文件和业务逻辑：将会有一个或多个具有1000或更多UserAuthorization的输入文件（比这更复杂） – fluminis

Spring批处理时使用步骤决策者和块

回答

相关问题