13 Oracle BPEL Process Managerのパフォーマンス・チューニング

Oracle Business Process Execution Language(BPEL)Process Managerには、コンポジット、ファブリック、アプリケーション、サーバーの各レベルでパフォーマンスを最適化するために構成可能なプロパティ設定がいくつか用意されています。この章では、各プロパティ設定について説明し、プロパティ設定の使用方法に関する推奨事項を示します。

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

• 13.1項「BPEL Process Managerについて」

• 13.2項「チューニングに関する基本的な考慮事項」

• 13.3項「コンポジット内で設定するBPELプロパティ」

• 13.4項「インスタンス・データ増大の影響を受ける表」

13.1 BPEL Process Managerについて

BPELとは、一連の独立したサービスを集めてエンドツーエンドのプロセス・フローを組み立てるための標準です。BPELを使用すれば、プロセス統合の取組みのコストおよび複雑さを大幅に軽減できます。Oracle BPEL Process Managerは、BPELビジネス・プロセスの作成、デプロイおよび管理を目的とした、包括的で使いやすいインフラストラクチャを提供します。

詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「BPELプロセスのサービス・コンポーネントとエンジンの構成」と『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「BPELプロセス・サービス・コンポーネントの使用」を参照してください。

13.2 チューニングに関する基本的な考慮事項

この項では、BPELエンジン・レベルでのパフォーマンス・チューニング・プロパティについて説明します。これらのプロパティは、Oracle Enterprise Managerを使用して構成できます。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

注意: この章で説明する構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。

13.2.1 BPELスレッド・モデル

ディスパッチャは、実行するディスパッチャ・メッセージをスケジュールする際に、そのメッセージをスレッド・プールにエンキューすることができます。各ディスパッチャ・セットには、スレッド・プール(java.util.concurrent.ThreadPoolExecutor)が1つ含まれます。実装されたBPELスレッド・プールでは、メッセージがエンキューされるとスレッドに通知し、適切な数のスレッドがプール内でインスタンス化されるようにしています。

注意: dspMinThreads、dspMaxThreads、dspInvokeAllocRatioの各構成プロパティは、Oracle 11gでは推奨されていません。また、Oracle 11gでは呼出しスレッドが専用のプールを持つため、dspInvokeAllocRatioは不要になりました。

13.2.1.1 ディスパッチャ・システム・スレッド

dspSystemThreadsプロパティには、システム・ディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。システム・ディスパッチャ・メッセージとは、通常はサーバーで迅速に処理される一般的なクリーン・アップ・タスク(ステートフル・メッセージBeanを元のプールへ解放するなど)です。一般に、実行時に生成される数のシステム・ディスパッチャ・メッセージは、ごく少数のスレッドで処理できます。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は2です。1スレッド未満の値は、デフォルト値に変更されます。

13.2.1.2 ディスパッチャ呼出しスレッド

dspInvokeThreadsプロパティには、呼出しディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。呼出しディスパッチ・メッセージは、受信したペイロードごとに生成されるもので、新規インスタンスのインスタンス化を目的としています。エンジンによって処理されるリクエストの大部分が(インスタンス・コールバックではなく)インスタンス呼出しである場合は、呼出しスレッド数を増やすことでパフォーマンスを改善できる可能性があります。スレッド数が多くなると、コンテキスト切替えのコストが高くなるため、CPU使用率が増加する場合もあります。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は20スレッドです。1スレッド未満の値は、デフォルト値に変更されます。

13.2.1.3 ディスパッチャ・エンジン・スレッド

dspEngineThreadsプロパティには、エンジン・ディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。エンジン・ディスパッチャ・メッセージは、アクティビティを非同期に処理する必要がある場合に必ず生成されます。デプロイされたプロセスの大部分が永続的で、多数のデハイドレーション・ポイント(プロセス途中のreceive、onMessage、onAlarmおよびwaitアクティビティ)がある場合は、エンジン・スレッド数を増やすことでパフォーマンスを改善できる可能性があります。スレッド数が多くなると、コンテキスト切替えのコストが高くなるため、CPU使用率が増加する場合もありますので注意してください。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は30スレッドです。1スレッド未満の値は、デフォルト値に変更されます。

13.2.1.4 ディスパッチャ最大リクエスト深さ

dspMaxRequestDepthプロパティには、同じリクエストの中で処理するメモリー内アクティビティの最大数を設定します。Oracle BPEL Process Managerは、アクティビティ・リクエストを処理した後、リクエストの有効性を損わずに後続のアクティビティをできるだけ多く処理しようとします。連続したアクティビティ処理がこの深さに達すると、インスタンスはデハイドレーションされ、次のアクティビティが別のトランザクションで実行されます。

リクエストの深さが大きすぎると、合計リクエスト時間がアプリケーション・サーバーのトランザクション・タイムアウト制限を超えることがあります。このプロセスは、永続プロセスに適用されます。

デフォルト値は600アクティビティです。

注意: 各スレッド・プールの最小スレッド数は1です。dsp*Threadsを0や負の数に設定することはできません。

13.2.2 監査

次のプロパティには、監査レベルを設定できます。

13.2.2.1 AuditLevel

auditLevelプロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、永続プロセスと一時プロセスの両方に適用されます。このプロパティが制御するのは、プロセスによってログに記録される監査イベントの量です。監査イベントを記録すると、audit_trail表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからプロセスの状態を確認する目的でのみ使用されます。

監査情報を保存しない場合は、Off値を使用します。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。監査レベルの設定の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の監査レベル設定の優先順位の概要に関する項を参照してください。

値	説明
継承	インフラストラクチャ・レベルから監査レベルを継承します。
オフ	監査イベント(アクティビティ実行情報)は保持されず、ロギングは実行されません。この場合、インスタンス処理のパフォーマンスがわずかに向上する可能性があります。
最小	すべてのイベントがログに記録されます。ただし、監査詳細(変数の内容)は記録されません。
エラー	管理者がただちに対処する必要があり、製品のバグ以外が原因の重大な問題のみログに記録します。このレベルを使用すると、パフォーマンスを向上できます。
本番	すべてのイベントがログに記録されます。assignアクティビティの監査詳細は記録されませんが、それ以外のすべてのアクティビティの詳細が記録されます。
開発	すべてのイベント、およびすべてのアクティビティのすべての監査詳細がログに記録されます。

13.2.2.2 AuditDetailThreshold

auditdetailthresholdプロパティには、監査証跡詳細文字列の最大サイズ(KB)を設定します。これを超えると、監査証跡詳細文字列が監査証跡とは別に格納されるようになります。監査証跡詳細文字列がしきい値設定より大きい場合、監査証跡詳細文字列は、監査証跡が最初に取得されたときに即座にロードされません。詳細文字列のサイズとともにリンクが表示されます。しきい値設定より大きな文字列は、audit_trail表ではなくaudit_details表に格納されます。

通常、詳細文字列にはBPEL変数の内容が含まれています。変数が非常に大きい場合は、変数を監査証跡に記録すると、パフォーマンスに重大な影響を与える可能性があります。

デフォルト値は50000(50KB)です。

13.2.2.3 AuditStorePolicy

このプロパティは、BPEL監査データを保持するための方針を指定します。

値	説明
syncSingleWrite (デフォルト)	監査証跡およびデハイドレーションは、1つのトランザクションでDBに対して保持されます。
syncMultipleWrite	監査証跡およびデハイドレーションは、同じスレッドの別個のトランザクションで保持されます。
async	監査証跡およびデハイドレーションは、別個のスレッドおよび別個のトランザクションによって保持されます。

デフォルトでは、監査メッセージはBPELメイン・トランザクションの一部として格納されます。BPELインスタンスは、フローがデハイドレーションに達するまで監査メッセージを保持し続けます。ユースケースによっては、たとえば、大規模なループがあり、デハイドレーション・ポイントがループ内にない場合、大量の監査ログがたまってしまいます。このため、メモリー不足問題が発生して、BPELメイン・トランザクションでタイムアウト・エラーが発生する可能性があります。syncMultipleWriteまたはasyncを使用して、監査メッセージをメイン・トランザクションとは別個に格納することを検討してください。

syncMultipleWriteおよびasync auditStorePolicyを使用する場合に、検討する必要がある他のプロパティがいくつかあります。次の各項を参照してください。

13.2.2.4 AuditFlushByteThreshold

このプロパティは、エンジンが監査イベントをフラッシュする頻度を制御します。基本的に現行バッチにイベントを追加した後に、エンジンは現行バッチのバイト・サイズがこの値より大きいかどうかを確認します。

asyncまたはsyncMultipleWriteの監査方式を使用している場合は、このプロパティのチューニングを検討してください。このサイズは、アプリケーションに基づいてチューニングする必要があります。

13.2.2.5 AuditFlushEventThreshold

このプロパティは、エンジンが監査イベントをフラッシュする頻度を制御します。基本的にイベント数がこの制限に達すると、エンジンはストア・コールをトリガーします。

asyncまたはsyncMultipleWriteの監査方式を使用している場合は、このプロパティのチューニングを検討してください。このサイズは、アプリケーションに基づいてチューニングする必要があります。

13.2.3 OneWayDeliveryPolicy

oneWayDeliveryPolicyは、Oracle 10gの構成プロパティdeliveryPersistencePolicyが基になっています。

新しい構成プロパティ名はbpel.config.oneWayDeliveryPolicyです。

警告: このプロパティをasync.cacheに設定した場合に、システム障害が発生すると、メッセージが失われる可能性があります。詳細は、『Oracle BPEL Process Manager管理者ガイド』を参照してください。

oneWayDeliveryPolicyプロパティは、Oracle BPEL Serverに入るメッセージのデータベース永続性を制御します。デフォルトでは、受信リクエストは配信サービス・データベース表dlv_messageに保存されます。保存されたリクエストは、後でOracle BPEL Serverのワーカー・スレッドによって取得され、ターゲットのBPELプロセスへ配信されます。このプロパティは、配信メッセージを永続化するものであり、永続プロセスに適用されます。

oneWayDeliveryPolicyプロパティをasync.cacheに設定すると、一方向メッセージの到着頻度がOracle BPEL Serverによる配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。また、システムが過負荷の状態になり(メッセージがスケジュール済キューにたまり)、メモリー不足エラーが発生することもあります。各自のユースケース・シナリオを検討し、この設定が適切かどうかを判断してください。

一方向呼出しメッセージは、配信されるまで、配信キャッシュに格納されます。一方向メッセージの到着頻度がOracle BPEL Serverによる配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。

値	説明
async.persist(デフォルト)	配信メッセージはデータベースに保存されます。この設定の場合、信頼性は確保されますが、データベースのパフォーマンスに多少の影響が出ます。システムの全体的なパフォーマンスに影響が出ることもあります。
async.cache	受信した配信メッセージはメモリー内キャッシュにのみ保存されます。信頼性よりパフォーマンスを優先する場合は、この設定を検討してください。
sync	Oracle BPEL Serverに、呼出しキューのメッセージのスケジューリングをバイパスするよう指示し、BPELインスタンスを同期的に呼び出します。この設定は、データベースのパフォーマンスに影響を与えることがあります。

13.2.4 MaximumNumberOfInvokeMessagesInCache

このプロパティは、メモリー内キャッシュに保持できる呼出しメッセージの数を指定します。エンジンがこの制限に達すると、メモリー内キャッシュのディスパッチャにメッセージをプッシュし、かわりにDBにメッセージを保存するため、これらの保存されたメッセージはリカバリ・ジョブを使用してリカバリできます。無効にするには、値-1を使用します。

デフォルト値は100000です。

13.2.5 StatsLastN

StatsLastNプロパティには、最近処理されたリクエスト・リストのサイズを設定します。リクエストが終了するたびに、リクエストの統計がリクエスト・リストに保存されます。0以下の値を指定すると、統計収集が無効になります。パフォーマンスを最適化するには、統計収集が不要であれば無効にすることを検討してください。

このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

デフォルト値は-1です。

13.2.6 LargeDocumentThreshold

largedocumentthresholdプロパティには、大きなXMLドキュメントの永続性しきい値を設定します。これは、BPEL変数の最大サイズ(KB)です。これを超えると、BPEL変数が他のインスタンス・スコープ・データとは異なる表に格納されるようになります。

このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

インスタンス処理を行う必要が生じるたびに、大きなXMLドキュメントの読込みおよび書出しが絶えず行われる場合は、Oracle BPEL Server全体のパフォーマンスに影響が出ます。

デフォルト値は10000(100KB)です。

13.2.7 ValidateXML

validateXMLプロパティには、送受信するXMLドキュメントを検証するかどうかを指定します。Trueに設定すると、Oracle BPEL Process Managerは送受信するXMLドキュメントにスキーマ検証を適用します。スキーマに準拠しないペイロード・データが捕捉され、フォルトとして表示されます。

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

注意: XMLペイロード検証を有効にすると、パフォーマンスに影響が出る可能性があります。

このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

デフォルト値はFalseです。

13.2.8 SyncMaxWaitTime

SyncMaxWaitTimeプロパティには、プロセス結果レシーバが戻るまでに結果を待つ最大時間を設定します。非同期BPELプロセスからの結果は、Oracle BPEL Serverからの結果を待つレシーバによって同期的に取得されます。

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

13.2.9 InstanceKeyBlockSize

InstanceKeyBlockSizeプロパティは、インスタンスIDの範囲サイズを制御します。Oracle BPEL Serverは、指定された値を使用して、インスタンス・キー(プロセス・インスタンスIDの範囲)をバッチ形式で作成します。このメモリー内IDの範囲が作成されると、次の範囲が更新されて、ci_id_range表に保存されます。

たとえば、instanceKeyBlockSizeが100に設定されている場合、Oracle BPEL Serverはメモリー内にインスタンス・キーの範囲(100個のキー。これは後でcube_instance表にcikeyとして挿入される)を作成します。最適なパフォーマンスを確保するには、ブロック・サイズがci_id_range表に対する更新の数より大きくなるようにします。

デフォルト値は10000です。

13.2.10 MaxRecoverAttempt

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

BPELインスタンスがinvokeMessageを使用して別のサーバーへのコールを作成し、サーバー停止、検証エラーまたはセキュリティ例外のためにそのコールが失敗すると、invokeMessageはリカバリ・キューに入れられ、BPELはそれらのメッセージを再試行しようとします。大量のメッセージがあり、大部分が同じターゲットに送信されている場合、そのターゲットはオーバーロードになる可能性があります。MaxRecoveryAttemptの適切な値を設定して、BPEL Webサービス・コールからターゲットのサーバーに対する過剰な負荷を防ぎます。

13.3 コンポジット内で設定するBPELプロパティ

この項では、デプロイメント・ディスクリプタの一部のセクションの構成プロパティを示します。各構成プロパティ・パラメータ、および各パラメータを変更した場合に予想されるエンジンの動作について説明します。

この項で設定するプロパティはすべて、BPELプロセスを含むコンポーネントの動作にのみ影響を与えます。各BPELプロセスは、コンポジットのコンポーネントとして作成できます。これらのプロパティは、composite.xmlまたはOracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで変更できます。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。

13.3.1 コンポーネント・プロパティ

次のコンポーネント・プロパティをチューニングすることでパフォーマンスを改善できます。

13.3.1.1 inMemoryOptimization

このプロパティは、処理対象のプロセスが一時プロセスであり、インスタンスのデハイドレーションが必要ないことをOracle BPEL Serverに示します。Trueに設定すると、completionPersistPolicyを使用して永続性動作が判断されます。このプロパティをTrueに設定できるのは、一時プロセス、またはreceive、wait、onMessage、onAlarmなどのアクティビティのようにデハイドレーション・ポイントを含まないプロセスに対してのみです。inMemoryOptimizationプロパティは、BPELコンポーネント・レベルで設定します。Falseに設定すると、デハイドレーションが無効になり、一部のユースケースのパフォーマンスを向上できます。

値:

このプロパティは次の値を取ります。

• False(デフォルト): インスタンスは完全に永続化され、デハイドレーション・ストア・データベースに記録されます。

• True: completionPersistPolicyを使用して永続性動作が判断されます。13.3.1.2項を参照してください。

13.3.1.2 completionPersistPolicy

このプロパティでは、インスタンス・データの保存方法を構成します。BPELコンポーネント・レベルでのみ設定できます。completionPersistPolicyプロパティを使用できるのは、inMemoryOptimizationがTrue(一時プロセス)に設定されている場合のみです。このパラメータは、データベースの増大およびスループットに影響を与える可能性があります(I/Oが減少するため)。

値	説明
On(デフォルト)	完了したインスタンスは通常どおり保存されます。
遅延	完了したインスタンスは、異なるスレッドで、別のトランザクション内に保存されます。
フォルト	失敗したインスタンスのみが保存されます。 注意: 未処理フォルトが発生すると、これらのフラグにかかわらず、インスタンスの監査情報はcube_instance表内で維持されます。
オフ	このプロセスのインスタンスは保存されません。

13.3.1.3 auditLevel

BPELプロセス・サービス・コンポーネントに監査レベルを設定できます。この設定は、SOAインフラストラクチャ、サービス・エンジンおよびSOAコンポジット・アプリケーション・レベルでの監査レベルより優先されます。

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

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

値	説明
継承	インフラストラクチャ・レベルから監査レベルを継承します。
オフ	監査イベント(アクティビティ実行情報)は保持されず、ロギングは実行されません。この場合、インスタンス処理のパフォーマンスがわずかに向上する可能性があります。
最小	すべてのイベントがログに記録されます。ただし、監査詳細(変数の内容)は記録されません。
エラー	管理者がただちに対処する必要があり、製品のバグ以外が原因の重大な問題のみログに記録します。このレベルを使用すると、パフォーマンスを向上できます。
本番	すべてのイベントがログに記録されます。assignアクティビティの監査詳細は記録されませんが、それ以外のすべてのアクティビティの詳細が記録されます。
開発	すべてのイベント、およびすべてのアクティビティのすべての監査詳細がログに記録されます。

13.3.2 パートナ・リンク・プロパティ

パートナ・リンクは、実行時にBPELで動的に構成できます。これは、BPELによって呼び出されるターゲット・サービスが実行時まで不明な場合に便利です。次のパートナ・リンク・プロパティをチューニングすることでパフォーマンスを改善できます。

13.3.2.1 idempotent

idempotentアクティビティとは、再試行可能なアクティビティ(assignアクティビティやinvokeアクティビティなど)です。Oracle BPEL Serverは、非idempotentアクティビティの後にインスタンスを保存します。このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

値:

このプロパティは次の値を取ります。

• False: アクティビティは実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。idempotentをFalseに設定すると、フェイルオーバーによる保護は強化されますが、BPELプロセスがデハイドレーション・ストアに頻繁にアクセスする場合はパフォーマンスに影響が出ることがあります。

• True(デフォルト): Oracle BPEL Serverに障害が発生した場合、再起動後にアクティビティが再度実行されます。これは、アクティビティの呼出し直後にサーバーがデハイドレーションされず、アクティビティの実行が記録されていないためです。このプロパティをTrueに設定できる例としては、読取り専用サービス(CreditRatingServiceなど)や、インスタンスのトランザクションを共有するローカルのEJB/WSIF呼出しなどがあります。

13.3.2.2 nonBlockingInvoke

デフォルトでは、Oracle BPEL Process Managerはブランチをパラレルではなく順番に実行することによって、単一のスレッドで処理を実行します。このプロパティをTrueに設定すると、各ブランチのinvokeアクティビティをパラレルに実行するための新しいスレッドが作成されます。このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

複数のflowブランチやflow nブランチにinvokeアクティビティが存在する場合は、このパラメータをTrueに設定することを検討してください。これは、パラレルのinvokeアクティビティが双方向の際には特に有効ですが、パラレルの一方向呼出しに対しても効果的な場合があります。

注意: 同じパートナ・リンクへの呼出しは、パラレルではなく順番に発生します。nonBlockingInvokeをTrueに設定して、毎回異なるパートナ・リンクを呼び出すと、すべてのパートナ・リンクが同じソースを指し示している場合でも、各リンクはパラレルで機能します。

値:

• True: Oracle BPEL Serverは、呼出しを実行するための新しいスレッドを生成します。

• False(デフォルト): Oracle BPEL Serverは、単一のプロセス・スレッドでinvokeアクティビティを実行します。

13.3.2.3 validateXML

メッセージ境界の検証を有効にします。検証を追加すると、CPUおよびメモリーのリソースが余分に消費されて、パフォーマンスに影響を与えることがありますので注意してください。

値:

• True: Trueに設定すると、このパートナ・リンクの<receive>および<invoke>中に、XMLメッセージがXMLスキーマに対して検証されます。XMLメッセージが無効な場合は、bpelx:invalidVariablesランタイムBPELフォルトがスローされます。これは、ドメイン・レベルのvalidateXMLプロパティに優先します。

• False(デフォルト): XML検証が無効になります。

13.4 インスタンス・データ増大の影響を受ける表

インスタンス・データは、Oracle BPEL Process Managerのスキーマ表の領域を占有します。監査やデハイドレーションによってデータが増大すると、データベースのパフォーマンスおよびスループットに大きな影響を与える可能性があります。監査構成は、13.2.2項「監査」を参照してください。また、デハイドレーション構成は、13.3.1.1項「inMemoryOptimization」を参照してください。次の表は、インスタンス・データ増大の影響を受ける表をまとめたものです。各表について簡単に説明しています。

表13-1 インスタンス・データ増大の影響を受けるOracle BPEL Process Managerの表

表の名前	表の説明
audit_trail	インスタンスの監査証跡を格納します。Oracle BPEL Controlに表示される監査証跡は、XMLドキュメントから作成されます。インスタンスが処理されると、各アクティビティがイベントをXMLとして監査証跡に書き込みます。
audit_details	APIを通じてログに記録される監査詳細を格納します。assignアクティビティなどは、デフォルトで、変数を監査詳細としてログに記録します。 監査詳細はサイズが大きいため、audit_trail表から分離されています。詳細のサイズがこのプロパティに指定した値より大きい場合、詳細はこの表に格納されます。それ以外の場合は、audit_trail表に格納されます。
cube_instance	プロセス・インスタンス・メタデータ(インスタンスの作成日、現在の状態、タイトル、プロセス識別子など)を格納します。
cube_scope	インスタンスのスコープ・データ(BPELフローで宣言されているすべての変数や、フロー全体のルーティング・ロジックを支援する内部オブジェクトなど)を格納します。
dlv_message	受信(呼出し)メッセージおよびコールバック・メッセージを受信時に格納します。この表には、メッセージのメタデータ(現在の状態、プロセス識別子、受信日など)のみが格納されます。
dlv_subscription	インスタンスの配信サブスクリプションを格納します。receiveアクティビティやonMessageアクティビティのように、インスタンスがパートナからのメッセージを待っているときは必ず、そのreceiveアクティビティに対するサブスクリプションが書き込まれます。
document_ci_ref	xml_document表に格納されているデータへのキューブ・インスタンスの参照を格納します。
document_dlv_msg_ref	xml_document表に格納されているdlv_messageドキュメントへの参照を格納します。
wftask	インスタンスに対して作成されたタスクを格納します。TaskManagerプロセスは、この表に現在の状態を保存します。
work_item	インスタンスによって作成されたアクティビティを格納します。BPELフローのすべてのアクティビティにwork_item表が存在します。この表には、アクティビティのメタデータ(現在の状態、ラベル、(waitアクティビティで使用される)有効期限)が格納されます。
xml_document	システム内のすべてのラージ・オブジェクト(dlv_messageドキュメントなど)を格納します。この表には、データがバイナリ・ラージ・オブジェクト(BLOB)として格納されます。ドキュメントとメタデータの記憶域を分けることで、ドキュメントのサイズに関係なく、メタデータを頻繁に変更できるようになります。
Headers_properties	ヘッダーおよびプロパティの情報を格納します。