| Oracle® Fusion Middleware Oracle Forms and Reportsアップグレード・ガイド 11gリリース2 (11.1.2.2) B66164-03 |
|
 前 |
| Oracle® Fusion Middleware Oracle Forms and Reportsアップグレード・ガイド 11gリリース2 (11.1.2.2) B66164-03 |
|
前 |
この章では、Oracle Forms and Reports 11gリリース2 (11.1.2)にアップグレードした後に実行する必要があるタスクについて説明します。
このタスクでは、コンポーネント固有の次のアップグレード手順を実行する必要があります。
Oracle Forms and Reports 11gリリース2 (11.1.2)にアップグレードした後で必要になる可能性がある手動タスクのリストを次に示します。
|
注意: Oracle Formsリリース6iからのアップグレードの詳細は、『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のOracle Forms Servicesへのアップグレードに関する項を参照してください。 |
Upgrade Assistantを使用してOracle Forms Services 10gリリース2 (10.1.2)をOracle Forms and Reports 11gリリース2 (11.1.2)にアップグレードした後に実行する必要があるアップグレード後のタスクのリストを次に示します。
Oracle Forms Services 11gで実行するFormsのアプリケーション・ファイル(fmx、mmxおよびplx)を再生成します。
ロード・バランシングおよび高可用性のために、Oracle Forms Services J2EEアプリケーションのEARファイル(formsapp.ear)を複数のOC4Jインスタンスにデプロイする場合は、Oracle WebLogic Serverでも同様にそれらをデプロイします。
具体的には、追加で管理対象サーバーを作成して、各サーバーにOracle Forms Services J2EEアプリケーションのEARファイルをデプロイすることができます。
EARファイルは、Oracle Fusion Middleware 11g の次の場所に格納されます。
ORACLE_HOME/forms/j2ee/formsapp.ear
詳細は、『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のForms管理対象サーバー・クラスタの拡張に関する項を参照してください。
コンテキスト・ルートまたはFormsのサーブレットの別名をオーバーライドするためにOracle Forms Services J2EEカスタム・アプリケーションのEARファイル(formsapp.ear)をデプロイする場合は、11g Oracle WebLogic Serverドメインで同様の手順を実行する必要があります。
詳細は、『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のForms Java EEアプリケーションのカスタム・デプロイメントに関する項を参照してください。
ソースOracleホームのシェル・スクリプトのカスタマイズした内容を、Oracle Fusion Middleware 11g Oracleインスタンス・ディレクトリに格納されている同等のシェル・スクリプトに手動でコピーします。
アップグレード・アシスタントは、FMAユーティリティ構成ファイル(converter.propertiesおよびsearch_replace.properties)をOracle Fusion Middleware 11gのアップグレード先Oracleインスタンスにコピーしてそれらの名前を変更し、それにより、.10.1.2の接辞尾が付きます。
必要に応じて、.10.1.2の構成ファイルにある必要なエントリをこれらのファイルのOracle Fusion Middleware 11g バージョンに手動でコピーできます。
Upgrade Scriptsを使用してOracle Fusion Middleware 11gリリース1 (11.1.1)のOracle Forms ServicesをOracle Fusion Middleware 11gリリース2 (11.1.2)にアップグレードした後に実行する必要がある手動タスクのリストを次に示します。
ロード・バランシングおよび高可用性のために、Oracle Forms Services J2EEアプリケーションのEARファイル(formsapp.ear)を複数の管理対象サーバーにデプロイした場合は、Oracle Fusion Middleware 11gリリース1 (11.1.1)からのアップグレード後に、同様の方法でそのファイルを再デプロイします。
EARファイルは、Oracle Fusion Middleware 11gの次の場所に格納されます。
ORACLE_INSTANCE/config/Formscomponent/forms/provision/formsapp.ear
詳細は、『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のForms管理対象サーバー・クラスタの拡張に関する項を参照してください。
コンテキスト・ルートまたはFormsのサーブレットの別名をオーバーライドするためにOracle Forms Services J2EEカスタム・アプリケーションのEARファイル(formsapp.ear)をデプロイする場合は、11g Oracle WebLogic Serverドメインで同様の手順を実行する必要があります。
詳細は、『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のForms Java EEアプリケーションのカスタム・デプロイメントに関する項を参照してください。
ソース・インスタンスのForms Oracle HTTP Server構成ファイルforms.confをカスタマイズしている場合、アップグレード先のインスタンスの同等のファイルにカスタマイズの内容を手動で追加する必要があります。
Oracle Forms and Reports 11gリリース2 (11.1.2)では、構成ファイルは次の場所にインストールされます。
ORACLE_INSTANCE/config/OHS/ohs1/modulesconf/forms.conf
forms.confファイルを変更した後でOracle HTTP Serverインスタンスを再起動する必要があることに注意してください。
Oracle Fusion Middleware 11gリリース1 (11.1.1)からアップグレードする際、11gリリース1 (11.1.1)インストールと同じポートを使用するように新しい11gリリース2 (11.1.2)インストールを変更できます。
または、11gリリース2 (11.1.2)のインストール中に定義されるポートを引き続き使用することもできます。
後者の場合は、11gリリース1 (11.1.1)の環境と新しくアップグレードされた11gリリース2 (11.1.2)のインスタンスの両方をポートの競合なしに同時に実行できます。
ただし、場合によっては、Oracle Forms and Reports 11gリリース2 (11.1.2)へのアップグレード後に、11gリリース1 (11.1.1)および11gリリース2 (11.1.2)の両インスタンスでOracle HTTP Serverを起動しようとするとポートが競合することがあります。これは、Oracle HTTP Serverの構成ファイルの一部のパスが正常にアップグレードされていないためです。
この問題が発生するのは、httpd.confファイルのadmin.confファイルおよびssl.confファイルへのパスが、システム変数を使用して定義されているのではなく、ハードコードされている場合です。結果として、11gリリース2 (11.1.2)の宛先Oracleインスタンスではなく、11gリリース1 (11.1.1)のソースOracleインスタンスの構成ファイルが引き続き参照されるようになります。
この問題を回避するには、宛先Oracleインスタンスで次のタスクを実行します。
宛先Oracle HTTP Serverのhttpd.confファイルを見つけます。
ファイルは、宛先Oracleインスタンスの次の場所にあります。
(WINDOWS> DEST_ORACLE_INSTANCE\config\OHS\ohs1\httpd.conf
テキスト・エディタでhttpd.confファイルを編集し、httpd.confファイルに含まれるすべてのディレクティブについて、すべてのソース・パスを宛先パスに置き換えます。
たとえば、次のパスを置き換えます。
"ServerRoot "<Source Oracle Instance>/config/OHS/ohs1"
次の文字列で置き換えます。
"ServerRoot "<Destination Oracle Instance>/config/OHS/ohs1"
httpd.confファイルを保存して閉じます。
<Destination Oracle Instance>/config/OHS/ohs1/ssl.confにあるssl.confファイルを編集します。次の例のように、フォワードスラッシュをバックスラッシュに置き換えます。
対処前:
</Directory> BrowserMatch ".*MSIE.*" / nokeepalive ssl-unclean-shutdown / downgrade-1.0 force-response-1.0 </IfModule>
対処後:
</Directory> BrowserMatch ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </IfModule> </VirtualHost>
ssl.confファイルを保存して閉じます。
Oracle HTTP Serverインスタンスを再起動します。
Oracle Reports 10gからOracle Reports 11gにアップグレードした場合、次の項で、OracleAS Reports Servicesユーザー向けの標準的なアップグレード後のタスクに関する説明を参照してください。
Oracle Reports 11g にアップグレードしても、セキュリティの構成はアップグレードされません。その結果、Oracle Reports 11g のセキュリティ構成は、アップグレード前の状態と変わりません。
Oracle Reports 11g で使用可能なセキュリティ機能、およびその機能の構成方法については、『Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services』のOracle Reports Servicesのセキュリティに関する項を参照してください。
次の項では、OracleAS Reports Services 11g にアップグレードした後で完了する必要があるその他の一般的なアップグレード後のタスクについて説明します。
reports.sh、rwrun.sh、rwserver.shなど、Oracle Reports 10gのOracleホームのbinディレクトリに格納されたシェル・スクリプトは、アップグレード・プロセスの際に自動ではアップグレードされません。かわりに、必要に応じてこれらのスクリプトを手動で変更する必要があります。アップグレード後は、これらのスクリプトを次のOracle Fusion Middleware 11g ディレクトリで確認できます。
ORACLE_INSTANCE/config/reports/bin
OracleAS Reports ServicesのDATファイルは、アップグレード・プロセス中にアップグレードされます。ただし、DATファイルのジョブ・コマンド・エントリに古いOracleホームのパス名または無効なパス名への参照が含まれていると、それらのジョブは失敗します。したがって、そのようなレポート・ジョブのスケジュールを変更する必要があります。
OracleAS Reports Services 10gでは、インプロセス・サーバー・ターゲットは、Oracle Enterprise Manager Application Server ControlではReports Serverとして表示されます。
ただし、OracleAS Reports Services 11gにアップグレードした後、インプロセス・サーバーはreportsと呼ばれるアプリケーションとしてOracle Enterprise Manager Fusion Middleware Controlに表示され、Reportsのアプリケーション・ページでインプロセス・サーバーのターゲットとReportsサーブレットを管理できます。
キャッシュ・レポート出力ファイルは、Oracle Reports 11g にアップグレードされません。
シングル・サインオン・ソフトウェアを認証に使用している場合、特定のアップグレード・シナリオでは、Oracle Forms and Reportsソフトウェアをシングル・サインオン・ソフトウェアに再登録する必要があります。
詳細は、次の項も参照してください。
次の表は、Oracle Forms and Reports 11gリリース2 (11.1.2)へのアップグレード後にシングル・サインオン・クライアントのアクセス・ファイルを再生成する必要がある標準的なアップグレード・シナリオを示したものです。
表6-1 シングル・サインオン構成情報の再生成が必要なアップグレード・シナリオ
| アップグレード・シナリオ | 説明 |
|---|---|
|
Oracle Single Sign-On 10gからOracle Access Manager 11gへのアップグレード |
Oracle Forms and Reports 11gリリース2 (11.1.2)は、既存のOracle Single Sign-On 10gソフトウェアの代替シングル・サインオン・ソフトウェアとしてOracle Access Manager 11gをサポートしています。 詳細は、1.7項「Oracle Forms and Reports 11gリリース2 (11.1.2)でのアイデンティティ管理およびシングル・サインオンの使用について」を参照してください。 対象のOracle Forms and Reports 11gリリース2 (11.1.2)ソフトウェアをOracle Access Manager 11gに対してインストールする場合、アップグレード後に、Oracle HTTP Serverに対して新しい構成情報を生成し、サーバーがOracle Single Sign-On 10gではなくOracle Access Managerに接続できるようにする必要があります。 同様に、後でOracle Single Sign-On 10gからOracle Access Manager 11gにアップグレードする場合、同じ手順を実行する必要があります。 |
|
Oracle Web Cacheとの連携のためのOracle HTTP Serverの構成 |
Oracle Forms and Reports 11gリリース2 (11.1.2)には、Oracle Web Cacheは含まれていません。そのため、アップグレードの際、Oracle HTTP Serverを既存のOracle Web Cacheインスタンスと接続するための構成データは保持されません。 詳細は、1.6項「Oracle Forms and Reports 11gリリース2 (11.1.2)でのWeb層コンポーネントの使用について」を参照してください。 アップグレード後に既存のOracle Web Cacheインスタンスと連携できるようにOracle HTTP Serverインスタンスを構成する場合、Oracle HTTP Serverに対して新しい構成情報を生成し、サーバーがシングル・サインオン・ソフトウェアに接続できるようにする必要があります。 |
シングル・サインオン構成情報の再生成に使用する手順は、使用しているシングル・サインオン・ソフトウェアとその構成方法に応じて異なります。内容は次のとおりです。
Oracle Single Sign-On 10gを使用している場合、osso.confファイルを再生成して、Oracle HTTP Serverが読み取ることができる適切な場所にコピーする必要があります。
詳細は、『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のOracleAS Single Sign-On Server 10gのosso.confファイルの生成に関する項を参照してください。
Oracle Access Manager 11gを使用し、Oracle HTTP Server Webゲート・プラグインを使用していない場合、osso.confファイルを再生成して、Oracle HTTP Serverが読み取ることができる適切な場所にコピーする必要があります。
詳細は、『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のOracle Access Managerのosso.confファイルの生成に関する項を参照してください。
Oracle Access Manager 11gを使用し、Oracle HTTP Server Webゲート・プラグインを使用している場合、Webゲート・エージェントを登録し、生成したファイルを適切な場所にコピーしてから、Oracle HTTP Serverインスタンスを再起動する必要があります。
詳細は、次の情報を参照してください:
『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のOAMでのWebゲートのインストールおよび構成に関する項
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Access Managerの新しいOracle HTTP Server 11g Webゲート・エージェントの使用のスタート・ガイド
Oracle Forms and Reports 11gリリース2 (11.1.2)へのアップグレード後にWeb層コンポーネントに対して実行する必要のあるタスクについては、次の項を参照してください。
Oracle Forms and Reports 11gリリース2 (11.1.2)へのアップグレード前にOracle Web Cacheを使用していた場合、既存のOracle Web Cacheインスタンスを引き続き使用することができます。ただし、アップグレードの完了後にOracle Web CacheとOracle HTTP Serverの両方を再構成する必要があります。
詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のOracle Web Cacheを構成および管理するための基本タスクに関する項を参照してください。
Oracle Single Sign-On 10gまたはOracle Access Manager 11gも使用している場合、ポートおよび接続を再構成した後に、シングル・サインオン・ソフトウェアにインストールを再登録することが必要となる可能性が高くなります。詳細は、6.3項「シングル・サインオン・ソフトウェアを使用している場合に必要なアップグレード後のタスク」を参照してください。
また、次のことに注意してください。
現在、Oracle Web Cache 10gを使用している場合、インストールされているOracle Web Cache 10gをOracle Web Cache 11gにアップグレードすることを検討できます。
Oracle Web Cache 10gからのアップグレードの詳細は、『Oracle Fusion Middleware Java EEアップグレード・ガイド』のJava EEおよびWebサーバー環境のアップグレードに関する説明を参照してください。
すでにOracle Web Cache 11gを実行している場合、11gの最新パッチ・セットを適用して最新のOracle Web Cacheソフトウェアを実行することを検討してください。
Oracle Fusion Middlewareの最新パッチ・セットの適用に関する詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。
SSLを使用してOracle HTTP Serverを保護している場合は、Oracle Forms and Reports 11gリリース2 (11.1.2)へのアップグレードを完了した後、次のタスクを実行する必要があります。
この手順を実行しなかった場合、Oracle HTTP Serverインスタンスを経由してサービスやURLへのアクセスを試みたときに、エラー・メッセージが表示されます。たとえば、シングル・サインオン・サーバーを使用している場合、次のようなエラー・メッセージが表示されることがあります。
Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or OHS single sign-on is incorrectly configured. Please notify your administrator.
この問題を解決するには:
Oracle HTTP Serverのhttpd.confファイルで、次の要素を見つけます。
ServerName hostname:portValue
Oracle HTTP ServerインスタンスのセキュアなHTTPSリスニング・ポートを参照するように、portValueを更新します。
次に例を示します。
ServerName webhost1.example.com:8090
詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの構成ファイルの変更に関する項を参照してください。
Oracle Fusion Middleware 11gへのアップグレード後のOracle HTTP ServerおよびOracle Web Cacheに対するタスクおよび情報の詳細は、『Oracle Fusion Middleware Java EEアップグレード・ガイド』のタスク5: Web層コンポーネントで必要なアップグレード後のタスクの実行を参照してください。
