11gにアップグレードする際に重要な追加情報について説明します。Suite、WebCenterおよびADFアプリケーションのアップグレードの概要」で説明しています。SOAアプリケーションのアップグレードのみに該当するタスクについて説明します。Suiteアプリケーションを11gにアップグレードする前に、外部パートナが(リモートWebサービスの形態で)稼働していて使用可能であることを確認する必要があります。Busの各サービスにアクセスできることが必要です。アクセスできない場合、アプリケーション内のプロジェクトを11gに正しく移行できません。Suiteアプリケーションの各プロジェクトを調査する必要があります。Manager構成ファイルを確認し、これらの構成ファイルから参照されているWebサービスのURIが有効で稼働していることを確認します。11gへの自動アップグレードが試行されます。JDeveloper移行ウィザードで自動的に実行できるタスクには制限があります。Suiteアプリケーションで必要となる可能性のある手動タスクのタイプについては、この章の該当する項を参照してください。(10.1.3)を使用することをお薦めします。JDeveloperは常に同時にインストールを更新して、これらのOracle製品を同じバージョンで実行するようにしてください。SOAコンポジット・エディタ拡張機能がインストールされている必要があります。JDeveloperの「ヘルプ」メニューから「バージョン情報」を選択し、「バージョン」タブをクリックします。コンポーネントのリストに「SOAコンポジット・エディタ」というエントリが表示されます。「バージョン情報」ダイアログ・ボックスの「バージョン」タブにこのコンポーネントが表示されない場合は、「バージョン情報」ダイアログを閉じて、「ヘルプ」メニューから「更新の確認」を選択します。更新の確認ウィザードを使用して、最新バージョンの「SOAコンポジット・エディタ」拡張機能を検索し、インストールします。EEアップグレード・ガイド』を参照してください。Serverへのアップグレードに関する情報が記載されています。EEアップグレード・ガイド』に記載されている手順と推奨事項に従ってJavaコードを確認してください。11gにアップグレードする際には、次の説明を参照してください。Suiteアプリケーションで使用できるAPIを示しています。11gにおける変更のサマリーと、各APIを使用するアプリケーションのアップグレードに関する詳細の参照先が記載されています。11g用に更新されましたが、新しい11gバージョンは10gと下位互換性があります。11g用に更新されましたが、新しい11gバージョンは10gと下位互換性があります。APIへのアップグレード」を参照してください。APIへのアップグレード」を参照してください。APIへのアップグレード」を参照してください。APIへのアップグレードに関する手順を説明します。RulesのSDKとAPIが大幅に改善されています。10gでは、開発者は、リポジトリへのアクセスとRuleSessionインスタンスの作成および使用を手動で管理する必要がありました。APIとデジション関数機能により、ルールの定義と実行を容易にするインタフェースと実装が提供されます。Rulesユーザーズ・ガイド』を参照してこれらの新機能の使用方法を確認してください。SDKに直接変換する方法を示します。ここで説明するすべてのクラスは、rulesdk2.jarファイルに格納されており、oracle.rules.sdk2パッケージの下にあります。10gでは、アプリケーション開発者は、アプリケーションの開発中にはファイルベースのリポジトリを使用し、本番環境でWebDAVリポジトリの使用に切り替えるのが一般的でした。11gでは、MDSにデプロイ可能な形式にパッケージ化する前に、ルール・ディクショナリ・ファイルに直接アクセスできます。次の例では、10gで開発モードでディクショナリにアクセスするために必要なコード(例9-1)と、11gで必要なコード(例9-2)を比較します。APIを使用してください。10gでは、推奨される本番リポジトリはWebDAVでした。11gでは、WebDAVはサポートされなくなり、メタデータ・サービス(MDS)が推奨リポジトリになります。ディクショナリの名前とバージョンは、(Javaクラスのネーミング方式と同様に)パッケージと名前に置き換えられました。10gのバージョンでは、真のバージョニングは提供されませんでした。11gでは、バージョンを指定する方法として単に名前を変更します。名前がfoo.bar.MyDict、バージョンが2の10gのディクショナリは、11gではfoo.barとしてパッケージ化され、MyDict2という名前が付きます。次の例では、10gで本番モードでディクショナリにアクセスするために必要なコード(例9-3)と、11gで必要なコード(例9-4)を比較します。10gでRLコードを生成するために必要なコードを示しています。11gでも、このコードは同じです。JDKを使用することをお薦めします。JRockitを使用している場合、アップグレード・プロセスが停止してしまいます。10gで提供されていたいくつかのAPIを置換する、新しいインフラストラクチャ管理APIが導入されています。Middlewareリリース・ノート』を参照してください。11gでアプリケーションを開いてアップグレードするときに、これらの参照は自動的にアップグレードされない可能性があることに注意してください。11gの「プロジェクト・プロパティ」ダイアログで「ライブラリとクラスパス」リンクを選択して、不足している参照を追加してください。Webサービス用のプロキシ設定を必要とするアプリケーションのアップグレード会社のファイアウォールの外にあるWebサービス・リソースを使用するアプリケーションをアップグレードする場合は、アップグレード・プロセスがプロキシ設定にアクセスしてアプリケーションのアップグレード中に適切な調整を行えるように、構成ファイルを変更する必要があります。11gを構成する手順は、次のとおりです。JDEV_HOME/binディレクトリで、次のファイルを検索します。ant-sca-upgrade.xmlファイルを編集し、次の設定を変更して、アップグレードするアプリケーションのWebサービス・アドレスを解決するために必要なプロキシ・サーバーとポートを識別できるようにします。value="-Dhttp.proxyPort=PROXY_PORT"/>これらの設定を変更する場所は、ファイル内に2つあります。Managerプロジェクトをアップグレードする場合に使用する場所です。11gでアプリケーションを開いてアップグレードします。11gでアプリケーションを開いてアップグレードする場合、アプリケーションのプロジェクトに関連付けられているbuild.xmlファイルとbuild.propertiesファイルはアップグレードされません。11gでこれらのファイルを再作成する必要があります。(UDDI)レジストリに登録されているリモート・リソースを使用する場合に重要です。詳細は、次の各項を参照してください。(10.1.3)のプロジェクトがOSRのserviceKeyを使用するエンドポイントURLを参照している場合は、アプリケーションをアップグレードする際に、エンドポイントURLが使用可能であることを確認する必要があります。ないと、アプリケーションのアップグレードは失敗します。このような失敗を回避するために、エンドポイントURLが使用可能であることを確認し、必要に応じて、bpel.xmlまたはルーティング・サービスでアクセス可能な新しいURLを指し示すようにエンドポイントURLを変更してください。Busのプロジェクトは、uddiプロトコルを使用してOSRからリソース参照を取得していました。Mediatorのプロジェクトはorauddiプロトコルを使用します。Busのプロジェクトをアップグレードする前に、次のことを実行する必要があります。11gでサポートされる新しいバインディングを使用するようにします。OSRで次の手順を実行します。Registryにログインします。「検索」タブで、「ビジネス」をクリックします。「名前の追加」をクリックして、名前別にビジネスを検索します。検索結果で、変更するビジネスの名前をクリックします。「ビジネスの表示」ページの左側のペインで、変更するサービスを右クリックし、コンテキスト・メニューから「バインディングの追加」を選択します。「バインディングの追加」ページの「タイプ」ドロップダウン・メニューから「wsdlDeployment」を選択します。「アクセス・ポイント」フィールドにURLを入力します。例:http://machine:port/Proj_ep?WSDL/「バインディングの追加」をクリックします。「変更の保存」をクリックします。11gで、アプリケーションを開いてアップグレードします。JDeveloperで、アップグレードしたプロジェクトのcomposite.xmlファイルを編集し、リソース・パレットの「UDDIレジストリ」オプションを使用してエンドポイントURLを構成します。UDDIレジストリの詳細は、次のURLを参照してください。11gでアプリケーションを開いてアップグレードする場合、アプリケーション・プロジェクトのカスタムXPath関数は、自動的にアップグレードされません。このため、アプリケーションをアップグレードした後、すべてのXPath関数クラスをサーバーのクラスパスにコピーし、サーバーの構成ファイルに関数を登録する必要があります。JDeveloperの移行ウィザードではサーバー情報を想定できないため、このステップは手動で行う必要があります。Suite開発者ガイド』のユーザー定義XPath拡張関数の作成に関する項を参照してください。11gのメディエータでのユーザー名とパスワードの動的割当ての理解この項では、10gと11gで、ユーザー名とパスワードを動的に割り当てる方法を比較します。10gでは、国コードでドメイン値マップ(DVM)を検索し、ユーザーIDとパスワードを取得して、これをHTTP認証に動的に指定します。11gでは、ユーザー名(javax.xml.ws.security.auth.username)とパスワード(javax.xml.ws.security.auth.password)を設定するか、正規化されたメッセージ・プロパティとして、既存のCSF資格証明を指すcsf-keyを設定する必要があります。これらは、ディスパッチ・リクエスト・プロパティとしてJAX-WSディスパッチ・レイヤーに渡されます。csf-keyを設定する方法は最も安全な方法です。11gでWS-Securityを使用している場合は、メディエータでの割当てを使用してsoapヘッダーを設定できます。(OWSM)では、動的ユーザーIDとパスワードはサポートされていません。11gのファイル命名規則の理解SOAコンポジット・アプリケーションをアップグレードする前に、アプリケーションまたはプロジェクトの名前が数字で始まらないことを確認してください。JDeveloperではcomposite.xmlを開こうとしたときに構文検証エラーが表示されます。この問題を回避するには、アプリケーションをアップグレードする前に、アプリケーションの名前を変更して番号を削除します。Suiteコマンドライン・アップグレード・ツールの使用方法について説明します。Suiteコマンドライン・アップグレード・ツールには、次の利点があります。コマンドライン・ツールを使用して、スクリプトまたはその他のコマンドライン自動化ツールによりアプリケーションのアップグレード作業を自動化できます。11gにアップグレードされます。コマンドライン・ツールを使用して、複数のBPELプロジェクトをマージして単一コンポジットを作成できます。JDeveloperの移行ウィザードでは実行できません。JDeveloperと同じコードベースが使用されているため、SOAプロジェクト・コンテンツの処理に関する機能はJDeveloperモードとまったく同じです。JDeveloperの移行ウィザードと互換性があります(いくつかの制限はあります)。JDeveloperに移動することもできます。両方のツールを使用して機能の制限を回避することもできます。コマンドライン・ツールでは、SOAプロジェクト・アーチファクトのみがアップグレードされることに注意してください。JDeveloperのアーチファクト(.jpr、.jwsファイルなど)は無視されます。この制限を回避するために、次の点に留意してください。Suiteコマンドライン・アップグレード・ツールは、BPELスーツケース・ディレクトリ(BPELサブディレクトリまたはBPELファイルをホストするディレクトリ)からコマンドラインで指定されたターゲット・ディレクトリにファイルをコピーします。このコピー・アクションでは、.jprまたは.jwsファイルはコピーされません。アップグレード後のターゲット・ディレクトリには、アップグレードされたSOAプロジェクト・コンテンツのみが格納されています。JDeveloperでこの問題を解決するには、新しいアプリケーションまたは新しいプロジェクトを作成し、新たにアップグレードされたコンポジット・ディレクトリをプロジェクト・ディレクトリとして定義します。Workflowプロジェクトを含むアプリケーションをアップグレードする場合は、アップグレードされたタスク・フォームごとに個別のプロジェクトが作成されることに注意してください。JDeveloperデプロイメントをサポートしていません。11gで開いて、JDeveloperからデプロイする必要があります。Suiteコマンドライン・アップグレード・ツールの使用方法」を参照してください。11gのインストール時に自動的にインストールされます。SuiteのOracleホームのbinディレクトリにインストールされます。JDeveloperホームのbinディレクトリにインストールされます。SOAプロジェクトを11gに移行できます。Suiteコマンドライン・アップグレード・ツールを実行していると想定しています。JDeveloperホームから実行している場合は、次の手順のORACLE_HOMEをJDEV_HOMEに置換してください。Antプロジェクトを使用するには、次の手順を実行します。Oracleホームへのパスとして定義されるようにORACLE_HOME環境変数を設定します。次のスクリプトを実行して、コマンドライン・ツールで必要な他の環境変数を設定します。ORACLE_HOME/bin/soaversion.shWindowsシステムの場合ORACLE_HOME\bin\soaversion.cmd次のようにAntプロジェクトを実行します。Suiteコマンドライン・アップグレード・ツールを使用する例は、例9-5および例9-6を参照してください。各コマンドライン引数の説明は、表9-2を参照してください。アップグレードの完了後、移行されたソースを検証するSCAコンパイラ(ant-sca-compile.xml)を実行します。SCAアップグレードでは、どのような場合でもすべてのアーチファクトが生成されるわけではないため、SCAコンパイラによってエラーまたは警告が生成され、その修正方法が示されます。詳細については、SCAコンパイラを確認してください。SCAコンパイラからクリーン・パスを取得した後、ant-sca-package.xmlツールを使用してアプリケーションをパッケージ化します。次に、ant-sca-deploy.xmlを使用してアプリケーションをデプロイできます。デプロイメントの後、サーバーでプロジェクトをテストできます。ここから、アプリケーション・プロジェクトを容易に確認、検証、および必要に応じて更新できます。Suiteコマンドライン・アップグレード・ツールの使用方法」を参照してください。10gプロジェクト・ファイルが格納されているディレクトリの完全修飾名およびパス。Managerプロジェクトの場合は、bpelフォルダになります。bpelフォルダをホストする親ディレクトリです。Busプロジェクト・フォルダになります。-Dtargetアップグレードされたプロジェクト・ファイルを含むディレクトリの完全修飾名およびパス。Managerプロジェクト・ファイルをアップグレードし、この引数で指定されているターゲット・ディレクトリのサブディレクトリに、新しいアップグレードされたファイルを生成します。Suiteコマンドライン・アップグレード・ツールはこの値を使用して、ターゲット・ディレクトリ内にアプリケーションのサブディレクトリを作成します。その後、アップグレードされたファイルをアプリケーションのサブディレクトリにコピーします。-Drevisionリビジョン番号。デフォルト値は1.0です。bpel_or_mediator_identifier次の2つの値のいずれかになります。Managerプロジェクトを識別します。Busプロジェクトを識別します。Managerプロジェクトをアップグレードすると想定されます。Suiteコマンドライン・アップグレード・ツールを実行する場合は、次の点に注意してください。sourceDirディレクトリとtargetDirディレクトリが同じディレクトリの場合、コマンドライン・アップグレード・ツールにより移行前にディレクトリのバックアップが自動的に作成されます。アップグレードを再実行する必要がある場合は、バックアップ・ディレクトリを使用してソース・ファイルをリストアできます。バックアップ・ディレクトリは、名前に.backupという接尾辞が付いています。sourceDirディレクトリとtargetDirディレクトリが異なる場合、移行中にsourceDir内のファイルは変更されないため、バックアップ・ディレクトリは作成されず、不要になります。アップグレード後、次の出力ディレクトリにログが作成されます。Suiteコマンドライン・アップグレード・ツールを使用して、複数のBPELプロジェクトをマージして単一コンポジットを作成できます。JDeveloperの移行ウィザードでは実行できません。複数のBPELプロジェクトを単一コンポジットに組み合せるには、コマンドラインで-Dsourceプロパティの一部として複数のソース・ディレクトリを指定します。パス・セパレータには、コロン(:)またはセミコロン(;)を使用できます。セパレータは、プラットフォームのローカル表記規則に変換されます。ガイドラインとして、二重引用符を使用して複数のソース・ディレクトリを識別すると、Antにより予期しない方法で入力が解析されるのを回避できます。指定された最初のソース・ディレクトリは11gプロジェクトのルートとみなされ、これによりコンポジット名が決定されます。コンポジット・サービスとして公開されます。マージ機能を使用する際には、各プロジェクトが関連していることが推奨されます。プロジェクトのマージは、BPELプロジェクトに対してのみサポートされます。ESBプロジェクトを他のBPELプロジェクトまたは他のESBプロジェクトとマージすることはできません。11gにアップグレードすることもできます。Suiteコマンドライン・アップグレード・ツールを使用したBPELまたはESBプロジェクトのアップグレード」に記載されている説明に従いますが、mediator引数を次のように使用してください。10gのプロジェクトでドメイン値マップ(DVM)または相互参照を使用する場合は、次の点に留意してください。10gにアップグレードされます。Busリポジトリに保存されているドメイン値マップと相互参照をアップグレードするには、手動でアップグレード・タスクを実行する必要があります。11gのメタデータ・サービス(MDS)リポジトリに移動します。Middleware管理者ガイド』のMDSリポジトリの管理に関する項を参照してください。ESBリポジトリにある10gのドメイン値マップをアップグレードするには、次のタスクを実行します。BusのOracleホームに変更します。エクスポート・スクリプトを使用して、メタデータをZIPファイルにエクスポートします。UNIXシステムの場合は次のスクリプトを使用します。SuiteアーカイブJARファイルを生成します。11gのOracleホームに変更します。次のコマンドを使用して、SOAアーカイブ・ファイルを生成します。このファイルは、自動的にsca_XrefDvmFiles10g_rev1.0.jarという名前になります。11gを起動して、新しいアプリケーションを作成します。Suiteアーカイブを新しいSOAプロジェクトにインポートします。11gの「ファイル」メニューから「インポート」を選択し、「SOAアーカイブをSOAプロジェクトへ」を選択します。「SOAアーカイブからのSOAプロジェクトの作成」ダイアログ・ボックスで、左側のナビゲーション・ツリーの「JARオプション」を選択し、「参照」をクリックして、この手順で以前に作成したsca_XrefDvmFiles10g_rev1.0.jarファイルを検索します。左側のナビゲーション・ツリーの「ファイル・グループ」→「プロジェクトの出力」を選択し、「アーカイブのターゲット・ディレクトリ」フィールドにXrefDvmFiles10gと入力します。「OK」をクリックして、XrefDvmFiles10gという名前の新しいSOAプロジェクトを作成します。新しいプロジェクトは、空のコンポジットと、アップグレードされたXRefおよびDVMファイルで構成されています。SOAインフラストラクチャにデプロイします。JDeveloperにおける複数のSOAコンポジット・アプリケーションをまたいだ共有データのデプロイ方法と使用方法に関する項を参照してください。11gを使用して、XrefDvmFiles10gプロジェクトのエントリを変更できます。変更を行うたびに、同じデプロイメント・プロセスを使用して、変更内容を適切なMDSリポジトリに転送する必要があります。11gで使用するようにアップグレードできます。11gのXREFデータベース・スキーマ表(XREF_DATA)が変更されたため必要です。XREFデータを修正します。11gデータは、別のOracleデータベースにあると想定しています。このシナリオは、アウトオブプレース・データ・アップグレードと呼ばれます。詳細は、次の各項を参照してください。11gにアップグレードする手順は、次のとおりです。10gから11gへのデータ・アップグレード・ユーティリティを検索し、ローカル・ディレクトリに解凍します。Middlewareのリポジトリ作成ユーティリティ(RCU)・アーカイブ・ファイルをダウンロードして解凍した場合は、次のディレクトリにあります。10gデータが格納されている2つ目のデータベースにアクセスするためのデータベース・リンクを作成します。(port=10g_db_listening_port))(connect_data=(sid=10g_db_SID)))'前述の例では、XREFデータが格納されているデータベースへの接続に必要な情報により、イタリック体で表示されている値を置換します。10gから11gへのデータ・アップグレード・ユーティリティを解凍したローカル・フォルダ内に作成されたディレクトリを次のサブディレクトリに変更します。XREF10gto11gDataUpgradeUtility/scriptsテキスト・エディタを使用して次のSQLファイルを開きます。Upgrade10gXrefTo11gXref.sqlファイルの内容を、次のように編集します。JDeveloperにおける複数のSOAコンポジット・アプリケーションをまたいだ共有データのデプロイ方法と使用方法に関する項を参照してください。必要に応じて、commitperbatchパラメータのデフォルト値を変更します(デフォルトは2000)。このパラメータには、移行中にバッチごとにコミットされたレコードの数を指定します。XREFをホストするOracleデータベースにXREFユーザーとしてログインし、次のように入力します。on;@Upgrade10gXrefTo11gXref.sqlこれらのコマンドによりデータはアップグレードされ、アップグレードの進捗状況がサーバー出力ログとして表示されます。ログをファイルにスプールできます。XREFデータが11gスキーマに準拠していない場合、またはアップグレード・プロセス中にエラーまたは例外が発生した場合は、破損したレコードがXREF_DATA_CORRUPTED表にコピーされます。この表には、EXCEPTION_CAUSEと呼ばれる追加の列とともに、XREF_DATAのすべての列があります。この列には、例外の理由と行番号が格納されます。XREFデータのアップグレードが完了したら、SYSユーザーとして次のSQLコマンドを使用し、データベース・リンクを削除します。dblink10g;レコードが正常に移行されていない場合、一時表XREF_DATA_CORRUPTEDおよびTEMP_UPGRADE_XREF_LOGはユーティリティで削除されず、手動でクリーン・アップする必要があります。reserved.法律上の注意点ライブラリ。