Rulesのディクショナリおよびプロジェクトをアップグレードする方法について説明します。Rulesのディクショナリおよびプロジェクトは旧リリースから移行できます。(11.1.1)で使用するには、ディクショナリを新しいディクショナリ形式に移行する必要があります。(11.1.1)に移行する移行パスは、リリース10.1.3.xディクショナリの作成方法に応じていくつかあります。この付録では、次の項目について説明します。(11.1.1)ディクショナリ形式に移行できます。JDeveloperを使用してディクショナリを移行する手順は、次のとおりです。JDeveloperを開始します。JDeveloperの「開始」ページが表示されます。「ファイル」メニューから「開く」を選択します。プロジェクトに移動し、「開く」を選択します。Manager移行ユーティリティが起動され、ルール・ディクショナリを含むプロジェクトが変換されます。ログ」ウィンドウを調べます。Designerにより手動で編集する必要があります。Rulesの手動移行タスク」を参照してください。「ファイル」メニューから「すべて保存」を選択します。(11.1.1)形式に移行できます。ほとんどの移行シナリオで、手動移行タスクを実行する必要があることに注意してください。(11.1.1)では更新されて、より強力な構成になったためです。Rulesの手動移行タスク」を参照してください。このコマンドライン・ツールは次のような名前のJavaクラスです。Oracleホーム内の次のディレクトリにあります。SOA_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jarコマンドライン・ツールを実行するには、クラスパスに特定のJARファイル・セットが必要です。SDKを使用したディクショナリの移行方法」を参照してください。クラスパスを設定してLinux上で移行ツールを実行する手順は、次のとおりです。OPTIONS次に、MigrateRuleRepositoryコマンドの例を示します。/scratch/jaxb_classes表B-1に、必須のMigrateRuleRepositoryコマンドライン引数を示します。表B-2に、オプションのMigrateRuleRepositoryコマンドライン引数を示します。表B-3に、WebDAVのMigrateRuleRepositoryコマンドライン引数を示します。WEBDAV_REPO}左記の文字列のいずれかを指定して、元のリポジトリのタイプを指定します。origin-repo引数には、移行するディクショナリを含むリリース10.1.3.xリポジトリを指定します。これは、WebDAVリポジトリのURLかファイル・パスのいずれかの文字列を使用して指定します。dir-name移行後のディクショナリの配置先となる宛先ディレクトリを指定します。移行後のディクショナリは、-destlocation、-destPackageNameおよび-destDictionaryName引数で構成されたディレクトリ構造に配置されます。例:dir-name/dest-pkg/dest-dict-name.xmlpkg-nameは、移行されて、dir-nameで作成されたディレクトリに配置されます。classpath移行時にJavaファクト・タイプのインポートに使用するクラスパスを指定します。schema-dirXMLファクト・タイプ内で使用されるすべてのスキーマを含むスキーマ・ディレクトリを指定します。jaxb-class-destinationスキーマのインポート時にJAXBクラスの生成先となるディレクトリを指定します。-all元のリポジトリ内のすべてのディクショナリを移行します。-allを使用するか、または-origDictionaryNameおよび-origVersionNameを指定します。origin-dict-allオプションとは併用しないでください。移行対象のディクショナリの名前を指定します。origin-version-allオプションとは併用しないでください。移行対象のディクショナリのバージョンを指定します。(11.1.1)形式で保存するときに使用するパッケージ名を指定します。移行後のディクショナリは、-destlocation、-destPackageNameおよび-destDictionaryName引数で構成されたディレクトリ構造に配置されます。(11.1.1)形式の結果ディクショナリを保存するときに使用するディクショナリ名を指定します。移行後のディクショナリは、-destlocation、-destPackageNameおよび-destDictionaryName引数で構成されたディレクトリ構造に配置されます。Walletファイルを指定します。webdav-proxy-hostプロキシが関係する場合、このオプションは必須です。必要であれば、引数にはWebDAVアクセス用プロキシとして使用するホストを指定します。webdav-proxy-port必要であれば、プロキシが関係する場合に、引数にはWebDAVアクセス用プロキシ・ホストで使用するポートを指定します。SDKと一緒に使用します。通常の移行シナリオでは、手動移行タスクを実行する必要があることに注意してください。SDKと同時に使用して移行するには、oracle.rules.tools.migrator.MigrateRuleRepositoryクラスを使用します。次の例では、http://www.oracle.com/technology/products/ias/business_rules/index.htmlにあるサンプルのhow-to-rules-javaを使用してディクショナリを移行します。JDeveloperを開始します。JDeveloperの「開始」ページが表示されます。アプリケーションがすでに作成されている場合は、「アプリケーション」をクリックし、ドロップダウン・リストから「新規アプリケーション」をクリックします。アプリケーションの作成ウィザードで、新規アプリケーションの名前と場所を入力します。「アプリケーション名」フィールドで、アプリケーション名を入力します。MigrateApplicationと入力します。ディレクトリ名を入力するか参照します。デフォルトを受け入れます。アプリケーション・パッケージ接頭辞を入力するか、またはデフォルトである接頭辞なしを受け入れます。接頭辞はグローバルに一意の接頭辞である必要があり、通常は、会社が所有しているドメイン名になります。接頭辞に続いてピリオドが、アプリケーションの初期プロジェクト内に作成されたオブジェクトに付加されます。この例では、接頭辞com.exampleを使用できます。Rulesプロジェクトに対して、アプリケーション・テンプレートとして「汎用アプリケーション」を選択します。「次へ」をクリックします。図B-4に示すように、汎用アプリケーションの作成ウィザードの「汎用プロジェクトの名前付け」で、新規プロジェクトの名前と場所を入力します。「プロジェクト名」フィールドで、アプリケーション名を入力します。MigrateProjectと入力します。ディレクトリ名を入力するか参照します。デフォルトを受け入れます。「プロジェクト・テクノロジ」タブの「選択可能」リストで、「Java」を選択し、「移動」をクリックして「選択済」領域に追加します。「終了」をクリックします。JDeveloperで、MigrateProjectという名前のプロジェクトを選択します。右クリックし、ドロップダウン・リストから「プロジェクト・プロパティ」を選択します。「ライブラリとクラスパス」アイテムを選択します。「JAR/ディレクトリの追加」をクリックします。次のJARファイルを含むようにプロジェクト・クラスパスを更新します。ORACLE_HOMEディレクトリ内で、JDEV_HOMEと並んでJAVA_HOMEがインストールされている可能性がある点に留意してください。JAVA_HOME/lib/tools.jarJDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jarJDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/rulesdk.jarJDEV_HOME/modules/oracle.adf.model_11.1.1/jr_dav.jarJDEV_HOME/modules/oracle.pki_11.1.1/oraclepki.jarJDEV_HOME/soa/modules/oracle.rules_11.1.1/rl.jarJDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/webdavrc.jar「アーカイブまたはディレクトリの追加」ダイアログで必要なJARファイルを選択し、図B-5に示すように「選択」をクリックします。残りのJARファイルについてステップ10から繰り返します。「ライブラリの追加」をクリックします。次のライブラリをプロジェクト・クラスパスに追加する必要があります。v2JAX-RPCクライアント図B-6に示すように「ライブラリの追加」ダイアログで必要なライブラリを選択し、「OK」をクリックします。残りのライブラリについてステップ13から繰り返します。「OK」をクリックします。JDeveloperで、MigrateProjectという名前のプロジェクトを選択します。右クリックし、ドロップダウン・リストから「新規」を選択します。「新規ギャラリ」の「カテゴリ」領域で、「一般」を選択します。「新規ギャラリ」の「項目」領域で、「Javaクラス」を選択します。「OK」をクリックします。図B-7に示すように、「Javaクラスの作成」ウィンドウで、次のプロパティを構成します。「名前」の値としてMigrateを入力します。「パッケージ」の値としてcom.exampleを入力します。次のチェック・ボックスを選択します。「OK」をクリックします。例B-1に示すようなJavaクラスが表示されます。APIを使用して、例B-2に示すようなコードを追加します。APIの詳細は、B.4.3項「手動移行に関する必知事項」を参照してください。}}移行元のリポジトリにXMLファクト・タイプが含まれている場合は、そのXMLファクト・タイプを定義するスキーマ・ファイルの場所を指定するだけでなく、スキーマ・ファイルをJavaクラスに変換する際にJAXBが使用する出力ディレクトリも指定する必要があります。このデモでは、XMLファクト・タイプがないため、次のコード行は必要ありません。appropriateアプリケーション・ナビゲータでMigrate.javaを右クリックし、「メイク」を選択します。アプリケーション・ナビゲータでMigrate.javaを右クリックし、「実行」を選択します。ログ」ウィンドウを調べます。場合によっては、移行を完了するために、ルールを手動で編集する必要があります。宛先位置から、移行後のディクショナリを取得します。この例では、C:\Temp\how-to-rules-java\dict\CarRepositorySDK2から取得します。APIリファレンスを参照してください。APIを使用して次のものを設定します。入力プロパティ入力プロパティには、移行するディクショナリの特性を定義します。例B-3の移行プログラムでは、標準的な入力プロパティが設定されます。);conv.setOriginType(MigrateRuleRepository.FILE_REPO);conv.setOriginDictionaryName(MigrateRuleRepository.MIGRATE_ALL);conv.setOriginVersionName(MigrateRuleRepository.MIGRATE_ALL);MigrateRuleRepositoryメソッドを使用して、次の必須の入力プロパティを設定する必要があります。移行対象のルール・ディクショナリの完全修飾パスを指定します。ルール・ディクショナリを含むリポジトリのタイプを指定します。次の定数のいずれかを選択できます。ルール・ディクショナリがホストのファイル・システムに単純なファイルとして格納されます。ルール・ディクショナリがWebDAV管理リポジトリに格納されます。移行対象として指定するルール・ディクショナリに含まれるディクショナリの名前を指定します。ディクショナリ名には、Stringとしての名前、または指定するディクショナリに含まれるすべてのディクショナリを移行する場合はMigrateRuleRepository.MIGRATE_ALLを指定します。移行対象として指定するルール・ディクショナリのバージョンを指定します。ディクショナリのバージョンには、Stringとしてのバージョン、または指定するディクショナリのすべてのバージョンを移行する場合はMigrateRuleRepository.MIGRATE_ALLを指定します。必要な場合は、この他のMigrateRuleRepositoryメソッドを使用してオプションの入力プロパティを定義することもできます。Rulesディクショナリの特性を定義します(項B.3.2.1「入力プロパティ」を参照)。例B-4の移行プログラムでは、標準的な入力プロパティが設定されます。);MigrateRuleRepositoryメソッドを使用して、次の必須の出力プロパティを設定する必要があります。Rulesベースのルール・ディクショナリの完全修飾ファイル名を指定します。必要な場合は、この他のMigrateRuleRepositoryメソッドを使用してオプションの出力プロパティを定義することもできます。Rulesディクショナリは、元のディクショナリで使用されていたパッケージ名を使用します。この動作をオーバーライドするには、MigrateRuleRepositoryのメソッドsetDestinationPackageNameを使用して新しいパッケージ名を指定します。(11.1.1)に必要な形式に移行する必要があります。BPELプロセスのデシジョン・サービスに含まれているディクショナリを最も簡単に移行する方法として、JDeveloperを使用できます。MigrateRuleRepositoryコマンドライン・ツールを使用して移行することもできます。移行シナリオによっては、手動移行タスクを実行する必要があります。2.0における重要なユーザビリティ上の改善点を利用できるようにするには、次の移行タスクを手動で実行する必要があります。2.0の最も重要な違いは、生成されるクラスです。1.5に導入される前に作成され、そのため一連のインタフェースと抽象クラスに依存しています。1.0を使用していました。2.0のみを使用できます。1.0としての再インポートはできません。(11.1.1)で動作します。Rulesを使用できます。例B-5に示すXSDフラグメントについて考えます。</element>この要素は、匿名の複合タイプを使用してデータ構造を定義しています。1.0では次のクラスが生成されます。FooTypeこれらのクラスのインスタンスを作成する唯一の手段は、ObjectFactoryの静的ファクトリ・メソッドです。2.0で生成される単一の注釈付きクラスFooは、newメソッドまたはObjectFactoryメソッドのいずれを使用してもインスタンス化できます。ルールの作成に使用されるファクト・タイプは、旧リリースではFooTypeであったのに対し、リリース11gではFooになりました。ファクト・タイプFooTypeをFooに移行するには、次の手動移行タスクを実行します。2.0に移行する手順ルール・マイグレータ・ツールを使用して移行します。Rulesディクショナリの移行」を参照してください。SCA-INF/classes内のすべてのクラスを削除します。ルールで使用するすべてのファクト・タイプに割り当てられている別名を記録します。Type」を記録します。2.0にアップグレードするXMLファクト・タイプをデータ・モデルから削除します。この操作を実行すると、削除するファクト・タイプの参照ごとに1つずつ、大量の検証警告が発生する可能性があります。参照されるすべての要素のIDとString値に対する参照は、SDKにより保存されます。参照のIDが設定されて存在している場合は、String値が現在の別名を反映するように更新されます。このため、ファクト・タイプの別名を変更すると、そのファクト・タイプが参照されるすべての場所で、参照のIDのために新しい値が取得されます。このIDの要素がディクショナリから削除された場合でも、String値には参照された要素の最後の既知名が保持されます。これにより、たとえば、次のことができます。別名「FactType1」のファクト・タイプを削除します。新しいファクト・タイプをインポートします。新しいファクト・タイプの別名を「FactType1」に設定します。削除されたファクト・タイプに対するすべての参照は、自動的に新しいファクト・タイプを参照するように変更されます。スキーマをインポートします。2.0がデフォルトです。ファクト・タイプの別名を以前の別名に設定します。Fooの別名をFooTypeに変更します。ディクショナリに対する検証を実行します。必要であれば、ファクト・タイプの別名を元の別名に設定します。別名FooTypeを再びFooに変更します。参照がすべて更新されたことを確認します。旧リリースでは、関数を作成する唯一の方法は、フリー・フォームのRLを作成することでした。この関数は生成されるRL名に依存していましたが、リリース11gで変更され、別名から自動的に計算されるようになったため、ユーザーが有効な名前を指定しなくても、関数がRLに準拠するようになりました。アクションを使用することで、全体にアクセスする関数をリライトしてこの変更に準拠するようにできます。関数の作成は、アクションを使用すると設計時に関数が検証されるため、旧リリースよりも容易になりました。10.1.3.xディクショナリでは、フリー・フォームのRL関数を含んでおり、データ・モデルにないJavaクラスの参照は一般的な方法でした。多くのディクショナリには、ObjectFactoryを使用してJAXBクラスのインスタンスを作成する関数が含まれています。2.0クラスとしてインポートされるため、スキーマを再インポートしてObjectFactoryをインポートするだけでは、このクラスをデータ・モデルに追加できません。この場合、ディクショナリの移行元となったプロジェクトの「classes」ディレクトリにあるObjectFactoryクラスを使用すると解決します。(11.1.1)の関数で参照できるようになります。詳細は、B.4.3項「手動移行に関する必知事項」を参照してください。RL関数を移行する手順は、次のとおりです。フリー・フォームのRL関数ごとに、アクションを使用するRLをリライトします。リリース11gでは、関数本体とルールの中でアクションを使用できます。ほとんどの場合にフリー・フォームの関数本体を不要にできる新しいアクション・フォームがいくつかあります。使用可能なアクション・フォームは次のとおりです。IfおよびElseForおよびWhileReturn、Throw、Try、CatchおよびFinallyRLディクショナリを検証します。Rulesユーザーズ・ガイド』のデシジョン表検証の理解に関する項を参照してください。1.0を使用することでした。1.0を使用することを選択する場合、生成されたRLがMultipleInheritanceExceptionをスローする可能性があります。MultipleInheritanceExceptionに関する項を参照してください。フリー・フォームのRL関数本体の検証チェックは、SDKでは行われません。このため、関数のエラーが存在していても、RLを実行しないかぎり明らかになりません。例B-6に、BPELプロセスにおけるこのようなエラーの例を示します。reserved.法律上の注意点ライブラリ。