1. Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの構成
  3. Oracle WebCenter Portalを含めるドメインの拡張

15 Oracle WebCenter Portalを含めるドメインの拡張

次の各トピックでは、Oracle WebCenter Portalソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

上位トピック: 「エンタープライズ・ドメインの構成」

Oracle WebCenter Contentでの動的クラスタのサポート

Oracle WebCenter Portalは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。

静的クラスタは、構成済クラスタとも言い、各サーバー・インスタンスを手動で構成して追加する従来型のクラスタです。動的クラスタには、新しい"server-template"オブジェクトが含まれています。このオブジェクトは、すべての生成された(動的)サーバー・インスタンスの一元的な構成を定義するために使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。この機能により、追加のサーバー容量が必要になったときに、動的クラスタ内のサーバー・インスタンスの数をスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。

この項に示すステップには、静的トポロジまたは動的トポロジの両方に対応するドメインの構成ステップが含まれています。この2種類の構成の相違点は次のとおりです。

  • 構成ウィザードのプロセスは、それぞれのケースに応じて異なることがあります。たとえば、サーバーではなく動的クラスタ用のサーバー・テンプレートの定義が必要になります。

  • 動的クラスタの場合は、サーバー固有の構成(リスニング・アドレスの設定、アップロードとステージングのディレクトリの構成、キーストアの構成など)をサーバーではなくサーバー・テンプレートで実行する必要があります。

  • 動的クラスタの場合は、サービス移行が異なる方法で構成されます。動的クラスタは移行可能ターゲットを使用しないかわりに、JMSリソースがクラスタをターゲットにします。動的クラスタのサービス移行を構成する際の具体的な手順は、このガイドに記載されています。

複合クラスタ(動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を含むクラスタ)は、Oracle WebCenter Portalエンタープライズ・デプロイメントではサポートされていません。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WebCenter Portalのためのドメイン拡張時に使用する変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

次のディレクトリ変数は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。

  • ORACLE_HOME

  • ASERVER_HOME

  • APPLICATION_HOME

  • DEPLOY_HOME

  • WEB_CONFIG_DIR

  • JAVA_HOME

さらに、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。

  • ADMINVHN

  • WCPHOST1

  • WCPHOST2

  • DBHOST1

  • DBHOST2

  • Oracle RACデータベースのSCANアドレス(DB-SCAN.examle.com)

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

エンタープライズ・デプロイメント用のソフトウェアのインストール

この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順について説明します。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WCCHOST1でのOracle WebCenter Portalインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

  1. WCCHOST1にログインします。
  2. インストール・プログラムがダウンロードされたディレクトリに移動します。
  3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。
    JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.3.0_wcportal.jar

    これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

    ソフトウェアをダウンロードして製品の実際のインストーラ・ファイル名を見つける方法の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

インストール画面への移動

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面 説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

「WebCenter Portal」を選択して「次へ」をクリックします。

注意:

  • WebCenter Portalワークリストの統合では、SOA Suiteによって提供されるBPELサービスが同じWeb層、SSOおよびアイデンティティ・ストアを共有する必要があります。

  • このエンタープライズ・デプロイメント・ガイドでは、SOA Suiteは同じWebLogic Serverドメインにインストールおよび構成され、Web層、SSOおよびディレクトリ構成に組み込まれます。

  • SOA Suiteのインストール先のORACLE_HOMEが同じであろうと別であろうと、WebCenter Portal SOAコンポジット・オプションが別のインストールとして必要です。そのインストールの詳細は、「Oracle WebCenter Portal SOAコンポジットのインストール」を参照してください。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、次のいずれかのドキュメントのOracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項を参照してください。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

WCCHOST2へのOracle WebCenter Portalのインストール

EDGの共有記憶域に関する推奨事項に従っている場合は、*HOST2ホストにマウントされている製品インストール用の個別の共有記憶域ボリュームが存在します。この2番目の製品ボリュームにもソフトウェアをインストールする必要があります。インストールの実行はWCCHOSTnホストと一貫した方法で行うことをお薦めします。「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

Oracle WebCenter Portalデータベース・スキーマの作成

Oracle WebCenter Portalドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

次の各トピックでは、必要なスキーマのインストール方法について説明します。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

  1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。
  2. 対象のシステムで、JAVA_HOME環境変数が、動作保証されたJDKの場所に設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

    UNIXオペレーティング・システムの場合:

    export JAVA_HOME=/u01/oracle/products/jdk
  3. RCUを起動します。

    UNIXオペレーティング・システムの場合:

    ./rcu

    注意:

    データベースで透過的データ暗号化(TDE)が有効化されている場合に、RCUによって作成される表領域を暗号化するには、RCUの起動時に-encryptTablespace trueオプションを指定します。

    これによって、RCUの実行中に追加の操作をすることなく、「表領域のマップ」画面で適切なRCU GUI「表領域の暗号化」チェック・ボックスが選択されるようにデフォルト指定されます。『リポジトリ作成ユーティリティによるスキーマの作成』の表領域の暗号化に関する項を参照してください。

親トピック: Oracle WebCenter Portalデータベース・スキーマの作成

スキーマ作成のためのRCU画面のナビゲート

スキーマ作成に必要なタスクは、次のとおりです。

タスク1   RCUの導入

「次」をクリックします。

タスク2   スキーマ作成の方法の選択

対象のデータベースに対するDBAアクティビティの実行に必要なパーミッションと権限が付与されている場合は、「システム・ロードおよび製品ロード」を選択します。この手順は、必要な権限が付与されていることを前提としています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。リポジトリ作成ユーティリティを使用したスキーマの作成のシステム・ロードおよび製品ロードの理解に関する項を参照してください。

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「DBMS/サービス」詳細を入力します。

「スキーマ所有者」および「スキーマ・パスワード」詳細を入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

タスク4   カスタム接頭辞の指定とスキーマの選択

「既存の接頭辞の選択」を選択し、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で初期ドメインを作成したときに使用した接頭辞を選択します。

スキーマのリストから「WebCenter Portal」を選択します。これにより、必要なWebCenter Portalスキーマが自動的に選択されます。また、次の依存スキーマがInfrastructureとともにすでにインストールされて灰色表示されています。

  • Metadata Services

  • 監査サービス

  • 監査サービス・アペンド

  • 監査サービス・ビューア

  • Oracle Platform Security Services

  • ユーザー・メッセージング・サービス

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

カスタム接頭辞の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境でスキーマを編成する方法の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のスキーマ作成の計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   カスタム変数の指定

エンタープライズ・デプロイメントの場合は、分析データをパーティション化できるように"Y"と入力することをお薦めします。

この機能は、月ごとに分析データをパーティション化します。パーティション化された環境でデータをパージするには、単に不要となった月ベースのパーティションを削除することをお薦めします。

分析データのパーティション化の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenter Portalの分析データのパーティション化に関する項を参照してください。

タスク7   必須スキーマの表領域の検証

「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。

確認ダイアログ・ボックスで「OK」をクリックします。

タスク8   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

タスク9   スキーマの作成の検証

スキーマが正常に作成されたことと、データベース接続詳細を確認するためには、SQL*Plusまたは別のユーティリティで、WCPINFRAスキーマ名および指定したパスワードを使用してデータベースに接続します。

次に例を示します。

sqlplus  

SQL*Plus: Release 12.1.0.1.0 Production on Wed Aug 31 05:41:31 2016  

Copyright (c) 1982, 2013, Oracle. All rights reserved.  

Enter user-name: FMW1221_WEBCENTER 
Enter password: schema_password

Connected to: 
Oracle Database 11g Enterprise Edition Release 12.1.0.1.0 - 64bit Production 
With the Partitioning, OLAP, Data Mining and Real Application Testing options  

SQL>

親トピック: Oracle WebCenter Portalデータベース・スキーマの作成

Oracle WebCenter Portalを含めるエンタープライズ・デプロイメント・ドメインの拡張

この項では、Oracle WebCenter Portalソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順を説明します。

ドメインの拡張には、次の操作が含まれます。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

構成ウィザードの起動

既存のエンタープライズ・デプロイメント・ドメインを拡張するための最初のステップとして構成ウィザードを起動します。

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverridesLate.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJavaコマンド行オプションの指定、追加の環境変数の指定などを実施するように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

このエンタープライズ・デプロイメント・ガイドでのsetUserOverridesLateスクリプトの使用の詳細は、「setUserOverridesLateスクリプトを使用したサーバー・パラメータのカスタマイズ」を参照してください。

構成ウィザードを起動する手順は次のとおりです。

  1. WebLogic Serverコンソールで、このドメイン拡張によって変更するすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーはオンラインのままです。
  2. 変更するすべての管理対象サーバーについて、管理対象サーバーのシャットダウンが完了していることを確認します。
  3. すべての管理対象サーバーが安定した状態になったら、管理サーバーを停止します。
  4. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。
    cd ORACLE_HOME/oracle_common/common/bin
./config.sh

親トピック: Oracle WebCenter Portalを含めるエンタープライズ・デプロイメント・ドメインの拡張

WebCenter Portalを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

次の各項に示す手順に従って、静的または動的クラスタを含むトポロジのドメインを作成および構成します。

親トピック: Oracle WebCenter Portalを含めるエンタープライズ・デプロイメント・ドメインの拡張

静的クラスタを含めるドメインの拡張

この項に示す手順に従って、静的クラスタを含めてトポロジのドメインを作成および構成します。

注意:

この項で説明する手順と同じ手順を使用して、静的クラスタを含めて既存のドメインを拡張できます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

  • Oracle WebCenter Portal – 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Pagelet Producer – 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Portlet Producers - 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Analytics Collector - 12.2.1.3.0 [wcportal]

また、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されています。

  • Oracle Enterprise Manager - 12.2.1.3.0[em]

  • Oracle WSM Policy Manager - 12.2.1.3.0[oracle_common]

  • Oracle JRF - 12.2.1.3.0[oracle_common]

  • WebLogic Coherenceクラスタの拡張 - 12.2.1.3.0 [wlserver]

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

Task 3   カスタム・データ・ソース用のGridLink Oracle RACデータベース接続の詳細情報の指定

構成ウィザード以外でドメインにデータ・ソースが追加されている場合、構成ウィザードでは追加のタスクが必要です。このタスクと次のタスクは、「Oracle SOA Suiteを含めるドメインの拡張」の最後で「リース用のGridLinkデータ・ソースの作成」と「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」が完了している場合に表示されます。

次のデータ・ソース用のGridLinkデータ・ソース構成の詳細情報を確認します。

  • リース

  • TLOG

  • JMS

注意:

これらのデータ・ソースの名前は、実行時にカスタマイズされていて、この例と一致しないことがあります。

これらのデータ・ソースの値が完全には表示されない場合、タスク6「JDBCコンポーネント・スキーマ情報の指定」で詳細を確認してください。

Task 4   カスタム・データ・ソース用のJDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のテスト・コンポーネント・スキーマに関する項を参照してください

タスク5   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示しています。 

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解 に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のデータソースのデフォルトを参照してください。

タスク6   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表にあるWebCenter Portalスキーマをすべて選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク7   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

表15-1 RACデータベースおよびコンポーネント・スキーマに接続するための情報

要素 説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

「FANの有効化」チェック・ボックスを選択して、FANイベントを受信および処理できるようにします。

タスク8   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のテスト・コンポーネント・スキーマに関する項を参照してください

タスク9   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

  • トポロジ

  • デプロイメントとサービス

タスク10   管理対象サーバーの構成

「管理対象サーバー」画面で、Oracle WebCenter Portal、Oracle WebCenter PortletおよびOracle WebCenter Collaboration用の新しい管理対象サーバーが以前に作成された他の管理対象サーバーとともにサーバーのリストに表示されます。これらのサーバーは、構成ウィザード・セッションで前に選択したOracle WebCenter Portal構成テンプレートによって自動的に作成されます。

次のタスクを実行して、デフォルトの管理対象サーバーを変更し、サーバー・タイプごとに2つ目の管理対象サーバーを作成します。

  1. WC_Portalを選択して、名前をWC_Portal1に変更します。

  2. 「クローン」を選択して別の管理対象サーバーを作成します。新しいサーバーの名前をWC_Portal2に変更します。

  3. 前述の2つのステップを繰り返して、WC_Portlet1およびWC_Portlet2を編集および作成します。

ヒント:

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

表15-2 新しい管理対象サーバーのプロパティ

サーバー名 リスニング・アドレス リスニング・ポート SSLの有効化 SSLリスニング・ポート サーバー・グループ

WC_Portal1

WCPHOST1

9001

いいえ

無効

WebCenter Portal管理対象サーバー

WebCenter Portal分析管理対象サーバー

WC_Portal2

WCPHOST2

9001

いいえ

無効

WebCenter Portal管理対象サーバー

WebCenter Portal分析管理対象サーバー

WC_Portlet1

WCPHOST1

9002

いいえ

無効

WebCenter Portalページレット・プロデューサ管理対象サーバー

WebCenter Portalポートレット・プロデューサ管理対象サーバー

WC_Portlet2

WCPHOST2

9002

いいえ

無効

WebCenter Portalページレット・プロデューサ管理対象サーバー

WebCenter Portalポートレット・プロデューサ管理対象サーバー
タスク11   クラスタへのサーバーの割当て

すべての静的に構成された管理対象サーバーが正しいクラスタに割り当てられていることを確認します。

注意:

動的クラスタを使用してWebCenter Portalを構成する場合、ここで割り当てる追加のサーバーはありません。

「次へ」をクリックして次の画面に進みます。

タスク12   クラスタの構成

「クラスタの構成」画面で、次の新しいクラスタを追加します。

  • Portal_Cluster

  • Portlet_Cluster

3つのクラスタ全部について、「クラスタ・アドレス」、「フロントエンド・ホスト」および「ポート」をデフォルト値のままにします。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク13   サーバー・テンプレートの割当て

「次へ」をクリックして次の画面に進みます。

タスク14   動的サーバーの構成
静的クラスタとして残そうとするクラスタに対して、動的サーバーのすべてのオプションが無効になっていることを確認します。

  1. この画面の「動的クラスタ」、「計算済リスニング・ポート」および「計算済マシン名」チェック・ボックスの選択が解除されていることを確認します。

  2. 「サーバー・テンプレート」で「未指定」が選択されていることを確認します。

  3. 「次」をクリックします。

タスク15   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、管理対象サーバーをそれぞれのクラスタに割り当てます。

  1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではPortal_Cluster)を選択します。

  2. 「サーバー」ペインで、次のいずれかを実行して、WC_Portal1をPortal_Clusterに割り当てます。

    • WC_Portal1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

    • WC_Portal1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

  3. 同じ手順を繰り返して、WC_Portal2をPortal_Clusterに割り当てます。

  4. ステップ1-3を繰り返して、WC_Portlet1およびWC_Portlet2をPortlet_Clusterに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク16   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。

タスク17 既存のマシンの検証

「Unixマシン」タブで、初期インフラストラクチャ・ドメインの作成時に作成したマシンの名前を確認します。

「次へ」をクリックします。

タスク18   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、作成したばかりの管理対象サーバーをドメイン内の対応するマシンに割り当てます。

WC_Portal1、WC_Portlet1をWCPHOST1に割り当てます。

WC_Portal2、WC_Portlet2をWCPHOST2に割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク19   仮想ターゲットの構成

「次へ」をクリックして次の画面に進みます。

タスク20   パーティションの構成

「次へ」をクリックして次の画面に進みます。

タスク21   デプロイメント・ターゲット指定

Oracle Web Services Manager Policy Managerが別のクラスタにデプロイされている場合は、PortalおよびPortletのクラスタに対するWSM-PMアプリケーションのデフォルトのターゲット指定を削除する必要があります。

「ターゲット」パネルで、Portal_ClusterおよびPortlet_Clusterのそれぞれについて、次のようにします。

「アプリケーション」フォルダ内のwsm-pmアプリケーション・エントリを選択し、左矢印ボタンをクリックしてターゲット・リストから削除します。

タスク22   サービス・ターゲット指定

Oracle Web Services Manager Policy Managerが別のクラスタにデプロイされている場合は、WSM-PMアプリケーションに必要なサービス・リソースのデフォルトのターゲット指定を、PortalおよびPortletのクラスタから削除できます。

「ターゲット」パネルで、Portal_ClusterおよびPortlet_Clusterのそれぞれについて、次のようにします。

次のリソースをターゲット・リストから選択して削除します。

  • mds-owsm

タスク23   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク24   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク25   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

静的クラスタを含めるドメインの拡張を完了したら、「ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播」に進みます。

動的クラスタを含めるドメインの拡張

この項に示す手順に従って、動的クラスタを含めてトポロジのドメインを拡張します。

注意:

この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件があわないときは、適切な内容を選択していることを確認するか、その他の詳細について説明されているドキュメントを参照してください。

ドメインを拡張して構成するためのタスクは次のとおりです。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、初期ドメインの一部として作成した管理ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

  • Oracle WebCenter Portal – 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Pagelet Producer – 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Portlet Producers - 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Analytics Collector - 12.2.1.3.0 [wcportal]

また、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されています。

  • Oracle Enterprise Manager - 12.2.1.3.0[em]

  • Oracle WSM Policy Manager - 12.2.1.3.0[oracle_common]

  • Oracle JRF - 12.2.1.3.0[oracle_common]

  • WebLogic Coherenceクラスタの拡張 - 12.2.1.3.0 [wlserver]

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

Task 3   カスタム・データ・ソース用のGridLink Oracle RACデータベース接続の詳細情報の指定

構成ウィザード以外でドメインにデータ・ソースが追加されている場合は、構成ウィザードで追加のタスクが表示されることがあります。このタスクと次のタスクは、「Oracle SOA Suiteを含めるドメインの拡張」の最後で「リース用のGridLinkデータ・ソースの作成」と「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」が完了している場合に表示されます。リース用のWLSSchemaDatasourceおよびJMS/TLOG永続ストアを再利用するオプションを選択している場合、このステップと次のステップは表示されません。

次のデータ・ソース用のGridLinkデータ・ソース構成の詳細情報を確認します。

  • リース

  • TLOG

  • JMS

注意:

これらのデータ・ソースの名前は、実行時にカスタマイズされていて、この例と一致しないことがあります。

これらのデータ・ソースの値が完全には表示されない場合、タスク6「JDBCコンポーネント・スキーマ情報の指定」で詳細を確認してください。

Task 4   カスタム・データ・ソース用のJDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のテスト・コンポーネント・スキーマに関する項を参照してください

タスク5   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。操作に成功すると、「接続結果ログ」に次の出力が示されます。 

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のデータソースのデフォルトを参照してください。

タスク6   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表のすべての新しいスキーマ(WebCenter Portal コンポーネント用)を選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク7   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素 説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

これらの値は、Oracle 11gデータベースに接続する際には必須で、Oracleデータベース・リリース12c以上に接続する場合はオプションです。Oracle 12cデータベースを使用している場合、ONSリストはデータベースからドライバに自動的に提供されます。

FANの有効化

「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

タスク8   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のテスト・コンポーネント・スキーマに関する項を参照してください

タスク9   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

  • トポロジ

  • デプロイメントとサービス

注意:

JMS JDBCストアの使用をお薦めします。WebCenter Content拡張のタスク3「高可用性オプションの構成」の項でもその選択が推奨されているため、ファイル・ストアを構成する必要はありません。

WebCenter Contentによる初期ドメインの拡張時にタスク3「高可用性オプションの構成」で「JMSファイル・ストア」オプションを選択している場合は、ここで「ファイル・ストア」オプションを選択して、共有の場所ORACLE_RUNTIME/domain_name/cluster_name/jmsでファイル・ストアが確実に構成されるようにする必要があります。フェイルオーバーが発生した場合に、ファイル・ストアを使用してJMSおよびHAを再開する場合は、共有の場所が必要です。JDBCストアを使用する場合は、ここで「ファイル・ストア」拡張構成オプションを選択しないでください。

タスク10   管理対象サーバーの構成

「管理対象サーバー」画面で、Oracle WebCenter PortalおよびPortletの複数の新しい管理対象サーバーが、既存のWebCenter Content IBRサーバー(インストールされている場合)と一緒に、構成済の静的管理対象サーバーのリストに表示されます。

動的クラスタ構成に静的管理対象サーバー定義は必要ありません。

次のステップを実行して、デフォルトのWC_PortletおよびWC_Portal管理対象サーバーを削除します。

  1. 削除する管理対象サーバー定義の「サーバー名」フィールドをクリックします。

  2. 「削除」をクリックします。

  3. 削除する管理対象サーバーごとに操作を繰り返します。

  4. 「次へ」をクリックして次の画面に進みます。

タスク11   クラスタの構成

このタスクでは、Oracle WebCenter Portalソフトウェアのターゲットにすることができる複数のクラスタを作成します。

「クラスタの構成」画面で、対応する動的サーバー・グループを指定して、次の新しいクラスタを追加します。
クラスタ名 動的サーバー・グループの選択

Portal_Cluster

PORTAL-ANALYTICS-DYN-CLUSTER

Portlet_Cluster

PORTLET-PAGELET-DYN-CLUSTER

  1. 「追加」をクリックします。

  2. 「クラスタ名」フィールドに適切な値を指定します。

  3. 「クラスタ・アドレス」フィールドおよび「フロントエンド・ホスト」フィールドは空白のままにします。

  4. 前述の表に従って、「動的サーバー・グループ」ドロップダウン・リストから適切な値を選択します。

    注意:

    デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

    ヒント:

    この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。

  5. 「次へ」をクリックして次の画面に進みます。

タスク12   サーバー・テンプレートの割当て

「サーバー・テンプレート」画面を使用して、指示に従って新しいサーバー・テンプレートを構成して割り当てます。

注意:

スケールアップおよびスケールアウトが可能な製品コンポーネントの動的クラスタでは、必要な最大許容数の動的管理対象サーバーに割り当てるリスニング・ポートを動的クラスタが自動計算できるように、十分なポート範囲を重複なしで予約できるようにすることが重要です。動的クラスタの計算済リスニング・ポート機能では、動的管理対象サーバー1台に対してポート番号が1ずつ増分されます。成長に対応するための余裕を見越した上で、スケーラビリティの要件に応じて、各種サービス間でリスニング・ポートの範囲を調整してください。最初の管理対象サーバーには、ここで指定されたリスニング・ポート値に1を足したポート番号が割り当てられます。
「クラスタの構成」画面で、対応する動的サーバー・グループを指定して、次の新しいクラスタを追加します。
名前 リスニング・ポート SSLリスニング・ポート SSLの有効化

portal-server-template

9010

9110

選択解除

portlet-server-template

9020

9120

選択解除

  1. 推奨事項に従ってリスニング・ポート値を更新します。

  2. 「SSLの有効化」オプションは未選択のままにしておきます。

  3. 構成値が重複しないよう「SSLリスニング・ポート」を適切な値に更新します。

  4. すべての値を正しく指定したら、「次へ」をクリックして次の画面に進みます。

タスク13   動的サーバーの構成

「動的サーバー」画面を使用して、管理対象サーバーの作成およびスケーリングの方法を制御するプロパティを構成します。『Oracle WebLogic Serverクラスタの管理』の「動的クラスタ」を参照してください。

次の手順に従って、新しいWebCenter PortalおよびPortletクラスタの設定を構成します。

  1. クラスタ名の値が前の手順で構成したものと一致していることを確認します。

  2. サーバー名の接頭辞の値が次のようになっていることを確認します。

    • Portal_Cluster: WC_Portal

    • Portlet_Cluster: WC_Portlet

  3. 正しいサーバー・テンプレートが「サーバー・テンプレート」ドロップダウン・リストから選択されていることを確認します。

    • Portal_Cluster: portal-server-template

    • Portlet_Cluster: portlet-server-template

  4. 新しいクラスタの動的クラスタ・サイズを指定します。

    単純な水平方向のスケールアウト用に冗長性を確保するために、ドメインで構成されているWCPHOSTnマシンの数以上のサイズを設定してください。ベースラインEDGトポロジの場合、この値は2になります。

    注意:

    クラスタ・サイズは、前の手順で指定した使用可能なリスニング・ポート範囲、使用可能なWCPHOSTnマシンの数、およびハードウェア・リソースの制限を考慮した上で、スケーラビリティのニーズに合わせて必要に応じて調整できます。

    この設定によって、クラスタの現在のサイズに影響がおよびますが、「最大動的サーバー数」を構成することはできません。

    動的クラスタ・サイズが「マシン名マッチング式」に一致する利用可能なマシンの数より大きく設定されている場合、それらのマシン上に複数の管理対象サーバーが垂直スケールアップ・トポロジで作成されます。

    スケーラビリティのチェック: 各クラスタに対して「計算済リスニング・ポート」オプションが選択されている場合は、ドメインの拡張後に、最大動的サーバー数が、前のタスクで指定した使用可能なリスニング・ポートの数を超えていないことを確認してください。最大動的サーバー数が、クラスタのポート範囲の間にある使用可能なポートの数を超えている場合は、クラスタのスケーリング時に問題が発生することがあります。

  5. 新しいクラスタの「マシン名マッチング式」フィールドに「WCPHOST*」と指定します。

    注意:

    WebLogicマシン名の構成をカスタマイズしている場合は、マッチング式で使用できる一意かつ一貫性のある接頭辞が名前に含まれていることを確認してください。

  6. 「計算済マシン名」、「計算済リスニング・ポート」および「動的クラスタ」の各フィールドを、次のように選択します。

    • Portal_Cluster: 3フィールドをすべて選択

    • Portlet_Cluster: 3フィールドをすべて選択

  7. 既存のクラスタのすべての設定を確認し、構成ウィザードによって予期せずに変更された可能性のある上記以外の構成選択がある場合は、これを修正します。

    例: IBR_Serversなどの静的クラスタについて、「計算済リスニング・ポート」および「動的クラスタ」のチェック・ボックスが選択されていないことを確認します。

  8. 「次へ」をクリックして次の画面に進みます。

タスク14   クラスタへのサーバーの割当て

すべての構成済静的管理対象サーバーが正しいクラスタに割り当てられていることを確認します。

注意:

この画面は、ドメインで静的クラスタまたは静的管理対象サーバーが定義されている場合にのみ表示されます。

動的クラスタを使用してWebCenter Portalを構成する場合は、ここで割り当てる構成によって管理対象サーバーが作成されることはありません。既存の管理対象サーバーだけが表示され、変更は必要ありません。

「次へ」をクリックして次の画面に進みます。

タスク15   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。初期ドメイン作成に基づいて想定どおりにポート番号が設定されていることを確認してから、「次へ」をクリックします。

注意:

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報のOracle Coherenceに関する項を参照してください。

タスク16 既存のマシンの検証

ステップは次のとおりです。

  1. 「Unixマシン」タブで、初期インフラストラクチャ・ドメインの作成時に作成したマシンの名前を確認します。

    表15-3 Unixマシンの作成時に使用する値

    名前 ノード・マネージャのリスニング・アドレス ノード・マネージャのリスニング・ポート

    ADMINHOST

    ADMINVHN変数の値を入力します。

    5556

    WCCHOST1

    WCCHOST1ホスト名変数の値。たとえば、WCCHOST1.example.comなどです。

    5556

    WCCHOST2

    WCCHOST2ホスト名変数の値。たとえば、WCCHOST2.example.comなどです。

    5556

    WCPHOST1

    WCPHOST1ホスト名変数の値。たとえば、WCPHOST1.example.comとなります。

    5556

    WCPHOST2

    WCPHOST2ホスト名変数の値。たとえば、WCPHOST2.example.comとなります。

    5556

  2. 「次へ」をクリックします。

タスク17   マシンへのサーバーの割当て

「次へ」をクリックして次の画面に進みます。

タスク18   仮想ターゲットの構成

「次へ」をクリックして次の画面に進みます。

タスク19   パーティションの構成

「次へ」をクリックして次の画面に進みます。

タスク20   デプロイメント・ターゲット指定

Oracle Web Services Manager Policy Managerが別のクラスタにデプロイされている場合は、PortalおよびPortletのクラスタに対するWSM-PMアプリケーションのデフォルトのターゲット指定を削除する必要があります。

  1. 「デプロイメント・ターゲット」パネルで、Portal_Clusterのwsm-pmアプリケーション・デプロイメントが見つかるまでスクロールします。

  2. Portal_Clusterのwsm-pmアプリケーション・デプロイメントをクリックします。

  3. 「デプロイメント・ターゲット」リストで左矢印ボタンをクリックして、Portal_Clusterからwsm-pmアプリケーション・デプロイメントを削除します。

  4. Portlet_Clusterのwsm-pmアプリケーション・デプロイメントに対してこの手順を繰り返します。

タスク21   サービス・ターゲット指定

Oracle Web Services Manager Policy Managerが別のクラスタにデプロイされている場合は、WSM-PMアプリケーションに必要なサービス・リソースのデフォルトのターゲット指定を、PortalおよびPortletのクラスタから削除できます。

  1. 「デプロイメント・ターゲット」パネルで、Portal_Clusterのmds-owsm JDBCSystemResourceが見つかるまでスクロールします。

  2. Portal_Clusterのmds-owsmリソースをクリックします。

  3. 左矢印ボタンをクリックして、Portal_Clusterからmds-owsmリソース・デプロイメントを削除します。

  4. Portlet_Clusterのmds-owsm JDBCSystemResourceデプロイメントに対してこの手順を繰り返します。

タスク22   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク23   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク24   管理サーバーの起動

管理サーバーを起動してログインし、クラスタ・ビューとサーバー・ビューを確認して、ドメインに対する変更が適用されていることを確認します。

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle WebCenter Portalインスタンスを含めることでドメインを拡張し、WCCHOST1上の管理サーバーを起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。
  1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのバックアップ・コピーを作成します。
  2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。
    cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true 
          -domain=ASERVER_HOME 
          -template=/full_path/wcpdomaintemplateExtWCP.jar 
          -template_name=wcpdomain_templateExtWCP

    この例では、次のようになります。

    • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

    • full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。

      テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。 

      SHARED_CONFIG_DIR/domains/template_filename.jar

    • wcpdomaintemplateExtWCP.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

    • wcpdomain_templateExtWCPは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

  3. 次のunpackコマンドをWCCHOST1で実行して、前のステップで作成したテンプレートをMSERVER_HOMEディレクトリに伝播します。
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME 
            -template=/full_path/wcpdomaintemplateExtWCP.jar 
            -app_dir=APPLICATION_HOME 
            -overwrite_domain=true

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • wcpdomaintemplateExtWCP.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

    • 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。

      上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

    • APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

    ヒント:

    packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

  4. パック済のJARファイルへのフルパスが他のサーバーで使用可能な共有ボリューム上にある場合は、このステップをスキップし、それ以外の場合は、次のコマンドをWCCHOST1で実行し、ステップ1で作成したテンプレート・パックをWCCHOST2、WCPHOST1およびWCPHOST2にコピーします。
    scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCCHOST2:/full_path/
scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCPHOST1:/full_path/
scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCPHOST2:/full_path/
  5. 次のunpackコマンドをWCCHOST2、WCPHOST1およびWCPHOST2で実行して、前のステップでコピーしたドメイン・テンプレートをローカルMSERVER_HOMEドメイン・ディレクトリにデプロイします。
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME 
            -template=/full_path/wcpdomaintemplateExtWCP.jar 
            -app_dir=APPLICATION_HOME 
            -overwrite_domain=true

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • wcpdomaintemplateExtWCP.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

    • 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。

      上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

    • APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

    ヒント:

    packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

ドメイン解凍後のsetDomainEnv.shへのカスタマイズのリストア

すでにASERVER_HOMEおよびMSERVER_HOME内のsetDomainEnv.shファイルにカスタマイズを加えていた場合、このようなカスタマイズはドメイン拡張後に再度行う必要があります。

注意:

setDomainEnvスクリプトを変更することはお薦めできません。詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

WebCenterエンタープライズ・デプロイメントについては、「setUserOverridesLateスクリプトを使用したサーバー・パラメータのカスタマイズ」を参照してください。

NodeManagerまたはWebLogic Serverインスタンスの起動前に、カスタマイズがすべてリストアされていることを確認します。

WCCHOST1で次の手順を実行します。

  1. ASERVER_HOME/bin/setDomainEnv.shを確認して更新します。
  2. MSERVER_HOME/bin/setDomainEnv.shを確認して更新します。
  3. MSERVER_HOME/bin/setDomainEnv.shを他のホスト(WCCHOST2、WCPHOST1、WCPHOST2など)にコピーします。

    注意:

    ASERVER_HOMEおよびMSERVER_HOMEのsetDomainEnv.sh構成ファイルに格納されているパラメータ値には、固有差があります。同じファイルを両方の場所にコピーすることはできないため、別々に編集する必要があります。MSERVER_HOME/bin/setDomainEnv.shは、環境全体で変らずコピーできます。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

ドメイン解凍後のNodeManager構成の更新

ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

注意:

各ホストのMSERVER_HOME/nodemanager/nodemanager.propertiesファイルについて、次のことを実行します。
  1. 正しいListenAddressパラメータ値を確認して、必要な場合は値を再設定します。
    grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties
  2. 次のコマンドの参照として、ドメイン構成ファイルから構成済アイデンティティ別名のリストを確認します。
    grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq

    注意:

    動的クラスタの使用時には、このリストにADMINVHNとワイルドカードの証明書アイデンティティ別名のみが表示されます。

    次の手順でnodemanger.properties CustomIdentityAliasプロパティを更新するときには、適切なホスト固有の証明書アイデンティティ別名を使用してください。

  3. 現在のnodemanager.properties CustomIdentityAliasパラメータの値がホストの別名と一致していることを確認します。
    grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties
  4. 必要に応じて、CustomIdentityAliasパラメータ値を、現在のホストに適した正しい別名文字列に再設定します。
  5. nodemanagerプロセスを再起動します。
    kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

注意:

CustomIdentityAliasパラメータの詳細は、「カスタム・キーストアを使用するためのノード・マネージャの構成」を参照してください。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

既存の管理対象サーバーの再起動と検証

ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたので、既存のコンポーネントの管理対象サーバーを再起動します。
  1. WebLogic Serverコンソールから、WebServices Manager Policy ManagerのWLS_WSMn管理対象サーバーを再起動します。
  2. 別のブラウザ・ウィンドウから、URLを正常にロードすることで、WSM-PMアプリケーションが応答していることを確認します。
    http://wcpinternal.example.com/wsm-pm/validator
  3. 続行する前に、その他すべての既存の管理対象サーバーを再起動します。これは、アプリケーションの停止を回避するために必要に応じてローリング方式で実行できます。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。

このステップは、リモート・デプロイメントの実行時の潜在的な問題の回避と、ステージ・モードが必要なデプロイメントのために必要です。

デプロイメント・ステージおよびアップロードの場所のディレクトリ・パスを更新するには、次のステップを実行します。

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

  3. 「ロックして編集」をクリックします。

  4. 使用するクラスタ・タイプに適したオブジェクトに移動して編集します。

    1. 静的クラスタの場合は「サーバー」にナビゲートし、編集する管理対象サーバーの名前をクリックします。

    2. 動的クラスタの場合、「クラスタ」→「サーバー・テンプレート」に移動し、編集するサーバー・テンプレートの名前をクリックします。

  5. 編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。

    1. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

    2. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。 

      MSERVER_HOME/servers/server_or_template_name/stage

      MSERVER_HOMEを MSERVER_HOMEディレクトリのフルパスに置き換えます。

      静的クラスタを使用する場合、編集対象の管理対象サーバーの正しい名前を使用して更新します。

      動的クラスタを使用する場合、テンプレート名はそのままにしておきます。例: /u02/oracle/config/domains/wcpedg_domain/servers/XYZ-server-template/stage

    3. 「アップロード・ディレクトリ名」を次の値に更新します。 

      ASERVER_HOME/servers/AdminServer/upload

      ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

    4. 「保存」をクリックします。

    5. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。

  6. 新しい管理対象サーバーまたは動的クラスタ・サーバー・テンプレートごとに前のステップを繰り返します。

  7. AdminServerの「アップロード・ディレクトリ名」に移動して、その値を更新します。

    1. 「サーバー」に移動してAdminServerを選択します。

    2. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

    3. 「ステージング・ディレクトリ名」が次のような絶対パスに設定されていることを確認します。

      ASERVER_HOME/servers/AdminServer/stage

    4. 「アップロード・ディレクトリ名」を次の絶対パスに更新します。

      ASERVER_HOME/servers/AdminServer/upload

      ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

    5. 「保存」をクリックします。

  8. 該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。

注意:

これ以上のドメイン構成を直接続行する場合、この時点ではstageおよびuploadディレクトリの変更を有効にするための再起動は厳密には必要ありません。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

動的クラスタを使用する際のリスニング・アドレスの構成

動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、デフォルトの構成は望ましくありません。動的クラスタを使用する際に、リスニング・アドレスを特定のアドレスに限定するには、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。リスニング・アドレスを変更した後に前の項で指定したテストURLを再確認し、クラスタ化された管理対象サーバーを再起動します。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WCPHOST1でのノード・マネージャの起動

WCPHOST1で拡張済のドメインを解凍したら、WCPHOST1の管理対象サーバー・ディレクトリからノード・マネージャを起動できます。

  1. WCPHOST1上の次のディレクトリに移動します。
    MSERVER_HOME/bin
  2. 次のコマンドを使用してノード・マネージャを起動します。
    nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WCPHOST2でのノード・マネージャの起動

ドメイン構成をWCPHOST2に伝播したら、MSERVER_HOMEドメイン・ディレクトリのノード・マネージャを起動できます。

  1. WCPHOST2にまだログインしていない場合は、ログインします。
  2. ディレクトリを次の場所に変更します。

    MSERVER_HOME/bin

  3. 次のコマンドを使用してWCPHOST2でノード・マネージャを起動します。
    nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

    ノード・マネージャの追加の構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WC_Portal1およびWC_Portlet1管理対象サーバーの起動と検証

これでドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle WebCenter Portalサーバーを起動できます。

このプロセスは、次の3つのタスクで構成されます。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WCPHOST1での管理対象サーバーの起動

WC_Portal1管理対象サーバーを起動する手順は次のとおりです。

  1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
    http://ADMINVHN:7001/em
  2. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。例: weblogic_wcp
  3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
  4. WC_Portal1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

    注意:

    WebCenter Portalサーバーは、ポリシー・アクセス・サービスに依存して機能します。これは、WebCenter Portalサーバーの起動前にドメイン内のWSM-PM管理対象サーバーが起動し、稼働していて、アクセスできる必要があることを意味します。

  5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WC_Portal1管理対象サーバーが起動し、稼働していることを確認します。
  6. 前述のステップを繰り返して、WCPHOST1でWC_Portlet1管理対象サーバーを起動します。

親トピック: WC_Portal1およびWC_Portlet1管理対象サーバーの起動と検証

ポータル管理者グループへのWCPAdminロールの追加

WC_Portal1管理対象サーバーでOracle WebCenter Portalの構成を検証する前に、WebCenter Portal管理者ロールをWCPAdministrators LDAPグループに付与します。

このタスクを実行するには、「Oracle WebCenter Portal製品の管理用のロールの構成」を参照してください。

親トピック: WC_Portal1およびWC_Portlet1管理対象サーバーの起動と検証

WLSTを使用したWebCenter Portal管理者ロールの付与

この項では、WLSTを使用してWebCenter Portalの管理者ロールを付与する方法について説明します。

WLSTを使用してWebCenter Portal管理者ロールを付与する手順は次のとおりです。
  1. LDAPストアでWCPAdministratorsという名前のグループを作成します。

    このグループは、WebCenter Portalで管理者ロールに割り当てられます。

    ユーザーの作成方法の詳細は、「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」および「新しい管理グループへの管理ロールの追加」を参照してください。

  2. 次のように、WebCenter Portal Oracleホーム・ディレクトリに移動してWLSTスクリプトを起動します。
    (UNIX) ORACLE_HOME/wcportal/common/bin/wlst.sh

(Windows) ORACLE_HOME\wcportal\common\bin\wlst.cmd
  3. 次のコマンドを使用して、ターゲット・ドメインの管理サーバーに接続します。
    wls:/offline>connect("user_name","password", "host_name:port_number")
  4. grantAppRoleコマンドを使用し、LDAPのWCPAdministratorsグループにWebCenter Portal管理者アプリケーション・ロールを付与します。
    grantAppRole(appStripe="webcenter", appRoleName="s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator", principalClass="weblogic.security.principal.WLSGroupImpl", principalName="WCPAdministrators")

    WCPAdministratorsは、前に作成したポータル管理グループの名前です。

  5. WC_Portal1管理対象サーバーを再起動します。
    shutdown('WC_Portal1', block='true', force='true')
start('WC_Portal1', block='true')
  6. 新しいアカウントをテストするには、新しいアカウント名を使用してWebCenter Portalにログインします。

    ブラウザでhttp://WCPHOST1:9001/webcenterを使用して、WebCenter Portalを開きます。ログイン後、「管理」リンクが表示されて、すべての管理操作を実行できるようになります。

Fusion Middleware Controlを使用したWebCenter Portal管理者ロールの付与

この項では、デフォルトのweblogicアカウント以外のユーザー・アカウントにWebCenter PortalのAdministratorロールを付与する方法を説明します。

Fusion Middleware Controlを使用してWebCenter Portalの管理者ロールを付与する手順は、次のとおりです。
  1. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。例: weblogic_wcp
  2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
  3. WebCenter Portalの管理者ロールを検索します。

    1. webcenterアプリケーション・ストライプを選択します。

    2. 検索フォームの「ロール名」オプションを「次で始まる」から「が次を含む」に変更します。

    3. 「が次を含む」オプションの横のテキスト・ボックスに、#Administratorと入力して「アプリケーション・ロールの検索」アイコンをクリックします。検索アイコン.

  4. 戻された行をクリックして管理者ロールを選択します。
  5. 「編集」アイコンアプリケーション・ロールの「編集」アイコンをクリックして「アプリケーション・ロールの編集」ビューを開きます。
  6. 「追加」アイコンをクリックします アプリケーション・ロールの「追加」アイコン
    メンバーを追加するためのフォームが表示されます。
  7. 検索タイプを「アプリケーション・ロール」から「グループ」に変更します。
  8. 「検索」機能を使用して、「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」で作成したWCPAdministrators LDAPグループを検索します。
  9. WCPAdministratorsグループの検索結果の適切な行をクリックして選択します。
  10. 「OK」をクリックして、選択したグループをロールに追加します。
  11. 「アプリケーション・ロールの編集」ページで、更新されたメンバー・リストに新しく追加したグループが含まれていることを確認します。
  12. 「OK」クリックしてアプリケーション・ロールに対する変更を保存します。
  13. WC_Portal1管理対象サーバーを再起動します。
    WCPAdministratorsグループのメンバーとしてWebCenter Portalにログインすると、「管理」リンクが表示されて、すべての管理操作を実行できます。

WCPHOST1でのWebCenter Portalの検証

WCPHOST1でPortalおよびPortletの管理対象サーバーを起動したら、次のアプリケーションURLを使用してWebアプリケーションが応答することを検証します。

注意:

  • 必要に応じて、weblogic_wcpとして認証します。

  • 「計算済リスニング・ポート」機能が有効化された動的クラスタリングを使用している場合は、ポート番号を適切な値に更新します。ポート割当ての例は、「クラスタ・タイプ別WebCenter Portalリスニング・ポートの概要」の表を参照してください。

表15-4 クラスタ・タイプ別WebCenter Portalリスニング・ポートの概要

管理対象サーバー リスニング・ポート(静的クラスタ) リスニング・ポート(動的クラスタ)
WC_Portal1 9001 9011
WC_Portal2 9001 9012
WC_Portlet1 9002 9021
WC_Portlet2 9002 9022

親トピック: WC_Portal1およびWC_Portlet1管理対象サーバーの起動と検証

WCPHOST2での管理対象サーバーの起動と検証

WCPHOST1で管理対象サーバーが正常に構成され、起動していることを確認したら、「WC_Portal1およびWC_Portlet1管理対象サーバーの起動と検証」の手順を使用して、WCPHOST2で新しい管理対象サーバーを起動して検証できます。

注意:

  • 必要に応じて、weblogic_wcpとして認証します。

  • 「計算済リスニング・ポート」機能が有効化された動的クラスタリングを使用している場合は、ポート番号を適切な値に更新します。ポート割当ての例は、「クラスタ・タイプ別WebCenter Portalリスニング・ポートの概要」の表を参照してください。

WCPHOST2でPortalおよびPortletの管理対象サーバーを起動したら、次のアプリケーションURLを使用してWebアプリケーションが応答することを検証します。

親トピック: WC_Portal1およびWC_Portlet1管理対象サーバーの起動と検証

WebCenter PortalおよびPortlet管理対象サーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

Oracle WebCenter Portalを含めてドメインを拡張したら、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認します。

これにより、アプリケーションとWebサービスが、フロントエンドのセキュアURLに対してコールバックやその他の通信を実行できるようになります。

「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WebCenter Portalのセッション永続性の構成

WebLogic Server内のクラスタにデプロイされているアプリケーションでは、クラスタ内の1つ以上のアプリケーション・サーバー・インスタンスの喪失や停止が発生した場合に備えて、必要に応じ、HTTPセッションの永続性およびレプリケーションを利用して、ユーザーの操作性(セッション・データ)の高可用性を確保できます。サーバー・インスタンス間でこのような追加のセッション・ステート・レプリケーションを使用すると、アプリケーションのパフォーマンスが低下します。

WebCenter Portalでは、デフォルトでHTTPセッションの永続性が無効になっていますが、必要に応じて有効にできます。

テクニカル・リファレンスについては、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッションおよびセッション永続性の使用に関する項と、『Oracle WebLogic Serverクラスタの管理』のHTTPステートの複製に関する項を参照してください。

WebCenter PortalでHTTPセッションの永続性を有効にするには、次の手順に従って、カスタマイズされたデプロイメント・プランを構成および適用します。

  1. WebCenter Portalアプリケーションの新しいデプロイメント・プランのXMLファイルを作成します。デプロイメント・プランは、すべてのホストからアクセス可能な共有ファイル・システム上のDEPLOY_PLAN_HOMEに配置されている必要があります。たとえば、次のようにパス/ファイル名を設定します。

    DEPLOY_PLAN_HOME/DOMAIN_NAME/webcenterPlan.xml

    注意:

    <config-root>要素の値ではDEPLOY_PLAN_HOMEおよびDOMAIN_NAMEへのフルパスに置き換えます。 
    <?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-deployment-plan.xsd" global-variables="false">
<application-name>webcenter</application-name>
<variable-definition>
    <variable>
      <name>addPersistentStore</name>
      <value>replicated_if_clustered</value>
    </variable>
  </variable-definition>
 
<module-override>
     <module-name>spaces.war</module-name>
     <module-type>war</module-type>
     <module-descriptor external="false">
        <root-element>weblogic-web-app</root-element>
        <uri>WEB-INF/weblogic.xml</uri>
        <variable-assignment>
            <name>addPersistentStore</name>
            <xpath>/weblogic-web-app/session-descriptor/persistent-store-type</xpath>
            <operation>add</operation>
        </variable-assignment>
     </module-descriptor>
</module-override>
<config-root>DEPLOY_PLAN_HOME/DOMAIN_NAME/webcenterPlan.xml</config-root>
</deployment-plan>

    注意:

    DEPLOY_PLAN_HOMEおよびDOMAIN_NAMEはプレースホルダの置換値です。必要に応じて実際のパスまたは名前を指定してください。

    DEPLOY_PLAN_HOMEの値は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」で指定されている共有ファイル・システム・ディレクトリへのフル・パスに置き換える必要があります。

  2. WebLogic Serverコンソールに管理ユーザーとしてサインインします。例: weblogic_wcp

  3. 「ドメイン構造」パネルで、「デプロイメント」をクリックします。

  4. 「ロックして編集」をクリックします。

  5. WebCenterアプリケーションのチェック・ボックスを選択します。

  6. 「更新」をクリックします。

  7. 「デプロイメント・プランのパス」の現在の値が「(値が指定されていません)」になっていることを確認します。

    注意:

    カスタム・デプロイメント・プランがあらかじめ指定されている場合は、すでに指定されているデプロイメントのカスタマイズ内容をそのまま使用するのではなく、ステップ1のコードと比べて異なっている点を既存のデプロイメント・プラン・ファイルに統合します。

  8. 「デプロイメント・プランのパス」フィールドに関連付けられている「パスの変更」をクリックします。

  9. カスタム・デプロイメント・プランのXMLファイルのフルパスを入力し、「次へ」をクリックします。 
    DEPLOY_PLAN_HOME/DOMAIN_NAME/webcenterPlan.xml

  10. 「終了」をクリックします。WebCenter Portalアプリケーションのデプロイメントは再デプロイする必要があります。デプロイ済の状態から更新することはできません。再デプロイ・オプションの選択を変更しないでください。

  11. 「チェンジ・センター」パネルの「変更のアクティブ化」をクリックします。

  12. Portal_Cluster内のすべての管理対象サーバーを再起動します。

  13. ASERVER_HOME/config/config.xmlのWebCenterアプリケーション・デプロイメントのセクションに、更新済のプラン拡張がリストされていることを確認します。<plan-dir>要素と<plan-path>要素を確認します。

    次に例を示します。
    <app-deployment>
    <name>webcenter</name>
    <target>WC_Portal</target>
    <module-type>ear</module-type>
    <source-path>/u01/oracle/products/fmw/wcportal/archives/applications/webcenter.ear</source-path>
    <deployment-order>400</deployment-order>
    <plan-dir xsi:nil="true"></plan-dir>
    <plan-path>/u01/oracle/config/wcpedg_domain/webcenterPlan.xml</plan-path>
    <security-dd-model>DDOnly</security-dd-model>
    <staging-mode>nostage</staging-mode>
    <parallel-deploy-modules>false</parallel-deploy-modules>
  </app-deployment>

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

分析の構成

エンタープライズ・デプロイメントの参照アーキテクチャでは、分析コレクタは、通常、ローカルのWebCenter Portalアプリケーションと1対1の関係で通信するように構成されます(コレクタはデフォルト・ポートでローカル・ホストをリスニングします)。Portal_Clusterが、(従来のクラスタ構成を使用して手動で、またはWebLogic Server動的クラスタ機能を使用して)垂直方向にスケールアップし、各WCPHOSTに複数の管理対象サーバーが割り当てられる場合は、分析コレクタに対して追加の構成を行う必要があります。

Portalおよび分析サービスの垂直方向のスケールアップに対応するために、同一ホスト上で複数のコレクタを構成して、ポートの競合が起こらないようにすることはできますが、ポータルに登録できるアクティブな共通の分析コレクタは1つだけです。このアクティブな登録では、ホスト名とポートの組合せを1つだけ参照できます。このため、WebCenter Portalアプリケーションは、他の場合と同様に、デフォルトの分析コレクタ・ポートを使用してイベント・メッセージをローカル・ホストに送信するように構成することをお薦めします。

注意:

クラスタ化された分析コレクタでは、WebCenter Portalのイベントの収集はサポートしていません。

ホストごとに複数のポータル管理対象サーバーをスケールアップする場合、分析コレクタのポートの競合を回避するための追加構成が必要です。その場合、コレクタの最大ポート値の構成の詳細は、『Oracle WebCenter Portalの管理』の分析コレクタ設定の構成に関する項を参照してください。

ポータル・ランタイム構成では、単一ポートによる単一のアクティブな分析コレクタ・サービス登録のみをサポートします。ポータル登録と一致するポートを使用してホストごとに起動されたコレクタのみがデータを収集します。そのコレクタまたは管理対象サーバーが停止すると、そのホストの残りのポータル・サーバーのいずれについても分析イベント収集は発生しません。

スケールアップ・シナリオで、ローカルのハードウェア・ロード・バランサを使用して、同じ場所に配置されたコレクタに分析トラフィックを一元的に分散させることができるかどうかは、このエンタープライズ・デプロイメント・ガイドのリリース時点では検証されていません。この潜在的なトポロジ・オプションの使用については、アーキテクチャでの採用を最終決定する前に、非本番環境で十分にテストする必要があります。

  • WebCenter Portalのデフォルトの分析接続の登録
    WebCenter Portalアプリケーションを分析コレクタに接続します。
  • Portal管理対象サーバーのスケールアップに対応するための分析の構成
    Portal管理対象サーバーをスケールアップして、ホストごとに複数の管理対象サーバーが割り当てられるようにする場合は、分析に対して追加の構成および管理プロセスが必要となることがあります。スケールアップ操作は、従来の静的クラスタの場合、手動になることもあります。WebLogic Serverの動的クラスタ機能を使用する場合は、スケール・アップを手動または柔軟な方法(ポリシー・ベース)で行うことができます。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WebCenter Portalのデフォルトの分析接続の登録

WebCenter Portalアプリケーションを分析コレクタに接続します。

WebCenter Portalアプリケーションを分析コレクタに接続するには、次のステップを実行します。

  1. 次のように、weblogic_wcpユーザーとしてWLSTを使用してドメインの管理サーバーに接続します。
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. WebCenter Portalアプリケーションと分析コレクタの間に接続を作成し、それをデフォルトの接続にします(default=1)

    注意:

    この項で示すコマンドは、接続に対して特定のサーバー名がリストされていても、WebCenterクラスタ化アプリケーションに対して1回のみ実行する必要があります。この構成が設定されると、すべてのサーバーに適用されます。

    次に例を示します。

    createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="Collector31314", collectorPort=31314, isEnabled=1, default=1, isUnicast=1, collectorHost="localhost", timeout=30)

    『WebLogic Scripting Toolコマンド・リファレンス』のcreateAnalyticsCollectorConnectionに関する項も参照してください。

  3. 変更を確認します。
    listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")
    次に例を示します。 
    wls:/wcedg_domain/serverConfig/> listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1") 
--------------
Collector31314 
-------------- 
Cluster Name / Host Name: localhost 
Port: 31314 
Timeout: 30 
Unicast: true 
Enabled: true

    『WebLogic Scripting Toolコマンド・リファレンス』のlistDefaultAnalyticsCollectorConnectionに関する項も参照してください。

親トピック: 分析の構成

Portal管理対象サーバーのスケールアップに対応するための分析の構成

Portal管理対象サーバーをスケールアップして、ホストごとに複数の管理対象サーバーが割り当てられるようにする場合は、分析に対して追加の構成および管理プロセスが必要になることがあります。スケールアップ操作は、従来の静的クラスタの場合、手動になることもあります。WebLogic Serverの動的クラスタ機能を使用する場合は、スケール・アップを手動または柔軟な方法(ポリシー・ベース)で行うことができます。

注意:

この項は、ホストごとに複数のPortal管理対象サーバーがある場合のみ適用されます。

エンタープライズ・デプロイメント・ガイドのデフォルトの参照アーキテクチャ(ホストごとにPortal管理対象サーバーが1つだけ)に従ってトポロジが構成されている場合や、水平方向のスケールアウト・シナリオにのみ対応するようにトポロジが拡張されている場合は、この項は適用されず、省略できます。

スケールアップに対応するには、次の2つの追加構成を行う必要があります。

  1. 複数のコレクタ・サービスが単一ホストで稼働し、個別のポートでリスニングできるように分析コレクタのポート範囲を設定する必要があります。

  2. 追加コレクタ用のWebCenter Portal登録を追加する必要があります。デフォルト・ポートの分析コレクタが使用できない場合に、これらの登録を素早くアクティブにしてポータル・サーバーを再起動できます。再起動後、ポータル・サーバーは、新しくアクティブ化されたコレクタ登録の使用を試みます。

信頼できる分析の高可用性に関する要件は、次のとおりです。

  • ポータル内のデフォルトおよびアクティブな登録で指定されたポートでリスニングする分析コレクタ・プロセスがあること。

  • すべてのWCPHOSTで構成された分析コレクタのポート範囲内にある各ポートで使用可能な分析コレクタ・プロセスがあること。

  • すべてのWCPHOSTに同一番号のスケールアップされたポータル管理対象サーバーがあること。ない場合、ポータル・サーバーによっては選択した登録用のローカルホストの現在デフォルトまたは使用可能なポートでコレクタが見つからないことがあります。

次の各項では、スケール・アップに対応する際に分析に対して行う必要のある追加構成について説明します。

  • 分析コレクタのポート範囲の構成
    分析コレクタ設定は環境全体にわたるもので、サーバー単位にカスタマイズすることはできません。maxPortパラメータは、複数の分析コレクタ・インスタンスでホストごとに固有のポートを使用するために、defaultPortより上の有効範囲を指定します。コレクタ・プロセスがデフォルト・ポートにバインドできない場合、maxPort値に達するまで、すべてのポート番号を試行します。使用可能なポートがない場合、ポータル管理対象サーバーは適切に起動できません。
  • WebCenter Portalでの分析コレクタの追加登録
    構成した分析コレクタのポート範囲内のポートごとに、固有の接続名および分析コレクタ構成で割り当てたポート範囲に基づいたポートを指定して、デフォルト以外のコレクタを追加登録します。これにより、コレクタの登録を永続的かつ有効な方法で切り替えることができるようになり、メンテナンス・プロセスが簡略化します。
  • ポータルのデフォルト分析登録のフェイルオーバー
    分析コレクタ・サービスがデフォルト・ポートでリスニングしているPortal管理対象サーバーで障害が発生した場合は、ポータル構成内の代わりの分析接続をデフォルト接続として選択し、稼働しているポータル・サーバーをできるだけ早く再起動する必要があります。

親トピック: 分析の構成

分析コレクタのポート範囲の構成

分析コレクタ設定は環境全体にわたるもので、サーバー単位にカスタマイズすることはできません。maxPortパラメータは、複数の分析コレクタ・インスタンスでホストごとに固有のポートを使用するために、defaultPortより上の有効範囲を指定します。コレクタ・プロセスがデフォルト・ポートにバインドできない場合、maxPort値に達するまで、すべてのポート番号を試行します。使用可能なポートがない場合、ポータル管理対象サーバーは適切に起動できません。

分析のmaxPort値を更新するには、ドメインの管理サーバーに接続する際に次のWLSTメソッドを使用します。

  1. 次のように、WLSTを使用してドメインの管理サーバーに接続します。
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. 次のWLSTコマンドを使用して、現行の分析コレクタ構成をリストします。
    listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')

    注意:

    • コレクタ・デフォルト・ポートおよびコレクタ最大ポートの割当てを確認してください。追加設定なしの状態では、同じポート番号です。

    • クラスタの値は無視する必要があります。

    • 分析のクラスタリングはサポートされておらず、障害が発生する可能性があります。

    次に例を示します。
    wls:/wcedg_domain/serverConfig/> listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root MBean.
For more help, use help('domainRuntime')

Collector Hostname = localhost 
Collector Default Port = 31314 
Collector Maximum Port = 31314 
Broadcast Type = Multicast 
Collector Heartbeat Frequency = 10 
Cluster Enabled? = 0 
Cluster Name =
  3. 必要な新しいコレクタ最大ポート番号を計算します。

    スケーラビリティのために必要と判断したPortal管理対象サーバーの数を想定し、環境で割り当てられたWCPHOSTnマシンの数を偶数倍した数に切り上げます。この値が、WCPHOSTごとに使用可能なコレクタ・インスタンスの合計数です。コレクタを備えたポータル管理対象サーバーの実際の数は、この値より少なくなることがあります。その場合でも、最大ポート番号は、同じ場所に配置された分析コレクタまたはPortal管理対象サーバーの最大数に対応できます。この倍数から1を減算して分析コレクタのデフォルト・ポート番号に加算し、分析コレクタのmaxPortパラメータ値を計算します。

    シナリオ例:

    • 環境の要件/ファクト:

      • SLAでは、ホスト障害時のパフォーマンス低下(サーバーの減少)を考慮します。

      • スケーラビリティ/パフォーマンスに必要なポータル管理対象サーバーの数: 5

      • 購入したWCPHOSTマシンの数: 2

      • 分析コレクタのデフォルト・ポートは変りません(31314)

      • ポータルおよび分析コレクタは同じ管理対象サーバー(WCP 12.2.1追加設定なしのトポロジ)にデプロイされます

    • 分析:

      • 必要なサーバー数をホスト数で除算した値を偶数に切り上げることで、ホスト当たりの最大サーバー数を導出します。

        ROUNDUP(5/2) = 3サーバー/ホスト(スケーラビリティのために必要な最大数)

      • WCPHOSTごとに3コレクタ分の分析コレクタ用ポート範囲をサポートする必要があります。

      • 分析コレクタのmaxPort: 31316

        デフォルト・ポート + ホストごとのポータル・サーバー数 - 1 = (31314+3-1)

  4. コレクタ構成設定を更新してmaxPort値を設定します。

    maxPort値は、コレクタ・デフォルト・ポート以上の増分されたポート番号です。

    注意:

    この項で示すコマンドは、接続に対して特定のサーバー名がリストされていても、WebCenterクラスタ化アプリケーションに対して1回のみ実行する必要があります。この構成が設定されると、すべてのサーバーに適用されます。
    次に例を示します。 
    setAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1', maxPort=31316)

    『WebLogic Scripting Toolコマンド・リファレンス』のcreateAnalyticsCollectorConnectionに関する項も参照してください。

  5. listAnalyticsCollectorConfig() WLSTメソッドを使用してコレクタ最大ポート値に対する変更を確認します。
    次に例を示します。 
    listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')

Collector Hostname  =  localhost
Collector Default Port  =  31314
Collector Maximum Port  =  31316
Broadcast Type  =  Multicast
Collector Heartbeat Frequency  =  10
Cluster Enabled?  =  0
Cluster Name  =

    『WebLogic Scripting Toolコマンド・リファレンス』のlistDefaultAnalyticsCollectorConnectionに関する項も参照してください。

  6. 「WebCenter Portalでの分析コレクタの追加登録」を実行したら、ポータル・サーバーを再起動します。
WebCenter Portalでの分析コレクタの追加登録

構成した分析コレクタのポート範囲内のポートごとに、固有の接続名および分析コレクタ構成で割り当てたポート範囲に基づいたポートを指定して、デフォルト以外のコレクタを追加登録します。これにより、コレクタの登録を永続的かつ有効な方法で切り替えることができるようになり、メンテナンス・プロセスが簡略化します。

次に例を示します。 
createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="NAME", collectorPort=PORTNUMBER, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)

ステップは次のとおりです。

  1. 次のように、WLSTを使用してドメインの管理サーバーに接続します。
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. 次のWLSTコマンドを使用して、現行の分析コレクタ構成をリストします。
    listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')
    次に例を示します。
    Collector Hostname  =  localhost
Collector Default Port  =  31314
Collector Maximum Port  =  31316
Broadcast Type  =  Multicast
Collector Heartbeat Frequency  =  10
Cluster Enabled?  =  0
Cluster Name  =

    注意:

    デフォルト・ポートから最大ポートまでの範囲内にある(最大ポート番号を含む)すべてのポート番号について、次のステップを繰り返す必要があります。デフォルト・ポートの登録は先に完了しておく必要があります。
  3. WLSTを使用して、デフォルト・ポートより上のポート番号から最大ポート番号までの各ポートについて登録を追加します。connectionName値とcollectorPort値は登録ごとに変更します。
    次に例を示します。
    createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="Collector31315", collectorPort=31315, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)

createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="Collector31316", collectorPort=31316, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)
  4. WLSTを使用して、すべての分析登録について詳細をリストして確認します。
    listAnalyticsCollectorConnections(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31315
------------------
Cluster Name / Host Name: localhost
Port: 31315
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31316
------------------
Cluster Name / Host Name: localhost
Port: 31316
Timeout: 30
Unicast: true
Enabled: true
  5. WLSTを使用して、デフォルトの(現在アクティブな)分析登録について詳細をリストします。
    次に例を示します。 
    listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true

    注意:

    この例では、ポート: 31314 (デフォルト・ポート)を示しています。複数の登録が作成されていますが、ポータルの分析登録は代替接続/ポートにまだフェイルオーバーされていません。マシンごとに起動される最初のポータル管理対象サーバーには、デフォルト・ポートでリスニングしている分析コレクタがあります。
  6. すべてのWC_Portaln管理対象サーバーを再起動して、変更を有効にします。これは、同時に実行することも、ローリング方式で実行することも可能です。
    例 - 同時:
    shutdown('Portal_Cluster', 'Cluster', force='true', block='true')
start('Portal_Cluster',  'Cluster', block='true')
    例 - ローリング方式(停止なし):
    shutdown('WC_Portal1', force='true', block='true')
start('WC_Portal1', block='true')

shutdown('WC_Portal2', force='true', block='true')
start('WC_Portal2', block='true')
ポータルのデフォルト分析登録のフェイルオーバー

分析コレクタ・サービスがデフォルト・ポートでリスニングしているPortal管理対象サーバーで障害が発生した場合は、ポータル構成内の代わりの分析接続をデフォルト接続として選択し、稼働しているポータル・サーバーをできるだけ早く再起動する必要があります。

そうなるまで、そのマシンの残りのポータル・インスタンスに対する分析収集は、デフォルト・ポートのコレクタとやり取りして分析メトリックを記録することができません。デフォルトとしてアクティブに使用される登録は一度に1つだけです。

デフォルト分析登録のフェイルオーバーは手動プロセスです。変更は環境全体にわたるものですが、各ポータル・サーバー・インスタンスの再起動時にのみ有効になります。

注意:

この項は、ホストごとに複数のPortal管理対象サーバーがある場合にのみ適用されます。

エンタープライズ・デプロイメント・ガイドのデフォルトの参照アーキテクチャ(ホストごとにPortal管理対象サーバーが1つだけ)に従ってトポロジが構成されている場合や、水平方向のスケールアウト・シナリオにのみ対応できるようにトポロジが拡張されている場合は、この項は適用されません。

デフォルト分析登録を変更するには、次のステップを実行します。

  1. 次のように、WLSTを使用してドメインの管理サーバーに接続します。
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. WLSTを使用して、デフォルトの(現在アクティブな)分析登録について詳細をリストします。
    listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true
  3. WLSTによって使用可能な分析登録をリストし、別のコレクタ名を選択してデフォルトとして設定します。
    listAnalyticsCollectorConnections(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31315
------------------
Cluster Name / Host Name: localhost
Port: 31315
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31316
------------------
Cluster Name / Host Name: localhost
Port: 31316
Timeout: 30
Unicast: true
Enabled: true
  4. WLSTを使用して、デフォルト分析登録を更新します。
    setDefaultAnalyticsCollectorConnection(appName="webcenter", name="Collector31315", server="WC_Portal1")
  5. すべてのWC_Portaln管理対象サーバーを再起動して、変更を有効にします。これは、同時に実行することも、ローリング方式で実行することも可能です。
    例 - 同時:
    shutdown('Portal_Cluster', 'Cluster', force='true', block='true') 
start('Portal_Cluster', 'Cluster', block='true')
    例 - ローリング方式(停止なし):
    shutdown('WC_Portal1', force='true', block='true') 
start('WC_Portal1', block='true')  

shutdown('WC_Portal2', force='true', block='true') 
start('WC_Portal2', block='true')

REST API構成の確認

この項では、REST APIの構成手順について説明します。

リリース12.2.1.0では、WebCenterのREST APIが、資格証明マップ構成を使用して事前構成されています。

RESTセキュリティ・トークンの正常な機能を可能にする資格証明ストア内のシード・エントリを確認するには、次のWLSTコマンドを実行します。

注意:

資格証明マップがすでに存在する場合は、JPS-01007例外メッセージが戻されます。これにより、構成を確認します。
  1. 次のように、コマンドラインのOracle WebLogic Scripting Tool (WLST)を使用して管理サーバーに接続します。
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('weblogic_admin_username','weblogic_admin_pwd','t3://ADMINVHN:7001')
  2. 次のWLSTのコマンドを実行して、資格証明ストアを構成します。
    createCred(map="o.webcenter.jf.csf.map", key="keygen.algorithm", 
     user="keygen.algorithm", password="AES") 
createCred(map="o.webcenter.jf.csf.map", key="cipher.transformation", 
     user="cipher.transformation", password="AES/CBC/PKCS5Padding")

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

拡張したドメイン用のOracle HTTP Serverの構成

次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

Oracle WebCenter Portalクラスタ用のOracle HTTP Serverの構成

Oracle WebCenter Portalクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、wcp.example.com仮想サーバーのパラメータを作成して定義するOracle HTTP Server構成ファイルを追加作成します。

この手順では、「アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

次のステップを実行して、リクエストが正しくルーティングされるように仮想ホスト構成ファイルを更新します。

  1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(OHS1)の構成ディレクトリに変更します。
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/
  2. wcp_vh.confファイルを編集し、次のディレクティブをファイルの終わり近く、最終行の<VirtualHost>のすぐ上に追加します。

    注意:

    静的または動的クラスタへの割当てに従って、適切なポート番号を構成します。「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、作成される動的管理対象サーバーごとに増分ポート番号が使用されます。

    WebLogicClusterディレクティブでは、部分的に停止した場合の初期接続を保証するために十分なだけの数の冗長なserver:portの組合せを指定する必要があります。クラスタ・メンバーの実際の合計リストは、任意のノードとの初回の接続時に自動的に取得されます。 

    # WebCenter Portal Application (previously called Spaces) 
<Location /webcenter>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /webcenterhelp>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /rss>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /rest>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /portalTools>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /wsrp-tools> 
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

</VirtualHost>
  3. wcp_vh.confファイルをWEBHOST2上の2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。
    scp WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/wcp_vh.conf \
WEBHOST2:/WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/wcp_vh.conf
  4. WEBHOST2にログインし、ディレクトリを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリに変更します。
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/
  5. wcp_vh.confを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。
  6. 両方のOracle HTTP Serverを再起動します。

親トピック: 拡張したドメイン用のOracle HTTP Serverの構成

ロード・バランサによるOracle WebCenter Portalパブリック・サービスURLの検証

Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層にパブリック・サービス・リクエストをルーティングできることを確認する手順は次のとおりです。

  1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

    サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

  2. 次のURLにアクセスできることを確認します。

親トピック: 拡張したドメイン用のOracle HTTP Serverの構成

内部WebCenterサービス用のHTTPサーバーの構成

内部Oracle WebCenterサービスにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、既存のwcpinternal_vh.confファイルを編集します。

この手順では、「アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

次のステップを実行して、リクエストが正しくルーティングされるように仮想ホスト構成ファイルを更新します。

  1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/
  2. wcpinternal_vh.confファイルを編集し、次のディレクティブをファイルの終わり近く、最終行の</VirtualHost>のすぐ上に追加します。

    注意:

    静的または動的クラスタへの割当てに従って、適切なポート番号を構成します。「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、作成される動的管理対象サーバーごとに増分ポート番号が使用されます。

    WebLogicClusterディレクティブでは、部分的に停止した場合の初期接続を保証するために十分なだけの数の冗長なserver:portの組合せを指定する必要があります。クラスタ・メンバーの実際の合計リストは、任意のノードとの初回の接続時に自動的に取得されます。 

    # WebCenter Portal Application Services

<Location /webcenter>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF 
</Location>  

<Location /webcenterhelp>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /rss>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /rsscrawl>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /sesUserAuth>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /rest>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Portlets
<Location /pagelets>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /portalTools>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /wsrp-tools>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Collector
<Location /collector>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

</VirtualHost>
  3. wcpinternal_vh.confファイルをWEBHOST2上の2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。
    scp WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/wcpinternal_vh.conf \
WEBHOST2:/WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/wcpinternal_vh.conf
  4. WEBHOST2にログインし、ディレクトリを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリに変更します。
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/
  5. wcpinternal_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1の参照からWEBHOST2の参照に変更します。
  6. 両方のOracle HTTP Serverを再起動します。

親トピック: 拡張したドメイン用のOracle HTTP Serverの構成

ロード・バランサによるOracle WebCenter Portal内部サービスURLの検証

Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層に内部サービス・リクエストをルーティングできることを確認する手順は次のとおりです。

  1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

    サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

  2. 次のURLにアクセスできることを確認します。

親トピック: 拡張したドメイン用のOracle HTTP Serverの構成

外部サービス用のWebCenter Portalの構成

この項では、Fusion Middleware ControlまたはWLSTコマンドを使用して、WebCenter Portalアプリケーション用に外部のツールおよびサービスを構成する方法を説明します。多くの外部サービスでは、WebCenter Portalアプリケーションとバックエンド・サーバー間に接続を設定する必要があります。

次に示すサービス構成を行うたびに、様々な管理対象サーバーを再起動して変更を有効にする必要があります。一部の再起動は、プロセス実行中の特定の時点で行う必要があります。その他の再起動については、この項を最初から最後まで完了する場合は、必要に応じて項の最後まで遅らせることができますが、そうでない場合は、すべての再起動を各サブトピック内で行う必要があります。サービス構成の項の最後まで遅らせることができる再起動については、注意書きでそのことを示しています。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張

WebCenterポートレット・プロデューサ・アプリケーションのデフォルトWebサービス・ポリシーの構成

Oracle WebCenter Portalのインストール後に、デフォルトのOracle Web Services Manager (OWSM)セキュリティ・ポリシーを次にアタッチする必要があります。

  • WSRPツール・プロデューサ(wsrp-tools)

これらのWebサービス・エンド・ポイントに対するセキュリティ・ポリシーは出荷時には構成されていないため、これらのステップが必要になります。

デフォルトのWebサービス・セキュリティ・ポリシーをアタッチする手順は次のとおりです。
  1. WC_Portal1、WC_Portal2、WC_Portlet1およびWC_Portlet2の各管理対象サーバーが起動し、稼働していることを確認します。
  2. 次のWebLogic Scripting Toolを起動します。
    WCPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh
  3. 管理者として管理サーバーに接続します。

    例

    connect("weblogic_wcp","admin password","t3://ADMINVHN:7001")

    詳細は、『Oracle WebCenter Portalの管理』のOracle WebLogic Scripting Tool (WLST)コマンドの実行に関する項を参照してください。

  4. WLSTコマンドを実行し、デフォルトのOWSMセキュリティ・ポリシー(oracle/wss10_saml_token_service_policy)を次の各エンド・ポイントにアタッチします。

    • WSRPツール・プロデューサ(wsrp-tools)

    注意:

    このトピックの例では、ご使用の環境のドメイン名および管理対象サーバー名を使用してアプリケーションのパラメータ値を構成します。

    WebServiceポリシーのアタッチの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のWebサービスのカスタムWLSTコマンドに関する項を参照してください。

    1. 次のWLSTコマンドを実行して、デフォルトのOWSMセキュリティ・ポリシーをWSRPツール・プロデューサのWebサービス・エンドポイントにアタッチします。1回の実行で、クラスタ内のすべてのサーバーに対してポリシーが構成されます(WC_Portlet1に対して実行)。次のコマンドのドメイン名には適切な値を設定してください。
      attachWebServicePolicy(application='/domain_name/WC_Portlet1/wsrp-tools', moduleName='wsrp-tools', moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

      Webサービス・ポリシーのアタッチの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のWebサービスのカスタムWLSTコマンドに関する項を参照してください(attachWebServicePolicy()の参照への直接リンク)。

      ここで選択するWS-Securityポリシーの詳細は、『Oracle WebCenter Portalの管理』のWSRPプロデューサのセキュリティ接続パラメータに関する項を参照してください。次の項でポートレット・プロデューサを登録するときにも、ここでアタッチした同じトークン・ポリシーを一貫して使用する必要があります。

  5. PortalおよびPortletクラスタ内のすべての管理対象サーバーを再起動します。

    注意:

    これらの再起動は、サービス接続を構成する前に、この時点で完了する必要があります。

親トピック: 外部サービス用のWebCenter Portalの構成

ポートレット・プロデューサの登録

WebCenter Portalアプリケーションに、すぐに使用できるいくつかのポートレット・プロデューサを登録できます。WebCenter Portalエンタープライズ・デプロイメントでは、必要なプロデューサのURLは次のとおりです。

  • WSRPプロデューサURL: http://wcpinternal.example.com/wsrp-tools/portlets/wsrp2?WSDL

  • WebClippingプロデューサURL: http://wcpinternal.example.com/portalTools/webClipping/providers

  • OmniPortletプロデューサURL: http://wcpinternal.example.com/portalTools/omniPortlet/providers

ポートレット・プロデューサは、Fusion Middleware ControlまたはWLSTコマンドを使用して登録できます。

親トピック: 外部サービス用のWebCenter Portalの構成

Fusion Middleware Controlを使用したすぐに使用できるポートレット・プロデューサの登録

Fusion Middleware Controlを使用してポートレット・プロデューサを登録する方法の詳細は、『Oracle WebCenter Portalの管理』の「ポートレット・プロデューサの管理」を参照してください。

WLSTを使用したすぐに使用できるポートレット・プロデューサの登録
WLSTを使用し、すぐに使用できるポートレット・プロデューサを登録するには、次の手順を実行します。
  1. 次のWebLogic Scripting Toolを起動します。
    WCPHOST1> ORACLE_HOME/oracle_common/common/bin/wlst.sh
  2. WLSTで、管理者として接続します。

    次に例を示します。

    connect("weblogic_wcp","admin password","t3://ADMINVHN:7001",server="WC_Portal1")
  3. すぐに使用可能なOmniPortletおよびWSRPポートレット・プロデューサを登録します。

    次に例を示します。

    registerOOTBProducers(producerHost='wcpinternal.example.com',producerPort=80, appName='webcenter', server='WC_Portal1')
    説明:

    • producerHostの値は、内部ロード・バランサの完全修飾ドメイン名に設定されます。

    • serverの値は、最初のPortal管理対象サーバーの名前です。

    • appNameの値はwebcenter (WebCenter Portalアプリケーションの名前)です。

    『WebCenter WLSTコマンド・リファレンス』のregisterOOTBProducersに関する項も参照してください。

  4. 新しいWSRPプロデューサをリストして、次のステップに必要なWSDL URLを表示します。
    listWSRPProducers(appName='webcenter', server='WC_Portal1')
  5. 「WebCenterポートレット・プロデューサ・アプリケーションのデフォルトWebサービス・ポリシーの構成」で以前にアタッチしたWS-Securityポリシー用にWSRPプロデューサ・サービスを構成します。

    • 前のステップで表示されたWSRP URLに基づいてurlパラメータを更新します。

    • 『WebCenter WLSTコマンド・リファレンス』でsetWSRPProducer() tokenTypeの詳細に指定されているとおりに、必要なポリシーに適した値にtokenTypeパラメータを更新します。
      setWSRPProducer(appName='webcenter', server='WC_Portal1', name='wc-WSRPTools', url='http://wcpinternal.exaple.com:80/wsrp-tools/portlets/wsrp2?WSDL', enforcePolicyURI='1', tokenType='WSS10_SAML_TOKEN_ONLY')

      注意:

      tokenTypeパラメータの値は、前の項でアタッチされたWS-Securityポリシーに適切に一致している必要があります。
  6. WSRPプロデューサをリストして、更新されたTokenType構成を確認します。
    listWSRPProducers(appName='webcenter', server='WC_Portal1')
  7. Portal_Cluster内のすべてのサーバーを再起動します。

    注意:

    追加のサービスを構成する場合は、ポータルの再起動を項の最後に1回だけ行うことができます。

ページレット・プロデューサの登録

WSRP、Oracle JPDKポートレットおよびOpenSocialガジェットをWebCenter Portalでページレットとして公開するには、ページレット・プロデューサを登録する必要があります。WebCenter Portalエンタープライズ・デプロイメントでは、必要なページレット・プロデューサのURLは次のとおりです。

http://wcpinternal.example.com/pagelets

ページレット・プロデューサは、Fusion Middleware ControlまたはWLSTコマンドを使用して登録できます。

親トピック: 外部サービス用のWebCenter Portalの構成

Fusion Middleware Controlを使用したページレット・プロデューサの登録

Fusion Middleware Controlを使用してページレット・プロデューサを登録するには:

  1. 管理者のアカウント(weblogic_wcpなど)を使用してFusion Middleware Controlにサインインし、WebCenter Portalのホーム・ページに移動します。

    注意:

    Enterprise Manager Fusion Middleware ControlでWebCenterリソースを管理する場合、リモートLDAPオーセンティケータ(weblogic_wcpなど)で作成されたWebCenter固有の管理ユーザーを使用することをお薦めします。「エンタープライズ・デプロイメントの管理用のロールの構成」を参照してください。

    『Oracle WebCenter Portalの管理』のWebCenter Portalのホームページへの移動に関する項を参照してください。

  2. 「WebCenter Portal」メニューから、「プロデューサの登録」を選択します。

  3. 次の表に示すように、ページレット・プロデューサの接続詳細を入力します。

    フィールド 説明

    接続名

    このページレット・プロデューサのインスタンスをアプリケーション内で識別するための一意の名前。名前は、すべてのWebCenter Portal接続タイプにおいて一意である必要があります。ここで指定した名前は、「UIコンポーネント」→「ページレット・プロデューサ」フォルダにあるコンポーザに表示されます(デフォルト)。

    プロデューサ・タイプ

    「ページレット・プロデューサ」を選択します。

    サーバーURL

    ページレット・プロデューサへのURL。URLには、完全修飾ドメイン名を含める必要があります。次の構文を使用します。

    <protocol>://<host_name>:<port_number>/pagelets/

    次に例を示します。

    http://wcpinternal.example.com/pagelets/

    ページレットにセキュアなデータが含まれている場合、登録するURLでhttpsプロトコルを使用する必要があります。次に例を示します。

    https://wcp.example.com/pagelets/

    コンテキスト・ルートは、必要に応じて/pagelets/から変更できます。詳細は、『Oracle WebCenter Portalの管理』のページレット・プロデューサの別のコンテキストへの再デプロイに関する項を参照してください。

    注意: WebCenter Portalでは、ページレット・プロデューサのURLがOAMによって保護されている場合、ページレット・カタログへのURLを除外する(アクセス制御なしで直接マップする)必要があります。そうしないと、RESTを使用した場合にカタログが空白になります。ページレット・カタログのURLは、http://<host_name>:<port_number>/ pagelets/api/v2/ensemble/pageletsです

  4. 「OK」をクリックします。新しいプロデューサが接続表に表示されます。

WLSTを使用したページレット・プロデューサの登録

WLSTを使用し、すぐに使用できるページレット・プロデューサを登録する手順は次のとおりです。

  1. 次のWebLogic Scripting Toolを起動します。

    WCPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh

  2. WLSTで、管理者として接続します。

    たとえば、次のようにします。

    connect("weblogic_wcp","admin password","t3://ADMINVHN:7001",server="WC_Portal1")

  3. 次のコマンドを入力して、ページレット・プロデューサを登録します。

    registerPageletProducer(appName='webcenter', name='PageletProducer', url='http://wcpinternal.example.com/pagelets', server='WC_Portal1')

コマンドの構文と例は、WebCenter WLSTコマンド・リファレンスのregisterPageletProducerに関する項を参照してください。

WLSTを使用して、現在の接続詳細を表示または編集することもできます。

WLSTコマンドの実行方法の詳細は、『Oracle WebCenter Portalの管理』のOracle WebLogic Scripting Tool (WLST)コマンドの実行に関する項を参照してください。

検索サービスの構成

『Oracle WebCenter Portalの管理』のWebCenter PortalでのOracle Secure Enterprise Searchの管理に関する項の手順を使用して、Oracle Secure Enterprise Search (Oracle SES)のサービスとクローラを構成できます。

注意:

WebCenter Portalは、Elasticsearchとの基本的な統合機能を備えています。WebCenterエンタープライズ・デプロイメント・トポロジにおける堅牢な高可用性Elasticsearchデプロイメントの構成は、このリリースの時点では完全にテストされていません。基本構成については、『Oracle WebCenter Portalの管理』のWebCenter PortalでのElasticsearchを使用した検索の管理に関する項を参照してください。WebCenterエンタープライズ・デプロイメント・ガイドのトポロジを使用するには、クラスタリング、HAおよびセキュリティ/アクセシビリティに関する追加の分析および構成が数多く必要になります。

次の点を確認します。

  • 『Oracle WebCenter Portalの管理』のWebCenter PortalでのOracle Secure Enterprise Searchの管理に関する項の説明のとおり、Oracle Secure Enterprise SearchがOracle Internet Directoryに登録され、WebCenter PortalアプリケーションがOracle SESの信頼できるエンティティとして構成されていること。

  • 『Oracle WebCenter Portalの管理』のOracle SES接続の設定に関する項の説明のとおり、WebCenter PortalアプリケーションとOracle Secure Enterprise Searchの間に接続が存在すること。

wcinternal_vh.confファイルで、次に示すwcpinternal.example.com仮想ホストの追加のURL場所のパスを追加して、各OHSサービスを再起動します。 

<Location /rsscrawl>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /sesUserAuth>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

親トピック: 外部サービス用のWebCenter Portalの構成

SMTPメール・サーバー用のOracle WebCenter Portal通知の構成

WebCenter Portalエンタープライズ・デプロイメントで、メールを使用して通知を送信することにした場合、企業のメール・サーバーへの接続を構成し、送信されたメールが正しく表示されるように固有のパラメータをいくつか指定する必要があります。

メール・サーバーおよびビジネス要件について不足なく構成するには、このタスクを完了する前に、必須およびオプションの構成とパラメータに関する詳細を『Oracle WebCenter Portalの管理』の「メールの管理」で確認してください。

メール・サーバーは、Fusion Middleware ControlまたはWLSTコマンドを使用して登録できます。

親トピック: 外部サービス用のWebCenter Portalの構成

Fusion Middleware Controlを使用したメール・サーバーの登録

Fusion Middleware Controlを使用してメール・サーバーを登録する方法の詳細は、『Oracle WebCenter Portalの管理』のFusion Middleware Controlを使用したメール・サーバーの登録に関する項を参照してください。

WLSTを使用したメール・サーバーの登録

WLSTコマンドのcreateMailConnectionを使用して、メール・サーバーの接続を作成します。
  1. 次のWebLogic Scripting Toolを起動します。
    ORACLE_HOME/oracle_common/common/bin/wlst.sh
  2. 管理サーバーに接続します。

    次に例を示します。

    connect('weblogic_wcp','admin password','t3://ADMINVHN:7001')
  3. メール・サーバー用の外部アプリケーション接続を登録します。
    createMailExtAppConnection(appName='webcenter', name='CorpMailServer', displayName='Corporate Mail Server', server='WC_Portal1')

    注意:

    「"webcenter"という名前の別のアプリケーションが存在します...」という警告は無視してください。
  4. メール・サーバー接続を登録します。
    createMailConnection(appName='webcenter', name='NotificationSharedConn', smtpHost='mail.example.com', smtpPort=25, smtpSecured=0, 
timeout=10, default=1,appId='CorpMailServer', server='WC_Portal1')

    注意:

    配信リストを通知する機能など、その他の機能は使用可能であり、メール・サーバーおよびビジネス・ニーズよっては必須になることもあります。『Oracle WebCenter Portalの管理』の「メールの管理」を参照してください

  5. 必須のメール・サーバー接続プロパティを設定します。

    これらのプロパティは、特定のメール・アドレスが外部アプリケーションとメール・サーバーで同じであることを保証します。これらのプロパティはメール接続に追加され、メールで「送信元」、「表示名」および「返信先」の各フィールドに使用されます。

    次に例を示します。

    setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.emailAddress', value='john.doe@example.com')

setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.displayName', value='John Doe')

setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.replyToAddress', value='feedback@example.com')
  6. Exchange 2007についてのみ、汎用配信リストを作成します。そのためには、mail.exchange.dl.group.typeプロパティの値を2 (デフォルト値)から8に更新する必要があります。

    次のように、mail.exchange.dl.group.typeメール・プロパティに値8を指定します。 

    setMailServiceProperty(appName='webcenter', property='mail.exchange.dl.group.type', value='8')

    アプリケーションで、要求時にユーザーID情報をメール送信する機能を備えた自己登録ページを用意している場合、ここで選択した外部アプリケーションに対してパブリック資格証明が構成されていることを確認してください。パブリック資格証明が定義されていない場合、要求時にユーザーにメールが送信されません。WebCenter Portalでは、デフォルトの自己登録ページでこの機能を提供しています。

  7. Portal_Cluster内のすべてのサーバーを再起動します。

    注意:

    追加のサービスを構成する場合は、ポータルの再起動を項の最後に1回だけ行うことができます。

コンテンツ・サーバーの接続の構成

Oracle WebCenter Portalは、ファイルのアップロード、ファイルとフォルダの作成と管理、ファイルのチェックアウト、バージョン管理を含む、コンテンツ管理とストレージ機能をサポートします。

WebCenter Portalでコンテンツ統合を提供するには、WebCenter Content Serverの接続を1つ以上構成し、それをデフォルト接続(アクティブまたはプライマリ接続と呼ばれることもあります)としてマークする必要があります。要件の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalのインストールと構成』のOracle WebCenter Content Serverの要件に関する項を参照してください。

WebCenter Portal Content Managerコンポーネント・ファイルのアップロードに対して高可用性を保証するには、追加構成が必要です。

親トピック: 外部サービス用のWebCenter Portalの構成

WebCenter PortalアプリケーションへのOracle WebCenter Contentの登録

Oracle WebCenter Content ServerをWebCenter Portalアプリケーションに登録するステップを示します。

注意:

Content Serverの登録の詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのツールおよびサービス用のバックエンド・データ・リポジトリの構成に関する項を参照してください。

ステップは次のとおりです。
  1. 管理者のアカウント(例: weblogic_wcp)を使用してFusion Middleware Controlにサインインして、アプリケーションのホーム・ページに移動します。

    たとえば、WebCenter Portalのホーム・ページに移動するには、「WebCenter」→「ポータル」→「サーバー」→WebCenter Portal (WC_Portal1)の順に開きます。

    注意:

    複数のWebCenter Portalエントリが表示されます(WebLogic管理対象サーバーごとに1つ)。いずれかを選択します。この項でのアプリケーション登録は、ポータル全体に適用されます。
  2. 「WebCenter Portal」メニューから「設定」→「サービス構成」を選択します。
  3. 「WebCenterサービス構成」ページのサービスのリストから、「コンテンツ・リポジトリ」を選択します。
  4. 新しいコンテンツ・リポジトリに接続するには、「追加」をクリックします。
  5. この接続の一意の名前を入力し、コンテンツ・リポジトリ・タイプを指定して、この接続をアプリケーションのアクティブな(またはデフォルトの)接続にするかどうかを指定します。

    • 接続名

      このコンテンツ・リポジトリ接続の名前を入力します。

      • 名前は、WebCenter Portalアプリケーション内ですべての接続タイプにわたって一意である必要があります。

      • ポータルやコンテンツ・フォルダなどをエクスポートまたはインポートする際に参照を引き続き使用できるようにするために、名前はポータル環境間で一貫している必要があります。

    • リポジトリ・タイプ

      接続先のリポジトリのタイプとして「Oracle Content Server」を選択します。

    • アクティブな接続

      このチェック・ボックスを選択します。

      1つのコンテンツ・リポジトリの登録を、WebCenter Portalの機能に使用するデフォルト・リポジトリとして機能するように、アクティブな接続として指定する必要があります。

      WebCenter Portalは複数のコンテンツ・リポジトリに接続できます。すべての接続が使用されますが、デフォルトの選択肢として機能するアクティブな接続として、いずれか1つの接続を指定する必要があります。

  6. 「アクティブな接続」チェック・ボックスを選択したら、次に示す追加のコンテンツ・リポジトリの詳細を入力します。デフォルトのリポジトリ接続については、これらの値を指定する必要があります。

    注意:

    WebCenter Portalアプリケーションでは、Portalを正しく機能させるために、これらの設定に基づいて、次回再起動時にデフォルトの/アクティブなWebCenter Contentリポジトリが再構成されます。

    • コンテンツ管理者

      デフォルト値のsysadminをお薦めします。この値をカスタマイズする場合は、ここで有効なWCC管理ユーザー名を構成します。この接続では、WebCenter Portalユーザーのかわりに、WebCenter Portalコンテンツ用のフォルダの作成や維持、コンテンツのアクセス権限の管理などの操作を実行できるようにするために、管理権限が必要です。

    • ポータル・サーバー識別子

      WebCenter Portalのすべてのコンテンツが格納されるルート・フォルダを入力します。まだ存在しないコンテンツ・リポジトリ・フォルダを指定するには、/foldernameの形式を使用します。たとえば、/MyWebCenterPortalのように指定します。ルート・フォルダは、ルート自体である/にはできず、アプリケーション全体で一意である必要があります。指定したフォルダはアプリケーションの起動時に作成されます。無効なエントリは、/、/foldername/、/foldername/subfolderなどです。

    • セキュリティ・グループ

      このコンテンツ・リポジトリ内のWebCenter Portalアプリケーションに対して一意の名前を入力します。たとえば、MyWebCenterPortalAppなどです。

      名前は、先頭がアルファベットで、その後はアルファベットまたはアンダースコアの任意の組合せである必要があります。文字列は、14文字以下である必要があります。

      この名前は、複数のWebCenter Portalアプリケーションが同じコンテンツ・リポジトリを共有している場合にデータを区別するために使用され、アプリケーション間で一意であることが必要です。また、ドキュメント関連のワークフロー、そのポータル・アプリケーションで作成されたすべてのデータが格納されるセキュリティ・グループおよびセキュリティ・ロールを指定するため、また特定のWebCenter Portalインスタンスに対するユーザー権限およびデフォルト属性をストライプするために使用されます。

  7. コンテンツ・リポジトリの接続の詳細を入力します。

    • RIDCソケット・タイプ

      「ソケット」を選択すると、Content Serverとの接続に、intradocソケットが使用されます。

      クライアントIPアドレスは、Content Serverで許可されたアドレスのリストに追加する必要があります。この場合、クライアントはOracle WebCenter Portalを実行しているマシンです。

    • サーバー・ホスト

      /csへのリクエストで利用可能なすべてのコンテンツ・サーバー・ノードを使用できるように、ここにはロード・バランサのアドレス(wcpinternal.example.com)を入力します。

      ロード・バランサで構成された仮想ホストのIPアドレスとロード・バランサのSelf-IPをContent Serverの着信ソケット接続アドレス・セキュリティ・フィルタに追加する必要があります。

      注意:

      まだ実行していない場合は、WebCenter Content Remote Intradoc Client (RIDC) APIのトラフィックをルーティングする方法を指定するルールを、次のようにロード・バランサに追加します。 

      (LBR)10.110.10.135:6300 -> 10.110.10.23:4444 (WCCHOST1) & 10.110.10.24:4444 (WCCHOST2)

    • サーバー・ポート

      Content Serverがリスニングするポート6300を入力します。

    • 接続タイムアウト(ミリ秒)

      接続タイムアウト・メッセージを発行するまで、Content Serverへのログインを許可する時間の長さ(ミリ秒)を指定します。タイムアウトが設定されていない場合、ログイン操作の時間制限はありません。環境に応じた適切なタイムアウトを選択します。たとえば、60000などです。

    • 認証方式

      「アイデンティティ伝播」を選択します。このエンタープライズ・デプロイメントでは、Content ServerとWebCenter Portalアプリケーションは、ユーザーの認証に同じアイデンティティ・ストアを使用します。

    • Webコンテキスト・ルート

      Content ServerのWebサーバー・コンテキスト・ルートとして/csを入力します。

    • 管理者ユーザー名

      このOracle Content Serverインスタンスに対する管理者権限を持つユーザー名を入力します。このユーザーは、プロファイルに基づくコンテンツ・タイプ情報のフェッチおよびWebCenter Portalキャッシュ無効化のためのドキュメント変更の追跡に使用されます。デフォルト値sysadminをそのまま使用できます。

    • 管理者のパスワード

      空のままにします。「管理者のパスワード」の値は、socketTypeをwebに設定した場合のみ必要です。

  8. 「OK」をクリックして、この接続を保存します。
  9. Portal_Cluster内のすべてのサーバーを再起動します。

    注意:

    追加のサービスを構成する場合は、ポータルの再起動を項の最後に1回だけ行うことができます。
高可用性のためのWebCenter Portal Content Manager MBeanの構成

WebCenter Portal Content Managerのコンポーネントおよびタスク・フローでは、WebCenter ContentリモートUI (RUI) APIを使用してコンテンツ統合機能を提供します。これらのライブラリはPortalのインストールに直接組み込まれる一方で、特定のMBean構成設定を高可用性アーキテクチャ内のフェイルセーフ・ランタイム用に変更する必要があります。

WebCenterアプリケーションのADFConfig:WccAdfConfigurationおよびADFConfig:ADFcConfigアプリケーション定義MBeanについて、次の属性を変更して検証します。

  • Application: webcenter:

    • ADFConfig: ADFcConfig

      • AdfScopeHaSupport

    • ADFConfig:WccAdfConfiguration:

      • ClusterCompatible

      • TemporayDirectory

高可用性環境でポータルがクラスタ化される場合、指定されたアップロード一時ディレクトリを全ポータル・ノードの共有ディスク・ボリューム上にある共通のディレクトリ場所に構成する必要があります。

  1. ORACLE_RUNTIME共有ボリュームに、Portal Content Managerのコンポーネント・アップロード場所固有のフォルダを作成します。
    mkdir -p ORACLE_RUNTIME/DOMAIN_NAME/Portal_Cluster/wccAdfUpload

    たとえば、次のようにします。

    mkdir -p /u01/oracle/runtime/wcedg/Portal_Cluster/wccAdfUpload
  2. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。例: weblogic_wcp
  3. 「WebLogicドメイン」メニューから「システムMBeanブラウザ」を選択します。
  4. 「システムMBeanブラウザ」ナビゲーション・メニューで、緑色の検索フィルタ・アイコンをクリックして、次のMBeanを検索します。
    oracle.adf.share.config:ApplicationName=webcenter,Location=WC_Portal1,name=WccAdfConfiguration,type=ADFConfig,Application=webcenter,ADFConfig=ADFConfig

    注意:

    最初のPortal管理対象サーバー名がWC_Portal1でない場合は、Locationの値を更新してください。
  5. ClusterCompatible属性の値がtrueであることを確認します。
  6. 「一時ディレクトリ」属性を前述の共有ストレージで作成したディレクトリに設定します。

    「一時ディレクトリ」属性には、WCPHOST1とWCPHOST2の両方がこのディレクトリ下に格納されたアップロード・ファイルにアクセスできるように、ディレクトリを設定する必要があります。

    たとえば、次のようにします。

    /u01/oracle/runtime/wcedg/Portal_Cluster/wccAdfUpload
  7. 「適用」をクリックします。
  8. 次の確認メッセージを待機します。
    Attributes "TemporaryDirectory" have been updated successfully.
  9. 「システムMBeanブラウザ」ナビゲーション・メニューで、緑色の検索フィルタ・アイコンをクリックして、次のMBeanを検索します。

    注意:

    最初のPortal管理対象サーバー名がWC_Portal1でない場合は、Locationの値を更新してください。 
    oracle.adf.share.config:ApplicationName=webcenter,Location=WC_Portal1,name=ADFcConfiguration,type=ADFConfig,Application=webcenter,ADFConfig=ADFConfig
  10. AdfScopeHASupport属性の値がtrueに設定されていることを確認し、必要に応じて更新します。
  11. 値を更新した場合は、「適用」をクリックして、ページ上部に確認メッセージが表示されることを確認します。
  12. 「システムMBeanブラウザ」ナビゲーション・メニューで、緑色の検索フィルタ・アイコンをクリックして、次のMBeanを検索します。

    注意:

    最初のPortal管理対象サーバー名がWC_Portal1でない場合は、Locationの値を更新してください。 
    oracle.adf.share.config:ApplicationName=webcenter,Location=WC_Portal1,name=ADFConfig,type=ADFConfig,Application=webcenter
  13. 「操作」タブをクリックします。
  14. 「操作」タブ・ビューの「名前」列の「保存」リンクをクリックします。
  15. 「操作: 保存」ページで、「起動」をクリックして、前回の保存操作以降に行われたすべてのMBeanの変更をコミットします。
  16. ページ上部に確認メッセージが表示されることを確認し、「戻り」をクリックします。
  17. 前のステップで、MBean構成の場所に使用されているポータル・サーバーを再起動します。MBeanの変更を正しく反映するには、このサーバーを最初に再起動する必要があります。
    たとえば、前述のMBean検索の例を基準とした場合は、WC_Portal1を再起動します。
  18. Portal_Cluster内のすべての管理対象サーバーを再起動します。

    注意:

    追加のサービスを構成する場合は、残りのポータルの再起動をこの項の最後に行うことができます。MBeanに前述の変更を加えたら、保存したMBeanの属性設定が一貫して適用されるように、WC_Portal1サーバーを最初に再起動する必要があります。

サービス構成のすべての変更をアクティブ化するためのPortal管理対象サーバーの再起動

前述の項でオプションの再起動を延期した場合は、ここでPortal管理対象サーバーを再起動します。

WLSTを使用してPortal_Clusterを停止および起動する手順は、次のとおりです。
  1. 次のWebLogic Scripting Toolを起動します。
    ORACLE_HOME/oracle_common/common/bin/wlst.sh
  2. 管理サーバーに接続します。

    次に例を示します。

    connect('weblogic_wcp','admin password','t3://ADMINVHN:7001")
  3. Portal_Clusterを停止し、終了するまで待機します。
    shutdown('Portal_Cluster', 'Cluster', force='true', block='true')
  4. Portal_Clusterを起動して、RUNNING状態になるまで待機します。
    start('Portal_Cluster', 'Cluster', block='true')
  5. Portal_Clusterが完全に起動したことを確認します。
    state('Portal_Cluster', 'Cluster')
  6. WLSTセッションを終了します。
    exit()

親トピック: 外部サービス用のWebCenter Portalの構成

構成のバックアップ

ベスト・プラクティスとして、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。ここまでのインストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

親トピック: Oracle WebCenter Portalを含めるドメインの拡張