18 Oracle Business Rulesのチューニング
Oracle Business Rulesをチューニングし、JavaコードやBPELプロセスなどの手続き型ロジックからのビジネス・ルールの抽出を可能にする際のパフォーマンスを最適化できます。
- Oracle Business Rulesについて
Oracle Business Rulesには、簡単に使用できるオーサリング環境およびパフォーマンスが高く推論可能なルール・エンジンが備えられています。 - Oracle Business Rulesのチューニング
Oracle Business Rulesをチューニングして、パフォーマンスを最適化できます。
親トピック: SOA Suiteのコンポーネント
Oracle Business Rulesについて
Oracle Business Rulesには、簡単に使用できるオーサリング環境およびパフォーマンスが高く推論可能なルール・エンジンが備えられています。
Oracle Business Rulesは、Oracle Fusion Middlewareスタックの一部であり、多くのOracle製品(ミドルウェアとアプリケーションの両方を含む)のコア・コンポーネントとなります。
『Oracle Business Process Managementによるビジネス・ルールの設計』と、『Oracle SOA SuiteでのSOAアプリケーションの開発』の「Oracle Business Rulesのスタート・ガイド」を参照してください。
親トピック: Oracle Business Rulesのチューニング
Oracle Business Rulesのチューニング
Oracle Business Rulesをチューニングして、パフォーマンスを最適化できます。
ほとんどの場合、ルールを記述する際にパフォーマンスに注意を払う必要はありません。ただし、どのテクノロジにも言えることですが、パフォーマンスを最大化するのに役立つヒントやコツがありますので、必要に応じて利用してください。考慮事項の大半は、データ・モデルの初期構成に関するものです。
表18-1 重要なビジネス・ルール・チューニング戦略
| 戦略 | 説明 | 推奨事項 |
|---|---|---|
|
Java Beansの使用 |
ルール・エンジンの効率が最も高いのは、推論するファクトがJava Beans (またはRLクラス)であり、関連付けられたテストにBeanプロパティが含まれている場合です。 |
Beanでは、各Beanプロパティのgetメソッドおよびsetメソッド(setが使用可能な場合)を公開する必要があります。 Java Beansでアプリケーション・データを直接利用できない場合は、そのデータをフラット化して、ファクトとしてアサートされる(さらにルールで使用される) Java Beansのコレクションにします。 |
|
複数の逆参照を使用するかわりに子ファクトをアサート |
|
ベスト・プラクティスとして、ファクト・タイプは可能なかぎりフラット化してください。 ファクト・タイプに階層構造がある場合、オブジェクト階層をアサートするために |
|
ルール条件における副作用の回避 |
ルール条件でテストが評価される回数は、手続き型プログラムでの回数よりも多くなるか、または少なくなる場合があります。 |
ルール条件では、値や状態の変更といった副作用を持つメソッドまたは関数を使用しないでください。 メソッドまたは関数に副作用がある場合、その副作用が発生する回数は予測できません。 |
|
ルール条件における高コストの操作の回避 |
コストの高い操作とは、I/O(ディスクまたはネットワーク)や大量の計算処理を伴う操作です。このような操作は、ルール・エンジンの外部で行います。 |
ルール条件では、コストの高い操作を避けてください。一般に、I/OやDBMSにルール・エンジンから直接アクセスするのは避けることを検討してください。 コストの高いその他の操作や計算については、計算処理を実行し、その結果をJavaファクトまたはRLファクトとしてアサートすることを検討してください。これらのファクトは、コストの高い操作ではなく、ルール条件で使用されます。 |
|
パターンの順序の検討 |
ルール・パターンの順序を変更すると、時間またはメモリー使用量、あるいはその両方の点でルール評価のパフォーマンスが向上します。システムに最適な順序を見つけるには実験が必要です。 |
あるファクトがルール評価中に変更されないと予想される場合、または頻繁には変更されない場合は、ファクト句を、変更が予想される率が少ないものから多いものへと順に配置します。 あるファクト句(そのファクトのみを伴うテストを含む)の一致するファクトが、ルール条件内の他のファクト句より少ないと予想される場合は、ファクト句を最も限定的な(一致するファクトが最も少ない)ものから最も限定的でないものへと順に配置します。 |
|
ルール条件におけるテストの順序の検討 |
適切な順序にすると、ルール条件を満たさないファクトに必要な計算処理の量を減らすことができます。 |
ルール条件内のテストは、より限定的なテストが限定的でないテストより前になるように配置される必要があります。 限定性の度合いが不明な場合や、一連のテストの限定性が同程度になると予想される場合は、単純なテストをコストの高いテストより前に配置してください。 |
assertXPathサポートの影響
assertXPathメソッドは、1つのコールで階層全体をアサートし、さらにXLinkファクトをアサートして子ファクトが親ファクトにリンクできるようにします。便利ですが、パフォーマンスに影響する場合があります。
assertXPathメソッドのパフォーマンスを改善するには、Rule Authorの「ディクショナリ・プロパティ」ページで、「パフォーマンスのために改善されたassertXPathサポートを有効化」チェック・ボックスを選択します。この機能を利用するには、次の条件を満たす必要があります。
-
//*"のみを使用して
assertXPathメソッドを呼び出すこと。他のXPath式を使用すると、RLIllegalArgumentExceptionが発生します。 -
XLinkファクトはアサートされないため、XLinkファクトをルール条件で使用しないこと。
子ファクトに対するXLinkファクトが不要であり、2、3のレベルをファクトとしてアサートするだけでよい場合は、関連するファクト・タイプのSupports XPathをオフにし、関数を使用してカスタム・アサートを実行することをお薦めします。次の例では、assertXPathメソッドを使用するかわりに、関数を使用して ExpenseReportおよびExpenseLineItemsをアサートしています。
function assertAllObjectsFromList(java.util.List objList)
{
java.util.Iterator iter = objList.iterator();
while (iter.hasNext())
{
assert(iter.next());
}
}
function assertExpenseReport (demo.ExpenseReport expenseReport)
{
assert(expenseReport);
assertAllObjectsFromList(expenseReport.getExpenseLineItem());
}
親トピック: Oracle Business Rulesのチューニング