| Oracle® Fusion Middleware Oracle WebLogic Portalアップグレード・ガイド 10gリリース3(10.3.4) B66149-01 |
|
 前 |
 次 |
この付録では、アップグレードされた環境に影響し、手動での作業を必要とする可能性があるWebLogic Portal 10.3.4での機能変更について説明します。
この章には、次の項があります。
次の各項では、WebLogic Portal 8.1から10.3.4に直接アップグレードした場合に発生する変更について説明します。手動での作業が必要になる場合があります。
このセクションの内容は次のとおりです。
RDBMS Authenticatorは8.1ではサポートされていましたが、Portal 9.2以降のすべてのリリースでは非推奨となっています。RDBMS AuthenticatorはSQL Authenticatorに置き換えられています。
アップグレード・ウィザードでRDBMS Authenticatorを使用するドメインをアップグレードできるようにするには、次の手順を手動で実行する必要があります。8.1 RDBMS AuthenticatorをPortal 10.3.4にアップグレードする前に、次の回避策を実行します。
setDomainEnv.cmd/sh変数weblogic.alternateTypesDirectoryを、非推奨のプロバイダへのパス(<WLPORTAL_HOME>/p13n/deprecated/lib/security)を含むように更新します。
アップグレード・ウィザードを実行してアップグレードを行います。アップグレード・ウィザードによって、ドメインのconfig.xmlファイルから非推奨のRDBMS Authenticatorへの参照も削除されます。
|
ヒント: ドメインのアップグレード・プロセス中にユーザー・ストアをアップグレードしなかった場合は、後で手動アップグレードを実行できます。upgrade_fromdbmsauth_tosqlauth.sqlスクリプトを実行して、WebLogic Portal固有のRDBMS AuthenticatorからWebLogic SQL Authenticatorにアップグレードします。このスクリプトは<WLPORTAL_HOME>\p13n\db\<DBMS>\ディレクトリにあります。 |
WebLogic Portal 10.0で追加されたフェデレーテッド・ポータルの伝播をサポートする新機能には、この項で説明するアップグレード手順の実行が必要になります。
この項のトピックは、次のとおりです。
WebLogic Portal 10.3.4では、より柔軟で実用的なフェデレーテッド・ポータルの伝播方法を可能にするWSRP 2.0の機能がサポートされています。WebLogic Portal 10.3.4では、ステージング環境と本番環境のコンシューマ・アプリケーションは個別のプロデューサを参照することができます。この新しい機能の最大の利点は、本番環境から独立したステージング環境内でリモート(プロキシ)ポートレットを作成および変更できることです。
WebLogic Portal 10.0以前は、WSRPコンシューマ・アプリケーションを伝播させるには、ソース・システムと宛先システムで同じプロデューサを参照する必要がありました。この構成(詳細は、WebLogic Portal 9.2プロダクション業務ガイドのWSRPの伝播に関する項を参照)にはいくつかの制限事項があります。
この項では、フェデレーテッド・ポータルのアップグレード手順について説明します。ここで説明する手順は、次のシナリオに適用されます。
ソース(ステージング)環境と宛先(本番)環境でコンシューマ・アプリケーションとプロデューサ・アプリケーションの両方をWebLogic Portal 10.0にアップグレードすることをお薦めします。それにより、新しい伝播機能を利用することが可能になり、伝播プロセスを単純化できます。
コンシューマ・アプリケーションをWebLogic Portal 10.0にアップグレードします。ソース環境と宛先環境の両方でアップグレードを実行します。
双方向伝播(ステージングから本番に伝播してから再度ステージングに戻る)を実行したことがある場合または伝播が失敗した場合は、次の追加手順を実行する必要があります。これらの状況がどちらも当てはまらない場合は、この追加手順をスキップして手順2に進みます。
ソース・システムと宛先システムの両方の各コンシューマ・アプリケーションからプロデューサ登録ハンドルを取得します。これを行うには、第A.1.2.5項「プロデューサ・ハンドルのリスト」の説明に従って、プロデューサのリストJSPユーティリティを実行します。
プロデューサ・アプリケーションをWebLogic Portal 10.0にアップグレードします。ステージング環境と本番環境の両方でアップグレードを実行します。
双方向伝播(ステージングから本番に伝播してから再度ステージングに戻る)を実行したことがある場合または伝播が失敗した場合は、次の追加手順を実行する必要があります。これらの状況がどちらも当てはまらない場合は、この追加手順をスキップして手順3に進みます。
プロデューサ登録ハンドルを更新します。これを行うには、第A.1.2.6項「プロデューサ登録ハンドルの更新」の説明に従って、登録ハンドルの更新JSPユーティリティを実行します。
伝播ツールを使用して、コンシューマ・アプリケーションをステージング環境から本番環境に伝播させます。伝播の詳細は、Oracle Fusion Middleware Oracle WebLogic Portalプロダクション業務ガイドを参照してください。
|
ヒント: 伝播時には、ポータル・フレームワーク・リソースのみを含むようにスコープを調整できます。 |
これでアップグレード・プロセスは完了です。これにより、ステージング環境と本番環境のコンシューマ・アプリケーションが個別のプロデューサを参照できるようになります。
|
注意: ステージングと本番のコンシューマが同じプロデューサを参照する構成を維持することもできます。ただし、WebLogic Portal 9.2プロダクション業務ガイド(http://download.oracle.com/docs/cd/E13218_01/wlp/docs92/prodOps/index.html)のWSRPの伝播に関する項に記載されている制限事項は適用されなくなります。 |
ポータルの伝播の詳細は、Oracle Fusion Middleware Oracle WebLogic Portalプロダクション業務ガイドを参照してください。
ドメインおよびプロデューサ・アプリケーションのみをアップグレードし、コンシューマはアップグレードしない場合は、この項のアップグレード手順を実行する必要があります。この項の手順は、コンシューマ・アプリケーションが現在WebLogic Portal 8.1.xまたは9.2であっても同様に適用されます。
|
注意: プロデューサのみをアップグレードする場合は、WebLogic Portal 9.2プロダクション業務ガイド(http://download.oracle.com/docs/cd/E13218_01/wlp/docs92/prodOps/index.html)のWSRPの伝播に関する項に記載されている伝播モデルを使用する必要があります。このモデルでは、ステージング環境と本番環境の両方のコンシューマ・アプリケーションが同じプロデューサを参照する必要があります。 |
|
注意: プロデューサのみをアップグレードする場合は、コンシューマ・アプリケーションでリモート・ポートレットを伝播するたびに、次の手順2と手順3を実行する必要があります。 |
プロデューサ・アプリケーションをWebLogic Portal 10.0にアップグレードします。
ソース・システムと宛先システムの両方の各コンシューマ・アプリケーションからプロデューサ登録ハンドルを取得します。これを行うには、第A.1.2.5項「プロデューサ・ハンドルのリスト」の説明に従って、プロデューサのリストJSPユーティリティを実行します。
宛先システムのアップグレードされた各プロデューサ・アプリケーションのプロデューサ登録ハンドルを更新します。これを行うには、第A.1.2.6項「プロデューサ登録ハンドルの更新」の説明に従って、登録の更新JSPユーティリティを実行します。
ポータルの伝播の詳細は、Oracle Fusion Middleware Oracle WebLogic Portalプロダクション業務ガイドを参照してください。
コンシューマ・アプリケーションをアップグレードし、プロデューサはアップグレードしない場合は、この項のアップグレード手順を実行する必要があります。この項の手順は、プロデューサ・アプリケーションが現在WebLogic Portal 8.1.xまたはも9.2であっても同様に適用されます。
|
注意: ステージングと本番のコンシューマが同じプロデューサを参照する構成を維持することもできます。ただし、WebLogic Portal 9.2プロダクション業務ガイド(http://download.oracle.com/docs/cd/E13218_01/wlp/docs92/prodOps/index.html)のポータルの伝播に関する項に記載されている制限事項は適用されなくなります。 |
|
注意: コンシューマのみをアップグレードする場合は、WebLogic Portal 9.2プロダクション業務ガイド(http://download.oracle.com/docs/cd/E13218_01/wlp/docs92/prodOps/index.html)のWSRPの伝播に関する項に記載されている伝播モデルを使用する必要があります。このモデルでは、ステージング環境と本番環境の両方のコンシューマ・アプリケーションが同じプロデューサを参照する必要があります。 |
|
注意: コンシューマのみをアップグレードする場合は、コンシューマ・アプリケーションを伝播するたびに、手順2と手順3を実行することをお薦めします。 |
コンシューマ・アプリケーションをWebLogic Portal 10.0にアップグレードします。ステージング環境と本番環境の両方でアップグレードを実行します。
|
注意: ステージング環境と本番環境のコンシューマ・アプリケーションが同じプロデューサを参照する構成を現在実行している場合は、次のオプションの手順を実行することをお薦めします。 |
(オプション/推奨)ソース・システムと宛先システムの両方の各コンシューマ・アプリケーションからプロデューサ登録ハンドルを取得します。これを行うには、第A.1.2.5項「プロデューサ・ハンドルのリスト」の説明に従って、プロデューサのリストJSPユーティリティを実行します。
(オプション/推奨)宛先システムのアップグレードされた各プロデューサ・アプリケーションのプロデューサ登録ハンドルを更新します。これを行うには、第A.1.2.6項「プロデューサ登録ハンドルの更新」の説明に従って、登録の更新JSPユーティリティを実行します。
|
注意: コンシューマのみをアップグレードする場合は、コンシューマ・アプリケーションを伝播するたびに、手順2と手順3を実行することをお薦めします。 |
コンシューマ・アプリケーションがデプロイされているステージング・システムと本番システムの両方で、プロデューサのリストJSPユーティリティ(listProducers.jsp)を実行できます。このユーティリティは、コンシューマに追加済のプロデューサの登録ハンドルを取得します。
手順については、Oracle Fusion Middleware Oracle WebLogic Portalプロダクション業務ガイドを参照してください。
ステージング・システムと本番システムの両方で、登録の更新JSPユーティリティ(updateRegistrations.jsp)を実行できます。このユーティリティは、特定のプロデューサを現在参照する各コンシューマ・アプリケーションの登録ハンドルを更新します。
手順については、Oracle Fusion Middleware Oracle WebLogic Portalプロダクション業務ガイドを参照してください。
統合ユーザー・プロファイル(UUP)をWebLogic Portal 8.1から10.3.4にアップグレードすると、p13n_ejb.jarファイルが削除され、WebLogic Portal 9.2ファイルの新しいバージョンで置き換えられます。この新しいp13n_ejb.jarファイルは、WebLogic Portal 9.2に付属のライブラリ・モジュールにパッケージ化されています。
WebLogic Portal 8.1で構成されたUUPをWebLogic Portal 9.2にアップグレードするには、次の手順を実行します。
Oracle Enterprise Pack for Eclipseを起動し、新しいワークスペースを作成します。
新しいポータル・ドメインを作成します。ポータルEARプロジェクトは作成しないでください。新しいドメインの作成方法については、Oracle Fusion Middleware Oracle WebLogic Portalポータル開発ガイドを参照してください。
「ファイル」→「インポート」を選択して、Portal 8.1 UUPアプリケーションを新しい環境にインポートします。
「インポート」ダイアログ・ボックスで「その他」フォルダを開き、Workshop 8.1アプリケーションを選択して、「次へ」をクリックします。
アプリケーションのインポートダイアログ・ボックスで「参照」をクリックし、8.1 UUPアプリケーションを選択します。.workファイルを選択し、「開く」をクリックします。図A-1に示すように、UUPアプリケーションのチェック・ボックスが選択されていることを確認し、「次へ」をクリックします。
ソースのアップグレードダイアログ・ボックスで、NetUIプロジェクト・アップグレーダ・オプションをクリックし、WebLogic J2EE共有ライブラリを使用チェック・ボックスを選択します。JSPファイル・マイグレータ・オプションをクリックし、Oracle NetUIタグをApache Beehiveタグで置き換えるチェック・ボックスを必要に応じて選択して、「終了」をクリックすることもできます。
アップグレードの終了後、次のアクションが実行されたことを確認します。
p13n-ejb.jarファイルがUUPアプリケーションのEARContentディレクトリから削除されたこと。
UUP EJB JARファイル(たとえばUUPExample.jar)がUUPアプリケーションのEARContentディレクトリに存在すること。
UUP EJB JARファイルが<UUPApplication>/EARContent/META-INF/ディレクトリにあるapplication.xmlファイルのモジュール・エントリで参照されていること。
例として、次のキャッシュ・エントリが<UUPApplication>/EARContent/META-INF/ディレクトリのp13n-cache-config.xmlファイルに追加されます。
<p13n:cache>
<p13n:name>UUPExampleCache</p13n:name>
<p13n:description>Cache for UUP Example</p13n:description>
<p13n:time-to-live>60000</p13n:time-to-live>
<p13n:max-entries>100</p13n:max-entries>
</p13n:cache>
ユーザー・プロファイル・ファイル(たとえばUUPExample.usr)がdata/src/userprofiles/ディレクトリ(またはDatasyncフォルダが存在するディレクトリ)に存在すること。
「サーバー」タブでサーバーを選択し、サーバーを右クリックしてプロジェクトの追加と削除を選択することにより、ポータル・アプリケーションをWebLogic Serverに関連付けます。「使用可能なプロジェクト」セクションからポータル・アプリケーションを選択し、「追加」をクリックし、「終了」をクリックします。
アプリケーションをビルドして公開します。WebLogic Server管理コンソールを起動して「デプロイメント」をクリックすることにより、アプリケーションを検証します。UUPアプリケーションがアクティブであることを確認します。次に、ツリーを開き、UUP JARファイルがEJBとして表示されていることを確認して、UUPアプリケーションを開きます。
WebLogic Portal 9.2と10.0では、2つのJSPタグ(<ugm:login>と<ugm:logout>)が非推奨になっています。<ugm:login>と<ugm:logout> JSPタグは、ugm_taglib.jarファイルからauth_taglib.jarファイルに移動されています。
10.3.4へのアップグレード後は、<auth:login>と<auth:logout> JSPタグを使用してください。属性とパラメータは同じです。
アップグレードが完了したら、管理コンソールを使用して、サード・パーティ・リポジトリのパスワードを手動で再入力する必要があります。リポジトリ設定の編集の詳細は、Oracle Fusion Middleware Oracle WebLogic Portalコンテンツ管理SPI開発ガイドを参照してください。
サード・パーティ・リポジトリのパスワードを手動で再入力するまで、これらのリポジトリにアクセスすることはできません。
WebLogic 8.1からWebLogic Portal 8.1 SP5では、優先順位の問題に起因して、コンテンツ問合せ式が異なる方法で生成されていました。コンテンツ問合せ式の実行時、優先順位は維持されていませんでした。たとえば、(a && (b || c)という式は、(a && b || c)と評価(実行)されました。
この問題はWeblogic Portal 10.0で修正されており、現在はコンテンツ問合せ式の実行時に優先順位が維持されます。ただし、WebLogic Portal 8.1からWebLogic Portal SP5での問合せ動作を引き続き使用する場合は、次のシステム・プロパティを定義するようにドメイン・スクリプトを編集する必要があります。-Dwlp.disable.content.rule.fix=true
WebLogic Portal 8.1のポータルのルック・アンド・フィールでは、スキンとスケルトンに、skin.properties(/skins/<skin_name>ディレクトリ)とskeleton.properties(/skeletons/<skeleton_name>ディレクトリ)という2つの構成ファイルを使用していました。どちらもテキスト・ファイルであり、skeleton.propertiesはオプションでした。
WebLogic Portal 10.0では、どちらのファイルもXMLで、必須になりました。
WebLogic Portal 8.1のルック・アンド・フィールをWebLogic Portal 10.3.4のフォーマットにアップグレードする手順は次のとおりです。
ルック・アンド・フィールを含むポータル・アプリケーションがWebLogic Portal 10.0に変換されていることを確認します。詳細は、Oracle Fusion Middleware Oracle WebLogic Portalポータル開発ガイドを参照してください。
Oracle Enterprise Pack for Eclipseでルック・アンド・フィールを開き、再保存します。構成ファイルが自動的に新しいXML形式に変換されます。
cm_taglib.jarとpz_compat_taglib.jarはアップグレード時に削除され、インポート・ウィザードにより、これらのtaglibを参照するすべてのJSPに、サポートされていないtaglib URIを持つことを示すフラグが付けられます。JSPは失敗します。
デフォルトでは、cm_taglib.jarファイルは新しい8.1 Webアプリケーションにインストールされませんでしたが、下位互換性のためにそれをアプリケーションに追加した場合は、アップグレードされたアプリケーション内でこのファイルを手動で処理する必要があります。
サポートされているタグおよびAPIを使用するように、cm_taglib.jarとpz_compat_taglib.jarへのすべての参照を変更し、古いjarファイルを削除します。
Struts 1.2にアップグレードする場合、10.3.4では、Strutsに対するWebLogic Portalのサポートが多少異なります。
WebLogic PortalでのStruts 1.1のサポートは以前のリリースと同じであり、web.xmlを使用してstruts-adapter taglibがURIにマップされます。新しいstruts-1.2.warライブラリ・モジュールのかわりにstruts-1.1.warライブラリ・モジュールを使用できます。
Struts 1.2にアップグレードする場合、web.xmlを使用してstrutsとstruts-adapter taglibをマップするかわりに、WebLogic Portalでは現在JSP 1.2の暗黙的なtaglibマッピングを使用しているため、JARのMETA-INFディレクトリの.tldファイルは、Webコンテナによって、tldに指定されているURIに暗黙的にマップされます。WebLogic Portalでは、これらはパスMETA-INF/tldsのstruts-adapter.jarにあります。
Struts 1.2にアップグレードするには、次の2つのいずれかの方法を選択します。
struts taglibを使用するすべてのJSPを、HTMLおよびネストされたtaglibについてはhttp://bea.com/struts/adapter/tags-htmlおよびhttp://bea.com/struts/adapter/tags-nestedを参照するように、アダプタによってオーバーライドされない残りのtaglibについてはhttp://struts.apache.org/tags-*を参照するように編集します。
.tldをstruts.jar(struts-1.1.war内)およびstruts-adapter.jar(ポータルWebライブラリ・モジュール内)の両方から抽出し、WEB-INF/tldsにコピーします。これにより、web.xmlを使用した明示的なtldマッピングを引き続き使用できます。
WebLogic Portal 8.1では、セッション用に最小限のポートレットの状態が永続化されていました。WebLogic Portal 8.1アップグレード・ガイドに記載されている回避策を使用して、デスクトップ下でのポートレットの状態を制御するバッキング・ファイルを設定できます。
この動作に依存すれば、8.1で使用していたソリューションを引き続き使用できます。手順および例については、WebLogic Portal 9.2ポータル開発ガイド(http://download.oracle.com/docs/cd/E13218_01/wlp/docs92/portlets/index.html)を参照してください。
WebLogic Portal 10.3.4で開発されたプロデューサ・アプリケーションおよびコンシューマ・アプリケーションは、WebLogic Portal 8.1で開発されたプロデューサおよびコンシューマと互換性があります。つまり、WebLogic Portal 10.0で開発されたポータルは、WebLogic Portal 8.1ドメインにデプロイされたポートレットを使用できます。同様に、WebLogic Portal 10.3.4プロデューサで公開されたポートレットを8.1コンシューマで使用することが可能です。
ただし、8.1または9.2コンシューマに対して独自のキーを使用する場合は、Oracle Fusion Middleware Oracle WebLogic Portalフェデレーテッド・ポータル・ガイドの「SAMLを使用したWSRPセキュリティの確立」に記載されている手順に従う必要があります。
この項では、HTTPレスポンスでのエンコーディングの設定方法の変更について説明します。
WebLogic Portal 8.1では、次の方法を使用してエンコーディングを設定していました。
.portalファイルでdirective.page要素の有無を確認します。その要素が存在する場合は、その属性からエンコーディングを取得します。
要素が存在しない場合は、JSPエンコーディングの構成を使用します。これはweb.xmlファイルの<jsp-param>セクションの<encoding>要素を確認します。これらの要素が存在しない場合、デフォルトはISO-8859-1です。
これらのメカニズムはどちらも現在は非推奨となっています。
8.1およびそれ以前のリリースとの互換性のため、また切断されたデスクトップの使用が望ましいいくつかの状況をサポートするために、WebLogic Portal 10.3.4には、新しいが非推奨となっている、StandalonePortletURL用のdesktopStateSharedというブール型プロパティおよび関連するJSPタグが用意されています。このプロパティを使用すると、従来の「切断されたデスクトップ」の動作を維持することができます。このプロパティと属性のデフォルト値はtrueであり、その場合ポートレットはデスクトップに接続されます。
pathまたはcontextualPathプロパティをURLまたはタグ上で明示的に設定すると、生成されるスタンドアロン・ポートレットと生成元のデスクトップとの関連付けも解除されます。スタンドアロン・ポートレットのコンテキスト内で生成されたURLについても同じことが言えます。pathまたはcontextualPathを設定すると、生成されるURLと生成元のデスクトップとの関連付けが解除されます。
8.1および以前のリリースのWebLogic Portalでは、推奨されてはいませんが、階層内の同じレベルに同じ名前のポートレット・カテゴリを複数作成することが可能でした。10.3.4では、この操作は許可されません(複数のカテゴリに同じ名前を使用できますが、階層内で同じレベルに配置することはできません)。
ポータル・アプリケーションを10.3.4にアップグレードすると、以前使用されていた重複するポートレット・カテゴリ名は維持されます。これらのカテゴリ名が一意になるように編集することが非常に重要です。一意にしないと、WebLogic Portal伝播ツールで予期しない結果が発生したり、伝播プロセス中にエラーが発生する可能性があります。
伝播ユーティリティWebアプリケーションpropagation.warは、WebLogic Portal 9.2で廃止されています。このアプリケーションはWebLogic Portal 8.1 SP4用のパッチで導入され、その後WebLogic Portal 8.1 SP5に組み込まれました。WebLogic Portalエンタープライズ・アプリケーションのルート・ディレクトリにpropagation.warファイルをインストールしたWebLogic Portalアプリケーションをアップグレードする場合は、WebLogic Portal 10.3.4へのアップグレード前または後にこのファイルを削除することをお薦めします。
WebLogic Portal 8.1には、定義ラベルを編集する機能がありましたが、推奨されていませんでした。定義ラベルを編集すると、たとえば保護されたリソースの公開やWSRP(ポートレット・ハンドルとして定義ラベルを使用する)の破損など、意図しない結果につながることがありました。
WebLogic Portal 9.2以降ではこの機能が置き換えられ、ユーザーのカスタマイズを失ったり、ラベルを変更したりすることなく、本番環境と開発環境の間でポータル・リソース(ブック、ページ、デスクトップ)を移動することができます。これらの新機能には、XIPや伝播ユーティリティなどがあります。XIPでは、個々のポータル・リソースを対象として開発システムと本番システムとの間でインポートおよびエクスポートを実行でき、スコープ(ライブラリ、管理者またはビジター)を指定できます。WebLogic Portalの伝播ツールの詳細は、Oracle Fusion Middleware Oracle WebLogic Portalプロダクション業務ガイドを参照してください。
WebLogic Portal 8.1または9.2で保存されたWebLogic Portalインベントリは、WebLogic Portal 10.0の伝播ツールでは使用できません。
次の各項では、WebLogic Portal 9.2または9.2 MP1から10.2/10.3/10.3.2/10.3.4.にアップグレードした場合に発生する変更について説明します。手動での作業が必要になる場合があります。
この項のトピックは、次のとおりです。
フェデレーテッド・ポータルを9.2から10.3.4にアップグレードする手順は、8.1から10.3.4にアップグレードする手順と同じです。詳細は、第A.1.2項「フェデレーテッド・ポータルの8.1から10.3.4へのアップグレード」を参照してください。
WebLogic Portal 9.2または9.2 MP1のUUPは、WebLogic Portal 10.3.4で自動的に動作します。9.2のUUPをアップグレードする必要はありません。
WebLogic Portal 8.1およびそれ以前のリリースとの下位互換性のため、また切断されたデスクトップの使用が望ましいいくつかの状況をサポートするために、WebLogic Portal 9.2には、新しいが非推奨となっている、StandalonePortletURL用のdesktopStateSharedというブール型プロパティおよび関連するJSPタグが用意されていました。このプロパティは10.3.4でも維持されており、非推奨のままです。
詳細は、第A.1.13項「切断されたデスクトップにdesktopStateSharedプロパティが必要」を参照してください。
前述の各項の作業を終了したら、WLPコンテンツを再索引付けする必要があります。WLPコンテンツの再索引付けの詳細は、Oracle Fusion Middleware Oracle WebLogic Portal Autonomy Search統合サンプル・ガイドを参照してください。
WebLogic Portal 10.3.4で開発されたプロデューサ・アプリケーションおよびコンシューマ・アプリケーションは、WebLogic Portal 9.2で開発されたプロデューサおよびコンシューマと互換性があります。つまり、WebLogic Portal 10.3.4で開発されたポータルは、WebLogic Portal 9.2ドメインにデプロイされたポートレットを使用できます。同様に、WebLogic Portal 10.3.4プロデューサで公開されたポートレットを9.2コンシューマで使用することが可能です。
ただし、9.2、10.0、10.2、10.3、10.3.2または10.3.4コンシューマに対して独自のキーを使用する場合は、Oracle Fusion Middleware Oracle WebLogic Portalコンテンツ管理SPI開発ガイドの「SAMLを使用したWSRPセキュリティの確立」に記載されている手順に従ってください。
9.2で伝播Antスクリプトを作成した場合は、手動でそれらを更新するか、10.0でスクリプトを再生成する必要があります。この変更は、いくつかのJARファイル名と、すべての伝播Antタスクのパッケージ名が変更されているために必要です。
Oracle Enterprise Pack for Eclipseを使用してスクリプトを再生成すると、正しいファイル名とパッケージ名が自動的に使用されます。スクリプトを手動で更新しなければならない場合(たとえば、最初にそれらを手動で作成した場合)、次の変更を加える必要があります。
伝播antタスクは現在、com.bea.propagation.ant.taskdefsパッケージに含まれています。
次の表は、9.2のJARファイル名および10.0で更新された名前を示します。
WebLogic Portal 8.1または9.2で保存されたWebLogic Portalインベントリは、WebLogic Portal 10.3.4の伝播ツールでは使用できません。
WebLogic Serverでは、外部のRDBMSを、認可、ロール・マッピング、資格証明マッピングおよび証明書レジストリ・プロバイダのデータストアとして使用するオプションを選択できます。WebLogic Portalでは、このデータストアをそのデフォルトのドメイン構成の一部として使用します。WLPドメインの構成時に、RDBMSセキュリティ・ストア表が自動的に作成されます。
RDBMSセキュリティ・ストアの詳細は、WebLogic Serverドキュメント『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のRDBMSセキュリティ・ストアの管理に関する項を参照してください。Oracle Fusion Middleware Oracle WebLogic Portalデータベース管理ガイドのRDBMSセキュリティ・ストア表に関する項も参照してください。
