ユース・ケースは、リカバリー・シナリオでのコンテキストとして使用されます。 このユース・ケースでのビジネスには、新規アカウントを作成する要求を受け取るアプリケーションがあります。
このソリューションは、モジュールのベスト・プラクティスによって推奨されている複数のモジュールで構成されています。
最初のモジュールは、要求を仲介し、処理をアカウント作成プロセスに委任します。以下の例では、別々のモジュールとしてソリューションを実装しています。要求は、SCA インポート/エクスポートを介してメディエーション・モジュール (AccountRouting) と処理モジュール (AccountCreation) の間で渡されます。2 つのモジュールの説明については、以下の画面取りを参照してください。
図 1 に示されるアセンブリー・ダイアグラムから始めて、障害が発生した可能性があるフロー内の場所を表示することができます。アセンブリー・ダイアグラム内の呼び出しポイントすべては、トランザクションを伝搬したり関係させたりすることができます。フロー内には、アプリケーションまたはシステムの障害の結果としてデータが集まる領域がいくつかあります。
一般に、トランザクション境界は、コンポーネントおよびインポート/エクスポート・バインディングとそれらの関連付けられた修飾子との間の対話 (同期および非同期) によって作成および管理されます。ビジネス・データは、トランザクション障害、デッドロック、またはロールバックのために、ほとんどの場合に特定のリカバリー・ロケーションに累積します。
WebSphere® Application Server 内のトランザクション機能により、WebSphere ESB は、サービス・プロバイダーによるトランザクションを参加させることができます。このような参加による対話は、インポートおよびエクスポートのバインディングについて理解する上で特に重要です。特定のビジネス・ケース内でのインポートとエクスポートの使用方法を理解することは、リカバリーする必要があるイベントが累積している場所を判別するために重要です。
エラー処理方針では、対話パターン、使用するトランザクション、インポートおよびエクスポートの使用をアプリケーションの開発前に定義する必要があります。ソリューションの設計者は、アプリケーションが作成されるときに使用される、使用する設定およびガイドラインを識別する必要があります。 例えば設計者は、同期呼び出しまたは非同期呼び出しをいつ使用するか、また BPEL 障害処理をいつ使用するかなどを理解する必要があります。 設計者は、すべてのサービスがトランザクションに参加できるかどうか、また参加できないサービスについては、問題が発生したときに補正をどう処理するかについて知っておく必要があります。
また、図 1 のアセンブリー・ダイアグラムに示されるアプリケーションでは、接続グループとモジュール開発のベスト・プラクティスを活用しています。このパターンを活用することにより、AccountRouting モジュールを停止して、新規イベントのインバウンド・フローを停止することができるようになっています。
以下のセクションでは、障害およびリカバリーにおけるビジネス・データのロケーションを説明します。
このビジネス・ケースでは、AccountCreation プロセスで BPEL プロセスを活用します。
短期実行プロセスはマイクロフローとして知られています。
これらの質問に対する答えを知ることは、以下の画面取りで強調表示されているアセンブリー・ダイアグラムの呼び出し 7 および 8 のリカバリー方針に影響を与えます。
長期実行 BPEL プロセスやビジネス・ステート・マシンなどのステートフル・コンポーネントには、プロセス・アクティビティー変更と状態変更がデータベースに対してコミットされる、数多くのデータベース・トランザクションが関係しています。作業は、データベースを更新し、次に実行する内容を記述したメッセージを内部キューに格納することによって進行します。
Business Flow Manager 内部のメッセージの処理で問題が発生した場合、これらのメッセージは保存キュー に移動します。システムは、メッセージの処理を続行しようとします。後続メッセージが正常に処理されると、保存キューのメッセージが再実行依頼されて処理されます。同じメッセージが保存キューに 5 回格納された場合、そのメッセージは保留キューに移されます。
メッセージ数の表示とメッセージの再生についての追加情報は、『保存キュー/保留キューからのメッセージの再生 (Replaying Messages from the Retention Queue / Hold Queue)』で提供されています。
Failed Event Manager (FEM) は、ほとんどの コンポーネント・タイプの間で非同期に実行された、イベントまたはサービス呼び出し要求の再生に使用されます。
失敗したイベントは、AccountRouting コンポーネントが SCA インポート・バインディング AccountCreationSCAImport を非同期で呼び出し、ServiceRuntimeException が戻された場合に作成されます。
重要な点として、BPEL がサービス対話においてクライアントになっている場合は、そのほとんどにおいて失敗したイベントが生成されません。つまり、(図 2 に示される) 7 および 8 の呼び出しでは、通常は失敗したイベントになりません。BPEL には、障害をモデル化するために、障害ハンドラーやその他の方法が用意されています。この理由から、「JDBCOutboundInterface」を呼び出す ServiceRuntimeException (SRE) 障害が発生した場合、SRE は処理のために BPEL に戻されます。プロジェクトのエラー処理方針では、BPEL において一貫した方法で実行時例外を処理する方法を定義してください。
ただし、インフラストラクチャー障害のためにプロセス・インスタンスにメッセージを配信できない場合には、BPEL クライアントへの非同期応答メッセージに対して、失敗したイベントが作成されることを念頭においてください。
以下の図は、Failed Event Manager コンポーネントの動作方法を示しています。図では、番号付けされた各ステップに関連する処理の説明を示しています。
再試行制限のデフォルト値は 5 (最初の呼び出しの 1 回および再試行 4 回) です。このデフォルト値は、管理コンソールで変更できます。例えば、M という SCA モジュールの場合は、
にナビゲートし、「最大デリバリー失敗数」フィールドで値を変更します。「失敗したイベント」はいつ作成されるか?
すでに述べたように、失敗したイベントは、同期呼び出しで作成されるのでも、標準的に両方向ビジネス・プロセス対話で作成されるのでもありません。
失敗したイベントは、通常、クライアントが非同期呼び出しパターンを使用し、サービス・プロバイダーが ServiceRuntimeException を throw したときに作成されます。
すべてが同じトランザクションで同期されて実行される場合、データはどこにも収集されません。その代わりに、データは呼び出しを行ったクライアントにすべてロールバックされます。コミットが発生すると、データは収集されます。呼び出しはすべて同期されて行われたが、複数のコミットが存在する場合、これらのコミットが問題になります。
一般的に、複数のトランザクションが必要な場合は、非同期処理呼び出しまたは長期実行 BPEL を使用する必要があります。毎回の ASYNC 呼び出しが、データ収集の機会となります。長期実行 BPEL 処理はコレクション・ポイントです。
呼び出しパターン | 失敗したイベントが作成されるかどうか (Y/N)? | 注 |
---|---|---|
同期 | いいえ | 失敗イベントは、サービス・ビジネス例外用に作成されず、同期パターンを使用するときも作成されません。 |
非同期 - 片方向 | いいえ | 定義により、片方向呼び出しでは障害を宣言できません。つまり、ServiceBusinessException を throw するのは不可能です。 |
非同期 - 据え置き応答 | いいえ | 失敗イベントは、サービス・ビジネス例外用に作成されません。 |
非同期 - コールバック | いいえ | 失敗イベントは、サービス・ビジネス例外用に作成されません。 |
呼び出しパターン | 失敗したイベントが作成されるかどうか (Y/N)? | 注 |
---|---|---|
同期 | いいえ | 失敗イベントは、サービス・ランタイム例外用に作成されず、同期パターンを使用するときも作成されません。 |
非同期 - 片方向 | はい | |
非同期 - 据え置き応答 | はい | |
非同期 - コールバック | はい | |
BPEL - 双方向 | いいえ | 失敗イベントは、ソース・コンポーネントがビジネス・プロセスのときは作成されません。
注: 非同期呼び出しについて、応答を BPEL に戻すことができない場合、失敗イベントが作成されます。
|
BPEL - 片方向 | はい |
失敗したイベントの表示および再実行依頼に関する追加情報については、セクション『失敗したイベントの再サブミット』を参照してください。
SCA モジュール宛先
再び、ビジネス・ケースに戻ります。
これらの宛先は、モジュールがアプリケーション・サーバーまたはクラスターにデプロイされるときに作成されます。
これらの宛先にメッセージが累積されることはまれです。これらの場所にメッセージが累積されるということは、パフォーマンス上の問題やアプリケーションの問題が発生している可能性が非常に高いことを示します。すぐに調査してください。メッセージのバックアップによってシステムが停止したり、リサイクル時間が延長されたりすることになるので、(選択した IT モニター・ソリューションによって) モジュールの宛先の深さをモニターすることは重要です。
これらは、生成される名前が「sca/」付きのモジュール名と同じになるため、「SCA モジュール」宛先と呼びます。これらの宛先は、SCA 非同期呼び出し (要求と応答のブローカリング) の機能において中心的な役割を果たします。SCA.SYSTEM バスへのアプリケーションのインストール中に生成される追加の宛先の数はさまざまですが、ここでは説明の目的上、「SCA モジュール」宛先の重要性について扱います。
システム統合バス再試行
ここでのビジネス・ケースを例に取ると、非同期通信をサポートするため、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 インフラストラクチャーに共通の「送達不能キュー」のようにして、モニターおよび管理する必要があります。
以下のシナリオについて考えてみてください。
この種の失敗は、AccountRoutingJMSExport (1) から要求を受け取ろうとするときに発生する可能性があります。このエクスポートは JMS エクスポートの 1 つで、イベントが SCA.Application.Bus のシステム例外宛先に累積する可能性があります。選択した IT モニター・ソリューションを使用して、この宛先の深さを観察してください。
Failed Event Manager と SIB の宛先
ノード名: WESBNode サーバー名: server1 リカバリー例外宛先: WBI.FailedEvent.WESBNode.server1一般に、SCA.System バスで作成されるすべての宛先は、失敗したメッセージがリカバリー例外宛先に経路指定されるように構成されます。
システム障害が発生すると、失敗したメッセージがこの例外宛先に取り込まれるのに加えて、WebSphere ESB リカバリー機能によってシステム・エラーを表す失敗したイベントが生成され、この資料の『Failed Event Manager』セクションで説明したようにこのイベントがリカバリー・データベースに保管されます。
要約すると、WebSphere ESB には、基本となる WebSphere Application Server プラットフォーム以上の管理機能が提供されています。これらの機能を理解して使用するには、『エラー防止およびリカバリーの計画』の『エラー防止計画』セクションに提供されているガイダンスに従うなど、適切な手段を講じる必要があります。
管理機能 | WebSphere ESB にバンドルされているか (Y/N)? | 要約 |
---|---|---|
Failed Event Manager | はい | 読み取り/編集/削除アクセス。これは、サービス・ランタイム例外と他の形態のインフラストラクチャーの障害を管理するための中心的な場所です。 |
Service Integration Bus Browser |
はい |
読み取り/削除。Service Integration Bus Browser は、サービス統合バスにおける日常の操作タスクの参照および実行のために管理コンソール上で使用します。 |