ヘッダーをスキップ
Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド
11g リリース1(11.1.1.7)
B55916-08
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

15 BPELプロセスのサービス・コンポーネントとエンジンの管理

この章では、BPELプロセス・サービス・コンポーネントとサービス・エンジンの管理方法(サービス・コンポーネントとサービス・エンジンのフォルトのリカバリ、サービス・コンポーネントのポリシーの管理、配信されていない起動メッセージとコールバック・メッセージについてのBPELプロセス・メッセージ・リカバリの実行、およびインスタンスとメッセージ・データのOracle Coherenceキャッシュへの格納を含む)について説明します。

この章では、次の項目について説明します。

サービス・コンポーネントとサービス・エンジンの概念の詳細は、次の項を参照してください。

15.1 BPELプロセス・サービス・コンポーネントのフォルトのリカバリ

リカバリ可能として識別されたBPELプロセス・サービス・コンポーネントを監視し、個別のフォルト・リカバリと一括のフォルト・リカバリを実行できます。リカバリ可能として識別されたBPELプロセス・フォルトについては、(fault-bindings.xmlファイルを介して)フォルトにバインドされ、アクションora-human-interventionをトリガーするフォルト・ポリシーが定義されている必要があります。ただし、フォルト・ポリシーが定義されていない場合、フォルトは、リカバリ可能またはリカバリ不可のフォルトとして通常どおり処理されます。

BPELプロセス・サービス・コンポーネントのフォルトをリカバリする手順は、次のとおりです。

  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...
    1. 「ホーム」を選択します。

    2. 「デプロイ済コンポジット」タブを選択します。

    3. 「コンポジット」セクションで、特定のSOAコンポジット・アプリケーションを選択します。

    1. 「soa-infra」の下にあるパーティションを展開します。

    2. 特定のSOAコンポジット・アプリケーションを選択します。


  2. 「コンポーネント・メトリック」セクションで、BPELプロセス・サービス・コンポーネントを選択します。

  3. 「フォルト」をクリックします。

    「フォルト」ページに、次の詳細が表示されます。

    • 特定のフォルトを検索するためのユーティリティ。基準を指定して「検索」をクリックします。詳細は、「ヘルプ」アイコンをクリックしてください。デフォルトでは、このページに初めてアクセスしたときにはフォルトは表示されません。フォルトを表示するには、「検索」をクリックする必要があります。

    • サービス・コンポーネントで発生したフォルト。フォルトID、エラー・メッセージ、フォルトのリカバリが可能かどうか、フォルトの発生時間、サービス・コンポーネントのインスタンスID、フォルトが発生したアクティビティ、およびフォルトが記述されているログ・ファイルへのリンクが表示されます。

    bpel_comp_faults.gifの説明が続きます
    図版bpel_comp_faults.gifの説明

    リカバリが可能として識別されたBPELプロセス・サービス・コンポーネントのフォルトはリカバリできます。

  4. 次のいずれかの方法を使用して、リカバリ対象のフォルトを選択します。BPELプロセス・サービス・コンポーネント・レベルでフォルト・リカバリ対象を選択することは、SOAインフラストラクチャ・レベル、SOAコンポジット・アプリケーション・レベルおよびOracle Mediatorサービス・コンポーネント・レベルで選択するのと同じです。

    対象 操作

    単一フォルト・リカバリ

    単一フォルト・リカバリの対象を選択するには、次の3つの方法があります。

    1. リカバリ可能として識別されたフォルトの行をクリックします。行が強調表示された状態で、ステップ6の説明に従って、「リカバリ・アクション」リストから特定のアクションを選択します。

    2. 「リカバリ」列で「リカバリ」リンクをクリックし、インスタンス監査証跡の「フォルト」ページにアクセスしてフォルト・リカバリを実行します。

    3. 「エラー・メッセージ」列で、リカバリ可能として識別されたフォルトのメッセージをクリックします。完全なフォルト詳細(フォルトID、フォルトの発生時間、フォルトの場所、フォルト・タイプ、エラー・メッセージ・テキストなど)が表示されます。リカバリ可能なフォルトには、「ここでリカバリ」オプションが表示されます。「ここでリカバリ」をクリックし、インスタンス監査証跡の「フォルト」ページにアクセスしてフォルト・リカバリを実行します。

    一括フォルト・リカバリ

    一括フォルト・リカバリの対象を選択するには、次の2つの方法があります。

    1. [Shift]キーまたは[Ctrl]キーを押しながら、行から特定のフォルトを選択します。

      または

    2. 「選択」メニューから、「すべてのリカバリ可能な値を選択」を選択します。次に、[Shift]キーまたは[Ctrl]キーを押しながらクリックすることによって、リカバリ操作に含めないフォルトの選択を解除します。

      次に:

    3. ステップ6の説明に従って、「リカバリ・アクション」リストからアクションを選択します。

      注意: 選択できるのは、選択したすべてのフォルトに適用可能なアクションのみです。

    すべてのフォルトのリカバリ

    1. 「選択」メニューから、「すべてのリカバリ可能な値を選択」を選択します。

    2. ステップ6の説明に従って、「リカバリ・アクション」リストからアクションを選択します。

      注意: 選択できるのは、選択したすべてのフォルトに適用可能なアクションのみです。



    注意:

    ほとんどの場合、フォルト・ポリシーのアクションは自動的に実行されます。ただし、アクションora-human-interventionを使用するフォルト・ポリシーを定義した場合は例外です。このアクションによって、Oracle Enterprise Manager Fusion Middleware Controlからリカバリできるリカバリ可能なフォルトが作成されます。


  5. 「リカバリ・アクション」リストからアクションを選択します。

    アクション 説明

    再試行

    インスタンスを直接再試行します。このリカバリ・アクションを使用するシナリオ例は、ネットワーク・エラーのためにサービス・プロバイダにアクセスできないことが原因でフォルトが発生した場合の例です。ネットワーク・エラーは現在解決しています。

    中断

    インスタンス全体を終了します。

    リプレイ

    フォルトが発生したスコープ・アクティビティ全体を再度リプレイします。

    再スロー

    現在のフォルトを再スローします。フォルトの処理に、BPELフォルト・ハンドラ(catchブランチ)が使用されます。デフォルトでは、再スロー・フォルト・ポリシーが明示的に指定されていない場合、すべての例外がフォルト管理フレームワークによって捕捉されます。

    続行

    フォルトを無視して処理を続行します(フォルト・アクティビティには成功のマークが付けられます)。


  6. 「フォルト」表内から次の追加監視タスクを実行します。

    1. 「リカバリ可能なフォルトのみ表示」チェック・ボックスを選択すると、リカバリ可能なフォルトのみ表示されます。

    2. 「フォルト・タイプ」リストから、すべてのフォルト、システム・フォルト、ビジネス・フォルトまたはOracle Web Services Manager(OWSM)フォルトを選択して、「フォルト」表に表示します。これらのフォルト・タイプの詳細は、「ヘルプ」アイコンをクリックしてください。

    3. 「ビュー」リストから、「列」「フォルトID」の順に選択し、各エラー・メッセージのフォルトIDを表示します。フォルトIDは自動的に生成され、フォルトを一意に識別します。フォルトIDは、エラー・メッセージをクリックしたときも表示されます。

    4. 「コンポーネント・インスタンスID」列で、特定のサービス・コンポーネントIDをクリックし、インスタンスに関するタスク詳細(たとえば、タスクの現在の状態)にアクセスします。拒否メッセージにはコンポーネント・インスタンスIDがありません。

    5. 「ログ」列で、リンクをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。

詳細は、次のドキュメントを参照してください。

15.2 BPELプロセス・サービス・コンポーネントのポリシーの管理

現在デプロイされているSOAコンポジット・アプリケーションのBPELプロセス・サービス・コンポーネントとの間で、ポリシーをアタッチおよびデタッチできます。ポリシーでは、メッセージ配信に対してセキュリティが適用されます。Oracle Fusion Middlewareでは、ポリシー・ベースのモデルを使用してWebサービスを管理します。


注意:

ポリシーをアタッチするには、その前に、使用可能なポリシーの定義と使用環境で使用するポリシーの詳細について、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。


BPELプロセス・サービス・コンポーネント・ポリシーを管理する手順は、次のとおりです。

  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...
    1. 「ホーム」を選択します。

    2. 「デプロイ済コンポジット」タブを選択します。

    3. 「コンポジット」セクションで、特定のSOAコンポジット・アプリケーションを選択します。

    1. 「soa-infra」の下にあるパーティションを展開します。

    2. 特定のSOAコンポジット・アプリケーションを選択します。


  2. 「コンポーネント・メトリック」セクションで、BPELプロセス・サービス・コンポーネントを選択します。

  3. 「ポリシー」をクリックします。

    「ポリシー」ページを使用すると、BPELプロセス・サービス・コンポーネントとの間でポリシーをアタッチおよびデタッチできます。「ポリシー」表には、アタッチされたポリシーの名前、切替え可能なポリシー参照ステータス(有効または無効)、カテゴリ(「管理」、「信頼できるメッセージング」、「MTOMアタッチメント」、「セキュリティ」または「WSアドレス」)、違反、およびSOAインフラストラクチャの最後の再起動以降の認証、認可、機密性および整合性の失敗が表示されます。

    bpel_comp_policy.gifの説明が続きます
    図版bpel_comp_policy.gifの説明

  4. 「アタッチ/デタッチ」をクリックします。

    複数のコンポーネントが使用可能な場合は、アタッチまたはデタッチを実行するサービスまたはコンポーネントを選択するプロンプトが表示されます。

  5. ポリシーのアタッチ先またはデタッチ先のサービスまたはコンポーネントを選択します。

    ポリシーをアタッチまたはデタッチするためのダイアログが起動します。

    「アタッチされたポリシー」セクションに、現在アタッチされているポリシーが表示されます。「使用可能なポリシー」セクションには、アタッチ可能な追加のポリシーが表示されます。

  6. 使用環境に適したポリシーを選択してアタッチします。

  7. 「アタッチ」をクリックします。

  8. ポリシーのアタッチを終了した後は、「検証」をクリックします。

  9. エラー・メッセージが表示された場合は、検証エラーがなくなるまで必要な修正を行います。

  10. 「OK」をクリックします。

    アタッチしたポリシーが「ポリシー」表に表示されます。

詳細は、次のドキュメントを参照してください。

15.3 BPELプロセス・サービス・エンジンのフォルトのリカバリ

BPELプロセス・サービス・エンジンで発生し、リカバリ可能として識別されたフォルトを監視し、個別リカバリと一括リカバリを実行できます。BPELプロセス・サービス・エンジンでは、すべてのBPELプロセス・サービス・コンポーネントのフォルトを、属しているSOAコンポジット・アプリケーション・インスタンスに関係なく表示できます。リカバリ可能として識別されたBPELプロセス・フォルトについては、(fault-bindings.xmlファイルを介して)フォルトにバインドされ、アクションora-human-interventionをトリガーするフォルト・ポリシーが定義されている必要があります。ただし、フォルト・ポリシーが定義されていない場合、フォルトは、リカバリ可能またはリカバリ不可のフォルトとして通常どおり処理されます。

BPELプロセス・サービス・エンジンのフォルトをリカバリする手順は、次のとおりです。

  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...
    1. 「サービス・エンジン」「BPEL」の順に選択します。

    1. 「soa-infra」を右クリックします。

    2. 「サービス・エンジン」「BPEL」の順に選択します。


  2. 「フォルト」をクリックします。

    「フォルト」ページに、次の詳細が表示されます。

    • 特定のフォルトを検索するためのユーティリティ。基準を指定して「検索」をクリックします。詳細は、「ヘルプ」アイコンをクリックしてください。デフォルトでは、このページに初めてアクセスしたときにはフォルトは表示されません。フォルトを表示するには、「検索」をクリックする必要があります。

    • サービス・エンジンで発生したフォルト。フォルトID、エラー・メッセージ、フォルトのリカバリが可能かどうか、フォルトの発生時間、フォルトが発生したSOAコンポジット・アプリケーションとサービス・コンポーネント、およびサービス・コンポーネント・インスタンスIDが表示されます。

    bpel_se_faults.gifの説明が続きます
    図版bpel_se_faults.gifの説明

    リカバリが可能として識別されたBPELプロセス・サービス・エンジンのフォルトはリカバリできます。

  3. 次のいずれかのオプションを使用して、リカバリ対象のフォルトを選択します。SOAインフラストラクチャ・レベル、SOAコンポジット・アプリケーション・レベルおよびOracle Mediatorサービス・コンポーネント・レベルでのフォルト・リカバリと同様に、単一フォルト・リカバリ、一括フォルト・リカバリ、およびすべてのフォルトのリカバリを実行できます。フォルトを選択してこれらのタイプのリカバリを実行する手順については、第15.1項「BPELプロセス・サービス・コンポーネントのフォルトのリカバリ」のステップ5を参照してください。


    注意:

    ほとんどの場合、フォルト・ポリシーのアクションは自動的に実行されます。ただし、アクションora-human-interventionを使用するフォルト・ポリシーを定義した場合は例外です。このアクションによって、Oracle Enterprise Manager Fusion Middleware Controlからリカバリできるリカバリ可能なフォルトが作成されます。


  4. 「リカバリ・アクション」リストからアクションを選択します。

    アクション 説明

    再試行

    再試行成功時アクションを指定するオプション付きでインスタンスを再試行します。このリカバリ・アクションを使用するシナリオ例は、ネットワーク・エラーのためにサービス・プロバイダにアクセスできないことが原因でフォルトが発生した場合の例です。ネットワーク・エラーは現在解決しています。

    中断

    インスタンス全体を終了します。

    リプレイ

    フォルトが発生したスコープ・アクティビティ全体を再度リプレイします。

    再スロー

    現在のフォルトを再スローします。フォルトの処理に、BPELフォルト・ハンドラ(catchブランチ)が使用されます。デフォルトでは、再スロー・フォルト・ポリシーが明示的に指定されていない場合、すべての例外がフォルト管理フレームワークによって捕捉されます。

    続行

    フォルトを無視して処理を続行します(フォルト・アクティビティには成功のマークが付けられます)。


  5. 「フォルト」表内から次の追加監視タスクを実行します。

    1. 「リカバリ可能なフォルトのみ表示」チェック・ボックスを選択すると、リカバリ可能なフォルトのみ表示されます。

    2. 「フォルト・タイプ」リストから、すべてのフォルト、システム・フォルト、ビジネス・フォルトまたはOWSMフォルトを選択して、「フォルト」表に表示します。これらのフォルト・タイプの詳細は、「ヘルプ」アイコンをクリックしてください。

    3. 「ビュー」リストから、「列」「フォルトID」の順に選択し、各エラー・メッセージのフォルトIDを表示します。フォルトIDは自動的に生成され、フォルトを一意に識別します。フォルトIDは、エラー・メッセージをクリックしたときも表示されます。

    4. 「コンポジット」列で、特定のSOAコンポジット・アプリケーションをクリックし、そのホーム・ページにアクセスします。

    5. 「コンポーネント」列で、特定のサービス・コンポーネントをクリックし、そのホーム・ページにアクセスします。

    6. 「コンポーネント・インスタンスID」列で、特定のサービス・コンポーネントIDをクリックし、インスタンスに関するタスク詳細(たとえば、タスクの現在の状態)にアクセスします。拒否メッセージにはコンポーネント・インスタンスIDがありません。

詳細は、次の各項を参照してください。

15.4 BPELプロセス・サービス・エンジンのメッセージ・リカバリの実行

プロセス・インスタンスのトランザクション・ロールバックによって配信されなかった起動メッセージまたはコールバック・メッセージのリカバリは、手動で実行できます。起動メッセージのリカバリは、非同期のBPELプロセスにのみ適用されます。同期BPELプロセスは、エラーをコール側クライアントに返すため、「リカバリ」ページからはリカバリできません。リカバリ可能アクティビティは失敗したアクティビティですが、リカバリが可能です。たとえば、非同期BPELプロセスを起動するファイル・アダプタを使用しているときに、システムがインスタンスの処理中にクラッシュした場合は、すべてのメッセージ・レコードが確実にリカバリされるように、サーバーが再起動したときに手動でリカバリを実行できます。

BPELプロセス・サービス・エンジンによる自動リカバリの試行に失敗したメッセージを管理することもできます。これらのメッセージの自動リカバリが複数回試行されないようにするには、これらのメッセージを消耗済状態にします。その後、これらのメッセージに対して次のいずれかのアクションを実行できます。

たとえば、データベース・アダプタに書き込むBPELプロセスがあるとします。データベースがダウンしている場合、これらのメッセージはリカバリ・キューに送信されます。これらのメッセージの自動リカバリは、データベースがダウンしている間は失敗します。これらのメッセージには、自動リカバリが再び試行されないように消耗済状態のマークが付けられます。データベースの実行が再び開始されたら、自動リカバリが再び試行されるように、これらのメッセージをリセットする(自動リカバリ・キューに戻す)ことができます。

BPELプロセス・サービス・エンジンのメッセージをリカバリする手順は、次のとおりです。

  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...
    1. 「サービス・エンジン」「BPEL」の順に選択します。

    1. 「soa-infra」を右クリックします。

    2. 「サービス・エンジン」「BPEL」の順に選択します。


  2. 「リカバリ」をクリックします。

    「リカバリ」ページに、次の詳細が表示されます。

    • 「アラーム表のリフレッシュ」ボタンは、データベース内の消失したインメモリー・クォーツ・スケジュール済ジョブを再同期化する場合に選択します。たとえば、waitアクティビティ、またはpickアクティビティのonAlarmブランチでタイマーが起動され、そのトランザクションがロールバックされたと仮定します。データベースのwaitアクティビティまたはonAlarmブランチにあるBPELインスタンスを使用して、これらのジョブを再同期化できます。

    • 特定のメッセージの失敗を検索するためのユーティリティ。基準を指定して「検索」をクリックします。詳細は、「ヘルプ」アイコンをクリックしてください。

      「ECID」フィールドに実行コンテキストID (ECID)値を入力できます。ECID値を使用すると、様々なコンポジット・アプリケーションのインスタンス間のメッセージ・フローを追跡できます。リカバリが必要なBPELプロセス・メッセージがあり、システムMBeanブラウザのAuditConfigプロパティが「すべて」 (デフォルト値)に設定されている場合は、「フローのトレース」ページの「トレース」表に次の警告メッセージが表示されます。

      BPEL Message Recovery Required
      

      「詳細表示」またはこのメッセージの横に表示されるリカバリ・アイコンをクリックすると、「警告」ダイアログがリカバリ可能メッセージ・タイプ(起動、コールバックおよびアクティビティ)の数およびECID値に関する情報とともに表示されます。「リカバリ」ページで検索基準を作成する一環として、「警告」ダイアログからECID値をコピーして「ECID」フィールドに貼り付け、リカバリ可能メッセージ・タイプを「タイプ」リストから選択できます。

      詳細は、第14.1項「BPELプロセス・サービス・コンポーネントの監査証跡とプロセス・フローの監視」を参照してください。


      注意:

      特定のECID値のメッセージを検索する際のSQL問合せのパフォーマンスを向上させるために、DLV_MESSAGE表のDLV_MESSAGE.ECID列に索引を追加することをお薦めします。これは、DLV_MESSAGE表のエントリが多すぎる場合、検索の問合せが遅くなり、データベースに過大な負荷をかける可能性があるためです。索引の追加の詳細は、『Oracle Database管理者ガイド』の「索引の作成」を参照してください。


    • サービス・エンジンでのメッセージの失敗。対話ID、メッセージの失敗のリカバリが可能かどうか、サービス・コンポーネント、失敗が発生したコンポジット・アプリケーション、およびフォルトの発生時間が表示されます。状態に応じて、これらのメッセージをただちにリカバリするか、これらのメッセージを取り消すか、または自動リカバリのためにこれらのメッセージをリセットできます。

    bpel_se_recov.gifの説明が続きます
    図版bpel_se_recov.gifの説明


    注意:

    • 解決済状態および未配信状態のコールバック・メッセージをリカバリできます。「タイプ」リストから「コールバック」を選択し、「メッセージの状態」リストから「解決」または「未配信」のいずれかを選択して検索条件を実行すると、これらのメッセージがリカバリ用に表示されます。コールバック・メッセージが最初にBPELプロセス・サービス・エンジンに入るとき、その状態は未配信状態です。対話IDのマッチングまたは相関のいずれかによって、このメッセージがターゲットBPELプロセス・インスタンスに解決されると、状態は解決済に切り替えられます。これらの両方の状態では、メッセージはまだ消費されていません。これらの2つの状態のメッセージはリカバリできます(消費のためにBPELプロセス・サービス・エンジンに再配信される)。他の状況では、コールバック・メッセージがこれらの両方の状態で残されている場合があります。これらの状態のメッセージもリカバリできます。ただし、残されているコールバック・メッセージが常に未配信状態のまま保たれる保証はありません。

    • 「タイプ」リストから「呼出し」を選択し、「メッセージの状態」リストから「未配信」を選択して「リカバリ」をクリックすると、リカバリが実行されます。ただし、Oracle BPEL Process Managerサービス・コンポーネントまたはサービス・エンジンの「ダッシュボード」ページでは、このインスタンスの「最終更新日時」列は空のままになります。これは予想された動作です。最終更新日時が表示されないのは、Oracle BPEL Process Managerの最初のインスタンス(たとえばbpel:70004)が、最初の呼出しによって作成されるためです(つまり、作成されるがまだ変更されていない)。未配信の呼出しメッセージをリカバリすると、常に新しいインスタンス(たとえばbpel:70005)が作成されます。以前作成されたインスタンス(bpel:70004)は使用されず、永続的に同じステータスのまま(「最終更新日時」列が空のまま)になります。この情報は監査目的でのみ提供されます。

    • 「メッセージの状態」リストはコールバック・メッセージおよび起動メッセージのタイプのリカバリにのみ適用され、アクティビティ・メッセージのタイプのリカバリには適用されません。


  3. この表でフォルトを選択します。

  4. 次のいずれかのオプションを選択します。

    アクション 説明

    リカバリ

    フォルトが発生したメッセージを再試行します。

    消耗済状態のメッセージを選択してこのボタンをクリックすると、メッセージのリカバリが即時に試行されます。このリカバリの試行も失敗となった場合、メッセージは消耗済状態に戻ります。メッセージを選択して「リセット」をクリックし、そのメッセージを自動リカバリ・キューに戻す必要があります。

    関連する例外エラーが原因で、非同期BPELプロセスでトランザクション・ロールバック・シナリオが発生した場合は、最後のデハイドレーション・アクティビティにロールバックします。これが新しいインスタンスであり、かつ最初のデハイドレーション・アクティビティが受信アクティビティであった場合、BPELプロセス・サービス・エンジンはリカバリ可能な呼出しを作成します。呼出しをリカバリするために「リカバリ」をクリックすると、サービス・エンジンによって新しいインスタンスが作成されます。このインスタンスは、例外エラーなしで実行が完了する可能性があります。ただし、フォルトとして識別された古いインスタンスは引き続き表示されます。

    中断

    取消としてマークされているメッセージが含まれるフロー全体を終了できる確認メッセージを表示して、コンポジット・インスタンスの状態を更新する場合に選択します。メッセージ取消は、ECIDのコンテキストで実行されます。このECIDを使用して複数のコンポジット・インスタンスがリンクされている場合は、すべてのコンポジットおよびサービス・コンポーネントのインスタンスが終了します。ECIDを使用すると、様々なコンポジット・アプリケーションのインスタンスを横断するメッセージ・フローを追跡できます。

    消耗済状態のメッセージを選択してこのボタンをクリックすると、そのメッセージのリカバリは試行されなくなります。

    リセット

    消耗済メッセージを未配信状態にリセットする場合に選択します。これにより、メッセージは自動リカバリ・キューに戻されます。消耗済状態で表示されたメッセージは、メッセージ表に表示されなくなります。「メッセージの状態」リストで「未配信」を選択して「検索」をクリックすると、これらのメッセージが表示されます。消耗済状態のコールバック・メッセージを解決状態にリセットし、引き続きリカバリ可能にすることもできます。

    中断せずに取消

    選択したBPELプロセス・メッセージの配信を取り消しますが、そのメッセージが含まれるコンポジット・インスタンス・フロー全体は取り消さない場合に選択します。BPELプロセス・メッセージを取り消しても、対応するコンポジット・インスタンスの状態は変更されません。このオプションを使用するアプリケーションは限定され、たとえば同じコールバックで受信した重複メッセージを削除する場合などに使用します。消耗済状態のメッセージを選択してこのボタンをクリックすると、そのメッセージのリカバリは試行されなくなります。

    注意: 「リカバリ」ボタンと「中断せずに取消」ボタンは、次の場合に有効になります。

    • ユーザーが管理者ロールまたはオペレータ・ロールを持つ場合。監視ロールを持つユーザーに対しては、これらのボタンは無効になります。

    • リカバリ可能なメッセージの場合。リカバリ可能なメッセージを選択すると、これらのボタンが有効になります。

    ロールの詳細は、付録C「ロールおよび権限」を参照してください。


    リカバリのためにメッセージが送信されると、そのアクションがBPELプロセス・サービス・エンジンによって完了するのに時間がかかる場合があります。通常、この時間は数秒以内となります。この間、メッセージは「リカバリ」ページに表示されたままになります。この期間内に、同じメッセージのリカバリをもう1回実行しても、無視されます。最新のリカバリ・ステータスを受信するには、ページを数秒ごとに更新します。


    注意:

    ora-retryアクションを使用してBPELプロセスにフォルト・ポリシーを定義した場合は、フォルトが発生すると、BPELプロセスではフォルトからのリカバリをretryCountパラメータに指定した回数試行します。この期間の後、プロセスは実行中の状態のままになります。完了していないプロセスのアクティビティ(呼出し、受信など)のステータスは、保留中の手動リカバリとして表示されます。これは予想された動作です。


    起動メッセージおよびコールバック・メッセージのリカバリを試行する最大回数を構成する方法の詳細は、第13.4項「起動メッセージおよびコールバック・メッセージの自動リカバリ試行の構成」を参照してください。

15.5 Oracle Exalogicプラットフォームにおけるインスタンスとメッセージ・データのOracle Coherence分散キャッシュへの格納

BPELプロセスを使用すると、各インスタンスで必要なデータベースの相互作用の回数によって、パフォーマンスの問題が発生する可能性があります。この要因が、非同期の永続フローよりも同期の一時フローのパフォーマンスが優れている主な原因になっています。この問題に対応するために、レスポンス時間の短縮が必要な状況では同期の一時フローを利用するように設計できます。ただし、ビジネス上の理由で、このタイプのフローを設計できない場合があります。

Oracle ExalogicプラットフォームでOracle SOA Suite 11g リリース1(11.1.1.6)以降を実行している場合は、Oracle Coherenceの分散キャッシュ機能を使用して、BPELプロセスからインスタンスとメッセージ・データを格納できます。これによってデータベースの読取り回数が減るため、データベースの相互作用の回数が減ります。

Oracle Coherenceは、頻繁に使用されるデータへのアクセスを提供することによって、企業がミッションクリティカルなアプリケーションを拡張することを可能にするOracle Fusion Middlewareのコンポーネントです。Oracle Coherenceに含まれる分散キャッシュ機能によって、読取りアクセスと書込みアクセスの両方のスケーラビリティが向上します。データはノード間で自動的、動的および透過的にパーティション化されます。分散アルゴリズムがネットワーク・トラフィックを最小化し、データが徐々に移動されることでサービスの停止が回避されます。

Oracle Exalogicは、幅広いアプリケーション・タイプと様々なワークロードに対応するプラットフォームを提供するように設計された、ハードウェアとソフトウェアの統合システムです。Oracle Exalogicは、大規模で、パフォーマンスの影響を受けやすく、ミッションクリティカルなアプリケーションのデプロイを対象にしています。


注意:

使用している環境でOracle Exalogicを使用していない場合、Oracle Coherenceの分散キャッシュは使用できません。


BPELプロセスに対して分散キャッシュを使用すると、次のようなパフォーマンスの向上を期待できます。

Oracle Coherenceの詳細は、Oracle Coherenceスタート・ガイドおよびOracle Coherence開発者ガイドを参照してください。

Oracle Exalogicの詳細は、Oracle Exalogicマシン所有者ガイドを参照してください。

15.5.1 Oracle Coherenceのキャッシュ機能アーキテクチャの概要

デハイドレーション時に、インスタンス・オブジェクトは、コンテナ管理のEnterprise JavaBeans(EJB)トランザクションでJava永続性API(JPA)を使用してデータベースに格納されます。BPELプロセス・サービス・エンジンでは、トランザクション後の処理用にトランザクションのafterCompletionリスナーを登録します。トランザクション中に変更されたインスタンス・オブジェクトは、追跡されてafterCompletionリスナーに対して使用可能になり、このリスナーによってキャッシュが更新されます。図15-1に、デハイドレーション・プロセスの詳細を示します。

図15-1 デハイドレーション・プロセス

図15-1の説明は次にあります。
「図15-1 デハイドレーション・プロセス」の説明

リハイドレーション時に、インスタンス・オブジェクトはキャッシュから読み取られます。実装では、トランザクション完了通知のXA保証は提供されず、キャッシュの削除によってオブジェクトがキャッシュから削除されます。実装では、これら2つの事項を考慮して、オブジェクトが返されない、または古いバージョンのオブジェクトが返されるというキャッシュの問題に対処します。

通常は、キャッシュの参照によって有効なオブジェクトが返されます。この場合、直接書込み(デフォルト)によるキャッシュの使用によって、デハイドレーションおよびリハイドレーションのパフォーマンスは次に示すように向上します。

(database read time + relational to object mapping) minus (Object serialization +
reading from serialized form + Coherence network overhead + query to
database for reading CACHE_VERSION)

また、データベース・サーバーでのアクティビティも減少します。

ネットワーク障害によってOracle Coherenceのキャッシュが使用できない場合でも、BPELプロセス・サービス・エンジンは稼働し続けます。エラーが発生しない場合、ビジネス・プロセス・インスタンスは処理を続行します。

15.5.2 デフォルトのSOAクラスタ・ノードおよびCoherenceキャッシュ・グリッド・ノードでの実行

BPELプロセス・キャッシュは、Oracle SOA Suiteクラスタ・ノードに作成されません。第15.5.7項「BPELプロセス・キャッシュ・サーバーの起動」の説明に従って、BPELキャッシュをホストするBPELキャッシュ・サーバーを起動する必要があります。パフォーマンスを向上させるには、最低4台のサーバーを起動してください。Oracle SOA SuiteクラスタとBPELキャッシュ・サーバーの順番に要件はありません。Oracle Enterprise Manager Fusion Middleware ControlでQualityOfServiceプロパティがCacheEnabledに設定されている場合でも、BPELプロセス・サービス・エンジンはBPELキャッシュ・サーバーがなくても稼働し続けます。

Oracle Coherenceの詳細は、Oracle Coherenceスタート・ガイドおよびOracle Coherence開発者ガイドを参照してください。

15.5.3 Oracle Coherenceのキャッシュ機能の構成

システムMBeanブラウザのQualityOfServiceプロパティを使用して、Oracle Coherenceをデハイドレーション用に構成できます。このプロパティは、SOAクラスタ内のいずれかのノードで構成できます。

Oracle Coherenceキャッシングをデハイドレーション用に構成する手順は、次のとおりです。

  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...
    1. 「SOA管理」「BPELプロパティ」の順に選択します。

    1. 「soa-infra」を右クリックします。

    2. 「SOA管理」「BPELプロパティ」の順に選択します。


    「BPELサービス・エンジン・プロパティ」が表示されます。

  2. 「詳細BPEL構成プロパティ」をクリックします。

  3. 「属性」タブで、「QualityOfService」をクリックします。

  4. 「値」フィールドに、環境に適した値を入力します。この変更によってSOAインフラストラクチャを再起動する必要はありません。

    表15-1 QualityOfServiceの値

    説明

    DirectWrite

    デハイドレーションおよびリハイドレーションでキャッシュを使用しません。読取りおよび書込み操作はデータベースに対して行われます。これがデフォルトの設定です。

    CacheEnabled

    デハイドレーション時は、インスタンス・データがXAデータ・ソース接続を使用してデータベースに格納され、トランザクション後の処理でオブジェクトがキャッシュに挿入されます。

    リハイドレーション時は、データがキャッシュからフェッチされます。データが見つからない場合(たとえば、BPELプロセス・キャッシュ・サーバーが使用できない場合)、またはバージョンが失効している場合、データはデータベースから読み取られます。


  5. 「適用」をクリックします。

15.5.4 複数の監査証跡メッセージの単一トランザクションへの格納の構成

非同期フローの場合、複数の監査証跡メッセージを単一トランザクションに格納すると、パフォーマンスが向上します。パフォーマンスを向上させるために(複数のインスタンスの)複数の監査証跡メッセージを単一トランザクションに格納するには、Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザのAsynchAuditBatchSizeプロパティを設定します。

このプロパティを適切な値に設定すると、監査証跡トランザクション・コミット数が減ります。かわりに、指定した制限に達した場合のみコミットが実行されます。

複数の監査証跡メッセージが単一トランザクションに格納されるように構成する手順は、次のとおりです。

  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...
    1. 「SOA管理」「BPELプロパティ」の順に選択します。

    1. 「soa-infra」を右クリックします。

    2. 「SOA管理」「BPELプロパティ」の順に選択します。


    「BPELサービス・エンジン・プロパティ」が表示されます。

  2. 「詳細BPEL構成プロパティ」をクリックします。

  3. 「属性」タブで、「AsynchAuditBatchSize」をクリックします。

  4. 「値」フィールドに、環境に適した値を入力します。デフォルト値の-1は、バッチ対象の監査証跡メッセージがないことを示します。各監査メッセージは、それぞれのトランザクションに保持されます。

    推奨される値の範囲は5から25です。たとえば、このプロパティを8に設定した場合、8つの監査証跡メッセージが蓄積されると、これらのメッセージに対して1つのトランザクションが作成され、デハイドレーション・ストアにコミットされます。

    このパラメータは、Oracle Exalogic環境にのみ影響します。その他の環境では使用できません。

    この変更によってSOAインフラストラクチャを再起動する必要はありません。

  5. 「適用」をクリックします。

15.5.5 Oracle Coherenceキャッシュへの監査証跡の格納の構成

Oracle Coherenceキャッシュに監査証跡を格納できます。これを行うには、Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザの次のプロパティをそれぞれの値に設定します。

これらの設定によって、次の動作が可能になります。

  • Oracle Coherenceキャッシュがキューとして動作して、データベースに監査証跡を書き込みます。

  • SOAサーバー・ノードのヒープとスレッドは、監査証跡を処理しません。

これらのプロパティのいずれかが異なる値に設定されていると、ヒープおよびディスパッチャ・スレッドがデータベースへの書込みに使用されます。

Oracle Coherenceキャッシュへの監査証跡の格納を構成する手順は次のとおりです。

  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...
    1. 「SOA管理」「BPELプロパティ」の順に選択します。

    1. 「soa-infra」を右クリックします。

    2. 「SOA管理」「BPELプロパティ」の順に選択します。


    「BPELサービス・エンジン・プロパティ」が表示されます。

  2. 「詳細BPEL構成プロパティ」をクリックします。

  3. 「属性」タブで、「AuditStorePolicy」をクリックします。

  4. 「値」フィールドに、asyncと入力します。


    注意:

    サーバーがキャッシュする場合は(SOA/BPELキャッシュ・サーバー)、一部の監査証跡メッセージはデータベースに永続化されません。この結果、監査ログが失われることになります。フェイルオーバーはサポートされません。これはOracle Coherenceの場合とメモリーまたはヒープ・キャッシュの場合の両方に適用されます。


  5. 「適用」をクリックします。

  6. 「戻る」をクリックします。

  7. 「属性」タブで、「QualityOfService.AuditStorePolicy.UseDistributedCache」をクリックします。

  8. 「値」リストから「True」を選択します。

  9. 「適用」をクリックします。

15.5.6 Oracle Coherenceキャッシュへの呼出しメッセージの格納の構成

Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザの次のプロパティをそれぞれの値に設定することで、Oracle Coherenceキャッシュに呼出しメッセージを格納できます。

これらのプロパティのいずれかが異なる値に設定されていると、Oracle Coherenceキャッシュではなく、ローカル・メモリーがキャッシュに使用されます。


注意:

サーバー(SOAおよびBPELプロセス・キャッシュ・サーバーの両方)のクラッシュ時に実行中の呼出しメッセージは損失または複製される可能性があります。フェイルオーバーはサポートされません。これはOracle Coherenceの場合とメモリーまたはヒープ・キャッシュの場合の両方に適用されます。


  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...
    1. 「SOA管理」「BPELプロパティ」の順に選択します。

    1. 「soa-infra」を右クリックします。

    2. 「SOA管理」「BPELプロパティ」の順に選択します。


    「BPELサービス・エンジン・プロパティ」が表示されます。

  2. 「詳細BPEL構成プロパティ」をクリックします。

  3. 「属性」タブで、「OneWayDeliveryPolicy」をクリックします。

  4. 「値」フィールドに、async.cacheと入力します。

  5. 「適用」をクリックします。

  6. 「戻る」をクリックします。

  7. 「属性」タブで、「QualityOfServiceOneWayDeliveryPolicyUseDistributedCache」をクリックします。

  8. 「値」リストから「True」を選択します。

  9. 「適用」をクリックします。

15.5.7 BPELプロセス・キャッシュ・サーバーの起動

start-bpel-cache.shスクリプトを実行して、Oracle SOA SuiteがインストールされているUNIXマシン上でBPELプロセス・キャッシュ・サーバーを起動します。

要件はネットワーク接続性のみです。Oracle SOA Suiteノードには、BPELプロセス・キャッシュ・サーバーがインストールされているホストからアクセスできる必要があります。

このスクリプトによって、Oracle SOA Suiteクラスタがマルチキャストのデフォルトのアドレスとポートに結合されます。これらの値は、$FMW_HOME/user_projects/domains/domain_name/bin/setDomainEnv.shファイルの対応する値と一致します。

クラスタに対してマルチキャストを選択したが、別のアドレスとポートを使用する場合は、環境変数を使用するか、またはshell変数を設定して、bpelCacheEnv.shファイル内の値を上書きできます。同じ値をSOA管理対象サーバーに対して使用します(setDomainEnv.sh内)。

Oracle SOA Suiteクラスタのデフォルトのキャッシュ構成は、マルチキャストではなくユニキャストである必要があります。Oracle CoherenceのOracle SOA Suiteクラスタに対して推奨されるキャッシュ構成の詳細は、『Oracle Fusion Middleware高可用性ガイド』または『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

BPELプロセス・キャッシュ・サーバーを起動する手順は、次のとおりです。

  1. $FMW_HOME/SOA_ORACLE_HOME/binディレクトリに移動します。

  2. start-bpel-cache.shファイルを開きます。

  3. start-bpel-cache.shファイル内の指示に従って、bpelCacheEnv.shファイルを作成し、各種の環境変数を構成します。

    環境変数またはshell変数の名前と値の書式については、start-bpel-cache.shファイルの最初のノート・セクションで説明されています。

  4. 第15.5.3項「Oracle Coherenceのキャッシュ機能の構成」で説明したように、最初にOracle Enterprise Manager Fusion Middleware ControlでQualityOfServiceプロパティをCacheEnabledに設定していることを確認します。

  5. 次のスクリプトを実行します。

    start-bpel-cache.sh