| Oracle® Fusion Middleware WebCenter Sitesアップグレード・ガイド 11g リリース1 (11.1.1.8.0) E49674-02 |
|
![]() 前 |
![]() 次 |
この章では、テスト環境の作成とアップグレード、テスト環境の検証、およびアクティブな環境のアップグレードについて説明します。
この章の内容は、次のとおりです。
アップグレード処理を開始する前に、次のことを確認します。
環境の必要性に応じて、第2章「現行バージョンのWebCenter Sitesにアップグレードする前に」のアップグレード前の手順を実行します。
Content ServerまたはWebCenter Sitesのデータベースの権限が『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』で推奨されているデフォルト値にリセットされていることを確認します。これは、実行中のシステムでは必要のない権限が、インストーラにとっては必要である可能性があるためです。アップグレードの完了後にこれらの権限を変更して、カスタマイズ内容を含めることができます。
クラスタ環境では、最初にプライマリ・クラスタ・メンバーをアップグレードし、その後すべてのセカンダリ・クラスタ・メンバーをアップグレードします。インストールを検証する前に、すべてのメンバーをアップグレードする必要があります。
その他の注意: WebCenter Sites 11gR1 (11.1.1.8.0)ではインタフェースに変更が加えられているため、最初にテスト環境でアップグレードを実行することを強くお薦めします。アクティブな環境のみでアップグレードを実行しようとすると、ダウンタイムがより長くなる可能性があります。
この項では、万一に備えてアクティブな環境をバックアップします。テスト環境の作成を選択した場合は、このバックアップをリカバリすることによってテスト環境を作成します。
アクティブな環境をバックアップするには
アクティブな環境内のすべてのシステムをバックアップします。これには、Content ServerまたはWebCenter Sitesのすべてのインスタンス、およびすべてのリモートのSatellite Serverが含まれます。
ガイドラインおよび具体的な手順は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』のバックアップおよびリカバリに関する章を参照してください。元のインストールにおけるバックアップおよびリカバリの手順を確認してください。それらの手順は次のガイドに記載されています。
FatWire Content Server 7.6パッチ2バックアップおよびリカバリ・ガイド
Oracle WebCenter Sites 11gR1 (11.1.1.6.1) バックアップおよびリカバリ・ガイド
必要に応じて、システムのコンテンツを別のシステムに公開することによって、アクティブな環境のすべてのシステムを同期します(たとえば、開発システムから管理システムや配信システムなどへの同期)。
すべての公開スケジュールを無効にして、公開セッションが実行されないようにします。アクティブな環境のアップグレードと検証が完了したら、公開スケジュールを再び有効にします。
カスタマイズした要素をメモしておきます。
それぞれのベーシック・アセット・タイプに関して、要素内のすべてのカスタム・コードのメモを記録しておきます(ElementCatalog表内)。
Content Server 7.6パッチ2からのアップグレードを行っており、Content Server Advanced管理インタフェースのいずれかの部分をカスタマイズしている場合は、カスタム・コードをメモしておきます。これは、既存のカスタマイズは変更されるまで動作しないためです。
WebCenter Sites 11gR1 (11.1.1.6.1)のContributorインタフェースをプログラム的にカスタマイズしている場合、それらのカスタマイズ内容は、CustomElementパスに置かれている場合にかぎりアップグレード時に保持されます。それ以外の場合、それらのカスタマイズ内容はアップグレード・プロセス時に上書きされます。開発者はバックアップしておいたインストールからカスタマイズ内容を再作成する必要があります。
すべてのイベント(検索イベントを含む)が無効であることを確認します。これは、Sites ExplorerまたはCatalogManagerから実行できます。詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。
次のアセット・タイプのリビジョン・トラッキングを無効にします。
ASSOCNAMED表
CSElement
Template
Page
|
注意: Content Server 7.6パッチ2からアップグレードする場合:
|
Webサーバーの構成、アプリケーション・サーバーの構成、データベースの構成、LDAPの構成など、既存のインストールに関するすべての情報を記録しておきます。これらはアップグレード時に変更されることはありませんが、なんらかの変更が必要な場合に既存の設定を参照する必要性が生じる場合があります(たとえば新しいキャッシュをチューニングする場合など)。
|
注意: Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x )からのアップグレードを行う場合、アクティブな環境をアップグレードする前に、テスト環境で試行アップグレードを実行してください。テスト環境が利用できない場合は、最初に開発システムのアップグレードから始めてください。この場合、より長いダウンタイムを想定してください。WebCenter Sitesに加えられる変更の度合いから判断すると、テスト環境を使用することを強くお薦めします。 |
テスト環境の作成準備が整ったら、前述の手順で作成したバックアップをリカバリします。リカバリのガイドラインは、第3.2項「アクティブな環境のバックアップ」の手順1で参照したガイドのバックアップおよびリカバリに関する章を参照してください。
FatWire Content Server 7.6パッチ2バックアップおよびリカバリ・ガイド
Oracle WebCenter Sites 11gR1 (11.1.1.6.1) バックアップおよびリカバリ・ガイド
アクティブな環境でリモートのSatellite Serverを実行している場合は、それらの中の少なくとも1つをテスト環境に複製します。
次のガイドラインを使用して、テスト環境の作成を継続します。
Content ServerまたはWebCenter Sitesでの作業:
Content ServerまたはWebCenter Sitesを、以前のホスト上にそれらが置かれていたのと同じ場所にコピーします。
ローカル・システム、およびこのアップグレードをテストする単一のリモートのSatellite Serverを除き、SystemSatellite表のエントリを消去します。
ContentServer.earファイルおよびcs.warファイル内にある次のファイル(表3-1)の中のホスト名とIPアドレスを変更します。
<cs_install_dir>ディレクトリ内にある次のプロパティ・ファイル(表3-2)の中のホスト名とIPアドレスを変更します。
WEMフレームワークをインストールしていた場合、次のファイルも編集します(表3-3)。
アプリケーション・サーバーでの作業:
以前のホストで使用したのと同じパスを使用してアプリケーション・サーバーをインストールします。
新しいデータソースを作成し、その新しいデータソースの情報を使用して、futuretense.iniファイル内の該当するデータベース・プロパティを更新します。リストアしたデータベースのデータベース情報を使用します。(データベース・プロパティは、プロパティ・エディタの「データベース」タブにリストされます。)
アプリケーション・サーバーの必要に応じて、Content ServerまたはWebCenter Sitesアプリケーションをデプロイします。
この項では、Oracle WebCenter Sites動作保証マトリックスと最新のリリース・ノートを使用して、最初に既存の環境をサポートするソフトウェアをアップグレードします。アップグレード対象となるのは、Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x )です。
|
注意: クラスタ環境向け。すべてのクラスタ・メンバーを停止します。アップグレードの準備はプライマリ・メンバーのみに対して行います。プライマリ・メンバーのアップグレードが完了したら、セカンダリ・メンバーのWebCenter Sitesもアップグレードします。 |
既存の環境のサポート・コンポーネントを、Oracle WebCenter Sites動作保証マトリックスに記載されているバージョンにアップグレードします。サポート・コンポーネントには次のものがあります。
オペレーティング・システム
アプリケーション・サーバー
Java SDK
Content ServerまたはWebCenter Sitesのデータベース
(条件付き)。LDAPサーバーおよびWebサーバー。LDAPを使用しており、LDAPサーバーのアップグレード(または変更)を決定した場合、古いサーバーから新しいサーバーにLDAPデータを手動で移行します。作業を続行する前に、LDAPデータが正しく移行されたことを確認します。
|
注意: サポート・コンポーネントの説明は、それぞれのベンダーのドキュメントを参照してください。 |
インストールが完全に機能することを確認します。
既存のインスタンスでOracleデータベースを実行している場合、Oracleデータベース・ユーザーに次のシステム権限が割り当てられていることを確認します。これらの権限は、WebCenter Sitesが動作するのに必要な権限と同じです。
GRANT UNLIMITED TABLESPACE TO <USER>;
GRANT CREATE SESSION TO <USER>;
GRANT CREATE TABLE TO <USER>;
GRANT CREATE VIEW TO <USER>;
アップグレードを通じてカスタマイズ内容が維持されるようにします。
|
注意: アップグレード時にデプロイメント・ディレクトリ内の |
カスタムのJARをデプロイしている場合、またはcs.warファイルおよびContentServer.earファイル(場所は<cs_install_dir>/ominstallinfo/app)の現在のコピーに反映されていない構成変更を行っている場合は、次の手順を実行して、現在デプロイされているContent Serverアプリケーションからクリーンなcs.warファイルおよびContentServer.earファイルを作成します。
ominstall/appからcs.warおよびContentServer.earをバックアップします。
WEMフレームワークがインストールされている場合、ominstall/ディレクトリからcas.warおよびcas.earをバックアップします。
デプロイされ、展開されているcs.warファイルを見つけ、そのファイルを圧縮します(WebCenter Sitesのインストーラによって使用されるとの同じバージョンのJARを使用します)。次に、そのファイルをominstall/appディレクトリに置きます。
バックアップしたContentServer.earファイルを専用のディレクトリに展開します。
展開されたContentServer.earファイル内の既存のファイルに新しいcs.warを上書きコピーし、このファイルを圧縮します(WebCenter Sitesのインストーラによって使用されるのと同じバージョンのJARを使用します)。
新しく圧縮されたContentServer.earをominstall/appディレクトリに配置します。
|
注意: WebCenter Sitesのインストーラは、 |
<cs_install_dir>ディレクトリ内のすべての.iniファイルをバックアップします。
プロパティ・エディタを使用して、futuretense.iniファイル内の次のプロパティの値のメモを記録しておきます。
secure.CatalogManager (「基本」タブ)
ft.sync (「クラスタ」タブ)
これらの値は、アップグレード・プロセスの中でインストーラによって変更されます。それらを元に戻す必要があります。
Content Server 7.6パッチ2からのアップグレードを行っており、システムが読取り専用のLDAPと統合されている場合、次の手順に従ってロールの追加と削除を行います。
対象の各ユーザーに対して次のロール(WebCenter Sitesの新規ロール)を追加します。
AdvancedUser: ユーザーがWebCenter Sites Adminインタフェース(以前はContent Server Advanced管理インタフェースと呼ばれていました)にログインすることを許可します。
SitesUser: ユーザーがWebCenter Sites Contributorインタフェースにログインすることを許可します。LDAPでは、SitesUserロールを手動で作成し、以前にDashUserロールが割り当てられていたすべてのユーザーに対して、このロールを割り当てる必要があります。
MobileSitesDeveloper: ユーザーがWebCenter Sites 11gR1 (11.1.1.8.0)で導入されたMobilityコンポーネントにアクセスすることを許可します。
ConnectorAdmin: WebCenter Sites Adminインタフェース内のWCC統合機能へのアクセスを許可します。
DashUserロールを削除します。このロールは、ユーザーがContent Server Dashインタフェースにログインすることを許可します。このインタフェースは削除されたため、このロールもLDAPから削除する必要があります。
|
注意: 次の項目に関して、
|
inCacheを現在使用している場合は、java tempディレクトリ内のキャッシュ・ファイルを手動で削除する必要があります。削除されるディレクトリの名前として、cascache、cscache、linkedcacheおよびsscacheがあります。
この手順では、すべてのデータベースの表のタイム・ゾーンがJVMのタイム・ゾーンに一致していることを確認します。アップグレード・プロセスでこのように一致している必要があるためです。
|
注意: 特に、分散したデータのタイムスタンプを標準化するため、JVMのタイム・ゾーンをUTC (GMT)に設定することをお薦めします。たとえば、コンテンツがロサンゼルスからニューヨークに対して公開され、いずれのサーバーもローカル時間で動作している場合、コンテンツの公開時間には3時間の差が生じます。いずれのサーバーもUTC (GMT)に設定することにより、あいまいさが解消されます。また、ログ・ファイルのデータはUTC (GMT)時間でレポートされることに注意してください。次の手順では、UTC (GMT)の設定を使用しています。クラスタのすべてのサーバーは同じタイム・ゾーンを使用することが重要です。手順全体を完了します。 リモートのSatellite Serverをアップグレードする場合、そのJVMではWebCenter SitesのJVMのタイム・ゾーンを使用するように設定します。 |
WebCenter SitesのJVMのタイム・ゾーンを変更する必要がある場合は、次のようにします(今すぐ実行するか、またはアップグレード・プロセスの中でアプリケーション・サーバーを開始する前の任意の時点で実行します)。
-Duser.timezone=<TIMEZONE_ID>
ここで、<TIMEZONE_ID>はUTCにすることをお薦めします。
リビジョン・トラッキングの表のタイム・ゾーンがJVMのタイム・ゾーンと一致していることを確認します。一致していない場合は、次の手順を実行します。
展開したインストーラのmiscディレクトリに移動し、タイム・ゾーン・ユーティリティ(sites-timezone-util.zip)を展開し、テキスト・エディタで次のいずれかのスクリプトを開きます。
Windows: tzutil.bat
UNIXまたはLinux: ./tzutil.sh
リビジョン・トラッキング用の新しいタイム・ゾーンを設定します。これを行うには、javaコマンドにデータベース接続と<DATABASEJAR>ファイルを指定し、次の変数を設定します。
... -r -d <DB_VENDOR> -o <TIMEZONE_ID> -n <TIMEZONE_ID> -p
|
注意:
リビジョン・トラッキングの表のデフォルトのタイム・ゾーンが変更されている場合は、 |
クラスパスおよび必要なデータベース・ドライバがスクリプト内で適切に設定されていることを確認します。
-pパラメータを指定してスクリプトを実行し、tzutil.logファイルを参照して、データベースに加えられることが想定される変更を確認します。
-pパラメータを指定せずにスクリプトを実行して、新しいタイム・ゾーンを使用するようにデータベース表を更新します。
すべてのデータベース表(リビジョン・トラッキングの表以外)のタイム・ゾーンがJVMのタイム・ゾーンと一致していることを確認します。一致していない場合は、スクリプトを次のように編集します。
javaコマンドから-rパラメータを削除し、次の変数を設定して、新しいタイム・ゾーンを設定します。
... -d <DB VENDOR> -o <TIMEZONE_ID> -n <TIMEZONE_ID> -p
-pパラメータを指定してスクリプトを実行し、tzutil.logファイルを参照して、データベースに加えられることが想定される変更を確認します。
-pパラメータを指定せずにスクリプトを実行して、新しいタイム・ゾーンを使用するようにデータベース表を更新します。
この手順では、WebCenter Sitesアップグレード・ユーティリティを実行して、データベース・スキーマのアップグレード前のステータスをログに記録します。インストーラによってデータベース・スキーマ(および索引)に加えられた変更を確認するため、アップグレード後にこのユーティリティを再度実行します。アップグレード・ユーティリティの詳細は、misc\upgrade-util.zip内にあるReadMeファイルを参照してください。
アップグレード・ユーティリティを実行する手順は次のとおりです。
展開したインストーラのmiscディレクトリに移動し、アップグレード・ユーティリティを展開し、次のいずれかのスクリプトを開きます。
Windows: cssystem.bat
UNIXまたはLinux: ./cssystem.sh
選択したスクリプトを編集し、システムに関する次の情報を入力します。
WebCenter Sitesのデータベース設定(ドライバ、URL、ユーザー名およびパスワード)を指定します。
データベースのタイプに対応するDATABASEJARファイルを指定します。
出力ファイルのパスを指定します。
-iパラメータを使用して、WebCenter Sitesの想定されるデプロイメント・パスを指定します。
選択したスクリプトを実行します。
スクリプトを実行すると、Systeminfo.logファイルが生成されます(\misc\ディレクトリ内)。このファイルには、想定されるWebCenter Sitesデータベース・スキーマの更新が含まれます。
|
注意: アップグレード・ユーティリティの使用方法の詳細は、 |
アプリケーション・サーバーから、WebCenter SitesおよびContent Serverの古いアプリケーションをアンデプロイします。アンデプロイの方法は、プラットフォームおよびWebCenter Sitesのバージョンに対応したインストレーション・ガイドを参照してください。WEMがインストールされたContent Server 7.6パッチ2からのアップグレード、またはWebCenter Sites 11gR1 (11.1.1.6.x )からのアップグレードを行っている場合、アプリケーション・サーバーからCASをアンデプロイし、削除します。
この項では、Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x )のそれぞれのインスタンスに対して、WebCenter Sitesアップグレード・インストーラを選択したモード(GUIモードまたはサイレント・モード)で実行します。
|
注意: 次の点を考慮してください。
|
Content ServerのインスタンスをWebCenter Sitesにアップグレードするには、次のいずれかを実行します。
WebCenter Sitesインストーラのアーカイブを一時ディレクトリに展開し、インストーラ・スクリプトを実行します。
Windows: csinstall.bat
UNIXまたはLinux: ./csInstall.sh
|
注意: アップグレード・プロセス中、およびアップグレード後のテストでは、インストーラのログ( アップグレード・パスがWebCenter Sites 11gR1 (11.1.1.6.x )から始まる場合、デフォルトのログの場所は |
アップグレードの実行時には、次の点に注意してください。
インストーラのほとんどのフィールドには、インストーラが元のインストールから検出した値があらかじめ設定されています。あらかじめ設定されている値を確認してください。それらの値が古い場合は、新しい値を設定する必要があります。(パスワードなどの情報は手動で入力する必要があります。)
変更できない値が設定されているフィールドは、入力できないようになっています(灰色になっています)。
インストーラの各画面にはオンライン・ヘルプが用意されており、画面で選択可能なオプションの詳しい説明が記載されています。アップグレード・プロセス中に問題が発生した場合は、オンライン・ヘルプを参照して、考えられる原因とその解決方法を確認してください。
プラットフォームに対応したインストレーション・ガイドを参照して、記載されているWebCenter Sitesのインストール手順を実行します。インストールが完了したら、このガイドに戻って作業を続行します。
|
注意: この時点で、アップグレード・プロセスが完了し、WebCenter Sitesの有効なインストールが実行されていると仮定します。アップグレードが失敗した場合は、前述の手順およびログを確認して、問題を解決してください。前述の手順を回復し、処理を再度開始する必要があるため、インストーラを終了しないでください。 |
WebCenter SitesおよびCASアプリケーションを再起動します。
この項では、次の手順を実行します。
<cs_install_dir>/ominstallinfoから<cs_install_dir>の外部のフォルダにomii.iniファイルをコピーし、このコピーの名前を必要に応じて変更します。サイレント・インストーラはアップグレード時にこのコピーを使用します。
FatWire Content Server 7.5の後に、ContentServerのユーザーまたはSatelliteServerのユーザーのデフォルトのユーザー名またはパスワード(またはその両方)を変更した場合は、名前変更したomii.iniファイルを開き、表3-4に記載されているプロパティを更新します。サイレント・インストーラは、これらのプロパティに指定された資格証明を参照して認証を行います。これらの資格証明が古い場合、インストーラは失敗します。
表3-4 名前変更されたomii.iniファイル内のプロパティ
| プロパティ | 説明 |
|---|---|
|
|
デフォルト値は |
|
|
暗号化されたパスワードを取得するには、Content Server(またはWebCenter Sites)のプロパティ・エディタを使用します。
|
|
|
|
この手順では、ロギング・システムを決定します。次のいずれかを実行します。
既存のロギング・システムからApache log4j (推奨)に移行する場合は、名前変更されたomii.iniファイルにConvertToLog4Jプロパティを追加し、このプロパティをtrueに設定します。
すでに手動でlog4jを構成している場合、または既存のロギング・システムを保持する場合は、omii.iniファイルにConvertToLog4Jプロパティを追加しないでください。
WebCenter SitesへのWCC統合のインストールを有効にするには、omii.iniファイルにWCCIntegration=trueプロパティを追加します。
この手順は、WEMフレームワーク(およびFatWire Content Server開発ツール、これはWEMフレームワークを必要とします)に適用されます。次のいずれかを実行します。
Content Server 7.6パッチ2からのアップグレードを行っている場合は、名前変更したomii.iniファイルに表3-5のプロパティを追加します。指定する情報は、Content Serverクラスタのプライマリ・メンバーまたはセカンダリ・メンバーのいずれに対してWEMフレームワークのインストールまたはアップグレードを行おうとしているかと、CASをクラスタ化しているかどうかに応じて異なります。
WebCenter Sites 11gR1 (11.1.1.6.x )からのアップグレードの場合は、omii.iniの中に表3-5のプロパティの値が正しく設定されていることを確認します。
表3-5 WEMのプロパティ
| プロパティ | 説明 |
|---|---|
|
WEM |
WEMフレームワークのインストールまたはアップグレードを行う場合は、このプロパティを 注意: この表に続いて、この表のプロパティを設定する方法を示した例が記載されています。それらの例は次のとおりです。 |
|
IsPrimaryClusterMember |
Content Serverのプライマリ・クラスタ・メンバーにWEMフレームワークをインストールするか、またはアップグレードする場合は、このプロパティを セカンダリ・クラスタ・メンバーにWEMフレームワークをインストールするか、またはアップグレードする場合は、このプロパティを WebCenter Sitesのクラスタ・メンバーに対する作業を行っている場合は、このプロパティは自動的に適切な値に設定されます。 |
|
CASHostNameLocal |
クラスタ化されたCAS: 内部でアクセス可能なCASロード・バランサを実行するサーバーのホスト名。 クラスタ化されていないCAS: CASがデプロイされるサーバーの内部のホスト名。 |
|
CASPortNumberLocal |
クラスタ化されたCAS: 内部でアクセス可能なCASロード・バランサを実行するサーバーのポート番号。 クラスタ化されていないCAS: CASがデプロイされるサーバーの内部のポート番号。 |
|
CASHostName |
クラスタ化されたCAS: CASロード・バランサを実行するサーバーのホスト名。 クラスタ化されていないCAS: CASがデプロイされるサーバーのホスト名。 |
|
CASPortNumber |
クラスタ化されたCAS: CASロード・バランサを実行するサーバーのポート番号。 クラスタ化されていないCAS: CASがデプロイされるサーバーのポート番号。 |
|
CASHostNameActual |
クラスタ化された/されていないCAS: CASが実際にデプロイされるサーバーのホスト名。 |
|
注意: プライマリ・クラスタ・メンバーをアップグレードする場合は、次の点に注意します。
|
WebCenter Sitesのプライマリ・クラスタ・メンバーにWEMフレームワークをインストールしている場合は、次のサンプル構成をリファレンスとして使用します。インストール・プロセスを続行する場合は、手順5にスキップします。
CASがクラスタ化されている場合:
WEM=true IsPrimaryClusterMember=true CASHostName=<host name of server with load balancer> CASPortNumber=<port number of server with load balancer> CASHostNameLocal=<host name of the internally accessible server with load balancer> CASPortNumberLocal=<port number of the internally accessible server with load balancer> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
CASがクラスタ化されていない場合:
WEM=true IsPrimaryClusterMember=true CASHostName=<host name of server on which CAS will be deployed> CASPortNumber=<port number of server on which CAS will be deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
WebCenter Sitesのセカンダリ・クラスタ・メンバーにWEMフレームワークをインストールしている場合は、次のサンプル構成をリファレンスとして使用します。インストール・プロセスを続行する場合は、手順5にスキップします。
CASがクラスタ化されている場合:
WEM=true IsPrimaryClusterMember=false CASHostName=<host name of server on which CAS has been deployed> CASPortNumber=<port number of server on which CAS has been deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
CASがクラスタ化されていない場合:
WEM=true IsPrimaryClusterMember=false CASHostName=<host name of server on which CAS has been deployed> CASPortNumber=<port number of server on which CAS has been deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
WebCenter Sitesのプライマリ・クラスタ・メンバー上のWEMフレームワークをアップグレードしている場合は、次のサンプル構成をリファレンスとして使用します。インストール・プロセスを続行する場合は、手順5にスキップします。
CASがクラスタ化されている場合:
WEM=true IsPrimaryClusterMember=true CASHostName=<host name of server with load balancer> CASPortNumber=<port number of server with load balancer> CASHostNameLocal=<host name of the internally accessible server with load balancer> CASPortNumberLocal=<port number of the internally accessible server with load balancer> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
CASがクラスタ化されていない場合:
WEM=true IsPrimaryClusterMember=true CASHostName=<host name of server on which CAS will be deployed> CASPortNumber-<port number of server on which CAS with be deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
WebCenter Sitesのセカンダリ・クラスタ・メンバー上のWEMフレームワークをアップグレードしている場合は、次のサンプル構成をリファレンスとして使用します。
CASがクラスタ化されている場合:
WEM=true IsPrimaryClusterMember=false CASHostName=<host name of server with load balancer> CASPortNumber=<port number of server with load balancer> CASHostNameLocal=<host name of the internally accessible server with load balancer> CASPortNumberLocal=<port number of the internally accessible server with load balancer> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
CASがクラスタ化されていない場合:
WEM=true IsPrimaryClusterMember=false CASHostName=<host name of server on which CAS has been deployed> CASPortNumber=<port number of server on which CAS has been deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
WebCenter Sites 11gR1 (11.1.1.8.0)のインストーラ・ファイルの圧縮を解除します。インストーラ・スクリプトの実行時に、アップグレード・プロセスが自動的に検出され、呼び出されます。
展開したフォルダのルートにあるinstall.iniファイルを次のように編集します。
nodisplayプロパティをtrueに設定します。
loadfileプロパティを<手順1で名前変更したomii.iniのパスと名前>に設定します。
|
注意: ファイル・システムのパスが正しく指定されていることを確認してください。たとえば、Windowsの場合、このオプションは次のようになります。
-または-
|
サイレント・インストーラを実行します。
Windows: csInstall.bat -silent
UNIXまたはLinux: csInstall.sh -silent
プラットフォームに対応したインストレーション・ガイドを参照して、記載されているWebCenter Sitesのインストール手順を実行します。インストールが完了したら、このガイドに戻って作業を続行します。
|
注意: この時点で、アップグレード・プロセスが完了し、WebCenter Sitesの有効なインストールが実行されていると仮定します。 アップグレードが失敗する場合は、前述の手順およびログを確認して、問題を解決してください。前述の手順を回復し、処理を再度開始する必要があるため、インストーラを終了しないでください。 |
WebCenter SitesおよびCASアプリケーションを再起動します。
この項では、アップグレード・ユーティリティを再実行し、データベース・スキーマが正しくデプロイされていることを確認します。
プロパティ・エディタを使用して、次の作業を行います。
futuretense.iniファイル(<cs_install_dir>内)を開き、secure.CatalogManager、secure.CatalogManager、ft.syncの各プロパティを元の値にリセットします。
Content Serverのインストールでカスタマイズしたプロパティ値がアップグレード・プロセスでデフォルト値に置き換えられた場合、ここでカスタム値を復元します。
元のインストールのバージョンに応じて、アップグレード時に次のプロパティが追加されます。
WebCenter Sites 11gR1 (11.1.1.6.0)からアップグレードした場合、futuretense_xcel.iniファイルにtimezoneattrという名前の新しいプロパティが追加されます。このプロパティの値を変更する場合は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。
Content Server 7.6パッチ2からアップグレードした場合、新しいプロパティが追加されます。それらは表3-6に記載されています。これらのプロパティの値を変更する場合は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。
表3-6 Fatwire Content Serverからのアップグレードで追加される新しいプロパティ
| プロパティ | プロパティ・ファイル |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FatWire Content Server 7.6パッチ2からアップグレードした場合:
FatWire Content Server Advanced管理インタフェースのいずれかの部分をカスタマイズしていた場合は、カスタム・コードを再適用します。
アップグレード後に、フレッシュ・インストールでは表示されない追加のフィールドが属性フォームに表示されます。フレッシュ・インストールと同じ属性フォームにするには、gator.iniファイルを編集し、mwb.externalattributesプロパティをfalseに設定します(gator.iniファイルは<cs_install_folder>にあります)。
(オプション) log4jにアップグレードする場合、commons_logging.propertiesファイルに設定されていた任意のカスタム・ロガーをlog4j.propertiesファイルに追加します。log4j.propertiesファイルを次のように更新します。
commons_logging.propertiesファイルに設定されていた任意のカスタム・ロガーを追加します。
log4j.propertiesファイルに次のプロパティを追加します。
log4j.logger.com.fatwire.logging.cs.file=INFO log4j.logger.com.fatwire.logging.cs.framework=INFO log4j.logger.com.fatwire.logging.cs.realtime=INFO log4j.logger.com.fatwire.logging.cs.sseed=INFO log4j.logger.com.fatwire.services=INFO log4j.logger.com.fatwire.services.dao=INFO log4j.logger.com.fatwire.services.time=INFO
アプリケーション・サーバーを再起動します。
WebCenter Sitesに一般管理者としてログインできることを確認します。
アップグレード後に検索エンジンが自動的に再起動されます。ただし、検索エンジンを使用するには、検索索引を再作成する必要があります。Luceneを使用して強制的に索引を再作成する方法は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。
いずれかのサイトで多言語アセットやロケール・フィルタリングの使用を計画している場合は、デフォルトのロケールを作成し、そのサイトのすべてのアセットにそれを適用します。詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。
それぞれのベーシック・アセット・タイプのアセット要素を再登録します。
ベーシック・アセットが有効になっているコンテンツ管理サイトにログインします。
左側のナビゲーション・ツリーで、「管理」タブを選択します。
「アセット・タイプ」ノードを展開します。
ベーシック・アセット・タイプをダブルクリックします。
右側のペインで、「アセット・エレメントの登録」をクリックします。
確認画面で、「アセット・エレメントの登録」をクリックします。
それぞれのベーシック・アセット・タイプに関して、ElementCatalog表内の各要素にカスタマイズ内容を再適用します。
次のアセット・タイプのリビジョン・トラッキングを無効にしていた場合は、それを有効にします。
ASSOCNAMED表
CSElement
Template
Page
|
注意: Content Server 7.6パッチ2からアップグレードする場合:
|
AdminSiteにWEM Adminアプリケーションを割り当てます。
配信システムに配置済ページを表示するためには、サイト・プランが公開されている必要があります。配信システムへのサイト・プラン・アセットの公開を可能にするには、リアルタイム宛先を初期化します。この初期化を行うことによって、配信時にSitePlanアセット・タイプが作成されます。
これまでの手順の実行中に記録したメモを集めます。アクティブな環境のアップグレード時にはこれらのメモを使用できます。
|
注意: デプロイしているそれぞれのリモートのSatellite Serverに対して、次の手順を繰り返してください。 |
カスタマイズ内容はすべて失われるため、リモートのSatellite Serverをバックアップし、加えたカスタマイズを把握できるようにします。
SatelliteServerのホーム・ディレクトリをアンデプロイし、削除します。
リモートのSatellite Serverをインストールします(『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください)。
Satellite ServerのJVMのタイム・ゾーンを、WebCenter SitesのJVMのタイム・ゾーンと一致するように設定します。
|
注意: WebCenter Sites 11gR1 (11.1.1.6.0)以降ではキャッシュ方式が変更されているため、JVMヒープの調整を行う必要があります。 |
アップグレードの手順に加えて、この項では、管理者、開発者またはコンテンツ作成者が実行する必要のある手順について説明します。これらの手順が正常に完了したら、システムの通常運用の準備が整います。
この項の内容は、次のとおりです。
第3.7.5項「開発者がOracle WebCenter Sites: Developer Toolsを使用していた場合」
第3.7.7項「カスタマイズされたWebCenter Sites 11gR1 (11.1.1.6.1)システムからアップグレードした場合」
JVMのタイム・ゾーンを変更した場合、スケジュール済イベントおよびコードがJVMのタイム・ゾーンと同期するようにします。次の手順を実行します。
現在のJVMのタイム・ゾーンに合致するようにスケジュール済イベントの時間パターンを更新します。
たとえば、以前はサーバーが太平洋標準時で動作しており、公開の実行が午後3:00にスケジュールされていた場合、UTC (GMT)にアップグレードした後、引き続き太平洋標準時の午後3:00に公開が実行されるためには、公開スケジュールを午後11:00 (GMT)に更新する必要があります。
現在のJVMのタイム・ゾーンに沿った時間パターンを使用して、公開スケジュールを更新します。手順については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の公開イベントのスケジュールに関する項を参照してください。
現在のJVMのタイム・ゾーンに沿った時間パターンを使用して、ワークフロー・イベントのスケジュールを更新します。手順については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の時間指定アクション・イベントのセットアップに関する項を参照してください。
カスタマイズ済のコードおよびテンプレート・コードの意図した動作が維持されているかどうかに関して、開発者に依頼して確認してもらいます。テンプレート・コードでデフォルトの日付フォーマッタを使用して日付をレンダリングしている場合、動作を維持するために日付フォーマッタにタイム・ゾーンのパラメータを追加しなければならない場合があります。次の表は、Webサイトで日付がどのようにレンダリングされるかを示しています。
| 日付フォーマッタ | アップグレード前のJVMのタイム・ゾーンはPST(米国太平洋標準時刻) | アップグレード後、JVMのタイム・ゾーンはGMT |
|---|---|---|
|
デフォルトの日付フォーマッタ |
3:00 PM PST |
11:00 PM GMT |
|
タイム・ゾーンがPSTに設定された日付フォーマッタ |
3:00 PM PST |
3:00 PM |
WebCenter SitesのXMLおよびJSPのタグ、Java API、およびJSP JSTLのすべての日付フォーマッタのタグで、タイム・ゾーン・パラメータがサポートされています。タイム・ゾーンに対応したテンプレートの更新の詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』のコンテキスト内およびプレゼンテーションの編集のためのテンプレートのコーディングに関する項を参照してください。
アップグレード前にいずれかのアセット・タイプのアセット・タイプ検索が構成されていた場合、アップグレード後の検索結果には日付が正しく表示されなくなります。ユーザーは、日付が正しく表示されるように、アセット・タイプの索引を再作成する必要があります。また、アップグレード・プロセスの後にグローバル検索の索引も再作成する必要があります。
元のインストールでSmartListsが作成されていた場合、第2.2項「アップグレード前の手順」を完了するとそれらは削除されます。コンテンツ作成者は、保存済検索としてそれらのSmartListsを再作成する必要があります。
Content Server 7.6パッチ2からアップグレードした場合、第1.4.5項「ページ・アセット・タイプおよびスロット・アセット・タイプ」で説明されているように、Pageアセット・タイプがアップグレードされます。WebCenter Sitesの管理者は、PageAttribute、PageDefinitionおよびPageFilterのスタート・メニューを作成して、これらのアセット・タイプを使用できるようにする必要があります。
WebCenter Sitesをアップグレードする前に開発者がDeveloper Toolsを使用していた場合、この項の手順を実行してください。
この項の内容は、次のとおりです。
アップグレード・プロセスで行われる変更によって、以前ワークスペースにエクスポートしたリソースを、再度ワークスペースにエクスポートする必要があります。次の手順を実行します。
以前にエクスポートしたすべてのリソース(サイト、アセット・タイプ、アセットなど)をバックアップします。
既存のワークスペースからすべてのリソースを削除します。
以前にエクスポートしたすべてのリソースをワークスペースに再度エクスポートします。
リソースがバージョン・コントロール・システムに格納されている場合は、以前にエクスポートしたすべてのリソースを再エクスポートしたリソースに置き換えます。
WebCenter Sitesをアップグレードする前に開発者がDeveloper Toolsを使用していた場合、Developer Toolsプラグインが最新のバージョンに更新されていることを確認する必要があります。Developer Toolsプラグインの更新方法については、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』のDeveloper Toolsの更新に関する項を参照するように開発者に伝えてください。
開発者が既存のサイトでモビリティ・デバイス・グループを有効にしている場合、そのサイトのアセットにモビリティのプレビュー機能が追加されます。開発者は、プレビュー・テンプレートのpagecriteriaパラメータにdパラメータを追加する必要があります。このようにしないと、アセットのプレビューでテンプレートが使用されるときに、ログ・ファイルにエラー・メッセージが記録される可能性があります。
WebCenter Sites 11gR1 (11.1.1.6.1)からのアップグレードで、開発者が以前にContributorインタフェースをプログラム的にカスタマイズしていた場合、この項に示すようにカスタマイズ内容を復元する必要があります。
|
注意: customElements以外の場所にカスタム要素が格納されていた場合、それらはアップグレード・プロセス時に上書きされます。開発者は、それらのカスタム要素を、この項で特定される新しい要素として再作成する必要があります。 |
開発者が検索要素UI/Data/Search/ListAction、UI/Data/Search/ListJson、UI/Data/Search/ThumbnailActionおよび/またはUI/Data/Search/ThumbnailJsonをカスタマイズしており、それらの要素がcustomElementsの下に格納されていた場合、次に示すように変更内容を新しい要素に移植する必要があります。
UI/Data/Search/ListActionからUI/Data/Search/SearchActionへ
UI/Data/Search/ListJsonからUI/Data/Search/SearchJsonへ
UI/Data/Search/ThumbnailActionからUI/Data/Search/BrowseActionへ
UI/Data/Search/ThumbnailJsonからUI/Data/Search/BrowseJsonへ
開発者が次の検索要素をカスタマイズしていた場合:
UI/Layout/CenterPane/Search/View/ListViewHtml
UI/Layout/CenterPane/Search/View/DockedListViewHtml
UI/Layout/CenterPane/Search/View/ThumbnailViewHtml
UI/Layout/CenterPane/Search/View/DockedThumbnailViewHtml
指し示すカスタム要素を次のように変更する必要があります。変更前:
storeElement = "UI/Data/Search/List"または
storeElement = "UI/Data/Search/Thumbnail"
変更後:
storeElement = BooleanUtils.toBoolean(browse) ? "UI/Data/Search/Browse" : "UI/Data/Search/Search";
開発者がUI/Layout/CenterPane/Search/View/ContextMenuConfigまたはUI/Layout/CenterPane/DashBoard/ContextMenuConfigを通じて検索またはダッシュボードのコンテキスト・メニューをカスタマイズまたは構成している場合、それらのカスタマイズ内容を削除し、クライアント側の同じ要素をカスタマイズする必要があります。クライアント側の構成方法は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。
Community、Gadgetsおよび/またはSite Captureアプリケーションを実行しているインストールをアップグレードする場合、それらのアプリケーションもアップグレードします。手順については、第II部「Oracle WebCenter Sites: Community-Gadgetsへのアップグレード」および第III部「Oracle WebCenter Sites: サイト・キャプチャのアップグレード」を参照してください。
WebCenter SitesとOracle Access Managerを統合する方法は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。Community-GadgetsおよびSite Captureもアップグレードした場合は、同じガイドでCommunity-GadgetsおよびSite Captureが、OAMと統合されたWebCenter Sitesと通信できるようにする方法を参照してください。
アップグレードした環境のそれぞれのWebCenter Sitesのインスタンスに対して、次の手順を実行します。
|
注意: クラスタを利用している場合は、プライマリ・クラスタ・メンバーから作業を開始し、次にそれぞれのセカンダリ・クラスタ・メンバーをテストします。最後に、ロード・バランサを通じてクラスタをテストします。 |
WebCenter Sitesに一般管理者としてログインします。
WebCenter Sitesのインタフェース(AdminとContributor)、および通常の運用で繰り返し使用するすべての機能をテストします。たとえば、検索、カスタム・アセット・タイプの作成と編集、アセットの作成と編集、サイトのプレビュー、ワークフロー、承認と公開についてテストします。インタフェースの詳細は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください。
環境の検証時に、次のいずれかを実行します。
テスト環境をアップグレードした場合は、第3.9項「アクティブな環境のアップグレード」に進みます。
アクティブな環境をアップグレードした場合は、次の手順を実行します。
公開スケジュールを有効にします。
いずれかのイベントを有効にします。
アップグレードした環境をバックアップします。
新しいキャッシュ構造で必要なチューニングを適用します。
クライアントのブラウザのキャッシュをクリアします(キャッシュされているコンテンツがあると問題が発生する可能性があります)。
作業を再開します。
最初にテスト環境をアップグレードした場合、次の手順を適用します。
テスト環境の検証が完了したら、アクティブな環境をアップグレードします。
試行アップグレード中もアクティブな環境は動作していたと仮定すると、そのContent ServerまたはWebCenter Sitesシステムを同期します(必要に応じて)。
開発システムからコンテンツ管理システムに公開します。
コンテンツ管理システムから配信システムに公開します。
この章の前述の手順、および試行アップグレード時に作成したメモを使用して、アクティブな環境をアップグレードします。
アップグレードした環境をバックアップします。
作業を再開します。