BPELプロセスのサービス・コンポーネントとエンジンの構成この章では、BPELプロセス・サービス・コンポーネントとサービス・エンジンの構成方法(監査レベル、監査証跡しきい値、ディスパッチャ・スレッド値などのプロパティ、BPELプロセスの自動リカバリ、マスター・ノード・リカバリ・スケジューリング、起動メッセージとコールバック・メッセージの自動リカバリ試行、およびコールバック・メッセージの順序の保持の構成を含む)について説明します。この章では、次の項目について説明します。Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。BPELプロセス・サービス・エンジン・プロパティの構成BPELプロセス・サービス・エンジン・プロパティを構成でき、このプロパティは、BPELプロセス・サービス・コンポーネントの処理時に、BPELプロセス・サービス・エンジンで使用されます。BPELプロセス・サービス・エンジン・プロパティを構成する手順は、次のとおりです。次のいずれかのオプションを使用して、このページにアクセスします。SOAインフラストラクチャのメニューから...ナビゲータのSOAフォルダから...「SOA管理」→「BPELプロパティ」の順に選択します。「soa-infra」を右クリックします。「SOA管理」→「BPELプロパティ」の順に選択します。「BPELサービス・エンジン・プロパティ」ページに、監査証跡しきい値と大容量ドキュメントしきい値の設定、ディスパッチャ・スレッド・プロパティの設定、ペイロード・スキーマの検証、および監査証跡レベルの設定を行うためのプロパティが表示されます。使用環境に適するようにサービス・エンジン・プロパティを変更します。監査レベル次のいずれかのオプションを選択します。コンポジット・インスタンスのトラッキング情報とペイロード・トラッキング情報は収集されません。ロギング・レベルは、SOAインフラストラクチャの監査レベルと同じです。この設定を使用すると、グローバル設定が変更されたときに、BPELプロセスの監査レベルも自動的に変更できます。このページで別の監査レベル・トラッキングを設定すると、SOAインフラストラクチャ・レベルで設定したトラッキングがオーバーライドされます。BPELプロセス・サービス・エンジンでは、監査詳細がキャプチャされません。したがって、フローの監査証跡で監査詳細は使用できません。他のすべてのイベントは記録されます。BPELプロセス・サービス・エンジンでは、ペイロードがキャプチャされません。フローの監査証跡でペイロード詳細は使用できません。他のBPELアクティビティのペイロード詳細は、assignアクティビティを除いて収集されます。このレベルは、標準の操作とテストに最適です。コンポジット・インスタンスのトラッキングとペイロード・トラッキングの両方を実行できます。すべてのイベントが記録されます。パフォーマンスに影響を与える可能性があります。このレベルは通常、デバッグする際に便利です。監査証跡しきい値(バイト)監査証跡とは別にチャンクされてデハイドレーション・ストア表に保存される前の、インスタンスの監査証跡の最大サイズをバイト単位で入力します。このしきい値を超えると、ペイロードのかわりに、「XMLの表示」リンクが監査証跡に表示されます。大容量のドキュメントしきい値(バイト)デハイドレーション・ストアの別の表に保存される前の、BPELプロセス・コンポーネント・インスタンス内に生成されるドキュメントの最大サイズを入力します。ディスパッチャ・システム・スレッドシステム・ディスパッチャ・メッセージの処理に割り当てるスレッドの合計数を指定します。システム・ディスパッチ・メッセージは、通常、サーバーにより迅速に処理される一般的なクリーン・アップ・タスクです(たとえば、ステートフル・メッセージBeanを元のプールに解放)。通常、実行時に生成されたシステム・ディスパッチ・メッセージの数を処理するために必要なスレッド数はごく少数です。デフォルト値は2スレッドです。1スレッド未満の値は、デフォルト値に変更されます。これらのスレッドの監視の詳細は、第14.6項「BPELプロセス・サービス・エンジンのリクエスト統計とスレッド・パフォーマンス統計の監視」を参照してください。ディスパッチャ呼出しスレッド呼出しディスパッチャ・メッセージの処理に割り当てるスレッド合計数を指定します。呼出しディスパッチャ・メッセージは、受信したペイロードごとに生成され、新規インスタンスをインスタンス化するために使用されます。サービス・エンジンで処理されるリクエストの大多数が(インスタンス・コールバックではなく)インスタンス呼出しである場合は、呼出しスレッド数を増加させることでパフォーマンスが大幅に向上する可能性があります。スレッド数が多くなるほど、コンテキスト切替えコストが高くなるため、CPU使用率が大幅に増加する可能性があります。デフォルト値は20スレッドです。1スレッド未満の値は、デフォルト値に変更されます。これらのスレッドの監視の詳細は、第14.6項「BPELプロセス・サービス・エンジンのリクエスト統計とスレッド・パフォーマンス統計の監視」を参照してください。ディスパッチャ・エンジン・スレッドエンジン・ディスパッチャ・メッセージの処理に割り当てるスレッド合計数を指定します。エンジン・ディスパッチャ・メッセージは、アクティビティを非同期で処理する必要がある場合に必ず生成されます。receive、onMessage、onAlarmおよびwaitアクティビティ)がある場合は、ディスパッチャ・エンジン・スレッド数を増加させることでパフォーマンスが大幅に向上する可能性があります。スレッド数が多くなるほど、コンテキスト切替えコストが高くなるため、CPU使用率が大幅に増加する可能性があります。デフォルト値は30スレッドです。1スレッド未満の値は、デフォルト値に変更されます。これらのスレッドの監視の詳細は、第14.6項「BPELプロセス・サービス・エンジンのリクエスト統計とスレッド・パフォーマンス統計の監視」を参照してください。ペイロードの検証インバウンド・メッセージとアウトバウンド・メッセージの検証を有効にする場合に選択します。スキーマに準拠しないペイロード・データが捕捉され、フォルトとして表示されます。この設定は、SOAコンポジット・アプリケーションおよびSOAインフラストラクチャのペイロード検証レベルの設定に依存しません。ペイロード検証がサービス・エンジンとSOAインフラストラクチャの両レベルで有効な場合、データは2回チェックされます。1回目は、データがSOAインフラストラクチャに入るとき、2回目は、データがサービス・エンジンに入るときです。BPELモニターおよびセンサーの無効化デプロイ済のすべてのSOAコンポジット・アプリケーションのすべてのBPELコンポーネントに定義されているすべてのBPELモニターおよびセンサーを無効にするには、このチェック・ボックスを選択します。「適用」をクリックします。システムMBeanブラウザで拡張BPELプロパティを構成するには、「詳細BPEL構成プロパティ」をクリックします。表示されるプロパティの一部を次に示します。各プロパティには説明が記載されています。Exalogicプラットフォームで、(複数のインスタンスの)複数の監査証跡メッセージを単一トランザクションに格納します。Coherence分散キャッシュへの格納」を参照してください。BPELで生成されたJavaソースをコンパイルするときに含める追加BPELクラスのパス。Suite開発者ガイド』のカスタム・クラスとJARファイルの追加方法に関する項を参照してください。BPELでアサーションの実行を無効化します(bpelx:assertアクティビティを含む)。Suite開発者ガイド』のアサーションの無効化方法に関する項を参照してください。センサーへのすべての呼出しを無効にします。非ブロッキング呼出しディスパッチャ・メッセージの処理に割り当てるスレッドの合計数。システムに多数の非ブロッキング呼出しがある場合は、このプロパティの値を増分できます。デフォルト値は2です。1未満の値は、自動的にデフォルト値に変更されます。BPELプロセス・サービス・エンジン内にコールバックの受信時間の順番にBPELプロセス・コールバックを保持します(trueに設定されている場合)。詳細は、第13.5項「コールバック・メッセージの順序の保持」を参照してください。失敗した期限切れ呼出し(wait/onAlarm)が失敗するまでに再試行される最大回数。次の期限切れ呼出しの再試行までの遅延。1回のフェッチごとにデハイドレーション・ストアから割り当てられるインスタンスIDのブロック・サイズ。メモリー内キャッシュに格納される起動メッセージ数。同一のリカバリ可能なインスタンスに発行する自動リカバリ試行の数。詳細は、第13.4項「起動メッセージおよびコールバック・メッセージの自動リカバリ試行の構成」と第15.5.4項「複数の監査証跡メッセージの単一トランザクションへの格納の構成」を参照してください。BPELプロセスがデハイドレーションに関連して実際に待機する最小期間。Suite開発者ガイド』の有効期限を設定する待機アクティビティの作成に関する項を参照してください。一方向呼出しメッセージを配信するかどうかを変更します。Coherenceのキャッシュを有効または無効にします。Coherenceのキャッシュ機能の構成」を参照してください。アクティビティの自動リカバリを構成し、マスター・ノード・リカバリ・スケジューリングを使用するようにクラスタ環境を構成します。Managerの自動リカバリの構成」と第13.3項「マスター・ノード・リカバリ・スケジューリングの構成」を参照してください。最近処理されたリクエスト・リストのサイズ。この値を1000などの値に変更してください。これによって、「統計」ページで下位レベルの統計を表示できます。詳細は、第14.6項「BPELプロセス・サービス・エンジンのリクエスト統計とスレッド・パフォーマンス統計の監視」を参照してください。タイムアウトする前に実行されるリクエスト操作およびレスポンス操作の最大回数。Suite開発者ガイド』の永続同期プロセスのトランザクション・タイムアウト値の指定に関する項を参照してください。使用環境に適した変更を行います。Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。Controlの自動リカバリ機能が備えられており、この機能を使用して、次のものを構成およびリカバリでます。関連付けられた有効期限を持ち、再スケジュールされるSOAインフラストラクチャでスケジュールされる、すべてのアクティビティ(waitアクティビティやpickアクティビティのOnAlarmブランチなど)指定されたしきい値の時間内に完了しないすべてのアクティビティ未解決のすべての起動メッセージおよびコールバック・メッセージ自動リカバリを構成するには、次の手順を実行します。ナビゲータで、「soa-infra」を右クリックし、「SOA管理」→「BPELプロパティ」の順に選択します。「詳細BPEL構成プロパティ」をクリックします。「名前」列で「RecoveryConfig」をクリックします。RecurringScheduleConfigを展開します。このセクションでは、繰返しのリカバリ試行を構成できます。次のプロパティを環境に適した値に設定し、「適用」をクリックします。プロパティ説明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)。日次リカバリを行わない場合、開始ウィンドウ時刻と停止ウィンドウ時刻を同じ値に設定します。停止ウィンドウ時刻が開始ウィンドウ時刻よりも前である場合は、開始ウィンドウ時刻と停止ウィンドウ時刻の両方が、それぞれのデフォルト値に変更されます。デフォルト値は午前0時(04:00)であり、実質的に、繰返しリカバリが04:00まで実行されるように設定されます。解析された時刻が無効な値である場合は、デフォルトで00:00に設定されます。subsequentTriggerDelay日次の繰返し起動リカバリ期間内での、リカバリ試行間の秒数。次のリカバリ・トリガーが現在のリカバリ期間の外になる場合、そのトリガーは次の繰返しリカバリ期間(翌日)までスケジュールされません。デフォルト値は300です(5分)。負の値の場合はデフォルトが選択されます。threshHoldTimeInMinutesこれは自動リカバリ処理を無視する分単位のしきい値の時間です。自動的な起動およびコールバック・リカバリの場合、この値は受信日付がしきい値の時間よりも小さいメッセージを選出するために使用されます。自動アクティビティ・リカバリの場合、この値は修正日付がしきい値の時間よりも小さいアクティビティを選出するために使用されます。このプロパティによって、BPELプロセス・サービス・エンジンがリカバリ目的でメッセージを選択するとき、サービス・エンジンの別のスレッドがそのメッセージを処理しているというメッセージ競合のシナリオを回避します。このプロパティによって、サービス・エンジンのリカバリ部分は、threshHoldTimeInMinutesの値よりも古いメッセージについてリカバリを試行するようになります。デフォルト値は10分です。負の値の場合はデフォルトが選択されます。「StartupScheduleConfig」を展開します。このセクションでは、サーバー起動リカバリ試行を構成できます。次のプロパティを環境に適した値に設定し、「適用」をクリックします。プロパティ説明maxMessageRaiseSize起動リカバリ試行ごとに送信するメッセージの最大数。サーバーに対するリカバリの影響を制限するには、このプロパティを使用します。この値は、アクティビティ、起動およびコールバックの問合せからフィルタするメッセージの最大数を指定するもので、つまり、アクティビティ表、呼出し表およびコールバック表のそれぞれからの50メッセージです。デフォルト値は50です。負の値に設定すると、データベースから選択されたすべてのメッセージがリカバリのために送信されます。ゼロの値の場合、データベースからメッセージが選択されません(実質的にリカバリが無効になります)。startupRecoveryDuration起動リカバリ期間が継続する秒数を指定します。サーバーが開始した後、起動リカバリ期間に入ります。この期間中、保留中のアクティビティと未配信のコールバック・メッセージおよび起動メッセージは処理のため再発行されます。デフォルト値は600です(10分)。負またはゼロの値の場合は起動リカバリが無効になります。subsequentTriggerDelayサーバー起動リカバリ期間内でのリカバリ試行間の秒数。次のリカバリ・トリガーがサーバー起動期間の外になる場合、そのトリガーはスケジュールされず、サーバーは繰返しリカバリ期間に移行します。デフォルト値は300です(5分)。負の値の場合はデフォルトが選択されます。注意:クラスタ内では、別々のノードが同じ項目の自動リカバリを同時に試行する場合があります。最初のノードが項目をロックしてリカバリを試行し、別のノードは安全に無視できる例外を発生させることができます。マスター・ノード・リカバリ・スケジューリングの構成マスター・ノード・リカバリ・スケジューリングを使用するようにクラスタ環境を構成できます。この環境では、マスター・ノードは、クラスタ内のすべてのノードに対してリカバリを実行するための専用ノードです。(11.1.1.3)より前のデータベース・スキーマを使用している場合は動作しません。マスター・ノード・リカバリ・スケジューリングを使用すると、次のタスクを実行できます。期限を過ぎた、有効期限が指定されているアクティビティ(waitアクティビティやpickアクティビティのOnAlarmブランチなど)のリカバリを実行できます。マスター・ノードは、期限切れの作業アイテムを取得し、再スケジュールします。残されている作業アイテムのリカバリコールバック・メッセージのリカバリ起動メッセージのリカバリ期限切れアクティビティのフェイルオーバーを実行でき、マスター・ノードは失敗したノードを検出すると、有効期限が指定された作業アイテムを再スケジュールしようとします。マスター・ノード・リカバリ・スケジューリングを構成する手順は、次のとおりです。Controlにログインします。「soa-infra」を右クリックします。「SOA管理」→「BPELプロパティ」の順に選択します。「詳細BPEL構成プロパティ」をクリックします。「名前」列で「RecoveryConfig」をクリックします。ClusterConfigを開きます。ClusterConfigプロパティは、RecurringScheduleConfigとStartupScheduleConfigにそれぞれ設定した繰り返しのリカバリ試行プロパティおよびサーバー起動リカバリ試行プロパティと関連して機能します。次のプロパティを環境に適した値に設定し、「適用」をクリックします。注意:インスタンスまたはメッセージがリカバリ可能になると、リカバリが試行されます。試行回数は追跡されません。リカバリが失敗すると、同じレコードを取得して試行し、再度失敗することを続けます。プロパティ説明clusterDbTimeRefreshデータベース時間のローカル・コピーをリフレッシュする頻度を指定します。別のコンピュータでのクロック・ドリフトが考慮されます。クラスタ内のすべてのノードは、正確さに関係なく、データベース時間に依存しています。デフォルト値は12時間(43200秒と指定)です。heartBeatIntervalクラスタ内の他のノードによって公開されたメッセージを確認するために、ノードがクラスタ・メッセージ表をポーリングする頻度を指定します。デフォルト値は5秒です。次のタスクが各間隔で実行されます。cluster_node表のノードの最終更新時間を更新します。マスター・ロールの所有権の要求を試行します。マスター・ロールが要求された場合、リカバリ・マネージャは作業を再開します。nodeReapThreshold値の間に更新時間が更新されていないすべてのノードを確認し、cluster_node表からそれらのノードを削除し、このノードのすべての期限切れ作業アイテムを再スケジュールします。masteAliveThresholdマスター・ノードがアクティブと見なされる秒数を指定します。この秒数の間にクラスタにチェックインしていないマスター・ノードは、終了されたと見なされます。cluster_master表で排他ロックを取得するノードはどれでも、この時点からマスター・ロールを要求できます。デフォルト値は15分(900秒と指定)です。nodeReapInterval古いクラスタ・ノードとマークするためにハートビート・スレッドを流用する頻度を指定します。マスター・ノードのみがこのジョブを実行します。デフォルト値は2時間(7200秒と指定)です。nodeReapThresholdノードがアクティブと見なされる秒数を指定します。この秒数の間にクラスタにチェックインしていないノードは、終了されたと見なされます。ハートビート・サイクル中に、マスター・ノードはcluster_node表をクリーン・アップしようとします。デフォルト値は15分(900秒と指定)です。起動メッセージおよびコールバック・メッセージの自動リカバリ試行の構成リカバリ可能な同じインスタンス内で発行する自動リカバリ試行の数を構成できます。入力した値によって、起動メッセージおよびコールバック・メッセージがリカバリされる最大回数が指定されます。値が2(デフォルト値)の場合、すべてのメッセージがリカバリされます。1つのメッセージに対するリカバリ試行の数が、指定された値を超過すると、そのメッセージにはリカバリ不能のマークが付けられます。起動メッセージおよびコールバック・メッセージの自動リカバリ試行を構成するには、次の手順を実行します。ナビゲータで、「soa-infra」を右クリックし、「SOA管理」→「BPELプロパティ」の順に選択します。「詳細BPEL構成プロパティ」をクリックします。「MaxRecoverAttempt」に移動します。「値」フィールドに値を入力します。MaxRecoverAttemptを設定した場合の起動メッセージとコールバック・メッセージのリカバリ動作は異なります。「MaxRecoverAttempt」を4に設定した場合は次のようになります。(N)回再試行されてから、消耗済状態にメッセージが移動されます。1)再試行されてから、消耗済状態にメッセージが移動されます。これは予想された動作です。最初の試行はリカバリ試行とはみなされません。リカバリ試行はBPELプロセス・サービス・エンジンによって増分されます。MaxRecoverAttemptが1に設定されている場合は、デフォルトの解決プロセスが1回実行された後で、リカバリ試行が1回実行されます。「適用」をクリックします。起動メッセージおよびコールバック・メッセージのリカバリの詳細は、第15.4項「BPELプロセス・サービス・エンジンのメッセージ・リカバリの実行」を参照してください。コールバック・メッセージの順序の保持システムMBeanブラウザで「ExecuteCallbacksInOrder」プロパティをtrueに設定することで、BPELプロセスのコールバック・メッセージの順番を保持して、確実に正しい順番でBPELプロセス・インスタンスに配信されるようにできます。ExecuteCallbacksInOrderは、所定のBPELプロセス・サービス・コンポーネント・インスタンスについてBPELプロセス・サービス・エンジンによって受信された順番でコールバックが配信されるようにできます。この設定は、BPELプロセス・サービス・エンジンにデプロイされているすべてのSOAコンポジット・アプリケーションに影響を与えます。ExecuteCallbacksInOrderプロパティへのアクセスと構成の詳細は、第13.1項「BPELプロセス・サービス・エンジン・プロパティの構成」を参照してください。BPELプロセス・サービス・コンポーネント・レベルでの監査レベルの設定BPELプロセス・サービス・コンポーネントには監査レベルを設定できます。この設定は、SOAインフラストラクチャ、サービス・エンジン、SOAコンポジット・アプリケーションの各レベルの監査レベル設定より優先されます。Mediator、ヒューマン・ワークフローおよびビジネス・ルール・サービス・コンポーネントについてはサポートされていません。BPELプロセス・サービス・コンポーネントの監査レベルを設定する方法は2つあります。BPELプロセス・サービス・コンポーネントに監査レベルを設定する手順は、次のとおりです。Controlの「システムMBeanブラウザ」で、次の手順を実行します。ナビゲーション・ツリーで「SOA」フォルダを開きます。「soa-infra」を右クリックして、「管理」→「システムMBeanブラウザ」の順に選択します。server_name」→「SCAComposite」→「Composite_Name」→「SCAComposite.SCAComponent」→「BPEL_Service_Component」→「プロパティ」の順に選択します。「追加」アイコンをクリックします。「Element_number」フォルダを開きます。複数リストから、「False」を選択します。「名前」フィールドに、bpel.config.auditlevelと入力します。「値」フィールドに値を入力します。「適用」をクリックします。JDeveloperを使用する場合bpel.config.auditLevelプロパティに、SOAプロジェクトのcomposite.xmlファイル内の該当する値を設定します。</component>監査レベルの詳細は、第1.4.1.1項「監査レベル設定の優先順位の概要」を参照してください。reserved.法律上の注意点ライブラリ。