この項では、Oracle WebLogic Portalを10.3.4にアップグレードするための計画および手順の概要を示します。次のWebLogic PortalアプリケーションからPortal 10.3.4に直接アップグレードできます。
Oracle WebLogic Portal 10.3.2
Oracle WebLogic Portal 10.3
Oracle WebLogic Portal 10.2
Oracle WebLogic Portal 10.0および10.0メンテナンス・パック1(MP1)
Oracle WebLogic Portal 9.2および9.2 MP1
Oracle WebLogic Portal 8.1 SP4、SP5およびSP6
WebLogic Portal 8.1を9.2にアップグレードし、9.2から10.0/10.2/10.3/10.3.2にアップグレードして、その後10.0/10.2/10.3/10.3.2を10.3.4にアップグレードする必要はありません。
注意: Autonomy Enterprise Searchを使用するWLPアプリケーションをアップグレードしており、Autonomy Enterprise Searchを今後も使用する必要がある場合は、まずAutonomy社(http://www.autonomy.com )から必要なライセンスを購入し、バイナリを入手する必要があります。WLPとAutonomyの併用の詳細は、Oracle Fusion Middleware Oracle WebLogic Portal Autonomy Search統合サンプル・ガイドを参照してください。
Autonomyのかわりに、OracleのSecure Enterprise Search(別途購入するか、WebCenter Suiteに同梱されている)などの別の検索エンジンを使用することもできます。 |
この章には、次の各項目が含まれます。
WebLogic Portalのアップグレードに関連する一部の作業は、WebLogicアップグレード・ウィザードを実行して行います。WebLogicアップグレード・ウィザードの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverアップグレード・ガイド』を参照してください。
このドキュメントで説明する様々なアクティビティを明確にするために、用語について簡単に説明します。
移行: サード・パーティ・テクノロジからOracle製品にアプリケーションおよびドメインを移動すること(たとえば、IBMからOracleへのお客様の移行)。
アップグレード: Oracleプラットフォーム(およびコンポーネント)を古いリリースまたはサービス・パックから新しいリリースまたはメンテナンス・パックに更新すること。これには、たとえば9.2 MP1から10.3.4への更新など、新しいバージョンで動作するように既存のアプリケーションおよびドメインを更新することが含まれます。
アプリケーション環境のアップグレードに必要なプロセスはアプリケーションのスコープによって決まります。アプリケーション環境には、WebLogicドメインおよびドメインに関連付けられているすべてのアプリケーションやアプリケーション・リソースが含まれます。また、ファイアウォール、ロード・バランサ、データベース、LDAPサーバーなどの外部リソースが含まれる場合もあります。
相互運用性: (1)1つのリリースまたはサービス・パックでデプロイされたアプリケーションが、別のリリースまたはサービス・パックでデプロイされたアプリケーションと通信する能力。(2)WebLogic Platformコンポーネントが標準プロトコルを使用してサード・パーティ・ソフトウェアと通信する能力。
互換性: 1つのリリースまたはサービス・パックを使用して構築されたアプリケーションが別のリリースまたはサービス・パックで動作すること。これには、アプリケーションの再構築が必要となる場合もあります。
WebLogic Portal 9.2、9.2 MP1、10.0、10.0 MP1、10.2、10.3および10.3.2アプリケーションを10.3.4にアップグレードできます。アップグレード・プロセスでは、WebLogic Portalドメインとアプリケーションをアップグレードします。WebLogicアップグレード・ウィザードを使用してポータル・ドメインをアップグレードしてから、ポータル・アプリケーションをアップグレードします。アップグレード手順の詳細は、第2章「WebLogic Portal 10.3.4へのアップグレード」を参照してください。
WebLogic Portal APIはWebLogic Portalの現在のバージョンでも維持されており(10.0から非推奨となり、現在のバージョンから削除されたCommerce APIを除く)、データベースおよびファイル・ベース・アセットのほとんどのコア・フォーマットは変更されていません。変更が行われた箇所については、新しいフォーマットにアップグレードするため、または必要な変更を手動で加えるためのツールが用意されています。
9.2および10.0/10.2/10.3/10.3.2のアップグレードは、.project
ファイルで実行されます。Portal 10.3.4へのアップグレード後は、元のポータル・バージョンに戻ることはできません。WebLogic Portal 9.2または10.0/10.2/10.3/10.3.2から10.3.4にアップグレードする場合、Derbyデータベースのバージョンはすでにアップグレード済です。
Portal 9.2または10.0/10.2/10.3/10.3.2アプリケーションから10.3.4へのアップグレードは、次のいずれかの方法を選択して実行できます。
既存の9.2または10.0/10.2/10.3/10.3.2ポータル・アプリケーションをWorkshop for WebLogicでワークスペースとして開く
既存の展開された9.2または10.0/10.2/10.3/10.3.2プロジェクトをWorkshop for WebLogicにインポートする
アーカイブされた9.2または10.0/10.2/10.3/10.3.2プロジェクト・ファイルをWorkshop for WebLogicにインポートする
ヒント: 既存のEARアプリケーションをアップグレードすることはできません。アップグレードできるのはプロジェクトのみです。 |
アップグレード手順については、第2.6.2項「Portal 9.2および10.0/10.2/10.3/10.3.2から10.3.4へのアップグレード」を参照してください。
WebLogic Portalでは、8.1 SP4、SP5およびSP6アプリケーションを10.3.4に直接アップグレードできます。ほとんどのWebLogic Portal APIはWebLogic Portalの現在のバージョンでも維持されており(10.0から非推奨となり、現在のバージョンから削除されたCommerce APIを除く)、データベースおよびファイル・ベース・アセットのほとんどのコア・フォーマットは変更されていません。変更が行われた箇所については、新しいフォーマットにアップグレードするため、または必要な変更を手動で加えるためのツールが用意されています。
アップグレード・プロセスでは、WebLogic Portal 8.1ポータル・アプリケーションおよびリソースをWebLogic Portal 10.3.4にアップグレードします。8.1から10.3.4へのアップグレードは、.work
ファイルで実行されます。起動スクリプトでドメインの設定方法をカスタマイズしている場合、その変更はWebLogic Portal 10.3.4起動スクリプトを実行すると上書きされます。
注意: WebLogic Portal 8.1から10.3.4にアップグレードすると、Derbyデータベースもアップグレードされます。 |
アップグレード手順については、第2.6.3項「Portal 8.1から10.3.4へのアップグレード」を参照してください。
ドメイン・アップグレーダ・ツールでは、必要に応じてライブラリ・モジュールを追加または削除できます。新しい製品インストールを指すように、既存のライブラリ・モジュール・パス情報も変更されます。
削除されたライブラリは、config.xml
ファイルから取り除かれます。8.1.xから10.3.4にアップグレードすると、ライブラリがconfig.xml
ファイルに追加されます。9.2または10.0/10.2/10.3/10.3.2から10.3.4にアップグレードすると、config.xml
ファイル内のモジュール・バージョン番号が10.3.4に変更されます。10.0 MP1から10.3.4にアップグレードすると、ドメイン・アップグレーダによりmaintenance-lib参照が削除されます。
この項では、WebLogic Portalの以前のバージョンとPortal 10.3.4リリースとの間での重要な機能変更の概要を示します。
WebLogic Portal 8.1には、WebLogic Portal固有のRDBMSAuthenticatorが含まれていました。これは非推奨となりました。WebLogic Server 9.2には新しいデフォルトのSQLAuthenticator認証プロバイダが含まれており、これにはユーザーとグループ用のRDBMSユーザー・ストアが含まれます。新しいWebLogic Server SQLAuthenticatorにアップグレードすることをお薦めします。
Steveからの注意
WebLogicアップグレード・ウィザードを実行してドメインをアップグレードする際、8.1インストールでRDBMSAuthenticatorを使用しているかどうかが判別されます。RDBMSAuthenticatorが検出されると、WebLogicアップグレード・ウィザードによって、デフォルトの認証プロバイダとしてWebLogic SQLAuthenticatorにアップグレードするのか、または既存のRDBMSユーザー・ストアを使用し続けるのかを選択するように求められます。既存の認証プロバイダを新しいWebLogic Server SQLAuthenticatorで置き換えると、パーソナライズ機能も含め、すべてのコンテンツがアップグレードされます。パーソナライズ機能をPortal 10.3.4 RDBMSユーザー・ストアに後から手動でアップグレードすることもできます。
ユーザー・ストアのアップグレード時には次のいずれかのオプションを選択します。
ユーザーとグループをアップグレードする: ユーザーとグループを、WebLogic Portal 8.1から、新しいデフォルトのWebLogic SQLAuthenticator認証プロバイダの一部である新しいRDBMSユーザー・ストアに自動的にアップグレードする場合に選択します。WebLogicアップグレード・ウィザードを実行し、Portal 8.1 RDBMSAuthenticatorが検出された場合、RDBMSAuthenticatorをアップグレードするオプションを選択できます。このオプションを選択すると、既存の認証プロバイダが新しいSQLAuthenticator認証プロバイダで置き換えられ、ユーザーとグループも含めてユーザー・ストアがアップグレードされます。config.xml
ファイルも更新されます。
ユーザーとグループをアップグレードしない: WebLogic Portal 8.1インストールのデフォルトのRDBMSAuthenticatorのRDBMSユーザー・ストアを使用し続ける場合に選択します。WebLogicアップグレード・ウィザードを実行し、Portal 8.1 RDBMSAuthenticatorが検出された場合、RDBMSAuthenticatorをアップグレードしないオプションを選択できます。ユーザーとグループをPortal 9.2 RDBMSユーザー・ストアに後から手動でアップグレードすることもできます。
ドメインのアップグレード・プロセス中にユーザー・ストアをアップグレードしない場合は、後で手動アップグレードを実行できます。WebLogic Portal固有のRDBMS AuthenticatorからWebLogic SQL Authenticatorにアップグレードするためのスクリプトは、<
WLPORTAL_HOME>/p13n/db/
<dbms>/upgrade_fromdbmsauth_ towlssqlauth.sql
です。
詳細は、第B.2項「8.1、9.2または10.0 Derbyデータベースのアップグレード」を参照してください。
注意: WebLogic Portal 8.1アプリケーションを10.3.4にアップグレードし、アップグレードされたドメインでUserProviderControl.createUser()クラスを使用すると、新しいユーザーがWebLogic Portalへのログインを試みた場合に、javax.security.auth.login.LoginExceptionエラーが表示されることがあります。これは、デフォルトで、WebLogic Portal 10.3.4ドメインの新規ユーザーが、移行された認証プロバイダ(通常はJAASフラグをREQUIREDに設定することにより構成される)ではなく、SQLAuthenticatorで作成されるために発生します。WebLogic Portalのドメイン・アップグレード・ウィザードでは、JAAS設定が調整されず、既存の認証プロバイダも削除されないため、この例外を回避するには、必要に応じてJAAS設定を調整するか、認証プロバイダを削除する必要があります。 |
ドメインを10.3.4にアップグレードする場合、RDBMSセキュリティ・ストアはデフォルトで有効にはなりません。セキュリティ・ストアを有効にして構成するには、Oracle WebLogic Server管理コンソールを使用する必要があります。RDBMSセキュリティ・ストアの詳細は、WebLogic Serverドキュメント『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のRDBMSセキュリティ・ストアの管理に関する項を参照してください。
WLPドメインを10.3.4にアップグレードする際、RDBMSセキュリティ・ストアも使用したい場合は、アップグレードの実行後にWebLogic Serverコンソールを使用してRDBMSセキュリティ・ストアを構成する必要があります。ドメインの再起動後に、ポリシーがRDBMSセキュリティ・ストアに自動移行されます。一方、RDBMSセキュリティ・ストアに対して構成された新しい(アップグレードされていない)ドメインにポリシーを移行する場合は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のRDBMSセキュリティ・ストアを使用するためのドメインのアップグレードに関する項で、古いセキュリティ・ストアから新しいセキュリティ・ストアへのデータの移行に関する情報を参照してください。
注意: アップグレード・プロセスの一環として、DDLによって、p13nDatasourceが構成されているスキーマ内にRDBMSセキュリティ・ストア表が自動的に作成されます。管理者はp13nDatasourceと同じデータベース接続設定を使用することをお薦めします。p13nDatasourceが構成されているスキーマ以外のデータベース・スキーマを使用または構成する必要がある場合、ポータル・ドメイン管理者は次のスクリプトを手動で実行して、そのスキーマに対するRDBMSセキュリティ・ストア表を作成する必要があります。
|
イベントにより、コンテンツを適切なオーディエンスに対して表示できます。
注意: イベントは、10.3.4にアップグレードされたコンテンツ・リポジトリに対して発生します(イベント追跡をリポジトリ・レベルで無効にしている場合を除く)。イベントは、リポジトリ構成の変更と、リポジトリでのコンテンツの追加、更新および削除に対しても発生する場合があります。アップグレードされなかった8.1または9.2リポジトリのコンテンツに対してはイベントは発生しません。イベントは、そのリポジトリで追加、更新または削除されたコンテンツに対して発生します。 |
バージョン8.1または9.2で個別の動作追跡データベースを作成した場合は、それを第B.4項「個別の8.1動作追跡データベースのアップグレード」の説明に従ってアップグレードしてください。