受信側は、トランスポート固有です。WBI-C には、FTP ディレクトリー、JMS、File ディレクトリー、SMTP (POP3)、および HTTP/S トランスポート用の受信側が付属しています。
WBI-C システムに新規トランスポートを追加するために、ユーザーは 4.2.2 リリースで提供される API を使用して、独自の受信側を作成できます。これらの新規受信側は、Community Console を使用して構成でき、また通常の方法で処理フローに統合できます。このセクションでは、新規受信側の開発プロセスを説明します。次について説明します。
受信側の内部の処理フローの本質はある程度は特定のトランスポートのニーズによって指示されますが、すべての受信側が実現する必要のある基本的なタスクがあります。ここでは、これらのタスクの上位について、一般的な方法で説明します。
- 1. トランスポートに到達するメッセージの検出
- 受信側は次の 2 つの方法のうちのいずれかを使用して、要求メッセージの到着を検出します。つまり、そのトランスポートに定義されたターゲットのポーリング (提供された JMS 受信側が実行) かまたはトランスポートからのコールバックの受信 (提供された HTTP/S 受信側が実行) です。
- 2. トランスポートからのメッセージの検索
- 受信側はトランスポートから、要求メッセージとトランスポート属性 (ヘッダーなど) を検索します。これには、ファイル・システムに一時ファイルを作成する場合があります。
- 3. WBI-C 必須ヘッダーの生成
- 文書の以降の処理に使用される、特別な WBI-C ヘッダーがあります。受信側には、トランスポート・メッセージ属性から、または他の方法で、該当するこれらのヘッダーのいずれかを作成するメカニズムが必要です。ヘッダーのリストは以下のとおりです。
- InboundCharSet: インバウンド文書の文字セット
- MsgLengthIncHeaders: メッセージの長さ (トランスポート・ヘッダーを含む)
- requestURI: HTTP の場合、受信したサーブレットの URI
- timestamp: 受信した文書のタイム・スタンプ
- fromIP: 文書が送信される宛先の IP アドレス
- certDN: SSL クライアント証明書の DN 名
さらに処理するために Document Manager に転送される受信側要求文書は、トランスポート・メッセージ、トランスポート・ヘッダー、およびこれらの WBI-C ヘッダーから構成されます。
注: 以下のステップ (4 および 5) は、いずれの順序でも実行できます。
- 4. 前処理の実行
- 受信側は WBI-C コンポーネント、受信側フレームワークを呼び出して、実際に前処理を行います。フレームワークは、コンソールを介してターゲットに指定されている Connect 提供またはユーザー定義のハンドラーを、コンソール構成画面に表示されている順に実行します。要求文書が入力として最初のハンドラーに渡され、戻された処理済みの文書が入力として次のハンドラーに渡される、という流れです。このステップでは、1 つ以上の文書を戻すことがあり、すべての受信側は、複数の戻り文書を処理するように設計する必要があります。
- 5. 同期状況の検査
- 受信側は受信側フレームワークを呼び出して、受信した要求が同期しているかどうかを判別します。フレームワークは、該当するハンドラーを見付けるまでハンドラーの構成済みリストを移動します。このステップの結果で、受信側の次ステップを判別します。要求が非同期の場合は、パス A に進みます。要求が同期の場合は、パス B に進みます。
- 6A. 非同期要求処理
- 要求が非同期の場合 (発生元の取引先に応答文書を戻す必要がない)、受信側はフレームワークを呼び出して要求文書を処理します。フレームワークは、Document Manager が検索する場所に情報を保管します。
- 6B. 同期要求処理
- 要求が同期の場合 (発生元の取引先に応答文書を戻す必要がある)、受信側はフレームワークを呼び出して要求文書を処理します。同期要求には、ブロッキングと非ブロッキングの 2 つのタイプがあります。ブロッキング・モードでは、フレームワークが Document Manager からの応答文書を受信側に戻すまで、受信側の呼び出しスレッドはブロックされます。非ブロッキング・モードでは、受信側の呼び出しスレッドがすぐに戻されます。後で応答文書を受け取ったとき、フレームワークは呼び出し側で processResponse メソッドを呼び出し、再び応答文書を渡します。この応答に発生元の要求を同期させるため、相関オブジェクトが使用されます。
- 7. 後処理の実行
- 同期要求の場合、受信側はフレームワークを呼び出して、応答文書が発生元の取引先に戻される前に、その応答文書に対して後処理を実行します。フレームワークは、コンソールを介してターゲットに指定されている Connect 提供またはユーザー定義のハンドラーを、コンソール構成画面に表示されている順に実行します。応答文書が入力として最初のハンドラーに渡され、戻された処理済みの文書が入力として次のハンドラーに渡される、という流れです。
- 8. 処理の完了
- 同期要求の場合、応答文書がトランスポートを介して発生元の取引先に戻されます。受信側はフレームワークで setResponseStatus メソッドを呼び出し、応答のデリバリーが成功したか失敗したかを報告します。その後、受信側は要求メッセージをトランスポートから除去します。
エラー条件が、次の場合に発生することがあります。
- トランスポートからのメッセージの検索に失敗
- 前処理の呼び出しに失敗
- 同期検査に失敗
- 非同期または同期処理実行の呼び出しに失敗
- 応答文書の後処理の呼び出しに失敗
- トランスポートに応答文書を戻そうとして失敗
これらのいずれかの障害が発生すると、受信側は次のアクションを実行します。
- トランスポートからのメッセージを拒否
- メッセージをトランスポートから除去する必要があります。例えば、JMS 受信側の場合、メッセージはキューから除去されます。HTTP 受信側の場合は、状況コード 500 が取引先に戻されます。
- 拒否されたメッセージのアーカイブ
- これはオプションのステップです。メッセージは、後で再発信されるキューか、またはローカル・ファイル・システムの拒否済みフォルダーにアーカイブされます。後者の場合、フレームワークは拒否された要求文書について該当するストレージ・ファイルを生成できることがあります。
- イベントの生成
- これはオプションのステップです。受信側開発者は、受信側にイベントを作成させるか、またはエラー条件の場合にアラートを発生させるか (またはその両方) を選択できます。イベントには 3 つのレベル (通知、警告、およびエラー) があります。通知イベントが実行フローに提供するのは、その詳細だけです。警告イベントは、実行フローを停止させるほどではない問題を記録します。エラー・イベントは、文書の処理がエラーで終わり、それ以上の文書の処理が停止したときに記録されます。例えば、同期要求で、フレームワークから受信した応答文書を受信側が発生元の取引先に戻すことができない場合、エラー・イベントが記録されます。受信側ステージで問題を記録するために使用できるイベントのリストは、後述の API の章にあります。
トランスポートでの着信メッセージの検出方法により、一般的な 2 つの受信側タイプがあります。
1 つの受信側タイプはポーリング・ベースで、トランスポートを定期的にポーリングして、新規のメッセージが到着したかどうかを判別します。この受信側タイプの Connect 提供のサンプルには、JMS と FTP があります。もう 1 つの受信側タイプはコールバック・ベースで、メッセージが到着すると、トランスポートから通知を受信します。HTTP 受信側は、コールバック・ベース受信側の例です。
注: 受信側はマルチボックス・モードで配置できます。この場合、複数の受信側とその構成済みターゲットは、同じトランスポート・ロケーションからメッセージを取り出します。このような配置モデルでは、並行管理アクセス調整機能が受信側に組み込まれている必要があります。
受信側の開発は、次の 2 つの主要部分をベースとします。つまり、API に
ReceiverInterface インターフェースで表される受信側自体と、API に
ReceiverFrameworkInterface インターフェースで表される受信側フレームワークです。フレームワークは、受信側と WBI-C コード本体との間のインターフェースを提供します。受信側はフレームワーク上のメソッドを呼び出して、さまざまな処理ステップを実現します。
API に指定されるその他のコンポーネントには次のものがあります。
Community Console に作成されたさまざまな構成属性を照会および設定する方法の ReceiverConfig、受信側がトランスポート・メッセージから作成する受信側要求文書である ReceiverDocumentInterface、非ブロッキング同期シナリオで同期を維持するために用意されたメカニズムである ResponseCorrelation、汎用例外クラスの BCGReceiverException、および Framework オブジェクトの取得、要求文書の作成、適切なファイル保管情報の検出のための静的メソッドを提供するユーティリティー・クラスである
BCGReceiverUtil などがあります。これらはすべて、受信側 API の章で詳しく説明されています。
