| Oracle Fusion Middleware Oracle Business Rulesユーザーズ・ガイド 11g リリース1(11.1.1.7) B55917-05 |
|
 前 |
 次 |
この付録では、Oracle Business Rulesの使用時に発生する問題の回避方法および解決方法について説明します。
内容は次のとおりです。
Rules Designerでは、Java Beanプロパティをサポートしているメソッドは選択リストに表示されません。Beanプロパティのみが表示されます。たとえば、Yという名前のプロパティを持つJava Beanには、少なくとも1つのgetterメソッドgetY()が必要で、setterメソッドsetY(y-type-param)が存在する場合もあります。Java FactTypeを表示すると、すべてのプロパティとメソッド(プロパティを構成するgetterおよびsetterを含む)が表示されます。選択リストには、Javaクラスのプロパティ(getterおよびsetterメソッドは含まない)のみが表示されます。プロパティの表示を制御しようとする場合は、プロパティの表示フラグを使用するのが最善の方法です。getterまたはsetterメソッドを非表示にマークしても、選択リストからプロパティが削除されない場合もあります。
Javaでは、Java Beanイントロスペクタに書込み専用プロパティが組み込まれています。Oracle RLでは、ルール内で判断できないため、Beanのようなプロパティは組み込まれません。したがって、Oracle RLでJavaファクト・タイプのBeanプロパティに正しくアクセスするには、getterおよびsetterの両方が必要です。setterがあってgetterのないプロパティ、つまり書込み専用プロパティは、Oracle RLの新しい構文では許可されません。
たとえば、Bean FooのメソッドがsetProp1(int i)のみの場合、Oracle RLでは次を使用できません。
Foo f = new Foo(prop1: 0)
XMLファクトで作業中に、次の書式のエラーが送信される場合があります。
Exception in thread "main" java.lang.NoClassDefFoundError:
java.lang.NoClassDefFoundErrorの原因は、必須クラスがCLASSPATHにないことである可能性があります。次をチェックしてみてください。
実行時にCLASSPATHにxml.jarを追加します。
生成済でコンパイル済のJAXBクラスが置かれるディレクトリをCLASSPATHに追加します。
Oracle Business Rulesでは、Rules DesignerからRLを生成する際、RL固有のキーワードがエスケープされます。ほとんどの場合、RL固有のキーワードはエラーなしで使用できます。ただし、クラス名としてキーワードを使用する場合は例外です。規則では、Javaクラスは大文字で始まり、RL固有のキーワードはすべて小文字であるため、これはJavaクラスにはほとんどありません。詳細は、『Oracle Fusion Middleware Oracle Business Rulesランゲージ・リファレンス・ガイド』を参照してください。
java.lang.IllegalAccessError: tried to access class com.sun.xml.bind.v2.runtime.reflect.opt.Const from class:...
理由: これは、アンマーシャリングが不正な場合(floatが必要な場合の文字など)に引き起こされるJAXB 2.1.6の問題490が原因である可能性があります。データが次のサイトで説明されています。
http://java.net/jira/browse/JAXB-490
回避方法: この問題の回避方法は、図D-1および図D-2に示すように、値を適切な要素に割り当てることです。図D-2では、approvalRequiredにデフォルト値false()が割り当てられています。
10.1.3から移行したディクショナリでは、JAXB 2.0ではなくJAXB 1.0が使用されます。これは、Oracle Fusion Middleware 11gリリース1 (11.1.1)ディクショナリのデフォルトです。このJAXB 1.0の使用により、移行されたディクショナリには要素タイプが含まれていない場合があります。ディクショナリの要素タイプが表示にマークされている場合、生成したRLによってMultipleInheritanceExceptionをスローされることになります。
この問題の解決策は、要素ファクト・タイプを参照不可としてマーク付けするか、データ・モデルから削除することです。ルールの記述にはJAXBで生成されたタイプのクラスのみを使用する必要があるため、要素タイプを削除しても機能が損なわれることはありません。
JAXBの定義済の動作では、'_' + 数字という形式の名前が見つかったら、エラーになります。この場合、JAXBはこの文字列から明白なJavaクラス名を生成できません。JAXBのデフォルト動作では、'_' + 文字は単語の境界として処理されます(underscoreBinding="asWordSeparator")。つまり、アンダースコアが外されて、文字はUpperCamelCasedになります。たとえば、_fooBarはFooBarにマップされます。
この問題を解決するには、違う方法で名前を生成するように、直接JAXBのスキーマをカスタマイズする必要があります。underscoreBindingのデフォルト値は"asWordSeparator"に指定され、名前の先頭にアンダースコアを使用することはできません。
グローバルな注釈underscoreBinding="asCharInWord"を使用すると、クラス名および番号の後の先頭が大文字のキャメル・ケースで'_'が保持されます。
<xsd:annotation><xsd:appinfo>
<jaxb:globalBindings underscoreBinding="asCharInWord" />
</xsd:appinfo></xsd:annotation>
このグローバルな注釈を使用すると、_1foo_bar_bazのマッピングは_1Foo_Bar_Bazとなります。
デシジョン・サービスを使用して、入力を定義するXMLスキーマを含むビジネス・ルールを実行すると、XMLスキーマ・ファイルFoo.xsd内の任意のcomplexType tFooの場合、タイプtFooのXMLスキーマ要素fooを1つのみ含めることができます。デシジョン・サービスでは、同じタイプtFooの2つの要素fooおよびbarを使用することはできません。
デシジョン・サービスを使用する場合、スキーマでcomplexTypeを定義するか、complexTypeを定義する別のスキーマをインポートする必要があります。次に示すような、complexTypeを定義しないスキーマは使用できません。
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.example.org"
targetNamespace="http://www.example.org"
elementFormDefault="qualified">
<xsd:element name="count" type="xsd:int"/>
</xsd:schema>
Oracle Business Rulesでは、Java言語に同じ名前があるファクト・タイプ・プロパティをインポートすると、予約語が除外されます。Javaの予約語の一覧は、次のページを参照してください。
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/_keywords.html
回避方法として、除外されるプロパティを作成するgetterおよびsetterメソッドのペアの名前を変更することがあげられます。これらのメソッド名を変更できない場合、メソッドが、プロパティではなくルール内で使用されているということです。
たとえば、continueという名前のプロパティが除外された場合は、プロパティを使用するかわりに、getContinue()およびsetContinue()メソッドを使用するルールを作成できます。このためには、パターンをリライトします。たとえば、次のように置換します。
fact IncrCount ic && ic.continue == "foo"
これを次の文字列で置き換えます。
fact IncrCount ic && ic.getContinue() == "foo"
別の例では、アクションで、次のように置換します。
[assert new] IncrCount(continue:"bar")
これを次の文字列で置き換えます。
[assign new] IncrCount ic = new IncrCount( )
[call] ic.setContinue("bar")
[assert] ic
