ヘッダーをスキップ
Oracle Fusion Middleware Oracle Business Rulesユーザーズ・ガイド
11g リリース1（11.1.1）
B55917-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

D Oracle Business Rulesのトラブルシューティング

この付録では、Oracle Business Rulesの使用時に発生する問題の回避方法および解決方法について説明します。内容は次のとおりです。

D.1 非表示のgetterメソッドとsetterメソッド

Rules Designerでは、Java Beanプロパティをサポートしているメソッドが選択リストに表示されません。表示されるのは、Beanプロパティのみです。 たとえば、Yという名前のプロパティを持つJava Beanには、少なくともgetterメソッドgetY()が設定されている必要があり、setterメソッドsetY(y-type-param)も設定されている場合があります。Javaファクト・タイプを表示すると、すべてのプロパティとメソッド（プロパティを構成するgetterとsetterを含む）が表示されます。選択リストに表示されるのは、Javaクラスのプロパティ（getterメソッドとsetterメソッド以外）のみです。プロパティ表示の制御を試みる場合は、プロパティの表示可能性フラグを使用することをお薦めします。getterメソッドまたはsetterメソッドを非表示としてマーク付けすると、プロパティを選択リストから削除できなくなります。

D.2 プロパティのsetterのみを使用したJavaクラス

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)

D.3 ディクショナリまたはディクショナリ・パッケージの名前の変更

ディクショナリまたはディクショナリ・パッケージの名前を変更する場合、JDeveloperの「リファクタ」→「名前の変更」を使用しても、ディクショナリ名またはディクショナリ・パッケージ名に効果はありません。ディクショナリ名またはディクショナリ・パッケージ名を変更するには、「ファイル」→「名前の変更」を使用します。「リファクタ」→「名前の変更」は使用しないでください。「リファクタ」オプションは、ディクショナリやディクショナリ・パッケージには適用されません。

この名前の変更操作によって、ディクショナリの名前は変更されますが、別名は変更されません。 この別名は、「ディクショナリ設定」ダイアログを使用して変更できます。 通常、これらは同じ値に設定する必要があります。詳細は、第2.2.4項「ディクショナリ設定の表示および編集方法」を参照してください。

詳細は、第2.2.5項「ディクショナリまたはディクショナリ・パッケージの名前の変更方法」を参照してください。

ディクショナリが、BPEL以外のコンポジットの一部としてBusiness Rulesコンポーネントを使用するコンポジット・アプリケーションの一部分である場合は、次の手順を実行してその名前を変更できます。

BPELを使用しないコンポジット・アプリケーション内のディクショナリの名前を変更するには、次を実行します。

ビジネス・ルールを使用するコンポジット・アプリケーション内のディクショナリの名前を変更する手順は、次のとおりです。

  1. ディクショナリ・ファイルを選択し、「ファイル」→「名前の変更」を選択して、ディクショナリ・ファイルの名前を変更します。

  2. ディクショナリを開き、「ディクショナリ設定」ダイアログを使用して、ディクショナリ名と一致するように別名を変更します。詳細は、第2.2.4項「ディクショナリ設定の表示および編集方法」を参照してください。

  3. プロジェクトで、新しいディクショナリ名と対応するようにディクショナリ名.decsファイルの名前を変更します。

  4. プロジェクトで、ディクショナリ名.decsファイルを開き、名前を変更したディクショナリ名と一致するように<path>要素の値を変更します。

  5. プロジェクトで、新しいディクショナリ名と対応するようにディクショナリ名.componentTypeファイルの名前を変更します。

  6. プロジェクトで、composite.xmlを開き、「ソース」タブを選択して、名前を変更したディクショナリと一致するように<component>要素のname属性を編集します。

  7. composite.xmlファイルで、名前を変更したディクショナリ名（拡張子.decs）と一致するように<implementation.decision>要素のsrc属性を編集します。

D.4 実行時のNoClassDefFoundエラー

XMLファクトで作業中に、次の書式のエラーが送信される場合があります。

Exception in thread "main" java.lang.NoClassDefFoundError:

java.lang.NoClassDefFoundErrorの原因は、必須クラスがCLASSPATHにないことである可能性があります。次をチェックしてみてください。

D.5 RL固有のキーワード・ネーミング競合エラー

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ランゲージ・リファレンス・ガイド』を参照してください。

D.6 ビジネス・ルール・サービス・ランタイムからのjava.lang.IllegalAccessError

問題: 次のようなエラーが送信されます。

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()が割り当てられています。

図D-1 ビジネス・ルール・サービス入力の値を初期化する式の追加

図D-1の説明が続きます
「図D-1 ビジネス・ルール・サービス入力の値を初期化する式の追加」の説明

図D-2 ビジネス・ルール・サービスの入力変数に割り当てられた式

図D-2の説明が続きます
「図D-2 ビジネス・ルール・サービスの入力変数に割り当てられた式」の説明

D.7 JAXB 1.0ディクショナリとRLのMultipleInheritanceException

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で生成されたタイプのクラスのみを使用する必要があるため、要素タイプを削除しても機能が損なわれることはありません。

D.8 アンダースコアを持つXMLスキーマで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となります。

D.9 デシジョン・サービスの入力と出力はどのように制限されますか。

デシジョン・サービスを使用して、入力を定義するXMLスキーマを含むビジネス・ルールを実行すると、XMLスキーマ・ファイルFoo.xsd内の任意のcomplexType tFooの場合、タイプtFooのXMLスキーマ要素fooを1つのみ含めることができます。 デシジョン・サービスでは、同じタイプtFooの2つの要素fooおよびbarを使用することはできません。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引