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批處理時使用步驟決策者和塊

回答

相關問題