| Oracle® Fusion Middleware Oracle Portal管理者ガイド 11g リリース1(11.1.1) B61385-02 |
|
 前 |
 次 |
この章では、PL/SQL HTTPアダプタとして知られている連携型Portalアダプタについて説明します。このアダプタを使用して他のOracle Portalインスタンスとポートレットを共有する方法についても説明しています。
この章の内容:
この項の内容:
連携型Portalアダプタは、Oracle Portalのコンポーネントの1つであり、これを使用して、複数のOracle PortalインスタンスがWebポートレット・インタフェースを介して互いのデータベース・ポートレットを共有できるようにします。これは、SOAPおよびHTTPを使用してデータベース・プロバイダを複数のデータベース・サーバーに分散するツールです。連携型Portalアダプタを使用すると、Webプロバイダと同様の扱いでデータベース・プロバイダにアクセスできます。
以前のリリースのOracle Portalでは、ポータル・インスタンスからアクセスされるすべてのデータベース・プロバイダは、ポータル・インスタンスを格納する同じ物理データベース・サーバー上に存在する必要がありました。
Oracle Portalリリース3.0.9で、データベース・ポートレットを複数のデータベース・サーバーに分散できるようになりました。これを実現するには、ユーザーは各ポータル・ノードを相互に登録して、ノード間のデータベース・リンクを作成する必要がありました。これらのポータル・ノードはファイアウォールを越えて機能しませんでした。さらに、ポータル・ノードの登録は対称型で、複数ノードの登録の管理が困難でした。
Oracle Portalには、Webプロバイダの概念が取り込まれています。つまり、ポータルとプロバイダ間の通信は、オープン・プロトコルHTTPとSOAPを使用して行われます。PDK-Javaサービスにより、ユーザーは、SOAPメッセージを受信してそれに応答するプロバイダをJavaで簡単に開発できます。
連携型Portalアダプタは、ポータル・インスタンスに(JavaとPL/SQLの両方で)書き込まれるモジュールで、WebプロバイダのSOAPメッセージを受信し、SOAPを解析して、メッセージをPL/SQLプロシージャ・コールとしてデータベース・プロバイダに送信します。つまり、連携型Portalアダプタによってデータベース・プロバイダはWebプロバイダとまったく同じように機能します。これにより、ユーザーはデータベース・プロバイダを複数のデータベース・サーバーに分散できます。すべてのリモート・プロバイダは、Webプロバイダとして利用できます。ユーザーはリモート・プロバイダの実装を意識する必要がなく、分散型ポータル・インストールを効果的に置き換えることができます。
データベース・プロバイダとWebプロバイダの大きな違いは、標準的なデータベース・プロバイダでは、コード内のポータル・セッションを使用し、ポータル・セッションが連携型Portalアダプタの一部としてリモート・ポータル・インスタンス上に作成されることです。SOAPメッセージは、リモート・ポータル・インスタンス上にセッションを作成するために必要な情報を格納できるように拡張されます。つまり、リモート・ポータルのユーザーは、ローカル・ポータルと同じユーザーである必要があります。たとえば、ユーザーAがPortal Aで実行中で、連携型Portalアダプタを介してPortal Bのプロバイダを使用している場合は、ユーザーAのセッションがPortal Bに作成されます。通常、これはPortal AとPortal Bがパートナ・アプリケーションと同じOracle Application Server Single Sign-Onを共有することを意味します。ただし、別個のOracleAS Single Sign-Onを使用して、各OracleAS Single Sign-Onが同じネーム・サーバーを共有することもできます。たとえば、2つのOracleAS Single Sign-Onが同じOracle Internet Directoryインスタンスを共有します。
連携型Portalアダプタの使用は、次の3つのカテゴリに分類できます。
表12-1 連携型Portalアダプタの使用
| カテゴリ | 説明 |
|---|---|
|
Oracle Portalデータベース・プロバイダ |
Oracle Portal内に作成されるPortal DBプロバイダには、連携型Portalアダプタの使用に必要なコードが含まれます。つまり、フォーム、チャート、レポートなどを含むアプリケーションを他のポータル・インスタンスで表示できます。 |
|
ページ |
ポートレットとして公開されるページは、連携型Portalアダプタを通じて実行することもできます。ページ内のリージョンには、ポートレットまたはアイテムを含めることができます。連携型Portalアダプタを使用すると、どのポータル・インスタンスからでもこれらのページにアクセスできます。 |
|
ユーザーが作成したプロバイダ |
ユーザーが独自のPL/SQLプロバイダを作成する必要がある場合があります。この章で説明するガイドラインに従ってコード化されている場合は、連携型Portalアダプタを使用してこれらのプロバイダを公開できます。 |
連携型Portalアダプタは、initSession SOAPメッセージに渡された情報に基づいて、リモート・ポータルにポータル・セッションを作成します。これにより、セキュリティの問題が生じます。これらのSOAPメッセージをレプリケートし、ポータル上の任意のユーザーに対してセッションを作成すれば、そのユーザーとしてポータルにアクセスできるためです。この問題を回避するため、2つのポータルで暗号鍵が共有され、SOAPメッセージの一部はその鍵を使用して暗号化されます。リクエストされたプライベート・ポータル・セッションは、すでに共有されている鍵で復号化できる場合にのみ作成されます。それ以外の場合は、PUBLICセッションが作成されます。ポートレットの表示リクエストは、Showメッセージによって行われます。このメッセージは、initSession SOAPメッセージによって作成される暗号化Cookieによって保護されます。暗号鍵を使用することにより、連携型Portalアダプタは安全に着信SOAPメッセージを信頼でき、ポータルがハッカーに公開されることなくポータル・インスタンスにポータル・セッションを作成できます。
他のポータル・インスタンスからそのポータル・インスタンスへのアクセスが、連携型Portalアダプタを介したアクセスのみであることがわかっている場合は、既知のポータル・インスタンス以外のコンピュータからのアクセスを制限するようにリスナーを構成することにより、セキュリティを強化することができます。これは、httpd.confファイルのAllowディレクティブを使用して設定します。
Oracle Fusion Middleware 10g(10.1.4)より前のリリースで作成したデータベース・プロバイダは、次の条件に該当する場合には連携型Portalアダプタを使用してアクセスしても機能しません。
ポートレットに相対リンクが含まれている場合
ポートレットがパーソナライズ可能な場合
連携型Portalアダプタを使用する場合は、ポートレット内のすべてのリンクが絶対リンクである必要があります(つまり、/images/foo.gifのような相対リンクではなく、http://<host>:<port>/images/foo.gif)。これは、ローカル・ポータル・インスタンス上のParallel Page Engineによってリクエストが処理されるためです。したがって、相対リンクはポートレットを含むポータルではなく、ローカル・ポータルを基準にして解釈されます。
パーソナライズの処理はデータベース・プロバイダとWebプロバイダで異なるため、パーソナライズは問題の原因となります。Webプロバイダの場合、パーソナライズ・フォームはローカル・ポータルのParallel Page Engineに送信されます。Parallel Page Engineがポートレットを次にコールしたときに、パーソナライズが保存され、ページが適切にリダイレクトされます。連携型Portalアダプタを介してアクセスされるデータベース・プロバイダはWebプロバイダでもあるため、Webプロバイダのパーソナライズ方式に対応する必要があります。これを実現するために、パブリックAPI(WWPRO_API_ADAPTER)が提供されています。
以前のリリースのOracle Portalで開発したPortalデータベースのポートレット・プロバイダは、連携型Portalアダプタで機能するように自動的にアップグレードされます。プロバイダとして公開されるページは、連携型Portalアダプタを通じてアクセスすることもできます。
連携型Portalアダプタを使用するには、管理手順をいくつか実行する必要があります。これらの手順は、次のとおりです。
DADには、連携型Portalアダプタがアクセスするすべてのポータルに対する一意のPlsqlSessionCookieName値が必要です。
たとえば、次のようになります。
portal1には、スキーマ名portal、DAD名portalおよびPlsqlSessionCookieName値portal1を指定できます。
portal2には、スキーマ名 portal、DAD名portalを指定できますが、PlsqlSessionCookieName値にはportal2などの異なる値を指定する必要があります。
|
注意: Oracle Portalの以前のリリースでは、DAD名はスキーマ名と同じである必要があり、DAD名は常に作成されたセッションCookieの名前と同じでした。このリリースでは状況が変わりました。現在では、ポータルがDADによってアクセスされるときに作成されるCookieの名前を指定することが可能になり、スキーマ名をDAD名と同じにする必要がなくなりました。 |
Oracle Enterprise Manager 11g Fusion Middleware Controlを使用して、セッションCookie名を更新できます。これを行うには、次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware Controlで、Portalホーム・ページに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。
「ポータル」メニューから、「設定」→「データベース・アクセス記述子」を選択します。
「データベース・アクセス記述子の構成」ページが表示されます。
既存のDADを編集するには、DAD名を選択して「編集」をクリックします。
「データベース・アクセス記述子の編集」ページが表示されます。
「データベース・アクセス記述子の編集」ページの「セキュリティ、文書、別名とセッション」セクションで「セッションCookie名」に新しい値を入力します。
「OK」をクリックします。
管理対象サーバー(WLS_PORTAL)を再起動します。
連携型Portalアダプタ機能は、分散したポータルのリモート・データベース・プロバイダの登録をサポートします。データベース・プロバイダは、リモート・ポータルの特別なURLに常駐するWebプロバイダのように登録されます。
|
注意: リモート・ポートレットでパブリック・コンテンツをレンダリングするのみの場合は、この項を無視できます。 |
リモート・ポートレットにレンダリングできるコンテンツをパブリックなもの以外にまで広げるには、あるポータルのユーザーAが別のポータルでも同様にユーザーAであるようにする必要があります。通常は、パートナ・アプリケーション機能を使用する共有Oracle Application Server Single Sign-Onによってこれを実現できますが、共有ネーム・サーバー(Oracle Internet Directoryなど)、同期化されたネーム・サーバーまたは手動プロセスを使用して実現することも可能です。
この環境を実現できる場合は、Hash Message Authentication Code (HMAC)認証メカニズムを使用して、プライベート・セッションをリモート・ポータルで開始し、リモート・ポートレットのプライベート・コンテンツをレンダリングできます。
Portal Aの管理者がPortal BのユーザーによるPortal A上のセッションの作成を許可する場合は、秘密鍵を各ポータル上に格納する必要があります。この鍵は、Portal AとPortal B間で送信されるSOAPリクエストの一部の暗号化と復号化に使用されます。鍵が見つからない場合や各ポータルで鍵が異なる場合は、PUBLICセッションのみが作成されます。
鍵は10文字以上の長さにする必要があります。また、管理者はセキュアで適切な方法を使用して、他の管理者に鍵の値を通知する必要があります。
キー・ストアの管理タスクを実行するために、SQLスクリプトが提供されています。これらのスクリプトはすべてORACLE_HOME\portal\admin\plsql\wwcディレクトリにあります。
| スクリプト | 説明 |
|---|---|
|
|
送信の終了時にキーを設定します(リモート・ポートレットを含むページが作成されるポータル・インスタンス)。 |
|
|
受信の終了時にキーを設定します(ポートレットが作成されるポータル・インスタンス)。 |
|
|
送信の終了時にキーを削除します(リモート・ポートレットを含むページが作成されるポータル・インスタンス)。 |
|
|
受信の終了時にキーを削除します(ポートレットが作成されるポータル・インスタンス)。 |
ここでの送信および受信は、SOAPメッセージの送信および受信のことです。
例12-1 HMACキーの設定:
前述の例では、Portal BがSOAPリクエストおよび表示リクエストの送信者、Portal Aがそれらのリクエストの受信者です。Portal Bのポータル管理者はSQL*Plusにポータル所有者として接続し、次のコマンドを実行する必要があります。
SQL> @proadsss Enter provider portal PL/SQL Adapter URL: http://<portalA_hostname>:<port>/adapter/<portalA_DAD> Enter shared key:<shared key> exit;
Portal Aのポータル管理者はSQL*Plusにポータル所有者として接続し、次のコマンドを実行する必要があります。
SQL> @proadssr Enter provider portal PL/SQL Adapter URL: http://<portalB_hostname>:<port>/adapter/<portalB_DAD> Enter shared key:<shared key> exit;
双方向のプロバイダ共有が必要な場合は、別の共有キーを使用して、前述と逆の手順を実行する必要があります。また、ポータルはそのプロバイダを他のポータル・インスタンスに公開でき(たとえば、Portal AがPortal BとPortal Cにプロバイダを公開する)、ポータル・インスタンスごとに異なるキーを設定できます。
通常、Cookieドメインは1台のコンピュータに制限されます。各ポータルでスクリプトを実行して、プロバイダの登録ページで「Portalと同じCookieドメインのWebプロバイダ」オプションを選択することにより、この範囲を拡張できます。これを実行すると、深いリンク機能を実現できます。つまり、連携型Portalアダプタによってレンダリングされたポートレット内のリンクをクリックすると、参照先(通常はリモート・ポータル)のページがブラウザにレンダリングされます。すでに確立されているセッション・コンテキストも維持されます。
ブラウザまたは他のHTTPクライアントが受け取ったCookieは、Cookieのドメインがサーバーのホスト名と一致する場合はサーバーに送信されます。このため、ドメインが.co.ukおよびmycompany.co.ukのCookieは、リクエストと一緒にhttp://mycompany.co.uk/portal/pls/etc/etcに送信されます。デフォルトでは、ポータルによって作成されるCookieの範囲は、中間層コンピュータのホスト名に制限されます。
ポートレットとの通信は、ブラウザではなくParallel Page Engine(PPE)によって中間層で行われます。このため、ポートレット内にリンクがある場合、リモート・ポータルのセッションCookieは、デフォルトではリモート・ポータルに送信されません。
この問題は、ポータルによって作成されたCookieの範囲を拡張し、PPEが受信したCookieがブラウザに必ず返送されるようにすることで解決できます。ポータルによって作成されたCookieの範囲を拡張するには、ORACLE_HOME\portal\admin\plsql\wwcディレクトリにあるSQLスクリプトctxckupd.sqlを実行します。
たとえば、次の2つのポータルがあります。
http://myhost1.mycompany.co.uk:3000/portal/pls/portalA
http://myhost2.mycompany.co.uk:4000/portal/pls/portalB
プロバイダは、Portal BからPortal Aに登録されます。
Portal Bのポートレットを含むページをPortal Aに表示すると、デフォルトでは、myhost2.mycompany.co.uk:4000をドメインとするPortal Bのポータル・セッションCookieが作成され、PPEに送信されます。プロバイダの登録ページで「ポータルと同じCookieドメインのWebプロバイダ」プロパティを選択しておくと、このCookieがブラウザに返送されますが、そのドメインはmyhost1.mycompany.co.uk:3000になります。これは、このドメインは送信元を示すものであり、送信元であるPPEがmyhost1.mycompany.co.uk:3000に存在するためです。
ポートレット内にリンクがある場合は、Cookieのドメインがリクエストのホストのドメインと一致しないため、Cookieはリクエストと一緒に送信されません。
この問題を解決するには、各ポータルのポータル所有者としてSQL*Plusに接続し、ORACLE_HOME\portal\admin\plsql\wwcを実行して、各ポータルが同じドメインになるように、Oracle Portalによって作成されるドメインのCookieの範囲を拡張します。これを実行すると、ポータルによって作成されるCookieドメインの範囲はブラウザに返信できるようにすべて拡張されます。これで、ポートレット内のリンクは正常に機能します。
|
注意: 中間層サーバーのホスト・ドメイン名にピリオド(「.」)が1つのみ含まれている場合、それはOracleのテスト済構成ではありません。予期しない結果を避けるため、中間層サーバーには複数の部分で構成されるドメイン名を指定してください。これにより、中間層のホスト・ドメイン名に複数のピリオドが含まれるようになります。 |
共通のID管理サーバーを利用すると、シングル・サインオンを最大限に活用できます。ポータル・セッション情報はリモート・ポータルに渡され、そこで連携型Portalアダプタを使用してセッションが作成されます。プライベート・セッションの作成対象とするすべてのポータルで、同じOracle Internet Directoryサーバーおよび同じOracleAS Single Sign-Onを共有することをお薦めします。
たとえば、ユーザーJSMITHがあるポータルでページを表示し、そのページのポートレットがリモート・ポータルの連携型Portalアダプタから提供されている場合、JSMITHに対するセッションはリモート・ポータルに作成されます。これら2つのポータルがOracleAS Single Sign-Onを共有しない場合、JSMITHは、一方のポータルではJohn Smithのユーザー名であり、もう一方のポータルではJane Smithのユーザー名になります。このような問題を回避するには、連携型Portalに参加するすべてのポータルが単一のOracle Identity Managementを使用するように構成します。これらすべてのポータルでは、認証に同じOracleAS Single Sign-Onを使用する必要があります。ただし、表示中のポートレットがパブリックの場合は、OracleAS Single Sign-Onを共有する必要はありません。パブリック・ポータル・セッションがリモート・ポータル・インスタンスに作成されます。
それぞれ別々のOracleAS Single Sign-On Serverを使用する2つのポータルがある場合は、先にそれらのOracleAS Single Sign-On Serverを統合する必要があります。これを行うには、『Oracle Application Server Single Sign-On管理者ガイド』の複数サーバーの統合に関する項を参照してください。
サーバーの統合とは、1つのサーバーの使用を停止し、もう1つのサーバーを両方のポータルが使用する共通のサーバーにすることを意味します。次に、使用停止としたOracleAS Single Sign-Onを使用するように構成していたポータルを、統合したサーバーを使用するように構成する必要があります。これを行うには、次の手順を実行します。
OracleAS Single Sign-OnおよびOracle Internet Directoryサーバーの共有
portal1とportal2の2つのポータルがあるとします。ここで、portal2のSSOサーバーの使用を停止し、portal1のSSOサーバーを使用するようにportal2を構成します。これを行うには、次の手順を実行します。
次の手順を実行して、portal1の同じOIDComponentを指すようにportal2のOIDDependency要素を変更します。
Oracle Enterprise Manager 11gでPortalホーム・ページに移動します。
「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。
「Oracle Internet Directory (OID)」セクションでportal1のOIDの詳細を入力します。
次の例に示すように、Identity ManagementインスタンスからORACLE_HOME/sso/bin(Unix)にあるssoreg.shを起動して、portal2のOracle HTTP Serverを再登録します。
$ORACLE_HOME/sso/bin/ssoreg.sh -site_name portal2.example.com:8090 -config_mod_osso TRUE -mod_osso_url http://portal2.example.com:8090 -update_mode MODIFY -remote_midtier -config_file config_file_path
Windowsでは、かわりにssoreg.batを実行する必要があります。
Portalスキーマにログインしてportal2のPortal Metadata Repositoryを更新し、WWSEC_PERSON$表のGUID列を更新してプレースホルダGUIDを設定します。これにより、新しく関連付けたOIDサーバーから新しいGUIDを取得できます。
SQL> update wwsec_person$ set guid = ':'||id; SQL> commit;
連携型Portalアダプタを使用したプロバイダの登録は、Webプロバイダの登録と似ています。次の手順を実行する必要があります。
Oracle Portalにログインします。
「Portalビルダー」ページが表示されます。
「管理」タブをクリックして「ポートレット」サブタブをクリックします。
「リモート・プロバイダ」ポートレットの「プロバイダの登録」をクリックします。
「プロバイダ情報」ページで、「名前」、「表示名」、「タイムアウト」および「タイムアウト・メッセージ」を通常どおり入力します。「実装スタイル」が「Web」に設定されていることを確認します。プロバイダは実際にはPL/SQLで記述されていますが、プロバイダとのすべての通信はデータベース・プロバイダではなく、Webプロバイダとして行われます。このため、「実装スタイル」を「Web」設定する必要があります。
「一般プロパティ」ページで、アダプタ・サービスのURLを入力します。URLの構文は、次の形式で入力する必要があります。
http://host:port/adapter/dad/schema
DADとスキーマが同じ場合は、次の形式も使用できます。
http://host:port/adapter/dad
host、port、DADおよびschemaはリモート・ポータル・インスタンスの場所を示します。URLをブラウザに貼り付けることにより、URLが正しいかどうかを確認できます。
URLが正しい場合は、アダプタ・テスト・ページに接続できたというメッセージが記載されたページに移動します。
「Portalと同じCookieドメインのWebプロバイダ」オプションを選択します。これにより、プロバイダから生成されるCookieがブラウザに返信されるようになります。前述のように、ポータルによって作成されるCookieの範囲を拡張しなければならない場合があります。
「サービスID」を入力します。これは、urn:<provider name>という形式で入力する必要があります。provider nameは、リモート・ポータル・インスタンス上のプロバイダの名前です。これは大文字で入力します(大文字・小文字は区別されます)。提携方Portalアダプタがリモート・ポータルの特定のプロバイダを見つけるために使用する情報です。
プロバイダとして公開されているページの場合、プロバイダの名前はMYPAGE970D272EBE9D2D0FE034080020F7DA4Bのようになります。「表示名」ではなく、この「名前」を指定してください。名前と表示名は、Oracle Portalの「管理」タブにある「ポートレット」サブタブの「リモート・プロバイダ」ポートレットで確認できます。「プロバイダをブラウズ」アイコンをクリックすると、すべてのプロバイダの名前が表示されます。
「ユーザー/セッション情報」セクションで、「ユーザー」ラジオ・ボタンを選択し、「ログイン頻度」を「ユーザー・セッションごとに1回」に設定します。これらの設定により、リモート・ポータル・インスタンス上にポータル・セッションを作成できるように、リクエストと一緒に情報が送信されます。
|
注意: 新規プロバイダを作成または登録すると、「ポートレット・ステージング領域」の「ポートレット・リポジトリ」に、そのプロバイダのポートレットを表示するためのページが作成されます。このページは、プロバイダを公開したユーザーおよびポータル管理者のみが表示できます。プロバイダを公開したユーザーまたはポータル管理者は、必要に応じて適切なユーザーやグループに権限を付与するように、プロバイダ・ページのプロパティを変更できます。 |
連携型Portalアダプタを通じてアクセスされるデータベース・プロバイダを記述する場合は、次の2つのコードについて特別な注意が必要です。
連携型Portalアダプタを通じてアクセスされるポートレット内のすべてのリンクには、相対リンクではなく、絶対リンクを使用する必要があります。相対リンクは、リモート中間層ではなく、ローカル中間層を基準にするため、機能しません。たとえば、/etc/etcではなく、http://myhost.mycompany/etc/etcという形式でリンクを作成する必要があります。
連携型Portalアダプタを通じてポートレットにアクセスするときのパーソナライズの適用方法は、PDK-Javaポートレットの場合と似ています。連携型Portalアダプタを通じてパーソナライズが機能するようにするには、主に次の2つの領域でポートレット・コードを変更する必要があります。
edit_defaultsモードまたはpersonalizeモード(パラメータp_modeがNULLの場合)でポートレットを表示するように、ポートレットを表示するコールにロジックを追加する必要があります。p_modeがOK、APPLYまたはRESETの場合、パーソナライズは適切なものとしてに保存されます。
パーソナライズ・ページ用として生成される<FORM> HTMLタグは、プロシージャwwpro_api_adapter.open_formを使用して作成する必要があります。これにより、フォームの正しい動作が実現し、ページの送信時に正しいパラメータが渡されるようになります。パーソナライズ・フォームの送信時に発生するイベントの順序は、次のとおりです。
ページがローカルPPEに送信されます。この送信とともに送信が必要な標準パラメータ(_providerid、_dad、p_actionなど)およびパーソナライズするパラメータがいくつかあります。プロシージャwwpro_api_adapter.open_formは、この送信の生成をできるかぎり単純にするために提供されています。
PPEはパーソナライズ・ページを再び表示します。ただし、ポートレットのshow_portletコール中に次のいずれかの設定になるように、p_actionパラメータが設定されます。
'OK: この場合、パーソナライズは保存され、ポートレットを含むページにリダイレクトされます。
'APPLY: この場合、パーソナライズは保存され、パーソナライズ・ページが表示されます。
'RESET: この場合、パラメータのデフォルト値の問合せが行われ、パーソナライズ・ページが表示されます。
データベース・サービス・プロバイダは、Oracle Fusion Middleware Portal Developer Kit(PDK)に含まれるサンプル・プロバイダであり、連携型Portalアダプタと連携して機能します。詳細は、Oracle Technology Network(OTN)(http://www.oracle.com/technology/products/ias/portal/pdk.html)にあるPortal Developer Kitを参照してください。
連携型Portalアダプタを介してページ・ポートレットを表示する際に既知の制限事項がいくつかあります。
詳細の表示モードは機能しません。つまり、ポートレットに関する詳細情報を表示するリンクとしてポートレット名を表示できません。
ページ・ポートレットに複数のタブが含まれている場合は、タブをクリックすると、深いリンクになり、描画されるページはページ全体に表示されます。つまり、元のページ内にポートレットとして表示されません。
連携型Portalアダプタを介してページを表示した場合、ページのバナーを含むナビゲーション・ページは正しく描画されません。たとえば、通常のページ・ポートレットでは「パーソナライズ」リンクによって、コンテナ・ページのパーソナライズ・オプションが表示されますが、リモートのページ・ポートレットでは表示されません。さらに、連携型Portalアダプタを介して表示されたページ・ポートレットには、コンテナ・ページのバナーが表示されませんが、通常のページ・ポートレットの場合はバナーが表示されます。
ページ・ポートレットにナビゲーション・ページ・ポートレットが含まれ、そこにサブ・ページ・リージョンが含まれている場合、連携型Portalアダプタを介して表示されたページ・ポートレットにはサブ・ページ・リージョンは表示されません。リモート以外のページ・ポートレットの場合は、そのリージョンに、ポートレットを含むコンテナ・ページのサブページが表示されます。
連携型Portalアダプタ・ポートレットをエクスポートおよびインポートする場合、ターゲット・ポータル・インスタンスで次の作業を実行していないと、ポートレットはターゲット・インスタンスに表示されません。
ソース・ポータル・インスタンスで実行されているPL/SQLアダプタを使用するようにターゲット・ポータル・インスタンスを構成します。
ソース・ポータル・インスタンスの連携型PortalアダプタのWebプロバイダ・ページで、ターゲット・ポータル・インスタンスに「表示」権限を付与します。
