1. Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理
  2. BPELプロセスのサービス・コンポーネントとエンジンの管理
  3. BPELプロセスのサービス・コンポーネントとエンジンの構成

17 BPELプロセスのサービス・コンポーネントとエンジンの構成

この章では、BPELプロセス・サービス・コンポーネントとサービス・エンジンの構成方法(監査レベルおよび監査証跡しきい値などのプロパティ、BPELプロセスの自動リカバリ、マスター・ノード・リカバリ・スケジューリング、起動メッセージとコールバック・メッセージの自動リカバリ試行およびコールバック・メッセージの順序の保持の構成を含む)について説明します。

この章の内容は次のとおりです。

Oracle SOA SuiteおよびOracle BPELプロセスのチューニングとパフォーマンス・プロパティの詳細は、パフォーマンスのチューニングを参照してください。

BPELプロセス・サービス・エンジン・プロパティの構成

BPELプロセス・サービス・エンジン・プロパティを構成でき、このプロパティは、BPELプロセス・サービス・コンポーネントの処理時に、BPELプロセス・サービス・エンジンで使用されます。

BPELプロセス・サービス・エンジン・プロパティを構成するには:

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

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから...

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

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

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

    「BPELサービス・エンジン・プロパティ」ページに、監査レベル、監査証跡および大容量ドキュメントしきい値、ペイロード・スキーマ、BPELモニターおよびセンサーを設定するためのプロパティが表示されます。

    bpel-engine-config-props.pngの説明が続きます
    図版bpel-engine-config-props.pngの説明

  2. 使用環境に適するようにサービス・エンジン・プロパティを変更します。

    プロパティ 説明

    監査レベル

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

    • オフ: ビジネス・フロー・インスタンスのトラッキング情報とペイロード・トラッキング情報は収集されません。

    • 継承: ロギング・レベルは、SOAインフラストラクチャの監査レベルと同じです。この設定を使用すると、グローバル設定が変更されたときに、BPELプロセスの監査レベルも自動的に変更できます。このページで別の監査レベル・トラッキングを設定すると、SOAインフラストラクチャ・レベルで設定したトラッキングがオーバーライドされます。

    • 最小: BPELプロセス・サービス・エンジンでは、監査詳細がキャプチャされません。したがって、フローの監査証跡で監査詳細は使用できません。他のすべてのイベントは記録されます。

    • 本番: BPELプロセス・サービス・エンジンでは、ペイロードがキャプチャされません。フローの監査証跡でペイロード詳細は使用できません。他のBPELアクティビティのペイロード詳細は、assignアクティビティを除いて収集されます。このレベルは、標準の操作とテストに最適です。

    • 開発: ビジネス・フロー・インスタンス・トラッキングおよびペイロード・トラッキングの両方を使用可能にします。すべてのイベントが記録されます。ただし、パフォーマンスに影響を与える可能性があります。このレベルはデバッグを対象としており、システム・パフォーマンスに影響を与える可能性があります。

    監査証跡しきい値(バイト)

    監査証跡とは別にチャンクされてデハイドレーション・ストア表に保存される前の、インスタンスの監査証跡の最大サイズをバイト単位で入力します。このしきい値を超えると、ペイロードのかわりに、「XMLの表示」リンクが監査証跡に表示されます。

    大容量のドキュメントしきい値(バイト)

    コンテンツが残りのインスタンス・スコープ・データとは異なる場所に格納される前の、BPEL変数の最大サイズを入力します。

    ペイロードの検証

    インバウンド・メッセージとアウトバウンド・メッセージの検証を有効にする場合に選択します。スキーマに準拠しないペイロード・データが捕捉され、フォルトとして表示されます。

    ノート: この設定は、SOAコンポジット・アプリケーションおよびSOAインフラストラクチャのペイロード検証レベルの設定に依存しません。ペイロード検証がサービス・エンジンとSOAインフラストラクチャ・レベルの両方で有効化されている場合、データは2回チェックされます。1回はSOAインフラストラクチャに入力されたとき、もう1回はサービス・エンジンに入力されたときです。

    BPELモニターおよびセンサーの無効化

    デプロイ済のすべてのSOAコンポジット・アプリケーションのすべてのBPELコンポーネントに定義されているすべてのBPELモニターおよびセンサーを無効にするには、このチェック・ボックスを選択します。

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

  4. システムMBeanブラウザで拡張BPELプロパティを構成するには、「詳細BPEL構成プロパティ」をクリックします。表示されるプロパティの一部を次に示します。各プロパティには説明が記載されています。

  5. 使用環境に適した変更を行います。

Oracle BPELプロセスのチューニングとパフォーマンス・パラメータの詳細は、パフォーマンスのチューニングを参照してください。

Oracle BPEL Process Managerの自動リカバリの構成

Oracle SOA Suiteには、Oracle Enterprise Manager Fusion Middleware Controlの自動リカバリ機能が備えられており、この機能を使用して、次のものを構成およびリカバリでます。

  • 関連付けられた有効期限を持ち、再スケジュールされるSOAインフラストラクチャでスケジュールされる、すべてのアクティビティ(waitアクティビティやpickアクティビティのOnAlarmブランチなど)

  • 指定されたしきい値の時間内に完了しないすべてのアクティビティ

  • 未解決のすべての起動メッセージおよびコールバック・メッセージ

自動リカバリを構成するには:

  1. ナビゲータで、「soa-infra」を右クリックし、「SOA管理」→「BPELプロパティ」の順に選択します。
  2. 「詳細BPEL構成プロパティ」をクリックします。
  3. 「名前」列で「RecoveryConfig」をクリックします。
  4. 「RecurringScheduleConfig」を展開します。

    このセクションでは、繰返しのリカバリ試行を構成できます。

  5. 次のプロパティを環境に適した値に設定し、「適用」をクリックします。
    プロパティ 説明

    maxMessageRaiseSize

    繰り返されるリカバリ試行ごとに送信するメッセージの最大数。サーバーに対するリカバリの影響を制限するには、このプロパティを使用します。この値は、アクティビティ、起動およびコールバックの問合せからフィルタするメッセージの最大数を指定するもので、つまり、アクティビティ表、呼出し表およびコールバック表のそれぞれからの50メッセージです。

    デフォルト値は50です。0の値の場合は、データベースからメッセージが選択されません(実質的にリカバリが無効になります)。

    警告: 負の値を指定すると、データベースから選択されたすべてのメッセージがリカバリのために送信されます。この値は、システムを過負荷状態にする可能性があります。この値を指定しないでください。

    startWindowTime

    日次リカバリ・ウィンドウの開始時刻であり、24時間の表記法で指定します。したがって、午後2:00は14:00と指定します。時間が1桁の値の場合、先頭のゼロを指定する必要はありません(1:00-9:00)。

    デフォルト値は午前0時(00:00)です。解析された時刻が無効な値の場合、デフォルトで午前0時に設定されます。

    stopWindowTime

    日次リカバリ・ウィンドウの停止時刻であり、24時間の表記法で指定されます。したがって、午後2:00は14:00と指定します。時間が1桁の値の場合、先頭のゼロを指定する必要はありません(1:00-9:00)。

    日次リカバリを行わない場合、開始ウィンドウ時刻と停止ウィンドウ時刻を同じ値に設定します。停止ウィンドウ時刻が開始ウィンドウ時刻よりも前である場合は、開始ウィンドウ時刻と停止ウィンドウ時刻の両方が、それぞれのデフォルト値に変更されます。

    デフォルト値は(04:00)であり、実質的に、繰返しリカバリが04:00まで実行されるように設定されます。

    解析された時刻が無効な値である場合は、デフォルトで00:00に設定されます。

    subsequentTriggerDelay

    日次の繰返し起動リカバリ期間内での、リカバリ試行間の秒数。次のリカバリ・トリガーが現在のリカバリ期間の外になる場合、そのトリガーは次の繰返しリカバリ期間(翌日)までスケジュールされません。

    デフォルト値は300です(5分)。負の値の場合はデフォルトが選択されます。

    threshHoldTimeInMinutes

    これは自動リカバリ処理を無視する分単位のしきい値の時間です。自動的な起動およびコールバック・リカバリの場合、この値は受信日付がしきい値の時間よりも小さいメッセージを選出するために使用されます。

    自動アクティビティ・リカバリでは、この値を使用して、しきい値の時間に到達していない変更日付を持つアクティビティを選択します。

    このプロパティによって、BPELプロセス・サービス・エンジンがリカバリ目的でメッセージを選択するとき、サービス・エンジンの別のスレッドがそのメッセージを処理しているというメッセージ競合のシナリオを回避します。このプロパティによって、サービス・エンジンのリカバリ部分は、threshHoldTimeInMinutesの値よりも古いメッセージについてリカバリを試行するようになります。

    デフォルト値は10分です。負の値の場合はデフォルトが選択されます。

  6. 「StartupScheduleConfig」を展開します。

    このセクションでは、サーバー起動リカバリ試行を構成できます。

  7. 次のプロパティを環境に適した値に設定し、「適用」をクリックします。
    プロパティ 説明

    maxMessageRaiseSize

    起動リカバリ試行ごとに送信するメッセージの最大数。サーバーに対するリカバリの影響を制限するには、このプロパティを使用します。この値は、アクティビティ、起動およびコールバックの問合せからフィルタするメッセージの最大数を指定するもので、つまり、アクティビティ表、呼出し表およびコールバック表のそれぞれからの50メッセージです。

    デフォルト値は50です。負の値に設定すると、データベースから選択されたすべてのメッセージがリカバリのために送信されます。ゼロの値の場合、データベースからメッセージが選択されません(実質的にリカバリが無効になります)。

    startupRecoveryDuration

    起動リカバリ期間が継続する秒数を指定します。サーバーが開始した後、起動リカバリ期間に入ります。この期間中、保留中のアクティビティと未配信のコールバック・メッセージおよび起動メッセージは処理のため再発行されます。

    デフォルト値は600です(10分)。負またはゼロの値の場合は起動リカバリが無効になります。

    subsequentTriggerDelay

    サーバー起動リカバリ期間内でのリカバリ試行間の秒数。次のリカバリ・トリガーがサーバー起動期間の外になる場合、そのトリガーはスケジュールされず、サーバーは繰返しリカバリ期間に移行します。

    デフォルト値は300です(5分)。負の値の場合はデフォルトが選択されます。

ノート:

クラスタ内では、別々のノードが同じ項目の自動リカバリを同時に試行する場合があります。最初のノードが項目をロックしてリカバリを試行し、別のノードは安全に無視できる例外を発生させることができます。

マスター・ノード・リカバリ・スケジューリングの構成

マスター・ノード・リカバリ・スケジューリングを使用するようにクラスタ環境を構成できます。この環境では、マスター・ノードは、クラスタ内のすべてのノードに対してリカバリを実行するための専用ノードです。

ノート:

この機能は、Oracle Fusion Middlewareリリース11g (11.1.1.3)より前のデータベース・スキーマを使用している場合は動作しません。

マスター・ノード・リカバリ・スケジューリングを使用すると、次のタスクを実行できます。

  • 期限を過ぎた、有効期限が指定されているアクティビティ(waitアクティビティやpickアクティビティのOnAlarmブランチなど)のリカバリを実行できます。マスター・ノードは、期限切れの作業アイテムを取得し、再スケジュールします。

  • 残されている作業アイテムのリカバリ

  • コールバック・メッセージのリカバリ

  • 起動メッセージのリカバリ

  • 期限切れアクティビティのフェイルオーバーを実行でき、マスター・ノードは失敗したノードを検出すると、有効期限が指定された作業アイテムを再スケジュールしようとします。

マスター・ノード・リカバリ・スケジューリングを構成するには:

  1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。
  2. 「soa-infra」を右クリックします。
  3. 「SOA管理」→「BPELプロパティ」の順に選択します。
  4. 「詳細BPEL構成プロパティ」をクリックします。
  5. 「名前」列で「RecoveryConfig」をクリックします。
  6. 「ClusterConfig」を展開します。ClusterConfigプロパティは、RecurringScheduleConfigとStartupScheduleConfigにそれぞれ設定した繰り返しのリカバリ試行プロパティおよびサーバー起動リカバリ試行プロパティと関連して機能します。
  7. 次のプロパティを環境に適した値に設定し、「適用」をクリックします。

    ノート:

    インスタンスまたはメッセージがリカバリ可能になると、リカバリが試行されます。ただし、試行回数は追跡されません。リカバリが失敗すると、同じレコードを取得して試行し、再度失敗することを続けます。

    プロパティ 説明

    clusterDbTimeRefresh

    データベース時間のローカル・コピーをリフレッシュする頻度を指定します。別のコンピュータでのクロック・ドリフトが考慮されます。クラスタ内のすべてのノードは、正確さに関係なく、データベース時間に依存しています。

    デフォルト値は12時間(43200秒と指定)です。

    heartBeatInterval

    クラスタ内の他のノードによって公開されたメッセージを確認するために、ノードがクラスタ・メッセージ表をポーリングする頻度を指定します。

    デフォルト値は5秒です。

    次のタスクが各間隔で実行されます。

    • cluster_node表のノードの最終更新時間を更新します。

    • マスター・ロールの所有権の要求を試行します。

    • マスター・ロールが要求された場合、リカバリ・マネージャは作業を再開します。

    • nodeReapThreshold値の間に更新時間が更新されていないすべてのノードを確認し、cluster_node表からそれらのノードを削除し、このノードのすべての期限切れ作業アイテムを再スケジュールします。

    masteAliveThreshold

    マスター・ノードがアクティブと見なされる秒数を指定します。この秒数の間にクラスタにチェックインしていないマスター・ノードは、終了されたと見なされます。cluster_master表で排他ロックを取得するノードはどれでも、この時点からマスター・ロールを要求できます。

    デフォルト値は15分(900秒と指定)です。

    nodeReapInterval

    古いクラスタ・ノードとマークするためにハートビート・スレッドを流用する頻度を指定します。マスター・ノードのみがこのジョブを実行します。

    デフォルト値は2時間(7200秒と指定)です。

    nodeReapThreshold

    ノードがアクティブと見なされる秒数を指定します。この秒数の間にクラスタにチェックインしていないノードは、終了されたと見なされます。ハートビート・サイクル中に、マスター・ノードはcluster_node表をクリーン・アップしようとします。

    デフォルト値は15分(900秒と指定)です。

起動メッセージおよびコールバック・メッセージの自動リカバリ試行の構成

リカバリ可能な同じインスタンス内で発行する自動リカバリ試行の数を構成できます。入力した値によって、起動メッセージおよびコールバック・メッセージがリカバリされる最大回数が指定されます。値が2 (デフォルト値)の場合、各リカバリ可能メッセージのリカバリが2回試行されます。1つのメッセージに対するリカバリ試行の数が、指定された値を超過すると、そのメッセージにはリカバリ不能のマークが付けられます。

起動メッセージおよびコールバック・メッセージの自動リカバリ試行を構成するには:

  1. ナビゲータで、「soa-infra」を右クリックし、「SOA管理」→「BPELプロパティ」の順に選択します。
  2. 「詳細BPEL構成プロパティ」をクリックします。
  3. 「MaxRecoverAttempt」に移動します。
  4. 「値」フィールドに値を入力します。

    MaxRecoverAttemptを設定した場合の起動メッセージとコールバック・メッセージのリカバリ動作は異なります。たとえば、「MaxRecoverAttempt」を4に設定した場合は次のようになります。

    • 起動メッセージ・リカバリは、4 (N)回再試行されてから、消耗済状態にメッセージが移動されます。

    • コールバック・メッセージ・リカバリは、5回(N + 1)再試行されてから、消耗済状態にメッセージが移動されます。

    これは予想された動作です。最初の試行はリカバリ試行とはみなされません。リカバリ試行はBPELプロセス・サービス・エンジンによって増分されます。MaxRecoverAttemptが1に設定されている場合は、デフォルトの解決プロセスが1回実行された後で、リカバリ試行が1回実行されます。

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

起動メッセージおよびコールバック・メッセージのリカバリの詳細は、「BPELプロセス・サービス・エンジンのメッセージ・リカバリの実行」を参照してください。

コールバック・メッセージの順序の保持

システムMBeanブラウザで「ExecuteCallbacksInOrder」プロパティをtrueに設定することで、BPELプロセスのコールバック・メッセージの順番を保持して、確実に正しい順番でBPELプロセス・インスタンスに配信されるようにできます。ExecuteCallbacksInOrderは、所定のビジネス・フロー・インスタンスについてBPELプロセス・サービス・エンジンによって受信された順番でコールバックが取得されるようにできます。この設定は、BPELプロセス・サービス・エンジンにデプロイされているすべてのSOAコンポジット・アプリケーションに影響を与えます。

ExecuteCallbacksInOrderプロパティへのアクセスと構成の詳細は、「BPELプロセス・サービス・エンジン・プロパティの構成」を参照してください。

BPELプロセス・サービス・コンポーネント・レベルでの監査レベルの設定

BPELプロセス・サービス・コンポーネントには監査レベルを設定できます。この設定は、SOAインフラストラクチャ、サービス・エンジン、SOAコンポジット・アプリケーションの各レベルの監査レベル設定より優先されます。サービス・コンポーネント・レベル設定はBPELプロセスについてのみ使用可能であり、Oracle Mediator、ヒューマン・ワークフローおよびビジネス・ルール・サービス・コンポーネントについてはサポートされていません。

BPELプロセス・サービス・コンポーネントの監査レベルを設定する方法は2つあります。サポートされる値は、「オフ」、「最小」、「継承」、「開発」および「本番」です。

BPELプロセス・サービス・コンポーネントに監査レベルを設定するには:

  • Oracle Enterprise Manager Fusion Middleware Controlの「システムMBeanブラウザ」で、次の手順を実行します。

    1. ナビゲーション・ツリーで「SOA」フォルダを開きます。

    2. 「soa-infra」を右クリックして、「管理」→「システムMBeanブラウザ」の順に選択します。

    3. 「アプリケーション定義のMBean」→「oracle.soa.config」→「「サーバー: server_name」→「SCAComposite」→「Composite_Name」→「SCAComposite.SCAComponent」→「BPEL_Service_Component」→「プロパティ」の順に選択します。

    4. 「追加」アイコンをクリックします。

    5. 「Element_number」フォルダを開きます。

    6. 複数リストから、「False」を選択します。

    7. 「名前」フィールドに、bpel.config.auditlevelと入力します。

    8. 「値」フィールドに値を入力します。

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

  • Oracle JDeveloperで、次のようにします。

    bpel.config.auditLevelプロパティに、SOAプロジェクトのcomposite.xmlファイル内の該当する値を設定します。 

    <component name="BPELProcess"> 
   <implementation.bpel src="BPELProcess.bpel" /> 
   <property name="bpel.config.auditLevel">Off</property> 
</component>

監査レベルの詳細は、「監査レベル設定の優先順位の概要」を参照してください。

高負荷データベース環境でのスタック・スレッドの回避

データベース・サーバーがビジー状態の場合や、CPU使用率が非常に高い場合など、データベースが高負荷になる場合は、Oracle SOA Suiteの制御外で、トランザクションがソケット・レベルでスタックすることのないSQL問合せを選択します。

Oracleでは、SOADataSourceおよびSOALocalDataSourceデータ・ソースに文タイムアウトを含めることをお薦めします。これにより、Oracle SOA Suiteの制御外で発生する長時間の実行やスタックしたSQL問合せを原因とするスタック・スレッドを回避できます。このアクションはOracle SOA Suiteに役立ち、

スタック・スレッドの増加を回避できます。これは、高負荷データベース環境でOracle SOA Suiteのパフォーマンスが低下する原因となります。

この場合、「文タイムアウト」に、JTAタイムアウト値より大きく、スタック・スレッドのタイムアウト値よりわずかに小さい値を設定し、スタック・スレッド発生の可能性を低減してください。

推奨値: JTA timeout < Statement timeoutかつStatement timeout < Stuck thread timeout (ただし、Stuck thread timeoutに近く、JTA timeoutとは大きく異なる値)。

次の理由で、この範囲をお薦めします:

  • すべてのスレッドがJTAトランザクション境界内の場合、影響はありません。

  • 長時間実行中のSQL問合せは、スタック・スレッドとしてマークされる直前に終了します。

文タイムアウトの設定の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の文タイムアウトによる文の処理時間の制限に関する項を参照してください。