IBM FileNet P8, バージョン 5.2.1            

Web Services-ReliableMessaging

Web サービスのほとんどの用途には標準メッセージング・モードが目的に適合しますが、アプリケーションの中には、Web サービスに対する要求が意図したターゲットに到達したこと、または Web サービスからの応答が元の要求元アプリケーションに到達したことを確認するメカニズムを必要とするものもあります。

PO 標準メッセージング

上の図は、ほとんどの Web サービス要求のための標準メッセージング・モードを示しています。片方向の要求の場合、クライアントは単一のメッセージを宛先 Web サービスに送信します。応答が予期される要求の場合、Web サービスを実行するメッセージが 1 つと、Web サービスからクライアントへの応答メッセージがあります。P8 バージョン 3.x を使用して作成された FileNet® プロセスは、この標準メッセージング・モードを使用します。

WS-ReliableMessaging 仕様は、いくつかの基準 (最低 1 回、最高 1 回、1 回のみ、または順序どおり) に従って宛先での受信を保証するプロトコルを提供します。信頼性の確保のために、宛先がメッセージの受信を肯定応答するかタイムアウトになるまで要求メッセージは繰り返し送信されます。

Web Services-ReliableMessaging

上の図では、Invoke システム関数が WS-ReliableMessaging 用に指定された要求を送信します。信頼メッセージング・ソースと信頼メッセージング宛先は、クライアントと宛先間のメッセージを管理し、意図した受信者が適切な肯定応答メッセージ付きで返信してくるまで各メッセージを送信します。片方向の要求の成功には、最小でも 5 個のメッセージが交換され、応答が期待される要求の場合は 10 個のメッセージが交換されます。

WS-ReliableMessaging の使用に関する注意

  • FileNet P8 4.0 プロセスで定義された Web サービス (Receive システム関数) では、標準メッセージングと信頼メッセージングの両方がサポートされます。

    以前の (3.x) FileNet プロセスで定義された Web サービスでは、標準メッセージング・モードのみがサポートされます。

  • FileNet 4.0 プロセスで定義されたクライアント (Invoke システム関数) は、標準メッセージングまたは信頼メッセージングのいずれかを使用して FileNet 4.0 プロセスを実行できます。プロセスは、単一の Application Engine を持つ FileNet P8 環境でも、複数の Application Engine を持つファーム型の環境でも存在できます。

    外部 Web サービスへの要求の場合、ワークフロー作成者は Web サービスが WS-ReliableMessaging をサポートしているかどうかを認識していなければなりません。

  • 単一の Application Engine を持つ P8 環境では、独立系ソフトウェア・ベンダーのアプリケーションにより、標準メッセージングか信頼メッセージングのいずれかを使用して FileNet Web サービスを実行できます。複数の Application Engine を持つファーム型の環境では、他のアプリケーションからの要求には標準メッセージングのみがサポートされます。
  • WS-ReliableMessaging を使用するためのインターフェースは、Invoke システム関数で使用できます。Receive および Reply システム関数には、特にユーザー構成はありません。WS-ReliableMessaging により、1 つの要求につき最低 5 つのメッセージがやり取りされ、再送信が必要な場合には、さらにメッセージが追加されます。したがって IBM® では、このタイプの処理を保証する要求の場合のみ WS-ReliableMessaging を使用することを推奨します。
  • 信頼メッセージングを使用する場合、ワークフロー作成者は、要求に関する問題をキャッチできるように Invoke システム関数に障害処理を指定しておく必要があります。

信頼メッセージングの目的は、一方の側にハードウェアおよびソフトウェア障害が発生した場合でも、クライアントと Web サービス間でメッセージを送信可能にすることです。現在の実装では、メモリー・キューを使用して信頼メッセージングを保管しています。そのため、サーバー障害の場合は情報が失われます。

信頼メッセージング要求における問題の管理

Web サービス要求が成功した場合、エンド・ユーザーは標準メッセージングで送信された要求と信頼メッセージングで送信された要求との違いに気付きません。

WS-ReliableMessaging を使用すると、ほとんどの問題は最終的にタイムアウトになります。IBM は、障害メッセージをキャッチできるように、Invoke システム関数で障害処理機能を使用して文字列データ・フィールドを指定することをお勧めします。アプリケーション以外の障害が発生した場合は、障害の原因に関係なく、信頼メッセージング状況情報が障害メッセージに追加され、ワーク・アイテムは適切な処理のために事前定義サブマップに移動されます。

信頼メッセージングの 非アクティブ・タイムアウトに関する特定の障害は orgorg.apache.axis.AxisFault であり、 「非アクティブ・タイムアウトに達しました。サーバーからの応答がありません」というメッセージが表示されます。

状態リストと障害メッセージの説明については、「WS-ReliableMessaging の状態」を参照してください。

メッセージと要求のタイムアウト

標準メッセージングの場合は、各要求について送信されるメッセージは 1 個のみです。標準メッセージングの非アクティブ・タイムアウトは 5 分間に設定されます。

信頼メッセージング要求については、予期される肯定応答メッセージが届くか非アクティブ・タイムアウトになるまで各メッセージは繰り返し送信されます。各メッセージは非アクティブ・タイムアウトの対象です。

Web サービス・メッセージ・シーケンス中に発生する非アクティブ・タイムアウトには、次の 2 つのタイプがあります。

  • メッセージに対する非アクティブ・タイムアウト - これは、送信されるメッセージと戻される肯定応答メッセージに対して許容される時間です。デフォルトは 5 分間です。
  • 要求に対する非アクティブ・タイムアウト - これは、メッセージ・シーケンス全体の完了に対して許容される時間です。各信頼要求に必要なすべてのメッセージに対する非アクティブ・タイムアウトに対応できるように、要求に対する非アクティブ・タイムアウトの設定は、メッセージに対する非アクティブ・タイムアウトの 5 倍 (デフォルトは 25 分間) です。

要求のタイムアウトが 25 分間に設定されていても、その時間が経過すると要求がタイムアウトするという意味ではありません。いずれかのメッセージがメッセージの非アクティブ・タイムアウトに達すると、要求はタイムアウトします。例えば、送信された最初のメッセージ Create Sequence Request メッセージがメッセージの非アクティブ・タイムアウトに達すると、障害が生成され、要求もタイムアウトします。あるいは、要求は正常に Web サービスに届き、同期応答を待機しているとします。応答が届かない場合、要求のタイムアウトに達すると要求はタイムアウトします。

ユーザーは、「送信の保証」のために、メッセージの非アクティブ・タイムアウトを大幅に長い期間に設定できます。 各送信メッセージは、待機対象の該当メッセージが到着するか非アクティブ・タイムアウト時間が切れるまで複数回送信されるため、非アクティブ・メッセージ・タイムアウトを長めに設定すると、宛先 Web サービスが障害から回復し、メッセージを受信して応答を戻す可能性が高くなります。

メッセージの非アクティブ・タイムアウトは、コンポーネント・マネージャーの下にある Process Task Manager の「信頼メッセージング設定」タブの「Web Services」で構成できます。WS-ReliableMessaging の非アクティブ・タイムアウトの値は、標準メッセージング・タイムアウトの値には影響を与えません。

再送信

送信メッセージが繰り返し送信されるときは、指定した再送信間隔で再送信されます。ベース再送信間隔は 3 秒間 (デフォルト) に設定され、メッセージが再送信されるたびに間隔は長くなります。すなわち、同じ発信メッセージが送信される頻度は徐々に減っていきます。

再送信間隔は、コンポーネント・マネージャーの下にある Process Task Manager の「信頼メッセージング設定」タブの「Web Services」で構成できます。

Invoke に対するユーザー定義タイムアウト

メッセージと要求タイムアウト制限のほかに、ワークフロー作成者は Invoke ステップにタイムアウト (ワークフロー・システム・タイムアウト) を指定できます。このタイムアウト値は、要求の非アクティブ・タイムアウトより長くても短くてもかまいません。要求タイムアウトになる前にワークフロー・システム・タイムアウトに達すると、ワーク・アイテムはユーザーが指定したタイムアウト・マップに移動します。ワークフロー・システム・タイムアウトに達する前に要求タイムアウトになると、障害が生成されます。Invoke が障害をキャッチする設計の場合、障害メッセージはユーザーが指定したストリング・データ・フィールドに保管され、ワーク・アイテムは障害用に指定されたマップに移動します。



最終更新日: 2016 年 3 月
bpfdh010.htm

© Copyright IBM Corp. 2016.