邏輯順序圖表

建立與初始化階段

系統會建立一般檔案處理器，並在檔案進入輸入目錄時收到輸入資料流。此時會建立檔案剖析器的實例。系統會在檔案剖析器上叫用特定方法 (如上所述) 來進行初始化。

交易階段

當檔案剖析器初始化之後，一般檔案處理器會使用該檔案剖析器實例來產生純 XML 結構。這會在檔案剖析器上叫用 getNextStream() 方法。

每次叫用時，檔案剖析器只會傳回一個純 XML。檔案剖析器的叫用作業會持續進行，直到檔案剖析器傳回 NULL 為止。NULL 代表檔案的結尾，也代表特定檔案的剖析作業已完成。當一般檔案處理器收到來自檔案剖析器的 NULL 時，就會停止叫用特定輸入檔的 getNextStream()。

檔案剖析器會使用檔案輸入資料流來分批讀取檔案。它可以逐位元組或逐行來讀取，但在每個 getNextStream() 方法呼叫的結尾，它讀取的資料量只夠建立一個純 XML 結構。例如，假設某個輸入檔的資料只夠建立一個純 XML，則第一次呼叫 getNextStream() 會傳回一個純 XML，下一次呼叫則傳回 NULL。但如果資料足夠建立數個純 XML，getNextStream () 呼叫會繼續傳回每個傳入部分的純 XML 結構，直到讀取到檔案的結尾為止。

例外處理階段

檔案剖析器內部的例外處理可分為兩個階段：反應與復原：

反應階段

此階段包含快取例外，並向一般檔案處理器報告。透過在一般檔案處理器 (this.fileProcessor) 上叫用 saveInvalidRow() 方法來達成此目的。

請注意，在發生例外時，檔案剖析器會停止剖析，然後 getNextStream() 會傳回 NULL。

如果無法傳回 NULL，則會在 Weblogic 伺服器日誌中看到錯誤，例如「檔案剖析器同時傳回正常和錯誤的結果」。

一般檔案處理器在收到例外報告時，會執行三項動作：

1. 建立 XML 承載 D1-PayloadErrorNotif，並將它傳遞至 OSB 訊息流程。訊息會從 BASE OSB 專案的 PPS 內部發布至「通知佇列」。

2. 藉由叫用 D1 jar 中的公用程式方法，來遞增「已發生的交易錯誤」變數。在檔案剖析生命週期期間發生的所有錯誤都會被擷取，並透過訊息 D1-PayloadSummary 來報告，再次將訊息發布到「通知佇列」。

3. 最後，會在錯誤目錄中建立資料檔，其中包含在發生錯誤時讀取的原始資料部分。它也會建立「被拒絕的檔案描述區」(RFD) 檔案。使用下方討論的 getCurrentInputPortion() 方法來取得原始輸入部分。

如上圖所示，saveInvalidRow() 方法有三個輸入參數：

1. 開始剖析的位置。它會將此資訊寫入 RFD 檔案。這有助於識別輸入檔中的錯誤位置。

2. 將被寫入錯誤資料檔的原始資料。它應該與傳入檔案的格式相同，且應包含從目前叫用 getNextStream() 方法開始所讀取的資料。您可以更正其中有問題的資料，並將「修正過的」檔案置於傳入資料夾中，以供進一步重新處理。

3. 透過 D1-PayloadErrorNotif 訊息來報告的錯誤訊息。請注意，錯誤訊息的內容必須由檔案剖析器開發人員定義。

復原階段

此階段不得與從上述已處理的例外中復原的情況混淆。這裡是指當檔案剖析因電力故障或網路中斷而完全中斷時的復原作業。

復原準備：一般檔案處理器會維護一份包含檔案之目前讀取位置的內部索引。一般檔案處理器會在每次以 getNextStream() 方法呼叫之前先叫用檔案剖析器上的 getPosition() 方法來達成此目的。

復原：如果發生中斷和後續還原的情況，一般檔案處理器會在檔案剖析器上設定開始位置。例如，如果故障發生在位元組 415，則開始位置會設為 415，讓檔案剖析器從該點開始讀取，而不是從 0 開始讀取。值 415 可稱為復原點。

當檔案剖析器再次開始剖析時，必須執行兩件事以確保檔案從復原點開始剖析：

1. 將復原點儲存至 startPosition 欄位。

2. 合併略過邏輯以從復原點啟動指標。