2 現行バージョンのWebCenter Sitesにアップグレードする前に

Oracle WebCenter Sites 11gR1 (11.1.1.8.0)にアップグレードする前に、この章を参照して、アップグレード戦略と前提条件の手順について理解してください。

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

• 第2.1項「アップグレード・プロセスの計画」

• 第2.2項「アップグレード前の手順」

• 第2.3項「アップグレード前の決定」

• 第2.4項「アップグレード後の手順の計画」

2.1 アップグレード・プロセスの計画

本番環境では、アップグレードにより、アクティブなシステムの操作が中断し、停止時間が延長する場合があります。このような中断を最小限に抑えるには、この章で概要を示すアップグレード戦略を採用すること、つまりテスト環境を更新して開始することを強くお薦めします。

注意: 「アクティブ」という用語は、現在コンテンツを処理している開発システム、管理システムまたは配信システムがあり、その予想外の停止時間によって組織の業務や生産性が影響を受けるシステムを示す場合に使用されます。

図2-1に示すように、エンタープライズレベルの環境は、通常、3つ以上の異なるWebCenter Sites強化システム(開発、管理および配信)で構成されます。各システムは、その独自のデータベースで実行し、通常はパブリッシュまたはOracle WebCenter Sites: 開発者ツールを介して他のシステムと相互運用します。

アクティブな環境をアップグレードする前に、複製環境で試行アップグレードを実行することが重要です。試行アップグレードは、システムに固有の問題を検出して記録し、実際のアップグレードの前にその問題を修正する場合に役立ちます。

注意: FatWire Content Server 7.6パッチ2のAdvancedユーザー・インタフェースやDashインタフェースに行われるカスタマイズはWebCenter Sites 11gR1 (11.1.1.8.0)で機能しないため、試行アップグレードは重要です。したがって、アクティブなシステムのアップグレードを試す前に、そのようなカスタマイズを新しいContributorインタフェース用に設計されたカスタマイズで置き換える場合には、適切な評価が必要です。

複製環境を使用できない場合、管理システムや配信システムに対する中断を最小限に抑えるには、開発システムをアップグレードして開始します。この方法はリスクが高いため、長時間の停止が許容可能と考えられる場合を除いては、試さないでください。

図2-1 WebCenter Sites環境

「図2-1 WebCenter Sites環境」の説明

2.2 アップグレード前の手順

このガイドは、経験豊富なWebCenter Sitesインストール・エンジニアを対象としています。WebCenter Sites 11gR1 (11.1.1.8.0)にアップグレードする前に、次の手順を実行します。

• WebCenter Sitesのリリース・ノートおよびOracle WebCenter Sites動作保証マトリックス(http://www.oracle.com/technetwork/middleware/webcenter/sites/downloads/index.html)を参照します。

• このガイドの以降の部分を参照して、アップグレード手順、アップグレード・インストーラで行われる変更、アップグレード後の手順を十分に把握してください。

• 次のいずれかのインストールで開始します。

  FatWire Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x)

  • 環境内のすべてのContent ServerシステムまたはWebCenter Sites 11gR1 (11.1.1.6.x)システムでWebCenter Sites 11gR1 (11.1.1.8.0)インストーラを実行します。システム・タイプには、開発、コンテンツ管理、配信の3つがあります。開発システムとコンテンツ管理システムは、通常同じタイプですが、異なる目的で使用されます。

    WebCenter Sites 11gR1 (11.1.1.8.0)インストーラは、システム・タイプ(開発、コンテンツ管理または配信)と、Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x)インストール・プロセス時に選択されたデプロイメント・モード(自動または手動)の両方を検出して再利用します。たとえば、Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x)を配信システムとしてインストールして自動的にデプロイした場合、WebCenter Sites 11gR1 (11.1.1.8.0)インストーラは、引き続きシステムを配信システムとして処理して自動的にデプロイします。

    
    

    注意: システム・タイプとデプロイメント・モードは、アップグレード時に変更できません。 WebCenter Sitesのプライマリ・クラスタ・メンバーは、アップグレード時にセカンダリ・クラスタ・メンバーとして再構成できません。逆も同様です。

    
    

  • WebCenter Sites 11gR1 (11.1.1.6.x)からアップグレードし、WebCenter Sitesシステムとともにサイト・キャプチャ、コミュニティまたはガジェットの各アプリケーションを実行する場合、これらのアプリケーションをアップグレードする必要があります。手順はこのガイドで説明します。

• 現在のプラットフォームがWebCenter Sites 11gR1 (11.1.1.8.0)でサポートされていない場合、WebCenter Sites 11gR1 (11.1.1.8.0)でサポートされるプラットフォームに再インストールして、アップグレードを続ける前にすべてのコンテンツとカスタマイズをこの環境にパブリッシュします。

• アプリケーション・サーバーをアップグレードする場合、新しいアプリケーション・サーバーを指し示すように次のプロパティを設定します。

  futuretense.iniのcs.jsproot

  ominstallinfo/omii.iniのcsjsproot

  これは、アップグレード・インストーラを起動する前に行う必要があります。行わない場合、インストール・プロセスの中間をすぎるとインストーラが機能しなくなります。

• 現在のContent ServerまたはWebCenter Sitesアプリケーションが最初のデプロイ以降に変更された場合(ほとんどの場合、変更される)、次の操作を実行します。

  • cs.warファイル、ContentServer.earファイルの順に作成して、現在のContent ServerまたはWebCenter Sitesアプリケーションをバックアップします。また、インストール・ディレクトリ、共有ディレクトリおよびデータベースもバックアップします。詳しい手順については、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』の章「バックアップおよびリカバリ」を参照してください。

    アップグレード後のプロセスでは、バックアップしたインストール・ディレクトリ、共有ディレクトリおよびデータベースを使用して、それらに含まれるカスタマイズを再適用します。

  • 現在のContent ServerまたはWebCenter Sites 11gR1 (11.1.1.6.x)アプリケーションの最初のデプロイ後にカスタマイズがそのアプリケーションに対して行われ、<cs_install_dir>/ominstallinfo/appにあるcs.warファイルとContentServer.earファイルにそのカスタマイズが反映されない場合、ファイルを削除し、現在デプロイされているWebCenter Sitesアプリケーションの.warファイルと.earファイルを同じディレクトリにコピーします。

    アップグレード時に、既存のcs.warファイルはcs-date-time.warとしてアーカイブされます。アップグレード後のプロセスで、アーカイブしたファイルを使用して、カスタマイズを必要に応じて再適用します。

  • カスタム索引を表に追加した場合、アップグレード・プロセスの完了後、これらの索引をバックアップして再適用します。

• Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x)からアップグレードする場合、次の事項を念頭に置いてください。

  • 管理インタフェースのカスタマイズは、アップグレード後は機能しません。そのため、データベース、インストール・フォルダ、共有フォルダおよびWebアプリケーションに格納されているすべてのカスタマイズをバックアップします。アップグレードの完了後、このバックアップからカスタマイズを再適用します。

  • Contributorインタフェースで作成されたSmartList (現在は保存済検索と呼ばれる)は、アップグレード後は機能しません。SmartListは、アップグレード前に削除する必要があります(アップグレード後、再作成する必要があります。

• すべての外部データのフィードとイベント(検索イベントを含む)が無効であることを確認します。(アップグレードの完了後、外部データのフィードとイベントを必ず有効にしてください。)

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

  • ASSOCNAMED表

  • CSElement

  • テンプレート

  • ページ

• JDK 1.6の場合、インストーラのSun/libディレクトリのjaxb-impl-2.1.12.jarファイルを、承認された<PATH_TO_JDK_FOLDER>/jre/lib/にコピーします。

  
  

  注意: JDK 1.6またはJDK 1.7に付属するjaxb-implを使用しないでください。WebCenter Sites 11gR1は、前述の指定場所で提供される、最新バージョンのjaxb-implに依存します。(JDK 1.6に付属の)WebLogic Serverとの実行時競合を解決するには、最新のJARファイルを使用する必要があります。

  
  

• すべてのアプリケーション・サーバーで次の操作を実行します。

  • 起動スクリプトを更新します。

    • max PermGenパラメータを128MBから196MBの範囲で設定します。例: -XX:MaxPermSize=196m

    • -Dcs.useJavaURLDecoderをfalseに設定します。この手順により、Apache URLCodecを使用してURL文字がデコードされます。

  • CLASSPATH環境変数を更新します。WebCenter Sites変更バージョンのMicrosoft XML Parser (WEB-INF/libディレクトリのMSXML.jar)にパスを追加します。クラスパスが別のバージョンのMicrosoft XML Parserを参照する場合、WebCenter SitesはXMLの解析時に機能しなくなります。

    
    

    注意: クラスパスとライブラリ・パスを適切に設定しない場合、CASは、システムへのアクセスが不可になるため、開始できません。OAMを使用する場合、アップグレードはCASに戻ります。

    
    

• ContentServerユーザー(システム定義ユーザー)のパスワードに特殊文字が含まれるか、パスワードが数字のみで構成される場合、そのパスワードを、特殊文字を含まない英数字のパスワードで置き換えます。アップグレード・インストーラは、パスワード・フィールドの特殊文字を受け入れず、数字のみのパスワードも受け入れません。すべてのアップグレードが完了すると、元のパスワードを使用できます。

  • Tomcatアプリケーション・サーバーでのオプション: データソースに関連するエラーを受信した場合、WebCenter Sitesの最初の起動時にデータソースが正しく初期化されるように、次のJARファイルを<app_server_home>/libディレクトリに配置します。

    • commons-dbcp-1.3.jar

      このファイルはhttp://commons.apache.org/dbcp/からダウンロードできます。

    • commons-pool-1.5.5.jar

      このファイルはhttp://commons.apache.org/pool/からダウンロードできます。

• 現在のシステムが、WEMフレームワークを実行するWebCenter Sites 11gR1 (11.1.1.6.x)またはContent Server 7.6パッチ2の場合、次の操作を実行します。

  1. アップグレードの開始前に、以前のCASインストールをアンデプロイして削除します。

  2. サイレント・インストールを予定する場合、表2-1に示すように、CASHostNameフィールドとCASPortNumberフィールドの値を設定して、すべてのContent Serverクラスタ・メンバーのomii.iniファイルを変更します。

  表2-1 CAS関連フィールド

  フィールド	CAS	値
  CASHostName	クラスタ	ロード・バランサが実行されているサーバーのホスト名。
  CASHostName	非クラスタ	CASがデプロイされるサーバーのホスト名。
  CASPortNumber	クラスタ	ロード・バランサが実行されているサーバーのポート名。
  CASPortNumber	非クラスタ	CASがデプロイされるサーバーのポート名。
  CASHostNameLocal	クラスタ	内部でアクセス可能なCASロード・バランサが実行されているサーバーのホスト名。
  CASHostNameLocal	非クラスタ	CASがデプロイされるサーバーの内部ホスト名。
  CASPortNumberLocal	クラスタ	内部でアクセス可能なCASロード・バランサが実行されているサーバーのポート名。
  CASPortNumberLocal	非クラスタ	CASがデプロイされるサーバーの内部ポート名。
  CASHostNameActual	クラスタ/非クラスタ	CASがデプロイされるサーバーのホスト名/IPアドレス。

  
  

• アップグレードの前にFatWire Content Serverの開発者ツールまたはWebCenter Sitesの開発者ツールを使用する場合、開発者ツールのプラグインが、WebCenter Sitesインストーラで提供される最新バージョンに更新されていることを確認します。

• Oracle WebCenter Sites: Sites Explorerが、複数の変更が含まれる最新バージョンに更新されていることを確認します。

2.3 アップグレード前の決定

• GUIインストーラとサイレント・インストーラのどちらを実行するか

  GUIインストーラは、アップグレード・プロセスの案内に役立つ拡張オンライン・ヘルプにアクセスできます。サイレント・インストーラを使用すると、omii.iniファイルで提供される構成情報に基づき、自動アップグレードを実行できます。これらのアップグレード手順の詳細は、第3.5.1項「グラフィカルなアップグレード」および第3.5.2項「サイレント・アップグレード」を参照してください。

• シングル・サインオンに行われる変更(SSO)

  SSOはWEMフレームワークの一部です。SSOの場合、アップグレード・プロセス時にCentral Authentication Service (CAS)デプロイメント情報を指定する必要があります。

  
  

  注意: OAMを使用する場合、WebCenter Sitesは、アップグレード時にCASの使用にリセットされます。アップグレードの完了後、OAMをリストアできます。

  
  

  アップグレード時に必要なCASデプロイメント情報は、Content Server 7.6パッチ2またはWebCenter Sites 11gR1 (11.1.1.6.x)インストールから継承されるデプロイメント・モード(自動または手動)によって異なります。

  継承されたデプロイメント・モードによるCASデプロイメント・プロセスの決定

  • プライマリContent Serverクラスタ・メンバーでインストーラを実行する場合、WEMフレームワークをインストールまたはアップグレードするためのデプロイメント・シナリオは次のようになります。

    • 自動デプロイメントが有効な場合、インストーラはWebCenter SitesとCASを同じサーバーにデプロイします。自動デプロイメント・プロセスが完了したら、CASを別のサーバーに移動する場合は、アップグレード後のプロセスの一環としてCASを手動で再デプロイする必要があります。

    • デプロイメント・モードが手動であることをインストーラが検出した場合、WebCenter Sitesを手動でデプロイします。さらに、CASを手動でデプロイします。

  • セカンダリCASクラスタ・メンバーでインストーラを実行する場合、セカンダリCASクラスタ・メンバーにCASデプロイメント情報を指定します。『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』の章「WebCenter SitesおよびCAS Webアプリケーションのデプロイ」の説明に従い、これらのメンバーを手動で構成してデプロイします。

• ロギング・システムの決定方法

  • Content Server 7.6パッチ2からアップグレードする場合、既存のロギング・システムからApache log4jに移行しますか?(推奨)

    Apache log4jに移行する場合、アップグレード・プロセスでlog4j移行オプションを選択する必要があります。アップグレード・プロセスでlog4jに移行しない場合は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の説明に従い、後からlog4jに切り替えることができます。

  • WebCenter Sites 11gR1 (11.1.1.6.x)からアップグレードする場合、アップグレード・プロセスでロギング・システムを選択するオプションを使用しますか?

    現在のインストールでApache log4jを使用する場合、Apache log4jは、アップグレード・プロセス時に自動で選択されてインストールされます。

    現在のインストールでlog4jを使用しない場合、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の説明に従い、アップグレード・プロセスでlog4jに移行するか、引き続き現在のロギング・システムを使用して後から切り替えることができます。

2.4 アップグレード後の手順の計画

WebCenter Sites 11gR1 (11.1.1.8.0)をアップグレードしたら、カスタマイズを再適用し、Satellite Serverを再インストールしてリモートSatellite Serverをアップグレードします。アップグレードしたインストールの検証後、開発者やコンテンツ・コントリビュータにも関連する一連の手順を完了します。この手順は、開発者やコンテンツ・コントリビュータが元のインストールをどのように使用したかによって異なります。詳細は、第3章「WebCenter Sitesの最新バージョンへのアップグレード」の第3.7項「アップグレード後の手順」を参照してください。