監査証跡しきい値(バイト) |
監査証跡とは別にチャンクされてデハイドレーション・ストア表に保存される前の、インスタンスの監査証跡の最大サイズをバイト単位で入力します。 このしきい値を超えると、ペイロードのかわりに、「XMLの表示」リンクが監査証跡に表示されます。 |
大容量のドキュメントしきい値(バイト) |
デハイドレーション・ストアの別の表に保存される前の、BPELプロセス・コンポーネント・インスタンス内に生成されるドキュメントの最大サイズを入力します。 |
ディスパッチャ・システム・スレッド |
システム・ディスパッチャ・メッセージの処理に割り当てるスレッド合計数を指定します。 システム・ディスパッチャ・メッセージは、通常、サーバーによって迅速に処理される一般的なクリーン・アップ・タスク(ステートフル・メッセージBeanの元のプールへの解放など)です。 通常、実行時に生成されたシステム・ディスパッチャ・メッセージの数を処理するために必要なスレッド数はごく少数です。
デフォルト値は2 スレッドです。 1 スレッド未満の値は、デフォルト値に変更されます。
|
ディスパッチャ呼出しスレッド |
呼出しディスパッチャ・メッセージの処理に割り当てるスレッド合計数を指定します。 呼出しディスパッチャ・メッセージは、受信したペイロードごとに生成され、新規インスタンスをインスタンス化するために使用されます。 エンジンで処理されるリクエストの大多数が(インスタンス・コールバックではなく)インスタンス呼出しである場合は、呼出しスレッド数を増加させることでパフォーマンスが大幅に向上する可能性があります。 スレッド数が多くなるほど、コンテキスト切替えコストが高くなるため、CPU使用率が大幅に増加する可能性があります。
デフォルト値は20 スレッドです。 1 スレッド未満の値は、デフォルト値に変更されます。
|
ディスパッチャ・エンジン・スレッド |
エンジン・ディスパッチャ・メッセージの処理に割り当てるスレッド合計数を指定します。 エンジン・ディスパッチャ・メッセージは、アクティビティを非同期で処理する必要がある場合に必ず生成されます。 デプロイされるプロセスの大多数が永続的で、多数のデハイドレーション・ポイント(midprocess receive、onMessage、onAlarmおよびwaitアクティビティ)がある場合は、エンジン・スレッド数を増加させることでパフォーマンスが大幅に向上する可能性があります。 スレッド数が多くなるほど、コンテキスト切替えコストが高くなるため、CPU使用率が大幅に増加する可能性があることに注意してください。
デフォルト値は30 スレッドです。 1 スレッド未満の値は、デフォルト値に変更されます。
|
ペイロードの検証 |
インバウンド・メッセージとアウトバウンド・メッセージの検証を有効にする場合に選択します。 スキーマに準拠しないペイロード・データが捕捉され、フォルトとして表示されます。
注意: この設定は、SOAコンポジット・アプリケーションおよびSOAインフラストラクチャのペイロード検証レベルの設定に依存しません。 ペイロード検証がサービス・エンジンとSOAインフラストラクチャの両レベルで有効な場合、データは2回チェックされます。1回目は、データがSOAインフラストラクチャに入るとき、2回目は、データがサービス・エンジンに入るときです。
|
監査レベル |
次のいずれかのオプションを選択します。
-
オフ: コンポジット・インスタンスのトラッキング情報とペイロード・トラッキング情報は収集されません。
-
継承: ロギング・レベルは、SOAインフラストラクチャの監査レベルと同じです。 この設定を使用すると、グローバル設定が変更されたときに、BPEL監査レベルも自動的に変更できます。 このページで別の監査レベル・トラッキングを設定すると、SOAインフラストラクチャ・レベルで設定したトラッキングが上書きされます。
-
最小: BPELサービス・エンジンでは、監査詳細がキャプチャされません。 したがって、フローの監査証跡で監査詳細は使用できません。 他のすべてのイベントは記録されます。
-
本番: BPELサービス・エンジンでは、ペイロードがキャプチャされません。 フローの監査証跡でペイロード詳細は使用できません。 他のBPELアクティビティのペイロード詳細は、assignアクティビティを除いて収集されます。 このレベルは、通常の操作とテストに最適です。
-
開発: コンポジット・インスタンスのトラッキングとペイロード・トラッキングの両方を実行できます。 すべてのイベントが記録されます。 ただし、パフォーマンスに影響を与える可能性があります。 このレベルは通常、デバッグする際に便利です。
|