WebSphere Enterprise Service Bus for z/OS バージョン 6.2.0 オペレーティング・システム: z/OS


ユース・ケース: 失敗イベントからのデータのリカバリー

ユース・ケースは、リカバリー・シナリオでのコンテキストとして使用されます。 このユース・ケースでのビジネスには、新規アカウントを作成する要求を受け取るアプリケーションがあります。

このソリューションは、モジュールのベスト・プラクティスによって推奨されている複数のモジュールで構成されています。

最初のモジュールは、要求を仲介し、処理をアカウント作成プロセスに委任します。以下の例では、別々のモジュールとしてソリューションを実装しています。要求は、SCA インポート/エクスポートを介してメディエーション・モジュール (AccountRouting) と処理モジュール (AccountCreation) の間で渡されます。2 つのモジュールの説明については、以下の画面取りを参照してください。

図 1. アカウント・ルーティング・プロセスのアセンブリー・ダイアグラム
要求は、メディエーション・モジュール (AccountRouting) と処理モジュール (AccountCreation) の間で、SCA インポートから SCA エクスポートに渡されます。

図 1 に示されるアセンブリー・ダイアグラムから始めて、障害が発生した可能性があるフロー内の場所を表示することができます。アセンブリー・ダイアグラム内の呼び出しポイントすべては、トランザクションを伝搬したり関係させたりすることができます。フロー内には、アプリケーションまたはシステムの障害の結果としてデータが集まる領域がいくつかあります。

一般に、トランザクション境界は、コンポーネントおよびインポート/エクスポート・バインディングとそれらの関連付けられた修飾子との間の対話 (同期および非同期) によって作成および管理されます。ビジネス・データは、トランザクション障害、デッドロック、またはロールバックのために、ほとんどの場合に特定のリカバリー・ロケーションに累積します。

WebSphere® Application Server 内のトランザクション機能により、WebSphere ESB は、サービス・プロバイダーによるトランザクションを参加させることができます。このような参加による対話は、インポートおよびエクスポートのバインディングについて理解する上で特に重要です。特定のビジネス・ケース内でのインポートとエクスポートの使用方法を理解することは、リカバリーする必要があるイベントが累積している場所を判別するために重要です。

エラー処理方針では、対話パターン、使用するトランザクション、インポートおよびエクスポートの使用をアプリケーションの開発前に定義する必要があります。ソリューションの設計者は、アプリケーションが作成されるときに使用される、使用する設定およびガイドラインを識別する必要があります。 例えば設計者は、同期呼び出しまたは非同期呼び出しをいつ使用するか、また BPEL 障害処理をいつ使用するかなどを理解する必要があります。 設計者は、すべてのサービスがトランザクションに参加できるかどうか、また参加できないサービスについては、問題が発生したときに補正をどう処理するかについて知っておく必要があります。

また、図 1 のアセンブリー・ダイアグラムに示されるアプリケーションでは、接続グループとモジュール開発のベスト・プラクティスを活用しています。このパターンを活用することにより、AccountRouting モジュールを停止して、新規イベントのインバウンド・フローを停止することができるようになっています。

以下のセクションでは、障害およびリカバリーにおけるビジネス・データのロケーションを説明します。

Business Flow Manager または Human Task Manager

このビジネス・ケースでは、AccountCreation プロセスで BPEL プロセスを活用します。

リカバリーに関しては、BPEL およびヒューマン・タスク管理について次のような質問について考えてみる必要があります。
  1. どのようなタイプのプロセスが実行中か (短期実行または長期実行、ビジネス・ステート・マシン、ヒューマン・タスク) ?

    短期実行プロセスはマイクロフローとして知られています。

  2. プロセスは正しく作成され、障害処理を使用してデータ保全性を向上させているか?
  3. トランザクション境界の予測と制御のために、呼び出しパターンと作業単位プロパティーはどのように構成されているか?

これらの質問に対する答えを知ることは、以下の画面取りで強調表示されているアセンブリー・ダイアグラムの呼び出し 7 および 8 のリカバリー方針に影響を与えます。

図 2. アカウント・ルーティングのアセンブリー・ダイアグラム - 呼び出し 7 および 8
呼び出し 7 および 8 を強調表示したアセンブリー・ダイアグラムを示す画面取り。

長期実行 BPEL プロセスやビジネス・ステート・マシンなどのステートフル・コンポーネントには、プロセス・アクティビティー変更と状態変更がデータベースに対してコミットされる、数多くのデータベース・トランザクションが関係しています。作業は、データベースを更新し、次に実行する内容を記述したメッセージを内部キューに格納することによって進行します。

Business Flow Manager 内部のメッセージの処理で問題が発生した場合、これらのメッセージは保存キュー に移動します。システムは、メッセージの処理を続行しようとします。後続メッセージが正常に処理されると、保存キューのメッセージが再実行依頼されて処理されます。同じメッセージが保存キューに 5 回格納された場合、そのメッセージは保留キューに移されます。

メッセージ数の表示とメッセージの再生についての追加情報は、『保存キュー/保留キューからのメッセージの再生 (Replaying Messages from the Retention Queue / Hold Queue)』で提供されています。

Failed Event Manager

Failed Event Manager (FEM) は、ほとんどの コンポーネント・タイプの間で非同期に実行された、イベントまたはサービス呼び出し要求の再生に使用されます。

失敗したイベントは、AccountRouting コンポーネントが SCA インポート・バインディング AccountCreationSCAImport を非同期で呼び出し、ServiceRuntimeException が戻された場合に作成されます。

重要な点として、BPEL がサービス対話においてクライアントになっている場合は、そのほとんどにおいて失敗したイベントが生成されません。つまり、(図 2 に示される) 7 および 8 の呼び出しでは、通常は失敗したイベントになりません。BPEL には、障害をモデル化するために、障害ハンドラーやその他の方法が用意されています。この理由から、「JDBCOutboundInterface」を呼び出す ServiceRuntimeException (SRE) 障害が発生した場合、SRE は処理のために BPEL に戻されます。プロジェクトのエラー処理方針では、BPEL において一貫した方法で実行時例外を処理する方法を定義してください。

ただし、インフラストラクチャー障害のためにプロセス・インスタンスにメッセージを配信できない場合には、BPEL クライアントへの非同期応答メッセージに対して、失敗したイベントが作成されることを念頭においてください。

以下の図は、Failed Event Manager コンポーネントの動作方法を示しています。図では、番号付けされた各ステップに関連する処理の説明を示しています。

図 3. Failed Event Manager の処理
Failed Event Manager の処理の図。図は番号付けされており、図に続いて番号付けされたステップがリストに記載されています。
Failed Event Manager の処理
  1. ソース・コンポーネントが非同期呼び出しパターンを使用して呼び出しを行う
  2. SCA MDB が SCA 宛先からメッセージを選出する
  3. SCA MDB が正しいターゲット・コンポーネントに対して呼び出しを行う
  4. ターゲット・コンポーネントが ServiceRuntimeException を throw する
  5. SCA MDB トランザクションが SCA 宛先にロールバックする
  6. 例外情報が、未確認 という状況を指定されて、Failed Event Manager データベースに保管される
  7. SIBus が呼び出しの再試行を n 回行う

    再試行制限のデフォルト値は 5 (最初の呼び出しの 1 回および再試行 4 回) です。このデフォルト値は、管理コンソールで変更できます。例えば、M という SCA モジュールの場合は、「バス」 > 「SCA.SYSTEM.<CELL>.BUS」 > 「宛先」 > 「sca/M」にナビゲートし、「最大デリバリー失敗数」フィールドで値を変更します。

  8. 再試行回数が指定された制限値に達すると、メッセージが FEM 宛先に移動される
  9. Failed Event Manager データベースがメッセージを選出する
  10. Failed Event Manager データベースが、データベース内の失敗したイベントを更新し、状況が失敗 に設定される

「失敗したイベント」はいつ作成されるか?

すでに述べたように、失敗したイベントは、同期呼び出しで作成されるのでも、標準的に両方向ビジネス・プロセス対話で作成されるのでもありません。

失敗したイベントは、通常、クライアントが非同期呼び出しパターンを使用し、サービス・プロバイダーが ServiceRuntimeException を throw したときに作成されます。

すべてが同じトランザクションで同期されて実行される場合、データはどこにも収集されません。その代わりに、データは呼び出しを行ったクライアントにすべてロールバックされます。コミットが発生すると、データは収集されます。呼び出しはすべて同期されて行われたが、複数のコミットが存在する場合、これらのコミットが問題になります。

一般的に、複数のトランザクションが必要な場合は、非同期処理呼び出しまたは長期実行 BPEL を使用する必要があります。毎回の ASYNC 呼び出しが、データ収集の機会となります。長期実行 BPEL 処理はコレクション・ポイントです。

表 1. 呼び出しパターンおよび失敗イベントの作成との関係: サービス・ビジネス例外
呼び出しパターン 失敗したイベントが作成されるかどうか (Y/N)?
同期 いいえ 失敗イベントは、サービス・ビジネス例外用に作成されず、同期パターンを使用するときも作成されません。
非同期 - 片方向 いいえ 定義により、片方向呼び出しでは障害を宣言できません。つまり、ServiceBusinessException を throw するのは不可能です。
非同期 - 据え置き応答 いいえ 失敗イベントは、サービス・ビジネス例外用に作成されません。
非同期 - コールバック いいえ 失敗イベントは、サービス・ビジネス例外用に作成されません。
表 2. 呼び出しパターンおよび失敗イベントの作成との関係: サービス・ランタイム例外
呼び出しパターン 失敗したイベントが作成されるかどうか (Y/N)?
同期 いいえ 失敗イベントは、サービス・ランタイム例外用に作成されず、同期パターンを使用するときも作成されません。
非同期 - 片方向 はい  
非同期 - 据え置き応答 はい  
非同期 - コールバック はい  
BPEL - 双方向 いいえ
失敗イベントは、ソース・コンポーネントがビジネス・プロセスのときは作成されません。
注: 非同期呼び出しについて、応答を BPEL に戻すことができない場合、失敗イベントが作成されます。
BPEL - 片方向 はい  
追加情報については、インフォメーション・センターの『失敗イベントの管理』というトピックを参照してください。

失敗したイベントの表示および再実行依頼に関する追加情報については、セクション『失敗したイベントの再サブミット』を参照してください。

サービス統合バスの宛先

処理待ちのメッセージは、少数のサービス統合バス (SIBus) 宛先に累積されます。これらの宛先の大部分は「システム」宛先です。これらの宛先内のメッセージは、通常、次の 3 つのタイプのメッセージで混成されています。
  • 処理の非同期要求
  • 要求に対する非同期応答
  • 非直列化または関数セレクター解決に失敗した非同期メッセージ
    注: 非同期応答は、有効なビジネス・オブジェクトであったり、要求の結果として返された障害であったりします。

SCA モジュール宛先

再び、ビジネス・ケースに戻ります。

ソリューションには、次の 2 つの「SCA モジュール」宛先があります。
  • sca/AccountRouting
  • sca/AccountCreation

これらの宛先は、モジュールがアプリケーション・サーバーまたはクラスターにデプロイされるときに作成されます。

これらの宛先にメッセージが累積されることはまれです。これらの場所にメッセージが累積されるということは、パフォーマンス上の問題やアプリケーションの問題が発生している可能性が非常に高いことを示します。すぐに調査してください。メッセージのバックアップによってシステムが停止したり、リサイクル時間が延長されたりすることになるので、(選択した IT モニター・ソリューションによって) モジュールの宛先の深さをモニターすることは重要です。

これらは、生成される名前が「sca/」付きのモジュール名と同じになるため、「SCA モジュール」宛先と呼びます。これらの宛先は、SCA 非同期呼び出し (要求と応答のブローカリング) の機能において中心的な役割を果たします。SCA.SYSTEM バスへのアプリケーションのインストール中に生成される追加の宛先の数はさまざまですが、ここでは説明の目的上、「SCA モジュール」宛先の重要性について扱います。

システム統合バス再試行

上述のとおり、FEM には SCA message driven bean (MDB) による再試行メカニズムが組み込まれています。この再試行動作は、モジュール宛先の「最大デリバリー失敗数」属性を変更することによって制御できます。
注: 通常は、この再試行機能を調整する必要はありません。ここでは、すべての状況について説明しておきます。

ここでのビジネス・ケースを例に取ると、非同期通信をサポートするため、SCA により多くの SI バス宛先が作成されています。

すでに学んだとおり、これらの宛先の 1 つは「sca/AccountRouting」と呼ばれます。非同期サービス呼び出しの ServiceRuntimeException 時に実行される再試行回数は、管理コンソールを介して「最大デリバリー失敗数」プロパティーの値を変更することによって調整できます。ただし、BPEL プロセスによるモジュールで、2 未満の値を設定することはできません。ServiceRuntimeExceptions を BPEL に戻して処理するには、2 回目のデリバリーが必要になります。

システム例外宛先

Failed Event Manager は、障害を管理するために調べることができる場所の 1 つです。JMS または EIS ベースのインポートおよびエクスポートを処理する場合は、別の重要な場所について考慮する必要があります。

SCA.Application バスの宛先は、失敗したメッセージを、そのバスの SIB システム例外宛先に経路指定するように構成されます。したがって、JMS エクスポートが SCA.Application バスからメッセージを選出し、ロールバック・シチュエーションに入ると、失敗したメッセージは、WBI リカバリー例外宛先ではなく、その SIB システムの例外宛先に経路指定されます。このシナリオは、SCA.Application バスでメッセージの非直列化に失敗しても失敗したイベントが生成されないという点で、上述の失敗したイベントの説明とは異なります。ソリューション内のすべてのバスには、システム例外宛先があります。これらの宛先は、ほとんど MQ インフラストラクチャーに共通の「送達不能キュー」のようにして、モニターおよび管理する必要があります。

以下のシナリオについて考えてみてください。

システム例外が処理される方法を示す図
外部の JMS クライアントは、JMS エクスポートによって公開されるインバウンド・キューにメッセージを格納します。JMS エクスポート・バインディング MDB は、処理するメッセージを選出します。ここから、以下の 2 つのいずれかの状態になります。
  1. JMS エクスポートは、メッセージを正常に解析し、呼び出されるインターフェース上の操作を判別します。この時点で、処理のためにメッセージが SCA ランタイムに送信されます。
  2. JMS エクスポートは、有効なビジネス・オブジェクトとしてメッセージ本文を認識することに失敗するか、または JMS エクスポート・バインディングがメッセージ本文を非直列化 しても、インターフェースで呼び出す適切な操作を判別できません。この時点でメッセージは、バスのシステム例外宛先に格納されます。

この種の失敗は、AccountRoutingJMSExport (1) から要求を受け取ろうとするときに発生する可能性があります。このエクスポートは JMS エクスポートの 1 つで、イベントが SCA.Application.Bus のシステム例外宛先に累積する可能性があります。選択した IT モニター・ソリューションを使用して、この宛先の深さを観察してください。

Failed Event Manager と SIB の宛先

WebSphere ESB の場合、例外宛先は WebSphere ESB 例外宛先キューに設定されます。このキューは、次の命名規則に従います。
ノード名: WESBNode
サーバー名: server1
リカバリー例外宛先: WBI.FailedEvent.WESBNode.server1
一般に、SCA.System バスで作成されるすべての宛先は、失敗したメッセージがリカバリー例外宛先に経路指定されるように構成されます。

システム障害が発生すると、失敗したメッセージがこの例外宛先に取り込まれるのに加えて、WebSphere ESB リカバリー機能によってシステム・エラーを表す失敗したイベントが生成され、この資料の『Failed Event Manager』セクションで説明したようにこのイベントがリカバリー・データベースに保管されます。

要約

要約すると、WebSphere ESB には、基本となる WebSphere Application Server プラットフォーム以上の管理機能が提供されています。これらの機能を理解して使用するには、『エラー防止およびリカバリーの計画』の『エラー防止計画』セクションに提供されているガイダンスに従うなど、適切な手段を講じる必要があります。

表 3. 障害管理を支援する管理機能
管理機能 WebSphere ESB にバンドルされているか (Y/N)? 要約
Failed Event Manager はい 読み取り/編集/削除アクセス。これは、サービス・ランタイム例外と他の形態のインフラストラクチャーの障害を管理するための中心的な場所です。

Service Integration Bus Browser

はい

読み取り/削除。Service Integration Bus Browser は、サービス統合バスにおける日常の操作タスクの参照および実行のために管理コンソール上で使用します。

注: これらのツールで同時に管理できるイベントまたはレコードの数は、メモリー割り振り、結果セットおよび DB チューニング、接続タイムアウトなどの外部要因に依存します。テストを実行し、例外 (OOM、TransactionTimeOut) を回避する適切なしきい値を設定してください。

concept 概念トピック

ご利用条件 | フィードバック


タイムスタンプ・アイコン 最終更新: 2010/07/05


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.zseries.doc/doc/crec_use_case_recovery.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
このインフォメーション・センターでは Eclipse テクノロジーが採用されています (http://www.eclipse.org)。