| Oracle® Fusion Middleware Oracle Portal管理者ガイド 11gリリース1（11.1.1） B61385-01 |
|
 戻る |
 次へ |
この章では、拡張構成に必要な構成について説明します。次のような構成ツールを実行するには、第5.1項「Oracle Portalの管理の開始」で説明している管理ツールに精通している必要があります。
この章の内容:
Oracle Fusion Middlewareリスニング・ポート内のポートを変更する方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
Oracle Portalでは、多くの様々なコンポーネント（Parallel Page Engine、Oracle HTTP Server、Oracle Web Cacheなど）を使用しますが、それらの各コンポーネントはHTTP通信でクライアントまたはサーバーの役目を果たすことがあります。このため、Oracle Portalの中間層にある各コンポーネントを、HTTPではなくHTTPSプロトコルやSecure Sockets Layer（SSL）を使用するように個別に構成する必要があります。
Oracle Portalで使用できるSSL構成オプションは、第7章「Oracle Portalの保護」で説明されています。次の項を参照してください。
この項では、同じOracle Metadata Repositoryにアクセスするためにフロントエンドとしてロード・バランス・ルーター（LBR）が設定された複数の中間層環境で、Oracle Portalを設定する方法を説明します。
|
注意: すべてがアウト・オブ・ボックスのポータル・インストールでは、このソリューションは、SSLを使用するように構成されていないため、内部の配置に最適です。企業内の配置をセキュアに構成するための推奨方法については、Oracle Fusion Middleware Java EEエンタープライズ・デプロイメント・ガイドを参照してください。 |
LBRの目的は、クライアント層に公開アドレスを1つだけ提供し、LBRによって行われるリクエストの配信に基づいて、実際にリクエストを処理するサーバーのファームをフロントエンドに設定することです。LBRそのものは、非常に高速のネットワーク・デバイスであり、Webリクエストを膨大な数の物理サーバーに配信できます。
ここで、図6-1に示すような複数の中間層構成を構成すると想定します。この例では、Oracle Portalの中間層として、同じコンピュータ上にOracle Web Cacheが示されています。理論的には、これらは別のコンピュータ上にあってもかまいません。
表6-1 詳細情報
| コンピュータ | 詳細 |
|---|---|
|
ロード・バランス・ルーター（LBR） |
コンピュータ名: IPアドレス: リスニング・ポート: 無効化用ポート: |
|
Portal中間層1（M1） |
コンピュータ名: IPアドレス: Oracle HTTP Serverリスニング・ポート: Oracle Web Cacheリスニング・ポート: Oracle Web Cache無効化用ポート: Web Cache管理用ポート: Oracle Portal管理対象サーバー（WLS_PORTAL）: |
|
Portal中間層2（M2） |
コンピュータ名: IPアドレス: Oracle HTTP Serverリスニング・ポート: Oracle Web Cacheリスニング・ポート: Oracle Web Cache無効化用ポート: Oracle Portal管理対象サーバー（WLS_PORTAL）: |
|
注意
|
正常な処理に必要なLBRの追加構成は次のとおりです。
ループバック通信
Oracle PortalのParallel Page Engine（PPE）は、ページ・メタデータの情報を取得します。この通信は、ループバック接続と呼ばれます。デフォルトの構成では、Oracle Web CacheとOracle Portalは同じコンピュータ上にあり、ループバック接続はローカルです。
LBRが Oracle Fusion Middlewareのフロントエンドに設定されており、Oracle Web Cacheが同じサブネット上にある場合は、追加構成が必要となります。このことをよく理解するために、この追加構成がないループバック接続の様々な部分を確認します。
Oracle Portalでページが生成されると、PPEはページ・メタデータのループバック・リクエストを送信します。このループバック・リクエストは、LBRに直接送信されます。
このリクエストがLBRによってOracle Web Cacheに転送されます。
Oracle Web Cacheは、リクエストをOracle HTTP Server下で稼働中のPortalサービスに転送します。
Portalサービスがリクエストを処理し、ループバック・リクエストのレスポンスをOracle Web Cacheに返信します。
Oracle Web Cacheは、リクエストをLBRに転送します。
LBRがレスポンスを受信します。このレスポンスは通常PPEに送り返されます。
LBRは、レスポンスを返信する必要があるソース・アドレスが同じサブネット上にあることを検出し、PPEのソケット接続ではなくLBRに既知のソケット接続を使用して、レスポンスをOracle Web Cacheに返信します。
Oracle Web Cacheはリクエストをまったくリスニングしておらず、有効なセッションがないため着信リプライは削除されます。
Oracle Portalページは、「ページ・メタ・データの取り出し中にタイムアウトになりました。」というエラーでタイムアウトします。
通常の場合、LBRはすべてのリクエストをOracle Web Cacheに転送するようにプログラミングされているため、その動作に問題はありません。ただし、ループバック・リクエストが内部ネットワークから流入する場合、好ましくない結果が発生します。
このような問題を回避するには、LBR上でNetwork Address Translation（NAT）のバウンス・バック・ルールを設定する必要があります。このルールによって、ファイアウォールの内側から流入するリクエストのプロキシとして、LBRが構成されます。この設定で内部リクエストが正しく転送されることが確認されます。また、レスポンスがLBRに到達したときに、レスポンスは正しく変換され、ネットワーク上の正しいソース・アドレス（この場合、PPE）に送信されます。
この設定に必要な手順については、後で説明します。NATバウンス・バックは、個々のLBRで様々に設定されます。詳細は、LBRの構成ガイドを参照してください。
|
関連項目 Oracle Fusion Middleware Java EEエンタープライズ・デプロイメント・ガイド |
Oracle Web Cacheの無効化
Oracle Web Cacheを利用して、Oracle Portalがそのコンテンツの多くをキャッシュすることができます。Oracle Web Cache内でキャッシュされたコンテンツが変更されると、Oracle Portalによって、無効化メッセージがデータベースからOracle Web Cacheへ送信されます。Oracle Portalでは、Oracle Web Cacheクラスタ内の1つのWeb Cacheノードにのみ、無効化メッセージを送信できます。Oracle Portalは、そのOracle Web Cacheメンバーに依存して、クラスタの他のメンバーのコンテンツを無効化します。Oracle Fusion MiddlewareのフロントエンドとしてLBRが設定されている場合、LBRは、データベースからの無効化リクエストを受け入れてクラスタのメンバー間で負荷を均衡させるように構成されている必要があります。ルーティングの設定方法によっては、NATを設定し、データ層上で適切な送信ポートを開く必要もあります。この設定に必要な手順については、後で説明します。
|
注意:
|
LBRをフロントエンドに設定した複数の中間層環境でOracle Portalを構成するには、次の手順を実行します。
単一のPortal中間層をインストールし、インストールを確認します。これを行うには、次の手順を実行します。
Oracle Fusion Middleware Oracle Portal、Forms、Reports、Discovererインストレーション・ガイドに説明されている手順に従って、最初のコンピュータ（M1）にPortal中間層をインストールします。ここでは、既存のOracle Fusion Middleware Infrastructureのサービスを使用することを想定しています。
|
関連項目 『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』 |
次の場所にあるOracle Portalホーム・ページにアクセスできることを確認して、中間層が正常にインストールされていることを確認します。
http://m1.abc.com:7777/portal/pls/portal
ここで、LBRを通じてアクセスされるOracle Portalを構成するために、次の手順に進みます。
ロード・バランス・ルーター（LBR）を通じてアクセスされるようにOracle Portalを構成するには、次の手順を実行します。
ポート80でリクエストを受け取り、これらのリクエストをコンピュータ（m1.abc.com）で実行中のOracle Web Cacheのポート8090へ転送するように、LBR（lbr.abc.com）を構成します。これを行うには、次の手順を実行します。
個々のサーバーを追加できるグループ（プール）をLBR上に設定します。
必要なサーバーのIPアドレスとポート番号をグループに追加します。
ポート80でリスニングを行い、グループのメンバー間で負荷を均衡させる仮想サーバーを作成します。
LBRが、リクエストを転送するためにリスニングするポートをOracle Web Cacheがリスニングしているポートへ変換することを確認します。
|
注意: グループと仮想サーバーを設定するには、LBRのドキュメントを参照してください。 |
基盤となるコンポーネントが、LBRのホスト名（lbr.abc.com）とLBRのポート番号（80）に基づくURLを作成できるように、M1でOracle Portal中間層を構成して、Oracle Portalページに描画される自己参照型URLがブラウザで有効になるようにします。これを行うには、次の手順を実行します。
第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して仮想ホストを定義し、仮想ホストの「サーバー名」フィールドにLBR（lbr.abc.com:80）のホスト名を指定します。
第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して2番目の仮想ホストを定義します。ただし、次の変更点があります。
仮想ホストの「サーバー名」フィールドに、M1（m1.abc.com:8090）のホスト名を指定します。
Oracle HTTP Serverを再起動します。
仮想ホストの構成後、Oracle Enterprise Manager 11g Fusion Middleware Controlでhttpd.confファイルを開いて、次の手順を実行します。
「Web層」を開いて、Oracle PortalインスタンスのOracle HTTP Server（ohs1）リンクをクリックします。
Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。
「サーバーの詳細構成」ページの「ファイルの選択」オプションで「httpd.conf」を選択して、「実行」をクリックします。
次の構文をhttpd.confファイルに追加します。
NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://lbr.abc.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>
<VirtualHost *:8888>
ServerName http://m1.abc.com:8090
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>
「適用」をクリックします。
Oracle HTTP Serverを再起動します。
M1でOracle Fusion Middleware Controlを使用して、前述の手順で作成した仮想ホスト・エントリ（lbr.abc.com）に対応させるサイトを次のように定義します。
Oracle Fusion Middleware Oracle Web Cache管理者ガイドの説明に従って、M1でOracle Enterprise Manager 11g Fusion Middleware ControlのWeb Cacheホーム・ページに移動します。
Web Cacheのメニューから、「管理」→「サイト」を選択します。
「サイト」ページが表示されます。
「サイト」で「作成」をクリックします。
「サイトの作成」ページで、「ホスト」にlbr.abc.com、「ポート」に80を指定します。
「デフォルト・サイト」および「圧縮」を選択します。
「URL接頭辞」は、空白のままにします。
「OK」をクリックします。「サイト」表にlbr.abc.comが表示されます。
「サイト」表からlbr.abc.comを選択して、「編集」をクリックします。
「別名」セクションで「作成」をクリックして新しい別名を作成し、次の情報を入力します。
ホスト名: m1.abc.com
ポート: 8090
「OK」をクリックします。
「適用」をクリックします。
M1でOracle Enterprise Manager 11g Fusion Middleware Controlを使用して、サイトlbr.abc.comを中間層m1.abc.comにマップします。
「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。
「サイト・サーバー間マッピング」セクションで、次の情報を入力します。
ホスト・パターン: lbr.abc.com
ポート・パターン: 80
「接頭辞」フィールドは、空白のままにします。
「オリジナル・サーバー」セクションで、「すべてのオリジナル・サーバー」からm1.abc.com:8888を選択し、それを「選択したオリジナル・サーバー」に移動します。
「OK」をクリックします。
「適用」をクリックします。
「サイト」表からm1.abc.comを選択して「削除」をクリックし、未使用のサイトを削除します。
「サイト・サーバー間マッピング」表で「削除」をクリックして、未使用のサイトを削除します。
Oracle Enterprise Manager 11gのWeb Cacheホーム・ページで「制御」→「再起動」を選択して、Oracle Web Cacheを再起動します。
サイトが正しくマップされたことを確認するために、「Site-to-Server Mapping」ページに移動して、M1がサイトのlbr.abc.comにマップされているかどうかを調べます。
m1.abc.comのコンピュータを構成して、LBRのホスト名が解決されて正しいIPアドレスが設定されるようにします。DNSの解決に委ねることも、次のようなエントリを/etc/hostsファイル内に作成することもできます。
L1.L1.L1.L1 lbr.abc.com
ここでのL1.L1.L1.L1は、LBRのIPアドレスです。これらの変更を行った後にシステムを再起動する必要はありません。
|
警告
127.0.0.1 m1.abc.com
|
m1.abc.comで実行中のPPEから流入するループバック・リクエストに対して、LBRがNATバウンス・バックを実行するように構成します。このように構成しておくと、PPEがOracle Web Cacheへループバック・リクエストを行うときに、エラーがないことが保証されます。
|
注意:
|
独立したポート（この例では4001）上のOracle Metadata Repositoryから無効化リクエストを受け取って、ポート4001のコンピュータm1.abc.comで実行中のOracle Web Cacheへそのリクエストが転送されるように、LBR（lbr.abc.com）を構成します。
|
注意: LBRは、Oracle Web Cacheの無効化用ポートでリスニングする必要はありません。ポート・マッピング機能のないLBRでは、ポート番号がOracle Web Cacheの無効化用ポートと一致している必要があります。 |
個々のサーバーを追加できるグループ（プール）をLBR上に設定します。
必要なサーバーのIPアドレスとポート番号をグループに追加します。
ポート8093でリスニングを行い、グループのメンバー間で負荷を均衡させる仮想サーバーを作成します。
LBRのポートが無効化リクエストをリスニングしており、Oracle Web Cacheの無効化用ポートと異なる場合、Oracle Web Cacheがリスニングしているポートへリクエストを転送するために、LBRでリスニングしているポートを変換する必要があります。
|
注意:
|
|
警告 セキュリティ上の理由から、LBRの無効化用ポート（ポート |
Portalの中間層を次のように構成します。
Enterprise ManagerでPortalホーム・ページに移動します。
「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。
「ポータル・ワイヤ構成」ページの「ポータル中間層」セクションに、次の情報を入力します。
公開ホスト: lbr.abc.com
リスニング・ポート: 80
「ポータル・ワイヤ構成」ページの「Oracle Web Cache」セクションで、「ホスト」にlbr.abc.com、「無効化ポート」に4001と入力します。
「適用」をクリックします。
管理対象サーバーを再起動します。
Oracle WebLogic Server管理コンソールで、lbr.abc.comのHTTP設定を次のように構成する必要があります。
Oracle WebLogic Server管理コンソールにログインします。
まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。
コンソールの左側のペインで、「環境」を開いて「クラスタ」を選択します。
クラスタ・サーバーを選択してから「HTTP」タブを選択します。
「HTTP」ページで、次の情報を入力します。
フロントエンド・ホスト: lbr.abc.com
フロントエンドHTTPポート: 80
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理対象サーバーを再起動します。
ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義されます。ssoregは、ORACLE_HOME/sso/binのIdentity Managementインスタンスにあります。
次の例は、UNIX上でのssoregの使用方法を示しています。
$ ssoreg.sh
-site_name lbr.abc.com
-mod_osso_url http://lbr.abc.com:port
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier
Windowsでは、かわりにssoreg.batを実行する必要があります。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のmod_ossoの登録に関する項を参照してください。
osso.confファイルをORACLE_INSTANCE/config/OHS/ohs1ディレクトリにコピーします。
Oracle HTTP Serverを再起動します。
次のテストを指定された順序で実行して、Oracle Portalが起動し、実行中であることを確認します。1つのテストに失敗した場合は、問題点の処置を行ってから次のテストに進んでください。Oracle Web Cache、Oracle HTTP ServerおよびLBRの構成とログを診断するには、『Oracle Fusion Middleware管理者ガイド』を参照してください。
Oracle Web Cacheにキャッシュされた静的ファイルにアクセスすることにより、Oracle Web CacheおよびOracle HTTP ServerにLBRを通じてアクセスできることをテストし、正常に機能することを確認します。たとえば、次のURLにアクセスできます。
http://lbr.abc.com:port/index.html
次のURLにアクセスすることにより、LBRを通じてOracle Metadata Repositoryに接続できることをテストします。
http://lbr.abc.com:port/portal/pls/portal/htp.p?cbuf=test
レスポンスはtestになります。このテストに成功することは、Oracle Fusion Middleware中間層がOracle Metadata Repositoryに接続できるということです。失敗した場合は、WLS_PortalインスタンスのWLS_PORTAL-diagnostic.logファイルでリクエストの失敗に関する詳細を調べ、適切な処理を行います。
次の手順を実行することにより、Oracle Portalにアクセスできることをテストします。
http://lbr.abc.com:port/portal/pls/portalにあるOracle Portalのホーム・ページにアクセスします。アクセスできなかった場合は、WLS_PortalインスタンスのWLS_PORTAL-diagnostic.logファイルを調べ、エラーを探します。このエラーの最も一般的な原因は、PPEがループバック接続を行えないことです。これが機能するように、次のことを行います。
LBR内でNATが有効であることを確認します。
m1.abc.com上の中間層がlbr.abc.comのアドレスを解決できることを確認します。これを行うには、m1.abc.comから次のコマンドを実行します。
ping lbr.abc.com
Oracle Portalホーム・ページにアクセス時に、XML解析エラーが発生することがあります。その場合は、診断ログを確認してください。エラーの原因の1つとして、Oracle Web CacheとOracle Portal間のWebCache無効化パスワードの不一致があげられます。両者の設定を調べて、パスワードが一致することを確認します。
ポータルのログイン・リンクをクリックします。これが機能しない場合は、ssoregを実行して仮想ホスト（mod_ossoがシングル・サインオンを容易にする）を登録した手順を確認します。詳細は、MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\logsにあるWLS_PORTALインスタンスのWLS_PORTAL-diagnostic.logファイルを調べてください。
ポータルのリンクをいくつかクリックしてみます。
コンテンツがOracle Web Cacheにキャッシュされていることを確認します。
Oracle Enterprise ManagerのWeb Cacheのメニューから、「監視」→「ポピュラーなリクエスト」を選択します。「ポピュラーなリクエストの表示」ドロップダウン・リストから「キャッシュされたポピュラーなリクエスト」を選択します。「キャッシュされたポピュラーなリクエスト」で「実行」をクリックし、ページのコンテンツを更新します。Oracle Portalにアクセスできた場合は、ポータルのコンテンツが表示されます（_esiReqType=2、wwpob_smd.has_previlegeおよびwwv_setting.render_cssなどの文字列を含むURL）。ポータルのコンテンツが何も表示されない場合は、別のブラウザを開き、Oracle Portalにログインします。「キャッシュされたポピュラーなリクエスト」ページに戻り、「実行」をクリックしてページのコンテンツを更新します。これで、検証用には十分なコンテンツが提供されます。
Oracle Portalで、ポートレットをページに追加するなどの基本的なページ編集を行って、新しいコンテンツが表示されることを確認します。新しいコンテンツが正しく表示されない場合やエラーが発生する場合は、Oracle Web Cacheの無効化の構成に誤りがあります。
M2（m2.abc.com）上で新しいポータル中間層をインストールするには、次の手順を実行します。
|
注意: Oracle Portalのインストールを続行する前に、WebLogic Serverがインストールされていることを確認してください。Oracle WebLogic Serverインストレーション・ガイドを参照してください。WebLogic ServerをインストールするとMiddlewareホームが作成されます。Middlewareホームは、すべてのOracle Fusion Middlewareコンポーネントのインストールに使用されます。 |
Oracle Universal Installerを実行して、Portal中間層を2番目のコンピュータ（M2）にインストールします。
Oracle Fusion Middleware中間層のインストール中に「インストール・タイプの選択」画面で「ソフトウェアのインストールおよび構成」オプションを選択して、「次へ」をクリックします。
「前提条件のチェック」画面で「次へ」をクリックして続行します。
ドメインの選択画面で「クラスタを開く」を選択して、次の情報を入力します。
ホスト: m1.abc.com
ポート: WebLogic管理ポート番号。デフォルトは7001です。
ユーザー名: WebLogic管理サーバーのユーザー名を入力します。
ユーザー・パスワード: WebLogic管理サーバーのパスワードを入力します。
「セキュリティ更新用の電子メールの指定」画面に情報を入力し、「次へ」をクリックして続行します。
Middlewareホーム、Oracleホーム、Oracleインスタンスの場所およびOracleインスタンス名を「インストール場所の指定」画面で指定し、次へ」をクリックして続行します。
|
注意: 2番目の中間層のインストールに同じ物理パスを使用することをお薦めします。このようにしておくと、1つのコンピュータで構成の変更を行い、その変更内容を別のコンピュータへ転送するときに役立ちます。物理パスが他のコンピュータと異なると、ファイルのコピー後にパスの要素が正しいかどうかの確認を行うことが必要になります。 |
「コンポーネントの構成」画面でM1に選択したコンポーネントを選択し、「次へ」をクリックします。
「ポートの構成」画面で構成ファイルを使用してポートを指定を選択し、「参照」をクリックしてM1で使用されるstaticports.iniファイルを選択します。M1のインストール時に保存しなかった場合、このファイルは存在しません。その場合は、ファイルの表示/編集をクリックし、ファイルを次のように編集します。
This port indicates the Domain port noDomain Port No = 7001 [OHS] Oracle HTTP Server Port No = 8888 [WEBCACHE] Oracle WebCache Port No = 8090 Oracle WebCache Invalidation Port No = 8093 [MANAGEDSERVER] Oracle WLS Portal Managed Server Port No = 9001
|
注意: ポートの値は、MIと同じである必要があります。 |
アプリケーションOIDの指定画面でOracle Internet Directoryサーバーの詳細を入力して、「次へ」をクリックします。
「インストール・サマリー」画面で情報を確認して、「インストール」をクリックします。
|
関連項目 『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』 |
この新しいインストールが以前の構成に影響を与えることはありません。Oracle PortalがM1上で起動されて実行中であり、LBRを通じてアクセスできることを確認します。確認方法の詳細は、第6.3.3項「手順3: Oracle Portalが起動し実行中であることの確認」を参照してください。
既存のポータルを実行するには、次の手順をこの順序で実行してM2を構成します。
中間層M1から中間層M2へ、Oracle Portalの構成設定値をコピーします。まずファイルをバックアップすることをお薦めします。これを行うには、次のファイルをコピーします。
appConfig.xml
portal_cache.conf
portal_dads.conf
portal_plsql.conf
MW_HOME\user_projects\domains\<DomainName>\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configurationをM1からM2にコピーします。
M1とM2が異なる物理パスを使用してインストールされている場合は、ファイルのコピー後にパスの要素が正しいかどうかを確認する必要があります。
基盤となるコンポーネントが、ロード・バランス・ルーター（LBR）のホスト名（lbr.abc.com）とLBRのポート番号（80）に基づくURLを作成できるように、新しいOracle Portal中間層を構成します。これを行うには、M2上でFusion Middleware Controlを使用して、次の手順を実行します。
第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して仮想ホストを定義します。ただし、次の変更点があります。
「新規リスニング・アドレス」オプションを選択して、lbr.abc.com:80と入力します。
仮想ホストの「サーバー名」フィールドに、LBR（lbr.abc.com）のホスト名を指定します。
第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して2番目の仮想ホストを定義します。ただし、次の変更点があります。
「新規リスニング・アドレス」オプションを選択して、m2.abc.com:8090と入力します。
仮想ホストの「サーバー名」フィールドに、M2（m2.abc.com）のホスト名を指定します。
Oracle HTTP Serverを再起動します。
仮想ホストの構成後、Oracle Enterprise Manager 11g Fusion Middleware Controlでhttpd.confファイルを開いて、次の手順を実行します。
「Web層」を開いて、Oracle PortalインスタンスのOracle HTTP Server（ohs1）リンクをクリックします。
Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。
「サーバーの詳細構成」ページの「ファイルの選択」オプションで「httpd.conf」を選択して、「実行」をクリックします。
次の構文をhttpd.confファイルに追加します。
NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://lbr.abc.com
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>
<VirtualHost *:8888>
ServerName http://m2.abc.com:8090
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>
「適用」をクリックします。
Oracle HTTP Serverを再起動します。
mod_oradav.conf、mod_osso.conf、plsql.confおよびportal.confをM1のORACLE_INSTANCE\config\OHS\ohs1\moduleconfからM2にコピーします。
ORACLE_INSTANCE\config\OHS\ohs1\osso.confをM1からM2にコピーします。
ORACLE_INSTANCE\config\OHS\ohs1\moduleconfにあるportal.confファイルを開き、WebLogicHostおよびWebLogicPortで始まるすべての行を削除してWebLogicClusterディレクティブと置き換え、次のように更新して、Oracle HTTP ServerがすべてのOracle WebLogic管理対象サーバーを認識するようにします。
M1の場合:
<Location /portal>
SetHandler weblogic-handler
WebLogicCluster m1.abc.com:9001,m2.abc.com:9001
</Location>
M2の場合:
<Location /portal>
SetHandler weblogic-handler
WebLogicCluster m2.abc.com:9001,m1.abc.com:9001
</Location>
次のコマンドを使用してOracle HTTP Serverを再起動します。
ORACLE_INSTANCE\bin\opmnctl stopall ORACLE_INSTANCE\bin\opmnctl startall
m2.abc.comのコンピュータを構成して、LBRのホスト名が解決されて正しいIPアドレスが設定されるようにします。DNSの解決に委ねることも、次のようなエントリを/etc/hostsファイル内に作成することもできます。
L1.L1.L1.L1 lbr.abc.com
|
警告
127.0.0.1 m2.abc.com |
Oracle Fusion Middleware Oracle Web Cache管理者ガイドで説明しているように、M1上でOracle Web Cache Managerにアクセスします。
M1でOracle Enterprise Manager 11gを使用して、M2を追加のオリジナル・サーバーとしてOracle Web Cacheに追加します。これを行うには、次の手順を実行します。
Oracle Enterprise Manager 11gで、M1のWeb Cacheホーム・ページに移動します。
Web Cacheのメニューから、「管理」→「オリジナル・サーバー」を選択します。
「オリジナル・サーバー」ページが表示されます。
「作成」をクリックします。
「オリジナル・サーバーの作成」ページが表示されます。
「オリジナル・サーバーの作成」ページで次の情報を指定します。
| プロパティ | 値 |
|---|---|
| ホスト | m2.abc.com |
| ポート | 8888 |
| 容量 | 100 |
| プロトコル | HTTP |
| 有効ルーティング | ENABLED |
| フェイルオーバーのしきい値 | 5 |
| URLのping | / |
| pingの間隔(秒) | 10 |
|
注意: 「ポート」の値には、M2のOracle HTTP Serverリスニング・ポートを指定します。 |
「OK」をクリックします。
「適用」をクリックします。
オリジナル・サーバーが正しく追加されたことを確認するには、「Origin Server」表内にm2.abc.comがあるかどうかを調べます。
詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドのサイトとオリジナル・サーバーのマップに関する項を参照してください。
次の手順に従って、M1でFusion Middleware Controlを使用し、lbr.abc.comサイトを2つのオリジナル・サーバーのm1.abc.comとm2.abc.comにマップします。
Oracle Enterprise Manager 11gで、M1のWeb Cacheホーム・ページに移動します。
Web Cacheのメニューから、「管理」→「サイト」を選択します。
「サイト」ページが表示されます。
「サイト・サーバー間マッピング」ページで表内のLBRサイトのマッピングを選択し、「編集」をクリックします。
「すべてのオリジナル・サーバー」でm2.abc.com:8888を選択し、それを「選択したオリジナル・サーバー」に移動します。
「OK」をクリックします。
「適用」をクリックします。
サイトが正しくマップされたことを確認するには、Enterprise ManagerのWeb Cacheメニューにアクセスして「管理」→「サイト」を選択し、「サイト・サーバー間マッピング」表でM1とM2の両方がlbr.abc.comのサイトに対応付けられているかどうかを調べます。
詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドのサイトとオリジナル・サーバーのマップに関する項を参照してください。
M1でOracle Fusion Middleware Controlを使用し、M2のOracle Web CacheをM1のOracle Web Cacheクラスタに追加して、両方のOracle Web Cacheのパスワードが同じであることを確認します。これを行うには、次の手順を実行します。
Fusion Middleware ControlでWeb Cacheホーム・ページに移動します。
Web Cacheのメニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページで「追加」をクリックします。
M2のWeb Cacheが追加されます。
「適用」をクリックします。
「同期化」をクリックし、「はい」をクリックして確認します。
M1およびM2上のOracle Web Cacheを再起動します。
キャッシュ・クラスタの構成の詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
m2.abc.comで実行中のOracle HTTP Serverから流入するループバック・リクエストのためにNATバウンス・バックを実行するように、LBRを構成します。詳細は、第6.3.2項「手順2: LBRを通じてアクセスされるM1でのOracle Portalの構成」の手順6を参照してください。
これらの手順の終了後は、設定した構成は図6-1のようになります。
|
注意: 中間層の追加は第6.3.4項「手順4: 新しいポータル（M2）のインストール」に概略を示した手順に従い、各中間層については、第6.3.5項「手順5: 既存のポータルを実行するための新しい中間層（M2）の構成」を参照してください。 |
Portalツール（OmniPortletおよびWebクリッピング）プロバイダ、およびローカルで構築されたWebプロバイダとカスタムで構築されたWebプロバイダが正常に機能していることを確認するには、中間層環境にさらに構成を追加する必要があります。OmniPortletやその他のWebプロバイダによってファイル・システムがすでにパーソナライズされている場合、PDK-Javaのプリファレンス・ストア移行/アップグレード・ユーティリティを使用して、既存のパーソナライズをデータベースに移行し、以前のリリースからのパーソナライズをアップグレードすることができます。このユーティリティの詳細は、第B.10項「PDK-Javaのプリファレンス・ストア移行/アップグレード・ユーティリティの使用」を参照してください。
WSRPプロデューサの場合は、Oracle Metadata Repositoryがデフォルトのポートレット・プリファレンス・ストアとして使用されます。別のプリファレンス・ストアを使用する場合は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。
複数の中間層環境でのPortalツール・プロバイダの構成
複数の中間層環境でPortalツール（OmniPortletおよびWebクリッピング）プロバイダを正常に機能させるには、次の手順を実行します。
Portalツールの構成情報は、中間層サーバーのOmniPortletおよびWebクリッピングprovider.xmlファイルに格納されています。1つの中間層（たとえば、M1）で構成を直接更新し、LBRですべての中間層フロントエンドに伝播する必要があります。詳細は、第E.1.3項「HTTPまたはHTTPSのプロキシ設定の構成」を参照してください。provider.xmlファイルに対して行われた変更を中間層のM2に伝播します。
MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet\provider.xmlをM1からM2にコピーします。
MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\tr7qwp\war\WEB-INF\providers\webClipping\provider.xmlをM1からM2にコピーします。
中間層のM2を再起動します。
次のURLにあるテスト・ページにアクセスして、OmniPortletとWebクリッピング・プロバイダがLBRを通じて正常に動作することを確認します。
OmniPortletプロバイダ: http://lbr.abc.com/portalTools/omniPortlet/providers/omniPortlet
OmniPortletプロバイダのテスト・ページで、「ポートレット情報」セクションに「使用可能なポートレットはありません」というメッセージが表示された場合、手順1でOmniPortletを正しく構成していない可能性があります。OmniPortletが正しく構成されている場合、「OmniPortlet」と「シンプル・パラメータ・フォーム」のポートレットがテスト・ページで利用できます。
Webクリッピング・プロバイダ: http://lbr.abc.com/portalTools/webClipping/providers/webClipping
|
注意: Webクリッピング・プロバイダまたはOmniPortletのWebページ・データソースを使用する場合は、Oracle Web Cacheでセッション・バインドを有効にする必要もあります。詳細は、「手順7: Oracle Web Cacheでのセッション・バインドの有効化」を参照してください。 |
Oracle Portalで、「ナビゲータ」にある「プロデューサ」タブの「ローカルで構築されたプロバイダ」で、OmniPortletプロデューサの「登録の編集」をクリックします。次に、「接続」タブをクリックし、プロデューサ登録URLの最初の部分をhttp://m1.abc.com:7777/からhttp://lbr.abc.com/に変更します。
Oracle Portalで、「ナビゲータ」にある「プロデューサ」タブの「ローカルで構築されたプロバイダ」で、Webクリッピング・プロデューサの「登録の編集」をクリックします。次に、「接続」タブをクリックし、プロデューサ登録URLの最初の部分をhttp://m1.abc.com:7777/からhttp://lbr.abc.com/に変更します。
ポートレット・リポジトリの「ポートレット・ビルダー」フォルダにPortalツール・ポートレットが表示されるように、ポートレット・リポジトリを更新します。
ポータル管理者としてログインし、「ビルダー」リンクをクリックします。
「管理者」タブをクリックします。
「ポートレット」サブタブをクリックします。
「ポートレット・リポジトリ」ポートレットの「ポートレット・リポジトリのリフレッシュ」リンクをクリックします。
更新処理がバックグラウンドで続行されます。
複数の中間層環境でのローカルで構築されたWebプロバイダの作成と編集
ローカルで構築されたプロバイダとは、Oracle Portalのインスタンス内部に定義されているプロバイダのことです。ローカルに構築されたプロバイダを使用できるのは、これらを前のリリースから移行した場合です。通常、LBRを構成する前に、これらのプロバイダを作成または編集します。LBRの構成後にこれを行うには、次の手順を実行します。
Webプロバイダの情報は、中間層サーバーのprovider.xmlファイルに保持されています。アップグレード・アシスタントを使用してprovider.xmlを1つの中間層（M1など）に移行し、LBRですべての中間層フロントエンドに伝播する必要があります。これを行う前に、M1以外の中間層をすべて停止する必要があります。
M1内のファイルに対して行われた変更を中間層のM2に伝播します。
MW_HOME\user_projects\domains\<Domain Name>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\kjdcke\war\WEB-INFに移動して、deployment、deployment_provideruiおよびprovidersの各フォルダをM1からM2にコピーします。
MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\kjdcke\war\WEB-INF\deployment_providerui\provideruiacls.xmlファイルをM1からM2にコピーします。
<warDir>要素をM2に適した値に変更します（太字の部分）。
<providerMap name="MyProducer" baseLanguage="en">
<displayName language="en" translation="myprovider"></displayName>
<timeout>20</timeout>
<timeoutMessage language="en" translation="Timed Out"></timeoutMessage>
<loginFrequency>Never</loginFrequency>
<httpURL>http://lbr.abc.com:80/portalTools/builder/providers/MYPROVIDER</httpURL>
<cookieDomain>abc.com</cookieDomain>
<serviceId>MYPROVIDER</serviceId>
<requireSessionData>false</requireSessionData>
<httpAppType>Portal</httpAppType>
<warDir>{providerBuilder war directory of this mid-tier}</warDir>
<warFile>providerBuilder</warFile>
</providerMap>
中間層のM2を再起動します。
URL http://lbr.abc.com:80/portalTools/builder/providers/<providerName>にあるテスト・ページにアクセスして、WebプロバイダがLBRを通じて正常に動作することを確認します。
複数の中間層環境でのカスタムで構築されたWSRPプロデューサの構成
デフォルトでは、WSRPプロデューサはポートレット・プリファレンス・データをOracle Metadata Repositoryに保存することで、複数の中間層環境で正常に機能します。この情報をカスタム・データベースを使用して保存する場合は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。
|
注意: 複数の中間層環境でポートレット・プリファレンス・データの保存にカスタム・データベースを使用する場合は、すべてのWSRPプロデューサがdata-sources.xmlにある同じデータベース・スキーマを参照する必要があります。 |
ロード・バランス・セッションベースのWebプロバイダの構成
フロントエンドとしてロード・バランス・ルーター（LBR）が設定されたセッションベースのWebプロバイダを構成するには、プロバイダの情報ページでログインの頻度を「ユーザー・セッションごとに1回」に設定し、LBRをCookieベースのルーティングを行うように構成する必要があります。ログインの頻度を設定するには、次の手順を実行します。
Oracle Portalにログインします。「Portalビルダー」ページが表示されます。
Portalビルダーで「管理」タブをクリックしてから、「ポートレット」タブをクリックします。
「リモート・プロバイダ」で、構成するWebプロバイダ名を入力し、「編集」をクリックします。
「接続」タブをクリックします。
「ユーザー/セッション情報」で、「ログイン周期」を「ユーザー・セッションごとに1回」に設定します。
「OK」をクリックします。
LBRをCookieベースのルーティングを行うように構成する方法の詳細は、LBR固有のドキュメントを参照してください。
外部アプリケーション・ログインURLの編集
外部アプリケーションが中間層でホスティングされている場合、外部アプリケーション・ログインURLをOracleAS Single Sign-On Serverで更新する必要があります。これを実行するには、『Oracle Application Server Single Sign-On管理者ガイド』の「外部アプリケーションの編集」に記載されている手順に従ってください。ログインURLの最初の部分をhttp://m1.abc.com:7777/からhttp://lbr.abc.com/に変更します。
Oracle Web Cacheのセッション・バインド機能は、ユーザー・セッションを特定のオリジナル・サーバーにバインドして、状態を一定の期間保持するために使用されます。デフォルトのOracle Portal中間層で実行されるほとんどすべてのコンポーネントはステートレスですが、セッション・バインドは次の2つの理由で必要になります。
Webクリッピング・ポートレットとOmniPortletのWebページ・データソースの両方で使用されるWebクリッピング・スタジオでは、状態を保持するHTTPセッションを使用するため、セッション・バインドを有効化する必要があります。Webクリッピングの詳細は、付録E「Portalツールのプロバイダの構成」を参照してください。
セッション・バインドを有効化すると、すべてのユーザー・リクエストが強制的に特定のOracle Portal中間層に転送されるので、ポータル・キャッシュのヒット率が高まります。ポータル・キャッシュの詳細は、第1.3.2項「ポータル・キャッシュについて」を参照してください。
|
注意: 複数の中間層がある場合、トポロジ内でLBRを構成しているかどうかにかかわりなく、Oracle Web Cacheのセッション・バインドを有効化する必要があります。この構成のOracle Portalでは、セッション・バインドをLBRに設定する必要はありません。 |
Oracle Web Cacheでポータル・ユーザー・セッションをOracle Portal中間層にバインドするには、Oracle Fusion Middleware Controlで次の手順を実行します。
Oracle Enterprise Manager 11gでWeb Cacheホーム・ページに移動します。
Web Cacheのメニューから、「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。
「セッション定義」表でセッション定義を作成します。セッション定義の作成方法の詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
次のようにセッション・バインド設定を指定します。
「セッション・ポリシー構成」セクションで、「作成」をクリックします。
表に新しい行が表示されます。
「セッション名」リストから手順3で作成したセッションを選択し、「キャッシュ」オプションから「セッションを使用」を選択します。
「セッション・バインディング構成」セクションで「セッションを使用したバインド」ラジオ・ボタンを選択します。手順3で作成したセッションを選択し、次の方式のいずれかを選択します。
Cookieベース: クライアントでCookieをサポートする場合に選択します。Oracle Web Cacheでは、独自のCookieを使用してセッションを追跡します。このCookieにはルーティング情報が含まれており、Oracle Web Cacheとクライアント・ブラウザ間で保持されます。
内部トラッキング: クライアントがCookieをサポートしておらず、アプリケーションがOracle HTTP ServerベースでもWLSベースでもない場合に選択します。このオプションは、Oracle Web Cacheの以前のリリースとの下位互換性の目的で用意されています。Oracle Web Cacheはメモリー内ルーティング表を維持します。表内の各エントリによって、セッションIDがオリジナル・サーバーにマップされます。ルーティング表は、クラスタ・ノード間では共有されません。このオプションを選択しており、キャッシュ・クラスタ構成がある場合は、ロード・バランサ・レイヤーでバインドする必要があります。
セッション・バインディングIAS: アプリケーションがWLSベースである場合に選択します。Oracle Web Cacheは、Oracle HTTP Serverを介してWLSに、各リクエストとともにルーティング情報を転送します。
「適用」をクリックして、変更を保存します。
詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
完了した構成が正常に機能していることを確認するには、次の手順を実行します。
Oracle Web Cacheに格納されたコンテンツを消去するには、次のようにM1およびM2を再起動します。
Oracle Enterprise Manager 11gにアクセスして、M1インスタンスを開きます。
詳細は、「Oracle Enterprise Manager 11g Fusion Middleware Controlへのアクセス」を参照してください。
M1のメニューから、「制御」→「停止」→「制御」→「起動」を選択します。
この手順をM2について繰り返します。
次の手順を実行して、Oracle PortalにLBRを通じてアクセスできるかどうかをテストします。
http://lbr.abc.com/portal/pls/portalにあるOracle Portalのホーム・ページにアクセスします。
ポータルのログイン・リンクをクリックします。
ポータルのリンクをいくつかクリックしてみます。
次の手順を実行して、コンテンツがOracle Web Cacheにキャッシュされていることを確認します。
Fusion Middleware Controlにアクセスして「Web層」を開き、「Webキャッシュ」を選択します。Web Cacheのメニューを右クリックし、「監視」→「ポピュラーなリクエスト」を選択します。「ポピュラーなリクエスト」ページが表示されます。Oracle Portalで、ポートレットをページに追加するなどの基本的なページ編集を行って、「ポピュラーなリクエスト」ページのリフレッシュ時に、このページに新しいコンテンツが表示されることを確認します。新しいコンテンツが正しく表示されない場合やエラーが発生する場合は、Oracle Web Cacheの無効化の構成に誤りがあります。
Oracle HTTP Serverは、仮想ホストの構成をサポートしています。仮想ホストによって、1台のコンピュータを任意の数の異なるサイトとして表すことができます。たとえば、1台のコンピュータを、www.abc.comとwww.xyz.comの両方で表すように構成できます。1台のコンピュータをmy.oracle.comとoraclepartnernetwork.oracle.comの両方で表すように構成することもできます。Oracle Portalを使用して仮想ホストを構成するには、Oracle HTTP Server上で仮想ホストを設定する必要があります。その他にOracle Web CacheとOracle Application Server Single Sign-Onの構成も必要です。
ポータル・ページは、最初にアクセスするホストのホスト名でOracle Web Cacheにキャッシュされます。同じページに対する後続のリクエストには必ず、アクセスするホストに関係なく、そのホスト名のあるリンクが含まれます。
たとえば、仮想ホストwww.abc.comを使用してページAにアクセスする場合、ページAのすべてのリンクは、www.abc.comの相対で表示されます。別のユーザーが仮想ホストwww.xyz.comを使用して、同じページAにアクセスする場合、Oracle Web Cacheにおいて別名処理が行われるため、このページ用に作成されたすべてのリンクは、www.abc.comを参照し、これらのリンクをクリックすると、www.abc.comから提供されるポータル・ページになります。
両方の仮想ホストから提供されるページが相互に排他的（つまり、サイトwww.abc.comから提供されるポータル・ページが、www.xyz.comから提供されていない）でないかぎり、ユーザーは2つの仮想ホストの間を往復します。これが望ましくない場合は、次のいずれかを実行できます。
http://metalink.oracle.comの824225.1で、Web Cacheサイト定義でホスト非依存の無効化により2つのサイトを作成するための情報を参照します。
Oracle Fusion Middleware Java EEエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle Portal専用のイントラネットとインターネットを設定します。
|
注意: 中間層のホスト名のみを変更する場合は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
サーバー名をwww.abc.comとし、http://www.abc.com:8090/portal/pls/portalのOracle Portalに接続することを想定します。中間層がインストールされるコンピュータのIPアドレスは、196.12.67.8です。
実際のサーバー名を使用してhttp://www.abc.com:8090/portal/pls/portalにあるOracle Portalにアクセスするだけでなく、仮想ホスト名を使用してhttp://www.xyz.com:8090/portal/pls/portalにもアクセスすると想定します。この場合の両方のURLが、同じIPアドレスを指します。
この例では、ポート8090がOracle Web Cacheのリスニング・ポート、ポート8888がOracle HTTP Serverのリスニング・ポートです。
また、OracleAS Single Sign-Onは、IPアドレスが123.45.67.8の別のコンピュータにインストールされていて、http://www.login.com:8091/pls/orassoというURLでアクセスされると想定します。
|
注意:
|
図6-4は、前述の構成を示しています。Oracle Web CacheとOracle Fusion Middlewareが同じ中間層のコンピュータにありますが、この2つは別々のコンピュータにあってもかまいません。
|
注意: ドメイン名www.abc.com、www.xyz.comおよびwww.login.comは有効なドメイン名であり、pingを実行できることが必要です。 |
仮想ホストを構成するには、次の手順を示された順序で実行します。
仮想ホスト名www.xyz.comおよび実際のサーバー名www.abc.com用に、httpd.confファイル内に仮想ホストのエントリを作成する必要があります。仮想ホストを定義するには、Oracle Enterprise Manager 11g Fusion Middleware Controlを使用して、次の手順を実行します。
この手順を終了した後に、次のことを実行します。
www.xyz.comの仮想ホストを作成するには、次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware Controlにアクセスします。
詳細は、「Oracle Enterprise Manager 11g Fusion Middleware Controlへのアクセス」を参照してください。
「Web層」を開いて、Oracle Portalインスタンスの「HTTPサーバー」リンクをクリックします。
Oracle HTTP Serverのホーム・ページで、「管理」→「仮想ホスト」を選択します。
「仮想ホスト」ページが表示されます。
「作成」ボタンをクリックします。
「仮想ホストの作成」ページが表示されます。
「仮想ホストの作成」ページで、表6-2にリストされている情報を入力します。
「OK」をクリックします。
サーバー名www.xyz.comが、表内に表示されることを確認します。
仮想ホストの構成後、Oracle Enterprise Manager 11g Fusion Middleware Controlでhttpd.confファイルを開いて、次の手順を実行します。
「Web層」を開いて、Oracle PortalインスタンスのOracle HTTP Server（ohs1）リンクをクリックします。
Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。
「サーバーの詳細構成」ページの「ファイルの選択」オプションで「httpd.conf」を選択して、「実行」をクリックします。
次に示すように、PortをServerNameに、およびRewriteとRewriteOptionsディレクティブをVirtualHostコンテナに追加します（太字の部分）。
NameVirtualHost *:8888
<VirtualHost *:8090>
ServerName http://www.xyz.com:8090
DocumentRoot <ORACLE_INSTANCE>/config/OHS/ohs1/htdocs
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>
「適用」をクリックします。
Oracle HTTP Serverのホーム・ページで「制御」→「再起動」を選択してOracle HTTP Serverを再起動します。
www.abc.comの仮想ホストを作成するには、次の手順を実行します。
第6.4.1.1項「www.xyz.comの仮想ホストの作成」の手順1〜6を実行します。
仮想ホストについての次の情報を「サーバー名」フィールドに入力します。
www.abc.com
第6.4.1.1項「www.xyz.comの仮想ホストの作成」の手順9を実行します。
Oracle HTTP Serverを再起動します。
www.abc.comとwww.xyz.comの仮想ホストを構成したら、次のようにFusion Middleware Controlを使用して、httpd.confファイルを確認します。
Oracle Enterprise Manager 11g Fusion Middleware Controlにアクセスします。
Oracle Portalインスタンスの「HTTPサーバー」リンクを右クリックします。
Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。
「サーバーの詳細構成」ページで「ファイルの選択」オプションから「httpd.conf」を選択して、「実行」をクリックします。
httpd.confファイルに次のような新しいセクションがあることを確認します。
NameVirtualHost *:8090 <VirtualHost *:8888> ServerName http://www.xyz.com:8090 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost> <VirtualHost *:8888> ServerName http://www.abc.com:8090 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost>
仮想ホストのエントリはhttpd.confファイルの既存の内容によって様々に異なることがありますが、www.abc.comとwww.xyz.comの両方の仮想ホストに対応する仮想ホストのエントリは必須です。
「適用」をクリックして、ファイルを更新します。
次のURLにアクセスして、サーバー名と仮想ホストの両方が機能していることを確認します。
http://www.xyz.com:8090/portal/pls/portal
http://www.abc.com:8090/portal/pls/portal
www.abc.comサイトは、すでにOracle Web Cache内に定義されています。これに加えて、複数の仮想ホストがOracle Metadata Repositoryに対して透過的になるように、Oracle Web Cache内にサイトの別名を作成する必要があります。www.abc.comはサイトとして設定されていますが、www.xyz.comはサイトの別名として定義しなければならないことに注意してください。このようにして、両方のサイト用にキャッシュされたコンテンツが、Oracle Web Cacheに送信される無効化メッセージによって無効化されます。
|
関連項目 サイトの別名の設定方法は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。 |
Oracle PortalをOracleAS Single Sign-Onに登録するには、次の手順を実行します。
ssoregを実行して、仮想ホストwww.xyz.comを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義されます。ssoregは、ORACLE_HOME/sso/bin（UNIX）のインフラストラクチャ層にあります。
次の例は、UNIX上でのssoregの使用方法を示しています。
ORACLE_HOME/sso/bin/ssoreg.sh -site_name www.xyz.com:8090 -config_mod_osso TRUE -mod_osso_url http://www.xyz.com:8090 -remote_midtier -config_file ORACLE_HOME/Apache/Apache/conf/osso/osso_xyz.conf
osso_xyz.confファイルをインフラストラクチャのホームからORACLE_INSTANCE/config/OHS/ohs1ディレクトリにコピーします。
Oracle Enterprise Manager 11g Fusion Middleware Controlを使用してhttpd.confファイルを開き、次のossoパラメータを追加します（太字の部分）。
<VirtualHost *:8888> ServerName www.xyz.com:8090 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit OssoIpCheck off OssoSecureCookies off OssoIdleTimeout off OssoConfigFile osso_xyz.conf </VirtualHost>
Oracle HTTP Serverを再起動します。
仮想ホストが正しく設定されたことを確認するには、次のいずれかのURLを使用してOracle Portalに接続します。
http://www.abc.com:8090/portal/pls/portal
http://www.xyz.com:8090/portal/pls/portal
最初のログイン時にhttp://www.login.comのログイン画面が表示され、ログインに成功することを確認してください。他の仮想ホストからのこれ以降のログインでは、シングル・サインオンが機能してログイン証明書の入力が求められないはずです。
ファイアウォールの外側のプロバイダおよびWebサイトへ接続するために、Oracle Portalを構成してプロキシ・サーバーを使用することができます。
|
注意:
|
プロキシ・サーバーを指定するには、次の手順を実行します。
「サービス」ポートレットで、「グローバル設定」をクリックします。
「サービス」ポートレットは「ビルダー」ページの「管理」タブにあります。
「プロキシ」タブをクリックします。
「HTTPプロキシ・ホスト」フィールドで、myproxy.mycompany.comのように、ファイアウォールの外側のアプリケーションにアクセスするために使用する、HTTPプロキシ・サーバーのアドレスを入力します。プロキシ・サーバー名に接頭辞http://は付けません。
「ポート」フィールドに、プロキシ・サーバーのポート番号を入力します。値を指定しない場合のポート番号のデフォルトは、80です。
|
注意: プロキシのソフトウェアを実行するサーバーの名前とポート番号については、サーバー管理者に問い合せてください。 |
「追加」をクリックします。
これで、ポータルとWebプロバイダまたはWSRPプロデューサ間の接続のためにプロキシ・サーバーを使用することができます。また、このプロキシは、たとえばURLアイテムに指定されたURLに接続するためなど、他の接続にも使用することができます。
「プロキシの選択」セクションで、このような接続に使用するプロキシ・サーバーを選択します。非プロバイダ接続でプロキシ・サーバーを使用しない場合は、「なし」を選択します。
「この文字で始まるドメインにプロキシ・サーバーを使用しない」フィールドに、プロキシ・サーバーを使用しないドメインを入力します。
|
注意: ドメインは、たとえば.mycompany.comのようにピリオド（.）で始まる必要があります。複数のドメインは、カンマ（,）で区切ります。 |
「OK」をクリックします。
プロキシ・サーバーの設定方法に関連する詳細は、Oracle Technology Network（OTN）（http://www.oracle.com/technology/）のホワイト・ペーパー「A Primer on Proxy Servers」を参照してください。
リバース・プロキシ・サーバーは、内部ホストを外部とアクセスできるホストと切り離すために、ファイアウォール・アーキテクチャの一部として使用されるホスト・プロセスです。外部リクエストが内部サービスにアクセスするために通過する必要があるプロキシを提供します。一般に、プロキシ・サーバーはデュアルホーム・ホストの形式をとります。つまり、プロキシ・サーバーは2つのネットワーク・インタフェース・カードを持つホストです。1つのインタフェースは外部ネットワークに接続し、もう1つのインタフェースは内部ネットワークまたはファイアウォールの非武装地帯（DMZ）に接続します。
表6-2は、ブラウザがプロキシ・サーバーで発行されたホスト名を介してサーバーにアクセスするアーキテクチャを示しています。プロキシ・サーバーはその後、リクエストをファイアウォール内の実際のホストに転送します。
|
注意: この構成が正しく機能するように、まずリバース・プロキシ・サーバーを使用するようにOracleAS Single Sign-Onを構成する必要があります。プロキシ・サーバーを使用するOracleAS Single Sign-Onのデプロイの詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。 |
この例では、次の値を使用します。
| プロパティ | 値 |
|---|---|
| 外部サーバー名 | www.abc.com |
| 外部サーバー・ポート | 80 |
| 内部サーバー名 | internal.company.com |
| Web Cacheリスニング・ポート | 8090 |
| Web Cache管理ポート | 8091 |
| Web Cache無効化ポート | 8093 |
| OHSリスニング・ポート | 8888 |
|
注意: この項で使用されている名前とポートは説明用の仮の値であり、実際の環境に合せて置き換える必要があります。『Oracle Fusion Middleware管理者ガイド』のポートの管理に関する項を参照してください。 |
図6-5に示すアーキテクチャでOracle Portalを構成するには、次の手順を実行します。
リバース・プロキシ・サーバーの構成
任意のプロキシ・サーバーを、リバース・プロキシとして機能させることができます。たとえば、Oracle Web Cache、Oracle HTTP ServerまたはInternet Information Services（IIS）リスナーなどを使用できます。
|
注意: この項ではOracle HTTP Serverをリバース・プロキシとして構成する方法について説明します。ポート80でリスニングし、www.abc.comとしてアクセスされるようにOracle HTTP Serverが設定および構成されていると仮定します。一部のプラットフォームでは、1024未満のポートを使用している場合、追加の構成手順が必要になります。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
Oracle HTTP Serverをリバース・プロキシとして使用するには、まずリバース・プロキシ・サーバー上でOracle HTTP Serverのスタンドアロン・バージョンをインストールします。この項では、受信リクエストをOracle Application Server Single Sign-On、Oracle Delegated Administration ServicesおよびOracle Portalに渡すようにOracle HTTP Serverを構成し、クライアントにリバース・プロキシ・サーバー・コンピュータのIDのみが表示されるようにすべてのHTTPヘッダーを変更する方法について説明します。Oracle HTTP Serverをリバース・プロキシとして構成するには、[P]（プロキシ強制）フラグつきのRewriteRuleディレクティブを使用してURLリライト・ルールを定義し、mod_proxyを介してリクエストを渡すようにします。LoadModuleディレクティブに従って、httpd.confファイル（ORACLE_INSTANCE\config\OHS\ohs1にある）でPortおよびRewriteディレクティブを追加します。
ProxyPassReverse / http://internal.company.com:8090
RewriteEngine On
RewriteRule ^/(.*) http://internal.company.com:8090/$1 [P]
Oracle HTTP Serverを再起動します。
ORACLE_INSTANCE\bin\opmnctl restartproc process-type=OHS
Oracle HTTP Serverの仮想ホストの構成
Portalが実行されている中間層で、リバース・プロキシのサーバー名を指すようにServerNameディレクティブを設定して、Oracle Portalページ上に表示される自己参照URLがブラウザで有効になるようにします。それには、次の手順を実行します。
第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して、リバース・プロキシに使用するOracle HTTP Serverインスタンスの仮想ホストを定義します。ただし、次の変更点があります。
「サーバー名」フィールドでwww.abc.comを指定します。
VirtualHostコンテナのPortディレクティブに80を指定します。
第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して、Oracle PortalとともにインストールしたApache ServerであるOracle HTTP Serverインスタンスの仮想ホストを定義します。ただし、次の変更点があります。
「サーバー名」フィールドでinternal.company.comを指定します。
VirtualHostコンテナのPortディレクティブに8090を指定します。
仮想ホストの構成後、Oracle Enterprise Manager 11g Fusion Middleware Controlを使用して、次のようにhttpd.confファイルを開きます。
「Web層」を開いて、Oracle PortalインスタンスのOracle HTTP Server（ohs1）リンクをクリックします。
Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。
「サーバーの詳細構成」ページで「ファイルの選択」オプションから「httpd.conf」を選択して、「実行」をクリックします。
次の構文をhttpd.confファイルに追加します。
NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName www.abc.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName Off
</VirtualHost>
<VirtualHost *:8888>
ServerName internal.company.com:8090
RewriteEngine On
RewriteOptions inherit
UseCanonicalName Off
</VirtualHost>
リバース・プロキシ・サーバーと連携するためのWeb Cacheの構成
Web Cacheのリバース・プロキシを構成するには、前の項で作成された仮想ホスト・エントリと一致するサイトを定義し、Oracle Fusion Middleware Controlを使用して、サイトのオリジナル・サーバーへの順序付けされたマッピングを作成する必要があります。それには、次の手順を実行します。
Enterprise ManagerのWeb Cacheホーム・ページに移動します。
「Webキャッシュ」メニューから「管理」→「サイト」を選択します。
「サイト」ページが表示されます。
サイト定義セクションで、「作成」をクリックします。
サイト定義の作成ページが表示されます。
次の情報を入力します。
ホスト: www.abc.com
ポート: 80
「別名」セクションで「作成」をクリックして新しい別名を作成します。
次の情報を入力します。
ホスト: internal.company.com
ポート: 8090
残りフィールドはデフォルト設定のままにします。
Click「OK」をクリックします。
|
注意: Webcacheが特定タイプのURLのみを許可するように、未使用のサイトを削除することをお薦めします。 |
「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。
「サイト・サーバー間マッピング」セクションで、次の情報を入力します。
ホスト・パターン: www.abc.com
ポート・パターン: 80
「オリジナル・サーバー」セクションで、「すべてのオリジナル・サーバー」からinternal.company.com:8888を選択し、それを「選択したオリジナル・サーバー」に移動します。
「OK」をクリックします。
Oracle Enterprise Manager 11gのWeb Cacheホーム・ページで「制御」→「再起動」を選択して、Oracle Web Cacheを再起動します。
リバース・プロキシ・サーバーと連携するためのPortal中間層の構成
Oracle Portalでは、Portalへのアクセスに使用するURLに関連する一部の情報が保持されます。ポータル中間層の構成を次のように更新する必要があります。
Enterprise ManagerでPortalホーム・ページに移動します。
「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。
「ポータル・ワイヤ構成」ページの「ポータル中間層」セクションに、次の情報を入力します。
公開ホスト名: www.abc.com
リスニング・ポート: 80
「適用」をクリックします。
管理対象サーバー（WLS_PORTAL）を再起動します。
リバース・プロキシ・サーバーと連携するためのOracle WebLogic Serverの構成
www.abc.comのHTTP設定を次のように構成する必要があります。
Oracle WebLogic Server管理コンソールにログインします。
まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。
コンソールの左側のペインで、「環境」を開いて「クラスタ」を選択します。
クラスタ・サーバーを選択してから「HTTP」タブを選択します。
「HTTP」ページで、次の情報を入力します。
フロントエンド・ホスト: www.abc.com
フロントエンドHTTPポート: 80
「保存」をクリックします。
管理対象サーバー（WLS_PORTAL）を再起動します。
内部サーバーのループバックの構成
パフォーマンスを向上させ、生成済のプロバイダが適切に機能するように、ローカルHOSTSファイルを使用して、通常は内部ネットワークに表示されないドメイン名を解決する必要があります。このループバック接続の詳細は、第1.2.2.2項「Oracle Portalでの通信フロー」を参照してください。
たとえば、internal.company.comのOracle Fusion Middlewareホストは自身に対するリクエストを作成しますが、リクエストしているURLはwww.abc.comを参照しています。そのマシンのローカルHOSTSファイルでホスト・エントリを作成し、ファイアウォール内でこの名前を解決できるようにして、必ずデータベース・マシンの/etc/hostsファイルにプロキシ・マシンのエントリを追加する必要があります。これは、ネットワーク上のデータベース・マシンでプロキシ・マシンのアドレスを解決するために必要な手順です。Windowsでは、この例のホスト・エントリに次の行を含める必要があります。
# This is a sample HOSTS file used by Microsoft TCP/IP # for Windows NT/2000. 127.0.0.1 localhost 123.45.67.8 www.abc.com
ローカルHOSTSファイルでこれらのエントリが指定されていない場合、リクエストをインターネット外に転送してからリバース・プロキシ（www.abc.com）を介して戻すプロキシ・サーバーを認識するようにOracle Fusion Middlewareを設定するか、www.abc.comに応答するようにリバース・プロキシ・サーバーの内部インタフェースを構成する必要があります。
|
注意: HP-UXなど一部のプラットフォームには、IP名マッピングのソースに適用する必要がある検索順序を指定するファイルがあります。プラットフォームにこのようなファイルがある場合、前述の例を機能させるには、IPマッピングでDNSサーバーの前にローカル・ホスト・ファイルをチェックするように指定します。 |
osso.confファイルの構成
osso.confファイルを次のように構成する必要があります。
Identity ManagementインスタンスからORACLE_HOME/sso/bin（Unix）にあるssoreg.shを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。
次の例は、UNIX上でのssoreg.shの使用方法を示しています。
$ORACLE_HOME/sso/bin/ssoreg.sh -site_name www.abc.com:80 -config_mod_osso TRUE -mod_osso_url http://www.abc.com:80 -update_mode MODIFY -remote_midtier -config_file/tmp/osso.conf
Windowsでは、かわりにssoreg.batを実行する必要があります。
osso.confファイルをORACLE_INSTANCE/config/OHS/ohs1ディレクトリにコピーします。
構成の確認
構成手順の完了後、http://www.abc.com/portal/pls/portalでプロキシ・ホスト名とポートを使用してOracle Portalにアクセスして、ただちに構成を確認できます。URLの上にマウスを置いて、internal.company.comではなくwww.abc.comと表示されること、およびブラウザのポート番号が8090または8888でないことを確認します。
Oracle Web Cacheにはキャッシュ、ページ・アセンブリおよび圧縮の機能が用意されています。Oracle Web Cacheは、静的および動的なWebコンテンツを迅速に配信し、Oracle Fusion Middlewareにロード・バランスおよびフェイルオーバーの機能を提供します。Oracle Portalでのキャッシュの機能の概要は、第1.3項「Oracle Portalのキャッシュについて」を参照してください。
この項では、Oracle Web Cacheを使用できるようにOracle Portalを構成する方法について説明します。
この項には次の項目が含まれています。
以前のリリースでは、Oracle Web Cacheを構成するためにOracle Web Cache Managerを使用する必要がありました。このリリースでは、Oracle Enterprise Manager 11g Fusion Middleware Controlを使用してOracle Web Cacheを構成し、Oracle Web Cache構成ファイルwebcache.xmlを更新できます。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
ホスト名や無効化用ポート番号など、Oracle Portalで使用する設定を変更するには、Oracle Enterprise Manager 11g Fusion Middleware Controlを使用します。これらの設定は、「ポータル・ワイヤ構成」ページで構成できます。
ポータルWeb CacheのWLST（オンライン）コマンドを使用して、次の作業を実行できます。
Portalリポジトリで使用されるWebCache構成の属性をリストするには、次のコマンドを実行します。
構文
listPortalWebcacheConfigAttributes ([dad_name])
| 引数 | 定義 |
|---|---|
dad_name |
オプション。データベース・アクセス記述子の名前です。デフォルトのデータベース・アクセス記述子の名前は、portalです。 |
例
次の例は、Portalリポジトリで使用されるWebCache構成をリストしています。無効化メッセージの送信先のWebCacheホスト名、無効化ユーザー名、パスワードおよび無効化メッセージの送信先の無効化ポートがリストされています。
listPortalWebcacheConfigAttributes(dad_name='portal1') --------------- WebCacheConfig --------------- WebCache Host: foo.oracle.com WebCache Invalidation Password: invalidator WebCache Invalidation Port: 6523 WebCache Invalidation User: invalidator
Portalリポジトリで使用されるWebCache構成の属性をリストするには、次のコマンドを実行します。
構文
setPortalWebcacheConfig([dad_name], [host], [inv_port], [inv_user], [inv_passwd])
| 引数 | 定義 |
|---|---|
dad_name |
オプション。データベース・アクセス記述子の名前です。デフォルトのデータベース・アクセス記述子の名前は、portalです。 |
host |
オプション。無効化メッセージの送信先となるWebCacheホスト名です。 |
inv_port |
オプション。無効化メッセージの送信先となるWebCacheポート番号です。 |
inv_user |
オプション。無効化メッセージの送信に使用するユーザー名です。 |
inv_password |
オプション。WebCacheの無効化パスワードです。 |
例
次の例では、指定された値に基づいてWebCache構成を更新します。
setPortalWebcacheConfig(dad_name='portal1',host='foo.oracle.com',inv_port= '6523',inv_user= 'invalidator',inv_passwd=' invalidator')
Oracle Portalのユーザー・インタフェースから、Oracle Web Cacheにキャッシュされたポータル・コンテンツを管理する様々なタスクを実行できます。Oracle Web Cacheにキャッシュされたポータル・コンテンツ全体を消去したり、各ポータル・ユーザーのコンテンツを消去したりすることもできます。
|
注意: キャッシュを消去すると、後続のリクエストがキャッシュ・ミスになり、キャッシュが再読込みされるまで、ポータルのパフォーマンスが低下することがあります。 |
ユーザーのグループ・メンバーシップが変更された場合は、そのユーザーのキャッシュ・エントリを削除して新しい権限を持てるようにするため、キャッシュを消去することができます。同様に、あるオブジェクトに対するユーザーまたはグループの権限を変更する場合も、そのオブジェクトのキャッシュ・エントリを消去することができます。
キャッシュ全体を消去したり、特定のユーザーのキャッシュを消去するには、ポータル管理者であることが必要です。特定のポータル・オブジェクトのキャッシュを消去するには、そのオブジェクトに対して、少なくとも「管理」権限を持っている必要があります。
次の各項で、Oracle Portalを使用して実行できる処理について詳細に説明します。
Web Cache全体を消去するには、次の手順を実行します。
「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。
「キャッシュ」タブをクリックします。
「Web Cache全体を消去」を選択します。
「適用」または「OK」をクリックして、キャッシュを消去します。
|
注意: これによってすべてのページURLとスタイル・シートが消去されますが、ポータル・イメージは消去されません。 |
特定のユーザーのためのキャッシュを消去するには、次の手順を実行します。
「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。
「キャッシュ」タブをクリックします。
「ユーザーのキャッシュを消去」フィールドに、キャッシュを消去するユーザーの名前を入力します。
|
注意: ユーザー名が不明な場合は、「ユーザーをブラウズ」アイコンをクリックし、表示されたリストから選択します。 |
「適用」または「OK」をクリックして、特定のユーザーのキャッシュを消去します。
|
注意: ユーザーのポータル・プロファイルを編集して、特定のユーザーのためのキャッシュを消去することもできます。 |
無効化ベースのキャッシュでは、アイテムの編集などによりオブジェクトが変更されたことをOracle Web Cacheに通知するメッセージをポータルまたはプロバイダが送信すると、キャッシュ・エントリがパージされます。ただし、キャッシュ・エントリに対する有効期間を設定することもできます。キャッシュ・エントリは、Oracle Web Cacheが無効化メッセージを受け取らない場合でも、この有効期間の最後に達するとパージされます。
|
注意: 無効化ベースのキャッシュのエントリに有効期間を設定するには、ポータル管理者であることが必要です。 |
無効化ベースのキャッシュのエントリに有効期間を設定するには、次の手順を実行します。
「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。
「キャッシュ」タブをクリックします。
「有効期間の最大値」フィールドに、キャッシュ・エントリがパージされるまでにキャッシュ内に留まる最大時間（分単位）を入力します。
|
注意: ここに小さな値を選択すると、キャッシュが頻繁に期限切れになるため、キャッシュのミスが頻繁に発生します。ただし、大きな値を選択すると、コンテンツが失効する場合があります。すべてのポータル・コンテンツがキャッシュできなくなるので、値に0は設定しないでください。 |
「OK」をクリックします。
ページ・グループ、ページ、ページ用のPortalテンプレート、ポートレット・リポジトリ内のポートレット、Portal DBプロバイダおよびPortal DBプロバイダのコンポーネントに対応するキャッシュ・エントリを消去するには、次の手順を実行します。
「ナビゲータ」内で、消去するオブジェクトまでドリルダウンします。
ページ・グループ、ページ、ページ用のPortalテンプレートの場合は、「プロパティ」をクリックし、「アクセス」タブをクリックします。
Portal DBプロバイダとPortal DBプロバイダのコンポーネントの場合は、「アクセス権限の付与」をクリックします。
ポートレットの場合は、「ポートレット・リポジトリ」ページ・グループの横の「ルート・ページの編集」をクリックし、目的のポートレットが含まれたページまでドリルダウンします。ポートレットの横にある「操作」アイコンをクリックし、「アクセス」をクリックします。
「キャッシュの消去」をクリックします。
「OK」をクリックします。
ユーザーが操作を行った結果、キャッシュ無効化キューが大きくなりすぎる場合があります。たとえば、大量のメンバーが属するグループへページに対するセキュリティ権限を繰り返し付与すると、付与するたびに、ユーザーごとにキュー内に弱い無効化が発生します。
弱い無効化は必要ではないこともありますが、Oracle Portalがその必要性を判断できない場合があります。たとえば、ページに対するグループ権限が「表示」から「パーソナライズ(フル)」にアップグレードされても、グループのメンバーが誰もページを表示しない場合、無効化は不要です。ただし、誰がページを表示したかの記録は、Portalにありません。したがって、セキュリティの変更を使用するように構成された弱い無効化が続行します。
ポータル管理者は、ポータル・スキーマの所有者としてSQL*Plusで次の問合せを実行し、キュー内の弱い無効化の回数を確認することができます。
select count(1) from wwutl_cache_inval_msg$ where process_type=2;
ポータル管理者は、ポータル・スキーマの所有者としてSQL*Plusで次の問合せを実行し、キュー内の弱いまたは強い無効化の合計回数を確認することができます。
select count(1) from wwutl_cache_inval_msg$;
この大きくなりすぎている可能性のあるwwutl_cache_inval_msg$表内の行数は、ある程度までは、データベースを実行しているインフラストラクチャの速度に依存します。Oracle PortalはOracle Web Cacheの無効化用ポートと通信するので、通常は50000個のメッセージによって弱い無効化ジョブの速度が低下し、50000個のメッセージをOracle Web Cacheへ送信するとネットワークに負荷がかかります。
弱い無効化が不要であることが判明した場合、ポータル管理者はポータル・スキーマの所有者として、SQL*Plusで次の問合せを実行することができます。
delete from wwutl_cache_inval_msg$ where process_type=2;
この問合せによって、弱い無効化がキューから削除されます。
弱い無効化が必要であってもそれが多すぎる場合、ポータル管理者は、次のコマンドを使用してキャッシュ無効化キューを消去することができます。
truncate table wwutl_cache_inval_msg$;
次にポータル管理者は、Oracle Portalのユーザー・インタフェースを通じてキャッシュ全体を消去する必要があります。この作業の詳細は、第6.7.4.1項「Web Cache全体の消去」を参照してください。
Oracle Portalは、無効化メッセージを使用してキャッシュ内のオブジェクトを期限切れにします。cachjsub.sqlスクリプトを使用すると、無効化ジョブの実行頻度を構成できます。cachjsub.sqlの実行方法の詳細は、第B.1項「cachjsub.sqlを使用した無効化メッセージの処理ジョブの管理」を参照してください。
Oracle Web Cacheは、1つ以上のOracle Portal中間層サーバーのフロントエンドに位置する専用サーバーに配置できます。Oracle Web Cacheは一般的なハードウェアでも十分に機能するため、専用の配置は、ハードウェアの費用の点では負担になりません。一般的には、1 GBのメモリを持つコンピュータを使用することをお薦めします。キャッシュ・サーバーと中間層サーバーのどちらも、高速のネットワーク・カードを使用してサイトのパフォーマンスを確保する必要があります。Oracle Portalでのキャッシュの機能の概要は、第1.3項「Oracle Portalのキャッシュについて」を参照してください。
Webサイトの管理者は、このトポロジを設定するために、Oracle Portal中間層と同じコンピュータにインストールされたOracle Web Cacheを無効にし、専用サーバーに新しいOracle Web Cacheインスタンスを設定する必要があります。図6-6には、Oracle Portalが専用のOracle Web Cacheインスタンスを使用するトポロジを示します。
図6-6 専用のOracle Web Cacheインスタンスを使用するOracle Portal
Oracle Portal中間層の場合、最初にOracleAS Infrastructureをインストールしてから、Portal中間層をインストールします。
OracleAS Infrastructureと中間層をそれぞれのサーバーにインストールした後、J2EE and Web Cache中間層を専用サーバーにインストールします。
次のURLからOracle Web Cacheのスタンドアロン版をインストールすることもできます。http://www.oracle.com/technology/software/products/ias/web_cache/index.html
Oracle Universal Installerは、Oracle Portal中間層のインストール時に、同じコンピュータ上にOracle Portal中間層とOracle Web Cacheを自動的に構成し起動します。未使用のOracle Portal中間層コンピュータにインストールされているOracle Web Cacheを無効にし、別のコンピュータにインストールされている専用のOracle Web Cacheを、Oracle Portal中間層と通信するように構成する必要があります。
Webサイトwww.company.com、ポート番号7777用の専用Oracle Web Cacheを構成するには、次の6つのタスクを実行します。
Oracle Web Cacheを専用サーバー上に正しく構成するには、Oracle Web Cacheが起動され、稼働中であることが必要です。Fusion Middleware Controlのホーム・ページ上でのOracle Web Cacheの起動、停止、再起動、およびそのステータスの表示方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
専用サーバーにOracle Web Cacheを正しく構成するには、Oracle Portal中間層と同じコンピュータにインストールされているOracle Web Cacheのオリジナル・サーバー情報が必要となります。専用のOracle Web Cacheインスタンスからオリジナル・サーバーのプロパティ設定を変更するには、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のタスク2: オリジナル・サーバーの設定の指定に関する項の説明に従ってください。
このタスクはオプションです。Oracle Portal中間層サーバーのリソースを節約するには、『Oracle Fusion Middleware管理者ガイド』の指示に従って、中間層サーバーの未使用のキャッシュを停止します。このキャッシュ・インスタンスは、この配置オプションでは使用されません。
Oracle Portal中間層は、Oracle Web Cacheのリスニング・ポート、invalidatorユーザー名、invalidatorパスワード設定などを認識している必要があります。「ポータル・ワイヤ構成」ページでこれらの設定を変更して、専用のOracle Web Cacheの新しいホスト名とポート番号をOracle Portal中間層に適用する必要があります。
Oracle Enterprise Manager 11gの「システム・コンポーネント」セクションで、「ポータル」をクリックします。Oracle Portalのホーム・ページが表示されます。
「ポータル」を右クリックして、「設定」→「ワイヤ構成」を選択します。
「管理」セクションで「PortalのWebキャッシュ設定」リンクをクリックします。「PortalのWebキャッシュ設定」ページが表示されます。
「ポータル・ワイヤ構成」ページの「ポータル中間層」で、「ホスト」フィールドを正しいホスト名www.company.comに変更し、「リスニング・ポート」フィールドを正しいポート番号7777に変更します。
無効化ホストなど他のWeb Cache設定を確認し、専用サーバー上のキャッシュ情報に一致するようにし、「適用」をクリックします。デフォルトのポートとパスワードの設定の変更方法については、オンライン・ヘルプを参照してください。
専用のOracle Web Cache設定を使用して、仮想ホストのエントリをOracle Portal中間層の一部であるOracle HTTP Serverのhttpd.confファイル内に作成する必要があります。この例では、仮想ホスト名としてwww.company.com、ポート番号として7777（専用のOracle Web Cacheリスニング・ポートと同じ）を設定しています。仮想ホスト名とポート番号は、Oracle Web Cacheで定義されているサイト定義の値と一貫している必要があります。これを行うには、次のタスクを実行します。
次のように仮想ホスト設定を構成します。
Oracle Enterprise Managerにログインします。
Oracle Enterprise Managerホーム・ページで「Web層」を開いて、インスタンスのHTTP Serverを選択します。
「HTTP Server」→「管理」に移動し、「仮想ホスト」を選択します。
「作成」をクリックします。
「仮想ホストの作成」ページで、表6-3にリストされている情報を入力します。
「OK」をクリックします。
|
注意: Oracle HTTP Serverは再起動しません。 |
仮想ホストの構成後、テキスト・エディタを使用してhttpd.conf（ORACLE_INSTANCE\config\OHS\ohs1にある）を開き、次のようにPortおよびRewriteディレクティブをVirtualHostコンテナに追加します（太字の部分）: 構文:
NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://www.company.com:8090
RewriteEngine On
RewriteOptions inherit
</VirtualHost>
Oracle Portalでは、中間層で使用されるOracleAS Infrastructureサービス（Oracle Identity ManagementまたはOracle Metadata Repository）を変更できます。この機能を使用すると、たとえば、中間層およびそのアプリケーションをテスト段階から本稼働用に移行することができます。Oracle Portalで使用されるOracle Metadata Repositoryを変更する場合は、テスト段階のOracle Metadata Repositoryに格納されたアプリケーション固有のデータを、本稼働環境のOracle Metadata Repositoryにも移動する必要があります。本稼働環境で追加のコンピュータが必要な場合は、インフラストラクチャ・サービスの変更が便利です。単一の手順で、中間層および配置済アプリケーションがすでにあるコンピュータを追加します。中間層インスタンスに使用されるインフラストラクチャ・サービスの変更方法は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
|
注意: デフォルトでは、Oracle Portalの中間層は1つのポータル・インスタンスで構成されます。このインスタンスのDAD名とOracle Metadata Repositoryスキーマ名はどちらもportalです。このデフォルトのOracle Portalインスタンスのインフラストラクチャ・サービスは、前述した方法でのみ変更できます。 |
ポータルの構成には、ファイルシステムの中間層およびデータベースのリポジトリの構成が含まれます。クラスタ環境でインストール後の構成が変更された場合は、各ノードで両方のタイプの構成を更新およびレプリケートする必要があります。
クラスタ構成のノードごとに、中間層（ファイル・システム）の構成を更新する必要があります。中間層の構成を更新するには、次のいずれかを実行します。
Oracle Enterprise Manager 11gにログインして、次の手順を実行します。
Portalキャッシュの構成を変更するには、Portalホーム・ページから「ポータル」→「設定」→「ポータル・キャッシュ」を選択して、「ポータル・キャッシュ構成」ページを表示します。必要に応じて変更を行い、「適用」をクリックします。WLSTコマンドを使用する場合は、「WLSTを使用したポータル・キャッシュの構成」を参照してください。
ページ・エンジンの構成を変更するには、Portalホーム・ページから「ポータル」→「設定」→「ページ・エンジン」を選択して、「ページ・エンジン構成」ページを表示します。必要に応じて変更を行い、「適用」をクリックします。WLSTコマンドを使用する場合は、「WLSTを使用したParallel Page Engineの構成」を参照してください。
クラスタ構成ではリポジトリ構成（データベース）を一度だけ更新すれば済みます。クラスタの全ノードで共有されるデータベースのバックエンドPortalスキーマが更新されるためです。ただし、中間層の構成のように、ノードごとにリポジトリの構成を繰り返し実行することもできます。リポジトリの構成を更新するには、Oracle Enterprise Manager 11g Fusion Middleware Controlにログインして、「ポータル」メニューから「設定」→「ワイヤ構成」を選択して、「ポータル・ワイヤ構成」を表示します。必要に応じて変更を行い、「適用」をクリックします。
WLSTコマンドを使用する場合は、「WLSTを使用したOracle Portalの構成」を参照してください。
複数の中間層インストールが実行される場合は、最初に設定されたOracleAS WirelessサービスのURLがOracle Portalインスタンスに格納されます。cfgiasw.plスクリプトを実行することにより、このURLを任意のOracleAS WirelessサービスのURLに変更できます。詳細は、第B.7項「cfgiaswスクリプトを使用したモバイル設定の構成」を参照してください。
|
注意: OracleAS Wirelessサービスとして選択したOracle Application Server中間層でportalRegistrarスクリプトを実行することにより、このURLを任意のOracleAS WirelessサービスのURLに変更できます。OracleAS Wirelessの構成の詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。 |
この項では、Oracle Portalのデフォルトおよびデフォルト以外のスキーマ・パスワードの変更について説明します。Portalスキーマのパスワードを取得する方法の詳細は、第5.6.10項「ポータル・スキーマ・パスワードの取得」を参照してください。Oracle Portalスキーマのパスワードは、RCUを使用してPortalスキーマをロードするときに作成され、Portalスキーマへのログインが必要な一部の操作で必要になります。Portalスキーマのパスワードは、LDAPベースの資格証明ストアに格納されます。LDAPベースのポリシー・ストアは要素serviceInstanceとともに構成ファイルjps-config.xmlで指定されます。次の例は、Oracle Internet Directory LDAPサーバーを使用したLDAPベースの資格証明ストアの仕様を示しています。
<serviceInstance name="someInstance" provider="some_ldap_provider"> ... <property name="credstore.type" value="OID"/> <property name="ldap.url" value="ldap://someURL"/> ... </serviceInstance>
jps-config.xmlファイルのデフォルトの場所は、MW_HOME\user_projects\domains\<DomainName>\config\fmwconfigです。
Oracle Portalスキーマのパスワードを変更するには、次の手順を実行します。
Portalインスタンスに応じて、次のいずれかのオプションを選択します。
Oracle Portalのデフォルトのインスタンス用Oracle Portalスキーマ・パスワードの変更方法の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Metadata Repositoryスキーマ・パスワードの変更に関する項を参照してください。
|
注意: デフォルトでは、Oracle Portalの中間層は1つのポータル・インスタンスで構成されます。このインスタンスのDAD名とOracle Metadata Repositoryスキーマ名はどちらもportalです。このOracle Portalのデフォルトのインスタンス用スキーマ・パスワードの変更方法の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Metadata Repositoryスキーマ・パスワードの変更に関する項を参照してください。 |
次のオプションを使用して、Portalの資格証明を変更できます。
この項では、Oracle Enterprise Managerでドメイン資格証明ストアの資格証明を管理する手順について説明します。
Oracle Enterprise Managerにログインして、「WebLogicドメイン」→「ドメイン名」に移動します。「ドメイン名」を右クリックして「セキュリティ」→「資格証明」を選択し、「資格証明」ページを表示します。
「資格証明ストア・プロバイダ」領域は読取り専用です。この領域を開くと、現在ドメインで使用している資格証明ストア・プロバイダが表示されます。
この読取り専用領域の下にある表で、資格証明を作成、編集および検索できます。
「削除」ボタンを使用していつでも、表で選択した項目（キーまたはマップ）を削除できます。資格証明マップを削除すると、マップにあるすべてのキーが削除されます。同様に、「編集」ボタンを使用して、選択した項目のデータを表示または変更できます。
特定のキー名と一致する資格証明を表示するには、「資格証明キー名」ボックスに一致させる文字列を入力し、右にある青いボタンをクリックします。問合せの結果が表に表示されます。
問合せの結果を確認後に資格証明リストを再表示するには、クラシック・ドメインを右クリックして「セキュリティ」→「資格証明」を選択します。
新しい資格証明マップの作成
新しい資格証明マップを作成するには:
「マップの作成」をクリックして、「マップの作成」ページを表示します。
ダイアログに、作成する資格証明のマップ名を入力します。
「OK」をクリックして「資格証明」ページに戻ります。新しい資格証明マップ名がフォルダ・アイコンとともに表に表示されます。
新しいキーの追加
新しいキーを資格証明マップに追加するには:
「キーの作成」をクリックして、「キーの作成」ページを表示します。
このダイアログで、「マップの選択」プルダウン・リストから新しいキーを挿入するマップを選択し、「キー」テキスト・ボックスにキーを入力して、「タイプ」プルダウン・リストからタイプを選択し（ダイアログの外観は、選択したタイプに応じて変わります）、必要なデータを入力します。
終了したら「OK」をクリックして「資格証明」ページに戻ります。新しいキーが、選択したマップに対応するマップ・アイコンの下に表示されます。
WLSTは資格証明を管理するために、次のオンライン・コマンドをサポートしています。
listCred
listCredコマンドは、特定のマップ名およびキー名を持つ、ドメイン資格証明ストア内の資格証明の属性値リストを返します。このコマンドは、パスワード・タイプの資格証明にカプセル化されたデータのみをリストします。
スクリプト・モードの構文
listCred -map mapName -key keyName
対話モードの構文
listCred(map="mapName", key="keyName")
引数（すべて必須）の意味は次のとおりです。
mapには、マップ名（フォルダ）を指定します。
keyには、キー名を指定します。
例
次のコマンドを呼び出すと、マップ名myMapおよびキー名myKeyを持つ、資格証明内のすべての情報（ユーザー名、パスワード、説明など）が返されます。
listCred -map myMap -key myKey
updateCred
updateCredコマンドは、特定のマップ名およびキー名を持つ、ドメイン資格証明ストア内の資格証明のタイプ、ユーザー名およびパスワードを変更します。このコマンドは、パスワード・タイプの資格証明にカプセル化されたデータのみを更新します。
スクリプト・モードの構文
updateCred -map mapName -key keyName -user userName -password passW [-desc description]
対話モードの構文
updateCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])
引数（大カッコ内の引数はオプション）の意味は次のとおりです。
mapには、資格証明ストアのマップ名（フォルダ）を指定します。
keyには、キー名を指定します。
userには、資格証明ユーザー名を指定します。
passwordには、資格証明パスワードを指定します。
descには、資格証明を説明する文字列を指定します。
例
次のコマンドを呼び出すと、マップ名myMapおよびキー名myKeyを持つ、パスワード資格証明のユーザー名、パスワードおよび説明が更新されます。
updateCred -map myMap
-key myKey
-user myUsr
-password myPassw
-desc "updated usr name and passw to connect to app xyz"
createCred
createCredコマンドは、特定のマップ名、キー名、ユーザー名およびパスワードを持つ新しい資格証明を、ドメイン資格証明ストア内に作成します。このコマンドでは、パスワード・タイプの資格証明のみを作成できます。
スクリプト・モードの構文
createCred -map mapName -key keyName -user userName -password passW [-desc description]
対話モードの構文
createCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])
引数（大カッコ内の引数はオプション）の意味は次のとおりです。
mapには、新しい資格証明のマップ名（フォルダ）を指定します。
keyには、新しい資格証明のキー名を指定します。
userには、新しい資格証明ユーザー名を指定します。
passwordは、新しい資格証明パスワードを指定します。
descには、新しい資格証明を説明する文字列を指定します。
例
次のコマンドを呼び出すと、指定したデータを持つ新しいパスワード資格証明が作成されます。
createCred -map myMap
-key myKey
-user myUsr
-password myPassw
-desc "new passw cred to connect to app xyz"
deleteCred
deleteCredコマンドは、特定のマップ名およびキー名を持つ資格証明を、ドメイン資格証明ストアから削除します。
スクリプト・モードの構文
deleteCred -map mapName -key keyName
対話モードの構文
deleteCred(map="mapName",key="keyName")
例
mapには、マップ名（フォルダ）を指定します。
keyには、キー名を指定します。
例
次のコマンドを呼び出すと、マップ名myMapおよびキー名myKeyの資格証明が削除されます。
deleteCred -map myMap -key myKey
通常、Oracle Portalスキーマのパスワードを変更するにはFusion Middleware Controlを使用しますが、スキーマがOracle Metadata Repositoryの外にあるポータル・インスタンスの場合は、SQL*Plusを使用してポータル・スキーマのパスワードを変更します。
次の手順に従い、データベースで直接スキーマのパスワードを変更します。
SYSDBA権限を持つユーザーとして、データベースに接続します。
次のコマンドを入力します。
SQL> ALTER USER <schema> IDENTIFIED BY <new_password>;
たとえば、PORTAL30スキーマのパスワードをabc123に変更するには、次のように指定します。
SQL> ALTER USER PORTAL30 IDENTIFIED BY abc123;
この後、新しいパスワードでデータベース・アクセス記述子（DAD）を更新する必要があります。次の手順を実行してDADを更新します。次のWLST（オンライン）コマンドを使用して、ポータルDADの属性を更新します。
updatePortalDad (name, [schema], [password], [connect_string], [nls_language])
これによりportal_dads.confファイルが更新され、管理対象サーバー（WLS_PORTAL）が再起動されます。
この項では、次のPortal構成にオプションとしてWLSTを使用する方法について説明します。
|
注意: 構成に変更を加えた後に、管理対象サーバーを再起動する必要があります。 |
次のWLSTオンライン・コマンドを使用して、Portal中間層の構成でPortalリポジトリを更新できます。
構文
setPortalMidtierConfig([dad_name], [ohs_host], [ohs_port], [ohs_protocol], [webcache_host], [webcache_inv_user], [webcache_inv_port], [webcache_inv_passwd])
| 引数 | 定義 |
|---|---|
dad_name |
オプション。データベース・アクセス記述子の名前です。デフォルトのデータベース・アクセス記述子の名前は、portalです。 |
ohs_host |
オプション。Oracle HTTP Serverホスト名です。 |
ohs_port |
オプション。Oracle HTTP Serverポート番号です。 |
ohs_protocol |
オプション。Oracle HTTP Serverプロトコルです。 |
webcache_host |
オプション。無効化メッセージの送信先となるWebCacheホスト名です。 |
webcache_inv_user |
オプション。無効化メッセージの送信に使用するWebCacheユーザー名です。 |
webcache_inv_port |
オプション。無効化メッセージの送信先となるWebCacheポート番号です。 |
webcache_inv_passwd |
オプション。WebCacheの無効化パスワードです。 |
例
次の例では、指定された値に基づいてPortal中間層の構成を更新します。
setPortalMidtierConfig(dad_name='portal1',ohs_host='foo.oracle.com',ohs_port='8090',ohs_protocol=false,webcache_host='foo.oracle.com',webcache_inv_user= 'invalidator',webcache_inv_port='6523',webcache_inv_passwd='invalidator')
WLST（オンライン）コマンドを使用して、ポート・サイト構成の属性をリストできます。
構文
listPortalSiteConfigAttributes ([dad_name])
| 引数 | 定義 |
|---|---|
dad_name |
オプション。データベース・アクセス記述子の名前です。デフォルトのデータベース・アクセス記述子の名前は、portalです。 |
例
次の例では、Portalサイトの構成をリストします。サイト・プロトコルはtrueまたはfalseを指定できます。HTTPはサイト・プロトコルがfalseの場合のプロトコルで、HTTPSはサイト・プロトコルがtrueの場合のプロトコルです。サイト・ホスト名とポート番号もリストしています。
listPortalSiteConfigAttributes ([dad_name]) --------------- SiteConfig --------------- Site Protocol: false Site Host: foo.oracle.com Site Port: 8090
WLST（オンライン）コマンドを使用して、Oracle Internet Directory構成の属性をリストおよび更新できます。
Oracle Internet Directory構成の属性をリストするには、次の手順を実行します。
構文
listPortalOIDConfigAttributes ([dad_name])
| 引数 | 定義 |
|---|---|
dad_name |
オプション。データベース・アクセス記述子の名前です。デフォルトのデータベース・アクセス記述子の名前は、portalです。 |
例
次の例では、Oracle Internet Directoryデータをリストします。Oracle Internet Directoryのホスト名とポート番号が含まれます。
listPortalOIDConfigAttributes(dad_name='portal1')
listPortalOIDConfigAttributes('portal1')
---------------
OidConfig
---------------
OID Port: 13060
OID Host: foo.oracle.com
Oracle Internet Directory構成の属性を更新するには、次の手順を実行します。
構文
setPortalOIDConfig ([dad_name], [host], [port], [protocol], [admin_user], [admin_passwd])
| 引数 | 定義 |
|---|---|
dad_name |
オプション。データベース・アクセス記述子の名前です。デフォルトのデータベース・アクセス記述子の名前は、portalです。 |
host |
オプション。Oracle Internet Directoryホスト名です。 |
port |
オプション。Oracle Internet Directoryポート番号です。 |
protocol |
オプション。Oracle Internet Directoryプロトコルです。 |
admin_user |
オプション。Oracle Internet Directory管理者名です。 |
admin_passwd |
オプション。Oracle Internet Directory管理者のパスワードです。 |
例
次の例では、指定された値に基づいてOID構成を更新します。
setPortalOIDConfig(dad_name='portal1',host='foo.oracle.com',port='13060',protocol=false,admin_user='cn=orcladmin',admin_passwd='oracle1')
