Oracle® Fusion Middleware

Oracle Portal管理者ガイド

11g リリース1 (11.1.1)

B61385-05(原本部品番号:E10239-10)

2013年9月

Oracle Fusion Middleware Oracle Portal管理者ガイド, 11g リリース1 (11.1.1)

B61385-05

Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved.

原本主著者: Swati Thacker

原本協力著者: Savija

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.   As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、他社の商標の可能性があります。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

Oracle Portalの新機能

- Oracle Portal 11g リリース1 (11.1.1)の新機能

- OracleAS Portal 10g リリース2 (10.1.4)の新機能

第I部 概念

1 Oracle Portalのアーキテクチャの理解

- 1.1 Oracle Portalコンポーネントについて

- 1.1.1 中間層コンポーネント

- 1.1.2 インフラストラクチャ・コンポーネント

- 1.2 Oracle Portalのアーキテクチャの理解

- 1.2.1 Oracle Portalと他のコンポーネントとの統合

- 1.2.2 要素を組み合せる方法

- 1.2.2.1 Oracle Portalでページが作成される方法

- 1.2.2.2 Oracle Portalでの通信フロー

- 1.3 Oracle Portalのキャッシュの理解

- 1.3.1 Oracle Web Cacheの理解

- 1.3.2 ポータル・キャッシュの理解

- 1.3.3 Oracle Portalにおけるキャッシュの無効化の理解

- 1.4 WSRPおよびJPSの理解

- 1.5 まとめ

2 Oracle Portalの計画

- 2.1 考慮すべき要点

- 2.1.1 適切なトポロジの選択

- 2.1.2 必要なハードウェア

- 2.1.3 パフォーマンスを最大にする方法

- 2.1.4 ポータルを拡張する方法

- 2.1.5 ポータルの可用性を向上させる方法

- 2.1.6 ポータルを保護する方法

- 2.1.7 ハードウェアとソフトウェアを構成する方法

- 2.1.7.1 単一のコンピュータの使用

- 2.1.7.2 複数のコンピュータの使用

- 2.1.8 構成の機能を向上させる方法

- 2.1.8.1 ロード・バランス

- 2.1.8.2 フェイルオーバーと冗長性

- 2.1.8.3 スケーラビリティ

- 2.2 必要な作業

- 2.2.1 ポータルの計画

- 2.2.2 Oracle Portalのアップグレード

- 2.2.3 インストール前の要件の確認

- 2.2.4 Oracle Fusion Middlewareのインストール

- 2.2.5 インストール後の構成の実行

- 2.2.6 拡張構成の実行

- 2.2.7 Oracle Portalの保護

- 2.2.8 Oracle Portalの監視

- 2.2.9 Oracle Portalのトラブルシューティング

第II部 インストールと基本構成

3 インストール前およびインストール後の作業

- 3.1 インストールの概要

- 3.1.1 WebLogic Serverのインストール

- 3.1.2 インフラストラクチャ・コンポーネントのインストール

- 3.1.3 Oracle Fusion Middleware中間層リリースのインストール

- 3.1.4 インストール・コンポーネントおよびバージョン

- 3.2 インストール後のOracle Portalへのアクセス

- 3.3 インストール時とインストール後のOracle Portalの構成

4 相互運用性シナリオ

5 基本的な構成および管理

- 5.1 Oracle Portalの管理のスタート・ガイド

- 5.1.1 Oracle Portalの「管理」タブの使用

- 5.1.2 その他の管理ツールの使用

- 5.1.2.1 Oracle Enterprise Manager 11g Fusion Middleware Control

- 5.1.2.2 WebLogic Scripting Tool (WLST)コマンドライン・ユーティリティ

- 5.1.2.3 Portalのインストールと構成のスクリプト

- 5.2 Oracle Portalに関する情報の検索

- 5.2.1 ブラウザでのOracle Portalへのアクセス

- 5.2.2 Oracle Portalのリリース番号の検索

- 5.3 基本的なページ管理の実行

- 5.3.1 デフォルト・ホームページの設定

- 5.3.1.1 システムのデフォルト・ホームページの設定

- 5.3.1.2 グループのデフォルト・ホームページの設定

- 5.3.1.3 ユーザーのデフォルト・ホームページの設定

- 5.3.2 システムのデフォルト・スタイルの設定

- 5.3.3 個人用ページの作成

- 5.3.3.1 新しいユーザーの個人用ページの自動作成

- 5.3.3.2 既存ユーザーの個人用ページの作成

- 5.3.4 アップロード・ファイルに割り当てる総容量の設定

- 5.3.5 アップロード・ファイルの最大ファイル・サイズの設定

- 5.3.6 ページ・グループ割当ての変更

- 5.3.7 電子メール(SMTP)ホストの指定

- 5.3.8 エラー・メッセージ・ページの指定

- 5.3.9 エラー・レポート・スタイルの指定

- 5.3.10 認証されていないユーザー用のデフォルト・ページの設定

- 5.3.11 ページ用のデフォルトのDOCTYPEの指定

- 5.3.12 状況依存ヘルプ・リンクの削除

- 5.4 自己登録の構成

- 5.5 承認のためのOracle BPELプロセス定義の設定

- 5.5.1 BPELのワークフローとポータルのワークフローの同期化

- 5.5.1.1 コールバックWebサービスの配置

- 5.5.1.2 BPELのポータルの構成

- 5.5.2 BPELビジネス・プロセスのポータルの保護

- 5.5.2.1 BPELサーバーへのアウトバウンドSSLの構成

- 5.5.2.2 ポータルへのBPELサーバー・コールバック

- 5.5.3 新規BPELプロセス定義の作成

- 5.5.4 既存のBPELプロセス定義の編集

- 5.5.5 既存のBPELプロセス定義の削除

- 5.5.6 Oracle Portalのメッセージ・スキーマ

- 5.5.7 BPELコールバックWebサービス・プロキシ

- 5.6 基本的なポータル管理の実行

- 5.6.1 Oracle Portalインスタンスの完全なURLの簡略化

- 5.6.2 Oracle Portalホーム・ページを使用するためのOracle HTTP Serverの構成

- 5.6.3 Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動

- 5.6.4 Fusion Middleware Controlを使用したポータルDADの構成

- 5.6.5 WLSTを使用したポータルDADの構成

- 5.6.5.1 ポータルDADの作成

- 5.6.5.2 ポータルDADの更新

- 5.6.5.3 ポータルDADの削除

- 5.6.5.4 DADのリスト

- 5.6.6 Fusion Middleware Controlを使用したポータル・キャッシュの構成

- 5.6.7 WLSTを使用したポータル・キャッシュの構成

- 5.6.8 ポータル・キャッシュの消去

- 5.6.9 PortalのParallel Page Engineの構成

- 5.6.9.1 PPE構成パラメータの設定

- 5.6.9.2 WLSTを使用したParallel Page Engineの構成

- 5.6.10 Portalスキーマのパスワードの取得

- 5.6.11 カスタム・イメージ・ディレクトリの使用

- 5.7 Oracle Portalでのモバイル・サポートの構成

- 5.7.1 Oracle Application Server Wirelessのインストール

- 5.7.2 Oracle Portalモバイル・アクセス用のOracleAS Single Sign-Onのパッチ適用

- 5.7.3 Oracle Portalでのモバイル設定の構成

- 5.7.3.1 モバイル・アクセスの有効化

- 5.7.3.2 モバイル・ホーム・ページの構成

- 5.7.3.3 モバイル・バナー・リンクでのページ・タイトルの表示

- 5.7.3.4 PDAでの拡張ページ・レイアウトの表示

- 5.7.3.5 モバイル・レスポンスのロギング

- 5.7.4 モバイル・アクセスの構成

- 5.7.4.1 Oracle Portalホーム・ページURL参照の構成

- 5.7.4.2 OracleAS Wireless PortalサービスURL参照の構成

- 5.7.5 キャッシュ・キーのモバイル・デバイス・コンポーネントの変更

- 5.8 ユーザー、グループおよびパスワードの管理

- 5.9 ブラウザ設定の構成

- 5.10 言語サポートの構成

- 5.10.1 Oracle Portalインストール後の言語のインストール

- 5.10.2 地域の使用の有効化

- 5.11 Oracle Portal WebDAVの構成

- 5.11.1 基本的なWebDAV構成の実行

- 5.11.2 WebDAVクライアントの設定

- 5.11.3 WebDAVクライアントとSSL

- 5.11.4 OraDAVドライバのバージョンの確認

- 5.11.5 OraDAVドライバのバージョンの確認

- 5.11.6 エラーの表示

- 5.12 リソース・プロキシの構成

第III部 拡張構成

6 拡張構成

- 6.1 Oracle Fusion Middlewareリスニング・ポートの変更

- 6.2 SSLの構成

- 6.3 ロード・バランシング・ルーターを使用する複数の中間層の構成 Router

- 6.3.1 ステップ1: 単一のPortal中間層(M1)のインストール

- 6.3.2 ステップ2: LBRを通じてアクセスされるM1でのOracle Portalの構成

- 6.3.3 ステップ3: Oracle Portalが起動し実行中であることの確認

- 6.3.4 ステップ4: 新しいポータル(M2)のインストール

- 6.3.5 ステップ5: 既存のポータルを実行するための新しい中間層(M2)の構成

- 6.3.6 ステップ6: PortalツールとWebプロバイダの構成(オプション)

- 6.3.7 ステップ7: Oracle Web Cacheでのセッション・バインドの有効化

- 6.3.8 ステップ8: 構成完了の確認

- 6.4 仮想ホストの構成

- 6.4.1 仮想ホストの作成

- 6.4.1.1 www.xyz.comの仮想ホストの作成

- 6.4.1.2 www.abc.comの仮想ホストの作成

- 6.4.1.3 httpd.confファイルの確認

- 6.4.1.4 仮想ホストが正しく構成されたことの確認

- 6.4.2 Oracle Web Cacheの構成

- 6.4.3 Oracle PortalのOracleAS Single Sign-Onへの登録

- 6.4.4 構成の確認

- 6.4.5 OracleAS Single Sign-On 10gのホスト名の変更に応じたPortalの再構成

- 6.5 プロキシ・サーバーを使用するためのOracle Portalの構成

- 6.6 リバース・プロキシ・サーバーを使用するためのOracle Portalの構成

- 6.7 Oracle Web CacheにキャッシュされたOracle Portalコンテンツの管理

- 6.7.1 Oracle Web Cacheの管理

- 6.7.2 Oracle Enterprise Managerを使用したPortalのWeb Cache設定の構成

- 6.7.3 WLSTを使用したPortalのWeb Cache設定の構成

- 6.7.3.1 属性のリスト

- 6.7.3.2 属性の更新

- 6.7.4 Oracle Web Cacheにキャッシュされたポータル・コンテンツの管理

- 6.7.4.1 Web Cache全体の消去

- 6.7.4.2 特定ユーザーのキャッシュの消去

- 6.7.4.3 無効化ベースのキャッシュの有効期間の設定

- 6.7.4.4 特定ポータル・オブジェクトのキャッシュの消去

- 6.7.5 SQL*Plusによるキャッシュ無効化キューの消去

- 6.7.6 無効化メッセージの処理ジョブの管理

- 6.8 専用のOracle Web Cacheインスタンスを使用するためのOracle Portalの構成

- 6.8.1 インストールの前提条件と要件の理解

- 6.8.2 専用のOracle Web Cacheの構成

- 6.8.2.1 タスク1: 専用サーバー上でOracle Web Cacheが稼働していることの確認

- 6.8.2.2 タスク2: 専用サーバー上でのOracle Web Cacheの構成

- 6.8.2.3 タスク3: 中間層サーバーの未使用のOracle Web Cacheの停止

- 6.8.2.4 タスク4: Oracle Web Cache設定を使用するOracle Portal中間層の構成

- 6.8.2.5 タスク5: Oracle HTTP Serverの仮想ホスト設定の構成

- 6.8.2.6 タスク6: Oracle HTTP Serverパートナ・アプリケーションの再登録

- 6.9 インストール後のクラスタ環境の構成

- 6.9.1 中間層の構成

- 6.9.2 リポジトリの構成

- 6.10 OracleAS Wirelessの構成

- 6.11 Oracle Portalスキーマ・パスワードの変更

- 6.11.1 デフォルトのOracle Portalインスタンスのスキーマ・パスワードの変更

- 6.11.2 Portalの資格証明の変更

- 6.11.2.1 Oracle Enterprise Managerを使用したPortalの資格証明の管理

- 6.11.2.2 WLSTコマンドを使用したPortalの資格証明の管理

- 6.11.3 デフォルトでないOracle Portalインスタンスのスキーマ・パスワードの変更

- 6.12 WLSTを使用したOracle Portalの構成

- 6.12.1 Portal中間層の構成

- 6.12.2 Portalサイト属性の構成

- 6.12.3 PortalのOracle Internet Directory属性の構成

- 6.12.3.1 属性のリスト

- 6.12.3.2 属性の更新

7 Oracle Portalの保護

- 7.1 Oracle Portalのセキュリティについて

- 7.1.1 Oracle Portalのセキュリティ・モデル

- 7.1.2 ユーザーのクラスとその権限

- 7.1.2.1 Oracle Portalのデフォルトの生成済ユーザー・アカウント

- 7.1.2.2 Oracle Portalのデフォルトの生成済グループ

- 7.1.2.3 Oracle Portalのデフォルト・スキーマ

- 7.1.3 保護されているリソース

- 7.1.3.1 グローバル権限

- 7.1.3.2 オブジェクト権限

- 7.1.3.3 新規プロバイダへの権限付与

- 7.1.3.4 Webプロバイダとプロバイダ・グループを編集する権限

- 7.1.3.5 WSRPプロデューサを作成および編集する権限

- 7.1.3.6 ポートレット・リポジトリ内のURLおよびXMLポートレットを編集するための権限

- 7.1.4 認可とアクセスの適用

- 7.1.5 認可の変更

- 7.1.5.1 セキュアなネットワーク認識のAuthorization Modifier

- 7.1.5.2 デフォルトのAuthorization Modifier

- 7.1.5.3 ページの表示と編集に関するAuthorization Modifier

- 7.1.5.4 Authorization Modifiersで使用する必要なページ属性の定義

- 7.1.6 Oracle Fusion Middlewareのセキュリティ・サービスの利用

- 7.1.7 Oracle Identity Managementインフラストラクチャの利用

- 7.1.7.1 Oracle PortalとOracleAS Single Sign-Onの関係

- 7.1.7.2 Oracle PortalとOracle Access Managerの関係

- 7.1.7.3 Oracle PortalとOracle Internet Directoryの関係

- 7.1.7.4 Oracle PortalとOracle Directory Integration Platformの関係

- 7.1.7.5 Oracle PortalとOracle Delegated Administration Servicesの関係

- 7.1.7.6 「ユーザー」ポートレット

- 7.1.7.7 「ポータル・ユーザー・プロファイル」ポートレット

- 7.1.7.8 「グループ」ポートレット

- 7.1.7.9 「ポータル・グループ・プロファイル」ポートレット

- 7.1.7.10 Oracle Delegated Administration Servicesのパブリック・ロール

- 7.1.8 動的グループの構成

- 7.1.8.1 動的グループの定義

- 7.1.8.2 動的グループの使用によるページの保護

- 7.1.9 ポートレットのセキュリティ

- 7.1.9.1 認証

- 7.1.9.2 認可

- 7.1.9.3 通信セキュリティ

- 7.1.9.4 アクセス制御リスト

- 7.1.9.5 Oracle Portalのサーバー認証

- 7.1.9.6 Portalツールの「プロバイダ構成」ページの保護

- 7.1.9.7 シングル・サインオン

- 7.1.9.8 プログラムによるポートレットのセキュリティ

- 7.1.9.9 メッセージ認証

- 7.1.9.10 HTTPS通信

- 7.1.9.11 SSLの構成

- 7.1.10 Web Services Remote Portletsへのアクセスの保護

- 7.1.10.1 キーストアの設定

- 7.1.10.2 プロデューサの構成

- 7.1.11 「OmniPortlet」と「シンプル・パラメータ・フォーム」の保護

- 7.1.12 Webクリッピング・プロバイダの保護

- 7.1.12.1 信頼できるサイトの証明書の追加

- 7.1.12.2 Webクリッピング・プロバイダのOracle Advanced Securityの構成

- 7.1.13 連携型Portalアダプタの保護

- 7.1.14 OraDAVの保護

- 7.1.14.1 セッションCookieの有効期限

- 7.1.14.2 SSLとOraDAV

- 7.1.14.3 MOD_ORADAV.CONFのパスワードの暗号化

- 7.2 Oracle PortalのOracle Fusion Middleware Security Frameworkの構成

- 7.2.1 Oracle PortalのFusion Middleware Security Frameworkオプションの構成

- 7.2.2 Oracle PortalのOracle Identity Managementオプションの構成

- 7.2.2.1 適切な命名属性とニックネーム属性の設定

- 7.2.2.2 Oracle Portalインストーラのロールの定義

- 7.3 Oracle Portalのセキュリティの構成

- 7.3.1 Oracle Portalのセキュリティ・オプションの構成

- 7.3.1.1 「グローバル設定」ページの設定の変更

- 7.3.1.2 ロール・ベースのアクセス制御の適用

- 7.3.1.3 プロバイダのメッセージ認証の構成

- 7.3.2 Oracle Fusion Middleware Security Frameworkのオプションの構成

- 7.3.2.1 Oracle PortalのSSLの構成

- 7.3.2.2 Oracle Internet Directoryへの接続の保護(オプション)

- 7.3.2.3 インストール後のセキュリティのチェックリスト

- 7.3.3 データベースのセキュリティのためのOracle Portalオプションの構成

8 Oracle Portalの監視と管理

- 8.1 Oracle Enterprise Manager 11g Fusion Middleware Controlの使用

- 8.2 Fusion Middleware Controlを使用したOracle Portalの監視と管理

- 8.2.1 Portalホーム・ページの概要

- 8.2.1.1 「ページ・レスポンス時間」ポートレット

- 8.2.1.2 「ページ・レスポンス・コード統計」ポートレット

- 8.2.1.3 「ポピュラーなプロデューサ」ポートレット

- 8.2.1.4 「関連コンポーネント」ポートレット

- 8.2.1.5 「プロデューサ」ポートレット

- 8.2.1.6 「リソース・センター」ポートレット

- 8.2.1.7 「ページ・エンジン統計」ポートレット

- 8.2.2 Oracleホーム・ページからの管理と監視

- 8.2.2.1 「パフォーマンス・メトリック」ページ

- 8.2.2.2 「パフォーマンス・サマリー」ページ

- 8.2.2.3 「データベース・アクセス記述子の構成」ページ

- 8.2.2.4 「ポータル・キャッシュ構成」ページ

- 8.2.2.5 「ページ・エンジン構成」ページ

- 8.2.2.6 「ポータル・ワイヤ構成」ページ

- 8.2.2.7 ログ

- 8.2.3 「トポロジ」タブ

- 8.3 Oracle Portal動作レポートの表示

- 8.3.1 ログに記録されるイベント

- 8.3.2 ログに記録されるイベントの選択

- 8.3.3 動作ログ・ビュー

- 8.3.4 動作ログのビューの外部的なアクセス

- 8.4 Oracle Fusion Middlewareポート情報の表示

- 8.5 Oracle Enterprise Managerの管理ロールの定義

- 8.6 Oracle Fusion MiddlewareのシステムMBeanブラウザについて

- 8.6.1 Oracle Fusion MiddlewareのシステムMBeanブラウザはいつ使用すればよいか

- 8.6.2 Portal構成MBeanについて

9 Oracle Portal用のイントラネットおよびインターネットの構成

- 9.1 Oracle Portalの専用イントラネットおよび専用インターネットの構成

- 9.1.1 外部中間層のインストールと構成

- 9.1.2 APPHOST3への最初の内部中間層のインストール

- 9.1.3 Oracle Web Cacheの無効化専用クラスタの構成

- 9.1.3.1 Oracle Web Cacheの無効化専用クラスタのネットワーク環境の準備

- 9.1.3.2 キャッシュの構成

- 9.1.3.3 ファイアウォールを経由した外部から内部への通信の無効化

- 9.1.4 APPHOST3の最初の内部中間層のロード・バランシング・ルーター用の構成

- 9.1.5 パートナ・アプリケーションとしての内部中間層の登録

- 9.1.6 WebLogicにおけるホスト・アサーションの変更

- 9.1.6.1 構成の検証

- 9.1.7 APPHOST4への2番目の内部中間層のインストール

- 9.1.8 Oracle Web Cacheの無効化専用クラスタの構成

- 9.1.9 APPHOST4の2番目の内部中間層のロード・バランシング・ルーター用の構成

- 9.1.10 Web Cacheの構成

- 9.1.11 Oracle Metadata RepositoryのOracle Portalスキーマの構成

- 9.1.12 構成完了後の検証

- 9.2 Oracle Portal 10gのイントラネットおよびインターネット設定の11gへのアップグレード

- 9.2.1 外部中間層のインストールとアップグレード

- 9.2.2 外部中間層のアップグレード後の構成

- 9.2.3 APPHOST3への最初の内部中間層のインストールとアップグレード

- 9.2.4 APPHOST3の最初の内部中間層のアップグレード後の構成

- 9.2.5 APPHOST4への2番目の中間層のインストールとアップグレード

- 9.2.6 APPHOST4の2番目の内部中間層のアップグレード後の構成

- 9.2.7 構成の検証

10 Oracle Portalの検索機能の構成

- 10.1 Oracle Portalの検索オプション

- 10.1.1 Oracle Portalの検索

- 10.1.2 Oracle Secure Enterprise Search

- 10.1.3 デフォルトの検索機能

- 10.1.4 使用する検索オプションの決定

- 10.1.5 Oracle Secure Enterprise SearchとOracle Portal検索の違い

- 10.2 Oracle Portalの検索オプションの構成

- 10.2.1 Oracle Portal検索ポートレットの構成

- 10.2.1.1 検索結果ページの選択

- 10.2.1.2 ページに表示する検索結果の数の制限

- 10.2.1.3 「拡張検索」リンクの選択(「基本検索」および「カスタム検索」ポートレット)

- 10.2.1.4 インターネット検索エンジンの選択(「拡張検索」および「カスタム検索」ポートレット)

- 10.2.2 Oracle PortalでのOracle Textオプションの検索

- 10.2.2.1 Oracle PortalでのOracle Textの有効化と無効化

- 10.2.2.2 Oracle Text検索結果オプションの設定

- 10.2.2.3 Oracle TextのベースURLの設定

- 10.2.2.4 Oracle Textのプロキシ設定の構成

- 10.2.3 Oracle PortalでのOracle Secure Enterprise Searchオプションの構成

- 10.3 Oracle Text

- 10.3.1 Oracle Textを有効または無効にした場合のOracle Portal検索の理解

- 10.3.1.1 Oracle Textを無効にした検索

- 10.3.1.2 Oracle Textを有効にした検索

- 10.3.2 Oracle Textの前提条件

- 10.3.3 Oracle Text索引

- 10.3.3.1 Oracle Text索引の概要

- 10.3.3.2 Oracle Text索引の設定

- 10.3.3.3 データストア・プロシージャ

- 10.3.3.4 Oracle PortalスキーマへのCTXAPPロールの付与

- 10.3.3.5 多言語機能(マルチレクサー)

- 10.3.3.6 STEM検索

- 10.3.3.7 AUTO_FILTERパフォーマンスの最大化

- 10.3.4 Oracle Text索引の作成および削除

- 10.3.4.1 ctxcrind.sqlを使用したすべてのOracle Text索引の作成

- 10.3.4.2 1つのOracle Text索引の作成

- 10.3.4.3 ctxdrind.sqlを使用したすべてのOracle Text索引の削除

- 10.3.4.4 1つのOracle Text索引の削除

- 10.3.5 Oracle Text索引の管理

- 10.3.5.1 Oracle Text索引の同期化

- 10.3.5.2 Oracle Text索引のコミット時の同期化

- 10.3.5.3 すべてのOracle Text索引の手動による同期化

- 10.3.5.4 索引の同期化のスケジューリング

- 10.3.5.5 Oracle Text索引の同期化の頻度の決定

- 10.3.5.6 すべての索引のコンテンツの同期化

- 10.3.5.7 Oracle Text索引の最適化

- 10.3.5.8 索引の最適化のスケジューリング

- 10.3.5.9 最適化の間隔の選択

- 10.3.6 URLコンテンツの索引作成と検索

- 10.3.6.1 相対URL

- 10.3.6.2 サポートされていないURL

- 10.3.6.3 サポートされているURL

- 10.3.6.4 URLの索引のプロキシ設定

- 10.3.7 ドキュメント索引およびURL索引の作成の無効化

- 10.3.8 Oracle Text索引のステータスの表示

- 10.3.9 Oracle Textの索引作成処理の監視

- 10.3.9.1 start_logを使用した索引処理の監視

- 10.3.9.2 logcrind.sqlを使用した索引作成の監視

- 10.3.10 索引作成エラーの表示

- 10.3.11 索引作成エラーのOracle Portal内のオブジェクトへの変換

- 10.3.11.1 アイテムの索引作成エラー

- 10.3.11.2 ページの索引作成エラー

- 10.3.11.3 カテゴリ索引エラー

- 10.3.11.4 パースペクティブの索引作成のエラー

- 10.3.11.5 ドキュメント索引エラー

- 10.3.11.6 URL索引エラー

- 10.3.12 一般的な索引作成エラー

- 10.3.12.1 一般的なドキュメント索引作成エラー

- 10.3.12.2 一般的なURL索引作成エラー

- 10.3.13 ハングまたはクラッシュする索引作成への対処方法

- 10.3.13.1 索引処理がハングしているかどうかの特定

- 10.3.13.2 索引のハングおよびクラッシュの防止

- 10.4 Oracle Secure Enterprise Search

- 10.4.1 Oracle Secure Enterprise Searchの概要

- 10.4.1.1 Oracle Secure Enterprise Searchのサンプル問合せアプリケーションについて

- 10.4.1.2 Oracle Secure Enterprise Searchの構成について

- 10.4.2 Oracle Secure Enterprise Searchの「セキュア」ポートレット

11 Oracle Portalのパフォーマンスの調整

- 11.1 サーバー・プロセス数の設定

- 11.2 アイドル・プロセス数の設定

- 11.3 PPEフェッチャ数の設定

- 11.4 Oracle HTTP Serverの調整

- 11.5 ファイル・システム・キャッシュの調整によるキャッシュのパフォーマンス向上

- 11.6 Oracle Net Servicesの調整

12 コンテンツのエクスポートとインポート

- 12.1 Oracle Portalのエクスポートまたはインポートの概要

- 12.2 始める前に

- 12.2.1 システム要件

- 12.2.2 その他の検討事項

- 12.2.3 コンテンツをエクスポートおよびインポートするための権限

- 12.3 エクスポートおよびインポート機能の使用例

- 12.3.1 事例1: 開発インスタンスと本稼働インスタンス間のインポートとエクスポート

- 12.3.2 事例2: 複数のポータル・インスタンス間での同一コンテンツの配置

- 12.3.3 事例3: 複数のソースのコンテンツ統合

- 12.4 Oracle Portalでのエクスポート

- 12.4.1 Oracle Portalのエクスポート - 推奨方法

- 12.4.1.1 Oracle Portalのエクスポート機能

- 12.4.1.2 トランスポート・セットの管理方法

- 12.4.2 Oracle Portalのエクスポート - 別の方法

- 12.5 トランスポート・セットの取得サービス

- 12.5.1 ソース・ポータルの登録

- 12.5.2 ターゲット・システムへのデータの移動

- 12.6 Oracle Portalでのインポート

- 12.6.1 Oracle Portalのインポート - 推奨方法

- 12.6.1.1 データベース・リンクの作成

- 12.6.1.2 データのインポート

- 12.6.1.3 トランスポート・セットの管理方法(インポート)

- 12.7 Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトの使用

- 12.7.1 コマンドライン・スクリプトのダウンロード

- 12.7.2 スクリプトの実行によるエクスポート・ダンプ・ファイルの作成

- 12.7.3 ターゲット・システムへのトランスポート・セット表のインポート

- 12.8 移行後のオブジェクトの動作

- 12.8.1 Oracle Portalオブジェクトの動作

- 12.8.1.1 ページ・グループ

- 12.8.1.2 属性

- 12.8.1.3 承認

- 12.8.1.4 アイテム

- 12.8.1.5 ページ

- 12.8.1.6 リージョン

- 12.8.1.7 Portalテンプレート

- 12.8.1.8 HTMLテンプレート

- 12.8.1.9 カテゴリ

- 12.8.1.10 パースペクティブ

- 12.8.1.11 ナビゲーション・ページ

- 12.8.1.12 スタイル

- 12.8.1.13 項目タイプ

- 12.8.1.14 ページ・タイプ

- 12.8.2 子オブジェクトのインポート動作

- 12.8.3 DBプロバイダ・オブジェクトの動作

- 12.8.3.1 生成済DBプロバイダ

- 12.8.3.2 Portal DBプロバイダ

- 12.8.3.3 Portal DBプロバイダのコンポーネント

- 12.8.3.4 共有コンポーネント

- 12.8.3.5 登録済データベース・プロバイダ

- 12.8.4 Portal DBプロバイダ・レポートのオブジェクト・タイプの動作

- 12.8.5 Webプロバイダの動作

- 12.8.5.1 OmniPortlet

- 12.8.5.2 Webクリッピング・プロバイダ、WSRPプロデューサとその他のWebプロバイダ

- 12.8.6 共有ポートレット・インスタンスの動作

- 12.9 エクスポートおよびインポート時の推奨方法

- 12.9.1 レプリケートされたタブの命名規則

- 12.9.2 ページ・グループおよびコンポーネントの移行

- 12.9.3 Portal DBプロバイダとコンポーネントの移行

- 12.9.4 検索コンポーネントの移行

- 12.9.4.1 「基本検索」および「拡張検索」ポートレット

- 12.9.4.2 「カスタム検索」ポートレット

- 12.9.5 アップグレードされたOracle Portalインスタンス間でのコンテンツの移行

- 12.9.6 ホスト環境でのエクスポートとインポート

- 12.9.7 Oracle Text索引の同期をオフにしたデータのインポート

- 12.9.8 ユーザーおよびグループの移行

13 連携型Portalアダプタの使用

- 13.1 連携型Portalアダプタについて

- 13.1.1 概要

- 13.1.2 データベース・プロバイダとWebプロバイダの違い

- 13.1.3 連携型Portalアダプタの使用

- 13.1.4 セキュリティの問題

- 13.1.5 連携型Portalアダプタに関連するポートレットの変更

- 13.2 連携型Portalアダプタを使用する環境の設定

- 13.2.1 PlsqlSessionCookieName値の確認

- 13.2.2 HMACを使用した連携型Portalアダプタ・ユーザー認証

- 13.2.3 Cookieドメインの設定

- 13.2.4 OracleAS Single Sign-OnおよびOracle Internet Directoryサーバーの共有

- 13.3 連携型Portalアダプタを使用したプロバイダの登録

- 13.4 連携型Portalアダプタを使用したカスタム・ポートレットの作成

- 13.4.1 相対リンク

- 13.4.2 パーソナライズ

- 13.5 連携型Portalアダプタのトラブルシューティング

第IV部 付録

A Oracle Fusion Middleware構成ファイルの使用

- A.1 Oracle HTTP Serverの構成ファイル(httpd.conf)

- A.2 DAD構成ファイル(portal_dads.conf)

- A.3 Oracle Databaseの接続構成

- A.4 Web Cache構成ファイル

- A.5 OracleAS Single Sign-Onのパートナ・アプリケーション表

- A.6 ローカルのHOSTSファイル

B Oracle Portalのインストールおよび構成スクリプトの使用

- B.1 cachjsub.sqlを使用した無効化メッセージの処理ジョブの管理

- B.2 secupoid.sqlスクリプトの使用

- B.3 ポータル・セッションCookieの構成

- B.3.1 Cookieの名前の構成

- B.3.2 Cookieの適用範囲の構成

- B.3.3 Cookieの保護

- B.4 セッション・クリーン・アップ・ジョブの管理

- B.5 実行時間とキャッシュの統計

- B.5.1 ポートレット統計

- B.5.1.1 ポートレットの実行時間情報

- B.5.1.2 ポートレットのキャッシュ情報

- B.5.2 ページ統計

- B.5.3 その他のサマリー統計

- B.6 cfgiaswスクリプトを使用したモバイルの構成

- B.7 cfgxodnc.plスクリプトを使用したキャッシュ・キーのモバイル・デバイス・コンポーネントの変更

- B.7.1 portal_dads.confファイルへのPlsqlCGIEnvironmentListパラメータの追加

- B.7.2 cfgxodnc.plスクリプトの実行

- B.7.3 PPE構成ファイルへのuseDeviceNameCacheKeysパラメータの追加

- B.7.4 キャッシュされたデータの消去

- B.8 カテゴリおよびパースペクティブ・スクリプトの使用

- B.9 PDK-Javaのプリファレンス・ストア移行/アップグレード・ユーティリティの使用

- B.10 スキーマ検証ユーティリティの使用

- B.10.1 Oracle Portalのエクスポートおよびインポートでのスキーマ検証ユーティリティの使用

- B.10.2 スキーマ検証ユーティリティのスタンドアロンでの使用

C JavaServer PagesとOracle Portalとの統合

- C.1 JavaServer Pages構成ファイルの使用

- C.1.1 JavaServer Pages構成ファイルの内容

- C.1.1.1 <jps>タグ

- C.1.1.2 <portal>タグ

- C.1.1.3 <database>タグ

- C.1.1.4 <url>タグ

- C.1.1.5 <cookie>タグ

- C.1.1.6 <pageGroups>タグ

- C.1.1.7 <pageGroup>タグ

- C.1.2 JavaServer Pages構成ファイルの例

- C.1.3 JavaServer Pages構成ファイルの場所

- C.1.4 外部JavaServer Pagesのログイン

- C.2 外部通信のためのJAZNファイルの設定

- C.2.1 mod_ossoの設定

- C.2.2 JAZNのLDAPによる設定

D wwv_context APIの使用

- D.1 プロシージャ

- D.1.1 add_attribute_section

- D.1.2 commit_sync

- D.1.3 create_index

- D.1.4 create_missing_indexes

- D.1.5 create_prefs

- D.1.6 createindex

- D.1.7 drop_all_indexes

- D.1.8 drop_index

- D.1.9 drop_invalid_indexes

- D.1.10 drop_prefs

- D.1.11 dropindex

- D.1.12 optimize

- D.1.13 set_parallel_degree

- D.1.14 set_sync_memory

- D.1.15 set_use_doc_index

- D.1.16 set_use_url_index

- D.1.17 sync

- D.1.18 touch_index(p_indexes wwsbr_array)

- D.1.19 touch_index

- D.1.20 update_index_prefs

- D.2 ファンクション

- D.2.1 checkindex

- D.2.2 doc_index

- D.2.3 get_commit_sync

- D.2.4 get_parallel_degree

- D.2.5 get_sync_memory

- D.2.6 get_use_doc_index

- D.2.7 get_use_url_index

- D.2.8 valid_doc_index

- D.2.9 valid_url_index

- D.2.10 url_index

- D.3 定数

- D.3.1 索引名の定数

- D.3.2 Oracle TextのAUTO_FILTER書式定数

- D.3.3 Oracle Textのジョブ定数

- D.3.4 索引作成に適さないURLの定数

- D.4 例外

E Portalツールのプロバイダの構成

- E.1 Webクリッピングの構成

- E.1.1 Webクリッピング・リポジトリの構成

- E.1.2 Webクリッピング・プロバイダの登録(PDK専用)

- E.1.3 HTTPまたはHTTPSのプロキシ設定の構成

- E.1.3.1 承認されていない外部Webサイトからのコンテンツのクリッピングの制限

- E.1.4 キャッシュの構成

- E.1.4.1 キャッシュの構成

- E.2 OmniPortletの構成

- E.2.1 OmniPortletプロバイダの構成

- E.2.1.1 HTTPまたはHTTPSのプロキシ設定の構成

- E.2.1.2 保護データ・リポジトリの構成(PDK専用)

- E.2.1.3 キャッシュの構成(PDK専用)

- E.2.1.4 HTTPS URLにアクセスするためのOmniPortletの構成

- E.2.2 オプションのOmniPortlet構成の実行

- E.2.3 OmniPortletプロバイダの登録(PDK専用)

- E.2.4 DataDirect JDBCドライバを使用して他のリレーショナル・データベースにアクセスするOmniPortletプロバイダの構成

- E.2.4.1 DataDirect JDBCドライバのインストール

- E.2.4.2 OmniPortletへのDataDirectドライバの登録

F 仮想プライベート・ポータルの設定と管理

- F.1 ホスティングの概要

- F.1.1 ホスティングを使用する理由

- F.1.2 既知の制約

- F.2 仮想プライベート・ポータルで実行する手順の概要

- F.2.1 ホスティングの有効化

- F.2.2 ユーザーおよびグループの設定

- F.2.3 サブスクライバの追加

- F.2.4 サブスクライバの削除

- F.2.5 拡張機能

- F.2.6 インストール前のチェックリスト

- F.2.7 Oracle Directory Managerの使用

- F.3 アウト・オブ・ボックスのポータルでのホスティングの有効化

- F.4 ASPのユーザーおよびグループ

- F.4.1 ASPユーザーおよびグループの設定

- F.4.2 制限事項

- F.5 サブスクライバの追加

- F.6 仮想プライベート・ポータルでの詳細操作

- F.6.1 ASPユーザーおよびグループの管理

- F.6.1.1 パスワード同期

- F.6.1.2 デルタ(構造の変更)同期

- F.6.1.3 完全同期

- F.6.2 サブスクライバの削除

- F.6.3 仮想プライベート・ポータル内でのWebDAVの使用

- F.6.4 仮想プライベート・ポータル用のDirectory Integration Platformの設定

- F.6.5 部分的に準備(下処理)されたサブスクライバ

- F.7 制限事項

- F.7.1 スクリプト

- F.7.2 ASPユーザーおよびグループのサポート

- F.7.3 サブスクライバの追加

- F.7.4 サブスクライバの削除

- F.7.5 アップグレード

- F.8 スクリプトのパラメータ

G Oracle Portalのトラブルシューティング

- G.1 問題と解決策

- G.1.1 Oracle Portalにアクセスできない

- G.1.2 Oracle Portalにログインできない

- G.1.3 カテゴリ・ページまたはパースペクティブ・ページ作成の問題

- G.1.4 Network Address Translation (NAT)設定の問題

- G.1.5 Oracle PortalとOracle Internet Directoryのユーザーおよびグループ情報が一致しない

- G.1.6 Oracle Portalのパフォーマンスの問題

- G.1.7 Webフォルダ作成時のエラー

- G.1.8 「新規ユーザーの作成」および「新規グループの作成」ポートレットが表示されない

- G.1.9 error_logファイルのORA-2000xエラー

- G.1.10 動的DNS環境でのリモートWebプロバイダのタイムアウト

- G.1.11 メモリー使用量の多い操作に関連する問題

- G.1.12 Oracle Textの索引を作成できない

- G.1.13 ヘルプの複数言語サポートの問題

- G.1.14 ポータル・ページに古いスタイルシートのデータが表示される

- G.1.15 ポータル・ページに古いコンテンツが表示される

- G.1.16 ポータル・ページにイメージが表示されない

- G.1.17 ハンドルされていない例外エラー

- G.1.18 OmniPortletプロバイダの構成の問題

- G.1.19 OmniPortletプロバイダのOracle Web Cacheの構成における問題

- G.1.20 モバイル・デバイスからOracle Portalへのアクセスに関する問題

- G.1.21 Oracle Portal 3.0.9または9.0.4からのアップグレード後のエクスポートおよびインポート時のエラー

- G.1.22 Oracle Portalの言語が中国語(繁体字)の場合に表示されるエラー

- G.1.23 アップロードされたコンテンツが検索で返されない

- G.2 Oracle Portalの問題の診断

- G.2.1 ECIDロギングの有効化

- G.2.2 トレース・ファイルの生成

- G.2.2.1 PlsqlBeforeProcedureとPlsqlAfterProcedureの使用

- G.2.2.2 sql_traceパラメータを設定する

- G.2.2.3 データベース・イベント10046の設定

- G.2.3 コンポーネントの診断出力の表示

- G.2.3.1 JPDK

- G.2.3.2 Portalサービス

- G.2.3.3 Parallel Page Engine

- G.2.3.4 Oracle Fusion Middleware Portal Developer Kit

- G.2.3.5 Oracle Metadata Repository

- G.2.3.6 Oracle Web Cache

- G.2.4 Fusion Middleware ControlのLog Viewerの使用

- G.2.5 Oracle Portal Diagnostics Assistantの使用

- G.2.6 Oracle Portalでのモバイル関連の問題の分析

- G.2.7 パフォーマンス・ログの有効化

- G.3 さらにサポートが必要な場合

索引

例一覧

- 5-1 ウォレットの登録

- 5-2 Oracle Portalのメッセージ・スキーマのサンプル

- 5-3 却下コールバックWebサービス

- 5-4 承認コールバックWebサービス

- 5-5 ポータルDADの作成

- 5-6 ポータルDADの属性の更新

- 5-7 Portal_dads.confファイルからのポータルDADエントリの削除

- 5-8 ドメイン内の様々なDADのリスト

- 5-9 ポータル・キャッシュの構成

- 5-10 Parallel Page Engineの更新

- 5-11 ポータル・アクセスのパラメータの構成

- 7-1 動的グループの定義

- 7-2 web.xmlへのJNDI環境変数の定義の追加

- 7-3 web.xmlでの複数プロバイダ・インスタンスに対するJNDI環境変数の定義

- 7-4 更新されたウォレットのパス

- 7-5 ウォレットの登録

- 7-6 ウォレットの登録

- 7-7 データベースへの証明書の登録

- 7-8 ポータル中間層のWLSへの証明書の登録

- 7-9 証明書のリストを含むサンプル・ファイル

- 9-1 UNIXでのssoregの使用方法

- 12-1 複数のサブスクリプションへのコンテンツのインポート

- 13-1 HMACキーの設定:

- A-1 httpd.conf

- A-2 portal_dads.conf

- B-1 キャッシュ情報のデバッグ出力1

- B-2 キャッシュ情報のデバッグ出力2

- B-3 キャッシュ情報のデバッグ出力3

- B-4 キャッシュ情報のデバッグ出力4

- C-1 JavaServer Pages構成ファイルの例

- F-1 シナリオ1 - 多数のサブスクライバの管理

- F-2 シナリオ2 - アップグレード

図一覧

- 1-1 Oracle Portalアーキテクチャのコンポーネント

- 1-2 中間層コンポーネント

- 1-3 インフラストラクチャ層コンポーネント

- 1-4 ポータル・ページのリクエスト・フロー

- 1-5 通信フローとプロトコル

- 1-6 中規模から大規模のポータル構成へのOracle Web Cacheの追加

- 2-1 Oracle Portal単一のコンピュータ構成

- 2-2 インフラストラクチャ層からのFusion Middleware中間層の切離し

- 2-3 個別のコンピュータにインストールされたOracle Identity Management

- 2-4 複数の中間層

- 2-5 ロード・バランシング・ルーターを使用する複数のサーバー構成

- 2-6 My Oracle.comの中間層の構成

- 3-1 「ログイン」リンク

- 5-1 「Portalビルダー」ページの「管理」タブ

- 5-2 PDAのサンプル・ページ・レイアウト

- 5-3 「言語の設定」ポートレット

- 6-1 ロード・バランシング・ルーターを使用する複数の中間層の構成

- 6-2 Oracle Portal中間層のインストール

- 6-3 Oracle PortalがLBRを通じてアクセスされている

- 6-4 仮想ホストの概要

- 6-5 リバース・プロキシ・サーバーの構成

- 6-6 専用のOracle Web Cacheインスタンスを使用するOracle Portal

- 7-1 Oracle Portalのセキュリティ・アーキテクチャ

- 7-2 ユーザー・プロキシによるN層認証

- 7-3 共有オブジェクト

- 7-4 属性の作成

- 7-5 「ページ・タイプ」の編集

- 7-6 ページ・タイプ

- 7-7 Oracle PortalのDIT構造

- 7-8 Oracle PortalグループのDIT構造

- 7-9 Oracle Directory Integration Platformの同期化

- 7-10 Oracle Delegated Administration Services、mod_ossoおよびOracleAS Single Sign-Onの関係

- 7-11 「ユーザー」ポートレット

- 7-12 「ポータル・ユーザー・プロファイル」ポートレット

- 7-13 「グループ」ポートレット

- 7-14 「ポータル・グループ・プロファイル」ポートレット

- 7-15 「グループの作成」ページ

- 7-16 「グループの作成」ページの「権限の割当て」セクション

- 7-17 グループのプロファイルの編集ページの「管理権限」セクション

- 7-18 「ロールの構成」ページ

- 7-19 OracleAS Single Sign-Onとの保護された接続

- 7-20 Oracle Web Cacheとの保護された接続

- 7-21 システム全体にわたって保護された接続

- 7-22 外部SSLのみ

- 8-1 Oracle Fusion Middleware Control - Oracle Portalホーム・ページ

- 8-2 「ページ・レスポンス時間」ポートレット

- 8-3 「ページ・レスポンス・コード統計」ポートレット

- 8-4 「ポピュラーなプロデューサ」ポートレット

- 8-5 「プロデューサ」ポートレット

- 8-6 「リソース・センター」ポートレット

- 8-7 「ページ・エンジン統計」ポートレット

- 8-8 Oracle Fusion Middleware - 「メトリック」ページ

- 8-9 Oracle Fusion Middleware - 「キャッシュ・メトリック」タブ

- 8-10 Oracle Fusion Middleware - 「リポジトリ・メトリック」タブ

- 8-11 Oracle Fusion Middleware - 「プロデューサ・メトリック」タブ

- 8-12 Oracle Fusion Middleware - 「プロデューサ・メトリック」タブ

- 8-13 Oracle Fusion Middleware - 「パフォーマンス・サマリー」ページ

- 8-14 「時間範囲選択」バー

- 8-15 メトリック・パレット

- 8-16 Oracle Fusion Middleware Control - 「データベース・アクセス記述子の構成」ページ

- 8-17 Oracle Fusion Middleware Control - 「データベース・アクセス記述子の編集」ページ

- 8-18 Fusion Middleware Control - 「ポータルのWebキャッシュ設定」ページ

- 8-19 Oracle Fusion Middleware Control - 「ページ・エンジン構成」ページ

- 8-20 Oracle Fusion Middleware Control - 「ログ・メッセージ」ページ

- 8-21 「ログ構成」ページ

- 8-22 「ログ・レジストリの管理」ページ

- 8-23 「ログ・レジストリ・レコードの編集」ページ

- 8-24 Oracle Fusion Middlewareの「ポートの使用状況」ページ

- 10-1 Oracle Portalの「基本検索」ポートレット

- 10-2 Oracle Portalの「基本検索結果ページ」

- 10-3 Oracle Portalの「拡張検索」ポートレット

- 10-4 Oracle Portalの「カスタム検索」ポートレット

- 10-5 Oracle Portalの「検索結果ページ」

- 10-6 Oracle Portalの「保存された検索」ポートレット

- 10-7 検索ポートレットの「ページに表示するヒット件数」の設定

- 10-8 「基本検索」および「カスタム検索」ポートレット上の「拡張検索」リンク

- 10-9 「拡張検索」および「カスタム検索」ポートレット上の「インターネット検索エンジン」リンク

- 12-1 エクスポート処理

- 12-2 トランスポート・セットのマニフェスト

- 12-3 マニフェストの詳細画面

- 12-4 Portalナビゲータ

- 12-5 トランスポート・セット・マネージャ

- 12-6 トランスポート・セット・マネージャのオブジェクト

- 12-7 「ログのエクスポートとスクリプトのダウンロード」ページ

- 12-8 トランスポート・セットのエクスポート・ログ

- 12-9 「トランスポート・セットのエクスポート」ポートレット

- 12-10 エクスポートするトランスポート・セットのブラウズ

- 12-11 「ソース・ポータルの登録」ページ

- 12-12 トランスポート・セットの取得

- 12-13 トランスポート・セット・マネージャのインポート・オブジェクト

- 12-14 トランスポート・セット・マネージャのインポート・ログ

- 12-15 「トランスポート・セットのインポート」ページ

- 12-16 「トランスポート・セットのインポート」ポートレット

- 12-17 インポートするトランスポート・セットのブラウズ

- 12-18 インポート処理

- 12-19 インポート処理

- B-1 デバッグ・モードで実行されているポータル・ページ

- E-1 Oracle Web Cacheによる無効化ベース・キャッシュ

- F-1 スクリプト実行前のOracle Internet Directoryツリー

- F-2 スクリプト実行後のOracle Internet Directoryツリー

- F-3 ユーザーおよびグループを設定したOracle Internet Directoryツリー

- F-4 Acme社のユーザーおよびグループのメンバーシップ構造

- F-5 ポータルおよびOracle Internet Directory内のCompanyA

- G-1 HTTP Serverのステータス

- G-2 ECIDの生成と伝播を伴うリクエストのフロー

- G-3 PDKログ・ページ

- G-4 PDKログ・ページのログ・エントリ

表一覧

- 3-1 インストール・コンポーネントおよびバージョン

- 3-2 Portal URLの説明

- 5-1 「ポータル」サブタブのポートレット

- 5-2 「ポートレット」サブタブのポートレット

- 5-3 「データベース」サブタブのポートレット

- 5-4 メッセージ・ペイロードの詳細

- 5-5 Portal WLST構成用のデータベース・アクセス記述子コマンド

- 5-6 Parallel Page Engine (PPE)のパラメータ

- 5-7 ProviderHeadersパラメータ

- 5-8 PDA表示オプション

- 5-9 Oracle Portalの言語とその略称

- 5-10 ptllangパラメータ

- 6-1 詳細情報

- 6-2 仮想ホスト情報

- 6-3 仮想ホスト情報

- 7-1 デフォルトのOracle Portalユーザー

- 7-2 デフォルトのOracle Portalグループ

- 7-3 Oracle Portalのデフォルト・スキーマ

- 7-4 ページ・グループ権限

- 7-5 Portal DBプロバイダ権限

- 7-6 管理権限

- 7-7 Oracle Portalオブジェクトと権限の制御

- 7-8 provideruiacls.xmlのグローバル権限コード

- 7-9 provideruiacl.xmlのオブジェクト権限コード

- 7-10 プロバイダとポートレットの属性値

- 7-11 Authorization Modifierパッケージ

- 7-12 Oracle PortalでサポートされていないOracle Internet Directoryの機能

- 7-13 inetOrgPersonの属性

- 7-14 orclUserV2の属性

- 7-15 groupOfUniqueNames/groupOfNamesの属性

- 7-16 orclGroupの属性

- 7-17 Oracle Portalによって処理されるディレクトリ同期イベント

- 7-18 WSRPプロデューサのキーストア接続パラメータ

- 7-19 共有ライブラリ・パスの環境変数

- 7-20 同期設定の比較

- 7-21 web.xml内の要素の相対順

- 7-22 「証明書リクエスト」ダイアログのフィールドのサンプル値

- 7-23 サイト・サーバー間マッピング

- 8-1 DAD設定

- 8-2 ポータル・キャッシュの設定

- 8-3 ポータルのParallel Page Engineの設定

- 8-4 Oracle Portalオブジェクトについてログに記録されるイベント

- 8-5 動作ログ・ビュー

- 8-6 Portalの構成MBean

- 9-1 ネットワーク・パケットによって使用される通信パスおよびポート

- 10-1 デフォルトの検索設定

- 10-2 Oracle Portalの検索オプション

- 10-3 Oracle Portalスキーマに含まれるOracle Text索引

- 10-4 Oracle Database 11gのOracle Text索引の推奨される同期化スケジュール

- 12-1 エクスポート・ユーザーの権限

- 12-2 インポート・ユーザーの権限

- 12-3 デフォルトのモード

- 12-4 OPEASST.CSHパラメータの説明

- 12-5 データベース接続情報

- 12-6 データベース・リンクの構文

- 12-7 ステータスの説明

- 12-8 警告または失敗のタイプ

- 12-9 連鎖する警告動作

- 12-10 パラメータの説明

- 12-11 上書きモードでのリージョンのインポート動作

- 12-12 子オブジェクトのインポート動作

- 12-13 移行時の共有ポートレット・インスタンスの動作

- 13-1 連携型Portalアダプタの使用

- 13-2 キー・ストアの管理用SQLスクリプト

- B-1 ctxjsubのパラメータ

- B-2 実行時間とキャッシュの_debug値の統計

- B-3 Oracle Application Server Wireless構成パラメータ

- B-4 cfgxodncスクリプトのパラメータ

- B-5 ユーティリティのアップグレード・モード

- B-6 ユーティリティの移行モード

- C-1 <portal>タグの属性

- C-2 <url>タグの属性

- C-3 <cookie>タグの属性

- C-4 <pageGroup>タグの属性

- E-1 Webクリッピング・リポジトリの設定

- E-2 Webクリッピング・プロバイダの登録設定

- E-3 Webクリッピング・プロバイダのプロキシ設定

- E-4 OmniPortletプロバイダのプロキシ設定

- E-5 OmniPortletプロバイダの登録設定

- E-6 driverInfoプロパティのパラメータ

- E-7 driverClassNameおよびdataSourceClassNameのパラメータと値

- F-1 パラメータ

- F-2 enblhstg.csh

- F-3 addsub.csh

- F-4 rmsub.csh

- F-5 syncasp.csh

- F-6 embldip.csh

- G-1 トレース・レベル

- G-2 ログ・レベル

- G-3 JPDK標準メッセージの属性

- G-4 ログ・レベルとその説明

- G-5 PPEリクエスト・ログのレベル

- G-6 PPEのurlDebugModeレベル

- G-7 PPE標準メッセージの属性

- G-8 PDKログ・レベル

- G-9 CREATE DIRECTORYのパラメータ

- G-10 リポジトリのログ・パッケージのパラメータ

- G-11 リポジトリ・コンテキストの属性

- G-12 Oracle Portal Diagnostics Assistantのスクリプトのパラメータ

- G-13 エラー・ログ・ファイルとその場所

はじめに

このガイドでは、Oracle Portalを構成する方法について説明します。これには、計画、アップグレード、インストール前の要件の確認、およびインストール後の作業の実行の方法が含まれています。また、このガイドでは、より高度なPortalの配置と、そのような配置に必要な拡張構成の実施方法についても説明します。さらに、監視とトラブルシューティングの情報も示します。

注意:

このマニュアルのPortable Document Format (PDF)版でURLが2行にわかれている場合は、このURLをクリックしてもブラウザに完全なURLデータは送信されません。PDFに含まれているURLにアクセスするには、URLをコピーし、ブラウザのアドレス・フィールドに貼り付けます。このマニュアルのHTML版では、リンクをクリックすればブラウザに直接リンク先が表示されます。

対象読者

このガイドは、次の2種類のユーザーを対象としています。

- Oracle Portalの構成と保守に携わるOracle Portal管理者

- 他のOracle Fusion Middlewareコンポーネントと連携して動作するようにOracle Portalを構成する必要のあるOracle Fusion Middleware管理者

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/us/corporate/accessibility/index.htmlを参照してください。

Oracleサポートへのアクセス

オラクル社のお客様は、My Oracle Supportを通じて電子的なサポートを受けることができます。詳細は、http://www.oracle.com/support/contact.htmlを参照してください。聴覚障害のあるお客様は、http://www.oracle.com/accessibility/support.htmlを参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middlewareドキュメント・ライブラリにある次の関連ドキュメントを参照してください。

- Oracle Fusion Middleware Oracle Portal開発者ガイド

- Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド

注意:

Oracle Portal関連用語の完全な用語集は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』にあります。

- Oracle Fusion Middlewareコンセプト・ガイド

- Oracle Fusion Middleware管理者ガイド

- Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

- Oracle Fusion Middleware Oracle Web Cache管理者ガイド

- Oracle Application Server Single Sign-On管理者ガイド

- Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

- Oracle Fusion Middleware Oracle Portal、Forms、Reports、Discovererアップグレード・ガイド

- Oracle Fusion Middlewareアップグレード・プランニング・ガイド

- Microsoft Windows (32ビット)でのOracle Fusion Middlewareのリリース・ノート

- Linux x86でのOracle Fusion Middlewareのリリース・ノート

表記規則

本文では、次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するグラフィカル・ユーザー・インタフェース要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、パラグラフ内のコマンド、URL、例に記載されているコード、画面に表示されるテキスト、または入力するテキストを示します。

大文字

大文字テキストは、プロシージャ名を示します。

< >

山カッコはユーザーが入力する情報を表します。

[ ]

大カッコは、カッコ内の項目を任意に選択することを表します。

.

.

.

垂直の省略記号は、例に直接関連しない複数の行が省略されていることを示します。

Oracle Portalの新機能

この章では、Oracle Portalの最新リリースおよび前のリリースで導入された機能について簡単に説明し、詳細の参照先を示しています。この章の内容は次のとおりです。

- Oracle Portal 11g リリース1 (11.1.1)の新機能

- OracleAS Portal 10g リリース2 (10.1.4)の新機能

Oracle Portal 11g リリース1 (11.1.1)の新機能

Oracle Portal 11g リリース1 (11.1.1)の新機能は、次のとおりです。

- Oracle WebLogic Server上でのOracle Portalの実行

- WS-Securityのサポート

- 新しいHTML文書型の宣言(Doctype)のサポート

- Oracle Internet Directoryの統合の最適化

- Identity Management統合

- Oracle Secure Enterprise Searchとの統合

- Oracle Enterprise Manager Fusion Middleware Control

- エクスポート/インポート・ユーティリティの改善

- Oracle Fusion Middlewareとの統合

- BPELを使用したコンテンツ承認のサポート

- Oracle Applicationsとの統合の改善

- Oracle PortalへのOracle WebCenter Portal: Servicesの統合

- Oracle JSF Portlet Bridgeを使用したJSFアプリケーションのポートレット化およびOracle Portalへの統合

- コンテンツの統合

- Oracle Portal管理コンテンツへのアクセスの向上

- OmniPortletの拡張

- 新しい業界標準のサポート

Oracle WebLogic Server上でのOracle Portalの実行

Oracle Portalは、前回のリリースではOracle Application Serverの一部として配布されましたが、現在はOracle WebLogic Server 11gR1 (10.3.3)上で動作します。

WS-Securityのサポート

この拡張により、管理者はWS-Security (SAML、UserTakenなど)を使用してWSRPプロデューサを保護し、アイデンティティ伝播に使用する適切な種類のトークンを選択できます。

新しいHTML文書型の宣言(Doctype)のサポート

新しいポータル構成設定によって、Oracle Portalによって生成されるHTML出力型を指定できます。HTML 4.01 Transitional以外に3つの新しい文書型(HTML 4.01 Strict、XHTML 1.0 Transitional、XHTML 1.0 Strict)がサポートされます。

Oracle Internet Directoryの統合の最適化

これらのセキュリティの拡張により、ログイン・パフォーマンスに対応して、グループのプロビジョニング変更の影響がユーザー認証に反映されるまでの時間を指定できます。

Identity Management統合

この拡張により、Oracle Internet Directoryの動的グループを定義したり、メンバーとしてユーザーを追加したり、動的グループに適切なアクセス権を追加してページを保護したりできます。グループの権限またはグループにおけるユーザーのメンバーシップに対してどのような変更を行っても、ページへのユーザーのアクセス権に反映されます。

Oracle Secure Enterprise Searchとの統合

Secure Enterprise Search (SES)により、公開および非公開のポータル・コンテンツと外部リポジトリの検索機能が提供されます(従来のUltra SearchがSESに置き換わります)。

Oracle Enterprise Manager Fusion Middleware Control

Oracle Portal 11g リリース1 (11.1.1)には、Oracle Enterprise Manager Fusion Middleware Control 11gとの統合機能が用意されています。Enterprise Manager Fusion Middleware Control 11gには重要な新機能が数多く導入されており、ポータル・コンポーネントを監視および構成したり、Oracle Enterprise Managerのインタフェースを使用してポータル・ページ、ポートレットおよびプロバイダのパフォーマンス・メトリックをリアルタイムで表示したりできます。

エクスポート/インポート・ユーティリティの改善

エクスポート/インポート・ユーティリティには、Oracle Portal 11g リリース1 (11.1.1)向けの重要な改善点がいくつかあります。その内容は次のとおりです。

- 事前確認の改善

- SVUの改善

- エラー・ログ記録機能の改善

- ユーザー・ガイダンスの拡張

- エクスポートの改善

- UIの拡張

- 新しいクローニング機能

Oracle Fusion Middlewareとの統合

Oracle Portal 11g リリース1 (11.1.1)は、Oracle Secure Enterprise Search(検索送信および検索結果)、Oracle BPEL(通知、タスク分析、レポート作成)、Oracle Business Intelligence Enterprise Edition (Siebel BI Tools)およびHyperion System BPM (Business Performance Management)を統合する新しいポートレットを備えており、Oracle Portalとのより高度で追加設定不要の統合を実現します。

BPELを使用したコンテンツ承認のサポート

Oracle Portal 11g リリース1 (11.1.1)では、Oracle BPELを使用して、ポータルのページ・グループ用およびページ用に承認プロセスを定義できます。Oracle BPELでは、Oracle Portalの組込みワークフローで提供される機能以外の機能が追加されているため、ポータルで簡単にその機能を活用できるようになりました。

Oracle Applicationsとの統合の改善

Oracle Portal 11g リリース1 (11.1.1)では、次のアプリケーションとの統合が改善されています。

- Oracle Self-Service ApplicationsなどのOracle Applications Frameworkに基づくOracle Applicationsは、Oracle Portal内のポートレットとしてOracle Applications Frameworkに基づいたアプリケーション・ページを公開できます。

- Oracle Portal 11g リリース1 (11.1.1)は、PeopleToolsリリース8.48テクノロジ・レイヤーに基づくPeopleSoft Version 9などのPeopleSoftアプリケーションからのポートレットの組込みもサポートします。次のアダプタを使用できます。

- Oracle Universal Content Management

- Content DB*サード・パーティ・コンテンツ管理JCRアダプタ

- ファイル・システム

Oracle PortalへのOracle WebCenter Portal: Servicesの統合

このリリースでは、別個のライセンスを使用するOracle WebCenter Portal: ServicesをOracle Portalに統合できます。サービス・プロデューサ・アプリケーション設定の詳細は、Oracle Fusion Middleware Oracle WebCenter開発者ガイドの第27章「Oracle JSF Portlet Bridgeを使用したポートレットの作成」を参照してください。

Oracle JSF Portlet Bridgeを使用したJSFアプリケーションのポートレット化およびOracle Portalへの統合

JSFアプリケーションは、Oracle WebCenter Portal: Servicesに同梱のOracle JSF Portlet Bridgeを使用してポートレット化できます。これらのポートレットはOracle Portalへの統合が可能です。Oracle JSF Portlet Bridgeの詳細は、Oracle Fusion Middleware Oracle WebCenter開発者ガイドのOracle JSF Portlet Bridgeを使用したポートレットの作成に関する項を参照してください。

コンテンツの統合

Oracle Portalポートレットでは、サード・パーティのドキュメント管理システムによるコンテンツを公開できます。ポートレットはOracle JDeveloperに作成され、JCR 1.0アダプタを使用してコンテンツ管理システムに接続されます。

Oracle Portal管理コンテンツへのアクセスの向上

Oracle Portal 11g リリース1 (11.1.1)では、新しいJCRベース(JSR-170)のアダプタが用意されており、カスタムJ2EEアプリケーションのポータル・リポジトリ内に保存および管理されるコンテンツを統合できます。

OmniPortletの拡張

この拡張は、SQL問合せやデータベース列などのデータ・ソースに基づいて値リストを動的に移入できる高度なパラメータ・フォームを提供します。また、OmniPortletのWebサービスのデータ・ソースが大幅に向上しているので、BPELおよびPL/SQLベースのWebサービスを含む複雑なWebサービスを利用できます。

新しい業界標準のサポート

Oracle Portal 11g リリース1 (11.1.1)では、次の新しい標準がサポートされています。

- WSRP 2.0: Oracle Portalは、ADFリッチ・クライアント・テクノロジで構築されたAjax対応の豊富なポートレットを含むWSRP 2.0をサポートします。

- JSR301: JavaServer Faces (JSR 301)のポートレット・ブリッジの仕様では、JSFを使用した新しいポートレットの作成、JSFページとタスク・フローの標準ベースのポートレットへの変換、および既存のJSFアプリケーションのOracle Portalへの変換を行うための標準について概説しています。

- JSR170: カスタムJ2EEアプリケーションのポータル・リポジトリ内に保存および管理されるコンテンツを統合できます。

OracleAS Portal 10g リリース2 (10.1.4)の新機能

OracleAS Portal 10gリリース2 (10.1.4)の新機能は、次のとおりです。

- 新しいキャッシュ・アーキテクチャ

- 問合せパスURLでのSSLのサポート

- 新しいURL形式

- WSRPのサポート

- 検索およびOracle Text索引の拡張

- プロバイダの拡張メッセージ認証のサポート

新しいキャッシュ・アーキテクチャ

10gリリース2 (10.1.4)では、OracleAS Portalのスケーラビリティが大幅に向上しました。今回のリリースでは、ページ・リクエスト処理のエントリ・ポイントがParallel Page Engine (PPE)ではなく、Edge Side Includes (ESI)処理を使用したOracleAS Web Cacheになります。これによりページ・メタデータ(PMD)が簡易化され、OracleAS Web Cacheで様々なタイプのメタデータをより詳細なレベルでキャッシュできるようになるため、キャッシュのヒット率が高まり、ポータル・コンテンツをより詳細に無効化できるようになります。この新しい手法では、OracleAS Web Cacheでのセキュアなフルページ・キャッシュもサポートされます。

問合せパスURLでのSSLのサポート

OracleAS Portalでは、データベースからコールを介して特定の情報にアクセスするためのOracleAS Single Sign-OnのURL接頭辞を、UTL_HTTPパッケージを使用して管理しています。また、これらのコールをHTTPSを使用して実行できるようになりました。以前のリリースでは、これらのコールはHTTPを使用して実行されていました。そのため、OracleAS PortalとOracleAS Single Sign-OnがHTTPSを使用するように構成されていても、OracleAS Single Sign-OnのHTTPポートを使用してこれらのインタフェースをサポートする必要がありました。HTTPSを使用している場合、SSLを使用するようにOracleAS Single Sign-Onを構成した後に、OracleAS Single Sign-Onの問合せパスのURLを更新する必要があります。

新しいURL形式

OracleAS Portal 10gリリース2 (10.1.4)のURL形式は、http://<host>:<port>/pls/<dad>からhttp://<host>:<port>/portal/pls/<dad>に変更されました。この変更は、OC4J_PORTALで実行するすべての必須Portalサービスの可用性に対応するためのものです。古い形式のURLにアクセスすると、OracleAS Portalによって、新しい形式を使用するようにURLが自動的に書き換えられるか、ブックマークされたURLを新しい形式に変更するようにユーザーに警告があります。

WSRPのサポート

エンタープライズ・ポータル・プロジェクトに関わっている組織にとって、アプリケーションの統合は大きな問題です。今まで、ユーザーは固有のAPIを使用して単一ポータル・プラットフォームのポートレットを開発してきましたが、特定ポータル・ベンダーのポートレットの不足にしばしば直面していました。これらはすべて、Web Services for Remote Portlets (WSRP)の導入によって変わりました。WSRPは、ポータルや他の中間Webアプリケーションでのビジュアルなユーザー向けWebサービスのプラグ・アンド・プレイを可能にするWebサービスの標準です。WSRPは標準であるため、標準コンテナとあらゆるWSRPポータル間の相互運用性が実現されます。

検索およびOracle Text索引の拡張

OracleAS Portalの検索機能の特筆すべき改善点は、次のとおりです。

- コミット時の検索索引の自動同期
Oracle Database 10gを使用している場合、ポータル・オブジェクトが追加、変更または削除されるたびにOracle Text索引が自動的に同期化されるように指定できます。この機能は、新しく追加または変更されたコンテンツをただちに検索可能にする必要のあるポータル・アプリケーションで役立ちます。

詳細は、第10.3.5.1項「Oracle Text索引の同期化」を参照してください。この機能は、Oracle Database 10gより前のデータベースでは使用できません。

- ドキュメントおよびURLフィルタの改善
Oracle Textでは、AUTO_FILTERを使用して、ドキュメントおよびURLコンテンツを索引作成に適したプレーン・テキスト形式に変換します。コンテンツを不必要に絞り込むと、ポータル検索の速度と効率性に悪影響を与える可能性があるため、このリリースでは、ファイルベースとURLベースのアイテム・タイプにMIMEタイプおよび文字セットという、2つの特別な属性が導入されました。これらの属性により、ポータル・ユーザーはポータルへのアップロード時にポータル・コンテンツを適切に分類できるようになり、フィルタ・プロセスが合理化されます。

詳細は、第10.3.3.7項「AUTO_FILTERパフォーマンスの最大化」を参照してください。

プロバイダの拡張メッセージ認証のサポート

10gリリース2 (10.1.4)では、OracleAS Portalでプロバイダの拡張メッセージ認証がサポートされるようになりました。拡張メッセージ認証では、認証されたユーザーIDをWebプロバイダに伝播するために使用されるヘッダーの整合性が保護されます。これにより、プロバイダ・コードでJ2EEセキュリティを利用できるようになります。

関連項目:

- プロバイダ・メッセージ認証の構成方法の詳細は、第7.3.1.3項「プロバイダのメッセージ認証の構成」を参照してください。

- Oracle Fusion Middleware Oracle Portal開発者ガイド

第I部

概念

第1部には次の章が含まれます:

- 第1章「Oracle Portalのアーキテクチャの理解」

- 第2章「Oracle Portalの計画」

1 Oracle Portalのアーキテクチャの理解

この章では、Oracle Portalとそのアーキテクチャについて説明します。この章の内容は次のとおりです。

- 「Oracle Portalコンポーネントについて」には、Oracle Portalのソリューションとコンポーネントに関する基本的な説明があり、Oracle Portalとどのように連携して機能するのかをよりよく理解できます。

注意:

Oracle Portalはスタンドアロンではインストールできません。Oracle Fusion Middlewareの一部としてインストールする必要があります。

- 「Oracle Portalのアーキテクチャの理解」には、Oracle Portalのアーキテクチャに関する基本的な説明があります。

- 「Oracle Portalのキャッシュの理解」では、中規模から大規模の配置における可用性とスケーラビリティを高めるために実装できるキャッシュの構成について説明します。

- 「WSRPおよびJPSの理解」では、Web Services for Remote Portlets(WSRP)仕様とJava Portlet Specification(JPS)の概要について説明します。これらの2つの標準を使用すれば、様々なポータル製品と相互運用するポートレットの開発が可能になるため、組織内のポートレットの可用性が高まります。

1.1 Oracle Portalコンポーネントについて

Oracle Portalアーキテクチャ全体について少しでも理解しておくと、使用するOracle Portalの構成がアーキテクチャの構造にどの程度適合しているかをより深く理解できます。以降の項では、構成戦略の計画に必要となる重要な概念と用語について説明します。

Oracle Portalのアーキテクチャは、次の3つの基本層で構成されています。

- クライアント層

- 中間層

- インフラストラクチャ層

クライアント層

ユーザーは、クライアント・コンピュータから中間層およびインフラストラクチャ層に接続して、情報公開のためのセルフサービス・ツールへのアクセス、アプリケーションの構築、コンテンツ管理の導入、および企業ポータル環境の管理を行います。

中間層

中間層は、通常1つのOracleホームにインストールされる一連のOracle Portalコンポーネントで、アプリケーション層とWeb層で構成されます。各企業では、1つ以上のFusion Middlewareインストールを単一のホストに配置することも、複雑なインストールの場合は複数のホストに分散することもできます。

インフラストラクチャ層

インフラストラクチャ・インストールは、ユーザーを認証し、アクセス制御情報を格納し、ユーザーがOracle Portalに対して保持している権限に基づいて必要なコンテンツをユーザーに渡すためのいくつかのコンポーネントで構成されています。中間層コンポーネントと同様に、インフラストラクチャ・コンポーネントを複数のホスト間に分散して、スケーラビリティと高可用性を実現することができます。

図1-1は、Oracle Portalアーキテクチャの3つの層を示しています。

図1-1 Oracle Portalアーキテクチャのコンポーネント

注意:

Oracle Portal 11g リリース1 (11.1.1)は、インターネット・プロトコル・バージョン6 (IPv6)では直接サポートされていません。

サポートされる構成は次のとおりです。

- IPv4/IPv6 デュアル・スタック・マシンでのIPv4/IPv6リバース・プロキシを設定

- IPv4マシン上にポータルの中間層およびバックエンド・データベースを配置し、クライアントからポータル・サーバーへのアクセスにはプロキシを使用

1.1.1 中間層コンポーネント

中間層は、Portalアーキテクチャの一部であり、高速で信頼性のあるパフォーマンスを実現するためにインテリジェント・データ・キャッシュを使用して、クライアントからのリクエストの受入れ、リクエストの検証、コンテンツの提供などを実行するコンポーネントが含まれています。

Oracle Portalでは、中間層は、すべてのWebリクエストを適切なプロバイダに転送することによって処理しています。中間層は、ポータル・ページが作成される場所であり、ポータル・コンテンツのキャッシュが管理される場所でもあります。中間層には、他のOracle Fusion Middlewareコンポーネントに対する機能も用意されています。

Oracle Portalの中間層の主要コンポーネントは、次の層に分割されています。

アプリケーション層

アプリケーション層は、次のコンポーネントで構成されます。

- Oracle WebLogic Server: Oracle WebLogic Serverは、標準ベースのアプリケーション・サーバーです。Webサイト、J2EEアプリケーションおよびWebサービスを実行するための、包括的で全面的に統合したプラットフォームを提供します。E-Businessに向けたビジネス・プロセスの検討で直面するあらゆる問題に対応します。
Oracle WebLogic Serverは、J2EEプラットフォーム、XMLおよび新たなWebサービス標準を全面的にサポートしています。Oracle WebLogic Serverを使用して、ネットワーク・ブラウザやモバイル機器からアクセスできるカスタマイズ可能な企業ポータルを構築することで、顧客や取引先が情報に容易にアクセスできるようになります。また、ビジネス・プロセスを再定義して、社内のアプリケーションおよびデータ・ソースを顧客や取引先のものと統合できます。リアルタイムなパーソナライズによって各顧客に適した環境を提供し、ナビゲート傾向、購買、格付け、購買層などの顧客データの評価と相関分析が可能です。

また、分散システムおよび多様なユーザー・コミュニティをすべて管理および監視するために、集中型の管理、セキュリティおよびディレクトリのフレームワークを実装できます。Oracle WebLogic Serverでは、組込みのWebキャッシュ、ロード・バランスおよびクラスタリングの機能を使用して高速でスケーラブルなインターネット・アプリケーションを配置することにより、Webサイトのインフラストラクチャを最大化することができます。

Oracle WebLogic Serverは、実際にはソリューションのセットです。それぞれのソリューションには、1つ以上のコンポーネントが含まれています。コンポーネントは、サービス、APIまたはアプリケーションになります。詳細は、『Oracle Fusion Middlewareコンセプト・ガイド』を参照してください。

- Portalサービス: Oracle Portalでは、Oracle HTTP Serverは、Oracle Portalに対するすべての受信リクエストを、すべてのPortalサービスが用意されたWLS_Portalインスタンスに転送することによって処理しています。Parallel Page Engine (PPE)は、Portalサービスの1つで、ポータル・ページを作成します。これ以外に、以前はmod_plsqlで提供されていたようなサービスも、Portalサービスに組み込まれました。

- Fusion Middlware Control: Portal用のこの管理ツールを使用すると、クラスタの管理、サービスの開始と停止、コンポーネントの有効化と無効化、ログとポートの参照、およびサーバーのリアルタイムの監視を行うことができます。

Web層

- Oracle HTTP Server:Oracle HTTP Serverは、Oracle Fusion Middlewareがサポートするすべてのプログラミング言語およびテクノロジの基盤となる配置プラットフォームです。Oracle HTTP Serverは、J2EEコンテナのフロントエンドに設定されたスケーラブルなWebリスナー、Web上で静的および動的なページとアプリケーションをホストするためのフレームワークを提供し、ロード・バランス、管理および構成を容易にする機能を備えています。

- Oracle Web Cache:Oracle Portal独自のファイルベースのキャッシュと連携して、ページ定義およびコンテンツをメモリー内にキャッシュし、パフォーマンスを向上させます。Oracle Portalは、Oracle Portal全体の可用性、スケーラビリティおよびパフォーマンスを改善するために、Oracle Web Cacheと密接に統合されています。Oracle Web Cacheは、キャッシュおよび圧縮のテクノロジを組み合せて、静的および動的に生成されたポータル・コンテンツを迅速に配信します。

図1-2 中間層コンポーネント

中間層インストールは次のコンポーネントで構成されます。

1. Oracle WebLogic Server、Oracle HTTP ServerおよびOracle Web Cache: 最も単純な構成で、Oracle Portalソリューション・コンポーネントは含まれていません。

2. Oracle Portal: Portalソリューションを、Oracle WebLogic ServerとOracle Web Cacheによって提供されるソリューションに追加します。

3. Oracle Reports、Oracle Business Intelligence DiscovererおよびOracle Forms: Oracle Portalなど、中間層コンポーネントのすべてが含まれています。

詳細は、次の項も参照してください。

- 第2.1.7項「ハードウェアとソフトウェアを構成する方法」

- 第6.3項「ロード・バランシング・ルーターを使用する複数の中間層の構成」

1.1.2 インフラストラクチャ・コンポーネント

デフォルトでは、インフラストラクチャ層はすべての認証リクエストを処理し、Oracle Fusion Middleware Metadata Repositoryをホストします。これには、Oracle PortalなどのFusion Middlewareコンポーネント、およびインフラストラクチャの他の部分で使用されるスキーマとビジネス・ロジックが含まれています。

Oracle Portalの中間層インストールには、インフラストラクチャ層が必要です。

Oracle Fusion Middleware Infrastructureには、次のものが含まれています。

- Oracle Internet Directory:Oracle Portalおよび他のOracle製品のユーザー証明書とグループ・メンバーシップを格納するためのLDAPバージョン3に準拠したリポジトリ。

- Oracle Application Server Single Sign-On (SSO):Oracle Portalおよび他のアプリケーションのOracle Internet Directoryを使用してユーザー証明書を認証します。ユーザーはWebポータルに1回ログインするだけで、同じユーザー名とパスワードを使用して複数のアカウントとアプリケーションにアクセスできるようになります。

- Oracle Metadata Repository:このリポジトリはOracle Databaseにインストールされており、Oracle Fusion Middlewareコンポーネントの製品メタデータが含まれているスキーマのコレクションで構成されています。Oracle Portalなどの中間層コンポーネントの中には、このリポジトリに自身のメタデータを格納しているため、実行時にこのメタデータにアクセスする必要があるものがあります。

図1-3 インフラストラクチャ層コンポーネント

これらのコンポーネントの複数のインスタンスを複数のサーバーにインストールし、ニーズに合せてサーバーに接続することができます。Oracle Portalの配置構成については、単一のサーバーへのすべてのコンポーネントのインストールから、Oracle Portalを構成する要素が複数のサーバーに分散される複数層構成まで、様々なオプションを使用できます。

OracleAS Infrastructureインストールには、次の3つのタイプがあります。

1. Oracle Identity Management: Oracle Identity Managementのサービス(Oracle Internet Directory、OracleAS Single Sign-On、Oracle Delegated Administration Services、Oracle Directory Integration and Provisioning、OracleAS Certificate Authority)をインストールおよび構成します。

2. Oracle Metadata Repository: Oracle Metadata Repositoryが含まれている新しいOracle Databaseをインストールし、Oracle Portalを構成するデータベース・オブジェクトを格納します。

3. Oracle Identity ManagementのコンポーネントとOracle Metadata Repository: 前述の2つのインストール・タイプにあげたすべてのコンポーネントで構成されます。

注意:

このガイドには、ORACLE_HOMEという参照先が記載されています。ORACLE_HOMEは、Oracleホームのフルパスを表し、参照するOracleホームを簡単に特定できる場合に使用しています。Oracleホームには、インストール・タイプに合せて選択するOracleのすべてのコンポーネントがあります。Oracle Universal Installerの「ファイルの場所」ウィンドウの「パス」フィールドで、Oracleホームを入力するよう求められます。

Oracleインスタンス、中間層、WLSインスタンスまたはOracle Metadata RepositoryのOracleホームを区別する必要があるプロシージャでは、次の表記規則が使用されます。

- Middlewareホームは、Oracle WebLogic Serverホームおよび1つ以上のOracleホーム(必要に応じて)で構成されます。Middlewareホームは、ローカル・ファイル・システムまたはNFSを介してアクセスできるリモートの共有ディスクに置くことができます。このドキュメントでは、製品のインストール先ディレクトリを指すためにMW_HOMEを使用します。
MW_HOMEは、インストールされているOracle Fusion Middlewareインスタンスのフルパス名に置き換える必要があります。

- Oracleホームには、特定製品をホストするためにインストールされているファイルが含まれます。たとえば、Portal Oracleホームには、Oracle Portalとそのコンポーネントのバイナリおよびバイナリ・ファイルが含まれます。Oracleホームは、Middlewareホームのディレクトリ構造内にあります。各Oracleホームは、複数のOracleインスタンスまたはOracle WebLogic Serverドメインに関連付けることができます。デフォルトのORACLE_HOMEは、as_1と名前が付けられています。

- Oracleインスタンス・ホームには、Oracle Web Cache、Oracle HTTP ServerまたはOracle Internet Directoryなどの1つ以上のシステム・コンポーネントが含まれます。Oracleインスタンスのシステム・コンポーネントは、同一マシン上に置く必要があります。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど更新可能なファイルが含まれます。Oracleインスタンスは、Oracle WebLogic Serverドメインのピアです。両方に、Oracleホーム外部の固有の構成が含まれます。Oracleインスタンスのディレクトリ構造は、Oracleホームのディレクトリ構造とは別個です。デフォルトのインスタンスのホームは、asinst_1と名前が付けられています。

- WebLogic Serverホームには、WebLogic Serverをホストするためにインストールされているファイルが含まれます。WebLogic ServerホームのディレクトリはOracleホームのディレクトリのピアで、Middlewareホームのディレクトリ構造内にあります。

- Oracle Metadata Repositoryホームは、Oracle Metadata Repositoryを含むOracleAS Infrastructureのフルパスを表します。

1.2 Oracle Portalのアーキテクチャの理解

配置チームがWebポータルを構築したら、次に、本稼働用のWebポータルを配置します。配置の成功は、遅延、エラーまたはサーバー停止がなく、エンド・ユーザーが適切な方法でコンテンツにアクセスできることを意味します。Oracle Portalは、様々なマシンに様々な構成でインストールできるため、配置の成功は、最終的にはサイトの要件に合せてポータルをどのように設定するかに依存します。この項では、構成を計画する際に役立つ背景情報について説明します。

1.2.1 Oracle Portalと他のコンポーネントとの統合

Oracle Fusion Middlewareコンポーネントの中には、Oracle Portalのポートレット・プロバイダ脚注 1 として機能するものがあります。これは、様々なコンポーネントの情報を1つのポータル・ページに簡単に統合できることを意味しています。他のコンポーネントは、次に説明するような、Oracle Portalにとって必須のサービスを提供します。

- Oracle Reports:Oracle Portalには、シンプルなレポート作成機能が含まれています。ただし、レポートが複雑になったら、レポートをOracle Reports Servicesにインポートして、用意されている機能をフル活用できます。Oracle Reports Servicesのレポートは、ポートレットとして配布できます。

関連項目:

Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド

- Oracle Business Intelligence Discoverer:OracleBI Discovererは、ポートレット・プロバイダとして、「ワークシート」ポートレットおよび「ワークブックのリスト」ポートレットをOracle Portalユーザーに提供します。「ワークシート」ポートレットには、単一のDiscovererワークシートの情報が含まれています。ポートレットには、この情報が表、グラフまたはその両方で表示されます。「ワークブックのリスト」ポートレットには、使用できるワークブックのリストが表示されます。

関連項目:

- Oracle Fusion Middleware Oracle Business Intelligence Discovererポートレット公開ガイド

- Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイド

- Oracle Secure Enterprise Search:Secure Enterprise Search (SES)を使用すると、ポータルのユーザーは強力な検索機能をポータル・ページに追加でき、様々なコンテンツ・リポジトリおよびデータ・ソースに対する検索に使用できます。また、Oracle Portalリポジトリをクロールする機能や公開コンテンツの検索機能も用意されています。Secure Enterprise Searchの詳細は、第10章「Oracle Portalの検索機能の構成」を参照してください。

- Oracle Application Server Wireless:Oracle Portalは、OracleAS Wirelessと連携して、ポータル・ページ構造を大半のワイヤレス・デバイスの小さい画面に適した形式に自動的に変換します。ワイヤレス・デバイスでは、OracleAS WirelessのXMLコンテンツを生成するポートレットのみを表示できます。
Oracle Portalの開発者は、ページ設計ツールのセットにアクセスできます。これらは、ワイヤレスの操作環境を最適化するポータル・ページを作成するときに役立ちます。開発者はこれらのツールを使用して、ワイヤレス・ユーザーに対して別個のポータル構造を構築できます。ワイヤレス・ページとポータル・ページで、ポートレット・インスタンスを共有することが可能です。これによってクライアントは、各ポートレットを再構成しなくても、ブラウザおよびワイヤレス・クライアント上のポートレットを再使用できるようになります。

詳細は、第5.7項「Oracle Portalでのモバイル・サポートの構成」を参照してください。

- Oracle Enterprise Manager 11g:Oracle Enterprise Manager 11gにはFusion Middleware Controlが用意されています。Oracle Enterprise Manager 11g Fusion Middleware Controlは、監視、診断、およびOracle Portal固有の統合およびパフォーマンス設定の構成で使用できます。Oracle Portalの監視の詳細は、第8章「Oracle Portalの監視と管理」を参照してください。

- Oracle Fusion Middleware Forms Services:Oracle Formsアプリケーションでは、対話的なグラフィカル・インタフェースがデータ妥当性チェックの強力なサポートと組み合されています。Forms開発者は、強力なデータ操作機能により、アプリケーションを迅速に作成できます。Fusion Middleware Forms Servicesでは、FormsアプリケーションがWeb環境のJavaクライアントに配置されます。Fusion Middleware Forms Servicesでは、クラスのダウンロード、ネットワーク通信量、およびOracle Databaseとの対話が、自動的に最適化されます。Fusion Middleware Forms ServicesアプリケーションはOracleAS Single Sign-Onで保護され、Oracle WebLogic Serverで提供されるOracle Portal環境からアクセスされます。

- Oracle Application Server Single Sign-On:OracleAS Single Sign-Onは、ポータルにアクセスしようとするユーザーを認証します。詳細は、第7.1.7.1項「Oracle PortalとOracleAS Single Sign-Onの関係」を参照してください。

- Oracle Internet Directory:Oracle Internet Directoryは、スケーラビリティに富んだOracleのLDAPバージョン3のサービスで、Portalのグループ・メンバーシップ情報をホストします。Oracle Portalは、ディレクトリに対して問合せを行い、ディレクトリからユーザーのグループ・メンバーシップを取得して、ユーザーが何にアクセスし、変更できるのかを確認します。詳細は、第7.1.7.3項「Oracle PortalとOracle Internet Directoryの関係」を参照してください。

- Oracle Delegated Administration:Oracle Portalでは、Oracle Internet Directoryに対してユーザーおよびグループ情報を問い合せるだけでなく、ユーザーおよびグループ情報を追加および変更するユーザー・インタフェースをユーザーに提供する必要があります。ディレクトリ内の情報を変更するには、Oracle Delegated Administration Servicesのユーザー・インタフェースを使用します。Oracle Portalは、ユーザーやグループを追加および変更する権限を持つユーザーに対してOracle Delegated Administration Servicesへのリンクを提供します。詳細は、第7.1.7.5項「Oracle PortalとOracle Delegated Administration Servicesの関係」を参照してください。

- Oracle Directory Integration and Provisioning:Oracle Directory Integration Platformは、Oracle Portalがサブスクライブするなんらかのディレクトリ・イベント(ユーザーの削除など)が発生したときにOracle Portalに通知します。基本的に、Directory Integration Serverは、Oracle Portalにおいて変更が必要なディレクトリで変更が行われたときに、Oracle Portalに通知します。詳細は、第7.1.7.4項「Oracle PortalとOracle Directory Integration Platformの関係」を参照してください。

- Metadata Repository:このメタデータ・リポジトリはリポジトリ作成ユーティリティ(RCU)を使用して作成されており、Oracle Fusion Middlewareコンポーネントの製品メタデータが含まれているスキーマのコレクションで構成されています。Oracle Portalはこのリポジトリに自身のメタデータを格納しているため、実行時にこのメタデータにアクセスする必要があります。

1.2.2 要素を組み合せる方法

ポータルはページのグループで構成されており、各ページは複数のリージョンに分割されています。リージョンは、特定のページの場所をページのアイテムおよびポートレットに割り当てる方法を指定します。

1.2.2.1 Oracle Portalでページが作成される方法

ユーザーがOracle Portalページをリクエストするたびに、そのページに対して選択されているポートレットおよびレイアウトに従って、ページは動的に作成および構成されます。ページを構成する要素は、通常、様々なソースから描画されます。たとえば、ページのレイアウト、外観およびユーザー・パーソナライズは、ポートレット・コンテンツから完全に分離され、すべてのページ定義の一部分としてデータベースに格納されます。この情報は、中間層にキャッシュされる場合もあります。

完全に作成されたページは、そのページのキャッシュ・プロパティに基づいてOracle Web Cacheにキャッシュされます。ただし、フルページ・キャッシュが使用されている場合、ページはOracle Web Cacheから直接提供されるため、リクエストごとに再作成されません。

ページに表示されるポートレットは、PL/SQLまたはJavaで記述できます。PL/SQLポートレットの場合、ソースはOracle Metadata Repositoryデータベースです。このデータベースには、Oracle Portalの現在のインスタンスがインストールされているデータベース、または連携型Portalアダプタを介してアクセスされるリモート・サーバーに配置されているOracle Metadata Repositoryの他のデータベースを使用できます。Javaで記述した場合、Webプロバイダは、ネットワーク(インターネットまたはイントラネット)からアクセス可能な任意の場所からポートレットを提供します。たとえば、様々なプロバイダのコンテンツを表示するポータル・ページを作成できます。プロバイダには、データベース・プロバイダ、Webプロバイダ、WSRPプロデューサなどがあります。

図1-4は、一般的なページの作成方法を示しています。今回のリリースでは、ページ・リクエスト処理のエントリ・ポイントがPPEではなく、Edge Side Includes (ESI)処理を使用したOracle Web Cacheになります。1つのページ・リクエストに含まれる様々なメタデータをより詳細なレベルでキャッシュできるようになるため、キャッシュのヒット率が高まり、ポータル・コンテンツをより細かく無効化することが可能になります。この新しい手法では、Oracle Web Cacheでのセキュアなフルページ・キャッシュもサポートされます。

図1-4 ポータル・ページのリクエスト・フロー

図1-4に、クライアントがOracle Portalページをリクエストする場合に実行される手順を示します。

1. クライアント・ブラウザがポータル・ページをリクエストします。Oracle Web Cacheがこのリクエストを受け取ります。

2. Oracle Web Cacheがページ・スタブを取得します。ページ・スタブは、作成するページの青写真と考えてください。このページ・スタブがOracle Web Cacheにキャッシュされていない場合は、Oracle Portalインスタンスで実行されているPortalサービスによってページ・スタブが生成されます。

注意:

Portalサービスは、ポータル・ページの作成や、ポータルおよびページのメタデータへのアクセスなどに使用されます。Parallel Page Engine (PPE)は、以前からあるPortalサービスの1つで、ポータル・ページを作成します。これ以外に、以前はmod_plsqlで提供されていたようなサービスも、Portalサービスに組み込まれました。

3. Oracle Web Cacheは、ページ・スタブを解析して、ユーザーおよびページのセキュリティ・メタデータを追加取得します。ユーザー・メタデータ(UMD)には、ユーザー名、デバイス・タイプおよび言語などがあります。このユーザー情報は、各ユーザーのセッションごとに一回収集されます。UMDがOracle Web Cacheにキャッシュされていない場合は、Oracle Portalインスタンスで実行されているPortalサービスによってページ・スタブが生成されます。ページ・セキュリティ・メタデータ(SMD)は、指定のURLのコンテンツを閲覧する権限がユーザーにあるかどうかを判断する際に使用される情報です。SMDがWeb Cacheにキャッシュされていない場合、リクエストはPortalサービスによってOracle Metadata Repositoryのポータル・スキーマに送信されます(図1-4には示されていません)。ログインしていないユーザーがプライベート・データをリクエストすると、ログインするよう求められます。そのユーザーにページを閲覧する権限がないと判断された場合は、エラー・ページが表示されます。

4. 完全に作成されたページのコピーがキャッシュにある場合、Oracle Web Cacheはそれを返します。そうでない場合は、Portalサービスのコンテンツをリクエストします。ページのコンテンツは、次のように作成されます。

1. Portalサービスは、キャッシュされたページ・メタデータ(PMD)のコピーをOracle Web Cacheから取得しようとします。PMD、つまりページ定義には、ページのポートレットとそのレイアウトに関する情報が含まれています。Oracle Web Cacheにキャッシュ・ミスがある場合、Portalサービスは、ポータル・キャッシュに有効なキャッシュされたコピーがあるかどうかを確認します。最終的に、キャッシュされたPMDのコピーがない場合は、Oracle Metadata Repositoryのポータル・スキーマによってPMDが生成されます。

2. Portalサービスは、ナビゲーション・ポートレット、バナー、タブ、サブページのリージョンなど共有のページ・コンポーネントがある場合、それらをOracle Web Cacheから取得します。これらのリクエストは同時に実行されます。有効なキャッシュされたコピーがない場合、リクエストはOracle Metadata Repositoryのポータル・スキーマに送信されます。

3. Portalサービスは、ページの各ポートレットについて、そのコンテンツのキャッシュされたコピーがポータル・キャッシュにあるかどうかを確認します。キャッシュ・ヒットがある場合は、キャッシュされたコンテンツが使用されます。キャッシュ・ミスがある場合は、Portalサービスが適切なプロバイダのコンテンツを取り出します。これらのリクエストは、前述の手順で説明したリクエストと同時に実行されます。各プロバイダはポートレットのコンテンツを返します。コンテンツは、Webプロバイダ、WSRPプロデューサまたはデータベース(DB)プロバイダからリクエストできます。

5. Oracle Web Cacheがクライアント・ブラウザに対して完全に作成されたページを返します。

1.2.2.2 Oracle Portalでの通信フロー

Oracle Portalは、複数の通信ポイントおよびプロトコルから構成される分散アーキテクチャを実装します。ファイアウォールとプロキシの導入を含む複雑な構成の場合は、通信ポイント、およびOracle Portalの様々なコンポーネントを統合する方法を理解する必要があります。また、複数のサーバーに様々な機能を分散させるには、ノード間の通信で使用するネットワーク・プロトコルについて知っておく必要があります。

Oracle Portalのアーキテクチャは、クライアント・ブラウザ(図1-5の左端)、中間層サーバー(図の左下)、インフラストラクチャ・サーバーとリポジトリ(図の左上)の3つの基本層で構成されています。デフォルトのインストールではすべてのサーバーとリポジトリを同じホストに配置しますが、パフォーマンスと可用性を向上させるため、これらの機能は別のサーバーにインストールすることをお薦めします。

図1-5は、Oracle Portalの様々なコンポーネント間の通信フローの詳細を示しています。

図1-5 通信フローとプロトコル

次に、3つの層とそこで使用される通信プロトコルについて説明します。

- クライアント

- インフラストラクチャ層

- 中間層

クライアント

- クライアントは、HTTPまたはHTTPSプロトコルを使用して、中間層の一部であるOracle Portalにリクエストを送信します。クライアントと中間層の間では、ファイアウォールおよびプロキシの使用がサポートされています。

- ユーザーを認証する必要がある場合は、クライアント・ブラウザがインフラストラクチャ層のOracle HTTP Serverにリダイレクトされます。この接続はHTTPまたはHTTPSを使用し、ネットワーク環境におけるファイアウォールとリバース・プロキシの両方の実装をサポートしています。

インフラストラクチャ層

インフラストラクチャ層は、Oracle HTTP Server、OracleAS Single Sign-On、Oracle Internet DirectoryおよびOracle Metadata Repositoryから構成されています。

- リクエストしたページで認証が必要な場合は、ユーザーはユーザー名とパスワードを入力するよう要求されます。この機能は、Portalサービスによって、認証のためにOracleAS Single Sign-Onへリダイレクトすることで実行されます。認証リクエストはすべてSQL*Netプロトコルを使用してやり取りされます。

- OracleAS Single Sign-Onは、LDAP/Sを介して、Oracle Internet Directoryを使用してユーザー証明書を検証します。証明書はディレクトリ内で見つかったものと照合され(LDAP比較)、その結果がOracleAS Single Sign-Onに返されます。認証に成功すると、OracleAS Single Sign-Onによってシングル・サインオンCookieが作成されます。ユーザーが認証され、適切なOracle Portalセッションが作成されると、ユーザーはページおよび他のオブジェクトにアクセスできるようになります。

- すべてのポータル・オブジェクトに対するアクセス制御リスト(ACL)はOracle Metadata Repositoryに保持されており、Oracle PortalはLDAP/Sリクエストを使用してOracle Internet Directoryと通信して、ディレクトリ内に定義されている適切なユーザーおよびグループ・メンバーシップ情報を問い合せます。ユーザーが最初にOracle Portalへログインすると、そのユーザーのグループ・メンバーシップがポータル・ノードへコピーされ、その層にキャッシュされます。このプロセスによって、オブジェクトの権限をすばやく検索することができます。ユーザーのオブジェクトおよびページの権限がわかると、Parallel Page Engineは適切な情報からページを生成します。

- ユーザー・プロビジョニングはすべてOracle Internet Directoryに対して行われます。インフラストラクチャ層のOracle HTTP ServerとLDAPサーバー間のインタフェースは、Oracle Delegated Administration Servicesサーブレットを介しています。Oracle Delegated Administration Servicesインタフェースは、LDAP/Sプロトコルを使用してOracle Internet Directoryと通信します。

- OracleAS Single Sign-Onモデルには、mod_ossoが追加されており、これによって、OracleAS Single Sign-On環境ですべてのURLが保護されます。Delegated Administration Servicesサーブレットへのコールは、mod_ossoプラグインによって保護されます。これは、Oracle Internet Directoryへのアクセスを提供する前に、ユーザーが正しく認証されていることを確認します。実際には、mod_ossoはURLを絞り込み、ユーザーが事前に認証されている場合にのみHTTPSベースのリクエストを転送します。

- Oracle Directory Integration Platformでは、ローカルでキャッシュされた情報をOracle Internet Directoryでの変更に合せて自動的に最新の状態にしています。Oracle Directory Integration Platformは、ローカル・キャッシュとOracle Internet Directoryを常に同期化するだけでなく、同様にOracle Internet Directoryと外部のすべてのリポジトリを常に同期化しています。Oracle Directory Integration Platformは、LDAP/Sを介してOracle Internet Directoryと通信します。

中間層

中間層は次の層に分割されています。

中間層はアプリケーション層とWeb層から成り、Oracle Web Cache、Oracle HTTP Server、Oracle WebLogic Serverおよびその他のOracle Portal コンポーネントで構成されています。

注意:

Oracle Web Cache、Oracle HTTP ServerおよびOracle WebLogic Serverは、スケーラビリティと可用性を向上させるために、別のホストにインストールすることができます。

- Oracle Web Cacheを、中間層コンポーネントのフロントエンドに設定して、Oracle Portalのスループットを最適化します。ブラウザからページ・リクエストがあると、Oracle Web CacheはそのURLを評価し、可能な場合はキャッシュからリクエストされたページを提供します。リクエストされたページが以前にキャッシュされていない場合、生成のためにそのリクエストはオリジン・サーバー(この場合はOracle HTTP Server)に転送されます。Oracle Web Cacheは、Webアクセラレータとして、次のコンポーネントとの間でHTTPまたはHTTPS通信を使用できるようにします。

- クライアント・ブラウザ

- 適切なオリジン・サーバー

- オリジン・サーバーとクライアント・ブラウザの両方

- Parallel Page Engine (PPE)は、Oracle Containers for J2EE内でサーブレットとして動作します。サーブレットに対するURLリクエストは、Oracle HTTP Serverのプラグインであるmod_weblogicを介して転送されます。mod_weblogicは、業界標準に準拠したプラグインで、AJP (Apache Java Protocol)を使用してOracle Containers for J2EEと通信します。

- WSRPコンテナは、WSRP仕様およびJava Specifications Request (JSR) 168 APIを実装するJavaポートレット・コンテナです。

- PPE自体は、HTTPSベースの通信を介して、データベース・プロバイダ、WebプロバイダおよびWeb Services for Remote Portlets(WSRP)プロデューサに対してリクエストを行います。データベース・プロバイダに対するレンダリング・リクエストは、PortalサービスへのURLループバックを介して行われますが、Webプロバイダのコールは、HTTPまたはHTTPSを介してSOAPベースのメッセージ・プロトコルを使用して行われます。また、WSRPプロデューサのコールは、Web Services Definition Language (WSDL) URLを使用するWSRPの通信プロトコルを使用して行われます。

- Webプロバイダは、Oracle Metadata Repositoryの情報が必要になると、HTTPまたはHTTPSを介してSOAPベースのメッセージ・プロトコルを使用して、PDKによって適切なコールを行います。

- Oracle Web Cacheコンポーネントは、無効化ベースのキャッシュ法を使用します。リクエストされたURLをキャッシュから提供できる場合は、指定されたURLが無効でないかぎり、そのURLは正しいとみなされます。ユーザーがOracle Portalの操作環境をカスタマイズしている場合、またはユーザーの変更を使用するように構成されている権限の場合、Oracle PortalはOracle Web Cache内で該当するキャッシュ・オブジェクトを無効化します。これを行うために、Oracle Portalは、Oracle Web Cacheの無効化用ポートに対して、Oracle Metadata Repositoryから直接HTTPSベースのリクエストを発行します。

1.3 Oracle Portalのキャッシュの理解

Oracle Portalは、次の場所でデータをキャッシュします。

- ブラウザ - リクエスト間で変更されないデータをキャッシュできます(有効期限ベースのページなど)。

- Oracle Web Cache - 様々なタイプのポータル・データがメモリー内キャッシュ・システムに保存されます。第1.3.1項「Oracle Web Cacheの理解」を参照してください。

- ポータル・キャッシュ - 様々なタイプのポータル・データは永続的なファイル・システムベースのキャッシュにも保存されます。第1.3.2項「ポータル・キャッシュの理解」を参照してください。

Oracle Portalは、次の3つの方法を使用してWebページとコンテンツをキャッシュします。

- 無効化ベースのキャッシュは、Oracle Web Cacheによって使用されます。アイテムは明示的に無効化されるまでキャッシュに残ります。たとえば、ユーザーがアイテムを更新した場合、キャッシュを無効化する必要があります。アップデート処理の一環として、Oracle Metadata Repositoryまたはプロバイダは無効化メッセージをOracle Web Cacheに送信します。無効化されたアイテムに対するリクエストが次に発生したときに、そのアイテムはキャッシュ内で更新されます。無効化ベースのキャッシュに対して有効期間を設定できます。詳細は、第6.7.4.3項「無効化ベースのキャッシュの有効期間の設定」を参照してください。

- 妥当性チェック・ベースのキャッシュは、ポータル・キャッシュによって使用されます。ポータル・キャッシュ内のアイテムが使用される前に、Portalサービスは、Oracle Metadata Repositoryまたはプロバイダにアクセスして、キャッシュされたアイテムがまだ有効かどうかを確認します。

- 有効期限ベースのキャッシュは、ポータル・キャッシュ、Oracle Web Cacheおよびブラウザによって使用されます。有効期限ベースのポートレットはポータル・キャッシュにキャッシュされるのに対し、有効期限ベースで作成されたページはOracle Web Cacheにキャッシュされます。アイテムの保持期間には、アイテムがキャッシュ内で有効である期間を指定します。この期間が経過したら、更新が必要になります。有効期限ベースのキャッシュを使用するページは、ユーザーのブラウザでもキャッシュされる場合があります。

キャッシュは次のレベルで実行されます。

- ユーザー - 各ユーザーに対してデータのコピーが個々にキャッシュされます。

- システム - すべてのユーザーに対して単一のデータのコピーがキャッシュされます。

1.3.1 Oracle Web Cacheの理解

Oracle Web Cacheは強力なサーバー・アクセラレータおよびロード・バランスのソリューションです。Oracle Portalを実行するには、Oracle Web Cacheが必要です。Oracle Web Cacheにはインテリジェント・キャッシュ、ページ・アセンブリおよび圧縮の機能が用意されています。Oracle Web Cacheは、静的および動的なWebコンテンツを迅速に配信し、Oracle Fusion Middlewareにロード・バランスおよびフェイルオーバーの機能を提供します。

中規模から大規模の配置の可用性とスケーラビリティを高めるには、Oracle Web Cacheの複数のインスタンスをキャッシュ・クラスタのメンバーとして実行するように構成します。クラスタは、協調するOracle Web Cacheインスタンスの集合で、連携して1つの論理キャッシュを提供します。キャッシュ・クラスタによって、障害検出とフェイルオーバーが実現され、Webサイトの可用性が向上します。Oracle Web Cacheインスタンスで障害が発生すると、キャッシュ・クラスタの他のメンバーが障害を検出して、障害が発生したクラスタ・メンバーのキャッシュ・コンテンツの所有権を引き継ぎます。これは、リクエストを所有者のキャッシュ・ノードへ転送した後、リクエストを受け取るノードがコンテンツを保持しているために実現されます。

Webサイトのコンテンツを複数のOracle Web Cacheサーバーに分散することで、より多くのコンテンツをキャッシュでき、より多くのクライアント接続をサポートできるため、Webサイトの容量を拡張できます。複数のリクエストが並行して実行されることにより、同時に処理されるリクエストの数が増えるため、CPUの処理能力を高めることができます。

Oracle Portalは、Web Cacheのオリジン・サーバーとして機能し、次のWeb Cache機能を利用します。

- 動的に生成されたユーザー固有のページ構造およびポートレットのコンテンツのキャッシュ

- ファイングレイン・キャッシュ制御

- 無効化ベースのキャッシュ

- レイヤー7のロード・バランスおよびフェイルオーバー検出

- パフォーマンス保証とサージ保護

ポータル・サイトの配置には、次の選択肢があります。

- 同じ場所: Web Cacheは、Oracle Portal中間層と同じ物理サーバーで動作します。この構成は、中間層のスケーラビリティが重要ではない、小規模でデータ量の少ないサイトに適しています。

- 専用: Web Cacheを、1つ以上のOracle Portal中間層サーバーの前に位置する専用サーバーに配置します。通常は、専用の配置では他のサーバー・プロセスとのリソース競合のリスクがないため、同じ場所での配置よりも優れています。Oracle Web Cacheは一般的なハードウェアで十分に機能するため、専用の配置は、ハードウェアの費用の点では負担になりません。
データ量の多い、中規模から大規模のビジネスWebサイトでは、次の理由により、専用配置トポロジの方が優れています。

- リソース競合がない:Oracle Web CacheとOracle Portal中間層を異なるサーバーにインストールすると、異なるサービス間でハードウェア・リソースに対する競合が発生しません。

- パフォーマンス保証とサージ保護:中間層サーバーとキャッシュ・サーバーを分離するトポロジによって、複合的な障害の発生を最小限に抑えることができます。Oracle Web Cacheでは、Webサーバーの負荷が許容量レベルを超えた場合でもサイトのパフォーマンスとスケーラビリティを保証する特許出願中の技術を使用しています。サージ保護メカニズムでは、システムの負荷が過剰な状態を検出することで、トラフィック・スパイクやサービス拒否攻撃に対処するための重要なバッファを提供します。

- サーバー・アフィニティ:Oracle Web Cacheは、複数のOracle Portal中間層サーバーとクラスタ内のプロバイダ間における負荷を均衡するために使用できます。状態を保持する必要がある場合は、Cookieを使用して、特定のサーバーに対する永続的な(スティッキーな)接続を維持できます。

関連項目:

第6.8項「専用のOracle Web Cacheインスタンスを使用するためのOracle Portalの構成」

データ量が非常に多いサイトでシングル・ポイント障害を回避するために、ロード・バランシング・ルーター(LBR)の背後に、Oracle Web Cacheを実行する複数のノードを配置することができます。Oracle Portalを複数配置している場合は、各ポータル・サイトで専用のWeb Cacheサーバーを使用することができます。1つ以上のサイトで、1つのWeb Cacheサーバーを共有することもできます。同様に、プロバイダとポータル・サイトでWeb Cacheを共有することも、プロバイダをホストしているWebサーバーの前に専用のWeb Cacheを配置することも可能です。Oracle Web Cacheの構成の詳細は、第6.7項「Oracle Web CacheにキャッシュされたOracle Portalコンテンツの管理」を参照してください。

Oracle Web Cacheのクラスタは、フェイルオーバーを提供するだけでなく、中間層に転送する負荷を均衡させます。

図1-6 中規模から大規模のポータル構成へのOracle Web Cacheの追加

所有者ノードへ最初のリクエストがあった後、コンテンツはリクエスト側のすべてのインスタンスへキャッシュされます。図1-6では、LBRは着信リクエストを3つのOracle Web Cacheインスタンスに配布しています。リクエストを受け取ったノードでオンデマンド・コンテンツを利用できない場合は、他のインスタンスでキャッシュされたコンテンツが調べられ、リクエストと一致するページがブラウザへ返されます。

Oracle Web Cacheのクラスタ機能を利用するには、各インスタンスをキャッシュ・クラスタのメンバーとして構成する必要があります。この設定では、Oracle Web Cacheインスタンスおよびそれと対応する中間層インスタンスとの間に1対1関係はありません。図1-6に示すように、Oracle Web Cache 1は中間層1、2および3の間でロード・バランスを行います。Oracle Web Cache 2および3も同様に行います。

関連項目:

Oracle Fusion Middleware Oracle Web Cache管理者ガイド

キャッシュとパフォーマンスの詳細は、Oracle Technology Network (OTN)を参照してください。

1.3.2 ポータル・キャッシュの理解

ポータル・キャッシュは、Oracle Portalのページおよびポートレット用のファイル・システムベースのキャッシュです。ポータル・キャッシュでは、妥当性チェック・ベースのキャッシュおよび有効期限ベースのキャッシュがサポートされています。

ポータル・キャッシュは、次の2つの種類のキャッシュで構成されています。

- ポータル・コンテンツ・キャッシュ
コンテンツ・キャッシュには、Oracle Portalで生成された、ユーザー・レベルおよびシステム・レベルのコンテンツが含まれています。この中には、ページ・メタデータ、データベース・ポートレット、Webポートレット、ドキュメント、スタイル・シート、イメージおよびフルページ・キャッシュが含まれています。

- ポータル・セッション・キャッシュ
Oracle Portalは、セッションCookieを使用して、各ポータル・ユーザーのセッションの詳細を保持します。このセッションCookieは暗号化されており、この中にはデータベース・ユーザー名、軽量ユーザー名、セッションのグローバリゼーション・サポート特性などの重要な情報が含まれています。Portalサービスがポータルのリクエストを実行するには、セッションCookieからデータベース・ユーザー名を取得する必要があります。各ユーザーのリクエストでコストの高い復号化処理を避けるために、PortalサービスはセッションCookieをいったん復号化し、関連するCookie詳細をメモリー内のセッション・キャッシュに置きます。メモリー内のセッション・キャッシュが、JVMによってガベージ・コレクションに使用される場合があるので、セッションの詳細もファイル・システムにキャッシュされます。

ポータル・コンテンツとセッション・キャッシュ・コンテンツは、ファイル・システム上にあります。通常は、ファイルDOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_cache.conf内で構成されます。Fusion Middleware ControlからOracle Portalのコンテンツ・キャッシュを指定できます。詳細は、第5.6.6項「Fusion Middleware Controlを使用したポータル・キャッシュの構成」を参照してください。

複数の中間層の構成では、共有ファイル・システム上の各中間層に対してポータル・キャッシュを設定できます。これにより、各中間層はそれぞれのキャッシュからコンテンツを取得しないで、キャッシュされたコンテンツを共有できるようになります。

たとえば、ある中間層は、アイテムに対するリクエストをポータル・キャッシュにキャッシュしてから処理します。複数の中間層を持つ構成に対してロード・バランシング・ルーターを使用するため、アイテムに対する次のリクエストは別の中間層で処理される場合があります。各中間層のポータル・キャッシュが共通のファイル・システム上で共有されている場合、この中間層はキャッシュされたコンテンツにアクセスできます。

ポータル・キャッシュを構成するための様々なパラメータがあります。

- キャッシュの場所

- 総キャッシュ・サイズ

- キャッシュ可能な最大ファイル・サイズ

- キャッシュされたファイルをキャッシュ・システムに保持できる最大時間

- キャッシュ記憶域の消去

関連項目:

- Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド

- 『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のcache.confに関する項

1.3.3 Oracle Portalにおけるキャッシュの無効化の理解

Oracle Portalは、Oracle Web Cacheとポータル・キャッシュの2つのキャッシュ・システムを使用します。Oracle Web Cacheでは、無効化ベースのキャッシュと有効期限ベースのキャッシュがサポートされています。ポータル・キャッシュでは、妥当性チェック・ベースのキャッシュと有効期限ベースのキャッシュがサポートされています。

キャッシュの無効化は、次の2つのグループに分類できます。

- 強い無効化
強い無効化は、1つのブラウザ・リクエストが行われている間キューに入っており、Oracle Portalのユーザー・インタフェース処理が完了すると処理されます。この結果はすぐに表示されます。大半のページ編集およびすべてのポートレットのカスタマイズは、強い無効化として処理されます。

- 弱い無効化
弱い無効化は、多数のブラウザ・リクエストが行われている間キューに保持され、弱い無効化のデータベース・ジョブによって後で処理されます。ユーザーまたはグループにページに対する権限を付与するなど、セキュリティに関する変更は弱い無効化として処理されます。

キャッシュ無効化のリソース要件

無効化は、編集とパーソナライズに基づいてキューに蓄積されます。実行する処理が多いほど、送信される無効化の件数が多くなります。個々の処理では、ポータル・オブジェクトやユーザーが多いほど、対応する無効化の処理に必要なリソースも増えます。たとえば、ユーザー・グループのアクセス権限を変更するには、グループの各ユーザーに対してデータを無効化する必要があります。したがって、グループが大きいほど無効化に必要なリソースが多くなります。別の例を考えてみましょう。大量のページを一括操作で削除する場合、無効化に必要なリソースは削除するページの数に比例します。無効化の処理では、記憶域、CPU、通信の各リソースが必要になります。したがって、キャッシュの無効化が大量に実行されると、システムの処理速度が低下する場合があります。その理由は次のいずれかになります。

- Oracle Web Cacheとの通信
強い無効化または弱い無効化のどちらかが処理されるときに、無効化メッセージを送信するために、Oracle Metadata RepositoryからのOracle Web Cacheの無効化用ポートでTCP/IP接続が確立されます。

強い無効化および弱い無効化のどちらの場合でも、キューに入れられたすべてのメッセージが、TCP/IP接続を使用してOracle Web Cacheへ送信されます。Oracle Web Cacheはこれらの無効化メッセージを受信し、キャッシュされたデータを無効化しようとします。この負荷は、データ・リクエストに応答するOracle Web Cacheの能力に影響を与えることがあります。

- キャッシュ無効化キューの記憶域
強い無効化と弱い無効化の両メッセージは、Oracle Metadata Repositoryのデータベース表内でキューに入れられます。キューのサイズが大きくなるにつれ、キューを保持するためのデータベース・リソースが、より多く必要になります。

- キャッシュ無効化キューの最適化
強い無効化または弱い無効化メッセージの処理中に、キューの最適化によって、重複した、または不要な無効化メッセージが削除されます。たとえば、ページ・グループが無効化される場合、ページ・グループ内の個々のページに対する無効化メッセージは不要です。大量の無効化メッセージがキューに入れられている場合は、最適化のプロセスに長時間かかることがあります。

1.4 WSRPおよびJPSの理解

WSRP仕様とは、Webサービス標準の1つで、ポータルや他の中間Webアプリケーションでのビジュアルなユーザー向けWebサービスのプラグ・アンド・プレイを可能にします。WSRPは標準であるため、特定の言語(Java、.NET、Perlなど)をベースにした標準対応コンテナと、あらゆるWSRPポータルとの間の相互運用性が実現します。そのため、WSRP対応のコンテナにデプロイしたポートレットは、言語に関係なく、この標準をサポートするすべてのポータルにレンダリングできます。WSRPの詳細は、http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.pdfを参照してください。

JPSはJSR 168とJSR 286を基盤としています。Javaを使用する標準ベースのポートレットを構築するAPIのセットを定義します。この仕様に従って構築されたポートレットは、ローカルでポータルにレンダリングできるほか、リモートでポートレットをレンダリングするWSRPコンテナにデプロイすることもできます。JSR 168の詳細は、http://jcp.org/aboutJava/communityprocess/final/jsr168/index.htmlを参照してください。

関連項目:

Oracle Fusion Middleware Oracle Portal開発者ガイド

1.5 まとめ

これで、Oracle Fusion Middlewareのアーキテクチャ、Oracle Portalがどのように適合しているか、Oracle Portalのキャッシュの機能について、およびWSRPプロデューサについての基本的な説明を終わります。次は、第2章「Oracle Portalの計画」に進んでください。この章を読み終えると、インストールをどのように構成したらよいかがわかるようになります。

脚注の凡例

脚注1: ポートレットとして表現されるアプリケーションと情報ソースは、プロバイダを介してポータルと通信します。ポートレットはプロバイダを1つしか持つことができませんが、プロバイダは基盤となるアプリケーションまたは情報ソースを公開する1つ以上のポートレットを持つことができます。

2 Oracle Portalの計画

この章では、Oracle Portalの計画、インストール、構成および管理に含まれるタスク・フローの詳細について説明します。この章を読むと、ポータルを効果的に構築するのに必要なハードウェアおよびソフトウェアをどのように計画すればよいかを理解することができます。

この章の内容:

- 考慮すべき要点

- 必要な作業

注意:

この章で使用されている用語の詳細は、第1章「Oracle Portalのアーキテクチャの理解」を参照してください。

2.1 考慮すべき要点

ポータルの構成を計画するには、システムで実現する目標を明確にすることが重要です。次の各項では、これらの重要な決定事項としてそれぞれ何が含まれるのかを確認します。

- 適切なトポロジの選択

- 必要なハードウェア

- パフォーマンスを最大にする方法

- ポータルを拡張する方法

- ポータルの可用性を向上させる方法

- ポータルを保護する方法

- ハードウェアとソフトウェアを構成する方法

- 構成の機能を向上させる方法

2.1.1 適切なトポロジの選択

Oracle Fusion Middlewareには、様々なトポロジ・オプションが用意されています。Oracle Fusion Middlewareの推奨トポロジには、小規模で一般的な開発の実装から、大規模な企業全体の実装までが含まれています。

関連項目:

- 『Oracle Fusion Middlewareコンセプト』の推奨トポロジの概要

- WebLogic Serverの高可用性

2.1.2 必要なハードウェア

Webポータルをサポートするサーバー、データベースおよびリソースは、特にピーク間隔では様々なユーザー通信量を処理する必要があります。

Webポータルと同様に、ポータルを配置するのに必要なサーバーおよびデータベースの容量は、主に、予想されるユーザー・リクエストの数によって決まります。1つのページをユーザーに表示するには、ユーザーがページの表示を許可されているかどうかの検証、ページに表示されるイメージのロード、ページの書式情報が含まれているスタイル・シートのコールなど、様々な処理が別個に必要になる場合があります。

必要な容量の上限および下限は、ユーザーがどのようにポータルを使用するかによって決まります。ポータルの主要機能が統合の場合は、一般的に負荷の大半が中間層にかかります。一方、大幅にカスタマイズしたコンテンツ・ドリブンのポータルの場合は、リポジトリやインフラストラクチャに負荷がシフトします。少なくとも、ユーザーが受け入れることができるレスポンス時間と、業務時間中の平均負荷を満たすだけのサーバー容量が必要です。可能であれば、ユーザー業務のピーク間隔中に予想されるページ・リクエストの量を満たすようにします。CPU、メモリー、I/O容量、ネットワーク帯域幅などのハードウェア・リソースは、レスポンス時間を短縮するための重要な要素です。Oracle Portalは、多数のトランザクションを処理できるサーバー、またはサーバー・グループにインストールする必要があります。このようにしない場合は、レスポンス時間が長くなることがあります。

サーバーおよびデータベースの容量を追加すると、Webポータルのパフォーマンスは確実に向上しますが、資金を自由に投入できる場合を除き、十分なパフォーマンスと新しいハードウェアおよびソフトウェアを使用できるようにするためのコストとのバランスを保つ必要があります。

関連項目:

Oracle Fusion Middleware管理者ガイド

2.1.3 パフォーマンスを最大にする方法

レスポンス時間は、ユーザー・リクエストが発行されてから、そのリクエストに対するレスポンスが完了するまでの経過時間です。Webポータルは、最小のソフトウェアおよびハードウェア・オーバーヘッドを使用して、できるだけ早く応答する必要があります。パフォーマンスについては、次の点について考慮する必要があります。

- 負荷を分散させる
Webポータル上に大量の通信量が予想される場合は、独自の中間層インスタンスを持つ複数のサーバーに負荷を分散することができます。過剰な通信量によって1つのサーバーがオーバーロードした場合は、別のサーバーがオーバーフローを処理できます。詳細は、第2.1.8.1項「ロード・バランス」を参照してください。

- 障害が発生しないようにする
Oracle Portalを分散構成にすると、Webポータルで利用できるソフトウェア・リソースおよびハードウェア・リソースが増加するので、単一サーバー構成よりも可用性が向上します。サーバーおよびソフトウェアを追加してフェイルオーバーを提供することで、システムに高い安定性を実現できます。詳細は、第2.1.8.2項「フェイルオーバーと冗長性」を参照してください。

- キャッシュ・クラスタを実装する
キャッシュ・クラスタを構成すると、中規模および大規模のデプロイメントの可用性とスケーラビリティを高めることができます。キャッシュ・クラスタによって、障害検出とフェイルオーバーが実現され、Webサイトの可用性が向上します。詳細は、第1.3項「Oracle Portalのキャッシュの理解」を参照してください。

関連項目:

Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド

- ページ、ポートレット・インスタンスおよびテンプレートに合せて最適なキャッシュ・オプションを選択する
キャッシュは、Oracle Portalのパフォーマンスを最大化するための主要な方法です。分散アーキテクチャを使用するとシステムの可用性と速度は向上しますが、キャッシュ法のほうがはるかに重要です。パフォーマンスとスケーラビリティを高めるために、Oracle Portalではいくつかのキャッシュ・オプションが用意されています。詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』にあるページのパフォーマンスの向上に関する章を参照してください。

2.1.4 ポータルを拡張する方法

冗長性は、同じ構成とした複数台のコンピュータを用意することでリクエストに対応する能力を十分に高め、障害やエラーの発生時にバックアップを提供することによって、システムのスケーリングを可能にします。

さらに、ページ、ポートレット・インスタンスおよびテンプレートに合せた最適なキャッシュ・オプションを選択することでスケーラビリティが向上します。Oracle Portalには、そのためのキャッシュ・オプションがいくつか用意されています。詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』にあるページのパフォーマンスの向上に関する章を参照してください。

詳細は、第2.1.8.3項「スケーラビリティ」および第1.3項「Oracle Portalのキャッシュの理解」を参照してください。

2.1.5 ポータルの可用性を向上させる方法

クラスタリングを行うと、単一のOracle Fusion Middlewareインスタンスを使用した場合よりもシステムの可用性を高めることができます。1つのOracle Fusion Middleware上の単一のインスタンスで稼働しているアプリケーションは、そのサーバーが稼働しているオペレーティング・システムとホストに依存しています。このような場合には、ホストが停止するとアプリケーションも使用できなくなるため、ホストはシングル・ポイント障害を引き起こします。

関連項目:

Oracle Fusion Middleware高可用性ガイド

2.1.6 ポータルを保護する方法

重要なデータは、すべてのユーザーが使用するコンテンツに影響を与えずに、セキュリティで保護する必要があります。

Oracle Portalでは、このような柔軟な方法でWebコンテンツへのアクセスを管理できるように、Oracle Fusion Middlewareの他のコンポーネントとOracle Database 11gを活用して、ポータルを強力に保護します。Oracle Portalでは、そのセキュリティ・モデルを実装するために、次のすべてのコンポーネントと対話します。

- Oracle Application Server Single Sign-On

- mod_osso (J2EE Webアプリケーションのシングル・サインオンを容易にするOracle HTTP Serverのリスナー・モジュール)

- Oracle Web Cache

- Oracle Internet Directory

- Oracle Delegated Administration Services

- Oracle Directory Integration Platform

詳細は、第7章「Oracle Portalの保護」を参照してください。

2.1.7 ハードウェアとソフトウェアを構成する方法

この項では、Oracle PortalおよびOracle Fusion Middlewareの関連するすべてのコンポーネントを最適に使用するために、ハードウェアとソフトウェアのインストールをどのように構成するかについて説明します。ここでは、多数のユーザーにサービスを行う大規模なサイトの配置だけでなく、小規模な開発環境を設定するために、ハードウェアをどのように構成するかを説明します。

2.1.7.1 単一のコンピュータの使用

最も単純な構成では、Oracle Fusion Middlewareのすべてのコンポーネントを、図2-1に示すように1台のコンピュータにインストールします。実際には、1つのデータベースをコンピュータに常駐させ、Oracle Portal、Oracle Internet DirectoryおよびOracleAS Single Sign-Onに個別のスキーマを格納することも可能です。

図2-1 Oracle Portal単一のコンピュータ構成

この構成は、開発者がOracle Portalの宣言インタフェースを使用してページ、ポートレットおよびアプリケーションを構築する、小規模な開発環境に適しています。また、完成したWebポータルの小規模なデプロイメントを簡単にサポートできます。より多くのコンテンツをより多くのユーザーに配信する大規模なサイトをデプロイする場合は、図2-1に示すような単一のサーバーまたは単純な構成では不十分です。

2.1.7.2 複数のコンピュータの使用

単一のコンピュータ構成がニーズに適さない場合は、Oracle Portalアーキテクチャの様々な要素を別のコンピュータに移動することを検討します。Webポータルを構成する場合は、使用するサイトの規模に応じて、それぞれ専門の処理を担当する複数のサーバーが必要になります。ハードウェアを追加することでパフォーマンスが向上し、ソフトウェア・インスタンスを追加することで冗長性をサポートできます。

大規模なWebポータル・サイトを構成する場合の配置オプションには、次の作業が必要です。

- Oracle Metadata Repositoryからの中間層の切離し

- Oracle Identity Managementの個別のインストール

- 中間層インスタンスの追加

- 中間層からOracle Web Cacheを切り離したインストール

- インフラストラクチャに対する高可用性の構成

配置したWebポータルの要件が実現されるまで、これらの作業を実行します。たとえば、サイトで通常の作業負荷のみを処理する場合は、最初に中間層をデータベースから切り離してから、Oracle Identity Managementを別のサーバーに移動することを考えます。前述の構成作業をすべて実行する必要はありません。ただし、サイトが拡大するにつれ、前述した順序で基になる構成を拡張する必要があります。

注意:

Webポータルをオンラインにする前に、小規模なテスト・システムで設定およびテストを行うことをお薦めします。これにより、最終的に使用するユーザーに影響を与えずに、実際の使用パターンに基づいて、役に立つ構成情報および調整情報を集めることができます。

2.1.7.2.1 Oracle Metadata Repositoryからの中間層の切離し

大規模なシステムを構成する際に最初に考慮すべきことは、図2-2に示すように、中間層を別にインストールすることです。

関連項目

Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド

図2-2 インフラストラクチャ層からのFusion Middleware中間層の切離し

これにより、Oracle Metadata Repositoryと中間層は、I/O、メモリー、ディスク容量などのハードウェア・リソースの競合から解放されます。また、これらのコンポーネントを別個のコンピュータにインストールすると、パフォーマンスをより柔軟に調整できます。これは、Oracle Metadata Repositoryに多数のコンテンツを格納するようなサイトでは重要です。オペレーティング・システムなどに関する調整パラメータは、HTTP Serverなどの中間層コンポーネントの調整パラメータとは別個になります。一方のパフォーマンス・パラメータを設定しても、もう一方のパフォーマンスが調整されない場合があります。

2.1.7.2.2 Oracle Identity Managementの個別のインストール

OracleAS Single Sign-Onは、Oracle Portalおよび他のアプリケーションのOracle Internet Directoryを使用してユーザー証明書を認証します。したがって、ユーザーは、1つのユーザー名とパスワードを使用してWebポータルに1回ログインするだけで、複数のアカウントとアプリケーションにアクセスできるようになります。

配置されたOracle Portalサイトにログインすると、そのユーザーは、その他のOracleAS Single Sign-Onのセキュアなすべてのアプリケーションにアクセスできます。

図2-3に示すように、Oracle Identity Managementは、Oracle Metadata Repositoryとは別のコンピュータに配置されています。1つのOracle Identity Managementインスタンスを、複数のOracle製品(Oracle Portalの中間層の複数のインスタンスなど)で使用するように構成できます。

図2-3 個別のコンピュータにインストールされたOracle Identity Management

図2-3に示すシステムは、分散構成の例です。この構成では、複数の中間層インスタンスのサポートが可能な集中型のOracle Identity Managementサーバーを採用しています。Oracle Identity Managementを専用サーバーに移動すると、そのパフォーマンスをデータベースと中間層とは無関係に調整できます。

さらに、Oracle Identity Managementを中間層インストールから切り離すことにより、分散システム全体の安定性が高まります。中間層がインストールされているコンピュータに障害が発生しても、OracleAS Single Sign-On、およびログインの検証をSingle Sign-Onに依存するその他の中間層インスタンスは、影響を受けません。また、複数のセキュリティ・ポリシーを使用して、構成内の様々なコンピュータを管理できます。

関連項目:

Oracle Fusion Middlewareインストレーション・プランニング・ガイド

2.1.7.2.3 中間層インスタンスの追加

きわめて大規模なWebポータルに対応するには、それぞれ同一の構成設定とした冗長中間層インスタンスを追加します。追加した中間層インスタンスは、図2-4のようになります。ハードウェアの障害を切り分けることができるように、中間層インスタンスのそれぞれを専用のコンピュータにインストールすることをお薦めします。

図2-4 複数の中間層

中間層はポータル・ページに対するユーザー・リクエストをプロバイダに転送し、返されたコンテンツを使用してページを作成します。中間層インスタンスをOracle Portal構成に追加すると、より多くのユーザー・リクエストを処理できるようになり、ポータル全体のパフォーマンスが向上します。データベースとネットワーク・リソースがより効率的に使用されます。

注意:

この構成の場合、ロード・バランシング・ルーター(LBR)を使用する必要があります。詳細は、第2.1.8.1項「ロード・バランス」を参照してください。

2.1.7.2.4 中間層からOracle Web Cacheを切り離したインストール

Oracle Web Cacheサーバーを中間層から切り離して、データのキャッシュ率の向上、リクエスト時間の短縮、中間層における負荷の軽減を実現することもできます。

Oracle Web CacheはCPUよりもメモリーを消費するため、切り離すと、システムの調整が容易になりパフォーマンスが向上します。また、コンポーネントを切り離すと、キャッシュされたデータとエンド・ユーザーの距離が縮まり、特定のユーザー・コミュニティのネットワーク・エッジでキャッシュされるコンテンツを制限することで効果的にセキュリティが向上します。たとえば、一般的な内部または外部のシナリオでは、特定のキャッシュされたコンテンツを有するコミュニティを対象にOracle Web Cacheの切離しを行うことができます。

2.1.7.2.5 インフラストラクチャに対する高可用性の構成

Oracle Fusion Middleware 11gでは、Cold Failover Cluster、Data Guard、Real Application Clusters (Oracle RAC)などのすべてのOracle高可用性(HA)ソリューションをOracleAS Infrastructureで使用できます。

関連項目:

Oracle Fusion Middleware高可用性ガイド

2.1.8 構成の機能を向上させる方法

Oracle Portalを分散構成にすると、Webポータルで利用できるソフトウェア・リソースおよびハードウェア・リソースが増加するので、単一サーバー構成よりも可用性が向上します。しかし、利点はこれにとどまりません。サーバーおよびソフトウェアを追加してフェイルオーバーを提供することで、システムに高い安定性を実現できます。さらに、複数のサーバー間でロード・バランシングを使用することで、1日を通してWebポータルに発生すると考えられる負荷の大幅な変動に対処できます。最終的に、分散構成にサーバーを増設してユーザーの増加に対応することで、高いスケーラビリティを得ることもできます。

2.1.8.1 ロード・バランス

Webポータル上に大量の通信量が予想される場合は、独自の中間層インスタンスを持つ複数のサーバーに負荷を分散することができます。過剰な通信量によって1つのサーバーがオーバーロードした場合は、別のサーバーがオーバーフローを処理できます。

Oracle Fusion Middlewareは、着信リクエストを処理するサーバー・インスタンスのプーリングを利用して、独自のロード・バランス機能を提供します。1つのインスタンスが応答しない場合、リクエストは別のインスタンスに転送されます。これにより、配置されたサイトのユーザーは、コンテンツとアプリケーションを常に利用できるようになります。

非常に大規模なサイトの場合は、ロード・バランスのハードウェアまたはソフトウェアを追加して、着信リクエストを中間層サーバーに分散できます。図2-5は、この目的で使用するロード・バランシング・ルーター(LBR)を示しています。LBRは、ネットワーク・リクエストを多数のサーバーに配布する高速ネットワーク・デバイスです。これは最も一般的なロード・バランスの方法です。ロード・バランス・ルーターは、各リクエストを特定の中間層サーバーに送信するかわりに、ポータル・ユーザーに公開アドレスを1つだけ提供します。

図2-5 ロード・バランシング・ルーターを使用する複数のサーバー構成

LBRを追加して、着信リクエストを中間層サーバーへ分散させる方法の詳細は、第6.3項「ロード・バランシング・ルーターを使用する複数の中間層の構成」を参照してください。

たとえば、通信量の多い個人用サイトMy.Oracle.com (MOC)で、LBRを使用してリクエストを振り分けるとします。負荷を分散するソフトウェア・ロジックは、中間層サーバーごとに個別にインストールするのではなく、LBR自体に用意されています。このため、LBRを使用すると、構成の管理コストを低減できます。MOCはイントラネットおよびエクストラネットのWebサイトです。それは、オラクル社のオンライン・サービスおよび外部プロバイダのビジネス情報に対するカスタマイズ可能な単一エントリ・ポイントを、オラクル社の従業員に提供します。

LBRを追加すれば、負荷の変動にも対応できます。ユーザーはサイトにアクセスし、アプリケーションを使用して、特定のピーク間隔(ほとんどのユーザーがログインして業務を開始する9 a.m.から10 a.m.など)に非常に高い頻度でコンテンツをリクエストすることがあります。このような大量の通信量が発生する時間に、LBRは、ページ・リクエストを様々な中間層インスタンスに分散して、迅速なレスポンスを確保することができます。

ピーク負荷が定期的に発生する場合は、ピーク負荷要件に対応するための構成を検討します。ピーク負荷の頻度が低い場合は、ハードウェアの投資を追加しないで、ピーク間隔にレスポンス時間の遅延が発生する状態で使用することもできます。

LBR自体を構成してフェイルオーバーをサポートすることもできます。図2-6に示すMy.Oracle.comの構成では、主ルーターに障害が発生した場合に利用できる、2番目のLBRを追加できます。

2.1.8.2 フェイルオーバーと冗長性

フェイルオーバーは、サーバーやデータベースなど、システムの一部に障害が発生した場合にバックアップに切り替える機能です。たとえば、Oracle Database 11gのいずれかに障害が発生しても、バックアップに保存された状態情報を使用して、サービスが再開されます。

冗長性は、同じ構成とした複数台のコンピュータを用意する技法です。冗長コンピュータは、リクエストを十分に処理できる能力を提供するほか、障害やエラーが発生した場合のバックアップとして機能します。冗長性は、構成の中でコンピュータを増設することによって実装します。1台のサーバーがアクティブになっているときは、他のサーバーがそのサーバーの動作を監視して、障害が発生した場合はただちにその処理を引き継ぎます。

図2-6に示すように、My Oracle.comは、他のサーバーで障害の原因となる問題が発生した場合に、引き継ぐことができる追加の中間層サーバーを使用して、フェイルオーバーを提供します。

注意:

図2-6に示しているコンポーネントは、考えられる構成の1つを表しています。オラクル社では、これらの特定のベンダーやコンポーネントを特にお薦めしたり支持しているわけではありません。

図2-6 My Oracle.comの中間層の構成

冗長中間層インスタンスを設定するには、同じサイト名およびサーバー・ポート・エントリ(サイト名がmy.oracle.com、ポートが5000など)で、元のインスタンスと各冗長インスタンスを構成します。つまり、物理的なサイト名とポートが同じである必要はありませんが、冗長層の仮想ホスト参照は同じでなくてはなりません。

冗長性のかわりに、構成全体の余剰容量を使用してフェイルオーバーを提供することもできます。たとえば、75%の容量で稼働中の4台の中間層サーバーがあるとします。1台のサーバーで障害が発生した場合、他の3台が4分の1の作業負荷を引き継ぐことができます(25%×3 = 75%、障害が発生したサーバーの容量に相当)。

2.1.8.3 スケーラビリティ

スケーラビリティは、時間の経過とともにユーザー数およびコンテンツのボリュームが増加したときに、増加したリクエストをWebポータルで処理できるようにする機能です。ポータルで処理可能なトラフィックが増えるため、レスポンス間隔やエラー頻度からユーザーがパフォーマンスの変化に気づくことはありません。スケーラビリティを目標とする場合は、必要に応じてデータベース容量とサーバーを追加しながら、それ以外の構成には影響を与えないような柔軟な構成が必要です。

2.2 必要な作業

この項では、Oracle Portalの計画、インストール、構成および管理に含まれるタスク・フローの詳細について説明します。

Oracle Portalを適切に配置するためには、次の手順が必要です。

1. ポータルの計画

2. Oracle Portalのアップグレード(必要な場合)

3. インストール前の要件の確認

4. Oracle Fusion Middlewareのインストール

5. インストール後の構成の実行(基本的な構成および管理)

6. 拡張構成の実行

7. Oracle Portalの保護

8. Oracle Portalの監視

9. Oracle Portalのトラブルシューティング

次の各項では、各手順の概要を説明し、様々な参照先(この構成ガイド、Oracle Fusion Middleware 11gドキュメント・ライブラリのその他のドキュメント、テクニカル・ホワイト・ペーパーおよびOTN(http://www.oracle.com/technology/)など)の詳細情報について説明します。

2.2.1 ポータルの計画

Oracle Portalを初めて使用する場合は、第1章「Oracle Portalのアーキテクチャの理解」を読むと、Oracle PortalがOracle Fusion Middlewareのアーキテクチャにどのように適合するかを理解することができます。

Oracle Portal構成の計画の詳細は、Portal Center(http://www.oracle.com/technology/products/ias/portal/index.html)を参照してください。

2.2.2 Oracle Portalのアップグレード

Oracle Portalの以前のリリースからのアップグレードに関する最新情報は、OTNのhttp://www.oracle.com/technetwork/middleware/ias/upgrade-087279.htmlを参照してください。アップグレードに関するページには、次の情報が用意されています。

- アップグレード・スクリプトのダウンロード手順

- アップグレードに関するオンライン・ドキュメント

2.2.3 インストール前の要件の確認

インストールをスムーズに行うためには、すべての前提条件を満たしており、インストール前の手順がすべて実行されていることを確認する必要があります。『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』には、Oracle Fusion Middlewareの一般的な要件が記載されていますが、第3章「インストール前およびインストール後の作業」には、ポータル特有の手順が説明されています。

2.2.4 Oracle Fusion Middlewareのインストール

『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』では、Oracle Portalを実行するのに必要なOracle Fusion Middleware中間層およびInfrastructureをインストールする手順を説明しています。詳細は、第3章「インストール前およびインストール後の作業」を参照してください。

2.2.5 インストール後の構成の実行

第5章「基本的な構成および管理」では、Oracle Portalの管理者が実行できる、構成後のすべての作業について説明しています。

詳細は、Portal Center(http://www.oracle.com/technology/products/ias/portal/index.html)を参照してください。

2.2.6 拡張構成の実行

第III部「拡張構成」は、Oracle Fusion Middlewareの管理者を対象としています。第6章「拡張構成」では、仮想ホスト、ロード・バランシング・ルーター、プロキシ・サーバー、Oracle Web CacheおよびOracleAS Single Sign-Onの構成など、Oracle Portalの拡張構成と統合構成を実行する方法を説明しています。第III部の他の章では、検索、インポートとエクスポートなどの機能の詳細について説明しています。

2.2.7 Oracle Portalの保護

第7章「Oracle Portalの保護」では、Oracle Portalでセキュリティ機能を構成するための詳細情報を説明しています。

2.2.8 Oracle Portalの監視

Oracle Portalは、Oracle Enterprise Manager 11g Fusion Middleware Controlから監視できます。詳細は、第8章「Oracle Portalの監視と管理」を参照してください。

また、ポータルのパフォーマンスを監視するパフォーマンス・レポートを生成できます。付録G「パフォーマンス・ログの有効化」を参照してください。このパフォーマンスに関する情報は、この後のOracle Portalのパフォーマンスのチューニングで役立ちます。第11章「Oracle Portalのパフォーマンスの調整」を参照してください。

2.2.9 Oracle Portalのトラブルシューティング

付録G「Oracle Portalのトラブルシューティング」では、様々な問題を解決および診断する方法について説明しています。

第II部

インストールと基本構成

第2部には次の章が含まれます:

- 第3章「インストール前およびインストール後の作業」

- 第4章「相互運用性シナリオ」

- 第5章「基本的な構成および管理」

3 インストール前およびインストール後の作業

この章では、Oracle Portalのインストール前およびインストール後に実行する必要があるインストール・タスクを説明します。各種のトポロジでインフラストラクチャおよび中間層をインストールおよび構成する手順の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』を参照してください。

この章の内容:

- インストールの概要

- インストール後のOracle Portalへのアクセス

- インストール時とインストール後のOracle Portalの構成

Oracle Portalを以前のリリースからアップグレードする場合は、Oracle Technology Network (OTN)のアップグレードに関するドキュメント(http://www.oracle.com/technology/products/ias/portal/upgrade.html)を参照してください。

3.1 インストールの概要

Oracle Portal 11g リリース1 (11.1.1)は、次のような段階を経てインストールされます。

- WebLogic Serverのインストール

- インフラストラクチャ・コンポーネントのインストール

- Oracle Fusion Middleware中間層リリースのインストール

3.1.1 WebLogic Serverのインストール

WebLogic Serverのインストールは、Core Application Server、Administration Console、Configuration WizardおよびUpgrade Framework、Web 2.0 HTTP Pub-Sub Server、JDBC Drivers、WebLogic Server Clients、WebLogic Web Server Plug-Ins、UDDIおよびXquery Support、Server Examplesで構成されます。WebLogic Serverのインストールには、Oracle WebLogic Serverリソースに論理的に関連するグループであるOracle WebLogic Server管理ドメインが含まれます。ドメインには管理サーバーという特別なOracle WebLogic Serverインスタンスが含まれており、ドメイン内のすべてのリソースがそこで一元的に構成および管理されます。通常、ドメインは、管理対象サーバーというOracle WebLogic Serverインスタンスも含めるように構成します。管理対象サーバーは、ポータル・アプリケーション・コンポーネント、Webサービスおよびそれぞれの関連リソースをホストします。Webアプリケーション、EJB、Webサービスおよびその他のリソースは管理対象サーバーに配置し、アプリケーション・サーバーは構成および管理にのみ使用します。管理対象サーバーはクラスタにグループ化できます。

デフォルトのPortal管理対象サーバーはWLS_PORTALで、次の場所にあります。

DOMAIN_HOME\config\fmwconfig\servers

注意:

Oracle Portalのインストールを続行する前に、WebLogic Serverがインストールされていることを確認してください。Oracle WebLogic Serverインストレーション・ガイドを参照してください。WebLogic ServerをインストールするとMiddlewareホームが作成されます。Middlewareホームは、すべてのOracle Fusion Middlewareコンポーネントのインストールに使用されます。

3.1.2 インフラストラクチャ・コンポーネントのインストール

インフラストラクチャのインストールには、次の作業が含まれます。

- Oracle Databaseのインストール

- Oracle Metadata Repositoryのインストール

- Oracle Single Sign-On 10gおよびOracle Delegated Administration Services 10gのインストール

注意:

詳細は、表3-1「インストール・コンポーネントおよびバージョン」を参照してください。

Oracle Databaseのインストール

Oracle Databaseでは、優れたパフォーマンス、信頼性およびスケーラビリティでPortalデータの格納、更新および効率的な取得を実現できます。サポート対象のリリースのOracle Databaseをインストールする必要があります。詳細は、OTNのhttp://www.oracle.com/technetwork/middleware/downloads/fmw-11gr1certmatrix.xlsにある、Oracle Fusion Middleware 11gR1のシステム要件およびサポートされるプラットフォームを参照してください。

関連項目:

『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』および「RCUを使用したPortalスキーマのロード」

Oracle Metadata Repositoryのインストール

メタデータ・リポジトリには、Oracle Portalのメタデータが格納されます。Oracle Fusion Middlewareの構成に関するメタデータやPortalのメタデータも格納できます。

インフラストラクチャのインストール時に、Oracle Metadata Repositoryによって新しいデータベースが作成され、Oracle Portalコンポーネントが使用するスキーマのコレクション(Oracle Portalメタデータ・スキーマなど)がデータベースに移入されます。

リポジトリ作成ユーティリティ(RCU) CD-ROMを使用して、1つのデータベースに複数のリポジトリを作成できます。必要なPortalスキーマはRCUで作成します。詳細は、第3.1.2項「RCUを使用したPortalスキーマのロード」を参照してください。

Oracle Portalをインストールすると、いくつかのデフォルトのデータベース・スキーマとユーザー・アカウントもインストールされます。デフォルトのデータベース・スキーマの詳細は、第7章「Oracle Portalの保護」の第7.3.1項「Oracle Portalのセキュリティ・オプションの構成」を参照してください。

関連項目:

Oracle Fusion Middlewareインストレーション・プランニング・ガイド

注意:

次に進む前に、インストールするPortalのスキーマを作成します。

Oracle Single Sign-On 10gおよびOracle Delegated Administration Services 10gのインストール

Oracle Identity Managementを使用すると、様々なサーバーでユーザー、デバイスおよびサービスのIDを構成および管理したり、それらのIDの管理を委任したり、エンドユーザーにセルフサービス権限を与えたりすることができます。また、エンタープライズ・アプリケーション間でシングル・サインオン・アクセスを構成および有効化し、オンライン・リソースへのアクセスを有効な資格証明を持つユーザーに制限することができます。

Oracle Portalでは、10g リリースのOracle Single Sign-On (SSO)とOracle Delegated Administration Services (DAS)が必要です。これらの10gコンポーネントにアクセス不可能な場合は、コンポーネントをインストールして、製品が適切に機能するようにしなければなりません。詳細は、Oracle Identity Management 10g (10.1.4.0.1)ドキュメント・ライブラリ(http://download.oracle.com/docs/cd/B28196_01/index.htm)を参照してください。

RCUを使用したPortalスキーマのロード

リポジトリ作成ユーティリティ(RCU)は、データベースでOracle Fusion Middlewareデータベース・スキーマを作成および管理するためのグラフィカルなCLIベースのツールです。Oracle Portalをインストールするには、データベースにスキーマが作成されている必要があり、RCUを使用してスキーマをデータベースに作成およびロードします。Portalスキーマを作成するには、次の手順を実行します。

1. ORACLE_HOME\bin\rcu.batからrcu.bat (Windows)を実行します。

2. 「ようこそ」画面が表示されたら、「次へ」をクリックします。

3. 「リポジトリの作成」画面で「作成」を選択してコンポーネントのスキーマをデータベースにロードし、「次へ」をクリックして続行します。

4. データベース接続詳細画面で、次の情報を入力します。

- データベース・タイプ: ドロップダウン・リストからデータベース・タイプを選択します。

- ホスト名: データベースが実行されているサーバーの名前を入力します。次の形式で入力します。
myhost.mydomain.com

Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。

- ポート: データベースのポート番号を入力します。Oracleデータベースのデフォルトのポート番号は、1521です。

- サービス名: データベースのサービス名を入力します。通常、サービス名はグローバル・データベース名と同じです。

- ユーザー名: データベースのユーザー名を入力します。

- パスワード: データベース・ユーザーのパスワードを入力します。

- ロール: ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

「次へ」をクリックします。

「リポジトリ作成ユーティリティ - 前提条件チェック」画面が表示されます。すべての前提条件が満たされたら「OK」をクリックします。

5. 「コンポーネントの選択」画面で、データベース・スキーマに追加する接頭辞(MPSなど)を入力して、次のチェック・ボックスのみを選択します。

- 「AS共通スキーマ」とその下のメタデータ・サービス・ポータルを選択します。

- 「WebCenter Suite」とその下の「WebCenterポートレット」を選択します。

「次へ」をクリックします。

前提条件を確認したら、「OK」をクリックします。

6. 「スキーマ・パスワード」画面で、主要スキーマ・ユーザーおよびその他の補助スキーマ・ユーザーごとにスキーマ・パスワードを入力します。

7. 「次へ」をクリックしてデフォルトの設定を受け入れて、「表領域のマップ」画面で次の操作を行います。

- 「はい」をクリックして、不足する表領域をRCUで作成できるようにします。

- 不足する表領域がある場合は、「OK」を選択して表領域の作成を確認します。

8. 「サマリー」画面(作成操作)の情報を確認し、「作成」をクリックしてスキーマの作成を開始します。

9. 「完了サマリー」画面でログ・ファイルの場所を書き留め、「閉じる」をクリックして画面を終了します。メインRCUログ・ファイルおよびコンポーネント・ログ・ファイルが、次のディレクトリに書き込まれます。
ORACLE_HOME\rcu\log\logdir.date_timestamp

関連項目:

Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド

3.1.3 Oracle Fusion Middleware中間層リリースのインストール

Oracle Fusion Middleware中間層のインストール時に、Oracle Portalは、インフラストラクチャ・サービスを使用するように構成されます。中間層のポータル・アプリケーションの配置も、このときに実行されます。この場合の手順は、次のとおりです。

1. Oracle Web Cacheの構成情報が、Oracle Metadata RepositoryのOracle Portalスキーマに格納されます。

2. ユーザーとグループの情報が、Oracle Internet Directoryで作成されます。

3. Oracle Fusion Middlewareのプロバイダ・グループが、Oracle Portalに追加されます。

4. Oracle Portalサービスの監視が構成されます。

5. プロバイダのユーザー・インタフェースが、Oracle Portalで動作するように構成されます。Oracle Portalからプロバイダのユーザー・インタフェース・フレームワークにアクセスするために使用される中間層URLが、「グローバル設定」ページに追加されます。

6. デフォルトのWebプロバイダ(OmniPortletとWebクリッピング)が登録されます。

7. Web Services for Remote Portlets(WSRP)コンテナがインストールされます。
ポータル・リポジトリ・データベースには、このWSRPコンテナのデフォルトのプリファレンス・ストアが格納されます。詳細は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。

注意:

Oracle Portalでは、すべてのWSRPプロデューサとの通信がサポートされます。

8. WSRPコンテナの実行用に、サンプルのJSR 168アプリケーションがインストールされます。

9. Oracle TextとSecure Enterprise Searchが構成されます。

10. Oracle Portal DADは、インストール時に指定したパラメータを使用して構成ファイルDOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_dads.confに作成されます。

11. webcache.xmlファイルがORACLE_INSTANCE\config\WebCache\webcache1に作成されます。
webcache.xmlには、Oracle Web Cacheの無効化の設定が格納され、OmniPortletやWebクリッピングなどのWebプロバイダで使用されます。詳細は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。

これらの手順の詳細は、インストール後に、\Program Files\Oracle\Inventory\logsファイル(Windows)および/etc/oraInst.locファイル(Unix)を参照してください。

Oracle Portalのデフォルトのユーザー・アカウントとグループの詳細は、第7.1.2.1項「Oracle Portalのデフォルトの生成済ユーザー・アカウント」および第7.1.2.2項「Oracle Portalのデフォルトの生成済グループ」を参照してください。

特に設定をしていない場合、この新規データベースの初期化パラメータはユーザー数がわずかな非常に小規模なOracle Portal構成に適しています。Oracle Portalの使用を計画している場合は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』で指定された設定を使用して、既存データベースにOracle Metadata Repositoryをインストールする際の要件に従って初期化パラメータを変更することをお薦めします。構成の変更時に、使用する構成の規模およびOracle Portalの同時使用ユーザー数に応じて初期化パラメータをさらにチューニングすることが必要な場合もあります。

3.1.4 インストール・コンポーネントおよびバージョン

表3-1に、様々なインストール・コンポーネントとそのバージョンを示します。

表3-1 インストール・コンポーネントおよびバージョン

データベースの数

Oracle WebLogic Server

インフラストラクチャ・コンポーネント

Oracle Fusion Middleware中間層

1つのデータベース

10.3.4.0

- Oracle Database: Identity ManagementおよびMetadata Repository: 10.2.0.4以降および11.1.0.7

- Oracle Metadata Repository: 10.1.4.0.1

- Oracle Single Sign-On 10gおよびOracle Delegated Administration Services 10g: 10.1.4.0.1 + PS3+(パッチ: 7215628 - 10.1.4.3.0)

- リポジトリ作成ユーティリティ: 11.1.1.4.0

11.1.1.4.0

2つのデータベース

10.3.4.0

- Oracle Database: Identity Management 10.1.0.5(シード)およびMetadata Repository 10.2.0.4以降および11.1.0.7

- Oracle Metadata Repository: 10.1.4.0.1 (IM)

- Oracle Single Sign-On 10gおよびOracle Delegated Administration Services 10g: 10.1.4.0.1 + PS3+(パッチ: 7215628 - 10.1.4.3.0)(IM)

- リポジトリ作成ユーティリティ: 11.1.1.4.0 (MR)

11.1.1.4.0

2つのデータベース

10.3.4.0

- Oracle Database: Identity Management IM: 9.2.0.7、10.1.0.5または10.2.0.2(コロケート) (Oracle Application Server Metadata Repository作成アシスタント・ユーザーズ・ガイドを参照)、およびMetadata Repository 10.2.0.4以降、11.1.0.7

- Oracle Metadata Repository: 10.1.4.0.1 (IM)

- Oracle Single Sign-On 10gおよびOracle Delegated Administration Services 10g: 10.1.4.0.1 + PS3+(パッチ: 7215628 - 10.1.4.3.0)(IM)

- リポジトリ作成ユーティリティ: 11.1.1.4.0 (MR)

11.1.1.4.0

3.2 インストール後のOracle Portalへのアクセス

この項では、インストール後にOracle Portalにアクセスするための手順について詳しく説明します。

1. お使いのブラウザで次のURLを入力して、Oracle Portalにアクセスします。

http://<host>:<port>/portal/pls/<dad>

例:

http://portal.example.com:8090/portal/pls/portal

「Portalビルダー」ページが表示されます。

表3-2は、Oracle Portalへのアクセス時に使用するURLの構成要素を示しています。

表3-2 Portal URLの説明

パラメータ

説明

host

Oracle Portalをインストールしてあるコンピュータを定義します。

ホスト名と絶対ドメイン名の両方を入力してください。たとえば、host.domain.comのように入力します。

この名前は、ORACLE_INSTANCE\config\OHS\ohs1にあるhttpd.confという構成ファイルのServerNameパラメータとも一致している必要があります。

ポート

Oracle Portalにアクセスするためのポート番号を定義します。

これはOracle Web Cacheのリスニング・ポートです。

portal

Oracle Portal WLS内で実行されているPortalサービスへリクエストをルーティングするように指定します。

注意: 以前のバージョンでは、Oracle PortalのURLの書式はhttp://<host>:<port>/pls/<dad>でした。Oracle HTTP Server構成のリライト規則により、このようなURLに対する下位互換性が提供されます。この規則を使用することで、URLの/pls/<dad>が、/portal/pls/<dad>に書き換えられます。古い書式のURLにアクセスが行われると、Oracle Portalは、そのURLを直接処理するか、ブックマークを作成したURLを新しい書式に変更するようユーザーに警告を表示します。

pls

リクエストがPL/SQLプロシージャであることを指定します。

dad

Oracle Portalのインストール用に指定したデータベース・アクセス記述子(DAD)を定義します。DADには、データベースへの接続方法に関する情報が入っています。通常のデフォルトのインストールでは、DADは'portal'です。

2. 右上端にある「ログイン」リンク(図3-1を参照)をクリックします。

図3-1 「ログイン」リンク

3. orcladminパスワードを使用して、orcladminユーザーとしてログインします。
ログインすると、デフォルトでは「ようこそ」タブに移動します。ここでドキュメント・ライブラリを参照したり、クイック・ヒントおよび「Oracle Portalの開始」に移動できます。

3.3 インストール時とインストール後のOracle Portalの構成

中間層(Oracle Portalを含む)のインストール時に、構成を行うかどうかを指定し、インストールの最後でOracle Portalを自動的に起動することができます。そのオプションを選択すると、Oracle Universal Installer (OUI)によってOracle Portalが構成されます。

「インストールのみ」を選択すると、Portalの構成は行われません。インストール後にOracle Portalを構成するには、『Oracle Fusion Middleware Oracle Portal, Forms, Reports and Discovererインストレーション・ガイド』の「インストールのみ」の項を参照してください。

4 相互運用性シナリオ

この章では、Oracle Portal 11g リリース1 (11.1.1)の相互運用性シナリオおよび考慮事項を紹介します。

関連情報については、次のドキュメントを参照してください。

- Oracle Fusion Middleware Oracle Portal、Forms、Reports、Discovererインストレーション・ガイド

- Oracle Fusion Middleware Oracle Portal、Forms、Reports、Discovererアップグレード・ガイド

相互運用性シナリオ

- Oracle Portal 11gリリース1 (11.1.1)とOracle Reports 11gリリース1 (11.1.1)

- Oracle Portal 11g リリース1 (11.1.1)とOracle Business Intelligence (BI) Discoverer 11gリリース1 (11.1.1)

- Oracle Portal 11gリリース1 (11.1.1)とOracle Identity Management 11gリリース1 (11.1.1)

- Oracle Portal 11gリリース1 (11.1.1)とOracle BPEL Process Manager 11gリリース1 (11.1.1)

- Oracle Portal 11gリリース1 (11.1.1)とOracle WebCenter Portal 11gリリース1 (11.1.1)

- Oracle Portal 11gリリース1 (11.1.1)とOracle Identity Management 10.1.4.x

- Oracle Portal 11gリリース1 (11.1.1)中間層とOracle Portal 10.1.4.xリポジトリ

- Oracle Portal 11gリリース1 (11.1.1)中間層とOracle Portal 10.1.2.xリポジトリ

- Oracle Portal 11gリリース1 (11.1.1)中間層とOracle Identity Management 10.1.4.xおよびOracle Portal 10.1.xリポジトリ

- Oracle Portal 11gリリース1 (11.1.1)中間層とOracle Identity Management/Single Sign-On 10.1.4.xおよびOracle Portal 10.1.xリポジトリ

- Oracle Portal 11gリリース1 (11.1.1)とOracle Identity Management 10.1.2.3およびOracle Single Sign-On/Oracle Delegated Administration Service (DAS) 10.1.2.3

- Oracle Portal 11gリリース1 (11.1.1)とOracle Access Manager 11gリリース1 (11.1.1)

- Oracle Portal 11gリリース1 (11.1.1)とSecured Enterprise Search (SES) 10.1.8.3。この相互運用性シナリオが機能するためには、https://support.oracle.comからAutomated Release Update (ARU) 11142341をダウンロードしてインストールする必要があります。

- Oracle Portal 11gリリース1 (11.1.1)とSecured Enterprise Search (SES) 10.1.8.4。この相互運用性シナリオが機能するためには、https://support.oracle.comからAutomated Release Update (ARU) 10984348および11142341をダウンロードしてインストールする必要があります。

5 基本的な構成および管理

この章では、Oracle PortalがOracle Fusion Middlewareコンポーネントとともにインストールされていると仮定し、インストールの完了後にポータル管理者が実行できる基本的な作業について説明します。

この章の内容:

- Oracle Portalの管理のスタート・ガイド

- Oracle Portalに関する情報の検索

- 基本的なページ管理の実行

- 自己登録の構成

- 承認のためのOracle BPELプロセス定義の設定

- 基本的なポータル管理の実行

- Oracle Portalでのモバイル・サポートの構成

- ユーザー、グループおよびパスワードの管理

- ブラウザ設定の構成

- 言語サポートの構成

- Oracle Portal WebDAVの構成

- リソース・プロキシの構成

5.1 Oracle Portalの管理のスタート・ガイド

Oracle Portalの基本構成は、Oracle Portalの「管理」タブで実行できます。また、Oracle Portalおよび関連するコンポーネントを構成するためのその他の管理ツールも用意されています。

この項では、様々な管理ツールを紹介します。

- Oracle Portalの「管理」タブの使用

- その他の管理ツールの使用

5.1.1 Oracle Portalの「管理」タブの使用

Oracle Portalフレームワークには、監視および構成ツールへのアクセス、シングル・サインオン、ディレクトリ統合、キャッシュおよびセキュリティなどの管理サービスがあります。ユーザーとグループの管理、セキュリティと検索機能の設定、ポータルとデータベースの管理に必要な多くの機能が、ポータル・ページでポートレットを介してアクセスする一連のダイアログ・ボックスに組み込まれています。

Oracle Portalをインストールしたら、管理者としてログインし(デフォルトのユーザー名はorcladmin)、様々な管理機能を実行する必要があります。Oracle Portalにログオンすると、「Portalビルダー」ページが表示されます。

「管理」タブをクリックしてすべてのサブタブとポートレットを表示すると、ポータルを管理しやすくなります。「管理」タブは、図5-1のように表示されます。

図5-1 「Portalビルダー」ページの「管理」タブ

「管理」タブ画面には次のサブタブが表示されます。

- ポータル - このサブタブでは、ユーザーとグループの作成、OracleAS Single Sign-On (SSO) Serverの管理のほか、Oracle Internet Directory、Secure Enterprise Search、Web Cache、プロキシ設定などのサービスの管理を行えます。

- 「ポートレット」 - このサブタブでは、ポートレット・リポジトリの表示、ログの更新、リモート・プロバイダとプロバイダ・グループの登録を行うことができます。

- 「データベース」 - このサブタブでは、データベース・スキーマの作成と編集、データベース・ロールの作成と編集、さらにデータベース・パラメータ、メモリー使用量、データベース記憶域の詳細などのデータベース情報の監視を行うことができます。

ポータル

「Portalビルダー」ページの「管理」タブにあるこのサブタブには、表5-1に示すポートレットがあります。このサブタブは、「管理」タブをクリックするとデフォルトで表示されます。

表5-1 「ポータル」サブタブのポートレット

ポートレット名

可能な作業

サービス

- デフォルト・ホームページやデフォルト・スタイルなどを指定します。

- Oracle Internet Directoryにあるユーザーとグループの管理や、ディレクトリ設定の構成を行います。

- ログ・レジストリを管理します。

- 基本検索と拡張検索の機能を設定します。

- プロキシ・サーバーの設定を指定します。

- Oracle Portalとその依存コンポーネント(Oracle HTTP Server、Portalサービス、Oracle Metadata Repository、Secure Enterprise Search、プロバイダなど)のパフォーマンスをOracle Enterprise Manager 11g Fusion Middleware Controlを使用して管理および監視します。

- Oracle BPELプロセス定義を管理し、BPELコールバックを構成します。

ログ・レジストリの管理とOracle Portalのパフォーマンスの監視の詳細は、第8章「Oracle Portalの監視と管理」を参照してください。

トランスポート・セット - エクスポート・サービス

- トランスポート・セットをエクスポートします。

- トランスポート・セットについて、ステータスの参照、スクリプトのダウンロード、再使用、エクスポートまたは削除を行います。
詳細は、第12章「Oracle Portalでのエクスポート」を参照してください。

トランスポート・セット - 取得サービス

- データベース・リンクをソース・ポータルとして登録します。

- ソース・ポータル登録をブラウズまたは削除します。

- トランスポート・セットをソースポータルからポータルへ取得します。

- 詳細は、第12章「トランスポート・セットの取得サービス」を参照してください。

トランスポート・セット - インポート・サービス

- トランスポート・セットを検証します。

- トランスポート・セットをインポートします。

- トランスポート・セットについて、ステータスの参照、事前チェック、インポートまたは削除を行います。

- 詳細は、第12章「Oracle Portalでのインポート」を参照してください。

Oracle Reportsセキュリティ

- Oracle Reportsオブジェクトへのアクセスを定義します。

- 定義ファイルをレポートします。

SSO Server管理

- OracleAS Single Sign-On (SSO) Server構成を編集します。

- パートナ・アプリケーションの構成情報を作成および編集します。

- 外部アプリケーションの構成情報を作成および編集します。

詳細は、第7章「Oracle Portalの保護」を参照してください。

注意: SSOの設定を変更するには、Oracle Fusion Middlewareの管理者としてログインする必要があります。

Oracle Reportsセキュリティ

- Oracle Reportsオブジェクトへのアクセスを定義します。

- 定義ファイルをレポートします。

ユーザー

- 新しいユーザーを作成し、アカウント情報を指定します。

- ユーザーを編集または削除します。

Portalユーザー・プロファイル

- ユーザーの設定およびグローバル権限の情報をポータルに構築します。

グループ

- グループを作成し、それにユーザーを割り当て、グループ管理者を指定します。

- グループを編集または削除します。

Portalグループ・プロファイル

- グループの設定および権限の情報をポータルに構築します。

ポートレット

「Portalビルダー」ページの「管理」タブにあるこのサブタブには、表5-2に示すポートレットがあります。

表5-2 「ポートレット」サブタブのポートレット

ポートレット名

可能な作業

ポートレット・リポジトリ

- ローカルおよびリモートのすべてのポートレットを表示します。

- リポジトリ内にあるすべてのポートレットに関する情報を更新します。

- ポートレット・リポジトリの更新ログを表示します。

リモート・プロバイダ

- ポートレット・リポジトリにプロバイダを追加します。

- プロバイダに関する構成およびアクセス情報を変更します。

リモート・プロバイダ・グループ

- 1つのURLで複数のプロバイダを登録します。

- プロバイダ・グループの登録を編集します。

データベース

「Portalビルダー」ページの「管理」タブにあるこのサブタブには、表5-3に示すポートレットがあります。

表5-3 「データベース」サブタブのポートレット

ポートレット名

可能な作業

スキーマ

- 新規データベース・スキーマの作成や、既存のスキーマの編集を行います。

ロール

- 新規データベース・ロールの作成や、既存のロールの編集を行います。

データベース情報

- 様々なデータベース関連の情報やパラメータを監視および表示します。

データベースのメモリー使用量、トランザクションおよびロック

- データベースのジョブを監視します。

- メモリー使用量とトランザクションのレポートとチャートを表示します。

- セッションおよびロックを監視します。

- 不要なユーザー・セッションを停止します。

データベース記憶域

- データベース記憶域に関連する様々な情報を監視および表示します。

5.1.2 その他の管理ツールの使用

Oracle Portalの「管理」タブを使用して実行できない管理タスクについては、次のいずれかのツールを使用する必要があります。

- Oracle Enterprise Manager 11g Fusion Middleware Control

- WebLogic Scripting Tool (WLST)コマンドライン・ユーティリティ

- Portalのインストールと構成のスクリプト

5.1.2.1 Oracle Enterprise Manager 11g Fusion Middleware Control

Oracle Enterprise Manager 11g Fusion Middleware Controlは、Oracle Fusion Middlewareとともにインストールされます。Oracle Portalからは、Oracle Fusion Middleware用の管理ツールと見なされます。Oracle Fusion Middleware Controlによって、ユーザーは次の管理作業、および構成に関する操作を実行できます。

- クラスタの管理

- サービスの開始および停止

- ログおよびポートの表示

- リアルタイム監視の実行

- Oracle Fusion Middleware中間層が使用するOracleAS Infrastructureサービスの変更

Oracle Fusion Middleware Controlのこれらの機能の詳細は、第8章「Oracle Portalの監視と管理」を参照してください。

Oracle Portalインスタンスの構成変更の大半は、Portalホーム・ページ、またはPortalホーム・ページからアクセスするコンポーネント・ページのいずれかから行います。Oracle Fusion Middleware Controlのホーム・ページからPortalのホーム・ページを開くには、ナビゲーション・サイドバーを使用してインスタンスを開き、「ポータル」フォルダを開いて、構成するOracle Portalインスタンスを選択します。Fusion Middleware Controlへのアクセス方法は、「Oracle Enterprise Manager 11g Fusion Middleware Controlへのアクセス」を参照してください。

5.1.2.2 WebLogic Scripting Tool (WLST)コマンドライン・ユーティリティ

WebLogic Scripting Tool (WLST)はコマンドライン・スクリプト・インタフェースであり、管理タスクを実行し、WebLogic Serverのインスタンスおよびドメインに対してWebLogic Server構成の変更を開始できます。詳細は、『WebLogic Scripting Tool Command Reference』を参照してください。Portal固有のWLSTコマンドを使用して、次の管理タスクおよび構成タスクを実行できます。

- WLSTを使用したポータルDADの構成

- WLSTを使用したポータル・キャッシュの構成

- WLSTを使用したParallel Page Engineの構成

- WLSTを使用したPortalのWeb Cache設定の構成

- Portal中間層の構成

- Portalサイト属性の構成

- PortalのOracle Internet Directory属性の構成

関連項目:

- Oracle Fusion Middleware管理者ガイドのOracle WebLogic Scripting Tool (WLST)のスタート・ガイド

- WebLogic Scripting Toolコマンド・リファレンス

5.1.2.3 Portalのインストールと構成のスクリプト

Oracle Portalのインストール時に、ORACLE_INSTANCEに様々なスクリプトがコピーされます。これらのスクリプトは、管理操作を実行するときに必要となります。これらのスクリプトの詳細は、付録B「Oracle Portalのインストールおよび構成スクリプトの使用」を参照してください。

5.2 Oracle Portalに関する情報の検索

この項の内容:

- ブラウザでのOracle Portalへのアクセス

- Oracle Portalのリリース番号の検索

5.2.1 ブラウザでのOracle Portalへのアクセス

Oracle Portalがインストールされたら、ブラウザで次のURLを入力してアクセスします。

http://<host>:<port>/portal/pls/<dad>

URLの構成要素の詳細は、表3-2「Portal URLの説明」を参照してください。

このリリースでは、下位互換性を維持するために古いURL構文がサポートされています。たとえば、http://<host>:<port>/pls/<dad>です。

関連項目:

第3.1項「インストールの概要」

5.2.2 Oracle Portalのリリース番号の検索

ポータルのリリース番号を調べるには、次の手順を実行します。

1. ポータル管理者としてログインします。

2. 「Portalビルダー」で、「管理」タブをクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

3. 「ポータル」タブをクリックします。

4. 「サービス」ポートレットで、「グローバル設定」リンクをクリックします。
Oracle Portalのリリース番号がページの下部に表示されます。

5.3 基本的なページ管理の実行

この項の内容:

- デフォルト・ホームページの設定

- システムのデフォルト・スタイルの設定

- 個人用ページの作成

- アップロード・ファイルに割り当てる総容量の設定

- アップロード・ファイルの最大ファイル・サイズの設定

- ページ・グループ割当ての変更

- エラー・メッセージ・ページの指定

- 認証されていないユーザー用のデフォルト・ページの設定

- ページ用のデフォルトのDOCTYPEの指定

- 状況依存ヘルプ・リンクの削除

5.3.1 デフォルト・ホームページの設定

ホーム・ページは、ユーザーがOracle Portalにログインすると最初に表示されるページです。次のようなロジックが適用されます。

- ユーザーが個人用のホーム・ページを指定している場合は、ユーザーがログインするとそのページが表示されます。

- ユーザーが個人用のホーム・ページをまだ選択していないが、ポータル管理者がそのユーザーのために設定している場合は、そのユーザーに指定されているデフォルト・ホームページが表示されます。

- ユーザーが個人用のホーム・ページを選択していない場合でも、デフォルトのグループに属していれば、そのグループに指定されたデフォルト・ホームページが表示されます。

- ユーザーのデフォルト・グループにデフォルト・ホームページがない場合や、ユーザーにデフォルト・グループがない場合は、システムのデフォルト・ホームページが表示されます。

注意:

システム、グループまたはユーザーのデフォルト・ホームページを定義するには、ポータル管理者であることが必要です。

5.3.1.1 システムのデフォルト・ホームページの設定

ユーザーのデフォルト・グループのデフォルト・ホームページがない場合は、システムのデフォルト・ホームページが表示されます。

システムのデフォルト・ホームページを設定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「デフォルト・ホームページ」フィールドの横の「ページをブラウズ」アイコンをクリックし、選択するページのリストを表示します。

注意:

このフィールドには値を入力できません。リストからいずれかを選択してください。

3. システムのデフォルト・ホームページにするページの横の「オブジェクトを戻す」をクリックします。

4. 「OK」をクリックして「Portalビルダー」に戻ります。

注意:

システムのデフォルト・ホームページが正しく設定されたことを確認するには、ポータルからログアウトして再度ログインします。ログインしなおすと、指定したページがシステムのデフォルト・ホームページになっています。

5.3.1.2 グループのデフォルト・ホームページの設定

ユーザーが個人用のホーム・ページを選択していない場合でも、デフォルトのグループに属していれば、そのグループに指定されたデフォルト・ホームページが表示されます。

グループのデフォルト・ホームページを設定するには、次の手順を実行します。

1. 「Portalグループ・プロファイル」ポートレットで、「名前」フィールドにデフォルト・ホームページを割り当てるグループの名前を入力します。
デフォルトでは、「ポータル・グループ・プロファイル」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

注意:

グループ名が不明な場合は、「グループをブラウズ」アイコンをクリックし、表示されたリストから選択します。

2. 「編集」をクリックします。

3. 「デフォルト・ホームページ」フィールドの横の「ページをブラウズ」アイコンをクリックし、選択するページのリストを表示します。

注意:

このフィールドには値を入力できません。リストからいずれかを選択してください。

4. グループのデフォルト・ホームページにするページの横の「オブジェクトを戻す」をクリックします。

5. 「OK」をクリックします。

注意:

グループのデフォルト・ホームページを削除するには、「リセット」をクリックします。

5.3.1.3 ユーザーのデフォルト・ホームページの設定

ユーザーは個人用のホーム・ページをまだ選択してないが、管理者がそのユーザーのために設定している場合は、そのユーザーに指定されているデフォルト・ホームページが表示されます。

ユーザーのデフォルト・ホームページを設定するには、次の手順を実行します。

1. 「Portalユーザー・プロファイル」ポートレットで、「名前」フィールドにデフォルトのホーム・ページを割り当てるグループの名前を入力します。
デフォルトでは、「Portalユーザー・プロファイル」ポートレットは「Portalビルダー」ページの「管理」タブにあります。

注意:

ユーザー名が不明な場合は、「ユーザーをブラウズ」アイコンをクリックし、表示されたリストから選択します。

2. 「編集」をクリックします。

3. 「デフォルト・ホームページ」フィールドの横の「ページをブラウズ」アイコンをクリックし、選択するページのリストを表示します。

注意:

このフィールドには値を入力できません。リストからいずれかを選択してください。

4. ユーザーのデフォルト・ホームページにするページの横の「オブジェクトを戻す」をクリックします。

5. 「OK」をクリックします。

注意:

ユーザーのデフォルト・ホームページをシステムのデフォルト・ホームページにリセットするには、「リセット」をクリックします。

5.3.2 システムのデフォルト・スタイルの設定

ポータル管理者は、システムのデフォルトとなるスタイルを選択する必要があります。

あるスタイルが削除されると、そのスタイルを使用していたすべてのページおよびアイテム・リージョンは、ページ・グループのデフォルト・スタイルに戻ります。ページ・グループのデフォルト・スタイルが「<なし>」の場合は、すべてのページおよびリージョンがシステムのデフォルト・スタイルに戻ります。

注意:

システムのデフォルト・スタイルを設定するには、ポータル管理者であることが必要です。

システムのデフォルト・スタイルを設定するには、次の手順を実行します。

1. 「Portalビルダー」で、「管理」タブをクリックします。

2. 「ポータル」サブタブをクリックします。

3. 「サービス」ポートレットで、「グローバル設定」リンクをクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

4. 「デフォルト・スタイル」セクションで、「表示名」リストからスタイルを選択します。

注意:

リストには、「共有オブジェクト」ページ・グループのパブリック・スタイルがすべて含まれています。

5. 「OK」をクリックして「Portalビルダー」に戻ります。

5.3.3 個人用ページの作成

個人用ページを使用すると、Oracle Portal内に、認可されたユーザーが自分のコンテンツを格納したり共有したりできる領域ができます。個人用ページは、「共有オブジェクト」ページ・グループにあり、ユーザー名のアルファベット順に並んでいます。

注意:

ユーザーの個人用ページを作成するには、ポータル管理者であることが必要です。

この項の内容:

- 新しいユーザーの個人用ページの自動作成

- 既存ユーザーの個人用ページの作成

5.3.3.1 新しいユーザーの個人用ページの自動作成

Oracle Portalを構成して新しいユーザーの個人用ページを自動的に作成するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「メイン」タブが表示されていることを確認します。

3. 「新しいユーザーに個人用ページを作成する」を選択します。

4. 「OK」をクリックします。

新しいユーザーが初めてログインしたときに、そのユーザーに個人用ページが自動的に作成されます。

注意:

個人用ページは、新しいユーザーが初めてログインしたとき(つまり、ユーザーにユーザー・レコードが作成されたとき)に自動的に作成され、すでに存在するユーザーには作成されません。

5.3.3.2 既存ユーザーの個人用ページの作成

Oracle Portalを構成して既存ユーザーの個人用ページを作成するには、次の手順を実行します。

1. 「Portalユーザー・プロファイル」ポートレットで、

1. 「名前」フィールドに、個人用ページを作成するユーザーの名前を入力します。

注意:

ユーザー名が不明な場合は、「ユーザーをブラウズ」アイコンをクリックし、表示されたリストから選択します。

2. 「編集」をクリックします。

デフォルトでは、「Portalユーザー・プロファイル」ポートレットは「Portalビルダー」ページの「管理」タブにあります。

2. 「プリファレンス」タブが表示されていることを確認します。

3. 「個人用ページの作成」を選択します。

注意:

このチェック・ボックスが表示されない場合、そのユーザーにはすでに個人用ページが作成されています。

4. 「OK」をクリックします。

注意:

- 個人用ページには、「共有オブジェクト」ページ・グループの「ナビゲータ」からアクセスできます。認可されたユーザーは「共有オブジェクト」ページ・グループの「個人用ページ」領域にドリルダウンできますが、自分の個人用ページまたはアクセス権限が付与されたページの個人用ページを表示することしかできません。

- アルファベットで始まらないユーザー名の付いたユーザーの個人用ページは、「個人用ページ」の「その他」領域にあります。

- 個人用ページは削除できません。

5.3.4 アップロード・ファイルに割り当てる総容量の設定

ページ・グループにアップロードされたドキュメントを格納するために、データベース内に確保される容量を制限できます。1つのページ・グループに割り当てられる容量を制限する場合は、第5.3.6項「ページ・グループ割当ての変更」を参照してください。

コンテンツ作成者がページ・グループにアップロードできる個別のファイルのサイズを制限することもできます。詳細は、第5.3.5項「アップロード・ファイルの最大ファイル・サイズの設定」を参照してください。

ユーザーがファイルをポータルにアップロードするとき、アップロードは中間層で監視され、総容量または最大ファイル・サイズが制限を超過していないかが検出されます。これらの制限のいずれかを超過すると、アップロードは終了し、エラー・メッセージが表示されます。

注意:

アップロード・ファイルに割り当てる総容量を設定するには、ポータル管理者であることが必要です。

アップロード・ファイルに割り当てる総容量を設定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「メイン」タブが表示されていることを確認します。

3. 「割り当てる総容量」ラジオ・グループで、「制限値」を選択してこのポータルのページ・グループにアップロードされるファイルを格納するために確保される総容量を制限します。

4. フィールドに、ポータル全体でアップロード・ファイル用に確保する最大容量をMB単位で入力します。この制限に達すると、ユーザーはポータルのページ・グループにファイルをアップロードできなくなります。

注意:

- アップロード・ファイルに制限を設けない場合は、「制限なし」を選択します。

- 制限が設定されている場合には、「使用済領域」フィールドに、このポータルのページ・グループにアップロードされたドキュメントが現在使用している容量が表示されます。制限が設定されていない場合でも、「計算」をクリックすれば、現在使用している容量を確認できます。計算には、ある程度の時間がかかる場合があります。

5. 「OK」をクリックします。

5.3.5 アップロード・ファイルの最大ファイル・サイズの設定

ポータルのページ・グループにアップロードできる個別のファイルのサイズを制限できます。

ページ・グループにアップロードされたドキュメントを格納するために、データベース内に確保される総容量を制限することもできます。詳細は、第5.3.4項「アップロード・ファイルに割り当てる総容量の設定」を参照してください。

ユーザーがファイルをポータルにアップロードするとき、アップロードは中間層で監視され、最大ファイル・サイズまたはポータル・ファイル割当ての制限を超過していないかが検出されます。これらの制限のいずれかを超過すると、アップロードは終了し、エラー・メッセージが表示されます。

注意:

アップロード・ファイルの最大ファイル・サイズを設定するには、ポータル管理者であることが必要です。

アップロード・ファイルの最大ファイル・サイズを設定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「メイン」タブが表示されていることを確認します。

3. 「最大ファイル・サイズ」ラジオ・グループで、「制限値」を選択してポータルにアップロードされる個別のファイルの最大サイズを指定します。

4. フィールドに、ポータルにアップロードされる個別のファイルの最大サイズをMB単位で入力します。コンテンツ作成者がこのサイズを超えるファイルをアップロードしようとすると、エラーが表示されます。

注意:

最大ファイル・サイズを設けない場合は、「制限なし」を選択します。

5. 「OK」をクリックします。

5.3.6 ページ・グループ割当ての変更

アップロードされたドキュメントを格納するためにページ・グループ内に確保される容量を制限できます。

注意:

ページ・グループ割当てを変更するには、次の権限の少なくとも1つを持っている必要があります。

- ポータル管理者

- ページ・グループの「すべて管理」権限

- すべてのページ・グループの「すべて管理」グローバル権限

ページ・グループ割当てを変更するには、次の手順を実行します。

1. 「Portalナビゲータ」ページで、「ページ・グループ」タブをクリックします。

2. 作業対象のページ・グループの横の「プロパティ」をクリックします。

3. 「ページ・グループ割当て」セクションで、「制限値」を選択してアップロードされたドキュメントを格納するために確保される容量を制限します。

4. フィールドに、ページ・グループにおけるアップロードされたドキュメントのサイズ制限をMB単位で入力します。この制限に達すると、ユーザーはページ・グループにドキュメントをアップロードできなくなります。

注意:

アップロードするドキュメントに制限を設けない場合は、「制限なし」を選択します。

5. 「OK」をクリックします。

5.3.7 電子メール(SMTP)ホストの指定

電子メール・サーバーのホスト名とポートを入力して、アカウントが承認または拒否されたときに自己登録ユーザーが電子メールによる通知を受けるようにします。通常、SMTPのデフォルト・ポートは25です。自己登録ユーザーに即時ログオンを許可する場合、この情報は不要です。

5.3.8 エラー・メッセージ・ページの指定

Oracle Portalでは、ユーザーに表示するエラー・メッセージ・ページを選択できます。デフォルトのシステム・エラー・ページを選択することも、カスタマイズした独自のエラー・ページを指定することもできます。

Oracle Portalには、「サンプル・エラー・ページ」というエラー・メッセージ・ページが含まれており、ポータルにある他のページの外観に合せて編集できます。「サンプル・エラー・ページ」は「Portal設計時ページ」グループにあり、すべての診断情報を表示するポートレットが含まれています。また、独自のエラー・メッセージ・ページを任意のページ・グループに作成することもできます。これを行うには、「エラー・メッセージ」ポートレットをページに含め、キャッシュを無効にする必要があります。

注意:

デフォルトでは、「エラー・メッセージ」ポートレットは、ポートレット・リポジトリの「管理ポートレット」ページにあります。

エラー・メッセージ・ページを指定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「エラー・ページ」セクションで、次のいずれかを選択します。

- 「システム・エラー・ページ」: システム・エラー・ページを使用してフルページのエラー・メッセージをユーザーに表示します。システム・エラー・ページには、すべての診断情報が自動的に含められます。

- 「エラー・ページ」: 独自のページを使用してフルページのエラー・メッセージをユーザーに表示します。「ページをブラウズ」アイコンをクリックし、使用するエラー・メッセージ・ページを選択します。

3. 「OK」をクリックします。

5.3.9 エラー・レポート・スタイルの指定

Oracle Portalでは、ユーザーに表示するエラー・レポート・スタイルを選択できます。セキュアなエラー・レポートを有効にすると、最上位レベルのエラー・メッセージのみが印刷されます。このオプションを選択すると、エラー・コード、原因およびアクションがエンド・ユーザーに公開されるのを防ぐことができます。

5.3.10 認証されていないユーザー用のデフォルト・ページの設定

ユーザーがログアウトした後やポータル・サイトに最初にアクセスしたときに表示されるデフォルト・ページを指定するには、PUBLIC(認証されていない)ユーザー用のデフォルト・ホームページを設定します。

注意:

デフォルト・ホームページを定義するには、ポータル管理者であることが必要です。

ユーザーがログアウトした後やサイトに最初にアクセスしたときに表示されるデフォルト・ページを設定するには、次の手順を実行します。

1. 「Portalユーザー・プロファイル」ポートレットで、「名前」フィールドに「PUBLIC」と入力します。
デフォルトでは、「Portalユーザー・プロファイル」ポートレットは「Portalビルダー」ページの「管理」タブにあります。

2. 「編集」をクリックします。

3. 「デフォルト・ホームページ」フィールドの横の「ページをブラウズ」アイコンをクリックし、選択するページのリストを表示します。

注意:

このフィールドには値を入力できません。リストからいずれかを選択してください。

4. ユーザーがログアウトするときに表示されるページの横の「オブジェクトを戻す」をクリックします。

5. 「OK」をクリックします。

注意:

この設定を削除するには、「リセット」をクリックします。

5.3.11 ページ用のデフォルトのDOCTYPEの指定

ポータル内のすべてのページに使用しているHTMLまたはXHTMLのバージョンを識別するグローバルなデフォルトの文書型を指定できます。グローバルな文書型設定を指定すると、ブラウザのページ表示速度が向上します。

HTMLまたはXHTMLのバージョンを識別するには、ページの最初のコードに次のような文書型宣言を含めます。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

文書型には次のようなものがあります。

- HTML 4.01互換モード

- HTML 4.01 Transitional

- HTML 4.01 Strict

- XHTML 1.0 Transitional

- XHTML 1.0 Strict

注意:

文書型の指定は、生成されたHTMLには影響しません。HTMLの先頭にあるDOCTYPE宣言にのみ影響します。

厳密な文書型(HTML Strictなど)を選択した場合は、この文書型を使用したときに禁止されるHTMLによって、ポートレットのリフレッシュ機能の一部が影響を受けます。具体例は次のとおりです。

- ページの編集時に、「ページ・アセンブリ・タイムアウト」オプションが表示されません。

- ポートレットのリフレッシュでは、ページの部分リフレッシュは使用されず、ページ全体がリフレッシュされます。

また、中央のイメージ位置のオプションを選択すると、HTMLはStrictとして検証されません。これは、この場合はCSS属性ではなくalign属性を使用する必要があること、またalign属性はStrictのガイドラインに準拠していないことが原因で生じます。

ページ・グループでページの文書型を指定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「ページDOCTYPE」セクションで、すべてのページ・グループでデフォルトとして使用するDOCTYPEを選択します。

3. 「ページ・グループに別のDOCTYPE使用を許可する」を選択して、ページ・グループ・レベルでこの設定をオーバーライドできるようにし、特定のページ・グループのページに異なる文書型を指定します。

4. 「OK」をクリックします。

5.3.12 状況依存ヘルプ・リンクの削除

SQL*PLUSにアクセスできる場合は、Oracle Portalのウィザード、ダイアログ・ボックス、アラートなどのバナーに表示される状況依存ヘルプ・リンクを非表示にすることができます。ウィザード、ダイアログ・ボックスおよびアラートの青いバー上の「?」アイコンを非表示にはできません。

この作業はユーザー・インタフェースからは実行できません。SQL*PLUSからプログラムによって行う必要があります。

注意:

ポータル・スキーマとポータルSSOスキーマの両方で、次のAPIコールを行う必要があります。

状況依存ヘルプ・リンクを削除するには、次の手順を実行します。

1. SQL*PLUSにアクセスします。

2. 次のように入力します。

exec wwui_api_body.set_display_help (wwui_api_body.DISPLAY_HELP_OFF);
commit;

状況依存ヘルプ・リンクを回復するには、次の手順を実行します。

1. SQL*PLUSにアクセスします。

2. 次のように入力します。

exec wwui_api_body.set_display_help (wwui_api_body.DISPLAY_HELP_ON);
commit;

5.4 自己登録の構成

ユーザーが独自のポータル・ユーザー・アカウントを作成できるようにするには、自己登録機能を設定する必要があります。このプロセスが終了すると自己登録リンクが「ログイン」ポートレットに表示されます。

アカウントが承認されるまでログインできないように、自己登録ユーザーに対する承認プロセスを設定することができます。アカウントが承認または拒否されると、ユーザーは電子メールによる通知を受けます。

自己登録ユーザーに対して承認を必要としない場合、ユーザーは登録後ただちにポータルにログインできます。

注意:

自己登録を設定するには、ポータル管理者であることが必要です。

自己登録を設定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「自己登録のオプション」セクションで、「自己登録を有効にする」を選択します。

3. 自己登録ユーザーが登録後ただちにポータルにログインできる場合は、「承認は必要ありません」を選択します。

4. 自己登録ユーザーがポータルにログインする前に承認を受ける必要がある場合は、「承認が必要です」を選択します。

1. 「構成」をクリックして承認プロセスを設定します。

2. 「承認者」フィールドに、自己登録ユーザーを承認する必要のあるユーザーまたはグループの名前を入力します。

注意:

複数のユーザーまたはグループを区切るには、セミコロン(;)を使用します。承認ルーティングの各手順には、ユーザーとグループの両方を含めることができます。

3. 「承認者のルーティング・メソッド」で、次のいずれかを選択します。

- 「一度に1人ずつ、全員の承認が必要」: 各ユーザーまたはグループに順番に通知し、すべてのユーザーまたはグループが自己登録ユーザーをログイン前に承認する必要がある場合。

- 「一度に全員、全員の承認が必要」: すべてのユーザーおよびグループに同時に通知し、すべてのユーザーまたはグループが自己登録ユーザーをログイン前に承認する必要がある場合。

- 「一度に全員、1人のみの承認が必要」: すべてのユーザーおよびグループに同時に通知するが、1人のユーザーまたはグループ・メンバーのみが自己登録ユーザーをログイン前に承認する必要がある場合。

4. 「手順を追加」をクリックします。

5. aからdまでの手順を繰り返し、承認プロセスに手順を追加します。

注意:

- このタブの他の設定を変更する必要はありません。この画面の他のタブの設定も同様です。

- 承認連鎖の最終承認者は、ユーザー登録リクエストを承認する権限を持っている必要があります。これを行うには、「アカウント管理の許可」権限を最終承認者に付与します。これらの権限は、DASのデフォルトの「ユーザーの編集」ページで割り当てることができます。

- 承認連鎖の各承認者は、自分のページに「通知」ポートレットがあり、承認待ちの新規ユーザー・アカウントの表示および処理を実行できる必要があります。「通知」ポートレットは、ポートレット・リポジトリの「Portalコンテンツ・ツール」の下にあります。

6. 「OK」をクリックして「グローバル設定」画面に戻ります。

5. 「OK」をクリックします。

6. ポータルのホーム・ページに移動します。

7. 編集モードに切り替えます。

8. ポータルのホーム・ページに「ログイン」ポートレットがまだ含まれていない場合は、ページに「ログイン」ポートレットを追加します。
デフォルトでは、「ログイン」ポートレットはポートレット・リポジトリの「管理」ページの「SSO/OID」ページにあります。

9. 「ログイン」ポートレットの横の「デフォルトの編集」アイコンをクリックします。

10. 「自己登録を有効にする」を選択します。

11. 「自己登録リンクのテキスト」フィールドに、ポータルに登録するときにユーザーがクリックするテキストを入力します。

12. Oracle Portalの自己登録画面を使用する場合は、「自己登録URL」フィールドを空白のままにしておきます。
独自の自己登録画面を作成する場合は、このフィールドにURLを入力します。

13. 「OK」をクリックします。

5.5 承認のためのOracle BPELプロセス定義の設定

Oracle Portalでは、承認機能を使用し、ポータルでのコンテンツの公開を管理および制御できます。ただし、組織にとって組込みの承認機能では少し制限が厳しいという場合は、かわりに承認のためのOracle BPELのワークフロー・プロセスを使用できます。

5.5.1 BPELのワークフローとポータルのワークフローの同期化

Oracle BPELのワークフローは、ポータルのデフォルトのワークフローと連携することが可能です。ただし、ワークフローのステータスはBPELの終了時に変化するため、ポータルのワークフロー表に反映しなおす必要があります。そのためには、ポータルの表を更新するWebサービスをBPELからコールバックします。ポータル承認スキーマへの接続の確立に必要な資格証明は、datasource.xmlで定義する必要があります。

5.5.1.1 コールバックWebサービスの配置

BPELからコールバックされたWebサービスを配置するには、次の手順を実行します。

1. WLS_PORTALにあるdatasources.xmlファイルに新しいJNDIエントリを追加します。JNDI名をPortalApprovalDSと指定します。
データソース・エントリを追加するには、次の手順を実行します。

1. Oracle WebLogic管理コンソールにログインします。

2. まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで「サービス」→「JDBC」の順に開き、次に、「データ・ソース」を選択します。

4. 「データ・ソース」ページの「サマリー」で、「新規」をクリックします。

5. 「JDBCデータ・ソースのプロパティ」ページで、JDBCデータ・ソース名を「jdbc/PortalApprovalDS」と入力します。

6. データベース・タイプとして「Oracle」を選択し、データベース・ドライバとして「Oracleのドライバ(Thin)バージョンXXXXXX」を選択します。

7. 「次へ」をクリックして続行してください。

8. 「トランザクション・オプション」ページで、「グローバル・トランザクション・オプション」を選択し、デフォルトの設定を受け入れて「次へ」をクリックします。

9. 「接続プロパティ」ページで、データベース名、ホスト名、ポート、データベース・ユーザー名(<<PORTAL_SCHEMA_NAME>>_APPROVALなど承認済のスキーマ名とパスワード)を入力し、「次へ」をクリックします。

10. 「データベース接続のテスト」ページで接続パラメータを確認し、「構成のテスト」をクリックします。

11. 「ターゲットの選択」ページで、データ・ソースの配置先サーバーとして「WLS_PORTAL」を選択します。
クラスタ・ポータルを使用している場合は、WebLogic管理コンソールにログインして「ドメイン名」→「環境」→「クラスタ」→「クラスタ・アドレス」を選択し、クラスタ・アドレスに対するポータル・マシン名を指定する必要があります。必要な情報を入力したら、管理対象サーバー(WLS_PORTAL)を再起動する必要があります。

12. 「終了」をクリックしてJDBCデータ・ソース構成を保存し、選択したターゲットにデータ・ソースを配置します。

2. Oracle WebLogic Server管理コンソールを使用して、ORACLE_HOME\archives\applicationsにあるWSPortalApproval.earファイルを管理対象サーバーWLS_PORTALに配置します。
アプリケーションを配置するには、次の手順を実行します。

1. Oracle WebLogic管理コンソールにログインします。

2. まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. コンソールの左側のペインで「デプロイ」を選択します。

4. 右側のペインで「インストール」をクリックします。

5. Install Application Assistantを使用してWSPortalApproval.earファイルを見つけ、「次へ」をクリックします。

6. これをインストールする必要があるサーバーを(利用できるサーバーのリストから)選択します(デフォルトのサーバーはWLS_PORTAL)。

7. 次の画面でデフォルト値を受け入れ、「終了」をクリックします。配置が「準備完了」状態になったら、「起動」を選択してアクティブにします。

3. DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_userに移動して、WSPortalApprovalフォルダが作成されていることを確認します。

4. 配置後は、配置したWebサービスが次の場所でアクセスできることを確認します。
http_protocol://wls_hostname:wls_port/bpel/WSPortalApproval.

5.5.1.2 BPELのポータルの構成

コールバックWebサービスの配置後は、次の手順を実行し、ポータルでBPELを有効にします。

1. Oracle Portalにログインします。

2. 「管理」タブをクリックしてから「ポータル」サブタブを選択します。

3. 「サービス」で、「BPELコールバックの構成」を選択します。
「BPELコールバックの構成」ページが表示されます。

4. コールバック・エンドポイント・フィールドで、手順1で取得したコールバック・サービスURLを入力します(例: http_protocol://wls_hostname:wls_port/bpel/WSPortalApproval)。

5. 「OK」をクリックします。

5.5.2 BPELビジネス・プロセスのポータルの保護

Oracle PortalではSecure Socket Layer (SSL)を使用して、SOAサーバーに配置された複合ヒューマン・ワークフローであるBPELビジネス・プロセスとの接続を保護します。エンド・ツー・エンドのポータルBPEL通信を保護するには、次のタスクを実行します。

- BPELサーバーへのアウトバウンドSSLの構成

- ポータルへのBPELサーバー・コールバック

ポータルの保護の詳細は、第7章「Oracle Portalの保護」を参照してください。

5.5.2.1 BPELサーバーへのアウトバウンドSSLの構成

ポータル・リポジトリからBPELサーバーへの通信を保護するには、次の手順を実行します。

- SSLを使用するようにBPELビジネス・プロセスを構成

- BPELサーバーの証明書をPortalデータベースのウォレットにインポート

5.5.2.1.1 SSLを使用するようにBPELビジネス・プロセスを構成

始める前に、SOA管理対象サーバーにBPELビジネス・プロセスが配置されていることを確認します。SSLを構成するには、次の手順を実行します。

SOA管理対象サーバーでのSSLの有効化

SOA管理対象サーバーを有効にするには、次のタスクを実行します。

1. Oracle WebLogic管理コンソールにログインします。

2. まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. コンソールの左側のペインで、「環境」を開いて「サーバー」を選択します。

4. 「サーバー」表で、SOA管理対象サーバー・インスタンスをクリックします。

5. 「SSLリスニング・ポートの有効化」を選択して「SSLリスニング・ポート」に番号を入力します。

キーおよび証明書の取得

SOA管理対象サーバーでSSLを有効にした後、次の手順を実行します。

1. Sun MicrosystemのkeytoolユーティリティであるCertGenユーティリティを使用して、SOA WebLogic管理対象サーバーのデジタル証明書、秘密鍵および信頼できるCA証明書を取得します。デジタル証明書、秘密鍵および信頼できるCA証明書を取得するには、前述のユーティリティを使用して作成された証明書要求を、EntrustやVerisignなどのベンダーに送信します。テスト目的で、WebLogic Serverキットに付属するデジタル証明書、秘密鍵および信頼できるCA証明書を使用することもできます。

2. 秘密鍵、デジタル証明書および信頼できるCA証明書を保存します。キーストアの秘密鍵と信頼できるCA証明書が、SSLに割り当てられます。

注意:

推奨されるキーストア・フォーマットはJKS (Java KeyStore)です。Oracle WebLogic Serverは、ファイルまたはWebLogicキーストア・プロバイダに保存されている秘密鍵および信頼できるCA証明書を、下位互換性を目的としてのみサポートしています。

IDおよび信頼できるキーストアの構成

WebLogic管理対象サーバーのIDおよび信頼できるキーストアを構成するには、WebLogic管理コンソールを使用して次の手順を実行する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. コンソールの左側のペインで、「環境」を開いて「サーバー」を選択します。

4. SOA WebLogic管理対象サーバーを選択します。

5. 「構成」→「キーストア」を選択します。

6. 「キーストア」フィールドで「カスタムIDとカスタム信頼」を選択します。

7. 「ID」セクションでIDキーストアの属性を定義します。

1. カスタムIDキーストア: IDキーストアへの絶対パスです。

2. カスタムIDキーストアのタイプ: キーストアのタイプです。

3. 「カスタムIDキーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワードです。この属性がオプションか必須かは、キーストアのタイプによって異なります。すべてのキーストアは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアは、キーストアからの読取りにパスフレーズが不要です。WebLogic Serverはキーストアからのみ読取りを行うため、このプロパティを定義するかどうかは、キーストアの要件によって異なります。

8. 「保存」をクリックします。

9. これらの変更内容をアクティブにするには、管理コンソールの変更センターで「変更のアクティブ化」をクリックします。

キーストアを構成したら、それをSSL向けに構成する必要があります。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプで、SSL向けのサーバー構成および双方向SSLの構成に関する項を参照してください。

5.5.2.1.2 BPELサーバーの証明書をPortalデータベースのウォレットにインポート

SSLを使用するようにBPELビジネス・プロセスを構成した後、ポータル・リポジトリとSOAサーバーとのhttps通信を可能にする必要があります。この通信を可能にするには、Portalデータベース・ウォレットのトラストストアに、BPELビジネス・プロセスの管理対象サーバーの信頼できるCA証明書を保存する必要があります。安全な通信が要求されるのは、BPELプロセスURLがポータル・リポジトリ内で使用される場合の、BPELサーバーに配置されるプロセスのWSDL URLおよびエンドポイントURLの登録中、およびアイテム(bpelワークフローに参加している)がページでアップロードされるときのBPELサーバーに対するSOAPリクエストにおいてです。

空のウォレットの作成(HTTPS)

空のウォレットを作成して、OracleAS Single Sign-OnへのSSLアクセスのトラスト・ポイントを確立します。これを行うには、次の手順を実行します:

1. ORACLE_HOMEでOracle Wallet Managerを開きます。生成したウォレットにOracle Metadata Repositoryのポータル・スキーマからアクセスできるかぎり、Oracle Wallet Managerはどこからでも実行できます。ウォレット(ウォレット・ファイルを含むディレクトリ)を任意の場所に保存して、Oracle Metadata Repositoryのポータル・スキーマからアクセス可能な別の場所に移動することもできます。

2. 「ウォレット」→「新規」を選択します。
UNIXの場合、ウォレットはデフォルトで次の場所に格納されます。

/etc/ORACLE/WALLETS/<Account Name creating the Wallet>

Windowsの場合、ウォレットはデフォルトで次の場所に格納されます。

\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS

3. ウォレットのパスワードを作成します。

4. 同じパスワードを「パスワードの確認」フィールドに入力します。

5. 「ウォレット・タイプ」に「標準」を選択します。

6. 「OK」をクリックします。

7. 「はい」をクリックして、証明書リクエストを作成するオプションを受け入れます。

8. 「証明書リクエスト」ダイアログにサーバーを一意に識別するための詳細を入力して、「OK」をクリックします。証明書リクエストが正常に作成されたことを示すダイアログが表示されます。ウォレット・ナビゲータの「証明書」ノードが「リクエスト済」に変わります。

9. 選択した認証局(CA)にCRを送信します。

10. 「ウォレットへの信頼できるルート証明書の追加(HTTPS)」に示すように、信頼できるルート証明書をウォレットに追加する必要があります。

11. このウォレットを次のように、適切なディレクトリに保存します。

INFRA_ORACLE_HOME\wallets

12. 「ウォレット」→「保存」を選択します。

ウォレットへの信頼できるルート証明書の追加(HTTPS)

この項の手順は、認証局の発行したOracleAS Single Sign-Onサーバーの信頼できるルート証明書が「信頼できる証明書」リストに含まれていない場合にのみ実行してください。この場合は、次の手順に示すように信頼できるルート証明書をウォレットに追加する必要があります。この手順は、Internet Explorerブラウザに基づいています。

1. ブラウザを使用して、https://infra.domain.com/pls/orassoにあるOracleAS Single Sign-Onのホーム・ページにアクセスします。これがHTTPS URLにあることを確認します。

1. サーバーの証明書がブラウザによって自動的に信頼されない場合は、「セキュリティの警告」ダイアログ・ボックスが表示されます。

2. 「証明書の表示」をクリックします。

3. 「証明のパス」タブをクリックします。

4. リストの最初の証明書である証明機関のルートを選択します。

5. 「証明書の表示」をクリックします。

6. 「証明書のインストール」をクリックします。
これによって、「証明書のインポート ウィザード」が表示されます。ウィザードによって、ブラウザの信頼できる認証機関リストに証明書がインポートされます。

7. 「次へ」をクリックします。

8. 「証明書の種類に基づいて、自動的に証明書ストアを選択する」を選択します。

9. 「次へ」をクリックします。

10. 「終了」をクリックします。
信頼できるルート証明書がブラウザにインストールされます。

2. ステータス・バーのロック・アイコンをクリックすると、「証明書」ダイアログ・ボックスが表示されます。

3. 「証明のパス」タブをクリックします。

4. リストの最初の証明書である証明機関のルートを選択します。

5. 「証明書の表示」をクリックします。

6. 「詳細」タブをクリックします。

7. 「ファイルにコピー」をクリックします。
これによって、「証明書のエクスポート ウィザード」が表示されます。

8. 「次へ」をクリックします。

9. 「使用する形式を選択してください」で「Base 64 encoded X.509 (.CER)」を選択します。

10. 「次へ」をクリックして、証明書のファイル名を指定します。証明書には、.cer拡張子を持つ任意のファイル名を指定できます。

11. 「次へ」をクリックして、「完了」をクリックします。

この時点で、.cer証明書ファイルが作成されます。このファイルには、信頼できる証明機関のルート証明書が含まれています。この証明書を、ウォレットの信頼できる証明書リストに追加する必要があります。追加するには、Wallet Managerがすでに実行され、空のウォレットが開いている状態で次の手順を実行します。

1. 「信頼できる証明書」ノードを右クリックします。

2. 「信頼できる証明書のインポート」を選択します。

3. 「証明書の貼付け」を選択し、「OK」をクリックします。

4. 以前作成した証明書ファイルの内容をBASE64形式の証明書のテキスト領域にコピーし、「OK」をクリックします。

5. 信頼できる証明書のリストに証明機関のルートが追加されていることを確認します。

6. ウォレットを保存します。

7. 自動ログイン機能を設定することもできます。「ウォレット」→「自動ログイン」をまだ選択していない場合は選択します。この機能はパスワードを使用せずにPKIベースでサービスにアクセスできるようにするためのものであり、ほとんどのウォレットで必要になります。データベース・サーバーとクライアントのウォレットには必要です。起動時にウォレット・パスワードを取得する製品では、オプションです。

注意:

BPELワークフロー・アプリケーションが双方向SSLを使用するように構成されている場合、DBウォレットCA(認証局)の信頼できる証明書をSOAサーバーのトラストストアにインポートする必要があります。

5.5.2.2 ポータルへのBPELサーバー・コールバック

クライアントが使用するポータル・コールバックURLは、次のシナリオで保護する必要があります。

- BPEL有効化ポータル(ポータル・コールバックURLのポータル・リポジトリへの登録)

- 「グローバル設定」ページでのコールバックURLのステータス問合せ(ポータル・リポジトリ)

- BPELサーバー上でのユーザーによる承認後、コールバックURLを通じてポータル・リポジトリとの接触が試行されます。

PortalコールバックWebサービス通信を保護するには、次の手順を実行します。

- PortalコールバックWebサービスの双方向SSLの構成

- Oracle BPELプロセスのIDおよび信頼できるキーストアの構成

- PortalデータベースのIDおよび信頼できるキーストアの構成

- BPELビジネス・プロセスでのPortalコールバックWebサービスによる認証の有効化

- Portalリポジトリ・クライアントでのPortalコールバックWebサービスによる認証の有効化

- データベース・ウォレットのPortalプリファレンス・ストアへの登録

5.5.2.2.1 PortalコールバックWebサービスの双方向SSLの構成

Portal Webサービスを構成するには:

1. WSPortalApproval.earが配置されていない場合は、第5.5.1.1項「コールバックWebサービスの配置」の説明に従って、WLS_PORTAL管理対象サーバーに配置する必要があります。

2. 管理対象サーバー(WLS_PORTAL)でWSPortalApproval.earに対してSSLを有効にするには、次の手順を実行します。

- Oracle WebLogic管理コンソールにログインします。

- まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。

- コンソールの左側のペインで、「環境」を開いて「サーバー」を選択します。

- 「サーバー」の表で、管理対象サーバーWLS_Portalのインスタンスをクリックします。

- 「SSLリスニング・ポートの有効化」を選択して「SSLリスニング・ポート」に番号を入力します。

3. Portal管理対象サーバー(WLS_Portal)のIDおよび信頼できるキーストアを取得します(「IDおよび信頼できるキーストアの構成」を参照)。

4. キーストアでSSLを構成します。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプで、サーバーの双方向SSLの構成に関する項を参照してください。

5.5.2.2.2 Oracle BPELプロセスのIDおよび信頼できるキーストアの構成

IDおよび信頼できるキーストアを構成するには、次の手順を実行します。

1. SOA管理対象サーバー(soa_server)にOracle BPELプロセスを配置します。

2. SOA管理対象サーバーのIDおよび信頼できるキーストアを取得します(「IDおよび信頼できるキーストアの構成」を参照)。

5.5.2.2.3 PortalデータベースのIDおよび信頼できるキーストアの構成

IDおよび信頼できるキーストアを保存するには、ウォレットを作成する必要があります。「空のウォレットの作成(HTTPS)」および「ウォレットへの信頼できるルート証明書の追加(HTTPS)」を参照してください。

5.5.2.2.4 BPELビジネス・プロセスでのPortalコールバックWebサービスによる認証の有効化

BPELビジネス・プロセスでは、(双方向SSLが構成された)Portal管理対象サーバーでの認証用に、IDを提示する必要があります。そのために、Keytoolのエクスポートおよびインポート・コマンドを使用して、次の手順を実行します。

- SOA管理対象サーバーのCAの信頼できる証明書を、BASE 64エンコード形式のテキスト・ファイルにエクスポートします(soa_server_trusted.cer)。

- Portal管理対象サーバーのCAの信頼できる証明書を、BASE 64エンコード形式のテキスト・ファイルにエクスポートします(portal_server_trusted.cer)。

- SOA管理対象CA(認証局)の信頼できる証明書(soa_server_trusted.cer)を、Portal管理対象サーバーのトラストストアにインポートします。

- PortalウォレットのCA(認証局)の信頼できる証明書(portal_server_trusted.cer)を、Portal管理対象サーバーのトラストストアにインポートします。

5.5.2.2.5 Portalリポジトリ・クライアントでのPortalコールバックWebサービスによる認証の有効化

双方向SSLを使用するように構成されているPortal管理対象サーバーでは、ウォレットの認証用にIDが提示される必要があります。そのために、次の手順を実行します。

- ウォレットのCAの信頼できる証明書を、BASE 64エンコード形式のテキスト・ファイルにエクスポートします (ウォレットからのエクスポートに、Oracle Wallet Managerまたはorapkiユーティリティを使用できます)。

- (前述の手順でファイルにエクスポートした)PortalウォレットのCA(認証局)の信頼できる証明書を、Portal管理対象サーバーのトラストストアにインポートします。

- PortalウォレットのCA(認証局)の信頼できる証明書(portal_server_trusted.cer)を、Portal DBウォレットのトラストストアにインポートします。

5.5.2.2.6 データベース・ウォレットのPortalプリファレンス・ストアへの登録

ポータル・リポジトリがデータベース・ウォレットを使用するように登録されていない場合、ORACLE_HOME\portal\admin\plsql\wwcにあるsecwc.sqlスクリプトを実行して登録する必要があります。

例5-1 ウォレットの登録

cd $ORACLE_HOME/portal/admin/plsql/wwc sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location>, <wallet_pwd>sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet', 'welcome1'

5.5.3 新規BPELプロセス定義の作成

ページ・グループの管理者とページの所有者が、承認にOracle BPELワークフロー・プロセスを使用できるようにするには、まずこれらのワークフロー・プロセスを指すプロセス定義を作成する必要があります。

注意:

ここでは、Oracle BPELプロセスの作成と配置が済んでいると想定しています。

1. 「サービス」ポートレットで、「BPELプロセス定義の設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「新規BPELプロセス定義の作成」をクリックします。

3. 「プロセス名」フィールドに、Oracle BPELプロセスの名前を入力します。
ページ・グループ管理者とページ設計者は、ページ・グループまたはページに使用するプロセスを選択する場合に、この名前を使用してプロセスを特定します。この名前は、Oracle BPELでプロセスの特定に使用した名前と同じである必要があります。また、名前には、空白や特殊文字を使用しないでください。

4. 「説明」フィールドに、Oracle BPELプロセスの動作の説明を入力します。
このフィールドは任意ですが、説明を入力しておくと、ページ・グループ管理者とページ設計者がページ・グループまたはページに使用するプロセスを選択する場合に大いに役立ちます。説明は4000文字まで入力でき、空白を含めることはできますが、特殊文字は使用できません。

5. 「プロセス配布の場所」フィールドに、Oracle BPELプロセスを配置するURLを入力します。これはエンドポイントとも呼ばれます。このエンドポイントは、SOAサーバーに配置されたプロセスから取得できます。
このURLにOracle Portalから直接アクセスできない場合には、グローバルなプロキシ定義を設定していることを確認してください。第6.5項「プロキシ・サーバーを使用するためのOracle Portalの構成」を参照してください。

6. 「プロセスWSDLの場所」フィールドに、Oracle BPELプロセスの説明ドキュメント(.wsdlファイル)のURLを入力します。Oracle Portalには、この.wsdlファイルに対する読取り権限が付与されている必要があります。
このURLにOracle Portalから直接アクセスできない場合には、グローバルなプロキシ定義を設定していることを確認してください。第6.5項「プロキシ・サーバーを使用するためのOracle Portalの構成」を参照してください。

7. 「プロセス処理」フィールドに、このOracle BPELプロセス定義のコール時にOracle Portalがトリガーする必要がある操作の名前を入力します。この操作については、WSDLドキュメントで説明しています。

8. 「OK」をクリックして、Oracle BPELプロセス定義を作成します。

9. 確認画面で、定義が正常に作成されたかどうかを確認できます。定義の作成に失敗した場合は、設定を確認して作成しなおします。
BPELプロセス定義が正しく作成されたら、「閉じる」をクリックします。

5.5.4 既存のBPELプロセス定義の編集

ワークフローに関係するアイテムがない場合、既存のBPELプロセス定義を編集できます。アイテムがある場合、ビジネス・プロセスはロックされます。

1. 「サービス」ポートレットで、「BPELプロセス定義の設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 編集するBPELプロセス定義の名前をクリックします。

3. 必要に応じてフィールドを編集します。これらのフィールドの詳細は、第5.5.3項「新規BPELプロセス定義の作成」を参照してください。

注意:

「プロセス名」フィールドは編集できません。

4. 「OK」をクリックして、変更を保存します。

5. 確認画面で、変更が正しく行われたかどうかを確認できます。変更に失敗した場合は、設定を確認して変更しなおします。
変更が正しく行われたら、「閉じる」をクリックします。

5.5.5 既存のBPELプロセス定義の削除

必要に応じて既存のBPELプロセス定義を削除できます。

1. 「サービス」ポートレットで、「BPELプロセス定義の設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 表で、削除するBPELプロセス定義の横にある「削除」アイコンをクリックします。

3. 削除するのがこのBPELプロセス定義で間違いがないか、詳細を確認します。

4. 操作を続ける場合は「削除」を、止める場合は「取消」をクリックします。

5. 「閉じる」をクリックします。

5.5.6 Oracle Portalのメッセージ・スキーマ

Oracle Portalでは、HTTPを介したSOAPメッセージを使用して、あらゆるOracle BPELワークフロー・プロセスを開始します。また、項目のURLなどのペイロード情報を送信することで、承認者がその情報を確認できるようにしています。

例5-2は、メッセージ・ペイロードに含まれる情報の種類を示すために、Oracle Portalのメッセージ・スキーマのサンプルを示しています。Oracle BPELワークフロー・プロセスの設計者は、プロセス(.XSD)ファイルの作成時にこの情報を使用する必要があります。

例5-2 Oracle Portalのメッセージ・スキーマのサンプル

<complexType>
<sequence>
<element name="title" type="string"/>
<element name="payload">
<complexType>
<sequence>
<element name="itemType" type="string"/>
<element name="url" type="string"/>
<element name="status" type="string"/>
<element name="date" type="string"/>
<element name="Originator" type="string"/>
<element name="description" type="string"/>
<element name="pageName" type="string"/>
<element name="pageDisplayName" type="string"/>
<element name="pageGroupName" type="string"/>
<element name="subject" type="string"/>
<element name="itemVersion" type="string"/>
<element name="itemExpiry" type="string"/>
<element name="itemDisplayOption" type="string"/>
<element name="author" type="string"/>
<element name="defaultLanguage" type="string"/>
</sequence>
</complexType>
</element>
<element name="itemId" type="integer"/>
<element name="pageId" type="integer"/>
<element name="siteId" type="integer"/>
<element name="submitter" type="string"/>
<element name="approvalId" type="integer"/>
<element name="instanceId" type="integer"/>
<element name="portalWSUrl" type="string"/>
<element name="content_manager">
<complexType>
<sequence>
<element name="userCount" type="integer"/>
<element name="users" type="string" minOccurs="0" maxOccurs="10"/>
</sequence>
</complexType>
</element>
<element name="page_manager">
<complexType>
<sequence>
<element name="userCount" type="integer"/>
<element name="users" type="string" minOccurs="0" maxOccurs="10"/>
</sequence>
</complexType>
</element>
<element name="page_group_manager">
<complexType>
<sequence>
<element name="userCount" type="integer"/>
<element name="users" type="string"/>
<element name="groupCount" type="integer"/>
<element name="groups" type="string"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>

表5-4では、メッセージ・ペイロードの様々な要素について説明しています。

表5-4 メッセージ・ペイロードの詳細

要素

説明

title

アイテムの表示名

itemType

アイテムのアイテム・タイプ(text、file、urlなど)

url

アイテムを指すURL

ステータス

アイテムのステータス

date

アイテムが送信された日付

Originator

アイテムの作成者

description

アイテムの説明

pageName

アイテムを含むページの内部名

pageDisplayName

アイテムを含むページのタイトル

pageGroupName

アイテムを含むページを所有するページ・グループの名前

subject

メッセージの送信理由を説明するためにOracle PortalからOracle BPELに送信される情報

itemVersion

アイテムのバージョン番号

itemExpiry

アイテムの有効期限

itemDisplayOption

アイテムの表示オプション

author

アイテムを送信したユーザーが指定した作成者の名前

defaultLanguage

ポータルのデフォルトの言語

itemId

アイテムに対して内部で生成したID

pageId

ページに対して内部で生成したID

siteId

ページ・グループに対して内部で生成したID

submitter

アイテムを送信したユーザー

approvalId

instanceId

アイテムの追加に使用したインスタンスID

content_manager

項目を掲載したページに対するコンテンツの管理権限を持つユーザーのリスト。これを使用してこの権限を持つ特定のユーザーのユーザー名を抽出し、Oracle BPELワークフロー・プロセスにおける承認者として使用します。

page_manager

項目を掲載したページに対する管理権限を持つユーザーのリスト。これを使用してこの権限を持つ特定のユーザーのユーザー名を抽出し、Oracle BPELワークフロー・プロセスにおける承認者として使用します。

page_group_manager

項目を掲載したページが属するページ・グループに対するすべて管理権限を持つユーザーのリスト。これを使用してこの権限を持つ特定のユーザーのユーザー名を抽出し、Oracle BPELワークフロー・プロセスにおける承認者として使用します。

5.5.7 BPELコールバックWebサービス・プロキシ

Oracle Portalでは、Oracle BPELワークフロー・プロセスはすべて、ビジネス・プロセスを配置する前にコールバック・サービスを追加する必要があります。

例5-3および例5-4は、却下手順および承認手順を示すコールバック・プロキシ・サービスのサンプルです。Oracle BPELワークフロー・プロセスの設計者は、プロセスの作成時にこの情報を使用できます。

例5-3 却下コールバックWebサービス

try
{
portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient client =
new portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient();

oracle.xml.parser.v2.XMLElement elm ;
elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:portalWSUrl");
org.w3c.dom.Node node = (org.w3c.dom.Node) elm.getFirstChild();
String portalWSUrl = node.getNodeValue();
System.out.println("portalWSUrl = " + portalWSUrl);
client.setEndpoint(portalWSUrl);

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:itemId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("Itemid = " + node.getNodeValue());
java.math.BigDecimal itemId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:pageId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("Pageid = " + node.getNodeValue());
java.math.BigDecimal pageId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:siteId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("Siteid = " + node.getNodeValue());
java.math.BigDecimal siteId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:approvalId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("approvalId = " + node.getNodeValue());
java.math.BigDecimal approvalId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:instanceId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("instanceId = " + node.getNodeValue());
java.math.BigDecimal instanceId = new java.math.BigDecimal(node.getNodeValue());

client.reject(itemId,pageId,siteId,instanceId,approvalId);
}
catch(java.rmi.RemoteException remoteException)
{
System.out.println("REJECT  "+remoteException);
System.out.println("An exception occured while trying " +
" connect to portal");
remoteException.printStackTrace();
}
catch(Exception exception)
{
System.out.println("REJECT_OTHERS "+ exception);
exception.printStackTrace();
}

例5-4 承認コールバックWebサービス

try
{
portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient client =
new portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient();

System.out.println("INSIDE THE APPROVE section");
oracle.xml.parser.v2.XMLElement elm ;

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:portalWSUrl");
org.w3c.dom.Node node = (org.w3c.dom.Node) elm.getFirstChild();
String portalWSUrl = node.getNodeValue();
System.out.println("portalWSUrl = " + portalWSUrl);
client.setEndpoint(portalWSUrl);

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:submitter");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("submitter = " + node.getNodeValue());
String submitter = new String(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:itemId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("Itemid = " + node.getNodeValue());
java.math.BigDecimal itemId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:pageId");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("pageid = " + node.getNodeValue());
java.math.BigDecimal pageId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:siteId");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("Siteid = " + node.getNodeValue());
java.math.BigDecimal siteId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:approvalId");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("approvalid = " + node.getNodeValue());
java.math.BigDecimal approvalId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:instanceId");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("instanceid = " + node.getNodeValue());
java.math.BigDecimal instanceId = new java.math.BigDecimal(node.getNodeValue());

client.approve(itemId,pageId,siteId,submitter,instanceId,approvalId);
}
catch(java.rmi.RemoteException remoteException)
{
System.out.println("INSIDE APPROVE  " + remoteException);
System.out.println("An exception occured while trying " +
" connect to portal");
remoteException.printStackTrace();
}
catch(Exception exception)
{
System.out.println("INSIDE APPROVE WHEN_OTHERS " + exception);
exception.printStackTrace();
}

5.6 基本的なポータル管理の実行

この項の内容:

- Oracle Portalインスタンスの完全なURLの簡略化

- Oracle Portalホーム・ページを使用するためのOracle HTTP Serverの構成

- Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動

- Fusion Middleware Controlを使用したポータルDADの構成

- WLSTを使用したポータルDADの構成

- Fusion Middleware Controlを使用したポータル・キャッシュの構成

- WLSTを使用したポータル・キャッシュの構成

- ポータル・キャッシュの消去

- PortalのParallel Page Engineの構成

- Portalスキーマのパスワードの取得

- カスタム・イメージ・ディレクトリの使用

5.6.1 Oracle Portalインスタンスの完全なURLの簡略化

Redirectディレクティブを使用すると、Oracle Portalのインストールによって作成された完全URLをより覚えやすい(わかりやすい)URLに簡略化できます。このようにすると、エンド・ユーザーは単純なURLを入力するだけでOracle Portalにアクセスできます。

デフォルトでは、新たにインストールしたOracle PortalのURLは次のように入力する必要があります。

http://<host>:<port>/portal/pls/<dad>

このURLを次のように簡略化できます。

http://<host>/<redirectpath>

注意:

Oracle PortalのURLをhttp://<host>:<port>/portalのように簡略化しないでください。Oracle Portalは、すでに/portalにマウントされているためです。

1. 次のディレクトリにあるOracle HTTP Server構成ファイル、httpd.confを開きます。

ORACLE_INSTANCE\config\OHS\ohs1

2. 次のようにリダイレクト・パスを入力します。

Redirect /<redirectpath> http://<host>:<port>/portal/pls/<dad>

例:

Redirect /portalhome http://mysite.oracle.com/portal/pls/portal

この例では、エンド・ユーザーは次のように入力できます。

http://mysite.oracle.com/portalhome

たとえば、次のような完全なURLにアクセスできます。

http://mysite.oracle.com/portal/pls/portal

注意:

- 例のhttp://mysite.oracle.com/portalhomeではデフォルト・ポートの使用を想定しています。デフォルト・ポートを使用していない場合は、http://mysite.oracle.com:<port>/portalhomeのようにポート番号を含めてURLを入力する必要があります。

- Oracle Enterprise Manager 11g Fusion Middleware Controlを使用してhttpd.confファイルを編集することもできます。httpd.confファイルを編集した後は、Oracle Enterprise Manager 11g Fusion Middleware Controlを使用してOracle HTTP Serverを再起動できます。

3. ORACLE_INSTANCE\bin\opmnctlから、次のコマンドを実行してHTTPサーバーを再起動します。

opmnctl restartproc type=ohs

Oracle Enterprise Manager 11g Fusion Middleware Controlを使用してHTTPサーバーを再起動することもできます。

5.6.2 Oracle Portalホーム・ページを使用するためのOracle HTTP Serverの構成

Oracle Portalホーム・ページをOracle HTTP Serverのデフォルトのホーム・ページに設定するには、次の手順を実行します。

1. ORACLE_INSTANCE\config\OHS\ohs1\htdocsディレクトリで、welcome-index.htmlファイルおよびwelcome-index.html.<lang>ファイルのバックアップ・コピーを作成します。<lang>は言語コードです。たとえば、welcome-index.html.enは、英語の索引HTMLファイルです。

2. welcome-index.html.<lang>ファイルの内容全体を次のHTMLリダイレクト・コードで置き換えます。

<HTML>
<SCRIPT LANGUAGE=JavaScript>
document.location="http://<host>.<domain>:<port>/portal/pls/<dad>"
</SCRIPT>
</HTML>

注意:

- ポート80または443でOracle Portalを実行している場合は、ポート番号を指定しないでください。ポート8090でOracle Portalを実行している場合は、ポート番号の指定が必要です。

- 他の言語のサポートを計画している場合は、言語ごとに、リダイレクト・コードを含む言語固有の索引HTMLファイルを用意する必要があります。

5.6.3 Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動

一般的にポータル・コンポーネントは、構成の変更に続いて再起動する必要があります。

Fusion Middleware Controlを使用してコンポーネントを起動、停止または再起動するには、次の手順を実行します。

1. 適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、「Oracle Enterprise Manager 11g Fusion Middleware Controlへのアクセス」を参照してください。

2. Oracle Portalインスタンスのホーム・ページに移動します。
詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。

3. 「関連コンポーネント」ポートレットを検索します。

4. 「関連コンポーネント」ポートレットの「名前」列で、起動または停止するコンポーネントをクリックします。

5. コンポーネントのメニューから「制御」を選択します。

6. 次のうちの1つを実行してください。

- コンポーネントを停止するには、「停止」をクリックします。

- コンポーネントを起動するには、「起動」をクリックします。

5.6.4 Fusion Middleware Controlを使用したポータルDADの構成

データベース・アクセス記述子(DAD)は、アプリケーションがHTTPリクエストを満たすためにOracle Databaseに接続する方法を指定する値のセットです。DADの情報には、ユーザー名(スキーマと権限も指定)、パスワード、接続文字列およびデータベースのグローバリゼーション・サポート言語が含まれます。

DADには、一般的なDADとポータルDADの2種類があります。Oracle Portal中間層は、ポータルDADを使用してOracle Metadata Repositoryにアクセスします。ここでは、ポータルDADを作成、編集または削除する方法を説明します。一般的なDADの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

ポータルDADの作成

Oracle Portalをインストールすると、ポータルDADが自動的に作成されます。ただしDADは、必要に応じて、Fusion Middleware Controlを使用して手動で作成できます。

注意:

Oracle Portalでサポートされるのは、ポータル・インスタンス1つ当たり1つのポータルのみであり、インスタンスに対してDADが事前に存在している場合には、新規DADを作成することはできません。

新規のポータルDADを作成するには、次の手順を実行します。

1. 適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

2. Oracle Portalインスタンスのホーム・ページに移動します。
詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。

3. 「ポータル」メニューから、「設定」→「データベース・アクセス記述子」を選択します。

4. 「追加」をクリックして、新規ポータルDADのパラメータを完成します。このページのすべてのオプションの詳細は、表8-1「DAD設定」を参照してください。

5. 「OK」をクリックします。

6. Oracle HTTP Serverと管理対象サーバー(WLS_PORTAL)を再起動します。
Oracle HTTP ServerとWLS_Portalのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。

ポータルDADの編集

Fusion Middleware Controlを使用してポータルDADを削除するには、次の手順を実行します。

1. 適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

2. Oracle Portalインスタンスのホーム・ページに移動します。
詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。

3. 「ポータル」メニューから、「設定」→「データベース・アクセス記述子」を選択します。

4. DADを選択し、「編集」をクリックします。必要に応じて、このOracle PortalインスタンスのDADパラメータを編集します。このページのすべてのオプションの詳細は、表8-1「DAD設定」を参照してください。

5. 「OK」をクリックします。

6. Oracle HTTP Serverと管理対象サーバー(WLS_PORTAL)を再起動します。
Oracle HTTP ServerとWLS_Portalのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。

ポータルDADの削除

Fusion Middleware Controlを使用してポータルDADを削除するには次のようにします。

注意:

デフォルトのポータルDADは削除しないでください。デフォルトのポータルDADを削除すると、Oracle Portalが動作しなくなります。

1. 適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

2. Oracle Portalインスタンスのホーム・ページに移動します。
詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。

3. 「ポータル」メニューから、「設定」→「データベース・アクセス記述子」を選択します。

4. DADを選択し、「削除」をクリックします。

5. 「OK」をクリックします。

6. Oracle HTTP Serverと管理対象サーバー(WLS_PORTAL)を再起動します。
Oracle HTTP ServerとWLS_Portalのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。

5.6.5 WLSTを使用したポータルDADの構成

WLSTコマンドライン・スクリプト・インタフェースからポータルDADを作成、リスト、更新または削除するには、次の手順を実行します。WLSTの使用方法の詳細は、第5.1.2.2項「WebLogic Scripting Tool (WLST)コマンドライン・ユーティリティ」を参照してください。

WLSTコマンドライン・スクリプト・インタフェースからポータルDADを作成、表示、更新または削除するには、表5-5にリストされているデータベース・アクセス記述子コマンドを使用します。操作に従って、DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configurationにあるportal_dads.confファイルが更新されます。

表5-5 Portal WLST構成用のデータベース・アクセス記述子コマンド

使用するコマンド

実行内容

WLSTでの使用

ポータルDADの作成

ポータル・データベース・アクセス記述子を作成します。

オンライン

ポータルDADの更新

ポータル・データベース・アクセス記述子の属性を更新します。

オンライン

ポータルDADの削除

ポータル・データベース・アクセス記述子を削除します。

オンライン

DADのリスト

データベース・アクセス記述子が構成に使用するパラメータをリストします。

オンライン

5.6.5.1 ポータルDADの作成

Oracle Portalをインストールすると、ポータルDADが自動的に作成されます。ポータルDADを手動で作成するには、次のWLST(オンライン)コマンドを使用します。

createPortalDad (name, schema, password, [connect_string], nls_language)

引数

定義

name

データベース・アクセス記述子の名前です。

schema

Portalデータベース・アカウントのユーザー名。

password

Portalデータベース・アカウントのパスワード。

connect_string

オプション。リモート・データベースの接続に使用される接続文字列。

接続文字列は、「ホスト名:ポート番号:接続文字列」という形式で指定できます。「ServiceNameFormat (host:port:service_name)」、「SIDFormat (host:port:database_sid)」または「TNSFormat (TNS別名または完全なTNSエントリ)」のいずれかを選択します。

nls_language

このDADで表されるポータル・データベースのグローバリゼーション・サポート言語。この設定は、データベース・セッション用のNLS_LANG環境変数をオーバーライドし、レスポンス文字セットなど、レスポンスに関連するいくつかの重要なグローバリゼーション・サポート・プロパティを定義します。

この言語設定は、バックエンド・データベースのNLS_LANGと一致している必要があります。

例5-5 ポータルDADの作成

createPortalDad(name='portal1',schema='schema',password='welcome1',connect_string='foo.oracle.com:1521:orcl',nls_language='AMERICAN_AMERICA.AL32UTF8')

注意:

Oracle Portalでサポートされるのは、ポータル・インスタンス1つ当たり1つのポータルのみであり、インスタンスに対してDADが事前に存在している場合には、新規DADを作成することはできません。

5.6.5.2 ポータルDADの更新

ポータルDADの属性を更新するには、次のWLST(オンライン)コマンドを使用します。

updatePortalDad (name, [schema], [password], [connect_string], [nls_language])

引数

定義

name

データベース・アクセス記述子の名前です。この名前は更新時に変更できません。

schema

オプション。Portalデータベース・アカウントのユーザー名。

password

オプション。Portalデータベース・アカウントのパスワード。

connect_string

オプション。リモート・データベースの接続に使用される接続文字列。

接続文字列は、「ホスト名:ポート番号:接続文字列」という形式で指定できます。「ServiceNameFormat (host:port:service_name)」、「SIDFormat (host:port:database_sid)」または「TNSFormat (TNS別名または完全なTNSエントリ)」のいずれかを選択します。

nls_language

オプション。このDADで表されるポータル・データベースのグローバリゼーション・サポート言語。この設定は、データベース・セッション用のNLS_LANG環境変数をオーバーライドし、レスポンス文字セットなど、レスポンスに関連するいくつかの重要なグローバリゼーション・サポート・プロパティを定義します。この言語設定は、バックエンド・データベースのNLS_LANGと一致している必要があります。

例5-6 ポータルDADの属性の更新

updatePortalDad(name='portal1',schema='user1',password='welcome2',connect_string='foo.oracle.com:1521:orcl',nls_language='AMERICAN_AMERICA.AL32UTF8')

5.6.5.3 ポータルDADの削除

ポータルDADを削除するには、次のWLST(オンライン)コマンドを使用します。

deletePortalDad(name)

引数

定義

name

ポータル・データベース・アクセス記述子の名前です。

例5-7 Portal_dads.confファイルからのポータルDADエントリの削除

deletePortalDad(name='portal1')

5.6.5.4 DADのリスト

すべてのDAD(一般DADとポータルDAD)で指定されているパラメータをリストするには、次のWLST(オンライン)コマンドを使用します。

listDads ()

例5-8 ドメイン内の様々なDADのリスト

listDads()
------------
/pls/portal1
Schema: h1user
Connect String: foo.oracle.com:1521:orcl
NLS Language: "AMERICAN_AMERICA.AL32UTF8"

5.6.6 Fusion Middleware Controlを使用したポータル・キャッシュの構成

ポータル・キャッシュは、Oracle Portalのページおよびポートレット用のファイル・システムベースのキャッシュです。詳細は、第1.3.2項「ポータル・キャッシュの理解」を参照してください。

Fusion Middleware Controlを使用してポータル・キャッシュを構成するには、次の手順を実行します。

1. 適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

2. Oracle Portalインスタンスのホーム・ページに移動します。
詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。

3. 「ポータル」メニューから、「設定」→「ポータル・キャッシュ」を選択します。

4. 「キャッシュ」オプションが「オン」に設定されていることを確認します。

5. 必要に応じて、このOracle Portalインスタンスのキャッシュ設定を編集します。このページのすべてのオプションの詳細は、表8-2「Portalキャッシュの設定」を参照してください。

6. 「適用」をクリックします。

7. 管理対象サーバー(WLS_PORTAL)を再起動します。
WLS_Portalコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。

5.6.7 WLSTを使用したポータル・キャッシュの構成

WLST(オンライン)コマンドによって、ポータル・キャッシュの属性が更新されます。

SE構成の詳細は、DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_cache.confファイルで管理されます。

ポータル・キャッシュの属性を更新するには、次を使用します。

configurePortalCache(enable, directory, total_size, max_size, cleanup_time, max_age)

引数

定義

enable

ポータル・コンテンツおよびセッションのキャッシングを有効化(「オン」)または無効化(「オフ」)します。

directory

キャッシュ・コンテンツが格納されるディレクトリ。

このディレクトリが存在することと、読込み/書込み権限があることを確認してください。

total_size

ポータル・キャッシュに使用可能なディスク容量の総サイズ(MB単位)。許可される最大値は4GBです。

max_size

全キャッシュ・ファイルに対する最大サイズ(バイト単位)。許可される最大値は4GBです。この制限を超える動的に生成されるコンテンツはキャッシュされません。

cleanup_time

キャッシュ記憶域の消去を開始する時間。クリーンアップが実行される日時を正確に定義するには、[Sunday-Saturday, Everyday, Everymonth][hh:mm]という書式を使用します。

max_age

1つのキャッシュされたドキュメントの最長保存期間。この設定によって、古いコンテンツがキャッシュ・システムに含まれないことが保証されます。古いキャッシュ・ファイルは削除され、新しいキャッシュ・ファイル用の領域が確保されます。デフォルトは30日です。

例5-9 ポータル・キャッシュの構成

configurePortalCache(enable=true,directory='/scratch/user/installs/Inst_1/cache/PortalComponent/portal',total_size=10101010,max_size=12300033,cleanup_time='Everyday 11:00',max_age=20)

5.6.8 ポータル・キャッシュの消去

ポータル・キャッシュ(Oracle Portalファイル・システムベースのキャッシュ)を消去する必要がある場合があります。たとえば、Oracle Metadata Repositoryの文字セットを変更する場合、既存のコンテンツでは古い文字セットが使用されるため、ポータル・キャッシュ全体を消去する必要があります。

ポータル・キャッシュを消去するには、次の手順を実行します。

1. ポータル・キャッシュのディレクトリに移動します。デフォルトのパスは、ORACLE_INSTANCE\portal\cacheです。

2. このディレクトリの下のすべてのファイルの再帰的削除を行います。たとえば、UNIXのプラットフォームでは、次のコマンドを発行します。

rm -rf *

注意:

- ポータル・キャッシュを消去したときは、Oracle Web Cacheのコンテンツも消去する必要があります。Oracle Web Cacheのコンテンツの消去の詳細は、第6.7.3項「WLSTを使用したPortalのWeb Cache設定の構成」を参照してください。

- すべての中間層でポータル・キャッシュを消去する必要があります。

警告

このコマンドを発行する前に、正しいディレクトリに移動していることを確認します。cacheディレクトリを削除しないでください。

5.6.9 PortalのParallel Page Engineの構成

Oracle Portalアーキテクチャは、3層アーキテクチャで設計されており、任意のブラウザから接続できます。この柔軟なアーキテクチャにより、各構成要素(ブラウザ、Oracle HTTP Serverリスナー、Oracle Database 11gおよびOracle Portal)を必要に応じて個別にアップグレードできます。

Oracle Portalの中間層の一部であるPPE (Parallel Page Engine)は、Oracle WebLogic Serverおよびサービス・ページのリクエストで実行されるサーブレットです。PPEによって、ページ・メタデータの読込み、ポートレット・コンテンツに対応するプロバイダのコール、プロバイダのレスポンスの受入れ、指定されたページ・レイアウトに従ったリクエストされたページの作成が行われます。

5.6.9.1 PPE構成パラメータの設定

すべてのサーブレットは、アプリケーションの配置に基づいてWLS_PORTALにインストールされます。PPEの構成パラメータは、appConfig.xmlファイル、つまり</portal-midtier>およびその構成パラメータに入力されます。デフォルトのインストールでは、このファイルは次の場所にあります。

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

PPEのproviderHeadersパラメータ(表5-7を参照)は、web.xmlファイルに入力されます。このファイルは次の場所にあります。

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portal\uh04o6\war\WEB-INF

PPEのパラメータ

表5-6は、PPEで使用できる様々な構成パラメータについて説明しています。各パラメータは、様々な方法でPPEの操作を設定します。たとえば、ログの記録方法を設定するパラメータ、エンジンのパフォーマンスを操作するパラメータ、Oracle Portal自体を操作するパラメータなどがあります。ほとんどのパラメータはデフォルト値のまま使用できますが、構成によってはデフォルト値を変更する必要があります。各パラメータについて、構文、説明およびデフォルト値を示します。

表5-6 Parallel Page Engine (PPE)のパラメータ

PPE設定

構文

説明

デフォルト値

x509certfile

<x509certfile>c:\certificates\trustedcerts.txt</x509certfile>

HTTPClientに暗黙的に信頼される証明書のリストが含まれたファイルを指定します。これらの証明書は、SSLを使用するHTTPClientによって行われたすべての接続に対するトラスト・ポイントとして追加されます。この設定がいったん使用されると、すべてのSSL接続が信頼されるようになります。そうでない場合、HTTPClientによってPPE内で例外がスローされます。

SSL接続は2つの理由でPPEから行われ、この構成が次の両方に影響を与えることに注意してください。

- たとえば、PMDなどに対する、ポータルへのループバック・リクエスト。

- プロバイダへのコールの表示。

ここで指定したファイルは、すべての信頼できる証明書をエクスポートすることによりウォレットから取得できますが、取得したファイル内のコメントは削除する必要があります。また、手動で信頼できる証明書ファイルを作成することもできます。

トラスト・ポイントは不使用

versionOnSplashScreen

<versionOnSplashScreen>false</versionOnSplashScreen>

PPEがバージョン情報をスプラッシュ画面に表示するかどうかを示します。

false

useScheme

<useScheme>http</useScheme>

PPEがポータルにリクエストを送るときに使用されるスキーム(httpまたはhttps)よりも優先されます。指定しない場合のデフォルトでは、ページ・リクエストのスキームを常に使用します。useSchemeパラメータを設定する場合は、usePortパラメータを設定する必要があります。

パブリック・アクセスがport A上でhttpsを経由し、port B上ではより高速なhttp接続を使用するためにPPEリクエストを設定する場合は、これらのパラメータを指定する必要があります。

ページ・リクエストのスキームを使用

usePort

<usePort>8888</usePort>

PPEがポータルへリクエストを行うときに使用されるポートよりも優先されます。指定しない場合のデフォルトでは、ページ・リクエストのポートを常に使用します。

パブリック・アクセスがport A上でhttpsを経由し、port B上ではより高速なhttp接続を使用するためにPPEリクエストを設定する場合は、これらのパラメータを指定する必要があります。

ページ・リクエストのポートを使用

useDeviceNameCacheKeys

<useDeviceNameCacheKeys>false</useDeviceNameCacheKeys>

このキーは、キャッシュ・キーの作成中にモバイル・デバイス名またはデバイス・クラスを使用する必要があるかどうかを指定します。デフォルトは、デバイス・クラスを使用するよう指定します。

trueに設定されている場合、デバイス名を使用してキャッシュ・キーが作成されます。

false

urlDebugUsers

<urlDebugUsers>fred,bill,ben</urlDebugUsers>

このパラメータは、_debug URLパラメータを使用できるユーザーのリストを示すために指定され、urlDebugModeパラメータ内の値の制限に依存しています。これを指定しない場合、すべてのユーザーが値の制限を条件としてそれを使用できます。

形式は、ポータル・ユーザー名のカンマ区切りのリストであり、前後の空白は無視されます。

要求されません。

urlDebugMode

<urlDebugMode>1</urlDebugMode>

PPEが受け付ける_debug URLパラメータの最高値を指定します。_debugの使用可能値は次のとおりです。

none、0、1、2、3、4および5。

指定した値よりも大きい値をPPEが受信すると、指定可能な最大値に設定されるか、または、値なしが許可されている場合は、元の値が無視されます。

値は、累積的です。たとえば、デバッグ値2を指定すると、デバッグ・レベル1および0の出力も記録されます。

1

stall

<stall>65</stall>

レスポンス・ヘッダーは返されたが、データ自体が返されていない場合は、stallが有効になります。この値により、PPEと接続が持続的に結合されないようにします。PPEは、レスポンス・ヘッダーを受信すると、すべてのデータが取得できるまで待機しようとします。リクエストされたポートレットが大きい場合や、低速のネットワークを使用している場合は、この値を適切に設定してください。

このパラメータの上限値は、Webユーザーが納得できるレスポンス時間(通常は数秒)に設定する必要があります。

65秒

showPageDebug

<showPageDebug>false</showPageDebug>

showPageDebugをtrueに設定すると、すべてのリクエストに対してページのタイミング情報が表示されます。

実行時間およびキャッシュの統計については、第B.5項「実行時間とキャッシュの統計」を参照してください。

false

showError

<showError>true</showError>

ポートレットがタイムアウトになった場合やPPEが特定のポートレット・リクエストの処理に失敗した場合は、ユーザーにエラーが表示されます。詳細なメッセージは表示できませんが、予期したページが表示されなかったことを示す説明が簡単に表示されます。このパラメータをfalseに設定すると、ユーザーにメッセージは表示されません。

true

resourceUrlKey

<resourceUrlKey>KEY</resourceUrlKey>

このキーは、WSRPリソースおよびJPDKリソースのプロキシ処理によってリクエストされたURLに対して、PPEがチェックサムを計算するために使用されます。

JPDKのプロキシ処理を使用している場合は、JNDI環境変数(resourceUrlKeyとも呼ばれる)をプロバイダ用に設定する必要があります。

なし

requestTime

<requestTime>30</requestTime>

独自のタイムアウト値が指定されていないポートレット・リクエストに割り当てられるデフォルトのタイムアウト値です。この値は、サーバーからレスポンス・ヘッダーが返されるまでの許容時間(秒)として適用されます。タイムアウト値は、タイムアウトが発生した場所の値が優先されます。ポートレットに独自のタイムアウト値が設定されている場合は、そのタイムアウトが使用されます。ポートレットにタイムアウトが設定されていない場合は、プロバイダに登録されたタイムアウトが使用されます。いずれの値も設定されていない場合は、requestTimeが使用されます。

このパラメータの上限値は、Webユーザーが納得できるレスポンス時間(通常は数秒)に設定する必要があります。

30秒

queueTimeout

<queueTimeout>10</queueTimeout>

タイムアウトになる前にリクエストがキューに格納される期間。このパラメータは、ポートレットに対するリクエストがタイムアウトになっている場合に使用されます。ただし、リクエストは送信されません。このパラメータを指定すると、他のパラメータと異なり、パフォーマンスの問題を考慮する必要があります。このパラメータは、リクエストがキューに格納される期間を調節するときに使用します。

10秒

proxyHost

proxyPort

<proxyHost>ph.comp.com</proxyHost>
<proxyPort>8888</proxyPort>

Oracle Fusion Middlewareのデータをリクエストするときに必要なプロキシ・サーバーの、ホスト名とポート番号です。これらのパラメータは、PPEとOracle Fusion Middlewareリスナーの間でプロキシ・サーバーを使用している場合にのみ必要です。

なし

poolSize

<poolSize>25</poolSize>

このパラメータは、PPEが一度に作成できる接続の数を表します。この値は、パフォーマンス要件に基づいて調整できます。値を大きくすると、より多くのスレッドおよび接続を使用できますが、使用するリソースが増加します。

25

offlinePath

offlinePathMxml

<offlinePath>/path/offline.html</offlinePath>
<offlinePathMxml>/path/offline.xml</offlinePathMxml>

設定したパラメータに応じて、オフライン・メッセージが表示されます。HTMLブラウザまたはモバイル対応デバイスのメッセージを表示できます。

NULL

minTimeout

<minTimeout>5</minTimeout>

ポートレットで使用できるリクエスト・タイムアウトの最小値です。minTimeoutが5に設定されている場合、ポートレットからタイムアウトとして2が送信されても、minTimeout値の5がそのポートレットに適用されます。

5秒

maxParallelPortlets

<maxParallelPortlets>20</maxParallelPortlets>

指定したページで同時に実行できるポートレット・リクエストの最大数を指定するために使用されます。指定できる値は次のとおりです。

0 - 制限なしを示します(利用可能なフェッチャ数以上)。

任意の正の整数 - 同時に処理できるリクエストの制限数を示します。

20

maxParallelPagePortlets

<maxParallelPagePortlets>10</maxParallelPagePortlets>

PPEで一度に実行可能なページ・ポートレット・リクエストの数を制限するために使用されます。指定できる値は次のとおりです。

0 - 制限なしを示します(利用可能なフェッチャ数以上)。

任意の正の整数 - 同時に処理できるリクエストの制限数を示します。

10

jspSrcAlias

<jspSrcAlias>/internal_jsp/</jspSrcAlias>

JSP Engineの別名(/portal/jspなどのパス)。

/jsp/

jspRoot

<jspRoot>internal_jsp</jspRoot>

JSPページのJSPファイルが配置されている場所の相対パス。

jsp

httpsPorts

<httpsPorts>433:444</httpsPorts>

コロン(:)区切り形式のポートのリスト。SSLを使用するようにOracle Portalが構成されます。

NULL

enableWebCacheStaticRules

<enableWebCacheStaticRules>false</enableWebCacheStaticRules>

このキーは、11g リリース1 (11.1.1)のポータル・リポジトリを実行している場合には使用されません。このキーは、11g リリース1 (11.1.1)の中間層で以前にリリースされたポータル・リポジトリを使用している場合の下位互換性を保つためにのみ提供されています。

以前のリリースのポータル・リポジトリを使用している場合、次の事項を考慮してください。

falseに設定すると、PPEは、収集されたページのサロゲート制御レスポンス・ヘッダーにno-storeディレクティブを格納します。これはOracle Web Cacheで定義されたどの静的なキャッシュ可能性ルールよりも優先し、収集されたページがWeb Cacheにキャッシュされないことが保証されます。

trueに設定すると、収集されたページのサロゲート制御レスポンス・ヘッダーにno-storeディレクティブは格納されません。これにより、収集されたページを静的なキャッシュ可能性ルールを使用してOracle Web Cacheにキャッシュすることが可能になります。

注意: trueに設定すると、URLを指定するだけでキャッシュにあるコンテンツにアクセスできるようになるので、セキュリティ上の影響が発生します。したがって、デフォルト値のfalseを使用することをお薦めします。Oracle Web Cacheのキャッシュに格納したポータル・データは、リクエスト内に存在するセキュアなOracle Portal HTTPヘッダーによって保護されます。trueに設定すると、URLを指定するだけで、作成完了したページをリクエストでき、それがキャッシュから返されます。

false

dmsLogging

<dmsLogging>false</dmsLogging>

dmsLoggingをtrueに設定すると、PPEはDMSログを出力します。

true

cacheEncryptionKey

<cacheEncryptionKey>KEY</cacheEncryptionKey>

このキーを使用すると、Oracle Web Cacheを使用してキャッシュされるヘッダーが暗号化されます。これにより、キャッシュ・キーのセキュリティが向上し、不正なリクエストがキャッシュされたオブジェクトを取得する可能性が低くなります。

このキーは、11g リリース1 (11.1.1)のポータル・リポジトリを実行している場合には使用されません。このキーは、11.1.1の中間層で以前にリリースされたポータル・リポジトリを使用している場合の下位互換性を保つためにのみ提供されています。

サーバーのコンテキスト情報

fileUploadLimit

<fileUploadLimit>65536</fileUploadLimit>

アップロードできるファイルの最大サイズ(バイト)を定義します。

65536

disableUploadRequestChunking

<disableUploadRequestChunking>false</disableUploadRequestChunking>

trueに設定されている場合、ファイル・アップロード時のデータ転送のチャンク・エンコードは無効になります。

false

wsrpFullPageDecoration

<wsrpFullPageDecoration>false</wsrpFullPageDecoration>

falseに設定すると、ポートレットがWSRPポートレットのフル・ページ・モードにレンダリングされるときに装飾を解除します。

true

wsrpCouldNotGetMarkupMsg

<wsrpCouldNotGetMarkupMsg>This is my personalized error message</wsrpCouldNotGetMarkupMsg>

(WSRPポートレット・リクエストが失敗したときに発行される)「マークアップを取得できませんでした」というデフォルトのメッセージをカスタム文字列に置換します。

none - デフォルトのメッセージを表示します。

5.6.9.1.1 プロバイダへのページ・ヘッダーの転送

PPEがページ・リクエストで受信した任意のHTTPヘッダーは、プロバイダに転送できます。これを行うには、ポータル管理者がプロバイダごとに転送するヘッダーを指定します。プロバイダは実行しているURLとオプションのサービスIDで識別されます。

ページ・ヘッダーをプロバイダに転送するには、web.xmlで初期化パラメータのproviderHeadersおよびheadersFor:を指定する必要があります。たとえば、web.xmlファイルに次の行を含めます。

...
<init-param>
<param-name>providerHeaders</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>headersFor: http://my.provider.com/jpdk/providers</param-name>
<param-value>Date:Pragma:X-Oracle-Header</param-value>
</init-param>
<init-param>
<param-name>headersFor: http://some.provider.com/jpdk/providers urn:charts</param-name>
<param-value>Via:X-Custom-Header</param-value>
</init-param>
<init-param>
<param-name>headersFor: http://other.provider.com/jpdk/clipping</param-name>
<param-value>Cookie/ORA_UCM_INFO;sandiaCookie:Via:X-Custom-Header</param-value>
</init-param>
...

これは、http://my.provider.com/jpdk/providersで実行され、ページ・リクエストからDate、PragmaおよびX-Oracle-Headerを受信するプロバイダ、およびhttp://some.provider.com/jpdk/providersで実行され、urn:chartsというサービスIDを有し、ViaおよびX-Custom-Headerページ・リクエスト・ヘッダーを受信するプロバイダに対するリクエストとなります。

http://other.provider.com/jpdk/clippingで実行されているプロバイダは、ORA_UCM_INFOおよびsandiaCookieページ・リクエストCookie以外にも、ViaおよびX-Custom-Headerページ・リクエスト・ヘッダーを受信します。ページ・リクエストの他のいかなるCookieも、転送されません。

表5-7では、パラメータproviderHeadersおよびheadersForについて説明しています。

表5-7 ProviderHeadersパラメータ

PPE設定

構文

説明

デフォルト値

providerHeaders

<init-param>

<param-name>providerHeaders</param-name>

<param-value>true</param-value>

</init-param>

ページ・ヘッダーをプロバイダへ転送可能にします。指定できる値は次のとおりです。

true: headersFor: <URL>[<sid>]で指定されたヘッダーがプロバイダに転送されます。

false - プロバイダの標準的なヘッダー処理を行います。

providerHeadersパラメータのデフォルトをfalseに設定することで、プロバイダのヘッダーが転送されないPPEの起動やページ処理時に、この機能に関連付けられたオーバーヘッドが処理されなくなります。

false

headersFor: <url> [<sid>]

<init-param>

<param-name>headersFor: <url> [<sid>]</param-name>

<param-value> header name</param-value>

</init-param>

コロン区切り形式のHTTPヘッダー名リストを指定します。これはサービスID <sid> (指定された場合)とともにプロバイダに送信され、URL <url>で実行されます。

また、このパラメータは、転送する名前付きCookieの指定にも使用されます。これらは、「Cookie/」という文字列が先頭に付くCookie名のセミコロン区切り形式のリストを使用して定義します。

なし

5.6.9.2 WLSTを使用したParallel Page Engineの構成

Portal中間層リポジトリ・サーブレットで使用される構成ファイルであるappConfig.xmlの一部のPPE構成パラメータは、WLST(オンライン)コマンドを使用して更新されます。WLSTコマンドは、appConfig.xmlファイルの次のパラメータを更新するために使用されます。

configurePortalPageEngine(encrypt_key, resource_url_key, use_port, use_scheme, x509certfile)

引数

定義

encrypt_key

Web Cacheを使用したキャッシュに使用されるヘッダーを暗号化するHMACキーを指定します。これにより、キャッシュ・キーのセキュリティが向上し、キャッシュされたオブジェクトが不正なリクエストにより取得される可能性が低くなります。

resource_url_key

このキーは、WSRPリソースおよびJPDKリソースのプロキシ処理によってリクエストされたURLに対して、チェックサムを計算するために使用されます。WSRPリソースのプロキシ処理を機能させるには、キーの値に10文字以上の英数字を設定する必要があります。また、JPDKのプロキシ処理では、JNDI環境変数(resourceUrlKeyとも呼ばれる)をプロバイダ用に設定する必要があります。

use_port

PPEがポータルへリクエストを行うときに使用されるポートよりも優先されます。指定しない場合のデフォルトでは、ページ・リクエストのポートを常に使用します。use_schemeを設定する場合には、use_port引数も設定する必要があります。

他の理由で使用されることもありますが、ほとんどは、SSLがブラウザとPPE間では実行されていてもPPEとポータル間では実行されていない場合に使用されます。この場合、ループバック・リクエストの非SSLポートは、ブラウザで使用されるSSLポートとは異なります。

use_scheme

PPEがポータルへリクエストを行うときに使用されるスキーム(HTTPまたはHTTPS)よりも優先されます。指定しない場合のデフォルトでは、ページ・リクエストのスキームを常に使用します。use_schemeを設定する場合には、use_port引数も設定する必要があります。

x509certfile

HTTPクライアントに暗黙的に信頼される証明書のリストが含まれたファイルを指定します。これらの証明書は、SSLを使用するHTTPクライアントにより確立されるすべての接続に対するトラスト・ポイントとして追加されます。

注意:

詳細は、表5-6「Parallel Page Engine (PPE)のパラメータ」を参照してください。

例5-10 Parallel Page Engineの更新

configurePortalPageEngine(encrypt_key='encryption key',resource_url_key='foo.oracle.com',use_port=9999,use_scheme='http',x509certfile='file')

5.6.10 Portalスキーマのパスワードの取得

Oracle Portalスキーマのパスワードは、ポータル・スキーマへのログインが必要な一部の操作で必要になります。この項では、Oracle Portalスキーマ・パスワードの取得方法について説明します。デフォルトおよびデフォルト以外のOracle Portal用のスキーマ・パスワードの変更方法の詳細は、第6.11項「Oracle Portalスキーマ・パスワードの変更」を参照してください。Portalスキーマのパスワードを取得するには、次の方法のいずれかを使用できます。

- Oracle Enterprise Manager 11g Fusion Middleware Controlの使用

- WLSTコマンドの使用

Oracle Enterprise Manager 11g Fusion Middleware Controlの使用

Oracle Enterprise Manager 11g Fusion Middleware Controlを使用してOracle Portalスキーマのパスワードを取得するには、次の手順を実行します。

1. Enterprise Managerにログインします。

2. WebLogicドメインを開いて、「ClasssicDomain」を選択します。

3. 「ClasssicDomain」を右クリックして、「セキュリティ」→「資格証明」を選択します。
「資格証明」ページが表示されます。

4. 「資格証明」でoracle.portal.dadsを開いて、mapnameとkeynameを表示します。デフォルトのmapnameはoracle.portal.dadsで、keynameは/pls/portalです。

WLSTコマンドの使用

Oracle Portalスキーマのパスワードは構成された資格証明ストアに格納されており、管理者はWLST listCredコマンドを使用して取得できます。このコマンドは、特定のマップ名およびキー名を持つドメイン資格証明ストア内の資格証明の属性値リストを返し、パスワード・タイプの資格証明にカプセル化されたデータのみをリストします。Portalスキーマのパスワードを取得するには、次の手順を実行します。

1. Windowsの場合はORACLE_HOME\common\binにあるwlstを実行します(Unixの場合はwlst.sh)。

2. connect()" -> wls:\offline>connect()を入力します。

3. ユーザー名、パスワードおよびサーバーURLを入力します。

4. listCred(map="mapName", key="keyName")を実行します。たとえば、wls:/ClassicDomain/serverConfig> listCred(map="oracle.portal.dads", key="/pls/portal")のようになります。

5. 次の例のように出力されます。

{map=oracle.portal.dads, key=/pls/portal}
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

[Name : DEV_PORTAL, Description : null, expiry Date : null]
PASSWORD:manager1

5.6.11 カスタム・イメージ・ディレクトリの使用

Oracle Portalのイメージ・ディレクトリ(デフォルトではORACLE_HOME\portal\images)に格納されているカスタム・イメージが将来のアップグレード時に失われないようにするために、独自のイメージ・ディレクトリを作成し、そのディレクトリに対して適切なOracle HTTP Serverの別名を設定することをお薦めします。

たとえば、ファイルORACLE_HOME\portal\conf\portal.confに次のようなエントリを追加します。この変更を行うには、ローカルのOracle Enterprise Manager 11g Fusion Middleware Controlインスタンスを使用することをお薦めします。詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』または『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

Alias /myimages/ "/opt/app/myportal/images/"
<Directory "/opt/app/myportal/images/">
AllowOverride None
Order allow,deny
Allow from all
ExpiresActive on
ExpiresDefault A2592000
<Files *>
Header set Surrogate-Control 'max-age=2592000'
</Files>
</Directory>

Oracle Web Cacheは、.bmp、.gif、.png、.jpgおよび.jpegファイルをグローバルにキャッシュするようにあらかじめ構成されているため、特別なOracle Web Cache構成を実行する必要はありません。

5.7 Oracle Portalでのモバイル・サポートの構成

この項では、Oracle PortalとOracle Application Server Wirelessが連携して動作するように構成する方法を説明します。Oracle Portalページは、デスクトップ・ブラウザ、携帯電話、PDAなど様々なデバイスで表示できます。Oracle Portalでは、OracleAS Wirelessを使用して、ワイヤレス・デバイスからのリクエストを受信したり、ポータルが提供するコンテンツを適切な形式に変換するためのワイヤレス機能を提供します。

この項では、次の内容について説明します。

- Oracle Application Server Wirelessのインストール

- Oracle Portalモバイル・アクセス用のOracle AS Single Sign-Onのパッチ適用

- Oracle Portalでのモバイル設定の構成

- モバイル・アクセスの構成

- キャッシュ・キーのモバイル・デバイス・コンポーネントの変更

5.7.1 Oracle Application Server Wirelessのインストール

現在、OracleAS Wirelessは、デフォルトではインストールされなくなりました。OracleAS Wireless 10gは、個別にインストールする必要があります。

Wirelessをインストールするには、次の手順を実行します。

1. OTNで配布されているOracle Application Server 10gリリース2をダウンロードします。
http://www.oracle.com/technetwork/middleware/ias/downloads/101202-095224.html

2. 画面に表示される手順に従い、配布されているOracleAS Wireless 10gをインストールします。
別のサーバーへのOracleAS Wireless 10gのインストールが完了したら、第5.7.4項「モバイル・アクセスの構成」に示すように、Oracle PortalとOracleAS Wirelessを構成します。

注意:

Oracle Portal 11gリリース1(11.1.1.4)では、モバイル・サポートにOracleAS Wireless 10gを使用します。

3. Wirelessインスタンスに、次のOracleAS Wireless 10gパッチをインストールする必要があります。

- OracleAS Wireless 10g (10.1.2.0.2)を使用している場合は、https://support.oracle.com/からパッチID 8567297をダウンロードできます。

- OracleAS Wireless 10g (10.1.2.3)を使用している場合は、https://support.oracle.com/からパッチID 8567297をダウンロードできます。

このパッチは、モバイル・デバイスのCookie処理に関する問題を修正するために必要です。

注意:

Oracle Application Server Wireless 10gとOracle Portal 11g リリース1 (11.1.1)を統合するには、My Oracle Supportノート837837.1 (Oracle Portal 11gリリース1 (11.1.1)とOracle Application Server Wireless)の説明に従って手動の手順を実行する必要があります。また、次も参照してください。

- My Oracle Supportノート343563.1: Oracle Application Server 10gリリース2 (10.1.2)の非推奨機能について

- My Oracle Supportノート402434.1: Oracle Application Server 10g リリース3 (10.1.3)の非推奨機能について

5.7.2 Oracle Portalモバイル・アクセス用のOracle AS Single Sign-Onのパッチ適用

モバイル・ログイン・フォームに関する問題を修正するには、https://support.oracle.com/からパッチID8564509をダウンロードしてインストールする必要があります。

5.7.3 Oracle Portalでのモバイル設定の構成

Oracle Portalでモバイル設定を構成するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「モバイル」タブをクリックします。

Oracle Portalのほとんどのモバイル関連の設定がここにあります。詳細は、次を参照してください。

- モバイル・アクセスの有効化

- モバイル・ホーム・ページの構成

- モバイル・バナー・リンクでのページ・タイトルの表示

- PDAでの拡張ページ・レイアウトの表示

- モバイル・レスポンスのロギング

- OracleAS Wireless PortalサービスURL参照の構成

注意:

ホストされた環境では、各サブスクライバを個別に管理できます。ただし、OracleAS WirelessサービスURLの設定は例外です。Oracle Portalがホスト・モードで動作している場合(複数のサブスクライバが存在)、Oracle AS WirelessサービスURLへの変更はすべてのサブスクライバに影響が及ぶため、ホスト側の管理者がコマンドライン・スクリプトを使用して行う必要があります。

5.7.3.1 モバイル・アクセスの有効化

「モバイル・アクセスを使用」オプションを使用すると、OracleAS Wirelessを介したモバイル・クライアントからのポータル・ページ・リクエストに対するOracle Portalのレスポンス方法を制御できます。Oracle Portalがモバイル・リクエストに対するレスポンスでページやポートレットを返す場合は、「モバイル・アクセスを使用」オプションを選択する必要があります。

このオプションを選択しないと、Oracle Portalはモバイル・リクエストに対してモバイルが有効になっていないことを伝えるメッセージで応答します。

モバイル・アクセスを有効にするには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。

2. 「モバイル」タブをクリックします。

3. 「モバイル・アクセスを使用」オプションを選択します。

4. 「OK」をクリックします。

5.7.3.2 モバイル・ホーム・ページの構成

モバイル・ホーム・ページは、ユーザーがモバイル・デバイスからOracle Portalにアクセスしたときに最初に表示されるページです。モバイル・アクセスが有効になっている場合は、モバイル・デバイス専用のホーム・ページをユーザーが選択できるかどうかを指定できます。また、すべてのモバイル・ホーム・ページにデフォルトで「ログイン」リンクを表示するかどうかを決定できます。

- ユーザーによるモバイル・ホーム・ページの選択の有効化

- モバイル・ホーム・ページからの「ログイン」リンクの除外

5.7.3.2.1 ユーザーによるモバイル・ホーム・ページの選択の有効化

「モバイル・ホームページ選択を有効にする」オプションを使用すると、ポータルのユーザーがモバイル・アクセス用に異なるホーム・ページを選択できるかどうかを制御できます。このオプションを選択しない場合、モバイル・デバイスに表示されるホーム・ページは、標準のデスクトップ・アクセスに使用されるホーム・ページと同じになります。

モバイル・ホーム・ページを許可するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。

2. 「モバイル」タブをクリックします。

3. 「モバイル・ホームページ選択を有効にする」オプションを選択します。

4. 「OK」をクリックします。

このオプションを選択すると、ユーザーが「アカウント情報」ページで「デフォルト・モバイル・ホームページ」フィールドを使用できるようになります。詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

5.7.3.2.2 モバイル・ホーム・ページからのログイン・リンクの除外

「ログイン・リンクをモバイル・ホーム・ページから除く」オプションを使用すると、モバイル・ホーム・ページに「ログイン」リンクを表示するかどうかを制御できます。モバイル・ホーム・ページが許可されると、モバイル・ホーム・ページにはデフォルトで「ログイン」リンクが表示されます。デフォルトの「ログイン」リンクを表示しない場合は、このオプションを選択します。

モバイル・ホーム・ページから「ログイン」リンクを除外するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。

2. 「モバイル」タブをクリックします。

3. 「ログイン・リンクをモバイル・ホーム・ページから除く」オプションを選択します。

4. 「OK」をクリックします。

5.7.3.3 モバイル・バナー・リンクでのページ・タイトルの表示

「モバイル・バナー・リンクでページ・タイトルを使用する」オプションを使用すると、モバイル・バナーのナビゲーション・リンクに表示されるテキストを選択できます。ナビゲーション・リンク・テキストでページ・タイトルを使用するには、このオプションを選択します。このサンプルは、図5-2を参照してください。このオプションを選択しない場合は、デフォルトのテキスト(「ホーム」および「戻る」)がかわりに使用されます。

ナビゲーション・リンク・テキストでページ・タイトルを使用するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。

2. 「モバイル」タブをクリックします。

3. 「モバイル・バナー・リンクでページ・タイトルを使用する」オプションを選択します。

4. 「OK」をクリックします。

5.7.3.4 PDAでの拡張ページ・レイアウトの表示

「表示をPDA用に拡張」オプションを使用すると、PDA(携帯情報端末)に拡張ページ・レイアウトを表示できます。PDAは他のモバイル・デバイスに比べて表示機能が優れておりシンプルであるため、PDAでのポータル・ページの表示は拡張が可能です。

このオプションを選択すると、テキスト、リンク・テキスト、ページ・リストの背景、バナーの背景などにPDAのデフォルトのフォント設定と色設定が使用されます。「PDA表示オプション」を追加設定することにより、デフォルトのPDA表示設定をオーバーライドしたり、必要に応じてPDAページ・バナーにイメージを組み込むことができます。図5-2「PDAのサンプル・ページ・レイアウト」を参照してください。

図5-2 PDAのサンプル・ページ・レイアウト

このオプションを選択しない場合は、すべてのモバイル・デバイスに同じページ・レイアウトが使用されます。

PDAに拡張ページ・レイアウトを表示したり、オプションでPDA表示オプションをカスタマイズするには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。

2. 「モバイル」タブをクリックします。

3. 「表示をPDA用に拡張」オプションを選択します。

4. 「適用」をクリックします。
「適用」をクリックすると、「PDA表示オプション」という新しいセクションがページの下部に表示されます。

5. (オプション)PDAでのポータル・ページの表示方法を制御するには、「PDA表示オプション」を設定します。フォントおよび色のプリファレンスを指定する場合は、有効なマークアップを使用してください。
詳細は、表5-8「PDA表示オプション」を参照してください。

6. 「OK」をクリックします。

表5-8 PDA表示オプション

オプション

説明

一般オプション

次に示すデフォルトのフォントと色をオーバーライドします。

- 背景色 - ポータル・ページの背景色を指定します。たとえば、#FF0000またはredと入力します。

- フォント名 - ポータル・ページのテキスト表示に使用されるフォントを指定します。たとえば、arialと入力します。

- フォント・サイズ - ポータル・ページのテキスト表示に使用されるフォント・サイズを指定します。たとえば、-1と入力します。

- フォント色 - ポータル・ページのテキスト表示に使用されるフォント色を指定します。たとえば、#0000FFまたはblueと入力します。

PDAで選択されたデフォルトのフォントまたは色を使用するには、該当するフィールドを空白のままにします。

基本リンク・オプション

次に示すデフォルトの色をオーバーライドします。

- 未参照のリンク色 - ポータル・ページの未参照リンクの色を指定します。たとえば、#00FFFFまたはlightblueと入力します。

- 選択したリンク色 - ポータル・ページの選択されたリンクの色を指定します。たとえば、#FFFFFFまたはwhiteと入力します。

- 参照済リンク色 - ポータル・ページの参照済リンクの色を指定します。たとえば、#FF00FFまたはmagentaと入力します。

PDAで選択されたデフォルトのリンク色を使用するには、該当するフィールドを空白のままにします。

バナー・イメージ・オプション

PDAバナーにイメージ(.GIF)を指定するには、次のオプションを使用します。

- バナー・イメージ(ファイル名またはURL) - イメージがポータルのデフォルト・イメージ・ディレクトリにある場合は、.GIFファイルの名前のみを入力します。たとえば、mylogoと入力します。または、イメージの完全なURLを入力します。たとえば、http://www.mycompany/images/mylogoと入力します。

- デフォルト・イメージ・ディレクトリですか。 - 使用するバナー・イメージがポータルのデフォルト・イメージ・ディレクトリにある場合は、このチェック・ボックスを選択します。イメージがaccBanner背景色の場合は、このチェック・ボックスを選択解除して、ポータル・ページの背景バナー色を指定します。たとえば、#00FFFFまたはlightblueのように入力します。URLのPDA.essibleで選択されたデフォルトの色を使用するには、該当するフィールドを空白のままにします。

- バナーの背景色 - ポータル・ページのバナーの背景色を指定します。たとえば、#00FFFFまたはlightblueと入力します。PDAで選択されたデフォルトの色を使用するには、該当するフィールドを空白のままにします。

ページ・リスト(ブレッドクラム)オプション

次に示すデフォルトの色をオーバーライドします。

- 前景色 - ポータル・ページのブレッドクラムの前景色を指定します。たとえば、#00FFFFまたはlightblueと入力します。

- 背景色 - ポータル・ページのブレッドクラムの背景色を指定します。たとえば、#0000FFまたはblueと入力します。

- リンク色 - ポータル・ページのブレッドクラムのリンク・テキストの色を指定します。たとえば、#000000またはblackと入力します。

PDAで選択されたデフォルトの色を使用するには、該当するフィールドを空白のままにします。

ログイン/ログアウト・リンク

ポータル・ページに表示されるログイン/ログアウト・リンクの色を指定します。たとえば、#000000またはblackと入力します。

5.7.3.5 モバイル・レスポンスのロギング

「モバイル・レスポンス・ログ」オプションを使用すると、モバイル・リクエストに対するポートレット・レスポンスをログに記録するかどうかを制御できます。この機能は、開発時のポートレットのデバッグに役立ちます。このオプションを選択すると、モバイル・デバイスのリクエストに対するレスポンスで、ページに表示されるモバイル・ポートレットによって生成されるコンテンツがログに記録されます。

モバイル・デバイスでは、ポータル・コンテンツがMobileXMLと呼ばれるOracle固有のマークアップ言語でレンダリングされます。このマークアップは、OracleAS Wirelessによって、リクエストを生成した適切なデバイスのマークアップに変換されます。

次の条件をすべて満たしている場合は、ポートレット・レスポンスがログに記録されます。

- 「モバイル・レスポンス・ログ」オプションが選択されています。

- リクエストしているユーザーがログインしています。

- リクエストがモバイル・デバイスからのものであるか、モバイル・ページへのものです。

注意:

- このオプションは、開発目的にのみ使用してください。モバイル・レスポンスのロギングはポータルのパフォーマンスに影響を与えるため、本稼働ポータルにこのオプションを設定することはお薦めしません。

- 「モバイル・レスポンス・ログ」オプションを有効または無効にする際、現在キャッシュされているページのデータは常にすべて無効となります。したがって、一般のアクセス用にOracle Portalを配置した後は、このオプションを頻繁に変更しないことをお薦めします。

モバイル・リクエストに対するポートレット・レスポンスをログに記録するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。

2. 「モバイル」タブをクリックします。

3. 「モバイル・レスポンス・ログ」オプションを選択します。

4. 「OK」をクリックします。

Oracle Portalには、ログに記録されたコンテンツを表示するための次の2つの組込みポートレットが付属しています。

- 最新のモバイル・ログ・エントリ - 特定ユーザーの最新の記録のみが、データの記録されたポートレットに関係なく表示されます。

- モバイル・ログ・ポートレット - ユーザーのコンテンツが記録されているすべてのポートレットのリストが表示されます。ユーザーは、確認するポートレットのコンテンツを選択できます。

詳細は、OTNのサイトでプロバイダのデバッグ技術: モバイル・ログ・ビューアの使用に関する記事(http://www.oracle.com/technology/products/ias/portal/html/mobile_11g_debugging.with.logs.html)を参照してください。

5.7.4 モバイル・アクセスの構成

最初のモバイル・アクセス構成、またはその後のOracle Application Server再構成によるOracle Application Server WirelessサービスURLやOracle Portalホーム・ページURLの変更後は、OracleAS WirelessとOracle Portalを手動で構成して、それぞれのURLを反映する必要があります。詳細は、次を参照してください。

- Oracle Portalホーム・ページURL参照の構成

- OracleAS Wireless PortalサービスURL参照の構成

5.7.4.1 Oracle Portalホーム・ページURL参照の構成

ホーム・ページURLは、OracleAS Wirelessサービスの定義で参照するアドレスです。ワイヤレス・アクセスを最初に構成したとき、またはホーム・ページURLが変更された場合は、次の参照を構成または更新する必要があります。

- Oracle Application Server Wirelessサービスの定義

- Oracle Portal自体への内部参照

5.7.4.1.1 Oracle Application Server Wirelessサービスの定義

OracleAS Wirelessサーバー・サービス定義のOracle Portalホーム・ページURLを構成するには、次の手順を実行します。

1. 次のURLを使用して、OracleAS Wirelessツールにログインします。

http://<host>:<port>/webtool/login.uix

2. ワイヤレス管理者用のユーザー名とパスワードを入力します。

3. 「コンテンツ」タブをクリックします。

4. コンテンツ・マネージャでPortalサービスを選択し、「編集」をクリックします。
コンテンツ・マネージャにPortalサービスが一覧表示されない場合は、「新しいPortalサービスの作成」に示すように、Wirelessの管理ツールを使用して新しいサービスを作成します。

5. 画面の左側にある「入力パラメータ」をクリックします。

6. 「パラメータ」画面で、必要に応じてURLを変更します。

7. 「適用」をクリックして、変更を保存します。

8. OracleAS Wirelessコンテンツ・マネージャからログアウトします。

関連項目:

Oracle Application Server Wireless管理者ガイド

新しいPortalサービスの作成

コンテンツ・マネージャにまだPortalサービスがない場合は、次に示すように、Wirelessの管理ツールを使用して作成します。

1. Wirelessの管理ツールを開き、「サービス」タブを選択します。

2. 「HttpMasterService」を選択し、「アプリケーションの作成」をクリックします。

3. 「マルチチャネル・アプリケーション」を選択し、「作成」をクリックします。

4. アプリケーション名に「portalservice」を、URLにPortalホーム・ページの完全なURLを入力します。
Portalホーム・ページURLが、AS11 Portalの「グローバル設定」の「モバイル」タブに次の形式で表示されます。

http://<AS11portal-host>/portal/pls/portal/portal.home

5. 「次へ」をクリックして、「完了」をクリックします。

6. 「portalservice」を選択して、「クイック公開」をクリックし、「portalservice」と名付けます。

7. 「終了」をクリックします。

8. 「コンテンツ」タブを選択し、「アプリケーション・リンクの追加」をクリックします。

9. 「master」リンクを開いて「portalservice」を選択し、「次へ」をクリックします。

10. アプリケーション・リンクを「portalservice」と名付け、「次へ」をクリックしてから「終了」をクリックします。

11. 「制御コンテンツへのアクセス」をクリックし、「ゲスト」を選択して「アプリケーションの割当て」をクリックします。

12. 「portalservice」を選択し、「グループに追加」をクリックしてから「終了」をクリックします。

13. 「ユーザー」タブを選択してから「ユーザー」サブタブを選択します。

14. 「ゲスト」を選択し、「アプリケーション・リンクの表示」をクリックして、「portalservice」がリストに表示されたことを確認します。

15. portalserviceサービスの表にあるオブジェクトID(例、7066)をメモして、「Portalグローバル設定モバイル」タブでURLを指定します。

5.7.4.1.2 Oracle Portal自体への内部参照

Oracle Portal自体のホーム・ページURLへの参照を構成するには、スクリプトcfgiasw.plを使用して値を設定します。このスクリプト・ファイルは次の場所にあります。

ORACLE_HOME/assistants/opca/

スクリプトを実行するには、次のコマンドを使用します。

perl cfgiasw.pl -s portal -c portal_db -h "http://my_portal_server.com/portal/pls/portal/portal.home"

前述の例はUNIXマシン固有のものです。cfgiaswスクリプトの詳細は、第B.6項「cfgiaswスクリプトを使用したモバイルの構成」を参照してください。

5.7.4.2 OracleAS Wireless PortalサービスURL参照の構成

Oracle Portalは、モバイル・デバイスへのアクセスを提供する手段としてOracle Application Server Wirelessを使用します。このアクセスを提供するには、ポータルが登録されているOracleAS WirelessサービスへのURLをOracle Portalが認識している必要があります。OracleAS WirelessサービスURLが変更された場合は、Oracle Portal内におけるその参照を更新する必要があります。この参照は次のいずれかの方法で構成できます。

- 「グローバル設定」ページを使用したOracleAS Wireless PortalサービスURLの構成

- cfgiaswスクリプトを使用したOracleAS WirelessサービスURL参照の構成

5.7.4.2.1 「グローバル設定」ページを使用したOracleAS Wireless PortalサービスURLの構成

「グローバル設定」ページを使用してOracleAS Wireless PortalサービスURLを更新するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「モバイル」タブをクリックします。

3. OracleAS Wireless PortalサービスURLフィールドにURLを入力します。

4. アプリケーション名に「portalservice」を、URLにPortalホーム・ページの完全なURLを次の形式で入力します。

http://<wireless-host>/ptg/rm?PAoid=<objectid>

<objectid>は、Wirelessの「管理」画面の「コンテンツ」タブのポータル・サービス・オブジェクトIDです。

5. 「OK」をクリックします。

Oracle Portalが複数のサブスクライバで動作していない場合にのみ、OracleAS Wireless PortalサービスURLの定義を設定できます。Oracle Portalが複数のサブスクライバで動作している場合は、ホスト側の管理者のみが(cfgiaswスクリプトを使用して)OracleAS Wireless PortalサービスURLの値を変更できます。

5.7.4.2.2 cfgiaswスクリプトを使用したOracleAS WirelessサービスURL参照の構成

Oracle Application Server Wireless PortalサービスのURLへのOracle Portalの参照を変更または構成するには、スクリプトcfgiasw.plを使用して値を設定します。このスクリプト・ファイルは次の場所にあります。

ORACLE_HOME\assistants\opca\

スクリプトを実行するには、次のコマンドを使用します。

perl cfgiasw.pl -s portal -c portal_db -w "http://my_iasw_server.com/ptg/rm?PAoid=12345"

前述の例はUNIXマシン固有のものです。cfgiaswスクリプトの詳細は、第B.6項「cfgiaswスクリプトを使用したモバイルの構成」を参照してください。

5.7.5 キャッシュ・キーのモバイル・デバイス・コンポーネントの変更

OracleAS WirelessがOracle Web Cacheと統合されることにより、ページ・レンダリングのパフォーマンスとスケーラビリティが向上します。キャッシュは、変換後のコンテンツ用のリポジトリとして使用されます。つまり、どのコンテンツをキャッシュに挿入する必要があるのか、およびキャッシュ内のコンテンツがいつ期限切れになるのかをワイヤレス・サーバーが実行時にチェックします。Oracle Portalで使用されるキャッシュ・キーは、多数のコンポーネントによって構成されています。その1つにOracleAS WirelessヘッダーのX-Oracle-Device.Classに基づくコンポーネントがあります。このコンポーネントにより、使用するモバイル・デバイスのクラスに基づいてポートレット・コンテンツがキャッシュされます。

デバイスのクラスではなく、特定のデバイス名に基づいてポートレット・コンテンツをキャッシュできます。詳細は、第B.7項「cfgxodnc.plスクリプトを使用したキャッシュ・キーのモバイル・デバイス・コンポーネントの変更」を参照してください。

5.8 ユーザー、グループおよびパスワードの管理

ユーザー、グループおよびパスワードの管理の詳細は、第7章「Oracle Portalの保護」を参照してください。

5.9 ブラウザ設定の構成

『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』の「はじめに」のブラウザの推奨事項を参照してください。

5.10 言語サポートの構成

Oracle Portalでは、様々な言語でアプリケーションの開発や配置が行えます。このため、開発者はポータルを構築する際に自国語で作業できます。また、エンド・ユーザーがドキュメントおよびその他のコンテンツを様々な言語で使用できるように、セルフサービス・コンテンツ管理では複数の言語をサポートしています。

中間層インストール時のデフォルトでは、en_USをサポートするようにOracle Portalが構成されます。インストール後に追加の言語(表5-9を参照)を構成するには、ptllangツールを使用します。詳細は、第5.10.1項「Oracle Portalインストール後の言語のインストール」を参照してください。

表5-9 Oracle Portalの言語とその略称

言語

言語の略称

アラビア語

ar

ポルトガル語(ブラジル)

ptb

フランス語(カナダ)

frc

チェコ語

cs

デンマーク語

dk

オランダ語

nl

英語

us

フィンランド語

sf

フランス語

f

ドイツ語

d

ギリシア語

el

ヘブライ語

iw

ハンガリー語

hu

イタリア語

i

日本語

ja

韓国語

ko

南米スペイン語

esa

ノルウェー語

n

ポーランド語

pl

ポルトガル語

pt

ルーマニア語

ro

ロシア語

ru

中国語(簡体字)

zhs

スロバキア語

sk

スペイン語

e

スウェーデン語

s

タイ語

th

中国語(繁体字)

zht

トルコ語

tr

注意:

Oracle Portalは、ZHT32EUCデータベース文字セットではサポートされていません。使用している環境で中国語(繁体字)をサポートしている場合は、AL32UTF8、ZHT16MSWIN950またはZHT16BIG5の文字セットを使用してください。

構成されている言語は、「言語の設定」ポートレットに表示されます。Oracle Portalは、ブラウザの言語設定に対応する言語、または「言語の設定」ポートレットで選択した言語で使用できます。ただし、ブラウザの言語設定がOracle Portalにインストールされている言語と対応している必要があります。「言語の設定」ポートレットはデフォルトでは表示されません。このポートレットは「Portalビルダー」ページや、Oracle Portalで作成した他のすべてのページで追加できます。

関連項目:

『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』の「言語の設定」ポートレットの操作に関する項を参照してください。

この項には次のトピックが含まれます:

- Oracle Portalインストール後の言語のインストール

- 地域の使用の有効化

5.10.1 Oracle Portalインストール後の言語のインストール

Oracle Portalをインストールした後で言語をインストールするには、ptllangを実行します。Oracle Portalでサポートする言語ごとに、ptllangを実行する必要があります。

注意:

ログイン操作時に、情報がOracle Application Server Single Sign-Onに送信されます。認証リクエストに使用された言語は、Oracle Portalに送り返されます。選択した言語が認識されるように、OracleAS Single Sign-Onには、Oracle Portalに存在するすべての言語がインストールされている必要があります。選択した言語がOracleAS Single Sign-Onにインストールされていない場合は、デフォルトで英語(アメリカ)が設定されます。これは、OracleAS Single Sign-Onで使用できない言語による認証をリクエストしたOracle Portalにアサートされる言語です。

Oracle Portalの「言語の設定」ポートレットでは、OracleAS Single Sign-OnとOracle Portalの言語および永続言語Cookieを設定します。

同じOracleAS Single Sign-Onを使用するよう構成されているポータルが複数存在し、それらのポータルに別々の言語がインストールされている場合は、どのポータルからの「言語の設定」リクエストにも対応できるように、これらのすべての言語がOracleAS Single Sign-Onに存在している必要があります。

環境

ptllangツールは、ORACLE_HOME/assistants/opcaディレクトリにあります。ORACLE_HOME環境変数をOracle Portal、Forms、ReportsおよびDiscovererのバイナリが格納されたOracleホームに設定します。

前提条件

Oracle Metadata Repositoryがインストール済で、それぞれのデータベースが起動していること。

使用方法

Windowsの場合:

ptllang.bat  -lang lang_code [ -s portal_schema] [-sp portal_schema_password] [-c portal_db_connect_string] [-log log_file_directory]

UNIXの場合:

ptllang.sh  -lang lang_code [ -s portal_schema] [-sp portal_schema_password] [-c portal_db_connect_string] [-log log_file_directory]

表5-10は、ptllangでサポートされているパラメータの一覧とその説明です。

表5-10 ptllangパラメータ

パラメータ

定義

-s

Oracle Portalスキーマ名。

デフォルト: portal

-sp

Oracle Portalスキーマのパスワード。

-c

Oracle Metadata Repositoryがインストールされているターゲット・データベースへの接続文字列。書式は、DbHostName:DbPortNumber:DbServiceNameです。

-lang

インストールする言語の略称。使用できるすべての略称は、表5-9を参照してください。

-log

ログ・ファイルが書き込まれるディレクトリ。

使用例

次の例では、コマンドラインで入力したものを渡します。これらの例では、オランダ語の文字列をOracle Metadata Repositoryのポータル・スキーマにロードします。

Windowsの場合:

ptllang.bat -s portal -sp portal -c myDBhost.domain.com:1521:dbServiceName -lang nl -log c:\temp

UNIXの場合:

ptllang.sh -s portal -sp portal -c myDBhost.domain.com:1521:dbServiceName -lang nl  -log /oracle/log

5.10.2 地域の使用の有効化

言語をOracle Portalにインストールすると、エンド・ユーザーは使用する言語を「言語の設定」ポートレットに表示される言語から選択できます。特定の言語については、地理上の位置(地域)を指定して選択することもできます。これにより日付、通貨、小数点などの書式のローカライゼーション設定が正しく表示されます。たとえば、ポータル言語を英語に設定する場合は、アメリカ、オーストラリア、カナダ、アイルランド、イギリスなどの地域から選択できます。

地域の選択は、デフォルトの「言語の設定」ポートレットでは使用できません。ユーザーが地理上の位置(地域)を指定できるようにするには、「言語の設定」ポートレットを編集する必要があります。

「言語の設定」ポートレットは、デフォルトでは表示されません。ただし、「Portalビルダー」ページやその他のOracle Portalページに追加できます。

ポータル・ページへの「言語の設定」ポートレットの追加

「言語の設定」ポートレットをポータル・ページに追加するには、次の手順を実行します。

1. ポータル・スキーマの所有者としてOracle Portalにログインします。

2. 「言語の設定」ポートレットを表示させるページを表示します。たとえば、「言語の設定」ポートレットを「Portalビルダー」ページの「管理者」タブに追加できます。

3. ページの上部にある「編集」をクリックします。

4. ポートレットを追加するリージョンにある「ポートレットの追加」アイコンをクリックします。

5. ポートレット・リポジトリで、「Portalコンテンツ・ツール」をクリックします。

6. 「使用可能なポートレット」領域で「言語の設定」をクリックし、「OK」をクリックします。
これで、「言語の設定」ポートレットがポータル・ページで使用可能になります。

注意:

ページに「言語の設定」ポートレットを追加した後で別の言語をインストールすると、ページを表示したときに、その新しい言語が表示されません。これに対処するには、そのポートレットを削除してからページに再度追加します。

地域およびロケールの使用の有効化

地域およびロケールの使用を有効にするには、次の手順を実行します。

1. ポータル・スキーマの所有者としてOracle Portalにログインします。

2. 「言語の設定」ポートレットの「デフォルトの編集」アイコンをクリックします。

3. 表示された「言語の設定ポートレット設定の編集」画面で、「地域の選択を有効にする」オプションを選択します。

4. 「OK」をクリックします。

「地域の選択を有効にする」オプションを選択すると、登録された言語ごとに該当するロケールが表示されます。ロケールは、図5-3に示すように、「言語の設定」ポートレット内で言語の後に表示されます。

図5-3 「言語の設定」ポートレット

注意:

Oracle Help for the Webを使用する、Oracle Portalのオンライン・ヘルプでは、異なる言語でオンライン・ヘルプのユーザー・インタフェースを表示するため、特定のフォントに依存します。適切なフォントをインストールするには、中間層サーバーのインストール時にオンライン・ヘルプの表示に使用する言語をすべて選択する必要があります。このためには、インストール時に「製品の言語」ボタンをクリックし、「インストールする製品の選択」画面で使用する言語を選択します。

また、中間層にインストールされる言語とインフラストラクチャ層にインストールされる言語が一致することを確認して、「言語の設定」リクエストがOracleAS Single Sign-Onに対して発行されたときに問題が発生しないようにする必要があります。

すべての言語をインストールすると、中間層のインストールに要する時間が長くなります。

5.11 Oracle Portal WebDAVの構成

WebDAVは、HTTP 1.1のプロトコル拡張で、分散オーサリングおよびバージョン管理をサポートします。WebDAVを使用すると、インターネットを透過的な読込みおよび書込みメディアとして利用することができます。つまり、URLアドレスに基づいて、コンテンツをチェックアウトし、編集してからチェックインすることができます。mod_davは、WebDAV仕様の実装です。標準のmod_dav実装は、ファイルの読込みおよび書込みアクセスをサポートします。

OraDAVとは、mod_oradavモジュールを使用して利用できる機能のことです。mod_oradavモジュールは、Oracleモジュールの1つです。mod_davの拡張実装として、Oracle HTTP Serverに組み込まれています。mod_oradavモジュールは、ローカル・ファイルおよびOracle Databaseの読取りと書込みを実行できます。Oracle Databaseには、OraDAVドライバがインストールされている必要があります。OraDAVドライバは、Oracle Portalのインストール時にデフォルトでインストールされます。mod_oradavモジュールはOraDAVドライバをコールして、WebDAV動作をデータベース動作にマップします。この結果、WebDAVクライアントは、Oracle Databaseに接続し、コンテンツの読取りと書込みを行い、様々なスキーマのドキュメントを問い合せたりロックしたりできるようになります。

関連項目:

Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

Oracle Fusion Middlewareのインストール時に、WebブラウザまたはWebDAVクライアントからOracle Databaseのコンテンツにアクセスできるように、必要なすべてのOraDAVパラメータに対して値が設定されます。デフォルト値が適切でない場合は、必要に応じてパラメータ値を変更できます。

ポータルのDAD構成ファイルと同様、WebDAVには独自の構成ファイル(INSTANCE_HOME/config/OHS/ohs1/moduleconf/mod_oradav.conf)があります。このファイルには、DAVおよびDAVParamで始まるOraDAVパラメータが格納されています。これらのパラメータは<Location>ディレクティブ内で指定されます。ファイルoradav.confは、httpd.confファイルに組み込まれます。

関連項目:

Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド

5.11.1 基本的なWebDAV構成の実行

Oracle Portalは、Oracle Fusion Middlewareとともにインストールされます。インストールが完了したら、ポータル・スキーマを指定する<Location>ディレクティブをmod_oradav.confファイルに移入する必要があります。例5-11では、/dav_portal/portalでOraDAVが有効になり、このディレクトリからポータル・スキーマに接続されます。その結果、WebDAVクライアントを使用してポータル・データにアクセスできるようになります(正しい値が設定された場合)。

例5-11 ポータル・アクセスのパラメータの構成

<Location /dav_portal/portal>
DAV Oracle
DAVDepthInfinity On
DAVParam ORACONNECTSN
<dbhost:dbport:dbservicename>
DAVParam ORAUSER <portal schema name>
DAVParam ORACRYPTPASSWORD <portal schema crypted password>
DAVParam ORACONTAINERNAME wwdav
DAVParam ORAPACKAGENAME
<portal_schema>.wwdav_api_driver   DAVParam ORAException RAISE
DAVParam ORATraceLevel 0   DAVParam ORACookieMaxAge 28800   Options Indexes
</Location>

デフォルトでは、Oracle Portal DAV URLは次のようになります。

http://<host>:<port>/dav_portal/portal/

例:

http://mysite.oracle.com:8090/dav_portal/portal

URLのdav_portal部分は、WebDAVクライアントを介したポータル・アクセスとpls仮想ディレクトリを使用するポータル・アクセスを区別するために使用される、仮想ディレクトリのデフォルト名です。portalは、ポータル・インストールのDADです。必要に応じ、仮想ホストを構成してWebDAVアクセスに別の簡単な覚えやすいURLを指定することもできます。

ポータルへのログインに使用するのと同じユーザー名とパスワードで、WebDAVクライアントのポータルに接続できます。ポータルがホストされた環境にある場合、ユーザーは次のようにユーザー名に会社情報も追加する必要があります。

<username>@<company>

認証

WebDAVクライアントによっては、ユーザーに認証を複数回リクエストすることがあります。これを回避するために、ポータル管理者は、oradav.confファイルに次の行を追加してCookieオプションを有効にできます。

DAVParam ORACookieMaxAge <seconds>

secondsは、Cookieの有効期限(秒)です。

たとえば、値が28800の場合は8時間になり、一度ユーザーがWebDAVクライアントを介してログインすると、8時間が経過するまで、クライアント・ツールはユーザー名とパスワードを送信しません。多くのWebDAVクライアント(Oracle Drive、WebFolders、Cadaverなど)では、ユーザーが初めて接続するときに入力したユーザー名とパスワードの値を保持しており、それらの値を使用して新しいCookieを作成するので、その時間が経過してもユーザーがユーザー名やパスワードの入力を求められることはありません。

注意:

Dreamweaverなど、一部のWebDAVクライアントでは、Cookieがサポートされていません。そのため、Cookieオプションを有効にしても、ユーザーはパスワードを複数回求められることがあります。

SQL*Net Advanced Security Option (ASO)を使用している場合は、次に示すようにmod_oradav.confファイルのパラメータORACONNECTをORASERVICE dbhostに置き換える必要があります。

<Location /dav_portal/portal>
DAV Oracle
DAVParam ORASERVICE dbhost
DAVParam ORAUSER portal_schema
DAVParam ORAPASSWORD portal_schema_password
DAVParam ORAPACKAGENAME portal_schema.wwdav_api_driver
Options Indexes
</Location>

これにより、tnsnames.oraファイルでデータベース別名を解決できるようになります。

注意:

- 新規のDADを追加するときにユーザー名とパスワードを指定しない場合、またはSQL*Plusを使用してポータル・データベース・スキーマのユーザー名およびパスワードを変更する場合は、portal_dads.confとmod_oradav.confのファイルを手動で更新する必要があります。

- portal_dads.confやmod_oradav.confに変更を加えたときは、必ずOracle HTTP Serverと管理対象サーバー(WLS_Portal)を再起動して新しい設定を有効にする必要があります。

デフォルトのファイル・ロックの時間制限

新しいDEFAULTLOCKTIMEOUTパラメータは、DAVクライアントによってロックが作成され、クライアントがそのロックを能動的に維持しない場合に持続する、単一ロックの合計時間に関する情報を提供します。このパラメータはオプションです。この値を変更すると、ロックのデフォルトの有効期限を定義できます。

mod_oradav.confファイルでは、パラメータDEFAULTLOCKTIMEOUTを次の形式で使用できます。

DAVParam DEFAULTLOCKTIMEOUT 86400

このパラメータは秒単位で指定します。構成ファイルにこのパラメータが指定されていない場合は、Oracle Portalによって1日(86400秒)で期限切れになるロックが作成されます。

ロックの指定時間を過ぎると、そのロックに関連した一時ドキュメントが削除されます。これは予期された動作です。例:

- ドキュメントの更新中にMicrosoft Wordがクラッシュした場合、ロック時間を過ぎるとドキュメントへの変更は失われます。

- LOCK、PUT、PUTなどの操作を実行してUNLOCKを指定せずにクライアントを終了すると、ロック時間を過ぎている場合は、PUTされたすべてのデータが失われます。

5.11.2 WebDAVクライアントの設定

WebDAVクライアントをOracle Portalに接続するための設定に必要な手順はクライアントによって異なります。すべてのクライアントは最終的にURLをリクエストします。Portal DAV URLは、Webブラウザでポータルにアクセスするときに使用するURLとよく似ており、次の書式を使用しています。

http://<host>:<port>/<dav_location>

5.11.3 WebDAVクライアントとSSL

OraDAVではSSL (Secure Socket Layer)がサポートされていますが、一部のWebDAVクライアントではサポートされていません。詳細は、WebDAVクライアントのドキュメントを参照してください。

5.11.4 OraDAVドライバのバージョンの確認

次の例に示すように、OraDAVドライバのバージョンをWebブラウザで確認できます。

http://<computer>:<port>/<dav location>/~OraDAV-Version

次の例のように出力されます。

Version 1.0.3.2.3-0030
Using Container Version 1.5

5.11.5 OraDAVドライバのバージョンの確認

oraDAVのバージョンは、http://host:portal/dav_portal/portalのdav_portalに移動することによってチェックできます。DavポータルのURLではバージョンがoraDavポータル・ドライバ名(バージョン番号)の形式で表示されます。

5.11.6 エラーの表示

ユーザーがWebDAVクライアントを使用してポータルで操作を実行するときに発生したエラーは、エラー・ログに記録されます。このエラー・ログは、Oracle Portal関連のWebDAVエラーが初めて発生したときに、ユーザーの個人用ページに、「エラー・ログ」というアイテムとして作成されます。これは、Webフォルダで表示される、操作の実行中にエラーが発生したというエラー・メッセージや、Cadaverで報告されるHTTPエラー番号など、WebDAVクライアントで報告されるエラー・メッセージの解釈に非常に役立ちます。

エラーはすべて、Apacheのエラー・ログ・ファイル(ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1)にも記録されるので、ユーザーが個人用ページを持っていない場合またはパブリック・ユーザーである場合でもエラーを調査できます。

mod_oradav.confファイルのパラメータOraTraceEventsを指定することで、エージェント、ユーザー、ECID、URL、メソッドなどのエラーに関する情報がApacheエラー・ログ・ファイルに記録されるようになります。この情報は、ポータル管理者やオラクル社カスタマ・サポート・センターがエラーを解決する際に役立ちます。mod_oradav.confファイルでは、パラメータOraTraceEventsを次の形式で使用できます。

DAVParam OraTraceEvents agent

Apacheのエラー・ログ・ファイルには、次の例のような形式で情報が記録されます。

[Wed Sep 22 10:38:46 2004] [notice] OraDAV: Agent [Secret-Agent-Man] User
[Hanckel] ECID [Viscous] URI [/orddav_var2/images/var2] Method [MKCOL].

Apacheのエラー・ログ・ファイルで、より詳細なエラー報告を利用するには、oradav.confファイルに次のパラメータを追加します。

DAVParam ORATraceLevel 1

注意:

- mod_oradav.confファイルを変更したときは必ずOracle HTTP Serverを再起動する必要があります。この実行方法の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。
また、他のOraDAVパラメータの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOraDAVの構成パラメータに関する項を参照してください。

- エラー・ログは切り捨てられず、非常に大きいファイルになる可能性があります。このファイルは定期的に削除することをお薦めします。次回エラーが発生したときに、新しいファイルが作成されます。

- クライアント・コンピュータはファイル名が存在するかどうかを確認するため、「見つかりません」というメッセージがエラー・ログに表示されることがあります。ファイルが存在しない場合は、エラー・ログに正しく404エラー・メッセージが表示されます。

5.12 リソース・プロキシの構成

JPDKリソース・プロキシを使用してポータルとプロバイダ間で共有可能なキーを選択する場合は、resourceURLKeyパラメータを構成する必要があります。このキーは、WSRPリソースおよびJPDKリソースのプロキシ処理によってリクエストされたURLに対して、Parallel Page Engineがチェックサムを計算するために使用されます。WSRPリソースのプロキシ処理を機能させるには、キーの値に10文字以上の英数字を設定する必要があります。製品に付属しているWSRPサンプルは、リソース・プロキシを使用します。このため、リソース・プロキシが正しく構成されないと、WSRPポートレットにイメージを表示できなくなります。また、JPDKのプロキシ処理では、JNDI環境変数(resourceUrlKeyとも呼ばれる)をプロバイダ用に設定する必要があります。詳細は、第5.6.9項「PortalのParallel Page Engineの構成」を参照してください。

WSRPリソース・プロキシを構成するには、次の手順を実行します。

1. WLSTコマンドconfigurePortalPageEngineを使用して、パラメータresource_url_keyに10文字以上の英数字の値を設定します。

注意:

リソースURLキーは、Fusion Middleware Controlで「ポータル」メニューから「設定」→「ページ・エンジン」を選択して設定できます。

2. WLS_PORTALを再起動します。

第III部

拡張構成

第3部には次の章が含まれます:

- 第6章「拡張構成」

- 第7章「Oracle Portalの保護」

- 第8章「Oracle Portalの監視と管理」

- 第10章「Oracle Portalの検索機能の構成」

- 第11章「Oracle Portalのパフォーマンスの調整」

- 第12章「コンテンツのエクスポートとインポート」

- 第13章「連携型Portalアダプタの使用」

6 拡張構成

この章では、拡張構成の実現に必要な構成について説明します。このような構成を実行するには、第5.1項「Oracle Portalの管理のスタート・ガイド」に記載された管理ツールに精通している必要があります。

この章の内容:

- Oracle Fusion Middlewareリスニング・ポートの変更

- SSLの構成

- ロード・バランシング・ルーターを使用する複数の中間層の構成

- 仮想ホストの構成

- プロキシ・サーバーを使用するためのOracle Portalの構成

- リバース・プロキシ・サーバーを使用するためのOracle Portalの構成

- Oracle Web CacheにキャッシュされたOracle Portalコンテンツの管理

- 専用のOracle Web Cacheインスタンスを使用するためのOracle Portalの構成

- インストール後のクラスタ環境の構成

- OracleAS Wirelessの構成

- Oracle Portalスキーマのパスワードの変更

- WLSTを使用したOracle Portalの構成

6.1 Oracle Fusion Middlewareリスニング・ポートの変更

Oracle Fusion Middlewareリスニング・ポート内のポートを変更する方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

関連項目:

第8.4項「Oracle Fusion Middlewareポート情報の表示」

6.2 SSLの構成

Oracle Portalでは、多くの様々なコンポーネント(Parallel Page Engine、Oracle HTTP Server、Oracle Web Cacheなど)を使用しますが、それらの各コンポーネントはHTTP通信でクライアントまたはサーバーの役目を果たすことがあります。このため、Oracle Portalの中間層にある各コンポーネントを、HTTPではなくHTTPSプロトコルやSecure Sockets Layer (SSL)を使用するように個別に構成する必要があります。

第7章「Oracle Portalの保護」では、次の各項でOracle Portalで使用できるSSL構成オプションについて説明しています。

- 第7.3.2.1.2項「OracleAS Single Sign-OnとのSSL接続」

- 第7.3.2.1.4項「Oracle Web CacheとのSSL接続」

- 第7.3.2.1.5項「Oracle PortalのエンドツーエンドSSL」

- 第7.3.2.1.6項「Oracle Fusion Middleware内では非SSLの外部SSL」

- 第7.3.2.1.7項「Oracle WebLogic管理対象サーバーのSSLの構成」

- 第7.3.2.1.8項「SSLを介して公開されるWebプロバイダ、プロバイダ・グループおよびWSRPプロデューサの構成と登録」

6.3 ロード・バランシング・ルーターを使用する複数の中間層の構成

この項では、同じOracle Metadata Repositoryにアクセスするためにフロントエンドとしてロード・バランシング・ルーター(LBR)が設定された複数の中間層環境で、Oracle Portalを設定する方法を説明します。

注意:

そのままですぐに使用できるすべてのポータル・インストールと同様、このソリューションはSSLを使用するように構成されていないため内部デプロイメントには最適です。推奨されるセキュアなエンタープライズ・デプロイメントの構成方法については、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

LBRの目的は、クライアント層に公開アドレスを1つだけ提供し、LBRによって行われるリクエストの配信に基づいて、実際にリクエストを処理するサーバーのファームをフロントエンドに設定することです。LBRそのものは、非常に高速のネットワーク・デバイスであり、Webリクエストを膨大な数の物理サーバーに配信できます。

ここで、図6-1に示すような複数の中間層構成を構成すると想定します。この例では、Oracle Portalの中間層として、同じコンピュータ上にOracle Web Cacheが示されています。理論的には、これらは別のコンピュータ上にあってもかまいません。

図6-1 ロード・バランシング・ルーターを使用する複数の中間層の構成

表6-1 詳細情報

コンピュータ

詳細

ロード・バランシング・ルーター(LBR)

コンピュータ名: lbr.abc.com

IPアドレス: L1.L1.L1.L1

リスニング・ポート: 80

無効化用ポート: 4001(内部からのみアクセス可能)

Portal中間層1(M1)

コンピュータ名: m1.abc.com

IPアドレス: M1.M1.M1.M1

Oracle HTTP Serverリスニング・ポート: 8888

Oracle Web Cacheリスニング・ポート: 8090

Oracle Web Cache無効化用ポート: 4001

Web Cache管理用ポート: 4002

Oracle Portal管理対象サーバー(WLS_PORTAL): 9001

Portal中間層2(M2)

コンピュータ名: m2.abc.com

IPアドレス: M2.M2.M2.M2

Oracle HTTP Serverリスニング・ポート: 8888

Oracle Web Cacheリスニング・ポート: 8090

Oracle Web Cache無効化用ポート: 4001

Oracle Portal管理対象サーバー(WLS_PORTAL): 9001

注意

- この項で使用されている名前とポートは説明用の仮の値であり、実際の環境に合せて置き換える必要があります。

- 特定のOracle Portalインスタンスのコンポーネントで現在使用されているポートの一覧を表示するには、第8.4項「Oracle Fusion Middlewareポート情報の表示」で説明している手順を参照してください。

正常な処理に必要なLBRの追加構成は次のとおりです。

- ループバック通信

- Oracle Web Cacheの無効化

ループバック通信

Oracle PortalのParallel Page Engine (PPE)は、ページ・メタデータの情報を取得します。この通信は、ループバック接続と呼ばれます。デフォルトの構成では、Oracle Web CacheとOracle Portalは同じコンピュータ上にあり、ループバック接続はローカルです。

LBRが Oracle Fusion Middlewareのフロントエンドに設定されており、Oracle Web Cacheが同じサブネット上にある場合は、追加構成が必要となります。このことをよく理解するために、この追加構成がないループバック接続の様々な部分を確認します。

1. Oracle Portalでページが生成されると、PPEはページ・メタデータのループバック・リクエストを送信します。このループバック・リクエストは、LBRに直接送信されます。

2. このリクエストがLBRによってOracle Web Cacheに転送されます。

3. Oracle Web Cacheは、リクエストをOracle HTTP Server下で稼働中のPortalサービスに転送します。

4. Portalサービスがリクエストを処理し、ループバック・リクエストのレスポンスをOracle Web Cacheに返信します。

5. Oracle Web Cacheは、リクエストをLBRに転送します。

6. LBRがレスポンスを受信します。このレスポンスは通常PPEに送り返されます。

7. LBRは、レスポンスを返信する必要があるソース・アドレスが同じサブネット上にあることを検出し、PPEのソケット接続ではなくLBRに既知のソケット接続を使用して、レスポンスをOracle Web Cacheに返信します。

8. Oracle Web Cacheはリクエストをまったくリスニングしておらず、有効なセッションがないため着信リプライは削除されます。

9. 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を設定し、データ層上で適切なアウトバウンド・ポートを開く必要もあります。この設定に必要な手順については、後で説明します。

注意:

- Oracle Web Cache無効化の完了後、Oracle Portalリポジトリでもパスワードが更新されていることを確認します。

- 図6-1に示すように、インフラストラクチャはLBRの内側にあります。インフラストラクチャは、1台のホスト上に構成することも、複数のホストに分散させることも可能です。インフラストラクチャを適切に構成するには、『Oracle Application Server Single Sign-On管理者ガイド』の拡張構成に関する情報を参照してください。

LBRをフロントエンドに設定した複数の中間層環境でOracle Portalを構成するには、次の手順を実行します。

- ステップ1: 単一のPortal中間層(M1)のインストール

- ステップ2: LBRを通じてアクセスされるM1でのOracle Portalの構成

- ステップ3: Oracle Portalが起動し実行中であることの確認

- ステップ4: 新しいポータル(M2)のインストール

- ステップ5: 既存のポータルを実行するための新しい中間層(M2)の構成

- ステップ6: PortalツールとWebプロバイダの構成(オプション)

- ステップ7: Oracle Web Cacheでのセッション・バインドの有効化

- ステップ8: 構成完了の確認

6.3.1 ステップ1: 単一のPortal中間層(M1)のインストール

単一のPortal中間層をインストールし、インストールを確認します。これを行うには、次の手順を実行します。

1. 『Oracle Fusion Middleware Oracle Portal, Forms, Reports and Discovererインストレーション・ガイド』に説明されている手順を使用して、1台目のコンピュータ(M1)にPortal中間層をインストールします。ここでは、既存のOracle Fusion Middleware Infrastructureのサービスを使用することを前提としています。

関連項目:

Oracle Fusion Middlewareインストレーション・プランニング・ガイド

2. 次の場所にあるOracle Portalホーム・ページにアクセスできることを確認して、中間層が正常にインストールされていることを確認します。

http://m1.abc.com:8090/portal/pls/portal

設定した構成は図6-2のようになります。詳細は表6-1に示されています。

図6-2 Oracle Portal中間層のインストール

ここで、LBRを通じてアクセスされるOracle Portalを構成するために、次の手順に進みます。

6.3.2 ステップ2: LBRを通じてアクセスされるM1でのOracle Portalの構成

ロード・バランシング・ルーター(LBR)を通じてアクセスされるようにOracle Portalを構成するには、次の手順を実行します。

1. ポート80でリクエストを受け取り、これらのリクエストをコンピュータ(m1.abc.com)で実行中のOracle Web Cacheのポート8090へ転送するように、LBR (lbr.abc.com)を構成します。そのためには、次の手順を実行します。

1. 個々のサーバーを追加できるグループ(プール)をLBR上に設定します。

2. 必要なサーバーのIPアドレスとポート番号をグループに追加します。

3. ポート80でリスニングを行い、グループのメンバー間で負荷を均衡させる仮想サーバーを作成します。

4. LBRが、リクエストを転送するためにリスニングするポートをOracle Web Cacheがリスニングしているポートへ変換することを確認します。

注意:

グループと仮想サーバーを設定するには、LBRのドキュメントを参照してください。

2. 基盤となるコンポーネントが、LBRのホスト名(lbr.abc.com)とLBRのポート番号(80)に基づくURLを作成できるように、M1でOracle Portal中間層を構成して、Oracle Portalページに描画される自己参照型URLがブラウザで有効になるようにします。これを行うには、次の手順を実行します:

1. 第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して仮想ホストを定義し、仮想ホストの「サーバー名」フィールドにLBR (lbr.abc.com:80)のホスト名を指定します。

2. 第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して2番目の仮想ホストを定義します。ただし、次の変更点があります。

- 仮想ホストの「サーバー名」フィールドに、M1 (m1.abc.com:8090)のホスト名を指定します。

- Oracle HTTP Serverを再起動します。

3. 仮想ホストの構成後、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を再起動します。

3. M1でOracle Fusion Middleware Controlを使用して、前述の手順で作成した仮想ホスト・エントリ(lbr.abc.com)に対応させるサイトを次のように定義します。

1. 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、M1でOracle Enterprise Manager 11g Fusion Middleware ControlのWeb Cacheホーム・ページに移動します。

2. Web Cacheのメニューから、「管理」→「サイト」を選択します。
「サイト」ページが表示されます。

3. 「サイト」で「作成」をクリックします。

4. 「サイトの作成」ページで、「ホスト」にlbr.abc.com、「ポート」に80を指定します。

5. 「デフォルト・サイト」および「圧縮」を選択します。

6. 「URL接頭辞」は、空白のままにします。

7. 「OK」をクリックします。「サイト」表にlbr.abc.comが表示されます。

8. 「サイト」表からlbr.abc.comを選択して、「編集」をクリックします。

9. 「別名」セクションで「作成」をクリックして新しい別名を作成し、次の情報を入力します。
ホスト名: m1.abc.com

ポート: 8090

10. 「OK」をクリックします。

11. 「適用」をクリックします。

4. M1でOracle Enterprise Manager 11g Fusion Middleware Controlを使用して、サイトlbr.abc.comを中間層m1.abc.comにマップします。

1. 「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。

2. 「サイト・サーバー間マッピング」セクションで、次の情報を入力します。
ホスト・パターン: lbr.abc.com

ポート・パターン: 80

「接頭辞」フィールドは、空白のままにします。

3. 「オリジン・サーバー」セクションで、「すべてのオリジン・サーバー」からm1.abc.com:8888を選択し、それを「選択したオリジン・サーバー」に移動します。

4. 「OK」をクリックします。

5. 「適用」をクリックします。

6. 「サイト」表からm1.abc.comを選択して「削除」をクリックし、未使用のサイトを削除します。

7. 「サイト・サーバー間マッピング」表で「削除」をクリックして、未使用のサイトを削除します。

8. Oracle Enterprise Manager 11gのWeb Cacheホーム・ページで「制御」→「再起動」を選択して、Oracle Web Cacheを再起動します。

サイトが正しくマップされたことを確認するために、「Site-to-Server Mapping」ページに移動して、M1がサイトのlbr.abc.comにマップされているかどうかを調べます。

5. m1.abc.comのコンピュータを構成して、LBRのホスト名が解決されて正しいIPアドレスが設定されるようにします。DNSの解決に委ねることも、次のようなエントリを/etc/hostsファイル内に作成することもできます。

L1.L1.L1.L1  lbr.abc.com

ここでのL1.L1.L1.L1は、LBRのIPアドレスです。これらの変更を行った後にシステムを再起動する必要はありません。

警告

/etc/hostsファイルにはローカル・ホスト名が127.0.0.1を指し示すエントリがないことを確認してください。例:

127.0.0.1 m1.abc.com

6. m1.abc.comで実行中のPPEから流入するループバック・リクエストに対して、LBRがNATバウンス・バックを実行するように構成します。このように構成しておくと、PPEがOracle Web Cacheへループバック・リクエストを行うときに、エラーがないことが保証されます。

注意:

- NATバウンス・バックは、個々のLBRで様々に設定されます。この設定方法は、使用するLBRの構成ガイドを参照してください。

- ログ・ファイルには、PPE (Parallel Page Engine)からのすべてのループバック・リクエストのためのNATバウンス・バック・アドレスが含まれます。これらのアドレスによって、LBRを介してOracle Web CacheまたはOracle HTTP Serverへリクエストが転送されます。

7. 独立したポート(この例では4001)上のOracle Metadata Repositoryから無効化リクエストを受け取って、ポート4001のコンピュータm1.abc.comで実行中のOracle Web Cacheへそのリクエストが転送されるように、LBR (lbr.abc.com)を構成します。

注意:

LBRは、Oracle Web Cacheの無効化ポートをリスニングする必要はありません。ポート・マッピング機能がないLBRの場合は、ポート番号がOracle Web Cache無効化ポートと一致している必要があります。

1. 個々のサーバーを追加できるグループ(プール)をLBR上に設定します。

2. 必要なサーバーのIPアドレスとポート番号をグループに追加します。

3. ポート4001でリスニングを行い、グループのメンバー間で負荷を均衡させる仮想サーバーを作成します。

4. LBRのポートが無効化リクエストをリスニングしており、Oracle Web Cacheの無効化用ポートと異なる場合、Oracle Web Cacheがリスニングしているポートへリクエストを転送するために、LBRでリスニングしているポートを変換する必要があります。

注意:

- グループと仮想サーバーを設定するには、LBRのドキュメントを参照してください。

- Oracle Fusion Middleware Infrastructureが別のファイアウォールの内側にある場合は、そこからLBRへ無効化メッセージを送信できることを確認する必要があります。

- Oracle Portal Metadata Repository Databaseが別のファイアウォールの内側にある場合は、データベース・マシンがプロバイダ登録URLを使用してWebプロバイダにアクセスできることを確認します。

警告

セキュリティ上の理由から、LBRの無効化用ポート(ポート4001)はネットワーク内からのみアクセスできるようにしておくことが必要です。

8. Portalの中間層を次のように構成します。

1. Enterprise ManagerでPortalホーム・ページに移動します。

2. 「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。

3. 「ポータル・ワイヤ構成」ページの「ポータル中間層」セクションに、次の情報を入力します。

- 公開ホスト: lbr.abc.com

- リスニング・ポート: 80

4. 「ポータル・ワイヤ構成」ページの「Oracle Web Cache」セクションで、「ホスト」にlbr.abc.com、「無効化ポート」に8093と入力します。

5. 「適用」をクリックします。

6. 管理対象サーバーを再起動します。

9. Oracle WebLogic Server管理コンソールで、lbr.abc.comのHTTP設定を次のように構成する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. コンソールの左側のペインで、「環境」を開いて「クラスタ」を選択します。

4. クラスタ・サーバーを選択してから「HTTP」タブを選択します。

5. 「HTTP」ページで、次の情報を入力します。

- フロントエンド・ホスト: lbr.abc.com

- フロントエンドHTTPポート: 80

6. 「保存」をクリックします。

7. 「変更のアクティブ化」をクリックします。

8. 管理対象サーバーを再起動します。

10. 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の登録に関する項を参照してください。

11. ORACLE_INSTANCE/config/OHS/ohs1にあるosso.confのバックアップを作成します。

12. osso.confファイルをORACLE_INSTANCE/config/OHS/ohs1ディレクトリにコピーします。

13. Oracle HTTP Serverを再起動します。

これらの手順の終了後は、設定した構成は図6-3のようになります。詳細は表6-1に示されています。

図6-3 Oracle PortalがLBRを通じてアクセスされている

6.3.3 ステップ3: Oracle Portalが起動し実行中であることの確認

次のテストを指定された順序で実行して、Oracle Portalが起動し、実行中であることを確認します。1つのテストに失敗した場合は、問題点の処置を行ってから次のテストに進んでください。Oracle Web Cache、Oracle HTTP ServerおよびLBRの構成とログを診断するには、『Oracle Fusion Middleware管理者ガイド』を参照してください。

1. Oracle Web Cacheにキャッシュされた静的ファイルにアクセスすることにより、Oracle Web CacheおよびOracle HTTP ServerにLBRを通じてアクセスできることをテストし、正常に機能することを確認します。たとえば、次のURLにアクセスできます。

http://lbr.abc.com:port/index.html

2. 次の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ファイルでリクエストの失敗に関する詳細を調べ、適切な処理を行います。

3. 次の手順を実行することにより、Oracle Portalにアクセスできることをテストします。

1. 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

2. Oracle Portalホーム・ページにアクセス時に、XML解析エラーが発生することがあります。その場合は、診断ログを確認してください。エラーの原因の1つとして、Oracle Web CacheとOracle Portal間のWebCache無効化パスワードの不一致があげられます。両者の設定を調べて、パスワードが一致することを確認します。

3. ポータルのログイン・リンクをクリックします。これが機能しない場合は、mod_ossoで簡略化したシングル・サインオン先である仮想ホストを登録するためにssoregを実行した際の手順を確認します。DOMAIN_HOME\servers\WLS_PORTAL\logsにある、WLS_PORTALインスタンスのWLS_PORTAL-diagnostic.logファイルで詳細を調べます。

4. ポータルのリンクをいくつかクリックしてみます。

5. コンテンツがOracle Web Cacheにキャッシュされていることを確認します。
Oracle Enterprise ManagerのWeb Cacheのメニューから、「監視」→「ポピュラーなリクエスト」を選択します。「ポピュラーなリクエストの表示」ドロップダウン・リストから「キャッシュされたポピュラーなリクエスト」を選択します。「キャッシュされたポピュラーなリクエスト」で「実行」をクリックし、ページのコンテンツを更新します。Oracle Portalにアクセスできた場合は、ポータルのコンテンツが表示されます(_esiReqType=2、wwpob_smd.has_previlegeおよびwwv_setting.render_cssなどの文字列を含むURL)。ポータルのコンテンツが何も表示されない場合は、別のブラウザを開き、Oracle Portalにログインします。「キャッシュされたポピュラーなリクエスト」ページに戻り、「実行」をクリックしてページのコンテンツを更新します。これで、検証用には十分なコンテンツが提供されます。

6. Oracle Portalで、ポートレットをページに追加するなどの基本的なページ編集を行って、新しいコンテンツが表示されることを確認します。新しいコンテンツが正しく表示されない場合やエラーが発生する場合は、Oracle Web Cacheの無効化の構成に誤りがあります。

6.3.4 ステップ4: 新しいポータル(M2)のインストール

M2 (m2.abc.com)上で新しいポータル中間層をインストールするには、次の手順を実行します。

注意:

Oracle Portalのインストールを続行する前に、WebLogic Serverがインストールされていることを確認してください。Oracle WebLogic Serverインストレーション・ガイドを参照してください。WebLogic ServerをインストールするとMiddlewareホームが作成されます。Middlewareホームは、すべてのOracle Fusion Middlewareコンポーネントのインストールに使用されます。

1. Oracle Universal Installerを実行して、Portal中間層を2番目のコンピュータ(M2)にインストールします。

2. Oracle Fusion Middleware中間層のインストール中に「インストール・タイプの選択」画面で「ソフトウェアのインストールおよび構成」オプションを選択して、「次へ」をクリックします。

3. 「前提条件のチェック」画面で「次へ」をクリックして続行します。

4. ドメインの選択画面で「クラスタを開く」を選択して、次の情報を入力します。

- ホスト: m1.abc.comを入力します。

- ポート: WebLogic管理ポート番号(デフォルト: 7001)を入力します。

- ユーザー名: WebLogic管理サーバーのユーザー名を入力します。

- ユーザー・パスワード: WebLogic管理サーバーのパスワードを入力します。

5. 「セキュリティ更新用の電子メールの指定」画面に情報を入力し、「次へ」をクリックして続行します。

6. Middlewareホーム、Oracleホーム、Oracleインスタンスの場所およびOracleインスタンス名を「インストール場所の指定」画面で指定し、次へ」をクリックして続行します。

注意:

2番目の中間層のインストールに同じ物理パスを使用することをお薦めします。このようにしておくと、1つのコンピュータで構成の変更を行い、その変更内容を別のコンピュータへ転送するときに役立ちます。物理パスが他のコンピュータと異なると、ファイルのコピー後にパスの要素が正しいかどうかの確認を行う必要が生じます。

7. 「コンポーネントの構成」画面でM1に選択したコンポーネントを選択し、「次へ」をクリックします。

8. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、click 「参照」をクリックしてM1で使用されるstaticports.iniファイルを選択します。
M1をインストールするときにこのファイルを保存していない場合、このファイルは存在しません。このシナリオでは、ファイルの表示/編集をクリックして、次のようにファイルを編集します。

Domain Port No = 7001
[OHS]
Oracle HTTP Server Port No = 8888
[WEBCACHE]
Oracle WebCache Port No = 8090
Oracle WebCache Invalidation Port No = 4001
[MANAGEDSERVER]
Oracle WLS Portal Managed Server Port No = 9001

注意:

ポートの値は、MIと同じである必要があります。

9. アプリケーションOIDの指定画面でOracle Internet Directoryサーバーの詳細を入力して、「次へ」をクリックします。

10. 「インストール・サマリー」画面で情報を確認して、「インストール」をクリックします。

関連項目:

Oracle Fusion Middlewareインストレーション・プランニング・ガイド

この新しいインストールが以前の構成に影響を与えることはありません。Oracle PortalがM1上で起動されて実行中であり、LBRを通じてアクセスできることを確認します。確認方法の詳細は、第6.3.3項「ステップ3: Oracle Portalが起動し実行中であることの確認」を参照してください。

6.3.5 ステップ5: 既存のポータルを実行するための新しい中間層(M2)の構成

既存のポータルを実行するには、次の手順をこの順序で実行してM2を構成します。

1. 中間層M1から中間層M2へ、Oracle Portalの構成設定値をコピーします。まずファイルのバックアップ・コピーを作成することをお薦めします。これを行うには、次のファイルをコピーします:

- appConfig.xml

- portal_cache.conf

- portal_dads.conf

- portal_plsql.conf

M1のDOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configurationからM2の同じパスにコピーします。

M1とM2が異なる物理パスを使用してインストールされている場合は、ファイルのコピー後にパスの要素が正しいかどうかを確認する必要があります。

2. 基盤となるコンポーネントが、ロード・バランシング・ルーター(LBR)のホスト名(lbr.abc.com)とLBRのポート番号(80)に基づくURLを作成できるように、新しいOracle Portal中間層を構成します。これを行うには、M2上でFusion Middleware Controlを使用して、次の手順を実行します。

1. 第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して仮想ホストを定義します。ただし、次の変更点があります。

- 「新規リスニング・アドレス」オプションを選択して、lbr.abc.com:80と入力します。

- 仮想ホストの「サーバー名」フィールドに、LBR (lbr.abc.com)のホスト名を指定します。

2. 第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して2番目の仮想ホストを定義します。ただし、次の変更点があります。

- 「新規リスニング・アドレス」オプションを選択して、m2.abc.com:8090と入力します。

- 仮想ホストの「サーバー名」フィールドに、M2 (m2.abc.com)のホスト名を指定します。

- Oracle HTTP Serverを再起動します。

3. 仮想ホストの構成後、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を再起動します。

3. mod_oradav.conf、mod_osso.conf、plsql.confおよびportal.confをM1のORACLE_INSTANCE\config\OHS\ohs1\moduleconfからM2にコピーします。

4. ORACLE_INSTANCE\config\OHS\ohs1\osso.confをM1からM2にコピーします。

5. 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>

6. 次のコマンドを使用してOracle HTTP Serverを再起動します。

ORACLE_INSTANCE\bin\opmnctl stopall
ORACLE_INSTANCE\bin\opmnctl startall

7. m2.abc.comのコンピュータを構成して、LBRのホスト名が解決されて正しいIPアドレスが設定されるようにします。DNSの解決に委ねることも、次のようなエントリを/etc/hostsファイル内に作成することもできます。

L1.L1.L1.L1  lbr.abc.com

警告

/etc/hostsファイルにはローカル・ホスト名が127.0.0.1を指し示すエントリがないことを確認してください。例:

127.0.0.1 m2.abc.com

8. 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』で説明しているように、M1上でOracle Web Cache Managerにアクセスします。

9. M1でOracle Enterprise Manager 11gを使用して、M2を追加のオリジン・サーバーとしてOracle Web Cacheに追加します。これを行うには、次の手順を実行します:

1. Oracle Enterprise Manager 11gで、M1のWeb Cacheホーム・ページに移動します。

2. Web Cacheのメニューから、「管理」→「オリジン・サーバー」を選択します。
「オリジン・サーバー」ページが表示されます。

3. 「作成」をクリックします。
「オリジン・サーバーの作成」ページが表示されます。

4. オリジン・サーバー・ページの表示の作成ページで、次の情報を指定します。

プロパティ

値

ホスト

m2.abc.com

ポート

8888

容量

100

プロトコル

HTTP

有効ルーティング

ENABLED

フェイルオーバーのしきい値

5

URLのping

/

pingの間隔(秒)

10

注意:

「ポート」の値には、M2のOracle HTTP Serverリスニング・ポートを指定します。

5. 「OK」をクリックします。

6. 「適用」をクリックします。

7. オリジン・サーバーが正しく追加されていることを確認するには、「オリジン・サーバー」表でm2.abc.comを探します。

詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバーへのサイトのマッピングに関する項を参照してください。

10. 次の手順に従って、M1でFusion Middleware Controlを使用し、lbr.abc.comサイトを2つのオリジン・サーバーのm1.abc.comとm2.abc.comにマップします。

1. Oracle Enterprise Manager 11gで、M1のWeb Cacheホーム・ページに移動します。

2. Web Cacheのメニューから、「管理」→「サイト」を選択します。
「サイト」ページが表示されます。

3. 「サイト・サーバー間マッピング」ページで表内のLBRサイトのマッピングを選択し、「編集」をクリックします。

4. 「すべてのオリジン・サーバー」でm2.abc.com:8888を選択し、それを「選択したオリジン・サーバー」に移動します。

5. 「OK」をクリックします。

6. 「適用」をクリックします。

7. サイトが正しくマップされたことを確認するには、Enterprise ManagerのWeb Cacheメニューにアクセスして「管理」→「サイト」を選択し、「サイト・サーバー間マッピング」表でM1とM2の両方がlbr.abc.comのサイトに対応付けられているかどうかを調べます。

詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバーへのサイトのマッピングに関する項を参照してください。

11. M1でOracle Fusion Middleware Controlを使用し、M2のOracle Web CacheをM1のOracle Web Cacheクラスタに追加して、両方のOracle Web Cacheのパスワードが同じであることを確認します。これを行うには、次の手順を実行します:

1. Fusion Middleware ControlでWeb Cacheホーム・ページに移動します。

2. Web Cacheのメニューから、「管理」→「クラスタ」を選択します。

3. 「クラスタ」ページで「追加」をクリックします。
M2のWeb Cacheが追加されます。

4. 「適用」をクリックします。

5. 「同期化」をクリックし、「はい」をクリックして確認します。

6. M1およびM2上のOracle Web Cacheを再起動します。
キャッシュ・クラスタの構成の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

12. 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)の構成」を参照してください。

6.3.6 ステップ6: PortalツールとWebプロバイダの構成(オプション)

Portalツール(OmniPortletおよびWebクリッピング)プロバイダ、およびローカルで構築されたWebプロバイダとカスタムで構築されたWebプロバイダが正常に機能していることを確認するには、中間層環境にさらに構成を追加する必要があります。OmniPortletやその他のWebプロバイダによってファイル・システムがすでにパーソナライズされている場合、PDK-Javaのプリファレンス・ストア移行/アップグレード・ユーティリティを使用して、既存のパーソナライズをデータベースに移行し、以前のリリースからのパーソナライズをアップグレードすることができます。このユーティリティの詳細は、第B.9項「PDK-Javaのプリファレンス・ストア移行/アップグレード・ユーティリティの使用」を参照してください。

WSRPプロデューサの場合は、Oracle Metadata Repositoryがデフォルトのポートレット・プリファレンス・ストアとして使用されます。別のプリファレンス・ストアを使用する場合は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。

複数の中間層環境でのPortalツール・プロバイダの構成

複数の中間層環境でPortalツール(OmniPortletおよびWebクリッピング)プロバイダを正常に機能させるには、次の手順を実行します。

1. Portalツールの構成情報は、中間層サーバーのOmniPortletおよびWebクリッピングのprovider.xmlファイルに格納されます。構成は、いずれかの中間層(例: M1)で直接更新し、LBRがフロントエンドとして設定されているすべての中間層に伝播させる必要があります。詳細は、第E.1.3項「HTTPまたはHTTPSのプロキシ設定の構成」を参照してください。
provider.xmlファイルに加えられた変更を中間層のM2に伝播します。

- M1からM2に、DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\providers\omniPortlet\provider.xmlをコピーします。
dir_nameは、デプロイメント・インスタンスごとにランダムに生成されたディレクトリ名であることに注意します。

- M1からM2に、DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\providers\webClipping\provider.xmlをコピーします。

2. 中間層のM2を再起動します。

3. 次の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でのセッション・バインドの有効化」を参照してください。

4. Oracle Portalで、「ナビゲータ」にある「プロデューサ」タブの「ローカルで構築されたプロバイダ」で、OmniPortletプロデューサの「登録の編集」をクリックします。次に、「接続」タブをクリックし、プロデューサ登録URLの最初の部分をhttp://m1.abc.com:7777/からhttp://lbr.abc.com/に変更します。

5. Oracle Portalで、「ナビゲータ」にある「プロデューサ」タブの「ローカルで構築されたプロバイダ」で、Webクリッピング・プロデューサの「登録の編集」をクリックします。次に、「接続」タブをクリックし、プロデューサ登録URLの最初の部分をhttp://m1.abc.com:7777/からhttp://lbr.abc.com/に変更します。

6. ポートレット・リポジトリの「ポートレット・ビルダー」フォルダにPortalツール・ポートレットが表示されるように、ポートレット・リポジトリを更新します。

1. ポータル管理者としてログインし、「ビルダー」リンクをクリックします。

2. 「管理者」タブをクリックします。

3. 「ポートレット」サブタブをクリックします。

4. 「ポートレット・リポジトリ」ポートレットの「ポートレット・リポジトリのリフレッシュ」リンクをクリックします。

5. 更新処理がバックグラウンドで続行されます。

複数の中間層環境でのローカルで構築されたWebプロバイダの作成と編集

ローカルで構築されたプロバイダとは、Oracle Portalのインスタンス内部に定義されているプロバイダのことです。ローカルに構築されたプロバイダを使用できるのは、これらを前のリリースから移行した場合です。通常、LBRを構成する前に、これらのプロバイダを作成または編集します。LBRの構成後にこれを行うには、次の手順を実行します。

1. Webプロバイダの情報は、中間層サーバーのprovider.xmlファイルに保持されています。アップグレード・アシスタントを使用してprovider.xmlを1つの中間層(M1など)に移行し、LBRですべての中間層フロントエンドに伝播する必要があります。これを行う前に、M1以外の中間層をすべて停止する必要があります。

2. M1内のファイルに対して行われた変更を中間層のM2に伝播します。

1. DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INFに移動し、フォルダdeployment、deployment_provideruiおよびprovidersを、M1からM2にコピーします。
dir_nameは、デプロイメント・インスタンスごとにランダムに生成されたディレクトリ名であることに注意します。

2. DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\\deployment_providerui\provideruiacls.xmlファイルの<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>

3. 中間層のM2を再起動します。

4. 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ベースのルーティングを行うように構成する必要があります。ログインの頻度を設定するには、次の手順を実行します。

1. Oracle Portalにログインします。「Portalビルダー」ページが表示されます。

2. Portalビルダーで「管理」タブをクリックしてから、「ポートレット」タブをクリックします。

3. 「リモート・プロバイダ」で、構成するWebプロバイダ名を入力し、「編集」をクリックします。

4. 「接続」タブをクリックします。

5. 「ユーザー/セッション情報」で、「ログイン周期」を「ユーザー・セッションごとに1回」に設定します。

6. 「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/に変更します。

6.3.7 ステップ7: Oracle Web Cacheでのセッション・バインドの有効化

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で次の手順を実行します。

1. Oracle Enterprise Manager 11gでWeb Cacheホーム・ページに移動します。

2. Web Cacheのメニューから、「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。

3. 「セッション定義」表でセッション定義を作成します。セッション定義の作成方法の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

4. 次のようにセッション・バインド設定を指定します。

1. 「セッション・ポリシー構成」セクションで、「作成」をクリックします。
表に新しい行が表示されます。

2. 「セッション名」リストからステップ3で作成したセッションを選択し、「キャッシュ」オプションから「セッションを使用」を選択します。

3. 「セッション・バインディング構成」セクションで「セッションを使用したバインド」ラジオ・ボタンを選択します。ステップ3で作成したセッションを選択し、「Cookieに基づく」を選択します。

4. 「適用」をクリックして、変更を保存します。

詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

6.3.8 ステップ8: 構成完了の確認

完了した構成が正常に機能していることを確認するには、次の手順を実行します。

1. Oracle Web Cacheに格納されたコンテンツを消去するには、次のようにM1およびM2を再起動します。

1. Oracle Enterprise Manager 11gにアクセスして、M1インスタンスを開きます。
詳細は、「Oracle Enterprise Manager 11g Fusion Middleware Controlへのアクセス」を参照してください。

2. M1のメニューから、「制御」→「停止」→「制御」→「起動」を選択します。

3. この手順をM2について繰り返します。

2. 次の手順を実行して、Oracle PortalにLBRを通じてアクセスできるかどうかをテストします。

1. http://lbr.abc.com/portal/pls/portalにあるOracle Portalのホーム・ページにアクセスします。

2. ポータルのログイン・リンクをクリックします。

3. ポータルのリンクをいくつかクリックしてみます。

4. 次の手順を実行して、コンテンツがOracle Web Cacheにキャッシュされていることを確認します。
Fusion Middleware Controlにアクセスして「Web層」を開き、「Webキャッシュ」を選択します。Web Cacheのメニューを右クリックし、「監視」→「ポピュラーなリクエスト」を選択します。「ポピュラーなリクエスト」ページが表示されます。Oracle Portalで、ポートレットをページに追加するなどの基本的なページ編集を行って、「ポピュラーなリクエスト」ページのリフレッシュ時に、このページに新しいコンテンツが表示されることを確認します。新しいコンテンツが正しく表示されない場合やエラーが発生する場合は、Oracle Web Cacheの無効化の構成に誤りがあります。

6.4 仮想ホストの構成

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キャッシュ・サイト定義で指定した2つのサイトの作成に関する詳細を参照してください。

注意:

中間層のホスト名のみを変更する場合は、『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でアクセスされると想定します。

注意:

- この例のIPアドレスは、説明のためのみに使用しており、有効なIPアドレスであるとはかぎりません。

- この項で使用されている名前とポートは説明用の仮の値であり、実際の環境に合せて置き換える必要があります。

- この項では、Oracle Portal中間層の仮想ホストの構成方法を説明するだけなので、OracleAS Single Sign-Onのホスト名が変更されることはありません。OracleAS Single Sign-Onのホスト名をカスタマイズする方法の詳細は、『Oracle Application Server Single Sign-On管理者ガイド』にあるプロキシ・サーバーを使用したOracleAS Single Sign-Onの配置に関する項、および『Oracle Fusion Middleware管理者ガイド』を参照してください。

図6-4は、前述の構成を示しています。Oracle Web CacheとOracle Fusion Middlewareが同じ中間層のコンピュータにありますが、この2つは別々のコンピュータにあってもかまいません。

図6-4 仮想ホストの概要

注意:

ドメイン名www.abc.com、www.xyz.comおよびwww.login.comは有効なドメイン名であり、pingを実行できることが必要です。

仮想ホストを構成するには、次の手順を示された順序で実行します。

1. 仮想ホストの作成

2. Oracle Web Cacheの構成

3. Oracle PortalのOracleAS Single Sign-Onへの登録

4. 構成の確認

6.4.1 仮想ホストの作成

仮想ホスト名www.xyz.comおよび実際のサーバー名www.abc.com用に、httpd.confファイル内に仮想ホストのエントリを作成する必要があります。仮想ホストを定義するには、Oracle Enterprise Manager 11g Fusion Middleware Controlを使用して、次の手順を実行します。

- www.xyz.comの仮想ホストの作成

- www.abc.comの仮想ホストの作成

この手順を終了した後に、次のことを実行します。

1. httpd.confファイルの確認

2. 仮想ホストが正しく構成されたことの確認

6.4.1.1 www.xyz.comの仮想ホストの作成

www.xyz.comの仮想ホストを作成するには、次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlにアクセスします。

詳細は、「Oracle Enterprise Manager 11g Fusion Middleware Controlへのアクセス」を参照してください。

2. 「Web層」を開いて、Oracle Portalインスタンスの「HTTPサーバー」リンクをクリックします。

3. Oracle HTTP Serverのホーム・ページで、「管理」→「仮想ホスト」を選択します。
「仮想ホスト」ページが表示されます。

4. 「作成」ボタンをクリックします。
「仮想ホストの作成」ページが表示されます。

5. 「仮想ホストの作成」ページで、表6-2にリストされている情報を入力します。

表6-2 仮想ホスト情報

仮想ホスト情報

値

仮想ホスト名

「既存のリスニング・アドレスの使用」を選択し、ドロップダウン・オプションからポート番号を選択します。

サーバー名

使用ドメイン名はhttp://www.xyz.comです。

ドキュメント・ルート・ディレクトリ

ORACLE_INSTANCE\config\OHS\ohs1\htdocs

ディレクトリの索引

空白も可

管理者の電子メール・アドレス

有効な電子メール・アドレス

タイプ

名前ベース

6. 「OK」をクリックします。

7. サーバー名http://www.xyz.comが表にリストされていることを確認します。

8. 仮想ホストの構成後、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 *:8888>
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を再起動します。

6.4.1.2 www.abc.comの仮想ホストの作成

www.abc.comの仮想ホストを作成するには、次の手順を実行します。

1. 第6.4.1.1項「www.xyz.comの仮想ホストの作成」のステップ1から6を実行します。

2. 仮想ホストについての次の情報を「サーバー名」フィールドに入力します。

www.abc.com

3. 第6.4.1.1項「www.xyz.comの仮想ホストの作成」のステップ8に従います。

4. Oracle HTTP Serverを再起動します。

6.4.1.3 httpd.confファイルの確認

www.abc.comとwww.xyz.comの仮想ホストを構成したら、次のようにFusion Middleware Controlを使用して、httpd.confファイルを確認します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlにアクセスします。

2. Oracle Portalインスタンスの「HTTPサーバー」リンクを右クリックします。

3. Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。

4. 「サーバーの詳細構成」ページで「ファイルの選択」オプションから「httpd.conf」を選択して、「実行」をクリックします。
httpd.confファイルに次のような新しいセクションがあることを確認します。

NameVirtualHost *:8888

<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の両方の仮想ホストに対応する仮想ホストのエントリは必須です。

5. 「適用」をクリックして、ファイルを更新します。

注意:

- httpd.confファイルは、手動で更新することもできます。このファイルは、前述したような正しいVirtualHostディレクティブを含めるために、手動で編集できます。
最後に、次のコマンドを実行してOracle HTTP Serverを再起動します。

ORACLE_INSTANCE\bin\opmnctl stopall
ORACLE_INSTANCE\bin\opmnctl startall

- 使用するサイト名がDNSに登録されていない場合は、次のようにして、使用中のクライアント・コンピュータでhostsファイルを更新する必要があります。
Windowsの場合、このファイルは通常、C:\WINNT\system32\drivers\etcディレクトリ内にあります。次の例は、Windowsでのhostsファイルです。

# Copyright (c) 1993-1995 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP
# for Windows.
#
127.0.0.1 localhost
196.12.67.8 www.abc.com
196.12.67.8 www.xyz.com

UNIXの場合、このファイルは通常、/etc/hostsディレクトリ内にあります。これらの変更を行った後にシステムを再起動する必要はありません。

6.4.1.4 仮想ホストが正しく構成されたことの確認

次のURLにアクセスして、サーバー名と仮想ホストの両方が機能していることを確認します。

- http://www.xyz.com:8090/portal/pls/portal

- http://www.abc.com:8090/portal/pls/portal

6.4.2 Oracle Web Cacheの構成

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管理者ガイド』を参照してください。

6.4.3 Oracle PortalのOracleAS Single Sign-Onへの登録

Oracle PortalをOracleAS Single Sign-Onに登録するには、次の手順を実行します。

1. 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

2. osso_xyz.confファイルをインフラストラクチャのホームからORACLE_INSTANCE/config/OHS/ohs1ディレクトリにコピーします。

3. 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>

4. Oracle HTTP Serverを再起動します。

6.4.4 構成の確認

仮想ホストが正しく設定されたことを確認するには、次のいずれかのURLを使用してOracle Portalに接続します。

- http://www.abc.com:8090/portal/pls/portal

- http://www.xyz.com:8090/portal/pls/portal

最初のログイン時にhttp://www.login.comのログイン画面が表示され、ログインに成功することを確認してください。他の仮想ホストからのこれ以降のログインでは、シングル・サインオンが機能してログイン証明書の入力が求められないはずです。

6.4.5 OracleAS Single Sign-On 10gのホスト名の変更に応じたPortalの再構成

OracleAS Single Sign-On 10gのホスト名の変更に応じてOracle Portalを再構成するには、次のようにします。

1. 10gインフラストラクチャ・ホームにあるORACLE_HOME/Apache/Apache/conf/httpd.confファイルで、次のようにサーバー名を新しいホスト名に変更します。

ServerName new_sso_host

例:

ServerName sso.mycompany.com

2. ORACLE_HOME環境変数を10gインフラストラクチャ・ホームに設定します。

1. 10gインフラストラクチャ・ホームでディレクトリをORACLE_HOME/sso/binに変更します。

2. 次のスクリプトを実行します(UNIXの場合)。

ssocfg.sh http new_sso_host new_sso_port

例:

ssocfg.sh http sso.mycompany.com 7777

注意:

Windowsの場合は、ssocfg.batスクリプトを使用します。

3. 新しいOracleAS Single Sign-On 10gパートナ・アプリケーションを登録します。

1. 10gインフラストラクチャ・ホームでディレクトリをORACLE_HOME/sso/binに変更します。

2. 次のスクリプトを実行します。

ssoreg.sh \
-oracle_home_path $ORACLE_HOME \
-site_name infrastructure_middle_tier:port \
-config_mod_osso TRUE \
-mod_osso_url http://new_sso_host:new_sso_port \
-config_file file_name.conf

例:

ssoreg.sh \
-oracle_home_path $ORACLE_HOME \
-site_name sso.mycompany.com:7777 \
-config_mod_osso TRUE \
-mod_osso_url http://sso.mycompany.com:7777 \
-config_file $ORACLE_HOME/Apache/Apache/conf/osso/osso-sso.conf

注意:

ここに表示されたコマンドライン構文と例はUNIX用です。

Windowsの場合は、ssoreg.batスクリプトを使用し、ディレクトリ・パスのセパレータには円記号(\)を使用して、コマンド全体を1行で入力します。

3. ORACLE_HOME/Apache/Apache/conf/osso/osso.confのバックアップを作成し、その内容を、前の手順で作成したORACLE_HOME/Apache/Apache/conf/osso/osso-sso.confファイルのものに置き換えます。

4. DCMリポジトリを更新します。

$ORACLE_HOME/dcm/bin/dcmctl updateconfig

5. DAS操作URLを変更します。

1. OID管理ツール(oidadmin)を起動します。

2. orcladminとしてログインします。

3. 次に示すようにDAS操作URLに移動します。

4. orcldasurlbaseの値を次の値に更新します。

http://new_sso_host:new_sso_port/

例:

http://sso.mycompany.com:7777/

5. 「適用」をクリックします。

6. 10gインフラストラクチャ層を再起動します。

$ORACLE_HOME/opmn/bin/opmnctl stopall
$ORACLE_HOME/opmn/bin/opmnctl startall

7. Oracle Portal 11g用の新しいmod_ossoパートナ・アプリケーションを登録します。

1. 10gインフラストラクチャ・ホームでディレクトリをORACLE_HOME/sso/binに変更します。

2. 次のスクリプトを実行します。

ssoreg.sh \
-site_name portal_middle_tier:port \
-config_mod_osso TRUE \
-oracle_home_path $ORACLE_HOME \
-mod_osso_url http://portal_host:port \
-config_file file_name.conf \
-admin_info cn=orcladmin \
-remote_midtier

例:

ssoreg.sh \
-site_name portal.mycompany.com:8090 \
-config_mod_osso TRUE \
-oracle_home_path $ORACLE_HOME \
-mod_osso_url http://portal.mycompany.com:8090 \
-config_file $ORACLE_HOME/Apache/Apache/conf/osso/osso-portal.conf \
-admin_info cn=orcladmin \
-remote_midtier

注意:

ここに表示されたコマンドライン構文と例はUNIX用です。

Windowsの場合は、ssoreg.batスクリプトを使用し、ディレクトリ・パスのセパレータには円記号(\)を使用して、コマンド全体を1行で入力します。

3. Oracle Portal 11gのORACLE_HOMEで、/config/OHS/ohs1/osso.confのバックアップを作成し、その内容を、前の手順で作成したORACLE_HOME/Apache/Apache/conf/osso/osso-portal.confファイルのものに置き換えます。

8. WLS_PORTAL管理対象サーバーを再起動します。
Oracle Enterprise Manager 11gのWeb Cacheホーム・ページで「制御」→「再起動」を選択して、Oracle Web Cacheを再起動します。

最後に、次のコマンドを実行してOracle HTTP Serverを再起動します。

ORACLE_INSTANCE\bin\opmnctl stopall
ORACLE_INSTANCE\bin\opmnctl startall

6.5 プロキシ・サーバーを使用するためのOracle Portalの構成

ファイアウォールの外側のプロバイダおよびWebサイトへ接続するために、Oracle Portalを構成してプロキシ・サーバーを使用することができます。

注意:

- Oracle Textでは、URLのコンテンツの索引を作成するときに、プロキシ・サーバーの設定を使用します。詳細は、第10.3.6.4項「URLの索引のプロキシ設定」を参照してください。

- プロキシ・サーバーを使用するためにOracle Portalを構成するには、ポータル管理者であることが必要です。

- 推奨されるセキュアなエンタープライズ・デプロイメントの構成方法は、Oracle Fusion Middleware Java EEエンタープライズ・デプロイメント・ガイドを参照してください。

プロキシ・サーバーを指定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
「サービス」ポートレットは「ビルダー」ページの「管理」タブにあります。

2. 「プロキシ」タブをクリックします。

3. 「HTTPプロキシ・ホスト」フィールドで、myproxy.mycompany.comのように、ファイアウォールの外側のアプリケーションにアクセスするために使用する、HTTPプロキシ・サーバーのアドレスを入力します。プロキシ・サーバー名に接頭辞http://は付けません。

4. 「ポート」フィールドに、プロキシ・サーバーのポート番号を入力します。値を指定しない場合のポート番号のデフォルトは、80です。

注意:

プロキシのソフトウェアを実行するサーバーの名前とポート番号については、サーバー管理者に問い合せてください。

5. 「追加」をクリックします。
これで、ポータルとWebプロバイダまたはWSRPプロデューサ間の接続のためにプロキシ・サーバーを使用することができます。また、このプロキシは、たとえばURLアイテムに指定されたURLに接続するためなど、他の接続にも使用することができます。

6. 「プロキシの選択」セクションで、このような接続に使用するプロキシ・サーバーを選択します。非プロバイダ接続でプロキシ・サーバーを使用しない場合は、「なし」を選択します。

7. 「この文字で始まるドメインにプロキシ・サーバーを使用しない」フィールドに、プロキシ・サーバーを使用しないドメインを入力します。

注意:

ドメインは、たとえば.mycompany.comのようにピリオド(.)で始まる必要があります。複数のドメインは、カンマ(,)で区切ります。

8. 「OK」をクリックします。

プロキシ・サーバーの設定方法の詳細は、Oracle Technology Network (OTN)のサイト(http://www.oracle.com/technology/)でプロキシ・サーバー入門の文書を参照してください。

6.6 リバース・プロキシ・サーバーを使用するためのOracle Portalの構成

リバース・プロキシ・サーバーは、ファイアウォール・アーキテクチャとして使用するホスト・プロセスであり、外部とアクセスできるホストから内部ホストを分離します。外部リクエストが内部サービスにアクセスする際に通過しなければならないプロキシを提供することで、これを実現できます。一般に、プロキシ・サーバーはデュアルホーム・ホストの形式をとります。つまり、プロキシ・サーバーは2つのネットワーク・インタフェース・カードを持つホストです。一方のインタフェースは外部ネットワークに接続し、もう一方のインタフェースは内部ネットワーク、つまりファイアウォールの非武装地帯(DMZ)に接続します。

表6-2は、ブラウザがプロキシ・サーバーで発行されたホスト名を介してサーバーにアクセスするアーキテクチャを示しています。プロキシ・サーバーはその後、リクエストをファイアウォール内の実際のホストに転送します。

注意:

この構成が正しく機能するように、まずリバース・プロキシ・サーバーを使用するようにOracleAS Single Sign-Onを構成する必要があります。プロキシ・サーバーを使用するOracleAS Single Sign-Onのデプロイの詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。

図6-5 リバース・プロキシ・サーバーの構成

この例では、次の値を使用します。

プロパティ

値

外部サーバー名

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を構成するには、次の手順を実行します。

1. リバース・プロキシ・サーバーの構成

2. Oracle HTTP Serverの仮想ホストの構成

3. リバース・プロキシ・サーバーと連携するためのWeb Cacheの構成

4. リバース・プロキシ・サーバーと連携するためのPortal中間層の構成

5. リバース・プロキシ・サーバーと連携するためのOracle WebLogic Serverの構成

6. 内部サーバーのループバックの構成

7. osso.confファイルの構成

8. 構成の確認

リバース・プロキシ・サーバーの構成

任意のプロキシ・サーバーを、リバース・プロキシとして機能させることができます。たとえば、Oracle Web Cache、Oracle HTTP ServerまたはInternet Information Services (IIS)リスナーなどを使用できます。

注意:

ここでは、Oracle HTTP Serverをリバース・プロキシとして構成する方法を説明します。ポート80をリスニングするOracle HTTP Serverが構成済であること、そこへのアクセスにはwww.abc.comを使用することを前提としています。プラットフォームによっては、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がブラウザで有効になるようにします。これを行うには、次の手順を実行します:

1. 第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して、リバース・プロキシに使用するOracle HTTP Serverインスタンスの仮想ホストを定義します。ただし、次の変更点があります。

- 「サーバー名」フィールドでwww.abc.comを指定します。

- 仮想ホスト・コンテナのPortディレクティブに80を指定します。

2. 第6.4.1.1項「www.xyz.comの仮想ホストの作成」で説明しているように、「仮想ホストの作成」ウィザードを使用して、Oracle PortalとともにインストールしたApache ServerであるOracle HTTP Serverインスタンスの仮想ホストを定義します。ただし、次の変更点があります。

- 「サーバー名」フィールドでinternal.company.comを指定します。

- VirtualHostコンテナのPortディレクティブに8090を指定します。

3. 仮想ホストの構成後、Oracle Enterprise Manager 11g Fusion Middleware Controlを使用して、次のようにhttpd.confファイルを開きます。

1. 「Web層」を開いて、Oracle PortalインスタンスのOracle HTTP Server (ohs1)リンクをクリックします。

2. Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。

3. 「サーバーの詳細構成」ページで「ファイルの選択」オプションから「httpd.conf」を選択して、「実行」をクリックします。

4. httpd.confファイルで、次の構文を編集します。

NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://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>

5. Oracle HTTP Serverを再起動します。

ORACLE_INSTANCE\bin\opmnctl restartproc process-type=OHS

リバース・プロキシ・サーバーと連携するためのWeb Cacheの構成

Web Cacheのリバース・プロキシを構成するには、前の項で作成された仮想ホスト・エントリと一致するサイトを定義し、Oracle Fusion Middleware Controlを使用して、サイトのオリジン・サーバーへの順序付けされたマッピングを作成する必要があります。これを行うには、次の手順を実行します:

1. Enterprise ManagerのWeb Cacheホーム・ページに移動します。

2. 「Webキャッシュ」メニューから「管理」→「サイト」を選択します。
「サイト」ページが表示されます。

3. サイト定義セクションで、「作成」をクリックします。
サイト定義の作成ページが表示されます。

4. 次の情報を入力します。

- ホスト: www.abc.com

- ポート: 80

5. 「別名」セクションで「作成」をクリックして新しい別名を作成します。

6. 次の情報を入力します。

- ホスト: internal.company.com

- ポート: 8090
残りフィールドはデフォルト設定のままにします。

7. Click 「OK」をクリックします。

注意:

Webcacheで特定タイプのURLのみが許可されるようにするため、未使用のサイトを削除することをお薦めします。

8. 「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。

9. 「サイト・サーバー間マッピング」セクションで、次の情報を入力します。

- ホスト・パターン: www.abc.com

- ポート・パターン: 80

10. 「オリジン・サーバー」セクションで、「すべてのオリジン・サーバー」からinternal.company.com:8888を選択し、それを「選択したオリジン・サーバー」に移動します。

11. 「OK」をクリックします。

12. Oracle Enterprise Manager 11gのWeb Cacheホーム・ページで「制御」→「再起動」を選択して、Oracle Web Cacheを再起動します。

リバース・プロキシ・サーバーと連携するためのPortal中間層の構成

Oracle Portalでは、Portalへのアクセスに使用するURLに関連する一部の情報が保持されます。ポータル中間層の構成を次のように更新する必要があります。

1. Enterprise ManagerでPortalホーム・ページに移動します。

2. 「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。

3. 「ポータル・ワイヤ構成」ページの「ポータル中間層」セクションに、次の情報を入力します。

- 公開ホスト名: www.abc.com

- リスニング・ポート: 80

4. 「適用」をクリックします。

5. 管理対象サーバー(WLS_PORTAL)を再起動します。

リバース・プロキシ・サーバーと連携するためのOracle WebLogic Serverの構成

www.abc.comのHTTP設定を次のように構成する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. コンソールの左側のペインで、「環境」を開いて「クラスタ」を選択します。

4. クラスタ・サーバーを選択してから「HTTP」タブを選択します。

5. 「HTTP」ページで、次の情報を入力します。

- フロントエンド・ホスト: www.abc.com

- フロントエンドHTTPポート: 80

6. 「保存」をクリックします。

7. 管理対象サーバー(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ファイルを次のように構成する必要があります。

1. 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を実行する必要があります。

2. the osso.confファイルのバックアップを作成します。

3. 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でないことを確認します。

6.7 Oracle Web CacheにキャッシュされたOracle Portalコンテンツの管理

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 Enterprise Managerを使用したPortalのWeb Cache設定の構成

- WLSTを使用したPortalのWeb Cache設定の構成

- Oracle Web Cacheにキャッシュされたポータル・コンテンツの管理

- SQL*Plusによるキャッシュ無効化キューの消去

- 無効化メッセージの処理ジョブの管理

6.7.1 Oracle Web Cacheの管理

以前のリリースでは、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管理者ガイド』を参照してください。

6.7.2 Oracle Enterprise Managerを使用したPortalのWeb Cache設定の構成

ホスト名や無効化用ポート番号など、Oracle Portalで使用する設定を変更するには、Oracle Enterprise Manager 11g Fusion Middleware Controlを使用します。これらの設定は、「ポータル・ワイヤ構成」ページで構成できます。

関連項目:

「ポータル・ワイヤ構成」ページの使用方法の詳細は、第8.2.2.6項「「ポータル・キャッシュ設定」ページ」を参照してください。

6.7.3 WLSTを使用したPortalのWeb Cache設定の構成

Portal Web CacheのWLST(オンライン)コマンドを使用して、次の作業を実行できます。

- 属性のリスト

- 属性の更新

6.7.3.1 属性のリスト

Portalリポジトリで使用されるWeb Cache構成の属性をリストするには、次のようにします。

構文

listPortalWebcacheConfigAttributes ([dad_name])

引数

定義

dad_name

オプション。データベース・アクセス記述子の名前です。デフォルトのデータベース・アクセス記述子の名前は、portalです。

例

次の例では、Portalリポジトリで使用しているWeb Cache構成が表示されます。無効化メッセージの送信先のWeb Cacheホスト名、無効化ユーザー名、パスワードおよび無効化メッセージの送信先の無効化ポートがリストされています。

listPortalWebcacheConfigAttributes(dad_name='portal')

---------------
WebCacheConfig
---------------
WebCache Host: foo.oracle.com
WebCache Invalidation Password: invalidator
WebCache Invalidation Port: 6523
WebCache Invalidation User: invalidator

6.7.3.2 属性の更新

Portalリポジトリで使用されるWeb Cache構成の属性をリストするには、次のようにします。

構文

setPortalWebcacheConfig([dad_name], [host], [inv_port], [inv_user], [inv_passwd])

引数

定義

dad_name

オプション。データベース・アクセス記述子の名前です。デフォルトのデータベース・アクセス記述子の名前は、portalです。

host

オプション。無効化メッセージの送信先となるWeb Cacheホスト名です。

inv_port

オプション。無効化メッセージの送信先となるWeb Cacheポート番号です。

inv_user

オプション。無効化メッセージの送信に使用するユーザー名です。

inv_password

オプション。Web Cacheの無効化パスワードです。

例

次の例では、指定された値に基づいてWeb Cache構成を更新します。

setPortalWebcacheConfig(dad_name='portal',host='example.mycompany.com',inv_port='6523',inv_user='invalidator',inv_passwd='invalidator')

6.7.4 Oracle Web Cacheにキャッシュされたポータル・コンテンツの管理

Oracle Portalのユーザー・インタフェースから、Oracle Web Cacheにキャッシュされたポータル・コンテンツを管理する様々なタスクを実行できます。Oracle Web Cacheにキャッシュされたポータル・コンテンツ全体を消去したり、各ポータル・ユーザーのコンテンツを消去したりすることもできます。

注意:

キャッシュをクリアすると、後続のリクエストでキャッシュ・ミスが発生し、キャッシュに再移入が完了するまで、Portalのパフォーマンスが低下することがあります。

ユーザーのグループ・メンバーシップが変更された場合は、そのユーザーのキャッシュ・エントリを削除して新しい権限を持てるようにするため、キャッシュを消去することができます。同様に、あるオブジェクトに対するユーザーまたはグループの権限を変更する場合も、そのオブジェクトのキャッシュ・エントリを消去することができます。

キャッシュ全体をクリアする場合、または特定のユーザーのキャッシュをクリアする場合は、ポータル管理者権限が必要です。特定のポータル・オブジェクトのキャッシュをクリアするには、そのオブジェクトに対する管理権限以上の権限が必要です。

次の各項で、Oracle Portalを使用して実行できる処理について詳細に説明します。

- Web Cache全体の消去

- 特定ユーザーのキャッシュの消去

- 無効化ベースのキャッシュの有効期間の設定

- 特定ポータル・オブジェクトのキャッシュの消去

6.7.4.1 Web Cache全体の消去

Web Cache全体を消去するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「キャッシュ」タブをクリックします。

3. 「Web Cache全体を消去」を選択します。

4. 「適用」または「OK」をクリックして、キャッシュを消去します。

注意:

これによってすべてのページURLとスタイル・シートが消去されますが、ポータル・イメージは消去されません。

6.7.4.2 特定ユーザーのキャッシュの消去

特定のユーザーのためのキャッシュを消去するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「キャッシュ」タブをクリックします。

3. 「ユーザーのキャッシュを消去」フィールドに、キャッシュを消去するユーザーの名前を入力します。

注意:

ユーザー名が不明な場合は、「ユーザーをブラウズ」アイコンをクリックし、表示されたリストから選択します。

4. 「適用」または「OK」をクリックして、特定のユーザーのキャッシュを消去します。

注意:

ユーザーのポータル・プロファイルを編集して、特定のユーザーのためのキャッシュを消去することもできます。

6.7.4.3 無効化ベースのキャッシュの有効期間の設定

無効化ベースのキャッシュでは、アイテムの編集などによりオブジェクトが変更されたことをOracle Web Cacheに通知するメッセージをポータルまたはプロバイダが送信すると、キャッシュ・エントリがパージされます。ただし、キャッシュ・エントリに対する有効期間を設定することもできます。キャッシュ・エントリは、Oracle Web Cacheが無効化メッセージを受け取らない場合でも、この有効期間の最後に達するとパージされます。

注意:

無効化ベースのキャッシュのエントリに有効期間を設定するには、ポータル管理者であることが必要です。

無効化ベースのキャッシュのエントリに有効期間を設定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「キャッシュ」タブをクリックします。

3. 「有効期間の最大値」フィールドに、キャッシュ・エントリがパージされるまでにキャッシュ内に留まる最大時間(分単位)を入力します。

注意:

ここに小さな値を選択すると、キャッシュが頻繁に期限切れになるため、キャッシュのミスが頻繁に発生します。ただし、大きな値を選択すると、コンテンツが失効する場合があります。すべてのポータル・コンテンツがキャッシュできなくなるので、値に0は設定しないでください。

4. 「OK」をクリックします。

6.7.4.4 特定ポータル・オブジェクトのキャッシュの消去

ページ・グループ、ページ、ページ用のPortalテンプレート、ポートレット・リポジトリ内のポートレット、Portal DBプロバイダおよびPortal DBプロバイダのコンポーネントに対応するキャッシュ・エントリを消去するには、次の手順を実行します。

1. 「ナビゲータ」内で、消去するオブジェクトまでドリルダウンします。

- ページ・グループ、ページ、ページ用のPortalテンプレートの場合は、「プロパティ」をクリックし、「アクセス」タブをクリックします。

- Portal DBプロバイダとPortal DBプロバイダのコンポーネントの場合は、「アクセス権限の付与」をクリックします。

- ポートレットの場合は、「ポートレット・リポジトリ」ページ・グループの横の「ルート・ページの編集」をクリックし、目的のポートレットが含まれたページまでドリルダウンします。ポートレットの横にある「操作」アイコンをクリックし、「アクセス」をクリックします。

2. 「キャッシュの消去」をクリックします。

3. 「OK」をクリックします。

6.7.5 SQL*Plusによるキャッシュ無効化キューの消去

ユーザーが操作を行った結果、キャッシュ無効化キューが大きくなりすぎる場合があります。たとえば、大量のメンバーが属するグループへページに対するセキュリティ権限を繰り返し付与すると、付与するたびに、ユーザーごとにキュー内に弱い無効化が発生します。

弱い無効化は必要ではないこともありますが、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全体の消去」を参照してください。

6.7.6 無効化メッセージの処理ジョブの管理

Oracle Portalは、無効化メッセージを使用してキャッシュ内のオブジェクトを期限切れにします。cachjsub.sqlスクリプトを使用すると、無効化ジョブの実行頻度を構成できます。cachjsub.sqlの実行方法の詳細は、第B.1項「cachjsub.sqlを使用した無効化メッセージの処理ジョブの管理」を参照してください。

6.8 専用のOracle Web Cacheインスタンスを使用するためのOracle Portalの構成

Oracle Web Cacheは、1つ以上のOracle Portal中間層サーバーのフロントエンドに位置する専用サーバーに配置できます。Oracle Web Cacheは一般的なハードウェアでも十分に機能するため、専用の配置は、ハードウェアの費用の点では負担になりません。一般的には、1GBのメモリーを持つコンピュータを使用することをお薦めします。キャッシュ・サーバーと中間層サーバーのどちらも、高速のネットワーク・カードを使用してサイトのパフォーマンスを確保する必要があります。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

6.8.1 インストールの前提条件と要件の理解

- Oracle Portal中間層の場合、最初にOracleAS Infrastructureをインストールしてから、Portal中間層をインストールします。

- OracleAS Infrastructureと中間層をそれぞれのサーバーにインストールした後に、Oracle Web Cacheを専用サーバーにインストールします。

6.8.2 専用のOracle Web Cacheの構成

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つのタスクを実行します。

- タスク1: 専用サーバー上でOracle Web Cacheが稼働していることの確認

- タスク2: 専用サーバー上でのOracle Web Cacheの構成

- タスク3: 中間層サーバーの未使用のOracle Web Cacheの停止

- タスク4: Oracle Web Cache設定を使用するOracle Portal中間層の構成

- タスク5: Oracle HTTP Serverの仮想ホスト設定の構成

- タスク6: Oracle HTTP Serverパートナ・アプリケーションの再登録

6.8.2.1 タスク1: 専用サーバー上でOracle Web Cacheが稼働していることの確認

Oracle Web Cacheを専用サーバー上に正しく構成するには、Oracle Web Cacheが起動され、稼働中であることが必要です。Fusion Middleware Controlのホーム・ページ上でのOracle Web Cacheの起動、停止、再起動、およびそのステータスの表示方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

6.8.2.2 タスク2: 専用サーバー上でのOracle Web Cacheの構成

専用サーバーにOracle Web Cacheを正しく構成するには、Oracle Portal中間層と同じコンピュータにインストールされているOracle Web Cacheのオリジン・サーバー情報が必要となります。専用のOracle Web Cacheインスタンスからオリジン・サーバーのプロパティ設定を変更するには、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のタスク2: オリジン・サーバーの設定の指定に関する項の説明に従ってください。

6.8.2.3 タスク3: 中間層サーバーの未使用のOracle Web Cacheの停止

このタスクはオプションです。Oracle Portal中間層サーバーのリソースを節約するには、『Oracle Fusion Middleware管理者ガイド』の指示に従って、中間層サーバーの未使用のキャッシュを停止します。このキャッシュ・インスタンスは、この配置オプションでは使用されません。

6.8.2.4 タスク4: Oracle Web Cache設定を使用するOracle Portal中間層の構成

Oracle Portal中間層は、Oracle Web Cacheのリスニング・ポート、invalidatorユーザー名、invalidatorパスワード設定などを認識している必要があります。「ポータル・ワイヤ構成」ページでこれらの設定を変更して、専用のOracle Web Cacheの新しいホスト名とポート番号をOracle Portal中間層に適用する必要があります。

1. Oracle Enterprise Manager 11gの「システム・コンポーネント」セクションで、「ポータル」をクリックします。Oracle Portalのホーム・ページが表示されます。

2. 「ポータル」を右クリックして、「設定」→「ワイヤ構成」を選択します。

3. 「管理」セクションで「PortalのWebキャッシュ設定」リンクをクリックします。「PortalのWebキャッシュ設定」ページが表示されます。

4. 「ポータル・ワイヤ構成」ページの「ポータル中間層」で、「ホスト」フィールドを正しいホスト名www.company.comに変更し、「リスニング・ポート」フィールドを正しいポート番号7777に変更します。

5. 無効化ホストなど他のWeb Cache設定を確認し、専用サーバー上のキャッシュ情報に一致するようにし、「適用」をクリックします。デフォルトのポートとパスワードの設定の変更方法については、オンライン・ヘルプを参照してください。

6.8.2.5 タスク5: Oracle HTTP Serverの仮想ホスト設定の構成

専用のOracle Web Cache設定を使用して、仮想ホストのエントリをOracle Portal中間層の一部であるOracle HTTP Serverのhttpd.confファイル内に作成する必要があります。この例では、仮想ホスト名としてwww.company.com、ポート番号として7777(専用のOracle Web Cacheリスニング・ポートと同じ)を設定しています。仮想ホスト名とポート番号は、Oracle Web Cacheで定義されているサイト定義の値と一貫している必要があります。これを行うには、次のタスクを実行します。

1. 次のように仮想ホスト設定を構成します。

1. Oracle Enterprise Managerにログインします。

2. Oracle Enterprise Managerホーム・ページで「Web層」を開いて、インスタンスのHTTP Serverを選択します。

3. 「HTTPサーバー」→「管理」と移動し、「仮想ホスト」を選択します。

4. 「作成」をクリックします。

5. 「仮想ホストの作成」ページで、表6-3にリストされている情報を入力します。

表6-3 仮想ホスト情報

仮想ホスト情報

値

仮想ホスト名

「既存のリスニング・アドレスの使用」を選択します。

サーバー名

ドメイン名、www.company.com

ドキュメント・ルート・ディレクトリ

ORACLE_INSTANCE\config\OHS\ohs1\htdocs

ディレクトリの索引

空白も可

管理者の電子メール・アドレス

有効な電子メール・アドレス

タイプ

名前ベース

6. 「OK」をクリックします。

注意:

Oracle HTTP Serverは再起動しません。

2. 仮想ホストの構成後、テキスト・エディタを使用してhttpd.conf (ORACLE_INSTANCE\config\OHS\ohs1にある)を開き、次のようにPortおよびRewriteディレクティブをVirtualHostコンテナに追加します(太字の部分): 構文:

NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://www.company.com:7777
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

6.8.2.6 タスク6: Oracle HTTP Serverパートナ・アプリケーションの再登録

Oracle HTTP Serverパートナ・アプリケーションの再登録の詳細は、「Oracle HTTP Serverパートナ・アプリケーションの再登録」を参照してください。

6.9 インストール後のクラスタ環境の構成

ポータルの構成には、ファイルシステムの中間層およびデータベースのリポジトリの構成が含まれます。クラスタ環境でインストール後の構成が変更された場合は、各ノードで両方のタイプの構成を更新およびレプリケートする必要があります。

6.9.1 中間層の構成

クラスタ構成のノードごとに、中間層(ファイル・システム)の構成を更新する必要があります。中間層の構成を更新するには、次のいずれかを実行します。

Oracle Enterprise Manager 11gにログインして、次の手順を実行します。

- Portalキャッシュの構成を変更するには、Portalホーム・ページから「ポータル」→「設定」→「ポータル・キャッシュ」を選択して、「ポータル・キャッシュ構成」ページを表示します。必要に応じて変更を行い、「適用」をクリックします。WLSTコマンドを使用する場合は、「WLSTを使用したポータル・キャッシュの構成」を参照してください。

- ページ・エンジンの構成を変更するには、Portalホーム・ページから「ポータル」→「設定」→「ページ・エンジン」を選択して、「ページ・エンジン構成」ページを表示します。必要に応じて変更を行い、「適用」をクリックします。WLSTコマンドを使用する場合は、「WLSTを使用したParallel Page Engineの構成」を参照してください。

6.9.2 リポジトリの構成

クラスタ構成ではリポジトリ構成(データベース)を一度だけ更新すれば済みます。クラスタの全ノードで共有されるデータベースのバックエンドPortalスキーマが更新されるためです。ただし、中間層の構成のように、ノードごとにリポジトリの構成を繰り返し実行することもできます。リポジトリの構成を更新するには、Oracle Enterprise Manager 11g Fusion Middleware Controlにログインして、「ポータル」メニューから「設定」→「ワイヤ構成」を選択して、「ポータル・ワイヤ構成」を表示します。必要に応じて変更を行い、「適用」をクリックします。

WLSTコマンドを使用する場合は、「WLSTを使用したOracle Portalの構成」を参照してください。

6.10 OracleAS Wirelessの構成

複数の中間層インストールが実行される場合は、最初に設定されたOracleAS WirelessサービスのURLがOracle Portalインスタンスに格納されます。cfgiasw.plスクリプトを実行することにより、これを任意のOracleAS Wirelessサービスで選択したものに変更できます。詳細は、第B.6項「cfgiaswスクリプトを使用したモバイル設定の構成」を参照してください。

注意:

OracleAS Wirelessサービスとして選択したOracle Application Server中間層でportalRegistrarスクリプトを実行することにより、このURLを任意のOracleAS WirelessサービスのURLに変更できます。OracleAS Wirelessの構成の詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。

6.11 Oracle Portalスキーマ・パスワードの変更

この項では、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のデフォルトの場所は、DOMAIN_HOME\config\fmwconfigです。

Oracle Portalスキーマのパスワードを変更するには、次の手順を実行します。

- Portalインスタンスに応じて、次のいずれかのオプションを選択します。

- デフォルトのOracle Portalインスタンスのスキーマ・パスワードの変更

- デフォルトでないOracle Portalインスタンスのスキーマ・パスワードの変更

- Portalの資格証明の変更

6.11.1 デフォルトのOracle 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スキーマ・パスワードの変更に関する項を参照してください。

6.11.2 Portalの資格証明の変更

次のオプションを使用して、Portalの資格証明を変更できます。

- Oracle Enterprise Managerを使用したPortalの資格証明の管理

- WLSTコマンドを使用したPortalの資格証明の管理

6.11.2.1 Oracle Enterprise Managerを使用したPortalの資格証明の管理

この項では、Oracle Enterprise Managerでドメイン資格証明ストアの資格証明を管理する手順について説明します。

1. Oracle Enterprise Managerにログインし、「WebLogicドメイン」→「ドメイン名」とナビゲートします。「ドメイン名」を右クリックし、「セキュリティ」→「資格証明」を選択して、「資格証明」ページを表示します。
「資格証明ストア・プロバイダ」領域は読取り専用です。この領域を開くと、現在ドメインで使用している資格証明ストア・プロバイダが表示されます。

この読取り専用領域の下にある表で、資格証明を作成、編集および検索できます。

2. 「削除」ボタンを使用していつでも、表で選択した項目(キーまたはマップ)を削除できます。資格証明マップを削除すると、マップにあるすべてのキーが削除されます。同様に、「編集」ボタンを使用して、選択した項目のデータを表示または変更できます。

3. 特定のキー名と一致する資格証明を表示するには、「資格証明キー名」ボックスに一致させる文字列を入力し、右にある青いボタンをクリックします。問合せの結果が表に表示されます。

4. 問合せの結果を確認後に資格証明リストを再表示するには、クラシック・ドメインを右クリックして「セキュリティ」→「資格証明」を選択します。

新しい資格証明マップの作成

新しい資格証明マップを作成するには:

1. 「マップの作成」をクリックして、「マップの作成」ページを表示します。

2. ダイアログに、作成する資格証明のマップ名を入力します。

3. 「OK」をクリックして「資格証明」ページに戻ります。新しい資格証明マップ名がフォルダ・アイコンとともに表に表示されます。

新しいキーの追加

新しいキーを資格証明マップに追加するには:

1. 「キーの作成」をクリックして、「キーの作成」ページを表示します。

2. このダイアログで、「マップの選択」プルダウン・リストから新しいキーを挿入するマップを選択し、「キー」テキスト・ボックスにキーを入力して、「タイプ」プルダウン・リストからタイプを選択し(ダイアログの外観は、選択したタイプに応じて変わります)、必要なデータを入力します。

3. 終了したら「OK」をクリックして「資格証明」ページに戻ります。新しいキーが、選択したマップに対応するマップ・アイコンの下に表示されます。

6.11.2.2 WLSTコマンドを使用したPortalの資格証明の管理

WLSTは資格証明を管理するために、次のオンライン・コマンドをサポートしています。

- listCred

- updateCred

- createCred

- deleteCred

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

6.11.3 デフォルトでないOracle Portalインスタンスのスキーマ・パスワードの変更

通常、Oracle Portalスキーマのパスワードを変更するにはFusion Middleware Controlを使用しますが、スキーマがOracle Metadata Repositoryの外にあるポータル・インスタンスの場合は、SQL*Plusを使用してポータル・スキーマのパスワードを変更します。

次の手順に従い、データベースで直接スキーマのパスワードを変更します。

1. SYSDBA権限を持つユーザーとして、データベースに接続します。

2. 次のコマンドを入力します。

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)が再起動されます。

6.12 WLSTを使用したOracle Portalの構成

この項では、次のPortal構成にオプションとしてWLSTを使用する方法について説明します。

- Portal中間層の構成

- Portalサイト属性の構成

- PortalのOracle Internet Directory属性の構成

注意:

構成に変更を加えた後に、管理対象サーバーを再起動する必要があります。

関連項目:

Enterprise Managerを使用したタスクの実行の詳細は、第8章「Oracle Portalの監視と管理」を参照してください。

6.12.1 Portal中間層の構成

次の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

オプション。無効化メッセージの送信先となるWeb Cacheホスト名です。

webcache_inv_user

オプション。無効化メッセージの送信に使用されるWeb Cacheユーザー名です。

webcache_inv_port

オプション。無効化メッセージの送信先となるWeb Cacheポート番号です。

webcache_inv_passwd

オプション。Web Cacheの無効化パスワードです。

例

次の例では、指定された値に基づいて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')

6.12.2 Portalサイト属性の構成

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

6.12.3 PortalのOracle Internet Directory属性の構成

WLST(オンライン)コマンドを使用して、Oracle Internet Directory構成の属性をリストおよび更新できます。

6.12.3.1 属性のリスト

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

6.12.3.2 属性の更新

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')

7 Oracle Portalの保護

ポータル・ソリューションの最も重要な側面の1つにセキュリティがあります。Webコンテンツへのユーザー・アクセスを制御したり、システムへの侵入者からサイトを保護したりできることがきわめて重要です。この章では、Oracle Portalのセキュリティのアーキテクチャについて説明します。

- Oracle Portalのセキュリティについて

- Oracle PortalのOracle Fusion Middleware Security Frameworkの構成

- Oracle Portalのセキュリティの構成

関連項目:

- Oracle Fusion Middlewareセキュリティ・ガイド

- Oracle Fusion Middleware Oracle Identity Managementスタート・ガイド

7.1 Oracle Portalのセキュリティについて

次の項では、Oracle Portalのセキュリティの概要と、Oracle Fusion Middleware Security Frameworkでの動作について説明します。

- Oracle Portalのセキュリティ・モデル

- ユーザーのクラスとその権限

- 保護されているリソース

- 認可とアクセスの適用

- 認可の変更

- Oracle Fusion Middlewareのセキュリティ・サービスの利用

- Oracle Identity Managementインフラストラクチャの利用

- 動的グループの構成

- ポートレットのセキュリティ

- Web Services Remote Portletsへのアクセスの保護

- OmniPortletとシンプル・パラメータ・フォームの保護

- Webクリッピング・プロバイダの保護

- 連携型Portalアダプタの保護

- OraDAVの保護

7.1.1 Oracle Portalのセキュリティ・モデル

Web上でコンテンツを利用可能にするときは、少なくともそのコンテンツの一部へのアクセスを制限する必要があることが普通です。たとえば、サイトにあるすべてのドキュメントの表示をすべてのユーザーに可能にすることはまず考えられません。また、サイトにあるすべてのドキュメントの変更をすべてのユーザーに許可することはさらに考えられません。Oracle Portalでは、Webサイトの表示や変更ができるユーザーを完全に制御できる包括的なセキュリティ・モデルを提供しています。

ユーザーは、Oracle Portalにログインしないと、コンテンツ作成者がパブリックとして作成したコンテンツしか閲覧できません。パブリック・コンテンツは、ポータル・オブジェクト(ページなど)のURLを知っていて、それが格納されているコンピュータに接続できるユーザーであれば誰でも閲覧できます。ユーザーは、パブリックとして作成されたオブジェクト(パブリック・ポートレットなど)のみを表示できます。オブジェクトにパブリック・コンテンツが含まれていない場合、ユーザーはそのオブジェクトへのアクセスを拒否されます。

ポータルにログインしたユーザーは、そのユーザーのアクセス権限によって、コンテンツの表示および変更ができる場合もあれば、できない場合もあります。一般に、認証されたユーザーは、パブリック・ユーザーに比べてポータルで表示や、より多くの操作を実行できます。たとえば、認証されたユーザーは、パブリック・ユーザーが閲覧できないページ上のアイテムやポートレットを表示できます。また、認証されているユーザーは、パブリック・ユーザーだったら通常拒否される可能性のある、コンテンツの追加や編集、プロパティ、権限の変更などを行うことができます。ポータルでは、ユーザーやグループごとにオブジェクト(ページ、アイテムまたはポートレット)へのアクセスを制御することができます。つまり、ページに対するアクセス権限を特定のユーザー名、ユーザー・グループ名またはその両方の組合せで付与できます。

Oracle Portalでは、このように柔軟な方法でWebコンテンツへのアクセスを管理するために、Oracle Fusion Middlewareの他のコンポーネントとOracle Database 11gを活用して、ポータルの強固な保護を実現します。Oracle Portalでは、そのセキュリティ・モデルを実装するために、次のすべてのコンポーネントと対話します。

- Oracle Application Server Single Sign-Onは、ポータルのパブリック以外の領域にアクセスしようとするユーザーを認証します。

- mod_ossoは、Oracle HTTP Serverモジュールの1つで、OracleAS Single Sign-Onに認証リクエストをリダイレクトします。パートナ・アプリケーションのユーザー・アクティビティの追跡にも使用されます。

- Oracle Web Cacheは、Oracle Portalによって作成されたページの処理に使用されるキャッシュです(リクエストを処理できない場合は、Oracle HTTP Serverが代行します)。Oracle Portalでは、無効化キャッシュに基づいて、基となるページまたはメタデータが変更されると、キャッシュを無効にします。

- Oracle Internet Directoryは、Oracle固有のLDAPバージョン3のサービスで、ユーザー証明書とグループ・メンバーシップのリポジトリとして機能します。

- Oracle Internet DirectoryのOracle Delegated Administration Servicesは、ディレクトリの内部に格納される情報(ユーザーおよびグループ)を追加または更新します。

- Oracle Directory Integration Platformは、Oracle Portalがサブスクライブするなんらかのディレクトリ・イベント(ユーザーの削除など)が発生したときにOracle Portalに通知します。基本的に、Directory Integration Serverは、Oracle Portalにおいて変更が必要なディレクトリで変更が行われたときに、Oracle Portalに通知します。

Oracle Portalのアーキテクチャ

図7-1は、Oracle Portalのセキュリティ・アーキテクチャのコンポーネントおよびそれらの関係を示しています。

図7-1 Oracle Portalのセキュリティ・アーキテクチャ

Oracle Portalのアーキテクチャは、3つの基本層(クライアント・ブラウザ、中間層サーバー、およびインフラストラクチャ・サーバーとリポジトリ)で構成されています。Oracle Internet DirectoryとOracleAS Single Sign-Onは、インフラストラクチャをインストールする過程でデフォルトで同じホストにインストールされます。この層は、引き続きOracle Portalのインストールに使用されます。

デフォルトのインストールでは、3つのサーバーとリポジトリがすべて同じホストにインストールされますが、これらの機能を別々のサーバーにインストールすることをお薦めします。

Oracle Portalでは、中間層とインフラストラクチャ層のコンポーネントに多数の共通コンポーネントがあります。その中には、データベース・アクセス記述子(DAD)とOracle Fusion Middlewareで構成するリポジトリ・アクセス・コンポーネントがあります。後者は、インフラストラクチャ層で使用され、Oracle Delegated Administration Servicesを実行し、中間層でポータル・ランタイム・エンジンを実行します。

Oracle Portalのスループットとパフォーマンスを最適化するために、生成されたページはOracle Web Cacheにキャッシュされます。Oracle Web Cacheからポータル・ページに対するリクエストを提出できる場合、リクエストはOracle Portal中間層にアクセスせずに返されます。それ以外の場合、リクエストは、HTTPのオリジナル・サーバーとParallel Page Engineに転送されます。

現在のユーザーがSingle Sign-On環境で認証されておらず、リクエストされたページがパブリック・ページではない場合、ユーザーはユーザー名とパスワードを入力するよう要求されます。この機能は、認証のためにOracleAS Single Sign-Onへリダイレクトすることによって実行され、そこでLDAPリクエストを介して、Oracle Internet Directoryを基準として証明書が検証されます。証明書はディレクトリ内で見つかったものと照合されます。

認証に成功すると、シングル・サインオンのセッションCookieがOracleAS Single Sign-Onで作成されます。ユーザーが認証され、適切なOracle Portalセッションが作成されたら、ユーザーがアクセスに必要な権限を持つページやオブジェクトを特定する必要があります。パフォーマンス上の理由から、すべてのポータル・オブジェクトのアクセス制御リスト(ACL)は、保護対象のオブジェクトの定義とともにOracle Metadata RepositoryのOracle Portalスキーマに格納されます。

ユーザーとグループのプロビジョニングは、Oracle Internet Directoryの機能です。つまり、すべてのユーザーおよびグループ・メンバーシップの情報がOracle Internet Directoryに格納されます。ユーザーが初めてOracle Portalにログインすると、ユーザーの現在のグループ・メンバーシップがディレクトリから読み取られ、ACLと同じリポジトリにキャッシュされます。このプロセスによって、オブジェクトの権限をすばやく検索することができます。ユーザーのオブジェクトやページの権限がわかると、適切なページ・メタデータを生成して、Parallel Page Engineによって保護されたページを収集できるようになります。

Oracle Internet Directory内のユーザーとグループのプロビジョニングを単純化してポータルで使用するために、Oracle PortalはOracle Delegated Administration Servicesを使用して、Oracle Internet Directoryへのダイレクト・アクセスを可能にするユーザー・インタフェースを生成します。Oracle Delegated Administration Servicesへのコールは、mod_ossoプラグインによって保護されます。これは、Oracle Internet Directoryへのアクセスを提供する前に、ユーザーが正しく認証されていることを確認します。

セキュリティ・アーキテクチャの重要な機能の1つは、ローカルでキャッシュされたグループ・メンバーシップ・リストをOracle Internet Directoryと同期化する機能です。Oracle Directory Integration Platformでは、ローカルでキャッシュされた情報をOracle Internet Directoryでの変更に合せて自動的に最新の状態にしています。

外部リポジトリと照合して認証を行う必要がある場合は、Oracle Internet Directoryによって、委任された認証と外部認証の両方がサポートされます。Oracle Directory Integration Platformは、ローカル・キャッシュとOracle Internet Directoryを常に同期化するだけでなく、同様にOracle Internet Directoryと外部のすべてのリポジトリを常に同期化しています。

7.1.2 ユーザーのクラスとその権限

Oracle Portalには、デフォルトでユーザー・アカウントとユーザー・グループが多数用意されています。

- Oracle Portalのデフォルトの生成済ユーザー・アカウント

- Oracle Portalのデフォルトの生成済グループ

- Oracle Portalのデフォルト・スキーマ

7.1.2.1 Oracle Portalのデフォルトの生成済ユーザー・アカウント

表7-1で、Oracle Portalのインストール時にデフォルトで作成されるユーザー・アカウントについて説明します。

表7-1 デフォルトのOracle Portalユーザー

ユーザー

説明

orcladmin

このアカウントにはOracle Portalで最上位の権限が付与されます。このアカウントは、Oracle Fusion Middleware管理者向けに作成され、Oracle Fusion Middlewareのインストール時に指定されたパスワードを使用します。

また、このユーザーは作成者にかかわらず、すべてのOracle Instant PortalのOracle Instant Portal管理者となります。

7.1.2.2 Oracle Portalのデフォルトの生成済グループ

表7-2は、Oracle Portalのインストール時にデフォルトで作成されるグループを示しています。

表7-2 デフォルトのOracle Portalグループ

グループ脚注 1

説明

AUTHENTICATED_USERS

認証された、つまりログインしているユーザーを含むグループ。このグループの目的は、ポータルにログインしているすべてのユーザーに与えるデフォルトの権限を割り当てる手段を提供することです。

デフォルトでは、このグループにはグループの作成権限とすべてのスタイルの作成権限が付与されます。

このグループは、OracleDASCreateGroupのメンバーです。

DBA

Oracle Fusion Middlewareの管理者向けに設定された、高度な権限を持つグループ。Oracle Fusion Middlewareの一部であるコンポーネントによって、すべてのコンポーネント固有の権限がこのグループのメンバーに付与されます。

DBAグループは、PORTAL_ADMINISTRATORSグループのメンバーです。

このグループは、次のOracle Fusion Middlewareの権限グループのメンバーにもなっています。

- OracleDASCreateUser

- OracleDASEditUser

- OracleDASDeleteUser

- OracleDASUserPriv

- OracleDASCreateGroup

- OracleDASEditGroup

- OracleDASDeleteGroup

- OracleDASGroupPriv

- OracleDASConfiguration

DBAのメンバーには、OracleAS Single Sign-Onの管理に必要な権限は付与されません。このグループのメンバーにOracleAS Single Sign-Onを管理させる場合は、Oracle Application Server Single Sign-On管理者ガイドの説明に従って、それらの権限をこのグループのメンバーに付与する必要があります。

PORTAL_ADMINISTRATORS

Oracle Portal向けに設定された高度な権限のあるグループ。

デフォルトでは、このグループには次のOracle Portalのグローバル権限が付与されます。

- すべてのページ・グループの管理

- すべてのページの管理

- すべてのスタイルの管理

- すべてのプロバイダの管理

- すべてのポートレットの管理

- すべてのPortal DBプロバイダの管理

- すべてのPortalユーザー・プロファイルの管理

- すべてのグループ・プロファイルの編集

- すべてのログの管理

- すべてのトランスポート・セットの実行

このグループは、次のOracle Fusion Middlewareの権限グループのメンバーでもあります。

- OracleDASCreateUser

- OracleDASEditUser

- OracleDASDeleteUser

- OracleDASCreateGroup

- OracleDASConfiguration

PORTAL_ADMINISTRATORSのメンバーには、OracleAS Single Sign-Onの管理に必要な権限は付与されません。このグループのメンバーにOracleAS Single Sign-Onを管理させる場合は、Oracle Application Server Single Sign-On管理者ガイドの説明に従って、それらの権限をこのグループのメンバーに付与する必要があります。

PORTLET_PUBLISHERS

ポータルの他のユーザーにポートレットを公開する必要があるユーザー向けに設定された権限のあるグループ。

このグループには、デフォルトでOracle Portalの「すべてのポートレットの公開」グローバル権限が付与されます。

PORTAL_DEVELOPERS

ポートレットを構築しているユーザー向けに設定された権限のあるグループ。

デフォルトでは、このグループには次のOracle Portalのグローバル権限が付与されます。

- すべてのPortal DBプロバイダの作成

- すべての共有コンポーネントの管理

Portalの開発者には、データベース・プロバイダおよびポートレットを作成するための特別な権限が必要です。その権限を、すべてのスキーマでのデータ変更などのタスクを実行する開発者に割り当てることができます。詳細は、表7-6を参照してください。また、管理者権限All Schemaオブジェクト・タイプにはManage権限も必要です。詳細は、表7-6を参照してください。

RW_ADMINISTRATOR

Oracle Reports Servicesのレポート、プリンタ、カレンダおよびサーバーを管理するユーザーのグループ。

「管理」など、必要なオブジェクト権限をこのグループに割り当てる必要があります。

RW_DEVELOPER

Oracle Reports Servicesのレポートを開発するユーザーのグループ。

「実行」や「管理」など、必要なオブジェクト権限をこのグループに割り当てる必要があります。

RW_POWER_USER

Oracle Reports Servicesのレポートを変更できるユーザーのグループ。

「実行」や「管理」など、必要なオブジェクト権限をこのグループに割り当てる必要があります。

RW_BASIC_USER

Oracle Reports Servicesのレポートを使用するユーザーのグループ。

「実行」など、必要なオブジェクト権限をこのグループに割り当てる必要があります。

OIP_USER_ADMINS

Oracle Instant Portalの作成とユーザー管理の両方を実行できるユーザーのグループ。FMWADMINユーザーはこのグループのメンバーです。

OIP_AVAILABLE_USERS

Oracle Instant Portalにアクセスできるユーザーのグループ。このリストは、Oracle Instant Portalのユーザー・インタフェースの「ユーザー権限の管理」ダイアログ・ボックスに表示されます。

注意: Oracle PortalユーザーをOracle Instant Portalユーザーとして指定するには、「グループ」ポートレットを使用して、インストール時にデフォルトで作成されるOIP_AVAILABLE_USERSグループにそれらのユーザーを追加します。次に、Oracle Instant Portalの「ユーザー権限の管理」ダイアログ・ボックスで適切な権限を割り当てます。

脚注1 この表に示すグループはすべて、cn=<portal_group_container>,cn=Groups,dc=MyCompany,dc=comにあります。ID管理レルムの名前は、システムがインストールされているサーバーのドメイン名によって決定されることに注意してください。たとえば、サーバーのドメイン名がoracle.comであった場合、デフォルトのID管理レルム名はdc=oracle,dc=comとなります。サーバーのドメイン名がわからない場合、Oracle Internet Directoryではデフォルトでインストール時に管理者が指定したドメインになります。OracleDASxxxxxグループは、Oracle Internet Directoryの権限グループで、cn=groups,cn=OracleContext,dc=MyCompany,dc=com下にあります。これらのグループは、Oracle Internet Directoryでの操作(ユーザーやグループ、およびそれらの権限の作成または編集)を実行する権限を付与します。

注意:

- Oracle Internet Directoryセルフサービス・コンソールでは、ポータル関連のロールの説明の先頭に、portal.040823.142021.462000000というような数値が付いています。これらの数値は、Oracle Portalアプリケーションの名前で、複数のポータルが同じIdentity Managementシステムに関連付けられているマルチポータル環境でロールを選択する際、この表示に基づいて選択できるよう表示されます。

- Oracle Instant Portalのホーム・ページで「管理」権限が与えられている場合、そのユーザーには、そのポータルに対するすべての権限が付与されています。権限がユーザーに明示的に付与されていないかぎり、他のOracle Instant Portalの編集、削除、表示は一切できません。ただし、このユーザーは、「ユーザー権限の管理」ダイアログ・ボックスで、自身で作成したユーザーであるかどうかに関係なく、任意のユーザーを削除できます。(このため、ホーム・ページに対する「管理」権限を持つユーザー数は制限してください。)

7.1.2.3 Oracle Portalのデフォルト・スキーマ

Oracle Portalをインストールすると、インストール・プロセスによって、知っておく必要のあるデフォルトのスキーマがいくつかインストールされます。

表7-3で、Oracle Portalのインストール時にデフォルトで作成されるスキーマについて説明します。

表7-3 Oracle Portalのデフォルト・スキーマ

スキーマ

説明

PREFIX_PORTAL

Oracle Portalのデータベース・オブジェクトとコードを含んでいます。

Webでリクエストされたプロシージャを実行する際に、PortalサービスはN層認証を使用して、軽量ユーザー・アカウントが割り当てられているスキーマ(デフォルトではPREFIX_PORTAL_PUBLIC)に接続します。図7-2に示すように、ポータル・ユーザーのデータベースへのアクセスは、単一のスキーマ・ユーザーを介してプロキシ処理されます。

PREFIX_PORTAL_PUBLIC

すべての軽量ユーザーがデフォルトでマップされるスキーマです。プロシージャの権限は、このPREFIX_PORTAL_PUBLICスキーマ独自に付与されます。PUBLICにはプロシージャの実行権限が付与されなくなりました。

PREFIX_PORTAL_DEMO

デモ・コードを保持するために作成されます。このスキーマのインストールはオプションです。

PREFIX_PORTAL_APP

外部JSPアプリケーションの認証に使用されます。

図7-2に、ユーザー・プロキシによるN層認証を示します。

図7-2 ユーザー・プロキシによるN層認証

7.1.3 保護されているリソース

Oracle Portal内では、アクセスを制御するときの精度レベルを決定します。権限はユーザーごと、またはグループごとに、どのオブジェクトに対しても割り当てることができます。たとえば、ポータル内の各アイテムに対してユーザーごとにアクセス権限を割り当てることができますが、この方法ではコンテンツ作成者にかなりの負担がかかります。

作成者の負担を減らす場合は、ページ・レベルでグループごとに権限を割り当て、所定のページに配置したすべてのアイテムが同様のセキュリティ要件を持つようにすることができます。この方法を使用すると、通常はアイテムが含まれるページを介してアイテムが受けるセキュリティで十分であるため、コンテンツ作成者はページよりも高いセキュリティを必要とするアイテムに対してのみ権限を割り当てる必要があります。

関連項目:

権限のモデル化方法の詳細は、第7.1.7.10項「Oracle Delegated Administration Servicesのパブリック・ロール」を参照してください。

7.1.3.1 グローバル権限

ユーザーまたはグループに特定のタイプのすべてのオブジェクトに対する一定レベルの権限を付与する場合は、グローバル権限を使用します。

注意:

グローバル権限を付与されたユーザーには、多大な権限が与えられます。そのため、グローバル権限は本当にそれを必要としているユーザーまたはグループに対してのみ、十分に注意して付与する必要があります。グローバル権限は少数のユーザーに限定するようにしてください。

権限グループには、3つのタイプがあります。

- 表7-4「ページ・グループ権限」

- 表7-5「Portal DBプロバイダ権限」

- 表7-6「管理権限」

表7-4 ページ・グループ権限

オブジェクト・タイプ

権限

すべてのページ・グループ

「なし」: グローバル・ページ・グループ権限は一切付与されません。

「すべて管理」: ページ・グループであらゆる作業を実行できます。この権限は、他のグローバル・ページ・グループ権限に含まれる他のすべての権限に優先します。たとえば、この権限ですべてのページを管理できます。

「クラスの管理」: ページ・グループのカテゴリ、パースペクティブ、カスタム属性、カスタム・ページ・タイプまたはカスタム・アイテム・タイプを作成、編集および削除できます。

「テンプレートの管理」: ページ・グループのPortalテンプレートまたはHTMLテンプレートを作成、編集および削除できます。すべてのテンプレートへのアクセス権限を付与します。

「スタイルの管理」: ページ・グループのスタイルを作成、編集および削除できます。

「表示」: ページ・グループのすべてのページを表示できます。

「作成」: ページ・グループを作成し、そのページ・グループにページ・グループ・オブジェクトを作成できます。この権限を保持するユーザーまたはグループは、作成したページ・グループおよびページ・グループ・オブジェクトを編集および削除することもできます。注意: この権限を保持するユーザーは、既存のページ・グループにはオブジェクトを作成できません。

すべてのページ

「なし」: グローバル・ページ権限は一切付与されません。

「管理」: ページ・グループのページを作成、編集、パーソナライズまたは削除できます。ページ・グループのすべてのページへのアクセス権限を付与します。

「コンテンツの管理」: ページ・グループのページのアイテム、ポートレットまたはタブの追加、編集、非表示、共有または削除を行うことができます。

「承認付きアイテムの管理」: ページ・グループのページに新しいアイテムを作成できます。新しいアイテムは、指定された承認プロセスによって承認されるまで公開されません。この権限を持つユーザーおよびグループは、作成したアイテムを編集することもできます。また、ページをパーソナライズすることもできます。ページ・グループに対する承認が有効になっていない場合、アイテムに対するこの権限は、オブジェクト・タイプ「すべてのページ」のグローバル権限「コンテンツの管理」と同様になります。

「スタイルの管理」: ページ・グループのページに、選択可能なスタイルまたは新しいスタイルを適用できます。新しいスタイルを作成、編集および削除できます。注意: ユーザー自身が作成したスタイルの編集のみを許可します(他のユーザーのスタイルは変更または削除できません)。

「ポートレットのパーソナライズ(フル)」: ページ・グループのページをパーソナライズして、ポートレットを追加、表示、非表示、削除、移動または再配置できます。ページをパーソナライズして、タブを表示、非表示、削除または再配置できます。または既存のタブ・リージョンにタブを追加できます。ページ・グループのページをパーソナライズして、別のスタイルを使用することもできます。

「ポートレットのパーソナライズ(追加のみ)」: ページ・グループのページをパーソナライズして、ポートレットの追加または既存のタブ・リージョンにタブを追加できます。これらの権限を保持するユーザーまたはグループは、追加したポートレットを削除することもできます。ページ・グループのページをパーソナライズして、別のスタイルを使用することもできます。

「ポートレットのパーソナライズ(非表示-表示)」: ページ・グループのページをパーソナライズして、ポートレットまたはタブを表示または非表示にできます。ページ・グループのページをパーソナライズして、別のスタイルを使用することもできます。ページ・グループのページにポートレットを配置できます。

「パーソナライズ(スタイル)」: ページ・グループのページをパーソナライズして、別のスタイルを使用することもできます。

「表示」: ページ・グループのすべてのページを表示できます。

「作成」: ページ・グループにサブページを作成できます。この権限を保持するユーザーまたはグループは、作成したサブページの編集および削除もできます。注意: ページを作成するには、ページを作成するページ・グループのルート・ページの「管理」権限を保持している必要があります。

すべてのスタイル

「なし」: グローバル・スタイル権限は一切付与されません。

「管理」: ページ・グループのスタイルを作成、編集および削除できます。

「表示」: ページ・グループのスタイルを表示できます。

「公開」: ページ・グループのスタイルを他のユーザーが使用できるように公開できます。

「作成」: ページ・グループにスタイルを作成できます。この権限を保持するユーザーまたはグループは、作成したスタイルを編集および削除することもできます。

すべてのプロバイダ

「なし」: グローバル・プロバイダ権限は一切付与されません。

「管理」: プロバイダを登録、編集および登録解除し、ポートレット・リポジトリを表示および更新することができます。プロバイダの編集権限を付与することもできます。

「編集」: 登録されたプロバイダを編集できます。

「公開」: プロバイダを登録および登録解除できます。

「実行」: プロバイダのコンテンツを表示できます。

「作成」: ポートレット・プロバイダを登録できます。ユーザー(またはグループ)が作成したプロバイダでは、そのユーザーに「管理」権限が付与されます。したがって、ユーザーは、自分が作成したプロバイダに対して(編集と登録解除を含め)すべての操作を実行できます。

すべてのポートレット

「なし」: グローバル・ポートレット権限は一切付与されません。

「管理」: プロバイダのポートレットを作成、編集または削除できます。

「編集」: プロバイダのポートレットを編集できます。

「実行」: プロバイダのポートレットを実行できます。この権限を保持するユーザーまたはグループは、ポートレットにセキュリティが適用されている場合でも、すべてのポートレットを表示できます。ナビゲータには、すべてのポートレットに対する「表示」リンクが表示されます。

「アクセス」: プロバイダのポートレットを表示できます。

「公開」: ページ、ナビゲーション・ページまたはPortal DBプロバイダ・ポートレットをポータルに公開して、ページに追加できるようにします。

表7-5 Portal DBプロバイダ権限

オブジェクト・タイプ

権限

すべてのPortal DBプロバイダ

「なし」: グローバル・アプリケーション権限は一切付与されません。

「管理」: Portal DBプロバイダを編集または削除できます。Portal DBプロバイダのポートレットを作成、編集または削除できます。Portal DBプロバイダおよびPortal DBプロバイダのポートレットへのアクセス権限を付与します。

「コンテンツの編集」: Portal DBプロバイダのポートレットを編集できます。

「ソースの表示」: パッケージの仕様部と本体を表示し、Portal DBプロバイダのポートレットを実行できます。ポートレットのソースを確認できるユーザーまたはグループを主な対象にしているため、その呼出し方法についての説明は省略します。

「パーソナライズ」: Portal DBプロバイダのポートレットを実行およびパーソナライズできます。

「実行」: Portal DBプロバイダのポートレットを実行できます。

「作成」: Portal DBプロバイダを作成できます。この権限を保持するユーザーまたはグループは、作成したプロバイダを編集および削除できます。また、作成したプロバイダのポートレットを作成、編集および削除できます。

すべての共有コンポーネント

「なし」: グローバル共有コンポーネント権限は一切付与されません。

「管理」: Portal DBプロバイダの共有コンポーネントを作成、表示、コピー、編集、削除およびエクスポートできます。システム共有コンポーネントを表示およびコピーできます。非システム共有コンポーネントへのアクセス権限を付与します。

「作成」: Portal DBプロバイダ内に共有コンポーネントを作成できます。システム共有コンポーネントを表示およびコピーできます。共有コンポーネントを表示できます。この権限を保持するユーザーまたはグループは、作成した共有コンポーネントを表示、コピー、編集、削除およびエクスポートできます。

表7-6 管理権限

オブジェクト・タイプ

権限

すべてのユーザー・プロファイル

「なし」: グローバル・ユーザー・プロファイル権限は一切付与されません。

「管理」: ユーザー・プロファイルを編集できます。他のユーザーおよびグループにこの権限を付与できます。

「編集」: ユーザー・プロファイルを編集できます。

すべてのグループ権限(プロファイル)

「なし」: グローバル・グループ・プロファイル権限は一切付与されません。

「管理」: グループ・プロファイルを編集できます。この権限を他のグループに付与できます。グループ・プロファイルの「権限」タブを使用すると、ユーザーはグループにこの権限を付与できます。「管理」権限によって「編集」権限が付与され、この権限を他のユーザーに付与できます。

「編集」: ポータル・グループ・プロファイルを編集(デフォルトのホーム・ページとデフォルトのモバイル・ホーム・ページを設定)できます。注意: グループの説明、メンバーシップおよび所有者を変更する権限は、Oracle Internet Directoryのアクセス制御ポリシーで制御されます。このポリシーは、OracleDASEditGroupグループのメンバーシップにより管理されます。

すべてのスキーマ

「なし」: グローバル・スキーマ権限は一切付与されません。

「管理」: スキーマを作成、編集および削除できます。スキーマへのアクセス権限を付与します。スキーマのデータベース・オブジェクトの作成、編集、削除および名前の変更ができます。表のデータまたはスキーマのビューの問合せ、更新、削除および挿入を行うことができます。スキーマのファンクション、プロシージャ、パッケージまたはビューをコンパイルできます。スキーマのファンクション、プロシージャまたはパッケージを実行できます。すべてのスキーマのデータベース・オブジェクトへのアクセス権限を付与します。

「データの変更」: スキーマを作成できます。表のデータまたはスキーマのビューの問合せ、更新、削除および挿入を行うことができます。スキーマのファンクション、プロシージャ、パッケージまたはビューをコンパイルできます。スキーマのファンクション、プロシージャまたはパッケージを実行できます。この権限を保持するユーザーまたはグループは、作成したスキーマの編集、削除およびアクセス権限の付与を行うことができます。

「データの挿入」: スキーマを作成できます。表のデータまたはスキーマのビューの問合せおよび挿入を行うことができます。この権限を保持するユーザーまたはグループは、作成したスキーマの編集、削除およびアクセス権限の付与を行うことができます。

「データの表示」: スキーマを作成できます。表のデータまたはスキーマのビューに対する問合せを行うことができます。この権限を保持するユーザーまたはグループは、作成したスキーマの編集、削除およびアクセス権限の付与を行うことができます。

「作成」: スキーマを作成します。この権限を保持するユーザーは各自が作成したスキーマの編集、削除およびアクセス許可も実行できます。注意: 「ビルダー」ページの「データベースの管理」タブで、「スキーマ」ポートレットへのアクセスをユーザーまたはグループに許可する場合は、そのユーザーまたはグループをDBAグループのメンバーにするか、「データベースの管理」タブで明示的にそのユーザーまたはグループに表示権限を付与します。これらの権限が付与されていないユーザーやグループは、「ナビゲータ」からスキーマにアクセスすることができません。

すべてのログ

「なし」: グローバル・ログ権限は一切付与されません。

「管理」: ログを編集またはパージ(消去)できます。この権限を他のユーザーに付与できます。

「編集」: ログを編集またはパージ(消去)できます。

「表示」: ログを表示できます。

すべてのトランスポート・セット

「なし」: グローバル・トランスポート・セット権限は一切付与されません。

「実行」: 共有されていないオブジェクトをエクスポートおよびインポートできます。また、この権限を保持するユーザーは、共有されていないエクスポート・オブジェクトとインポート・オブジェクトを編集またはパージ(消去)できます。

「管理」: インポート・セットまたはエクスポート・セットを編集またはパージ(消去)できます。この権限を他のユーザーに付与できます。

7.1.3.2 オブジェクト権限

オブジェクトの「ページの編集」の「アクセス」タブを使用すると、Oracle Portal内の次のすべてのオブジェクトに対するアクセス権限をユーザーまたはグループに割り当てることができます。

表7-7 Oracle Portalオブジェクトと権限の制御

オブジェクトのタイプ

利用できる権限

権限の継承元

カレンダ

- 管理

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

チャート

(SQL問合せベース)

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

チャート

(ウィザード・ベース)

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

データ・コンポーネント

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

データ・コンポーネント・セル

- 編集

- 表示

データ・コンポーネント

データベース・プロバイダ

- 管理

- 編集

- ソースの表示

- パーソナライズ

- 実行

該当なし

ドキュメント

- 所有

- 管理

- 表示のみ

ページまたはアイテム

動的ページ・コンポーネント

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

フォーム脚注 1

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

フレーム・ドライバ

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

階層

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

イメージ・チャート

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

リンク

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

値リスト

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

メニュー

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

Oracle Reports Servicesプリンタ

- 管理

- 編集

- 表示

- 実行

データベース・プロバイダ

Oracle Reports Servicesレポート

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

Oracle Reports Servicesサーバー

- 管理

- 編集

- 表示

- 実行

データベース・プロバイダ

ページ

- 管理

- コンテンツの管理

- 承認付きアイテムの管理脚注 2

- スタイルの管理

- ポートレットのパーソナライズ(フル)

- ポートレットのパーソナライズ(追加のみ)

- ポートレットのパーソナライズ(非表示-表示)

- パーソナライズ(スタイル)

- 表示

ページ・グループのルート・ページ

ページ・グループ

- すべて管理

- クラスの管理

- テンプレートの管理

- スタイルの管理

- 表示

該当なし

ページ・アイテム

- 所有

- 管理

- 表示のみ

ページ

ポートレット

- 管理

- 編集

- 実行

- アクセス

- 公開

該当なし

プロバイダ

- 管理

- 編集

- 公開

- 実行

該当なし

例による問合せフォーム

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

レポート脚注 3

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

スキーマ

- 管理

- 更新

- 挿入

- 表示

該当なし

URL

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

XML

- 管理

- 編集

- 表示

- パーソナライズ

- 実行

データベース・プロバイダ

脚注1 フォームには多様なタイプ(ストアド・プロシージャまたは表ベース、リリース2またはリリース3ベース、マスター/ディテール)がありますが、これらのタイプで利用できる権限や権限の継承元はすべて同じです。

脚注2 この権限は、承認がページ・グループ・レベルで有効になっている場合にのみ、「アクセス」タブで使用できます。ページ・グループに対する承認が有効になっていないか、承認は有効になっているがページ・レベルまたはページ・グループ・レベルに承認プロセスが定義されていない場合、この権限はページのグローバル権限「コンテンツの管理」と同様になります。

脚注3 レポートには2つの異なるタイプ(SQLおよび表ベース)がありますが、これらのタイプで利用できる権限や権限の継承元はすべて同じです。

7.1.3.3 新規プロバイダへの権限付与

新規プロバイダを作成または登録すると、「ポートレット・ステージング領域」の「ポートレット・リポジトリ」にページが作成され、そのプロバイダのポートレットが表示されます。このページはすべてのログイン・ユーザーに表示されるわけではありません。プロバイダを公開したユーザーおよびポータル管理者にのみ表示されます。公開者またはポータル管理者は、プロバイダのページ・プロパティを変更して、必要に応じて適切なユーザーまたはグループに権限を付与できます。

7.1.3.4 Webプロバイダとプロバイダ・グループを編集する権限

ファイルを直接操作するかわりに、ユーザー・インタフェースを使用してWebプロバイダとプロバイダ・グループを管理するには、管理ユーザーに適切な権限を付与する必要があります。アクセス制御リストの実装方法は、Oracle Portalスキーマに常駐するオブジェクトの場合とは異なります。Oracle Portalスキーマに常駐するオブジェクトの詳細は、第7.1.3.1項「グローバル権限」および第7.1.3.2項「オブジェクト権限」を参照してください。プロバイダ権限の付与は、XMLファイルで管理します。

Webプロバイダまたはプロバイダ・グループを編集および削除するための権限を付与するには、次のファイルを手動で変更する必要があります。

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INF\deployment_providerui\provideruiacls.xml

次に、このファイルの例を示します。

注意:

この例のユーザー名any_provider_manage_user、any_provider_edit_userなどは、ユーザー名の例です。各権限のコードは、ユーザー名に示されている権限に対応しています。実際にユーザーに付与する場合は、<user>要素のname属性の値として、OracleAS Single Sign-Onユーザー名を指定します。これにより、該当する権限コードを使用して権限が設定されます。

<providerui xmlns="http://www.example.com/portal/providerui/1.0">
<objectType name="ALL_OBJECTS">
<object name="ANY_PROVIDER" owner="providerui">
<user name="any_provider_manager_user" privilege="500"/>
<user name="any_provider_edit_user" privilege="400"/>
<user name="any_provider_execute_user" privilege="300"/>
</object>
<object name="ANY_PORTLET" owner="providerui">
<user name="any_portlet_manage_user" privilege="500"/>
<user name="any_portlet_edit_user" privilege="400"/>
<user name="any_portlet_execute_user" privilege="300"/>
</object>
</objectType>
<objectType name="PROVIDER">
<object name="TEST_PROVIDER" owner="providerui">
<user name="provider_manage_user" privilege="500"/>
<user name="provider_edit_user" privilege="400"/>
<user name="provider_execute_user" privilege="300"/>
</object>
</objectType>
<objectType name="PORTLET">
<object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER">
<user name="portlet_manage_user" privilege="500"/>
<user name="portlet_edit_user" privilege="400"/>
<user name="portlet_execute_user" privilege="300"/>
</object>
</objectType>
</providerui>

このファイルでは、次の項に説明されている権限タイプを付与できます。

- グローバル権限

- オブジェクト・レベルの権限

7.1.3.4.1 グローバル権限

表7-8で、provideruiacls.xmlファイルでユーザーに付与できるグローバル・オブジェクト・タイプおよび対応する権限コードについて説明します。ユーザーに権限を付与するときには、数値の権限コードを指定する必要があります。

表7-8 provideruiacls.xmlのグローバル権限コード

オブジェクトのタイプ

利用できる権限

ANY_PROVIDER

500(管理): プロバイダまたはプロバイダ・グループおよびそれらのポートレットを編集または削除したり、開くことができます。

400(編集): プロバイダまたはプロバイダ・グループを編集したり、それらのポートレットを実行することができます。

300(実行): プロバイダまたはプロバイダ・グループを開いたり、それらのポートレットを実行することができます。

ANY_PORTLET

500(管理): プロバイダのポートレットを編集、削除または実行できます。

400(編集): プロバイダのポートレットを編集または実行できます。

300(実行): プロバイダのポートレットを実行できます。

特定のユーザーの権限を追加するには、たとえば次のように、適切なオブジェクト・タイプ・コンテナにエントリを追加します。

<objectType name="ALL_OBJECTS">
<object name="ANY_PROVIDER" owner="providerui">
<user name="jdoe" privilege="400"/>
…
</object>
</objectType>

これらのグローバル権限では、objectTypeの名前はALL_OBJECTSに、オブジェクト所有者はprovideruiに設定します。また、オブジェクト名は、設定している権限付与のタイプに応じてANY_PROVIDERまたはANY_PORTLETになります。

次に、ユーザー名および権限を、権限受領者のOracleAS Single Sign-Onのユーザー名と、割り当てる権限コードに対応する値に設定します。このモデルでは、グループへの権限付与はサポートされません。ユーザーへの直接付与のみがサポートされます。

7.1.3.4.2 オブジェクト・レベルの権限

表7-9では、ユーザーに付与できるオブジェクト・レベルの権限について説明します。オブジェクト・レベルの権限を付与されたユーザーは、provideruiacl.xml XMLファイル内で特定のオブジェクト・インスタンスを参照できます。

表7-9 provideruiacl.xmlのオブジェクト権限コード

オブジェクトのタイプ

利用できる権限

PROVIDER

500(管理): 指定されたプロバイダまたはプロバイダ・グループおよびそれらのポートレットを編集または削除したり、開くことができます。

400(編集): 指定されたプロバイダまたはプロバイダ・グループを編集したり、それらのポートレットを実行することができます。

300(実行): 指定されたプロバイダまたはプロバイダ・グループを開いたり、それらのポートレットを実行することができます。

PORTLET

500(管理): 指定されたプロバイダの指定されたポートレットを編集、削除または実行できます。

400(編集): 指定されたプロバイダの指定されたポートレットを編集または実行できます。

300(実行): 指定されたプロバイダの指定されたポートレットを実行できます。

特定のユーザーの権限を追加するには、たとえば次のように、適切なオブジェクト・タイプ・コンテナにエントリを追加します。

<objectType name="PORTLET">
<object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER">
<user name="jdoe" privilege="400"/>
…
</object>
</objectType>

オブジェクト・レベルの権限では、objectTypeの名前は、アクセスを許可するオブジェクト・インスタンスに応じてPROVIDERまたはPORTLETに設定します。オブジェクト名は、同じくインスタンスに応じてプロバイダ名またはポートレット名に設定します。オブジェクト所有者は、プロバイダとポートレットのそれぞれについて、provideruiまたは関連プロバイダ名に設定します。

表7-10に、これらの規則をまとめます。

表7-10 プロバイダとポートレットの属性値

属性

プロバイダ・インスタンスの権限を付与する場合

ポートレット・インスタンスの権限を付与する場合

オブジェクト・タイプ名

PROVIDER

PORTLET

オブジェクト名

プロバイダ名またはプロバイダ・グループ名

ポートレット名

オブジェクトの所有者

providerui

プロバイダ名

ユーザー名

OracleAS Single Sign-Onユーザー名

OracleAS Single Sign-Onユーザー名

ユーザーの権限

権限コード

権限コード

7.1.3.5 WSRPプロデューサを作成および編集する権限

WSRPプロデューサを作成および編集する権限の付与の詳細は、次の場所に記載されているJSR 168仕様のセキュリティに関する項を参照してください。

http://jcp.org/aboutJava/communityprocess/first/jsr168/index.html.

7.1.3.6 ポートレット・リポジトリ内のURLおよびXMLポートレットを編集するための権限

ポートレット・リポジトリ内のURLおよびXMLポートレットを編集するには、ユーザーに権限を付与する必要があります。URLおよびXMLポートレットは、ポートレット・リポジトリの「ポートレット・ビルダー」ページから利用できます。アクセス権限を付与したり、JPDK Webアプリケーションでサンプル・プロバイダを編集するには、次のフォルダのprovideruiacls.xmlを手動で変更する必要があります。

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INF\deployment_providerui\

付与できる権限の詳細は、第7.1.3.4項「Webプロバイダとプロバイダ・グループを編集する権限」を参照してください。

7.1.4 認可とアクセスの適用

ユーザーがOracle Portalへのログインを試みると、まずOracleAS Single Sign-Onによって証明書がディレクトリと照合される必要があります。IDの照合が終わると、Oracle Portalによってディレクトリに格納されているユーザーのアクセス権限がチェックされて、ポータルで表示および使用できるオブジェクトが特定されます。

1. Oracle Portalから、ユーザーが「ログイン」リンクをクリックして、ログインするようリクエストします。

2. ログイン・リクエストがmod_ossoに転送されます。mod_ossoは、動的ディレクティブを使用して、認証のためにOracleAS Single Sign-Onサーバーと連携します。

3. OracleAS Single Sign-Onによってユーザー証明書がディレクトリに格納されている情報と照合されます。

4. 認証に成功すると、OracleAS Single Sign-OnによってユーザーのSSO Cookieが作成されます。認証に成功しなかった場合、ユーザーはアクセスを拒否され、ユーザー名とパスワードの再入力のためにログイン・ページに戻されます。

5. ユーザーIDが確認されると、制御がOracle Portalに戻され、ポータル・セッションCookieが作成されます。次に、Oracle Portalはディレクトリに接続して、ユーザーのグループ・メンバーシップと権限を確認します。

6. そのセッションの間に、Oracle Portalによってユーザーのメンバーシップと権限の情報がローカルにキャッシュされます。

7. ユーザーがページへのアクセスを試みると、Oracle Portalによって次の確認が行われます。

- ページがパブリックであるかどうかを確認します。パブリックであれば、ユーザーはそのページを表示できます。

- そのページがパブリックでない場合は、Oracle Portalによってローカルの権限表が照合されて、現行のユーザーにそのページを表示する権限があるかどうかが確認されます。ユーザーに表示する権限があれば、ユーザーはページを表示できます。

- 現行のユーザーにページを直接表示する権限がない場合は、Oracle Portalによって、キャッシュされているメンバーシップ情報と権限表が照合されて、ユーザーが属しているいずれかのグループにそのページを表示する権限があるかどうかが確認されます。ユーザーが属しているいずれかのグループにページを表示する権限があれば、ユーザーはページを表示できます。

注意:

ユーザーの権限に影響を及ぼす変更がOracle Internet Directoryに対して行われた場合は、通知が送信され、そのユーザーに関するキャッシュされた情報が無効になります。このため、Oracle Portalでは、通知を受信するとすぐに、ユーザーの更新された権限を適用し始めます。groupOfNamesオブジェクト・クラスに基づくグループを使用している場合は、プロビジョニング・プロファイルを更新する必要があります。詳細は、「groupOfNamesベースのグループのサブスクリプション・プロファイルの更新」を参照してください。

7.1.5 認可の変更

Oracle Portal 11gでは、ユーザーが特定のページを表示または編集できるかどうかが、ページとユーザー(またはユーザーが属するロール)を参照するACLポリシー定義に従って決まります。ユーザーの権限は、特定のビジネス・ルール(リクエストの発信元など)ではなく、名前付きの個別IDで定義します。このセキュリティ・モデルの拡張を実現するために、Oracle Portal 11gでは、認可ルーチンを拡張するAuthorization Modifierパッケージが導入されています。このパッケージは、標準のACLチェックの前に実行され、ACLそのものを照合する前に別のルールによる評価を可能にします。この機能は、新規のページまたはページ・グループにのみ適用され、既存のページまたはページ・グループには適用されません。Authorization Modifierでアクセスが許可されると(trueが返される)、認証チェックはデフォルトのACLベースのメカニズムに戻り、ユーザーに適切なアクセス権限があるかどうかが判断されます。逆に、Authorization Modifierでアクセスが拒否されると(falseが返される)、ACLの照会も実行されず、たとえACLで許可されている場合でも、該当の操作に対する適切な権限がユーザーにない場合と同様に扱われます。インストールした状態のままのAuthorization Modificationパッケージは、デフォルトで必ずtrueを返すため、この機能は事実上無効になっています。したがって、アクセス権限の決定は、セキュリティACLの評価のみが基準となります。Authorization Modifierの機能を有効にするには、デフォルトのパッケージ本体を、目的のビジネス・ルールを実装したパッケージに置き換える必要があります。

Portalには、次のAuthorization Modifierが付属しています。

- セキュアなネットワーク認識のAuthorization Modifier

- デフォルトのAuthorization Modifier

- ページの表示と編集に関するAuthorization Modifier

7.1.5.1 セキュアなネットワーク認識のAuthorization Modifier

Oracle Portalには、事前に定義された3つのModifierパッケージが付属します(表7-11を参照)。これを使用して、セキュアなネットワーク認識のPortal環境を構築することで、ACLに基づくだけでなく、Portalページのリクエスト元にも基づくセキュリティ・ポリシーを実装できます。

表7-11 Authorization Modifierパッケージ

スクリプト・ファイル

説明

cfgamyes.pkb

デフォルトのConFiGuration Authorization Modifierでは、セキュアなネットワークの外部からのリクエストに対して、すべてのページの編集機能やカスタマイズ機能が無効になっています。

cfgampev.pkb

ConFiGuration Authorization Modifier for Page Edit and Viewでは、セキュアなネットワークの外部に対して個々のページを保護できます。つまり、セキュアなネットワーク環境の外部からのリクエストに対しては、特定のページの表示および編集を許可しない機能です。

cfgamno.pkb

Authorization Modifierを無効にしてデフォルトの状態に戻します。

Modifierパッケージは、ORACLE_HOME\upgrade\portal\admin\plsql\wwcディレクトリにあります。

このパッケージを使用するには、次の手順を実行します。

1. SQL*Plusを使用して、所有者としてOracle Portalスキーマに接続します。

2. 必要なパッケージ本体のスクリプト・ファイルを実行して、現在インストールされているAuthorization Modifierを上書きします。

7.1.5.2 デフォルトのAuthorization Modifier

このAuthorization Modifierパッケージの実装では、前述のORA_EXT_REQ CGI環境変数が存在するかどうかによって、リクエストを受信したサーバーが誰にでもアクセス可能なサーバーであるかどうかを認識します。そのようなサーバーで受信したリクエストは、セキュアなネットワーク環境の外部にあるものと見なします。Authorizationパッケージでコンパイルしたネットワーク外部からのリクエストは、編集リクエストを含め、すべて自動的に無効となります。つまり、カスタマイズおよび編集のリンクはすべてページから削除され、直接編集のURL参照はどれも許可されません。

7.1.5.3 ページの表示と編集に関するAuthorization Modifier

この実装では次の内容を扱います。

7.1.5.3.1 特定のページの保護

より厳密なAuthorization Modifier (cfgampev)でも、CGI変数を使用して外部リクエストを判別します。ただし、この場合は、定義済のページ・メタデータと組み合せて、カスタムのページ属性としてそれを使用することで、目的とする内部と外部のセキュリティをポータル内のページの一部にのみ配置します。このように、特定のページに対する外部からの表示および編集を可能にする権限は、表示や編集に対する名前付き属性が当該のページに定義されているかどうかによって決まります。

7.1.5.3.2 特定のページにおける外部からの表示防止

ページを外部から表示できるかどうかは、カスタム属性isViewRestrictedで決まります。カスタム・ページ・テンプレートを使用してページ記述の一部として定義したこの属性の設定によって、ページの表示が可能かどうかが動的に決まります。この属性をOnに設定すると外部からはページを表示できなくなり、Off(デフォルト値)に設定すると外部からでも表示できるようになります。このルールが有効になっている場合は、エンド・ユーザーから見ると、ページを参照するリンクはすべて削除され、ページに対する直接のURLアクセス(ブラウザのブックマークなど)は不可能になります。

7.1.5.3.3 特定のページに対する外部からの編集およびカスタマイズの防止

同様に、もう1つの名前付き属性であるisEditRestrictedによって、特定のページがセキュアなネットワークの外部から編集できるかどうかが決まります。これは、すべてのeditWhenを実行する機能をグローバルでオフにするDefault Modifierとは異なります。この属性値をOnに設定すると、ページの編集機能とカスタマイズ機能は無効となり、Offに設定すると外部からでも編集できるようになります。この属性を設定すると、ページ・レベルで編集リンクが削除されるだけでなく、Portalにあるどのページでも、page.ファンクションに埋め込んだポートレットの編集機能やカスタマイズ機能が無効になります。

7.1.5.4 Authorization Modifiersで使用する必要なページ属性の定義

現在、前述の属性は標準ページ・メタデータに含まれていませんが、拡張可能なページ・モデルを使用すると、これらの属性を「カスタム属性」としてページ定義に追加できます。内部と外部の保護可能ページの基礎として使用するカスタム・ページ・タイプを作成することで、ページ設計者は、ページを内部で保護するか、セキュアなネットワークの内外からアクセス可能にするかを宣言によって定義できます。次の項では、前述のAuthorization Modifier機能でページを保護するために使用する適切なページ・タイプの作成手順について説明します。

1. Oracle Portalにログインします。

2. 「Portalビルダー」ページで「ナビゲータ」を選択します。

3. 「Portalナビゲータ」ページの「ページ・グループ」タブで「共有オブジェクト」を選択して、「カスタム属性」および「ページ・タイプ」を定義します。これらのプロパティは、有効範囲を特定のページ・グループに限定したオブジェクトとしてではなく、複数のページ・グループで再利用できるように共有オブジェクトとして定義することをお薦めします。

図7-3 共有オブジェクト

4. 「共有オブジェクト」ページで「属性」を選択します。

5. 「属性」ページで、「新規作成」→「属性」を選択して、次のように入力します。

- 表示名: 必要な機能に応じて、「isViewRestricted」または「isEditRestricted」と入力します。Authorization Modifierのルールでは大文字と小文字が区別されるので、属性名を入力する際は特に注意してください。

- 「データ型」を「BOOLEAN」に設定します。

図7-4 属性の作成

6. 「作成」をクリックします。

7. 「isViewRestricted」リンクをクリックして、属性を編集します。

8. 「属性の編集」ページで「翻訳を使用可能にする」を選択します。

9. 「適用」をクリックします。

10. 「OK」をクリックします。

必要なカスタム属性を定義した後、それをページのメタデータに記述する必要があります。そのためには、次の手順を実行します。

1. 「共有オブジェクト」で「ページ・タイプ」を選択します。

2. 「ページ・タイプ」ページで、「新規作成」→「ページ・タイプ」を選択し、次のように入力します。

- 表示名: 名前に「NetworkSecurablePage」と入力します。

- 基となるページ・タイプ: 「標準」を選択します。

- 「作成」をクリックします。

- 新しいページ・タイプを編集し、「属性」タブを選択して、そのページ・タイプに関連する属性を定義します。

- 「NetworkSecurablePage」リンクをクリックして、ページ・タイプを編集します。

- 「属性」タブをクリックします。

- 「属性」ページで、「使用可能な属性」リストから属性を選択して「選択した属性」リストに移動します。

- 「適用」をクリックします。

- セキュリティ要件に応じて、属性のデフォルト値を設定します。

- 「必須」チェック・ボックスを選択して、この属性が「ページ・タイプ」とページ・デザイナに表示されるようにします。
「適用」をクリックします。

図7-5 「ページ・タイプ」の編集

作成した新しいページ・タイプが公開されるようにページ・グループを構成する必要があります。そのためには、次の手順を実行します。

1. 「ページ・グループ」を選択して「プロパティ」をクリックします。

2. 「ページ・グループの編集」ページで「構成」タブをクリックします。

3. 「タイプおよび分類」で「編集」をクリックします。

4. このシナリオで作成したページを選択し、「NetworkSecurablePage」を「非表示のページ・タイプ」から「表示されるページ・タイプ」に移動して、この新しいページ・タイプが「ページ・グループ」で公開されるようにします。

図7-6 ページ・タイプ

7.1.6 Oracle Fusion Middlewareのセキュリティ・サービスの利用

Oracle Portalでは、次の方法でOracle Fusion Middlewareのセキュリティ・サービスを利用します。

- SSL暗号化

- J2EEセキュリティ

関連項目:

詳細は、次を参照してください。

- 第7.3.2.1項「Oracle PortalのSSLの構成」

- 第C.2項「外部通信のためのJAZNファイルの設定」

- Oracle Fusion Middleware Oracle Containers for Java EEサービス・ガイド

SSL暗号化

HTTPSとSecure Socket Layer (SSL)を使用すると、クライアントとサーバーとの間に安全な接続を確立できます。通信の両端で発行されるデジタル証明書によって、サーバーと通信の暗号化の妥当性が検証され、それらが脅かされていないことが確認されます。Oracle Fusion Middlewareのセキュリティ・サービスを使用してOracle PortalのSSL暗号化を実装できます。

J2EEセキュリティ

コンテナがJAZN LDAP用に構成されており、ポータルが拡張認証を使用してメッセージの整合性を保証するように構成されている場合、JPDK WebプロバイダではWLS J2EEセキュリティ・ロールを利用して認証ロジックを実装できます。

関連項目:

第7.3.1.3.2項「拡張認証」

7.1.7 Oracle Identity Managementインフラストラクチャの利用

より包括的なセキュリティ・ソリューションを実現するために、Oracle PortalではOracle Identity Managementインフラストラクチャに含まれている各種コンポーネントを利用します。

- Oracle PortalとOracleAS Single Sign-Onの関係

- Oracle PortalとOracle Access Managerの関係

- Oracle PortalとOracle Internet Directoryの関係

- Oracle PortalとOracle Directory Integration Platformの関係

- Oracle PortalとOracle Delegated Administration Servicesの関係

Oracle Portalでは、ユーザーやグループを作成するときにも、Oracle Identity Managementを利用します。ポータルのユーザーやグループの作成、およびグローバル権限や設定項目の設定に最もよく使用される方法では、次のポートレットが使用されます。

- 「ユーザー」ポートレット

- 「Portalユーザー・プロファイル」ポートレット

- 「グループ」ポートレット

- 「Portalグループ・プロファイル」ポートレット

関連項目:

Oracle Fusion Middleware Oracle Identity Managementスタート・ガイド

7.1.7.1 Oracle PortalとOracleAS Single Sign-Onの関係

Oracle Portalでは、ユーザー認証にOracleAS Single Sign-Onを使用します。

7.1.7.1.1 外部アプリケーションのサポート

OracleAS Single Sign-Onでは外部アプリケーションの概念をサポートしています。外部アプリケーションは独自の認証メカニズムを保持していますが、OracleAS Single Sign-OnではOracle Portalユーザーのログインを自動化できます。これは、シングル・サインオン・サーバーに登録されている外部アプリケーションのリストを公開する外部アプリケーション・ポートレットを提供することで実現できます。

注意:

Basic認証方式(ユーザー名とパスワード)を使用したシングル・サインオンは、ユーザーがFirefoxを使用してアクセスする外部アプリケーションで利用できます。ただし、シングル・サインオンは現在、Basic認証方式を使用する外部アプリケーションにInternet Explorer 6.xまたは7.xでアクセスしたときには利用できません。

7.1.7.1.2 Oracle Portalでのグローバル非アクティビティ・タイムアウトのサポート

OracleAS Single Sign-On Serverではグローバルな非アクティブのタイムアウトを構成できます。この機能を使用するには、インフラストラクチャ層でOracleAS Single Sign-Onサーバーを構成し、Oracle Fusion Middlewareの中間層でmod_ossoを構成する必要があります。

- OracleAS Single Sign-On server 10.1.2.xを使用するOracle Portal 11gでのグローバルな非アクティブのタイムアウトの構成の詳細は、Oracle Application Server Single Sign-On管理者ガイドを参照してください。

- OracleAS Single Sign-On server 10.1.4.3を使用するOracle Portal 11gでグローバルな非アクティブのタイムアウトを構成するには、次のようにします。

注意:

ここで説明する例はすべてUNIXのコードおよびディレクトリ・パスを使用しています。Windowsの場合は、円記号(\)を使用し、ssoreg.shをssoreg.batに置き換えてください。

1. ssogito.sqlスクリプトを実行します。これは、ORACLE_HOME/sso/admin/plsql/ssoにあります。
フィールドのリストが表示されます。

- timeout_cookie_domainの値を入力フィールドに、Oracle PortalおよびSingle Sign-Onがインストールされたドメインの名前を入力します(例: timeout_cookie_domainの値を入力: acme.org)。

- 非アクティブなタイムアウト値を入力フィールドに、必要な非アクティブ期間の長さを分単位で入力します(例: 非アクティブなタイムアウト値を入力: 15)

- new_git_versionの値を入力フィールドに、値v3.0を設定します。

2. 次のコマンドを実行して、OracleAS Single Sign-OnサーバーにMOD_OSSOを登録します。

/app/oracle/product/sso10143/sso/bin/ssoreg.sh -oracle_home_path /app/oracle/product/sso10143 -site_name ssoacme.org:7777 -config_mod_osso TRUE -mod_osso_url http://sso.acme.org -config_file /app/oracle/product/sso10143/Apache/Apache/conf/osso/osso.conf

3. mod_osso.confファイルを編集してOssoIdleTimeoutパラメータをオンにします。このファイルは次の例のようにORACLE_HOME/Apache/Apache/confにあります。

<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout on
OssoConfigFile  /app/oracle/product/sso10143/Apache/Apache/conf/osso/osso.conf

4. OC4J_SECURITYとOracle HTTP_Serverの両方を再起動します。

/app/oracle/product/sso10143/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
/app/oracle/product/sso10143/opmn/bin/opmnctl restartproc process-type=HTTP_Server

5. OracleAS SIngle Sign-Onサーバーで、グローバルな非アクティブのタイムアウトをテストします。

1. http://sso.acme.org:7777/oiddasに移動します。

2. orcladminとしてログインして、20分待ちます。

3. サーバーから再度認証を求められるかどうかを確認します。

6. PortalサーバーのMOD_OSSOを登録します。

ORACLE_HOME/sso/bin/ssoreg.sh
-oracle_home_path $ORACLE_HOME
-site_name www.acme.org:8090
-config_mod_osso TRUE
-mod_osso_url http://www.acme.org:8090
-remote_midtier
-config_file /app/oracle/product/Middleware_Portal/asinst_1/config/OHS/ohs1/osso.conf

7. mod_osso.confファイルを編集してOssoIdleTimeoutパラメータをオンにします。このファイルは次の例に示されるようにORACLE_INSTANCE/config/OHS/ohs1/moduleconfにあります。

<IfModule mod_osso.c>
OssoIpCheck off
OssoSecureCookies off
OssoIdleTimeout on
OssoConfigFile osso.conf

8. Portalの中間層からHTTP Serverを再起動します。

/app/oracle/product/Middleware_Portal/asinst_1/bin/opmnctl restartproc process-type=OHS

9. Portalの中間層でグローバルな非アクティブのタイムアウトをテストします。

1. http://www.acme.org:8090/portal/pls/portalに移動します。

2. orcladminとしてログインして、20分待ちます。

3. サーバーから再度認証を求められるかどうかを確認します。

7.1.7.2 Oracle PortalとOracle Access Managerの関係

Oracle Access Managerは、Oracle Fusion Middlewareのコンポーネントの1つです。OracleAS Single Sign-On 10gのかわりに使用して、集中認証、ポリシーベースの認可、委任管理などを実装できます。

OracleAS Single Sign-On 10gからOracle Access Manager 11gへのアップグレード

OracleAS Single Sign-On 10gからOracle Access Manager 11gへのアップグレードにはOracle Fusion Middleware Upgrade Assistantを使用できます。

注意:

Oracle Access Manager 11gにアップグレードすると、SSOサーバー管理ポートレットからは外部アプリケーションの作成、管理およびアクセスを実行できなくなります。ポートレットでリンクのいずれかをクリックすると、エラーが発生します。

アップグレード・プロセス時に外部アプリケーションが検出された場合、Upgrade Assistantには、アップグレードを中止するオプションが表示されます。処理の続行を選択すると、OAMへのアップグレード後に外部アプリケーションが機能しなくなり、外部アプリケーションの作成や管理はできなくなります。

Oracle Access Manager 11gへのアップグレードの詳細は、 Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイドの「Oracle Single Sign-On環境のアップグレード」の章を参照してください。このドキュメントでは、Oracle Access Manager 11gへのアップグレード後にOracle Delegated Administration Servicesを引続き使用するかどうかに応じて実行する必要のあるアップグレード・パスを説明しています。

7.1.7.3 Oracle PortalとOracle Internet Directoryの関係

Oracle Internet Directory (OID)は、スケーラブルなOracle固有のLDAPバージョン3のサービスで、Oracleの一般的なユーザーIDをホストします。Oracle Portalは、OIDに対して問合せを行い、ユーザーの権限、およびユーザーがOracle Portalで何を表示し、実行できるのかを確認します。特に、Oracle Portalは、OIDからユーザーのグループ・メンバーシップを取得して、ユーザーが何にアクセスし、変更できるのかを確認します。

このモデルでは、Oracle Portalに次のようなOracle Internet Directoryとの対話が必要となります。

- ディレクトリに格納されているOracle Portal固有のエントリ

- ディレクトリに格納されているグループ属性

- ディレクトリに格納されているユーザー属性

- ディレクトリからのユーザーおよびグループ情報のキャッシュ

- Oracle Delegated Administration Servicesによるディレクトリからのユーザーとグループの値リストの生成

Oracle Portalは、Oracle Internet Directoryの機能を使用してユーザーとグループを効率的に管理します。Oracle Internet Directoryが提供する機能の一覧は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「Oracle Internet Directoryの新機能」を参照してください。ただし、Oracle Internet Directoryの一部の機能は、Oracle Portalでは使用できません。

表7-12は、Oracle PortalでサポートされていないOracle Internet Directoryの機能とその説明です。

表7-12 Oracle PortalでサポートされていないOracle Internet Directoryの機能

機能

説明

動的グループ

動的グループのメンバーシップは、指定した属性値およびアサーションに基づいて、動的に計算されます。動的グループに対してはWebキャッシュの無効化を行うタイミングを特定できないため、動的グループで保護されているページは、有効期限ベースのキャッシュを使用するか、またはキャッシュを使用しないようにする必要があります。

Single Authentication Security Layer (SASL)

SASLは、接続ベースのプロトコルに認証サポートを追加するための手段です。Oracle Internet DirectoryサーバーはSASLベースの認証メカニズムをサポートしています。しかし現在のところ、Oracle Portalが使用するDBMS_LDAPパッケージはこれらのメカニズムをサポートしていません。

クライアント側の参照キャッシュ

パフォーマンスを向上させるため、APIを使用してクライアント側にキャッシュされた参照エントリをキャッシュできます。現在のところ、Oracle Portalが使用するDBMS_LDAPパッケージは、クライアント側の参照キャッシュをサポートしていません。

7.1.7.3.1 Oracle PortalのOracle Internet Directoryにあるディレクトリ・エントリ

セキュリティを正しく機能させるには、Oracle Portalのディレクトリのディレクトリ情報ツリー(DIT)構造内に次のエントリが必要です。

- デフォルト・ユーザー・アカウント (cn=PUBLIC, cn=orcladmin)。ID管理レルムのユーザー・ベース(cn=Users,dc=MyCompany,dc=com脚注 1 )に作成されます。orcladminユーザーは、ポータルのインストールおよび構成時に、デフォルトでDBAグループに追加されます。PUBLICユーザーは、認証されていないユーザー用に作成されます。通常、PUBLICユーザー・エントリは、どのユーザーでもアクセスできる(制限されていない)ポータル・コンテンツを表示する権限を付与するためのものです。

- グループ・コンテナ 。ID管理レルムのグループ・ベース(cn=Groups,dc=MyCompany,dc=com^1)内に作成されます。Oracle Portalでは、ディレクトリ内のどのグループも利用できますが、グループがOracle Portalグループ・コンテナ内にあると、より簡単にアクセスして値リストに表示できます。
グループ・コンテナの名前は、Oracle Portalの情報に基づいています。

- Oracle Portalスキーマ名

- Oracle Portalがインフラストラクチャ・サービスの使用を開始した日時

名前の書式は次のとおりです。

schema_name.yymmdd.hh24miss.ff

注意:

Oracle Portal 10g リリース1より前のリリースでは、グループ・コンテナの名前の書式が異なる場合があります。

- グループ。ディレクトリのOracle Portalグループ・コンテナ内に作成されます。

- cn=AUTHENTICATED_USERS

- cn=DBA

- cn=PORTAL_ADMINISTRATORS

- cn=PORTAL_DEVELOPERS

- cn=PORTLET_PUBLISHERS

- cn=RW_ADMINISTRATOR

- cn=RW_DEVELOPER

- cn=RW_POWER_USER

- cn=RW_BASIC_USER

- アプリケーション・エンティティ(orclApplicationCommonName=application_name)。ルートのOracleコンテキスト(cn=Portal,cn=Products,cn=OracleContext)に作成されます。アプリケーションのパスワードはランダムに生成されます。Oracle Portalでは、ディレクトリへの問合せやディレクトリに対する操作(ユーザーの追加など)をユーザーにかわって行う必要があるときに、このエンティティを使用してディレクトリにバインドします。Oracle Portalがユーザーにかわってディレクトリにバインドするときは、プロキシ接続を使用してユーザーとして接続します。この方法により、ユーザーの認可制限がディレクトリによって正しく適用されていることが確認されます。Oracle Portalのアプリケーション・エンティティは、ユーザーのプロキシ権限グループ(cn=UserProxyPrivilege,cn=Groups,cn=OracleContext)内のメンバーシップによって、プロキシ接続を開始するための権限を取得します。アプリケーション・エンティティの名前は、スキーマと、Oracle Portalがインフラストラクチャ・サービスの使用を開始した日時に基づいています。たとえば、アプリケーション・エンティティの名前がportal.040820.123756.096286000であるとすると、portalはスキーマ名であり、040820.123756.096286000はyymmdd.hh24miss.ffという書式のタイムスタンプです。

- ディレクトリ同期サブスクリプション。プロビジョニング・プロファイルのエントリは、ディレクトリ(cn=Provisioning Profile,cn=changelog subscriber,cn=oracle internet directory)のプロビジョニング・プロファイル・ノードに作成されます。このエントリは、ユーザーまたはグループの権限情報が変更されたときにディレクトリからOracle Portalに通知する必要があることを示します。このエントリによって、Oracle Portalではユーザーの認可とディレクトリに格納されている情報を同期化できます。

注意:

Oracle Internet Directoryからプロビジョニング・プロファイルを削除すると、「グローバル設定」ページの「SSO/OID」タブにある「ディレクトリ同期」セクションから、「ディレクトリ同期の有効化」とイベント通知の送信頻度n秒が表示されなくなります。「グローバル設定」ページに移動するには、「Portalビルダー」で、「管理」タブの「ポータル」サブタブに移動し、「サービス」ポートレットの「グローバル設定」リンクをクリックします。

図7-7は、Oracle Portalの情報がディレクトリのDIT構造のどこにあるかを示しています。

図7-7 Oracle PortalのDIT構造

cn=Groups,cn=OracleContext,<subscriber_dn>の下に、次のグループを含むcn=Groupsコンテナがあります。

authenticationServices
userProxyPrivilege
iasadmins
OracleDASCreateUser
OracleDASEditGroup
OracleDASCreateGroup
OracleDASEditUser
OracleDASDeleteUser
OracleDASUserPriv
OracleUserSecurityAdmins
OracleDASDeleteGroup
OracleDASGroupPriv
OracleDASConfiguration

これらの権限グループのエントリは、そのメンバーシップにポータル・グループとポータル・アプリケーション・エントリを追加するよう、ポータルのインストール時に変更されます。これにより、目的のポータル機能が実現します。同様に、ポータル情報もこれらのグループに含まれます。

7.1.7.3.2 Oracle Internet Directoryに格納されているユーザー属性

Oracle Portalは、Oracle Fusion Middlewareの他のすべてのコンポーネントと同様に、ディレクトリを使用して、ユーザー情報を格納しています。ディレクトリ内のユーザーはすべて、次のオブジェクト・クラスを使用して定義されます。

- inetOrgPersonオブジェクト・クラスには、Internet Engineering Task Force (IETF)のRequest for Comments (RFC) 2798番によって定義されているユーザー属性がすべて含まれています。

- orclUserおよびorclUserV2オブジェクト・クラスには、Oracle製品のその他の標準属性のセットが含まれています。

次の表は、Oracle Internet Directoryに格納されている様々なユーザー属性を示しています。

表7-13 inetOrgPersonの属性

inetOrgPerson (IETF)の属性

コメント

cn

ユーザーの共通名。

この属性は必須です。

employeeNumber

従業員の識別に使用される番号。

sn

姓。この属性は必須です。この属性を明示的に指定しない場合は、ユーザーのニックネームが使用されます。

givenName

名。

middleName

displayName

優先名。

mail

電子メール・アドレス。

telephoneNumber

homePhone

mobile

pager

facsimileTelephoneNumber

street

l

オフィスの所在地(市)。

st

オフィスの所在地(州)。

postalCode

オフィスの郵便番号。

c

オフィスの所在地(国)。

homePostalAddress

自宅の住所。

jpegPhoto

本人の画像。

o

組織

title

manager

従業員の監督者。

uid

ユーザーID。

userPassword

preferredLanguage

表7-14 orclUserV2の属性

orclUserv2の属性

コメント

orclIsVisible

ユーザーを管理者以外の全員に対して非表示にするかどうかを示すフラグ。

orclDisplayPersonalInfo

ユーザーの個人情報を管理者以外の全員に対して非表示にするかどうかを示すフラグ。

orclMaidenName

orclDateOfBirth

orclHireDate

orclDefaultProfileGroup

本人のデフォルト・ユーザー・グループ。

orclActiveStartDate

アカウントが有効になった日付。

orclActiveEndDate

アカウントが終了した(または終了する)日付。

orclTimeZone

orclIsEnabled

ユーザー・アカウントがアクティブかどうかを示すフラグ。アクティブでない場合、ユーザーはログインできません。

7.1.7.3.3 Oracle Internet Directoryに格納されているグループ属性

Oracle Portalは、Oracle Fusion Middlewareの他のすべてのコンポーネントと同様に、ディレクトリを使用して、グループ情報を格納しています。ディレクトリ内のグループはすべて、次のオブジェクト・クラスを使用して定義されます。

- groupOfUniqueNamesオブジェクト・クラスには、IETF (RFC 2256)によって定義されているグループ属性がすべて含まれています。

- orclGroupオブジェクト・クラスには、Oracle Portalのその他の標準属性のセットが含まれています。

注意:

Oracle Portalリリース9.0.2以上では、グループの適用範囲を特定のページ・グループにすることはできません。このオプションは、Oracle Portalリリース3.0.9.x以下でのみ有効でした。

図7-8は、Oracle Portalのグループ情報がディレクトリのDIT構造のどこにあるかを示しています。

図7-8 Oracle PortalグループのDIT構造

次の表は、Oracle Internet Directoryに格納されている様々なグループ属性を示しています。

表7-15 groupOfUniqueNames/groupOfNamesの属性

groupOfUniqueNames/groupOfNames (IETF)の属性

コメント

cn

グループの共通名。「グループ」ポートレットの「グループの編集」フィールドのような場所に入力してグループを見つけることができます。

description

グループの説明。そのグループが表示されている値リストに表示されます。

uniqueMember/member

グループのすべてのメンバーの識別名(DN)のリスト。メンバーのDNは、ユーザーまたは別のグループを表します。

owner

このグループを管理する権限を持っているすべてのユーザーおよびグループのDNのリスト。

表7-16 orclGroupの属性

orclGroupの属性

コメント

orclGUID

このグループのグローバル一意識別子(GUID)。

orclIsVisible

グループがパブリックかプライベートかを示すフラグ。プライベート・グループは、その所有者の値リストにしか表示されません。他のユーザーはそれらを表示できません。

7.1.7.3.4 Oracle PortalでのOracle Internet Directoryのキャッシュ

パフォーマンスを向上させるために、Oracle Portalでは一部のディレクトリ情報をローカルにキャッシュします。特に、Oracle Portalでは次の情報をキャッシュします。

- Oracle Portalのディレクトリ接続情報

- Oracle Delegated Administration ServicesのURL

- ディレクトリのポートレット(「ユーザー」および「グループ」ポートレットなど)に対する認可チェックのための特定の権限グループのorclGUID

- 一部のOracleコンテキスト情報

- ローカルで選択したグループの検索および作成ベース

- 各ユーザーのグループ・メンバーシップおよびデフォルト・グループ

Oracle Portalによってキャッシュされる情報のほとんどは、ディレクトリ接続情報などの静的な情報です。Oracle Portalでは、グループ・メンバーシップやデフォルト・グループなどのより動的なアイテムの更新は、Oracle Directory Integration and Provisioningエージェントに依存しています。Oracle Portalでは、ディレクトリ同期サブスクリプションがディレクトリ内で管理されていて、Oracle Portalのセキュリティに影響する変更イベント(グループにユーザーを追加する、グループからユーザーを削除するなど)が発生した場合には、エージェントにフラグを設定して通知します。

7.1.7.3.5 Oracle Portalでのユーザーとグループの値リスト

「ユーザー」、「グループ」、「Portalユーザー・プロファイル」、「Portalグループ・プロファイル」の各ポートレットには、ユーザーまたはグループの値リストが含まれています。これらの値リストには、ディレクトリに格納されている情報を設定する必要があります。デフォルトでは、値リストにはOracle PortalのDIT構造のOracle Portalグループ・コンテナに含まれるグループが表示されます。正しいアクセス権限があれば、ツリー内のどのグループでも参照することができます。

グループの値リストに表示されるグループは、それらを表示するユーザーの権限によって異なります。たとえば、ユーザーが「グループ」ポートレットから値リストを表示すると、そのユーザーが編集または削除できるグループのみがリストに表示されます。Oracle Portal 10g リリース2 (10.1.2)以降では、LOVを実装すると、コールバック・メソッドをサポートできます。このコールバック・メカニズムは、Oracle Delegated Administration Services環境での対応するサポートを必要とします。

Oracle Portal 10g リリース2 (10.1.2)より前のバージョンからアップグレードし、インフラストラクチャ層とFusion Middleware中間層を別々のホストやプロトコルに切り離している場合、追加のユーザーとグループの値リスト(LOV)構成を実行して、JavaScriptオリジン・サーバーのセキュリティ・ポリシーを取り込んでいる可能性があります。

次の2つの構成オプションがあります。

- secjsdom.sqlスクリプトの実行による共通ドメインの設定

- Oracle Delegated Administration Servicesの中間層への配置

ご使用の環境に適したOracle Delegated Administration Servicesのバージョンをインストールし、前述の構成オプションをまだ使用していない場合、Oracle Portalでは、別のホストのLOVをサポートするために後続の構成手順は不要です。ただし、前述の構成オプションを使用した場合は、これらの手順を削除する必要があります。これは、次のように行うことができます。

1. Oracle Portalを構成して、ローカルに配置されたOracle Delegated Administration Servicesサーブレットを使用するようにした場合は、次のとおりsecdaslc.sqlスクリプトを実行して、インフラストラクチャ層を指すように再構成します。

1. オペレーティング・システムのプロンプトから、次のディレクトリに移動します。

ORACLE_HOME\portal\admin\plsql\wwc

2. SQL*Plusを使用して、所有者としてOracle Portalスキーマに接続し、次のコマンドを実行します。

@secdaslc N
commit;

Oracle Portalをコールバック・メソッドをサポートしない前のリリースのOracle Delegated Administration Servicesとともに使用し、ディレクトリとOracle Portalサーバーが別のドメインに常駐している場合、Oracle Delegated Administration Services環境に必要なパッチをインストールして、ドメイン全体でLOVを使用できるようにする必要があります。

7.1.7.4 Oracle PortalとOracle Directory Integration Platformの関係

図7-9に示すように、Oracle Directory Integration Platformには、コンポーネントにユーザーやグループの変更イベントを通知して、ディレクトリを同期化するための重要なサービスがいくつかあります。

図7-9 Oracle Directory Integration Platformの同期化

この図では、Oracle Internet Directoryに対するフローに2つのパスがあります。最初のパスは、Oracle Directory Synchronization Serviceと呼ばれており、同期化の概念を示しています。この場合、Oracle Internet Directoryは一部の外部ディレクトリまたはリポジトリへのゲートウェイとして機能します。同期化サービスでは、変更内容がOracle Internet Directoryとそれに接続されているディレクトリとの間で確実に調整されるようにします。いずれかのディレクトリで変更が行われるたびに、Oracle Internet Directoryで通知が発行され、影響を受けるすべてのディレクトリに変更が適切に反映されるようにする必要があります。

2番目のパスは、Oracle Directory Provisioning Integration Serviceと呼ばれており、プロビジョニングの概念を示しています。プロビジョニングでは、Oracle Portalなどのアプリケーションは特定のユーザーまたはグループ情報に対する変更をサブスクライブします。たとえば、管理者がOracle Delegated Administration Servicesを使用してグループからユーザーを削除したとします。この変更の結果、そのユーザーはOracle Portalの特定のページにアクセスできなくなります。Oracle Directory Integration Platformでは、Oracle Portalに、ローカル・キャッシュを更新するように通知して、ユーザーがアクセスできなくなったページにアクセスするのを速やかに防ぐ必要があります。

プロビジョニング・サービスの場合、Oracle Portalなどのコンポーネントは、ユーザーやグループ情報のローカル・キャッシュをOracle Internet Directoryの中央のユーザーやグループのリポジトリと同期化するために、プロビジョニング・イベント(グループの削除など)をサブスクライブします。変更イベントが発生すると、その変更イベントをサブスクライブするコンポーネントはすべて、Oracle Directory Integration Platformのディレクトリ同期プロビジョニング・エージェントによって通知されます。Oracle Portalでは、ディレクトリ内にポータル・ディレクトリ同期サブスクリプションのフラグを設定して、サブスクライブされた変更イベントが実行されるたびに通知されるようにします。表7-17は、Oracle Portalがサブスクライブするイベントとそれらのイベントが発生したときに実行される処理を示しています。

表7-17 Oracle Portalによって処理されるディレクトリ同期イベント

サブスクライブされたイベント

Oracle Portalの処理

USER DELETE

ローカルのユーザー・プロファイル・エントリが削除され、結果的にそのユーザーの権限も削除されます。このユーザーに関連付けられているページがOracle Web Cacheで無効化されます。

USER MODIFY

(orclDefaultProfileGroup)

ユーザーのデフォルト・グループがローカルのユーザー・プロファイルで変更されます。

GROUP DELETE

ローカルのグループ・プロファイルが削除され、結果的にこのグループに割り当てられている権限も削除されます。「グローバル設定」の「SSO/OID」タブで即時同期化が有効の場合、それに応じて、WWSEC_FLAT$表が更新されます。

GROUP MODIFY

(uniqueMember, member)

「グローバル設定」の「SSO/OID」タブで即時同期化が有効の場合、WWSEC_FLAT$表が更新されて、Oracle Portalに影響を及ぼすメンバーシップの変更が反映されます。

メンバーシップの変更に伴い、変更したグループに対してグループが追加または削除される場合は、追加または削除されたグループのユーザーに関連付けられているページがOracle Web Cacheで無効化されます。この処理が行われるのは、セキュリティの変更がページに表示される内容やページそのもののアクセス権限に影響を及ぼすことがあるからです。

注意:

Oracle Portalでは、ユーザーやグループの作成イベントをサブスクライブする必要はありません。新しいユーザーが初めてログインするか、新しいユーザーになんらかの権限を初めて割り当てることによって、そのユーザーがOracle Portalのアクセス制御リスト(ACL)で参照されると、ローカルのユーザー・プロファイルが自動的に作成されます。同様に、新しいグループが初めてACLで参照されると、ローカルのグループ・プロファイルが自動的に作成されます。

正しく機能させるには、次の要件に従ってOracle PortalとOracle Directory Integration Platformを統合する必要があります。

- Oracle Directory Integration Platformが動作していること。Oracle Portalリリース11.0.0以上では、opmctl start allを使用してインフラストラクチャ層を起動した場合、Oracle Directory Integration and Provisioningのエージェントもデフォルトで開始されます。Oracle Directory Integration Platformを起動するには、oidctlコマンドを実行します。例:

oidctl instance=1 server=odisrv flags="host=iasqa-ultra1.abc.com port=4032" start

- サブスクリプション・プロファイルがOracle Internet Directory内に作成されていること。デフォルトのサブスクリプション・プロファイルは、Oracle Portalのインストール中に自動的に作成されます。

関連項目:

Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

7.1.7.4.1 groupOfNamesベースのグループのサブスクリプション・プロファイルの更新

デフォルトでは、Oracle Delegated Administration ServicesによってOracle Internet Directory内に作成されたグループは、IETFオブジェクト・クラスgroupOfUniqueNamesを基にしています。ただし、現在はオブジェクト・クラスgroupOfNamesで作成されたグループの処理もサポートしています。ポータルで、既存のOracle Directory Integration Platformのサブスクリプション・プロファイルがOracle Internet Directory (9.0.2以降)に存在する場合は、groupOfUniqueNamesを使用するグループに基づいてグループの変更や削除がサブスクライブされています。Oracle Internet Directoryに格納されている既存のグループがgroupOfNamesオブジェクト・クラスを基にしている場合は、groupOfUniqueNamesの他にgroupOfNamesを基にしたグループのイベントもサブスクライブするようOracle Directory Integration Platformのサブスクリプション・プロファイルを更新する必要があります。

サブスクリプション・プロファイルを作成または更新するには、次の例に示すように次のようにoidprovtoolを実行します。

oidprovtool operation=create ldap_host=myhost.mycompany.com \
ldap_port=389 \
ldap_user_dn="cn=orcladmin" \
application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext"\
organization_dn="dc=us,dc=mycompany,dc=com" \
interface_name=PORTAL.WWSEC_OID_SYNC \
interface_type=PLSQL \
interface_connect_info=myhost:1521:iasdb:PORTAL:password\schedule=360 \
event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE"\
event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY (orclDefaultProfileGroup,userpassword)"\
eventsubscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
profile_mode=OUTBOUND

これにより、プロビジョニング・プロファイルが作成または更新され、uniqueMemberおよびmember属性の変更がサブスクライブされます。デフォルトでは、このプロビジョニング・プロファイルが有効化されます。

7.1.7.5 Oracle PortalとOracle Delegated Administration Servicesの関係

Oracle Portalでは、ディレクトリに対してユーザーおよびグループ情報を問い合せるだけでなく、ユーザーおよびグループ情報を追加および変更する方法をユーザーに提供する必要があります。ディレクトリ内の情報を変更するには、Oracle Delegated Administration Servicesを使用します。Oracle Portalは、ユーザーやグループを追加および変更する権限を持つユーザーに対して委任管理サーバーへのリンクを提供します。

7.1.7.5.1 Oracle Internet Directoryに格納されている情報の作成と更新

Oracle Delegated Administration Servicesには、ディレクトリを更新するための包括的なインタフェースが用意されています。適切な権限を持っている認証されたユーザーは、Oracle Portalの「管理」タブの「ユーザー」および「グループ」ポートレットを使用して委任管理サーバーにアクセスできます。これらのポートレットにアクセスするには、それぞれOracleDASCreateUserおよびOracleDASCreateGroupグループのメンバーである必要があります。AUTHENTICATED_USERSは、デフォルトでグループを作成できます。

7.1.7.5.2 Oracle Delegated Administration Services、mod_ossoおよびOracleAS Single Sign-Onの関係

mod_ossoは、HTTPサーバーを事実上パートナ・アプリケーションにすることによって、OracleAS Single Sign-On環境の内側にあるURLを保護します。Oracle Delegated Administration Servicesの機能は、mod_ossoを使用してOracleAS Single Sign-OnセッションからユーザーのIDを取得することによってシングル・サインオン対応になります。

図7-10 Oracle Delegated Administration Services、mod_ossoおよびOracleAS Single Sign-Onの関係

mod_ossoは、Oracle HTTP Serverのモジュールであり、パートナ・アプリケーションとして作成されています。mod_ossoを使用すると、WLSアプリケーション上のアプリケーションでシングル・サインオンを使用できるようになります。このためには、Oracle HTTP Serverのディレクティブでmod_ossoを構成して、Oracle Fusion MiddlewareアプリケーションのURLへのアクセスを制限します。

Oracle Delegated Administration Servicesでは、アクセスを試みるユーザーの認証にmod_ossoを利用します。ユーザーがOracle Delegated Administration Servicesのダイアログ(ユーザーまたはグループのリスト、「ユーザーの作成」フォームなど)にアクセスしようとすると、mod_ossoによってユーザーが認証されているかどうかが確認されます。mod_ossoでは、認証を確認する以外の認可チェックは行いません。ユーザーが認証されていない場合は、mod_osso (OracleAS Single Sign-Onのパートナ・アプリケーション)によってユーザーのリクエストがOracleAS Single Sign-Onにリダイレクトされます。OracleAS Single Sign-Onでは、次のいずれかを実行します。

- ユーザーが正しく認証されたことを示すCookieを見つけ、認証済のトークンをmod_ossoに返信します。

- Cookieがまだ1つも作成されていない場合は、ユーザーを認証するためのログイン・ページを表示します。

正しく認証されたユーザーは、mod_ossoによって、リクエストされたOracle Delegated Administration ServicesのURLにリダイレクトされます。これで、そのユーザーはOracle Delegated Administration Servicesにアクセスできるようになり、通常はOracle Internet Directory内のアクセス制御項目に応じてユーザーの権限が適用されます。

Oracle Delegated Administration ServicesのURL

Oracle Portalのユーザー・セッションからOracle Delegated Administration Servicesに送信された最初のリクエストはOracleAS Single Sign-Onにリダイレクトされ、mod_ossoがパートナ・アプリケーションとしてOracle Delegated Administration ServicesのかわりにユーザーのIDを確立します。OracleAS Single Sign-Onは、リクエストされたOracle Delegated Administration ServicesのURLを含むURLCトークンを作成します。URLCトークンの長さは、Internet Explorerによって約2Kに制限されます。同様に、Oracle Delegated Administration ServicesのURLの長さも制限されます。Oracle Portalは、Oracle Delegated Administration Servicesとシームレスに統合できるように、現在のポータル・ページとポータル・ホーム・ページのURLをこのOracle Delegated Administration ServicesのURL内に含めます。Oracle Delegated Administration Servicesの標準的なURLを次に示します。

http://myportal.us.abc.com:8090/oiddas/ui/oracle/ldap/das/group/AppCreateGroupInfo
Admin?doneURL=https%3A%2F%2Fwebsvr.us.abc.com%3A5001%2Fportal%2Fpage%3F_
pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2_
6_7&homeURL=https%3A%2F%2Fwebserver.us.abc.com%3A5001%2Fportal%2Fpage%3F_
pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2
_6_7&parentDN=cn%3Dportal_9_0_2_6_
7.s901dev0.portalserver.us.abc.com%2Ccn%3Dgroups%2Cdc%3Dus%2Cdc%3Doracle%2Cdc%3Dco
m&enablePA=true

このURLが、URLCトークンに含まれ、セキュリティ上の理由から暗号化された場合、最終的なトークンの長さは容易に2Kのしきい値に到達します。この制限を超えた場合、ブラウザにエラーが表示される可能性があります。

URLに固定サイズはありません。ただし、Oracle Delegated Administration Services操作の実行時にブラウザでエラーが発生した場合は、URLが2Kの制限を超えないようポータルURLを構成する様々な部分のサイズを短縮する必要があります。たとえば、ホスト名を8文字以下に制限したり、DAD名を6文字以下に制限します。

この問題が発生した場合の回避策は、最初に「サービス」ポートレットの「ディレクトリ管理」リンクなど、比較的短い長さのURLを通じてOracle Delegated Administration Servicesにログインすることです。これ以降のOracle Delegated Administration Servicesへのアクセスでは、SSOリダイレクトを必要としないため、正常に接続できます。

7.1.7.6 「ユーザー」ポートレット

「管理」にある「ポータル」タブの「ユーザー」ポートレットを使用すると、Oracle Delegated Administration Servicesを使用してユーザーを作成および更新できます。新しいユーザーを作成するには、「ユーザー」ポートレットの「新規ユーザーの作成」リンクをクリックします。既存のユーザーの情報を更新するには、「名前」フィールドにそのユーザー名を入力するか、値リストからそれを選択して、「編集」をクリックします。ユーザーを削除するには、「名前」フィールドにそのユーザー名を入力するか、値リストからそれを選択して、「削除」をクリックします。

注意:

OracleDASCreateUser、OracleDASEditUserまたはOracleDASDeleteUser権限グループのメンバーであるユーザーのみが「ユーザー」ポートレットを表示することができます。新しいユーザーを作成するためのリンクは、OracleDASCreateUserグループのメンバーであるユーザーにのみ表示されます。

関連項目:

Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

図7-11 「ユーザー」ポートレット

7.1.7.7 「ポータル・ユーザー・プロファイル」ポートレット

注意:

「Portalユーザー・プロファイル」ポートレットは、すべてのユーザー・プロファイルに対する「管理」または「編集」権限を持つユーザーのみが表示することができます。

特にポータルに関係するグローバル・ユーザー権限や設定項目を設定する場合は、「Portalユーザー・プロファイル」ポートレットを使用します。ポータルに関するユーザーの設定項目や権限を更新するには、「名前」フィールドにそのユーザー名を入力するか、値リストからそれを選択します。ユーザーのプロファイルに対して、次のすべての設定を行うことができます。

- プリファレンス

- ユーザーがポータルにアクセスできるかどうか

- ユーザーのデータベース・スキーマ名

- ユーザーが個人用ページを持っているかどうか

- ユーザーのデフォルト・ユーザー・グループ

- ユーザーのデフォルトのホーム・ページ

- ユーザーのデフォルト・スタイル

- ユーザーのOracle Web Cacheを消去するかどうか

- グローバル権限

- ページ・グループ権限

- Portal DBプロバイダ権限

- 管理権限

図7-12 「ポータル・ユーザー・プロファイル」ポートレット

7.1.7.8 「グループ」ポートレット

注意:

どのユーザーも「グループ」ポートレットを表示できますが、新しいグループを作成するためのリンクは、OracleDASCreateGroup権限グループのメンバーであるユーザーにのみ表示されます。ユーザーがグループを編集または削除できるのは、そのグループの所有者であるか、そのグループを編集または削除するための適切なアクセス制御情報(ACI)を持つグループのメンバーである場合のみです。次の権限グループは、Oracle Internet Directoryに組み込まれています。

- OracleDASCreateGroup

- OracleDASEditGroup

- OracleDASDeleteGroup

これらの権限グループは、グローバル権限に相当するため、慎重に割り当てる必要があります。

「管理」にある「ポータル」タブの「グループ」ポートレットを使用すると、Oracle Delegated Administration Servicesを使用してユーザー・グループを作成および更新できます。新しいグループを作成するには、「グループ」ポートレットの「新規グループの作成」リンクをクリックします。既存のグループの情報を更新するには、「名前」フィールドにその名前を入力するか、値リストからそれを選択して、「編集」をクリックします。グループを削除するには、「名前」フィールドにそのグループ名を入力するか、値リストからそれを選択して、「削除」をクリックします。

関連項目:

Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

図7-13 「グループ」ポートレット

7.1.7.9 「ポータル・グループ・プロファイル」ポートレット

注意:

「Portalグループ・プロファイル」ポートレットはすべてのユーザーに表示されますが、すべてのグループ・プロファイルに対する「管理」または「編集」権限を持つユーザー、またはグループの所有者のみがそのプロファイルを編集することができます。

特にポータルに関係するグローバルなグループの設定項目や権限を設定する場合は、「Portalグループ・プロファイル」ポートレットを使用する必要があります。ポータルに関するグループの設定項目や権限を更新するには、「名前」フィールドにそのグループ名を入力するか、値リストからそれを選択します。グループのプロファイルに対して、次のすべての設定を行うことができます。

- プリファレンス

- グループのデフォルトのホーム・ページ

- グループのデフォルト・スタイル

- グローバル権限

- ページ・グループ権限

- Portal DBの権限

- 管理権限

図7-14 「ポータル・グループ・プロファイル」ポートレット

7.1.7.10 Oracle Delegated Administration Servicesのパブリック・ロール

多くの場合、Oracle Delegated Administration Servicesに用意されているユーザー・ロールを使用したほうが、より効率的に個々のユーザーに権限を割り当てることができます。ユーザー作成時、「ユーザーの作成」ページに「ロール割当て」セクションがあります。

注意:

9.0.4より前のリリースでは、ロールはパブリック・グループと呼ばれていました。

ロールには、非常に便利なメカニズムが備えられており、それによって同時に複数のユーザーを作成し、権限のセットを付与することができます。ロールのチェック・ボックスを特定のユーザーに対して選択しておくと、そのユーザーには作成時に特定のロールが指定されます。管理者は、独自のロールを作成して、Oracle Internet DirectoryとOracle Portalの権限を組み合せてそのロールに事前に割り当てることができます。

7.1.7.10.1 例: ユーザー管理者ロールの定義

ユーザー管理者として適切な権限を持つロールを作成するとします。このようなロールは、次の手順に従って作成できます。

ステップ1: グループを作成する

まず、次のようにグループを作成します。

1. 「管理」タブをまだ表示していない場合、「Portalビルダー」(設計時のページ)で、「管理」タブをクリックします。

2. 「グループ」ポートレットの「新規グループの作成」をクリックします。図7-15に示すような「グループの作成」ページが表示されます。

図7-15 「グループの作成」ページ

3. 必須フィールド(アスタリスクで表示)を入力します。

4. 「グループの作成」ページで、「権限の割当て」をクリックしてそのセクションに移動し、図7-16に示すように、次の権限を選択します。

- ユーザーの作成を許可

- ユーザーの編集を許可

- ユーザーの削除を許可

図7-16 「グループの作成」ページの「権限の割当て」セクション

5. 「発行」をクリックします。

ステップ2: すべてのユーザー・プロファイルに対する「管理」権限を割り当てる

ユーザー管理者グループを作成したら、そのグループにすべてのユーザー・プロファイルに対する「管理」権限を割り当てる必要があります。この権限は、ユーザー管理のためにこのグループに割り当てる必要がある唯一のグローバル権限です。

1. 「管理」タブをまだ表示していない場合、「Portalビルダー」(設計時のページ)で、「管理」タブをクリックします。

2. 「Portalグループ・プロファイル」ポートレットで、新しく作成したグループの名前を入力して、「編集」をクリックします。

3. 「権限」タブをクリックします。

4. 図7-17に示すように、「管理権限」セクションが表示されるまで下方にスクロールします。「すべてのユーザー・プロファイル」の横のリストから、「管理」を選択します。

図7-17 グループのプロファイルの編集ページの「管理権限」セクション

5. 「OK」をクリックします。

ステップ3: グループをロールにする

ユーザー管理者ロールを表すグループの作成が終わったので、そのグループをロールとして有効にし、「ユーザーの作成」ページのロールのリストに表示されるようにする必要があります。

1. 「管理」タブをまだ表示していない場合、「Portalビルダー」(設計時のページ)で、「管理」タブをクリックします。

2. 「サービス」ポートレットで、「ディレクトリ管理」をクリックします。

3. 「構成」タブをクリックします。

4. 「ユーザー・エントリ」をクリックします。

5. 図7-18に示すように、ウィザードのステップ5「ロールの構成」が表示されるまで「次へ」をクリックします。

6. 「ロールの追加」をクリックして、新しいグループを選択し、それをロールのリストに追加します。

図7-18 「ロールの構成」ページ

7. 「終了」をクリックします。これで、「ユーザーの作成」ページのパブリック・グループ・リストに、作成したグループが表示されます。

ステップ4: 詳細な「権限の割当て」セクションを非表示にする

権限の直接割当てではなく、ロールの使用を推進するには、「ユーザーの作成」ページの権限の割当ての詳細セクションを無効にします。この変更を実装するには、Oracle Portalスキーマ内の構成エントリを更新する必要があります。この設定によって、Oracle Delegated Administration Servicesでは、Oracle Portal管理ページからコールされたユーザーの作成/編集ページの「権限の割当て」セクションが非表示になります。

1. SQL*Plusを介してPORTALスキーマにログインします。

注意:

PORTALスキーマのパスワードは、Oracle Internet Directoryに格納されています。このエントリは、管理者が「エントリ管理」にある次のパスのoidadminユーティリティを実行することによって表示されます。

OrclResourceName=PORTAL,orclReferenceName=iasdb.myho

st.au.oracle.com,cn=IAS Infrastructure

Databases,cn=IAS,cn=Products,cn=OracleContext

2. 次のコマンドを実行して、das_enable_pa変数をOracle PortalのOracle Internet Directory構成のプリファレンス・ストア内に設定します。

$ sqlplus
...
Enter user-name: portal
Enter password:
...
SQL> set serverout on
SQL> exec wwsec_oid.set_preference_value('das_enable_pa', 'N');

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

SQL> exit
...

3. 「ユーザー」ポートレットはOracle Web CacheだけでなくOracle Portalの中間層のファイル・システム・キャッシュにもキャッシュされるため、キャッシュされているポートレットを事前に無効にしておく必要があります。構成パラメータを更新すると、このポートレットの動作は変更されますが、パラメータを更新してもキャッシュは無効になりません。「ユーザー」ポートレットのキャッシュ・バージョンを無効にするには、次の手順を実行します。

1. 管理者権限を持つユーザーとしてOracle Portalにログインします。

2. 「ビルダー」に移動します。

3. 「管理」タブをクリックします。

4. 「ポータル」タブから、「グローバル設定」を開き、「SSO/OID」タブに移動します。

5. ページの一番下までスクロールします。

6. 「OIDパラメータ用キャッシュのリフレッシュ」を選択します。

7. 「適用」をクリックします。

関連項目:

Oracle Fusion Middleware Oracle Web Cache管理者ガイド

ステップ5: 変更内容を検証する

ステップ1から4を実行した後、「ユーザーの作成」ページを表示して、作成したユーザー管理者のグループがそこに表示されることを確認します。Oracle Portalの他の管理ロールまたはグループがどのようにしてこのページの「ロール割当て」リストに事前に生成されているのか注意してください。

7.1.8 動的グループの構成

動的グループのサポートは、動的に移入された静的グループの機能に依存します。11.1.1では、動的グループは静的グループと同様に公開されます(実際には、動的グループは、静的メンバー・リストと動的に決定されたメンバーシップから作成されます)。

グループの動的メンバーシップは、グループのlabeledURI属性に適切なLDAP問合せフィルタを設定することで定義します。問合せフィルタでは、グループのメンバーシップを定義するユーザー・セットを定義します。

注意:

labeledURI属性はDASコンソールには公開されないため、動的グループはDASで定義できません。labeledURI属性は、Oracle Directory Manager内で、またはコマンドラインからldapmodifyなどの適切なLDAPコマンドを使用して定義する必要があります。

7.1.8.1 動的グループの定義

動的グループは次の2つの方法で作成できます。

- LDIFファイルでldapaddコマンドを使用して作成する

- Oracle Directory Services Manager (ODSM)を使用して作成する

オプション1: LDIFファイルを使用した動的グループの作成

LDIFファイルを使用して動的グループを作成するには、次の手順を実行します。

1. テキスト・エディタでLDIFファイルを作成します。次の例は、デフォルトのユーザー検索ベースで役職が「Manager」のユーザーをすべて表示するように動的グループを定義する方法を示しています。

例7-1 動的グループの定義

dn: cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=orac
le,dc=com
labeleduri: ldap://myserver.mycompany.com.com:12061/cn=users,dc=us,dc=mybiz,dc=com
??sub?(title=Manager)
description: Dynamic Group of Managers
cn: Managers
orclisvisible: true
objectclass: orclDynamicGroup
objectclass: orclGroup
objectclass: top
objectclass: groupOfUniqueNames
displayname: Managers
owner: cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com

注意:

LDAPのURLのlabeledURI属性の構文は、RFC 2255 (http://www.faqs.org/rfcs/rfc2255.html)で定義します。上の例は、DN cn=users,dc=us,dc=mybiz,dc=comでtitle=Manager属性の全エントリの検索を表しています。myserver.mycompany.comサーバーのLDAPポート12061でサブツリー(sub)の検索を使用して行います。

動的グループは、LDAPのURLとして表してlabeledURI属性で定義することができるすべての属性または条件で定義できます。また動的グループは、orclDynamicGroupオブジェクト・クラスに含まれるConnectByアサーションを使用して定義することもできます。この方法の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

2. ファイルを保存し、ldapaddコマンドを発行してOIDサーバーを更新します。例:
ldapadd -h myserver -p 12061 -D cn=fmwadmin -w mybiz1 –f managers.ldif –v

add labeleduri: ldap://myserver.mycompany.com:12061/cn=users,dc=us,dc=mybiz,dc=com??sub?(title=Manager)

add description:

Dynamic Group of Managers

add cn:

Managers

add orclisvisible:

true

add objectclass:

orclDynamicGroup

orclGroup

top

groupOfUniqueNames

add displayname:

Managers

add owner:

cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com

adding new entry cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=mybiz,dc=com

modify complete

オプション2: ODSMを使用した動的グループの作成

1. Oracle Directory Services Manager (ODSM)を起動し、Oracle Internet Directoryサーバーに接続します。
Oracle Directory Services Managerの起動と使用の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のOracle Directory Services Managerの使用に関する項を参照してください。

2. 「移動先」リストから、「データ・ブラウザ」を選択します。

3. データ・ブラウザで、「新規エントリ」アイコンをクリックします。

4. DNを入力し、オブジェクト・クラスorclDynamicGroupおよびgroupOfUniqueNamesを追加します。

5. 「必須プロパティ」タブで、CN属性を入力します。

6. 「オプション・プロパティ」タブで、labeleduriの属性を入力します。

7. 「OK」をクリックし、動的グループの定義を完了します。

ツリー・ビューをリフレッシュすると、作成した新規グループが表示されます。グループ・メンバーがODSMには表示されないことに注意してください。

7.1.8.2 動的グループの使用によるページの保護

動的グループを定義すると、Portalでのページ保護の保証として使用できます。動的グループを更新してもDIP変更イベントは発生しないため、Portalには、このような動的グループによって影響を受ける可能性のあるページを無効化するトリガーがありません。そのため、動的グループを使用して保護しているページは、キャッシュしないか、またはユーザー・レベルで、動的グループの定義に使用している属性に適したキャッシュ有効期限を指定した失効ベースのキャッシュを行う必要があります。

7.1.9 ポートレットのセキュリティ

ポートレットは、アプリケーションのウィンドウの役目を果たし、サマリー情報を表示したり、アプリケーションのすべての機能にアクセスする方法を提供したりします。ポートレットでは、アプリケーションの機能をポータルに直接公開したり、タスクを実行するためにアプリケーション自体にアクセスできる深いリンクを提供したりします。ポートレットでは情報をWebページに表示できるように書式設定するため、基になるアプリケーションはOracle Portalと統合されるためにWeb対応である必要はありません。

Oracle Portalでは、ポートレットはプロバイダによって管理されます。プロバイダとは、Oracle Portalに登録されているアプリケーションのことです。Oracle Portalでは、次の3種類のプロバイダをサポートしています。

- Webプロバイダ

- データベース・プロバイダ

- Web Services for Remote Portlets(WSRP)プロデューサ

ポートレットのセキュリティは、次の3つの主な機能領域で構成されています。

- 認証: ユーザーがセキュアなURLに初めてアクセスすると、そのユーザーのIDを確認する情報(ユーザー名、パスワード、デジタル証明書など)を入力するよう要求されます。

- 認可: 認可とは、特定のユーザーがアプリケーションの一部にアクセスできるようにするプロセスのことです。アプリケーションには、誰でも自由にアクセスできる部分もあれば、限られた何人かの認証済ユーザーのみがアクセスできる部分もあります。

- 通信セキュリティ: 通信セキュリティとは、Oracle Portalがプロバイダとやり取りする通信(メッセージなど)の真正性を確立するために使用する方法のことです。高度にネットワーク化された環境では、通信が認証されたものであるかどうかを確認することがきわめて重要です。

Webプロバイダを確実に安全なものにするためには、これらの各領域でプロバイダが保護されていることを確認する必要があります。3つの領域のうちの1つか2つのセキュリティ機能を実装しただけでは、プロバイダがセキュアであるとみなすことはできません。Webプロバイダの保護に力を注いだだけ、プロバイダが公開するデータの機密性も高くなります。

WSRPポートレットのセキュリティを確保するために、Oracle PortalおよびWSRPプロデューサは、VPNネットワークや、ファイアウォールの内側にあるネットワークなど、本質的にセキュアなネットワークを介して通信します。

7.1.9.1 認証

ユーザーが初めてOracle Portalにログインするときは、アクセスを許可される前に、ユーザーのIDを確認するためのパスワードを入力する必要があります。このログイン・プロセスは、OracleAS Single Sign-Onによって管理されています。詳細は、第7.1.9.7項「シングル・サインオン」を参照してください。

7.1.9.2 認可

認可により、特定のユーザーがポートレットの表示または対話を行えるかどうかが判断されます。認可チェックには、次の2種類があります。

- Portalのアクセス制御リスト: Oracle Portalにログインすると、ユーザーはOracleAS Single Sign-Onによって認証されます。認証されると、Oracle Portalではアクセス制御リスト(ACL)を使用して、ページやポートレットなどのポータル・オブジェクトに対する権限をユーザーに付与します。操作の範囲は、単にオブジェクトを表示することから管理機能の実行にまで及びます。ある特定の権限が付与されているグループに属さないユーザーは、Oracle Portalで、その権限に関連付けられている操作が実行できません。

- プログラムによるポートレットのセキュリティ: Portal Developer's Kit-Javaには、特定のユーザーにポートレットの表示が認可されているかどうかを確認するためにコールされるAPIが含まれています。これらのAPIを使用して、Portal ACLのセキュリティを強化する認可ロジックを実装できます。

- J2EEセキュリティ・ロール: プロバイダ・コードではプログラムによるJ2EEセキュリティを使用できます。この機能を利用するには、アサートされたIDの整合性を保護するため、拡張認証を使用するようにプロバイダを構成する必要があります。ポートレット・コード内からは、request.isUserInRole("securityrole")を使用できます。ここで、requestはHttpServletRequestリクエストで、securityroleは宣言されたJ2EEセキュリティ・ロールです。拡張認証の構成方法の詳細は、第7.3.1.3.2項「拡張認証」を参照してください。

7.1.9.3 通信セキュリティ

認証と認可は、Webプロバイダを保護する重要なコンポーネントです。ただし、認証と承認ではプロバイダが受信したメッセージの認証性までは確認されないため、それだけでプロバイダへのアクセスを保護するのには適していません。通信が保護されていないと、誰かがOracle Portalを装い、Webプロバイダをだまして機密情報を返信させる危険があります。

通信セキュリティは、Oracle PortalとJPDK Webプロバイダとの通信を保護することに的を絞っています。これらの方法は、ポータル・データベースの内部で実行するデータベース・プロバイダには適用されません。通信セキュリティには、次の3つのタイプがあります。

- Portalサーバー認証では、受信メッセージが信頼できるホストから送信されたことを確認します。

- メッセージ認証では、受信メッセージが改ざんされていないことを確認します。

- メッセージの暗号化では、メッセージの内容を暗号化することによって保護します。

7.1.9.3.1 Portalサーバー認証

Portalサーバー認証では、プロバイダへのアクセスを少数の認証されているコンピュータに制限します。この方法では、受信したHTTPメッセージのIPアドレスまたはホスト名を信頼できるホストのリストと比較します。IPアドレスまたはホスト名がリストにあれば、メッセージはプロバイダに渡されます。リストになければ、そのメッセージはプロバイダに達する前に拒否されます。

7.1.9.3.2 メッセージ認証

メッセージ認証は、共有キーをベースとしたチェックサムをプロバイダのメッセージに追加することによって機能します。メッセージがプロバイダによって受信されると、予想されるチェックサムの値が計算され、その値が実際に受信された値と比較されることによって、メッセージの認証性が確認されます。それらの値が同じであれば、メッセージは受け入れられます。それらの値が異なっていれば、メッセージは拒否されてその後の処理も行われません。チェックサムには、送信中にメッセージが不法に記録され、後で再送信される可能性を低くするためのタイムスタンプが含まれています。

関連項目:

第7.1.9.9項「メッセージ認証」

7.1.9.3.3 メッセージの暗号化

メッセージの暗号化は、プロバイダとOracle Portalとの通信にHTTPSプロトコルを使用することによって行われます。メッセージは強力に暗号化されるため、その中でデータが保護され、機密性が保持されます。暗号化は高度なセキュリティを確保できる一方で、必然的にパフォーマンスにも影響を及ぼします。

注意:

このリリースでは、Oracle PortalおよびWSRPプロデューサ間の通信にHTTPSプロトコルを使用できません。

7.1.9.4 アクセス制御リスト

Oracle Portalにログインすると、ユーザーはOracleAS Single Sign-Onによって認証されます。次に、Oracle Portalで、アクセス制御リスト(ACL)を使用して、ユーザーに各コンテンツ(プロバイダやポートレットなど)の表示が認可されているかどうかが確認されます。ある特定の権限が付与されているグループに属さないユーザーは、Oracle Portalで、その権限に関連付けられている操作が実行できません。

ACLは、次のように管理されます。

- 権限は、それらが付与されているオブジェクトに対して実行できる操作を定義します。「管理」、「実行」、「アクセス」、「公開」などのいくつかの権限を付与できます。これらの権限のいずれかを設定すると、ユーザーはポートレットにアクセスできます。

- ユーザーとその権限は、ビルダーの「管理」タブにある「ポータル」タブで管理されます。

- グループ内のグループ・メンバーシップとそのグループに付与されている権限は、ビルダーの「管理」タブにある「ポータル」タブで管理されます。ユーザー・グループに付与されている権限は、そのグループのすべてのメンバーによって継承されます。

- プロバイダに権限を付与できます。デフォルトでは、それらの権限はプロバイダとそのプロバイダ内のすべてのポートレットに適用されます。プロバイダのACLは、ナビゲータの「プロバイダ」タブで管理されます。

- ポートレットの権限によって、ポートレットのプロバイダに設定された権限をオーバーライドできます。ポートレットのACLは、ナビゲータの「プロバイダ」タブで管理されます。「プロバイダ」の「開く」をクリックすると、プロバイダのポートレットを管理するためのページが表示されます。

7.1.9.4.1 利点

- ACLは、ポータル・オブジェクトを保護するための、簡単で、しかも非常に強力なメカニズムを備えています。

- ユーザーやグループは集中管理されているため、グループのメンバーシップの変更に伴ってACLを変更する必要はありません。

7.1.9.4.2 不利な点

ACLは、プロバイダまたはポートレットのレベルで適用されます。ポートレットが置かれているポータル・ページによって、ポートレットのセキュリティ・ルールを変更することはできません。

7.1.9.5 Oracle Portalのサーバー認証

プロバイダへの認可されていないアクセスを回避する方法の1つは、サーバー・レベルでプロバイダへのアクセスを既知のクライアント・コンピュータに制限することです。この方法は、サービス拒否攻撃に対する防御にある程度役に立ちます。

Oracle HTTP Serverでは、ホスト名またはIPアドレスを基にしたhttpd.confファイル内のディレクティブを許可または拒否できます。識別子としてホスト名を使用すると、サーバーはドメイン・ネーム・サーバーでそれらを見つける必要があり、各リクエストの処理に対してオーバーヘッドが発生します。IPアドレスを使用すると、このような余分のオーバーヘッドが発生しなくて済みますが、IPアドレスは警告なしに変更される可能性があります。

7.1.9.5.1 利点

- この方法では、信頼できるホストのみがプロバイダにアクセスできます。

- アクセスの制限を簡単に設定することができます。

7.1.9.5.2 不利な点

- Oracle Web CacheにはIPアドレスのチェック機能がありません。プロバイダの手前にOracle Web Cacheがある場合は、どのホストのクライアントもOracle Web Cacheに表示リクエストを送信できます。

- この方法を回避するには、偽のIPアドレスとホスト名が含まれるメッセージをプロバイダに送信します。この方法は慎重に実行する必要があります。リターン・メッセージでは、コピーされたIPアドレスをコンピュータに送信しますが、そのIPアドレスによって引き続き問題が発生する可能性があるからです。

次の各項は、Webプロバイダにのみ適用され、WSRPプロデューサには適用されません。

7.1.9.6 Portalツールの「プロバイダ構成」ページの保護

特に設定を行っていない場合、Portalツール(OmniPortletとWebクリッピング)のプロバイダ構成ページは一定の権限によって保護されています。この権限の詳細は、第7.1.3.4項「Webプロバイダとプロバイダ・グループを編集する権限」を参照してください。これらのページが保護されていない場合は、DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INFディレクトリのweb.xmlファイルで、次のパラメータと値がfalseではなくtrueに設定されていることを確認してください。

<init-param>
<param-name>oracle.webdb.providerui.securedAccessParam</param-name>
<param-value>true</param-value>
</init-param>

7.1.9.7 シングル・サインオン

ポートレットは、アプリケーションのウィンドウの役目を果たし、コンテンツのサマリーや、アプリケーションのすべての機能にアクセスする方法を表示します。ポートレットでは、アプリケーションの機能をポータルに直接公開したり、タスクを実行するためにアプリケーション自体にアクセスできる深いリンクを提供したりできます。

アプリケーションで認可が行われない場合は、ユーザーがそのアプリケーションを表示したり、そのアプリケーションやそれに関連付けられているポートレットを使用するのに認証は必要ありません。より制限のあるアプリケーションについては、それにアクセスしているユーザーを認証する必要があります。

- パートナ・アプリケーションでは、Oracle Portalのユーザーと同じ認証ユーザーを共有しています。この場合、アプリケーションのユーザーとOracle Portalのユーザーは同じです。

- 外部アプリケーションでは、ユーザーの証明書にOracle Portalとは異なる認証メカニズムを使用し、通常は異なるリポジトリを使用します。アプリケーションのユーザー名がOracle Portalと同じである場合がありますが、外部アプリケーションでは独自のメカニズムによってユーザーを確認します。

7.1.9.7.1 パートナ・アプリケーション

パートナ・アプリケーションでは、認証のためにOracle Portalと同じOracleAS Single Sign-Onを共有しています。OracleAS Single Sign-Onのインスタンスを共有すると、ユーザーがOracle Portalにすでにログインしているときは、再度ログインしなくてもそのIDがパートナ・アプリケーションにアサートされることになります。

パートナ・アプリケーションは、OracleAS Single Sign-Onと密接に統合されています。ユーザーがパートナ・アプリケーションへのアクセスを試みると、パートナ・アプリケーションはそのユーザーの認証をOracleAS Single Sign-Onに委任します。有効なユーザー名とパスワードによって一度認証されると、ユーザーは同じOracleAS Single Sign-Onインスタンスを共有している他のパートナ・アプリケーションにアクセスするときにユーザー名またはパスワードを入力する必要がありません。OracleAS Single Sign-Onでは、ユーザーが正常に認証されたことを確認し、認証が成功したことを他のパートナ・アプリケーションに示します。

パートナ・アプリケーションのプロバイダは、プロバイダにかわってOracle Portalにユーザーを認証してもらいます。この関係が可能なのは、Oracle Portal自体がパートナ・アプリケーションであるからです。パートナ・アプリケーションのプロバイダは、それ自体で認証を行うことができないため、この方法でOracle Portalにユーザーを認証してもらう必要があります。ユーザーを直接認証するには、プロバイダがブラウザをOracleAS Single Sign-Onにリダイレクトし、成功URLと失敗URLを提供する必要があります。この方法は、プロバイダのアーキテクチャが原因で実行できません。その主な理由は、認証がOracle PortalからプロバイダへのAPIコールを受けて行われるからです。認証に際し、OracleAS Single Sign-OnではinitSession()/dologin()メソッドを同様にコールして、通常の処理を行うことができません。

パートナ・アプリケーションでのユーザーの認証は、従来型のアプリケーションとは異なります。パートナ・アプリケーションは、ユーザー認証をOracleAS Single Sign-Onに委任します。ユーザーが認証されていない場合、OracleAS Single Sign-Onでは、ユーザーにユーザー名とパスワードを入力するよう要求するログイン・ページが表示されます。ログイン・ページでは、ユーザー名とパスワードがOracleAS Single Sign-Onに送り返されます。

認証に成功すると、OracleAS Single Sign-Onではユーザーに関する情報を格納した専用のCookieが作成されます。セキュリティを確保するために、OracleAS Single Sign-OnではCookieの内容が暗号化されています。Cookieは、ユーザーのブラウザに送り返されますが、OracleAS Single Sign-Onのみがそれにアクセスできるように適用範囲が設定されます。それは他のリスナーには渡されません。Cookieの作成後、OracleAS Single Sign-OnはWebブラウザをパートナ・アプリケーションによって指定された成功URLにリダイレクトします。この時点で、パートナ・アプリケーションでは、アプリケーションのセッションCookieが作成されます。このCookieにはその後のセッションの再確立に必要な情報が格納されます。以降はこのパートナ・アプリケーションに対するリクエストを発行すると、パートナ・アプリケーションのセッションCookieの存在が検出され、それによりユーザーがすでに認証済であることが確認されます。

ユーザーが後で別のパートナ・アプリケーションにアクセスすると、そのアプリケーションはアプリケーション固有のセッションCookieを検索します。Cookieが見つからない場合は、前に説明したように、アプリケーションはリクエストをOracleAS Single Sign-Onにリダイレクトします。今度は、OracleAS Single Sign-OnがユーザーのOracleAS Single Sign-On Cookieの存在を検出します。このCookieはユーザーがすでに認証されていることを示しているため、OracleAS Single Sign-Onでは、ユーザーに証明書の再入力を要求せずに、ブラウザを2番目のパートナ・アプリケーションの成功URLにリダイレクトします。この時点で、パートナ・アプリケーションでは、そのアプリケーション固有のセッションCookieが作成されます。

Oracle Portalによって行われるIDアサーションのプロバイダに対する整合性を保護するには、HMACを使用したメッセージ認証を構成する必要があります。この設定方法の詳細は、第7.3.1.3項「プロバイダのメッセージ認証の構成」を参照してください。

利点

- Oracle PortalとOracleAS Single Sign-Onを最も密接に統合できます。

- ユーザーはOracleAS Single Sign-Onを最も有効に利用できます。

- ポータルとプロバイダの間でユーザー名やパスワードを送信しないため、最もセキュアな形式で統合を行うことができます。

- アプリケーションとポータルは同じユーザー・リポジトリを共有しているため、ユーザーの管理が軽減されます。

不利な点

- アプリケーションのユーザー・コミュニティがポータルのユーザー・コミュニティのサブセットである可能性があっても、アプリケーションはOracle Portalと同じユーザー・リポジトリを共有する必要があります。この小さな問題には、そのアプリケーションをアプリケーションのユーザー・コミュニティに公開するポータル・ページへのアクセスを制限することによって対処できます。

- アプリケーションを1つ以上のOracleAS Single Sign-Onと密接に統合できるのは、それらが同じユーザー・リポジトリを共有している場合のみです。

実装テクニック

アプリケーションは、mod_ossoを使用してURLを保護することで、パートナ・アプリケーションにすることができます。一度構成すると、mod_ossoはURLへのアクセスを制限し、OracleAS Single Sign-OnへのリダイレクトやCookieの作成などの処理を行います。

mod_osso

mod_ossoは、汎用的なOracle HTTP Serverモジュールで、OracleAS Single Sign-Onのパートナ・アプリケーションです。それは、OracleAS Single Sign-Onを使用して認証を行います。モジュールは、Oracle HTTP ServerとOracleAS Single Sign-Onの間のCookieの通信や処理をすべて行います。WebアプリケーションのURLを保護するようにmod_ossoを構成すると、そのアプリケーションは実質的にパートナ・アプリケーションとなります。

Oracle Portalもパートナ・アプリケーションであり、OracleAS Single Sign-Onを使用してユーザーを認証します。Oracle Portalとmod_ossoが同じOracleAS Single Sign-Onインスタンスを使用するという前提で、ユーザーはいずれか一方にログインすることによって、WebアプリケーションにもOracle Portalにもアクセスできます。つまり、一度のログインのみで、WebアプリケーションとOracle Portalの両方にアクセスできるようになります。

利点

- mod_ossoは、設定が簡単です。

- アプリケーションにコードを追加する必要がありません。

- OracleAS Single Sign-On環境の新機能は、単純な動的ディレクティブを通じて公開されます。

- mod_ossoは、パートナ・アプリケーションのCookieを作成し、Cookieの処理をすべて行います。

- mod_ossoは、パートナ・アプリケーション、およびパートナ・アプリケーションのプロバイダからの深いリンクを保護します。

不利な点

- 必ずしも不利な点ではありませんが、mod_ossoは、Webアプリケーションでしか使用できません。

7.1.9.7.2 外部アプリケーション

外部アプリケーションとは、Oracle Portalとは異なる認証メカニズムを使用するアプリケーションのことです。このアプリケーションでは、Oracle Portalによって使用されるのとは異なるOracleAS Single Sign-Onインスタンスを使用することも、他の認証方法を使用することもできます。どちらの場合も、OracleAS Single Sign-Onでは、ユーザー名のマッピングやパスワードなど、ユーザーの認証に必要な資格証明を各外部アプリケーションに格納します。Oracle Portalにすでにログインしているユーザーは、ユーザー名やパスワードを入力しなくても外部アプリケーションにログインできます。

独自のユーザー認証を管理しているアプリケーションは、外部アプリケーションとして登録することにより、OracleAS Single Sign-Onと柔軟に統合できます。Oracle Fusion Middleware Portal Developer Kitを使用して外部アプリケーションをプロバイダとして公開すれば、ページのポートレットからその外部アプリケーションにアクセスできます。外部アプリケーションのプロバイダは、JPDK Webプロバイダでのみ利用できます。

関連項目:

「外部アプリケーション」ポートレットの詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

以前に認証されたユーザーが初めて外部アプリケーションにアクセスするとき、OracleAS Single Sign-Onではその外部アプリケーションを使用してユーザーの認証を試みます。この認証は、そのアプリケーションの登録情報、ユーザーのユーザー名とパスワードを結合するHTTPリクエストを送信することによって行われます。ユーザーがまだその外部アプリケーションのユーザー名とパスワードを登録していない場合、OracleAS Single Sign-Onでは認証リクエストを作成する前に、ユーザーに必要な情報を入力するよう要求します。ユーザーが外部アプリケーションのユーザー名とパスワードを入力すると、OracleAS Single Sign-Onでは新しいユーザー名とパスワードが、そのユーザーのOracle Portalのユーザー名にマップされ、格納されます。次回ユーザーが外部アプリケーションにアクセスする必要があるときは、格納されている証明書が使用されます。

注意:

外部アプリケーションのURLを変更した場合は、OracleAS Single Sign-On Serverでその外部アプリケーションを更新する必要があります。外部アプリケーションの更新については、『Oracle Application Server Single Sign-On管理者ガイド』の外部アプリケーションの編集に関する項を参照してください。

利点

- 多数のポータルとの統合が可能です。優先ポータルがある場合は、アプリケーションをそのポータルのパートナ・アプリケーションとして統合し、他のポータルの外部アプリケーションとして統合できます。

- ユーザーはシングル・サインオンを利用することができます。ただし、ユーザーは異なるユーザー名やパスワードを管理する必要があります。さらに、外部アプリケーションのユーザー名のマッピングも管理する必要があります。

- 複数のポータルとの統合を、それらのユーザー・リポジトリやシングル・サインオンのメカニズムに関係なく行うことができます。

不利な点

- 外部アプリケーションは、ポータルと同じユーザー・リポジトリを共有しません。このため、ユーザー情報の管理がさらに必要となります。

- ユーザー名とパスワードが平文でプロバイダに送信されます。この方法は、パートナ・アプリケーションほどセキュアではありません。SSLを使用するようにプロバイダのURLを構成すると、この問題に対処できます。

- JavaまたはPL/SQLと簡単に統合できるテクノロジを使用してアプリケーションを作成する必要があります。

7.1.9.7.3 アプリケーションによる認証を行わない

この場合、プロバイダはリクエストを送信するポータルを信頼します。プロバイダは、ユーザーがログインしているかどうかやポータル・ユーザー名を確認することはできますが、アプリケーションではユーザーの認証は行いません。

利点

この形式の統合は最も簡単かつ短時間で実装できます。

不利な点

Oracle Portalとの統合が最も弱くなります。ただし、ポートレットのコンテンツに機密情報が含まれていない場合、またはプロバイダの場所がネットワーク・トポロジによって保護されており、ポータルでのみアクセス可能な場合、これは問題にはならないことがあります。

7.1.9.8 プログラムによるポートレットのセキュリティ

プロバイダ内部にポートレットのセキュリティ・メソッドを実装して、特定のユーザーがポートレット・インスタンスにアクセスできるかどうかを確認できます。これらのセキュリティ・メソッドは、ポートレット・レベルで機能します。つまり、各ポートレットに独自のユーザー・アクセス制御を適用することができます。プロバイダでアクセス制御メソッドを実装することにより、ユーザーの証明書が認可ロジックに通った場合にのみコンテンツがポートレットから取得されます。プロバイダでポートレットのセキュリティ・メソッドを実装しない場合は、偽名や認証されていない名前であっても、すべてのユーザー名が通ります。

プロバイダでは、次の2つのポートレットのセキュリティ・メソッドを実装できます。

- ポートレットのリストを取得します。

- ポートレットのアクセスを確認します。

これらのメソッドでは、認可レベルに関する次の情報にアクセスできます。

- 強い認証は、ユーザーが現行のOracle PortalセッションでOracleAS Single Sign-Onによって認証されたこと、つまり有効なユーザー名とパスワードを使用してOracle Portalにログインし、そのセッションでポートレットをコールしたことを示します。

- パブリックは、ユーザーが現行のOracle Portalセッションのコンテキスト内でログインしておらず、そのような状態が以前に存在したことを示す永続的なCookieもないことを示します。

ポートレットは、次に示すOracle Portalのユーザー権限やグループ・メンバーシップにもアクセスできます。

- ユーザーのデフォルト・グループ

- ユーザーまたはグループの権限

- すべてのグループで利用できる最高のユーザー権限

- ユーザーがアクセスできるオブジェクト

7.1.9.8.1 利点

ポートレットのセキュリティ・メソッドを使用すると、ユーザーの認可レベルによって異なる出力をポートレットで作成することができます。

7.1.9.8.2 不利な点

セキュリティ・マネージャのほとんどの実装では、認可レベルまたは受信メッセージに含まれている他のなんらかのユーザー固有の要素が使用されます。この種の確認は、Oracle Portalを装うエンティティによって無視されることがあります。

7.1.9.9 メッセージ認証

Oracle Fusion Middleware Portal Developer Kitでは、メッセージ認証をサポートして、指定されたプロバイダ・インスタンスまたはプロバイダ・インスタンスのグループへのアクセスを制限します。プロバイダは、ポータルとプロバイダの管理者のみが知っている秘密共有キーに登録されます。

Oracle Portalインスタンスでは、Hashed Message Authentication Code (HMAC)アルゴリズムを使用して計算されたデジタル署名が各メッセージとともにプロバイダに送信されます。プロバイダは、共有キーの独自のコピーで署名を確認することによって、メッセージを認証することができます。このテクニックは、プロバイダとのSSL通信でクライアント証明書のかわりに使用することができます。

Oracle Portalインスタンスでは、ユーザー情報、共有キーおよびタイムスタンプを基にして署名が計算されます。署名とタイムスタンプは、SOAPメッセージの一部として送信されます。タイムスタンプは、UTC(協定世界時、グリニッジ標準時の学術名)を基にしているため、異なるタイム・ゾーンのコンピュータ間のメッセージに使用することができます。

プロバイダがこのメッセージを受信すると、その署名の独自のコピーを作成します。署名が合致すると、メッセージのタイムスタンプを現在の時刻と比較します。2つの時刻の差が許容値の範囲内にある場合は、メッセージは本物とみなされ、その結果、処理されます。

1つのプロバイダ・インスタンスで複数の共有キーをサポートすることはできません。複数のキーを使用すると、プロバイダを共有している複数のクライアントが同じキーを使用した場合にセキュリティや管理上の問題が発生する可能性があります。たとえば、共有キーのコピーの1つがなんらかの方法で侵害された場合、プロバイダの管理者は新しいキーを作成して、それをすべてのクライアントに配布し、クライアントはそのプロバイダ定義を更新する必要があります。この問題を回避するには、異なるプロバイダ・サービスを配置して、サービスごとに一意の共有キーを指定します。各プロバイダ・サービスには独自のデプロイ・プロパティ・ファイルがあるため、各サービスは他のサービスとは無関係に構成されます。同じプロバイダ・アダプタ内に複数のプロバイダ・サービスを配置することによるオーバーヘッドは比較的小さいものです。

プロバイダの手前にOracle Web Cacheがない場合、プロバイダ・セッションの存続期間中に同じ署名Cookieが使用されるということは、パフォーマンスと、リクエストを認証することによって得られるセキュリティの間で妥協する必要があることを意味します。署名Cookieの値は、最初のSOAPリクエストによってプロバイダとのセッションが確立された後に1回のみ計算されます。プロバイダ・セッションのタイムアウトが短いほど、署名が計算される頻度が多くなり、不正な表示リクエストに対するセキュリティが高まります。ただし、セッションの確立に必要なSOAPリクエストにより時間がかかります。

Oracle Web Cacheを使用して表示リクエストのレスポンスをキャッシュするプロバイダでも、同様の妥協が必要です。キャッシュされたコンテンツは、受信リクエストに、キャッシュされたコンテンツを取得するための署名Cookieが含まれているという点でセキュアですが、長期間にわたってコンテンツをキャッシュすると、プロバイダは不正な表示リクエストに対して無防備になります。

署名要素では、メッセージの傍受や再送信に対する保護は行われますが、メッセージ・コンテンツの傍受や読取りを防ぐための処理は何も行われません。しかも、メッセージは平文で送信されます。メッセージの内容が認可されていない者に読み取られるのが心配な場合は、メッセージ認証をSSLと組み合せて使用する必要があります。

関連項目:

第7.3.1.3項「プロバイダのメッセージ認証の構成」

7.1.9.9.1 利点

メッセージ認証では、プロバイダによって受信されたメッセージが正当なOracle Portalインスタンスから送信されたものであることが保証されます。

7.1.9.9.2 不利な点

- プロバイダが複数のOracle Portalインスタンスを処理する場合は、メッセージ認証によって管理上の問題が発生する可能性があります。

- セッションのタイムアウトを短くすることでメッセージ認証のセキュリティを非常に高くした場合は、パフォーマンス上の影響があります。

7.1.9.10 HTTPS通信

Oracle Portalとプロバイダとの通常の通信には、TCPをトランスポート・レイヤーとして使用し、データを平文で送信するHTTPというネットワーク・プロトコルが使用されます。認可されていないエージェントが、傍受したメッセージを読む可能性があります。HTTPSは、TCPの上位にある特別なセキュリティ・レイヤー(SSL)を使用して、クライアントとサーバーとの通信を保護します。

SSLを使用して通信を受け入れる各エンティティ(Oracle Web Cacheインスタンスなど)は、自由に利用できる公開鍵と、エンティティのみが知っている秘密鍵を持っています。エンティティに送信されるメッセージはすべて、そのエンティティの公開鍵で暗号化されます。公開鍵で暗号化されたメッセージは、秘密鍵によってのみ復号化できるため、メッセージが傍受された場合でも復号化はできません。

証明書は通信の署名に使用され、それによって公開鍵が実際に正しいエントリに属していることが保証されます。このような証明書は、認証局(CA)として知られる信頼できるサード・パーティ(OracleAS Certificate AuthorityやVerisign社など)によって発行されます。この証明書には、エンティティの名前、公開鍵およびその他のセキュリティ資格証明が含まれています。これは、サーバーのIDを確認するためにSSL通信のサーバー側にインストールされます。クライアントのIDを確認するためにクライアントの証明書をクライアントにインストールすることもできますが、この機能ではまだOracle Portalがサポートされていません。かわりにメッセージ認証を使用できます。

Oracle Wallet Managerは、公開鍵のセキュリティ資格証明の管理に使用されるアプリケーションです。これは、公開鍵/秘密鍵のペアの生成、CAへの証明書リクエストの作成およびサーバーでの証明書のインストールに使用されます。

7.1.9.11 SSLの構成

プロバイダをOracle Portalインスタンスから登録するときは、URLを1つのみ入力します。HTTPまたはHTTPSを使用できますが、両方を組み合せての使用はできません。

コンピュータにインストールされたサーバー側の証明書は、そのコンピュータ(ドメイン)の識別に使用されますが、そのコンピュータの複数のポート定義で使用される場合があります。証明書の信頼リストを使用することで、特に識別されたサーバーのみに通信が限定されます。信頼できるOracle Portalインスタンスとプロバイダとの通信を完全に保護するには、メッセージ認証もあわせて使用する必要があります。

関連項目:

- 第7.3.2.1項「Oracle PortalのSSLの構成」

- Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

- Oracle Fusion Middleware Oracle Web Cache管理者ガイド

7.1.9.11.1 利点

- SSLは、プロバイダからParallel Page Engineへのデータの転送中に、ポートレットのコンテンツを暗号化します。ポートレット・コンテンツのセキュリティを強化するには、周囲のページをSSLベースのリクエストで起動する必要があります。

7.1.9.11.2 不利な点

- 暗号化は、Oracle Portalのパフォーマンスに影響を与えます。

- 暗号化を使用する場合は、一部のコンテンツがパブリックであっても、プロバイダのすべてのポートレットでHTTPSを使用する必要があります。

Webプロバイダのセキュリティに関する詳細は、次の文書を参照してください。

- 「Overview of Provider Security」

- 「Overview of Password Authenticated Applications」

Oracle Technology Network (OTN)のサイト(http://www.oracle.com/technology/)で入手できます。

7.1.10 Web Services Remote Portletsへのアクセスの保護

ここでは、Oracle PortalからWSRPポートレットへのアクセスをセキュリティで保護する方法について説明します。

- キーストアの設定

- プロデューサの構成

WSRPプロデューサの概要の詳細は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。

7.1.10.1 キーストアの設定

WSRPプロデューサおよびPortalアプリケーションのセキュリティ資格証明は、Java Keystore (JKS)またはOracle Walletを使用して取得および管理できます。キーストアとは、使用可能な公開鍵および秘密鍵に関する情報を提供するファイルです。キーは、認証やデータ整合性などの様々な目的で使用します。ピアの証明書の検証に必要なユーザー証明書およびトラスト・ポイントも、ウォレットまたはキーストアに保存されます。キーストアの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

次の手順にあるコンシューマは、WSRPを介してリモート・ポートレット・プロデューサで生成したポートレットを利用するOracle Portalです。このプロデューサでは、コンシューマの公開鍵を使用して、そのコンシューマから受け取ったセキュリティ・トークンの真正性を検証します。このトークンは、getMarkupインタフェースを介して受け取ったリクエストのWS-Security・ヘッダーにあります。そのために、プロデューサではコンシューマの証明書とその署名に使用するルート証明書を収めたJavaキーストアが必要になります。これらの証明書は、信頼できる証明書としてJavaキーストアに追加されます。

この項では、Java Keystore (JKS)を使用してキーストアおよびキーを作成する方法について説明します。JKSは、Sun社で規定した固有のキーストア・フォーマットです。JKSでキーおよび証明書を作成および管理するには、Java JDK 6で配布されているkeytoolユーティリティを使用します。

コンシューマおよびプロデューサで使用するJavaキーストアの作成

コンシューマのJavaキーストアを作成するには、次の手順を実行します。

1. MW_HOME\jdk160_xx_\binに移動して、コマンド・プロンプトを開きます。

2. 次のようにkeytoolを使用して、キーのペアを生成します。

keytool -genkeypair -keyalg RSA -dname "<consumer_dname>" -alias <consumer_alias> -keypass <key_password> -keystore <keystore> -storepass <keystore_password> -validity <days_valid>

説明:

- <consumer_dname>はコンシューマの名前です(cn=consumer,dc=example,dc=comなど)。

- <consumer_alias>はコンシューマの別名です(consumerなど)。

- <key_password>は新しい公開鍵のパスワードです(welcome1など)。

- <keystore>はキーストアの名前です(consumer.jksなど)。

- <keystore_password>はキーストアのパスワードです(welcome1など)。

- <days_valid>はキーのパスワードの有効日数です(360など)。

注意:

キーを生成するためにkeytoolで使用するデフォルトのアルゴリズム(DSA)は機能しないので、前述のようにRSAを値として指定した-keyalgパラメータを使用する必要があります。

3. コンシューマの公開鍵をエクスポートします。

keytool -exportcert -v -alias <consumer_alias> -keystore <keystore> -storepass <keystore_password> -rfc -file <certificate_file>

説明:

- <consumer_alias>はコンシューマの別名です(consumerなど)。

- <keystore>はキーストアの名前です(consumer.jksなど)。

- <key_password>は、公開鍵のパスワードです(welcome1など)。

- <keystore_password>はキーストアのパスワードです(welcome1など)。

- <certificate_file>は、キーのエクスポート先の証明書のファイル名です(consumer.cerなど)。

4. 次のように、プロデューサのキーストアに信頼できる証明書をインポートします。

keytool -importcert -alias <consumer_alias> -file <certificate_file> -keystore <keystore> -storepass <keystore_password>

説明:

- <consumer_alias>は、コンシューマの別名です。

- <certificate_file>は、コンシューマの証明書のファイル名です。

- <keystore>は、プロデューサのキーストアの名前です。

- <keystore_password>は、プロデューサのキーストアのパスワードです。

7.1.10.2 プロデューサの構成

プロデューサを構成するには、次の手順を実行します。

- グローバル・キーストアの構成

- WSRPプロデューサの登録

グローバル・キーストアの構成

キーストアを構成するには、次の手順を実行します。

1. Oracle Portalにログインします。

2. 「管理」タブをクリックします。

3. 「サービス」ポートレットで「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

4. 「キーストア」タブをクリックします。
「デフォルト・キーストア」ページが表示されます。

5. 「デフォルト・キーストア」ページで、必要な情報を入力します。

6. 「適用」をクリックします。

7. 「OK」をクリックします。

WSRPプロデューサの登録

プロデューサを登録するには、次の手順を実行します。

1. 「ポートレット」サブタブをクリックします。

2. 「リモート・プロバイダ」ポートレットで、「プロバイダの登録」をクリックして「プロバイダの登録」ページを表示し、次の情報を入力します。

- 「名前」フィールドにプロバイダの名前を入力します。名前は200文字以内で入力します。空白や特殊文字は使用できません。

- 「表示名」フィールドに、そのプロバイダを参照したときに表示される名前を入力します(Portlet Repositoryなど)。表示名は200文字以内で入力します。

- 「タイムアウト」フィールドに、タイムアウト・メッセージを表示するまでにOracle Portalがプロバイダへの接続を試行し続ける時間を秒数で入力します。

- 「タイムアウト・メッセージ」フィールドには、「タイムアウト」フィールドで指定した秒数内にOracle Portalがプロバイダとの接続を確立できなかったときに表示されるメッセージを入力します。このメッセージはポートレットの本文内に表示されます。

- 「実装スタイル」リストから、使用しているWSRPプロバイダの「WSRP」を選択します。

「次へ」をクリックして「接続の定義」ページを表示します。

3. 「WSDL URL」フィールドで、プロバイダのWSDL URLを入力して「次へ」をクリックします。
ポータル登録プロパティ値ページが表示されます。

4. プロバイダに必要な登録プロパティを入力します。登録プロパティがない場合は、次の手順に進みます。
「WS-Security構成」ページが表示されます。

5. 「キーストア構成」セクションで、表7-18の説明にあるパラメータを入力します。

表7-18 WSRPプロデューサのキーストア接続パラメータ

フィールド

説明

ストア・パス

SOAPメッセージの一部(セキュリティ・トークンおよびSOAPメッセージ本体)での署名に使用する証明書および秘密鍵を収めたキーストアのフルパスを入力します。

選択するファイルとして、JDK keytoolまたはOracle Walletで作成したキーストアを指定できます。

ストア・パスワード

キーストアを作成したときに設定したキーストアのパスワードを入力します。ストアの正しいパスワードを入力してください。正しくないパスワードを入力すると、実行時のプロデューサ・ポートレットにエラーが表示されます。

ストア・タイプ

このプロデューサのキーストア・タイプ(JKSまたはORACLEWALLET)を選択します。

署名鍵の別名

リストから署名キーの別名を選択します。

署名鍵のパスワード

「署名鍵の別名」で指定した別名で特定するキーにアクセスするためのパスワードを指定します。

6. 「終了」をクリックします。「登録確認」ページが表示されます。

注意:

PeopleSoft 8.48および8.49 WSRPプロデューサは、ユーザー名トークンのプロファイルのみをサポートします。Oracle WSRPプロデューサは、SAMLトークンのプロファイルをサポートします。その他のWSRPコンテナでサポートされているトークンのフォーマットについては、それぞれのベンダーに確認してください。

7.1.11 「OmniPortlet」と「シンプル・パラメータ・フォーム」の保護

「OmniPortlet」と「シンプル・パラメータ・フォーム」は、ポートレット・リポジトリの「ポートレット・ビルダー」にあります。デフォルトでは、ページを作成する権限を持つユーザーであれば、これらのポートレットをページに追加したり、それらを定義したりすることができます。さらに、ページに対して最低でも「コンテンツの管理」権限を持っていれば、「OmniPortletの定義」または「シンプル・パラメータ・フォームの定義」をクリックしてこれらのポートレットを定義できます。

この種のアクセスを制御する場合は、権限チェックをアクティブにします。次の手順を実行すると、「アクセス」タブからユーザーまたはユーザー・グループに付与された権限に応じてこれらのポートレットの表示が変わります。ポートレットに対してなんらかの操作を実行するには、ユーザーまたはユーザー・グループに少なくとも「実行」権限が必要です。

1. Oracle Portalにログインします。

2. 「ナビゲータ」リンクをクリックします。

3. 「ポートレット・リポジトリ」ページ・グループをクリックします。

4. 「ページ」をクリックします。

5. 「ポートレット・ビルダー」ページの横の「編集」をクリックします。

6. ページの左上にあるページの「アクセス」をクリックします。

7. 「アイテム・レベルのセキュリティを有効にする」を選択します。

8. 「OK」をクリックします。

9. 「OmniPortlet」の横の「アイテムの編集」アイコンをクリックします。

10. 「アクセス」タブをクリックします。

11. 「ポートレットのアクセス権限を設定」を選択します。

12. 「適用」をクリックし、このページの「アクセス権限の付与」セクションと「アクセス権限の変更」セクションの表示内容を書き留めます。

13. 「アクセス権限の付与」セクションを使用して、ユーザーとグループに必要な権限を割り当てます。

14. 「OK」をクリックします。

15. 「シンプル・パラメータ・フォーム」についても、ステップ9から14を繰り返します。

7.1.12 Webクリッピング・プロバイダの保護

付録E「Portalツールのプロバイダの構成」では、Webクリッピング・プロバイダを使用する前に実行する必要がある管理タスクについて説明します。次の項では、Webクリッピング・プロバイダによって信頼できるサイトにアクセスし、それ自体とデータベース間のチャネルを暗号化できるようにするために必要ないくつかのセキュリティ構成オプションについて説明します。

- 信頼できるサイトの証明書の追加

- Webクリッピング・プロバイダのOracle Advanced Securityの構成

7.1.12.1 信頼できるサイトの証明書の追加

ユーザーがセキュアなサイトへ移動すると、そのWebサイトは、セキュリティに関する情報をユーザーから要求されたときに自身の身元を示す証明書をユーザーに返すことが普通です。ユーザーが証明書を受け取ると、その証明書はブラウザの信頼できる証明書のリスト内に置かれるので、ブラウザとそのサーバーとの間でセキュアなチャネルを開くことができます。Webブラウザと同様に、Webクリッピング・プロバイダは外部Webサイトに対してHTTPクライアントとして機能します。Webクリッピング・プロバイダが信頼できるサイトを追跡できるように、このようなサイトの証明書を格納するファイル(ORACLE_HOME\portal\confディレクトリのca-bundle.crtファイル)が使用されます。

出荷されるca-bundle.crtは、Oracle Wallet Managerからの信頼できるサーバー証明書ファイルをエクスポートしたものです。Oracle Wallet Manager内のデフォルトの信頼できるサーバー証明書は、Web上に存在するすべてのサーバー証明書を網羅するものではありません。このため、ユーザーがHTTPSを使用してセキュアなサーバーに移動しているときに、Webクリッピング・スタジオ内で、SSLのハンド・シェイク・フォームに失敗したという例外が発生することがあります。この問題を解決するには、参照された新しい信頼できるサイトを使用してca-bundle.crtファイルを拡張する必要があります。ポータル管理者として、次の手順に従って、出荷されたca-bundle.crtファイルを拡張する必要があります。

1. ブラウザ(Internet Explorerを推奨)を使用して、参照できても信頼できる証明書ファイルにない外部の各HTTPS Webサイトから、BASE64形式でルート・サーバーの証明書をダウンロードします。

2. Oracle Wallet Managerを使用して、各証明書をインポートします。

3. 信頼できるサーバー証明書をファイルにエクスポートして、ca-bundle.crtファイルをそのファイルで置き換えます。

Oracle Wallet Managerの詳細は、OTNのサイト(http://www.oracle.com/technology/)のOracle Databaseのドキュメントの『Oracle Database Advanced Security管理者ガイド』を参照してください。

7.1.12.2 Webクリッピング・プロバイダのOracle Advanced Securityの構成

Webクリッピング・プロバイダでは、中間層のプロバイダ自身とWebクリッピング・リポジトリのホストであるデータベース間のチャネルを保護し暗号化する、Oracle Advanced Security Option (ASO)を使用することができます。ASOは、Oracle Fusion Middleware Enterprise Editionでの利用またはStandard Editionへの追加オプションとしての利用のみが可能な機能なので、デフォルトでは、この機能は無効になっています。この機能を有効にするには、次の手順を実行します。

1. 次の場所にあるWebクリッピングの「プロバイダ・テスト・ページ」に移動します。

http://<host>:<port>/portalTools/webClipping/providers/webClipping

2. 「プロバイダ構成」セクションの「設定」列の下に、「Webクリッピング・リポジトリ」フィールドがあります。「操作」列内の対応する「編集」リンクをクリックします。

3. 「プロバイダの編集: Webクリッピング」ページの「リポジトリ設定」セクションで、「詳細セキュリティ・オプション」フィールドの「有効化(保護されたデータベース接続)」オプションを選択します。

4. 「OK」を選択して設定を保存し、Webクリッピングの「プロバイダ・テスト・ページ」に戻ります。

さらに、sqlnet.oraファイル内に次のASO構成パラメータを設定して、Webクリッピング・プロバイダと、Webクリッピング・リポジトリのホストとして動作するデータベース間で確立されるデータベース接続でASOが使用されるようにします。使用する値リストについては、『Oracle Database Advanced Security管理者ガイド』を参照してください。考えられるすべてのパラメータの組合せについて詳しく説明しています。

- SQLNET.AUTHENTICATION_SERVICES -- このパラメータは、ASOとのデータベース接続を行う際にサポートされている認証方法を選択するのに使用します。このパラメータの設定の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- SQLNET.CRYPTO_SEED -- このパラメータは、暗号化シード値(FIPS 140-1設定)を指し、ASOとのデータベース接続を行う際に使用します。
このパラメータの設定の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

注意:

最初の構成、つまりデータベース・パラメータがすでに設定されている状態の後にこれらのパラメータを設定する場合は、データベース接続がすでに開いているとみなされます。ASOを有効にすると、データベースへのすべての接続が影響を受けるため、ASOを使用する場合は、Webクリッピング・プロバイダが含まれているWLSインスタンスを再起動して、現在のすべての接続をリセットすることをお薦めします。ASOを無効にするときも、この作業が必要です。

7.1.13 連携型Portalアダプタの保護

連携型Portalアダプタは、Oracle Portalのコンポーネントで、ポータル・インスタンスがWebポートレット・インタフェースを介してポートレットを共有できるようにするために使用します。たとえば、あるポータル・インスタンスで、ソースが別のポータル・インスタンスに存在するポートレットを含むページをユーザーが表示するとします。リモート・ポータルの連携型Portalアダプタがポートレットのリクエストを受信すると、リモート・ポータルでそのユーザーのセッションが開始されます。これで、ポートレットがユーザーによってリモート・ポータル・インスタンスから実行できるようになります。このシナリオには、セキュリティ上、次の2つの意味があります。

- 連携型Portalアダプタは、リモート・ポータルでそのユーザーのセッションを作成する必要があるため、2つのポータル・インスタンスが同じSingle Sign-On Serverを共有するのが最善の方法です。そうしない場合、連携型Portalアダプタがユーザーをリモート・ポータル・インスタンスにログインさせようとしたときに名前の重複が起こる可能性があります。

- 連携型Portalアダプタは、受信したSOAPメッセージを基にしてプライベート・ポータル・セッションを作成するため、セキュリティ上のリスクとなる可能性があります。メッセージ認証コードを使用して、連携型Portalアダプタによって受信されたメッセージが信頼できるソースから送信されたものであることを確認する必要があります。

関連項目:

第13章「連携型Portalアダプタの使用」

詳細は、OTNのサイト(http://www.oracle.com/technology/)にある「How to Add Remote Portlets Using the Federated Portal Adapter」を参照してください。

7.1.14 OraDAVの保護

WebDAV (World Wide Web Distributed Authoring and Versioning)は、Web上でのコラボレーションによるオーサリングのためのIETFの標準です。それは、インターネット上で、互いに離れた位置にいるユーザーが共同で編集やファイル管理を行うためのHTTPの拡張のセットを定義します。

OraDAV (WebDAVをOracleに実装したもの)は、Oracle HTTP ServerがWebDAVのクライアントと通信するのに使用するメカニズムです。OraDAVを使用すると、ユーザーはそのWebDAVクライアントを使用してOracle Portalに接続できます。セキュリティについては、WebDAVを介してOracle Portalにアクセスする場合は、次の2つのセキュリティ問題を考慮する必要があります。

- OraDAVのOracle PortalセッションCookieの有効期限

- SSLとOraDAV

7.1.14.1 セッションCookieの有効期限

OraDAVの構成パラメータ、ORACookieMaxAgeは、DAVクライアントがCookieを保持する時間を秒単位で指定します。デフォルト値は、28800 (8時間)です。多くのWebDAVクライアント(Oracle Drive、WebFolders、Cadaverなど)では、ユーザーが初めて接続したときに入力した値を保持しており、それを使用して新しいCookieを作成するので、この時間が経過してもユーザーにユーザー名とパスワードの入力を要求することはありません。

ORACookieMaxAgeは、Oracle Enterprise Managerで変更できるほか、ORACLE_INSTANCE\config\OHS\ohs1\moduleconfにあるmod_oradav.confファイルで直接編集することもできます。このファイルを手動で変更する場合は、その変更を動的構成管理と同期化する必要があります。構成ファイルを変更したら、Oracle HTTP Serverを再起動して、変更を実行時システムに反映させる必要があります。

ORACLE_INSTANCE\bin\opmnctlから次のコマンドを実行して、Oracle HTTP Serverを再起動します。

opmnctl restartproc type=ohs

注意:

すべてのWebDAVクライアントがCookieを使用するわけではありません。HTTP Basic認証を使用して各リクエストに対する認証を行うクライアントもあります。クライアントでは、WebDAVクライアント・セッションの接続期間中、ユーザー名とパスワードを記録するように選択できるため、ユーザーに対して証明書の入力を1度要求するだけで済みます。ただし、どちらの場合も、この動作によってOracle Portalからのレスポンス時間が長くなります。これは、そのようなクライアントからのリクエストはすべて認証する必要があるため、Oracle Internet Directoryとの通信が余分に必要となるからです。

関連項目:

Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

7.1.14.2 SSLとOraDAV

WebDAV通信でのSSLの使用は、OraDAVでサポートされます。

7.1.14.3 MOD_ORADAV.CONFのパスワードの暗号化

ここでは、mod_oradav.confファイルのパスワードを暗号化する方法を説明します。

次のタスクを実行します。

- DAVパスワードの編集

- パスワードの曖昧化

DAVパスワードの編集

mod_oradav.confファイルのパスワードを編集するには、次のようにします。

1. ORACLE_INSTANCE/config/OHS/ohs1/moduleconf (UNIX)にあるmod_oradav.confファイルを開きます。

2. パスワードを変更するDAVエントリの場所を確認します。デフォルトのポータル・インスタンスの場合、DAV構成エントリは次のディレクティブにあります。

<Location /dav_portal/portal>

3. DAVエントリで、ディレクティブORACRYPTPASSWORD (例: DAVParam ORACRYPTPASSWORD BS50NfrosVZOjfgc9hUQ9wcbFFxLSYT/BA==)を削除し、次の構文を使用してクリア・テキストのパスワードに置換します。

DAVParam ORAPASSWORD <your_password_here>

例:

passwd123というパスワードを設定する場合は、DAVParam ORAPASSWORD passwd123という行を追加します。

4. ファイルを保存します。

パスワードの曖昧化

DAVパスワードの編集後は、UNIXのORACLE_HOME/bin、またはWindowsのORACLE_HOME\binにあるoradavTool.plスクリプトを実行して、DAVパスワードを曖昧化することをお薦めします。これを行うには、次の手順を実行します:

1. 必要に応じて、次のコマンドを使用して、ユーザーをOracleソフトウェアの所有者ユーザー(通常はoracle)に変更します。

su - oracle

2. 現在のリリースのOracleホーム・ディレクトリへのパスを指定するようにORACLE_HOME環境変数を設定し、Perl実行可能ファイルを格納したディレクトリおよびoradavTool.plスクリプトの場所(UNIXの場合はORACLE_HOME/ohs/bin、Windowsの場合はORACLE_HOME\ohs\bin)を指定するようにPATH環境変数を設定します。
Bourne、Bash、またはKornシェルの場合:

$ ORACLE_HOME=new_ORACLE_HOME_path;export ORACLE_HOME
PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH;export PATH

Cまたはtcshシェル:

% setenv ORACLE_HOME new_ORACLE_HOME_PATH
% setenv PATH ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:PATH

Microsoft Windowsでは、PATHおよびPERL5LIB環境変数を設定します。

set PATH=ORACLE_HOME\bin;%ORACLE_HOME%\perl\bin;%PATH%
set PERL5LIB=ORACLE_HOME\perl\lib

3. UNIXプラットフォームでは、共有ライブラリ・パス環境変数を設定します。
ORACLE_HOME/libまたはlib32ディレクトリを共有ライブラリ・パスで指定します。表7-19に、各プラットフォームに適したディレクトリおよび環境変数を示します。

表7-19 共有ライブラリ・パスの環境変数

プラットフォーム

環境変数

指定するディレクトリ

AIXベース・システム

LIBPATH

ORACLE_HOME/lib

HP-UX PA-RISC

SHLIB_PATH

ORACLE_HOME/lib

Solarisオペレーティング・システム

LD_LIBRARY_PATH

ORACLE_HOME/lib32

その他のUNIXプラットフォーム(Linux、HP Tru64 UNIXなど)

LD_LIBRARY_PATH

ORACLE_HOME/lib

たとえば、HP-UX PA-RISCシステムの場合は、ORACLE_HOME/libディレクトリを指定するようにSHLIB_PATH環境変数を設定します。

$SHLIB_PATH=$ORACLE_HOME/lib:$SHLIB_PATH;export SHLIB_PATH

4. ディレクトリを、oradavTool.plスクリプトの場所であるORACLE_HOME/bin (UNIX)ディレクトリに変更します。

5. 次のPerlスクリプトを起動して、mod_oradav.confパスワードを暗号化します。

perl oradavTool.pl -f mod_oradav.conffilename

ここで、mod_oradav.conffilenameは、mod_oradav.confファイルへのフルパスを記述したmod_oradav.confのファイル名です。

UNIXの例:

perl oradavTool.pl -f /u01/app/oracle/as11gr1/ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_oradav.conf

6. ディレクティブORAPASSWORDが新しいディレクティブORACRYPTPASSWORDによって更新され、パスワードが曖昧化されます。

7. Oracle HTTP Serverを再起動します。

7.2 Oracle PortalのOracle Fusion Middleware Security Frameworkの構成

この項では、次の考慮事項について説明します。

- Oracle PortalのFusion Middleware Security Frameworkオプションの構成

- Oracle PortalのOracle Identity Managementオプションの構成

7.2.1 Oracle PortalのFusion Middleware Security Frameworkオプションの構成

Oracle Fusion Middleware Security Frameworkを構成する際にOracle Portalで考慮が必要な主な事項は、SSLをどのように正しく構成するかという点です。Oracle PortalのSSLの構成の詳細は、第7.3.2.1項「Oracle PortalのSSLの構成」を参照してください。

7.2.2 Oracle PortalのOracle Identity Managementオプションの構成

Oracle Portalのセキュリティを構成するときは、Oracle Identity Managementに関連する次のトピックについて考慮する必要があります。

- 適切な命名属性とニックネーム属性の設定

7.2.2.1 適切な命名属性とニックネーム属性の設定

Oracle Identity Managementインフラストラクチャのディレクトリ情報ツリー構造とOracleコンテキスト・パラメータの設定を決めるときは、命名属性とニックネーム属性を異なる値にするように考慮する必要があります。命名属性は、エントリの識別名の最初の属性として使用されます。対照的に、ニックネーム属性はOracleAS Single Sign-Onのユーザー名を保持します。

Oracle Portalで、Oracle Internet Directory内のニックネーム属性の値を変更することによってユーザーの名前を正しく変更されるようにするには、ニックネーム属性が命名属性と異なっている必要があります。この2つを分けておくことにより、Oracle Internet Directory内のユーザーのエントリの識別名は、ニックネーム属性の値が変わっても変更されません。

関連項目:

Oracle Fusion Middleware Oracle Identity Managementスタート・ガイド

7.2.2.2 Oracle Portalインストーラのロールの定義

Oracle Portal Configuration Assistant (OPCA)を実行するには、このツールで各種操作を実行するための権限が必要です。ユーザーがptlasstを実行したときに、証明書に-ldap_d 'cn=orcladmin' -w orcladmin_pwdを指定すると、それはOracle Internet DirectoryのスーパーユーザーのIDとみなされ、すべての操作を実行できるようになります。一方、cn=orcladmin以外のユーザーがptlasstを実行する必要がある場合、操作を正常に実行するためには、そのユーザーに明示的に権限を付与する必要があります。

Oracle Fusion Middlewareのエンタープライズ・デプロイメントでは、中央のOracle Identity Managementインフラストラクチャ(Oracle Internet DirectoryやOracle Application Server Single Sign-Onなど)の保守と管理を中央のデータ・センターで担当していることがあります。企業内の部署でOracle Portalをインストールし、それを中央のインフラストラクチャに関連付ける必要がある場合、その部署の管理者にOracle Identity Managementインフラストラクチャの管理者がcn=orcladminパスワードを渡し、Oracle Portalをインストールできるようにすることは望ましい方法ではありません。このような場合は、Oracle Identity Management管理者が特定の権限をOracle Portal管理者に付与し、Oracle Portalを構成できるようにすることが可能です。構成後に、その権限を取り消すことができます。

Oracle Portalインストーラのロールを定義し、それを特定のユーザーに割り当てるには、次の手順を実行します。

1. このような目的のために、LDIF置換ファイル(.sbs)が用意されています。このファイルを使用すると、グループを作成したうえで、Oracle Portalの構成に必要な権限を継承できるように、そのグループを適切な権限グループに追加できます。
このファイルは次の場所にあります。

ORACLE_HOME/portal/admin/plsql/wwc/secadmin.sbs

ldifmigratorを使用してこのファイルを実行し、キーワードを置き換えてファイルを適切なLDIFファイルに変換する必要があります。

ldifmigrator 'input_file=secadmin.sbs' 'output_file=secadmin.ldif' -lookup 'host=oidhost' 'port=oidport' 'DN=cn=orcladmin' 'password=orcladmin_pwd'

2. このコマンドにより、secadmin.ldifというファイルが作成されます。これをOracle Internet Directoryサーバーにロードして、Oracle Portalインストーラで必要なロールをインストールできます。

ldapmodify -h <oidhost> -p <oidport> -D cn=orcladmin -w orcladmin_pwd -v -c -f secadmin.ldif

secadmin.ldifファイルをOracle Internet Directoryにロードすると、Oracle Delegated Administration Servicesの「ユーザーの作成」ページや「ユーザーの編集」ページで、新しく作成されたロールを使用できるようになります。ユーザーにこのロールを付与するには、orcladminとしてログインする必要があります。orcladminユーザーのみが、このロールを他のユーザーに付与できます。

3. Oracle Delegated Administration Servicesにログオンして、Oracle Portalをインストールする機能の付与先とするユーザーのエントリを見つけます。そのユーザーのエントリを編集して、Oracle Portalインストーラのロールを有効にします。これで、このユーザーはOracle Portalを構成できるようになります。

注意:

ディレクトリに大量のグループが存在する場合は、Oracle Portalインストーラ用のこのロールを定義するだけでなく、ディレクトリ・サーバーの問合せエントリの返送制限を適切に設定し、Oracle Portalの構成で問い合せたときにすべての該当グループの情報が返るようにしておく必要があります。この制限は、ディレクトリのルート・エントリのorclsizelimit属性に保存されています。Oracle Portalの構成では、グループのリストをローカル・キャッシュに移入するためにグループを問い合せます。cn=orcladminアカウントを使用してこの構成を起動すると、問合せの制限が適用されません。一方、cn=orcladmin以外のユーザーによる構成ではサーバーの問合せ制限が適用されます。そのため、Oracle Portalの構成の実行時のみであっても、この制限を十分に大きい値に設定する必要があります。

ldapmodifyコマンドライン・ユーティリティで使用できるサンプルLDIFファイルは、次のとおりです。

dn:
changetype: modify
replace: orclsizelimit
orclsizelimit: 2000

また、Oracle Directory Managerから問合せエントリの返送制限を設定することもできます。この属性はサーバー・エントリに対して表示されます。

4. Oracle Portalの構成が終了した後、構成を実施したユーザーのエントリを再編集して権限を削除できます。初期構成が完了すればこの権限は不要になります。

7.3 Oracle Portalのセキュリティの構成

この項では、Oracle Portalの構成上の考慮事項について説明します。

- Oracle Portalのセキュリティ・オプションの構成

- Oracle Fusion Middleware Security Frameworkのオプションの構成

- データベースのセキュリティのためのOracle Portalオプションの構成

7.3.1 Oracle Portalのセキュリティ・オプションの構成

この項には次の項目が含まれています。

- 「グローバル設定」ページの設定の変更

- ロール・ベースのアクセス制御の適用

- プロバイダのメッセージ認証の構成

7.3.1.1 「グローバル設定」ページの設定の変更

Oracle Portalをインストールし、第7.3.2.3項「インストール後のセキュリティのチェックリスト」にある適切なタスクを実行すると、Oracle Portalの「グローバル設定」ページでセキュリティに関連する次のすべての設定を変更できます。

- Oracle Internet Directoryパラメータのキャッシュ

- Oracle Directory Integration Platformの同期化

- グループ検索ベースの識別名(DN)

- グループ作成ベースの識別名(DN)

7.3.1.1.1 Oracle Internet Directoryパラメータのキャッシュ

第7.1.7項「Oracle Identity Managementインフラストラクチャの利用」で説明したように、Oracle Portalではディレクトリからの情報のキャッシュを管理しています。「グローバル設定」ページで、このキャッシュをディレクトリからの更新済の情報で更新することができます。「OIDパラメータ用キャッシュのリフレッシュ」では、ディレクトリからの最新のパラメータ値でキャッシュがただちに更新されます。キャッシュされた情報は比較的静的な情報であるため、キャッシュを頻繁に更新する必要はありません。

7.3.1.1.2 Oracle Directory Integration Platformの同期化

Oracle Portalではグループ・メンバーシップの情報をキャッシュするため、ディレクトリでその情報が変更されたらキャッシュが更新されるメカニズムを必要とします。Directory Integration Serverでは、Oracle Portalに反映する必要がある変更がディレクトリで行われるたびにOracle Portalに通知します。「グローバル設定」では、次の設定を行うことができます。

- 「ディレクトリ同期の有効化」: 関連する変更がディレクトリで行われたときにDirectory Integration ServerがOracle Portalに通知するかどうかを定義します。この設定を選択しないと、Directory Integration ServerによってサブスクライブされたイベントがOracle Portalに通知されません。Oracle Portalの構成が適切であり、かつサポートされている場合には、このオプションを有効にする必要があります。

- 「イベント通知の送信頻度n秒」: 関連する変更をOracle Portalに通知するためにDirectory Integration Serverによってイベント通知が送信される時間間隔を定義します。この設定は、「ディレクトリ同期の有効化」が選択されている場合にのみ利用できます。

次の設定により、ログイン・パフォーマンスに対応して、グループのプロビジョニング変更の影響がユーザーの認可に反映されるまでの時間を指定できます。

ロール・メンバーの遅延同期を有効にする

ユーザーのグループ・メンバーシップがポータルで更新されるのは、Oracle Internet Directoryでのグループ・メンバーシップの変更後のログインとその次のログインのみです。認可の変更は、次のログインで反映されます。ログイン・イベント間にユーザーのグループの更新が行われなかった場合、その後のログインでは、いずれかのユーザーのグループに対して変更が行われるまで、ユーザーのグループに対して再び問合せが行われることはありません。

ロール・メンバーの即時同期を有効にする

ユーザーのグループ・メンバーシップはログインごとに更新されます。また、グループの更新通知をOracle Internet DirectoryからPortalが受信したときにも更新されます。このモードは、Oracle Internet Directoryの更新後すぐに認可の更新を適用する必要がある場合(考えられるのは、現在のセッション内でユーザーの認可を変更する場合)にのみ設定することをお薦めします。

ログインのたびにロール・メンバーの同期を有効にする

ユーザーのグループ・メンバーシップは、ログインごとにポータルで更新され、グループがOracle Internet Directoryで更新された次のログインで有効になります。

ユーザーのグループ・メンバーシップは、ログインごとにポータルで、そのセッションの間、有効なグループ・メンバーシップの更新セットを反映して更新されます。Oracle Internet Directoryに対して、必要か不要かに関係なく、ログインごとにグループ・メンバーシップの現在のセットを問い合せます。なんらかの理由により、ユーザーのグループ・メンバーシップがPortalに正しく反映されない場合は、ログインごとに正しいセットを使用して再確立が行われます。

表7-18では、ログイン・パフォーマンスと、各設定でユーザーの認可が更新される速度のトレードオフを比較しています。

表7-20 同期設定の比較

設定

説明

遅延同期

ベスト・パフォーマンス - このユーザーに影響を与えるグループ・メンバーシップ変更が行われた後にのみログインが遅くなります。

即時同期

この設定は、パフォーマンスに対する影響が最大になります。グループ同期化の更新がユーザーのセッション内で行われることがあり、また更新はログインごとに行われ、最も迅速な効果が得られるために、DIPの同期化間隔とWebキャッシュの弱い無効化間隔をかなり低く設定する必要があるので、これらのイベントの頻度が増加するからです。

ログインごとの同期化

ベースライン・パフォーマンス - 以前のリリースと整合性があります。

Oracle Directory Integration and Provisioningサーバーが稼働していて、Oracle Portalを使用できるように構成されているときは、Oracle Internet Directoryでグループ・メンバーシップが変更されると、Oracle Portalで弱いキャッシュの無効化が行われます。

関連項目:

- 第1.3.3項「Oracle Portalにおけるキャッシュの無効化の理解」

- 第6.7項「Oracle Web CacheにキャッシュされたOracle Portalコンテンツの管理」

- 第7.1.7.4項「Oracle PortalとOracle Directory Integration Platformの関係」

次に、グループ・メンバーシップのキャッシュの無効化の例を示します。

- ユーザーをグループに追加すると、Oracle Directory Integration and Provisioningサーバーではその変更をOracle Portalに通知します。そうするとOracle Portalでは、弱い無効化ジョブによって処理される弱い無効化メッセージを1つ発行します。これは、このユーザーが持っている新しい権限が、表示できるデータに影響を与える可能性があるからです。

- グループ_Aをグループ_Bに追加すると、Oracle Directory Integration and Provisioningサーバーではその変更をOracle Portalに通知します。そうするとOracle Portalでは、グループ_Aの各ユーザーに弱い無効化メッセージを発行します。これは、グループ_Aのユーザーが持っている新しい権限が、表示できるデータに影響を与える可能性があるからです。

7.3.1.1.3 グループ作成ベースの識別名(DN)

Oracle Portalでは、ディレクトリ内のユーザー・グループの情報を管理しています。「グループ」ポートレットを使用してグループを作成すると、それらはLDAPのディレクトリ情報ツリー(DIT)のノードの下に作成されます。ノードは、その識別名(DN)によって識別されます。このため、Oracle Portalでは、どのノードにグループを作成するかを指定する必要があります。

「グループ作成ベースDN」は、Oracle Portalで管理するユーザー・グループが含まれているノードのDNです。例:

cn=portal.040820.123756.096286000,cn=Groups,dc=MyCompany,dc=com

この設定は、Oracle Portalを既存のDITと対話するように構成する場合に特に役立ちます。

7.3.1.1.4 グループ検索ベースの識別名(DN)

どのノードにグループを作成するのかを定義する必要があるのと同様に、Oracle Portalでどのノードで既存のグループを検索するのかも定義する必要があります。たとえば、「グループ」ポートレットにグループの値リストが表示されているときにOracle Portalでどこを検索するのかを指定する必要があります。

「ローカル・グループ検索ベースDN」は、Oracle Portalで管理するユーザー・グループが含まれているノードのDNです。例:

cn=portal.040820.123756.096286000,cn=Groups,dc=MyCompany,dc=com

この設定は、Oracle Portalを既存のDITと対話するように構成する場合に特に役立ちます。

7.3.1.2 ロール・ベースのアクセス制御の適用

Oracle Portal 10g リリース2 (10.1.2)以降では、ロール・ベースのアクセス制御の適用を有効化または無効化できます。このオプションは、デフォルト構成では無効です。ロール・ベースのアクセス制御では、オブジェクト・レベルの権限やグローバル権限を、Oracle Portalのユーザー・インタフェースからユーザーに直接割り当てることを禁止し、グループにのみ権限を付与するように強制できます。ただし、このオプションは、ユーザーに直接付与される次のような権限には影響しません。

- ロール・ベースのアクセス制御が有効になる前の権限

- オブジェクトの作成時に自動で付与される権限

- Oracle Portal APIの使用を通じて付与される権限

ロール・ベースのアクセス制御の有効と無効を切り替えるには、ORACLE_HOME/portal/admin/plsql/wwcディレクトリのsecrlacl.sqlスクリプトを実行する必要があります。secrlacl.sqlの構文は、次のとおりです。

@secrlacl.sql Y|N

たとえば、ロール・ベースのアクセス制御を有効にする場合、次のようにスクリプトを実行します。

@secrlacl.sql Y

ロール・ベースのアクセス制御が有効になると、Oracle Portalが次のように変化します。

- オブジェクトの「アクセス」タブ。ここには、グループのLOVのみが表示され、ユーザーのLOVは表示されません。

- 「権限」タブは、ユーザー・プロファイルの編集ページに表示されません。

7.3.1.3 プロバイダのメッセージ認証の構成

HMAC対応の通信を行うプロバイダ・サービスには、追加の構成が必要です。Basic認証または拡張認証を設定できます。

7.3.1.3.1 Basic認証

JPDKプロバイダ・コードがoracle.portal.provider.v2.render.PortletRenderRequestオブジェクトのoracle.portal.provider.v2.ProviderUserを経由してポータル・ユーザーのIDを受け入れ、このIDを使用して機密情報を取り扱う操作を実行する場合は、Basicメッセージ認証を使用するようにポータルとこのプロバイダを構成する必要があります。Basicメッセージ認証ではHashed Message Authentication Code(HMAC)を利用します。HMACは、暗号化ハッシュ関数を使用してメッセージ認証を行い、メッセージの整合性を保証するメカニズムです。

HMACを使用したBasic認証を構成するには、JPDK WebプロバイダとOracle Portalの両方を次のように構成する必要があります。

JPDK Webプロバイダ

JPDK Webプロバイダでは、WebプロバイダのJNDI環境変数として、共有キーをweb.xmlファイルに追加します。web.xmlの中でこの環境エントリを追加する場所は、ファイル末尾近くにある、表7-21に太字で示されている場所です。この表は、web.xmlの中で各要素が占める相対的な順序を示しています。

表7-21 web.xml内の要素の相対順

要素名

icon?

display-name?

description?

distributable?

context-param*

filter*

filter-mapping*

listener*

servlet*

servlet-mapping*

session-config?

mime-mapping*

welcome-file-list?

error-page*

taglib*

resource-env-ref*

resource-ref*

security-constraint*

login-config?

security-role*

env-entry*

ejb-ref*

ejb-local-ref*

JNDI環境変数の定義をweb.xmlファイルに追加するには、次のenv-entry要素を適切な場所に追加します。

<env-entry>
<env-entry-name>oracle/portal/provider/service_name/sharedKey</env-entry-name>
<env-entry-value>shared_key_value</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

例7-2に示すように、サービス名と共有キーの値を入力します。

例7-2 web.xmlへのJNDI環境変数の定義の追加

<env-entry>
<env-entry-name>oracle/portal/provider/sample/sharedKey</env-entry-name>
<env-entry-value>1234567890abcdeFGHIJ</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

この例では、sampleはプロバイダのサービス名、1234567890abcdeFGHIJは共有キーの値です。HMACの計算に使用する共有秘密鍵の値には、10から20文字の英数字を指定する必要があります。

例7-3に示すように、保護するプロバイダ・インスタンスごとに、この環境変数を定義する必要があります。

例7-3 web.xmlでの複数プロバイダ・インスタンスに対するJNDI環境変数の定義

<env-entry>
<env-entry-name>oracle/portal/provider/provider0/sharedKey</env-entry-name>
<env-entry-value>1234567890abcdeFGHIJ</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

<env-entry>
<env-entry-name>oracle/portal/provider/provider1/sharedKey</env-entry-name>
<env-entry-value>0987654321abcdeFGHIJ</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

<env-entry>
<env-entry-name>oracle/portal/provider/provider2/sharedKey</env-entry-name>
<env-entry-value>123123123123</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

または、プロバイダのプロパティsharedKeyを.propertiesファイルに追加することもできます。これを行うには、次の手順を実行します:

1. ファイル<app_root>/WEB-INF/deployment/service_name.propertiesを開きます。(service_nameはプロバイダのサービス・インスタンス名に置き換えてください。)

2. 次の例に示すように、プロバイダのプロパティsharedKeyと共有キーの値を追加します。

sharedKey=1234567890abcdeFGHIJ

このプロパティは、各service_name.propertiesファイルで、保護するプロバイダ・インスタンスごとに設定する必要があります。

注意:

この代替手法の短所として、JNDI環境エントリではプロバイダの環境変数を管理できるにもかかわらず、Oracle Fusion Middleware Controlを使用するとこれらの環境変数を管理できないという点があります。

Oracle Portal

次の手順を実行して、Oracle Portalでプロバイダを登録し、共有キーとログイン周期を設定します。

1. 「Portalビルダー」で「管理」タブをクリックして、「ポートレット」サブタブをクリックします。

2. 「リモート・プロバイダ」ポートレットの「プロバイダの登録」をクリックします。

3. 「プロバイダの登録」ページでプロバイダの詳細を入力して、「次へ」をクリックします。

4. 「一般プロパティ」セクションで、「共有キー」に秘密鍵の値を入力します。

5. 「ユーザー/セッション情報」セクションの「ログイン周期」で、「ユーザー・セッションごとに1回」を選択します。

6. ウィザードの手順に従って、「終了」をクリックします。

7.3.1.3.2 拡張認証

JPDK Webプロバイダ・コードがJAZN-LDAP用に構成されているWLSコンテナで実行されており、プロバイダ・コードがJ2EEセキュリティを使用しているか、HttpServletRequestオブジェクトのgetRemoteUser()メソッドまたはgetUserPrincipal()メソッドを経由してユーザーのIDを取得する場合は、拡張メッセージ認証を使用するようにポータルとこのプロバイダを構成する必要があります。また、『Oracle Fusion Middleware Oracle Portal開発者ガイド』に説明されているように、プロバイダでLDAP (Oracle Internet Directory)セキュリティ機能を使用している場合にも拡張メッセージ認証を構成する必要があります。拡張メッセージ認証では、認証されたユーザーIDをプロバイダに伝播するための追加のヘッダーの整合性が保護されます。

HMACを使用した拡張認証を構成するには、JPDK WebプロバイダとOracle Portalの両方を構成する必要があります。

JPDK Webプロバイダ

JPDK Webプロバイダを構成するには、次の手順を実行します。

1. JPDK Webプロバイダでは、WebプロバイダのJNDI環境変数として、共有キーをweb.xmlファイルに追加します。web.xmlの中でこの環境エントリを追加する場所は、表7-21に示す、ファイルの末尾近くです。この表は、web.xml内で各要素が占める相対的な順序を示しています。
JNDI環境変数の定義をweb.xmlファイルに追加するには、次のenv-entry要素を適切な場所に追加します。

<env-entry>
<env-entry-name>oracle/portal/provider/service_name/sharedKey</env-entry-name>
<env-entry-value>shared_key_value</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

例7-2に示すように、サービス名と共有キーの値を入力します。

例7-2では、sampleがプロバイダのサービス名、1234567890abcdeFGHIJが共有キーの値です。HMACの計算に使用する共有秘密鍵の値には、10から20文字の英数字を指定する必要があります。

例7-3に示すように、保護するプロバイダ・インスタンスごとに、この環境変数を定義する必要があります。

または、プロバイダのプロパティsharedKeyを.propertiesファイルに追加することもできます。これを行うには、次の手順を実行します:

1. ファイル<app_root>/WEB-INF/deployment/service_name.propertiesを開きます。(service_nameはプロバイダのサービス・インスタンス名に置き換えてください。)

2. 次の例に示すように、プロバイダのプロパティsharedKeyと共有キーの値を追加します。

sharedKey=1234567890abcdeFGHIJ

このプロパティは、各service_name.propertiesファイルで、保護するプロバイダ・インスタンスごとに設定する必要があります。

注意:

この代替手法の短所として、JNDI環境エントリではプロバイダの環境変数を管理できるにもかかわらず、Oracle Fusion Middleware Controlを使用するとこれらの環境変数を管理できないという点があります。

2. プロバイダのプロパティenhancedAuthenticationを.propertiesファイルに追加します。これを行うには、次の手順を実行します:

1. ファイル<app_root>/WEB-INF/deployment/service_name.propertiesを開きます。(service_nameはプロバイダのサービス・インスタンス名に置き換えてください。)

2. 次の例に示すように、プロバイダのプロパティenhancedAuthenticationを追加してtrueに設定します。

enhancedAuthentication=true

このプロパティは、各service_name.propertiesファイルで、保護するプロバイダ・インスタンスごとに設定する必要があります。

Oracle Portal

次の手順を実行して、Oracle Portalでプロバイダを登録し、共有キーとログイン周期を設定します。

1. 「Portalビルダー」で「管理」タブをクリックして、「ポートレット」サブタブをクリックします。

2. 「リモート・プロバイダ」ポートレットの「プロバイダの登録」をクリックします。

3. 「プロバイダの登録」ページでプロバイダの詳細を入力して、「次へ」をクリックします。

4. 「一般プロパティ」セクションで、「共有キー」に秘密鍵の値を入力します。

5. 「ユーザー/セッション情報」セクションの「ログイン周期」で、「ユーザー・セッションごとに1回」を選択します。

6. ウィザードの手順に従って、「終了」をクリックします。

7.3.2 Oracle Fusion Middleware Security Frameworkのオプションの構成

Oracle Portalを構成するときは、Oracle Fusion Middleware Security Frameworkを利用する次のオプションを考慮する必要があります。

- Oracle PortalのSSLの構成

- Oracle Internet Directoryへの接続の保護(オプション)

- インストール後のセキュリティのチェックリスト

7.3.2.1 Oracle PortalのSSLの構成

次の項では、Oracle Portalの最も一般的なSSL構成の概要と、それらを実装するために必要な手順について説明します。

- 第7.3.2.1.1項「SSLの構成の概要」

- 第7.3.2.1.2項「OracleAS Single Sign-OnとのSSL接続」

- 第7.3.2.1.3項「Oracle Access ManagerとのSSL接続」

- 第7.3.2.1.4項「Oracle Web CacheとのSSL接続」

- 第7.3.2.1.5項「Oracle PortalのエンドツーエンドSSL」

- 第7.3.2.1.6項「Oracle Fusion Middleware内では非SSLの外部SSL」

- 第7.3.2.1.7項「Oracle WebLogic管理対象サーバーのSSLの構成」

- 第7.3.2.1.8項「SSLを介して公開されるWebプロバイダ、プロバイダ・グループおよびWSRPプロデューサの構成と登録」

7.3.2.1.1 SSLの構成の概要

Oracle Portalでは、多くの様々なコンポーネント(Parallel Page Engine、Oracle HTTP Server、Oracle Web Cacheなど)を使用しますが、それらの各コンポーネントはHTTP通信でクライアントまたはサーバーの役目を果たすことがあります。このため、Oracle Fusion Middlewareの中間層にある各コンポーネントを、HTTPではなくHTTPSプロトコルで個別に構成する場合があります。

Oracle Portalとの対話処理では、様々なネットワーク・ホップを実行します。これらのホップは次のとおりです。

- クライアント・ブラウザと、ポータル環境のエントリ・ポイントの間。次のいずれかです。

- Oracle Web Cache

- リバース・プロキシやSSLアクセラレータなどのネットワーク端のハードウェア・デバイス

- Oracle Fusion Middleware中間層のOracle Web CacheとOracle HTTP Serverの間

- クライアント・ブラウザと、OracleAS Single Sign-OnまたはOracle Internet Directory(またはインフラストラクチャ)層のOracle HTTP Serverの間

- 中間層のParallel Page Engine (PPE)とOracle Web Cacheまたはフロントエンドのリバース・プロキシの間のループバック

- Parallel Page Engine (PPE)と、ポートレット・コンテンツを生成するリモートWebプロバイダの間

- Oracle PortalインフラストラクチャとOracle Internet Directoryの間

SSL使用上の制限

- 部分的なSSL構成モードの場合、Parallel Page Engineの下では外部JavaServer Pagesが機能しません。それらは、Oracle Portal全体でSSLを使用している場合にのみ機能します。ロード・バランシング・ルーターを使用している環境でSSLを外部実装した場合は、内部JavaServer Pagesのみが機能します。
このことから、第7.3.2.1.2項「OracleAS Single Sign-OnとのSSL接続」、第7.3.2.1.5項「Oracle PortalのエンドツーエンドSSL」、および第7.3.2.1.6項「Oracle Fusion Middleware内では非SSLの外部SSL」で取り上げているSSL構成でのみ、外部JSPを使用するようにします。

- ssl.confファイルのデフォルト設定を使用すると、HP-IA上で実行されるOracle Portalサーバーには、Microsoft Internet Explorerからアクセスできません。この問題を回避するには、次のようにしてssl.confファイルから行downgrade-1.0 force-response-1.0を削除します。
修正前

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

修正後

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown

SSLを構成する前の確認事項

推奨される方法に従ってSSLを構成する前に、デフォルトの非SSL構成で、Oracle Portalが正常に動作することを確認する必要があります。そのためには、次のポータル・タスクを正常に実行できるかどうかを確認します。

- Oracle Portalのホーム・ページにアクセスできる

- ユーザーはOracle Portalにログインできる

- コンテンツの編集が即座に表示される

7.3.2.1.2 Oracle Single Sign-OnとのSSL接続

接続をSSLで保護する必要があるとすれば、それはブラウザとOracleAS Single Sign-Onの間の接続です。ブラウザとOracleAS Single Sign-Onの間での送信中は、SSLによってパスワードが保護される必要があります。最低レベルのセキュリティでも、このオプションを使用してインストールを構成する必要があります。この後のすべてのSSLの構成では、SSLがOracleAS Single Sign-Onに対応するように構成されているものとします。

図7-19は、SSLを使用できるように構成されたOracleAS Single Sign-Onを示しています。

図7-19 OracleAS Single Sign-Onとの保護された接続

「SSLを構成する前の確認事項」で示した事項を確認したら、次のいずれかの手順を使用してOracleAS Single Sign-OnとのSSL接続を構成できます。

- SSLConfigToolを使用したOracleAS Single Sign-OnのSSL構成

- 手動でのOracleAS Single Sign-OnのSSL構成

SSLConfigToolを使用したOracleAS Single Sign-OnのSSL構成

注意:

このOracleAS Single Sign-On中間層パートナ・アプリケーションはまだ非SSLなので、非SSLとして再登録する必要があります。つまり、mod_ossoを再登録するときには、ssoregのmod_osso_urlパラメータとしてOracleAS Single Sign-On中間層の非SSL URLを指定する必要があります。

詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のmod_ossoの登録に関する項を参照してください。

SSLConfigToolを使用してOracleAS Single Sign-OnにSSLを構成するには、次の手順を実行します。

1. Oracle Fusion Middleware InfrastructureでSSLConfigToolスクリプトを実行します。

1. Identity ManagementがインストールされているOracleAS InfrastructureでSSLを有効にします。次のWindowsの例に示すように、インフラストラクチャのOracleホームでSSLConfigToolを実行します。

SSLConfigTool.bat -config_w_default -opwd <fmwadmin_pwd>

説明:

- config_w_defaultは、portlist.iniファイルに指定された値を使用して、ツールをサイレント・モードで実行します。

- opwdはOracle管理者パスワードです。パスワードを指定しないと指定を求められます。

関連項目:

Oracle Fusion Middleware管理者ガイド

『Oracle Application Server Single Sign-On管理者ガイド』のSSLの有効化に関する説明。リバース・プロキシ・サーバーの内側でOracleAS Single Sign-Onを構成する場合は、『Oracle Application Server Single Sign-On管理者ガイド』のプロキシ・サーバーと組み合せたOracleAS Single Sign-Onの配置に関する説明を参照してください。

2. Identity ManagementがインストールされているOracleAS InfrastructureでSSLを有効にした場合、OracleAS Single Sign-On URLを保護する必要があります。これを行うには、『Oracle Application Server Single Sign-On管理者ガイド』のシングル・サインオンURLの保護に関する項を参照してください。

2. ウォレットを作成します。詳細は、「空のウォレットの作成(HTTPS)」を参照してください。

3. OracleAS Single Sign-Onの証明書の発行者が、「信頼できる証明書」リストに存在することを確認します。このリストにない場合は、「ウォレットへの信頼できるルート証明書の追加(HTTPS)」に示すように、信頼できるルート証明書をウォレットに追加する必要があります。

4. 「Portalリポジトリのプリファレンス・ストアでのウォレットのパスとパスワードの更新」の説明に従ってウォレットのパスとパスワードを更新します。

5. 「Oracle HTTP Serverパートナ・アプリケーションの再登録」の説明に従ってOracle HTTP Serverを再登録します。

6. Oracle Internet Directoryで、cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContextエントリのorcldasurlbase属性の更新が必要になる場合があります。HTTPSポートを使用するように設定されていない場合は、Oracle Internet Directoryパラメータのキャッシュをリフレッシュする必要があります。更新するには、次の手順を実行します。

1. Oracle Directory Manager(統合管理ツール: Windowsの場合はOracle Directory Manager、UNIXの場合はINFRA_ORACLE_HOME/bin/oidadmin)を使用し、Oracle Directory Managerを実行して、cn=fmwadminとしてログインします。

2. 「エントリ管理」で、cn=OracleContext→cn=Products→cn=DAS→cn=OperationURLsに移動します。

3. orcldasurlbaseエントリに、インフラストラクチャ層で使用されているHTTPSポート(https://<infrahost>:<port>/)が反映されているかどうかを確認します。

orcldasurlbaseエントリにHTTPSポートが反映されていない場合は、それをOracle Internet Directoryで変更し、関連するOracle Internet Directory情報を格納したポータル・キャッシュをリフレッシュする必要があります。このポータル・キャッシュをリフレッシュするには、次の手順を実行します。

1. 管理者権限を持つユーザーとしてOracle Portalにログオンします。

2. 「Portalビルダー」ページで「管理」タブをクリックします。

3. 「ポータル」タブから、「グローバル設定」を開き、「SSO/OID」タブに移動します。

4. ページの一番下までスクロールします。

5. 「OIDパラメータのキャッシュ」で「OIDパラメータ用キャッシュのリフレッシュ」を選択します。

6. 「適用」をクリックします。

7. 「DASホスト名」フィールドの適切な値でページが更新されます。

これで、OracleAS Single Sign-OnとのSSL通信の構成が完了しました。

注意:

ページに正しいSSO URLを表示するため、Portal modplsqlキャッシュをクリアする必要があります。

次の例は、UNIX上でPortal modsqlをクリアする方法を示しています。

cd $INSTANCE_HOME/portal/cache
rm –rf ./session/*
rm -rf ./plsql/*
rm -rf ./pmd/*

WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化

1. 次の手順を実行して、WebLogicプラグインを有効化します。

1. WebLogic管理コンソールにログインします。

2. 「チェンジ・センター」ペインの「ロックして編集」を選択していない場合は選択します。

3. 「ドメイン構造」ペインで、「環境」ノードを開き、「クラスタ」を選択します。
ドメインに構成されているクラスタのリストが表示されます。

4. cluster_portalをクリックします。

5. ページ下部近くの「詳細」リンクを開きます。

6. 「WebLogicプラグインの有効化」オプションを選択します。

7. 「保存」をクリックします。

2. 次の例に示すように、ORACLE_INSTANCE/config/OHS/OHS Name/moduleconf/portal.confのWLS routing configurationセクションで、WLProxySSLPassThroughおよびWebLogic ProxySSLのパラメータをONに設定します。

# WLS routing configuration
<Location /portal>
SetHandler weblogic-handler
WebLogicCluster <HostName>:<Weblogic portal ClusterPort>
WLProxySSL On
WLProxySSLPassThrough ON
</Location>

3. Oracle WebLogic管理コンソールを使用して、WLS_PORTALを再起動します。
次のコマンドを使用して、Oracle HTTPを再起動します。

ORACLE_INSTANCE/bin/opmnctl stopall
ORACLE_INSTANCE/bin/opmnctl startall

手動でのOracleAS Single Sign-OnのSSL構成

このオプションを手動で構成する場合は、『Oracle Application Server Single Sign-On管理者ガイド』のSSLの有効化に関する項を参照してください。リバース・プロキシ・サーバーの内側でOracleAS Single Sign-Onを構成する場合は、『Oracle Application Server Single Sign-On管理者ガイド』のプロキシ・サーバーと組み合せたOracleAS Single Sign-Onの配置に関する説明を参照してください。

注意:

このOracleAS Single Sign-On中間層パートナ・アプリケーションはまだ非SSLなので、非SSLとして再登録する必要があります。つまり、mod_ossoを再登録するときには、ssoregのmod_osso_urlパラメータとしてOracleAS Single Sign-On中間層の非SSL URLを指定する必要があります。

詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のmod_ossoの登録に関する項を参照してください。

Oracle Portalのこのリリースでは、OracleAS Single Sign-OnのURLへのアクセスでHTTPまたはHTTPSのどちらを使用するかを、ポータルを構成するときに選択できます。次の手順では、各構成に必要な手順を示します。

- 空のウォレットの作成(HTTPS)

- ウォレットへの信頼できるルート証明書の追加(HTTPS)

- Portalリポジトリのプリファレンス・ストアでのウォレットのパスとパスワードの更新

- Oracle HTTP Serverパートナ・アプリケーションの再登録(HTTPおよびHTTPS)

- WebLogicプラグインの有効化(HTTPS)

- ウォレットのパスとOracleAS Single Sign-Onの問合せパスURLの確認(HTTPおよびHTTPS)

- Oracle Internet DirectoryでのOracle Delegated Administration ServicesのURLベース・エントリの条件付き更新(HTTPおよびHTTPS)

空のウォレットの作成(HTTPS)

この項の手順は、OracleAS Single Sign-OnでHTTPSポートを使用する場合にのみ実行してください。この手順は、SSLを使用するようOracleAS Single Sign-Onを構成した後に実行します。

空のウォレットを作成して、OracleAS Single Sign-OnへのSSLアクセスのトラスト・ポイントを確立します。これを行うには、次の手順を実行します:

1. Oracle Wallet Manager(ORACLE_HOME\bin\owm)を開きます。生成したウォレットにOracle Metadata Repositoryのポータル・スキーマからアクセスできるかぎり、Oracle Wallet Managerはどこからでも実行できます。ウォレット(ウォレット・ファイルを格納したディレクトリ)を任意の場所に保存して、Oracle Metadata Repositoryのポータル・スキーマからアクセス可能な別の場所に移動することもできます。

2. 「ウォレット」→「新規」を選択します。
UNIXの場合、ウォレットはデフォルトで次の場所に格納されます。

/etc/ORACLE/WALLETS/<Account Name creating the Wallet>

Windowsの場合、ウォレットはデフォルトで次の場所に格納されます。

\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS

3. ウォレットのパスワードを作成します。

4. 同じパスワードを「パスワードの確認」フィールドに入力します。

5. 「ウォレット・タイプ」に「標準」を選択します。

6. 「OK」をクリックします。

7. 証明書リクエストの作成を求められたら、「いいえ」をクリックします。

8. OracleAS Single Sign-Onの証明書の発行者が、「信頼できる証明書」リストに存在することを確認します。このリストにない場合は、「ウォレットへの信頼できるルート証明書の追加(HTTPS)」に示すように、信頼できるルート証明書をウォレットに追加する必要があります。

9. このウォレットを次のように、適切なディレクトリに保存します。

INFRA_ORACLE_HOME\wallets

10. 「ウォレット」、「保存」の順に選択します。

11. 「ウォレット」を選択し、「自動ログイン」を選択していない場合は選択します。

ウォレットへの信頼できるルート証明書の追加(HTTPS)

この項の手順は、認証局の発行したOracleAS Single Sign-Onサーバーの信頼できるルート証明書が「信頼できる証明書」リストに含まれていない場合にのみ実行してください。この場合は、次の手順に示すように信頼できるルート証明書をウォレットに追加する必要があります。この手順は、Internet Explorerブラウザに基づいています。

1. ブラウザを使用して、https://infra.domain.com/pls/orassoにあるOracleAS Single Sign-Onのホーム・ページにアクセスします。これがHTTPS URLにあることを確認します。

1. サーバーの証明書がブラウザによって自動的に信頼されない場合は、「セキュリティの警告」ダイアログ・ボックスが表示されます。

2. 「証明書の表示」をクリックします。

3. 「証明のパス」タブをクリックします。

4. リストの最初の証明書である証明機関のルートを選択します。

5. 「証明書の表示」をクリックします。

6. 「証明書のインストール」をクリックします。
これによって、「証明書のインポート ウィザード」が表示されます。ウィザードによって、ブラウザの信頼できる認証機関リストに証明書がインポートされます。

7. 「次へ」をクリックします。

8. 「証明書の種類に基づいて、自動的に証明書ストアを選択する」を選択します。

9. 「次へ」をクリックします。

10. 「終了」をクリックします。
信頼できるルート証明書がブラウザにインストールされます。

2. ステータス・バーのロック・アイコンをクリックすると、「証明書」ダイアログ・ボックスが表示されます。

3. 「証明のパス」タブをクリックします。

4. リストの最初の証明書である証明機関のルートを選択します。

5. 「証明書の表示」をクリックします。

6. 「詳細」タブをクリックします。

7. 「ファイルにコピー」をクリックします。
これによって、「証明書のエクスポート ウィザード」が表示されます。

8. 「次へ」をクリックします。

9. 「使用する形式を選択してください」で「Base 64 encoded X.509 (.CER)」を選択します。

10. 「次へ」をクリックして、証明書のファイル名を指定します。証明書には、.cer拡張子を持つ任意のファイル名を指定できます。

11. 「次へ」をクリックして、「完了」をクリックします。

この時点で、.cer証明書ファイルが作成されます。このファイルには、信頼できる証明機関のルート証明書が含まれています。この証明書を、ウォレットの信頼できる証明書リストに追加する必要があります。追加するには、Wallet Managerがすでに実行され、空のウォレットが開いている状態で次の手順を実行します。

1. 「信頼できる証明書」ノードを右クリックします。

2. 「信頼できる証明書のインポート」を選択します。

3. 「証明書の貼付け」を選択し、「OK」をクリックします。

4. 以前作成した証明書ファイルの内容をBASE64形式の証明書のテキスト領域にコピーし、「OK」をクリックします。

5. 信頼できる証明書のリストに証明機関のルートが追加されていることを確認します。

6. ウォレットを保存します。

Portalリポジトリのプリファレンス・ストアでのウォレットのパスとパスワードの更新

この項の手順は、OracleAS Single Sign-OnでHTTPSポートを使用する場合にのみ実行してください。この手順は、SSLを使用するようOracleAS Single Sign-Onを構成した後に実行します。

Oracle Portal中間層ホームから次のスクリプトを使用して、Portalリポジトリのプリファレンス・ストアにあるウォレットのパスとパスワードを更新します。

cd $ORACLE_HOME/portal/admin/plsql/wwc
sqlplus <portal_schema/<portal_pwd>@connectstring
sql> @secwc.sql <wallet_location> <wallet_pwd>

例7-4 更新されたウォレットのパス

@secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet''welcome1'

Oracle HTTP Serverパートナ・アプリケーションの再登録 (HTTPおよびHTTPS)

ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義します。ssoregは、ORACLE_HOME/sso/binにあります。

次の例は、UNIX上でのssoregの使用方法を示しています。

ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com
-config_mod_osso TRUE
-mod_osso_url http://www.abc.com:8090
-remote_midtier
-config_file ORACLE_INSTANCE/conf/OHS/ohs1/osso.conf
-admin_info cn=orcladmin

Windowsでは、このかわりにssoreg.batバッチ・ファイルを実行する必要があります。詳細は、Oracle Application Server Single Sign-On管理者ガイドを参照してください。

WebLogicプラグインの有効化(HTTPS)

「WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化」を参照してください。

ウォレットのパスとOracleAS Single Sign-Onの問合せパスURLの確認(HTTPおよびHTTPS)

Oracle Portalでは、データベースからコールを介して特定の情報にアクセスするためのOracleAS Single Sign-OnのURL接頭辞を、UTL_HTTPパッケージを使用して管理しています。このインタフェースを介して行われるコールは、次の理由で欠かすことができません。

- 外部アプリケーションのリストを取得して、「外部アプリケーション」ポートレットのカスタマイズができるようにします。

- OracleAS Single Sign-Onのユーザー名を外部アプリケーションのユーザー名にマップします。

ウォレットのパスおよびOracleAS Single Sign-Onの問合せパスのURLを確認するには、次の手順を実行します。

1. ポータル管理者としてOracle Portalにログインします。

2. 「管理」タブをクリックします。

3. 「ポータル」タブをクリックします。

4. 「サービス」ポートレットの「グローバル設定」をクリックします。

5. 「SSO/OID」タブをクリックします。

6. 「SSO Server設定」セクションに、適切な値が表示されます。

Oracle Internet DirectoryでのOracle Delegated Administration ServicesのURLベース・エントリの条件付き更新(HTTPおよびHTTPS)

OracleAS Single Sign-On上でSSLを有効にしたら、これ以降に認証をリクエストしたときに各パートナ・アプリケーションが更新済のSSLログインURLを取得できるように、すべてのOracleAS Single Sign-Onパートナ・アプリケーションを再登録する必要があります。

インフラストラクチャ層のOracle HTTP ServerのSSLを有効にしたら、インフラストラクチャ層のmod_ossoを含むすべてのパートナ・アプリケーションを再登録する必要があります。Oracle Delegated Administration Servicesにアクセスするときに、非SSLモードまたはSSLモードを選択できます。Oracle Delegated Administration ServicesのベースURLは、Oracle Internet Directoryに格納されます。このベースURLを基にして、他のアプリケーションからOracle Delegated Administration Services機能に接続するときに表示されるURLが決まります。

SSLモードでOracle Delegated Administration Servicesにアクセスする場合は、mod_ossoを再登録するときに、ssoregのmod_osso_urlパラメータとしてSSL URLを指定する必要があります。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のmod_ossoの登録に関する項を参照してください。

SSLモードでOracle Delegated Administration Servicesにアクセスする場合は、その設定を行うために、Oracle Internet Directory内のcn=OperationURLs, cn=DAS, cn=Products, cn=OracleContextエントリのorcldasurlbase属性を更新する必要があります。この属性値は、Oracle Portalによって、後続のOracle Delegated Administration ServicesのURLの生成に使用されます。この手順は、インフラストラクチャ層のOracle HTTP ServerもHTTPSポートでリスニングしていることを前提とします。

1. この手順では、Oracle Directory Manager(統合管理ツール: Windowsの場合はOracle Directory Manager、UNIXの場合はINFRA_ORACLE_HOME/bin/oidadmin)を使用する必要があります。Oracle Directory Managerを実行し、cn=orcladminとしてログインします。

2. 「エントリ管理」で、cn=OracleContext→cn=Products→cn=DAS→cn=OperationURLsに移動します。

3. orcldasurlbaseエントリを更新して、HTTPSポート(https://<infrahost> :<port> /)がインフラストラクチャ層で使用されるように反映させます。

Oracle Internet Directoryでエントリを更新したら、ポータル・キャッシュを更新する必要があります。ここには、関連するOracle Internet Directory情報が格納されています。

1. 管理者権限を持つユーザーとしてOracle Portalにログオンします。

2. 「ビルダー」に移動します。

3. 「管理」タブをクリックします。

4. 「ポータル」タブから、「グローバル設定」を開き、「SSO/OID」タブに移動します。

5. ページの一番下までスクロールします。

6. 「OIDパラメータ用キャッシュのリフレッシュ」を選択します。

7. 「適用」をクリックします。

8. 「DASホスト名」フィールドの適切な値でページが更新されます。

注意:

SSOのSSLが有効で、Portal URLを介してアクセスするようにSSOを登録している場合、Oracle PortalからOIDを容易に操作できるように、「ポータル・グループ」設定ページでOIDのorcldasurlbaseエントリのHTTPS URLを指していることを確認してください。

これで、OracleAS Single Sign-OnとのSSL通信の構成が完了しました。

注意:

ページに正しいSSO URLを表示するため、Portal modplsqlキャッシュをクリアする必要があります。

次の例は、UNIX上でPortal modsqlをクリアする方法を示しています。

cd $INSTANCE_HOME/portal/cache
rm –rf ./session/*
rm -rf ./plsql/*
rm -rf ./pmd/*

7.3.2.1.3 Oracle Access ManagerとのSSL接続

Oracle Access Manager (OAM)を認証サーバーとして使用する場合は、Oracle Access Manager (OAM)とのSSL通信を有効にする必要があります。Oracle Access Manager (OAM)との通信を保護する方法の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』の安全な通信と証明書の管理に関する項を参照してください。

7.3.2.1.4 Oracle Web CacheとのSSL接続

Oracle Single Sign-Onの通信を保護したら、次にOracle Portalの玄関口に相当するOracle Web Cacheとの通信を保護します。この構成では、Oracle Web Cacheは、パフォーマンスを向上させるために、HTTPを使用してリクエストをOracle HTTP Server (Oracle Portalの中間層の役目を果たす)に転送できます。同様に、Oracle Web Cacheにループバックされるポートレット・コンテンツに対するParallel Page Engineのリクエストでも、HTTPを使用してコンテンツをリクエストできます。

図7-20は、SSLを使用できるように構成されたOracle Web Cacheを示しています。

図7-20 Oracle Web Cacheとの保護された接続

「SSLを構成する前の確認事項」で示した事項を確認したら、次のようにしてOracle Web Cacheに対するSSLを構成します。

注意:

前述のSSL構成では、Oracle Portal中間層パートナ・アプリケーションを再登録する必要があります。このOracleAS Single Sign-On中間層パートナ・アプリケーションはまだ非SSLなので、非SSLとして登録する必要があります。つまり、mod_ossoを再登録するときには、ssoregのmod_osso_urlパラメータとしてOracleAS Single Sign-On中間層の非SSL URLを指定する必要があります。

mod_ossoの登録の詳細は、Oracle Application Server Single Sign-On管理者ガイドを参照してください。

- OracleAS Single Sign-OnでのSSLの有効化

- ウォレットの作成

- Oracle Web Cacheの保護

- Parallel Page Engineの構成

- HTTPサーバーの構成

- Oracle HTTP Serverパートナ・アプリケーションの再登録

- SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録

- SSLを介して公開されるWSRPプロデューサの構成と登録

- Portalツールの信頼できる証明書ファイルの拡張

- Secure Enterprise Searchのアクセスの有効化

- Portalリポジトリのワイヤ構成

- PortalリポジトリでのWeb Cache SSLの構成

- WebLogicプラグインの有効化

OracleAS Single Sign-OnでのSSLの有効化

「手動でのOracleAS Single Sign-OnのSSL構成」の説明にある手順を実行して、OracleAS Single Sign-OnのSSLを有効にします。

ウォレットの作成

Oracle Portalの各種コンポーネントでは、Oracle Wallet Managerを使用してセキュアな通信のための証明書を格納しています。このプロセスの最初の手順は、認証局(OracleAS Certificate Authority、Verisign社、GTE CyberTrust社など)から証明書を取得することです。

注意:

OracleAS Single Sign-OnのSSLを有効にしている場合は、空のウォレットを作成する必要があります。この手順では、新しいウォレットを作成することをお薦めします。

証明書の取得 適切な署名機関からデジタル証明書を取得するには、サーバーを一意に識別する証明書リクエスト(CR)を署名機関に送信します。

1. 中間層のORACLE_HOME/binにあるOracle Wallet Managerを開きます。UNIXの場合は、コマンド・プロンプトから「owm」と入力します。Windowsの場合は、「スタート」メニューからOracle Wallet Managerを起動します。

2. 「ウォレット」→「新規」を選択します。
UNIXの場合、ウォレットはデフォルトで次の場所に格納されます。

/etc/ORACLE/WALLETS/<Account Name creating the Wallet>

Windowsの場合、ウォレットはデフォルトで次の場所に格納されます。

\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS

3. ウォレットのパスワードを作成して、「ウォレット・タイプ」として、「標準」(デフォルト値)またはPKCS1のいずれかのオプションを選択します。

4. 「はい」をクリックして、CRを作成するオプションを受け入れます。

5. 「証明書リクエスト」ダイアログに、サーバーを一意に識別する詳細を入力します。表7-22に、「証明書リクエスト」ダイアログの各種フィールドのサンプル値をいくつか示します。

表7-22 「証明書リクエスト」ダイアログのフィールドのサンプル値

フィールド名

サンプル値

共通名

www.abc.com

組織単位

DOCUMENTATION

組織

Oracle Corporation

市町村

Redwood Shores

都道府県(注意: 略語は使用しないでください。完全な名称を表記する必要があります)

California

6. 「OK」をクリックします。証明書リクエストが正常に作成されたことを示すダイアログが表示されます。ウォレット・ナビゲータの「証明書」ノードが「Requested」に変わります。

7. このウォレットを次のように、適切なディレクトリに保存します。

ORACLE_HOME\webcache\wallets\portalssl

8. 選択した認証局(CA)にCRを送信します。

注意:

証明書は、認証局(CA)として知られる信頼できるサード・パーティ(OracleAS Certificate AuthorityやVerisign社など)によって発行されます。証明書の取得方法の詳細は、適切なベンダーのWebサイトを参照してください。

切取りと貼付け

CAによっては、証明書リクエストを切り取ってWebページに貼り付けたり、引き続きサイトにアップロードできるようにCRをファイルにエクスポートしたりすることが必要な場合もあります。

1. ウォレット・ナビゲータの「証明書」ノードを選択します。

2. 「証明書リクエスト」フィールドの証明書のテキストを強調表示します。BEGIN/END NEW CERTIFICATE REQUEST行が含まれていることを確認してください。

3. CAのWebサイトにある「証明書リクエスト」フィールドにコピーして貼り付けます。

証明書リクエストのエクスポート

証明書リクエストをエクスポートするには、次の手順を実行します。

1. 「操作」→「証明書リクエストのエクスポート」を選択します。

2. CRファイルの名前と場所を選択します。CRのエクスポートが正常に行われたことを示すステータス行メッセージが表示されます。

3. エクスポートしたCRは、CAのWebサイトにアップロードできます。

信頼できる証明書の管理 CAによるリクエストの処理が終わると、ユーザー証明書が電子メールの本文、または指定のWebページからダウンロードするシンプル・ファイルとしてユーザーに転送されます。

注意:

試用版のルート証明書を使用している場合、またはOracle Wallet Managerに現在インストールされていないCAを選択した場合は、まずCAの信頼できる証明書をインポートしてから、サーバー固有のユーザー証明書をインポートしてください。

信頼できる証明書のインポート(必要な場合)

信頼できる証明書をインポートするには、次の手順を実行します。

1. 「操作」→「信頼できる証明書のインポート」を選択します。

2. CAに基づいて、「証明書の貼付け」または「証明書を含むファイルを選択」を選択します。

3. 適切な証明書ファイルを選択するか、電子メールの本文を貼り付けます。Oracle Wallet Managerでは、BASE64でエンコードされたルート証明書を想定しています。BASE64でエンコードされたルート証明書がない場合は、「信頼できる証明書の書式の変更(必要な場合)」で説明する手順を実行する必要があります。

4. 「OK」をクリックします。

証明書が正常にインポートされたことを示すステータス行メッセージが表示されます。サーバー固有のユーザー証明書をインポートすると、ツリー構造内の証明書ノードにも「待機中」と表示されます。

信頼できる証明書の書式の変更(必要な場合)

証明書のインポートに失敗した場合は、その証明書の書式がOracle Wallet Managerでサポートされていない可能性があります。この場合は、その証明書をサポートされている書式に変換してからインポートする必要があります。これを最も簡単に行うには、ブラウザ内にある証明書のインポート/エクスポート・ウィザードを使用します。次の手順は、Internet Explorerのブラウザを使用した場合です。

1. Internet Explorerで、「ツール」→「インターネット オプション」を選択します。

2. 「コンテンツ」タブをクリックします。

3. 「証明書」をクリックします。

4. 「信頼されたルート証明機関」タブをクリックします。

5. 「インポート...」を選択し、ウィザードに従って証明書をインポートします。

6. 新しくインポートされた証明書をリストで強調表示します。

7. 「エクスポート...」をクリックし、ウィザードに従って「エクスポート ファイルの形式」ページに進みます。

8. 「Base 64 encoded X.509」を選択します。

9. 「次へ」をクリックして、証明書のファイル名を入力します。

10. 「次へ」をクリックします。

11. 「終了」をクリックします。

12. Oracle Wallet Managerで、「操作」→「信頼できる証明書のインポート」を選択します。

信頼できるルート証明書がOracle Wallet Managerに正常にインポートされたら、サーバー固有のユーザー証明書をインポートすることができます。

サーバーのユーザー証明書のインポート

サーバーのユーザー証明書をインポートするには、次の手順を実行します。

1. 「操作」→「ユーザー証明書のインポート」を選択します。

2. CAに基づいて、「証明書の貼付け」または「証明書を含むファイルを選択」を選択します。

3. 適切な証明書ファイルを選択するか、電子メールの本文を貼り付けます。

4. 「OK」をクリックします。

ユーザー証明書が正常にインポートされたことを示すステータス行メッセージが表示されます。

証明書のインポートが終了したら、自動ログイン機能を有効にしてWalletを保存することが重要です。この手順が必要なのは、プロセスが開始されてOracle Web Cacheがウォレットにアクセスしても、ウォレットのパスワードはOracle Web Cacheによって保持されないためです。このプロパティが設定されていないと、Oracle Web CacheをSSLモードで実行した場合にすぐにシャットダウンします。このプロパティを設定するには、次の手順を実行します。

1. Oracle Wallet Managerのリストで、インポートした信頼できる証明書を選択します。

2. 「ウォレット」→「保存」を選択します。

3. 「ウォレット」→「自動ログイン」をまだ選択していない場合は選択します。

Oracle Web Cacheの保護

次の項では、Oracle Web CacheがSSL接続を許可するように構成する方法について説明します。

Oracle Web CacheのSSLポートの構成

Oracle Web CacheのSSLポートを構成するには、次の手順を実行します。

1. 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』で説明しているように、Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。

2. 「Webキャッシュ」メニューから「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。

3. 「作成」をクリックします。

4. 「ポートの作成」ページで次の情報を入力します。

- ポート・タイプ: NORM

- IPアドレス: ANY

- Port Number: Web CacheがリスニングするSSLポート

5. 「OK」をクリックします。

6. SSLポートを追加するには、前述の手順で作成したポートを選択して「編集...」をクリックし、「SSL構成」セクションで次の情報を入力します。

- SSLの有効化: チェック・ボックスを選択します。

- サーバー・ウォレット名: SSLサーバー証明書を収めたウォレットを選択します。

7. 「OK」をクリックします。

8. 「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。

前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

公開されたSSLホスト名およびポートのサイトの定義

デフォルトではSSLは構成されていないので、Oracle Web CacheがキャッシュするSSLベースのサイトの定義を追加する必要があります。サイト定義を追加するには、次の手順を実行します。

1. 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、Oracle Enterprise Manager 11g Fusion Middleware ControlのWeb Cacheホーム・ページに移動します。

2. 「Webキャッシュ」メニューから、「管理」→「サイト」を選択します。
「サイト」ページが表示されます。

3. 「サイト」で「作成」をクリックします。

4. 「サイトの作成」ページで次の詳細情報を入力します。

- ブラウザに表示するホスト名を「ホスト」に入力します。
ロード・バランシング・ルーターまたはリバース・プロキシを使用する構成の場合は、ロード・バランシング・ルーターまたはリバース・プロキシ・サーバーの名前になります。Oracle Web Cacheがブラウザ・リクエストを受け取る構成の場合は、Oracle Web Cacheのホスト名になります。

- ブラウザ・リクエストに指定されているHTTPSポートを「Port」に設定します。

- 「URL接頭辞」は空白のままにします。

- 「デフォルト・サイト」チェック・ボックスを選択します。

- 「圧縮」チェック・ボックスを選択解除します。

- 「OK」をクリックします。

- 「適用」をクリックします。

5. デフォルトのアウト・オブ・ボックスの非SSLサイトなど、変更後の構成では使用できなくなるすべてのサイトを削除します。

前述の手順の詳細は、次を参照してください。

- 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のキャッシュ用のHTTPSリクエストのサイト作成に関する項

- 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のサイト定義の作成に関する項

サイトの別名の追加

いくつかの異なるホスト名またはポート、あるいはその両方にコンテンツがキャッシュされているときに、それらが実際には同じ論理コンテンツを参照している場合には、サイトの別名が必要になります。たとえば、PPEがあるポートレットのリクエストを作成したときに、このポートレットが非SSLポート上でリクエストされているが、メイン・サイトがSSLモードでアクセスされる場合には、別名のエントリが必要になります。これにより、SSLを使用するサイトからアクセスされるコンテンツと非SSLモードでアクセスされるコンテンツが、等しいとみなされます。このようにした場合には、そのコンテンツを無効化するために無効化リクエストを送信すると、どちらのモードのURLでキャッシュされている場合でもコンテンツが無効化されます。

このOracle Web Cache SSLサイトについて、非SSL Oracle Web Cacheリスニング・ポート用の別名を作成する必要があります。サイトの別名を作成するには、次の手順を実行します。

1. 新しく追加したサイトを「サイト」ページで選択して「編集」をクリックします。

2. 「別名」セクションで、「作成」をクリックして新しい別名を作成してから、このサイトを入力したときに使用したホスト名を入力し、PPEがOracle Web Cacheからポートレットをリクエストするときに使用する非SSLポートを指定します。

3. 「OK」をクリックします。

4. 「適用」をクリックします。

5. 必要な追加を行ってからサーバーを再起動します。

たとえば、URL、https://portal.mycompany.com:4443を使用して論理サイト名にアクセスするとき、Oracle Web Cacheの非SSLリスニング・ポートが8090の場合、SSLポート4443のサイトを選択してOracle Web Cacheの非SSLポート(8090)を使用して別名を追加します。

前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のサイト定義の作成に関する項を参照してください。

新しいサイトのサイト・サーバー間マッピングのオリジン・サーバーへの追加

新しいサイト定義を追加した後、そのサイトのサイト・サーバー間マッピングをオリジン・サーバーに追加する必要があります。これを行うには、次の手順を実行します。

1. 「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。

2. 「サイト・サーバー間マッピングの作成」セクションで、マッピングするサイトの情報を入力します。このサイトには、SSLポートを使用するOracle Web Cacheサイトを指定する必要があります。たとえば、論理サイト名がhttps://portal.mycompany.com:4443の場合は、ホスト・パターンがportal.mycompany.comで、ポート・パターンが4443のサイトを選択します。

3. 「オリジン・サーバー」セクションで、コンテンツのリクエストのルーティング先とする非SSLのオリジン・サーバーを選択し、それを「すべてのオリジン・サーバー」から「選択したオリジン・サーバー」のリストに移動します。たとえば、ホストportal.mycompany.comのポート8888でオリジン・サーバーを実行している場合は、portal.mycompany.com:8888を選択します。

4. 「OK」を選択してダイアログ・ボックスを閉じると、元のページに表7-23「サイト・サーバー間マッピング」のような新しいマッピングが表示されます。

5. 「変更の適用」をクリックします。

6. 「適用」をクリックします。

7. Oracle Web Cacheを再起動します。

前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバーへのサイトのマッピングに関する項を参照してください。

セッション・バインドの有効化

Oracle Web Cacheのセッション・バインド機能は、ユーザー・セッションを特定のオリジン・サーバーにバインドして、状態を一定の期間保持するために使用されます。デフォルトのOracle Portal中間層で実行するほとんどのコンポーネントはステートレスですが、セッション・バインドが必要です。

Oracle Web Cacheでポータル・ユーザー・セッションをOracle Portal中間層にバインドするには、次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlで、Web Cacheホーム・ページに移動します。

2. 「Webキャッシュ」メニューから、「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。

3. 前述の手順で作成したサイトを選択します。

4. 「セッション・バインディング構成」セクションで「Set-Cookieを使用したCookieに基づくセッション・バインディング」を選択します。

5. 「適用」をクリックします。

詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

オリジン・サーバー・ウォレットへのウォレットのパスの追加

「オリジン・サーバー・ウォレット」ページにウォレットのパスを入力するには、次の手順を実行します。

1. Oracle Web Cache管理ページ(http://www.abc.com:<webcache_admin_port>/webcacheadmin)の「オリジン・サーバー」、「サイト」および「ロード・バランシング」でオリジン・サーバー・ウォレットをクリックします。

注意:

administratorとしてログインする必要があります。パスワードが不明の場合は、Oracle Fusion MiddleWare Controlを使用してリセットできます。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のパスワードのセキュリティ構成に関する項を参照してください。

2. 「キャッシュ名」のオプションを選択して、ウォレットのパスを変更します。

3. 「選択対象の編集」をクリックして、オリジン・サーバー・ウォレットの編集ダイアログ・ボックスを表示します。

4. 有効なウォレット・ディレクトリを入力します。たとえば、「リスニング・ポート」ページで指定したウォレット・ディレクトリ・パスを使用します。

5. 「Submit」をクリックしてダイアログ・ウィンドウを閉じます。「オリジン・サーバー・ウォレット」ページの表に、新しいウォレットのディレクトリ・パスが表示されます。

注意:

Oracle Web Cacheをセキュリティで保護するすべての手順を実行したら、変更を有効にするため、Oracle Fusion Middleware Controlを使用してOracle Web Cacheサーバーを再起動する必要があります。

Parallel Page Engineの構成

この構成では、ポートレットをリクエストするときにHTTPリクエストを使用するように、PPEを構成する必要があります。次の項では、この目的のために部分的SSL PPE構成を実装する方法について説明します。 PPEを構成するには、次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。

2. Oracle Portalホーム・ページの「ポータル」メニューから、「設定」→「ページ・エンジン」を選択します。
「ページ・エンジン構成」ページが表示されます。

3. 「拡張プロパティ」セクションで、次のパラメータを追加します。

- ポートの使用: 8090

- スキームの使用: http

- HTTPSポート: 4443

4. (オプション) PPEが特定の証明書のみを信頼するようにする必要がある場合は、「拡張プロパティ」セクションの「509証明書ファイル」フィールドにx509certfileを追加します。x509certfileの値は、「信頼できる」サーバーのグループを定義する証明書のリストが記載されたテキスト・ファイルへの絶対パスです。

注意:

x509certfileを実装しないと、PPEではすべてのSSL証明書を信頼します。

5. 「適用」をクリックします。

6. 管理対象サーバー(WLS_PORTAL)を再起動します。

HTTPサーバーの構成

仮想ホストの定義を追加します。PortalがWeb CacheのSSLポートを使用して動作する場合、この構成でホスト名とポートの自己参照URLを指定します。httpd.confファイルで、仮想ホストについて次の詳細情報を追加します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。

2. 「Web層」を開いて、Oracle PortalインスタンスのOracle HTTP Server (ohs1)リンクをクリックします。

3. Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。

4. 「サーバーの詳細構成」ページの「ファイルの選択」オプションで「httpd.conf」を選択して、「実行」をクリックします。

5. httpd.confファイルで、仮想ホストについて次の詳細情報を追加します。

LoadModule certheaders_module ORACLE_HOME/ohs/modules/mod_certheaders.so
NameVirtualHost *:OHS http port
<VirtualHost *:OHS http port>
ServerName https://webcachehost:webcache=sslport
RewriteEngine On
RewriteOptions inherit
SimulateHttps On
UseCanonicalName On
</VirtualHost>

ORACLE_HOMEは、Oracle PortalインストールのOracleホームへのフルパスです。

6. 「適用」をクリックします。

7. Oracle HTTP Serverのホーム・ページで「制御」→「再起動」を選択してOracle HTTP Serverを再起動します。

Oracle HTTP Serverパートナ・アプリケーションの再登録

ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義します。ssoregは、ORACLE_HOME/sso/binのインフラストラクチャ層(OID)にあります。

次の例は、UNIX上でのssoregの使用方法を示しています。

ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com:4443
-config_mod_osso TRUE
-mod_osso_url https://www.abc.com:4443
-update_mode MODIFY
-remote_midtier
-config_file /tmp/osso.conf
-admin_info cn=orcladmin

Web Cache SSLポートの仮想ホストを構成したohsインスタンス (ORACLE_INSTANCE/config/OHS/ohs1/osso.conf)にosso.confをコピーします。

次のコマンドを使用してOracle HTTP Serverを再起動します。

ORACLE_INSTANCE/bin/opmnctl stopall
ORACLE_INSTANCE/bin/opmnctl startall

Windowsでは、かわりにssoreg.batバッチ・ファイルを実行する必要があります。パートナ・アプリケーション登録の詳細は、Oracle Application Server Single Sign-On管理者ガイドを参照してください。

Oracle Web CacheとのSSL通信の構成が完了しました。

SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録

詳細は、「SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録」を参照してください。

SSLを介して公開されるWSRPプロデューサの構成と登録

詳細は、「SSLを介して公開されるWSRPプロデューサの構成と登録」を参照してください。

Portalツールの信頼できる証明書ファイルの拡張

OmniPortletプロバイダのWebページ・データ・ソースを使用する場合は、Webクリッピング・プロバイダへのループバックを実行するので、OmniPortletのprovider.xmlファイルにある<trustedCertificateLocation>タグで指定した信頼できる証明書ファイルに、Webプロバイダのサーバー証明書を追加する必要があります。デフォルトの証明書ファイルは、ORACLE_HOME\portal\confディレクトリにあるca-bundle.crtファイルです。

これを行うには、Internet Explorerのブラウザに基づく次の手順を実行します。別のブラウザを使用して必要な証明書のキャプチャとエクスポートを行う場合、この手順は少し異なることがあります。

1. 次の手順で必要な証明書をキャプチャします。ブラウザで、Webクリッピングの「プロバイダ・テスト・ページ」(http://<host>:<port>/portalTools/webClipping/providers/webClipping)を指定します。
「セキュリティの警告」ダイアログ・ボックスが表示され、「このセキュリティ証明書は、信頼する会社から発行されていません。証明書を表示して、この証明機関を信頼するかどうか決定してください。」などのメッセージが表示されます。「証明書の表示」をクリックし、次に示す手順を実行して証明書を一時ファイルにエクスポートします。

1. 「詳細」タブを選択します。

2. ドロップダウン・リストから「表示: <すべて>」を選択し、「ファイルにコピー」をクリックします。エクスポート・ウィザードを実行して、Base-64 encoded X.509形式の証明書を一時ファイルORACLE_HOME/portal/conf/providertemp.cerにエクスポートします。

2. 一時ファイル内の証明書を、OmniPortletプロバイダが使用する証明書ファイル(デフォルトはORACLE_HOME/portal/conf/ca-bundle.crt)に追加します。

Secure Enterprise Searchのアクセスの有効化

セキュアなWebサイトにSecure Enterprise Searchからアクセスするには、中間層インスタンスとインフラストラクチャ・インスタンスにあるクローラのトラストストアおよびOracle Containers for J2EE (WLS) JVMのトラストストアに証明書をインポートする必要があります。

デフォルトでは、WLS JVMは、既知の認証局の証明書を認識します。ただし、セキュアなポータル・インスタンスが、自己署名の証明書または不明な認証局によって署名された証明書を使用する場合は、そのポータルの証明書をWLS JVMのトラストストアにインポートする必要があります。WLS JVMのデフォルトのトラストストアは、ORACLE_HOME\jdk\jre\lib\security\cacertsにあります。

必要な証明書をトラストストアに追加するには、中間層インスタンスとインフラストラクチャ・インスタンスで次の手順を実行します。

1. ディレクトリを、中間層のORACLE_HOME\jdk\jre\lib\security\に変更します。

2. トラストストア・ファイルcacertsのバックアップ(cacerts.bakなど)を作成します。

3. 次のコマンドを実行して、必要な証明書をトラストストアに追加します。

$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/jdk/jre/lib/security/cacerts

注意:

-aliasには任意の値を使用してください。ただし、この値は証明書ごとに一意である必要があります。

4. トラストストア・パスワードを入力し、確認を促すメッセージが表示されたら「Yes」と入力します。

注意:

前述の手順は、Secure Enterprise Searchクローラを含むOracleAS Infrastructure上でも実行する必要があります。

Portalリポジトリのワイヤ構成

Portalの中間層を次のように構成します。

1. Oracle Enterprise Manager 11gでPortalホーム・ページに移動します。

2. 「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。

3. 「ポータル・ワイヤ構成」ページの「ポータル中間層」セクションに、次の情報を入力します。

- 公開ホスト: ホスト名を入力します。

- リスニング・ポート: ポート番号を入力します。

- 「SSLプロトコル」チェック・ボックスを選択します。

4. 「適用」をクリックします。

5. 管理対象サーバーを再起動します。

Web Cache SSLのPortalリポジトリの構成

SSO情報を取得するために、Portalでmod_ossoが必要になります。mod_ossoはSSLで構成されているので(WC SSLポートを使用するパートナ・アプリケーションとして登録されています)、ポータルはWC SSL証明書の保存に使用するウォレットのパスおよびパスワードが必要になります。

Portalリポジトリのプリファレンス・ストアにあるウォレットのパスとパスワードを更新するには、次の手順を実行します。

1. Web CacheのSSL証明書をPortalデータベース・ウォレットのトラストストアにインポートします。

2. データベース・ウォレットがない場合は、データベースがインストールされている環境でOWM (Oracle wallet manager)またはorapkiユーティリティを使用して作成できます。ウォレットができたら、Web CacheのSSL証明書をデータベース・ウォレットにインポートします。

3. ORACLE_HOME\portal\admin\plsql\wwcにあるsecwc.sqlスクリプトを使用して、このウォレットの場所をPortalプリファレンス・ストアに登録する必要があります。

例7-5 ウォレットの登録

cd $ORACLE_HOME/portal/admin/plsql/wwc
sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location> <wallet_pwd>
sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet''welcome1'

WebLogicプラグインの有効化

「WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化」を参照してください。

7.3.2.1.5 Oracle PortalのエンドツーエンドSSL

最大限のセキュリティを必要とするインストールに対しては、システム全体にわたってSSLを構成することができます。この構成では、PPEからOracle Web Cacheへのループバックでウォレットが使用され、PPEとWebプロバイダとのホップで証明書がウォレットを介さずに直接使用されます。

図7-21は、Oracle Portal全体にわたって構成したSSLを示しています。

図7-21 システム全体にわたって保護された接続

注意:

第7.3.2.1.4項「Oracle Web CacheとのSSL接続」で説明した手順をすでに実行している場合は、Oracle Portal全体にSSLを構成する前に、適用したすべての変更を元に戻す必要があります。

「SSLを構成する前の確認事項」に記載された確認事項の実行を完了したら、次のようにしてOracleAS Single Sign-OnでSSLを構成します。

- OracleAS Single Sign-OnでのSSLの有効化

- ウォレットの作成

- Oracle HTTP ServerおよびOracle WebLogic Serverの構成

- Oracle Web Cacheの保護

- Parallel Page Engineの保護

- Oracle Portalの公開アドレスとプロトコルの指定

- HTTPサーバーの構成

- Oracle HTTP Serverパートナ・アプリケーションの再登録

- PortalリポジトリでのWeb Cache SSLの構成

- WebLogicプラグインの有効化

- SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録

- SSLを介して公開されるWSRPプロデューサの構成と登録

- Portalツールの信頼できる証明書ファイルの拡張

- Secure Enterprise Searchのアクセスの有効化

OracleAS Single Sign-OnでのSSLの有効化

「手動でのOracleAS Single Sign-OnのSSL構成」の説明にある手順を実行して、OracleAS Single Sign-OnのSSLを有効にします。

ウォレットの作成

Oracle Web CacheとOracle HTTP Serverが同じコンピュータ上にある場合は、リスナーとオリジン・サーバー(およびOracle Web Cacheで利用できる他のすべてポート)との間で1つのウォレットを共有できます。逆に、ポート別に専用のウォレットを作成することもできます。この場合は、この2つのサーバーおよびそのポートで前述と同じウォレットを共有します。

Oracle HTTP ServerとOracle Web Cacheが互いに別のコンピュータ上にある場合のように、Oracle HTTP Server用に別のウォレットの作成が必要になることがあります。この場合は、「ウォレットの作成」の手順を参照して、Oracle HTTP Server用のウォレットを作成します。

デフォルトでは、Oracle HTTP ServerとOracle Web Cacheは同じコンピュータ上にあり、これらの間でウォレットを共有できます。

注意:

作成したウォレットは、Fusion MiddleWare ControlまたはimportWallet WLSTコマンドを使用してインポートします。詳細は、『Oracle Fusion Middleware管理者ガイド』のウォレットの管理に関する項を参照してください。

Oracle HTTP ServerおよびOracle WebLogic Serverの構成

WebLogic Server (WLS)とSSL通信を確立するようにOracle HTTP Serverを構成し、SSLモードをプロキシ処理するようにWeblogic管理対象サーバー(WLS_PORTAL)へのルーティング情報を設定する必要があります。HTTPおよびWLSを構成するには、次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware ControlからOracle HTTP Serverのホーム・ページに移動して、「管理」→「詳細構成」を選択します。
「詳細構成」ページが表示されます。

2. メニュー・オプションから「portal.conf」ファイルを選択して「実行」をクリックします。

3. 次のように、WLProxySSLパラメータをONに設定します。

# WLS routing configuration
<Location /portal>
SetHandler weblogic-handler
WebLogicHost stbcr13-3.us.abc.com
WebLogicPort 9001
WLProxySSL On
</Location>

4. 「適用」をクリックします。

5. Oracle HTTP Server用に別のウォレットを作成する必要があります。この場合は、「ウォレットの作成」の手順を参照してOracle HTTP Server用のウォレットを作成し、webcache.xmlファイルの<OSWALLET>タグにそのウォレットの場所が追加されていること確認します。
Oracle Enterprise Manager 11gを使用して、次のようにウォレットの場所を<OSWALLET>タグに追加できます。

1. 「Web層」を開いて、Oracle PortalインスタンスのOracle Web Cache (webcache1)リンクをクリックします。

2. 「Webキャッシュ」メニューから「セキュリティ」→「SSL構成」を選択します。

3. 作成したウォレットを選択して「ウォレットの変更」をクリックします。

4. 「OK」をクリックします。

6. Oracle HTTP Serverを再起動します。

7. 新規に作成したウォレットからテキスト・ファイルに証明書をコピーします。次に、Oracle Portalがデプロイされた管理対象サーバーで使用されるキーストアにこのファイルをインポートします。
WebLogic Serverのキーストアの場所を確認するには、WebLogic Server管理コンソールに移動して、「環境」→「サーバー」と移動し、WLS_PORTALリンクをクリックします。「構成」タブで「キーストア」サブタブを選択し、「Java標準信頼キーストア」フィールドで指定されているパスを探します。

Oracle HTTP Serverウォレットから証明書をエクスポートする際は、Oracle Wallet Manager、または中間層で使用可能なorapkiユーティリティを使用できます。キーストアへの証明書のインポートには、keytoolを使用できます。

次は、keytoolの使用例です。

keytool -import -trustcacerts -alias aliasName -file
certificate_file_name -keystore cacerts -storetype JKS

ファイル・サーバー証明書とウォレットからエクスポートした認証局のルート証明書がcertificate_file_nameで指定されている必要があります。

詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareにおけるSSL構成に関する項を参照してください。

Oracle Web Cacheの保護

次の項では、Oracle Web CacheがSSL接続を許可し、SSLリクエストをSSL対応のオリジン・サーバーに転送するように構成する方法について説明します。

Oracle Web CacheのSSLポートの構成

Oracle Web CacheのSSLポートを構成するには、次の手順を実行します。

1. 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。

2. 「Webキャッシュ」メニューから「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。

3. 「作成」をクリックします。

4. 「ポートの作成」ページで次の情報を入力します。

- ポート・タイプ: NORM

- IPアドレス: ANY

- Port Number: Web CacheがリスニングするSSLポート。

5. 「OK」をクリックします。

6. SSLポートを追加するには、前述の手順で作成したポートを選択して「編集...」をクリックし、「SSL構成」セクションで次の情報を入力します。

- SSLの有効化: チェック・ボックスを選択します。

- サーバー・ウォレット名: SSLサーバー証明書を収めたウォレットを選択します。

7. 「OK」をクリックします。

8. 「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。

前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のキャッシュ用のHTTPS動作ポートの構成に関する項を参照してください。

SSLオリジン・サーバーを追加する

SSLオリジン・サーバーを追加するには、次の手順を実行します。

1. 「Webキャッシュ」メニューから「管理」→「オリジン・サーバー」を選択します。
「オリジン・サーバー」ページが表示されます。

2. 「作成...」をクリックしてSSLオリジン・サーバーを追加します。

3. 次の情報を入力します。

- Host Name: Oracle HTTP Serverが実行されているコンピュータの物理ホスト名。

- Port: Oracle HTTP ServerのSSLリスニング・ポート。このプロパティは、ORACLE_INSTANCE\config\OHS\ohs1にあるHTTPサーバーのssl.confファイル内のListenパラメータにマッピングされます。

- Capacity: 100

- Protocol: HTTPS

- Routing: 有効

- Failover Threshold: 5

- Ping URL: /

- Ping Interval: 10

4. 「OK」をクリックします。

5. 「適用」をクリックします。

6. 「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。

前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバー、ロード・バランスおよびフェイルオーバー設定の構成に関する項を参照してください。

公開されたSSLホスト名およびポートのサイトを定義する

デフォルトではSSLは構成されていないので、Oracle Web CacheがキャッシュするSSLベースのサイトの定義を追加する必要があります。サイトを定義するには、次の手順を実行します。

1. 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、Oracle Enterprise Manager 11g Fusion Middleware ControlのWeb Cacheホーム・ページに移動します。

2. 「Webキャッシュ」メニューから「管理」→「サイト」を選択します。
「サイト」ページが表示されます。

3. 「サイト」で「作成」をクリックします。

4. 「サイトの作成」ページで次の詳細情報を入力します。

- ブラウザに表示するホスト名を「ホスト名」に入力します。

- ブラウザ・リクエストに指定されているHTTPSポート(Oracle Web CacheのSSLリスニング・ポート)を「ポート」に設定します。

- 「デフォルト・サイト」で「Yes」を選択します。

- サイト規模の圧縮で「No」を選択します。
その他のパラメータはデフォルト設定のままとして、空白のエントリがあってもそのままにしておきます。

- 「OK」をクリックします。

- 「適用」をクリックします。

5. 変更後の構成では使用できなくなるすべてのサイトを削除します。

前述の手順の詳細は、次を参照してください。

- 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のキャッシュ用のHTTPSリクエストのサイト作成に関する項

- 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のサイト定義の作成に関する項

新しいサイトのサイト・サーバー間マッピングのオリジン・サーバーへの追加

新しいサイト定義を追加した後、そのサイトのサイト・サーバー間マッピングをオリジン・サーバーに追加する必要があります。これを行うには、次の手順を実行します。

1. 「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。

2. マッピングするサイトを選択し、「すべてのオリジン・サーバー」から「選択したオリジン・サーバー」リストにそのサイトを移動します。これはSSLポートが設定されたOracle Web Cacheサイトであることが必要です。

3. 前の手順「SSLオリジン・サーバーを追加する」で追加した、コンテンツを取得するためにリクエストをルーティングするオリジン・サーバーを選択します。

4. 「変更の適用」→「適用」をクリックすると、表7-23のような元のページの新しいマッピングが表示されます。

表7-23 サイト・サーバー間マッピング

ホスト名(Oracle Web Cacheホスト名)

サイト・ポート(Oracle Web Cacheリスニング・ポート)

ESIコンテンツ・ポリシー

ホスト名(Oracle Web Cacheホスト名)

オリジン・サーバー・ポート(Oracle Http Serverポート)

プロキシ

www.mycompany.com

8094

制限なし

www.mycompany.com

8889

いいえ

5. Oracle Web Cacheを再起動します。

前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバーへのサイトのマッピングに関する項を参照してください。

セッション・バインドの有効化

Oracle Web Cacheのセッション・バインド機能は、ユーザー・セッションを特定のオリジン・サーバーにバインドして、状態を一定の期間保持するために使用されます。デフォルトのOracle Portal中間層で実行されるほとんどすべてのコンポーネントはステートレスですが、セッション・バインドは次の2つの理由で必要になります。

Oracle Web Cacheでポータル・ユーザー・セッションをOracle Portal中間層にバインドするには、次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlで、Web Cacheホーム・ページに移動します。

2. 「Webキャッシュ」メニューから「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。

3. 前述の手順で作成したサイトを選択します。

4. 「セッション・バインディング構成」セクションで「Set-Cookieを使用したCookieに基づくセッション・バインディング」を選択します。

5. 「適用」をクリックします。

詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

オリジン・サーバー・ウォレットへのウォレットのパスの追加

「オリジン・サーバー・ウォレットへのウォレットのパスの追加」を参照してください。

Parallel Page Engineの保護

この構成では、リクエストがHTTPSを介してOracle Web Cacheに送信され、同様にPPEがHTTPSを介してループバックするときに、全体を通してSSLが使用されます。サーバーでは、その証明書とともに送信される連鎖を指定します。この連鎖が有効で、自己署名のルート証明書を得る場合、トラスト・ポイントがまだそれにロードされていないという前提では、その証明書が信頼できるかどうか確認しなくても有効となります。

この構成を実装するには、Oracle Portal中間層で次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。

2. Oracle Portalホーム・ページの「ポータル」メニューから「設定」→「ページ・エンジン」を選択して「ページ・エンジン構成」ページを表示します。

3. 「拡張プロパティ」セクションで、「HTTPSポート」の値にOracle Web CacheのSSLポートを入力します。

4. (オプション)PPEで特定の証明書のみを信頼する場合はx509certfileを追加します。x509certfileの値は、信頼できるサーバー・グループを定義する証明書のリストを含むテキスト・ファイルへの絶対パスです。

注意:

x509certfileを実装しないと、PPEではすべてのSSL証明書を信頼します。

5. 「適用」をクリックします。

6. 管理対象サーバー(WLS_PORTAL)を再起動します。

Oracle Portalの公開アドレスとプロトコルの指定

SSL用に変更されたポートでOracle Portalの公開アドレスを指定するには、次のようにOracle Enterprise Managerを使用する必要があります。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlに移動します。

2. Oracle Portalの中間層で実行しているOracle Fusion Middlewareを含むスタンドアロン・インスタンスをクリックします。

3. Oracle Portalのシステム・コンポーネント(WLS_PORTAL)をクリックします。

4. 「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。

5. 「ポータル・ワイヤ構成」ページの「ポータル中間層」セクションに、次の情報を入力します。

- リスニング・ポート: Oracle Web CacheのSSLポート番号を入力します。

- 「SSLプロトコル」チェック・ボックスを選択します。

6. 「適用」をクリックします。

Oracle Portalのスキーマがこの設定で更新され、Oracle Enterprise Manager 11gのターゲット・インスタンスがそのURLテストにHTTPSを使用するように更新されます。

後でHTTPに切り替えることにする場合は、これと同じ手順を実行して、「リスニング・ポートSSL使用可能」を「いいえ」に戻します。

HTTPサーバーの構成

仮想ホストの定義を編集します。PortalがSSLで動作する場合、この構成でホスト名とポートの自己参照URLを指定します。Oracle Enterprise Manager 11g Fusion Middleware ControlのOracle HTTP Serverホーム・ページに移動して、「管理」→「拡張構成」を選択します。「ssl.conf」ファイルを選択して、次の太字で示す仮想ホストに関する詳細を追加します。

<VirtualHost *:8890>
UseCanonicalName On
ServerName https://dadvmn0041.us.abc.com:8094
<IfModule ossl_module>
SSLEngine on
SSLVerifyClient None
SSLCipherSuite
SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SH
A,SSL_RSA_WITH_DES_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_C BC_SHA
SSLCRLCheck Off
SSLWallet "wallet_location"

次の例に示すように、wallet_locationを、カスタム・ウォレットのフルパスに置き換えます。

SSLWallet "$ORACLE_INSTANCE/config/OHS/ohs1/keystores/default"

Oracle HTTP Serverパートナ・アプリケーションの再登録

ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義します。ssoregは、ORACLE_HOME/sso/binのインフラストラクチャ層(OID)にあります。

次の例は、UNIX上でのssoregの使用方法を示しています。

ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com
-config_mod_osso TRUE
-mod_osso_url https://www.abc.com:8094
-update_mode MODIFY
-remote_midtier
-config_file ORACLE_INSTANCE/config/OHS/ohs1/osso.conf
-admin_info cn=orcladmin

osso.confをohsインスタンスにコピーします。これは、Web CacheのSSLポートで仮想ホストを構成した場所です(ORACLE_INSTANCE/config/OHS/ohs1/osso.conf)。

次のコマンドを使用してOracle HTTP Serverを再起動します。

ORACLE_HOME/bin/opmnctl stopall
ORACLE_HOME/bin/opmnctl startall

Windowsでは、かわりにssoreg.batバッチ・ファイルを実行する必要があります。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のパートナ・アプリケーションの作成に関する項を参照してください。

Web Cache SSLのPortalリポジトリの構成

SSO情報を取得するために、Portalでmod_ossoが必要になります。mod_ossoはSSLで構成されているので(WC SSLポートを使用するパートナ・アプリケーションとして登録されています)、ポータルはWC SSL証明書の保存に使用するウォレットのパスおよびパスワードが必要になります。

Portalリポジトリのプリファレンス・ストアにあるウォレットのパスとパスワードを更新するには、次の手順を実行します。

1. Web CacheのSSL証明書をPortalデータベース・ウォレットのトラストストアにインポートします。

2. データベース・ウォレットがない場合は、データベースがインストールされている環境でOWM (Oracle wallet manager)またはorapkiユーティリティを使用して作成できます。ウォレットができたら、Web CacheのSSL証明書をデータベース・ウォレットにインポートします。

3. ORACLE_HOME\portal\admin\plsql\wwcにあるsecwc.sqlスクリプトを使用して、このウォレットの場所をPortalプリファレンス・ストアに登録する必要があります。

例7-6 ウォレットの登録

cd $ORACLE_HOME/portal/admin/plsql/wwc
sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location> <wallet_pwd>
sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet''welcome1'

WebLogicプラグインの有効化

「WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化」を参照してください。

SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録

「SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録」を参照してください。

SSLを介して公開されるWSRPプロデューサの構成と登録

「SSLを介して公開されるWSRPプロデューサの構成と登録」を参照してください。

Portalツールの信頼できる証明書ファイルの拡張

「Portalツールの信頼できる証明書ファイルの拡張」を参照してください。

Secure Enterprise Searchのアクセスの有効化

「Secure Enterprise Searchのアクセスの有効化」を参照してください。

7.3.2.1.6 Oracle Fusion Middleware内では非SSLの外部SSL

前の構成では、Oracle Fusion Middleware内の通信がSSLを介して保護されるようにOracle Portalを構成する方法について説明しました。特定の状況下では、サイトはSSL URLを介して外部にアクセスする一方で、内部的にはOracle Fusion Middlewareを非SSLモードで実行するようにOracle Portalを設定することもあります。後者のシナリオでは、ロード・バランシング・ルーター(LBR)またはSSLアクセラレータを使用してSSLから非SSLへの変換を行う必要があります。この項では、LBRまたはリバース・プロキシ・サーバーのアクセラレータでSSLの変換を行う場合に使用する手順について説明します。

このオプションでは、Oracle Fusion Middleware Security FrameworkのSSL機能は使用しませんが、そのかわり、SSLの接続ポイントを提供するために外部コンポーネントを使用します。これらの外部アクセラレータは、LBRやリバース・プロキシ・サーバーと組み合せることができます。Oracle Fusion Middlewareを使用すると、これらの外部装置でSSLを提供するように構成できるため、最良のパフォーマンスを得るためにOracle Fusion Middleware内部でHTTPを使用できるようになります。

図7-22は、Oracle PortalがSSLを介して外部にアクセスする構成を示しています。

図7-22 外部SSLのみ

注意:

通常の構成では、w1.abc.comとm1.abc.comは同じコンピュータ上にありますが、説明のために、ここではそれらを分けています。

この手順では、次のことを前提としています。

- この例では、LBRなどのSSLアクセラレータでSSLを高速化し、LBRはHTTPプロトコルやHTTPSプロトコルとそのポート間のページ・リクエストのプロキシ処理も行うこと。SSLエンド・ポイントの場所は、ループバック・リクエストの送信先も決定します。たとえば、SSL対応のリバース・プロキシ・サーバーが単一プロトコルLBRのフロントエンドになっている場合、公開サイトがリバース・プロキシ・サーバーによって公開中に、ループバック・リクエストはLBRに送信されます。

- 使用するロード・バランシング・ルーターがlbr.abc.comで実行されており、サイトのアクセスに使用されるLBRのポートが443であること。

- Oracle Web Cacheがコンピュータのw1.abc.comで実行されており、そのリスニング・ポートが8090、管理用ポートが4002であり、無効化ポートが4001であること。

- Oracle HTTP Serverがコンピュータのm1.abc.comで実行されており、そのポートが8888であること。

- 使用されているポート番号は仮の値であること。

関連項目:

- 第6.3項「ロード・バランシング・ルーターを使用する複数の中間層の構成」

- Oracle Portalエンタープライズ・デプロイメント・ガイド: http://www.oracle.com/technetwork/database/features/availability/maa-portal-edg-129356.pdf

- Oracle Fusion Middleware高可用性ガイド

「SSLを構成する前の確認事項」に記載された確認事項の実行を完了したら、次のようにしてOracle Portalで外部SSLの構成を行います。

- Oracle Fusion Middlewareの中間層の構成

- Oracle HTTP Serverパートナ・アプリケーションの再登録

- Secure Enterprise Searchのアクセスの有効化

- WebLogicプラグインの有効化

Oracle Fusion Middlewareの中間層の構成

基になるコンポーネントがロード・バランシング・ルーターのホスト名(lbr.abc.com)とポート(443)に基づくURLを作成できるように、Oracle Fusion Middlewareの中間層を構成する必要があります。これを行うには、次の手順を実行します。

1. httpd.confを次のように編集します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlにアクセスします。

2. Oracle Portalがインストールされている中間層のリンクをクリックします。

3. 「Web層」を開いて、Oracle PortalインスタンスのHTTP Serverリンクをクリックします。

4. Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。

5. 「サーバーの詳細構成」ページで、「ファイルの選択」オプションから「httpd.conf」を選択して「実行」をクリックします。

6. 次の仮想ホストの定義を追加します。

NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName https://lbr.abc.com:443
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:8888>
ServerName http://m1.abc.com:8090
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

7. 「適用」をクリックします。

8. Oracle HTTP Serverのホームから「制御」→「再起動」を選択してOracle HTTP Serverを再起動します。

2. Parallel Page Engineを構成します。これを行うには、次の手順を実行します:

1. Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。

2. Oracle Portalホーム・ページの「ポータル」メニューから「設定」→「ページ・エンジン」を選択して「ページ・エンジン構成」ページを表示します。

3. 「拡張プロパティ」セクションで次のパラメータを追加して、サイトで使用したものとは異なるプロトコルとポートを使用してループバックを試みます。

- スキームの使用: http

- ポートの使用: 8090

- HTTPSポート: 443

4. 「適用」をクリックします。

5. 「ポータル」メニューから「制御」→「停止」→「起動」を選択して、WLS_PORTALインスタンスを再起動します。

3. DNSでlbr.abc.comがLBRのIPアドレスに解決されることを確認します。

4. Oracle Enterprise Manager 11g Fusion Middleware Controlにログインして、次の手順を実行します。

1. Portalホーム・ページの「ポータル」メニューから「設定」→「ワイヤ構成」を選択して「ポータル・ワイヤ構成」ページを表示します。

2. 「ポータル・ワイヤ構成」ページの「Oracle Web Cache」セクションで、次のWeb Cacheのパラメータを入力します。

- ホスト: lbr.abc.com

- 無効化ポート: 4001

- 無効化ユーザー: invalidator

- 無効化パスワード: 指定したパスワード

3. 「ポータル中間層」セクションで「SSLプロトコル」チェック・ボックスを選択します。

4. 「適用」をクリックします。

5. Oracle Enterprise Manager 11g Fusion Middleware ControlのOracle Web Cacheホーム・ページで「管理」→「サイト」を選択します。
「サイト」ページが表示されます。

6. 「サイト」で「作成」をクリックします。

7. 「サイトの作成」ページで次の詳細情報を入力します。

- ホスト: 公開されたホスト名と外部SSLアクセラレータ・デバイスまたはリバース・プロキシ・サーバーの完全修飾ドメイン名。

- ポート: SSLポート番号(デフォルトのSSLポートの443など)。

- URL接頭辞: 空白のまま

- クライアント側証明書: 不要

- Default Site: はい。

- 圧縮: いいえ。

前述の構成手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

8. 「OK」をクリックします。

9. 「適用」をクリックします。

10. Oracle Web Cacheの別名を設定します。Parallel Page EngineがOracle Web Cacheにループバックし、Oracle Web Cacheがロード・バランシング・ルーターとは異なるポートでリスニングしている構成では、ループバック・コンテンツがlbr.abc.com:8090というURLキーでキャッシュされます。一方、Oracle Portalでは書式がlbr.abc.com:443のURLを無効にする無効化リクエストを送信します。この矛盾に対処するには、Oracle Web Cache内に別名を設定して、その別名にlbr.abc.com:8090とlbr.abc.com:443が同じであることを認識させ、一方に対する無効化リクエストによって他方に対するリクエストも無効になり、キャッシュされたコンテンツもこの別名を基にして利用されるようにする必要があります。

1. Oracle Enterprise Manager 11g Fusion Middleware ControlのOracle Web Cacheホーム・ページで「管理」→「サイト」を選択します。

2. 「サイト」ページで、新しく追加したサイトを選択し(ここではlbr.abc.com)、「編集」をクリックします。
「サイトの編集」ページが表示されます。

3. 「別名」セクションで、「作成」をクリックして新しい別名を作成し、「ホスト」に「lbr.abc.com」、「ポート」に「8090」と入力します。この8090は、Parallel Page EngineのappConfig.xml構成ファイルで指定されているusePortの値です。

4. 「OK」をクリックします。

5. 「適用」をクリックします。

6. 「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。

前の例のように、外部SSL構成で構成したサイトに対してデフォルトのHTTPSポート443を選択した場合、Oracle Web Cacheで、lbr.abc.com:443サイトの追加の別名(lbr.abc.com:80)を定義する必要があります。ステップ10で説明した別名の作成方法に従って、ポートの8090を80に置き換えます。

ブラウザが送信するホスト・ヘッダーは、ポート番号が付加されていないlbr.abc.comなので、ポート80には別名が必要となります。Oracle Web Cacheでは、HTTPポートをリスニングしているので、ポート番号が80であることが前提となっており、このポート番号を使用してサイト・サーバー間マッピングが決まります。キャッシュ・キーの作成にもこのポート番号が使用されます。

11. 新しいサイト定義を追加した後、そのサイトのサイト・サーバー間マッピングをオリジン・サーバーに追加する必要があります。これを行うには、次の手順を実行します。

1. 「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。

2. 「サイト・サーバー間マッピングの作成」セクションで、マッピングするサイト(lbr.abc.com)の情報を入力して、前の手順で作成したサイトの定義を選択します。

3. 「オリジン・サーバー」セクションで「m1.abc.com」を選択して、それを「すべてのオリジン・サーバー」から「選択したオリジン・サーバー」リストに移動します。

4. 「OK」をクリックします。

5. 「適用」をクリックします。

6. 「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。
サイトが正しくマッピングされたことを確認するには、「サイト・サーバー間マッピング」ページに移動して、サイトlbr.abc.comにm1.abc.comがマッピングされていることを確認します。

前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバーへのサイトのマッピングに関する項を参照してください。

12. 次のようにロード・バランシング・ルーターlbr.abc.comを構成します。

1. HTTPSポート443のリクエストを受け入れ、それらをコンピュータw1.abc.comで動作しているOracle Web Cacheのポート(8090)に転送し、同時にHTTPSリクエストをHTTPに変換するようにします。

2. HTTPポート8090のリクエストを受け入れ、それらをコンピュータw1.abc.comで動作しているOracle Web Cacheのポート(8090)に転送するようにします。これでループバック・リクエストが有効になります。LBRのポート(8090)は、中間層からのみアクセス可能である必要があります。ファイアウォールは、正常に機能させるために別に構成する必要があります。これをテストするには、中間層サーバーで次のコマンドを実行します。

telnet lbr.abc.com 8090

telnetコマンドの実行時に、接続の失敗メッセージが表示されないようにします。

3. 無効化リクエスト用のHTTPポート4001のリクエストを受け入れ、それらをOracle Web Cacheの無効化用ポート(4001)に転送するようにします。Oracle Metadata Repositoryから無効化リクエスト用のLBRのポートに接続できる必要があります。ファイアウォールは、正常に機能させるために別に構成する必要があります。これをテストするには、Oracle Metadata Repositoryサーバーで次のコマンドを実行します。

telnet lbr.abc.com 4001

telnetコマンドの実行時に、接続の失敗メッセージが表示されないようにします。

4. LBRを介して中間層からOracle Web Cacheへの通信を問題なく実行できるようにします。これには、NAT関連の構成が必要になることがあります。NATの構成の詳細は、第6.3項「ロード・バランシング・ルーターを使用する複数の中間層の構成」を参照してください。

注意:

この構成のWebプロバイダへの影響については、第6.3.6項「ステップ6: PortalツールとWebプロバイダの構成(オプション)」を参照してください。

5. LBRを介してOracle Metadata Repositoryから無効化リクエスト用のOracle Web Cacheへの通信を問題なく実行できるようにします。これには、NAT関連の構成が必要になることがあります。

Oracle HTTP Serverパートナ・アプリケーションの再登録

ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義します。ssoregは、ORACLE_HOME/sso/binのインフラストラクチャ層にあります。

次の例は、UNIX上でのssoregの使用方法を示しています。

$ ssoreg.sh
-site_name lbr.abc.com
-config_mod_osso TRUE
-mod_osso_url https://lbr.abc.com:8094
-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管理者ガイド』のパートナ・アプリケーションの作成に関する項を参照してください。

Secure Enterprise Searchのアクセスの有効化

セキュアなWebサイトにSecure Enterprise Searchからアクセスするには、インフラストラクチャ・インスタンスにあるクローラのトラストストアおよびOracle Containers for J2EE (WLS) JVMのトラストストアに証明書をインポートする必要があります。

デフォルトでは、WLS JVMは、既知の認証局の証明書を認識します。ただし、セキュアなポータル・インスタンスが、自己署名の証明書または不明な認証局によって署名された証明書を使用する場合は、そのポータルの証明書をWLS JVMのトラストストアにインポートする必要があります。WLS JVMのデフォルトのトラストストアは、ORACLE_HOME\jdk\jre\lib\security\cacertsにあります。

必要な証明書をトラストストアに追加するには、インフラストラクチャ・インスタンスで次の手順を実行します。

1. ディレクトリを、インフラストラクチャのORACLE_INSTANCE\jdk\jre\lib\securityに変更します。

2. トラストストア・ファイルcacertsのバックアップ(cacerts.bakなど)を作成します。

3. 次のUNIXのコマンドを実行して、必要な証明書をトラストストアに追加します。

$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/jdk/jre/lib/security/cacerts

注意:

-aliasには任意の値を使用してください。ただし、この値は証明書ごとに一意である必要があります。

4. トラストストア・パスワードを入力し、確認を促すメッセージが表示されたら「Yes」と入力します。

注意:

前述の手順は、Secure Enterprise Searchクローラを含むOracleAS Infrastructure上でも実行する必要があります。

WebLogicプラグインの有効化

「WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化」を参照してください。

7.3.2.1.7 Oracle WebLogic管理対象サーバーのSSLの構成

この項では、WebLogic管理コンソールを使用して、WLSでSSLを有効にする方法について説明します。次の手順を実行します。

1. WebLogic管理コンソールにログインして、ポータルのインストール時に作成したドメインに対してコンソールが構成されていることを確認します。

2. まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. コンソールの左側のペインで、「環境」を開いて「サーバー」を選択します。

4. 「サーバー」の表で、管理対象サーバーWLS_Portalのインスタンスをクリックします。

5. 「SSLリスニング・ポート有効」を選択して「SSLリスニング・ポート」に番号を入力します。

6. 「構成」タブ・グループ→「キーストア」タブ・ページを選択します。

7. 「キーストア」フィールドで「デモIDとデモ信頼」オプションを選択します。

8. 「一般」タブ・ページを選択します。

9. ページ末尾近くの「詳細」オプショングループを開き、「WebLogicプラグインの有効化」オプションを選択します。

10. 「保存」をクリックします。

これで、WLS管理対象サーバー(WLS_Portal)がSSLで構成されました。

7.3.2.1.8 SSLを介して公開されるWebプロバイダ、プロバイダ・グループおよびWSRPプロデューサの構成と登録

この項では、SSLを介して公開されるWebプロバイダ、プロバイダ・グループおよびWSRPプロデューサにアクセスするためのOracle Portalの構成方法について説明します。この項には次のトピックが含まれます:

- SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録

- SSLを介して公開されるWSRPプロデューサの構成と登録

SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録

SSLを介して公開されるWebプロバイダを登録するには、Webプロバイダが使用する認証局のルート証明書のコピーが必要です。Webプロバイダが不明または一般的でない認証局を使用している場合は、適切なルート証明書(Base-64 encoded X.509形式を使用)を信頼できる証明書のセットに追加する必要があります。この証明書セットは、Oracle Portalスキーマを含むOracle Metadata RepositoryをホストするOracle Databaseによって認識されます。SSLを介して公開されるWebプロバイダまたはプロバイダ・グループを構成するには、次の手順を実行します。

1. プロデューサのSSL証明書をデータベース・キーストアにインポートするには、次の手順を実行します。

- ディレクトリを、Oracleホームの$ORACLE_HOME/javavm/lib/securityに変更します。ここには、Oracle Portalスキーマを収めたOracle Metadata RepositoryをホストするOracle Databaseが格納されています。

- トラストストア・ファイルcacertsのバックアップ(cacerts.bakなど)を作成します。

- 次のUNIXのコマンドを実行して、必要な証明書をトラストストアに追加します。

$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/javavm/lib/security/cacerts

注意:

-aliasには任意の値を使用してください。ただし、この値は証明書ごとに一意である必要があります。

- トラストストア・パスワードを入力し、確認を促すメッセージが表示されたら「Yes」と入力します。

注意:

ポータル・スキーマがリポジトリ作成ユーティリティ(RCU)データベース内にあり、そのOracle Databaseリリースが10g (10.1.0.x)より古い場合、これらの手順は不要です。

例7-7 データベースへの証明書の登録

[ABC@stake03 security]$ $ORACLE_HOME/jdk/bin/keytool -import -alias cacert2 -file /home/name1/testcer.crt.cer -trustcacerts -v -keystore /u01/app/oracle/product/1021prod_ee/javavm/lib/security/cacerts
Enter keystore password:  changeit
Owner: CN=xmlns.oracle.com, O=wc_1
Issuer: CN=xmlns.oracle.com, O=wc_1
Serial number: 0
Valid from: Thu Mar 06 19:48:48 PST 2008 until: Tue Mar 05 19:48:48 PST 2013
Certificate fingerprints:
MD5:  4D:43:B4:A7:E9:02:33:20:A9:82:C4:CE:8D:4A:46:59
SHA1: FB:3D:1D:6D:01:6F:7B:35:27:85:20:0F:C4:28:F2:6A  2:75:1D:29
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Saving /u01/app/oracle/product/1021prod_ee/javavm/lib/security/cacerts]

2. プロデューサのSSL証明書をポータル中間層のWLSキーストアにインポートするには、次の手順を実行します。

- ディレクトリを、WLS_PORTAL管理対象サーバーを実行しているJDKのJavaホームJAVA_HOME/jre/lib/security/に変更します。

- トラストストア・ファイルcacertsのバックアップ(cacerts.bakなど)を作成します。

- 次のコマンドを実行して、必要な証明書をトラストストアに追加します。

$JAVA_HOME/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $JAVA_HOME/jre/lib/security/cacerts

注意:

-aliasには任意の値を使用してください。ただし、この値は証明書ごとに一意である必要があります。

- トラストストア・パスワードを入力し、確認を促すメッセージが表示されたら「Yes」と入力します。

例7-8 ポータル中間層のWLSへの証明書の登録

[ABC@stake03 security]$ $JAVA_HOME/jdk/bin/keytool -import -alias cacert2 -file /home/name1/testcer.crt.cer -trustcacerts -v -keystore /u01/app/oracle/product/portal/jdk/jre/lib/security/cacerts
Enter keystore password:  changeit
Owner: CN=xmlns.oracle.com, O=wc_1
Issuer: CN=xmlns.oracle.com, O=wc_1
Serial number: 0
Valid from: Thu Mar 06 19:48:48 PST 2008 until: Tue Mar 05 19:48:48 PST 2013
Certificate fingerprints:
MD5:  4D:43:B4:A7:E9:02:33:20:A9:82:C4:CE:8D:4A:46:59
SHA1: FB:3D:1D:6D:01:6F:7B:35:27:85:20:0F:C4:28:F2:6A  2:75:1D:29
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Saving /u01/app/oracle/product/portal/jdk/jre/lib/security/cacerts]

関連項目:

第7.3.2.1.5項「Oracle PortalのエンドツーエンドSSL」の「Parallel Page Engineの保護」

SSLを介して公開されるWSRPプロデューサの構成と登録

SSLを介して公開されるWSRPプロデューサを構成するには、次の手順を実行します。

1. Webブラウザで、WSRPプロデューサのWSDL URLを入力し、このURLが機能していることを確認します。WSDL定義がブラウザに表示されない場合は、WARファイルの配置に失敗していることになります。詳細は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』のJavaポートレットの問題の診断に関する項を参照してください。

2. WSDLファイルを変更して、HTTPを介して使用できるようにします。

注意:

次の手順は、HTTPプロトコルを使用してWSRPポートを生成する場合の設定用です。これは、WSDL URLのリクエストにHTTPが使用されていたためです。ただし、HTTPを使用してWSDLにアクセスしており、HTTPSを使用して内部URLを参照する場合は、ステップ2を省略してください。

1. Webブラウザに、HTTPS WSDL URLを入力します。例:
https://host:port/context-root/portlets?WSDL

WSDL定義内の各ポートがHTTPSの場所とともに表示されます。例:

<wsdl:port binding="bind:WSRP_v1_Markup_Binding_SOAP" name="WSRPBaseService">
<soap:address location="https://host:port/context-root/portlets/WSRPBaseService"/>
</wsdl:port>

2. WSDL定義のコピーをアプリケーション・サーバー上のファイルに保存します。このファイルは、HTTPを介した外部アクセスが可能な場所に存在する必要があります。たとえば、Oracle PortalのインストールのORACLE_HOME/Apache/Apache/htdocs/ディレクトリを使用します。プロデューサをOracle Portalに登録する場合は、登録の「接続の定義」ページで、「WSDL URL」にこのWSDLの場所を使用します。WSDL URLの形式は次のとおりです。
http://<host>:<port>/<Savedxml.xml>WSDL

注意:

WSDL URLの形式で、ファイル・タイプを<Savedxml.xml>から<Savedxml.html>または<Savedxml.txt>に変更します。このファイル・タイプの変更は、Oracle Portalのバージョン11.1.1.4.0以降で必要になります。

3. ポートがHTTPSの場所とともに表示されていない場合は、ポートを手動で変更してから続行する必要があります。これを行うには、ブラウザでXMLをファイルに保存し、テキスト・エディタで開きます。

3. SSLを介して公開されるWSRPプロデューサを登録するには、WSRPプロデューサが使用する認証局のルート証明書のコピーが必要です。Oracle Portalスキーマを含むOracle Metadata RepositoryをホストしているOracle Databaseによって認識される、信頼できる証明書のセットにルート証明書が存在するかどうかを確認します。ルート証明書がすでに存在するかどうかを確認するには、第7.3.2.1.5項「SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録」の手順1と2を繰り返してください。SSL対応ポータルのホーム・ページにアクセスします。証明書のセキュリティの警告ダイアログ・ボックスが表示される場合は、ステップ4を省略します。

4. WSRPプロデューサが不明または一般的でない認証局を使用している場合は、適切なルート証明書(Base-64 encoded X.509形式を使用)を信頼できる証明書のセットに追加する必要があります。WSRPプロデューサで使用する認証局のルート証明書をトラストストアに追加するには、第7.3.2.1.5項「SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録」の手順1と2を繰り返してください。

5. (オプション)PPEで特定の証明書のみを信頼する場合は、x509certfileをappConfig.xmlファイル(場所: DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration)に追加します。x509certfileの値は、信頼できるサーバー・グループを定義する証明書のリストを含むテキスト・ファイルへの絶対パスです。例:
<x509certfile>c:\mySSLconfig\trustedCerts.txt</x509certfile>

一般的なtrustedCerts.txtファイルは、例7-9に示すような内容を含んでいます。

例7-9 証明書のリストを含むサンプル・ファイル

-----BEGIN CERTIFICATE-----
MIICPDCCAaUCEDJQM89Q0VbzXIGtZVxPyCUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTIwMDEwNzIzNTk1OVow
XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQ
VoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2
yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAEtEZmBoZOSY
G/OwcuaViXzde7OVwB0u2NgZ0C00PcZQmhCGjKo/O6gE/DdSlcPZydvN8oYGxLEb8IKIMEKOF1Ac
ZHq4PplJdJf8rAJD+5YMVgQlDHx8h50kp9jwMim1pN9dokzFFjKoQvZFprY2ueC/ZTaTwtLXa9ze
WdaiNfhF
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIICPTCCAaYCEQC6WslMBTuS1qe2307QU5INMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0wNDAxMDcyMzU5NTla
MF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3Mg
MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAtlqLow1qI4OAa885h/QhEzMGTCWi7VUSl8WngLn6g8EgoPovFQ18oWBrfnks
+gYPOq72G2+x0v8vKFJfg31LxHq3+GYfgFT8t8KOWUoUV0bRmpO+QZEDuxWAk1zr58wIbD8+s0r8
/0tsI9VQgiZEGY4jw3HqGSRHBJ51v8imAB8CAwEAATANBgkqhkiG9w0BAQIFAAOBgQC2AB+TV6QH
p0DOZUA/VV7t7/pUSaUw1iF8YYfug5MLv7Qz8pisnwa/TqjOFIFMywROWMPPX+5815pvy0GKt3+B
uP+EYcYnQ2UdDOyxAArdG6S7x3ggKLKi3TaVLuFUT79guXdoEZkj6OpS6KoATmdOu5C1RZtG644W
78QzWzM91Q==
-----END CERTIFICATE-----

注意:

x509certfileを実装しないと、PPEではすべてのSSL証明書を信頼します。

6. Oracle Fusion Middlewareインスタンスを再起動します。

ORACLE_HOME/opmn/bin/opmnctl stopallORACLE_HOME/opmn/bin/opmnctl startall

7. WSDLを指定してWSRPプロデューサを登録します。ここで使用するURLは、HTTPSベースである必要があります。例:

http://><host>:<port>/wsrp-tools/portlets/wsrp2/WSDL

7.3.2.2 Oracle Internet Directoryへの接続の保護(オプション)

第7.3.2.1項「Oracle PortalのSSLの構成」では、主にHTTPベースのネットワーク・ホップについて説明しました。しかし、Oracle Internet Directory自体へのネットワーク接続(LDAPベースの通信)も保護することができます。この場合は、Oracle Internet DirectoryがLDAP over SSL (LDAPS)を使用するよう構成されている必要があります。Oracle Internet DirectoryをLDAPS用に構成する方法の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

Oracle Internet DirectoryでSSLが使用されるように構成したら、Oracle Portalスキーマを更新して、LDAPサーバーで新しいポートが使用されるようにする必要があります。この手順を実行するには、ORACLE_HOME/portal/admin/plsql/wwcにあるSQLスクリプトsecupoid.sqlを実行します。このスクリプトを使用すると、次のOracle Internet Directory関連のパラメータを設定できます。

- ディレクトリのホスト名

- ディレクトリ・ポート

- アプリケーション・ディレクトリのパスワード

- SSL設定

このスクリプトを実行すると、現在の設定が表示され、それに応じてその設定を変更できます。この場合は、次の設定を行います。

use_ssl_to_connect_to_ldap=Y

スクリプトにより、Oracle PortalのOracle Internet Directoryキャッシュを自動更新するオプションが提供されます。詳細は、第B.2項「secupoid.sqlスクリプトの使用」を参照してください。

注意:

10g リリース2 (10.1.2)以降では、インストール後にLDAPSを実装する必要はなく、オプションで、LDAPSを使用してOracle Portalをインストールできます。

7.3.2.3 インストール後のセキュリティのチェックリスト

Oracle Portalをインストールした後は、次の手順を実行してセキュリティの構成を行うことを考慮する必要があります。

- Oracle TextのベースURLの更新

- 軽量のOracle Portalユーザーのパスワードの保護

- 不要なオブジェクトの削除

- デフォルトで生成済の権限の確認

- プロバイダのコンポーネントへのパブリック・アクセスの取消し

- 管理ページへのアクセス制御

- PL/SQLパッケージの保護

- SSL使用の考慮

- Oracle Internet Directory接続でのLDAP over SSLの使用の考慮

- アプリケーション・エンティティのパスワードの変更

7.3.2.3.1 Oracle TextのベースURLの更新

ポータルをSSLで構成したら、次の手順を実行してOracle TextのベースURLを更新します。

1. Oracle Portalにログインします。

2. 「管理」タブをクリックします。

3. 「サービス」ポートレットで、「グローバル設定」を選択します。

4. 「グローバル設定」ページで「検索」タブを選択します。

5. 「Oracle TextのベースURL」の「ベースURL」で、URLのプロパティを「http」から「https」に変更します。たとえば、http://abc0088.us.abc.com:8090/portal/pls/portal/からhttps://abc0088.us.abc.com:8090/portal/pls/portal/に変更します。

7.3.2.3.2 軽量のOracle Portalユーザーのパスワードの保護

悪意のユーザーがデフォルト・ユーザーのパスワードを探ろうとすると、アカウントがロックされます。このロックはサーバーから解除することができますが、管理上、デフォルト・ユーザー・アカウントに依存しないことをお薦めします。これらのアカウントのパスワードを保護するには、次の手順を実行します。

1. デフォルト・ユーザーと同じアクセス権を使用して新しい軽量の管理者アカウントを作成し、OracleAS Single Sign-Onのデフォルト・ユーザーのアカウントの終了日付を設定します。または、デフォルト・ユーザーの「ユーザーの編集」ページの「ユーザーにログインを許可する」設定の選択を解除することもできます。

2. デフォルト・ユーザーのログインを無効にするか、パスワードを変更したら、デフォルトのパスワードを使ってデフォルト・ユーザーとしてポータルにログインし、変更が正しく行われたことを確認します。

7.3.2.3.3 不要なオブジェクトの削除

廃止されたページや不要なページからポータルにユーザーが入るのを防ぐには、使用していないオブジェクトをOracle Portalおよびデータベース環境から削除する必要があります。例:

- 使用していないページ・グループを削除します。

- 使用していないOracle Portalプロバイダを削除します。

7.3.2.3.4 デフォルトで生成済の権限の確認

Oracle Portalがインストールされると、表7-2に示してある生成済のグループに、それらのロールで通常必要とされる権限のセットが用意されます。これらの最初の権限のセットを確認して、それらがセキュリティ・ポリシーと矛盾していないことを確認する必要があります。

ユーザーまたはグループは、次のいずれかのソースから権限を取得することができます。

- Oracle Portalのアクセス制御エントリ

- Oracle Internet Directoryの権限グループ

Oracle Portalのアクセス制御エントリから付与された権限を編集するには、「Portalユーザー・プロファイル」ポートレットまたは「Portalグループ・プロファイル」ポートレットの「管理」タブからユーザーまたはグループのプロファイルを編集します。「ユーザー・プロファイル」または「グループ・プロファイル」ダイアログの「権限」タブをクリックします。このリストから権限を取り消すことも、割り当てることもできます。

Oracle Internet Directoryの権限グループから付与された権限を編集するには、Oracle Internet Directoryで「ユーザー」ポートレットまたは「グループ」ポートレットを使用してユーザーまたはグループを編集します。Oracle Internet Directoryで「権限の割当て」リストの横のチェックマークを付けたり、外したりして、適切な権限を付与したり、取り消したりします。

AUTHENTICATED_USERSグループに付与された権限は、OracleAS Single Sign-Onを通じてOracle Portalにログインしたすべてのユーザーに、認証に成功した時点で与えられます。これは、ログインしたすべてのユーザーを対象にデフォルトの権限で作成するグループです。

たとえば、認証されているユーザーがグループを作成できないようにする場合は、「グループ」ポートレットからAUTHENTICATED_USERSグループを編集し、「権限の割当て」にある「グループの作成を許可」の横のチェックマークを外します。

7.3.2.3.5 プロバイダのコンポーネントへのパブリック・アクセスの取消し

場合によっては、Oracle Portalプロバイダのコンポーネントで、アプリケーション表のレコードを表示するか、変更するかをユーザーが選択できます。セキュリティを強化するには、不要な場合、このようなコンポーネントからのパブリック・アクセスを取り消す必要があります。また、メニュー・オプションに対して特定のアクセス権を持つメニュー・コンポーネントを使用して、アプリケーション・アクセスをより厳しく制御することもできます。

7.3.2.3.6 管理ページへのアクセス制御

管理インタフェースにアクセスしてはならないユーザーが管理ページに入るのを防ぐには、次のページ・グループとそれらに含まれているページに対するアクセス権を制御する必要があります。

- 「ポータル・デザインタイム・ページ」: Oracle Portalホーム・ページ、ビルダー・ページ、ナビゲータ・ページが含まれているページ・グループです。

- ポートレット・リポジトリ。

前述のページ・グループへのアクセスを制御するには、次の手順を実行します。

1. 「ナビゲータ」で、「ページ・グループ」をクリックします。

2. アクセス設定を変更するページ・グループの横の「プロパティの編集」をクリックします。

3. 「アクセス」タブをクリックします。

4. MANAGE ALLを特定のユーザーまたは特定のグループに付与します。たとえば、DBA、PORTAL_ADMINISTRATORS、PORTAL_DEVELOPERS、独自のグループなどです。

5. 終了したら、「OK」をクリックします。

これらのページ・グループの個々の管理ページへのアクセスを制御するには、次の手順を実行します。

1. 「ナビゲータ」で、「ページ・グループ」をクリックします。

2. アクセス設定を変更するページが含まれているページ・グループの横の「コンテンツ」をクリックします。

3. 「ページ」をクリックします。

4. アクセス設定を変更するページの横の「プロパティ」をクリックします。

5. 「アクセス」タブをクリックします。

6. MANAGE ALLを特定のユーザーまたは特定のグループに付与します。たとえば、DBA、PORTAL_ADMINISTRATORS、PORTAL_DEVELOPERS、独自のグループなどです。

7. 終了したら、「OK」をクリックします。

注意:

「ビルダー」ページは、Portal設計時ページというページ・グループのルート・ページです。そのアクセス設定を変更するには、Portal設計時ページ・グループの横の「ルート・ページの編集」をクリックする必要があります。

7.3.2.3.7 PL/SQLパッケージの保護

デフォルトのインストールでは、PUBLICに付与されている標準のデータベース手順(dbms_*やutl_*など)を保護します。独自に記述したPL/SQLパッケージをPUBLICに割り当て、それらのパッケージへWebブラウザからアクセスできないようにするときは、『Oracle Fusion Middleware mod_plsqlユーザーズ・ガイド』の「mod_plsqlを使用したアプリケーション・データベース・アクセスの保護」を参照してください。

7.3.2.3.8 SSL使用の考慮

ポータルに機密情報が含まれている場合は、SSLを使用してポータルを構成することを考慮してください。使用可能なSSL構成オプションは、第7.3.2.1項「Oracle PortalのSSLの構成」を参照してください。

7.3.2.3.9 Oracle Internet Directory接続でのLDAP over SSLの使用の考慮

デフォルトでは、Oracle Portalは、ディレクトリに接続するときに、SSLを使用しないLDAPを使用します。ディレクトリ・サーバーがSSLポートに対応している場合は、LDAP over SSL (LDAPS)を使用するようにOracle Portalを構成できます。

関連項目:

Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

ディレクトリへの接続にSSLを使用するようにOracle Portalを構成するには、ORACLE_HOME/portal/admin/plsql/wwcにあるsecupoid.sqlスクリプトを実行する必要があります。このスクリプトにより、ディレクトリに関連する次のOracle Portal構成パラメータを変更できます。

- ディレクトリのホスト名

- ディレクトリ・ポート

- アプリケーション・ディレクトリのパスワード

- SSL設定

Oracle Portalをインストールすると、ディレクトリ・サーバーを使用するように自動的に構成されます。ただし、SSLを使用するかどうかなど、インストール後に一部の設定を変更できます。ディレクトリのSSL接続を変更するには、PORTALスキーマのsecupoid.sqlスクリプトを実行して、LDAPポートのかわりにLDAPSポートを指定すると、SSLを使用するように指定されます。

secupoid.sqlスクリプトの実行

この項では、SQL*Plusからsecupoid.sqlを実行した例を示します。

この例では、LDAPをポート389で実行するようにディレクトリを初期構成しています。次にLDAPSポートを636上で有効にします。サーバー名は変わらないため、以前の値を保持したままポートを更新し、SSLを使用することを指定するために「Use SSL?」に対して「Y」を設定します。このスクリプトを実行すると、現在の構成が表示され、変更可能な構成を置き換えることができます。スクリプトの実行後に、Oracle Portalのディレクトリ・キャッシュを更新することもできます。SSLを有効にしても、Oracle Portalによってキャッシュされたディレクトリ情報は変更されません。このため、通常はこうした状況でキャッシュを更新する必要はありません。

SQL> @secupoid
Current Configuration
--------------------
OID Host: oid.domain.com
OID Port: 389
Application DN:
orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext
Application Password: 3E8C2D1B87CB61011757239C5AA9B390
Use SSL? N

PL/SQL procedure successfully completed.

Updating OID Configuration Entries
Press [Enter] to retain the current value for each parameter
For SSL Connection to LDAP, specify "Y"es or "N"o
------------------------------------------------
Enter value for oid_host:
Enter value for oid_port: 636
Enter value for app_password:
Enter value for use_ssl_to_connect_to_ldap: Y
Enter value for refresh_with_new_settings: N

PL/SQL procedure successfully completed.

No errors.

このスクリプトの実行後に、Oracle Portalは、ディレクトリでLDAPSアクセスを使用するように構成されます。詳細は、第B.2項「secupoid.sqlスクリプトの使用」を参照してください。

7.3.2.3.10 アプリケーション・エンティティのパスワードの変更

Oracle Portalでは、ユーザーのパスワードをディレクトリに渡しません。OracleAS Single Sign-Onのみで、この処理が行われます。ただし、Oracle Portalは、そのアプリケーション・エンティティとパスワードを使用して、ディレクトリに対する認証を行います。

アプリケーション・エンティティのパスワードを変更する場合は、まずコマンドライン・ユーティリティまたはOracle Directory Managerを使用して、ディレクトリ内にあるそのエントリを変更する必要があります。ディレクトリでアプリケーション・エントリを見つけるには、secupoid.sqlスクリプトによって報告されるDNが必要です。デフォルトでは、Oracle Portalのアプリケーション・エントリは次のとおりです。

orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext

パスワードを変更するには、アプリケーション・エントリのuserPassword属性を新しいパスワードに設定します。

ディレクトリのパスワードの変更後に、PORTALスキーマでsecupoid.sqlスクリプトを実行し、同じように新しいパスワードを指定します。スクリプトを実行することで、Oracle Portalでパスワードを暗号化して保存し、ディレクトリへの接続時に検索できるようになります。

secupoid.sqlスクリプトの詳細は、第B.2項「secupoid.sqlスクリプトの使用」を参照してください。

関連項目:

アプリケーション・エンティティの詳細は、第7.1.7.3.1項「Oracle PortalのOracle Internet Directoryにあるディレクトリ・エントリ」を参照してください。

7.3.3 データベースのセキュリティのためのOracle Portalオプションの構成

ファイングレイン・アクセス・コントロールと保護アプリケーション・コンテキストがあれば、新しい局面でデータベース内のデータを保護することができます。

ファイングレイン・アクセス・コントロールは、仮想プライベート・データベースまたは行レベルのセキュリティと呼ばれることもあります。Oracle Database 11gのファイングレイン・アクセス・コントロールは、実行時に、データベース表やビューに対して発行されるあらゆる問合せに条件(WHERE句)を動的にアタッチする機能です。この機能を使用すると、実行時にプロシージャで問合せを変更できます。問合せを実行しているユーザー、問合せを実行している場所、問合せを実行している日時などを調べ、それらの状況をふまえて条件を作成することができます。アプリケーション・コンテキストを使用すると、安全に情報を環境(ユーザーが保持するアプリケーション・ロールなど)に追加したり、プロシージャや条件の中でもそれにアクセスしたりできます。

ファイングレイン・アクセス・コントロールの例として、異なるグループのユーザーが表示できる行を特定するセキュリティ・ポリシーを設けることができます。セキュリティ・ポリシーでは、ログインしているユーザーやそのユーザーが属しているグループに基づいて条件を作成します。

ファイングレイン・アクセスとアプリケーション・コンテキストの詳細は、Portal Center(http://portalcenter.oracle.com/)を参照してください。

脚注の凡例

脚注1: デフォルトのID管理レルムの名前は、システムがインストールされているサーバーのドメイン名によって決定されます。たとえば、ドメイン・ネーム・サーバーがoracleであった場合、デフォルトのID管理レルム名はdc=oracle,dc=comとなります。ドメイン・ネーム・サーバーがわからない場合、ディレクトリによって割り当てられているデフォルト名はdc=Default Company,dc=comです。

8 Oracle Portalの監視と管理

この章では、利用可能な監視および管理のツールについてと、そのようなツールを使用してOracle Portalを監視および管理する方法を説明します。

Oracle Portalは、Oracle Enterprise Manager 11g Fusion Middleware Controlから監視および管理できます。また、Oracle Portalのパフォーマンスを監視し、Oracle Portalのアクセス特性を分析するために、Oracle Portal Analyticsを表示することができます。

WLSTを使用してOracle Portalを構成することもできます。第5.1.2.2項「WebLogic Scripting Tool (WLST)コマンドライン・ユーティリティ」を参照してください。

関連項目:

Oracle Portalの監視と管理の詳細は、Oracle Technology Network (OTN)のOracle Portalの管理に関するページ(http://www.oracle.com/technology/products/ias/portal/index.html)を参照してください。

この章の内容:

- Oracle Enterprise Manager 11g Fusion Middleware Controlの使用

- Fusion Middleware Controlを使用したOracle Portalの監視と管理

- Oracle Portal動作レポートの表示

- Oracle Fusion Middlewareポート情報の表示

- Oracle Enterprise Managerの管理ロールの定義

- Oracle Fusion MiddlewareのシステムMBeanブラウザについて

8.1 Oracle Enterprise Manager 11g Fusion Middleware Controlの使用

Oracle Enterprise Manager 11g Fusion Middleware Controlは、Oracle Portalをインストールすると同時にインストールされます。Oracle Portalの観点からは、Oracle Portal用の管理コンソールとみなされます。Oracle Enterprise Consoleでは、次の処理を実行できます。

- クラスタの管理

- サービスの開始および停止

- ログおよびポートの表示

- リアルタイム監視の実行

Oracle Enterprise Manager 11g Fusion Middleware Controlへのアクセス

http://<hostname.domain>:<port>/emのURLに移動することにより、アクセスできます。たとえば、http://myhost.mycompany.com:7001/emにアクセスします。

Fusion Middleware Controlの開始ページは、ファーム・ホーム・ページです。このページには、ファームのシステム・コンポーネントのステータスを示す「アプリケーションのデプロイ」ページおよび「Fusion Middleware」ページがあります。これらのポートレットから、監視および管理の目的で、Oracle Fusion Middlewareの各コンポーネントのホーム・ページを表示できます。

Oracle Portalを構成済の場合は、「Fusion Middleware」ポートレットの「Portal: portal (WLS_PORTAL)」にOracle Portalが表示されます。

関連項目:

Oracle Fusion Middleware管理者ガイド

8.2 Fusion Middleware Controlを使用したOracle Portalの監視と管理

Oracle Portalを監視および管理するには、Oracle Fusion Middlewareホーム・ページの「ポータル」でポータルJ2EEアプリケーション名をクリックします。Portalアプリケーションの他にWebLogicコンテナ名も表示されるので、特定のWebLogicコンテナで稼働している特定のポータル・アプリケーションを識別できます。WLS_PORTALはポータル・サーブレットのコンテナであり、監視する実際のポータル・サーブレットではありません。

Fusion Middleware Controlには、Portalに関する有用なメトリックが多数表示されます。このメトリックを表形式で表示すると、メトリックの行を昇順または降順にソートして最大値および最小値を容易に検索できます。

8.2.1 Portalホーム・ページの概要

図8-1は、Oracle Portalの監視のメイン・ページであるOracle Portalホーム・ページを示しています。ここからPortalの構成、ログ、メトリックの各ページおよびPortalコンポーネントにアクセスします。

図8-1 Oracle Fusion Middleware Control - Oracle Portalホーム・ページ

図8-1に示すように、Oracle Portalホーム・ページには、様々なポートレットが表示されます。これらについては、次の各項で説明します。

- 「ページ・レスポンス時間」ポートレット

- 「ページ・レスポンス・コード統計」ポートレット

- 「ポピュラーなプロデューサ」ポートレット

- 「関連コンポーネント」ポートレット

- 「プロデューサ」ポートレット

- 「リソース・センター」ポートレット

- 「ページ・エンジン統計」ポートレット

8.2.1.1 「ページ・レスポンス時間」ポートレット

図8-2に示すように、「ページ・レスポンス時間」ポートレットには、Parallel Page Engine (PPE)がページの生成に要する平均時間(ミリ秒)がグラフで表示されます。

図8-2 「ページ・レスポンス時間」ポートレット

8.2.1.2 「ページ・レスポンス・コード統計」ポートレット

図8-3に示すように、「ページ・レスポンス・コード統計」ポートレットには、PortalのPPEで生成されたHTTPレスポンス・コードに関する統計が表示されています。通常、HTTP-2xxおよびHTTP-3xxのステータス・コードは、レスポンスが成功したことを意味します。

図8-3 「ページ・レスポンス・コード統計」ポートレット

8.2.1.3 「ポピュラーなプロデューサ」ポートレット

図8-4に示すように、「ポピュラーなプロデューサ」ポートレットには、アクセス数に基づいて相対的に使用頻度の高いプロデューサがグラフで表示されています。

図8-4 「ポピュラーなプロデューサ」ポートレット

8.2.1.4 「関連コンポーネント」ポートレット

「関連コンポーネント」ポートレットには、Oracle Portalによって使用されるOracle Fusion Middlewareコンポーネントが一覧表示されます。リンクをクリックすると、個々のOracle Fusion Middlewareコンポーネントについて、より詳しい情報へドリルダウンすることができます。表示されるコンポーネントは、次のとおりです。

- Portal URL

- WebLogic Server

8.2.1.4.1 Portal URL

Portal URLをクリックすると、現在構成されているOracle Portalの「ようこそ」ページが表示されます。

8.2.1.4.2 WebLogic Server

「関連コンポーネント」ポートレット内の「WebLogic Server」(ドメイン名)リンクをクリックすると、現在構成されているOracle Portalに関連付けられているWLSインスタンスのOracle WebLogic Serverドメインのホーム・ページが表示されます。このホーム・ページが、Oracle Portalに関連付けられているWLSインスタンスを管理および監視するための開始位置です。たとえば、ここからWLSインスタンスを再起動することができます。構成を変更した場合、Portal上で稼働するWebLogic Serverを必ず再起動する必要があります。WebLogic Server(ドメイン名)リンクをクリックすると、その再起動の処理を素早く実行できます。

8.2.1.5 「プロデューサ」ポートレット

図8-5に示すように、「プロデューサ」ポートレットには、Portalプロデューサ、およびそのステータスとメトリックが一覧表示されています。ポートレットから前回に得たレスポンス・コードにエラーがない場合、プロデューサのステータスには「稼働中」と表示されます。少なくとも1つのポートレットから得た前回のレスポンス・コードにエラーがあった場合は、「停止中」と表示されます。

監視できるメトリックは、次のとおりです。

- ステータス - 特定のプロデューサのポートレットが「稼働中」または「停止中」かを示します。

- 可用性 - プロデューサからHTTP-2xxレスポンスを取得したクエストの割合。

- 起動 - プロデューサのポートレットが起動された回数。

- 平均 - プロデューサのポートレットをリクエストするための平均時間(ミリ秒)。

図8-5 「プロデューサ」ポートレット

8.2.1.6 「リソース・センター」ポートレット

図8-6に示すように、「リソース・センター」ポートレットには、Oracle Fusion Middleware Controlを使用したOracle Portalの構成に関する一般的な情報へのリンク、共通の管理タスクの手順へのリンク、およびその他の役立つサイトへのリンクが提供されています。

図8-6 「リソース・センター」ポートレット

8.2.1.7 「ページ・エンジン統計」ポートレット

図8-7に示すように、「ページ・エンジン統計」ポートレットには、PPEの平均レスポンス時間、ページ・アクセス数、ページ・メタデータ・メトリックおよびキューのステータスが表示されています。

図8-7 「ページ・エンジン統計」ポートレット

8.2.2 Oracleホーム・ページからの管理と監視

Oracle Portalホーム・ページから、Oracle PortalおよびPortalのJ2EEアプリケーションを停止および起動できるほか、Portalの構成、ログおよびメトリックの各ページにアクセスできます。

8.2.2.1 「パフォーマンス・メトリック」ページ

「パフォーマンス・メトリック」ページを使用すると、Oracle Portalのメトリックなど、Oracle Fusion Middlewareファームおよびファーム・コンポーネントのメトリックが表示されます。Portalホーム・ページの「ポータル」メニューから「監視」→「パフォーマンス・メトリック」をクリックすると、図8-8に示す「メトリック」ページが表示されます。

図8-8 Oracle Fusion Middleware - 「メトリック」ページ

メトリック収集の概要: 最近の履歴および起動以降のメトリック

Oracle Portalでは、パフォーマンス・メトリックが自動的に有効になっています。つまり、パフォーマンス・メトリックを収集するために、オプションの設定や何らかの外部構成の実行が必要になることはありません。アプリケーションの実行速度低下やハングなどの問題が発生した場合は、特定のメトリックを表示して、その問題に関する詳細情報を調査できます。Fusion Middleware Controlはデータをリアルタイムで提供します。

Oracle Portalでは、次のタイプのメトリックが得られます。

- 起動時以降: PortalアプリケーションをホストするWebLogic Serverが稼働中であれば、いつでもリアルタイムのメトリックが得られます。コンテナの起動時から収集または集計したリアルタイムのメトリックがPortalの「起動時以降」に表示されます。これらのメトリックは、WebLogic Serverがこれまで稼働した期間中に集計されたデータを示すのできわめて有用です。

注意:

メトリックの収集は、Oracle Fusion Middlewareコンポーネントが再起動した後に更新されます。再起動以前に収集されたデータは失われます。

- 最近の履歴: Oracle Portalメトリックは、「起動時以降」メトリックの他に、5分ごとにパフォーマンス・データを取得するように構成されています。このメトリック・データは、「起動時以降」メトリックと組み合せて「最近の履歴」メトリックとして得られます。「最近の履歴」に表示されるすべてのメトリックは、最新のメトリックのみを使用して計算されます。たとえば、あるサービスが短期間使用されたことがあっても、過去15分にはアクセスがなかった場合、そのサービスの「起動時以降」メトリックには正の数が表示されますが、「最近の履歴」メトリックはすべて0になります。「最近の履歴」メトリックでは、最近の実行時アクセスで収集したデータに基づいて、稼働中のサイトのパフォーマンスをリアルタイムで知ることができます。
一般的には、「最近の履歴」メトリックでは直前の10から15分のデータが示されます。ただし、直前の10から15分のデータではない場合もあります。

- WebLogic Serverが起動したばかりで、起動から10から15分経過していない場合、「最近の履歴」にはサーバーが起動してからの稼働期間のデータが表示されます。

- メトリックのリクエストが長期にわたって検出されない場合、メトリックの収集は一時的に停止します。クライアントがメトリックをリクエストすると収集が再開します。メトリックの収集が停止すると、メトリックの収集が停止した時点からのデータが「最近の履歴」に表示されます。メトリックの収集を再開すると、データの表示が始まります。

稼働中のサイトを診断しているときに、Portalのメトリック・ページに移動して「サービス・サマリー」セクションを表示すると、頻繁に使用されているサービスや予想外に時間がかかっているサービスを特定できます。タイムスタンプの横の「リフレッシュ」アイコンをクリックすると、ライブ・データのメトリックを更新できます。各サービスをクリックしてこの手順を繰り返し、サービスの中でどの処理に時間がかかっているかを判断します。必要に応じて、そのサービスを使用しているアプリケーションのページに移動して、より詳細なデータが得られる実行時メトリックをトリガーするようにアプリケーションを設定します。

「メトリック」ページは次の5つのタブで構成されています。

- 「ページ・メトリック」タブ

- 「キャッシュ・メトリック」タブ

- 「リポジトリ・メトリック」タブ

- 「プロデューサ・メトリック」タブ

- 「ポートレット・メトリック」タブ

詳細は、Oracle Enterprise Manager 11gのオンライン・ヘルプを参照してください。

「ページ・メトリック」タブ

「ページ・メトリック」タブ(図8-8)では次の情報が提供されます。

- PPEで生成されたHTTPレスポンス・コードの割合の統計。

- 起動以降の期間および最近の履歴での、ページのアクセス件数、平均ページ・レスポンス時間(ミリ秒)、処理リクエスト件数などのページ・エンジン統計。

「キャッシュ・メトリック」タブ

「キャッシュ・メトリック」タブ(図8-9)には、接続プール統計およびポータル・キャッシュ統計が表示されるポートレットがあります。

図8-9 Oracle Fusion Middleware - 「キャッシュ・メトリック」タブ

「リポジトリ・メトリック」タブ

「リポジトリ・メトリック」タブ(図8-10)には、リポジトリ・レスポンス・コード統計やデータベース接続プールなど、Portalデータベース・リポジトリ・リクエストのメトリックが表示されます。

図8-10 Oracle Fusion Middleware - 「リポジトリ・メトリック」タブ

- データベース接続プール: データベース接続プールのステータスが表示されます。

- 「リポジトリ・レスポンス・コード統計」ポートレットでは次の情報が提供されます。

- HTTPレスポンス・コードのタイプ。

- 起動以降と直前の15分間の、HTTPレスポンス・コードごとの起動数とその割合。

- 通常、HTTP-2xxおよびHTTP-3xxのステータス・コードは、レスポンスが成功したことを意味します。

- HTTP-499は、リクエストしたリソースが保護されているのでログイン・アクセスが必要であることを意味する特別なコードです。

- HTTP-470は、ログアウト処理が実行されたことを意味します。

- 起動以降の期間と最近の履歴での、各HTTPレスポンス・コードがリクエストの処理に要する平均時間。

- HTTPリクエストの処理に要した最大時間。

「プロデューサ・メトリック」タブ

「プロデューサ・メトリック」タブ(図8-11)には3つのポートレットがあり、それぞれ、アクセス数から見た最も使用頻度の高いプロデューサ、プロデューサのレスポンス時間およびすべてのプロデューサのデータを収めた表が表示されます。

図8-11 Oracle Fusion Middleware - 「プロデューサ・メトリック」タブ

- 「最もポピュラーなプロデューサ」ポートレットでは次の情報が提供されます。

- プロデューサ当たりの起動回数(チャートに表示)。

- このチャートでは、最大値は最も使用頻度が高いポートレット・プロデューサを示し、最小値は最も使用頻度が低いポートレット・プロデューサを示します。

- 「ポピュラーなプロデューサのレスポンス時間」では次の情報が提供されます。

- Portalアプリケーション起動以降の、各ポートレット・プロデューサがプロデューサ・リクエストの処理に要する平均時間(チャートに表示)。

- チャートの最大値は、最も処理が遅いポートレット・プロデューサを示し、最小値は最も処理が速いポートレット・プロデューサを示します。

- 「プロデューサ統計」ポートレットでは次の情報が提供されます。

- 監視対象のポートレット・プロデューサの名前。
ポートレット・プロデューサの名前をクリックすると、アプリケーションが使用している各ポートレットの詳細情報が表示されます。

- 各ポートレット・プロデューサの現在のステータス。
「稼働中」(緑の上向き矢印)は、ポートレット・プロデューサが稼働中であることを示し、「停止中」(赤い下向き矢印)は、ポートレット・プロデューサが現在使用できないことを示します。プロデューサ・インスタンスが停止中か、ネットワーク接続に問題がある可能性があります。

- 起動以降の期間と最近の履歴での、成功したプロデューサ起動回数の割合。

- 起動以降の期間と最近の履歴での、プロデューサ当たりの起動回数。

- 起動以降の期間と最近の履歴での、キャッシュ・ヒット数の割合。

- 「平均時間(ms)」表をソートすることで、使用しているPortalアプリケーションからのアクセス頻度が最も高いポートレット・プロデューサ、および各ポートレット・プロデューサがプロデューサ・リクエストの処理に要する平均時間(結果にかかわらず)を、起動以降の期間と最近の履歴で知ることができます。このメトリックを使用すると、非稼働のポートレット・プロデューサが検出されます。このメトリックを起動メトリックと組み合せて使用すると、どのプロデューサに重点を置くか優先順位を付けることができます。

- プロデューサ・リクエストの処理に要した最大時間と最小時間。

「ポートレット・メトリック」タブ

「ポートレット・メトリック」タブ(図8-15)には3つのポートレットがあり、それぞれ、アクセス数から見た最も使用頻度の高いポートレット、ポートレット・レスポンス時間およびその他のポートレット・メトリックが表示されます。

図8-12 Oracle Fusion Middleware - 「プロデューサ・メトリック」タブ

- 「最もポピュラーなポートレット」ポートレットでは次の情報が提供されます。

- ポートレット当たりの起動回数(チャートに表示)。
チャートの最大値は、最も使用頻度が高いポートレットを示し、最小値は最も使用頻度が低いポートレットを示します。

- 「ポピュラーなポートレット・レスポンス時間」では次の情報が提供されます。

- Portalアプリケーション起動以降の、各ポートレットがリクエストの処理に要する平均時間(チャートに表示)。

- チャートの最小値は、最高のパフォーマンスのポートレットを示します。

- 最大値は、最低のパフォーマンスのポートレットを示します。

- 「ポートレット統計」ポートレットでは次の情報が提供されます。

- 各ポートレットの現在のステータス。
「稼働中」(緑の上向き矢印)は、ポートレットが稼働中であることを示し、「停止中」(赤い下向き矢印)は、ポートレットが現在使用できないことを示します。プロデューサ・インスタンスが停止中か、ネットワーク接続に問題がある可能性があります。

- 監視されているポートレットの名前。

- ポートレットへのアクセスに使用されているポートレット・プロデューサの名前。

- ポートレット・プロデューサのタイプ(「Web」または「WSRP」)。
Webポートレット・プロデューサ - J2EEアプリケーション・サーバーに配置されます。多くの場合、このアプリケーション・サーバーはリモートであり、Simple Object Access Protocol (SOAP) over HTTPを使用して通信します。

WSRPポートレット・プロデューサ - Web Services for Remote Portlets (WSRP)はWebサービスの標準であり、これを利用すると、標準コンテナとあらゆるWSRPアプリケーション間の相互運用性が実現されます。

- 起動以降の期間と最近の履歴での、成功したプロデューサ起動回数の割合。「成功した呼出し(%)」が100%より小さい場合は、診断ログを確認してサービス・リクエストが失敗した原因を調べます。

- 起動以降の期間と最近の履歴での、プロデューサ当たりの起動回数。

- 起動以降の期間と最近の履歴での、キャッシュ・ヒット数の割合。

- 「平均時間(ms)」表をソートすることで、使用しているPortalアプリケーションからのアクセス頻度が最も高いポートレット、および各ポートレットがリクエストの処理に要する平均時間(結果にかかわらず)を、起動以降の期間と最近の履歴で知ることができます。このメトリックを使用すると、非稼働のポートレットが検出されます。このメトリックを起動メトリックと組み合せて使用すると、どのポートレットに重点を置くか優先順位を付けることができます。

- ポートレット・リクエストの処理に要した最大時間と最小時間。

8.2.2.2 「パフォーマンス・サマリー」ページ

「パフォーマンス・サマリー」ページを使用すると、Oracle PortalおよびOracle Portalコンポーネントのメトリックが表示されます。Oracle Fusion Middlewareでは、継続的に実行時のパフォーマンスを自動測定します。パフォーマンス・メトリックは自動的に有効になります。つまり、パフォーマンス・メトリックを収集するために、オプションを設定したり追加構成を行う必要はありません。アプリケーションの実行速度低下やハングなどの問題が発生した場合は、特定のメトリックを表示して、その問題に関する詳細情報を調査できます。

Portalホーム・ページの「ポータル」メニューから「監視」→「パフォーマンス・サマリー」をクリックすると、図8-13に示す「パフォーマンス・サマリー」ページが表示されます。

図8-13 Oracle Fusion Middleware - 「パフォーマンス・サマリー」ページ

「パフォーマンス・サマリー」ページから、次の操作を実行できます。

- 「時間範囲選択」バーのオプションを使用して、表示するメトリックの時間範囲を選択します。

- 「表示」オプションを使用して、表示オプション(メトリックしきい値など)を設定します。

- 「表ビュー」オプションを使用して、表形式でメトリックを表示します。

- 「メトリック・パレット」を使用して、表示するメトリックを選択します。

「時間範囲選択」オプション

「時間範囲選択」バー(図8-14)には、表示するメトリックの時間範囲を選択するオプションがあります。

図8-14 「時間範囲選択」バー

「表示」オプション

「表示」オプションを使用して、選択したメトリックのメトリックしきい値を選択します。

「オーバーレイ」オプション

「オーバーレイ」オプションを使用すると、別のポータル・アプリケーションのメトリックが表示されます。

「メトリック・パレットの表示」オプション

「メトリック・パレットの表示」オプションを使用すると、「メトリック・パレット」(図8-15)が表示され、表示するメトリックを選択できます。

図8-15 メトリック・パレット

8.2.2.3 「データベース・アクセス記述子の構成」ページ

Fusion Middleware Controlで、Oracle PortalインスタンスのDAD(データベース・アクセス記述子)を追加、編集または削除できます。Portalホーム・ページの「ポータル」メニューから「設定」→「データベース・アクセス記述子」をクリックすると、図8-16に示す「データベース・アクセス記述子の構成」ページが表示されます。

詳細は、第5.6.4項「Fusion Middleware Controlを使用したポータルDADの構成」を参照してください。

図8-16 Oracle Fusion Middleware Control - 「データベース・アクセス記述子の構成」ページ

「データベース・アクセス記述子の編集」ページから、DAD設定を編集または表示できます。「データベース・アクセス記述子の構成」ページからDADを選択して、「編集」をクリックすると、図8-17に示す「データベース・アクセス記述子の編集」ページが表示されます。DADの追加、削除および編集の詳細は、第5.6.4項「Fusion Middleware Controlを使用したポータルDADの構成」を参照してください。

注意:

「DADの編集」ページでいずれかの値を変更した場合は、Oracle HTTP ServerとWLS_PORTALを再起動する必要があります。

図8-17 Oracle Fusion Middleware Control - 「データベース・アクセス記述子の編集」ページ

「データベース・アクセス記述子の編集」ページで、表8-1「DAD設定」で詳しく説明するDAD設定値を変更できます。

表8-1 DAD設定

設定

説明

データベース・アクセス記述子の「名前または位置」

ポータルDADを指すパス(例、/pls/portal)を指定します。パスは、/plsで始まる必要があり、特殊文字や空白を使用してはいけません。また、64文字を超えてはいけません。

注意: ポータルDADの編集時は、このフィールドは読取り専用です。

ポータル・スキーマ名

ポータル・インスタンスのスキーマ名を入力します。

ポータル・スキーマ・パスワード

ポータル・インスタンスのスキーマのパスワードを入力します。

ヒント: スキーマのパスワードを取得するには、第5.6.10項「ポータル・スキーマ・パスワードの取得」を参照してください。

このフィールドを使用して、デフォルト以外のOracle Portalインスタンス用パスワードを設定します。

デフォルトのOracle Portalインスタンスに対しては、パスワードを設定することをお薦めします。詳細は、第6.11項「Oracle Portalスキーマのパスワードの変更」を参照してください。

データベース接続文字列

データベースがリモートの場合は、接続文字列を入力します。Portal DADを編集する場合、下の接続文字列フォーマット・プロパティを使用して、入力した接続文字列の書式を指定します。

接続文字列形式

「データベース接続文字列」プロパティに使用した書式を指定します。オプションは、次のとおりです。

- TnsNameFormat (TNS別名または完全なTNSエントリ)
接続文字列がtnsnames.oraによって解決されるとき、または完全なtnsnames.oraエントリがmod_plsql構成ファイルに指定されているときは、この書式を指定します。例:

myhostdb.oracle.com

または

DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=myhost.oracle.com)(Port=1521))(CONNECT_DATA=(SID=mydb)))"

- LdapServiceNameFormat
データベース接続の詳細がLDAPディレクトリで定義されているときは、この書式を指定します。LDAP接続の詳細は、$ORACLE_HOME/ldap/adminディレクトリにあるldap.oraファイルに含まれています。

- NetServiceNameFormat (SQL*Netエントリ)
接続文字列がSQL*Netによって解決されるときは、この書式を指定します。たとえば、LDAPを介した名前解決の場合はcn=oracle,cn=mydb、tnsnames.oraを介した名前解決の場合はmydb.oracle.comです。ネット・サービス名の詳細は、SQL*Netのドキュメントを参照してください。

Real Application Clustersのようなデータベース・インストールでは、LDAPで検索されるようにNetServiceNameFormatを使用した接続文字列を構成することをお薦めします。このようにすると、追加および削除されたデータベース・ノードを認識させるために各Oracle Fusion Middleware中間層を個別に再構成しなくても、ノードを追加または削除できます。

データベースNLS言語

このDADによって指定されるOracle PortalデータベースのNLS言語を入力します。この設定は、データベース・セッション用のNLS_LANG環境変数をオーバーライドし、レスポンス文字セットなど、レスポンス関連の一部の重要なNLSプロパティを定義します。

Oracle Portalの場合、この設定はバックエンド・データベースのNLS_LANGと一致する必要があります。たとえば、このパラメータをJAPANESE_JAPAN.JA16SJISに設定すると、コンテンツはデータベースからJA16SJIS文字セットで転送されます。

ヒント: このパラメータの設定を取得するには、nls_database_parameters表に次の問合せを実行します。

select value, parameter

from nls_database_parameters

where parameter in ('NLS_LANGUAGE', 'NLS_TERRITORY','NLS_CHARACTERSET');

mod_plsqlのパラメータPlsqlNLSLanguageの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

検証機能のリクエスト

アプリケーション定義のPL/SQLファンクションを指定します。このファンクションにより、リクエストされたプロシージャをさらに処理できます。これにより、PL/SQLアプリケーションに厳重なセキュリティを実装できます。たとえば、このDADからの実行を禁止されたパッケージまたはプロシージャ・コールをブロックできます。

PL/SQLファンクションに次の形式を使用します。

boolean function_name (procedure_name IN varchar2)

起動時には、引数procedure_nameに、リクエストで実行しようとしているプロシージャの名前が含まれます。たとえば、ブラウザからコールできるPL/SQLアプリケーション・プロシージャがすべてパッケージmypkg内にある場合は、次のファンクションを実装できます。

boolean my_validation_check

(procedure_name varchar2)

is

begin

if (upper(procedure_name) like upper

('myschema.mypkg%')) then

return TRUE;

else

return FALSE;

end if;

end;

このプロパティを指定するには、次の構文を使用します。

plsqlRequestValidationFunction <string>

例:

PlsqlRequestValidationFunction myschema.mypkg.my_validation_check

ヒント:

デフォルトでは、mod_plsqlは、特定のスキーマまたはパッケージへのダイレクトURLアクセスを禁止しています。詳細は、次に説明する「除外リスト」プロパティを参照してください。

このファンクションに対しては、使用しているアプリケーションに属するリクエストおよびブラウザからコール可能なリクエストのみが許可されるような実装にすることを強くお薦めします。

このファンクションは、すべてのリクエストについてコールされるため、可能なかぎりパフォーマンスを高くしてください。ここでは、いくつかの推奨事項を示します。

- 前述の例と同じようにこのファンクションが実装されるように、PL/SQLパッケージに名前を付けます。

- 実装で表検索を実行し、許可するパッケージまたはプロシージャを特定する場合、共有プールにカーソルを固定すると、パフォーマンスを改善できます。

除外リスト

ブラウザから直接実行することを禁止されているプロシージャ、パッケージまたはスキーマの名前を指定します。このリストはカンマ区切りで、リストの各文字列には大文字と小文字の区別がなく、ワイルドカードが使用可能です。このパラメータが指定されていない場合は、デフォルトのプロシージャが使用されます。デフォルトのリストには、sys.*、dbms_*、utl_*、owa_*、owa.*、htp.*、htf.*があります。

このパラメータがオーバーライドされても、デフォルトは有効です。そのため、除外されるパターンのリストにデフォルトのリストを明示的に追加する必要はありません。

PlsqlCGIExclusionListに指定したパターンに空白を使用する場合は、除外リストを二重引用符で囲みます。

このディレクティブを#NONE#に設定すると、すべての保護が無効になり、セキュリティ上のリスクが発生します。この設定は、稼働中のサイトに対しては行わないことをお薦めします。これはデバッグを行うためにのみ用意されています。

セッションCookie名

このパラメータが適用されるのは、分散環境の一部になっているOracle Portalインストールのみです。このパラメータはデフォルトで自動的にDAD名に設定されるため、ほとんどの場合、このフィールドは空白のままにします。

セッション・ステート管理の選択

ポータルのデフォルト(StatelessWithResetPackageState): 「セッション・ステート管理」プロパティに値が設定されていません。mod_plsqlによって割り当てられたデフォルト設定が使用されます。

CGI環境リスト

オーバーライドするCGI環境変数または新しいCGI環境変数、あるいはその両方を指定します。これは、名前と値のペアからなるカンマ区切りのリストです。次に示す既存の環境変数のオーバーライド、または新しい環境変数の追加ができます。次のパラメータに値が指定されていない場合、その値はOracle HTTP Serverから取得されます。

- AUTHORIZATION

- DAD_NAME

- DOC_ACCESS_PATH

- DOCUMENT_TABLE

- HTTP_ACCEPT

- HTTP_ACCEPT_ENCODING

- HTTP_ACCEPT_CHARSET

- HTTP_ACCEPT_LANGUAGE

- HTTP_COOKIE

- HTTP_HOST

- HTTP_PRAGMA

- HTTP_REFERER

- HTTP_USER_AGENT

- PATH_ALIAS

- PATH_INFO

- REMOTE_ADDR

- REMOTE_HOST

- REMOTE_USER

- REQUEST_CHARSET

- REQUEST_IANA_CHARSET

- REQUEST_METHOD

- REQUEST_PROTOCOL

- SCRIPT_NAME

- SCRIPT_PREFIX

- SERVER_NAME

- SERVER_PORT

- SERVER_PROTOCOL

エラー・スタイル

mod_plsqlとOracle HTTP Serverのいずれで生成されたページにエラー・メッセージを表示するかを指定します。このパラメータは、ファイルdads.confを手動で編集し、DADレベルまたはグローバル・レベルで指定します。

ApacheStyle(デフォルト) - 発生したHTTPエラーがmod_plsqlによってOracle HTTP Serverに示され、Oracle HTTP Serverではエラー・ページが生成されます。これをOracle HTTP ServerのError Documentディレクティブとともに使用すると、カスタマイズされたエラー・メッセージを生成できます。

modplsqlStyle - mod_plsqlによってエラー・ページが生成されます。エラー・ページには通常、発生したPL/SQLエラーを示す短いメッセージ(例、scott.foo PROCEDURE NOT FOUND)が表示されます。

DebugStyle - mod_plsqlによってエラー・ページが生成されます。このエラー・ページには、URL、パラメータ、サーバー構成情報などの追加情報が含まれます。

このモードはデバッグ専用です。内部サーバー変数を表示するとセキュリティ上のリスクが発生するため、本番システムではこのモードを使用しないでください。

注意: PL/SQLアプリケーションで独自のエラー・ページが生成される場合は、このオプションは無視されます。

ドキュメント表

Webブラウザを使用してアップロードされたファイルが格納されているデータベース表の名前を入力します。

<Schema>.wwdoc_documentというフォーマットを使用します。

ドキュメント・パス

URLインストールのパスを入力し、ドキュメントが参照されていることを示します。次のURLでは、docs(デフォルト値)がドキュメント・パスです。

http://myapp.myserver.com:2000/pls/my_site/docs/folder1/presentation

パスの別名

ダイレクト・アクセスURLのためにPL/SQLアプリケーションによって使用されます。デフォルトはurlです。キーワードurlの後はすべて、起動したプロシージャに送信されます。

パス別名プロシージャ

ダイレクト・アクセスURLのためにPL/SQLアプリケーションによって使用されます。

プロシージャを常に記述する

「オン」または「オフ」を指定します。mod_plsqlでは、渡されるパラメータのデータ型が認識されている必要があります。mod_plsqlでは、データ型に基づいて、各パラメータが配列またはスカラーとしてバインドされます。これは、次の2つの方法で行うことができます。

オフ - mod_plsqlのデフォルト。このオプションを選択すると、mod_plsqlでは次の経験則が使用されます。

- 渡される値が1つの場合、パラメータはスカラーです。それ以外の場合は配列です。

注意: 配列パラメータに1つの値を渡そうとしても、失敗してしまいます。次にDescribeコールが作成され、データベース・トリップが2つ必要になります(1つは実行に失敗したコールのため、もう1つはDescribeコールのため)。

オン - データ型を認識するための1つの方法として、プロシージャを実行前に記述します。この方法は、各プロシージャを実行前に記述する必要があるので、効率が悪くなる可能性があります。

プロシージャの前

ユーザー定義のプロシージャは、ターゲット・プロシージャの起動前にコールされます。このオプションは、ヘッダーの生成またはSQLトレースの有効化の起動に使用します。

プロシージャの後

ユーザー定義のプロシージャは、ターゲット・プロシージャの起動後にコールされます。このオプションは、フッターの生成またはSQLトレースの停止に使用します。

取出しバッファ・サイズ(行)

データベースへのラウンドトリップごとにmod_plsqlがフェッチするPL/SQLレスポンス・データの行数を指定します。デフォルトは200行です。

8.2.2.4 「ポータル・キャッシュ構成」ページ

Oracle Fusion Middleware Controlで、Oracle Portalが使用するOracle Web Cacheの設定を指定できます。Oracle Portalホーム・ページの「ポータル」メニューから「設定」→「ポータル・キャッシュ」を選択すると、図8-18に示す「ポータル・キャッシュ構成」ページが表示されます。

図8-18 Fusion Middleware Control - 「ポータルのWebキャッシュ設定」ページ

「ポータルのWebキャッシュ設定」ページで、表8-2で詳しく説明する設定値を変更できます。

表8-2 ポータル・キャッシュの設定

設定

説明

キャッシュ

ポータル・コンテンツおよびセッションのキャッシングを有効化(「オン」)または無効化(「オフ」)します。

キャッシュ・ディレクトリ

キャッシュ・コンテンツが格納されるディレクトリ・パス。

注意: このディレクトリが存在することと、アクセス可能(読込み/書込みアクセスが必要)であることを確認してください。

総キャッシュ・サイズ

ポータル・キャッシュに使用可能なディスク容量の総サイズ(MB単位)。許可される最大値は4GBです。

注意: この設定はハード制限ではありません。キャッシュが一時的にこの制限値を超える場合があります。

キャッシュ可能ファイルの最大サイズ

全キャッシュ・ファイルに対する最大サイズ(バイト単位)。許可される最大値は4GBです。

この制限を超える動的に生成されるコンテンツはキャッシュされません。

キャッシュ・スケジュール

キャッシュ記憶域の消去を開始する時間。消去を開始する日時を正確に定義するには、[Every Sunday - Every Saturday, Every Day, Every Month][hh:mm]の書式を使用します。

消去頻度は、毎日、毎週および毎月を単位として設定できます。デフォルトはEvery Day 23:00です。消去の頻度を少なくするとパフォーマンスは向上しますが、総キャッシュ・サイズの上限を超える可能性があります。頻度を多くするとパフォーマンスが低下しますが、総キャッシュ・サイズは超えません。

- 頻度を毎日に定義するには、Every Dayを選択します。消去は、毎日指定された時間に開始されます。例:
Every Day 2:00

キャッシュは、毎日午前2時(ローカル時間)に消去されます。

- 頻度を毎週に定義するには、曜日([Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday])を入力します。例:
Every Wednesday 15:30

キャッシュは、毎週水曜日の午後3時30分(ローカル時間)に消去されます。

- 頻度を毎月に定義するには、Every Monthを選択します。消去は、月の最初の土曜日の指定された時間に開始されます。例:
Every Month 23:00

キャッシュは、毎月の最初の土曜日の夜11時(ローカル時間)に消去されます。

キャッシュ・ファイルの最長保存期間(日)

キャッシュ・ファイルに適用する最長保存期間。この設定によって、古いコンテンツがキャッシュ・システムに含まれないことが保証されます。古いキャッシュ・ファイルは削除され、新しいキャッシュ・ファイル用の領域が確保されます。デフォルト値は30日間です。

注意: この設定は、ポータル・コンテンツのキャッシュ・アイテムにのみ適用されます。セッションCookieのキャッシュ・アイテムは、1日を超えると消去されます。

ポータル・キャッシュの構成方法の詳細は、第5.6.6項「Fusion Middleware Controlを使用したポータル・キャッシュの構成」を参照してください。

8.2.2.5 「ページ・エンジン構成」ページ

「ページ・エンジンの構成」ページを使用して、Oracle Portalで使用しているParallel Page Engine (PPE)のパフォーマンスを分析します。Oracle Portalホーム・ページの「ポータル」メニューから「設定」→「ページ・エンジン」を選択すると、図8-18に示す「ページ・エンジン構成」ページが表示されます。

図8-19 Oracle Fusion Middleware Control - 「ページ・エンジン構成」ページ

「ページ・エンジン構成」ページで、表8-3で詳しく説明する設定値を変更できます。

表8-3 ポータルのParallel Page Engineの設定

設定

説明

プロキシ・ホスト

Oracle Fusion Middlewareのデータをリクエストするときに必要なプロキシ・サーバーのホスト名です。これらのパラメータは、PPEとOracle Fusion Middlewareリスナーの間でプロキシ・サーバーを使用している場合にのみ必要です。

プロキシ・ポート

「プロキシ・ホスト」で指定されたプロキシ・サーバーのポート番号です。

プロキシ・ユーザー

「プロキシ・ホスト」で指定したプロキシ・サーバーのユーザーです。

プロキシ・パスワード

「プロキシ・ホスト」で指定したプロキシ・サーバーのパスワードです。

暗号化キーのキャッシュ

このキーを使用すると、Oracle Web Cacheを使用してキャッシュされるヘッダーが暗号化されます。これにより、キャッシュ・キーのセキュリティが向上し、不正なリクエストがキャッシュされたオブジェクトを取得する可能性が低くなります。

ポータル・リポジトリの11g リリース1 (11.1.1)以降を実行している場合、このキーは使用されません。このキーは、ポータル・リポジトリの以前のリリースで11.1.1中間層を使用している場合に下位互換性を確保する目的でのみ提供されています。

リソースURLキー

このキーは、WSRPリソースおよびJPDKリソースのプロキシ処理によってリクエストされたURLに対して、PPEがチェックサムを計算するために使用されます。

WSRPリソースのプロキシ処理を機能させるには、キーの値に10文字以上の英数字を設定する必要があります。

また、JPDKのプロキシ処理では、JNDI環境変数(resourceUrlKeyと呼ばれる)をプロバイダ用に設定する必要があります。

ポートの使用

PPEがポータルへリクエストを行うときに使用されるポートよりも優先されます。指定しない場合のデフォルトでは、ページ・リクエストのポートを常に使用します。

注意: Use SchemeおよびUse Portパラメータを設定する必要があります。

パブリック・アクセスがport A上でhttpsを経由し、port B上ではより高速なhttp接続を使用するためにPPEリクエストを設定する場合は、これらのパラメータを指定する必要があります。

スキームの使用

PPEがポータルへリクエストを行うときに使用されるスキーム(HTTPまたはHTTPS)よりも優先されます。指定しない場合のデフォルトでは、ページ・リクエストのスキームを常に使用します。

注意: Use SchemeおよびUse Portパラメータを設定する必要があります。

パブリック・アクセスがport A上でhttpsを経由し、port B上ではより高速なhttp接続を使用するためにPPEリクエストを設定する場合は、これらのパラメータを指定する必要があります。

509証明書ファイル

HTTPClientに暗黙的に信頼される証明書のリストが含まれたファイルを指定します。これらの証明書は、SSLを使用するHTTPClientによって行われたすべての接続に対するトラスト・ポイントとして追加されます。この設定がいったん使用されると、すべてのSSL接続が信頼されるようになります。そうでない場合、HTTPClientによってPPE内で例外がスローされます。

SSL接続は2つの理由でPPEから行われ、この構成が次の両方に影響を与えます。

- たとえば、PMDなどに対する、ポータルへのループバック・リクエスト。

- プロバイダへのコールの表示。

注意: ここで指定したファイルは、すべての信頼できる証明書をエクスポートすることによりウォレットから取得できますが、取得したファイル内のコメントは削除する必要があります。また、手動で信頼できる証明書ファイルを作成することもできます。

Parallel Page Engineの構成方法の詳細は、第5.6.9項「PortalのParallel Page Engineの構成」を参照してください。

8.2.2.6 「ポータル・ワイヤ構成」ページ

「ポータル・ワイヤ構成」ページを使用して、ポータル中間層を構成し、データベース・アクセス記述子向けにWeb CacheおよびOracle Internet Directory (OID)を構成します。Oracle Portalホーム・ページの「ポータル」メニューから「設定」→「ワイヤ構成」を選択すると、図8-18に示す「ポータル・ワイヤ構成」ページが表示されます。

このページは、次のセクションで構成されます。

- データベース記述子の選択

- ポータル中間層

- Webキャッシュ

- OID

データベース記述子の選択

このフィールドで、構成するデータベース・アクセス記述子を指定します。

ポータル中間層

要素

説明

ホスト

Portal URLの<hostname>を指定します。高可用性環境では、このホスト名としてロード・バランサのホスト名を指定します。スタンドアロン設定では、このホスト名としてWebキャッシュのホスト名を指定します。ブラウザでURLにhttps://www.myportal.com:4443を指定してポータルにアクセスする場合、「ホスト」にはwww.myportal.comを指定します。

ポート

Portal URLの<port>を指定します。これは、HA設定のロード・バランサのホスト名のリスニング・ポートです。スタンドアロン設定では、このポートとしてWebキャッシュのリスニング・ポートを指定します。ブラウザでURLにhttps://www.myportal.com:4443を指定してポータルにアクセスする場合、「ポート」には4443を指定します。

SSLプロトコル

ポータルURLのプロトコルを指定します。HTTP (非SSL)とHTTPS (SSL)のいずれかです。ブラウザでURLにhttps://www.myportal.com:4443を指定してポータルにアクセスする場合は、「SSLプロトコル」チェック・ボックスを選択します。

Webキャッシュ

要素

説明

ホスト

Webキャッシュとの送受信にポータルで使用するホスト名を指定します。デフォルトでは、これはポータル中間層のホスト・プロパティと一致し、ほとんどの構成でこのデフォルト値を使用します。

無効化ポート

無効化を実行する際にWebキャッシュとの送受信にポータルで使用するポート番号を指定します。非高可用性環境では、Oracle Web Cacheの無効化ポートと一致するようにこのプロパティを構成します。高可用性環境では、このプロパティは個々の無効化ポート間のロード・バランス・トラフィックとして機能するLBR上のポートにマップされます。

無効化ユーザー

個々の無効化ユーザー名を指定します。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

無効化パスワード

個々のパスワードを指定します。これは、Webキャッシュでコンテンツを無効にする際にポータルで使用する無効化パスワードです。このパスワードは、Webキャッシュのパスワードと一致している必要があります。一致していないとポータルを使用できません。

このページでOracle Web Cacheのプロパティを設定すると、Oracle Portalのスキーマが更新されます。

注意:

- 「ポータルのWebキャッシュ設定」ページでOracle Web Cacheのプロパティを変更すると、ポータルでキャッシュしたプロパティに影響します。Fusion Middleware Controlの「Webキャッシュ管理」ページに移動し、Webキャッシュを適切に変更します。Oracle Web Cacheの詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

- Oracle Web CacheとWebプロバイダが同じ中間層で稼動している場合、Oracle Web Cacheの設定を変更するとOmniPortletやWeb ClippingなどのWebプロバイダに影響することがあります。この場合は、Webプロバイダでもキャッシュの構成を適宜変更する必要があります。『Oracle Fusion Middleware Oracle Portal開発者ガイド』のOracle Web Cache無効化ポートの定義に関する項を参照してください。

OID

要素

説明

ホスト

OIDサーバーのホスト名を指定します。

ポート

OIDポート番号を指定します。

ユーザー

OIDユーザー名を指定します。

パスワード

OIDパスワードを指定します。

プロトコル

使用するプロトコルを指定します。HTTPSプロトコルを使用する場合は、このチェック・ボックスを選択します。

注意:

Oracle Portalのワイヤ構成を終了した後は、キャッシュ・コンテンツを更新する必要があります。

8.2.2.7 ログ

「ログ・メッセージ」ページ

「ログ・メッセージ」ページを使用すると、Oracle Portalインスタンスに関する詳細な診断情報が表示されます。Portalホーム・ページの「ポータル」メニューから「ログ」→「ログ・メッセージの表示」をクリックすると、図8-20に示す「ログ・メッセージ」ページが表示されます。詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

図8-20 Oracle Fusion Middleware Control - 「ログ・メッセージ」ページ

詳細は、付録G「Oracle Portalのトラブルシューティング」を参照してください。

「ログ構成」ページ

Fusion Middleware Controlで、Oracle Portalが使用するログ設定を指定できます。Oracle Portalホーム・ページの「ポータル」メニューから「ログ」→「ログ構成」を選択すると、図8-21に示す「ログ構成」ページが表示されます。

図8-21 「ログ構成」ページ

関連項目:

Oracle Fusion Middleware管理者ガイド

8.2.3 「トポロジ」タブ

「トポロジ」タブは、各Fusion Middlewareコンポーネントのホーム・ページの先頭に表示されます。「トポロジ」リンクをクリックすると、Oracle Fusion Middleware環境がグラフィック表示されます。これには、Oracle Portalインスタンスを実行する、Webキャッシュ、WLS_Portal、HTTP ServerなどのOracle Fusion Middlewareプロセスが表示されます。

関連項目:

Oracle Fusion Middleware管理者ガイド

8.3 Oracle Portal動作レポートの表示

オブジェクトおよび動作をOracle Portalでどのようにログ記録するかを指定し、データ分析用のレポートを生成することができます。たとえば、Oracle Portalユーザーが特定のページを作成、編集または削除するたびに、動作ログの表にエントリを追加することができます。

認可されたユーザーは誰でも、Oracle Portalのログ・レジストリ・レコードを表示することができます。ただし、ポータル管理者のみが、ログに記録される情報を設定することができます。詳細は、第8.3.2項「ログに記録されるイベントの選択」を参照してください。

注意:

Oracle Web CacheをOracle Portalアーキテクチャ内に導入することによって、Oracle Portalの動作ログの表内に記録される動作のいくつかが不正確になっています。このような動作には、表示、実行(レポート、チャートおよび階層)、および表示設定があります。ログに記録されたその他のすべての動作は正確なままに保たれているため、動作ログの表とビューはOracle Metadata Repository内にあります。

8.3.1 ログに記録されるイベント

表8-4に、ポータル・オブジェクトについてログに記録されるイベントをまとめます。

表8-4 Oracle Portalオブジェクトについてログに記録されるイベント

ポータル・オブジェクト

イベント

ページ

作成、編集、削除、パーソナライズ

アイテム

作成、編集、削除、移動、チェックアウト、チェックイン

アプリケーション・コンポーネント

作成、編集、削除、実行(レポート、チャート、階層を除く)、コピー、エクスポート、名前の変更、生成、アクセス制御、管理、挿入、更新、保存

ポートレット

ページへの追加、ページからの削除

ポートレット・インスタンス

非表示、パーソナライズ

検索

検索

注意:

作成、編集、削除などのユーザーおよびグループの操作はOracle Internet Directoryによってログに記録され、ログが有効であれば、Oracle Directory Managerから表示することができます。詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

8.3.2 ログに記録されるイベントの選択

Oracle Portalログ・レジストリ・レコードに記録されるイベントは、選択することができます。

1. 「サービス」ポートレットで、「ログ・レジストリ管理」をクリックします。

注意:

デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

「ログ・レジストリの管理」ページは、図8-22のように表示されます。

図8-22 「ログ・レジストリの管理」ページ

図8-22には、2つのログ・リクエストが表示されています。1つ目では、ポートレットがパーソナライズされるたびに、動作ログにエントリが作成されます。2つ目では、ページが作成されるたびにエントリが作成されます。すべてのリクエストをログに記録する場合は、各フィールドで「%」を選択します。

2. 次のうちの1つを実行してください。
「ログ・レジストリ・レコードの新規追加」をクリックして、新しいログ・レジストリ・レコードを作成し、ログ基準を指定します。

または

既存のログ・レジストリ・レコードのログ基準を編集します。これを行うには、次の手順を実行します:

1. 「編集」アイコンをクリックして、既存のログ・レジストリ・レコードのログ基準を変更します(「編集」アイコンは、「ログ・レジストリ・レコードの編集/削除」の下にあります)。
図8-23に示すような、「ログ・レジストリ・レコードの編集」ページが表示されます。

図8-23 「ログ・レジストリ・レコードの編集」ページ

2. 「サブ・ドメイン」リストから、ログに記録するオブジェクトを選択します。表8-4には有効なオブジェクトが示されています。

3. 「操作」リストから、ログに記録する操作(またはイベント)を選択します。表8-4には有効な操作が示されています。

4. 必要に応じて他のログ基準も指定します。

5. 「OK」をクリックします。

8.3.3 動作ログ・ビュー

wwlog_*という名前のいくつかの動作ログのビューが利用できます。これらのビューは、Oracle Portalがインストールされたスキーマ内にあります。これらのビューは公開できますが、各ログはオブジェクトのセキュリティに従って保護されています。たとえば、ページについての情報は、ユーザーがアクセス権限を持っているページについてのみ利用できます。

表8-5に、すべての動作ログのビューと説明を示します。必要な場合には、これらのビューに基づいた簡潔なOracle Portal DBプロバイダのレポートおよびチャートを作成することができます。

表8-5 動作ログ・ビュー

ログ・ビュー

説明

wwlog_portal_admin_logs

すべてのログ(ユーザーがポータル管理者の場合にのみレコードがあります)。

wwlog_user_logs

現在のユーザーによって作成されたすべてのログ

wwlog_all_portlet_logs

現在のユーザーが表示できるページ上のポートレット・インスタンス

wwlog_all_document_logs

現在のユーザーが表示できるドキュメント

wwlog_all_search_logs

現在のユーザーが表示できる検索

wwlog_all_item_logs

現在のユーザーが表示できるアイテム

wwlog_all_component_logs

現在のユーザーが表示できるコンポーネント

wwlog_all_object_logs

前述のすべてのビューを含むサマリー・ビュー

8.3.4 動作ログのビューの外部的なアクセス

SQL*PlusやOracle Reports Servicesなどを使用して、Oracle Portalブラウザベースのインタフェース以外から、動作ログのビュー内の情報にアクセスすることもできます。これを行うには、wwctx_api.set_context APIを使用して、次のようにデータベース・セッション用に最初にポータルのセキュリティ・コンテキストを設定する必要があります。

wwctx_api.set_context (
p_user_name => 'portal_username',
p_password  => 'portal_pw'
);

8.4 Oracle Fusion Middlewareポート情報の表示

Oracle Fusion Middleware Controlでは、特定のOracle Fusion Middlewareインスタンスのコンポーネントで現在使用しているすべてのポートが「ポートの使用状況」ページに表示されます。このページは、各種Oracle Fusion Middlewareコンポーネント間のポートの競合のトラブルシューティングを行うときに重要になります。

可能なときは常に、Oracle Fusion Middleware Controlに、適切なOracle Enterprise Manager 11g構成ページへのリンクが表示されます。ここで、コンポーネントのポート設定を変更できます。

Oracle Fusion Middlewareのポート使用情報にアクセスするには、次の手順を実行します。

1. ナビゲーション・ペインでファームを開いて「WebLogicドメイン」を開きます。

2. ドメインを選択します。

3. 「WebLogicドメイン」メニューから「ポートの使用状況」を選択します。
「ポートの使用状況」ページは、図8-24のように表示されます。

図8-24 Oracle Fusion Middlewareの「ポートの使用状況」ページ

ポート管理の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

8.5 Oracle Enterprise Managerの管理ロールの定義

11g リリース1 (11.1.1)では、Oracle Enterprise Managerは、管理者、オペレータおよびモニターという3つの管理ロールをサポートします。管理者ロールは、セキュリティ関連の操作を含むすべての操作を実行する完全な権限を持ちます。オペレータおよびモニターは、一部の権限に制限されます。ユーザーに権限がない機能は表示されないか、グレーで表示されます。次の表でその権限について説明します。

処理

管理者

オペレータ

モニター

起動および停止

はい

はい

いいえ

メトリックの表示

はい

はい

はい

ログ・メッセージの表示

はい

はい

はい

ログ構成

はい

いいえ

いいえ

キャッシュの構成の設定

はい

表示する権限のみ

表示する権限のみ

PPE構成

はい

表示する権限のみ

表示する権限のみ

ポータル・ワイヤ構成

はい

表示する権限のみ

表示する権限のみ

DAD構成表

はい

表示する権限のみ

表示する権限のみ

DAD構成: 処理の追加

はい

いいえ

いいえ

DAD構成: 処理の編集

はい

いいえ

いいえ

DAD構成: 処理の削除

はい

いいえ

いいえ

8.6 Oracle Fusion MiddlewareのシステムMBeanブラウザについて

Oracle Fusion MiddlewareのシステムMBeanブラウザは、Oracle Fusion Middleware Controlの一部であり、中間層コンポーネントの構成設定の更新に使用します。マネージドBean (MBean)は、アプリケーション、サービス、コンポーネント、デバイスなど、分散環境内のJMX管理可能リソースを表すJavaオブジェクトです。MBeanは、Java EE Management Specification (JSR-77)で定義されています。これは、Java Management Extension (JMX)の一部であり、Java EE環境内でアプリケーションを管理するための標準インタフェースを作成できる仕様のセットです。

この項には次のトピックが含まれます:

- Oracle Fusion MiddlewareのシステムMBeanブラウザはいつ使用すればよいか

- Portal構成MBeanについて

8.6.1 Oracle Fusion MiddlewareのシステムMBeanブラウザはいつ使用すればよいか

システムMBeanブラウザは、Oracle Portalの構成設定を入力または変更する場合に使用します。この入力または変更は、Fusion Middleware Controlの「Oracle Portal」ページではできません。

注意:

中間層の上級管理者以外は、システムMBeanブラウザを使用しないでください。

8.6.2 Portal構成MBeanについて

構成MBeanは、Oracle Portal構成ファイルごとに定義します。表8-6に、Oracle Portalの構成MBeanをまとめます。

表8-6 Portalの構成MBean

構成MBean

関連する構成ファイル

Portal DAD MBean (Config)

portal_dads.conf

Portal Cache MBean (Config)

portal_cache.conf

Portal plsql MBean (Config)

portal_plsql.conf

Portal Midtier MBean (Config)

appConfig.xml

Portal Wiring MBean (Runtime)

関連する構成ファイルはありません。

注意:

レジストリで設定されるPortal環境変数は、すべてがMBeanを使用して公開されるわけではありません。ただし、サーバー構成ファイルENVIDで指定されている環境変数は、PortalServerConfigMXBeanによって公開されます。

9 Oracle Portal用のイントラネットおよびインターネットの構成

このドキュメントでは、Oracle Portalの専用イントラネットおよび専用インターネットを構成し、イントラネットおよびインターネット設定をOracle Portal 10gからOracle Portal 11gにアップグレードする方法を説明します。このドキュメントは次のトピックで構成されています。

Oracle Portalの専用イントラネットおよび専用インターネットの構成

Oracle Portal 10gのイントラネットおよびインターネット設定の11gへのアップグレード

9.1 Oracle Portalの専用イントラネットおよび専用インターネットの構成

Oracle Portalは、企業ネットワーク内のクライアントと外部クライアントの両方からアクセスできるように構成できます。この項では、この構成のいくつかの重要な特徴と、このような目的でOracle Portalを構成する方法を説明します。

Oracle Portalのイントラネットとインターネットの構成には、それぞれ別のホスト上に存在する2つの論理中間層、portal.mycompany.comとinternal.mycompany.comが必要です。中間層が物理的に分離されることにより、インターネット・ユーザー用とイントラネット・ユーザー用にキャッシュされるコンテンツが分離されます。これによりセキュリティが強化され、一方の論理中間層に移動したユーザーがもう一方の論理中間層で処理されたコンテンツにアクセスすることがなくなります。各論理中間層からは、Oracle Application Server Metadata Repository内の同じOracle Portalスキーマおよび同じOracle Portalデータにアクセスできます。この構成では、外部の論理中間層がWebプロバイダのインストール、構成および公開に使用される1次中間層になります。内部の論理中間層はパートナ・アプリケーション用です。

イントラネットとインターネットを構成するには、すべてのOracle Web Cacheインスタンスが無効化専用クラスタとして構成されている必要があります。無効化専用のクラスタ化により、Oracle Web Cacheでは、2つの論理サイトで個別のキャッシュを維持しながら、クラスタ・メンバー間で無効化メッセージを共有できます(その結果、2つの論理サイト間でコンテンツの編集が認識されます)。

この構成では、無効化メッセージはOracleAS Metadata Repository内のOracle Portalスキーマから内部のOracle Web Cacheインスタンスに送信され、その後すべてのクラスタ・メンバーに送信されます。この構成で使用される無効化メッセージでは、キャッシュされたURLで指定されているホストやポートに関係なく必ずコンテンツが無効化されます。このような無効化により、いずれの論理中間層のURLでキャッシュされたコンテンツも確実に無効化されます。Oracle Web Cacheの無効化専用クラスタの詳細は、『Oracle Application Server Portal構成ガイド』を参照してください。

内部ユーザーと外部ユーザーのコミュニティが個別のものになるように、Oracle Portalアプリケーションへのアクセスには2つのURLが使用されます。イントラネットからの場合はhttp://internal.mycompany.com、インターネットからの場合はhttps://portal.mycompany.comです。

Oracle Portalの専用イントラネットと専用エクストラネットを構成するプロセスは次のタスクで構成されます。

1. 外部中間層のインストールと構成

2. APPHOST3への最初の内部中間層のインストール

3. Oracle Web Cacheの無効化専用クラスタの構成

4. APPHOST3の最初の内部中間層のロード・バランシング・ルーター用の構成

5. パートナ・アプリケーションとしての内部中間層の登録

6. WebLogicにおけるホスト・アサーションの変更

7. APPHOST4への2番目の内部中間層のインストール

8. Oracle Web Cacheの無効化専用クラスタの構成

9. APPHOST4の2番目の内部中間層のロード・バランシング・ルーター用の構成

10. Web Cacheの構成

11. Oracle Metadata RepositoryのOracle Portalスキーマの構成

12. 構成完了後の検証

9.1.1 外部中間層のインストールと構成

外部中間層をインストールして構成するには、Oracle Portalエンタープライズ・デプロイメント・ガイド:11.1.1.2の次の項にある手順を実行します。

- APPHOST1へのアプリケーション層のインストール

- APPHOST1の構成

9.1.2 APPHOST3への最初の内部中間層のインストール

最初の内部中間層をインストールするには、次の手順を実行します。

1. Disk1/stage/Responseディレクトリのstaticport.iniファイルを、TMPなどのローカル・ディレクトリにコピーします。

2. staticport.iniファイルを編集し、次のカスタム・ポートを割り当てます。

Oracle HTTP Server port = 7777
Oracle HTTP Server Listen port = 7778
Web Cache HTTP Listen port = 7777
Web Cache Administration port = 9400
Web Cache Invalidation port = 9401
Web Cache Statistics port = 9402
Application Server Control port = 1810

3. APPHOST3に最初の中間層をインストールする前に、ポータル・スキーマのリポジトリ・バージョンを11.1.1.4から11.1.1.1.0に変更する必要があります。そのためには、次の手順を実行します。

1. 次の例に示すように、portal schemaとしてデータベースに接続し、ポータル・バージョンを問い合せます。

>sqlplus portal/portaldb_portal@portaldb
sql> select version from wwc_version$;
sql> 11.1.1.4.0

このポータル・リポジトリ・バージョンを忘れないように書き留めておきます。

2. 次の例に示すように、ポータル・リポジトリ・バージョンを11.1.1.1.0に変更します。

sql> update wwc_version$ set version = '11.1.1.1.0';
sql> commit;
sql> select * from wwc_version$;
sql> 11.1.1.1.0

この手順は必須です。この手順を実行せずにAPPHOST3に新しく中間層をインストールすると、ポータル・スキーマに保持されている構成が新しくインストールした中間層の情報で上書きされます。これは外部ポータル中間層に影響を及ぼします。ポータル・スキーマ・バージョンを一時的にダウングレードすることで、ポータル・スキーマに保持されている構成をそのまま残すことができます。後でポータル・バージョンを元のバージョンに戻す必要があります。ポータル・リポジトリのダウングレードは、新しいドメインを作成する場合にのみ必要になります。

Weblogic Serverのインストール

1. Oracle Universal Installerを起動します。
Unixでインストーラを起動するには、server103_linux32.binコマンドを発行します。

Windowsでインストーラを起動するには、server103_win32.exeコマンドを発行します。

「ようこそ」画面が表示されたら、「次へ」をクリックします。

2. ミドルウェア・ホーム・ディレクトリを選択します。
次の例に示すように、「ミドルウェア・ホーム」に値を入力します。

/u01/app/oracle/product/FMW

以降、これをMW_HOMEと呼びます。「次へ」をクリックします。

3. 次の画面で、セキュリティ更新に登録するよう求められます。
Oracle Supportからのセキュリティ更新を受け取るかどうかを選択します。「次へ」をクリックします。

4. インストール・タイプの選択画面で「標準」インストール・タイプを選択します。
「次へ」をクリックします。

5. 製品インストール・ディレクトリの選択画面で、製品のインストール先となるパスを指定します。「次へ」をクリックします。

6. これで、指定した場所にWeblogic Serverがインストールされるようになりました。「インストール・サマリー」画面が表示されます。「完了」をクリックして、インストールを完了します。

Oracle Portalのインストール

1. 次のコマンドを実行して、前述の手順で作成したMW_HOMEにOracle Portalのバイナリをインストールします。
UNIXの場合: runInstaller

Windowsの場合: setup.exe

2. 「ようこそ」画面が表示されます。「次へ」をクリックします。

3. 「インストール・タイプ」画面が表示されます。ソフトウェアのインストールと構成を選択し、「次へ」をクリックします。
前提条件チェック画面が表示されます。

4. すべてのチェックで問題がないことを確認し、「次へ」をクリックします。
「インストール場所の指定」画面が表示されます。

5. 次の値を入力します。

- ミドルウェア・ホーム(MW_HOME)
例: /u01/1pp/oracle/product/FMW

- Oracleホーム
ポータルのインストール・ディレクトリを入力します。これはMW_HOMEディレクトリ内に配置されます。

例: Portal

- Weblogicサーバー・ディレクトリ
Oracle Weblogic Serverのインストール・ディレクトリを入力します。これは、MW_HOME/wlserver_10.3にする必要があります。

例: /u01/app/oracle/product/FMW/wlserver_10.3

- Oracleインスタンスの場所
Oracle Configurationのファイルを配置するディレクトリを入力します。これは、Oracleホームの外部にする必要があります。以降、これをORACLE_INSTANCEと呼びます。

例: /u01/app/oracle/admin/PortalDomain/Portal1

- Oracleインスタンス名。
この場合はPortal1です。

「次へ」をクリックします。「ドメインの選択」画面が表示されます。

6. 新規ドメインの作成を選択します。「ユーザー名」、「ユーザー・パスワード」および「ドメイン名」に値を入力します。
「次へ」をクリックします。「コンポーネントの構成」画面が表示されます。

7. 次の値にチェックが付いていることを確認します。

- サーバー・コンポーネント: Oracle Portal

- 管理コンポーネント: Enterprise Manager

- クラスタ化されているボックス
「次へ」をクリックします。「ポートの構成」画面が表示されます。

8. 構成ファイルを使用してポートを指定を選択します。
ファイル名を選択して、「表示」または「編集」をクリックします。サンプルのstatisticports.iniファイルは、インストールのDisk1のstage/repsonseディレクトリにあります。

ファイルを保存し、「次へ」をクリックします。

9. スキーマの指定画面で、次の値を指定します。

- データベース接続文字列
例:

db_hostname:port:servicename

- Portalスキーマ名: MYP_PORTAL

- ポータル・スキーマ・パスワード
RCUで入力したパスワードを入力します。

「次へ」をクリックします。ポートレット・スキーマの指定画面が表示されます。

10. 次のポートレット・スキーマの資格証明を指定します。

- ポートレット・スキーマ名: MYP_PORTLET

- ポートレット・スキーマ・パスワード: RCUで入力したパスワードを入力します。

「次へ」をクリックします。アプリケーション・アイデンティティ・ストアの指定画面が表示されます。

11. 次の値を指定します。

- ホスト名
OIDサーバーの名前を入力します。

- ポート
OIDポート「389」を入力します

- ユーザー名
「cn=orcladmin」と入力します。

- パスワード
orcladminのOIDパスワードを入力します。

「次へ」をクリックします。「サマリー」画面が表示されます。

12. 「インストール」をクリックしてインストール処理を開始します。

注意:

UNIXインストールでは、プロンプトが表示されたらoracleRoot.shスクリプトを実行します。

9.1.3 Oracle Web Cacheの無効化専用クラスタの構成

内部と外部の両方のコンピュータのOracle Web Cacheインスタンスを含む、Oracle Web Cacheの無効化専用クラスタを構成する必要があります。このクラスタ構成では、無効化リクエストがすべてのキャッシュ・クラスタ・メンバーに伝播されます。ただし、Oracle Web Cacheの無効化専用クラスタでは、その他のリクエストはクラスタ・メンバー間で転送されません。ユーザー・リクエストの処理中に、各クラスタ・メンバーは個々のキャッシュとして機能し、ピア・クラスタ・メンバーにはオブジェクトをリクエストしません。

この構成を使用すると、特にそのメンバーがファイアウォールで分離されているクラスタでは、多数のキャッシュの管理を簡略化できます。たとえば、イントラネットをインターネットから分離するファイアウォールの両側に2つのキャッシュが存在するクラスタを持つことができます。

9.1.3.1 Oracle Web Cacheの無効化専用クラスタのネットワーク環境の準備

外部と内部のOracle Web Cacheインスタンス間でOracle Web Cacheの無効化専用クラスタを構成する前に、次のチェックを実行します。

1. すべての外部Oracle Web Cacheインスタンスからすべての内部Oracle Web Cacheインスタンスを解決し、接続できること、またその逆が可能であることを確認します。これは、pingネットワーク・コマンドを使用して確認できます。

2. ファイアウォールで無効化ポート(9401)が一方向のみで開いていることを確認します。内部のOracle Web Cacheインスタンスから外部のOracle Web Cacheインスタンスに対して開いている必要があります。

3. ファイアウォールで管理ポート(9400)が双方向で開いていることを確認します。

注意:

構成が完了したら、外部中間層から内部中間層へのトラフィックに対して管理ポート(9400)を閉じてください。

4. 内部のOracle Web Cacheのポートから外部のOracle Web Cacheのポートに、telnetを使用してネットワーク・パケットを送信できることを確認します。

9.1.3.2 キャッシュの構成

この項では、APPHOST1のOracle Web Cache Managerを使用してキャッシュ・クラスタの設定を構成し、キャッシュをクラスタとして管理して、キャッシュのコンテンツを分離する方法を説明します。

1. ナビゲータ・フレームで「Properties」→「Clustering」を選択します。
「Clustering」ページが表示されます。「General Cluster Information」セクションにフェイルオーバーと無効化の伝幡に関するクラスタ全体のデフォルト値が表示されます。「Cluster Members」表に外部中間層キャッシュが表示されます。

2. 「Clustering」ページの「General Cluster Information」セクションで「Edit」をクリックします。
「Edit General Cluster Information」ダイアログ・ボックスが表示されます。

3. 「Propagate Invalidation」フィールドで「Yes」を選択して、キャッシュ・クラスタ・メンバーからの無効化リクエストが他のキャッシュ・クラスタ・メンバーに伝播されるように指定します。

4. 「Submit」をクリックします。

5. 「Clustering」ページの「Cluster Members」表に、現在のキャッシュのデフォルト値が表示されます。APPHOST1クラスタ・メンバーを選択し、「Edit Selected」をクリックします。
「Edit Cluster Member」ダイアログ・ボックスが表示されます。

6. 「Capacity」フィールドに0と入力します。

注意:

すべてのクラスタ・メンバーの容量に0を割り当てると、クラスタ・メンバー間でリクエストの転送は行われません。この設定では、すべてのキャッシュ・クラスタ・メンバー間で構成と無効化を伝播して、多数のキャッシュの管理を簡略化できます。

7. 「Submit」をクリックします。

クラスタにAPPHOST3を追加する前に、次の条件を満たしている必要があります。

- キャッシュが起動されている。

- 追加するキャッシュの管理者パスワードは、APPHOST1の管理者パスワードと同じである必要があります。パスワードが異なる場合は、キャッシュの管理サーバーに接続して管理パスワードを変更する必要があります。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の第8章「設定と構成」の「作業2: セキュリティ設定の変更」を参照してください。

9.1.3.2.1 無効化専用クラスタへのキャッシュの追加

次に、APPHOST1のOracle Web Cache Managerを使用して、APPHOST3のキャッシュをクラスタに追加する必要があります。

OracleAS Web Cache Managerでクラスタにキャッシュを追加するには、次の手順を実行します。

1. ナビゲータ・フレームで「Properties」→「Clustering」を選択します。
「Clustering」ページが表示されます。

2. 「Clustering」ページの「Cluster Members」セクションで、「Add」をクリックします。
「Add Cache to Cluster」ダイアログ・ボックスが表示されます。

3. 「Host Name」フィールドに、クラスタに追加するキャッシュのホスト名としてapphost3.abc.oracle.comと入力します。

4. 「Admin Port」フィールドに、クラスタに追加するキャッシュのWebキャッシュ管理ポート(9400)を入力します。

5. HTTPブラウザ・リクエストを受け入れる場合は、「Protocol for Admin Port」フィールドで「HTTP」を選択します。

6. 「Cache Name」フィールドに、apphost3.abc.oracle.com-webcacheと入力します。

7. 「Submit」をクリックします。
これでキャッシュはクラスタの一部となり、「Cluster Members」表に表示されます。

8. 「Host Name」フィールドと「Cache Name」フィールドをapphost4に置き換え、手順2から7を繰り返します。

9. 「変更の適用」をクリックします。
新しいキャッシュ・クラスタ・メンバーのキャッシュ固有の情報がクラスタ構成に追加されます。

10. 各クラスタ・メンバーの「Capacity」を0に設定します。そのためには、「Properties」→「Clustering」を選択します。クラスタ・メンバーを選択して「Edit」をクリックします。「Edit Cluster Member」ダイアログ・ボックスで、「Capacity」を0に設定します。

11. すべてのクラスタ・メンバーに構成を伝播します。
クラスタを変更してそれを適用すると、OracleAS Web Cacheにより、新しいキャッシュ・クラスタ・メンバーのキャッシュ固有の情報が構成に追加されます。すべてのクラスタ・メンバーに変更を適用するには、構成を伝播してクラスタ・メンバーのキャッシュ・サーバー・プロセスを再起動する必要があります。

Oracle Web Cache Managerで新しいクラスタ・メンバーに構成を伝播するには、次の手順を実行します。

1. ナビゲータ・フレームで、「Operations」→「Cache Operations」を選択します。
「Cache Operations」ページが表示されます。「Operation Needed」列に、構成を伝幡するキャッシュが示されます。

2. すべてのキャッシュ・クラスタ・メンバーに構成を伝播します。

- 「Operate On」フィールドで「All caches」を選択します。

- 「Interval」で「Immediate」を選択します(伝幡にはその他の間隔は使用できません。)

- 「Propagate」をクリックします。

操作が完了すると、「Cache Operations」ページの「Operation Needed」列に再起動が必要なクラスタ・メンバーが示されます。

3. すべてのクラスタ・メンバーを停止して再起動します。

- 「Operate On」フィールドで「All caches」を選択します。

- キャッシュに対する操作を時間差をつけて開始するために「Interval」を選択し、「Restart」をクリックします。
操作が完了すると、「Cache Operations」ページの「Operation Needed」列に必要な操作がないことが示されます。これでキャッシュ・クラスタを使用する準備ができました。

12. ネットワーク外からのトラフィックに対して管理ポートと無効化ポートが閉じていることを確認してください。

9.1.3.3 ファイアウォールを経由した外部から内部への通信の無効化

ファイアウォールを経由した外部から内部への通信を無効にするには、次の手順を実行します。

1. 外部中間層から内部中間層への管理ポートを無効にします。

2. telnetを使用して、外部のOracle Web Cacheから内部のOracle Web Cacheの管理ポートおよび無効化ポートにネットワーク・パケットを送信できないことを確認します。

3. 管理ポートと無効化ポートの両方で、内部のOracle Web Cacheから外部のOracle Web Cacheにネットワーク・パケットを送信できることを確認します。
通信パスおよびポートは、表9-1のようになります。

表9-1 ネットワーク・パケットによって使用される通信パスおよびポート

通信パス

有効にするポート

内部WebCache 1から外部WebCache 1

ポート9400およびポート9401

内部WebCache 1から外部WebCache 2

ポート9400およびポート9401

注意:

ネットワーク・セキュリティ上の理由から、クラスタ構成の追加は内部中間層のいずれかにあるWeb Cacheインスタンスから実行してください。クラスタ管理にはクラスタ内の任意のWeb Cacheインスタンスを使用できますが、外部のOracle Web Cacheインスタンスを使用する場合は、ファイアウォールに一時的に管理ポートを開いて、外部から内部へのトラフィックを許可する必要があります。

9.1.4 APPHOST3の最初の内部中間層のロード・バランシング・ルーター用の構成

ロード・バランシング・ルーターがポート7777でリクエストを受け入れ、APPHOST3上のOracleAS Web Cacheのポート7777に転送するように構成する必要があります。

また、基盤となるコンポーネントがロード・バランシング・ルーターのホスト名(xmlns.oracle.com)とポート番号7777に基づいてURLを作成し、Oracle Portalページに表示される自己参照URLがブラウザで有効なものになるように、APPHOST3のOracle Portal中間層を構成する必要があります。そのためには、仮想ホストを構成する必要があります。仮想ホストを構成するには、次の手順を実行します。

1. ロード・バランシング・ルーターがポート80でリクエストを受け入れ、APPHOST3で稼動するOracle Web Cacheのポート(7777)に転送するように構成します。これを行うには、次の手順を実行します。

1. ロード・バランシング・ルーター上にグループ(プール)を設定します。このグループには個々のサーバーを追加できます。詳細な手順は、ロード・バランシング・ルーターのドキュメントを参照してください。

2. 必要なサーバーのIPアドレスとポート番号をグループに追加します。

3. ポート80でリスニングを行い、グループのメンバー間でリクエストを配分する仮想サーバーを作成します。詳細な手順は、ロード・バランシング・ルーターのドキュメントを参照してください。

4. ロード・バランシング・ルーターが、自身がリスニングしているポートを変換し、Oracle Web Cacheがリスニングしているポートにリクエストを転送することを確認します。

2. 基盤となるコンポーネントがロード・バランシング・ルーターのホスト名(internal.mycompany.com)とポート番号(80)に基づいてURLを作成し、Oracle Portalページに表示される自己参照URLがブラウザで有効なものになるように、APPHOST3のOracle Portal中間層を構成します。そのためには、次のように仮想ホストを定義します。

1. http://apphost3.abc.oracle.com:7001/emにあるOracle Enterprise Manager 11gコンソールにアクセスします。

2. 左側のナビゲーション・パネルで「Web層」を開きます。

3. 「ohs1」を選択します。Oracle HTTP Serverのホームページが表示されます。

4. メニューから「管理」を選択し、「拡張構成」に移動します。

5. 「選択」ファイル・メニューから「httpd.conf」を選択します。「実行」をクリックしてファイルを編集します。

6. httpd.confファイルを編集します。次の例に示すように、VirtualHostコンテナを追加します。

NameVirtualHost *:7778

<VirtualHost *:7778>
ServerName internal.mycompany.com
Port 80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

7. 「適用」をクリックします。

8. Oracle HTTP Serverを再起動するように求められたら、「いいえ」をクリックします。

3. 2番目の仮想ホストを定義します。この場合、次の項目を除いて、最初の仮想ホストの定義と同じ手順を使用します。

- 「サーバー名」にapphost3.mycompany.comを指定します。

- VirtualHostコンテナのPortディレクティブに7777を指定します。

- Oracle HTTP Serverを再起動するように求められたら、「はい」をクリックします。

4. APPHOST3のOracle Web Cache Managerを使用して、前の手順で作成した仮想ホストのエントリに一致するサイトを定義します。

1. 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、APPHOST3のOracle Web Cache Managerにアクセスします。

2. 「Properties」で「Sites」をクリックします。

3. 「Named Sites Definitions」で「Create」をクリックします。

4. 「Create Named Site」ページで、「Host」にinternal.mycompany.com、「Port」に80を指定します。他のフィールドはすべてデフォルト値のままとします。

5. 「OK」をクリックします。「Named Sites Definitions」表にinternal.mycompany.comが表示されるようになります。

5. 外部中間層のOracle Web Cache Managerを使用して、APPHOST3をオリジン・サーバーとしてOracle Web Cacheクラスタに追加します。APPHOST3を追加するには、次の手順を実行します。

1. 「Origin Servers, Sites, and Load Balancing」で「Origin Server」をクリックします。

2. 「Origin Server」ページで、「Application Web Servers」表の「Add」をクリックします。

3. 「Add Application Web Server」ページで次の情報を入力します。

プロパティ

値

ホスト名

apphost3.abc.oracle.com

ポート

7778 (APPHOST3のOracle HTTP Serverリスニング・ポート)

Routing

ENABLED

容量

100

フェイルオーバーのしきい値

5

URLのping

/

Ping Interval

10

プロトコル

HTTP

4. 「発行」をクリックします。

5. オリジン・サーバーが正しく追加されていることを確認するために、「Origin Server」表でapphost3.mycompany.comを探します。

注意:

詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のサイトからオリジン・サーバーへのマッピングに関する項を参照してください。

6. 外部中間層のOracle Web Cache Managerを使用して、サイトinternal.mycompany.comを中間層apphost3.mycompany.comにマップします。

1. ナビゲーション・フレームで、「Origin Servers, Sites, and Load Balancing」の「Site-to-Server Mapping」を選択します。

2. 「Site-to-Server Mapping」ページで、表の中の最初のマッピングを選択して「Insert Above」をクリックします。

3. 「Edit/Add Site-to-Server Mapping」ページで、「Select from Site definitions」オプションを選択し、internal.mycompany.comを選択します。

4. 「Select Application Web Servers」セクションで、「Origin Servers」ページで指定したAPPHOST3上のアプリケーション・サーバー(apphost3.mycompany.com)を選択します。

5. 「発行」をクリックします。

6. ページの上部にある「Apply Changes」をクリックします。

7. 「Cache Operations」ページで「Restart」をクリックし、APPHOST3のOracle Web Cacheを再起動します。

サイトが正しくマッピングされていることを確認するには、「Site-to-Server Mapping」ページに移動し、APPHOST3がサイトinternal.mycompany.comにマップされていることを確認します。

7. apphost3.mycompany.comコンピュータがロード・バランシング・ルーターのホスト名を解決して正しいIPアドレスを取得できるように構成します。DNS解決を使用するか、/etc/hostsファイルに次のエントリを作成します。
xxx.xxx.240 internal.mycompany.com

注意:

/etc/hostsファイルにはローカル・ホスト名が127.0.0.1を指し示すエントリがないことを確認してください。例:

127.0.0.1 apphost3.mycompany.com

9.1.5 パートナ・アプリケーションとしての内部中間層の登録

シングル・サインオン・コンポーネントが正しく動作するためには、常にURLのホスト名と同じ名前でパートナ・アプリケーションから参照される必要があります。これは、Cookieが生成元のホストにのみ返されるためです。

内部中間層をパートナ・アプリケーションとして登録する必要があります。そのためには、内部中間層(APPHOST3)から次の手順を実行する必要があります。

1. ORACLE_HOME変数をSSOのORACLE_HOMEの場所に設定します。

2. 例9-1のようにパラメータを指定して、SSO登録スクリプトORACLE_HOME/sso/bin/ssoreg.shを実行します。

例9-1 UNIXでのssoregの使用方法

-site_name_internal.mycompany.com
-mod_osso_URL https://internal.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

Windowsの場合は、ssoreg.batスクリプトを実行します。

3. MW_HOME/asinst_1/config/OHS/ohs1にあるポータル中間層ホームに/tmp/osso.confをコピーします。

4. 次のコマンドを発行してOracle HTTP Serverを再起動します。
ORACLE_HOME/opm/bin/opmnctl restartproc process-type=OHS

5. 次のURLを使用してシングル・サインオン・サーバーにログインします。
http://login.mycompany.com/pls/orasso

6. 管理ページに移動してから、「パートナ・アプリケーションの管理」ページに移動します。apphost3.mycompany.comのエントリを削除します。

7. Web層を再起動して変更を有効にします。Oracle Web Tierコンポーネントを再起動するには次のコマンドを使用します。
opmnctl stopall

opmnctl startall

注意:

前述のコマンドを発行する前に、環境変数ORACLE_INSTANCEがインストール時に入力した値に設定されていることを確認してください。

9.1.6 WebLogicにおけるホスト・アサーションの変更

Oracle HTTP ServerはWebLogicのプロキシとして機能するため、デフォルトでは特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。これを実現するには、次の手順を実行します。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。
http://apphost1.abc.oracle.com:7001/console

2. 「環境」を選択して「クラスタ」に移動します。

3. 「チェンジ・センター」ウィンドウで「ロックして編集」をクリックし、編集可能にします。

4. 「cluster_portal」を選択します。「HTTP」に移動して次の値を入力します。

パラメータ

値

フロントエンド・ホスト

internal.mycompany.com

フロントエンドHTTPポート

80

フロントエンドHTTPSポート

任意

5. 「チェンジ・センター」ウィンドウの「変更のアクティブ化」をクリックします。

6. WLS_PORTAL管理対象サーバーを再起動します。WLS_PORTALを再起動するには、次の手順を実行します。

1. http://apphost1.abc.oracle.com:7001/consoleにログインします。

2. 「サーバー」に移動して「制御」タブを選択します。

3. 「WLS_PORTAL」チェック・ボックスを選択し、「停止」をクリックします。

4. WLS_PORTALを再起動するには、「WLS_PORTAL」チェック・ボックスを選択し、「起動」をクリックします。
WLS_PORTALが起動します。

9.1.6.1 構成の検証

APPHOST3の最初の内部中間層を構成したら、ポータル・バージョン番号を元のバージョン番号に戻す必要があります。これを行うには、次の手順を実行します:

1. 次の例に示すように、portal schemaとしてデータベースに接続し、ポータル・バージョンを問い合せます。

>sqlplus portal/portaldb_portal@portaldb
sql> select version from wwc_version$;
sql> 11.1.1.1.0

2. 次の例に示すように、ポータル・リポジトリ・バージョンを11.1.1.4.0に変更します。

sql> update wwc_version$ set version = '11.1.1.4.0';
sql> commit;
sql> select * from wwc_version$;
sql> 11.1.1.4.0

構成を検証するには、次のテストを実行します。

テスト

URL

結果

ロード・バランサのテスト

http://myPortal.mycompany.com/

ホーム・ページが表示されます

SSL経由したロード・バランサのテスト

https://myPortal.mycompany.com/

ホーム・ページが表示されます

ロード・バランサの終了のテスト

http://myPortal.mycompany.com/portal/pls/portal/owa_util.print_cgi_env

HTTPSのREQUEST_PROTOCOL値

9.1.7 APPHOST4への2番目の内部中間層のインストール

2番目の内部中間層をAPPHOST4にインストールする前に、APPHOST3で内部中間層が実行されていることを確認してください。2番目の内部中間層をAPPHOST4にインストールするには、次のタスクを実行します。

- 次の点を除き、第9.1.2項「APPHOST3への最初の内部中間層のインストール」の手順に従って2番目の内部中間層をインストールします。

- 必要に応じて、APPHOST3をAPPHOST4に置き換えます。

- ポータル・バージョン番号の変更は最初の内部中間層をAPPHOST3にインストールする場合にのみ必要になります。以降、APPHOST4や他の中間層を設定する場合、ポータル・バージョン番号は変更しないでください。

- 「Oracle Portalをインストール」セクションで、手順6を次の手順に置き換えます。

- 「クラスタを開く」を選択します。次の値を入力します。

パラメータ

値

ホスト名

WebLogic管理サーバーを実行しているホストの名前: APPHOST3.mycompany.com

ポート

管理サーバーが使用しているポート。例: 7001

ユーザー名

管理サーバーの管理者アカウント名

パスワード

管理サーバーのパスワード

「次へ」をクリックします。「コンポーネントの構成」画面が表示されます。

注意:

2番目の中間層のインストールに同じ物理パスを使用することをお薦めします。このようにしておくと、1つのマシンで構成の変更を行い、その変更内容を別のマシンへ転送するときに役立ちます。

9.1.8 Oracle Web Cacheの無効化専用クラスタの構成

APPHOST4に2番目の中間層をインストールしたら、APPHOST1のOracle Web Cache Managerを使用して、APPHOST4のキャッシュをクラスタに追加する必要があります。そのためには、必要に応じてAPPHOST3をAPPHOST4に置き換えて第9.1.3項「Oracle Web Cacheの無効化専用クラスタの構成」の手順を実行します。

9.1.9 APPHOST4の2番目の内部中間層のロード・バランシング・ルーター用の構成

2番目の内部中間層をAPPHOST4に構成するには、次の手順を実行します。

1. WLS_PORTAL1(APPHOST4)をAPPHOST3のORACLE HTTP Serverに追加します。
管理対象サーバーWLS_PORTALを起動したら、外部中間層のOracle HTTP Server (OHS)からリクエストがルーティングされるように設定する必要があります。

2. クラスタ対応にするためにOracle HTTP Server構成を更新します。
WebLogicクラスタを作成したら、WebLogicのリクエストがクラスタに転送されるようにする必要があります。そのためには、APPHOST3のORACLE_INSTANCE/config/OHS/ohs1/moduleconfにあるportal.confファイルを次のように編集する必要があります。

- 次で始まるブロックのエントリを変更します。

- /portal

- /portalTools

- /wsrp-tools

- /portalHelp

- /portalHelp2

- 次を編集します。

<Location /portal>
SetHandler WebLogic-handler
WebLogicHost apphost3.mycompany.com
WebLogicPort 9001
</Location>

編集後

<Location /portal>
SetHandler WebLogic-handler
WebLogicCluster apphost3.mycompany.com:9001,apphost4.mycompany.com:9001
</Location>

3. 次のコマンドを使用してOracle HTTP Serverを再起動します。
opmnctl restartproc process-type=OHS

4. APPHOST3からAPPHOST4に構成情報をコピーします。

ファイル

APPHOST3上の場所

APPHOST4上の場所

appConfig.xml

portal_cache.conf

portal_dads.conf

portal_plsql.conf

MW_HOME/user_projects/domains/PortalDomain/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

MW_HOME/user_projects/domains/PortalDomain/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration

mod_oradav.conf

mod_osso.conf

plsql.conf

portal.conf

virtual_hosts.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

osso.conf

ORACLE_INSTANCE/config/OHS/ohs1

ORACLE_INSTANCE/config/OHS/ohs1

sqlnet.ora

ORACLE_INSTANCE/config/

ORACLE_INSTANCE/config/

5. 次のコマンドを使用してOracle HTTP Serverを再起動します。

ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME/opmn/bin/opmnctl startall

6. 仮想ホストを構成します。
基盤となるコンポーネントがロード・バランシング・ルーターのホスト名(internal.mycompany.com)とポート番号7777に基づいてURLを作成できるようにOracle Portal中間層を構成する必要があります。そのためには、仮想ホストを構成する必要があります。仮想ホストを構成するには、次の手順を実行します。

1. $INSTANCE_HOME/config/OHS/ohs1にあるhttpd.confファイルを編集します。

2. 次のエントリをこのファイルに追加します。

NameVirtualHost *:8888
<VirtualHost *8888>
ServerName http://internal.mycompany.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:8888>
ServerName apphost4.abc.oracle.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

7. APPHOST4上に次のポータル・ディレクトリを作成し、Oracle Portalのキャッシュの記憶域にします。
ORACLE_INSTANCE/portal/cache

ORACLE_INSTANCE/diagnostics/logs/portal

8. ディレクトリ$DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration内にあるファイルでインスタンス・パスを更新します。
次に示すようにファイルを編集します。

portal_cache.conf: PlsqlCacheDirectoryを変更します

portal_plsql.conf: PlsqlLogDirectoryを変更します

9. 次のURLを使用してAPPHOST4の管理サーバーにログインし、WLS_PORTAL1を起動します。
http://apphost4.abc.oracle.com:7001/console

WLS_PORTAL1の起動の詳細は、Oracle Portalエンタープライズ・デプロイメント・ガイド:11.1.1.2のWLS_PORTAL1の起動に関する項を参照してください。

10. 構成を検証します
構成が完了したら、構成を検証する必要があります。構成を検証するには、次のテストを実行します。

テスト

URL

結果

ロード・バランサのテスト

http://myPortal.mycompany.com/

ホーム・ページが表示されます

SSL経由したロード・バランサのテスト

https://myPortal.mycompany.com/

ホーム・ページが表示されます

ロード・バランサの終了のテスト

https://myPortal.mycompany.com/portal/pls/portal/owa_util.print_cgi_env

HTTPSのREQUEST_PROTOCOL値

9.1.10 Web Cacheの構成

Web Cacheパスワードの変更

Web Cacheの無効化パスワードと管理パスワードはランダムに生成されます。これらのパスワードをデフォルト値から新しい既知の値に変更することをお薦めします。パスワードを変更するには、次の手順を実行します。

1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

2. APPHOST4で「wc1」を選択します。

3. ページの最上部にあるメニュー・リストから「管理」を選択し、「パスワード」に移動します。

4. 新しい無効化パスワードと管理パスワードを入力します。確認して、「適用」をクリックします。

注意:

外部中間層で使用したパスワードと同じものを使用します。

5. 次のコマンドを使用してWeb Cacheを再起動し、変更を有効にします。
opmnctl restartproc ias-component=wc1

APPHOST3のOracle Web Cache Managerを使用してAPPHOST4を追加します。

Oracle Web Cache Managerを使用してAPPHOST4を追加するには、次の手順を実行します。

1. 「Origin Servers, Sites, and Load Balancing」で「Origin Server」をクリックします。

2. 「Origin Server」ページで、「Application Web Servers」表の「Add」をクリックします。

3. 「Add Application Web Server」ページで次の情報を入力します。

プロパティ

値

ホスト名

apphost4.abc.oracle.com

ポート

7778 (APPHOST4のOracle HTTP Serverリスニング・ポート)

Routing

ENABLED

容量

100

フェイルオーバーのしきい値

5

URLのping

/

Ping Interval

10

プロトコル

HTTP

4. 「発行」をクリックします。

5. オリジン・サーバーが正しく追加されていることを確認するために、「Origin Server」表でapphost4.abc.oracle.comを探します。

APPHOST3のOracle Web Cache Managerを使用して、ロード・バランシング・ルーター・サイトをオリジン・サーバーにマップします。

Web Cache Managerを使用してロード・バランシング・ルーター・サイトinternal.mycompany.comを2つのオリジン・サーバーapphost3.mycompany.comおよびapphost4.mycompany.comにマップするには、次の手順を実行します。

1. ナビゲーション・フレームで、「Origin Servers, Sites, and Load Balancing」の「Site-to-Server Mapping」を選択します。

2. 「Site-to-Server Mapping」ページにある表でロード・バランシング・ルーター・サイトのマッピングを選択し、「Edit Selected」をクリックします。

3. 「Select Application Web Servers」セクションで、APPHOST4の「Origin Server」ページで指定したアプリケーションWebサーバー(apphost4.mycompany.com)を選択します。

4. 「発行」をクリックします。

5. サイトが正しくマッピングされていることを確認するには、「Site to Server Mappings」表でAPPHOST3とAPPHOST4の両方がinternal.mycompany.comにマップされていることを確認します。

6. ページ上部の「変更の適用」をクリックします。「Cache Operations」ページで次の手順を実行します。

1. 「Propagate」をクリックしてAPPHOST4に変更を伝幡します。

2. 「Restart」をクリックしてAPPHOST3およびAPPHOST4のWeb Cachesを再起動します。

9.1.11 Oracle Metadata RepositoryのOracle Portalスキーマの構成

ホストに依存しない無効化を送信できるように、Oracle Metadata RepositoryのOracle Portalスキーマを構成します。これを行うには、次の手順を実行します:

1. APPHost1にログインし、SQL*Plusを使用してスクリプトOH/portal/admin/plsql/wwc/cachhii.sqlを実行します。

2. プロンプトでonを指定して、ホストに依存しない無効化を有効にします。

9.1.12 構成完了後の検証

構成が完了し、正常に機能していることを確認するには、次の手順を実行します。

1. 次の手順を実行して、ロード・バランシング・ルーターを介してOracle AS Portalにアクセスできるかどうかをテストします。

1. http://internal.mycompany.com:7777/pls/portalにあるOracleAS Portalのホームページにアクセスします。

2. ポータルのログイン・リンクをクリックします。

3. ポータルのリンクをいくつかクリックしてみます。

4. コンテンツがOracle Web Cacheにキャッシュされていることを確認します。そのためには、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、APPHOST3のOracle Web Cache Managerにアクセスします。
「Monitoring」で「Popular Requests」をクリックします。「Filter Objects」ドロップダウン・リストから「Cached」を選択し、「Update」をクリックします。Oracle Portalにアクセスできていれば、ポータル・コンテンツ(/pls/portalを含むURLなど)が表示されます。

Oracle Portalで、ポートレットをページに追加するなどの基本的なページ編集を行って、新しいコンテンツが表示されることを確認します。新しいコンテンツが正しく表示されない場合やエラーが発生する場合は、Oracle Web Cacheの無効化の構成に誤りがあります。

9.2 Oracle Portal 10gのイントラネットおよびインターネット設定の11gへのアップグレード

この項の内容は、次のとおりです。

- 外部中間層のインストールとアップグレード

- 外部中間層のアップグレード後の構成

- APPHOST3への最初の内部中間層のインストールとアップグレード

- APPHOST3の最初の内部中間層のアップグレード後の構成

- APPHOST4への2番目の中間層のインストールとアップグレード

- APPHOST4の2番目の内部中間層のアップグレード後の構成

- 構成の検証

9.2.1 外部中間層のインストールとアップグレード

外部中間層のインストール

外部中間層をインストールするには、次のタスクを実行します。

1. WebLogic Serverバージョン1034をインストールします。

2. PS1 S/Wビットをインストールします。

3. PS3 Sparseパッチをインストールします。

4. MW_HOME/oracle_home/install/config/deployにあるvi portal-deployment-sequence.xmlファイルを開きます。
次に示すように、ファイルの次の行をコメントアウトします。

<!-- <Deploy name="portalHelp" file="portal/jlib/portalHelp.ear" description="Portal Help" stagingMode="nostage"/> -->
<!-- <Deploy name="portalHelp2" file="portal/jlib/portalHelp2.ear" description="Portal Help 2" stagingMode="nostage"/>-->

5. MW_HOME/$ORACLE_HOME/binにある./config.shを実行します。

リポジトリおよび外部中間層のアップグレード

リポジトリおよび外部中間層は、アップグレード・アシスタントを使用してアップグレードする必要があります。外部中間層および必要なスキーマとリポジトリをアップグレードするには、Oracle Fusion Middleware Oracle Portal、Forms、ReportsおよびDiscovererアップグレード・ガイドのタスク6: アップグレード・アシスタントを使用した必要なスキーマおよび中間層のアップグレードに関する項を参照してください。

9.2.2 外部中間層のアップグレード後の構成

リポジトリと中間層をアップグレードしたら、中間層を構成する必要があります。次の構成タスクを実行する必要があります。

1. MW_HOME/instance_name/config/OHS/ohs1にあるhttpd.confファイルを開きます。次に示すようにファイルを編集します。

NameVirtualHost*:7778
<VirtualHost*:7778>
ServerName portal.mycompany.com
#SecureHttps On
Port 443
UseCanonicalName On
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

<VirtualHost*:7778>
ServerName apphost1.abc.oracle.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

2. フロントエンド・ホストおよびポートの詳細を指定します。

1. 次のURLを使用して、アップグレードしたWebLogicコンソールにログインします。
http://apphost1.abc.oracle.com:7001/console

2. 左側のナビゲーション・パネルで「クラスタ」に移動し、「クラスタのサマリー」をクリックします。

3. 「cluster_portal」を選択します。cluster_portalの設定ページが表示されます。

4. 「構成」セクションで「HTTP」タブを選択します。

5. 次に示すフロントエンド・ホストおよびポートの詳細を入力します。
フロントエンド・ホスト: portal.mycompany.com

フロントエンドHTTPポート: 80

フロントエンドHTTPSポート: 443

6. 「保存」をクリックします。「変更のアクティブ化」をクリックして変更を有効にします。

3. WLS_PORTALを再起動して構成の変更を有効にします。WLS_PORTALを再起動するには、次の手順を実行します。

1. http://apphost1.abc.oracle.com:7001/consoleにログインします。

2. 「サーバー」に移動して「制御」タブを選択します。

3. 「WLS_PORTAL」チェック・ボックスを選択し、「停止」をクリックします。

4. WLS_PORTALを再起動するには、「WLS_PORTAL」チェック・ボックスを選択し、「起動」をクリックします。
WLS_PORTALが起動します。

4. 次の場所にあるportal_dads.confファイルを開きます:次に示すようにファイルを編集します。

<Location /pls/portal>
SetHandler pls_handler
Order allow,deny
Allow from All
AllowOverride None
PlsqlDatabaseUsername portal
PlsqlDatabasePassword CSFPassword
PlsqlDatabaseConnectString portalinfra.abc.oracle.com:1521:portaldb.abc.oracle.com  ServiceNameFormat
PlsqlNLSLanguage AMERICAN_AMERICA.WE8ISO8859P1
PlsqlAuthenticationMode SingleSignOn
PlsqlDocumentTablename portal.wwdoc_document
PlsqlDocumentPath docs
PlsqlDocumentProcedure portal.wwdoc_process.process_download
PlsqlDefaultPage portal.home
PlsqlPathAlias url
PlsqlPathAliasProcedure portal.wwpth_api_alias.process_download
PlsqlExclusionList "#None#"
PlsqlCGIEnvironmentList "REQUEST_PROTOCOL=HTTPS"
PlsqlCGIEnvironmentList "SERVER_PORT=443"
</Location>

5. データベース・ウォレットを作成し、そのウォレットにロード・バランサの証明書を格納します。データベース・ウォレット内に証明書を格納したら、そのウォレットの場所をポータル・リポジトリ内に格納する必要があります。
そのためには、Oracle Portalエンタープライズ・デプロイメント・ガイド:11.1.1.2の次の項にある手順をすべて実行します。

- データベース・ウォレットの作成

- データベース・ウォレットへの証明書のインポート

- ポータルに対するウォレットの識別

6. 外部中間層をSSOに登録する必要があります。SSOへの登録の詳細は、Oracle Portalエンタープライズ・デプロイメント・ガイド:11.1.1.2を参照してください。

7. Web層(OHSとWeb Cache)を再起動します。
前述の変更を行った後、Web層コンポーネントを再起動する必要があります。そのためには、次のコマンドを発行します。

opmnctl stopall

opmnctl startall

8. 構成を検証します。
構成を検証するには、次のテストを実行します。

テスト

URL

結果

ロード・バランサのSSL終了のテスト

https://myPortal.mycompany.com/portal/pls/portal/owa_util.print_cgi_env

HTTPSのREQUEST_PROTOCOL値

ロード・バランサを経由したPortalのテスト

https://myPortal.mycompany.com/portal/pls/portal

ポータルのホーム・ページが表示されます

ロード・バランサを経由したPortalログインのテスト

https://myPortal.mycompany.com/portal/pls/portal

orcladminアカウントを使用してログインできる必要があります。

9.2.3 APPHOST3への最初の内部中間層のインストールとアップグレード

APPHOST3への最初の内部中間層のインストール

内部中間層をAPPHOST3にインストールするには、次のタスクを実行します。

1. WebLogic Serverバージョン1034をインストールします。

2. PS1 S/Wビットをインストールします。

3. PS3 Sparseパッチをインストールします。

4. MW_HOME/oracle_home/install/config/deployにあるvi portal-deployment-sequence.xmlファイルを開きます。
次に示すように、ファイルの次の行をコメントアウトします。

<!-- <Deploy name="portalHelp" file="portal/jlib/portalHelp.ear" description="Portal Help" stagingMode="nostage"/> -->
<!-- <Deploy name="portalHelp2" file="portal/jlib/portalHelp2.ear" description="Portal Help 2" stagingMode="nostage"/>-->

5. 次に示すように、データベースに接続し、ポータル・スキーマのバージョンを変更します。

>sqlplus portal/portaldb_portal@portaldb
sql> select version from wwc_version$;
sql> 11.1.1.4.0

次に示すように、今度はバージョンを11.1.1.1.0に変更します。

sql> update wwc_version$ set version = '11.1.1.1.0';
sql> commit;
sql> select * from wwc_version$;
sql> 11.1.1.1.0

6. 11g RCUを使用してポートレット・スキーマを作成します。

7. MW_HOME/$ORACLE_HOME/binにある./config.shを実行します。

APPHOST3の最初の内部中間層のアップグレード

APPHOST3の内部中間層をアップグレードするには、アップグレード・アシスタントを使用する必要があります。APPHOST3の内部中間層をアップグレードするには、Oracle Fusion Middleware Oracle Portal、Forms、ReportsおよびDiscovererアップグレード・ガイドのタスク6: アップグレード・アシスタントを使用した必要なスキーマおよび中間層のアップグレードに関する項を参照してください。

注意:

リポジトリは外部中間層に対してのみアップグレードされます。APPHOST3およびAPPHOST4の内部中間層に対しては、リポジトリのアップグレードは不要です。

9.2.4 APPHOST3の最初の内部中間層のアップグレード後の構成

内部中間層をアップグレードしたら、その中間層を構成する必要があります。次の構成タスクを実行する必要があります。

1. フロントエンド・ホストおよびポートの詳細を指定します。

1. 次のURLを使用して、アップグレードしたWebLogicコンソールにログインします。
http://apphost3.abc.oracle.com:7001/console

2. 左側のナビゲーション・パネルで「クラスタ」に移動し、「クラスタのサマリー」をクリックします。

3. 「cluster_portal」を選択します。cluster_portalの設定ページが表示されます。

4. 「構成」セクションで「HTTP」タブを選択します。

5. 次に示すフロントエンド・ホストおよびポートの詳細を入力します。
フロントエンド・ホスト: internal.mycompany.com

フロントエンドHTTPポート: 7777

「保存」をクリックします。

注意:

「フロントエンドHTTPSポート」フィールドは空白のままにします。

6. 次の手順を実行してWLS_PORTALを再起動し、変更を有効にします。

1. WebLogicコンソールにログインします。

2. 「サーバー」に移動して「制御」タブを選択します。

3. 「WLS_PORTAL」チェック・ボックスを選択し、「停止」をクリックします。

4. WLS_PORTALを再起動するには、「WLS_PORTAL」チェック・ボックスを選択し、「起動」をクリックします。
WLS_PORTALが起動します。

2. APPHOST3の内部中間層をSSOに登録する必要があります。SSOへの登録の詳細は、Oracle Portalエンタープライズ・デプロイメント・ガイド:11.1.1.2を参照してください。生成されたosso.confファイルを次のディレクトリにコピーします。
$ORACLE_HOME/asinst_1/config/OHS/ohs1/osso.

3. Web層(OHSとWeb Cache)を再起動します。
前述の変更を行った後、Web層コンポーネントを再起動する必要があります。そのためには、次のコマンドを発行します。

opmnctl stopall

opmnctl startall

9.2.5 APPHOST4への2番目の中間層のインストールとアップグレード

APPHOST3の最初の内部中間層をインストールしてアップグレードしたら、ポータル・バージョン番号を元のバージョン番号に戻す必要があります。これを行うには、次の手順を実行します:

1. 次の例に示すように、portal schemaとしてデータベースに接続し、ポータル・バージョンを問い合せます。

>sqlplus portal/portaldb_portal@portaldb
sql> select version from wwc_version$;
sql> 11.1.1.1.0

2. 次の例に示すように、ポータル・リポジトリ・バージョンを11.1.1.4.0に変更します。

sql> update wwc_version$ set version = '11.1.1.4.0';
sql> commit;
sql> select * from wwc_version$;
sql> 11.1.1.4.0

注意:

ポータル・バージョン番号の変更は最初の内部中間層をAPPHOST3にインストールおよびアップグレードする場合にのみ必要になります。以降、APPHOST4や他の中間層を設定する場合、ポータル・バージョン番号は変更しないでください。

APPHOST4への2番目の内部中間層のインストール

2番目の内部中間層をAPPHOST4にインストールするには、次のタスクを実行します。

1. 外部中間層のインストールの手順をすべて実行します。

2. 第9.1.7項「APPHOST4への2番目の内部中間層のインストール」の説明に従って、Oracle Portal 11gをインストールします。

APPHOST4の2番目の内部中間層のアップグレード

APPHOST3の内部中間層をアップグレードするには、アップグレード・アシスタントを使用する必要があります。APPHOST3の内部中間層をアップグレードするには、Oracle Fusion Middleware Oracle Portal、Forms、ReportsおよびDiscovererアップグレード・ガイドのタスク6: アップグレード・アシスタントを使用した必要なスキーマおよび中間層のアップグレードに関する項を参照してください。

注意:

リポジトリは外部中間層に対してのみアップグレードされます。APPHOST3およびAPPHOST4の内部中間層に対しては、リポジトリのアップグレードは不要です。

9.2.6 APPHOST4の2番目の内部中間層のアップグレード後の構成

APPHOST4のWebLogicドメインを構成するには、次のタスクを実行します。

1. WLS_PORTAL1(APPHOST4)をAPPHOST3のORACLE HTTP Serverに追加します。
管理対象サーバーWLS_PORTALを起動したら、外部中間層のOracle HTTP Server (OHS)からリクエストがルーティングされるように設定する必要があります。

2. クラスタ対応にするためにOracle HTTP Server構成を更新します。
WebLogicクラスタを作成したら、WebLogicのリクエストがクラスタに転送されるようにする必要があります。そのためには、APPHOST3のORACLE_INSTANCE/config/OHS/ohs1/moduleconfにあるportal.confファイルを次のように編集する必要があります。

- 次で始まるブロックのエントリを変更します。

- /portal

- /portalTools

- /wsrp-tools

- /portalHelp

- /portalHelp2

- 次を編集します。

<Location /portal>
SetHandler WebLogic-handler
WebLogicHost apphost3.mycompany.com
WebLogicPort 9001
</Location>

編集後

<Location /portal>
SetHandler WebLogic-handler
WebLogicCluster apphost3.mycompany.com:9001,apphost4.mycompany.com:9001
</Location>

3. 次のコマンドを使用してOracle HTTP Serverを再起動します。
opmnctl restartproc process-type=OHS

4. APPHOST3からAPPHOST4に構成情報をコピーします。

ファイル

APPHOST3上の場所

APPHOST4上の場所

appConfig.xml

portal_cache.conf

portal_dads.conf

portal_plsql.conf

MW_HOME/user_projects/domains/PortalDomain/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

MW_HOME/user_projects/domains/PortalDomain/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration

mod_oradav.conf

mod_osso.conf

plsql.conf

portal.conf

virtual_hosts.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

osso.conf

ORACLE_INSTANCE/config/OHS/ohs1

ORACLE_INSTANCE/config/OHS/ohs1

sqlnet.ora

ORACLE_INSTANCE/config/

ORACLE_INSTANCE/config/

5. 仮想ホストを構成します。これを実行する手順を次に示します。

1. APPHOST4のORACLE_INSTANCE/config/OHS/ohs1/moduleconfにあるvirtual_hosts.confファイルを編集します。

2. 次に示すように、UseCanonicalName Onエントリがファイルにあることを確認します。

NameVirtualHost *:7778
<VirtualHost *7778>
ServerName http://internal.mycompany.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:7778>
ServerName apphost4.abc.oracle.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

6. 次のコマンドを使用してOracle HTTP Serverを再起動します。

ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME/opmn/bin/opmnctl startall

7. APPHOST4上に次のポータル・ディレクトリを作成し、Oracle Portalのキャッシュの記憶域にします。
ORACLE_INSTANCE/portal/cache

ORACLE_INSTANCE/diagnostics/logs/portal

8. ディレクトリ$DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration内にあるファイルでインスタンス・パスを更新します。
次に示すようにファイルを編集します。

portal_cache.conf: PlsqlCacheDirectoryを変更します

portal_plsql.conf: PlsqlLogDirectoryを変更します

9. WLS_PORTAL1を起動する前に、次の手順を実行します。

1. $ORACLE_HOME/archives/applications dirにあるportal.earファイルを解凍します。

2. portal_dads.conf (0バイトのファイル)を開きます。ファイルに内容を追加して0バイト以外のファイルにし、保存します。

3. portal.earファイルを再ビルドします。

4. WLS_PORTAL1を再起動します。

5. APPHOST3インスタンスから$DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration (APPHOST4)にportal_dads.confファイルをコピーします。

6. WLS_PORTAL1サーバーを再起動します。

10. 次のURLを使用してAPPHOST4の管理サーバーにログインし、WLS_PORTAL1を起動します。
http://apphost4.abc.oracle.com:7001/console

WLS_PORTAL1の起動の詳細は、Oracle Portalエンタープライズ・デプロイメント・ガイド:11.1.1.2のWLS_PORTAL1の起動に関する項を参照してください。

9.2.7 構成の検証

構成を検証するには、次の2つのシナリオで外部ポータルURL (http://portal.mycompany.com/portal/pls/portal)と内部ポータルURL (http://internal.mycompany.com:7777/portal/pls/portal)にアクセスし、それぞれが正しく動作することを確認します。

- APPHOST3 (opmnサービスとWLS_PORTAL)が完全に停止しており、APPHOST4 (opmnサービスとWLS_PORTAL)が完全に起動している。
APPHOST3 (opmnサービスとWLS_PORTAL)が完全に起動しており、APPHOST4 (opmnサービスとWLS_PORTAL)が完全に停止している。

10 Oracle Portalの検索機能の構成

この章では、Oracle Portalでの検索機能の設定方法について説明します。これには、Oracle Textの設定方法とOracle Text索引の管理方法も含まれます。

この章の内容:

- Oracle Portalの検索オプション

- Oracle Portalの検索オプションの構成

- Oracle Text

- Oracle Secure Enterprise Search

10.1 Oracle Portalの検索オプション

Oracle Portalは、必要に応じてカスタマイズできる強力な検索機能を提供します。堅牢な組込みの検索ポートレットにより、ポートレット・リポジトリ、ポータル・ページおよび外部サイトの検索を実行できます。

さらに、HTML、XML、PDF、ワープロ書式、スプレッドシート書式、プレゼンテーション書式、その他の一般的なビジネス書式などを含む、100種類を超えるドキュメント・タイプを検索できます。

この項では、Oracle Portalで利用できる検索オプション、および最適なオプションを選択する方法について説明します。

- Oracle Portalの検索

- Oracle Secure Enterprise Search

- デフォルトの検索機能

- 使用する検索オプションの決定

- Oracle Secure Enterprise SearchとOracle Portal検索の違い

10.1.1 Oracle Portalの検索

Oracle Portalには、Oracle Portalリポジトリ内に格納、管理されているコンテンツを検索するための組込み機能のセットがあります。これらの機能は、様々な方法で構成できる次の4つの検索ポートレットに組み込まれています。

- 「基本検索」 - このポートレットでは、簡単なキーワード検索が可能です。

- 「拡張検索」 - このポートレットでは、複数の属性値の演算子を含む、より詳細な検索条件を入力できます。

- 「カスタム検索」 - このポートレットは、任意にカスタマイズでき、結果を適切に表示する定義済の検索など、ニーズに合せた検索ポートレットを設計できます。このポートレットは、「基本検索」および「拡張検索」ポートレットのスーパーセットのため、必要に応じてこれらのポートレットと同様の外観および動作となるよう構成可能です。

- 「保存された検索」 - このポートレットでは、保存された検索を繰り返すことができます。

これらのポートレットによる検索では、Oracle Portalリポジトリ内のコンテンツに関連付けられたテキスト・タイプのすべてのメタデータが検索されます。たとえば、表示名、キーワード、説明、その他の類似属性などです。

Oracle Textは、デフォルトでOracle Portalで有効になっているため、ポートレットではメタデータ以外にポータルのコンテンツも検索できます。

注意:

これは、ポートレットのコンテンツには適用されません。ポートレット・コンテンツは索引を作成できないため、検索することもできません。

つまり、Oracle Portalの検索ポートレットでは、次のものも検索対象になります。

- ドキュメントとファイルおよびURLアイテム - バイナリ形式のファイルとURLアイテムは、Oracle Textで絞込みできるファイル形式であれば、索引を作成できます。

- URL (URL属性内の)が指定するWebページ - コンテンツはプレーン・テキストまたはHTMLである必要があります。

注意:

AND検索演算子(「すべての語を含む」、「すべての語に部分的に一致する」、「すべての語にあいまい一致する」など)を使用して複数の検索文字列を指定した場合は、それらすべての文字列が同じ検索索引内に出現する場合にのみ一致となります。たとえば、weights aerobicsと入力して「すべてを含む」演算子を選択したとします。検索結果が返されるのは、この2つの語がアイテムのメタデータ、URLコンテンツまたはドキュメント・コンテンツで検出された場合のみです。weightsがURLコンテンツで検出され、aerobicsがドキュメント・コンテンツで検出された場合は一致したことになりません。

Oracle Portalで使用するOracle Textの構成方法の詳細は、第10.2.2項「Oracle PortalでのOracle Textオプションの構成」を参照してください。Oracle Text、Oracle Text索引の管理方法およびトラブルシューティングの情報の詳細は、第10.3項「Oracle Text」を参照してください。

Oracle Portalの検索ポートレットの構成方法の詳細は、第10.2.1項「Oracle Portal検索ポートレットの構成」を参照してください。Oracle Portal検索ポートレット、Oracle Portalページへの検索機能の追加方法の詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

Oracle Textの無効化

アウト・オブ・ボックスのOracle Textは有効化されています。Oracle Textを無効化することはお薦めしませんが、ポータルでOracle Portalリポジトリ・コンテンツの全テキスト検索を必要としない場合やそのメリットがない場合は、Oracle Textを無効にできます。詳細は、第10.3.1.1項「Oracle Textを無効にした検索」を参照してください。

検索結果とコンテンツのセキュリティ

Oracle Portalの検索結果のページには、検索基準に一致するアイテム、ページ、カテゴリまたはパースペクティブが表示されます。詳細は、第10.1.3項「デフォルトの検索機能」を参照してください。検索結果に、次のものは表示されません。

- 表示する権限のないコンテンツ。

- 期限切れ、またはまだ公開されていないコンテンツ。

- テンプレートから生成されたページ・コンテンツ。

- ポートレット・インスタンスまたはポータル・スマート・リンク

- 複数バージョンのアイテム(バージョニングが有効な場合、検索結果には現在のバージョンのアイテムのみが返されます)

ページ設計者は、各検索結果と関連するオブジェクトへのリンクを表示するかどうかを選択できます。たとえば、アイテムに関連するページ・グループ、ページ、カテゴリおよびパースペクティブへのリンクを表示できます。ただし、ユーザーに適切なアクセス権限が付与されていない場合、リンクをクリックしてオブジェクトにアクセスすることは、拒否されます。

10.1.2 Oracle Secure Enterprise Search

Oracle Secure Enterprise Search (SES)は、Oracle Portalリポジトリなど、様々なコンテンツ・リポジトリおよびデータ・ソースに対するエンタープライズ検索機能を提供します。Oracle Secure Enterprise Searchには、Oracle Portalページに埋め込むことができるセキュアな検索ポートレットが用意されています。

このポートレットから、ユーザーが検索文字列を入力して検索を行うと、構成されたすべてのデータ・ソースのコンテンツが含まれる1つの結果セットが返されます。Oracle Portalがデータ・ソースの1つとして構成されている場合、検索を実行すると、パブリック・コンテンツ、およびユーザーが表示権限を持つプライベート・コンテンツが返されます。

Oracle Secure Enterprise Searchの構成手順の詳細は、Oracle Technology Network (OTN)(http://www.oracle.com/technology/products/oses/index.html)から入手できる『Oracle Secure Enterprise Search管理者ガイド』を参照してください。

Oracle Secure Enterprise Searchの概要の詳細は、第10.4項「Oracle Secure Enterprise Search」を参照してください。

10.1.3 デフォルトの検索機能

Oracle Portalの標準インストールの後、すぐにOracle Portalの検索機能を使用できます。追加の構成をせずに、組込みのOracle Portal検索ポートレットのいずれかをページに配置し、ポータル・コンテンツの検索に使用できます。

インストール時に、Oracle Textの索引が作成され、同期化されると、ポータルでOracle Textの検索が有効になります。ただし、新しいまたは変更されたコンテンツ(アイテム、ページ、カテゴリ、パースペクティブ)は、Oracle Textの索引が再び同期化されるまで、検索結果として返されないことに注意する必要があります。第10.3.5.1項「Oracle Text索引の同期化」を参照してください。

デフォルトでは、Oracle Textの索引はwwv_context.syncをコールするジョブによって1時間おきに同期化されます。使用するポータルにデフォルトの同期化の間隔が適していない場合は、いつでも変更できます。詳細は、第10.3.5.5項「Oracle Text索引の同期化の頻度の決定」を参照してください。

Oracle Database 11gを使用している場合、ポータル・オブジェクトが追加、変更または削除されるたびに、Oracle Text索引が自動的に同期化されるように指定できます。この機能は、新しく追加または変更されたコンテンツをただちに検索可能にする必要のあるポータル・アプリケーションで役立ちます。詳細は、第10.3.5.2項「Oracle Text索引のコミット時の同期化」を参照してください。

注意:

Oracle Textで提供される追加機能を使用しない場合は、この機能を無効にできます。第10.2.2.1項「Oracle PortalでのOracle Textの有効化と無効化」を参照してください。

表10-1は、その他のデフォルトの検索設定を示しています。これらの値の変更方法の詳細は、第10.2項「Oracle Portalの検索オプションの構成」を参照してください。

表10-1 デフォルトの検索設定

検索設定オプション

デフォルト

結果ページ - 基本検索ポートレットおよび基本検索ボックス・アイテム

基本検索結果ページ

結果ページ - 拡張検索、カスタム検索および保存された検索ポートレット

検索結果ページ

拡張検索リンク

拡張検索ページ

インターネット検索エンジン・リンク

なし

ページに表示するヒット件数

20

Oracle Text

有効

Oracle Text - テーマと要旨

無効

Oracle Text - テキストの色を強調

デフォルト

Oracle Text - テキストのスタイルを強調

プレーン

Oracle Text - ベースURL

http://<host>:<port>/portal/pls/<dad>

次の図は、デフォルトの検索ポートレットおよびページを示しています。

図10-1 Oracle Portalの「基本検索」ポートレット

図10-2 Oracle Portalの「基本検索結果ページ」

図10-3 Oracle Portalの「拡張検索」ポートレット

図10-4 Oracle Portalの「カスタム検索」ポートレット

図10-5 Oracle Portalの「検索結果ページ」

図10-6 Oracle Portalの「保存された検索」ポートレット

10.1.4 使用する検索オプションの決定

Oracle Portal内での検索の構成方法の選択は、検索の目的を慎重に検討し、ポータル・コンテンツについて理解することから始まります。主な考慮事項の一部を次に示します。

- 検索の範囲 - ポータルの検索から返される結果を、Oracle Portalリポジトリ内で管理されるコンテンツに制限するのか、それともその他のリポジトリからの結果を返すようにするのか。

- 検索のレベル - ドキュメント・コンテンツの全テキストの索引作成が必要なのか、それともメタデータのみの索引作成で十分なのか。

- コンテンツのセキュリティ・ポリシーとポータル・ユーザー・プロファイル - 検索は、主にパブリック・コンテンツを検索するパブリックの認証されていないユーザーを対象にするのか、それともコンテンツに対して様々なレベルのアクセス権限を持つ個々のユーザーを対象にするのか。

- 拡張検索機能 - 結果を関連性に基づいて整列し、ドキュメントのテーマと要旨、およびOracle Textのその他の機能を表示する機能をユーザーに提供することが重要かどうか。

- 管理 - 索引、データ・ソースなどの管理および維持にどのぐらいの時間を費やすことができるか。

表10-2を使用して、検索要件を満たす最適な検索構成を選択します。

表10-2 Oracle Portalの検索オプション

Oracle Portal (Oracle Textが無効)

Oracle Portal (Oracle Textが有効)

Oracle Secure Enterprise Search

検索の範囲

Oracle Portalリポジトリのみ。

Oracle Portalリポジトリのみ。

Oracle Portalリポジトリおよびその他のリポジトリ。

検索のレベル

Oracle Portalメタデータのみ。

全テキスト索引。

全テキスト索引。

コンテンツのセキュリティとユーザー・プロファイル

検索結果にセキュアなパブリック・コンテンツを返します。

検索結果にセキュアなパブリック・コンテンツを返します。

検索結果にセキュアなパブリック・コンテンツを返します。

拡張検索機能

いいえ

はい

はい

管理

最小限

全テキスト索引を維持します。

全テキスト索引を維持し、データ・ソースを構成します。

10.1.5 Oracle Secure Enterprise SearchとOracle Portal検索の違い

この項では、Oracle Secure Enterprise SearchとOracle Portal検索の主な違いを中心に説明します。

- パブリック・コンテンツの収集は、Oracle Ultra Searchでのみ可能です。
Oracle Portalは、Oracle Ultra Searchにファイル・システムとして公開されます。フォルダのコンテンツを表示するには、そのフォルダをパブリックにする必要があります。パブリックにしないと、そのフォルダからも、そのフォルダのサブフォルダ階層からもコンテンツを収集できません。コンテンツを作成してそれをパブリックにした場合でも、その索引を作成するには、そのコンテンツを格納するすべてのフォルダをパブリックにする必要があります。

- Oracle Secure Enterprise Searchはページとアイテムを1つのリストとして返します。
Oracle Secure Enterprise Searchは、Oracle Portalのページとアイテムを、メタデータとコンテンツを含むリソースとして認識します。言い換えれば、収集して索引を作成し、検索結果を返し、視覚的に表現する対象となります。つまり、Oracle Secure Enterprise Searchは、ページとアイテムの両方を含む検索結果のリストを返すことができます。Oracle Portal検索は、データのタイプ(ページ、アイテム、カテゴリおよびパースペクティブ)を区別して検索するため、一度に1つのタイプのデータのみを検索できます。Oracle Secure Enterprise Searchの場合は、カテゴリとパースペクティブを検索可能なエンティティとして区別しないため、特定のパースペクティブまたはカテゴリを含むアイテムとページを(Oracle Portal検索と同様に)検索できます。

- Oracle Secure Enterprise Searchは、メタデータ以外に、表示されているページのコンテンツを検索します。
Oracle Portal検索は、ページとアイテムのメタデータを検索します。Oracle Secure Enterprise Searchクローラは、表示されているコンテンツに加えてメタデータを対象にします。つまり、Oracle Secure Enterprise Searchは、Oracle Portal検索が結果を返さないときでも、結果を返すことができます。

- Oracle Portal検索では、いくつかのアイテム・タイプが除外されます。
Oracle Portal検索は、次のベース・アイテム・タイプのアイテムのみを返すことができます。

- <なし>(ベース・アイテム・タイプがない)

- ベース・ファイル

- ベースURL

- ベース・テキスト

- ベースPL/SQL

- ベース・ページ・リンク

- ベース・イメージ

- ベース・イメージ・マップ

Oracle Secure Enterprise Searchは、ベース・アイテム・タイプに関係なく、アイテムのメタデータとともに、アイテムがページに表示されるときのアイテム・タイプ表現に基づいて、索引を作成します。ページの解釈に基づいて索引が作成されるためです。つまり、バナー、テンプレート・アイテム、ログイン/ログアウトのリンクなど、ページ上のすべての静的コンテンツと動的コンテンツの索引が、Oracle Secure Enterprise Searchによって作成されます。

- Oracle Textとスコア計算システム

Oracle Secure Enterprise SearchとOracle Portal検索は、どちらもOracle Textを使用してコンテンツの索引を作成しますが、その実装方法は異なります。さらに、Oracle Secure Enterprise Searchは、Oracle Portal検索と異なるスコア計算システムを使用し、カスタマイズすることもできます。詳細は、OTN(http://www.oracle.com/technology/products/oses/index.html)から入手できる『Oracle Secure Enterprise Search管理者ガイド』を参照してください。

どちらのスコア計算システムでも、タイトルに検索文字列が見つかった場合に重み付けされるため、タイトル内でのヒット数は、ドキュメント・コンテンツ内でのヒット数よりも高く計算されます。Oracle Portalの検索では、タイトルに複数の文字列が見つかった場合はさらに高いスコアが付けられます。また、検索条件に近い複数の文字列や最もヒット数が多い検索結果に対しても重み付けされます。

- Oracle Secure Enterprise Searchは外部コンテンツを収集します
Oracle Secure Enterprise Searchは、Oracle Portalの外部のコンテンツ(外部Webソース)を収集できます。Oracle Portalの検索は、内部コンテンツに制限されます。

10.2 Oracle Portalの検索オプションの構成

Oracle Portalの検索機能は、デフォルトでインストールされるので、すぐに検索機能を使用できます。インストール時のデフォルトの詳細は、第10.1.3項「デフォルトの検索機能」を参照してください。

この項では、ポータル管理者がすべての検索ポートレットに影響する次の検索機能を構成する方法について説明します。

- Oracle Portal検索ポートレットの構成

- Oracle PortalでのOracle Textオプションの検索

- Oracle PortalでのOracle Secure Enterprise Searchオプションの構成

10.2.1 Oracle Portal検索ポートレットの構成

この項では、すべてのOracle Portal検索ポートレットに影響する次の検索機能を構成する方法について説明します。

- 検索結果ページの選択

- ページに表示する検索結果の数の制限

- 「拡張検索」リンクの選択(「基本検索」および「カスタム検索」ポートレット)

- インターネット検索エンジンの選択(「拡張検索」および「カスタム検索」ポートレット)

10.2.1.1 検索結果ページの選択

次の場所から検索した結果の表示に使用するページを指定できます。

- 「基本検索」ポートレットおよび「基本検索」ボックス・アイテム

- 「拡張検索」、「カスタム検索」および「保存された検索」ポートレット

異なる検索結果ページを選択すると、新しい検索ポートレットと既存の検索ポートレットの両方に適用されます。

必要に応じて、特定の「カスタム検索」ポートレットの設定をオーバーライドできます。「検索結果を表示する場所を指定してください。」オプション(「デフォルトの編集: 結果の表示」タブ)が「デフォルト検索結果ページ」に設定されている場合は、「カスタム検索」ポートレットはここで指定された結果ページのみを使用します。「カスタム検索」ポートレットのオプションの設定方法の詳細は、OTN(http://www.oracle.com/technology/products/ias/portal/documentation.html)から入手できる『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

Oracle Portal検索ポートレットの検索結果ページを指定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「検索」タブをクリックします。

3. 「基本検索ポートレットおよび基本検索ボックス・アイテム」の「検索結果ページ」セクションで、適切な検索結果ページを選択します。
検索ポートレットを含む任意のポータル・ページを選択できます。検索ポートレットのないページを選択した場合、結果は表示されません。デフォルトは、「基本検索結果ページ」です。

4. 「拡張検索、カスタム検索および保存された検索ポートレット」に、適切な検索結果ページを選択します。
検索ポートレットを含む任意のポータル・ページを選択できます。検索ポートレットのないページを選択した場合、結果は表示されません。デフォルトは、「検索結果ページ」です。

5. 「OK」を選択します。

注意:

ページ・キャッシュが有効になっている場合でも、既存の検索ポートレットに変更がすぐに表示されないことがあります。すべての検索ポートレットのキャッシュは、24時間ごとに自動的に消去されます。これらのキャッシュは、Oracle Fusion Middleware Controlの「Webキャッシュ管理」ページから手動で消去することもできます。第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

選択したページが後で削除されると、関連する「ページ」フィールドは空になります。別のページを選択し、「OK」をクリックします。「取消」をクリックすると、検索操作後に「ページが見つかりません。」というエラーが表示されます。

10.2.1.2 ページに表示する検索結果の数の制限

検索ポートレットに表示する結果の数を制限できます。この制限は、「基本検索」、「拡張検索」および「カスタム検索」ポートレットに適用されます。

個々の「基本検索」または「拡張検索」ポートレットに対してこの制限の変更はできません。ただし、必要に応じて、「カスタム検索」ポートレットの設定をオーバーライドできます。

検索によって返される結果の数がこの制限を超える場合、検索結果ページには、すべての結果が表示できるように図10-7に示すような「次へ」および「前へ」アイコンが表示されます。「カスタム検索」ポートレットでは、これらのアイコンは必要に応じて非表示にできます。

「カスタム検索」ポートレットのオプションを設定する方法の詳細は、OTN(http://www.oracle.com/technology/products/ias/portal/documentation.html)から入手できる『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

図10-7 検索ポートレットの「ページに表示するヒット件数」の設定

たとえば、「ページに表示するヒット件数」の制限を10にした場合、最初の検索結果ページには最初の10件の結果が表示され、以降の各ページには最初の10件に続く結果が10件ずつ表示されます。

注意:

制限を変更した場合、新しい値は既存の検索ポートレットではなく、新しい検索ポートレットにのみ影響します。

1ページ当たりの検索結果の数を指定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「検索」タブをクリックします。

3. 「検索のプロパティ」セクションの「ページに表示するヒット件数」に、1ページに表示する検索結果の数を入力します。

4. 「OK」をクリックします。

10.2.1.3 「拡張検索」リンクの選択(「基本検索」および「カスタム検索」ポートレット)

通常、拡張検索では、追加の検索条件を指定できます。たとえば、図10-8を参照してください。

図10-8 「基本検索」および「カスタム検索」ポートレット上の「拡張検索」リンク

「拡張検索」リンクは、外部サイト、別のポータル・ページ、またはOracle Portal内のパッケージ・コールへリンクできます。

拡張検索リンクは「基本検索」ポートレットに表示されます。オプションとして、このリンクを「カスタム検索」ポートレットに表示できます。「カスタム検索」ポートレットのオプションを設定する方法の詳細は、OTN(http://www.oracle.com/technology/products/ias/portal/documentation.html)から入手できる『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

すべての「基本/カスタム検索」ポートレット・インスタンスに対して、「拡張検索リンク」のリンク先を指定できます。新しい「拡張検索リンク」を指定すると、拡張検索リンクが表示される新規および既存の検索ポートレットの両方に適用されます。

拡張検索リンクの詳細を入力するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「検索」タブをクリックします。

3. 「拡張検索リンク」セクションで、次のいずれかを実行します。

- 「拡張検索」のリンク先の「ページ名」を指定します。
デフォルトは「拡張検索ページ」です。このページには、Oracle Portalに付属している「拡張検索」ポートレットがあります。このページとして、拡張検索のオプションを表示する任意のポータル・ページを選択でき、そのページにはOracle Portalの検索ポートレットを配置する必要はありません。たとえば、使用しているPortal内にJSPページがある場合は、拡張検索のオプションを持つJSPページを使用できます。

選択したページが後で削除されると、このフィールドは空になります。別のページを選択し、「OK」をクリックします。「取消」をクリックしても、すべての「拡張検索」リンクは削除されたページを指定したままになります。

- 「拡張検索」リンクの「URL」を指定します。
使用するURLを入力します。ポータル全体で拡張検索に使用するカスタマイズした検索エンジンを作成した場合は、ここにそのリンクを指定できます。

絶対URLまたは相対URLを指定できます。たとえば、http://www.myfavoritesearchengine.comを指定すると、このインターネット検索サイトへのリンクが直接作成されます。

相対URL(つまり、ポータル・パッケージ)を入力する場合は、ここで指定した値はOracle PortalスキーマURLに追加されるため、その結果、ポータル・パッケージがコールされます。指定した値が/で始まるかどうかによって、次のように値が追加されます。

/で始まる場合、このURLは、http://<webserver>:<port>//<PORTALSCHEMA>.my_search_package.my_search_method>のようになります。

値のみを指定する場合、このURLは、http://<webserver>:<port>/portal/pls/<dad>//<PORTALSCHEMA>.my_search_package.my_search_methodのようになります。

4. 「OK」を選択します。

注意:

ページ・キャッシュが有効になっている場合でも、既存の検索ポートレットに変更がすぐに表示されないことがあります。すべての検索ポートレットのキャッシュは、24時間ごとに自動的に消去されます。これらのキャッシュは、Oracle Fusion Middleware Controlの「Webキャッシュ管理」ページから手動で消去することもできます。第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

10.2.1.4 インターネット検索エンジンの選択(「拡張検索」および「カスタム検索」ポートレット)

インターネット検索エンジン・リンクは「拡張検索」ポートレットに表示されます。したがって、ユーザーがOracle Portalを検索したときに必要な情報を見つけることができなかった場合は、インターネット検索エンジンを使用して検索対象を広げることができます。図10-9を参照してください。

図10-9 「拡張検索」および「カスタム検索」ポートレット上の「インターネット検索エンジン」リンク

オプションとして、このリンクを「カスタム検索」ポートレットに表示できます。「カスタム検索」ポートレットのオプションを設定する方法の詳細は、OTN(http://www.oracle.com/technology/products/ias/portal/documentation.html)から入手できる『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

インターネット検索エンジンのURL、およびユーザーがインターネット検索エンジンにアクセスするためにクリックするリンク・テキストを指定すると、インターネット検索リンクを表示するすべての新規および既存の拡張/「カスタム検索」ポートレット・インスタンスに適用されます。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「検索」タブをクリックします。

3. 「インターネット検索エンジン」セクションの「URL」に、インターネット検索エンジンのURLを入力します。たとえば、「http://www.myinternetsearch.com」と入力します。
URLは、完全な形式である必要があります。http://と関連パラメータをすべて含んでいる必要があります。

4. 「リンク・テキスト」に、指定したインターネット検索エンジンにアクセスするためのテキストを入力します。たとえば、「MySearch」などです。
「MySearch」と入力した場合は、「拡張検索」ポートレット、またはオプションで「カスタム検索」ポートレットにリンクとしてこのテキストが表示されます。図10-9を参照してください。

5. 「OK」を選択します。

インターネット検索エンジンのプロパティ(URLとリンク・テキスト)を指定しない場合は、「拡張検索」または「カスタム検索」ポートレットにもインターネット検索エンジンへのリンクは表示されません。

注意:

ページ・キャッシュが有効になっている場合でも、既存の検索ポートレットに変更がすぐに表示されないことがあります。すべての検索ポートレットのキャッシュは、24時間ごとに自動的に消去されます。これらのキャッシュは、Fusion Middleware Controlの「Webキャッシュ管理」ページから手動で消去することもできます。第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

10.2.2 Oracle PortalでのOracle Textオプションの検索

この項ではOracle Portalで次のOracle Text機能を構成する方法について説明します。

- Oracle PortalでのOracle Textの有効化と無効化

- Oracle Text検索結果オプションの設定

- Oracle TextのベースURLの設定

- Oracle Textのプロキシ設定の構成

注意:

ページ・キャッシュが有効になっている場合でも、既存の検索ポートレットにOracle Text設定への変更がすぐに表示されないことがあります。すべての検索ポートレットのキャッシュは、24時間ごとに自動的に消去されます。これらのキャッシュは、Fusion Middleware Controlの「Webキャッシュ管理」ページから手動で消去することもできます。第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

Oracle Text、Oracle Text索引の管理方法およびトラブルシューティングの情報の詳細は、第10.3項「Oracle Text」を参照してください。

10.2.2.1 Oracle PortalでのOracle Textの有効化と無効化

Oracle Textを使用することで、Oracle Portalの検索機能が拡張されます。第10.1.1項「Oracle Portalの検索」を参照してください。アウト・オブ・ボックスのOracle Textは常に有効化されています。Oracle Textを無効化することはお薦めしませんが、ポータルでOracle Portalリポジトリ・コンテンツの全テキストの索引作成を必要としない場合やそのメリットがない場合は、Oracle Textを無効にできます。第10.2.2.1項「Oracle PortalでのOracle Textの有効化と無効化」も参照してください。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「検索」タブをクリックします。

3. Oracle Textを使用するには、Oracle Portalを検索するときに「Oracle Text検索を使用可能にする」を選択します。
Oracle Textを無効にするには、このオプションを選択解除します。

注意:

「Oracle Textはインストールされていません」というメッセージが表示される場合は、Oracle Textがデータベースにインストールされていないので、Oracle Portalでは使用できません。Oracle Textをインストールするようデータベース管理者に依頼してください。インストールしたら、SQL*Plusで次のコマンドを実行して、Oracle Textロールを作成する必要があります。

inctxgrn.sql

このファイルは、ORACLE_HOME/portal/admin/plsql/wwsディレクトリにあります。

PORTALスキーマのユーザー名とパスワードを使用してログインします。Oracle Text索引も作成する必要があります。詳細は、第10.3.4項「Oracle Text索引の作成および削除」を参照してください。

4. 「OK」をクリックします。

10.2.2.2 Oracle Text検索結果オプションの設定

Oracle Textを有効にすると、検索結果として返されるアイテム(ドキュメントやファイル)とともに追加の情報を表示できます。返される各アイテムに対して、次を表示できます。

- 主要なテーマがグラフに表示されます。テーマは、最も頻繁に使用されている名詞と動詞を示します。

- コンテンツに関する簡単なサマリー(要旨)が表示されます。要旨は、そのコンテンツの名詞と動詞の使用頻度に基づいて生成されます。

- HTML形式。

- HTML形式のファイル。検索文字列を特定の色またはフォントで強調します。

テーマおよび要旨はオプションであり、HTMLの強調は次のようにカスタマイズできます。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「検索」タブをクリックします。

3. 「テーマと要旨を使用可能にする」を選択して、検索によってアイテムが返されるたびにテーマと要旨を作成します。

注意:

テーマと要旨を利用できない言語があります。

4. 「テキストの色を強調」には、検索によって返されるアイテムをHTML形式で表示するときに、検索文字列を強調する色を選択します。

5. 「テキストのスタイルを強調」には、検索によって返されるアイテムをHTML形式で表示するときに、検索文字列に適用するスタイルを選択します。

6. 「OK」をクリックします。

10.2.2.3 Oracle TextのベースURLの設定

Oracle Textは、相対URLを完全修飾された絶対URLに解決するためにベースURLを必要とします。詳細は、第10.3.6.1項「相対URL」を参照してください。

Oracle TextのベースURLを指定するには、次の手順を実行します。

1. 「サービス」ポートレットで、「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。

2. 「検索」タブをクリックします。

3. http://<host>:<port>/portal/pls/<dad>という書式で、「Oracle TextのベースURL」を入力します。
たとえば、http://myportal.com:4000/portal/pls/designのようになります。

値を指定しない場合は、どの相対URLにも索引が作成されないので、相対URLが指すURLコンテンツは検索できません。

4. 「OK」をクリックします。

10.2.2.4 Oracle Textのプロキシ設定の構成

Oracle Textでは、Oracle Portalのプロキシ・サーバーの設定を使用してURLコンテンツにアクセスします。これは、Oracle Portalがファイアウォールの内側にあり、かつURLアイテムがこのファイアウォール外を指定している場合に必要となります。詳細は、第10.3.6.4項「URLの索引のプロキシ設定」を参照してください。

Oracle Portalのグローバル・プロキシ設定を構成する方法の詳細は、第6.5項「プロキシ・サーバーを使用するためのOracle Portalの構成」を参照してください。

10.2.3 Oracle PortalでのOracle Secure Enterprise Searchオプションの構成

第10.4項「Oracle Secure Enterprise Search」を参照してください。

10.3 Oracle Text

Oracle Textは、Oracle Databaseに強力なテキスト検索とインテリジェントなテキスト管理を追加します。Oracle Portalは、Oracle Textの機能を使用して検索機能を拡張しています。

アウト・オブ・ボックスのOracle Textは常に有効化されています。ただし、Oracle PortalでOracle Textを使用する機能はオプションであり、ポータル管理者が無効にできます。詳細は、第10.3.1項「Oracle Textを有効または無効にした場合のOracle Portal検索の理解」を参照してください。

Oracle PortalでOracle Textを使用する方法について、次の項で説明します。

- Oracle Textを有効または無効にした場合のOracle Portal検索の理解

- Oracle Textの前提条件

- Oracle Text索引

- Oracle Text索引の作成および削除

- Oracle Text索引の管理

- URLコンテンツの索引作成と検索

- ドキュメント索引およびURL索引の作成の無効化

- Oracle Text索引のステータスの表示

- Oracle Textの索引作成処理の監視

- 索引作成エラーの表示

- 索引作成エラーのOracle Portal内のオブジェクトへの変換

- 一般的な索引作成エラー

- ハングまたはクラッシュする索引作成への対処方法

詳細は、OTN(http://www.oracle.com/technology/)から入手できるOracle Textのドキュメントを参照してください。

10.3.1 Oracle Textを有効または無効にした場合のOracle Portal検索の理解

アウト・オブ・ボックスのOracle Textは常に有効化されています。Oracle Textを無効化することはお薦めしませんが、ポータルでOracle Portalリポジトリ・コンテンツの全テキストの索引作成を必要としない場合やそのメリットがない場合は、Oracle Textを無効にできます。

Oracle Textを無効にする手順の詳細は、第10.2.2.1項「Oracle PortalでのOracle Textの有効化と無効化」を参照してください。

10.3.1.1 Oracle Textを無効にした検索

Oracle Textが無効のときに基本検索を実行(検索文字列のみを入力)する場合、次のメタデータが検索されます。

- アイテム属性(表示名、説明、キーワード、作成者)

- ページ属性(表示名、説明、キーワード)

- カテゴリおよびパースペクティブ属性(表示名、説明)

基本検索では、カスタム属性が検索されません。

検索演算子「すべての語を含む」を使用して複数の検索文字列を指定した場合は、それらすべての文字列が同じ属性内に出現する場合にのみ一致となります。たとえば、weights aerobicsと入力した場合、これら2つの文字列が、両方とも1つの属性(説明など)内で検出された場合にのみ検索結果が返されます。文字列weightsが説明内に見つかり、aerobicsが表示名内に見つかった場合は、一致となりません。

また、Oracle Textを無効にすると、使用できる検索演算子が限られます。主な検索文字列では、「すべての語を含む」、「いずれかの語を含む」、「これらの語に完全一致する」という3つの検索演算子しか使用できなくなります。さらに、属性検索で使用できる演算子も限られます。

選択した属性に対して条件を指定する検索(拡張検索)では、選択した属性が照合されます。拡張検索フォームでは、ファイルベースまたはURLベースの属性(URLやファイル名などの生成された属性を含む)は表示されません。Oracle Textを無効にした場合、これらの属性は検索できないためです。同様に、「カスタム検索」ポートレットを編集するページ設計者は、ファイルベースおよびURLベースの属性を検索条件として選択できなくなります。Oracle Textが無効になる前に、検索ポートレットでファイルベースまたはURLベースの属性を指定した場合、Oracle Textが無効になると、それらの属性がグレーのイタリック体で表示されます。

10.3.1.2 Oracle Textを有効にした検索

基本検索を実行するときにOracle Textが有効になっている場合は、カスタム・テキスト属性を含むすべてのテキスト・タイプの属性が検索されます。さらに、ファイルおよびURLアイテムのコンテンツが検索されます。

バイナリ形式のドキュメントとファイルおよびURLアイテムは、Oracle Textで絞込みできるファイル形式であれば検索できます。また、コンテンツがプレーン・テキストまたはHTMLであれば、URL (URL属性で指定)のリンク先であるWebページも検索できます。詳細は、第10.3.3.1項「Oracle Text索引の概要」を参照してください。

10.3.2 Oracle Textの前提条件

Oracle Textは、Oracle Database 11gの標準コンポーネントです。Oracle PortalでOracle Textの機能を使用する場合は、Oracle Textコンポーネントが正しくインストールされ、正常に機能していることが不可欠です。

次のことを確認します。

- Oracle TextがOracle Portalリポジトリ・データベースにインストールされています。Oracle Portalリポジトリ・データベースにOracle Textのコンポーネントがないと、Oracle Portalリポジトリをインストールできません。これは、Oracle Portalパッケージの中には、Oracle Textコンポーネントが存在するCTXSYSスキーマのctx_ddlパッケージを参照するものがあるからです。

- Oracle Textのアップグレードが完了しています。特に、データベースのアップグレード時には、Oracle Textに関係する手動の手順が正常に完了していることが不可欠です。

- Oracle Text AUTO_FILTERのライブラリ・パスが正しく設定されています。AUTO_FILTERが正常に機能するには、ctxhx実行可能ファイル(索引作成時にコールされる)で適切な共有ライブラリをロードできる必要があります。第10.3.3.1項「Oracle Text索引の概要」も参照してください。

- UNIXプラットフォームの場合は、TNSリスナーとデータベースが起動する環境の両方で、ldが使用するライブラリ・パスにORACLE_HOME/ctx/libを指定しておく必要があります。様々なUNIXプラットフォームに対するライブラリ・パスの環境変数は、次のとおりです。
Solaris、Tru64 UNIX、Linux → $LD_LIBRARY_PATH

HP/UX → $SHLIB_PATHおよび$LD_LIBRARY_PATH

IBM AIX → $LIBPATH

詳細は、OTN(http://www.oracle.com/technology/documentation/)から入手できるOracle Textリファレンスを参照してください。

Oracle Textの索引作成処理を機能させるには、ライブラリ・パスを変更するたびに、データベースとリスナーの両方を再起動する必要があります。どちらかまたは両方の環境変数が設定されていない場合は、予想どおりに文書に索引が作成されず、表ctx_user_index_errorsに、DRG-11207、ステータス137エラーが多数表示されることがあります。第10.3.12.1項「一般的なドキュメント索引作成エラー」も参照してください。

- Windowsプラットフォームでは、適切なOracle TextのDLLが、ORACLE_HOME\binに存在します。このパスが環境変数PATHに含まれる、つまりOracleサーバーが起動される環境にあることを確認します。

10.3.3 Oracle Text索引

Oracle PortalでOracle Textの機能を使用する場合は、Oracle PortalスキーマにいくつかのOracle Text索引が必要になります。これらの索引の詳細は、次の項で説明します。

- Oracle Text索引の概要

- Oracle Text索引の設定

- データストア・プロシージャ

- Oracle PortalスキーマへのCTXAPPロールの付与

- 多言語機能(マルチレクサー)

- STEM検索

- AUTO_FILTERパフォーマンスの最大化

10.3.3.1 Oracle Text索引の概要

必要なOracle Text索引はすべて、パッケージwwv_contextに含まれるプロシージャによってOracle Portalのインストール時に自動的に作成されます。

関連項目:

付録D「wwv_context APIの使用」

ポータルのインストール後は、このパッケージ内のプロシージャを、索引の削除や再作成などの索引管理に使用できます。詳細は、第10.3.4.3項「ctxdrind.sqlを使用したすべてのOracle Text索引の削除」および第10.3.4.1項「ctxcrind.sqlを使用したすべてのOracle Text索引の作成」を参照してください。

注意:

Oracle Text索引が存在するときでも、Oracle Textを無効にできます。第10.2.2.1項「Oracle PortalでのOracle Textの有効化と無効化」を参照してください。

表10-3で、必要なOracle Text索引について説明します。

表10-3 Oracle Portalスキーマに含まれるOracle Text索引

索引

Table.column

用途

データストア・タイプ

フィルタ・
タイプ

オプションか

WWSBR_CORNER_CTX_INDX

wwpob_page$.ctxtxt

ページ・メタデータの索引作成

ユーザー・データストア

-

いいえ

WWSBR_DOC_CTX_INDX

wwdoc_document$.
blob_content

ドキュメント・コンテンツの索引作成

直接データストア

AUTO_FILTER

はい

WWSBR_PERSP_CTX_INDX

wwv_perspectives.
ctxtxt

パースペクティブ・メタデータの索引作成

ユーザー・データストア

-

いいえ

WWSBR_THING_CTX_INDX

wwv_things.ctxtxt

アイテム・メタデータの索引作成

ユーザー・データストア

-

いいえ

WWSBR_TOPIC_CTX_INDX

wwv_topics.ctxtxt

カテゴリ・メタデータの索引作成

ユーザー・データストア

-

いいえ

WWSBR_URL_CTX_INDX

wwsbr_url$.absolute_url

URLコンテンツの索引作成

URLデータストア

AUTO_FILTER

はい

ほとんどのOracle Text索引では、ユーザー・データストアを使用します。例外は、索引WWSBR_DOC_CTX_INDX(ドキュメント索引)およびWWSBR_URL_CTX_INDX (URL索引)です。

- ドキュメント索引: 直接データストアを使用します。つまり、wwdoc_document$表のBLOBタイプblob_contentの列に直接保持されるドキュメント・コンテンツに索引を作成します。

- URL索引: absolute_url列が指す場所から、wwsbr_url$表の行ごとに索引の作成対象とするコンテンツを取り出します。

ドキュメント索引とURL索引の作成は、無効にできます。無効にすることで、検索対象がアイテム、ページ、カテゴリおよびパースペクティブのメタデータのみに限定されるため、ポータル検索の速度と効率性が向上します。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」を参照してください。

ドキュメント索引とURL索引はどちらもフィルタ(AUTO_FILTER)を使用して、ドキュメントを索引作成に適したプレーン・テキスト形式に変換します。

- バイナリ・ドキュメントは、プレーン・テキストに変換されます(そのバイナリ形式がAUTO_FILTERでサポートされている場合)。

- プレーン・テキスト、HTML、XHTML、SGMLおよびXMLドキュメントでは、フィルタが使用されずに索引が直接作成されます。

- グラフィックのような、索引を作成する必要がないドキュメントはフィルタで無視されます。

第10.3.3.7項「AUTO_FILTERパフォーマンスの最大化」も参照してください。

注意:

Oracle Portalが機能的なAUTO_FILTERの存在しないデータベースにインストールされている場合、ドキュメントおよびURL検索は、AUTO_FILTERなしでは機能しないことから、自動的に無効化されます。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」も参照してください。

10.3.3.2 Oracle Text索引の設定

Oracle Textでは、設定を使用してOracle Portal向けのOracle Text索引を構成します。これらの設定は、Oracle Portalのスキーマで作成し、そのスキーマで所有します。つまり、設定はCTXSYSスキーマに存在するctx_ddlパッケージを使用して作成され、設定を表すデータは実際にはCTXSYSスキーマ内のリレーショナル表に格納されます。

Oracle Text索引の設定は、索引が作成される前に作成する必要があります。その後の設定に対する変更は、Oracle Text索引を削除して再作成しないと、有効になりません。

Oracle Text索引を作成するためにOracle Portalのインストール時に使用されるOracle Text索引の設定は、パッケージwwv_contextを使用して再作成できます。一部のOracle Text索引の設定は、インストール後にポータル管理者が構成することもできます。たとえば、グローバルOracle Portalのプロキシ設定値は、Oracle TextがOracle Text索引で使用するプロキシ設定の移入に使用されます。

関連項目:

付録D「wwv_context APIの使用」

Oracle Text索引は、索引作成の言語面を制御するためにいくつかのレクサー・プリファレンスも使用します。レクサー・プリファレンスは、スクリプトsbrimtlx.sqlによって作成されます。このスクリプトは、レクサー・プリファレンスを再作成するときにいつでも実行できます。このスクリプトは、ORACLE_HOME/portal/admin/plsql/wwsディレクトリにあります。

詳細は、OTN(http://www.oracle.com/technology/)にあるOracle Textのドキュメントを参照してください。

10.3.3.3 データストア・プロシージャ

Oracle9i Database Serverでは、ユーザー・データストアを使用するOracle Text索引ごとに、Oracle TextがインストールされているCTXSYSスキーマにデータストア・プロシージャが作成されます。特定の索引が作成される各行に対し、このプロシージャがコールされます。これらのプロシージャが、次にOracle Portalスキーマのプロシージャをコールします。

データストア・プロシージャには、次のように名前を付けます。

- WWSBR_THING_CTX_<user_id>

- WWSBR_CORNER_CTX_<user_id>

- WWSBR_PERSP_CTX_<user_id>

- WWSBR_TOPIC_CTX_<user_id>

<user_id>は、Oracle Portalリポジトリのスキーマのuser_id (ALL_USERSビューに表示される)です。同じデータベースに複数のOracle Portalリポジトリが存在する場合は、プロシージャ名が重複することがないようにこの接尾辞が必要です。

なんらかの理由によりこれらのプロシージャが存在しない場合は、Oracle Textは機能しません。これは、たとえば、CTXSYSスキーマが削除され、再インストールされた場合に発生することがあります。この場合は、Oracle Portalスキーマの所有者として、次のようにスクリプトinctxgrn.sqlを実行することによりプロシージャを再インストールできます。

SQL> @inctxgrn.sql

また、このスクリプトは、CTXAPPロールをOracle Portalスキーマに付与します。詳細は、第10.3.3.4項「Oracle PortalスキーマへのCTXAPPロールの付与」を参照してください。このスクリプトは、ORACLE_HOME/portal/admin/plsql/wwsディレクトリにあります。

Oracle Database 11gでは、データストア・プロシージャはCTXSYSスキーマ内に作成されません。このプロシージャは、索引を所有するスキーマ(Oracle Portalスキーマ)が所有します。その場合、これらのプロシージャはすべてパッケージwwsbr_ctx_procsの中にあります。

- wwsbr_ctx_procs.thing_ctx

- wwsbr_ctx_procs.corner_ctx

- wwsbr_ctx_procs.perspective_ctx

- wwsbr_ctx_procs.topic_ctx

プロシージャはOracle Portalスキーマの中にあるため、<user_id>接尾辞は必要ありません。

10.3.3.4 Oracle PortalスキーマへのCTXAPPロールの付与

Oracle Textの機能を使用するためには、CTXAPPロールがOracle Portalスキーマに付与されている必要があります。これは、Oracle Portalのインストール時に自動的に行われ、通常それ以上何も操作する必要はありません。

なんらかの理由によりこの付与が取り消された場合は、Oracle Textは機能しません。たとえば、これはCTXSYSスキーマが再インストールされたときにCTXAPPロールが削除されると、発生することがあります。

必要な付与を元に戻すには、Oracle Portalスキーマの所有者として次のようにスクリプトinctxgrn.sqlを実行します。

SQL> @inctxgrn.sql

このスクリプトは、ORACLE_HOME/portal/admin/plsql/wwsディレクトリにあります。このスクリプトは、CTXSYSスキーマで必要なOracle Portalユーザー・データストア・プロシージャも作成します。第10.3.3.3項「データストア・プロシージャ」を参照してください。

10.3.3.5 多言語機能(マルチレクサー)

Oracle Portalでは、Oracle Textのマルチレクサーを使用し、Oracle Portalで言語固有の検索ができます。マルチレクサーは、次のことを行います。

- 検索の言語面の実行方法を制御します。

- コンテンツ、アイテム、ページ、カテゴリ、パースペクティブ、およびこれらを翻訳したものが、各言語に適した方法で処理されるようにします。

レクサー・プリファレンスは、すべてのOracle Text索引で使用されるマルチレクサーの構成に使用されます。レクサー・プリファレンスは、スクリプト・ファイルsbrimtlx.sqlによって作成されます。このスクリプトは、ORACLE_HOME\portal\admin\plsql\wwsディレクトリにあります。必要に応じてこれらの設定を変更できますが、変更後は変更を有効にするために、Oracle Text索引をいったん削除してから再作成する必要があります。

マルチレクサーの詳細は、OTN(http://www.oracle.com/technology/)にあるOracle Textのドキュメントを参照してください。

10.3.3.6 STEM検索

Oracle PortalでOracle Textが有効になっているときは、STEM検索がデフォルトで使用されます。STEM検索を使用すると、指定した文字列と同じ語根を持つ語を検索できます。たとえば、語幹の$singを入力すると、語sang、sung、singにまで問合せが拡張されます。

ただし、STEM検索が使用されるのは、Oracle TextでSTEM検索がサポートされている次のいずれかの言語を使用しているOracle Portalにログインしたときだけです。

AMERICAN ENGLISH
CANADIAN FRENCH
DUTCH
UK ENGLISH
FRENCH
GERMAN DIN
GERMAN
ITALIAN
LATIN AMERICAN SPANISH
MEXICAN SPANISH
SPANISH

その他の言語では、STEM演算子は使用されません。

10.3.3.7 AUTO_FILTERパフォーマンスの最大化

AUTO_FILTERは、PDFドキュメントなどのほとんどのドキュメント形式を、索引に適したプレーン・テキスト形式に変換できる汎用的なフィルタです。Oracle Portalでは、ドキュメント索引とURL索引でのみAUTO_FILTERが使用されます。

索引作成のプロセスでは、AUTO_FILTERによって、ドキュメントとURLコンテンツが次のAUTO_FILTER_FORMAT設定に従って変換されます。

- BINARY - これらのドキュメントは、プレーン・テキストに変換されます(そのバイナリ形式がAUTO_FILTERでサポートされている場合)。

- TEXT - これらのドキュメントでは、AUTO_FILTERが使用されずに索引が直接作成されます。たとえば、プレーン・テキスト、HTML、XHTML、SGML、XMLドキュメントなどがあります。

- IGNORE - イメージなどのドキュメントでは、絞込みや索引作成が行われません。

コンテンツを不必要に絞り込むと、ポータル検索の速度と効率性に悪影響を与えるため、絞込み処理を最適化することが重要です。AUTO_FILTERを最適化する最善の方法は、ポータルにアップロードしたすべてのドキュメントおよびURLコンテンツを、正しいMIMEタイプと文字セットで分類しておくことです。

- MIMEタイプ - Oracle Portalでは、ドキュメントのMIMEタイプによって、AUTO_FILTER_FORMAT (AUTO_FILTERがドキュメントを絞り込むかどうかの判断に使用する設定)が決まります。たとえば、MIMEタイプのアプリケーションやPDFでアップロードされたドキュメントは、BINARYにマッピングされた後で絞込みが行われます。一方、MIMEタイプのテキストやHTMLでアップロードされたドキュメントは、TEXTにマッピングされ、索引が直接作成されます。MIMEタイプのイメージやGIFでアップロードされた他のドキュメントは、IGNOREにマッピングされます。

- 文字セット - AUTO_FILTERは、ドキュメント内のデータベースにない文字セットをデータベース用の文字セットに変換できます。これにより、他の文字セットでドキュメントの索引作成および検索を行えます。AUTO_FILTERが文字セットを判別できない場合、またはその文字セットがサポートされていない場合、文字セット変換なしでドキュメントの索引作成が行われます。

AUTO_FILTER_FORMATマッピングを判別するために、ポータルにコンテンツがアップロードされたときにブラウザは次のマッピング・シーケンスを使用します。

ファイル

- (割り当てるブラウザによって、またはMimetype属性を使用して指定するユーザーによって)MIMEタイプが指定されている場合、このMIMEタイプは、AUTO_FILTER_FORMATへのマッピングに使用されます(wwdav$mime表を使用)。

- MIMEタイプが表に存在しない場合には、AUTO_FILTER_FORMATの検索にファイル拡張子が使用されます。

- ファイル拡張子が、定義された拡張子のいずれとも一致しない場合には、ドキュメント索引用のデフォルトのAUTO_FILTER_FORMATが使用されます。

URL

- ユーザーがMimetype属性を使用してMIMEタイプを指定した場合、このMIMEタイプは、AUTO_FILTER_FORMATへのマッピングに使用されます(wwdav$mime表を使用)。

- MIMEタイプが表に存在せず、URLにファイル拡張子がある場合、AUTO_FILTER_FORMATの検索にファイル拡張子が使用されます。たとえば、URLがPDFファイルを指している場合、AUTO_FILTER_FORMATはBINARYに設定されます。

- 拡張子がいずれとも一致しない場合には、URL索引用のデフォルトのAUTO_FILTER_FORMATが使用されます。

Oracle Portalでは、すべてのポータル・コンテンツの分類と絞込みが正常に行われるように、ファイルベースとURLベースのアイテム・タイプにMIMEタイプおよび文字セットという、2つの特別な属性が用意されています。これらの属性が含まれるように組込みのベース・ファイルとベースURLアイテム・タイプを拡張することによって、ポータル・コンテンツのアップロード時に正しい情報を入力できます。

注意:

MIMEタイプや文字セット属性によって、正しいMIMEタイプおよび文字セットをファイルベースとURLベースのアイテムに指定することは可能ですが、これらをファイルとURLの属性に指定することはできません。

- ファイル属性 - ブラウザが常にMIMEタイプを判別します。

- URL属性 - MIMEタイプはtext/htmlであるため、AUTO_FILTERは常にURL属性をプレーン・テキストとして処理します。

使用しているポータルでポータル検索の速度や効率性が重視されている場合や、データベースにない文字セットを使用するドキュメントをポータルで保存または参照する場合は、使用するファイルベースおよびURLベースのアイテム・タイプすべてにMIMEタイプおよび文字セットの属性を追加することを、そのページ・グループの管理者に依頼してください。『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』のアイテム・タイプへの属性の追加に関する項も参照してください。

注意:

MIMEタイプや文字セットでポータル・コンテンツを検索する場合、対応する属性(MIMEタイプまたは文字セット)を含むアイテム・タイプに基づくコンテンツのみが見つかります。

詳細は、OTN(http://www.oracle.com/technology/)にあるOracle Textのドキュメントを参照してください。

10.3.4 Oracle Text索引の作成および削除

必要なすべてのOracle Text索引は、Oracle Portalリポジトリのインストール時に自動的に作成されます。ただし、後で索引を削除すると、再作成する必要がある場合があります。

索引の作成および削除は大量の時間とリソースを消費する操作であるため、業務時間中を避けてこの作業を計画するようにしてください。また、Oracle Text索引を削除して再作成すると、ポータルの検索機能が低下する場合があります。これは、検索機能が正常に機能するにはすべての索引が存在し、有効である必要があるためです。索引を削除すると、検索を有効にしていても、オプションの検索演算子や特別な検索結果属性などのOracle Text機能が一時的に利用できなくなります。これは、この作業を業務時間中を避けて計画することを推奨する別の理由です。

注意:

Oracle Text索引を削除または作成してもOracle Web Cacheは無効になりません。そのため、自動的に公開された検索結果や既存の検索フォームは、キャッシュで期限切れになるか、他のユーザーが「デフォルトの編集」ページを使用して検索ポートレットを編集するまで表示されます。

次の各項で、Oracle Text索引を作成および削除する方法について説明します。

- ctxcrind.sqlを使用したすべてのOracle Text索引の作成

- 1つのOracle Text索引の作成

- ctxdrind.sqlを使用したすべてのOracle Text索引の削除

- 1つのOracle Text索引の削除

10.3.4.1 ctxcrind.sqlを使用したすべてのOracle Text索引の作成

Oracle Portalに付属するスクリプトおよびパッケージを使用してすべてのOracle Text索引を再作成できます。Oracle Text索引を作成するための主なスクリプトはctxcrind.sqlで、これはディレクトリORACLE_HOME/portal/admin/plsql/wwsにあります。

Oracle Portalリポジトリのスキーマの所有者として、スクリプトctxcrind.sqlを実行すると、次のようになります。

- 必要なすべてのOracle Text索引および設定が作成されます。第10.3.3項「Oracle Text索引」も参照してください。

- 既存のOracle Text索引がある場合は、すべての既存の設定および有効な索引が削除され、再作成されます。索引は、次の場合に有効であるとみなされます。

- 関連する索引のビューuser_indexes内の行のindex_status、domidx_statusおよびdomidx_opstatusがすべて'VALID'に設定されています。

- 索引には、ctx_user_indexesに、idx_statusが'INDEXED'に設定されたエントリがあります。

- 存在しない索引も作成されます。

この処理は、数時間を要することがあります。

スクリプトctxcrind.sqlを使用してOracle Text索引を作成するには:

1. ORACLE_HOME/portal/admin/plsql/wwsディレクトリに移動します。

2. SQL*Plusで、PORTALスキーマのユーザー名とパスワードを使用してログインします。

3. SQL*Plusで、次のコマンドを入力します。

ctxcrind.sql

処理が正常に終了すると、すべてのOracle Text索引および設定がOracle Portalリポジトリのスキーマに作成されます。処理に失敗する場合は、システムがすべての要件を満たしているかどうかを確認します。第10.3.2項「Oracle Textの前提条件」を参照してください。

注意:

Oracle Text索引の作成に要する時間は、ポータルに存在するアイテムおよびページ・グループの数によって変わります。

スクリプトctxcrind.sqlは、次のプロシージャをコールします。

wwv_context.createindex( p_message => l_message );

p_messageは、完了メッセージを渡すoutパラメータです。コールwwv_context.createindex()は、次のようになります。

wwv_context.drop_prefs;  /* Drop all Oracle Text preferences for the indexes, except Lexer preferences */
wwv_context.drop_invalid_indexes; /* Drop all invalid indexes */
wwv_context.create_prefs; /* Create all Oracle Text preferences,except Lexer preferences */
wwv_context.create_missing_indexes(l_indexes);  /* Create missing indexes and record them in l_indexes */
wwv_context.touch_index(l_indexes); /* Mark all rows for created indexes as requiring synchronization */
wwv_context.sync;     /* Synchronize indexes */
wwv_context.optimize; /* Optimize indexes */

関連項目:

付録D「wwv_context APIの使用」

10.3.4.2 1つのOracle Text索引の作成

特定の索引を作成する場合は、プロシージャwwv_context.create_index(p_index)を使用します。付録D「create_index」も参照してください。

p_indexを使用して、作成する索引を指定します。次のいずれかを選択できます。

wwv_context.PAGE_TEXT_INDEX
wwv_context.DOC_TEXT_INDEX
wwv_context.PERSPECTIVE_TEXT_INDEX
wwv_context.ITEM_TEXT_INDEX
wwv_context.CATEGORY_TEXT_INDEX
wwv_context.URL_TEXT_INDEX

このプロシージャは、空の索引を作成します。空の索引からは検索結果を返すことができないため、索引にデータを移入する必要もあります。更新のために索引をマークする方法および索引を同期化する方法の詳細は、第10.3.5.6項「すべての索引のコンテンツの同期化」を参照してください。

10.3.4.3 ctxdrind.sqlを使用したすべてのOracle Text索引の削除

スクリプトctxdrind.sqlを使用して、すべてのOracle Text索引および設定(レクサー・プリファレンスを除く)を削除できます。このスクリプトは、ORACLE_HOME/portal/admin/plsql/wwsディレクトリにあります。

スクリプトctxdrind.sqlを使用してすべてのOracle Text索引を削除するには:

1. ORACLE_HOME/portal/admin/plsql/wwsディレクトリに移動します。

2. SQL*Plusで、PORTALスキーマのユーザー名とパスワードを使用してログインします。

3. SQL*Plusで、次のコマンドを入力します。

ctxdrind.sql

このスクリプトは、次のプロシージャをコールします。

wwv_context.dropindex(p_message  =>l_message);

p_messageは、完了メッセージを渡すoutパラメータです。

注意:

Oracle Text索引を削除すると、索引が作成されていた表を参照するビューとパッケージは無効になります。

これらのビューとパッケージは、次にアクセスされたときに自動的に有効になります。ビューとパッケージは、手動で有効にすることもできます。

10.3.4.4 1つのOracle Text索引の削除

特定のOracle Text索引を削除するとします。たとえば、別のプロキシ設定で再作成できるようにするためにURL索引を削除し、その他のすべての索引は削除も再作成もしない場合などです。

これを行うには、次のコマンドを使用して索引を直接削除します。

SQL> drop index <index_name> force;

たとえば、URL索引を削除するには、次のように入力します。

SQL> drop index WWSBR_URL_CTX_INDX force;

また、wwv_context.drop_indexを使用して索引を削除することもできます。

SQL>exec wwv_context.drop_index('<index_name>');

付録D「drop_index」も参照してください。

10.3.5 Oracle Text索引の管理

正確な検索結果をポータルから効率的に得るには、Oracle Text索引を適切に管理することが重要です。Oracle Text索引を管理している場合は、索引の同期化と最適化を検討する必要があります。

- 同期化: キューに基づいてOracle Text索引を更新します。

- 最適化: 断片化された行を圧縮し、Oracle Text索引に含まれる古いデータを削除します。索引を同期化すると、必要以上に多くのディスク容量を消費するようになり、問合せの効率が低下します。

Oracle Textを使用すると、各索引が同期化および最適化される頻度を完全に制御できます。同期化の詳細は、次を参照してください。

- Oracle Text索引の同期化

- Oracle Text索引のコミット時の同期化

- すべてのOracle Text索引の手動による同期化

- 索引の同期化のスケジューリング

- Oracle Text索引の同期化の頻度の決定

- すべての索引のコンテンツの同期化

最適化の詳細は、次を参照してください。

- Oracle Text索引の最適化

- 索引の最適化のスケジューリング

- 最適化の間隔の選択

10.3.5.1 Oracle Text索引の同期化

新しいコンテンツ(アイテム、ページ、カテゴリ、パースペクティブ)をポータルに追加した場合は、そのコンテンツに索引を作成しないと検索結果として得ることができません。また、表の中で索引を作成済の行の内容を変更すると、その行は同期化が必要であるとマークされます。このような行は、保留状態の行と呼ばれ、索引を同期化しないと検索結果として返されません。

ビューctx_user_pendingで、どの行が保留状態であるとマークされているかを確認できます。また、スクリプトtextstat.sqlを使用して、索引ごとに同期化する必要のある行数を確認できます。第10.3.8項「Oracle Text索引のステータスの表示」も参照してください。

インストール時にはOracle Textの索引が作成されて同期化されますが、すべての索引はデフォルトで、wwv_context.syncをコールするジョブによって1時間おきに同期化されるようにスケジュールされます。使用しているポータルで1時間おきの同期化が不適切な場合は、デフォルトの同期化スケジュールを変更することができます。たとえば、テキスト変更をすぐに索引に反映させる必要がある場合は、5秒ごとに同期化するように選択できます。または、コンピュータの処理資源をより効率的に利用しながら、最適な索引を目指す場合は、1日に一度だけ同期化するように選択できます。第10.3.5.4項「索引の同期化のスケジューリング」を参照してください。

ポータル・コンテンツを追加、更新または削除した後、Oracle Text索引がすぐに同期化されるように指定できます。また、この指定は索引ごとに構成できます。Oracle Database 10gより前のバージョンではsyncプロパティがサポートされていないため、この機能はこれらのバージョンのデータベースでは使用できません。ページ、アイテム、カテゴリおよびパースペクティブの索引は、コミット時に同期化されるように構成することをお薦めします。この構成が原因で検索パフォーマンスが低下することはありません。ドキュメントとURLの索引もコミット時に同期化されるように構成できますが、その場合はポータル検索の速度と効率が低下する可能性があるので、その使用はポータルごとに評価する必要があります。表10-4に、Oracle Database 11gのOracle Text索引の推奨される同期化スケジュールを示します。

表10-4 Oracle Database 11gのOracle Text索引の推奨される同期化スケジュール

Oracle Text索引

Oracle Database 11gでの索引の同期化

ページ、アイテム、カテゴリ、パースペクティブ

コミットの直後、つまり、関連するポータル・オブジェクトが追加、変更または削除された後に同期化します。第10.3.5.2項「Oracle Text索引のコミット時の同期化」を参照してください。

ドキュメント、URL

wwv_context.syncをコールするジョブによって1時間おきに(または他の定期的な間隔で)同期化をスケジュールします。第10.3.5.4項「索引の同期化のスケジューリング」を参照してください。

次の項では、同期化オプションについて説明します。

- Oracle Text索引のコミット時の同期化

- すべてのOracle Text索引の手動による同期化

- 索引の同期化のスケジューリング

10.3.5.2 Oracle Text索引のコミット時の同期化

wwv_context.commit_sync()プロシージャを使用して、ポータルにデータがコミットされた直後にOracle Text索引を同期化するかどうかを指定できます。詳細は、付録D「commit_sync」も参照してください。

コミットしても、同期化が完了するまで何も返されません。同期化は別のトランザクションとして実行されるため、データがコミットされても、ある一定の期間(通常は、短時間)は索引の変更がコミットされない場合があります。この操作には、メモリー・パラメータで指定されたメモリーが使用されます。付録D「set_sync_memory」も参照してください。

注意:

この設定の現在のステータスを調べるには、textstat.sqlを使用します。詳細は、第10.3.8項「Oracle Text索引のステータスの表示」を参照してください。

コミット時におけるOracle Text索引の同期化の指定

wwv_context.commit_syncをOracle Portalスキーマの所有者としてSQL*Plusから、次のコマンドを使用して実行します。

exec wwv_context.commit_sync('<Index_name>', true);

手動によるOracle Text索引の同期化の指定

wwv_context.commit_syncをOracle Portalスキーマの所有者としてSQL*Plusから、次のコマンドを使用して実行します。

exec wwv_context.commit_sync('<Index_name>', false);

コミット時におけるOracle Text索引の同期化のステータス確認

wwv_context.get_commit_syncをOracle Portalスキーマの所有者としてSQL*Plusから、次のコマンドを使用して実行します。

set serveroutput on
begin
dbms_output.put_line(
case wwv_context.get_commit_sync('<index_name>')
when true then
'Index synchronizes automatically when data commits'
when false then
'Index needs to be synchronized manually'
end
);
end;

10.3.5.3 すべてのOracle Text索引の手動による同期化

wwv_context.sync()プロシージャを使用して、Oracle Text索引を手動で同期化します。このプロシージャは、すべての保留状態の行に索引を作成します。付録D「sync」も参照してください。

手動の同期化では、メモリー・サイズとパラレル同期も指定できます。付録D「set_parallel_degree」および付録D「set_sync_memory」も参照してください。

注意:

wwv_context.syncでは、データがコミットされた直後に同期化される索引(wwv_context.commit_syncがtrueに設定されている)は無視されます。

Oracle Text索引の手動による同期化

このプロシージャをOracle Portalスキーマの所有者としてSQL*Plusから、次のコマンドを使用して実行します。

exec wwv_context.sync();

次の構文を使用して、同期化の並列度を指定します。

exec wwv_context.set_parallel_degree('<index_name>', <parallel_degree>);

例:

exec wwv_context.set_parallel_degree('WWSBR_CORNER_CTX_INDX', 2);

次の構文を使用して、同期化のメモリー使用量を指定します。

exec wwv_context.set_sync_memory('<index_name>', <sync_memory);

例:

exec wwv_context.set_sync_memory('WWSBR_CORNER_CTX_INDX', 12582912);

このプロシージャは、すべての仮想プライベート・ポータルのサブスクライバ間で動作します。

10.3.5.4 索引の同期化のスケジューリング

ほとんどのインストールでは、新しく追加または更新したコンテンツに定期的に索引が作成されるように、索引の同期化を一定の間隔で自動的に実行するようにスケジュールする必要があります。textjsub.sqlスクリプトを使用して、ジョブをスケジュールできます。これには、dbms_jobを使用して、一定の間隔でwwv_context.syncをコールします。

このスクリプトは、次のように3つのパラメータをとり、同期化ジョブの変更または削除にも使用されます。

start_time        - a valid date or 'START' or 'STOP'
start_time_fmt    - start time format mask.
Ignored if start_time is 'START' or 'STOP'
interval_minutes  - minutes between each run. Ignored if 'STOP'

start_timeにSTARTを設定した場合、2番目の引数が無視され、次のジョブがただちに実行されるようにスケジュールされます。それ以降のジョブは、指定した間隔で実行されます。

start_timeにSTOPを設定する場合は、ジョブは削除され、その他の引数は無視されます。

Oracle Text索引の同期化のスケジュール

textjsub.sqlスクリプトを実行します。たとえば、索引の同期化を60分ごとにスケジュールするには、次のように入力します。

SQL> @textjsub.sql START NOW 60

10.3.5.5 Oracle Text索引の同期化の頻度の決定

索引の同期化ジョブの適切な間隔は、次の条件によって決まります。

- 新しいコンテンツがポータル・サイトに追加される頻度。

- 新しく追加または変更されたコンテンツがただちに検索可能にならないと問題になるかどうか。

- 追加または変更されたコンテンツが検索可能になるまでの期間はどの程度が妥当か。

要件によって、同期化の間隔は数分から数日になります。

少数の行の同期化を繰り返すよりも、多数の行の同期化を一度に行う方が、断片化された索引が少なくなるので効率的です。断片化された索引が少ない場合は、必要な最適化の頻度も少なくなります。詳細は、第10.3.5.7項「Oracle Text索引の最適化」を参照してください。

ただし、多数の行の索引を一度に同期化すると、サーバーに大きな負荷がかかります。同期化を頻繁に行うと、実行される作業量は増加しますが、サーバー上の負荷は分散されます。ジョブは、保留状態の行の同期化のみを行いますが、同期化ジョブを起動する際には、わずかでも常にオーバーヘッドがある程度発生します。

10.3.5.6 すべての索引のコンテンツの同期化

特定のOracle Text索引のすべての行を同期化が必要とマークして、その索引のすべてのコンテンツを同期化できます。

たとえば、索引は最初に作成された時点では空なので、索引のコンテンツ全体を更新する必要があります。このためには、索引を作成済の列について更新を実行する必要があります。表の中で索引を作成済のすべての行に対し、プロシージャwvv_context.touch_index(p_index)を使用して列を更新します。

このプロシージャの実行後、表ctx_user_index_pendingには、索引が作成された表の行ごとにエントリが作成されています。

このプロシージャは、すべての仮想プライベート・ポータルのサブスクライバ間で動作します。

索引のすべてのコンテンツの同期化

プロシージャwvv_context.touch_index(p_index)を使用します。p_indexを使用して、次の索引名のいずれか1つを指定できます。

wwv_context.PAGE_TEXT_INDEX
wwv_context.DOC_TEXT_INDEX
wwv_context.PERSPECTIVE_TEXT_INDEX
wwv_context.ITEM_TEXT_INDEX
wwv_context.CATEGPRY_TEXT_INDEX
wwv_context.URL_TEXT_INDEX

複数の索引のすべてのコンテンツの同期化

プロシージャwvv_context.touch_index(p_indexes)を使用します。p_indexesを使用して、同期化する索引名の可変配列(wwsbr_array)を指定できます。

10.3.5.7 Oracle Text索引の最適化

Oracle Text索引を同期化すると、それらが断片化されます。各Oracle Text索引は逆索引であり、逆索引では検索文字列は検索が効率的に行えるような形式になっています。各検索文字列は、文字列の場所を参照します。

同期化時に新しい検索文字列が追加される場合、重複する文字列は削除されないため、索引に同じ文字列が複数個含まれる場合があります。これにより索引のサイズが大きくなり、検索問合せのパフォーマンスが低下します。

これを解決するには、Oracle Text索引を最適化します。この処理は、索引を圧縮し、必要に応じて古いデータを削除します。

すべてのOracle Text索引の最適化

すべてのOracle Text索引を最適化するには、プロシージャwwv_context.optimize()を使用します。付録D「optimize」も参照してください。

このプロシージャは、次のパラメータをとります。

wwv_context.optimize
(
p_optlevel in varchar2 default CTX_DDL.OPTLEVEL_FULL, -- FULL, FAST, TOKEN
p_maxtime in number default null,  -- Maximum time for full optimization, in minutes
p_token in varchar2 default null -- Token to optimize (when TOKEN)
);

内部的に、このプロシージャはOracle Text索引ごとにOracle Textプロシージャのctx_ddl.optimize_indexをコールし、これらのパラメータを渡します。高速最適化やトークンの最適化とは異なり、すべての索引が最適化されます。

詳細は、OTN(http://www.oracle.com/technology/)にあるOracle Textのドキュメントを参照してください。

注意:

Oracle Text索引が存在しない場合は、プロシージャwwv_context.optimizeは無効です。

wwv_context.optimizeは、Oracle Text索引がかなり断片化されて最適化が必要な場合にのみ、Oracle Text索引を最適化します。使用される断片化の評価基準は、1つのトークンが索引に複数回現れる平均回数です。この平均が11以上の場合は、索引の最適化が必要とみなされます。次の断片化の問合せを使用します。

SELECT AVG(COUNT(*)) FROM DR$<index_name>$I
GROUP BY TOKEN_TEXT HAVING COUNT(*) > 1

<index_name>は、評価される索引の名前です。

10.3.5.8 索引の最適化のスケジューリング

ほとんどのインストールでは、索引の最適化プロセスを一定の間隔で自動的に実行するようにスケジュールする必要があります。スクリプトoptjsub.sqlを使用して、ジョブをスケジュールできます。これには、dbms_jobを使用して、一定の間隔でwwv_context.optimizeをコールします。

このスクリプトoptjsub.sqlは、次のように3つのパラメータをとり、最適化ジョブの変更または削除にも使用されます。

start_time       - A valid date or 'START' or 'STOP'
start_time_fmt   - Start time format mask.
Ignored if start_time is 'START' or 'STOP'
interval_minutes - Minutes between each run. Ignored if 'STOP'

start_timeに'START'を設定した場合、2番目の引数が無視され、次のジョブがただちに実行されるようにスケジュールされます。それ以降のジョブは、指定した間隔で実行されます。

start_timeに'STOP'を設定する場合は、ジョブは削除され、その他の引数は無視されます。

Oracle Portalのインストール時に、24時間ごとにすべてのOracle Text索引を最適化するためのジョブが設定されます。

Oracle Text索引の最適化のスケジュール

スクリプトoptjsub.sqlを実行します。たとえば、索引の最適化を60分ごとにスケジュールするには、次のように入力します。

SQL> @optjsub.sql START NOW 60

このスクリプトは、ORACLE_HOME/portal/admin/plsql/wwsディレクトリにあります。この最適化ジョブの実行時にOracle Text索引がない場合は、このプロシージャは無効です。

10.3.5.9 最適化の間隔の選択

Oracle Text索引に必要な最適化の頻度は、ロードするコンテンツの量や種類、同期化のスケジュールなどの多くの要因に依存するので予測は困難です。

ただし、一定の間隔で索引の断片化を評価する場合は、索引の断片化の速度を確認できます。この情報を使用して、適切な最適化の間隔を設定できます。

プロシージャwwv_context.optimizeでは、索引が断片化されているとみなされた場合にのみ、索引を最適化します。したがって、このジョブをコールする際の最小のオーバーヘッド以外は、必要以上にこのジョブを実行しても問題はありません。

Oracle Portalのインストール時に、24時間ごとにすべてのOracle Text索引を最適化するためのジョブが設定されます。

10.3.6 URLコンテンツの索引作成と検索

Oracle PortalでOracle Textが有効な場合、アイテムまたはページにアタッチされたURL属性のコンテンツにデフォルトで索引が作成されます。索引作成には、ページ上のポートレット・コンテンツが含まれないことに注意してください。URLコンテンツに索引が作成されると、検索可能になります。URL属性の検索条件を入力すると、そのURLコンテンツが検索されます。

注意:

ポータル・ユーザーにURLコンテンツの検索を許可しない場合は、URL索引を無効にできます。詳細は、第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」を参照してください。

10.3.6.1 相対URL

Oracle Portalでは、URL属性の相対URLを入力できます。相対URLがポータル・ページでリンクとして表示されるときには、URLはポータル・ページのHTMLの<head>セクションに設定されたベースHREFに対して相対的です。ベースHREFの書式は次のとおりです。

<protocol>://<server>:<port>/portal/pls/<dad>/

たとえば、HTMLの<head>セクションに、次のようなURLが指定されたとします。

<base href="http://myserver.abc.com/portal/pls/portal/">

この例では、次のようになります。

- 相対URLの/help/index.htmlは、ブラウザにより次のように解決されます。
http://myserver.abc.com/help/index.html

- 相対URLの!PORTAL.mypackage.proc(先行の/なし)は、ブラウザにより次のように解決されます。
http://myserver.abc.com/portal/pls/portal/!PORTAL.mypackage.proc

ページ上のベースHREFは、ページをリクエストするのに使用されるURLによって変わります。ページにアクセスするために複数のURLを使用することが可能なので、ベースHREFはページにアクセスするために使用されたURLを反映します。

Oracle TextのベースURLの設定

URLコンテンツに索引を作成する場合、Oracle Textでは相対URLを完全修飾された絶対URLに解決する方法を知る必要があります。Oracle Textには、正しいベースHREFを判断するための最初のリクエストのコンテキストがわからないため、使用するベースHREFを指定する必要があります。「グローバル設定: 検索」ページで「Oracle TextのベースURL」プロパティを指定して、このオプションを設定します。詳細は、第10.2.2.3項「Oracle TextのベースURLの設定」を参照してください。

Oracle Portalのインストール時に、このオプションは自動的に設定されます。

Oracle TextのベースURLの書式は次のとおりです。

<protocol>://<server>:<port>/portal/pls/<dad>/

たとえば、http://myserver.abc.com/portal/pls/portal/のようになります。

注意:

HTTPS URLには、Oracle Textで索引が作成されないので、httpsで始まるOracle TextベースURLを指定しないでください。入力すると、どの相対URLにも索引は作成されません。

Oracle TextベースURLを変更しても、その場では有効になりません。編集したURLは同期化が必要とマークされ、索引を次回同期化したときにOracle Textで新しい設定が使用されます。すべてのURLで新しいOracle TextベースURL値をすぐに使用する場合は、次のプロシージャを使用して、URL索引のコンテンツ全体に同期化が必要とマークします。

SQL> wwv_context.touch_index(wwv_context.URL_TEXT_INDEX);

このプロシージャは、すべてのサブスクライバ間で有効です。1つの仮想プライベート・ポータル・サブスクライバでは、これは次のものに相当します。

SQL> update wwsbr_url$ set absolute_url = null;
...
SQL> commit;

10.3.6.2 サポートされていないURL

Oracle Text索引は、次のプロトコルを使用するURLには作成できません。

- https

- javascript

URLアイテムがこれらのプロトコルのいずれかを指定する場合は、それには索引は作成されません。対応するエラーは、Oracle Textのエラー・ログには記録されません。

10.3.6.3 サポートされているURL

Oracle Text索引は、次のプロトコルを使用するURLに作成できます。

- http

- file - ファイルURLは、データベース・サーバーからアクセス可能である必要があります。

- ftp - FTP URLでは、匿名ユーザーでも、Oracle Textは認証を行えないので、認証を必要としない場所を指定する必要があります。

10.3.6.4 URLの索引のプロキシ設定

URLのコンテンツに索引を作成すると、Oracle Textではプロキシ・サーバーを使用してURLにアクセスできます。これは、Oracle Portalがファイアウォールの内側にあり、かつURLがこのファイアウォールの外側を指す場合に必要となります。索引の作成は、Oracle Portalリポジトリ・サーバーから行われるため、重要なのはこのコンピュータに必要なプロキシ設定です。

URL索引では、Oracle Portalにグローバルに使用されるものと同じプロキシ設定を使用します。これらは「プロキシ設定」ページで設定し、「サービス」ポートレットから使用できます。詳細は、第10.2.2.4項「Oracle Textのプロキシ設定の構成」を参照してください。

プロキシ設定は、Oracle Text索引が作成されるときに使用されます。したがって、プロキシ設定を変更する場合は、索引を再作成する必要があります。すべての索引を削除し、再作成する必要がある場合は、スクリプトのctxdrind.sql(索引の削除)およびctxcrind.sql(索引の作成)を使用します。詳細は、第10.3.4項「Oracle Text索引の作成および削除」を参照してください。

SQL> @ctxdrind.sql
...
SQL> @ctxcrind.sql
...

これらのスクリプトは、すべての索引をいったん削除してから再作成するので、大規模な索引では処理に時間がかかることがあります。代替策として、次のようにOracle Textの設定とURL索引のみを削除してから再作成することもできます。

begin
-- Drop and re-create the Oracle Text preferences
-- to pick up the new proxy settings.
wwv_context.drop_prefs();
wwv_context.create_prefs();
end;
/
-- Check that the proxy settings used by the index are correct
select prv_attribute attribute, prv_value value
from ctx_user_preference_values
where prv_attribute in ('TIMEOUT','HTTP_PROXY','NO_PROXY')
/

begin
-- Drop and re-create the URL index
wwv_context.drop_index(wwv_context.URL_TEXT_INDEX);
wwv_context.create_index(wwv_context.URL_TEXT_INDEX);

-- Mark all of the rows for the index as pending
wwv_context.touch_index(wwv_context.URL_TEXT_INDEX);

-- Syncronize and optimize
wwv_context.sync();
wwv_context.optimize();
end;
/

10.3.7 ドキュメント索引およびURL索引の作成の無効化

デフォルトでは、Oracle Portalリポジトリにアップロードされたファイルのコンテンツと、URLアイテムまたはカスタムURL属性で参照されるコンテンツに索引が作成されます。これにより、ドキュメントとURLコンテンツで文字列を検索および検出できるため、通常はこの設定の方が適切です。

ポータル・ユーザーがファイルおよびURLコンテンツ内で検索を実行する必要がない場合は、これらのドキュメントおよびURLの索引を無効にできます。無効にすると、検索対象は、アイテム、ページ、カテゴリおよびパースペクティブのメタデータ(タイトル、作成者、キーワード、説明、更新日と、すべてのカスタム・テキスト、ブールおよび日付属性を含む)に限定されます。メタデータ限定の検索は、効率的であるため、ファイルとURLコンテンツを含む検索よりも高速です。

注意:

機能的なAUTO_FILTERが存在しないデータベースにOracle Portalリポジトリをインストールすると、ドキュメントおよびURLの検索は、AUTO_FILTERなしでは機能しないことから、自動的に無効になります。

次のプロシージャを使用して、ドキュメントおよびURLの索引が必要かどうかを指定します。

- set_use_doc_index

- set_use_url_index

これらのプロシージャは両方とも、パッケージwwv_contextの中にあります。詳細は、付録D「wwv_context APIの使用」を参照してください。

ドキュメント索引とURL索引を無効にする場合、(通常は失われたOracle Text索引を作成する)ctxcrind.sqlスクリプトを使用して、必要ではなくなった既存のドキュメント索引とURL索引を削除します。ドキュメント索引とURL索引を削除しない場合でも、それらの索引は、同期化ジョブや最適化ジョブの実行時に更新されます。したがって、ctxcrind.sqlを実行して未使用の索引を削除するほうが効率的です。第10.3.4項「Oracle Text索引の作成および削除」を参照してください。

ドキュメントおよびURLの索引設定を変更すると、Oracle Portalの検索ポートレットの外観と動作が影響を受けます。ポートレットをキャッシュしている場合、この変更は即座に反映されない場合があります。そのため、索引になんらかの変更を加えた後は、ポータルのキャッシュを手動で消去する必要があります。第6.7.4.4項「特定ポータル・オブジェクトのキャッシュの消去」を参照してください。

たとえば、ドキュメント索引を無効にすると、検索ポートレットでは、使用できるファイルベース属性の検索演算子が少なくなります。つまり、「ファイル名の中のすべてに一致」と「ファイル名の中のいずれかに一致」のみが表示されます。同様に、URL索引を無効にすると、URLベース属性に使用できる演算子は、「URLの中のすべてに一致」と「URLの中のいずれかに一致」のみになります。これらの索引を無効にすると、ファイルおよびURLコンテンツは検索不可能になるため、他の検索演算子(「コンテンツにすべてが含まれる」など)は表示されなくなります。

ドキュメント索引を無効にすると、テーマ、要旨およびHTMLとして表示の各機能は使用できなくなるため、「グローバル設定: 検索」ページでテーマと要旨を無効にする必要があります。詳細は、第10.2.2.2項「Oracle Text検索結果オプションの設定」を参照してください。

ドキュメント索引とURL索引の有効と無効を切り替えるには:

次のプロシージャを使用します。

-- To enable the document index
execute wwv_context.set_use_doc_index(true);
-- To disable the document index
execute wwv_context.set_use_doc_index(false);
-- To enable the URL index
execute wwv_context.set_use_url_index(true);
-- To disable the URL index
execute wwv_context.set_use_url_index(false);

10.3.8 Oracle Text索引のステータスの表示

ポータル・スキーマからアクセスできるいくつかの表およびビューで、Oracle Text索引のステータスを確認できます。

Oracle Text索引のステータス・レポートを表示するには、ポータル・スキーマの所有者としてtextstat.sqlスクリプトを実行します。

SQL> @textstat.sql

このスクリプトは、ORACLE_HOME/portal/admin/plsql/wwsディレクトリにあります。このスクリプトによって生成される情報の例を次に示します。

SQL> @textstat
Portal Text Indexes:

INDEX_NAME            STATUS   DOMIDX_STATUS DOMIDX_OPSTATUS IDX_STATUS
--------------------- -------- ------------- --------------- ------------
WWSBR_CORNER_CTX_INDX VALID    VALID         VALID           INDEXED
WWSBR_DOC_CTX_INDX    VALID    VALID         VALID           INDEXED
WWSBR_PERSP_CTX_INDX  VALID    VALID         VALID           INDEXED
WWSBR_THING_CTX_INDX  VALID    VALID         VALID           INDEXED
WWSBR_TOPIC_CTX_INDX  VALID    VALID         VALID           INDEXED
WWSBR_URL_CTX_INDX    VALID    VALID         VALID           INDEXED

Document and URL index preferences:
Document Index: true  - index will be used if valid
URL Index:      true  - index will be used if valid

Indexes with rows waiting to be indexed:

Index                     Rows to Index
-----------------------   -------------
WWSBR_CORNER_CTX_INDX        2677

PL/SQL procedure successfully completed.

Scheduled Text Jobs:

LAST_DATE LAST_SEC  NEXT_DATE NEXT_SEC  B  FAILURES INTERVAL            WHAT
--------- --------- --------- ---------- - ------ -------------------------
25-AUG-05 04:57:32  26-AUG-05 04:57:32  N   0     SYSDATE + 24/24 wwsbr_stats.gather_stale;
25-AUG-05 04:57:32  26-AUG-05 04:57:32  N   0     SYSDATE + 1440/(24*60) wwv_context.optimize(CTX_DDL.OPTLEVEL_FULL,1440,null);
25-AUG-05 06:59:30  25-AUG-05 07:59:30  N   0     SYSDATE + 60/(24*60)  wwv_context.sync;

Running Text Jobs:
no rows selected

Indexes sync on commit setting:
Item Index:        true    - Index will sync automatically when data commits
Page Index:        true    - Index will sync automatically when data commits
Document Index:    false   - Index needs to be syncronized manually
Category Index:    true    - Index will sync automatically when data commits
Perspective Index: true    - Index will sync automatically when data commits
URL Index:         false   - Index needs to be syncronized manually

SQL>

このスクリプトから、次の情報を表示できます。

- Portalテキスト索引のステータス - すべてのOracle Text索引が存在するかどうか、およびそれらの現在のステータスが表示されます。この例で示したように、最初の3つのステータスの列では、機能する有効な索引に対してはすべてVALIDが表示され、最後の列にはINDEXEDが表示されています。第10.3.3.1項「Oracle Text索引の概要」も参照してください。

- ドキュメントおよびURL索引のステータス - ドキュメント索引とURL索引が有効(true)であるか無効(false)であるかが表示されます。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」も参照してください。

- 索引ごとの保留中の行数 - 索引作成を待機中の索引が表示されます。索引作成を待機中、または保留中の行がある索引ごとにエントリが表示されます。保留状態の行の数も表示されます。第10.3.5.1項「Oracle Text索引の同期化」も参照してください。

- スケジュールされたOracle Textのジョブの詳細 - 索引の管理のためにスケジュールされているジョブが表示されます。このレポートには、ジョブが最後に実行された日時とジョブが次回実行される予定の日が表示されます。Bの列は、ジョブが壊れたかどうかを示します。壊れた場合はYとマークされ、実行されません。Interval列は、次回ジョブが実行される時刻を示し、最後にWhat列は各ジョブに対して実行されるプロシージャを示します。第10.3.5.4項「索引の同期化のスケジューリング」も参照してください。

- アクティブなOracle Textジョブの詳細 - textstat.sqlレポートが実行されたときに、実行されていたジョブの詳細が表示されます。

- コミット時の索引の同期化の設定 - このセクションには、ポータルでデータがコミットされた直後に同期化を実行するように構成されている索引、およびwwv_context.syncを使用して手動で(またはジョブを使用して)同期化する必要がある索引が表示されます。第10.3.5.2項「Oracle Text索引のコミット時の同期化」も参照してください。
以前のバージョンのデータベースでは、次の情報が表示されます。

Indexes sync on commit setting:
...Not available for this database version, available from 10g onwards.

10.3.9 Oracle Textの索引作成処理の監視

Oracle Textは、索引が作成され値が入力されると、ファイルにログ情報を記録します。これにより、索引作成処理の進捗状況を監視し、索引を追跡し、発生する可能性のある問題のトラブルシューティングを行うことができるようになります。

10.3.9.1 start_logを使用した索引処理の監視

ctx_output.start_log (filename)コマンドを使用して、索引作成プロセスからの出力をログに記録できます。次の例では、ログ・ファイルの名前はtextindex.logとなっています。

ctx_output.start_log('textindex.log');
ctx_output.add_event(ctx_output.event_index_print_rowid);
...
-- Create or syncronize the indexes
...
ctx_output.end_log;

ログ・ファイルの場所は、ctx_adm.set_parameterのLOG_DIRECTORYパラメータを使用して指定できます。この例では、/tmpを指定します。いったんディレクトリを設定すると、それ以降のすべてのOracle Textのログはこのディレクトリに出力されます。

ctxsys.ctx_adm.set_parameter('LOG_DIRECTORY', '/tmp');

10.3.9.2 logcrind.sqlを使用した索引作成の監視

スクリプトlogcrind.sql (ctxcrind.sqlのかわり)を使用すると、ログを有効にしてOracle Text索引を作成できます。このスクリプトは、ログ・ファイルの名前であるパラメータを1つとります。例:

SQL> @logcrind.sql textindex.log

このスクリプトは、LOG_DIRECTORYを、user_dump_dest初期化パラメータで指定された、データベースudumpディレクトリと同じになるように設定します。

add_eventコール(前述の例で使用されている)は、スクリプトlogcrind.sqlでも使用され、これは索引が作成されたすべての行の行IDをログに出力します。このログは、索引作成処理の追跡を可能にし、各行の索引作成が正常に行われたかどうかも示します。

次にのOracle Text索引作成ログの例を示します。

13:53:27 05/06/03 begin logging
13:53:27 05/06/03 event
13:53:42 05/06/03 log
13:53:42 05/06/03 event
13:53:48 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_CORNER_CTX_INDX$X"
13:53:48 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_CORNER_CTX_INDX$X" created
13:53:49 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_DOC_CTX_INDX$X"
13:53:49 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_DOC_CTX_INDX$X" created
13:53:49 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_PERSP_CTX_INDX$X"
13:53:49 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_PERSP_CTX_INDX$X" created
13:53:50 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_THING_CTX_INDX$X"
13:53:50 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_THING_CTX_INDX$X" created
13:53:51 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_TOPIC_CTX_INDX$X"
13:53:51 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_TOPIC_CTX_INDX$X" created
13:53:51 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_URL_CTX_INDX$X"
13:53:51 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_URL_CTX_INDX$X" created
13:54:16 05/06/03 sync index: MYPORTAL.WWSBR_CORNER_CTX_INDX
13:54:17 05/06/03 Begin document indexing
13:54:17 05/06/03 INDEXING ROWID AAAUUcAAJAAAlhMAAA
13:54:17 05/06/03 INDEXING ROWID AAAUUcAAJAAAlhMAAI
..
13:54:18 05/06/03 INDEXING ROWID AAAUUcAAJAAAlhQAAk
13:54:18 05/06/03 Errors reading documents: 0
13:54:18 05/06/03 Index data for 159 documents to be written to database
13:54:18 05/06/03    memory use: 225971
13:54:18 05/06/03 Begin sorting the inverted list.
13:54:18 05/06/03 End sorting the inverted list.
13:54:18 05/06/03 Writing index data to database.
13:54:18 05/06/03    index data written to database.
13:54:18 05/06/03 End of document indexing. 159 documents indexed.

10.3.10 索引作成エラーの表示

索引の作成時または同期化時に発生したエラーは、ビューCTX_USER_INDEX_ERRORSに記録されます。次のコマンドを使用して、それらのエラーの詳細を表示できます。

SQL> desc ctx_user_index_errors;
Name                   Null?    Type
---------------------- -------- ---------------
ERR_INDEX_NAME         NOT NULL VARCHAR2(30)
ERR_TIMESTAMP                   DATE
ERR_TEXTKEY                     VARCHAR2(18)
ERR_TEXT                        VARCHAR2(4000)

SQL>

このビューには、索引名、索引が作成された表内の行に対応する行ID (ERR_TEXTKEY列)、および失敗の原因を示すエラー・メッセージが表示されます。また、エラー・ログ・ファイルには、索引が作成された表内の行の行IDと成功または失敗メッセージが表示されます。

通常、アイテム(WWSBR_THING_CTX_INDX)、ページ(WWSBR_CORNER_CTX_INDX)、カテゴリ(WWSBR_TOPIC_CTX_INDX)またはパースペクティブ(WWSBR_PERSP_CTX_INDX)の索引のエラーは表示されません。これは、Oracle Portalとこれらのコンテンツが生成する索引のコンテンツに対する索引の作成が容易なためです。ドキュメントやURLコンテンツの索引を作成するときのほうがエラーが頻繁に発生します。

ドキュメント索引の場合、コンテンツの絞込みを行いバイナリの文書をプレーン・テキストに変換して、索引を作成することが必要な場合があります。これが失敗する理由がいくつかあります。たとえば、ドキュメントの書式がOracle TextのフィルタであるAUTO_FILTERでサポートされていない場合などです。第10.3.3.7項「AUTO_FILTERパフォーマンスの最大化」も参照してください。

URL索引の場合、URLコンテンツを取り出す必要があり、これがいくつかの理由で失敗することがあります。たとえば、Oracle Portalサーバーがファイアウォールの内側にあるためにアクセスできない場所がURLで指定され、かつプロキシ設定が正しく設定されていない場合などです。または、URLが誤っているか、アクセス対象のサイトが停止している場合などです。

また、URLのコンテンツが絞り込まれるときにエラーが発生する場合があります。たとえば、すべてのURL属性はプレーン・テキストであると想定されるため、プレーン・テキストでないURL属性が存在する場合はエラーが発生します。

10.3.11 索引作成エラーのOracle Portal内のオブジェクトへの変換

ビューCTX_USER_INDEX_ERRORSまたはOracle Text索引作成ログに表示される索引作成のエラーは、エラーが発生したときに索引が作成されていた表内の行IDを示します。この情報を使用して索引作成の問題が発生している行を特定し、またこの行に対応するポータル・アイテムまたはページも特定できます。

次の項では、索引作成の問題の原因を特定する必要がある場合に役立つ問合せについて説明します。

- アイテムの索引作成エラー

- ページの索引作成エラー

- カテゴリ索引エラー

- パースペクティブの索引作成のエラー

- ドキュメント索引エラー

- URL索引エラー

10.3.11.1 アイテムの索引作成エラー

行IDは、問題が発生したアイテム表内の行を示します。直接の問合せを実行して、その行についてさらに情報を得ることができます。例:

select i.name, i.title,          -- item title
p.name page_name,         -- page name
p.title page_title,       -- page display name
pg.name page_group,       -- page group name
sl.title page_group_title -- page group display name (default language)
from wwv_things i,
wwpob_page$ p,
wwpob_item$ pi,
wwsbr_sites$ pg,
wwsbr_site_languages$ sl
where i.masterthingid = pi.master_thing_id
and i.siteid = pi.site_id
and pi.page_id = p.id
and sl.siteid = pg.id
and sl.language = pg.defaultlanguage
and pi.page_site_id = p.siteid
and pg.id = i.siteid
and i.rowid = 'AAAOwMAAJAAAWISAAF

10.3.11.2 ページの索引作成エラー

行IDは、ページ表内の行を示します。直接の問合せを実行して、索引が作成されていたページについてさらに情報を得ることができます。例:

select p.name page_name,
p.title page_title,
pg.name page_group,
sl.title page_group_title
from wwpob_page$ p,
wwsbr_sites$ pg,
wwsbr_site_languages$ sl
where sl.siteid = pg.id
and sl.language = pg.defaultlanguage
and pg.id = p.siteid
and p.rowid = 'AAAOv/AAJAAAaSSAAB'

10.3.11.3 カテゴリ索引エラー

カテゴリ表に対して直接の問合せを実行して、問題のカテゴリを特定できます。結合を使用して、ページ・グループを表示することもできます。この問合せは、カテゴリ名と表示名、そしてページ・グループ名と表示名を表示します。

select c.title, c.name, pg.name, sl.title
from wwv_topics c,
wwsbr_sites$ pg,
wwsbr_site_languages$ sl
where sl.siteid = pg.id
and sl.language = pg.defaultlanguage
and pg.id = c.siteid
and rowid='AAAOv/AAJAAAaSSAAB'

10.3.11.4 パースペクティブの索引作成エラー

カテゴリの場合と同様です。パースペクティブ表に対して直接の問合せを実行すると、問題のパースぺクティブがわかります。結合を使用して、ページ・グループを表示することもできます。

select p.title, p.name, pg.name, sl.title
from wwv_perspectives p,
wwsbr_sites$ pg,
wwsbr_site_languages$ sl
where sl.siteid = pg.id
and sl.language = pg.defaultlanguage
and pg.id = p.siteid
and p.rowid = 'AAAOv/AAJAAAaSSAAB'

10.3.11.5 ドキュメント索引エラー

ドキュメント索引でエラーが頻繁に発生することがあります。この場合、索引はドキュメントが実際に格納された表にあります。したがって、アイテム表に結合しなおして、関連するアイテムを特定する必要があります。

次の問合せは、ドキュメントの問合せに関連するドキュメントのファイル名、アイテムの名前および表示名を返します。

select d.filename, i.name, i.title  from wwv_things i,
wwdoc_document$ d,
wwv_docinfo di
where
d.name = di.name(+)
and di.thingid = i.id(+)
and di.masterthingid = i.masterthingid(+)
and di.siteid = i.siteid(+)
and d.rowid = 'AAAOYyAAJAAAWAaAAF'

すべてのドキュメントがアイテムと関連付けられるとはかぎらないので、この場合同様の方法でページ表に結合するように問合せを変更する必要があります。

10.3.11.6 URL索引エラー

ドキュメント索引同様、関連するアイテムを特定するためにアイテム表に結合しなおす必要があります。

次の問合せは、URL、およびアイテム名と表示名を表示します。

select u.url, u.absolute_url, i.name, i.title
from wwv_things i,
wwsbr_url$ u
where u.object_id = i.id
and u.object_siteid = i.siteid
and u.object_type = 'ITEM'
and u.rowid = 'AAAOYyAAKAAAWAaAAB'

URLはアイテムに関連付けられているとはかぎらず、ページに関連付けられていることもあり、その場合同様にページ表に結合するように問合せを変更する必要があります。

10.3.12 一般的な索引作成エラー

次の項では、一般的な索引作成エラーについて説明します。

- 一般的なドキュメント索引作成エラー

- 一般的なURL索引作成エラー

10.3.12.1 一般的なドキュメント索引作成エラー

通常、ドキュメント索引作成エラーは次の書式になります。

DRG-11207: user filter command exited with status n

問題の原因は実際の終了ステータスで示されます。一般的な終了ステータスの値とその意味の説明は、Oracle Metalink (http://metalink.oracle.com)にログオンし、記事「Troubleshooting DRG-11207 errors」を参照してください。この記事のIDはDocId 210319.1です。

10.3.12.2 一般的なURL索引作成エラー

ここでは、いくつかの一般的なURL索引作成エラーを示します。このリストには、すべてのエラーが含まれているわけではなく、よく発生する一般的なエラーの一部に焦点を当てています。

DRG-11604 URL store: access to %(1)s is denied

索引作成ユーザー・エージェントがドキュメントへのアクセスを拒否されました。クローラは、サイトから返されたCookieの認証や管理を行うことができません。そのURLにアクセスできるかどうかを確認します。それが保護されている場合は、そのコンテンツに索引作成できない可能性があります。

DRG-11609 URL store: unable to open local file specified by %(1)s
DRG-11610 URL store: unable to read local file specified by %(1)s

これらは、ファイル:// URLのファイルを開いたり読み取ったりすることができない場合に発生します。Oracle Portalリポジトリ・データベースが稼働しているコンピュータからファイルにアクセスできる必要があります。ファイルが存在し、データベース・ユーザーとしてデータベース・コンピュータからアクセスできるかどうかを確認します。

DRG-11611 URL store: unknown protocol specified in %1)s

URLに指定されたプロトコルが、Oracle Textユーザー・エージェントが認識できるものではありません。プロトコルを指定しない場合にこれが発生します。この問題の一般的な原因は、相対URLが指定されているが、「Oracle TextのベースURL」オプションに完全に修飾されたURLが設定されていないということです。また、Oracle Textは、http、fileおよびftpのURLにのみ索引を作成できます。失敗したURLを調べて、有効なプロトコルが使用され、サポートされている完全に修飾された書式になっていることを確認します。第10.3.6項「URLコンテンツの索引作成と検索」も参照してください。

DRG-11612 URL store: unknown host specified in %(1)s

URLが、Oracle Portalリポジトリ・データベース・サーバーから解決できないホストをURLに指定しました。Oracle Portalリポジトリ・サーバーとURLで指定された場所の間にファイアウォールが存在する可能性があります。この場合、プロキシ・サーバーを使用してURLにアクセスする必要がある可能性があります。URLが正しく、かつホストがOracle Portalデータベース・サーバーからアクセスできることを確認します。また、Oracle Portalのプロキシ設定が正しく、かつ索引がそのプロキシ設定を使用していることを確認します。第10.2.2.4項「Oracle Textのプロキシ設定の構成」も参照してください。

DRG-11613 URL store: connection refused to host specified by %(1)s

これは、URLに指定されたホストが解決されたが、HTTPリクエストが拒否されたことを意味します。URLが正しく、かつアクセス可能であることを確認します。

DRG-11614 URL store: communication with host specified in %(1)s timed out

リクエストがタイムアウトになりました。URLが正しく、かつアクセス可能であることを確認します。

DRG-11616 URL store: too many redirections trying to access %(1)s

1つのURLにアクセスすると、別のURLへリダイレクトされる場合があります。これによりさらにリダイレクトが行われ、リダイレクトが続いていくことがあります。発生するリダイレクトの数が多い場合は、このエラーが表示されます。これは、リダイレクトのループが検出されると発生します。

DRG-11622 URL store: unknown HTTP error getting %(1)s

Oracle Textによって明示的に処理されないHTTPエラーが発生しました。このHTTPエラーは、エラー・メッセージで報告されます。

10.3.13 ハングまたはクラッシュする索引作成への対処方法

なんらかの理由でドキュメントまたはURLの索引が作成できない場合は、エラーがログに記録されます。この場合、索引作成処理の正常な完了が妨げられることはありません。ただし、索引作成に失敗したコンテンツは検索できません。

索引作成処理が完全に失敗になる場合があります。この場合、索引に値が適切に移入される前に、索引作成処理が終了します。そのような問題が発生した場合には、オラクル社カスタマ・サポート・センターに報告してください。ただし、場合によっては、失敗の原因になるコンテンツを除外することによって、一時的に問題を回避できます。詳細は、第10.3.13.2項「索引のハングおよびクラッシュの防止」を参照してください。

まれに、索引作成処理により、致命的な失敗が発生することがあります。つまり、索引作成を実行しているサーバー・プロセスが終了する場合です。これが発生すると、次のメッセージが索引作成処理を実行しているクライアントに表示されます。

ORA-03113 End of file on communication channel

注意:

索引作成処理が正常に完了したかどうかが不明な場合は、end of fileエラーが明確に報告されるSQL Plusから処理を繰り返します。

サーバー・プロセスが終了した場合は、このイベントがデータベース・ログに記録されるはずです。データベース・アラート・ログを使用し、作成されたトレース・ファイルの場所を特定します。トレース・ファイルは、ORA-0600またはORA-7445などのエラーを示します。たとえば、このトレース・ファイルは、スクリプトlogcrind.sqlを使用してOracle Text索引を作成するときに発生するエラーを示します。

ksedmp: internal or fatal error
ORA-7445: exception encountered: core dump [drsfdatam()+308] [SIGSEGV]
[Address not mapped to object] [0x0] [
] []
Current SQL statement for this session:
declare
l_dump_dest varchar2(512);
p_logfile varchar2(100) := 'sync_2012.log';
begin
dbms_output.enable(10000);
select value into l_dump_dest from v$parameter
where name = 'user_dump_dest';
ctxsys.ctx_adm.set_parameter('LOG_DIRECTORY',l_dump_dest);
ctx_output.start_log(p_logfile);
ctx_output.add_event(ctx_output.event_index_print_rowid);
dbms_output.put_line('Log file is: '||ctx_output.logfilename);
wwv_context.sync();
ctx_output.end_log;
end;
----- PL/SQL Call Stack -----
object line object
handle number name
8198f83c 244 package body CTXSYS.DRIDISP
8198f83c 377 package body CTXSYS.DRIDISP
8198f83c 334 package body CTXSYS.DRIDISP
8178acc8 403 package body CTXSYS.DRIDML
827124b0 2033 package body CTXSYS.DRIDDL
827124b0 2090 package body CTXSYS.DRIDDL
817ea0f0 1324 package body CTXSYS.CTX_DDL
8185a488 828 package body TOOLS.WWV_CONTEXT
82d83ed8 18 anonymous block
----- Call Stack Trace -----

10.3.13.1 索引処理がハングしているかどうかの特定

索引作成処理がハングしているかどうかを特定する最も簡単な方法は、Oracle Textのログを有効にして索引作成処理を実行することです。第10.3.9項「Oracle Textの索引作成処理の監視」を参照してください。

このログを有効にすると、行に索引が作成されたときに各行の行IDが記録されるので、索引作成処理が長い間ハングしている行を判別できます。行によっては正常な処理でも数分かかる場合がありますが、処理が予想以上に長くかかる場合は、問題が発生している可能性があります。

一般に、ビューCTX_USER_INDEX_ERRORSは、索引作成のプロセスがハングまたはクラッシュした理由の特定にはあまり有効ではありません。これは、情報はコミットされるまでこのビューに表示されないためで、コミットは索引作成処理がハングしている間は行われません。事実、処理がクラッシュした場合は、コミットはまったく行われません。

URLの索引作成やドキュメントの絞込みなどの処理は、かなり時間がかかる場合があります。これらの処理は両方とも、プロセスをさらに長引かせないためにタイムアウト・メカニズムの対象になります。

- URLの索引作成のタイムアウト - URLコンテンツを取り出すためのデフォルトのタイムアウトは、30秒です。URLコンテンツを30秒以内に取り出すことができない場合は、取出しが中止されて、失敗エラーがビューCTX_USER_INDEX_ERRORSに報告され、索引作成のプロセスは次の行に進みます。ほとんどの場合、URLコンテンツを取り出すには30秒で十分です。ただし、いったんコンテンツを取り出したら、それに索引を作成する必要があるので、合計時間はURLのタイムアウト値よりも少し長い場合があります。

- ドキュメント絞込みのタイムアウト - ドキュメントの絞込み処理のタイムアウトは、厳密なタイムアウト制限ではありません。このタイムアウトの設定値は、デフォルトで120秒に設定されています。この設定値は、AUTO_FILTERによる出力の生成を待機する時間です。このタイムアウト値が経過すると、現在の絞込み処理は終了し、現在のドキュメントのコンテンツには索引が作成されず、索引作成プロセスは次のドキュメントに進みます。120秒を経過した後、AUTO_FILTERの出力ファイルのサイズが増え続ける場合は、絞込み処理が続行しています。

このタイムアウト・メカニズムは、問題が発生しやすい2つの分野である、URLおよびドキュメントの索引作成の問題の防止に役立ちます。ただし、索引作成処理が無期限にハングする状況が発生する可能性はまだあります。

10.3.13.2 索引のハングおよびクラッシュの防止

特定のコンテンツが索引作成処理の失敗の原因である場合は、そのコンテンツを索引作成プロセスから除外できます。最初に、問題の原因の行を特定する必要があります。この項では、この方法とそのようなコンテンツを除外するための追加の手順について説明します。

ステップ1: 索引作成の問題の原因である行IDを特定する

これは、print rowid eventを有効にして、Oracle Textのログ機能を使用して行うことができます。生成されたログ・ファイルを調べると、失敗したときの(処理されていた行の)行IDを特定できます。ほとんどの場合、この行IDが索引作成の問題の原因です。

ただし、場合によっては、失敗したときに実際に処理されていた行の行IDがログ・ファイルに書き込まれないことがあります。この場合、その行の次の行IDを確認する必要があります。

- たとえば、索引を最初に作成したときに、表全体を同期化している場合は、行IDは表の次の行IDになっています。行IDを特定するには、order by句なしで表から選択します。

- いくつかの保留状態の行のみ更新された場合は、ビューctx_user_pendingを調べて次の行IDを特定します。

索引作成の問題の原因である行を特定したら、それが正しい行であるかどうかを確認する必要があります。これは、その行のみを同期化して失敗を再現することにより行います。

Oracle Text索引が存在しない場合は、次のコマンドを使用して索引を作成します(ただし、索引に値を移入しないでください)。

SQL> exec wwv_context.drop_prefs;
PL/SQL procedure successfully completed.
SQL> exec wwv_context.create_prefs;
PL/SQL procedure successfully completed.
SQL> declare
2      l_indexes wwsbr_array;
3  begin
4      wwv_context.create_missing_indexes(l_indexes);
5  end;
6  /
PL/SQL procedure successfully completed.
SQL>

これにより、すべての索引が作成され、保留状態の行はありません。

ステップ2: 問題の行IDを保留中としてマークする

次の手順では、索引作成の問題の原因である可能性がある行を保留中としてマークします。更新する必要のある列は、どの索引を更新するかによって決まります。それらの列の名前を次の例に示します。これらの例にでてくる行IDを、確認対象の行IDと置き換えます。

URL索引(WWSBR_URL_CTX_INDX): absolute_url列には、トリガーによって値が移入されるので、次のようにここでこの列にNULLを設定します。

update wwsbr_url$ set absolute_url=null where rowid = 'AAAOwQAAJAAAU0+AAL';

ドキュメント索引(WWSBR_DOC_CTX_INDX): blob_content列を更新しますが、元のblob_content値を保持します。

update wwdoc_document$ set blob_content = blob_content where rowid = 'AAAOYyAAJAAAWAaAAF'

アイテム索引(WWSBR_THING_CTX_INDX): この索引は、ctxtxt列に作成されたユーザー・データストアを使用します。この列の値は、無意味であり、Oracle Portalでは常に1です。

update wwv_things set ctxtxt = '1' where rowid = 'AAAOwMAAJAAAU0eAAB'

ページ索引(WWSBR_FOLDER_CTX_INDX): アイテム索引と同様です。

update wwpob_page$ set ctxtxt = 1 where rowid = 'AAAOwMAAJAAAWITAAA'

カテゴリ索引(WWSBR_TOPIC_CTX_INDX): アイテム索引と同様です。

update wwv_topics set ctxtxt = 1 where rowid = 'AAAOwMAAJAAAWITAAA'

パースペクティブ索引(WWSBR_PERSP_CTX_INDX): アイテム索引と同様です。

update wwv_perspectives set ctxtxt = 1 where rowid = 'AAAOwMAAJAAAWITAAA'

複数のサブスクライバがインストールされたサイトがある場合は、サブスクライバを切り替えてからでないと必要な行を見ることができない場合があります。サブスクライバを変更するには、次のプロシージャを使用して軽量ユーザーのセッション・コンテキストを設定します。

wwctx_api.set_context
(
p_user_name     IN varchar2,
p_password      IN varchar2 default null,
p_company       IN varchar2 default null
);

wwctx_apiは、パブリックPL/SQL APIパッケージです。詳細は、OTN(http://www.oracle.com/technology/products/ias/portal)から入手できる『Oracle Portal PL/SQL API Reference』を参照してください。

列の更新後、疑いのある行が保留中のキューに入れられます。

ステップ3: 索引を同期化する

ここで、次のコマンドを使用して、索引を同期化し、同じ問題が発生するかどうかを確認できます。

SQL> exec wwv_context.sync();

このコマンドは、疑いのある行が保留中のキュー内の唯一の行である場合にのみ同期化します。テストを繰り返すために、行を再度更新できます。付録D「sync」も参照してください。

ステップ4: 問題の原因のコンテンツを除外する

索引作成の問題の原因である行を変更または削除して、今後、索引作成処理がハングまたはクラッシュするのを防止できます。たとえば、ドキュメントの場合は、Oracle Portal内の関連するアイテムを編集して、そのドキュメントを削除できます。

注意:

索引作成処理中にシステムがハングまたはクラッシュした場合は、オラクル社カスタマ・サポート・センターに問い合せてください。問題の原因のコンテンツに関連する具体的な詳細情報を提供していただくと、問題の再現が容易になります。

10.4 Oracle Secure Enterprise Search

この項では、Oracle Secure Enterprise Searchと、Oracle Secure Enterprise Searchの「セキュア」ポートレットのサンプルについて説明します。ここでは、次の内容について説明します。

- Oracle Secure Enterprise Searchの概要

- Oracle Secure Enterprise Searchの「セキュア」ポートレット

10.4.1 Oracle Secure Enterprise Searchの概要

Oracle Secure Enterprise Searchは、Oracle DatabaseとOracle Textテクノロジ上に構築され、Oracle Database、その他のODBC準拠データベース、IMAPメール・サーバー、Webサーバーが提供するHTML文書、ディスク上のファイルなどの複数のリポジトリに対する一括検索機能を提供します。

Oracle Secure Enterprise Searchは、クローラを使用してドキュメントを収集します。検索するWebサイトに適したクローラをスケジュールできます。ドキュメントは固有のリポジトリに残り、クロールされた情報は索引の作成に使用されます。この索引は、指定したOracle Database内のファイアウォールの内側で保持されます。また、Oracle Secure Enterprise Searchは、コンテンツ管理ソリューションを構築するためのAPIも提供します。

また、Oracle Secure Enterprise Searchは次のものも提供します。

- データベース内のテキストを検索するための完全なテキスト問合せ言語

- Oracle DatabaseサーバーとSQL問合せ言語の完全な統合

- 概念検索やテーマ分析などの高度な機能

- 異なるリポジトリ間での属性検索を容易にする属性マッピング

- 使用頻度の高いすべてのファイル形式(150以上)の索引作成

- 中国語、日本語、韓国語(CJK)、およびUnicodeのサポートを含む完全なグローバリゼーション

詳細は、次の場所にあるOTNを参照してください。

http://www.oracle.com/technology/products/oses/index.html

Oracle Secure Enterprise Searchは、Oracle Portalに統合されているため、高機能なマルチリポジトリ検索機能をポータル・ページに追加できます。また、Oracle Portalの専用リポジトリをクロールする機能およびパブリック・コンテンツとプライベート・コンテンツを検索する機能も用意されています。

10.4.1.1 Oracle Secure Enterprise Searchのサンプル問合せアプリケーションについて

Oracle Secure Enterprise Searchには、検索結果の問合せと表示に必要な機能を備えたサンプル問合せアプリケーションが含まれています。問合せアプリケーションは、J2EE準拠のWebアプリケーションとして作成されています。サンプル問合せアプリケーションには、Oracle Secure Enterprise Searchの「セキュア」ポートレットも含まれています。

The Oracle Secure Enterprise Searchの「セキュア」ポートレットは、Oracle Portalで使用する検索ポートレットの作成方法を示します。ユーザーが検索問合せを発行すると、検索基準に一致する結果リストが返されます。

Oracle PortalでOracle Secure Enterprise Searchの「セキュア」ポートレットを使用する方法の詳細は、『Oracle Secure Enterprise Search管理者ガイド』の「付録A」を参照してください。

10.4.1.2 Oracle Secure Enterprise Searchの構成について

Secure Enterprise Search (SES)を使用している場合、デフォルトでは、Portalの検索結果にはアイテムまたはページの永続的なURL形式が表示されます。URLを読める形式で表示するには、次の手順を実行します。

1. Portalスキーマ・パスワードを使用して、sbrsrxml.sqlを実行します。このファイルは、WindowsではORACLE_HOME\upgrade\portal\admin\plsql\wws、UNIXではORACLE_HOME/upgrade/portal/admin/plsql/wwsにあります。

2. 値0を入力します。たとえば、Windowsでは@wws\sbrsrxml.sql 0と入力します。

完全なSESクロールを実行すると、URLは読める形式で表示されます。URLを永続的なURL形式で表示する場合は、sbrsrxml.sqlを実行して1を入力します。

詳細は、『Oracle Secure Enterprise Search管理者ガイド』(http://download.oracle.com/docs/cd/E14507_01/admin.1112/e14130/toc.htm)を参照してください。

10.4.2 Oracle Secure Enterprise Searchの「セキュア」ポートレット

Oracle Secure Enterprise Searchには、Oracle Portalページに埋め込むことができる検索ポートレットが用意されています。

詳細は、『Oracle Secure Enterprise Search管理者ガイド』を参照してください。

11 Oracle Portalのパフォーマンスの調整

この章では、ポータル・システムの基本構成を設定した後で、その構成を基にしてOracle Portalのパフォーマンスを調整する方法について説明します。

この章では、Oracle Portalのパフォーマンスを調整する方法として、次のオプションについて説明します。

- サーバー・プロセス数の設定

- アイドル・プロセス数の設定

- PPEフェッチャ数の設定

- Oracle HTTP Serverの調整

- ファイル・システム・キャッシュの調整によるキャッシュのパフォーマンス向上

- Oracle Net Servicesの調整

関連項目:

- Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド

- 次の場所にあるPortal Centerの「Performance」ページ
http://www.oracle.com/technology/products/ias/portal

11.1 サーバー・プロセス数の設定

Oracle HTTP Serverは、WebリクエストをHTTPプロセスへ配布して処理します。Oracle HTTP Serverは、ユーザーのブラウザから送信されるすべてのタイプのリクエスト(静的ファイル、Javaサーブレット、PL/SQLプロシージャに対するリクエストなど)を処理できます。

MaxClientsは、Oracle HTTP Serverの構成ディレクティブの1つで、Oracle HTTP Serverが常に処理可能なWebリクエストの最大数を制御します。リクエスト数がMaxClientsを超えると、Oracle HTTP Serverは、現在の負荷を処理してHTTPプロセスが解放されるまで、新しいリクエストの処理を拒否します。たとえば、あるクライアント・ブラウザが許容セッション数を超えていると、他のクライアント・ブラウザがロックアウトされることがあります。

MaxClientsディレクティブは、同時Webリクエストの適切なフローをサーバーに許可するレギュレータとして考えることができます。この値が小さすぎると、Webポータルのパフォーマンスが低下する場合があります。より多くの通信量を迅速なレスポンスで処理するサーバーおよびデータベース・リソースを配置しても、適切なプロセス数がMaxClientsに設定されていないと、Webリクエストを処理できない場合があります。

各HTTPプロセス・サーバーはCPU時間、メモリー、I/Oなどのリソースを消費するため、MaxClientsの値が大きすぎると、必要以上にリソースを消費することになります。その結果、パフォーマンスが低下する場合があります。Oracle HTTP Serverは、PL/SQLプロシージャに対するリクエストなど、あらゆる種類のリクエストを処理できます。Oracle HTTP Serverがリクエストを受信すると、ポータル・データベースと通信するためにPortalサービスにリクエストを渡します。ポータル・データベースへのリクエストを実行するサーバー・プロセスごとに、データベース接続をキャッシュする必要があります。MaxClientsに設定する値によって、Portalサービスが開くことができるデータベース接続の上限が決まります。

たとえば、MaxClientsを最大数の1024に設定します。Oracle HTTP Serverは、常に1024(データベース接続を必要とする数を含む)のWebリクエストを同時に処理できます。サーバーがこの負荷に対応できる場合でも、接続先のデータベースが対応できないことがあります。PL/SQLプロシージャのリクエスト数が他のタイプのリクエスト数より急激に多くなった場合は、データベースが対応できる負荷を超える可能性があります。

注意

Windowsの場合は、Oracle HTTP ServerのパラメータThreadsPerChildを調整してください。

パフォーマンスを最適にするには、構成内のサーバーが処理できるWebリクエストの数およびデータベースが処理できる通信量を決めることです。1つのデータベースに接続する複数の中間層サーバーがポータル構成に含まれている場合、処理可能なWebリクエストの数は、中間層よりもデータベースの容量によって制限される可能性があります。

関連項目:

- Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

- 第11.4項「Oracle HTTP Serverの調整」の「MaxClients値の構成」

11.2 アイドル・プロセス数の設定

MinSpareServersは、UNIX特有のOracle HTTP Serverディレクティブの1つで、アイドル・セッションの最小数を設定します。アイドル・セッションとは、Webリクエストを現在処理していないセッションのことです。アイドル・セッションの数が、MinSpareServersで指定されている数よりも少ない場合は、最大で毎秒1個のプロセスが新しく作成されます。

このパラメータは、アクセス頻度の高いサイトに対してのみ調整してください。デフォルトの設定は5です。このパラメータを大きな数に設定することはお薦めできません。原則として、ポータルが通常処理するWebリクエストの平均数を少し上回る値にMinSpareServersを設定します。できるだけ、新しいポートを開かずに、開いているポートによってユーザー・リクエストが処理されるように設定します。ただし、この状態を実現するには、データベース・リソースで必要な数のポートを利用できなければなりません。

UNIXとは異なり、Windowsはスレッドベースのオペレーティング・システムであり、1つのプロセスが開始された後、その子プロセスが必要に応じてスレッド化されます。Windowsコンピュータの場合、このディレクティブはMaxThreadsPerChildと呼ばれます。これは、サーバーが同時に処理できるリクエスト数を表します。サーバー、およびサーバーが使用することのできるシステム・リソースの応答性に従って、この値を設定してください。WindowsのMaxThreadsPerChildはUNIXのMaxClientsに相当します。

関連項目:

Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

11.3 PPEフェッチャ数の設定

ポータル・ページに対するリクエストはURLの形式で開始され、ユーザーのブラウザからOracle HTTP Serverに送信されます。ポータル・ページに対するリクエストの場合、Parallel Page Engine (PPE)に転送されます。次にPPEは、ポートレットを実行してコンテンツをポータル・ページに返すよう、ページ上のポートレットを所有する各プロバイダに要求します。

PPEにおける同時実行性を向上させるには、次の手順を実行します。

デフォルトのスレッド数を増やす

PPEはフェッチャのプールを使用して、リクエストをプロバイダに転送し、返されるデータを待機します。リクエストの処理を終了したフェッチャは解放され、新しいリクエストを処理できるようになります。

PPEスレッドの数を調整するパラメータは、poolSizeという名前で、DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xmlファイルに構成されています。

デフォルト値は、25です。ほとんどのWebポータルの場合、プール・サイズを変更する必要はありません。ただし、プール・サイズが小さすぎると、ピーク間隔でページの描画に時間がかかるようになります。プール・サイズが大きすぎると、リソースが不足することがあります。同時に多数のURLリクエストが発生して、PPEの処理量を超える可能性があるためです。

PPEのパラメータは次のとおりです。

<poolSize>50</poolSize>

構成の変更を有効にするには、Oracle Fusion Middleware中間層を再起動します。

11.4 Oracle HTTP Serverの調整

Oracle HTTP Serverリスナーを設定することにした場合でも、Oracle HTTP Serverリスナーによって同時に処理できるリクエストのおおよその数を設定して、パフォーマンスを最適化することができます。

Oracle Portalの実行に必要なデータベース・セッションの合計数は、ポータル・リポジトリへの同時アクセスを必要とする同時リクエストの合計数の要因になります。特定のインスタンスによるサービスが可能な任意のタイプの同時リクエストの合計数は、Oracle HTTP Serverの構成パラメータMaxClientsの要因になります。

ポータル・リポジトリへの各接続では、1つのネットワーク接続と2つのセッションを使用します(2つのセッションは同じ物理接続を使用します)。最初のセッションはportal用、2番目のセッションはportal_public用です。

したがって、MaxClientsは150に設定されていても、ポータル・リポジトリへの同時アクセスを必要とする同時リクエストの最大数が50である場合は、100 (50*2)セッションを実行できるようにデータベースを構成する必要があります。

理論的には、150すべてのリクエストがポータル・リポジトリへの同時アクセスを必要とすることも考えられ、このような場合に必要なデータベース・セッション数は300 (150*2)になります。実際には、このような状況はほとんど発生しません。

ポータル・リポジトリへの同時アクセスを必要とする同時リクエストの数が多く、処理可能なセッション数を越えた場合、クライアントがロックアウトされることがあります。ただし、セッション数を非常に大きな値に設定すると、リソースが必要以上に消費されます。

注意:

1. 同時にサービスされる一般的なリクエストには、常に様々なタイプ(静的イメージ、ポータル・ページのリクエスト、その他のOracle HTTP Serverリクエストなど)があり、ポータル・リポジトリへの同時アクセスを必要とする実際の同時リクエストの数はわずかです。

2. Oracle PortalではOracle Web Cacheとポータル・ファイル・キャッシュを利用してコンテンツがキャッシュされるため、ポータル・リポジトリへ頻繁に接続する必要がなくなり、データベース・セッションの要件が軽減されます。

3. ポータル・ページのリクエストでは、PPEのpoolSizeパラメータがスロットルのように動作します。これにより、ポータル・ページに対する同時リクエストによってシステムが満杯になる可能性が低下します。

4. この項では、Oracle Portal内部で実行されるPortalサービスで必要なセッションについてのみ説明しています。同じリポジトリに接続する他のエンティティについても考慮する必要があります。

MaxClients値の構成

一般に、ログインの頻度はOracle Portalへアクセスする頻度よりも低いため、独立したOracle HTTP ServerリスナーでOracleAS Single Sign-Onを構成するほうが適切です。目標は、MaxClientsの設定をポータル・システムのニーズに影響しない程度に合理的な値に調整することです。

関連項目:

Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド

MaxClients設定を構成するには、次の手順を実行します。

1. OracleAS Single Sign-Onのリスナーの場合、MaxClientsパラメータに設定する近似値を決定し、次の場所にある構成ファイルhttpd.confで、その近似値に応じて値を適切に編集します。

ORACLE_INSTANCE\config\OHS\ohs1

MaxClientsの設定を調整して、Oracle HTTP ServerリスナーでOracle HTTP Serverのサービスによって処理されるリクエストの数を制御します。これによって、確立されるセッションの最大数が制御されます。

2. Oracle Portalリスナーの場合は、OracleAS Single Sign-OnのニーズとOracle Portalのニーズに従って、矛盾が発生しないようにMaxClientsパラメータを個別に調整できます。このパラメータは、確立されるセッションの数に直接対応しており、Oracle HTTP Serverリスナーがポータル・リスナーで処理できる最大負荷に相当します。
次の例は、httpd.confファイルのMaxClientsセクションを表しています。

# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule prefork.c>
StartServers         5
MinSpareServers      5
MaxSpareServers     10
MaxClients         150
MaxRequestsPerChild  0
AcceptMutex fcntl

注意:

- OracleAS Single Sign-OnとOracle Portalを個別に調整する場合は、それぞれのリスナーが個別に作成されます。Oracle Portalはポータル・データベース上のリソース(セッション)を制御し、OracleAS Single Sign-OnはOracleAS Single Sign-Onデータベース上のリソースを制御します。

- データベースで許可されるセッションと接続の数は、Oracle Databaseのinit.oraファイルに設定されている値によって制限されます。詳細は、Oracle Databaseドキュメント・ライブラリを参照してください。

11.5 ファイル・システム・キャッシュの調整によるキャッシュのパフォーマンス向上

ファイル・システム・キャッシュを調整すると、キャッシュのパフォーマンスが向上します。ファイル・システム・キャッシュを調整するには、次の2つの方法があります。

- より高速なファイル・システムに常駐するように、ファイル・システム・キャッシュを構成します。

- セッション・キャッシュ・ディレクトリをよりパフォーマンスの高いファイル・システムへ移動します。

注意:

今回のリリース以降、Oracle Portalではセッション・キャッシュのメモリー内キャッシュが実装されています。この機能により、頻繁に使用されるセッション・キャッシュ・オブジェクトの読込みにおいて競合が発生する可能性が低くなるため、よりパフォーマンスの高いファイル・システムへセッション・キャッシュのコンテンツを移動する必要がなくなります。

これらの方法の詳細は『Oracle Fusion Middleware mod_plsqlユーザーズ・ガイド』のPL/SQLパフォーマンスの最適化に関する項を参照してください。

11.6 Oracle Net Servicesの調整

Portalサービスは、Oracle Net Servicesを利用して、Oracle Metadata RepositoryのOracle Portalスキーマに接続します。Oracle Net Servicesを調整すると、データベース・アクセスのパフォーマンスが向上します。

詳細は、Oracle Technology Network (OTN)(http://www.oracle.com/technology/)のホワイト・ペーパー「Tuning Oracle Net Services to optimize mod_plsql Database access times」を参照してください。このドキュメントに記載されている調整方法は、Oracle Portalでも使用できます。

12 コンテンツのエクスポートとインポート

Oracle Portalには、ポータル間でコンテンツを転送するためのエクスポート・ユーティリティとインポート・ユーティリティが用意されています。この章では、エクスポート・ユーティリティとインポート・ユーティリティの使用に関する推奨事項と最善の使用方法について説明します。この章には、次の各項が含まれます。

- Oracle Portalのエクスポートまたはインポートの概要

- 始める前に

- エクスポートおよびインポート機能の使用例

- Oracle Portalでのエクスポート

- トランスポート・セットの取得サービス

- Oracle Portalでのインポート

- Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトの使用

- 移行後のオブジェクトの動作

- エクスポートおよびインポート時の推奨方法

12.1 Oracle Portalのエクスポートまたはインポートの概要

この項では、Oracle Portalのエクスポートとインポートを実行する際に必要となる作業、およびこれらの機能がOracle Fusion Middlewareの他のコンポーネントとどのように連携するかについて説明します。この項には次のトピックが含まれます:

- Oracle Portalのエクスポートとインポートの機能

- 詳細情報

Oracle Portalのエクスポートとインポートの機能

Oracle Portalのエクスポートおよびインポート処理は、次の手順で行われます。

1. トランスポート・セットを作成し、その内容をトランスポート表に抽出します。トランスポート・セットには、ターゲットのポータル環境にエクスポートするポータル・オブジェクトが含まれています。この情報は、マニフェストに表示されます。マニフェストは、トランスポート・セット内のオブジェクトをリストにしたもので、エクスポートを詳細に制御するために使用されます。エクスポート・プロセスと「トランスポート・セット - エクスポート・サービス」ポートレットの使用の詳細は、第12.4.1.2項「トランスポート・セットの管理方法」を参照してください。

2. 介在するファイアウォールがある場合は、「トランスポート・セット 取得サービス」ポートレットを使用するか、またはOracle Portalのエクスポートとインポートのコマンドライン・スクリプトを使用して、1つのシステム(ソース)から別のシステム(ターゲット)にトランスポート・セットを移動します。「トランスポート・セット 取得サービス」ポートレットを使用して、ソース・システムからターゲット・システムにトランスポート・セットを移動する方法の詳細は、第12.5.2項「ターゲット・システムへのデータの移動」を参照してください。コマンドライン・スクリプトの使用方法の詳細は、第12.7項「Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトの使用」を参照してください。

3. 「トランスポート・セットのインポート」ポートレットを使用して、トランスポート表からターゲット・ポータル・リポジトリにオブジェクトをインポートします。インポート・プロセスと「トランスポート・セットのインポート」ポートレットの使用方法の詳細は、第12.6.1項「Oracle Portalのインポート - 推奨方法」を参照してください。

詳細情報

- 『Oracle Fusion Middleware管理者ガイド』で、Oracle Portalの製品固有メタデータをテスト・メタデータ・リポジトリから本稼働メタデータ・リポジトリへ移動する方法に関する項を参照してください。

- 『Oracle Fusion Middleware Oracle Portal開発者ガイド』で、ポートレット・パーソナライズのエクスポートとインポートの制御に関する項を参照してください。

12.2 始める前に

エクスポートおよびインポート処理を開始する前に、次の情報を確認してください。

- システム要件

- その他の検討事項

- コンテンツをエクスポートおよびインポートするための権限

- Oracle Portalインスタンスの情報

- Portalスキーマ名。

- ポータル・スキーマのパスワード。

- Portal接続文字列情報。

- Portalユーザー名。

- Portalユーザーのパスワード。

- 会社名(ホストされたポータル・インストールの場合のみ使用)通常は空白のままにしておきます。

注意:

Oracle Portalスキーマのパスワードは、このアプリケーションのインストール時に作成された乱数のパスワードです。

12.2.1 システム要件

コンテンツをエクスポートおよびインポートする前に、使用するシステムが、この項に記載されているシステムの最低条件を満たしていることを確認します。

注意:

- エクスポートとインポートは、Oracle Portalの同じリリースおよび同じパッチ・リリースでのみ機能します(リリース10.1.4とリリース10.1.4、リリース11.1.1とリリース11.1.1など)。リリース10.1.2とリリース10.1.4、リリース10.1.4とリリース11.1.1などのように、リリースが異なる場合はエクスポートおよびインポートできません。

- オブジェクトを正しく移行するには、ターゲットとソースのポータル・リポジトリのバージョンが同じである必要があります。中間層のバージョンの違いは移行に影響しません。

- クライアントのエクスポート・ユーティリティでの異なるリリースの使用。Oracle Databaseの異なるリリース間でデータを移動する場合は、次の規則を適用します。

- Oracle Database impユーティリティとデータをインポートするデータベース(ターゲット・データベース)は、必ず同じリリースまたはそれ以上のリリースを使用します。

- Oracle Database expユーティリティのリリースは、ソース・データベースとターゲット・データベースのうち、より以前のリリースと同じでなければなりません。

注意:

- Oracle Databaseのexpとimpは、ユーザー・データをバックアップまたは転送する際、Oracle特有の形式でデータをダンプし、復元するために使用される、エクスポートとインポートのための移行ユーティリティです。

- データベース・リリースの不一致に関する問題が発生した場合は、オラクル社カスタマ・サポート・センターに連絡してください。

データベースのOracleホームと中間層のOracleホームのどちらを使用するかは、ソースとターゲットのポータル・インストールに使用されているデータベースのリリースによります。デフォルトでは、リリース11.1.1の中間層では、リリース11.1.1のOracleホームが使用されます。

前述の推奨事項に基づくと、リリース11.1.1のポータルとリリース11.1.1の中間層の場合は、次の条件が適用されます。

- コンテンツをエクスポートするときは、常に中間層のOracleホームを使用します。リリース10.2.0.3は、リリース11.1.1のポータル・インストールがサポートする最も初期のデータベース・リリースです。

- コンテンツをインポートするときは、常にターゲット・データベースのOracleホームを使用します。インポート・ユーティリティとターゲット・データベースのリリースは同じである必要があります。

たとえば、より新しいリリースのデータベースにインポートする場合は、ソース・データベースと同じリリースのOracle Database expユーティリティを使用してエクスポート・ファイルを作成します。より以前のリリースのデータベースにインポートする場合は、ターゲット・データベースと同じリリースのOracle Database expユーティリティを使用してエクスポート・ファイルを作成します。

注意:

インポート元とエクスポート先のポータル・インストールでは、同じリリースのデータベースを使用することを薦めします。

- Oracleエクスポートおよびインポートと文字セット。Oracle Database expユーティリティは、常に、エクスポート・サーバーの文字セットでユーザー・データ(Unicodeデータを含む)をエクスポートします。文字セットはデータベースの作成時に指定します。
Oracle Database impユーティリティは、インポート・サーバーの文字セットにデータを自動的に変換します。

8ビット文字セットのエクスポート・ファイルをインポートすると、一部の8ビット・キャラクタが失われる(つまり7ビットの対応するキャラクタに変換される)場合があります。この現象は、クライアント・システムに固有の7ビット文字セットがある場合、またはオペレーティング・システムの環境変数NLS_LANGが7ビット文字セットに設定されている場合に発生します。アクセント記号のある文字は、ほとんどの場合、アクセント記号が失われます。

Oracle Databaseのexpユーティリティとimpユーティリティでは、データをエクスポートまたはインポートする前に必要な文字セットの変換が示されます。

注意:

エクスポート・クライアントとエクスポート・サーバーの間で文字セットの幅が異なる場合は、変換によってデータが拡張されるとデータが切り捨てられることがあります。切捨てが発生する場合は、警告メッセージが表示されます。

- ソースおよびターゲットのポータル・インスタンスについてよく把握します。

- ソース・コンピュータおよびターゲット・コンピュータ上の対象ディレクトリにコマンドラインからアクセスできますか。Oracle Portalのエクスポートとインポートのコマンドライン・スクリプトを使用して、1つのシステムから別のシステムにトランスポート・セットを移動する場合、エクスポートおよびインポート処理で生成されるシェルまたはコマンド・ユーティリティを実行するためにコマンドラインへのアクセスが必要です。同時に、コマンドライン・ユーティリティからは、Oracle Databaseのexpユーティリティとimpユーティリティ、およびOracle Portalインスタンスにアクセスできる必要があります。

- バックグラウンド・ジョブを実行できるようにデータベースが構成されていますか。エクスポートまたはインポートの各プロセスは、それぞれバックグラウンド・プロセスを設定します。このため、データベース・パラメータjob_queue_processesが正しく設定されているかどうかを確認してください。
job_queue_processesパラメータの値を確認するには、SQL*Plusから次の問合せを実行します。

%select name, value from v$parameter where name='job_queue_processes'

バックグラウンド・ジョブを実行できるようにするには、job_queue_processesの値を2以上に設定します。

また、データベースのORACLE_INSTANCEに格納されているinit.oraファイルを調べて、job_queue_processesパラメータを確認する方法もあります。

- データのエクスポートとインポートをいつ実行しますか。営業時間外にエクスポートおよびインポート処理を実行し、処理中はOracle Portalにアクセスできないようにします。ポータルへのアクセスを一時的に無効にするには、エクスポート中はリスナーを別のポート番号に構成し、エクスポート処理が完了した後で元のポートに戻すという方法があります。

注意:

Oracle Database expユーティリティおよびimpユーティリティの実行中にエラーや警告が発生した場合は、トランスポート・セットをインポートしないでください。まず、Oracle Databaseのexpログ・ファイル(<script_file_name>_<long identifier>_exp.log)およびimpログ・ファイル(<script_file_name>_<long identifier>_imp.log)に記録されるエラーや警告を確認し、問題を解決してください。

- エクスポートまたはインポート処理にどの程度の時間がかかりますか。Oracle Portalのコンテンツをエクスポートまたはインポートする際の所要時間を正確に予測することはできません。コンテンツのエクスポートとインポートにかかる時間は、様々な要因の影響を受けます。エクスポートとインポートに影響する要因は次のとおりです。
エクスポート処理に影響を与える要因は次のとおりです。

- エクスポートされるオブジェクトには、ページ・グループ全体にわたる複数の依存性があります。

- オブジェクト間に参照または依存性があります。

- 抽出処理の開始に時間がかかる場合、キューで割り当てられているデータベース・ジョブが原因です。

- 抽出されるドキュメント(特にBLOB列)が数多く存在しています。

- ソート処理の場合、一時表領域のメモリーが不十分です。

- スキーマ検証に時間がかかる場合、検証を要するオブジェクトの数が多いことが原因です。

インポート処理に影響を与える要因は次のとおりです。

- 大容量のページ・グループの事前チェック(事前チェックを要する内部および外部の依存性の数にもよります)。

- インポート処理の開始に時間がかかる場合、キューで割り当てられているデータベース・ジョブが原因です。

- ソート処理の場合、一時表領域のメモリーが不十分です。

- インポート後のスキーマ検証に時間がかかる場合、検証を要するオブジェクトの数が多いことが原因です。

- ソース言語とターゲット言語がある程度以上異なっています。

ヒント

サイズの大きいトランスポート・セットをインポートするときは、事前に、関連するデータベース・キャッシュのパラメータ値を必要に応じて大きくしておきます。これで、トランスポート・セットのサイズが大きい場合でも、それほど時間をかけずにインポートできるようになります。

12.2.2 その他の検討事項

ここでは、Oracle Portalのデータをエクスポートおよびインポートする前に考慮する必要があるその他の重要事項を説明します。

- 大容量のデータ・セットをエクスポートまたはインポートする場合、一時表領域に十分な空きがあることを確認します。空き領域が十分であれば、メモリー不足が原因でエクスポート処理やインポート処理が失敗することはありません。

- コマンドラインから大容量のページ・グループをエクスポートする場合は、opeasst.cshスクリプトを使用します。詳細は、第12.4.1.1.3項「コマンドラインからの大容量のページ・グループのエクスポート」を参照してください。

- コマンドラインから大容量のページ・グループをインポートする場合は、-automatic_mergeオプションを使用してインポート・スクリプトを実行します。詳細は、第12.7.3項「ターゲット・システムへのトランスポート・セット表のインポート」を参照してください。

- Business Intelligence and Formsのコンポーネントをインストールしており、ソース・ポータル・インスタンスでOracle Portalの関連ポートレットを使用する場合、ポータル・インスタンス間でデータをエクスポートおよびインポートする前に、ターゲット・ポータル・インスタンスにも同じコンポーネントがインストールされていることを確認する必要があります。同じBusiness Intelligence and Formsコンポーネントがターゲット・ポータル・インスタンスにインストールされていない場合は、インポート時に、それらのコンポーネントに関連するポートレットが表示ページから削除されます。

注意:

ソースまたはターゲットのポータル・インスタンスで問題が発生した場合、システム表を手作業で更新して解決することは避けてください。手作業での処理は、エクスポートおよびインポート処理が失敗する原因になります。ソースまたはターゲットのインスタンスに問題が生じた場合は、オラクル社カスタマ・サポート・センターに連絡してください。

12.2.3 コンテンツをエクスポートおよびインポートするための権限

この項では、コンテンツを正しくエクスポートおよびインポートするための権限について説明します。ここで説明する権限は、Oracle Instant Portalのコンテンツをエクスポートおよびインポートする場合にも適用されます。

コンテンツをエクスポートするための権限

共有オブジェクト(共有ページ・グループ内のオブジェクト)のエクスポートを安全に制御できるように、インフラストラクチャ・レベルで2つの権限が定義されています。

- 「すべてのトランスポート・セット」の「管理」: 共有オブジェクトを含め、ポータル・オブジェクトをエクスポートおよびインポートできます。この権限は、ポータルのインストール・プロセスで、DBAグループにデフォルトで付与されます。

- 「すべてのトランスポート・セット」の「実行」: 共有オブジェクト以外のポータル・オブジェクトをエクスポートおよびインポートできます。この権限は、ポータルのインストール・プロセスで、PORTAL_ADMINISTRATORSグループにデフォルトで付与されます。

表12-1に、エクスポート・ユーザーの権限を示します。

表12-1 エクスポート・ユーザーの権限

ユーザーの権限

非共有オブジェクトのエクスポート

共有オブジェクトのエクスポート

「すべてのトランスポート・セット」の「管理」

はい

はい

「すべてのトランスポート・セット」の「実行」

はい

いいえ

「すべてのトランスポート・セット」の「なし」

いいえ

いいえ

コンテンツをインポートするための権限

「すべてのトランスポート・セット」の「管理」権限の他にも、コンテンツを正常にインポートするために、特定タイプのオブジェクトに対する管理権限が必要です。

たとえば、Webプロバイダが含まれているページ・グループの場合、そのページ・グループをインポートするには、「すべてのプロバイダ」および「すべてのページ・グループ」に対する「すべて管理」権限が必要です。表12-2に、それぞれのオブジェクト・タイプおよび必要な権限レベルを示します。

注意:

インストール時またはアップグレード時に、FMWADMINユーザーとOracle Portalユーザーには、すべてのページ・グループに対する「すべて管理」権限が付与されます。DBAグループのメンバーにも、すべてのページ・グループに対する「すべて管理」権限がデフォルトで付与されます。

表12-2 インポート・ユーザーの権限

オブジェクト・タイプ

権限

すべてのページ・グループ

ページ・グループと共有オブジェクトをインポートするには、「すべて管理」と「すべてのプロバイダの管理」が必要です。

すべてのプロバイダ

ページ・グループ、Portal DBプロバイダ、Webプロバイダ、WSRPプロデューサ、およびその他のデータベース・プロバイダをインポートするには、「管理」が必要です。

すべてのPortal DBプロバイダ

Portal DBプロバイダのオブジェクトをインポートするには、「管理」が必要です。

すべての共有コンポーネント

Portal DBプロバイダのオブジェクトが共有コンポーネントを参照している場合、共有コンポーネントをインポートするには、「管理」が必要です。

注意:

共有オブジェクト・グループに属しているスタイルに基づくページをインポートする場合、共有オブジェクトをインポートする権限がないと、ページのスタイルがデフォルトで「メイン・スタイル」にリセットされます。

12.3 エクスポートおよびインポート機能の使用例

Oracle Portalは、ソースとターゲットのポータル・インスタンス間で、ページ・グループおよびポータル・コンテンツをコピーまたは更新する機能をサポートしています。この項では、Oracle Portalのエクスポートおよびインポート処理の最も一般的な使用例を紹介します。

12.3.1 事例1: 開発インスタンスと本稼働インスタンス間のインポートとエクスポート

この事例では、ポータルのページ・グループとポートレットを、Oracle Portalの開発インスタンスと本稼働インスタンス間でコピーまたは更新する手順を説明します。

注意:

ユーザーのパーソナライズはエクスポートされないため、ソースのページまたはポートレット上のパーソナライズは一切エクスポートまたはインポートされません。

シナリオ1: ページとコンテンツをターゲットのポータル・システムにエクスポートします。ターゲット・システムに対する最初のエクスポートでは、ページ・グループ全体を移行する必要があります。次の手順は、処理の概要を示しています。

1. ソース・システム上で、ページ・グループ、アプリケーションおよびコンテンツを開発します。

2. エクスポートするページ、アプリケーションおよびコンテンツを特定し、それに応じてトランスポート・セットを作成して、ターゲット・システムにエクスポートします。

3. トランスポート・セットをターゲット・システムのポータル・リポジトリにインポートします。

シナリオ2: ターゲット・インスタンスのコンテンツを更新します。Oracle Portalは、次の場合のみ、ターゲット・システムのアイテムとリージョン・レベルのコンテンツの更新をサポートしています。

ソースからターゲットのインスタンスにすべての変更をエクスポートおよびインポートする場合。ターゲット・システムのすべてのページ構造、コンテンツおよびユーザー設定項目が、ソース・システムのコンテンツで置き換えられます。ターゲット・システムへの最初のエクスポートでは、ソース・ポータルからターゲット・ポータル・インスタンスに、ページ・グループ全体を移行します。

コンテンツをエクスポートおよびインポートする推奨方法の詳細は、第12.9項「エクスポートおよびインポート時の推奨方法」を参照してください。

12.3.2 事例2: 複数のポータル・インスタンス間での同一コンテンツの配置

「トランスポート・セットの取得」ポータルを使用してデータをトランスポートするとともに、移行ツールexpおよびimpを使用して複数のOracle Portalインスタンスにわたって同一のコンテンツを配置することもできます。この事例では、Oracle Portalのオブジェクト(ポートレット、ページ・グループなど)を1つのインスタンスで作成した後、移行ユーティリティexpおよびimpを使用して、そのオブジェクトを複数のインスタンスへ伝播します。詳細は、『Oracle Fusion Middleware管理者ガイド』の、本番環境からテスト環境へのステージングに関する説明を参照してください。

12.3.3 事例3: 複数のソースのコンテンツ統合

Oracle Portalのエクスポートおよびインポート機能を使用して、複数のポータル・インスタンスのコンテンツをターゲットとなる1つのポータル・インスタンスに移行する場合は、次の点を考慮する必要があります。

- インポート元となる複数のポータル・インスタンス上で、同じ名前のオブジェクトを作成しないでください。これにより、共有オブジェクト間でのネームスペースの競合を回避できます。たとえば、ソース・インスタンス(source1とsource2)に共有テンプレート(shared_tempate1)を作成し、source1とsource2それぞれのページ・グループ(pgrp1とpgrp2)が使用するとします。この場合、source1とsource2の2つのページ・グループを1つのターゲット・インスタンスに統合しようとすると、2つのページ・グループが同じ名前を持つ別々の共有テンプレート(shared_template1)を使用しているため、事前チェック・エラーが発生します。

- 同じ名前を持つ複数のページ・グループを作成しないでください。たとえば、ソース・インスタンスsource1とsource2にページ・グループpgrp1をそれぞれ作成した場合、これら2つのページ・グループを1つのターゲット・インスタンスに統合することはできません。この注意事項は、データベース・プロバイダのオブジェクト名、共有コンポーネント名、Webプロバイダ名、データベース・プロバイダ名にも適用されます。

12.4 Oracle Portalでのエクスポート

この項では、Oracle Portalでエクスポートを実行する方法について説明します。この項には次のトピックが含まれます:

- Oracle Portalのエクスポート - 推奨方法

- Oracle Portalのエクスポート - 別の方法

12.4.1 Oracle Portalのエクスポート - 推奨方法

この項では、Oracle Portalのコンテンツをエクスポートまたはインポートする際に推奨される方法について説明します。次のトピックが含まれます:

- Oracle Portalのエクスポート機能

- トランスポート・セットの管理方法

12.4.1.1 Oracle Portalのエクスポート機能

この項では、ソース・ポータル・システムからコンテンツを正しく転送するために必要な次のエクスポート処理と手順について説明します。

- トランスポート・セットの作成

- データのエクスポート

- コマンドラインからの大容量のページ・グループのエクスポート

12.4.1.1.1 トランスポート・セットの作成

システム要件を確認したら、次にトランスポート・セットを作成する必要があります。図12-1は、プロセスを図で示しています。

注意:

競合の問題が発生しないように、1人のユーザーが1つのトランスポート・セットを管理するようにしてください。

図12-1 エクスポート処理

1. 「ナビゲータ」または「一括操作」(一度に複数のページをエクスポート・トランスポート・セットに追加できます)で、エクスポートするページ・グループまたはルート・ページを選択します。トランスポート・セット・マネージャが表示されます。

2. 名前を選択し、トランスポート・セットの一部として、アクセス制御とプリファレンスを含めるか、外部オブジェクトと子オブジェクトを含めるかを選択します。「次へ」をクリックすると、トランスポート・マニフェストが生成されます。

3. 依存性の計算が終了したら、「マニフェストの表示」をクリックし、「トランスポート・セットのエクスポート」ページを表示して結果を確認します。マニフェストは、トランスポート・セット内のオブジェクトをリストにしたもので、エクスポートを詳細に制御するために使用されます。この項の「インポート・モードの処理」で説明しているように、明示オブジェクトおよび参照しているオブジェクトに対して、「インポート時に置換」オプションが適切に設定されていることを確認します。接続先ポータルで必要な外部オブジェクトがあれば、トランスポート・セットに追加します。これでトランスポート・セットをエクスポートできるようになりました。

4. 「今すぐエクスポート」をクリックしてエクスポートを開始します。この手順でデータが抽出され、トランスポート表にデータが入力されます。エクスポート・プロセスの詳細は、第12.4.1.1.2項「データのエクスポート」を参照してください。

エクスポート・トランスポート・セット・マネージャによって、トランスポート・セット内のオブジェクトのすべての依存性が正しく抽出されます。具体的には、依存性マネージャは、明示的にエクスポートされるオブジェクトとどのような関係にあるかに基づいて、各オブジェクトを、明示的に選択、参照、外部または子に分類します。この情報はマニフェストに表示されます。図12-2を参照してください。オブジェクトは次のように分類されます。

- 「明示的に選択されたオブジェクト」:「ナビゲータ」または「一括操作」で、エクスポート対象として明示的に選択されたオブジェクトです。

- 「参照しているオブジェクト」:明示的に選択されたオブジェクトが直接または間接的に参照しているが、常に明示オブジェクトとして同じページ・グループ内にあるオブジェクトです。たとえば、ページで使用されているスタイルは、それが同じページ・グループに属している場合は、参照しているオブジェクトになります。

- 「外部オブジェクト」:外部オブジェクトによって、明示的に選択されたオブジェクトはターゲット・ポータルで機能するようになります。たとえば、外部プロバイダとデータベース・スキーマは、外部オブジェクトとみなすことができます。一般的には、共有オブジェクトおよびコンポーネントは、明示的に選択されていない場合は外部オブジェクトとなります。

- 「子オブジェクト」:階層に含まれているオブジェクトです。たとえば、サブページ、サブカテゴリ、サブパースペクティブは、それぞれページ、カテゴリ、パースペクティブの子オブジェクトです。

注意:

- 参照しているオブジェクトに子オブジェクトが含まれている場合、それらの子オブジェクトは再使用モードでインポートされます。そのため、参照しているオブジェクトを明示的に選択し、トランスポート・セットに含める必要があります。これにより、インポート・モードを「インポート時に置換」に設定できます。ページ・グループを再使用モードでインポートする前に、ページ・グループのプロパティを書き留めておいてください。ページ・グループを手動でインポートした後、変更内容を更新して以前のプロパティを反映させます。

- 子オブジェクトは、明示オブジェクトのみを対象に移行用として選択されます。参照セクションに親ページ、カテゴリまたはパースペクティブが表示される場合、子オブジェクトは選択されません。詳細は、表12-12 「子オブジェクトのインポート動作」を参照してください。

- 明示オブジェクトおよび参照オブジェクトのコンテナは、外部の依存性として移行されます。

インポート・モードの処理

マニフェストには、インポート・モードの制御に関する精度レベルが用意されています。マニフェストは、トランスポート・セット内のオブジェクトのリストです。インポートでは、次の2つのモードを使用できます。

- 「インポート時に置換」:ターゲットのオブジェクトが存在する場合は、置き換えられます。オブジェクトが存在しない場合は、作成されます。このモードが選択されていなくて、オブジェクトが存在する場合は、ターゲット・ポータルのオブジェクトはそのまま保持されます。ただし、ターゲットにオブジェクトが存在しない場合は、オブジェクトが作成されます。

- 「インポートの再使用」:ターゲットにオブジェクトが存在しない場合は、作成されます。すでに存在する場合は、そのまま保持されます。

表12-3に、オブジェクトの分類とデフォルトのモードを示します。

表12-3 デフォルトのモード

オブジェクトの分類

デフォルトのインポート・モード

明示的に選択されたオブジェクト

インポート時に置換

参照しているオブジェクト

再使用

子オブジェクト

インポート時に置換

外部オブジェクト

再使用

図12-2は、トランスポート・セットのマニフェストの例です。

図12-2 トランスポート・セットのマニフェスト

たとえば、明示的に選択されたオブジェクトの名前をクリックすると、子オブジェクト、参照オブジェクトおよび外部オブジェクトの詳細ビューが表示されます。オブジェクトは、ツリー形式でも表形式でも表示できます。図12-3は、マニフェストの詳細画面のツリー表示の一例です。

図12-3 マニフェストの詳細画面

注意:

編集可能な生成済アイテム・タイプが抽出されます。生成済のタイプは編集しないでください。これらを抽出する場合は、既存の生成済タイプに基づいて、共有オブジェクトのページ・グループでカスタム・タイプを作成します。依存性マネージャによってこれらはマニフェストに追加されます。

12.4.1.1.2 データのエクスポート

ソースからターゲット・インスタンスにポータル・コンテンツをエクスポートおよびインポートする前に、第12.8項「移行後のオブジェクトの動作」を参照してください。

注意:

ポートレットに関連するポートレット・リポジトリ情報(セキュリティや編成など)は、エクスポートおよびインポート処理では移行されません。

オブジェクトをエクスポートするには、次の手順を実行します。

1. エクスポートするオブジェクトを選択します。「ナビゲータ」を使用するか、または検索結果でページ・グループの「一括操作」を使用します。図12-4を参照してください。

注意:

ポートレット(Portalフォーム、Portalレポート、チャート、動的ページ)を参照するポータル・ページまたはページ・グループをエクスポートする前に、必ずこれらのポートレットをエクスポートしてください。

図12-4はPortalナビゲータの一例です。

図12-4 Portalナビゲータ

2. 「エクスポート」、「ページ・グループのエクスポート」、「ルート・ページのエクスポート」いずれかのリンクをクリックして、トランスポート・セット・マネージャを表示します。トランスポート・セットの名前はできるだけわかりやすいものにし、名前の先頭には特殊文字を使用しないようにします。たとえば、My Company Transport Set 12-NOV-2008のようにします。
図12-5は、トランスポート・セット・マネージャの例です。

図12-5 トランスポート・セット・マネージャ

3. トランスポート・セットのオブジェクトに関連付けられたアクセス制御リスト(ACL)を含める場合は、「アクセス制御とプリファレンス」を選択します。このオプションを選択した場合は、次の処理が行われます。

- オブジェクトに関連付けられたユーザーとグループが移行されます。

- オブジェクトに割り当てられている権限が移行されます。

- ユーザーに関連付けられたパラメータとイベントが移行されます。

4. 明示的に選択されたオブジェクトでエクスポートに外部オブジェクトの依存性を含めるには、「すべての外部オブジェクトをエクスポート」を選択します。

5. エクスポートに階層オブジェクトを含めるかどうかを選択します。

- 明示的に選択されたオブジェクトの子オブジェクトをすべてエクスポートに含めるには、「階層全体を含める」を選択します。

- 明示的に選択されたオブジェクトの構造のみをエクスポートに含めるには(子オブジェクトをいっさい含めないようにするには)、「オブジェクト構造のみ含める」を選択します。このオプションは、階層オブジェクト(ページ、パースペクティブおよびカテゴリ)にのみ適用されます。

6. トランスポート・セットの「ページ・オプション」を設定します。
マニフェスト表示

- 依存性マニフェストにすべてのオブジェクトを一度にレンダリングするには、「全トランスポート表示」(デフォルト)を選択します。

- ページ区切り表示を選択して、セクションごとに表示可能なオブジェクトの数をユーザー・オプションで設定できるようにします。たとえば、表示可能なオブジェクトの数を100に設定すると、ページ区切りコントロールでは1セクションに100個のオブジェクトのみを表示できます。このオプションは、レンダリング前にマニフェストのユーザー・インタフェースがタイムアウトする可能性がある大きなトランスポート・セットの場合に特に便利です。

ツリー表示

- すべての依存性を一度に表示した詳細な依存性ツリーをレンダリングするには、「全依存性表示」(デフォルト)を選択します。

- ページ区切り表示を選択して依存性を即時参照のみに制限し、ページ区切りのドリル・ダウンコントロールを使用して、子参照を横断表示するようにします。この設定は、ツリー表示レンダリングがタイムアウトする可能性がある大規模な依存性ツリーの場合に便利です。

7. 「次へ」をクリックすると、トランスポート・マニフェストが生成されます。依存性の計算が終わったら(「再問合せ」をクリックしてステータスを確認)、「マニフェストの表示」をクリックし、エクスポート/インポートの依存性マネージャを表示して結果を確認します(図12-6を参照)。この項の「インポート・モードの処理」で説明しているように、明示オブジェクトおよび参照しているオブジェクトに対して、「インポート時に置換」オプションが適切に設定されていることを確認します。接続先ポータルで必要な外部オブジェクトがあれば、トランスポート・セットに追加します。

8. 変更後に「再計算」をクリックすると、更新されたマニフェストが表示されます。
図12-6は、トランスポート・セットのオブジェクトを示しています。

図12-6 トランスポート・セット・マネージャのオブジェクト

9. 依存性の計算の後すぐにトランスポート・セットを完成させるには、「今すぐエクスポート」をクリックします。依存性の計算後に変更を行った場合、またはPortalの他のユーザーが変更を加えた可能性がある場合は、「再計算してエクスポート」をクリックすると、トランスポート・セットをエクスポートする前に依存性が再計算されます。エクスポート用としてマークされたオブジェクトは、移行用のトランスポート表にコピーされます。エクスポート処理が完了したら、「ログのエクスポートとスクリプトのダウンロード」ページが表示されます。

注意:

「今すぐエクスポート」を選択するとオブジェクトがエクスポートされます。

図12-7 「ログのエクスポートとスクリプトのダウンロード」ページ

10. 「操作のログを表示」リンクをクリックし、エラーが発生していないかどうかをトランスポート・セット・マネージャ内のログでチェックします。
図12-8は、「ログの表示」ページの一例です。

図12-8 トランスポート・セットのエクスポート・ログ

注意:

デバッグ・メッセージを含むエクスポート処理の詳細なログを表示するには、ログの上部にある「ログ情報の詳細はここで見ることができます」と表示されるリンクをクリックします。

11. ファイアウォール経由でターゲット・システムにデータを移動する場合は、「トランスポート・セットの取得」ポートレットではなく、Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトを使用する必要があります。「ログのエクスポートとスクリプトのダウンロード」ページから、オペレーティング・システムに基づいて適切なエクスポート・スクリプトを選択し、ソース・システムにダウンロードします。コマンドライン・スクリプトの使用方法の詳細は、第12.7項「Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトの使用」を参照してください。

12.4.1.1.3 コマンドラインからの大容量のページ・グループのエクスポート

opeasst.csh (Oracle Portal Export Assistant)スクリプトを使用すると、ポータルのユーザー・インタフェースを介さずに、大容量のページ・グループをすべての依存性とともにエクスポートできます。このスクリプトは、「すべての外部オブジェクトをエクスポート」オプションを有効にした状態のユーザー・インタフェースを介したトランスポート・セットのエクスポートの動作をレプリケートします。

このスクリプトにより、次のことが次の順序で実行されます。

- 指定した名前でトランスポート・セットを作成する

- 指定したページ・グループの依存性を計算し、昇格可能な外部オブジェクトがなくなるまで、すべての外部オブジェクトを反復的に昇格する

- トランスポート表にメタデータを抽出する

- トランスポート・セットの外部の依存性(存在する場合)に対してチェックリストを生成する

このスクリプトは、/portal/admin/plsql/wwuディレクトリにあります。スクリプトの例を次に示します。

%opeasst.csh
Usage: opeasst.csh -s portal_schema
-p portal_password -c connect_string
-ts transportset_name -pgrps pgrp_names
-log log_name [-export_acls]

注意:

このスクリプトを使用して、すべてのページ・グループをエクスポートできます。

表12-4で、この処理で使用するパラメータについて説明します。

表12-4 OPEASST.CSHパラメータの説明

パラメータ

説明

-s portal_schema

ポータルで使用するOracle Databaseのアカウント。

-p portal_password

ポータルで使用するOracle Databaseのパスワード。

-c connect_string

ソース・データベースのTNS接続情報。

-ts transportset_name

作成するトランスポート・セットの名前。

-pgrps pgrp_names

エクスポートするページ・グループのカンマ区切りのリスト。

注意: スクリプトを使用して生成済ページ・グループをエクスポートすることはできません。

エクスポート・チェックリストのプロセス・ログの出力先とするログ・ファイルの名前。

-export_acls

オブジェクト・レベルの権限をエクスポートします。

コマンドラインからエクスポートを実行した後で、次の手順を実行します。

1. 「ステータス」リンクをクリックし、トランスポート・セット・マネージャのログで、エラーが発生していないかどうかを確認します。システム上にあるトランスポート・セットの編集および参照方法の詳細は、第12.4.1.2項「トランスポート・セットの管理方法」を参照してください。

2. エクスポートが完了したら、トランスポート・セットを参照し、オペレーティング・システムに適切なスクリプトを選択します。詳細は、第12.7項「Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトの使用」を参照してください。

3. オプションに-mode exportを使用してスクリプトを実行します。

%MyScript.csh -mode export

これにより、スキーマ名(ソース)、パスワード、ダンプ・ファイル名などの情報を入力するよう要求されます。また、終了時にダンプ・ファイルが作成されます。

4. FTPを使用して、ダンプ・ファイルとエクスポートおよびインポート・スクリプトを、ターゲットのOracle Portalスキーマがあるコンピュータに転送します。

5. オブジェクトをインポートするには、最初にトランスポート・セットのダンプ・ファイルの内容をターゲット・システムのトランスポート・セット表にインポートする必要があります。詳細は、第12.6.1.2項「データのインポート」を参照してください。

現在は、次の機能と制限が適用されます。

- スクリプトはページ・グループのエクスポートのみをサポートしています。

- カンマで区切られた値を使用して、複数のページ・グループを一度にエクスポートできます。

- エクスポート後に、エクスポート・チェックリストのログを参照できます。これらのログは、インポート前に前提条件を特定する際に役立ちます。

- アクセス制御リストのエクスポート機能がサポートされています。

- インポート・モード・オプション(「インポート時に置換」および「インポート時に再利用」)は利用できません。

- データベース・プロバイダのエクスポートはサポートされていません。

- 依存性マネージャによって、ページ・グループの一部の外部オブジェクトをエクスポートすることになった場合は、ユーザーが処理を行わなくても、スクリプトによってすべての外部オブジェクトが自動的に明示化されます。明示化可能なこれらのオブジェクトは、再帰的に追加されてトランスポート・セットの一部となり、最終的にトランスポート・セットに外部オブジェクトは残りません。

- このスクリプト名は変更できません。

注意:

- opeasst.cshスクリプトを実行するためにデータベースに接続するときは、インフラストラクチャのOracleホーム(ORACLE_INSTANCE)に設定してください。

- Windowsオペレーティング・システム上でシェル・スクリプト・ツールを実行するには、次のUNIXエミュレーション・ユーティリティのいずれかが必要です。
— Cygwin 1.3.2.2-1以降。http://www.cygwin.com/を参照してください。

— MKS Toolkit 6.1。http://www.datafocus.com/を参照してください。

- コマンドラインを使用すると、タイムスタンプに基づいて新しいダンプが作成され、既存のダンプは上書きされずに残ります。ディスク容量を有効に利用するために、使用しない古いダンプ・ファイルは定期的に削除することをお薦めします。

12.4.1.2 トランスポート・セットの管理方法

「管理」ページの「トランスポート・セット - エクスポート・サービス」ポートレットを使用して、システム上のトランスポート・セットをエクスポート、参照および編集できます。この項では、次の内容について説明します。

- エクスポートするトランスポート・セットのブラウズ

注意:

このステータスは、取得されるトランスポート・セットに対し、ソースとターゲットの両方で「ACQUIRE_IN_PROGRESS」に設定されます。これは、トランスポート・セットのエクスポート/ブラウズ・リストで有効なステータスです。

12.4.1.2.1 エクスポートするトランスポート・セットのブラウズ

エクスポートされたトランスポート・セットに対して選択されているオブジェクトのリストを表示および編集できます。システム上のすべてのトランスポート・セットおよびそれらの現在のステータスを表示できます。また、操作のログや参照しているオブジェクトを表示し、エクスポート・スクリプトとインポート・スクリプトをダウンロードすることもできます。

トランスポート・セットを表示するには、次の手順を実行します。

1. 「トランスポート・セットのエクスポート」ポートレットに移動します。図12-9は、「トランスポート・セットのエクスポート」ポートレットを示しています。

図12-9 「トランスポート・セットのエクスポート」ポートレット

2. 「エクスポートするトランスポート・セットのブラウズ」をクリックします。図12-10は、「エクスポートするトランスポート・セットのブラウズ」画面の例です。

図12-10 エクスポートするトランスポート・セットのブラウズ

「エクスポートするトランスポート・セットのブラウズ」画面には、ソース・システム上のすべてのトランスポート・セットのステータスが表示されます。

- トランスポート・セットのエクスポート・マニフェストを表示するには、「名前」をクリックします。

- トランスポート・セットのスクリプトをダウンロードするには、対応する「スクリプト」リンクをクリックします。

- トランスポート・セットのログを表示するには、「ステータス」をクリックします。

- トランスポート・セットがインポート可能であるかどうかを検証するチェックリストを生成するには、「チェック・リストの生成」をクリックします。

- トランスポート・セットを削除するには、そのトランスポート・セットを選択して「削除」をクリックします。

トランスポート・セットを選択して「削除」をクリックすると、確認を求められます。「OK」をクリックしても、「エクスポート」、「エクスポート進行中」、「事前チェック進行中」、「移行中」、「インポート」または「インポート進行中」ステータスにあるトランスポート・セットには反映されません。

以前にエクスポートされたトランスポート・セットまたは完成された(依存性の計算が完了した)トランスポート・セットを再利用できるようにするには、そのトランスポート・セットを選択して「再使用」をクリックします。

トランスポート・セットを選択して「再使用」をクリックすると、確認を求められます。「OK」をクリックしても、「エクスポート」、「エクスポート進行中」、「移行中」、「インポート可能」、 「インポート」または「インポート進行中」のいずれかのステータスにあるトランスポート・セットには何の影響もありません。

注意:

- 「再使用」オプションは、ステータスが...であるソース・ポータルのトランスポート・セットでのみ有効です。

- 複数の階層を含むオブジェクトを、同じトランスポート・セットでインポートできます。

12.4.2 Oracle Portalのエクスポート - 別の方法

Oracle Portalのソース・インスタンスとターゲット・インスタンスが両方とも(製品メタデータ・リポジトリではなく)カスタマ・データベース・インストールに存在する場合に、コンテンツをエクスポートできます。つまり、ソースおよびターゲットのOracle Portalインスタンスが同じデータベースにあり、これらのインスタンス間にファイアウォールが存在しない場合、「トランスポート・セットの取得」サービスを使用できます。詳細は、「Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトの使用」を参照してください。

詳細は、『Oracle Fusion Middleware管理者ガイド』の本番環境からテスト環境へのステージングに関する項を参照してください。

12.5 トランスポート・セットの取得サービス

「トランスポート・セット - 取得サービス」ポートレットを使用して、次のタスクを実行します。

- ソース・ポータルの登録

- ターゲット・システムへのデータの移動

12.5.1 ソース・ポータルの登録

ソース・ポータルからデータを移動する前に、まずポータルを登録する必要があります。登録が完了すると、第12.5.2項「ターゲット・システムへのデータの移動」で説明しているように、ソース・ポータルを選択して、「トランスポート・セット - 取得サービス」ポータルでデータ・ソースを指定するために使用できます。

ソース・ポータルを登録するには、次の手順を実行します。

1. 資格証明を埋め込んだ、ソース・ポータルへのプライベート・データベース・リンク(固定ユーザー・データベース・リンクと呼ばれる)を作成します。データベース・リンクの作成方法は、第12.6.1.1項「データベース・リンクの作成」を参照してください。

2. 「トランスポート・セット - 取得サービス」ポートレットで、「ソース・ポータルの登録」をクリックすると、「ソース・ポータルの登録」画面が表示されます。図12-11は、「ソース・ポータルの登録」画面を示しています。

図12-11 「ソース・ポータルの登録」ページ

3. ソース・ポータルに一意の名前とデータベース・リンクを指定して、「Register登録」をクリックします。これで、トランスポート・セットを取得するときにソース・ポータルを選択できるようになりました。

4. ソース・ポータルに一意の名前とデータベース・リンクを指定して、「Register登録」をクリックします。これで、トランスポート・セットを取得するときにソース・ポータルを選択できるようになりました。

12.5.2 ターゲット・システムへのデータの移動

オブジェクトをインポートする前に、最初にトランスポート・セットの内容をターゲット・システムのトランスポート・セット表にインポートする必要があります。介在するファイアウォールがない場合は、次に示すように「トランスポート・セット - 取得サービス」ポートレットを使用してデータを移動します。ファイアウォール経由でデータを移動する場合、または「トランスポート・セットの取得」ポートレットを使用できないローカル構成上の考慮事項がある場合は、第12.7項「Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトの使用」に示すように、コマンドライン・スクリプトを使用してください。

「トランスポート・セットの取得」ポートレットを使用して内容を移動するには、次の手順を実行します。

1. 「トランスポート・セット - 取得サービス」ポートレットで、「管理」ページの「ソース・ポータルのブラウズ」をクリックし、データの移動元であるソース・ポータルがターゲット・インスタンスに登録されていることを確認します。
ソース・ポータルがまだ登録されていない場合には、「トランスポート・セットの取得」ポートレットで「ソース・ポータルの登録」をクリックし、第12.5.1「ソース・ポータルの登録」に示すようにソース・ポータルを登録します。

2. 「トランスポート・セット - 取得サービス」ポートレットから「トランスポート・セットの取得」をクリックすると、「トランスポート・セットの取得」ページが表示されます。

図12-12 トランスポート・セットの取得

3. ソース・ポータルとトランスポート・セットを指定し、「獲得」をクリックすると、データの転送が開始されます。

4. 転送が完了したら、「マニフェストの表示」をクリックし、トランスポート・セットのマニフェストを表示します。明示的に選択したオブジェクトをクリックすると、詳細なマニフェストが表示されます。「ツリー表示」をクリックすると、ネストされた依存性が表示されます。

5. 「閉じる」をクリックしてマニフェストに戻ってから「即時事前チェック」をクリックすると、転送されたデータの事前チェックが実行されます。すべてのオブジェクト依存性が解決されていることが確認されます。

6. 事前チェックが完了したら「マニフェストの表示」をクリックして、ステータス列にエラーがないことを確認します。ステータス・アイコンを確認するには、表12-7を参照してください。エラーをすべて解決してからトランスポート・セットのインポートを続行します。

12.6 Oracle Portalでのインポート

この項では、Oracle Portalでインポートを実行する方法について説明します。この項には次のトピックが含まれます:

- Oracle Portalのインポート - 推奨方法

12.6.1 Oracle Portalのインポート - 推奨方法

この項では、「トランスポート・セット - 取得サービス」ポータルを使用して、ターゲット・ポータル・システムにコンテンツを正しく転送するために必要な次のインポート処理と手順について説明します。

- データベース・リンクの作成

- ソース・ポータルの登録

- ターゲット・システムへのデータの移動

- データのインポート

- トランスポート・セットの管理方法(インポート)

12.6.1.1 データベース・リンクの作成

「トランスポート・セットの取得」機能は、固定ユーザー・データベース・リンクを使用して、ソース・データベースからデータを引き出します。アプリケーションが固定ユーザー・データベース・リンクを使用すると、ローカル・サーバーは常に、リモート・データベース内の固定リモート・スキーマへの接続を確立します。アプリケーションがリンクを使用してリモート・データベースにアクセスすると、ローカル・サーバーもまた、ネットワーク経由で固定ユーザーの資格証明を送信します。

データベース・リンクを作成するには、次の手順を実行します。

1. 「Portalビルダー」ページで、「ナビゲータ」リンクをクリックします。

2. 「データベース・オブジェクト」タブをクリックします。

3. 「名前」列で、リンク先のスキーマまでスクロールし、スキーマの名前をクリックします。

4. 「新規作成」→「データベース・リンク」をクリックします。

5. データベース・リンクの特定に使用する「データベース・リンク名」を入力します。
例: mydb.mydomain@remotedb

6. 完成したデータベース・リンクを所有するスキーマを選択してから「次へ」をクリックします。スキーマ・アクセス権限として「管理」が付与されたスキーマのみがリストに表示されます。

7. 表12-5に示すようにデータベース接続フィールドへの入力を完了してから「次へ」をクリックします。

表12-5 データベース接続情報

フィールド

説明

現行ユーザー

Oracle Portalへのログインに使用するのと同じユーザー名とパスワードを使用して、リモート・データベースにログインする場合に選択します。

特定ユーザー

Oracle Portalへのログインに使用するものとは異なるユーザー名とパスワードを使用して、リモート・データベースにログインする場合に選択します。

ユーザー名

現行ユーザーまたは特定ユーザーとして自動的にデータベースにログインする場合は、「ユーザー名」および「パスワード」を入力します。「ユーザー名」と「パスワード」を入力しない場合には、リンクを使用してデータベースにログインしようとすると、ログイン・ダイアログ・ボックスが表示されます。

「ユーザー名」および「パスワード」は、リモート・データベース内で有効なユーザー・アカウントである必要があります。

パスワード

データベースの「ユーザー名」に対するパスワードを入力します。

8. データベースの「TNS名」を入力するか、または「ホスト・アドレス」、 「ホスト・サービス名」、「ホスト・プロトコル」および「ホスト・ポート」を入力してから、「終了」をクリックします。

データベース・リンクを作成したら、第12.5.1項「ソース・ポータルの登録」に示すように、そのデータベース・リンクを登録します。登録されたソース・ポータルを介してリンクが確立されると、ソース・ポータルで「エクスポート完了」状態であるトランスポート・セットのいずれかを選択し、第12.5.2項「ターゲット・システムへのデータの移動」で説明しているように、「トランスポート・セット - 取得サービス」ポータルを使用して、選択したトランスポート・セットをターゲットに移動できます。取得プロセスでは、データベース・リンクを介してバッチ内のトランスポート・セット・データが1つずつ引き出され、プロセスが終了するとユーザーに通知されます。

コマンドラインからのデータベース・リンクの作成

データベース・リンクは、SQL *Plusを次の構文で使用して、コマンドラインから作成することもできます。

create database link <link_name> connect to <source-portal> identified by "<source-portal-password>" using '<net-service-name>';

説明:

表12-6 データベース・リンクの構文

パラメータ

説明

link_name

リンクのユーザー定義名。

source-portal

このポータルのソースとして登録するポータル・スキーマの名前。

source-portal-password

前述のスキーマのデータベース・パスワード。

注意: Oracle 11gデータベースのパスワードは、以前のバージョンとは異なり、デフォルトで大文字と小文字が区別されます。パスワードの大文字と小文字の区別を保持するには、パスワードを二重引用符で囲む必要があります。

net-service-name

別名または完全な接続記述子($TNS_ADMIN/tnsnames.oraから取得)。

例:

create database link mylink1 connect to portal12 identified by "******"

使用

'(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = xmlns.oracle.com)(PORT = 1521)))

(CONNECT_DATA =

(SERVER=DEDICATED)

(SERVICE_NAME = abcd.oracle.com)))'

SQL *Plusを使用したデータベース・リンクの作成方法の詳細は、『Oracle Database管理者ガイド』のデータベース・リンクの作成に関する項を参照してください。

データベース・リンクを作成したら、第12.5.1項「ソース・ポータルの登録」に示すように、そのデータベース・リンクを登録し、第12.5.2項「ターゲット・システムへのデータの移動」に示すように、「トランスポート・セット - 取得サービス」ポータルを使用してターゲットに移動します。

12.6.1.2 データのインポート

オブジェクトをインポートするには、最初にトランスポート・セットのコンテンツをターゲット・システムにインポートする必要があります。インポートするトランスポート・セットを選択すると、事前チェック・プロセスによって、そのオブジェクトがターゲットに存在しているかどうかが判断されます。

コンテンツをインポートするには、次の手順を実行します。

1. 「トランスポート・セットのインポート」ポートレットを探します。デフォルトでは「管理」タブにインストールされています。

注意:

トランスポート・セットをインポートするときに、「トランスポート・セットのブラウズ」リンクをクリックすると、新しくインポートしたトランスポート・セット(ステータスは「エクスポート完了」)とエクスポート・スクリプトへのリンクが表示されます。

ターゲットのトランスポート・セットで「再使用」を選択すると、トランスポート・セットがリセットされます。これにより、ターゲット・インスタンスからトランスポート・セットがエクスポートされず、トランスポート・セット内のオブジェクトと一致するオブジェクトが存在しないため、トランスポート・セットが使用できなくなります。

2. インポートしたトランスポート・セットを選択し、「インポート」をクリックします。インポート・マネージャの「オブジェクト」ページが表示されます。
図12-13は、インポート対象となっているオブジェクトのリストが表示された「オブジェクト」ページです。

図12-13 トランスポート・セット・マネージャのインポート・オブジェクト

3. 「インポート時に置換」を選択すると、オブジェクトがターゲット・ポータルで見つかった場合、そのオブジェクトが置き換えられます。

注意:

明示的に選択されたオブジェクトのデフォルト・モードは「インポート時に置換」です。参照オブジェクトのデフォルト・モードは「再使用」です。明示的に選択しないかぎり、外部オブジェクトにはインポート・モードを適用できません。

4. ログ出力を表示するには、「ステータス」アイコンをクリックします。各ステータスの説明は表12-7を参照してください。

表12-7 ステータスの説明

ステータス

説明

正常終了

失敗

警告付きで終了

図12-14は、「ログの表示」ページの一例です。

図12-14 トランスポート・セット・マネージャのインポート・ログ

注意:

デバッグ・メッセージを含むインポート処理の詳細なログを表示するには、トランスポート・セット・ログの上部にある「ログ情報の詳細はここで見ることができます」と表示されるリンクをクリックします。

5. 「閉じる」をクリックして、「オブジェクト」ページに戻ります。

6. 「メイン」タブをクリックします。

図12-15 「トランスポート・セットのインポート」ページ

7. トランスポート・セットのオブジェクトに関連付けられたアクセス制御リスト(ACL)を含める場合は、「アクセス制御とプリファレンス」オプションの「アクセス制御とプリファレンス」を選択します。

注意:

エクスポート処理の実行中に「アクセス制御リストのインポート」オプションを選択しなかった場合は、このオプションを選択できません。

このオプションを選択した場合は、次の処理が行われます。

- グループのプロファイルは、それらがターゲットに存在しない場合にのみ作成されます。

- ユーザーとグループのプロファイルは、次回のインポートで更新されません。ユーザーのデフォルト・グループは、インポートされません。

- ユーザーがターゲットに存在する場合、そのユーザーのデフォルト・グループはOracle Internet Directoryに基づいて設定されます。

8. 変更を加えている場合、インポートの前に警告またはエラーを解決するには「再度事前チェック」を選択し、トランスポート・セットをインポートする前に事前チェックするには「事前チェックしてインポート」を選択し、事前チェックを行わずにトランスポート・セットをインポートするには「今すぐインポート」を選択し、変更を保存して後でトランスポート・セットに戻るには「保存して閉じる」を選択します。

注意:

9. エラーがあるかどうか、ログを調べます。
すべてのコンテンツが正常にインポートされたことを確認するには、次の事項を確認します。

- ナビゲータで、インポートしたポータル・ページ・グループのコンテンツが正しくインポートされているかどうかを確認します。特に、各ポータル・ページで、適切なポートレットがポータル・ページの各リージョンに表示されるかどうかを確認します。これらのポートレット(ナビゲーション・ページ、ポートレットとして公開されているページ、データベース・プロバイダのコンポーネントまたはWebポートレット)が、外部の依存性として表示され、ターゲットに存在しない場合、ポートレット・エントリがページから削除されます。

注意:

インポート中に、2段階の事前チェックが実行されます。「ログの表示」をクリックすると、処理の最初の段階と、完全な事前チェックの両方が表示されます。これは、インポートの前、およびポータル表にデータを入力する前に行われます。

「ログのリフレッシュ」をクリックすると、処理の第2段階およびタイムスタンプの異なる事前チェックの両方が表示されます。

インポート時の失敗と警告

インポートされるオブジェクトは、2つのタイプに分類できます。

- 警告のタイプ - 失敗時に、明示的に選択されたオブジェクトに警告が連鎖するオブジェクト。

- 失敗のタイプ - 失敗時に、明示的に選択されたオブジェクトに失敗が連鎖するオブジェクト。

警告のタイプのオブジェクトでは警告が発生し、明示的に選択したオブジェクトをインポートできます。失敗のタイプのオブジェクトは、インポートされません。

明示的に選択されたオブジェクトに警告のタイプと失敗のタイプの2つの依存性があり、両方の依存性が事前チェック・プロセスに失敗した場合は、失敗のタイプが優先され、明示的に選択したオブジェクトは失敗します。

警告のタイプは、他の種類のオブジェクトよりも、明示的に選択したオブジェクトに影響します。参照オブジェクトと外部オブジェクトは、明示的に選択したオブジェクトを対象に、そのタイプに基づいて失敗および警告を生成します。表12-8に、警告または失敗の動作をオブジェクトごとに示します。

表12-8 警告または失敗のタイプ

オブジェクト

タイプ

予期される動作

属性

失敗

依存する属性が失敗すると、明示的に選択されたオブジェクトは失敗します。

アイテム・タイプ

失敗

依存するアイテム・タイプが失敗すると、明示的に選択されたオブジェクトは失敗します。

ページ・タイプ

失敗

依存するページ・タイプが失敗すると、明示的に選択されたオブジェクトは失敗します。

スタイル

警告

スタイルは、それが属するページ・グループのメイン・スタイルに設定されます。

カテゴリ

警告

カテゴリはnoneに設定されます。

パースペクティブ

警告

アイテムまたはページに関連付けられたパースペクティブは削除されます。

ページのPortalテンプレート

失敗

依存するテンプレートが失敗すると、明示的に選択されたオブジェクトは失敗します。

アイテムのPortalテンプレート

警告

アイテムまたはページに関連付けられたアイテムのPortalテンプレートは削除されます。

HTMLテンプレート

警告

アイテムまたはページに関連付けられたHTMLテンプレートは削除されます。

ページ

警告

ページが別のオブジェクトに依存しているときは、3つの結果が考えられます。

- ポートレットとして公開されているページ。ページ・ポートレットが含まれるリージョンからポートレット・エントリが削除されます。

- ページを指すページ・リンク。リンク先のページが失敗したため、ページ・リンクがリージョンから削除されます。

- ページ・パラメータとイベント依存性。失敗したページを指していたリンクは、ページ・パラメータとイベント・リンクが配置されているページを指すようにリセットされます。

ナビゲーション・ページ

警告

ナビゲーション・ページ・ポートレットはページから削除されます。インポート後、ページを別のナビゲーション・ページに関連付けることができます。

色、フォント、JavaScript、アプリケーション・テンプレート、イメージ

警告

実行時にデフォルトに設定されます。

その他のプロバイダ(DBプロバイダ、Webプロバイダ、WSRPプロバイダ)

警告

参照されているページのポートレット・インスタンスが削除されます。詳細は、「ポートレット・クリーンアップ」を参照してください。

エクスポート対象として選択した子オブジェクトがターゲットに存在しないため、次に示すコンテナ・オブジェクトが外部依存性として表示された場合、明示的に選択されたオブジェクト(コンテナ・オブジェクトの子オブジェクト)は失敗します。

- ページ・グループ

- Portal DBプロバイダ

- カテゴリ

- パースペクティブ

- ページ

連鎖する警告動作

事前チェック中にオブジェクトで検出された警告または失敗は、表12-9のように動作します。

表12-9 連鎖する警告動作

オブジェクト

警告ステータス

失敗ステータス

含まれるオブジェクト

ステータスは、コンテナ・オブジェクトに連鎖します。

ステータスは、コンテナ・オブジェクトに連鎖します。

階層オブジェクト

- ステータスは、すべての親オブジェクトに連鎖します。

- ステータスは、子オブジェクトに連鎖しない。

- ステータスは、すべての子オブジェクトに連鎖します。

- ステータスは、すべての親オブジェクトに連鎖します。

参照しているオブジェクト

ステータスは、参照しているオブジェクトすべてには連鎖しない。

ステータスは、すべての参照しているオブジェクトに連鎖します。

ポートレット・クリーンアップ

インポートされるポートレットは、インポート・プロセス中にターゲットのポートレット・リポジトリと同期します。インポート処理の解決フェーズ中に失敗したポートレット・インスタンスは、ソース・ページから削除されます。

たとえば、ページには、次のいずれかのポートレットを含むことが可能です。

- ナビゲーション・ページ

- ポートレットとして公開されているページ

- データベース・ポートレット(登録済または組込み)

- Web/WSRPポートレット(登録済または組込み)

これらのポートレットが、再使用モードで外部の依存性として表示され、ターゲット・ページに存在しない場合、ポートレット・インスタンスはページから削除されます。これらの依存性が明示化されていて、そのインポートに失敗した場合も、ポートレット・インスタンスが削除されます。

つまり、インポートしたポートレットがターゲットのポートレット・リポジトリに存在しない場合、そのポートレットはソース・ページから削除されます。

注意:

ポートレットのクリーンアップ操作では、ページ・パラメータとイベント、URL、テキストなどのポートレットの依存性が削除されます。ソース・ページからポートレット・インスタンスを削除した後も、ページ構造は元の状態のまま変わりません。

ナビゲーション・ページ(外部の依存性)がターゲット・ページに存在しない場合、ナビゲーション・ページを使用するページは警告付きで渡され、ナビゲーション・ページ・ポートレットはソース・ページから削除されます。

12.6.1.3 トランスポート・セットの管理方法(インポート)

「管理」ページの「トランスポート・セット インポート・サービス」ポートレットを使用して、システム上のトランスポート・セットをインポート、参照および編集できます。この項では、次の内容について説明します。

- インポートするトランスポート・セットのブラウズ

注意:

このステータスは、取得されるトランスポート・セットに対し、ソースとターゲットの両方で「ACQUIRE_IN_PROGRESS」に設定されます。これは、トランスポート・セットのエクスポート/ブラウズ・リストで有効なステータスです。

インポートするトランスポート・セットのブラウズ

インポートされたトランスポート・セットに対して選択されているオブジェクトのリストを表示および編集できます。システム上のすべてのトランスポート・セットおよびそれらの現在のステータスを表示できます。また、操作のログや参照しているオブジェクトを表示し、チェックリストを生成することもできます。

トランスポート・セットを表示するには、次の手順を実行します。

1. 「トランスポート・セットのインポート」ポートレットに移動します。図12-16は、「トランスポート・セットのインポート」ポータルを示しています。

図12-16 「トランスポート・セットのインポート」ポートレット

2. 「インポートするトランスポート・セットのブラウズ」をクリックします。図12-17は、「インポートするトランスポート・セットのブラウズ」画面の例です。

図12-17 インポートするトランスポート・セットのブラウズ

「インポートするトランスポート・セットのブラウズ」ページには、ソース・システム上のすべてのトランスポート・セットのステータスが表示されます。

トランスポート・セットのエクスポート・マニフェストを表示するには、「名前」をクリックします。

トランスポート・セットのログを表示するには、「ステータス」をクリックします。

トランスポート・セットを削除するには、そのトランスポート・セットを選択して「削除」をクリックします。

トランスポート・セットを選択して「削除」をクリックすると、確認を求められます。「OK」をクリックしても、「エクスポート」、「エクスポート進行中」、「事前チェック進行中」、「移行中」、「インポート」または「インポート進行中」ステータスにあるトランスポート・セットには反映されません。

トランスポート・セットがインポート可能であるかどうかを検証するチェックリストを生成するには、「チェック・リストの生成」をクリックします。

12.7 Oracle Portalのエクスポートおよびインポートのコマンドライン・スクリプトの使用

ソース・インスタンスとターゲット・インスタンスの間に介在するファイアウォールがある場合は、Oracle Portalのエクスポートとインポートのコマンドライン・スクリプトを使用して、トランスポート・セットを移動する必要があります。この処理は、次の内容で構成されます。

- コマンドライン・スクリプトのダウンロード

- スクリプトの実行によるエクスポート・ダンプ・ファイルの作成

- ターゲット・システムへのトランスポート・セット表のインポート

12.7.1 コマンドライン・スクリプトのダウンロード

Internet Explorerで「スクリプトのダウンロードとログの表示」のページを使用して、次のようにスクリプトをダウンロードします。

1. 選択したスクリプトを右クリックし、「対象をファイルに保存」をクリックします。

2. 名前を変更し、正しいファイル拡張子(UNIXの場合は.csh、NTの場合は.cmd)を付加します。たとえば、MyScript.cshのようになります。

3. エクスポート・スクリプトを実行するファイル・システムのディレクトリにファイルを保存します。通常、このディレクトリはエクスポート・ポータルがある場所です。

注意:

この場所には、データベースへのアクセス権限が必要です。システムによっては、ダウンロードしたUNIXスクリプトに対し、実行前に適切な実行権限を設定する必要があります。エクスポート・スクリプトは編集しないでください。

12.7.2スクリプトの実行によるエクスポート・ダンプ・ファイルの作成

エクスポート処理の次の手順では、前の項で作成したスクリプトを使用してトランスポート・セットのダンプ・ファイルを作成し、エクスポート・データをターゲット・システムに転送します。

1. 次の例に示すパラメータを指定して、スクリプトを実行します。この例では、スクリプト名がMyScript.cshであると仮定しています。太字のパラメータは、エクスポートの場合にのみ適用する必須のパラメータです。

%MyScript.csh
Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
<-s portal_schema><-p portal_password> <-pu portal_username>
<-pp portal_userpassword> <-company company_name> <-c connect_string>
<-d dump_file_names> <-dir directory_object> <-sp source_portal>
<-automatic_merge>

注意:

- エクスポート・スクリプトを実行する場合は、インフラストラクチャのOracleホーム(ORACLE_INSTANCE)を設定してください。

- company_nameパラメータの値は、ホストされるポータルで作業中にログイン・ページに表示される会社名です。ホストされるポータル以外で作業している場合、このパラメータの値はnoneになります。対話モードでスクリプトを実行している場合は、値を渡さないでください。エクスポート・スクリプトは編集しないでください。

表12-10で、このプロセスで使用できるパラメータについて説明します。

表12-10 パラメータの説明

パラメータ

説明

-mode

エクスポート/インポート・コマンドライン・ユーティリティを起動するモード。

EXPORTモード: Oracle Database expユーティリティを使用して、コンテンツをダンプ・ファイルにエクスポートします。

IMPORTモード: Oracle Database impユーティリティを使用して、コンテンツをダンプ・ファイルにインポートします。

EXPORTDPモード: Oracle Databaseのexpdp (ORACLE DATAPUMP EXPORT)ユーティリティを使用して、コンテンツをダンプ・ファイルにエクスポートします。

IMPORTDPモード: Oracle Databaseのimpdp (ORACLE DATAPUMP EXPORT)ユーティリティを使用して、コンテンツをダンプ・ファイルからインポートします。

-s portal_schema

ポータルで使用するOracle Databaseのアカウント。

-p portal_password

ポータルで使用するOracle Databaseのパスワード。

-pu portal_username

ポータルにログインするための軽量ユーザー名。

-pp portal_userpassword

ポータルにログインするための軽量ユーザー・パスワード。

-company company_name

会社名(ORACLEなど)。

-c connect_string

リモート・データベースへのTNS接続情報。

-d dump_file_names

Oracleエクスポート・ユーティリティまたはインポート・ユーティリティが読込みや書込みを行うファイルの名前。複数のファイル名を指定する場合は、各ファイル名をカンマで区切る必要があります。

たとえば、FILE1.DMP,FILE2.DMPのように指定します。

注意: 複数のファイル名を指定しない場合は、エクスポート処理またはインポート処理の実行時に、必要に応じて別のファイル名を指定するよう要求されます。

-dir directory_object

Oracleのexpdp/impdpユーティリティのディレクトリ・オブジェクト。
directory_objectは、(実際のディレクトリの名前ではなく)データベース管理者(DBA)がSQL CREATE DIRECTORYコマンドを使用して作成したデータベース・ディレクトリ・オブジェクトの名前です(適用可能なモード => EXPORTDP / IMPORTDP)。

-sp source_portal

ソース・ポータルのOracle Databaseアカウント(適用可能なモード => IMPORTDP)。Datapumpインポートでは、ダンプからターゲットにスキーマ・オブジェクトをマップするためにこの情報が必要です。

-automatic_merge

ダンプ・ファイルの内容を自動的にインポートします(適用可能なモード => IMPORT / IMPDP)。

-automatic_precheck

ダンプ・ファイルの内容を自動的に事前チェックします(適用可能なモード => IMPORT / IMPDP)。

注意:

IMPORTユーティリティでは、EXPORTユーティリティを使用して作成されたダンプのみを読み取ることができます。IMPDPユーティリティでは、EXPDPユーティリティを使用して作成されたダンプのみを読み取ることができます。

2. エクスポート・データを転送します。これを行うには、次の手順を実行します。

1. オプションに-mode exportまたは-mode exportdpを使用してスクリプトを実行します。たとえば、EXPORTモードでこのスクリプトを実行するには、次のようにします。

myscript1.csh -mode export -s myportal -p myportal123 -c mydb -d myexport.dmp

または、EXPORTDPモードでこのスクリプトを実行するには、次のようにします。

myscript1.csh -mode exportdp -s myportal -p myportal123 -c mydb -d myexport.dmp -dir expimp_dir

expimp_dirは、SQL*Plusセッションのcreate directoryコマンドを使用して作成された論理ディレクトリで、サーバー上の任意の物理ディレクトリにマップされます。

2. 最後にFTPを使用して、ダンプ・ファイルとエクスポートおよびインポート・スクリプトを、ターゲットのOracle Portalスキーマがあるコンピュータに転送します。

12.7.3 ターゲット・システムへのトランスポート・セット表のインポート

最後の手順として、コマンドライン・スクリプトを使用してターゲット・システムにトランスポート表をインポートします。エクスポートで使用したものと同じスクリプトをコールしますが、ここでは-modeパラメータをimportまたはimportdbに設定します。太字のパラメータは、インポートの場合にのみ適用する必須のパラメータです。パラメータの詳細は、表12-10を参照してください。

%MyScript.csh
Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
<-s portal_schema><-p portal_password> <-pu portal_username>
<-pp portal_userpassword> <-company company_name> <-c connect_string>
<-d dump_file_names> <-dir directory_object> <-sp source_portal>
<-automatic_merge>

Example to run the script in IMPORT mode:
myscript1.csh -mode import -s myportal -p myportal123 -pu expimp_usr
-pp expimp_usr123 -company ORACLE -c mydb -d myexport.dmp

Example to run the script in IMPORTDP mode:
myscript1.csh -mode importdp -s myportal -p myportal123 -pu expimp_usr
-pp expimp_usr123 -sp myportal -company ORACLE -c mydb -d myexport.dmp
-dir expimp_dir

コマンドラインからインポート全体を実行するには(バックグラウンド・プロセスが開始されます)、ポータル・ユーザー名およびパスワードのパラメータを指定する必要があります。これは、ターゲットのポータル・インスタンスでロールを検証するために必要です。

注意:

- インポート・スクリプトを実行する場合は、インフラストラクチャのOracleホーム(ORACLE_INSTANCE)を設定してください。

- -automatic_mergeオプションを使用してスクリプトを実行する前に、ターゲット・インスタンスのマニフェストに外部オブジェクトがすべて列記されていることを確認します。確認するには、-automatic_precheckオプションを使用してスクリプトを実行します。外部オブジェクトには、データベース・スキーマ、表、外部アプリケーションなどが含まれます。この情報を取得するには、ソース・インスタンスの外部オブジェクトを確認します。

- company_nameパラメータの値は、ホストされるポータルで作業中にログイン・ページに表示される会社名です。ホストされるポータル以外で作業している場合、このパラメータの値はnoneになります。対話モードでスクリプトを実行している場合は、値を渡さないでください。

ダンプ・ファイルの内容がインポートされると、ユーザー・インタフェースからトランスポート・セットを利用できるようになり、ターゲットのポータル・システムでマージできます。図12-18は、インポート処理のしくみを示しています。

図12-18 インポート処理

次の手順は、インポート処理の概要を示しています。

1. エクスポートで使用したスクリプトを使用して、トランスポート・セットのダンプ・ファイルの内容をトランスポート・セット表にインポートします。

2. インポートを開始するためにバックグラウンド・ジョブが送信され、ログ情報が生成されます。

3. インポートが終了すると、ユーザー・インタフェースからトランスポート・セットにアクセスできます。
最後の手順として、コマンドライン・スクリプトを使用してターゲット・システムにトランスポート表をインポートします。エクスポートで使用したものと同じスクリプトをコールしますが、ここでは-modeパラメータをimportまたはimportdbに設定します。太字のパラメータは、インポートの場合にのみ適用する必須のパラメータです。パラメータの詳細は、表12-10を参照してください。

%MyScript.csh
Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
<-s portal_schema><-p portal_password> <-pu portal_username>
<-pp portal_userpassword> <-company company_name> <-c connect_string>
<-d dump_file_names> <-dir directory_object> <-sp source_portal>
<-automatic_merge>

Example to run the script in IMPORT mode:
myscript1.csh -mode import -s myportal -p myportal123 -pu expimp_usr
-pp expimp_usr123 -company ORACLE -c mydb -d myexport.dmp

Example to run the script in IMPORTDP mode:
myscript1.csh -mode importdp -s myportal -p myportal123 -pu expimp_usr
-pp expimp_usr123 -sp myportal -company ORACLE -c mydb -d myexport.dmp
-dir expimp_dir

コマンドラインからインポート全体を実行するには(バックグラウンド・プロセスが開始されます)、ポータル・ユーザー名およびパスワードのパラメータを指定する必要があります。これは、ターゲットのポータル・インスタンスでロールを検証するために必要です。

注意:

- インポート・スクリプトを実行する場合は、インフラストラクチャのOracleホーム(ORACLE_HOME)を設定してください。

- -automatic_mergeオプションを使用してスクリプトを実行する前に、ターゲット・インスタンスのマニフェストに外部オブジェクトがすべて列記されていることを確認します。確認するには、-automatic_precheckオプションを使用してスクリプトを実行します。外部オブジェクトには、データベース・スキーマ、表、外部アプリケーションなどが含まれます。この情報を取得するには、ソース・インスタンスの外部オブジェクトを確認します。

- company_nameパラメータの値は、ホストされるポータルで作業中にログイン・ページに表示される会社名です。ホストされるポータル以外で作業している場合、このパラメータの値はnoneになります。対話モードでスクリプトを実行している場合は、値を渡さないでください。

ダンプ・ファイルの内容がインポートされると、ユーザー・インタフェースからトランスポート・セットを利用できるようになり、ターゲットのポータル・システムでマージできます。図12-18は、インポート処理のしくみを示しています。

図12-19 インポート処理

次の手順は、インポート処理の概要を示しています。

1. エクスポートで使用したスクリプトを使用して、トランスポート・セットのダンプ・ファイルの内容をトランスポート・セット表にインポートします。

2. インポートを開始するためにバックグラウンド・ジョブが送信され、ログ情報が生成されます。

3. インポートが終了すると、ユーザー・インタフェースからトランスポート・セットにアクセスできます。

注意:

データ整合性を維持するために、次の処理は行わないでください。

- あるオブジェクトをインポートし、名前を変更した後で再インポートします。

- あるオブジェクトをインポートし、共有オブジェクトに移動した後で再インポートします。

- オブジェクトをインポートし、ある階層から別の階層に移動します。

12.8 移行後のオブジェクトの動作

Oracle Portalのエクスポートおよびインポート機能を使用して、ソース・インスタンスからターゲット・インスタンスにポータル・コンテンツを移行する前に、次に示す事項を検討してください。この項では、移行後のOracle Portalオブジェクトの動作について説明します。

翻訳のインポート

上書きモードでの翻訳のインポートは、厳密な上書きとはなりません。この場合、翻訳がマージされているように動作します。ターゲットの不要な翻訳は、ソースに存在しない場合でも、上書きモードでのページ・グループのインポート時に削除されません。不要な翻訳は、インポート後に削除できます。ただし、ソースからの新しい翻訳は、インポートされます。この動作は、次の表のすべての関連オブジェクトの翻訳に関して有効です。

この項には次の項目が含まれています。

- 第12.8.1項「Oracle Portalオブジェクトの動作」

- 第12.8.2項「子オブジェクトのインポート動作」

- 第12.8.3項「DBプロバイダ・オブジェクトの動作」

- 第12.8.4項「Portal DBプロバイダ・レポートのオブジェクト・タイプの動作」

- 第12.8.5項「Webプロバイダの動作」

- 第12.8.6項「共有ポートレット・インスタンスの動作」

12.8.1 Oracle Portalオブジェクトの動作

この項では、次のポータル・オブジェクトの移行後の動作について説明します。

- ページ・グループ

- 属性

- 承認

- アイテム

- ページ

- リージョン

- Portalテンプレート

- HTMLテンプレート

- カテゴリ

- パースペクティブ

- ナビゲーション・ページ

- スタイル

- アイテム・タイプ

- ページ・タイプ

12.8.1.1 ページ・グループ

最初のエクスポートおよびインポートで、ページ・グループが存在しない場合は、ターゲット・システムにページ・グループが作成されます。ページ・グループ・レベルのすべての設定が、ターゲット・システムにレプリケートされます。2回目のインポートでは、選択したモードによって次のように動作します。

「インポート時に置換」モード:ソースのページ・グループのプロパティによって、ターゲットのプロパティが置き換えられます。ページ・グループ内のオブジェクトはすべて、それらが存在するかどうかに応じて作成または更新されます。

「再使用」モード:ターゲットにページ・グループがすでに存在する場合は、そのプロパティが再使用され、更新されません。ページ・グループ内に新しいオブジェクトが作成され、既存のオブジェクトは再使用されます。

注意:

- 現時点では、再使用モードを使用してページ・グループをインポートする場合、新しいページは作成されません。

- 「構成」タブに表示されるオブジェクトの順序は、ソース・ポータルとターゲット・ポータルで異なることがあります。この場合、アイテムやカテゴリなどの選択時に、ターゲット・ポータルでドロップダウン・リストが異なっているように見えます。ターゲットに表示されるオブジェクトは手動で順序変更できます。

- ページ・グループのすべての構成可能な設定は、ページ・グループの「プロパティ」をクリックすると表示される「構成」タブで適切に再使用および上書きできます。

- ページ・グループを別の名前でインポートすると、ターゲット上に新しいページ・グループが作成されます。

- 「共有オブジェクト」ページ・グループの移行では、編集またはエクスポートできないページは除外されます。たとえば、AからZのルート・ページなどがあります。

12.8.1.2 属性

最初のエクスポートおよびインポートでは、ターゲット・システムに属性が作成されます。2回目のインポートでは、ターゲットで選択したモードによって次のように動作します。

「インポート時に置換」モード:属性のプロパティが更新されます。

「再使用」モード:属性がすでにターゲットに存在する場合は、それが再使用され、更新されません。

注意

- 外部としてマークされている属性は、「すべてのトランスポート・セット」の「管理」権限を持っている場合でも、ターゲットに作成できません。

- ソースとターゲットの属性は、名前、タイプおよび一意の内部識別子が同じである場合にのみ、同じであるとみなされます。2つの属性の一意の内部識別子が同じで、名前が異なる場合は、「インポート時に置換」モードでのみインポートすることが可能です。名前とタイプが同じで一意の内部識別子が異なる場合は、属性のインポートは失敗し、関連する他のすべてのオブジェクトでも失敗します。

12.8.1.3 承認

承認者を表示するには、アクセス制御リストと、そこで承認が定義されているページ・グループまたはページを、エクスポートおよびインポートする必要があります。

「インポート時に置換」モード:承認プロセスは、ページまたはページ・グループに対して設定されます。ページ・グループまたはページが挿入または更新としてマークされている場合、承認オブジェクトは、「インポート時に置換」モードで処理されます。ターゲットの承認済情報はすべて削除され、再作成されます。ソース上の保留状態のアイテムはインポートされず、ターゲット上の保留状態のアイテムもともに削除されることに注意してください。

「再使用」モード:何も処理は行われません。

12.8.1.4 アイテム

アイテム情報は、ページ・エクスポートの一部になります。これらは、ページのインポート・モードに従います。

「インポート時に置換」モード:ページを「インポート時に置換」モードでインポートした場合は、ソースのページ・リージョンのアイテムがターゲットにコピーされます。ターゲットのみにあるアイテムは削除され、ソースとターゲットの両方にあるアイテムは更新され、ソースのみにあるターゲットは作成されます。

「再使用」モード:ソースからいずれのアイテムもインポートされません。ソースのページは参照としてのみ使用され、アイテムのインポート・モードを判別します。

注意:

- PL/SQLアイテム、ページまたは属性に関連するスキーマは、それがパブリック・スキーマや作成者スキーマではない場合にのみ抽出されます。これらのスキーマは、外部オブジェクトとしてマークされます。事前チェックでの失敗を避けるには、スキーマがターゲット・データベースに存在する必要があります。ただし、インポートを進めることはできます。ログには、実行時エラーが発生するが、後でスキーマを配置して再度関連付けすることで修正できるという適切なメッセージが表示されます。

- オブジェクト・アイテムのリストは、それらが参照しているオブジェクト(ページ、カテゴリおよびパースペクティブ)をオブジェクトのリストと同じトランスポート・セットに移行しないかぎり、ソースとターゲットとで異なって表示されます。依存性マネージャは、オブジェクトのリストで参照されているオブジェクトをエクスポート対象としてマークしません。このため、それらの参照されているオブジェクトをエクスポート対象として明示的にマークするか、またはそれらがトランスポート・セットにすで含まれていることを確認する必要があります。

- 同じページの続いて実行されるインポートの間に、ポートレット・インスタンス・アイテムがあるリージョンから別のリージョンに移動された場合、ユーザーがそのポートレット・インスタンスに行ったパーソナライズは削除されます。

- テンプレートに基づくページのアイテムは、上書きモードにおいて同期されます。

- アクティブ状態で明示的にチェックアウトされるすべてのアイテムは、インポート後にチェックインされます。

12.8.1.5 ページ

ページとそれが参照するページ・タイプ、テンプレートおよびスタイルに加え、コンテンツ(アイテムとポートレット)をエクスポートします。

「インポート時に置換」モード:ページのプロパティが置き換えられます。リージョンのインポートの動作については、第12.8.1.6項「リージョン」を参照してください。アイテムの動作については、第12.8.1.4項「アイテム」を参照してください。

「再使用」モード:ターゲットの元のページが再使用されます。子オブジェクトは、ターゲットでは作成されません(まだ存在していない場合)。

ページを上書きモードでインポートする際のインポート動作については、表12-11「上書きモードでのリージョンのインポート動作」を参照してください。

注意

- 現在のリリースでは、WebDAVを使用したコンテンツのロックとロック解除はサポートされていません。コンテンツ作成者はファイルをロックできます。ファイルをロックすると、アイテムがチェックアウトされます。インポート時、所有されているロックは表示されません。

- ポートレットとして公開されているページが外部オブジェクト・リストに表示されている場合は、そのページが必ずトランスポート・セットに含まれるようにします。

12.8.1.6 リージョン

リージョン情報は、ページ・エクスポートの一部になります。これらは、ページのインポート・モードに従います。

「インポート時に置換」モード:ページを「インポート時に置換」モードでインポートした場合は、ソースのページ・リージョンがターゲットにコピーされます。ターゲットでのみ検出されたリージョンは、そのリージョン内のすべてのコンテンツも含め、すべて削除されます。

「再使用」モード:ソースからは、リージョンやアイテムが一切インポートされません。ソースのページは参照としてのみ使用され、リージョンのインポート・モードを判別します。

注意: Oracle Portalのこのリリースでは、ターゲット・リージョンがソースと同期します。詳細は、表12-11「上書きモードでのリージョンのインポート動作」を参照してください。

リージョンの同期

Oracle Portalの今回のリリースでは、ターゲット・リージョンがソースと同期します。表12-11は、ページを上書きモードでインポートする場合のインポート動作を示しています。

表12-11 上書きモードでのリージョンのインポート動作

事例

ソース

ターゲット

インポート動作

ターゲット・リージョンとソースの同期

Region_A

Region_B

Region_D

Region_A

Region_C

Region_D

Region_E

- Region_AとRegion_Dの属性が、ソースのプロパティで更新されます。

- Region_Bは、ターゲットで検出されないため、作成されます。

- Region_CとRegion_Eは、ターゲットにのみ存在するため、削除されます。

ターゲットからのリージョンの削除

-

-

リージョンをターゲットから削除すると、ユーザーのパーソナライズを含むすべてのアイテムとポートレットが、ターゲットから削除されます。

ページのルート・リージョンの不一致

注意: 1つのページに設定できるルート・リージョンは1つだけです。

ルート・リージョン - Region_X

ルート・リージョン - Region_Y

ルートRegion_Yの階層全体が、ターゲットから削除され、ソースのRegion_X階層で再作成されます。

リージョン・タイプの不一致

注意: 使用可能なリージョン・タイプは、アイテム、ポートレット、タブおよびサブページです。

Region_X - タイプA

Region_X - タイプB

リージョン・タイプの不一致が存在すると、そのリージョンの(ユーザーのパーソナライズを含む)すべてのアイテムとポートレットがターゲットから削除され、ソース・リージョンのアイテムで再作成されます。

リージョン・タイプの一致

Region_X - タイプA

Region_X - タイプA

ターゲット・アイテムは、そのリージョンのソース・アイテムと同期します。

ターゲット・アイテムとソースの同期

注意: この処理は、ソースとターゲットのリージョン・タイプが一致する場合に適用されます。

Item_A

Item_B

Item_D

Item_A(基本ユーザー)

Item_A(ユーザーA用にパーソナライズ)

Item_C(基本ユーザー)

Item_D(基本ユーザー)

Item_E(ユーザーB用にパーソナライズ)

- Item_A(基本ユーザー)は、上書きされます。

- Item_A(ユーザーA用にパーソナライズ)は、ターゲットに維持されます。

- Item_Bは、ターゲットに作成されます。

- Item_C(基本ユーザー)は、ソースから削除されます。

- Item_D(基本ユーザー)は、上書きされます。

- Item_E(ユーザーB用にパーソナライズ)は、ターゲットに維持されます。

注意: Item_Eはソースに存在しませんが、ターゲットでユーザー用にパーソナライズされているため、ターゲットから削除されません。

また、基本ユーザーのアイテム・レコードのみがページ構成の一部であり、ページの編集時に表示されます。

12.8.1.7 Portalテンプレート

テンプレートとそれが参照するスタイル、およびテンプレートのすべてのコンテンツをエクスポートします。テンプレートに依存するページのレイアウトとコンテンツは、ターゲット上の変更されたテンプレートと同期化されます。

「インポート時に置換」モード:テンプレートのプロパティがインポート時に置き換えられます。

「再使用」モード:ターゲットでテンプレート情報が再使用されます。ソース・システムの設定は更新されません。

注意:

- 共有オブジェクトまたはページ・グループにあるカテゴリ・ページ・テンプレートとパースペクティブ・ページ・テンプレートは、エクスポートまたはインポートしないでください。これらのテンプレートは、カテゴリまたはパースペクティブをそのページ・グループで作成した場合のみ存在します。

- テンプレートは、そのテンプレートに基づくすべてのページでテンプレートのスタイルを必ず使用するようにするか、またはテンプレートに基づくページで独自のスタイルを使用できるようにすることができます。スタイルが変更されたテンプレートをインポートするときに、ページでテンプレートのスタイルを必ず使用するようになっている場合は、そのテンプレートに基づいたページに変更が伝播されるのみになります。

- 前回のインポート後にテンプレートを変更した場合、そのテンプレートは再使用できません。変更したテンプレートを再使用しようとすると、そのテンプレートに基づくトランスポート・セットのページとともに、事前チェックの段階で失敗します。インポートを続行するには、上書きモードでテンプレートをマークする必要があることを知らせるメッセージが、事前チェックのログに記録されます。

- アイテムのPortalテンプレートを使用するページまたはアイテムを移行すると、そのアイテムのPortalテンプレートはターゲットの依存性として使用されます。

- テンプレートが上書きモードである場合にPortalテンプレートに基づくページがインポートされると、そのテンプレートに基づいたページ・リージョン、アイテムまたはポートレット上のページのカスタマイズ(移動、非表示、追加、削除など)は、リージョン、アイテムまたはポートレットを含め、ソースからターゲットに引き継がれます。ターゲット・ページは、ソース・ページとまったく同じ外観になります。

- Portalテンプレートが上書きモードでインポートされる場合、ターゲット上のページのパーソナライズは、移行されたページ上にベース・アイテム、ポートレット、リージョンまたはタブが存在するかぎり保持されます。

注意:

ターゲット上のパーソナライズの一環としてタブ上で削除を行った場合、その削除処理は失われます。パーソナライズされた削除済タブのインポート後、タブ上にアイテムやポートレットは表示されません。これは、テンプレートの設定が優先され、テンプレートに基づいてターゲットにタブが再作成されるためです。ただし、パーソナライズのデータが保持されるため、タブ上の実際のアイテムまたはポートレットは再作成されません。

12.8.1.8 HTMLテンプレート

エクスポートおよびインポートの最初の実行時には、ターゲット・システムにHTMLテンプレートが作成されます。2回目のインポートでは、ターゲットで選択したモードによって次のように動作します。

「インポート時に置換」モード:HTMLテンプレートのプロパティが更新されます。

「再使用」モード:HTMLテンプレートがすでにターゲットに存在する場合は、それが再使用され、更新されません。

12.8.1.9 カテゴリ

カテゴリとそのサブカテゴリをエクスポートします。

「再使用」モード:ターゲットの元のカテゴリが再使用されます。子オブジェクトは、ターゲットでは作成されません(まだ存在していない場合)。

注意

- カテゴリ・ページ(カテゴリをクリックすると表示されるページ)とカテゴリ・テンプレートはエクスポートされません。これらは、インポート時に毎回作成されます。カテゴリは常に再使用されるので、ターゲット上で行った変更は、その後のインポート時に失われることはありません。これは、カテゴリ、カテゴリ・ページおよびカテゴリ・テンプレートに適用されます。

- 「インポート時に置換」モードはありません。「インポート時に置換」オプションは適用されず、カテゴリは常に再使用されます。

12.8.1.10 パースペクティブ

パースペクティブとそのサブパースペクティブをエクスポートします。

「再使用」モード:ターゲットの元のパースペクティブが再使用されます。子オブジェクトは、ターゲットでは作成されません(まだ存在していない場合)。

注意

- 「インポート時に置換」モードはありません。「インポート時に置換」オプションは適用されず、パースペクティブは常に再使用されます。

- パースペクティブ・ページ(パースペクティブをクリックすると表示されるページ)とパースペクティブ・テンプレートはエクスポートされません。これらは、インポート時に毎回作成されます。パースペクティブは常に再使用されるので、ターゲット上で行った変更は、その後のインポート時に失われることはありません。これは、パースペクティブ、パースペクティブ・ページおよびパースペクティブ・テンプレートに適用されます。

12.8.1.11 ナビゲーション・ページ

ナビゲーション・ページとそれが参照するスタイル、およびナビゲーション・ページ上のすべてのリンクをエクスポートします。

「インポート時に置換」モード:ナビゲーション・ページのプロパティが置き換えられます。

「再使用」モード:ターゲットの元のナビゲーション・ページが再使用されます。

12.8.1.12 スタイル

スタイルをエクスポートします。

「インポート時に置換」モード:スタイルのプロパティが置き換えられます。

「再使用」モード:ターゲット上のスタイルが再使用されます。

注意:

- ソースとターゲットのスタイルは、名前と一意の内部識別子が同じである場合に、同じであるとみなされます。2つのスタイルの一意の内部識別子が同じで、名前が異なる場合は、「インポート時に置換」モードでのみインポートできます。

- スタイルに関連する属性は、インポートされません。ローカル・スタイルは、スタイルの属するページ・グループのすべてのローカル属性と、すべての共有属性に関連します。共有スタイルは、すべての共有属性に関連します。

12.8.1.13 アイテム・タイプ

アイテム・タイプとそれが参照する属性をエクスポートします。

すべてのポータル・インスタンスに存在する編集可能な生成済アイテム・タイプが抽出されます。

注意

- 生成済アイテム・タイプを修正する場合は、生成済アイテム・タイプをコピーし、コピーのプロパティを修正することをお薦めします。

- ソースとターゲットのアイテム・タイプは、名前、タイプおよび一意の内部識別子が同じである場合に、同じであるとみなされます。ソースとターゲットのアイテム・タイプの一意の内部識別子が同じで、名前が異なる場合は、「インポート時に置換」モードでのみインポートできます。

- 現時点では、インポートとインポートの間に、カスタム・タイプ(アイテム・タイプ、ページ・タイプ)に関連付けられた属性を変更するか、カスタム・タイプに関連付けられた機能を変更すると、その変更が正しく移行されないことがあります。ターゲットでカスタム・タイプを削除および再作成する必要があります。この結果、カスタム・タイプに基づくすべてのアイテムとページが削除されます。

- ページのアイテム・リンクが別のページのアイテムを指す場合、そのアイテム・リンクを含むページがエクスポートされると、リンクされたオブジェクトが存在するページが依存ページとして使用されます。

12.8.1.14 ページ・タイプ

ページ・タイプとそれが参照する属性をエクスポートします。

注意:

- ソースとターゲットのページ・タイプは、名前、タイプおよび一意の内部識別子が同じである場合にのみ、同じであるとみなされます。ソースとターゲットのページ・タイプの一意の内部識別子が同じで、名前が異なる場合は、「インポート時に置換」モードでのみインポートすることが可能です。

- 現時点では、インポートとインポートの間に、カスタム・タイプ(アイテム・タイプ、ページ・タイプ)に関連付けられた属性を変更するか、カスタム・タイプに関連付けられた機能を変更すると、その変更が正しく移行されないことがあります。ターゲットでカスタム・タイプを削除および再作成する必要があります。この結果、カスタム・タイプに基づくアイテムまたはページはすべて削除されます。

12.8.2 子オブジェクトのインポート動作

この項では、移行後の子オブジェクトの機能について説明します。詳しい動作は表12-12のとおりです。

表12-12 子オブジェクトのインポート動作

オブジェクト名

オブジェクト

インポート動作

含まれるオブジェクト(オブジェクトの構造に関与)

- リージョン

- アイテム

- ページ上のタブとサブタブ

- 含まれるオブジェクトは、含まれるオブジェクトのいずれかが作成または上書きされる場合に、作成または上書きされます。

- コンテナ・オブジェクトがターゲットで再使用される場合は、ターゲットに存在しなくとも、含まれるオブジェクトはトランスポート・セットから作成されません。

含まれるオブジェクト(オブジェクトの構造には関与せず、コンテナ内のプレースホルダとして機能)

- ページ・グループ内の属性、スタイル、カテゴリ、パースペクティブ、アイテム・タイプ、ページ・タイプ、ページなど

- Portal DBプロバイダ内のフォーム、レポート、チャート、動的ページなど

- コンテナ・オブジェクトがターゲットに存在する場合、またはトランスポート・セットから作成される場合は、含まれるオブジェクトが作成されます。

- コンテナ・オブジェクトがターゲットで再使用される場合は、トランスポート・セットから新しい含まれるオブジェクトのみが作成されます。ターゲット上では、既存のすべてのオブジェクトがそのまま維持されます。

子オブジェクト

- サブページ

- サブカテゴリとサブパースペクティブ

- 親オブジェクトがターゲットに存在する場合、またはトランスポート・セットから作成される場合に、子オブジェクトが作成されます。

12.8.3 DBプロバイダ・オブジェクトの動作

この項では、次のDBプロバイダ・オブジェクトの移行後の動作について説明します。

- 生成済DBプロバイダ

- Portal DBプロバイダ

- Portal DBプロバイダのコンポーネント

- 共有コンポーネント

- 登録済データベース・プロバイダ

12.8.3.1 生成済DBプロバイダ

- インプレース開発ポートレットを含むページをインポートすると、それらのポートレットに関連するコンポーネントが、ターゲット・ポータルのインプレース開発プロバイダのデータベース・スキーマで自動的に作成されます。
インプレース開発データベース・プロバイダの名前はPTL_TOOLS_APPです。PTL_TOOLS_APPの基礎となるデータベース・スキーマは、<PortalSchema>_APPです。

- 他の生成済データベース・プロバイダでは、ソース・ポータルから取得されている関連コンポーネントが、ターゲット・ポータルのデータベース・プロバイダのデータベース・スキーマに自動的に作成されます(そのプロバイダがすでにターゲット・ポータルに存在する場合)。
ターゲット・ポータルにプロバイダが存在しない場合は、生成済データベース・プロバイダをトランスポート・セットの一部にする必要があります。これ以外の場合は、プロバイダを移動する必要はありません。

注意:

- インプレース開発プロバイダは、スタンドアロン・ベースでエクスポートまたはインポートできません。つまり、インプレース開発ポートレットがページに存在する必要があります。

- インプレース開発プロバイダは、他のデータベース・プロバイダとは異なり、UIマニフェストに外部オブジェクトとして表示されません。

- データベース・プロバイダを移行する際、インプレース開発コンポーネントまたは他のデータベース・プロバイダのコンポーネントで、データベース・プロバイダの基礎となるスキーマ以外のスキーマのデータベース・オブジェクトからデータを取得している場合、前もってexpユーティリティとimpユーティリティを使用してターゲット・ポータルにそのデータベース・スキーマもエクスポートまたはインポートしておく必要があります。

12.8.3.2 Portal DBプロバイダ

最初のエクスポートおよびインポートでは、Portal DB プロバイダが存在しない場合は、ターゲット・システムに作成されます。

- Portal DBプロバイダのプロパティは、ターゲットで作成されます。

- 新しく作成されたPortal DBプロバイダは、プロバイダ登録が行われます。

2回目のインポートでは、ターゲットで選択したモードによって次のように動作します。

「インポート時に置換」モード:ソースのPortal DB プロバイダのプロパティによって、ターゲットのプロパティが置き換えられます。Portal DBプロバイダ内のコンポーネントはすべて、それらが存在するかどうかに応じて作成または更新されます。

「再使用」モード:ターゲットにPortal DBプロバイダがすでに存在する場合は、そのプロパティが再使用され、更新されません。Portal DBプロバイダ内の新しいコンポーネントは作成され、既存のコンポーネントは再使用されます。

注意:

Portal DBプロバイダを移行する場合は、Portal DBプロバイダをインポートする前に、次の作業を実行します。

1. エクスポートするPortal DBプロバイダによって使用されているスキーマがターゲット・データベースのインスタンスに存在することと、そのスキーマへのCONNECTとRESOURCEロールが付与されていることを確認します。

2. ターゲットでprovsyns.sqlスクリプト(MID_TIER_ORACLE_HOME/portal/admin/plsql/wwcディレクトリにある)を実行します。SQL*Plusを使用して、Portalスキーマの所有者としてログインし、次のようにSQLプロンプトからスクリプトを実行します。

SQL> @provsyns.sql <db_provider_schema_name>

provsyns.sqlスクリプトは、Portal DBプロバイダのスキーマに対して複数回実行できます。

12.8.3.3 Portal DBプロバイダのコンポーネント

Portal DBプロバイダのコンポーネントは次のとおりです。

- メニュー

- フォーム

- レポート

- チャート

- カレンダ

- 値リスト

- リンク

- 階層

- 動的ページ

- XML/URLコンポーネント

- データ・コンポーネント

エクスポートおよびインポートの最初の実行時には、ターゲット・システムにコンポーネントが作成されます。

- 指定されたPortal DBプロバイダの下に最初のコンポーネントが作成され、これが本稼働バージョンになります。

- Portal DBプロバイダに関連付けられているスキーマの下に、コンポーネントと同じ名前のパッケージが作成されます。

2回目のインポートでは、ターゲットで選択したモードによって次のように動作します。

「インポート時に置換」モード:既存のバージョンの上に最新バージョンのコンポーネントが作成され、これが本稼働バージョンになります。ターゲットに既存のバージョンがある場合は、それらがアーカイブされます。本稼働バージョンから取得された情報を使用して、パッケージが再生成されます。

「再使用」モード:ターゲットにコンポーネントが存在しない場合は、作成されます。

注意:

- 値リストとリンクのコンポーネントには、バージョンまたはパッケージが関連付けられません。そのため、上書きモードでは、これらのコンポーネントがターゲット上で削除され、再作成されます。

- 値リストおよびリンクのコンポーネントは、それ自体ではレンダリングできないか、またはポートレット・フォームに含まれないため、これらのコンポーネントに付加されるパーソナライズはありません。

- 値リスト(LOV)は外部オブジェクトとして表示され、選択して明示化できます。LOVがターゲットに存在しない場合でもインポートは続行されます。ただし、属性に関連するLOVがリセットされ、後でLOVを取得して再度関連付けできることを知らせるメッセージがログに記録されます。

12.8.3.4 共有コンポーネント

共有コンポーネントは次のとおりです。

- 色

- フォント

- イメージ

- JavaScript

- UIテンプレート(構成済、非構成済)

エクスポートおよびインポートの最初の実行時、共有コンポーネントが存在しないときはターゲット・システムに作成されます。

2回目のインポートでは、ターゲットで選択したモードによって次のように動作します。

「インポート時に置換」モード:共有コンポーネントが削除され、ソース情報を使用して再作成されます。

「再使用」モード:ターゲットに共有コンポーネントがすでに存在する場合は、そのプロパティが再使用され、更新されません。新しい共有コンポーネントは作成され、既存のコンポーネントは再使用されます。

注意: システムの色、フォント、テンプレートはターゲットで再使用され、エクスポートおよびインポートされることはありません。

12.8.3.5 登録済データベース・プロバイダ

登録済データベース・プロバイダに関連するスキーマは、マニフェストの外部オブジェクトのマークが付けられます。インポートで注意する内容は、次のとおりです。

- プロバイダとスキーマがターゲットに存在しない場合は、スキーマが事前チェックで失敗します。その結果としてプロバイダが失敗し、さらに明示オブジェクトが失敗します。

- プロバイダが存在するものの、スキーマがソースとターゲットで異なる場合は、プロバイダに警告ステータスが割り当てられ、ログにスキーマ上の差異が存在することが示されます。

注意: データベース登録エラーを回避するには、ソースからターゲットへのスキーマの移行後に、すべてのオブジェクトが有効であることを確認する必要があります。

12.8.4 Portal DBプロバイダ・レポートのオブジェクト・タイプの動作

Report Security Accessオブジェクトは常に、Portal DBプロバイダのエクスポートおよびインポートの一部としてエクスポートまたはインポートされます。

注意:

- Report Security Accessコンポーネントの詳細なエクスポートおよびインポートはサポートされていません。

- バージョン管理については、Report Security AccessコンポーネントはDBプロバイダのコンポーネントと同じ動作をします。

- DBプロバイダのコンポーネントと同様、レポート定義ファイル(RDF)アクセス・コンポーネントのパッケージが作成または再生成されます。

12.8.5 Webプロバイダの動作

この項では、次のWebプロバイダについて説明します。

- OmniPortlet

- Webクリッピング・プロバイダ、WSRPプロデューサとその他のWebプロバイダ

Webプロバイダのエクスポートおよびインポートの有効化と無効化

OmniPortletプロバイダおよびWebクリッピング・プロバイダの移行を有効または無効にするには、DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\kjdcke\war\WEB-INF\web.xmlファイルで次の変数を編集します。

<env-entry>
<env-entry-name>oracle/portal/provider/global/transportEnabled</env-entry-name>
<env-entry-value>true</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

この値をfalseに設定すると、OmniPortletプロバイダおよびWebクリッピング・プロバイダのエクスポートとインポートが無効になります。

12.8.5.1 OmniPortlet

独自のデフォルト・パーソナライズと関連情報を含み、トランスポート・セットから参照されるOmniPortletプロバイダは、ページとともに自動的にエクスポートおよびインポートされます。

OmniPortletインスタンスに関連する接続情報(データベース、ユーザー名、パスワード、URL、HTTP認証ユーザー名、パスワードなど)は、デフォルトで自動的に移行されます。

セキュリティ上の理由から、接続情報のエクスポートとインポートを無効にする場合は、DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet\provider.xmlファイルを編集して、exportConnectionInfoパラメータをfalseに設定します。例:

<provider class="oracle.webdb.reformlet.ReformletProvider">
<exportConnectionInfo>false</exportConnectionInfo>
...
</provider>

接続情報を移行しない場合、インポートされるOmniPortletでは、ターゲットの同名の接続情報が使用されます(存在する場合)。また、「デフォルトの編集」ページまたは「パーソナライズ」ページで、インポートされたOmniPortletインスタンスの接続情報を入力することもできます。

インポートされる接続情報が、ターゲットにあるプロバイダの既存の接続情報と同じ名前の場合、ソース・プロバイダの接続情報は、上書きモードを指定しないかぎりインポートされません。接続情報のインポートに失敗すると、トランスポート・ログにメッセージが書き込まれます。

「再使用」モード:OmniPortletプロバイダが常に再使用されます。

注意:

- プロバイダの登録時に権限の不足によってエラーが発生した場合は、プロバイダ・オブジェクトの事前チェックに失敗します。これは、明示的に選択されたオブジェクトにも連鎖します。プロバイダが失敗すると、明示的に選択されたオブジェクトも必ず失敗します。

- 「デフォルトの編集」でのカスタマイズは、移行されます。ユーザーのパーソナライズが存在する場合、その設定は維持されます。

重要:

- ソースのOmniPortletプロバイダとターゲットのOmniPortletプロバイダでlocalePersonalizationLevelが異なる場合、ページをインポートした後、一部のパーソナライズにアクセスできなくなる可能性があります。たとえば、現在のロケールが日本語であり、ソースのOmniPortletプロバイダではlocalePersonalizationLevelがlocaleに設定されており、ターゲットのOmniPortletプロバイダではnoneに設定されている場合、インポート後は、日本語のパーソナライズにアクセスできません。
DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortletディレクトリにあるprovider.xmlファイルで、localePersonalizationLevelを設定します。

localePersonalizationLevelの詳細は、MID_TIER_ORACLE_HOME/portal/pdkjava/v2/pdkjava.v2.release.notes.htmlのリリース・ノートを参照してください。

- OmniPortletポートレットがSSL URLを使用してデータを取得するように構成されている場合は、これらのファイルを手動でコピーする必要があります。デフォルトでは、SSL URLの証明書がエクスポートおよびインポートされないためです。次の手順を実行して、証明書ファイルをターゲット・インスタンスに手動でコピーします。

1. SSL URLの証明書を、OmniPortletプロバイダが使用する証明書ファイル(デフォルトはORACLE_HOME\portal\conf/ca-bundle.crt)に追加します。

2. DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortletディレクトリにあるOmniPortletのprovider.xmlファイルで、<trustedCertificateLocation>タグを更新します。

3. WLS_PORTALを再起動します。

12.8.5.2 Webクリッピング・プロバイダ、WSRPプロデューサとその他のWebプロバイダ

トランスポート・セットが参照するWebクリッピング・プロバイダ、WSRPプロデューサとその他のWebプロバイダは、ターゲット・システムにすでに存在しているか、ターゲット・システムへのインポート時に正常に登録できる必要があります。

「再使用」モード:Webクリッピング・プロバイダ、WSRPプロデューサとその他のWebプロバイダは常に再使用されます。

重要: Webクリッピング・ポートレットがSSL URLを使用してデータを取得するように構成されている場合は、これらのファイルを手動でコピーする必要があります。デフォルトでは、SSL URLの証明書がエクスポートおよびインポートされないためです。次の手順を実行して、証明書ファイルをターゲット・インスタンスに手動でコピーします。

1. SSL URLの証明書を、Webクリッピング・プロバイダが使用する証明書ファイル(デフォルトはMID_TIER_ORACLE_HOME/portal/conf/ca-bundle.crt)に追加します。

2. DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortletディレクトリにあるOmniPortletのprovider.xmlファイルで、<trustedCertificateLocation>タグを更新します。

3. WLS_PORTALを再起動します。

注意:

- プロバイダの登録時に権限の不足によってエラーが発生した場合は、プロバイダ・オブジェクトの事前チェックに失敗します。これは、明示的に選択されたオブジェクトにも連鎖します。プロバイダが失敗すると、明示的に選択されたオブジェクトも必ず失敗します。

- WSRPポートレットがインポートされる場合、ポートレットのパーソナライズはインポートされません。

12.8.6 共有ポートレット・インスタンスの動作

表12-13のシナリオは、移行時の共有ポートレット・インスタンスの動作をまとめたものです。

表12-13 移行時の共有ポートレット・インスタンスの動作

ソース

ターゲット

1. 共有ポートレットのユーザー・ページを(ポートレット・リポジトリ情報なしで)エクスポートします。

1. 共有ポートレットの最初のインポートを実行します。

2. 共有ポートレット・インスタンスの表示名を使用して、ポートレット・リポジトリの下に登録します。

1. 共有ポートレット・インスタンスの名前を変更します。
これらの変更はポートレット・リポジトリ・アイテムには反映されず、アイテムにはまだ元の名前/表示名が残ることに注意してください。

2. ユーザー・ページをエクスポートします。

1. 名前を変更した共有ポートレット・インスタンスがすでにターゲットに存在すれば、それをインポートします。
ポートレット・インスタンスはターゲットで再利用されるため、ソースでの表示名の変更は移行されません。

12.9 エクスポートおよびインポート時の推奨方法

次に、Oracle Portalのエクスポートおよびインポート機能を使用して、開発またはテスト環境から本稼働インスタンスにポータル・コンテンツを移行する際の、重要な推奨事項と最善の実施例について概説します。

- レプリケートされたタブの命名規則

- ページ・グループおよびコンポーネントの移行

- Portal DBプロバイダとコンポーネントの移行

- 検索コンポーネントの移行

- アップグレードされたOracle Portalインスタンス間でのコンテンツの移行

- ホスト環境でのエクスポートとインポート

- Oracle Text索引の同期をオフにしたデータのインポート

- ユーザーおよびグループの移行

12.9.1 レプリケートされたタブの命名規則

以前のリリースでは、テンプレートに基づくページ上でタブをレプリケートした場合、ターゲットでレプリケートされたタブの名前は、ソースのタブの名前と異なっていました。その結果、後でページを取得すると、ソースのタブとターゲットのタブが一致せず、追加のタブがターゲットに作成されていました。

Oracle Portalの今回のリリースでは、レプリケートされるテンプレート・タブについて予測可能な命名規則が採用されたため、タブの重複を避けることができます。ページ名は階層内でのみ一意である必要があるため、レプリケートされたタブは、テンプレート・タブと同じ名前を継承します。ただし、必ずレプリケートされたタブの名前を変更していないことを確認してください。

12.9.2 ページ・グループおよびコンポーネントの移行

ページ・グループおよびそれに関連付けられたコンポーネントは、このドキュメントで説明しているエクスポート・ユーティリティとインポート・ユーティリティを使用して、開発環境から本稼働環境に移行できます。ターゲット・システムにページ・グループ全体がすでにインポートされている場合のみ、ページ・グループ全体だけでなく、ページ・グループ内の個々のコンポーネント(サブページ、カテゴリ、パースペクティブ、ページ・スタイルなど)をターゲット・システムに個別に移動できます。

- 重要な考慮事項と推奨方法:

- ターゲット・システムへの最初のエクスポートでは、ソース・ポータルからターゲット・ポータル・インスタンスに、ページ・グループ全体を移行します。以降のトランスポート・セットでは、個別のページをエクスポートすることも、ターゲット・ポータル・インストールの他のページ・グループ・コンポーネントをエクスポートすることもできます。

注意:

ページ・グループがターゲットに存在していない場合は、オブジェクトの事前チェック・プロセスに失敗します。ページ・グループ・オブジェクトがエクスポートされるときは、必ずそのオブジェクトを所有しているページ・グループが外部の依存性として含められます。ページ・グループがターゲットに存在しているかどうか不明で、事前チェックに失敗する可能性がある場合は、ページ・グループを明示化できます。

これは、階層に含まれている他のオブジェクトにも当てはまります。カテゴリ、パースペクティブおよびページがエクスポートされると、それらが所属するページ・グループだけでなく、親のカテゴリ、パースペクティブまたはページが外部の依存性として表示されます。データベース・プロバイダ・コンポーネントが単独でエクスポートされると、外部の依存性としてプロバイダが表示されます。

ページ・グループのデフォルトの設定(デフォルトのテンプレート、スタイル、ナビゲーション・ページなど)も依存性マネージャによって抽出され、参照または外部(ローカルまたは共有)として分類されます。

- 同じ名前のページがターゲットに再インポートされた場合は、そのページの新規および既存のすべてのコンテンツが置き換えられます。

- ページ・グループ内のオブジェクトは、ターゲット・ポータルで同じ名前を持つ同じページ・グループにしか移動できません。

- ページは、サブページとともに移行されます。

- ターゲット・システムへの最初のインポートの終了後に、ターゲット・システムでページ・グループの名前を変更した場合は、以降に同じページ・グループをインポートしようとすると失敗します。

- ソースで構成されているカテゴリ、アイテム・タイプ、パースペクティブおよびページ・タイプは、ターゲットでは自動的に構成されません。ページ・グループをエクスポートしていない場合は、これらのオブジェクトを明示的に構成する必要があります。

- ページURLの動作: ポータル・ページへのリンクを作成する場合は、必ず、ページ・リンクのアイテム・タイプまたはパスベースのURLを使用します。Rawポータル・ページURLを使用しないでください。
デフォルトでは、Oracle Portalで生成されたポータル・ページのURLにはインストール固有のID番号が含まれ、これらの番号はオブジェクトがエクスポートされると変更されます。このため、ページが他のサイトにインポートされるとリンクが壊れます。

ページに対して生成されたURLの例を次に示します。ページが他のサイトにインポートされると、このページIDが変わります。

http://my.portal.com/servlet/page?_pageid=47,49&_dad=portalr2&_schema=portal

このようなURLを手動入力のリンクとして使用している場合は、パスベースのURLまたはページ・リンクのアイテム・タイプを使用することをお薦めします。

同じページのパスベースURLは次のようになります。

http://my.portal.com/portal/pls/portal/url/PAGE/HRPAGEGROUP/HRHOME/HRBENEFITS

ページのパスベースURLを検索するには、ページのプロパティ・シートを調べます。プロパティ・シートへのリンクを表示するには、ページにプロパティ・シートのスマート・リンク・アイテムを追加します。

「ページ・リンク」アイテム・タイプを使用して、ページへのリンクを作成することもできます。「ページ・リンク」アイテム・タイプは、実行時に正しいリンクを動的に生成します。

- ページ・ポートレット: ページを置き換えると、ターゲットのコンテンツと構造が置き換えられます。

注意:

- このリリースでは、Oracle Portalのサーベイ・コンポーネントおよび「お気に入り」ポートレットをインポートおよびエクスポートできません。ソースに追加された新規の「お気に入り」または「グループ」は、トランスポート・セットに表示されることはなく、ターゲットに移行されることもありません。

- このリリースでは、汎用ページ・ポートレットのエクスポートとインポートが可能です。任意のページを指すように汎用ページ・ポートレットを構成できるようになりました。ページ・ポートレットが指すページは、そのページがページ・ポートレットと同じページ・グループに属しているかどうかに応じ、依存性マネージャによって参照または外部としてマークされます。インポート時に、この情報は解決され、プリファレンス・ストアに格納されます。インポート時にページがターゲットに存在しない場合、ポートレットはリセットされます。

- このリリースでは、Webプロバイダおよびそのデフォルト・パーソナライズをエクスポートおよびインポートできます。『Oracle Fusion Middleware Oracle Portal開発者ガイド』で、ポートレット・パーソナライズのエクスポートとインポートの制御に関する項を参照してください。

ターゲットのページのコンテンツ(アイテム、ポートレット)はそのまま保持し、ソースのスタイル・レイアウトまたはレンダリングの変更内容をインポートするには、連携型Portalアダプタ・ポートレットを介してコンテンツを公開します。ページ構造のコンテンツを、2つの異なるページ・グループに分けることが重要です。一方はコンテンツのみのページ・グループで、連携型Portalアダプタを介して公開されます。もう一方は表示用のページ・グループです。ユーザーはこれを使用して、ポータルのアクセス、表示およびカスタマイズを行うことができます。次の手順を実行します。

1. ソース・システムで、後で他のページに公開する単一のリージョンがあるページのみを含むページ・グループを作成します。このリージョンには、ポートレットまたはアイテムのいずれかが挿入されます。このページ・グループに、「コンテンツ・ページ・グループ」という名前を付けます。

2. このコンテンツ・ページ・グループをターゲット・システムにエクスポートします。

3. ターゲット・システムで、連携型Portalアダプタを介してコンテンツ・ページ・グループを登録します。ターゲット・システムの連携型Portalアダプタ・プロバイダを介して、これらのページをポートレットとして公開します。

4. ソース・システムで、連携型Portalアダプタ・プロバイダと同じ名前を使用して、同じプロバイダを登録します。

5. ソース・システムで、「表示ページ」という別のページ・グループを作成します。このページ・グループには、連携型Portalアダプタ・プロバイダからポートレットを公開するリージョンが含まれるページを作成します。必要に応じて、このページ・グループにタブおよび他のポートレット・リージョンを含めることもできます。

6. 「表示ページ」グループをターゲット・システムにエクスポートします。

7. ターゲット・システムから、連携型Portalアダプタ・プロバイダを介して公開されたコンテンツ・ページ・グループのページに対して、更新、削除、修正およびリージョンへの新しいアイテムの追加を行います。

8. ソース・システムで、「表示ページ」ページ・グループに対して、ページ構造(タブ、新しいリージョンなど)の変更を行います。

9. 最新の「表示ページ」ページ・グループをターゲット・システムにエクスポートします。

10. ステップ7でターゲット環境で行った変更が、コンテンツ・ページ・グループに反映されていることを確認します。

11. ターゲット・システムに、最後に変更した「表示ページ」ページ・グループのページに対する最新の変更が反映されていることを確認します。

注意:

アダプタ・レンダリング・プロバイダ(ループバックの場合)からのポートレットが含まれているページがインポートされており、プロバイダが新しいポータルに自動的に登録されている場合は、URLが古く、以前のポータルを参照しています。

新しいポータルで、ループバック・プロバイダが必要な場合は、新しく作成するか、またはデフォルトのプロバイダを更新する必要があります。

- ページとポートレットのパーソナライズおよびデフォルトの移行の編集:ターゲット・システム上のページまたはポートレットにユーザーが加えたカスタマイズは、そのページまたはポートレットのプロパティの編集を置換または再使用する場合でも、保持しておくことができます。

注意:

現時点では、Webポートレットのパーソナライズは保持されません。デフォルトの編集の移行は、OmniPortletプロバイダおよびWebクリッピング・プロバイダで利用できます。他のプロバイダでこの機能を実装している場合、デフォルトの編集も移行できます。このサポートの実装方法の詳細は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。

ソース・ポータルのページ上に存在しないベース・オブジェクトは、その後のインポートが終了した後でターゲット・ページから削除されます。これによって、ベース・ポートレット・リージョンのすべてのパーソナライズも必ず削除されます。ベース・オブジェクトとは、ページの中核となる定義の一部としてインポートされるリージョン、ポートレット、アイテムおよびタブのことで、ページの構造とコンテンツを定義します。

ページにすでに存在しているポートレットは、そのページが「インポート時に置換」モードでインポートされると、次のように動作します。

- デフォルトの編集は移行されます。

- ユーザーのパーソナライズは保持されます。

ページのプロパティは、そのページが「インポート時に置換」モードでインポートされると、次のように動作します。

- プロパティの編集は置き換えられます。

- ユーザーのパーソナライズは保持されます(ユーザーのカスタマイズが有効であることが前提)。

注意:

ポートレットとタブは、パーソナライズ、追加、表示/非表示の切り替え、削除および移動が可能です。ページには、少なくとも1つのポートレット・リージョンとそのリージョン内の1つのタブ(カスタマイズに関連するタブ)を定義する必要があります。カスタマイズされたオブジェクトは、ページのプロパティを継承します。リージョンを削除すると(2回目のインポートでページからリージョンまたはタブを削除する場合など)、カスタマイズされたオブジェクトも削除されます。

ページのポートレット数を増やしてページをインポートするときは、ターゲットのページをカスタマイズしてポートレットを削除した場合でも、ソースの内容が優先されます。次に同じページをインポートするとき、削除されたポートレットは、ターゲットの構造に追加される新しいポートレットとみなされます。これはタブにも当てはまります。

これらのポートレット(パーソナライズ)およびページのコンテンツを構成するポートレットの表示順序は、ソースおよびインポートのモードによって決まります。

- 「インポート時に置換」モード:ソースのポートレットはソース内と同じ順序で配置され、その後にターゲットのポートレット(パーソナライズ)が配置されます。

- 「再使用」モード:パーソナライズが保持され、ターゲット・ページは変更されません。

12.9.3 Portal DBプロバイダとコンポーネントの移行

Portal DBプロバイダおよびそれに関連付けられたコンポーネントは、この章で説明しているエクスポート・ユーティリティとインポート・ユーティリティを使用して、開発環境から本稼働環境に移動できます。Portal DBプロバイダ全体だけでなく、Portal DBプロバイダ内の個々のコンポーネント(フォーム、レポート、チャート、カレンダなど)をターゲット・システムに個別に移動することができます。これは、Portal DBプロバイダ全体が、ターゲット・システムへすでにインポートされている場合のみ可能です。

Portal DBプロバイダのコンポーネントの移行において考慮すべき事項と最善の実施例は次のとおりです。

- Portal DBプロバイダのポートレットIDの再配置をprovider.xmlファイルで直接行うと、移行後に問題が発生する可能性があるため、行わないでください。

- Portal DBプロバイダのコンポーネントまたはコンポーネントが参照するデータベース・オブジェクトを格納するためにポータル・スキーマを使用するのを避けます。

- ソース環境で、Portal DBプロバイダのコンポーネント用の別のスキーマ(ポートレット・スキーマと呼ばれます)を作成します。これは、Portal DBプロバイダが作成されるときに登録情報で参照されるスキーマです。

詳細は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』のOracle Portalのスキーマの作成に関する項を参照してください。

- ソース環境で、コンポーネントが参照するデータベース・オブジェクトの別のスキーマ(データベース・オブジェクト・スキーマと呼ばれます)を作成します。データベース・オブジェクトが特定のスキーマにすでに存在する場合は、Portal DBプロバイダの作成時にこのスキーマが参照されないことを確認します。これは、Portlet DBプロバイダのコンポーネントの作成に使用されるデータベース・オブジェクト(表、ビュー、プロシージャなど)を保持するスキーマです。たとえば、表、ビューまたはプロシージャに基づくフォームを構築するときは、その表、ビューまたはプロシージャがデータベース・オブジェクト・スキーマに格納されます。

- Portal DBプロバイダとそのコンポーネントをインポートする前に、コンポーネントが参照するデータベース・オブジェクト・スキーマがターゲット環境で利用できることを確認します。データベース・オブジェクト・スキーマは、ソース環境のものと同じ名前である必要があります。データベース・オブジェクトとデータベース・オブジェクト・スキーマが、ソース環境のものと同じ権限付与および権限を持っていることを確認します。また、すべてのデータベース・オブジェクトのステータスが有効であることを確認します。データベース・オブジェクト・スキーマは、データベースのエクスポートまたはインポート・ユーティリティを使用してエクスポートまたはインポートできます。

- Portal DBプロバイダとそのコンポーネントをインポートする前に、ターゲット環境に、ソース環境と同じ名前で空のポートレット・スキーマを作成します。

- Portal DBプロバイダに、編集モードまたはアーカイブ・モードのコンポーネントが含まれていないことを確認します。インポート後にターゲット環境に有効なコンポーネントが含まれるようにするために、エクスポートする各コンポーネントには、1つの有効な本稼働バージョンのみが格納されている必要があります。

- ページ・グループに、Portal DBプロバイダからのポートレットが含まれている場合は、エクスポートするトランスポート・セット内にそのプロバイダを明示的に含める必要があります。かわりに、プロバイダをあらかじめエクスポートまたはインポートしておくこともできます。

- 登録済Portal DBプロバイダに関連するスキーマは、マニフェストの外部オブジェクトとして抽出されます。

注意:

データベース・オブジェクト・スキーマをインポートする場合、スキーマに関連するACL(ロールと権限)がターゲット・システムにすでに存在することを必ず確認してください。これにより、コンポーネントの生成またはデータベース・プロバイダの登録が、インポート中に失敗しないようにします。

12.9.4 検索コンポーネントの移行

ページに検索コンポーネントを追加する場合は、いくつかの選択肢があります。検索フィールドに入力された検索条件と照合するための基本検索、拡張検索、および自動実行される検索を作成するためのカスタム検索を追加できます。

12.9.4.1 「基本検索」および「拡張検索」ポートレット

「基本検索」ポートレットおよび「拡張検索」ポートレットは、エクスポートおよびインポートできます。インポート後、ポートレットは、ユーザー設定項目を含め、ソース・ポータルで表示されていたとおりに表示されます(ユーザー設定項目がインポートされた場合)。

12.9.4.2 「カスタム検索」ポートレット

「カスタム検索」ポートレットでは、ポータルにある他のオブジェクトを参照する多数のカスタマイズを定義できます。この参照先オブジェクトとして、検索するページ・グループ、検索する属性、送信フォームの図、結果のスタイル、結果のページ、結果の属性、カテゴリのデフォルト値、パースペクティブ、アイテム・タイプの属性などがあります。これらは依存性とみなすことができます。「カスタム検索」ポートレットをエクスポートおよびインポートすると、その依存性が計算され、外部依存性としてマニフェストに表示されます。これをトランスポート・セットに追加して、エクスポートおよびインポートできるようにするかどうかはユーザーが決定できます。

含めない場合、「カスタム検索」ポートレットがソースでカスタマイズできるのにターゲットに依存性がないという状況になることもあります。また、ソースの「カスタム検索」ポートレットがカスタマイズされており、その後、依存性がポータルから削除され、「カスタム検索」ポートレットのカスタマイズが更新されていないという状況も考えられます。このような場合、検索で「カスタム検索」ポートレットを使用すると、見つからない参照は無視されます。「カスタム検索」ポートレットが再度カスタマイズされ、カスタマイズが保存されると、見つからない参照は削除されます。

エクスポート時には、エクスポート用に選択したすべての「カスタム検索」ポートレットがチェックされ、見つからない参照がすべて削除されます。その後、カスタマイズがトランスポート・セットに含められます。

インポート時には、事前チェックによって、インポート後にターゲットで依存性が欠落していないかどうかが判断されます。ログにメッセージが書き込まれます。依存性が欠落している「カスタム検索」ポートレットでは、「カスタム検索」ポートレットの参照パス、欠落している依存性、およびインポート時に何が起こったかがログに表示されます。

「カスタム検索」ポートレットがあるページには、警告のフラグが設定されます。実際のインポートでは、ターゲット内の同じ依存性のIDがすべて正しくなるように「カスタム検索」ポートレットのカスタマイズが修正され、カスタマイズがターゲットにコピーされます。

注意:

「保存された検索」ポートレットを使用して保存された検索結果は、インポートまたはエクスポートされません。新しいターゲットで同じ検索を送信し、検索結果の最新セットを保存する必要があります。

12.9.5 アップグレードされたOracle Portalインスタンス間でのコンテンツの移行

2つのポータルが9.0.2より前のリリースからアップグレードされている場合、それらのポータル間ではエクスポートおよびインポートできません。たとえば、ソース側の開発ポータル・インスタンスとターゲット側の本稼働ポータル・インスタンスが両方ともリリース3.0.9だとします。この2つのインスタンスをそれぞれリリース9.0.4にアップグレードし、その後でリリース11.1.1にアップブレードします。11.1.1にアップグレードした開発インスタンスと本稼働インスタンスの間で、コンテンツをエクスポートおよびインポートすることはできません。

9.0.2より前のリリースのOracle Portalからアップグレードすると、アップグレード処理の過程で、オブジェクト(スタイル、属性、アイテム・タイプ、ページ・タイプ)に新しいグローバル一意識別子(GUID)が付与されます。2つのOracle PortalインスタンスのオブジェクトのGUIDが一致しない場合、これらのオブジェクトの事前チェックは失敗します。たとえば、ソース開発インスタンスとターゲット本稼働インスタンスがある場合に事前チェックの失敗を避けるには、Oracle Portalインスタンスを再同期化する必要があります。これを行うには、次の手順を実行します:

1. 空のポータル・インスタンスを作成します(このインスタンスが、新しいソース開発インスタンスになります)。

2. ターゲットの本稼働ポータル・インスタンスのコンテンツをエクスポートします。

3. ソース側の新しい開発ポータル・インスタンスにコンテンツをインポートします。

これで、ターゲット側の本稼働ポータル・インスタンスとソース側の新しい開発ポータル・インスタンスとの間で、コンテンツをエクスポートおよびインポートすることができました。

生成済のページ・グループ・オブジェクト(トップ・レベル・ページ、設計時ページなど)への参照は、2つのインスタンスにわたる正しいGUIDに解決できません。エクスポートするオブジェクトからこれらの参照を削除してください。または、生成済ページ・グループ・オブジェクトの機能をコピーする新しいオブジェクトを作成します。

注意:

開発インスタンスの新規コンポーネントはすべて、開発ポータル・インスタンスを再作成する際に失われます。本稼働インスタンスのアップグレードは、開発インスタンスのすべての新規コンポーネントを本稼働インスタンスに移行してから行ってください。部分的に開発したコンポーネントがある場合は、新しい開発ポータル・インスタンスの作成後に、それらのコンポーネントを再作成する必要があります。

関連項目:

第12.4.2項「Oracle Portalのエクスポート - 別の方法」

12.9.6 ホスト環境でのエクスポートとインポート

Oracle Portalのエクスポートおよびインポートでは、新規サブスクリプションのコンテンツと構造のレプリケートに使用可能な分類コンテンツを作成できます。この処理は、トランスポート・セットのコンテンツをシステム表にインポートするときに、ポータル・インスタンスでサブスクリプション情報を設定することで行われます。これは、ホスト環境で、任意のサブスクリプションからエクスポートし、他の任意のサブスクリプションにインポートできることを意味します。このインポート処理の対象は、1つのサブスクリプションに限定されません。次のように、1つのトランスポート・セットのコンテンツを複数のサブスクリプションにインポートできます。

1. コマンドライン・ユーティリティをインポート・モードで実行します。

2. サブスクリプションにログインします。

3. トランスポート・セットのコンテンツをサブスクリプションにインポートします。

例12-1に、Oracle Portalのエクスポートおよびインポート機能を使用して、トランスポート・セットのコンテンツを複数のサブスクリプションにインポートする手順を示します。

例12-1 複数のサブスクリプションへのコンテンツのインポート

1. デフォルトのシード・サブスクリプションを作成します(各種オブジェクトは、このサブスクリプション上に作成し管理します)。

このサブスクリプションでは、分類コンテンツと構造を作成します。作成する内容としては、ページ・グループ、ページ、その他のページ・グループ・オブジェクト、Portal DBプロバイダとそのコンポーネント(ページ内のポートレットとして公開)、Webプロバイダのポートレットなどがあります。

2. コンテンツと構造をトランスポート・セットにエクスポートします。これがシード・トランスポート・セットになります。

3. トランスポート・セットのコンテンツをダンプ・ファイルにエクスポートします。

4. 先に定義した構造とコンテンツを持つサブスクリプションを、次の手順で新規に作成します。

1. サブスクリプションを新規に作成します。

2. ダンプ・ファイルのコンテンツをポータル・インスタンスにインポートします。

3. 作成したサブスクリプションにログインします。

4. 「トランスポート・セット」ポートレットで、トランスポート・セットを選択してインポートします。

5. 新しいサブスクリプションに、必要な構造とコンテンツが含まれていることを確認します。

5. 前述の手順を、ステップ1で作成した構造とコンテンツに基づく各新規サブスクリプションに対して繰り返します。

この手順は、複数の分類カテゴリを作成する際に利用できます。カテゴリごとにトランスポート・セットを作成し、先の手順に従って新規サブスクリプションにデータを設定してください。

注意:

複数のサブスクライバが存在するホスト環境では、トランスポート・セットをOracle Portal内の特定のサブスクリプションに固定することはできません。エクスポートおよびインポート用としてトランスポート・セットを作成した場合、Oracle Portalにログインする他のすべてのユーザーは、そのポータル内のすべてのサブスクリプションで、作成したトランスポート・セットの内容を表示できます。

12.9.7 Oracle Text索引の同期をオフにしたデータのインポート

サイズの大きいデータ・セットをターゲットのOracle Portalインスタンスにインポートする場合、Oracle Text索引の同期が有効になっていると、通常よりインポート処理に時間がかかることがあります。インポート時はOracle Text索引の同期を無効にしておくと、インポート処理に要する時間が短縮されます。Oracle Text索引の同期を無効にするには、次の手順を実行します。

1. インポート処理を開始する前に、ターゲットのOracle Portalインスタンスで、ポータル・スキーマ所有者(PORTAL)として次のコマンドを実行します。

@textjsub.sql STOP

テキスト索引の同期のスケジュール設定、開始方法、停止方法については、第10.3.5.4項「索引の同期化のスケジューリング」を参照してください。

2. wwv_context.syncジョブがdba_jobs表に存在しないことを確認します。

3. データ・セットをインポートします。詳細は、第12.6.1.2項「データのインポート」を参照してください。

4. ポータル・スキーマ所有者(PORTAL)として、textjsub.sqlスクリプトを実行します。

@textjsub.sql START

5. 必要であれば、Oracle Text索引を同期するためのコマンドを実行します。そのための手順は、第10.3.5.1項「Oracle Text索引の同期化」を参照してください。

12.9.8 ユーザーおよびグループの移行

エクスポートおよびインポートを実行する場合は、次の手順に従うことをお薦めします。

- ソース側の開発システムでポータル・オブジェクト(ページ・グループ、コンテンツ、ポートレットなど)を開発します。

- エクスポートおよびインポートのタスクを簡略化するため、ユーザー、グループおよび権限は本稼働システムでのみ割り当てます。

- エクスポートおよびインポートを使用して、ポータル・オブジェクトをターゲット側の本稼働システムに移行します。

- 必要に応じて、インポート済ポータル・オブジェクトにユーザーおよび権限を適用します。

ユーザーとグループは、Oracle Internet Directoryで定義します。Oracle Portalのエクスポートにアクセス制御リストおよびユーザーとグループのプリファレンスを含めることを選択すると、ポータル・スキーマに格納されているユーザーとグループのプロファイルがトランスポート・セットに含まれます。ただし、Oracle Internet Directoryに格納されているユーザーとグループの定義は移行されません。

ユーザーとグループのプロファイルをターゲット・ポータルに適切にインポートするには、参照されているユーザーとグループがターゲット・ポータルの関連するOracle Internet Directoryに存在する必要があります。

ポータルのコンテンツをテスト・サーバーまたは開発サーバーで構築しており、後で本稼働サーバーへの移動を予定している場合は、テスト・サーバーでセキュリティ権限を割り当てた後、コンテンツとともにこれらの権限を本稼働サーバーに移行できます。

この場合は、グループにセキュリティ権限を割り当て、テスト・インフラストラクチャと本稼働インフラストラクチャ間でユーザー・グループの一貫性について確認する必要がないようにします。

本稼働サーバーとテスト・サーバーの両方におけるユーザー・グループを正確にモデル化する必要がある場合は、Oracle Directory Integration and Provisioning機能を使用して、本稼働ディレクトリ・サーバーのデータをテスト・サーバーのデータに同期化するのが最適な手段です。本稼働サーバーのデータをテスト・サーバーと同期化すると、本稼働サーバーに影響を及ぼすことなくテスト・ユーザーとグループをOracle Internet Directoryのテスト・サーバーに追加できます。

注意:

ディレクトリ同期化の設定の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。本稼働サーバーからテスト・サーバーへのデータの同期化は自動的に行うのが最適です。反対にテスト・サーバーのデータを本稼働サーバーに同期化することはお薦めできません。

ユーザーとグループの移行の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

テスト・サーバーに本稼働グループも存在している場合は、テスト・サーバーですべてのアクセス権限をモデル化およびテストし、エクスポートしたオブジェクトを含むポータル・アクセス制御リストを本稼働システムに安全に移行できます。

テスト・システムの新しいグループおよびそのグループのアクセス権限を本稼働システムに移行する場合は、ポータル・コンテンツおよびアクセス制御リストを本稼働システムに移動する前に、グループの定義を本稼働システムに必ず移行してください。グループは最初に本稼働システムで作成し、テストのアクセス制御エントリを適用する前に、同期化プロセスによってテスト・システムに反映させることができます。グループを最初にテスト・インスタンスに作成する必要がある場合は、テスト・システムでのグループの作成に使用した方法で本稼働システムにグループを作成できます。これを手動で実行した場合、本稼働システムで同じ手順を手動で繰り返さないようにするには、テスト・インスタンスでLDAP問合せを発行してLDIFファイルを生成し、このファイルを本稼働インスタンスにロードします。例:

%ldapsearch –h testoid.domain.com –p 389 –D cn=fmwadmin –w password123 -b 'cn=portal.iasdb.domain.com,cn=groups,dc=domain,dc=com' –s sub –L 'cn=groupname' > newgroup.ldif

注意:

グループ情報を含むLDIFファイルを本稼働のOracle Internet Directoryインスタンスにロードする前に、ファイルを編集し、ポータル・インスタンス名を本稼働のOracle Internet Directoryインスタンスのポータル・インスタンス名と同じにする必要があります。通常、テスト・インスタンスと本稼働インスタンスではこの名前が異なっており、名前はグループDNの一部であるため、ファイルのロード前に変更する必要があります。

この例では、cn=portal.iasdb.dbserver.domain.dcom, cn=groups, dc=us, dc=oracle, dc=comはポータル・グループが存在する場所です。Oracle Internet Directoryのディレクトリ情報ツリーのエントリを編成する方法の詳細は、第7章「Oracle Portalの保護」を参照してください。これによって、グループ定義を含む、newgroup.ldifというファイルが作成されます。このファイルは次のようにldapaddを使用して、本稼働のOracle Internet Directoryインスタンスにロードできます。

%ldapadd –h prodoid.domain.com –p 389 –D cn=fmwadmin –w password123 –v -f newgroup.ldif

一部の生成済ポータル・グループに付与されたデフォルトの権限のみを配置するか、または権限をまったく配置しないことを選択できます。権限をまったく配置しない場合は、インポートを実行するユーザーがオブジェクトを所有します。このユーザーは、特定の配置に対して、必要に応じてターゲット・システムに権限を付与できます。

権限がPortal内の生成済グループに付与されており、これらの生成済グループがターゲット・システムにも存在するかぎり、生成済グループまたはユーザーを同期化する必要はありません。権限はこれらの生成済グループに正しく関連付けられます。

グループ・プロファイルをソース側からターゲット側に移行するとき、エクスポート済プロファイルがソース側のローカル・グループ用であった場合は、インポートによってグループのDNがターゲット・システムのローカル・グループ・ベースに再マップされます。ローカル・グループは、ポータル・グループのコンテナ(グループ・インストール・ベース)にあるグループです。グループ・インストール・ベースにないグループに対しては、DNは変更されません。

注意:

wwuディレクトリに含まれていたssoexpおよびssoimpスクリプトは、Oracle Fusion Middleware 9.0.xでは廃止されており、9.0.xログイン・サーバーとの互換性がありません。これらのスクリプトは使用しないでください。

13 連携型Portalアダプタの使用

この章では、PL/SQL HTTPアダプタとして知られている連携型Portalアダプタについて説明します。このアダプタを使用して他のOracle Portalインスタンスとポートレットを共有する方法についても説明しています。

この章の内容:

- 連携型Portalアダプタについて

- 連携型Portalアダプタを使用する環境の設定

- 連携型Portalアダプタを使用したプロバイダの登録

- 連携型Portalアダプタを使用したカスタム・ポートレットの作成

- 連携型Portalアダプタのトラブルシューティング

13.1 連携型Portalアダプタについて

この項の内容:

- 概要

- データベース・プロバイダとWebプロバイダの違い

- 連携型Portalアダプタの使用

- セキュリティの問題

- 連携型Portalアダプタに関連するポートレットの変更

13.1.1 概要

連携型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プロバイダとして利用できます。ユーザーはリモート・プロバイダの実装を意識する必要がなく、分散型ポータル・インストールを効果的に置き換えることができます。

13.1.2 データベース・プロバイダと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インスタンスを共有します。

13.1.3 連携型Portalアダプタの使用

連携型Portalアダプタの使用は、次の3つのカテゴリに分類できます。

表13-1 連携型Portalアダプタの使用

カテゴリ

説明

Oracle Portalデータベース・プロバイダ

Oracle Portal内に作成されるPortal DBプロバイダには、連携型Portalアダプタの使用に必要なコードが含まれます。つまり、フォーム、チャート、レポートなどを含むアプリケーションを他のポータル・インスタンスで表示できます。

ページ

ポートレットとして公開されるページは、連携型Portalアダプタを通じて実行することもできます。ページ内のリージョンには、ポートレットまたはアイテムを含めることができます。連携型Portalアダプタを使用すると、どのポータル・インスタンスからでもこれらのページにアクセスできます。

ユーザーが作成したプロバイダ

ユーザーが独自のPL/SQLプロバイダを作成する必要がある場合があります。この章で説明するガイドラインに従ってコード化されている場合は、連携型Portalアダプタを使用してこれらのプロバイダを公開できます。

13.1.4 セキュリティの問題

連携型Portalアダプタは、initSession SOAPメッセージに渡された情報に基づいて、リモート・ポータルにポータル・セッションを作成します。これにより、セキュリティの問題が生じます。これらのSOAPメッセージをレプリケートし、ポータル上の任意のユーザーに対してセッションを作成すれば、そのユーザーとしてポータルにアクセスできるためです。この問題を回避するため、2つのポータルで暗号鍵が共有され、SOAPメッセージの一部はその鍵を使用して暗号化されます。リクエストされたプライベート・ポータル・セッションは、すでに共有されている鍵で復号化できる場合にのみ作成されます。それ以外の場合は、PUBLICセッションが作成されます。ポートレットの表示リクエストは、Showメッセージによって行われます。このメッセージは、initSession SOAPメッセージによって作成される暗号化Cookieによって保護されます。暗号鍵を使用することにより、連携型Portalアダプタは安全に着信SOAPメッセージを信頼でき、ポータルがハッカーに公開されることなくポータル・インスタンスにポータル・セッションを作成できます。

関連項目:

第13.2.2項「HMACを使用した連携型Portalアダプタ・ユーザー認証」

他のポータル・インスタンスからそのポータル・インスタンスへのアクセスが、連携型Portalアダプタを介したアクセスのみであることがわかっている場合は、既知のポータル・インスタンス以外のコンピュータからのアクセスを制限するようにリスナーを構成することにより、セキュリティを強化することができます。これは、httpd.confファイルのAllowディレクティブを使用して設定します。

13.1.5 連携型Portalアダプタに関連するポートレットの変更

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アダプタを通じてアクセスすることもできます。

13.2 連携型Portalアダプタを使用する環境の設定

連携型Portalアダプタを使用するには、管理手順をいくつか実行する必要があります。これらの手順は、次のとおりです。

- PlsqlSessionCookieName値の確認

- HMACを使用した連携型Portalアダプタ・ユーザー認証

- Cookieドメインの設定

- OracleAS Single Sign-OnおよびOracle Internet Directoryサーバーの共有

13.2.1 PlsqlSessionCookieName値の確認

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名を更新できます。これを行うには、次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlで、Portalホーム・ページに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

2. 「ポータル」メニューから、「設定」→「データベース・アクセス記述子」を選択します。
「データベース・アクセス記述子の構成」ページが表示されます。

3. 既存のDADを編集するには、DAD名を選択して「編集」をクリックします。
「データベース・アクセス記述子の編集」ページが表示されます。

4. 「データベース・アクセス記述子の編集」ページの「セキュリティ、文書、別名とセッション」セクションで「セッションCookie名」に新しい値を入力します。

5. 「OK」をクリックします。

6. 管理対象サーバー(WLS_PORTAL)を再起動します。

13.2.2 HMACを使用した連携型Portalアダプタ・ユーザー認証

連携型Portalアダプタ機能は、分散したポータルのリモート・データベース・プロバイダの登録をサポートします。データベース・プロバイダは、リモート・ポータルの特別なURLに常駐するWebプロバイダのように登録されます。

注意:

リモート・ポートレットでパブリック・コンテンツをレンダリングするのみの場合は、この項を無視できます。

リモート・ポートレットにレンダリングできるコンテンツをパブリックなもの以外にまで広げるには、あるポータルのユーザーAが別のポータルでも同様にユーザーAであるようにする必要があります。通常は、パートナ・アプリケーション機能を使用する共有Oracle Application Server Single Sign-Onによってこれを実現できますが、共有ネーム・サーバー(Oracle Internet Directoryなど)、同期化されたネーム・サーバーまたは手動プロセスを使用して実現することも可能です。

この環境を実現できる場合は、Hash Message Authentication Code (HMAC)認証メカニズムを使用して、プライベート・セッションをリモート・ポータルで開始し、リモート・ポートレットのプライベート・コンテンツをレンダリングできます。

HMACキーの設定

Portal Aの管理者がPortal BのユーザーによるPortal A上のセッションの作成を許可する場合は、秘密鍵を各ポータル上に格納する必要があります。この鍵は、それらの間で送信されるSOAPリクエストの一部の暗号化と復号化に使用されます。鍵が見つからない場合や各ポータルで鍵が異なる場合は、PUBLICセッションのみが作成されます。

鍵は10文字以上の長さにする必要があります。また、管理者はセキュアで適切な方法を使用して、他の管理者に鍵の値を通知する必要があります。

キー・ストアの管理タスクを実行するために、SQLスクリプトが提供されています。これらのスクリプトはすべてORACLE_HOME\portal\admin\plsql\wwcディレクトリにあります。

表13-2 キー・ストアの管理用SQLスクリプト

スクリプト

説明

proadsss.sql

送信の終了時にキーを設定します(リモート・ポートレットを含むページが作成されるポータル・インスタンス)。

proadssr.sql

受信の終了時にキーを設定します(ポートレットが作成されるポータル・インスタンス)。

proadsds.sql

送信の終了時にキーを削除します(リモート・ポートレットを含むページが作成されるポータル・インスタンス)。

proadsdr.sql

受信の終了時にキーを削除します(ポートレットが作成されるポータル・インスタンス)。

ここでの送信および受信は、SOAPメッセージの送信および受信のことです。

例13-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にプロバイダを公開する)、ポータル・インスタンスごとに異なるキーを設定できます。

13.2.3 Cookieドメインの設定

通常、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ドメインの範囲はブラウザに返信できるようにすべて拡張されます。これで、ポートレット内のリンクは正常に機能します。

関連項目:

第B.3項「ポータル・セッションCookieの構成」

注意:

中間層サーバーのホスト・ドメイン名にピリオド(「.」)が1つのみ含まれている場合、それはOracleのテスト済構成ではありません。予期しない結果を避けるため、中間層サーバーには複数の部分で構成されるドメイン名を指定してください。これにより、中間層のホスト・ドメイン名に複数のピリオドが含まれるようになります。

13.2.4 OracleAS Single Sign-OnおよびOracle Internet Directoryサーバーの共有

共通のIdentity Managementサーバーを利用すると、シングル・サインオンを最大限に活用できます。ポータル・セッション情報はリモート・ポータルに渡され、そこで連携型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を構成します。これを行うには、次の手順を実行します:

1. 次の手順を実行して、portal1の同じOIDComponentを指すようにportal2のOIDDependency要素を変更します。

1. Oracle Enterprise Manager 11gでPortalホーム・ページに移動します。

2. 「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。

3. 「Oracle Internet Directory (OID)」セクションでportal1のOIDの詳細を入力します。

2. 次の例に示すように、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を実行する必要があります。

3. Portalスキーマにログインしてportal2のPortal Metadata Repositoryを更新し、WWSEC_PERSON$表のGUID列を更新してプレースホルダGUIDを設定します。これにより、新しく関連付けたOIDサーバーから新しいGUIDを取得できます。

SQL> update wwsec_person$ set guid = ':'||id;
SQL> commit;

13.3 連携型Portalアダプタを使用したプロバイダの登録

連携型Portalアダプタを使用したプロバイダの登録は、Webプロバイダの登録と似ています。次の手順を実行する必要があります。

1. Oracle Portalにログインします。
「Portalビルダー」ページが表示されます。

2. 「管理」タブをクリックして「ポートレット」サブタブをクリックします。

3. 「リモート・プロバイダ」ポートレットの「プロバイダの登録」をクリックします。

4. 「プロバイダ情報」ページで、「名前」、「表示名」、「タイムアウト」および「タイムアウト・メッセージ」を通常どおり入力します。「実装スタイル」が「Web」に設定されていることを確認します。プロバイダは実際にはPL/SQLで記述されていますが、プロバイダとのすべての通信はデータベース・プロバイダではなく、Webプロバイダとして行われます。このため、「実装スタイル」を「Web」設定する必要があります。

5. 「一般プロパティ」ページで、アダプタ・サービスのURLを入力します。URLの構文は、次の形式で入力する必要があります。

http://host:port/adapter/dad/schema

DADとスキーマが同じ場合は、次の形式も使用できます。

http://host:port/adapter/dad

host、port、DADおよびschemaはリモート・ポータル・インスタンスの場所を示します。URLをブラウザに貼り付けることにより、URLが正しいかどうかを確認できます。

URLが正しい場合は、アダプタ・テスト・ページに接続できたというメッセージが記載されたページに移動します。

6. 「Portalと同じCookieドメインのWebプロバイダ」オプションを選択します。これにより、プロバイダから生成されるCookieがブラウザに返信されるようになります。前述のように、ポータルによって作成されるCookieの範囲を拡張しなければならない場合があります。

7. 「サービスID」を入力します。これは、urn:<provider name>という形式で入力する必要があります。provider nameは、リモート・ポータル・インスタンス上のプロバイダの名前です。これは大文字で入力します(大文字・小文字は区別されます)。提携方Portalアダプタがリモート・ポータルの特定のプロバイダを見つけるために使用する情報です。
プロバイダとして公開されているページの場合、プロバイダの名前はMYPAGE970D272EBE9D2D0FE034080020F7DA4Bのようになります。「表示名」ではなく、この「名前」を指定してください。名前と表示名は、Oracle Portalの「管理」タブにある「ポートレット」サブタブの「リモート・プロバイダ」ポートレットで確認できます。「プロバイダをブラウズ」アイコンをクリックすると、すべてのプロバイダの名前が表示されます。

8. 「ユーザー/セッション情報」セクションで、「ユーザー」ラジオ・ボタンを選択し、「ログイン頻度」を「ユーザー・セッションごとに1回」に設定します。これらの設定により、リモート・ポータル・インスタンス上にポータル・セッションを作成できるように、リクエストと一緒に情報が送信されます。

注意:

新規プロバイダを作成または登録すると、「ポートレット・ステージング領域」の「ポートレット・リポジトリ」にページが作成され、そのプロバイダのポートレットが表示されます。このページはすべてのログイン・ユーザーに表示されるわけではありません。プロバイダを公開したユーザーおよびポータル管理者にのみ表示されます。公開者またはポータル管理者は、プロバイダのページ・プロパティを変更して、必要に応じて適切なユーザーおよびグループに権限を付与できます。

13.4 連携型Portalアダプタを使用したカスタム・ポートレットの作成

連携型Portalアダプタを通じてアクセスされるデータベース・プロバイダを記述する場合は、次の2つのコードについて特別な注意が必要です。これらを次に示します。

- 相対リンク

- パーソナライズ

13.4.1 相対リンク

連携型Portalアダプタを通じてアクセスされるポートレット内のすべてのリンクには、相対リンクではなく、絶対リンクを使用する必要があります。相対リンクは、リモート中間層ではなく、ローカル中間層を基準にするため、機能しません。たとえば、/etc/etcではなく、http://myhost.mycompany/etc/etcという形式でリンクを作成する必要があります。

13.4.2 パーソナライズ

連携型Portalアダプタを通じてポートレットにアクセスするときのパーソナライズの適用方法は、PDK-Javaポートレットの場合と似ています。連携型Portalアダプタを通じてパーソナライズが機能するようにするには、主に次の2つの領域でポートレット・コードを変更する必要があります。

- edit_defaultsモードまたはpersonalizeモード(パラメータp_modeがNULLの場合)でポートレットを表示するように、ポートレットを表示するコールにロジックを追加する必要があります。p_modeがOK、APPLYまたはRESETの場合、パーソナライズは適切なものとしてに保存されます。

- パーソナライズ・ページ用として生成される<FORM> HTMLタグは、プロシージャwwpro_api_adapter.open_formを使用して作成する必要があります。これにより、フォームの正しい動作が実現し、ページの送信時に正しいパラメータが渡されるようになります。パーソナライズ・フォームの送信時に発生するイベントの順序は、次のとおりです。

1. ページがローカルPPEに送信されます。この送信とともに送信が必要な標準パラメータ(_providerid、_dad、p_actionなど)およびパーソナライズするパラメータがいくつかあります。プロシージャwwpro_api_adapter.open_formは、この送信の生成をできるかぎり単純にするために提供されています。

2. 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を参照してください。

13.5 連携型Portalアダプタのトラブルシューティング

連携型Portalアダプタを介してページ・ポートレットを表示する際に既知の制限事項がいくつかあります。

- 詳細の表示モードは機能しません。つまり、ポートレットに関する詳細情報を表示するリンクとしてポートレット名を表示できません。

- ページ・ポートレットに複数のタブが含まれている場合は、タブをクリックすると、深いリンクになり、描画されるページはページ全体に表示されます。つまり、元のページ内にポートレットとして表示されません。

- 連携型Portalアダプタを介してページを表示した場合、ページのバナーを含むナビゲーション・ページは正しく描画されません。たとえば、通常のページ・ポートレットでは「パーソナライズ」リンクによって、コンテナ・ページのパーソナライズ・オプションが表示されますが、リモートのページ・ポートレットでは表示されません。さらに、連携型Portalアダプタを介して表示されたページ・ポートレットには、コンテナ・ページのバナーが表示されませんが、通常のページ・ポートレットの場合はバナーが表示されます。

- ページ・ポートレットにナビゲーション・ページ・ポートレットが含まれ、そこにサブ・ページ・リージョンが含まれている場合、連携型Portalアダプタを介して表示されたページ・ポートレットにはサブ・ページ・リージョンは表示されません。リモート以外のページ・ポートレットの場合は、そのリージョンに、ポートレットを含むコンテナ・ページのサブページが表示されます。

- 連携型Portalアダプタ・ポートレットをエクスポートおよびインポートする場合、ターゲット・ポータル・インスタンスで次の作業を実行していないと、ポートレットはターゲット・インスタンスに表示されません。

1. ソース・ポータル・インスタンスで実行されているPL/SQLアダプタを使用するようにターゲット・ポータル・インスタンスを構成します。

2. ソース・ポータル・インスタンスの連携型PortalアダプタのWebプロバイダ・ページで、ターゲット・ポータル・インスタンスに「表示」権限を付与します。

第IV部

付録

第IV部には次の付録があります。

- 付録A「Oracle Fusion Middleware構成ファイルの使用」

- 付録B「Oracle Portalのインストールおよび構成スクリプトの使用」

- 付録C「JavaServer PagesとOracle Portalとの統合」

- 付録D「wwv_context APIの使用」

- 付録E「Portalツールのプロバイダの構成」

- 付録F「仮想プライベート・ポータルの設定と管理」

- 付録G「Oracle Portalのトラブルシューティング」

A Oracle Fusion Middleware構成ファイルの使用

Oracle Portalの管理にはOracle Enterprise Manager 11g Fusion Middleware Controlを使用することをお薦めしますが、Oracle Fusion Middlewareの構成ファイルと表から直接変更することもできます。この付録では、Oracle Fusion Middlewareや中間層にあるそのコンポーネントの接続や動作に影響を及ぼす可能性のあるファイルと表およびその接続先にある他のコンピュータについて説明します。

関連項目:

Oracle Fusion Middleware管理者ガイド

この付録の内容:

- Oracle HTTP Serverの構成ファイル(httpd.conf)

- DAD構成ファイル(portal_dads.conf)

- Oracle Databaseの接続構成

- Web Cache構成ファイル

- OracleAS Single Sign-Onのパートナ・アプリケーション表

- ローカルのHOSTSファイル

関連項目:

appConfig.xmlファイルの詳細は、第5.6.9項「PortalのParallel Page Engineの構成」を参照してください。

A.1 Oracle HTTP Serverの構成ファイル(httpd.conf)

Oracle HTTP Serverの構成ファイルhttpd.confには、Oracle HTTP Serverを実行するための構成情報が入っています。このファイルの内容は、リスニング・ポート、サーバー名、仮想ホスト、プロキシ構成などに関する情報です。また、SSL (Secure Sockets Layer)サポートの構成もこのファイルで行います。その場合は、証明書や他のHTTPS構成ディレクティブなどの情報を定義します。このファイルは次の場所にあります。

ORACLE_INSTANCE\config\OHS\ohs1\httpd.conf

仮想ホストをOracle HTTP Serverに追加作成する場合、次の例に示すように、Oracle Portalで使用される仮想ホスト用にRewriteEngineおよびRewriteOptionsのmod_rewriteディレクティブをhttpd.confファイルに追加する必要があります(太字の部分)。

NameVirtualHost *:7778
<VirtualHost *:7778>
ServerName http://www.xyz.com:7779
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

例A-1 httpd.conf

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <portal-midtier xmlns="http://xmlns.oracle.com/portal/config/midtier" description="Oracle Portal Midtier Configuration Parameters">
<useWebCache>true</useWebCache>
<jspRoot>internal_jsp</jspRoot>
<jspSrcAlias>/internal_jsp/</jspSrcAlias>
<useSessionMemorycache>true</useSessionMemorycache>
<autoRedirect>true</autoRedirect>
<maxParallelPortlets>20</maxParallelPortlets>
<maxParallelPagePortlets>10</maxParallelPagePortlets>
</portal-midtier>

A.2 DAD構成ファイル(portal_dads.conf)

このファイルには、PL/SQLデータベース・アクセス記述子(DAD)用の構成パラメータがあります。DADは、データベース・サーバーがHTTPリクエストを満たすための方法を示す値のセットです。

ポータルDADを変更するには、Oracle Enterprise Manager 11g Fusion Middleware ControlやWLSTを使用するか、または手動で、portal_dads.confファイルを編集します。

- Fusion Middleware Controlの使用

- WLSTを使用したポータルDADの構成

- portal_dads.confファイルを手動で編集

手動でportal_dads.confファイルを更新する場合は、必要なmod_rewriteディレクティブをhttpd.confに、mod_wlsディレクティブをmod_weblogic.confにそれぞれ追加する必要があります。

Fusion Middleware Controlの使用

Fusion Middleware Controlを使用して、次のタスクを実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlを開きます。

2. Portalインスタンスを開きます。

3. 「ポータル」メニューから「設定」→「データベース・アクセス記述子」を選択して、DAD構成情報を表示します。

DADファイルを編集するには、次の手順を実行します。

1. 編集するポータルDADを選択し、「編集」をクリックします。

2. 新しい値を入力し、「OK」をクリックします。

3. Oracle HTTP ServerとWLS_PORTALコンポーネントを再起動します。

これによって、必要なmod_rewriteとmod_weblogicのディレクティブが追加されます。

DADの構成またはOracle Fusion Middleware Controlの使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

portal_dads.confファイルを手動で編集

portal_dads.confファイルで行う更新のタイプに応じて、次のタスクのいずれかまたはすべてを実行します。

1. 新しいポータルDADをportal_dads.confファイルに追加した場合は、次のRewriteディレクティブをhttpd.confファイルに追加する必要があります。

RewriteRule (^/pls/<dad>/.*) /portal$1 [PT]
RewriteRule (^/pls/<dad>$) /portal$1 [PT]

<dad>は、新しいDADの名前です。例:

RewriteRule (^/pls/mydad/.*) /portal$1 [PT]
RewriteRule (^/pls/mydad$) /portal$1 [PT]

2. portal_dads.confファイルでDAD名を変更した場合は、前述の手順で説明したRewriteディレクティブを新しいDAD名で更新する必要があります。

3. 中間層で行われた手動による構成の変更を更新するために、次のコマンドを実行します。

ORACLE_INSTANCE/bin/opmnctl restartproc process-type=OHS

plsqlSessionCookieName値の更新

plsqlSessionCookieNameはFusion Middleware Controlで変更できますが、portal_dads.confファイルで、この値を手動で変更することもできます。このファイルは次の場所にあります。

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

このファイルの一般的なエントリは、次のようになります。

<Location /pls/portal>
SetHandler pls_handler
Order allow,deny
Allow from All
AllowOverride None
PlsqlDatabaseUsername portal
PlsqlDatabasePassword SomePassword
PlsqlDatabaseConnectString myhost.domain.com:1521:mySID
PlsqlDefaultPage portal.home
PlsqlAuthenticationMode SingleSignOn
PlsqlSessionCookieName portal
PlsqlMaxRequestsPerSession 500
PlsqlDocumentTablename portal.wwdoc_document
PlsqlDocumentPath docs
PlsqlDocumentProcedure portal.wwdoc_process.process_download
PlsqlPathAlias url
PlsqlPathAliasProcedure portal.wwpth_api_alias.process_download
PlsqlFetchBufferSize 128
</Location>

DADエントリを編集するには、PlsqlSessionCookieName値を、たとえばportal2に変更します。ファイルを保存した後は、Oracle HTTP Server構成を更新して、WLS_PORTALを再起動します。

関連項目:

Fusion Middleware Controlを使用してDADを構成する方法については、第5.6.4項「Fusion Middleware Controlを使用したポータルDADの構成」を参照してください。

注意:

portal_dads.confファイルは、Fusion Middleware Controlを使用して編集することをお薦めします。

手動でportal_dads.confファイルを編集する場合は、必要なmod_rewriteとmod_weblogicのディレクティブを、httpd.confとmod_weblogic.confのファイルにそれぞれ追加する必要があります。これを行うには、Fusion Middleware Controlを使用して、第A.2項「DAD構成ファイル(portal_dads.conf)」で説明した手順を実行します。

例A-2 portal_dads.conf

<Location  /pls/portal>
SetHandler  pls_handler
Order  deny,allow
Allow  "from All"
AllowOverride  None
PlsqlAuthenticationMode  SingleSignOn
PlsqlDatabaseUsername  HW081010A_PORTAL
PlsqlDatabasePassword  welcome1
PlsqlDatabaseConnectString  xmlns.oracle.com:1521:abc.oracle.com  ServiceNameFormat
PlsqlNLSLanguage  AMERICAN_AMERICA.AL32UTF8
PlsqlPathAlias  url
PlsqlSessionCookieName  HW081010A_PORTAL
PlsqlPathAliasProcedure  HW081010A_PORTAL.wwpth_api_alias.process_download
PlsqlSessionStateManagement  StatelessWithFastResetPackageState
PlsqlDocumentPath  docs
PlsqlDocumentProcedure  HW081010A_PORTAL.wwdoc_process.process_download
PlsqlDocumentTablename  HW081010A_PORTAL.wwdoc_document
PlsqlDefaultPage  HW081010A_PORTAL.home
</Location>

A.3 Oracle Databaseの接続構成

SQL*Net構成ファイルは、DADで接続文字列として使用されるエントリを定義します。通常、Oracle PortalがインストールされているデータベースにOracle WebLogic Serverから接続する方法についての情報は、DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configurationのportal_dads.confおよびDATABASE_HOME\network\adminのsqlnet.oraの各ファイルに記述されています。

SQL*Netの構成の詳細は、Oracle Database 11gドキュメント・ライブラリのOracle Database Net Services管理者ガイドを参照してください。

A.4 Web Cache構成ファイル

Oracle Web Cache構成ファイルの詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

A.5 OracleAS Single Sign-Onのパートナ・アプリケーション表

OracleAS Single Sign-On側にある構成表は、パートナ・アプリケーション表WWSSO_PAPP_CONFIGURATION_INFO$です。この表の管理は通常、OracleAS Single Sign-Onアプリケーションのユーザー・インタフェース(パートナ・アプリケーションの追加または編集用)を使用して行います。

最初のインストールの場合は、ssoregツールを使用して、Portalのmod_osso_urlを登録する必要があります。これにより、OracleAS Single Sign-Onのパートナ構成表とOracle Portalの有効な構成表の両方に設定が移入されます。例:

$ORACLE_HOME/sso/bin/ssoreg.sh
-site_name portal.example.com:8090
-config_mod_osso TRUE
-mod_osso_url http://portal.example.com:8090
-remote_midtier
-config_file config_file_path

Windowsでは、ssoreg.batバッチ・ファイルを実行する必要があります。

A.6 ローカルのHOSTSファイル

ネットワーク・ホストにあるHOSTSファイルでは、IP名とIPアドレスとのマッピングを定義します。通常、ドメイン・ネーム・サーバー(DNS)がIP名とIPアドレスのマッピングを行います。第5章「基本的な構成および管理」に説明されている一部の構成では、内部のネットワーク内に定義されていないドメイン名を使用して、内部のネットワークでホストをアドレス指定することが必要な場合もあります。このような場合は、サーバーのHOSTSファイルを使用して必要な名前解決を行うことができます。

B Oracle Portalのインストールおよび構成スクリプトの使用

Oracle Fusion Middlewareの一部としてOracle Portalをインストールした後は、いくつかのスクリプトがインストール後の構成を行うために使用できるようになります。

この付録の内容:

- cachjsub.sqlを使用した無効化メッセージの処理ジョブの管理

- secupoid.sqlスクリプトの使用

- ポータル・セッションCookieの構成

- セッション・クリーン・アップ・ジョブの管理

- 実行時間とキャッシュの統計

- cfgiaswスクリプトを使用したモバイルの構成

- cfgxodnc.plスクリプトを使用したキャッシュ・キーのモバイル・デバイス・コンポーネントの変更

- カテゴリおよびパースペクティブ・スクリプトの使用

- PDK-Javaのプリファレンス・ストア移行/アップグレード・ユーティリティの使用

- スキーマ検証ユーティリティの使用

B.1 cachjsub.sqlを使用した無効化メッセージの処理ジョブの管理

Oracle Portalは、パフォーマンスを向上させるためにキャッシュを使用します。使用されるキャッシュのタイプの1つに、無効化ベースのキャッシュがあります。無効化ベースのキャッシュでは、Oracle Portalは様々なオブジェクト(ページ、ポートレットなど)を一定期間キャッシュします。これらのオブジェクトがリクエストされると、オブジェクトがキャッシュされている場合はキャッシュから取得され、キャッシュされていない場合はMetadata Repositoryから再生成されます。これらのオブジェクトのキャッシュは、最大キャッシュ時間に達したとき、または無効化メッセージによってオブジェクトが明示的に無効化したときに期限切れになります。

Oracle Portalは、キャッシュ内のオブジェクトを期限切れにするときに、無効化メッセージを使用します。無効化メッセージは、強い無効化と弱い無効化に分類されます。強い無効化はすぐに有効になります。つまり、無効化するオブジェクトはすぐにキャッシュから期限切れになります。弱い無効化は、無効化処理ジョブによって処理されたときに有効になります。無効化ジョブの実行頻度は構成可能です。これは、cachjsub.sqlスクリプトを使用して行います。

無効化処理ジョブの実行頻度を変更するには、次の手順を実行します。

1. 次のディレクトリに移動します。
ORACLE_HOME\portal\admin\plsql\wwc

2. ポータル・スキーマがインストールされているデータベースで、そのスキーマの適切なユーザー名とパスワードを使用してSQL*Plusにログインします。
例:

sqlplus portal/portal

3. 次のコマンドを入力して、無効化処理ジョブの実行頻度を更新します。

SQL> @cachjsub.sql <start_time> <start_time_fmt> <interval_mins>

cachjsub.sqlは、次の3つのパラメータをとります。

- start_timeには、最初のジョブが実行される時間またはSTARTを指定します。

- start_time_fmtには、start_timeの値に適用するOracle日付書式モデルを指定します。Oracle日付書式モデルの詳細は、データベースのドキュメント・ライブラリを参照してください。

- interval_minsには、実行の間隔を分単位で指定します。

注意:

最初のパラメータにSTARTを指定すると、2番目のパラメータは無視され、デフォルトで現在の時刻が開始時刻になります。

例1

SQL> @cachjsub.sql START null 120

例2

SQL> @cachjsub.sql '02-22-2005 7:30' 'MM-DD-YYYY HH:MI' 1440

例3

SQL> @cachjsub.sql '06-14-2005 15:30' 'MM-DD-YYYY HH24:MI' 60

注意: 例3では、24時間形式で時刻が表示されます。

B.2 secupoid.sqlスクリプトの使用

デフォルトでは、Oracle Portalは、Oracle Internet Directoryに接続するときに、SSLを使用しないLDAPを使用します。Oracle Internet DirectoryサーバーがSSLポートに対応している場合は、LDAP over SSL (LDAPS)を使用するようにOracle Portalを構成できます。

関連項目:

Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

SSLを使用してOracle Internet Directoryに接続するようにOracle Portalを構成するには、secupoid.sqlスクリプトを実行する必要があります。このスクリプトにより、Oracle Internet Directoryに関連する次のOracle Portal構成パラメータを変更できます。

- Oracle Internet Directoryホスト名

- Oracle Internet Directoryポート

- アプリケーションOracle Internet Directoryパスワード

- SSL設定

Oracle Portalをインストールすると、Oracle Internet Directoryサーバーを使用するように自動的に構成されます。ただし、SSLを使用するかどうかなど、インストール後に一部の設定を変更できます。Oracle Internet DirectoryのSSL接続に変更するには、PORTALスキーマのORACLE_HOME/portal/admin/plsql/wwc/secupoid.sqlスクリプトを実行してLDAPポートのかわりにLDAPSポートを指定すると、SSLを使用するように指定されます。

secupoid.sqlスクリプトの実行

この項では、SQL*Plusからsecupoid.sqlを実行した例を示します。

この例では、LDAPをポート3060で実行するようにOracle Internet Directoryを初期構成しています。次にLDAPSポートを3130上で有効にします。サーバー名は変わらないため、以前の値を保持したままポートを更新し、SSLを使用することを指定するために「Use SSL?」に対して「Y」を設定します。このスクリプトを実行すると、現在の構成が表示され、変更可能な構成を置き換えることができます。スクリプトの実行後に、Oracle PortalのOracle Internet Directoryキャッシュを更新することもできます。SSLを有効にしても、Oracle PortalによってキャッシュされたOracle Internet Directory情報は変更されません。このため、通常はこうした状況でキャッシュを更新する必要はありません。

SQL> @secupoid
Current Configuration
--------------------
OID Host: oid.domain.com
OID Port: 3060
Application DN:
orclapplicationcommonname=ssl_portal.080130.052806.514018000,cn=portal,cn=products,cn=oraclecontext
Application Password: 2E1325D176112857A6E76E803E6284B0
Use SSL? N

PL/SQL procedure successfully completed.

Updating OID Configuration Entries
Press [Enter] to retain the current value for each parameter
For SSL Connection to LDAP, specify "Y"es or "N"o
------------------------------------------------
Enter value for oid_host:
Enter value for oid_port: 3130
Enter value for app_password:
Enter value for use_ssl_to_connect_to_ldap: Y
Enter value for refresh_with_new_settings: N

PL/SQL procedure successfully completed.

No errors.

このスクリプトの実行後に、Oracle Portalは、Oracle Internet DirectoryでLDAPSアクセスを使用するように構成されます。

secupoid.sqlを実行すると、Oracle Metadata Repositoryのポータル・スキーマに格納されているOracle Internet Directoryのポート番号が変更される場合があります。

B.3 ポータル・セッションCookieの構成

Oracle Portalは、セッションCookieを使用して、ポータル・アプリケーションのセッション状態を保持します。ポータルが正常に機能するよう、クライアントのブラウザはサーバーのCookieを受け取るように構成しておく必要があります。インストール時には、ポータル・セッションCookieに、ほとんどのインストールで適用できるように設定されているデフォルトの名前、適用範囲およびセキュリティが定義されます。この項ではこれらのデフォルトについて説明し、必要な場合にこれらの値を変更する方法について説明します。

B.3.1 Cookieの名前の構成

デフォルトでは、ポータルのセッションCookieに、ポータル・スキーマへのアクセスに使用されるデフォルトのデータベース・アクセス記述子(DAD)に従ってportalという名前が設定されます。明示的に別の設定をする必要がある場合は、Oracle Enterprise Manager 11gを使用してCookie名を変更することができます。これを行うには、Oracle Enterprise Manager 11g Fusion Middleware ControlのDADの編集ページにアクセスする必要があります。このページは、Oracle Portalの中間層コンポーネントのmod_plsqlサービスにあります。Cookie名は、「文書、別名およびセッション」ページで設定できます。Cookie名を変更するには、「セッションCookie」セクションの「セッション・クッキー名」フィールドに名前を指定します。

B.3.2 Cookieの適用範囲の構成

2つの中間層から同じポータルに同時にアクセスする場合や、PL/SQLアダプタ機能に必要なポータルCookieドメインを開く場合は、そのアーキテクチャが使用するすべての中間層サーバーにOracle PortalセッションCookieが送信されるように、Cookieの適用範囲を定義する必要があります。デフォルトでは、セッションCookieのドメインは、その生成元のホストに適用されます。Cookieのパスは「/」に設定されます。

注意:

これらの変更はポータルで通信量が発生していないときに行ってください。そのようにしないと、セッションCookie名を変更した後、既存のセッションでセッション・エラー(ORA-20000)が発生します。

たとえば、Cookieがwww.company.comから生成された場合は、そのCookieのドメインはwww.company.comとなります。しかし、たとえば別のサーバーportal.company.comも、このセッションCookieにアクセスする必要がある中間層のサーバーである場合があります。この場合は、Cookieドメインを広げて、portal.company.comサーバーもこのCookieを参照できるようにする必要があります。

ポータル・セッションCookieの適用範囲を変更するには、次の手順を実行します。

1. 次のディレクトリに移動します。

ORACLE_HOME\portal\admin\plsql\wwc

2. 作成したOracle Portalスキーマがインストールされているデータベースで、ポータル・スキーマとしてSQL*Plusにログインします。例:

sqlplus portal\portal_pwd

3. 次のコマンドを入力します。

SQL> @ctxckupd
OracleAS Portal
Current Settings for Portal Session Cookie:
Cookie Domain : Only send cookie back to originating host:port
Set Cookie as Secure: Y
Enter the domain for the session cookie: .company.com
Should cookie be flagged as secure for HTTPS sessions? (Y/N): N
Settings changed to
Cookie Domain : .company.com
Do not set cookie as secure. (N)
SQL>

このコマンドを使用すると、セッションCookieのCookieドメインを設定できます。この例では、Cookieドメインは.company.comに設定されます。

注意:

- 各種のリスナーを使用したり、複数のドメイン間でセッションCookieを保持している場合は、Cookieドメインがホスト名のみになるように指定します。たとえば、2台のコンピュータからOracle Portalにアクセスする場合は、次のように指定します。
— machine1.us.company.com:3000

— machine2.us.company.com:4000

ctxckupd.sqlを実行するときは、Cookieドメインを.us.company.comに設定します。

- Cookieのドメインは、ユーザーの優先言語を判断する永続的なCookieである、NLS_LANGUAGE Cookieの有効範囲も特定します。このNLS_LANGUAGE Cookieは、「言語の設定」ポートレットで言語を選択するときに設定されます。

B.3.3 Cookieの保護

Oracle Portalのこのリリースでは、スクリプトctxckupd.sqlに付加的なオプションSet Cookie as Secureが含まれています。

このスクリプトは、デフォルトではORACLE_HOME\portal\admin\plsql\wwcにあります。このスクリプトを実行すると、次のように出力されます。

SQL> @ctxckupd
OracleAS Portal
Current Settings for Portal Session Cookie:
Cookie Domain : Only send cookie back to originating host:port
Set Cookie as Secure: Y
Enter the domain for the session cookie...
Leave blank to scope to originating host:
Should cookie be flagged as secure for HTTPS sessions? (Y/N): N
Settings changed to
Cookie Domain : Only send cookie back to originating host:port
Do not set cookie as secure. (N)
SQL>

Set Cookie as Secureは、リクエストがHTTPS接続を介してのみ渡される場合は、Cookieをサーバーへ返信しなければならないことを意味します。この設定では、セッションCookieを保護する必要がある場合には、必ずセキュアな接続を介して転送されるようになります。デフォルトでは、このオプションはYesに設定されており、ほとんどの配置においてこれで問題ありません。

ただし場合によっては、Set Cookie as SecureオプションをNoに設定しなければならないことがあります。たとえば、HTTPとHTTPSの両方を介してポータルにアクセスし、両方のプロトコルでセッションCookieを共有する場合があります(これは、両者ともデフォルトのポート、つまりHTTPでは80、HTTPSでは443で実行されている場合に可能です)。このような場合には、Set Cookie as SecureがNoに設定されている場合は、HTTPSリクエストを介して生成された同じCookieが、後続のどのHTTPリクエストにも送信されます。

B.4 セッション・クリーン・アップ・ジョブの管理

Oracle PortalとOracleAS Single Sign-Onは、他のWebベース・アプリケーションと同様に、セッション管理を行います。セッションはCookieを使用して管理されます。セッション情報は、Oracle PortalスキーマおよびOracleAS Single Sign-Onスキーマの表に格納されます。ユーザーがログアウトすると、セッション情報は非アクティブのマークが設定されます。DBMSジョブは、非アクティブな行をクリーン・アップします。

セッション表には、アクティブのマークが設定された行の数が累計されます。ユーザーがログアウトするかわりにブラウザをシャットダウンしたときは、実際に使用されていない場合でも、その行はアクティブになります。クリーン・アップ・ジョブは、指定された期間を経過したアクティブな行をクリーン・アップします。

Oracle Portalをインストールすると、セッション表(WWCTX_SSO_SESSION$)のセッション・クリーン・アップを実行するDBMSジョブがインストールされます。クリーン・アップ・ジョブは、24時間ごとに実行されるように設定されます。最初にスケジュールされたクリーン・アップは、ジョブのインストールから24時間後に発生します。

ジョブが実行されると、非アクティブなセッションがすべて削除され、さらにアクティブのマークが設定されたセッション(WWCTX_SSO_SESSION$.ACTIVE = 1)のうち、7日間を経過したもの(WWCTX_SSO_SESSION$.SESSION_START_TIME < sysdate - 7)がすべて削除されます。

これらのデフォルト設定を変更するには、ポータル・セッションを管理するOracleAS Single Sign-OnスキーマまたはOracleAS Single Sign-Onセッションを管理するOracle Portalスキーマにあるジョブ管理スクリプトをいくつか実行します。これらのジョブ管理スクリプトは、同じセッション管理インフラストラクチャを利用します。

現在のクリーン・アップ・ジョブ情報を取得するには、次の手順を実行します。

1. 次のディレクトリに移動します。

ORACLE_HOME\portal\admin\plsql\wwc

2. Oracle PortalスキーマまたはOracleAS Single Sign-Onスキーマがインストールされているデータベースで、そのスキーマの適切なユーザー名とパスワードを使用してSQL*Plusにログインします。
例:

sqlplus portal\portal

3. 次のコマンドを入力して、現在のジョブ情報を取得します。

SQL> @ctxjget

現在インストールされているジョブ情報が、DBMS_JOBパッケージから返されて表示されます。

The session cleanup job is job ID 7381
dbms_job.isubmit(job=>7381,what=>'begin execute immediate''begin
wwctx_sso.cleanup_sessions(p_hours_old => 168); end;''; exception when
others then null; end;',next_date=>to_date('2001-04-17:14:07:20',
'YYYY-MM-DD:HH24:MI:SS'),interval=>'SYSDATE + 24/24',no_parse=>TRUE);

PL/SQL procedure successfully completed.

結果には、実行するプロシージャ、それに渡すパラメータ、次の呼出しが発生する日時が示されています。この例では、1週間(168時間)経過しているアクティブ・セッションをこのジョブでクリーン・アップします。また、このジョブの次回実行予定は2001年4月17日の午後5:14で、それ以降は24時間ごとに実行されます。

削除の対象とするセッションの有効期間を調整したり、クリーン・アップの頻度を変更したりするなど、ジョブの実行を変更する必要がある場合は、ctxjsub.sqlスクリプトを実行し、変更した実行パラメータを送信します。

変更済の実行パラメータを送信するには、次の手順を実行します。

1. 次のディレクトリに移動します。

ORACLE_HOME\portal\admin\plsql\wwc

2. Oracle PortalスキーマまたはOracleAS Single Sign-Onスキーマがインストールされているデータベースで、そのスキーマの適切なユーザー名とパスワードを使用してSQL*Plusにログインします。例:

sqlplus portal\portal

3. 次のコマンドを入力して、新しいクリーン・アップ・ジョブ情報を送信します。

@ctxjsub <hours_old> <start_time> <time_format> <interval_hours>

表B-1は、ctxjsubパラメータの一覧です。

表B-1 ctxjsubのパラメータ

パラメータ

説明

hours_old

削除の対象とするアクティブ・セッションの有効期間

start_time

次のジョブを実行する時刻

time_format

start_timeの書式を指定するための時刻書式

interval_hours

クリーン・アップ・ジョブの実行間隔(時間)

例:

SQL> @ctxjsub 200 '04/17/2001 10:00' 'MM/DD/YYYY HH24:MI' 12

ジョブの情報が、次のように表示されます。

Created path for job id.
DBMS_JOB id = 7381
Cleanup job updated. Job ID = 7381

PL/SQL procedure successfully completed.

実行パラメータを変更するためのクリーン・アップ・ジョブ送信スクリプトは、何度でも実行できます。スクリプトを起動するたびに、クリーン・アップ・ジョブのジョブIDに関連付けられているジョブ情報が更新されます。このジョブIDは、プリファレンス・ストアで管理され、ジョブ情報が更新されます。このため、複数のジョブが送信されることがありません。

STARTにstart_timeを指定することもできます。この場合、time_formatパラメータは無視されますが、NOWのようななんらかの値を渡す必要はあります。現在時刻から<interval_hours>の時間間隔でジョブが実行されます。

SQL> @ctxjsub 168 START NOW 24

これにより、インストール時と同じ設定で、ジョブが送信されます。

クリーン・アップ・ジョブをすぐに実行する場合は、ctxjget.sqlをコールして、ジョブIDを取得します。ジョブIDを取得したら、製品スキーマに入っている次のコマンドを発行して、そのジョブを実行できます。

SQL> exec dbms_job.run(7381);

この例では、ctxjget.sqlをコールして返されたジョブIDは7381です。この方法でジョブを実行すると、この手動起動のinterval_hours時間後に、次のジョブが自動的に起動します。このジョブを元のスケジュールで実行するには、ctxjsub.sqlを使用して目的のstart_timeを再送信します。

B.5 実行時間とキャッシュの統計

すべてのOracle Portalページは、実行時間とキャッシュの情報が表示される特殊なモードで実行できます。このデバッグ情報をすべてのページに表示する場合は、appConfig.xmlファイルでParallel Page EngineのshowPageDebugパラメータにtrueを設定します。

関連項目:

第5.6.9項「PortalのParallel Page Engineの構成」

選択したいくつかのページとポートレットに関するデバッグ情報を表示する場合は、_debug URLパラメータによってログ・レベルを制御することができます。たとえば、次のOracle Portalページの実行時間の統計を参照するには、次のようにします。

http://abc.com/servlet/page?_pageid=21

これに手動で?_debug=3を挿入します。

次のようになります。

http://abc.com/servlet/page?_pageid=21?_debug=3

_debugの有効な値は、0、1、2、3、4および5です。

1より大きい値を使用すると、リクエストの間にlogmodeの値が増え、すべてのリクエストのログ・メッセージが、ページ・レスポンスへエコーされるようトリガーされることがあります。

注意:

0より大きい値を指定すると、_debug=1がバック・エンドのリクエストで伝播されます。

表B-2は、_debugの結果の値を表しています。

表B-2 実行時間とキャッシュの_debug値の統計

値

実行時間とキャッシュの統計

プロバイダへのフラグの転送 (値1として)

最小値まで増えるlogmode

ページ・レスポンスへのログ・メッセージの書込み

0

はい

-

-

-

1

はい

はい

-

-

2

はい

はい

デバッグ

はい

3

はい

はい

リクエスト

はい

4

はい

はい

コンテンツ

はい

5

はい

はい

解析中

はい

urlDebugModeおよびurlDebugUsersは付加的なパラメータで、これを使用してURLでの_debugの使用を制限できます。詳細は、第5.6.9項「PortalのParallel Page Engineの構成」を参照してください。

ポータル・ページをデバッグ・モードで実行すると、次の統計を表示できます。

- ポートレット統計

- ページ統計

- その他のサマリー統計

図B-1は、_debug=0モードで実行されているページを表しています。

図B-1 デバッグ・モードで実行されているポータル・ページ

B.5.1 ポートレット統計

図B-1は、ポートレットに関連する様々な統計をポートレットごとに示しています。各ポートレットは、固有の内部参照識別番号を持ちます。この番号は「ポートレットの情報」サマリーで使用されます。図B-1の左上端のポートレットでは、この番号が6256になっています。

ポートレットごとに次の統計が表示されます。

B.5.1.1 ポートレットの実行時間情報

- ポートレット表示時間: (ミリ秒)(ミリ秒間待機)
ポートレットの取得に要する時間とリクエストがキューに入っている時間(ミリ秒)が表示されます。

- 表示時間ステータス
この統計は非推奨で、今では使用されていません。

- XSLTの実行時間: (ミリ秒)
XSLスタイル・シートの取得に必要な時間(ミリ秒)が表示されます(XMLポートレットの場合)。

B.5.1.2 ポートレットのキャッシュ情報

- ポートレット・キャッシュ・ステータス: Web Cache(値)、ファイル・システム・キャッシュ(値)
Oracle Web CacheおよびPortalキャッシュのキャッシュ・ステータスです。

Oracle Web Cacheの有効な値は、次のとおりです。

- 「MISS」または「NEW [M]」は、Oracle Web Cacheにキャッシュ・ミスが発生していることを示します。ポートレットによって新しいコンテンツが生成されています。

- 「MISS」または「STALE [G]」は、Oracle Web Cache内の古いコンテンツが原因でキャッシュ・ミスが発生していることを示します。

- 「HIT [H]」は、Oracle Web Cacheがヒットしたことを示します。

ファイル・システム・キャッシュの有効な値は、次のとおりです。

- 「HIT_PING」は、妥当性チェック・ベースのポートレットのキャッシュ・ヒットを示します。

- 「HIT_EXPIRES」は、有効期限ベースのポートレットのキャッシュ・ヒットを示します。

- 「MISS_STALE」は、キャッシュにあるコンテンツが古いためにキャッシュ・ミスが発生していることを示します。これは、有効期限ベースおよび妥当性チェック・ベースのポートレットに適用されます。

- 「MISS_NEW」は、キャッシュ・ミスが発生していることを示します。ポートレットによって新しいコンテンツが生成されています。これは、有効期限ベースおよび妥当性チェック・ベースのポートレットに適用されます。

ポートレットがファイル・システム・キャッシュを使用する場合は、前述の情報が表示されます。そうでない場合は、NULLになります。

Oracle Web Cacheがヒットした場合は、コンテンツがOracle Web Cacheから直接提供されるため、ファイル・システム・キャッシュに関する詳細は表示されません。また、ポートレットがOracle Web Cacheを使用しない場合、Web Cache情報は出力されません。

- キャッシュから: Web Cache: キャッシュ有効期限(秒)、キャッシュ経過時間(秒)、ファイル・システム・キャッシュ(値)
ポートレットが使用するキャッシュのタイプに基づいて、Oracle Web Cacheとファイル・システム・キャッシュの情報がここに出力されます。

関連項目:

Oracle Fusion Middleware Oracle Web Cache管理者ガイド

「キャッシュ有効期限」には、Oracle Web Cacheのポートレット・コンテンツの有効期間(秒)が表示されます。

キャッシュ経過時間には、ポートレット・コンテンツがOracle Web Cacheにキャッシュされている時間(秒)が表示されます。

「File System Cache」には、ファイル・システム・キャッシュから取得された情報が表示されます。つまり、キャッシュ・キーとキャッシュ有効期限が表示されます。キャッシュがヒットした場合は、キャッシュ・レベルと、「HIT_PING」または「HIT_EXPIRES」のキャッシュ・ステータスが表示されます。

キャッシュがヒットしたときは、妥当性チェック・ベースのポートレットの場合はキャッシュ・キー、キャッシュ・レベルおよび「HIT_PING」のキャッシュ・ステータス値が表示され、有効期限ベースのポートレットの場合はキャッシュ有効期限、キャッシュ・レベルおよび「HIT_EXPIRES」のキャッシュ・ステータス値が表示されます。

妥当性チェック・ベースおよび有効期限ベースのポートレットの場合、新しいポートレット・コンテンツが生成されたためにキャッシュ・ミスが発生したときは、「なし」が出力されます。ポートレットには、新しいキャッシュ・キー、キャッシュ有効期限およびキャッシュ・レベルを取得するように通知されます(「キャッシュ・ステータス」: 「MISS_NEW」)。

妥当性チェック・ベースのポートレットの場合、キャッシュ内のコンテンツが失効したためにキャッシュ・ミスが発生したときは、キャッシュに現在入っているキャッシュ・キーとキャッシュ・レベルの値が表示されます。この場合、ポートレットに対して、更新済のキャッシュ・キーとキャッシュ・レベルを取得するように通知されます(「キャッシュ・ステータス」: 「MISS_STALE」)。

有効期限ベースのポートレットの場合、キャッシュ内のコンテンツが失効したためにキャッシュ・ミスが発生したときは、「キャッシュ有効期限」フィールドが「INVALID」になり、キャッシュ・レベルが表示されます。この場合、ポートレットに対して、更新済のキャッシュ有効期限とキャッシュ・レベルを取得するように通知されます(「キャッシュ・ステータス」: 「MISS_STALE」)。

- ポートレットから: (キャッシュ・キー)(キャッシュ・レベル)
ポートレットから: (キャッシュ・キー)(キャッシュ・レベル)

ファイル・システムのキャッシュ・キー、キャッシュ有効期限およびキャッシュ・レベルについて、ポートレットから取得された情報です。キャッシュ・ミスが発生し、更新済または新規の値を取得するようにポートレットに通知があると表示されます(「キャッシュ・ステータス」: 「MISS_NEW」または「MISS_STALE」)。Oracle Web Cacheに関連する情報は、このセクションに表示されません。

妥当性チェック・ベースのポートレットの場合、キャッシュがヒットしてpingが正常に終了したとき(キャッシュ内のコンテンツが引き続き有効な場合)、ポートレットは新しいキャッシュ・キーとキャッシュ・レベルを返しません。つまり、キャッシュは引き続き有効であることを示します。この場合、Ping成功と表示されます(「キャッシュ・ステータス」: 「HIT_PING」)。

有効期限ベースのポートレットの場合、キャッシュがヒットしてコンテンツが失効していないときは、ポートレットに対してコンテンツの要求は通知されません。この場合、「Not contacted」が表示されます(「キャッシュ・ステータス」: 「HIT_EXPIRES」)。

次に、様々なキャッシュ・シナリオとその出力例をいくつか示します。ここでは、ページおよびポートレット関連の出力例はあげません。

注意:

このリリースでは、ページ・ポートレットは、コンテナ・ページ定義とは別のポートレットとしてリクエストされます。そのため、デバッグ出力ではページ・ポートレットごとに、ポートレットとページのキャッシュ情報が表示されます。

例B-1 キャッシュ情報のデバッグ出力1

ポートレット・キャッシュ: ファイル・システム・キャッシュ、キャッシュ・タイプ: 妥当性チェック・ベース、ステータス: MISS, STALE

Caching information for portlet:
Portlet Cache status: File System Cache:- MISS,STALE
From Cache: File System Cache:- Cache Key: 42, Cache Level: USER
From Portlet: Cache Key: 44, Cache Level: USER

例B-2 キャッシュ情報のデバッグ出力2

ポートレット・キャッシュ: ファイル・システム・キャッシュ、キャッシュ・タイプ: 有効期限ベース、ステータス: MISS, NEW

Caching information for portlet:
Portlet Cache status:File System Cache:-  MISS,NEW
From Cache: File System Cache:-None
From Portlet: Cache Expires: 1, Cache Level: USER

例B-3 キャッシュ情報のデバッグ出力3

ポートレット・キャッシュ: ファイル・システム・キャッシュ、Web Cache、キャッシュ・タイプ: 妥当性チェック・ベースおよび無効化ベース、ステータス: MISS, NEW(ファイル・システム・キャッシュおよびWeb Cache内)

Caching information for portlet:
Portlet Cache status: Web Cache:- MISS,NEW [M], File System Cache:- MISS,NEW
From Cache: Web Cache:- Cache Expires: 86400 secs, Age in Cache: 0 secs , File System Cache:- None
From Portlet: Cache Key: 9.0.2.2.1502:04:18:09:19:56, Cache Level: SYSTEM

例B-4 キャッシュ情報のデバッグ出力4

ポートレット・キャッシュ: Web Cache、キャッシュ・タイプ: 無効化ベース、ステータス: HIT (Web Cache内)

Caching information for portlet:
Portlet Cache status: Web Cache:- HIT [H]
From Cache: Web Cache:- Cache Expires: 86400 secs, Age in Cache: 58 secs
From Portlet: -

B.5.2 ページ統計

図B-1に示したページ上のポートレットと同様に、すべてのページには一意の内部参照識別番号があります。

ページの場合は、次の統計が表示されます。

- 経過時間: (ミリ秒)
Parallel Page Engine (PPE)で計算されたページを生成するために必要な時間の合計です。ネットワーク・オーバーヘッドによって、ブラウザで実際に生成される時間は、これより長くなる可能性があります。

経過時間は、ページ・メタ待機時間とストリーム時間で構成されます。ページ・メタ待機時間は、HTTP接続でコンテンツを待機した時間です。ストリーム時間は、コンテンツの要素をストリーム化および収集した時間です。ストリーム時間は、次の要素で構成されます。

- ページ・メタ時間

- ポートレットの完了を待機した時間

- コンテンツをストリーム化してブラウザに書き込んだ時間

経過時間は、ページを収集(リクエストを受信してから最後のバイトをブラウザに書き込むまで)するためにかかった時間(ミリ秒)です。

- ページ・メタ時間: (ミリ秒)(ミリ秒待機)
ページ・メタデータの取得にかかった時間が表示されます。待機時間(ミリ秒)は、リクエストがキューに入っていた時間です。

- ページ・メタ・キャッシュ・ステータス: (Web Cacheの値)、(キャッシュ有効期限: ミリ秒)、(キャッシュ経過時間: ミリ秒)、(ファイル・システム・キャッシュの値)
Oracle Web CacheとPortalキャッシュのキャッシュ・ステータスを表します。Oracle Web Cacheの有効な値は、「MISS, or NEW」および「HIT」です。Portalキャッシュの有効な値は、「HIT, or PING」および「MISS, or STALE」です。Webキャッシュ有効期限と「キャッシュ経過時間」の値は、ミリ秒単位です。

- ログイン・メタ時間: (ミリ秒)(ミリ秒間待機)

ログイン・メタ・データの取得にかかった時間(ミリ秒)が表示されます。待機時間は、リクエスト・キュー内にリクエストが入っていた時間(ミリ秒)が表示されます。

- ログイン・メタ・キャッシュ・ステータス

前述のページ・メタ・キャッシュ・ステータスと同様に、Web CacheとPortalキャッシュのログイン・メタ・データのキャッシュ・ステータスを表します。

B.5.3 その他のサマリー統計

- Stream info: (ミリ秒)
ページをストリーム化してブラウザに書き込んだ時間(ミリ秒)を表します。

- processing: (ミリ秒)
ストリーム化にかかった時間(ミリ秒)。

- write: (ミリ秒)
write行は、複数回繰り返されることがあります。write行は、ストリームに対して各物理バッファが書き込んだことを表します。各バッファが書き込むたびに、1 write行が記録されます。

- flush: (ミリ秒)
flushログは、書込みストリームがフラッシュされたことを示します。これは、ネットワーク・ラウンドトリップの数を追跡するために記録されます。

B.6 cfgiaswスクリプトを使用したモバイルの構成

Oracle PortalまたはOracleAS Wirelessのポータル・サービスURLに対するポータルの参照を変更する場合は、スクリプトcfgiasw.plを使用して参照を手動で更新する必要があります。このスクリプト・ファイルは次の場所にあります。

ORACLE_HOME\assistants\opca

パラメータを指定せずにスクリプトを実行すると、次のような使用方法が画面に表示されます。

使用方法:

perl cfgiasw.pl -s portal_schema
-w ias wireless url
-h portal home page url
-c connect_string

表B-3 Oracle Application Server Wireless構成パラメータ

パラメータ

説明

-s

Oracle Portalデータ・オブジェクトのOracle Databaseスキーマ。

デフォルトはPORTAL。

-w

Oracle Portalに対するモバイル・リクエスト用のOracle Application Server WirelessゲートウェイのURL。このパラメータは必須です(デフォルトはなし)。このパラメータの値は、二重引用符で囲む必要があります。

-h

Oracle Portalホーム・ページのURL。これは、Oracle Portal中間層の文字セットを特定するためにポータル内で使用されます。この情報は、Oracle Application Server Wirelessサービスを作成するときに必要です。このパラメータは必須ではありません(デフォルトはなし)。このパラメータの値は、二重引用符で囲む必要があります。

-c

データベースに対する接続文字列(デフォルトはなし)。

注意:

- Oracle Portalのインストールの一部として入手できるPerlバージョンを使用してください。パス変数は次のように設定します。
Windowsの場合:

PATH ORACLE_HOME\perl\bin\

SolarisまたはLinuxの場合:

PATH ORACLE_HOME/perl/bin

- cfgiaswスクリプトの実行時、パスワードを入力するよう求められます。スクリプトの実行を続けるには、ポータル・スキーマのパスワードを指定します。

ホストされていないPortalでは、OracleAS WirelessのPortalサービスのURL参照を、「グローバル設定」ページの「モバイル」タブで設定できます。ただし、Oracle Portalホーム・ページのURLは例外で、これはcfgiaswスクリプトでしか設定できません。

このスクリプトは、Oracle Portalで、OracleAS WirelessのPortalサービスのURLおよびOracle Portalホーム・ページのURLの両方に対する参照を設定する場合に使用します。これは、ホストされた環境でURL参照の設定に使用でき、すべてのサブスクライバに影響を与えます。この情報はサブスクライバごとに個別に構成されないためです。例:

perl cfgiasw.pl -s portal -c portal_db -w "http://<iaswhost>:<port>/ptg/rm?PAoid=$wireless_service_id"

この例では、モバイル・デバイスが、Oracle Application Server Wireless サーバーの仲介なしでOracle Portalに対してリクエストを直接作成すると、Oracle Portalによってクライアントがここで指定されたURLにリダイレクトされます。このURLは、Oracle Application Server WirelessサーバーのOracle PortalのサービスのURLで、次の書式になります。

http://<host>:<port>/ptg/rm?PAoid=<service_id>

この設定が空白の場合は、Oracle Portalに対して直接作成されたモバイル・クライアントのリクエストは、リクエストがサポートされていないことを示すHTTPステータスを受け取ります。

Oracle Portalで他のモバイル設定を構成する場合は、第5.7項「Oracle Portalでのモバイル・サポートの構成」を参照してください。

B.7 cfgxodnc.plスクリプトを使用したキャッシュ・キーのモバイル・デバイス・コンポーネントの変更

Oracle Portalで使用されるキャッシュ・キーは、多数のコンポーネントによって構成されています。これらのコンポーネントの1つはURLに、別のコンポーネントはOracleAS WirelessヘッダーであるX-Oracle-Device.Classに基づいています。これらのコンポーネントにより、使用するモバイル・デバイスのクラスに基づいてポートレット・コンテンツがキャッシュされます。デバイスのクラスには、pcbrowser、pdabrowser、microbrowserなどがあります。

デバイスのクラスではなく、特定のデバイス名に基づいてポートレット・コンテンツをキャッシュできます。これを行うには、キャッシュ・キーのデバイス・コンポーネントのX-Oracle-Device.ClassヘッダーをX-Oracle-Device.Nameヘッダーに置き換える必要があります。

Oracle Portalが、X-Oracle-Device.Nameヘッダーの値に基づいてキャッシュされたポートレット・コンテンツと正常に動作するには、次の作業が必要です。

- Oracle Portalがこのヘッダーを使用できるようにします。実行手順は、第B.7.1項「portal_dads.confファイルへのPlsqlCGIEnvironmentListパラメータの追加」を参照してください。

- キャッシュを無効にするか、Oracle PortalがX-Oracle-Device.Nameヘッダーに基づいてコンテンツをキャッシュできるように構成します。Oracle PortalがX-Oracle-Device.Nameヘッダーに基づいてポートレット・コンテンツをキャッシュできるように構成するには、次の作業を実行します。

- 第B.7.2項「cfgxodnc.plスクリプトの実行」

- 第B.7.3項「PPE構成ファイルへのuseDeviceNameCacheKeysパラメータの追加」

- 第B.7.4項「キャッシュされたデータの消去」

関連項目:

ポータル・コンテンツのキャッシュを無効にする手順は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

B.7.1 portal_dads.confファイルへのPlsqlCGIEnvironmentListパラメータの追加

Oracle PortalがX-Oracle-Device.Nameヘッダーを使用できるようにするには、新しいパラメータPlsqlCGIEnvironmentListをOracle Fusion Middlewareインスタンスのportal_dads.confファイルに追加する必要があります。portal_dads.confファイルを編集するには、次の手順を実行します。

1. 次のディレクトリにあるportal_dads.confファイルを開きます。

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

2. 次のエントリをファイルに追加します。

PlsqlCGIEnvironmentList HTTP_X_ORACLE_DEVICE_NAME

3. portal_dads.confファイルを保存します。

注意:

portal_dads.confファイルは、手動で編集することもできますが、Application Server Controlを使用することをお薦めします。これを行うには、Fusion Middleware Controlを使用して、第A.2項「DAD構成ファイル(portal_dads.conf)」に説明されている手順に従ってください。

手動でportal_dads.confファイルを編集する場合は、必要なmod_rewriteとmod_weblogicのディレクティブを、httpd.confとmod_weblogic.confのファイルにそれぞれ追加する必要があります。

4. 次のコマンドを実行してOracle HTTP Serverを再起動します。

INSTANNCE_HOME\bin\opmnctl restartproc type=OHS

モバイル・デバイスを使用してOracle Portalにアクセスすると、コンテンツは使用しているモバイル・デバイスに基づいてレンダリングされます。また、キャッシュの容量も増えます。

B.7.2 cfgxodnc.plスクリプトの実行

Oracle PortalがX-Oracle-Device.Nameヘッダーを使用できるようにするには、cfgxodnc.plスクリプトをonモードで実行します。このスクリプトは次の場所にあります。

Oracle_HOME\assistants\opca

使用方法:

perl cfgxodnc.pl -s portal_schema
-c portal_connect_string
-on|-off

このスクリプトを実行するには、すべてのパラメータを指定する必要があります。

表B-4 cfgxodncスクリプトのパラメータ

パラメータ

説明

-s

Oracle Portalデータ・オブジェクトのOracle Databaseスキーマ。

デフォルトはPORTAL。

-c

データベースに対する接続文字列(デフォルトはなし)。

-on/-off

キャッシュ・キーでX-Oracle-Device.Nameの使用を有効または無効にするオプション。

注意:

Oracle Fusion Middlewareのインストールの一部として入手できるPerlバージョンを使用してください。パス変数は次のように設定します。

Windowsの場合:

PATH ORACLE_INSTANCE\perl\bin\

SolarisまたはLinuxの場合:

PATH ORACLE_INSTANCE/perl/bin

注意:

cfgxodnc.plスクリプトの実行時、パスワードの入力を求められます。スクリプトの実行を続けるには、ポータル・スキーマのパスワードを指定します。

cfgxodnc.plスクリプトを使用してX-Oracle-Device.Nameヘッダーを有効にする例を次に示します。

perl cfgxodnc.pl -s PORTAL -c portal_database -on

X-Oracle-Device.Nameヘッダーをキャッシュ・キーのデバイス・コンポーネントで使用すると、キャッシュ・サイズは増加します。使用するヘッダーをX-Oracle-Device.Classに戻すと、キャッシュ・サイズは減少します。

キャッシュ・キーのデバイス・コンポーネントで使用するヘッダーをX-Oracle-Device.Classに戻すには、cfgxodnc.plスクリプトをoffモードで実行します。

B.7.3 PPE構成ファイルへのuseDeviceNameCacheKeysパラメータの追加

キャッシュ・キーの作成時にデバイス・クラスのかわりにデバイス名を使用するには、次のように、appConfig.xmlファイルを編集してuseDeviceNameCacheKeysを設定します。

1. 次のディレクトリにあるappConfig.xmlファイルを開きます。

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

2. 次のエントリをファイルに追加します。

useDeviceNameCacheKeys

3. appConf.xmlファイルを保存します。

4. Oracle HTTP ServerとWLS_PORTALを再起動します。
Oracle HTTP ServerとWLS_PORTALのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。

B.7.4 キャッシュされたデータの消去

デバイス名に基づいて新しいキャッシュ・キーを作成するには、Oracle Web CacheとOracle Portalファイル・システム・キャッシュの両方で、キャッシュされた全データを消去する必要があります。Oracle Web Cacheでキャッシュされたデータの消去については、第6.7.3項「WLSTを使用したPortalのWeb Cache設定の構成」を参照してください。ファイル・システム・キャッシュでキャッシュされたデータの消去については、第5.6.8項「ポータル・キャッシュの消去」を参照してください。

B.8 カテゴリおよびパースペクティブ・スクリプトの使用

すべての新しいカテゴリ・ページまたはパースペクティブ・ページがエラーなしで作成され、すべての既存のカテゴリ・ページまたはパースペクティブ・ページに、関連付けられたアイテムおよびページが予想どおりに表示されるように、カテゴリおよびパースペクティブ・スクリプトを実行する必要があります。

必要なスクリプトは、次のとおりです。

ORACLE_HOME\portal\admin\plsql\wws\pstdefin.sql
ORACLE_HOME\portal\admin\plsql\wws\pstpgshw.sql
ORACLE_HOME\portal\admin\plsql\wws\pstundef.sql
ORACLE_HOME\portal\admin\plsql\wws\pstpgcre.sql
ORACLE_HOME\portal\admin\plsql\wws\pstprcpg.sql

これらのスクリプトを実行するには、次の手順を実行します。

1. 現在のカテゴリまたはパースペクティブのテンプレートを削除します。

2. ポータル・スキーマ・ユーザーとしてSQL*Plusを使用して、Oracle Portalに接続します。

3. pstdefin.sqlファイルを次の情報を使用して構成します。

- ページ・グループ情報。単一のページ・グループ、複数のページ・グループ、またはすべてのページ・グループのページを再作成できます。

- ページ情報。カテゴリ・ページまたはパースペクティブ・ページのみ、あるいはその両方を再作成できます。

これらの設定の説明は、pstdefin.sqlファイルにあります。必要に応じて、スクリプトpstpgshw.sqlを使用して情報をOracle Portalから取得し、pstdefin.sqlファイルを構成します。

4. スクリプトpstpgcre.sqlを実行して変更内容を適用します。例:

SQL> @pstpgcre.sql

ページ・グループにテンプレートが存在する場合に、新しいページを作成すると、そのテンプレートに基づいて新しいカテゴリ・ページまたはパースペクティブ・ページが作成されます。スクリプトの実行前にテンプレートを削除した場合、またはテンプレートが存在しない場合、ページ・グループに新しいテンプレートが作成され、そのテンプレートに基づいて新しいページが作成されます。

B.9 PDK-Javaのプリファレンス・ストア移行/アップグレード・ユーティリティの使用

プリファレンス・ストアとは、Oracle Portalの使用時、ユーザー・プリファレンスのデータ、ポートレットおよびプロバイダの設定、ポートレットのデータなどの情報を格納するメカニズムです。現在、PDK-JavaにはDBPreferenceStoreとFilePreferenceStoreの2つのPreferenceStoreが実装されています。DBPreferenceStoreにはJDBC対応のリレーショナル・データベースを使用するデータが保存され、FilePreferenceStoreにはファイル・システムを使用するデータが保存されます。

このユーティリティを使用すると、異なるプリファレンス・ストア間で既存のデータを移行したり(たとえば、FilePreferenceStoreからDBPreferenceStoreへ)、以前のリリースのPDK-JavaおよびOracle Portalをアップグレードすることによって、既存のポートレットで生成されたポートレット・プリファレンス・データを管理できます。このツールでのアップグレードによって、ロケール固有のポートレット・プリファレンスの既存データで、最新のPDKおよびOracle Portalリリースに対応したネーミング形式を使用できるようになります。

すでにOracleAS PDKをインストールしている場合は、プリファレンス・ストア移行/アップグレード・ユーティリティを使用してプリファレンス・ストアに保存されている情報を管理できます。このユーティリティはpdkjava.jarファイルにあります。

プリファレンス・ストア移行/アップグレード・ユーティリティの完全な構文を次に示します。

java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar;
$ORACLE_HOME/portal/jlib/ptlshare.jar
oracle.portal.provider.v2.preference.MigrationTool

注意:

filetodbモードの移行時は、前述のコマンドのクラスパスにはpdkjava.jarおよびptlshare.jarファイルのほかに、$ORACLE_HOME/jdbc/lib/ojdbc6.jarも含める必要があります。

プリファレンス・ストア移行/アップグレード・ユーティリティは、次のいずれかのモードで実行できます。このコマンドの実行時に-modeで選択します。

- アップグレード・モード

- 移行モード

注意:

このユーティリティの実行後、最新のプリファレンス・ストア情報が使用されるように、WLS_PORTALとOracle HTTP Serverを再起動します。

アップグレード・モード

使用されるネーミング形式がOracle Portalの現在のバージョンおよび指定されているlocalePersonalizationLevelの設定と対応するようにプリファレンス・ストア内の既存のロケール固有プリファレンスを変更して既存のデータをアップグレードするには、アップグレード・モード(fileまたはdb)を使用します。

表B-5に、このユーティリティのアップグレード・モードを示します。

表B-5 ユーティリティのアップグレード・モード

モード

説明

file

FilePreferenceStore内のデータをアップグレードする場合に使用します。

db

DBPreferenceStore内のデータをアップグレードする場合に使用します。

アップグレード・モード(fileまたはdb)は、次のようなシナリオで使用します。

- OracleAS PDK 9.0.4.0.0以前のリリースからアップグレードする場合で、localePersonalizationLevelとしてデフォルトのlanguageの設定を使用して既存のポートレットを使用する場合(以前のリリースではデフォルト設定はlocale)。

- Oracle Portal 9.0.2.0.0以前のリリースからアップグレードする場合で、localePersonalizationLevelの設定がlocaleである既存のポートレットを使用する場合(Oracle Portalでは現在、一部のロケール名が変更されているため、既存のデータには再マッピングが必要なものもあります)。

- 既存のポートレットのlocalePersonalizationLevelの設定をlocaleからlanguageに変更する場合。またはその反対に変更する場合。

アップグレード・モード(fileまたはdb)を使用する場合、アップグレード先のlocalePersonalizationLevelを指定する(languageまたはlocale)には-remapオプションを使用する必要があります。また、-countriesオプションを使用して、ISO国コードに優先順位を付けたリストを指定できます。このリストは、複数の国のプリファレンスを再マップして競合が発生した場合のプリファレンスの優先順位を示します。たとえば、コマンドで-remap language -countries GB,USと指定すると、プリファレンス・ストアでアメリカ英語のプリファレンスとイギリス英語のプリファレンス(en_USとen_GB)が検出された場合、イギリス英語のプリファレンスが英語全体のプリファレンス(en)として再マッピングされます。

注意:

このユーティリティをdbモードで実行する場合、pref1Userプロパティおよびpref1passwordプロパティには、data-sources.xmlファイルのJDBC接続定義に指定されている値を使用してください。

移行モード

ソースのプリファレンス・ストアからターゲットのプリファレンス・ストアにデータをコピーするには、移行モード(filetodb、filetofile、dbtofile、または dbtodb)を使用します。このモードでユーティリティを実行すると、すべてのポートレット定義のプリファレンス・ストアが更新されます。

表B-6に、このユーティリティの移行モードを示します。

表B-6 ユーティリティの移行モード

モード

説明

filetodb

データをFilePreferenceStoreからDBPreferenceStoreにコピーする場合に使用します。

filetofile

別の場所にあるFilePreferenceStore間でデータをコピーする場合に使用します。

dbtofile

データをDBPreferenceStoreからFilePreferenceStoreにコピーする場合に使用します。

dbtodb

別のデータベース表のDBPreferenceStore間でデータをコピーする場合に使用します。

移行モード(filetodb、filetofile、dbtofile、またはdbtodb)を使用するとき、-remapおよび-countriesオプションを使用して、ロケール固有のプリファレンスがデータの移行中に適切に再マップされてアップグレードされるよう指定できます。

このユーティリティのその他のオプションは、アップグレードまたは移行プロセスにおいて、プリファレンス・ストアのプロパティを指定するために使用します。これらのオプションは、provider.xmlに指定した、プリファレンス・ストア用に記述したタグと対応する必要があります。プリファレンス・ストアに設定できるプロパティの詳細は、次の場所にある『PDK-Java XML Provider Definition Tag Reference』を参照してください。

http://www.oracle.com/technology/products/webcenter/files/pdk_downloads/xml_tag_reference_v2.html

接頭辞が-pref1のプロパティは、ソース・プリファレンス・ストアのプロパティです。アップグレード・モード(fileまたはdb)では、このストアが唯一のプリファレンス・ストアです。たとえば、-pref1UseHashing true -pref1RootDirectory j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sampleと指定すると、ソースFilePreferenceStoreのuseHashingプロパティとrootDirectoryプロパティが設定されます。

注意:

Portal Development Kitをインストールした場合、ソース・プリファレンス・ストアの場所は次のとおりです。

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\jpdk\dir_name\war\WEB-INF\providers

基本の移行モードのいずれかの場合、接頭辞が-pref2のプロパティは、ターゲット・プリファレンス・ストアのプロパティを指定します。たとえば、-pref2User portlet_prefs -pref2Password portlet_prefs -pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysidを指定すると、ターゲットのDBPreferenceStoreにデータベース接続の詳細が設定されます。

次にUNIXでのユーティリティの使用例を示します。

java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar;
$ORACLE_HOME/portal/jlib/ptlshare.jar
oracle.portal.provider.v2.preference.MigrationTool -mode file -remap language
-countries GB,US -pref1UseHashing true
-pref1RootDirectory $DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/jpdk/dir/war/WEB-INF/providers

java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar;
$ORACLE_HOME/portal/jlib/ptlshare.jar; $ORACLE_HOME/jdbc/lib/ojdbc6.jar
oracle.portal.provider.v2.preference.MigrationTool -mode filetodb -remap locale
-countries AR,MX -pref1UseHashing true
-pref1RootDirectory $DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/jpdk/dir/war/WEB-INF/providers
-pref2User portlet_prefs -pref2Password portlet_prefs
-pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid

B.10 スキーマ検証ユーティリティの使用

スキーマ検証ユーティリティ(SVU)は、ポータル・スキーマ内のデータの不整合をクリーンアップおよびレポートするために使用します。SVUでは、ページ・グループ・オブジェクトおよびDBプロバイダ・オブジェクトが検証されます。

SVUの使用上の利点を次にいくつか示します。

- これにより、ソースとターゲットのPortalインスタンス間のデータ不整合を原因とするOracle Portalインポートの失敗が防止されます。

- Portalのバージョンをアップデートするためにパッチを適用する場合に、Oracle Portalパッチの失敗を防止します。

スキーマ検証ユーティリティは、次のようなシナリオで実行します。

- Oracle Portalのエクスポートおよびインポート処理時。

- ユーザー・インタフェースの使用時に、ORA-1403、ORA-1422、ORA-4088などのエラーが表示された場合。

検証の実行方法およびSVUスクリプトsvu_rept.sqlのダウンロード方法の詳細は、Oracle Metalink(http://metalink.oracle.com)にログインし、スキーマ検証ユーティリティに関する記事を参照してください。この記事のドキュメントIDは286619.1です。

スキーマ検証ユーティリティには、次の2種類の実行方法があります。

- Oracle Portalのエクスポートおよびインポートでのスキーマ検証ユーティリティの使用

- スキーマ検証ユーティリティのスタンドアロンでの使用

B.10.1 Oracle Portalのエクスポートおよびインポートでのスキーマ検証ユーティリティの使用

Oracle Portalのエクスポートとインポートでは、SVUはREPORTモードで自動的に実行されます。デフォルトでは、エクスポートとインポート時に、次の段階でバックグラウンドで実行されます。

1. エクスポート前 - ソース・インスタンスに存在するデータの不整合をクリーンアップします。

2. インポート前 - ターゲット・インスタンスに存在するデータの不整合で、インポート処理に影響を与える可能性のあるものをクリーンアップします。

3. インポート後 - インポート処理によって生じた可能性のあるデータの不整合をクリーンアップします。
SVUで不整合が報告されると、エクスポート処理やインポート処理は失敗し、ステータスはABORTになります。エクスポート処理またはインポート処理が中断されると、エラー・メッセージが表示され、不整合の詳細と「クリーンアップ・モード」リンクが示されます。このリンクをクリックするとSVUがCLEANUPモードで起動され、エクスポート処理またはインポート処理を完了できるようになります。

B.10.2 スキーマ検証ユーティリティのスタンドアロンでの使用

データ不整合がレポートまたは検出された場合、SVUをスタンドアロン・モードで実行できます。このユーティリティをスタンドアロン・モードで実行するには、スクリプトsvu_rept.sqlをOracle Portalスキーマ所有者(PORTAL)として実行します。

SQL> @svu_rept.sql

このスクリプトを実行するモードとタイプの指定が求められます。

モード:

- REPORT - データの不整合をレポートします。

- CLEANUP - データの不整合をクリーンアップします。

タイプ:

- ALL - ページ・グループ・オブジェクトとDBプロバイダ・オブジェクトの両方を検証します。

- PAGEGROUP - ページ・グループ・オブジェクトのみを検証します。

- DBPROV - DBプロバイダ・オブジェクトのみを検証します。

モードとタイプを入力したら、ログ・ファイルを保存するパスの指定が求められます。ここではc:\temp\svu.logのようにパスを入力します。SVUをまずREPORTモードで実行してから、CLEANUPモードで実行します。

重要

- SVUをCLEANUPモードで実行する前に、必ずデータベースの有効なバックアップを作成してください。

- SVUをCLEANUPモードで実行した後にREPORTモードを実行すると、不整合はレポートされません。不整合がレポートされた場合は、オラクル社カスタマ・サポート・センターに連絡してください。

C JavaServer PagesとOracle Portalとの統合

Oracle Portalには、様々な種類のWebページを作成する機能があります。この機能をJavaServer Pages (JSP)で補足することができます。

この付録では、承認されたJSPのみへのアクセスを許可し、JSPからポートレット・コンテンツへの認可されていないアクセスを防ぐことにより、Oracle Portalを保護する方法を説明します。また、ログインを必要とする保護された外部JSPにアクセスを許可するために必要な手順も説明します。

この付録の内容:

- JavaServer Pages構成ファイルの使用

- 外部通信のためのJAZNファイルの設定

C.1 JavaServer Pages構成ファイルの使用

ほとんどすべてのJSPは、タグ・ライブラリを使用してOracle Portalのポートレット・コンテンツをリクエストできるので、承認されたJSPのみがアクセス可能であることが保証されるようなセキュアな方法が必要です。これは、次の2つのメカニズムで制御できます。

- JSP内の<portal:usePortal>タグ

- 外部JSP構成ファイル

構成ファイルによって、Oracle Portalインスタンスとインスタンス内のページ・グループが識別され、外部JSPのそれらへアクセスが許可されます。

構成ファイル固有のコーディング要件については、第C.1.1項「JavaServer Pages構成ファイルの内容」を参照してください。

完成した構成ファイルは、Oracle Portalに識別される必要があります。手順の説明は、第C.1.3項「JavaServer Pages構成ファイルの場所」を参照してください。

この項の内容:

- JavaServer Pages構成ファイルの内容

- JavaServer Pages構成ファイルの例

- JavaServer Pages構成ファイルの場所

- 外部JavaServer Pagesのログイン

C.1.1 JavaServer Pages構成ファイルの内容

必要なタグは次のとおりです。

- <jps>

- <portal>

- <database>

- <url>

- <Cookie>

- <pageGroups>

- <pageGroup>

C.1.1.1 <jps>タグ

<jps>タグは、外部JSPがアクセスできるOracle Portalインスタンスのリストを提供するためのコンテナ・タグです。

開始タグ

<jps version="1.0">

現行のOracle Portalリリース用にバージョン番号を1.0に設定する必要があります。

終了タグ

</jps>

C.1.1.2 <portal>タグ

<portal>タグで、個々のOracle Portalインスタンスを記述します。

開始タグ

<portal name="MyPortal" default="true">

終了タグ

</portal>

表C-1 <portal>タグの属性

タグの属性" width="100%">

属性

値

name

Oracle Portalインスタンスに付ける記述名。名前は、構成ファイル内で一意である必要があります。

デフォルト

usePortalタグでポータル名を指定しない場合に、このポータルがデフォルトのインスタンスかどうかを示すtrueまたはfalseフラグ。値を指定しない場合は、falseに設定されます。

デフォルトのポータルは、構成ファイルごとに1つのみです。

C.1.1.3 <database>タグ

<database>タグで、指定されたOracle Portalインスタンスについてのデータベース接続情報を提供します。例:

<database data-source="jdbc/MyPortal"/>

data-source属性値はデータ・ソースの名前であり、J2EE_HOME/configディレクトリ内のdata-sources.xmlファイルに指定されている必要があります。

次に、data-source定義の例を示します。

<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="MyPortal"
location="jdbc/MyPortal"
xa-location="jdbc/xa/MyPortal"
ejb-location="jdbc/MyPortal"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="portal_app"
password="portal_app"
url="jdbc:oracle:thin:@xyz.oracle.com:1521:orcl"
inactivity-timeout="30"
/>

usernameおよびpassword属性は、Oracle Portalアプリケーション・スキーマのユーザー名とパスワードに設定する必要があります。

C.1.1.4 <url>タグ

<url>タグで、Oracle Portalインスタンスへの接続情報を提供します。例:

<url protocol="http" host="defg.oracle.com" port="7500" path="portal/pls/portal"/>

表C-2 <url>タグの属性

タグの属性" width="100%">

属性

値

protocol

Oracle Portalインスタンスへの接続に使用されるプロトコルの名前。現在、HTTPおよびHTTPSプロトコルのみがサポートされています。protocol属性を指定しない場合のデフォルトはhttpです。

host

Oracle Portalの中間層のコンピュータ名。

ポート

ポート番号。portを指定しない場合のデフォルトは80です。

path

今回のリリースでは、pathを/portal/pls/<PORTAL-DAD-NAME>に設定する必要があります。

C.1.1.5 <cookie>タグ

<cookie>タグで、Oracle PortalのCookieを記述します。例:

<cookie name="portal" maxAge="-1" path="/" domain=".oracle.com"/>

表C-3 <cookie>タグの属性

タグの属性" width="100%">

属性

値

name

Cookieの名前。これは、Oracle Portalインスタンスcookie名と同じにする必要があります。nameは、cookieタグの必須属性です。

maxAge

Cookieの最長保存期間。秒単位で指定します。ブラウザがシャットダウンされるまでCookieの保存を希望する場合は、-1を指定します。maxAgeは、cookieタグにとって必須の属性です。

path

ブラウザがこのCookieを返すサーバーのパス。pathは、cookieタグにとって必須の属性です。

domain

この属性は、SSOポートレットのCookie構成に変更が行われた場合にのみ指定する必要があります。SSOのドキュメントを参照してください。

C.1.1.6 <pageGroups>タグ

<pageGroups>タグで、pageGroupタグのコンテナを形成します。このタグには属性がありません。

開始タグ

<pageGroups>

終了タグ

</pageGroups>

C.1.1.7 <pageGroup>タグ

<pageGroup>タグで、それぞれのページ・グループのプロパティを記述します。例:

<pageGroup name="JPSDemo" key="welcome" default="true"/>

表C-4 <pageGroup>タグの属性

タグの属性" width="100%">

属性

値

name

ページ・グループ名。この名前は、ページ・グループがOracle Portal内で作成されたときに付けられた名前にする必要があります。

key

ページ・グループのキー。この値は、Oracle Portal内でページ・グループに割り当てられたアクセス・キーの値と一致している必要があります。(ここで識別されるページ・グループは、JSPアクセスに対応できる必要があります。)

デフォルト

このページ・グループがこのOracle Portalインスタンス内のデフォルトのページ・グループかどうかを示すフラグ。trueまたはfalseに設定されます。ページ・グループ名が指定されない場合、デフォルトのページ・グループはusePortalタグで使用されているものになります。このpageGroupタグのdefault属性に値が指定されない場合は、falseに設定されます。

デフォルトのページ・グループは、ポータル・インスタンスごとに1つのみです。

C.1.2 JavaServer Pages構成ファイルの例

次に、JSP構成ファイルの例を示します。

例C-1 JavaServer Pages構成ファイルの例

<jps version="1.0">
<portal name="MyPortal" default="true">
<database data-source="jdbc/MyPortal"/>
<url host="xyz.oracle.com" port="7500" path="/portal/pls/portal"/>
<cookie name="portal" maxAge="-1" path="/" />
<pageGroups>
<pageGroup name="JPSDemo"  key="welcome" default="true"/>
<pageGroup name="JPSDemo2" key="welcome" default="false"/>
</pageGroups>
</portal>
<portal name="AnotherPortal">
<database data-source="jdbc/AnotherPortal"/>
<url protocol="http" host="abc.oracle.com" port="8888"
path="/portal/pls/portal90"/>
<cookie name="portal90" maxAge="-1" path="/" />
<pageGroups>
<pageGroup name="JPSDemo"  key="welcome"/>
<pageGroup name="JPSDemo1"  key="welcome1"/>
<pageGroup name="JPSDemo2"  key="welcome2"/>
<pageGroup name="JPSDemo3"  key="welcome3"/>
<pageGroup name="JPSDemo4"  key="welcome4"/>
</pageGroups>
</portal>
</jps>

C.1.3 JavaServer Pages構成ファイルの場所

JavaServer Pages構成ファイルは任意の名前とすることができ、ファイル・システムのどの場所にも置くことができます。

この場所は、web.xmlファイルのコンテキスト・パラメータを使用して指定します。このファイルはDOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portal\dir_name\war\WEB-INFディレクトリにあります。

web.xmlファイル内のコンテキスト・パラメータは、次のとおりです。

<context-param>
<param-name>oracle.webdb.service.ConfigLoader</param-name>
<param-value>/WEB-INF/wwjps.xml</param-value>
<description>This parameter specifies the location of the JPS
configuration file</description>
</context-param>

C.1.4 外部JavaServer Pagesのログイン

外部JSPは、そのログイン要件によって次のように分類されます。

- ログインが不要な、またはOracle Portalのログイン・リンクを通じてユーザーがログインするパブリックJSP

- ログインが必要な保護されたJSP

保護された外部JSPには追加の設定要件があります。そのような要件については、次の項で説明します。

C.2 外部通信のためのJAZNファイルの設定

次の手順は、保護された外部JSPに対してのみ必要です。つまり、ログインが必要な外部JSPに対する手順です。

外部JSP内でポータルへのログインが必要な場合は、次のタグ構文を使用する必要があります。

<portal:usePortal id="AnyPortal" pagegroup="AnyPageGroup" login="true" />

このJSPを実行すると、まだログインしていない場合は、OracleAS Single Sign-Onへリダイレクトされます。これを正常に機能させるために、次の項を参照してください。

- mod_ossoの設定(まだ設定されていない場合)

- JAZNのLDAPによる設定

C.2.1 mod_ossoの設定

デフォルトでは、使用中のOracle HTTP Serverは、OracleAS Single Sign-Onに登録されています。変更が発生したために再登録が必要な場合は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。

C.2.2 JAZNのLDAPによる設定

JAZNとは、Java Authentication and Authorization Service (JAAS)プロバイダの内部名です。JAASは、アプリケーションがユーザーのアクセス制御を認証および適用できるようにするJavaパッケージです。Oracle Portal内でのJAZNの使用は、外部JSPの認証に制限されています。

JAZNがLDAPと連携していることを確認します。(JAZNに提供されるデモを使用することができます。)

次の追加手順を実行します。

- DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\124k5v\META-INF\orion-application.xmlで、次の行を追加します。

<jazn provider="LDAP" location="ldap://<OIDHOST>:389" default-realm="oracle">
<jazn-web-app auth-method="SSO" />
</jazn>

ポート番号389は、LDAPサーバーのデフォルトのポートです。ただし、他のどのようなポートでも割り当てることができます。<host>および<port>の情報を入手するためには、Oracle Internet Directory管理者に連絡してください。

関連項目:

詳細は、次を参照してください。

- 第C.2項「外部通信のためのJAZNファイルの設定」

- Oracle Fusion Middleware Oracle Containers for Java EEサービス・ガイド

D wwv_context APIの使用

wwv_contextパッケージには、Oracle Portalで使用するOracle Text索引を作成および管理するプロシージャが含まれています。この付録では、このパッケージの内容について次の項で説明します。

- プロシージャ

- ファンクション

- 定数

- 例外

注意:

Oracle Text索引と、そのOracle Portalでの使用方法の詳細は、第10章「Oracle Portalの検索機能の構成」を参照してください。

D.1 プロシージャ

wwv_contextパッケージには、次のプロシージャが含まれています。

add_attribute_section

commit_sync

create_index

create_missing_indexes

create_prefs

createindex

drop_all_indexes

drop_index

drop_invalid_indexes

drop_prefs

dropindex

optimize

set_parallel_degree

set_sync_memory

set_use_doc_index

set_use_url_index

同期

touch_index(p_indexes wwsbr_array)

touch_index

update_index_prefs

D.1.1 add_attribute_section

procedure add_attribute_section(
p_attributeid     in number,
p_attributesiteid in number
)

アイテムおよびページ索引で使用されるセクション・グループに、新しいセクションを追加します。このセクション・グループは1つの属性と対応します。これによって、索引のメタデータのみが変更され、索引データそのものは変更されません。新しいセクションは検索できますが、索引そのものは変更されません。

索引は、存在する場合のみ変更されます。つまり索引が存在しない場合は、このプロシージャでは何も処理しません。

パラメータ

p_attributeId - 追加する属性セクションのID

p_attributeSiteId - 追加する属性セクションのサイトID

D.1.2 commit_sync

procedure commit_sync(
p_index       in varchar2
p_commit_sync in boolean
)

(Oracle Database 10g以降)ポータルへのデータのコミット直後にOracle Text索引を同期化するか、またはwwv_context.syncを使用して手動で同期化する必要があるかを指定します(「sync」を参照)。

索引を手動で同期化する場合、またはデータベースがOracle Database 10gより前の場合は、wwv_context.syncを直接実行するか、一定の間隔でwwv_context.syncをコールするジョブを作成できます。wwv_context.syncは、commit_syncがtrueに設定されている索引を無視します。第10.3.5.4項「索引の同期化のスケジューリング」も参照してください。

注意:

commit_syncプロパティは、バージョンがOracle Database 10g以降のデータベースでのみ使用可能です。それより前のバージョンでは、Oracle Text索引を手動で同期化するか、同期化スケジュール(特定の日付と時刻)に従って同期化します。第10.3.5.1項「Oracle Text索引の同期化」も参照してください。

パラメータ

p_index - 索引の名前。索引名の定数のいずれか1つを指定します。

p_commit_sync - コミット直後に索引を同期化するかを指定します。ポータルでデータがコミットされるたびに自動的に索引を同期化する場合は、commit_syncをtrueに設定します。wwv_context.syncを使用して索引を手動で同期化する場合は、commit_syncをfalseに設定します。

例外

INVALID_INDEX - 索引の名前が認識されませんでした。

D.1.3 create_index

procedure create_index(
p_index in varchar2
)

特定のOracle Text索引を作成します。第10.3.3項「Oracle Text索引」も参照してください。

このプロシージャはトラブルシューティングの目的でのみ使用します。特に問題が発生していない状況では、create_missing_indexesを使用して、不足しているすべての索引を作成するか、またはcreateindexを使用して無効な索引を削除し、プリファレンスおよび不足している索引を再作成します。

パラメータ

p_index - 作成する索引の名前。索引名の定数のいずれか1つを指定します。

例外

INVALID_INDEX - 索引の名前が認識されませんでした。

D.1.4 create_missing_indexes

procedure create_missing_indexes(
p_indexes out wwsbr_array
)

不足しているOracle Text索引をすべて作成します。ビューctx_user_indexesに基づいて存在している索引は、存在しているとみなされます。

このプロシージャは、既存の索引が有効かどうかは調べません。有効でない部分がある索引を削除するには、プロシージャdrop_invalid_indexesを使用します。

このプロシージャは、空の索引を作成します。索引に値を移入するには、プロシージャtouch_index(p_indexes wwsbr_array)を使用して、対象の索引について索引の再作成が必要であることをマークし、その後に索引と同期化する必要があります。

Oracle Textのデータストアおよびフィルタのプリファレンスはすでに存在しているため、このプロシージャでは作成しません。プリファレンスがない場合に作成するには、プロシージャcreate_prefsを使用します。

パラメータ

p_indexes - 作成した索引のリストが含まれている配列を返します。

D.1.5 create_prefs

procedure create_prefs

データストアおよびフィルタのプリファレンスを作成します。両方ともOracle Text索引を作成するときに使用します。第10.3.3.2項「Oracle Text索引の設定」も参照してください。

このプロシージャは、レクサー・プリファレンスは作成しません。レクサー・プリファレンスを作成するには、ORACLE_HOME\portal\admin\plsql\wwsディレクトリに格納されているsbrimtlx.sqlスクリプトを使用します。第10.3.3.5項「多言語機能(マルチレクサー)」も参照してください。

Oracle Textの設定は、索引が作成される前に作成する必要があります。その後の設定に対する変更は、Oracle Text索引を削除して再作成しないと、有効になりません。

D.1.6 createindex

procedure createindex(
p_language in  varchar2 default wwnls_api.nls_default_language,
p_message  out varchar2
)

Oracle Portalで使用するOracle Text索引を作成します。詳細は、第10.3.3項「Oracle Text索引」を参照してください。

この高水準プロシージャは、次のタスクを実行します。

- 既存のプリファレンス・オブジェクトをすべて削除します。

- 無効な索引をすべて削除します。

- Oracle Textのプリファレンスを再作成します。

- 不足している索引を作成します(最初は空)。

- 新しい索引の場合は、索引付けが可能なすべてのOracle Portalコンテンツに、索引の再作成が必要であることをマークします。

- 索引を同期化します(最初に値を移入し、次に索引を最適化します)。

このプロシージャは、次のものと同じように機能します。

wwv_context.drop_prefs;
wwv_context.drop_invalid_indexes;
wwv_context.create_prefs;
wwv_context.create_missing_indexes(l_indexes);
wwv_context.touch_index(l_indexes);
wwv_context.sync;
wwv_context.optimize;

D.1.7 drop_all_indexes

procedure drop_all_indexes

Oracle Portalで使用するOracle Text索引をすべて削除します。

このプロシージャは、Oracle Textのプリファレンスは削除しません。これを削除するには、プロシージャdrop_prefsを使用します。

D.1.8 drop_index

procedure drop_index(
p_index in varchar2
)

特定のOracle Text索引を削除します。このプロシージャでは、索引が存在するかどうかは検証しません。

パラメータ

p_index - 削除する索引の名前。索引名の定数のいずれか1つを指定します。

例外

INVALID_INDEX - 索引の名前が認識されませんでした。

D.1.9 drop_invalid_indexes

procedure drop_invalid_indexes

無効なOracle Text索引のみを削除します。有効なOracle Text索引は削除されません。

次のビューで次のstatus列がすべてVALIDに設定されている場合は、索引が有効であるとみなされます。

- user_indexes.status

- user_indexes.domidx_status

- user_indexes.domidx_optstatus

- ctx_user_indexes.idx_status

いずれかのstatus列が有効でない場合、または索引が両方のビューのエントリを持っていない場合は、その索引は無効とみなされて削除されます。詳細は、第10.3.8項「Oracle Text索引のステータスの表示」を参照してください。

D.1.10 drop_prefs

procedure drop_prefs

Oracle Textのデータストアおよびフィルタのプリファレンスを削除します。第10.3.3.2項「Oracle Text索引の設定」も参照してください。

データストアおよびフィルタのプリファレンスは、Oracle Text索引を作成するときに使用します。このプロシージャは、スクリプトsbrimtlx.sqlを使用して作成されたレクサー・プリファレンスは削除しません。このスクリプトは、ORACLE_HOME\portal\admin\plsql\wwsディレクトリにあります。

D.1.11 dropindex

procedure dropindex(
p_language in varchar2 default wwnls_api.nls_default_language,
p_message  out varchar2
)

Oracle Portalで使用される既存のOracle Text索引をすべて削除します。第10.3.3項「Oracle Text索引」も参照してください。

このプロシージャは、次のものと同じように機能します。

wwv_context.drop_prefs;
wwv_context.drop_all_indexes;

D.1.12 optimize

procedure optimize(
p_optlevel in varchar2 default ctx_ddl.optlevel_full,
p_maxtime  in number   default null,
p_token    in varchar2 default null
)

Oracle Portalで使用する既存のOracle Text索引をすべて最適化します。それぞれの索引は、Oracle Textプロシージャctx_ddl.optimize_index()をコールすることによって最適化されます。

このプロシージャのパラメータは、Oracle Textプロシージャctx_ddl.optimize_indexで必要なパラメータと同じです。

パラメータ

p_optlevel - 最適化のレベル。FULL、FASTまたはTOKENのいずれかを指定します。

p_maxtime - Oracle Textが索引の最適化に費やす時間(分単位)。

p_token - 最適化するトークン(レベルTOKENで最適化を実行する場合)。

Oracle Technology Network (OTN)のサイト(http://www.oracle.com/technology/products/text/index.html)で、Oracle Textの参照ドキュメントも参照してください。

D.1.13 set_parallel_degree

procedure set_parallel_degree(
p_index           in varchar2,
p_parallel_degree in pls_integer
)

プロシージャwwv_context.syncを使用して索引を同期化するときに使用する並列度を設定します(「sync」を参照)。マルチプロセッサ・コンピュータでは、同期化操作を同時に実行できます。複数のプロセッサを使用して同期化を実行すれば、特に大量のデータに対して索引を作成する場合に処理速度が向上します。

デフォルトの設定は1です。これは並列度が指定されていないことを示します。1より大きい値を指定するとパラレル同期が有効になります。並列度に、データベース・サーバーで使用可能なプロセッサの合計数より大きい値を指定すると、同期中に実現される並列度が要求した値よりも小さくなる場合があります。

注意:

コミット直後に索引を同期化する(get_commit_syncがtrueを返す)場合、この設定は無効になります。詳細は、「commit_sync」も参照してください。

OTNのサイト(http://www.oracle.com/technology/products/text/index.html)で、Oracle Textの参照ドキュメントも参照してください。

パラメータ

p_index - 索引の名前。索引名の定数のいずれか1つを指定します。

p_parallel_degree - 指定された索引を同期化するときに使用する並列度。

例外

INVALID_SETTING - p_parallel_degreeの書式または値が認識されませんでした。

INVALID_INDEX - 索引の名前が認識されませんでした。

INTERNAL_EXCEPTION - 予期しない内部エラーが発生しました。

D.1.14 set_sync_memory

procedure set_sync_memory(
p_index  in varchar2,
p_memory in varchar2
)

プロシージャwwv_context.syncを使用して索引を同期化するときにOracle Textで使用する、実行時のメモリー量を指定します(「sync」を参照)。メモリー量は、バイト単位の値を入力するか、接尾辞にK、BまたはGを付加して、それぞれキロバイト、メガバイト、ギガバイトの値を表すこともできます。たとえば、値に10000と入力すると10000バイトを表し、10Kと入力すると10キロバイトを表します。

指定したメモリーがいっぱいになると、データはデータベースに書き込まれます。この状況が頻繁に発生すると、索引付けのパフォーマンスが低下し、Oracle Text索引はより断片化されます。索引の断片化は、ポータルでの検索の問合せ速度を低下させる可能性があります。メモリー量を小さく指定するとパフォーマンスに影響を与え、索引の断片化が増加しますが、実行時のメモリーが不足している場合などは有効です。

p_memoryをNullに設定すると、デフォルトの索引メモリーの設定が使用されます。このデフォルト値は、Oracle Textの変更可能なシステム・パラメータDEFAULT_INDEX_MEMORYを使用して設定できます。別の値を指定する場合は、Oracle Textのシステム・パラメータMAX_INDEX_MEMORYよりも小さい値を指定する必要があります。

詳細は、OTNのサイト(http://www.oracle.com/technology/products/text/index.html)で、Oracle Textの参照ドキュメントを参照してください。

注意:

コミット直後に索引を同期化する(get_commit_syncがtrueを返す)場合、この設定は無効になります。詳細は、「commit_sync」も参照してください。

パラメータ

p_index - 索引の名前。索引名の定数のいずれか1つを指定します。

p_memory - この索引の同期化に使用するメモリーの最大量。

例外

INVALID_SETTING - p_memoryの書式または範囲が認識されませんでした。

INVALID_INDEX - 索引の名前が認識されませんでした。

INTERNAL_EXCEPTION - 予期しない内部エラーが発生しました。

D.1.15 set_use_doc_index

procedure set_use_doc_index(
p_value in boolean
)

ドキュメント索引が必須であるかどうかを指定します。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」も参照してください。

セッション期間中、この情報に対するリクエストの繰返しを避けるため、この値はキャッシュされます。

パラメータ

p_value - trueまたはfalseのいずれかを指定します。trueに設定すると、ドキュメント索引が必須になります。

D.1.16 set_use_url_index

procedure set_use_url_index(
p_value in boolean
)

URL索引が必須であるかどうかを指定します。詳細は、第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」を参照してください。

セッション期間中、この情報に対するリクエストの繰返しを避けるため、この値はキャッシュされます。

パラメータ

p_value - trueまたはfalseのいずれかを指定します。trueに設定すると、URL索引が必須になります。

D.1.17 sync

procedure sync

Oracle Portalで使用するOracle Text索引をすべて同期化します。それぞれの索引は、Oracle Textプロシージャctx_ddl.sync_index()をコールすることによって同期化します。このプロシージャでは、前回の同期化の後で更新された行の索引をすべて再作成します。同期化が終了すると、新しく追加または更新したコンテンツを検索できるようになります。第10.3.5.1項「Oracle Text索引の同期化」も参照してください。

同期化する前に、保留状態のキューが、表wwsbr_url$の内容で更新されます。この表には、Oracle Portalに格納されているURL属性の値がすべて含まれています。URLの値が定数wwv_context_util.g_noindexの値と同じ場合は、このキューの行が削除されます。行には、元のURLがOracle Textによって索引付けされていなかったことを示すために、この値が設定されます。たとえば、https://またはjavascript:で始まるURLなどが該当します。

ctx_ddl.sync_indexの詳細は、OTNのサイト(http://www.oracle.com/technology/products/text/index.html)でOracle Textに関するドキュメントを参照してください。

D.1.18 touch_index(p_indexes wwsbr_array)

procedure touch_index(
p_indexes in wwsbr_array
)

1つ以上の索引のコンテンツにアクセスします。索引にアクセスすると、すべての索引コンテンツは同期化が必要とマークされます。詳細は、第10.3.5.6項「すべての索引のコンテンツの同期化」を参照してください。

索引のコンテンツがこの方法でマークされると、プロシージャsyncを使用して、マークされたコンテンツの索引を再作成します。

このプロシージャは、現行のサブスクライバのみでなく、複数の仮想プライベート・ポータルのサブスクライバ間で動作します。このプロシージャは、それぞれのサブスクライバに順に切り替えて、終了すると元のサブスクライバに戻ります。

パラメータ

p_indexes - アクセスする索引名が含まれている配列。索引名の定数を1つ以上指定します。

D.1.19 touch_index

procedure touch_index(
p_index in varchar2 default null
)

1つの索引またはすべての索引のコンテンツにアクセスします。このプロシージャは、指定された1つの索引にアクセスするのに便利です。また、このプロシージャは、NULL値を渡すことによってすべての索引にアクセスすることができます。第10.3.5.6項「すべての索引のコンテンツの同期化」も参照してください。

このプロシージャは前述のtouch_index(p_indexes wwsbr_array)をコールします。

パラメータ

p_index - アクセスする索引の名前。すべての索引にアクセスする場合はNULLを指定します。名前を指定する場合は、索引名の定数のいずれか1つを指定します。

詳細は、第D.1.18項「touch_index(p_indexes wwsbr_array)」を参照してください。

D.1.20 update_index_prefs

procedure update_index_prefs

現在のOracle Text索引データベース・プリファレンスを更新します。このプロシージャは、バージョンがOracle Database 10gより前のデータベースでのみ有効です。

索引の作成後にデータストア・プリファレンスを変更した場合、その変更内容は索引に自動で適用されません。このプロシージャを使用して、データストア・プリファレンスの変更をOracle Text索引に適用します。

索引が欠落している場合、それらの索引に操作は実行されません。

D.2 ファンクション

wwv_contextパッケージには、次のファンクションが含まれています。

checkindex

doc_index

get_commit_sync

get_parallel_degree

get_sync_memory

get_use_doc_index

get_use_url_index

valid_doc_index

valid_url_index

url_index

D.2.1 checkindex

function checkindex(
p_force in boolean default false
) return boolean

必須のOracle Text索引がすべて存在するかどうかをチェックします。ドキュメント索引とURL索引はオプションのため、これらの索引の存在と妥当性を検証するには、valid_doc_indexおよびvalid_url_indexをコールします。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」も参照してください。

セッション期間中、checkindexの戻り値はキャッシュされます。p_forceにtrueが渡されると、Oracle Text索引のステータスは、事前にキャッシュされている値とは関係なく常に再評価されます。

パラメータ

p_force - trueまたはfalseのいずれかを指定します。trueに設定すると、Oracle Text索引がチェックされます。

戻り値

すべての必須索引が存在し、かつ有効である場合、trueが返されます。

D.2.2 doc_index

function doc_index
return boolean

ドキュメント索引が必須であるかどうか(get_use_doc_indexを使用)、および使用可能かどうか(valid_doc_indexを使用)をチェックします。

戻り値

ドキュメント索引が必須で、かつ有効である場合、trueが返されます。

D.2.3 get_commit_sync

function get_commit_sync(
p_index in varchar2)
return boolean

索引を、ポータルへのデータのコミット直後に同期化するか、または手動で同期化するかを検証します。詳細は、「commit_sync」も参照してください。

注意:

commit_syncプロパティは、バージョンがOracle Database 10gより前のデータベースでは使用できません。以前のバージョンのデータベースでコールされた場合、このファンクションはfalseを返します。

パラメータ

p_index - 索引の名前。索引名の定数のいずれか1つを指定します。

戻り値

ポータルへのデータのコミット直後に同期化するよう索引が構成されている場合は、trueを返します。手動で同期化するように構成されている場合は、falseを返します。

D.2.4 get_parallel_degree

function get_parallel_degree(
p_index in varchar2)
return boolean

プロシージャwwv_context.syncを使用して索引を同期化するときに使用する並列度を取得します(「sync」を参照)。マルチプロセッサ・コンピュータでは、同期化操作を同時に実行できます。複数のプロセッサを使用して同期化を実行すれば、特に大量のデータに対して索引を作成する場合に処理速度が向上します。

デフォルトの設定は1です。これは並列度が指定されていないことを示します。1より大きい値を指定するとパラレル同期が有効になります。並列度に、データベース・サーバーで使用可能なプロセッサの合計数より大きい値を指定すると、同期中に実現される並列度が要求した値よりも小さくなる場合があります。

注意:

コミット直後に索引を同期化する(get_commit_syncがtrueを返す)場合、並列度の設定は無効になります。

OTNのサイト(http://www.oracle.com/technology/products/text/index.html)で、Oracle Textの参照ドキュメントも参照してください。

パラメータ

p_index - 索引の名前。索引名の定数のいずれか1つを指定します。

戻り値

指定された索引を同期化するときに使用する並列度を返します。

例外

INVALID_INDEX - 索引の名前が認識されませんでした。

INTERNAL_EXCEPTION - 予期しない内部エラーが発生しました。

D.2.5 get_sync_memory

function get_sync_memory(
p_index in varchar2)
return boolean

プロシージャwwv_context.syncを使用して索引を同期化するときにOracle Textで使用する、実行時のメモリー量を(バイト単位で)取得します(「sync」を参照)。

メモリーがいっぱいになると、データはデータベースに書き込まれます。この状況が頻繁に発生すると、索引付けのパフォーマンスが低下し、Oracle Text索引はより断片化されます。索引の断片化は、ポータルでの検索の問合せ速度を低下させる可能性があります。メモリー量が小さいとパフォーマンスに影響を与え、索引の断片化が増加しますが、実行時のメモリーが不足している場合などは有効です。

NULL値は、デフォルトの索引メモリーの設定が使用されていることを示します。このデフォルト値は、Oracle Textの変更可能なシステム・パラメータDEFAULT_INDEX_MEMORYを使用して設定できます。詳細は、OTNのサイト(http://www.oracle.com/technology/products/text/index.html)で、Oracle Textの参照ドキュメントを参照してください。

注意:

コミット直後に索引を同期化する(get_commit_syncがtrueを返す)場合、メモリーの設定は無効になります。

パラメータ

p_index - 索引の名前。索引名の定数のいずれか1つを指定します。

戻り値

指定された索引を同期化するときに使用するメモリー量を(バイト単位で)返します。

例外

INVALID_INDEX - 索引の名前が認識されませんでした。

INTERNAL_EXCEPTION - 予期しない内部エラーが発生しました。

D.2.6 get_use_doc_index

function get_use_doc_index
return boolean

ドキュメント索引が必須であるかどうかを判別します。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」も参照してください。

セッション期間中、この情報に対するリクエストの繰返しを避けるため、この値はキャッシュされます。

戻り値

ドキュメント索引が必須である場合、trueが返されます。

D.2.7 get_use_url_index

function get_use_url_index
return boolean

URL索引が必須であるかどうかを判別します。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」も参照してください。

セッション期間中、この情報に対するリクエストの繰返しを避けるため、この値はキャッシュされます。

戻り値

URL索引が必須である場合、trueが返されます。

D.2.8 valid_doc_index

function valid_doc_index
return boolean

ドキュメント索引が有効で、使用可能な状態にあるかどうかを判別します。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」も参照してください。ファンクションcheckindexがコールされていない場合は、コールされます。

セッション期間中、この情報に対するリクエストの繰返しを避けるため、この値はキャッシュされます。

戻り値

ドキュメント索引が存在し、かつ有効である場合、trueが返されます。

D.2.9 valid_url_index

function valid_url_index
return boolean

URL索引が有効で、使用可能な状態にあるかどうかを判別します。第10.3.7項「ドキュメント索引およびURL索引の作成の無効化」も参照してください。ファンクションcheckindexがコールされていない場合は、コールされます。

セッション期間中、この情報に対するリクエストの繰返しを避けるため、この値はキャッシュされます。

戻り値

URL索引が存在し、かつ有効である場合、trueが返されます。

D.2.10 url_index

function url_index
return boolean

URL索引が必須であり(get_use_url_indexを使用)、使用可能かどうか(valid_url_indexを使用)をチェックします。

戻り値

URL索引が必須で、かつ有効である場合、trueが返されます。

D.3 定数

wwv_contextパッケージには、次の定数が含まれています。

- 索引名の定数

- Oracle TextのAUTO_FILTER書式定数

- Oracle Textのジョブ定数

- 索引作成に適さないURLの定数

D.3.1 索引名の定数

次の定数を使用して、Oracle Portalで使用されるOracle Text索引を指定します。

- ページ索引 - wwv_context.PAGE_TEXT_INDEX

- ドキュメント索引 - wwv_context.DOC_TEXT_INDEX

- パースペクティブ索引 - wwv_context.PERSPECTIVE_TEXT_INDEX

- アイテム索引 - wwv_context.ITEM_TEXT_INDEX

- カテゴリ索引 - wwv_context.CATEGORY_TEXT_INDEX

- URL索引 - wwv_context.URL_TEXT_INDEX

PAGE_TEXT_INDEX

PAGE_TEXT_INDEX constant varchar2(30) := 'WWSBR_CORNER_CTX_INDX'

DOC_TEXT_INDEX

DOC_TEXT_INDEX constant varchar2(30) := 'WWSBR_DOC_CTX_INDX'

PERSPECTIVE_TEXT_INDEX

PERSPECTIVE_TEXT_INDEX constant varchar2(30) := 'WWSBR_PERSP_CTX_INDX'

ITEM_TEXT_INDEX

ITEM_TEXT_INDEX constant varchar2(30) := 'WWSBR_THING_CTX_INDX'

CATEGORY_TEXT_INDEX

CATEGORY_TEXT_INDEX constant varchar2(30) := 'WWSBR_TOPIC_CTX_INDX'

URL_TEXT_INDEX

URL_TEXT_INDEX constant varchar2(30) := 'WWSBR_URL_CTX_INDX'

D.3.2 Oracle TextのAUTO_FILTER書式定数

ドキュメント索引およびURL索引は、AUTO_FILTERを使用してドキュメントを索引作成に適したプレーン・テキスト形式に変換します。すべてのドキュメント・タイプに絞込みが必要なわけではありません。ドキュメント・タイプの中には、直接索引を作成できるものもあります。AUTO_FILTERでは、次の設定を使用して、絞込みの必要なドキュメントを特定します。

- BINARY_FORMAT - ドキュメントがプレーン・テキストやHTML以外の形式で、AUTO_FILTERでサポートされている形式(PDFなど)であることを示します。このようなドキュメントは、索引作成の可能なテキスト形式に変換されます(そのバイナリ形式がAUTO_FILTERでサポートされている場合)。

- TEXT_FORMAT - ドキュメントがプレーン・テキストまたはHTMLであることを示します。これが指定されると、ドキュメントの絞込みは行われませんが、文字セットが変換される場合があります。

- IGNORE - ドキュメントの索引を作成する必要がないことを示します(例 - イメージ・ファイルなど)。

注意:

AUTO_FILTERは、現在は非推奨になったINSO_FILTERを置き換えるものです。

BINARY_FORMAT

BINARY_FORMAT constant varchar2(10) := 'BINARY';

TEXT_FORMAT

TEXT_FORMAT   constant varchar2(10) := 'TEXT';

IGNORE

IGNORE        constant varchar2(10) := 'IGNORE';

D.3.3 Oracle Textのジョブ定数

Oracle Textのメンテナンス・ジョブの管理に次の定数が使用されます。

- SYNC_JOB_PREF - 同期化ジョブIDを保存するためのプリファレンス名。索引の同期化スクリプトtextjsub.sqlで使用します。第10.3.5.4項「索引の同期化のスケジューリング」も参照してください。

- OPTIMIZE_JOB_PREF - 最適化ジョブIDを保存するためのプリファレンス名。索引の最適化スクリプトoptjsub.sqlで使用します。第10.3.5.8項「索引の最適化のスケジューリング」も参照してください。

SYNC_JOB_PREF

SYNC_JOB_PREF constant varchar2(20) := 'text_sync_jobid';

OPTIMIZE_JOB_PREF

OPTIMIZE_JOB_PREF constant varchar2(20) := 'text_optimize_jobid';

D.3.4 索引作成に適さないURLの定数

行に索引を作成できないことを表すための絶対URL。URLの索引は、wwsbr_url.absolute_urlの列に作成されます。この列は、トリガーによって値が移入されます。

javascript:で始まるURLなど、索引作成には不適切なURLの場合には、この定数値が使用されます。第10.3.6.2項「サポートされていないURL」も参照してください。

G_NOINDEX

G_NOINDEX constant varchar2(15) := 'wwsbr_noindex'

D.4 例外

INVALID_INDEX

索引の名前が認識されませんでした。

INVALID_INDEX exception

INVALID_SETTING

APIの設定に無効な値が指定されました。

INVALID_SETTING exception

E Portalツールのプロバイダの構成

Portalツールには、WebクリッピングとOmniPortletの2つのWebプロバイダが含まれています。ページ設計者およびポートレット開発者は、これらを使用して宣言的にポートレットを構築できます。Webクリッピング・ポートレットを使用すると、コンテンツをポータル・ページのポートレットとして、リモートWebサイトから公開できます。OmniPortletを使用すると、Webサービス、XML、データベースなどの様々なデータ・ソースに含まれるデータを公開して、それらで定義されている表、グラフ、HTMLなどの様々なレイアウトに従って表示できます。

この付録の内容:

- Webクリッピングの構成

- OmniPortletの構成

E.1 Webクリッピングの構成

Webクリッピングは、ブラウザベースの宣言ツールで、任意のWebアプリケーションをOracle Portalに統合できます。これは、Webアプリケーションの既存のユーザー・インタフェースを利用することで、迅速な統合が可能なように設計されています。Webクリッピングは、Oracle PortalのコンポーネントであるJava Portal Developers Kitを使用するWebプロバイダとして実装されています。

Webクリッピングにより、集中化された1つのWebページで、複数のポートレットにWebコンテンツを収集できます。Webクリッピングを使用すれば、大規模な組織全体に分散しているWebサイトのコンテンツを統合できます。

Webクリッピングを使用する前に、次のようないくつかの管理タスクを実行する必要があります。

- Webクリッピング・リポジトリの構成

- Webクリッピング・プロバイダの登録(PDK専用)

- HTTPまたはHTTPSのプロキシ設定の構成

- キャッシュの構成

- 信頼できるサイトの証明書の追加
第7章「Oracle Portalの保護」の第7.1.12.1項では、信頼できる証明書ファイルを構成または拡張する方法について説明しています。Oracle Wallet Managerから生成された信頼できるサーバー証明書ファイルであるca-bundle.crtは、Oracle Portalに付属しています。このファイルには、HTTPSを使用してセキュアなサーバーに移動するために使用される、信頼できるサーバー証明書の初期リストが含まれています。しかし、これはWeb上に存在する安全と考えられるすべてのサーバー証明書の完全なリストではないため、信頼できる新たな参照サイトが加われば、そのサイトの信頼できるサーバー証明書が認識されるように、このファイルを構成または拡張する必要があります。

- Webクリッピング・プロバイダのOracle Advanced Securityの構成
第7章「Oracle Portalの保護」の第7.1.12.2項では、Oracle Advanced Security Option (ASO)を構成して、中間層にあるASO自体とWebクリッピング・リポジトリがあるデータベース間のチャネルを保護および暗号化する方法について説明しています。

E.1.1 Webクリッピング・リポジトリの構成

Webクリッピングの定義は、Oracle Databaseがホストとして処理するWebクリッピング・リポジトリに永続的に保存しておく必要があります。

ポータル管理者として、次のディレクトリにあるprovider.xmlファイル内のrepositoryInfoエントリを編集することにより、Webクリッピング・リポジトリを構成できます。

UNIXの場合:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/tr7qwp/war/WEB-INF/providers/webClipping

Windowsの場合:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\tr7qwp\war\WEB-INF\providers\webClipping

次の例のいずれかを使用して、リポジトリの構成を開始します。リポジトリはMDSに基づいて構成することも、データベースに基づいて構成することもできます。

例(MDSを使用):

<repositoryInfo class="oracle.portal.wcs.provider.info.MdsInformation">
<mdsConfigLocation>mds-config.xml</mdsConfigLocation>
</repositoryInfo>

例(データソースで定義されたOracle Databaseを使用):

<repositoryInfo class="oracle.portal.wcs.provider.info.JdbcDbInformation">
<jdbcConnetionName>pref/portletPrefs</jdbcConnectionName>
<useASO>false</useASO>
</repositoryInfo>

例(Oracle 10g Database以降を使用):

<repositoryInfo class="oracle.portal.wcs.provider.info.DatabaseInformation">
<useRAA>false</useRAA>
<databaseHost>mycompany.dbhost.com</databaseHost>
<databasePort>1521</databasePort>
<databaseSid>iasdb</databaseSid>
<databaseUsername>webclip_user</databaseUsername>
<databasePassword>AX3tR</databasePassword>
<useASO>false</useASO>
</repositoryInfo>

例(Infrastructureデータベース内のPORTALスキーマを使用):

<repositoryInfo class="oracle.portal.wcs.provider.info.DatabaseInformation">
<useRAA>true</useRAA>
<useASO>false</useASO>
</repositoryInfo>

各要素の意味と値を表E-3に示します。

表E-1 Webクリッピング・リポジトリの設定

フィールド

値

repositoryInfo

repositoryInfoタグ内のclass属性は、Webクリッピング定義を格納するためにどのタイプのリポジトリを使用するかを指定します。現在は、class属性には次の2つの値のみが有効です。

oracle.portal.wcs.provider.info.MdsInformation

Webクリッピング定義の格納にMDSが使用され、MDS構成がmds-config.xmlファイルにプッシュされるという意味です。

oracle.portal.wcs.provider.info.DatabaseInformation

Webクリッピング定義の格納にOracle 9i以降のデータベースが使用され、repositoryInfoタグの子としてデータベース接続の詳細が含まれるという意味です。

mdsConfigLocation

このrepositoryInfoの子タグは、repositoryInfoクラスがoracle.portal.wcs.provider.info.MdsInformationである場合にのみ役立ちます。これは、パス名が絶対であるか相対であるかに関係なく、MDS構成ファイル(mds-config.xml)の場所を指定します。

絶対パス名の定義は、システムに依存します。UNIXシステムでは、先頭が一重のフォワード・スラッシュ(/)の場合に絶対パス名となります。Microsoft Windowsシステムでは、先頭がドライブ文字で、その後に一重のバックスラッシュ(\)が続くか、または先頭が二重のバックスラッシュ(\\)の場合に絶対パス名となります。

相対パスを指定した場合、portalTools EARファイルを配置した場所に応じたベース・ディレクトリが基準になります。

デフォルト値はmds-config.xmlで、このコピーがWEB-INFに用意されています。

useASO

有効な値: true | false

Webクリッピングとデータベース間の通信チャネルを暗号化する場合にAdvanced Security Optionを使用するには、trueを指定します。これは、クリップされたコンテンツに大文字と小文字が区別されるデータが含まれる場合に、セキュリティを強化するために用意されています。

useRAA

許容される値: true | false

データベース接続パラメータにアクセスする場合にリポジトリ・アクセスAPIを使用するには、trueを指定します。この値にtrueを選択すると、Webクリッピング・プロバイダで、デフォルトのOracleAS InfrastructureデータベースをWebクリッピング・リポジトリとして使用するように設定した場合と同様の効果が得られます。

注意: このオプションを選択した場合、その他のrepositoryInfoタグを指定する必要はありません。

databaseHost

バージョン9i以降のOracleデータベースのホスト名を指定します。

databasePort

Oracleデータベース・リスナーのポート番号(通常は1521)を指定します。

databaseSid

Webクリッピング・リポジトリのホストに使用しているデータベースのOracle SIDを指定します。

databaseUsername

データベースへのログインに使用するユーザー名を入力します。

databasePassword

指定したデータベースのユーザー名に対するパスワードを入力します。例に示すように、先頭に感嘆符(!)が付いたプレーン・テキストのパスワードを入力すると、プロデューサを起動したときにWebクリッピング・プロバイダでプロバイダ内のパスワードが暗号化できるようになります。

E.1.2 Webクリッピング・プロバイダの登録(PDK専用)

OracleAS PDKの一部としてWebクリッピング・プロバイダをダウンロードしてインストールした場合にのみ、このタスクを実行します。

注意:

Oracle Fusion Middlewareのインストールの一部としてOracle Portalをインストールした場合、Webクリッピング・プロバイダは、ポートレット・リポジトリのポートレット・ビルダー・フォルダの下にデフォルトで登録されます。

Webクリッピング・プロバイダは構成後、Oracle Portalインスタンスにポートレット・プロバイダとして登録する必要があります。その後、ポートレットをポータル・ページに追加できます。

Webクリッピング・プロバイダを登録するには、次の手順を実行します。

1. Oracle Portalにログオンします。

2. Oracle Portalのホーム・ページにある「管理」タブに移動します。デフォルトでは、このページに「プロバイダ」ポートレットがあります。ここにない場合は、Portalの検索機能を使用して「プロバイダ」ポートレットを検索します。

3. 「プロバイダ」ポートレットの「ポートレット・プロバイダの登録」をクリックします。

4. 登録ウィザードの手順に従い、表E-2に示すとおりにWebクリッピング・プロバイダの登録設定を行います。

注意:

ポートレット・リポジトリの「ポートレット・ビルダー」フォルダの下にある生成済Webクリッピング・プロバイダと、このWebクリッピング・プロバイダを区別するには、このWebクリッピング・プロバイダに、たとえばWeb Clipping provider on host ABCのような区別しやすい名前を付ける必要があります。

表E-5には、指定する必要のある設定を示しています。

表E-2 Webクリッピング・プロバイダの登録設定

フィールド

値

名前

WebClipping_ABC

表示名

ホストABC上のWebクリッピング・プロバイダ

タイムアウト

200秒

タイムアウト・メッセージ

ホストABC上のWebクリッピング・プロバイダのタイムアウト

実装スタイル

Web

URL

http://<host>:<port>/portalTools/webClipping/providers/webClipping

ポートレットのコンテンツをキャッシュする場合は、Oracle Web Cacheインスタンスを指すようにWebキャッシュのURLホスト名とポート番号を指定します。例:

http://<cache_instance_name>:<cache_port>/portalTools/webClipping/providers/webClipping

ユーザーは、Webプロバイダ・アプリケーション内とシングル・サインオン認証内とで、同じ識別情報を保持します

このオプションを選択します。

ユーザー固有の情報をプロバイダに送信する場合、「ユーザー」を選択します

このオプションを選択します。

ログイン周期

ユーザー・セッションごとに1回

プロキシを必要とする

No(プロバイダ・アダプタとの接続にプロキシを必要としない場合)

5. 「終了」をクリックします。

これで、Webクリッピング・プロバイダを使用してポートレットをポータル・ページに追加できるようになりました。Webクリッピング・プロバイダは、デフォルトでポートレット・リポジトリの「ポートレット・ステージング領域」フォルダの下に登録されます。

E.1.3 HTTPまたはHTTPSのプロキシ設定の構成

HTTPまたはHTTPSのプロキシ設定は、Webクリッピング・スタジオがファイアウォールの外にあるWebサイトに接続できるように設定する必要があります。ポータル管理者は、HTTPまたはHTTPS構成に従って、手動でプロキシを設定できます。次のディレクトリにあるprovider.xmlファイルで適切なエントリを編集します。

UNIXの場合:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/tr7qwp/war/WEB-INF/providers/webClipping

Windowsの場合:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\tr7qwp\war\WEB-INF\providers\webClipping

次の例は、provider.xmlの関連部分を示しています。

<proxyInfo class="oracle.portal.provider.v2.ProxyInformation">
<httpProxyHost>proxy_hostname</httpProxyHost>
<httpProxyPort>proxy_portnum</httpProxyPort>
<dontProxyFor>list_of_proxies</dontProxyFor>
<proxyUser>proxy_username</proxyUser>
<proxyPassword>proxy_password</proxyPassword>
<proxyType>basic_or_digest</proxyType>
<proxyUseAuth>true_or_false</proxyUseAuth>
<proxyUseGlobal>true_or_false</proxyUseGlobal>
<proxyRealm>realm_name</proxyRealm>
</proxyInfo>

各要素の意味と値を表E-3に示します。

表E-3 Webクリッピング・プロバイダのプロキシ設定

フィールド

値

httpProxyHost

Webクリッピング・プロバイダからそのデータ・ソースにURL接続するためにプロキシ・サーバーが必要な場合に、そのプロキシ・サーバーのホスト名を入力します。

httpProxyPort

Webクリッピング・プロバイダからそのデータ・ソースにURL接続するためにプロキシ・サーバーが必要な場合に、そのプロキシ・サーバーのホスト名を入力します。httpProxyHostを指定し、ポートを指定しなかった場合、httpProxyPortはデフォルトのポート番号80に設定されます。

dontProxyFor

プロキシ・サーバーを迂回して直接接続できる任意のドメインまたはホストの名前を入力します。ドメイン名は、企業、組織または政府機関などの名前を含むURLの一部です。

*.oracle.com

ホストは、完全修飾されたホスト名でもIPアドレスでもかまいません。この要素を使用して、コンテンツを制限する一連のホスト名も指定できます。

proxyUseAuth

有効な値: true | false

プロキシ・サーバーが認証を要求する場合には「true」を入力します。認証パラメータは、次のタグで指定されます。

proxyType、proxyRealm、proxyUseGlobal、proxyUserおよびproxyPassword。

proxyType

有効な値: Basic | Digest

このプロバイダが使用するプロキシ・サーバーのタイプを選択します。注意: Basic認証またはDigest認証の詳細は、http://www.faqs.org/rfcs/rfc2617.htmlを参照してください。

proxyRealm

次のログイン情報に従って、ユーザーがアクセスするプロキシ・サーバーのレルムの名前を入力します。レルムの名前がわからない場合は、プロキシ・サーバーの管理者に問い合せてください。

proxyUseGlobal

有効な値: true | false

trueの場合、<proxyUser>と<proxyPassword>の値は、すべてのユーザーに使用されます。ユーザーには「ソース」タブおよび「パーソナライズ」画面で「プロキシ認証」セクションが表示されません。

falseの場合、ページ設計者はポートレットを定義するときに、「ソース」タブの「プロキシ認証」セクションからログインする必要があります。エンド・ユーザーは、「パーソナライズ」画面の「プロキシ認証」セクションからログインする必要があります。proxyUsernameとproxyPasswordが指定されている場合、それらはパブリック・ユーザーのためにのみ使用されます。

proxyUser

プロキシ・サーバーにログインするユーザー名を入力します。

proxyPassword

指定したユーザー名のパスワードを入力します。例に示すように、プレーン・テキストのパスワードの前に接頭辞「!」を付ける必要があります。プロデューサが起動すると、このパスワードはprovider.xmlで暗号化されて保護されます。

E.1.3.1 承認されていない外部Webサイトからのコンテンツのクリッピングの制限

承認されていない外部Webサイトからユーザーがコンテンツをクリッピングするのを制限するために、Webクリッピングではプロキシの例外リストを使用します。このメカニズムは、外部Webサイトへ到達するためにプロキシ・サーバーを利用している環境でのみ利用可能です。(通常、プロキシ・サーバーを迂回して、直接接続できる任意のドメインを指定するには、プロキシ例外リストを使用します。)

外部Webサイトをプロキシ例外リストに追加するには、次の手順を実行します。

1. 「プロバイダ・テスト・ページ」に移動し、次のURLを入力してWebクリッピングを行います。

http://servername:port/portalTools/webClipping/providers/webClipping

2. 「プロバイダの編集: webClipping」ページに移動します。

3. 「プロキシ設定」セクションの「プロキシを使用しないドメイン」フィールドに、制限の対象となるWebサイトを入力します。

4. 「OK」をクリックして設定を保存し、Webクリッピングのテスト・ページに戻ります。

ユーザーがリストにあるドメイン内のWebサイトをWebクリッピング・スタジオから参照しようとすると、HTTPタイムアウト・エラーが発生します。

E.1.4 キャッシュの構成

デフォルトでは、すべてのWebクリッピング・ポートレットに対して、有効化ベースのキャッシュがOracle Portalを介して使用されます。有効化ベースのキャッシュを使用すると、キャッシュされたアイテムがまだ有効であるかどうかを判断するために、Parallel Page Engine (PPE)がOracle Portalプロバイダに連絡します。

Oracle Web Cacheがインストールされている場合は、無効化ベースのキャッシュをOracle Web Cache経由で使用することを選択できます。それぞれのキャッシュのタイプは排他的であることに注意してください。つまり、どちらか一方のみを選択でき、両方は選択できません。

無効化ベースのキャッシュでは、アイテムの更新が必要であるという通知をキャッシュが受け取るまで、アイテムはキャッシュに残ります。たとえば、Webクリッピング・ポートレットに定期的に更新されるコンテンツが含まれていると、キャッシュは無効化されます。図E-1に示す無効化ベースのキャッシュは、PPEが関与するラウンド・トリップごとに同じネットワーク通信量を保ちながら、Webクリッピング・プロバイダが受け入れる必要があるリクエストの数を減らします。配置の状況に応じて、適切なキャッシュ方法を採用することができます。

図E-1 Oracle Web Cacheによる無効化ベース・キャッシュ

キャッシュの詳細は、第1.3項「Oracle Portalのキャッシュの理解」および第6.7項「Oracle Web CacheにキャッシュされたOracle Portalコンテンツの管理」を参照してください。

デフォルトでは、Webクリッピング・プロバイダにはポータル・キャッシュ(有効化ベースのキャッシュ)が使用されます。Oracle Web Cache(無効化ベースのキャッシュ)を使用するには、キャッシュの構成方法について第E.1.4.1項「キャッシュの構成」を参照してください。

Webクリッピング・コンテンツのキャッシュにOracle Web Cacheを使用する場合は、最終手順で、Portalナビゲータを使用し、プロバイダURLの接続文字列をOracle Web CacheのポートのあるURLを指定するように変更します。通常、Oracle Web Cacheのポートは、7778です。この値はFusion Middleware Controlの「ポート」ページで確認してください。例:

http://host:webcacheport/portalTools/webClipping/providers/webClipping

この構成では、Oracle PortalインスタンスとWebクリッピング・プロバイダ間のWebクリッピング・コンテンツがOracle Web Cacheによってキャッシュに格納されます。

E.1.4.1 キャッシュの構成

Oracle Web Cacheを使用してキャッシュを有効化にするには、次の手順を実行します。

1. 無効化のホストとポート番号の正確な値を確認するために、次のディレクトリにある webcache.xmlファイルを調べます。
UNIXの場合:

ORACLE_INSTANCE/config/WebCache/wc1

Windowsの場合:

ORACLE_INSTANCE\config\WebCache\wc1

2. 次のディレクトリにあるprovider.xmlファイルを編集します。
UNIXの場合:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/tr7qwp/war/WEB-INF/providers/webClipping

Windowsの場合:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\tr7qwp\war\WEB-INF\providers\webClipping

provider.xmlファイルで次のことを実行します。

1. useInvalidationCachingタグを検索し、Oracle Web Cacheの無効化ベースのキャッシュを有効にするためにその値をtrueに設定します。

2. cacheExpiresタグを検索し、その値を変更する場合はデフォルト値に設定します。この値は分単位です。

E.2 OmniPortletの構成

OmniPortletは、Oracle Portalのサブコンポーネントで、これを使用するとページ設計者および開発者は、様々なレイアウトを使用して様々なデータ・ソースからデータを簡単に公開できます。OmniPortletでは、Webサービス、スプレッドシート(カンマ区切り)およびXML、さらには既存のWebページのアプリケーション・データなど、ほとんどすべての種類のデータ・ソースをベースとすることができます。OmniPortletを使用すると、ページ設計者およびコンテンツ作成者は、次の操作を実行できます。

- 保護データへのアクセス

- グラフ、フォーム、レポートなど様々なレイアウトを使用したデータのフォーマット

- ページ・パラメータの受入れ

- パラメータの引渡し

- イベントの呼出し

- パーソナライズ可能な設定のページ閲覧者への公開

OmniPortletを使用する前に、次のようないくつかの管理タスクを実行する必要があります。

- 第E.2.1項「OmniPortletプロバイダの構成」

- 第E.2.2項「オプションのOmniPortlet構成の実行」

- 第E.2.3項「OmniPortletプロバイダの登録(PDK専用)」

- 第E.2.4項「DataDirect JDBCドライバを使用して他のリレーショナル・データベースにアクセスするOmniPortletプロバイダの構成」

E.2.1 OmniPortletプロバイダの構成

OmniPortletを使用する前に、Oracle Portalのインストール方法に応じて、いくつかの管理タスクの実行が必要がなることがあります。Oracle PortalをOracle Fusion Middlewareリリースの一部としてインストールした場合は、構成のほとんどは完了済です。

実行する必要のある管理タスクは、次のとおりです。

- 第E.2.1.1項「HTTPまたはHTTPSのプロキシ設定の構成」

- 第E.2.1.2項「保護データ・リポジトリの構成(PDK専用)」

- 第E.2.1.3項「キャッシュの構成(PDK専用)」

- 第E.2.1.4項「HTTPS URLにアクセスするためのOmniPortletの構成」

E.2.1.1 HTTPまたはHTTPSのプロキシ設定の構成

ファイアウォール外のデータ・ソースにURL接続を行うためにプロバイダにプロキシ・サーバーが必要な場合、HTTPまたはHTTPSプロキシを設定する必要があります。

注意:

HTTPまたはHTTPSプロキシの設定は、XML、CSV、Webサービス、Webページのデータ・ソースなどの、URLベースのデータ・ソースにのみ使用できます。

OmniPortletプロバイダにプロキシ設定を構成するには、次のディレクトリにあるOmniPortletのprovider.xmlファイルを編集して、Webクリッピング・プロバイダで行ったのと同じ手順を実行する必要があります。

UNIXの場合:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/1pwj8k/war/WEB-INF/providers/omniPortlet

Windowsの場合:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet

ファイルの編集後、新しい設定を有効にするためにOracle WebLogic Serverを再起動する必要はありません。ただし、Webページのデータ・ソースが正しく機能するためには、Webクリッピングのprovider.xmlファイルでproxyInfoタグを設定する必要があります。provider.xmlでWebクリッピングのプロキシ設定を構成する方法の詳細は、Webクリッピング・プロバイダに関する第E.1.3項「HTTPまたはHTTPSのプロキシ設定の構成」を参照してください。

次の例は、provider.xmlの関連部分を示しています。

<proxyInfo class="oracle.portal.provider.v2.ProxyInformation">
<httpProxyHost>proxy.mycompany.com</httpProxyHost>
<httpProxyPort>80</httpProxyPort>
<dontProxyFor>*.mycompany.com</dontProxyFor>
<proxyUseAuth>true</proxyUseAuth>
<proxyType>Basic</proxyType>
<proxyRealm>realm1</proxyRealm>
<proxyUseGlobal>false</proxyUseGlobal>
<proxyUser>scott</proxyUser>
<proxyPassword>!tiger</proxyPassword>
</proxyInfo>

各要素の意味と値を、表E-4に示します。

表E-4 OmniPortletプロバイダのプロキシ設定

フィールド

値

httpProxyHost

OmniPortletプロバイダからそのデータ・ソースにURL接続するためにプロキシ・サーバーが必要な場合に、そのプロキシ・サーバーのホスト名を入力します。

httpProxyPort

OmniPortletプロバイダからそのデータ・ソースにURL接続するために、プロキシ・サーバーのホスト名を入力します(プロキシ・サーバーが必要な場合)。httpProxyHostを指定し、ポートを指定しなかった場合、httpProxyPortはデフォルトのポート番号80に設定されます。

dontProxyFor

プロキシ・サーバーを迂回して直接接続できる任意のドメインまたはホストの名前を入力します。ドメイン名は、企業、組織または政府機関などの名前を含むURLの一部です。

*.oracle.com

ホストは、完全修飾されたホスト名でもIPアドレスでもかまいません。この要素を使用して、コンテンツを制限する一連のホスト名も指定できます。

proxyUseAuth

有効な値: true | false

プロキシ・サーバーが認証を要求する場合には「true」を入力します。認証パラメータは、次のタグで指定されます。

proxyType、proxyRealm、proxyUseGlobal、proxyUserおよびproxyPassword。

proxyType

有効な値: Basic | Digest

このプロバイダが使用するプロキシ・サーバーのタイプを選択します。注意: Basic認証またはDigest認証の詳細は、http://www.faqs.org/rfcs/rfc2617.htmlを参照してください。

proxyRealm

次のログイン情報に従って、ユーザーがアクセスするプロキシ・サーバーのレルムの名前を入力します。レルムの名前がわからない場合は、プロキシ・サーバーの管理者に問い合せてください。

proxyUseGlobal

有効な値: true | false

trueの場合、<proxyUser>と<proxyPassword>の値は、すべてのユーザーに使用されます。ユーザーには「ソース」タブおよび「パーソナライズ」画面で「プロキシ認証」セクションが表示されません。

falseの場合、ページ設計者はポートレットを定義するときに、「ソース」タブの「プロキシ認証」セクションからログインする必要があります。エンド・ユーザーは、「パーソナライズ」画面の「プロキシ認証」セクションからログインする必要があります。proxyUsernameとproxyPasswordが指定されている場合、それらはパブリック・ユーザーのためにのみ使用されます。

proxyUser

プロキシ・サーバーにログインするユーザー名を入力します。

proxyPassword

指定したユーザー名のパスワードを入力します。例に示すように、プレーン・テキストのパスワードの前に接頭辞「!」を付ける必要があります。プロデューサが起動すると、このパスワードはprovider.xmlで暗号化されて保護されます。

E.2.1.2 保護データ・リポジトリの構成(PDK専用)

OmniPortletでは、保護データへのアクセスに必要な資格証明をWebクリッピング・リポジトリに格納します。Webページのデータ・ソースを使用したり、保護データを使用して作業する場合(SQLデータベースやURLベースのデータ・ソースをHTTP Basic認証で使用する場合)は、リポジトリを構成する必要があります。すでにWebクリッピング・リポジトリを構成している場合は、同じリポジトリであるため保護データ・リポジトリを再度構成する必要はありません。

リポジトリを構成するには、OmniPortletの「プロバイダ・テスト・ページ」の「保護データ・リポジトリ」の隣りにある「編集」をクリックします。「プロバイダの編集」ページが表示されます。このページに、リポジトリの情報を入力します。詳細は、Webクリッピング・プロバイダに関する第E.1.1項「Webクリッピング・リポジトリの構成」を参照してください。

E.2.1.3 キャッシュの構成(PDK専用)

無効化ベースのキャッシュを使用してポートレットのコンテンツをキャッシュする場合、任意のOracle Web Cacheインスタンスをプロバイダのフロント・エンドとして構成する必要があります。

次の例に示すように、プロバイダを登録する際に、特定のOracle Web Cacheインスタンスを指定するURLホスト名およびポート番号を使用する必要があります。

http://<cache_instance_name>:<cache_port>/portalTools/omniPortlet/providers/omniPortlet

このタスクは、OmniPortletプロバイダを登録する際に実行する必要があります。OmniPortletプロバイダの登録の詳細は、第E.2.3項「OmniPortletプロバイダの登録(PDK専用)」を参照してください。

「デフォルトの編集」ページまたは「パーソナライズ」ページからOmniPortletの定義が変更された場合、プロバイダはキャッシュ内のポートレットのコンテンツの無効化と削除を要求するリクエストを生成します。無効化のリクエストは、Oracle Web Cacheインスタンスの無効化用ポートに送信されます。Oracle Web Cacheインスタンスの情報は、ORACLE_INSTANCE/config/WebCache/wc1ディレクトリのwebcache.xmlファイルに維持されます。Web Cacheの無効化の設定が変更された場合は、このファイルを更新する必要があります。webcache.xmlファイルのエントリの例を次に示します。

<?xml version="1.0"?>
<webcache>
<invalidation
host="<cache_instance_name>"
port="<cache_invalidation_port>"
authorization="<obfuscated_username_password>"/>
</webcache>

説明:

- <cache_instance_name>は、Web Cacheインスタンスのホスト名です。

- <cache_invalidation_port>は、Web Cacheの無効化ポートです。

- <obfuscated_username_password>は、invalidatorユーザー名およびパスワードです。
invalidatorユーザー名およびパスワードの不明瞭化については、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。

E.2.1.4 HTTPS URLにアクセスするためのOmniPortletの構成

次の操作を行うと、HTTPS URL経由でデータにアクセスするようOmniPortletを構成できます。

- 信頼できるサイトの証明書の追加

- HTTPSアクセス用のライブラリ(PDK専用)

信頼できるサイトの証明書の追加

このタスクは、WebクリッピングまたはOmniPortletのいずれかに1回のみ実行します。

Oracle Wallet Managerから生成された信頼できるサーバー証明書ファイルであるca-bundle.crtは、Oracle Portalに付属しています。このファイルには、HTTPSを使用してセキュアなサーバーに移動するために使用される、信頼できるサーバー証明書の初期リストが含まれています。しかし、これはWeb上に存在するセキュアと考えられるすべてのサーバー証明書の完全なリストではないため、信頼できる新たな参照サイトが加われば、そのサイトの信頼できるサーバー証明書が認識されるように、このファイルを構成または拡張する必要があります。信頼できる証明書ファイルの構成または拡張の詳細は、第7.1.12.1項「信頼できるサイトの証明書の追加」を参照してください。

HTTPSアクセス用のライブラリのコピー(PDK専用)

HTTPS URLにアクセスするには、OmniPortletはファイルnjssl10.dll (Windowsの場合)またはlibnjssl10.so (UNIXの場合)にアクセスする必要があります。

Windows上で実行されているプロバイダの場合、PATH環境変数に定義されているフォルダにnjssl10.dllファイルが必要です。このフォルダにない場合は、ORACLE_HOME/binディレクトリからコピーできます。

UNIX上で実行されているプロバイダの場合、LD_LIBRARY_PATH環境変数に定義されているフォルダにlibnjssl10.soファイルが必要です。このフォルダにない場合は、ORACLE_HOME/libディレクトリからコピーできます。

ライブラリをコピーした後、WLS_PORTALインスタンスを再起動する必要があります。

E.2.2 オプションのOmniPortlet構成の実行

次にオプションの構成タスクを示します。

LocalePersonalizationLevelの設定

OmniPortletおよびシンプル・パラメータ・フォームのLocalePersonalizationLevelのデフォルト設定は、noneです。このモードでは、「デフォルトの編集」モードを使用してポートレットのデフォルト値を編集する際に、現行のポータル・セッション言語またはブラウザのロケールに関係なく、変更がすべてのユーザーに適用されます。「デフォルトの編集」モードを使用した変更をすべてのユーザーに適用しない場合は、次のディレクトリにあるprovider.xmlファイルでLocalePersonalizationLevelタグをlanguageまたはlocaleに変更して、OmniPortletプロバイダのこの設定を変更できます。

UNIXの場合:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/1pwj8k/war/WEB-INF/providers/omniPortlet

Windowsの場合:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet

これらの設定の詳細は、次の場所にあるPDK-Javaのリリース・ノートを参照してください。

ORACLE_HOME/portal/pdkjava/v2/pdkjava.v2.releasenotes.html

Graphクラスの使用に戻ってのチャート・レイアウト・スタイルのレンダリング

OmniPortletでは、ThinGraphクラスを使用して、チャート・レイアウト・スタイルをレンダリングします。これによって、多言語サポートが強化され、中間層でフォントに依存しなくなります。Oracle Portal 11.1.1で作成されるチャート・スタイルは、Graphクラスが使用されていた前リリースのものとは異なる場合があります。前のチャート・スタイルを表示するには、前のGraphクラスの使用に戻る必要があります。

これを行うには、次の手順を実行します:

1. 次のディレクトリにあるprovider.xmlファイルに移動します。
UNIXの場合:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/1pwj8k/war/WEB-INF/providers/omniPortlet

Windowsの場合:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet

2. 次のようにuseThinGraphタグを編集します。
<useThinGraph>false</useThinGraph>

3. provider.xmlファイルを保存します。

E.2.3 OmniPortletプロバイダの登録(PDK専用)

OracleAS PDKの一部としてOmniPortletプロバイダをダウンロードしてインストールした場合にのみ、このタスクを実行します。

注意:

Oracle Fusion Middlewareのインストールの一部としてOracle Portalをインストールした場合、OmniPortletプロバイダは、ポートレット・リポジトリのポートレット・ビルダー・フォルダの下にデフォルトで登録されます。

OmniPortletプロバイダを構成したら、これをOracle Portalインスタンスにポートレット・プロバイダとして登録する必要があります。その後、ポートレットをポータル・ページに追加できます。

OmniPortletプロバイダを登録するには、次の手順を実行します。

1. Oracle Portalにログオンします。

2. Oracle Portalのホーム・ページにある「構築」タブに移動します。デフォルトでは、このページに「プロバイダ」ポートレットがあります。ここにない場合は、Portalの検索機能を使用して「プロバイダ」ポートレットを検索します。

3. 「プロバイダ」ポートレットの「ポートレット・プロバイダの登録」をクリックします。

4. 登録ウィザードの手順に従い、OmniPortletプロバイダの登録設定を指定します。

注意:

ポートレット・リポジトリの「ポートレット・ビルダー」フォルダの下にある生成済OmniPortletプロバイダと、このOmniPortletプロバイダを区別するには、このOmniPortletプロバイダに、たとえばOmniPortlet provider on host ABCのような区別しやすい名前を付ける必要があります。

表E-5には、指定する必要のある設定を示しています。

表E-5 OmniPortletプロバイダの登録設定

フィールド

値

名前

OmniPortlet_ABC

表示名

ホストABC上のOmniPortletプロバイダ

タイムアウト

200秒

タイムアウト・メッセージ

ホストABC上のOmniPortletプロバイダのタイムアウト

実装スタイル

Web

URL

http://<host>:<port>/portalTools/omniPortlet/providers/omniPortlet

ポートレットのコンテンツをキャッシュする場合は、Oracle Web Cacheインスタンスを指すようにWebキャッシュのURL名とポート番号を指定します。例:

http://<cache_instance_name>:<cache_port>/portalTools/omniPortlet/providers/omniPortlet

ユーザーは、Webプロバイダ・アプリケーション内とシングル・サインオン認証内とで、同じ識別情報を保持します

このオプションを選択します。

ユーザー固有の情報をプロバイダに送信する場合、「ユーザー」を選択します

このオプションを選択します。

ログイン周期

なし

プロキシを必要とする

No(プロバイダ・アダプタとの接続にプロキシを必要としない場合)

5. 「終了」をクリックします。

これで、OmniPortletプロバイダを使用してポートレットをポータル・ページに追加できるようになりました。OmniPortletプロバイダは、デフォルトでポートレット・リポジトリの「ポートレット・ステージング領域」フォルダの下に登録されます。

E.2.4 DataDirect JDBCドライバを使用して他のリレーショナル・データベースにアクセスするOmniPortletプロバイダの構成

OmniPortlet SQLデータ・ソースは、Oracle JDBCドライバを使用してOracle Databaseにアクセスするように事前構成されています。またSun社のJDBC-ODBCドライバを使用してODBCデータ・ソースにアクセスするように事前構成されています。DataDirect JDBCドライバ(優先ドライバ)を使用してOmniPortletで他のリレーショナル・データベースにアクセスするには、この手順を実行します。

DataDirect JDBCドライバを使用して、他のリレーショナル・データベースにアクセスするようOmniPortlet SQLデータ・ソースを構成できます。これを行うには、次の手順を実行します:

- DataDirect JDBCドライバのインストール

- OmniPortletへのDataDirectドライバの登録

関連項目:

サポートされるデータベースのリストについては、次の場所にある「Certification Matrix for Oracle Fusion Middleware and DataDirect JDBC」を参照してください。

http://www.oracle.com/technology/tech/java/

E.2.4.1 DataDirect JDBCドライバのインストール

DataDirect JDBCドライバは、単一のZIPファイルにパッケージ化されています。これにはサポートされるデータベースにアクセスするための様々なドライバが含まれています。このZIPファイルは次の場所からダウンロードします。

http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html

DataDirect JDBCドライバをインストールするには、次の手順を実行します。

1. ZIPファイルのコンテンツを一時ディレクトリ(/temp/datadirectなど)に解凍します。

2. ORACLE_HOME/portal/applibディレクトリを作成していない場合は、作成します。

3. /temp/datadirect/libディレクトリから、DataDirect JDBCドライバをORACLE_INSTANCE>/applibディレクトリにコピーします。

4. WLS_PORTALインスタンスの構成を調べて、DataDirectライブラリがロードされていることを確認します。これを行うには、次の手順を実行します:

1. DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portal\1qz1z6\APP-INF\classes\META-INF\application.xmlファイルを開きます。このファイルは、このインスタンスですべてのアプリケーションの構成に使用します。

2. 存在しない場合、<library path="../applib"/>のXMLエントリをファイルに追加します。

E.2.4.2 OmniPortletへのDataDirectドライバの登録

OmniPortletは、Webプロバイダとして実装され、すべての構成プロパティがprovider.xmlファイルに格納されます。DataDirect JDBCドライバをOmniPortletとともに使用するには、これらのドライバをprovider.xmlファイルに登録する必要があります。

新しいDataDirect JDBCドライバを登録するには、次の手順を実行します。

1. DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet\provider.xmlバックアップ・ファイルを作成して開きます。

2. SQLデータ・ソース構成エントリに使用するドライバを追加します。これを行うには、次を実行します。

1. XMLタグdriverInfoを検索します。

2. 最後のdriverInfoタグの後ろに新しいエントリを追加します。

次の例では、Microsoft SQL Serverのエントリを示します。

- OmniPortletリリース9.0.4.1以降の場合:

<!-- registration of DataDirect Connect for JDBC SQL Server driver -->
<driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo">
<name>Microsoft SQL Server</name>
<sourceDataBase>other</sourceDataBase>
<subProtocol>sqlserver</subProtocol>
<connectString>mainProtocol:subProtocol://databaseName</connectString>
<driverClassName>com.oracle.ias.jdbc.sqlserver.SQLServerDriver
</driverClassName>
<dataSourceClassName>com.oracle.ias.jdbcx.sqlserver.SQLServerDataSource
</dataSourceClassName>
<connHandlerClass>oracle.webdb.reformlet.data.jdbc.JDBCConnectionHandler
</connHandlerClass>
<connPoolSize>5</connPoolSize>
<loginTimeOut>30</loginTimeOut>
</driverInfo>

- 9.0.4.1より前のOmniPortletリリースの場合:

<!-- registration of DataDirect Connect for JDBC SQL Server driver -->
<driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo">
<name>Microsoft SQL Server</name>
<sourceDataBase>other</sourceDataBase>
<subProtocol>sqlserver</subProtocol>
<connectString>mainProtocol:subProtocol://databaseName</connectString>
<driverClassName>com.oracle.ias.jdbc.sqlserver.SQLServerDriver
</driverClassName>
<connHandlerClass>
oracle.webdb.reformlet.data.jdbc.JDBCODBCConnectionHandler
</connHandlerClass>
<connPoolSize>5</connPoolSize>
<loginTimeOut>30</loginTimeOut>
</driverInfo>

表E-6では、driverInfoプロパティのパラメータについて説明しています。

表E-6 driverInfoプロパティのパラメータ

パラメータ

説明

name

使用するデータベースの名前。この名前は、「OmniPortlet」ウィザードの「ソース」タブで使用されます。

sourceDataBase

内部値。この値はotherに設定します。

subProtocol

OmniPortletで接続文字列の作成に使用されるJDBCサブプロトコル名。たとえば、sqlserver、sybase、 db2です。サブプロトコル名の一覧については、この項の最後に示されているリンクから、DataDirect JDBCドライバのドキュメントを参照してください。

connectString

接続文字列の書式の説明。DataDirectドライバの場合、書式はmainProtocol:subProtocol://databaseNameです。

driverClassName

ドライバ・クラスの名前。他の値については、この項の最後に示されているリンクから、DataDirect JDBCドライバのドキュメントを参照してください。

dataSourceClassName

接続プーリングを実装するデータ・ソース・クラスの名前。このパラメータは、OmniPortletリリース9.0.4.1以降でのみ使用可能です。ご使用のドライバの適切なデータ・ソース・クラス名については、表E-7を参照してください。

connHandlerClass

OmniPortletでドライバおよび接続プーリングの管理に使用されるクラス。値は次のいずれかになります。

- OmniPortletリリース9.0.4.1以降の場合:
oracle.webdb.reformlet.data.jdbc.JDBCConnectionHandler

- 9.0.4.1より前のOmniPortletリリースの場合:
oracle.webdb.reformlet.data.jdbc.JDBCODBCConnectionHandler

connPoolSize

接続プールによって開かれる最小の接続数。

loginTimeOut

データベースへの接続にデータ・ソースが待機する最大時間(秒単位)。

表E-7では、特定のDataDirect JDBCドライバのdriverClassNameプロパティとdataSourceClassNameプロパティの値を示します。

表E-7 driverClassNameおよびdataSourceClassNameのパラメータと値

サポートされるDataDirectドライバ

プロパティ

Microsoft SQL Server

- パラメータ: driverClassName
値: com.oracle.ias.jdbc.sqlserver.SQLServerDriver

- パラメータ: dataSourceClassName
値: com.oracle.ias.jdbcx.sqlserver.SQLServerDataSource

Sybase

- パラメータ: driverClassName
値: com.oracle.ias.jdbc.sybase.SybaseDriver

- パラメータ: dataSourceClassName
値: com.oracle.ias.jdbcx.sybase.SybaseDataSource

DB2

- パラメータ: driverClassName
値: com.oracle.ias.jdbc.db2.DB2Driver

- パラメータ: dataSourceClassName
値: com.oracle.ias.jdbcx.db2.DB2DataSource

Informix

- パラメータ: driverClassName
値: com.oracle.ias.jdbc.informix.InformixDriver

- パラメータ: dataSourceClassName
値: com.oracle.ias.jdbcx.informix.InformixDataSource

3. provider.xmlファイルを保存します。

4. Oracle Fusion Middlewareインスタンスを停止して、起動します。

注意:

クラスタ環境やロード・バランシング環境などの複数ノード構成でOmniPortletを使用する場合は、各ノードにprovider.xmlファイルを手動でコピーする必要があります。

関連項目:

DataDirect JDBCドライバの詳細は、次のドキュメントを参照してください。

- 次のPortal Centerの「Portlet Development」ページにあるホワイト・ペーパー「How to Use DataDirect JDBC Drivers with OmniPortlet」
http://www.oracle.com/technology/products/ias/portal/portlet_development_10g1014.html

- 次の場所にある「Certification Matrix for Oracle Fusion Middleware and DataDirect JDBC」
http://www.oracle.com/technology/tech/java/

- 次のマニュアルに記載されているOmniPortletでのDataDirect JDBCドライバの使用に関する項
Oracle Fusion Middleware Oracle Portal開発者ガイド

トラブルシューティングの情報

OmniPortletプロバイダの構成または使用時にエラーや問題が発生した場合は、付録G「Oracle Portalのトラブルシューティング」のトラブルシューティングの情報を参照してください。

F 仮想プライベート・ポータルの設定と管理

この付録では、仮想プライベート・ポータル(VPP)を設定し、管理する手順について説明します。仮想プライベート・ポータル(ホストされるポータル)の設定と管理に関連する様々なタスクについては、事例を通じて示します。

この付録の内容:

- ホスティングの概要

- 仮想プライベート・ポータルで実行する手順の概要

- アウト・オブ・ボックスのポータルでのホスティングの有効化

- ASPのユーザーおよびグループ

- サブスクライバの追加

- 仮想プライベート・ポータルでの詳細操作

- 制限事項

- スクリプトのパラメータ

F.1 ホスティングの概要

タスクを調べる前に、ホスティング機能の利点と既知の制約について説明します。

F.1.1 ホスティングを使用する理由

顧客にポータル・サービスを提供したいと考えているアプリケーション・サービス・プロバイダ(ASP)のAcmeという会社を想定します。Acme社では、費用対効果が高くセキュアなポータルを作成およびカスタマイズできる柔軟性を顧客に提供したいと考えています。顧客が独自のユーザー、情報およびポータル・ページをセキュアに作成し、管理できるようにしたいと考えています。

各顧客専用のポータルまたはデータベース・インスタンスがあれば、顧客が必要とするセキュリティを提供できます。従来は、一企業内の複数の組織に対して完全に孤立化したポータル環境を実装するには、組織ごとに専用のデータベース・インスタンスが必要でした。これは、特に組織数が多い場合にはハードウェアと人件費の面で費用がかかります。顧客数が増加すると、人件費とハードウェアのコストが急速に増大していました。単一の共有インスタンスの方が管理しやすいのは明らかですが、複数の組織をセキュアにホストするのに必要なレベルの孤立性は得られません。

単一のインスタンスはコストが低く、管理も簡単ですが、従来のポータル・ソリューションでは、アプリケーション内に組み入れる複雑なセキュリティ・ルールが必要でした。Acme社で必要なのは、コストとセキュリティの両方の点で最善の方法です。VPPは、ASP向けプラットフォームに、大企業のIT部門で部門単位のイントラネットまたはエクストラネットのポータル・サイトをホストできる、管理しやすい方法を提供します。Oracle Portalには、複数の組織をホストするための費用対効果がより高く、しかも管理しやすいソリューションがあり、そのソリューションからきわめて高度なセキュリティ機能を備えた共有インスタンス・モデルの利点が得られます。VPPを使用する場合、サブスクライバを追加する必要があります。サブスクライバは、アプリケーション・サービス・プロバイダ(ASP)と契約し、ホストされたOracle Portalのストライプを割り当てられた企業です。

F.1.2 既知の制約

共有インスタンス・モデルには多くの利点がありますが、VPP環境を実装する前にいくつか考慮すべき点があります。

ホストされるテクノロジは、各サブスクライバ、つまり認証レルムを完全に切り離します。VPPは、ポータルでコンテンツを取得する前に、各ユーザーに対して、会社のIDおよび名前の入力や特定のコンテキストの設定を要求します。コンテンツとデータの範囲は、サブスクライバのコンテキストに制限されています。ポータルはサブスクライバ・レベルで保護されるので、サブスクライバ間でのデータ共有は一切できません。データ共有はセキュリティ上の理由で許可されません。たとえば、A社とB社でドキュメントを共有する場合は、VPPを使用しないでください。

すべてのサブスクライバに繰り返し変更を行う作業もより複雑です。管理上の観点からは、ポータルのユーザー・インタフェース操作はサブスクライバごとに行う必要があります。

例F-1 シナリオ1 - 多数のサブスクライバの管理

A社、B社およびC社に同一のポータル・ページ1、2および3があるとします。管理者がA社にログインしてページ1のレイアウトを変更すると、その特定のサブスクライバにのみ影響します。B社のページ1を変更するには、B社の管理者がポータルのユーザー・インタフェースを使用して同じ変更を実行する必要があります。サブスクライバの数が少ない間は、各サブスクライバへのログインは容易です。多数のサブスクライバを管理する場合、多数のポータル・サイトを管理する最善の方法は、ポータルAPIを使用するか、各サイトに変更を加える自動テスト・ツールを使用してページを更新することです。これにより、多数のサブスクライバの管理は非常に複雑になります。

例F-2 シナリオ2 - アップグレード

アップグレードについても考慮する必要があります。ポータル・リポジトリをアップグレードするときには、各サブスクライバのデータをアップグレードする必要があります。Acme社で1000サブスクライバをホストする場合、ポータル・リポジトリのアップグレードは、すべてのサブスクライバのデータを処理するまで完了しません。

1つのリポジトリのアップグレードに平均で10分かかるとします。単一インスタンス上でアップグレード処理を分割することは不可能なため、VPPによるポータル・リポジトリ・アップグレードでは既存のすべてのサブスクライバをループします。この例では、1つのアップグレードに10分、それにサブスクライバの数をかけただけかかるため、10×1000で10000分になります。これでは停止時間が長すぎます。

このため、小規模で管理しやすいVPPの配置としては、1インスタンス当たり50サブスクライバ程度にすることをお薦めします。どうしてもこの推奨最大数を超えてしまうときは、複数のVPPインスタンスを配置することを検討します。変更やアップグレードを行うための妥当な停止時間帯を選択するため、タイム・ゾーン・ベースで区分化することもお薦めします。個別にアップグレード可能な複数のポータル・リポジトリを構成できます。つまり、同時に1000サブスクライバすべてに影響を与えることなく、1つのインスタンス上で50サブスクライバをアップグレードすることができます。

注意:

このドキュメントでは、「サブスクライバ」と「認証レルム」を同じ意味で使用しています。

F.2 仮想プライベート・ポータルで実行する手順の概要

次の項で、ホスト・インストールの設定と管理に関連するタスクの概要を説明します。

- ホスティングの有効化

- ユーザーおよびグループの設定

- サブスクライバの追加

- サブスクライバの削除

- 拡張機能

- インストール前のチェックリスト

- Oracle Directory Managerの使用

F.2.1 ホスティングの有効化

- Oracle PortalとOracleAS Single Sign-On (SSO) Server上でホスティングを有効にします。

- ASPユーザーおよびグループのサポート用にOracle Internet Directory上に基本構造を作成します。

F.2.2 ユーザーおよびグループの設定

- サポートと管理のインフラストラクチャおよびユーザーによって、仮想プライベート・ポータルを設定します。ASPでは、これらを使用して、顧客に代わって仮想プライベート・ポータルを管理します。

F.2.3 サブスクライバの追加

- Oracle PortalおよびSSOスキーマ内に新しいサブスクライバ・ストライプを作成します。この手順にはページ、ページ・グループ、ポートレットおよびプロバイダの情報のようなオブジェクトのコピーも含まれるので、デフォルトの環境とページを事前に定義しておくことができます。

- 新しいOracle Internet Directoryサブスクライバ・ツリーを作成し、Oracle Internet Directory内に必要なポータル・エントリ(生成済のグループ、ユーザー、権限など)を確立します。

- Oracle Internet Directory内の新しいサブスクライバ用にASPグループおよびユーザーをコピーします(ミラー・エントリの作成、権限の割当てなど)。

F.2.4 サブスクライバの削除

- Oracle PortalおよびSSOスキーマ内のサブスクライバのデータを削除します。

- Oracle Internet Directory内のサブスクライバ・サブ・ツリー全体を削除します。

F.2.5 拡張機能

- WebDAVを使用すると、URLアドレスを透過的な読込みおよび書込みメディアとして利用することができます。つまり、コンテンツをチェックアウトし、編集してからチェックインすることができます。

- Secure Enterprise Searchには、Oracle Database、IMAPサーバー、Webページ、ディスク・ファイル、ポータル・ページ・グループなどの複数のリポジトリの一括検索機能が用意されています。

F.2.6 インストール前のチェックリスト

仮想プライベート・ポータルを有効にするスクリプトを実行する前に、最初に、このようなスクリプトを実行するための情報を収集します。表F-1は、パラメータの一覧とその説明です。

表F-1 パラメータ

パラメータ

説明

-pc

<host>:<port>:<sid>の書式のポータル・スキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。これは、必須のパラメータです。

-ps

Oracle Portalスキーマ名。デフォルトでは、portalです。

-sc

<host>:<port>:<sid>の書式のSSOスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。デフォルトでは、-pcパラメータの値です。

-ss

SSOスキーマ名。デフォルトでは、orassoです。

-h

Oracle Internet Directoryサーバーのホスト名。これは、必須のパラメータです。

-p

Oracle Internet Directoryサーバーのポート番号。デフォルトでは、389です。

-d

Oracle Internet DirectoryバインドDN。デフォルトでは、cn=orcladminです。このDNには、新しいサブスクライバを作成するための権限など、Oracle Internet Directory管理権限がある必要があります。

F.2.7 Oracle Directory Managerの使用

プロセスを開始するには、Oracle Directory Manager(ODM)を使用します。ODMは、Oracle Internet Directoryを管理する上で役立つGUIツールです。ポータルおよびorassoユーザーのパスワードを入手するには、次の手順を実行します。

1. Oracle Directory Managerを起動します。

- 最初のフィールドで、Oracle Internet DirectoryバインドDN(パラメータの-d)を指定します。デフォルトでは、cn=orcladminです。このDNには、新しいサブスクライバを作成するための権限など、Oracle Internet Directory管理権限がある必要があります。

- 2番目のフィールドで、Oracle Internet DirectoryバインドDNのパスワード(パラメータの-w)を指定します。デフォルトでは、welcome1です。

- 3番目のフィールドで、Oracle Internet Directoryインスタンスを選択します。Oracle Internet Directoryインスタンスを定義していない場合は、このフィールドの右にあるアイコンをクリックし、Oracle Internet Directoryが実行されているサーバーのホスト名(パラメータの-h)とポート番号(パラメータの-p)を指定します。デフォルトでは、389または4032です。

2. Oracle Internet Directoryにログインした後は、メニュー・ツリーに沿って次のように移動します。「エントリ管理」 > cn=OracleContext > cn=Products > cn=IAS。
cn=IAS Infrastructure Database > orclReferenceName=Oracle Internet Directoryデータベースの名前。

3. ツリーの移動を続けます。

4. orassoユーザー名をクリックします。

5. 右側のパネルで、orclpasswordattributeというセクションを探します。これはorassoユーザーのパスワードです(パラメータの-sw)。

6. ポータル・ユーザー名をクリックします。

7. 右側のパネルにorclpasswordattributeというセクションがあります。これは、ポータル・ユーザーのパスワードです(パラメータの-pw)。

F.3 アウト・オブ・ボックスのポータルでのホスティングの有効化

アウト・オブ・ボックスのOracle Portalのインストールを開始するには、ポータル上でホスティングを有効にします。Cシェル・スクリプトによって、次のタスクが実行されます。

- Oracle PortalとOracleAS Single Sign-On Server上でホスティングを有効にします。

- ASPユーザーおよびグループのサポート用にOracle Internet Directory上に基本構造を作成します。

スクリプトがどのように動作するかを示すために、スクリプトを実行する前のOracle Internet Directoryツリーの図を次に示します。

図F-1 スクリプト実行前のOracle Internet Directoryツリー

スクリプトを実行するには、UNIXのコマンドラインで次のように入力します。

cd ORACLE_HOME/portal/admin/plsql/wwhost
./enblhstg.csh -pc portaldb.acme.com:1521:portaldb -ps portal -sc portaldb.acme.com:1521:portaldb -ss orasso -h oid.acme.com -p 389 -d "cn=orcladmin"

Single Sign-Onの中間層を停止し、起動します。

パラメータの詳細な説明は、第F.8項「スクリプトのパラメータ」を参照してください。

スクリプトを実行した後、Oracle Internet Directoryツリーは図F-2のようになります。

図F-2 スクリプト実行後のOracle Internet Directoryツリー

これで、ポータル・インスタンスのホスティングが有効になりました。ポータルのログイン画面に進むと、「ユーザー名」、「パスワード」および「企業」の3つの入力フィールドが表示されます。デフォルトのサブスクライバとしてログインする場合は、「企業」フィールドに「acme」と入力するか、または空白のままにしておきます。

デフォルトのサブスクライバは、管理上の目的でASPのために保存されています。それぞれの顧客に対しては、顧客がログインして使用できるようになる前に新しいサブスクライバを作成しておく必要があります。

F.4 ASPのユーザーおよびグループ

Acme社はASPであるため、顧客に代わって仮想プライベート・ポータルを管理するためのサポートと管理のインフラストラクチャが必要です。仮想プライベート・ポータルには、複数のサブスクライバPortalの管理が容易になるような、ASPのユーザーとグループに対するサポート機能が用意されています。

ASPのユーザーとグループは、Acme社のサブスクライバ(顧客)の仮想プライベート・ポータルに対する様々なレベルの管理アクセス権を持つことができます。ASPユーザーは、必要な権限に応じて複数のグループに分割することができます。たとえば、Aliceにはユーザー・アカウントを管理する権限、BobとJoeにはページ・コンテンツを管理する権限が必要だとします。これらの権限グループは、ASPグループです。

このようなASPユーザーとグループによって、1人のASPユーザーが単一の証明書のセット(ユーザー名およびパスワード)を使用して複数のサブスクライバにログインすることができ、すべてのサブスクライバに事前に定義された権限と同じ権限のセットを持つことができるようになります。このことは、すべてのサブスクライバを網羅するASPユーザーおよびグループのミラー・エントリを作成することによって行われます。ユーザーおよびグループのエントリは、事前に提供されるスクリプトによって同期が保たれます(ASP同期化スクリプトに関する項を参照)。注意: この同期化(スクリプトまたは自動で)は、ユーザーとグループを同期化するだけで、ポータル権限は同期化しません。

次の各項で、Acme社用にASPユーザーおよびグループのサポートによって仮想プライベート・ポータルを設定する方法と、その他実行することが望ましい場合があるタスクについて説明します。

- ASPユーザーおよびグループの設定

- 制限事項

F.4.1 ASPユーザーおよびグループの設定

ASPユーザーおよびグループのためのマスター・エントリは、デフォルトのサブスクライバに存在します。ユーザーとグループは追加のアクセス権を持つことができるので(デフォルトのサブスクライバ内のすべてのユーザーがすべてのサブスクライバにログインできるわけではありません)、ASPのユーザーおよびグループを明示的に設定する必要があります。

ポータル上でホスティングを有効にすると、スクリプトによって、デフォルトのサブスクライバのOracle Internet Directoryサブツリーの下にASPという名前のグループが作成されます。これは、ASPユーザーおよびグループのサポートのためのプレースホルダです。ASPユーザーおよびグループを設定するために、このプレースホルダが必要です。この時点から、このプレースホルダのグループはASPグループとして参照されます。Acme社がASPのユーザーとグループを使用できるいくつかの例をあげます。

- Aliceは、すべてのサブスクライバのユーザー・アカウントを管理する必要があります。

- BobとJoeは、すべてのサブスクライバのページを管理する必要があります。

- Tomは、すべてのサブスクライバにログインする必要がありますが、標準の認証されたユーザー権限しか持っていません。

これを行うには、次の手順を実行します。

- デフォルトのサブスクライバ内に、ユーザーのasp_alice、asp_bob、asp_joeおよびasp_tomを作成します。

- デフォルトのサブスクライバ内にasp_UserAdmというグループを作成し、そのグループにユーザー・アカウントを管理する権限を割り当てます。また、同じデフォルトのサブスクライバ内にasp_PageAdmというグループを作成し、そのグループにページを管理する権限を割り当てます。

- asp_UserAdmグループのメンバーとしてasp_aliceを加えます。

- asp_PageAdmグループのメンバーとしてasp_bobとasp_joeを加えます。

- ASPグループのメンバーとしてasp_UserAdmとasp_PageAdmを加えます。

- ASPグループのメンバーとしてユーザーasp_tomを加えます。

これで、ASPのユーザーとグループを設定しました。Oracle Internet Directoryツリーは、図F-3のようになります。

図F-3 ユーザーおよびグループを設定したOracle Internet Directoryツリー

さらに正確に説明すると、ASPユーザーおよびグループは、次のように定義されています。

- ASPグループは、ASPグループそのもの、またはその直接のグループ・メンバーのどちらかです。

- ASPユーザーは、ASPグループの直接のユーザー・メンバーです。

図F-4 Acme社のユーザーおよびグループのメンバーシップ構造

デフォルトでは、ポータルのブートストラップ・ユーザーはASPグループのメンバーです。つまり、このようなユーザーは、デフォルトではASPユーザーです。ポータルのブートストラップ・ユーザーであるportal、portal_adminおよびFMWADMINの詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

新しいサブスクライバを追加すると、ポータルのサブスクライバ追加のスクリプトによって、新しいサブスクライバ内にASPユーザーおよびグループのためのミラー・エントリが自動的に作成されます。したがって、それらのユーザーは新しいサブスクライバにログインすることができ、対応する権限を持つことができます。

F.4.2 制限事項

ASPユーザー/グループの設定には、制限事項がいくつかあります。

- ASPユーザーおよびグループは、2レベルより多くレベルを設定できません。つまり、ASPグループの直接のメンバーでないASPグループ、またはどのASPグループの直接のメンバーでもないユーザーは、ミラー・エントリの作成中に無視されます。

- Oracle Internet Directoryでは、ユーザー名は各サブスクライバ内でASPユーザーも含めて一意である(大文字と小文字の区別なし)ことが必要です。たとえば、サブスクライバであるCompanyA内にBobとbobの2人のユーザーがあってはなりません。ASPユーザーは各サブスクライバ内にミラー・エントリを持つので、ユーザー名の重複を防ぐためにASPユーザーには特別な名前を付けてください。これに対応して、このドキュメント全体で、asp_bob、asp_joeのような名前を使用しています。

- 同じ理由で、ASPグループにもasp_PageAdmin、asp_UserAdminのような特別な名前を使用します。ホスティング・スクリプトではASPグループが動的に処理されるので、ASPグループ内にポータルの生成済のグループを作成しないでください。同じ権限のASPグループが必要な場合は、新しいグループを作成し、そのグループを生成済のグループのメンバーにします。

- デフォルト以外のサブスクライバのASPユーザーおよびグループは、ホスティング・スクリプトでのみ管理します。これらのユーザー、グループまたはその両方を手動で変更しないでください。

- ASPグループはすべてのASPユーザーおよびグループの唯一のプレースホルダであり、権限のために設計されているのではありません。ASPグループに権限を割り当てないでください。これらの権限は他のサブスクライバにコピーされません。

F.5 サブスクライバの追加

これで、Acme社によってASPユーザーとグループが設定され、ポータルのホスティングが有効になりました。次の手順は、顧客を仮想プライベート・ポータルのサブスクライバとして追加することです。CompanyA、CompanyBなどのAcme社の各顧客用に、ポータルに新しいサブスクライバを作成します。Cシェル・スクリプトによって、次のタスクが実行されます。

- Oracle PortalおよびSSOスキーマ内に新しいストライプを作成します。この段階で、ページ・グループ、ページ、ポートレットおよびプロバイダ情報などのオブジェクトがコピーされます。

- 新しいOracle Internet Directoryサブスクライバ・ツリーを作成し、Oracle Internet Directory内に必要なポータル・エントリ(生成済のグループ、ユーザー、権限など)を確立します。

- Oracle Internet Directory内の新しいサブスクライバ用にASPグループおよびユーザーをコピーします(ミラー・エントリの作成、権限の割当てなど)。

サブスクライバのCompanyAを追加するには、UNIXのコマンドラインで次のコマンドを入力します。

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name CompanyA -id 1001 -type all -pc
portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso –a
portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d "cn=orcladmin" -rc "cn=OracleContext" -sd acme -tp ORACLE_INSTANCE/ldap/schema/oid/

パラメータの説明は、第F.8項「スクリプトのパラメータ」を参照してください。

出力を確認し、エラーがあった場合はオラクル社のテクニカル・サポートに連絡してください。スクリプトを実行すると、サブスクライバであるCompanyAは、Oracle PortalとOracle Internet Directoryの両方に存在します。Oracle Internet Directoryツリーは、図F-5のようになります。

図F-5 ポータルおよびOracle Internet Directory内のCompanyA

同じスクリプトを実行してサブスクライバのCompanyBを作成します。

これで、2つのサブスクライバがある仮想プライベート・ポータルを設定しました。ASPユーザーを試行するには、デフォルトのサブスクライバ内に作成したのと同じパスワードを使用して、ユーザーのasp_aliceとしてCompanyAにログインしてください。Aliceは、ユーザー管理タスクを行うための権限を持っている必要があります。

F.6 仮想プライベート・ポータルでの詳細操作

この項の内容:

- ASPユーザーおよびグループの管理

- サブスクライバの削除

- 仮想プライベート・ポータル内でのWebDAVの使用

- 仮想プライベート・ポータル用のDirectory Integration Platformの設定

- 部分的に準備(下処理)されたサブスクライバ

F.6.1 ASPユーザーおよびグループの管理

すべてのサブスクライバを設定した後で、ASPユーザーおよびグループの構造でいくつかの変更が必要になることがあります。例:

- Bobがデフォルトのサブスクライバ内の自分のパスワードを変更したので、他のすべてのサブスクライバ内でも新しいパスワードと同期化する必要があります。

- Joeは、Acme社を辞めたので、ASPユーザーとして以後ログインできないようにする必要があります。

- サービス契約が変更され、ASPではユーザー・アカウントの問題に以後責任を持ちません。そのため、asp_UserAdmグループは必要なくなります。

- ASPユーザーおよびグループがデフォルトのサブスクライバ内で変更される場合は、その他のすべてのサブスクライバ内で変更を同期化するために、提供されたスクリプトを使用する必要があります。

この同期化スクリプトには、次の3つのオプションがあります。

- パスワード同期

- デルタ(構造の変更)同期

- 完全同期

F.6.1.1 パスワード同期

パスワード同期を使用すると、このスクリプトによって、デフォルトのサブスクライバ内のパスワードが使用され、すべてのASPユーザーのミラー・エントリのパスワードが更新されます。

前述の最初の例の場合、UNIXコマンドラインで次のコマンドを使用して、Bobの新しいパスワードとの同期をとることができます。

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode pwd -u asp_bob

Directory Integration Platformを有効にしている場合は、ASPユーザーのパスワード変更の同期化が自動的に行われるので、このスクリプトを実行する必要はありません。

F.6.1.2 デルタ(構造の変更)同期

デルタ同期を使用する場合は、このスクリプトによって、デフォルトのサブスクライバ内で変更されたユーザーおよびグループが検索され、他のすべてのサブスクライバにも変更内容が適用されます。

従業員の退職またはサービス契約の変更の場合、UNIXコマンドラインで次のコマンドを使用して、新しいASP構造との同期をとることができます。

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode dif

デルタ同期では、古いASP構造との一貫性および整合性を前提としています。つまり、各サブスクライバ内の古いASP構造が一貫性のある正しいものであれば、デルタ同期は正しく動作します。そうでない場合は、デルタ同期よりも低速の完全同期のオプションを使用します。

F.6.1.3 完全同期

スクリプトによってデフォルトのサブスクライバのASP構造が取得され、他のすべてのサブスクライバの構造へ上書きされます。デルタ同期によるASP構造の同期化に失敗した場合は、このオプションの使用を考慮してください。

従業員の退職またはサービス契約の変更の場合、UNIXコマンドラインで次のコマンドを使用して、新しいASP構造との同期をとることができます。

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode all

完全同期はデルタ同期よりも速度が遅いため、必要な場合にのみ使用してください。

F.6.2 サブスクライバの削除

ポータルのサブスクライバが不要になった場合、またはサブスクライバの作成中にエラーが発生した場合は、提供されているスクリプトを使用して、そのサブスクライバを永久に削除することができます。このスクリプトにより、次のことが実行されます。

- Oracle PortalおよびSSOスキーマ内のサブスクライバのデータを削除します。

- Oracle Internet Directory内のサブスクライバ・サブ・ツリー全体を削除します。

たとえば、サブスクライバのnowhereを削除するには、UNIXコマンドラインで次のコマンドを入力します。仮想プライベート・ポータルのインスタンスをインストールしたOracle Databaseのバックアップがないかぎり、この方法で削除したサブスクライバは復元できなくなります。

> cd ORACLE_INSTANCE/portal/admin/plsql/wwhost

>./rmsub.csh -name nowhere -pc portaldb.acme.com:1521:portaldb -pp change_on_
install -ps portal -sc portaldb.acme.com:1521:portaldb -sp change_on_install -ss
orasso –a portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d
"cn=orcladmin" -cs 1000

パラメータの説明は、第F.8項「スクリプトのパラメータ」を参照してください。

F.6.3 仮想プライベート・ポータル内でのWebDAVの使用

WebDAVは、分散オーサリングおよびバージョン管理をサポートするプロトコルです。WebDAVを使用すると、インターネットを透過的な読込みおよび書込みメディアとして利用することができます。つまり、URLアドレスに基づいて、コンテンツをチェックアウトし、編集してからチェックインすることができます。Oracle PortalでのWebDAVの動作、およびWebDAVの設定方法の詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。

仮想プライベート・ポータルでのWebDAVの設定方法は、アウト・オブ・ボックスのポータルでのWebDAVの設定方法と同じです。

仮想プライベート・ポータルでのWebDAVへの接続方法は、アウト・オブ・ボックスのポータル内での接続方法と類似しています。唯一の違いは、仮想プライベート・ポータル内でWebDAVへ接続するときに、次の行が使用されることです。

"<username>@<subscriber_name>" as the username, instead of just ...
"<username>" as required in an out-of-the-box portal.

たとえば、サブスクライバであるCompanyA内のユーザーJoeを使用してWebDAVに接続するには、ユーザー名としてjoe@CompanyA、パスワードとしてJoeのパスワードを使用します。

別のサブスクライバがWebDAV接続のために同じURLを使用すると、クライアント側のオペレーティング・システムがその接続をキャッシュに入れる可能性があります。たとえば、Windows 2000 PCでユーザーportal_admin@acmeを使用してWebDAVに接続すると、オペレーティング・システムのキャッシュが原因で、サブスクライバであるCompanyA内でユーザーjoe@CompanyAとしてWebDAVに接続できません。オペレーティング・システムのキャッシュや格納されたユーザー名およびパスワードの消去方法の詳細は、オペレーティング・システムのドキュメントを参照してください。

F.6.4 仮想プライベート・ポータル用のDirectory Integration Platformの設定

Directory Integration Platformとは、様々なディレクトリとディレクトリ対応アプリケーション間の同期化を実行する包括的なフレームワークです。このフレームワークによって提供されるサービスの1つがProvisioning Integrationであり、このサービスで、ディレクトリ・イベントについての通知をディレクトリ対応アプリケーションへ送信することができます。

関連項目:

Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

アウト・オブ・ボックスのOracle Portalのインストールにおいては、Directory Integration Platformは有効化されています。仮想プライベート・ポータルでDirectory Integration Platformを無効にしてある場合、次の手順を実行してDirectory Integration Platformを再度有効化します。

1. 既存のサブスクライバでDirectory Integration Platformを有効にするための、提供されているスクリプトを実行します。
たとえば、UNIX環境では次のように実行します。

enbldip.csh -pc portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -enable

2. addsub.cshとrmsub.csh内のoidprovtoolへのコールをコメント解除して、サブスクライバを追加または削除するときにこれらの2つのスクリプトがDirectory Integration Platformプロファイル・エントリに適用されるようにします。
これを行うには、次の手順を実行します。

1. エディタで前述の2つのファイルを開きます。

2. oidprovtool文字列のある行を検索します。

3. 検索された行をコメント解除します。

また、次を実行して、ポータル内のすべてのサブスクライバにあるDirectory Integration Platformを無効にすることもできます。

1. 次のようにして、提供されているスクリプトをUNIXのコマンドラインで実行します。

enbldip.csh -pc portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -h oid.acme.com -p 389 -d "cn=fmwadmin" -disable

2. addsub.cshとrmsub.csh内のoidprovtoolへのコールをコメント化して、サブスクライバを追加または削除するときにこれらの2つのスクリプトがDirectory Integration Platformプロファイル・エントリを無視するようにします。
これを行うには、次の手順を実行します。

1. エディタで前述の2つのファイルを開きます。

2. oidprovtoolのある行を検索します。

3. 検索された行をコメント化します。

F.6.5 部分的に準備(下処理)されたサブスクライバ

addsub.cshスクリプトを実行して新しいサブスクライバを作成する場合、Oracle Portal、Oracle Internet DirectoryおよびOracleAS Single Sign-Onがインストールされているコンピュータがどのように構成されているかに応じて、数分かかることがあります。新しいサブスクライバが作成されるときに発生するデータ操作に加えて、ほとんどのASPは、サブスクラバ作成時に、管理プロビジョニングとサブスクライバ固有のカスタマイズを実行します。

サブスクライバの登録をすばやく行うために、仮想プライベート・ポータルでは、ASPがサブスクライバを部分的に準備できるようになっています。このようにすると、ASPが登録されるときに、サブスクライバでは登録後のカスタマイズのみを実行する必要があり、仮想プライベート・ポータルのストライプをそのサブスクライバに直接割り当てます。仮想プライベート・ポータルには、addsub.cshスクリプト内にデータベース専用モードが用意されています。そのモードでは、ポータルおよびSSOデータベースでデータのコピーが実行されます。ASPがサブスクライバにストライプを割り当てる準備ができると、LDAPモードを使用してaddsub.cshスクリプトを実行することで、サブスクライバの作成が終了します。

ポータルおよびSSOデータベース内でサブスクライバを部分的に準備する場合は、addsub.csh内で-typeパラメータを使用します。たとえば、UNIXのコマンドラインで次のように入力します。

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name TEMP_COMPANY -id 1003 -type db -pc
portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso -h
oid.acme.com -p 389 -d "cn=orcladmin" -rc "cn=OracleContext" -sd acme

この例で使用されているように、会社名にTEMP_COMPANYのような一時的な名前を使用することができます。後で顧客(CompanyCなど)が実際に追加されるとき、UNIXコマンドラインで次のコマンドを実行することができます。

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name CompanyC -id 1003 -type ldap -pc
portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso -a
portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d "cn=orcladmin"
-rc "cn=OracleContext" -sd acme -tp ORACLE_INSTANCE/ldap/schema/oid/

部分的にサブスクライバを準備するときと同じサブスクライバIDを使用して、顧客の本来の名前(CompanyC)を付ける必要があります。これまでの名前(前述の例では、TEMP_COMPANY)が新しい名前に置き換えられます。スクリプトによってCompanyCのためのOracle Internet Directoryサブスクライバ・ツリーが作成され、Oracle Internet Directoryの設定とポータル・スキーマが同期化されます。このプロセスは、最初からサブスクライバを作成するよりも時間がかかりません。

-type ldapオプションを使用してaddsub.cshを実行する前に、-type dbオプションを使用して、サブスクライバを部分的に準備する必要があります。

仮想プライベート・ポータルでのOracle Portal中間層のインストール

第3章「インストール前およびインストール後の作業」の手順を実行することで、Oracle Portal中間層のインストールを実行できます。

Oracle Portal中間層インストールは、仮想プライベート・ポータルに対して実行することができます。

F.7 制限事項

次の項に、様々な仮想プライベート・ポータルのスクリプトと操作に対する制限事項をまとめています。

- スクリプト

- ASPユーザーおよびグループのサポート

- サブスクライバの追加

- サブスクライバの削除

- アップグレード

F.7.1 スクリプト

仮想プライベート・ポータルの構成およびプロビジョニングのスクリプトは、現在のところ、UNIX Cシェル環境でのみ実行できます。

F.7.2 ASPユーザーおよびグループのサポート

- トップ・レベルのASPグループには、どのOracle Internet Directory権限も割り当てないでください。権限は、サブスクライバ間でコピーまたは同期化されません。ASPグループのサブグループの権限は、同期化され、コピーされます。

- デフォルトのサブスクライバ以外のその他のサブスクライバで実行されるOracle Internet Directory内のASPユーザーおよびグループの構造に対する変更は、サブスクライバの同期化のスクリプトが実行されるときは保存されません。

- ポータルの生成済のグループは、ASPグループにはできません。

F.7.3 サブスクライバの追加

新しいサブスクライバの名前は、Oracle Internet Directory内で一意である必要があります。

F.7.4 サブスクライバの削除

このスクリプトは、デフォルトのサブスクライバを削除するためには使用できません。これを行うには、Portal依存性設定ツール(ptlconfig)を使用します。

F.7.5 アップグレード

Oracle Portalリリース9.0.2.xから9.0.4.xへのアップグレードを実行する場合、Oracle Text索引を再作成する必要があります。ctxcrind.sqlスクリプトを実行してすべてのOracle Text索引を再作成する方法の詳細は、第10.3.4.1項「ctxcrind.sqlを使用したすべてのOracle Text索引の作成」を参照してください。

F.8 スクリプトのパラメータ

表F-2から表F-6に、仮想プライベート・ポータルを管理するために提供されているスクリプト用のすべてのパラメータを一覧表示し、説明します。これらのスクリプトは、ORACLE_HOME/portal/admin/plsql/wwhostディレクトリにあります。

注意:

任意のスクリプトのパラメータのリストを作成するには、UNIXシェル内でパラメータなしでそのスクリプトを実行します。スクリプトの出力をログ・ファイルに保存する場合は、<log_filename>を使用するログ・ファイルの名前で置き換えて、コマンドの最後に|& tee <log_filename>を入力します。

表F-2 enblhstg.csh

パラメータ

説明

-pc

<host>:<port>:<sid>の書式のOracle Portalスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。これは、必須のパラメータです。

-ps

Oracle Portalスキーマ名。デフォルトでは、portalです。

-pw

Oracle Portalスキーマのパスワード(デフォルトはなし)。

-sc

<host>:<port>:<sid>の書式のSSOスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。デフォルトでは、-pcパラメータの値です。

-ss

SSOスキーマ名。デフォルトでは、orassoです。

-sw

SSOスキーマのパスワード(デフォルトはなし)。

-h

Oracle Internet Directoryサーバーのホスト名。これは、必須のパラメータです。

-p

Oracle Internet Directoryサーバーのポート番号。デフォルトでは、389です。

-d

Oracle Internet DirectoryバインドDN。デフォルトでは、cn=fmwadminです。このDNには、新しいサブスクライバを作成するための権限など、Oracle Internet Directory管理権限がある必要があります。

-w

Oracle Internet DirectoryバインドDNのパスワード(デフォルトはなし)。

表F-3 addsub.csh

パラメータ

説明

-name

新しいサブスクライバのOracle Internet Directoryニックネーム。これは、必須のパラメータです。この名前は、他のどのサブスクライバによっても使用されていないものにします。

-id

新しいサブスクライバの内部IDであり、Oracle PortalおよびOracleAS Single Sign-On内で使用されます。これは、必須のパラメータです。これは、Oracle PortalやOracleAS Single Sign-Onスキーマにある他のどのサブスクライバでも使用していないものとする必要があります。

-type

有効な値は、次のとおりです。

- db - Oracle PortalおよびOracleAS Single Sign-Onスキーマ内でシード・データのみをコピーします。

- ldap - Oracle PortalおよびOracleAS Single Sign-OnのためにOracle Internet Directoryエントリを作成します。-type dbオプションを使用して一時的なサブスクライバを追加した後に、-type ldapオプションのみを使用してスクリプトを実行することができます。

- all - デフォルト値であり、dbとldapタイプのジョブを両方とも実行します。

-pc

<host>:<port>:<sid>の書式のOracle Portalスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。これは、必須のパラメータです。

-pp

ポータル・インスタンスのSYSユーザーのパスワード。デフォルトでは、change_on_installです。

-ps

Oracle Portalスキーマ名。デフォルトでは、portalです。

-pw

Oracle Portalスキーマのパスワード(デフォルトはなし)。

-sc

<host>:<port>:<sid>の書式のSSOスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。デフォルトでは、-pcパラメータの値です。

-sp

SSOインスタンスのSYSユーザーのパスワード。

-ss

SSOスキーマ名。デフォルトでは、orassoです。

-sw

SSOスキーマのパスワード。デフォルトでは、-ssパラメータの値です。

-a

Portalアプリケーション名。デフォルトでは、<portal_schema>.<sid>.<dbhost>です。

-h

Oracle Internet Directoryサーバーのホスト名。これは、必須のパラメータです。

-p

Oracle Internet Directoryサーバーのポート番号。デフォルトでは、389です。

-d

Oracle Internet DirectoryバインドDN。デフォルトでは、cn=fmwadminです。このDNには、新しいサブスクライバを作成するための権限など、Oracle Internet Directory管理権限がある必要があります。

-w

Oracle Internet DirectoryバインドDNのパスワード(デフォルトはなし)。

-rc

Oracle Internet Directoryルート・コンテキストDN。デフォルトでは、cn=OracleContextです。

-sd

テンプレート・サブスクライバのOracle Internet Directoryニックネーム。デフォルトでは、ポータルのデフォルト・サブスクライバのニックネームです。

-tp

Oracle Internet Directoryサブスクライバ作成のためのテンプレート・ファイルのファイル・システムのパス。デフォルトでは、ORACLE_INSTANCE/ldap/schema/oid/です。

表F-4 rmsub.csh

パラメータ

説明

-name

削除される既存の非デフォルト・サブスクライバのOracle Internet Directoryニックネーム。これは、必須のパラメータです。デフォルトのサブスクライバは、このスクリプトで削除できません。かわりにptlconfigツールを使用してください。

-pc

<host>:<port>:<sid>の書式のOracle Portalスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。これは、必須のパラメータです。

-pp

ポータル・インスタンスのSYSユーザーのパスワード(デフォルトはなし)。

-ps

Oracle Portalスキーマ名。デフォルトでは、portalです。

-sc

<host>:<port>:<sid>の書式のSSOスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。デフォルトでは、-pcパラメータの値です。

-sp

OracleAS Single Sign-OnインスタンスのSYSユーザーのパスワード。デフォルトでは、OracleAS Single Sign-OnとOracle Portalが別のデータベース・インスタンスにある場合はchange_on_installであり、OracleAS Single Sign-OnとOracle Portalが同じデータベース・インスタンスを使用する場合は-ppパラメータの値です。

-ss

SSOスキーマ名。デフォルトでは、orassoです。

-a

Portalアプリケーション名。デフォルトでは、<portal_schema>.<sid>.<dbhost>です。

-h

Oracle Internet Directoryサーバーのホスト名。これは、必須のパラメータです。

-p

Oracle Internet Directoryサーバーのポート番号。デフォルトでは、389です。

-d

Oracle Internet DirectoryバインドDN。デフォルトでは、cn=fmwadminです。このDNには、新しいサブスクライバを作成するための権限など、Oracle Internet Directory管理権限がある必要があります。

-w

Oracle Internet DirectoryバインドDNのパスワード(デフォルトはなし)。

-cs

コミット・サイズ。必須のデータベースのコミット前に削除できる行数を指定します。デフォルトでは、1000です。

表F-5 syncasp.csh

パラメータ

説明

-mode

これは、必須のパラメータです。有効な値は、次のとおりです。

- pwd - 1人のASPユーザーのためにパスワードを同期化します。

- dif - 最後の同期化以後のASP構造の変更を同期化します。

- all - ASP構造の完全な同期化を行います。

-pc

<host>:<port>:<sid>の書式のOracle Portalスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。これは、必須のパラメータです。

-ps

Oracle Portalスキーマ名。デフォルトでは、portalです。

-pw

Oracle Portalスキーマのパスワード(デフォルトはなし)。

-h

Oracle Internet Directoryサーバーのホスト名。これは、必須のパラメータです。

-p

Oracle Internet Directoryサーバーのポート番号。デフォルトでは、389です。

-d

Oracle Internet DirectoryバインドDN。デフォルトでは、cn=fmwadminです。このDNには、新しいサブスクライバを作成するための権限など、Oracle Internet Directory管理権限がある必要があります。

-w

Oracle Internet DirectoryバインドDNのパスワード(デフォルトはなし)。

-u

このパラメータは、パスワードを同期化させる必要があるユーザー名を指定するために、パスワード同期のパラメータ(pwd)とともに使用されます。

-l

ログ・ファイル名。

表F-6 embldip.csh

パラメータ

説明

-pc

<host>:<port>:<sid>の書式のOracle Portalスキーマのデータベース接続文字列。<host>は、絶対ドメイン名です。これは、必須のパラメータです。

-pp

ポータル・インスタンスのSYSユーザーのパスワード(デフォルトはなし)。

-ps

Oracle Portalスキーマ名。デフォルトでは、portalです。

-h

Oracle Internet Directoryサーバーのホスト名。これは、必須のパラメータです。

-p

Oracle Internet Directoryサーバーのポート番号。デフォルトでは、389です。

-d

Oracle Internet DirectoryバインドDN。デフォルトでは、cn=fmwadminです。このDNには、新しいサブスクライバを作成するための権限など、Oracle Internet Directory管理権限がある必要があります。

-w

Oracle Internet DirectoryバインドDNのパスワード(デフォルトはなし)。

-enable

ポータル内のすべてのサブスクライバでDirectory Integration Platformを有効化します。このパラメータは、-disableパラメータに優先します。

-disable

ポータル内のすべてのサブスクライバでDirectory Integration Platformを無効化します。

G Oracle Portalのトラブルシューティング

この付録では、Oracle Portalの使用中に発生する可能性のある一般的な問題と、それらの解決方法について説明します。また、Oracle Portalの問題の診断方法について詳細な手順を示します。次のトピックが含まれます:

- 問題と解決策

- Oracle Portalの問題の診断

- さらにサポートが必要な場合

G.1 問題と解決策

この項では、一般的な障害と解決策について説明します。次のトピックが含まれます:

- Oracle Portalにアクセスできない

- Oracle Portalにログインできない

- カテゴリ・ページまたはパースペクティブ・ページ作成の問題

- Network Address Translation (NAT)設定の問題

- Oracle PortalとOracle Internet Directoryのユーザーおよびグループ情報が一致しない

- Oracle Portalのパフォーマンスの問題

- Webフォルダ作成時のエラー

- 「新規ユーザーの作成」および「新規グループの作成」ポートレットが表示されない

- error_logファイルのORA-2000xエラー

- 動的DNS環境でのリモートWebプロバイダのタイムアウト

- メモリー使用量の多い操作に関連する問題

- Oracle Textの索引を作成できない

- ヘルプの複数言語サポートの問題

- ポータル・ページに古いスタイルシートのデータが表示される

- ポータル・ページに古いコンテンツが表示される

- ポータル・ページにイメージが表示されない

- ハンドルされていない例外エラー

- OmniPortletプロバイダの構成の問題

- OmniPortletプロバイダのOracle Web Cacheの構成における問題

- モバイル・デバイスからOracle Portalへのアクセスに関する問題

- Oracle Portal 3.0.9または9.0.4からのアップグレード後のエクスポートおよびインポート時のエラー

- Oracle Portalの言語が中国語(繁体字)の場合に表示されるエラー

- アップロードされたコンテンツが検索で返されない

G.1.1 Oracle Portalにアクセスできない

たとえば、ページが表示されないか、「HTTP 503: サービスが使用できません」エラー、または「リクエスト処理中にエラーが発生しました。ブラウザをリフレッシュしてください。この問題が継続して発生する場合は、サイトの管理者にお問い合せください」エラーが発生します。

Oracle Portalでは、Oracle HTTP Server、Oracle Web Cache、Portalサービス、Oracle Metadata Repository、WLS_PORTALなどのOracle Fusion Middlewareコンポーネントが起動され、稼働中であることが必要です。これらのコンポーネントのいずれかが使用不能(停止中)である可能性があります。

問題1

Oracle HTTP Serverが停止中です。

解決策1

Fusion Middleware Controlで、Oracle Portalのホーム・ページを表示します。詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。

Oracle HTTP Serverが稼働中であるかどうかを確認します。Oracle HTTP Serverのステータスが、Oracle Fusion Middleware Controlホーム・ページの「Fusion Middleware」ペインに表示されます。

図G-1 HTTP Serverのステータス

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、Fusion Middleware ControlからOracle HTTP Serverを起動します。

Fusion Middleware Controlを使用してOracle HTTP Serverを起動するには、次の手順を実行します。

1. ナビゲーション・ペインで「Web層」を開いて、HTTP Serverを選択します(デフォルトではohs1)。

2. 「ohs1」を右クリックして、「制御」→「起動」を選択してOracle HTTP Serverを起動します。

Oracle HTTP Serverが正常に起動した場合は、ポータルにアクセスできるかどうかを確認します。

Oracle HTTP Serverを起動できない場合は、Log Viewerを使用してOracle HTTP Serverのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。

Log Viewerを使用していない場合は、ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\access_logディレクトリおよびORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\console~OHS~1.logディレクトリにある関連のエラー・ログ・ファイルを確認します。

関連項目:

Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

問題2

Oracle Web Cacheが停止中です。

解決策2

Oracle Web Cacheプロセスが実行されているOracle PortalのFusion Middleware Controlに移動します。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

Oracle Web Cacheが稼働中であるかどうかを確認します。Oracle Web Cacheのステータスは、Fusion Middlewareの「システム・コンポーネント」表に表示されます。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、Fusion Middleware Controlを使用してOracle Web Cacheを起動します。

Fusion Middleware ControlでOracle Web Cacheの監視および管理のページにアクセスするには、Fusion Middlewareの「システム・コンポーネント」表の「Webキャッシュ」をクリックします。

Oracle Web Cacheが正常に起動した場合は、ポータルにアクセスできるようになったかどうかを確認します。

Oracle Web Cacheを起動できない場合は、Oracle Web Cacheのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。

Log Viewerを使用していない場合は、ORACLE_INSTANCE\diagnostics\logs\WebCache\wc1\access_logディレクトリおよびORACLE_INSTANCE\diagnostics\logs\WebCache\wc1\event_logディレクトリにある関連のエラー・ログ・ファイルを確認してください。

問題3

Portal DADの構成が不正なため、Oracle Portalが稼働していません。

解決策3

Oracle Portal DADのステータスおよび構成を確認します。Fusion Middleware Controlで、Oracle Portalのホーム・ページに移動します。Oracle Portalホーム・ページで「設定」→「データベース・アクセス記述子」をクリックします。「データベース・アクセス記述子の構成」ページの「DAD」表で、ポータルに構成したDADが稼働しているかどうかを確認します。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、「DAD」表でDADの名前をクリックし、すべてのプロパティが正しく設定されていることを確認します。変更を保存し、WLS_PORTALとOracle HTTP Serverの両方を再起動して、変更を有効にします。ポータルのホーム・ページでDADを構成する方法については、第5.6.4項「Fusion Middleware Controlを使用したポータルDADの構成」を参照してください。

注意:

DADのデータベース接続の詳細は、ポータルのOracle Fusion Middlewareに関連付けられたOracleホーム・ディレクトリから、SQL*Plusを使用して確認できます。DAD設定のページには、パスワードが暗号化された形式で表示されるため、パスワードを再入力して、パスワードの有効性に問題がないことを確認します。

ポータルにアクセスできるようになったかどうかを確認します。

問題4

Oracle Metadata Repositoryが停止中です。

解決策4

Oracle Fusion Middleware Controlで、Oracle Portalのホーム・ページを表示します。詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。

「Portalによって使用されるOracle Metadata Repository」セクションを調べます。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、データベースを起動します。

データベースが正常に起動した場合は、ポータルにアクセスできるようになったかどうかを確認します。

問題5

WLS_PORTALサービスが停止中です。

解決策5

Oracle Fusion Middleware Controlで、Oracle Portalインスタンスのドメインのホーム・ページを表示します。詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

WLS_PORTALのステータスは、「システム・コンポーネント」表に表示されます。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、Oracle Fusion Middleware Controlを使用してWLS_PORTALを起動します。

Oracle Fusion Middleware ControlでWLS_PORTALの監視および管理のページにアクセスするには、次のいずれかの場所で「WLS_PORTAL」をクリックします。

- 「Parallel Page Engineサービス」ページ(Oracle Portalホーム・ページの「コンポーネント・ステータス」表からアクセス可能)

- Fusion Middlewareの「システム・コンポーネント」表

WLS_PORTALが正常に起動した場合は、ポータルにアクセスできるようになったかどうかを確認します。

WLS_PORTALを起動できない場合は、WLS_PORTALのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。

問題6

SQL* Netリスナーが停止中であるか、構成が間違っています。

解決策6

メタデータ・リポジトリがインストールされているホストで、SQL*NET TNSリスナーが稼働中であるかどうかを確認します。データベースが存在するコンピュータにログインします。現在のディレクトリが$PATHでない場合は、ORACLE_INSTANCE/binディレクトリに移動し、次のコマンドを使用して、TNSリスナーのステータスを確認します。

lsnrctl status

サービスが稼働していない場合は、次のコマンドでサービスを起動します。

lsnrctl start

サービスがすでに稼働している場合は、Oracle Databaseドキュメント・ライブラリの『Oracle Database Net Services管理者ガイド』を参照し、Oracle Net Servicesのトラブルシューティングの方法を確認してください。

問題7

Portalサービスが別のエラーをレポートしています。

解決策7

次の手順に従って、問題を解決します。

1. ORACLE_HOME/opmn/binに移動して、opmctl statusコマンドを発行します。キー・サービスのステータスが稼働中であることを確認します。稼働中でない場合は、ORACLE_HOME/opmn/logsの下にあるファイルで詳細を調べてください。

2. ORACLE_INSTANCE/webcache/logsに移動します。event_logファイルで、問題箇所を調べます。

G.1.2 Oracle Portalにログインできない

パブリック・ホームページにアクセスできるのに、ログインできません。この問題の一般的な現象は次のとおりです。

- 「ログイン」をクリックしても、ログイン・ページが表示されません。

- OracleAS Single Sign-Onのログイン・ページで資格証明を入力した後、エラーが発生します。

- 認証された後、Oracle Portalのページでエラーが発生します。

問題1

Oracle Portalへのログイン・プロセス中に発生した問題が原因で、Oracle Portalにログインできないと考えられます。

Oracle Portalのログイン・プロセスは、論理的に次の3つの部分に分けることができます。

- OracleAS PortalとOracle Single Sign-On間の通信

- Oracle PortalとOracle Internet Directory間の通信

- ホームページの割当て

解決策1

この問題の原因を診断するには、ログイン・プロセスの各部分に焦点をおいて解決策を調べます。

Oracle PortalとOracleAS Single Sign-On間の通信の検証

ログイン・プロセスの最初の部分を理解するために、Oracle Portalが次の場所でアクセスされると想定します。

http://www.company.com/portal/pls/portal/

パブリック・ホームページで「ログイン」をクリックすると、OracleAS Single Sign-Onのページにリダイレクトされます。たとえば、次のURLに変更されます。

http://login.company.com:4443/pls/sso

管理者から指定されたユーザー名とパスワードを入力して「ログイン」をクリックすると、ユーザー情報がOracleAS Single Sign-OnからOracle Portalに送り返されます。

ログイン・プロセスのこの部分で発生した問題の原因を診断するには、次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware ControlでOracleAS Single Sign-Onのホーム・ページを表示します。
OracleAS Single Sign-Onのホーム・ページには、Infrastructureホーム・ディレクトリ・インスタンスのホーム・ページからアクセスできます。

詳細は、『Oracle Application Server Single Sign-On管理者ガイド』の「スタンドアロン・コンソールのホームページの解説と使用方法」を参照してください。

2. Oracle HTTP Serverが稼働中であるかどうかを確認します。
「関連リンク」セクションに表示された「HTTP_Server」をクリックします。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、Oracle Fusion Middleware Controlを使用してOracle HTTP Serverを起動します。

Oracle Fusion Middleware ControlでOracle HTTP Serverの監視および管理のページにアクセスするには、次のいずれかの場所で「HTTP_Server」をクリックします。

- OracleAS Single Sign-Onのホーム・ページ

- Fusion Middlewareの「システム・コンポーネント」表

Oracle HTTP Serverが正常に起動した場合は、ログインできるようになったかどうかを確認します。

Oracle HTTP Serverを起動できない場合は、Oracle HTTP Serverのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。Log Viewerを使用していない場合は、次のディレクトリにある関連のエラー・ログ・ファイルを確認してください。

ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\access.log

3. OracleAS Single Sign-On DADのステータスおよび構成を確認します。
OracleAS Single Sign-Onのホーム・ページで、次の手順を実行します。

1. OracleAS Single Sign-Onのホーム・ページの「関連リンク」セクションで、「HTTP_Server」をクリックします。

2. 「管理」をクリックします。

3. 「PL/SQLのプロパティ」をクリックして、「DAD」セクションを確認します。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、「DAD」表でDADの名前をクリックし、すべてのプロパティが正しく設定されていることを確認します。変更を保存し、Oracle HTTP ServerとWLS_PORTALを再起動して変更を有効にします。

ログインできるようになったかどうかを確認します。

4. OracleAS Single Sign-Onスキーマが含まれるデータベースが稼働しているかどうかを確認します。
データベース情報は、Oracle Enterprise Manager 11g Fusion Middleware ControlのOracleAS Single Sign-Onのホーム・ページに表示されます。さらに詳しい情報を表示するには、ドリルダウンします。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、データベースを起動します。

データベースが正常に起動した場合は、OracleAS Single Sign-Onスキーマにアクセスできるようになったかどうかを確認します。

5. SQL* Netリスナーのステータスおよび構成を確認します。
ID管理リポジトリがインストールされているホストで、SQL*NET TNSリスナーが稼働中であるかどうかを確認します。データベースがあるコンピュータにログインします。現在のディレクトリが$PATHでない場合は、ORACLE_INSTANCE/binディレクトリに移動し、次のコマンドを使用して、TNSリスナーのステータスを確認します。

lsnrctl status

サービスが稼働していない場合は、次のコマンドでサービスを起動します。

lsnrctl start

サービスが稼働している場合は、Oracle Database 11gドキュメント・ライブラリのOracle Database Net Services管理者ガイドを参照し、返されたエラー番号を確認して、適切な処置を取ります。

Oracle PortalとOracle Internet Directory間の通信の検証

Oracle Portalのログイン・プロセスの2つ目の部分では、OracleAS Single Sign-Onから提供された資格証明を使用して、Oracle PortalがOracle Internet Directoryからグループ・メンバーシップ情報を取得します。

ログイン・プロセスのこの部分で発生した問題の原因を診断するには、Metadata Repositoryのログを確認します。

ホーム・ページの割当ての検証

Oracle Portalのログイン・プロセスの最後の部分では、グループ・メンバーシップに基づいて、ユーザーが適切なOracle Portalのホーム・ページにリダイレクトされます。ホームページのプリファレンスは、システム、グループまたはユーザーのレベルで指定されます。

ユーザーにホーム・ページが指定されている場合は、ログイン時にそのホーム・ページが表示されます。ホーム・ページが指定されていない場合でも、ユーザーがデフォルト・グループに属していて、そのデフォルト・グループにホーム・ページが指定されていれば、そのホーム・ページが表示されます。ユーザーにホーム・ページが指定されておらず、ユーザーがデフォルト・グループに属していないか、またはデフォルト・グループにホーム・ページが指定されていない場合は、システム・レベルのデフォルトのホーム・ページが表示されます。

問題の原因を診断するには、ユーザー、グループまたはシステムのレベルで、ホームページの「表示」権限がユーザーに付与されているかどうかを確認します。

ホームページを表示するには、そのページを表示する権限が必要です。権限は次のいずれかに付与できます。

- ユーザー

- ユーザー・グループ

- パブリック

これらのどのレベルにもページを表示する権限が付与されていない場合は、「WWC-44131: この操作を行う権限がありません。」というエラー・メッセージが表示されます。

グループまたはシステムのレベルで、ユーザーが属するグループにページを表示するための正しい権限が付与されているかどうかを管理者に確認します。

ポータル管理者は、次の手順を実行して、ユーザーのホーム・ページを指定する必要があります。

- ユーザーのプロファイルを編集し、ユーザーのデフォルト・ホームページとデフォルト・グループを見つけます。

- デフォルト・ホームページがユーザーにすでに指定されている場合は、ここで終了します。そうでない場合は、デフォルト・グループのグループ・プロファイルを編集し、デフォルト・ホームページが指定されているかどうかを確認します。

- デフォルト・ホームページがデフォルト・グループに指定されている場合は、ここで終了します。そうでない場合は、「グローバル設定」ページからデフォルト・ホームページを確認します。

ホームページを確立したら、次に、そのページに付与されている権限を調べます。ページを編集して、「アクセス」をクリックします。パブリックでページが表示できるかどうかを確認します。さらに、権限受領者のリストを調べます。ユーザーまたはユーザーが属するグループに、そのページに対する「表示」またはそれ以上の権限が付与されているかどうかを確認します。必要に応じて、適切な権限を付与します。ユーザーがメンバーであるグループに権限が付与されている場合は、そのユーザーの名前がメンバー・リストに表示されていることを確認します。

G.1.3 カテゴリ・ページまたはパースペクティブ・ページ作成の問題

カテゴリ・ページまたはパースペクティブ・ページの作成時に、次のエラーが発生する場合があります。

- WWS-32022:The category has been created but it was not possible to place the search portlets onto the category page. The category page will not show the items or pages in the category.

- WWS-32023:The perspective has been created but it was not possible to place the search portlets onto the perspective page. The perspective page will not show the items or pages in the perspective.

問題

ページ・グループにカテゴリを作成すると、カテゴリ・テンプレートに基づいてカテゴリ・ページが作成されます。同様に、パースペクティブを作成すると、パースぺクティブ・テンプレートに基づいてパースペクティブ・ページが作成されます。これらの基になるカテゴリまたはパースペクティブのテンプレートを変更した場合は、新しいカテゴリまたはパースペクティブを作成すると、前述のいずれかのメッセージが表示されることがあります。

解決策

これらのエラーのいずれかが表示された場合は、現在のカテゴリまたはパースペクティブのテンプレートを削除してから、スクリプトを実行して次の操作を行います。

- 現行のカテゴリまたはパースペクティブのテンプレートを元のバージョンに置き換えます。

- 現行のテンプレートに基づいたカテゴリ・ページまたはパースペクティブ・ページを再作成します。これは、すべてのページ・グループにも、特定のページ・グループにも実行できます。

これにより、すべての新しいカテゴリ・ページまたはパースペクティブ・ページがエラーなしで作成され、すべての既存のカテゴリ・ページまたはパースペクティブ・ページに、関連付けられたアイテムおよびページが予想どおりに表示されます。

これらのスクリプトの検索場所と実行方法の詳細は、第B.8項「カテゴリおよびパースペクティブ・スクリプトの使用」を参照してください。

G.1.4 Network Address Translation (NAT)設定の問題

第6.3項「ロード・バランシング・ルーターを使用する複数の中間層の構成」の手順に従った後、次のエラーが発生します。

Timeout occurred while retrieving page metadata

問題

NATバウンスバック・ルールがLBRに対して正しく設定されていない場合、複数の中間層を構成する際に、ループバック・リクエストに対するレスポンスが削除され、Oracle Portalのページがタイムアウトになります。

解決策

NATバウンスバック・ルールは、LBRごとに異なる内容になります。詳細は、LBRの構成ガイドを参照してください。正常なループバック通信を実現するためにLBRに追加の構成が必要になる理由の詳細は、第6.3項「ロード・バランシング・ルーターを使用する複数の中間層の構成」を参照してください。

G.1.5 Oracle PortalとOracle Internet Directoryのユーザーおよびグループ情報が一致しない

Oracle Portalのユーザーおよびグループ情報が、Oracle Internet Directoryの情報と一致しません。

問題

Oracle Internet Directoryからの変更が、Oracle Portalに伝播されません。Oracle Portalでは、ユーザーまたはグループの権限情報が変更されたときに通知を受けるために、プロビジョニング・プロファイルを使用します。これにより、Oracle Portalの認可情報をOracle Internet Directoryに格納されている情報と一致させておくことが可能になります。デフォルトでは、このプロビジョニング・プロファイルは有効です。

解決策

次の手順を実行して、この問題の原因を診断します。

1. プロビジョニングが有効かどうかを確認します。
次の手順を実行して、プロビジョニングが有効かどうかを確認します。

1. Oracle Portalにログインします。「管理」タブをクリックします。「Portalビルダー」ページで、「サービス」の下の「グローバル設定」をクリックします。

2. 「SSO/OID」タブをクリックして、「ディレクトリ同期」セクションまでスクロールします。このセクションで、ディレクトリ同期を有効にするかどうかを指定できます。「ディレクトリ同期の有効化」が選択され、デフォルトでイベント通知の送信頻度n秒が300秒に設定されている必要があります。

3. 「ディレクトリ同期」セクションが表示されていない場合、または「ディレクトリ同期の有効化」のチェック・ボックスが選択されていない場合、プロビジョニング・プロファイルは有効になっていません。「ディレクトリ同期の有効化」チェック・ボックスを選択してから、「OK」または「適用」をクリックして、プロビジョニング・プロファイルを有効にします。

エラーが発生した場合は、次の例に示すように、oidprovtoolツールを使用してプロビジョニング・プロファイルを再作成する必要があります。

oidprovtool operation=create ldap_host=myhost.mycompany.com ldap_port=389 \
ldap_user_dn="cn=orcladmin" ldap_user_password=welcome1 application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \
interface_type=PLSQL interface_connect_info=myhost:1521:iasdb:PORTAL:password \
schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
profile_mode=OUTBOUND

2. Oracle Directory Integration Platformが起動され、稼働しているかどうかを確認します。
これを行うには、次の手順を実行します。

1. Oracle Enterprise Manager 11g Fusion Middleware Controlを表示します。詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。ポータルに関連付けられたInfrastructureホーム・ディレクトリのOracle Fusion Middleware Controlに移動します。

2. Oracle Internet Directoryのステータスは、Fusion Middlewareのページに表示されます。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、Fusion Middleware Controlを使用してOracle Internet Directoryを起動します。

Oracle Fusion Middleware ControlでOracle Internet Directoryの監視および管理のページにアクセスするには、Fusion Middlewareの「システム・コンポーネント」表の「OID」をクリックします。

Oracle Internet Directoryが正常に起動した場合は、次の手順に進みます。

Oracle Internet Directoryを起動できない場合は、Oracle Internet Directoryのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。

3. Oracle Directory Integration Platformが稼働中であるかどうかを確認します。
Fusion Middlewareの「システム・コンポーネント」表の「OID」をクリックします。その次のページで、「ステータス」セクションの「ディレクトリ統合」をクリックします。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、Oracle Enterprise Manager 11gのFusion Middleware Controlを使用してOracle Directory Integration Platformサーバーを起動します。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Management統合ガイド』のOracle Directory Integration and Provisioningサーバーの管理に関する項

- 『Oracle Fusion Middleware Oracle Identity Management統合ガイド』のOracle Directory Integration and Provisioningサーバーの診断に関する項

3. トレース・ログ・ファイルと監査ログ・ファイルの内容を確認します。
変更が伝播されると、結果がトレース・ファイルと監査ファイルに書き込まれます。これらのファイルの内容を確認することで、伝播の失敗についての追加情報が得られます。次の手順を実行して、これらのファイルの内容を確認します。

1. Oracle Directory Integration Platformサーバーが稼働しているコンピュータにログインします。
通常、Oracle Internet DirectoryがインストールされているコンピュータにはOracle Directory Integration Platformサーバーがあります。

2. トレース・ログ・ファイルと監査ログ・ファイルを調べます。
ORACLE_INSTANCE/ldap/odi/log/ディレクトリに移動します。

各プロビジョニング・プロファイルには、ログ・ディレクトリの*.trc(トレース)ログ・ファイルと*.aud(監査)ログ・ファイルの2つの関連ファイルがあります。

デフォルトでは、トレース・ログ・ファイルには300秒ごとに生成されたエントリが保存されます。これは、イベント通知の送信頻度n秒のデフォルト値が300に設定されているためです。このファイルには、Oracle Directory Integration Platformで記録された最新情報のログのほかに、発生したエラーもすべて保存されます。トレース・ログ・ファイルは、一定時間が経過すると再利用されます。

監査ログ・ファイルには、プロビジョニング・プロファイルに伝播されたすべての変更の履歴が含まれています。監査ログ・ファイルに記録されるメッセージの例を次に示します。

Tue Jun 19 17:07:30 GMT 2004  -  Audit Log Start
-----------------------------------------------------
Group Exists Check - DN : cn=super_users,cn=ASDB.COMPANY.US.COM,cn=Database
Instances,cn=SES,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
mpany,dc=com ,GUID (CE0D473B93B521FAE0340003BA109AC2) - Response :
=============Event ID : 2320 - (GROUP_MODIFY)=============
Source     : orclapplicationcommonname= ASDB.COMPANY.COM,cn=database
instances,cn=ses,cn=portal,cn=products,cn=oraclecontext
Time       : 20031209170036z
Object Name: super_users
Object GUID: CE0D473B93B521FAE0340003BA109AC2
Object DN  : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database
Instances,cn=ses,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
mpany,dc=com
AttrName     -      OpType     -     Value
-------------------------------------------
uniquemember    -     ADD    -
cn=portal,cn=users,dc=us,dc=company,dc=com
EVENT_NTFY Response : 1
2320 : Success : 2 : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database
Instances,cn=ses,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
mpany,dc=com
-----------------------------------------------------

伝播情報はトレース・ログ・ファイルに書き込まれ、定期的に監査ログ・ファイルに追加されます。変更が正しく伝播されると、トレース・ログ・ファイル内のタイム・スタンプが更新されます。

- 変更が正しく伝播されているのに、Oracle Portalに反映されていない場合は、「変更が正しく伝播されているか」に進んでください。

- トレース・ログ・ファイルと監査ログ・ファイルが見つからない場合は、次の手順を実行して、プロビジョニング・プロファイルが存在するかどうかを確認します。

1. Oracle Portalにログインします。「管理」タブをクリックします。「Portalビルダー」ページで、「サービス」の下の「グローバル設定」をクリックします。

2. 「SSO/OID」タブをクリックして、「ディレクトリ同期」セクションまでスクロールします。このセクションで、ディレクトリ同期を有効にするかどうかを指定できます。「ディレクトリ同期の有効化」が選択され、イベント通知の送信頻度n秒がデフォルトで300秒に設定されている必要があります。

3. これらの値が設定されていない場合は、次の項で説明するように、プロビジョニング・プロファイルを作成する必要があります。

ORACLE_INSTANCE/ldap/odi/log/ディレクトリでトレース・ログ・ファイルと監査ログ・ファイルが見つからない場合は、プロビジョニング・プロファイルが削除された可能性があります。プロビジョニング・プロファイルを再作成するには、oidprovtoolツールを次のように実行します。

ldap_user_dn="cn=orcladmin" ldap_user_password=welcome1 application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \
interface_type=PLSQL interface_connect_info=myhost:1521:iasdb:PORTAL:password \
schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
profile_mode=OUTBOUND

変更が正しく伝播されているか

変更が正しく伝播されるかどうかを診断するには、Oracle Internet DirectoryでOracle Portalを使用して、ユーザーの作成、削除、再作成を順に実行します。これを行うには、次の手順を実行します:

1. 「管理」タブをクリックします。

2. 「ユーザー」から「新規ユーザーの作成」をクリックします。

3. ユーザーのプロファイルを編集します。

4. ユーザーを削除します。

5. 同じ名前でユーザーを再作成します。

間隔(メッセージの「イベント通知の送信頻度」に指定した時間)の間待機します。待機時間を最小にするには、この値を300秒未満に再設定します。その後、新規作成したユーザーとしてログインします。ログイン時に次のエラーが表示された場合は、Oracle Internet DirectoryからOracle Portalに情報が伝播されていません。

Error "WWC-41742: There is a conflict with your assigned user name. There is a user entry with this name, but with a different globally unique identifier (GUID), which must be resolved before you can log on with this name. Please inform your administrator."

情報が伝播されない場合、Oracle Portalでは、同じユーザー名が異なるGUIDで格納されているため、このエラーがスローされます。

変更が正しく伝播されない場合は、Oracle Directory Integration Platformに問題があるか、またはOracle Directory Integration PlatformによるOracle Portalの構成に問題があると思われます。Oracle Portal構成の問題である場合は、ptlconfigツールを次のように実行します。

ptlconfig -dad <dad> -dipreg

G.1.6 Oracle Portalのパフォーマンスの問題

Oracle Portalでは、ページのロードが遅いなど、パフォーマンスの問題が発生する場合があります。

ポータルが遅くなるには、いくつかの理由が考えられます。これらの問題の一部をここで説明します。

問題1

キャッシュができません。

解決策1

- Oracle Fusion Middleware Controlを使用して、第5.6.6項「Fusion Middleware Controlを使用したポータル・キャッシュの構成」で説明しているように、Portalの「キャッシング」オプションが「オン」に設定されていることを確認します。

問題2

ページ・メタデータがOracle Web Cacheにキャッシュされません。Oracle Portalのバージョンを確認するために中間層からOracle Portalスキーマに行われた最初の一度かぎりのコールが失敗した可能性があります。

解決策2

この問題を解決するには、次のタスクを実行します。

1. ページ・メタデータがOracle Web Cacheにキャッシュされていないことを確認します。これを行うには、次の手順を実行します。

- ページのURLの末尾に&_debug=1を追加してブラウザを更新し、Oracle Web Cacheページ・メタデータのキャッシュのステータスがMISS, NON-CACHEABLEになっているかどうかを確認します。

2. すべてのWLS_PORTALインスタンスを再起動します。

3. ステップ1を再び実行し、ページ・メタデータがOracle Web Cacheにキャッシュされるようになったかどうかを確認します。

問題3

接続プールの再利用が少ないかまったくありません。

解決策3

Fusion Middleware ControlのMBeanブラウザを使用して、MaxRequestsPerSessionパラメータを1000に設定します。

注意:

MaxRequestsPerSession属性が1に設定されていないことを確認してください。設定されていると、接続プーリングが無効になります。MaxRequestsPerSession属性の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

MaxRequestsPerSession属性を変更するには、次の手順を実行します。

1. 適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

2. 「ファーム」メニューから、「管理」→「システムMBeanブラウザ」を選択します。

3. 検索機能を使用してMBeanの属性PlsqlMaxRequestsPerSessionを検索するか、またはナビゲーション・ペインを使用して「MBean」→「oracle.mas.config」→「PortalConfig」→「pls/portal」を開きます。

4. 「属性」タブで、PlsqlMaxRequestsPerSession属性までスクロールしてクリックします。

5. 属性値を「1000」にリセットし、「OK」をクリックします。

6. Oracle HTTP ServerとWLS_PORTALを再起動します。
Oracle HTTP ServerとWLS_PORTALのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。

問題4

サイトが応答していません。

解決策4

WebCacheおよびOHSのログの診断メッセージを確認して、これらのOracleコンポーネントを調整する必要がないかどうかを調べます。

Oracle Fusion Middleware ControlのMBeanブラウザ
属性を変更するには、次の手順を実行します。

1. 適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。

2. 「ファーム」メニューから、「管理」→「システムMBeanブラウザ」を選択します。

3. 検索機能を使用してMBeanの属性を検索するか、またはナビゲーション・ペインを使用して「MBean」→「oracle.mas.config」→「PortalConfig」→「グローバル」を開きます。

4. 「属性」タブで、当該の属性までスクロールしてクリックします。

5. 属性値をリセットし、「OK」をクリックします。

6. Oracle HTTP ServerとWLS_PORTALを再起動します。
Oracle HTTP ServerとWLS_PORTALのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。

問題6

ディスクの入出力が分散されません。

解決策6

次のような多くのコンポーネントが常にディスクにアクセスしています。

- Oracle HTTP Serverのアクセス・ログおよびエラー・ログ

- Portalのキャッシュされたコンテンツ

- Webコンテンツ・サービス

- その他のローカル・アプリケーション

これらのコンポーネントはすべて、ファイル・システムのリソースを確保するために競合します。入力または出力のボトルネックを減らすには、物理ディスク間で分散処理が確実に行われるようにします。

問題7

ネットワーク・ホップが多すぎます。通常、次のいずれかの問題が発生します。

- クラスタ化されたOracle HTTP Server環境で、PPEループバックが構成されません。

- サーブレット・エンジンが、Oracle HTTP Serverでもmod_weblogicでもないコンピュータで稼働します。

- Infrastructureのコンポーネントが、複数のルーターがある広いネットワーク間で稼働しています。

解決策7

前述の問題について回避または対処することにより、ネットワーク・ホップ数を減らすようにします。

問題8

コンテンツの提供にHTTPSプロトコルを使用します。

保護が不要な普通のコンテンツにHTTPSを使用するようにポータルを構成している可能性があります。

解決策8

HTTPSの不要な使用を避けます。ほとんどの場合、HTTPで十分です。セキュアな環境が実際に必要な場合は、HTTPSとSSL (Secure Socket Layer)を管理するリバース・プロキシ・ハードウェアを使用します。詳細は、第6.6項「リバース・プロキシ・サーバーを使用するためのOracle Portalの構成」を参照してください。

関連項目:

- 第7.3.2.1項「Oracle PortalのSSLの構成」

- Oracle Fusion Middleware Java EEエンタープライズ・デプロイメント・ガイド

問題9

提示された解決策の作業をすべて実行したにもかかわらず、Oracle Portalの速度が遅いままです。

解決策9

- Oracle Portal、Oracle Portalのホストおよび関連コンポーネントのメトリック情報を確認します。
Oracle Portalに必要なすべてのコンポーネントが予想どおりに稼働している場合は、次の手順としてOracle Fusion Middleware Controlでメトリック情報を確認します。この情報を確認することにより、問題を特定できる場合があります。

ポータルのホーム・ページの「すべてのメトリック」をクリックし、メトリック情報を確認します。他の関連コンポーネント(Oracle Web Cache、Oracle HTTP Serverなど)のホーム・ページ上で、これを繰り返します。

- Oracle Portal Diagnostics Assistantを実行します。
Oracle Portal Diagnostics Assistantを使用して生成されたレポートを調べると、ポータル関連の問題を診断できます。詳細は、第G.2.5項「Oracle Portal Diagnostics Assistantの使用」を参照してください。

関連項目:

- 詳細は、OTN(http://www.oracle.com/technology/products/ias/portal/performance_10g1014.html)にあるOracle Portalのパフォーマンスに関するページを参照してください。

- OTNにあるパフォーマンス監視スクリプトのzipファイル(http://www.oracle.com/technology/products/ias/portal/files/portal_performance.zip)

- Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド

- Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

注意:

パフォーマンス監視スクリプトのzipファイルは、Oracle Fusion Middlewareのインストールの一部としても入手できます。

G.1.7 Webフォルダ作成時のエラー

Oracle PortalでWebフォルダを作成しようとすると、Webサーバーのエラー・ログ・ファイルにORA-20504エラーが生成されます。

問題

wwdav$path表とwwdav$asl表が壊れています。

解決策

表に値を再び移入するには、DAVローダー(wwdav_loader)・ユーティリティを実行する必要があります。SQL*Plusから次のプロシージャを実行することで、DAVローダー・ユーティリティを実行できます。

set serveroutput on size 1000000
begin
wwdav_loader.create_dav_content;
end;

これによりすべてのDAVデータが再作成されます。さらに多くのデバッグ情報を取得するには、次のプロシージャも使用できます。

set serveroutput on size 1000000
begin
wwdav_loader.create_dav_content(
p_debug_mode => true);
end;

DAVローダーの実行により、DAV表から一時ドキュメントと、ドキュメントに対するロックが削除されます。承認のために送信されたアイテムは、受け入れられるか拒否されるまで、DAVローダーには表示されなくなります。

今後、DAVスキーマにデータの破損があるかどうかを調べるには、DAV Reportユーティリティを使用できます。このユーティリティを使用するには、次の手順を実行します。

1. ディレクトリをORACLE_HOME/upgrade/portal/admin/plsql/wwu/に変更します。ここにdavreprt.sqlファイルがあります。

2. PORTALスキーマ・ユーザーとしてSQL*Plusにログインします。

3. DAV Reportユーティリティを次のように実行します。

davreprt.sql

これにより、一連のテストが実行されます。すべてのテストに合格すると、DAVスキーマには既知のデータの破損が見つからなかったことになります。いずれかのテストに失敗した場合は、DAVローダーを実行して、データの破損を修正する必要があります。

G.1.8 「新規ユーザーの作成」および「新規グループの作成」ポートレットが表示されない

「新規ユーザーの作成」ポートレットと「新規グループの作成」ポートレットは、ユーザー権限に基づいて表示されます。ポートレットは、様々な理由から表示されないことが考えられます。

問題1

十分な権限がありません。

解決策1

Delegated Administration Serviceセルフサービス・コンソールを使用して、ユーザーおよびグループを管理できるかどうかを確認します。必要な権限を持っていない場合は、必要な権限を付与するように管理者に要求します。しかし、セルフサービス・コンソールからこれらの操作を正常に実行できた場合は、次の2つの問題に関連している可能性があります。問題について管理者に通知してください。

問題2

Oracle Internet Directoryが停止中か、Oracle Internet Directoryのグループ情報が間違っています。

解決策2

Oracle Internet Directoryのグループ・メンバーシップ情報が間違っているか、Oracle Internet Directoryが起動されず、稼働中でない場合は、次の手順を実行して、この問題の原因を診断します。

1. Oracle Enterprise Manager 11gのFusion Middleware Controlで、ポータルのホーム・ページを表示します。詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。ポータルに関連付けられたInfrastructureホーム・ディレクトリのOracle Fusion Middleware Controlコンソールに移動します。
Oracle Internet Directoryが稼働中であるかどうかを確認します。Oracle Internet Directoryのステータスは、「Fusion Middleware」ページに表示されます。

- ステータスが「稼働中」の場合は、次の手順に進みます。

- ステータスが「停止中」の場合は、Oracle Fusion Middleware Controlコンソールまたはコマンドラインを使用してOracle Internet Directoryを起動します。
Oracle Fusion Middleware ControlコンソールでOracle Internet Directoryの監視および管理のページにアクセスするには、Fusion Middlewareの「システム・コンポーネント」表の「Oracle Internet Directory」をクリックします。

Oracle Internet Directoryが正常に起動した場合、「新規ユーザーの作成」ポートレットと「新規グループの作成」ポートレットが表示されるかどうかを確認します。

Oracle Internet Directoryを起動できない場合は、Oracle Internet Directoryのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。

問題3

Oracle PortalとOracle Internet Directoryの接続構成が間違っています。

解決策3

Enterprise Managerにログインして、「ポータル・ワイヤ構成」ページで正しいOIDパラメータが入力されていることを確認します。

G.1.9 error_logファイルのORA-2000xエラー

Oracle Portalへのログインを試みると、ORACLE_INSTANCE/diagnostics/logs/OHSComponent/ohs1ディレクトリにある診断ログ・ファイルに、次のいずれかのエラーが生成されます。

- ORA-20000: 「有効なセッションを介さずにセッション・コンテキストにアクセスしようとしました。」
このエラーは、そのブラウザ・セッションに関連付けられたOracle Portalセッションが中断または消去されたか、またはセッションCookieそのものが見つからないことを示します。

- ORA-20001: 「セッションCookieが破損しているため、セッション情報を取得できません。ブラウザを閉じてから再接続してください。」
このエラーは、セッションCookieが壊れているか、無効であることを示します。

- ORA-20005: 「セッションに非アクティブのマークが付けられているため、セッション・コンテキストを復元できませんでした。」
このエラーは、セッションCookieが非アクティブなセッションを指定している場合に発生します。ブラウザから送られたCookieは、セッションに格納されているCookieと一致しますが、セッションはアクティブではありません。

- ORA-20006: 「Cookieの値がセッション・リポジトリに格納されている値と一致しないため、セッション・コンテキストを復元できませんでした。」
このエラーは、ブラウザから送られたCookieと、セッションに格納されているCookieの間に不一致があることを示します。

注意:

これらのエラーのいくつかが発生するものと理解しておいてください。発生する例外が異常な数にのぼる場合のみ、オラクル社カスタマ・サポート・センターに問題を報告してください。詳細は、第G.3項「さらにサポートが必要な場合」を参照してください。

これらのエラーの詳細は、次の各項で説明します。

ORA-20000「有効なセッションを介さずにセッション・コンテキストにアクセスしようとしました。」

このエラーは、次のいずれかの問題によって発生します。

セッション行がない

各セッションCookieには、対応するセッションがあります。セッションを格納しているポータル・スキーマには、セッションに対応するセッションCookieの情報が含まれています。セッションには、セッションID、ユーザー名、セッション開始時刻、ユーザーがログインしているかどうか、ユーザーのログイン時刻、セッションがアクティブか消去用としてマークされているかどうか、などのデータが格納されています。ORA-20000エラーは、Cookieで指定されたセッションIDが、Oracle Metadata Repositoryのポータル・スキーマに格納されているセッションに存在しない場合に発生します。

セッションが消去される

Oracle Metadata Repositoryのポータル・スキーマから古いセッションを消去するために、バックグラウンド・ジョブが頻繁に実行されます。デフォルトでは、8日以上経過したセッションを消去するようにこのジョブが構成されています。バックグラウンド・ジョブにより消去されたセッションにアクセスしようとすると、ORA-20000エラーが発生します。詳細は、第B.4項「セッション・クリーン・アップ・ジョブの管理」を参照してください。

セッションCookieがない

Oracle Metadata Repositoryのポータル・スキーマで使用するために構成されたDADが複数あり、それらのDADで指定されたCookie名が同じでない場合、その名前はwwctx_cookie_info$表のcookie_name値になり、DADの1つを介して新規セッション作成のリクエストが受信されるたびに値が変わります。その結果、ORA-20000エラーが発生します。

ORA-20001 - 「セッションCookieが破損しているため、セッション情報を取得できません。ブラウザを閉じてから再接続してください。」

ORA-20001エラーは、次のいずれかの問題によって発生します。

Cookieが切り捨てられる

リクエストの送信中にブラウザの「停止」ボタンをクリックすると、Cookieが切り捨てられる場合があります。次回ブラウザにアクセスしたときに、サーバーはそのCookieを正しく復号化できません。

別のサーバーからのCookieが受信された

ドメイン全体のCookie範囲で構成された別のOracle Portalに最近アクセスした場合、ORA-20001エラーが発生する可能性があります。そのポータルのCookie名が、現在のポータルのCookie名と同じ場合、Oracle PortalはそのCookieを使用しようとします。しかし、ポータルのCookieはポータル固有のキーで暗号化されているため、Oracle PortalはそのCookieを復号化できず、Cookieが壊れているとみなして、ORA-20001エラーを生成します。

このネームスペースの衝突の問題を回避するには、これらのCookieの取得先を特定する必要があります。ブラウザを閉じると、セッションCookieがすべて消去されます。Cookieの取得先を確認するために、Cookieの警告を有効にしてブラウザを起動することにより、問題をデバッグできます。

Cookieの暗号化キーが変更される

Cookieは、DES3暗号化を使用して暗号化されます。暗号化キーは、Oracle Metadata Repositoryのポータル・スキーマに格納されます。その値は通常Oracle Portalのインストール時に設定され、その後変わりません。この値がインストール後に変更されると、未処理のセッションCookieを復号化できなくなります。また、このキーで暗号化されたその他の値も復号化できません。この値は変更しないように注意してください。

ORA-20005「セッションに非アクティブのマークが付けられているため、セッション・コンテキストを復元できませんでした。」

ORA-20005エラーは、セッションCookieで非アクティブなセッションを指している場合に発生します。ブラウザから送られたCookieは、セッションに格納されているCookieと一致しますが、セッションはアクティブではありません。これは、ログアウト・リクエストを発行していても、ブラウザでCookieがリセットされる前に別のリクエストが送信されたことを示しています(たとえば、他のユーザーが言語ポートレットから言語を変更するリクエストを送信した場合など)。

セッションが非アクティブとしてマークされている

ユーザーがログアウトする際、ポータル・スキーマに格納されているセッションが非アクティブの状態に更新される可能性があります。しかし、ブラウザの「停止」ボタンをクリックしても、そのCookieがユーザーのブラウザから消去されません。この状態になると、ブラウザから古いCookieが送信されるため、Oracle Portalは非アクティブなセッションを探そうとします。このような場合にORA-20000エラーが発生します。

ORA-20006「Cookieの値がセッション・リポジトリに格納されている値と一致しないため、セッション・コンテキストを復元できませんでした。」

ORA-20006エラーは、ブラウザから送られたCookieとセッションに格納されているCookieに不一致があることを示しています。これは、Cookieがあるリクエストに基づいて変更されたにもかかわらず、ブラウザでCookieが実際に更新される前に、ユーザーが別のリクエストを送信したときに発生する可能性があります。たとえば、ユーザーが言語ポートレットから言語を変更するリクエストを作成したのに、最初のリクエストが完了する前に別のリクエストを送信した場合などです。これはORA-20005エラーと似ていますが、Cookie自体にクライアントとサーバー間の不一致が含まれている点が異なります。

タイム・スタンプが一致しない

Cookieが正しく復号化されても、Cookie内のタイム・スタンプが関連セッション行内のタイム・スタンプと一致しない場合、Cookieは壊れているとみなされます。タイム・スタンプのこの不一致は、ユーザーが2回ログインを起動した場合、ネットワーク構成の問題またはセッション作成ロジックの不具合がある場合、あるいは悪質なセッション攻撃を受けた場合に発生する可能性があります。

G.1.10 動的DNS環境でのリモートWebプロバイダのタイムアウト

Oracle Portalの中間層とは異なるコンピュータにあるリモートWebプロバイダは、WLS_PORTALサービスが最初に起動されたときに稼働しますが、しばらくすると停止します。長いタイムアウト時間が経過した後、同じプロバイダからの各ポートレットのかわりに「エラー: ポートレットに接続できませんでした。」というメッセージが表示されます。ポートレットのタイムアウト時間のエラーは、WLS_PORTAL WLS_PORTAL-diagnostic.logファイルにも書き込まれます。WLS_PORTALを再起動すると、Webプロバイダは再び稼働しますが、限られた時間のみ稼働します。

問題

Webプロバイダがドメイン名からIPアドレスへのマッピングに動的DNS (DDNS)を使用していることがこの問題の原因である可能性があります。これは、Webプロバイダのドメイン名が解決されるIPアドレスが時間によって変化することを意味します。一方、Javaのデフォルトのキャッシュ・ポリシーでは、解決済のIPアドレスはそのまま永続的にキャッシュされたままとなります。つまり、DDNSを使用しているために、WebプロバイダのIPアドレスが変更された場合でも、Javaのキャッシュには古いIPアドレスが保持されています。

解決策

この問題を解決するには、リモートWebプロバイダのタイムアウトを防止する構成をWLS_PORTALで別途設定します。WLS_PORTALのsun.net.inetaddr.ttlシステム・プロパティを変更する必要があります。JDK 1.3以降では、sun.net.inetaddr.ttlシステム・プロパティを使用して、キャッシュされたIPアドレスに対する存続時間(TTL)を秒単位で指定できます。

例

1. 次のようにopmn.xmlファイルを編集します。

<java-option value="-server -Xincgc -Xnoclassgc -Xms256m -Xmx512m -Dsun.net.inetaddr.ttl=120"/>

2. opmnとそのすべてのサブプロセスを停止し、最新の構成の変更が有効になるように再起動します。
これを行うには、次のコマンドを実行します。

ORACLE_INSTANCE/opmn/bin/opmnctl stopall
ORACLE_INSTANCE/opmn/bin/opmnctl startall

G.1.11 メモリー使用量の多い操作に関連する問題

「ORA-04031: 共有メモリーの30192バイトを割当てできません」というエラーが表示されます。

問題

デフォルトでは、Oracle Fusion Middlewareのshared_pool_sizeの値は32MBです。次のようなメモリーの使用量が多い操作を実行する場合は、これが問題になることがあります。

- エクスポートまたはインポート

- Portalのフォームまたはレポートの作成

解決策

メモリーの使用量が多い操作を問題なく実行できるようにするには、shared_pool_sizeパラメータの値を大きくする必要があります。

データベース初期化パラメータの更新に関する手順が不明な場合は、Oracle Database 11gドキュメント・ライブラリのOracle Database管理者ガイドで、サーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する項を参照してください。

注意:

オプションの手順として、Oracle Portal Diagnostics Assistantを実行して、データベースの既存の値と推奨値のレポートを表示することをお薦めします。詳細は、「Oracle Portal Diagnostics Assistantの実行」を参照してください。

G.1.12 Oracle Textの索引を作成できない

Oracle Textの索引を作成しようとすると、次のエラーが発生する場合があります。

- CTXAPPロールをポータルに付与できません

- エラー: CTXSYSでのデータ・ストア・プロシージャの作成

- エラー: Oracle Textデータ・ストアの設定

- 予期しないエラーが発生しました。(WWS-32100)

問題

Oracle Textの索引を作成しようとすると、問題が発生します。

解決策

Oracle Textは、ポータル・スキーマと同じOracle Databaseのホーム・ディレクトリにインストールする必要があります。詳細は、第10.3.2項「Oracle Textの前提条件」を参照してください。

この問題を解決するには、次のいずれかのオプションを選択してください。

- データベースにアクセスし、Oracle Portalスキーマの所有者としてログインします。SQL*Plusを起動し、inctxgrn.sqlスクリプトを実行します。このスクリプトは、ORACLE_HOME\portal\admin\plsql\wwsディレクトリにあります。このスクリプトを実行すると、Oracle Textデータ・ストア・プロシージャが作成され、さらに、Oracle PortalスキーマにCTXAPPロールが付与されます。

- データベースへのアクセス権はあっても、inctxgrn.sqlスクリプトのコピーがない場合は、SQL*Plusを使用してスキーマ所有者としてデータベースに接続し、次のコマンドを実行します。

set serveroutput on size 10000
begin
wwv_context_util.grantCtxRole(user);
end;
@@sbrimtlx

(user)を、Oracle Portalスキーマの所有者(portalなど)に置き換えます。

G.1.13 ヘルプの複数言語サポートの問題

Oracle Portalで、オンライン・ヘルプの一部しか翻訳されていないように見えます。

問題

Oracle Portalでは、オンライン・ヘルプで複数言語を使用できます。しかし、状況依存ヘルプのトピックの一部しか、日本語以外の言語に翻訳されていません。

解決策

これは予想される動作です。

G.1.14 ポータル・ページに古いスタイルシートのデータが表示される

スタイルシートを編集したのに、ポータル・ページのコンテキストでスタイルシートをプレビューまたは表示すると、古いスタイルシートのデータが表示されます。

問題

スタイルシートに行った変更がポータル・ページに反映されていません。これは、Last-Modifiedヘッダーを生成する数値に、グリニッジ標準時(GMT)がタイムゾーンを調整しないまま付加されるためです。オリジナル・サーバーのタイムゾーンがGMTよりも先行している場合、生成されるLast-Modifiedヘッダーは、実際には将来の日付になります。

解決策

次のエラーが発生した場合は、『Oracle Application Server Portalエラー・メッセージ・ガイド』に説明されている診断手順を実行します。

WWC-40018: General invalidation message processing exception: %1
WWC-40019: Could not open web cache connection

これらの手順で問題が解決しない場合は、Oracle Web Cacheホストとデータベース・ホストで、日付、時刻およびタイムゾーンが現在の値に設定されていることを確認します。また、データベースのタイムゾーンが、データベース・ホストのタイムゾーンと一致する設定になっていることを確認します。データベースのタイムゾーンは、次の問合せを実行することで判別できます。

SQL> SELECT DBTIMEZONE FROM DUAL;

データベースのタイムゾーンがデータベース・ホストのタイムゾーンと異なる場合は、ALTER DATABASE SET TIME_ZONEコマンドを使用してデータベースのタイムゾーンをデータベース・ホストのタイムゾーンに設定し、データベースを再起動します。

例:

SQL> ALTER DATABASE SET TIME_ZONE = '-05:00';

変更された設定は、データベースを再起動するまで有効になりません。

G.1.15 ポータル・ページに古いコンテンツが表示される

ポータル・ページのコンテンツが更新されず、古いコンテンツが表示されます。

問題

ブラウザのキャッシュの設定が間違っている可能性があります。

解決策

ブラウザのキャッシュの設定が「なし」に設定されていないことを確認します。

この設定を確認するには、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』の「はじめに」でブラウザの推奨事項に関する項を参照してください。

G.1.16 ポータル・ページにイメージが表示されない

Oracle Portalの使用時に、次のような問題が発生する場合があります。

- イメージが表示されません。

- ポータルをログアウトした後、ブラウザを再起動しないとログインできません。

問題

ブラウザのイメージの設定が間違っている可能性があります。

解決策

イメージが自動的にロードされることを確認します。この設定を確認するには、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』の「はじめに」でブラウザの推奨事項に関する項を参照してください。

注意:

この設定は常に有効にすることをお薦めします。

G.1.17 ハンドルされていない例外エラー

Oracle Portalのアクセス時または使用時に、ハンドルされていない例外が発生する場合があります。たとえば、「エラー30526: ハンドルされていない例外が発生」などが発生します。

問題

Oracle Portalで、リカバリ不能なデータベース・エラーが発生します。

解決策

ハンドルされていない例外エラーの場合、エラーの実際の原因は不明です。考えられるエラーの原因について、より多くの情報を集めるには、トレース・ファイルを生成します。

トレースを有効にすると、トレース・ファイルはデータベース・パラメータuser_dump_destに指定されているディレクトリに生成されます。このディレクトリの名前を検索するには、次のいずれかのコマンドを使用します。

select value from v$parameter where name = 'user_dump_dest';

show parameter user_dump_dest;

トレース・ファイルを生成する手順については、第G.2.2項「トレース・ファイルの生成」を参照してください。これらのトレース・ファイルはフォーマットされません。フォーマットするには、tkprofユーティリティを使用します。

G.1.18 OmniPortletプロバイダの構成の問題

ポートレットを構築するためにOmniPortletプロバイダを構成すると、いくつかの問題が発生する場合があります。これらの問題の多くを解決するには、OmniPortletプロバイダのアプリケーション・ログ・ファイルWLS_Portal.logを確認する必要があります。このログ・ファイルは次の場所にあります。

DOMAIN_HOME\servers\WLS_PORTAL\logs

問題

必要なSSLライブラリがライブラリ・パスにありません。

OracleAS PDKがPortalインスタンスにインストールされている場合、次のエラーが発生する場合があります。

"java.lang.NoClassDefFoundError: at oracle.security.ssl.OracleSSLCipherSuite.isSSLLibDomestic when accessing HTTPS site with certificate"

解決策

SSLライブラリがライブラリ・パスにあることを確認します。詳細は、「HTTPSアクセス用のライブラリのコピー(PDK専用)」を参照してください。

G.1.19 OmniPortletプロバイダのOracle Web Cacheの構成における問題

ポータル・ページに古いポートレットの内容が表示され、ポートレット定義が反映されません。この問題は、Oracle Web Cache構成時の次のエラーによって発生する場合があります。

問題1

ポートの値がcache.xmlファイルに正しく指定されていません。次のエラーが発生する場合があります。

CONFIGURATION: Encountered a Cache Invalidation Exception.
oracle.net.http.HttpConfigurationException: Bad "port" value in configuration element "invalidation"

解決策1

正しいポート番号をcache.xmlファイルに設定します。

cache.xmlファイルのテンプレートのコピーは、ORACLE_INSTANCE/portal/conf ディレクトリにあります。ポートを指定するには、この構成ファイルを、次の例のイタリック体の部分が示すように変更してください。

<?xml version="1.0"?>
<webcache>
<invalidation
host="cache.abc.oracle.com"
port="4001"
authorization="0510198d5df8efd5779406342be2528aa0cccb179ea6b77baf49f019f5075a3a11"/>
</webcache>

問題2

cache.xmlファイルで認証値が暗号化されていません。次のエラーが発生する場合があります。

CONFIGURATION: Encountered a Cache Invalidation Exception.
oracle.net.http.HttpConfigurationException: Bad "authorization" value in configuration element "invalidation." String un-obfuscation error

解決策2

Oracle Web Cacheインスタンスの情報は、ORACLE_INSTANCE/portal/confディレクトリのcache.xmlファイルに維持されます。Web Cacheの無効化の設定が変更された場合は、このファイルを更新する必要があります。詳細は、第E.2.1.3項「キャッシュの構成(PDK専用)」を参照してください。

問題3

oracle.http.configfileシステム・プロパティが定義されていません。つまり、Web Cacheの無効化に関して構成ファイルが定義されていません。WLS_Portalインスタンスを起動したときに、次のエラーが発生する場合があります。

Error: CONFIGURATION: Provider Test Page: Web Cache Invalidation config file not defined by "oracle.http.configfile"

G.1.20 モバイル・デバイスからOracle Portalへのアクセスに関する問題

標準のデスクトップ・ブラウザと比べて、モバイル・デバイスには、詳細なエラー情報を表示する適切なインタフェースがありません。そのため、多くのエラー情報は、Oracle Application Server Wirelessログ・ファイルに記録されます。このログ・ファイルには、アクティビティ・ロガーと呼ばれるWebベースの監視ツールを使用してアクセスできます。アクティビティ・ロガーの使用方法の詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。

OracleAS Wireless経由でOracle Portalにアクセスすると、次のようなエラーが発生する場合があります。

- サービス・エラー

- 一時エラー

サービス・エラー

サービス・エラーは、ワイヤレス・サーバーにバックエンド・サーバーへのアクセスの問題がある場合に、OracleAS Wirelessサーバーによって生成されます。サービス・エラーは次のように表示されます。

Service Error

サービス・エラーは、次のいずれかの理由により生成されます。

- textまたはvnd.oracle.mobilexmlタイプではないドキュメントがOracleAS Wirelessサーバーに返されました。

- textまたはvnd.oracle.mobilexmlタイプのドキュメントがOracleAS Wirelessサーバーに返されましたが、コンテンツが無効なXMLです。

- textまたはvnd.oracle.mobilexmlタイプのドキュメントがOracleAS Wirelessサーバーに返されましたが、コンテンツが無効なOracleAS Wireless XMLです。

- エラー・ステータスがOracleAS Wirelessサーバーに返されましたが、ユーザーに返すことができる添付ドキュメントがありません。

一時エラー

一時エラーは、モバイル・デバイスにエラー・ドキュメントのレンダリングの問題がある場合に、Parallel Page Engine (PPE)によって生成されるメッセージです。一時エラーは次のように表示されます。

A temporary error has prevented Oracle Portal from servicing your request. (id=<nnnnn>)

値<nnnn>は、ログのエラーIDです。

標準のデスクトップ・ブラウザでは、エラー・ドキュメントをレンダリングすると、データベースへのメタデータのコールによって生成されたエラー・ドキュメントが、PPEによって取得され、ユーザーに渡されます。モバイル・デバイスでは、モバイル・リクエストに対してレンダリングされるドキュメントはOracleAS Wireless XMLである必要があるため、これは実行できません。

PPEがモバイル・リクエストを処理している場合、データベースが無効なOracleAS Wireless XMLのエラー・ドキュメントをレンダリングすると、PPEは次のタスクを実行します。

1. このドキュメントをDOMAIN_HOME\servers\WLS_PORTAL\logsディレクトリにあるサーブレット・エラー・ログ・ファイルに書き込みます。

2. 一意のIDをこのエラーに割り当てます。

3. 標準のエラー・テンプレートを次のフォーマットでユーザーに渡します。

A temporary error has prevented Oracle Portal from servicing your request. (id=<nnnnn>)

<nnnn>は、ログのエラーIDです。

サービス・エラーと一時エラーの問題および回避策

サービス・エラーと一時エラーの様々な問題および回避策については、次の項で説明します。

注意:

推奨される回避策を実行したら、キャッシュをクリアし、ブラウザを再起動してください。エラー・ページがキャッシュされていると、バックエンド・サービスにアクセスしたときに再びサービス・エラーが発生する可能性があるため、これは必ず実行してください。

問題1

Oracle Application Serverが正しく構成されていません。サービス・エラーが検出されます。

解決策1

Oracle Application Serverで、Oracle PortalとOracleAS Wirelessの構成を確認します。これらの設定の確認方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

問題2

モバイル・デバイスまたはシミュレータからOracle Portalへのアクセスが認証されていません。これは、ログオン時のセッションCookieの妥当性チェックで、IPアドレスの照合が失敗したことが原因と考えられます。サービス・エラーが検出されます。

解決策2

Cookieの妥当性チェックにおけるIPチェックの状態を変更します。

モバイル・デバイスまたはシミュレータからOracle Portalへアクセスして、サービス・エラーが発生するかどうかを確認します。

問題3

xml.validation.modeパラメータがTrueに設定されています。このパラメータがTrueに設定されていると、OracleAS Wirelessは、無効なXMLフォーマットのエラー・メッセージ・ファイルの妥当性チェックを試みます。サービス・エラーが検出されます。

解決策3

OracleAS Wirelessインスタンスで、次の場所にあるweb.xmlファイルのxml.validation.modeパラメータがFalseに設定されていることを確認します。

ORACLE_HOME/j2ee/OC4J_Wireless/applications/wdk/wdk-web/WEB-INF

モバイル・デバイスまたはシミュレータからOracle Portalへアクセスして、サービス・エラーが発生するかどうかを確認します。

問題4

OracleAS Wirelessの動作が変更されています。サービス・エラーが検出されます。

解決策4

OracleAS Wirelessサーバーで、任意のサービスを実行できるかどうか確認します。たとえば、モバイル・デバイスまたはシミュレータから、OracleAS Wirelessのサンプルを実行できるかどうかを確認します。詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。

- サンプルのサービスが動作しない場合は、OracleAS Wirelessを再インストールして、構成しなおす必要があります。詳細は、OracleAS Wirelessのドキュメントを参照してください。

- サンプルのサービスが正常に動作した場合は、OracleAS Wirelessサーバーのログ・ファイルでトラブルシューティング情報を調べます。ログ・ファイルには、問題の原因となっているポータル・サービスからのレスポンスに関する情報が格納されています。この情報を使用すれば、ポータルがエラー・ステータスまたは無効なOracleAS Wireless XMLを返していないかどうかを確認できます。

OracleAS Wirelessアクティビティ・ロガーの下部にある「ログの表示」をクリックして、OracleAS Wirelessサーバー・ログ・ファイルにアクセスします。ログ・ファイルの最後の500行が表示されます。ワイヤレス・サーバーのログ・ファイルは、ORACLE_INSTANCE/wireless/logs/ directory or the /var/tmp/ディレクトリにあります。

ログ・ファイルの情報に基づいて、修正手順を実行するか、またはオラクル社カスタマ・サポート・センターに問い合せます。

注意:

ログ・ファイルを表示するときは、表示行数を変更できますが、大きなログ・ファイルの情報を検索する場合は、オペレーティング・システムのvi、emacs、moreなどのコマンドを使用してファイルを表示することをお薦めします。

問題5

メタデータの取得時にエラーが発生します。一時エラーが検出されます。

解決策5

トラブルシューティング情報を確認するには、DOMAIN_HOME\servers\WLS_PORTAL\logsディレクトリにある、サーブレットのエラー・ログ・ファイルWLS_PORTAL-diagnostic.logにアクセスします。サーブレットのエラー・ログ・ファイルには、元のエラー・ドキュメントとそのヘッダーが記録されるため、問題が発生したときに標準のデスクトップ・ブラウザで利用できる情報と同僚の情報が格納されます。エラー・ログ・ファイルの情報を使用して、通常のOracle Portalのトラブルシューティング分析を行います。

問題6

モバイル・ブラウザでログイン・リンクをクリックすると、サービス・エラーが発生します。

解決策6

第5.7.1項および第5.7.2項に説明があるAS WirelessパッチおよびOracle SSOパッチが適用されていることを確認します。

G.1.21 Oracle Portal 3.0.9または9.0.4からのアップグレード後のエクスポートおよびインポート時のエラー

Oracle Portal 3.0.9または9.0.4からアップグレードした後に、Oracle Portalのエクスポートおよびインポートを実行すると、予期しないエラーが発生する場合があります。

問題1

トランスポート・セットにカテゴリまたはパースペクティブが含まれている場合は、カテゴリおよびパースペクティブのテンプレートに不適切なページ・タイプID (11ではなく1)が設定されていることにより、エラーが発生する場合があります。

解決策1

トランスポート・セットを確認します。カテゴリまたはパースペクティブが含まれている場合は、Oracle Portalのエクスポートおよびインポート・ユーティリティを実行する前に、次のスクリプトを実行して、この問題を修正します。

SQL> @pstpgcre.sql

このスクリプトは、ORACLE_INSTANCE/portal/admin/plsql/wws/pstpgcre.sqlにあります。このスクリプトを実行すると、カテゴリおよびパースペクティブのテンプレートとその関連ページが削除され、再作成されます。

カテゴリおよびパースペクティブのスクリプトの使用方法は、第B.8項「カテゴリおよびパースペクティブ・スクリプトの使用」を参照してください。

問題2

Oracle Portalを3.0.9からアップグレードすると、カテゴリ名とパースペクティブ名の末尾にpageidとsiteidが追加されます。これがポータル間のエクスポートとインポートに影響を与えています。たとえば、GENERALという名前のカテゴリをバージョン3.0.9からバージョン9.0.4にアップグレードし、さらにバージョン11.1.1にアップグレードすると、アップグレード後のカテゴリ名はGENERAL_12345_0になります。この場合の12345がpageidで、0がsiteidです。

同じカテゴリとパースペクティブでありながら、その名前がソースのポータルとターゲットのポータルで異なっている場合、ポータル間のエクスポートおよびインポートを実行すると、カテゴリまたはパースペクティブを検索するようにカスタマイズされている検索ポートレットから、カテゴリとパースペクティブの検索条件が失われます。

解決策2

ソースとターゲットのポータルで、カテゴリ名とパースペクティブ名が完全に一致していることを確認します。例:

- カテゴリ名とパースペクティブ名の末尾に追加されたIDを削除して、アップグレード前の名前に変更します。たとえば、GENERAL_12345_0を元のGENERALに変更します。

- または、新しいカテゴリ名とパースペクティブ名を指定します。指定した名前のカテゴリまたはパースペクティブがすでに存在する場合は、別の名前にするよう促すメッセージが表示されます。

注意:

ソースとターゲットの両方のポータルで同じ変更を行ってください。

G.1.22 Oracle Portalの言語が中国語(繁体字)の場合に表示されるエラー

ポータルの言語が中国語(繁体字)に設定されている場合、「カスタム検索」ポートレットなどのポートレットの操作時、またはナビゲータの使用時にエラーが発生することがあります。

問題

Oracle Metadata RepositoryデータベースのSHARED_POOL_SIZEに設定された値が小さすぎると、ポートレットの操作時にエラーが発生する可能性があります。

解決策

これに対処するには、Oracle Metadata RepositoryデータベースのSHARED_POOL_SIZEの値を大きくします。推奨される最小サイズは144MBですが、この設定は中国語(繁体字)には小さすぎます。SHARED_POOL_SIZEを216MB以上に増やしてみてください。

G.1.23 アップロードされたコンテンツが検索で返されない

ポータル・コンテンツをアップロードしており、そのコンテンツがOracle PortalのOracle Text検索を使用して返されない場合は、コンテンツの索引が適切に作成されておらず、検索可能な状態でない可能性があります。

問題

コンテンツがポータルにアップロードされていますが、検索したときに返されません。

解決策

アップロードされたコンテンツの索引が正しく作成されており、検索可能になっていることを確認してください。たとえば、フィルタが原因でドキュメントの索引が正しく作成されていないと、索引内にトークンが存在しないため、ドキュメント内の用語が索引内のトークンと一致せず、検索可能な状態になりません。

コンテンツの索引が正しく作成されており、検索可能な状態であることを確認するには、ファイルベースとURLベースのアイテム・タイプにMIMEタイプ属性および文字セット属性を追加(またはファイルベースとURLベースのアイテムを新規作成してこれらの属性を追加)し、コンテンツのアップロード時にMIMEタイプと文字セットを指定します。

G.2 Oracle Portalの問題の診断

Oracle Portalは、中間層とデータベース層で構成され、各層は多数のコンポーネントで構成されています。これらのコンポーネントは多数のコンピュータに分散でき、大量のリクエストを同時に処理することもできます。

Oracle Portalの機能の問題を分析および解決するために、Oracle Portal上で診断ツールを使用することもできます。

この項には次のトピックが含まれます:

- ECIDロギングの有効化

- トレース・ファイルの生成

- コンポーネントの診断出力の表示

- Fusion Middleware ControlのLog Viewerの使用

- Oracle Portal Diagnostics Assistantの使用

- Oracle Portalでのモバイル関連の問題の分析

- パフォーマンス・ログの有効化

G.2.1 ECIDロギングの有効化

問題の診断を容易にするために、コンポーネントでは受信したリクエストに関連する情報をログ・ファイルに記録できます。ここでは、問題を診断するために様々なログ・ファイルを構成し、使用する方法、およびExecution Context Identifier (ECID)を使用して、個々のリクエストを最初から最後まで追跡する方法を説明します。

実行コンテキスト識別子

Oracle Portalは同時に多数のリクエストに対応できるため、様々なOracle Portalコンポーネントを通して1つのリクエストを追跡するのは、これらのリクエストに関連する情報が混ざってしまい難しい場合があります。

Oracle Portalでは、リクエストに割り当てられ、そのリクエストについて記録された情報に付加される一意の番号であるECIDを利用します。リクエストが1つのコンポーネントから別のコンポーネントに渡されるときに、ECIDを増分して、順序を付けることができます。このECIDの順序をたどれば、任意の数のコンポーネントを通る個々のリクエストを追跡できます。

ECIDは、ECIDなしの最初のリクエストを受信するOracle Fusion Middlewareコンポーネントが生成します。図G-2は、ECIDの生成と伝播を示しています。この図では、破線がECID付きのリクエストを示しています。

図G-2 ECIDの生成と伝播を伴うリクエストのフロー

ECIDの生成は、Oracle Web Cache、Oracle HTTP ServerおよびParallel Page Engine (PPE)で行われます。ECIDは、まだ存在しない場合にのみ生成されます。このリリースでは、Oracle Web Cacheのポータル無効化のログに元のリクエストのECIDが含まれるようになりました。これを使用して、元の編集やパーソナライズに無効化を関連付けることができます。

関連項目:

ECID、およびこれを利用してOracle Fusion Middlewareコンポーネントからのメッセージの関係を調べる方法については、『Oracle Fusion Middleware管理者ガイド』を参照してください。

G.2.2 トレース・ファイルの生成

プロセスで内部エラーが検出されたときに、エラーの情報をトレース・ファイルに書き込むことができます。この情報は、ハンドルされていない例外エラーを分析する場合に役立ちます。詳細は、第G.1.17項「ハンドルされていない例外エラー」を参照してください。

データベース・インスタンスのセッションに対するトレース・ファイルを生成するには、次の方法を使用できます。

- PlsqlBeforeProcedureとPlsqlAfterProcedureを使用する

- sql_traceパラメータを設定する

- データベース・イベント10046を設定する

G.2.2.1 PlsqlBeforeProcedureとPlsqlAfterProcedureの使用

データベース・インスタンスの特定のセッションに対するSQLトレースは、新しいDADを作成し、PlsqlBeforeProcedureおよびPlsqlAfterProcedureプロシージャの値を設定することで有効にできます。

注意:

PlsqlBeforeProcedureとPlsqlAfterProcedureの値は元のDADに設定することもできますが、他のユーザーに影響を与える可能性があります。したがって、新しいDADを作成することをお薦めします。

トレースを有効にするには、次の手順を実行します。

1. ポータル・スキーマのutltrace.sqlスクリプトを実行します。デフォルトのポータル・スキーマ名は、portalです。

注意:

スクリプトutltrace.sqlは、Oracle Fusion Middleware Repository Creation AssistantのCD-ROMのORACLE_INSTANCE/portal/admin/plsql/wwcディレクトリにあります。このCD-ROMは、Oracle Portalのインストールに使用したOracle Fusion Middleware CD-ROMパックに含まれています。

Oracle Portal 11.1.1の場合は、次の場所のOracle Metalinkからutltrace.sqlのソース・コードを入手できます。

http://metalink.oracle.com

2. portal_trcなどの新しいDADを作成します。『Oracle Fusion Middleware mod_plsqlユーザーズ・ガイド』を参照してください。

3. 「OK」をクリックして、HTTP ServerのPL/SQLプロパティに戻ります。

4. DADステータス・セクションで、作成したDADをクリックします。「拡張」をクリックして、次の値を設定します。

- PlsqlBeforeProcedure: portal.wwutl_trace.trace_on

- PlsqlAfterProcedure: portal.wwutl_trace.trace_off

5. HTTP ServerとWLS_PORTALを停止して、起動します。

注意:

新しいDADのCookieは、ポータルURLのDADと置き換えることができるように、ポータルのDADと同じにする必要があります。新しいDADのCookie名がポータルのDADと異なる場合は、新しいDADのCookie名をポータルのDADのCookie名に置き換えてください。

Cookie名の確認方法または更新方法の詳細は、第13.2.1項「PlsqlSessionCookieName値の確認」を参照してください。

6. Oracle Portal URLのDADを、ステップ2で定義した新しいDADに変更し、そのURLを使用してOracle Portalにアクセスします。たとえば、
http://<hostname>:<port>/portal/pls/portal/portal.home

次のように変更します。

http://<hostname>:<port>/portal/pls/portal_trc/portal.home

イベントを設定した後、2つのトレース・ファイルがuser_dump_destディレクトリに書き込まれます。このファイルを開いて、発生したハンドルされていない例外エラーについての情報を確認します。

G.2.2.2 sql_traceパラメータを設定する

sql_traceデータベースの初期化パラメータを設定して、トレースを有効化できます。

イベントを設定した後、そのイベントを有効にするには、データベース・インスタンスを再起動する必要があります。

データベース・インスタンスのすべてのセッションのトレースを有効にするには、次のSQL構文を使用して、SPFILEのsql_traceパラメータをtrueに設定します。

ALTER SYSTEM SET
sql_trace=true
COMMENT = 'turn tracing ON for all sessions'
SCOPE=SPFILE;

トレースを無効にするには、次の構文を使用します。

ALTER SYSTEM SET
sql_trace=false
COMMENT = 'turn tracing OFF for all sessions'
SCOPE=SPFILE;

データベースの初期化パラメータの更新手順に精通していない場合は、Oracle Database 11gドキュメント・ライブラリの『Oracle Database管理者ガイド』で、サーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する項を参照してください。

G.2.2.3 データベース・イベント10046の設定

データベース・イベント10046を設定すると、データベース・インスタンスのすべてのセッションのトレースを有効にできます。イベント10046は、パラメータ・ファイルのsql_traceの値をtrueに設定することと同義です。さらに、イベント10046を設定する場合は、トレースのレベルも指定できます。

注意:

イベントの設定は、オラクル社カスタマ・サポート・センターのサポートがある場合にのみ行ってください。

表G-1は、トレース・レベルを示しています。

表G-1 トレース・レベル

レベル

説明

1

標準のSQL_TRACE機能を有効にする場合に使用します。これはデフォルト値です。

4

標準のSQL_TRACE機能を有効にし、バインド値をトレースする場合に使用します。

8

標準のSQL_TRACE機能を有効にし、待機をトレースする場合に使用します。

これは主にラッチ待機の識別に使用しますが、全表スキャンおよび全索引スキャンの識別にも使用できます。

12

標準のSQL_TRACE機能を有効にし、バインド値と待機をトレースする場合に使用します。

注意:

データベース・イベントを設定する際は、次の点を考慮してください。

- データベース・インスタンスの稼働時はイベントを設定できません。

- イベントを設定する場合、データベースをマウントしたり、開く必要はありません。データベース・インスタンスがNOMOUNT状態の場合に、コマンドを実行できます。

SPFILEのデータベース・イベント10046を設定してトレースを有効にするには、次の構文を使用します。

ALTER SYSTEM SET
EVENT = '10325 trace name context forever, level 10:10015 trace name context forever, level 1'
COMMENT = 'Debug tracing of control and rollback'
SCOPE=SPFILE;

データベースの初期化パラメータの更新手順に精通していない場合は、Oracle Database 11gドキュメント・ライブラリの『Oracle Database管理者ガイド』で、サーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する項を参照してください。

G.2.3 コンポーネントの診断出力の表示

様々なOracle Portalコンポーネントの診断出力を構成できます。次のコンポーネントが該当します。

- JPDK

- Portalサービス

- Parallel Page Engine

- Oracle Fusion Middleware Portal Developer Kit

- Oracle Metadata Repository

- Oracle Web Cache

G.2.3.1 JPDK

Java Portal Development Kit (JPDK)は、Javaベースのポートレットとポートレット・プロバイダを構築するためのフレームワークを提供します。Javaベースのプロバイダ、つまりWebプロバイダは、Webアプリケーションとして記述されます。JPDKには、プロバイダ・アダプタごとに制御されるロギング機能も含まれます。

表G-2は、使用できるログ・レベルとその説明です。ログ・レベルの値の許容範囲は1から8で、累積的です。たとえば、ログ・レベルの3を指定すると、ログ・レベルの1および2の出力も記録されます。

表G-2 ログ・レベル

ログ・レベル

説明

1

構成

2

重大なエラー

3

警告

4

例外

5

パフォーマンス

6

詳細なパフォーマンス情報

7

情報

8

デバッグ

JPDKログ・ファイルの内容

プロバイダ・アダプタの診断情報は、サーブレットのコンテキスト・ログ・ファイルWLS_PORTAL-diagnostic.logに記録されます。

JPDKメッセージには、次の2種類があります。

- 標準JPDKメッセージ

- パフォーマンスJPDKメッセージ

標準JPDKメッセージ

プロバイダ・アダプタのWLS_PORTAL-diagnostic.logファイルに記録される標準JPDKメッセージの例を次に示します。

07/12/31 02:58:59 jpdk: [instance=1926_EXPIRESSAMPLE_886361, id=1024597399815ApplicationServerThread-12,4] Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361

標準のJPDKメッセージの内容は、次のとおりです。

- 日時: 07/12/31 02:58:59

- Webアプリケーション: jpdk

- ECID、順序番号: id=1024597399815ApplicationServerThread-12,4

- ポートレット・インスタンス識別子: instance=1926_EXPIRESSAMPLE_886361

- メッセージ: Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361

ポートレット・インスタンス識別子は、特定のページの特定のポートレット・インスタンスを識別し、次のように分類されます。

- 内部順序番号: 1926

- ポートレット名: EXPIRESSAMPLE

- プロバイダ識別子: 886361

これらの値の一部についてのさらに詳しい情報を表G-3に示します。

表G-3 JPDK標準メッセージの属性

値

詳細

ECID

一部のメッセージでは、ECIDおよびポートレット・インスタンス識別子の値がNULLになっています。通常それらは、リポジトリからのSOAPメッセージです。

ポートレット・インスタンス識別子

この場合、メッセージは特定のポートレット・インスタンスに関連付けられていないので、ポートレット・インスタンス識別子がNULLであることを除き、ECIDと同じになります。

G.2.3.2 Portalサービス

Portalサービスのパフォーマンスは、Oracle HTTP Serverを介してログに記録されます。error_logファイルのデフォルト・ディレクトリは、UNIXの場合はORACLE_INSTANCE/Apache/Apache/log、Windowsの場合はORACLE_INSTANCE\Apache\Apache\logです。ログは、構成ファイルhttpd.confのLogLevelパラメータで制御されます。

G.2.3.3 Parallel Page Engine

Parallel Page Engine (PPE)は、ページ・レイアウトを表すデータを受け入れて、このデータをポートレットを含むページに変換する共有サーバー・プロセス・サーブレットです。

PPEのログは、サーブレットおよびリクエスト・レベルで制御できます。リクエストのログ・レベルを指定しない場合は、リクエストに対してサーブレット・レベルが使用されます。サーブレットとリクエストの両方のログ・レベルを指定する場合は、この2つの高いほうのレベルがリクエストに使用されます。

サーブレットレベルのログ

Oracle Portalの診断ログ設定は、WLS_PORTALインスタンスのlogging.xmlファイル(DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL)に保持されます。

デフォルトでは、ログ・レベルはNOTIFICATION:1で、ロガー「oracle」に設定されます。Portalのロガーoracle.portalはoracleロガーの子であり、logging.xmlでロギング・レベルが指定されていない場合は親からロギング・レベルを継承します。必要に応じて、ロガーoracle.portalに独自のログ・レベルを設定できます。例:

<logger name="oracle.portal" level="FINE"/>

パフォーマンス・ログは、appConfig.xml(DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml)で設定します。デフォルトでは、offに設定されています。

<perfLogMode>off</perfLogMode>

onまたはperfを指定することで有効にできます。パフォーマンス・ログの出力は、診断ログと同じターゲットに送信されます。

表G-4は、oracle.portalロガーのレベル設定がPPEのロギング出力に与える影響を示しています。

表G-4 ログ・レベルとその説明

ログ・レベル

説明

なし

メッセージはありません。

重大

デバッグ・メッセージはありません。警告およびエラーに関する情報が得られます。

構成

デバッグ・メッセージはありません。構成に関するメッセージの情報が得られます。

密

構成に関するメッセージおよび一般的なデバッグ・メッセージの情報が得られます。

詳細

「密」ログ・レベルのすべての情報およびPPEによるリクエストの詳細が得られます。

最も詳細

「詳細」ログ・レベルのすべての情報およびPPEとメタデータ解析で生成されるリクエストのコンテンツの詳細が得られます。

リクエストレベルのログ

PPEリクエストレベルのログは、_debug URLパラメータで制御されます。たとえば、次のURLに対してリクエストレベルのログを指定するとします。

http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema

次のパラメータを手動で挿入する必要があります。

&_debug=3

変更後のURLは次のようになります。

http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema&_debug=3

表G-5に、_debugの値を示します。

表G-5 PPEリクエスト・ログのレベル

値

詳細

0

ページのデバッグ情報を有効にします。

1

ページのデバッグ情報を有効にします。

2

ページにログを記録し、リクエストのログ・モードをdebugに設定します。

3

ページにログを記録し、リクエストのログ・モードをrequestに設定します。

4

ページにログを記録し、リクエストのログ・モードをcontentに設定します。

5

ページにログを記録し、リクエストのログ・モードをparsingに設定します。

ページのログ

_debugを2、3、4または5に設定すると、ページのログが有効になります。つまり、リクエストに対して記録されたメッセージは、PPEのログ・ファイルと、返されるページに記録されます。

ページのログは、リクエストに関連する詳細情報を取得するための手段です。この結果、これはセキュリティの問題ともなるため、urlDebugModeサーブレット初期化引数が用意されています。

urlDebugMode引数は、ポータルのappConfig.xmlファイル(DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml)の中でoracle.portalloggerと並んで記述されています。

<urlDebugMode>4</urlDebugMode>

表G-6に、urlDebugMode引数の値を示します。デフォルト値は、1です。

表G-6 PPEのurlDebugModeレベル

値

詳細

なし

_debug URLパラメータを無視します。

0

_debugに0を指定できます。

1

_debugに0または1を指定できます。

2

_debugに0、1または2を指定できます。

3

_debugに0、1、2または3を指定できます。

4

_debugに0、1、2、3または4を指定できます。

5

_debugに0、1、2、3、4または5を指定できます。

PPEログ・ファイルの内容

PPE診断メッセージは、サーブレット・コンテキストのWLS_PORTAL-diagnostic.logファイルに記録されます。このファイルは、次の場所にあります。

DOMAIN_HOME\servers\WLS_PORTAL\logs

PPEメッセージには、次の2種類があります。

- 標準PPEメッセージ

- パフォーマンスPPEメッセージ

標準PPEメッセージ

ログ・ファイルに記録される標準のPPEメッセージの例を次に示します。

03/12/31 11:54:35 portal: id=22020914339,0 DEBUG: active=53  ContentFetcher
Unexpected Exception Request Failed:java.lang.IllegalArgumentException
name=content-fetcher52 label=dbPortlet url=https://abc.company.com:5001/pls/ptl_
9_0_4_0_87/!PTL_9_0_4_0_87.wwpro_app_provider.execute_portlet/391497559/4
time=38975ms timeout=15000ms process=ResponseHeaders

この標準のPPEメッセージの内容は、次のとおりです。

- 日時: 03/12/31 11:54:35

- Webアプリケーション: portal

- logmodeフラグ: DEBUG

- アクティブな数: active=53

- ECID: id=22020914339, 0

- メッセージ: ContentFetcher Unexpected Exception Request Failed

表G-7に、これらの一部の値の詳細を示します。

表G-7 PPE標準メッセージの属性

値

詳細

logmodeフラグ

ログ・モードがdebug以上であることを示します。logmodeがperfに設定されてログ・レベルがdebugより低くなった場合、logmodeフラグはメッセージに含まれません。

アクティブな数

PPEのスレッド・グループに含まれているスレッドの数を示します。logmodeがperfに設定されてログ・レベルがdebugより低くなった場合、アクティブな数はメッセージに含まれません。

ECID

nullも可。そのような値が含まれるメッセージは、PPEバックグラウンド・タスク(プールされたオブジェクトの消去など)に関連しています。バックグラウンド・タスクはリクエストとは関連していないので、ECIDを指定しません。

パフォーマンスPPEメッセージ

ログ・ファイルに記録されるパフォーマンスPPEメッセージの例を次に示します。

07/06/16 06:06:37 portal: [perf] 140.87.20.124
https://abc.company.com:8250/portal/ page?_pageid=40,1&_dad=portal&_
schema=PORTAL&_mode=16 id=8198110376563,1 type=page name=40,1 status=200
user=PORTAL subscriberID=1 reqTime=187ms waitTime=0ms cache=(null) timeout=No
redirects=0 bytes=33865 authLevel=10 webCacheStatus=(null) webCacheExpires=(null)
webCacheAge=(null) csConv=No readTime=No,0ms pageTimeout=No procTime=0ms

G.2.3.4 Oracle Fusion Middleware Portal Developer Kit

Oracle Fusion Middleware Portal Developer Kit (PDK)は、Java、Web Services、XML、ASP、Perl、PL/SQLなどの様々なWeb言語でポートレットおよびポートレット・プロバイダを構築するためのフレームワークを提供します。したがって、PDKにはJPDKも含まれています。

PDKは、中核となるロギング機能を提供し、特定の開発者キットでログ記録を行うことによってこの機能を拡張します。PDKログは、図G-3に示したようなWebベースのユーザー・インタフェースを通して制御されます。

図G-3 PDKログ・ページ

このPDKログ・ページは、次の場所にあります。

http://<host>:<port>/portal/pls/<dad>/<schema>.wwpro_log.render

サンプルのURLは次のとおりです。

http://myserver.myplace.com:3000/portal/pls/portal/PORTAL.wwpro_log.render

このページから、表G-8に示したログ・レベルを適用できます。

表G-8 PDKログ・レベル

レベル

詳細

No debugging

ログを記録しません

PROHTTPJ

プロバイダ・フレームワークのログ

PROGRP

プロバイダのログ

ADAPTER

連携型ポータル・アダプタのログ

CACHE

キャッシュのログ

FORCE

Oracle内部

INVAL

無効化のログ

PROREG

プロバイダ登録のログ

PROLOGIN

ページ・メタデータの生成、ログインおよびセッションの初期化のログ

PROPROV

プロバイダ通信のログ

PROPMR

ポートレット・メタデータ・リポジトリのログ

PROHTTP

Webプロバイダ・フレームワークのログ

All

すべてのログ・レベルを有効にします

PDKログ・ファイルの内容

図G-4に示したように、PDKログの設定に使用したものと同じページで、PDKログ・エントリを表示できます。

図G-4 PDKログ・ページのログ・エントリ

G.2.3.5 Oracle Metadata Repository

Oracle Metadata Repositoryは、Oracle Portalデータベース・スキーマに存在するすべてのメタデータ、ポータル・コンテンツおよびPL/SQLコードから構成されています。Oracle Portalスキーマで実行されるPL/SQLコードは、Oracle Portalの他のコンポーネントから生成される診断出力と相互に関係付けることができる診断出力も生成します。

ログ・ファイルはOracle Metadata Repositoryで生成されるため、Oracle Portalを実行するデータベースは、これが可能なように構成されている必要があります。これを行うには、CREATE DIRECTORY文を使用してディレクトリ・オブジェクトを作成する必要があります。

ディレクトリ・オブジェクトは、外部ファイルと外部表データがあるサーバー・ファイル・システム上のディレクトリの別名を指定します。

注意:

ディレクトリはすべて単一のネームスペースで作成され、個々のスキーマにより所有されます。特定のユーザーにディレクトリでのオブジェクト権限を付与することにより、ディレクトリ構造内に格納されたファイルへのアクセスを保護できます。

CREATE DIRECTORY文を使用するには、CREATE ANY DIRECTORYシステム権限が必要です。ディレクトリを作成すると、そのディレクトリに対するREADおよびWRITEのオブジェクト権限が自動的に付与されます。その結果、ディレクトリの作成者、つまりデータベース管理者は、これらの権限を他のユーザーやロールに付与できます。

注意:

ディレクトリに対するWRITE権限は、外部表との接続において便利です。この権限により、権限受領者は、外部表エージェントがそのディレクトリにログ・ファイルまたは不良ファイルを書き込めるかどうかを決定できます。

ファイル記憶域用に対応するオペレーティング・システム・ディレクトリも作成する必要があります。システムまたはデータベース管理者は、オペレーティング・システム・ディレクトリにOracle Databaseプロセスに対する正しいREAD権限とWRITE権限があることを確認する必要があります。

ディレクトリに付与される権限は、オペレーティング・システム・ディレクトリに定義されている権限とは関係なく作成され、これら2つは正確に一致する場合も、しない場合もあります。たとえば、サンプル・ユーザーhrにディレクトリ・オブジェクトに対するREAD権限が付与されているのに、対応するオペレーティング・システム・ディレクトリにOracle Databaseプロセスに対して定義されたREAD権限がない場合には、エラーが発生します。

新しいディレクトリ・オブジェクトを作成するには、次の構文を使用します。

CREATE [OR REPLACE] DIRECTORY AS 'path_name';

表G-9に、CREATE DIRECTORY構文で使用するパラメータを示します。

表G-9 CREATE DIRECTORYのパラメータ

セマンティクス

説明

OR REPLACE

ディレクトリ・データベース・オブジェクトがすでに存在する場合は、再作成するためにOR REPLACEを指定します。この句を使用して、既存ディレクトリの定義を、そのディレクトリにすでに付与されているデータベース・オブジェクト権限を削除、再作成、再付与することなく変更できます。

再定義されたディレクトリに対するアクセス権限がすでに付与されている既存のユーザーは、権限を再び付与されることなく、そのディレクトリにアクセスできます。

directory

作成されるディレクトリ・オブジェクトの名前を指定します。directory名の最大長は30バイトです。ディレクトリ・オブジェクトはスキーマ名で修飾できません。

Oracle Databaseでは、指定するディレクトリが実際に存在するかどうかが検証されません。したがって、オペレーティング・システムで有効なディレクトリが指定されていることを確認する必要があります。さらに、オペレーティング・システムで大文字と小文字を区別するパス名が使用される場合は、必ず正しい形式でディレクトリを指定してください。パス名の最後にスラッシュを付ける必要はありません。

path_name

ファイルがあるサーバーのオペレーティング・システム・ディレクトリのフル・パス名を指定します。一重引用符が必要です。その結果、パス名は大文字と小文字が区別されます。

たとえば、次の文では、サーバー上のディレクトリを指定するディレクトリ・データベース・オブジェクトが作成されます。

CREATE DIRECTORY admin AS 'oracle/admin';

次の文は、bfile_dirディレクトリ・データベース・オブジェクトを再定義して、オペレーティング・システム・ディレクトリ/private1/lob/filesに格納されているファイルへのアクセスを可能にします。

CREATE OR REPLACE DIRECTORY bfile_dir AS '/private1/LOB/files';

リリース9.2より前のOracle Databaseの場合、PL/SQLコードにより診断出力を生成するには、次の行を追加して、データベースの初期化パラメータ・ファイルを更新します。

UTL_FILE_DIR=<directory where you want to write the log file>

データベースの初期化パラメータの更新手順に精通していない場合は、Oracle Database 11gドキュメント・ライブラリの『Oracle Database管理者ガイド』で、サーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する項を参照してください。

多数のUTL_FILE_DIRエントリが存在する場合があるため、書き込むディレクトリがすでに定義されている場合は、このファイルを変更する必要はありません。

注意:

Oracle Metadata Repositoryのインストールでは、インストール先のデータベースにUTL_FILE_DIRパラメータがある場合、Oracle Portalインストーラは、Oracle Metadata Repositoryログ・ファイルの場所としてデータベース・パラメータに最初に定義されたディレクトリを使用するようにOracle Metadata Repositoryを構成します。UTL_FILE_DIRディレクトリが構成されていない場合は、インストール時にOracle Metadata Repositoryログは設定されません。

Oracle Metadata Repositoryのログは、ログ・パッケージによって実行されます。このログ・パッケージは、SQL*Plusから実行する必要があるlogcfg.sqlスクリプトによって制御されます。

logcfg.sqlスクリプトは、次の場所にあります。

ORACLE_INSTANCE/portal/admin/plsql/wwc

logcfg.sqlスクリプトには、log_level、log_state_level、log_format、log_file、log_directoryの順に、5つのパラメータを指定できます。指定したパラメータが5つ未満の場合は、1つ以上の値がリクエストされます。このリクエストに対するレスポンスとして値を受け取らない場合は、現在の値が維持されます。

表G-10は、logcfg.sqlパラメータの詳細を示しています。

表G-10 リポジトリのログ・パッケージのパラメータ

パラメータ

詳細

log_level

記録されたメッセージのレベルを示します。値は、次のとおりです。

- 0: なし

- 1: エラー

- 2: 警告

- 3: 情報

- 4: トレース

- 5: デバッグ

- 6: 詳細なデバッグ

値は、累積的です。デフォルト値は、1です。

log_state_level

状態情報が自動的にログに記録されるメッセージのレベルを示します。値は、次のとおりです。

- 0: なし

- 1: エラー

- 2: 警告

- 3: 情報

- 4: トレース

- 5: デバッグ

- 6: 詳細なデバッグ

値は、累積的です。

log_format

状態情報のフォーマットとは異なる、自動的に記録されたコンテキスト情報のフォーマットを示します。値は、次のとおりです。

- 0: シンプル

- 1: 詳細

log_file

書き込むログ・ファイルの名前を指定します。このファイルがまだ存在しない場合は、作成を試みます。

log_directory

log_fileパラメータが存在するディレクトリを指定します。この値には、物理的パスまたはディレクトリ・オブジェクトを指定できます。この値が物理ディレクトリの場合、このディレクトリはデータベース・パラメータ・ファイルのUTL_FILE_DIRプロパティに定義する必要があります。例:

utl_file_dir=/export/home/oracle/as1014/logs

データベース・パラメータ・ファイルを変更する場合は、変更を有効にするためにデータベースを再起動する必要があります。

この値がディレクトリ・オブジェクトの場合、ディレクトリ・オブジェクト名を大文字で指定する必要があります。たとえば、LOGSとします。

たとえば、logcfg.sqlスクリプトをSQL*Plusから次のように実行できます。

@logcfg.sql 3 3 1 portal.log /export/home/oracle/as1014/logs

ディレクトリ・オブジェクトを参照する場合は、ディレクトリ・オブジェクト名を大文字で指定する必要があります。たとえば、logsという名前のディレクトリ・オブジェクトを参照するには、logcfg.sqlスクリプトをSQL*Plusから次のように実行します。

@logcfg.sql 3 3 1 portal.log LOGS

logcfg.sqlを実行すると、使用方法が表示されます。

Configure Portal diagnostics
usage:
logcfg.sql <log_level> <log_state_level> <log_format> <log_file> <log_directory>
If for any of the params a null value is specified the existing value will be maintained.
Log levels:
0 : None (turn diagnostics off)
1 : Error
2 : Warning
3 : Information
4 : Trace
5 : Debug
6 : Fine Debug
Log formats:
0 : Simple
1 : Detailed

現在の値も表示されます。

Current settings:
Log level:     3
Log state level:     3
Log format:     1
Log file:     portal.log
Log directory:     /export/home/oracle/as101202/dblogs

Oracle Metadata Repository診断ログ・ファイルを切り捨てるには、ORACLE_INSTANCE/portal/admin/plsql/wwcにあるSQLスクリプトlogtrunc.sqlを実行します。

リポジトリ・ログ・ファイルの内容

Oracle Metadata Repositoryの診断情報の場所は、リポジトリ診断パッケージ・パラメータのlog_fileおよびlog_directoryによって指定されます。

Oracle Metadata Repositoryログ・ファイルに記録されるERRORタイプ・メッセージの例を次に示します。

[06-AUG-2007 15:02:15] [ERROR] id=(102733434) ctx=wwsrc_simple_edit.render_simple_edit_prefs user=PORTAL subscriberId=1 language=us userAgent="Mozilla/5.0" ip=192.0.0.1
ORA-30625: method dispatch on NULL SELF
[START-ERROR-STACK]
ORA-30625: method dispatch on NULL SELF
[END-ERROR-STACK]
[START-CALL-STACK]
----- PL/SQL Call Stack -----
object          line          object
handle          number        name
81b35e6c        350           package body PORTAL.WWLOG_API_DIAG
81b35e6c        443           package body PORTAL.WWLOG_API_DIAG
81b35e6c        526           package body PORTAL.WWLOG_API_DIAG
86765ac8        259           package body PORTAL.WWSRC_SIMPLE_EDIT
86765ac8        334           package body PORTAL.WWSRC_SIMPLE_EDIT
84317130        19            package body PORTAL.WWSBR_BASIC_SEARCH
88857980        713           package body PORTAL.WWSBR_SITEBUILDER_PROVIDER
8323ad18        1             anonymous block
87e53d5c        648           package body PORTAL.WWPRO_API_PROVIDER
81ae1e50        2644          package body PORTAL.WWPOB_PAGE
877a0d9c        12            anonymous block
[END-CALL-STACK]
[START-QUERY-STRING]
_providerid=102274117
_portletid=14
_mode=5
_title=Basic%20Search
_referencepath=1875_BASICSEARCH_102274117
_back_url=http%3A%2F%2Fmyserver.myplace.com%3A3000%2Fpls%2Fportal%
_portlet_reference=33_31293_33_1_1
[END-QUERY-STRING]

ログ・ファイルに記録されるメッセージは次のとおりです。

ORA-30625: method dispatch on NULL SELF: メッセージ本体。

ログ・ファイルには、コンテキスト情報および状態情報も記録されます。

コンテキスト情報

コンテキスト情報は、詳細またはシンプルのいずれかのフォーマットで生成されます。これは、log_formatパラメータで指定します。次の例は、フォーマットの詳細です。

- 06-AUG-2007 15:02:15: 日時

- ERROR: メッセージ・レベル

- id=(102733434, 1): ECID

- ctx=wwsrc_simple_edit.render_simple_edit_prefs: メッセージ・コンテキスト

- user=PORTAL: データベース・ユーザー

- subscriberId=1: サブスクライバ識別子

- language=us: グローバリゼーション・サポート言語

- userAgent="Mozilla/5.0": ユーザー・エージェント

- ip=192.0.0.1: クライアントIPアドレス

シンプルな書式は、詳細な書式の一部であり、次の情報が含まれます。

- 06-AUG-2007 15:02:15: 日時

- ERROR: メッセージ・レベル

- ctx=wwsrc_simple_edit.render_simple_edit_prefs: メッセージ・コンテキスト

表G-11に、これらの一部の値の補足情報を示します。

表G-11 リポジトリ・コンテキストの属性

値

詳細

クライアントIPアドレス

通常、これは使用しているクライアントのブラウザまたはHTTPプロキシのIPアドレスです。Oracle Portalページ・アセンブリ・プロセスはループバック・コールを使用しているため、IPアドレスは中間層そのものを表すこともできます。

サブスクライバ識別子

リポジトリにアクセスしたサブスクライバを識別します。

ユーザー・エージェント

使用しているブラウザの説明です。

状態情報

状態情報は、エラー・スタック、コール・スタックおよび問合せ文字列で構成されます。それぞれの例を次に示します。

注意:

PL/SQLエラー・スタックは、ERRORタイプのメッセージがログに記録されている場合にのみ表示されます。

エラー・スタック:

[START-ERROR-STACK]
ORA-30625: method dispatch on NULL SELF
[END-ERROR-STACK]

コール・スタック:

[START-CALL-STACK]
----- PL/SQL Call Stack -----
object          line        object
handle          number      name
81b35e6c        350         package body PORTAL.WWLOG_API_DIAG
81b35e6c        443         package body PORTAL.WWLOG_API_DIAG
81b35e6c        526         package body PORTAL.WWLOG_API_DIAG
86765ac8        259         package body PORTAL.WWSRC_SIMPLE_EDIT
86765ac8        334         package body PORTAL.WWSRC_SIMPLE_EDIT
84317130        19          package body PORTAL.WWSBR_BASIC_SEARCH
88857980        713         package body PORTAL.WWSBR_SITEBUILDER_PROVIDER
8323ad18        1           anonymous block
87e53d5c        648         package body PORTAL.WWPRO_API_PROVIDER
81ae1e50        2644        package body PORTAL.WWPOB_PAGE
877a0d9c        12          anonymous block
[END-CALL-STACK]

問合せ文字列:

[START-QUERY-STRING]
_providerid=102274117
_portletid=14
_mode=5
_title=Basic%20Search
_referencepath=1875_BASICSEARCH_102274117
_back_url=http%3A%2F%2Fmyserver.myplace.com%3A3000%2Fpls%2Fportal%
_portlet_reference=33_31293_33_1_1
[END-QUERY-STRING]

リポジトリ診断ログ・ファイルの登録

Oracle Enterprise Manager 11gには、Log ReaderとLog Viewerがあります。Log Readerを使用すると、管理者はログ・ファイルをファイルベースのログ・リポジトリにアップロードできます。Log Viewerを使用すると管理者はリポジトリにロードされたログ・エントリの表示や問合せを行うことができます。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。

リポジトリ診断ログ・ファイルのエントリのロードや表示を行うためには、先にログ・ファイルをOracle Enterprise Manager 11gに登録する必要があります。これを行うには、次のファイルを編集します。

ORACLE_INSTANCE/diagnostics/config/registration/PORTAL.xml

このファイルには、ログ・ファイルの詳細を反映するようにコピーして拡張できるテンプレート・エントリがあります。テンプレートは、次のとおりです。

<logs xmlns="http://www.oracle.com/iAS/EMComponent/ojdl" helpIDLogs="psm_cs_xml_log_info">

<!--
<log path="<PATH>" componentId="PORTAL">
<logreader type="SimpleTextLog">
<property name="ComponentId" value="PORTAL"/>
<property name="ModuleId" value="Portal:<INSTANCE>"/>
<property name="TimestampFormat" value="[dd-MMM-yyyy HH:mm:ss]"/>
<property name="TimestampLocale" value="en_US"/>
</logreader>
<logviewer ComponentName="ID_VLOGS_PORTAL_REP@ResourceBundle"
LogType="ERROR"
LogName="Diagnostics for Portal instance <INSTANCE>"/>
</log>
-->

</logs>

コピーしたテンプレート・エントリに含まれる情報を次のように変更します。

- <PATH>: ログ・ファイルの絶対パスとファイル名。

- <INSTANCE>: 定義されている場合、Oracle Enterprise Manager 11gでのOracle Portalターゲットの名前。対応するOracle PortalターゲットがOracle Enterprise Manager 11gにない場合は、<portal schema name>-<db service name>など、Oracle Portalインスタンスの名前とデータベースの詳細を使用します。この値は、Log Viewerでこのログ・エントリを他のOracle Portalインスタンスのログ・エントリと区別するために使用します。

新しいPORTAL.xmlエントリを保存すると、Log Readerはログ・ファイルの定期的なアップロードを開始し、Log Viewerを使用してログ・ファイルの表示や問合せを行えるようになります。

Oracle Metadata Repositoryは多数の中間層を通してアクセスされるので、次の手順を実行する必要があります。

- リポジトリ診断ログ・ファイルをOracle Portal中間層を監視しているいずれかのOracle Enterprise Manager 11g Fusion Middleware Controlインスタンスに登録します。

- Oracle PortalデータベースがOracle Portal中間層以外のコンピュータにある場合は、ネットワーク・ファイル・システムからログ・ファイルにアクセスできるようにします。

- 複数の中間層環境でログを相互に関連付けるには、Oracle Portal中間層を監視する各Oracle Enterprise Manager 11gインスタンスにリポジトリ診断ログ・ファイルを登録する必要があります。

注意:

Oracle Enterprise Manager 11gを使用して、ORACLE_INSTANCE/diagnostics/config/registration/にあるPORTAL.xmlファイル内のリポジトリ診断ログ・ファイルの場所を更新する必要があります。

G.2.3.6 Oracle Web Cache

Oracle Web Cacheのイベントとエラーは、イベント・ログに格納されます。イベント・ログは、どのドキュメントまたはオブジェクトがキャッシュに挿入されたかを確認するうえで役立ちます。リスニング・ポートの競合または起動や停止の問題を特定することもできます。デフォルトでは、イベント・ログのファイル名はevent_logであり、UNIXではORACLE_INSTANCE/webcache/logsに、WindowsではORACLE_INSTANCE\webcache\logsに格納されています。

関連項目:

Oracle Fusion Middleware Oracle Web Cache管理者ガイド

G.2.4 Fusion Middleware ControlのLog Viewerの使用

Oracle Enterprise Manager 11g Fusion Middleware Controlでは、次のログ・ファイルのエントリの表示や問合せが可能です。そのため、Oracle Portalに関連する問題の診断に役立ちます。関連するOracle Fusion Middlewareのコンポーネントのログ・ファイルには、次のものがあります。

- Portal:<instance>: ポータル・インスタンスごとに、<customer_specified_log_name>という1つの診断エラー・ログ・ファイルを表示します。このログ・ファイルは、関連するOracle Metadata Repositoryによって生成されます。

- HTTP_Server: error_log、access_logという複数のエラー・ログ・ファイルまたはアクセス・ログ・ファイルを表示します。これらのログ・ファイルには、すべての関連するPortalサービスのログ情報が含まれています。

- WLS_Portal: WLS_PORTAL-diagnostic.logという複数のアプリケーション・ログ・ファイルを表示します。このログ・ファイルには、すべての関連するPPEログ情報が含まれています。

- Web Cache: event_logおよびaccess_logというエラー・ログ・ファイルおよびアクセス・ログ・ファイルを表示します。

登録手順を完了しなければ、Oracle Metadata Repositoryログ・ファイルをFusion Middleware ControlのLog Viewerで使用することはできません。手順については、「リポジトリ診断ログ・ファイルの登録」を参照してください。

JPDK WLSインスタンスがOracle Portalの中間層のOracleホームにない場合は、そのログ・ファイルはローカルのFusion Middleware Controlのインスタンスを使用しないと表示できません。診断の相関関係を作成する必要がある場合は、Oracle Metadata Repositoryログ・ファイルをリモートに配置する場合の手順と同様のリモート登録手順に従う必要があります。

Oracle Fusion Middleware ControlのLog Viewerでログ・ファイルのエントリを表示する方法以外にも、ECID値を使用してログ・ファイル間でエントリを相互に関連付けることによって、詳細な診断を行うこともできます。詳細は、第G.2.1項「ECIDロギングの有効化」を参照してください。このドリルダウンの相関関係は、Oracle Fusion Middleware ControlのLog Viewerに自動的に表示されます。

ログ・ファイルのエントリを表示するには、各Oracle Fusion Middleware Controlのコンポーネントのホーム・ページの上部と下部にある「ログ」をクリックします。

関連項目:

Log Viewerの使用方法の詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。このマニュアルでは、診断ログ・ファイル情報に対する高度な問合せ、ログ・リポジトリ内での診断メッセージ(選択したOracle Fusion Middlewareコンポーネントから収集)の検索、およびログ・ファイルとコンポーネント間でのメッセージ相互の関連付けの方法についても説明します。

G.2.5 Oracle Portal Diagnostics Assistantの使用

Oracle Portalのインストール後に問題のトラブルシューティングを行う場合は、Oracle Portal Diagnostics Assistantを使用します。Oracle Portalへのアクセスの問題から、Oracle Portal内の異なるレベルでのエラー発生などの様々な問題があります。

Oracle Portal Diagnostics Assistantの結果を調べることで、問題を診断できます。また、結果をオラクル社カスタマ・サポート・センターにアップロードして、問題のトラブルシューティングに役立てることもできます。

生成されるレポートには、次のセクションが含まれます。

- エラーおよび違反(Oracle Portal Diagnostics Assistantで検出された場合のみ)のサマリー

- Oracle Portalリポジトリのデータベース情報

- OracleAS Single Sign-Onのデータベース情報

- Oracle Internet Directoryの診断レポート

- Oracle Textの診断レポート

- Apacheのエラー・ログ・ファイル分析

また、利便性のために、すべてのOracle Portal関連の構成ファイルおよびログ・ファイルが収集され、圧縮されます。

Oracle Portal Diagnostics Assistantを実行するには、UNIXの場合はスクリプトpda.csh、Windowsの場合はpda.cmdを使用する必要があります。スクリプトを実行するたびに、生成されたファイル用の新しいディレクトリが、Oracle Portal Diagnostics Assistantのzipファイルをダウンロードしたディレクトリの下に作成されます。ディレクトリ名は、タイムスタンプの形式で表されます。たとえば、070623132344の場合、次のような意味になります。

年: 07
月: 06
日: 23
時: 13
分: 23
秒: 44

Oracle Portal Diagnostics Assistantの実行後、該当するディレクトリに移動して、ブラウザのウィンドウでpda.htmという名前のHTMLレポートを開きます。このレポートを調べて、診断情報を確認します。

オラクル社カスタマ・サポート・センターに問題のトラブルシューティングのサポートを依頼する場合は、Oracle Metalink(http://metalink.oracle.com)にログオンして、生成されたPDA<directory_name>.zipというzipファイル(PDA040623132344.zipなど)をアップロードします。

Oracle Portal Diagnostics Assistantの使用方法および収集された情報の詳細は、Oracle Portal Diagnostics Assistantをダウンロードしたディレクトリのreadmeファイルを参照してください。

Oracle Portal Diagnostics Assistantの実行

Oracle Portal Diagnostics Assistantを使用して診断情報を生成するには、次の手順を実行します。

1. 次の場所にアクセスし、OTNの「Support and Metalink」セクションで、Oracle Portal Diagnostics Assistantの最新の更新およびパッチ情報を確認します。
http://www.oracle.com/technology/

最新のOracle Portal Diagnostics Assistantスクリプトをダウンロードします。「Support/Upgrade」は、「Product Information」セクションにあります。

2. ORACLE_INSTANCE環境変数が、正しいOracle Portal中間層のOracleホーム・ディレクトリに設定されていることを確認します。
Oracle Portal Diagnostics AssistantをデータベースのOracleホーム・ディレクトリから実行しようとすると、失敗し、診断情報は収集されません。

3. Oracle Portal Diagnostics Assistantをダウンロードして解凍した場所に移動します。

4. UNIXでは、次のようにOracle Portal Diagnostics Assistantを実行します。

pda.csh
-schema <portal schema name>
-password <portal schema password>
-connect <Portal connect string>
-ssoSchema <SSO schema name>
-ssoPassword <SSO schema password>
-ssoConnect <SSO connect string>
[-apacheLogDir <directory name>]
[-apacheLogName <file name>]
[-logFileLimit <number of rows>]
[-show]
[-showall]

ヘルプ情報を表示するには、パラメータを使用せずにスクリプトを実行します。

表G-12は、Oracle Portal Diagnostics Assistantのスクリプトで使用するパラメータとその説明です。

表G-12 Oracle Portal Diagnostics Assistantのスクリプトのパラメータ

パラメータ

説明

-schema

Oracle Portalスキーマの名前。このパラメータは必須です。デフォルトはPortal。

-password

Oracle Portalスキーマのパスワード。このパラメータは必須です。デフォルトはportal_schema。

-connect

Oracle Portalスキーマの接続文字列。<host>:<port>:<sid>というフォーマットを使用します。このパラメータは必須です。

-ssoSchema

OracleAS Single Sign-Onスキーマの名前。このパラメータは必須です。

-ssoPassword

OracleAS Single Sign-Onスキーマのパスワード。このパラメータは必須です。

-ssoConnect

OracleAS Single Sign-Onスキーマの接続文字列。<host>:<port>:<sid>というフォーマットを使用します。このパラメータは必須です。

-apacheLogDir

Oracle HTTP Serverのエラー・ログ・ファイルのディレクトリ。このパラメータはオプションです。デフォルトは、ORACLE_INSTANCE/Apache/Apache/logsです。

-apacheLogName

エラー・ログ・ファイル名。このパラメータはオプションです。デフォルトはerror_log。

-logFileLimit

エラー・ログ・ファイル内の行数。このパラメータはオプションです。デフォルトは10000。

-show

必要な問合せのセットのみに基づいて診断情報を生成します。他のパラメータが選択されていない場合、これが診断情報を生成する際のデフォルト・モードとなります。

-showall

すべての問合せに基づいて診断情報を生成します。このモードでは、関連するセキュリティ表からすべてのポータル・オブジェクトとその権限を取得する問合せも使用されます。そのため、-showallモードでの診断情報の生成には、非常に時間がかかります。

UNIXプラットフォームでのOracle Portal Diagnostics Assistantの実行例を次に示します。

# Set the environment
#
setenv ORACLE_INSTANCE /oracle/productsAS
#
# Run PDA
#
pda.csh \
-schema portal  \
-password <portal_password>  \
-connect abc.oracle.com:1521:orcl1 \
-ssoSchema orasso \
-ssoPassword <orasso_password> \
-ssoConnect defg.oracle.com:1521:orcl2
-show

Windowsでは、次のようにOracle Portal Diagnostics Assistantを実行します。

1. コマンド・プロンプトを起動して、次のコマンドを実行します。

pda.cmd
-schema <portal schema name>
-password <portal schema password>
-connect <Portal connect string>
-ssoSchema <SSO schema name>
-ssoPassword <SSO schema password>
-ssoConnect <SSO connect string>
[-apacheLogDir <directory name>]
[-apacheLogName <file name>]
[-logFileLimit <number of rows>]
[-show]
[-showall]

ヘルプ情報を表示するには、パラメータを使用せずにスクリプトを実行します。

表G-12は、Oracle Portal Diagnostics Assistantのスクリプトで使用するパラメータとその説明です。

5. ブラウザのウィンドウで最新のHTMLレポート(pda.htm)を開き、Oracle Portalの問題の診断に役立てます。

G.2.6 Oracle Portalでのモバイル関連の問題の分析

標準のデスクトップ・ブラウザと比べて、モバイル・デバイスには、詳細なエラー情報を表示する適切なインタフェースがありません。次に示す情報は、Oracle Portalでモバイル関連の問題を分析する場合に役立ちます。

_debugパラメータの使用

すべてのOracle Portalページは、実行時間とキャッシュの情報が表示される特殊なモードで実行できます。ページのURLの末尾に_debug=1パラメータを付けると、表示されるレスポンスに他の実行時間の情報が追加されます。

選択したいくつかのページとポートレットに関するデバッグ情報を表示する場合は、_debug URLパラメータを使用してログ・レベルを制御できます。_debugの有効な値は、0、1、2、3、4および5です。実行時間およびキャッシュの統計の詳細は、第B.5項「実行時間とキャッシュの統計」を参照してください。

モバイル・ブラウザからアクセスする場合は、_debug URLパラメータを使用すると問題が生じることがあります。これは、次の理由によります。

- モバイル・デバイスでOracle Portalのアクセスに使用されるURLは、Oracle Portalではなく、OracleAS Wirelessサービスを参照しています。したがって、モバイル・ブラウザでは、_debug=1パラメータを直接URLに付加することはできません。

- モバイル・デバイスで情報をレンダリングするには、レスポンス・ページが有効なOracleAS Wireless XMLであることが必要です。追加情報は有効なOracleAS Wireless XMLでない場合があるため、モバイルのレスポンス・ページのインラインに追加できません。

この問題を解決して_debugパラメータを使用するには、次のタスクを実行します。

1. OracleAS Wirelessに登録されているデフォルトのPortalサービスを使用するかわりに、ページに直接アクセスする新しいサービスをOracleAS Wirelessサーバーに作成します。URLは、次のフォーマットで指定します。

http://<host.domain>:<port>/portal/pls/portal/MyGroup/MyPage?_debug=1

2. モバイル・デバイスで、デフォルトのPortalサービスではなく、新しいサービスをリクエストします。

3. サーブレットのログ・ファイルを表示して、記録されたパフォーマンス情報を調べます。この情報は、次のようなフォーマットで表示されます。

4/23/02 5:38 AM portal: [perf] Information for Portlet 33,31071.
Portlet Timing: 234 msecs (wait=0)
Timing Status:
XSLT Timing: null msecs
Caching information of portlet:
Portlet Cache status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], <I>File System Cache:-</I> MISS,NEW
From Cache:  <I>Web Cache:-</I> -,  <I>File System Cache:-</I> None
From Portlet: Cache Key: NORMAL, Cache Level: USER

4/23/02 5:38 AM portal: [perf] Information for Page 33%2C31060%2C33_31062
Elapsed Time: 2470 msecs
Page meta-time 7 msecs (wait = 994)
Page meta Cache Status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], Cache Expires: null secs, Age in Cache: null secs ,  <I>File System Cache:-</I> MISS,NEW
Login meta-time 1227 msecs (wait = 1)
Login meta Cache Status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], Cache Expires: null secs, Age in Cache: null secs

サポートに役立つモバイル情報

第G.1.20項「モバイル・デバイスからOracle Portalへのアクセスに関する問題」で説明したトラブルシューティングの手順を使用してもモバイル関連の問題を解決できない場合は、オラクル社カスタマ・サポート・センターに問い合せます。オラクル社カスタマ・サポート・センターを利用する際は、あらかじめ次の質問に対する回答を用意してください。

1. エラーはどのような現象ですか(エラー・メッセージが表示された、欠落しているレスポンスがあった、空白の画面が表示された、など)。

2. エラーはどのような状況で発生しますか。

- ユーザーはログオンしていましたか。

- 認証されたすべてのユーザーに同じ問題が発生していますか。

- その問題はパブリック・ユーザーにも発生していますか。

- ログオンの段階で問題は発生しますか。

- ログオンできるまでにどのくらい時間がかかりましたか。

- 通常どおりにログオンしましたか、あるいはログオンするよう指示されましたか。

- ページを表示するときに問題は発生しますか。

- ページの構造を説明してください。

- タイトルをパーソナライズできるポートレットはありますか。

- 通信ネットワーク上のOracleAS Wirelessを介さずに、標準のデスクトップ・ブラウザでページをプレビューできますか。

- 個々のポートレットを表示するときに問題は発生しますか。

- 問題が発生するのはすべてのモバイル・ページ、一部のページ、1ページのみのいずれですか。

3. 可能であれば、OracleAS Wirelessデバッグ・ツールを使用してPortalサービスを実行します。これには、特定のOracleAS Wirelessアクセスが必要です。詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。

4. 表G-13に示すログ・ファイルのいずれかに、問題が記録されていますか。

表G-13 エラー・ログ・ファイルとその場所

ログ・ファイル

場所

OracleAS Wirelessサーバーのログ・ファイル

ORACLE_INSTANCE/wireless/logs/sys_panama.logまたは/var/tmp/sys_panama.log

サーバーJVMの標準出力:

ORACLE_INSTANCE/opmn/logs/OC4J_Wireless_default_island/application.log

プロバイダJVMの標準出力:

ORACLE_INSTANCE/j2ee/OC4J_wireless/application-deployments/portal/WLS_OC4J_default_island/application.log

Oracle HTTP Serverのログ・ファイル

ORACLE_INSTANCE/Apache/Apache/logs/access_log/application.logおよびORACLE_INSTANCE/Apache/Apache/logs/error_log

Parallel Page Engineサーバーのログ・ファイル

ORACLE_INSTANCE/j2ee/WLS_PORTAL/application-deployments/portal/WLS_PORTAL_default_island_1/application.log

G.2.7 パフォーマンス・ログの有効化

Oracle Portalでパフォーマンス・ログを有効にするには、次の手順を実行します。

1. logging.xmlを開きます。これは、DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTALディレクトリに存在します。

2. 次のように、nameにoracle.portal、levelにNotification:16を指定してlogger要素を追加します。
<logger name="oracle.portal" level="NOTIFICATION:16"/>

注意:

パフォーマンス・ログを無効にするには、前述の行をlogging.xmlから削除するか、levelをERROR:1に変更します。

3. WLS_PORTALサーバーを再起動します。

ログ・エントリは、DOMAIN_HOME/servers/WLS_PORTAL/logsディレクトリのWLS_PORTAL-diagnostic.logファイルに書き込まれます。

注意:

- Oracle Portal中間層でmod_plsqlパフォーマンス・ログを有効にするには、httpd.confファイルのLogLevelディレクティブをinfoに設定します。このファイルは、ORACLE_INSTANCE/config/OHS/ohs_component_name (デフォルトのOHSコンポーネント名はohs1)に存在します。
LogLevelディレクティブを有効にするには、さらにhttpd.confファイルのOraLogModeディレクティブをapacheに設定してOHSサーバーを再起動します。

詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverのログ・ディレクティブに関する項を参照してください。

- Oracle Web Cacheでパフォーマンス・ログを有効にするには、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のアクセス・ログの構成に関する項の説明に従ってアクセス・ログを構成します。

G.3 さらにサポートが必要な場合

次の場所のOracle MetaLinkには、さらに多くの解決策が掲載されています。

http://metalink.oracle.com

ここでも問題の解決策が見つからない場合は、オラクル社カスタマ・サポート・センターに問い合せてください。

オラクル社カスタマ・サポート・センターに問題のトラブルシューティングを依頼する場合は、次の手順を実行してください。

1. Oracle Portal Diagnostics Assistantを実行します。
Oracle Portal Diagnostics Assistantを使用して生成されたレポートを調べると、ポータル関連の問題を診断できます。詳細は、第G.2.5項「Oracle Portal Diagnostics Assistantの使用」でも説明しています。

2. オラクル社カスタマ・サポート・センターに問い合せます。
ポータルにアクセスできない原因が特定できない場合は、オラクル社カスタマ・サポート・センターに問い合せます。オラクル社カスタマ・サポート・センターが問題のトラブルシューティングを行う際に役立つ、次の情報を用意してください。

- Oracle Portal Diagnostics Assistantで生成されたZIPファイル。

- 実行したコマンドライン・スクリプト(ptlconfigなど)と使用したすべてのパラメータの詳細。

- Oracle Fusion Middlewareコンポーネントがどのように構成されているかを示す、おおまかなネットワーク図。

関連項目:

Microsoft Windows (32ビット)用Oracle Fusion Middlewareのリリース・ノート(OTNのhttp://www.oracle.com/technology/documentation/index.htmlで入手可能)

索引
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X

A

アクセス

適用, 7.1.4

モデル, 7.1.4

アクセス制御リスト, 7.1.9.2, 7.1.9.4, 12.4.1.1.2, 12.4.1.1.3, 12.6.1.2 アクセス

ポート情報, 8.4

ACL, 7.1.9.4 動作ログのビュー, 8.3.3 動作レポート, 8.3 追加

サブスクライバ, F.2.3, F.5

addsub.csh, F.8 OmniPortletの管理

キャッシュの構成, E.2.1.3

OmniPortletの構成, E.2

リポジトリの構成, E.2.1.2

HTTPSアクセス用のライブラリのコピー, E.2.1.4

Webクリッピングの管理

セキュリティの構成

信頼できるサイトの証明書の追加, 7.1.12.1

詳細セキュリティ・オプション(ASO), 7.1.12.2

Webクリッピング・ポートレットの構成, E.1 Webクリッピング・リポジトリの構成, E.1.1 手動でのキャッシュ構成, E.1.4.1 手動でのプロキシの設定, E.1.3 承認されていない外部Webサイトからのクリッピングの制限, E.1.3.1 詳細セキュリティ・オプション(ASO)パラメータの設定, 7.1.12.2 Webクリッピングの「プロバイダ・テスト・ページ」の使用

詳細セキュリティ・オプション(ASO), 7.1.12.2

管理

アクセス, 7.3.2.3.6

グローバル権限, 7.1.3.1

管理ツール, 5.1.2 管理者ロール

例, 7.1.7.10.1

拡張検索リンク

構成, 10.2.1.3

デフォルト, 10.1.3

「拡張検索」ポートレット, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

デフォルト, 10.1.3

インターネット検索エンジン・リンク, 10.2.1.4

有効化または無効化されたOracle Text, 10.3.1

検索結果ページ, 10.2.1.1

エージェント

Directory Integration and Provisioning, 7.1.7.3.4

別名

Oracle Web CacheおよびSSLのサイト, 7.3.2.1.4

アプリケーション・エンティティ, 7.1.7.3.1

パスワード, 7.3.2.3.10

Application Server Control

ログ・ファイルの表示, G.2.4

ポート情報の表示, 8.4

アプリケーション・サービス・プロバイダ, F.1.1 application.log, G.2.3.1

OmniPortletプロバイダ, G.1.18

アプリケーション

mod_osso, 7.1.9.7.1

セキュリティ, 7.1.9.7

外部に対するセキュリティ, 7.1.9.7.2

承認

BPELプロセス定義の作成, 5.5.3

BPELプロセス定義の削除, 5.5.5

BPELプロセス定義の編集, 5.5.4

アーキテクチャ

セキュリティ, 7.1.1, 7.1.7

ASP, F.1.1

ユーザーとグループ, F.4

対象読者, はじめに AUTHENTICATED_USERSグループ, 7.1.2.2 認証

Basic, 7.3.1.3.1

拡張, 7.3.1.3.2

HMAC, 7.3.1.3.1

モデル, 7.1.4

認可, 7.1.4

モデル, 7.1.4

AUTO_FILTERフィルタ

文字セット変換, 10.3.3.7

MIMEタイプ変換, 10.3.3.7

機能しない, 10.3.7

ライブラリ・パスの設定, 10.3.2

ドキュメント索引とURL索引に使用, 10.3.3.1

AUTO_FILTER_FORMAT

API定数, D.3.2

設定, 10.3.3.7

B

基本的なページ管理

ページ・グループ割当ての変更, 5.3.6

個人用ページの作成, 5.3.3

状況依存ヘルプ・リンクの削除, 5.3.12

デフォルト・ホームページの設定, 5.3.1

アップロード・ファイルの最大ファイル・サイズの設定, 5.3.5

ユーザーのログアウト時に表示されるページの設定, 5.3.10

システムのデフォルト・スタイルの設定, 5.3.2

アップロード・ファイルに割り当てる総容量の設定, 5.3.4

エラー・メッセージ・ページの指定, 5.3.8

デフォルトのDOCTYPE設定の指定, 5.3.11

基本検索ボックス

デフォルト, 10.1.3

有効化または無効化されたOracle Text, 10.3.1

検索結果ページ, 10.2.1.1

「基本検索」ポートレット, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

「拡張検索」リンク, 10.2.1.3

デフォルト, 10.1.3

有効化または無効化されたOracle Text, 10.3.1

検索結果ページ, 10.2.1.1

BPEL

メッセージ・ペイロード, 5.5.6, 5.5.7

プロセス定義

作成, 5.5.3

削除, 5.5.5

編集, 5.5.4

ブラウザ設定

トラブルシューティング, G.1.15, G.1.16

ブラウザ

Oracle Portal,へのアクセス 5.2.1

C

CA, 1.1.2, 7.1.9.10, 7.3.2.1.4, 7.3.2.1.4

キャッシュ

Oracle Internet Directory, 7.1.7.3.4

Oracle Web Cache, 8.2.2.4

ポータル・キャッシュ, 8.2.2.3

「Cache Operations」ページ, OracleAS Web Cache Manager, 9.1.3.2.1 cacheEncryptionKey, 5.6.9.1 cache.xmlファイル

Webクリッピング, E.1.4.1

キャッシュ

構成

Webクリッピング, E.1.4.1

OmniPortletの構成, E.2.1.3 OmniPortlet, E.2.1.3 パフォーマンスの向上, B.1 Webクリッピング, E.1.4 cachjsub.sql, B.1, B.1 事例

仮想プライベート・ポータル, F

カテゴリ・ページ, G.1.3 証明書

信頼できる証明書の変更, 7.3.2.1.4

ウォレットの作成, 5.5.2.1.2, 7.3.2.1.4

リクエストのエクスポート, 7.3.2.1.4

サーバーのユーザー証明書のインポート, 7.3.2.1.4

信頼できる証明書のインポート, 7.3.2.1.4

Oracle Wallet Manager, 5.5.2.1.2, 7.3.2.1.2, 7.3.2.1.4

リクエスト, 7.3.2.1.4

信頼できる, 7.3.2.1.4

認証局, 1.1.2, 7.1.9.10, 7.3.2.1.4, 7.3.2.1.4 証明書ファイル, 7.3.2.1.4, 7.3.2.1.5 変更

ページ・グループ割当て, 5.3.6

文字セットの索引作成, 10.3.3.7 「Clustering」ページ, OracleAS Web Cache Manager, 9.1.3.2 資格証明を管理するためのコマンド, 6.11.2.2 commit_syncプロシージャ, 10.3.5.2, D.1.2 通信

HMAC, 7.3.1.3.1

通信セキュリティ

プロバイダ用, 7.1.9.3

完全

同期, F.6.1.3

コンポーネント

移行, 12.9.3

構成

SSL, 7.3.2.1

OmniPortletの構成, E.2 Webクリッピング・ポートレットの構成, E.1 Webクリッピング・リポジトリの構成, E.1.1 コンテナ

グループ, 7.1.7.3.1

コンテンツ

移行, 12.9.5

コンテンツ・キャッシュ, 1.3.2 状況依存ヘルプ・リンク, 5.3.12

削除, 5.3.12

Cookie

OraDAVの有効期限, 7.1.14.1

Cookieドメイン

すべての中間層サーバーに送信するための適用範囲の変更, B.3.2

作成

カテゴリ・ページ, G.1.3

既存ユーザーの個人用ページ, 5.3.3.2

新しいユーザーの個人用ページ、自動, 5.3.3.1

個人用ページ, 5.3.3

パースペクティブ・ページ, G.1.3

ctxcrind.sql, 10.3.4.1, 10.3.4.1, 10.3.7, F.7.5 ctxdrind.sql, 10.3.4.3 CTXSYSスキーマ, 10.3.2, 10.3.3.2, 10.3.3.3 「カスタム検索」ポートレット, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

「拡張検索」リンク, 10.2.1.3

デフォルト, 10.1.3

インターネット検索エンジン・リンク, 10.2.1.4

有効化または無効化されたOracle Text, 10.3.1

検索結果ページ, 10.2.1.1

D

DAD

構成, 5.6.4

DADエントリ

新規作成, A.2

dads.conf

DAD名の更新, A.2

データ

エクスポート, 12.4.1.1

データ・ソース

OmniPortlet SQL, E.2.4

データベース・オブジェクト・スキーマ, 12.9.3 データベース・プロバイダ, 13.1.2 DataDirect JDBCドライバ, E.2.4

OmniPortletでの登録, E.2.4.2

DBAグループ, 7.1.2.2 DBPreferenceStore, B.9 デフォルト・ホームページ, 5.3.1

グループ, 5.3.1.2

設定, 5.3.1

システム, 5.3.1.1

ユーザー, 5.3.1.3

デフォルト・スキーマ, 7.1.2.3

PORTAL, 7.1.2.3

PORTAL_APP, 7.1.2.3

PORTAL_DEMO, 7.1.2.3

PORTAL_PUBLIC, 7.1.2.3

Delegated Administration Services, 7.1.7.5

mod_ossoおよびOracleAS Single Sign-On, 7.1.7.5.2

デルタ

同期, F.6.1.2

設計時ページ, 12.9.5 開発インスタンス, 12.9.5 診断レポート, G.2.5 Directory Integration Platform, F.6.4

グローバル設定, 7.3.1.1.2

仮想プライベート・ポータル, F.6.4

ディレクトリ同期サブスクリプション

Oracle Internet Directoryエントリ 7.1.7.3.1

ディレクトリ同期プロビジョニング, 7.1.7.4 DIT構造

グループ 7.1.7.3.3

ユーザー, 7.1.7.3.1

ニックネーム属性, 7.2.2.1

dmsLogging, 5.6.9.1 文書型

グローバル・デフォルトの設定, 5.3.11

ドキュメント索引, 10.3.3.1

無効化, 10.3.7

エラー, 10.3.10, 10.3.11.5, 10.3.12.1

get_use_doc_indexファンクション, D.2.6

set_use_doc_indexプロシージャ, D.1.15

タイムアウト・エラー, 10.3.13.1

valid_doc_indexプロシージャ, D.2.8

E

ECID

「実行コンテキスト識別子」を参照, G.2

embldip.csh, F.8 エミュレーション・ユーティリティ, 12.4.1.1.3 enableWebCacheStaticRules, 5.6.9.1 有効化

ホスティング, F.2.1, F.3

ロケール, 5.10.2

地域, 5.10.2

仮想プライベート・ポータルの有効化

インストール前のチェックリスト, F.2.6

enblhstg.csh, F.8 拡張認証, 7.3.1.3.2 enhancedAuthentication, 7.3.1.3.2 Enterprise Manager

「Oracle Enterprise Manager」を参照, 8

環境変数, 7.3.1.3.1, 7.3.1.3.2 エラー・メッセージ・ページ

指定, 5.3.8

error_log, G.2.3.2 エラー

Oracle Text索引, 10.3.10

Oracle Textはインストールされていません, 10.2.2.1

トラブルシューティング, G

イベントのログ記録, 8.3.1 event_log, G.2.3.6 イベント

ディレクトリ同期, 7.1.7.4

実行コンテキスト識別子(ECID), G.2 エクスポート, 12.4.1.1

アクセス制御リスト, 12.4.1.1.2, 12.4.1.1.3

データ, 12.4.1.1

エクスポートとインポート

エクスポートとインポートの機能, 12.1

マニフェスト, 12.1

中間層のバージョン, 12.2.1

opeasst.csh, 12.4.1.1.3, 12.4.1.1.3

トランスポート・セット, 12.1

F

連携型Portalアダプタ

セキュリティ, 7.1.13

FilePreferenceStore, B.9 Oracle Portal,に関する情報の検索 5.2 ファイアウォール

分離されたクラスタ・メンバー, 9.1.3

外部から内部への通信の無効化, 9.1.3.3

外部および内部のOracleAS Web Cacheインスタンス, 9.1.3.1

Fusion Middleware Control

Oracle Portalの監視, 8.1

使用, 8.1

Fusion Middleware Portal Developer Kit

ログ, G.2.3.4

G

開始

Oracle Portal, 5.1

Oracle Textの要旨, 10.2.2.2, 10.3.7 グローバル非アクティビティ・タイムアウト, 7.1.7.1.2 グローバル権限, 7.1.3.1 グローバル設定, 7.3.1.1

Directory Integration Platformの同期化, 7.3.1.1.2

グループ作成ベースのDN, 7.3.1.1.3

グループ検索ベースのDN, 7.3.1.1.4

Oracle Internet Directoryのキャッシュの更新, 7.3.1.1.1

Global Unique Identifier, 12.9.5 用語集, はじめに グループ

デフォルト・ホームページ, 5.3.1.2

Oracle Instant Portal, 7.1.2.2, 7.1.2.2

グループ権限

グローバル権限, 7.1.3.1

グループのデフォルト・ホームページ, 5.3.1.2

設定, 5.3.1.2

groupOfNames

グループのサブスクリプション・プロファイル, 7.1.7.4.1

groupOfNamesオブジェクト・クラス

属性, 7.1.7.3.3, 7.1.7.3.3

groupOfUniqueNamesオブジェクト・クラス, 7.1.7.3.3

属性, 7.1.7.3.3, 7.1.7.3.3

グループ

権限の割り当て, 7.1.7.10.1

Oracle Internet Directoryの属性, 7.1.7.3.3

AUTHENTICATED_USERS, 7.1.2.2

変更イベント, 7.1.7.4

Oracle Internet Directoryのコンテナ, 7.1.7.3.1

作成, 7.1.7.10.1

作成ベースのDN, 7.3.1.1.3

DBA, 7.1.2.2

デフォルト, 7.1.2.2

DIT構造, 7.1.7.3.3

ロールとして有効にする, 7.1.7.10.1

「グループ」ポートレット, 7.1.7.8

Oracle Internet Directory, 7.1.7.3.1

値リスト, 7.1.7.3.5

Portalグループ・プロファイル, 7.1.7.9

PORTAL_ADMINISTRATORS, 7.1.2.2

PORTAL_DEVELOPERS, 7.1.2.2

ポートレットへのアクセス, 7.1.7.5.1

PORTLET_PUBLISHERS, 7.1.2.2

パブリック, 7.1.7.10

RW_ADMINISTRATOR, 7.1.2.2

RW_BASIC_USER, 7.1.2.2

RW_DEVELOPER, 7.1.2.2

RW_POWER_USER, 7.1.2.2

検索ベースのDN, 7.3.1.1.4

生成済, 7.1.2.2

サブスクリプション・プロファイルの更新, 7.1.7.4.1

GUID, 12.9.5 ガイド, はじめに

H

Hashed Message Authentication Code, 7.3.1.3.1

HMAC, 7.3.1.3.1

HMACキー

設定, 13.2.2

ホスト名

サイトの定義, 7.3.2.1.5

ホスティング

有効化, F.2.1

HTMLテンプレート, 12.8.1.8 httpd.conf, 11.4

定義, A.1

組み込まれたoradav.confファイル, 5.11

HTTPS

証明書リクエスト, 7.3.2.1.4

プロバイダとの通信, 7.1.9.10

完全, 7.3.2.1.5

構成の概要, 7.3.2.1.1

ロード・バランシング・ルーターによる構成, 7.3.2.1.6

ウォレットの作成, 5.5.2.1.2, 7.3.2.1.4

Oracle Internet Directoryのネットワーク接続, 7.3.2.2

LDAPS, 7.3.2.3.9

Oracle Web Cache, 7.3.2.1.4

OracleAS Single Sign-On, 7.3.2.1.2

問合せパスのURLの更新, 7.3.2.1.2

ロード・バランシング・ルーターの使用, 7.3.2.1.6

httpsports, 5.6.9.1

I

IETF(RFC 2798), 7.1.7.3.2, 7.1.7.3.3

インポート

アクセス制御リスト, 12.6.1.2

inctxgrn.sql, 10.2.2.1, 10.3.3.3, 10.3.3.4 索引

Oracle Text, 10.3.4, 10.3.6, 10.3.8, 10.3.9, 10.3.10

inetOrgPersonオブジェクト・クラス, 7.1.7.3.2

属性, 7.1.7.3.2

INFRA_ORACLE_HOME, 1.1.2 INSOフィルタ

(非推奨)「AUTO_FILTER」を参照, 10.3.2

インストール

デフォルト・グループ, 7.1.2.2

デフォルト・スキーマ, 7.1.2.3, 7.1.2.3

デフォルト・ユーザー, 7.1.2.1

インターネット検索エンジン・リンク

構成, 10.2.1.4

デフォルト, 10.1.3

無効化ベースのキャッシュ, B.1 無効化ジョブ

構成, B.1

無効化メッセージ, B.1, B.1 無効化ベースのキャッシュ

OmniPortlet, E.2.1.3

Webクリッピング, E.1.4

無効化

強い無効化と弱い無効化, B.1

J

J2EEセキュリティ, 7.1.6

Java Portal Development Kit (JPDK), G.2.3.1

JAZN-LDAP, 7.3.1.3.2

JDBC-ODBCドライバ, E.2.4

JNDI

環境変数, 7.3.1.3.1, 7.3.1.3.2

JPDK, G.2.3.1 JPDKメッセージ, G.2.3.1 JPS, 1 jspRoot, 5.6.9.1 jspSrcAlias, 5.6.9.1

K

キー・ストア, 13.2.2

管理用SQLスクリプト, 13.2.2

WSRPプロデューサのキーストア, 7.1.10.1

L

言語

言語サポートの構成, 5.10

Oracle Textのマルチレクサー, 10.3.3.5

「言語の設定」ポートレット, 5.10

LDAPS

Oracle Internet Directory, 7.3.2.3.9

レクサー・プリファレンス, 10.3.3.2 値リスト

ユーザーとグループ, 7.1.7.3.5

ロード・バランシング・ルーター

リクエストの受取りと転送, 9.1.4

ロード・バランシング・ルーター

リクエストの受取りと転送, 6.3.2

Network Address Translationバウンス・バックの構成, 6.3.2

アクセスのためのOracle Portalの構成, 6.3.2

SSLの構成, 7.3.2.1.6

無効化リクエストの処理, 6.3.2

複数の中間層の設定, 6.3

SSL, 7.3.2.1.6

LocalePersonalizationLevel

OmniPortletの設定, E.2.2

ロケール, 5.10.2

使用の有効化, 5.10.2

logcfg.sql, G.2.3.5 logcrind.sql, 10.3.9.2 ログイン周期, 7.3.1.3.1, 7.3.1.3.2 「ログイン」ポートレット

SSL, 7.3.2.3.8

ログ

診断ログ・ファイル, 8.2.2.7

Fusion Middleware Portal Developer Kit, G.2.3.4

グローバル権限, 7.1.3.1

Java Portal Development Kit (JPDK), G.2.3.1

Oracle Metadata Repository, G.2.3.5

Oracle Web Cache, G.2.3.6

Parallel Page Engine, G.2.3.3

ポータルの動作ログ・ファイル, 8.3

Portalサービス, G.2.3.2

Oracle Portalのための設定, 8.2.2.7

Log Viewerの使用, G.2.4

M

管理, 8

管理

ASPのユーザーおよびグループ, F.6.1

最大キャッシュ, B.1 MaxClients, 11.4 アップロード・ファイルの最大ファイル・サイズ, 5.3.5 maxParallelPagePortlets, 5.6.9.1 maxParallelPortlets, 5.6.9.1 MaxRequestsPerSession, G.1.6 メモリー関連の問題, G.1.11 索引に使用するメモリー・サイズ, 10.3.5.3 メッセージ認証, 7.3.1.3.1

プロバイダのセキュリティ用, 7.1.9.9

メッセージの暗号化

プロバイダのセキュリティ用, 7.1.9.3.3

メッセージ

JPDK, G.2.3.1

MetaLink, G.3 コンテンツの移行, 12.9.5 Portal DBプロバイダの移行, 12.9.3 MIMEタイプの索引作成, 10.3.3.7 minTimeout, 5.6.9.1 mod_dav, 5.11 mod_oradavモジュール, 5.11 mod_osso

Delegated Administration ServicesおよびOracleAS Single Sign-On, 7.1.7.5.2

パートナ・アプリケーション用, 7.1.9.7.1

監視

Oracle Portalのコンポーネント, 8

パッケージの保護, 7.3.2.3.7

マルチレクサー

Oracle Textでサポートされる, 10.3.3.5

N

Network Address Translation (NAT)バウンス・バック, 6.3.2

ネットワーク接続

Oracle Internet Directory, 7.3.2.2

ニックネーム属性, 7.2.2.1 N層認証, 7.1.2.3

O

オブジェクト権限, 7.1.3.2

ODBCデータ・ソース, E.2.4

ODM, F.2.7

使用, F.2.7

offlinePathHtml, 5.6.9.1 offlinePathMxml, 5.6.9.1 OIP_AVAILABLE_USERS, 7.1.2.2 OIP_USER_ADMINS, 7.1.2.2 OmniPortlet

application.log, G.1.18

構成の問題, G.1.18

エクスポートとインポート, 12.8.5.1

登録, E.2.3

DataDirect JDBCドライバの登録, E.2.4.2

セキュリティ, 7.1.11

OmniPortletの管理

構成, E.2

キャッシュの構成, E.2.1.3

リポジトリの構成, E.2.1.2

HTTPSアクセス用のライブラリのコピー, E.2.1.4

OmniPortletプロバイダ

登録, E.2.3

OmniPortlet SQLデータ・ソース, E.2.4 オンライン・ヘルプ・システム, 5.10.2 opmn.xml, G.1.10 最適化

AUTO_FILTER, 10.3.3.7

Oracle Text索引, 10.3.5

optjsub.sql, D.3.3 Oracle Application Server

構成ファイル, A.6

ポート情報の表示, 8.4

Oracle Cache

Webクリッピングによる構成, E.1.4.1

Webクリッピング, E.1.4

Oracle Certificate Authority, 1.1.2, 7.1.9.10, 7.3.2.1.4, 7.3.2.1.4 Oracle Delegated Administration Services

値リスト, 7.1.7.3.5

権限, 7.1.7.5.1

パブリック・ロール, 7.1.7.10

Oracle Directory Integration and Provisioning

エージェント, 7.1.7.3.4

Oracle Directory Integration Platform, 7.1.7.4

要件, 7.1.7.4

Oracle Directory Manager, F.2.7

使用, F.2.7

Oracle Enterprise Manager, 8

Fusion Middleware Controlの使用, 8.1

Oracle Fusion Middleware

構成ファイル, A

Oracle Help for the Web, 5.10.2 Oracle Instant Portal

グループ, 7.1.2.2, 7.1.2.2

ユーザー, 7.1.2.1

Oracle Internet Directory, 7.1.7.3

アプリケーション・エンティティ, 7.1.7.3.1

キャッシュ, 7.1.7.3.4

ネットワーク接続でのSSLの構成, 7.3.2.2

デフォルト・ユーザー・アカウント, 7.1.7.3.1

ディレクトリ同期サブスクリプション・エントリ, 7.1.7.3.1

エントリ, 7.1.7.3.1

グループ属性, 7.1.7.3.3

グループ・コンテナ, 7.1.7.3.1

グループのDIT構造, 7.1.7.3.3

groupOfUniqueNames, 7.1.7.3.3

グループ, 7.1.7.3.1

inetOrgPerson, 7.1.7.3.2

LDAPS, 7.3.2.3.9

ニックネーム属性, 7.2.2.1

orclGroup, 7.1.7.3.3

orclUser, 7.1.7.3.2

orclUserV2, 7.1.7.3.2

情報を更新するための権限, 7.1.7.5.1

キャッシュされたパラメータの更新, 7.3.1.1.1

ユーザーとグループの値リスト, 7.1.7.3.5

ユーザー属性, 7.1.7.3.2

ユーザーのDIT構造, 7.1.7.3.1

Oracle JDBCドライバ, E.2.4 Oracle Metadata Repository, 1.1.2, 1.2.1, 2.1.7.2.1, 3.1.2, 3.1.3, 5.1.1, 5.6.4, 5.10.1, 6.3.2, 6.4.2, 8.3, G.1.1, G.2.3.5, G.2.4

logcfg.sql, G.2.3.5

ログ, G.2.3.5

Oracle MetaLink, G.3 Oracle Net Services, 11.6 Oracle Portal

ブラウザでのアクセス, 5.2.1

キャッシュ設定, 8.2.2.3

ユーザーおよびグループの作成, 7.1.7

情報の検索, 5.2

開始, 5.1

ログ構成の設定, 8.2.2.7

Enterprise Managerによる監視, 8

トラブルシューティング, G

アップグレード, 3

ユーザーとグループの値リスト, 7.1.7.3.5

Web Cacheの設定, 8.2.2.4

Oracle Portal Diagnostic Assistant

レポート, G.2.5

使用, G.2.5

Oracle Portalの「ログ構成」ページ, 8.2.2.7 Oracle Portalのログ・レジストリ, 8.3 Oracle Secure Enterprise Search

Oracle Portalでの構成, 10.2.3

概要, 10.4.1

ポートレット, 10.4.2

Oracle Text

プロキシ設定の構成, 10.2.2.4

ベースURLの構成, 10.2.2.3

有効化と無効化, 10.2.2.1

索引, 10.3.4, 10.3.6, 10.3.8, 10.3.9, 10.3.10

概要, 10.3

前提条件, 10.3.2

結果オプションの設定, 10.2.2.2

テーマと要旨, 10.2.2.2

wwv_context API, D

Oracle Text索引

作成と削除, 10.3.4

エラー, 10.3.10, 10.3.11, 10.3.12.1

管理API, D

監視, 10.3.9

最適化, 10.3.5.7

再作成, F.7.5

URLコンテンツの検索, 10.3.6

ステータス, 10.3.8

同期, 10.3.5.1

トラブルシューティング, 10.3.13

Oracle Ultra Search

ポートレット, 10.4.1.1

Oracle Universal Installer, 1.1.2 Oracle Wallet Manager, 5.5.2.1.2, 7.3.2.1.2, 7.3.2.1.4 Oracle Web Cache

SSLポートの構成, 7.3.2.1.4, 7.3.2.1.5

OmniPortletでの構成, E.2.1.3

サイトの定義, 7.3.2.1.4

OmniPortlet構成時の問題, G.1.19

ログ, G.2.3.6

Oracle Portalのための設定, 8.2.2.4

SSL用の公開アドレスとプロトコルの指定, 7.3.2.1.5

SSL, 7.3.2.1.4

ORACLE_HOME, 1.1.2

表記規則, 1.1.2, 1.1.2

区別, 1.1.2

OracleAS Single Sign-On, 7.1.7.1

対応する言語のインストール, 5.10.2

Delegated Administration Servicesおよびmod_osso, 7.1.7.5.2

SSL, 7.3.2.1.2

ssoreg, 7.3.2.1.2, 7.3.2.1.4, 7.3.2.1.5, 7.3.2.1.6

OracleAS Web Cache

Managerおよびクラスタの構成, 9.1.3.2

Managerおよび伝幡の構成, 9.1.3.2.1

oracle.http.configfile, G.1.19 OraDAV

セキュリティ, 7.1.14

セッションCookieの有効期限, 7.1.14.1

SSL, 7.1.14.2

OraDAVの実装, 5.11 oradav.conf

DAV構成ファイル, 5.11.1

ORCLADMINユーザー, 7.1.2.1 orclGroupオブジェクト・クラス, 7.1.7.3.3

属性, 7.1.7.3.3

orclUserオブジェクト・クラス, 7.1.7.3.2 orclUserV2オブジェクト・クラス, 7.1.7.3.2

属性, 7.1.7.3.2

オリジン・サーバー

SSL, 7.3.2.1.5

アウト・オブ・ボックスのポータル, F.3 概要

仮想プライベート・ポータル, F.2

P

ページ・グループ

エクスポート, 12.4.1.1

ページ・グループ割当て, 5.3.6

変更, 5.3.6

ページ・グループ

グローバル権限, 7.1.3.1

ページ

グローバル権限, 7.1.3.1

パラレル索引の同期化, 10.3.5.3 Parallel Page Engine

SSLを部分的に構成, 7.3.2.1.4

完全SSL, 7.3.2.1.5

ログ, G.2.3.3

パートナ・アプリケーション

mod_ossoによって保護される, 7.1.9.7.1

セキュリティ, 7.1.9.7.1

パスワード

変更, 6.11

パスワード

アプリケーション・エンティティ, 7.3.2.3.10

スキーマ, 7.1.7.10.1

同期, F.6.1.1

パスワード

保護, 7.3.2.3.2

ペイロード

BPEL用, 5.5.6, 5.5.7

pda.cmdスクリプト, G.2.5 pda.cshスクリプト, G.2.5 PDK

プリファレンス・ストア移行/アップグレード・ユーティリティ, 6.3.6, B.9

「Oracle Fusion Middleware Portal Developer Kit」を参照, G.2.3.4

PDK-Java, 6.3.6, B.9 パフォーマンスの問題, G.1.6 個人用ページ

新しいユーザー用に自動作成, 5.3.3.1

新しいユーザー用に作成, 5.3.3.2

個人用ページ, 5.3.3

作成, 5.3.3, 5.3.3

パーソナライズ・フォーム

イベントの順序, 13.4.2

パースペクティブ・ページ, G.1.3 PL/SQL HTTPアダプタ, 13, 13.1

概要、13.1.1

PlsqlAfterProcedure, G.2.2.1 PlsqlBeforeProcedure, G.2.2.1 PlsqlSessionCookieName

値の変更, A.2

poolSize, 5.6.9.1 ポート

デフォルトの変更, 6.1

サイトのSSLの定義, 7.3.2.1.5

情報の表示, 8.4

PORTAL

スキーマのパスワード, 7.1.7.10.1

ポータル

アウト・オブ・ボックス, F.3

テンプレート, 12.8.1.7

アップグレード, 3

ポータル・キャッシュ

設定, 8.2.2.3

ポータル・キャッシュ

構成, 5.6.6, 5.6.7

ポータル・キャッシュ

コンテンツ・キャッシュ, 1.3.2

セッション・キャッシュ, 1.3.2

理解, 1.3.2

Portal DBプロバイダ

グローバル権限, 7.1.3.1

移行, 12.9.3

Portal依存性設定

Web Cache, 8.2.2.6

PORTALスキーマ, 7.1.2.3 Portalサービス

ログ, G.2.3.2

Portalテンプレート, 12.8.1.7 PORTAL_ADMINISTRATORSグループ, 7.1.2.2 PORTAL_APPスキーマ, 7.1.2.3 portal_dads.conf, A.2 PORTAL_DEMOスキーマ, 7.1.2.3 PORTAL_DEVELOPERSグループ, 7.1.2.2 PORTAL_PUBLICスキーマ, 7.1.2.3 PORTLET_PUBLISHERSグループ, 7.1.2.2 ポートレット

アプリケーションのセキュリティ, 7.1.9.7

グループ, 7.1.7.8

ログイン, 7.3.2.3.8

Portalグループ・プロファイル, 7.1.7.9

Portalユーザー・プロファイル, 7.1.7.7

権限, 7.1.3.1

プログラムによるセキュリティ, 7.1.9.8

プロバイダ権限, 7.1.3.4

セキュリティ, 7.1.9

ユーザー, 7.1.7.6

ポートレット・スキーマ, 12.9.3 ポート

Oracle Portalへのアクセスに使用, 5.2.1

インストール後

セキュリティのチェックリスト, 7.3.2.3

PPEのパラメータ

cacheEncryptionKey, 5.6.9.1

dmsLogging, 5.6.9.1

enableWebCacheStaticRules, 5.6.9.1

httpsports, 5.6.9.1

jspRoot, 5.6.9.1

jspSrcAlias, 5.6.9.1

maxParallelPagePortlets, 5.6.9.1

maxParallelPortlets, 5.6.9.1

minTimeout, 5.6.9.1

offlinePathHtml, 5.6.9.1

offlinePathMxml, 5.6.9.1

poolSize, 5.6.9.1

proxyHost, 5.6.9.1

proxyPort, 5.6.9.1

queueTimeout, 5.6.9.1

requesttime, 5.6.9.1

resourceUrlKey, 5.6.9.1

showError, 5.6.9.1

showPageDebug, 5.6.9.1

stall, 5.6.9.1

urlDebugMode, 5.6.9.1

urlDebugUsers, 5.6.9.1

useDeviceNameCacheKeys, 5.6.9.1

usePort, 5.6.9.1

useScheme, 5.6.9.1

versionOnSplashScreen, 5.6.9.1

x509certfile, 5.6.9.1

下処理

サブスクライバ, F.6.5

プリファレンス・ストア移行/アップグレード, B.9 プリファレンス・ストア移行/アップグレード・ユーティリティ, 6.3.6, B.9 PreferenceStore, B.9 事前チェック

失敗, 12.9.5

権限

グループへの割当て, 7.1.7.10.1

オブジェクトの抑制, 7.1.3.2

グローバル, 7.1.3.1

グローバル管理, 7.1.3.1

グローバル・ページ・グループ, 7.1.3.1

「ユーザーの作成」ページの割当てセクションを非表示にする, 7.1.7.10.1

OmniPortlet, 7.1.11

すべてのグループ権限, 7.1.3.1

すべてのログ, 7.1.3.1

すべてのページ・グループ, 7.1.3.1

すべてのページ, 7.1.3.1

すべてのPortal DBプロバイダ, 7.1.3.1

すべてのポートレット, 7.1.3.1

すべてのプロバイダ, 7.1.3.1

すべてのスキーマ, 7.1.3.1

すべての共有コンポーネント, 7.1.3.1

すべてのスタイル, 7.1.3.1

すべてのトランスポート・セット, 7.1.3.1

すべてのユーザー・プロファイル, 7.1.3.1

プロバイダ, 7.1.3.4

生成済, 7.3.2.3.4

シンプル・パラメータ・フォーム, 7.1.11

本稼働インスタンス, 12.9.5 プロパティ

enhancedAuthentication, 7.3.1.3.2

sharedKey, 7.3.1.3.1, 7.3.1.3.1, 7.3.1.3.2

保護されているリソース, 7.1.3 プロバイダ

権限, 7.1.3.4

プロバイダ・グループ

権限, 7.1.3.4

プロバイダ・グループ

グローバル権限コード, 7.1.3.4.1

オブジェクト権限コード, 7.1.3.4.2

プロバイダ

通信セキュリティ, 7.1.9.3

データベース・プロバイダとWebプロバイダ, 13.1.2

グローバル権限コード, 7.1.3.4.1

グローバル権限, 7.1.3.1

HTTPS通信, 7.1.9.10

メッセージ認証, 7.1.9.9

メッセージの暗号化, 7.1.9.3.3

オブジェクト権限コード, 7.1.3.4.2

コンポーネントへのパブリック・アクセスの取消し, 7.3.2.3.5

サーバー認証, 7.1.9.5

SSL, 7.1.9.11

provideruiacls.xml, 7.1.3.4 provider.xmlファイル

OmniPortlet, E.2.1.1, E.2.4.2

Webクリッピング, E.1.3, E.1.4.1

Webクリッピング・リポジトリ, E.1.1

プロビジョニング

イベント, 7.1.7.4

Oracle Internet Directoryのプロファイル・エントリ, 7.1.7.3.1

ユーザーやグループの変更イベント, 7.1.7.4

プロキシ・サーバー

使用するためのOracle Portalの構成, 6.5

Webクリッピングの構成, E.1.3

ドメイン, 6.5

Oracle Textで使用, 10.2.2.4

プロキシ設定

Webクリッピング, E.1.3

proxyHost, 5.6.9.1 proxyPort, 5.6.9.1 パブリック・ロール, 7.1.7.10

例, 7.1.7.10.1

Q

問合せパスのURL

iasconfig.xmlの更新, 7.3.2.1.2

queueTimeout, 5.6.9.1

R

リダイレクト

Oracle Portal URLの簡略化, 5.6.1

登録

OmniPortlet, E.2.3

OmniPortletプロバイダ, E.2.3

Webクリッピング・プロバイダ, E.1.2

削除

状況依存ヘルプ・リンク, 5.3.12

サブスクライバ, F.2.4, F.6.2

レポート

ポータルの動作, 8.3

requesttime, 5.6.9.1 リソース

保護されている, 7.1.3

resourceUrlKey, 5.6.9.1 リバース・プロキシ・サーバー

構成, 6.6

SSLの構成, 7.3.2.1.6

rmsub.csh, F.8 ロール

グループをロールとして有効にする, 7.1.7.10.1

例, 7.1.7.10.1

パブリック, 7.1.7.10

ルーター

ロード・バランスの構成, 6.3

RW_ADMINISTRATORグループ, 7.1.2.2 RW_BASIC_USERグループ, 7.1.2.2 RW_DEVELOPERグループ, 7.1.2.2 RW_POWER_USERグループ, 7.1.2.2

S

「保存された検索」ポートレット, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

sbrimtlx.sql, 10.3.3.2, 10.3.3.5, D.1.5, D.1.10

スキーマ

パスワード, 7.1.7.10.1

スキーマ・パスワード

変更, 6.11

スキーマ, 7.1.2.3

デフォルト, 7.1.2.3, 7.1.2.3

グローバル権限, 7.1.3.1

PORTAL, 7.1.2.3

PORTAL_APP, 7.1.2.3

PORTAL_DEMO, 7.1.2.3

PORTAL_PUBLIC, 7.1.2.3

スクリプト

cachjsub.sql, B.1

スクリプト

仮想プライベート・ポータル, F.8

検索オプション, 10

Oracle Portal検索ポートレットの構成, 10.2.1

Oracle Secure Enterprise Searchの構成, 10.2.3

Oracle Text検索ポートレットの構成, 10.2.2

構成方法の決定, 10.1.4

デフォルトの機能, 10.1.3

Oracle Portalの検索, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

Oracle Text, 10.1.1

Oracle Ultra Search, 10.1.2

検索結果

検索結果ページの選択, 10.2.1.1

すべてのページの結果の制限, 10.2.1.2

secupoid.sql, 7.3.2.3.9, 7.3.2.3.10, 7.3.2.3.10, B.2

Oracle Internet Directoryに接続するためのSSLの構成, B.2

実行, 7.3.2.3.9

セキュリティ, 7

概要, 7.1

アクセス制御リスト, 7.1.9.4

アクセスの適用, 7.1.4

管理ページへのアクセス, 7.3.2.3.6

アプリケーション・エンティティのパスワード, 7.3.2.3.10

アーキテクチャ, 7.1.1, 7.1.7

AUTHENTICATED_USERSグループ, 7.1.2.2

認可, 7.1.4

プロバイダの通信, 7.1.9.3

DBAグループ, 7.1.2.2

デフォルト・グループ, 7.1.2.2

デフォルト・スキーマ, 7.1.2.3

デフォルト・ユーザー・アカウント, 7.1.2.1

Delegated Administration Service, 7.1.7.5

Directory Integration and Provisioningエージェント, 7.1.7.3.4

ディレクトリ同期イベント, 7.1.7.4

ディレクトリ同期プロビジョニング, 7.1.7.4

DIT構造, 7.1.7.3.1

外部アプリケーション, 7.1.9.7.2

連携型Portalアダプタ, 7.1.13

グローバル管理権限, 7.1.3.1

グローバル・ページ・グループ権限, 7.1.3.1

グローバル権限, 7.1.3.1

グローバル設定, 7.3.1.1

Oracle Internet Directoryのグループ属性, 7.1.7.3.3

GROUP DELETEイベント, 7.1.7.4, 7.3.2.1.4

GROUP MODIFYイベント, 7.1.7.4, 7.3.2.1.4, 7.3.2.1.4

「グループ」ポートレット, 7.1.7.8

groupOfUniqueNamesオブジェクト・クラス, 7.1.7.3.3

プロバイダとのHTTPS通信, 7.1.9.10

inetOrgPersonオブジェクト・クラス, 7.1.7.3.2

J2EE, 7.1.6

WSRPプロデューサのキーストア, 7.1.10.1

Oracle Security Servicesの利用, 7.1.6

「ログイン」ポートレット, 7.3.2.3.8

モデル, 7.1.1

監視パッケージ, 7.3.2.3.7

オブジェクト権限, 7.1.3.2

OmniPortlet, 7.1.11

Oracle Directory Integration Platform, 7.1.7.4

Oracle Internet Directory, 7.1.7.3

Oracle Internet Directoryのキャッシュ, 7.1.7.3.4

OracleAS Single Sign-On, 7.1.7.1

OraDAVのセキュリティ, 7.1.14

ORCLADMINユーザー, 7.1.2.1

orclGroupオブジェクト・クラス, 7.1.7.3.3

orclUserオブジェクト・クラス, 7.1.7.3.2

orclUserV2オブジェクト・クラス, 7.1.7.3.2

概要, 7.1.1

パートナ・アプリケーション, 7.1.9.7.1

「Portalグループ・プロファイル」ポートレット, 7.1.7.9

「Portalユーザー・プロファイル」ポートレット, 7.1.7.7

PORTAL_ADMINISTRATORSグループ, 7.1.2.2

PORTAL_DEVELOPERSグループ, 7.1.2.2

PORTLET_PUBLISHERSグループ, 7.1.2.2

ポートレット, 7.1.9

インストール後のチェックリスト, 7.3.2.3

権限, 7.1.2

ポートレットのためのプログラム, 7.1.9.8

プロバイダのメッセージ認証, 7.1.9.9

プロバイダのコンポーネントへのパブリック・アクセス, 7.3.2.3.5

OIDパラメータ用キャッシュのリフレッシュ, 7.3.1.1.1

不要なオブジェクトの削除, 7.3.2.3.3

保護されているリソース, 7.1.3

RW_ADMINISTRATORグループ, 7.1.2.2

RW_BASIC_USERグループ, 7.1.2.2

RW_DEVELOPERグループ, 7.1.2.2

RW_POWER_USERグループ, 7.1.2.2

パスワードの保護, 7.3.2.3.2

生成済の権限, 7.3.2.3.4

サーバー認証, 7.1.9.5

OraDAVのセッションCookieの有効期限, 7.1.14.1

シンプル・パラメータ・フォーム, 7.1.11

プロバイダ用のSSL, 7.1.9.11

Oracle Internet Directoryのユーザー属性, 7.1.7.3.2

USER DELETEイベント, 7.1.7.4, 7.3.2.1.4

USER MODIFYイベント, 7.1.7.4, 7.3.2.1.4

「ユーザー」ポートレット, 7.1.7.6

ユーザー, 7.1.2

WWSEC_FLAT$表, 7.1.7.4, 7.3.2.1.4

サーバー認証

プロバイダのセキュリティ用, 7.1.9.5

セッション

OraDAVの有効期限, 7.1.14.1

セッション・バインド

Oracle Web Cacheでの有効化, 6.3.7, 7.3.2.1.4, 7.3.2.1.5

セッション・キャッシュ, 1.3.2 セッション

Cookie, B.3.2

設定

デフォルト・ホームページ, 5.3.1

グループのデフォルト・ホームページ, 5.3.1.2

アップロード・ファイルの最大ファイル・サイズ, 5.3.5

ユーザーのログアウト時に表示されるページ, 5.3.10

システムのデフォルト・ホームページ, 5.3.1.1

システムのデフォルト・スタイル, 5.3.2

アップロード・ファイルに割り当てる総容量, 5.3.4

ユーザーのデフォルト・ホームページ, 5.3.1.3

ユーザーのログアウト時に表示されるページの設定, 5.3.10 設定

ASPのユーザーおよびグループ, F.4.1

ユーザーとグループ, F.2.2

共有コンポーネント

グローバル権限, 7.1.3.1

共有キー, 7.3.1.3.1 shared_pool_sizeパラメータ, G.1.11 sharedKey, 7.3.1.3.1, 7.3.1.3.1, 7.3.1.3.2 シェル・スクリプト

ツール, 12.4.1.1.3

showError, 5.6.9.1 showPageDebug, 5.6.9.1 シンプル・パラメータ・フォーム

セキュリティ, 7.1.11

シングル・サインオン, 7.1.7.1

アプリケーションの認証, 7.1.9.7

サイト

別名, 7.3.2.1.4

SSL環境でOracle Web Cache用に定義, 7.3.2.1.4

SSLホスト名およびポートの定義, 7.3.2.1.5

サーバー・マッピング, 7.3.2.1.4, 7.3.2.1.5

指定

エラー・メッセージ・ページ, 5.3.8

エラー・メッセージ・ページの指定, 5.3.8 sql_traceパラメータ, G.2.2.2 SSL

証明書リクエスト, 7.3.2.1.4

完全, 7.3.2.1.5

構成の概要, 7.3.2.1.1

SSLポートの構成, 7.3.2.1.5

Oracle Web CacheのSSLポートの構成, 7.3.2.1.4

ロード・バランシング・ルーターによる構成, 7.3.2.1.6

ウォレットの作成, 5.5.2.1.2, 7.3.2.1.4

暗号化, 7.1.6

Oracle Internet Directoryのネットワーク接続, 7.3.2.2

プロバイダ用, 7.1.9.11

LDAPS, 7.3.2.3.9

Oracle Web Cache, 7.3.2.1.4

OracleAS Single Sign-On, 7.3.2.1.2

OraDAV, 7.1.14.2

オリジン・サーバー, 7.3.2.1.5

Parallel Page Engine、部分的, 7.3.2.1.4

公開アドレスとプロトコルの指定, 7.3.2.1.5

問合せパスのURLの更新, 7.3.2.1.2

ロード・バランシング・ルーターの使用, 7.3.2.1.6

プロバイダ, 7.1.9.10

SSLの構成, 7.3.2.1 SSL問合せパスのURL, 7.3.2.1.2 ssoreg, 7.3.2.1.2, 7.3.2.1.4, 7.3.2.1.5, 7.3.2.1.6 stall, 5.6.9.1 ステータス情報, 8.2.1, 8.2.1.4 STEM検索, 10.3.3.6 スタイル

グローバル権限, 7.1.3.1

サブスクライバ, F.2.3

追加, F.2.3, F.5

下処理, F.6.5

削除, F.2.4, F.6.2

サブスクリプション・プロファイル

更新, 7.1.7.4.1

同期

完全, F.6.1.3

デルタ, F.6.1.2

パスワード, F.6.1.1

syncasp.csh, F.8 同期化

Directory Integration and Provisioningエージェント, 7.1.7.3.4

Oracle Internet Directoryのエントリ, 7.1.7.3.1

手動, 10.3.5.3

コミット時, 10.3.5.2, 10.3.8, D.1.2

Oracle Text索引, 10.3.5

ユーザーやグループの変更イベント, 7.1.7.4

システム

デフォルト・ホームページ, 5.3.1.1

システムのデフォルト・ホームページ, 5.3.1.1

設定, 5.3.1.1

システムのデフォルト・スタイル, 5.3.2

設定, 5.3.2

T

TCP/IP, 6.4.1.3

テンプレート

HTML, 12.8.1.8

Portal, 12.8.1.7

地域, 5.10.2

使用の有効化, 5.10.2

textjsub.sql, D.3.3 textstat.sql, 10.3.5.1, 10.3.8 テーマと要旨

無効化, 10.3.7

Oracle Textの有効化, 10.2.2.2

ツール, 5.1.2

シェル・スクリプト, 12.4.1.1.3

トップ・レベルのページ, 12.9.5 トポロジ・ビューア, 8.2.3 アップロード・ファイルに割り当てる総容量, 5.3.4 トレース・ファイル

生成, G.2.2

トランスポート・セット

グローバル権限, 7.1.3.1

トラブルシューティング, G

ブラウザ設定, G.1.15, G.1.16

連携型Portalアダプタ, 13.5

ハンドルされていない例外エラー, G.1.17

信頼できる証明書, 7.3.2.1.4, 7.3.2.1.5

変更, 7.3.2.1.4

インポート, 7.3.2.1.4

信頼できる証明書

管理, 7.3.2.1.4

調整

Oracle Net Services, 11.6

U

Ultra Search

「Oracle Ultra Search」を参照, 10.4

ハンドルされていない例外エラー, G.1.17 UNIX

エミュレーション・ユーティリティ, 12.4.1.1.3

アップグレード, 12.9.5, F.7.5

ポータル, 3

アップロード・ファイル

割り当てる総容量, 5.3.4

URL索引, 10.3.3.1

無効化, 10.3.7

エラー, 10.3.10, 10.3.11.6, 10.3.12.2

get_use_url_indexファンクション, D.2.7

set_use_url_indexプロシージャ, D.1.16

タイムアウト・エラー, 10.3.13.1

valid_url_indexプロシージャ, D.2.9

URLの検索, 10.3.6 urlDebugMode, 5.6.9.1 urlDebugUsers, 5.6.9.1 useDeviceNameCacheKeys, 5.6.9.1 usePort, 5.6.9.1 ユーザー

デフォルト・ホームページ, 5.3.1.3

Oracle Instant Portal, 7.1.2.1

ORCLADMIN, 7.1.2.1

ユーザー・アカウント

生成済, 7.1.2.1

ユーザー証明書

インポート, 7.3.2.1.4

ユーザー・プロファイル

グローバル権限, 7.1.3.1

ユーザーのデフォルト・ホームページ, 5.3.1.3

設定, 5.3.1.3

user_dump_dest, G.1.17 ユーザー

Oracle Internet Directoryの属性, 7.1.7.3.2

変更イベント, 7.1.7.4

デフォルト, 7.1.2.1

「ユーザーの作成」ページの割当てセクションを非表示にする, 7.1.7.10.1

値リスト, 7.1.7.3.5

「Portalユーザー・プロファイル」ポートレット, 7.1.7.7

ポートレットへのアクセス, 7.1.7.5.1

パスワードの保護, 7.3.2.3.2

「ユーザー」ポートレット, 7.1.7.6

ユーザーとグループ

ASP, F.4

設定, F.2.2

useScheme, 5.6.9.1 使用

ODM, F.2.7

Oracle Directory Manager, F.2.7

ユーティリティ

プリファレンス・ストア移行/アップグレード, B.9

プリファレンス・ストア移行/アップグレード, 6.3.6, B.9

UTL_FILE_DIRパラメータ, G.2.3.5

V

有効化ベースのキャッシュ

Webクリッピング, E.1.4

versionOnSplashScreen, 5.6.9.1 表示

ポート情報, 8.4

仮想ホスト

構成, 6.4

Oracle Web Cacheの構成, 6.4.2

エントリの作成, 6.4.1

仮想プライベート・ポータル, F

拡張機能, F.2.5

詳細操作, F.6

事例, F

Directory Integration Platform, F.6.4

概要, F.2

スクリプト, F.8

WebDAV, F.6.3

VPP, F

W

ウォレット

作成, 5.5.2.1.2, 7.3.2.1.4

Oracle Wallet Manager, 5.5.2.1.2, 7.3.2.1.2, 7.3.2.1.4

保存, 7.3.2.1.4

Web Cache

「Oracle Web Cache」を参照, 8.2.2.4

Oracle Portalのための設定, 8.2.2.4

Webクリッピングの管理

構成, E.1

セキュリティの構成

信頼できるサイトの証明書の追加, 7.1.12.1

詳細セキュリティ・オプション(ASO), 7.1.12.2

Webクリッピング・リポジトリの構成, E.1.1 手動でのキャッシュ構成, E.1.4.1 手動でのプロキシの設定, E.1.3 承認されていない外部Webサイトからのクリッピングの制限, E.1.3.1 詳細セキュリティ・オプション(ASO)パラメータの設定, 7.1.12.2 Webクリッピングの「プロバイダ・テスト・ページ」の使用

詳細セキュリティ・オプション(ASO), 7.1.12.2

Webクリッピング・プロバイダ

登録, E.1.2

Webクリッピング・リポジトリ

構成, E.1.1

Webプロバイダ, 13.1.2 Webプロバイダ

タイムアウト・エラーの回避, G.1.10

権限, 7.1.3.4

Web Services for Remote Portlets, 3.1.3 WebDAV

Portalアクセスのパラメータ, 5.11.1

仮想プライベート・ポータル, F.6.3

web.xml

logmode, G.2.3.3

ワークフロー

BPELプロセス定義の作成, 5.5.3

BPELプロセス定義の削除, 5.5.5

BPELプロセス定義の編集, 5.5.4

WSRP, 1, 1.2.2.1, 1.2.2.1, 1.2.2.2, 1.4, 3.1.3, 7.1.9 WSRPプロデューサ

キーストア, 7.1.10.1

WWSSO_PAPP_CONFIGURATION_INFO$, A.5 wwv_context API

定数, D.3.1

例外, D.4

Oracle Text索引の管理, D

プロシージャ, D.1, D.2

X

x509certfile, 5.6.9.1

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。