Oracle9i Application Server for Sun SPARC Solaris...Oracle9i Application Server for Sun SPARC...

Oracle9i Application Server for Sun SPARC Solaris

R1.0.2.2.x から R9.0.2 への移行

リリース 2（9.0.2）

2002 年 7 月

部品番号：J05911-01

Oracle9i Application Server for Sun SPARC Solaris R1.0.2.2.x から R9.0.2 への移行 , リリース 2（9.0.2）

部品番号：J05911-01

原本名：Oracle9i Application Server Migrating from Oracle9iAS Release 1 (1.0.2.2.x) to Release 2 (9.0.2), Release 2 (9.0.2) for Sun SPARC Solaris

原本部品番号：A96157-01

原本協力者：Haranadh Abburu, Gina Abeleles, Kamalendu Biswas, Chris Broadbent, Chung-Ho Chen, Will Chin, David Clay, Michele Cyran, Saheli Dey, Greg Cook, Joe Garcia, Mark Gizejewski, Cathy Godwin, Binod Gupta, Robert Hipps, Marilyn Hollinger, Pavana Jain, Clara Jaeckel, Pushkar Kapasi, Ashish Kolli, Eric Lee, Jeremy Lizt, Mark Loper, Stephen Lee, Xiaohua Lu, Leslie Marder, Duncan Mills, Oscar Naim, Probal Nandy, Raymond Ng, Frank Nimphius, Andy Page, Saurabh Pandey, Julia Pond, Harish Rawat, Frank Rovitto, Mike Rubino, Charlie Shapiro, Jimmy Shi, Preeti Somal, Baogang Song, Margaret Taft, Todd Vender, Brian Wright, Paul Wright, Liujin Yu, Naveen Zalpuri.

Copyright © 2002 Oracle Corporation. All rights reserved.

Printed in Japan.

制限付権利の説明

プログラム（ソフトウェアおよびドキュメントを含む）の使用、複製または開示は、オラクル社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権に関する法律により保護されています。

当プログラムのリバース・エンジニアリング等は禁止されております。

このドキュメントの情報は、予告なしに変更されることがあります。オラクル社は本ドキュメントの無謬性を保証しません。

* オラクル社とは、Oracle Corporation（米国オラクル）または日本オラクル株式会社（日本オラクル）を指します。

危険な用途への使用について

オラクル社製品は、原子力、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションを用途として開発されておりません。オラクル社製品を上述のようなアプリケーションに使用することについての安全確保は、顧客各位の責任と費用により行ってください。万一かかる用途での使用によりクレームや損害が発生いたしましても、日本オラクル株式会社と開発元である Oracle Corporation（米国オラクル）およびその関連会社は一切責任を負いかねます。当プログラムを米国国防総省の米国政府機関に提供する際には、『Restricted Rights』と共に提供してください。この場合次の Notice が適用されます。

Restricted Rights Notice

Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication, and disclosure of the Programs, including documentation, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are "restricted computer software" and use, duplication, and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-19, Commercial Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

このドキュメントに記載されているその他の会社名および製品名は、あくまでその製品および会社を識別する目的にのみ使用されており、それぞれの所有者の商標または登録商標です。

目次目次目次目次

はじめにはじめにはじめにはじめに ........................................................................................................................................................................... xi

対象読者 .................................................................................................................................................................... xii

このマニュアルの構成 ............................................................................................................................................ xii関連文書 ................................................................................................................................................................... xiii表記規則 ................................................................................................................................................................... xiii

1 Oracle9iAS の移行の概要の移行の概要の移行の概要の移行の概要

移行の範囲と方法移行の範囲と方法移行の範囲と方法移行の範囲と方法 ................................................................................................................................................... 1-2ソースおよびターゲットの Oracle9iAS のインストールの識別 ............................................................. 1-2

移行パス移行パス移行パス移行パス ................................................................................................................................................................... 1-2

コンポーネントおよびインストール・タイプ ........................................................................................... 1-3

Oracle9iAS リリース 1 およびリリース 2 のインストール・タイプ ...................................................... 1-5

データベースの移行が必要なコンポーネント ......................................................................................... 1-10

コンポーネントの相互依存性 ..................................................................................................................... 1-11

移行の準備移行の準備移行の準備移行の準備 ............................................................................................................................................................. 1-13このマニュアルの使用方法このマニュアルの使用方法このマニュアルの使用方法このマニュアルの使用方法 ................................................................................................................................. 1-14

2 Oracle9iAS Migration Assistant の使用の使用の使用の使用

Oracle9iAS Migration Assistant の理解の理解の理解の理解 ............................................................................................................ 2-2Oracle HTTP Server の移行プロセス .......................................................................................................... 2-2

Oracle HTTP Server の移行候補 .......................................................................................................... 2-2

デフォルト・モジュール ............................................................................................................... 2-4httpd.conf のデフォルト・ディレクティブ ............................................................................... 2-5

移行されない Oracle HTTP Server 要素 ............................................................................................. 2-6Oracle HTTP Server のディレクティブの移行プロセス .................................................................. 2-7

i

SSL 設定の移行 ............................................................................................................................... 2-8Oracle HTTP Server の移行に対するバックアップおよび監査方法 ............................................ 2-10

Oracle9iAS Containers for J2EE（OC4J）の移行プロセス .................................................................... 2-10

OC4J の移行候補 .................................................................................................................................. 2-11スタンドアロン OC4J インスタンスと移行 ..................................................................................... 2-11OC4J 構成ファイルの移行プロセス .................................................................................................. 2-12

OC4J の移行における J2EE 準拠要件 ................................................................................................ 2-12J2EE 準拠に対する EAR ファイルの検証 ................................................................................. 2-12

OC4J の移行に対するバックアップおよび監査方法 ...................................................................... 2-13

Oracle9iAS Web Cache の移行プロセス ................................................................................................... 2-14

Web Cache の移行候補 ........................................................................................................................ 2-14セッション定義の移行 ................................................................................................................. 2-14

Web Cache の移行プロセス ................................................................................................................ 2-15

Web Cache の移行に対するバックアップおよび監査方法 ............................................................ 2-16Oracle9iAS Migration Assistant のインストールのインストールのインストールのインストール .......................................................................................... 2-17

ハードウェア要件 ......................................................................................................................................... 2-17

ソフトウェア要件 ......................................................................................................................................... 2-17

オペレーティング・システム要件 ............................................................................................................. 2-18

Oracle Universal Installer の起動 .............................................................................................................. 2-20

アプリケーションの移行アプリケーションの移行アプリケーションの移行アプリケーションの移行 ..................................................................................................................................... 2-26移行の準備 ..................................................................................................................................................... 2-26

情報要件 ................................................................................................................................................. 2-26SSL 設定要件 ......................................................................................................................................... 2-26

Oracle9iAS Migration Assistant（GUI バージョン）の使用 ................................................................ 2-27

Oracle9iAS Migration Assistant（コマンドライン・バージョン）の使用 ......................................... 2-34

Web Cache の移行の完了 ............................................................................................................................ 2-36

Oracle9iAS Migration Assistant の再起動の再起動の再起動の再起動 ...................................................................................................... 2-37

3 インターネット・アプリケーションのコンポーネントの移行インターネット・アプリケーションのコンポーネントの移行インターネット・アプリケーションのコンポーネントの移行インターネット・アプリケーションのコンポーネントの移行

Oracle9iAS Containers for J2EE（（（（OC4J）の移行）の移行）の移行）の移行 ........................................................................................... 3-2

JSP から OC4J への移行 ................................................................................................................................. 3-2

Servlet 2.3 環境と Servlet 2.0 環境における JSP ページの比較 ....................................................... 3-3JSP コンテナの移行についての留意点 ................................................................................................ 3-4

taglib-location の設定 .................................................................................................................... 3-4

HTML コメント .............................................................................................................................. 3-5閉じられていないタグがあるページを含むための Include ディレクティブの使用 ........... 3-5

ii

Include ディレクティブ構文 ........................................................................................................ 3-6タグ属性の設定で使用される引用符 ........................................................................................... 3-6

アプリケーション環境と留意点 ........................................................................................................... 3-6

globals.jsa からの移行 ................................................................................................................... 3-7クラスパス機能 ............................................................................................................................... 3-7JspScopeListener 機能の移行 ........................................................................................................ 3-9

JSP グローバル・インクルード .......................................................................................................... 3-10ojsp-global-include.xml ファイル .............................................................................................. 3-10<ojsp-global-include> .................................................................................................................. 3-10

<include ... > .................................................................................................................................. 3-10<into ... > ........................................................................................................................................ 3-11グローバル・インクルードの例 ................................................................................................. 3-11例 : ヘッダー / フッター ............................................................................................................. 3-11

例 : translate_params 等価コード .............................................................................................. 3-12JSP 構成 .................................................................................................................................................. 3-13

以前の Oracle JSP 構成パラメータのサポート ........................................................................ 3-14

新しい Oracle JSP 構成パラメータ ............................................................................................ 3-15translate_params の移行でのグローバル・インクルード ..................................................... 3-16

ojspc ユーティリティを使用する場合の問題点 ............................................................................... 3-16

OC4J 環境における ojspc の実行 ............................................................................................... 3-16JServ 環境における ojspc_jserv の実行 ..................................................................................... 3-17

パッケージングおよびデプロイメント ............................................................................................. 3-17その他の留意点 ..................................................................................................................................... 3-18

HTTP パラメータのグローバリゼーションについての留意点 ............................................. 3-18setCharacterEncoding() メソッド .............................................................................................. 3-18文字形式での静的テキスト ......................................................................................................... 3-19

jsp:param 設定の適切な処理 ...................................................................................................... 3-19タグ・ハンドラの再利用 ............................................................................................................. 3-19セッション・キーのシードの生成 ............................................................................................. 3-20

JServ から OC4J への移行 ........................................................................................................................... 3-20

Web アプリケーション環境 ................................................................................................................ 3-21サーブレット・コンテキストとサーブレット・パスのマッピング ..................................... 3-21

デフォルトの Web アプリケーションのルート・コンテキストの変更 ...................................... 3-22

サーブレット・ゾーンと Web アプリケーションの比較 ............................................................... 3-23JServ のゾーン仕様の基本 ........................................................................................................... 3-23OC4J アプリケーション仕様の基本 .......................................................................................... 3-23

アプリケーション構造、ファイルの場所およびデプロイ ............................................................. 3-25JServ のファイル・リポジトリ ................................................................................................... 3-25

iii

OC4J のアプリケーション構造とファイルの場所 .................................................................. 3-25OC4J のデプロイ .................................................................................................................................. 3-27サーブレット環境の設定 ..................................................................................................................... 3-28

JVM パラメータと環境変数 ........................................................................................................ 3-28JServ における環境変数の設定 ................................................................................................... 3-28OC4J における環境変数の設定 .................................................................................................. 3-29

マウントの設定 ............................................................................................................................. 3-30JServ におけるマウントの設定 ................................................................................................... 3-30OC4J におけるマウントの設定 .................................................................................................. 3-30

サーブレット別名と URL マッピング ...................................................................................... 3-32JServ におけるサーブレット別名と URL マッピング ............................................................ 3-32OC4J におけるサーブレット別名と拡張子マッピング .......................................................... 3-33

初期化パラメータ ................................................................................................................................. 3-33

JServ における初期化パラメータの設定 .................................................................................. 3-33OC4J における初期化パラメータの設定 .................................................................................. 3-34

サーブレット実行時の留意点 ............................................................................................................. 3-35

サーブレットの事前起動 ............................................................................................................. 3-35JServ における事前起動とタイムアウトの設定 ...................................................................... 3-35OC4J における事前起動の設定 .................................................................................................. 3-36

クラス・ローダーとクラスの自動再ロード ..................................................................................... 3-36JServ におけるクラスのロード ................................................................................................... 3-36OC4J におけるクラスのロード .................................................................................................. 3-37

セッションのトラッキングと動作 ..................................................................................................... 3-38

JServ におけるセッションのトラッキングと動作 .................................................................. 3-38OC4J におけるセッションのトラッキングと動作 .................................................................. 3-38メッセージおよびエラーのロギング ......................................................................................... 3-39

JServ におけるメッセージのロギング ...................................................................................... 3-39OC4J におけるメッセージのロギング ...................................................................................... 3-40

ロード・バランシングとフォルト・トレランス ............................................................................. 3-41JServ におけるリクエスト・ルーティングとロード・バランシング .................................. 3-41

OC4J におけるロード・バランシングとフォルト・トレランス .......................................... 3-42例 : JServ から OC4J への移行 ........................................................................................................... 3-42

JServ における設定 ....................................................................................................................... 3-43

principals.xml ファイルの Java 認証および認可サービスへの移行 ..................................................... 3-48

Oracle9iAS SOAP の移行の移行の移行の移行 ................................................................................................................................... 3-49Oracle Business Components for Java の移行の移行の移行の移行 ............................................................................................... 3-50

BC4J アプリケーションの移行 ................................................................................................................... 3-51

iv

4 Portal コンポーネントの移行コンポーネントの移行コンポーネントの移行コンポーネントの移行

Oracle9iAS Portal の移行の移行の移行の移行 ..................................................................................................................................... 4-2中間層の移行 ................................................................................................................................................... 4-2

Oracle9iAS Portal リリース 9.0.2 のアーキテクチャの変更 ............................................................ 4-2JServ ゾーンから OC4J アプリケーションへの移行 ................................................................. 4-2

Parallel Page Engine の移行 ................................................................................................................. 4-3リリース 2 での mod_plsql パラメータの変更 .................................................................................. 4-7

DAD パラメータの使用方法 ........................................................................................................ 4-9

移行された DAD の例 ................................................................................................................. 4-10データベース・アクセス記述子（DAD）の移行 ................................................................... 4-11

中間層のキャッシュ構成の移行 ......................................................................................................... 4-12Portal Developer Kit（PDK）for Java の Web プロバイダの移行 ....................................................... 4-14

PDK for Java Framework とサンプルのインストール ................................................................... 4-14PDK for Java Framework の設定要件 ....................................................................................... 4-14サンプル・プロバイダのデプロイ ............................................................................................. 4-15

サンプル・プロバイダの登録 ..................................................................................................... 4-16サンプル・ポートレットのページへの追加 ............................................................................. 4-17プロバイダの保護 ......................................................................................................................... 4-17

PDK for Java 9.0.2 の概要 .................................................................................................................... 4-18PDK for Java の旧リリースと新リリースの相違点のまとめ ......................................................... 4-18

インタフェースから抽象クラスへの変更 ................................................................................. 4-19パッケージの再編成 ..................................................................................................................... 4-19

オブジェクト指向のフレームワーク ......................................................................................... 4-19移行オプション ..................................................................................................................................... 4-21

PDK for Java 3.0.9.x から PDK for Java 9.0.x（v1）への移行 ............................................... 4-21

PDK for Java 3.0.9.x から PDK for Java 9.0.x（v2）への移行 ............................................... 4-24プロバイダのパッケージングおよびデプロイ ................................................................................. 4-29

サービス名またはサービス識別子 ............................................................................................. 4-29

WAR ファイルおよび EAR ファイル ........................................................................................ 4-29OC4J へのプロバイダのデプロイ .............................................................................................. 4-33プロバイダの登録 ......................................................................................................................... 4-34

中間層のアップグレード後の Web Cache のキャッシュ・ルール ............................................... 4-35

Web Cache のキャッシュ機能について .................................................................................... 4-35Portal 3.0.9 のキャッシュ機能について .................................................................................... 4-35リリース 2 の Middle-Tier を Web Cache と Portal 3.0.9 のリポジトリと一緒に使用する場合のキャッシュ機能 ................................................................................................. 4-35キャッシュ・ルールの設定 ......................................................................................................... 4-36

SSL 設定の移行 ..................................................................................................................................... 4-37

v

ブラウザから Web Cache への SSL 接続 .................................................................................. 4-38Web Cache から Oracle9iAS の中間層への接続 ...................................................................... 4-38Parallel Page Engine（PPE）から Web Cache への接続 ....................................................... 4-38

証明書と HTTPS を使用するポートの保護 .............................................................................. 4-38Portal の移行に関するトラブルシューティングとヒント ..................................................................... 4-39

リリース 1 のイメージ・ファイルを使用するための Oracle9iAS リリース 2（9.0.2）の構成 4-39

Portal EAR ファイルの確認 ................................................................................................................ 4-40JNI キャッシュ・ライブラリがアクセス可能であることの確認 .................................................. 4-40

Oracle Ultra Search の移行の移行の移行の移行 ................................................................................................................................ 4-40

UltraSearch の移行方法 ............................................................................................................................... 4-41

インプレース移行 ................................................................................................................................. 4-41ELT（抽出、ロードおよび変換）による移行 ................................................................................. 4-42

移行ログ ......................................................................................................................................................... 4-43

5 Wireless コンポーネントの移行コンポーネントの移行コンポーネントの移行コンポーネントの移行

Oracle9iAS Wireless の移行の移行の移行の移行 ................................................................................................................................ 5-2移行の範囲 ....................................................................................................................................................... 5-2

ユーザー・エージェント・プロパティ・ファイルからデータベースへの移行 ................... 5-2テーブル・スキーマの変更に伴うトランスフォーマのアップグレード ............................... 5-2サイトとノードの構成プロパティからデータベースへの移行 ............................................... 5-3

panama ユーザー・テーブルから OID への移行 ...................................................................... 5-3移行パス ........................................................................................................................................................... 5-3

開始前の処理 ........................................................................................................................................... 5-3インプレース移行 ................................................................................................................................... 5-4

新旧のリリースが同じコンピュータにインストールされている場合 ................................... 5-5新旧のリリースが個別のコンピュータにインストールされている場合 ............................... 5-7リポジトリの移行 ........................................................................................................................... 5-9

ユーザーの移行 ..................................................................................................................................... 5-10カスタマイズを移行するための追加手順 ......................................................................................... 5-11

複数の中間層を使用した移行 ..................................................................................................................... 5-12

vi

6 Business Intelligence コンポーネントの移行コンポーネントの移行コンポーネントの移行コンポーネントの移行

Oracle9i Forms Services の移行の移行の移行の移行 .......................................................................................................................... 6-2Forms6i Services の Common Gateway Interface（CGI）から Forms Servlet への移行 ........... 6-4Forms 6i の静的な HTML 起動ファイルから Forms 9i の汎用アプリケーション HTML起動ファイルへの移行 ........................................................................................................................... 6-5

Oracle9i Forms Services の Forms で静的 HTML ファイルを使用する場合 ........................ 6-7Forms 6i リスナーから Forms Listener Servlet への移行 ................................................................. 6-8

Forms Listener Servlet アーキテクチャから Oracle9i Forms Services への移行 ........................ 6-10ロード・バランシングの移行 ............................................................................................................. 6-12使用上の注意 ......................................................................................................................................... 6-12

Forms Servlet によるアイコン・イメージの配布 ................................................................... 6-12Reports Services を使用するための統合コールから Oracle9i Reports への移行 ............... 6-13Forms Listener Servlet の OC4J での別名の作成 ..................................................................... 6-14Forms Listener Servlet 管理ページへのアクセス .................................................................... 6-14

Oracle9i Forms Services への移行のベスト・プラクティス ......................................................... 6-15Oracle9iAS Reports Services の移行の移行の移行の移行 ................................................................................................................ 6-16

Reports 構成ファイルの移行 ...................................................................................................................... 6-16

Oracle9iAS Reports Services と Oracle9iAS Portal の併用 .................................................................... 6-17

Oracle Graphics の移行 ............................................................................................................................... 6-18

Oracle9iAS Reports Services の非推奨機能 .............................................................................................. 6-19

Oracle9iAS Discoverer の移行の移行の移行の移行 .......................................................................................................................... 6-20環境設定の移行 ..................................................................................................................................... 6-20

デフォルト・ユーザーの環境設定の移行 ................................................................................. 6-20Discoverer リリース 4.1 から Discoverer 9.0.2 へのユーザー・レベル環境設定の移行 ... 6-21

エンド・ユーザー・レイヤーの更新 ................................................................................................. 6-21URL 参照の更新 .................................................................................................................................... 6-21セッション・タイムアウトの構成 ..................................................................................................... 6-22

Discoverer Viewer のカスタマイズの移行 ....................................................................................... 6-22JInitiator のアップグレード ................................................................................................................ 6-23

Oracle9iAS Personalization の移行の移行の移行の移行 ................................................................................................................. 6-24移行の概要 ..................................................................................................................................................... 6-24

移行スクリプトの場所 ......................................................................................................................... 6-25extract-load-and-transform による移行 .................................................................................................... 6-25

OP リリース 9.0.2 のインストール .................................................................................................... 6-25

ELT を使用した OP リリース 9.0.1MTR の移行 .............................................................................. 6-25OP リリース 9.0.1 および OP リリース 9.0.2 の起動 ....................................................................... 6-26

インプレース移行 ......................................................................................................................................... 6-26

vii

OP リリース 9.0.2 のインストール .................................................................................................... 6-27インプレースによる OP リリース 9.0.1 の MTR の移行 ................................................................ 6-27OP リリース 9.0.2 の起動 .................................................................................................................... 6-28

移行した MTR のダウングレード .............................................................................................................. 6-28

OP リリース 9.0.1 の削除 ............................................................................................................................ 6-29

7 管理コンポーネントの移行管理コンポーネントの移行管理コンポーネントの移行管理コンポーネントの移行

Oracle Enterprise Manager の移行の移行の移行の移行 ..................................................................................................................... 7-2移行の準備 ....................................................................................................................................................... 7-2

Management Server および Enterprise Manager のアプリケーションの停止 ..................... 7-2

リポジトリのバックアップ ........................................................................................................... 7-2リポジトリのアップグレード ....................................................................................................................... 7-3

既存のリポジトリの削除 ............................................................................................................................... 7-5

構成後の Management Server の管理 ......................................................................................................... 7-8

Oracle9iAS Single Sign-On の移行の移行の移行の移行 .................................................................................................................... 7-8Oracle Internet Directory の移行の移行の移行の移行 ........................................................................................................................ 7-9

アップグレード時の考慮事項 ....................................................................................................................... 7-9

アップグレード前の作業 ............................................................................................................................. 7-10

シングル・ノード環境でのアップグレード ............................................................................................. 7-10

データベースのリリース 8.1.7.* から 9.0.1.0.0 への移行 ................................................................ 7-11

9.0.1.3.0 データベース・パッチの適用 .............................................................................................. 7-11Oracle Internet Directory Configuration Assistant ......................................................................... 7-11リリース 3.0.1.* から 9.0.1.2.0 へのアップグレード ........................................................................ 7-13

マルチノード環境でのアップグレード ..................................................................................................... 7-15

一度に 1 つのノードをアップグレードする場合 ............................................................................. 7-15レプリケート環境の下位互換性 ......................................................................................................... 7-16同時にすべてのノードをアップグレードする場合 ......................................................................... 7-17

アップグレード後の作業 ............................................................................................................................. 7-17

JOB_QUEUE_PROCESSES パラメータの設定 ................................................................................ 7-17ユーザー・データのアップグレード ................................................................................................. 7-18

パスワードの変換 ......................................................................................................................... 7-18Oracle コンテキストの設定 ................................................................................................................ 7-18

ルート Oracle コンテキストの設定 ........................................................................................... 7-18デフォルトのサブスクライバ Oracle コンテキストの設定 ................................................... 7-19

パスワード・ポリシーの設定 ..................................................................................................... 7-19アップグレード後の手動による作業およびデータベース移行時の代替方法 ............................. 7-20

viii

サーバー管理 ................................................................................................................................. 7-20ディレクトリ統合サーバー ......................................................................................................... 7-20データベースのインポート / エクスポートによるアップグレード .................................... 7-20

8 E-Business 統合コンポーネントの移行統合コンポーネントの移行統合コンポーネントの移行統合コンポーネントの移行

Oracle9iAS InterConnect の移行の移行の移行の移行 ........................................................................................................................ 8-2ハブ・コンポーネントの移行 ....................................................................................................................... 8-2

メタデータの移行 ........................................................................................................................................... 8-2

アダプタの移行 ............................................................................................................................................... 8-3

iStudio および SDK の移行 ........................................................................................................................... 8-3

管理の移行 ....................................................................................................................................................... 8-3

Oracle Workflow の移行 ............................................................................................................................... 8-4

索引索引索引索引

ix

はじめにはじめにはじめにはじめに

このマニュアルでは、Oracle9i Application Server リリース 1（1.0.2.2）から Oracle9i Application Server リリース 2（9.0.2）への移行方法について説明します。

「はじめに」の項目は次のとおりです。

� 対象読者

� このマニュアルの構成

� 関連文書

� 表記規則

xi

対象読者対象読者対象読者対象読者『Oracle9i Application Server R1.0.2.2.x から R9.0.2 への移行』は、アプリケーション・サーバーによって使用されるデータベースのアプリケーション・サーバー管理者およびマネージャを対象としています。

このマニュアルの構成このマニュアルの構成このマニュアルの構成このマニュアルの構成このマニュアルは、Oracle9iAS のソリューション・エリアで構成されており、次の章から構成されています。

第 1 章「Oracle9iAS の移行の概要」

この章では、移行の範囲、以前および現在のリリースのコンポーネントおよび移行の方法と用語について説明します。

第 2 章「Oracle9iAS Migration Assistant の使用」

この章では、Oracle9iAS Migration Tool を使用して、Oracle HTTP Server、Oracle9iAS Containers for J2EE および Oracle9iAS Web Cache を移行する方法について説明します。

第 3 章「インターネット・アプリケーションのコンポーネントの移行」

この章では、JSP および JServ アプリケーションを Oracle9iAS Containers for J2EE、Oracle9iAS SOAP および Oracle8i PL/SQL に移行する方法について説明します。

第 4 章「Portal コンポーネントの移行」

この章では、Oracle9iAS Portal および Ultra Search を移行する方法について説明します。

第 5 章「Wireless コンポーネントの移行」

この章では、Oracle9iAS Wireless を移行する方法について説明します。

第 6 章「Business Intelligence コンポーネントの移行」

この章では、Oracle9iAS Forms Services、Oracle9iAS Reports Services、Oracle9iAS Discoverer および Oracle9iAS Personalization を移行する方法について説明します。

第 7 章「管理コンポーネントの移行」

この章では、Oracle Enterprise Manager、Oracle9iAS Single Sign-On および Oracle Internet Directory を移行する方法について説明します。

第 8 章「E-Business 統合コンポーネントの移行」

この章では、Oracle9iAS InterConnect を移行する方法について説明します。

xii

関連文書関連文書関連文書関連文書リリース・ノート、インストレーション・マニュアル、ホワイト・ペーパーまたはその他の関連文書は、OTN-J（Oracle Technology Network Japan）の Web サイトから無償でダウンロードできます。 OTN-J を使用するには、オンラインでの登録が必要です。次の URL で登録できます。

http://otn.oracle.co.jp/membership/

OTN のユーザー名とパスワードをすでに取得している場合は、次の OTN-J Web サイトの文書セクションに直接接続できます。

http://otn.oracle.co.jp/document/

表記規則表記規則表記規則表記規則この項では、このマニュアルのテキストおよびコード例に使用されている表記規則について説明します。ここで説明する内容は、次のとおりです。

� 本文の表記規則

� コード例の表記規則

xiii

本文の表記規則本文の表記規則本文の表記規則本文の表記規則本文中には、特別な用語が一目でわかるように、様々な表記規則が使用されています。次の表に、本文の表記規則と使用例を示します。

表記規則表記規則表記規則表記規則意味意味意味意味例例例例

太字太字太字太字太字は、本文で定義されている用語、用語集に記載されている用語、またはその両方に該当する用語を示します。

この句を指定することにより、索引構成表索引構成表索引構成表索引構成表が作成されます。

固定幅フォントの大文字

固定幅フォントの大文字は、システムによって指定される要素を示します。この要素

には、パラメータ、権限、データ型、Recovery Manager キーワード、SQL キー

ワード、SQL*Plus またはユーティリティ・

コマンド、パッケージとメソッド、システム指定の列名、データベース・オブジェクトおよび構造体、ユーザー名およびロールが含まれます。

この句は、NUMBER列にのみ指定可能です。

データベースをバックアップするには、BACKUPコマンドを使用します。

USER_TABLESデータのディクショナリ・ビュー

の TABLE_NAME列を問い合せます。

DBMS_STATS.GENERATE_STATSプロシージャを

使用します。

固定幅フォントの小文字

固定幅フォントの小文字は、実行可能ファイル、ファイル名、ディレクトリ名およびユーザー定義要素のサンプルを示します。これらの要素には、コンピュータ名、データベース名、ネット・サービス名および接続識別子、さらにユーザー指定のデータベース・オブジェクトおよび構造体、列名、パッケージおよびクラス、ユーザー名およびロール、プログラム・ユニットおよびパラメータ値が含まれます。

注意注意注意注意 : プログラム要素の中には、大文字と

小文字が混在して使用されているものもあります。これらの要素については、表示され

ているとおりに入力してください。

sqlplusと入力し、SQL*Plus を開きます。

パスワードは、orapwdファイルに指定されてい

ます。

データファイルおよび制御ファイルを/disk1/oracle/dbsディレクトリにバックアッ

プします。

department_id、department_nameおよび

location_id列は、hr.departments表内に存

在します。

QUERY_REWRITE_ENABLED初期化パラメータを

trueに設定します。

oeユーザーで接続します。

JRepUtilクラスによってこれらのメソッドが実

装されます。

固定幅フォントの小文字のイタリック

固定幅フォントの小文字のイタリックは、プレースホルダまたは変数を示します。

parallel_clauseを指定できます。

Uold_release.SQLを実行します。old_releaseは、アップグレード前にインストール済

のリリースを示します。

xiv

コード例の表記規則コード例の表記規則コード例の表記規則コード例の表記規則コード例では、SQL、PL/SQL、SQL*Plus またはその他のコマンドライン構文が示されます。この中では、次の例のように、固定幅フォントが使用され、通常の本文とは区別して表示されます。

SELECT username FROM dba_users WHERE username = 'MIGRATE';

次の表に、コード例に使用される表記規則と使用例を示します。


[ ] 大カッコはオプションの項目を示します。大カッコ自体は入力しないでください。

DECIMAL (digits [ , precision ])

{ } 中カッコは、カッコ内の項目のうちの 1 つ

を指定する必要があることを示します。中カッコ自体は入力しないでください。

{ENABLE | DISABLE}

| 縦線は、大カッコまたは中カッコ内の選択肢を示します。これらのオプションのうちの

1 つを入力します。縦線は入力しないでくだ

さい。

{ENABLE | DISABLE}

[COMPRESS | NOCOMPRESS]

... 水平の省略記号は、次のどちらかを示しています。

� コード中で、例に直接関係のない部分が省略されていること。

� コードの一部が繰返し可能であること。

CREATE TABLE ... AS subquery;

SELECT col1, col2, ... , coln FROM employees;

.

.

.

縦方向の省略記号は、コード中で、例に直接関係のない行が何行か省略されていることを示します。

その他の表記大カッコ、中カッコ、縦線および省略記号以外の記号は、表示されているとおりに入力してください。

acctbal NUMBER(11,2);

acct CONSTANT NUMBER(4) := 3;

イタリック体イタリック体のテキストは、特定の値を指定する必要のあるプレースホルダまたは変数を示します。

CONNECT SYSTEM/system_password

DB_NAME = database_name

xv

マニュアル内にある外部マニュアル内にある外部マニュアル内にある外部マニュアル内にある外部 Web サイトへのリンクの利用についてサイトへのリンクの利用についてサイトへのリンクの利用についてサイトへのリンクの利用についてこのマニュアルには、オラクル社が所有または管理していない他の企業や組織の Web サイトへのリンクが記載されている場合があります。オラクル社では、このような Web サイトの利用に関する評価も代弁も行いません。

大文字大文字で表記されている部分は、システムによって指定される要素を示します。ユー

ザーが定義する用語と区別するために、これらの用語は大文字で表記されます。用語が

大カッコで囲まれている場合を除いて、表示されている順序およびスペルのとおりに入力します。ただし、これらの用語には大文

字・小文字の区別がないため、小文字で入力しても構いません。

SELECT last_name, employee_id FROM employees;

SELECT * FROM USER_TABLES;

DROP TABLE hr.employees;

小文字小文字で表記されている部分は、ユーザーが指定するプログラム要素を示します。たと

えば、表、列またはファイルの名前を示します。

注意注意注意注意 : プログラム要素の中には、大文字と

小文字が混在して使用されているものもあります。これらの要素については、表示され

ているとおりに入力してください。

SELECT last_name, employee_id FROM employees;

sqlplus hr/hr

CREATE USER mjones IDENTIFIED BY ty3MU9;


xvi

Oracle9iAS の移行の

1
Oracle9iAS の移行の概要の移行の概要の移行の概要の移行の概要
この章では、Oracle9iAS の移行の範囲、方法およびプロセスについて説明します。この章の主な項は次のとおりです。

� 移行の範囲と方法

� 移行パス

� 移行の準備

� このマニュアルの使用方法

概要 1-1

移行の範囲と方法

移行の範囲と方法移行の範囲と方法移行の範囲と方法移行の範囲と方法この移行ガイドの情報は、Oracle9iAS リリース 1（1.0.2.2）からリリース 2（9.0.2）への移行にのみ適用されます。

リリース 1（1.0.2.1.x）がインストールされている場合は、初に Oracle9iAS リリース 1（1.0.2.2.x）へ移行する必要があります。

ソースおよびターゲットのソースおよびターゲットのソースおよびターゲットのソースおよびターゲットの Oracle9iAS のインストールの識別のインストールの識別のインストールの識別のインストールの識別このマニュアルでは、Oracle9iAS リリース 1（1.0.2.2.x）が Oracle9iAS リリース 2（9.0.2）以外の異なる Oracle ホームにインストールされている場合の、Oracle ホーム相互の移行について説明します。 Oracle ホームは次のように呼ばれます。

リリース 1（1.0.2.2）の場所は、ORACLE_HOME_1 またはソース Oracle ホームと呼ばれます。

リリース 2（9.0.2）の場所は、ORACLE_HOME_2 またはターゲット Oracle ホームと呼ばれます。

移行パス移行パス移行パス移行パスこの項では、リリース 1 とリリース 2 のアーキテクチャ、コンポーネントおよびインストール・タイプを比較して、移行先であるリリース 2 のインストール・タイプの選択に関するリコメンデーションを示します。また、データベースとコンポーネント間の依存性に関する情報を示し、それらの情報に即した移行の進め方について説明します。この項の項目は次のとおりです。

� コンポーネントおよびインストール・タイプ

� Oracle9iAS リリース 1 およびリリース 2 のインストール・タイプ

� データベースの移行が必要なコンポーネント

� コンポーネントの相互依存性

関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server Oracle Application Server からの移行』

1-2　Oracle9i Application Server for Sun SPARC Solaris R1.0.2.2.x から R9.0.2 への移行

移行パス

コンポーネントおよびインストール・タイプコンポーネントおよびインストール・タイプコンポーネントおよびインストール・タイプコンポーネントおよびインストール・タイプ表 1-1 に、Oracle9iAS のコンポーネントおよびそれらのコンポーネントの以前のリリースおよび現行のリリースでのインストール・タイプを示します。移行を計画するコンポーネントは、リリース 2 のインストール時に選択したインストール・タイプである必要があります。

表表表表 1-1 Oracle9iAS コンポーネントおよびインストール・タイプコンポーネントおよびインストール・タイプコンポーネントおよびインストール・タイプコンポーネントおよびインストール・タイプ

コンポーネントコンポーネントコンポーネントコンポーネントOracle9iAS リリースリリースリリースリリース 1（（（（1.0.2.2.x）の）の）の）の

インストール・タイプインストール・タイプインストール・タイプインストール・タイプOracle9iAS リリースリリースリリースリリース 2（（（（9.0.2）の）の）の）の

インストール・タイプインストール・タイプインストール・タイプインストール・タイプ

Oracle HTTP Server Core、Minimal、Standard、Enterprise � J2EE および Web Cache

� Portal および Wireless

� Business Intelligence および Forms

� Unified Messaging

Oracle9iAS Containers for J2EE

Core � J2EE および Web Cache




Oracle Business Components for Java

Core、Minimal、Standard、Enterprise � J2EE および Web Cache

Oracle9iAS Forms Services Enterprise � Business Intelligence および Forms


Oracle9iAS Portal Minimal、Standard、Enterprise � Portal および Wireless



Oracle9iAS Wireless Minimal、Standard、Enterprise � Portal および Wireless



Oracle9iAS Web Cache Core、Enterprise � J2EE および Web Cache




Oracle9iAS Reports Services

Enterprise � Business Intelligence および Forms


Oracle9iAS の移行の概要 1-3

移行パス

Oracle9iAS Discoverer Enterprise � Business Intelligence および Forms


Oracle9iAS Personalization 該当なし � Business Intelligence および Forms


Oracle Enterprise Manager Web Site

Enterprise（旧 Oracle Management Server）

� J2EE および Web Cache




Oracle Internet File System Standard、Enterprise 移行の詳細については、Oracle Internet File System のインストレーション・ガイ

ドを参照してください。 Oracle Internet File System は、Oracle9iAS とは別の CDで提供されています。

Oracle9iAS Unified Messaging

該当なし � Unified Messaging

表表表表 1-1 Oracle9iAS コンポーネントおよびインストール・タイプ（続き）コンポーネントおよびインストール・タイプ（続き）コンポーネントおよびインストール・タイプ（続き）コンポーネントおよびインストール・タイプ（続き）

コンポーネントコンポーネントコンポーネントコンポーネントOracle9iAS リリースリリースリリースリリース 1（（（（1.0.2.2.x）の）の）の）の

インストール・タイプインストール・タイプインストール・タイプインストール・タイプOracle9iAS リリースリリースリリースリリース 2（（（（9.0.2）の）の）の）の

インストール・タイプインストール・タイプインストール・タイプインストール・タイプ


移行パス

Oracle9iAS リリースリリースリリースリリース 1 およびリリースおよびリリースおよびリリースおよびリリース 2 のインストール・タイプのインストール・タイプのインストール・タイプのインストール・タイプリリース 1 からリリース 2 に移行するうえで、アーキテクチャとインストール・タイプの関係を理解すると役に立ちます。この項では、その関係について詳細に図示および説明します。

図図図図 1-1 Oracle9iAS リリースリリースリリースリリース 1（（（（1.0.2.2.x）のアーキテクチャ）のアーキテクチャ）のアーキテクチャ）のアーキテクチャ

ブラウザ

ホスト

オリジナル・データベース

ホスト

オリジナル・データベース

ホスト

Minimal Edition

ホスト

Standard Edition

ホスト

Enterprise Edition

DatabaseCache


移行パス

図図図図 1-2 Oracle9iAS リリースリリースリリースリリース 2（（（（9.0.2）のアーキテクチャ）のアーキテクチャ）のアーキテクチャ）のアーキテクチャ

ホスト1

J2EEおよびWeb Cache

PortalおよびWireless

ホスト2

Business IntelligenceおよびForms

Unified Messaging

ホスト3

Oracle9iASMetadata

Repository

Oracle Internet Directory

Oracle9iAS Single Sign-On

ホスト4

Oracle9iDatabase

Oracle Management Server


移行パス

表表表表 1-2 Oracle9iAS リリースリリースリリースリリース 1 およびリリースおよびリリースおよびリリースおよびリリース 2 のインストール・タイプのインストール・タイプのインストール・タイプのインストール・タイプ

リリースリリースリリースリリース 1 のインスのインスのインスのインストール・タイプトール・タイプトール・タイプトール・タイプ

リリースリリースリリースリリース 1 ののののコンポーネント構成コンポーネント構成コンポーネント構成コンポーネント構成

推奨されるリリース推奨されるリリース推奨されるリリース推奨されるリリース 2 ののののインストール・タイプインストール・タイプインストール・タイプインストール・タイプ

推奨されるリリース推奨されるリリース推奨されるリリース推奨されるリリース 2 ののののコンポーネント構成コンポーネント構成コンポーネント構成コンポーネント構成

Core

Minimal Edition

Standard Edition

Enterprise Edition

Oracle HTTP Server J2EE および Web Cache Oracle HTTP Server


Core

Enterprise Edition

Oracle HTTP Server J2EE および Web Cache Oracle HTTP Server


Oracle9iAS Web Cache

Core Oracle9iAS Containers for J2EE

J2EE および Web Cache Oracle HTTP Server


Core

Enterprise Edition

Oracle9iAS Web Cache J2EE および Web Cache Oracle HTTP Server



Minimal Edition

Standard Edition

Enterprise Edition

Oracle HTTP Server

Oracle9iAS Portal

Portal および Wireless Oracle HTTP Server



Oracle9iAS Portal

Minimal Edition

Standard Edition

Enterprise Edition

Oracle HTTP Server

Oracle9iAS Wireless




Oracle9iAS Portal

Minimal Edition

Standard Edition

Enterprise Edition

Oracle HTTP Server

Oracle9iAS Portal

Oracle9iAS Wireless




Oracle9iAS Portal

Oracle9iAS Wireless

Standard Edition

Enterprise Edition

Oracle HTTP Server

Oracle Enterprise Java Engine




移行パス

Standard Edition

Enterprise Edition

Oracle HTTP Server

Oracle Internet File System

Portal および Wireless ならびに

Oracle Internet File System のイ

ンストールおよび設定（サプリメンタル CD で使用可能）

Oracle HTTP Server



Oracle9iAS Portal


Standard Edition

Enterprise Edition

Oracle HTTP Server

Oracle9iAS Portal

Oracle9iAS Wireless



Portal および Wireless ならびに

Oracle Internet File System のイ

ンストールおよび設定（サプリメンタル CD で使用可能）

Oracle HTTP Server



Oracle9iAS Portal

Oracle9iAS Wireless


Enterprise Edition Oracle HTTP Server

Oracle9iAS Database Cache

適用なし







Oracle9iAS Discoverer

Business Intelligence およびForms

Oracle HTTP Server



Oracle9iAS Portal





Oracle HTTP Server



Oracle9iAS Portal


表表表表 1-2 Oracle9iAS リリースリリースリリースリリース 1 およびリリースおよびリリースおよびリリースおよびリリース 2 のインストール・タイプ（続き）のインストール・タイプ（続き）のインストール・タイプ（続き）のインストール・タイプ（続き）






移行パス


Oracle9iAS Forms Services


Oracle HTTP Server



Oracle9iAS Portal




Oracle9iAS Infrastructure Oracle9iASMetadata Repository



Oracle9iAS Portal

Oracle9iAS Wireless


Oracle9iAS Database Cache







Business Intelligence および

Forms ならびに次の列に示され

る構成およびOracle Internet File System（サプリメンタル CD で

使用可能）のインストールおよび設定

Oracle9iASMetadata Repositoryおよび Oracle Management Server が構成された

Oracle9iASInfrastructure のイン

ストール

Oracle HTTP Server



Oracle9iAS Portal


Oracle9iAS Wireless




表表表表 1-2 Oracle9iAS リリースリリースリリースリリース 1 およびリリースおよびリリースおよびリリースおよびリリース 2 のインストール・タイプ（続き）のインストール・タイプ（続き）のインストール・タイプ（続き）のインストール・タイプ（続き）






移行パス

データベースの移行が必要なコンポーネントデータベースの移行が必要なコンポーネントデータベースの移行が必要なコンポーネントデータベースの移行が必要なコンポーネント表 1-3 に、データベースの移行が必要なコンポーネントおよび関連する移行作業の一覧を示します。

表表表表 1-3 データベースの移行が必要なコンポーネントデータベースの移行が必要なコンポーネントデータベースの移行が必要なコンポーネントデータベースの移行が必要なコンポーネント

コンポーネントコンポーネントコンポーネントコンポーネント移行作業移行作業移行作業移行作業

Oracle9iAS Portal 1. Middle-Tier を移行します（データベース・アクセス記述子

（DAD）およびプロバイダを移行します）。

2. Portal データベースの既存 Portal メタデータを参照します。

Oracle9iAS Wireless 1. Oracle9iAS リリース 2（9.0.2）の Middle-Tier および

Infrastructure をインストールします。

2. Panama ユーザーを OID に移行します。

3. ユーザー・エージェント・プロパティ・ファイルをデータベースに移行します。

4. トランスフォーマを移行します。

5. サイトおよびノード・プロパティをデータベースに移行します。

Oracle9iAS Discoverer 1. Oracle9iAS リリース 2（9.0.2）の Middle-Tier および

Infrastructure をインストールします。

2. Middle-Tier を移行します（作業環境の移行、URL 参照の更新、

セッション・タイムアウトの設定およびビューアのカスタマイズの移行を行います）。

3. 顧客データベースの EUL 表を移行します。


1. Middle-Tier を移行します。

Oracle9iAS Personalization

1. データベースのアップグレードを実行します。


1. Oracle9iAS リリース 2（9.0.2）の Infrastructure をインストールし

ます。

2. OIDCA を実行して OID インスタンスをアップグレードします。


1. Oracle9iAS リリース 2（9.0.2）の Infrastructure をインストールし

ます。

2. データベースを移行します。


移行パス

コンポーネントの相互依存性コンポーネントの相互依存性コンポーネントの相互依存性コンポーネントの相互依存性この項では、Oracle9iAS のコンポーネント間の依存性を識別して、これらを移行するための管理方法を説明します。

表表表表 1-4 Oracle9iAS のコンポーネントの相互依存性のコンポーネントの相互依存性のコンポーネントの相互依存性のコンポーネントの相互依存性

コンポーネント名コンポーネント名コンポーネント名コンポーネント名Oracle9iAS リリースリリースリリースリリース 1（（（（1.0.2.2.x））））のコンポーネントの相互依存性のコンポーネントの相互依存性のコンポーネントの相互依存性のコンポーネントの相互依存性

Oracle9iAS リリースリリースリリースリリース 2（（（（9.0.2）の）の）の）のコンポーネントの相互依存性コンポーネントの相互依存性コンポーネントの相互依存性コンポーネントの相互依存性


なし Oracle HTTP Server、mod_oc4j

Oracle9iAS Portal Oracle HTTP Server、mod_plsql


Oracle HTTP Server、mod_plsql、mod_oc4j





Metadata Repository

Oracle9iAS Wireless

Oracle HTTP Server、mod_jserv Oracle HTTP Server、mod_oc4j


Oracle9iAS Portal




Metadata Repository




Oracle9iAS Portal




Metadata Repository


移行パス




Oracle9iAS Portal




Metadata Repository






Metadata Repository


データベース Metadata Repository

Oracle9iAS Unified Messaging

データベース Oracle HTTP Server、mod_oc4j




Metadata Repository

Oracle9iAS Personalization

データベース Oracle HTTP Server、mod_oc4j





表表表表 1-4 Oracle9iAS のコンポーネントの相互依存性（続き）のコンポーネントの相互依存性（続き）のコンポーネントの相互依存性（続き）のコンポーネントの相互依存性（続き）

コンポーネント名コンポーネント名コンポーネント名コンポーネント名Oracle9iAS リリースリリースリリースリリース 1（（（（1.0.2.2.x））））のコンポーネントの相互依存性のコンポーネントの相互依存性のコンポーネントの相互依存性のコンポーネントの相互依存性

Oracle9iAS リリースリリースリリースリリース 2（（（（9.0.2）の）の）の）のコンポーネントの相互依存性コンポーネントの相互依存性コンポーネントの相互依存性コンポーネントの相互依存性


移行の準備

移行中に依存性を確認するには、次の順序で移行します。

1. 初に、インフラストラクチャである、Oracle Internet Directory、Oracle9iAS Single Sign-On および Oracle Management Server を移行します。

2. 中間層インスタンスを（J2EE およびキャッシング・コンポーネントを、Migration Assistant を使用して）移行します。

3. 表に示される順序、つまりコンポーネントのインストール順序で残りのコンポーネント（Oracle9iAS Portal、Oracle9iAS Wireless、Oracle9iAS Reports Services など）を移行します。

移行の準備移行の準備移行の準備移行の準備この項では、リリース 1 からリリース 2 への移行前に実行する必要がある操作について説明します。リリース 1（1.0.2.1.x）がインストールされている場合は、初に Oracle9iAS リリース 1（1.0.2.2.x）へ移行する必要があります。

移行プロセスを開始する前に、次の操作を行ってください。

1. 必要に応じて、Oracle9iAS リリース 2（9.0.2）インスタンスを停止します。

2. 移行プロセスによって影響を受ける Oracle9iAS リリース 2（9.0.2）インスタンスのすべての構成ファイルおよびデータ・ファイルのバックアップを取ります。影響を受けるファイルがわからない場合は、該当するコンポーネントの移行に対する指示を参照してください。

3. Oracle9iAS リリース 1（1.0.2.2.x）インスタンスを停止します。

4. すべてのターゲット移行ディレクトリに対するアクセス権があることを確認します。

5. Oracle9iAS Infrastructure のパッチがインストールされていることを確認します。

関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server Oracle Application Server からの移行』


このマニュアルの使用方法

このマニュアルの使用方法このマニュアルの使用方法このマニュアルの使用方法このマニュアルの使用方法このマニュアルにはすべてのコンポーネントに対する指示が含まれているため、インストールされていないコンポーネントの指示はスキップしてください。

1. Oracle Enterprise Manager、Oracle9iAS Single Sign-On および Oracle Internet Directoryを移行するには、第 7 章「管理コンポーネントの移行」を参照します。

2. Oracle HTTP Server、Oracle9iAS Containers for J2EE および Oracle9iAS Web Cache を移行するには、第 2 章「Oracle9iAS Migration Assistant の使用」の指示に従います。

3. インストールされているコンポーネントを確認して、該当する章を参照してそれらのコンポーネントを移行します。移行するコンポーネントの種類と順序を決定します（1-11ページの「コンポーネントの相互依存性」を参照）。

4. JServ、Oracle JSP ページ、Oracle9iAS SOAP、Oracle8i PL/SQL および Oracle9iAS Forms Services を移行するには、第 3 章「インターネット・アプリケーションのコンポーネントの移行」を参照します。

5. Oracle9iAS Portal および Ultra Search を移行するには、第 4 章「Portal コンポーネントの移行」を参照します。

6. Oracle9iAS Wireless を移行するには、第 5 章「Wireless コンポーネントの移行」を参照します。

7. Oracle9iAS Reports Services、Oracle9iAS Discoverer および Oracle9iAS Personalizationを移行するには、第 6 章「Business Intelligence コンポーネントの移行」を参照します。

8. Oracle9iAS InterConnect および Oracle Workflow を移行するには、第 8 章「E-Business統合コンポーネントの移行」を参照します。


Oracle9iAS Migration Assistant の

2
Oracle9iAS Migration Assistant の使用の使用の使用の使用
この章では、Oracle HTTP Server、Oracle9iAS Containers for J2EE および Web Cache をOracle9iAS リリース 1（1.0.2.2.x）から Oracle9iAS リリース 2（9.0.2）に移行するツールである Oracle9iAS Migration Assistant について説明します。 Oracle9iAS Migration Assistantは、GUI バージョンとコマンドライン・バージョンで使用可能です。

Oracle9iAS Migration Assistant は移行プロセスの大部分を自動化することで、手動でのファイルの移行に関するエラーを削減し、手動では時間のかかるプロセスが早く進むようにします。また、移行後すぐにアプリケーションが使用できるように準備されるため、インストール後すぐに新しいリリースの Oracle9iAS を使用できます。

この章の項は次のとおりです。

� Oracle9iAS Migration Assistant の理解

� Oracle HTTP Server の移行プロセス

� Oracle9iAS Containers for J2EE（OC4J）の移行プロセス

� Oracle9iAS Web Cache の移行プロセス

� Oracle9iAS Migration Assistant のインストール

� アプリケーションの移行

� Oracle9iAS Migration Assistant の再起動

注意注意注意注意 : Oracle9iAS Migration Assistant は、リリース 1（1.0.2.2.x）からの移行に対してのみ使用できます。

使用 2-1

Oracle9iAS Migration Assistant の理解

Oracle9iAS Migration Assistant の理解の理解の理解の理解この項では、Oracle9iAS Migration Assistant の全体的な機能および各移行オプションの特別な機能の詳細について説明します。 Oracle9iAS Migration Assistant は、次のように設計されています。

� 同じコンピュータの Oracle9iAS リリース 1（1.0.2.2.x）の Oracle ホームから Oracle9iASリリース 2（9.0.2）の Oracle ホームに、指定されたコンポーネントを移行します。

� すべての移行アクティビティを記録するログ・ファイルを作成します。

� カスタマイズされていない Oracle9iAS リリース 2（9.0.2）のインストールに対して実行します。

� 移行プロセスを監査可能にします。ターゲットOracleホームであるOracle9iASリリース2（9.0.2）にフラグを設定して、Oracle9iAS Migration Assistant による移行が実行されたことを示します。すべての移行アクティビティがログ・ファイルに記録されます。 2-37ページの「Oracle9iAS Migration Assistant の再起動」を参照してください。

Oracle9iAS Migration Assistant を起動する前に、使用する予定の各オプションに関する項をお読みください。

� Oracle HTTP Server の移行プロセス（2-2 ページ）

� Oracle9iAS Containers for J2EE（OC4J）の移行プロセス（2-10 ページ）

� Oracle9iAS Web Cache の移行プロセス（2-10 ページ）

� Oracle9iAS Migration Assistant（GUI バージョン）の使用（2-27 ページ）

� Oracle9iAS Migration Assistant（コマンドライン・バージョン）の使用（2-34 ページ）

Oracle HTTP Server の移行プロセスの移行プロセスの移行プロセスの移行プロセスこの項では、Oracle HTTP Server の移行オプションの機能について説明し、各コンポーネントに移行された要素の一覧を示します。この項の項目は次のとおりです。

� Oracle HTTP Server の移行候補

� Oracle HTTP Server のディレクティブの移行プロセス

� Oracle HTTP Server の移行に対するバックアップおよび監査方法

Oracle HTTP Server の移行候補の移行候補の移行候補の移行候補Oracle HTTP Server の移行オプションでは、次の構成ファイル、プログラム、静的ドキュメントおよびモジュールが移行の候補として認識されます。

� httpd.conf ファイル。（このファイルを選択しないと、他のファイルが移行されません。）



� 9.0.2 インスタンスにない cgi および fastcgi プログラムデフォルトの Oracle9iAS リリース 1.0.2.2 インスタンスには、次のプログラムが含まれています。

ORACLE_HOME_1/Apache/Apache/cgi-bin/printenvORACLE_HOME_1/Apache/Apache/cgi-bin/test-cgiORACLE_HOME_1/Apache/Apache/fastcgi-bin/echoORACLE_HOME_1/Apache/Apache/fastcgi-bin/echo2

httpd.confの ScriptAliasまたは Options ExecCGIディレクティブで定義されているその他の cgi または fastcgi アプリケーションは移行候補です。

� 次の場所にある新規の静的ドキュメントまたはディレクトリ

ORACLE_HOME_1/Apache/Apache/htdocs

次のサブディレクトリは例外です。

webapp

onlineorders_html

manual

doc

_pages

� 次のディレクトリ下にある任意の新規ファイルまたはディレクトリ

ORACLE_HOME_1/Apache/Apache/htdocs/WEB-INF（サブディレクトリを含む）

ORACLE_HOME_1/Apache/Apache/htdocs/demo（サブディレクトリを含む）

注意注意注意注意 : oracle_apache.confまたは jserv.conf以外の Include ディレクティブで命名された任意の構成ファイルも移行できます。たとえば、ユーザー定義の構成ファイル myFile.confおよび httpd.confに次のディレクティブがあるとします。

include "home/myDirectory/myFile.conf"

この場合、移行処理中に、ディレクティブおよびファイルの移行を選択できます。

注意注意注意注意 : index.htmlは、デフォルトとファイル・サイズが異なる場合のみ移行されます。ファイル・サイズが同じでも内容が異なる場合は、index.htmlを手動で移行する必要があります。

Oracle9iAS Migration Assistant の使用 2-3


� Oracle9iAS リリース 1（1.0.2.2.x）のデフォルト・セットにはないが LoadModule ディレクティブで指定されている任意のモジュールの .so（共有オブジェクト）ファイル。

デフォルト・モジュールデフォルト・モジュールデフォルト・モジュールデフォルト・モジュール

表 2-1 に、Oracle9iAS リリース 1（1.0.2.2.x）に含まれるモジュールのデフォルト・セットの一覧を示します。

表表表表 2-1 デフォルト・モジュールデフォルト・モジュールデフォルト・モジュールデフォルト・モジュール

モジュール名モジュール名モジュール名モジュール名

access_module dms_module perl_module

action_module env_module proxy_module

agent_log_module example_module referer_log_module

alias_module expires_module rewrite_module

anon_auth_module fastcgi_module setenvif_module

asis_module headers_module speling_module

auth_module imap_module ssl_module

autoindex_module includes_module status_module

cern_meta_module info_module unique_id_module

cgi_module mime_magic_module userdir_module

dbm_auth_module mime_module usertrack_module

define_module mmap_static_module vhost_alias_module

digest_module negotiation_module

dir_module oprocmgr_module



httpd.conf のデフォルト・ディレクティブのデフォルト・ディレクティブのデフォルト・ディレクティブのデフォルト・ディレクティブ

表 2-2 に、httpd.confファイルの両方のバージョンにあるディレクティブの一覧を示します。

表表表表 2-2 httpd.conf のデフォルト・ディレクティブのデフォルト・ディレクティブのデフォルト・ディレクティブのデフォルト・ディレクティブ

ディレクティブ名ディレクティブ名ディレクティブ名ディレクティブ名

AccessFileName IfDefine ScriptAlias

AddCharset IfModule ServerAdmin

AddEncoding IndexOptions ServerName

AddHandler KeepAlive ServerRoot

AddIcon KeepAliveTimeout ServerSignature

AddIconByEncoding LanguagePriority ServerType

AddIconByType Listen SetEnv

AddLanguage LoadModule SetHandler

Alias Location SSLEngine

Allow LogFormat SSLLog

AllowOverride LogLevel SSLLogLevel

BrowserMatch MaxClients SSLMutex

CustomLog MaxKeepAliveRequests SSLOptions

DefaultIcon MaxRequestsPerChild SSLPassPhraseDialog

DefaultType MaxSpareServers SSLRandomSeed

Deny MIMEMagicFile SSLSessionCache

Directory MinSpareServers SSLSessionCacheTimeout

DirectoryIndex Options StartServers

DocumentRoot Order Timeout

ErrorLog PassEnv TransferLog

ExtendedStatus PerlHandler TypesConfig

Files PerlSendHeader UseCanonicalName

Group PidFile User

HeaderName Port UserDir

HostnameLookups ReadmeName



これは、Oracle HTTP Server の移行に対するディレクティブのデフォルト・セットです。これらのディレクティブは、1.0.2.2 および 9.0.2 インスタンスの httpd.confファイルのデフォルト・バージョンで発生します。 Oracle9iAS Migration Assistant によって違いがハイライトされるので、移行するディレクトリを選択できます。ディレクティブの設定が両方のファイルで同じ場合は、処理は行われません。

次の移行プロセスの説明では、ディレクティブはプリミティブ・ディレクティブまたはコンテナ・ディレクティブと呼ばれています。プリミティブ・ディレクティブは、次のように単一行を使用します。

Timeout 300

KeepAlive on

コンテナ・ディレクティブは複数行を使用し、開始ディレクティブと終了ディレクティブを持ち、引数（プリミティブ・ディレクティブ）を含みます。たとえば、次のようになります。

<Directory "/private2/myDirectory"> Options FollowSymLinks MultiViews AllowOverride None</Directory>

上記のコンテナ・ディレクティブには、開始ディレクティブ <Directory "/private2/myDirectory">および終了ディレクティブ </Directory>があります。引数は、プリミティブ・ディレクティブ Options FollowSymLinks MultiViewsおよびAllowOverride Noneです。

移行されない移行されない移行されない移行されない Oracle HTTP Server 要素要素要素要素Oracle HTTP Server 移行オプションでは、次の要素は移行されません。

JServ - JServ は、従来の使用をサポートするためにのみ Oracle9iAS リリース 2（9.0.2）に含まれています。サーブレット環境には Oracle9iAS Containers for J2EE（OC4J）を推奨します。リリース 1 で JServ を使用していてリリース 2 で OC4J を使用する場合は、3-20 ページの「JServ から OC4J への移行」を参照してください。 JServ を手動で移行するプロセスが説明されています。

mod_plsql の使用に関連する構成ファイルの使用に関連する構成ファイルの使用に関連する構成ファイルの使用に関連する構成ファイル - oracle_apache.conf、plsql.conf、dads.conf、cache.confなどのファイルおよび（oracle_apache.confの）httpd.confの Include ディレクティブは移行から除外されます。

関連項目関連項目関連項目関連項目 : mod_plsql 構成の移行に関する指示は第 4 章「Portal コンポーネントの移行」、「データベース・アクセス記述子（DAD）の移行」、パラメータ変更の完全なリストは「リリース 2 での mod_plsql パラメータの変更」を参照してください。



Oracle HTTP Server のディレクティブの移行プロセスのディレクティブの移行プロセスのディレクティブの移行プロセスのディレクティブの移行プロセスディレクティブを移行するために、Oracle9iAS Migration Assistant では次の処理が行われます。

1. デフォルトの（カスタマイズされていない）ファイルである httpd.conf.defaultと異なるリリース 1（1.0.2.2）の httpd.confファイル、または新規の（ディレクティブのデフォルト・セットに含まれていない）httpd.confファイルのディレクティブを提示します。デフォルト・ファイルである httpd.conf.defaultが存在しないと、プログラムは動作しません。

デフォルトでは、これらすべてのディレクティブがチェックボックスで移行用に選択され、スクロール・リストに提示されます。チェックボックスのチェックを外すと、移行からそのディレクティブを除外できます。

2. 選択されたディレクティブが、差分ファイルに書き込まれます。

3. 差分ファイルは、次のようにリリース 2（9.0.2）の httpd.confファイルにマージされます。

� 変更されたデフォルト・ディレクティブは、リリース 2（9.0.2）の httpd.confファイルの対応ディレクティブを置換します。

� デフォルト以外のディレクティブ（表 2-2 にリストされてないディレクティブ）は、リリース 2（9.0.2）の httpd.confファイルの末尾に書き込まれます。

注意注意注意注意 : 例外として、mod_proxy ディレクティブは、デフォルトで選択されていません。すべての mod_proxy ディレクティブは、デフォルトでチェックが外されています。「httpd.conf: Directives」画面（2-31 ページに表示）で明示的に選択されないかぎり、これらのディレクティブは移行されません。

注意注意注意注意 : コンテナ・ディレクティブはその全体が移行されます。移行するコンテナ・ディレクティブを選択すると、そのコンテナ・ディレクティブの引数（プリミティブ・ディレクティブ）がすべて選択されます。このため、コンテナ・ディレクティブの上位（開始および終了ディレクティブ）のみが移行に選択されているものとして提示されます。

パス関連ディレクティブは、ソース・パスではなく宛先パスで提示されます。たとえば、次のようなリリース 1 構成のディレクティブがあります。

ORACLE_HOME_1/Apache/Apache/myAlias

画面では、次のように表示されます。

ORACLE_HOME_2/Apache/Apache/myAlias



4. JServ ディレクティブが廃棄されます。

SSL 設定の移行設定の移行設定の移行設定の移行

Oracle9iAS リリース 2（9.0.2）の mod_ossl を持つ標準 SSL の置換に対応するために、Oracle9iAS Migration Assistant は、リリース 1 構成（例 2-2）に基づいて、mod_ossl のディレクティブである SSLWallet（例 2-1）を自動的に作成します。次に、Oracle Wallet を生成するプログラムが起動されます。 Oracle9iAS Migration Assistant の起動前にリリース 1 ファイルの SSL 設定をコメントアウトすると、移行中に Wallet が生成されないようにすることを選択できます。

移行で有効な Wallet が生成されるようにするために、リリース 1 構成にトラスト・ポイント（証明書の署名者）を指定する必要があります。それには、次の 2 つの方法があります。

� 署名者の証明書（証明連鎖）をリリース 1 のサーバー証明書ファイルに連結します。

� すべての署名者を 1 つのファイルに連結し、リリース 1 の httpd.confファイルのSSLCertificateChainFileディレクティブを使用します。

また、リリース 1 の httpd.confファイルの SSLCACertificateFileおよびSSLCACertificatePathで他の認証局の証明書を指定すると、Wallet に他の認証局の証明書をインポートできます。

関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server セキュリティ・ガイド』

注意注意注意注意 : リリース 1 のデフォルト SSL 証明書は認証局 'oracle demoCA' によって署名されており、証明書は次の場所にあります。

ORACLE_HOME_1/Apache/Apache/conf/ssl.crt/demoCAcert.crt.

移行前に、SSLCertificateChainFile ディレクティブが次のデフォルト SSL証明書を参照するように設定する必要があります。

SSLCertificateChainFile ORACLE_HOME_1/Apache/Apache/conf/ssl.crt/demoCAcert.crt



Oracle9iAS Migration Assistant は、SSL 証明書キー・ファイルおよび Wallet パスワードを次のように管理します。

Oracle9iAS リリース 2（9.0.2）（IfModule）およびリリース 1（IfDefine）に対するhttpd.confの SSL ディレクティブを次に示します。

例例例例 2-1 SSL ディレクティブ（リリースディレクティブ（リリースディレクティブ（リリースディレクティブ（リリース 2））））

<IfModule mod_ossl.c> <VirtualHost _default_:4443> SSLWallet wallet location SSLVerifyClient optional SSLProtocol all </VirtualHost></IfModule>

例例例例 2-2 SSL ディレクティブ（リリースディレクティブ（リリースディレクティブ（リリースディレクティブ（リリース 1））））

<IfDefine SSL> <VirtualHost _default_:443> SSLCertficateFile certificate location SSLCertificateKeyFile key location

SSLCertificateChainFile chain location SSLVerifyClient optional_no_ca SSLProtocol TLSv1 </VirtualHost></IfDefine>

次の変更点に注意してください。

� SSLVerifyClientは、optional_no_caに設定されていた場合は、optionalに設定されます。

� SSLProtocolは、TLSv1に設定されていた場合は、allに設定されます。

表表表表 2-3 SSL パスワードの要件パスワードの要件パスワードの要件パスワードの要件

リリースリリースリリースリリース 1 のののの SSL 証明書キー・ファイルの証明書キー・ファイルの証明書キー・ファイルの証明書キー・ファイルのパスワードパスワードパスワードパスワード移行中の処理移行中の処理移行中の処理移行中の処理

デフォルトの 'welcome' パスワードパスワードは要求されません。

'welcome' 以外のパスワード正しいパスワードを入力するように要求されます。

パスワードの割当てなしパスワードは要求されず、生成される Wallet パスワードが 'welcome' に設定されます。



次のディレクティブは mod_ossl では無効なので、SSLWalletによって置換されます。

� SSLCertificateFile

� SSLCertificateKeyFile

� SSLCertificateChainFile

� SSLCACertificatePath

� SSLCACertificateFile

� SSLRandomSeed

� SSLVerifyDepth

移行中に、Oracle9iAS Migration Assistant によって証明書関連のディレクティブが抽出され、Wallet を生成するプログラムが起動されます。 Wallet 関連のディレクティブは差分ファイルに書き込まれます。 SSLWallet の値は、SSLCertificateFileの値か、パス関連の場合は次のようになります。

ORACLE_HOME_2/Apache/Apache/conf/ssl.wlt/certificate name

Oracle HTTP Server の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法 Oracle9iAS Migration Assistant は、次の機能を実行して移行プロセスを監査する方法を提供します。

� 9.0.2 のデフォルトの httpd.confファイルのバックアップを httpd.conf.migbakという名前で作成します。パーサーによって書き込まれているため、このファイルは、httpd.confのフォーマットと同じではありませんが、内容はまったく同じです。

� すべての移行アクティビティおよびエラーが次の場所に記録されます。

ORACLE_HOME_2/migration/log/iASMigration.log

Oracle9iAS Containers for J2EE（（（（OC4J）の移行プロセス）の移行プロセス）の移行プロセス）の移行プロセスこの項では、OC4J の移行オプションの機能について説明します。この項の項目は次のとおりです。

� OC4J の移行候補

� OC4J 構成ファイルの移行プロセス

� OC4J の移行に対するバックアップおよび監査方法



OC4J の移行候補の移行候補の移行候補の移行候補OC4J の移行オプションでは、次の構成ファイルおよびアプリケーションが移行の候補として認識されます。

� principals.xmlおよび data-sources.xmlファイル。

� .ear ファイル形式で 1.0.2.2 インスタンスの server.xmlファイルに定義されたアプリケーション。

スタンドアロンスタンドアロンスタンドアロンスタンドアロン OC4J インスタンスと移行インスタンスと移行インスタンスと移行インスタンスと移行Oracle9iAS リリース 1（1.0.2.2.x）のインストール前に OC4J をスタンドアロン構成でインストールしている場合、Oracle9iAS Migration Assistant は Oracle9iAS リリース 1（1.0.2.2.x）にバンドルされた OC4J インスタンスのみを移行することに注意してください。

たとえば、次のような場合が想定されます。

1. OC4J インスタンスがインストールおよび設定され、アプリケーションがデプロイされています。

2. 続いて、Oracle9iAS リリース 1（1.0.2.2.x）が、バンドルされた OC4J インスタンスとともにインストールされました。アプリケーションは元のインスタンスにデプロイされたままです。

3. Oracle9iAS Migration Assistant が実行されます。

アプリケーションは、Oracle9iAS リリース 1（1.0.2.2.x）の OC4J インスタンスになかったため、移行されません。

注意注意注意注意 : 移行するには、アプリケーションは .ear ファイル形式でソースのserver.xmlファイルに定義されている必要があります。アプリケーションは、DCM（Distributed Configuration Management）によってリリース2（9.0.2）の Oracle9iAS インスタンスにデプロイされます。アプリケーションは以前 9.0.2 にインストールされていない（9.0.2 インスタンスは新規の変更されていない Oracle9iAS インストールである）ことが前提ですが、アプリケーションが存在する場合は上書きされます。

Oracle9iAS Migration Assistant は、.ear 以外の形式（.war、展開されているなど）のアプリケーションは移行しません。



OC4J 構成ファイルの移行プロセス構成ファイルの移行プロセス構成ファイルの移行プロセス構成ファイルの移行プロセスOC4J の移行オプションでは、次の処理が行われます。

1. 選択された principals.xmlおよび data-sources.xmlを $ORACLE_HOME_1/J2EE から $ORACLE_HOME_2/J2EE にコピーします。

2. ORACLE_HOME_1 の server.xmlファイルからアプリケーション情報を読み込んで、移行するアプリケーションを選択するように要求します。

3. ORACLE_HOME_2 のデフォルト OC4J インスタンスを起動します。

4. ORACLE_HOME_2 の移行済アプリケーションを再デプロイします。

5. デフォルト OC4J インスタンス（および実行中であれば Oracle9iAS のすべて）を停止します。

OC4J の移行におけるの移行におけるの移行におけるの移行における J2EE 準拠要件準拠要件準拠要件準拠要件Oracle9iAS リリース 2（9.0.2）では、OC4J のデプロイによって J2EE 準拠ルールが施行されます。このため、Oracle9iAS Migration Assistant では J2EE に 100% 準拠していないアプリケーションが移行されない場合があります。 Oracle9iAS Migration Assistant はファイルを読み込んで Oracle9iAS リリース 2（9.0.2）にデプロイしようとしますが、デプロイが失敗した場合はアプリケーションが J2EE 準拠でない可能性があります。

Oracle9iAS Migration Assistant が何らかの理由でアプリケーションをデプロイできない場合は、例外が記録されます（準拠の問題として明示的に説明されない場合があります）。

J2EE アプリケーションの開発は標準化され移植可能ですが、XML 構成ファイルは異なります。アプリケーションを OC4J にデプロイする前に、複数の XML ファイルを設定する必要が生じる場合があります。必要とされる設定は、アプリケーションが使用するサービスによって異なります。たとえば、アプリケーションがデータベースを使用する場合は、data-sources.xmlファイルの DataSource オブジェクトを設定する必要があります。

J2EE 準拠に対する準拠に対する準拠に対する準拠に対する EAR ファイルの検証ファイルの検証ファイルの検証ファイルの検証

dcmctl ユーティリティによって、J2EE 準拠の検証コマンドが提供されます。 1 つの入力、つまり EAR ファイルの名前が必要とされ、そのファイルの非準拠特性の一覧が示されます。構文は次のとおりです。

dcmctl validateEarFile -v -f name.ear

ここでの name は EAR ファイルの名前です。 -v は dcmctl の冗長オプションを指定し、これによってコマンドのも詳細な出力が提供されます。



必要に応じて検証ルーチンが Web の DTD（Sun 社のサイトなど）にアクセスできるようにプロキシ設定を行う必要があります。これを行うには、プロキシのホスト名およびポートを指定する ORACLE_DCM_JVM_ARGS という環境変数を定義します。たとえば、tcsh を使用するとコマンドは次のようになります。

tcsh> setenv ORACLE_DCM_JVM_ARGS "-DhttpProxy.host=www-proxy.hostname.com -DhttpProxy.port=9999"

ここで、hostname はホスト名で、9999 はポート番号です。（この環境変数の定義方法はプラットフォームに依存します。）

例例例例 2-3 J2EE 準拠アプリケーションの準拠アプリケーションの準拠アプリケーションの準拠アプリケーションの validateEarFile コマンドと出力コマンドと出力コマンドと出力コマンドと出力

dcmctl validateEarFile -v -f simple.ear

No J2EE XML/DTD validation errors were found

例例例例 2-4 J2EE 非準拠アプリケーションの非準拠アプリケーションの非準拠アプリケーションの非準拠アプリケーションの validateEarFile コマンドと出力コマンドと出力コマンドと出力コマンドと出力

dcmctl validateEarFile -v -f petstore.ear

Warning: J2EE/DTD validation errors were found

ADMN-906001 {0} Base Exception: oracle.ias.sysmgmt.deployment.j2ee.exception.J2eeDeploymentException:Cannot get xml document by parsing /var/tmp/jar50152.tmp: Invalid element 'servlet' in content of 'web-app', expected elements '[servlet-mapping, session-config, mime-mapping, welcome-file-list, error-page, taglib, resource-ref, security-constraint, login-config, security-role, env-entry, ejb-ref]'.

アプリケーションはデプロイ可能でも、予測不可能または望ましくないサーバー動作が発生する場合があるため、移行前にすべてのアプリケーションが J2EE に全般的に準拠しているか確認することをお薦めします。たとえば、各アプリケーションで一意なコンテキスト・ルートが application.xmlに定義されていることを確認します。

OC4J の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法Oracle9iAS Migration Assistant は、次の機能を実行して移行プロセスを監査する方法を提供します。

� 各構成ファイルのバックアップを作成します。コピーは、ファイル名は同じで、拡張子は .SAVED_COPYです。

� すべての移行アクティビティおよびエラーが次の場所に記録されます。




Oracle9iAS Web Cache の移行プロセスの移行プロセスの移行プロセスの移行プロセスこの項では、Web Cache の移行オプションの機能について説明します。この項の項目は次のとおりです。

� Web Cache の移行候補

� Web Cache の移行プロセス

� Web Cache の移行に対するバックアップおよび監査方法

Web Cache の移行候補の移行候補の移行候補の移行候補Web Cache の移行オプションでは、ORACLE_HOME_1 の webcache.xmlファイルのほとんどの要素が認識されます。これらの要素は、次の「Web Cache の移行プロセス」に一覧表示されています。

Oracle9iAS Migration Assistant では、次のものは移行されません。

� internal.xmlファイル。 internal.xmlファイルの CALYPSONETINFO 要素からネットワーク・タイムアウト、キープ・アライブの値および osrecv値を ORACLE_HOME_2 の webcache.xmlファイルに手動で移行する必要があります。

� 明確化に使用されるヘッダーが HOST ヘッダーの場合はMULTIVERSIONHEADERRULE。 Oracle9iAS リリース 2（9.0.2）の Web Cache では複数のサイトがサポートされます。サイトからサーバーへのマッピングの詳細は、Web Cache のマニュアルを参照してください。

セッション定義の移行セッション定義の移行セッション定義の移行セッション定義の移行

セッション定義は、セッション名、Cookie、URL パラメータおよびデフォルト値で構成されています。 Oracle9iAS Migration Assistant では、次のようにセッション定義が移行されます。

� セッション名、Cookie、URL パラメータおよびデフォルト値がリリース 1 とリリース 2で同じ場合、セッション定義は移行されません。

� セッション名が同じで、Cookie、URL パラメータまたはデフォルト値が異なる場合、Oracle9iAS Migration Assistant によってセッションがそのまま移行され、リリース 2セッションの名前が変更されて参照が更新されます。

警告警告警告警告 : 元のリリース 2 の Web Cache セッション定義を参照するWEBCACHETAG を使用していたアプリケーションは、名前変更されたセッション定義を使用するように変更する必要があります。



Web Cache の移行プロセスの移行プロセスの移行プロセスの移行プロセスWeb Cache の移行オプションでは、次の処理が行われます。

1. webcache.xmlファイルの次の要素を ORACLE_HOME_1 から ORACLE_HOME_2 にコピーします。

� SECURITY

SECURESUBNET（SECURITY のサブ要素、トラステッド・サブネット）

� WATCHDOG

� REQUESTBACKLOGTIMELIMIT（SITE 要素の属性）

ORACLE_HOME_2の webcache.xmlの初の SITE 要素にコピーされます。

� ERRORPAGES

ORACLE_HOME_1 の webcache.xmlファイルから、初の SITE 要素下にあるORACLE_HOME_2 の webcache.xmlファイルにコピーされます。

� MULTIVERSIONCOOKIESRULE

ORACLE_HOME_1 の webcache.xmlファイルからコピーされ、ORACLE_HOME_2 の webcache.xmlファイルの GLOBALCACHINGRULES 要素の同じセクションのデータとマージされます。重複または冗長なマルチバージョン Cookieルールが発生する可能性があります。解決法は、2-36 ページの「Web Cache の移行の完了」を参照してください。

� SESSIONCACHINGRULE

ORACLE_HOME_1 の webcache.xmlファイルから、GLOBALCACHINGRULESセクションにある ORACLE_HOME_2 の webcache.xmlファイルにコピーされます。重複または冗長なセッション・キャッシュ処理ルールが発生する可能性があります。解決法は、2-36 ページの「Web Cache の移行の完了」を参照してください。

� EXPIRATIONRULE

ORACLE_HOME_1 の webcache.xmlファイルからコピーされ、ORACLE_HOME_2 の webcache.xmlファイルの GLOBALCACHINGRULES 要素の同じセクションのデータとマージされます。重複または冗長な期限切れルールが発生する可能性があります。解決法は、2-36 ページの「Web Cache の移行の完了」を参照してください。

注意注意注意注意 : Oracle9iAS Migration Assistant では、パスワードは移行されません。管理者パスワードおよび無効化パスワードには、リリース 2 のインストール時のデフォルト値があります。デフォルト・パスワードの詳細は、Web Cache のマニュアルを参照してください。



� CACHEABILITY

ORACLE_HOME_1 の webcache.xmlファイルから、GLOBALCACHINGRULESセクションにある ORACLE_HOME_2 の webcache.xmlファイルにコピーされます。重複または冗長なキャッシュ可能性ルールが発生する可能性があります。解決法は、2-36 ページの「Web Cache の移行の完了」を参照してください。

� HOST

ORACLE_HOME_1 の webcache.xmlファイルのすべてのアプリケーション Webサーバーが、ORACLE_HOME_2 の webcache.xmlファイルに移行されます。ホスト ID は、これらのホストそれぞれに生成されます。

� EVENTLOG

� ACCESSLOG（LOGDIR 属性を除く）

� RESOURCELIMITS

Web Cache の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法の移行に対するバックアップおよび監査方法Oracle9iAS Migration Assistant は、次の機能を実行して移行プロセスを監査する方法を提供します。

1. ORACLE_HOME_2 の webcache.xmlファイルのバックアップ・コピーを作成します。バックアップ・ファイルの名前は webcache.xml.backupです。

2. すべての移行アクティビティおよびエラーが次の場所に記録されます。


注意注意注意注意 : 移行された CACHEABILITY ルールは GLOBALCACHINGRULESセクションで定義されているため、ORACLE_HOME_2 の webcache.xmlファイルに定義されたすべての SITES に適用されます。

後で ORACLE_HOME_2 に別の SITE 要素を定義する場合は、そのキャッシュ可能性ルールも定義する必要があります。 GLOBALCACHINGRULESセクションで定義されるルールは、新規 SITE にも適用されます。


Oracle9iAS Migration Assistant のインストール

Oracle9iAS Migration Assistant のインストールのインストールのインストールのインストールこの項では、Oracle9iAS Migration Assistant のインストールにおけるハードウェア要件およびソフトウェア要件に関する情報を提供します。項目は次のとおりです。

� ハードウェア要件

� ソフトウェア要件

� Oracle Universal Installer の起動

ハードウェア要件ハードウェア要件ハードウェア要件ハードウェア要件次の表 2-4「Oracle9iAS Migration Assistant のハードウェア要件」に、Oracle9iAS Migration Assistant の低ハードウェア要件を示します。

表表表表 2-4 Oracle9iAS Migration Assistant のハードウェア要件のハードウェア要件のハードウェア要件のハードウェア要件

ソフトウェア要件ソフトウェア要件ソフトウェア要件ソフトウェア要件Oracle9iAS Migration Assistant では、次のソフトウェアが必要です。

� Oracle9iAS リリース 2（9.0.2）の Middle-Tier

� Oracle Universal Installer リリース 2.1.0.9 以上

� JDK 1.3.1

ハードウェア項目ハードウェア項目ハードウェア項目ハードウェア項目低要件低要件低要件低要件

CPU1

1 複数 CPU コンピュータをお薦めします。

SPARC プロセッサ

メモリー 128MB

モニター 256 色表示機能



オペレーティング・システム要件オペレーティング・システム要件オペレーティング・システム要件オペレーティング・システム要件表 2-5 に、Oracle9iAS Migration Assistant のインストール前にダウンロードする必要があるSolaris オペレーティング・システムのパッチの一覧を示します。パッチは次の URL からダウンロードできます。

http://sunsolve.sun.com

表表表表 2-5 Solaris オペレーティング・システムのパッチオペレーティング・システムのパッチオペレーティング・システムのパッチオペレーティング・システムのパッチ

オペレーティング・オペレーティング・オペレーティング・オペレーティング・システムシステムシステムシステムバージョンバージョンバージョンバージョン

Solaris 2.6 � Linker パッチ : 107733-09 以上

� /usr/lib/libthread.so.1 パッチ : 105568-23 以上

� libaio、libc、watchmalloc パッチ : 105210-38 以上

� X Input & Output Method パッチ : 106040-17 以上

� Linker パッチ : 105490-07 以上

� OpenWindows 3.6: Xsun パッチ : 105633-59 以上1

� 中国語 TrueType フォント : 106409-01 以上2

� SunOS 5.6: JDK1.2.1_03 は、ISO8859-01 ロケールの致命的エ

ラーで失敗します。 108091-03 以上3

� CDE 1.2: libDtSvc パッチ（推奨）: 105669-10 以上

� Motif 1.2.7: ランタイム・ライブラリ・パッチ : 105284-45 以上

� SunOS 5.6: カーネル更新パッチ（推奨）: 105181-30 以上

� Patchadd および patchrm パッチ : 106125-11 以上

� /kernel/drv/mm パッチ : 106429-02 以上

� C++ 共有ライブラリ・パッチ : 105591-09 以上

� ユーロ・サポート・パッチ : 106842-09 以上および 106841-01以上



Solaris 7（2.7） � Libthread パッチ : 106980-17 以上

� カーネル更新パッチ : 106541-17 以上

� /kernal/fs/sockfs パッチ : 109104-04 以上

� /usr/lib/fs/fsck パッチ : 107544-03 以上

� Motif ランタイム・ライブラリ・パッチ : 107081-37 以上

� X Input & Output Method パッチ : 107636-08 以上

� OpenWindows 3.6.1 Xsun パッチ : 108376-29 以上 1

� CDE ウィンドウ・マネージャ・パッチ : 107226-18 以上

� CDE 1.3 libDT Widget パッチ : 108374-05 以上

� zh.GBK ロケールの不良フォントを置換するパッチ : 107153-01以上

� Linker パッチ : 106950-16 以上

� C++ 共有ライブラリ・パッチ : 106300-09 以上および 106327-08以上

� Open Windows 3.6.1 libX+ パッチ : 107656-07 以上

� CDE 1.3: dtsession パッチ : 107702-07 以上

Solaris 8（2.8） � Xsun パッチ : 108652-37 以上

� CDE dtwm パッチ : 108921-13 以上

� Motif 2.1 パッチ : 108940-37 以上

1 このパッチはアジア地域にのみ必要です。2 このパッチは、Swing アプリケーションで繁体字中国語を表示する場合にのみ必要です。3 このパッチは、ISO8859-1 または ISO8859-15 の文字エンコーディングを使用するロケールにのみ必要

です。

オペレーティング・オペレーティング・オペレーティング・オペレーティング・システムシステムシステムシステムバージョンバージョンバージョンバージョン



Oracle Universal Installer の起動の起動の起動の起動次の手順に従って、Oracle9iAS Migration Assistant をインストールする Oracle Universal Installer を起動します。

1. コンピュータで実行されているすべての Oracle のプロセスおよびサービス（Oracleデータベースなど）を停止します。

2. CD-ROM ドライブに Supplemental CD を挿入します。

3. インストール CD-ROM をマウントします。

Oracle 製品インストール CD-ROM は RockRidge フォーマットです。 Solaris Volume Management ソフトウェア（Sun SPARC Solaris によってデフォルトでインストール）を使用している場合は、CD-ROM をディスク・ドライブに挿入すると自動的にcdrom/9ias_supplementalにマウントされます。

Solaris Volume Management ソフトウェアを使用していない場合は、CD-ROM を手動でマウントする必要があります。 CD-ROM を手動でマウントまたはアンマウントするには、root 権限が必要です。ドライブから CD-ROM を取り除く前に、必ず CD-ROM をアンマウントしてください。

4. Supplemental CD-ROM を手動でマウントするには、次の手順を実行します。

5. CD-ROM ドライブに Supplemental CD を挿入します。

6. root ユーザーとしてログインします。

7. CD-ROM マウント・ポイント・ディレクトリを作成します。

prompt> mkdir mount_point

8. CD-ROM ドライブをマウント・ポイント・ディレクトリにマウントして、root アカウントを終了します。

prompt> mount options device_name mount_point

prompt> exit

次の例では、Solaris Volume Management ソフトウェアを使用せずに CD-ROM が手動で /cdromにマウントされます。 root ユーザーとして、次のコマンドを実行します。

prompt> mkdir /cdromprompt> mount -r -F hsfs device_name /cdrom

a. root ユーザーとしてログアウトします。

注意注意注意注意 : これは重要な手順です。 root ユーザーとして Oracle Universal Installer を起動した場合、root ユーザーのみが Oracle9iAS Migration Assistant を管理する権限を持ちます。



b. CD-ROM から Oracle Universal Installer を実行します。

c. oracleユーザーとしてログインします。

d. 次を入力して Oracle Universal Installer を起動します。

prompt> mount_point/9ias_supplemental/runInstaller

「ようこそ」画面が表示されます（図 2-1）。

図図図図 2-1 Oracle Universal Installer の「ようこそ」画面の「ようこそ」画面の「ようこそ」画面の「ようこそ」画面

1. 「次へ」をクリックします。

「ファイルの場所」画面が表示されます（図 2-2）。



図図図図 2-2 Oracle Universal Installer の「ファイルの場所」画面の「ファイルの場所」画面の「ファイルの場所」画面の「ファイルの場所」画面

2. 「ソース ...」フィールドで、Supplemental CD の products.jar ファイルの場所を指定します。パスを入力するか、あるいは「参照 ...」をクリックしてナビゲートします。

3. 「インストール先 ...」フィールドで、Oracle9iAS Migration Assistant をインストールする Oracle ホームを指定します。「名前」ドロップダウン・ボックスには、コンピュータのすべての中間層 Oracle ホームのリストが含まれています。


「サマリー」画面が表示されます（図 2-3）。

注意注意注意注意 : 「ソース」および「インストール先」の場所は、同じコンピュータ上に存在する必要があります。

注意注意注意注意 : Oracle9iAS Migration Assistant は、Middle-Tier インストールの既存の Oracle9iAS リリース 2（9.0.2）の Oracle ホームにのみインストールできます。 Infrastructure インストールにはインストールできません。



図図図図 2-3 Oracle Universal Installer の「サマリー」画面の「サマリー」画面の「サマリー」画面の「サマリー」画面

この画面には、「ファイルの場所」画面の選択内容、つまり products.jarとインストール先 Oracle ホームへのパス、ならびにインストール・タイプ、言語および領域要件の要約が示されています。

5. ソースまたはインストール先のパスを変更する必要がある場合は、「戻る」をクリックして任意のパスを入力または選択します。変更しない場合は、手順 6 に進みます。


「インストール」画面が表示されます（図 2-4）。



図図図図 2-4 Oracle Universal Installer の「インストール」画面の「インストール」画面の「インストール」画面の「インストール」画面

この画面には、選択された Oracle ホームへの Oracle9iAS Migration Assistant のインストール進捗状況が表示されます。プログレス・バー上部のテキストは、インストール処理を発生と同時に示します。プロセスが完了すると、「インストールの終了」画面が表示されます（図 2-5）。



図図図図 2-5 Oracle Universal Installer の「インストールの終了」画面の「インストールの終了」画面の「インストールの終了」画面の「インストールの終了」画面

この画面には、インストール・プロセスの結果が示されます。

7. 「終了」をクリックします。


アプリケーションの移行

アプリケーションの移行アプリケーションの移行アプリケーションの移行アプリケーションの移行この項では、移行の準備に関するガイドライン、Oracle9iAS Migration Assistant の起動および操作に関する手順ごとの指示を示します。

移行の準備移行の準備移行の準備移行の準備この項では、移行の前提条件となる手順の概要を示します。

情報要件情報要件情報要件情報要件Oracle9iAS Migration Assistant を起動する前に、次のものを（移行を計画するコンポーネントに応じて）準備してください。

� デフォルトの 'welcome' パスワード以外のパスワードが割り当てられている場合は、Oracle HTTP Server の SSL 証明書のキー・ファイルのパスワード。（パスワード要件は、表 2-3 を参照。）このパスワードは、SSL 変換中の Wallet 生成に使用されます。間違ったパスワードを 3 回入力すると、SSL 関連情報を含むコンポーネントは非移行ステータスに設定（移行から除外）されます。

� 設定に関する Oracle HTTP Server ディレクティブとその目的に対する知識。

SSL 設定要件設定要件設定要件設定要件Oracle9iAS リリース 2（9.0.2）環境で Oracle HTTP Server に SSL を使用する場合、Oracle9iAS Migration Assistant の起動前に次のディレクティブが httpd.confファイルで設定されている（アンコメントされている）ことを確認してください。

� SSLCertificateFile

� SSLCertificateKeyFile

SSLCertificateFileおよび SSLCertificateKeyFileは SSL 対応 Web サイトで必須であり、移行される設定が SSL 設定の場合はこれらのディレクティブがリリース 1 のインストールの httpd.confに設定されます。

また、リリース 1 のインストールのディレクティブによってトラスト・ポイントが指定されるようにする必要があります。この方法の詳細は、2-8 ページの「SSL 設定の移行」を参照してください。

注意注意注意注意 : Oracle9iAS Migration Assistant を使用する前に Oracle9iAS を起動する必要はありません。 Oracle9iAS Migration Assistant は OC4J インスタンスを起動して OC4J アプリケーションをデプロイしてから、完了したインスタンスを停止します。



Oracle9iAS Migration Assistant（（（（GUI バージョン）の使用バージョン）の使用バージョン）の使用バージョン）の使用1. 必要に応じて、Oracle9iAS Migration Assistant のインストール先ディレクトリに変更し

ます。

2. 次のコマンドで Oracle9iAS Migration Assistant を起動します。

MigAssistant.sh

「Oracle Home」画面が表示されます（図 2-6）。

図図図図 2-6「「「「Oracle Home」画面」画面」画面」画面

3. 「Source...」フィールドで、ORACLE_HOME_1 へのフルパスを指定します。次のいずれかの操作を行います。

� フィールドにフルパスを入力します。

� 「Browse...」をクリックして、ナビゲートしてパスを指定します。

4. 「Destination...」フィールドで、ORACLE_HOME_2 へのフルパスを指定します。次のいずれかの操作を行います。

� フィールドにフルパスを入力します。

� 「Browse...」をクリックして、ナビゲートしてパスを指定します。

指定した「Source...」のパスに OC4J がない場合、「J2EE Home」画面が表示されます（図 2-7）。



図図図図 2-7「「「「J2EE Home」画面」画面」画面」画面

5. OC4J が「Source...」のパス以外の場所にインストールされた場合は、「Migrate OC4J」ラジオ・ボタンをクリックして 1.0.2.2 の J2EE ホーム・パスを指定（入力あるいはナビゲート）し、「次へ」をクリックします。

6. OC4J がインストールされていない場合あるいは移行しない場合は、「Exclude OC4J」ラジオ・ボタンをクリックしてから「次へ」をクリックします。

「Components」画面が表示されます（図 2-8）。デフォルトでは、すべてのコンポーネントが移行対象として選択されています。

図図図図 2-8「「「「Components」画面」画面」画面」画面



7. 移行からコンポーネントを選択解除するには、チェックボックスをクリックしてチェックを外します。


OC4J が選択された場合、「OC4J」画面が表示されます（図 2-9）。デフォルトでは、すべてのアプリケーションが移行対象として選択されています。構成ファイルおよびアプリケーションを移行対象として識別する方法の詳細は、2-11 ページの「OC4J の移行候補」を参照してください。

図図図図 2-9「「「「OC4J」画面」画面」画面」画面

9. 移行からファイルまたはアプリケーションを選択解除するには、チェックボックスをクリックしてチェックを外します。

10.「次へ」をクリックします。

Oracle HTTP Server が選択された場合、「Oracle HTTP Server」画面が表示されます（図 2-10）。デフォルトでは、すべての構成ファイルおよび CGI アプリケーションが移行対象として選択されています。構成ファイルおよびアプリケーションを移行対象として識別する方法の詳細は、2-2 ページの「Oracle HTTP Server の移行候補」を参照してください。



図図図図 2-10「「「「Oracle HTTP Server」画面」画面」画面」画面

11. 移行からファイルまたはアプリケーションを選択解除するには、チェックボックスをクリックしてチェックを外します。


デフォルトの 'welcome' 以外のパスワードの SSL 証明書ファイルが見つかった場合、「httpd.conf: Passwords」画面が表示されます（図 2-11）。

図図図図 2-11「「「「httpd.conf: Passwords」画面」画面」画面」画面



13.「password」フィールドに証明書キー・ファイルのパスワードを入力します。 SSL Wallet はこのパスワードで生成されます。


「httpd.conf: Directives」画面（図 2-12）が表示されます。この画面には移行に選択できるディレクティブが示されます。デフォルトでは、mod_proxy 以外のすべてのディレクティブが移行対象として選択されています。 Oracle9iAS Migration Assistant によるこのディレクティブ・リストのコンパイル方法の詳細は、2-7 ページの「Oracle HTTP Server のディレクティブの移行プロセス」を参照してください。

15. ディレクティブを選択解除するには、チェックボックスをクリックして選択を解除します。

図図図図 2-12「「「「httpd.conf: Directives」画面」画面」画面」画面


Oracle ホーム、構成ファイルおよびアプリケーションの選択内容を示す「Summary」画面（図 2-13）が表示されます。

注意注意注意注意 : Oracle9iAS Migration Assistant では、間違ったパスワードを 3 回入力すると、SSL 対応コンポーネントが非移行ステータスに設定されます。この場合は、コンポーネントを手動で移行する必要があります。



図図図図 2-13「「「「Summary」画面」画面」画面」画面

17. 選択内容を確認します。

18. 必要に応じて、「戻る」をクリックして前の画面に移動し、変更を行います。


「Warning」画面が表示されます（図 2-14）。

図図図図 2-14「「「「Warning」画面」画面」画面」画面



20.「次へ」をクリックして選択した移行内容を適用するか、あるいは「戻る」をクリックして前の画面に移動して変更を行います。

完了した移行のパーセンテージを示すプログレス・バーのある「Migration Status」画面が表示されます（図 2-15）。

図図図図 2-15「「「「Migration Status」画面」画面」画面」画面

21.「完了」をクリックして Oracle9iAS Migration Assistant を閉じます。

警告警告警告警告 : ここで「次へ」をクリックすると、ここで「次へ」をクリックすると、ここで「次へ」をクリックすると、ここで「次へ」をクリックすると、Oracle9iAS Migration Assistant は現在の移行選択内容で適用を開始します。は現在の移行選択内容で適用を開始します。は現在の移行選択内容で適用を開始します。は現在の移行選択内容で適用を開始します。移行の開始後は、移行の開始後は、移行の開始後は、移行の開始後は、「取消」をクリックして「取消」をクリックして「取消」をクリックして「取消」をクリックして Oracle9iAS Migration Assistant を停止できます。を停止できます。を停止できます。を停止できます。進行中の移行（進行中の移行（進行中の移行（進行中の移行（Oracle HTTP Server、、、、OC4J またはまたはまたはまたは Web Cache）を完了し）を完了し）を完了し）を完了してから、停止します。てから、停止します。てから、停止します。てから、停止します。選択されているそれ以外の移行は開始されません。選択されているそれ以外の移行は開始されません。選択されているそれ以外の移行は開始されません。選択されているそれ以外の移行は開始されません。

移行を元に戻すには、移行を元に戻すには、移行を元に戻すには、移行を元に戻すには、9.0.2 インスタンスの構成ファイルをバックアップかインスタンスの構成ファイルをバックアップかインスタンスの構成ファイルをバックアップかインスタンスの構成ファイルをバックアップから手動でリストアする必要があります。ら手動でリストアする必要があります。ら手動でリストアする必要があります。ら手動でリストアする必要があります。

バックアップとファイル名の説明は、次を参照してください。バックアップとファイル名の説明は、次を参照してください。バックアップとファイル名の説明は、次を参照してください。バックアップとファイル名の説明は、次を参照してください。

� 「Oracle HTTP Server の移行に対するバックアップおよび監査方法」（2-10 ページ）

� 「OC4J の移行に対するバックアップおよび監査方法」（2-13 ページ）

� 「Web Cache の移行に対するバックアップおよび監査方法」（2-16 ページ）



22. ログ・ファイルを確認します。

23. 移行した各アプリケーションに対してテストを実行します。

Oracle9iAS Migration Assistant（コマンドライン・バージョン）の使用（コマンドライン・バージョン）の使用（コマンドライン・バージョン）の使用（コマンドライン・バージョン）の使用1. 次のコマンドで Oracle9iAS Migration Assistant を起動します。

MigAssistantCmd.sh

次のプロンプトが表示されます。

Source Oracle home?

2. ORACLE_HOME_1 のパスを入力します。


Target Oracle home?

3. ORACLE_HOME_2 のパスを入力します。

次のようなプロンプトが表示されます。

Select compnents to migrate Migrate all components?[YES]n

4. [Enter] キーを押して大カッコ内のデフォルトを確定するか、n を入力してから [Enter]キーを押して拒否します。


5. 各プロンプトに対して手順 4を繰り返します。残りのプロンプトは次のようになります。

Migrate all subComponents of PlugIn Oracle9iAS Web Cache?[YES]n

Migrate webcache.xml[YES]

Migrate all subComponents of PlugIn Oracle9iAS Containers for J2EE(OC4J)?[YES]n

Migrate data-sources.xml[YES]

Migrate principals.xml[YES]

Migrate all subComponents of PlugIn Oracle HTTP Server?[YES]n

Migrate httpd.conf[YES]

Migrate Globals.java[YES]

Migrate Globals.class[YES]



Migrate Globals$__jsp_StaticText.class[YES]

Migrate globals.ser[YES]

Migrate _index.java[YES]

Migrate _index.class[YES]

Migrate _index$__jsp_StaticText.class[YES]

Questionaire PlugIn Oracle HTTP Server httpd.conf Please enter the password for ORACLE_HOME_1/conf/ssl.crt/server.crt:[welcome]

6. [Enter] キーを押してデフォルトのパスワード welcomeを確定するか、パスワードを入力して [Enter] キーを押します。

次のような選択内容のサマリーが表示されます。

Summary page PlugIn Oracle9iAS Web Cache webcache.xml PlugIn Oracle9iAS Containers for J2EE(OC4J) data-sources.xml principals.xml news.ear petstore.ear atm.ear PlugIn Oracle HTTP Server Globals.java Globals.class Globals$__jsp_StaticText.class globals.ser _index.java _index.class _index$__jsp_StaticText.classStart migration...

7. [Enter] キーを押して移行を開始します。

移行プロセスが開始されます。次のようなステータス・メッセージが表示されます。

Migrating plugin Oracle9iAS Web CacheOutcome Status code 0Status description SUCCESSMigrating plugin Oracle9iAS Containers for J2EE(OC4J)Outcome Status code 0Status description SUCCESSMigrating plugin Oracle9iAS HTTP ServerOutcome Status code 0Status description SUCCESS



8. ログ・ファイルを確認します。

9. 移行した各アプリケーションに対してテストを実行します。

Web Cache の移行の完了の移行の完了の移行の完了の移行の完了Web Cache の移行を完了するために、次の作業を実行する必要が生じる場合があります。次のように、管理者ユーザー・インタフェースを使用して設定を確認し、必要に応じて変更します。

� サイトからサーバーへのマッピングを作成します。

� リリース 1 と同じ Operations Port Wallet または Listening Port Wallet を使用するには、リリース 1 の Wallet 情報を取得し、管理ユーザー・インタフェースを使用してリリース 2 の Wallet 情報を変更します。

� インストール後のユーザー変更を確認します。

Oracle9iAS リリース 2（9.0.2）のインストール後は、いつでも Oracle9iAS Migration Assistant を起動できます。 webcache.xmlファイルが変更された場合は、変更内容が保存されます。冗長なキャッシュ可能性ルールが存在する場合があります。これを解決するには、ファイルを確認する必要があります。ルール自体およびルールの表示順序によって、Web Cache が実行するキャッシング動作が決定されます。

� 移行によって生じたポート競合を解決します。

ポート番号は、webcache.xmlファイルから移行されません。リリース 1 とリリース 2の webcache.xmlファイルを比較して、Oracle9iAS Migration Assistant が実行した移行後にポート競合が存在していないことを確認してください。

Web Cache では、管理、リスニング、統計および失効化のポート番号は移行されません。リリース 1 のポート番号をリリース 2 で使用するには、次の手順を実行します。

1. リリース 1 で使用されていた Web Cache のポート番号を決定します。

2. 管理ユーザー・インタフェースを使用して、リリース 2 のポート番号を変更します。

� セッション・キャッシュ処理ルールを確認して、重複があれば解決します。

� 期限切れルールを確認して、重複があれば解決します。

� マルチバージョン Cookie ルールを確認して、重複があれば解決します。

注意注意注意注意 : ポート競合のために Web Cache の管理プロセスが開始されない場合は、webcache.xmlファイルの MULTIPORT 要素に正しい管理ポートを指定し、Web Cache を再起動する必要があります。


Oracle9iAS Migration Assistant の再起動

Oracle9iAS Migration Assistant の再起動の再起動の再起動の再起動Oracle9iAS Migration Assistant を再起動する前に、Oracle9iAS リリース 2（9.0.2）インスタンスを移行前の状態にリストアする必要があります。次の手順を実行します。

1. リリース 2 の Oracle ホーム・ディレクトリからフラグ・ファイル firstRunを削除します。

2. すべての構成ファイルおよびディレクトリを移行前の状態にリストアします。（ログ・ファイルを使用して変更またはコピーされたファイルを特定してください。）

3. 次の項目の指示に従ってください。

「Oracle9iAS Migration Assistant（GUI バージョン）の使用」（2-27 ページ）

または

「Oracle9iAS Migration Assistant（コマンドライン・バージョン）の使用」（2-34 ページ）


Oracle9iAS Migration Assistant の再起動


インターネット・アプリケーションのコンポーネントの

3
インターネット・アプリケーションのインターネット・アプリケーションのインターネット・アプリケーションのインターネット・アプリケーションの
コンポーネントの移行コンポーネントの移行コンポーネントの移行コンポーネントの移行

この章では、インターネット・アプリケーションのコンポーネントを移行する際に必要な構成ファイル、アプリケーション配布ファイルおよびメタデータ・スキーマの変更方法について説明します。この章の主な項は次のとおりです。

� Oracle9iAS Containers for J2EE（OC4J）の移行

� Oracle9iAS SOAP の移行

� Oracle Business Components for Java の移行

移行 3-1

Oracle9iAS Containers for J2EE（OC4J）の移行

Oracle9iAS Containers for J2EE（（（（OC4J）の移行）の移行）の移行）の移行この項では、Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iAS リリース 2（9.0.2）への次の移行方法について説明します。

� JSP から OC4J への移行

� JServ から OC4J への移行

JSP からからからから OC4J への移行への移行への移行への移行この項では、Oracle9i Application Server のユーザーが、Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iAS リリース 2（9.0.2）に JSP アプリケーションを移行する場合に留意すべき点を説明します。また、Servlet 2.0 に準拠した環境である Apache JServ から、新しいリリースに含まれている、Servlet 2.3 に準拠した環境である Oracle9iAS Containers for J2EE（OC4J）にスムーズに移行する方法についても説明します。さらに、JSP コンテナの相違点についても説明します。

この項の項目は次のとおりです。

� Servlet 2.3 環境と Servlet 2.0 環境における JSP ページの比較

� JSP コンテナの移行についての留意点

� アプリケーション環境と留意点

� JSP グローバル・インクルード

� JSP 構成

� ojspc ユーティリティを使用する場合の問題点

� パッケージングおよびデプロイメント

� その他の留意点

注意注意注意注意 : アプリケーション環境、サーブレット・コンテキスト、サーブレット・パスのマッピング、アプリケーションのルート構成、OC4J の構成、およびデプロイについては、サーブレットの移行に関する項を参照してください。



Servlet 2.3 環境と環境と環境と環境と Servlet 2.0 環境における環境における環境における環境における JSP ページの比較ページの比較ページの比較ページの比較Oracle9iAS リリース 2（9.0.2）が登場する前は、JServ が主要なサーブレット環境でした。 Servlet2.3 を実装する OC4J と Servlet2.0 を実装する JServ では、サーブレット環境が大きく異なります。次に、両環境の相違点をまとめます。

� 標準のアプリケーション環境と標準のアプリケーション環境と標準のアプリケーション環境と標準のアプリケーション環境と globals.jsa の違いの違いの違いの違い — Servlet2.2 と 2.3 では、Web アプリケーションの概念が十分に定義されていますが、Servlet2.0 にはそのような定義がありません。現在は、サーブレット標準と OC4J の実装によって、Web アプリケーションのドキュメント・ルートの概念とアプリケーションのパッケージ方法が定義されます。詳細は、3-6 ページの「アプリケーション環境と留意点」を参照してください。 JServ では、Oracle で JSP を実装するときに、globals.jsaを介してアプリケーション・フレームワークをエミュレートしていました。 Oracle9iAS リリース 2（9.0.2）では、globals.jsaを使用する必要がなくなったため、OC4J でも globals.jsaをサポートしていません。

� リクエスト・ディスパッチャリクエスト・ディスパッチャリクエスト・ディスパッチャリクエスト・ディスパッチャ — Servlet2.1 仕様では、リクエスト・ディスパッチャの概念が導入されました。リクエスト・ディスパッチャにより、JSP ページやサーブレットが、他のページまたはサーブレットのコンテンツを含めたり、他のページまたはサーブレットに実行命令を送れるようになります。 JServ では、Oracle で JSP を実装するときに、リクエスト・ディスパッチャの機能をエミュレートしていました。 OC4J では、このようなエミュレーションは必要はありません。

� 属性の格納属性の格納属性の格納属性の格納 — Servlet2.1 以降の仕様では、リクエスト・レベルまたはアプリケーション・レベルの属性を格納できるようになりました。開発者は、HTTP リクエスト・オブジェクトとサーブレット・コンテキスト・オブジェクト（アプリケーション・レベル）を使用して、状態情報を格納および取得できます。 JServ では、Oracle で JSP を実装するときに、この機能をエミュレートしていました。 Oracle9iAS リリース 2（9.0.2）のOC4J では、このようなエミュレーションは必要はありません。

� サーブレットのフィルタ処理サーブレットのフィルタ処理サーブレットのフィルタ処理サーブレットのフィルタ処理 — Servlet2.3 仕様では、サーブレットのフィルタ処理の概念が導入されました。開発者は、サーブレットのフィルタ処理により、HTTP リクエストとレスポンスを検証および変更できます。たとえば、共通ヘッダーやフッター、またはカスタマイズされた認証や許可にこの処理を使用できます。この機能は、以前のバージョンの Oracle9iAS や Oracle JSP の各リリースでは使用できませんが、Oracle9iAS リリース 2（9.0.2）の OC4J では使用できます。

� グローバリゼーショングローバリゼーショングローバリゼーショングローバリゼーション — Servlet 2.3 仕様では、HTTP リクエスト・オブジェクトの標準の setCharacterEncoding()メソッドを介して、HTTP パラメータに対するグローバリゼーション・サポートを提供します。以前の Oracle JSP の実装では、translate_params構成パラメータによりグローバリゼーションがサポートされ、その後、パブリック・ユーティリティ・クラスの setReqCharacterEncoding()メソッドを介してサポートしていました。新しい仕様では、アプリケーションをsetCharacterEncoding()に移行する必要があります。 3-18 ページの「HTTP パラメータのグローバリゼーションについての留意点」を参照してください。

インターネット・アプリケーションのコンポーネントの移行 3-3


JSP コンテナの移行についての留意点コンテナの移行についての留意点コンテナの移行についての留意点コンテナの移行についての留意点OC4J を初めて装備した Oracle9iAS リリース 1（1.0.2.2.x）には、次の 2 種類の JSP コンテナが用意されていました。

� Oracle が開発した Oracle JSP と呼ばれるコンテナ

� Ironflare AB からライセンスを取得した、Orion JSP コンテナと呼ばれていたコンテナ

Oracle JSP コンテナには、グローバリゼーション・サポートおよび SQLJ サポートなどの有用な付加機能や拡張機能を含め、多くの利点があります。 Orion コンテナにも高速性などの利点がありますが、デメリットもあります。 JSP 1.1 のリファレンス実装（Tomcat）と比較すると、Orion コンテナは常に一定水準の動作をするとは限らず、国際化およびグローバリゼーションのサポートも不十分です。

Oracle9iAS リリース 2（9.0.2）によって、この 2 種類のコンテナが、OC4J JSP コンテナという、1 つの JSP コンテナに統合されました。 OC4J JSP コンテナは、以前の 2 種類のコンテナの優れた機能を受け継いで、OC4J サーブレット・コンテナのサーブレットととして効率良く機能し、他の OC4J コンテナとも統合されます。統合されたコンテナは、主に Oracle JSPトランスレータと Orion JSP コンテナのランタイム・システムで構成され、新しく簡素化されたディスパッチャと OC4J 1.0.2.2 のコア・ランタイム・クラスを使用して実行されます。

Oracle9iAS リリース 1（1.0.2.2.x）では、Orion コンテナがデフォルトの JSP コンテナでした。このコンテナを使用していた場合は、Oracle9iAS リリース 2（9.0.2）の OC4J JSP コンテナに移行する際、多くの注意が必要です。元の Orion JSP コンテナを継続して使用できるように OC4J を構成できますが、お薦めしません。 Orion JSP コンテナを継続して使用する場合は、一時的な使用に限ってください。

次に、移行についての留意点をまとめます。

taglib-location の設定の設定の設定の設定次は、web.xmlの taglibの定義例です。

<taglib> <taglib-uri>/hello</taglib-uri> <taglib-location>WEB-INF/lib/taglib.tld</taglib-location></taglib>

taglib-locationの設定の先頭に "/" が付いていないことに注意してください。リリース9.0.2 の OC4J JSP コンテナでは、これが次のようになります。

/WEB-INF/WEB-INF/lib/taglib.tld

これは JSP 仕様に準拠しています。 Orion JSP コンテナでは次のようになります（おそらくこちらが開発者の意図だったと思われます）。

/WEB-INF/lib/taglib.tld

先頭に "/" を追加して、次のように taglib-locationの設定を変更してください。

<taglib-location>/WEB-INF/lib/taglib.tld</taglib-location>


HTML コメントコメントコメントコメント Orion JSP コンテナでは、で示される HTML コメントの内容が無視される場合がありました（JSP コメントの <%-- ... --%>は無視されません）。その結果、HTML コメントの中身が出力されませんでした。

OC4J JSP コンテナでは、HTML コメントは解釈されませんが、無視されることもありません。 OC4J JSP コンテナからは、ブラウザを介して HTML コメントが渡されます。この動作は JSP 仕様に準拠しています。このことから、たとえば、開発者が HTML コメントにJavaScript を追加する際などは、OC4J JSP コンテナの方が適しています。

閉じられていないタグがあるページを含むための閉じられていないタグがあるページを含むための閉じられていないタグがあるページを含むための閉じられていないタグがあるページを含むための Include ディレクティブの使用ディレクティブの使用ディレクティブの使用ディレクティブの使用 JSP 仕様では、適切なタグで閉じられていないページ・ヘッダーを includeディレクティブで受け入れるかどうかについて指定されていません。 Orion JSP コンテナではこのようなページが受け入れられますが、OC4J JSP エンジンおよび Tomcat のリファレンス実装では受け入れられません。次に例を示します。

--------------------------a.jsp<jsp:useBean id="b" class="pkgA.BeanB" ><% // init the bean %>--------------------------

--------------------------b.jsp<%@ include file="a.jsp" %></jsp:useBean><%= new java.util.Date() %>--------------------------

上記は Orion JSP コンテナで受け入れられます。これを OC4J JSP コンテナに移行する場合は、次のように変更します。

--------------------------a.jsp<jsp:useBean id="b" class="pkgA.BeanB" ><% // init the bean %></jsp:useBean>--------------------------

--------------------------b.jsp<%@ include file="a.jsp" %><%= new java.util.Date() %>--------------------------


Include ディレクティブ構文ディレクティブ構文ディレクティブ構文ディレクティブ構文 Orion JSP コンテナでは、次の不適切な構文が受け入れられていました。

<%@ include file="value" />

この構文は仕様に準拠していないため、OC4J JSP コンテナでは受け入れられません。正しいInclude ディレクティブ構文は次のとおりです。

<%@ include file="value" %>

タグ属性の設定で使用される引用符タグ属性の設定で使用される引用符タグ属性の設定で使用される引用符タグ属性の設定で使用される引用符 JSP 1.2 仕様では、タグ属性の設定を引用符で囲む必要があります。また、設定内の引用符にはエスケープ文字を使用する必要があります。この点が以前の JSP 仕様で明確に定義されていなかったので、引用符で正しく囲まれていない属性も Orion JSP コンテナで受け入れられていました。

次は不適切な構文ですが、Orion JSP コンテナでは受け入れられていました。

<jsp:tag prop=<%=bean.getProperty("name")%> />

次は正しい構文です。追加されている引用符とエスケープ文字に注意してください。このように記述しなければ、OC4J JSP コンテナでは受け入れられません。

<jsp:tag prop="<%=bean.getProperty(\"name\")%>"/>

アプリケーション環境と留意点アプリケーション環境と留意点アプリケーション環境と留意点アプリケーション環境と留意点Servlet2.0 仕様では、Web アプリケーションの概念が明確に定義されていなかったので、サーブレット・コンテキストとアプリケーションの間に関連性が定義されていませんでした。 JServ などの Servlet 2.0 環境では、1 つの JVM に対してサーブレット・コンテキスト・オブジェクトが 1 つしかありません。 Servlet 2.0 環境には、セッション・オブジェクトも 1つしかありません。

ただし、Oracle JSP を実装する環境では、globals.jsaファイル（標準外の Oracle の拡張機能）を使用することによって、特に Servlet2.0 の環境に対して、1 つの Web サーバー上で複数のアプリケーションやセッションをサポートをしてきました。 Oracle JSP 以外では、個々のサーブレット・コンテキストが各アプリケーションに対して有効ではないので、globals.jsaを使用して、Oracle JSP コンテナからアプリケーションに対して個別にServletContextオブジェクトを提供していました。

Oracle9iAS リリース 2（9.0.2）の OC4J では、Servlet2.3 の環境において標準的なアプリケーションがサポートされるので、globals.jsaファイルはサポートされません。（3-7ページの「globals.jsa からの移行」を参照。）



以降では、次に挙げる globals.jsaについての留意点とアプリケーション環境に関するその他の問題点を説明します。

� globals.jsaからの移行

� クラスパスについての留意点

� Oracle JSP スコープ・リスナーの変更

globals.jsa からの移行からの移行からの移行からの移行

リリース 9.0.2 の OC4J JSP コンテナでは、globals.jsaがサポートされません。 globals.jsaを使用する既存のアプリケーションがある場合は、globals.jsaから移行する必要があります。 globals.jsaの代替として、次の方法をお薦めします。

� globals.jsaをアプリケーション・マーカーとして使用するかわりに、標準の WARパッケージングを使用してアプリケーション構造を示します。

� globals.jsaのスタート・セッション・イベント、エンド・セッション・イベント、スタート・アプリケーション・イベント、およびエンド・アプリケーション・イベントを使用するかわりに、標準 Servlet2.3 のリスナー機能を使用します。たとえば、標準のjavax.servlet.ServletContextListenerインタフェースおよびjavax.servlet.http.HttpSessionListenerインタフェースを介して同様の機能が提供されます。

� globals.jsaを使用してグローバル変数宣言を行うかわりに、1 つのソース・ファイルで宣言を作成し、リリース 9.0.2 で導入された OC4J JSP エンジンのグローバル・インクルード機能を使用します。3-10 ページの「JSP グローバル・インクルード」を参照してください。

すぐに移行できない場合でも、globals.jsaを使用するアプリケーションを OC4J 環境で実行できます。ただし、新しい oracle.jsp.runtimev2.JspServletフロントエンド・サーブレットではなく、以前の oracle.jsp.JspServletフロントエンド・サーブレットを使用している場合に限ります。使用するサーブレットは、アプリケーションの web.xmlファイルの <servlet>要素で指定できます。web.xmlファイルの設定は、OC4J のglobal-web-application.xmlファイルの設定より優先されます。この設定を使用するのは短期間にしてください。新しいフロントエンド・サーブレットは、多くの新しい機能や構成パラメータをサポートし、パフォーマンスが向上しているからです。（3-13 ページの

「JSP 構成」を参照。）

クラスパス機能クラスパス機能クラスパス機能クラスパス機能

Oracle9iAS リリース 2（9.0.2）の OC4J JSP コンテナでは、変換された JSP ページや、そのページに必要なあらゆる .classファイルおよび .jarファイルを検索するときに、Webサーバー上の標準の場所が検索対象になります。 OC4J JSP コンテナには、Web サーバーのクラスパスが構成されていなくても、検索対象の場所にあるファイルを見つけ、自動的にその場所にクラスを再ロードする機能が備わっています（構成の設定により異なる）。



次のように、依存クラスの場所はアプリケーション・ルートに対する相対パスで示されます。

/WEB-INF/classes/.../WEB-INF/lib

JSP ページの実装クラス（変換されたページ）の場所は次のとおりです。

.../_pages/...

/WEB-INF/classesディレクトリは、Java の各 .classファイルが置かれる場所です。クラス・ファイルは、Java パッケージのネーミング規則に従って、classesディレクトリの下のサブディレクトリに保存されます。たとえば、oracle.jsp.sample.lotteryパッケージ内にあると定義される LottoBeanという名前の JavaBean があるとします。 JSP コンテナは、アプリケーション・ルートに対して相対的な次の場所を検索して、LottoBean.classを見つけます。

/WEB-INF/classes/oracle/jsp/sample/lottery/LottoBean.class

libディレクトリは、.jarファイルが置かれる場所です。 Java パッケージ構造は、.jarファイルの構造で指定されるので、.jarファイルはすべて、サブディレクトリではなくlibディレクトリの直下に置かれます。たとえば LottoBean.classは、次のように、アプリケーション・ルートに対して相対的な次の場所にある lottery.jarに格納されます。

/WEB-INF/lib/lottery.jar

OC4J では、_pagesディレクトリは、次のディレクトリの下にあります。

/j2ee/home/application-deployments/app-name/web-app-name/temp

app-nameは、OC4J の server.xmlにある applicationタグで指定されます。一方、WAR ファイル名に対応する web-app-nameは、OC4J の default-web-site.xmlファイルにある web-appタグで、app-name にマッピングされます。詳細は、『Oracle9iAS Containers for J2EE ユーザーズ・ガイド』および『Oracle9iAS Containers for J2EE Servlet 開発者ガイド』を参照してください。

変換された JSP ページに対して生成されたページ・実装クラスは、元の .jspファイルの場所に応じて、_pagesディレクトリの下のサブディレクトリに置かれます。

重要重要重要重要 : _pagesディレクトリの場所などの実装に関する詳細は、今後のリリースで変更になる場合があります。


JspScopeListener 機能の移行機能の移行機能の移行機能の移行

Oracle の JspScopeListenerインタフェースは OC4J に移植されているので、ページ・スコープ、リクエスト・スコープ、セッション・スコープ、およびアプリケーション・スコープの各イベントを管理できます。ただし、Servlet2.3 仕様に準拠するために加えられた変更があるので、以前のリリースとは異なる方法で機能します。

OC4J JSP コンテナを使用する場合、ページ・スコープ・オブジェクトに対する特別な手順や構成は必要ありません。 Oracle 固有のランタイム実装によって、pageスコープがサポートされます。ただし、他の JSP 環境に移行する場合は、pageスコープをサポートするためにカスタム・タグである checkPageScopeを使用してください。

セッション・スコープ・イベントに対して JspScopeListenerを使用する場合は、JspScopeListenerインタフェースだけでなく、標準のHttpSessionBindingListenerインタフェースも実装する必要があります。これは、Servlet2.3 仕様では、JSP コンテナのかわりにサーブレット・コンテナを使用してセッション・ベース・イベントを通知するからです。 HttpSessionBindingListenerのvalueUnbound()メソッドを、JspScopeListenerインタフェースの outOfScope()メソッドと共有する共通メソッドに委譲してください。

JspScopeListenerでは、サーブレット・フィルタを介してリクエスト・スコープのオブジェクトがサポートされます。フィルタは、特定の URL パターンに一致するすべてのサーブレットに適用されます。リクエスト・スコープ・オブジェクトのイベントを処理するには、使用するアプリケーションの web.xmlファイルに次を入力してください。 JspScopeListenerを確実に正しく機能させるため、他の filterを設定した後に次の設定を入力してください。

<filter> <filter-name>Request Filter</filter-name> <filter-class>oracle.jsp.event.impl.RequestScopeFilter</filter-class> </filter>  <filter-mapping> <filter-name>Request Filter</filter-name> <url-pattern>/jsp/*</url-pattern> </filter-mapping>

JspScopeListenerでは、Servlet2.3 仕様に基づき、サーブレット・コンテキスト・リスナー・実装クラスによりアプリケーション・スコープのオブジェクトがサポートされます。アプリケーション・スコープ・オブジェクトのイベントを処理するには、使用するアプリケーションの web.xmlファイルに次を入力して追加してください。 JspScopeListenerを確実に正しく機能させるため、他の listenerを設定した後に次の設定を入力してください。

<listener> <listener-class>oracle.jsp.event.impl.AppScopeListener</listener-class> </listener>


追加情報および事例は、『Oracle9iAS Containers for J2EE JSP タグ・ライブラリおよびユーティリティ・リファレンス』を参照してください。

JSP グローバル・インクルードグローバル・インクルードグローバル・インクルードグローバル・インクルードOracle9iAS リリース 2（9.0.2）では、OC4J JSP コンテナにグローバル・インクルード機能が備わっています。この機能を使用すると、仮想 JSP includeディレクティブによって、任意の 1 以上のファイルを、指定したディレクトリの直下またはそのサブディレクトリにあるJSP ページに静的に含めることができます。変換時に JSP コンテナでは、構成ファイルである /WEB-INF/ojsp-global-include.xmlが検索されます。このファイルには、含まれるファイルとページのディレクトリが指定されています。

この拡張機能は、以前の Oracle JSP リリースの globals.jsaファイルや translate_params機能を使用していたアプリケーションを移行する場合に特に便利です。

グローバルにインクルードされたファイルは、たとえば次のような目的で使用できます。

� Bean のグローバルな宣言（以前は globals.jsaでサポート）

� 共通ページのヘッダーまたはフッター

� translate_params等価コード

ojsp-global-include.xml ファイルファイルファイルファイル

ojsp-global-include.xmlファイルでは、インクルードするファイル名、インクルードする位置（JSP ページの先頭または末尾のどちらか）、グローバル・インクルードが適用される JSP ページの場所を指定します。この項では、ojsp-global-include.xmlファイルの要素について説明します。

<ojsp-global-include>

これは、ojsp-global-include.xmlファイルのルート要素です。属性はありません。

サブ要素 :

<include>

<include ... >

<ojsp-global-include>のサブ要素である上記の要素使用して、インクルードするファイルと、インクルードする位置（JSP ページの先頭または末尾のどちらか）を指定します。

サブ要素 :

<into>



属性 :

� file: インクルードするファイルを "/header.html"または"/WEB-INF/globalbeandeclarations.jsph"のように指定します。ファイル名の先頭に、必ずスラッシュ（/）を付けてください。ファイル名は、ページを起点とした相対指定ではなく、コンテキストを起点とした相対指定にする必要があります。

� position: ファイルが JSP ページの先頭または末尾のどちらにインクルードされるかを指定します。指定できる値は、"top"（デフォルト）または "bottom"です。

<into ... >

<include>のサブ要素である上記の要素を使用して、指定したファイルをインクルードする JSP ページの場所（ディレクトリまたはサブディレクトリ）を指定します。この要素にサブ要素はありません。

属性 :

� directory: ディレクトリを指定します。このディレクトリまたはサブディレクトリにあるどの JSP ページにも、<include>要素の file属性で指定したファイルが静的にインクルードされます。 directoryを指定するときは、たとえば "/dir1"のように、必ず先頭にスラッシュ（/）を付けてください。 "/dir1/"のように、ディレクトリ名の後にスラッシュを付けることもできます。スラッシュを付けない場合は、変換時に内部に追加されます。

� subdir: directoryで指定したディレクトリのすべてのサブディレクトリにある JSPページに、ファイルも静的にインクルードさせるかどうかを指定します。指定できる値は、"true"（デフォルト）または "false"です。

グローバル・インクルードの例グローバル・インクルードの例グローバル・インクルードの例グローバル・インクルードの例

この項では、グローバル・インクルードの例を紹介します。

例例例例 : ヘッダーヘッダーヘッダーヘッダー / フッターフッターフッターフッター

次の ojsp-global-include.xmlファイルを想定します。

<?xml version="1.0" standalone='yes'?><!DOCTYPE ojsp-global-include SYSTEM 'ojsp-global-include.dtd'>

<ojsp-global-include> <include file="/header.html"> <into directory="/dir1" /> </include> <include file="/footer1.html" position="bottom"> <into directory="/dir1" subdir="false" /> <into directory="/dir1/part1/" subdir="false" /> </include> <include file="/footer2.html" position="bottom">



<into directory="/dir1/part2/" subdir="false" /> </include></ojsp-global-include>

この例では、次の 3 点が指定されています。

� header.htmlファイルが、dir1ディレクトリ内またはそのサブディレクトリ内にあるすべての JSP ページの先頭にインクルードされます。このディレクトリまたはそのサブディレクトリ内にある各 .jspファイルのページの先頭に、次の includeディレクティブがある場合と同じ結果が得られます。

<%@ include file="/header.html" %>

� footer1.htmlファイルが、dir1ディレクトリ内またはその part1サブディレクトリ内にあるすべての JSP ページの末尾にインクルードされます。このディレクトリ内にある各 .jspファイルのページの末尾に、次の includeディレクティブがある場合と同じ結果が得られます。

<%@ include file="/footer1.html" %>

� footer2.htmlファイルが、dir1ディレクトリの part2サブディレクトリにあるすべての JSP ページの末尾にインクルードされます。このディレクトリ内にある各 .jspファイルのページの末尾に、次の includeディレクティブがある場合と同じ結果が得られます。

<%@ include file="/footer2.html" %>

例例例例 : translate_params 等価コード等価コード等価コード等価コード

次の ojsp-global-include.xmlファイルを想定します。

<?xml version="1.0" standalone='yes'?><!DOCTYPE ojsp-global-include SYSTEM 'ojsp-global-include.dtd'>

<ojsp-global-include> <include file="/WEB-INF/nls/params.jsf"> <into directory="/" /> </include> </ojsp-global-include>

注意注意注意注意 : 1 つの JSP ページに複数のヘッダーやフッターがインクルードされる場合、インクルード順序は、ojsp-global-include.xmlファイルの<include>要素の順序に従います。



さらに、params.jsfに次が含まれているとします。

<% request.setCharacterEncoding(response.getCharacterEncoding(); %>

params.jsfファイルが、アプリケーションのルート・ディレクトリ内またはそのサブディレクトリ内にあるすべての JSP ページの先頭にインクルードされます。つまり、アプリケーションのすべての JSP ページにインクルードされることになります。このディレクトリまたはそのサブディレクトリ内にある各 .jspファイルのページの先頭に、次の includeディレクティブがある場合と同じ結果が得られます。

<%@ include file="/WEB-INF/nls/parms.jsf" %>

3-16 ページの「translate_params の移行でのグローバル・インクルード」を参照してください。

JSP 構成構成構成構成Oracle9iAS リリース 2（9.0.2）の OC4J では、Oracle9iAS の JServ コンポーネントで使用されていた oracle.jsp.JspServletのかわりに、oracle.jsp.runtimev2.JspServletフロントエンド・サーブレットが使用されます。

このクラスを JSP サーブレットとしてマッピングする処理は、OC4J のglobal-web-application.xmlファイルに次のような記述をすることにより自動的に行われます。

<servlet> <servlet-name>jsp</servlet-name> <servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class> ... init params ...</servlet>

このファイルには <servlet-mapping>要素も含まれ、この要素によって、このフロントエンド・サーブレットにマッピングされるファイル拡張子（.jsp、.JSP、.sqljsp、.SQLJSP）が指定されます。

上記の "init params" などの構成パラメータも、global-web-application.xmlファイルで設定できます。次に例を示します。

<init-param> <param-name>precompile_check</param-name> <param-value>true</param-value> </init-param>



以前の以前の以前の以前の Oracle JSP 構成パラメータのサポート構成パラメータのサポート構成パラメータのサポート構成パラメータのサポート

表 3-1 は、JServ 環境用の以前のフロントエンド・サーブレットがサポートしていた構成パラメータの一覧です。Oracle9iAS リリース 2（9.0.2）の OC4J 環境にも関連し、サポートされている構成パラメータに注目してください。

表表表表 3-1 サポートされる構成パラメータサポートされる構成パラメータサポートされる構成パラメータサポートされる構成パラメータ : JServ からからからから OC4J への移行への移行への移行への移行

JServ でサポートされでサポートされでサポートされでサポートされる構成パラメータる構成パラメータる構成パラメータる構成パラメータ

OC4J でサポートさでサポートさでサポートさでサポートされる構成パラメータれる構成パラメータれる構成パラメータれる構成パラメータ備考備考備考備考

alias_translation OC4J では不要

bypass_source OC4J の新しいパラメータに移行（main_mode）

classpath OC4J では不要

debug_mode debug_mode 変更なし

developer_mode OC4J の新しいパラメータに移行（main_mode）

emit_debuginfo emit_debuginfo 変更なし

external_resource external_resource

変更なし

javaccmd javaccmd 変更なし

send_error OC4J では不要

session_sharing OC4J では不要

sqljcmd sqljcmd 変更なし

translate_params OC4J では不要。標準のサーブレット・リクエス

トである setCharacterEncoding()メソッド

を使用します。

注意注意注意注意 : 3-16 ページの「translate_params の移行

でのグローバル・インクルード」を参照してください。

unsafe_reload OC4J では不要



新しい新しい新しい新しい Oracle JSP 構成パラメータ構成パラメータ構成パラメータ構成パラメータ

Oracle9iAS リリース 2（9.0.2）に、次の JSP 構成パラメータが追加されました。

� main_mode — 変更時に、クラスを自動的に再ロードするのか、JSP ページを自動的に再コンパイルするのかを決定します。設定できる値は、justrun、reload、recompileのいずれかです。

� old_include_from_top —ネストされるincludeディレクティブ内のページ位置を、トップレベル・ページを起点とする相対位置にするため、このブール値を trueに設定します。Oracle9iAS リリース 2（9.0.2）より前の Oracle JSP の動作への下位互換性を保つための設定です。

� precompile_check— HTTPリクエストが標準のjsp_precompile設定に適合しているかを確認するため、このブール値を trueに設定します。

� reduce_tag_code — カスタム・タグを使用するために生成されるコードのサイズを縮小するには、ブール値を trueに設定します。

� req_time_introspection — コンパイル時のイントロスペクションが不可能な場合にリクエスト時の JavaBean イントロスペクションを有効にするため、このブール値をtrueに設定します。コンパイル時のイントロスペクションが可能であり、無事に実行されようであれば、このパラメータは無視され、リクエスト時のイントロスペクションは実行されません。

� static_text_in_chars — JSP トランスレータにより JSP ページ内の静的テキストをバイトではなく文字で作成するには、このブール値を trueに設定します。 3-19 ページの「文字形式での静的テキスト」を参照してください。

� tags_reuse_default — JSP タグ・ハンドラ・プーリングのデフォルト設定を指定します。デフォルトで、有効にするには true、無効にするには false に設定します。このデフォルト設定は、どの JSP ページでも優先されます。 3-19 ページの「タグ・ハンドラの再利用」を参照してください。

� xml_validate — web.xmlファイルと TLD ファイルで、XML 妥当性チェックを実行するかどうかを、このブール値で設定します。

詳細は、『Oracle9iAS Containers for J2EE JavaServer Pages サポート・リファレンス』を参照してください。



translate_params の移行でのグローバル・インクルードの移行でのグローバル・インクルードの移行でのグローバル・インクルードの移行でのグローバル・インクルード

Oracle9iAS リリース 2（9.0.2）の OC4J JSP コンテナに備わっている新しいグローバル・インクルード機能（3-10 ページの「JSP グローバル・インクルード」を参照）は、translate_paramsを使用してグローバリゼーションを行っていたアプリケーションを移行する場合に便利です。

このときグローバルにインクルードされたファイルには、translate_paramsと同じ機能を提供するため、次のいずれかに似たスクリプトレットが含まれます。

� リクエスト・キャラクタ・セットのハードコード

<% request.setCharacterEncoding("desired_charset"); %>

または、

� レスポンスのキャラクタ・セットをリクエストのキャラクタ・セットとして使用。このときレスポンスのキャラクタ・セットは、JSP の pageディレクティブのcontentType属性で指定されます。

<% request.setCharacterEncoding(response.getCharacterEncoding()); %>

または、

� レスポンスのキャラクタ・セットをリクエストのキャラクタ・セットとして使用。このときレスポンスのキャラクタ・セットは、Java 論理により動的に決定されます。

<% String yourCharSet = yourLogicToDetermineCharset(); response.setContentType("text/html; charset="+yourCharSet); request.setCharacterEncoding(response.getCharcterEncoding()); // NOTE: The relative ordering of response.setContentType() // and request.setCharacterEncoding() is important.%>

ojspc ユーティリティを使用する場合の問題点ユーティリティを使用する場合の問題点ユーティリティを使用する場合の問題点ユーティリティを使用する場合の問題点Oracle9iAS リリース 2（9.0.2）で変換前処理を行うための ojspcユーティリティを使用して移行する場合に、重大ではありませんが、注意すべき点がいくつかあります。

OC4J 環境における環境における環境における環境における ojspc の実行の実行の実行の実行

OC4J 環境では、変換前処理用にクラスパスを設定する ojspcフロントエンド・スクリプトが変更されています。 OC4J で ojspcを実行するユーザーが、新しい ojspcのデフォルト設定を使用して問題が発生することはあまりありませんが、次の 2 点には注意してください。

� 使用しているアプリケーションが JSP 1.2 以前の includeディレクティブの動作に依存している場合は、-oldIncludeFromTop=trueと設定すると、以前の動作との互換性を確保できます。この ojspcオプションにより、新しい old_include_from_top JSP構成パラメータを使用する場合と同じ結果が得られます。



� 以前のリリース（つまり JServ 環境）では文字で生成されていた静的テキストが、OC4Jのデフォルト設定ではバイトコードで生成されます。以前の環境と同じ動作を得たい場合は、-staticTextInChars=trueと設定してください。この ojspcオプションにより、新しい static_text_in_chars JSP 構成パラメータを使用する場合と同じ結果が得られます。

old_include_from_topパラメータと static_text_in_charsパラメータの詳細は、3-15 ページの「新しい Oracle JSP 構成パラメータ」を参照してください。

JServ 環境における環境における環境における環境における ojspc_jserv の実行の実行の実行の実行

Oracle9iAS リリース 2（9.0.2）の JServ 環境で ojspcを使用して変換前処理を行う場合は、ojspc（または ojspc.bat）スクリプトではなく、新しい ojspc_jservスクリプト

（Windows NT では ojspc_jserv.bat）を使用してください。

パッケージングおよびデプロイメントパッケージングおよびデプロイメントパッケージングおよびデプロイメントパッケージングおよびデプロイメントOracle9iAS の以前のリリースでは、標準の Servlet2.2 仕様 WAR（Web archive）ファイルを介してデプロイが行われていました。 Oracle9iAS リリース 2（9.0.2）では、標準の J2EE 1.2 EAR（Enterprise archive）ファイルを介してデプロイが行われます。EAR ファイル内部には WAR ファイルが含まれています。

OC4J 環境では、標準の EAR ファイルを介してアプリケーションが配布されます。アプリケーション名と EAR ファイルの名前と場所は、OC4J の/j2ee/home/config/server.xmlファイルの applicationタグで指定します。

Oracle Enterprise Manager のデプロイ機能を使用しても、この処理を行えます。

EAR ファイルには次のものが含まれます。

� 標準の application.xml構成ファイル。場所 : /META-INF

� （オプション）orion-application.xml構成ファイル。場所 : /META-INF

� 標準の WAR ファイル

WAR ファイルには次のものが含まれます。

� 標準の web.xml構成ファイル。場所 : /WEB-INF

� （オプション）orion-web.xml構成ファイル。場所 : /WEB-INF

� アプリケーションを実行するために必要なすべての JSP ページと Java クラス（サーブレット、JavaBean、およびその他のクラス）。場所 : /WEB-INF/classes直下、/WEB-INF/libの JAR ファイル

server.xmlファイルの application-serverタグにある application-directory設定で指定された OC4J のアプリケーション・ディレクトリに、EAR ファイルを置きます。通常は、/j2ee/home/applicationsディレクトリになります。このディレクトリは、server.xmlの applicationタグで指定される EAR ファイルの場所と同じです。



OC4J のオート・デプロイ機能では、アプリケーション・ディレクトリ（server.xmlで指定）にある新しい EAR ファイルが自動的に検出されます。そして、server.xmlファイルの application-serverタグにある deployment-directory設定の指定に従って、階層的に抽出され、アプリケーション・デプロイ・ディレクトリに置かれます。通常は、/j2ee/home/application-deploymentsディレクトリになります。

その他の留意点その他の留意点その他の留意点その他の留意点この項では、その他の留意点について説明します。

� HTTP パラメータのグローバリゼーションについての留意点

� タグ・ハンドラの再利用

� セッション・キーのシードの生成

HTTP パラメータのグローバリゼーションについての留意点パラメータのグローバリゼーションについての留意点パラメータのグローバリゼーションについての留意点パラメータのグローバリゼーションについての留意点

Oracle9iAS リリース 9.0.2 には、新しいグローバリゼーション機能が用意されています。

setCharacterEncoding() メソッドメソッドメソッドメソッド

Servlet2.3 仕様で効果的に機能するため、HTTP リクエストを読み取るときの非デフォルト文字エンコーディングを指定する標準機能として setCharacterEncoding()がjavax.servlet.ServletRequestクラスで使用できるようになりました。このメソッドのシグネチャは次のとおりです。

void setCharacterEncoding(java.lang.String enc) throws java.io.UnsupportedEncodingException

encパラメータは、設定する文字エンコーディングの名前を指定する文字列です。この設定はデフォルトの設定より優先されます。このメソッドを呼び出してから、getReader()メソッドを使用してリクエスト・パラメータや入力を読み込んでください（getReader()メソッドも ServletRequestクラスのメソッドです）。

対応する次の getter メソッドもあります。

String getCharacterEncoding()

Servlet2.3 より前の環境で使用されていた Oracle9iAS の以前のリリースでは、setCharacterEncoding()メソッドを使用できませんでした。 Servlet2.0 仕様の JServ 環境に代表されるそのような環境では、Oracle で JSP を実装することによって、標準外の拡張機能として、次の 2 つの機能を使用できました。

� oracle.jsp.util.PublicUtil.setReqCharacterEncoding()メソッド（推奨）

� translate_params構成パラメータ（または等価コード）

OC4J を使用する場合は、標準の setCharacterEncoding()に移行する必要があります。



文字形式での静的テキスト文字形式での静的テキスト文字形式での静的テキスト文字形式での静的テキスト

Oracle9iAS の以前のリリースでは主要なサーブレット環境だった JServ では、静的テキストが文字で出力されます。 OC4J では、より高いスループットを実現するため、デフォルトでは静的テキストがバイトコードで出力されます。

静的テキストがバイトコードで生成される場合、一部のグローバリゼーション機能が使用できなくなり、柔軟性が失われます。このため、OC4J JSP コンテナでは static_text_in_chars構成パラメータをサポートし、文字形式での出力に設定を戻せるようにしています。

たとえば、実行中でも文字エンコーディングに動的に変更できる機能が、使用しているアプリケーションで必要な場合は、次のように設定してフラグを有効化します。

<% response.setContentType("text/html; charset=UTF-8"); %>

jsp:param 設定の適切な処理設定の適切な処理設定の適切な処理設定の適切な処理

次のような jsp:includeタグとネストした jsp:paramタグがある場合を考えます。

<jsp:include page="..." > <jsp:param name="..." value="..." /></jsp:include>

Oracle9iAS リリース 2（9.0.2）の OC4J JSP コンテナでは、jsp:paramタグに name設定とvalue設定を手動でエンコーディングする必要はありません。適切な Java の文字列を使用すれば、自動的にエンコーディングされます。以前の Oracle9iAS リリース 1（1.0.2.2.x）のOrion JSP コンテナでは、手動でのエンコーディングが必要でした。

タグ・ハンドラの再利用タグ・ハンドラの再利用タグ・ハンドラの再利用タグ・ハンドラの再利用

Oracle9iAS リリース 2（9.0.2）の OC4J では、JSP ページ・コンテキストでoracle.jsp.tags.reuse属性を設定することによって、JSP タグ・ハンドラのインスタンスを特定の JSP ページ（常に applicationスコープ）にプールするかどうかを指定できます。 trueに設定するとプールされ、falseに設定するとプールされません。たとえば、次のようになります。

pageContext.setAttribute("oracle.jsp.tags.reuse", new Boolean(true));

ページごとに設定することも、1 つのページのさまざまなセクションに異なる設定を適用することもできます。

デフォルト設定は、tags_reuse_default JSP 構成パラメータで指定されているとおりです。 OC4J では trueに、JServ では falseに設定されています。



セッション・キーのシードの生成セッション・キーのシードの生成セッション・キーのシードの生成セッション・キーのシードの生成

Oracle9iAS リリース 2（9.0.2）の OC4J では、よりセキュアな手順でセッション・キーのシードを生成します。初の HttpSessionオブジェクトが OC4J インスタンスで生成されると、セッション・キーのシードを生成するための多数のスレッドが作成されます。このため、セッション・オブジェクトを使用する JSP ページを初めてコンパイルするときや提供するときに、Oracle9iAS リリース 1（1.0.2.2.x）の OC4J 環境の場合よりも時間がかかります。シードが生成された後は、JSP ページのコンパイルや提供にかかる時間が以前の長さに戻ります。

JServ からからからから OC4J への移行への移行への移行への移行この項では、Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iAS リリース 2（9.0.2）へ、サーブレット・アプリケーションを移行する場合に留意すべき点を説明します。また、Apache JServ サーブレット 2.0 の環境から、Oracle9iAS Containers for J2EE（OC4J）のサーブレット 2.3 の環境へスムーズに移行する方法についても説明します。

具体的な内容は、アプリケーション環境とサーブレット・ゾーンについて、クラスとファイルの場所、マウント・ポイント、サーブレット別名、初期化パラメータ、環境と JVM 設定、サーブレットの事前起動、クラスのロード、ログ取得、サーブレット・セッション、ロード・バランシングおよびフォルト・トレランスについてです。この項の項目は次のとおりです。

� Web アプリケーション環境

� アプリケーション構造、ファイルの場所およびデプロイ

� サーブレット環境の設定

� サーブレット実行時の留意点

� ロード・バランシングとフォルト・トレランス

ほとんどの項目は、JServ に関する参照情報、OC4J に関する参照情報の順で構成されています。

詳細は、『Oracle9iAS Containers for J2EE Servlet 開発者ガイド』および『Oracle9iAS Containers for J2EE ユーザーズ・ガイド』を参照してください。

注意注意注意注意 : この項は、読者が、Sun 社の Java Servlet Specification2.2 および2.3、WAR（Web Archive）ファイル、EAR（Enterprise Archive）ファイルおよび web.xmlについて、ある程度の予備知識を持っていることを前提としています OC4J の構成ファイルに関する予備知識があると、なおよいでしょう。



Web アプリケーション環境アプリケーション環境アプリケーション環境アプリケーション環境Oracle9iAS リリース 1（1.0.2.2.x）では、Java Servlet Specification 2.0 仕様の Apach JServ が主たるサーブレット環境でした。 Servlet 2.0 の仕様では、Web アプリケーションの概念が明確に定義されていなかったので、サーブレット・コンテキストと Web アプリケーションの間の関連性が定義されていませんでした。 JServ などの Servlet 2.0 環境では、1 つの JVM に対してサーブレット・コンテキスト・オブジェクトは 1 つしかありません。 Servlet 2.0 環境には、セッション・オブジェクトも 1 つしかありません。

Oracle9iAS リリース 2（9.0.2）では、OC4J が主たるアプリケーション環境です。 OC4J には、標準の Web アプリケーションをサポートする Servlet2.3 コンテナが含まれます。

この項の項目は次のとおりです。

� サーブレット・コンテキストとサーブレット・パスのマッピング

� デフォルトの Web アプリケーションのルート・コンテキストの変更

� サーブレット・ゾーンと Web アプリケーションの比較

サーブレット・コンテキストとサーブレット・パスのマッピングサーブレット・コンテキストとサーブレット・パスのマッピングサーブレット・コンテキストとサーブレット・パスのマッピングサーブレット・コンテキストとサーブレット・パスのマッピング

Servlet2.2 および 2.3 の仕様では、それぞれの Web アプリケーションがサーブレット・コンテキストを持ちます。この点が Servlet2.0 の JServ 環境とは異なります。この項では、Servlet 2.2 および 2.3 の機能の概要を説明します。

それぞれのサーブレット・コンテキストは、Web アプリケーションのモジュールへのベース・パスである、サーバー・ファイル・システム内のディレクトリ・パスに関連付けられています。このパスを、アプリケーション・ルートと呼びます。 Web アプリケーションごとに、アプリケーション・ルートが存在します。 Servlet2.2 および 2.3 環境の Web アプリケーションでは、サーブレット、JSP ページおよび HTML ファイルなどの静的ファイルは、すべてこのアプリケーション・ルートに基づきます。一方、Servlet2.0 環境では、サーブレットおよびJSP ページのアプリケーション・ルートと静的ファイルのドキュメント・ルートは異なります。

サーブレットを呼び出すための URL パスは、次のような構成になります。

http://host[:port]/contextpath/servletpath

サーブレット・コンテキストが作成されると、アプリケーション・ルートと URL のコンテキスト・パスのマッピングが指定されます。サーブレット・パスは、アプリケーションのweb.xmlファイルで定義されます。具体的には、web.xml内の <servlet>タグによって、サーブレット・クラスとサーブレット名が関連付けられ、web.xml内の<servlet-mapping>タグによって、サーブレット名と URL パターンが関連付けられます。リクエストが Web アプリケーションへ届くと、サーブレット・コンテナは、リクエストに含まれるパスと web.xmlで定義されている既存の URL パターンを比較し、一致するURL パターンのサーブレットを呼び出します。詳細は、『Oracle9iAS Containers for J2EE Servlet 開発者ガイド』を参照してください。



たとえば、あるアプリケーションのアプリケーション・ルートが/home/dir/mybankapp/mybankwebappであり、これが、コンテキスト・パスである/mybankにマップされているとします。さらに、そのアプリケーションには、サーブレット・パスが loginservletであるサーブレットが含まれているとします。この場合、このサーブレットを呼び出す URL は次のようになります。

http://host[:port]/mybank/loginservlet

アプリケーションのルート・ディレクトリそのものは、エンド・ユーザーには見えません。

この例で、このアプリケーションで HTML ページがリクエストされる場合を考えます。次の URL は、/home/dir/mybankapp/mybankwebapp/dir1/abc.htmlにあるファイルを参照しています。

http://host[:port]/mybank/dir1/abc.html

それぞれのサーブレット環境には、デフォルトのサーブレット・コンテキストがあります。デフォルト・コンテキストの場合、コンテキスト・パスは、"/" だけになり、デフォルトのサーブレット・コンテキストのアプリケーション・ルートにマップされます。たとえば、デフォルト・コンテキストのアプリケーション・ルートが/home/dir/defaultapp/defaultwebappであり、サーブレット・パスが myservletであるサーブレットが、このデフォルト・コンテキストを使用するとします。このサーブレットを呼び出す URL は次のようになります。

http://host[:port]/myservlet

URL で指定されたコンテキスト・パスに一致するものがない場合も、デフォルト・コンテキストが使用されます。

この例で、HTML ファイルがリクエストされる場合を考えます。次の URL は、/home/dir/defaultapp/defaultwebapp/dir2/def.htmlにあるファイルを参照しています。

http://host[:port]/dir2/def.html

デフォルトのデフォルトのデフォルトのデフォルトの Web アプリケーションのルート・コンテキストの変更アプリケーションのルート・コンテキストの変更アプリケーションのルート・コンテキストの変更アプリケーションのルート・コンテキストの変更Oracle9iAS リリース 2（9.0.2）では、デフォルトの Web アプリケーションのルート・コンテキストは、"/j2ee" です。リリース 1.0.2.2 では、ルート・コンテキスト・パスは "/" だったので、この変更によって、デフォルトの Web アプリケーションでのデプロイに影響が及びます。 OC4J で提供されているサンプルやデモも同様です。

リリース 1.0.2.2 で次の URL によって呼び出されていた、デフォルトの Web アプリケーションのサーブレットの場合を考えます。

http://host[:port]/servlet/myservlet



リリース 2（9.0.2）では、このサーブレットを呼び出す URL が次のようになります。

http://host[:port]/j2ee/servlet/myservlet

サーブレット・ゾーンとサーブレット・ゾーンとサーブレット・ゾーンとサーブレット・ゾーンと Web アプリケーションの比較アプリケーションの比較アプリケーションの比較アプリケーションの比較JServ にはサーブレット・ゾーンの概念がありました。サーブレット・ゾーンは、Servlet2.2以上の仕様の Web アプリケーションの概念に相当します。この項では、JServ における基本的なゾーン設定と、OC4J における基本的なアプリケーション設定を比較検討します。

JServ のゾーン仕様の基本のゾーン仕様の基本のゾーン仕様の基本のゾーン仕様の基本

JServ は、サーブレット・ゾーンを使用します。サーブレット・ゾーンとは、Web アプリケーションの概念に似ています。ゾーンを使用することによって、JServ 環境全体を複数のサーブレットのグループに分けて開発することができます。グループは、ワーク・ロード、使用率、セキュリティ権限などの条件別に作成されます。 JServ では、サーブレットは、サーブレット・ゾーンに基づいてグループ化され、管理されます。サーブレット・コンテナそのものには関係しません。サーブレット・ゾーンは少なくとも 1 つ必要です。

サーブレット・ゾーンは、jserv.propertiesファイルで指定されます。さらに、ゾーンごとにゾーン・プロパティ・ファイルと呼ばれる構成ファイルがあります。このファイルは通常、zonexxx.propertiesのような命名規則に基づきます。

jserv.propertiesでのゾーン設定の例です。

zones = zone1,zone2

それぞれのゾーンに対応するゾーン・プロパティ・ファイルの場所は、jserv.propertiesで次のように指定されます。

zone1.properties =/servlet/zone1/zone1.properties zone2.properties =/servlet2/zone2/zone2.properties

OC4J アプリケーション仕様の基本アプリケーション仕様の基本アプリケーション仕様の基本アプリケーション仕様の基本

OC4J では、Web アプリケーションがゾーンに相当すると考えることができます。また、OC4J でも、サーブレットはアプリケーションごとにグループ化され、管理されています。さらに、OC4J には、デフォルトのグローバル・アプリケーションという概念があり、これが、すべてのアプリケーションの親になり、デフォルトの Web アプリケーションを定義します。

OC4J では、EAR ファイルを使用してアプリケーションをデプロイします。 EAR ファイルを配布する場合、少なくとも次のファイルを設定する必要があります。

� default-web-site.xml

� web.xml



上記のファイルのかわりに、orion-web.xmlファイルを使用して、アプリケーション固有の OC4J 機能を設定することもできます。 web.xmlファイルと orion-web.xmlファイルは、通常 WAR ファイルに含まれます。

次に、Web アプリケーションで使用される主な OC4J 構成ファイルの概要を示します。

次のファイルは、すべての OC4J アプリケーションで使用されるグローバル・ファイルです。通常は、/j2ee/home/configディレクトリにあります。

� default-web-site.xml — デフォルトの Web サイトで使用される各 Web アプリケーションに対する <web-app>要素を含みます。この要素の "Web application name" で指定された名前にアプリケーション名がマップされます。 Web アプリケーション名はWAR 配布ファイル名に対応します。 server.xmlファイルで追加の Web サイト用として指定されている、追加の Web サイト用 XML ファイルも同じように使用されます。

� global-web-application.xml — OC4J の Web アプリケーションで使用されるグローバル構成ファイルで、デフォルト構成を確立し、JSP のフロントエンド・サーブレットの設定と構成を行うファイルです。

� application.xml — OC4Jの J2EEアプリケーションが使用するグローバル構成ファイルです。

� data-sources.xml — データベース接続で使用されるデータ・ソースを指定します。

グローバルな application.xmlファイル以外に、標準の application.xmlファイルおよびオプションで使用できる orion-application.xmlファイルがアプリケーションごとにあります。これらのファイルは、アプリケーションの EAR ファイルに含まれます。

さらに、アプリケーション EAR ファイルに含まれるアプリケーション WAR ファイルには、標準の web.xmlファイルおよびオプションで使用できる orion-web.xmlファイルがあります。このようなアプリケーション固有およびデプロイ固有の構成ファイルでの設定は、global-web-application.xmlでの設定より優先されます。あるいは、必要な設定を追加します。 global-web-application.xmlファイルと orion-web.xmlファイルは、同じ要素をサポートします。これらは、web.xmlファイルがサポートする要素のスーパーセットです。

orion-application.xmlファイルと orion-web.xmlファイルがアーカイブ・ファイル内にない場合は、global-web-application.xmlファイルの設定に従って、初回の配布時に生成されます。

これらのファイルの使用方法の詳細は、『Oracle9iAS Containers for J2EE ユーザーズ・ガイド』および『Oracle9iAS Containers for J2EE Servlet 開発者ガイド』を参照してください。



アプリケーション構造、ファイルの場所およびデプロイアプリケーション構造、ファイルの場所およびデプロイアプリケーション構造、ファイルの場所およびデプロイアプリケーション構造、ファイルの場所およびデプロイこの項では、一般的な OC4J Web アプリケーションの構造、OC4J と JServ におけるファイルの場所の設定方法の違い、およびアプリケーションのデプロイ方法の基本について説明します。この項の項目は次のとおりです。

� JServ のファイル・リポジトリ

� OC4J のアプリケーション構造とファイルの場所

� OC4J のデプロイ

JServ のファイル・リポジトリのファイル・リポジトリのファイル・リポジトリのファイル・リポジトリ

サーブレット・ゾーン内のサーブレットの場所、つまりリポジトリは、ゾーン・プロパティ・ファイルの repositoriesコマンドで指定されます。（詳細は、3-23 ページの

「JServ のゾーン仕様の基本」を参照してください。） JServ は、リポジトリ・エントリで指定された場所からクラスをロードします。次に例を示します。

repositories=/private/mydir/net.jar repositories=/private/mydir/tmp/net.zip repositories=/private/mydir/applications

例に示すように、クラス・ファイルはディレクトリまたはアーカイブ・ファイル（.zipまたは .jar）から直接読み込まれます。リポジトリとクラスのロードの詳細は、3-36 ページの「JServ におけるクラスのロード」を参照してください。

OC4J のアプリケーション構造とファイルの場所のアプリケーション構造とファイルの場所のアプリケーション構造とファイルの場所のアプリケーション構造とファイルの場所図 3-1 は、アプリケーション・ルート・ディレクトリ下の通常（推奨）の Web アプリケーション構造を示します。（アプリケーション構造の大半は Servlet2.2 および 2.3 環境にあてはまります。）

OC4J では、ルート・ディレクトリは、app-name/web-app-nameです。アプリケーション名は、server.xmlファイルで定義され、default-web-site.xmlファイルまたは他のWeb サイト用 XML ファイルで、Web アプリケーション名にマップされます。



図図図図 3-1 OC4J のアプリケーション構造のアプリケーション構造のアプリケーション構造のアプリケーション構造

この構造に従って、サーブレット・クラスを <application_name>/<web-app-name>/WEB-INF/classesディレクトリ下に置きます。必要に応じて、パッケージ名に従ってサブディレクトリにも置きます。たとえば、examplesパッケージにHelloWorldServletがある場合、クラス・ファイルの場所は次のようになります。

<application_name>/<web-app-name>/WEB-INF/classes/examples/HelloWorldServlet

HTML ファイル、JSP ページおよびその他のリソース・ファイルは、アプリケーション・ルート・ディレクトリに置きます。

JAR ファイルなどの必要なライブラリ・ファイルは、次のディレクトリに置きます。

<application_name>/<web-app-name>/WEB-INF/lib

図に示すように、JServ の場合と同様に OC4J でも、クラス・ファイルはディレクトリまたはアーカイブ・ファイル（.zip または .jar）から直接読み込まれます。



コード・ベースを指定することもできます。コード・ベースを指定するには、必要なファイルを好きな場所へ置き、orion-web.xmlファイルの <orion-web-app>要素の<classpath>サブ要素で、その場所をクラスパスへ追加します。

<classpath path="/private/test/test.jar" />

OC4J のデプロイのデプロイのデプロイのデプロイOC4J では、Oracle Enterprise Manager（OEM）を使用してアプリケーションをデプロイします。また、OC4J におけるデプロイでは、通常、EAR（Enterprise Archive）ファイルが使用されます。

次の例を使用して、HelloServletというサーブレットおよび Hello.jspという JSP ページを持つ簡単なアプリケーションの EAR ファイルを作成します。

1. web.xmlファイルおよび orion-web.xmlファイル（オプション）を作成および設定して、アプリケーション固有の設定を指定します。

2. JAR ユーティリティを使用して、アプリケーション・ルートから、helloapp.warという名前の WAR ファイルを作成します。

helloapp.warファイルには次のものが含まれます。

META-INF/MANIFEST.MFWEB-INF/WEB-INF/classes/WEB-INF/classes/HelloServlet.classWEB-INF/orion-web.xmlWEB-INF/web.xmlHello.jsp

（META-INF/MANIFST.MFファイルは JAR ユーティリティによって作成されます。このファイルを変更する必要はありません。）

3. アプリケーションのデプロイを実行するための EAR ファイルである helloapp.earを作成します。

EAR ファイルには次のものが含まれます。

META-INF/META-INF/MANIFEST.MFMETA-INF/application.xmlMETA-INF/orion-application.xmlhelloapp.war

EAR ファイルを配布するには、application.xmlファイルが必要ですが、orion-application.xmlファイルでも代用できます。



作成した helloapp.warファイルを使用して、Web アプリケーションをデプロイできます。このとき OEM を使用します。

サーブレット環境の設定サーブレット環境の設定サーブレット環境の設定サーブレット環境の設定この項では、様々なサーブレットの設定上のポイントを取り上げ、JServ および OC4J の設定手順を確認します。この項の項目は次のとおりです。

� JVM パラメータと環境変数

� マウントの設定

� サーブレット別名と URL マッピング

� 初期化パラメータ

JVM パラメータと環境変数パラメータと環境変数パラメータと環境変数パラメータと環境変数

この項では、JVM および環境変数の設定方法を、JServ と OC4J の場合で比較します。

JServ における環境変数の設定における環境変数の設定における環境変数の設定における環境変数の設定

jserv.propertiesで、Oracle 環境の設定など、JVM で使用される環境変数を設定できます。次は Oracle の設定の例です。

wrapper.env=LD_LIBRARY_PATH=...wrapper.env=ORACLE_HOME=... wrapper.env=ORACLE_SID=...

Java およびシステムの環境も設定できます。

� 次のように、クラスパスを設定します。

wrapper.classpath=...

� 次のように、パスを設定します。

wrapper.path=...

UNIX におけるデフォルトは次のとおりです。

/bin:/usr/bin:/usr/local/bin:

� 次のように、Java インタプリタのフルパスを設定します（パスで参照できない場合）。

wrapper.bin=...

� wrapper.bin.parametersで、ヒープやスタックのサイズなど、JVM のロード・パラメータを設定します。次に例を示します。

wrapper.bin.parameters=-Xms64m



� wrapper.env.copyまたは wrapper.env.copyallを使用して、コール元から JVMへ環境パラメータをコピーします。次の初の例は、すべての環境パラメータをコピーします。2 番目の例は、特定の環境パラメータ（この場合は myparam）をコピーします。

wrapper.env.copyall

wrapper.env.copy=myparam

さらに JServ には、security.maxConnections、security.allowedaddressesおよび security.authenticationのセキュリティ・パラメータがあります。

OC4J における環境変数の設定における環境変数の設定における環境変数の設定における環境変数の設定

OC4J で環境パラメータを設定するために使用されるメソッドは、起動方法によって異なります。

OPMN での起動

OC4J が OEM（opmnプロセス管理モジュールの OPMN）で起動されている場合は、$ORACLE_HOME/opmn/conf/opmn.xml構成ファイルを使用してパラメータを設定できます。特に、<oc4j>要素の次のサブ要素が関係します。

� <java-bin>を使用して、Java 実行可能ファイルへのパスを指定します。この要素が指定されないと、$ORACLE_HOME/jdk/bin/javaがデフォルトで使用されません。

� <java-option>を使用して、JVM が必要とするコマンドライン・パラメータを指定します。

<java-bin>サブ要素は、JServ の wrapper.binと同じです。 <java-option>サブ要素は、JServ の wrapper.bin.parametersと同じです。

次に例を示します（<oc4j>要素の構文の関連部分のみ）。

<oc4j numProcs="1" maxRetry="4" ... > <java-bin path="/private/my-sun/jdk/bin/java" /> <java-option value="-Xmls32m -Xmx64m -Xss128K -Doracle.ons.oraclehome=/private/oracle" /> ...</oc4j>

また、opmn.xmlファイルの <environment>要素を使用して、Oracle の環境変数を指定できます。次に例を示します。

<environment> <prop name="PATH" value="/private/home/ias/lib"/> <prop name="CLASSPATH" value="/private/home/ias/bin" /> <prop name="LD_LIBRARY_PATH" value="/private/home/lib" /></environment>



この設定は、新しいプロセスの起動時にそのプロセスの環境を設定します。

OPMN の詳細は、『Oracle9i Application Server 管理者ガイド』を参照してください。

マウントの設定マウントの設定マウントの設定マウントの設定

JServ（mod_jserv）および OC4J（mod_oc4j）には、それぞれ、" マウント・ポイント "と呼ばれるアプリケーション・ルートの場所を決定するための " マウント " コマンドがあります。

JServ におけるマウントの設定におけるマウントの設定におけるマウントの設定におけるマウントの設定

JServ では、マウント・ポイントを使用して、様々なサーブレット・ゾーンのルートの場所を定義します。プロトコル、ホスト、ポートが指定されていない場合は、jserv.confファイルにデフォルトで入力されているものから選択されます。このファイルは、httpd.confファイルに含まれます。

次のサンプルのマウント・コマンドを見てください。

ApJServMount /servlets /rootApJServMount /servlets/admin ajpv11://myhost:9009/admin

この 2 つのコマンドを基に、たとえば、次が実行されます。

� 初の ApJServMountコマンドを実行すると、次の URL が、サーブレット・ゾーンのrootにある HelloWorldServletサーブレットをリクエストします。

http://myhost.mycompany.com/servlets/HelloWorldServlet

� 2 番目の ApJServMountコマンドを実行すると、次の URL が、Apache JServ Protocol（AJP）バージョン 1.1 を使用して、ポート 9009 を経由して処理されます。

http://myhost.mycompany.com/servlets/admin/HelloWorldServlet

OC4J におけるマウントの設定におけるマウントの設定におけるマウントの設定におけるマウントの設定

OC4J と Oracle HTTP Server 環境では、$ORACLE_HOME/Apache/Apache/conf/mod_oc4j.confファイルを使用してマウント・ポイントを指定できます。ホストやポートなど、その他の関連する Java サイドの設定は、default-web-site.xmlファイルで行うことができます。

前項の「JServ におけるマウントの設定」を読んで比較してください。次の JServ の例をもう一度見てみましょう。

ApJServMount /servlets/admin ajpv11://myhost:9009/admin



default-web-site.xmlの <web-site>要素でも、同じようにプロトコルとホストを設定できます（デフォルト以外の Web サイトについては、他の Web サイト用 XML ファイルを使用します）。

<web-site port="9009" protocol="ajp13" ...>...</web-site>

また、<web-site>要素の <web-app>サブ要素を使用すると、対応する Web アプリケーション名やアプリケーション・ルートなど、サイト上のアプリケーション情報を個々に指定することができます。次に例を示します。

<web-app application="ojspdemos" name="ojspdemos-web" root="/ojspdemos" />

OC4J は、default-web-site.xml（またはその他の Web サイト用 XML ファイル）のアプリケーション設定に従って、ターゲット・ホストの myhost上から Web アプリケーションを検索します。

先に入力される Oc4jMountコマンドに基づいて、次のリクエストが、Apache JServ Protocol（AJP）バージョン 1.3 を使用してポート 9009 上の myhostをリッスンする OC4Jプロセスにルーティングされます。

http://myhost.mycompany.com/servlets/admin/HelloWorld

myhost上の Web サイト用 XML ファイルのアプリケーション設定に従って、OC4J はアプリケーションを検索します。

OEM（opmnプロセス）が OC4J を起動し、mod_oc4j.confで次を追加すると、opmnプロセスは、使用できる適当な AJP ポートを探して、すべての可能性のあるポートをスキャンします。フォーム /servlets/admin/*のリクエストは、デフォルトの home の OC4J インスタンスにある OC4J JVM の 1 つに送られます。

Oc4jMount /servlets/admin/*

これは、次の default-web-site.xmlファイルのデフォルト設定に関係します。

<web-site port="0" protocol="ajp13" ...>...</web-site>

重要重要重要重要 : Oc4jMountコマンドで指定されるホストとポートは、default-web-site.xmlファイルの ajp13プロトコルに対して指定されるホストおよびポートと同じである必要があります。



特定の OC4J インスタンス、クラスタ間のロード・バランシングおよび Oracle9iAS のインスタンス間のロード・バランシングも指定できます。次に例を示します。

Oc4jMount /servlets/admin/* oc4j_inst1Oc4jMount /servlets/admin/* cluster://ias_cluster_1:home,ias_cluster_2:homeOc4jMount /servlets/admin/* instance://ias_inst_1:home_1,ias_inst_2:home_2

Oc4jMountコマンドの詳細は、『Oracle9i Application Server Oracle HTTP Server 管理ガイド』を参照してください。 default-web-site.xmlファイルとその他の Web サイト用XML ファイルの詳細は、『Oracle9iAS Containers for J2EE Servlet 開発者ガイド』を参照してください。

サーブレット別名とサーブレット別名とサーブレット別名とサーブレット別名と URL マッピングマッピングマッピングマッピング

この項では、サーブレット別名と URL マッピングの指定について、JServ と OC4J における方法を比較検討します。

JServ におけるサーブレット別名とにおけるサーブレット別名とにおけるサーブレット別名とにおけるサーブレット別名と URL マッピングマッピングマッピングマッピング

JServ では、サーブレット別名を該当するゾーン・プロパティ・ファイルで指定します。たとえば、サーブレット・クラスの example.extensionmapping.InputServletに対して、別名の inputservletを指定することによって、フルパスで指定しなくてもサーブレットを呼び出せます。次のように指定します。

servlet.inputservlet.code = example.extensionmapping.InputServlet

マウント・ポイントなどの URL 拡張子でのマッピングは、jserv.confファイルで定義します。次に例を示します。

ApJServAction .inp /servlets/example.extensionmapping.InputServlet

末尾が ".inp" の URL が InputServletにマップされます。

次のマウント・コマンドを想定します。

ApJServMount /servlets /root

ApJServMountコマンドと ApJServActionコマンドによって、次の URL が、サーブレット・ゾーン rootにある example.extensionmapping.InputServletに渡されます。

http://myhost.mycompany.com/EmployeeInput.inp



OC4J におけるサーブレット別名と拡張子マッピングにおけるサーブレット別名と拡張子マッピングにおけるサーブレット別名と拡張子マッピングにおけるサーブレット別名と拡張子マッピング

OC4J では、サーブレット別名と URL マッピングを global-web-application.xmlファイルで次のように指定します。

<servlet> <servlet-name>inputservlet</servlet-name> <servlet-class>example.extensionmapping.InputServlet</servlet-class></servlet>...<servlet-mapping> <servlet-name>inputservlet</servlet-name> <url-pattern>/*.inp</url-pattern></servlet-mapping>

サーブレット名（別名）は何でもかまいません。サーブレット・クラスと<servlet-mapping>要素で指定される URL 拡張子を関連付けるための参照名としてだけ使用されるからです。

初期化パラメータ初期化パラメータ初期化パラメータ初期化パラメータこの項では、サーブレット初期化パラメータの設定方法について、JServ と OC4J の場合の違いを説明します。

JServ における初期化パラメータの設定における初期化パラメータの設定における初期化パラメータの設定における初期化パラメータの設定

JServ では、ゾーン全体のデフォルト・パラメータ設定だけでなく、サーブレット・ベースの初期化パラメータの設定（initArgs）もサポートします。初期化パラメータは、該当するゾーン・プロパティ・ファイルで設定します。

たとえば、サーブレット foo1に対して、nameパラメータにサーブレット・ベースの設定を次のように指定します。

servlet.foo1.initArgs=name=scott

ゾーン全体のデフォルト設定は、そのゾーンにあるすべてのサーブレットで共有されます。これは、次のように指定します。 companyパラメータのデフォルト設定が指定されます。

servlets.default.initArgs=company=oracle

同じ名前のパラメータに対しては、サーブレット・ベースの設定の方が、ゾーン全体（デフォルト）の設定よりも優先されます。



OC4J における初期化パラメータの設定における初期化パラメータの設定における初期化パラメータの設定における初期化パラメータの設定

OC4J では、サーブレット・ベースの初期化パラメータを、標準の web.xmlファイルの<servlet>要素のサブ要素を使用して設定します。次で設定されている内容は、前の項でfoo1サーブレットを使用して設定したものと同じです（サーブレット・クラスも指定しています）。

<servlet> <servlet-name>foo</servlet-name> <servlet-class>FooServlet</servlet-class> <init-param> <param-name>name</param-name> <param-value>scott</param-value> </init-param></servlet>

OC4J には、ゾーン全体の設定という概念がありません。つまり、アプリケーション全体に適用されるデフォルトの設定を行う仕組みがありません。しかし、context-paramを使用すれば、概念的には同じような設定が可能です。それぞれの Web アプリケーションに対して、サーブレット・コンテキストがあります。アプリケーションの web.xmlファイルで、そのコンテキストに属性を設定できます。次に例を示します。

<context-param> <param-name>company</param-name> <param-value>oracle</param-name></context-param>

コンテキスト・パラメータを設定するには、javax.servlet.ServletContextクラスの標準の servlet2.3 メソッドを使用します。次の例は、ServletContextインスタンスの初期化パラメータ名のリストを返します。

ServletContext ctx = getConfig().getServletContext();ctx.getInitParameterNames();

次のコールでは、companyパラメータの値を取得します。

ctx.getInitParameter("company");



サーブレット実行時の留意点サーブレット実行時の留意点サーブレット実行時の留意点サーブレット実行時の留意点この項では、サーブレットの実行とクラスのロードに関して移行時に留意すべき点を説明します。この項の項目は次のとおりです。

� サーブレットの事前起動

� クラス・ローダーとクラスの自動再ロード

� セッションのトラッキングと動作

� メッセージおよびエラーのロギング

サーブレットの事前起動サーブレットの事前起動サーブレットの事前起動サーブレットの事前起動

JServ でも OC4J でも、サーブレットは事前起動できます。初のリクエストが届いてからサーブレット・インスタンスを生成するのではなく、あらかじめサーブレットを作成しておき、サーブレット・コンテナの起動時に、サーブレット・コンテナによって作成したサーブレットを起動できます。これにより、初のリクエストへの応答にかかる時間を短縮できます。

JServ における事前起動とタイムアウトの設定における事前起動とタイムアウトの設定における事前起動とタイムアウトの設定における事前起動とタイムアウトの設定

JServ では、次のように、事前起動するサーブレットを該当するゾーン・プロパティ・ファイルで指定します。

servlets.startup=oracle.sample.test1.HelloWorld,foo1

この設定では、HelloWorldと foo1サーブレットが事前起動します。

完全な名前のかわりに別名を使用しても指定できます。

JServ のゾーン・プロパティ・ファイルでは、次のパラメータをサポートします。OC4J には、これらに相当するパラメータはありません。

� 初期化のタイムアウト時間（この時間を過ぎたら、サーブレット・コンテナは初期化を中止する）を指定するパラメータと、サーブレットが破棄された後のタイムアウト時間を指定するパラメータ。

init.timeoutdestroy.timeout

� シングルスレッド・モデルのパラメータ — サーブレットがjavax.servlet.SingleThreadModelインタフェースを実装する場合に作成されるサーブレット・インスタンスの数を指定します。

SingleThreadModelServlet.initialCapacitySingleThreadModelServlet.incrementCapacitySingleThreadModelServlet.maximumCapacity



OC4J における事前起動の設定における事前起動の設定における事前起動の設定における事前起動の設定

OC4J では、アプリケーションの web.xmlファイルの <servlet>要素の<load-on-startup>サブ要素を使用することによって、サーブレットを事前起動できます。

<servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>oracle.sample.test1.HelloWorld</servlet-class> <load-on-startup/></servlet>

クラス・ローダーとクラスの自動再ロードクラス・ローダーとクラスの自動再ロードクラス・ローダーとクラスの自動再ロードクラス・ローダーとクラスの自動再ロードこの項では、サーブレットのクラス・ローダーとサーブレット実行時のクラスの再ロードについて説明します。

JServ におけるクラスのロードにおけるクラスのロードにおけるクラスのロードにおけるクラスのロード

この項では、JServ 環境におけるクラス・ローダーとクラスの再ロードについて説明します。

次のそれぞれに対して独立したクラス・ローダーがあります。

� システム・クラス — システム・クラスパスのクラス

JServ を自動的に起動する場合、システム・クラスパスは、jserv.propertiesファイルの wrapper.classpathの設定で決まります。 JServ を手動で起動する場合、システム・クラスパスは、特定の JServ インスタンスの CLASSPATHの設定で決まります。

システム・クラスパス（サーブレット・クラスを含む）からロードされるクラスを自動的に再ロードするには、サーバーを再起動する必要があります。

� ゾーン・クラス — ゾーン・クラスパスのクラス

ゾーン・クラスパスは、ゾーン・プロパティ・ファイルの repositoriesパラメータで指定されます。

次の点に注意してください。

� システム・クラスパスからロードされるクラスは、同一の JVM のすべてのゾーンで共有されます。

� それぞれのサーブレット・ゾーンは、ゾーン・クラスパスのクラスに対して、カスタム・クラス・ローダーの独自のインスタンスを持ちます。

� ゾーン・クラスパスからロードされるクラスは、ゾーン間で共有されません。また、複数のゾーンで使用可能なクラスがある場合、その静的変数は、ゾーンが同じ JVM 内にあっても、ゾーン間で共有されません。静的変数を共有するには、そのクラスがシステム・クラスパス内にあり、システム・クラス・ローダーでロードされるクラスである必要があります。



ゾーン・クラスパスのクラスで、ゾーン・クラス・ローダーでロードされるクラスの場合、変更後に自動的に再ロードできます。これはアプリケーションの開発段階では便利です。ゾーン・プロパティ・ファイルで次のように設定します。

autoreload.classes=true

OC4J におけるクラスのロードにおけるクラスのロードにおけるクラスのロードにおけるクラスのロード

JServ での設定に相当する、OC4J でのクラスパスとクラス・ローダーの設定は次のようになります。

� サーバー全体のクラスのロードについては、グローバルなj2ee/home/config/application.xmlファイルの <library>要素でクラスパスを設定できます。次に例を示します。

<library path="/tmp/net.jar" />

ディレクトリへのパスは、相対パスまたは絶対パスで指定できます。指定したディレクトリは、JAR ファイルまたは ZIP ファイルを対象にスキャンされ、起動時にクラスパスにインクルードされます。デフォルトでは、application.xmlファイルは、j2ee/home/libディレクトリからファイルをインクルードするように設定されています。（このパスを指定する <library>要素は、デフォルトのグローバルなapplication.xmlファイルにあります。）

� アプリケーション・ベースのクラスのロードの場合、デフォルトのクラスパスは、WEB-INF/classesディレクトリ（クラスファイルの場合はパッケージ名に基づくサブディレクトリ）と WEB-INF/libディレクトリ（JAR ライブラリと ZIP ライブラリ）で構成されます。

orion-web.xmlファイルの <classpath>要素を使用して、アプリケーションのクラスパスを追加できます。次に例を示します。

<classpath path="/private/test/test.jar" />

OC4J でサーブレットの自動的な再コンパイルと再ロードを指定するには、j2ee/home/config/global-web-application.xmlファイルまたはアプリケーションの orion-web.xmlファイル（特定のアプリケーションのglobal-web-application.xmlに優先する）の <orion-web-app>要素のdevelopment属性を trueに設定します。

注意注意注意注意 : グローバルな application.xmlファイルと、それぞれのアプリケーションの application.xmlファイルを混同しないようにしてください。



この場合、ターゲットのディレクトリにあるクラスは、クラスが変更されたとき、または、アプリケーション・レベルの XML ファイルが変更されたときに、自動的に再ロードされます。この機能は、アプリケーションの開発時には便利です。

デフォルトでは、ソース・ファイルの .javaが、自動再ロード時にターゲット・ディレクトリの WEB-INF/srcから取得されます（このディレクトリが存在する場合）。 srcディレクトリが存在しない場合は、ソース・ファイルは、WEB-INF/classes（代替ディレクトリ）から取得されます。ソース・ファイルを取得する代替ディレクトリは、次の略例のように、アプリケーションの orion-web.xmlファイルの <orion-web-app>要素のsource-directory属性で指定できます。

<orion-web-app ... source-directory="/private/scott/myservletsource" ...> ...</orion-web-app>

この場合、ファイルが取得されるのは、指定されたディレクトリからのみになります。srcディレクトリや classesディレクトリからは取得されません。

セッションのトラッキングと動作セッションのトラッキングと動作セッションのトラッキングと動作セッションのトラッキングと動作この項では、JServ 環境と OC4J 環境におけるセッションの動作と関連する設定について説明します。

JServ におけるセッションのトラッキングと動作におけるセッションのトラッキングと動作におけるセッションのトラッキングと動作におけるセッションのトラッキングと動作

JServ では、ゾーン・プロパティ・ファイルの次のパラメータを使用して、セッションの動作を指定します。

� session.useCookies — セッションで Cookie を使用するかどうかを指定します（デフォルトは trueです）。 falseの場合にセッション・トラッキングを行うには、レスポンス・オブジェクトの encodeUrl()メソッドを使用するしかありません。

� session.timeout — セッションを無効化するまでの待機時間をミリ秒単位で指定します（デフォルトは 1800000、つまり 30 分）。

� session.checkFrequency — セッションのタイムアウトをチェックする時間を秒単位で指定します（デフォルトは 30）。

OC4J におけるセッションのトラッキングと動作におけるセッションのトラッキングと動作におけるセッションのトラッキングと動作におけるセッションのトラッキングと動作

OC4J のセッション・トラッキングでは、まずサーブレット・コンテナが Cookie を使用してトラッキングを試みます。 Cookie が無効になっている場合は、サーブレットで明示的にレスポンス・オブジェクトの encodeURL()メソッドを使用する場合のみ、セッション・トラッキングを行うことができます。（encodeURL()メソッドは、Servlet 2.0 の encodeUrl()メソッドの代わりに使用できます。現在、encodeUrl()メソッドは推奨されていません。）



セッションを無効化するまでの待機時間を分単位で指定できます（デフォルトは 20）。アプリケーションの web.xmlファイルの <session-config>要素の <session-timeout>サブ要素を、次のように使用します。

<session-config> <session-timeout>30</session-timeout></session-config>

また、セッション Cookie の使用を無効にするには、global-web-application.xmlファイルまたは orion-web.xmlファイルで、次のように設定してください。

<session-tracking cookies="disabled" ... > ...</session-tracking>

（デフォルトでは Cookie は有効に設定されています。）これは、JServ で、session.useCookiesを使用して設定する場合と同じです。 JServ での場合と同様、Cookie が無効な状態でセッション・トラッキングを行うには、明示的にレスポンス・オブジェクトの encodeURL()メソッドを使用する必要があります。

メッセージおよびエラーのロギングメッセージおよびエラーのロギングメッセージおよびエラーのロギングメッセージおよびエラーのロギング

この項では、JServ 環境と OC4J 環境におけるログファイルの設定方法を比較します。

JServ におけるメッセージのロギングにおけるメッセージのロギングにおけるメッセージのロギングにおけるメッセージのロギング

ログ・ファイル名、タイムスタンプの書式などの設定を含む、メッセージ・ロギングのパラメータは、jserv.propertiesファイルで指定します。ロギングを設定しておくと、デバッグにも役立ちます。

主要なパラメータは次のとおりです。

� log — メッセージ・ログを作成するかどうかを指定します（デフォルトでは log=trueです）。

� log.file — メッセージ・ログを書き込むファイルを指定します（絶対パス名での指定を推奨します）。

� log.timestamp — メッセージの直前にタイムスタンプを挿入するかどうかを指定します（デフォルトでは log.timestamp=trueです）。

� log.dateFormat — タイムスタンプの日付書式を指定します。デフォルトの書式は、"dd/MM/yyyy HH:mm:ss:SSS.zz" です。

� log.queue.maxage — メッセージがキューに置かれる大時間をミリ秒単位で指定します。

� log.queue.maxsize — キューに置かれるメッセージの大数を指定します。



さらに、さまざまなレベルのロギング情報を有効にするための、次のようなパラメータがあります。

� log.channel

� log.channel.info

� log.channel.ServletException

� log.channel.jservException

� log.channel.warning

� log.channel.servletLog

� log.channel.critical

� log.channel.debug

OC4J におけるメッセージのロギングにおけるメッセージのロギングにおけるメッセージのロギングにおけるメッセージのロギング

OC4J でのロギングの設定は、いくつかの設定が必要なだけで、比較的簡単です。 2 つのログがあります。

サーブレット・ロギング

このドキュメントの「サーブレット・ロギング」という用語は、サーブレット・コンテキスト情報のロギングを意味します。これには、サーブレット・コンテキスト・オブジェクトのlog()メソッドを使用して、サーブレットの例外や情報に関するログを作成することも含まれます。

サーブレット・ロギングで作成するログ・ファイルを指定するには、グローバルなj2ee/home/config/application.xmlファイルの <log>要素の <file>サブ要素を使用します。次に例を示します。

<log> <file path="../log/global-application.log" /></log>

この設定よりも特定のアプリケーションでの設定を優先させるには、そのアプリケーション固有の orion-application.xmlファイルを使用して、設定してください。このファイルの詳細は、『Oracle9iAS Containers for J2EE ユーザーズ・ガイド』を参照してください。

サーバー・ロギング

サーバーの起動やシャットダウン、リカバリの通知などのサーバーの全般的な情報を記録するログ・ファイルもあります。このログ・ファイルの名前を指定するには、server.xmlファイルの <log>要素の <file>サブ要素を使用します。構文は、前述のapplication.xmlファイルの例で示したものと同じです。



Web アクセス・ロギング

このドキュメントの「Web アクセス・ロギング」という用語は、ホスト、IP アドレス、時刻、リクエスト URI、HTTP レスポンス・ステータス・コードなどの、HTTP 関連情報のトラッキングを意味します。

default-web-site.xmlファイルまたはその他の Web サイト用 XML ファイルの<web-site>要素の <access-log>サブ要素を使用して、ログ・ファイルを指定できます。次に例を示します。

<web-site ... >... <access-log path="../log/http-web-access.log" />...</web-site>

サーバーが OEM（opmnプロセス）で起動されている場合は、ログは、opmn/logsディレクトリに保存されます。通常、ログ・ファイル名は次のようになります。

$OH/opmn/logs/<oc4j_instance_name>.default_island.proc

別のログ・ファイルを使用したい場合は、$ORACLE_HOME/opmn/conf/opmn.xmlファイルの <log-file>要素を使用して指定できます。次に例を示します。

<log-file path="../logdir/my-web-access.log" level="3" />

level属性は、ロギングの重大度を 1 ～ 6 のレベルで次のように指定します。 1=FATAL、2=ERROR、3=WARN、4=NOTIFY、5=DEBUG、6=VERBOSE。

ロード・バランシングとフォルト・トレランスロード・バランシングとフォルト・トレランスロード・バランシングとフォルト・トレランスロード・バランシングとフォルト・トレランスこの項では、JServ および OC4J 環境で、ロード・バランシングおよびフォルト・トレランスを行う場合のポイントと設定について説明します。

JServ におけるリクエスト・ルーティングとロード・バランシングにおけるリクエスト・ルーティングとロード・バランシングにおけるリクエスト・ルーティングとロード・バランシングにおけるリクエスト・ルーティングとロード・バランシング

JServ では、HttpSessionオブジェクトの使用時に、該当する JServ インスタンス ID をセッション ID に追加することによって、リクエスト・ルーティングをサポートします。

セッションが起動する前に HTTP リクエストが受信された場合は、使用可能なインスタンスから任意の JServ インスタンスが選ばれ、受信したリクエストを処理し、その JServ インスタンス ID を持つ Cookie が Web ブラウザ（または他の HTTP クライアント）へ返されます。その後、同じセッションから次のリクエストが届くと、そのリクエストは、JServID を手がかりにして、前回と同じ JServ インスタンスへ送られます（前回の JServ インスタンスがダウンしている場合は、自動的に別のインスタンスへ送られます）。

関連項目関連項目関連項目関連項目 : opmnの詳細は、『Oracle9i Application Server 管理者ガイド』を参照してください。



このような機能があるため、JServ では、HttpSessionオブジェクトは分散不可能です。つまり、セッション・オブジェクトを複数の JServ インスタンス間に分散できません。このため、JServ で長い HTTP セッションが発生すると、柔軟なロード・バランシングができなくなります。また、対応する JServ JVM がクラッシュすると、セッション・データが失われます。セッションをフェイルオーバーする機能がないので、フォルト・トレランスが低いことになります。

OC4J におけるロード・バランシングとフォルト・トレランスにおけるロード・バランシングとフォルト・トレランスにおけるロード・バランシングとフォルト・トレランスにおけるロード・バランシングとフォルト・トレランス

OC4J は、OC4J インスタンスのクラスタをサポートします。クラスタはユーザーのニーズに合せてカスタマイズすることができます。 OC4J のロード・バランシングでは、リクエストによるワークロードをクラスタ内の複数のサーバーに分散することによって、大量のユーザー通信を処理できます。ロード・バランサが、HttpSessionデータなど、個々のノードの状態をクラスタへレプリケートします。（状態情報は永続的な記憶領域へは保存されません。メモリーへ格納されます。） OC4J のフォルト・トレランス機能では、万一サーバーに障害が発生した場合、自動的にクライアントがクラスタ内の別のサーバーへリダイレクトされます。

OC4J では、HTTP セッションが、ロード・バランスされたクラスタ・アイランド内の他のOC4J JVM インスタンスへレプリケートされます。これによって、JVM がダウンしてもセッション状態が失われません。これは JServ にはない機能です。

リクエストがクラスタ・アイランド内の他の JVM を経由してルーティングされる場合、適切な設定が存在すれば、他の JVM でもそのセッション状態を使用できます。また、個々のJVM がダウンした状況でも、セッション状態を使用することができます。 Web アプリケーションがスムーズに機能します。

この機能を使用するには、Web アプリケーションが、アプリケーションの web.xmlファイルの <distributable>要素で「分散可能」にマークされている必要があります。レプリケーションを正しく機能させるには、分散可能な HttpSessionインスタンスのオブジェクトが、シリアライズ可能またはリモート可能である必要があります。

OC4J でのロード・バランシングとフォルト・トレランスの詳細は、『Oracle9i Application Server パフォーマンス・ガイド』を参照してください。

例例例例 : JServ からからからから OC4J への移行への移行への移行への移行この項では、Apache JServ から OC4J へ Web アプリケーションを移行する一般的な例を紹介します。移行前の JServ の設定と移行後の OC4J の設定についても触れます。紹介する例は、必ずしも典型的なケースや良のケースではなく、説明用の事例として作成されたものです。

紹介する例では、2 つのサーブレット（ソース・ファイルであるHelloWorldServlet.javaと SessionServlet.java）、2 つの JSP ページ

（Hello.jspと snoop.jsp）およびそれに伴う .gifファイルと index.htmlファイルを使用します。



JServ における設定における設定における設定における設定

この項では、移行前の JServ の設定について説明します。

次のディレクトリ構造があるとします。

/private/scott-sun/migration-example/ index.html

classes/ HelloWorldServlet.java SessionServlet.java

jsps/ Hello.jsp snoop.jsp

examples/ index.html

images/ blk_line_bullet_35.gif red_arrow_bullet_35.gif

次の JServ 構成ファイルには、関連するエントリがあります。それぞれの構成ファイルについて説明します。

APACHE_HOME/apache/conf/jserv/jserv.conf jserv.properties zone.properties

jserv.conf の設定の設定の設定の設定

この例で使用する jserv.confファイルには次のエントリが含まれます。

Alias /migdemos /private/scott-sun/migration-exampleApJServMount /servlet /root

jserv.properties の設定の設定の設定の設定

この例で使用する jserv.propertiesファイルには次のエントリが含まれます。

zones=root

# Configuration file for each servlet zone (one per servlet zone)# Syntax: [servlet zone name as on the zones list].properties=# [full path to configFile] (String)# Default: NONE# Note: if the file could not be opened, try using absolute paths.root.properties=/private/scott-sun/apache/conf/jserv/zone.properties



zone.properties の設定の設定の設定の設定

この例で使用する zone.propertiesファイルには次のエントリが含まれます。

# List of Repositories#######################

# The list of servlet repositories controlled by this servlet zone# Syntax: repositories=[repository],[repository]...# Default: NONE# Note: The classes you want to be reloaded upon modification should be put# here.repositories=/private/scott-sun/migration-example/classes

JServ における起動用における起動用における起動用における起動用 URL

前述の設定を想定する場合、次の URL を使用して（適切なポートを指定して）、様々なページを直接起動できます。

サーブレットを起動するには :

http://scott-sun:port/servlet/HelloWorldServlethttp://scott-sun:port/servlet/SessionServlet

JSP ページを起動するには :

http://scott-sun:port/migdemos/jsps/Hello.jsphttp://scott-sun:port/migdemos/jsps/snoop.jsp

index の HTML ページを起動するには :

http://scott-sun:port/migdemos/index.htmlhttp://scott-sun:port/migdemos/examples/index.html

OC4J における設定における設定における設定における設定

この項では、移行するための OC4J の設定について説明します。次の構造があるとします。

/private/scott-sun/migration-example/ migration-example.ear

META-INF/ application.xml

migration-example.war index.html WEB-INF/ web.xml orion-web.xml

classes/



HelloWorldServlet.java SessionServlet.java

jsps/ Hello.jsp snoop.jsp

examples/ index.html

images/ blk_line_bullet_35.gif red_arrow_bullet_35.gif

もちろん初期の段階では、EAR ファイル（migration-example.ear）および WAR ファイル（migration-example.war）は存在しません。両ファイル以外のディレクトリ構造が完成した後に、JAR ユーティリティを使用してそれらのファイルを作成します。 EAR ファイルと WAR ファイルは、わかりやすいように、コンテンツがネストした状態でディレクトリ構造に表示されます。

WAR ファイルの構造は次のようになります。

META-INF/META-INF/MANIFEST.MFWEB-INF/WEB-INF/classes/WEB-INF/classes/HelloWorldServlet.javaWEB-INF/classes/SessionServlet.javaWEB-INF/web.xmlWEB-INF/orion-web.xmljsps/jsps/Hello.jspjsps/snoop.jspexamples/examples/index.htmlexamples/images/examples/images/blk_line_bullet_35.gifexamples/images/red_arrow_bullet_35.gifindex.html

EAR ファイルの構造は次のようになります。

META-INF/META-INF/MANIFEST.MFMETA-INF/application.xmlmigration-example.war



OC4J のデプロイ規則に従って、EAR ファイルを配布します。詳細は、『Oracle9iAS Containers for J2EE ユーザーズ・ガイド』および『Oracle9iAS Containers for J2EE Servlet 開発者ガイド』を参照してください。

次は、OC4J の移行とデプロイメントに関する一般的な提案です。

� OC4J でのサーブレットの再コンパイルは必要ありません。しかし、現在は推奨されていない Servlet 2.0 メソッドを使用している場合は、そのメソッドを特定しておくと便利です。推奨されていないメソッドを使用する場合も、サーブレットを OC4J で実行できます。

� Servlet2.0 環境では、個別のサーブレット・コンテキストはありません。すべてのサーブレットが 1 つにグループ化されています。 Servlet 2.2 または 2.3 環境では、WAR ファイルごとに特定のサーブレット・コンテキストへ配布します。 JServ 環境では一緒に効率良く実行できるサーブレットが、OC4J では異なるコンテキストにある場合、OC4J 環境ではサーブレット間の相互依存性により実行時に問題が発生します。

� アプリケーション固有のライブラリ・ファイルやユーティリティの JAR ファイルは、WEB-INF/libディレクトリに置きます。

� システム全体のライブラリ・ファイルやユーティリティの JAR ファイルは、すべてのアプリケーションからアクセス可能な j2ee/home/libディレクトリに置きます。

クラス・ファイルや JAR ファイルの場所などのシステム全体のパス設定は、グローバルなapplication.xmlファイルで指定します。

j2ee/home/config/application.xml

たとえば、j2ee/home/libをシステム全体のライブラリ・ファイルの場所として指定します。

application.xml の設定の設定の設定の設定

この例で使用する application.xmlファイルには次のエントリが含まれます。

<?xml version="1.0"?><!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd"><application> <display-name>OC4J demo application</display-name> <description> Collection of servlet samples. </description> <module> <web> <web-uri>migration-example.war</web-uri> <context-root>/migdemos</context-root> </web> </module></application>


orion-web.xml の設定の設定の設定の設定

この例で使用する orion-web.xmlファイルには次のエントリが含まれます。

<?xml version="1.0"?><!DOCTYPE orion-web-app PUBLIC "-//Evermind//DTD Orion Web Application 2.3//EN""http://xmlns.oracle.com/ias/dtds/orion-web.dtd">

<orion-web-app deployment-version="9iAS 9.0.2" servlet-webdir="/servlet"></orion-web-app>

web.xml の設定の設定の設定の設定

この例で使用する web.xmlファイルには次のエントリが含まれます。

<?xml version="1.0"?><!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

<web-app>  <servlet> <servlet-name>HelloServlet</servlet-name> <servlet-class>HelloWorldServlet</servlet-class> </servlet> <welcome-file-list> <welcome-file>index.html</welcome-file> </welcome-file-list></web-app>

注意注意注意注意 :

� <context-root>の設定が、アプリケーション全体のルートです。

� アプリケーションごとに、アプリケーション固有の設定を含むapplication.xmlがあります。前述のサーバー全体の設定を含むグローバルな application.xmlファイルと、それぞれのアプリケーションの application.xmlファイルを混同しないようにしてください。


OC4J における起動用における起動用における起動用における起動用 URL

前述の設定を想定する場合、次の URL を使用して（適切なポートを指定して）、様々なページを直接起動できます。

サーブレットを起動するには :

http://scott-sun:port/migdemos/servlet/HelloWorldServlethttp://scott-sun:port/migdemos/servlet/SessionServlet

（application.xmlの <context-root>の設定と orion-web.xmlのservlet-webdirの設定が、ここでは関係します。）

JSP ページを起動するには :

http://scott-sun:port/migdemos/jsps/Hello.jsphttp://scott-sun:port/migdemos/jsps/snoop.jsp

index の HTML ページを起動するには :

http://scott-sun:port/migdemos/index.htmlhttp://scott-sun:port/migdemos/examples/index.html

principals.xml ファイルのファイルのファイルのファイルの Java 認証および認可サービスへの移行認証および認可サービスへの移行認証および認可サービスへの移行認証および認可サービスへの移行Oracle9iAS リリース 1（1.0.2.2.x）の OC4J のセキュリティ・サービスでは、prinicpals.xmlファイルで、ユーザーおよびグループを定義し、定義したユーザーやグループをアプリケーションのデプロイメント・ディスクリプタで定義されるロールへマップします。

Oracle9iAS リリース 2（9.0.2）では、セキュリティ・サービスは、Java 認証および認可サービス（JAAS）を介して提供されます。 JAAS の詳細は『Oracle9iAS セキュリティ・ガイド』の「 JAAS のセキュリティ」を参照してください。

JAZN Admintool を使用すると、セキュリティ管理者がユーザー、領域、ロールおよびポリシーを管理できます。このツールには、principals.xmlを JAAS 領域へ移行するコマンド・スイッチがあります。構文は次のとおりです。

java -jar jazn.jar -convert filename realm

filenameは、OC4J の principals.xmlファイルの場所で、realmは JAAS で定義された領域です。たとえば、次のようになります。

java -jar jazn.jar -convert /home/config/principals.xml MyCompanyRealm

principals.xmlグループに与えられたすべての許可は、JAAS ロールに与えられます。非アクティブに設定されているユーザーは移行されません。


Oracle9iAS SOAP の移行

Oracle9iAS SOAP の移行の移行の移行の移行この項では、SOAP アプリケーションを Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iASリリース 2（9.0.2）へ移行する方法を説明します。

SOAP はサーブレットとして実装されます。サーブレットは、サービス起動をユーザーが提供する実装クラスに委任します。 Oracle9iAS リリース 1（1.0.2.2.x）では、JServ がデフォルトのサーブレット・エンジンでした。 Oracle9iAS リリース 2（9.0.2）では、OC4J がサーブレット・エンジンです。 SOAP アプリケーションを移行するには、サービス実装クラスとディスクリプタをコピーおよび再パッケージングし、同時に、JServ コンテナと OC4J コンテナの設定についても考慮する必要があります。（JServ および OC4J の設定の詳細は、3-20ページの「JServ から OC4J への移行」を参照してください。）

Oracle9iAS リリース 2（9.0.2）には、空の（サービスを含まない）SOAP アプリケーションとWebアプリケーション・アーカイブがすぐにインストールできる状態で準備されています。ファイル名は、soap.earおよび soap.warで、$ORACLE_HOME/soap/lib/soap.earにあります。 soap.warファイルは、soap.earファイルに含まれる WAR ファイルのコピーです。

SOAP の移行には、Oracle9iAS リリース 1（1.0.2.2.x）のファイルを空の SOAP アプリケーションのコピーへ挿入し、OC4J でそのアプリケーションをデプロイする手順が含まれます。ファイルは次の 2 つの方法のどちらかで、必ず " 挿入 " してください。

� jar -xを使用して soap.earファイルおよび soap.warファイルを解凍し、コンポーネント・ディレクトリへ置きます。古いファイルを対応するディレクトリへコピーし、jar -cを使用して新しい .ear ファイルおよび .war ファイルを作成します。

� jar -uを使用して、.war ファイルおよび .ear ファイルを解凍せずに、両ファイルの内容を更新します。

移行プロセスは次のとおりです。

1. $ORACLE_HOME_2/soap/lib/soap.earおよび $ORACLE_HOME_2/soap/webapps/soap.warを作業しやすいディレクトリ（例で使用しているworkdir など）へコピーします。

2. soapサービス用にユーザーが独自に作成したすべてのクラス・ファイルをworkdir/soap.warへ挿入します。

3. soap.jarおよび samples.jar以外のすべての jar ファイルを、$ORACLE_HOME_1/soap/webapps/soap/WEB-INF/libから workdir/soap.warへ挿入します。

4. 古い構成ファイルの $ORACLE_HOME_1/soap/webapps/soap/WEB-INF/config/soapConfig.xmlが一度も変更されていないことが確かな場合は、手順 6 へ進んでください。

5. 古い構成ファイルである $ORACLE_HOME_1/soap/webapps/soap/WEB-INF/config/soapConfig.xmlのコピーを作成し、作成したコピーの名前を soap.xmlに変更します。


Oracle Business Components for Java の移行

6. providerManager要素および serviceManager要素のクラス属性を確認しながら、ファイルを編集します。

移行すべきすべてのコードは、workdir/soap.jarにあります。

7. 新しい workdir/soap.jarを workdir/soap.earに挿入します。

8. .ear ファイルを OC4J に配布します。

9. インストールされている SOAP サービスを、『Oracle9iASWeb Services 開発者ガイド』の説明に従ってアクティブ化します。

Oracle Business Components for Java の移行の移行の移行の移行次の手順に従って、Oracle Business Components for Java アプリケーションを、JServ を使用する Oracle9iAS リリース 2（9.0.2）へ移行します。 JServ は、従来の使用をサポートするためにのみ、Oracle9iAS リリース 2（9.0.2）で提供されています。デフォルトでは無効に設定されています。デフォルトのサーブレット・コンテナは、OC4J です。

ビジネス・コンポーネント・アプリケーションが OC4J を使用するようにしたい場合は、Oracle9i JDeveloper から再デプロイする必要があります。Oracle9i JDeveloper でのデプロイの詳細は、JDeveloper 関連ドキュメントを参照してください。

注意注意注意注意 : providerManager および serviceManager のインタフェースはリリース 1 から変更になりました。したがって、クラスを提供している場合は、コードを修正して再コンパイルし、workdir/soap.warに挿入する必要があります。 soap.war の場所は、WEB-INFの直下で、WEB-INF/configではありません。それらの変更については、SOAP javadoc で詳しく述べています。

クラスを提供していない場合は、soap.xmlファイルの class =行からクラス属性を削除してください。 workdir/soap.warにある soap.xmlファイルを、新しい soap.xmlで置き換えてください。

注意注意注意注意 : 次の手順は、対象のビジネス・コンポーネントがローカル・モードでデプロイされていることを前提としています。対象のビジネス・コンポーネントが、EJB または CORBA サーバー・オブジェクトとして、Oracle JVM にデプロイされている場合は、OC4J EJB モジュールなどの別のプラットフォームへ Oracle9i JDeveloper から再デプロイする必要があります。 Oracle9i JDeveloper でのデプロイと、JDeveloper 3.2.3 プロジェクトの Oracle9i JDeveloper への移行の詳細は、JDeveloper 関連ドキュメントを参照してください。



BC4J アプリケーションの移行アプリケーションの移行アプリケーションの移行アプリケーションの移行BC4J アプリケーションは次の手順で移行します。 Oracle9iAS リリース 2（9.0.2）におけるJServ の設定についても説明します。

1. JSP ファイルおよびビジネス・コンポーネントの JAR ファイルを ORACLE_HOME_2にコピーします。

2. それぞれの JAR ファイル（ビジネス・コンポーネント、Web Bean、またはその他の作成済みアーカイブ、あるいはそのすべて）に、wrapper.classpath=pathという行を追加します。pathは JAR ファイルへのパスです。

3. $ORACLE_HOME_2/Apache/Apache/conf/httpd.confにある jserv.confファイルに対する Include ディレクティブをアンコメントします。

#include "/ORACLE_HOME_2/Apache/Jserv/etc/jserv.conf"

4. jserv.confを編集し、JServ の使用方法に合うようにディレクティブを設定します。（jserv.confには、プロセス管理とロード・バランシング・サービスを提供する

Oracle のモジュールである、mod_jserv および mod_oprocmgr を設定する Include ディレクティブが含まれます。）

5. 必要に応じて、$ORACLE_HOME_2/Apache/Jserv/etc/jserv.propertiesファイルを編集します。

6. 必要に応じて、$ORACLE_HOME_2/Apache/Jserv/etc/zone.propertiesファイルを編集します。

7. （オプション）次の手順を実行すると、JServ と Oracle9iAS Containers for J2EE（OC4J）が共存できるように設定できます。ポータルは OC4J に依存するので、この設定は、

「Portal および Wireless」インストール・タイプを使用している場合に重要になります。

あるアプリケーションが JServ 上で実行され、別のアプリケーションが OC4J 上で実行されるように設定できます。次の URL があるとします。

/application1/file1.jspは、JServ 上で実行するための URL です。

/application2/file2.jspは、OC4J 上で実行するための URL です。

application1 の URL を書き換える必要があります。

a. $ORACLE_HOME_2/Apache/Apache/conf/httpd.confを編集し、次のディレクティブがアクティブで（アンコメントされていて）、存在することを確認します。

LoadModule rewrite_module libexec/mod_rewrite.soRewriteEngine on

関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server Oracle HTTP Server 管理ガイド』



b. $ORACLE_HOME_2/Apache/jsp/conf/ojsp.confを編集して、次のディレクティブを追加します。

RewriteRule /application1/(.*)/(.*)\.jsp$ /application1/$1/$2.jsp1ApJServAction .jsp1 /servlets/oracle.jsp.JspServlet

c. 次のディレクティブを削除します。

ApJServAction .jsp /servlets/oracle.jsp.JspServlet

d. $ORACLE_HOME_2/Apache/Jserv/etc/jserv.confを編集し、/servletsを、JSP リクエストを処理する JVM へマウントします。 ApJServMount ディレクティブまたは ApJServGroupMount ディレクティブを使用します（JServ プロセスの起動方法によって、どちらを使用するか決まります）。

8. Oracle HTTP Server を再起動します。


Portal コンポーネントの

4
Portal コンポーネントの移行コンポーネントの移行コンポーネントの移行コンポーネントの移行
この章では、Portal コンポーネントの移行に必要な構成ファイルおよびアプリケーション配布ファイルの変更方法について説明します。この章の主な項は次のとおりです。

� Oracle9iAS Portal の移行

� Oracle Ultra Search の移行

移行 4-1

Oracle9iAS Portal の移行

Oracle9iAS Portal の移行の移行の移行の移行この項では、Oracle9iAS Portal を移行する方法について説明します。この項は、次の項目で構成されています。

� 中間層の移行

� Portal Developer Kit（PDK）for Java の Web プロバイダの移行

� Portal の移行に関するトラブルシューティングとヒント

中間層の移行中間層の移行中間層の移行中間層の移行この項では、Oracle Portal リリース 3.0.9 から Oracle9iAS Portal リリース 9.0.2 に Portal コンポーネント中間層を移行する手順を説明します。この項の項目は次のとおりです。

� Oracle9iAS Portal リリース 9.0.2 のアーキテクチャの変更（4-2 ページ）

� Parallel Page Engine の移行（4-3 ページ）

� データベース・アクセス記述子（DAD）の移行（4-11 ページ）

� Portal Developer Kit（PDK）for Java の Web プロバイダの移行（4-14 ページ）

� 中間層のキャッシュ構成の移行（4-12 ページ）

� SSL 設定の移行（4-37 ページ）

� Portal の移行に関するトラブルシューティングとヒント（4-39 ページ）

Oracle9iAS Portal リリースリリースリリースリリース 9.0.2 のアーキテクチャの変更のアーキテクチャの変更のアーキテクチャの変更のアーキテクチャの変更Oracle9iAS Portal リリース 9.0.2 は、Oracle9iAS リリース 2（9.0.2）が基盤となっているため、従来のサーブレット・コンテナである JServ ではなく、J2EE 準拠の新しいサーブレット・コンテナである OC4J で構成されています。中間層を従来のアーキテクチャから新しいアーキテクチャに移行するには、手動で操作する必要があります。

JServ ゾーンからゾーンからゾーンからゾーンから OC4J アプリケーションへの移行アプリケーションへの移行アプリケーションへの移行アプリケーションへの移行

1. /servlet/page/*というパターンのリクエストが OC4J の Portal インスタンスに送られるように、mod_oc4jを設定します。

a. $ORACLE_HOME_2/Apache/Apache/conf/mod_oc4j.confを編集して、次の行を追加します。

OC4JMount /servlet/page OC4J_Portal

注意注意注意注意 : このファイルにある他の OC4JMount ディレクティブの隣に、このディレクティブを追加してください。追加する行は、<IfModule mod_oc4j.c> ブロック内に含めてください。



b. JServ によって /servletマウント・ポイントが使用されないように設定するため、$ORACLE_HOME_2/Apache/Jserv/etc/jserv.confを編集して、ApJServMount ディレクティブを変更します。デフォルトのサーブレット・ゾーンでは、/servletマウント・ポイントが使用されます。

次のディレクティブを変更します。

ApJServMount /servlet /root

このディレクティブを変更して、別の JServ のマウント・ポイントを指定します。たとえば、次のようにします。

ApJServMount /anotherMountPoint /root

2. すべての /servlet/pageリクエストの実行に Portal アプリケーションを使用するように、OC4J を設定します。

a. $ORACLE_HOME_2/j2ee/OC4J_Portal/config/default-web-site.xmlを編集して、次の行を追加します。

<web-app application="portal" name="portal" root="/" />

Parallel Page Engine の移行の移行の移行の移行Oracle9iAS Portal リリース 9.0.2 に同梱される Parallel Page Engine（PPE）には下位互換性があり、Oracle Portal リリース 3.0.9（Oracle9iAS リリース 1（1.0.2.2.x））とともに使用できます。Oracle9iAS Portal リリース 9.0.2 に必要な新しい設定は、すべて自動的に実行されます。手動で設定する必要があるのは、カスタム設定を新しい環境に移行する場合です。表 4-1に、PPE で変更できる Oracle Portal リリース 3.0.9 のパラメータを一覧表示します。

注意注意注意注意 : このファイルにある他の <web-app application> ディレクティブの次に、このディレクティブを追加してください。追加する行は<web-site> ブロック内に含めてください。

Portal コンポーネントの移行 4-3


表表表表 4-1 Parallel Page Engine のパラメータのパラメータのパラメータのパラメータ

パラメータパラメータパラメータパラメータ説明説明説明説明

cacheBuffer キャッシュされたページを取得する際に使用されるメモリー・バッファの合計サイズです。システムが取得するページの合計サ

イズとほぼ一致する値を設定する必要があります。このバッファ

が使用されるのは、ファイルがディスクから読み込まれ、ブラウザに書き込まれるときです。小さい値を設定すると、複数のディ

スク読込みが発生してパフォーマンスが低下します。大きい値を

設定すると、ディスク読込みは減少しますが消費されるリソースが増加します。デフォルトは 32768 です。

httpsports SSL/HTTPS を実行しているポートの一覧です。ポート番号はコロ

ン（:）で区切られ、下のように表記されます。

9999:8888:7777

Portal が SSL/HTTPS モードで実行されている場合、Portal を実

行しているポートがここで指定されている必要があります。デフォルトは NULL です。

logmode デバッグを行うために設定します。このパラメータに値が設定さ

れていると、PPE がデバッグ・モードで実行されます。このパラ

メータに値が設定されていないと、PPE が通常のモードで実行さ

れ、低限の警告とエラーだけが必要時に書き込まれます。

logpath PPE のログの書込み先となる絶対パスです。既存のパスを指定し

てもかまいません。デフォルトでは、JServ のデフォルトのログ・

パスが指定されています。

minTimeout アウトバウンドの HTTP リクエストが実行されるまでのポート

レット待機時間（秒単位）です。ポートレットから提供された値

がこの値より小さい場合でも、この値まで増加されます。このパ

ラメータが initArgs で指定されていない場合は、デフォルトで 5秒に設定されます。

offlinePath 何らかの理由で Portal をオフラインにする必要がある場合、この

パラメータを設定しておくと、Portal がオフラインであることを

クライアントに通知するためにあらかじめ指定されていたファイルがサーブレットから返されます。このパラメータに値が設定さ

れているときは、PPE をオフライン・モードで実行できます。デフォルトは NULL です。

poolSize パラレル処理で使用されるスレッドの合計数です。値が大きいほ

ど、処理されるリクエストの数が増えますが、消費されるリソースも増えます。値が小さいほど、処理されるリクエストの数が少

なくなり、消費されるリソースも少なくてすみます。デフォルト

は 25 です。



上記のパラメータを移行するには、パラメータ名と値を $ORACLE_HOME_2/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xmlファイルにコピーします。

次に、リリース 3.0.9 およびリリース 9.0.2 でのパラメータの名前および値の位置と形式について例を示します。

prefix modplsql をポイントするときに使用されるプリフィックスです。デフォルトは /plsです。

proxyHost 必要な場合にプロキシ・リクエストを処理するホストです。デフォルトは NULL です。

proxyIgnore プロキシ・サーバーの使用時に無視されるドメインの一覧です。ドメイン名は HTTP 1.1 規格に準拠し、先頭が "."、末尾が文字で

なければなりません。デフォルトは NULL です。

proxyPort 必要な場合にプロキシ・リクエストの処理で使用されるポートです。デフォルトは NULL です。

queueTimeout リクエストがタイムアウトのためキューから除外されるまでの、リクエストの待機時間（秒単位）です。 initArgs で指定されていな

い場合は、デフォルトの 10 秒が設定されます。

requesttime タイムアウトになる前のリクエストの実行時間（秒単位）です。メタデータでタイムアウト・パラメータが指定されていない場合に限り有効です。このパラメータの値は、minTimeout とmaxTimeout で指定されている値の範囲内になります。 initArgs で値が指定されていない場合は、デフォルトの 15 秒が設定されま

す。

showError タイムアウトやポートレットの欠陥などの PPE エラーをユーザー

に表示するかどうかを指定します。 true に設定するとエラー・

メッセージが表示され、false に設定すると表示されません。デフォルトは true です。

stall アウトバウンドの HTTP リクエストに対して、接続を開いた状態

で維持する時間（秒単位）です。ポートレットから提供されたタ

イムアウト値がこの値より小さい場合は、この値まで縮小されます。この値が initArgs で指定されていない場合、デフォルトの 65秒が設定されます。

表表表表 4-1 Parallel Page Engine のパラメータ（続き）のパラメータ（続き）のパラメータ（続き）のパラメータ（続き）

パラメータパラメータパラメータパラメータ説明説明説明説明



例例例例 4-1 リリースリリースリリースリリース 3.0.9 形式の形式の形式の形式の initArgs パラメータパラメータパラメータパラメータ

リリース 3.0.9 のパラメータ構文は次のとおりです。

servlet.name.initArgs=NAME=VALUE

httpsportsパラメータを 443 に設定する場合は、次のようになります。

servlet.page.initArgs=httpsports=443

例例例例 4-2 リリースリリースリリースリリース 9.0.2 形式の形式の形式の形式の initArgs パラメータパラメータパラメータパラメータ

バージョン 9.0.2 のパラメータ形式の構文は次のとおりです。

<servlet> <servlet-name>xxxx</servlet-name> <servlet-class>aaa.bbb</servlet-class> <init-param> <param-name>NAME</param-name> <param-value>VALUE</param-value> </init-param> </servlet>

httpsportsパラメータを 443 に設定する場合は、次のようになります。

<servlet> <servlet-name>page</servlet-name> <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> <init-param> <param-name>httpsports</param-name> <param-value>443</param-value> </init-param> </servlet>



リリースリリースリリースリリース 2 でのでのでのでの mod_plsql パラメータの変更パラメータの変更パラメータの変更パラメータの変更リリース 2 の mod_plsql DAD では、アプリケーションを構成する場合に、Oracle HTTP Server Location ディレクティブを使用します。このパラメータの構文では、パラメータ名と値を等号（=）ではなく空白で区切ります。表 4-2 に、リリース 1 で使用されていたパラメータと、それに対応するリリース 2 のパラメータを一覧表示します。また、一部のパラメータについては、指定する値も比較して示します。

関連項目関連項目関連項目関連項目 : DAD パラメータについては、『Oracle9i Application Server Oracle HTTP Server 管理ガイド』で詳しく説明しています。

表表表表 4-2 DAD パラメータパラメータパラメータパラメータ

リリースリリースリリースリリース 1 ののののパラメータパラメータパラメータパラメータリリースリリースリリースリリース 2 のパラメータのパラメータのパラメータのパラメータリリースリリースリリースリリース 1 での値での値での値での値リリースリリースリリースリリース 2 での値での値での値での値

debugModules PlsqlLogEnable all、debug、info notice、warn、alert crit

Off, On（Off と On 以外の状態につい

ては、httpd.confの LogLevel で設

定します。）

username PlsqlDatabaseUserName

password PlsqlDatabasePassword

connect_string PlsqlDatabaseConnectString

default_page PlsqlDefaultPage

document_table PlsqlDocumentTablename

document_path PlsqlDocumentPath

document_proc PlsqlDocumentProcedure

upload_as_long_raw PlsqlUploadAsLongRaw

always_describe PlsqlAlwaysDescribeProcedure

before_proc PlsqlBeforeProcedure

after_proc PlsqlAfterProcedure

reuse PlsqlMaxRequestsPerSession Yes、No 1000（デフォルト）、1

pathalias PlsqlPathAlias

pathaliasproc PlsqlPathAliasProcedure

enablesso PlsqlAuthenticationMode Yes SingleSignOn



custom_auth PlsqlAuthenticationMode Not Set

Custom

Global

PerPackage

Basic

GlobalOwa

CustomOwa

PerPackageOwa

sncookiename PlsqlSessionCookieName

stateful PlsqlSessionStateManagement STATELESS_RESET（デフォル

ト）

STATELESS_FAST_RESET

STATELESS_PRESERVE

StatelessWithResetPackageState

StatelessWithFastResetPackageState

StatelessWithPreservePackageState

response_array_size PlsqlFetchBufferSize

exclusion_list PlsqlExclusionList 1 行に 1 つ

cgi_env_list PlsqlCGIEnvironmentList 1 行に 1 つ

nls_lang PlsqlNLSLanguage

error_style PlsqlErrorStyle WebServer

Gateway

GatewayDebug

ApacheStyle

ModplsqlStyle

DebugStyle

bind_bucket_widths PlsqlBindBucketWidths 1 行に 1 つ

bind_bucket_lengths PlsqlBindBucketLengths 1 行に 1 つ

表表表表 4-2 DAD パラメータ（続き）パラメータ（続き）パラメータ（続き）パラメータ（続き）

リリースリリースリリースリリース 1 ののののパラメータパラメータパラメータパラメータリリースリリースリリースリリース 2 のパラメータのパラメータのパラメータのパラメータリリースリリースリリースリリース 1 での値での値での値での値リリースリリースリリースリリース 2 での値での値での値での値



DAD パラメータの使用方法パラメータの使用方法パラメータの使用方法パラメータの使用方法

この項では、リリース 2 でのパラメータの使用方法を詳細に説明します。

� 以前のリリースで設定しなかったパラメータを、リリース 2（9.0.2）で設定しないでください。指定しなかったパラメータは、mod_plsql によって自動的にシステム内部のデフォルト値に設定されます。

mod_plsql には管理ページがないので、次のパラメータの使用を推奨しません。

� administrators

� adminPath

� admindad

� 次のパラメータのグローバル・レベルでの使用は推奨しません。各 DAD で、明示的に指定してください。

� upload_as_long_raw

� upload_as_blob

� enablesso

� stateful

� custom_auth

� error_style

� name_prefix

� upload_as_blob

� リリース 2 では、defaultDadパラメータを使用しません。Oracle HTTP Server を使用してルールを書き換えても同じ結果が得られるからです。

� Portal を使用して、ファイル名に空白文字を含むファイルをダウンロードする場合は、DAD 構成パラメータの PlsqlCompatibilityModeを 1 に設定する必要があります。このようにフラグを設定しておくと、ダウンロードするファイルにプラス記号（+）が付くのを防げます。



移行された移行された移行された移行された DAD の例の例の例の例

リリース 1 の構成ファイルである、$ORACLE_HOME_1/Apache/modplsql/cfg/wdbsvr.appの DAD の例を次に示します。

; [DAD_portal30] username = portal30 password = portal30 connect_string = pk.us.oracle.com default_page = portal30.home document_table = portal30.wwdoc_document document_path = docs document_proc = portal30.wwdoc_process.process_download upload_as_long_raw = txt, gif upload_as_blob = * ;name_prefix = always_describe = No ;before_proc = ;after_proc = reuse = Yes pathalias = url pathaliasproc = portal30.wwpth_api_alias.process_download enablesso = Yes ;sncookiename = ;stateful = ;custom_auth = ;response_array_size = ;exclusion_list = ;cgi_env_list = ;error_style = ;nls_lang = ;

移行処理により、この DAD が Location ディレクティブの次の引数に変換されます。

<Location /pls/portal30> SetHandler pls_handler Order allow, deny Allow from All AllowOverride None PlsqlDatabaseUsername portal30 PlsqlDatabasePassword portal30 PlsqlDatabaseConnectString pk.us.oracle.com PlsqlDefaultPage portal30.home PlsqlDocumentTable portal30.wwdoc_document PlsqlDocumentPath docs PlsqlDocumentProc portal30.wwdoc_process.process_download



PlsqlUploadAsLongRaw txt PlsqlUploadAsLongRaw gif PlsqlMaxRequestsPerSession 1000 PlsqlAuthenticationMode SingleSignOn PlsqlPathAlias url PlsqlPathAliasProcedure portal30.wwpth_alias.process_download </Location>

データベース・アクセス記述子（データベース・アクセス記述子（データベース・アクセス記述子（データベース・アクセス記述子（DAD）の移行）の移行）の移行）の移行

リリース 1 からリリース 2 への変更に伴って、Portal と Login Server の DAD が大幅に変更されました。また、DAD を移行するための移行ツールが用意されています。この項では、移行ツールを使用して DAD を移行する方法と、mod_plsql パラメータ間の相違点について説明します。

dadMigration スクリプトの実行

この項では、Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iAS リリース 2（9.0.2）に、データベース・アクセス記述子（DAD）を移行する方法を説明します。 Oracle9iAS リリース1（1.0.2.2.x）の DAD 構成ファイルである wdbsvr.appの情報を、Oracle9iAS リリース 2

（9.0.2）の構成ファイルである dads.confに移行する必要があります。移行後、Web DAVエントリが oradav.confに作成されます。

移行は、dadMigration スクリプトを実行し、Portal Configuration Interface（PCI）を使用して行います。スクリプト・ファイルのフルパスと名前は次のとおりです。

$ORACLE_HOME_2/bin/dadMigration.csh（UNIX）

%ORACLE_HOME_2%¥bin/dadMigration.cmd（Windows）

移行スクリプトを実行すると、以前のリリースの DAD が読み込まれ、新しい DAD および対応するWeb DAV エントリが作成されます。移行スクリプトの実行には targetOracleHome (-t) と migrationSource (-s) の 2 つのパラメータが必要です。移行スクリプトを実行するには、次の手順に従います。

1. UNIX の場合 :

dadMigration.csh -t ORACLE_HOME_2 -s $ORACLE_HOME_1/Apache/modplsql/cfg/wdbsvr.app

Windows の場合 :

dadMigration.cmd -t ORACLE_HOME_2 -s $ORACLE_HOME_1/Apache/modplsql/cfg/wdbsvr.app

ORACLE_HOME_2では、移行先の Oracle ホームを指定します（デフォルトはORACLE_HOME 環境変数の値です）。

ORACLE_HOME_1では、移行するリリース .3.0.9 DAD 形式ファイルの場所を指定します（デフォルトは wdbsvr.appです）。

2. EMD を再起動して変更を反映します。



3. DAD が移行されたことを確認します。確認するには、管理および監視用のユーザー・インタフェースを使用して、mod_plsql サービス・ページの場所まで移動し、そのページの DAD 状態セクションを調べます。 DAD が正常に移行されていたら、そこに表示されます。

中間層のキャッシュ構成の移行中間層のキャッシュ構成の移行中間層のキャッシュ構成の移行中間層のキャッシュ構成の移行キャッシュ構成の移行は手動で行い、Oracle9iAS リリース 1（1.0.2.2.x）の Oracle ホームで設定された値に基づいてパラメータを変更する必要があります。

注意注意注意注意 : EMD を再起動する前に別の移行や Portal の設定を行うと、移行に伴う変更が失われる場合があります。

警告警告警告警告 : リリース 1 とリリース 2 で中間層のホスト名とポートが同一でない場合は、ssodatanスクリプトを使用して Portal を再登録してください。詳細は、『Oracle9iAS Portal 構成ガイド』を参照してください。

表表表表 4-3 中間層キャッシュ・パラメータ中間層キャッシュ・パラメータ中間層キャッシュ・パラメータ中間層キャッシュ・パラメータ

リリースリリースリリースリリース 1 のパラメータのパラメータのパラメータのパラメータリリースリリースリリースリリース 2 のパラメータのパラメータのパラメータのパラメータリリースリリースリリースリリース 1 での値での値での値での値リリースリリースリリースリリース 2 での値での値での値での値

enabled PlsqlCacheEnable Yes、No On、Off

cache_dir PlsqlCacheDirectory キャッシュのディレクトリキャッシュのディレクトリ

total_size PlsqlCacheTotalSize

cleanup_size PlsqlCacheCleanupSize

cleanup_interval PlsqlCacheCleanupInterval ユーザーが指定する値（秒単位）

ユーザーが指定する値（分単位）

注意注意注意注意 : リリース 1 のセッション・キャッシュ設定と PL/SQL のキャッシュ設定は、1 つのキャッシュ設定にまとめられました。次の例を参照してください。



例例例例 4-3 Oracle9iAS リリースリリースリリースリリース 1 のキャッシュ構成ファイルのキャッシュ構成ファイルのキャッシュ構成ファイルのキャッシュ構成ファイル

$ORACLE_HOME_1/Apache/modplsql/cfg/cache.cfgファイルの内容は次のとおりです。

[PLSQL CACHE] enabled = yes cache_dir = /u01/app/oracleproduct/IAS1022/Apache/modplsql/cache/plsql total_size = 25600000 cleanup_size = 10240000 cleanup_interval = 43200 max_size = 1024000 ; [Cookie Cache] enabled = yes cache_dir = /u01/app/oracleproduct/IAS1022/Apache/modplsql/cache/session total_size = 25600000 cleanup_size = 10240000 cleanup_interval = 43200 max_size = 1024000

例例例例 4-4 Oracle9iAS リリースリリースリリースリリース 2 のキャッシュ構成ファイルのキャッシュ構成ファイルのキャッシュ構成ファイルのキャッシュ構成ファイル

リリース 1 のファイルは、次の $ORACLE_HOME_2/Apache/modplsql/conf/cache.confに変換されます。

PlsqlCacheEnable On PlsqlCacheDirectory /u01/app/oracle/product/IAS1022/Apache/modplsql/cache PlsqlCacheTotalSize 25600000 PlsqlCacheCleanupSize 10240000 PlsqlCacheCleanupInterval 720 PlsqlCacheMaxSize 1024000



Portal Developer Kit（（（（PDK））））for Java のののの Web プロバイダの移行プロバイダの移行プロバイダの移行プロバイダの移行この項では、PDK for Java リリース 3.0.9 のプロバイダを PDK for Java リリース 9.0.x にアップグレードする方法について説明します。リリース番号が大きいほど、Oracle9iAS リリース2（9.0.2）と同期がとれていることを示します。PDK for Java は、Oracle9iAS リリース 2

（9.0.2）のコンポーネントの 1 つです。この項の項目は次のとおりです。

PDK for Java Framework とサンプルのインストール

移行オプション

PDK for Java 3.0.9.x から PDK for Java 9.0.x（v1）への移行

PDK for Java 3.0.9.x から PDK for Java 9.0.x（v2）への移行

プロバイダのパッケージングおよびデプロイ

PDK for Java Framework とサンプルのインストールとサンプルのインストールとサンプルのインストールとサンプルのインストールPDK for Java Framework は、Oracle9iAS の $ORACLE_HOME/portal/pdkjava/v2/にあります。PDK for Java Framework には、Web ポートレットを作成するために必要なツールとドキュメントが用意されています。初の段階では、PDK for Java Framework と Web プロバイダのサンプルを使用すると便利です。 PDK for Java Framework にはプロバイダ用のフレームワークが用意されており、このフレームワークをもとにポートレットを作成します。

この項では、PDK for Java Framework とサンプルのインストールおよび設定について説明します。また、PDK for Java Framework、各種サンプルおよび作成したポートレットを実行できるように Oracle HTTP Server を設定する方法についても説明します。

PDK for Java Framework には、次のアプリケーション・ファイルが含まれています。

� jpdk.ear: サンプルのプロバイダ・アプリケーション（Java ライブラリ、JSP ファイル、HTML ファイルなど）およびサンプル・アプリケーションを実行するために必要なリソースが入っています。

� template.ear: プロバイダのデプロイを容易にするためのテンプレート EAR ファイルです。

PDK for Java Framework の設定要件の設定要件の設定要件の設定要件

フレームワークとサンプルを実行するには、Oracle9iAS Containers for J2EE（OC4J）を含むOracle9iAS をインストールし、設定しておく必要があります。



サンプル・プロバイダのデプロイサンプル・プロバイダのデプロイサンプル・プロバイダのデプロイサンプル・プロバイダのデプロイ

サンプル・プロバイダをデプロイするには、次の手順に従います。

1. jpdk.earを OC4J アプリケーション用のサブディレクトリ（通常は、$ORACLE_HOME_2/j2ee/OC4J_Portal/applications）にコピーします。

2. $ORACLE_HOME_2/j2ee/OC4J_Portal/config/server.xmlファイルに次の行を追加します。

<application name="jpdk" path="../applications/jpdk.ear" />

3. $ORACLE_HOME_2/j2ee/OC4J_Portal/config/default-web-site.xmlファイルに次の行を追加して、デフォルトのサイトにアプリケーションをバインドします。

<web-app application="jpdk" name="jpdk" path="/jpdk/" />

4. OC4J を起動します。またはリスナーを再起動します。

手順 3 で指定した情報に基づいて、アプリケーションが自動的にデプロイされます。

5. 次の形式の URL を使用して、プロバイダにアクセスします。

http://server:port/jpdk/providers/sample/provider name

PDK for Java にはいくつかのサンプル・プロバイダが付属しています。表 4-4 に、それらのサンプル・プロバイダを示します。

表表表表 4-4 PDK for Java のサンプル・プロバイダのサンプル・プロバイダのサンプル・プロバイダのサンプル・プロバイダ

プロバイダ名プロバイダ名プロバイダ名プロバイダ名説明説明説明説明

sample 様々なレンダリング技術、カスタマイズ機能およびキャッシュ機能のデモを実行できる各種のポートレットが入っています。

dbPersonalization dbPersonalizationManager の操作のデモを実行できるポートレットで

す。

externalApp 外部アプリケーションの統合のデモを実行できます。

feedback ポータルのユーザーからのフィードバックを取得できるサンプル・ポートレットです。

invalidation Oracle9iAS Web Cache を使用した、失効機能によるキャッシュのデモ

を実行できるサンプル・ポートレットです。

partnerApp パートナ・アプリケーションの統合のデモを実行できます。

subscriber 承認申請キーを使用してリクエストの発信元を識別する操作のデモを実行できます。



サンプル・プロバイダの登録サンプル・プロバイダの登録サンプル・プロバイダの登録サンプル・プロバイダの登録

Oracle HTTP Server で Web プロバイダのサンプルを設定したら、サンプル・ポートレットをページに追加する前に、設定したプロバイダを Oracle9iAS Portal に登録する必要があります。

1. Oracle Portal のホームページの「構築」タブで、「プロバイダ」という名前のポートレットの中にある「ポートレット・プロバイダの登録」をクリックします。

2. 次に示すように、サンプルのプロバイダ情報に関する各フィールドに値を入力します。

「名前」「名前」「名前」「名前」: SampleWebProvider

「表示名」「表示名」「表示名」「表示名」: サンプル Web プロバイダ

「タイムアウト」「タイムアウト」「タイムアウト」「タイムアウト」: 100

「タイムアウト・メッセージ」「タイムアウト・メッセージ」「タイムアウト・メッセージ」「タイムアウト・メッセージ」: 「Application Timed Out」

「実装スタイル」「実装スタイル」「実装スタイル」「実装スタイル」: 「Web」

「「「「Register on Remote Nodes」」」」: 「いいえ」

「ログイン頻度」「ログイン頻度」「ログイン頻度」「ログイン頻度」: 「ユーザー・セッションごとに 1 回」

「「「「URL」」」」:

http://myserver.mydomain.com:port/jpdk/providers/sample

（使用するプロバイダの URL に置き換えてください。）

次のオプションのラジオ・ボタンをクリックします。

「ユーザーは、「ユーザーは、「ユーザーは、「ユーザーは、Web プロバイダ・アプリケーション内とシングル・サインオン認証内とプロバイダ・アプリケーション内とシングル・サインオン認証内とプロバイダ・アプリケーション内とシングル・サインオン認証内とプロバイダ・アプリケーション内とシングル・サインオン認証内とで、同じ識別情報を保持します。」で、同じ識別情報を保持します。」で、同じ識別情報を保持します。」で、同じ識別情報を保持します。」

「プロキシを必要とする」「プロキシを必要とする」「プロキシを必要とする」「プロキシを必要とする」: 「いいえ」（プロバイダ・アダプタへの接続にプロキシを必要としない場合）

3. 「OK」をクリックします。

登録が完了すると、ポートレット・リポジトリにすべてのサンプル・ポートレットが表示されます。

注意注意注意注意 : Oracle Portal を使用して新しいプロバイダを登録する場合、プロバイダを登録したユーザーのみがプロバイダとポートレットを表示する権限を持ちます。必要な場合は、ポートレット・リポジトリのコンテンツ領域にある（プロバイダ名の付いた）フォルダに移動し、プロバイダ権限を適宜更新してください。



サンプル・ポートレットのページへの追加サンプル・ポートレットのページへの追加サンプル・ポートレットのページへの追加サンプル・ポートレットのページへの追加

サンプル・ポートレットをページに追加するには、次の手順に従います。

1. ページを作成します。

2. SampleWebProvider のポートレットを、作成したページに追加します。

3. ポートレットを追加したページを表示します。

ポートレット・リポジトリにあるポートレットを確認できます。

プロバイダの保護プロバイダの保護プロバイダの保護プロバイダの保護

本番環境で PDK for Java Framework を使用する場合、プロバイダへのアクセスを保護することをお薦めします。 Oracle9iAS には、（Oracle HTTP Server の構成ファイルであるhttpd.confを使用して）IP アドレスやホスト名をもとにアクセスを拒否する機能があります。次に例を示します。

Portal からのリクエストのみを受け入れる場合

プロバイダが Oracle Portal からのリクエストのみを受け入れるようにするには、プロバイダのパスを指定する Location ディレクティブを使用して、Portal の IP アドレスからのアクセスのみを許可するように設定します。 httpd.confファイルに次の行を追加してください。

<Location provider path> order deny, allow deny from all allow from ip address 1 allow from ip address 2 </Location>

ip address 1 と ip address 2 は、Portal があるコンピュータの IP アドレスを示します。

特定のパスを保護する場合

/servlet などのパスを保護することもできます。特定のパスを保護するには、そのパスに対する次のようなディレクティブを追加してください。

<Location /servlet > order deny, allow deny from all allow from ip address 1 allow from ip address 2 </Location>



特定のパスにある特定のサーブレットを保護する場合

provider という名前のサーブレットに対するアクセスを制限して、そのサーブレットがmy.oracle.com または portal.oracle.com からのアクセスのみを受け入れるようにするには、次のようなディレクティブを使用してください。

<Location /servlet/provider > order deny, allow deny from all allow from my.oracle.com allow from portal.oracle.com </Location>

PDK for Java 9.0.2 の概要の概要の概要の概要PDK for Java 9.0.x には、2 つのバージョンの PDK for Java Framework があります。

バージョン 1 は、PDK for Java 3.0.9 に組み込まれていたフレームワークを拡張したもので、携帯情報端末向けのコンテンツ・プロバイダおよびポートレットのサポートが追加されています。このバージョンのフレームワークは、JServ サーブレット・コンテナで実行できます。

バージョン 2 では、J2EE 準拠の OC4J サーブレット・コンテナで実行できる Web プロバイダを作成できます。バージョン 2 では、J2EE のサポートに加え、フレームワークにオブジェクト指向の技術が取り入れられており、既存の Web プロバイダを維持しながらフレームワークを容易に拡張できるようになっています。このような変更に伴って、新しいクラスを追加し、API を一部変更する必要が生じたため、バージョン 2 のフレームワークを使用するには、既存の Web プロバイダに変更を加える必要があります。

PDK for Java の旧リリースと新リリースの相違点のまとめの旧リリースと新リリースの相違点のまとめの旧リリースと新リリースの相違点のまとめの旧リリースと新リリースの相違点のまとめPDK for Java リリース 9.0.2 には、フレームワーク全体としての安定性を高めると同時に、既存のコードへの影響を小限に抑えながらフレームワークに新しい機能を容易に導入できるようにするための変更がいくつか加えられています。これらの変更内容は次のとおりです。

� API の定義に使用していた Java インタフェースを抽象クラスに変更

� パッケージ構造の再編成

� オブジェクト指向のフレームワークのサポート

関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server Oracle HTTP Server 管理ガイド』



インタフェースから抽象クラスへの変更インタフェースから抽象クラスへの変更インタフェースから抽象クラスへの変更インタフェースから抽象クラスへの変更

旧リリースの PDK for Java の開発時には、Java インタフェースを使用してトップレベルのAPI を定義していたため、新しい機能を追加するのが困難でした。その理由は、新しい機能の追加に伴って API を変更しなければならない場合が多く、API を変更すると、その変更をJava インタフェースの変更にも反映しなければならなかったからです。

デフォルトの実装を使用して開発している場合は、このような変更による影響はありませんでした。しかし、複雑なプロバイダを作成して開発している場合は、インタフェースを変更すると、プロバイダの実装がインタフェースの定義と一致しなくなるため、コードが壊れる可能性があります。

この問題を解決するため、ほとんどの Java インタフェースが抽象クラスに置き換えられました。抽象クラスを使用することによって、既存のコードを維持したまま新しい機能を追加できます。抽象クラスへの変更によって、（Java の多重継承がサポートされなくなるために）柔軟性が低くなり、新リリースの PDK for Java に対応するためにコードを変更しなければなりませんが、長期的な観点から見れば、安定性が向上するため、この変更によるメリットの方が大きいことがわかります。

パッケージの再編成パッケージの再編成パッケージの再編成パッケージの再編成

Java インタフェースから抽象クラスへの変更に加え、JPDK のパッケージ構造が変更されました。新しいバージョン・ナンバーが含まれ、機能別にクラスが編成されるようになりました。

すべてのパッケージのパッケージ名に、PDK for Java のバージョン 2 のパッケージであることを示す「v2」というバージョン・ナンバーが含まれるようになりました。パッケージ名にバージョン・ナンバーが含まれていると、衝突が発生しないようにして、同じクラスパスに異なるバージョンの PDK for Java を含めることができます。

バージョン・ナンバーの表示に加え、クラスがより論理的な構成になるように再編成されました。新しい構成では、クラスが機能別にグループ分けされます。これにより、既存のクラスを見つけやすくなり、新しい機能を追加したときに新しいクラスを編成しやすくなります。

オブジェクト指向のフレームワークオブジェクト指向のフレームワークオブジェクト指向のフレームワークオブジェクト指向のフレームワーク

コードが開発者にとってわかりやすくなるようにし、開発者が実装するプロバイダ API とOracle Portal と通信するための基本コードを明確に区別できるようにするために、プロバイダとポートレットのインタフェースが変更されました。

以前のプロバイダとポートレットの API はオブジェクト指向ではなく、フレームワークのコミュニケーション層からの API コールがこれらのオブジェクトをバイパスして、コントローラ・オブジェクトに直接アクセスする場合もありました。新しい API では、いくつかの点が変更されています。プロバイダ・インタフェースが、ProviderInstance およびProviderDefinition の 2 つの抽象クラスに分割されました。



以前のプロバイダ・インタフェースでは次のものを示していました。

� プロバイダの登録済インスタンス（特定のポータル・インスタンス上の登録済プロバイダを示す登録済インスタンス）

� プロバイダ（現在のポートレット）を定義するメタデータ

情報を分割することによって、クラスの用途が開発者にとってはっきりわかるようになり、1 組のメタデータを多数の登録済インスタンスの間で共有できるようになります。その結果、プロバイダのインスタンス固有の動作をサポートするプラットフォームが作成されます（たとえば、そのプロバイダの登録済インスタンスに固有の設定をプロバイダに設定できます）。

ポートレット・インタフェースは、PortletInstance および PortletDefinition の 2 つの抽象クラスに分割されました。以前のポートレット・インタフェースは、ポートレットのメタデータのみを示していました。ポートレットに影響を及ぼすすべての API コールは、実際には適切なコントローラに直接ルーティングされていました。このようなアーキテクチャの場合、フレームワークのコミュニケーション層との明確なインタフェースが作成されず、開発者が複雑なポートレットを操作しようとしても、フレームワーク内での制御の流れを理解するのが困難でした。

この問題を解決するため、PortletInstance および PortletDefinition の抽象クラスが作成されました。 PortletDefinition はポートレットの共有可能な定義を示し、PortletInstance は特定のユーザーがアクセスする（あるいは、特定のユーザーの代理としてアクセスする）そのポートレットの特定のインスタンスを示します。このように 2 つの抽象クラスに分割されたことにより、ポートレットのインスタンス（レンダリング、コピー、セキュリティなど）に影響を及ぼすすべての API が、PortletInstance クラスにまとめられました。

アーキテクチャがこのように変更されたことによって、開発者は PDK for Java のレンダリング、パーソナライズ、セキュリティのフレームワークを使用しなくても開発できるようになり、より自由な開発が可能になりました。 PortletInstance のデフォルト実装では、前のバージョンの PDK for Java で導入され、開発者が使い慣れているレンダリング、パーソナライズ、セキュリティのコントローラを、変更後も引き続き使用できます。コミュニケーション層からのすべてのコールは、ProviderInstance および（必要な場合には）PortletInstance から実行されるようになります。

プロバイダとポートレットのインスタンスを示すクラスが明確に定義されているので、PDK for Java のコミュニケーション層からのすべての API コールが ProviderInstance およびPortletInstance インタフェースを介してスムーズに伝達され、経験の浅い開発者にとってもわかりやすいフレームワークになっています。



移行オプション移行オプション移行オプション移行オプションフレームワークに 2 つのバージョンがあるので、次の 3 通りの移行オプションがあります。

� オプションオプションオプションオプション 1: PDK for Java 3.0.9.x から PDK for Java 9.0.x（v1）に移行する

� オプションオプションオプションオプション 2: PDK for Java 3.0.9.x から PDK for Java 9.0.x（v2）に移行する

� オプションオプションオプションオプション 3: PDK for Java 3.0.9.x から PDK for Java 9.0.x（v1）に移行した後、PDK for Java 9.0.x（v2）に移行する

オプション 1 は既存の Web プロバイダを変更する必要がないので、も簡単です。しかし、Oracle9iAS で JServ サーブレット・コンテナを設定する必要があります。この方法の場合、Oracle9iAS リリース 2（9.0.2）への移行後、すぐに既存の Web プロバイダを実装できます。しかし、OC4J のどの機能も使用することができません。

オプション 2 では、新しいフレームワークを使用できるように既存の Web プロバイダを変更する必要があるので、オプション 1 よりも作業が若干多くなります。ほとんどの Web プロバイダに対して、必要な変更を簡単に行うことができます（Java クラスの import 文を変更する、一部のメソッド・コールで使用されるクラスを変更する）。通常、バージョン 1 のフレームワークのメソッドをそのまま使用できるので、機能は変わりませんが、それらのメソッドの含まれるクラスが変更されている場合があります。オプション 2 では、OC4J サーブレット・コンテナの機能とバージョン 2 のフレームワークの新しい機能を利用できます。新しい機能のほとんどは、バージョン 2 のフレームワークにのみ追加されたものです。

オプション 3 は、オプション 1 とオプション 2 を組み合せた手法です。このオプションでは、Oracle9iAS リリース 2（9.0.2）で実行できる Web プロバイダを短時間で作成できます。その後、都合の良いときに、バージョン 2 のフレームワークに移行できます。

PDK for Java 3.0.9.x からからからから PDK for Java 9.0.x（（（（v1）への移行）への移行）への移行）への移行

この項では、PDK for Java 3.0.9 のプロバイダを PDK for Java 9.0 のバージョン 1 に移行する方法について説明します。この場合、プロバイダのコードや定義ファイルを変更する必要はありません。主に必要な作業は、JServ の設定と Web プロバイダを示すサーブレットの宣言です。

1. $ORACLE_HOME_2/Apache/Apache/conf/httpd.confにある jserv.confファイルに対する Include ディレクティブをアンコメントします。

#include "/$ORACLE_HOME_2/Apache/Jserv/etc/jserv.conf"

2. jserv.confを編集し、JServ の使用方法にあうようにディレクティブを設定します。（jserv.confには、プロセス管理とロード・バランシング・サービスを提供する

Oracle のモジュールである、mod_jserv および mod_oprocmgr を設定する Include ディレクティブが含まれます。）

関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server Oracle HTTP Server管理ガイド』



3. 必要に応じて、$ORACLE_HOME_2/Apache/Jserv/etc/jserv.propertiesファイルを編集します。

4. 必要に応じて、$ORACLE_HOME_2/Apache/Jserv/etc/zone.propertiesファイルを編集します。

5. 次の手順を実行すると、JServ と Oracle9iAS Containers for J2EE（OC4J）が共存できるように設定できます。

あるアプリケーションが JServ 上で実行され、別のアプリケーションが OC4J 上で実行されるように設定できます。次の URL があるとします。

/application1/file1.jspは、JServ 上で実行するための URL です。

/application2/file2.jspは、OC4J 上で実行するための URL です。

application1 の URL を書き換える必要があります。

a. $ORACLE_HOME_2/Apache/Apache/conf/httpd.confを編集し、次のディレクティブがアクティブで（アンコメントされていて）、存在することを確認します。

LoadModule rewrite_module libexec/mod_rewrite.soRewriteEngine on

b. $ORACLE_HOME_2/Apache/jsp/conf/ojsp.confを編集して、次のディレクティブを追加します。

RewriteRule /application1/(.*)/(.*)\.jsp$ /application1/$1/$2.jsp1ApJServAction .jsp1 /servlets/oracle.jsp.JspServlet

c. 次のディレクティブを削除します。

ApJServAction .jsp /servlets/oracle.jsp.JspServlet

d. $ORACLE_HOME_2/Apache/Jserv/etc/jserv.confを編集し、/servletsを、JSP リクエストを処理する JVM へマウントします。 ApJServMount ディレクティブまたは ApJServGroupMount ディレクティブを使用します（JServ プロセスの起動方法によって、どちらを使用するか決まります）。

6. プロバイダに必要な製品をインストールします。

� Oracle XML Parser V2（必須）

� Oracle JSP（プロバイダが JSP を使用している場合に必要）

� Oracle JDBC（データベース・パーソナライズ・マネージャを使用している場合またはプロバイダがデータベースにアクセスする必要がある場合に必要）

7. PDK for Java 9.0.x のバージョン 1 をインストールします。 $ORACLE_HOME_2/portal/pdkjava/v1/jpdkv1.zipの圧縮ファイルを使用します。このファイルを解凍して適当な場所に置きます。ここでは、$ORACLE_HOME_2/portal/pdkjava/v1に置くものとします。



8. $ORACLE_HOME_2/Apache/Jserv/etc/jserv.propertiesファイルのwrapper.classpathに、$ORACLE_HOME_2/portal/pdkjava/v1/jpdk/v1/lib/provider.jarを追加します。

9. $ORACLE_HOME_2/Apache/Jserv/etc/zone.propertiesファイルに、プロバイダのサーブレット・エントリを宣言します。（$ORACLE_HOME_1/Apache/Jserv/etc/zone.propertiesファイルから、サーブレット・エントリをコピーして貼り付けます。）

ファイルの内容は例 4-5 のようになります。この例で使用されている表記上の規則について次に説明します。

� 太字は、値が変更されたことを示します。変更された値のほとんどはクラス名です。

� 太字のイタリックはファイル構造が変更されたことを示します。太字のイタリックで強調されている箇所は、削除、追加または変更された箇所です。

例例例例 4-5 バージョンバージョンバージョンバージョン 1 へのアップグレード後のサンプル・プロバイダの定義ファイルへのアップグレード後のサンプル・プロバイダの定義ファイルへのアップグレード後のサンプル・プロバイダの定義ファイルへのアップグレード後のサンプル・プロバイダの定義ファイル

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?providerDefinition version="2.0"?> <!DOCTYPE provider [ <!ENTITY virtualRoot "/jpdk/"> <!ENTITY physicalRoot "E:\9iAS\Apache\Apache\htdocs\jpdk\"> ]> <provider class="oracle.portal.provider.v1.http.DefaultProvider"> <session>true</session> <containerRenderer class="oracle.portal.provider.v1.DefaultContainerRenderer" />

<portlet class="oracle.portal.provider.v1.http.DefaultPortlet"> <id>1</id> <name>samplePortlet</name> <title>Sample Portlet</title> <shortTitle>Sample</shortTitle> <description>PDK-Java version 1 portlet definition</description> <timeout>10</timeout> <timeoutMessage>Sample Portlet timed out</timeoutMessage> <hasHelp>true</hasHelp> <hasAbout>true</hasAbout> <showDetails>true</showDetails> <showEdit>true</showEdit> <showEditDefault>true</showEditDefault> <acceptContentType>text/html</acceptContentType> <renderer class="oracle.portal.provider.v1.RenderManager"> <resourcePath>&virtualRoot;samplePortlet</resourcePath> <appRoot>&physicalRoot;samplePortlet</appRoot> <contentType>text/html</contentType> <showPage class="oracle.portal.provider.v1.http.JspRenderer">



<name>showPage.jsp</name> </showPage> <helpPage class="oracle.portal.provider.v1.http.FileRenderer"> <name>help.html</name> </helpPage> <editPage class="oracle.portal.provider.v1.http.Servlet20Renderer"> <servletClass>your.package.EditServlet</servletClass> </editPage> <editDefaultsPage class="oracle.portal.provider.v1.http.Servlet20Renderer"> <servletClass>your.package.EditServlet</servletClass> </editDefaultsPage> <aboutPage class="oracle.portal.provider.v1.http.FileRenderer"> <name>about.html</name> </aboutPage> <showDetailsPage class="oracle.portal.provider.v1.http.JspRenderer"> <name>details.jsp</name> </showDetailsPage> </renderer> <personalizationManager class="oracle.portal.provider.v1.FilePersonalizationManager"> <dataClass>your.package.DataClass</dataClass> <useHashing>true</useHashing> </personalizationManager> <securityManager class="oracle.portal.provider.v2.security.DefaultSecurityManager"> <authLevel>STRONG</authLevel> </securityManager> </portlet> </provider>

PDK for Java 3.0.9.x からからからから PDK for Java 9.0.x（（（（v2）への移行）への移行）への移行）への移行

この項では、既存の（PDK for Java 3.0.9 の）プロバイダを変更する方法について説明します。

Java クラス、サーブレットまたはクラス、サーブレットまたはクラス、サーブレットまたはクラス、サーブレットまたは JSP の更新の更新の更新の更新

この項では、新しいフレームワークの JavaDoc について説明します。 JavaDoc は PDK for Java のサンプル・プロバイダと一緒にインストールされます。JavaDoc には、次の形式のURL を使用してアクセスします。

http://host:port/jpdk/apidoc

hostは、Oracle9iAS リリース 2（9.0.2）がインストールされているコンピュータの名前を示します。portは、Oracle HTTP Server がリスニングしているポートを示します。



1. Java クラスと JSP の import文を変更して、新しいパッケージ構成を反映させます。新しいパッケージ階層は、レンダリング、セキュリティ、パーソナライズなどの機能に基づいた、より論理的な構成になっています。

2. oracle.portal.provider.v1.Providerへの参照を、コールされるメソッドに従って、oracle.portal.provider.v2.ProviderInstanceまたはoracle.portal.provider.v2.ProviderDefinitionに変更します。コールされるメソッドがどちらのクラスに含まれているかは、JavaDoc で確認します。

3. oracle.portal.provider.v1.Portletへの参照を、コールされるメソッドに従って、oracle.portal.provider.v2.PortletInstanceまたはoracle.portal.provider.v2.PortletDefinitionに変更します。コールされるメソッドがどちらのクラスに含まれているかは、JavaDoc で確認します。

4. oracle.portal.provider.v1.DefaultSecurityManagerへの参照を、oracle.portal.provider.v2.security.AuthLevelSecurityManagerに変更します。

5. providerIdを格納する変数の型を long 型から java.lang.String に変更します。（データ型を変更することによって、将来のリリースの API をより柔軟に活用できるようになります。）

プロバイダ定義ファイル（プロバイダ定義ファイル（プロバイダ定義ファイル（プロバイダ定義ファイル（provider.xml）の更新）の更新）の更新）の更新

1. oracle.portal.provider.v1.DefaultProviderへの参照を、oracle.portal.provider.v2.DefaultProviderDefinition（またはoracle.portal.provider.v2.ProviderDefinitionを拡張するクラス）に変更します。

2. oracle.portal.provider.v1.DefaultPortletへの参照を、oracle.portal.provider.v2.DefaultPortletDefinition（またはoracle.portal.provider.v2.PortletDefinitionを拡張するクラス）に変更します。

3. oracle.portal.provider.v1.http.JspRendererおよびoracle.portal.provider.v1.http.Servlet20Rendererへの参照を、oracle.portal.provider.v2.render.http.ResourceRendererに変更します。

4. JSP/ サーブレット・ファイルへの参照を、プロバイダの WAR ファイル内のリソース（JSP、サーブレットまたはファイル）の場所に基づく相対 URI に変更します。プロバイダの WAR ファイルおよび WAR ファイルを使用してプロバイダをデプロイする方法の詳細は、4-29 ページの「プロバイダのパッケージングおよびデプロイ」を参照してください。



5. （オプション）oracle.portal.provider.v1.render.FileRendererへの参照を、oracle.portal.provider.v2.render.FileRendererまたはoracle.portal.provider.v2.render.http.ResourceRendererに変更します。 JSP、サーブレットおよび静的ファイルに対しては、ResourceRenderer を使用できます。しかし、静的ファイルに対しては FileRenderer を使用することをお薦めします。FileRenderer を使用すると、指定されたファイルの内容がメモリーにキャッシュされ、ファイルを作成するたびにファイル・システムにアクセスしなくても済むようになります。

6. バージョン 1 のパーソナライズ・マネージャをバージョン 2 のものに変更します。

バージョン 2 の PDK for Java Framework には、次の 2 つのパーソナライズ・マネージャがあります。

oracle.portal.provider.v2.personalize.PrefStorePersonalizationManager

および

oracle.portal.provider.v2.personalize.DBPersonalizationManager

PrefStorePersonalizationManagerは、FilePersonalizationManagerおよび DBPersonalizationManager2にかわるものです。環境設定を格納するためのプリファレンス・ストアという新しい機能があります。 PrefStorePersonalizationManagerを使用するには、プロバイダの定義ファイルに、1 つ以上のプリファレンス・ストアを宣言する必要があります。プリファレンス・ストアは、ファイル・ベースとデータベース・ベースのどちらでも可能です。ファイル・ベースまたはデータベース・ベースのプリファレンス・ストアは、PDK for Java 3.0.9 のパーソナライズ・マネージャと互換性があります。

旧リリースで使用していたもの旧リリースで使用していたもの旧リリースで使用していたもの旧リリースで使用していたもの新リリースで使用するもの新リリースで使用するもの新リリースで使用するもの新リリースで使用するもの

FilePersonalizationManager PrefStorePersonalizationManager およびファイル・

ベースのプリファレンス・ストア

DBPersonalizationManager2 PrefStorePersonalizationManager およびデータベー

ス・ベースのプリファレンス・ストア

DBPersonalizationManager oracle.portal.provider.v2.personalize.DBPersonalizationManager



ファイル・ベースのプリファレンス・ストアの宣言ファイル・ベースのプリファレンス・ストアの宣言ファイル・ベースのプリファレンス・ストアの宣言ファイル・ベースのプリファレンス・ストアの宣言

ファイル・ベースのプリファレンス・ストアを宣言するには、次の例に示すようなXML を使用します。 rootDirectoryには、FilePersonalizationManager で使用されていたルート・ディレクトリを指定してください。 FilePersonalizationManager の宣言時にルート・ディレクトリを指定しなかった場合、rootDirectoryには、プロバイダ・サーブレットに渡される provider_root引数に指定されたルート・ディレクトリを指定してください。パーソナライズ・データを新しい場所に移動するには、zip または tarを使用して、元のルート・ディレクトリ（すべてのサブディレクトリを含む）の中身を圧縮し、移動先で解凍します。（その場合、rootDirectoryの値は、データの解凍先のディレクトリのパスになります。）

<preferenceStore class="oracle.portal.provider.v2.preference.FilePreferenceStore"> <name>prefStore1</name> <rootDirectory>d:\root\directory</rootDirectory> <useHashing>true</useHashing> </preferenceStore>

データベース・ベースのプリファレンス・ストアの宣言データベース・ベースのプリファレンス・ストアの宣言データベース・ベースのプリファレンス・ストアの宣言データベース・ベースのプリファレンス・ストアの宣言

データベース・ベースのプリファレンス・ストアを宣言するには、次の例に示すようなXML を使用します。 DBPreferenceStore を使用する場合は、プロバイダをデプロイするOC4J インスタンスの j2ee/home/config/datasources.xmlファイルに、データソースを宣言する必要があります。 DBPreferenceStore は JNDI を使用して、プリファレンス・ストアとして使用するデータソースを検索します。

<preferenceStore class="oracle.portal.provider.v2.preference.DBPreferenceStore"> <name>prefStore2</name> <connection>oc4jDataSourceName</connection> <table>databaseTableName</table> </preferenceStore>

7. 次への参照を、

oracle.portal.provider.v1.DefaultSecurityManager

次に変更します。

oracle.portal.provider.v2.security.AuthLevelSecurityManager

注意注意注意注意 : プリファレンス・ストアは、<provider> 要素の中で、<portlet>要素と同じレベルで宣言する必要があります。



ファイルの内容は例 4-6 のようになります。この例で使用されている表記上の規則について次に説明します。

� 太字は、値が変更されたことを示します。変更された値のほとんどはクラス名です。

� 太字のイタリックはファイル構造が変更されたことを示します。太字のイタリックで強調されている箇所は、削除、追加または変更された箇所です。

例例例例 4-6 バージョンバージョンバージョンバージョン 2 へのアップグレード後のプロバイダの定義ファイルへのアップグレード後のプロバイダの定義ファイルへのアップグレード後のプロバイダの定義ファイルへのアップグレード後のプロバイダの定義ファイル

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><?providerDefinition version="3.1"?> <provider class="oracle.portal.provider.v2.DefaultProviderDefinition"> <session>false</session> <containerRenderer class="oracle.portal.provider.v2.render.DefaultContainerRenderer" /> <preferenceStore class="oracle.portal.provider.v2.preference.FilePreferenceStore"> <name>prefStore1</name> <rootDirectory>d:\root\directory</rootDirectory> <useHashing>true</useHashing> </preferenceStore> <portlet class="oracle.portal.provider.v2.DefaultPortletDefinition"> <id>1</id> <name>samplePortlet</name> <title>Sample Portlet</title> <shortTitle>Sample</shortTitle> <description>PDK-Java version 2 portlet definition</description> <timeout>10</timeout> <timeoutMessage>Sample timed out</timeoutMessage> <hasHelp>true</hasHelp> <hasAbout>true</hasAbout> <showDetails>true</showDetails> <showEdit>true</showEdit> <showEditDefault>true</showEditDefault> <acceptContentType>text/html</acceptContentType> <renderer class="oracle.portal.provider.v2.render.RenderManager"> <contentType>text/html</contentType> <showPage class="oracle.portal.provider.v2.render.ResourceRenderer"> <resourcePath>/jsps/showPage.jsp</resourcePath> </showPage> <helpPage class="oracle.portal.provider.v2.render.http.FileRenderer"> <appRoot>file path</appRoot> <name>help.html</name> </helpPage> <editPage>/servlet/editServlet</editPage> <editDefaultsPage>/servlet/editServlet</editDefaultsPage> <aboutPage>/htdocs/submitServlet/about.html</aboutPage>



<showDetailsPage>/jsps/showDetails.jsp</showDetailsPage> </renderer> <personalizationManager class="oracle.portal.provider.v2.personalize.PrefStorePersonalizationManager" > <dataClass>your.package.DataClass</dataClass> </personalizationManager> <securityManager class="oracle.portal.provider.v2.security.AuthLevelSecurityManager"> <authLevel>STRONG</authLevel> </securityManager> </portlet> </provider>

プロバイダのパッケージングおよびデプロイプロバイダのパッケージングおよびデプロイプロバイダのパッケージングおよびデプロイプロバイダのパッケージングおよびデプロイこの項では、プロバイダをパッケージしてデプロイする手順について説明します。この項の項目は次のとおりです。

� 4-29 ページのページのページのページの「サービス名またはサービス識別子」「サービス名またはサービス識別子」「サービス名またはサービス識別子」「サービス名またはサービス識別子」

� 4-29 ページのページのページのページの「「「「WAR ファイルおよびファイルおよびファイルおよびファイルおよび EAR ファイル」ファイル」ファイル」ファイル」

� 4-33 ページのページのページのページの「「「「OC4J へのプロバイダのデプロイ」へのプロバイダのデプロイ」へのプロバイダのデプロイ」へのプロバイダのデプロイ」

� 4-34 ページのページのページのページの「プロバイダの登録」「プロバイダの登録」「プロバイダの登録」「プロバイダの登録」

サービス名またはサービス識別子サービス名またはサービス識別子サービス名またはサービス識別子サービス名またはサービス識別子

PDK for Java では、複数のプロバイダを 1 つのアダプタ・サーブレットの下にデプロイできます。プロバイダは、サービス名またはサービス識別子（SOAP のサービス識別子と同じ）によって識別されます。新しいプロバイダをデプロイする場合、プロバイダにサービス名を割り当て、そのサービス名を使用して、プロバイダの WAR ファイルを作成する必要があります。

デプロイ後には、正しいサービス名を使用してプロバイダを Oracle Portal に登録し、リクエストが適切なプロバイダに確実に送られるようにする必要があります。旧リリースの Oracle Portal ではサービス名が含まれないので、プロバイダの 1 つをデフォルトのプロバイダに指定できます。サービス名が指定されていないリクエストをアダプタ・サーブレットが受け取ると、そのリクエストはデフォルトのプロバイダに転送されます。

WAR ファイルおよびファイルおよびファイルおよびファイルおよび EAR ファイルファイルファイルファイル

WAR（Web Application Archive）ファイルと EAR（Enterprise Application Archive）ファイルを使用すると、標準化された手順で、OC4J などの J2EE アプリケーション・サーバーにアプリケーションをデプロイすることができます。 WAR ファイルと EAR ファイルは、アプリケーションの実行に必要なすべてのコンポーネントを 1 つのファイルにカプセル化したものです。そのため、どのアプリケーションをデプロイする場合でも、簡単で一貫した方法でデプロイすることができ、アプリケーションの開発環境から、テスト環境、本番環境への移動時に発生するエラーの数を減らすことができます。



WAR ファイルには、Web アプリケーションのすべてのコンポーネントが含まれます。アプリケーションを実行するために必要な、Java ライブラリまたはクラス、サーブレット定義およびパラメータ設定、JSP ファイル、静的 HTML ファイルなどのリソースが含まれます。

EAR ファイルは企業アプリケーションのアーカイブに相当します。 EAR ファイルによって、Web アプリケーションをグループ化する仕組みが提供されます。

作業ディレクトリの作成作業ディレクトリの作成作業ディレクトリの作成作業ディレクトリの作成

WAR ファイルと EAR ファイルのディレクトリを作成するには、次の手順に従います。

1. deploy という名前のディレクトリを作成します。

2. deploy/ear および deploy/war という名前のサブディレクトリを作成します。

3. ディレクトリの指定を deploy/earに変更します。

4. 次のコマンドを使用してテンプレート EAR ファイルを解凍し、deploy/earに置きます。

jar -xvf $ORACLE_HOME_2/portal/pdkjava/v2/lib/template.ear

5. deploy/ear/template.earファイルをデプロイ先のディレクトリに移動します。

6. deploy/ear/template.warファイルを deploy/warに移動します。

7. ディレクトリの指定を deploy/warに変更します。

8. 次のコマンドを使用してテンプレート WAR ファイルを解凍し、deploy/warに置きます。

jar -xvf deploy/war/template.war

9. deploy/war/template.warファイルをデプロイ先のディレクトリに移動します。

WAR ファイルと EAR ファイルを作成するために必要な構造とファイルを持つ 2 つの作業ディレクトリが作成されました。

WAR ファイルのコンテンツの指定ファイルのコンテンツの指定ファイルのコンテンツの指定ファイルのコンテンツの指定

プロバイダをデプロイする場合、まず初に、プロバイダおよびプロバイダを実行するのに必要なすべてのリソースを含む WAR ファイルを作成する必要があります。手動で WARファイルを作成する場合には、次の手順に従います。ソフトウェア・ユーティリティを使用して WAR ファイルを作成することもできます。

1. プロバイダに必要な JAR ファイルをコピーして、deploy/war/WEB-INF/libディレクトリに置きます。このディレクトリには、PDK for Java の JAR ファイルが置かれています。

2. .jar ファイルに含まれない Java クラスがプロバイダに必要な場合は、それらのクラスをdeploy/war/WEB-INF/libディレクトリに追加します。クラス・ファイルが、それぞれの Java パッケージ名に対応するディレクトリやサブディレクトリに必ず保存されるようにします。



3. 静的 HTML ファイル、JSP およびイメージを deploy/warに追加します。

4. プロバイダのプロバイダ用ディレクトリの下にサブディレクトリを作成します。サブディレクトリの名前は、プロバイダのサービス識別子またはサービス名になります。

5. 作成したサブディレクトリにプロバイダ定義ファイルを置きます。

6. _default.propertiesファイルを serviceid.propertiesにコピーし、プロバイダの構成を反映するように編集します。

7. WAR ファイルに含まれるプロバイダが 1 つのみである場合、デフォルト・プロバイダの構成を反映するように _default.propertiesファイルを編集します（デフォルト・プロバイダとは、Portal からのリクエストにサービス識別子が指定されていない場合にアクセスされるプロバイダです）。

8. サーブレットを使用してコンテンツを作成する場合は、WEB-INF/web.xmlを編集して、あらかじめ定義されたサーブレットの一覧に、使用するサーブレットを追加します。このとき、PDK for Java で必要なサーブレットを削除しないように注意してください。

注意注意注意注意 : サブディレクトリを作成して、ファイルを整理できます。サブディレクトリは、ファイルへのアクセス時に使用される URI の一部になるので、注意してください。たとえば、htmlというサブディレクトリを作成し、すべての静的 HTML ファイルをそのサブディレクトリに置いたとします。そのサブディレクトリにある help.htmlファイルにアクセスするには、プロバイダ定義ファイルで html/help.html という URI を指定して、そのファイルへの参照を指定します。作成するサブディレクトリの数や深さに制限はありません。

注意注意注意注意 : リリース 3.0.9 以下の Portal では、サービス識別子を指定できないので、リクエストは常にデフォルトのプロバイダに転送されます。



デフォルト・サービスの指定デフォルト・サービスの指定デフォルト・サービスの指定デフォルト・サービスの指定

デフォルト・サービスとは、サービス名が指定されていないすべてのリクエストを受け入れるプロバイダです。デフォルト・サービスは、Oracle Portal リリース 3.0.9 のプロバイダを登録できるようにするための機能です。

デフォルト・プロバイダは、WAR ファイル用の /deploy ディレクトリにある _default.propertiesファイルに指定します。 _default.propertiesファイルは次のような内容です。

serviceClass=oracle.portal.provider.v2.adapter.soapV1.ProviderAdapter loaderClass=oracle.portal.provider.v2.http.DefaultProviderLoader definition=providers/sample/provider.xml autoReload=true

1. definition=エントリを編集して、デフォルト・プロバイダ用のプロバイダ定義ファイルを指定します。指定するディレクトリ・パスは WAR ファイルのコンテンツに基づくパスにする必要があります。ファイルシステムでのファイルの物理的な位置を指定しないでください。

2. プロバイダ定義ファイルを使用しないでプロバイダを定義している場合は、ProviderLoaderインタフェースの実装を作成し、loaderClass エントリを編集する必要があります。

WAR ファイルの作成ファイルの作成ファイルの作成ファイルの作成

WAR ファイルのコンテンツを指定したら、WAR ファイルそのものを作成します。 WARファイルを作成するには、次の手順に従います。


2. 次のコマンドを使用して、WAR ファイルを作成します。

jar -cvf warfilename.war

warfilename は、作成する WAR ファイルの名前を示します。

EAR ファイルの作成ファイルの作成ファイルの作成ファイルの作成

EAR ファイルを手動で設定するには、次の手順に従います。ソフトウェア・ユーティリティを使用して、EAR ファイルを作成することもできます。

1. ディレクトリの指定を deploy/earに変更します。

2. META-INF/application.xmlファイルを開きます（このファイルは、EAR ファイル・テンプレートの解凍後に作業ディレクトリに置かれたファイルです）。ファイルの内容は次のようになります。

<?xml version "1.0"> <!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd">



<application> <display-name>this is the display name of the application</display-name> <description>this is a description of the application</description> <module> <web> <web-uri>yourwarfile.war</web-uri> <context-root>/</context-root> </web> </module> </application>

3. <display-name>要素の値をアプリケーションの表示名に変更します。

4. <description>要素の値をアプリケーションの説明に変更します。

5. <web-uri>要素の値を、使用する WAR ファイル名に変更します。

6. application.xmlファイルを、そのままの名前で元の場所に保存します。

7. 以前に作成した WAR ファイルを deploy/earディレクトリにコピーします。


9. 次のコマンドを使用して、EAR ファイルを作成します。

jar -cvf earfilename.ear

earfilename は、作成する EAR ファイルの名前を示します。

OC4J へのプロバイダのデプロイへのプロバイダのデプロイへのプロバイダのデプロイへのプロバイダのデプロイ

OC4J にプロバイダをデプロイするには、次の手順に従います。

1. .ear ファイルを OC4J のアプリケーション・サブディレクトリ（通常は、$ORACLE_HOME/oc4j/j2ee/home/applications）にコピーします。

2. $ORACLE_HOME/oc4j/j2ee/home/config/server.xmlファイルに次の行を追加します。

<application name="application name" path="../applications/ear file name" />

application name はアプリケーション名を示します。ear file name はプロバイダを含む.ear ファイルの名前を示します。

3. $ORACLE_HOME/oc4j/j2ee/home/config/default-web-site.xmlファイルに次の行を追加して、デフォルト・サイトに Web アプリケーションをバインドします。

<web-app application="application name" name="deployment name" path="/{application path}/" />



application name は、server.xml ファイルに指定されたアプリケーション名を示します。deployment name は、そのアプリケーションのデプロイに関連する名前を示します。

4. OC4J を起動します。

手順 3 で指定した情報に基づいて、アプリケーションが自動的にデプロイされます。

5. 次の形式の URL を使用して、プロバイダにアクセスします。

http://host:port/application path/servlet/soaprouter

host は、Oracle9iAS リスナーをホスティングしているサーバーの名前を示します。portは、Oracle9iAS リスナーが使用するポートを示します。application path は、手順 3 で指定したアプリケーションの相対 URI を示します。次に例を示します。

http://iashost:80/newProvider/servlet/soaprouter

6. プロバイダがデプロイされ、アクセス可能であることを確認します。デフォルト・プロバイダのテスト・ページが表示されます（.properties ファイルに debug=1 と指定されている必要があります）。特定のプロバイダのテスト・ページを表示するには、そのサービス名を URL に追加します。次に例を示します。

http://iashost:80/newProvider/servlet/soaprouter/sample

プロバイダの登録プロバイダの登録プロバイダの登録プロバイダの登録

Web プロバイダには、URL のほかに、サービス名やサービス識別子があります。 URL はアダプタ・サーブレットの場所を示し、サービス名はそのアダプタにデプロイされるプロバイダを示します。

Oracle Portal リリース 3.0.9 ではサービス名を使用しないので、登録の手順が異なります。

� Oracle Portal 9.0.2 での登録

Oracle Portal 9.0.2 で Web プロバイダを登録するときに登録ウィザードを使用すると、プロバイダの URL とサービス名の両方を指定するフィールドが表示されます。 URL にはアダプタ・サーブレットの URL を指定し、サービス名には登録するプロバイダ・サービスの名前を指定します。 URL とサービス名の両方を指定してください。サービス名を指定しなかった場合は、デフォルト・プロバイダとして登録されます。あいまいな設定を避けるため、必ずサービス名を指定してください。

� Oracle Portal 3.0.9 での登録

Oracle Portal 3.0.9 で登録する場合には、サービス名をアダプタの URL に追加して指定します。たとえば、次のように指定します。

サービス名 : sample

サーブレットの URL: http://iashost:80/newProvider/servlet/soaprouter

登録 URL: http://iashost:80/newProvider/servlet/soaprouter/sample



登録 URL に /sampleを指定しなかった場合、すべてのリクエストは _default.propertiesに指定されたプロバイダに転送されます（「デフォルト・サービスの指定」を参照してください）。この機能によって、既存のプロバイダを新しいバージョンの PDK for Java にアップグレードしても、そのプロバイダを使用するポータルに影響を与えることなく、元の URL を使用してプロバイダをデプロイできます。

中間層のアップグレード後の中間層のアップグレード後の中間層のアップグレード後の中間層のアップグレード後の Web Cache のキャッシュ・ルールのキャッシュ・ルールのキャッシュ・ルールのキャッシュ・ルールこの項で説明するキャッシュ設定の変更のほかにも、Oracle9iAS リリース 2（9.0.2）ではデフォルトで Web Cache をインストールします。Oracle9iAS Portal リリース 9.0.2 では Web Cache の機能を使用します。

リリース 3.0.x の Portal を Oracle9iAS リリース 2（9.0.2）の Portal にアップグレードする場合、または Portal リポジトリを Oracle9iAS リリース 2（9.0.2）にアップグレードする前にMiddle-Tier をアップグレードする場合は、Web Cache に特定のキャッシュ・ルールを設定して、Portal のコンテンツがキャッシュされるのを防ぐ必要があります。キャッシュされたコンテンツは保護されなくなります。この項では、キャッシュ・ルールを設定する理由とその設定方法について説明します。

Web Cache のキャッシュ機能についてのキャッシュ機能についてのキャッシュ機能についてのキャッシュ機能について

Oracle9iAS リリース 2（9.0.2）での Web Cache のデフォルトのキャッシュ・ルールには、次のルールが含まれます。

� *.pdf、*.html、*htm、*gif、*jpe、*jpeg、*.js のすべてのファイルをキャッシュに永久に格納する。

� Expires、Last-Modified などの標準の HTTP ヘッダーを受け入れる。

Portal 3.0.9 のキャッシュ機能についてのキャッシュ機能についてのキャッシュ機能についてのキャッシュ機能について

Portal リリース 3.0.9 では、標準の HTTP ヘッダーを使用して、あらかじめ指定された期間の間、" フル・ページ "、データベースにあるイメージとドキュメント、および中間層にあるイメージをブラウザにキャッシュします。

リリースリリースリリースリリース 2 のののの Middle-Tier をををを Web Cache とととと Portal 3.0.9 のリポジトリと一緒に使用する場合ののリポジトリと一緒に使用する場合ののリポジトリと一緒に使用する場合ののリポジトリと一緒に使用する場合のキャッシュ機能キャッシュ機能キャッシュ機能キャッシュ機能

Web Cache があるリリース 2 の Middle-Tier を Portal 3.0.9 のリポジトリのフロントエンドとして使用する場合、Web Cache のキャッシュ・ルールが Potal のキャッシュ・ルールより優先されます。

注意注意注意注意 : このマニュアルでは Portal リポジトリの移行方法については説明しません。



� ブラウザにキャッシュされるはずのすべての Portal オブジェクトが、Web Cache によってキャッシュされるため、セキュリティ上の問題が生じます。

� Web Cache のデフォルトのキャッシュ・ルールによって、ブラウザにキャッシュされないはずのドキュメントが、Web Cache にキャッシュされてしまいます。

� Portal のキャッシュ・ルールでは、8 時間後に期限切れになるはずのイメージが、Web Cache によってキャッシュに永久に格納されることもあります。

キャッシュ・ルールの設定キャッシュ・ルールの設定キャッシュ・ルールの設定キャッシュ・ルールの設定

Web Cache によって Portal のコンテンツがキャッシュされるのを防ぐため、2 つのキャッシュ・ルールを設定する必要があります。この 2 つのルールは、次のリクエストがキャッシュされるのを防ぎます。

� Middle-Tier の mod_plsqsl コンポーネントへのリクエスト。このリクエストの URL は/pls/DAD name/という形式になります。デフォルトの DAD 名は portal30です。この項で説明する例では、この DAD 名を使用しています。

� Middle-Tier の Page Assembler コンポーネントへのリクエスト。このリクエストの URLは /servlet/page/という形式になります。

キャッシュ・ルールを追加するには、次の手順に従います。

1. 「Web Cache Administrator」ページに移動します。

2. ユーザー名を administratorと入力して、Web Cache 管理者から与えられたパスワードを入力します。（デフォルトのパスワードは adminstratorです。）

3. 「OK」をクリックします。

「Web Cache Administration」ページが表示されます。

4. ナビゲーション・フレームの「General Configuration」セクションで、「Cacheability Rules」のリンクをクリックします。

5. 「Site Specific」表の初の行のラジオ・ボタンをクリックします。

6. 表の下にある「Insert Above」ボタンをクリックします。

「Create Cacheability Rule」ウィンドウが表示されます。

7. 「URL expression」フィールドに /pls/portal30と入力します。（DAD 名がportal30以外の場合は、DAD 名を入力します。）

8. 「POST Body Expression」フィールドに .*（ドット、アスタリスク）と入力します。

9. 「Don't Cache」ラジオ・ボタンがオンになっていることを確認します。

10.「Compress」がオフになっていることを確認します。

11.「Comment」フィールドに、「Portal のコンテンツが Web Cache にキャッシュされないように設定する。Portal リポジトリをリリース 2 にアップグレートしたら、このコメントを削除すること。」と入力します。



12.「Submit」をクリックします。

ウィンドウが閉じます。表の初の行に、入力した値が表示されます。

13. 追加したルールの横にあるラジオ・ボタンをクリックします。

14. 表の下にある「Insert Below」ボタンをクリックします。

「Create Cacheability Rule」ウィンドウが表示されます。

15.「URL expression」フィールドに /servlet/pageと入力します。

16.「Method」フィールドで、GET および問合せ文字列の付いた GET のチェック・ボックスをオンにします。

17.「Don't Cache」ラジオ・ボタンがオンになっていることを確認します。

18.「Comment」フィールドに、「Portal のコンテンツが Web Cache にキャッシュされないように設定する。Portal リポジトリをリリース 2 にアップグレートしたら、このコメントを削除すること。」と入力します。

19.「Submit」をクリックします。

ウィンドウが閉じます。表の 2 番目の行に、入力した値が表示されます。

20. 同じ手順を繰り返して、pls/portal30_ssoを設定します。

SSL 設定の移行設定の移行設定の移行設定の移行SSL 設定の移行は手動で行います。移行時には、Portal のページをレンダリングするルート上に SSL 接続を設定する必要があります。 Oracle9iAS Portal には、クライアントとサーバーの組合せが含まれ、それぞれの組合せが SSL 接続によって保護されます。たとえば、Web Cache と Parallel Page Engine は、クライアントとサーバーとして機能しますが、Oracle9i Application Server はサーバーとしてのみ機能します。

Oracle9iAS リリース 2（9.0.2）で SSL 接続を移行（または再設定）するには、次の手順に従います。 Oracle HTTP Server に対する SSL 証明書と Wallet は、Oracle9iAS Migration Assistant によって作成されます（2-8 ページの「SSL 設定の移行」を参照してください）。以前のリリースで使用していた証明書を使用することもできます。ただし、リリース 2 でサポートされない Global Site ID は使用できません。

1. Wallet を使用できるように、Oracle9iAS Web Cache を設定します。

2. initArgs の新しい形式を使用して Parallel Page Engine（PPE）を設定します。

関連項目関連項目関連項目関連項目 : 『Oracle9iAS Web Cache 管理および配置ガイド』

関連項目関連項目関連項目関連項目 : 4-6 ページの例 4-2「リリース 9.0.2 形式の initArgs パラメータ」



図図図図 4-1 Oracle9iAS Portal におけるにおけるにおけるにおける SSL 接続接続接続接続

図 4-1 に、Portal のページをレンダリングするときの通信ルートを示します。それぞれのSSL 接続ポイントについて、次に説明します。

ブラウザからブラウザからブラウザからブラウザから Web Cache へのへのへのへの SSL 接続接続接続接続

Portal のページに対するリクエストはこの接続で処理されます。 Web Cache リスナー上で SSL 証明書によって保護されます。

Web Cache からからからから Oracle9iAS の中間層への接続の中間層への接続の中間層への接続の中間層への接続

ポート番号の設定によって、リクエストが Web Cache サーバーをバイパスする場合があります。そのため、SSL 通信を行うことができるように Oracle9iAS を設定する必要があります。

Parallel Page Engine（（（（PPE）から）から）から）から Web Cache への接続への接続への接続への接続

Web Cache が保護されている場合、この通信経路は安全です。しかし、PPE が SSL の使用を認識できるようにするための設定を行う必要があります。

証明書と証明書と証明書と証明書と HTTPS を使用するポートの保護を使用するポートの保護を使用するポートの保護を使用するポートの保護

HTTPS の場合、ポートに証明書を使用することによって、セキュリティを向上させることができます。この設定を行うには、$ORACLE_HOME_2/j2ee/OC4J/applications/portal/portal/WEB_INF/web.xmlweb.xmlファイルを編集します。

すべてのポートで常時使用できるように HTTPS を設定する必要があります。 Parallel Page Engine が、HTTPS の下でどのポートが操作されているかを認識できるようにする必要があります。

関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server セキュリティ・ガイド』、『Oracle9i Application Server 管理者ガイド』

WebCache

HTTPS HTTPS

Oracle9iASの中間層

Portalブラウザ

PPE

Oracle HTTP Servermod_ossl



web.xml ファイルに次の設定を追加します。

<init-param><param-name>httpsports</param-name><param-value>433:444</param-value></init-param>

ポート番号 433 および 444 は、使用している HTTPS のポート設定に変更してください。サーバーにはポートが 1 つあれば十分です。この例でポートを 2 つ指定しているのは、複数のエントリがある場合の構文を示すためです。ここに指定する各ポートは HTTPS プロトコルを使用し、そのポートに対して Oracle HTTP Server で証明書を作成する必要があります。

Portal の移行に関するトラブルシューティングとヒントの移行に関するトラブルシューティングとヒントの移行に関するトラブルシューティングとヒントの移行に関するトラブルシューティングとヒントこの項では、移行した Portal が適切に機能するために必要な、構成の設定やファイルについて説明します。問題が発生した場合は、この項で説明している条件を満たしているかどうか確認してください。

リリースリリースリリースリリース 1 のイメージ・ファイルを使用するためののイメージ・ファイルを使用するためののイメージ・ファイルを使用するためののイメージ・ファイルを使用するための Oracle9iAS リリースリリースリリースリリース2（（（（9.0.2）の構成）の構成）の構成）の構成Oracle9iAS リリース 1（1.0.2.2.x）で使用していたすべての静的な Oracle Portal イメージ・ファイルを、Oracle9iAS リリース 2（9.0.2）で使用できるようにするには、$ORACLE_HOME/Apache/Apache/conf/httpd.confを次のように変更します。

# Configuration information added for Oracle Portal 3.0.9 Alias /help/ "/physical/location/of/your/3.0.9/help/files" Alias /images/ "/physical/location/of/your/3.0.9/image/files " <Directory "/physical/location/of/your/3.0.9/image/files" > AllowOverride None Order allow,deny Allow from all ExpiresActive on ExpiresDefault A28800 <Files *> Header set Surrogate-Control 'max-age=2592000' </Files> </Directory> <Directory "/physical/location/of/your/3.0.9/help/files" > AllowOverride None Order allow,deny Allow from all ExpiresActive on ExpiresDefault A28800 <Files *>


Oracle Ultra Search の移行

Header set Surrogate-Control 'max-age=2592000' </Files> </Directory>

Portal EAR ファイルの確認ファイルの確認ファイルの確認ファイルの確認portal.earファイルが、$ORACLE_HOME_2/j2ee/OC4J_Portal/applicationsの下にあることを確認します。そうでない場合は、Oracle9iAS のインストール時に適切なオプションが選択されなかったことを示します。別の場所に portal.earファイルがある場合は、このファイルをコピーまたは移動して、正しい場所に置いてください。Oracle9iAS を再インストールする必要はありません。

JNI キャッシュ・ライブラリがアクセス可能であることの確認キャッシュ・ライブラリがアクセス可能であることの確認キャッシュ・ライブラリがアクセス可能であることの確認キャッシュ・ライブラリがアクセス可能であることの確認JNI キャッシュ・ライブラリの wwjni.jarが $ORACLE_HOME_2/portal/jlibにあり、JNI キャッシュ・ライブラリを使用できるように OC4J が構成されていることを確認します。特に、次の行が $ORACLE_HOME_2/j2ee/home/config/application.xmlに含まれることを確認してください。

"<library_path="../../../lib" />

この行に示されるパスは、wwjni.jarが格納されている場所へのパスです。そうでない場合は、Oracle9iAS のインストール時に適切なオプションが選択されなかったことを示します。別の場所に portal.earファイルがある場合は、このファイルをコピーまたは移動して、正しい場所に置いてください。Oracle9iAS を再インストールする必要はありません。

Oracle Ultra Search の移行の移行の移行の移行Oracle Ultra Search リリース 9.0.1 から Oracle Ultra Search リリース 9.0.2 に移行するには、移行スクリプトを実行し、いくつかの操作を手動で実行する必要があります。

Ultra Search の移行スクリプトでは、現在のシステムのバージョンを調べた後に、ユーザー・データを移行します。ユーザー・データには、メタデータ、データ・ソース、マッピング、データ収集スケジュール、認証および問合せ統計など、ディクショナリおよびテーブル・データがすべて含まれます。

リリース 9.0.1 で作成されたすべてのデータ収集スケジュールやジョブは、データとシステムを移行する前に無効になります。移行が完了した後で、データ収集スケジュールを再び有効にすると、ドキュメントに索引が再度作成されます。システムを再構成したり、データを再入力する必要はありません。移行後も、以前のリリースで収集され索引が作成されたドキュメントを検索できます。



UltraSearch の移行方法の移行方法の移行方法の移行方法UltraSearch のユーザー・データを移行するには、2 つの方法があります。 1 つはインプレースに移行する方法で、もう 1 つは ETL（抽出、ロードおよび変換）による移行です。

インプレース移行インプレース移行インプレース移行インプレース移行インプレースなアプローチで移行するには、次の手順を実行します。

1. 移行中にハードウェアに障害が発生してもロールバック機能がないため、データベースのバックアップを作成します。

2. SQL スクリプトの ULTRASEARCH_HOME/admin/wk0upgrade.sqlを実行します。このスクリプトを実行するには、次のパラメータを入力する必要があります。

� SYSPW: ユーザー SYS のパスワード

� WKSYSPW: ユーザー WKSYS のパスワード

� HOST: データベースのホスト・マシン

� PORT: データベースのポート番号

� ORACLE_SID: データベースの SID

� WK_TABLESPACE: Ultra Search が使用できる表領域

� WK_TEMPTABLESPACE: 一時表領域

� CONN_STRING: データベース接続文字列

� ORACLE_HOME: Oracle ホームのパス

� JAVA_EXE_PATH: Java 実行可能ファイルのパス

� PATH_SEPARATOR: Java クラスパスのセパレータ。UNIX の場合は : （コロン）、Windows の場合は ;（セミコロン）を使用します。

このスクリプトにより、次の処理が実行されます。

1. ユーザー・データをバックアップします。

2. リリース 9.0.1 のデータベース・オブジェクトをアンインストールします。

3. リリース 9.0.2 のデータベース・オブジェクトをインストールします。

4. ユーザー・インスタンスを再作成します。

5. データを復元します。

3. データ収集スケジュールをアクティブ状態に戻すため、Ultra Search 管理ツールを使用して索引を再作成します。



ELT（抽出、ロードおよび変換）による移行（抽出、ロードおよび変換）による移行（抽出、ロードおよび変換）による移行（抽出、ロードおよび変換）による移行ETL によるアプローチで移行するには、次の手順を実行します。

1. 新しい Oracle ホームにリリース 9.0.2 をインストールします。古いリリースと同じコンピュータ上でも別のコンピュータ上でもどちらでも可能です。

2. 新しい Oracle ホームで、ユーザー・インスタンス・スキーマと関連するデータベース・オブジェクトを再作成します。リリース 9.0.1 で作成された表のデータ・ソースに対して、元表がローカル・データベースにある場合は、その元表をリリース 9.0.2 の新しいデータベースにコピーする必要があります。表データ・ソースの元表がリモート・データベース表に設定されている場合は、リリース 9.0.2 の新しいデータベースからそのリモート・データベースへのリンクを再作成する必要があります。

3. SQL スクリプトの ULTRASEARCH_HOME/admin/wk0migrate.sqlを実行します。このスクリプトを実行するには、次のパラメータを入力する必要があります。

� WKSYSPW: ユーザー WKSYS のパスワード

� CONN_STRING: データベース接続文字列

� SRC_WKSYSPW: リリース 9.0.1 データベースのユーザー WKSYS のパスワード

� SRC_CONN_STRING: ソース・データベース接続文字列

このスクリプトにより、次の処理が実行されます。

1. ユーザー・インスタンスを再作成します。

2. データを復元します。

4. データ収集スケジュールをアクティブ状態に戻すため、Ultra Search 管理ツールを使用して索引を再作成します。

注意注意注意注意 : 新しいシステムが同じコンピュータ上にある場合は、データベース・リスナーのポートが、リリース 9.0.1 のデータベース・リスナーのポートと同じものにならないように設定する必要があります。別のポートを指定することによって、新旧の両方のデータベースが同時にリスニングできます。



移行ログ移行ログ移行ログ移行ログwk0upgrade.sqlを実行してインプレース移行を行う場合と、wk0migrate.sqlを実行して ETL 移行を行う場合は、移行スクリプトの実行結果がログに記録されます。次の項目がログ・ファイルに記録されます。

� 現行の実行手順

� ストアド・プロシージャによって生成されたエラー・メッセージ

� バックアップされたデータ・レコードの数

� コピーまたは移行されたデータ・レコードの数

インプレース移行で作成されるログ・ファイル名は次のとおりです。

ULTRASEARCH_HOME/admin/wk0upgrade.log

ETL 移行で作成されるログ・ファイル名は次のとおりです。

ULTRASEARCH_HOME/admin/wk0migrate.log


Wireless コンポーネントの

5
Wireless コンポーネントの移行コンポーネントの移行コンポーネントの移行コンポーネントの移行
この章では、Wireless コンポーネントの移行に必要な構成ファイル、アプリケーション配布ファイルおよびメタデータ・スキーマの変更方法について説明します。この章の項は次のとおりです。

� Oracle9iAS Wireless の移行

� 移行の範囲

� 移行パス

� 複数の中間層を使用した移行

移行 5-1

Oracle9iAS Wireless の移行

Oracle9iAS Wireless の移行の移行の移行の移行この項では、Oracle9iAS Wireless を Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iAS リリース 2（9.0.2）に移行する方法について説明します。

移行の範囲移行の範囲移行の範囲移行の範囲Oracle9i Application Server リリース 1.0.2.2.0 からリリース 2（9.0.2）に移行するには、次の変更が必要です。

� データベース・スキーマの移行データベース・スキーマの移行データベース・スキーマの移行データベース・スキーマの移行 : データベース・スキーマは、このリリースにおいて大幅に変更および拡張されています。

� モデル・オブジェクトの移行モデル・オブジェクトの移行モデル・オブジェクトの移行モデル・オブジェクトの移行 : 新しいモデル・オブジェクトが導入され、スキーマが変更されたため、モデル・オブジェクトを変更します。スクリプト up111-200.xmlを使用して、データベース・スキーマを移行します。次のグループのモデル・オブジェクトが影響を受けます。

� グループ

� ロール

� ユーザー

� サービス・リスト

� トランスフォーマ

� 論理デバイス

� アダプタ

ユーザー・エージェント・プロパティ・ファイルからデータベースへの移行ユーザー・エージェント・プロパティ・ファイルからデータベースへの移行ユーザー・エージェント・プロパティ・ファイルからデータベースへの移行ユーザー・エージェント・プロパティ・ファイルからデータベースへの移行

以前のリリースでは、HTTP ユーザー・エージェント・ヘッダーから論理デバイスへのマッピングは、プレーン Java プロパティ・ファイルに格納されていました。このリリースでは、このマッピングがデータベースに格納されます。したがって、マッピング情報を Java プロパティ・ファイルからデータベースに移行する必要があります。

テーブル・スキーマの変更に伴うトランスフォーマのアップグレードテーブル・スキーマの変更に伴うトランスフォーマのアップグレードテーブル・スキーマの変更に伴うトランスフォーマのアップグレードテーブル・スキーマの変更に伴うトランスフォーマのアップグレード

リリース 2（9.0.2）では、トランスフォーマと論理デバイスの間の永続表現が変更されたため、個別の Java プログラムを使用して新しいテーブル・スキーマにアップグレードします。

警告警告警告警告 : 移行アクティビティを開始する前に、必ずリポジトリをバック移行アクティビティを開始する前に、必ずリポジトリをバック移行アクティビティを開始する前に、必ずリポジトリをバック移行アクティビティを開始する前に、必ずリポジトリをバックアップしてください。アップしてください。アップしてください。アップしてください。



サイトとノードの構成プロパティからデータベースへの移行サイトとノードの構成プロパティからデータベースへの移行サイトとノードの構成プロパティからデータベースへの移行サイトとノードの構成プロパティからデータベースへの移行

Oracle9iAS Wireless 1.0.2.2.0 の Java プロパティ・ファイルに格納されているサイトおよびノードの構成プロパティを、データベースに移行する必要があります。

panama ユーザー・テーブルからユーザー・テーブルからユーザー・テーブルからユーザー・テーブルから OID への移行への移行への移行への移行

panamaユーザー・テーブルに格納されているユーザー情報を OID に移行する必要があります。

移行パス移行パス移行パス移行パスこの項では、Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iAS リリース 2（9.0.2）に移行する方法を説明します。ここでは、Oracle 9iAS の以前のリリースとは異なる ORACLE_HOME にリリース 2（9.0.2）をインストールするものと仮定します（新しくインストールする際は、別の ORACLE_HOME が必要です）。

1. リポジトリをバックアップします。

2. インプレース・リポジトリ・アップグレードを行う場合は、Oracle9iAS Wireless リリース 9.0.2 ソフトウェアを新規としてインストールします（インプレース・リポジトリ・アップグレードによって、既存のデータベースを Wireless スキーマ・リポジトリとして引き続き使用できます。ただし、インプレース移行を実行してリポジトリを移行することをお薦めします）。リポジトリ・アップグレードは、Oracle9iAS Wireless インフラストラクチャ・リポジトリの一部分としての新規リポジトリではなく、現行のリポジトリで実行します。

開始前の処理開始前の処理開始前の処理開始前の処理1. 新しくインストールした Oracle9iAS Wireless リリース 9.0.2 の場所および $ORACLE_

HOME_2/JDK を個々に指定するため、環境変数 ORACLE_HOME JAVA13_HOME を設定します。

2. Oracle9iAS Wireless リリース 1.0.2.2.0 のリポジトリ・データベースに対応する、指定サービス・エントリを作成します（tnsnames.oraにエントリが存在しない場合）。

重要重要重要重要 : Oracle9i Application Server リリース 1.0.2.2 のデータベースには、8.1.7.1.0 以降のパッチセットを必ず適用してください。このパッチを適用しないと、移行後に SSO サーバーが正常に動作しなくなります。

Wireless コンポーネントの移行 5-3


インプレース移行インプレース移行インプレース移行インプレース移行インプレース移行を完了するには、Wireless プロビジョニング・プロファイル・エントリを削除する必要があります。

Wireless ポストインストーラによって、OID のデフォルト Wireless スキーマを指定するプロビジョニング・プロファイル・エントリが作成されます。インプレース移行では、次のスクリプトを実行して、このエントリを削除する必要があります。

ORACLE_HOME/bin/oidprovtool operation=delete ldap_host=<ldap_host> ldap_port=<ldap_port> ldap_user_dn='cn=orcladmin'ldap_user_password=<password of cn=orcladmin> application_dn='orclApplicationCommonName=Wireless1, cn=Wireless, cn=Products,cn=OracleContext' organization_dn=<default subscriber dn>

たとえば、次のようになります。

oidprovtool operation=delete ldap_host=hrawat-sun ldap_port=389 ldap_user_dn='cn=orcladmin' ldap_user_password='welcome1' application_dn='orclApplicationCommonName=Wireless1, cn=Wireless, cn=Products,cn=OracleContext' organization_dn='o=DEFAULT SUBSCRIBER, dc=COM'

重要重要重要重要 : Oracle9i Application Server リリース 2（9.0.2）の OC4Jインスタンスを必ずシャットダウンしてください。シャットダウンするには、Oracle9i Application Server リリース 2（9.0.2）の$ORACLE_HOME_2/opmn/binディレクトリから、コマンドopmnctl stopallを発行します。ただし、Oracle Enterprise Manager デーモンは稼動させておく必要があります。このデーモンを起動するには（まだ稼動していない場合）、Oracle9i Application Server リリース 2（9.0.2）の $ORACLE_HOME_2/binから、emctl startを実行します。

注意注意注意注意 : コマンドは単一行に入力してください。



新旧のリリースが同じコンピュータにインストールされている場合新旧のリリースが同じコンピュータにインストールされている場合新旧のリリースが同じコンピュータにインストールされている場合新旧のリリースが同じコンピュータにインストールされている場合

1. Oracle Enterprise Manager（EM）コンソールを使用して、Oracle9iAS Wireless リリース 1.0.2.2.0 のインストール環境のリポジトリ・データベースを指定するように、データベース・スキーマを変更します。

2. Oracle9iAS Wireless リリース 1.0.2.2.0 のリポジトリ・データベースに管理ユーザーとして接続し、$ORACLE_HOME_2/wireless/sql/aq_grants.sqlスクリプトを実行します。

次のコマンド構文を使用します。

sqlplus Adminuser/Adminpassword@SID @./aq_grants.sql ias10220_wireless_schemaname


sqlplus system/manager@0817 @./aq_grants.sql ptg102_user

3. Oracle9iAS Wireless リリース 2（9.0.2）の $ORACLE_HOME/wireless/upgradeディレクトリで、スクリプト ptgUpgrade.shまたは ptgUpgrade.bat（Windows の場合）を実行して、Oracle9iAS Wireless 1.0.2.2.0 の $ORACLE_HOME、Oracle9iAS Wireless 1.0.2.2.0 の接続文字列および Oracle9iAS Wireless リリース 2（9.0.2）の$ORACLE_HOME を指定します。たとえば、次のようになります。


ptgUpgrade.sh old_oracle_home old_connect_str new_oracle_home admin_user admin_passwd [host port https_port NT only]


ptgUpgrade.sh /private/wireless1022 ptg1022_user/ptg1022_passwd@wirelessdbservicename /private/iasv2 orcladmin welcome1

Windows NT の場合は、次のようになります。

ptgUpgrade.bat d:¥wireless1022 ptg1022_user/ptg1022_passwd@wirelessdbservicename d:¥iasv2 orcladmin welcome1 iasv2.mydomain.com 7778 4443

関連項目関連項目関連項目関連項目 : 『Oracle Enterprise Manager 構成ガイド』、『Oracle Enterprise Manager 管理者ガイド』および『Oracle Enterprise Manager 概要』



4. モバイル・ゲートウェイの URL を Oracle Portal に登録する必要があります。この処理は、Oracle Portal を有効化したり構成する場合にのみ必要です。次に示すように、Oracle9iAS Wireless リリース 9.0.2 の $ORACLE_HOME_2/wireless/sampleディレクトリで、portalRegistrar.sh（または portalRegistrar.bat）スクリプトを実行します。

portalRegistrar.sh ias_admin_user device_portal_url


portalRegistrar.sh orcladmin http://upgradedv2machine.mycompany.com:7777/ptg/rm

5. 新しくアップグレードしたデータベース・リポジトリを指定するように、Oracle Enterprise Manager ファイル $ORACLE_HOME_2/sysman/emd/targets.xmlを編集します。 oracle_wirelessに対応するターゲット・エントリに、次の太字で示している変更を加えます。

<Property NAME="ConfigDBPort" VALUE="port number of upgraded database"/><Property NAME="ConfigDBpassword" VALUE="schema password of upgraded database" ENCRYPTED="FALSE"/><Property NAME="MachineName" VALUE="machine name of upgraded database"/><Property NAME="ConfigDBSID" VALUE="SID of upgraded database"/><Property NAME="ConfigDBMachineName" VALUE="machine name of upgraded database"/><Property NAME="UserName" VALUE="schema name of upgraded database" ENCRYPTED="FALSE"/><Property NAME="Port" VALUE="port number of upgraded database"/><Property NAME="SID" VALUE="SID of upgraded database"/><Property NAME="ConfigDBUserName" VALUE="schema name of upgraded database" ENCRYPTED="FALSE"/><Property NAME="ORACLE_HOME" VALUE="no modification required"/><Property NAME="password" VALUE="schema password of upgraded database" ENCRYPTED="FALSE"/><Property NAME="host" VALUE="fully qualified host name of wireless middle tier"/>

注意注意注意注意 : ptgUpgrade スクリプトの実行中に、「一意性制約違反」というメッセージが数回表示される場合があります。このメッセージは無視してください。これは、新しいブートストラップ・ファイルに、既存のユーザー・エージェント・エントリと競合するユーザー・エージェント・エントリが含まれているために発生します。



新旧のリリースが個別のコンピュータにインストールされている場合新旧のリリースが個別のコンピュータにインストールされている場合新旧のリリースが個別のコンピュータにインストールされている場合新旧のリリースが個別のコンピュータにインストールされている場合

Oracle9iAS Wireless 1.0.2.2.0 がコンピュータ mc1 にインストールされていて（リポジトリ・データベースは db1）、Oracle9iAS Wireless リリース 2（9.0.2）がコンピュータ mc2 にインストールされている（リポジトリ・データベースは db2）場合は、次の手順に従います。

1. EM コンソールを使用して、Oracle9iAS Wireless 1.0.2.2.0 のインストール環境のリポジトリ・データベースを指定するように、データベース・スキーマを変更します。

2. Oracle9iAS Wireless 1.0.2.2.0 のリポジトリ・データベースに管理ユーザーとして接続し、$ORACLE_HOME_2/wireless/sql/aq_grants.sqlスクリプトを実行します。


sqlplus Adminuser/Adminpassword@SID @./aq_grants.sql ias10220_wireless_schemaname


sqlplus system/manager@0817 @./aq_grants.sql ptg102_user

3. ディレクトリ構造 $ORACLE_HOME_1/panama/server/classesの全体をマシン mc1から一時ディレクトリにコピーした後、<temporary directory>/panama/server/classes/oracle/panama/spatial/spatial.propertiesファイルを開いて、各プロパティのプレフィックス（<OLD ORACLE HOME>に相当するパス）を一時ディレクトリの絶対パスで置き換えます。

たとえば、一時ディレクトリが /tmpである場合は、/tmp/panama/server/classes/oracle/panama/spatial/spatial.propertiesのファイルを開いて、file.providers.config.xml.geocoding = /private/ias/10220PME/panama/server/classes/oracle/panama spatial/geocoder/Geocoders.xml（/private/ias/10220PMEは OLD_ORACLE_HOMEに相当するパス）という部分をfile.providers.config.xml.geocoding = /tmp/panama/server/classes/oracle/panama/spatial/geocoder/Geocoders.xmlに変更します。

4. mc2 で ptgUpgrade.shスクリプトを実行し、コピーした一時ディレクトリの場所、Oracle9i Application Server リリース 1.0.2.2.0 の接続文字列および Oracle9i Application Server リリース 2（9.0.2）の $ORACLE_HOME. を指定します。たとえば、次のようになります。

ptgUpgrade.sh /tmp ptg1022_user/ptg1022_passwd@wirelessdbservicename /private/iasv2

Windows の場合は、次のようになります。

ptgUpgrade.bat d:¥temp ptg1022_user/ptg1022_passwd@wirelessdbservicename d:¥iasv2 orcladmin welcome1 iasv2.mydomain.com 7778 4443



5. モバイル・ゲートウェイの URL を Oracle Portal に登録する必要があります。この処理は、Oracle Portal を有効化したり構成する場合にのみ必要です。次に示すように、Oracle9iAS Wireless リリース 9.0.2 の $ORACLE_HOME/wireless/sampleディレクトリで、portalRegistrar.sh（または portalRegistrar.bat）スクリプトを実行します。

portalRegistrar.sh ias_admin_user device_portal_url


portalRegistrar.sh orcladmin http://upgradedv2machine.mycompany.com:7777/ptg/rm

6. 新しくアップグレードしたデータベース・リポジトリを指定するように、Oracle Enterprise Manager のターゲット・ファイルを変更する必要があります。このファイルを変更するには、Oracle9iAS Wireless リリース 9.0.2 の $ORACLE_HOME/sysman/emdにあるファイル targets.xmlを編集します。oracle_wirelessに対応するターゲット・エントリに次の変更（太字太字太字太字で示している部分）を加えます。

<Property NAME="ConfigDBPort" VALUE="port number of upgraded database"/><Property NAME="ConfigDBpassword" VALUE="schema password of upgraded database" ENCRYPTED="FALSE"/><Property NAME="MachineName" VALUE="machine name of upgraded database"/><Property NAME="ConfigDBSID" VALUE="SID of upgraded database"/><Property NAME="ConfigDBMachineName" VALUE="machine name of upgraded database"/><Property NAME="UserName" VALUE="schema name of upgraded database" ENCRYPTED="FALSE"/><Property NAME="Port" VALUE="port number of upgraded database"/><Property NAME="SID" VALUE="SID of upgraded database"/><Property NAME="ConfigDBUserName" VALUE="schema name of upgraded database" ENCRYPTED="FALSE"/><Property NAME="ORACLE_HOME" VALUE="no modification required"/><Property NAME="password" VALUE="schema password of upgraded database" ENCRYPTED="FALSE"/><Property NAME="host" VALUE="fully qualified host name of wireless middle tier"/>

注意注意注意注意 : ptgUpgrade スクリプトの実行中に、「一意性制約違反」というメッセージが数回表示される場合があります。これらは無視してもかまいません。これは、新しいブートストラップ・ファイルに、既存のユーザー・エージェント・エントリと競合するユーザー・エージェント・エントリが含まれているために発生します。



リポジトリの移行リポジトリの移行リポジトリの移行リポジトリの移行

Oracle9iAS Wireless リリース 9.0.2 のインフラストラクチャ層の一部としてインストールしたデータベースに、現行のデータベースのデータを移行する場合は、リポジトリを移行します。リポジトリを移行すると、現行のデータベースが使用されなくなります。

1. expを使用して、既存のデータベース情報をエクスポートします。たとえば、次のようになります。

exp system/manager owner=ptg102_user file=exported.dmp log=exported.log

出力ファイル exported.dmpが作成されます。

2. Oracle9iAS Wireless リリース 1.0.2.2.0 のリポジトリ・データベースに管理ユーザーとして接続し、$ORACLE_HOME_2/wireless/sql/create_aq_userスクリプトを使用して、新しいスキーマを作成します。たとえば、次のようになります。

SQL>@create_aq_user.sql ptg20_user welcome

3. 新しいユーザー名（ptg20_user）およびパスワード（welcome）を使用して、新しく作成したユーザーとして接続します。たとえば、次のようになります。

SQL> connect pt20_user welcome

4. create_all SQLスクリプトを実行します。たとえば、次のようになります。

SQL> @create_all.sql

5. EM コンソールを使用して、この新しいスキーマを指定するように Wireless の接続文字列を変更します。

6. Oracle9i データベースが別のコンピュータにある場合、FTP を使用して、exported.dmpファイルをそのコンピュータに置きます。

7. impを使用して、Oracle9i データベースをインポートします。たとえば、次のようになります。

imp system/manager fromuser=ptg102_user touser=ptg20_user file=exported.dmp commit=y ingore=n log=imported.log

注意注意注意注意 : AQ が使用しているオブジェクト・タイプによっては、オブジェクト ID の妥当性チェックに失敗する場合があります。（Oracle インポート・ユーティリティを使用しているときに）失敗した場合、TOID_NOVALIDATE パラメータを使用して、そのオブジェクト・タイプの妥当性チェックを無効化することを検討してください。

commit=yと設定すると、冗長なロールバック処理を回避できるため、パフォーマンスが向上します。



8. Oracle9iAS Wireless リリース 1.0.2.2 および Oracle9iAS Wireless リリース 9.0.2 のインストール先が同じコンピュータなのか個別のコンピュータなのかにより、「新旧のリリースが同じコンピュータにインストールされている場合」または「新旧のリリースが個別のコンピュータにインストールされている場合」の手順に従ってアップグレードします。

ユーザーの移行ユーザーの移行ユーザーの移行ユーザーの移行Single Sign On をサポートするために、Wireless リポジトリに格納されているユーザー情報を、Oracle9iAS Wireless インフラストラクチャの一部である Oracle Internet Directory

（OID）に移行する必要があります。

インプレース移行であってもリポジトリ移行であっても、また、Oracle9i Application Server リリース 1（1.0.2.2）とリリース 2（9.0.2）が同じコンピュータにインストールされていても、異なるコンピュータにインストールされていても、この手順は必ず実行してください。

Oracle Internet Directory では、可能なパスワード・ハッシング・スキームがすべてサポートされているわけではありません。現在サポートされているスキームには、MD4、MD5、SHA および Unix Crypt が含まれています。サポートされているパスワード・ハッシング・スキームの総合リストは、『Oracle Internet Directory 管理ガイド』の付録 F を参照してください。サポートされていないパスワード・ハッシング・スキームを扱う場合も、同マニュアルの同項を参照してください。

ユーザーを Oracle Internet Directory に移行する前に、Oracle Internet Directory のデフォルトのパスワード・ハッシング・スキームを、Oracle9iAS Wireless 1.0.2.2 で使用するスキームに変更する必要があります。この手順を実行するには、『Oracle Internet Directory 管理ガイド』の第 17 章「ユーザー認証資格証明のディレクトリ格納」を参照してください。

1. OID のデフォルト・サブスクライバのパスワード・ポリシーを変更します。

OID のサブスクライバ用であるデフォルトのパスワード・ポリシーでは、5 文字以上で数字を少なくとも 1 つ含むユーザー・パスワードを設定する必要があります。既存ユーザーを OID にアップロードする前に、既存ユーザーのパスワードがサブスクライバのパスワード・ポリシーに準拠するように、デフォルト・サブスクライバのパスワード・ポリシーを変更する必要があります。パスワード・ポリシーの詳細は、『Oracle Internet Directory 管理ガイド』の第 18 章「パスワード・ポリシー」を参照してください。

2. ユーザーをデータベース・リポジトリから OID に移行するには、Oracle9i Application Server リリース 2（9.0.2）がインストールされているマシンで、ptgUpgradeRepository.sh（またはオペレーティング・システムに応じて、ptgUpgradeRepository.bat）を実行します。

注意注意注意注意 : Oracle9iAS リリース 2（9.0.2）では、ユーザー情報は OID に格納されます。OID では、ユーザー名の大文字 / 小文字が区別されません。これとは異なり、以前のバージョンの Oracle9iAS Wireless では、ユーザー名の大文字 / 小文字が区別されます。




ptgUpgradeRespoitory.sh ldap_host ldap_port ldap_dn ldap_password subscriber_name connect_str

各パラメータの説明は、次のとおりです。

� ldap_hostは、OID サーバーの場所です。

� ldap_portは、OID サーバーのポートです。

� ldap_dnは、OID 管理ユーザーの DN です。

� ldap_passwordは、OID 管理ユーザーのパスワードです。

� subscriber_nameは、インストール時に指定したサブスクライバ名です。デフォルトでは、Oracle9iAS がインストールされているマシンの DNS ドメイン名になります。

� connect_strは、旧データベース・スキーマへの接続文字列です（フォーマットは、user/password@machine_name.domain:port:sid）。


ptgUpgradeRepository.sh myhost.mydomain 389 'cn=orcladmin' welcome1 'mySubscriberName' ptg102_user/[email protected]:1521:o817

カスタマイズを移行するための追加手順カスタマイズを移行するための追加手順カスタマイズを移行するための追加手順カスタマイズを移行するための追加手順次に示す手順は、なんらかのカスタマイズをフック形式で Oracle9i Application Server リリース 1.0.2.2 に導入していた場合にのみ実行します。

1. フックのクラスをコンピュータ mc2 にコピーし、$ORACLE_HOME_2/j2ee/OC4J_wireless/config/application.xmlファイルを変更して、コピーしたクラスを指定するライブラリ・パス・ディレクティブを追加します（すなわち、そのクラスをサーバーのクラスパスに含めます）。

2. カスタマイズの一部としてアプリケーションまたはサーブレットが追加されており、移行が必要な場合は、既存のアプリケーションの移行に関する Oracle9iAS ドキュメントを参照してください。



複数の中間層を使用した移行複数の中間層を使用した移行複数の中間層を使用した移行複数の中間層を使用した移行複数の中間層を使用して、既存のインストール環境を Oracle9i Application Server リリース2（9.0.2）に移行することも可能です。ただし、移行スクリプトはいずれか 1 つの中間層から1 度しか実行できません。複数の中間層を使用して、Oracle9i Application Server リリース1.0.2.2 のインスタンスを Oracle9i Application Server リリース 2（9.0.2）インストールに移行するには、一般的に次の手順に従います。

1. Oracle9i Application Server リリース 2（9.0.2）のインフラストラクチャ層をインストールします。

2. Oracle9i Application Server リリース 2（9.0.2）の中間層を、このインフラストラクチャ層の指定に必要な数だけインストールします。

3. Oracle9i Application Server リリース 1.0.2.2 のインスタンスを任意の 1 つの中間層からアップグレードします。

4. Enterprise Manager コンソールを使用して、アップグレードされたデータベースおよびリポジトリを指定するように、各中間層のスキーマを変更します。

5. 「新旧のリリースが同じコンピュータにインストールされている場合」または「新旧のリリースが個別のコンピュータにインストールされている場合」の説明に従って、各中間層インスタンスの targets.xmlファイルを編集します。

注意注意注意注意 : 移行プロセスの完了後、中間層およびインフラストラクチャ層にあるすべてのサーバーを再起動する必要があります。


Business Intelligence コンポーネントの

6
Business Intelligence コンポーネントの移行コンポーネントの移行コンポーネントの移行コンポーネントの移行
この章では、Business Intelligence コンポーネントの移行に必要な構成ファイル、アプリケーション配布ファイルおよびメタデータ・スキーマの変更方法について説明します。この章の主な項は次のとおりです。

� Oracle9i Forms Services の移行

� Oracle9iAS Reports Services の移行

� Oracle9iAS Discoverer の移行

� Oracle9iAS Personalization の移行

移行 6-1

Oracle9i Forms Services の移行

Oracle9i Forms Services の移行の移行の移行の移行Oracle9iAS リリース 2（9.0.2） Enterprise Edition には、Oracle9i Forms Services が含まれています。Oracle9iAS リリース 1（1.0.2.2.x）には、Forms6i Services が含まれています。この項では、Forms6i Services の配布を Oracle9iAS リリース 2（9.0.2）の Oracle9i Forms Services に移行する方法について説明します。

Oracle9iAS リリース 1（1.0.2.2.x）には、Forms6i Services が含まれており、次の配布オプションをサポートしています。

Web インタフェース

� 静的な HTML ファイル

� Common Gateway Interface（CGI）

� Forms Servlet

Forms Servlet のリクエスト・ディスパッチャ・タイプ（リスナー）

� Forms リスナー

� Forms Listener Servlet

Oracle9iAS リリース 2（9.0.2）では、これらのオプションのすべてをサポートしているわけではありません。 Oracle9i Forms Services では、Common Gateway Interface（CGI）が Webインタフェース・オプションではなく、Forms リスナーが Forms Web リクエストのオプションでもないためです。 Oracle9i Forms Services のアーキテクチャでは、次の Forms Services 配置オプションをサポートしています。

Web インタフェース

� Forms Servlet

リクエスト・ディスパッチャ（リスナー）

� Forms Listener Servlet

この項では、Forms Services を Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iAS リリース2（9.0.2）に移行する際に必要な手順について詳細に説明します。

この項は、次のサブ項目で構成されています。

� Forms6i Services のののの Common Gateway Interface（（（（CGI）から）から）から）から Forms Servlet への移行への移行への移行への移行

この項では、Forms CGI から Forms Servlet に移行するために必要な変更について説明します。 Forms Services の Common Gateway Interface を使用して、アプリケーション用の Forms アプレット起動 HTML ファイルを動的にレンダリングしている場合は、この手順に従います。



� Forms 6i の静的なの静的なの静的なの静的なHTML 起動ファイルから起動ファイルから起動ファイルから起動ファイルから Forms 9i の汎用アプリケーションの汎用アプリケーションの汎用アプリケーションの汎用アプリケーションHTML 起起起起動ファイルへの移行動ファイルへの移行動ファイルへの移行動ファイルへの移行

Forms6i Services で静的 HTML 配布ファイルを使用している場合は、この手順に従います。 Forms Servlet には管理およびアプリケーション配布をより簡単にする機能が用意されているため、Oracle9i Forms Services での静的 HTML 配布ファイルの使用はお薦めしません。

� Forms 6i リスナーからリスナーからリスナーからリスナーから Forms Listener Servlet への移行への移行への移行への移行

Web Forms ランタイム・プロセスの起動に Forms リスナーを使用している場合は、この手順に従います。 Forms リスナーは、Forms アプリケーション用の Web リクエストを、リスナーによって起動されるランタイム・プロセスにルーティングする C プログラムです。 Forms Listener Servlet も同様ですが、Java ですべて記述されています。この項では、リスナー・タイプ間の相違、およびアプリケーションを Forms リスナーからForms Listener Servlet に移行する方法について説明します。

� Forms Listener Servlet アーキテクチャからアーキテクチャからアーキテクチャからアーキテクチャから Oracle9i Forms Services への移行への移行への移行への移行

この項では、Oracle9i Forms Services での配布と Forms6i Services での配布の相違について説明します。

� ロード・バランシングの移行ロード・バランシングの移行ロード・バランシングの移行ロード・バランシングの移行

Forms6i Services でロード・バランシング（Forms Services のメトリック・サーバーまたは JServ エンジン・ロード・バランシング方法）を使用している場合は、この説明を参照してください。

� 使用上の注意使用上の注意使用上の注意使用上の注意

この項では、Forms6i Services から移行する際の Oracle9i Forms Services の構成と配布について説明します。この項には、次の内容が含まれています。

� 「Forms Servlet によるアイコン・イメージの配布」

� 「Reports Services を使用するための統合コールから Oracle9i Reports への移行」

� 「Forms Listener Servlet の OC4J での別名の作成」

� 「Forms Listener Servlet 管理ページへのアクセス」

� Oracle9i Forms Services への移行のベスト・プラクティスへの移行のベスト・プラクティスへの移行のベスト・プラクティスへの移行のベスト・プラクティス

この項では、Forms6i Services を Oracle9i Forms Services に移行する際のチェック・リストを示します。この時点では、Forms アプリケーションのソース・モジュールがすでに Forms 9i にアップグレード済であるようにしてください。

Business Intelligence コンポーネントの移行 6-3


Forms6i Services のののの Common Gateway Interface（（（（CGI）から）から）から）から Forms Servlet へへへへの移行の移行の移行の移行CGI は、Forms アプレット起動 HTML ファイルを動的にレンダリングするために、Forms6i Services に導入されました。 Forms CGI では、formsweb.cfg構成ファイルおよび HTMLテンプレートを使用して、アプリケーション固有の起動 HTML ファイルを作成します。 CGIインタフェースは、Oracle HTTP Server httpd.confファイルのエントリによって構成されています。このファイルは、ifcgi60.exeファイルを含むディレクトリ構造用のScriptAlias である dev60cgiを定義します。

Forms Servlet では、CGI と同様の方法で HTML をレンダリングしますが、Internet Explorer のネイティブ VM をサポートするブラウザ・タイプ自動検出機能も提供します。 Oracle9i Forms Services のサーブレットは、Oracle9iAS リリース 2（9.0.2） Enterprise Edition のインストール時に構成され、f90servletという名前が付けられます。

Forms Servlet にアクセスするには、次の URL をリクエストします。

http://<hostname>:port/forms90/f90servlet

この URL は、Forms6i Services で CGI インタフェースとともに使用する URL と類似しています。 forms90/serverディレクトリにある formsweb.cfgファイルのカスタム構成セクションに myappとして構成されているアプリケーションをコールするには、次の URL をリクエストします。

http://<hostname>:port/forms90/f90servlet?config=myapp

構成は、インストール時に自動的に行われます。インストーラにより、Oracle9iAS Containers for J2EE（OC4J）ホーム（<ORACLE_HOME>/j2ee/home）に、Oracle9i Forms Services リリース 2 の構成、forms90appおよび forms90webを指定する仮想パス/forms90/を作成します。

Forms6i Services の CGI 環境を Oracle9iAS リリース 2（9.0.2）で Oracle9i Forms Services のサーブレット環境に移行するには、次の手順に従います。

1. $ORACLE_HOME_1にある forms60/server/formsweb.cfgファイルからアプリケーション固有の構成をすべてコピーして、$ORACLE_HOME_2にあるforms90/server/formsweb.cfg ファイルに追加します。

2. 移行する Oracle9i Forms Services のアプリケーション・モジュールを指定するように、forms90/serverにある default.envファイルの FORMS90_PATHを構成します。

注意注意注意注意 : 9i ファイルは 6i ファイルとは異なるため、$ORACLE_HOME_2にある 9i formsweb.cfgファイルを $ORACLE_HOME_1 にある 6i formsweb.cfgファイルに置き換えることは、危険を伴ないます。アプリケーション構成の行を 6i ファイルから 9i ファイルにコピーしてください。



3. Forms 6i の HTML テンプレート・ファイルを変更した場合、同じ変更を Oracle9i Forms Services の HTML テンプレート・ファイルに加えます。

Forms 6i の静的なの静的なの静的なの静的な HTML 起動ファイルから起動ファイルから起動ファイルから起動ファイルから Forms 9i の汎用アプリケーの汎用アプリケーの汎用アプリケーの汎用アプリケーションションションション HTML 起動ファイルへの移行起動ファイルへの移行起動ファイルへの移行起動ファイルへの移行Oracle9i Forms Services によって配布される各アプリケーションには、formsweb.cfg構成ファイルで構成されたカスタム・アプリケーション定義が含まれています。この定義は、使用していた JInitiator のバージョン、ベース HTML テンプレート・ファイルの名前と場所など、一般的なシステム設定を自動的に継承します。

カスタム・アプリケーション定義の名前は、Forms URL の一部になります。次に、異なるアプリケーションを定義するカスタム設定の例を 2 つ示します。

[MyHR_app]IE=Jinit serverURL=/forms90/l90servlet form = hr_main.fmx lookAndFeel=Oracle otherparams=myParam1=12 userid=scott/tiger@orcl

このアプリケーションは、次の URL によって起動します。

http://<hostname>:<port>/forms90/f90servlet?config=MyHR_app

注意注意注意注意 : 独自の環境ファイルを作成することもできます。作成するには、default.envをコピーして、特定のアプリケーションで使用できるように変更し、envFile=作成した環境ファイルを formsweb.cfgファイルのカスタム・アプリケーション・セクションに追加します。

注意注意注意注意 : サーブレットでは JInitiator、Java プラグインおよび Internet Explorer のネイティブな VM をサポートしているため、3 つの HTML テンプレート・ファイル、すなわち basejini.htm、basejpi.htmおよびbaseie.htmをすべて変更する必要があります。



もう 1 つのカスタム・アプリケーション定義は、次のようになります。

[booking_app]IE=native serverURL=/forms90/l90servlet form = book.fmx lookAndFeel=Oracle otherparams= userid=

このアプリケーションは、次の URL によって起動します。

http://<hostname>:<port>/forms90/f90servlet?config=booking_app

静的な HTML ファイルごとに、カスタム・アプリケーション定義を 1 つ作成する必要があります。静的な HTML ファイルの一部として、少なくとも Oracle9i Forms Servicesの f90all.jarを保持する archiveパラメータが含まれます。カスタム・アーカイブ・ファイルを追加した場合、アーカイブ・パラメータ・ディレクティブは、archive=f90all.jar, custom.jarのようになります。 Forms Servlet およびformsweb.cfgファイルを使用すると、アーカイブ設定は「User Parameter」セクションで定義されます。すべてのカスタム・アプリケーション設定で、これらの値は継承されます。したがって、使用しているアプリケーションに要求される独自の custom.jarファイルを追加する場合を除き、このパラメータを明示的に設定する必要はありません。

custom.jarを追加した場合、カスタム・アプリケーション定義に次の行を追加します（この例では、JInitiator または IE ネイティブではない VM を使用しているものと仮定しています）。

[booking_app] archive_jini=f90all_jinit.jar, custom.jar archive=f90all.jar, custom.jar serverURL=/forms90/l90servlet form = book.fmx lookAndFeel=Oracle otherparams= userid=

移行するには、次の手順を実行します。

1. forms90/serverにある default.envファイルを編集して、Forms 9i アプリケーション・モジュールの場所を FORMS90_PATHに追加します。

2. forms90/server/formsweb.cfgファイルを編集して、置換する各静的 HTML アプリケーション・ファイル用のカスタム・アプリケーション・セクションを追加します。

3. 各カスタム・アプリケーション・セクションに名前を付けます。名前は [ ]（大カッコ）で囲みます。また、スペースを含めないでください（上記の例を参照）。



4. 次の URL を使用して、アプリケーションを起動します。

http://<hostname>:<port>/forms90/f90servlet?config=name

Oracle9i Forms Services のののの Forms で静的で静的で静的で静的 HTML ファイルを使用する場合ファイルを使用する場合ファイルを使用する場合ファイルを使用する場合必要に応じて、Oracle9iAS リリース 2（9.0.2）でも静的な HTML ファイルを引き続き使用できます。ただし、静的な HTML ファイルを使用した場合、その Forms アプリケーションでは、Single Sign On サポートなど、リリース 2 の機能の一部を使用できません。

Forms Listener Servlet は、インストール後、自動的に /forms90/l90servletにセットアップされます。静的な HTML ファイルをリリース 2 で使用するには、serverURL パラメータ用の値を含めるように、それぞれの静的な起動 HTML ファイルを変更する必要があります。 serverPortおよび serverHostは、使用されなくなったので未定義のまま残ります。Oracle9i Forms Services では、JInitiator バージョン 1.3.x を使用するため、その設定も変更する必要があります。必要な値は、/forms90/server/formsweb.cfgファイルにあります。

このように構成するには、次の移行手順に従います。

1. 移行する Oracle9i Forms Services のアプリケーション・モジュールを指定するように、forms90/server/default.envファイルの FORMS90_PATHを構成します。

2. 静的 HTML 起動ファイルの場所を指定するように、$ORACLE_HOME_2/Apache/Apache/conf/httpd.confファイルに仮想ディレクトリを作成します。

3. アプリケーション起動 HTML ファイルを次のように変更します。

a. serverURLの値 /forms90/l90servletを追加します。

b. JInitiator のバージョン番号を変更します。

4. コードベース・パラメータを forms90/javaに変更します。

5. $ORACLE_HOME_2/j2ee/OC4J_BI_Forms/applications/forms90app/form90web/WEB-INFに移動して、web.xmlファイルを編集します。

6. 環境ファイル（通常は、$ORACLE_HOME_2/forms90/server/default.env）を指定するように、Listener Servlet 用の envFile初期化パラメータを設定します。

編集後、web.xml ファイルにある Forms Listener Servlet 用のエントリは、例 6-1 に示しているような形式になります。


例例例例 6-1 web.xml にあるにあるにあるにある Forms リスナー・エントリリスナー・エントリリスナー・エントリリスナー・エントリ

<servlet> <servlet-name>l90servlet</servlet-name> <servlet-class>oracle.forms.servlet.ListenerServlet</servlet-class> <init-param> <param-name>envFile</param-name> <param-value>ORACLE_HOME_2/forms90/server/default.env</param-value> </init-param></servlet>

Forms 6i リスナーからリスナーからリスナーからリスナーから Forms Listener Servlet への移行への移行への移行への移行Forms 6i リスナーは、受信 Forms Web リクエストにかわって Forms ランタイム・プロセスを起動する C プログラムです Forms Web ランタイム・プロセスは、Forms アプレットによって直接アクセスされます。アクセス時は、ダイレクト・ソケットまたは HTTP ソケット接続のいずれかが使用されます。したがって、Forms リスナーが、アプリケーション Web クライアントとサーバー間の通信プロセスに関わることがなくなったため、ほかの受信 Webリクエストを処理できるようになります。

Java プログラムである Forms Listener Servlet も、Forms アプリケーションに対する受信Web リクエストを処理し、Forms サーバー側の Web ランタイム・プロセスを起動します。ただし、Forms リスナーとは異なり、Forms Listener Servlet は、Forms アプリケーションのアプレット - サーバー間通信に残ります。

Forms 6i リスナーによって特定のポート（デフォルトでは 9000）がリスニングされている間、Forms Servlet にはそれ以上のポートは必要なく、Forms Servlet 自体が HTTP リスナー・ポートによってアクセスされます。 Forms Listener Servlet は、Forms 6i のパッチ 4 に導入されており、Oracle9i Forms Services でサポートされている唯一のリスナーです。

Forms Listener Servlet は、インストール時に構成されます。

インストーラによって、Oracle9i Forms Services を指定する仮想パス /forms90/が作成されます。 Oracle9iAS Containers for J2EE（OC4J）は、サーブレット環境です。

次の URL を使用して、Oracle9i Forms Services 管理ページをリクエストします。

http://<hostname>:<port>/forms90/f90servlet/admin

このページには、Forms Listener Servlet が構成済で使用準備が整っていることが提示されます。f90servletは、インストール時に Forms Servlet 用に構成されたアクセス名です。 Forms Listener Servlet の名前は、l90servletです。

Forms Servlet を使用して Forms Listener Servlet にアクセスする場合は、Forms60/server/formsweb.cfgファイルにあるカスタム・アプリケーション設定を、Forms90/server/formsweb.cfgファイルに追加するだけです。すべてのアプリケーション構成では、serverURL パラメータの値 /forms90/l90servletをグローバル・システム・パラメータ設定から自動的に継承します。


Forms アプリケーションの配布を、Forms リスナーのアーキテクチャから Forms Listener Servlet のアーキテクチャに変更する際に必要な作業は、formsweb.cfgファイルにあるserverURL パラメータの値を提供することのみです。インストール時に、このパラメータは/forms90/l90servletに設定されます。


1. Forms アプリケーション・ファイルを新しいディレクトリにコピーして、それらをOracle9i Forms Services モジュールに移行します。

2. Forms90/server/default.envディレクトリにあるファイルを編集して、移行したOracle9i Forms Services のアプリケーション・モジュールの場所を FORMS90_PATH変数に追加します。

3. カスタム・アプリケーション設定を、Forms6i Services の formsweb.cfgファイルから、Oracle9i Forms Services の formsweb.cfgファイルにコピーします。

4. アプリケーション固有の環境ファイルが必要な場合は、その Forms Listener Servlet 用にサーブレット別名を定義するかわりに、その情報をアプリケーションのカスタム・アプリケーション定義セクションに追加します。たとえば、次のようになります。

envFile=myEnvFile.env

このとき、myEnvFile.envは、Forms90/serverディレクトリに配置されています。

5. Forms6i Services の HTML テンプレート・ファイルを変更した場合、同じ変更をOracle9i Forms Services の HTML テンプレート・ファイルに加えます。

注意注意注意注意 : 9i ファイルは 6i ファイルと異なるため、$ORACLE_HOME_2 にある 9i formsweb.cfgファイルを $ORACLE_HOME_1 にある 6i formsweb.cfgファイルに置き換えることは、お薦めできません。アプリケーション構成の行を 6i ファイルから 9i ファイルにコピーしてください。

注意注意注意注意 : 9i ファイルは 6i ファイルと異なるため、$ORACLE_HOME_2 にある 9i formsweb.cfgファイルを $ORACLE_HOME_1 にある 6i formsweb.cfgファイルに置き換えることは、お薦めできません。アプリケーション構成の行を 6i ファイルから 9i ファイルにコピーしてください。




http://hostname:port/forms90/90servlet?config=application

Forms Listener ServletアーキテクチャからアーキテクチャからアーキテクチャからアーキテクチャからOracle9i Forms Servicesへの移行への移行への移行への移行Forms6i Services では、別名が定義されていない Forms Listener Servlet は、oracle.forms.servlet.ListenerServletによってアクセスされます。 Forms Listener Servlet の構成は、jserv.propertiesファイルおよび zone.propertiesファイルに定義されています。

Oracle9i Forms Services でも、Forms Listener Servlet は同じです。ただし、サーブレット名は f90servletおよび l90servletとなり、また、サーブレット・コンテナは Oracle9iAS Containers for J2EE（OC4J）になります。リリース 1 と同様に、インストール時に構成されます。 OC4J の Forms Listener Servlet の構成は、<Forms_OC4J_Home>/applications/forms90app/forms90web/WEB-INF/web.xmlに格納されます。 envFile パラメータなど、初期化パラメータのなかには、formsweb.cfg ファイルに移行されるため、サーブレット・エンジンで構成する必要がないものもあります。

Oracle9iAS リリース 2（9.0.2）をインストールすると、Forms Listener Servlet が構成されます。

インストーラにより、Oracle9i Forms Services を指定する仮想パス /forms90/が作成されます。 Oracle9iAS Containers for J2EE（OC4J）は、サーブレット環境です。

インストール後、次の URL を使用して Oracle9i Forms Services 管理ページにアクセスします。

http://<hostname>:<port>/forms90/f90servlet/admin

注意注意注意注意 : 基礎となるベース HTML ファイルを変更する必要がある場合は、提供されているテンプレート・ファイルをコピーしてからファイルを編集してください。編集した HTML ファイルには別の名前を付けて保存し、インストール時に提供されたデフォルトのテンプレートは変更ぜすにそのまま保管しておきます。これによって、アプリケーションにパッチ・セットを適用しても、カスタム HTML テンプレート・ファイルは上書きされません。

独自のテンプレート・ファイルをアプリケーションで使用するには、そのシステム・セクションにあるこれらのパラメータ、もしくは次のカスタム・アプリケーション定義の 1 つを使用します。

baseHTML=your base template.htmbaseHTMLjinitiator=your base jinit.htmbaseHTMLie=your base ie.htm



このページには、Forms Listener Servlet が構成済であることが提示されます。f90servletは、インストール時に Forms Servlet 用に構成されたアクセス名です。Forms Listener Servlet の名前は、l90servletです。


1. Forms アプリケーション・ファイルを新しいディレクトリにコピーして、それらをForms 9i のモジュールに移行します。

2. forms90/server ディレクトリにある default.env ファイルを編集して、移行した Forms 9i のアプリケーション・モジュールの場所を FORMS90_PATH 変数に追加します。

3. Forms6i Services の formsweb.cfg ファイルにあるカスタム・アプリケーションの設定をコピーして、それを Forms 9i の formsweb.cfg ファイルに追加します。

4. アプリケーション固有の環境ファイルが必要な場合は、Forms Listener Servlet 用にサーブレット別名を定義するかわりに、サーブレット別名の情報をアプリケーションのカスタム・アプリケーション定義セクションに追加します。たとえば、次のようになります。

envFile=myEnvFile.env

このとき、myEnvFile.envは、forms90/serverディレクトリに配置されています。

5. Forms6i Services の HTML テンプレート・ファイルを変更した場合、同じ変更をOracle9i Forms Services の HTML テンプレート・ファイルに加えます。


http://hostname:port/forms90/f90servlet?config=application

注意注意注意注意 : 9i ファイルは 6i ファイルと異なるため、$ORACLE_HOME_2 にある 9i formsweb.cfgファイルを $ORACLE_HOME_1 にある 6i formsweb.cfgファイルに置き換えることはお薦めできません。アプリケーション構成の行を 6i ファイルから 9i ファイルにコピーしてください。



ロード・バランシングの移行ロード・バランシングの移行ロード・バランシングの移行ロード・バランシングの移行Forms6i Services のロード・バランシング方法は、使用する配布タイプによって異なります。

� Forms 6i リスナーを使用する場合は、メトリック・サーバー（個別プロセス）によりロード・バランシングが実行されます。

� Forms 6i サーブレットを使用する場合は、JServ サーブレット・エンジンによって、JServ エンジン間のラウンド・ロビン・ロード・バランシングが使用されて、ロード・バランシングが構成されます。

Oracle9iAS リリース 2（9.0.2）の Oracle9i Forms Services では、ロード・バランシングはmod_oc4j によって実行されます。mod_oc4j は、Forms Servlet および Forms Listener Servlet を処理するサーブレット・コンテナに Web リクエストをバインドします。

ロード・バランシング用クラスタのセットアップ情報は、『Oracle9i Application Server 管理者ガイド』を参照してください。

使用上の注意使用上の注意使用上の注意使用上の注意この項では、Forms6i Services から移行した Oracle9i Forms Services の構成と配布について説明します。

Forms Servlet によるアイコン・イメージの配布によるアイコン・イメージの配布によるアイコン・イメージの配布によるアイコン・イメージの配布

Forms6i Services で静的な HTML 起動ファイルを使用すると、その起動 HTML ファイルに関連する場所にあるアプリケーションで使用される、イメージの記憶域を使用できます。 Oracle9i Forms Services の Forms Servlet では、このような機能をサポートしていません。

そのかわりに、アプリケーションのアイコン・イメージの場所として、codebase値が設定された imageBaseパラメータを使用します。 codebase値は、Forms クライアントの Javaアーカイブ・ファイルがすべて含まれている /forms90/javaディレクトリを参照します。パフォーマンス上の理由から、この場所にイメージを格納することはお薦めしません。

そのかわり、個別のアーカイブ・ファイルにアイコンをバンドルすることをお薦めします。アーカイブはクライアントに永久的にキャッシュされるため、この方法を使用することでパフォーマンスが向上します。次に、アーカイブ・ファイルを作成して、そこにイメージを置く方法について説明します。

1. jarコマンドが正常に機能することを確認します。正常に機能しない場合は、JDK が正しいパス環境変数エントリ（/bin ディレクトリを指定）でシステムにインストールされているかどうかを確認します。

2. アプリケーション・イメージを含むディレクトリに移動して、次のコマンドを発行します。

jar -cfv application_images.jar *.extension

ここで、applicationはアプリケーション名、extensionはイメージ・ファイルの拡張子（たとえば、.gif）です。



JAR ファイル application_images.jarは、カレント・ディレクトリに作成されます。

3. application_images.jarファイルを forms90/javaディレクトリにコピーします。

4. formsweb.cfgファイルを編集して、アプリケーション用に定義したカスタム・アプリケーション・セクションに、imageBase=codebaseを追加します。

5. アプリケーションで使用するアーカイブ・パスに application_images.jarファイルを追加します。追加するには、次の行をカスタム・アプリケーション・セクションに追加します。

archive_jini=f90all_jinit.jar,<application>_images.jar archive=f90all.jar,<application>_images.jar archive_ie=f90all.jar,<application>_images.jar

カスタム・アイコン・ファイルを Forms Services で配布する方法の詳細は、Oracle9iAS のドキュメントである『Oracle9i Forms アプリケーションの配布の基本』の「Oracle9iAS Form Services の構成」を参照してください。

Reports Services を使用するための統合コールからを使用するための統合コールからを使用するための統合コールからを使用するための統合コールから Oracle9i Reports への移行への移行への移行への移行

Oracle9iAS リリース 2（9.0.2）では、Forms の Oracle Reports に対する統合コールが、クライアント側のバックグラウンド・エンジンで処理されません。Oracle9i Forms Services では、アプリケーションが Run_Report_Object組込みを使用して、統合されたレポートを処理するための Reports 9i Services をコールします。 Reports Services は、使用しているシステムにセットアップされます。コールを移行するには、次の手順に従います。

1. Run_Product(Reports,...)をすべて、Run_Report_Object()を使用する等価コールに変更します。

2. アプリケーションの Reports モジュールの場所を Reports Services の REPORTS_PATHに追加します。

3. Reports Services を参照するように、Run_Report_Objectを変更します。

注意注意注意注意 : archive_ieには、f90all.cabが含まれている必要があります。IE5 のネイティブ VM を使用する場合は、この方がアーカイブ・フォーマットとして適しています。アーカイブと CAB ファイルは混在できないため、イメージ用の CAB ファイルを作成するか、Forms アプリケーション用の f90all.jarを使用してください（前者の方法をお薦めします）。


Forms Listener Servlet のののの OC4J での別名の作成での別名の作成での別名の作成での別名の作成

Forms6i Services のパッチ 8 以前では、アプリケーションごとに個別の環境ファイルを使用するために、Forms Servlet の別名を $ORACLE_HOME/Apache/JServ/conf/zone.propertiesファイルに作成する必要がありました。 Oracle9i Forms Services の Forms Servlet では、この作業は必要ありません。次に示すように、envFileパラメータを使用して、formsweb.cfgファイルで環境ファイル名を設定できます。

EnvFile=myApp.env

Forms 9i では、Forms Servlet の別名を次のファイルに作成しません。

ORACLE_HOME/Apache/Jserv/etc/jserv.properties.

そのかわり、次のファイルに作成します。

<ORACLE_HOME>/<Forms_OC4J_Home>/applications/forms90app/forms90web/WEB-INF/web.xml

必要な作業は、<servlet>タグと </servlet>タグ間の内容をコピーして、サーブレット名を変更するだけです。新しいサーブレット別名用の URL マッピングを作成するには、前述のファイルに次の内容を追加します。

<servlet-mapping><servlet-name>New_Servlet_Name</servlet-name><url-pattern>/New_URL_Name*</url-pattern></servlet-mapping>

Forms Listener Servlet 管理ページへのアクセス管理ページへのアクセス管理ページへのアクセス管理ページへのアクセス

Forms6i Services で Forms Listener Servlet 用のテスト・ページを表示するには、次の URLを使用します。

http://hostname:port/servlet/oracle.forms.servlet.ListenerServlet

表示される情報は、初期化パラメータ TestModeの値によって異なります。その値は、$ORACLE_HOME/Apache/Jserv/etc/zone.properties構成ファイルで設定します。

Oracle9i Forms Services 用のテスト・ページを表示するには、次の URL を使用します。

http://hostname:port/forms90/f90servlet/admin

表示される情報は、初期化パラメータ testModeの値によって異なります。この値は、<ORACLE_HOME>/<Forms_OC4J_HOME>/applications/forms90app/forms90web/WEB-INF/web.xml構成ファイルで設定します。次に、例を示します。

<init-param>


<param-name>testMode</param-name> <param-value>true</param-value></init-param>

Oracle9i Forms Services への移行のベスト・プラクティスへの移行のベスト・プラクティスへの移行のベスト・プラクティスへの移行のベスト・プラクティスこの項では、Forms アプリケーションを Oracle9iAS リリース 2（9.0.2）に移行する際の一般的な推奨事項および考慮事項について説明します。

� お使いのアプリケーションを Oracle9iAS リリース 2（9.0.2）に正常に移行するまでは、インストールした Oracle9iAS リリース 1（1.0.2.2.x）を保持します。

� Forms Listener Servlet の新しいアーキテクチャを使用して、Forms6i Services を配布します。

� Forms CGI のかわりに、Forms Servlet を使用します。

� 統合された Reports アプリケーションをコールする Run_Productを、Reports Servicesをコールする Run_Report_Objectに置換します（または、Forms 9i で今後利用可能になる PL/SQL 変換ユーティリティを使用します）。

� Oracle9iAS リリース 2（9.0.2）をインストールして、アプリケーションで使用する情報を基に forms90/serverディレクトリにある formsweb.cfgファイルを構成します。同じディレクトリに、Forms アプリケーションで使用する環境ファイルをコピーします。同じマシンではない場合は、Oracle9iAS リリース 2（9.0.2）が稼動しているマシンに、移行した Forms アプリケーション・モジュール・ファイルをコピーします。

� Oracle9iAS リリース 2（9.0.2）を起動した後、次の URL を使用して、Oracle9i Forms Services のリスナー・サーブレットのテスト・ページにアクセスします。

http://hostname:port/forms90/f90servlet/admin

� アプリケーション設定が formsweb.cfgファイルに追加されていること、および環境変数 FORMS90_PATHにアプリケーション・モジュールのディレクトリが含まれていることを確認します。

� SQL*Plus 接続を使用してデータベースにアクセスできることを確認します。

� http://hostname:port/forms90/f90servlet?config=your_appと入力して、アプリケーションを起動します。

� Oracle9iAS リリース 1（1.0.2.2.x）を停止する前に、Oracle9i Forms Service に配布されたアプリケーションをテストします。

� 初にソース・ファイルを移行し、完全にバックアップしてから、アプリケーション・ファイルを保護します。


Oracle9iAS Reports Services の移行

Oracle9iAS Reports Services の移行の移行の移行の移行この項では、6i Reports Server の構成を Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iASリリース 2（9.0.2）に移行する方法について説明します。この項の項目は次のとおりです。

� Reports 構成ファイルの移行

� Oracle9iAS Reports Services と Oracle9iAS Portal の併用

� Oracle Graphics の移行

� Oracle9iAS Reports Services の非推奨機能

Reports 構成ファイルの移行構成ファイルの移行構成ファイルの移行構成ファイルの移行6i Reports Server の永続ファイルおよびサーバー構成ファイルを再利用する場合は、次のファイルをコピーします。

ORACLE_HOME_1/reports60/server/report_server_name.ora

コピー先 :

ORACLE_HOME_2/reports/conf/report_server_name.ora

さらに、次のファイルが存在する場合も、コピーします。

ORACLE_HOME_1/reports60/server/report_server_name.dat

コピー先 :

ORACLE_HOME_2/reports/server/report_server_name.dat

6i Reports Server の cgicmd.datファイルを再利用する場合は、次のファイルをコピーします。

ORACLE_HOME_1/reports60/server/cgicmd.dat

コピー先 :

ORACLE_HOME_2/reports/conf/cgicmd.dat

Oracle9iAS Reports Services では、セキュリティ機能が強化されました。 Oracle 6i Reportsでは、接続文字列情報を cgicmd.datファイルに配置している場合があります。 Oracle9iAS Reports Services で強化されたセキュリティ機能を使用するには、この接続文字列情報をOracle Internet Directory（OID）に移行することを検討する必要があります。

関連項目関連項目関連項目関連項目 : 『Oracle9iAS Reports Services レポート Web 公開ガイド』



Oracle9iAS Reports Services とととと Oracle9iAS Portal の併用の併用の併用の併用Oracle9i へのスムーズな移行を促進するために、Oracle9iAS Reports Server では、セキュリティ・リポジトリ、およびページ・グループまたはコンテンツ領域にプッシュするレポート・コンテンツの宛先として、Oracle9iAS Portal リリース 9.0 またはリリース 3.0.9 を使用できます。この互換性は、現在 Oracle9iAS リリース 1（1.0.2.2.x）で Oracle9iAS Portal 3.0.9と Oracle Reports 6i を統合して使用しており、Oracle9i Reports にアップグレードする一方で、Oracle9iAS Portal リリース 3.0.9 を引き続き使用したい場合に、特に便利です。

この方法で Oracle9i Reports を構成するには、その Reports Server で、セキュリティ機能およびレポートの宛先として、Oracle9iAS Portal リリース 3.0.9 接続を使用できる必要があります。 Reports Server で、セキュリティ・システムが Oracle9iAS Portal リリース 9.0 インスタンスではなく、Oracle9iAS Portal リリース 3.0.9 インスタンスであることが検出されると、Reports Server は 6i セキュリティ互換モードで稼動します。また、Reports サーブレットは、このモードを使用して、Oracle9iAS Portal リリース 3.0.9 との統合を使用するレポート・リクエストに対して適切に動作します。

同時に、セキュリティおよび宛先要素として Oracle9iAS Portal リリース 9.0 を使用している別の Oracle9iAS Reports Server も使用できます。この Oracle9iAS Reports Server では、認証のための Single Sign On や OID のサポートなど、すべての新機能とともに稼動します。また、Reports サーブレットは、このモードを使用して、Oracle9iAS Portal リリース 9.0 との統合を使用するレポート・リクエストに対しても適切に動作します。この場合も、サーブレットで Single Sign On を使用できます（使用できるように構成されている場合）。

Oracle9iAS Reports Server が正常に稼動しているか確認するには、次の操作を行います。

� Oracle9iAS Portal リリース 3.0.9 とともに動作するように Oracle9iAS Reports Server をセットアップするには、Reports Server 構成ファイル servername.confのセキュリティ要素の下にある securityUserid プロパティ、および宛先要素の下にあるportalUserid プロパティ用に、Portal リリース 3.0.9 のデータベースのユーザー名、パスワードおよび TNS 名を＜ユーザー名 / パスワード @TNS 名＞の形式で入力します。たとえば、次のようになります。

<security id=”rwSec” class="oracle.reports.server.RWSecurity”><property name="securityUserid" value="portal309_id/portal309_password@portal_schema" confidential="yes" encrypted="no"/>

</security>

注意注意注意注意 : Oracle9iAS Reports Server にサービスを提供するために必要なOracle9iAS Reports サーブレットのインスタンスは、1 つのみです。これは、Reports Server で稼働されているインスタンスが Oracle9iAS Portal リリース 3.0.9 のインスタンスであっても、Oracle9iAS Portal リリース 9.0のインスタンスであっても同様です。サーブレットは、リクエストの送信先となる Reports Server に応じて、6i モードと 9i モードを切り替えます。



� Oracle9iAS Portal リリース 9.0 とともに動作するように Oracle9iAS Reports Server をセットアップするには、Reports Server 構成ファイル servername.confのセキュリティ要素の下にある securityUserid プロパティ、および宛先要素の下にあるportalUserid プロパティ用に、Portal リリース 9.0 のデータベースのユーザー名、パスワードおよび TNS 名を＜ユーザー名 / パスワード @TNS 名＞の形式で入力します。たとえば、次のようになります。

<security id=”rwSec” class="oracle.reports.server.RWSecurity”> <property name="securityUserid" value="portal90_id/portal90_ password@portal_schema" confidential=”yes” encrypted="no"/></security>

Oracle Graphics の移行の移行の移行の移行Oracle9iAS Reports Services には、以前のリリースの Oracle Graphics にかわる新しいグラフ・エンジンが備わっています。 Oracle Graphics のグラフを新しいグラフ・エンジンには移行できませんが、Oracle9iAS Reports Services で、下位互換として Oracle Graphics エンジンを使用できます。

Windows の場合、Oracle Graphics エンジンを下位互換にするには、Oracle Graphics 6i ホームをシステム・パスに入れます。

UNIX の場合、g90runm.shで、環境変数 ORACLE_GRAPHICS6I_HOME を、Oracle Graphics 6i がインストールされている ORACLE_HOME ディレクトリに設定します。 ORACLE_GRAPHICS6I_HOME の設定に関する追加情報は、g90runm.shのコメントを参照してください。

Oracle9iAS Reports Services で Oracle Graphics を使用する場合、次の制限が適用されます。

� Oracle Graphics グラフは、印刷レイアウトでしか使用できません。新しい JSP Web レイアウトでは、動作しません。 Oracle Graphics グラフを Web フォーマットに挿入する場合は、印刷レイアウトを実行して、Web 宛先フォーマット（たとえば、HTML、HTMLCSS など）にする必要があります。

� Oracle Graphics を使用するレポートは、レポート定義ファイル（RDF）フォーマットで保存する必要があります。 XML など、他のフォーマットでは保存できません。

� Oracle9iAS Reports Services には新しい Oracle Graphics チャートを追加できません。既存の Oracle Graphics チャートしか実行できません。新規チャートでは、Oracle9iAS Reports Services に備わっている新しいチャート・エンジンを使用します。

関連項目関連項目関連項目関連項目 : 『Oracle9iAS Reports Services レポート Web 公開ガイド』



Oracle9iAS Reports Services の非推奨機能の非推奨機能の非推奨機能の非推奨機能次に、Oracle9iAS Reports Services の非推奨機能のリストを示します。これらの機能を使用している既存レポートは、変更しなくても機能しますが、引き続き使用することはお薦めしません。また、これらの機能についての説明ドキュメントも提供しておりません。

� ユーザー・イグジット

� rwcgi Web 実行可能ファイル

� コマンドライン・オプション : CURRENCY、THOUSANDS、DECIMAL、PROFILE、ERRFILE、LOGFILE、BACKGROUND、KEYIN、KEYOUT

� SRW.SET_ATTR 組込み

� OLE2 オブジェクト・サポート

次の機能は、完全に削除されています。

� rwrunc キャラクタ・モード・ランタイム

� rwrun のクライアント / サーバー GUI レポート・プレビューア

� rwrbe60 バックグラウンド・エンジン

� rwows60 OAS カートリッジ

� obe60 クエリー・ビルダー

� obs60 スキーマ・ビルダー


Oracle9iAS Discoverer の移行

Oracle9iAS Discoverer の移行の移行の移行の移行この項では、Oracle9iAS Discoverer を Oracle9iAS リリース 1（1.0.2.2.x）から Oracle9iASリリース 2（9.0.2）に移行する方法について説明します。この処理には、次のタスクが含まれます。

� 環境設定の移行

� エンド・ユーザー・レイヤーの更新

� URL 参照の更新

� セッション・タイムアウトの構成

� Discoverer Viewer のカスタマイズの移行

移行処理を開始する前に、次の作業を行います。

1. Oracle9iAS リリース 2（9.0.2） Discoverer のインストールが成功していることを確認します。次の URL から使用可能なリンクを使用して、Discoverer のデモを実行します。

http://hostname:port/discoverer/intro/html/disc_demo_intro.htm

環境設定の移行環境設定の移行環境設定の移行環境設定の移行この項では、デフォルト・ユーザーおよびユーザー・レベルの環境設定を移行する方法について説明します。

デフォルト・ユーザーの環境設定の移行デフォルト・ユーザーの環境設定の移行デフォルト・ユーザーの環境設定の移行デフォルト・ユーザーの環境設定の移行

デフォルト・ユーザーの環境設定を移行するには、次の手順に従います。

1. 次の元のバージョン 4.1 ファイルを

$ORACLE_HOME_1/6iserver/discwb4/util/pref.txt

次のファイルと比較します。

$ORACLE_HOME_2/discoverer902/util/pref.txt

2. $ORACLE_HOME_1/../pref.txtファイルに変更が加えられている場合は、$ORACLE_HOME_2../pref.txtファイルにも元のバージョン 4.1 ファイルと同じ変更が含まれるように編集します。

3. デフォルトの環境設定を適用するには、次のコマンドを発行します。

dis51pr -apply -nopause



Discoverer リリースリリースリリースリリース 4.1 からからからから Discoverer 9.0.2 へのユーザー・レベル環境設定の移行へのユーザー・レベル環境設定の移行へのユーザー・レベル環境設定の移行へのユーザー・レベル環境設定の移行

ユーザー・レベルの環境設定を Discoverer リリース 4.1 から移行するには、次の手順に従います。

1. （UNIX のみ）.reg_key.dcファイル（DC_REG環境変数が指定するファイル）を、DC902_REG環境変数によって指定される場所にコピーします。

2. 次のコマンドを発行します。

dis51pr -migrate

エンド・ユーザー・レイヤーの更新エンド・ユーザー・レイヤーの更新エンド・ユーザー・レイヤーの更新エンド・ユーザー・レイヤーの更新Oracle9iAS リリース 2（9.0.2）とともに出荷されているバージョンの Discoverer では、Discoverer Administrator 9.0.2（Oracle9i Developer Suite リリース 9.0.2 とともに出荷されています）によって作成されるエンド・ユーザー・レイヤーが必要です。既存の Discoverer 4.1 エンド・ユーザー・レイヤーがある場合、Discoverer Administrator 9.0.2 を使用して、エンド・ユーザー・レイヤーをバージョン 4.1 からバージョン 5.1 にアップグレードする必要があります。

URL 参照の更新参照の更新参照の更新参照の更新Discoverer Viewer および Discoverer Plus のすべての URL 参照は変更されています。これらには、Web サイトおよびクライアント・ブックマーク内のリンクも含まれます。制限はありません。次の表に従って、旧 URL をすべて新しい URL に手動で置き換える必要があります。

関連項目関連項目関連項目関連項目 : 『Oracle9i Discoverer Administrator 管理ガイド』

Discoverer Plus リリースリリースリリースリリース 1 のののの URL リリースリリースリリースリリース 2 のののの URL 例例例例

http://hostname/discwb4/html/english/ms_ie/start_ie.htm

または

http://hostname/discwb4/html/english/netscape/start_nn.htm

http://hostname/discoverer/plus

旧 URL

http://host:port/discwb4/english...

新 URL

http://host:port/discoverer/plus

Discoverer Viewer リリースリリースリリースリリース 1 のののの URL リリースリリースリリースリリース 2 のののの URL 例例例例

http://hostname/discoverer4i/viewer http://hostname/discoverer/viewer 旧 URL

http://host:port/discoverer4i/viewer

新 URL

http://host:port/discoverer/viewer



セッション・タイムアウトの構成セッション・タイムアウトの構成セッション・タイムアウトの構成セッション・タイムアウトの構成session-timeoutパラメータは、次の場所から移動しています。

ORACLE_HOME_1/Apache/Jserv/etc/disco4iviewer.properties

新しい場所

ORACLE_HOME_2/j2ee/OC4J_BI_Forms/applications/discoverer/web/WEB-INF/web.xml

session-timeoutパラメータは、HTTP セッション・タイムアウト、すなわち、Discoverer サーブレットがユーザーの HTTP セッションを終了するまでに、ブラウザによる別の HTTP または HTTPS リクエストの作成を待機する時間（分）を制御します。

session-timeoutパラメータは、web.xmlファイルにあり、<web-app>を読み込む行の直後に続きます。次に例を示します。

<session-config><session-timeout>15</session-timeout></session-config>

Discoverer Viewer のカスタマイズの移行のカスタマイズの移行のカスタマイズの移行のカスタマイズの移行Oracle9iAS Discoverer Viewer の外観と動作は、多くのファイルによって制御されています。これらのファイルは、特定要件を満たすように Discoverer Viewer をカスタマイズするため、変更されている場合があります。Oracle9iAS リリース 2（9.0.2）をインストールすると、いくつかのファイルが別の名前で新しくインストールされます。特に、disco4iv.xmlはconfiguration.xmlに名前変更され、viewer_config.xmlは ui_config.xmlに名前変更されています。元の構成ファイルおよび .xsl ファイルを変更している場合、新しいファイルを編集して、元のバージョン 4.1 ファイルの変更を再適用する必要があります。

注意注意注意注意 : 新しいファイルを元のバージョン 4.1 ファイルに置き換えないでください（単純にファイルの名前を変更しないでください）。新旧ファイルの相違部分すべてではなく、カスタマイズ部分のみを元のバージョン 4.1 のファイルから新しいファイルに移行するには、次の手順に従います。



1. $ORACLE_HOME_1/Apache/Apache/htdocs/disco4iv/htmlにある元のバージョン 4.1 の各ファイルについて、次のタスクを実行します。

a. 次の表を使用して、等価情報を含むファイルを識別します。

b. 元のバージョン 4.1 のファイルと、$ORACLE_HOME_2/J2EE/OC4J_BI_Forms/applications/discoverer/web/ディレクトリにある、リリース 2 の対応するファイルと比較します。

c. リリース 2 の対応するファイルを編集して、元のバージョン 4.1 ファイルで見つかったカスタマイズを取り込みます。

JInitiator のアップグレードのアップグレードのアップグレードのアップグレードOracle9iAS リリース 2（9.0.2） Discoverer は、提供されているバージョン（1.3.x）以降のJInitiator とともに使用する必要があります。 JInitiator のバージョンは、次のファイルにあるjvm要素によって指定されています。

ORACLE_HOME_2/j2ee/OC4J_BI_Forms/applications/discoverer/web/plus_files/xsl/plus_config.xml

Oracle9iAS リリース 1（1.0.2.2.x）で提供されているバージョンの JInitiator とともに、Oracle9iAS リリース 2（9.0.2） Discoverer を実行しないでください。

リリースリリースリリースリリース 1 のファイルのファイルのファイルのファイルリリースリリースリリースリリース 2 のファイルのファイルのファイルのファイル

disco4iv.xml web/WEB-INF/configuration.xml

viewer_config.xml web/common/xsl/ui_config.xml

注意注意注意注意 : configuration.xmlを変更する場合は、Oracle Enterprise Manager の使用を検討してください。 Oracle Enterprise Manager には、configuration.xmlを編集するためのユーザー・インタフェースが備わっており、各設定に関する有用な情報も含まれています。


Oracle9iAS Personalization の移行

Oracle9iAS Personalization の移行の移行の移行の移行この項では、Oracle9iAS Personalization（OP）リリース 9.0.1 からリリース 9.0.2 に移行する方法について説明します。移行には、2 つの方法、すなわち extract-load-and-transform

（ELT）方式とインプレース方式があります。

移行するには、特定の OP コンポーネントを停止したり起動したりする必要があります。これらのタスクの実行方法は、オンライン・ヘルプで OP の管理 UI に関する説明を参照するか、『Oracle9iAS Personalization ユーザーズ・ガイド』および『Oracle9iAS Personalization管理者ガイド』を参照してください。『Oracle9iAS Personalization ユーザーズ・ガイド』には、OP コンポーネントおよびそれらの協調動作に関する説明が含まれています。

移行の概要移行の概要移行の概要移行の概要OP リリース 9.0.1 から OP リリース 9.0.2 への移行（アップグレード）には、次の 2 つの方法があります。

� extract-load-and-transform（ELT）による移行

� インプレース移行

いずれの方法を使用しても、OP リリース 9.0.1 のマイニング・テーブル・リポジトリ（MTR）が OP リリース 9.0.2 の MTR に移行されます。 MTR には、パッケージの構築に必要なすべてのデータ、および OP アプリケーションによって収集されたすべての情報が含まれています。したがって、MTR を移行することで、重要データを保持できます。

マイニング・オブジェクト・リポジトリ（MOR）、リコメンデーション・エンジン、および管理 UI と REAPI Demo 用の構成設定は、提供されているスクリプトを使用しても移行されません。 MTR を移行した後、MOR に格納されている OP メタデータを 9.0.2 MTR に再入力します（再入力するには、OP 管理者ユーザー・インタフェースを使用します）。また、すべてのパッケージを再構築して配布する必要があります。

いずれの移行タイプにも、メリットとデメリットがあります。

� ELT 移行では、OP リリース 9.0.1 のインストール環境をそのまま保持できます。 ELT 移行を使用すると、OP リリース 9.0.2 を別のマシン（または複数のマシン）にインストールして、OP リリース 9.0.1 の MTR のデータを 9.0.2 MTR にコピーできます。移行の完了後、OP リリース 9.0.2 を実行できます。ただし、ELT 移行では、2 つの MTR を保持するため、必要な容量が大きくなります。

� インプレース移行では、既存の OP リリース 9.0.1 の MTR を OP リリース 9.0.2 の MTR に変更します。移行後は、9.0.1 MTR が存在しなくなるため、別の使用可能な 9.0.1 MTRが存在しない限り、リース 9.0.1 の OP を実行できなくなります。ただし、バックアップからリリース 9.0.1 を再ロードするか、または 9.0.2 MTR を 9.0.1 MTR にダウングレードできます。次に説明する「移行した MTR のダウングレード」を参照してください。



移行スクリプトの場所移行スクリプトの場所移行スクリプトの場所移行スクリプトの場所この項で説明するスクリプトは、すべて次の場所にあります。

$ORACLE_HOME/dmt/admin

extract-load-and-transform による移行による移行による移行による移行ELT 移行では、OP リリース 9.0.1 をそのまま保持できます。 ELT 移行は、次の手順で実行します。

1. OP リリース 9.0.2 をインストールします。

2. OP リリース 9.0.1 から移行します。

3. OP リリース 9.0.1 を再起動して、必要に応じて OP リリース 9.0.2 を起動します。

OP リリースリリースリリースリリース 9.0.2 のインストールのインストールのインストールのインストール『Oracle9i Application Server インストレーション・ガイド』の説明に従って、OP リリース

9.0.2 をインストールします。 OP リリース 9.0.1 のどのファイルも上書きしないでください。インストールの完了後、MOR を 1 つ、MTR を 1 つ、および RE を少なくとも 1 つ構成します。

ELT を使用したを使用したを使用したを使用した OP リリースリリースリリースリリース 9.0.1MTR の移行の移行の移行の移行これらの手順は、OP リリース 9.0.1 がインストールされているすべてのシステムで実行します。移行作業では、OP リリース 9.0.1 を停止した後、OP リリース 9.0.2 のインストール時に作成した 9.0.2 MTR に、9.0.1 MTR をコピーします。移行するには、次の手順に従います。

1. パッケージ・ビルド、パッケージ配布、および 9.0.1 MTR を参照するレポートをすべて停止します。

a. OP 管理者ユーザー・インタフェースを使用して、すべてのパッケージ・ビルド、パッケージ配布およびレポートが停止していることを確認します。これらのいずれかが稼動している場合、それを取り消すか、または完了するまで待機します。また、ビルド、配布およびレポートを開始しないように、それらのスケジュールを変更する必要があります。

b. なにも稼動していないことを確認します。

2. スクリプト $ORACLE_HOME/dmt/admin/REmaint.shを使用して、すべてのリコメンデーション・エンジンを停止します。

REmaint.shは、MOR に認識されるすべての RE を停止し、RE に対して、すべてのキャッシュ情報を MTR に保存するように強制します。スクリプトが完了した後は、停止した RE を使用しようとするアプリケーションに対して、RE_OFFLINE 例外が通知されます。

3. 9.0.1 MTR をバックアップします。



4. 9.0.1 MTR で次のスクリプトを実行して、RE のリストを生成します。

mor_re_farmjから、ID、名前、説明を選択します。

5. 次の手順に従って、OP リリース 9.0.1 の MTR を OP リリース 9.0.2 の MTR にコピーします。

a. 9.0.1 MTR をエクスポートします。

mtrexp.sh MTRUsername, MTRpassword, TnsAlias

b. 9.0.1 MTR を 9.02 MTR にインポートします。

mtrimp.sh SYSTEMPasswd oldMTRUname, NewMTRUname, NewMTRUname, NewTableSpaceName, NewDataFileName, TnsAlias

既存の 9.0.1 MTR が、新しい OP リリース 9.0.2 の MTR にコピーされます。

OP リリースリリースリリースリリース 9.0.1 およびおよびおよびおよび OP リリースリリースリリースリリース 9.0.2 の起動の起動の起動の起動移行が完了すると、OP リリース 9.0.1 の管理 UI を使用して、9.0.1 RE を起動できます。これで、これらの RE に接続しようとするアプリケーションに対して例外が通知されなくなります。

OP リリース 9.0.2 を起動するには、まず、必要な RE がすべて作成済であることを確認します。次に、リリース 9.0.2 の管理 UI を使用して、9.0.2RE に移行した MTR に基づいて、新しいパッケージを構築して配布します。

9.0.2 MTR を使用するアプリケーションは、いずれも 9.0.2 REAPI.jarファイルにアクセスする必要があります。コードを再コンパイルする必要はありません。

インプレース移行インプレース移行インプレース移行インプレース移行インプレース移行では、9.0.1 MTR を 9.0.2 MTR にコピーします。（移行が完了すると、9.0.1 MTR は存在しなくなります。）インプレース移行は、主に次の手順で実行します。

1. OP リリース 9.0.2 をインストールします。

2. MTR をリリース 9.0.1 から移行します。

3. OP リリース 9.0.2 を起動します（移行した 9.0.1 MTR 以外の 9.0.1 MTR が存在しない限り、OP リリース 9.0.1 を再起動できません）。

注意注意注意注意 : 必要に応じて、移行した MTR を 9.0.1 MTR にダウングレードできます。



OP リリースリリースリリースリリース 9.0.2 のインストールのインストールのインストールのインストール『Oracle9i Application Server インストレーション・ガイド』の説明に従って、OP リリース

9.0.2 の MOR と RE のみをインストールします。 OP リリース 9.0.1 のどのファイルも上書きしないでください。インストールの完了後、MOR を 1 つ、MTR を 1 つ、および RE をリリース 9.0.1 のアプリケーションで必要な数だけ構成します。

インプレースによるインプレースによるインプレースによるインプレースによる OP リリースリリースリリースリリース 9.0.1 のののの MTR の移行の移行の移行の移行これらの手順は、OP リリース 9.0.1 がインストールされているすべてのシステムで実行します。移行作業では、OP リリース 9.0.1 を停止した後、OP リリース 9.0.2 のインストール時に作成した 9.0.2 MTR に、9.0.1 MTR をコピーします。移行するには、次の手順に従います。


a. OP 管理者ユーザー・インタフェースを使用して、すべてのパッケージ・ビルド、パッケージ配布およびレポートが停止していることを確認します。これらのいずれかが稼動している場合、それを取り消すか、または完了するまで待機します。また、ビルド、配布およびレポートを開始しないように、それらのスケジュールを変更する必要があります。


2. スクリプト REmaint.shを使用して、すべてのリコメンデーション・エンジンを停止します。


3. 9.0.1 MTR をバックアップします。

4. 9.0.1 MTR で次のスクリプトを実行して、RE のリストを生成します。

mor_re_farmjから、ID、名前、説明を選択します。

5. 次のスクリプトを使用して、OP リリース 9.0.1 の MTR をアップグレードします。

opupgrd.sql MTRUsername, MTRpassword, TnsAlias

既存の 9.0.1 MTR が、新しい OP リリース 9.0.2 の MTR にコピーされます。



OP リリースリリースリリースリリース 9.0.2 の起動の起動の起動の起動9.0.1 MTR はすでに存在しないため、OP リリース 9.0.1 を起動できません（移行した 9.0.1 MTR 以外に 9.0.1 MTR が存在する場合には起動できます）。

OP リリース 9.0.2 を起動するには、まず、必要な RE がすべて作成済であることを確認します。次に、リリース 9.0.2 の管理 UI を使用して、9.0.2RE に移行した MTR に基づいて、新しいパッケージを構築して配布します。


移行した移行した移行した移行した MTR のダウングレードのダウングレードのダウングレードのダウングレード必要に応じて、9.0.2 MTR をダウングレード、すなわち 9.0.1 MTR に変換できます。ダウングレードするには、9.0.2 MTR から 9.0.1 MTR へのインプレース移行を実行します。

ダウングレードするには、次の手順に従います。


a. OP の管理 UI を使用して、すべてのパッケージ・ビルド、パッケージ配布およびレポートが停止していることを確認します。これらのいずれかが稼動している場合、それを取り消すか、または完了するまで待機します。また、ビルド、配布およびレポートを開始しないように、それらのスケジュールを変更する必要があります。


2. スクリプト REmaint.shを使用して、すべてのリコメンデーション・エンジンを停止します。


3. 次のスクリプトを使用して、OP リリース 9.0.2 の MTR を OP リリース 9.0.1 の MTR にダウングレードします。

opdowngrd.sql MTRUsername, MTRpassword, TnsAlias

注意注意注意注意 : スケジュールされているタスクや MTR 接続を削除しないでください。



4. OP リリース 9.0.1 を再起動するには、9.0.1 MTR 接続を作成して（9.0.1 MTR 接続がない場合）、ダウングレードした MTR に基づいて、新しいパッケージを構築して配布し、レポートを再スケジュールします。


OP リリースリリースリリースリリース 9.0.1 の削除の削除の削除の削除移行が正常に完了したことを確認してから、OP リリース 9.0.1 を削除してください。これは、インプレース移行を実行している場合、特に重要です。

OP リリース 9.0.1 がもはや必要ではないと確信できた後、『Oracle9iAS Personalization 管理者ガイド』の説明に従って、OP リリース 9.0.1 を停止してから削除してください。


管理コンポーネントの

7
管理コンポーネントの移行管理コンポーネントの移行管理コンポーネントの移行管理コンポーネントの移行
この章では、管理コンポーネントの移行に必要な構成ファイル、アプリケーション配布ファイルおよびメタデータ・スキーマの変更方法について説明します。この章の主な項は次のとおりです。

� Oracle Enterprise Manager の移行

� Oracle9iAS Single Sign-On の移行

� Oracle Internet Directory の移行

注意注意注意注意 : この移行手順は、Oracle Management Server が Oracle9iAS リリース 2（9.0.2）Infrastructure インストールの一部としてインストールされており、Oracle9iAS リリース 1（1.0.2.2.x）の管理に Oracle Enterprise Manager を使用していた場合にのみ適用します。このマニュアルで説明する手順は、Oracle Enterprise Manager Web Site には適用しないでください。Oracle Enterprise Manager Web Site は、Oracle9iAS リリース 2

（9.0.2）の管理に使用する Web ベースの管理ツールであり、移行の必要はありません。 Enterprise Manager のコンポーネントの詳細は、『Oracle9i Application Server 管理者ガイド』を参照してください。

移行 7-1

Oracle Enterprise Manager の移行

Oracle Enterprise Manager の移行の移行の移行の移行この項では、Oracle Enterprise Manager リリース 2.x のリポジトリをリリース 9i のリポジトリにアップグレードする方法について説明します。リリース 9i より前の既存のリポジトリは、インストール時に自動的にアップグレードされません。アップグレードするには、インストール後に Oracle Enterprise Manager Configuration Assistant を手動で実行する必要があります。また、アップグレードする前に、リリース 9i の新しいリポジトリを作成しておく必要があります。

Oracle Enterprise Manager Configuration Assistant は、リリース 2.x の既存のリポジトリを取得して、リリース 9i のリポジトリに直接アップグレードします。

移行の準備移行の準備移行の準備移行の準備この項では、Oracle Enterprise Manager の移行前に実行する必要のある手順の概要について説明します。

Management Server およびおよびおよびおよび Enterprise Manager のアプリケーションの停止のアプリケーションの停止のアプリケーションの停止のアプリケーションの停止

アップグレードを実行する前に、まず初に、そのリポジトリを使用している Management Server および Oracle Enterprise Manager のアプリケーションをすべて停止する必要があります。 Management Server でそのリポジトリを使用している場合に、リポジトリをアップグレードすると、サーバー・エラーの原因となります。

リリース 2.2 より前の Oracle Enterprise Manager を使用している場合、または別売りのManagement Pack を使用している場合は、『Oracle Enterprise Manager 構成ガイド』に記載されている Enterprise Manager のリポジトリの移行に関する重要情報を参照してください。

リポジトリのバックアップリポジトリのバックアップリポジトリのバックアップリポジトリのバックアップ

リポジトリをアップグレードする前に、まず初に、標準のエクスポート機能を使用して、データベースまたはリポジトリのスキーマをバックアップしておく必要があります。 EXPORT ユーティリティが、基本ユーティリティとして Oracle データベース・サーバーに付属しています。

リポジトリのアップグレード中に障害が発生した場合、そのリポジトリは使用できなくなります。障害が発生したリポジトリは、アップグレード可能なリポジトリのリストに表示されなくなります。

注意注意注意注意 : SYS ユーザーの下に作成されているリポジトリは、エクスポートできません。



リポジトリのアップグレードリポジトリのアップグレードリポジトリのアップグレードリポジトリのアップグレードリポジトリをアップグレードするには、以降の項で説明する手順に従います。

1. 次の手順に従って、Enterprise Manager Configuration Assistant を起動します。

（Windows NT の場合）Windows の「スタート」メニューから Enterprise Manager Configuration Assistant を起動します。

または、コマンドラインから次のコマンドを使用して、Enterprise Manager Configuration Assistant を起動します。

emca

（UNIX の場合）コマンドラインから次のコマンドを使用して、Enterprise Manager Configuration Assistant を起動します。

emca

2. 「ようこそ」ページで「次へ」をクリックします。

「構成操作」ページが表示されます。

3. 構成操作のリストから「既存のリポジトリを更新」を選択し、「次へ」をクリックして、操作を続行します。

「リポジトリのデータベースの選択」ページが表示されます。

4. アップグレードするリポジトリが含まれているデータベースにログインします。

注意注意注意注意 : リポジトリにあるすべてのジョブおよびイベントの詳細情報は、その情報を安全に保管するためにバイナリ・フィールドに格納されています。また、データ自体は、スキーマ所有者名を使用して暗号化されています。したがって、Enterprise Manager のリポジトリを別のデータベースに移動することは可能ですが、そのリポジトリの所有者が同じスキーマ名を持っている必要があります。リポジトリのスキーマ名を変更することはできません。あるユーザーから別のユーザーにリポジトリをエクスポートまたはインポートすると、復号化キーが一致せず、ジョブとイベントが使用できなくなります。

注意注意注意注意 : emcaコマンドを実行するには、$ORACLE_HOME/sysman/configディレクトリにある omsconfig.propertiesファイルに対する書込みアクセス権が必要です。

管理コンポーネントの移行 7-3


「リポジトリの選択」ページが表示されます。アップグレードするリポジトリを選択する場合、「リポジトリの選択」ページにはリリース 2.0、2.1 および 2.2 のリポジトリのみが表示されます。この場合、Enterprise Manager Configuration Assistant では、リリース9.0.1 のリポジトリは表示されません（これらのリポジトリはすでに新バージョンであり、アップグレードする必要がないためです）。このページには、リポジトリに関する次の情報が表示されます。

ユーザー名ユーザー名ユーザー名ユーザー名 : リポジトリのユーザー名です。

バージョンバージョンバージョンバージョン : リポジトリのバージョンです。

タイプタイプタイプタイプ : リポジトリのタイプです。タイプは、「Enterprise」または「スタンドアロン」のいずれかです。 Management Server に接続されている Oracle Enterprise Manager では、Enterprise リポジトリが使用されます。 Management Server に接続されていないOracle Enterprise Manager を使用する場合、アプリケーションによってはスタンドアロン・リポジトリが必要になります。

5. リポジトリを選択して、「次へ」をクリックします。

「リポジトリへのログイン情報」ページが表示されます。

リポジトリのアップグレードを実行するには、リポジトリ所有者（リポジトリの作成時に指定したユーザー）として、リポジトリ・データベースにログインする必要があります。リポジトリ・ユーザー名は前のページから引き継がれますが、パスワードは入力する必要があります。

6. リポジトリ・ユーザーのパスワードを入力します。

注意注意注意注意 : リポジトリをアップグレードするには、DBA 権限を所有するユーザーとしてデータベースに接続する必要があります。 Enterprise Manager Configuration Assistant によって作成されたリポジトリ・スキーマ・ユーザーは、この手順で必要な DBA 権限を所有していません。セキュリティ上の問題が発生しないようにするために、リポジトリ・スキーマ・ユーザーに必要以上の権限を付与しないでください。そのかわりに、たとえばsystem/manager など、DBA 権限を所有する別のユーザーとして、データベースに接続してください。

注意注意注意注意 : 指定したデータベースにリリース 2.x のリポジトリが含まれていない場合、リポジトリのリストには何も表示されず、グレー表示になります。また、「データベースでリポジトリが見つかりませんでした。」というメッセージが表示されます。その場合には、「取消」をクリックしてEnterprise Manager Configuration Assistant を終了するか、または「戻る」をクリックして前のページに戻り、別のデータベースに接続します。



7. 「次へ」をクリックして、操作を続行します。

「リポジトリ更新のサマリー」ページが表示されます。

このページには、指定したすべての情報のサマリーが表示されます。リポジトリのアップグレードを実行する場合は、「完了」をクリックします。指定した情報を変更する必要がある場合は、「戻る」をクリックして、前のページに戻ります。

「Configuration Assistant の進行」ウィンドウが表示されます。ここには、実行済の処理および実行中の操作の各段階（処理ステップ）が表示されます。各処理ステップは、1行のテキストで表示されます。

8. テキスト領域に詳細情報を表示するには、「詳細の表示」をクリックします。テキスト領域を閉じるには、「詳細の非表示」をクリックします。

処理が完了する前に「取消」ボタンをクリックすると、要求した操作を取り消すことができます。ただし、操作を取り消すと、そのリポジトリは使用できなくなります。

処理が完了すると、結果のいかんにかかわらず、「取消」ボタンは「閉じる」ボタンに変わります。

エラーが発生することなく、すべてのステップが完了すると、「処理が完了しました。」というメッセージが表示されます。

9. 「閉じる」をクリックします。

アップグレードされているリポジトリが、ローカルの Management Server によって実際に使用されているリポジトリである場合に限り、Configuration Assistant によるアップグレード操作中に、Oracle Management Server が作成されます（まだ存在していない場合）。

既存のリポジトリの削除既存のリポジトリの削除既存のリポジトリの削除既存のリポジトリの削除リポジトリを削除して、そのリポジトリを使用しているローカルの Management Server の構成を解除するには、次の手順に従います。

1. そのリポジトリを使用している Management Server および Oracle Enterprise Managerのアプリケーションをすべて停止します。

2. Configuration Assistant を起動します。

「ようこそ」ページが表示されます。


「構成操作」ページが表示されます。

注意注意注意注意 : Management Server でそのリポジトリを使用している場合に、リポジトリを削除すると、サーバー・エラーの原因となります。



4. 構成操作のリストから「既存のリポジトリの削除」を選択して、「次へ」をクリックします。

「リポジトリのデータベースの選択」ページが表示されます。

5. 削除するリポジトリが含まれているデータベースにログインします。

「リポジトリの選択」ページが表示されます。このページには、リポジトリに関する次の情報が表示されます。

ユーザー名ユーザー名ユーザー名ユーザー名 : リポジトリのユーザー名です。

バージョンバージョンバージョンバージョン : リポジトリのバージョンです。

タイプタイプタイプタイプ : リポジトリのタイプです。タイプは、「Enterprise」または「スタンドアロン」のいずれかです。 Management Server に接続されている Oracle Enterprise Manager では、Enterprise リポジトリが使用されます。 Management Server に接続されていないOracle Enterprise Manager を使用する場合、アプリケーションによってはスタンドアロン・リポジトリが必要になります。

6. リポジトリを選択して、「次へ」をクリックします。

「リポジトリの削除オプションの選択」ページが表示されます。ここでは、リポジトリ・ユーザーとそのスキーマ・オブジェクトをすべて削除するか、またはリポジトリ・オブジェクトのみを削除するかを選択できます。

注意注意注意注意 : リポジトリをアップグレードするには、DBA 権限を所有するユーザーとしてデータベースに接続する必要があります。 Enterprise Manager Configuration Assistant によって作成されたリポジトリ・スキーマ・ユーザーは、この手順で必要な DBA 権限を所有していません。セキュリティ上の問題が発生しないようにするために、リポジトリ・スキーマ・ユーザーに必要以上の権限を付与しないでください。そのかわりに、たとえばsystem/manager など、DBA 権限を所有する別のユーザーとして、データベースに接続してください。

注意注意注意注意 : 指定したデータベースにリリース 2.x または 9i のリポジトリが含まれていない場合、リポジトリのリストには何も表示されず、グレー表示になります。また、「データベースでリポジトリが見つかりませんでした。」というメッセージが表示されます。その場合には、「取消」をクリックして Enterprise Manager Configuration Assistant を終了するか、または

「戻る」をクリックして前のページに戻り、別のデータベースに接続します。



� リポジトリのみを削除する場合は、リポジトリ・ユーザーのパスワードを指定する必要があります。これは、Enterprise Manager Configuration Assistant がリポジトリに接続して、Oracle Enterprise Manager の SQL 削除スクリプトを起動できるようにするためです。この場合、リポジトリ・オブジェクトのみが削除され、リポジトリにある他のスキーマ・オブジェクトは残ります。

� リポジトリ・ユーザーとそのスキーマ・オブジェクトをすべて削除する場合、パスワードは不要です。この手順を続行する前に、そのスキーマに他に重要なオブジェクトがないか確認してください。これを確認しないと、貴重なデータが失われることがあります。

� 新バージョンまたは新のバージョンではないリポジトリを選択した場合、有効なオプションはリポジトリ・ユーザーを削除する操作のみとなります。削除スクリプトで処理できるのは、新バージョンおよび新のバージョンのみです。

� Configuration Assistant では、管理対象のリポジトリが omsconfig.propertiesファイルで指定されていることが検出されても、そのリポジトリを削除しない場合には、Management Server の構成は変更されません。

� 管理対象のリポジトリを削除すると、Configuration Assistant によってManagement Server の構成が消去されます。


「リポジトリ削除のサマリー」ページが表示されます。このページには、リポジトリ削除の操作時に指定したすべての情報のサマリーが表示されます。

8. リポジトリの削除を続行する場合は、「完了」をクリックします。指定した情報を変更する必要がある場合は、「戻る」をクリックして、前のページに戻ります。

「Configuration Assistant の進行」ウィンドウが表示されます。ここには、実行済の処理および実行中の操作の各段階（処理ステップ）が表示されます。各処理ステップは、1行のテキストで表示されます。

9. テキスト領域に詳細情報を表示するには、「詳細の表示」をクリックします。テキスト領域を閉じるには、「詳細の非表示」をクリックします。

処理が完了すると、結果のいかんにかかわらず、「取消」ボタンは「閉じる」ボタンに変わります。

エラーが発生することなく、すべてのステップが完了すると、「処理が完了しました。」というメッセージが表示されます。

処理が完了する前に「取消」ボタンをクリックすると、要求した操作を取り消すことができます。

10.「閉じる」をクリックします。


Oracle9iAS Single Sign-On の移行

構成後の構成後の構成後の構成後の Management Server の管理の管理の管理の管理構成が完了した後は、Management Server によってクライアントと管理対象ノード間の分散管理がサポートされます。通知のための中央エンジンである Management Server によって、すべてのシステム管理作業が処理され、これらの作業が企業全体にわたって分散管理されます。

Oracle9iAS Single Sign-On の移行の移行の移行の移行この項では、Oracle9iAS リリース 1（1.0.2.2.x）のスタンドアロン・アプリケーションをOracle9iAS リリース 2（9.0.2）の Single Sign-On で使用できるように移行するプロセスについて説明します。

1. Oracle9iAS リリース 2（9.0.2）Infrastructure のオプションをインストールします。これによって、Single Sign-On（SSO）Server および Oracle Internet Directory（OID）がインストールされます。

2. Oracle9iAS リリース 1（1.0.2.2.x）のアプリケーション用のユーザー・データを OID リリース 9.0.2 に移行します。これによって、SSO Server リリース 9.0.2 で有効なユーザーとして認識されるようになります。複数のユーザー・リポジトリを使用している場合は、まず初に、単一の企業ユーザーが所有している複数のアカウント名の整合性を図り、各ユーザーに一意のアカウント / ユーザー名を発行してから、それらの一意のアカウントを OID に移行します。ユーザー・プロビジョニングおよびディレクトリ情報ツリー

（DIT）の詳細は、OID リリース 9.0.2 に関するドキュメントを参照してください。

3. アプリケーション・ロジックを Oracle9iAS Containers for J2EE（OC4J）に移行します。

リリース 2 では、ほとんどのアプリケーションが mod_sso（Oracle HTTP Server のSingle Sign-On 用モジュール）および OC4J のセキュリティ・インフラストラクチャと統合されます。

このプロセスが完了すると、リリース 2 で提供されるセキュリティ・インフラストラクチャをリリース 1 のアプリケーションで使用できるようになります。

関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server 管理者ガイド』

関連項目関連項目関連項目関連項目 : 第 3 章「インターネット・アプリケーションのコンポーネントの移行」

関連項目関連項目関連項目関連項目 : 『Oracle9iAS Single Sign-On 管理者ガイド』

関連項目関連項目関連項目関連項目 : 『Oracle9iAS Single Sign-On アプリケーション開発者ガイド』


Oracle Internet Directory の移行

Oracle Internet Directory の移行の移行の移行の移行この項では、次のリリースの Oracle Internet Directory（OID）を Oracle Internet Directoryリリース 9.0.2.1.0 に移行する方法について説明します。

� Oracle Internet Directory 2.1.1.x

� Oracle Internet Directory 3.0.1.x

以降の説明の中では、ORACLE_HOME_1 は既存の Oracle Internet Directory の Oracle ホームを表し、ORACLE_HOME_2 は新しくインストールした Oracle Internet Directory 9.0.2.1.0の Oracle ホームを表します。移行およびアップグレードのプロセスは、次のようになります。

1. サポートされているバージョンの OID は ORACLE_HOME_1 から使用できます。

2. Infrastructure インストールにより、別の Oracle ホームである ORACLE_HOME_2 にOID 9.0.2.1.0 をインストールします。

3. 旧 OID インストールからデータベースを移行する必要があります。この移行には、データベースを新バージョンにアップグレードし、その親である Oracle ホームをORACLE_HOME_1 から ORACLE_HOME_2 に変更する作業が含まれます。この手順が完了すると、データベースを実行するバイナリを ORACLE_HOME_2 から使用できるようになります。

4. OID スキーマをリリース 9.0.2.1.0 にアップグレードします。

5. アップグレードが完了します。

アップグレード時の考慮事項アップグレード時の考慮事項アップグレード時の考慮事項アップグレード時の考慮事項次の条件および手順は、アップグレードの計画と実行を成功させるために重要な事項です。

� 手順 2 で実行する OID 9.0.2.1.0 のインストール時に、データベース・インスタンスがORACLE_HOME_2 に作成されます。このデータベースを、Oracle9iAS の他のコンポーネントでインフラストラクチャとして使用しないでください。このデータベースは、Database Configuration Assistant（DBCA）によって廃棄および削除されます。

� アップグレードの後に、ORACLE_HOME_1 を削除できます。削除後にファイル・システムをクリーンアップする場合には注意が必要です。データベースおよび制御ファイルを ORACLE_HOME_2 から実行できるように移行しても、その場所はアップグレード後も変更されません。したがって、クリーンアップ時には、これらのファイルをそのまま残してください。

注意注意注意注意 : SSO Server リリース 2 では、リリース 1 からのサーバーの移行は含まれません。



� ORACLE_HOME_2 は、アップグレードした OID をサポートする目的でのみ使用します。 ORACLE_HOME_2 自体は、完全な Oracle9iAS Infrastructure ではありません。ただし、ORACLE_HOME_2 で稼動する OID は、OID 9.0.2.1.0 を必要とする他のOracle9iAS 9.0.2.1.0 インストールによって使用可能です。

アップグレード前の作業アップグレード前の作業アップグレード前の作業アップグレード前の作業アップグレードを開始する前に、次の手順を実行する必要があります。

1. 既存の OID がインストールされている ORACLE_HOME_1 にあるすべての OID プロセス（OID モニター、OID サーバー、レプリケーション・サーバー、ディレクトリ統合サーバー）を停止します。対応するデータベース・インスタンスおよびリスナーは、稼動したままにしておいてください。

2. Oracle9iAS リリース 2（9.0.2）インストール CD-ROM に入っている OID 9.0.2.1.0 をORACLE_HOME_2 にインストールします。インストールの完了後、ORACLE_HOME_2 で稼動しているすべての OID プロセス、ならびに ORACLE_HOME_2 にある対応するインフラストラクチャ・データベースおよびリスナーを停止します。

シングル・ノード環境でのアップグレードシングル・ノード環境でのアップグレードシングル・ノード環境でのアップグレードシングル・ノード環境でのアップグレード次の表に、シングル・ノード環境で OID をアップグレードするための手順を示します。

注意注意注意注意 : 既存のスキーマ情報とデータを保存しておくために、操作を続行する前に、ORACLE_HOME_1 にあるデータベースをバックアップしておくことを強くお薦めします。

OID のバージョンのバージョンのバージョンのバージョンデータベースデータベースデータベースデータベースのバージョンのバージョンのバージョンのバージョン

ORACLE_HOME_1 からからからからORACLE_HOME_2 へのへのへのへの移行移行移行移行

既存のデータベースの既存のデータベースの既存のデータベースの既存のデータベースのリリースリリースリリースリリース 9.0.1 へのへのへのへの移行移行移行移行

9.0.1.2.0 データデータデータデータベース・パッチベース・パッチベース・パッチベース・パッチ

OID スキーマのスキーマのスキーマのスキーマのアップグレードアップグレードアップグレードアップグレード

2.1.1.x 8.1.7.x Oracle Data Migration Assistant（ODMA）に

よって実行される

Oracle Data Migration Assistant によって実

行される

OIDCA を起動す

る前に手動で適用する

（詳細は、以降の説明を参照）

OIDCA

3.0.1.x 9.0.1.x Oracle Internet Directory Configuration Assistant

（OIDCA）によって実行

される

該当なし OIDCA の実行時

に手動で適用する

（詳細は、以降の説明を参照）

OIDCA



データベースのリリースデータベースのリリースデータベースのリリースデータベースのリリース 8.1.7.* からからからから 9.0.1.0.0 への移行への移行への移行への移行Oracle Internet Directory 3.0.1.x からのみアップグレードする場合は、「リリース 3.0.1.* から9.0.1.2.0 へのアップグレード」に示す手順に進みます。

1. ORACLE_HOME_2 で、$ORACLE_HOME_2/bin/odmaを実行して、Oracle Data Migration Assistant（ODMA）を起動します。ウィザードの指示に従って、旧バージョンの OID 2.1.1.* が稼動している ORACLE_HOME_1 にある既存の 8.1.7.* データベースを移行します。正しい SID が指定されていることと、データベース・リスナーを移行するように選択していることを確認してください。 Oracle Data Migration Assistant の詳細は、9i（9.0.1.0.0）データベースの移行に関するドキュメントを参照してください。

9.0.1.3.0 データベース・パッチの適用データベース・パッチの適用データベース・パッチの適用データベース・パッチの適用データベースが ORACLE_HOME_2 から起動していることを確認します。9.0.1.3.0 データベース・パッチ・セットを適用するには、InteroperaPatch の readme.htmの説明に従ってください。

Oracle Internet Directory Configuration AssistantORACLE_HOME_2 で、次の手順を実行します。

1. $ORACLE_HOME_2/bin/oidcaを実行して、Oracle Internet Directory Configuration Assistant（OIDCA）を起動します。

「ようこそ」画面が表示されます。


3. 「既存の OID のアップグレード」オプションを選択して、「次へ」をクリックします。

「データベースの移行」画面が表示されます。

4. アップグレード対象のデータベース（アップグレード対象の OID が稼動していたデータベース）に関する次の情報を指定します。

� 旧 OID データベースのデータベース SID

� データベース・ユーザー、SYSTEM および ODS のパスワード

� 旧バージョンの OID の Oracle ホーム

� 旧 OID データベース用の init.oraファイルの保存場所（例 : /private1/oracle/dbs/initoiddb.ora）

� OID データベース用のリスナー・ポート

� OID データベース用の接続文字列


「アップグレード中」ウィンドウが表示されます。



6. 「Oracle Internet Directory 資格証明」画面で、OID サーバーに関する次の情報を指定します。

� OID サーバーの起動が必要な非 SSL ポート。デフォルト値は 389 に指定されています。

� OID サーバーの起動が必要な SSL ポート。デフォルト値は 636 に指定されています。

� スーパー・ユーザーの識別名（DN）。

� 対応するスーパー・ユーザー・パスワード。


ルート Oracle コンテキストおよび Directory Integration Platform 関連の情報がアップグレードされます。

8. 「Upgrading Subscriber」画面で、所属組織のルートを識別する識別名（DN）を指定します（例 : o=acme、dc=com）。このドメインは、デフォルトのサブスクライバ・ノードになります。このサブスクライバの下に、Oracle コンテキストがサブスクライバとして作成されます。


「User Data Migration」画面が表示されます。

10. ユーザー・データの移行を OIDCA による処理の一部として実行する場合は、「はい」を選択します。（ユーザー数が 10,000 を超える）大規模なディレクトリを使用している場合、この処理はアップグレード後の手順として実行することを強くお薦めします。 OIDCA の外部でユーザーの移行を実行する方法の詳細は、「ユーザー・データのアップグレード」を参照してください。

アップグレードが完了します。

11. Oracle Internet Directory Configuration Assistant を終了します。

OID が稼動して、指定した非 SSL ポートおよび SSL ポートをリスニングします。

注意注意注意注意 : 既存の Oracle コンテキストを持たないか、またはリリース9.0.0.0.0 以上の Oracle コンテキストを持っているドメインを選択することをお薦めします。リリース 9.0.0.0.0 以上の Oracle コンテキストは、アップグレード可能です。一方、リリース 8.1.6.0.0 の Oracle コンテキストは、アップグレードされません。



リリースリリースリリースリリース 3.0.1.* からからからから 9.0.1.2.0 へのアップグレードへのアップグレードへのアップグレードへのアップグレードORACLE_HOME_2 で、次の手順を実行します。

1. $ORACLE_HOME_2/bin/oidcaを実行して、Oracle Internet Directory Configuration Assistant（OIDCA）を起動します。

「ようこそ」画面が表示されます。


3. 「既存の OID のアップグレード」オプションを選択して、「次へ」をクリックします。

4. 「データベースの移行」画面が表示されます。

5. アップグレード対象のデータベース（アップグレード対象の OID が稼動していたデータベース）に関する次の情報を指定します。

� 旧 OID データベースのデータベース SID

� データベース・ユーザー、SYSTEM および ODS のパスワード

� 旧バージョンの OID の Oracle ホーム

� 旧 OID データベース用の INIT.ORAファイルの保存場所（例 : /.../oracle/dbs/initoiddb.ora）

� OID データベース用のリスナー・ポート

� OID データベース用の接続文字列


OID データベースが ORACLE_HOME_1 から ORACLE_HOME_2 に移行されます。

7. 別に表示されるウィンドウで、次に示す手順に従って、9.0.1.2.0 パッチを適用します。

a. OID 3.0.1.x からアップグレードする場合は、ORACLE_HOME_1 のデータベースを停止します（まだ稼動している場合）。次に、データベースを ORACLE_HOME_2環境から起動して、データベースの移行を完了します。

b. ORACLE_HOME_1 のリスナーを停止します。

c. $ORACLE_HOME_1/network/admin/tnsnames.oraにある旧 OID データベース用のリスナー・エントリを $ORACLE_HOME_2/network/admin/tnsnames.oraにコピーします。

d. $ORACLE_HOME_1/network/admin/listerner.oraにある旧 OID データベース用のリスナー・エントリを $ORACLE_HOME_2/network/admin/listener.oraにコピーします。

e. ORACLE_HOME_2 でリスナーを起動します。

f. 9.0.1.2.0 データベース・パッチ・セットを適用するには、InteroperaPatch のreadme.htmの説明に従います。



g. 「次へ」をクリックします。

「アップグレード中」ウィンドウが表示されます。

8. 「Oracle Internet Directory 資格証明」画面で、OID サーバーに関する次の情報を指定します。

� OID サーバーの起動が必要な非 SSL ポート。デフォルト値は 389 に指定されています。

� OID サーバーの起動が必要な SSL ポート。デフォルト値は 636 に指定されています。

� スーパー・ユーザーの識別名（DN）。

� 対応するスーパー・ユーザー・パスワード。


ルート Oracle コンテキストおよび Directory Integration Platform 関連の情報がアップグレードされます。

10.「Upgrading Subscriber」画面で、所属組織のルートを識別する識別名（DN）を指定します（例 : o=acme、dc=com）。このドメインは、デフォルトのサブスクライバ・ノードになります。このサブスクライバの下に、Oracle コンテキストがサブスクライバとして作成されます。


「User Data Migration」画面が表示されます。

12. ユーザー・データの移行を OIDCA による処理の一部として実行する場合は、「はい」を選択します。（ユーザー数が 10,000 を超える）大規模なディレクトリを使用している場合、この処理はアップグレード後の手順として実行することをお薦めします。 OIDCAの外部でユーザーの移行を実行する方法の詳細は、「ユーザー・データのアップグレード」を参照してください。

アップグレードが完了します。

13. Oracle Internet Directory Configuration Assistant を終了します。

OID サーバーが稼動して、指定した非 SSL ポートおよび SSL ポートをリスニングします。

注意注意注意注意 : 既存の Oracle コンテキストを持たないか、またはリリース9.0.0.0.0 以上の Oracle コンテキストを持っているドメインを選択することをお薦めします。リリース 9.0.0.0.0 以上の Oracle コンテキストは、アップグレード可能です。一方、リリース 8.1.6.0.0 の Oracle コンテキストは、アップグレードされません。



マルチノード環境でのアップグレードマルチノード環境でのアップグレードマルチノード環境でのアップグレードマルチノード環境でのアップグレードレプリケーション環境における複数ノードの OID システムのアップグレードには、特別な注意が必要です。この項では、複数ノードの OID システムをアップグレードする 2 つの方法について説明します。

一度に一度に一度に一度に 1 つのノードをアップグレードする場合つのノードをアップグレードする場合つのノードをアップグレードする場合つのノードをアップグレードする場合この方法を使用すると、レプリケート・ネットワークの完全停止を回避できます。他のノードを使用可能な状態のまま残しながら、1 つのノードをアップグレードできます。次の点に注意してください。

� すべてのノードをアップグレードするまでは、アップグレードは完了しません。ただし、この間に、アップグレード中のノードを除き、すべてのネットワーク・ノードは使用可能な状態のまま残ります。

� 他のサイトをアップグレードする前に、マスター定義サイト（MDS）でアップグレードを実行する必要があります。

� アップグレード中は、1 つのノードのみを読取り / 書込みモードにします。残りのノードは、すべて読取り専用モードに設定します。

1. 次の手順に従って、ノードを読取り専用モードに変更します。

a. 次のようにして、入力ファイル inputfile.ldifを作成します。

dn:changetype: modifyreplace: orclservermodeorclservermode:r

b. 次のコマンドを使用して、ノードを読取り専用モードに変更します。

$ORACLE_HOME_1/bin/ldapmodify -D super-user DN -w super-user password -h hostname -p port -f inputfile.ldif

2. 次の手順に従って、ノードをアップグレードします（各ノードで、この手順を繰り返します）。

a. すべての OID プロセスを停止します。

b. $ORACLE_HOME_1/ldap/admin/delasrjobs.sqlを実行して、ASR プッシュ・ジョブを一時的に削除します。このスクリプトによって、変更を MDS にプッシュする他のマスター・サイト上の Oracle9i レプリケーション・ジョブが削除されます。これらのジョブを一時的に削除すると、現行のノードがレプリケーション環境から削除され、そのノードに対しては変更が適用されません。一方、他のノードは稼動中のまま残り、変更のレプリケートが継続して実行されます。



3. ノードを OID 9.0.2.1.0 にアップグレードします。アップグレードする手順は、7-15 ページの「一度に 1 つのノードをアップグレードする場合」および 7-16 ページの「レプリケート環境の下位互換性」を参照してください。

4. アップグレードの完了後、OID データベース、リスナーおよび OID プロセス（OID モニター、OID サーバー、ディレクトリ統合サーバー）がすべて稼動していることを確認します。

5. $ORACLE_HOME_2/ldap/admin/delasrjobs.sqlを実行して、ASR プッシュ・ジョブをもう一度作成します。削除した ASR ジョブがリストアされます。アップグレードされたノードにおける変更は、ネットワーク上にあるその他のノードにプッシュされます（逆もまた同様です）。これで、アップグレードされたノードは、レプリケート・ネットワークに戻ります。

レプリケート環境の下位互換性レプリケート環境の下位互換性レプリケート環境の下位互換性レプリケート環境の下位互換性前述のように、すべてのノードをアップグレードするまでは、アップグレードは完了しません。

既存のディレクトリ・レプリケーション・グループ（DRG）をアップグレードしている場合、新しくアップグレードされた OID 9.0.2.1.0 に対する変更の一部は、アップグレードされていない旧バージョンのノードにはレプリケートされません。これらの変更は、終的にコンシューマ・ノードが 9.0.2.1.0 にアップグレードされたときに、正常にレプリケートされます。

可能な場合は、DRG のアップグレード時に次の制限を適用します。

� DRG のすべてのノードがアップグレードされるまでは、DRG の中でアップグレードされたノードに対して LDAP 操作を実行しないこと。

� アップグレードされたノードを更新する必要がある場合、その他のノードがアップグレードされるまでは、その変更をそれらのノードに対してプッシュしないこと。

そのためには、レプリケーション・サーバーを特別なモード（-o FALSE）で起動して、特定のノードによる変更のプッシュを一時的に無効にします。レプリケーション・サーバーをこのモードで起動するには、次のコマンドを実行します。

$ORACLE_HOME/bin/oidctl connect=connect string server=oidrepld instance=1 flags="-p port -h host -o FALSE " start

旧バージョンのノードで行われた変更は、いずれも新しいリリース 9.0.2.1.0 のノードに正常にレプリケートされます。



同時にすべてのノードをアップグレードする場合同時にすべてのノードをアップグレードする場合同時にすべてのノードをアップグレードする場合同時にすべてのノードをアップグレードする場合一度にすべてのノードをアップグレードする方法を使用すると、下位互換性の問題を回避できます。ただし、この方法でアップグレードする場合には、一定の時間、レプリケート・ネットワークを完全に停止する必要があります。停止しても支障がない場合には、この方法の使用をお薦めします。

この方法では、すべてのノードを読取り専用にする必要があるため、すべてのノードにあるすべての OID プロセスが停止することになります。このレプリケート・ネットワークは、アップグレード・プロセス中には使用不能となります。

1. 次の手順に従って、ノードを読取り専用モードに変更します。

a. 次のようにして、入力ファイル inputfile.ldifを作成します。

dn:changetype: modifyreplace: orclservermodeorclservermode:r

b. 次のコマンドを使用して、ノードを読取り専用モードに変更します。

$ORACLE_HOME_1/bin/ldapmodify -D super-user DN -w super-user password -h hostname -p port -f inputfile.ldif

2. 各ノードの変更ログ・キューが空の場合、OID サーバーおよび各ノードのすべての OIDプロセスと対応するデータベースを停止します。

3. 各ノードを OID 9.0.2.1.0 にアップグレードします。アップグレードする手順は、7-15ページの「一度に 1 つのノードをアップグレードする場合」および 7-16 ページの「レプリケート環境の下位互換性」を参照してください。

アップグレード後の作業アップグレード後の作業アップグレード後の作業アップグレード後の作業アップグレードが完了したら、次の作業を実行します。

JOB_QUEUE_PROCESSES パラメータの設定パラメータの設定パラメータの設定パラメータの設定DRG のすべてのノードで、データベースの init.ora ファイルの JOB_QUEUE_PROCESSESパラメータに次の値を設定します。

� シングル・ノード環境の場合は、1 以上の値を設定します。

� マルチノード環境の場合は、ノードの数を設定します。



ユーザー・データのアップグレードユーザー・データのアップグレードユーザー・データのアップグレードユーザー・データのアップグレードシングル・ノード環境でのアップグレードを実行している場合は、この作業を実行する必要があります。マルチノード環境の場合、この作業はマスター定義サイト（MDS）でのみ必要です。 OIDCA でユーザー・データの移行を実行した場合は、この項をスキップします。

パスワードの変換パスワードの変換パスワードの変換パスワードの変換

OID 9.0.2.1.0 のパスワード・フォーマットは、BASE64 です。したがって、16 進数で格納されている旧バージョンのパスワードを変換する必要があります。変換するには、次の手順に従います。

1. 次のコマンドを使用して ldapsearchを実行し、暗号化されているすべてのユーザー・パスワードをファイルに出力します。この場合、出力ファイルとして $ORACLE_HOME_2/ldap/install/pwdin.ldifファイルを使用しています。

$ORACLE_HOME_2/bin/ldapsearch –L –h OID host name -p OID Non-SSL port -D OID Super User DN-w OID Super User Password -b "" –s sub "objectclass=*" dn userpassword > $OH/ldap/install/pwdin.ldif

2. 次のコマンドを発行し、passwordconvert ツールを使用して、$ORACLE_HOME_2/ldap/install/pwdin.ldifにあるユーザー・パスワードを変換し、$ORACLE_HOME_2/ldap/install/pwdout.ldifに出力します。

$ORACLE_HOME_2/bin/passwordconvert –m hex2base64 –f modify $ORACLE_HOME_2/ldap/install/pwdin.ldif $ORACLE_HOME_2/ldap/install/pwdout.ldif

3. 次のコマンドを発行し、ldapmodify を使用して、BASE64 に基づいてエンコードされた$ORACLE_HOME/ldap/install/pwdout.ldif にあるユーザー・パスワードを OID にアップロードします。

$ORACLE_HOME_2/bin/ldapmodify –h OID host name -p OID Non-SSL port -D OID Super User DN-w OID Super User Password> -f $ORACLE_HOME_2/ldap/install/pwdout.ldif

Oracle コンテキストの設定コンテキストの設定コンテキストの設定コンテキストの設定Oracle コンテキストを設定するには、Oracle Directory Manager（ODM）を使用します。

ルートルートルートルート Oracle コンテキストの設定コンテキストの設定コンテキストの設定コンテキストの設定

DN "cn=Common, cn=Products, <Root Oracle Context DN>” の下にあるルートOracle コンテキストに、次の情報を追加する必要があります。デフォルトでは、ルートOracle コンテキストの DN は "cn=OracleContext" になっています。次の属性値が必要です。

� orclSubscriberSearchBase - ディレクトリ情報ツリー内でサブスクライバを検索するときのベース・ノードを示します。

� orclSubscriberNickNameAttribute - サブスクライバ検索ベースの下にあるサブスクライバを検索するときに使用するニックネーム属性を示します。



� orclDefaultSubscriber - 所属組織のルートを示します。この値は、7-13 ページの「リリース 3.0.1.* から 9.0.1.2.0 へのアップグレード」で指定した値と同じになります。

デフォルトのサブスクライバデフォルトのサブスクライバデフォルトのサブスクライバデフォルトのサブスクライバ Oracle コンテキストの設定コンテキストの設定コンテキストの設定コンテキストの設定

DN “cn=Common, cn=Products, cn=oracleContext, <Subscriber DN>” の下にあるサブスクライバ固有の Oracle コンテキストに、次の情報を追加する必要があります。

� orclCommonUserSearchBase - サブスクライバ・サブツリー内でユーザーを検索するときのベース・ノードを示します。アップグレード時に、この属性値はサブスクライバDN に設定されます。

� orclCommonNickNameAttribute - サブスクライバ・サブツリー内でグループを検索するときのベース・ノードを示します。

� orclCommonGroupSearchBase - すべてのグループが配置されているディレクトリ情報ツリー内のノードを示します。

パスワード・ポリシーの設定パスワード・ポリシーの設定パスワード・ポリシーの設定パスワード・ポリシーの設定

パスワード・ポリシーが旧バージョンの OID に存在する場合（DN cn=pwdpolicyentry, cn=oracle internet directoryの下に配置されています）、そのポリシーはルートOracle コンテキストとデフォルトのサブスクライバ Oracle コンテキストの両方に適用されます。前のバージョンにおける、そのポリシーを含む元の DN cn=pwdpolicyentry, cn=oracle internet directoryは削除されます。

それ以外の場合は、サブスクライバ Oracle コンテキストの作成処理の中で、デフォルトのパスワード・ポリシーが設定されます。デフォルトでは、デフォルト・サブスクライバのパスワード・ポリシーは次の値に設定されます。

� ユーザー・パスワードの有効期間は、60 日です（pwdmaxage=5184000）。

� 10 回連続してログインに失敗すると、アカウントはロックアウトされます（pwdlockout=1 および pwdmaxfailure=10）。

� パスワードの構文チェックは有効になっており、ユーザー・パスワードの小文字数は5 文字です（pwdchecksyntax=1 および pwdminlength = 5）。

� ユーザー・パスワードには、1 つ以上の数字が含まれている必要があります（orclpwdalphanumeric=1）。

（これらの属性値は、エントリ cn=PwdPolicyEntry, cn=Common,cn=Products,cn=oracleContext,subscriber DNにあります。）

注意注意注意注意 : この属性値が設定されていない場合、ルート Oracle コンテキストの下にあるパスワード・ポリシーが適用されます。

関連項目関連項目関連項目関連項目 : 『Oracle Internet Directory 管理者ガイド』



ルート Oracle コンテキストの下にあるパスワード・ポリシーは、ルート DSE の下にあるすべてのエンティティに適用されます。ただし、ルート Oracle コンテキストの下にあるエンティティには適用されません。

アップグレードした OID を Oracle9iAS リリース 2（9.0.2）の他のコンポーネントと統合する場合は、適切なアクセス制御ポリシー（ACP）を設定して、必要な権限をそれらのコンポーネントに付与する必要があります。

アップグレード後の手動による作業およびデータベース移行時のアップグレード後の手動による作業およびデータベース移行時のアップグレード後の手動による作業およびデータベース移行時のアップグレード後の手動による作業およびデータベース移行時の代替方法代替方法代替方法代替方法

サーバー管理サーバー管理サーバー管理サーバー管理

アップグレード後に、targets.xmlにある OID ターゲットを手動で更新して、適切なORACLE_SID、および ods と emd 管理者のユーザー・パスワードを指定する必要があります。

ディレクトリ統合サーバーディレクトリ統合サーバーディレクトリ統合サーバーディレクトリ統合サーバー

アップグレード時に、Directory Integration Platform（DIP）サーバーは起動されません。 Directory Integration Platform を使用するには、DIP サーバーを明示的に登録して起動する必要があります。

データベースのインポートデータベースのインポートデータベースのインポートデータベースのインポート / エクスポートによるアップグレードエクスポートによるアップグレードエクスポートによるアップグレードエクスポートによるアップグレード

データベースのインポート / エクスポートを利用したアップグレード・プロシージャを使用することもできます。これによって、OID のバージョン間での移行をより柔軟に実行できます。データベースの移行は必要ありません。


関連項目関連項目関連項目関連項目 : 『Oracle9i Application Server セキュリティ・ガイド』

関連項目関連項目関連項目関連項目 : 『Oracle Internet Directory リリース・ノート』




E-Business 統合コンポーネントの

8
E-Business 統合コンポーネントの移行統合コンポーネントの移行統合コンポーネントの移行統合コンポーネントの移行
この章では、E-Business 統合コンポーネントを移行する方法について説明します。この章の項は次のとおりです。

� Oracle9iAS InterConnect の移行

� ハブ・コンポーネントの移行

� メタデータの移行

� アダプタの移行

� iStudio および SDK の移行

� 管理の移行

� Oracle Workflow の移行

移行 8-1

Oracle9iAS InterConnect の移行

Oracle9iAS InterConnect の移行の移行の移行の移行この項では、Oracle9iAS InterConnect を移行する方法について説明します。（スキーマは、新しいリリース 2（9.0.2）のデータベースにあります。）

ハブ・コンポーネントの移行ハブ・コンポーネントの移行ハブ・コンポーネントの移行ハブ・コンポーネントの移行1. Oracle9iAS InterConnect リリース 1（1.0.2.2）のインストール環境と一致するように、

リリース 2 のインストール環境を構成します。次の点に注意してください。

� リリース 2 の Infrastructure データベースは、リリース 1 の Hub データベースに対応しています。

� Oracle9iAS の中間層の Oracle ホームは、Oracle9iAS リリース 1（1.0.2.2.x）のリポジトリがインストールされている Oracle ホームに対応しています。

2. Oracle9iAS InterConnect Hub を Oracle9iAS の中間層の Oracle ホームにインストールします。

これで、Oracle9iAS InterConnect リポジトリ、Workflow および Workflow Communication がインストールされます。デフォルトでは、これらのコンポーネントはInfrastructure データベースにあるスキーマを指定します。

メタデータの移行メタデータの移行メタデータの移行メタデータの移行1. リリース 1 のインストール時に提供された oaiexport スクリプトを実行します。次のコ

マンドを使用して、リポジトリ名、ファイル名、システム・パスワードおよび接続文字列の各値を指定します。

ORACLE_HOME_1/oai/4.1/repository/repository name/oaiexport file name system/system password connect string

メタデータは、カレント・ディレクトリにあるファイルにエクスポートされます。

2. リリース 2 のインストール時に提供された oaiimport スクリプトを実行します。次のコマンドを使用して、リポジトリ名、ユーザーからのファイル名（インポートするメタデータのユーザー ID）、システム・パスワード、oaihub902 スキーマ・パスワードおよび接続文字列の各値を指定します。

ORACLE_HOME_2/oai/9.0.2/repository/oaiimport file name from user system/system password oaihub902 schema password connect string

ファイルは、Oracle9iAS リリース 2（9.0.2）の Infrastructure データベースにインポートされます。



3. SQL*Plus を使用して、Infrastructure データベースの Hub スキーマに接続し、次のコマンドを実行します。

update emd set type='AQ' where type='XML' commit;

アダプタの移行アダプタの移行アダプタの移行アダプタの移行1. 所有している既存のアダプタに対応する Oracle9iAS InterConnect 902 アダプタをインス

トールします。 Hub データベースの情報が求められると、Oracle9iAS リリース 2（9.0.2）の Infrastructure データベースが参照されます。

2. その他すべての情報を要求するプロンプトが表示されたら、既存の構成から値を指定します。

iStudio およびおよびおよびおよび SDK の移行の移行の移行の移行1. Oracle9iAS InterConnect Developer Kits 902 をインストールします。これには、新しい

バージョンの iStudio および SDK が含まれています。 iStudio プロジェクトを作成するときに、Hub データベース情報が求められると、Oracle9iAS リリース 2（9.0.2）のInfrastructure データベースが参照されます。

管理の移行管理の移行管理の移行管理の移行1. Oracle Enterprise Manager コンソールリリース 902 をインストールします。

これで、Oracle9iAS InterConnect 用に正しく構成された Oracle Enterprise Manager が使用可能になります。

E-Business 統合コンポーネントの移行 8-3


Oracle Workflow の移行の移行の移行の移行Oracle Workflow を Oracle9iAS リリース 1.0.2.2 からリリース 2（9.0.2）に移行するには、次の手順に従います。

1. Oracle Workflow を Oracle9iAS リリース 2（9.0.2）とともにインストールします。これには、『Oracle9i Application Server インストレーション・ガイド』で説明しているように、インストール前およびインストール後に行うすべての手順が含まれています。

このインストールによって、データベースにあるサーバー・バージョンの Oracle Workflow が更新されます。詳細は、『Oracle9i Application Server インストレーション・ガイド』を参照してください。

2. リリース 2 のインストール用に、Workflow のセットアップ手順をすべて実行します。実行方法は、『Oracle Workflow Guide』の「Setting Up Oracle Workflow」を参照してください。特に、次を確認してください。

� グローバルな Workflow 作業環境の適切な設定

� Oracle Workflow 用のディレクトリ・サービスのセットアップ

� 通知メーラーを実行するために使用するパラメータを含む、通知メーラー用新規構成ファイルの作成

3. カスタマイズしたファイルを ORACLE_HOME_1 から ORACLE_HOME_2 にコピーします。コピーするファイルには、次が含まれます。

� ワークフロー・プロセス定義ファイル（$ORACLE_HOME_1/wf/res/langにある.wftファイル）

� ビジネス・イベント・システム定義ファイル（$ORACLE_HOME_1/wf/res/langにある .xmlファイル）

� SQL スクリプト（$ORACLE_HOME_1/wf/sql/にある .sqlファイル）

� カスタム・ヘルプ・ファイル（$ORACLE_HOME_1/wf/doc/lang/wfcustにある.htmファイルまたは $ORACLE_HOME_1/wf/res/langにある .hlp ファイル）

� カスタマイズを含むその他のファイル


索引索引索引索引
記号記号記号記号_default.properties ファイル，4-31，4-32_pages ディレクトリ
Migration Assistant，2-3場所，3-8

数字数字数字数字8.1.7.1.0 パッチセット、1.0.2.2.x データベース，5-3

Aafter_proc DAD パラメータ，4-7alias_translation JServ パラメータ，3-14always_describe DAD パラメータ，4-7application.xml ファイル，3-17，3-24

BBACKGROUND コマンドライン・オプション

（Reports），6-19before_proc DAD パラメータ，4-7bind_bucket_lengths DAD パラメータ，4-8bind_bucket_widths DAD パラメータ，4-8bypass_source JServ パラメータ，3-14

Ccache_dir 中間層キャッシュ・パラメータ，4-12cacheBuffer パラメータ（Portal），4-4cache.cfg ファイル，4-13CGI

Forms Services，6-2，6-4Migration Assistant，2-3

cgi_env_list DAD パラメータ，4-8cgicmd.dat ファイル（Reports），6-16checkPageScope，3-9classpath

JServ パラメータ，3-14サブ要素，3-27

cleanup_interval 中間層キャッシュ・パラメータ，4-12cleanup_size 中間層キャッシュ・パラメータ，4-12configuration.xml ファイル，6-23connect_string DAD パラメータ，4-7Cookie、セッション定義（Web Cache），2-14CPU，2-17CURRENCY コマンドライン・オプション（Reports），

6-19custom_auth DAD パラメータ，4-8

DdadMigration スクリプト，4-11dads.conf ファイル，4-11DAD パラメータ，4-7

after_proc，4-7always_describe，4-7before_proc，4-7bind_bucket_lengths，4-8bind_bucket_widths，4-8cgi_env_list，4-8connect_string，4-7custom_auth，4-8debugModules，4-7default_page，4-7document_path，4-7document_proc，4-7document_table，4-7enablesso，4-7

索引索引索引索引 -1

error_style，4-8exclusion_list，4-8nls_lang，4-8password，4-7pathalias，4-7pathaliasproc，4-7PlsqlAfterProcedure，4-7PlsqlAlwaysDescribeProcedure，4-7PlsqlAuthenticationMode，4-7，4-8PlsqlBeforeProcedure，4-7PlsqlBindBucketLengths，4-8PlsqlBindBucketWidths，4-8PlsqlCGIEnvironmentList，4-8PlsqlCompatibilityMode，4-9PlsqlDatabaseConnectString，4-7PlsqlDatabasePassword，4-7PlsqlDatabaseUserName，4-7PlsqlDefaultPage，4-7PlsqlDocumentPath，4-7PlsqlDocumentProcedure，4-7PlsqlDocumentTablename，4-7PlsqlErrorStyle，4-8PlsqlExclusionList，4-8PlsqlFetchBufferSize，4-8PlsqlLogEnable，4-7PlsqlMaxRequestsPerSession，4-7PlsqlNLSLanguage，4-8PlsqlPathAlias，4-7PlsqlPathAliasProcedure，4-7PlsqlSessionCookieName，4-8PlsqlSessionStateManagement，4-8PlsqlUploadAsLongRaw，4-7response_array_size，4-8reuse，4-7sncookiename，4-8stateful，4-8upload_as_long_raw，4-7username，4-7

Database Configuration Assistant（DBCA）（OID），

7-9data-sources.xml ファイル，2-12，3-24DBPersonalizationManager，4-26DBPersonalizationManager2，4-26debug_mode JServ パラメータ，3-14debugModules DAD パラメータ，4-7DECIMAL コマンドライン・オプション（Reports），

6-19

default_page DAD パラメータ，4-7default.env，6-6default-web-site.xml ファイル，3-24demo ディレクトリ、Migration Assistant，2-3developer_mode JServ パラメータ，3-14Directory Integration Platform（DIP）（OID），7-20disco4iv.xml ファイル，6-23document_path DAD パラメータ，4-7document_proc DAD パラメータ，4-7document_table DAD パラメータ，4-7doc ディレクトリ、Migration Assistant，2-3

EEAR ファイル，3-17，4-29emit_debuginfo JServ パラメータ，3-14enabled 中間層キャッシュ・パラメータ，4-12enablesso DAD パラメータ，4-7encodeURL() メソッド，3-38ERRFILE コマンドライン・オプション（Reports），

6-19error_style DAD パラメータ，4-8exclusion_list DAD パラメータ，4-8EXPORT ユーティリティ（Oracle Database Server），

7-2external_resource JServ パラメータ，3-14

Ffastcgi、Migration Assistant，2-3FilePersonalizationManager，4-26Forms CGI，6-4Forms URL，6-5formsweb.cfg ファイル，6-4

Gglobals.jsa，3-3

～からの移行，3-7複数のアプリケーションやセッションのサポート，

3-6global-web-application.xml ファイル，3-24GUI レポート・プレビューア，6-19


HHost ヘッダー（Web Cache），2-14HTML コメント，3-5HTTP 1.1，4-5httpd.conf ファイル，3-30，4-17，4-39HttpSessionBindingListener，3-9httpsports パラメータ（Portal），4-4HTTP リクエスト・オブジェクト，3-3

Iifcgi60.exe ファイル，6-4Include ディレクティブ

構文，3-6ネスト，3-15ページ・ヘッダー，3-5

Infrastructure インストール（OID），7-9Infrastructure のオプション、Oracle9iAS，7-8internal.xml ファイル、Migration Assistant，2-14iStudio，8-3

JJ2EE 準拠、Migration Assistant，2-12JAAS セキュリティ・サービス，3-48JAAS セキュリティの移行，3-48JAVA13_HOME 環境変数（Wireless），5-3javaccmd JServ パラメータ，3-14javax.servlet.ServletRequest クラス，3-18Java インタフェース，4-19JInitiator

アップグレード，6-23バージョン（Forms），6-7

jpdk.ear ファイル，4-14JServ

Migration Assistant，2-6OC4J との共存，3-51，4-22設定，3-51，4-21パラメータ

alias_translation，3-14bypass_source，3-14classpath，3-14debug_mode，3-14developer_mode，3-14emit_debuginfo，3-14external_resource，3-14

javaccmd，3-14send_error，3-14session_sharing，3-14sqljcmd，3-14translate_params，3-14unsafe_reload，3-14セキュリティ，3-29

jserv.conf ファイル，3-30Migration Assistant，2-3

jserv.properties ファイル，3-28jsp_precompile 設定，3-15JspScopeListener，3-9JSP コンテナ，3-2

移行についての留意点，3-4JVM の環境変数，3-28

KKEYIN コマンドライン・オプション（Reports），6-19KEYOUT コマンドライン・オプション（Reports），

6-19

LLOGFILE コマンドライン・オプション（Reports），

6-19logmode パラメータ（Portal），4-4logpath パラメータ（Portal），4-4

Mmain_mode Oracle JSP パラメータ，3-15manual ディレクトリ、Migration Assistant，2-3minTimeout パラメータ（Portal），4-4mod_ossl、Migration Assistant，2-8mod_plsql

DAD パラメータ，4-7Migration Assistant，2-6推奨されていないパラメータ，4-9

mod_proxy ディレクティブ、Migration Asssistant，2-7

mtrexp スクリプト（Personalization），6-26mtrimp スクリプト（Personalization），6-26

Nnls_lang DAD パラメータ，4-8


Oobe60 クエリービルダー（Reports），6-19obs60 スキーマ・ビルダー（Reports），6-19OC4J

JServ との共存，3-51，4-22JSP コンテナ，3-4移行，2-10セキュリティ，3-48ルート・ディレクトリ，3-25

OC4J でのフォルト・トレランス，3-41OC4J でのロード・バランシング，3-41OC4J でのロギング，3-40OC4J の環境変数，3-28offlinePath パラメータ（Portal），4-4OID プロセス，7-10ojspc 変換前処理ユーティリティ，3-16ojsp-global-include.xml，3-10old_include_from_top Oracle JSP パラメータ，3-15OLE2 オブジェクト・サポート（Reports），6-19omsconfig.properties ファイル，7-7omsconfig.properties ファイル（OEM），7-3onlineorders_html ディレクトリ、Migration

Assistant，2-3opdowngrd スクリプト（Personalization），6-28opmn.xml ファイル，3-29opupgrd スクリプト（Personalization），6-27Oracle Data Migration Assistant（ODMA），7-11Oracle Directory Manager（ODM）（OID），7-18Oracle Enterprise Manager，8-3

Configuration Assistant，7-2Oracle Internet Directory

Infrastructure の一部，7-8Wireless リポジトリからの移行，5-10

Oracle Internet Directory Configuration Assistant（OIDCA），7-10

Oracle JDBC，4-22Oracle JSP，3-4，4-22Oracle JSP パラメータ

main_mode，3-15old_include_from_top，3-15precompile_check，3-15reduce_tag_code，3-15req_time_introspection，3-15static_text_in_chars，3-15tags_reuse_default，3-15xml_validate，3-15

Oracle Universal Installer，2-20CD-ROM のマウント，2-20起動，2-20手動マウント，2-20

Oracle Workflow，8-4Oracle XML Parser V2，4-22oracle_apache.conf、Migration Assistant，2-3ORACLE_HOME 環境変数（Wireless），5-3Oracle9iAS Migration Assistant

GUI バージョン，2-27インストール，2-17コマンドライン・バージョン，2-34再起動，2-37

oracle.jsp.JspServlet，3-7oracle.jsp.runtimev2.JspServlet，3-13oracle.jsp.tags.reuse，3-19oracle.jsp.util.PublicUtil.setReqCharacterEncoding()，

3-18oradav.conf ファイル，4-11Orion JSP コンテナ，3-4orion-web.xml ファイル，3-17outOfScope() メソッド，3-9

Ppages ディレクトリ、Migration Assistant，2-3panama ユーザー・テーブル（Wireless），5-3Parallel Page Engine（PPE），4-3password DAD パラメータ，4-7pathalias DAD パラメータ，4-7pathaliasproc DAD パラメータ，4-7PlsqlAfterProcedure DAD パラメータ，4-7PlsqlAlwaysDescribeProcedure DAD パラメータ，4-7PlsqlAuthenticationMode DAD パラメータ，4-7，4-8PlsqlBeforeProcedure DAD パラメータ，4-7PlsqlBindBucketLengths DAD パラメータ，4-8PlsqlBindBucketWidths DAD パラメータ，4-8PlsqlCacheCleanupInterval 中間層キャッシュ・パラ

メータ，4-12PlsqlCacheCleanupSize 中間層キャッシュ・パラメー

タ，4-12PlsqlCacheDirectory 中間層キャッシュ・パラメータ，

4-12PlsqlCacheEnable 中間層キャッシュ・パラメータ，

4-12PlsqlCacheTotalSize 中間層キャッシュ・パラメータ，

4-12


PlsqlCGIEnvironmentList DAD パラメータ，4-8PlsqlCompatibilityMode DAD パラメータ，4-9PlsqlDatabaseConnectString DAD パラメータ，4-7PlsqlDatabasePassword DAD パラメータ，4-7PlsqlDatabaseUserName DAD パラメータ，4-7PlsqlDefaultPage DAD パラメータ，4-7PlsqlDocumentPath DAD パラメータ，4-7PlsqlDocumentProcedure DAD パラメータ，4-7PlsqlDocumentTablename DAD パラメータ，4-7PlsqlErrorStyle DAD パラメータ，4-8PlPlsqlExclusionList DAD パラメータ，4-8PlsqlFetchBufferSize DAD パラメータ，4-8PlsqlLogEnable DAD パラメータ，4-7PlsqlMaxRequestsPerSession DAD パラメータ，4-7PlsqlNLSLanguage DAD パラメータ，4-8PlsqlPathAlias DAD パラメータ，4-7PlsqlPathAliasProcedure DAD パラメータ，4-7PlsqlSessionCookieName DAD パラメータ，4-8PlsqlSessionStateManagement DAD パラメータ，4-8PlsqlUploadAsLongRaw DAD パラメータ，4-7plus_config.xml ファイル，6-23poolSize パラメータ（Portal），4-4Portal

イメージ・ファイル，4-39キャッシュ・ルール，4-35

Portal Configuration Interface（PCI），4-11Portal Developer Kit（PDK）for Java，4-14portal.ear ファイル，4-40portalRegistrar スクリプト（Wireless），5-6Portal の Parallel Page Engine のパラメータ

cacheBuffer，4-4httpsports，4-4logmode，4-4logpath，4-4minTimeout，4-4offlinePath，4-4poolSize，4-4prefix，4-5proxyHost，4-5proxyIgnore，4-5proxyPort，4-5queueTimeout，4-5requesttime，4-5showError，4-5stall，4-5

Portal リポジトリの移行，4-35PortletDefinition クラス，4-20

PortletInstance クラス，4-20precompile_check Oracle JSP パラメータ，3-15prefix パラメータ（Portal），4-5prinicpals.xml ファイル，3-48PROFILE コマンドライン・オプション（Reports），

6-19provider.xml ファイル，4-25proxyHost パラメータ（Portal），4-5proxyIgnore パラメータ（Portal），4-5proxyPort パラメータ（Portal），4-5ptgUpgradeRepository スクリプト（Wireless），5-11ptgUpgrade スクリプト（Wireless），5-5

QqueueTimeout パラメータ（Portal），4-5

RREAPI.jar ファイル（Personalization），6-29reduce_tag_code Oracle JSP パラメータ，3-15remaint スクリプト（Personalization），6-25，6-27，

6-28Reports Server、Portal インスタンス，6-17req_time_introspection Oracle JSP パラメータ，3-15requestttime パラメータ（Portal），4-5response_array_size DAD パラメータ，4-8reuse DAD パラメータ，4-7rwcgi Web 実行可能ファイル（Reports），6-19rwows60 OAS カートリッジ（Reports），6-19rwrbe60 バックグラウンド・エンジン（Reports），6-19rwrunc キャラクタ・モード・ランタイム（Reports），

6-19

Ssend_error JServ パラメータ，3-14server.xml ファイル，3-17serviceid.properties ファイル，4-31Servlet

2.0，3-462.2，3-462.3，3-46

session_sharing JServ パラメータ，3-14setCharacterEncoding() メソッド，3-3，3-18showError パラメータ（Portal），4-5


Single Sign-On（SSO）Single Sign-On Server、Infrastructure の一部，7-8

Single Sign On（SSO）

Reports Server，6-17sncookiename DAD パラメータ，4-8soap.ear ファイル，3-49soap.war ファイル，3-49SQLJ，3-4sqljcmd JServ パラメータ，3-14SQLPlus，8-3SRW.SET_ATTR 組込み（Reports），6-19SSL

移行，2-8証明書、デフォルト，2-8ディレクティブ，2-9

SSLCACertificateFile，2-8SSLCACertificatePath，2-8SSLCertificateChainFile，2-8SSLCertificateChainFile、移行の値，2-8SSLWallet，2-8ssodatan スクリプト（Portal），4-12SSO サーバー（Wireless），5-3stall パラメータ（Portal），4-5stateful DAD パラメータ，4-8static_text_in_chars JSP パラメータ，3-19static_text_in_chars Oracle JSP パラメータ，3-15

Ttaglib の定義，3-4tags_reuse_default JSP パラメータ，3-19tags_reuse_default Oracle JSP パラメータ，3-15targets.xml ファイル（Wireless），5-12template.ear ファイル，4-14THOUSANDS コマンドライン・オプション

（Reports），6-19Tomcat，3-4total_size 中間層キャッシュ・パラメータ，4-12translate_params JServ パラメータ，3-14，3-18

Uui_config.xml ファイル，6-23unsafe_reload JServ パラメータ，3-14upload_as_long_raw DAD パラメータ，4-7

URLForms，6-5参照（Discoverer），6-21セッション定義のパラメータ（Web Cache），2-14パターン，3-9マッピング（JServ），3-32モバイル・ゲートウェイ（Wireless），5-6

URL の形式Page Assembler，4-36

username DAD パラメータ，4-7

Vviewer_config.xml ファイル，6-23

WWallet

移行中に生成，2-8，2-10パスワード，2-8，2-26

WAR ファイル，3-17，4-29wdbsvr.app ファイル，4-10，4-11Web Cache のキャッシュ・ルール，4-35webapp ディレクトリ、Migration Assistant，2-3WEBCACHETAG，2-14WEB-INF/ クラス・ディレクトリ，3-8WEB-INF ディレクトリ、Migration Assistant，2-3web.xml ファイル，3-17，3-24，4-31Web プロバイダ

移行，4-14サンプル，4-15ソフトウェア要件，4-22定義ファイル，4-23デフォルト，4-32デプロイ，4-29登録，4-34

Wireless プロビジョニング・プロファイル・エントリ，

5-4wwjni.jar ファイル，4-40

Xxml_validate Oracle JSP パラメータ，3-15


ああああアクセス権，1-13アクセス制御ポリシー（ACP），7-20アダプタ、InterConnect，8-3アプリケーション・ルート，3-21

いいいい依存クラス，3-8イメージ・ファイル（Portal），4-39

ええええエンコーディング，3-19エンド・ユーザー・レイヤー（Discoverer）、更新，

6-21

かかかかカスタム・ヘルプ・ファイル，8-4

きききき起動，2-20キャッシュ可能性ルール

Migration Assistant，2-16冗長の解決，2-36

キャッシュ・ルール，4-35共有オブジェクト・ファイル、Migration Assistant，

2-4

くくくくクラス

OC4J のアプリケーション構造，3-26WAR ファイル内，3-17自動再ロード，3-15ロード，3-25

クラスの自動再ロード，3-15クラスパス

OC4J，3-37ojspc フロントエンド・スクリプト，3-16機能，3-7システム，3-36ゾーン，3-36

グラフィックス、移行（Reports），6-18

グローバリゼーション，3-3，3-16，3-18グローバル・アプリケーション，3-23グローバル・インクルード，3-7，3-10，3-16

translate_params，3-13ヘッダー / フッター，3-11

ここここコンテキスト・ルート，2-13，3-3

ささささサーバー・エラー、アップグレードによるエラー

（Oracle Enterprise Manager），7-2サービス名，4-29サーブレット

2.0，3-2，3-32.1，3-32.2，3-252.3，3-2，3-3，3-25コンテキスト，3-6コンテキスト・オブジェクト，3-3ゾーンのデフォルト・マウント・ポイント，4-3フィルタ処理，3-3マッピング，3-13

サブスクライバ・ノード、デフォルト（OID），7-12

しししし実装クラス，3-8証明書、インポート，2-8

すすすすスキーマのアップグレード（OID），7-9スクリプト

dadMigration，4-11mtrexp（Personalization），6-26mtrimp（Personalization），6-26oaiexport，8-2oaiimport，8-2opdowngrd（Personalization），6-28opupgrd（Personalization），6-27portalRegistrar（Wireless），5-6ptgUpgrade（Wireless），5-5ptgUpgradeRepository（Wireless），5-11remaint（Personalization），6-25，6-27，6-28


ssodatan（Portal），4-12Workflow 移行のための SQL，8-4オブジェクトの削除（Oracle Enterprise Manager），

7-7場所（Personalization），6-25

せせせせ静的ドキュメント、Migration Assistant，2-3セキュリティ、JServ，3-29セキュリティ・リポジトリ（Portal），6-17セッション定義、移行（Web Cache），2-14セッション・トラッキング，3-38

そそそそソフトウェア要件、Migration Assistant，2-17

たたたたタグ属性の設定，3-6

ちちちち中間層キャッシュ・パラメータ，4-12抽象クラス，4-19

つつつつ通知メーラー、Oracle Workflow，8-4

ててててディレクティブ、デフォルト・セット，2-5ディレクトリ

_pages，3-8cdrom/9ias__disk1，2-20JSP ページのインクルード元，3-10クラス，3-8

ディレクトリ・サービス、Oracle Workflow，8-4ディレクトリ・レプリケーション・グループ（DRG）

（OID），7-16データの移行、ユーザー（OID），7-12データベース・スキーマ（Wireless），5-2データベースの移行（OID），7-9デフォルトのサブスクライバ，7-19

ととととドキュメント・ルート，3-3トラスト・ポイント，2-8

ははははハードウェア要件、Migration Assistant，2-17ハブ・スキーマ、InterConnect，8-3

ふふふふファイル名に空白が含まれる，4-9複数の中間層、移行手順，5-12

へへへへページ実装クラス，3-8変数宣言，3-7

ほほほほポート競合、Web Cache 移行，2-36

ままままマイニング・テーブル・リポジトリ

（Personalization），6-24マウント・ポイント，3-30マウント・ポイント、デフォルトのサーブレット・

ゾーン，4-3

めめめめ明確化（Web Cache），2-14メタデータ、InterConnect，8-2メモリー要件、Migration Assistant，2-17

もももも文字エンコーディング，3-19モジュール、デフォルト・セット，2-4モデル・オブジェクト（Wireless），5-2モバイル・ゲートウェイの URL，5-6モバイル・ゲートウェイの URL（Wireless）

URLモバイル・ゲートウェイ（Wireless），5-8


ゆゆゆゆユーザー・イグジット（Reports），6-19ユーザー・データの移行（OID），7-12

よよよよ要件

ソフトウェア、Migration Assistant，2-17ハードウェア、Migration Assistant，2-17

りりりりリクエスト・ディスパッチャ，3-3リコメンデーション・エンジン（Personalization），

6-24

るるるるルート Oracle コンテキスト，7-18ルート・コンテキスト，3-22

れれれれレポート・プレビューア，6-19

ろろろろログ・ファイル、Ultra Search 移行，4-43


Oracle9i Application Server for Sun SPARC Solaris...Oracle9i Application Server for Sun SPARC...

Documents

Transcript of Oracle9i Application Server for Sun SPARC Solaris...Oracle9i Application Server for Sun SPARC...