| Oracle® Fusion Middleware Oracle SOA Suite、WebCenter PortalおよびADFアップグレード・ガイド 11g リリース1 (11.1.1.8.0) B55926-08 |
|
 前 |
| Oracle® Fusion Middleware Oracle SOA Suite、WebCenter PortalおよびADFアップグレード・ガイド 11g リリース1 (11.1.1.8.0) B55926-08 |
|
前 |
この章では、Oracle Business Rulesのディクショナリおよびプロジェクトをアップグレードする方法について説明します。
Oracle Business Rulesのディクショナリおよびプロジェクトは旧リリースから移行できます。Oracle Business Rulesリリース10.1.3.xで作成されたディクショナリをOracle Business Rules for Oracle Fusion Middleware 11g リリース1 (11.1.1)で使用するには、ディクショナリを新しいディクショナリ形式に移行する必要があります。Oracle Business Rulesリリース10.1.3.x形式のディクショナリをOracle Fusion Middleware 11g リリース1 (11.1.1)に移行する移行パスは、リリース10.1.3.xディクショナリの作成方法に応じていくつかあります。
この付録では、次の項目について説明します。
ディクショナリが10.1.3.x BPELデシジョン・サービスで作成されたアプリケーションの一部である場合は、Oracle JDeveloperでBPELプロセスを開くときに、Oracle Fusion Middleware 11g リリース1 (11.1.1)ディクショナリ形式に移行できます。
Oracle JDeveloperを使用してディクショナリを移行する手順は、次のとおりです。
図B-1に示すように、Oracle JDeveloperを開始します。これにより、Oracle JDeveloperの「開始」ページが表示されます。
「ファイル」メニューから「開く」を選択します。
プロジェクトに移動し、「開く」を選択します。
Oracle BPEL Process Manager移行ユーティリティが起動され、ルール・ディクショナリを含むプロジェクトが変換されます。
エラーがないかどうか、「メッセージ - ログ」ウィンドウを調べます。
場合によっては、移行を完了するために、移行するルール・ディクショナリをOracle Business Rules Designerにより手動で編集する必要があります。詳細は、B.4項「Oracle Business Rulesの手動移行タスク」を参照してください。
「ファイル」メニューから「すべて保存」を選択します。
MigrateRuleRepositoryコマンドライン・ツールを使用して、ディクショナリを10.1.3.x形式からOracle Fusion Middleware 11g リリース1 (11.1.1)形式に移行できます。ほとんどの移行シナリオで、手動移行タスクを実行する必要があることに注意してください。これは、10.1.3.xのコンセプトが、Oracle Fusion Middleware 11g リリース1 (11.1.1)では更新されて、より強力な構成になったためです。手動移行タスクの詳細は、B.4項「Oracle Business Rulesの手動移行タスク」を参照してください。
このコマンドライン・ツールは次のような名前のJavaクラスです。
oracle.rules.tools.migrator.MigrateRuleRepository
これはSOA Oracleホーム内の次のディレクトリにあります。
SOA_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jar
コマンドライン・ツールを実行するには、クラスパスに特定のJARファイル・セットが必要です。必要なJARファイルおよびライブラリのリストは、B.3.1項「Oracle Business Rules SDKを使用したディクショナリの移行方法」を参照してください。
たとえば、クラスパスを設定してLinux上で移行ツールを実行する手順は、次のとおりです。
> export CLASSPATH=required_jar_files > java -cp $CLASSPATH oracle.rules.tools.migrator.MigrateRuleRepository OPTIONS
次に、MigrateRuleRepositoryコマンドの例を示します。
MigrateRuleRepository -all
-origType FILE_REPO
-origLocation /scratch/MyRepository
-destLocation /scratch/MyMigratedDictionaries
-importedClasspath /scratch/foo.jar:/scratch/myclasses
-xsdDirectory /scratch/myschemas
-xsdGeneration /scratch/jaxb_classes
表B-1に、必須のMigrateRuleRepositoryコマンドライン引数を示します。表B-2に、オプションのMigrateRuleRepositoryコマンドライン引数を示します。表B-3に、WebDAVのMigrateRuleRepositoryコマンドライン引数を示します。
表B-1 MigrateRuleRepositoryの必須オプション
| オプション | 説明 |
|---|---|
|
|
左記の文字列のいずれかを指定して、元のリポジトリのタイプを指定します。 |
|
|
引数には、移行するディクショナリを含むリリース10.1.3.xリポジトリを指定します。これは、WebDAVリポジトリのURLかファイル・パスのいずれかの文字列を使用して指定します。 |
|
|
移行後のディクショナリの配置先となる宛先ディレクトリを指定します。移行後のディクショナリは、 例: dir-name/dest-pkg/dest-dict-name.xml
|
|
|
移行時にJavaファクト・タイプのインポートに使用するクラスパスを指定します。 |
|
|
XMLファクト・タイプ内で使用されるすべてのスキーマを含むスキーマ・ディレクトリを指定します。 |
|
|
スキーマのインポート時にJAXBクラスの生成先となるディレクトリを指定します。 |
|
|
元のリポジトリ内のすべてのディクショナリを移行します。
|
|
|
移行対象のディクショナリの名前を指定します。 |
|
|
移行対象のディクショナリのバージョンを指定します。 |
表B-2 任意のMigrateRuleRepositoryオプション
| オプション | 説明 |
|---|---|
|
|
移行結果のディクショナリをOracle Business Rules Oracle Fusion Middleware 11g リリース1 (11.1.1)形式で保存するときに使用するパッケージ名を指定します。移行後のディクショナリは、 |
|
|
Oracle Business Rules Oracle Fusion Middleware 11g リリース1 (11.1.1)形式の結果ディクショナリを保存するときに使用するディクショナリ名を指定します。移行後のディクショナリは、 |
表B-3 WebDAV専用のMigrateRuleRepositoryオプション
| オプション | 引数および説明 |
|---|---|
|
|
引数には、WebDAV認証情報を含むOracle Walletファイルを指定します。 |
|
|
プロキシが関係する場合、このオプションは必須です。必要であれば、引数にはWebDAVアクセス用プロキシとして使用するホストを指定します。 |
|
|
必要であれば、プロキシが関係する場合に、引数にはWebDAVアクセス用プロキシ・ホストで使用するポートを指定します。 |
MigrateRuleRepositoryプログラム関連インタフェースをOracle Business Rules SDKと一緒に使用します。通常の移行シナリオでは、手動移行タスクを実行する必要があることに注意してください。
JavaをOracle Business Rules SDKと同時に使用して移行するには、oracle.rules.tools.migrator.MigrateRuleRepositoryクラスを使用します。
次の例では、http://www.oracle.com/technology/products/ias/business_rules/index.htmlにあるサンプルのhow-to-rules-javaを使用してディクショナリを移行します。
Oracle Business Rules SDKを使用してディクショナリを移行する手順
図B-2に示すように、Oracle JDeveloperを開始します。これにより、Oracle JDeveloperの「開始」ページが表示されます。
アプリケーションが作成されていない場合は、アプリケーション・ナビゲータで「新規アプリケーション」 をクリックします。または、アプリケーションがすでに作成されている場合は、「アプリケーション」をクリックし、ドロップダウン・リストから「新規アプリケーション」をクリックします。
アプリケーションの作成ウィザードで、新規アプリケーションの名前と場所を入力します。
「アプリケーション名」フィールドで、アプリケーション名を入力します。たとえば、MigrateApplicationと入力します。
ディレクトリ名を入力するか参照します。または、デフォルトを受け入れます。
アプリケーション・パッケージ接頭辞を入力するか、またはデフォルトである接頭辞なしを受け入れます。
接頭辞はグローバルに一意の接頭辞である必要があり、通常は、会社が所有しているドメイン名になります。接頭辞に続いてピリオドが、アプリケーションの初期プロジェクト内に作成されたオブジェクトに付加されます。
この例では、接頭辞com.exampleを使用できます。
図B-3に示すように、Oracle Business Rulesプロジェクトに対して、アプリケーション・テンプレートとして「汎用アプリケーション」を選択します。
「次へ」をクリックします。
図B-4に示すように、汎用アプリケーションの作成ウィザードの「汎用プロジェクトの名前付け」で、新規プロジェクトの名前と場所を入力します。
「プロジェクト名」フィールドで、アプリケーション名を入力します。たとえば、MigrateProjectと入力します。
ディレクトリ名を入力するか参照します。または、デフォルトを受け入れます。
「プロジェクト・テクノロジ」タブの「選択可能」リストで、「Java」を選択し、「移動」をクリックして「選択済」領域に追加します。
「終了」をクリックします。
Oracle JDeveloperで、MigrateProjectという名前のプロジェクトを選択します。
右クリックし、ドロップダウン・リストから「プロジェクト・プロパティ」を選択します。
「ライブラリとクラスパス」アイテムを選択します。
「JAR/ディレクトリの追加」をクリックします。
次のJARファイルを含むようにプロジェクト・クラスパスを更新します。
ORACLE_HOMEディレクトリ内で、JDEV_HOMEと並んでJAVA_HOMEがインストールされている可能性がある点に留意してください。
JAVA_HOME/lib/tools.jar JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jar JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/rulesdk.jar JDEV_HOME/modules/oracle.adf.model_11.1.1/jr_dav.jar JDEV_HOME/modules/oracle.pki_11.1.1/oraclepki.jar JDEV_HOME/soa/modules/oracle.rules_11.1.1/rl.jar JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/webdavrc.jar
「アーカイブまたはディレクトリの追加」ダイアログで必要なJARファイルを選択し、図B-5に示すように「選択」をクリックします。
残りのJARファイルについてステップ10から繰り返します。
「ライブラリの追加」をクリックします。
次のライブラリをプロジェクト・クラスパスに追加する必要があります。
BC4Jクライアント
Oracle JDBC
Oracle Rules
Oracle XML Parser v2
JAX-RPCクライアント
図B-6に示すように「ライブラリの追加」ダイアログで必要なライブラリを選択し、「OK」をクリックします。
残りのライブラリについてステップ13から繰り返します。
「OK」をクリックします。
Oracle JDeveloperで、MigrateProjectという名前のプロジェクトを選択します。
右クリックし、ドロップダウン・リストから「新規」を選択します。
「新規ギャラリ」の「カテゴリ」領域で、「一般」を選択します。
「新規ギャラリ」の「項目」領域で、「Javaクラス」を選択します。
「OK」をクリックします。
図B-7に示すように、「Javaクラスの作成」ウィンドウで、次のプロパティを構成します。
「名前」の値としてMigrateを入力します。
「パッケージ」の値としてcom.exampleを入力します。
次のチェック・ボックスを選択します。
public
<なし>
スーパークラスからのコンストラクタ
mainメソッド
「OK」をクリックします。
例B-1に示すようなJavaクラスが表示されます。
MigrateRuleRepository APIを使用して、例B-2に示すようなコードを追加します。
MigrateRuleRepository APIの詳細は、B.4.3項「手動移行に関する必知事項」を参照してください。
例B-2 完成したMigrate.java
package com.example;
import java.io.PrintWriter;
import oracle.rules.tools.migrator.MigrateRuleRepository;
public class Migrate {
public Migrate() {
try {
// Create a migrator instance
MigrateRuleRepository conv = new MigrateRuleRepository();
// Set the output buffer
conv.setOutLog(new PrintWriter(System.out));
// Set input properties (SDK format)
conv.setOriginLocation("C:\\Temp\\how-to-rules-java\\dict\\CarRepository");
conv.setOriginType(MigrateRuleRepository.FILE_REPO);
conv.setOriginDictionaryName(MigrateRuleRepository.MIGRATE_ALL);
conv.setOriginVersionName(MigrateRuleRepository.MIGRATE_ALL);
conv.setImportedClassPath("C:\\Temp\\how-to-rules-java\\lib\\car.jar");
// Set output properties
conv.setDestinationLocation("C:\\Temp\\how-to-rules-java\\dict\\CarRepositorySDK2");
conv.migrate();
String results = conv.getTotalStats();
System.out.print(results);
}
catch (Exception e)
{
System.out.print(e);
}
}
public static void main(String[] args) {
Migrate migrate = new Migrate();
}
}
移行元のリポジトリにXMLファクト・タイプが含まれている場合は、そのXMLファクト・タイプを定義するスキーマ・ファイルの場所を指定するだけでなく、スキーマ・ファイルをJavaクラスに変換する際にJAXBが使用する出力ディレクトリも指定する必要があります。
このデモでは、XMLファクト・タイプがないため、次のコード行は必要ありません。
conv.setXSDLocation("C:\\Temp\\how-to-rules-java\\schemas"); // or other
directory, as appropriate
conv.setXSDOutputDirectory("C:\\Temp\\how-to-rules-java\\jaxbOutput"); // or
other directory, as appropriate
アプリケーション・ナビゲータでMigrate.javaを右クリックし、「メイク」を選択します。
アプリケーション・ナビゲータでMigrate.javaを右クリックし、「実行」を選択します。
エラーがないかどうか、「メッセージ - ログ」ウィンドウを調べます。
場合によっては、移行を完了するために、ルールを手動で編集する必要があります。
宛先位置から、移行後のディクショナリを取得します。
この例では、C:\Temp\how-to-rules-java\dict\CarRepositorySDK2から取得します。
MigrateRuleRepository APIの詳細は、Oracle Fusion Middleware Oracle Business RulesのJava APIリファレンスを参照してください。
例B-3に示すように、標準的な移行プログラムでは、MigrateRuleRepository APIを使用して次のものを設定します。
入力プロパティには、移行するディクショナリの特性を定義します。例B-3の移行プログラムでは、標準的な入力プロパティが設定されます。
例B-3 入力プロパティ
// Set input properties (SDK format) conv.setOriginLocation( "C:\\scratch\\SDK1_Repository" ); conv.setOriginType(MigrateRuleRepository.FILE_REPO); conv.setOriginDictionaryName(MigrateRuleRepository.MIGRATE_ALL); conv.setOriginVersionName(MigrateRuleRepository.MIGRATE_ALL);
MigrateRuleRepositoryメソッドを使用して、次の必須の入力プロパティを設定する必要があります。
setOriginLocation - 移行対象のルール・ディクショナリの完全修飾パスを指定します。
setOriginType - ルール・ディクショナリを含むリポジトリのタイプを指定します。次の定数のいずれかを選択できます。
MigrateRuleRepository.FILE_REPO: ルール・ディクショナリがホストのファイル・システムに単純なファイルとして格納されます。
MigrateRuleRepository.WEBDAV_REPO: ルール・ディクショナリがWebDAV管理リポジトリに格納されます。
setOriginDictionaryName - 移行対象として指定するルール・ディクショナリに含まれるディクショナリの名前を指定します。ディクショナリ名には、Stringとしての名前、または指定するディクショナリに含まれるすべてのディクショナリを移行する場合はMigrateRuleRepository.MIGRATE_ALLを指定します。
setOriginVersionName - 移行対象として指定するルール・ディクショナリのバージョンを指定します。ディクショナリのバージョンには、Stringとしてのバージョン、または指定するディクショナリのすべてのバージョンを移行する場合はMigrateRuleRepository.MIGRATE_ALLを指定します。
必要な場合は、この他のMigrateRuleRepositoryメソッドを使用してオプションの入力プロパティを定義することもできます。
出力プロパティでは、入力プロパティを指定している場合に、MigrateRuleRepositoryクラスの移行先となるOracle Fusion Middleware 11g リリース1 (11.1.1) Oracle Business Rulesディクショナリの特性を定義します(項B.3.2.1「入力プロパティ」を参照)。例B-4の移行プログラムでは、標準的な入力プロパティが設定されます。
例B-4 出力プロパティ
// Set output properties (SDK2 format) conv.setDestinationLocation( "C:\\scratch\\SDK2_Migrated_Dictionaries" );
MigrateRuleRepositoryメソッドを使用して、次の必須の出力プロパティを設定する必要があります。
setDestinationLocation - 新しいOracle Fusion Middleware 11g リリース1 (11.1.1) Oracle Business Rulesベースのルール・ディクショナリの完全修飾ファイル名を指定します。
必要な場合は、この他のMigrateRuleRepositoryメソッドを使用してオプションの出力プロパティを定義することもできます。
たとえば、デフォルトでは、新しいOracle Fusion Middleware 11g リリース1 (11.1.1) Oracle Business Rulesディクショナリは、元のディクショナリで使用されていたパッケージ名を使用します。この動作をオーバーライドするには、MigrateRuleRepositoryのメソッドsetDestinationPackageNameを使用して新しいパッケージ名を指定します。
Oracle Business Rulesリリース10.1.3.xで作成されたディクショナリを使用できるようにするには、そのディクショナリをOracle Fusion Middleware 11g リリース1 (11.1.1)に必要な形式に移行する必要があります。BPELプロセスのデシジョン・サービスに含まれているディクショナリを最も簡単に移行する方法として、JDeveloperを使用できます。あるいは、MigrateRuleRepositoryコマンドライン・ツールを使用して移行することもできます。移行シナリオによっては、手動移行タスクを実行する必要があります。
JAXB 2.0における重要なユーザビリティ上の改善点を利用できるようにするには、次の移行タスクを手動で実行する必要があります。
JAXB 1.0とJAXB 2.0の最も重要な違いは、生成されるクラスです。JAXB 1.0は、注釈がJava 1.5に導入される前に作成され、そのため一連のインタフェースと抽象クラスに依存しています。Oracle Business Rulesリリース10.1.3.xでは、デフォルトでJAXB 1.0を使用していました。Oracle Fusion Middleware 11g リリース1 (11.1.1)では、デフォルトでJAXB 2.0を使用します。Rules Designerでは、XMLスキーマをインポートするには、JAXB 2.0のみを使用できます。移行後のディクショナリは引き続きJAXB 1.0を使用しますが、スキーマの変更やJAXB 1.0としての再インポートはできません。
JAXB 1.0オブジェクトを使用する移行後のディクショナリも、Oracle Fusion Middleware 11g リリース1 (11.1.1)で動作します。ただし、JAXB 2.0では、重要な新機能および様々な改善を利用してOracle Business Rulesを使用できます。
例B-5に示すXSDフラグメントについて考えます。
例B-5 XSDフラグメント
<element name="foo">
<complexType>
<sequence>
<element name="bar" type="string"/>
<element name="baz" type="string"/>
</sequence>
</complexType>
</element>
この要素は、匿名の複合タイプを使用してデータ構造を定義しています。JAXB 1.0では次のクラスが生成されます。
FooType
Foo extends FooType, javax.xml.bind.Element
FooImpl extends FooTypeImpl implements Foo
FooTypeImpl extends oracle.xml.jaxb.JaxbNode implements FooType
これらのクラスのインスタンスを作成する唯一の手段は、ObjectFactoryの静的ファクトリ・メソッドです。
これに対して、JAXB 2.0で生成される単一の注釈付きクラスFooは、newメソッドまたはObjectFactoryメソッドのいずれを使用してもインスタンス化できます。
ルールの作成に使用されるファクト・タイプは、旧リリースではFooTypeであったのに対し、リリース11gではFooになりました。
ファクト・タイプFooTypeをFooに移行するには、次の手動移行タスクを実行します。
JAXB 1.0からJAXB 2.0に移行する手順
ルール・マイグレータ・ツールを使用して移行します。
詳細は、B.2項「ルール・マイグレータ・ツールを使用したOracle Business Rulesディクショナリの移行」を参照してください。
SCA-INF/classes内のすべてのクラスを削除します。
ルールで使用するすべてのファクト・タイプに割り当てられている別名を記録します。
たとえば、FooTypeファクトの別名「My Foo Type」を記録します。
JAXB 2.0にアップグレードするXMLファクト・タイプをデータ・モデルから削除します。
この操作を実行すると、削除するファクト・タイプの参照ごとに1つずつ、大量の検証警告が発生する可能性があります。
ただし、参照されるすべての要素のIDとString値に対する参照は、SDKにより保存されます。
参照のIDが設定されて存在している場合は、String値が現在の別名を反映するように更新されます。このため、ファクト・タイプの別名を変更すると、そのファクト・タイプが参照されるすべての場所で、参照のIDのために新しい値が取得されます。
このIDの要素がディクショナリから削除された場合でも、String値には参照された要素の最後の既知名が保持されます。これにより、たとえば、次のことができます。
別名「FactType1」のファクト・タイプを削除します。
新しいファクト・タイプをインポートします。
新しいファクト・タイプの別名を「FactType1」に設定します。削除されたファクト・タイプに対するすべての参照は、自動的に新しいファクト・タイプを参照するように変更されます。
スキーマをインポートします。
リリース11gでは、JAXB 2.0がデフォルトです。
ファクト・タイプの別名を以前の別名に設定します。
たとえば、Fooの別名をFooTypeに変更します。
ディクショナリに対する検証を実行します。
必要であれば、ファクト・タイプの別名を元の別名に設定します。
たとえば、別名FooTypeを再びFooに変更します。
参照がすべて更新されたことを確認します。
旧リリースでは、関数を作成する唯一の方法は、フリー・フォームのRLを作成することでした。この関数は生成されるRL名に依存していましたが、リリース11gで変更され、別名から自動的に計算されるようになったため、ユーザーが有効な名前を指定しなくても、関数がRLに準拠するようになりました。
アクションを使用することで、全体にアクセスする関数をリライトしてこの変更に準拠するようにできます。関数の作成は、アクションを使用すると設計時に関数が検証されるため、旧リリースよりも容易になりました。
Oracle Business Rules Release 10.1.3.xディクショナリでは、フリー・フォームのRL関数を含んでおり、データ・モデルにないJavaクラスの参照は一般的な方法でした。たとえば、多くのディクショナリには、ObjectFactoryを使用してJAXBクラスのインスタンスを作成する関数が含まれています。Oracle Fusion Middleware 11g リリース1 (11.1.1)では、このクラスはJAXB 2.0クラスとしてインポートされるため、スキーマを再インポートしてObjectFactoryをインポートするだけでは、このクラスをデータ・モデルに追加できません。この場合、ディクショナリの移行元となったプロジェクトの「classes」ディレクトリにあるObjectFactoryクラスを使用すると解決します。このObjectFactoryクラスはJavaクラスとしてインポートする必要があり、それにより、Oracle Fusion Middleware 11g リリース1 (11.1.1)の関数で参照できるようになります。
詳細は、B.4.3項「手動移行に関する必知事項」を参照してください。
RL関数を移行する手順は、次のとおりです。
フリー・フォームのRL関数ごとに、アクションを使用するRLをリライトします。
リリース11gでは、関数本体とルールの中でアクションを使用できます。ほとんどの場合にフリー・フォームの関数本体を不要にできる新しいアクション・フォームがいくつかあります。使用可能なアクション・フォームは次のとおりです。
Call
AssertおよびAssert new
Retract
AssignおよびAssign New
Modify
Synchronized
Expression
Assert
If、Else IfおよびElse
ForおよびWhile
Return、Throw、Try、CatchおよびFinally
RL
ディクショナリを検証します。
詳細は、『Oracle Fusion Middleware Oracle Business Rulesユーザーズ・ガイド』のデシジョン表検証の理解に関する項を参照してください。
旧リリースでは、XMLスキーマをインポートする唯一の方法はJAXB 1.0を使用することでした。リリース11gでは、Oracle Business RulesはJAXB 1.0をサポートしますが、デフォルトはJAXB 2.0です。引き続きJAXB 1.0を使用することを選択する場合、生成されたRLがMultipleInheritanceExceptionをスローする可能性があります。詳細は、『Oracle Fusion Middleware Oracle Business Rulesユーザーズ・ガイド』のJAXB 1.0ディクショナリおよびRL MultipleInheritanceExceptionに関する項を参照してください。
フリー・フォームのRL関数本体の検証チェックは、SDKでは行われません。このため、関数のエラーが存在していても、RLを実行しないかぎり明らかになりません。例B-6に、BPELプロセスにおけるこのようなエラーの例を示します。
例B-6 無効なRL関数の実行時エラー
[2008-10-01T04:52:15.043-07:00] [server_soa] [ERROR] [] [oracle.soa.services.rules] [tid: 35] [ecid:0000HmsG4oAEsHQ6ubV4EH18sYBt0000JA,0:2:100000051] [composite_name:ThreePattern] [component_name: CreditRatingRules] [component_instance_id:90558a4f-8781-4ac7-821c-49f46dd2f8fc] [composite_instance_id: 90033] <.>
Error caching the Decision Services metadata.[[
Error caching the decision services metadata for path
default/ThreePattern!1.0*c04f9ced-55ff-42fc-a6ee-f64a2055baf2/CreditRatingRules.
Check the underlying exception and correct the error. This is most likely due
to a rule modeling isssue. Validate the rule dictionary in rule designer and
fix any errors and warnings. Contact oracle support if error is not fixable.
ORABPEL-36109 Error caching the Decision Services metadata.
Error caching the decision services metadata for path default/ThreePattern!1.0*c04f9ced-55ff-42fc-a6ee-f64a2055baf2/CreditRatingRules.
Check the underlying exception and correct the error. This is most likely due to a rule modeling isssue. Validate the rule dictionary in rule designer and fix any errors and warnings. Contact oracle support if error is not fixable.
at oracle.bpel.services.rules.impl.DecisionServiceCache.cacheDecisionServiceMetadata(DecisionServiceCache.java:1039)
at
oracle.bpel.services.rules.impl.DecisionServiceCache.prepare(DecisionServiceCache.java:343)
at
oracle.bpel.services.rules.impl.DecisionServiceImpl.preProcess(DecisionServiceImpl.java:1164)
...
Caused by: oracle.rules.rl.exceptions.UndefinedException: symbol'CreditRatingRules.rating_param' is undefined at line 25 column 8 in main
at
oracle.rules.rl.exceptions.ExceptionFactory.createUndefinedException(ExceptionFactory.java:386)
at oracle.rules.rl.analyze.Expr.qname(Expr.java:1742)
at oracle.rules.rl.analyze.Expr.primary(Expr.java:814)
at oracle.rules.rl.analyze.Expr.expr(Expr.java:195)
...
