| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース1 (11.1.1) B61006-10 |
|
 前 |
 次 |
Oracle Business Rulesテクノロジは、ビジネス・ルールの自動化、およびJavaコードやBPELプロセスといった手続き型ロジックからのビジネス・ルールの抽出を可能にします。
この章の内容は次のとおりです。
Oracle Business Rulesを使用すると、パフォーマンスが高く使いやすい形でビジネス・ルール・テクノロジを実装できます。使いやすいオーサリング環境、および推論機能を持つきわめて高パフォーマンスなルール・エンジンを備えています。Oracle Business Rulesは、Oracle Fusion Middlewareスタックの一部であり、多くのOracle製品(ミドルウェアとアプリケーションの両方を含む)のコア・コンポーネントとなります。
ほとんどの場合、ルールを記述する際にパフォーマンスに注意を払う必要はありません。ただし、どのテクノロジにも言えることですが、パフォーマンスを最大化するのに役立つヒントやコツがありますので、必要に応じて利用してください。考慮事項の大半は、データ・モデルの初期構成に関するものです。
ルール・エンジンの効率が最も高いのは、推論するファクトがJava Beans (またはRLクラス)であり、関連付けられたテストにBeanプロパティが含まれている場合です。Beanでは、各Beanプロパティのgetメソッドおよびsetメソッド(setが使用可能な場合)を公開する必要があります。Java Beansでアプリケーション・データを直接利用できない場合は、そのデータをフラット化して、ファクトとしてアサートされる(さらにルールで使用される)Java Beansのコレクションにします。
Account.Contact.Addressのような式には、オブジェクトの逆参照が複数含まれています。ルール条件では、これは単独の逆参照を含む式ほど効率的ではありません。ベスト・プラクティスとして、ファクト・タイプは可能なかぎりフラット化してください。ファクト・タイプが階層構造を伴う場合は、assertXPathまたはその他の方法で、オブジェクト階層をアサートすることを検討してください。つまり、前述の例では、AccountとContactの両方をファクト・タイプとしてアサートします。
ルール条件では、値や状態の変更といった副作用を持つメソッドまたは関数を使用しないでください。ルール・エンジンがReteネットワークを構築したときに行われる最適化、ならびにファクトとして実行されるReteネットワーク操作がアサート、変更(および再アサート)または取り出されたときに行われる最適化により、ルール条件内のテストが評価される回数は、手続き型プログラムに比べて多くなったり、少なくなったりします。メソッドまたは関数に副作用がある場合、その副作用が発生する回数は予測できません。
ルール条件では、コストの高い操作を避けてください。コストの高い操作とは、I/O(ディスクまたはネットワーク)や大量の計算処理を伴う操作です。一般に、I/OやDBMSにルール・エンジンから直接アクセスするのは避けることを検討してください。このような操作は、ルール・エンジンの外部で行います。コストの高いその他の操作や計算については、計算処理を実行し、その結果をJavaファクトまたはRLファクトとしてアサートすることを検討してください。これらのファクトは、コストの高い操作ではなく、ルール条件で使用されます。
ルール・パターンの順序を変更すると、時間またはメモリー使用量、あるいはその両方の点でルール評価のパフォーマンスが向上します。ルール条件内のファクト句(パターン)の順序を決定する際には、主なガイドラインとして次の2点に従ってください。
あるファクトがルール評価中に変更されない(頻繁には変更されない)と予想される場合は、そのファクト句を、頻繁に変更されるファクト句より前に配置します。つまり、予想される変更頻度が低いものから高いものへとファクト句を並べます。このようにファクト句を並べると、ルール評価のパフォーマンス(所要時間)が向上します。
あるファクト句(そのファクトのみを伴うテストを含む)の一致するファクトが、ルール条件内の他のファクト句より少ないと予想される場合は、そのファクト句を他のファクト句より前に配置します。つまり、限定性が最も高い(一致するファクトが最も少ない)ものから低いものへとファクト句を並べます。こうすることで、ルール評価中に使用されるメモリーの量が減少します。また、パフォーマンスが向上することもあります。
この2つのガイドラインは対立することがあります。その場合は、いろいろと試したうえで最適な順序を見つけてください。
ファクト句と同様に、ルール条件内のテストは、限定性の高いものが限定性の低いものより前にくるように並べてください。そうすれば、ルール条件を満たさないファクトに必要な計算処理の量を減らすことができます。限定性の度合いが不明な場合や、一連のテストの限定性が同程度になる予想される場合は、単純なテストをコストの高いテストより前に配置してください。
|
注意: AssertXPathは、10gのルールの使用方法または11gに移行される10gのプロジェクトにのみ関係します。11gリリース1以降では、AssertXPathはAssertTreeに置き換えられました。11gでは、リンクが異なる方法で扱われているため、XLinkファクトはアサートされません。AssertTreeにはデフォルトで、10gのルール用の特別なチェック・ボックスと同様の機能があります。 |
ルール・エンジンが行う作業のほとんどは、アサート、取出しまたは変更の操作中に実行されます。その中でも、assertXPathは非常に便利ですが、パフォーマンスに影響を与えることがあります。このメソッドには、1つのコールで階層全体をアサートするだけでなく、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());
}
assertXPathのパフォーマンスを改善するには、Rule Authorの「ディクショナリ・プロパティ」ページで、「パフォーマンスのために改善されたassertXPathサポートを有効化」チェック・ボックスを選択します。この機能を利用するには、次の条件を満たす必要があります。
XPath式//*のみを使用してassertXPathを呼び出すこと。他のXPath式を使用すると、RLIllegalArgumentExceptionが発生します。
XLinkファクトはアサートされないため、XLinkファクトをルール条件で使用しないこと。
