この付録では、Oracle Business Rulesの使用時に発生する問題の回避方法および解決方法について説明します。内容は次のとおりです。
Rules Designerでは、Java Beanプロパティをサポートしているメソッドが選択リストに表示されません。表示されるのは、Beanプロパティのみです。 たとえば、Y
という名前のプロパティを持つJava Beanには、少なくともgetterメソッドgetY()
が設定されている必要があり、setterメソッドsetY(y-type-param)
も設定されている場合があります。Javaファクト・タイプを表示すると、すべてのプロパティとメソッド(プロパティを構成する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)
ディクショナリまたはディクショナリ・パッケージの名前を変更する場合、JDeveloperの「リファクタ」→「名前の変更」を使用しても、ディクショナリ名またはディクショナリ・パッケージ名に効果はありません。ディクショナリ名またはディクショナリ・パッケージ名を変更するには、「ファイル」→「名前の変更」を使用します。「リファクタ」→「名前の変更」は使用しないでください。「リファクタ」オプションは、ディクショナリやディクショナリ・パッケージには適用されません。
この名前の変更操作によって、ディクショナリの名前は変更されますが、別名は変更されません。 この別名は、「ディクショナリ設定」ダイアログを使用して変更できます。 通常、これらは同じ値に設定する必要があります。詳細は、第2.2.4項「ディクショナリ設定の表示および編集方法」を参照してください。
詳細は、第2.2.5項「ディクショナリまたはディクショナリ・パッケージの名前の変更方法」を参照してください。
ディクショナリが、BPEL以外のコンポジットの一部としてBusiness Rulesコンポーネントを使用するコンポジット・アプリケーションの一部分である場合は、次の手順を実行してその名前を変更できます。
BPELを使用しないコンポジット・アプリケーション内のディクショナリの名前を変更するには、次を実行します。
ビジネス・ルールを使用するコンポジット・アプリケーション内のディクショナリの名前を変更する手順は、次のとおりです。
ディクショナリ・ファイルを選択し、「ファイル」→「名前の変更」を選択して、ディクショナリ・ファイルの名前を変更します。
ディクショナリを開き、「ディクショナリ設定」ダイアログを使用して、ディクショナリ名と一致するように別名を変更します。詳細は、第2.2.4項「ディクショナリ設定の表示および編集方法」を参照してください。
プロジェクトで、新しいディクショナリ名と対応するようにディクショナリ名.decs
ファイルの名前を変更します。
プロジェクトで、ディクショナリ名.decs
ファイルを開き、名前を変更したディクショナリ名と一致するように<path>要素の値を変更します。
プロジェクトで、新しいディクショナリ名と対応するようにディクショナリ名.componentType
ファイルの名前を変更します。
プロジェクトで、composite.xml
を開き、「ソース」タブを選択して、名前を変更したディクショナリと一致するように<component
>要素のname
属性を編集します。
composite.xml
ファイルで、名前を変更したディクショナリ名(拡張子.decs
)と一致するように<implementation.decision>
要素のsrc
属性を編集します。
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固有のキーワードはエラーなしで使用できます。ただし、クラス名としてキーワードを使用する場合は例外です。 This is unlikely for Java classes because by convention they start with an upper case letter and RL specific keywords are all lowercase.規則では、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が原因である可能性があります。データが次のサイトで説明されています。
https://jaxb.dev.java.net/issues/show_bug.cgi?id=490
回避方法: この問題の回避方法は、図D-1および図D-2に示すように、値を適切な要素に割り当てることです。図D-2では、approvalRequired
にデフォルト値false()
が割り当てられています。
10.1.3から移行されたディクショナリは、JAXB 2.0ではなくJAXB 1.0を使用します。JAXB 1.0は、Oracle Fusion Middleware 11g リリース1(11.1.1)ディクショナリのデフォルトです。 JAXB 1.0が使用されていることから、移行されたディクショナリには要素タイプが含まれている場合があります。 ディクショナリに参照可能としてマーク付けされている要素タイプがある場合、生成されたRLでMultipleInheritanceException
がスローされる可能性があります。
この問題の解決策は、要素ファクト・タイプを参照不可としてマーク付けするか、データ・モデルから削除することです。ルールの記述にはJAXBで生成されたタイプのクラスのみを使用する必要があるため、要素タイプを削除しても機能が損なわれることはありません。
'_'
+ 番号という形式の名前がある場合、JAXBの定義済の動作は失敗します。 この場合、JAXBではこの文字列から明確なJavaクラス名を生成できません。 デフォルトの動作では、JAXBは、'_'
+ 文字が単語の境界(underscoreBinding="asWordSeparator"
)を示すものとして処理します。つまり、アンダースコアは削除され、この文字は先頭が大文字のキャメル・ケース(UpperCamelCaseのような形式)になります。 たとえば、_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
を使用することはできません。