|
|
この付録では、WebLogic Portal 9.2 および 10.0 で行われた機能の変更について説明します。これらの変更はアップグレード後の環境に影響し、手動でタスクを実行しなければならない場合があります。
以下の節では、Portal 8.1 から 10.0 に直接アップグレードする際の変更について説明します。手動でタスクを実行しなければならない場合があります。
WebLogic Portal 10.0 に追加された連合ポータル伝播をサポートする新機能では、この節のアップグレード手順を実行する必要があります。この節では、次のトピックについて説明します。
WebLogic Portal 10.0 は WSRP 2.0 の機能をサポートし、より柔軟で実践的な連合ポータルの伝播アプローチを可能にします。WebLogic Portal 10.0 では、ステージングおよびプロダクション環境のコンシューマ アプリケーションが個別のプロデューサをポイントすることが可能です。この新機能の主な利点は、プロダクション環境とは独立して、ステージング環境でリモート (プロキシ) ポートレットを作成および変更できる点です。
WebLogic Portal 10.0 以前は、WSRP コンシューマ アプリケーションを伝播するには、ソースおよび送り先システムのコンシューマが同じプロデューサをポイントしている必要がありました。このコンフィグレーションは WebLogic Portal 9.2 の『プロダクション業務ガイド』の「WSRP 伝播」に記載されていますが、いくつかの制限があります。
この節では、連合ポータルのアップグレード手順を説明します。ここで記載された手順は、以下のシナリオに適用されます。
ソース (ステージング) および送り先 (プロダクション) 環境のプロデューサおよびコンシューマの両方のアプリケーションを WebLogic Portal 10.0 にアップグレードすることが推奨されます。これにより、新しい伝播機能を利用して、伝播処理を簡素化できます。
ソースおよび送り先システムの各コンシューマ アプリケーションからプロデューサ登録ハンドルを取得します。これを行うには、「プロデューサ ハンドルのリスト」で説明しているプロデューサ リスト JSP ユーティリティを実行します。
プロデューサ登録ハンドルを更新します。これを行うには、「プロデューサ登録ハンドルの更新」で説明している登録ハンドル更新 JSP ユーティリティを実行します。
| ヒント : | 伝播時は、ポータル フレームワークのリソースのみを含めるようにスコープを調整できます。 |
これでアップグレード処理は完了です。これにより、ステージングおよびプロダクション環境のコンシューマ アプリケーションが個別のプロデューサをポイントできるようになります。
| 注意 : | ステージングとプロダクションのコンシューマが同一のプロデューサをポイントするコンフィグレーションを保持する必要がある場合は、そうすることも可能です。ただし、WebLogic Portal 9.2 の『プロダクション業務ガイド』の「WSRP 伝播」に記載された制限は適用されなくなります。 |
ポータルの伝播の詳細については、『プロダクション業務ガイド』を参照してください。
ドメインとプロデューサ アプリケーションをアップグレードし、コンシューマをアップグレードしない場合は、この節のアップグレード手順を実行する必要があります。この節の手順は、コンシューマ アプリケーションが現在 WebLogic Portal 8.1.x または 9.2 であっても同様に適用されます。
| 注意 : | プロデューサのみをアップグレードする場合は、WebLogic 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 の実行には管理者権限が必要です。 |
| 注意 : | コンシューマ アプリケーションが WebLogic Portal 9.2 環境にデプロイされている場合は、以下の手順 1 と 2 を実行する必要があります。コンシューマ環境がすでに WebLogic Portal 10.0 にアップグレードされている場合は、手順 1 と 2 は必要ありません。 |
listProducers.jsp ファイルを展開します。WinZip などのアーカイブ ツールを使用して、listProducers.jsp ファイルをアーカイブから展開できます。
WEBLOGIC_HOME/portal/lib/modules/wlp-propagation-web-lib.war
listProducers.jsp ファイルを、コンシューマがデプロイされている Web アプリケーションにコピーします。これを、ステージングとプロダクションの両方のシステムで行います。
http://host:port/EarProjectNamePropagation/wsrp/listProducers.jsp
EarProjectName はサーバにデプロイされたエンタープライズ アプリケーションの名前です。次に例を示します。
http://localhost:7001/myEarPropagation/wsrp/listProducers.jsp
| 注意 : | この節で説明するユーティリティを実行する必要があるのは、プロデューサ アプリケーションがデプロイされたシステム上のみです。 |
この節では、ステージングおよびプロダクションの両方のシステムで登録更新 JSP ユーティリティ (updateRegistrations.jsp) を実行する方法について説明します。このユーティリティは、指定のプロデューサを現在参照している各コンシューマ アプリケーションの登録ハンドルを更新します。
| 注意 : | プロデューサ アプリケーションが WebLogic Portal 9.2 環境にデプロイされている場合は、以下の手順 1 と 2 を実行する必要があります。プロデューサ環境がすでに WebLogic Portal 10.0 にアップグレードされている場合は、手順 1 と 2 は必要ありません。 |
updateRegistrations.jsp ファイルを展開します。WinZip などのアーカイブ ツールを使用して、updateRegistrations.jsp ファイルをアーカイブから展開できます。
WEBLOGIC_HOME/portal/lib/modules/wlp-propagation-web-lib.war
updateRegistrations.jsp ファイルを、プロデューサがデプロイされている Web アプリケーションにコピーします。これを、ステージングとプロダクションの両方のシステムで行います。
http://host:port/EarProjectNamePropagation/wsrp/updateRegistrations.jsp
EarProjectName はサーバにデプロイされたエンタープライズ アプリケーションの名前です。次に例を示します。
http://localhost:7001/myEarPropagation/wsrp/updateRegistrations.jsp
| 注意 : | 登録更新 JSP は、送り先登録ハンドルに関連するすべてのポートレットをコピーし、ソース登録ハンドルにコピーを渡します。 |
WebLogic Portal 8.1 から 10.0 に統合ユーザ プロファイル (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.0 へのアップグレード後は、<auth:login> および <auth:logout> JSP タグを使用する必要があります。属性とパラメータは同じです。
Autonomy 検索を使用していて、WebLogic Portal 8.1 からアップグレードする場合は、次の手順を実行して WebLogic Portal 10.0 に含まれている新バージョンの Autonomy にアップグレードする必要があります。アップグレード プロセスでは、既存の検索設定とデータベースは新しい検索機能に自動的には移行されません。アップグレードしたアプリケーションで Autonomy 検索を操作するには、手動でコンフィグレーションする必要があります。
新しいバージョンの Autonomy は、portal/thirdparty/autonomy-wlp100 ディレクトリにインストールされます。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 を weblogic_home/portal/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.0 形式にアップグレードするには、次の作業を行います。
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.0 では 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 でデータベースのポートレットの状態を永続化するには、netuix-config.xml ファイルの control-state-location 要素にある persistence-enabled 属性を使用します。
persistence-enabled 属性の例を次に示します。
<session persistence-enabled="true"/>
persistence-enabled 属性を true に設定すると、ユーザがログインしたときにコントロール ツリーの状態がデータベースからロードされ、ユーザがログアウトしたときに新しい状態が保存されます。コントロール ツリーの状態は、ユーザがポータルと対話したときに消去されます。
実装されているデフォルトかつ唯一の永続性タイプは JDBC です。デフォルトの実装では、ユーザの ProfileWrapper の BEA_PORTAL_FRAMEWORK_CONTROL_TREE_STATE プロパティ セットを使用します。ProfileWrapper はユーザの HTTP セッションで作成され、保存されている必要があります。ProfileWrapper は、web.xml ファイルでコンフィグレーションされる PortalServletFilter によって作成されます。ProfileWrapper がユーザのセッションに見つからないと、コントロール ツリーの状態は永続化されません。
| 注意 : | ページ フローと struts に関連する状態は、コントロール ツリーの状態の一部ではないため、永続化されません。ページ フローのポートレットと struts のポートレットは、ユーザがログアウトしたときと同じ状態ではない可能性があります。 |
子要素の reader-class-name はこの state-location のリーダー クラス名を、writer-class-name はライター クラス名を指定します。リーダーまたはライターの動作をカスタマイズするには、ControlStateReader インタフェースまたは ControlStateWriter インタフェースを実装し、netuix-config.xml ファイルでインタフェースをコンフィグレーションします。
WebLogic Portal 10.0 を使用して開発されたプロデューサ アプリケーションとコンシューマ アプリケーションは、WebLogic Portal 8.1 を使用して開発されたプロデューサおよびコンシューマと互換性があります。つまり、WebLogic Portal 10.0 を使用して開発したポータルは、WebLogic Portal 8.1 ドメインにデプロイされたポートレットを使用できます。同じように、WebLogic Portal 10.0 プロデューサでエクスポーズしたポートレットは、8.1 コンシューマによって使用できます。
ただし、8.1 コンシューマまたは 9.2 コンシューマに対して独自のキーを使用する場合は、『連合ポータル ガイド』の「SAML による WSRP セキュリティの確立」の手順に従う必要があります。
この節では、HTTP 応答のエンコーディング設定の変更について説明します。
WebLogic Portal 8.1 では、次のエンコーディング設定方法が使用されていました。
WebLogic Portal 10.0 では、次のエンコーディング設定方法が使用されています。
古い方法も引き続き使用できますが、非推奨の警告を発生させないように、新しい方法を使用することをお勧めします。次に例を示します。
.portalファイルの<netuix:desktop ... encoding="UTF-8" />
netuix-config.xmlファイルの<defaultEncoding encoding="UTF-8" />
.portal ファイルを編集中にポータル ビューまたはアウトライン ビューからデスクトップ要素を選択すると、ワークベンチではプロパティ ビューに新しい encoding プロパティが表示されるようになりました。新しいポータルのデフォルト値は UTF-8 です。値を編集するには、編集可能なドロップダウン メニューを使用します。
最初は、ドロップダウン メニューにはすべての基本的な IANA エンコーディング値に加えて中国語、韓国語、および日本語用の拡張エンコーディングのリストが表示されます。リストに表示される値は説明用の表示名であり、.portal ファイルに保存されるときに実際の IANA 名に変換されます。
ドロップダウン メニューに該当する値が表示されない場合は、入力できます。〔Enter〕を押すと、バリデータはエンコーディングが有効かつサポートされていることを検証します。入力値は、拡張エンコーディング セットから入力することも、エンコーディング用の IANA 名、エリアス、または標準名にすることもできます。エンコーディングの検証に失敗すると、警告メッセージ「you can choose to override the validation and accept the value anyway.」が表示されます。値は、デスクトップ encoding 属性に対して .portal ファイルにそのまま保存されます。
8.1 および以前のリリースとの互換性のため、および接続解除された少数のデスクトップを使用可能にするために、WebLogic Portal 10.0 は新しいブール プロパティを備えています(非推奨)。これは、StandalonePortletURL および関連付けられた JSP タグ用の desktopStateShared と呼ばれています。このプロパティを使用すると、以前の「接続解除されたデスクトップ」の動作を残すことができます。このプロパティと属性のデフォルト値は true になり、その場合はポートレットがデスクトップに接続します。
URL またはタグの path プロパティまたは contextualPath プロパティを明示的に設定すると、接続元デスクトップからスタンドアロン ポートレットへの関連付けも解除されます。また、スタンドアロン ポートレットのコンテキスト内で生成されたすべての URL に対して true が保持されます。path または contextualPath の設定によって、URL と接続元デスクトップとの接続が解除されます。
8.1 および以前のリリースの WebLogic Portal では、(非推奨でしたが) 同じ名前、階層の同じレベルで複数のポートレット カテゴリ名を作成することができました。バージョン 10.0 では、この操作は許可されません (複数のカテゴリに対して同じ名前を使用できますが、階層内で「ピア」にすることはできません)。
ポータル アプリケーションを 10.0 にアップグレードすると、以前使用していた重複するポートレット カテゴリ名は保持されます。カテゴリ名を編集してユニークにしてください。ユニークにしないと、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.0 へのアップグレード前または後にそのファイルを削除することをお勧めします。
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.0 にアップグレードする際の変更について説明します。手動でタスクを実行しなければならない場合があります。
9.2 から 10.0 への連合ポータルのアップグレード手順は、8.1 から 10.0 への場合の手順と同じです。詳細な手順については、「8.1 から 10.0 への連合ポータルのアップグレード」を参照してください。
WebLogic Portal 9.2 または 9.2 MP1 の UUP は WebLogic Portal 10.0 で自動的に動作します。9.2 UUP をアップグレードする必要はありません。
WebLogic Portal 8.1 および以前のリリースとの下位互換性のため、および接続解除された少数のデスクトップを使用可能にするために、WebLogic Portal 9.2 は新しいブール プロパティを備えています(非推奨)。これは、StandalonePortletURL および関連付けられた JSP タグ用の desktopStateShared と呼ばれています。
| 注意 : | このプロパティは 10.0 でも保持されていますが、引き続き非推奨です。 |
このプロパティを使用すると、以前の「接続解除されたデスクトップ」の動作を残すことができます。このプロパティと属性のデフォルト値は true になり、その場合はポートレットがデスクトップに接続します。URL またはタグの path プロパティまたは contextualPath プロパティを明示的に設定すると、接続元デスクトップからスタンドアロン ポートレットへの関連付けも解除されます。また、スタンドアロン ポートレットのコンテキスト内で生成されたすべての URL に対して true が保持されます。path または contextualPath の設定によって、URL と接続元デスクトップとの接続が解除されます。
検索サービスをアップグレードすると、Autonomy コンフィグレーション ファイルが更新され、コンテンツのインデックスが再作成されます。
オプションで、10.0 Autonomy インストール ディレクトリを使用するように既存の Autonomy インストールを移行することを選択できます。WebLogic Portal 10.0 には WebLogic Portal 9.2 と同じバージョンの Autonomy が付属していますが、インストール ディレクトリが変更されています。新しいディレクトリは以下になります。
\\WebLogic_HOME\cm\thirdparty\autonomy-wlp10
プロダクション環境の場合、BEA は 9.2 インストール ディレクトリを引き続き使用することを推奨します (\\WebLogic_HOME\portal\thirdparty\autonomy-wlp92)。
開発環境の場合、BEA は以前のインストール ディレクトリを使用せず、新しいインストール ディレクトリを使用することを推奨します。
| 注意 : | プロダクション環境では BEA コンテンツのインデックスを再作成する必要があります。詳細については、『検索の統合ガイド』を参照してください。 |
新しい場所を使用するために、必要なすべての Autonomy コンフィグレーション ファイルを更新します。Autonomy コンフィグレーション ファイルの詳細については、『検索の統合』の「対象サーバでの Autonomy のコンフィグレーション」を参照してください。
検索クエリで引き続き二重引用符をサポートするには、BEACMRepoFetch.cfg ファイルに以下の変更を加える必要があります。
二重引用符 (たとえば、"引用符" など) をサポートするには :
1. Autonomy ホストで、以下のファイルを編集します。
//autonomyhome/operatingsystem/internal/BEACMRepoFetch/BEACMRepoFetch.cfg
//WebLogic_Home/portal/thirdparty/autonomy/linux-intel/internal/BEACMRepoFetch/BEACMRepoFetch.cfg
2. [BEACMRepoIDXImport] セクションで、以下の行を追加します。
ImportBifIncludeQuotes=true
クエリの日本語文字を引き続きサポートするには、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
オプションで、ご使用の 9.2 Autonomy コンフィグレーションを 10.0 インストールに移行できます。
| 注意 : | アップグレードしたプロダクション環境の場合、BEA は引き続き既存の 9.2 Autonomy の場所を使用することを推奨します。 |
9.2 Autonomy コンフィグレーションとデータを新しい 10.0 の場所に移行するには :
IDOL サーバで、以下のフォルダを 9.2 の場所から 10.0 の場所にコピーします。
\\wlp-92\IDOLserver\IDOL\content\ フォルダにある以下のサブフォルダを、\\wlp-10\IDOLserver\IDOL\content\ の新しいコンテンツ フォルダの場所にコピーします。\\wlp-92\IDOLserver\IDOL\indextasks\ フォルダにある以下のサブフォルダを、新しい \\wlp-10\IDOLserver\IDOL\indextasks\ フォルダにコピーします。\\wlp-92\IDOLserver\IDOL\agentstore\ フォルダにある以下のサブフォルダを、新しい \\wlp-10\IDOLserver\IDOL\agentstore\ フォルダにコピーします。\\wlp-92\IDOLserver\IDOL\category\ フォルダにある以下のサブフォルダを、新しい \\wlp-10\IDOLserver\IDOL\category\ フォルダにコピーします。
9.2 IDOL サーバからすべてのインデックス付きデータをエクスポートし、10.0 の場所に再インポートする必要があります。
インデックス付きコンテンツをエクスポートするには、ブラウザから以下のコマンドを使用します。ご使用の Autonomy コンフィグレーションの適切なホスト名およびポートを使用します。また、コンテンツのインデックス作成のファイル名をディレクトリを含めて指定する必要があります。
http://host:port/DREEXPORTIDX?FileName<filename>&Compress<true\false>
9.2 の場所からインデックス付きデータをインポートした後、以下のコマンドを使用して、コンテンツを新しい WebLogic Portal 10.0 の場所にインポートします。ご使用の Autonomy コンフィグレーションの適切なホスト名およびポートを使用し、データのエクスポート時に作成されたファイルを使用します。
http://host:port/DREADD?<filename>
上の手順が完了したら、BEA コンテンツのインデックスを再作成する必要があります。BEA コンテンツのインデックス再作成の詳細については、『検索の統合ガイド』を参照してください。
WebLogic Portal 10.0 を使用して開発されたプロデューサ アプリケーションとコンシューマ アプリケーションは、WebLogic Portal 9.2 を使用して開発されたプロデューサおよびコンシューマと互換性があります。つまり、WebLogic Portal 10.0 を使用して開発したポータルは、WebLogic Portal 9.2 ドメインにデプロイされたポートレットを使用できます。同じように、WebLogic Portal 10.0 プロデューサでエクスポーズしたポートレットは、9.2 コンシューマによって使用できます。
ただし、9.2 コンシューマまたは 10.0 コンシューマに対して独自のキーを使用する場合は、『連合ポータル ガイド』の「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.0 伝播ツールでは使用できません。
  
|
