ロジック・シーケンス図

次のシーケンス図は、ファイル・パーサー機能の理解に役立ちます。SGG D1 jarに記述されているFileParserおよびFileParser2 Javaインタフェースをファイル・パーサーとして認められるようにカスタム・クラスで実装する必要があります。詳細は、「FileParserインタフェース」および「FileParser2インタフェース」を参照してください。

FAは入力ディレクトリでファイルを検索するときに、FPとの対話を開始するGFPをインスタンス化してコールします。対話は、次の3つのフェーズに分類できます。

インスタンス化および初期化
- setProcessor()
- setInputStream()
- setStartPosition()
トランザクション
- getPosition()
- getNextStream()
例外処理
- getCurrentInputPortion()

インスタンス化および初期化フェーズ

GFPはインスタンス化され、ファイルが入力ディレクトリに入力されると入力ストリームを受信します。その時点でFPのインスタンスがインスタンス化されます。前述した特定のメソッドは、初期化するFPで呼び出されます。

トランザクション・フェーズ

FPが初期化されると、GFPはFPインスタンスを使用してプレーンXML構造を生成します。これは、FP上でのgetNextStream()メソッドの呼出しにより行われます。

呼出しのたびに、FPは1つのプレーンXMLを返します。FP呼出しは、FPからNULLが返されるまで続行されます。NULLはファイルの終わりおよび特定のファイルで解析が完了したことを示します。GFPは、FPからNULLを受信すると、特定の入力ファイルに対するgetNextStream()の呼出しを停止します。

FPは、ファイル入力ストリームを使用してファイルを部分的に読み取ります。バイト単位または行単位で読み取ることができますが、各getNextStream()メソッド・コールの終わりに、1つのプレーンXML構造を作成するのに十分なデータのみを読み取ります。たとえば、入力ファイルに1つのプレーンXMLのみに十分なデータがある場合は、getNextStream()の最初のコールでプレーンXMLが返され、次のコールではNULLが返されます。ただし、複数存在する場合は、getNextStream()コールはファイルの終わりに到達するまですべての着信部分に対してプレーンXML構造を返し続けます。

例外処理フェーズ

FP内の例外処理は、2つのフェーズ(反応およびリカバリ)に分類できます。

反応フェーズ

このフェーズでは、例外の捕捉およびGFPへの報告が行われます。これは、GFP (this.fileProcessor)に対するsaveInvalidRow()メソッドの呼出しにより実現されます。

例外が発生すると、解析は実行されなくなり、getNextStream()からNULLが渡されます。

NULLを返せない場合、「ファイル・パーサーによってよい結果と悪い結果の両方が同時に返されました」などのエラーがWeblogicサーバー・ログに見つかる場合があります。

例外がGFPに報告された場合、次の3つの処理が行われます。

XMLペイロードD1-PayloadErrorNotifが作成され、OSBメッセージ・フローに渡されます。このメッセージは、BASE OSBプロジェクトのPPS内から通知キューに公開されます。
D1 jar内のユーティリティ・メソッドの呼出しにより、"transaction error occurred"変数が増分されます。ファイル解析中に発生したすべてのエラーが捕捉され、メッセージD1-PayloadSummaryを介して報告されます。これは、通知キューに公開されます。
最後に、エラー発生時に読み取られた未処理データの一部を含むデータ・ファイルがエラー・ディレクトリに作成されます。Rejected File Descriptor (RFD)ファイルも作成されます。未処理入力部分は、後述するgetCurrentInputPortion()メソッドを利用して使用できます。

前の図で示したように、saveInvalidRow()メソッドは3つの入力パラメータを使用します。

解析が開始された位置。RFDファイルに書き込まれます。これは、入力ファイル内のエラーの位置を特定するのに役立ちます。
エラー・データ・ファイルに書き込まれる未処理データ。着信ファイル書式と同じで、getNextStream()メソッドの現在の呼出しが開始されてから読み取られたデータが含まれている必要があります。問題が見つかったデータの修正が可能で、修正されたファイルは再処理のために着信フォルダに配置されます。
D1-PayloadErrorNotifメッセージに報告されたエラー・メッセージ。エラー・メッセージの内容は、ファイル・パーサー開発者が定義する必要があります。

リカバリ・フェーズ

このフェーズを前述した処理済例外からのリカバリと混同しないでください。これは、ファイル解析が停電またはネットワーク中断により完全に中断された場合のリカバリです。

リカバリの準備: GFPは、ファイルの現在の読取位置に内部索引を維持します。これは、GFPによってgetNextStream()メソッド・コールの前にFPに対してgetPosition()メソッドをコールすることで行われます。

リカバリ: 中断とその後のリストアでは、GFPはファイル・パーサーに対して現在の位置を設定します。たとえば、バイト415でエラーが発生した場合、開始位置は415に設定され、FPは0ではなくその位置から読取を開始します。値415は、リカバリ位置として参照できます。

ファイル・パーサーが解析を再度開始する場合、リカバリ位置から解析を開始するために次の2つの処理を実行する必要があります。

リカバリ位置をstartPositionフィールドに保存します。
リカバリ位置からポインタを開始するためのスキップ・ロジックを組み込みます。