|
|
この付録では、WebLogic Portal 10.3 で行われた機能の変更について説明します。これらの変更はアップグレード後の環境に影響し、手動でタスクを実行しなければならない場合があります。
以下の節では、Portal 8.1 から 10.3 に直接アップグレードする際の変更について説明します。手動でタスクを実行しなければならない場合があります。
RDBMS 認証プロバイダは、8.1 でサポート対象でしたが、ポータル 9.2 および以降のすべてのリリースでは非推奨となりました。RDBMS 認証プロバイダは、SQL 認証プロバイダに置き換えられました。
RDBMS 認証プロバイダがあるドメインをアップグレードするため、[アップグレード ウィザード] でのサポートを有効にするには、以下の手順を手動で実行する必要があります。8.1 RDBMS 認証プロバイダから Portal 10.3 にアップグレードする前に、以下の解決策を実行します。
| ヒント : | ドメインのアップグレード プロセス中にユーザ ストアをアップグレードしなかった場合は、後で手動でアップグレードできます。upgrade_fromdbmsauth_tosqlauth.sql スクリプトを実行して、WebLogic Portal 固有の RDBMS 認証プロバイダから WebLogic SQL 認証プロバイダへアップグレードします。スクリプトは、<WLPORTAL_HOME>\p13n\db\<DBMS>\ ディレクトリにあります。 |
WebLogic Portal 10.0 に追加された連合ポータル伝播をサポートする新機能では、この節のアップグレード手順を実行する必要があります。
WebLogic Portal 10.3 は WSRP 2.0 の機能をサポートし、より柔軟で実践的な連合ポータルの伝播アプローチを可能にします。WebLogic Portal 10.3 では、ステージングおよびプロダクション環境のコンシューマ アプリケーションが個別のプロデューサをポイントすることが可能です。この新機能の主な利点は、プロダクション環境とは独立して、ステージング環境でリモート (プロキシ) ポートレットを作成および変更できる点です。
WebLogic Portal 10.0 以前は、WSRP コンシューマ アプリケーションを伝播するには、ソースおよび送り先システムのコンシューマが同じプロデューサをポイントしている必要がありました。このコンフィグレーションは WebLogic Portal 9.2 の『プロダクション業務ガイド』の「WSRP 伝播」に記載されていますが、いくつかの制限があります。
この節では、連合ポータルのアップグレード手順を説明します。ここで記載された手順は、以下のシナリオに適用されます。
ソース (ステージング) および送り先 (プロダクション) 環境のプロデューサおよびコンシューマの両方のアプリケーションを WebLogic Portal 10.0 にアップグレードすることが推奨されます。これにより、新しい伝播機能を利用して、伝播処理を簡素化できます。
ソースおよび送り先システムの各コンシューマ アプリケーションからプロデューサ登録ハンドルを取得します。これを行うには、「プロデューサ ハンドルのリスト」で説明しているプロデューサ リスト JSP ユーティリティを実行します。
プロデューサ登録ハンドルを更新します。これを行うには、「プロデューサ登録ハンドルの更新」で説明している登録ハンドル更新 JSP ユーティリティを実行します。
| ヒント : | 伝播時は、ポータル フレームワークのリソースのみを含めるようにスコープを調整できます。 |
これでアップグレード処理は完了です。これにより、ステージングおよびプロダクション環境のコンシューマ アプリケーションが個別のプロデューサをポイントできるようになります。
| 注意 : | ステージングとプロダクションのコンシューマが同一のプロデューサを指定するコンフィグレーションを保持する必要がある場合は、そうすることも可能です。ただし、Portal 9.2 の『プロダクション業務ガイド』の「WSRP 伝播」に記載された制限は適用されなくなります。 |
ポータルの伝播の詳細については、『プロダクション業務ガイド』を参照してください。
ドメインとプロデューサ アプリケーションをアップグレードし、コンシューマをアップグレードしない場合は、この節のアップグレード手順を実行する必要があります。この節の手順は、コンシューマ アプリケーションが現在 WebLogic Portal 8.1.x または 9.2 であっても同様に適用されます。
| 注意 : | コンシューマのみをアップグレードする場合は、Portal 9.2 の『プロダクション業務ガイド』の「WSRP 伝播」に記載された伝播モデルを使用する必要があります。このモデルでは、ステージングとプロダクションの両方の環境のコンシューマ アプリケーションが同じプロデューサをポイントする必要があります。 |
| 注意 : | プロデューサのみをアップグレードする場合は、リモート ポートレットをコンシューマ アプリケーションに伝播するたびに以下の手順 2 および、手順 3 を実行する必要があります。 |
ポータルの伝播の詳細については、『プロダクション業務ガイド』を参照してください。
コンシューマ アプリケーションをアップグレードし、プロデューサをアップグレードしない場合は、この節のアップグレード手順を実行する必要があります。この節の手順は、プロデューサ アプリケーションが現在 WebLogic Portal 8.1.x または 9.2 であっても同様に適用されます。
| 注意 : | ステージングとプロダクションのコンシューマが同一のプロデューサをポイントするコンフィグレーションを保持する必要がある場合は、そうすることも可能です。ただし、WebLogic Portal 9.2 の『プロダクション業務ガイド』の「WSRP 伝播」に記載された制限は適用されなくなります。 |
| 注意 : | コンシューマのみをアップグレードする場合は、WebLogic Portal 9.2 の『プロダクション業務ガイド』の「WSRP 伝播」に記載された伝播モデルを使用する必要があります。このモデルでは、ステージングとプロダクションの両方の環境のコンシューマ アプリケーションが同じプロデューサをポイントする必要があります。 |
| 注意 : | コンシューマのみをアップグレードする場合は、コンシューマ アプリケーションを伝播するたびに手順 2 と 3 を実行することが推奨されます。 |
| 注意 : | 現在ステージングとプロダクション環境のコンシューマ アプリケーションが同じプロデューサをポイントするコンフィグレーションを実行している場合、以下の手順はオプションですが推奨される手順です。 |
| 注意 : | コンシューマのみをアップグレードする場合は、コンシューマ アプリケーションを伝播するたびに手順 2 と 3 を実行することが推奨されます。 |
コンシューマ アプリケーションがデプロイされているステージングおよびプロダクションの両方のシステムでプロデューサ リスト JSP ユーティリティ (listProducers.jsp) を実行することができます。このユーティリティは、コンシュｰマに事前に追加されているプロデューサの登録ハンドルを取得します。
手順については、『プロダクション業務ガイド』を参照してください。
ステージングおよびプロダクションの両方のシステムで登録更新 JSP ユーティリティ (updateRegistrations.jsp) を実行できます。このユーティリティは、指定のプロデューサを現在参照している各コンシューマ アプリケーションの登録ハンドルを更新します。
手順については、『プロダクション業務ガイド』を参照してください。
WebLogic Portal 8.1 から 10.3 に統合ユーザ プロファイル (UUP) をアップグレードする場合は、p13n_ejb.jar ファイルが削除され、新しい WebLogic Portal 9.2 バージョンのファイルに置き換えられます。新しい p13n_ejb.jar ファイルは、WebLogic Portal 9.2 に付属のライブラリ モジュールにパッケージ化されます。
次の手順を実行して、WebLogic Portal 8.1 でコンフィグレーションされた UUP を WebLogic Portal 9.2 の UUP にアップグレードします。
.work ファイルを選択し、[開く] をクリックします。UUP アプリケーションのチェック ボックスが選択されていることを確認し、[次] をクリックします。画面は図 A-1 のようになります。
p13n-ejb.jar ファイルが削除されている。UUPExample.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>data/src/userprofiles/ ディレクトリ (または Datasync フォルダが存在するディレクトリ) にユーザ プロファイル ファイル (たとえば、UUPExample.usr) が存在することを確認する。
2 つの JSP タグ <ugm:login> および <ugm:logout> は WebLogic Portal 9.2 および 10.0 で非推奨になっています。<ugm:login> および <ugm:logout> JSP タグは ugm_taglib.jar ファイルから auth_taglib.jar ファイルに移動されました。
10.3 へのアップグレード後は、<auth:login> および <auth:logout> JSP タグを使用する必要があります。属性とパラメータは同じです。
Autonomy 検索を使用していて、WebLogic Portal 8.1 からアップグレードする場合は、次の手順を実行して WebLogic Portal 10.3 に含まれている新バージョンの Autonomy にアップグレードする必要があります。アップグレード プロセスでは、既存の検索設定とデータベースは新しい検索機能に自動的には移行されません。アップグレードしたアプリケーションで Autonomy 検索を操作するには、手動でコンフィグレーションする必要があります。
新バージョンの Autonomy は、<WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10 ディレクトリにインストールされます。Autonomy 検索コンフィグレーションの詳細については、『検索の統合ガイド』を参照してください。
Autonomy 検索のインストールとコンフィグレーションが終了したら、新しい機能を使用できるように、次の手順を実行してアプリケーションをアップグレードします。
WebLogic Portal com.bea.query クラスまたは 8.1 Autonomy API を使用してアプリケーションを記述し、新しい 9.2 バージョンの Autonomy API を使用しないでこれらのアプリケーションを引き続き使用する場合、古い非推奨 API をアプリケーションに手動で追加する必要があります。
ただし、WebLogic Portal または Autonomy の 8.1 API を引き続き使用する場合、8.1 API が 10.0 API より優先され、10.0 Autonomy エンジンとの互換性がなくなります。つまり、全文検索など、10.0 の一部のコンテンツ管理機能を使用できません。
8.1 バージョンの Autonomy をポータル アプリケーションで引き続き使用する場合、古い API をインストールに手動で追加する必要があります。
古いバージョンの Autonomy を 10.0 アプリケーションに追加するには
autonomyCompat.jar と autonomyClient.1.5.0.jar を <WLPORTAL_HOME>/info-mgmt/lib/thirdparty/search/81-compat-only ディレクトリから application_home/app-INF/lib ディレクトリにコピーします。
8.1 の Autonomy API とエンジンが実行されます。
「10.0 ポータル アプリケーションにおける 8.1 検索の使用」の手順を完了した後に 10.0 バージョンの Autonomy にアップグレードする場合、実装を元に戻すことができます。
9.2 で 8.1 Autonomy を実装した後に 10.0 バージョンの Autonomy を使用するようにアップグレードするには
com.bea.query.* クラスの使用またはアプリケーションの Autonomy クライアント API への呼び出しを探し、更新し、それらを 10.0 バージョンの Autonomy API への適切な呼び出しに置き換えます。autonomyCompat.jar ファイルと autonomyClient1.5.0.jar ファイルを app-inf/lib ディレクトリから削除します。
アップグレードが完了したら、Administration Console を使用してサードパーティのリポジトリのパスワードを手動で再入力します。リポジトリ設定の編集については、『コンテンツ管理ガイド』を参照してください。
サードパーティのリポジトリのパスワードを手動で再入力するまで、それらのリポジトリにはアクセスできません。
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 形式にアップグレードするには、次の作業を行います。
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 では Struts に対する WebLogic Portal のサポートは若干異なります。
WebLogic Portal の Struts 1.1 サポートは以前のリリースと同じであり、web.xml を使用して struts-adapter taglib が URI にマップされます。新しい struts-1.2.war ライブラリ モジュールの代わりに、struts-1.1.war ライブラリ モジュールを使用できます。
web.xml を使用して struts と struts-adapter taglib をマップするのではなく、Struts 1.2 にアップグレードすると、現在 WebLogic Portal は JSP 1.2 の暗黙的な taglib マッピングを使用しているため、Web コンテナによって JAR の META-INF ディレクトリにある .tld ファイルが tld に指定した URI に暗黙的にマップされます。WebLogic Portal では、これらはパス META-INF/tlds の struts-adapter.jar にあります。
Struts 1.2 にアップグレードするには、次の 2 種類の方法のいずれかを選択します。
http://bea.com/struts/adapter/tags-html を、ネストされた taglib の場合は http://bea.com/struts/adapter/tags-nested を、アダプタがオーバーライドしない他の taglib の場合は http://struts.apache.org/tags-* を参照する struts taglib を使用する。struts.jar (struts-1.1.war 内) と struts-adapter.jar (ポータル Web ライブラリ モジュール内) の両方から .tld を抽出し、WEB-INF/tlds にコピーする。これにより、web.xml を使用した明示的 tld マッピングを引き続き使用できます。
WebLogic Portal 8.1 では、セッション用に最小限のポートレット状態が永続化されていました。解決策として、『WebLogic Portal 8.1 へのアップグレード』で記載されているように、デスクトップのポートレットの状態を制御するバッキング ファイルを設定できます。
この動作に依存すると、8.1 で使用された解決は引き続き使用できます。手順および例については、『9.2 ポートレット ガイド』を参照してください。
WebLogic Portal 10.3 を使用して開発されたプロデューサ アプリケーションとコンシューマ アプリケーションは、WebLogic Portal 8.1 を使用して開発されたプロデューサおよびコンシューマと互換性があります。つまり、WebLogic Portal 10.0 を使用して開発したポータルは、WebLogic Portal 8.1 ドメインにデプロイされたポートレットを使用できます。同じように、WebLogic Portal 10.3 プロデューサでエクスポーズしたポートレットは、8.1 コンシューマによって使用できます。
ただし、8.1 コンシューマまたは 9.2 コンシューマに対して独自のキーを使用する場合は、『連合ポータル ガイド』の「SAML による WSRP セキュリティの確立」の手順に従う必要があります。
この節では、HTTP 応答のエンコーディング設定の変更について説明します。
WebLogic Portal 8.1 では、以下のメソッドは、エンコーディングを設定するのに使用されました。
Workshop for WebLogic でのエンコーディングの設定および編集手順については、『10.3 ポータル開発ガイド』を参照してください。
8.1 および以前のリリースとの互換性のため、および接続解除された少数のデスクトップを使用可能にするために、WebLogic Portal 10.3 は新しいブール プロパティを備えています(非推奨)。これは、StandalonePortletURL および関連付けられた JSP タグ用の desktopStateShared と呼ばれています。このプロパティを使用すると、以前の「接続解除されたデスクトップ」の動作を残すことができます。このプロパティと属性のデフォルト値は true になり、その場合はポートレットがデスクトップに接続します。
URL またはタグの path プロパティまたは contextualPath プロパティを明示的に設定すると、接続元デスクトップからスタンドアロン ポートレットへの関連付けも解除されます。また、スタンドアロン ポートレットのコンテキスト内で生成されたすべての URL に対して true が保持されます。path または contextualPath の設定によって、URL と接続元デスクトップとの接続が解除されます。
8.1 および以前のリリースの WebLogic Portal では、(非推奨でしたが) 同じ名前、階層の同じレベルで複数のポートレット カテゴリ名を作成することができました。バージョン 10.3 では、この操作は許可されません (複数のカテゴリに対して同じ名前を使用できますが、階層内で「ピア」にすることはできません)。
ポータル アプリケーションを 10.3 にアップグレードすると、以前使用していた重複するポートレット カテゴリ名は保持されます。カテゴリ名を編集してユニークにしてください。ユニークにしないと、WebLogic Portal 伝播ツールで予期しない結果が発生したり、伝播プロセス中にエラーが発生する恐れがあります。
Propagation Utility の Web アプリケーション propagation.war は、WebLogic Portal 9.2 では推奨されていません。このアプリケーションは WebLogic Portal 8.1 SP4 用のパッチで導入された後、WebLogic Portal 8.1 SP5 に組み込まれました。WebLogic Portal エンタープライズ アプリケーションのルート ディレクトリにファイル propagation.war をインストール済みで、WebLogic Portal の Web アプリケーションをアップグレードする場合は、WebLogic Portal 10.3 へのアップグレード前または後にそのファイルを削除することをお勧めします。
WebLogic Portal 8.1 には定義ラベルを編集する機能が用意されていましたが、非推奨でした。定義ラベルを変更すると、保護されたリソースをエクスポーズしたり、ポートレット ハンドルとして定義ラベルを使用する WSRP を壊すなど、意図しない影響を及ぼすことがありました。
WebLogic Portal 9.2 ではこの機能が置き換えられ、ユーザ カスタマイズを失ったり、ラベルを変更することなく、プロダクション環境と開発環境の間でポータル リソース (ブック、ページ、デスクトップ) を移動することができます。この新しい機能には XIP と Propagation Utility が含まれています。XIP では個別のポータル リソースを開発システムとプロダクション システム間でインポートおよびエクスポートでき、スコープ (ライブラリ、管理、または訪問者) を指定できます。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 にアップグレードする際の変更について説明します。手動でタスクを実行しなければならない場合があります。
9.2 から 10.3 への連合ポータルのアップグレード手順は、8.1 から 10.3 への場合の手順と同じです。詳細な手順については、「8.1 から 10.3 への連合ポータルのアップグレード」を参照してください。
WebLogic Portal 9.2 または 9.2 MP1 の UPP は WebLogic Portal 10.3 で自動的に動作します。9.2 UUP をアップグレードする必要はありません。
WebLogic Portal 8.1 および以前のリリースとの下位互換性のため、および接続解除された少数のデスクトップを使用可能にするために、WebLogic Portal 9.2 は新しいブール プロパティを備えています(非推奨)。これは、StandalonePortletURL および関連付けられた JSP タグ用の desktopStateShared と呼ばれています。このプロパティは 10.3 でも保持されていますが、引き続き非推奨です。
詳細については、「接続解除されたデスクトップには desktopStateShared プロパティが必要」を参照してください。
検索サービスをアップグレードすると、Autonomy コンフィグレーション ファイルが更新され、コンテンツのインデックスが再作成されます。
オプションで、10.0 Autonomy インストール ディレクトリを使用するように既存の Autonomy インストールを移行することを選択できます。WebLogic Portal 10.3 には WebLogic Portal 9.2 と同じバージョンの Autonomy が付属していますが、インストール ディレクトリが変更されています。新しいインストール ディレクトリ は、<WLPORTAL_HOME>\content-mgmt\thirdparty\autonomy-wlp10 です。
プロダクション環境の場合は、引き続き 10.3 インストール ディレクトリ (<WLPORTAL_HOME>\content-mgmt\thirdparty\autonomy-wlp10) を使用する必要があります。
開発環境の場合、Oracle は以前のインストール ディレクトリを使用せず、新しいインストール ディレクトリを使用することを推奨します。
新しい複数の言語の検索、クエリ、およびインデックス機能は追加されました。デフォルト 10.3 コンフィギュレーションを変更することなく、9.2 コンフィギュレーションをサポートします。新しい機能の詳細については、『検索の統合../search/multilang.htmlマルチ言語の検索およびインデックス」を参照してください。
| 注意 : | プロダクション環境では WLP コンテンツのインデックスを再作成する必要があります。詳細については、『検索の統合ガイド』を参照してください。 |
WebLogic Portal 9.2 では、リポジトリ コンフィギュレーションが以下のどちらも設定してある場合、CM 全文検索は、起動時にAutonomy と接続されます
WebLogic Portal 10.3 では、接続用の設定では以下のものが必要です。
10.3 の設定では、リポジトリに対して使用される CM 全文検索がより正確に反映されます。
その理由は、WLP 9.2 全文検索アプリケーションでは CM 全文検索インデックスを使用するのに search-indexing-is-enabled=TRUE の設定が必要ですが、これがすでに適用されているからです。ただし、10.3 リポジトリ コンフィギュレーションを確認し、必要に応じて、更新します。
新しい場所を使用するために、必要なすべての Autonomy コンフィグレーション ファイルを更新します。Autonomy コンフィグレーション ファイルの詳細については、『検索の統合ガイド』の「対象サーバでの Autonomy のコンフィグレーション」を参照してください。
検索クエリで引き続き二重引用符をサポートするには、BEACMRepoFetch.cfg ファイルに以下の変更を加える必要があります。
クエリの日本語文字を引き続きサポートするには、AutonomyIDOLServer.cfg ファイルに以下の変更を加える必要があります。
[FieldProcessing] セクションで、以下を行います。[Properties] セクションの前に、以下のセクションを追加します。[SetLanguage]
Property=LanguageFields
PropertyFieldCSVs=*/DRELANGUAGETYPE
[Properties] セクションで、[Properties] セクションのリストの最大数値に 1 を足した数字を使って 19=LanguageFields の形式で行を追加します。[Properties]
0=IndexFields
...
18=MoreReferenceFields
[Properties]
0=IndexFields
...
18=MoreReferenceFields
19=LanguageFields
[Security] セクションの前に、以下のセクションを追加します。[LanguageFields]
LanguageType=TRUE
| 注意 : | 検索、クエリ、およびインデックスに対する追加の日本語とエンコード機能が 10.3 インストールに追加されました。新しい機能の詳細については、『検索の統合』の「マルチ言語の検索およびインデックス」を参照してください。 |
オプションで、現在の 9.2 Autonomy コンフィグレーションを 10.3 インストールに移行できます。
| 注意 : | アップグレードしたプロダクション環境の場合、引き続き既存の 9.2 Autonomy の場所を使用することを推奨します。 |
9.2 Autonomy コンフィグレーションとデータを新しい 10.3 の場所に移行するには
IDOL サーバで、以下のフォルダを 9.2 の場所から 10.3 の場所にコピーします。
\\wlp-92\IDOLserver\IDOL\content\ フォルダにある以下のサブフォルダを、\\wlp-10\IDOLserver\IDOL\content\ の場所の新しいコンテンツ フォルダおよび \\wlp-102\IDOLserver\IDOL\content\ の新しいコンテンツ フォルダの場所にコピーします。\\wlp-92\IDOLserver\IDOL\indextasks\ フォルダにある以下のサブフォルダを、新しい Portal 10.3 の \\wlp-103\IDOLserver\IDOL\indextasks\ フォルダにコピーします。\\wlp-92\IDOLserver\IDOL\agentstore\ フォルダにある以下のサブフォルダを、新しい Portal 10.3 の \\wlp-103\IDOLserver\IDOL\agentstore\ フォルダにコピーします。\\wlp-92\IDOLserver\IDOL\category\ フォルダにある以下のサブフォルダを、新しい Portal 10.3 の \\wlp-103\IDOLserver\IDOL\category\ フォルダにコピーします。
9.2 IDOL サーバからすべてのインデックス付きデータをエクスポートし、10.3 の場所に再インポートする必要があります。
インデックス付きコンテンツをエクスポートするには、ブラウザから以下のコマンドを使用します。ご使用の Autonomy コンフィグレーションの適切なホスト名およびポートを使用します。また、コンテンツのインデックス作成のファイル名をディレクトリを含めて指定する必要があります。
http://host:port/DREEXPORTIDX?FileName<filename>&Compress<true\false>
9.2 の場所からインデックス付きデータをインポートした後、以下のコマンドを使用して、コンテンツを新しい WebLogic Portal 10.3 の場所にインポートします。ご使用の Autonomy コンフィグレーションの適切なホスト名およびポートを使用し、データのエクスポート時に作成されたファイルを使用します。
http://host:port/DREADD?<filename>
上の手順が完了したら、WLP コンテンツのインデックスを再作成する必要があります。WLP コンテンツのインデックス再作成の詳細については、『検索の統合ガイド』を参照してください。
WebLogic Portal 10.3 を使用して開発されたプロデューサ アプリケーションとコンシューマ アプリケーションは、WebLogic Portal 9.2 を使用して開発されたプロデューサおよびコンシューマと互換性があります。つまり、WebLogic Portal 10.3 を使用して開発したポータルは、WebLogic Portal 9.2 ドメインにデプロイされたポートレットを使用できます。同じように、WebLogic Portal 10.3 プロデューサでエクスポーズしたポートレットは、9.2 コンシューマによって使用できます。
ただし、9.2、10.0、10.2 コンシューマまたは 10.3 コンシューマに対して独自のキーを使用する場合は、『連合ポータル ガイド』の「SAML による WSRP セキュリティの確立」の手順に従う必要があります。
9.2 で伝播 Ant スクリプトを作成した場合は、手動で更新するか、または 10.0 で再生成する必要があります。いくつかの JAR ファイル名と、すべての伝播 Ant タスクのパッケージ名が変更されているため、この変更作業が必要です。
Workshop for WebLogic を使用してスクリプトを生成すると、適切なファイル名とパッケージ名が自動的に使用されます。手動でスクリプトを更新する必要がある場合は (たとえば、最初に手動でスクリプトを作成した場合)、以下の変更を行う必要があります。
現在、伝播 ant タスクはパッケージ com.bea.propagation.ant.taskdefs に置かれています。
以下の表は、9.2 JAR ファイル名と 10.0 用の更新名を示します。
WebLogic Portal 8.1 または 9.2 で保存された WebLogic Portal インベントリは WebLogic Portal 10.3 伝播ツールでは使用できません。
  
|