ヘッダーをスキップ
Oracle® Fusion Middleware WebCenter Sitesアップグレード・ガイド
11g リリース1 (11.1.1.8.0)
E49674-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

3 WebCenter Sitesの最新バージョンへのアップグレード

この章では、テスト環境の作成とアップグレード、テスト環境の検証、およびアクティブな環境のアップグレードについて説明します。

この章の内容は、次のとおりです。

3.1 アップグレード・プロセスに関する注意

アップグレード処理を開始する前に、次のことを確認します。

3.2 アクティブな環境のバックアップ

この項では、万一に備えてアクティブな環境をバックアップします。テスト環境の作成を選択した場合は、このバックアップをリカバリすることによってテスト環境を作成します。

アクティブな環境をバックアップするには

  1. アクティブな環境内のすべてのシステムをバックアップします。これには、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) バックアップおよびリカバリ・ガイド

  2. 必要に応じて、システムのコンテンツを別のシステムに公開することによって、アクティブな環境のすべてのシステムを同期します(たとえば、開発システムから管理システムや配信システムなどへの同期)。

  3. すべての公開スケジュールを無効にして、公開セッションが実行されないようにします。アクティブな環境のアップグレードと検証が完了したら、公開スケジュールを再び有効にします。

  4. カスタマイズした要素をメモしておきます。

    1. それぞれのベーシック・アセット・タイプに関して、要素内のすべてのカスタム・コードのメモを記録しておきます(ElementCatalog表内)。

    2. Content Server 7.6パッチ2からのアップグレードを行っており、Content Server Advanced管理インタフェースのいずれかの部分をカスタマイズしている場合は、カスタム・コードをメモしておきます。これは、既存のカスタマイズは変更されるまで動作しないためです。

    3. WebCenter Sites 11gR1 (11.1.1.6.1)のContributorインタフェースをプログラム的にカスタマイズしている場合、それらのカスタマイズ内容は、CustomElementパスに置かれている場合にかぎりアップグレード時に保持されます。それ以外の場合、それらのカスタマイズ内容はアップグレード・プロセス時に上書きされます。開発者はバックアップしておいたインストールからカスタマイズ内容を再作成する必要があります。

  5. すべてのイベント(検索イベントを含む)が無効であることを確認します。これは、Sites ExplorerまたはCatalogManagerから実行できます。詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

  6. 次のアセット・タイプのリビジョン・トラッキングを無効にします。

    • ASSOCNAMED

    • CSElement

    • Template

    • Page


    注意:

    Content Server 7.6パッチ2からアップグレードする場合:

    • すべてのアセット・タイプのリビジョン・トラッキングを無効にします。

    • Pageアセット・タイプがアップグレードされ、部分的にフレックス・アセット・タイプのように動作するようになります。これにより、アップグレード後のPageアセット・タイプはPageAttributePageDefinitionおよびPageFilterも持つことになります。


  7. Webサーバーの構成、アプリケーション・サーバーの構成、データベースの構成、LDAPの構成など、既存のインストールに関するすべての情報を記録しておきます。これらはアップグレード時に変更されることはありませんが、なんらかの変更が必要な場合に既存の設定を参照する必要性が生じる場合があります(たとえば新しいキャッシュをチューニングする場合など)。

3.3 テスト環境の作成


注意:

Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x )からのアップグレードを行う場合、アクティブな環境をアップグレードする前に、テスト環境で試行アップグレードを実行してください。テスト環境が利用できない場合は、最初に開発システムのアップグレードから始めてください。この場合、より長いダウンタイムを想定してください。WebCenter Sitesに加えられる変更の度合いから判断すると、テスト環境を使用することを強くお薦めします。


  1. テスト環境の作成準備が整ったら、前述の手順で作成したバックアップをリカバリします。リカバリのガイドラインは、第3.2項「アクティブな環境のバックアップ」の手順1で参照したガイドのバックアップおよびリカバリに関する章を参照してください。

    • FatWire Content Server 7.6パッチ2バックアップおよびリカバリ・ガイド

    • Oracle WebCenter Sites 11gR1 (11.1.1.6.1) バックアップおよびリカバリ・ガイド

  2. アクティブな環境でリモートのSatellite Serverを実行している場合は、それらの中の少なくとも1つをテスト環境に複製します。

  3. 次のガイドラインを使用して、テスト環境の作成を継続します。

    Content ServerまたはWebCenter Sitesでの作業:

    1. Content ServerまたはWebCenter Sitesを、以前のホスト上にそれらが置かれていたのと同じ場所にコピーします。

    2. ローカル・システム、およびこのアップグレードをテストする単一のリモートのSatellite Serverを除き、SystemSatellite表のエントリを消去します。

    3. ContentServer.earファイルおよびcs.warファイル内にある次のファイル(表3-1)の中のホスト名とIPアドレスを変更します。

      表3-1 ContentServer.earおよびCS.war内のファイル

      ホスト名とIPアドレスの変更 ファイル ディレクトリ

      必須

      satellite.properties (ホスト)

      <deploy_dir>/WEB-INF/classes

      オプション

      SampleSites.html

      <deploy_dir>/Xcelerate

      オプション

      AssetSet.wsdl

      AssetType.wsdl

      Asset.wsdl

      Miscellaneous.wsdl

      SitePlan.wsdl

      <deploy_dir>/Xcelerate/wsdl


    4. <cs_install_dir>ディレクトリ内にある次のプロパティ・ファイル(表3-2)の中のホスト名とIPアドレスを変更します。

      表3-2 <cs_install_dir>内にあるプロパティ・ファイル

      ホスト名とIPアドレスの変更 プロパティ・ファイル プロパティ

      必須

      futuretense.ini

      databaseloader.ini

      futuretense_xcel.ini

      cs.eventhost

      db1.loginurl

      xcelerate.batchhost


    5. WEMフレームワークをインストールしていた場合、次のファイルも編集します(表3-3)。

      表3-3 以前にWEMフレームワークをインストールしていた場合の編集対象ファイル

      ホスト名とIPアドレスの変更 ファイル 注意

      必須

      <cshome>/Bin/jbossTicketCacheReplicationConfig.xml

      <cshome>/bin/cas.properties

      <cshome>/Bin/host.properties

      CS/WEB-INF/classes/SSOConfig.xml

      CAS/WEB-INF/deployerConfigContext.xml

      必要に応じて値の検索と置換を行います。


    アプリケーション・サーバーでの作業:

    1. 以前のホストで使用したのと同じパスを使用してアプリケーション・サーバーをインストールします。

    2. 新しいデータソースを作成し、その新しいデータソースの情報を使用して、futuretense.iniファイル内の該当するデータベース・プロパティを更新します。リストアしたデータベースのデータベース情報を使用します。(データベース・プロパティは、プロパティ・エディタの「データベース」タブにリストされます。)

    3. アプリケーション・サーバーの必要に応じて、Content ServerまたはWebCenter Sitesアプリケーションをデプロイします。

3.4 環境をアップグレードするための準備

この項では、Oracle WebCenter Sites動作保証マトリックスと最新のリリース・ノートを使用して、最初に既存の環境をサポートするソフトウェアをアップグレードします。アップグレード対象となるのは、Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x )です。

3.4.1 手順1: サポート・コンポーネントのアップグレード


注意:

クラスタ環境向け。すべてのクラスタ・メンバーを停止します。アップグレードの準備はプライマリ・メンバーのみに対して行います。プライマリ・メンバーのアップグレードが完了したら、セカンダリ・メンバーのWebCenter Sitesもアップグレードします。


  1. 既存の環境のサポート・コンポーネントを、Oracle WebCenter Sites動作保証マトリックスに記載されているバージョンにアップグレードします。サポート・コンポーネントには次のものがあります。

    • オペレーティング・システム

    • アプリケーション・サーバー

    • Java SDK

    • Content ServerまたはWebCenter Sitesのデータベース

    • (条件付き)。LDAPサーバーおよびWebサーバー。LDAPを使用しており、LDAPサーバーのアップグレード(または変更)を決定した場合、古いサーバーから新しいサーバーにLDAPデータを手動で移行します。作業を続行する前に、LDAPデータが正しく移行されたことを確認します。


      注意:

      サポート・コンポーネントの説明は、それぞれのベンダーのドキュメントを参照してください。


  2. インストールが完全に機能することを確認します。

3.4.2 手順2: 既存のインスタンスの準備

  1. 既存のインスタンスでOracleデータベースを実行している場合、Oracleデータベース・ユーザーに次のシステム権限が割り当てられていることを確認します。これらの権限は、WebCenter Sitesが動作するのに必要な権限と同じです。

    • GRANT UNLIMITED TABLESPACE TO <USER>;

    • GRANT CREATE SESSION TO <USER>;

    • GRANT CREATE TABLE TO <USER>;

    • GRANT CREATE VIEW TO <USER>;

  2. アップグレードを通じてカスタマイズ内容が維持されるようにします。


    注意:

    アップグレード時にデプロイメント・ディレクトリ内のjs/srcフォルダが削除されるため、この手順ではデプロイメントのカスタマイズ(存在する場合)をバックアップします。


    カスタムのJARをデプロイしている場合、またはcs.warファイルおよびContentServer.earファイル(場所は<cs_install_dir>/ominstallinfo/app)の現在のコピーに反映されていない構成変更を行っている場合は、次の手順を実行して、現在デプロイされているContent Serverアプリケーションからクリーンなcs.warファイルおよびContentServer.earファイルを作成します。

    1. ominstall/appからcs.warおよびContentServer.earをバックアップします。

    2. WEMフレームワークがインストールされている場合、ominstall/ディレクトリからcas.warおよびcas.earをバックアップします。

    3. デプロイされ、展開されているcs.warファイルを見つけ、そのファイルを圧縮します(WebCenter Sitesのインストーラによって使用されるとの同じバージョンのJARを使用します)。次に、そのファイルをominstall/appディレクトリに置きます。

    4. バックアップしたContentServer.earファイルを専用のディレクトリに展開します。

    5. 展開されたContentServer.earファイル内の既存のファイルに新しいcs.warを上書きコピーし、このファイルを圧縮します(WebCenter Sitesのインストーラによって使用されるのと同じバージョンのJARを使用します)。

    6. 新しく圧縮されたContentServer.earominstall/appディレクトリに配置します。


      注意:

      WebCenter Sitesのインストーラは、<cs_install_dir>/ominstallinfo/appディレクトリにあるContent ServerまたはWebCenter Sitesアプリケーションを検出するように構成されています。cs.warファイルとContentServer.earファイルは、名前を変更したり、移動したりしないでください。インストーラがContent ServerまたはWebCenter Sitesアプリケーションを検出できないと、アップグレード・プロセスは失敗します。


  3. <cs_install_dir>ディレクトリ内のすべての.iniファイルをバックアップします。

  4. プロパティ・エディタを使用して、futuretense.iniファイル内の次のプロパティの値のメモを記録しておきます。

    • secure.CatalogManager (「基本」タブ)

    • ft.sync (「クラスタ」タブ)

    これらの値は、アップグレード・プロセスの中でインストーラによって変更されます。それらを元に戻す必要があります。

  5. Content Server 7.6パッチ2からのアップグレードを行っており、システムが読取り専用のLDAPと統合されている場合、次の手順に従ってロールの追加と削除を行います。

    1. 対象の各ユーザーに対して次のロール(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統合機能へのアクセスを許可します。

    2. DashUserロールを削除します。このロールは、ユーザーがContent Server Dashインタフェースにログインすることを許可します。このインタフェースは削除されたため、このロールもLDAPから削除する必要があります。


      注意:

      次の項目に関して、DashUserロールはSitesUserロールに置き換えられました。

      • スタート・メニュー

      • ツリー・タブ

      • ワークフロー手順、プロセス、割当ておよび機能権限。

      • 保存済の検索

      • 公開先

      • アクセス権


  6. inCacheを現在使用している場合は、java tempディレクトリ内のキャッシュ・ファイルを手動で削除する必要があります。削除されるディレクトリの名前として、cascachecscachelinkedcacheおよびsscacheがあります。

  7. この手順では、すべてのデータベースの表のタイム・ゾーンがJVMのタイム・ゾーンに一致していることを確認します。アップグレード・プロセスでこのように一致している必要があるためです。


    注意:

    特に、分散したデータのタイムスタンプを標準化するため、JVMのタイム・ゾーンをUTC (GMT)に設定することをお薦めします。たとえば、コンテンツがロサンゼルスからニューヨークに対して公開され、いずれのサーバーもローカル時間で動作している場合、コンテンツの公開時間には3時間の差が生じます。いずれのサーバーもUTC (GMT)に設定することにより、あいまいさが解消されます。また、ログ・ファイルのデータはUTC (GMT)時間でレポートされることに注意してください。次の手順では、UTC (GMT)の設定を使用しています。クラスタのすべてのサーバーは同じタイム・ゾーンを使用することが重要です。手順全体を完了します。

    リモートのSatellite Serverをアップグレードする場合、そのJVMではWebCenter SitesのJVMのタイム・ゾーンを使用するように設定します。


    1. WebCenter SitesのJVMのタイム・ゾーンを変更する必要がある場合は、次のようにします(今すぐ実行するか、またはアップグレード・プロセスの中でアプリケーション・サーバーを開始する前の任意の時点で実行します)。

      -Duser.timezone=<TIMEZONE_ID>

      ここで、<TIMEZONE_ID>はUTCにすることをお薦めします。

    2. リビジョン・トラッキングの表のタイム・ゾーンが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


        注意:

        javaコマンドのこれらの変数はスクリプト内に定義されています。

        リビジョン・トラッキングの表のデフォルトのタイム・ゾーンが変更されている場合は、-o <TIMEZONE_ID>の値はUTCになります。


      • クラスパスおよび必要なデータベース・ドライバがスクリプト内で適切に設定されていることを確認します。

      • -pパラメータを指定してスクリプトを実行し、tzutil.logファイルを参照して、データベースに加えられることが想定される変更を確認します。

      • -pパラメータを指定せずにスクリプトを実行して、新しいタイム・ゾーンを使用するようにデータベース表を更新します。

    3. すべてのデータベース表(リビジョン・トラッキングの表以外)のタイム・ゾーンがJVMのタイム・ゾーンと一致していることを確認します。一致していない場合は、スクリプトを次のように編集します。

      • javaコマンドから-rパラメータを削除し、次の変数を設定して、新しいタイム・ゾーンを設定します。

        ... -d <DB VENDOR> -o <TIMEZONE_ID> -n <TIMEZONE_ID> -p
        
      • -pパラメータを指定してスクリプトを実行し、tzutil.logファイルを参照して、データベースに加えられることが想定される変更を確認します。

      • -pパラメータを指定せずにスクリプトを実行して、新しいタイム・ゾーンを使用するようにデータベース表を更新します。

  8. この手順では、WebCenter Sitesアップグレード・ユーティリティを実行して、データベース・スキーマのアップグレード前のステータスをログに記録します。インストーラによってデータベース・スキーマ(および索引)に加えられた変更を確認するため、アップグレード後にこのユーティリティを再度実行します。アップグレード・ユーティリティの詳細は、misc\upgrade-util.zip内にあるReadMeファイルを参照してください。

    アップグレード・ユーティリティを実行する手順は次のとおりです。

    1. 展開したインストーラのmiscディレクトリに移動し、アップグレード・ユーティリティを展開し、次のいずれかのスクリプトを開きます。

      Windows:              cssystem.bat

      UNIXまたはLinux: ./cssystem.sh

    2. 選択したスクリプトを編集し、システムに関する次の情報を入力します。

      • WebCenter Sitesのデータベース設定(ドライバ、URL、ユーザー名およびパスワード)を指定します。

      • データベースのタイプに対応するDATABASEJARファイルを指定します。

      • 出力ファイルのパスを指定します。

      • -iパラメータを使用して、WebCenter Sitesの想定されるデプロイメント・パスを指定します。

    3. 選択したスクリプトを実行します。

      スクリプトを実行すると、Systeminfo.logファイルが生成されます(\misc\ディレクトリ内)。このファイルには、想定されるWebCenter Sitesデータベース・スキーマの更新が含まれます。


      注意:

      アップグレード・ユーティリティの使用方法の詳細は、\misc\upgrade-util.zipディレクトリ内のReadMe.txtファイルを参照してください。


  9. アプリケーション・サーバーから、WebCenter SitesおよびContent Serverの古いアプリケーションをアンデプロイします。アンデプロイの方法は、プラットフォームおよびWebCenter Sitesのバージョンに対応したインストレーション・ガイドを参照してください。WEMがインストールされたContent Server 7.6パッチ2からのアップグレード、またはWebCenter Sites 11gR1 (11.1.1.6.x )からのアップグレードを行っている場合、アプリケーション・サーバーからCASをアンデプロイし、削除します。

3.5 WebCenter Sites 11gR1 (11.1.1.8.0)へのインスタンスのアップグレード

この項では、Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x )のそれぞれのインスタンスに対して、WebCenter Sitesアップグレード・インストーラを選択したモード(GUIモードまたはサイレント・モード)で実行します。


注意:

次の点を考慮してください。

  • 第3.4項「環境をアップグレードするための準備」で大きな変更を行った場合は、環境をバックアップします。バックアップを行っていないと、アップグレードが失敗した場合、第3.2項「アクティブな環境のバックアップ」からアップグレード手順をやり直す必要があります。

  • Content Server 7.6パッチ2の場合:

    log4jを有効にしていた場合、アップグレードでは引き続きlog4jが使用されます。commons-logging.propertiesを使用していた場合は、アップグレード・プロセス中にlog4jを変更する機会があります。

    – 古いページ・キャッシング・フレームワークが有効になっていた場合、そのキャッシュはフラッシュされ、inCacheフレームワークに置き換えられます。


Content ServerのインスタンスをWebCenter Sitesにアップグレードするには、次のいずれかを実行します。

3.5.1 グラフィカルなアップグレード

  1. WebCenter Sitesインストーラのアーカイブを一時ディレクトリに展開し、インストーラ・スクリプトを実行します。

    • Windows:        csinstall.bat

    • UNIXまたはLinux:   ./csInstall.sh


      注意:

      アップグレード・プロセス中、およびアップグレード後のテストでは、インストーラのログ(install_log.log)、WebCenter Sitesアプリケーションのログ、およびアプリケーション・サーバーのログを監視します。エラーが発生した場合は、ログを参照してその原因を探ることができます。

      アップグレード・パスがWebCenter Sites 11gR1 (11.1.1.6.x )から始まる場合、デフォルトのログの場所は<cs_install_dir>/logs/sites.logです。


    アップグレードの実行時には、次の点に注意してください。

    • インストーラのほとんどのフィールドには、インストーラが元のインストールから検出した値があらかじめ設定されています。あらかじめ設定されている値を確認してください。それらの値が古い場合は、新しい値を設定する必要があります。(パスワードなどの情報は手動で入力する必要があります。)

    • 変更できない値が設定されているフィールドは、入力できないようになっています(灰色になっています)。

    • インストーラの各画面にはオンライン・ヘルプが用意されており、画面で選択可能なオプションの詳しい説明が記載されています。アップグレード・プロセス中に問題が発生した場合は、オンライン・ヘルプを参照して、考えられる原因とその解決方法を確認してください。

  2. プラットフォームに対応したインストレーション・ガイドを参照して、記載されているWebCenter Sitesのインストール手順を実行します。インストールが完了したら、このガイドに戻って作業を続行します。


    注意:

    この時点で、アップグレード・プロセスが完了し、WebCenter Sitesの有効なインストールが実行されていると仮定します。アップグレードが失敗した場合は、前述の手順およびログを確認して、問題を解決してください。前述の手順を回復し、処理を再度開始する必要があるため、インストーラを終了しないでください。


  3. WebCenter SitesおよびCASアプリケーションを再起動します。

  4. 第3.5.3項「アップグレード・ユーティリティの再実行」に進みます。

3.5.2 サイレント・アップグレード

この項では、次の手順を実行します。

3.5.2.1 omii.iniファイルの構成

  1. <cs_install_dir>/ominstallinfoから<cs_install_dir>の外部のフォルダにomii.iniファイルをコピーし、このコピーの名前を必要に応じて変更します。サイレント・インストーラはアップグレード時にこのコピーを使用します。

  2. FatWire Content Server 7.5の後に、ContentServerのユーザーまたはSatelliteServerのユーザーのデフォルトのユーザー名またはパスワード(またはその両方)を変更した場合は、名前変更したomii.iniファイルを開き、表3-4に記載されているプロパティを更新します。サイレント・インストーラは、これらのプロパティに指定された資格証明を参照して認証を行います。これらの資格証明が古い場合、インストーラは失敗します。

    表3-4 名前変更されたomii.iniファイル内のプロパティ

    プロパティ 説明

    CSInstallAccountName

    ContentServerユーザーの現在のユーザー名を指定します。

    デフォルト値はContentServerです。

    CSInstallAccountPassword

    ContentServerユーザーの暗号化されたパスワードを指定します。

    暗号化されたパスワードを取得するには、Content Server(またはWebCenter Sites)のプロパティ・エディタを使用します。

    1. プロパティ・エディタでfuturetense.iniファイルを開きます。

    2. cs.mirrorpasswordプロパティを検索します。このプロパティに値が設定されている場合、その値を一時的にテキスト・ファイルに保存します。

    3. cs.mirrorpasswordプロパティの値を暗号化するパスワードに置き換えます。

    4. プロパティ・ファイルを保存します。これによりパスワードが暗号化されます。

    5. 暗号化されたパスワードをomii.iniファイルにコピーします。

    6. cs.mirrorpasswordに値が設定されていた場合は、その値を元に戻します。

    SSUserPassword

    SatelliteServerユーザーの暗号化されたパスワードを指定します。暗号化されたパスワードを取得するには、前述のCSInstallAccountPasswordの手順を使用します。


  3. この手順では、ロギング・システムを決定します。次のいずれかを実行します。

    • 既存のロギング・システムからApache log4j (推奨)に移行する場合は、名前変更されたomii.iniファイルにConvertToLog4Jプロパティを追加し、このプロパティをtrueに設定します。

    • すでに手動でlog4jを構成している場合、または既存のロギング・システムを保持する場合は、omii.iniファイルにConvertToLog4Jプロパティを追加しないでください

    • WebCenter SitesへのWCC統合のインストールを有効にするには、omii.iniファイルにWCCIntegration=trueプロパティを追加します。

  4. この手順は、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フレームワークのインストールまたはアップグレードを行う場合は、このプロパティをtrueに設定します。

    注意: この表に続いて、この表のプロパティを設定する方法を示した例が記載されています。それらの例は次のとおりです。

    - 第3.5.2.1.1項「WEMフレームワークをインストールするためのサンプル構成」

    - 第3.5.2.1.2項「WEMフレームワークをアップグレードするためのサンプル構成」

    IsPrimaryClusterMember

    Content Serverのプライマリ・クラスタ・メンバーにWEMフレームワークをインストールするか、またはアップグレードする場合は、このプロパティをtrueに設定します。

    セカンダリ・クラスタ・メンバーにWEMフレームワークをインストールするか、またはアップグレードする場合は、このプロパティをfalseに設定します。

    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とCASを同じサーバーにデプロイします。インストール・プロセスが完了した後、別のサーバーにCASを手動で再デプロイできます。これについては、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』のWebCenter SitesおよびCAS Webアプリケーションのデプロイに関する項で説明されています。

    • 手動デプロイを有効にしている場合は、WebCenter Sitesをデプロイします。また、同じサーバーまたは別のサーバーにCASをデプロイします。インストール・プロセスが完了した後、別のサーバーにCASを再デプロイすることを決定した場合、それを手動で実行できます。これについては、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』のWebCenter SitesおよびCAS Webアプリケーションのデプロイに関する項で説明されています。


3.5.2.1.1 WEMフレームワークをインストールするためのサンプル構成
  1. 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>
      
  2. 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>
      
3.5.2.1.2 WEMフレームワークをアップグレードするためのサンプル構成
  1. 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>
      
  2. 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>
      

3.5.2.2 サイレント・インストーラの実行

  1. WebCenter Sites 11gR1 (11.1.1.8.0)のインストーラ・ファイルの圧縮を解除します。インストーラ・スクリプトの実行時に、アップグレード・プロセスが自動的に検出され、呼び出されます。

  2. 展開したフォルダのルートにあるinstall.iniファイルを次のように編集します。

    1. nodisplayプロパティをtrueに設定します。

    2. loadfileプロパティを<手順1で名前変更したomii.iniのパスと名前>に設定します。


      注意:

      ファイル・システムのパスが正しく指定されていることを確認してください。たとえば、Windowsの場合、このオプションは次のようになります。

      CSInstallDirectory=C\:/csinstall

      -または-

      c\:\\install


  3. サイレント・インストーラを実行します。

    • Windows:       csInstall.bat -silent

    • UNIXまたはLinux:  csInstall.sh -silent

  4. プラットフォームに対応したインストレーション・ガイドを参照して、記載されているWebCenter Sitesのインストール手順を実行します。インストールが完了したら、このガイドに戻って作業を続行します。


    注意:

    この時点で、アップグレード・プロセスが完了し、WebCenter Sitesの有効なインストールが実行されていると仮定します。

    アップグレードが失敗する場合は、前述の手順およびログを確認して、問題を解決してください。前述の手順を回復し、処理を再度開始する必要があるため、インストーラを終了しないでください。


  5. WebCenter SitesおよびCASアプリケーションを再起動します。

  6. 第3.5.3項「アップグレード・ユーティリティの再実行」に進みます。

3.5.3 アップグレード・ユーティリティの再実行

この項では、アップグレード・ユーティリティを再実行し、データベース・スキーマが正しくデプロイされていることを確認します。

  1. 次のいずれかのスクリプトを実行します(これはアップグレード用のインスタンスを準備したときに手順8で構成、実行したものです)。

    • Windows:       cssystem.bat

    • UNIXまたはLinux:   cssystem.sh

  2. アップグレード・ユーティリティを再実行することによって、更新されたsysteminfo.logファイルが生成されます。このファイルと手順8で生成されたsysteminfo.logファイルを比較し、データベース・スキーマの変更が想定通りに行われていることを確認します。

3.5.4 アップグレードの完了

  1. プロパティ・エディタを使用して、次の作業を行います。

    • futuretense.iniファイル(<cs_install_dir>内)を開き、secure.CatalogManagersecure.CatalogManagerft.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からのアップグレードで追加される新しいプロパティ

      プロパティ プロパティ・ファイル

      advancedUI.enableAssetForms

      futuretense_xcel.ini

      cc.BlobServerTimeout

      futuretense.ini

      cc.BlobServerCacheCSz

      futuretense.ini

      cs.HTTP_HOST

      futuretense.ini

      com.fatwire.logging.cs.realtime

      commons-logging.properties

      xcelerate.timezoneattr

      futuretense_xcel.ini

      xcelerate.imageeditor.clarkii.basepath

      futuretense_xcel.ini


  2. FatWire Content Server 7.6パッチ2からアップグレードした場合:

    1. FatWire Content Server Advanced管理インタフェースのいずれかの部分をカスタマイズしていた場合は、カスタム・コードを再適用します。

    2. アップグレード後に、フレッシュ・インストールでは表示されない追加のフィールドが属性フォームに表示されます。フレッシュ・インストールと同じ属性フォームにするには、gator.iniファイルを編集し、mwb.externalattributesプロパティをfalseに設定します(gator.iniファイルは<cs_install_folder>にあります)。

  3. (オプション) log4jにアップグレードする場合、commons_logging.propertiesファイルに設定されていた任意のカスタム・ロガーをlog4j.propertiesファイルに追加します。log4j.propertiesファイルを次のように更新します。

    1. commons_logging.propertiesファイルに設定されていた任意のカスタム・ロガーを追加します。

    2. 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
      
  4. アプリケーション・サーバーを再起動します。

  5. WebCenter Sitesに一般管理者としてログインできることを確認します。

  6. アップグレード後に検索エンジンが自動的に再起動されます。ただし、検索エンジンを使用するには、検索索引を再作成する必要があります。Luceneを使用して強制的に索引を再作成する方法は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

  7. いずれかのサイトで多言語アセットやロケール・フィルタリングの使用を計画している場合は、デフォルトのロケールを作成し、そのサイトのすべてのアセットにそれを適用します。詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。

  8. それぞれのベーシック・アセット・タイプのアセット要素を再登録します。

    1. ベーシック・アセットが有効になっているコンテンツ管理サイトにログインします。

    2. 左側のナビゲーション・ツリーで、「管理」タブを選択します。

    3. 「アセット・タイプ」ノードを展開します。

    4. ベーシック・アセット・タイプをダブルクリックします。

    5. 右側のペインで、「アセット・エレメントの登録」をクリックします。

    6. 確認画面で、「アセット・エレメントの登録」をクリックします。

    7. それぞれのベーシック・アセット・タイプに関して、ElementCatalog表内の各要素にカスタマイズ内容を再適用します。

  9. 次のアセット・タイプのリビジョン・トラッキングを無効にしていた場合は、それを有効にします。

    • ASSOCNAMED

    • CSElement

    • Template

    • Page


    注意:

    Content Server 7.6パッチ2からアップグレードする場合:

    • すべてのアセット・タイプのリビジョン・トラッキングを有効にします。

    • Pageアセット・タイプがアップグレードされ、部分的にフレックス・アセット・タイプのように動作するようになります。これにより、アップグレード後のPageアセット・タイプはPageAttributePageDefinitionおよびPageFilterも持つことになります。


  10. AdminSiteにWEM Adminアプリケーションを割り当てます。

  11. 配信システムに配置済ページを表示するためには、サイト・プランが公開されている必要があります。配信システムへのサイト・プラン・アセットの公開を可能にするには、リアルタイム宛先を初期化します。この初期化を行うことによって、配信時にSitePlanアセット・タイプが作成されます。

  12. これまでの手順の実行中に記録したメモを集めます。アクティブな環境のアップグレード時にはこれらのメモを使用できます。

3.6 リモートのSatellite Serverのアップグレード


注意:

デプロイしているそれぞれのリモートのSatellite Serverに対して、次の手順を繰り返してください。


  1. カスタマイズ内容はすべて失われるため、リモートのSatellite Serverをバックアップし、加えたカスタマイズを把握できるようにします。

  2. SatelliteServerのホーム・ディレクトリをアンデプロイし、削除します。

  3. リモートのSatellite Serverをインストールします(『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください)。

  4. Satellite ServerのJVMのタイム・ゾーンを、WebCenter SitesのJVMのタイム・ゾーンと一致するように設定します。


    注意:

    WebCenter Sites 11gR1 (11.1.1.6.0)以降ではキャッシュ方式が変更されているため、JVMヒープの調整を行う必要があります。


3.7 アップグレード後の手順

アップグレードの手順に加えて、この項では、管理者、開発者またはコンテンツ作成者が実行する必要のある手順について説明します。これらの手順が正常に完了したら、システムの通常運用の準備が整います。

この項の内容は、次のとおりです。

3.7.1 JVMのタイム・ゾーンを変更した場合

JVMのタイム・ゾーンを変更した場合、スケジュール済イベントおよびコードがJVMのタイム・ゾーンと同期するようにします。次の手順を実行します。

  1. 現在のJVMのタイム・ゾーンに合致するようにスケジュール済イベントの時間パターンを更新します。

    たとえば、以前はサーバーが太平洋標準時で動作しており、公開の実行が午後3:00にスケジュールされていた場合、UTC (GMT)にアップグレードした後、引き続き太平洋標準時の午後3:00に公開が実行されるためには、公開スケジュールを午後11:00 (GMT)に更新する必要があります。

    1. 現在のJVMのタイム・ゾーンに沿った時間パターンを使用して、公開スケジュールを更新します。手順については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の公開イベントのスケジュールに関する項を参照してください。

    2. 現在のJVMのタイム・ゾーンに沿った時間パターンを使用して、ワークフロー・イベントのスケジュールを更新します。手順については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の時間指定アクション・イベントのセットアップに関する項を参照してください。

  2. カスタマイズ済のコードおよびテンプレート・コードの意図した動作が維持されているかどうかに関して、開発者に依頼して確認してもらいます。テンプレート・コードでデフォルトの日付フォーマッタを使用して日付をレンダリングしている場合、動作を維持するために日付フォーマッタにタイム・ゾーンのパラメータを追加しなければならない場合があります。次の表は、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開発者ガイド』のコンテキスト内およびプレゼンテーションの編集のためのテンプレートのコーディングに関する項を参照してください。

3.7.2 アセット・タイプとグローバル検索が構成されていた場合

アップグレード前にいずれかのアセット・タイプのアセット・タイプ検索が構成されていた場合、アップグレード後の検索結果には日付が正しく表示されなくなります。ユーザーは、日付が正しく表示されるように、アセット・タイプの索引を再作成する必要があります。また、アップグレード・プロセスの後にグローバル検索の索引も再作成する必要があります。

3.7.3 SmartListsが作成されていた場合

元のインストールでSmartListsが作成されていた場合、第2.2項「アップグレード前の手順」を完了するとそれらは削除されます。コンテンツ作成者は、保存済検索としてそれらのSmartListsを再作成する必要があります。

3.7.4 FatWire Content Serverからアップグレードした場合

Content Server 7.6パッチ2からアップグレードした場合、第1.4.5項「ページ・アセット・タイプおよびスロット・アセット・タイプ」で説明されているように、Pageアセット・タイプがアップグレードされます。WebCenter Sitesの管理者は、PageAttributePageDefinitionおよびPageFilterのスタート・メニューを作成して、これらのアセット・タイプを使用できるようにする必要があります。

3.7.5 開発者がOracle WebCenter Sites: Developer Toolsを使用していた場合

WebCenter Sitesをアップグレードする前に開発者がDeveloper Toolsを使用していた場合、この項の手順を実行してください。

この項の内容は、次のとおりです。

3.7.5.1 リソースの再エクスポート

アップグレード・プロセスで行われる変更によって、以前ワークスペースにエクスポートしたリソースを、再度ワークスペースにエクスポートする必要があります。次の手順を実行します。

  1. 以前にエクスポートしたすべてのリソース(サイト、アセット・タイプ、アセットなど)をバックアップします。

  2. 既存のワークスペースからすべてのリソースを削除します。

  3. 以前にエクスポートしたすべてのリソースをワークスペースに再度エクスポートします。

  4. リソースがバージョン・コントロール・システムに格納されている場合は、以前にエクスポートしたすべてのリソースを再エクスポートしたリソースに置き換えます。

3.7.5.2 Developer Toolsプラグインの更新

WebCenter Sitesをアップグレードする前に開発者がDeveloper Toolsを使用していた場合、Developer Toolsプラグインが最新のバージョンに更新されていることを確認する必要があります。Developer Toolsプラグインの更新方法については、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』のDeveloper Toolsの更新に関する項を参照するように開発者に伝えてください。

3.7.6 前に存在していたサイトで開発者がモビリティ・デバイス・グループを有効にしていた場合

開発者が既存のサイトでモビリティ・デバイス・グループを有効にしている場合、そのサイトのアセットにモビリティのプレビュー機能が追加されます。開発者は、プレビュー・テンプレートのpagecriteriaパラメータにdパラメータを追加する必要があります。このようにしないと、アセットのプレビューでテンプレートが使用されるときに、ログ・ファイルにエラー・メッセージが記録される可能性があります。

3.7.7 カスタマイズされたWebCenter Sites 11gR1 (11.1.1.6.1)システムからアップグレードした場合

WebCenter Sites 11gR1 (11.1.1.6.1)からのアップグレードで、開発者が以前にContributorインタフェースをプログラム的にカスタマイズしていた場合、この項に示すようにカスタマイズ内容を復元する必要があります。


注意:

customElements以外の場所にカスタム要素が格納されていた場合、それらはアップグレード・プロセス時に上書きされます。開発者は、それらのカスタム要素を、この項で特定される新しい要素として再作成する必要があります。


  • 開発者が検索要素UI/Data/Search/ListActionUI/Data/Search/ListJsonUI/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開発者ガイド』を参照してください。

3.7.8 インストールでCommunity、GadgetsまたはSite Captureを実行していた場合

Community、Gadgetsおよび/またはSite Captureアプリケーションを実行しているインストールをアップグレードする場合、それらのアプリケーションもアップグレードします。手順については、第II部「Oracle WebCenter Sites: Community-Gadgetsへのアップグレード」および第III部「Oracle WebCenter Sites: サイト・キャプチャのアップグレード」を参照してください。

3.7.9 WebCenter SitesとOracle Access Managerを統合する必要がある場合

WebCenter SitesとOracle Access Managerを統合する方法は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。Community-GadgetsおよびSite Captureもアップグレードした場合は、同じガイドでCommunity-GadgetsおよびSite Captureが、OAMと統合されたWebCenter Sitesと通信できるようにする方法を参照してください。

3.8 アップグレードした環境の検証

アップグレードした環境のそれぞれのWebCenter Sitesのインスタンスに対して、次の手順を実行します。


注意:

クラスタを利用している場合は、プライマリ・クラスタ・メンバーから作業を開始し、次にそれぞれのセカンダリ・クラスタ・メンバーをテストします。最後に、ロード・バランサを通じてクラスタをテストします。


  1. WebCenter Sitesに一般管理者としてログインします。

  2. WebCenter Sitesのインタフェース(AdminとContributor)、および通常の運用で繰り返し使用するすべての機能をテストします。たとえば、検索、カスタム・アセット・タイプの作成と編集、アセットの作成と編集、サイトのプレビュー、ワークフロー、承認と公開についてテストします。インタフェースの詳細は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください。

  3. 環境の検証時に、次のいずれかを実行します。

    • テスト環境をアップグレードした場合は、第3.9項「アクティブな環境のアップグレード」に進みます。

    • アクティブな環境をアップグレードした場合は、次の手順を実行します。

      1. 公開スケジュールを有効にします。

      2. いずれかのイベントを有効にします。

      3. アップグレードした環境をバックアップします。

      4. 新しいキャッシュ構造で必要なチューニングを適用します。

      5. クライアントのブラウザのキャッシュをクリアします(キャッシュされているコンテンツがあると問題が発生する可能性があります)。

      6. 作業を再開します。

3.9 アクティブな環境のアップグレード

最初にテスト環境をアップグレードした場合、次の手順を適用します。

  1. テスト環境の検証が完了したら、アクティブな環境をアップグレードします。

    1. 試行アップグレード中もアクティブな環境は動作していたと仮定すると、そのContent ServerまたはWebCenter Sitesシステムを同期します(必要に応じて)。

      • 開発システムからコンテンツ管理システムに公開します。

      • コンテンツ管理システムから配信システムに公開します。

    2. この章の前述の手順、および試行アップグレード時に作成したメモを使用して、アクティブな環境をアップグレードします。

  2. アップグレードした環境をバックアップします。

  3. 作業を再開します。