Oracle® Fusion Middleware

WebCenter Sitesインストレーション・ガイド

11gリリース1 (11.1.1.8.0)

E49672-02(原本部品番号:E29632-03)

2014年2月

Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド, 11g リリース1 (11.1.1.8.0)

E49672-02

Copyright © 2011, 2014, Oracle and/or its affiliates. All rights reserved.

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

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

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

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および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の登録商標です。

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

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- このガイドのグラフィック

- 表記規則

このガイドで説明する新機能

第I部 Oracle WebCenter Sitesのインストール

1 WebCenter Sitesのインストール・プロセスの概要

- 1.1 インストールのクイック・リファレンス

- 1.2 次のステップ

2 WebCenter Sitesをインストールするための前提条件

- 2.1 始める前に

- 2.2 次のステップ

3 Oracle WebLogic Application ServerにWebCenter Sitesをインストールするための準備

- 3.1 WebLogic Application Serverのセットアップのクイック・リファレンス

- 3.1.1 手順の概要

- 3.1.2 この章で使用されるパスとディレクトリ

- 3.1.3 WebLogic Serverの起動/停止コマンド

- 3.2 ステップ1: WebLogic Application Serverの構成

- 3.2.1 WebLogicドメインの作成

- 3.2.2 WebLogicドメインの構成

- 3.2.2.1 マシンの作成

- 3.2.2.2 クラスタの作成と構成

- 3.2.2.3 管理対象サーバーの作成と構成

- 3.2.2.4 データ・ソースの作成と構成

- 3.2.2.5 Javaオプションの設定

- 3.2.2.6 クラスパスの設定

- 3.2.2.7 リモート管理対象サーバーの転送

- 3.3 ステップ2: Oracle WebLogic ServerとサポートされているWebサーバーとの統合

- 3.3.1 Oracle HTTP Serverの構成

- 3.3.2 Apache HTTPサーバーの構成

- 3.3.3 IIS Webサーバーの構成

4 Apache Tomcat Application ServerにWebCenter Sitesをインストールするための準備

- 4.1 Tomcat Application Serverのセットアップのクイック・リファレンス

- 4.1.1 手順の概要

- 4.1.2 この章で使用されるパスとディレクトリ

- 4.1.3 Tomcatの起動/停止コマンド

- 4.2 ステップ1: Tomcat Application Serverの構成

- 4.2.1 Tomcat Serverポートの変更

- 4.2.2 データ・ソースの作成と構成

- 4.2.3 Javaオプションの設定

- 4.2.4 クラスパスの設定

- 4.2.5 URIエンコーディングの構成

- 4.2.6 ロード・バランシングのためのTomcatサーバーの構成

- 4.2.7 クラスタリングのためのTomcatサーバーの構成

- 4.2.8 SSLのためのTomcatサーバーの構成

- 4.3 ステップ2: Tomcat Application ServerとサポートされているWebサーバーとの統合

- 4.3.1 Apache HTTPサーバーの構成

5 IBM WebSphere Application ServerにWebCenter Sitesをインストールするための準備

- 5.1 WebSphere Application Serverのセットアップのクイック・リファレンス

- 5.1.1 手順の概要

- 5.1.2 WebSphere Application Serverの構成で使用されるパスとディレクトリ

- 5.1.3 WebSphere Application Serverの起動/停止コマンド

- 5.1.3.1 デプロイメント・マネージャ

- 5.1.3.2 ノード・エージェント

- 5.1.3.3 アプリケーション・サーバー

- 5.2 ステップ1: WebSphere Application Serverの構成

- 5.2.1 必要なプロファイルの作成

- 5.2.2 クラスタの作成

- 5.2.3 サーバーの作成

- 5.2.4 サーバーの構成

- 5.2.4.1 Webコンテナ・プロパティの構成

- 5.2.4.2 セッション管理の構成

- 5.2.4.3 クラスパスとJavaオプションの設定

- 5.2.5 仮想ホストのホスト別名の作成

- 5.2.6 データベース通信のためのWAS環境の構成

- 5.2.6.1 J2C認証データの作成

- 5.2.6.2 JDBCプロバイダの作成

- 5.2.6.3 データ・ソースの作成

- 5.3 ステップ2: WebSphere Application ServerとサポートされているWebサーバーとの統合

6 WebCenter Sitesのインストール手順

- 6.1 WebCenter Sitesのインストール・プロセスの概要

- 6.2 インストール・オプション

- 6.3 WebCenter Sitesアプリケーションのインストール

- 6.3.1 GUIインストーラの実行

- 6.3.2 サイレント・インストール

- 6.4 中間点での構成変更

- 6.4.1 CASファイルのコピー

- 6.4.2 CASファイルの変更

- 6.4.3 Webアプリケーション・ファイルの変更

- 6.5 WebCenter SitesおよびCAS Webアプリケーションのデプロイ

- 6.5.1 WebLogic ServerへのWebCenter SitesおよびCASのデプロイ

- 6.5.1.1 WebLogic Scripting Toolを使用したデプロイ

- 6.5.1.2 WebLogic管理コンソールからのデプロイ

- 6.5.2 WebSphereへのWebCenter SitesおよびCASのデプロイ

- 6.5.3 TomcatへのWebCenter SitesおよびCASのデプロイ

- 6.6 WebCenter Sitesの再起動

- 6.7 WebLogic Application Serverの本番モードへの切替え(配信システムのみ)

7 WebCenter Sitesのインストール後の手順

- 7.1 XMLパーサーのロード

- 7.2 CASに対する信頼できるURLの指定

- 7.3 WebCenter Sitesのインストールの検証

- 7.4 LDAPとの統合(オプション)

- 7.5 Oracle Access Manager (OAM)とWebCenter Sitesとの統合(オプション)

- 7.6 Satellite Serverのインストール

- 7.7 ビジネス上の目的に合わせたWebCenter Sitesのセットアップ

第II部 Oracle WebCenter Sites: Satellite Serverのインストール

8 Satellite Serverの概要

- 8.1 共存

- 8.2 リモート

9 リモートSatellite Serverのインストール手順

- 9.1 ステップ1: 必須ハードウェアおよびソフトウェアのインストール

- 9.1.1 ネットワークに関する考慮事項

- 9.1.2 ロード・バランサの要件

- 9.1.3 構成要件

- 9.1.4 アプリケーション・サーバーの要件

- 9.1.5 Satellite Serverのコンテンツ

- 9.2 ステップ2: インストール・ファイルの展開

- 9.3 ステップ3: Satellite Serverのインストール

- 9.3.1 GUIインストーラを使用したSatellite Serverのインストール

- 9.3.2 Satellite Serverのサイレント・インストール

- 9.4 ステップ4: WebCenter SitesへのSatellite Serverの登録

- 9.5 ステップ5: CASに対する信頼できるURLの指定

- 9.6 ステップ6: Satellite Serverの起動

- 9.7 ステップ7: 構成のテスト

- 9.8 ステップ8: 追加のリモート・サーバーでのSatellite Serverのインストール

- 9.9 次のステップ

10 Satellite Serverのインストール後の手順

- 10.1 キャッシュ条件の調整

- 10.2 ログ構成

第III部 Oracle WebCenter Sitesの国際化

11 複数言語操作用の環境の構成

- 11.1 WebCenter Sites固有の設定

- 11.1.1 cs.contenttypeプロパティ

- 11.1.2 cs.contenttype変数(SiteCatalog resargs1で設定)

- 11.1.3 フォームの_charset_ hidden変数

- 11.1.4 望ましいエンコーディング

- 11.1.5 XMLまたはJSPエレメントで指定されるエンコーディング

- 11.1.6 SetVarタグの使用

- 11.1.7 HTTP METAタグの使用

- 11.2 Internet Explorerの設定

- 11.3 国際化のための追加の指定

- 11.3.1 ファイル・システムに格納されているファイル

- 11.3.1.1 XMLおよびJSPファイル

- 11.3.1.2 HTMLファイル

- 11.3.1.3 SystemSQL問合せ

- 11.3.1.4 SystemPageCache表から参照されるページ・キャッシュ・ファイル

- 11.3.2 属性エディタ

- 11.3.2.1 記事本文、フレックス・アセット、ユーザー定義アセット

- 11.3.3 XMLポスト

- 11.3.4 Catalog Mover

- 11.3.5 Sites Explorer

- 11.3.6 サイト・デスクトップとサイトDocLink

- 11.3.7 WebCenter Sitesインタフェース

- 11.3.7.1 単一言語の制限

- 11.3.8 機能の制限

第IV部 Oracle WebCenter Sites: コミュニティ-ガジェットのインストール

12 コミュニティ-ガジェットの概要

- 12.1 コミュニティ-ガジェットについて

- 12.1.1 WebCenter Sitesのコンポーネントを使用するコミュニティ-ガジェット

- 12.1.2 コミュニティ-ガジェットの管理および本番コンポーネント

- 12.2 本番および管理環境

- 12.2.1 WebCenter Sitesの通信

- 12.2.2 コミュニティ-ガジェットとWebCenter Sitesとの通信

- 12.3 コミュニティ-ガジェットの構成

- 12.3.1 基本構成

- 12.3.2 本番構成

13 コミュニティ-ガジェットをインストールするための前提条件

- 13.1 コミュニティ-ガジェットをインストールする前に

- 13.1.1 すべてのインストールの前提条件

- 13.1.2 クラスタ化された環境の場合の前提条件

- 13.1.3 LDAP構成の場合の前提条件

- 13.2 パスおよびディレクトリのネーミング規則

14 コミュニティ-ガジェットに対するアプリケーション・サーバーの構成

- 14.1 コミュニティ-ガジェットのデプロイメントの概要

- 14.2 クラスタ化されていないデプロイメント用のアプリケーション・サーバーの構成

- 14.2.1 Apache Tomcatの構成

- 14.2.2 Oracle WebLogic Application Serverの構成

- 14.2.3 IBM WebSphere Application Serverの構成

- 14.3 クラスタ化されたデプロイメント用のアプリケーション・サーバーの構成

- 14.3.1 Apache Tomcatの構成(クラスタ化されている)

- 14.3.2 Oracle WebLogic Application Serverの構成(クラスタ化されている)

- 14.3.3 IBM WebSphere Application Serverの構成(クラスタ化されている)

15 コミュニティ-ガジェット・デプロイメント・ファイルの生成

- 15.1 コミュニティ-ガジェット・デプロイメント・ファイルのグラフィカルな生成

- 15.2 コミュニティ-ガジェット・デプロイメント・ファイルのサイレントな生成

- 15.3 コミュニティ-ガジェット・インストール・ディレクトリ構造の検証

16 コミュニティ-ガジェットのデプロイメント前の手順の完了

- 16.1 inCacheの無効化の構成

- 16.2 インストーラによって生成された構成ファイルのコピー

- 16.3 プロキシ接続設定

- 16.4 コミュニティ-ガジェットのURLのWebCenter SitesのcustomBeans.xmlファイルへの追加

- 16.5 Shindigの機能の有効化

- 16.6 管理または本番、あるいはその両方のWebCenter SitesがOAMと統合されている場合

17 コミュニティ-ガジェットのデプロイ

- 17.1 概要

- 17.2 クラスタ化されていないコミュニティ-ガジェット・アプリケーションのデプロイ

- 17.2.1 Apache Tomcatへのデプロイ

- 17.2.2 Oracle WebLogic Application Serverへのデプロイ

- 17.2.3 IBM WebSphere Application Serverへのデプロイ

- 17.3 クラスタ化されたコミュニティ-ガジェット・アプリケーションのデプロイ

- 17.3.1 Apache Tomcatへのデプロイ(クラスタ化されている)

- 17.3.2 Oracle WebLogic Application Serverへのデプロイ(クラスタ化されている)

- 17.3.3 IBM WebSphere Application Serverへのデプロイ(クラスタ化されている)

18 コミュニティ-ガジェットの検証と実装

- 18.1 コミュニティ-ガジェットのURLの検証

- 18.2 コミュニティ-ガジェット・アプリケーションの登録

- 18.3 ユーザーがコミュニティおよびガジェット・インタフェースにアクセスすることを認可

- 18.4 WebCenter Sitesコントリビュータ・インタフェースへのコミュニティ-ガジェットの統合

19 サンプル・ガジェットの追加

- 19.1 サンプル・ガジェットをインストールするための前提条件

- 19.2 サンプル・ガジェットのインストール

第V部 Community Blogsモジュールのインストール

20 Community Blogsモジュールのインストール手順

- 20.1 Community Blogsモジュールの概要

- 20.2 Community Blogsモジュールのインストール中のWebCenter Sitesに対する変更

- 20.3 Community Blogsモジュールをインストールするための前提条件

- 20.4 WebCenter SitesへのCommunity Blogsモジュールのインストール

- 20.5 インストールの検証

第VI部 Oracle WebCenter Sites: サイト・キャプチャのインストール

21 WebCenter Sites: サイト・キャプチャの概要

- 21.1 WebCenter Sites: サイト・キャプチャについて

- 21.2 サイト・キャプチャのインストールの概要

- 21.3 始める前に

- 21.4 次のステップ

22 サイト・キャプチャ・アプリケーション・サーバーの構成

- 22.1 構成オプション

- 22.2 Tomcat Application Serverの構成

- 22.3 WebLogic Application Serverの構成

- 22.4 WebSphere Application Serverの構成

23 サイト・キャプチャのインストール手順

- 23.1 インストール手順

- 23.1.1 サイレント・インストーラの実行

- 23.1.2 GUIインストーラの実行

- 23.1.3 サイト・キャプチャのデプロイ

- 23.1.3.1 Tomcat Application Serverへのデプロイ

- 23.1.3.2 WebLogic Application Serverへのデプロイ

- 23.1.3.3 WebSphere Application Serverへのデプロイ

- 23.2 インストール後の手順

- 23.2.1 サイト・キャプチャがOracle Databaseを使用している場合

- 23.2.2 customBeans.xmlファイルへのサイト・キャプチャURLの追加

- 23.2.3 サイト・キャプチャ・アプリケーションの検証

- 23.2.4 サイト・キャプチャを操作するユーザーの認可

- 23.3 次のステップ

24 パブリッシュによってトリガーされるサイト・キャプチャの有効化

- 24.1 サイト・キャプチャとOracle WebCenter Sitesのパブリッシュ・プロセスとの統合

- 24.2 次のステップ

第VII部 Oracle WebCenter Sites: Analyticsのインストール

25 Analyticsアーキテクチャの概要

- 25.1 Analyticsインストールのコンポーネント

- 25.2 インストールのシナリオ

- 25.2.1 単一サーバーのインストール: 単一サーバー上にAnalyticsとそのデータベース

- 25.2.2 デュアルサーバーのインストール: 別々のサーバー上にAnalyticsとそのデータベース

- 25.2.3 エンタープライズレベルのインストール: 完全に分散

- 25.3 プロセス・フロー

- 25.4 用語と定義

26 Analyticsをインストールするための前提条件

- 26.1 インストール前のチェックリスト

- 26.1.1 必要な経験

- 26.1.2 システム・アーキテクチャ

- 26.1.3 WebCenter Sites: Analyticsキット

- 26.1.4 Hadoopのインストール

- 26.1.5 WebCenter Sitesおよびサポート・ドキュメント

- 26.1.6 WebCenter Sites: Analyticsサイレント・インストーラ

- 26.1.7 WebCenter Sites: Analyticsサポート・ソフトウェア

- 26.1.7.1 データベース

- 26.1.7.2 アプリケーション・サーバー

- 26.1.7.2.1 すべてのアプリケーション・サーバー

- 26.1.7.2.2 JBoss Application Server

- 26.1.7.2.3 WebLogic Application Server

- 26.1.7.2.4 WebSphereを使用している場合

- 26.1.8 環境変数

- 26.1.9 チャートのサポート

- 26.2 次のステップ

27 Analyticsのインストール手順

- 27.1 Analyticsサイレント・インストーラの概要

- 27.1.1 インストールの概要

- 27.1.2 サイレント・インストーラのアクション

- 27.2 インストール手順

- 27.2.1 ステップ1. Analyticsを解凍する

- 27.2.2 ステップ2. Analytics用にanalytics-build.propertiesをカスタマイズする

- 27.2.2.1 全般的なインストール・プロパティ

- 27.2.2.2 ビジター検出プロパティ

- 27.2.2.3 システム構成および処理のデフォルト

- 27.2.2.4 WebサーバーURLプロパティ

- 27.2.2.5 アプリケーション・サーバー・デプロイメント・プロパティ

- 27.2.2.6 データベース接続プロパティ

- 27.2.2.7 Hadoopプロパティ

- 27.2.3 ステップ3. サイレント・インストーラの実行を準備する

- 27.2.4 ステップ4. Analyticsをインストールする

- 27.2.4.1 単一サーバーのAnalyticsのインストール

- 27.2.4.2 デュアル・サーバーのAnalyticsのインストール

- 27.2.4.3 分散Analyticsインストール

- 27.2.5 ステップ5. Analyticsを有効化するようにWebCenter Sitesを構成する

- 27.3 次のステップ

28 Analytics構成パラメータの調整

- 28.1 構成ファイルの概要

- 28.2 global.xml

- 28.2.1 <params> </params>内のパラメータ

- 28.2.1.1 データベース接続パラメータ

- 28.2.2 LFSログライター実装パラメータ

- 28.3 log4j.properties

- 28.3.1 Hadoopジョブ・スケジューラに対するロギングの設定

- 28.4 futuretense_xcel.ini

29 ビジター検出の構成

- 29.1 概要

- 29.2 メソッド

- 29.2.1 自己構成ビジター・トラッキング

- 29.2.2 Sessionfingerprintメソッド

- 29.2.3 Cookieメソッド

30 Analyticsインストールの検証

- 30.1 検証手順

- 30.2 推奨構成

- 30.2.1 インストーラ・ファイル

- 30.2.2 センサーの過負荷アラート

- 30.2.2.1 過負荷アラートのしきい値の設定

- 30.2.2.2 赤状態への対処

- 30.2.3 Geolocationデータベース

- 30.3 次のステップ

第VIII部 Oracle WebCenter Sites: Content Integration Platformのインストール

31 ファイル・システムおよびMicrosoft SharePointに対するContent Integration Platformのインストール

- 31.1 インストールの概要

- 31.1.1 前提条件

- 31.1.2 パッケージ化

- 31.1.3 ファイルのインストール先

- 31.2 Content Integration Platformのインストール

- 31.2.1 ステップ1: Content Integration Agentをインストールする

- 31.2.2 ステップ2: Sites Agent Servicesをインストールする

- 31.2.3 ステップ3: WebCenter Sitesにスキーマをインストールする

- 31.2.4 ステップ4: (オプション)イベント通知の構成

- 31.3 インストールの検証

- 31.4 本番データのパブリッシュ

- 31.5 CIPインストールのカスタマイズ

32 Content Integration Platform for EMC Documentumのインストール

- 32.1 インストールの概要

- 32.2 前提条件

- 32.3 パッケージ化

- 32.4 インストール手順

- 32.4.1 ステップ1: Content Integration Agentをインストールする

- 32.4.2 ステップ2. CIPパブリッシュ・コンポーネントをインストールする

- 32.4.2.1 A. Sites Agent Servicesをインストールする

- 32.4.2.2 B. Oracle WebCenter SitesにEMC Documentumスキーマをインストールする

- 32.4.3 ステップ3. Documentumへのアーカイブをサポートするスキーマをインストールする

- 32.4.4 ステップ4. デフォルトmappings.xmlファイルをバックアップする

- 32.5 次のステップ

第IX部 リファレンス: バックアップとリカバリ

33 バックアップとリカバリ

- 33.1 バックアップとリカバリの前提条件

- 33.2 バックアップとリカバリの手順

- 33.2.1 WebCenter Sitesインストール・ディレクトリ

- 33.2.1.1 バックアップ

- 33.2.1.2 リカバリ

- 33.2.2 共有ディレクトリ

- 33.2.2.1 バックアップ

- 33.2.2.2 リカバリ

- 33.2.3 Webアプリケーションの.warおよび.earファイル

- 33.2.3.1 バックアップ

- 33.2.3.1.1 展開されていないファイルのバックアップ

- 33.2.3.1.2 デプロイメントの変更がない、展開されたファイルのバックアップ

- 33.2.3.1.3 デプロイメントの変更がある、展開されたファイルのバックアップ

- 33.2.3.2 リカバリ

- 33.2.3.2.1 展開されていないファイルのリカバリ

- 33.2.3.2.2 デプロイメントの変更がない、展開されたファイルのリカバリ

- 33.2.3.2.3 デプロイメントの変更がある、展開されたファイルのリカバリ

- 33.2.4 WebCenter Sitesのデータベース

- 33.2.4.1 バックアップ

- 33.2.4.1.1 SQL Server 2008および2008R2のバックアップ

- 33.2.4.1.2 Oracle 11gのバックアップ

- 33.2.4.1.3 DB2 9.7のバックアップ

- 33.2.4.2 リカバリ

- 33.2.4.2.1 SQL Server 2008および2008R2のリカバリ

- 33.2.4.2.2 Oracle 11gのリカバリ

- 33.2.4.2.3 DB2 V9.7のリカバリ

- 33.2.5 LDAP

- 33.2.5.1 バックアップ

- 33.2.5.2 リカバリ

- 33.3 リカバリ済WebCenter Sitesアプリケーションの実行

Oracle WebCenter Sites: Analyticsアプリケーションの用語集

はじめに

このガイドには、Oracle WebCenter Sites、Satellite Server、コミュニティ-ガジェット、Community Blogsモジュール、サイト・キャプチャ、AnalyticsおよびContent Integration Platformのインストールに関する情報が記載されています。また、多言語操作のための環境の構成、WebCenter Sitesのバックアップおよびリカバリの手順も記載されています。

対象読者

このガイドは、データベース、データベース・ドライバ、アプリケーション・サーバー、Webサーバー、LDAPサーバーなどエンタープライズレベルのソフトウェアのインストールおよび構成の経験があるインストール・エンジニアを対象にしています。

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

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、現在のリリースの次のドキュメントを参照してください。

- Oracle WebCenter Sites動作保証マトリックス

- Oracle WebCenter Sitesリリース・ノート

- 『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』

- 『Oracle Fusion Middleware WebCenter Sites管理者ガイド』

- 『Oracle Fusion Middleware WebCenter Sites開発者ガイド』

このガイドのグラフィック

このガイドのグラフィックは、インストールまたは構成プロセスで相互作用するものに類似したダイアログ・ボックスおよびウィンドウのスクリーン・キャプチャです。それらのグラフィックは、インストールおよび構成のプロセスに従うために役立つよう記載しています。それらは、パラメータ値、選択するオプション、製品バージョン番号などの情報の提供を意図するものではありません。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interfaceエレメント、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

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

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』には、以前は複数のブックに分かれていたインストレーション・ドキュメントが統合されています。このガイドでは、Oracle WebLogic、Apache TomcatおよびIBM WebSphere Application ServerへのOracle WebCenter Sitesのインストールおよび構成について説明します。他のWebCenter Sitesアプリケーションをインストールするための詳細な手順も説明します。さらに、複数言語操作用の環境の構成および環境のバックアップとリカバリについても説明します。このブックには、次の部が含まれています。

- 第I部「Oracle WebCenter Sitesのインストール」

- 第II部「Oracle WebCenter Sites: Satellite Serverのインストール」

- 第III部「Oracle WebCenter Sitesの国際化」

- 第IV部「Oracle WebCenter Sites: コミュニティ-ガジェットのインストール」

- 第V部「Community Blogsモジュールのインストール」

- 第VI部「Oracle WebCenter Sites: サイト・キャプチャのインストール」

- 第VII部「Oracle WebCenter Sites: Analyticsのインストール」

- 第VIII部「Oracle WebCenter Sites: Content Integration Platformのインストール」

- 第IX部「リファレンス: バックアップとリカバリ」

第1部

Oracle WebCenter Sitesのインストール

第I部は、次の章で構成されています。

- 第1章「WebCenter Sitesのインストール・プロセスの概要」

- 第2章「WebCenter Sitesをインストールするための前提条件」

- 第3章「Oracle WebLogic Application ServerにWebCenter Sitesをインストールするための準備」

- 第4章「Apache Tomcat Application ServerにWebCenter Sitesをインストールするための準備」

- 第5章「IBM WebSphere Application ServerにWebCenter Sitesをインストールするための準備」

- 第6章「WebCenter Sitesのインストール手順」

- 第7章「WebCenter Sitesのインストール後の手順」

1 WebCenter Sitesのインストール・プロセスの概要

この章では、スタンドアロンおよびクラスタ環境においてアプリケーション・サーバー(Oracle WebLogic Server、Apache TomcatおよびIBM WebSphere)にWebCenter Sitesをインストールする準備に役立つ情報を提供します。

サポートされている環境は、次のとおりです。

- 単一サーバー環境: 単一のWebCenter Sitesインストールで構成されている環境。フロントエンドWebサーバーがある場合もない場合もあります。

- 複数のサーバーでロード・バランスされている環境: 複数のWebCenter Sitesインストールで構成され、それらが同じデータベースおよび共有ディレクトリを共有し、1つのフロントエンド・ロード・バランサを使用する環境。WebCenter Sitesアプリケーションがデプロイされているアプリケーション・サーバーは、スタンドアロン・サーバーであり、クラスタに属していません。

- 複数サーバーのクラスタ環境: 複数のWebCenter Sitesインストールで構成され、それらが同じデータベースおよび共有ディレクトリを共有し、1つのフロントエンド・ロード・バランサを使用する環境。WebCenter Sitesアプリケーションがデプロイされているアプリケーション・サーバーは、同じクラスタに属しています。クラスタは、セッション永続性をサポートするように構成されている場合があります。この環境では、水平クラスタリングのみがサポートされています。

このガイドでは、次のトピックは取り上げません。それらは範囲外です。

- LDAP統合。概要は、第7.4項「LDAPとの統合(オプション)」に記載されています。このトピックの詳細は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。

- Oracle Access Manager (OAM)とWebCenter Sitesとの統合。このトピックの詳細は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。

この章の内容は、次のとおりです。

- 第1.1項「インストールのクイック・リファレンス」

- 第1.2項「次のステップ」

1.1 インストールのクイック・リファレンス

WebCenter Sitesをインストールする前に、そのサポート・ソフトウェアを、WebCenter Sitesを使用する予定の開発、コンテンツ管理および配信の各システムにインストールして構成します。各デプロイメント、コンテンツ管理および配信システムの各サーバーに対してWebCenter Sitesインストーラを一度ずつ実行します。開発およびコンテンツ管理に対するインストール・プロセス中に、サンプル・サイトおよびサンプル・コンテンツをインストールするかどうかを選択できます。インストール・プロセスが終了したら、インストール後の手順を完了して、WebCenter Sitesシステムを検証し、必要に応じてOAMやLDAPなど追加のサポートを構成します。

次の手順は、WebCenter Sitesのサポート・ソフトウェアの構成、WebCenter Sitesのインストール、その機能の検証、およびインストール後の手順の完了といったインストール・プロセスの概要を示しています。次の手順を、インストール手順およびその詳しい説明を記載した章のクイック・リファレンスとしてお手元に保持してください。

次の手順を、すべてのデプロイメントに対して完了します。

1. 前提となる手順の完了
この手順では、サポートされているデータベースのセットアップ、サポートされているアプリケーション・サーバーのインストール、必要に応じてサポートされているWebサーバーのインストールも含まれるいくつかの手順を完了することで、インストール・プロセス用に環境を整えます。詳細は、第2章「WebCenter Sitesをインストールするための前提条件」を参照してください。

2. アプリケーション・サーバーのセットアップ
この手順では、次のことを実行します。

1. 使用しているアプリケーション・サーバーに応じて次の項の1つの説明に従い、アプリケーション・サーバーを構成します。

- 第3.2項「ステップ1: WebLogic Application Serverの構成」

- 第4.2項「ステップ1: Tomcat Application Serverの構成」

- 第5.2項「ステップ1: WebSphere Application Serverの構成」

2. Webサーバーをインストールした場合は、それを次のようにアプリケーション・サーバーと統合します。

- 第3.3項「ステップ2: Oracle WebLogic ServerとサポートされているWebサーバーとの統合」

- 第4.3項「ステップ2: Tomcat Application ServerとサポートされているWebサーバーとの統合」

- 第5.3項「ステップ2: WebSphere Application ServerとサポートされているWebサーバーとの統合」

3. WebCenter Sitesのインストール
環境内の構成されたアプリケーション・サーバーごとに、GUIインストーラまたはサイレント・インストーラを実行することでWebCenter Sitesをインストールします。手順は、第6章「WebCenter Sitesのインストール手順」を参照してください。

インストール中に、いくつかのインストール・アクションを実行するようにインストーラから要求されます。その場合、WebCenter Sites Webアプリケーションを(WebLogicおよびWebSphere上に)手動でデプロイし、残りの手順に従ってインストールを完了する必要があります。(手順は、第6.5項「WebCenter SitesおよびCAS Webアプリケーションのデプロイ」に記載されています。)

4. インストール後の手順の完了
ご使用のシステムに適した手順を完了します。完全な手順については第7章「WebCenter Sitesのインストール後の手順」を、概要については次のリストを参照してください。

1. WebCenter Sitesには、Microsoft XML Parserの修正済バージョンが含まれています(WEB-INF/libディレクトリのMSXML.jar)。WebCenter Sites CLASSPATH環境変数で、異なるバージョンのMicrosoft XML Parserが参照されている場合は、WebCenter Sitesによって使用されるバージョンを参照するようにそのパスを変更する必要があります。そのようにしない場合は、解析時にWebCenter Sitesが失敗します。詳細は、第7.1項「XMLパーサーのロード」を参照してください。

2. CASリダイレクトのための信頼できるURLを追加する場合は、第7.2項「CASに対する信頼できるURLの指定」を参照してください。

3. 一般管理者としてOracle WebCenter Sitesにログインし、WebCenter Sites管理インタフェースおよびコントリビュータ・インタフェースにアクセスすることで、WebCenter Sitesインストールを検証します。詳細は、第7.3項「WebCenter Sitesのインストールの検証」を参照してください。

4. LDAP統合を実行する必要がある場合は、第7.4項「LDAPとの統合(オプション)」の手順を完了します。

5. CASをOracle Access Manager (OAM)に置き換える場合は、第7.5項「Oracle Access Manager (OAM)とWebCenter Sitesとの統合(オプション)」の説明に従ってください。

5. リモートSatellite Serverを、第9章「リモートSatellite Serverのインストール手順」の説明に従ってインストールします。

6. ビジネス上の目的に合わせたWebCenter Sitesのセットアップ
インストール全体が完了し、検証したら、WebCenter Sitesをそのビジネス上の目的に合わせてセットアップします。詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』および『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。

1.2 次のステップ

第2項「WebCenter Sitesをインストールするための前提条件」に続きます。

2 WebCenter Sitesをインストールするための前提条件

この章の内容は、次のとおりです。

- 第2.1項「始める前に」

- 第2.2項「次のステップ」

2.1 始める前に

- WebCenter Sitesのインストールに関する各種情報は、次のドキュメントを参照してください。

- WebCenter Sitesをインストールするプラットフォームを選択するには、Oracle WebCenter Sites動作保証マトリックスを参照してください。このガイドの説明に従って、プラットフォームのコンポーネントをインストールおよび構成します。
このガイドでは、サード・パーティ製品の構成に関しては選択した情報のみを記載しています。詳細および最新のe-fix、パッチ、およびサービス・パックの入手は、サード・パーティ製品のベンダーのドキュメントおよびリリース・ノートを参照してください。

- WebCenter Sitesのインストール・プロセスおよび関連する手順に関する最新の詳細は、Oracle WebCenter Sitesリリース・ノートを参照してください。

- サポートされているデータベース、アプリケーション・サーバー、およびWebサーバーのインストール手順、およびWebCenter Sitesに必要なソフトウェアとの統合手順は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』という名称のガイドを参照してください。

- GUI WebCenter Sitesインストーラを実行する予定である場合は、ご使用のシステムがインストーラGUIを表示する機能を備えているか確認してください。そのインストーラは、テキスト・モードでは機能しません。
WebCenter Sitesは、GUIインストーラを実行しても、サイレントでもインストールおよびデプロイできます。GUIインストーラを実行すると、グラフィカル・インタフェースによってインストール・プロセスの手順が示され、必要に応じて情報を入力し、オプションを選択するように求められます。また、オンライン・ヘルプにアクセスすることもできます。サイレント・インストールを行うには、最初に、GUIインストーラを設定のサマリー画面まで実行してから終了することでomii.iniファイルを生成します。サイレント・インストーラは、このファイルを使用してWebCenter Sitesをインストールします。

環境内のすべてのシステムに対してWebCenter Sitesインストーラを実行します。2つのシステム・タイプがあります。コンテンツ管理または開発(これらのインストール・プロセスは同一です)と配信です。コンテンツ管理システムと開発システムは、同じモードで実行されますが、使用目的は異なります。

注意:

次の注意事項があります。

- システム・タイプは、そのタイプを選択して「次へ」(GUIインストール)をクリックするか、サイレント・インストーラの実行を開始した後は、変更できません。

- インストール・プロセスでは、配信システムに一部のユーザー・インタフェースはインストールされません。配信には、選択機能の管理を有効化した限定されたバージョンのWebCenter Sites管理インタフェースのみがインストールされます。

- ご使用のWebCenter Sites環境内のシステムの名前は、このドキュメントで使用される名前と異なる場合があります。通常、コンテンツ管理システムは「ステージング」とも呼ばれ、配信システムは「本番」とも呼ばれます。

- WebCenter Sitesサイレント・インストーラには、CASのインストールが含まれています。デフォルトでは、CASはプライマリ・サーバーにインストールされます。プライマリ・サーバー以外のサーバーでCASを実行する場合は、CASアプリケーションをデプロイし、途中で(インストーラが一時停止したときに)必須ファイルをコピーします。

- CASのかわりにOAMまたは別のシングルサインオン・プロバイダを使用する予定である場合は、WebCenter SitesをインストールしてCASと連動させます。インストールを検証したら、新しいシングル・サインオン・プロバイダに切り替えます。

- Java Development Kit (JDK)の古いバージョンをCLASSPATHおよびPATH環境変数から削除します。
WebCenter SitesにはJDKが必要です。この製品は、Javaランタイム環境では適切に動作しません。

- WebCenter Sitesのインストール先となるディレクトリを作成します。ディレクトリ名(このガイドでは<sites_install_dir>)およびパスには、空白や非ASCII文字を含めることはできず、アプリケーション・サーバーはディレクトリとの間で読取り/書込み可能であることが必要です。クラスタ環境では、このディレクトリのパスは、すべてのWebCenter Sitesサーバーで同一であることが必要です。

- クラスタ化されたインストールの場合、すべてのクラスタ・メンバーが読み取りおよび書き込みできる共有ファイル・システム・ディレクトリを作成してあることを確認します。このディレクトリ名およびパスには空白を含めることはできません。このディレクトリは、すべてのクラスタ・メンバー・システムで同じパスにマウントされる必要があります。

- WebCenter Sites一時ファイルのディレクトリを作成します。このディレクトリは、各WebCenter Sitesサーバーに一意である必要があります。

- すべてのタイプのインストールで、JDK/binディレクトリをパス変数に追加します。

- サポートされるデータベースをインストールします。
WebCenter Sitesは、WebCenter Sites専用に構成されたデータベースへのアクセスを必要とします。サポートされるデータベース(および他のサード・パーティ・コンポーネント)のリストは、Oracle WebCenter Sites動作保証マトリックスを参照してください。

他のWebCenter Sitesサポート・ソフトウェアをインストールする前に、次の手順を完了します。

1. データベース管理システムをインストールします。
手順は、製品ベンダーのドキュメントを参照してください。

2. WebCenter Sites用のデータベースを作成および構成します。
詳細は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。

データベース構成は、異なるアプリケーション・サーバーにわたって同一であることに注意してください。選択したデータベースを作成および構成するには、適切な章を参照してください。

データベース構成は、異なるクラスタ・サーバーにわたって同一であることに注意してください。

- サポートされているアプリケーション・サーバーを、WebCenter Sitesインストールを含める予定の各サーバーにインストールします。詳細は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。

- ご使用の環境での必要に応じて、サポートされているWebサーバーをインストールします。詳細は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。

2.2 次のステップ

次のステップでは、WebCenter Sitesインストール・プロセス用にアプリケーション・サーバーを準備します。手順は、次の章の1つを参照してください。

- 第3章「Oracle WebLogic Application ServerにWebCenter Sitesをインストールするための準備」

- 第4章「Apache Tomcat Application ServerにWebCenter Sitesをインストールするための準備」

- 第5章「IBM WebSphere Application ServerにWebCenter Sitesをインストールするための準備」

3 Oracle WebLogic Application ServerにWebCenter Sitesをインストールするための準備

この章では、WebCenter Sites WebアプリケーションをサポートするためのWebLogic Serverの構成について説明します。このドキュメントの内容は次のとおりです。

- 第3.1項「WebLogic Application Serverのセットアップのクイック・リファレンス」

- 第3.2項「ステップ1: WebLogic Application Serverの構成」

- 第3.3項「ステップ2: Oracle WebLogic ServerとサポートされているWebサーバーとの統合」

注意:

この章の手順を開始する前に、第2章「WebCenter Sitesをインストールするための前提条件」で説明した前提条件の手順を完了していることを確認してください。

3.1 WebLogic Application Serverのセットアップのクイック・リファレンス

この項の内容は、次のとおりです。

- 第3.1.1項「手順の概要」

- 第3.1.2項「この章で使用されるパスとディレクトリ」

- 第3.1.3項「WebLogic Serverの起動/停止コマンド」

3.1.1 手順の概要

アプリケーション・サーバーをインストール済の開発、コンテンツ管理、および配信の各環境に対して、次の手順を完了します。

ステップ1: WebLogic Application Serverの構成

1. 第3.2.1項「WebLogicドメインの作成」に示すようにWebLogicドメインを作成します。この手順は、管理サーバーが含まれているドメインを作成するために必要です。

2. 第3.2.2項「WebLogicドメインの構成」に示すようにWebLogicドメインを構成します。この手順では、次のようにする必要があります。

1. WebLogicサーバーを実行する物理サーバーごとにマシンを1つ作成します。手順は、第3.2.2.1項「マシンの作成」を参照してください。

2. クラスタ環境を構成している場合は、第3.2.2.2項「クラスタの作成と構成」の説明に従って、クラスタを作成および構成します。

3. 1つ以上のWebLogic管理対象サーバーを作成および構成します。手順は、第3.2.2.3項「管理対象サーバーの作成と構成」を参照してください。

4. 第3.2.2.4項「データ・ソースの作成と構成」の説明に従って、データ・ソースを作成および構成します。

5. 第3.2.2.5項「Javaオプションの設定」の説明に従って、Javaオプションを設定します。

6. 第3.2.2.6項「クラスパスの設定」の説明に従って、クラスパスを設定します。

7. 複数サーバー環境を構成する場合は、第3.2.2.7項「リモート管理対象サーバーの転送」の説明に従って、すべてのリモート管理対象サーバーをそれらの物理サーバーに転送します。

ステップ2: WebLogic Application ServerとサポートされているWebサーバーとの統合

ご使用の環境にWebサーバーが必要な場合、次の説明に従って、WebLogic Application ServerをOracle、ApacheまたはIIS Webサーバーと統合することもできます。

- 第3.3.1項「Oracle HTTP Serverの構成」

- 第3.3.2項「Apache HTTPサーバーの構成」

- 第3.3.3項「IIS Webサーバーの構成」

3.1.2 この章で使用されるパスとディレクトリ

表3-1は、この章で使用されるパスおよびディレクトリを示しています。

表3-1 WebLogic Application Serverの構成で使用されるパスとディレクトリ

名前

説明

<sites_install_dir>

WebCenter Sitesがインストールされているディレクトリのパス。このパスにWebCenter Sitesアプリケーションの名前は含まれません。

<shared_dir>

指定したシステムの共有フォルダのパス。このパスには共有フォルダの名前が含まれます。

<sites_deploy_home>

展開されたWebCenter Sites Webアプリケーションの予測されるパス。WebCenter Sitesインストーラは、指定されたデプロイメント・ディレクトリ(<deploy_home>)および指定されたWebCenter Sitesアプリケーション名(<sites_app_name>)を使用し、Webアプリケーションをパス<deploy_home>/<sites_app_name>に展開します。

<weblogic_home>

WebLogicがインストールされているディレクトリのパス。パスには、ディレクトリの名前が含まれます。

<domain_home>

WebLogicドメインのパス。このパスにはドメイン名が含まれます。

<apache_home>

Apache Webサーバーがインストールされているディレクトリのパス。パスには、ディレクトリの名前が含まれます。

3.1.3 WebLogic Serverの起動/停止コマンド

この項では、WebLogic Serverを管理するためにこのガイドで使用されるコマンドをリストします。

注意:

UNIXベースのシステムを使用していると想定しています。Windowsベースのインストールの場合は、コマンドの終わりが.cmdまたは.bat拡張子になります。

- 管理サーバーを起動します。

<domain_home>/bin/startWebLogic.sh

- 管理サーバーを停止します。

<domain_home>/bin/stopWebLogic.sh

- ノード・マネージャを起動します。

<weblogic_home>/wlserver_10.3/server/bin/startNodeManager.sh

- 管理対象サーバーを起動します。

<domain_home>/bin/startManagedWebLogic.sh <managed_server_name> http://<admin_server_host>:<admin_port>

- 管理対象サーバーを停止します。

<domain_home>/bin/stopManagedWebLogic.sh <managed_server_name> http://<admin_server_host>:<admin_port>

3.2 ステップ1: WebLogic Application Serverの構成

WebLogic Application Serverを構成するには、次の手順を完了します。

- 第3.2.1項「WebLogicドメインの作成」

- 第3.2.2項「WebLogicドメインの構成」

3.2.1 WebLogicドメインの作成

次の手順で、WebLogicドメインを作成し、管理サーバーを構成します。複数サーバー非クラスタ化環境では、単一のドメインを作成して1つの管理コンソールからローカルおよびリモートのすべてのサーバーを管理するか、スタンドアロン・サーバーごとに1つずつドメインを作成できます。クラスタ化された環境では、プライマリ・クラスタ・メンバー上にドメインを作成します。

WebLogic Serverドメインを作成および構成する手順は、次のとおりです。

1. ディレクトリを<weblogic_home>/wlserver_10.3/common/binに変更し、config.sh (Windowsの場合は.cmd)を実行します。

2. ドメインを作成します

1. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

2. 「ドメイン・ソースの選択」画面で、基本WebLogic Serverドメインをサポートするために自動的に構成されたドメインを生成するを選択し(図3-1)、「次へ」をクリックします。

図3-1 ドメイン・ソースの選択

3. 「ドメイン名と場所の指定」画面で、WebLogicドメインの名前およびパスを入力します(図3-2)。「次へ」をクリックします。

図3-2 ドメイン名と場所

注意:

ドメインのパスは、このガイド全体で<domain_home>とします。

4. 「管理者ユーザー名およびパスワードの構成」画面で、WebLogicドメインのユーザー名とパスワードを入力します(図3-3)。「次へ」をクリックします。

図3-3 管理者ユーザー名およびパスワード

5. 「サーバーの起動モードおよびJDKの構成」画面で、「開発モード」および(WebLogic提供のJDKリスト・ボックスで)望ましいSDKを選択します。図3-4を参照してください。本番環境の場合、ドメインはこのガイドの後半の第6.7項「WebLogic Application Serverの本番モードへの切替え(配信システムのみ)」で本番モードに変更されます。「次へ」をクリックします。

注意:

JRockit JDKを使用する場合、次のものが含まれる最適化ファイルを作成する必要があります。

{ match: [ "net/sf/ehcache/Cache.get*","com/fatwire/cache/ehcache/EhCacheObjectCache._get*","com/fatwire/cache/ehcache/EhCacheObjectCache.get*","net/sf/ehcache/Cache.isExpired*" ], hotspot : { enable : false },}

このファイルは、WebLogic Serverが実行されている物理サーバーそれぞれにコピーする必要があります。

図3-4 サーバー起動モードとJDK構成

6. 「オプション構成の選択」画面で、「管理サーバー」を選択します(図3-5)。管理対象サーバー、クラスタ、およびマシンが作成され、このガイドで後で構成します。「次へ」をクリックします。

図3-5 オプションの構成

3. 管理サーバーを構成します(図3-6)。

1. 管理サーバーの名前、アドレス、およびポートを入力します。

2. SSLを使用する場合は、「SSL有効」を選択し、それが実行されるポートを含めます(配信の場合は推奨)。

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

図3-6 管理サーバー構成

注意:

このガイド全体にわたって、入力した値を、<admin_server_host>および<admin_port>と表します。

4. ドメイン構成を確認し(図3-7)、「作成」をクリックします。

図3-7 構成のサマリー

5. ドメインのインストールが開始されます(図3-8)。インストールが完了したら、終了をクリックします。

図3-8 ドメインの作成

3.2.2 WebLogicドメインの構成

この項では、次の手順を完了します。

- 第3.2.2.1項「マシンの作成」

- 第3.2.2.2項「クラスタの作成と構成」

- 第3.2.2.3項「管理対象サーバーの作成と構成」

- 第3.2.2.4項「データ・ソースの作成と構成」

- 第3.2.2.5項「Javaオプションの設定」

- 第3.2.2.6項「クラスパスの設定」

- 第3.2.2.7項「リモート管理対象サーバーの転送」

3.2.2.1 マシンの作成

マシンは、1つ以上のWebLogic Serverをホストする1つの物理サーバーを論理的に表します。管理サーバーはリモート・サーバーを起動するために、ノード・マネージャとともにマシン定義を使用します。

マシンを作成する手順は、次のとおりです。

1. 管理サーバーの起動。

<domain_home>/bin/startWebLogic.sh

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

http://<admin_server_host>:<admin_port>/console

3. 左のツリーで「環境」を展開し、「マシン」をクリックします。

4. WebLogic Serverが実行される物理サーバーごとに、次の手順を完了します。

1. 「新規」をクリックします。

2. 「名前」に入力します。

3. OSを選択します。

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

5. 保護されたリスナーを使用する場合は、「SSL」を選択し、それ以外の場合は「プレーン」を選択します。

6. 「リスニング・アドレス」に入力します。

7. 必要に応じてポートを変更します。

8. 「終了」をクリックします。

3.2.2.2 クラスタの作成と構成

クラスタ環境では、すべてのWebLogicサーバーはクラスタに属しており、サーバー間の通信はアプリケーション・サーバーによって管理されます。

1. 管理コンソールから「環境」を開き、「クラスタ」をクリックします。

2. クラスタを作成します。

1. 「新規」をクリックします。

2. クラスタ名を入力します。

3. 「マルチキャスト」を選択します。

4. 必要に応じて、「マルチキャスト・アドレス」を変更します。

5. 「マルチキャスト・ポート」に、使用されていないポートを入力します。

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

3. (オプション) セッション永続性を有効化します。

1. 新しく作成したクラスタをクリックし、「レプリケーション」タブを選択します。

2. 「クラスタ間レプリケーションのタイプ」に対して、「MAN (同期) HTTPセッション・ステートのレプリケーション」を選択します。

3. 「リモート・クラスタ・アドレス」は空白のままにします。

4. 「レプリケーション・チャネル」に対して、レプリケーション・トラフィックに使用されるチャネルの名前を入力します。この名前は、そのドメイン内の各クラスタに対して一意であることが必要です。このガイドで、後でこの名前を持つネットワーク・チャネルを、クラスタ内のすべてのサーバーに対して作成します。

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

4. 第3.2.2.3項「管理対象サーバーの作成と構成」に続きます。

3.2.2.3 管理対象サーバーの作成と構成

この管理コンソールで管理されるサーバー(クラスタ環境内のすべてのサーバー)それぞれに対して、次の手順を完了します。

管理対象サーバーを作成および構成する手順は、次のとおりです。

1. 管理コンソールから「環境」を開き、「サーバー」をクリックします。

2. 管理対象サーバーを作成します。

1. 「新規」をクリックします。

2. 「サーバー名」、「サーバー・リスニング・アドレス」および「サーバー・リスニング・ポート」に入力します。

3. サーバーが、単一サーバーまたは複数サーバーでロード・バランシングされた環境の一部である場合、「いいえ、これはスタンドアロン・サーバーです。」を選択します。サーバーがクラスタ環境の一部である場合は、「はい、このサーバーを既存のクラスタのメンバーにします。」を選択し、第3.2.2.2項「クラスタの作成と構成」で作成したクラスタの名前を選択します。

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

5. 「終了」をクリックします。

3. マシンとサーバーを関連付けます。

1. 新規作成したサーバーをクリックします。

2. 「マシン」に対して、このWebLogic Serverが実行される物理サーバーに対応するマシンを選択します。

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

4. weblogic. Deployerおよびweblogic.Adminユーティリティを使用して、サーバーおよびそのデプロイメントを操作するには、トンネリングを有効化する必要があります。
トンネリングを有効化します。

1. 「プロトコル」タブをクリックします。

2. 「トンネリングの有効化」チェック・ボックスを選択します。

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

5. レプリケーション・チャネルを作成します。

注意:

これがクラスタ環境でないか、セッション永続性が使用されない場合は、この手順をスキップします。

1. 「プロトコル」タブから、「チャネル」タブをクリックします。

2. 「新規」をクリックします。

3. 第3.2.2.2項「クラスタの作成と構成」のステップ3で指定したレプリケーション・チャネルの名前を入力します。

4. 「プロトコル」に対して「HTTP」を選択します。

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

6. アドレスは空白のままにし、デフォルト・ポートもそのままにします。

7. 「終了」をクリックします。

3.2.2.4 データ・ソースの作成と構成

この項では、管理コンソールを使用してサポートされているデータベースのいずれかにデータ・ソースを作成する方法を説明します。

1. (DB2のみ) IBM DB2ドライバJARファイルをドメイン・クラスパスに追加します。

1. 管理サーバーを停止します。

<domain_home>/bin/stopWebLogic.sh

注意:

db2jcc4.jarはサポートされていません。

2. DB2からdb2jcc.jarおよびdb2jcc_license_cu.jarを、ドメイン・クラスパスに追加できる場所にコピーします。

3. テキスト・エディタで<domain_home>/bin/setDomainEnv.shを開き、次の行を探します。

# ADD EXTENSIONS TO CLASSPATHS

4. その後に、次の行を追加します。

PRE_CLASSPATH="<path_to_db2jcc.jar>:<path_to_db2jcc_license_cu.jar>:${PRE_CLASSPATH}"

5. 変更を保存します。

注意:

DB2データ・ソースを作成するには、最初にWebLogicパッチ13536596および13870996をダウンロードして適用する必要があります。

6. 管理サーバーの起動。

2. 管理コンソールから、「サービス」を開き、「データ・ソース」をクリックします。

3. データ・ソースを作成します。成

1. 「新規」をクリックして、「汎用データ・ソース」を選択します。

2. 「JNDI名」に名前を入力します。このガイド全体にわたって、入力した値は<jndi_name>と表します。

3. 「データベースのタイプ」に対して、サポートされているデータベース(Oracle、MS SQL ServerまたはDB2)の1つを選択します。

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

図3-9 新規JDBCデータ・ソース - JNDI名およびデータベース・タイプ

5. 「データベース・ドライバ」に対して、ステップcで選択したタイプに対応するオプションを次のものから選択します。

Oracle - Oracle's Driver (Thin) for Instance connections;  Versions:9.0.1 and later
MS SQL Server - Oracle's MS SQL Server Driver (Type 4) Versions:7.0 and later
DB2 - Other (IBM DB2 Universal JDBC Type 4 Driver will be used)

注意:

XAデータ・ソースは、WebCenter Sitesでサポートされていません。

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

7. 「グローバル・トランザクションのサポート」および「1フェーズ・コミット」が選択されていることを確認し、「次へ」をクリックします。

8. 「接続プロパティ」に対して、「データベース名」、「ホスト名」、「ポート」、「データベース・ユーザー名」および「パスワード」の値を入力します。
「DB2」に対して、「ユーザー名」および「パスワード」のみ入力できます。

図3-10 新しいJDBCデータ・ソース - 接続プロパティ

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

10. (DB2のみ) 「ドライバ・クラス名」にcom.ibm.db2.jcc.DB2Driverと入力します。「URL」に次のように入力します。

jdbc:db2://<db_host>:<db_port>/<db_name>. For Properties, enter user=<db_user_name>

11. データ・ソース情報が適切であることを確認し、「構成のテスト」をクリックします。テストに失敗した場合、データ・ソース情報を確認し、再試行します。テストが成功したら、「次へ」をクリックします。

図3-11 データ・ソース情報の確認

12. 管理サーバーと、データ・ソースへのアクセスが必要なすべての管理対象サーバーを選択します。クラスタ環境では、個々の管理対象サーバーを選択するかわりにクラスタを選択します。

13. 「終了」をクリックします。

4. 接続プール・サイズを構成します。

1. 新規作成したデータ・ソースをクリックします。

2. 「接続プール」タブをクリックします。

3. 「初期容量」に対して10を入力し、「最大容量」に対して100を入力します。

注意:

これらは推奨値であり、環境での必要に応じて変更できます。

図3-12 構成 - 接続プール

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

3.2.2.5 Javaオプションの設定

この項では、メモリー引数の設定およびWebCenter Sitesに必要なJavaオプションの追加方法について説明します。

注意:

JRockit JDKを使用する場合、次のものが含まれる最適化ファイルを作成する必要があります。

{ match: [ "net/sf/ehcache/Cache.get*",
"com/fatwire/cache/ehcache/EhCacheObjectCache._
get*","com/fatwire/cache/ehcache/EhCacheObjectCache.get*",
"net/sf/ehcache/Cache.isExpired*" ],
hotspot : { enable : false },}

1. 管理サーバーを停止します。

2. メモリー引数を設定します。

1. テキスト・エディタで<domain_home>/bin/setDomainEnv.shを開き、次のものを探します。

WLS_MEM_ARGS

2. SunとJRockitの両方に、WLS_MEM_ARGS_64BITまたはWLS_MEM_ARGS_32BITの値を設定します。推奨値は-Xms512m -Xmx2048mです。

3. 変更を保存します。

3. WebCenter Sitesに必要なJavaオプションを追加します。

1. テキスト・エディタで<domain_home>/bin/startWebLogic.shを開き、次の行を探します(Start Derbyセクションの下にあります)。

JAVA_OPTIONS="${SAVE_JAVA_OPTIONS}"

2. 次のJavaオプションを追加することで、行を変更します。

- -Dfile.encoding=UTF-8
このオプションによってUTF-8ファイル・エンコーディングが指定されます。

- -Dnet.sf.ehcache.enableShutdownHook=true
このオプションによって、Ehcache停止フックが有効化されます。

- -Djava.net.preferIPv4Stack=true
このオプションで、IPv4アドレスの使用が指定されます。

- -Duser.timezone=UTC
このオプションは、JVMのタイムゾーンの設定に使用されます。すべてのWebCenter Sitesインストールで、この値をUTCに設定することをお薦めします。ただし、この値がすべてのWebCenter Sitesインストールで同一であるかぎり、任意のタイムゾーンを設定できます。

- -Djava.io.tmpdir=<path_to_sites_tmpdir>
このオプションは、JVMがどの一時ディレクトリを使用するのかを指定します。この値は、第2.1項「始める前に」で作成したディレクトリのパスにする必要があります。

- (JRockit JDK only) -XX:+UnlockDiagnosticVMOptions -XX:OptFile=<path_to_optimization_file>
これらのオプションは、JRockit JDKを使用する場合に必要です。それらは、第3.2.1項「WebLogicドメインの作成」で作成した最適化ファイルを使用することをJVMに示します。

注意:

Shift-JIS文字を使用する場合は、-Dcs.useJavaURLDecoder=falseオプションを追加します。

前述の変更を行った後、変更済の行は次のようになります。

JAVA_OPTIONS="-Dfile.encoding=UTF-8  -Dnet.sf.ehcache.enableShutdownHook=true -Djava.net.preferIPv4Stack=true -Duser.timezone=UTC -Djava.io.tmpdir=<path_to_sites_tmpdir> ${SAVE_JAVA_OPTIONS}"

3. 変更を保存します。

3.2.2.6 クラスパスの設定

この項では、WebCenter Sitesが必要とするパスを、アプリケーション・サーバー・クラスパスに追加する方法を説明します。クラスが必ず最初にロードされるようにするには、それをPRE_CLASSPATH変数に追加します。

1. 必要なパスをWebCenter SitesのCLASSPATHに追加します。

1. テキスト・エディタで<domain_home>/bin/startWebLogic.shを開き、次の行を探します(Start Derbyセクションの下にあります)。

CLASSPATH="${SAVE_CLASSPATH}"

2. 次のパスを追加することで、行を変更します。

<sites_install_dir>/bin

このパスには、必須のWebCenter SitesおよびCASの構成ファイルが含まれます。このパスがないと、CAS Webアプリケーションは起動せず、WebCenter Sites管理インタフェースの「管理」タブの「システム・ツール」ノードの機能が低下します。

3. 変更を保存します。

2. 必要なパスをWebCenter SitesのPRE_CLASSPATHに追加します。

1. テキスト・エディタでwlserver_10.3/server/bin/startNodeManager.shを開き、次の行を探します。

# Get PRE and POST environment
if [ ! -z "${PRE_CLASSPATH}" ]; then
CLASSPATH="PRE_CLASSPATH="<sites_deploy_home>/WEB-INF/lib/commons-lang-2.4.jar:${PRE_CLASSPATH}"${CLASSPATHSEP}${CLASSPATH}"

2. その後に、次の行を追加します。

PRE_CLASSPATH="<sites_deploy_home>/WEB-INF/lib/commons-lang-2.4.jar:${PRE_CLASSPATH}"

このJARは、展開されたWebCenter Sites Webアプリケーションのlibディレクトリにあります。WebCenter Sitesコントリビュータ・インタフェースによって適切にロードされるようにするには、このJARが、クラスパスにそのクラスの他のバージョンより前にロードされている必要があります。

注意:

この変更はすべてのドメインに影響します。

3. 変更を保存します。

3.2.2.7 リモート管理対象サーバーの転送

この項では、管理コンソールを使用して作成したリモート管理されているサーバーを、それらが実行される物理サーバーに転送する方法を説明します。

1. ドメイン内のすべてのサーバーが停止していることを確認します。

2. プライマリ・サーバーで作成されたドメインからテンプレートを作成します。<weblogic_home>/wlserver10.3/common/binから次のコマンドを実行します。

./pack.sh -managed=true -domain=<domain_home> -template=<template_creation_location>/<template_name>.jar -template_name="<template_name>"
For example:
./pack.sh -managed=true -domain=/opt/Oracle/Middleware/user_projects/domains/SitesDomain -template=/opt/Downloads/SitesDomainTemplate.jar -template_name="SitesDomainTemplate"

3. リモート・サーバーごとに、次の手順を完了します。

1. 新規作成したテンプレートをリモート・サーバーにコピーします。

注意:

リモート・サーバーには、WebLogic Serverがすでにインストールされている必要があります。

2. コピーしたテンプレートから管理対象サーバーおよび必要なドメイン・ファイルを解凍します。
ドメインは、プライマリ・サーバーと同じ場所に作成されます。

3. <weblogic_home>/wlserver10.3/common/binディレクトリから次のコマンドを実行します。

./unpack.sh -domain=<domain_home> -template=<template_location>/<template name>.jar

例:

./unpack.sh -domain=/opt/Oracle/Middleware/user_projects/domains/SitesDomain -template=/opt/Downloads/SitesDomain.jar

4. <domain_home>/bin/startWebLogic.shおよび<domain_home>/bin/setDomainEnv.shファイルを、プライマリ・サーバーからリモート・サーバーの<domain_home>/binディレクトリにコピーします。変更されたファイルは、テンプレートに含まれていません。

5. ファイルを変更し、第3.2.2.5項「Javaオプションの設定」および第3.2.2.6項「クラスパスの設定」で追加されたパスまたはオプションにおける違いを反映する変更をすべて行います。

6. 変更を保存します。

3.3 ステップ2: Oracle WebLogic ServerとサポートされているWebサーバーとの統合

この章では、WebLogicサーバーを、選択したサポートされているWebサーバーと統合するためのガイドラインを示します。

この章の内容は、次のとおりです。

- 第3.3.1項「Oracle HTTP Serverの構成」

- 第3.3.2項「Apache HTTPサーバーの構成」

- 第3.3.3項「IIS Webサーバーの構成」

3.3.1 Oracle HTTP Serverの構成

次の手順に従い、WebLogicで使用するために、mod_wl_ohsプラグインをOracle HTTP Serverで構成します。

1. テキスト・エディタで<ohs_instance>/config/OHS/<server_name>/mod_wl_ohs.confを開き、コメント化されたLocationタグの前に次のものを追加します。
単一サーバー環境

<IfModule mod_weblogic.c>
WebLogicHost {weblogic_host}
WebLogicPort {weblogic_port}
</IfModule>

<Location /{sites_context_root}>
SetHandler weblogic-handler
</Location>

<Location /cas>
SetHandler weblogic-handler
</Location>

複数サーバー環境

<IfModule mod_weblogic.c>
WebLogicCluster {weblogic_host1}:{weblogic_port1},{weblogic_host2}:{weblogic_port2}
</IfModule>

<Location /{sites_context_root}>
SetHandler weblogic-handler</Location>

<Location /cas>
SetHandler weblogic-handler
</Location>

2. 変更を保存します。

3. Webサーバーを再起動します。

3.3.2 Apache HTTPサーバーの構成

この項では、WebLogicで使用するために、mod_wlプラグインをApache 2.2.x HTTPサーバーで構成する方法について説明します。

mod_wlプラグインを構成する手順は、次のとおりです。

1. mod_so.cが有効化されていることを確認します。<apache_home>/bin/apachectl –lを実行します。mod_so.cが出力されたリストにない場合、–enable-module=soオプションを指定してApacheを再構築する必要があります。

2. mod_wl_22.soファイルを<weblogic_home>/wlserver_10.3/server/plugin/<os_type>/<os_version>から<apache_home>/modulesにコピーします。

3. テキスト・エディタで<apache_home>/config/httpd.confを開き、そのファイルの最後に次のものを追加します。
単一サーバー環境

<IfModule mod_weblogic.c>
WebLogicHost {weblogic_host}
WebLogicPort {weblogic_port}
</IfModule>

<Location /{sites_context_root}>
SetHandler weblogic-handler
</Location>

<Location /cas>
SetHandler weblogic-handler
</Location>

複数サーバー環境

LoadModule weblogic_module modules/mod_wl_22.so

<IfModule mod_weblogic.c>
WebLogicCluster {weblogic_host1}:{weblogic_port1},{weblogic_host2}:{weblogic_port2}
</IfModule>

<Location /{sites_context_root}>
SetHandler weblogic-handler
</Location>

<Location /cas>
SetHandler weblogic-handler
</Location>

4. 変更を保存します。

5. 次のコマンドで、httpd.confファイルの構文を検証します。

<apache_home>/bin/apachectl -t

6. Webサーバーを再起動します。

3.3.3 IIS Webサーバーの構成

この項では、WebLogic Serverで使用するために、IISプラグインをIISバージョン7.0以降で構成する方法について説明します。

IISバージョン7.0以降のIISプラグインを構成する手順は、次のとおりです。

1. <wl_home>/wlserver_10.3/server/plugin/ディレクトリに移動し、適切なOSバージョンおよびタイプのプラグイン・フォルダを、IISをインストールしたサーバー(<IIS_plugin_dir>ディレクトリと呼ぶ)にコピーします。例: C:\inetpub\win\x64

2. IISマネージャにアクセスします。「Connections」ナビゲーション・ペインで、「root server」→「Sites」を開きます。

1. 「Default Web Site」ノードを右クリックし、「Manage Web Site」→「Advanced Settings」を選択します(図3-13)。

図3-13 Connections - Manage Web Site

2. 「Advanced Settings」ウィンドウで、「Physical Path」フィールドの値を<IIS_plugin_dir>ディレクトリ(ステップ1のもの)に変更します。例: C:\inetpub\win\x64次に、「OK」をクリックします。

3. 「Default Web Site Home」画面で「ISAPI Filters」をダブルクリックします。

1. 「ISAPI Filters」画面の任意の場所を右クリックし、コンテキスト・メニューから「Add」をクリックします。
「Add ISAPI Filter」ウィンドウが開きます。

2. 次のフィールドに、ご使用のシステムに適した情報を移入します。例:

- Filter name: wlforward

- Executable: C:\inetpub\win\x64\iisforward.dll

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

4. 「Default Web Site」をクリックし、「Default Web Site Home」画面に戻ります。「Default Web Site Home」画面で、「Handler Mappings」をダブルクリックします。

1. 「Handler Mappings」画面で、任意の場所を右クリックし、コンテキスト・メニューから「Add Script Map」を選択します。
「Add Script Map」ウィンドウが開きます。

2. 次のフィールドに、ご使用のシステムに適した情報を入力します(図3-14)。例:

- Requested Path: *

- Executable: C:\inetpub\win\x64\iisproxy.dll

- Name: IISProxy

図3-14 「Edit Script Map」ダイアログ・ボックス

3. 「Requested Restrictions」をクリックします。図3-15に示すように、「Request Restrictions」ウィンドウで、「Invoker handler mapping」オプションを選択解除します(選択されている場合)。

図3-15 「Request Restrictions」ダイアログ・ボックス

4. 「Yes」をクリックします(図3-16)。

図3-16 「Edit Script Map」ダイアログ・ボックス

5. 「root server」ノードをクリックして「IIS Home」画面にアクセスし、「ISAPI and CGI Restrictions」をダブルクリックします。

1. 「ISAPI and CGI Restrictions」画面で、任意の場所を右クリックし、コンテキスト・メニューから「Edit Feature Settings」を選択します。

2. 「Edit ISAPI and CGI Restrictions Settings」ウィンドウで、「Allow unspecified CGI modules」オプションと「Allow unspecified ISAPI modules」オプションの両方を選択します(図3-17)。

図3-17 「Edit ISAPI and CGI Restrictions Settings」ダイアログ・ボックス

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

6. 「Physical Path」フォルダ(ステップ1の<IIS_plugin_dir>ディレクトリ)で、iisproxy.iniというファイルを作成し、それに、ご使用のシステムに適した情報を移入します。

- クラスタ化されていない環境では、次の例を使用します。

WebLogicHost=<hostname>
WebLogicPort=<port>
ConnectRetrySecs=5
WLForwardPath=/<cs_context_root>,/<cas_context_root>

- クラスタ化されている環境では、次の例を使用します。

WebLogicCluster=<member1_hostname>:<member1_port>,
<member2_hostname>:<member2_port>,<membern_hostname>:
<membern_port>
ConnectRetrySecs=5
ConnectTimeoutSecs=25
WLForwardPath=/<cs_context_root>,/<cas_context_root>

これらのパラメータの詳細は、ベンダーのドキュメントを参照してください。

注意:

SitesとCASが同じサーバー上にある場合は/casのみ含めてください。CASが別のサーバーにある場合は、その環境に一意のそれの新しいエントリが必要になります。

7. IIS ServerおよびデフォルトWebサイトを起動します。

8. これで、WebCenter Sitesをインストールする準備ができました。手順については、第6章「WebCenter Sitesのインストール手順」に進んでください。

4 Apache Tomcat Application ServerにWebCenter Sitesをインストールするための準備

この章では、WebCenter Sites WebアプリケーションをサポートするためのTomcatの構成について説明します。

この章の内容は、次のとおりです。

- 第4.1項「Tomcat Application Serverのセットアップのクイック・リファレンス」

- 第4.2項「ステップ1: Tomcat Application Serverの構成」

- 第4.3項「ステップ2: Tomcat Application ServerとサポートされているWebサーバーとの統合」

4.1 Tomcat Application Serverのセットアップのクイック・リファレンス

この項の内容は、次のとおりです。

- 第4.1.1項「手順の概要」

- 第4.1.2項「この章で使用されるパスとディレクトリ」

- 第4.1.3項「Tomcatの起動/停止コマンド」

4.1.1 手順の概要

開発、コンテンツ管理および配信の各環境の要件に応じて、次の手順を完了します。

ステップ1: Tomcat Application Serverの構成

1. 第4.2.1項「Tomcat Serverポートの変更」の説明に従って、デフォルトTomcatポートを変更します。

2. 第4.2.2項「データ・ソースの作成と構成」の説明に従って、データ・ソースを作成および構成します。

3. 第4.2.3項「Javaオプションの設定」の説明に従って、Javaオプションを設定します。

4. 第4.2.4項「クラスパスの設定」の説明に従って、クラスパスを設定します。

5. 第4.2.5項「URIエンコーディングの構成」の説明に従って、URIエンコーディング文字セットを設定します。

6. サーバーが、複数サーバー環境の一部である場合は、第4.2.6項「ロード・バランシングのためのTomcatサーバーの構成」の説明に従って、jvmRoute属性を設定します。

7. Tomcatサーバーが、クラスタ環境の一部である場合は、第4.2.7項「クラスタリングのためのTomcatサーバーの構成」の説明に従って、クラスタリング用にサーバーを構成します。

8. サーバーがSSLを介して実行されている場合は、第4.2.8項「SSLのためのTomcatサーバーの構成」の説明に従って、SSL用にTomcatサーバーを構成します。

ステップ2: Tomcat Application ServerとサポートされているWebサーバーとの統合

この手順は、次のような場合に必要です。

- Apache Web Serverを使用してロード・バランシングされるクラスタ化された環境を作成する。

- Tomcatの前にApache Web Serverを配置する。

TomcatをApache Web Serverと統合する手順は、第4.3項「ステップ2: Tomcat Application ServerとサポートされているWebサーバーとの統合」に記載します。

4.1.2 この章で使用されるパスとディレクトリ

表4-1は、この章で使用されるパスおよびディレクトリを示しています。

表4-1 Tomcat Application Serverの構成で使用されるパスとディレクトリ

名前

説明

<sites_install_dir>

WebCenter Sitesインストール・ディレクトリのパス。

<tomcat_home>

Tomcatインストール・ディレクトリのパス。

<shared_dir>

指定されたシステムの共有フォルダのパス。パスには、共有フォルダの名前が含まれます。

4.1.3 Tomcatの起動/停止コマンド

この項では、Tomcatインスタンスの起動および停止のコマンドをリストします。

注意:

すべてのコマンドは、CATALINA_HOMEおよびJAVA_HOMEが適切なディレクトリに設定されていることを必要とします。

Tomcatインスタンスを起動する手順は、次のとおりです。

次のコマンドを実行します。

- UNIXの場合:

<tomcat_home>/bin/startup.sh

- Windowsの場合:

<tomcat_home>/bin/startup.bat

Tomcatインスタンスを停止する手順は、次のとおりです。

次のコマンドを実行します。

- UNIXの場合:

<tomcat_home>/bin/shutdown.sh -force

- Windowsの場合:

<tomcat_home>/bin/shutdown.bat

4.2 ステップ1: Tomcat Application Serverの構成

この項では、次の手順を完了します。

- 第4.2.1項「Tomcat Serverポートの変更」

- 第4.2.2項「データ・ソースの作成と構成」

- 第4.2.3項「Javaオプションの設定」

- 第4.2.4項「クラスパスの設定」

- 第4.2.6項「ロード・バランシングのためのTomcatサーバーの構成」

- 第4.2.7項「クラスタリングのためのTomcatサーバーの構成」

- 第4.2.8項「SSLのためのTomcatサーバーの構成」

注意:

この項の手順では、UNIXコマンドを使用します。

4.2.1 Tomcat Serverポートの変更

この項では、Tomcatによって使用されるデフォルト・ポートを変更する方法を説明します。同じ物理サーバー上で複数のTomcatサーバーを実行するには、これらのポートを変更し、ポートの競合を回避する必要があります。

1. Tomcatサーバーを停止します。

2. テキスト・エディタで<tomcat_home>/conf/server.xmlファイルを開き、次のポートを変更します。

- 停止ポート(デフォルト8005)
このポートは、Tomcatサーバーを停止するときに使用されます。

- HTTPポート(デフォルト8080)
これは、Webアプリケーションにアクセス可能になるメイン・ポートです。

- リダイレクト・ポート(デフォルト8443)

このポートは、HTTPとAJPの両方のコネクタで変更する必要があります。

- AJPポート(デフォルト8009)
このポートは、Apache Webサーバーとの通信に使用できます。

- (SSLのみ) SSL HTTPポート(デフォルト8443)
SSLを使用する場合、このポートをステップ2で使用したものと同じ値に変更します。

3. 変更を保存します。

4.2.2 データ・ソースの作成と構成

1. 使用するデータベースに対応するデータ・ソース情報を選択し、必要なJARファイルを<tomcat_home>/libディレクトリに配置します。表4-2のデータ・ソース情報は、次のステップでデータ・ソースを作成するために使用されます。

表4-2 データ・ソース情報

データベース・ドライバ

パラメータ

値

JTDS (サード・パーティ・ドライバ)

- DriverClass

- 必須.jarファイル

- URL

- net.sourceforge.jtds.jdbcx.JtdsDataSource

- jtds-1.2.5 jar

- jdbc:jtds:sqlserver://<server>:<dbport>/<dbname>
例: jdbc:jtds:sqlserver://127.0.0.1:1433/contentDB

DB2

- DriverClass

- 必須.jarファイル

- URL

- com.ibm.db2.jcc.DB2Driver

- db2jcc.jar, db2cc_license_cu.jar
注意: db2jcc4.jarファイルはサポートされていません。db2jcc4.jarファイルが使用されている場合、インストールに失敗します。

- jdbc:db2://<hostname>:<dbport>/<dbname>
例: jdbc:db2://127.0.0.1:50001/contentDB

Oracle Thinドライバ

- DriverClass

- 必須.jarファイル

- URL

- oracle.jdbc.driver.OracleDriver

- ojdbc6.jar

- jdbc:oracle:thin:@//<hostname>:1521/<dbname>
例: jdbc:oracle:thin:@//127.0.0.1:1521/contentDB

2. テキスト・エディタで<tomcat_home>/conf/server.xmlファイルを開き、Hostタグ内に次のXMLコードを追加し、パラメータ化されている値をすべて置換します。

<Context path="/<sites_context_root>" docBase="<sites_context_root>" reloadable="true" crossContext="true">
<Resource name="<jndi_name>" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30"
username="<db_user_name>"
password="<db_user_password>"
driverClassName="<db_driver_class>"
url="<db_url>"/>
</Context>

Oracle Databaseの場合のサンプル・データ・ソース:

<Context path="/cs" docBase="cs" reloadable="true" crossContext="true">
<Resource name="csDataSource" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30"
username="csuser"
password="password"
driverClassName="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@//127.0.0.1:1521/contentDB"/>
</Context>

注意:

前述の例では、データベース接続の最大許容数は、100に設定されています。これは推奨される値ですが、環境の要件に応じて変更できます。

3. 変更を保存します。

4.2.3 Javaオプションの設定

この項では、メモリー引数の設定およびWebCenter Sitesに必要なJavaオプションの追加方法について説明します。

1. テキスト・エディタで<tomcat_home>/bin/setenv.shを開き、行CATALINA_OPTS="<java_opts>"を追加します。<java_opts>は、空白で区切られた次のオプションのリストです。

- -Xms512m -Xmx2048m
これらのオプションで、最小および最大メモリー・ヒープ・サイズが設定されます。これらは推奨されるサイズですが、環境の要件に応じて変更できます。

- -XX:MaxPermSize=192m
このオプションで、Permanent世代の容量の最大サイズが設定されます。これは推奨されるサイズですが、環境の要件に応じて変更できます。

- -Dfile.encoding=UTF-8
このオプションによってUTF-8ファイル・エンコーディングが指定されます。

- -Dnet.sf.ehcache.enableShutdownHook=true
このオプションによって、Ehcache停止フックが有効化されます。

- -Djava.net.preferIPv4Stack=true
このオプションで、IPv4アドレスの使用が指定されます。

- -Duser.timezone=UTC
このオプションは、JVMのタイムゾーンの設定に使用されます。すべてのWebCenter Sitesインストールで、この値をUTCに設定することをお薦めします。ただし、この値がすべてのWebCenter Sitesインストールで同一であるかぎり、任意のタイムゾーンを設定できます。完成したCATALINA_OPTSは次のようになるはずです。

CATALINA_OPTS="-Xms512m -Xmx2048m -XX:MaxPermSize=192m
-Dfile.encoding=UTF-8
-Dnet.sf.ehcache.enableShutdownHook=true -Djava.net.preferIPv4Stack=true
-Duser.timezone=UTC"

注意:

Shift-JIS文字を使用する場合は、-Dcs.useJavaURLDecoder=falseオプションを追加します。

2. 変更を保存します。

4.2.4 クラスパスの設定

この項では、WebCenter Sitesが必要とするパスを、アプリケーション・サーバー・クラスパスに追加する方法を説明します。

1. テキスト・エディタで<tomcat_home>/bin/setenv.shを開き、行CLASSPATH="<paths>"を追加します。ここで、<paths>は、次のパスのコロン(:)で区切られたリストです。

1. <sites_install_dir>/bin
このパスには、必須のWebCenter SitesおよびCASの構成ファイルが含まれます。このファイルがないと、CAS Webアプリケーションは起動せず、WebCenter Sites管理インタフェースの「管理」タブの「システム・ツール」ノードの機能が低下します。

2. $JAVA_HOME/lib/tools.jar
このJARファイルは、JDK内にあります。

2. 変更を保存します。

4.2.5 URIエンコーディングの構成

この項では、URIエンコーディングの文字セットをUTF-8に設定する方法を説明します。

1. テキスト・エディタで<tomcat_home>/conf/server.xmlを開き、次のようにHTTP Connectorタグ内にURIEncoding属性を追加します。

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" URIEncoding="UTF-8" />

2. 変更を保存します。

4.2.6 ロード・バランシングのためのTomcatサーバーの構成

この項では、ロード・バランシング環境の一部となることができるようにTomcatサーバーを構成する方法を説明します。

1. テキスト・エディタで<tomcat_home>/conf/server.xmlを開き、次のようにEngineタグ内にjvmRoute属性を追加します。

<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">

2. jvmRouteの値を変更し、それが、ロード・バランシングされるすべての他のTomcatサーバーに対して一意になるようにします。

3. 変更を保存します。

4.2.7 クラスタリングのためのTomcatサーバーの構成

この項では、クラスタの一部となるようにTomcatサーバーを構成する方法を説明します。

1. テキスト・エディタで<tomcat_home>/conf/server.xmlファイルを開き、次のXMLコードを、Engineタグ内の最初のものとなるように追加します。

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

2. 必要に応じて、Membershipアドレスまたはポートを変更します。

- 各クラスタは、メッセージの競合を回避するために、一意のMembershipアドレスとポートの組合せを持つ必要があります。

- 1つのクラスタのすべてのメンバーは、Membershipアドレスおよびポートに対して同じ値を持つ必要があります。

3. 必要に応じて、ReceiverポートまたはautoBindを変更します。
レシーバは、ポートと、ポート+autoBindの範囲の空きポートにバインドすることで、ポートの競合を自動的に回避します。これらの値のいずれかを必要に応じて変更し、レシーバが使用するポートの範囲を制限します。

4. 変更を保存します。

4.2.8 SSLのためのTomcatサーバーの構成

1. 次のように証明書を生成します。

keytool -genkey -alias tomcat -keyalg RSA –keystore
<tomcat_home>/keys/.keystore

1. -keystoreパラメータを、生成されたキーを格納する場所に設定します。

2. キーストア・パスワードを求められたら、自身のパスワードを使用するか、デフォルトのchangeitを使用できます。カスタム・パスワードを入力する場合、server.xmlファイルの値の変更が必要になります(ステップ2で説明)。

3. 求められたら、姓名、組織名、市区町村、都道府県および国コードを入力し、確認のために「Yes」をクリックします。

4. 次に「Enter key password for <tomcat> (RETURN if same as keystore password)」が表示されたら、キー・パスワードはキーストア・パスワードと同じであるため、[Enter]キーを押します。

2. <tomcat_home>/conf/server.xmlを編集し、SSLセクションを非コメント化し、次の属性をSSLコネクタに追加します。

- keystoreType="JKS"
この属性は、Javaキーストア(Javaのキーツールで生成される形式)の場合はJKSに設定されます。

- keystoreFile="<tomcat_home>/keys/.keystore"
この属性は、.keystoreファイルが作成され、ステップ1で使用されたものと同じパスに設定されます。

- keystorePass="<new_password>"
この属性は、ステップ1で使用されたキーストア・パスワードがchangeitではなく、使用されたカスタム・パスワードに設定する必要がある場合にのみ必要です。

3. 変更を保存します。

4. サーバーを起動した後、ブラウザにhttps://<tomcat_host>:<ssl_port>を指定します。
システムが適切に機能している場合、証明書を受け入れるように求められます。証明書を受け入れると、Tomcat索引ページが表示されます。

4.3 ステップ2: Tomcat Application ServerとサポートされているWebサーバーとの統合

この項では、Tomcatサーバーを、選択したサポートされているWebサーバーと統合するためのガイドラインを示します。

4.3.1 Apache HTTPサーバーの構成

この項では、Tomcatで使用するために、mod_proxy_ajpプラグインをApache 2.2.xまたはApache 2.4.x HTTPサーバーで構成する方法について説明します。

1. mod_so.cが有効化されていることを確認します。<apache_home>/bin/apachectl -lを実行します。mod_so.cが出力されたリストにない場合、-enable-module=soオプションを指定してApacheを再構築する必要があります。

2. テキスト・エディタで<apache_home>/config/httpd.confを開き、そのファイルの最後に次のものを追加します。
単一サーバー環境

ProxyPass /cas ajp://<tomcat_server_host>:<ajp_port>/cas
ProxyPassReverse /cas ajp://<tomcat_server_host>:<ajp_port>/cas
ProxyPass /<sites_context_root> ajp://<tomcat_server_host>:<ajp_port>/<sites_context_root>
ProxyPassReverse /<sites_context_root> ajp://<tomcat_server_host>:<ajp_port>/<sites_context_root>

複数サーバー環境

<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from none
Allow from all
</Location>

<Proxy balancer://cluster>
BalancerMember ajp://<tomcat_server_host1>:<ajp_port1> loadfactor=1 route=<jvm_route1>
BalancerMember ajp://<tomcat_server_host2>:<ajp_port2> loadfactor=1 route=<jvm_route2>
ProxySet stickysession=JSESSIONID
</Proxy>

ProxyPass /cas balancer://cluster/cas
ProxyPassReverse /cas balancer://cluster/cas
ProxyPass /<sites_context_root> balancer://cluster/<sites_context_root>
ProxyPassReverse /<sites_context_root> balancer://cluster/<sites_context_root>

注意:

この例では、バランサマネージャがすべてのアクセスを許可します。セキュリティを高めるために、Apacheのドキュメントを参照して、Deny fromおよびAllow fromの値を変更できます。

AVI Sportsサンプル・サイトをインストールする場合は、各BalancerMember行の終わりにtimeout=180を追加します。

3. 変更を保存します。

4. 次のコマンドで、httpd.confファイルの構文を検証します。
<apache_home>/bin/apachectl -t

5. Webサーバーを再起動します。

5 IBM WebSphere Application ServerにWebCenter Sitesをインストールするための準備

この章は、WebCenter Sites用にWebSphere Application Server (WAS)を構成する方法を示します。

この章の内容は、次のとおりです。

- 第5.1項「WebSphere Application Serverのセットアップのクイック・リファレンス」

- 第5.2項「ステップ1: WebSphere Application Serverの構成」

- 第5.3項「ステップ2: WebSphere Application ServerとサポートされているWebサーバーとの統合」

注意:

この章の手順を開始する前に、第2章「WebCenter Sitesをインストールするための前提条件」で説明した前提条件の手順を完了していることを確認してください。

5.1 WebSphere Application Serverのセットアップのクイック・リファレンス

この項の内容は、次のとおりです。

- 第5.1.1項「手順の概要」

- 第5.1.2項「WebSphere Application Serverの構成で使用されるパスとディレクトリ」

- 第5.1.3項「WebSphere Application Serverの起動/停止コマンド」

5.1.1 手順の概要

WebCenter Sitesをインストールする開発、コンテンツ管理、および配信の各環境に対して、次の手順を完了します。

ステップ1: WebSphere Application Serverの構成

1. 第5.2.1項「必要なプロファイルの作成」の説明に従って、デプロイメント・マネージャおよびアプリケーション・サーバーのプロファイルを作成します。

2. クラスタ環境を構成している場合は、第5.2.2項「クラスタの作成」の説明に従って、クラスタを作成します。

3. 非クラスタ環境を構成している場合は、第5.2.3項「サーバーの作成」の説明に従って、アプリケーション・サーバーを作成します。

4. 第5.2.4項「サーバーの構成」の説明に従って、アプリケーション・サーバーを構成します。
この手順では、次のことを実行する必要があります。

1. 第5.2.4.1項「Webコンテナ・プロパティの構成」の説明に従って、アプリケーション・サーバーのWebコンテナ・プロパティを構成します。

2. 第5.2.4.2項「セッション管理の構成」の説明に従って、アプリケーション・サーバーのセッション管理を構成します。

3. 第5.2.4.3項「クラスパスとJavaオプションの設定」の説明に従って、クラスパスおよびJavaオプションを設定します。

5. 第5.2.5項「仮想ホストのホスト別名の作成」の説明に従って、新規サーバーの仮想ホストにホスト別名を追加します。

6. 第5.2.6項「データベース通信のためのWAS環境の構成」の説明に従って、WebCenter Sitesデータベースに接続するようにWAS環境を構成します。
この手順では、次のことを実行する必要があります。

1. 第5.2.6.1項「J2C認証データの作成」の説明に従って、J2C認証データを作成します。

2. 第5.2.6.2項「JDBCプロバイダの作成」の説明に従って、JDBCプロバイダを作成します。

3. 第5.2.6.3項「データ・ソースの作成」の説明に従って、データ・ソースを作成します。

ステップ2: WebSphere Application ServerとサポートされているWebサーバーとの統合

ご使用の環境にWebサーバーが必要な場合、WebSphere Application ServerをIBM HTTP ServerまたはApache Webサーバーと統合することもできます。詳細は、第5.3項「ステップ2: WebSphere Application ServerとサポートされているWebサーバーとの統合」を参照してください。

5.1.2 WebSphere Application Serverの構成で使用されるパスとディレクトリ

表5-1はWebSphere Application Serverの構成に使用されるパスおよびディレクトリを示しています。

表5-1 WebSphere Application Serverの構成で使用されるパスとディレクトリ

名前

説明

<sites_install_dir>

WebCenter Sitesがインストールされているディレクトリのパス。パスには、ディレクトリの名前が含まれます。

<shared_dir>

WebCenter Sites共有ファイル・システム・ディレクトリのパス。パスには、共有ディレクトリの名前が含まれます。

<WAS_home>

WebSphere Application Serverがインストールされているディレクトリのパス。パスには、ディレクトリの名前が含まれます。

<dmgr_host>

デプロイメント・マネージャのホストのホスト名またはIPアドレス。

<dmgr_port>

デプロイメント・マネージャ・コンソールが接続をリスニングするポート番号。

<dmgr_profile>

デプロイメント・マネージャ・プロファイルの名前。

<dmgr_soap_port>

デプロイメント・マネージャのSimple Object Access Protocolポートの番号。

<server_name>

WASサーバーの名前。

<appsrv_profile>

アプリケーション・サーバー・プロファイルの名前。

<appsrv_node>

アプリケーション・サーバー・ノードの名前。

<ibm_http_home>

IBM HTTP Serverがインストールされているディレクトリのパス。パスには、ディレクトリの名前が含まれます。

<plugin_root>

Webサーバーのプラグイン・ディレクトリのパス。パスには、ディレクトリの名前が含まれます。

5.1.3 WebSphere Application Serverの起動/停止コマンド

この項では、WASコンポーネントの起動および停止のコマンドをリストします。

この項の内容は、次のとおりです。

- 第5.1.3.1項「デプロイメント・マネージャ」

- 第5.1.3.2項「ノード・エージェント」

- 第5.1.3.3項「アプリケーション・サーバー」

5.1.3.1 デプロイメント・マネージャ

注意:

デフォルト・デプロイメント・マネージャ・プロファイル名はDmgr01です。

起動および停止のコマンドは次のとおりです。

- 起動:

- Windowsの場合:

<WAS_home>\bin\startManager.bat -profileName <dmgr_profile>

- UNIXの場合:

<WAS_home>/bin/startManager.sh -profileName <dmgr_profile>

- 停止:

- Windowsの場合:

<WAS_home>\bin\stopManager.bat -profileName <dmgr_profile>

- UNIXの場合:

<WAS_home>/bin/stopManager.sh -profileName <dmgr_profile>

5.1.3.2 ノード・エージェント

注意:

最初に作成されたアプリケーション・サーバー・プロファイルのデフォルト名はAppSrv01です。

起動および停止のコマンドは次のとおりです。

- 起動:

- Windowsの場合

<WAS_home>\bin\startNode.bat –profileName <appsrv_profile>

- UNIXの場合

<WAS_home>/bin/startNode.sh –profileName <appsrv_profile>

- 停止:

- Windowsの場合:

<WAS_home>\bin\stopNode.bat –profileName <appsrv_profile>

- UNIXの場合:

<WAS_home>/bin/stopNode.sh –profileName <appsrv_profile>

5.1.3.3 アプリケーション・サーバー

注意:

デフォルトのサーバー名はserver1です。

最初に作成されたアプリケーション・サーバー・プロファイルのデフォルト名はAppSrv01です。

起動および停止のコマンドは次のとおりです。

- 起動:

- Windowsの場合:

<WAS_home>\bin\startServer.bat <server_name> -profileName <appsrv_profile>

- UNIXの場合:

<WAS_home>/bin/startServer.sh <server_name> -profileName <appsrv_profile>

- 停止:

- Windowsの場合:

<WAS_home>\bin\stopServer.bat <server_name> -profileName <appsrv_profile>

- UNIXの場合:

<WAS_home>/bin/stopServer.sh <server_name> -profileName <appsrv_profile>

5.2 ステップ1: WebSphere Application Serverの構成

この項では、コマンドラインを使用してWASインスタンスを作成する方法を示します。

注意:

Windowsでは、この項で使用するコマンドライン・ツールの名前は、.shのかわりに.batで終わります。Windowsシステムでコマンドを実行するときは、必要な置換を行うことを忘れないでください。

この項の内容は、次のとおりです。

- 第5.2.1項「必要なプロファイルの作成」

- 第5.2.2項「クラスタの作成」

- 第5.2.3項「サーバーの作成」

- 第5.2.4項「サーバーの構成」

- 第5.2.5項「仮想ホストのホスト別名の作成」

- 第5.2.6項「データベース通信のためのWAS環境の構成」

5.2.1 必要なプロファイルの作成

この項に示す手順に従って、環境での必要に応じて、デプロイメント・マネージャおよびアプリケーション・サーバーのプロファイルを作成します。複数サーバー非クラスタ化環境では、単一のデプロイメント・マネージャを使用して1つの管理コンソールからローカルおよびリモートのすべてのサーバーを管理するか、物理サーバーごとに1つのデプロイメント・マネージャを使用できます。クラスタ化された環境では、プライマリ・クラスタ・メンバー上でのみデプロイメント・マネージャを使用します。

注意:

各プロファイルのノードにリモートにアクセスできるように、システムに対してホスト名が構成されていることを確認します。

1. 使用されていないプロファイルを削除します。
今後使用されないプロファイルをクリーンアップする場合は、次の手順を完了します。

1. 既存のプロファイルをリストします。
チェックするWASインストールの<WAS_home>/binディレクトリから、次のコマンドを実行します。

./manageprofiles.sh -listProfiles

デフォルトでは、デプロイメント・マネージャ・プロファイルは先頭にDmgrが付いており、アプリケーション・サーバー・プロファイルは先頭にAppSrvが付いています。

2. 削除するプロファイルをリストから選択し、ステップcに進みます。

3. プロファイルを削除します。

ステップbで選択した各プロファイルに、次のコマンドを実行します。

./manageprofiles.sh -delete -profileName <profile_name>

4. 残されたプロファイル・ディレクトリ<WAS_home>/profiles/<profile_name>を削除します。

2. 次のようにデプロイメント・マネージャ・プロファイルを作成します。
インストーラによって作成されたデプロイメント・マネージャを使用していない場合、ここで1つ作成します。次のコマンドは、環境用のセル(<dmgr_host>Cell#)またはトップレベルの組織単位、およびデプロイメント・マネージャ・プロファイル用のノード(<dmgr_host>CellManager#)またはミドルレベルの組織単位を作成します。プライマリ・サーバーの<WAS_home>/binディレクトリから、次のコマンドを実行します。

./manageprofiles.sh -create -profileName <dmgr_profile> -profilePath <WAS_home>/profiles/<dmgr_profile> -templatePath <WAS_home>/profileTemplates/dmgr -isDefault -defaultPorts

注意:

Adminセキュリティを有効にする場合は、次のオプションを追加します。

-enableAdminSecurity true -adminUserName <username> -adminPassword <password>

3. デプロイメント・マネージャを起動します。

<WAS_home>/bin/startManager.sh -profileName <dmgr_profile>

4. アプリケーション・サーバー・プロファイルを作成します。
各物理サーバーに対して、管理対象またはスタンドアロンのいずれかのアプリケーション・サーバー・プロファイルを作成します。アプリケーション・サーバー・プロファイルがデプロイメント・マネージャに対してローカルになる場合、それは管理対象になります。それがリモートである場合、それはスタンドアロンになります。次の手順のコマンドは、プロファイルごとに1つのノード(<appsrv_host>Node#)を作成します。

1. 管理対象アプリケーション・サーバー・プロファイルを作成します。
プロファイルを格納するサーバーの<WAS_home>/binディレクトリから、次のコマンドを実行します。

./manageprofiles.sh -create -profileName <appsrv_profile> -profilePath <WAS_home>/profiles/<appsrv_profile> -templatePath <WAS_home>/profileTemplates/managed -isDefault

2. スタンドアロン・アプリケーション・サーバー・プロファイルを作成します。

./manageprofiles.sh -create -profileName <appsrv_profile> -profilePath <WAS_home>/profiles/<appsrv_profile> -templatePath <WAS_home>/profileTemplates/default -isDefault

注意:

これらのプロファイルに使用されるポートは、サーバー上の既存のアプリケーション・サーバー・プロファイルに基づいた、次に使用可能なポートのセットになります。

5. デプロイメント・マネージャでアプリケーション・サーバー・プロファイルをフェデレートします。
次のコマンドは、アプリケーション・サーバー・プロファイルのノードを、デプロイメント・マネージャによって管理されているセルと関連付けます。ステップ3で作成したアプリケーション・サーバー・プロファイルごとに、プロファイルが格納されるサーバーの<WAS_home>/binディレクトリから次のコマンドを実行します。

./addNode.sh <dmgr_host> <dmgr_soap_port> -profileName <appsrv_profile>

注意:

<dmgr_soap_port>のデフォルト値は8879です。

6. ノード・エージェントを起動します。
アプリケーション・サーバー・プロファイルごとに、このプロファイルが配置されているサーバーから次のコマンドを実行します。

<WAS_home>/bin/startNode.sh -profileName <appsrv_profile>

5.2.2 クラスタの作成

クラスタ環境では、すべてのWebSphereサーバーはクラスタに属しており、サーバー間の通信はアプリケーション・サーバーによって管理されます。

1. WebSphere Integrated Solutions管理コンソールにログインします。

http://<dmgr_host>:<dmgr_port>/admin

デフォルト・デプロイメント・マネージャ・ポートは9060です。

2. 左側のツリーで、「Servers」→「Clusters」を開き、「WebSphere」アプリケーション・サーバー・クラスタをクリックします。

3. クラスタを作成します。

1. 「新規」をクリックします。

2. クラスタ名を入力します。

3. セッション永続性を使用する環境の場合は、「Configure HTTP session memory-to-memory replication」を選択します。

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

5. クラスタ・メンバー・サーバーを作成します。
アプリケーション・サーバー・クラスタ・メンバーごとに次の手順を繰り返します。

1. クラスタ・メンバーの名前を入力します。

2. クラスタ・メンバーが配置されるノードを選択します。

3. 最初のクラスタ・メンバーの場合は「Next」を、それ以外の場合は「Add Member」をクリックします。

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

6. 「終了」をクリックします。

4. 変更を保存します。

5.2.3 サーバーの作成

クラスタ化されていない環境では、次の手順でサーバーを作成します。

1. 管理コンソールから、「Servers」→「Server Types」を開き、「WebSphere application servers」をクリックします。

2. サーバーを作成します。

環境内のアプリケーション・サーバーごとに次の手順を繰り返します。

1. 「新規」をクリックします。

2. サーバーが配置されるノードを選択します。

3. サーバー名を入力します。

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

5. デフォルト・テンプレートを選択し、「Next」をクリックします。

6. 「Generate Unique Ports」を選択し、「Next」をクリックします。

7. 「終了」をクリックします。

8. 新規作成したサーバーをクリックします。

9. 「Communications」の下の「Ports」を開きます。

10. 次のポートを書き留めます(それらは、後で仮想ホストに追加されます)。

- WC_defaulthost

- WC_defaulthost_secure

- SIP_DEFAULTHOST

- SIP_DEFAULTHOST_SECURE

3. 変更を保存します。

5.2.4 サーバーの構成

この項では、次の手順を完了します。

- 第5.2.4.1項「Webコンテナ・プロパティの構成」

- 第5.2.4.2項「セッション管理の構成」

- 第5.2.4.3項「クラスパスとJavaオプションの設定」

5.2.4.1 Webコンテナ・プロパティの構成

この項では、WebCenter Sitesに必要なWebコンテナ・プロパティの構成方法を説明します。

1. 管理コンソールから、「Servers」→「Server Types」を開き、「WebSphere application servers」をクリックします。

2. Webコンテナ・プロパティを追加します。
アプリケーション・サーバーごとに、次の手順を完了します。

1. サーバーを選択し、「Web Container Settings」ノードを開きます。

2. 左側のペインで、「Servers」→「Server Types」を開き、「Application Servers」をクリックします。
構成されているサーバーのリストが表示されます。

3. WebCenter Sitesのために作成したアプリケーション・サーバー・インスタンスを選択し(たとえば、server1を選択)、「Web Container Settings」ノードを開きます(図5-1)。

図5-1 「Web Container Settings」ノード

4. 「Web Container Settings」ノードの下で、「Web container」をクリックします。

5. 「Web container」ノードの下で、「Custom Properties」→「New」をクリックします(図5-2)。

- 「Name」フィールドに、NoAdditionalSessionInfoと入力します。

- 「値」フィールドに、trueと入力します。

図5-2 カスタム・プロパティ

6. 「Save」をクリックします。すべてのノードに変更を同期します(図5-3)。

7. 次のステップeおよびfによって、次の2つのプロパティが追加されます。

com.ibm.ws.webcontainer.initFilterBeforeInitServlet=true
com.ibm.ws.webcontainer.invokeFilterInitAtStartup=true

Webコンテナ・プロパティは、図5-3に似たものになります。

図5-3 Webコンテナ・プロパティ

5.2.4.2 セッション管理の構成

この項では、WebCenter Sitesに必要なセッション管理プロパティの構成方法を説明します。

1. 管理コンソールから、「Servers」→「Server Types」を開き、「WebSphere application servers」をクリックします。

2. セッション管理プロパティを構成します。
アプリケーション・サーバーごとに、次の手順を完了します。

1. サーバーをクリックし、「Container Settings」の下で「Session management」をクリックします。

2. 「General Properties」の下の「Enable cookies」をクリックします(図5-4)。

図5-4 セッション・トラッキング・メカニズム: Cookieの有効化

3. 「Set session cookies to HTTPOnly to help prevent cross-sites scripting」チェック・ボックスを選択解除します(図5-5)。
これは、WebCenter Sites管理インタフェースでツリー・アプレットを実行するために必要です。

図5-5 Cookie設定の指定

4. 「Cookie path」に対して、「Use the context root」を選択します(図5-6)。

図5-6 Cookieパスの設定

5. 「Apply」→「OK」をクリックし、変更を保存します。

6. 「Additional Properties」の下の「Custom properties」をクリックします。

7. 「新規」をクリックします。

8. 「Name」フィールドにHttpSessionCloneIdと入力します。

9. 「Value」フィールドに、8または9個の英数字IDを入力します(図5-7)。クラスタ環境では、このIDは、セッションが存在しているクラスタ・メンバーの識別に使用されます。このIDは、すべてのクラスタ・メンバーで一意であることが必要です。

図5-7 HttpSessionCloneId

10. 「OK」をクリックし、変更を保存します。

5.2.4.3 クラスパスとJavaオプションの設定

この項では、メモリー引数の設定およびWebCenter Sitesに必要なJavaオプションの追加方法について説明します。

1. 管理コンソールから、「Servers」→「Server Types」を開き、「WebSphere application servers」をクリックします。

2. クラスパスとJavaオプションの設定
アプリケーション・サーバーごとに、次の手順を完了します。

1. サーバーをクリックし、「Server Infrastructure」の下の「Java and Process Management」を展開し、「Process definition」をクリックします(図5-8)。

図5-8 Javaおよびプロセス管理 - プロセス定義

2. 「Additional Properties」の下の「Java Virtual Machine」をクリックします。

3. クラスパスを設定します。
「Classpath」の下のボックスに、次のパスを入力します。<sites_install_dir>/bin

4. 「Memory Arguments」を設定します。

- 「Initial heap size」の下のボックスに値を入力します。推奨値は512です。

- 「Maximum heap size」の下のボックスに値を入力します。推奨値は2048です。

5. Javaオプションを設定します。
「Generic JVM arguments」の下のボックスに、空白で区切って、次のJavaオプションを追加します。

- -Dfile.encoding=UTF-8
このオプションによってUTF-8ファイル・エンコーディングが指定されます。

- -Dclient.encoding.override=UTF-8
このオプションによってUTF-8 URIエンコーディングが指定されます。

- -Dnet.sf.ehcache.enableShutdownHook=true
このオプションによって、Ehcache停止フックが有効化されます。

- -Djava.net.preferIPv4Stack=true
このオプションで、IPv4アドレスの使用が指定されます。

- -Duser.timezone=UTC
このオプションは、JVMのタイムゾーンの設定に使用されます。すべてのWebCenter Sitesインストールで、この値をUTCに設定することをお薦めします。ただし、この値がすべてのWebCenter Sitesインストールで同一であるかぎり、任意のタイムゾーンを使用できます。

- -Djava.io.tmpdir=<path_to_sites_tmpdir>
このオプションは、JVMがどの一時ディレクトリを使用するのかを指定します。この値(図5-9) は、第2.1項「始める前に」で作成したディレクトリのパスにする必要があります。

注意:

Shift-JIS文字を使用する場合は、-Dcs.useJavaURLDecoder=falseオプションを追加します。

図5-9 汎用JVM引数

6. 「OK」をクリックし、変更を保存します。

5.2.5 仮想ホストのホスト別名の作成

この項では、作成した新規サーバーの仮想ホストにホスト別名を追加する方法を説明します。

1. 管理コンソールから「Environment」を開き、「Virtual hosts」をクリックします。

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

3. 「Additional Properties」の下の「Host Aliases」をクリックします。

4. 第5.2.3項「サーバーの作成」のステップ2で書き留めたポートのリストと、既存のホスト別名を比較します。ホスト別名がない一意のポートそれぞれに、次のように実行します。

1. 「新規」をクリックします。

2. 「Host Name」に対して、*を入力します。

3. 「Port」に対して、ポート番号を入力します。

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

5. 変更を保存します。

5.2.6 データベース通信のためのWAS環境の構成

この項では、WebCenter Sitesのデータベースと通信するようにWAS環境を構成する方法を説明します。

- 第5.2.6.1項「J2C認証データの作成」

- 第5.2.6.2項「JDBCプロバイダの作成」

- 第5.2.6.3項「データ・ソースの作成」

5.2.6.1 J2C認証データの作成

J2C認証データは、JDBC接続などの接続を保護するために使用できるアイデンティティとパスワードのリストです。

1. 管理コンソールから、「Security」を開き、「Global Security」をクリックします(図5-10)。

図5-10 「Security」ノード

2. 「Authentication」の下の「Java Authentication and Authorization」を展開し、「J2C authentication data」をクリックします。

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

4. J2C認証データを作成します(図5-11)。

1. 「Alias」に対して、このユーザーIDとパスワードのペアの一意の別名を入力します。

2. 「User ID」および「Password」に対して、WebCenter Sitesデータベースへの接続に使用されるユーザーの情報を入力します。

図5-11 JAAS – J2C認証データ

3. 「OK」をクリックし、変更を保存します。

5.2.6.2 JDBCプロバイダの作成

JDBCプロバイダは、特定のJDBCドライバ実装を使用するすべてのデータ・ソースをカプセル化します。クラスタ環境では、すべてのサーバーが同じJDBCプロバイダを共有します。クラスタ化されていない環境では、プロバイダをサーバーごとに作成する必要があります。

1. データベース・タイプに対応するデータベース・ドライバJARファイルを<WAS_home>/universalDriver/libディレクトリにコピーします。

- DB2の場合:

- db2jcc.jar

- db2jcc_license_cu.jar

注意:

db2jcc4.jarはサポートされていません。

- Oracleの場合: ojdbc6.jar

- MS SQL Serverの場合: jtds-1.2.5.jar

2. 管理コンソールから、「Resources」→「JDBC」を開き、「JDBC providers」をクリックします。

3. プロバイダがクラスタ環境用である場合は、「Scope」の下で、ドロップダウン・メニューから「Cluster=<cluster_name>」を選択します。プロバイダが非クラスタ環境用である場合は、「Scope」の下で、「Node=<appsrv_node>, Server=<server_name>」を選択します。

4. 「新規」をクリックします。

5. 「Create a new JDBC provider」画面で、次のことを完了します(図5-12)。

1. 「Database type」に対して、「DB2」、「Oracl」または「User-defined」(MS SQL Serverを使用する場合)を選択します。

2. 「Provider type」に対して、「DB2 Universal JDBC Driver Provider」(DB2の場合)または「Oracle JDBC Driver」(Oracleの場合)を選択しますMS SQL Serverを使用する場合、このドロップダウンは表示されません。

3. 「Implementation type」に対して、OracleまたはDB2を使用する場合は、「Connection pool data source」を選択します。MS SQL Serverを使用する場合は、net.sourceforge.jtds.jdbcx.JtdsDataSourceと入力します。

4. 「Name」に対して、JDBCプロバイダの名前を入力します。

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

図5-12 接続プール・データ・ソース

6. 「Enter database class path information」画面(図5-13)で、次のうちの1つを実行します。
Oracle:

1. ${ORACLE_JDBC_DRIVER_PATH}の値に対して、ステップ1でコピーしたojdb6.jarファイルの場所を入力します。

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

DB2:

1. 「Class path」の下で、${UNIVERSAL_JDBC_DRIVER_PATH}を${DB2UNIVERSAL_JDBC_DRIVER_PATH}に置き換え、db2jcc_license_cisuz.jarが含まれている行を削除します。

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

3. ${DB2UNIVERSAL_JDBC_DRIVER_PATH}の値に対して、ステップ1でコピーしたdb2cc.jarおよびdb2jcc_license_cu.jarファイルの場所を入力します。

図5-13 データベース・クラス・パス情報

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

MS SQL Server: 「Class path」の下で、既存の行を削除し、次のステップ1でコピーしたjtds-1.2.5.jarファイルのパスを追加します。<WAS_home>/universalDriver/lib/jtds-1.2.5.jar

7. 「Summary」画面(図5-14)で、選択した設定を確認し、「Finish」をクリックします。

図5-14 「Summary」

8. 変更を保存します。

5.2.6.3 データ・ソースの作成

1. 管理コンソールから、「Resources」→「JDBC」を開き、「Data sources」をクリックします。

2. データ・ソースがクラスタ環境用である場合は、「Scope」の下で、ドロップダウン・メニューから「Cluster=<cluster_name>」を選択します。データ・ソースが非クラスタ環境用である場合は、「Scope」の下で、「Node=<appsrv_node>, Server=<server_name>」を選択します。

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

4. 「Enter basic data source information」画面(図5-15)で、次のように実行します。

1. 「Data source name」フィールドに、このデータ・ソースの一意の名前を入力します。

2. 「JNDI name」フィールドに、このデータ・ソースのJNDI名を入力します。

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

図5-15 基本データ・ソース情報

4. 「Select an existing JDBC provider」を選択します(図5-16)。

5. ドロップダウン・リストで、第5.2.6.2項「JDBCプロバイダの作成」で作成したJDBCプロバイダを選択します。

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

図5-16 既存のJDBCプロバイダ

5. 「Enter database-specific properties for the data source」画面(図5-17)で、次のように実行します。

- ステップeでDB2 JDBCプロバイダを選択した場合、次のように実行します。

1. 「Database name」フィールドに、WebCenter Sitesによって使用されるデータベースの名前を入力します。

2. 「Driver type」ドロップダウン・リストで、「4」を選択します。

3. 「Server name」フィールドに、WebCenter Sitesデータベースを実行しているマシンのホスト名またはIPアドレスを入力します。

4. 「Port number」フィールドに、WebCenter Sitesデータベースが接続をリスニングするポート番号を入力します。

5. 「Use this data source in container managed persistence (CMP)」チェック・ボックスを選択します。

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

図5-17 データ・ソースのデータベース固有のプロパティ

- ステップeで、Oracle JDBCプロバイダを選択した場合、次のように実行します。

1. 「URL」フィールドに、WebCenter Sitesによって使用されるデータベースのURLを入力します。URLは次の書式で入力する必要があります。

jdbc:oracle:thin:@//<db_host>:<db_port>/<db_name>

説明:

- <db_host>は、WebCenter Sitesデータベースを実行しているマシンのホスト名またはIPアドレスです。

- <db_port>は、WebCenter Sitesデータベースが接続をリスニングするポート番号です。

- <db_name> は、WebCenter Sitesデータベースの名前です。

2. 「Data store helper class name」ドロップダウン・リストで、「Oracle11g data store helper」を選択します。

3. 「Use this data source in container managed persistence (CMP)」チェック・ボックスを選択します。

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

- ステップeで、SQL Serverプロバイダを選択した場合、次のように実行します。

1. 「Database name」フィールドに、WebCenter Sitesによって使用されるデータベースの名前を入力します。

2. 「Server name」フィールドに、WebCenter Sitesデータベースを実行しているマシンのホスト名またはIPアドレスを入力します。

3. 「Port number」フィールドに、WebCenter Sitesデータベースが接続をリスニングするポート番号を入力します。

4. 「Use this data source in container managed persistence (CMP)」チェック・ボックスを選択します。

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

6. 「Component-managed authentication alias」ドロップダウン・リスト(図5-18)で、第5.2.6.1項「J2C認証データの作成」で作成したJ2C認証を選択し、「Next」をクリックします。

図5-18 「Component-Managed Authentication Alias」

ステップeで、SQL Serverプロバイダを選択した場合、次のように実行します。

1. 「Data store helper class name」は、デフォルト・クラスのままにします。

2. 「Use this data source in container managed persistence (CMP)」チェック・ボックスを選択します。

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

7. 変更を保存します。

8. データ・ソースのリストで、直前に作成したデータ・ソースを選択します。

9. 「Data source」画面の「Additional Properties」領域で、「Connection pool properties」をクリックします。

10. 「Connection pools」画面(図5-19)で、次のように実行します。

1. 「Maximum connections」フィールドに、100 (または、自身の構成に適した値がわかっている場合はその値)を入力します。

2. 「Minimum connections」フィールドに、10 (または、自身の構成に適した値がわかっている場合はその値)を入力します。

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

図5-19 「Connection Pools」

11. 変更を保存します。

12. DB2を実行しているインストールの場合(図5-20):

1. データ・ソースのリストで、直前に作成したデータ・ソースを選択します。

2. 「Data source」画面の「Additional Properties」領域で、「Custom properties」をクリックします。

3. 「Custom properties」画面で、「resultSetHoldability」をクリックします。

図5-20 resultSetHoldability

4. 「Value」フィールドに、1を入力します(図5-21)。「OK」をクリックします。

図5-21 resultSetHoldabilityの値

5. 「新規」をクリックします。

6. 「Name」に「allowNextOnExhaustedResultSet」と入力し、「Value」に「1」と入力します。「OK」をクリックします。

7. 「新規」をクリックします。

8. 「Name」に「allowNullResultSetForExecuteQuery」と入力し、「Value」に「1」と入力します。「OK」をクリックします。

9. 「Messages」ボックスで、「Review」をクリックします。

10. 「Save」画面で、次のように実行します。

1. 「Synchronize changes with nodes」チェック・ボックスを選択します。

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

13. 変更を保存します。

5.3 ステップ2: WebSphere Application ServerとサポートされているWebサーバーとの統合

この項では、IBM WebSphere Application Server用のWebサーバー・プラグインを使用してWASをIBM HTTP ServerまたはApache 2.2.x Webサーバーと統合する方法を説明します。WebサーバーおよびWebサーバー・プラグインがインストールされたら、次の手順を実行します。

1. Webサーバー構成スクリプトをコピーして実行します。
Webサーバー・プラグイン・インストーラによって構成スクリプト<plugin_home>/bin/configure<web_server_name>.shが作成され、それを使用してWebサーバーがデプロイメント・マネージャに追加され、管理コンソールで管理できるようになります。

このファイルを、デプロイメント・マネージャが実行されている(すでに実行されていない場合は起動します)プライマリ・サーバーの<WAS_home>/binディレクトリにコピーし、そのスクリプトを実行します。

2. プラグイン構成を生成し、伝播します。
管理コンソールから、WAS環境に基づいてプラグイン構成ファイルを生成できます。

1. 管理コンソールの左側で、「Server Types」を開き、「Web servers」をクリックします。
スクリプトを使用して追加したWebサーバーが表示されます(図5-22)。

図5-22 Webサーバー

2. Webサーバーをクリックし、「Plug-in properties」をクリックします。
「Plug-in properties」画面が表示されます(図5-23)。

図5-23 「Plug-In Properties」

3. プラグイン構成ファイルを表示するには、plugin-cfg.xmlの横にある「View」をクリックします(図5-23)。クラスタ環境では、ファイルは図5-24のようなものになります。
「Plug-in properties」画面で、プラグイン構成ファイルの自動生成および伝播を無効化し、ログ・ファイル・レベルを変更します。

WebCenter SitesおよびCAS Webアプリケーションをインストールおよびデプロイした後、プラグイン構成ファイルを再生成および再伝播します。

図5-24 プラグイン構成ファイル

4. プラグインを手動で生成および伝播するには、「Web servers」画面に移動し、構成するWebサーバーを選択し、「Generate Plug-in」をクリックします。

5. プラグインの生成に成功したら、構成するWebサーバーを選択し、「Propagate Plug-in」をクリックします。

6 WebCenter Sitesのインストール手順

この章は、WebCenter Sitesのインストール、アプリケーション・サーバーへのデプロイおよびデータベースへの接続のガイドラインを示します。

この章の内容は、次のとおりです。

- 第6.1項「WebCenter Sitesのインストール・プロセスの概要」

- 第6.2項「インストール・オプション」

- 第6.3項「WebCenter Sitesアプリケーションのインストール」

- 第6.4項「中間点での構成変更」

- 第6.5項「WebCenter SitesおよびCAS Webアプリケーションのデプロイ」

- 第6.6項「WebCenter Sitesの再起動」

- 第6.7項「WebLogic Application Serverの本番モードへの切替え(配信システムのみ)」

注意:

この章の手順を開始する前に、第2章「WebCenter Sitesをインストールするための前提条件」で説明した前提条件の手順を完了していることと、次の章の1つの説明に従ってアプリケーション・サーバーを構成済であることを確認してください。

- 第3章「Oracle WebLogic Application ServerにWebCenter Sitesをインストールするための準備」

- 第4章「Apache Tomcat Application ServerにWebCenter Sitesをインストールするための準備」

- 第5章「IBM WebSphere Application ServerにWebCenter Sitesをインストールするための準備」

6.1 WebCenter Sitesのインストール・プロセスの概要

すべてのアプリケーション・サーバーを構成し、必要に応じてWebサーバーと統合すると、WebCenter Sitesをインストールする準備が整います。複数サーバー環境では、1つのサーバーがプライマリ・サーバーとして指定され、すべての他のサーバーはセカンダリとして指定されます。各サーバーにインストーラをコピーして実行する必要があり、サーバー・タイプに応じて様々なインストール・アクションが必要です。インストーラの実行は、次の2つのステージで構成されています。

1. 最初のステージでは、インストーラは必要な構成情報を収集し、ファイル構造をインストールします。最初のステージの終わりに、WebCenter Sitesをデプロイするように求める「インストール・アクション」ウィンドウが表示されます。サイレント・インストールでは、これらの手順はコマンドラインに表示されます。これらの手順には、WebCenter Sitesアプリケーションのデプロイメントが含まれています。
最初のステージに失敗した場合、前に戻って構成オプション(データベース・タイプは除く)を変更し、インストールを再試行できます。

注意:

インストール中に指定したデータベースのタイプを変更する必要がある場合は、インストール済WebCenter Sitesファイル構造を削除してからWebCenter Sitesのインストールを再開する必要があります。

2. 2番目のステージでは、データベースに、WebCenter Sitesが機能するために必要な表およびデータが移入されます。2番目のステージに失敗した場合、データベース表を削除し、WebCenter Sitesアプリケーションをアンデプロイし、WebCenter Sitesファイル構造を削除して、WebCenter Sitesを再インストールする必要があります。

6.2 インストール・オプション

この項では、WebCenter Sitesインストーラを実行する方法を説明します。この手順は、プライマリ・サーバーおよびすべてのセカンダリ・サーバーで完了する必要があります。

- GUIインストーラの実行
GUIインストーラを実行すると、グラフィカル・インタフェースによってインストール・プロセスの手順が示され、必要に応じて情報を入力し、オプションを選択するように求められます。また、オンライン・ヘルプにアクセスすることもできます。

- サイレント・インストール
サイレント・インストールを行うには、最初に、GUIインストーラを設定のサマリー画面まで実行してから終了することでomii.iniファイルを生成します。サイレント・インストーラは、このファイルを使用してWebCenter Sitesをインストールします。

WebアプリケーションとしてのWebCenter Sitesのインストール手順は、第6.3項「WebCenter Sitesアプリケーションのインストール」を参照してください。

6.3 WebCenter Sitesアプリケーションのインストール

注意:

この項の手順を開始する前に、次の手順を完了していることを確認します。

- 次に示すご使用のアプリケーション・サーバーに対応した章の説明に従って、WebCenter Sites用のアプリケーション・サーバーを構成した。第3.2項「ステップ1: WebLogic Application Serverの構成」、第4.2項「ステップ1: Tomcat Application Serverの構成」または第5.2項「ステップ1: WebSphere Application Serverの構成」。

- 必要に応じて、第3.3項「ステップ2: Oracle WebLogic ServerとサポートされているWebサーバーとの統合」 第4.3項「ステップ2: Tomcat Application ServerとサポートされているWebサーバーとの統合」または第5.3項「ステップ2: WebSphere Application ServerとサポートされているWebサーバーとの統合」の説明に従って、アプリケーション・サーバーをサポートされているWebサーバーと統合した。

WebCenter Sitesサイレント・インストーラには、CASのインストールが含まれています。デフォルトでは、CASはプライマリ・サーバーにインストールされます。

この項の内容は、次のとおりです。

- 第6.3.1項「GUIインストーラの実行」

- 第6.3.2項「サイレント・インストール」

6.3.1 GUIインストーラの実行

GUIインストーラを使用してWebCenter Sitesをインストールする手順は、次のとおりです。

1. WebCenter Sitesインストーラ・アーカイブを一時ディレクトリに抽出します。

2. インストーラ・ファイルが含まれている一時ディレクトリに変更します。

3. 次のインストーラ・スクリプトを実行します。

- Windowsの場合: csInstall.bat

- UNIXの場合: csInstall.sh

インストーラは、各画面にオンライン・ヘルプを備えています。各画面に表示されるオプションの詳細な説明は、オンライン・ヘルプをお読みください。インストール・プロセス中に問題が発生した場合は、考えられる原因および解決策についてオンライン・ヘルプを参照してください。

4. 単一サーバー環境、または複数サーバー環境のプライマリ・サーバーにインストールしている場合は、「クラスタリング」画面で、単一サーバーを選択します。複数サーバー環境のセカンダリ・サーバーにインストールしている場合は、「クラスタ・メンバー」を選択します。

注意:

すべてのCASインスタンスが同じクラスタ内にある場合を除いて、CASのクラスタリング設定(mcast_addr、mcast_port、ClusterNameなど)は一意である必要があります。つまり、これらの設定は、同じマシン上で実行されている他のどのCASインスタンスの設定とも異なる必要があります。

5. Enter CAS Deployment information画面で、次のうちの1つを実行します。

- ファイアウォールが配置されているネットワークの場合は、フィールドに次のように入力します。

- サーバー・ホスト名の入力: CASサーバーのホスト名またはIPアドレスを、外部ネットワークから参照されるとおりに入力します。CASをクラスタ化している場合は、外部に面しているロード・バランサのホスト名またはIPアドレスを入力します。

- サーバー・ポート番号の入力: CASサーバーのポート番号を、外部ネットワークから参照されるとおりに入力します。CASをクラスタ化している場合は、外部に面しているロード・バランサのポート番号を入力します。

- 内部からアクセス可能なCASのサーバー・ホスト名の入力: CASサーバーのホスト名またはIPアドレスを、内部ネットワークで参照されるとおりに入力します。CASをクラスタ化している場合、ロード・バランサのホスト名またはIPアドレスを、内部ネットワークで参照されるとおりに入力します。

- 内部からアクセス可能なCASのサーバー・ポート番号の入力: CASサーバーのポート番号を、内部ネットワークで参照されるとおりに入力します。CASをクラスタ化している場合、ロード・バランサのホスト名またはIPアドレスを、内部ネットワークで参照されるとおりに入力します。

- CASが実際にデプロイされているサーバー・ホスト名の入力: CASがデプロイされるマシンのホスト名を入力します。

- ファイアウォールが配置されていないネットワークの場合は(図6-1)、フィールドに次のように入力します。

- サーバー・ホスト名の入力: CASサーバーのホスト名またはIPアドレスを入力します。CASをクラスタ化している場合は、ロード・バランサのホスト名またはIPアドレスを入力します。

- サーバー・ポート番号の入力: CASサーバーのポート番号を入力します。CASをクラスタ化している場合は、ロード・バランサのポート番号を入力します。

- 内部からアクセス可能なCASのサーバー・ホスト名の入力: CASサーバーのホスト名またはIPアドレスを入力します。CASをクラスタ化している場合は、ロード・バランサのホスト名またはIPアドレスを入力します。

- 内部からアクセス可能なCASのサーバー・ポート番号の入力: CASサーバーのポート番号を入力します。CASをクラスタ化している場合は、ロード・バランサのポート番号を入力します。

- CASが実際にインストールされているサーバー・ホスト名の入力: CASがデプロイされるマシンのホスト名を入力します。

図6-1 CASのデプロイメント情報

6. 設定のサマリー画面で、GUIインストーラを使用してomii.iniファイルを生成している場合は「終了」をクリックし、それ以外の場合は「次へ」をクリックします。

7. インストールの途中で、「インストール・アクション」ウィンドウが表示され、インストールを完了するために実行する必要がある手順がリストされます。次のように実行します。

1. 第6.4項「中間点での構成変更」の説明に従って、必要な構成変更を完了します。

2. WebCenter SitesおよびCAS Webアプリケーションをデプロイします。手順は、ご使用のアプリケーション・サーバーに応じて、次の項の1つを参照してください。

- 第6.5.1項「WebLogic ServerへのWebCenter SitesおよびCASのデプロイ」

- 第6.5.2項「WebSphereへのWebCenter SitesおよびCASのデプロイ」

- 第6.5.3項「TomcatへのWebCenter SitesおよびCASのデプロイ」

3. アプリケーション・サーバーを起動します。

注意:

複数サーバー環境では、インストーラが実行されたアプリケーション・サーバーのみが実行されており、すべての他のサーバーは停止している必要があります。

4. 「テスト」をクリックし、すべてのテストが正常に終了した場合は、「OK」をクリックしてインストールを続行します。

8. インストール・プロセスが正常に完了したら、次のように実行します。

1. すべてのインストールの場合、第6.6項「WebCenter Sitesの再起動」に進みます。

注意:

WebCenter SitesをWebLogic Serverにデプロイした場合は、第6.7項「WebLogic Application Serverの本番モードへの切替え(配信システムのみ)」の手順も完了します。

2. すべてのインストールの場合、第7章「WebCenter Sitesのインストール後の手順」のインストール後の手順を完了することでフォローアップします。

6.3.2 サイレント・インストール

1. 第6.3.1項「GUIインストーラの実行」の手順1から6に従うことで、GUIインストーラを使用してomii.iniファイルを生成します。

注意:

これを実行する必要があるのは環境ごとに1回のみです。最初のもの後の追加の各サーバーに対して、ポートおよびパスに必要な変更を行った後に同じomii.iniファイルを使用できます。セカンダリ・サーバーにサイレント・インストールする場合は、次のプロパティが設定されていることを確認してください。

- - CSInstallType=cluster

- - IsPrimaryClusterMember=false

2. omii.iniファイルを<sites_install_dir>の外にあるフォルダにコピーし、GUIインストーラによって作成されたファイルをすべて消去します。

3. 配信システムをインストールしている場合は、fwadminおよびContentServer/SatelliteServerユーザーに一意のパスワードを設定する必要があります。

1. 一時ディレクトリのContentServerフォルダ内のcscore.xmlファイルを開きます。

2. 次のセクションで、パスワードを設定します。

<IF COND="Variables.bShowInstallTypeDialog=false">
<THEN>
<DIALOGACTION>
<SETVARIABLE NAME="passwordVar" VALUE=" "/>
<SETVARIABLE NAME="passwordAdminVar" VALUE=" "/>
</DIALOGACTION>
</THEN>
</IF>

1. NAME="passwordVar"の後のVALUEフィールドにfwadminユーザーのパスワードを設定します。

2. NAME="passwordAdminVar"の後のVALUEフィールドにContentServer/SatteliteServerユーザーのパスワードを設定します。

3. ファイルを保存して閉じます。

4. 一時ディレクトリのrootフォルダ内のinstall.iniファイルを編集します。

1. nodisplayプロパティをtrueに設定します。

2. loadfileプロパティを非コメント化し、それを、ステップ2のomii.iniファイルのパスおよび名前に設定します。

注意:

ファイル・システム・パスを適切に指定したことを確認します。Windowsの場合:

CSInstallDirectory=C\:/csinstall

- or -

c\:\\install

3. ファイルを保存して閉じます。

5. インストーラ・ファイルが含まれている一時ディレクトリに変更します。

6. 次のインストーラ・スクリプトを実行します。

- Windowsの場合: csInstall.bat -silent

- UNIXの場合: csInstall.sh -silent

7. インストールの途中で、インストールを完了するために実行する必要がある手順を示すプロンプトが出力されます。次のように実行します。

1. 第6.4項「中間点での構成変更」の説明に従って、必要な構成変更を完了します。

2. WebCenter SitesおよびCAS Webアプリケーションをデプロイします。手順は、ご使用のアプリケーション・サーバーに応じて、次の項の1つを参照してください。

- 第6.5.1項「WebLogic ServerへのWebCenter SitesおよびCASのデプロイ」

- 第6.5.2項「WebSphereへのWebCenter SitesおよびCASのデプロイ」

- 第6.5.3項「TomcatへのWebCenter SitesおよびCASのデプロイ」

3. アプリケーション・サーバーを起動します。

注意:

複数サーバー環境では、インストーラが実行されたアプリケーション・サーバーのみが実行されており、すべての他のサーバーは停止している必要があります。

4. インストーラでWebCenter Sites Webアプリケーションに対して指定したホスト名、コンテキスト・ルートおよびポートを使用して、ブラウザで次のURLを開きます。

- http://<hostname>:<port>/<context_root>/HelloCS

- http://<hostname>:<port>/<context_root>/CatalogManager?ftcmd=pingdb

テストに成功した場合は、インストーラを実行したウィンドウで[Enter]キーを押して、インストールを続行します。

6.4 中間点での構成変更

この項では、デプロイメントの前に、WebCenter Sitesインストーラの途中で必要な手順を説明します。

注意:

マルチキャスト・パケットの伝播を制御する存続時間の値を設定する場合は、通信するサーバー間の距離に基づいて、次の値の1つを使用します。

- 0 (ローカル・サーバーに限定されるマルチキャスト・パケット)

- 1 (同じサブネットに限定されるマルチキャスト・パケット)

- 32 (同じリージョンに限定されるマルチキャスト・パケット)

- 64 (同じ大陸に限定されるマルチキャスト・パケット)

- 255 (制限のないマルチキャスト・パケット)

この項には、次が含まれます。

- 第6.4.1項「CASファイルのコピー」

- 第6.4.2項「CASファイルの変更」

- 第6.4.3項「Webアプリケーション・ファイルの変更」

6.4.1 CASファイルのコピー

第6.3.1項「GUIインストーラの実行」のステップ4で単一サーバーを選択しており、かつWebCenter Sites Webアプリケーションがインストールされているもの以外の物理サーバーにCAS Webアプリケーションをデプロイする場合、次のファイルを<sites_install_dir>/binディレクトリから、それらのサーバー上の場所にコピーします。この場所は、CASがデプロイされるアプリケーション・サーバーのパス内にする必要があります。

第6.3.1項「GUIインストーラの実行」のステップ4でクラスタ・メンバーを選択した場合、次のファイルをプライマリ・サーバーの<sites_install_dir>/binディレクトリから、セカンダリ・サーバーの<sites_install_dir>/binディレクトリにコピーします。

- host.properties

- cas.properties

- jbossTicketCacheReplicationConfig.xml

6.4.2 CASファイルの変更

第6.3.1項「GUIインストーラの実行」のステップ4で単一サーバーを選択した場合、プライマリ・サーバー上で、さらに必要であればそのファイルがコピーされた他の物理サーバー上で、次のファイルを変更します(sitesinstall/binフォルダにある)。

第6.3.1項「GUIインストーラの実行」のステップ4で「クラスタ・メンバー」を選択した場合、セカンダリ・サーバー上で、次のファイルを変更します(sitesinstall/binフォルダにある)。

- host.properties
host.nameプロパティ、どのサーバーがチケットを生成したのかを識別するために使用されます。デフォルトでは、書式cas-<local_hostname>-<cluster_id>を使用します。この値の書式は変更可能ですが、すべてのサーバーで一意である必要があります。

- jbossTicketCacheReplicationConfig.xml
ファイルのClusterConfigセクションで、UDPタグの次の属性を変更します。

- mcast_addr
複数CASサーバー環境では、mcast_addrとmcast_portの組合せは、すべてのメンバーに対して同一であり、かつ他のCAS環境に対しては一意であることが必要です。

- mcast_port
複数CASサーバー環境では、mcast_addrとmcast_portの組合せは、すべてのメンバーに対して同一であり、かつ他のCAS環境に対しては一意であることが必要です。

- bind_addr
この値は、CASサーバーが実行される物理サーバーのホスト名またはIPアドレス(マルチホーム・サーバーの場合に必要)に設定します。

- ip_ttl
この存続時間の値は、前述の注意事項に基づいて設定します。

- customBeans.xml
customBeans.xmlファイルには、信頼できるURLのリストが含まれます。正常にログインしたビジターは、CASによってこのURLにリダイレクトされます。デフォルトでは、WebCenter Sites WebアプリケーションへのURLがこのファイルで指定されています。

WebCenter Sitesを他のWebCenter Sites Webアプリケーション(コミュニティ-ガジェットなど)と一緒にインストールした場合、これらのWebアプリケーションのURLもこのファイルでリストする必要があります。

例:

<bean id="customServiceValidator"
class="com.fatwire.cas.web.ServiceValidator">
<property name="validUrls">
<list>
.
<value>http://hostname:port/cs/wem/fatwire/wem/Welcome</value>
<value>http://hostIP:port/SitesWebapp/*</value>
<value>http://hostname:port/Community-GadgetsWebapp/*</value>
.
</list>
</property>

URLは次の形式でリストできます。

- 正確な比較用の完全なURLのリスト。例:

http://hostname:port/cs/wem/fatwire/wem/Welcome

指定されたURL(この例では、WebCenter Sitesの「ようこそ」ページ)にのみアクセスが許可されます。この形式では、サブ・リソースへのアクセスは許可されません。

- 最後に/*を入力することによるグループURLのリスト。例:

http://hostIP:port/SitesWebapp/*

WebCenter Sites Webアプリケーションの正確なURLであるhttp://hostIP:port/SitesWebappへのアクセスを含め、WebCenter Sites Webアプリケーション(SitesWebapp)の下にあるすべてのリソースへのアクセスが許可されます。

hostname:portおよびhostIP:portを相互に使用することで、WebCenter SitesとそのWebアプリケーションにアクセスする場合、これらのURLを両方ともcustomBeans.xmlファイルで指定する必要があります。

注意:

クラスタ化されたWebCenter Sites環境で作業する場合、ホスト名(またはホストIPアドレス)およびポート番号はロード・バランサを指している必要があります。

6.4.3 Webアプリケーション・ファイルの変更

複数サーバー環境の場合は、次のWebアプリケーション・ファイルを変更します。

注意:

WebSphere環境の場合は、変更を行う前に、<sites_install_dir>/ominstallinfo/appにあるWebCenter Sites .earファイルを、一時ディレクトリに開く必要があります。変更を行った後、.earファイルを再圧縮し、元のファイルを置き換えます。

TomcatおよびWebLogicの場合、WebCenter SitesおよびCAS .warファイルは、インストーラによってデプロイメント用にすでに開いています。

- キャッシュ・ファイル(cs-cache.xml、cas-cache.xml、ss-cache.xml、linked-cache.xml)
WebCenter Sites WebアプリケーションのWEB-INF/classesディレクトリ内のこれらのキャッシュ・ファイルを変更します。cacheManagerPeerProviderFactoryタグの次の属性に対して変更が必要です。

- multicastGroupAddress
multicastGroupAddressとmulticastGroupPortの組合せは、すべてのメンバーに対して同一であり、かつ他のWebCenter Sites環境に対しては一意であることが必要です。

- multicastGroupPort
multicastGroupAddressとmulticastGroupPortの組合せは、すべてのメンバーに対して同一であり、かつ他のWebCenter Sites環境に対しては一意であることが必要です。

- timeToLive
この存続時間の値は、次の注意事項に基づいて設定します。

注意:

multicastGroupPortプロパティは、クラスタ・メンバー全体に対して同一に設定する必要があります。たとえば、CS1のcs-cache.xmlファイル内でmulticastGroupPort=4444と指定されている場合、CS2とCS3でもそれぞれのファイル内で同じ設定を指定する必要があります。

timeToLiveプロパティは、1つのパケットに対して許可されるホップの数を指定するもので、これによってパケットの伝播距離が決まります。有効な値範囲は0から255の間で、次の制約があります。

- 0: 同一ホスト

- 1: 同一サブネット

- 32: 同一サイト

- 64: 同一範囲

- 128: 同一大陸

- 255: 無制限

- ブートストラップ(cas-cache.xmlの場合のみ)
クラスタ化されたCASを使用する際にノードを再起動すると、サーバー起動時に、隣接するノードからの既存のセッションとチケット情報をキャッシュに事前移入するオプションが表示されます。これは、再起動したノードにセッションがレプリケートされる場合など、ごくかぎられたケースで有効です。しかし、これにより、アプリケーション・サーバーの起動時間が長くなる場合があります。この機能は、デフォルトでは無効です。cas-cache.xmlで、次のコメント化されている行の後の行を非コメント化することで有効化できます。

<!-- Uncomment following lines to enable bootstrapping -->

3つのセクションのすべてでreplicateAsynchronously=trueを設定し、CASキャッシュを非同期に事前移入します。そうでない場合は、replicateAsynchronously=falseを設定します。replicateAsynchronously=trueを設定すると、競合状態が発生する可能性があるからです。

- (WebLogicのみ) weblogic.xml
WebLogicのURIエンコーディング文字セットを設定するには、WebCenter Sites WebアプリケーションのWEB-INFディレクトリのweblogic.xmlファイルで、weblogic-web-appエレメント内に次の行を追加します。

<charset-params>
<input-charset>
<resource-path>*</resource-path>
<java-charset-name>UTF-8</java-charset-name>
</input-charset>
</charset-params>

セッション永続性を有効化したWebLogicクラスタ環境を構成している場合は、WebCenter SitesおよびCAS WebアプリケーションのWEB-INFディレクトリのweblogic.xmlファイルを、session-descriptorエレメント内に次の行を追加することで変更します。<persistent-store-type>replicated</persistent-store-type>

- (Tomcatのみ) web.xml
Tomcatクラスタ環境を構成している場合は、WebCenter Sites WebアプリケーションのWEB-INFディレクトリのweb.xmlファイルを、web-appタグの後に最初の行として次のタグを追加することで変更します。<distributable/>

6.5 WebCenter SitesおよびCAS Webアプリケーションのデプロイ

この項の内容は、次のとおりです。

- 第6.5.1項「WebLogic ServerへのWebCenter SitesおよびCASのデプロイ」

- 第6.5.2項「WebSphereへのWebCenter SitesおよびCASのデプロイ」

- 第6.5.3項「TomcatへのWebCenter SitesおよびCASのデプロイ」

6.5.1 WebLogic ServerへのWebCenter SitesおよびCASのデプロイ

この項では、WebLogic Scripting Toolまたは管理コンソールを使用してWebLogicアプリケーション・サーバー上にWebCenter SitesおよびCAS Webアプリケーションをデプロイする方法を説明します。

この項の内容は、次のとおりです。

- 第6.5.1.1項「WebLogic Scripting Toolを使用したデプロイ」

- 第6.5.1.2項「WebLogic管理コンソールからのデプロイ」

6.5.1.1 WebLogic Scripting Toolを使用したデプロイ

WebLogic Scripting Toolは、管理対象WebLogicドメインに使用されるコマンドライン・スクリプト環境です。これは、管理サーバーが実行されていることを必要とします。このツールを使用して、次の手順に従うことでWebCenter SitesおよびCAS Webアプリケーションをデプロイできます。

注意:

クラスタ環境では、WebCenter SitesおよびCASアプリケーションのデプロイメントは、プライマリ・サーバーのインストールの途中で、1回のみ実行する必要があります。

1. Jythonスクリプトを作成します。
WLSTは、このスクリプト内に含まれているコマンドを実行して、アプリケーションをデプロイします。次のコマンドが含まれている新規.pyファイルを作成します。

注意:

connectコマンドの場合、WebLogic管理サーバーの情報を入力します。

deployコマンドの場合、インストーラで指定したアプリケーション名、開いているWebアプリケーションのパス、およびターゲット・サーバーまたはクラスタの名前を使用します。クラスタ環境では、クラスタの名前をターゲットとして使用します。

connect('<admin_user>', '<admin_password>', 't3://<admin_host>:<admin_port>')
deploy('<sites_application_name>', '<sites_deploy_home>', '<target>', 'nostage')
deploy('cas', '<cas_deploy_home>', '<target>', 'nostage')
disconnect()
exit()

2. WebLogic Scripting Toolを実行します。
アプリケーションをデプロイするには、次のコマンドを実行します。

<weblogic_home>/common/bin/wlst.sh <path_to_jython_script>

6.5.1.2 WebLogic管理コンソールからのデプロイ

この項では、WebLogic管理コンソールからWebLogicアプリケーション・サーバー上にSitesおよびCAS Webアプリケーションをデプロイする方法を説明します。次の手順を、各アプリケーションに対して完了します。

注意:

クラスタ環境では、WebCenter SitesおよびCASアプリケーションのデプロイメントは、プライマリ・サーバーのインストールの途中で、1回のみ実行する必要があります。

1. WebLogicサーバーの管理コンソールにログインします。

2. 次のようにWebアプリケーションをデプロイします(図6-2)。

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

2. 「インストール」ボタンをクリックします。必要に応じて、現在の場所を、WebCenter Sitesインストーラの手動デプロイメント画面で指定したパスに変更できます。

3. WebCenter Sites Webアプリケーションの指定した名前を持つディレクトリ(open directoryとマークされている)を選択し、「次へ」をクリックします。

図6-2 「アプリケーション・インストール・アシスタント」 - CS (open directory)

4. 「このデプロイメントをアプリケーションとしてインストールする」オプションを選択し(図6-3)、「次へ」をクリックします。

図6-3 アプリケーションとしてのこのデプロイメントのインストール

5. 「ソースのアクセス可能性」セクションで、「デプロイメントを次の場所からアクセス可能にする」を選択します(図6-4)。

図6-4 デプロイメントにアクセスする場所

6. 「次へ」をクリックし、「終了」をクリックします。

6.5.2 WebSphereへのWebCenter SitesおよびCASのデプロイ

この項では、WebSphere Integrated Solutions管理コンソールからWebSphere Application Server上にWebCenter SitesおよびCAS Webアプリケーションをデプロイする方法を説明します。各アプリケーションに対して次の手順を完了します。

注意:

クラスタ環境では、WebCenter SitesおよびCASアプリケーションのデプロイメントは、プライマリ・サーバーのインストールの途中で、1回のみ実行する必要があります。

1. WebSphere Integrated Solutions管理コンソールにログインします。

2. 左側のツリーで、「Applications」→「Application Types」を開き、「WebSphere enterprise applications」をクリックします(図6-5)。

図6-5 「WebSphere Enterprise Applications」

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

4. 「Preparing for the application installation」画面で、「Remote file system」を選択し、「Browse」をクリックします(図6-6)。

図6-6 「Remote File System」フィールド

5. 「Browse Remote Filesystems」画面で、次のように実行します。

1. .earファイルが配置されているアプリケーション・サーバー・ノードをクリックします。

2. WebCenter Sitesの場合:
<sites_install_dir>/ominstallinfo/appディレクトリを参照します。

CASの場合:

<sites_install_dir>/ominstallinfoディレクトリを参照します。

3. WebCenter Sitesの場合:
ContentServer.earファイルを選択します。

CASの場合:

cas.earファイルを選択します。

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

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

6. 「Preparing for the application installation」画面で、「Detailed」を選択し、「Next」をクリックします(図6-7)。

図6-7 「Detailed」オプション

7. 「Application Security Warnings」画面で、「Continue」をクリックします。

8. 「Select installation options」画面で、「Precompile JavaServer Pages」ファイルを選択して、「Next」をクリックします(図6-8)。

図6-8 「Select Installation Options」

9. 「Map modules to servers」画面(図6-9)で、次のように実行します。

1. .warファイル・モジュールのチェック・ボックスを選択します。

2. 「Clusters and servers」の下でデプロイメント・ターゲットを選択します。
クラスタ環境では、クラスタを選択します。

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

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

図6-9 「Clusters and Servers」

10. 「Provide options to compile JSPs」画面(図6-10)で、「JDK Source Level」フィールドの値を16に変更し、「Next」をクリックします。

図6-10 「Provide Options to Compile JSPs」

11. 「Provide JSP reloading options for Web modules」画面で、「Step 13: Summary」のリンク(図6-11)をクリックします。

図6-11 「Step 13: Summary」

12. 「Summary」画面(図6-12)で、選択したオプションを確認し、「Finish」をクリックします。

図6-12 「Summary of Installation Options」

13. 「Enterprise Applications」画面で、新しくデプロイしたアプリケーションをクリックします。

14. その後に続く画面で、「Class loading and update detection」をクリックします(図6-13)。

図6-13 「Class Uploading and Update Detection」

15. 開いた画面(図6-14)で、次のように実行します。

1. 「Polling interval for updated files」フィールドに、30を入力します。

2. 「Class load order」セクションで、「Classes loaded with application class loader first」を選択します。

3. 「WAR class loader policy」セクションで、「Single class loader for application」を選択します。

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

図6-14 「Class Loader」

16. 変更を保存します。

6.5.3 TomcatへのWebCenter SitesおよびCASのデプロイ

プライマリおよびセカンダリのサーバー・インストール中に、WebCenter Sitesインストーラによって、WebCenter Sites WebアプリケーションがTomcatサーバーのwebappsディレクトリに自動的に開きます。

プライマリ・サーバー・インストール中に、WebCenter Sitesインストーラによって、CAS WebアプリケーションがプライマリTomcatサーバーのwebappsディレクトリに自動的に開きます。CAS Webアプリケーションは、この時点までに、他のすべてのサーバーおよびそれらのそれぞれのwebappsディレクトリにコピーしておく必要があります。

6.6 WebCenter Sitesの再起動

アプリケーション・サーバーのインストールが完了したら、サーバーを検証する前にそれを再起動します。

6.7 WebLogic Application Serverの本番モードへの切替え(配信システムのみ)

配信システムにインストールした場合は、WebLogicを本番モードに切り替えます。

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

2. ツリー内のドメイン名をクリックします。

3. 「一般」タブをクリックします。

4. 「本番モード」の横にあるチェック・ボックスを選択します。

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

6. 「変更の承諾」をクリックします。

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

8. これで、WebCenter Sitesインストールを検証し、必要に応じて様々なインストール後の手順を完了する準備ができました。第7章「WebCenter Sitesのインストール後の手順」に続きます。

7 WebCenter Sitesのインストール後の手順

WebCenter Sitesのインストール・プロセスが正常に完了したら、ご使用の環境での必要に応じて次の手順を実行します。

- 第7.1項「XMLパーサーのロード」

- 第7.2項「CASに対する信頼できるURLの指定」

- 第7.3項「WebCenter Sitesのインストールの検証」

- 第7.4項「LDAPとの統合(オプション)」

- 第7.5項「Oracle Access Manager (OAM)とWebCenter Sitesとの統合(オプション)」

- 第7.6項「Satellite Serverのインストール」

- 第7.7項「ビジネス上の目的に合わせたWebCenter Sitesのセットアップ」

7.1 XMLパーサーのロード

WebCenter Sitesには、Microsoft XML Parserの修正済バージョンが含まれています(WEB-INF/libディレクトリのMSXML.jar)。CLASSPATH環境変数で、異なるバージョンのParserが参照されている場合は、WebCenter Sitesによって使用されるバージョンを参照するようにそのパスを変更する必要があります。そのようにしないと、XML解析時にWebCenter Sitesが失敗します。

7.2 CASに対する信頼できるURLの指定

ログインに成功すると、ユーザーは、CASによって、リクエストされたサービスにリダイレクトされます。セキュリティ目的で、リクエストされたサービスを、CASがそのユーザーをサービスにリダイレクトする前に検証できます。リクエストされたサービスを検証するには、信頼できる(許可される)URLのリストを
cs_install/bin/customBeans.xmlファイルに指定し、CASサーバーを再起動します。URLは、次の書式のいずれか1つにできます。

- 正確なURL: 例

http://<hostname>:<port>/cs/wem/fatwire/wem/Welcome

- 一致するURL: 例

http://<hostname>:<port>/SitesWebapp/*

ここで、/*は、http://<hostname>:<port>/SitesWebappで始まるすべてのURLが許可されることを示します。

ユーザーがIPアドレスを使用して信頼できるリソースにアクセスする必要がある場合、それらのURLも指定します。

7.3 WebCenter Sitesのインストールの検証

一般管理者としてOracle WebCenter Sitesにログインし、WebCenter Sites管理インタフェース、コントリビュータ・インタフェースおよびWEM管理インタフェースにアクセスすることで、インストールを検証します。このプロセスで、シングル・サインオンが機能していることを検証します(WebCenter Sitesからログアウトしてからログインしなおすことなく異なるアプリケーションにアクセスすることによって)。

WebCenter Sitesインタフェースにアクセスする手順は、次のとおりです。

1. ブラウザを次のURLにポイントします。

http://<server>:<port>/<context>/login

ここで、<server>はWebCenter Sitesを実行しているサーバーのホスト名またはIPアドレス、<port>はWebCenter Sitesアプリケーションのポート番号、<context>はサーバー上にデプロイされたWebCenter Sitesアプリケーションの名前です。

WebCenter Sitesログイン・フォームが表示されます(図7-1)。

図7-1 WebCenter Sitesログイン・フォーム

2. 次の資格証明情報を入力します。

- ユーザー名: fwadmin

- パスワード: xceladmin

3. 「ログイン」をクリックします。

4. WEM管理インタフェースにアクセスします。「サイト」ドロップダウン・リストで、「AdminSite」を選択し、WEM Adminインタフェースのアイコンを選択します(図7-2)。

図7-2 「AdminSite」オプションとWEM管理アイコン

WEM管理インタフェースが(AdminSite上に)表示されます(図7-3)。

図7-3 WEM管理インタフェース

5. アプリケーション・バー(インタフェースの最上部にある)に移動し、WebCenter Sites 「管理」インタフェースのアイコンを選択することでWebCenter Sites管理インタフェースにアクセスします(図7-4)。

図7-4 アプリケーション・バーのWEM管理アイコン

WebCenter Sites管理インタフェース(AdminSite上)が表示されます(図7-5)。システム管理機能のみ使用可能です。

図7-5 AdminSiteの管理機能

6. WebCenter Sitesコントリビュータ・インタフェースにアクセスします。

注意:

WebCenter Sitesコントリビュータ・インタフェースは、AdminSiteと関連付けられていません。次の手順の1つから開始します。

- avisportsまたはFirstSite IIサンプル・サイトがインストールされている場合、コントリビュータ・インタフェースは各サイトに割り当てられます。ステップ6aに進み、これらのサンプル・サイトのいずれか1つを選択し、コントリビュータ・インタフェースにアクセスします。

- サンプル・サイトがインストールされていない場合、WEM管理インタフェースを開き(ステップ4を参照)、サイトを作成し、ユーザーを作成し、そのユーザーをサイトに割り当てることが必要になります。コントリビュータ・インタフェースは、同じサイトに自動的に割り当てられます。WEM管理インタフェースからサイトにユーザーを割り当てる手順については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照し、この手順を続行してください。

1. アプリケーション・バーに移動します。サイトの選択ドロップダウン・リスト(図7-6)で、AdminSite以外のサイトを選択します。

図7-6 アプリケーション・バーのナビゲーション

2. これが、選択したサイトへの初めてのアクセスであるため、図7-7に示す画面が表示されます。コントリビュータ・インタフェースのアイコンを選択します。

図7-7 コントリビュータ・インタフェース・アイコン

(後に続くアクセスでは、選択したサイトで最後にアクセスしたアプリケーションが開きます。)

選択したサイトのコントリビュータ・インタフェースが表示されます(図7-8)。

図7-8 コントリビュータ・インタフェース

これで、WebCenter Sitesを構成する準備が整いました。この章の残りの手順に従ってください。

7.4 LDAPとの統合(オプション)

LDAP統合は、Webインストールのオプションです。

LDAP統合を実行する必要がある場合は、次のように実行します。

1. 選択したサポートされているLDAPサーバーをセットアップします。詳細は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。

2. WebCenter Sites CDに収録されているLDAP統合プログラムを実行します。
詳細は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。

注意:

プライマリ・クラスタ・メンバーにLDAPを構成済である場合、必ず、すべてのセカンダリ・クラスタ・メンバーに対してconfiguredLDAP.shを実行してください。

3. 統合をテストします。

http://<servername>:<port>/servlet/CatalogManager?ftcmd=login&username=<username>&password=<password>

説明:

<servername>は、WebCenter Sitesをホストするマシンの名前です。

<port>は、そのサーバーのポート番号です。

<username>はユーザー定義です(たとえば、ContentServer)。

<password>はユーザー定義です(たとえば、password)。

7.5 Oracle Access Manager (OAM)とWebCenter Sitesとの統合(オプション)

CASをOracle Access Manager (OAM)に置き換える場合は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』の手順を参照してください。

7.6 Satellite Serverのインストール

詳細は、第9章「リモートSatellite Serverのインストール手順」を参照してください。

7.7 ビジネス上の目的に合わせたWebCenter Sitesのセットアップ

WebCenter Sitesのインストールを完了すると、それをビジネスで使用するために構成する準備が整います。詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』および『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。データ・モデル、コンテンツ管理サイト、サイト・ユーザー、パブリッシュ関数、クライアント・インタフェースなどコンテンツ管理環境を作成および有効化する方法を説明します。

第II部

Oracle WebCenter Sites: Satellite Serverのインストール

第II部は、次の章で構成されています。

- 第8章「Satellite Serverの概要」

- 第9章「リモートSatellite Serverのインストール手順」

- 第10章「Satellite Serverのインストール後の手順」

8 Satellite Serverの概要

Satellite Serverは、WebCenter Sitesシステムと連動して、次のような利点を提供します。

- キャッシュの追加のレイヤー。WebCenter Sitesキャッシュによって提供されるキャッシュのレイヤーを補足します。

- スケーラビリティ。Satellite Serverのリモート・インストールを追加することで、迅速かつ経済的にWebCenter Sitesシステムにスケーラビリティを持たせることができます。

- パフォーマンスの向上。Satellite Serverは、WebCenter Sites上の負荷を軽減し、コンテンツを、それを表示するWebサイトのビジターの近くに移動することで、Webサイトのパフォーマンスを向上します。

- REST呼出しをキャッシュする機能。この理由のために、コンテンツ管理インストールおよび配信インストールの前にリモートSatellite Serverを追加する場合があります。

この章では、これらの利点を得るために実装する構成について説明します。

Satellite Serverは、次のように構成できます。

- 共存。これにより、キャッシュの2つめのレイヤーが提供され、開発および管理システムでコンテンツの実際の配信をシミュレートできます。

- リモート。これにより、配信システムのパフォーマンスおよびスケーラビリティが向上します。

このドキュメントの内容は次のとおりです。

- 第8.1項「共存」

- 第8.2項「リモート」

8.1 共存

WebCenter Sitesには、Satellite Serverのコピーが同梱されており、それはWebCenter Sitesソフトウェアと同じマシンに自動的にインストールされ、有効化されます。これが、共存Satellite Serverです。共存Satellite Serverの目的は、開発および管理システムに、アクティブ・サイト(配信システム)で行われるページ配信をシミュレートする機能を提供することです。

共存Satellite Serverは、WebCenter Sitesキャッシュによって提供されるものに追加されるキャッシュのレイヤーを提供します。Satellite ServerとWebCenter Sitesのキャッシュは、直列で機能して二重バッファのキャッシュを提供し、キャッシュされたページのコピーは、Satellite ServerとWebCenter Sitesの両方のキャッシュに格納されます。この構成の短所は、オブジェクトごとに2つのコピーをメモリーに格納するため、メモリー使用量が増加することです。二重バッファのキャッシュの詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』の「キャッシュ」の章を参照してください。図8-1は、Satellite Serverの共存インストールを示しています。

共存Satellite Serverホストを、第10.1項「キャッシュ条件の調整」の説明に従って、WebCenter Sitesシステムのパフォーマンスが最適になるように設定することをお薦めします。

図8-1 共存Satellite Serverアーキテクチャ

8.2 リモート

配信システムで、1つ以上のリモートSatellite Serverインスタンスをセットアップする必要があります。少なくとも、1つのリモートSatellite ServerをWebCenter Sitesと同じ地理的位置にインストールする必要があります。リモートの地理的位置のパフォーマンスを高めるために、図8-2に示すように追加のリモートSatellite Serverを構成できます。

図8-2 リモートSatellite Serverアーキテクチャ

Satellite Serverのリモート・インストールは、二重バッファのキャッシュを可能にするのみでなく、いくつかの利点をもたらします。

- コンテンツがその対象読者の近くに移動することで、Webサイトのパフォーマンスが向上します。前の図では、たとえば、メイン・データ・センターがニューヨークにあり、セカンダリ・データ・センターがヨーロッパおよびアジアにあるとします。

- キャッシュ・コンテンツはリクエストをWebCenter Sitesに転送する必要がなくなり、このリソースが他のタスクを処理できるようになるため、スケーリングの向上が可能になります。

Satellite Serverのリモート・インスタンスのインストールおよび構成の詳細は、第9項「リモートSatellite Serverのインストール手順」を参照してください。

9 リモートSatellite Serverのインストール手順

Satellite Serverのリモート・インスタンスをインストールする場合、それらをサポートされている任意のアプリケーション・サーバーにインストールできます(アプリケーション・マトリックスを参照)。Satellite Serverのリモート・インスタンスのインストールおよび構成は、反復プロセスです。最初に1つのリモートSatellite Serverでインストール、構成およびテストを行い、次に、他のリモートSatellite Serverインストールをインストール、構成およびテストします。Satellite Serverソフトウェアのインストールおよび初期構成が完了したら、ハードウェアおよびソフトウェア・スタックを最大限利用するために構成を調節できます。

Satellite Serverのリモート・インスタンスをインストールおよび構成するには、次の手順を完了します。

- 第9.1項「ステップ1: 必須ハードウェアおよびソフトウェアのインストール」

- 第9.2項「ステップ2: インストール・ファイルの展開」

- 第9.3項「ステップ3: Satellite Serverのインストール」

- 第9.4項「ステップ4: WebCenter SitesへのSatellite Serverの登録」

- 第9.5項「ステップ5: CASに対する信頼できるURLの指定」

- 第9.6項「ステップ6: Satellite Serverの起動」

- 第9.7項「ステップ7: 構成のテスト」

- 第9.8項「ステップ8: 追加のリモート・サーバーでのSatellite Serverのインストール」

- 第9.9項「次のステップ」

9.1 ステップ1: 必須ハードウェアおよびソフトウェアのインストール

Satellite Serverをインストールする前に、必須ハードウェアおよびソフトウェアがあることを確認します。最新の情報は、Oracle WebCenter Sites動作保証マトリックスを参照してください。

この項の内容は、次のとおりです。

- 第9.1.1項「ネットワークに関する考慮事項」

- 第9.1.2項「ロード・バランサの要件」

- 第9.1.3項「構成要件」

- 第9.1.4項「アプリケーション・サーバーの要件」

- 第9.1.5項「Satellite Serverのコンテンツ」

9.1.1 ネットワークに関する考慮事項

Satellite ServerホストとWebCenter Sitesホストの間の接続は、キャッシュされていないデータの提供のパフォーマンスを制限する要因です。リモート接続は、Satellite Serverキャッシュにないデータにアクセスする場合、帯域幅および待機時間に関するパフォーマンスが低下します。

9.1.2 ロード・バランサ要件

複数のリモートSatellite Serverを使用している場合は、ロード・バランサ(ハードウェアまたはソフトウェアベース)が必要です。Oracle製品は、使用可能なロード・バランサのブランドに制限はありませんが、セッション・アフィニティをサポートするロード・バランサを使用し、セッション・アフィニティを有効化することを強くお薦めします。

9.1.3 構成要件

Satellite Serverホストは、表9-1の最小要件を満たす必要があります。

表9-1 Satellite Serverの最小要件

要件

説明

オペレーティング・システム

Oracle WebCenter Sites動作保証マトリックスを参照してください。

アプリケーション・サーバー

Oracle WebCenter Sites動作保証マトリックスを参照してください。

CPU

デュアル・コア・システム(推奨: クワッド・コア・システム以上)

物理メモリー

4GB (12GB以上を推奨)

ディスク領域

2GB (4GB以上を推奨)

JVM

32ビット(64ビットを推奨)

9.1.4 アプリケーション・サーバーの要件

WebCenter Sitesで使用されるデフォルト・キャッシュ・フレームワークであるinCacheは、効率的に機能するために次のJVMパラメータを設定する必要があります。

-Dnet.sf.ehcache.enableShutdownHook=true
-DnumOfDiskStores=<will vary based on drive speed>

9.1.5 Satellite Serverのコンテンツ

Satellite Serverは、完全な機能を備えたサーブレット・コンテナおよびサーブレット・エンジンを必要とします。サポートされる環境については、Oracle WebCenter Sites動作保証マトリックスを参照してください。

9.2 ステップ2: インストール・ファイルの展開

インストール・ファイルの名前はSatelliteServer.zipです。このファイルをホスト・マシンに抽出します。

- UNIX: SatelliteServer.zipを解凍します。

- Windows: WindowsエクスプローラでSatelliteServer.zipをダブルクリックします。

このzipファイルを抽出すると、SatelliteServerという名前のサブディレクトリが作成されます。そのサブディレクトリのいずれも名前を変更しないでください。アーカイブ済ディレクトリ構造を保持してください。そのようにしない場合、インストーラが失敗します。

9.3 ステップ3: Satellite Serverのインストール

Satellite Serverは、次のようにインストールできます。

- 第9.3.1項「GUIインストーラを使用したSatellite Serverのインストール」

- 第9.3.2項「Satellite Serverのサイレント・インストール」

9.3.1 GUIインストーラを使用したSatellite Serverのインストール

1. 次のインストーラ・スクリプトを実行します。

- Windowsの場合: ssInstall.bat

- UNIXベースのシステムの場合: ssInstall.sh

2. 初期画面(図9-1)で、「次へ」をクリックします。

図9-1 初期画面

3. 「インストール・ディレクトリ」画面(図9-2)に、Satellite Serverのターゲット・インストール・パスを入力します。必要な権限を持っていることを確認します。指定したディレクトリが存在しない場合は、インストーラから、それを作成する権限を要求されます。

図9-2 インストール・ディレクトリ

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

4. 望ましいプラットフォーム・タイプを選択します(図9-3)。

図9-3 プラットフォーム・タイプ

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

5. 目的のアプリケーション・サーバーを選択し、Satellite Serverのコンテキスト・ルート (図9-4)を入力します。

図9-4 アプリケーション・サーバー

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

6. WebCenter Sites情報を入力します(図9-5)。

- WebCenter Sitesを実行しているマシンのホスト名またはIPアドレス。

- WebCenter Sitesが接続をリスニングするポート番号。

- Satellite Serverが接続するアプリケーション・コンテキスト・ルート。

- WebCenter Sitesがセキュア接続を介してインストールされたかどうか。

図9-5 Sitesの情報

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

7. Satellite Server管理アカウント情報を入力します (図9-6)。

- ユーザーの管理アカウントのユーザー名を入力します。デフォルトでは、このフィールドにはSatelliteServerが移入されています。

- ユーザーのパスワードを入力します。

図9-6 Satellite Serverの情報

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

8. CASデプロイメントの情報を入力します(図9-7)。

- 最初の2つのフィールド(サーバー・ホスト名とポート番号)に、CASがデプロイされているサーバーのホスト名とポート番号を入力します。

- 内部からアクセス可能なCASのサーバー・ホスト名とポート番号の各フィールドは、それぞれCASHostNameLocalプロパティおよびCASPortNumberLocalプロパティにマップされます。これらのプロパティは、ロード・バランサではなく、CASが実際にデプロイされているサーバーを指している必要があります。ただし、クラスタ内では、ホストがロード・バランサを指す必要があります。次のように実行します。CASサーバーがファイアウォールの背後からアクセスできない場合、ファイアウォールの背後からアクセス可能なサーバーのホスト名およびポート番号を入力します。それ以外の場合、最初の2つのフィールドと同じ情報を入力します。

図9-7 CASのデプロイメント情報

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

9. 「インストール」をクリックしてインストール処理を開始します(図9-8)。

図9-8 インストールの進行状況

10. Satellite Serverをデプロイします(図9-9)。
Satellite Serverのwarファイル(デフォルトではcs.warという名前)は、Satellite Serverのインストール・ディレクトリの下のominstallinfo/app/にあります。必要に応じて、cs.warファイルの名前を変更し、展開したWARファイルをサーバーにデプロイし、サーバーを起動(または再起動)し、「OK」をクリックして、インストールを完了します。

図9-9 インストール・アクション

11. デプロイメントに成功した場合、確認ダイアログ・ボックスが表示されます。「OK」をクリックしてインストール・ログを確認します(図9-10)。

図9-10 インストールの進行状況

12. 「終了」をクリックしてインストーラを終了します。

9.3.2 Satellite Serverのサイレント・インストール

Satellite Serverのサイレント・インストールを行うには:

1. omii.iniファイルを生成します。

1. Satellite ServerのGUIインストーラを、第9.3.1項「GUIインストーラを使用したSatellite Serverのインストール」のステップ1から8の説明に従って実行します。

2. 「インストールの進行状況」画面(図9-8)が表示されたら、GUIインストーラを停止します。

2. <RSS_Home>\omiiから、GUIインストーラで入力したパラメータを含むomii.iniファイルをコピーします。

3. 必要に応じてomii.iniファイルを編集し、このファイルをSatellite Serverのインストール・ディレクトリに貼り付けます。

4. Satellite Serverのインストール・ディレクトリにあるinstall.iniファイルを次のように編集します。

nodisplay=true
loadfile=<path to the omii.ini file you just edited>

5. ssInstall.sh -silentを実行します。

9.4 ステップ4: WebCenter SitesへのSatellite Serverの登録

このステップでは、リモートSatellite ServerをWebCenter Sitesに登録し、WebCenter SitesがリモートSatellite Serverキャッシュを適切に管理できるようにします。すべてのSatellite Serverインストールが、それぞれのWebCenter Sitesインストールに登録されている必要があります。

注意:

各リモートSatellite Serverは、単一のWebCenter Sitesインストールとのみ関連付けることができます。したがって、2つの個別のWebCenter Sitesインストールに同じリモートSatellite Serverを使用することはできません(管理や本番など)。

1. Windowsシステムの場合、Sites Explorerを開き、SiteGod権限を持つユーザー(たとえば、一般管理者またはContentServerユーザー)としてWebCenter Sitesにログインします。

2. System Satelliteタブをクリックします。

3. 開いた表には、具体的な値が移入されており、各行は一意のSatellite Serverシステムを表しています。推奨値については、次の表を参照してください。

列

値

id

このSatellite Serverを識別する数値(正の整数)。これは、この表の同じ列の他の行の他のどの値とも異なる必要があります。

description

このSatellite Serverをユーザーに識別させるテキストの記述。リファレンス目的にのみ使用されます。

protocol

Satellite Serverがリクエストを受信するプロトコル。これは通常、httpです。

host

Satellite Serverのホスト名またはIPアドレス。これは、ロード・バランサではなく実際のSatellite Serverエンジンのホストにする必要があります。

port

Satellite Serverがリクエストのリスニングを行うポート。

satelliteservletpath

ポート番号からSatelliteサーブレットの名前までを含むURLの部分です。これは通常、/servlet/Satelliteです。

flushservletpath

ポート番号からFlushServerサーブレットの名前までを含むURLの部分です。これは通常、/servlet/FlushServerです。

inventoryservletpath

ポート番号からインベントリ・サーブレットの名前までを含むURLの一部です。これは通常、/servlet/Inventoryです。

pastramiservletpath

ポート番号からインベントリ・サーブレットの名前までを含むURLの一部です。これは通常、/servlet/Pastramiです。

username

このSatellite Serverに割り当てられたユーザー名。

password

このSatellite Serverに割り当てられたパスワード。パスワードは、入力された後に、Sites Explorerによって自動的に暗号化されます。

4. 「ファイル」メニューから「保存」 を選択して、変更を保存します。

5. Sites Explorerを終了します。

9.5 ステップ5: CASに対する信頼できるURLの指定

ログインに成功すると、ユーザーは、CASによって、リクエストされたサービスにリダイレクトされます。セキュリティ目的で、リクエストされたサービスを、CASがそのユーザーをサービスにリダイレクトする前に検証できます。リクエストされるサービスのURLの指定の手順は、第7.2項「CASに対する信頼できるURLの指定」を参照してください。

9.6 ステップ6: Satellite Serverの起動

必要に応じて、アプリケーション・サーバーを再起動します。アプリケーション・サーバーの再起動(デプロイ)方法の詳細は、第I部「Oracle WebCenter Sitesのインストール」を参照してください。

9.7 ステップ7: 構成のテスト

Satellite Serverを他のマシンにインストールする前に、新規インストールしたSatellite Serverをテストし、それがWebCenter Sitesと適切に通信していることを確認します。Satellite Serverをテストするには、コンテキスト管理モードで実行されてるWebCenter Sitesシステムからコンテンツをパブリッシュする必要があります。

構成をテストする手順は、次のとおりです。

1. ロード・バランサを構成し、すべてのWebCenter Sitesリクエストが、1つのSatellite Serverインスタンスに送信されるようにします。

2. ブラウザを使用してSatellite Server URLに移動します。例:

http://<server>:<port>/<URI>/Satellite?pagename=<MyPage>

ここで<MyPage>は、WebCenter Sitesシステム上の任意のページです。

注意:

入力するSatellite ServerのURLを見つける最も簡単な方法は、コンテンツ管理システムのページをプレビューしてそのURLをコピーし、リモートSatellite Serverを指定するように変更します。

3. すべてが適切に構成されている場合、ブラウザに、選択したページが表示されます。
選択したページがブラウザに表示されない場合は、次のことを確認してください。

- ロード・バランサを適切にセットアップしましたか。このテストの場合、WebCenter Sitesに対するすべてのリクエストは、Satellite Serverマシンに送信する必要があることを忘れないでください。(他のマシンはまだ構成されておらず、したがつてこれらのリクエストを処理できません。)

- Satellite Serverプロパティを適切に設定しましたか。特に、ホスト名およびポート番号を適切な値に設定したことを確認してください。

- WebCenter Sitesに無効なページをリクエストしましたか。

9.8 ステップ8: 追加のリモート・サーバーでのSatellite Serverのインストール

最初のリモートSatellite Serverインスタンスをインストールおよびテストした後、この章の手順を反復することで、残りのSatellite Serverインスタンスをインストールおよび構成します。

9.9 次のステップ

第10章「Satellite Serverのインストール後の手順」に進み、キャッシュ条件を調整し、WebCenter Sitesシステムのパフォーマンスを最適化します。

10 Satellite Serverのインストール後の手順

リモートSatellite Serverをインストールおよび構成した後、キャッシュ条件を調整し、WebCenter Sitesシステムのパフォーマンスを最適化できます。

この章では、次の項目について説明します。

- 第10.1項「キャッシュ条件の調整」

- 第10.2項「ログ構成」

10.1 キャッシュ条件の調整

inCacheを使用している場合

inCacheフレームワークを使用している場合、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』にリストされているプロパティを設定することでそれを調整できます。

inCacheまたは従来のキャッシュ・フレームワークのいずれのタイプでも、satellite.propertiesファイルで有効期限プロパティを設定できます。有効期限プロパティは、アイテムを生成したBlobに対してsatellite.blobまたはRENDER.SATELLITEBLOBタグでキャッシュ有効期限値が明示的に設定されていない場合のBlobのデフォルト有効期限時間を定義します。

- 有効期限をneverに設定すると、Blobが時間的な理由で期限切れになることはないことがSatellite Serverに通知されます。そのようなオブジェクトが、キャッシュに無期限にとどまるとは限りません。たとえば、キャッシュがいっぱいの場合、Satellite ServerによってLRU (最低使用頻度)アルゴリズムに基づいてキャッシュからオブジェクトが削除されます。

- 有効期限をimmediateに設定すると、Satellite Serverに、ページ、ページレットまたはBlobをまったくキャッシュしないことが通知されます。

特定のセットの有効期限日付と時刻を定義するには、次の書式を使用する文字列を有効期限プロパティに割り当てます。

hh:mm:ss W/DD/MM

このプロパティの値は、TimePatternオブジェクトの構文に従います。構文定義は、便宜のため表10-1にも示します。

表10-1 TimePattern構文

パラメータ

有効な値

説明

hh

0-23

時間。たとえば、0は午前0時、12は正午、15は午後3時などを意味します。

mm

0-59

その時刻を過ぎた分数。

ss

0-59

その分を過ぎた秒数。

w

0-6

曜日。たとえば、0は日曜、1は月曜などを意味します。

DD

1-31

月の日。

MM

1-12

月。たとえば、1は1月、2は2月などを意味します。

たとえば、次の有効期限値は、毎月曜日の午後3時30分および4月15日を意味します。

15:30:00 1/15/4

WとDDの両方の値を指定すると、両方の値が適用されます。したがって、ページは月曜日(Wフィールド)と15日(DDフィールド)に期限切れします。曜日による有効期限のみを示す場合は、DDフィールドにアスタリスクを入力します。たとえば、4月の毎月曜日の午後3時30分の有効期限を示すには、次のように有効期限値を設定します。

15:30:00 1/*/4

日付による有効期限のみを示す場合は、Wフィールドにアスタリスクを入力します。たとえば、4月15日の午後3時30分の有効期限を示すには、次のように有効期限値を設定します。

15:30:00 */15/4

hh、mm、ssまたはMMフィールドにアスタリスクを設定すると、すべての有効な値を意味します。たとえば、月曜日の午後3時30分および毎月15日の有効期限を示すには、次のように有効期限値を設定します。

15:30:00 1/15/*

また、値をカンマで区切ることで、6つのフィールドのいずれにも複数の値を指定できます。値の範囲を表すには、マイナス記号を使用します。たとえば、次の有効期限値は6時00分(朝)および1時00分(午後)および5時00分(午後)、および6月の月曜日から金曜日までを表します。

6,13,17:00:00 1-5/*/6

ページが15分ごとに期限切れする必要があることを示すには、有効期限値を次のように設定します。

*:15,30,45:0 */*/*

デフォルトの値は次のとおりです。

5:0:0 */*/*

これは、Satellite Serverキャッシュ内のすべてのものが、毎日午前5時00分に期限切れすることを意味します。

10.2 ログ構成

Satellite Serverは、Apache Jakarta Commons Loggingを使用します。デフォルトでは、特定のJCL構成情報は指定されていません。その結果、JCLは、INFO、WARNおよびERRORメッセージをコンソールに記録するようになります。ユーザーが詳細な構成情報を指定するには、次のディレクトリ内にcommons-logging.propertiesという空のファイルを配置します。

<$SatelliteServerRoot>/WEB-INF/classes

その後、そのファイルをプロパティ・エディタを使用して編集します。プロパティ・エディタは、各プロパティに関する詳細なログ構成情報を提供します。

プロパティ・エディタを開くには、settings.batバッチ・ファイル(Windows)またはsettings.shスクリプト(UNIX)を実行します。commons-logging.propertiesファイルが開きます。それにはいくつかのタブがあります。「ロガー」タブの下に、他のエントリとともに次のものが表示されます。

com.fatwire.logging.cs.satellite
com.fatwire.logging.cs.satellite.cache
com.fatwire.logging.cs.satellite.host
com.fatwire.logging.cs.satellite.request

これらが、Satellite Serverが使用するロガーです。各ロガーに関する情報および設定可能な値は、プロパティ・エディタのプロパティの説明を参照してください。「ファクトリ」タブの下で、Satellite Serverで使用するロガーのタイプを選択できます。デフォルトでは、プロパティ・エディタは、これを次のように設定します。

COM.fatwire.cs.core.logging.TraditionalLog

これにより、ログ・メッセージを、「トラディショナル・ログ」タブの下で構成されているログ・ファイルに書き込めます。(logging.fileプロパティが必須であることに注意してください。)

コンソールにメッセージを送信するには、org.apache.commons.logging.Logプロパティを空白またはCOM.FutureTense.Logging.StandardLogに設定します。完了したら、変更を保存し、プロパティ・エディタを終了し、アプリケーション・サーバーを再起動することでSatellite Serverを再起動します。JCLの詳細は、JCL Webサイト(http://jakarta.apache.org/commons/logging/)を参照してください。

第III部

Oracle WebCenter Sitesの国際化

第III部は、次の章で構成されています。

- 第11章「複数言語操作用の環境の構成」

11 複数言語操作用の環境の構成

この章では、WebCenter Sitesで複数言語操作が可能になるように環境を構成する方法について説明します。

この章の内容は、次のとおりです。

- 第11.1項「WebCenter Sites固有の設定」

- 第11.2項「Internet Explorerの設定」

- 第11.3項「国際化のための追加の指定」

11.1 WebCenter Sites固有の設定

注意:

- 特定のWebCenter Sitesインスタンスに対して選択した設定は、すべてのクラスタ・メンバー(存在する場合)およびすべての環境(開発、コンテンツ管理、配信など)にわたって再生成する必要があります。

- 次に説明するプロパティと変数のいずれも設定されていない場合、cs.contenttypeプロパティがデフォルトでtext/htmlに設定されます。出力の文字セットは、デフォルトで、デフォルト・システム・エンコーディングになります。

11.1.1 cs.contenttypeプロパティ

futuretense.iniのcs.contenttypeプロパティは、システム全体の(グローバル)プロパティであり、送信文字エンコーディングを定義します。デフォルトでは、このプロパティは、text/html; charset=UTF-8に設定されます。特定のエンコーディングが必要な場合は、この値を変更します。たとえば、出力エンコーディングをShift_JISにする場合、このプロパティをtext/html; charset=Shift_JISに設定します。Sites Explorerは、この設定に依存してデータを適切に表示します。

11.1.2 cs.contenttype変数(SiteCatalog resargs1で設定)

cs.contenttype変数で、ページごとに出力エンコーディングを制御できます。この変数は、cs.contenttypeプロパティで定義された値をオーバーライドします。この変数は、第11.1.1項「cs.contenttypeプロパティ」に示すように、cs.contenttypeプロパティと同じように設定する必要があります。

WebServicesの下のページは、cs.contenttype=application/xml;charset=UTF-8に設定されていることに注意してください。

11.1.3 フォームの_charset_ hidden変数

HTML formタグを使用して国際化データを入力する場合、必ず、_charset_入力タイプ変数を、form宣言の後の一番最初に設定します。例:

<form action='ContentServer' method='get'>
<input type='hidden' name='_charset_'/>
<input type='hidden' name='pagename' value='<%=ics.GetVar("pagename")%>'/>
<input type='text' name='name' value='<%=ics.GetVar("name")%>'/>
<input type='submit'/>
</form>

値がない場合、_charset_ hidden変数は、Internet Explorerブラウザでのみ機能します。

11.1.4 望ましいエンコーディング

WebCenter Sitesで、HTTPリクエストを特定のエンコーディング(たとえば、Cp943C)で消費する必要があり、それが広く使用されているエンコーディング(Shift_JIS)に近似している場合、_charset_ hidden変数のみに頼るのは不十分です。Internet Explorerでは、Cp943Cに設定された_charset_値が検出されると、それがShift_JISに変更されます。これにより、WebCenter Sitesは、すべてのデータを強制的にShift_JISで読み取るようになります。これに対処するために、特別な名前のプロパティ構文が使用されます。

cs.contenttype.<charset>=<preferred_encoding_for_this_charset>

たとえば、前述のシナリオに関しては、このプロパティを次のように指定して、WebCenter SitesにCp943Cを使用するように示します。

cs.contenttype.Shift_JIS=Cp943C

このプロパティ構造は、Internet Explorerの動作が_charset_ valueの値と競合し、それが変更されるという前述のような特別な状況でのみ必要です。

11.1.5 XMLまたはJSPエレメントで指定されるエンコーディング

XMLエレメントの<?xml行内のエンコーディングは、ディスク上の.xmlファイルのエンコーディングを指定します。JSPの場合も同じです。ページ・ディレクティブ内に指定されたエンコーディングは、2つのことを指定します。1つめは、ディスク上の.jspファイルのエンコーディングです。2つめは、評価済JSPエレメントの出力エンコーディングです。これは、包含するJSPのエンコーディングに(またはXMLの場合はページの出力エンコーディング(content-type))に変換されます。したがって、cs.contenttypeを使用すると送信ページがShift-JISなどの特定のエンコーディングを持つことを指定できますが、JSPはUTF-8を出力でき、UTF-8は、Shift-JISに変換されて、ページのレスポンスの出力ストリームに入れられます。次の例は、エンコーディングの指定方法を示しています。

- XML: <?xml version="1.0" encoding="UTF-8"?>

- JSP: <%@ page contentType="text/html; charset=UTF-8" %>

11.1.6 SetVarタグの使用

JSPおよびXMLでSetVarタグを使用して、送信ページ・エンコーディングを制御することもできます。SetVarタグは、何かがストリームで出力される前に設定する必要があります。

JSPでは、次のように記述できます。

<cs:ftcs>
<ics:setvar name="cs.contenttype" value="text/html; charset=UTF-8" />
...
</cs:ftcs>
In XML, you have the following options:
<ftcs>
<setvar name="cs.contenttype" value="text/html; charset=utf-8"/>
...
</ftcs>

2つめのオプションは、ics.streamheaderタグを使用することですが、これも何かがストリームで出力される前に行う必要があり、XML内でのみ使用できます。

<ftcs>
<ics.streamheader name="Content-Type" value="text/html; charset=utf-8"/>
...
</ftcs>

11.1.7 HTTP METAタグの使用

エンコーディングが前述の方法のいずれかで指定されている場合、METAタグには何も効力もなくなります。それ以外の場合、ブラウザではMETAタグで指定されたエンコーディングでのデータの表示が試みられます。

11.2 Internet Explorerの設定

Internet Explorer 8には、デフォルトですべての言語がインストールされています。特定の言語でテキストを表示できない場合は、多くの場合、それをブラウザで有効化する必要があります。

別の言語でコンテンツを表示する手順は、次のとおりです。

1. 「ツール」→「インターネット オプション」→「全般」タブに移動します。

2. ページの右下にある「言語」をクリックします。

3. 「追加」をクリックし、他の言語を、ボックスにすでに表示されている言語のリストに追加します。

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

5. Internet Explorerを閉じてから、再度開きます。コンテンツが、指定した言語で表示されるようになります(Webページがそのように提供されている場合)。

11.3 国際化のための追加の指定

次の項では、特定の国際化要件とともにWebCenter Sitesのいくつかの機能をリストします。これらの機能は次のとおりです。

- 第11.3.1項「ファイル・システムに格納されているファイル」

- 第11.3.2項「属性エディタ」

- 第11.3.3項「XMLポスト」

- 第11.3.4項「Catalog Mover」

- 第11.3.5項「Sites Explorer」

- 第11.3.6項「サイト・デスクトップとサイトDocLink」

- 第11.3.7項「WebCenter Sitesインタフェース」

- 第11.3.8項「機能の制限」

11.3.1 ファイル・システムに格納されているファイル

url列参照のために、ファイル・システムには多くの間接ファイルが格納されています。この項で、それらのファイルについて説明します。

11.3.1.1 XMLおよびJSPファイル

第11.1.5項「XMLまたはJSPエレメントで指定されるエンコーディング」を参照してください。

11.3.1.2 HTMLファイル

HTMLファイルは、file.encoding Javaパラメータ値を使用して読み取られます。ファイル内のデータも、それが最初に格納された方法によって異なります。

11.3.1.3 SystemSQL問合せ

SystemSQLは、url列を使用して、ファイル・システム上のSQL問合せを保持するファイルを指します。このファイルがロードされると、そのファイルのエンコーディングはJavaデフォルト・エンコーディング(System.getProperty("file.encoding"))であると想定されます。SystemSQL問合せを作成可能な方法はいくつかあります(Sites Explorer、テキスト・エディタまたはWebCenter Sites)。問合せを作成するときは、おそらく、常にASCII7を使用することが最適です。それは、どのデータも通常、実行時に変数の置換を使用してマージされるためです。

11.3.1.4 SystemPageCache表から参照されるページ・キャッシュ・ファイル

ページ・キャッシュ・ファイルの場合、ファイルのエンコーディングがUTF-8になるように、ページ・キャッシュ・ファイルを管理します。このファイルはWebCenter Sitesを介してのみ読み取りおよび書き込みされるため、このように管理できます。

11.3.2 属性エディタ

属性エディタにテキストを指定する方法は2つあります。

- 表示されるテキスト領域にテキストを入力します。Form Postの実行によってエンコーディングが判別されます。

- 「参照」ボタンを使用して、テキスト・ファイルを選択します。そのテキスト・ファイルのエンコーディングは、xcelerate.charsetエンコーディングで指定されたエンコーディングに一致する必要があります。(xcelerate.charsetプロパティは、futuretense_xcel.iniファイル内にあります。)

11.3.2.1 記事本文、フレックス・アセット、ユーザー定義アセット

記事本文は、file.encoding Javaプロパティ値を使用してファイル・システムに格納されます。

11.3.3 XMLポスト

非ASCIIファイルをXMLポストを介して投稿する場合、Javaファイル・エンコーディングが、そのファイルのエンコーディングと一致する必要があります。たとえば、日本語のファイル(UTF-8として格納されている)をUTF-8システムに投稿する場合、XMLポスト・コマンドが実行される前に次のうちの1つが設定されている必要があります。

- システム・ロケールがUTF-8に設定されている必要がある。

- -Dfile.encoding=UTF-8のオプションがXMLポスト・コマンドに指定されている必要がある。

同様に、そのファイルがShift_JISとして格納されている場合は、対応するシステム・ロケールが設定されているか、Java file.encodingオプションが指定されている必要があります。

WebCenter Sitesでは、投稿されたXMLファイルの最初の行としての<?xml行のエンコーディングがサポートされています。これは、.xmlファイルが読み取られるエンコーディングまで、他のすべてをオーバーライドします。

11.3.4 Catalog Mover

CatalogMover.bat (UNIX上では.sh)ファイルを開き、javaコマンドを変更して、カタログに格納されている文字の表示に必要なエンコーディングを反映する値を指定したfile.encodingパラメータを含めます。このステップは、ファイル・システムのデフォルト・エンコーディングが、カタログに格納されているデータのものと一致する場合は省略できます。

11.3.5 Sites Explorer

Sites Explorerは、futuretense.iniのcs.contenttypeプロパティが適切な値に設定されていることを必要とします。単純なASCII文字を表示する場合は、何も行う必要はありません。ただし、日本語など複雑な文字を表示する場合は、cs.contenttypeを次のうちの1つに設定する必要があります。

- text/html;charset=SJIS

- text/html;charset=UTF-8

さらに、場合によっては、ユーザーは日本語および他の各種文字セットのフォント・サポートをロードし、それらが適切に表示されるようにする必要があります。たとえば、これをWindows 2003で行うには、「設定」→「コントロール パネル」→「地域のオプション」に移動します。最初の「全般」タブで、「システムの言語設定」のリストからサポートする言語を選択します。「適用」→「OK」をクリックします。この時点で、WindowsインストールCDの挿入が必要になります。

11.3.6 サイト・デスクトップとサイトDocLink

サイト・デスクトップおよびサイトDocLinkクライアントは、Windowsによってサポートされる文字セットをサポートします。サイト・デスクトップまたはサイトDocLinkで特定の文字セットを有効化するには、最初にWindowsでそれを有効化します。手順は、Microsoft Windowsのドキュメントを参照してください。

11.3.7 WebCenter Sitesインタフェース

ユーザーのマシンは、WebCenter Sitesインタフェースで表示される文字をサポート可能であることが必要です。英語以外の言語では、ユーザーは次のことを確認する必要があります。

- 文字の表示に適したフォントがインストールされている。

- Windowsマシンでは、ロケールおよび言語の設定が、表示される文字をサポートしている。たとえば、日本語の文字をインタフェースに表示する場合、最初に、日本語の文字を表示するようにWindowsを構成する必要があります。(ターゲット言語をサポートするようにWindowsを構成する手順は、Windowsのドキュメントを参照してください)

- UNIXマシンでは、ロケール(LANGおよびLC_ALL環境変数)が適切に設定されている必要があります。

- ブラウザのエンコーディングも適切に設定されている必要があります。

11.3.7.1 単一言語の制限

コンテンツ管理システムを多言語に構成できますが、ユーザー・インタフェースの特定の部分では表示できる言語は1つのみです。

たとえば、WebCenter Sitesデータベースの表および列の名前、およびカテゴリやソース・コードなど個々のアイテムは、1つの名前をのみ持つことができます。したがって、個々のWebCenter Sitesのテキストの大部分は多言語で表示可能ですが、フィールド名やアセット・タイプ名などのアイテムは、1つの言語でのみ表示できます。

1つの名前のみ持つことができる、つまり1つの言語でのみ表示できるアイテムのリストは、次のとおりです。

- アセット・タイプ名

- フィールド名

- アセット名

- カテゴリ

- ソース・コード

- ツリー・タブ名

- サイト名

- ワークフロー・ビルディング・ブロック(アクション、電子メール・オブジェクト、条件、状態、ステップ、プロセス)の名前

- ロール名

- スタート・メニュー・アイテム(「検索」と「新規」の両方)

2つ以上の言語をサポートしているシステムでは、どの言語が大多数のコンテンツ・プロバイダによって使用されるのかを判別し、その言語を使用してサイト、タブ、アセット・タイプなどに名前を付ける必要があります。

11.3.8 機能の制限

WebCenter Sitesには、国際化使用に対して次の機能の制限があります。

- プロパティ・エディタは、ASCIIのみサポートしています。

- 小数は、US書式(小数区切りは「.」)で入力する必要があります。

第IV部

Oracle WebCenter Sites: コミュニティ-ガジェットのインストール

この部では、Oracle WebCenter Sites: コミュニティ-ガジェットWebアプリケーションを単一モードおよびクラスタ化されたモードでインストールおよび構成するプロセスについて説明します。

第IV部は、次の章で構成されています。

- 第12章「コミュニティ-ガジェットの概要」

- 第13章「コミュニティ-ガジェットをインストールするための前提条件」

- 第14章「コミュニティ-ガジェットに対するアプリケーション・サーバーの構成」

- 第15章「コミュニティ-ガジェット・デプロイメント・ファイルの生成」

- 第16章「コミュニティ-ガジェットのデプロイメント前の手順の完了」

- 第17章「コミュニティ-ガジェットのデプロイ」

- 第18章「コミュニティ-ガジェットの検証と実装」

- 第19章「サンプル・ガジェットの追加」

12 コミュニティ-ガジェットの概要

この章では、WebCenter Sites: コミュニティ-ガジェットの概要を示し、その構成を単純な開発環境とコンテンツ管理環境、および複雑な本番環境の両方について説明します。

この章の内容は、次のとおりです。

- 第12.1項「コミュニティ-ガジェットについて」

- 第12.2項「本番および管理環境」

- 第12.3項「コミュニティ-ガジェットの構成」

12.1 コミュニティ-ガジェットについて

コミュニティ-ガジェットは、Oracle WebCenter Sitesと統合されたJava EE Webアプリケーションのセットであり、ソーシャル・コンピューティング・アプリケーションとして分散環境で機能します。コミュニティ-ガジェットは、ユーザーに2つのWebエクスペリエンス管理(WEM)アプリケーション(コミュニティおよびガジェット)を提供します。

コミュニティWEMアプリケーションを使用すると、Webサイトのコンテンツに対するビジターのコメント、レビューおよび評価を収集するためのウィジェットを構成できます。コミュニティWEMアプリケーションでは、目的のトピックに関するアンケートを実施するための投票を作成して管理することもできます。ガジェットWEMアプリケーションを使用すると、Webサイトのビジターに、個別のガジェットをデプロイしたり、1つ以上のガジェットが含まれるダッシュボードをデプロイしたりできます。

コミュニティ-ガジェットをインストールするための構成手順に進む前に、この章では、コミュニティ-ガジェットの概要、コミュニティ-ガジェットとWebCenter Sitesとの関係、そのコンポーネント、およびそれらの目的について説明します。

この項の内容は、次のとおりです。

- 第12.1.1項「WebCenter Sitesのコンポーネントを使用するコミュニティ-ガジェット」

- 第12.1.2項「コミュニティ-ガジェットの管理および本番コンポーネント」

12.1.1 WebCenter Sitesのコンポーネントを使用するコミュニティ-ガジェット

コミュニティ-ガジェットは、Webエクスペリエンス管理フレームワークを介してWebCenter Sitesと統合され、次のリソースを使用します。

- アセット・リポジトリ: コミュニティ-ガジェットにはアセット・リポジトリが必要です。WebCenter Sitesは、アセット・リポジトリ、つまりデータベースを提供します。コミュニティ-ガジェットはデータベースに直接アクセスしません。データベースとのやりとりはWebCenter Sitesによってすべて管理されます。

- WebCenter Sites: Webエクスペリエンス管理フレームワーク (WEMフレームワーク)。RESTサービスおよびCentral Authentication Service (CAS)をコミュニティ-ガジェットに提供します。

- コミュニティ-ガジェットは、RESTサービスによってWebCenter Sitesと通信し、そのアセット・モデルを使用します。

- CASはREST API用の認証サービスを提供するために使用されます。

注意:

WebCenter Sites同様、コミュニティ-ガジェットには独自のCASインスタンスがありますが、それを使用できるのは本番サイドのみです。CASインスタンスを区別するため、WebCenter Sitesに同梱されているCASをWEM CAS (またはSites CAS)、コミュニティ-ガジェットに同梱されているCASをVisitors CASと呼びます。CAS Webアプリケーション(WEM CASおよびVisitors CAS)はコード・レベルではほとんど同じですが、構成が異なり、代替可能ではありません。それらを同じアプリケーション・サーバーまたはクラスタにインストールすることもできません。

CASの詳細は、次のURLを参照してください。

http://www.jasig.org/cas

注意:

WebCenter Sitesは(CASのかわりに)OAMと統合できます。

- 管理システムのコミュニティ-ガジェットは、WebCenter Sitesに統合された同じOAMを使用して、WebCenter Sitesと通信します。

- 本番システムのコミュニティ-ガジェットは、Visitors CASを使用してビジターを認証します。これをOAMに置き換えることはできません。ただし、(管理システムのWebCenter Sites同様)本番システムのWebCenter SitesはOAMと統合でき、コミュニティ-ガジェットはOAMを使用して本番システムのWebCenter Sitesと通信できます。

12.1.2 コミュニティ-ガジェットの管理および本番コンポーネント

コミュニティ-ガジェットは、アプリケーションの管理セットと本番(配信)セットの2つの部分で構成されています。

注意:

管理コミュニティ-ガジェットと本番コミュニティ-ガジェットは、別々のアプリケーション・サーバー・インスタンスにデプロイする必要があります。1つのアプリケーション・サーバーに両方をデプロイすることはサポートされていません。

- 管理コミュニティ-ガジェットには、次の2つのWebアプリケーションが含まれています。

- コミュニティ-ガジェットWebアプリケーション

- Shindig Webアプリケーション

- 本番コミュニティ-ガジェットには、次の3つのWebアプリケーションが含まれています。

- コミュニティ-ガジェットWebアプリケーション

- Shindig Webアプリケーション

- CAS Webアプリケーション

管理コミュニティ-ガジェットは、ユーザーが生成したコンテンツ(UGC)の管理、ガジェットの登録および同様の機能に使用されます。セキュリティ上の理由から、通常、それには内部からのみアクセスできます。ビジターは、本番コミュニティ-ガジェットに、Webページにデプロイされているウィジェットおよびガジェット・ダッシュボードを使用してアクセスします。ビジターの認証はVisitors CASを介して管理されます。

管理と本番のどちらのコミュニティ-ガジェットでも、ガジェットのレンダリングにShindig OpenSocialコンテナが使用されます。本番コミュニティ-ガジェットは、外部からアクセス可能であることが必要です。Shindig Webアプリケーションの詳細は、次のURLを参照してください。

http://shindig.apache.org/

コミュニティ-ガジェットは、そのエンド・ユーザーに対して2つのWEMアプリケーションを提供します。

- コミュニティWEMアプリケーション: コミュニティ・インタフェースを提供します。これを使用して、ビジターのコメント、レビュー、評価および投票時の投票数を収集するためのウィジェットを構成します。コミュニティWEMアプリケーションは、ユーザーが生成したコンテンツのモデレートにも使用されます。

- カジェットWEMアプリケーション: ガジェット管理者インタフェース(グローバル・カタログ)およびガジェット・ユーザー・インタフェースを提供します。ユーザーにどのインタフェースが表示されるのかは、ユーザーのロールによって決まります。どちらのインタフェースも、ガジェットの管理に使用され、それにはガジェットの登録、共有および構成とダッシュボードが含まれます。

WEM FrameworkおよびWEMアプリケーションの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』および『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。

12.2 本番および管理環境

ユーザーが生成したコンテンツを管理するために、コミュニティ-ガジェットは2つの環境を必要とします。管理環境と本番(配信)環境です。そこで管理および本番コミュニティ-ガジェット・インスタンスは、WebCenter Sitesと絶えず通信を行います。

この項の内容は、次のとおりです。

- 第12.2.1項「WebCenter Sitesの通信」

- 第12.2.2項「コミュニティ-ガジェットとWebCenter Sitesとの通信」

12.2.1 WebCenter Sitesの通信

WebCenter Sitesでは、図12-1に示すように、Webサイトのコンテンツは、すべて管理システム上で生成および管理され、本番システムにパブリッシュされます。テンプレートは、コンテンツ管理システム上で生成され、本番システムにパブリッシュされて、パブリッシュされたコンテンツの外観を構成します。

図12-1 WebCenter Sitesの通信

Webサイトのコンテンツはすべて、WebCenter Sitesコンテンツ管理システムのユーザーによって、生成、管理およびパブリッシュされます。

12.2.2 コミュニティ-ガジェットとWebCenter Sitesとの通信

コミュニティ-ガジェット・システムでのコンテンツの生成および管理のプロセスは、WebCenter Sites上のものとは異なります。それは、それらにはWebサイトのビジターなど様々なタイプのユーザーが関与し、それらすべての人がWebCenter Sitesを介して互いのコンテンツと相互作用するためです。

- ウィジェットおよびガジェットは、管理コミュニティ-ガジェット・インスタンスのユーザーによって生成され、WebCenter Sites本番システムにデプロイされます。

- コメントやレビューなどユーザーが生成するコンテンツは、コミュニティ-ガジェットの本番インスタンス上にデプロイされたウィジェットに、Webサイトのビジターによって入力されます。

- ユーザーが生成したコンテンツは、WebCenter Sitesの本番データベースに格納されます。このコンテンツは、管理コミュニティ-ガジェットの管理者およびモデレータ・ユーザーによって管理されます。

これらの相互作用全体にわたって、ウィジェット、ガジェットおよびコンテンツは、WebCenter Sitesの管理および本番データベースに格納されます。図12-2に示すように、コミュニティ-ガジェットに関与するすべてのコンテンツ生成および管理プロセスは、WebCenter Sitesを通過します。

図12-2 コミュニティ-ガジェットとWebCenter Sitesとの通信

注意:

図12-2は、ファイアウォールの使用を示しています。ファイアウォールは、WebCenter Sitesおよびコミュニティ-ガジェットによって使用されるすべてのポート上で自由な情報交換を許可する必要があります。

12.3 コミュニティ-ガジェットの構成

コミュニティ-ガジェット環境は、多くの方法で構成できます。この項では、一般的に使用される基本と本番の構成について説明します。

この項の内容は、次のとおりです。

- 第12.3.1項「基本構成」

- 第12.3.2項「本番構成」

12.3.1 基本構成

基本コミュニティ-ガジェット環境は、4つの自己完結ブロックで構成されています。コミュニティ-ガジェット(本番)、コミュニティ-ガジェット(管理)、WebCenter Sites(本番)およびWebCenter Sites(コンテンツ管理)です。これらのブロックを図12-3に示します。それらには、A、B、CおよびDのラベルが付いています。

図12-3 基本コミュニティ-ガジェット環境: 開発、ステージング、または限定的な本番環境

図12-3に示すブロックは、各ブロック内の各アプリケーションに個別のアプリケーション・サーバーが使用されるかぎり、いくつかの方法でどのような構成でもデプロイできます。

注意:

可能な構成の範囲は、4つのブロックすべてを異なるサーバー上で実行することから、1つのサーバーですべてのブロックを実行することまでです。1つのサーバーへの管理および本番アプリケーションのデプロイメントは、開発目的(本番環境ではない)の場合にのみサポートされています。

図12-3に示す構成は、開発およびステージングの場合に最適であり、一般的に使用されます。これは、ロードが限定的で、拡張性や冗長性が不要なQAおよび本番に対しても使用されることがあります。図12-3では、2つの独立したサーバーが使用されています。各サーバーには、WebCenter Sites: コミュニティ-ガジェットの1つのインスタンスおよびWebCenter Sitesの1つのインスタンスで構成された独立したスタックがあります。つまり、各サーバーには、2つの独立した(クラスタ化されていない)アプリケーション・サーバーおよび1つのローカル・データベースがあります。2つのサーバー間の通信は(セキュリティの要件に応じて)オプションのファイアウォールを通過します。

12.3.2 本番構成

本番環境へのコミュニティ-ガジェットのデプロイでは、第12.3.1項「基本構成」で説明したものと同じ4つの基本ブロックを使用します。ただし、冗長性とスケーラビリティの両方を提供するために、これらの各ブロックはサブブロックに分割されています。複数のブロックに分割することに加えて、セキュリティを向上させるためにすべての通信にHTTPSを使用することをお薦めします。

この章の残りの図では、本番環境で使用される様々なクラスタ化された構成を高度なレベルで示します。

- 図12-4は、本番環境のサンプル管理スタックを示しています。

- 図12-5は、本番環境のサンプル本番(配信)スタックを示しています。

- 図12-6は、2つのサブブロックに分割されたコミュニティ-ガジェット本番ブロックを示しています。

- 図12-7は、6つのサブブロックに分割されたコミュニティ-ガジェット本番ブロックを示しています。

図12-4 本番環境のサンプル管理スタック

図12-4は、図12-3に示した管理スタックのクラスタ化されたバージョンを示しています。

図12-4では、管理コミュニティ-ガジェット(図12-3のブロックB)がクラスタ化されています。管理WebCenter Sitesアプリケーション(図12-3のブロックD)もクラスタ化されており、データベース・クラスタが使用されます。

図12-5 本番環境のサンプル本番(配信)スタック

図12-5は、図12-3に示した本番スタックのクラスタ化されたバージョンを示しています。

図12-5では、本番コミュニティ-ガジェット(図12-3のブロックA)がクラスタ化されています。本番WebCenter Sitesアプリケーション(図12-3のブロックC)もクラスタ化されており、データベース・クラスタが使用されます。

図12-6 2つのサブブロックで構成されているコミュニティ-ガジェット本番ブロック

図12-6では、コミュニティ-ガジェット本番ブロック(図12-3のブロックA)は、2つのサーバーからなるクラスタに分割されています(これは、図12-7に示すようにサブブロックを複製するのみで任意の数のサーバーに拡張できます)。

- 各サブブロックの機能に不可欠なことは、アプリケーション・サーバーが完全にクラスタ化されており、セッション・フェイルオーバーが含まれていることです。

- 各クラスタ・メンバーには、コミュニティ-ガジェット、ShindigおよびVisitors CASに固有の構成ファイルが必要なため、ファイル・システムが各インスタンス上で複製されています。

注意:

図12-6の例では、共有ファイル・システムを使用しています。共有ファイル・システムは必須ではありませんが、関連ディレクトリを簡単にコピーできます(必要な場合)。

- 障害発生時のフェイルオーバーを提供するために、クラスタ・メンバーの前にロード・バランサが配置されています。

図12-7 6つのサブブロックで構成されているコミュニティ-ガジェット本番ブロック

図12-7では、コミュニティ-ガジェット本番ブロック(図12-3のブロックA)は、6つのサーバー上の6つのサブブロックに分割されています。このコミュニティ-ガジェット本番ブロックは、 3つの独立したクラスタで構成されています。1つはVisitors CAS用、1つはShindig用、そして1つはコミュニティ-ガジェット用です。この種類の分割は可能ですが、お薦めはしません。通常、図12-6に示すような2つのサブブロックからなる1つのクラスタで、必要な機能およびフェイルオーバーは提供され、管理オーバーヘッドも少なくなります。

- 図12-7で、各サブブロックの機能に不可欠なことは、アプリケーション・サーバーが完全にクラスタ化されており、セッション・フェイルオーバーが含まれていることです。

- 構成情報については、すべてのサーバーが同じ共有ファイル・システムにアクセスします。

注意:

図12-7の例では、共有ファイル・システムを使用しています。共有ファイル・システムは必須ではありませんが、関連ディレクトリを簡単にコピーできます(必要な場合)。

- 3つのロード・バランサが配置されています。1つはコミュニティ-ガジェット用、1つはShindigアプリケーション用、そして1つはVisitors CAS用です。

13 コミュニティ-ガジェットをインストールするための前提条件

この章では、コミュニティ-ガジェットをインストールするための前提条件を説明し、このガイドで使用されるパスおよびディレクトリのネーミング規則をリストします。

この章の内容は、次のとおりです。

- 第13.1項「コミュニティ-ガジェットをインストールする前に」

- 第13.2項「パスおよびディレクトリのネーミング規則」

13.1 コミュニティ-ガジェットをインストールする前に

コミュニティ-ガジェットをインストールする前に、この項の前提条件の手順を完了します。

この項の内容は、次のとおりです。

- 第13.1.1項「すべてのインストールの前提条件」

- 第13.1.2項「クラスタ化された環境の場合の前提条件」

- 第13.1.3項「LDAP構成の場合の前提条件」

13.1.1 すべてのインストールの前提条件

- コミュニティ-ガジェットのインストールには、WebCenter Sites、WEMフレームワーク、アプリケーション・サーバー、およびエンタープライズレベルのソフトウェアのインストールおよび構成プロセスに関する専門知識が必要です。

- コミュニティ-ガジェットのサポートされているプラットフォームおよびインストール手順に関する最新の情報について、Oracle WebCenter Sites動作保証マトリックスおよびコミュニティ-ガジェットのリリース・ノートを確認してください。

- このガイドをお読みになり、インストール・オプションを決定してください。

- コミュニティ-ガジェットは、そのネイティブ・アイデンティティ・プロバイダ(WEMフレームワークによって使用されるデータベース)とLDAPアイデンティティ・プロバイダのどちらとでも連動するようにインストールできます。

- コミュニティ-ガジェットは、グラフィカル・インストーラとサイレント・インストーラのどちらを使用してもインストールできます。

- コミュニティ-ガジェットは、シングル・ノードとして、またはクラスタの一部としてインストールできます。

- 本番(配信)サーバー上のCentral Authentication Service (CAS)アプリケーションという言葉は、すべてVisitors CASを指します。必要に応じて、管理および本番システム上のWebCenter SitesをOracle Access Manager (OAM)と統合できます。

- 各管理ノードおよび各本番ノードに、コミュニティ-ガジェットの専用のアプリケーション・サーバーがあることを確認します。

注意:

単一のアプリケーション・サーバー上へのコミュニティ-ガジェットのインストールはサポートされていません。

- コミュニティ-ガジェットには、JDK 1.6またはそれ以降のバージョンが必要です。JAVA_HOME環境変数が、JDK 1.6またはそれ以降のバージョンのパスに設定されており、それがOracle WebCenter Sites動作保証マトリックスにリストされていることを確認します。

注意:

Xサーバーが存在しないか適切に構成されていない場合、Unix/Linux/Solarisプラットフォーム上で、次のJVMパラメータを各コミュニティ-ガジェット・アプリケーション・サーバーに追加します。-Djava.awt.headless=true

- 読取り専用LDAPを使用している場合、コミュニティ-ガジェットに対して次のロールを作成します。

- ロール: Moderator

- 説明: サイト・モデレータ

コミュニティ-ガジェットによって使用される他のロール (GeneralAdmin、SiteAdminおよびDesigner)は、デフォルトでWebCenter Sitesに存在します。

- WebCenter SitesがCASまたはOAMと統合されているコンテンツ管理システムおよび本番(配信)システムで構成された完全に機能しているWebCenter Sites環境を保持していることを確認します。

注意:

コミュニティ-ガジェットをインストールした後、同じCASまたはOAMを使用してWebCenter Sitesと通信するようにコミュニティ-ガジェットを構成します。

- コミュニティWEMアプリケーションおよびガジェットWEMアプリケーションをホストするようにWebCenter Sitesシステムを準備します。

1. 管理WebCenter Sitesで、次のコンテンツ管理サイトを作成または選択します。

- <app_site>。コミュニティ-ガジェットをインストールした後に、ここにコミュニティ・ユーザー・インタフェースおよびガジェット・ユーザー・インタフェースを割り当てます。複数のサイトを作成または選択できます(コミュニティ・ユーザーおよびガジェット・ユーザー・インタフェースは、任意の数の任意のコンテンツ管理サイトに割り当てることができます)。

- <base_site>。ここには、ガジェット・グローバル・カタログ・インタフェースが割り当てられ、ガジェットを登録して他のコンテンツ管理サイトに配信するために使用されます。コミュニティ-ガジェットのインストール・プロセス中に、コミュニティ-ガジェットに対してこのサイトを指定します。選択できるサイトは1つのみです。

2. コミュニティ-ガジェットをインストールする前に、それらのサイトをWebCenter Sites本番システムにミラー・パブリッシュします。

注意:

WebCenter Sitesを介した本番コミュニティ-ガジェットと管理コミュニティ-ガジェットの間の通信をサポートするために、同一の名前が付いたコンテンツ管理サイトを作成する必要があります。

例:

- 管理サイドでは、各<app_site>は、コミュニティおよびガジェット・インタフェースを表示するために使用され、ユーザーは、そこで、ウィジェットおよびガジェットの外観を構成し、ウィジェットおよびガジェットに対するビジターの権限を設定できます。本番(配信)サイドにも同じ設定が適用されます。

- 本番(配信)サイドでは、各<app_site>は、ビジターが生成するコンテンツを格納するために使用されます。管理サイドでは、同じサイトに、モデレートおよび関連タスクのために、コミュニティ・インタフェースにビジターが生成するコンテンツが表示されます。

管理コミュニティWEMアプリケーションまたはガジェットWEMアプリケーションをWebCenter Sites管理システム上のサイトに割り当てると、本番コミュニティ-ガジェット・インスタンスが、WebCenter Sites本番システム上の同じサイトに自動的に割り当てられます。これで、本番コミュニティ-ガジェットが、管理コミュニティ-ガジェットと通信できるようになります。

- WebCenter Sites本番システムで、次のようにして検索を有効化します。Lucene検索エンジンを起動します。『Oracle Fusion Middleware WebCenter Sites開発者ガイド』の手順を参照して、検索索引付けを構成します。

13.1.2 クラスタ化された環境の場合の前提条件

クラスタ化された環境アプリケーションをインストールする場合は、ロード・バランサが構成されていることを確認します。

13.1.3 LDAP構成の場合の前提条件

LDAPアイデンティティ・プロバイダを使用する場合は、次の手順を完了します。

1. 次のいずれかを実行します。

- 新しいLDAPサーバーを使用する場合は、サポートされているLDAPサーバーをインストールおよび構成します。

- 既存のLDAPサーバーを使用する場合は、新しいベースdnを作成し、コミュニティ-ガジェット・ビジター用に提供します。

2. LDIFファイルを作成し、{ldap_basedn}をご使用のシステムの値に置き換えます。ユーザーごとに# add user entryをコピーすることで、複数のユーザーをインポートできます。
例:

dn: {ldap_basedn}
objectclass: dcObject
objectclass: organization
dc: oracle
description: OpenLDAP pre_cg_setup
o: Oracle Software

# add user
dn: cn=<user_name>,{ldap_basedn}
objectClass: inetOrgPerson
objectClass: top
userPassword: <user_password>
cn: <user_name>
sn: <user_name>
displayName: <user_name>
mail: <user_email>
description: <user_description>

13.2 パスおよびディレクトリのネーミング規則

表13-1は、コミュニティ-ガジェット・インストール手順で使用されるパスおよびディレクトリのネーミング規則を示しています。

表13-1 このガイドで使用されるパスおよびディレクトリの名前

規則

説明

<cg_install_dir>

コミュニティ-ガジェットのインストール先となるディレクトリのパス。

<WL_HOME>

WebLogicがインストールされているディレクトリのパス。パスには、ディレクトリの名前が含まれます。

<TC_HOME>

Tomcatがインストールされているディレクトリのパス。パスには、ディレクトリの名前が含まれます。

<WS_HOME>

WebSphereがインストールされているディレクトリのパス。パスには、ディレクトリの名前が含まれます。

<ServerA>

一意のホスト名およびIPアドレスを持つサーバーAを表します。

<ServerB>

一意のホスト名およびIPアドレスを持つサーバーBを表します。

<cgA_Mi>

管理コミュニティ-ガジェット(Shindigを含む)のデプロイ先となるアプリケーション・サーバーのパス。

- Aは、アプリケーション・サーバーがインストールされているサーバーを表します(この場合は、<ServerA>)。

- Mは、管理コミュニティ-ガジェットを表します。

- iは、管理コミュニティ-ガジェットのi番目のインスタンスを表します。

<cgB_Pi>

本番コミュニティ-ガジェット(ShindigおよびVisitors CASを含む)のデプロイ先となるアプリケーション・サーバー・インスタンスのパス。

- Bは、アプリケーション・サーバーがインストールされているサーバーを表します(この場合は、<ServerB>)。

- Pは、本番コミュニティ-ガジェットを表します。

- iは、本番コミュニティ-ガジェットのi番目のインスタンスを表します。

<base_site>

コンテンツ管理サイト。ガジェット・グローバル・カタログ・インタフェース用に使用されます。ビジターのプロファイル・データの格納用でもあります。

これは、コミュニティ-ガジェットのインストール・プロセス中に、インストーラ画面の1つで、コミュニティ-ガジェットのアプリケーション・サイトとして指定されます。

選択できるサイトは1つのみです。

<app_site>

コンテンツ管理サイト。コミュニティ・ユーザー・インタフェースおよびガジェット・ユーザー・インタフェース用に使用されます。

複数サイトがサポートされています。

14 コミュニティ-ガジェットに対するアプリケーション・サーバーの構成

この章では、コミュニティ-ガジェット・アプリケーションのクラスタ化されていないデプロイメントおよびクラスタ化されたデプロイメントをサポートするためのアプリケーション・サーバーの構成手順を説明します。

この章の内容は、次のとおりです。

- 第14.1項「コミュニティ-ガジェットのデプロイメントの概要」

- 第14.2項「クラスタ化されていないデプロイメント用のアプリケーション・サーバーの構成」

- 第14.3項「クラスタ化されたデプロイメント用のアプリケーション・サーバーの構成」

14.1 コミュニティ-ガジェットのデプロイメントの概要

コミュニティ-ガジェット・アプリケーションは数多くの方法でデプロイできます。インストールのために、次のようなデュアルサーバー構成を使用します。

- クラスタ化されていないデプロイメント
このガイドでは、2つのサーバーにコミュニティ-ガジェットをデプロイします。管理コミュニティ-ガジェットは<ServerA>にデプロイし、本番コミュニティ-ガジェットは<ServerB>にデプロイします。

- クラスタ化されたデプロイメント
コミュニティ-ガジェットは、水平または垂直のいずれかのクラスタ化アプリケーションとしてデプロイできます。このガイドでは、次のようにコミュニティ-ガジェットを垂直にクラスタ化します。管理コミュニティ-ガジェットは<ServerA>上のクラスタとしてデプロイし、本番コミュニティ-ガジェットは<ServerB>上のクラスタとしてデプロイします。水平クラスタリングは、前述の構成を、必要な数の追加サーバー上に複製することで実現できます。

14.2 クラスタ化されていないデプロイメント用のアプリケーション・サーバーの構成

この項では、クラスタ化されていないコミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするように、選択したアプリケーション・サーバーを構成する手順について説明します。

この項では、次の構成について説明します。

- 第14.2.1項「Apache Tomcatの構成」

- 第14.2.2項「Oracle WebLogic Application Serverの構成」

- 第14.2.3項「IBM WebSphere Application Serverの構成」

注意:

この項では、クラスタ化されていないコミュニティ-ガジェットをサポートするようにアプリケーション・サーバーを構成します。第12章「コミュニティ-ガジェットの概要」の説明のように、クラスタ化されていないシステムを構成する方法は複数あります。例を示すために、この項の手順では、第14.1項「コミュニティ-ガジェットのデプロイメントの概要」に示すように、2つのサーバーへのコミュニティ-ガジェット・アプリケーションのデプロイメントについて説明します。

この項の内容は、次のとおりです。

- 第14.2.1項「Apache Tomcatの構成」

- 第14.2.2項「Oracle WebLogic Application Serverの構成」

- 第14.2.3項「IBM WebSphere Application Serverの構成」

14.2.1 Apache Tomcatの構成

この項では、次のようにクラスタ化されていないコミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするようにApache Tomcatを構成します。

1. <ServerA>の場合:

1. 管理コミュニティ-ガジェット・アプリケーションをデプロイするTomcatインスタンス(<cgA_M1>)を作成します。

2. <cgA_M1>/binのcatalina.shを編集し、最初のコメント・ブロックの後に次の行を追加します。

CATALINA_HOME=<cgA_M1>

2. <ServerB>の場合:

1. 本番コミュニティ-ガジェット・アプリケーションをデプロイするTomcatインスタンス(<cgB_P1>)を作成します。

2. <cgB_P1>/binのcatalina.shを編集し、最初のコメント・ブロックの後に次の行を追加します。

CATALINA_HOME=<cgB_P1>

3. 第15章「コミュニティ-ガジェット・デプロイメント・ファイルの生成」に続きます。

14.2.2 Oracle WebLogic Application Serverの構成

この項では、クラスタ化されていないコミュニティ-ガジェットのデプロイメントをサポートするようにWebLogic Application Serverを構成します。

注意:

マシンおよび管理対象サーバーは、WebLogicドメイン構成ユーティリティの一部として作成するか、対応するドメインのWebLogic管理コンソールから別に作成できます。WebLogicドメインの構成の詳しい手順については、Oracle WebLogic Application Serverのドキュメントを参照してください。

クラスタ化されていない管理コミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするには、次の手順を完了します。

1. <ServerA>上で、ドメイン構成ユーティリティを使用し、ドメイン、新しいマシンおよび新しい管理対象サーバーを作成します。

たとえば、Linuxを使用している場合、次のようにします。

cd <WL_HOME>/wlserver_10.3/common/bin
./config.sh

参考のため、このガイドで使用する構成を、表14-1、表14-2および表14-3に示します。

表14-1 管理コミュニティ-ガジェットに対するWebLogicドメインの構成例

プロパティ

値

ドメイン名

<cgMgmt>

管理サーバー

<ServerA>

管理サーバー・ポート

例: 7001

または、ご使用の構成に適した値を使用します。

表14-2 管理コミュニティ-ガジェットに対するWebLogicマシンの構成例

プロパティ

値

マシン名

<wlcgA_M>

リスニング・アドレス

<ServerA>

リスニング・ポート

例: 5556

または、ご使用の構成に適した値を使用します。

表14-3 管理コミュニティ-ガジェットに対するWebLogic管理対象サーバーの構成例

プロパティ

値

管理対象サーバー

<cgA_M1>

ドメイン

<cgMgmt>

リスニング・アドレス

<ServerA>

リスニング・ポート

例: 7003

または、ご使用の構成に適した値を使用します。

マシン

<wlcgA_M>

2. 同様に、クラスタ化されていない本番コミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするように、次のようにWebLogic Application Serverを構成します。

<ServerB>上で、ドメイン構成ユーティリティを使用し、ドメイン、新しいマシンおよび新しい管理対象サーバーを作成します。

参考のため、このガイドで使用する構成を、表14-4、表14-5および表14-6に示します。

表14-4 本番コミュニティ-ガジェットに対するWebLogicドメインの構成例

プロパティ

値

ドメイン名

<cgProd>

管理サーバー

<ServerB>

管理サーバー・ポート

例: 7001

または、ご使用の構成に適した値を使用します。

表14-5 本番コミュニティ-ガジェットに対するWebLogicマシンの構成例

プロパティ

値

マシン名

<wlcgB_P>

リスニング・アドレス

<ServerB>

リスニング・ポート

例: 5556

または、ご使用の構成に適した値を使用します。

表14-6 本番コミュニティ-ガジェットに対するWebLogic管理対象サーバーの構成例

プロパティ

値

管理対象サーバー

<cgB_P1>

ドメイン

<cgProd>

リスニング・アドレス

<ServerB>

リスニング・ポート

例: 7003

または、ご使用の構成に適した値を使用します。

マシン

<wlcgB_P>

3. 手順1および2の各サーバーに対して、次のようにします。

1. 「トンネリングの有効化」を選択します。

2. 「ホスト名の検証」に対して「なし」を選択します。

4. ドメインごとに、コミュニティ-ガジェット・アプリケーションをステージングするためのディレクトリを作成します。このガイドでは、次のパスにapplicationsという名前のディレクトリを作成します。

<WL_HOME>/user_projects/domains/cgMgmt/applications
<WL_HOME>/user_projects/domains/cgProd/applications

5. 第15章「コミュニティ-ガジェット・デプロイメント・ファイルの生成」に続きます。

14.2.3 IBM WebSphere Application Serverの構成

この項では、クラスタ化されていないコミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするようにIBM WebSphere Application Serverを構成します。

注意:

IBM WebSphere Application Serverの構成の詳しい手順については、ベンダーのドキュメントを参照してください。

1. 管理コミュニティ-ガジェット・アプリケーションをデプロイするノードを作成し、そのノードをデプロイメント・マネージャにフェデレートします。
デプロイメント・マネージャを構成していない場合は、デプロイメント・マネージャおよびアプリケーション・サーバー・プロファイルを作成し、そのノードを、作成したデプロイメント・マネージャ・プロファイルにフェデレートします。

参照のため、このガイドで使用する構成を、表14-7および表14-8に示します。

表14-7 管理コミュニティ-ガジェットに対するWebSphereプロファイルの構成例

プロパティ

値

Deployment Manager Profile

<Dmgr01>

Host Server

<ServerA>

Deployment Manager Admin Server Port

例: 9060

または、ご使用の構成に適した値を使用します。

表14-8 管理コミュニティ-ガジェットに対するWebSphere Application Serverの構成例

プロパティ

値

Application Server Name

<cgA_M1>

Profile

<AppSrv01>

Node

<ServerA_Node01>

リスニング・アドレス

<ServerA>

リスニング・ポート

例: 9080

または、ご使用の構成に適した値を使用します。

2. 同様に、本番コミュニティ-ガジェット・アプリケーションをデプロイするノードを作成し、そのノードをデプロイメント・マネージャにフェデレートします。
参照のため、このガイドで使用する構成を、表14-9および表14-10に示します。

表14-9 本番コミュニティ-ガジェットに対するWebSphereプロファイルの構成例

プロパティ

値

Deployment Manager Profile

<Dmgr01>

Host Server

<ServerA>

Deployment Manager Admin Server Port

例: 9060

または、ご使用の構成に適した値を使用します。

表14-10 本番コミュニティ-ガジェットに対するWebアプリケーション・サーバー・プロファイルの構成例

プロパティ

値

Application Server Name

<cgB_P1>

Profile

<AppSrv02>

Node

<ServerB_Node02>

リスニング・アドレス

<ServerB>

リスニング・ポート

例: 9080

または、ご使用の構成に適した値を使用します。

3. 第15章「コミュニティ-ガジェット・デプロイメント・ファイルの生成」に続きます。

14.3 クラスタ化されたデプロイメント用のアプリケーション・サーバーの構成

この項では、コミュニティ-ガジェット・アプリケーションのクラスタ化されたデプロイメントをサポートするためのサポートされているアプリケーション・サーバーの構成について説明します。

この項では、次のクラスタ化されたデプロイメント構成について説明します。

- 第14.3.1項「Apache Tomcatの構成(クラスタ化されている)」

- 第14.3.2項「Oracle WebLogic Application Serverの構成(クラスタ化されている)」

- 第14.3.3項「IBM WebSphere Application Serverの構成(クラスタ化されている)」

注意:

この項では、クラスタ化されたコミュニティ-ガジェット・インストールをサポートするようにアプリケーション・サーバーを構成します。第12章「コミュニティ-ガジェットの概要」の説明のように、クラスタ化されたシステムを構成する方法は複数あります。例を示すために、この項の手順では、第14.1項「コミュニティ-ガジェットのデプロイメントの概要」に示すように、コミュニティ-ガジェット・アプリケーションの垂直クラスタリングについて説明します。

14.3.1 Apache Tomcatの構成(クラスタ化されている)

この項では、クラスタ化されたコミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするようにApache Tomcatを構成します。

1. <ServerA>の場合:

1. 管理コミュニティ-ガジェット・アプリケーションをデプロイするTomcatインスタンス(<cgA_M1>)を作成します。<cgA_M1>/binのcatalina.shを編集し、最初のコメント・ブロックの後に次の行を追加します。

CATALINA_HOME=<cgA_M1>

2. 管理コミュニティ-ガジェット・アプリケーションをデプロイするTomcatインスタンス(<cgA_M2>)を作成します。<cgA_M2>/binのcatalina.shを編集し、最初のコメント・ブロックの後に次の行を追加します。

CATALINA_HOME=<cgA_M2>

3. server.xmlファイルを編集し、ポートの競合が起こらないようにします。

2. <ServerB>の場合:

1. 本番コミュニティ-ガジェット・アプリケーションをデプロイするTomcatインスタンス(<cgB_P1>)を作成します。<cgB_P1>/binのcatalina.shを編集し、最初のコメント・ブロックの後に次の行を追加します。

CATALINA_HOME=<cgB_P1>

2. 本番コミュニティ-ガジェット・アプリケーションをデプロイするTomcatインスタンス(<cgB_P2>)を作成します。<cgB_P2>/binのcatalina.shを編集し、最初のコメント・ブロックの後に次の行を追加します。

CATALINA_HOME=<cgB_P2>

3. server.xmlファイルを編集し、ポートの競合が起こらないようにします。
前述の手順を完了した後、Tomcat構成は、表14-11の例に似たものになります。

表14-11 コミュニティ-ガジェット・アプリケーションに対するTomcatの構成例

ホスト

Tomcatインスタンス

ポート番号

<ServerA>

<cgA_M1>

8080

<ServerA>

<cgA_M2>

8180

<ServerB>

<cgB_P1>

8080

<ServerB>

<cgB_P2>

8180

3. server.xmlファイルを編集することでアプリケーション・サーバー・クラスタを構成します。<ServerA>および<ServerB>に対して、次の手順に従ってください。

1. 各クラスタ・メンバーに対して、次のコードをserver.xmlファイルに追加することで、クラスタリング機能を追加します(コードの詳細は、Apache Tomcatのドキュメントを参照してください)。

<Cluster className=
"org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">
<Manager className=
"org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>

<Channel className=
"org.apache.catalina.tribes.group.GroupChannel">
<Membership className=
"org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>

<Receiver className=
"org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>

<Sender className=
"org.apache.catalina.tribes.transport.
ReplicationTransmitter">
<Transport className=
"org.apache.catalina.tribes.transport.nio.
PooledParallelSender"/>
</Sender>

<Interceptor className=
"org.apache.catalina.tribes.group.interceptors.
TcpFailureDetector"/>
<Interceptor className=
"org.apache.catalina.tribes.group.interceptors.
MessageDispatch15Interceptor"/>
</Channel>

<Valve className=
"org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className=
"org.apache.catalina.ha.session.
JvmRouteBinderValve"/>

<Deployer className=
"org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>

<ClusterListener className=
"org.apache.catalina.ha.session.
JvmRouteSessionIDBinderListener"/>
<ClusterListener className=
"org.apache.catalina.ha.session.
ClusterSessionListener"/>
</Cluster>

2. AJPを使用したロード・バランシングを有効化するには、server.xmlファイルでEngine行を見つけ、サーバー・インスタンスのjvmRouteを追加します。たとえば、行<Engine name="Catalina" defaultHost="localhost">にjvmrouteを含め、そのサーバーにjvm1を指定するには、jvmRoute="jvm1"を<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">のように追加します。
各サーバーは、一意のjvmRoute名を持っている必要があります。

3. 同じクラスタに属しているTomcatインスタンスのすべてが、Membershipタグのマルチキャストaddressおよびportについて同じ値を持っていることを確認します。たとえば、<cgB_P1>および<cgB_P2>のマルチキャスト・アドレスおよびポートは同じ値になっている必要があります。

4. 異なるクラスタに属しているTomcatインスタンスのすべてが、クラスタ間で一意のマルチキャスト・アドレスまたはポート番号(Membershipタグ内)を持っていることを確認します。たとえば、<cgA_M1>/<cgA_M2>クラスタ内のすべてのTomcatインスタンスは、<cgB_P1>/<cgB_P2>クラスタ内のTomcatインスタンスのマルチキャスト・アドレスまたはポート番号と異なるマルチキャスト・アドレスまたはポート番号を持っている必要があります。

5. 垂直クラスタの場合は、同じサーバー上に配置されているすべてのTomcatインスタンスが、Receiverタグのportパラメータに対して異なる値を持っていることを確認します。

6. マルチホーム・サーバーを使用している場合、Receiverタグのaddressパラメータの値として(自動的なもののかわりに)正確なIPアドレスまたはホスト名を入力します。

4. すべてのTomcatインスタンス上で、<web-app>タグ内の<distributable/>タグを<TC_HOME>/conf/web.xmlファイルに追加します。

5. 第15章「コミュニティ-ガジェット・デプロイメント・ファイルの生成」に続きます。

14.3.2 Oracle WebLogic Application Serverの構成(クラスタ化されている)

この項では、クラスタ化されたコミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするようにWebLogic Application Serverを構成します。

注意:

マシンおよび管理対象サーバーは、WebLogicドメイン構成ユーティリティの一部として作成するか、対応するドメインのWebLogic管理コンソールから別に作成できます。WebLogicドメインの構成の詳しい手順については、Oracle WebLogic Application Serverのドキュメントを参照してください。

1. クラスタ化された管理コミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするには、次の手順を完了します。
<ServerA>上で、ドメイン構成ユーティリティを使用し、ドメイン、新しいマシン、新しい管理対象サーバーおよびクラスタを作成します。

たとえば、Linuxを使用している場合、次のようにします。

cd <WL_HOME>/wlserver_10.3/common/bin
./config.sh

参考のため、このガイドで使用する構成を、表14-12、表14-13、表14-14および表14-15に示します。

表14-12 管理コミュニティ-ガジェットに対するWebLogicドメインの構成例(クラスタ化されている)

プロパティ

値

ドメイン名

<cgMgmt>

管理サーバー

<ServerA>

管理サーバー・ポート

例: 7001

または、ご使用の構成に適した値を使用します。

表14-13 管理コミュニティ-ガジェットに対するWebLogicマシンの構成例(クラスタ化されている)

プロパティ

値

マシン名

<wlcgA_M>

リスニング・アドレス

<ServerA>

リスニング・ポート

例: 5556

または、ご使用の構成に適した値を使用します。

表14-14 管理コミュニティ-ガジェットに対するWebLogic管理対象サーバーの構成例(クラスタ化されている)

プロパティ

値

管理対象サーバー1

<cgA_M1>

ドメイン

<cgMgmt>

リスニング・アドレス

<ServerA>

リスニング・ポート

例: 7003

または、ご使用の構成に適した値を使用します。

マシン

<wlcgA_M>

管理対象サーバー2

<cgA_M2>

ドメイン

<cgMgmt>

リスニング・アドレス

<ServerA>

リスニング・ポート

例: 7005

または、ご使用の構成に適した値を使用します。

マシン

<wlcgA_M>

表14-15 管理コミュニティ-ガジェットに対するWebLogicクラスタの構成例(クラスタ化されている)

プロパティ

値

クラスタ名

<wlcg_M>

クラスタ・アドレス

<ServerA>

クラスタのメッセージング・モード

ユニキャスト(または、環境に応じてマルチキャスト)

クラスタの一部としての管理対象サーバー

<cgA_M1>、<cgA_M2>

2. 同様に、クラスタ化された本番コミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするようにWebLogic Application Serverを構成します。
<ServerB>上で、ドメイン構成ユーティリティを使用し、ドメイン、新しいマシン、新しい管理対象サーバーおよびクラスタを作成します。

参考のため、このガイドで使用する構成を、表14-16、表14-17、表14-18および表14-19に示します。

表14-16 本番コミュニティ-ガジェットに対するWebLogicドメインの構成例(クラスタ化されている)

プロパティ

値

ドメイン名

<cgProd>

管理サーバー

<ServerB>

管理サーバー・ポート

例: 7001

または、ご使用の構成に適した値を使用します。

表14-17 本番コミュニティ-ガジェットに対するWebLogicマシンの構成例(クラスタ化されている)

プロパティ

値

マシン名

<wlcgB_P>

リスニング・アドレス

<ServerB>

リスニング・ポート

例: 5556

または、ご使用の構成に適した値を使用します。

表14-18 本番コミュニティ-ガジェットに対するWebLogic管理対象サーバーの構成例(クラスタ化されている)

プロパティ

値

管理対象サーバー1

<cgB_P1>

ドメイン

<cgProd>

リスニング・アドレス

<ServerB>

リスニング・ポート

例: 7003

または、ご使用の構成に適した値を使用します。

マシン

<wlcgB_P>

管理対象サーバー2

<cgB_P2>

ドメイン

<cgProd>

リスニング・アドレス

<ServerB>

リスニング・ポート

例: 7005

または、ご使用の構成に適した値を使用します。

マシン

<wlcgB_P>

表14-19 本番コミュニティ-ガジェットに対するWebLogicクラスタの構成例(クラスタ化されている)

プロパティ

値

クラスタ名

<wlcg_P>

クラスタ・アドレス

<ServerB>

クラスタのメッセージング・モード

ユニキャスト(または、環境に応じてマルチキャスト)

クラスタの一部としての管理対象サーバー

<cgB_P1>、<cgB_P2>

3. <ServerA>および<ServerB>上に作成された管理対象サーバーごとに、次のようにします。

1. 「トンネリングの有効化」を選択します。

2. 「ホスト名の検証」に対して「なし」を選択します。

4. ドメインごとに、コミュニティ・アプリケーションをステージングするためのディレクトリを作成します。このガイドでは、次のパスにapplicationsという名前のディレクトリを作成します。

<WL_HOME>/user_projects/domains/cgMgmt/applications
<WL_HOME>/user_projects/domains/cgProd/applications

5. クラスタごとに、その詳細クラスタ構成セクションに移動し、「WebLogicプラグインの有効化」パラメータを選択します。

6. 第15章「コミュニティ-ガジェット・デプロイメント・ファイルの生成」に続きます。

14.3.3 IBM WebSphere Application Serverの構成(クラスタ化されている)

この項では、クラスタ化されたコミュニティ-ガジェット・アプリケーションのデプロイメントをサポートするようにWebSphere Application Serverを構成します。

注意:

IBM WebSphere Application Serverの構成の詳しい手順、つまりプロファイルの作成またはノードのフェデレートの詳細は、ベンダーのドキュメントを参照してください。

1. 管理コミュニティ-ガジェット・アプリケーションをデプロイするノードを作成し、そのノードをデプロイメント・マネージャにフェデレートします。
デプロイメント・マネージャを構成していない場合は、デプロイメント・マネージャおよびアプリケーション・サーバー・プロファイルを作成し、そのノードを、作成したデプロイメント・マネージャ・プロファイルにフェデレートします。

参照のため、このガイドで使用する構成を、表14-20および表14-21に示します。

表14-20 管理コミュニティ-ガジェットに対するWebSphereプロファイルの構成例(クラスタ化されている)

プロパティ

値

Deployment Manager Profile

<Dmgr01>

Host Server

<ServerA>

Deployment Manager Admin Server Port

例: 9060

または、ご使用の構成に適した値を使用します。

表14-21 管理コミュニティ-ガジェットに対するWebSphere Application Serverの構成例(クラスタ化されている)

プロパティ

値

Application Server Name

<cgA_M1>

Profile

<AppSrv01>

Node

<ServerA_Node01>

リスニング・アドレス

<ServerA>

リスニング・ポート

例: 9080

または、ご使用の構成に適した値を使用します。

Application Server Name

<cgA_M2>

Profile

<AppSrv01>

Node

<ServerA_Node01>

リスニング・アドレス

<ServerA>

リスニング・ポート

例: 9081

または、ご使用の構成に適した値を使用します。

2. 同様に、本番コミュニティ-ガジェット・アプリケーションをデプロイするノードを作成し、そのノードをデプロイメント・マネージャにフェデレートします。
参照のため、このガイドで使用する構成を、表14-22および表14-23に示します。

表14-22 本番コミュニティ-ガジェットに対するWebSphereプロファイルの構成例(クラスタ化されている)

プロパティ

値

Deployment Manager Profile

<Dmgr01>

Host Server

<ServerA>

Deployment Manager Admin Server Port

例: 9060

または、ご使用の構成に適した値を使用します。

表14-23 本番コミュニティ-ガジェットに対するWebSphere Application Serverの構成例(クラスタ化されている)

プロパティ

値

Application Server 1 Name

<cgB_P1>

Profile

<AppSrv02>

Node

<ServerB_Node02>

リスニング・アドレス

<ServerB>

リスニング・ポート

例: 9080

または、ご使用の構成に適した値を使用します。

Application Server 2 Name

<cgB_P2>

Profile

<AppSrv02>

Node

<ServerB_Node02>

リスニング・アドレス

<ServerB>

リスニング・ポート

例: 9081

または、ご使用の構成に適した値を使用します。

3. WebSphere管理コンソールを使用して2つの新しいクラスタ(表14-24を参照)を作成します。
例:

http://<ServerA>:9060/ibm/console

表14-24 コミュニティ-ガジェットに対するWebSphereクラスタの構成例

構成

プロパティ

値

クラスタ1

クラスタ名

<wscg_M>

クラスタ1

Configure HTTP memory-to-memory replication

Yes

クラスタ1

Cluster Members

<cgA_M1>、<cgA_M2>

クラスタ2

クラスタ名

<wscg_P>

クラスタ2

Configure HTTP memory-to-memory replication

Yes

クラスタ2

Cluster Members

<cgB_P1>、<cgB_P2>

4. <ServerA>および<ServerB>上に作成された管理対象サーバーごとに、WebSphere管理コンソールで次の手順を完了します。

1. メモリー間複製を設定します。

2. 「Web Container Settings」の下に、次のカスタム・プロパティを追加します。

Name: HttpSessionCloneId
Value: 11111111 (8-9 characters, unique for each managed server)

5. レプリケーション・ドメインをカスタマイズする場合、管理コンソールを使用します(左側のフレームで「Environment」→「Replication domains」を選択します)。

6. すべてのクラスタ・メンバーに対してポートを追加します(「Environment」に移動し、「Virtual hosts」→「default_host」→「Host Aliases」を選択し、ポートを追加します)。

7. 第15章「コミュニティ-ガジェット・デプロイメント・ファイルの生成」に続きます。

15 コミュニティ-ガジェット・デプロイメント・ファイルの生成

この章では、コミュニティ-ガジェットwar/ earファイルをグラフィカルに生成する方法とサイレントに生成する方法について説明します。

この章の内容は、次のとおりです。

- 第15.1項「コミュニティ-ガジェット・デプロイメント・ファイルのグラフィカルな生成」

- 第15.2項「コミュニティ-ガジェット・デプロイメント・ファイルのサイレントな生成」

- 第15.3項「コミュニティ-ガジェット・インストール・ディレクトリ構造の検証」

15.1 コミュニティ-ガジェット・デプロイメント・ファイルのグラフィカルな生成

グラフィカル・インストーラは、コミュニティ-ガジェット・インストール・ディレクトリを作成し、デプロイメント用のwar/earファイルを生成する構成ウィザードです。

コミュニティ-ガジェット・デプロイメント・ファイルをグラフィカルに生成するには、次の手順に従います。

注意:

この項では、WebCenter Sitesの管理インスタンスをOAMと統合する場合に必要な手順についても説明します。

1. コミュニティ-ガジェット配布zipファイルをサーバーにダウンロードし、それを一時ディレクトリに抽出します。抽出されたフォルダには、cgInstall.batおよびcgInstall.shファイルが含まれており、それらは、コミュニティ-ガジェット・インストーラを実行するために必要です。

2. インストール・ディレクトリを作成します。その中に、コミュニティ-ガジェット・インストーラによって、必要なフォルダおよびファイルが作成されます。

3. JAVA_HOMEを、JDK 1.6またはそれ以降のバージョンのパスに設定します。
例:

export JAVA_HOME=/opt/jdk1.6.0_43

4. リモートUNIX環境で、DISPLAY環境変数を設定します。
例:

export DISPLAY=10.120.15.20:0.0

5. 次のインストーラ・スクリプトを実行します。

- Windowsの場合: cgInstall.bat

- UNIXの場合: cgInstall.sh

6. 初期画面(図15-1)が表示されます。「次へ」をクリックします。

図15-1 インストーラの初期画面

7. 「インストール・ディレクトリ」画面(図15-2)で、コミュニティ-ガジェット・アプリケーションのインストール先となるディレクトリ(手順2で作成)のパスを指定するか、「参照」をクリックしてディレクトリに移動します。
パスには、空白を含めないでください。指定したディレクトリが存在しない場合は、インストーラによって作成されます。

図15-2 インストール・ディレクトリ

8. 管理CG情報画面(図15-3)で、次のようにします。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- 管理コミュニティ-ガジェット・アプリケーション・サーバーのホスト名またはIPアドレスを入力します。クラスタをインストールする場合は、ロード・バランサのホスト名またはIPアドレスを入力します。

注意:

管理システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、Oracle HTTP Serverホストの名前またはIPアドレスを指定します。

- 管理コミュニティ-ガジェット・アプリケーション・サーバーのポート番号を入力します。クラスタをインストールする場合は、ロード・バランサのポート番号を入力します。

注意:

管理システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、Oracle HTTP Serverのポートを指定します。

- 管理コミュニティ-ガジェット・アプリケーションのコンテキスト・ルートを入力します。

図15-3 管理CG情報

9. 管理Shindig情報画面(図15-4)で、次のようにします。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- 管理Shindigアプリケーション・サーバーのホスト名またはIPアドレスを入力します。クラスタをインストールする場合は、ロード・バランサのホスト名またはIPアドレスを入力します。

注意:

管理システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、Oracle HTTP Serverホストの名前またはIPアドレスを指定します。

- 管理Shindigアプリケーション・サーバーのポート番号を入力します。クラスタをインストールする場合は、ロード・バランサのポート番号を入力します。

注意:

管理システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、Oracle HTTP Serverのポートを指定します。

- 管理Shindigアプリケーションのコンテキスト・ルートを入力します。

図15-4 管理Shindig情報

10. 本番CG情報画面(図15-5)で、次のようにします。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- 本番コミュニティ-ガジェット・アプリケーション・サーバーのホスト名またはIPアドレスを入力します。クラスタをインストールする場合は、ロード・バランサのホスト名またはIPアドレスを入力します。

- 本番コミュニティ-ガジェット・アプリケーション・サーバーのポート番号を入力します。クラスタをインストールする場合は、ロード・バランサのポート番号を入力します。

- 本番コミュニティ-ガジェット・アプリケーションのコンテキスト・ルートを入力します。

図15-5 本番CG情報

11. 本番Shindig情報画面(図15-6)で、次のようにします。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- 本番Shindigアプリケーション・サーバーのホスト名またはIPアドレスを入力します。クラスタをインストールする場合は、ロード・バランサのホスト名またはIPアドレスを入力します。

- 本番Shindigアプリケーション・サーバーのポート番号を入力します。クラスタをインストールする場合は、ロード・バランサのポート番号を入力します。

- 本番Shindigアプリケーションのコンテキスト・ルートを入力します。

図15-6 本番CG情報

12. Visitors CAS Server情報画面(図15-7)で次のようにします。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- Visitors CASアプリケーション・サーバーのホスト名またはIPアドレスを入力します。クラスタをインストールする場合は、ロード・バランサのホスト名またはIPアドレスを入力します。

- Visitors CASアプリケーション・サーバーのポート番号を入力します。クラスタをインストールする場合は、ロード・バランサのポート番号を入力します。

- Visitors CASアプリケーションのコンテキスト・ルートを入力します。

- Visitors CASのデプロイ先となるサーバーのホスト名またはIPアドレスを入力します。

- クラスタ化されていないインストールの場合、このフィールドの値は前述のフィールドの値(Visitors CASのホスト名)と同一です。

- クラスタ化されたインストールの場合、このフィールドの値はVisitors CASアプリケーション・サーバーのホスト名です。(前述のフィールドのVisitors CASのホスト名の値が、ロード・バランサのホスト名またはIPアドレスに設定されていることを確認してください。)

図15-7 Visitors CAS Server情報

13. アプリケーション・サイト画面(図15-8)で、管理WebCenter Sitesインスタンス上にガジェット・グローバル・カタログ・インタフェースを表示するためと、本番Sitesインスタンスにビジターのプロファイル・データを格納するために使用される<base_site>の名前を入力します。(「ガジェット」ユーザー・インタフェースおよび「コミュニティ」ユーザー・インタフェースは、どのサイト<app_site>でも使用できます。)

図15-8 アプリケーション・サイト

14. 管理Sites情報画面(図15-9)で、次のようにします。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- 管理WebCenter Sitesアプリケーション・サーバーのホスト名またはIPアドレスを入力します。

注意:

管理システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、Oracle HTTP Serverホストの名前またはIPアドレスを指定します。

- 管理WebCenter Sitesアプリケーション・サーバーのポート番号を入力します。

- 注意:
管理システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、Oracle HTTP Serverのポートを指定します。

- 管理WebCenter Sitesアプリケーションのコンテキスト・ルートを入力します。

図15-9 管理Sites情報

15. 管理Sites管理ユーザー画面(図15-10)で、次のようにします。

- 一般管理者ユーザー名を入力します。これを使用して、WebCenter Sites管理システムにログインします。
ユーザー名は、大文字小文字が区別され、8から64個までの英数字を使用できます。デフォルト・ユーザー: fwadmin

- 管理者パスワードを入力します。
パスワードは、大文字小文字が区別され、8から64個までの英数字を使用できます。

- 確認のため、パスワードを再入力します。

図15-10 管理Sites管理ユーザー

16. 管理Sites CAS情報画面(図15-11)で、次のようにします。

注意:

管理システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、デフォルト値を受け入れ、「次へ」をクリックし、手順17に進みます。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- 管理Sites CASアプリケーション・サーバーのホスト名またはIPアドレスを入力します。

- 管理Sites CASアプリケーション・サーバーのポート番号を入力します。

- 管理Sites CASアプリケーションのコンテキスト・ルートを入力します。

図15-11 管理Sites CAS情報

17. 本番Sites情報画面(図15-12)で、次のようにします。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- 本番WebCenter Sitesアプリケーション・サーバーのホスト名またはIPアドレスを入力します。

注意:

本番システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、Oracle HTTP Serverホストの名前またはIPアドレスを指定します。

- 本番WebCenter Sitesアプリケーション・サーバーのポート番号を入力します。

注意:

本番システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、Oracle HTTP Serverホストのポートを指定します。

- 本番WebCenter Sitesアプリケーションのコンテキスト・ルートを入力します。

図15-12 本番Sites情報

18. 本番Sites管理ユーザー画面(図15-13)で、次のようにします。

- 一般管理者ユーザー名を入力します。これを使用して、WebCenter Sites本番システムにログインします。
ユーザー名は、大文字小文字が区別され、8から64個までの英数字を使用できます。デフォルト・ユーザー: fwadmin

- 管理者パスワードを入力します。
パスワードは、大文字小文字が区別され、8から64個までの英数字を使用できます。

- 確認のため、パスワードを再入力します。

図15-13 本番Sites管理ユーザー

19. 本番Sites Satelliteユーザー画面(図15-14)で、次のようにします。

- 本番WebCenter Sitesアプリケーション用に構成されているSatellite Serverのユーザー名を入力します。
ユーザー名は、大文字小文字が区別され、8から64個までの英数字を使用できます。デフォルト・ユーザー: SatelliteServer

- Satellite Serverユーザーのパスワードを入力します。
パスワードは、大文字小文字が区別され、8から64個までの英数字を使用できます。

- 確認のため、パスワードを再入力します。

Satellite Serverは、キャッシュ・エンジンであり、これにより、WebCenter Sitesは、ビジターの最後のリクエスト以降に変更されない、事前にレンダリングされたページの静的バージョンを提供できるようになります(それ以外の場合、WebCenter Sitesは、リクエストごとにページを動的に生成します)。Satellite Serverのキャッシュにより、WebCenter Sitesシステムのパフォーマンスが向上します。

図15-14 本番Sites Satelliteユーザー

20. 本番Sites CAS情報画面(図15-15)で、次のようにします。

注意:

本番システム上のWebCenter SitesがOracle Access Managerと統合されている場合は、デフォルト値を受け入れ、「次へ」をクリックし、手順21に進みます。

- httpまたはhttps (HTTP over SSL)プロトコルを選択します。

- 本番Sites CASアプリケーション・サーバーのホスト名またはIPアドレスを入力します。

- 本番Sites CASアプリケーション・サーバーのポート番号を入力します。

- 本番Sites CASアプリケーションのコンテキスト・ルートを入力します。

図15-15 本番Sites CAS情報

21. ユーザー・アイデンティティ・プロバイダの構成画面で、次のオプションのうちの1つを選択します(図15-16)。

- WebCenter Sitesデータベース(wem-db)を使用した構成

- LDAPを使用した構成このオプションを選択した場合、「次へ」をクリックすると「LDAPサーバー情報」画面が表示されます。

図15-16 ユーザー・アイデンティティ・プロバイダの構成

22. 前の手順で、LDAPを使用した構成を選択した場合は、図15-17に示すLDAPサーバー情報画面で次の値を指定します(例は、第13.1.3項「LDAP構成の場合の前提条件」を参照してください)。

- LDAPサーバー・ホスト名またはIPアドレス。

- LDAPサーバー・ポート。

- LDAPサーバー・ベースDN。

- LDAP管理者ユーザー。

- LDAP管理者のパスワード。

図15-17 LDAPサーバー情報

23. メール・サーバー情報画面(図15-18)で、次のようにします。

- 電子メール接続セキュリティに対してSSL/TLSまたは「なし」を選択します。

- メール・サーバー・ホスト名またはIPアドレスを入力します。

- メール・サーバー・ポートを入力します。

- 「送信者」フィールドに使用する電子メール・アドレスを入力します。

注意:

メール・サーバー情報は、コミュニティ-ガジェット・アプリケーションによってビジターと通信するために使用されます。

図15-18 メール・サーバー情報

24. 電子メール送信者ログイン画面で、次のオプションのうちの1つを選択します(図15-19)。

- はい: メールを送信するにはログインが必要です。このオプションを選択した場合、「次へ」をクリックすると電子メール送信者情報画面が表示されます。

- いいえ: メールを送信するためにログインする必要はありません。

図15-19 電子メール送信者ログイン

25. 前の手順で「はい」を選択した場合、電子メール送信者情報画面(図15-20)に、次の値を指定します。

- 送信元ユーザーの電子メール・アドレス。

- 送信元ユーザーのパスワード。

- 確認のため、送信者ユーザーのパスワードを再入力します。

図15-20 電子メール送信者情報

26. 設定のサマリー画面(図15-21)に、このインストールに対して行った構成の選択のサマリーが表示されます。

- 設定のサマリーをレビューし、すべてのオプションが適切に構成されていることを確認します。

- 変更が必要なオプションを見つけた場合は、「前へ」をクリックし、そのオプションを含むインストーラ画面に戻ります。

図15-21 設定のサマリー

27. 「インストールの進行状況」画面(図15-22)で、「インストール」をクリックし、デプロイメント・ファイルの生成プロセスを開始します。そのプロセスは、「クライアント・ログ」タブから監視できます。

図15-22 インストールの進行状況

28. インストーラのタスクが正常に完了すると、確認メモが表示されます(図15-23)。「OK」をクリックし、コミュニティ-ガジェットWebアプリケーションのwar/earファイルを作成します。インストーラ・プロセスを終了しないでください。それは、正常に終了させます。

図15-23 インストールの進行状況

29. 第15.3項「コミュニティ-ガジェット・インストール・ディレクトリ構造の検証」に続きます。

15.2 コミュニティ-ガジェット・デプロイメント・ファイルのサイレントな生成

コミュニティ-ガジェット・デプロイメント・ファイルをサイレントに生成するには、次の手順に従います。

1. コミュニティ-ガジェット・アプリケーションをインストールする予定のサーバー上にコミュニティ-ガジェット・インストーラを抽出します。

2. インストール・フォルダには、サンプルomii_sample.iniファイルが含まれており、これをサイレント・インストールに使用できます。

1. デフォルト値を検証し、必要に応じて追加の値を入力することで、ファイルを編集します。ガイドについては、ファイルないのコメントを参照してください。

2. ファイルを保存し、それを<cg_install_dir>の外のフォルダにコピーします。

3. install.iniファイル(抽出されたコミュニティ-ガジェット・インストーラ内)を次のように編集します。

- loadfile=<path_to_the_copied_omii.ini_file>を(手順2bのomii.iniファイルを指すように)設定します

- nodisplay=trueを設定します。

注意:

このファイルのパスには、Windowsプラットフォーム上であってもフォワード・スラッシュ("/")をパス・セパレータとして含める必要があります。例: d:/CG/omii.ini

4. インストール・ディレクトリを作成します。その中に、コミュニティ-ガジェット・インストーラによって、必要なフォルダおよびファイルが作成されます。
例:

/u01/software/Apps/CG

5. JAVA_HOMEを、JDK 1.6またはそれ以降のバージョンのパスに設定します。
例:

export JAVA_HOME=/opt/jdk1.6.0_43

6. コミュニティ-ガジェット・サイレント・インストーラを次のように実行します。

1. cgInstall.shまたはcgInstall.batスクリプトを-silentパラメータを指定して実行します。

2. CG web-application files have been generated successfullyメッセージが表示され、プロセスが完了するまで待ちます。

7. 第15.3項「コミュニティ-ガジェット・インストール・ディレクトリ構造の検証」に続きます。

15.3 コミュニティ-ガジェット・インストール・ディレクトリ構造の検証

インストーラのプロセスが完了すると、生成されたデプロイメント・ファイルが含まれるコミュニティ-ガジェット・インストール・ディレクトリが作成されます。

1. コミュニティ-ガジェット・インストール・ディレクトリおよび生成されたデプロイメント・ファイルの場所を確認します。この手順に示すディレクトリ構造を参照してください。メイン・サブディレクトリは次のとおりです。

- cg_licenses: このサブディレクトリには、必須ライセンス・ファイルが含まれています。

- deploy: このサブディレクトリには、コミュニティ-ガジェット・アプリケーションの管理サイドと本番サイドに対して生成されるwarおよびearファイルが含まれています。このディレクトリには、アプリケーション・サーバー・クラスパスに追加する必要があるスタンドアロン構成ファイルも含まれています。war/earファイルは手動でデプロイする必要があります。

- logs: このサブディレクトリには、使用中にコミュニティ-ガジェット・アプリケーションによって作成されるログが格納されます。

- ominstallinfo: このサブディレクトリには、コミュニティ-ガジェット・インストールに関する情報が含まれています。インストール・ログおよびインストール設定ファイルは、このサブディレクトリに格納されます。

<cg_install_dir>
|--cg_licenses
| |--cas_thirdparty_licenses
| |--shindig_thirdparty_licenses
|--deploy
| |--management
| | |--CommunityGadgets.ear
| | |--cg.war
| | |--Shindig.ear
| | |--shindig.war
| | |--management_node1
| | | |--cas-cache.xml
| | | |--cos-cache.xml
| | | |--log4j-cos.properties
| | | |--log4j-shindig.properties
| | | |--setup_auth.properties
| | | |--setup_cos.properties
| | | |--setup_cs.properties
| | | |--setup_proxy.properties
| | | |--setup_shindig.properties
| | | |--wsdk_facilities.properties
| | | |--ESAPI.properties
| | | |--validation.properties
| | | |--wem_sso_config.xml
| | | |--oam_wem_sso_config_sample.xml
| | | |--gas_features.txt
| |--production
| | |--cas.ear
| | |--cas.war
| | |--CommunityGadgets.ear
| | |--cg.war
| | |--Shindig.ear
| | |--shindig.war
| |--production_node1
| | | |--cas.properties
| | | |--customBeans.xml
| | | |--host.properties
| | | |--jbossTicketCacheReplicationConfig.xml
| | | |--cas-cache.xml
| | | |--cos-cache.xml
| | | |--log4j-cos.properties
| | | |--log4j.properties
| | | |--log4j-shindig.properties
| | | |--setup_auth.properties
| | | |--setup_cos.properties
| | | |--setup_cs.properties
| | | |--setup_proxy.properties
| | | |--setup_shindig.properties
| | | |--wsdk_facilities.properties
| | | |--ESAPI.properties
| | | |--validation.properties
| | | |--wem_sso_config.xml
| | | |--oam_wem_sso_config_sample.xml
| | | |--gas_features.txt
|--logs
|--ominstallinfo
| |--install_log.log
| |--management_cgwar.log
| |--management_shindigwar.log
| |--omii.ini
| |--omproduct.ini
| |--production_caswar.log
| |--production_cgwar.log
| |--production_shindigwar.log

2. 第16章「コミュニティ-ガジェットのデプロイメント前の手順の完了」に続きます。

16 コミュニティ-ガジェットのデプロイメント前の手順の完了

この章では、コミュニティ-ガジェットをデプロイする前に完了する必要がある手順について説明します。コミュニティ-ガジェット・デプロイメント・ファイルは正常に生成済であると想定します。

この章の内容は、次のとおりです。

- 第16.1項「inCacheの無効化の構成」

- 第16.2項「インストーラによって生成された構成ファイルのコピー」

- 第16.3項「プロキシ接続設定」

- 第16.4項「コミュニティ-ガジェットのURLのWebCenter SitesのcustomBeans.xmlファイルへの追加」

- 第16.5項「Shindigの機能の有効化」

- 第16.6項「管理または本番、あるいはその両方のWebCenter SitesがOAMと統合されている場合」

16.1 inCacheの無効化の構成

1. Sites Explorerを実行し、ContentServerユーザーを使用して本番WebCenter Sitesサーバーに接続します。(Sites Explorerへのログイン手順は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。)

2. Sites ExplorerでSystemSatellite表を開きます。

1. 表の最初の行をコピーします。

2. その行を、コミュニティ-ガジェット・アプリケーションの管理ノードごとに1つずつ、コミュニティ-ガジェット・アプリケーションの本番ノードごとに1つずつ、表に貼り付けます。

3. 新しい行で、次のフィールドの値を、自身のインストールに合わせて変更します。

- description: <node name>

- protocol: <http or https>

- host: <host name or IP address of the management or production Community-Gadgets application server>

- port: <port number of the management or production Community-Gadgets application server>

- flushservletpath: /cg/FlushServer

注意:

標準コミュニティ-ガジェット・アプリケーションのコンテキスト・ルートが使用されていない場合、次のものを使用します。

/<new context root>/FlushServer

- username: <of the production Satellite Server user> (デフォルトはSatelliteServerです)

- password: <password of the above user>

3. 第16.2項「インストーラによって生成された構成ファイルのコピー」に続きます。

16.2 インストーラによって生成された構成ファイルのコピー

デプロイ済コミュニティ-ガジェット・アプリケーションを適切に起動するためにアプリケーション・サーバーによって読み取られるプロパティ・ファイルおよび他の構成ファイルがコミュニティ-ガジェット・インストーラによって作成されました。

1. 管理を容易にし、スケーラビリティを向上させるために、コミュニティ-ガジェット・アプリケーションの各インスタンスがそれ自体のファイルのセットを持つように、ファイルをコピーすることをお薦めします。

1. <cg_install_dir>内に、<cg-standalone-configs>というディレクトリを作成します。

2. この新しく作成したディレクトリ内に、各管理ノードおよび各本番ノードに1つずつサブディレクトリを作成します。このサブディレクトリには、それらのノードの構成ファイルが格納されます。これらのディレクトリは、アーキテクチャに応じて、共有ファイル・システム上あっても、個別のサーバー上にあっても構いません。

3. 前述の手順で作成したサブディレクトリごとに、そのパスを、アプリケーション・サーバーのクラスパスに追加します。
たとえば、Linuxの場合、次のようにします。

mkdir <cg_install_dir>/<cg-standalone-configs>
cd <cg_install_dir>/<cg-standalone-configs>
mkdir <cgA_M1> <cgA_M2> <cgB_P1> <cgB_P2> ...

2. インストーラによって生成された構成ファイルおよびプロパティ・ファイルを、次のようにノードのサブディレクトリに追加します。
各管理コミュニティ-ガジェット・アプリケーション・ノードの場合:

1. 構成ファイルを、<cg_install_dir>/deploy/management/management_node1から、管理コミュニティ-ガジェット・アプリケーションに対して手順1.bで作成したサブディレクトリにコピーします。
たとえば、Linuxの場合、次のようにします。

cd <cg_install_dir>/deploy/management/management_node1
cp -p ./* <cg_install_dir>/<cg-standalone-configs>/<cgA_M1>

2. 必要に応じて、特定のノードの各管理コミュニティ-ガジェット・アプリケーションのlog4j-cos.propertiesおよびlog4j-shindig.propertiesを変更することで、ログ・ファイル名を変更します。

各本番コミュニティ-ガジェット・アプリケーション・ノードの場合:

1. 構成ファイルを、<cg_install_dir>/deploy/production/production_node1から、本番コミュニティ-ガジェット・アプリケーションに対して手順1.bで作成したサブディレクトリにコピーします。
たとえば、Linuxの場合、次のようにします。

cd <cg_install_dir>/deploy/production/production_node1
cp -p ./* <cg_install_dir>/<cg-standalone-configs>/<cgB_P1>

2. UDPタグに移動し、次のように実行することでjbossTicketCacheReplicationConfig.xmlを編集します。

- クラスタ化されていないアプリケーションの場合は、mcast_portの値を、サブネット上のその他のCASアプリケーションに対して一意のポート番号に設定します。

- クラスタ化されたアプリケーションの場合は、ip_ttlの値を8に設定し、bind_addrをVisitors CASクラスタ・メンバーのホストIPアドレスに変更します。すべてのクラスタ・メンバーが、同じmcastアドレスおよびポート上でリスニングしていることを確認します。

3. 必要に応じて、特定のノードの各本番コミュニティ-ガジェット・アプリケーションのlog4j-cos.properties、log4j-shindig.propertiesおよびlog4j.propertiesを変更することで、ログ・ファイル名を変更します。

3. ご使用のシステムでの必要に応じて、この章の残りの手順を完了します。終了したら、第17章「コミュニティ-ガジェットのデプロイ」に進みます。

16.3 プロキシ接続設定

コミュニティ-ガジェット・アプリケーションは、図16-1に示すように、最大5つのプロキシ接続設定をサポートします(デフォルトでは無効化されています)。

図16-1 コミュニティ-ガジェットによってサポートされるプロキシ接続設定

- プロキシ接続1は、インターネット接続プロキシであり、本番コミュニティ-ガジェット・アプリケーションからインターネットへの通信をサポートします。このプロキシ接続は、Facebook、Twitter、Google、Janrainなどサードパーティのサービスを介した外部認証に使用されます。

- プロキシ接続2は、インターネット接続プロキシであり、管理コミュニティ-ガジェット・アプリケーションからインターネットへの通信をサポートします。このプロキシ接続は、ガジェット登録中に外部ガジェット記述子にアクセスするために使用されます。

- プロキシ接続3は、本番コミュニティ-ガジェット・アプリケーションから本番WebCenter Sitesアプリケーションへの通信をサポートします。

- プロキシ接続4は、管理コミュニティ-ガジェット・アプリケーションから管理WebCenter Sitesアプリケーションへの通信をサポートします。

- プロキシ接続5は、管理コミュニティ-ガジェット・アプリケーションから本番WebCenter Sitesアプリケーションへの通信をサポートします。

プロキシ接続を構成する場合は、次のように実行します。

1. プロキシ接続は、deploy/production/production_node1およびdeploy/management/management_node1フォルダ内、または第16.2項「インストーラによって生成された構成ファイルのコピー」で作成したフォルダ内にあるsetup_proxy.propertiesファイルで構成されます。setup_proxy.propertiesファイルには、各プロキシ接続のパラメータが含まれた5つのセクションがあります。

- デフォルトでは、すべてのプロキシ・セクションにfalseに設定された<proxy>.proxy.attrs.enabledパラメータがあり、これがプロキシを使用しない場合の設定になります。

- プロキシを使用する場合は、関連するセクションに移動し、次のパラメータを設定します。

- <proxy>.proxy.attrs.enabledパラメータをtrueに設定します。

- <proxy>.proxy.attrs.hostパラメータを、プロキシのホスト名またはIPアドレスに設定します。

- <proxy>.proxy.attrs.portパラメータをプロキシcos-production_www.proxy.attrs.auth.userのポートに設定します。

- プロキシで認証が必要な場合は、<proxy>.proxy.attrs.auth.requiredパラメータをtrueに設定し、<proxy>.proxy.attrs.auth.userおよび<proxy>.proxy.attrs.auth.passwordパラメータにユーザー名およびパスワードを指定します。

注意:

インターネット・プロキシのセクションで、ご使用の管理および本番WebCenter Sitesインスタンスのホスト名を、プロキシが本番および管理に使用できないホストのリストに追加すると役立つ場合があります。

- 参照のために、サンプル構成セクションを次に示します。
本番インターネット接続プロキシのサンプル構成 (setup_proxy.propertiesファイルの最初のセクション):

# Use proxy server
# Possible values: "true" or "false"
cos-production_www.proxy.attrs.enabled=true
# Proxy type
# Possible values: "http" or "socks"
cos-production_www.proxy.attrs.type=http
# Proxy server host
cos-production_www.proxy.attrs.host=www-proxy.example.com
# Proxy server port.
cos-production_www.proxy.attrs.port=80
# Is authentication required for proxy server configured above.
cos-production_www.proxy.attrs.auth.required=true
# User proxy account to log in to the proxy server
cos-production_www.proxy.attrs.auth.user=user
# Password of the above user.
cos-production_www.proxy.attrs.auth.password=proxypassword
# List of hosts for which proxy should not be used
cos-production_www.proxy.attrs.non_proxy_hosts=

2. ご使用のシステムでの必要に応じて、この章の残りの手順を完了します。終了したら、第17章「コミュニティ-ガジェットのデプロイ」に進みます。

16.4 コミュニティ-ガジェットのURLのWebCenter SitesのcustomBeans.xmlファイルへの追加

1. インストール内で、<sites_install_dir>/bin/customBeans.xmlに移動します。

2. customBeans.xmlファイルを開きます。

3. RequestParamValidator Beanセクションで、次のようにコミュニティ-ガジェットのURLをvalidUrlsリスト内に追加します。

- WebCenter Sites管理システムでは、各管理コミュニティ・ガジェット・インスタンスに対して次のように入力します。

<value>{protocol}://{cg_mgmt_node_host}:{cg_mgmt_node_port}/{cg_context}/*</value>

- WebCenter Sites本番システムでは、各本番コミュニティ・ガジェット・インスタンスに対して次のように入力します。

<value>{protocol}://{cg_prod_node_host}:{cg_prod_node_port}/{cg_context}/*</value>

- クラスタ化されたインストールの場合、コミュニティ-ガジェット・ロード・バランサに対して追加の値の指定が必要です。

例16-1に、サンプルのcustomBeans.xmlファイルを示します。

例16-1 サンプルのcustomBeans.xmlファイル

<bean id="RequestParamValidator"class="com.fatwire.cas.web.RequestParamValidator">
<property name="validUrls">
<list>
<!-- Sites URL -->
<value>http://192.0.2.1:8080/cs/*</value>
<!-- Community-Gadgets  node 1 -->
<value>http://192.0.2.2:8080/cg/*</value>
<!-- Community-Gadgets  node 2 -->
<value>http://192.0.2.3:8080/cg/*</value>
<!-- Community-Gadgets  Load Balancer 1 -->
<value>http://192.0.2.4:80/cg/*</value>
</list>
</property>
</bean>

16.5 Shindigの機能の有効化

iGoogleのために開発されたかiGoogle機能を使用するガジェットは、場合によっては、そのガジェットが適切にレンダリングするために特別なShindig機能を有効化する必要があります。これらのShindig機能を有効化した場合、コミュニティ-ガジェット・アプリケーションによって、インターネットからガジェットのレンダリングに必要なサードパーティ・ライブラリがダウンロードされます。

注意:

サードパーティ・ライブラリのダウンロードを有効化するには、インターネットにアクセスできる必要があります。インターネット・アクセスにプロキシを使用する場合は、setup_proxy.propertiesファイルで管理と本番の両方のインターネット・アクセスに対して適切な接続設定を構成します。詳細は、第16.3項「プロキシ接続設定」を参照してください。

1. コミュニティ-ガジェット・アプリケーションに対して追加のShindig機能を有効化する場合は、<cg_install_dir>/deploy/management/management_node1および<cg_install_dir>/deploy/production/production_node1フォルダ(または第16.2項「インストーラによって生成された構成ファイルのコピー」で作成したフォルダ)に配置されているgas_features.txtファイルの次の行を非コメント化します。

# features/analytics/feature.xml
# features/com.google.gadgets.analytics/feature.xml
# features-extras/org.jquery.core-1.4.2/feature.xml

2. ご使用のシステムでの必要に応じて、この章の残りの手順を完了します。終了したら、第17章「コミュニティ-ガジェットのデプロイ」に進みます。

16.6 管理または本番、あるいはその両方のWebCenter SitesがOAMと統合されている場合

1. 管理または本番、あるいはその両方のWebCenter SitesがOAMと統合されている場合、コミュニティ-ガジェット・インスタンスが、同じOAMと連動するように構成します。詳細は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』を参照してください。

2. 第17章「コミュニティ-ガジェットのデプロイ」に続きます。

17 コミュニティ-ガジェットのデプロイ

この章では、サポートされているアプリケーション・サーバーにコミュニティ-ガジェットをデプロイする手順について説明します。

この章の内容は、次のとおりです。

- 17.1項「概要」

- 第17.2項「クラスタ化されていないコミュニティ-ガジェット・アプリケーションのデプロイ」

- 第17.3項「クラスタ化されたコミュニティ-ガジェット・アプリケーションのデプロイ」

17.1 概要

コミュニティ-ガジェットをデプロイする場合、次のことを実行します。

- 管理システムで、管理コミュニティ-ガジェットWebアプリケーションおよび管理Shindig Webアプリケーション(ガジェット・レンダリング用)をデプロイします。

- 本番システムで、本番コミュニティ-ガジェットWebアプリケーション、本番Shindig Webアプリケーション(ガジェット・レンダリング用)、およびVisitors CAS Webアプリケーション(認証用)をデプロイします。

手順は、この章で説明します。

注意:

この章で先に進む前に、第IV部「Oracle WebCenter Sites: コミュニティ-ガジェットのインストール」の前の章の必須手順を完了していることを確認します。

17.2 クラスタ化されていないコミュニティ-ガジェット・アプリケーションのデプロイ

この項では、サポートされているアプリケーション・サーバーにクラスタ化されていないコミュニティ-ガジェット・アプリケーションをデプロイする手順について説明します。

この項では、次のデプロイメント構成について説明します。

- 第17.2.1項「Apache Tomcatへのデプロイ」

- 第17.2.2項「Oracle WebLogic Application Serverへのデプロイ」

- 第17.2.3項「IBM WebSphere Application Serverへのデプロイ」

17.2.1 Apache Tomcatへのデプロイ

この項では、Tomcatにクラスタ化されていないコミュニティ-ガジェット・アプリケーションをデプロイします。

注意:

Apache Tomcatへのアプリケーションのデプロイ方法の詳しい手順は、ベンダーのドキュメントを参照してください。

1. コミュニティ-ガジェット・アプリケーションをデプロイする前に、各アプリケーション・サーバーのクラスパスが、それぞれのコミュニティ-ガジェット構成ディレクトリ(第16.2項「インストーラによって生成された構成ファイルのコピー」で作成したもの)を指していることを確認します。
参照のため、このガイドで使用する構成を、表17-1に示します。

表17-1 Tomcatサーバーの場合のクラスパス構成(クラスタ化されていない)

Tomcatサーバー

サーバー・クラスパス

<cgA_M1>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgA_M1>:${CLASSPATH}"

<cgB_P1>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgB_P1>:${CLASSPATH}"

2. コミュニティ-ガジェット・インストーラによって、<cg_install_dir>/deploy/managementディレクトリおよび<cg_install_dir>/deploy/productionディレクトリにwarおよびearファイルが作成されます。Tomcat管理コンソールを使用するか、展開したwarファイルをwebappsディレクトリにコピーすることで、コミュニティ-ガジェット・アプリケーションをデプロイします。表17-2に、warファイルの場所を示します。

注意:

catalina.sh (またはcatalina.bat)ファイルで、行"CLASSPATH="がコメント・アウトされていることを確認します。

- UNIXの場合: #CLASSPATH=

- Windowsの場合: REM CLASSPATH=

表17-2 Tomcatの場合のWARファイルの場所(クラスタ化されていない)

Application Serverインスタンス

WARファイルの場所

サンプル・デプロイメントの場所

<cgA_M1>

<cg_install_dir>/deploy/management/cg.war

<cg_install_dir>/deploy/management/shindig.war

<cgA_M1>/webapps/cg

<cgA_M1>/webapps/shindig

<cgB_P1>

<cg_install_dir>/deploy/production/cg.war

<cg_install_dir>/deploy/production/shindig.war

<cg_install_dir>/deploy/production/cas.war

<cgB_P1>/webapps/cg

<cgB_P1>/webapps/shindig

<cgB_P1>/webapps/cas

注意:

インストール時にCGコンテキスト・ルートが変更されている場合、tomcat webapps内のCGデプロイ・フォルダ名はCGコンテキスト・ルートと同一である必要があります。

3. 管理対象サーバーを起動する前に、第13項「コミュニティ-ガジェットをインストールするための前提条件」の説明のようにWebCenter Sitesが実行され、構成されていることを確認します。

4. 本番および管理デプロイメント・サーバーを起動します。
たとえば、Linuxの場合、次のようにします。

<ServerB>の場合:

cd <cgB_P1>/bin
./catalina.sh run

<ServerA>の場合:

cd <cgA_M1>/bin
./catalina.sh run

5. 第18章「コミュニティ-ガジェットの検証と実装」に続きます。

17.2.2 Oracle WebLogic Application Serverへのデプロイ

この項では、Oracle WebLogic Application Serverにクラスタ化されていないコミュニティ-ガジェット・アプリケーションをデプロイします。

注意:

次の点を考慮してください。

- Oracle WebLogic Application ServerへのWebアプリケーションのデプロイの詳しい手順については、Oracle WebLogic Application Serverのドキュメントを参照してください。

- コミュニティ-ガジェット・アプリケーションをWebLogic Application Server上にデプロイする場合は、JVMパラメータ(-DUseSunHttpHandler=true)をWebLogic Application ServerのJAVA_OPTIONSに追加します。

1. コミュニティ-ガジェット・アプリケーションをデプロイする前に、各アプリケーション・サーバーのクラスパスが、それぞれのコミュニティ-ガジェット構成ディレクトリ(第16.2項「インストーラによって生成された構成ファイルのコピー」で作成したもの)を指していることを確認します。
参照のため、このガイドで使用する構成を、表17-3に示します。

表17-3 管理対象サーバーの場合のクラスパス構成(WebLogic、クラスタ化されていない)

管理対象サーバー

サーバー・クラスパス

<cgA_M1>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgA_M1>:${CLASSPATH}"

<cgB_P1>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgB_P1>:${CLASSPATH}"

2. コミュニティ-ガジェット・インストーラによって、<cg_install_dir>/deploy/managementおよび<cg_install_dir>/deploy/productionディレクトリにwarおよびearファイルが作成されます。warファイルの内容を抽出し、コマンドラインまたは管理コンソールを使用してそれらをデプロイします。表17-4に、warファイルの場所を示します。

表17-4 WebLogicの場合のWARファイルの場所(クラスタ化されていない)

管理対象サーバー

WARファイルの場所

サンプル・デプロイメントの場所

<cgA_M1>

<cg_install_dir>/deploy/management/cg.war

<cg_install_dir>/deploy/management/shindig.war

<WL_HOME>/user_projects/domains/<cgMgmt>/applications/cg

<WL_HOME>/user_projects/domains/<cgMgmt>/applications/shindig

<cgB_P1>

<cg_install_dir>/deploy/production/cg.war

<cg_install_dir>/deploy/management/shindig.war

<cg_install_dir>/deploy/production/cas.war

<WL_HOME>/user_projects/domains/<cgProd>/applications/cg

<WL_HOME>/user_projects/domains/<cgProd>/applications/shindig

<WL_HOME>/user_projects/domains/<cgProd>/applications/cas

3. 管理対象サーバーを起動する前に、第13項「コミュニティ-ガジェットをインストールするための前提条件」の説明のようにWebCenter Sitesが実行され、構成されていることを確認します。

4. コミュニティ-ガジェット・アプリケーションからそのアプリケーション・サーバーのJREに、jaxb-api-2.2.2.jarおよびjaxb-impl-2.2.3-1.jarファイルをコピーします。これらのファイルを取得するには、cos.warを解凍します。これらのJARは、WEB-INF/libディレクトリ内にあります。
これらのファイルは、<WebLogic_JDK>/jre/lib/endorsedフォルダに配置する必要があります(endorsedフォルダが存在していない場合は、作成してください。)。

5. 本番および管理デプロイメント・サーバーを起動します。
たとえば、Linuxの場合、次のようにします。

cd <WL_HOME>/user_projects/domains/<cgProd>/bin
./startManagedServer <cgB_P1> http://<ServerB>:7001

cd <WL_HOME>/user_projects/domains/<cgMgmt>/bin
./startManagedServer <cgA_M1> http://<ServerA>:7001

6. 第18章「コミュニティ-ガジェットの検証と実装」に続きます。

17.2.3 IBM WebSphere Application Serverへのデプロイ

この項では、IBM WebSphere Application Serverにクラスタ化されていないコミュニティ-ガジェット・アプリケーションをデプロイします。

注意:

IBM WebSphere Application ServerにWebアプリケーションをデプロイする詳しい手順については、ベンダーのドキュメントを参照してください。

1. コミュニティ-ガジェット・アプリケーションをデプロイする前に、各アプリケーション・サーバーのクラスパスが、それぞれのコミュニティ-ガジェット構成ディレクトリ(第16.2項「インストーラによって生成された構成ファイルのコピー」で作成したもの)を指していることを確認します。これを行うには、次のようにします。

1. デプロイメント・マネージャにログインします(たとえば、http://<ServerA>:9060/ibm/consoleにアクセスします)。

2. サーバーごとに、「Java and Process Management」→「Process Definition」→「Java Virtual Machine」を選択し、CLASSPATHフィールドを編集します。

参照のため、このガイドで使用する構成を、表17-5に示します。

表17-5 WebSphereの場合のクラスパス構成(クラスタ化されていない)

管理対象サーバー

サーバー・クラスパス

<cgA_M1>

/<cg_install_dir>/<cg-standalone-configs>/<cgA_M1>

<cgB_P1>

/<cg_install_dir>/<cg-standalone-configs>/<cgB_P1>

2. コミュニティ-ガジェット・インストーラによって、<cg_install_dir>/deploy/managementディレクトリおよび<cg_install_dir>/deploy/productionディレクトリにwarおよびearファイルが作成されます。表17-6に、earファイルの場所を示します。

表17-6 WebSphereの場合のEARファイルの場所(クラスタ化されていない)

管理対象サーバー

EARファイルの場所

<cgA_M1>

<cg_install_dir>/deploy/management/CommunityGadgets.ear

<cg_install_dir>/deploy/management/Shindig.ear

<cgB_P1>

<cg_install_dir>/deploy/production/CommunityGadgets.ear

<cg_install_dir>/deploy/production/Shindig.ear

<cg_install_dir>/deploy/production/cas.ear

3. コミュニティ-ガジェット・アプリケーション、Shindigアプリケーション、およびVisitors CASアプリケーションに対してWebSphere管理コンソールで次の手順を完了します。

1. 「Applications」→「Application Types」→「WebSphere enterprise applications」→「application_name」を選択します。

2. 「Web Module Properties」の下の「Session management」を選択します。

3. 「General Properties」の下の「Enable Cookies」を選択し、Cookieパスの値を/から/<application-context-root>に変更します(デフォルト値は、コミュニティ-ガジェット・アプリケーションの場合は/cg、Shindigの場合は/shindig、Visitors CASアプリケーションの場合は/casです)。

4. 「Apply and Save」をクリックします。

5. 「General Properties」の下の「Override session management」を選択します。

6. 「Apply and Save」をクリックします。

4. コミュニティ-ガジェット・アプリケーションからそのアプリケーション・サーバーのJREに、axb-api-2.2.2.jar、jaxb-impl-2.2.3-1.jarおよびasm-3.1.jarファイルをコピーします。これらのファイルは、<WebSphere_JDK>/jre/lib/endorsedフォルダに配置する必要があります(endorsedフォルダが存在していない場合は、作成してください。)。

5. 管理対象サーバーを起動する前に、第13項「コミュニティ-ガジェットをインストールするための前提条件」の説明のようにWebCenter Sitesが実行され、構成されていることを確認します。

6. デプロイメント・マネージャ・プロファイルおよびノードを起動します。
たとえば、Linuxの場合、次のようにします。

<ServerA>の場合:

<WS_HOME>/bin
./startManager.sh -profileName <Dmgr01>
./startNode.sh -profileName <AppSrv01>

<ServerB>の場合:

./startNode.sh -profileName <AppSrv02>

7. 本番および管理サーバーを起動します。
たとえば、Linuxの場合、次のようにします。

<ServerB>の場合:

./startServer.sh cgB_P1 -profileName <AppSrv02>

<ServerA>の場合:

./startServer.sh cgA_M1 -profileName <AppSrv01>

8. 第18章「コミュニティ-ガジェットの検証と実装」に続きます。

17.3 クラスタ化されたコミュニティ-ガジェット・アプリケーションのデプロイ

この項では、サポートされているアプリケーション・サーバーにクラスタ化されたコミュニティ-ガジェット・アプリケーションをデプロイする手順について説明します。

この項では、次のデプロイメント構成について説明します。

- 第17.3.1項「Apache Tomcatへのデプロイ(クラスタ化されている)」

- 第17.3.2項「Oracle WebLogic Application Serverへのデプロイ(クラスタ化されている)」

- 第17.3.3項「IBM WebSphere Application Serverへのデプロイ(クラスタ化されている)」

17.3.1 Apache Tomcatへのデプロイ(クラスタ化されている)

この項では、Tomcatにクラスタ化されたコミュニティ-ガジェット・アプリケーションをデプロイします。

注意:

Apache Tomcatへのアプリケーションのデプロイ方法の詳しい手順は、ベンダーのドキュメントを参照してください。

1. コミュニティ-ガジェット・アプリケーションをデプロイする前に、各アプリケーション・サーバーのクラスパスが、それぞれのコミュニティ-ガジェット構成ディレクトリ(第16.2項「インストーラによって生成された構成ファイルのコピー」で作成したもの)を指していることを確認します。
参照のため、このガイドで使用する構成を、表17-7に示します。

表17-7 Tomcatサーバーの場合のクラスパス構成(クラスタ化されている)

管理対象サーバー

サーバー・クラスパス

<cgA_M1>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgA_M1>:${CLASSPATH}"

<cgB_P1>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgB_P1>:${CLASSPATH}"

<cgA_M2>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgA_M2>:${CLASSPATH}"

<cgB_P2>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgB_P2>:${CLASSPATH}"

2. コミュニティ-ガジェット・インストーラによって、<cg_install_dir>/deploy/managementおよび<cg_install_dir>/deploy/productionディレクトリにwarおよびearファイルが作成されます。Tomcat管理コンソールを使用するか、展開したwarファイルをwebappsディレクトリにコピーすることで、コミュニティ-ガジェット・アプリケーションをデプロイします。表17-8に、warファイルの場所を示します。

表17-8 Tomcatの場合のWARファイルの場所(クラスタ化されている)

Application Serverインスタンス

WARファイルの場所

サンプル・デプロイメントの場所

<cgA_M1>

<cg_install_dir>/deploy/management/cg.war

<cg_install_dir>/deploy/management/shindig.war

<cgA_M1>/webapps/cg

<cgA_M1>/webapps/shindig

<cgB_P1>

<cg_install_dir>/deploy/production/cg.war

<cg_install_dir>/deploy/production/shindig.war

<cg_install_dir>/deploy/production/cas.war

<cgB_P1>/webapps/cg

<cgB_P1>/webapps/shindig

<cgB_P1>/webapps/cas

<cgA_M2>

<cg_install_dir>/deploy/management/cg.war

<cg_install_dir>/deploy/management/shindig.war

<cgA_M2>/webapps/cg

<cgA_M2>/webapps/shindig

<cgB_P2>

<cg_install_dir>/deploy/production/cg.war

<cg_install_dir>/deploy/production/shindig.war

<cg_install_dir>/deploy/production/cas.war

<cgB_P2>/webapps/cg

<cgB_P2>/webapps/shindig

<cgB_P2>/webapps/cas

3. 管理対象サーバーを起動する前に、第13項「コミュニティ-ガジェットをインストールするための前提条件」の説明のようにWebCenter Sitesが実行され、構成されていることを確認します。

4. 本番および管理デプロイメント・サーバーを起動します。
たとえば、Linuxの場合、次のようにします。

<ServerB>の場合:

cd <cgB_P1>/bin
./catalina.sh run
cd <cgB_P2>/bin
./catalina.sh run

<ServerA>の場合:

cd <cgA_M1>/bin
./catalina.sh run
cd <cgA_M2>/bin
./catalina.sh run

5. 第18章「コミュニティ-ガジェットの検証と実装」に続きます。

17.3.2 Oracle WebLogic Application Serverへのデプロイ(クラスタ化されている)

この項では、Oracle WebLogic Application Serverにクラスタ化されているコミュニティ-ガジェット・アプリケーションをデプロイします。

注意:

次の点を考慮してください。

- Oracle WebLogic Application ServerへのWebアプリケーションのデプロイの詳しい手順については、Oracle WebLogic Application Serverのドキュメントを参照してください。

- コミュニティ-ガジェット・アプリケーションをWebLogic Application Server上にデプロイする前に、JVMパラメータ(-DUseSunHttpHandler=true)をWebLogic Application ServerのJAVA_OPTIONSに追加します。

1. コミュニティ-ガジェット・アプリケーションをデプロイする前に、各アプリケーション・サーバーのクラスパスが、それぞれのコミュニティ-ガジェット構成ディレクトリ(第16.2項「インストーラによって生成された構成ファイルのコピー」で作成したもの)を指していることを確認します。
参照のため、このガイドで使用する構成を、表17-9に示します。

表17-9 管理対象サーバーの場合のクラスパス構成(クラスタ化されたWebLogic)

管理対象サーバー

サーバー・クラスパス

<cgA_M1>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgA_M1>:${CLASSPATH}"

<cgB_P1>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgB_P1>:${CLASSPATH}"

<cgA_M2>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgA_M2>:${CLASSPATH}"

<cgB_P2>

CLASSPATH="/<cg_install_dir>/<cg-standalone-configs>/<cgB_P2>:${CLASSPATH}"

2. コミュニティ-ガジェット・インストーラによって、<cg_install_dir>/deploy/managementおよび<cg_install_dir>/deploy/productionディレクトリにwarおよびearファイルが作成されます。warファイルの内容を抽出し、コマンドラインまたは管理コンソールを使用してそれらをデプロイします。表17-10に、warファイルの場所を示します。

表17-10 WebLogicの場合のWARファイルの場所(クラスタ化されている)

ターゲット・サーバー: すべてのクラスタ・メンバー

WARファイルの場所

サンプル・デプロイメントの場所

<cgA_M1>

<cgA_M2>

<cg_install_dir>/deploy/management/cg.war

<cg_install_dir>/deploy/management/shindig.war

<WL_HOME>/user_projects/domains/<cgMgmt>/applications/cg

<WL_HOME>/user_projects/domains/<cgMgmt>/applications/shindig

<cgB_P1>

<cgB_P2>

<cg_install_dir>/deploy/production/cg.war

<cg_install_dir>/deploy/production/shindig.war

<cg_install_dir>/deploy/production/cas.war

<WL_HOME>/user_projects/domains/<cgProd>/applications/cg

<WL_HOME>/user_projects/domains/<cgProd>/applications/shindig

<WL_HOME>/user_projects/domains/<cgProd>/applications/cas

3. 管理対象サーバーを起動する前に、第13項「コミュニティ-ガジェットをインストールするための前提条件」の説明のようにWebCenter Sitesが実行され、構成されていることを確認します。

4. コミュニティ-ガジェット・アプリケーションからそのアプリケーション・サーバーのJREに、jaxb-api-2.2.2.jarファイルおよびjaxb-impl-2.2.3-1.jarファイルをコピーします。これらのファイルは、<WebLogic_JDK>/jre/lib/endorsedフォルダに配置する必要があります(endorsedフォルダが存在していない場合は、作成してください。)。

5. 本番および管理デプロイメント・サーバーを起動します。
たとえば、Linuxの場合、次のようにします。

<ServerB>の場合:

cd <WL_HOME>/user_projects/domains/<cgProd>/bin
./startManagedServer <cgB_P1> http://<ServerB>:7001
cd <WL_HOME>/user_projects/domains/<cgProd>/bin
./startManagedServer <cgB_P2> http://<ServerB>:7001

<ServerA>の場合:

cd <WL_HOME>/user_projects/domains/<cgMgmt>/bin
./startManagedServer <cgA_M1> http://<ServerA>:7001
cd <WL_HOME>/user_projects/domains/<cgMgmt>/bin
./startManagedServer <cgA_M2> http://<ServerA>:7001

6. 第18章「コミュニティ-ガジェットの検証と実装」に続きます。

17.3.3 IBM WebSphere Application Serverへのデプロイ(クラスタ化されている)

この項では、IBM WebSphere Application Serverにクラスタ化されたコミュニティ-ガジェット・アプリケーションをデプロイします。

注意:

IBM WebSphere Application ServerにWebアプリケーションをデプロイする詳しい手順については、ベンダーのドキュメントを参照してください。

1. コミュニティ-ガジェット・アプリケーションをデプロイする前に、各アプリケーション・サーバーのクラスパスが、それぞれのコミュニティ-ガジェット構成ディレクトリ(第16.2項「インストーラによって生成された構成ファイルのコピー」で作成したもの)を指していることを確認します。これを行うには、次のようにします。

1. デプロイメント・マネージャにログインします(たとえば、http://<ServerA>:9060/ibm/consoleにアクセスします)。

2. サーバーごとに、「Java and Process Management」→「Process Definition」→「Java Virtual Machine」を選択し、CLASSPATHフィールドを編集します。
参照のため、このガイドで使用する構成を、表17-11に示します。

表17-11 WebSphereの場合のクラスパス構成(クラスタ化されている)

管理対象サーバー

サーバー・クラスパス

<cgA_M1>

/<cg_install_dir>/<cg-standalone-configs>/<cgA_M1>

<cgB_P1>

/<cg_install_dir>/<cg-standalone-configs>/<cgB_P1>

<cgA_M2>

/<cg_install_dir>/<cg-standalone-configs>/<cgA_M2>

<cgB_P2>

/<cg_install_dir>/<cg-standalone-configs>/<cgB_P2>

2. コミュニティ-ガジェット・インストーラによって、<cg_install_dir>/deploy/managementおよび<cg_install_dir>/deploy/productionディレクトリにwarおよびearファイルが作成されます。表17-12に、earファイルの場所を示します。

表17-12 WebSphereの場合のEARファイルの場所(クラスタ化されている)

ターゲット・サーバー

EARファイルの場所

<wscg_M> cluster:

<cgA_M1>,<cgA_M2>

<cg_install_dir>/deploy/management/CommunityGadgets.ear

<cg_install_dir>/deploy/management/Shindig.ear

<wscg_P> cluster:

<cgB_P1>,<cgB_P2>

<cg_install_dir>/deploy/production/CommunityGadgets.ear

<cg_install_dir>/deploy/production/Shindig.ear

<cg_install_dir>/deploy/production/cas.ear

3. 各コミュニティ-ガジェット・アプリケーション、Shindigアプリケーション、およびVisitors CASアプリケーションに対してWebSphere管理コンソールで次の手順を完了します。

1. 「Applications」→「Application Types」→「WebSphere enterprise applications」→「application_name」を選択します。

2. 「Web Module Properties」の下の「Session management」を選択します。

3. 「General Properties」の下の「Enable Cookies」を選択し、Cookieパスの値を/から/<application-context-root>に変更します(デフォルト値は、コミュニティ-ガジェット・アプリケーションの場合は/cg、Shindigの場合は/shindig、Visitors CASアプリケーションの場合は/casです)。

4. 「Apply and Save」をクリックします。

5. 「General Properties」の下の「Override session management」を選択します。

6. 「Apply and Save」をクリックします。

4. コミュニティ-ガジェットからそのアプリケーション・サーバーのJREに、axb-api-2.2.2.jar、jaxb-impl-2.2.3-1.jarおよびasm-3.1.jarファイルをコピーします。これらのファイルは、<WebSphere_JDK>/jre/lib/endorsedフォルダに配置する必要があります(endorsedフォルダが存在していない場合は、作成してください。)。

5. 管理対象サーバーを起動する前に、第13項「コミュニティ-ガジェットをインストールするための前提条件」の説明のようにWebCenter Sitesが実行され、構成されていることを確認します。

6. デプロイメント・マネージャ・プロファイルおよびノードを起動します。
たとえば、Linuxの場合、次のようにします。

<ServerA>の場合:

<WS_HOME>/bin
./startManager.sh -profileName <Dmgr01>
./startNode.sh -profileName <AppSrv01>

<ServerB>の場合:

./startNode.sh -profileName <AppSrv02>

7. 本番および管理サーバーを起動します。
たとえば、Linuxの場合、次のようにします。

<ServerB>の場合:

./startServer.sh cgB_P1 -profileName <AppSrv02>
./startServer.sh cgB_P2 -profileName <AppSrv02>

<ServerA>の場合:

./startServer.sh cgA_M1 -profileName <AppSrv01>
./startServer.sh cgA_M2 -profileName <AppSrv01>

8. 第18章「コミュニティ-ガジェットの検証と実装」に続きます。

18 コミュニティ-ガジェットの検証と実装

コミュニティ-ガジェットをデプロイしたら、インストールを検証し、ユーザーがコミュニティWEMアプリケーションおよびガジェットWEMアプリケーションを操作することを認可することで、そのインタフェースを表示します。また、コミュニティ-ガジェットをWebCenter Sitesコントリビュータ・インタフェースと統合し、コントリビュータ・インタフェースからガジェットおよびウィジェットを直接デプロイしたり、デプロイ済ウィジェットをカスタマイズしたりすることもできます。

この章の内容は、次のとおりです。

- 第18.1項「コミュニティ-ガジェットのURLの検証」

- 第18.2項「コミュニティ-ガジェット・アプリケーションの登録」

- 第18.3項「ユーザーがコミュニティおよびガジェット・インタフェースにアクセスすることを認可」

- 第18.4項「WebCenter Sitesコントリビュータ・インタフェースへのコミュニティ-ガジェットの統合」

18.1 コミュニティ-ガジェットのURLの検証

この項では、新しくインストールしたコミュニティ-ガジェット・アプリケーションが適切に動作していることを検証します。

注意:

この項内のURLは、コミュニティ-ガジェットが適切にインストールされていることを検証するためにのみ使用されます。それらのURLは、コミュニティWEMアプリケーションまたはガジェットWEMアプリケーションの管理操作のための起動には使用できません(エラーが表示されます)。

セキュリティのために、検証プロセスの完了後は、それらのURLに外部からアクセスできないようにしてください。ただし、内部アクセスは、トラブルシューティングに役立ちます。

1. 次の順序でアプリケーション・サーバーを起動します。

注意:

この項では、最初にすべてのサーバーを起動し、次にすべてのURLを検証します。わかりやすくするために、各サーバーを一度に1つずつ起動してテストできます。この方法では、問題が存在する場合、残りのサーバーを起動する前にそれを修正できます。

1. WebCenter Sitesロード・バランサを起動します(インストールがクラスタ化されていると想定)。

2. WebCenter Sitesアプリケーション・サーバー(本番および管理)を起動します。

注意:

サーバーが適切に起動しており、指定したユーザーとして両方のサーバー上のコミュニティ-ガジェットにログインできることを確認します。

コミュニティ-ガジェットのインストールを続行する前に、本番システム上のWebCenter Sitesをバックアップすることをお薦めします。

3. コミュニティ-ガジェット・ロード・バランサを起動します(インストールがクラスタ化されていると想定)。

4. 1つのコミュニティ-ガジェット(本番)アプリケーション・サーバー・インスタンスを起動します。

注意:

本番システム上のWebCenter Sitesとコミュニティ-ガジェット本番サーバーおよびアプリケーションに対するすべてのログを監視します。続行する前にログに報告されたエラーを解決します。それを実行しないと、コミュニティ-ガジェットが不明な状態のままになる場合があります。

5. 残りのコミュニティ-ガジェット(本番)アプリケーション・サーバー・インスタンスを起動します。

6. 1つのコミュニティ-ガジェット(管理)アプリケーション・サーバー・インスタンスを起動します。

7. 残りのコミュニティ-ガジェット(管理)アプリケーション・サーバー・インスタンスを起動します。

2. この時点で、すべてのインスタンスが稼働しており、個々のURLを検証してロード・バランサをテストできます。

3. Visitors CASのすべてのデプロイ済インスタンスに対して、次のことを検証します。

1. Visitors CASアプリケーションのログイン・フォームが表示されることを検証します。次のものにはまだログインできません。

http://<production_cg_host>:<production_cg_port>/<production_cg_cas_context root>/login

例:

http://192.0.2.1:8080/cas/login

2. 本番および管理システムの各ノードのコミュニティ-ガジェット・アプリケーションのステータスを検証します。本番から初めて、次に管理に移動することが最も適切です。

http://<cg_node_host>:<cg_node_port>/<cg_context_root>/status

例:

ノード1: http://192.0.2.1:8080/cg/status

ノード2: http://192.0.2.1:8080/cg/status

図18-1に似た画面が、SUCCESSまたはINFOのいずれかを示すすべてのオプションとともに表示されます。いずれかのオプションに別のステータス(ERRORまたはWARNING)が表示されたり、ページが90秒以内にロードされない場合は、続行できません。Luceneのステータスが「Luceneが動作していません」の場合、または処理中のステータスが2分以上表示される場合は続行できません。『Oracle Fusion Middleware WebCenter Sites開発者ガイド』のLuceneパラメータの構成に関する項の説明に従って、WebCenter Sites本番インスタンスでLuceneエンジンを構成してください。

注意:

エラーまたは警告が表示される場合、コミュニティ-ガジェット・ログ・ファイルおよびアプリケーション・サーバーのログで障害元の詳細について確認します。

図18-1 「ノード・ステータス」ページ

4. 各管理ノードで、一般管理者としてコミュニティ・ユーザー・インタフェースにログインします(デフォルト・ユーザーはfwadmin。インストール・プロセス中に別の管理者の資格証明を入力した場合は、その資格証明を使用します)。

http://<cg_node_host>:<cg_node_port>/cg/admin/start.jsp?siteid=<Site to which Community WEM application will be assigned>

例:

http://192.0.2.1:90/cg/admin/start.jsp?siteid=avisports

ログインすると、コミュニティ・ユーザー・インタフェースにWEMフレームワークを介してアクセスしなかったことを示すメッセージが表示されます(図18-2)。

図18-2 WEMフレームワークの外部からアクセスしたコミュニティ・ユーザー・インタフェース

注意:

コミュニティ・ユーザー・インタフェースが表示されなかったり、Access Denied以外のエラー・メッセージが表示される場合は、ログイン・エラーが発生しており、続行できません。

障害が表示される場合、コミュニティ-ガジェット・アプリケーションのログ・ファイルおよびアプリケーション・サーバーのログで障害元の詳細について確認します。

5. 各管理ノードで、一般管理者としてガジェット管理者インタフェース(グローバル・カタログ)にログインします(デフォルト・ユーザーはfwadmin。インストール・プロセス中に別の管理者の資格証明を入力した場合は、その資格証明を使用します)。

http://<cg_node_host>:<cg_node_port>/cg/admin-gadgets/start.jsp?siteid=<Site to which Gadgets WEM application will be assigned>

例:

http://192.0.2.1/cg/admin-gadgets/start.jsp?siteid=avisports

ログインすると、ガジェット管理者インタフェースにWEMフレームワークを介してアクセスしなかったことを示すメッセージが表示されます(図18-3)。

図18-3 WEMフレームワークの外部からアクセスしたガジェット管理者インタフェース

注意:

ガジェット管理者インタフェースが表示されなかったり、Access Denied以外のエラー・メッセージが表示される場合は、ログイン・エラーが発生しており、続行できません。

障害が表示される場合、コミュニティ-ガジェット・ログ・ファイルおよびアプリケーション・サーバーのログで障害元の詳細について確認します。

18.2 コミュニティ-ガジェット・アプリケーションの登録

最初の起動中(コミュニティ-ガジェット・アプリケーション・サーバーを最初に起動したとき)に、コミュニティ-ガジェットによってそれ自体が管理WebCenter Sitesインスタンスに登録されます。それによって、次の2つのWEMアプリケーションが作成されます。

- コミュニティ: このWEMアプリケーションは、コミュニティ・ユーザー・インタフェースを提供します。

- カジェット: このWEMアプリケーションは、ガジェット・ユーザー・インタフェースおよびガジェット管理者インタフェース(グローバル・カタログ)を提供します。

次の手順は、コミュニティWEMアプリケーションおよびガジェットWEMアプリケーションのインタフェースを表示することです。手順は、第18.3項「ユーザーがコミュニティおよびガジェット・インタフェースにアクセスすることを認可」を参照してください。

18.3 ユーザーがコミュニティおよびガジェット・インタフェースにアクセスすることを認可

この項では、ユーザーがコミュニティWEMアプリケーションおよびガジェットWEMアプリケーションを操作することを認可し、そのユーザーとしてログインしてインタフェースにアクセスすることで、コミュニティおよびガジェット・インタフェースを表示します。

注意:

ユーザー認証の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』に記載されています。クイック・スタートの場合、次の手順に従ってください。

この項全体を通して、WEM管理インタフェースを使用して、次のようにユーザーを認可します。

- コミュニティWEMアプリケーションとそのユーザーを、1つの共通のロールを使用して同じサイト(<app_site>)に割り当てます。同じサイト上のアプリケーションとユーザーに少なくとも1つのロールを共有させると、そのサイト上のそのアプリケーションへのそのユーザーのアクセスを許可することになります。

- ガジェットWEMアプリケーションとそのユーザーを、1つの共通のロールを使用して同じサイト(<app_site>)に割り当てます。

- ガジェットWEMアプリケーションを<base_site>に割り当て、ガジェット管理者インタフェース(グローバル・カタログ)を表示します。

ユーザーを認可するには、次の手順を完了します。

注意:

管理WebCenter Sitesシステムで読取り専用LDAPを使用している場合は、Moderatorロールを手動でそのLDAPデータベースに追加します。このロールは、ユーザーにコミュニティ・アプリケーションのモデレータ権限を付与するために必要です。他のすべてのコミュニティ-ガジェット・ロール(GeneralAdmin、SiteAdminおよびDesigner)は、WebCenter Sitesで事前定義されています。

1. コミュニティWEMアプリケーション<app_site>に割り当てます。

1. WEM管理インタフェースの「アプリケーション」ページから開始し、「コミュニティ」アプリケーション名をポイントし、「アプリケーションの管理」を選択します。

2. 「アプリケーションの管理」画面で、「サイトへの割当て」をクリックします。

3. コミュニティWEMアプリケーションを割り当てる<app_site>サイトを選択します。

4. コミュニティ・アプリケーションに対して次のロールを選択します。GeneralAdmin、SiteAdmin、ModeratorおよびDesigner。

2. ガジェットWEMアプリケーション<app_site>に割り当てます。

1. WEM管理インタフェースの「アプリケーション」ページから開始し、「ガジェット」アプリケーション名をポイントし、「アプリケーションの管理」を選択します。

2. 「アプリケーションの管理」画面で、「サイトへの割当て」をクリックします。

3. ガジェットWEMアプリケーションの割り当てる<app_site>サイトを選択します。

4. ガジェット・アプリケーションに対して次のロールを選択します。GeneralAdmin、SiteAdminおよびDesigner。

3. ガジェットWEMアプリケーション<base_site>に割り当てます。

1. WEM管理インタフェースの「アプリケーション」ページから開始し、「ガジェット」アプリケーション名をポイントし、「アプリケーションの管理」を選択します。

2. 「アプリケーションの管理」画面で、「サイトへの割当て」をクリックします。

3. ガジェットWEMアプリケーションを割り当てる<base_site>サイトを選択します。

4. ガジェット・アプリケーションに対してGeneralAdminロールを選択します。

4. ユーザーがコミュニティWEMアプリケーションにアクセスすることを認可します。

1. メニュー・バーで、「サイト」を選択します。

2. コミュニティWEMアプリケーションを割り当てるサイトをポイントし、「サイト・ユーザーの管理」を選択します。

3. 「サイト・ユーザーの管理」画面で、必要に応じて、次の手順の1つまたは両方を完了します。

1. サイトにユーザーを割り当て、ユーザーにロールを割り当てるには、「ユーザーの割当て」をクリックします。

2. 既存のサイト・ユーザーにロールを割り当てるには、そのユーザーの名前をポイントし、「ユーザーへのロールの割当て」を選択します。
「ユーザーへのロールの割当て」画面で、次のロールの少なくとも1つを選択します。GeneralAdmin、SiteAdmin、Designer、Moderator。

「保存して閉じる」をクリックします。

注意:

ユーザーのいずれかにSiteAdminロールを割り当てた場合、そのユーザーがSiteAdmin_AdminSiteというRESTセキュリティ・グループのメンバーであることを確認します。RESTセキュリティ・グループへのユーザーの追加手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』のWebエクスペリエンス管理フレームワークの管理の部を参照してください。

5. ユーザーがガジェットWEMアプリケーションにアクセスすることを認可します。

1. メニュー・バーで、「サイト」を選択します。

2. ガジェットWEMアプリケーションを割り当てるサイトをポイントし、「サイト・ユーザーの管理」を選択します。

3. 「サイト・ユーザーの管理」画面で、必要に応じて、次の1つまたは両方を完了します。

- サイトにユーザーを割り当て、ユーザーにロールを割り当てるには、「ユーザーの割当て」をクリックします。

- 既存のサイト・ユーザーにロールを割り当てるには、そのユーザーの名前をポイントし、「ユーザーへのロールの割当て」を選択します。
「ユーザーへのロールの割当て」画面で、次のロールの少なくとも1つを選択します。<app_siteのGeneralAdmin、SiteAdmin、Designer。<base_siteに対してGeneralAdminロールを選択します。各ロールに関連付けられている権限は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』の「Oracle WebCenter Sites: コミュニティ・アプリケーションにようこそ」の章を参照してください。

「保存して閉じる」をクリックします。

注意:

ユーザーのいずれかにSiteAdminロールを割り当てた場合、そのユーザーがSiteAdmin_AdminSiteというRESTセキュリティ・グループのメンバーであることを確認します。RESTセキュリティ・グループへのユーザーの追加手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』のWebエクスペリエンス管理フレームワークの管理の部を参照してください。

6. 次のようにして、<app_site>上のコミュニティWEMアプリケーションへの各ユーザーのアクセスを検証します。

1. 前述の手順で認可したコミュニティ・ユーザーとしてWebCenter Sitesにログインします。

2. 図18-4に示すように、<app_site>を選択し、コミュニティ・アプリケーション・アイコンをクリックします。

図18-4 「サイト」ドロップダウン・リストおよびコミュニティ・アプリケーション・アイコン

3. 「すべてのコメント」画面が表示されます(図18-5)。Designerロールを持つユーザーには、「すべての投票」画面が表示されます。名前の付いた画面が表示された場合は、現在のユーザーがコミュニティ・インタフェースにアクセスすることの認可が完了しました。次のステップに進みます。

図18-5 「すべてのコメント」画面

7. 次のようにして<app_site>および<base_site>上のガジェットWEMアプリケーションへの各ユーザーのアクセスを検証します。

1. 前述の手順で認可したガジェット・ユーザーとしてWebCenter Sitesにログインします。

2. 図18-6に示すように、<app_site>を選択し、ガジェット・アプリケーション・アイコンをクリックします。

図18-6 「サイト」ドロップダウン・リストおよびガジェット・アプリケーション・アイコン

3. 「カタログ」画面(図18-7)が表示された場合は、現在のユーザーが<app_site>上のガジェットWEMアプリケーションにアクセスすることの認可が完了しました。次のステップに進みます。

4. 図18-7 ガジェット・ユーザー・インタフェース

8. 次のようにして、<base_site>上のガジェットWEMアプリケーションへの一般管理者のアクセスを検証します。

1. 一般管理者としてWebCenter Sitesにログインします。

2. 図18-8に示すように、<base_site>を選択し、ガジェット・アプリケーション・アイコンをクリックします。

図18-8 「サイト」ドロップダウン・リストおよびガジェット・アプリケーション・アイコン

3. ガジェット管理者インタフェース(グローバル・カタログ)が表示されます(図18-9)。次のステップに進みます。

図18-9 ガジェット管理者インタフェース

9. 追加のサイトにコミュニティWEMアプリケーションまたはガジェットWEMアプリケーションを割り当てる場合は、最初にWebCenter Sitesコンテンツ管理システム上のサイトを作成または選択し、そのサイトをWebCenter Sites本番システムにミラー・パブリッシュし、この項の手順を繰り返します。

18.4 WebCenter Sitesコントリビュータ・インタフェースへのコミュニティ-ガジェットの統合

管理コミュニティ-ガジェットWebアプリケーションをWebCenter Sitesコントリビュータ・インタフェースに統合した場合、ユーザーは、WebCenter Sitesコントリビュータ・インタフェースからウィジェットおよびガジェットを直接デプロイできます。

WebCenter Sitesコントリビュータ・インタフェースにコミュニティ-ガジェットを統合するには:

1. 次のように、コミュニティ-ガジェットのURLをfuturetense_xcel.iniプロパティ・ファイルに追加します。

1. WebCenter Sitesプロパティ・エディタでfuturetense_xcel.iniファイル(管理WebCenter Sitesインストール・フォルダにある)を開きます。

2. cg.management.urlを設定し、管理コミュニティ-ガジェットWebアプリケーションのURLを指定します。
ファイルの修正にプロパティ・エディタを使用していない場合、プロパティ値の構文は次のようになります。コロン文字(:)は円記号(\)でエスケープする必要があります。

cg.management.url=<protocol>\://<cg_mgmt_host>\:<cg_mgmt_port>/<cg_mgmt_context>

例:

cg.management.url=http\://cgmgmt.example.com\:8280/cg

3. cg.production.urlを設定し、本番コミュニティ-ガジェットWebアプリケーションのURLを指定します。
ファイルの修正にプロパティ・エディタを使用していない場合、プロパティ値の構文は次のようになります。コロン文字(:)は円記号(\)でエスケープする必要があります。

cg.production.url=<protocol>\://<cg_prod_host>\:<cg_prod_port>/<cg_prod_context>

例:

cg.production.url=http\://cgprod.example.com\:8380/cg

2. 管理と本番の両方のWebCenter Sitesインスタンスのアプリケーション・サーバーを再起動します。

3. コントリビュータ・インタフェースとコミュニティ-ガジェットを統合するサイトにコミュニティおよびガジェットWEMアプリケーションを割り当てていない場合は、第18.3項「ユーザーがコミュニティおよびガジェット・インタフェースにアクセスすることを認可」の手順に従ってください。

4. コミュニティ-ガジェット・アセット・タイプおよび「検索」スタート・メニュー・アイテムを有効化します。

1. 次のロールの1つを割り当てられたユーザーとして、コミュニティ・インタフェースとガジェット・インタフェースのいずれかを有効化したサイトにログインします。GeneralAdmin、SiteAdminまたはDesigner。

2. コミュニティ・インタフェースとガジェット・インタフェースのいずれかのアイコンを選択します。
コミュニティ・インタフェースとガジェット・インタフェースのいずれかに最初にアクセスしたときに、次のコミュニティ-ガジェット・アセット・タイプが、すべての必須サイトで自動的に有効化されます。CGGadget、CGPollおよびCGWidget。これらのアセット・タイプの「検索」スタート・メニュー・アイテムも、自動的に有効化されます。

5. 次のようにして、コントリビュータ・インタフェースとコミュニティ-ガジェットとの統合を検証します。

1. 次のロールの1つを割り当てられたユーザーとして、WebCenter Sitesコントリビュータ・インタフェースにログインします。GeneralAdmin、SiteAdminまたはDesigner。

2. 左側のナビゲーション・ペインにコミュニティ-ガジェット・ツリー・ペインが表示され、そのコミュニティ-ガジェット・ツリーにウィジェットおよびガジェットが含まれていることを確認します。

3. 検索フィールドに次のアセット・タイプを検索するためのオプションが表示されていることを確認します。CGGadget、CGWidgetおよびCGPoll。

4. CGWidgetアセット・タイプの検索を実行し、関連するデータが検索結果として返されることを検証します。

WebCenter Sitesコントリビュータ・インタフェースは、図18-10に示すようなものなります。コミュニティ-ガジェット・ツリーには、サイトに使用可能なウィジェットおよびガジェットがリストされます。これで、それらのウィジェットおよびガジェットは、コントリビュータ・インタフェースから直接デプロイできます。「コミュニティ-ガジェット」ツリーの詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

注意:

コントリビュータ・インタフェースにコミュニティ-ガジェット・ツリーが表示されない場合や、コミュニティ-ガジェット・アセット・タイプまたは「検索」スタート・メニュー・アイテム、あるいはその両方にコントリビュータ・インタフェースからアクセスできない場合は、futuretense_xcel.iniファイルのxcelerate.batchuserおよびxcelerate.batchpassパラメータのユーザー名およびパスワードを確認してください。これらのパラメータの詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

図18-10 WebCenter Sitesコントリビュータ・インタフェースのコミュニティ-ガジェット・ツリー

19 サンプル・ガジェットの追加

この章の内容は、次のとおりです。

- 第19.1項「サンプル・ガジェットをインストールするための前提条件」

- 第19.2項「サンプル・ガジェットのインストール」

19.1 サンプル・ガジェットをインストールするための前提条件

WebCenter Sitesには、次のサンプル・ガジェットが同梱されています(図19-1)。

ListGadget、RSSGadget、ThumbListGadgetおよび SlideshowGadget。

図19-1 WebCenter Sitesのガジェット

サンプル・ガジェットは、FirstSite IIサンプル・サイトにインストールする必要があります。そのサイトは、デモ・データを格納可能になっている必要があります。管理WebCenter SitesシステムにFirstSite IIがない場合は、次のように実行します。

図19-2に示すように、デモ・データの格納を有効化したFirstSite IIを実行するWebCenter Sitesシステムを準備します。

図19-2 FirstSite IIサンプル・サイト

新しく準備したWebCenter Sitesシステムにサンプル・ガジェットをインストールしたら(第19.2項「サンプル・ガジェットのインストール」を参照)、FirstSite IIをWebCenter Sites管理システムにパブリッシュします。

19.2 サンプル・ガジェットのインストール

サンプル・ガジェットをインストールすると、次のコンポーネントがインストールされます。

- FW_CSGadgetアセット・タイプ(ガジェットの作成に使用される)

- サンプル・ガジェット(タイプFW_CSGadgetのアセット)

- ガジェットをレンダリングするためのテンプレート

- サンプル・ガジェットにコンテンツを提供するアセット。これらのアセットは、FirstSite IIアセット・タイプのインスタンスです。

サンプル・ガジェットをインストールする手順は、次のとおりです。

1. 第19.1項「サンプル・ガジェットをインストールするための前提条件」の前提条件が満たされていることを確認します。

2. WCS_GadgetServer_Samples.zipという名前のインストール・ファイルをホスト・マシンに抽出します。このzipファイルを抽出すると、gadgets_samplesという名前のサブディレクトリが作成されます。

注意:

このサブディレクトリとそれのサブディレクトリのいずれの名前も変更しないでください。アーカイブされたディレクトリ構造を、必ず保持してください。そのようにしない場合、インストーラが失敗します。

3. 次のガジェット・アプリケーション統合インストーラ・スクリプトを実行します。

- Windows: gsInstall.bat

- UNIX: gsInstall.sh

4. 初期画面(図19-3)で、「次へ」をクリックします。

図19-3 ガジェット・サーバーのサンプル・ガジェット

5. Sitesインストール・ディレクトリ画面(図19-4)に、本番WebCenter Sitesインストール・ディレクトリのパスを入力します。

注意:

管理WebCenter Sitesインストール・ディレクトリのパスを入力することもできます。ただし、管理WebCenter Sitesインスタンスにインストールされているサンプル・ガジェットに、本番コミュニティ-ガジェット・インスタンスがアクセスできるようにしておく必要があります。

図19-4 Sitesインストール・ディレクトリ

6. インストールする製品の選択画面で、サンプル・ガジェットを選択します(図19-5)。

図19-5 インストールする製品

次のコンポーネントがインストールされます。

- FW_CSGadgetアセット・タイプ(ガジェットの作成に使用される)

- サンプル・ガジェット(タイプFW_CSGadgetのアセット)

- ガジェットをレンダリングするためのテンプレート

- サンプル・ガジェットにコンテンツを提供するアセット。これらのアセットは、FirstSite IIアセット・タイプのインスタンスです。

7. 「クラスタリング」画面(図19-6)で、単一サーバーとセカンダリ・クラスタ・メンバーのうちのどちらにサンプル・ガジェットをインストールするのかを指定します。「次へ」をクリックします。

図19-6 クラスタリング

8. 設定のサマリー画面で、「次へ」をクリックします(図19-7)。

図19-7 設定のサマリー

9. 「インストールの進行状況」画面で、「インストール」をクリックし、インストールを開始します(図19-8)。

図19-8 インストールの進行状況

10. 「インストール・アクション」ダイアログ・ボックスが開いたら、WebCenter Sitesインストールを起動し、「テスト」をクリックして、WebCenter Sitesインストールをテストします(図19-9)。「OK」をクリックします。

図19-9 インストール・アクション

11. インストールが完了したら(図19-10)、「OK」をクリックします。

図19-10 インストールが成功しました。

12. サンプル・ガジェットを、ガジェット・アプリケーションのグローバル・ガジェット・カタログまたはサイト・ガジェット・カタログのいずれかに登録します。手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』のガジェットの登録に関する項を参照してください。

注意:

ガジェットを登録するには、ガジェットの記述子URLを入力する必要があります。URLを入手するには、次の手順に従います。

サンプル・ガジェットの記述子URLを入手する手順は、次のとおりです。

1. 一般管理者の資格証明(たとえば、fwadmin /xceladmin)を使用してWebCenter Sitesにログインします。FirstSite IIサンプル・サイトを選択し、「コントリビュータ」インタフェースのアイコンを選択します。

2. 「検索」フィールドで、下矢印をクリックし、「検索タイプ」メニューを開きます。

3. 「検索タイプ」メニューでCSベースのガジェットの検索を選択します。

4. 「検索」フィールドで、拡大鏡ボタンをクリックします。

5. 検索結果リストで、サンプル・ガジェットのいずれかを右クリックし、「プレビュー」を選択します。

6. プレビュー・テンプレートの選択ダイアログ・ボックスで、ListSiteGadgetsを選択し、ガジェット記述子URLのリストを表示します。(図19-11)。

図19-11 ガジェット記述子URLのリスト

7. サンプル・ガジェットが正常に登録されると、それらは、それらのガジェットを登録した方法に応じて、グローバル・ガジェット・カタログまたはサイト・ガジェット・カタログにサムネイルとして表示されます。たとえば、図19-12を参照してください。

図19-12 サンプル・ガジェット・サムネイルが表示されているガジェット・インタフェース

サンプル・ガジェットおよびカスタム・ガジェットの作成の詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』の「ガジェットの開発」を参照してください。

第V部

Community Blogsモジュールのインストール

第V部は、次の章で構成されています。

- 第20章「Community Blogsモジュールのインストール手順」

20 Community Blogsモジュールのインストール手順

この章では、WebCenter Sites: Community Blogsモジュールの概要と、コンテンツ管理サイトへのCommunity Blogsモジュールのインストール手順について説明します。また、Community Blogsモジュールがインストールされた後にサイトに追加されたコンポーネントに関する情報も提供します。

この章の内容は、次のとおりです。

- 第20.1項「Community Blogsモジュールの概要」

- 第20.2項「Community Blogsモジュールのインストール中のWebCenter Sitesに対する変更」

- 第20.3項「Community Blogsモジュールをインストールするための前提条件」

- 第20.4項「WebCenter SitesへのCommunity Blogsモジュールのインストール」

- 第20.5項「インストールの検証」

20.1 Community Blogsモジュールの概要

コンテンツ管理サイトにCommunity Blogsモジュールをインストールすると、Webサイトへのブログの表示に特化したページの作成に必要なコンポーネントがコンテンツ・プロバイダに提供されます。

Community Blogsモジュールのコンポーネントは次のとおりです。

- Blogフレックス・ファミリ

- デフォルトSiteEntryアセット

- デフォルト・ブログ・テンプレート

- デフォルトCSElement

- サンプル・ブログ・ページ・アセット

これらのコンポーネントは、デフォルト値およびコードで事前構成済であり、図20-1に示すサンプル・ブログWebページをレンダリングします。

図20-1 Community Blogsモジュールのサンプル・ページ

自身のWebサイトにブログ・ページを追加するために、これらのブログ・コンポーネントを必要に応じて再使用および再構成できます。

Community BlogsモジュールをWebCenter Sites: コミュニティ・アプリケーションと統合すると、コミュニティ・アプリケーションのコメント・フィールドが自動的にブログ・ページに挿入され、サイトのビジターに表示されます。コメント機能によって、ビジターはブログに対するフィードバックを提供でき、それによってWebサイトのコンテンツ・プロバイダは、彼らが投稿したブログのコンテンツを向上させることができます。

20.2 Community Blogsモジュールのインストール中のWebCenter Sitesに対する変更

インストール・プロセス中に、ブログ・インストーラによって、次のコンポーネントがWebCenter Sitesシステムに追加されます。

- Blogフレックス・ファミリは、選択したCMサイトに追加されます。

- FW_BlogAsset (ブログ・アセット)

- FW_BlogParent (ブログ・カテゴリ)

- FW_BlogAssetDef (ブログ・アセット定義)

- FW_BlogParentDef (ブログ・カテゴリ定義)

- FW_BlogAttribute (ブログ属性)

- FW_BlogFilter (ブログ・フィルタ)

- FW_BlogAuthor (ブログ作成者)

- FW_BlogAuthorParent (ブログ作成者カテゴリ)

- FW_BlogAuthorDef (ブログ作成者定義)

- FW_BlogAuthorParentDef (ブログ作成者カテゴリ定義)

- Blogフレックス・ファミリのスタート・メニュー・アイテムは、サイト上で自動的に有効化されます。

注意:

Community Blogsモジュールのツリー・タブは、手動で作成し、サイトに対して有効化する必要があります。このツリー・タブで、コンテンツ・プロバイダは、ブログ・アセットおよびカテゴリの階層を確認できます。ツリー・タブの作成手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- 次のブログ関連コンポーネントおよびサンプル・アセットが、コンテンツ管理サイトに追加されます。

- サンプル・ブログ・ページ・アセット

- デフォルト・ブログCSElement

- デフォルト・ブログ・テンプレート

- デフォルトSiteEntryアセット

そのままで使用でき、そのサンプル・ブログ・ページをテストWebサイトにパブリッシュするとそれらのデフォルトの外観を表示できます(図20-1に示す)。デフォルト・ブログ・コンポーネントは、必要に応じて再使用および再構成することもできます。サンプル・ブログ・ページを構成するコンポーネントの詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』の「Community Blogs: サンプル・ブログ・ページ」の章を参照してください。

- Community Blogsモジュールをコミュニティ・アプリケーションと統合すると、次のプロパティがfuturetense_xcel.iniファイルに追加されます。

プロパティ

説明

fwblogs.cos.enabled

Community Blogsモジュールが既存のコミュニティ-ガジェット・インストールと統合されている場合、このプロパティはTRUEに設定されています。

cos.hostname

このプロパティは、コミュニティ-ガジェット本番システムのホスト名を指します。

cos.portnumber

このプロパティは、コミュニティ-ガジェット本番システムのポート番号を指します。

cos.protocol

このプロパティは、コミュニティ-ガジェット本番システムのプロトコル(httpまたはhttps)を指します。

cos.contextroot

このプロパティは、コミュニティ-ガジェット本番システムのコンテキスト・ルートを指します。

20.3 Community Blogsモジュールをインストールするための前提条件

Community Blogsモジュールをインストールする前に、次の要件が満たされていることを確認します。

- Community Blogsモジュールは、コンテンツ管理または開発システムのいずれか、および配信システム上で実行されている完全に機能しているWebCenter Sitesシステムにインストールする必要があります。

注意:

管理WebCenter Sitesシステムと配信WebCenter SitesシステムにCommunity Blogsモジュールをインストールした場合、WebCenter Sites配信システム上のfuturetense_xcel.iniファイルの次のパラメータが管理WebCenter Sitesシステム上のものと同じ値になっていることを確認します。

- fwblogs.cos.enabled

- cos.protocol

- cos.hostname

- cos.portnumber

- cos.contextroot

- Community Blogsモジュールとコミュニティ-ガジェット・アプリケーションを統合する場合、コミュニティ-ガジェット本番システムの完全なURL(プロトコル、コンテキスト・ルート、ホスト名およびポート番号)を把握している必要があります。コミュニティ・アプリケーションの機能の詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

注意:

コミュニティ・アプリケーションと統合すると、Community Blogsモジュールは、Oracle WebCenter Sites: Webエクスペリエンス管理(WEM)フレームワークを使用します。

- Community Blogsモジュールをインストールするコンテンツ管理サイトを選択または作成します。そのサイトは、Community Blogsモジュール・コンポーネントおよびサンプル・アセットの格納に専用となります。このサイトの目的は、サンプル・アセットをレビューし、ブログ・データ・モデルを確認し、試用してみることです。同じサイトが、配信システムにも存在している必要があります。

20.4 WebCenter SitesへのCommunity Blogsモジュールのインストール

この項では、GUIインストーラを使用して、選択したコンテンツ管理サイトにCommunity Blogsモジュールをインストールする方法について説明します。コンテンツ管理または開発システム、および配信システム上でインストーラを実行します。

注意:

Community Blogsモジュールのインストールを開始するときは、WebCenter Sitesインストールが稼働していないことを確認します。WebCenter Sitesが稼働している場合は、インストールに失敗します。

WebCenter SitesシステムにCommunity Blogsモジュールをインストールする手順は次のとおりです。

1. WebCenter Sitesを実行しているマシンにCommunityServerBlogs.zipを抽出します。

2. 次のブログ・インストーラ・スクリプトを実行します。

- Windows: blogInstall.bat

- UNIX: blogInstall.sh

3. 初期画面(図20-2)で、「次へ」をクリックします。

図20-2 初期画面

4. Sitesインストール・ディレクトリ画面に、WebCenter Sitesインストール・ディレクトリのパスを入力します(図20-3)。

図20-3 Sitesインストール・ディレクトリ

5. インストールする製品の選択画面で、インストールする製品を選択します(図20-4)。

図20-4 インストールする製品

6. 「クラスタリング」画面で、単一サーバーとクラスタ・メンバーのうちのどちらにCommunity Blogsモジュールをインストールするのかを指定します(図20-5)。

図20-5 クラスタリング

7. Community Blogsモジュールをコミュニティ・アプリケーションと統合する場合は、「はい」を選択します(図20-6)。

図20-6 Community Blogsとコミュニティ・アプリケーションの統合

注意:

Community Blogsモジュールをコミュニティ・アプリケーションと統合すると、Webサイトのブログ・テンプレートにコメント・ウィジェットおよびコメント・リンクのためのタグが自動的に追加されます。

8. Community Blogsモジュールとコミュニティ・アプリケーションを統合することを選択する場合は、コミュニティ・アプリケーションの本番システムに関して次の情報を入力する必要があります(図20-7)。

- コミュニティ・アプリケーションを実行しているマシンのホスト名またはIPアドレス。

- コミュニティ・アプリケーションが実行されているポート番号。

図20-7 本番の情報

9. 設定のサマリー画面で、Community Blogsモジュールをインストールする環境を確認します(図20-8)。「次へ」をクリックします。

図20-8 設定のサマリー

10. 「インストールの進行状況」画面で、「インストール」をクリックします(図20-9)。

図20-9 インストールの進行状況

11. アプリケーション・サーバーが実行中でないことを確認します(図20-10)。「OK」をクリックします。

図20-10 アプリケーション・サーバーの警告

12. インストール中に「インストール・アクション」ダイアログ・ボックスが開きます(図20-11)。

1. WebCenter Sitesシステムを起動します。

2. 「テスト」をクリックし、Community BlogsモジュールとWebCenter Sitesとの間のデータベース接続をテストします。

3. 「OK」をクリックしてインストールを続行します。

図20-11 インストール・アクション

13. 「サイトの選択」画面が開き(図20-12)、WebCenter Sitesシステム上のコンテンツ管理サイトがリストされます。Community Blogsモジュールをインストールするサイトを選択します。「OK」をクリックします。

図20-12 サイトの選択

注意:

Community Blogsインストーラを複数回実行すると、最初にインストーラを実行したときに選択したサイトにCommunity Blogsモジュールが自動的にインストールされます。

14. インストールが完了しました(図20-13)。「OK」をクリックしてインストーラを終了します。WebCenter Sitesシステムを停止してから再起動します。

図20-13 インストールの進行状況

15. インストールに成功したことを確認します。第20.5項「インストールの検証」を参照してください。WebCenter Sitesシステムに追加されたブログ・コンポーネントおよびサンプル・アセットに関する情報が必要な場合は、第20.2項「Community Blogsモジュールのインストール中のWebCenter Sitesに対する変更」を参照してください。

20.5 インストールの検証

インストーラによって、コンテンツ管理サイトにBlogフレックス・ファミリが追加されています。このフレックス・ファミリは、ブログWebページを作成するためのフレームワークを提供します。

注意:

WebSphereアプリケーション・サーバーの場合は、Blogsアプリケーションをインストールした後にContentServer.earファイルを再デプロイします。

Blogフレックス・ファミリがCMサイトに追加されたことを確認する手順は次のとおりです。

1. 一般管理者の資格証明(デフォルトではfwadmin /xceladmin)を使用してWebCenter Sitesにログインします。Community Blogsモジュールをインストールしたサイトを選択し、WebCenter Sitesの「管理」アイコンを選択します。

2. WebCenter Sitesツリーに移動し、「管理」タブを選択します。

1. 「フレックス・ファミリ・メーカー」ノードを開きます。
ブログ属性アセット・タイプがリストされていることがわかります。

2. Blogフレックス・ファミリのすべてのノードを開きます。ブログ階層は、図20-14のように表示されます。

図20-14 ブログ階層

Blogフレックス・ファミリ階層が前述のようにレンダリングされる場合、Community Blogsモジュールが正常にインストールされています。WebCenter Sitesインストールに追加されたブログ・コンポーネントの詳細は、第20.2項「Community Blogsモジュールのインストール中のWebCenter Sitesに対する変更」を参照してください。

第VI部

Oracle WebCenter Sites: サイト・キャプチャのインストール

第VI部は、次の章で構成されています。

- 第21章「WebCenter Sites: サイト・キャプチャの概要」

- 第22章「サイト・キャプチャ・アプリケーション・サーバーの構成」

- 第23章「サイト・キャプチャのインストール手順」

- 第24章「パブリッシュによってトリガーされるサイト・キャプチャの有効化」

21 WebCenter Sites: サイト・キャプチャの概要

この章では、サイト・キャプチャ・アプリケーションおよびインストール・プロセスの概要を示します。

この章では、次の項目について説明します。

- 第21.1項「WebCenter Sites: サイト・キャプチャについて」

- 第21.2項「サイト・キャプチャのインストールの概要」

- 第21.3項「始める前に」

- 第21.4項「次のステップ」

21.1 WebCenter Sites: サイト・キャプチャについて

Oracle WebCenter Sites: サイト・キャプチャは、Webアプリケーションであり、Oracle WebCenter Sites: Webエクスペリエンス管理(WEM)フレームワークを介してOracle WebCenter Sitesと統合され、評価、コンプライアンス目的、高可用性要件および他のタイプのシナリオのために、動的にパブリッシュされたWebサイトをキャプチャします。

クロールは、サイト・キャプチャ・インタフェースから手動で開始するか、WebCenter Sites RealTimeパブリッシュ・セッションの完了によってトリガーできます。各シナリオでは、クローラは、ユーザーの選択に基づいて次のモードの1つでサイトをキャプチャします。

- 静的モード: サイトは、提供する準備が整ったファイルとして格納されます。最新のキャプチャのみが保持されます。

- アーカイブ・モード: サイトはzipファイルに格納されます。サイト・キャプチャ・データベース内のポインタによって、サイト・キャプチャ・インタフェースからのアーカイブ管理が可能です。

21.2 サイト・キャプチャのインストールの概要

このガイドには、次のものをサポートするサイト・キャプチャのインストールおよび構成手順が記載されています。

- 静的およびアーカイブ・キャプチャを、サイト・キャプチャ・インタフェースから手動で開始します。

- 静的およびアーカイブ・キャプチャを、WebCenter Sites RealTimeパブリッシュ・セッションの完了によってトリガーします。パブリッシュによってトリガーされるサイト・キャプチャの設定はオプションです。

- 管理ユーザーおよび開発者。サイト・キャプチャ・アプリケーションは、サイト・キャプチャ・アプリケーションが実行されるWebCenter Sitesシステムの一般管理者向けに設計されています。開発者が、高度なクローラ構成コード(たとえば、サイト・キャプチャが、静的にキャプチャされたサイトをWebサーバーのドキュメント・ベースにコピーするなど、クロール後のコマンドを実行するようトリガーするコード)を記述します。

21.3 始める前に

このガイドのユーザーは、エンタープライズレベルのソフトウェア(アプリケーション・サーバーやデータベースなど)のインストールおよび構成の経験が必要です。また、WebCenter SitesおよびWEM管理インタフェースでの一般管理者の経験も必要です。

- このガイドの手順を完了するには、RESTAdminセキュリティ・グループに属するWebCenter Sites一般管理者であることが必要です。

- サポートされるオペレーティング・システム、アプリケーション・サーバー、データベースおよびブラウザの詳細は、Oracle WebCenter Sites 11gリリース1 (11.1.1.x)動作保証マトリックスをダウンロードしてください。また、サイト・キャプチャの情報は、Oracle WebCenter Sitesリリース・ノートをダウンロードしてください。

- このガイドをお読みになり、サイト・キャプチャのインストール・プロセスの理解を深めてください。基本手順は、サイト・キャプチャ・アプリケーション・サーバーの構成、サイト・キャプチャwarファイルを作成するためのインストーラの実行、サイト・キャプチャのデプロイ、インストール後および検証の手順の完了、および必要であればパブリッシュによってトリガーされるサイト・キャプチャのセットアップです。

- すべてのシステムで、JAVA_HOME変数が、JDK 1.6の有効なインストールを指し示すように設定します。

- サイト・キャプチャ・インストール・コンポーネントを準備します。

- 開発またはコンテンツ管理モードで実行されている、専用の完全に機能しているOracle WebCenter Sitesインストールがあることを確認します。サイト・キャプチャを実行するには、このWebCenter Sitesシステムと通信する必要があります。

- サイト・キャプチャ・アプリケーション・サーバーおよびそのアプリケーション自体をインストールする専用のアプリケーション・サーバーがあることを確認します。インストール・プロセス中に、WebCenter Sitesシステム(前述のもの、それ自体のホスト・マシン上で実行されている)と通信するようにサイト・キャプチャを構成します。

- サイト・キャプチャ・アプリケーションを、単一アプリケーションとして実行するのか、クラスタ化モードで実行するのかを決定します。単一サーバー・インストール、およびクラスタ化されたインストールの図は、図21-1を参照してください。

- 次のコンポーネントをインストールまたは再使用します。
専用のアプリケーション・サーバーでサポートされるサイト・キャプチャ・アプリケーション・サーバーをインストールします。クラスタ化されたインストールの場合は、サイト・キャプチャ・インスタンスごとにアプリケーション・サーバーをインストールします。

クラスタ化されたインストールの場合、選択したホスト・マシンにロード・バランサをインストールします。サイト・キャプチャ・インストール・ディレクトリは、すべてのクラスタ・メンバーからアクセス可能な共有ディレクトリであることが必要です。

アーカイブされたサイトを格納するために、WebCenter Sitesのデータベースを再使用することも、選択したホスト・マシンに、専用のサポートされているサイト・キャプチャ・データベースをインストールすることもできます。

- パブリッシュによってトリガーされるサイト・キャプチャを実行するかどうかを決定します。その場合は、WebCenter Sitesソースおよびターゲット・システムが必要になります。

- ターゲット・システムは、REST APIおよびWEM SSO APIを備えており、それによって、ターゲット・システムが、必要なクローラを起動するためにパブリッシュ・セッションの終わりにサイト・キャプチャ・アプリケーションと通信できるようになります。その後、サイト・キャプチャ・アプリケーションは、クローラ起動ステータスをターゲットWebCenter Sitesシステムに送信し、そこから、同じ情報がソースWebCenter Sitesシステムに送信されます。両方のWebCenter Sitesシステムによって、それら自体のログ・ファイル(デフォルトではfuturetense.txt)にステータス情報が記録されます。

- ソースおよびターゲットWebCenter Sitesシステムを、サイト・キャプチャ・インストールと統合します。可能な構成のいくつかについては、図21-2「パブリッシュによってトリガーされるサイト・キャプチャが可能な単一サーバー・インストール」および図21-3「パブリッシュによってトリガーされるサイト・キャプチャが可能なクラスタ化されたインストール」を参照してください。

- サンプル・クローラをインストールするかどうかを決定します(推奨)。サンプル・クローラの詳細は、第23.1項「インストール手順」のステップ1の注意を参照してください。

- サイト・キャプチャは、サイレントにインストールするか、グラフィカルでインストールするかを選択できます。サイレント・インストーラは、設定する必要があるすべての情報それぞれについてヘルプとサンプル値を備えています。

図21-1 単一サーバーとクラスタ化されたインストール

図21-2 パブリッシュによってトリガーされるサイト・キャプチャが可能な単一サーバー・インストール

図21-3 パブリッシュによってトリガーされるサイト・キャプチャが可能なクラスタ化されたインストール

21.4 次のステップ

第22章「サイト・キャプチャ・アプリケーション・サーバーの構成」に続きます。

22 サイト・キャプチャ・アプリケーション・サーバーの構成

サイト・キャプチャは、単一アプリケーションとしても、クラスタ化されたインストール内でも実行できます。

この章では、次の項目について説明します。

- 第22.1項「構成オプション」

- 第22.2項「Tomcat Application Serverの構成」

- 第22.3項「WebLogic Application Serverの構成」

- 第22.4項「WebSphere Application Serverの構成」

22.1 構成オプション

この章では、単一インスタンスとしてまたはクラスタ・モードで実行されるサイト・キャプチャをサポートするようにアプリケーション・サーバーを構成します。

注意:

構成手順に進む前に、アーカイブのプレビューをサポートするには、サイト・キャプチャ・アプリケーションをコンテキスト・ルート/で実行する必要があることに注意してください。(サイト・キャプチャは、アーカイブ内からページを提供し、それはどのようなコンテキスト・ルートを持っていても構いません。)

次の手順の1つを完了します。

- 第22.2項「Tomcat Application Serverの構成」

- 第22.3項「WebLogic Application Serverの構成」

- 第22.4項「WebSphere Application Serverの構成」

22.2 Tomcat Application Serverの構成

クラスタ化された環境を作成する場合は、すべてのクラスタ・メンバーで次の手順を完了します。

Tomcatを構成する手順は、次のとおりです。

1. <apache-tomcat-6.0.29 directory>\confのserver.xmlを開き、次のように実行します。

1. ポート8080をサイト・キャプチャ・ポート(アプリケーション・サーバーがリスニングするもの)に置き換えます。

注意:

クラスタ化されたインストールの場合は、各クラスタ・メンバーに一意のポート番号を指定します。

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

2. サイト・キャプチャのデータ・ソースを構成します。

注意:

クラスタ化されたインストールの場合は、各クラスタ・メンバーに同じデータ・ソースを構成します。

選択したドライバのドライバ・クラス名およびURLの構成の詳細は、表22-1を参照してください。

次に、サンプルDB2構成を示します。

<Context path="" docBase="ROOT" debug="5" reloadable="true" crossContext="true">
<Resource name="scDataSource"
auth="Container"
type="javax.sql.DataSource"
url="jdbc:db2://<hostname>:<port>/CLUSTDB"
driverClassName="com.ibm.db2.jcc.DB2Driver"
username="xxxxx"
password="xxxxxxx"
maxActive="20"
maxIdle="10"
maxWait="-1" />
</Context>

表22-1 データベース・ドライバ・パラメータ

データベース・ドライバ

パラメータ

値

SQL Server

DriverClass

net.sourceforge.jtds.jdbcx. JtdsDataSource

SQL Server

必須.jarファイル

jtds-1.2.jar

SQL Server

URL

jdbc:jtds:sqlserver://<server>:<dbport>/<dbname>

例: jdbc:jtds:sqlserver://192.0.2.1:1433/SC70

DB2

DriverClass

com.ibm.db2.jcc.DB2Driver

DB2

必須.jarファイル

db2jcc.jar, db2cc_license_cu.jar

DB2

URL

jdbc:db2://<hostname>:<dbport>/<dbname>

例: jdbc:db2://192.0.2.1:5000/ SC70

Oracle

DriverClass

oracle.jdbc.driver.OracleDriver

Oracle

必須.jarファイル

Ojdbc6.jar

Oracle

URL

jdbc:oracle:thin:@//<hostname>:1521/<dbname>

例: jdbc:oracle:thin:@//godzilla.fatwire.com:1521/SC70

2. 必須データベース・ドライバJARファイルを<apache-tomcat-6.0.29 directory>\libにコピーします。

3. アプリケーション・サーバーの構成を完了したら、第23章「サイト・キャプチャのインストール手順」に進みます。

22.3 WebLogic Application Serverの構成

クラスタ化された環境を作成する場合は、すべてのクラスタ・メンバーで次の手順を完了します。

WebLogicを構成する手順は、次のとおりです。

1. WebLogicにドメインを作成し、そのドメインの管理者ユーザー名およびパスワードを構成します。

2. 次のように、コマンド・プロンプトからWebLogic管理サーバーを起動します。

- Windows: startweblogic.cmd

- UNIX: ./startweblogic.sh

3. コンソールにログインします。

1. 直前に作成したドメインに管理対象サーバー<managed_server_name>を作成します。

注意:

クラスタ化されたインストールの場合は、各クラスタ・メンバーに一意のポート番号を指定します。

2. データ・ソースを作成し、それを管理対象サーバー<managed_ server_name>にマップします。

注意:

クラスタ化されたインストールの場合は、各クラスタ・メンバーに同じデータ・ソースを構成します。

4. アプリケーション・サーバーの構成を完了したら、第23章「サイト・キャプチャのインストール手順」に進みます。

22.4 WebSphere Application Serverの構成

クラスタ化された環境を作成する場合は、すべてのクラスタ・メンバーで次の手順を完了します。

WebSphereを構成する手順は、次のとおりです。

1. WebSphereアプリケーション・サーバー・インスタンスを作成します。

注意:

クラスタ化されたインストールの場合は、各クラスタ・メンバーに一意のポート番号を指定します。

2. 新しく作成したサーバー・インスタンスのデータ・ソースを作成します。

注意:

クラスタ化されたインストールの場合は、各クラスタ・メンバーに同じデータ・ソースを構成します。

1. 必須データベース・ドライバを<websphere_install_dir>/websphere/AppServer/universalDriver/libにコピーします(必須ドライバは表22-1を参照してください)。

2. WebSphereコンソールにログインし、次のように実行します。
データベースのユーザー名およびパスワードを、別名を作成することで追加します(「Security」に移動し、「Global security」→「Java Authentication and Authorization Service」→「J2C authentication data」を選択します)。

JDBCプロバイダおよびデータ・ソースを作成します(「Resources」に移動し、「JDBC」を選択します)。

3. アプリケーション・サーバーの構成を完了したら、第23章「サイト・キャプチャのインストール手順」に進みます。

23 サイト・キャプチャのインストール手順

サイト・キャプチャは、グラフィカルでもサイレントでもインストールできます。最初にインストーラを使用してwarファイルを作成し、そのwarファイルを手動でデプロイし、インストールをテストします。

この章では、次の項目について説明します。

- 第23.1項「インストール手順」

- 第23.2項「インストール後の手順」

- 第23.3項「次のステップ」

23.1 インストール手順

サイト・キャプチャ・をインストールするには、次の基本手順を完了する必要があります。

1. サイレントまたはGUIインストーラを実行し、サイト・キャプチャwarファイル(ROOT.war)を作成します。

2. 注意:
クラスタ化されたインストールおよびサンプル・クローラのインストールについて次の事項に注意してください。

- クラスタ化されたインストールを作成する場合は次のようにします。
インストーラを1回実行します。この章に示すように、すべてのクラスタ・メンバーにROOT.warファイル(およびROOTフォルダ)をデプロイします。サイト・キャプチャ・インストール・ディレクトリは、すべての他のクラスタ・メンバーからアクセス可能な共有ディレクトリであることが必要です。

- サンプル・クローラのインストールをお薦めします。サイト・キャプチャ・インストールを迅速にテストおよび使用する手順は、次に示すSampleクローラに基づいています。
Sampleは、基本的なクローラであり、任意の動的サイトをキャプチャするように簡単に構成できます。構成手順は、クローラの構成ファイルにクローラの開始URIを設定することです。

FirstSiteIIは、WebCenter Sites FirstSiteIIサンプルWebサイトをキャプチャするための高度な構成コードを備えたクローラです。このコードは、クローラのサイト・キャプチャ・プロセス(この例では静的サイトとしての動的サイト(FirstSiteII)のダウンロード)の制御に使用される様々なメソッドおよびインタフェースの実装を示します。

クローラは、不要になった場合は簡単に削除できます。

3. WebCenter SitesをOracle Access Manager (OAM)とともに実行している場合は、OAMをサイト・キャプチャと統合します。

4. サイト・キャプチャ・アプリケーションをデプロイします。

詳細な手順は、この項の残りの部分で説明します。

23.1.1 サイレント・インストーラの実行

注意:

サイレント・インストーラのかわりにGUIインストーラを実行する場合は、第23.1.2項「GUIインストーラの実行」にスキップします。

1. sitecapture.zipファイルを、サーバー上の望ましい場所に解凍します。

2. ファイル内に記述されている手順に従って、omii.iniファイル(抽出されたフォルダのルート・レベルにある)を構成し、そのファイルを保存します。
単一インストールおよびクラスタ化されたインストールのどちらでも、ホスト名とポート番号は外部からアクセス可能であることが必要です。

注意:

サンプル・クローラのインストールをお薦めします。クローラの詳細は、第23.1項「インストール手順」のステップ1の注意を参照してください。

3. Install.iniファイル(抽出されたフォルダのルート・レベルにある)を開き、最初のセクションに行loadfile=omii.iniを追加し、そのファイルを保存します。

4. コマンド・プロンプトを開き、次のコマンドの1つを実行します。

- Windows: scInstall.bat -silent

- Linux: scInstall.sh -silent

インストールに成功すると、コマンド・ウィンドウに次のメッセージが表示されます。"Installation Finished Successfully"

5. インストーラ・プロセスが正常に終了するまで待ち、再びコマンド・プロンプトを表示します。ROOTフォルダおよびROOT.warファイルが、omii.iniファイルに指定されたインストール・ディレクトリのwebappsフォルダに作成されます。

6. 次のいずれかを実行します。

- WebCenter SitesをOracle Access Manager (OAM)とともに実行している場合は、OAMをサイト・キャプチャ・アプリケーションと統合します。手順は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』のroot-context.xmlファイルの調整に関する項を参照してください。

- WebCenter SitesをCASとともに実行している場合は、第23.1.3項「サイト・キャプチャのデプロイ」に進みます。

23.1.2 GUIインストーラの実行

注意:

GUIインストーラのかわりにサイレント・インストーラを実行する場合は、第23.1.1項「サイレント・インストーラの実行」に進みます。

1. sitecapture.zipをサイト・キャプチャ・サーバーのディレクトリにダウンロードし、それを一時ディレクトリに抽出します。抽出されたフォルダには、scInstall.batおよびscInstall.shファイルが含まれており、それらは、サイト・キャプチャ・インストーラを実行するために必要です。

2. 次のインストーラ・スクリプトを実行します。

- Windowsの場合: scInstall.bat

- UNIXの場合: scInstall.sh
インストーラの初期画面が表示されます(図23-1)。

図23-1 初期画面

3. サイト・キャプチャがインストールされているディレクトリのパスを指定し(図23-2)、「次へ」をクリックします。

図23-2 サイト・キャプチャ・インストール・ディレクトリ

4. インストールする製品(サイト・キャプチャ)を選択し(図23-3)、「次へ」をクリックします。

図23-3 インストールする製品の選択

5. 単一サーバーと「クラスタ」のいずれかを選択し(図23-4)、「次へ」をクリックします。

図23-4 サイト・キャプチャのインストール・タイプ

6. サイト・キャプチャのホスト・マシンに関する情報を入力します(図23-5)。単一インストールおよびクラスタ化されたインストールのどちらでも、ホスト名とポート番号は外部からアクセス可能であることが必要です。

- 単一サーバーのインストール:

- サイト・キャプチャ・アプリケーション・サーバーを実行しているマシンのホスト名(またはIPアドレス)を入力します。

- サイト・キャプチャ・アプリケーション・サーバーのポート番号を入力します(アプリケーション・サーバーの構成手順で指定したものと同じ番号)。

- プロトコルをHTTPまたはHTTPSに指定します。

図23-5 サイト・キャプチャ情報: 単一サーバー

- クラスタ化されたインストール(図23-6):

- ロード・バランサを実行しているマシンのホスト名(またはIPアドレス)を入力します。

- ロード・バランサのポート番号を入力します。

- プロトコルをHTTPまたはHTTPSに指定します。

図23-6 サイト・キャプチャ情報: クラスタ化されたインストール

7. サイト・キャプチャがアプリケーションとして実行されているWebCenter Sitesシステムに関する情報を入力します(図23-7)。

- WebCenter Sitesホスト名またはIPアドレス

- WebCenter Sitesがリスニングするポート

- WebCenter Sitesアプリケーション・サーバーのプロトコル(HTTPまたはHTTPS)

- WebCenter Sitesアプリケーションのコンテキスト・ルート

図23-7 Oracle WebCenter Sitesの情報

8. WebCenter Sites管理者の資格証明を入力します(図23-8)。

- WebCenter Sites一般管理者の現在のユーザー名

- 現在のパスワード

図23-8 Oracle WebCenter Sitesの管理情報

9. CASアプリケーションに関する情報を入力します(図23-9)。

- CASホスト名(またはIPアドレス)

- ポート番号

- CASアプリケーション・サーバーのプロトコル(HTTPまたはHTTPS)

- CASコンテキスト・ルート

図23-9 CASサーバー情報

10. サイト・キャプチャをインストールするアプリケーション・サーバーを選択します(図23-10)。

注意:

インストーラによってROOT.warファイルが作成されます。それはアプリケーション・サーバーにデプロイします。

図23-10 「アプリケーション・サーバーの情報」

11. データベース情報を入力します(図23-11)。

- サイト・キャプチャが接続するデータベースを選択します(サイト・キャプチャのデータベースとWebCenter Sitesのデータベースのいずれかを選択します)。

- サイト・キャプチャのデータ・ソースの名前を、アプリケーション・サーバーで構成したとおりに指定します。

図23-11 「データベース情報」

12. サンプル・クローラをインストールするかどうかを選択します(図23-12)。

注意:

サンプル・クローラのインストールをお薦めします。クローラの詳細は、第23.1項「インストール手順」のステップ1の注意を参照してください。

図23-12 サンプル・クローラ構成

13. 設定のサマリーをレビューして、入力したデータを確認します(図23-13)。設定を編集するには、「前」をクリックして、関連する画面に戻ります。

図23-13 設定のサマリー

14. 設定を確認したら(図23-14)、「インストール」をクリックします。

図23-14 「インストールの進行状況」

インストール・プロセスが正常に終了すると(図23-15)、次のメッセージが表示されます。"Site Capture war file was successfully created"。

図23-15 サイト・キャプチャのインストールの成功

サイト・キャプチャ・ファイル・システムも作成されました。ROOT.warというwarファイルが、<SC_INSTALL_DIR/fw-site-capture/webappsフォルダに配置されています。サイト・キャプチャ・ファイル・システムの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の「サイト・キャプチャ・ファイル・システム」の章を参照してください。

15. 次のいずれかを実行します。

- WebCenter SitesをOracle Access Manager (OAM)とともに実行している場合は、OAMをサイト・キャプチャ・アプリケーションと統合します。手順は、『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』のroot-context.xmlファイルの調整に関する項を参照してください。

- WebCenter SitesをCASとともに実行している場合は、第23.1.3項「サイト・キャプチャのデプロイ」に進みます。

23.1.3 サイト・キャプチャのデプロイ

注意:

次の点を考慮してください。

- クラスタ化されたインストールの場合は、各クラスタ・メンバーで同じデプロイメント手順を完了します。

- サイト・キャプチャ・アプリケーションは、/のコンテキスト・ルートを持っている必要があります。

この項では、サイト・キャプチャのROOT.warファイルをデプロイする手順を説明します。手順は、次の項の1つを参照してください。

- 第23.1.3.1項「Tomcat Application Serverへのデプロイ」

- 第23.1.3.2項「WebLogic Application Serverへのデプロイ」

- 第23.1.3.3項「WebSphere Application Serverへのデプロイ」

23.1.3.1 Tomcat Application Serverへのデプロイ

1. <SC_INSTALL_DIR>\fw-site-capture\webapps\のROOTフォルダをコピーし、<apache-tomcat-6.0.29 directory>\webapps\ディレクトリのROOTフォルダを上書きします。

2. サイト・キャプチャを起動する手順は、次のとおりです。

1. WebCenter Sitesが実行されていることを確認します。

2. アプリケーション・サーバーを起動します(<apache-tomcat-6.0.29 directory>\binフォルダのstartup.batまたはstartup.shファイルを実行します)。

3. 第23.2項「インストール後の手順」に続きます。

23.1.3.2 WebLogic Application Serverへのデプロイ

1. 次のようにして、サイト・キャプチャのWEB-INF\libフォルダにあるantlr-2.7.7.jarおよびcommons-lang-2.5.jarというファイルをコピーします。
<SC_INSTALL_DIR>\fw-site_capture\webapps\ROOT\WEB-INF\lib

そして、それらを次のWebLogicインストール・パスに貼り付けます。

<Weblogic Home>\wlserver_10.3\common\lib

2. サイト・キャプチャ・ドメインのsetdomainEnv.cmdまたはsetdomainEnv.shファイル(<Weblogic Home>\user_projects\domains\<domain name>\binに配置されている)にプレクラス・パスを設定します。
変更を行う必要がある場所の例は、次のとおりです。

- Windowsの場合(setdomainEnv.cmd内):

set WL_HOME=E:\<WL HOME\Weblogic\wlserver_10.3
set PRE_CLASSPATH=%WL_HOME%\common\lib\antlr-2.7.7.jar;%WL_HOME
%\common\lib\commons-lang-2.5.jar(in windows machine)
for %%i in ("%WL_HOME%") do set WL_HOME=%%~fsi

- Linuxの場合(setdomainEnv.sh内):

WL_HOME="/root/Oracle/Middleware/wlserver_10.3"
PRE_CLASSPATH=$WL_HOME/common/lib/antlr-2.7.7.jar:
$WL_HOME/common/lib/commons-lang-2.5.jar
export WL_HOME

3. サイト・キャプチャ・アプリケーションをデプロイします。

1. コンソールのデプロイメント・セクションに移動し、<SC_INSTALL_DIR>\fw-site-capture\webappsにあるROOTフォルダのパスを選択します。

2. 管理対象サーバーをデプロイメント・ターゲットとして選択します。

4. サイト・キャプチャを起動する手順は、次のとおりです。

1. WebCenter Sitesが実行されていることを確認します。

2. 管理対象サーバー<managed_server_name>を起動します。たとえば、次のようにします。
./startmanagedweblogic.sh <managed_server_name>

http://<admin_server_hostname>:<admin_server_port>/

5. 「インストール後の手順」に続きます。

23.1.3.3 WebSphere Application Serverへのデプロイ

1. WebSphere管理インタフェースで、次のようにします。

1. パス「Application」→「Application Types」→「WebSphere enterprise applications」の順に移動し、<SC_INSTALL_DIR>\fw-site-capture\webapps\にあるROOT.warファイルを選択します。

2. WebSphereコンソールから、「Enterprise Applications」→「Site Capture Webapp」→「Class loader」(「Class loading and update detection」)に移動して、クラス・ロードのオプションを表示します。サイト・キャプチャでは、Warポリシー用のデフォルトの構成が必要です。「WAR class loader policy」セクションで「Class loader for each WAR file in application」オプションが選択されていることを確認します。

3. デプロイメント・プロセスを完了します。

2. サイト・キャプチャを起動する手順は、次のとおりです。

1. WebCenter Sitesが実行されていることを確認します。

2. アプリケーション・サーバーを起動します。

3. 第23.2項「インストール後の手順」に続きます。

23.2 インストール後の手順

サイト・キャプチャがインストールされてアプリケーション・サーバーが起動されると、サイト・キャプチャが起動し、それ自体をAdminSite上で有効化されたアプリケーションとして自動的に登録します。さらに、データベースがOracleでない場合は、サイト・キャプチャによって、必要な表およびレコードがそのデータベースに追加されます。

サイト・キャプチャのインストールを完了して検証するには、次の項の手順を完了します。

- 第23.2.1項「サイト・キャプチャがOracle Databaseを使用している場合」

- 第23.2.2項「customBeans.xmlファイルへのサイト・キャプチャURLの追加」

- 第23.2.3項「サイト・キャプチャ・アプリケーションの検証」

- 第23.2.4項「サイト・キャプチャを操作するユーザーの認可」

23.2.1 サイト・キャプチャがOracle Databaseを使用している場合

サイト・キャプチャがOracle Databaseを使用する場合は、スキーマを作成するsqlスクリプトを手動で実行する必要があります。<SC_INSTALL_DIR>/Sql-Scriptsフォルダにあるcrawler_oracle_db.sqlという名前のスクリプトを使用できます。

23.2.2 customBeans.xmlファイルへのサイト・キャプチャURLの追加

1. インストール内で、<Sites_Installation_Directory>/bin/customBeans.xmlに移動します。

2. customBeans.xmlファイルを開きます。

3. bean idセクションで、サイト・キャプチャURLを次のように追加します。

<bean id="RequestParamValidator"
class="com.fatwire.cas.web.RequestParamValidator">
<property name="validUrls">
<list>
<value>http://<Sites_Host_Name>:<Sites_Port>/<Sites_Context_root>/*</value>
<value>http://<Site Capture Hostname>:<SiteCapture_port>/__admin/*</value>
</list>
</property>
</bean>

4. WebCenter Sitesアプリケーション・サーバーおよびサイト・キャプチャ・サーバーを再起動します。

23.2.3 サイト・キャプチャ・アプリケーションの検証

サイト・キャプチャ・アプリケーションをWEM管理インタフェースで使用できることを確認します。

1. 一般管理者としてWebCenter Sitesにログインします。

2. AdminSiteに移動し、WEM管理アプリケーションを選択します。

3. メニュー・バーで、「アプリケーション」をクリックし、「アプリケーション」ページにサイト・キャプチャがリストされていることを確認します。

4. 図23-16に示すアイコンで表されたサイト・キャプチャ・アプリケーションに移動します。

図23-16 サイト・キャプチャ・アプリケーション・アイコン

ホーム・ページが開きます。サンプル・クローラのインストールを選択する場合、それらはホーム・ページにSampleおよびFirstSiteIIとしてリストされています(図23-17)。

図23-17 FirstSiteIIおよびSampleクローラ

23.2.4 サイト・キャプチャを操作するユーザーの認可

サイト・キャプチャ・アプリケーションは、WebCenter Sites一般管理者および一般管理者権限を持つ開発者向けに設計されています。そのようなユーザーはすべて、AdminSiteへのアクセス権を持ち、そこでサイト・キャプチャ・アプリケーションが登録され、実行されています。(アクセスは、AdminSite上のGeneralAdminロールおよびRestAdminセキュリティ・グループのユーザーのメンバーシップを介して付与されます。ユーザーの認証およびWEM管理インタフェースの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の「ユーザーの作成と認可」の章を参照してください。

サイト・キャプチャ・ユーザーは、特に、静的にキャプチャされたサイトおよびクローラのログを取得するために、そのホスト・マシンへの管理アクセス権限も必要です。

23.3 次のステップ

- パブリッシュによってトリガーされるサイト・キャプチャをセットアップする場合は、第24章「パブリッシュによってトリガーされるサイト・キャプチャの有効化」を参照してください。

- サイト・キャプチャの使用を開始するには、インタフェースのナビゲーションおよびクローラ構成コードの記述の詳細について『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

24 パブリッシュによってトリガーされるサイト・キャプチャの有効化

サイト・キャプチャ・アプリケーションをインストールした後、パブリッシュによってトリガーされるサイト・キャプチャを有効化することを選択できます。

この章では、次の項目について説明します。

- 第24.1項「サイト・キャプチャとOracle WebCenter Sitesのパブリッシュ・プロセスとの統合」

- 第24.2項「次のステップ」

24.1 サイト・キャプチャとOracle WebCenter Sitesのパブリッシュ・プロセスとの統合

サイト・キャプチャを、RealTimeパブリッシュ・セッションの完了によってトリガーできます。パブリッシュによってトリガーされるサイト・キャプチャを有効化する場合は、サイト・キャプチャ・アプリケーションをインストールした後にこの項の手順を完了します(第23章「サイト・キャプチャのインストール手順」)。この手順は、サイト・キャプチャ・アプリケーションをWebCenter Sitesパブリッシュ・システムと統合し、それとサイト・キャプチャとの通信を可能にする方法を示しています。可能なシステム構成のいくつかについては、図21-2「パブリッシュによってトリガーされるサイト・キャプチャが可能な単一サーバー・インストール」および図21-3「パブリッシュによってトリガーされるサイト・キャプチャが可能なクラスタ化されたインストール」を参照してください。

サイト・キャプチャとWebCenter Sitesのパブリッシュ・プロセスを統合する手順は、次のとおりです。

1. WebCenter Sitesソース・システム上で、次のようにします。

1. fw-crawler-publish-listener-1.0.jarファイルを<cs_deploy>/WEB-INF/libフォルダにデプロイします。

2. fw-crawler-publish-listener-1.0-elements.zipファイルを解凍し、CatalogMoverを使用してFW_PublishingEventRegistry.htmlをインポートします。

この手順によって、WebCenter SitesデータベースのFW_PublishingEventRegistry表にRemoteElementInvokingPublishingEventListenerレコードが作成され、これにより、パブリッシュ・イベントがWebCenter Sitesターゲット・システム上のInvokeCrawlerエレメントを呼び出せるようになります。

3. WebCenter Sitesソース・システムを再起動します。

2. WebCenter Sitesターゲット・システム上で、次のようにします。

1. CatalogMoverを使用して、ElementCatalog.htmlおよびSiteCatalog.htmlを、前述のステップ1bで抽出した(WebCenter Sitesソース・システム上の)解凍済fw-crawler-publish-listener-1.0-elements.zipファイルからインポートします。
このステップによってInvokeCrawler.jspがインポートされます。これはサイト・キャプチャ・アプリケーションのクローラの起動に使用されます。

注意:

クローラは、サイト・キャプチャのパブリッシュの宛先定義内およびサイト・キャプチャ・アプリケーション内で定義する必要があります。詳細は、第24.2項「次のステップ」を参照してください。

2. crawler.propertiesファイル(/<cs_deploy>/WEB-INF/classesフォルダ内)をコピーし、次に示すプロパティを構成します。

- sc.url: 次のいずれかを実行します。
単一サーバー・インストールの場合、次のサイト・キャプチャ・アプリケーションのURLを指定します。

sc.url=http://<sitecapturehost:sitecaptureport>/__admin

クラスタ化されたインストールの場合、次のロード・バランサのURLを指定します。

sc.url=http://<loadbalancerhost:loadbalancer>/__admin

- cas.url=http://<cashost:casport>/cas
サイト・キャプチャ・アプリケーションが指し示すCASアプリケーションを指定します。

- cs.username=<RestAdmin User>
WebCenter Sites一般管理者のユーザー名を、サイト・キャプチャのインストール・プロセス中に指定したとおりに指定します。

- cs.password=<Password>
前述のユーザーのパスワードを、サイト・キャプチャのインストール・プロセス中に指定したとおりに指定します。

3. fw-crawler-publish-listener-1.1.jarファイルを、ターゲットWebCenter Sitesシステムの<cs_deploy>/WEB-INF/libフォルダにデプロイします。

3. 統合プロセスが完了しました。パブリッシュによってトリガーされるサイト・キャプチャ操作の設定のサマリーに関する第24.2項「次のステップ」に進みます。

24.2 次のステップ

この時点で、サイト・キャプチャとWebCenter Sites RealTimeパブリッシュ・プロセスとの統合が完了しました。ただし、パブリッシュによってトリガーされるサイト・キャプチャが機能するには、次の条件も満たす必要があります。

- RealTimeパブリッシュの宛先定義が、ソース・システムで構成され、新しくパブリッシュされたサイトをキャプチャするために起動されるクローラを指定する必要があります。この定義では、クローラのキャプチャ・モードも指定する必要があります。

- 前述の手順で指定したクローラは、サイト・キャプチャ・アプリケーション内に存在している必要があります。さらに、各クローラのCrawlerConfigurator.groovyファイルで、クローラに対して少なくとも1つの有効な起動URIおよびリンク抽出ロジックが指定されている必要があります。

注意:

前述の構成手順が完了したら、ソースWebCenter SitesシステムからターゲットWebCenter Sitesシステムにサイトをパブリッシュします。パブリッシュが終了すると、サイト・キャプチャが起動し、次のように続行されます。

1. ソースWebCenter Sitesシステムによって、ターゲット・システム上のInvokeCrawlerエレメントが呼び出されます。

2. ターゲットWebCenter Sitesシステムは、サイト・キャプチャ・アプリケーションと通信し、クローラを起動します。

3. WebCenter Sitesターゲット・システムは、クローラの起動ステータスを、WebCenter Sitesソース・システムに通信します。ソースとターゲットの両方のシステムによって、それら自体のログ・ファイル(デフォルトではfuturetense.txt)にステータス情報が記録されます。

同時に、起動されたクローラは、パブリッシュの宛先定義の設定に応じて、静的とアーカイブ・モードのいずれかでサイト・リソースをキャプチャします。

パブリッシュによってトリガーされるサイト・キャプチャを設定する場合、必要な数のパブリッシュの宛先定義を構成し、必要な数のクローラを起動できます。前述の構成手順に進む準備ができたら、手順について『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。同じガイドに、サイト・キャプチャ・インタフェースのナビゲーション、サイト・キャプチャ操作のセットアップ、およびサイト・キャプチャ・プロセスを制御するためのクローラの構成ファイルのコーディングに関する情報も記載されています。

第VII部

Oracle WebCenter Sites: Analyticsのインストール

AnalyticsはWebCenter Sitesに接続し、サイト・トラフィック情報の包括的コレクションを、カスタマイズ可能なレポートの形式でユーザーに提供します。この部では、Oracle WebCenter Sites: Analyticsをインストールおよび構成し、Oracle WebCenter Sitesによって動作しているWebサイト上のトラフィックを監視し、Oracle WebCenter Sites(そのEngageアプリケーションも含む)で作成されたコンテンツとビジターの相互作用を分析する手順について説明します。

注意:

この部で説明する概要および手順は、Oracle WebCenter Sites: Analyticsバージョン11.1.1.6.0向けです。

第VII部は、次の章で構成されています。

- 第25章「Analyticsアーキテクチャの概要」

- 第26章「Analyticsをインストールするための前提条件」

- 第27章「Analyticsのインストール手順」

- 第28章「Analytics構成パラメータの調整」

- 第29章「ビジター検出の構成」

- 第30章「Analyticsインストールの検証」

25 Analyticsアーキテクチャの概要

この章では、Analyticsスイートを構成するコンポーネントの概要を示し、Analyticsをインストールする場合に実装を選択できるシナリオについて説明します。

この章の内容は、次のとおりです。

- 第25.1項「Analyticsインストールのコンポーネント」

- 第25.2項「インストールのシナリオ」

- 第25.3項「プロセス・フロー」

- 第25.4項「用語と定義」

25.1 Analyticsインストールのコンポーネント

Analyticsは、高度なスケーラビリティを可能にするモジュラー・システムです。Analyticsインストールは、次のコンポーネントで構成されており、データベースにアクセスするためのJDBC、HTTP接続、RMIおよび固有のSocketプロトコルを介して相互に通信します。

- Hadoop

- WebCenter Sites: Analytics

- ロード・バランサ

Hadoop

Hadoopは、分散データ・ストレージ(HDFS)および分散データ処理(Map/Reduce)を提供します。Hadoop分散ファイル・システム (HDFS)では、Hadoopクラスタ全体にわたる分散方式でHadoopプログラムの入力ファイルおよび出力ファイルが格納され、高速な集約された帯域幅が提供されます。

WebCenter Sites: Analytics

- Analyticsデータ取得アプリケーション(Analytics Sensorとも呼ぶ): 自身のオンライン・サイトをビジターが閲覧する際の彼らのアクティビティに関するデータを取得し、そのデータをローカル・ファイル・システムに格納するWebアプリケーション。(データ取得を機能させるには、特別なタグであるAddAnalyticsImgTagを、監視対象のページに埋め込む必要があります。そのタグによって、データ取得プロセスがトリガーされます。)

- Hadoop分散ファイル・システム(HDFS)エージェントは、データ取得サーバーによって収集されたRAWデータを取得し、それをローカル・ファイル・システムからHDFSにコピーします。

- Hadoopジョブ(スケジューラ)は、HDFSに格納されているRAWデータに対する統計を効率的に計算するために、並列かつ分散形式でジョブを実行します。
HadoopによってMap/Reduceという計算パラダイムが実装されます。それによって、大規模な計算が小さい作業フラグメントに分割され、それらをそれぞれクラスタ上の任意のノードで実行または再実行できます。Map/Reduceには、jarファイルとクラスの組合せが必要であり、それらはすべて、通常jobファイルと呼ばれる1つのjarファイルに収集されています。ジョブを実行するには、それをJobTrackerに送信します。Hadoopジョブは、次のアクションを実行することで反応します。

- ジョブをスケジュールし、JobTrackerに送信します。

- データ取得サーバーによって取得されたRAWデータを処理して統計データにし、それをAnalyticsデータベースに書き込みます。

Hadoopは、HDFSを参照し、ジョブのステータスを判別するためのWebインタフェースを備えています。

- Analyticsデータベース: データ取得サーバーによって取得されたRAWデータに対する集計および統計データが格納されます。

- Analyticsレポート作成および管理Webアプリケーション

- このレポート作成コンポーネントは、レポートの生成に使用されるユーザー・インタフェースを提供します。

- 管理コンポーネントは、ご使用のWebCenter SitesシステムとAnalyticsを統合するために使用される管理インタフェースを提供します。

通常、レポート作成コンポーネントと管理コンポーネントは、同じコンピュータ上に常駐します。

ロード・バランサ

ロード・バランサは、パフォーマンスの向上のために、複数のデータ取得サーバーとリンクするために使用されます。フェイルオーバーのために、ロード・バランシングもお薦めします。

ご使用のWebCenter SitesおよびAnalyticsシステムを侵入から保護するために、ファイアウォールも強くお薦めします。Analyticsのモジュラー特質によって、Analyticsはいくつかの方法でインストールできます。第25.2項「インストールのシナリオ」では、一般的な方法について説明します。

25.2 インストールのシナリオ

この項では、サイトにAnalyticsを実装する場合に選択できる様々なインストール・シナリオについて説明します。シナリオは次のとおりです。

- 第25.2.1項「単一サーバーのインストール: 単一サーバー上にAnalyticsとそのデータベース」

- 第25.2.2項「デュアルサーバーのインストール: 別々のサーバー上にAnalyticsとそのデータベース」

- 第25.2.3項「エンタープライズレベルのインストール: 完全に分散」

25.2.1 単一サーバーのインストール: 単一サーバー上にAnalyticsとそのデータベース

このシナリオでは、すべてのAnalyticsコンポーネントが、単一の専用コンピュータ上に配置されます。このシナリオは、Analyticsでテストおよび試験を実行する必要がある場合に最適です。図25-1は、単一サーバーのAnalyticsのインストールを示しており、どこに構成ファイルが配置され、サービスが実行されるのかを示しています。矢印はデータ・フローを表しています。

図25-1 単一サーバーのAnalyticsのインストール

25.2.2 デュアルサーバーのインストール: 別々のサーバー上にAnalyticsとそのデータベース

このシナリオでは、Analyticsデータベース以外のAnalyticsコンポーネントが単一の専用サーバーでホストされます。Analyticsデータベースはそれ自体のサーバーにインストールされます。このシナリオは、向上したパフォーマンス条件の下でAnalyticsでのテストおよび試験を実行する必要がある場合に最適です(データベース・トランザクションをHadoopジョブから切り離すことで、リソースに対する競合が最小化されます)。図25-2は、デュアルサーバーのAnalyticsのインストールを示しており、どこに構成ファイルが配置され、サービスが実行されるのかを示しています。矢印はデータ・フローを表しています。

図25-2 デュアルサーバーのAnalyticsのインストール

25.2.3 エンタープライズレベルのインストール: 完全に分散

このシナリオでは、Analyticsコンポーネントは、別々のコンピュータ上で実行されます。この方法は、より複雑ですが、各コンポーネントは自由に使用できる専用の処理能力を確保できるため、スケーラビリティが得られ、パフォーマンスが向上します。図25-3は、エンタープライズレベルのインストールを示しており、どこに構成ファイルが配置され、サービスが実行されるのかを示しています。矢印はデータ・フローを表しています。リモートSatellite ServerとともにAnalyticsをインストールする場合の詳細は、 図25-3の注意を参照してください。

図25-3 エンタープライズレベルのAnalyticsのインストール

25.3 プロセス・フロー

機能しているAnalyticsインストールでは、RAWサイト・ビジター・データは、Analytics Sensor (データ取得アプリケーション)によって継続的に取得され、ローカル・ファイル・システムに格納されます。ファイル・システム内のRAWデータは、HDFSエージェントによって定期的に呼び出されます。HDFSエージェントは、RAWデータをHadoop分散ファイル・システム(HDFS)にコピーし、そこでそのデータがHadoopジョブによって処理されます(図25-4)。

Hadoopジョブは、場所とOracle固有のプロセッサ(1つの場所のサイト・ビジター・データを読み取り、そのデータを統計的に処理し、その結果を、次のプロセッサが取得できるように別の場所に書き込む)で構成されています。処理が完了すると、結果(RAWデータ上の統計)がAnalyticsデータベースに注入されます。

Hadoopジョブのステータスは、Analytics管理インタフェースの「ステータス・サマリー」パネルから監視できます。データ処理および「ステータス・サマリー」パネルの詳細は、『Oracle Fusion Middleware WebCenter Sites: Analytics管理者ガイド』の「リファレンス: Hadoopジョブのプロセッサと場所」の章に記載されています。

図25-4 Hadoopジョブのプロセス・フロー

25.4 用語と定義

次にリストする用語は、このガイド全体でよく使用されます。用語集には、追加の用語が定義されています。

- 「Analyticsデータ取得アプリケーション」は、Analytics Sensorまたは単にセンサーとも呼ばれます。

- インストールおよび構成手順のコンテキストおよびレポート統計の解釈における用語「サイト」は、オンライン・サイトのバック・エンドとして機能するコンテンツ管理(CM)サイトを指します。

- 「FirstSite II」は、サンプル・コンテンツ管理サイトであり、このガイド全体にわたって、レポートの例のサポートおよびコード・スニペットの提供のために使用されます。FirstSite IIは、etravelという名前のオンライン・サンプル・サイトのバック・エンドでもあります。

26 Analyticsをインストールするための前提条件

この章では、Analyticsをインストールおよび構成してWebCenter Sites Webアプリケーション上で実行するための前提条件を説明します。

この章の内容は、次のとおりです。

- 第26.1項「インストール前のチェックリスト」

- 第26.2項「次の手順」

26.1 インストール前のチェックリスト

Analyticsをインストールするには、サイレント・インストーラ(Javaベース・スクリプト)を実行します。サイレント・インストーラを実行する前に、Analyticsをサポートするすべてのコンポーネントの可用性および構成を確認します。

- 第26.1.1項「必要な経験」

- 第26.1.2項「システム・アーキテクチャ」

- 第26.1.3項「WebCenter Sites: Analyticsキット」

- 第26.1.4項「Hadoopのインストール」

- 第26.1.5項「WebCenter Sitesおよびサポート・ドキュメント」

- 第26.1.6項「WebCenter Sites: Analyticsサイレント・インストーラ」

- 第26.1.7項「WebCenter Sites: Analyticsサポート・ソフトウェア」

- 第26.1.8項「環境変数」

- 第26.1.9項「チャートのサポート」

26.1.1 必要な経験

Analyticsをインストールするには、エンタープライズレベルのソフトウェア(アプリケーション・サーバーやデータベースなど)のインストールおよび構成と、システム運用パラメータの設定の経験が必要です。

26.1.2 システム・アーキテクチャ

- 第25章「Analyticsアーキテクチャの概要」をお読みになり、Analytics製品のアーキテクチャおよびサポートされているインストール・オプションを確認してください。

- リリース・ノートおよびOracle WebCenter Sites動作保証マトリックスをお読みになり、Analyticsをサポートするサード・パーティ・ソフトウェアの動作保証されているバージョンを使用していることを確認します。

26.1.3 WebCenter Sites: Analyticsキット

ライセンスを付与されているAnalyticsキット(analytics2.5.zip)を所有していることを確認します。このキットは図26-1に示すように構成されています。

図26-1 Analyticsキットのディレクトリ構造

このキットには、Analyticsサイレント・インストーラ・ファイル、サポート・サード・パーティ・ソフトウェアおよびAnalyticsスイートが含まれています。Analyticsスイートは、次のアプリケーションで構成されています。

- Analyticsデータ取得Webアプリケーション(センサーとも呼ぶ)

- Analytics管理者Webアプリケーション

- Analyticsレポート作成Webアプリケーション(レポート作成エンジンおよびインタフェース)

- Hadoop分散ファイル・システム(HDFS)エージェント

- Hadoopジョブ(スケジューラ)

26.1.4 Hadoopのインストール

注意:

Analyticsキットの3rdparty-toolsフォルダに、Hadoopバイナリが格納されています。このHadoopバイナリを使用して、Hadoopをインストールします(Hadoop Webサイトで使用可能なファイルはしません)。

1. この項では、ローカル、疑似分散または完全な分散(推奨)のうち、開発、スケーラビリティおよびパフォーマンスの要件に最も適したモードでHadoopをインストールおよび構成します。これらのモードの説明は、次のとおりです。

- ローカル(スタンドアロン)モードは、開発およびデバッグ用に使用されます。デフォルトでは、Hadoopは、単一Javaプロセスとして非分散モードで実行するように構成されています。

- 疑似分散モードは、単一サーバーインストールで使用されます。このモードでは、すべてのHadoopサービス(たとえば、NameNode、JobTracker、DataNodeおよびTaskTracker)は、単一ノード上で実行され、各サービスは個別のJavaプロセスとして実行されます。

- 完全な分散モードは、エンタープライズレベルのインストールに使用されます。このモードでは、Hadoopは、並列かつ分散方式で複数のノードで実行されます。Hadoopのセットアップには、少なくとも2つのノードが必要です。1つのマシンはマスター・ノードとして機能し、残りのマシンはスレーブ・ノードとして機能します。マスター・ノード上では、NameNodeおよびJobTrackerサービスが実行されます。スレーブ・ノード上では、DataNodeおよびTaskTrackerサービスが実行されます。

2. Hadoopのインストール手順は、「Hadoop Quick Start」サイトを参照してください。そのURLは、その執筆時点では次のとおりです。
http://hadoop.apache.org/docs/r0.18.3/quickstart.pdf

疑似または完全な分散のいずれかのモードでHadoopをインストールする場合は、マスターおよびスレーブのすべてのコンピュータでhadoop-site.xmlというプロパティ・ファイルを構成する必要があります。推奨されるプロパティ値およびサンプル・ファイルは、この項に記載します。

hadoop-site.xmlを構成する手順は、次のとおりです。

1. 表26-1に示すようにhadoop-site.xmlファイルを構成します。構成済ファイルは、サンプルhadoop-site.xmlファイルに類似したものになります。

2. 完全な分散モードでインストールする場合は、マスターおよびスレーブのすべてのコンピュータに構成済hadoop-site.xmlをコピーする必要があります。

表26-1 hadoop-site.xmlのプロパティ

プロパティ

説明

サンプル値

fs.default.name

デフォルト・ファイル・システムの名前。スキームおよび認可によってFileSystemの実装が判別されるURI。

URIのスキームによって、FileSystem実装クラスを指定する構成プロパティ(fs.SCHEME.impl)が判別されます。

URIの権限は、ファイル・システムのホスト、ポートなどの判別に使用されます。

hdfs://<ipaddress>:<port1>

説明:

<ipaddress>は、マスター・ノードのIPアドレスです。

<port1>は、受信接続をリスニングするNameNodeのポートです。

例:

hdfs://192.0.2.1:9090

mapred.job.tracker

MapReduceジョブ・トラッカが実行されているホストおよびポート。

このプロパティがlocalに設定されている場合、ジョブは、1つのmapおよびreduceタスクとしてインプロセスで実行されます。

<ipaddress>:<port2>
local

例:

192.0.2.1:7070

注意: 完全な分散モードでは、マスター・ノードのIPアドレスを入力します。

dfs.replication

デフォルトのブロック複製。HDFSに作成されているファイルの複製の数。

この値は、クラスタ内のDataNodesの数と同一である必要があります。デフォルトは、dfs.replicationが設定されていない場合に使用されます。

<equal to the number of data nodes>

dfs.permissions

HDFSにおける権限チェックを有効化または無効化します。

- trueにすると、HDFSにおける権限チェックが有効化されます。

- falseにすると、権限チェックは無効化されますが、他のすべての動作は変更されません。

一方の値から他方の値に切り替えても、ファイルまたはディレクトリのモード、所有者またはグループが変更されることはありません。

true | false

hadoop.tmp.dir

ローカル・ファイル・システム上のHadoopファイル・システムの場所。

/work/hadoop/hadoop-0.18.2/tmp/hadoop-${user.name}

mapred.child.java.opts

TaskTracker子プロセス用のJavaオプション。

次のパラメータは、存在する場合に補間されます。@taskid@が現在のTaskIDに置換されます。@の他のオカレンスは変更されません。

例:

/tmpのtaskidに指定されたファイルに対する冗長gcロギングを有効化し、ヒープの最大値を1GBに設定するには、次の値を渡します。

-Xmx1024m -verbose:gc
-Xloggc:/tmp/@taskid@.gc

構成変数mapred.child.ulimitを使用すると、子プロセスの最大仮想メモリーを制御できます。

-Xmx1024m

mapred.tasktracker.
expiry.interval

TaskTrackerがハートビートを送信しない場合に「切断」と宣言されるまでの時間間隔(ミリ秒単位)。

60000000

mapred.task.timeout

入力の読取り、出力の書込み、そのステータス文字列の更新のいずれも実行していない場合に、タスクが終了するまでのミリ秒数。

60000000

mapred.map.tasks

ジョブ当たりのmapタスクのデフォルト数。通常、使用可能なホスト数より数倍大きい値に近い素数に設定します。mapred.job.trackerでローカルIPアドレスが指定されている場合は無視されます。

11

mapred.reduce.tasks

ジョブ当たりのreduceタスクのデフォルト数。通常、使用可能ホスト数に近い素数に設定します。mapred.job.trackerでローカルIPアドレスが指定されている場合は無視されます。

7

mapred.tasktracker
.map.tasks.maximum

TaskTrackerによって同時に実行されるmapタスクの最大数。

次の数値を指定します

mapred.map.tasksの値を超える

mapred.map.tasksの値を超える整数

mapred.tasktracker
.reduce.tasks.maximum

TaskTrackerによって同時に実行されるreduceタスクの最大数。

次の数値を指定します

mapred.reduce.tasksの値を超える

mapred.reduce.tasksの値を超える整数

サンプルhadoop-site.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- Put site-specific property overrides in this file. -->

<configuration>

<property>
<name>fs.default.name</name>
<value>hdfs://192.0.2.1:9090</value>
<description>The name of the default file system.A URI whose
scheme and authority determine the FileSystem implementation. The
uri's scheme determines the config property (fs.SCHEME.impl) naming
the FileSystem implementation class.The uri's authority is used to
determine the host, port, etc. for a filesystem.</description>
</property>

<property>
<name>mapred.job.tracker</name>
<value>192.0.2.1:7090</value>
<description>The host and port that the MapReduce job tracker runs
at.If "local", then jobs are run in-process as a single map
and reduce task.
</description>
</property>

<property>
<name>dfs.replication</name>
<value>1</value>
<description>Default block replication.
The actual number of replications can be specified when the file is created.
The default is used if replication is not specified in create time.
</description>
</property>

<property>
<name>dfs.permissions</name>
<value>false</value>
<description>
If "true", enable permission checking in HDFS.
If "false", permission checking is turned off,
but all other behavior is unchanged.
Switching from one parameter value to the other does not change the
mode,owner or group of files or directories.
</description>
</property>

<property>
<name>hadoop.tmp.dir</name>
<value/work/hadoop/hadoop-0.18.2/tmp/hadoop-${user.name}</value>
<description>A base for other temporary directories.</description>
</property>

<property>
<name>mapred.child.java.opts</name>
<value>-Xmx200m</value>
<description>Java opts for the task tracker child processes.
The following symbol, if present, will be interpolated: @taskid@ is
replaced  by current TaskID. Any other occurrences of '@' will go
unchanged.

For example, to enable verbose gc logging to a file named for the
taskid in  /tmp and to set the heap maximum to be a gigabyte, pass a
'value' of: -Xmx1024m -verbose:gc -Xloggc:/tmp/@taskid@.gc
The configuration variable mapred.child.ulimit can be used to control
the maximum virtual memory of the child processes.
</description>
</property>

<property>
<name>mapred.tasktracker.expiry.interval</name>
<value>600000</value>
<description>Expert: The time-interval, in miliseconds, after which
a tasktracker is declared 'lost' if it doesn't send heartbeats.
</description>
</property>

<property>
<name>mapred.task.timeout</name>
<value>600000</value>
<description>The number of milliseconds before a task will be
terminated if it neither reads an input, writes an output, nor
updates its status string.
</description>
</property>

<property>
<name>mapred.map.tasks</name>
<value>2</value>
<description>The default number of map tasks per job.Typically set
to a prime several times greater than number of available hosts.
Ignored when mapred.job.tracker is "local".
</description>
</property>

<property>
<name>mapred.reduce.tasks</name>
<value>1</value>
<description>The default number of reduce tasks per job.Typically
set to a prime close to the number of available hosts.Ignored
when mapred.job.tracker is "local".
</description>
</property>

<property>
<name>mapred.tasktracker.map.tasks.maximum</name>
<value>2</value>
<description>The maximum number of map tasks that will be run
simultaneously by a task tracker.
</description>
</property>

<property>
<name>mapred.tasktracker.reduce.tasks.maximum</name>
<value>2</value>
<description>The maximum number of reduce tasks that will be run
simultaneously by a task tracker.
</description>
</property>

</configuration>

3. Hadoopをインストールおよび構成したら、Hadoopクラスタを検証します。

1. 分散ファイル・システムが、複数のマシンにわたって実行されているかどうかを判別するには、次のようにしてマスター・ノード上でHadoop HDFSインタフェースを開きます。

http://<hostname_MasterNode>:50070/

HDFSインタフェースは、合計および残りの容量、アクティブ・ノード、停止ノードなどクラスタのステータスのサマリーを提供します。さらに、それを使用してHDFSネームスペースを参照し、Webブラウザでそのファイルの内容を表示できます。また、ローカル・マシンのHadoopログ・ファイルへのアクセスも提供します。

2. 次のように、Hadoopに同梱されていてマスター・ノード上で実行されているMapReduce監視Webアプリケーションを使用してMapReduceセットアップを表示します。

http://<hostname_MasterNode>:50030/

26.1.5 WebCenter Sitesおよびサポート・ドキュメント

- ライセンスを付与されたバージョンのWebCenter Sites Webアプリケーションを使用しており、それによって完全に機能しているオンライン・サイトが稼働していることを確認します。

- WebCenter Sitesドキュメントを手元に準備します。インストール・プロセスにおける各種ステップでは、サード・パーティのコンポーネントを作成および構成し、AnalyticsをWebCenter Sitesと統合する必要があります。次のガイドをダウンロードします。

- 『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』: WebCenter Sites環境用のOracle Databaseの作成および構成に関する手順が記載されています。

- 『Oracle Fusion Middleware WebCenter Sites管理者ガイド』: 統合プロセス中のロールの作成および割当てに関する手順が記載されています。

- 『Oracle Fusion Middleware WebCenter Sites開発者ガイド』: 統合プロセスでのCatalogMoverの使用に関する手順が記載されています。

26.1.6 WebCenter Sites: Analyticsサイレント・インストーラ

Analyticsサイレント・インストーラは、Antで開発されたJavaベースのスクリプトであり、Analyticsをインストールします。サイレント・インストーラは、Analyticsキットに同梱されています。

- 現在サポートされているバージョンのAnt (サイレント・インストーラに必要)が、サイレント・インストーラ自体を実行する予定の各サーバー上で実行されていることを確認します。

- このガイドで説明するインストール・シナリオをよく理解し、自身の運用に適したシナリオを選択してください。シナリオは次のとおりです。

- 単一サーバーのインストール: 図25-1

- デュアル・サーバーのインストール: 図25-2

- エンタープライズレベルのインストール: 図25-3

注意:

サイレント・インストーラのスクリプトでは、Analyticsがローカルに(それが実行されているコンピュータ上に)対話なしでインストールされます。サイレント・インスールには、インストール・フォルダの準備およびデータベースのセットアップから、Webアプリケーションおよびユーティリティ・プログラムのデプロイまでのすべての手順が含まれています。

26.1.7 WebCenter Sites: Analyticsサポート・ソフトウェア

- 第26.1.7.1項「データベース」

- 第26.1.7.2項「アプリケーション・サーバー」

26.1.7.1 データベース

- Oracleデータベース管理システム(DBMS)およびSQL Plusユーティリティをインストールします。Analyticsスキーマは、SQL PlusによってOracle Databaseにインストールされます。(インストール手順は、製品ベンダーのドキュメントを参照してください。)

- AnalyticsデータベースとしてOracle Databaseを作成および構成します。
WebCenter SitesインストールがOracle DBMS上で実行されている場合、そのサーバーに追加のデータベースをサポートする能力があるなら、その同じDBMSを使用してAnalyticsのデータベースを作成できます。領域の要件は、指定した時間枠内に取得すると予期されるサイト・トラフィック・データの量、取得済データに対して計算される統計の量、RAWデータおよび統計をすべてアーカイブする予定であるかどうかによって異なります。

Oracle Databaseの作成および構成の手順は、次のとおりです。

1. 『Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成』の手順に従ってください。

注意:

次の点を忘れないでください。

- グローバル名およびSIDを設定するときは、8文字を超える名前を作成しないでください。

- ユーザーを作成するときは、analyticsユーザーを作成します。

2. エンコーディングをUnicode (AL32UTF8)に設定します。次のコマンドの1つを使用して、環境変数nls_langをNLS_LANG=AMERICAN_AMERICA.AL32UTF8に変更します。

- Windowsでは、次のコマンドを入力します。

set NLS_LANG=AMERICAN_AMERICA.AL32UTF8

- Linuxでは、コマンドは、使用しているシェルに応じて異なります。
KornおよびBourneシェルの場合:

NLS_LANG=AMERICAN_AMERICA.AL32UTF8
export NLS_LANG

Cシェルの場合:

setenv NLS_LANG AMERICAN_AMERICA.AL32UTF8

26.1.7.2 アプリケーション・サーバー

- Analytics Webアプリケーション(つまり、データ取得、管理者アプリケーションおよびレポート作成アプリケーション)をホストするためのサポートされているアプリケーション・サーバーをインストールします。サポートされているアプリケーション・サーバーのリストは、Oracle WebCenter Sites動作保証マトリックスを参照してください。

注意:

単一サーバーのインストールでは、1つのアプリケーション・サーバーが必要です。

複数サーバーのインストールでは、その構成に応じて最大3つのアプリケーション・サーバー(たとえば、データ取得アプリケーション、管理者アプリケーションおよびレポート作成アプリケーションが別々のコンピュータにインストールされている場合は、3つのアプリケーション・サーバー)が必要です。

- 各アプリケーション・サーバーが、Analyticsデータベースと連動するJDBCドライバを提供することを確認します。(AnalyticsにはJDBCドライバは同梱されていません。)

26.1.7.2.1 すべてのアプリケーション・サーバー

- UTF-8の文字エンコーディング用に各アプリケーション・サーバーを構成します。

注意:

アプリケーション・サーバーのエンコーディング設定は、global.xmlのencodingパラメータの値に一致する必要があります。その値は、UTF-8です。

- Tomcatの場合:
ファイル$CATALINA_HOME/conf/server.xmlを編集し、URIEncoding属性をUTF-8に設定します。

<Connector port="8080" URIEncoding="UTF-8"/>

- WebSphereの場合:
アプリケーション・サーバーのJVM設定のシステム・プロパティdefault.client.encodingの値をUTF-8に設定します。

- Analyticsレポート作成(および管理者)サーバー上のアプリケーション・サーバーの場合は、JVMパラメータを次のように設定します。

-Djava.awt.headless=true

- アプリケーション・サーバー上のDNS参照を有効化します。自身のサイトにアクセスするビジターのマシンのホスト名をHostsレポートに表示するために、DNSサーバーはDNS参照を実行する必要があります。手順については、ご使用のアプリケーション・サーバーのドキュメントを参照してください。

注意:

DNS参照を実行するようにアプリケーション・サーバーが構成されていないと、Hostsレポートには、かわりに(IP Addressesレポートと同じように)IPアドレスが表示されます。

26.1.7.2.2 JBoss Application Server

次のように実行します。

- JBossによって使用されるlibフォルダから共通jarファイルを削除します(Analytics管理者アプリケーションが実行できるようにするため)。

26.1.7.2.3 WebLogicアプリケーション・サーバー

次のように実行します。

- Analyticsアプリケーションがログ・ファイルを作成できるようにするために、log4j jarファイルをWebLogicドメインのlibフォルダに追加します。

- アプリケーション・サーバーの起動コマンドのPRE_CLASSPATHにantlr.jarファイルを追加します。例:

C:/bea/wlserver_10.3/samples/domains/wl_server/bin/setDomainEnv.cmd

26.1.7.2.4 WebSphereを使用している場合

- Webアプリケーションのクラス・ローダーの順序にparentLastクラスを構成します。

26.1.8 環境変数

次のように実行します。

- JAVA_HOMEを、現在サポートされているJDKのパスに、PATH変数を$JAVA_HOME/binに設定します。これらの設定は、Hadoop (Hadoop-env.sh)、HDFSエージェント、およびHadoopジョブに必要です(そのようにしない場合、それらはすべて実行されません)。

注意:

Windowsでは、次のようにJAVA_HOMEをその正規の形式に設定します。

C:\PROGRA~1\<path_to_jdk>

そのようにしない場合、パスに空白が含まれていると(たとえば、C:\Program Files)、そのパスを二重引用符で囲む必要があります(たとえば、"C:\Program Files")。

- Solarisシステムでは、次の行をhadoop-env.shに追加します。

export PATH=$PATH:/usr/ucb

- ANT_HOME (サイレント・インストーラによって必要とされる)を現在のパスに設定します。

26.1.9 チャートのサポート

次のように実行します。

- Analyticsレポート内では、チャートのレンダリングにSwiff Chart Generatorが使用されます。Swiff Chart Generatorを、Analyticsホスト(単一サーバーのインストール)またはレポート作成サーバー(複数サーバーのインストール)のいずれかにインストールします。レポート作成サーバーはanalytics.warをホストします。
Swiff Chart Generatorのコピーは、次の場所から購入できます。

http://www.globfx.com/

評価版は、次の場所で入手できます。

http://www.globfx.com/downloads/swfchartgen/

- レポートを表示するコンピュータにAdobe Flash Playerをインストールします。Adobe Flash Playerの無料版は、次の場所で入手できます。

http://www.adobe.com/go/getflashplayer

Adobe Flash Playerをインストールしなくても、レポートは生成できます。ただし、それらにチャートが含まれていても、それらはdownload pluginリンクに置き換えられます。

26.2 次のステップ

サイレント・インストーラを使用して、Analyticsをインストールします。手順は、第27章「Analyticsのインストール手順」を参照してください。

27 Analyticsのインストール手順

この章では、スクリプトを使用してWebCenter Sites WebアプリケーションにAnalyticsをインストールする手順について説明します。

この章の内容は、次のとおりです。

- 第27.1項「Analyticsサイレント・インストーラの概要」

- 第27.2項「インストール手順」

- 第27.3項「次のステップ」

27.1 Analyticsサイレント・インストーラの概要

サイレント・インストーラは、Antで開発されたJavaベースのスクリプトです。このスクリプトでは、Analyticsがローカルに(それが実行されているコンピュータ上に)対話なしでインストールされます。

この章では、より一般的なインストール・シナリオについて説明します。それらを次に示します。

- 単一サーバー: 単一サーバーにAnalyticsおよびそのデータベースをインストールします(図25-1)

- デュアル・サーバー: 別々のサーバーにAnalyticsおよびそのデータベースをインストールします(図25-2)

- エンタープライズレベル: Analyticsは完全な分散モードになります(図25-3)

サイレント・インスールには、インストール・フォルダの準備およびデータベースのセットアップから、Webアプリケーションおよびユーティリティ・プログラムのデプロイまでのすべての手順が含まれています。この章の「インストール手順」から始まる残りの項では、サイレント・インストーラを実行するために完了する必要がある手順について説明します。次に概要を示します。

27.1.1 インストールの概要

簡単に言えば、前提条件(第26章「Analyticsをインストールするための前提条件」に示す)が満たされていることを確認した後、次のように実行してAnalyticsをインストールします。

1. Analyticsを解凍します。

1. マスター・ノード上でAnalyticsを解凍します。(分散インストールでは、SQL Plusをホストするサーバーなど、他の関連するノード上でAnalyticsを解凍します。)

注意:

次の点を考慮してください。

- サイレント・インストーラは、Analytics製品に同梱されています。

- サイレント・インストーラは、Analytics固有のスキーマでOracle Databaseを更新するためにSQL Plusホスト上で実行する必要があります。

2. WebCenter Sitesホスト上でAnalyticsを解凍します。

注意:

サイレント・インストーラは、WebCenter SitesをAnalyticsに対して初期化するためにWebCenter Sitesホスト上で実行する必要があります。WebCenter Sites futuretense_xcel.iniプロパティ・ファイルの場所を指定すると、サイレント・インストーラがAnalytics固有の設定でそれを変更できるようになり、初期化に役立ちます。

WebCenter Sitesを初期化すると、AddAnalyticsImgTagがサイト・ビジターに関するデータを取得できるようになります。AddAnalyticsImgTagの詳細は、『Oracle Fusion Middleware WebCenter Sites: Analytics開発者ガイド』の「様々なタイプのレポートに対するデータ取得の有効化」の章を参照してください。

2. Analytics向けにanalytics-build.propertiesファイルをカスタマイズします。Analytics製品を解凍したすべてのサーバー上でそのファイルをカスタマイズし、ご使用の環境にAnalytics製品を適切にデプロイするためにサイレント・インストーラが必要とする情報を宣言し、AnalyticsをWebCenter Sitesに対して(前述の注意で説明したように)初期化します。

3. 環境変数およびクラスパスを調べて、それらが適切に設定されていることを確認することで、インストーラを実行する準備をします。

4. Analytics製品を解凍したすべてのサーバー上でサイレント・インストーラを実行することで、Analyticsをインストールおよびデプロイします。

5. Analyticsを有効化するようにWebCenter Sitesを構成します。この手順では、WebCenter Sitesホスト上のanalytics-build.propertiesファイルをカスタマイズします。

27.1.2 サイレント・インストーラのアクション

サイレント・インストーラの実行を開始すると、それによって次の手順が実行されます。

1. インストールされるコンポーネントをすべて格納し、使用できるようにするためのAnalytics製品フォルダを準備します。

2. Analytics/Hadoopジョブ・スケジューリング・システム用の別のサブディレクトリを準備します。

3. sensor.war Webアプリケーションによって必要とされるhdfsagentユーティリティ用の別のサブディレクトリをセットアップおよび準備します。

4. analytics-build.propertiesファイルに指定した値を使用して、各種構成ファイルをカスタマイズします(第28章「Analytics構成パラメータの調整」に示す)。

- global.xml-distの名前をglobal.xmlに変更し、それのプロパティを、analytics-build.propertiesで指定した値に設定します。

- log4j.properties-distの名前をlog4j.propertiesに変更し、それのプロパティを、analytics-build.propertiesで指定した値に設定します。

- futuretense_xcel.ini (WebCenter Sitesプロパティ・ファイルの1つ)のプロパティをカスタマイズします。

5. SQL Plusを使用し、create_sys.sql、create_normal.sqlおよびregion.sql.のスクリプトを実行することで、Oracle DatabaseをAnalyticsデータベース・スキーマで更新します。

6. reports.zipアーカイブを解凍し、それらのファイルを、レポート作成エンジンによって参照される(ローカル・ファイル・システム上の)サブディレクトリに配置します。

7. Analytics Webアプリケーション(sensor.war、analytics.warおよびanalyticsadmin.war)が、指定されたアプリケーション・サーバーに自動的にデプロイされます。

8. WebCenter Sitesホスト上のサイレント・インストーラによって、WebCenter Sitesシステムが更新され、Analyticsがインストールされていることをそれが判別できるようになります。この更新によって、WebCenter Sites管理インタフェースの左上隅に表示される「分析」リンクが有効化されます。

27.2 インストール手順

注意:

この項の手順を開始する前に、第26章「Analyticsをインストールするための前提条件」に記載されているすべての前提条件が満たされていることを確認します。

Analyticsをインストールする手順は次のとおりです。

ステップ1. Analyticsを解凍する

ステップ2. Analytics用にanalytics-build.propertiesをカスタマイズする

ステップ3. サイレント・インストーラの実行を準備する

ステップ4. Analyticsをインストールする

ステップ5. Analyticsを有効化するようにWebCenter Sitesを構成する

27.2.1 ステップ1. Analyticsを解凍する

Analytics製品analytics2.5.zipには、サイレント・インストーラが含まれています。

Analyticsを解凍する手順は次のとおりです。

1. 作成予定のインストールタイプに応じて、次のいずれかの操作を行います。

- 単一サーバーのインストール(図25-1)。このシナリオでは、Analyticsをそれ自体のサーバー(すべてのAnalyticsサポートソフトウェアがホストされている)にインストールします。サーバー上でanalytics2.5.zipを解凍します。

- デュアル・サーバーのインストール(図25-2)。このシナリオでは、Analyticsおよびそのデータベースをそれら自体のサーバーにインストールします。

- Analyticsサーバー上でanalytics2.5.zipを解凍します。

- データベース・サーバーのホストにSQL Plusがインストールされている場合は、データベース・サーバーのホスト上でanalytics2.5.zipを解凍します。(SQL PlusとOracle Database間の通信を有効化するには、サイレント・インストーラを、SQL Plusをホストするサーバー上で実行する必要があります。)

- エンタープライズレベルのインストール(図25-3)。このシナリオでは、完全な分散モードでAnalyticsをインストールします。マスター・ノードおよびAnalyticsコンポーネントをインストールする残りの各サーバー上でanalytics2.5.zipを解凍します。
たとえば、自身のロード・バランシング・スキームで、複数のAnalytics Sensor(データ取得アプリケーション)を、異なるデータ取得ノードにデプロイする必要がある場合は、それらのデータ取得ノードすべてでanalytics2.5.zipを解凍します。

注意:

SQL PlusによってOracle DatabaseをAnalytics固有のスキーマで更新できるようにするには、analytics2.5.zipがSQL Plusをホストするサーバー上で解凍されていることを確認します。

1. WebCenter Sitesホスト上でanalytics2.5.zipを解凍します。

2. 「ステップ2. Analytics用にanalytics-build.propertiesをカスタマイズする」に続きます。

27.2.2 ステップ2. Analytics用にanalytics-build.propertiesをカスタマイズする

analytics-build.propertiesプロパティ・ファイルには、Analyticsサイレント・インストーラが必要とする環境固有の構成データがすべて含まれています。この手順では、サイレント・インストーラにインストールの仕様を提供するために、analytics-build.propertiesをカスタマイズします。(analytics-build.propertiesファイルは、複数のセクションに分かれています。各セクションは、自身の使用に応じてシステムを調整するために必要な特定の情報に固有です。)

Analytics(またはそのコンポーネント)をインストール予定の各サーバー上で次の手順を完了します。

Analytics用にanalytics-build.propertiesをカスタマイズする手順は、次のとおりです。

1. analytics-build.properties (Analyticsキットのルートに配置されている)をバックアップします。

2. 任意のテキスト・エディタでanalytics-build.propertiesを開き、次の項に示すようにプロパティを設定します。

- 第27.2.2.1項「全般的なインストール・プロパティ」

- 第27.2.2.2項「ビジター検出プロパティ」

- 第27.2.2.3項「システム構成および処理のデフォルト」

- 第27.2.2.4項「WebサーバーURLプロパティ」

- 第27.2.2.5項「アプリケーション・サーバー・デプロイメント・プロパティ」

- 第27.2.2.6項「データベース接続プロパティ」

- 第27.2.2.7項「Hadoopプロパティ」

注意:

Windowsのみ。インストール・ディレクトリのパスを指定する場合、それに空白が含まれているときは、そのパスを必ず二重引用符で囲んでください。

27.2.2.1 全般的なインストール・プロパティ

このグループのプロパティは、インストール・プロセスの全般的な性質の情報を提供します。この項では、Analyticsディレクトリのパス、サード・パーティのコンポーネントの場所、パスワードのリセットおよびアカウントの作成を実行できる管理者の電子メール・アドレスを指定します。

表27-1 analytics-build.propertiesの全般的なインストール・プロパティ

プロパティ

説明

Analytics.installation.path

最終的なAnalyticsインストール・ディレクトリの絶対パス。

swchart.instdir

Swiff Chart製品がインストールされているディレクトリの絶対パス。

注意: パスはスラッシュ(UNIX上)または円記号(Windows上)で終了する必要があります。

forgotpassword.value

パスワードのリカバリを担当するAnalytics管理者の電子メール・アドレス。global.xmlファイルで、電子メール・アドレスを設定します。

noaccount.value

アカウントの作成を担当するAnalytics管理者の電子メール・アドレス。global.xmlファイルで、電子メール・アドレスを設定します。

href.help.value

Analyticsに関するヘルプを入手できるURL。

http://www.oracle.com/technetwork/middleware/webcenter/sites/overview/index.html

27.2.2.2 ビジター検出プロパティ

ビジターの検出は、Analytics Sensor(データ取得アプリケーション)によって行われます。デフォルトでは、analytics-build.propertiesファイルで、すべてのサイトにわたってビジターをトラッキングするSessionfingerprintメソッドがサポートされています。Sessionfingerprintメソッドは、IPアドレス、画面解像度およびエージェント文字列の組合せによって各ビジターを識別します。

表27-2を使用して、analytics-build.propertiesでビジター検出プロパティを確認または設定(示したとおりに)します。それらのプロパティは、オブジェクト・インプレッション(システムによって取得および処理される)に含める識別子をシステムがどのように生成するのかを指定します。識別子は、集計のためのオブジェクト・インプレッションの適切なグループ化を提供するために重要です。

注意:

オブジェクト・インプレッションは、sensorサーブレットの単一の呼出しです。詳細は、『Oracle Fusion Middleware WebCenter Sites: Analytics管理者ガイド』のオブジェクト・インプレッションに関する項を参照してください。

表27-2 analytics-build.propertiesのビジター検出プロパティ

プロパティ

説明

sessionIdGenerator

セッションの識別に使用されるIDジェネレータを指定します。

注意: デフォルト値はAppServerIDです。この値は修正しないでください。それは、IDを生成するオブジェクトへの参照です。

visitorIdGenerator

サイトのビジターの識別に使用されるIDジェネレータを指定します。

注意: デフォルト値はSessionfingerprintIdです。このデフォルト値では、IPアドレス、画面サイズおよびエージェント(ブラウザ・タイプ)の組合せである識別子が生成されます。

デフォルト・ジェネレータでは不十分な場合は、ビジターを一意に識別する他の2つのオプションがあります。自己構成検出とCookieメソッドです。これらのオプションを実装するかSessionfingerprint構成を(選択したサイトのビジターを検出するために)調整する場合は、Analyticsのインストール後にglobal.xmlを直接変更することで、それを実行できます。(手順は、第29章「ビジター検出の構成」に記載しています。)

27.2.2.3 システム構成および処理のデフォルト

analytics-build.propertiesのencodingプロパティがUTF-8に設定されており、アプリケーション・サーバーの設定が同じ値に設定されていることを確認します。サイレント・インストーラによって、global.xmlのencodingパラメータが、analytics-build.propertiesに指定した値に設定されます。

必要に応じて、データ処理およびアーカイブに関連するプロパティ(表27-3に示す)を設定します。

表27-3 analytics-build.propertiesのデータ処理およびアーカイブのプロパティ

プロパティ

説明

midnight.offset

ファイル・ローテーションに使用される相対的な午前0時をシステムが導出できるようにします。相対的な午前0時およびsession.rotate.delayによって、セッション・データを取得するための毎日のサイクルがいつ終了するのかが決まります。(session.rotate.delayの詳細は、表28-1にあります。)

書式: 分

デフォルト値: 0

cs_enabled

Analyticsインタフェースで、WebCenter Sitesインタフェースに移動するためのボタンを有効化するか無効化するかを指定します。

デフォルト値: true

archive.enabled

RAWデータ・ファイルのHDFSエージェントによるアーカイブを有効化するかどうかを指定します。

archive.enabledがtrueまたはfalseに設定されている場合、data.txtファイルは、analyticsルート・フォルダから削除されます。

アーカイブを有効化するには、このプロパティをtrueに設定します。アーカイブを有効化すると、HDFSエージェントによって、data.txtがアーカイブ・フォルダに移動されることにより、RAW Analyticsデータのアーカイブが定期的に作成されるようになります。(アーカイブ・ディレクトリおよび開始時刻は、次のプロパティで指定されます。archive.output.dirおよびarchive.start.time)

デフォルト値: false

archive.output.dir

アーカイブ済データ・ファイルを格納するディレクトリのパスを指定します。有効なURIにする必要があります。

サンプル値:

- Windows:
archive.output.dir=file://d:/archive

- Linux:
archive.output.dir=/analytics/archive

書式: ディレクトリ・パス

archive.start.time

RAWデータのアーカイブの開示時刻(HH:mm)を指定します。HDFSエージェントが、このプロパティで指定した時刻に、毎日、アーカイブ・タスクを開始するようになります。

たとえば、毎日午後4時にアーカイブを開始するには、archive.start.time=16:00と設定します。

書式: HH:mmで表される24時間書式。HHの範囲は00–23、mmの範囲は00–59です。

デフォルト値: 06:00

purgejobs.enabled

パージ・ジョブをいつ実行するのかを決定します。このプロパティをtrueに設定した場合、システムによって、サブフォルダおよびファイルをそれらが正常に処理された後に削除するクリーンアップ・ジョブが自動的にスケジュールされます。

デフォルト値: false

sensor.requestqueue
.maxsize

Analytics SensorのCRITICAL状態を指定します。

このプロパティは、記録する必要があるRAWデータの量に対して十分な速度でセンサーが反応できないCRITICAL (赤)状態をトリガーするしきい値を指定します。このしきい値に達するか超えた場合は、Analytics Sensorコンポーネントが赤く表示されます。

このプロパティのしきい値は、オブジェクト・インプレッションとして、つまり、sensorサーブレットの単一の呼出しとして表されます。

(Analytics Sensorコンポーネントは、『Oracle Fusion Middleware WebCenter Sites: Analytics管理者ガイド』のHadoopジョブのプロセス・フローの図に示すように、Analytics管理インタフェースのパネルの「コンポーネント」タブの「概要」オプションに表されます。)

デフォルト値: 10000

sensor.requestqueue
.warnsize

Analytics SensorのWARNING状態を指定します。

このプロパティは、記録する必要があるRAWデータの量に対して十分な速度でセンサーが反応できないWARNING (黄)状態をトリガーするしきい値を指定します。このしきい値に達するか超えた場合は、Analytics Sensorコンポーネントが黄色く表示されます。

このプロパティのしきい値は、オブジェクト・インプレッションとして、つまり、sensorサーブレットの単一の呼出しとして表されます。

(Analytics Sensorコンポーネントは、『Oracle Fusion Middleware WebCenter Sites: Analytics管理者ガイド』のHadoopジョブのプロセス・フローの図に示すように、Analytics管理インタフェースのパネルの「コンポーネント」タブの「概要」オプションに表されます。)

デフォルト値: 3000

27.2.2.4 WebサーバーURLプロパティ

この項では、WebCenter Sites URL、および各Analytics Webアプリケーションがそのインストールの完了後に常駐する基本URL (http://<address>:<port>)を指定します。表27-4を参照してください。

表27-4 analytics-build.propertiesのWebサーバーURLプロパティ

プロパティ

説明

analytics.sensor.web.server

センサーWebアプリケーションのURL。

analytics.report.web.server

Analytics WebアプリケーションのURL。

analytics.admin.web.server

Analytics管理WebアプリケーションのURL。

27.2.2.5 アプリケーション・サーバー・デプロイメント・プロパティ

この項では、Analytics Webアプリケーションをデプロイするためにインストーラによって使用されるアプリケーション・サーバーを指定します。使用されないアプリケーション・サーバーの無効化も行います。表27-5、表27-6、表27-7および表27-8を参照してください。

注意:

次の点を確認してください。

- 使用されるアプリケーション・サーバーに対して、そのinstallプロパティをtrueに設定します。他の関連するプロパティをすべて設定します。

- 使用されないアプリケーション・サーバーそれぞれに対して、そのアプリケーション・サーバーに関連する文を削除しないでください。そのアプリケーション・サーバーのinstallプロパティがfalse (デフォルト)に設定されていることを確認します。そのようにしない場合、インストーラによってそのサーバーへのAnalytics Webアプリケーションのデプロイが試みられます。

表27-5 analytics-build.propertiesのWebLogicデプロイメント・プロパティ

プロパティ

説明

install.weblogic

WebLogicをデプロイするにはtrueに設定します。

weblogic.userid

WebLogic管理ユーザーID。

weblogic.password

前に指定したWebLogic管理ユーザーのパスワード。

weblogic.targets

サーバー名、クラスタ名または仮装ホスト名。

weblogic.admin.url

WebLogicの管理機能のURL。

weblogic.home.dir

WebLogicホーム・ディレクトリのパス。

表27-6 analytics-build.propertiesのJBossデプロイメント・プロパティ

プロパティ

説明

install.jboss

JBossをデプロイするにはtrueに設定します。

jboss.deploy.dir

JBossデプロイメント・ディレクトリのパス。

表27-7 analytics-build.propertiesのTomcatデプロイメント・プロパティ

プロパティ

説明

install.tomcat

Tomcatをデプロイするにはtrueに設定します。

tomcat.home.dir

Tomcatホーム・ディレクトリのパス。

表27-8 analytics-build.propertiesのWebSphereデプロイメント・プロパティ

プロパティ

説明

install.websphere

WebSphereをデプロイするにはtrueに設定します。

websphere.userid

WebSphere管理ユーザーID。

websphere.password

WebSphere管理パスワード。

websphere.home.dir

WebSphereホーム・ディレクトリ。

websphere.node.name

WebSphereノードの名前。

websphere.base.command

WebSphere wsadminコマンド。

websphere.save.command

WebSphere saveコマンド。

websphere.engine.instdir.value

Analytics reportingengineインストール・ディレクトリの場所。

websphere.cell.name

ソフトウェア・コンポーネントが配布および実行される単一ノード(マシン・インスタンス)または複数ノードを表すために定義されたネームスペース。

WebSphereアプリケーション・サーバー上にAnalyticsアプリケーションをインストールする場合は、そのアプリケーションがインストールおよび実行されるセルおよびノードの名前を指定することで、そのアプリケーションの配布方法を指定する必要があります。

websphere.server.name

アプリケーションがデプロイされているWebSphereインストール内のサーバーの名前。

27.2.2.6 データベース接続プロパティ

この項では、インストーラによってAnalyticsデータを格納するためにOracle Databaseへのアクセスに使用される情報を指定します。Analytics構成ファイルに配置されるJDBC/JNDI情報も指定します。JDBCデータとJNDIデータは、相互に排他です。それらのうち一方についてのみ、そのenabledプロパティをtrueに設定してください。表27-9、表27-10および表27-11を参照してください。

表27-9 analytics-build.propertiesのデータベース・プロパティ

プロパティ

説明

install.database

インストール・スキーマ問合せを実行するにはtrueに設定します。

db.home.dir

データベース・ホーム・ディレクトリ。

db.sys.user

システム・ユーザー名。

db.sys.password

システム・ユーザー・パスワード。

db.host

ホスト・アドレス。

db.port

ホスト・ポート番号。

db.sid

データベースSID。

表27-10 analytics-build.propertiesのJDBCデータベース・ライター・プロパティ

プロパティ

説明

jdbc.enabled

True | false

JDBC設定を構成するにはtrueに設定します。

jdbc.name.value

データベース接続の名前。

jdbc.default.value

default="true"でマークされる接続が1つのみ存在する必要があります。

jdbc.type.value

接続のタイプ: jdbc

jdbc.classname.value

JDBCドライバ・クラス。

jdbc.url.value

JDBC URL

jdbc.user.value

JDBC属性。データベース・ユーザー名

jdbc.password.value

JDBC属性、データベース・パスワード

表27-11 analytics-build.propertiesのJNDIプロパティ

プロパティ

説明

jndi.enabled

True | false

JNDI設定を構成するにはtrueに設定します。

jndi.name.value

データベース接続の名前。

jndi.default.value

default="true"でマークされる接続が1つのみ存在する必要があります。

jndi.type.value

接続のタイプ: resource

jndi.resource.value

JNDI属性。JNDI名

27.2.2.7 Hadoopプロパティ

この項では、Hadoop構成に関する情報を指定します(表27-12)。

- Hadoopインストール・ディレクトリのベース・パス

- RAWデータのパス。一方のパスは、ローカル・ファイル・システム上で、Analytics Sensor(データ取得アプリケーション)によってRAWデータが記録される場所を指定します。他方のパスは、Hadoop分散ファイル・システム上で、HDFSエージェントによってRAWデータが書き込まれる場所を指定します。

表27-12 analytics-build.propertiesのHadoopプロパティ

プロパティ

説明

hadoop.installation.path

Hadoopインストール・ディレクトリのパス。

hadoop.hdfs.defaultfs

Analytics RAWデータを書き込むためのHDFSのデフォルト・パス。

hadoop.tasktracker.url

Hadoopタスク・トラッカWebアプリケーションのURL。

hadoop.filesystem.url

Hadoopファイル・システムWebアプリケーションのURL。

logwriter.output.path

データ取得アプリケーションがRAWデータを記録するローカル・ファイル・システムのパス。

27.2.3 ステップ3. サイレント・インストーラの実行を準備する

サイレント・インストーラを実行する前に、サイレント・インストーラを解凍したすべてのサーバー上で次の手順を完了します。

1. 環境内のJAVA_HOMEおよびANT_HOMEが、適切なパスに設定されていることを確認します。

2. すべてのAnalyticsアプリケーション・サーバーを起動します(サイレント・インストーラが機能するには、それらが実行中であることが必要です)。

3. UNIXを使用している場合は、次のコマンドを発行して(インストーラを実行するための)その後のコマンドを実行できるようにします。

chmod +x analytics_install.sh

4. WebLogicにインストールする場合は、次のコマンドの1つを実行し、クラスパスが適切に設定されていることを確認し、WebLogicデプロイメント・タスクが適切に実行されるようにしてください。

- UNIX:

<WL_HOME>/server/bin/setWLSEnv.sh

- Windows:

<WL_HOME>\setWLSEnv.bat

27.2.4 ステップ4. Analyticsをインストールする

この手順では、サイレント・インストーラを実行し、それによって、analytics-build.propertiesファイル(その中で次のものが指定されている)に対してAnalytics製品がインストールされます。

- ファイル・システム上のAnalyticsがインストールされる場所。

- 使用するアプリケーション・サーバーおよびそれが存在する場所。

- データベースの場所。

- WebCenter Sitesの場所。

- システム上のその他の関連する製品またはソフトウェア・コンポーネントが配置されている場所。

この項には、次のインストール・シナリオが含まれています。

- 第27.2.4.1項「単一サーバーのAnalyticsのインストール」

- 第27.2.4.2項「デュアル・サーバーのAnalyticsのインストール」

- 第27.2.4.3項「分散Analyticsインストール」

27.2.4.1 単一サーバーのAnalyticsのインストール

このシナリオでは、すべてのAnalyticsサポート・ソフトウェアを実行しているものと同じサーバー上にAnalytics製品全体をインストールします。

単一サーバーにAnalyticsをインストールする手順は、次のとおりです。

1. 次のようにサイレント・インストーラを実行します。

- UNIX:

./analytics_install.sh

- Windows:

analytics_install.bat

注意:

インストールされるコンポーネントの説明は、表27-13を参照してください。サイレント・インストーラが実行されるときに発生するイベントの詳細は、この手順の次のステップを参照してください。

2. analytics_installコマンドの実行が開始されると、インストール・プロセスが開始され、第27.1.2項「サイレント・インストーラのアクション」にリストされたステップがスクリプトによって実行されます。インストール・プロセスが正常に完了すると、次のメッセージが表示されます。

The silent install has finished.
--------------------------------------------------------------
Your installation of Analytics is complete. Please review your
application server documentation and make sure that it is
configured for UTF-8 encoding.

--------------------------------------------------------------

注意:

エラーが発生した場合、インストール・プロセスは終了し、次のメッセージが表示されます。

"The install script ended with error code nn. Please consult the log and check for errors."

コンソールにエラーが報告された場合は、analytics-install.logを調べ、問題を特定します(analytics-install.logファイルは、サイレント・インストーラが常駐しているディレクトリに配置されています)。通常、問題は、1つ以上のプロパティが不適切に構成されている場合に発生します。プロパティを注意深く見直し、不適切なプロパティを修正して、サイレント・インストーラを再実行します。

必須コンポーネントが見つからないためにエラーが発生した場合は、JAVA_HOMEまたはANT_HOME環境設定に適切な調整を行い、サイレント・インストーラを再実行します。

3. インストーラがそのタスクを正常に完了したら、Analyticsに対してWebCenter Sitesを初期化します。「ステップ5. Analyticsを有効化するようにWebCenter Sitesを構成する」に進みます。

27.2.4.2 デュアル・サーバーのAnalyticsのインストール

このシナリオでは、データベースを除くAnalyticsサポート・ソフトウェアをホストしているサーバー上に、Analytics製品をインストールします。Analyticsデータベースは、それ自体のサーバーにインストールされます。

2つのサーバー上にAnalyticsをインストールする手順は、次のとおりです。

1. Analyticsをインストールするサーバー上でサイレント・インストーラを実行します。

- UNIX:

./analytics_install.sh sensor hadoopjobs analytics analyticsadmin cs_integration verify_install

- Windows:

analytics_install.bat sensor hadoopjobs analytics
analyticsadmin cs_integration verify_install

analytics_installコマンドの実行が開始されると、インストール・プロセスが始まります。サイレント・インストーラが実行されるときに発生するイベントの詳細は、第27.2.4.1項「単一サーバーのAnalyticsのインストール」のステップ2を参照してください。

2. SQL Plusがすでにインストールされているデータベース・サーバー上でサイレント・インストーラを実行します。(サイレント・インストーラを実行すると、表27-13に示すように、AnalyticsスキーマでOracle Databaseが初期化されます。Antターゲットのdatabaseを参照してください)。

- UNIX:

./analytics_install.sh database

- Windows:

analytics_install.bat database

3. インストーラがそのタスクを正常に完了したら、Analyticsに対してWebCenter Sitesを初期化します。「ステップ5. Analyticsを有効化するようにWebCenter Sitesを構成する」に進みます。

27.2.4.3 分散Analyticsインストール

分散インストールの場合、analytics2.5.zipを解凍したサーバーに、Analytics製品の様々な部分をインストールします。analytics_installコマンドを実行し、指定したサーバーにどの部分(つまり、Antターゲット)をインストールするのかを指定します。選択したターゲットに、サポート・システムに対する依存関係がある場合、サイレント・インストーラによって、そのサポート・システムがインストールされているかどうか(Analyticsデータベースの場合は実行されているかどうかも)が確認されます。表27-13は、サイレント・インストーラによって認識される各ターゲットおよびそれの他のシステムに対する依存関係を示しています。

分散モードでAnalyticsをインストールする手順は、次のとおりです。

1. AnalyticsコンポーネントをインストールするAnalyticsサーバーごとにインストーラを実行します。

- UNIX:

./analytics_install.sh <Ant_target>

- Windows:

analytics_install.bat <Ant_target>

注意:

<Ant_target>パラメータは、表27-13で定義されている個々のAntターゲットまたは空白で区切ったターゲットのリストに設定できます。一度に1つずつターゲットをインストールするには、ターゲットごとにサイレント・インストーラを実行します。ターゲットを指定しない場合は、指定されたサーバーにすべてのAnalyticsコンポーネント(表27-13に定義されている)がインストールされます。

表27-13 Antターゲットおよびそれらの依存関係

Antターゲット

説明

サイレント・インストーラを解凍したサーバー

依存関係

sensor

データ取得WebアプリケーションおよびHDFSエージェント(Oracle固有)をインストールします。

データ取得

なし

hadoopjobs

Oracle固有のAnalytics/Hadoopジョブ・スケジューラをインストールします。

マスター・ノード

Oracle

database

AnalyticsスキーマでOracle Databaseを更新します。

database Antターゲットは、Analytics固有のデータベース定義をSQL Plusにロードします。その後、SQL Plusは、その定義でOracle Databaseを更新し、Analyticsによって必要とされるスキーマでデータベースを初期化します。

SQL Plusがインストールされているサーバー

Oracle

analytics

Analyticsレポート作成エンジンWebアプリケーションをインストールします。

管理、レポート作成

Oracle

analyticsadmin

Analytics管理Webアプリケーションをインストールします。

管理、レポート作成

Oracle

cs_integration

futuretense_xcel.iniを変更します(WebCenter Sitesシステム上にあります。WebCenter Sitesが実行中でなくても、futuretense_xcel.iniはインストーラによって変更されます)。

サイレント・インストーラは、cs.localプロパティ(インストール・プロセス中に設定)に対してfuturetense_xcel.iniを見つけます。

WebCenter Sitesホスト

なし

verify_install

Hadoopジョブの検証に使用されるオブジェクト・インプレッションを提供します。

注意: 第30章「Analyticsインストールの検証」でAnalyticsインストールを検証する場合は、このターゲットを使用します。

データ取得

なし

2. analytics_installコマンドの実行が開始されると、インストール・プロセスが始まります。サイレント・インストーラが実行されるときに発生するイベントの詳細は、第27.2.4.1項「単一サーバーのAnalyticsのインストール」のステップ2を参照してください。

3. インストーラによってそのタスクが正常に完了されたら、Analyticsを有効化するようにWebCenter Sitesを構成し、Analyticsサーバーの場所を指定します。「ステップ5. Analyticsを有効化するようにWebCenter Sitesを構成する」に進みます。

27.2.5 ステップ5. Analyticsを有効化するようにWebCenter Sitesを構成する

Analyticsが正常にインストールされたら、WebCenter Sitesホスト上で次の手順を完了します。

注意:

WebCenter Sitesが実行中でなくても、この項の手順は正常に完了します。

1. WebCenter Sites futuretense_xcel.iniプロパティ・ファイルの場所を指定し、サイレント・インストーラがAnalytics固有の設定でそれを変更できるようにします。
analytics-build.propertiesを開き、表27-14に示すプロパティを変更します。

表27-14 futuretense_xcel.iniを更新するプロパティ

プロパティ

説明

cs.local

WebCenter Sitesが(サイレント・インストーラに対して)ローカルであることを指定します。このプロパティがtrueに設定されていることを確認します。

src.ini.file

WebCenter Sites futuretense_xcel.iniプロパティ・ファイルの場所を指定します。

サンプル値:

- Windows:

- C:/JSK_060809\RunTime\ContentServer/7.5.1/futuretense_xcel.ini

- Linux:

- /home/fatwire/RunTime/contentServer/7.5.1/futuretense_xcel.ini

mod.ini.file

WebCenter Sites futuretense_xcel.iniプロパティ・ファイルのパスを指定します。(このパスは、src.ini.fileプロパティ内のパスと同一です。)

AnalyticsがインストールされていることをWebCenter Sitesに認識させます。このプロパティは(analytics-build.propertiesで指定した変更に従って)futuretense_xcel.iniを変更し、変更済のfuturetense_xcel.iniファイルを、指定した場所に書き込みます。元のfuturetense_xcel.iniファイル(src.ini.fileによって指定されたもの)は、自動的にバックアップされます。

サンプル値: src.ini.fileで設定した値を使用します。

2. WebCenter Sitesホストで、次のようにサイレント・インストーラを実行します。

- UNIX:

./analytics_install.sh cs_integration

- Windows:

analytics_install.bat cs_integration

3. サイレント・インストーラによってそのタスクが完了されたら、第27.3項「次のステップ」に進みます。

27.3 次のステップ

- Analyticsのインストールを検証する前に、必要に応じて、次の手順を完了します。

- サイレント・インストーラによって更新されたAnalytics構成ファイルを調べます。第28章「Analytics構成パラメータの調整」を参照してください。この章には、Hadoopジョブ・スケジューラのロギングのセットアップ手順も記載されています。

- 任意。ビジタートラッキング構成を変更します。手順は、第29章「ビジター検出の構成」を参照してください。

- Analyticsのインストールを完了するには、第30章「Analyticsインストールの検証」の手順に従ってください。

28 Analytics構成パラメータの調整

この章では、サイレント・インストーラによってAnalyticsがインストールされるときに更新される構成ファイルについて説明します。この章では、構成ファイル内のプロパティの設定のガイドラインも示します。ファイルは次のとおりです。

- 第28.2項「global.xml」

- 第28.3項「log4j.properties」

- 第28.4項「futuretense_xcel.ini」

28.1 構成ファイルの概要

Analyticsをインストールする場合、サイレント・インストーラによって、各種プロパティの値が、analytics-build.propertiesで指定した値に一致するように設定されます。プロパティは、次のファイル内に格納されています。

- global.xml

- log4j.properties

- futuretense_xcel.ini

Analyticsがイントールされたら、必要に応じて、それぞれのファイル内の各種プロパティを直接調整できます。ガイドラインは、この章の残りの部分で説明します。

注意:

サイレント・インストーラによって作成されるインストール・ディレクトリ(および関連する構成)は、移動したり、名前変更したり、その他の方法で変更したりしないでください。

28.2 global.xml

global.xmlファイルは、そのファイルが格納され、かつインストーラが実行された各サーバー上で、Analyticsサイレント・インストーラによって変更されます。Analyticsがインストールされたら、global.xmlをそれぞれのホスト上で直接カスタマイズできます。カスタマイズ可能なセクションは次のとおりです。

- <params> </params>内のパラメータ

- データベース接続パラメータ

- LFSログライター実装パラメータ

注意:

次の表では、リセットできないプロパティには影が付いています。各アプリケーションには、そのアプリケーションのクラスパスに配置されている、それ自体のglobal.xmlファイルがあります。

28.2.1 <params> </params>内のパラメータ

このセクションには、Analyticsインストール・ディレクトリ、システム管理者の連絡先、RAWデータの処理およびデータ処理条件を定義するプロパティが含まれています。

注意:

表28-1では、いくつかのパラメータの後にアスタリスク(*)が付いていますが、これはそれらのパラメータがリセットできないことを示しています。

表28-1 global.xmlのAnalyticsパラメータ

パラメータ

説明

サンプル値/書式

ホスト

swchart_instdir*

Swiff Chart Generatorのインストール・ディレクトリの絶対パス。

UNIX:

/usr1/software/SwiffChart

Windows:

C:/Program Files/GlobFX
/Swiff Chart Generator3

なし

engine_instdir*

Analyticsアプリケーションがデプロイされたディレクトリの絶対パス。

UNIX:

/usr/share/tomcat/analytics

Windows:

C:/CS/tomcat5/webapps
/analytics

なし

href_cs*

WebCenter SitesインタフェースのコンテキストURL。

http://analytics
.yourcompany.com/analytics

なし

report_instdir*

デプロイ済レポート構成XMLファイルの絶対パス。

UNIX:

/data/analytics/reports

Windows:

C:/CS/reports

なし

forgotpassword

パスワードのリカバリを担当するAnalytics管理者の電子メール・アドレス。

admin@yourcompany.com

レポート作成ノード

noaccount

アカウントの作成を担当するAnalytics管理者の電子メール・アドレス。

admin@yourcompany.com

レポート作成ノード

href_reporting*

Analyticsレポート作成アプリケーションのURL。このURLは、Analyticsレポート作成アプリケーションからAnalytics管理者アプリケーションにリンクするために必要です。

../analytics/

なし

href_admin*

Analyticsレポート管理者アプリケーションのURL。このURLは、Analyticsレポート管理者アプリケーションからAnalyticsレポート作成アプリケーションにリンクするために必要です。

../analyticsadmin/

なし

href_help*

Analyticsに関するヘルプを入手できるURL。

http://www.oracle.com
/technetwork/middleware
/webcenter/sites/overview
/index.html

なし

encoding*

リクエスト・パラメータのデコードおよびレスポンス・パラメータのエンコードに使用される文字エンコーディング。このエンコーディングは、アプリケーション・サーバーのエンコーディングと一致している必要があります。

utf8

なし

hadoop.hdfs
.defaultfs*

Hadoopファイル・システム上で、下にRAWデータ、出力およびキャッシュのファイルが格納されているルート・ディレクトリの場所。

hdfs://<hostname>:<port>
/analytics

説明:

<hostname>は、マスター・ノードの名前です。

<port>は、hadoop-site.xml.のfs.default.name構成パラメータに指定されているNameNodeポートです。

なし

hadoop.local.
cachedir*

ジョブの起動時にfileEnvObjectsを格納するフォルダのローカル・パス。

/usr/local/cache/

なし

analytics.
filtercurrentdata

現在の日、週、月および年のデータの処理をスキップするかどうかを指定するフラグ。

下の行にリストされるプロパティを有効化する場合、このプロパティをtrueに設定します。(それらのプロパティは次のとおりです。analytics.filtercurrentXXX)

デフォルト値: false

マスター・ノード

analytics.
filtercurrentXXX

(XXXは、day、week、monthまたはyearです)

現在の日/週/月/年のデータの処理をスキップするかどうかを指定するフラグ。日/週/月/年のそれぞれの処理は、次のパラメータを追加し、それらをfalseに設定することで、個別に設定できます。

analytics.filtercurrentday
analytics.filtercurrentweek
analytics.filtercurrentmonth
analytics.filtercurrentyear

注意: 前述のパラメータの1つ以上を追加する場合、analytics.filtercurrentdata (前にリストしたもの)がtrueに設定されていることを確認します。

analytics.filtercurrentday=
false

マスター・ノード

admin.context*

Analyticsレポート管理者アプリケーションのURL。末尾のスラッシュ(/)を追加します。

http://<hostname>:<port>
/analyticsadmin/

説明:

<hostname> は、管理サーバーの名前です。

<port>は、アプリケーション・サーバーのポートです。

なし

sensor.context*

センサー・アプリケーションのURL。末尾のスラッシュを追加します。

http://<hostname>:<port>/sensor/

説明:

<hostname>は、データ取得サーバーの名前です。

<port>は、アプリケーション・サーバーのポートです。

なし

monitoring.
registry.port*

RMIサービスを起動するポート。

11199

なし

href.hadoop.
tasktracker*

Hadoop TaskTracker管理インタフェースのURL。

http://<hostname>:50030/

説明:

<hostname>は、マスター・ノードの名前です。

href.hadoop.
filesystem.
browser*

hdfsファイル・システム・ブラウザ・インタフェースのURL。

http://<hostname>:50070/

説明:

<hostname>は、マスター・ノードの名前です。

importer.sleeptime

ローカル・ファイル・システムからhdfsにコピーするRAWデータをhdfsagentが検索するまでの時間間隔(分単位)。

10

データ取得

NumberOfProcessor
Threads

同時に実行されるジョブの数。各ジョブは、Hadoopによってタスクに分割されます。

大規模システムの場合、NumberOfProcessorThreadsは1に設定し、一度に実行できるジョブが1つのみになるようにします。小規模システムまたはデモンストレーション・シナリオでは、この値を大きくできます(3、4または5)。

1

マスター・ノード

sensor.
thresholdtime

センサーがdata.txt.tmpファイル(受信RAWデータが最初に書き込まれる)をdata.txtにローテーションするまでの時間間隔(分単位)。その間隔内に処理されるデータが5から10GBを超えないように時間間隔を設定します。

このパラメータを省略した場合、デフォルトのしきい値の時間(10分)が使用されます。

240

データ取得

session.rotate.
delay

RAWセッション・データが未処理のままになる、午前0時の後の時間間隔(分単位)。

デフォルトは360分です。つまり、セッション・データは、午前0時の6時間後にHDFSに移動されます。その後、セッション処理が開始されます。

360

データ取得

scheduler.
checkinterval

スケジューラが新規データに対して新しいHadoopジョブを作成する頻度を指定します。

デフォルト値は15分です。

15

マスター・ノード

midnight.offset

ファイル・ローテーションに使用される相対的な午前0時をシステムが導出できるようにします。相対的な午前0時およびsession.rotate。

delayによって、セッション・データを取得するための毎日のサイクルがいつ終了するのかが決まります。

デフォルト値: 0

書式: 分

データ取得

cs_enabled

Analyticsインタフェースで、WebCenter Sitesインタフェースに移動するためのボタンを有効化するか無効化するかを指定します。

デフォルト値: true

レポート作成アプリケーション

archive.enabled

RAWデータ・ファイルのHDFSエージェントによるアーカイブを有効化するかどうかを指定します。このプロパティがtrueに設定されている場合、HDFSエージェントによって、RAW分析データのアーカイブが定期的に自動的に作成されます。アーカイブ・ディレクトリおよび開始時刻は、次のプロパティで指定されます。archive.output.dirおよびarchive.start.time

デフォルト値: false

データ取得

archive.output.dir

アーカイブ済データ・ファイルを格納するディレクトリのパス。有効なURIにする必要があります。

書式: ディレクトリ・パス

データ取得

archive.start.
time

アーカイブの開始時刻。アーカイブ・タスクは、毎日、HH:mmに開始されます。

デフォルト値: 06:00

書式: HH:mm (24時間形式)。HHの範囲は00–23、mmの範囲は00–59です。

データ取得

purgejobs.enabled

このプロパティをtrueに設定した場合、システムによって、サブフォルダおよびファイルをそれらが正常に処理された後に削除するクリーンアップ・ジョブが自動的にスケジュールされます。

デフォルト値: false

マスター・ノード

notification.
enabled

電子メール通知を有効化するかどうかを示します。電子メール通知は、Analyticsサービスの可用性が変更されたときに送信されます。

デフォルト値: false

管理ノード

mail.from

通知の送信元の電子メール・アドレス。

書式: 電子メール・アドレス

管理ノード

sensor.
requestqueue.
maxsize

Analytics SensorのCRITICAL状態を指定します。

このプロパティは、記録する必要があるRAWデータの量に対して十分な速度でセンサーが反応できないCRITICAL (赤)状態をトリガーするしきい値を指定します。このしきい値に達するか超えた場合は、Analytics Sensorコンポーネントが赤く表示されます。

このプロパティのしきい値は、オブジェクト・インプレッションとして、つまり、sensorサーブレットの単一の呼出しとして表されます。

(Analytics Sensorコンポーネントは、Analytics管理インタフェースの「コンポーネント」タブの「概要」パネルに表されます。)

デフォルト値: 10000

管理ノード

sensor.
requestqueue.
warnsize

Analytics SensorのWARNING状態を指定します。

このプロパティは、記録する必要があるRAWデータの量に対して十分な速度でセンサーが反応できないWARNING (黄)状態をトリガーするしきい値を指定します。このしきい値に達するか超えた場合は、Analytics Sensorコンポーネントが黄色く表示されます。

このプロパティのしきい値は、オブジェクト・インプレッションとして、つまり、sensorサーブレットの単一の呼出しとして表されます。

(Analytics Sensorコンポーネントは、Analytics管理インタフェースの「コンポーネント」タブの「概要」パネルに表されます。)

デフォルト値: 3000

管理ノード

ipBlacklist

正規化プロセス中にレコードが無視されるIPアドレスを格納します。このパラメータの値は、リクエストIPアドレスと比較されるIPアドレス(またはフラグメント、あるいはその両方)のカンマ区切りリストです。リクエスト・アドレスが、リストされた値のいずれかと一致する場合、それは削除されます。

- 特定のIPアドレスからのすべてのサイトへのアクセスを制限する場合は、次のエレメントでipBlacklistパラメータを囲みます。

<params host="default"
...
</params>

- 特定のIPアドレスからの特定のサイトへのアクセスを制限する場合は、各サイトについて、次のエレメントでipBlacklistパラメータを囲みます。

<params host="siteName">
...
</params>

書式:

<param type="string"
name="ipBlacklist"
value="ip_address-1,
ip_address-2, ..."/>

- すべてのサイトに対するサンプルIPアドレス・ブラックリスト:

<params host="default"
<param type="string" name="ipBlacklist"
value="123.45.67.89,
192.168.1.4"
/>
</params>

- 特定のサイトに対するサンプルIPアドレス・ブラックリスト:

<params host= "CompanySite.com">
<paramtype="ipBlacklist"value="123.45.67.89, 192.168.90.5"/>
</params>

データ取得

28.2.1.1 データベース接続パラメータ

通常、ユーザーが必要とするデータベース接続は1つのみです。カスタム・レポート作成には、複数の接続が必要な場合があります。独自のJDBCリソースを定義するか、JNDIを介して既存のJDBC接続を参照する必要がある場合、次のタグを使用します。

<connection
name="<connection_name>"
default="true"
type="<jdbc_or_resource>"
classname="<database_driver_classname>"
url="<database_url>"
user="<database user name>"
password="<database password>" />

表28-2は、データベース接続パラメータを示しています。

表28-2 データベース接続パラメータ

パラメータ

説明

name

接続の名前。

例: localhostDB

default

default="true"でマークされる接続が1つのみ存在する必要があります。

type

接続のタイプ: jdbc (JDBC)またはresource (JNDI)

resourcename

JNDI属性、JNDI名

注意: typeがresourceに設定されている場合にのみ使用されます。

classname

JDBCドライバ・クラス。

例: oracle.jdbc.driver.OracleDriver

url

JDBC URL

user

JDBC属性、データベース・ユーザー名

password

JDBC属性、データベース・パスワード

例28-1 Example JDBC:

<connection
name="jdbcsample"
default="true"
type="jdbc"
classname="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@dbserver:1521:sid"
user="analytics"
password="analytics" />

例28-2 Example JNDI:

<connection
name="conn1"
default="false"
type="resource"
resourcename="java:comp/env/jdbc/tadev" />

28.2.2 LFSログライター実装パラメータ

LFSログライター実装により、ローカル・ファイル・システムに受信RAWデータが書き込まれます。ルート・パス(RAWデータの書込み先の場所)を変更する場合、次のタグを使用します。

<logwriters>
<logwriter type="LFS" name="LFS" rootpath="C:/analytics/
sensorlocal" />
</logwriters>

注意:

表28-3では、いくつかのパラメータの後にアスタリスク(*)が付いていますが、これはそれらのパラメータがリセットできないことを示しています。

表28-3 ログライター・パラメータ

パラメータ

説明

type*

ログライターのタイプ。

有効な値: LFS

name*

ログライターの別名。

有効な値: LFS

rootpath

RAWデータの書込み先となる、ローカル・ファイル・システム上の場所。

例:

UNIX:

rootpath="/analytics/sensor"

Windows:

rootpath="c:/analytics/sensor"

28.3 log4j.properties

log4j.propertiesファイルは、そのファイルが格納され、かつインストーラが実行された各サーバー上で、サイレント・インストーラによって変更されます。Analyticsインストールが完了したら、表28-4に示すすべてまたは選択したlog4j.propertiesファイル内のプロパティを直接カスタマイズできます。(log4j.propertiesファイルは、<HADOOP_HOME>/confに配置されています。)

表28-4 log4j.properties内のパラメータ

プロパティ

説明

例/書式

log4j.rootLogger

ログ・レベルおよびルート・ロガーのアペンダを指定します。カンマで区切ることで、複数のアペンダを指定できます。

log4j.rootLogger=INFO,
DaRoFiAppender

-または-

log4j.rootLogger=INFO,
DaRoFiAppender,
ConsoleAppender

log4j.category.
com.fatwire.
analytics

ログ・レベルを指定します。次に、重大度の高いものから順にログ・レベルについて説明します。

- FATAL: 早期終了の原因となる重大なエラー。

- ERROR: ランタイム・エラーまたは予期しない状態。

- WARN: 望ましくないまたは予期しないが、必ずしも誤りではない、他のランタイム状況。

- INFO: アプリケーションのワークフローおよびステータスに関する情報メッセージを提供します。

- DEBUG: 様々な種類のデバッグ情報。

- TRACE: すべてのロギング情報。

注意: 本番モードでは、このプロパティはWARNに設定する必要があります。

INFO

log4j.appender.
DaRoFiAppender

ロギングに使用されるアペンダを指定します。

org.apache.log4j.
DailyRollingFileAppender

log4j.appender.
DaRoFiAppender.
datePattern

次の書式で日付パターンを指定します。

'.'yyyy-MM-dd

log4j.appender.
DaRoFiAppender.file

ログ・ファイルの名前とともに、ログ・ファイルの場所を指定します。

../logs/xxx.log

log4j.appender.
DaRoFiAppender.layout

レイアウトを指定します。

org.apache.log4j.PatternLayout

log4j.appender.
DaRoFiAppender.layout.
ConversionPattern

レイアウト・パターンを指定します。

%d{ISO8601}%- 5p[%t]%c:%m%n

28.3.1 Hadoopジョブ・スケジューラに対するロギングの設定

次のパラメータを追加することで、log4j.propertiesファイルを編集します。

hadoop.root.logger=WARN,console, DRFA
hadoop.log.file=hadoop.log
log4j.rootLogger=${hadoop.root.logger}, DRFA, EventCounter

#
# Daily Rolling File Appender
#
log4j.appender.DRFA=org.apache.log4j.DailyRollingFileAppender
log4j.appender.DRFA.File=${hadoop.log.dir}/${hadoop.log.file}

# Rollver at midnight
log4j.appender.DRFA.DatePattern=.yyyy-MM-dd

# 30-day backup
log4j.appender.DRFA.MaxBackupIndex=30
log4j.appender.DRFA.layout=org.apache.log4j.PatternLayout

# Pattern format: Date LogLevel LoggerName LogMessage
log4j.appender.DRFA.layout.ConversionPattern=%d{ISO8601} %p %c: %m%n

28.4 futuretense_xcel.ini

サイレント・インストーラによって、サイレント・インストーラが実行されているマシンに配置されているWebCenter Sitesアプリケーションのfuturetense_xcel.iniファイルが変更されます。このファイルを変更する目的は、Analyticsアプリケーションの場所および認可ユーザーを指定することです。

注意:

表28-5では、いくつかのパラメータの後にアスタリスク(*)が付いていますが、これはそれらのパラメータがリセットできないことを示しています。

表28-5 futuretense_xcel.iniのAnalyticsプロパティ

プロパティ

説明

例

analytics.datacaptureurl*

Analyticsデータ取得サーブレット(sensorサーブレット)が実行されているURL

http://<ipaddress>:<port>
/sensor/statistic

analytics.enabled

Analyticsが使用可能かどうかを示します。

注意: falseに設定すると、このプロパティによってデータ取得が無効化されます。

true

analytics.piurl*

Analyticsパフォーマンス・インディケータ・サーブレットが実行されているURLパフォーマンス・インディケータの詳細は、『Oracle Fusion Middleware WebCenter Sites: Analytics管理者ガイド』の「Oracle WebCenter Sites: AnalyticsとOracle Web Center Sitesとの統合」の章を参照してください。

http://<ipaddress>:<port>
/analytics/PI

analytics.reporturl*

生成されたレポートが表示されるURL。

http://<ipaddress>:<port>
/analytics/Report.do

analytics.user*

WebCenter SitesからAnalyticsにログインする、事前構成済Analyticsユーザー。

csuser

Analyticsでのデフォルト。名前の変更はお薦めいたしません。

29 ビジター検出の構成

この章の内容は、次のとおりです。

- 第29.1項「概要」

- 第29.2項「メソッド」

29.1 概要

ビジターのトラッキングは、データ取得アプリケーション(センサー)によって行われます。ビジターは次のメソッドでトラッキングできます。

- 自己構成メソッド。新規ビジターのトラッキングをサポートします。

- Sessionfingerprintメソッド

- Cookieメソッド

注意:

デフォルトでは、すべてのサイトでSessionfingerprintメソッドが有効化されています。

29.2 メソッド

ビジターをトラッキングするメソッドは、ビジター・トラッキング・コードをglobal.xml(およびトラッキング・メソッドによってはimgタグ)に追加することで実装します。

注意:

ビジター・トラッキング・メソッドを変更する場合は、各センサー・インスタンスのglobal.xml構成ファイルも更新する必要があります。global.xmlの場所は、使用しているアプリケーション・サーバーによって異なります。

global.xmlファイルのパラメータを変更するときは、Analytics Sensor Webアプリケーションを停止し、そのglobal.xmlファイルを変更し、センサーを起動して変更を有効化します。

29.2.1 自己構成ビジター・トラッキング

自己構成ビジター・トラッキング・メソッドでは、イメージ・リクエストに追加されるcookieidパラメータの値が使用されます。

ビジターをトラッキングする手順は、次のとおりです。

1. 次のパラメータをimgタグに追加します。
cookieid: ビジターID

newvisitor: ユーザーがすでにそのサイトを訪問したことがあるかどうかを判別します。

2. cookieidパラメータの名前を(たとえばvisitoridに)変更する必要がある場合、次のことも実行する必要があります。

1. global.xmlの次の行を、その後に示すように変更します。
変更前:

<alias name="cookieid" for="cookieid"/>

変更後:

<alias name="visitorid" for="cookieid"/>

2. visitoridおよびnewvisitorパラメータをimgタグに渡します。

29.2.2 Sessionfingerprintメソッド

Sessionfingerprintメソッドは、IPアドレス、画面解像度、およびセッションをビジターに割り当てるエージェント文字列の組合せによって各ビジターを識別します。Sessionfingerprintは、すべてのサイトに対して有効化することも、選択したサイトに対して有効化することもできます。Sessionfingerprintは、Analyticsが最初にインストールされたときはデフォルトですべてのサイトに対して有効化されています。

注意:

Sessionfingerprintメソッドは、新規のビジター・トラッキングをサポートしていません。

sessionfingerprintメソッドを有効化する手順は、次のとおりです。

- すべてのサイトのビジター・トラッキングを有効化するには、次の太字の行をglobal.xmlに追加します(次に示すようにデフォルトの<params> ... </params>タグ内にそれらをネストします)。

<params host="default">
<param type="string" name="sessionIdGenerator"
value="AppServerId"/>
<param type="string" name="visitorIdGenerator"
value="SessionfingerprintId"/>
...
</params>

- 選択したサイトのビジター・トラッキングを有効化するには、太字の行をglobal.xmlに追加します(次に示すように<root>タグ内にそれらをネストします)。

<root>
<params site="sitename">
<param type="string" name="sessionIdGenerator"
value="AppServerId"/>
<param type="string" name="visitorIdGenerator"
value="SessionfingerprintId"/>
</params>

<params host="default"> ...

表29-1は、Sessionfingerprintビジター・トラッキングのパラメータを示しています。

表29-1 Sessionfingerprintビジター・トラッキングのパラメータ

パラメータ

説明

sessionIdGenerator

セッションの識別に使用されるIDジェネレータを指定します。

注意: デフォルト値はAppServerIDです。この値は修正しないでください。それは、IDを生成するオブジェクトへの参照です。

visitorIdGenerator

サイトのビジターの識別に使用されるIDジェネレータを指定します。

このメソッドに必要な値:

SessionfingerprintId

site

imgタグを介して渡されるサイトの名前

29.2.3 Cookieメソッド

Cookieメソッドを使用すると、ビジター・トラッキングをすべてのサイトにわたって有効化することも、選択したサイト内で有効化することもできます。

Cookieメソッドを有効化する手順は、次のとおりです。

- すべてのサイトのビジター・トラッキングを有効化するには、次の太字の行をglobal.xmlに追加します(次に示すようにデフォルトの<params> ... </params>タグ内にそれらをネストします)。

注意:

次のコードを使用する場合は、サンプル値を自身の値に置き換えてください。パラメータ定義は、第29.2.3項の「Cookieベースのビジター・トラッキングのパラメータ」を参照してください。

<params host="default">
<param type="string" name="visitorIdGenerator"
value="CookieId"/>
<param type="string" name="visitorIdCookieName" value="visid"/>
<param type="string" name="visitorIdCookieMaxAge"
value="31536000"/>
<param type="string" name="visitorIdCookieDomain" value="firstsiteii"/>
<param type="string" name="visitorIdCookiePath" value="/"/>
<param type="string" name="visitorIdCookieSecure"
value="false"/>
...
</params>

- 選択したサイトのビジター・トラッキングを有効化するには、太字の行をglobal.xmlに追加します(次に示すように<root>タグ内にそれらをネストします)。

注意:

次のコードを使用する場合は、サンプル値を自身の値に置き換えてください。パラメータ定義は、第29.2.3項の「Cookieベースのビジター・トラッキングのパラメータ」を参照してください。

<root>
<params site="FirstSiteII">
<param type="string" name="sessionIdGenerator" value="AppServerId"/>
<param type="string" name="visitorIdGenerator" value="CookieId"/>
<param type="string" name="visitorIdCookieName" value="visid"/>
<param type="string" name="visitorIdCookieMaxAge" value="31536000"/>
<param type="string" name="visitorIdCookieDomain" value=".firstsiteii.at"/>
<param type="string" name="visitorIdCookiePath" value="/"/>
<param type="string" name="visitorIdCookieSecure" value="false"/>
</params>
<params host="default">
...

表29-2は、Cookieベースのビジター・トラッキングのパラメータを示しています。

表29-2 Cookieベースのビジター・トラッキングのパラメータ

パラメータ

説明

sessionIdGenerator

セッションの識別に使用されるIDジェネレータを指定します。

注意: デフォルト値はAppServerIDです。この値は修正しないでください。それは、IDを生成するオブジェクトへの参照です。

visitorIdGenerator

サイトのビジターの識別に使用されるIDジェネレータを指定します。

このメソッドに必要な値: CookieId

visitorIdCookieName

クライアント・サイドに設定されているCookieの名前。

例: visid

visitorIdCookieMaxAge

ミリ秒単位のCookieの経過時間。この時間の経過後は、そのCookieは無効です。(設定した値は、現在の時間に追加されます。)

例: 31536000

visitorIdCookieDomain

Cookieを設定する必要があるドメイン。

例: firstsiteii

注意: ローカル・ホストにvisitorIdCookieDomainを設定する場合は、localhost値を使用しないでください。それは、大部分のブラウザで受け入れられません。かわりに、ホスト・ファイルに次のタイプのエントリを追加します。

例:

127.0.0.1 firstsiteii.at

さらに、futuretense_xcel.iniのanalytics.datacaptureurlを次のように変更します。

http\://firstsiteii.at\:8081/sensor/statistic

visitorIdCookiePath

Cookieを設定する必要があるサブパス。

例: "/"

visitorIdCookieSecure

CookieがSSL接続など安全なチャネルで送信されることを指定します。デフォルト値(false)を変更しないでください。

site

imgタグを介して渡されるサイトの名前

例: FirstSite II

30 Analyticsインストールの検証

この章では、新しくインストールされたAnalyticsアプリケーションおよびそのコンポーネントの動作を検証する手順を説明します。

この章の内容は、次のとおりです。

- 第30.1項「検証手順」

- 第30.2項「推奨構成」

- 第30.3項「次のステップ」

30.1 検証手順

この項では、Hadoop、HDFSエージェントおよびHadoopジョブを起動し、次の手順を完了します。

- データ取得が機能していることを検証します。

- HDFSエージェントを検証します。

- Hadoopジョブを検証します。

- Analyticsレポート作成インタフェースを表示可能であることを検証します。

- Analytics管理者インタフェースを表示可能であることを検証します。

Analyticsインストールを検証する手順は、次のとおりです。

1. Hadoopを起動します。

2. HDFSエージェントを起動します(binフォルダにあるrun.shを実行します)。

cd ${ANALYTICS_HOME}/hdfsagent/bin
chmod +x run.sh
./run.sh

ANALYTICS_HOMEは、Analyticsインストール・ディレクトリです。

3. Hadoopジョブを起動する前に、次のように実行して、Hadoopジョブの動作が中断されないようにします。

1. ファイル/etc/security/limits.confを編集します。

2. soft nofileおよびhard nofileの値を65536に変更します。

3. Hadoopが実行される新しいシェルを開きます。ulimit -nが少なくとも1024であることを確認します。

4. Hadoopジョブを起動します(binフォルダにあるrun.shを実行します)。

注意:

Hadoopの起動時にHadoopジョブ・スケジューラが実行されるようにするためには、JVMに少なくとも512MBのメモリーがあることが必要です。メモリーが不十分な場合は、メモリー・パラメータ-Xmx512mをHadoopジョブのrun.shファイルに追加します。

Hadoopジョブ・スケジューラはHDFSのマスターであるため、そのスケジューラを再起動するときはすべてのHDFSエージェントを再起動する必要があります。

cd ${ANALYTICS_HOME}/hadoop-jobs/bin
chmod +x run.sh
./run.sh

5. データ取得が機能していることを検証します。

1. アプリケーション・サーバーが、Analytics Sensorがインストールされているサーバー上で実行されていることを確認します。

2. verify_installユーティリティを実行し、Analytics SensorのURLにアクセスします。複数サーバーのインストールの場合、すべてのデータ取得サーバー上でverify_installユーティリティを実行します。(verify_installユーティリティには、Hadoopジョブをテストするためのサンプル・オブジェクト・インプレッションが含まれています。)

- UNIX:

./analytics_install.sh verify_install

- Windows:

analytics_install.bat verify_install

システムによって、プレビュー・サムネイルが(1x1ピクセルのgifファイルとして)返されます。受信RAWデータが、Analytics Sensorによってdata.txt.tmpファイルに書き込まれます(図30-1を参照)。

図30-1 取得済データのストレージ

data.txt.tmpファイルは、ローカル・ファイル・システムのフォルダに格納されます。そのフォルダは、global.xmlのlogwriterエレメント(rootpath属性)で指定されます(表28-3を参照)。しきい値の間隔に到達するか(表28-1のsensor.thresholdプロパティを参照)、アプリケーション・サーバーが再起動したときに、センサーによってdata.txt.tmpファイルがdata.txtにローテーションされます。

たとえば、フォルダが<logwriter type="LFS" name="LFS" rootpath="C:/analytics/data" />として指定されている場合、RAW取得データは図30-1に示す、/analytics/data/フォルダから開始するフォルダ構造に書き込まれます。RAWデータは、data.txt.tmpに収集され、ローテーション後に、data.txtに格納されます。oirawdataおよびsesrawdataというフォルダは、システム・デフォルトです。

6. HDFSエージェントを検証します。

1. HDFSエージェントがdata.txt (およびそのディレクトリ構造)をローカル・ファイル・システムからHDFSに正常のコピーしたことを確認します。HDFSエージェントは、data.txtを次のように処理します。

- ローカル・ファイルシステムからHDFSのフォルダにdata.txtファイルをコピーします。そのHDFSフォルダは、global.xmlのhadoop.hdfs.defaultfsパラメータによって指定されています(表28-1を参照)。

- data.txtが正常にコピーされると、それはローカル・ファイル・システムから削除されます。

2. HDFSエージェントのアクションを検証し、ファイル・システムを調査するには、マスター・ノード上で実行されているHadoop HDFS Webインタフェース(http://<hostname_MasterNode>:50070/)を開き、そのフォルダを参照します。

7. Hadoopジョブを検証します。

Hadoopジョブは、HDFSエージェントによってローカル・ファイル・システムからHDFSにコピーされたデータを処理します。そのジョブのステータスを表示するには、次のJobTracker WebインタフェースURLを開きます。

http://<hostname_MasterNode>:50030/

JobTracker Webインタフェースの「RUNNING Jobs」セクションにOIProcessorジョブが表示されます。OIProcessorジョブが完了すると、OIInjectionジョブが開始され、そのデータがAnalyticsデータベースに挿入されます。

注意:

一連のセッションおよびビジター・ジョブも実行されます。ジョブが完了したら、それらのステータスがAnalytics管理者アプリケーションの「ステータス・サマリー」パネルに表示されます。管理者アプリケーションにログインするときに、9のジョブを検証します。

8. Analyticsレポート作成インタフェースを表示可能であることを検証します。

次のURLにあるAnalyticsレポート作成アプリケーションに、ユーザー名csuserおよびパスワードcsuserでログインします。

http://<hostname:port>/analytics

ここで、<hostname>は、レポート作成アプリケーションがインストールされているサーバーのホスト名です。

注意:

csuser (パスワードcsuser)は、Analyticsの出荷時のデフォルトです。このユーザーはAnalyticsの管理権限を持っています。Analytics管理インタフェースで作業する必要がある場合は、csuser/csuserとしてログインします(たとえば、『Oracle Fusion Middleware WebCenter Sites: Analytics管理者ガイド』の「Oracle WebCenter Sites: AnalyticsとOracle Web Center Sitesとの統合」の章では、AnalyticsをWebCenter Sitesと統合します)。

データベース接続に失敗した場合は、その事実を示すメッセージが表示されます。

9. Analytics管理者インタフェースを表示可能であることを検証します。

次のURLにあるAnalytics管理者アプリケーションに、ユーザー名csuserおよびパスワードcsuserでログインします。

http://<hostname:port>/analyticsadmin

ここで、<hostname>は、管理者アプリケーションがインストールされているサーバーのホスト名です。

開く画面(図30-2)には、場所とプロセッサの「ステータス・サマリー」パネルが表示されます。

図30-2 Analytics管理者インタフェース(「コンポーネント」タブの「概要」オプション)

「図30-2 Analytics管理者インタフェース(「コンポーネント」タブの「概要」オプション)」の説明

ここで、様々なコンポーネントのステータスを監視できます。例:

- Analytics Sensorを監視して、それが機能しており、サイト・トラフィックに適切にレスポンスしていることを確認できます。(センサーの監視とアラートへの反応の詳細は、「センサーの過負荷アラート」を参照してください。)

- Analytics Sensorを停止できます。

- 場所またはプロセッサをクリックしてそのステータスを表示することで、Hadoopジョブを検証できます。(Hadoopジョブおよび「ステータス・サマリー」パネルの詳細は、『Oracle Fusion Middleware WebCenter Sites: Analytics管理者ガイド』の「リファレンス: Hadoopジョブのプロセッサと場所」の章を参照してください。)

30.2 推奨構成

- インストーラ・ファイル

- センサーの過負荷アラート

- Geolocationデータベース

30.2.1 インストーラ・ファイル

Analyticsインストールを検証したら、インストーラ・ファイルをそれぞれのホストに保持します。後で、運用パラメータの変更が必要になった場合に、そのインストーラを再実行できます。運用パラメータの手動による変更はお薦めいたしません。

インストーラ・ファイルは次のとおりです。

- libは、サイレント・インストーラを実行するときにそれをサポートするために必要な追加のjarファイルがすべて含まれているフォルダです。

- analytics-build.propertiesには、Analytics製品をシステムにどのようにインストールするのかを定義するすべてのプロパティが含まれています。

- analytics-build.xmlは、サイレント・インストールを実行するためのAntでビルドされたスクリプトです。

- analytics_install.batは、Windowsコマンド・ウィンドウでサイレント・インストーラを実行するバッチ・ファイルです。

- analytics_install.shは、サイレント・インストーラを実行するUNIX/Linuxシェル・スクリプトです。

- analytics-silent-install.jarには、サイレント・インストーラに必要なカスタムJavaクラスがすべて含まれています。

- log4j.propertiesは、実行時の出力ターゲット、メッセージのタイプおよびレベル、メッセージの書式などのロギング動作を構成するために使用されます。

30.2.2 センサーの過負荷アラート

大量のサイト・トラフィックにより、Analytics Sensorは、受信データで過負荷になり、正常に反応しなくなることがあります。Analytics Sensorは、ファイル・システムへの書込みを停止し、メモリー不足状態になるまで、かわりにメモリーに受信データを格納します。

Analytics管理者インタフェース(図30-2)で、Analytics Sensorボタンが黄色または赤で表示され、過負荷状態がアラートされます。黄色は、WARNING状態を示します。赤は、CRITICAL状態を示します(センサーが実行されていると想定)。

注意:

停止または機能していないAnalytics Sensorも、赤で表示されます。

30.2.2.1 過負荷アラートのしきい値の設定

global.xmlのプロパティによって、WARNINGまたはCRITICAL状態をトリガーするしきい値が決まります。そのプロパティはsensor.requestqueue.warnsizeおよびsensor.requestqueue.maxsizeです。これらのプロパティを、Analyticsインストールの構成およびサイト・トラフィックの量に適したしきい値に設定します。これらのプロパティの詳細は、表28-1を参照してください。

30.2.2.2 赤状態への対処

「ステータス・サマリー」(管理インタフェース、図30-2)を監視していて、Analytics Sensorボタンが赤く表示されていることに気づいた場合、センサーが停止しているのか、障害が発生しているのか、過負荷になっているのかを判別する必要があります。過負荷の場合、システムをリセットして正常な動作を再開するには、メモリーをクリアする必要があります。メモリーからクリアされたデータは、取得できなくなり、失われます。

赤の状態に対処する手順は、次のとおりです。

Analytics Sensorボタンをクリックし、メイン・パネルに注意します。

- "No data available"と表示されていたら、Analytics Sensorは停止しているか障害が発生しています。

- 「センサーの詳細」パネルが表示されていたら、Analytics Sensorは実行中ですが過負荷になっています。「リテンション・ポンドのクリア」というラベルが付いたアイコンをクリックし、メモリーをクリアします(図30-3)。

図30-3 リテンション・ポンド

30.2.3 Geolocationデータベース

GeoLite Cityは、MaxMindによって提供されている高度に最適化された地理位置情報データベースです。GeoLite Cityは、高速検索を実行するためにバイナリ形式になっています。これは、Analyticsによって、それに含まれている情報(国、地域、地域コード、メトロ・コード、市区町村および郵便番号)のために使用されます。GeoLite Cityデータベースは毎月、月の初めにMaxMindによって更新されます。

最新のGeoLite Cityデータベースをインストールする手順は、次のとおりです。

1. 次の場所から、バイナリ形式のGeoLite Cityデータベースをダウンロードします。
http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz

2. 次のようにファイルを解凍します。

- Windowsの場合: winzipまたはzipプログラムを使用して、ファイルを解凍します。

- UNIXの場合: tarコマンドを使用してファイルを解凍します。

tar xvzf GeoLiteCity.dat.gz

3. GeoLiteCity.datファイルを、Hadoopジョブ・アプリケーションがインストールされているサーバー上のAnalyticsインストール・フォルダの下のCACHEフォルダにコピーします。
UNIXの場合:

cp GeoLiteCity.dat <ANALYTICS_INSTALL_DIR>/CACHE

30.3 次のステップ

この章のすべての手順を正常に完了すると、AnalyticsをWebCenter Sitesと統合してデータ取得およびレポート生成を有効化する準備が整います。

Analyticsの統合および有効化は、管理者と開発者の共同作業です。

- 管理者は、Analyticsにページおよびその他のアセット・タイプを登録し、それらが認識されてレポートに含まれるようにします。また、管理者は、レポートを生成する権限をユーザーに付与します。

- 開発者は、パブリッシュされたページでのデータ取得を有効化し、デフォルトHadoopジョブのセットによってRAWデータが処理されて、取得結果がレポートに格納されることを検証することで、レポートにデータが必ず埋め込まれるようにします。

統合、データ取得およびデータ処理の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』および『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。

第VIII部

Oracle WebCenter Sites: Content Integration Platformのインストール

第VIII部は、次の章で構成されています。

- 第31章「ファイル・システムおよびMicrosoft SharePointに対するContent Integration Platformのインストール」

- 第32章「Content Integration Platform for EMC Documentumのインストール」

31 ファイル・システムおよびMicrosoft SharePointに対するContent Integration Platformのインストール

この章では、ファイル・システムおよびMicrosoft SharePointシステムからWebCenter SitesへのパブリッシュをサポートするためのContent Integration Platformのインストールおよび構成手順について説明します。

この章の内容は、次のとおりです。

- 第31.1項「インストールの概要」

- 第31.2項「Content Integration Platformのインストール」

- 第31.3項「インストールの検証」

- 第31.4項「本番データのパブリッシュ」

31.1 インストールの概要

この項の内容は、次のとおりです。

- 第31.1.1項「前提条件」

- 第31.1.2項「パッケージ化」

- 第31.1.3項「ファイルのインストール先」

31.1.1 前提条件

- Microsoft Visual C++ 2008再配布可能ファイル(x86)。http://www.microsoft.comからダウンロードできます。

- OpenSSL。http://www.openssl.orgからダウンロードできます。

31.1.2 パッケージ化

Content Integration Platformは、次のファイルのセットとして配布されます。

ファイル

説明

cipagent-vNo.msi (Windowsの場合) cipagent-vNo.rpm.bin (Linuxの場合)

これらのファイルによって、Content Integration Agent (CIPCommanderおよびservice)と、そのエージェント・プロセスの制御に使用される構成ファイルがインストールされます。

csagentservices.war

このファイルによって、ログ・ファイルの詳細の設定およびWebCenter Sitesデータベースへのアクセスの制限に使用されるプロパティ・ファイルを含むSites Agent Servicesがインストールされます。

cs_filesystem_schema.zip

このファイルによって、FileSystemフレックス・ファミリがインストールされます。

cs_sharepoint_schema.zip

このファイルによって、SharePointフレックス・ファミリがインストールされます。

31.1.3 ファイルのインストール先

Content Integration Platformは、ネイティブ実行可能ファイルを使用します。

Content Integration Platformをインストールする手順は、次のとおりです。

1. Content Integration Agentを、サポートされているオペレーティング・システムを実行しており、かつソースとターゲットの両方のシステムにアクセスできる任意のコンピュータにインストールします。

注意:

このリリースのサポートされているシステムの詳細は、Oracle WebCenter Sites動作保証マトリックスを参照してください。

2. csagentservices.warを、WebCenter Sites Sharedディレクトリにアクセスできるシステムにデプロイします。
WebCenter Sitesシステムは、完全に機能している必要があります。それが、本番(配信)システムではないことが必要です。

3. WebCenter Sitesに該当するスキーマをインストールします。

- cs_filesystem_schema.zip

- cs_sharepoint_schema.zip

完全なインストール手順は、第31.2項「Content Integration Platformのインストール」に記載しています。

31.2 Content Integration Platformのインストール

注意:

インストール・プロセスを問題なく実行するため、次の手順をお読みになり、インストール手順および入力を求められる情報を理解してください。「ステップ3: WebCenter Sitesにスキーマをインストールする」を効率的に完了するには、経験を積んだWebCenter Sites管理者である必要があります。

この項では、次の手順を完了します。

- ステップ1: Content Integration Agentをインストールする

- ステップ2: Sites Agent Servicesをインストールする

- ステップ3: WebCenter Sitesにスキーマをインストールする

31.2.1 ステップ1: Content Integration Agentをインストールする

1. Windowsオペレーティング・システムを使用している場合は、Content Integration Agentをホストする同じコンピュータにMicrosoft Visual C++ 2008再配布可能パッケージ(x86)をインストールします。(この再配布可能パッケージは、Microsoft Webサイトからダウンロードできます。)

2. cipagentファイルを、サポートされているオペレーティング・システムを実行しており、かつソースとターゲットの両方のシステムにアクセスできるコンピュータで実行します。

- Windows:
cipagent-11.1.1.6.0-36.msiを実行し、画面上の手順に従います。11.1.1.6.0 CIPエージェント・インストーラは、エージェント・フォルダのCIP 11.1.1.6.0インストール・バイナリにあります。

ターゲット・ディレクトリに次のフォルダが作成されます。

bin
cipagent.exe
cipcommander.exe
conf
..all conf files
security
..all certificates and private keys
logs
..log file
licenses
..licenses

- Linux:
11.1.1.6.0 CIPエージェント・インストーラは、エージェント・フォルダのCIP 11.1.1.6.0インストール・バイナリにあります。

rootユーザーとしてソース・システムで次のコマンドを実行します。

./cipagent-11.1.1.6.0-38.el5.i386.rpm.bin

このコマンドによって、次のディレクトリがインストールされます。

usr
local
bin
cipagent -exe
cipcommander
lib
cipagent
..all librariesshare
share
cipagent
conf
security
logs
licenses

3. 構成ファイルcatalog.xml ([path_to_cipagent]/conf/にある、Linuxの場合は/usr/local/share/conf/)をバックアップします。

4. catalog.xmlを編集します。
catalog.xmlファイルには、ソース・システムおよびWebCenter Sitesに接続するためにContent Integration Agentが必要とする構成設定が格納されています。このファイルを編集し、Content Integration Agentにシステムの場所およびユーザー情報を提供します。

1. テキスト・エディタを使用して、catalog.xmlを開きます。

2. Oracle WebCenter Sitesのアダプタを編集します。
csという名前で、70b1e307-26a1-499c-9295-cf0b6bd01342というIDを持つプロバイダ・エレメントを見つけ、次のパラメータを設定します。

- urlAS: WebCenter SitesとともにデプロイされるWebサービス・モジュールを指します。ホスト名およびポートのみ、変更する必要があります。通常、それらは、WebCenter Sitesが実行されているホストの名前およびポートです。コンテキスト名およびコンテキスト関連パスは、それらがデフォルト(http://localhost:8080/csagentservices/InfostoriaService)と異なることがわかっている場合以外は変更しないでください。

- username: WebCenter Sitesデータベース表を変更する権限を持つアカウントのユーザー名(たとえば、一般管理者のfwadmin)。

- password: 前述のユーザーのパスワード(たとえば、ユーザー名がfwadminであるとすると、xceladmin)。

- context: これは空白のままにします。

3. Microsoft SharePointを使用している場合は、そのSharePointインストールのアダプタを編集します。
sharepointという名前で、7137dd5d-9ed7-4327-b4fd-8caeebd5889aというIDを持つプロバイダ・エレメントを見つけ、次のパラメータを設定します。

- urlSharepoint: パブリッシュ元となるSharePointサイトを指すURL。通常、ホスト名(デフォルト値はhttp://localhost)のみ変更する必要があります。

- username: パブリッシュ可能なコンテンツに対する権限を持つアカウントのユーザー名。

- password: 前述のユーザーのパスワード。

4. catalog.xmlを保存します。

5. Content Integration Agent実行可能ファイルを再起動します。

- Windows: Content Integration Agentサービスを再起動します。

- Linux: rootユーザーとして次のように入力します。/sbin/service cipagent restart

注意:

Content Integration Agent実行可能ファイルは、スタンドアロン・プロセスとしてもシステム・デーモンとしても実行できます。この実行可能ファイルによって、デフォルト・ポート7070 (Content Integration AgentとのCIPCommander通信のために予約されている)上でシンプルなHTTPサーバーが起動されます。ポート7070は、localhostにバインドされているため、システムが追加のセキュリティ・リスクにさらされることはありません。fileserver機能のデフォルト構成は、ポート7071を使用し、ホスト名の自動検出を試みます。エージェントが実行されているマシンに複数のネットワーク・インタフェースがインストールされている場合は、autoを、Sites Agent Servicesインストールからアクセス可能なDNS名またはIPアドレスに変更することをお薦めします。ポートを変更する必要がある場合、facilities.xmlのポート指定を編集し、-p <port>をCIPCommanderを起動するすべてのコマンドに追加します。

6. 次のステップである「ステップ2: Sites Agent Servicesをインストールする」に進みます。

31.2.2 ステップ2: Sites Agent Servicesをインストールする

注意:

Sites Agent Servicesは、本番(配信)以外のどのようなのWebCenter Sitesシステムにインストールできます。コンテンツ管理(ステージング)システムをお薦めします。

1. csagentservices.war内の次のファイルを編集します(それらのファイルはすべて、csagentservices/WEB-INF/classes内に配置されています)。

- commons-logging.properties: ログ・ファイルおよびログの詳細設定を定義します。

- csAgentServices.properties: WebCenter Sitesデータベースへのアクセスを有効化します。

1. テキスト・エディタを使用して、Agent Servicesログ・ファイル(agentservices.log)を指すようにcommons-logging.propertiesを編集します。

2. アプリケーション・サーバー固有のデータ・ソースを作成します(詳細は、第I部「Oracle WebCenter Sitesのインストール」を参照してください。)

3. csAgentServices.propertiesを変更し、WebCenter Sitesデータベースへのアクセスを有効化します。
テキスト・エディタを使用して、次のプロパティを設定します。

- uploader.username: フレックス・ファミリを編集する権限を持つアカウントのユーザー名。

- uploader.password: 指定したユーザー名のパスワード。

- cs.installDir: WebCenter Sitesインストール・ディレクトリ(たとえば、C:\CS)。

- cs.url: WebCenter Sites URL。WebCenter Sites Webアプリケーションを指します。デフォルト値は、http://localhost:8080/csです。

csAgentServices.propertiesを保存します。

2. WebCenter Sitesホスト上のアプリケーション・サーバーにcsagentservices.warをデプロイします。

3. アプリケーション・サーバーを再起動します。

4. 次のステップである「ステップ3: WebCenter Sitesにスキーマをインストールする」に進みます。

31.2.3 ステップ3: WebCenter Sitesにスキーマをインストールする

この手順では、次に示す適用可能なzipファイルをWebCenter Sitesにインポートします。

- cs_filesystem_schema.zip

- cs_sharepoint_schema.zip

スキーマをインストールする手順は、次のとおりです。

1. WebCenter Sitesインストール・ディレクトリからcatalogmover.bat (またはLinux上のcatalogmover.sh)を実行します。

注意:

CatalogMoverを使用するには、それをWebCenter Sitesに接続する必要があります。

1. 「Server」→「Connect」を選択します。

2. 次の情報を指定します。
Server: 接続先のHTTPサーバーの名前、およびそのサーバーが実行されているポート。

Name: ContentServer

Password: <password>

「Password」フィールドの下で、ご使用のWebCenter Sitesインストールに適用する値を選択(または入力)します。

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

2. 「Catalog」→「Auto Import Catalog(s)」に移動します。

1. インポートするファイルを選択します。

2. インポート・ダイアログで、次に示すフィールドに入力します。
Catalog Data Directory: デフォルト値のままにします。

Catalog ACL List: Browser,SiteGod,xceleditor,xceladmin

3. 必要に応じて、残りのファイルをインポートします。

3. 一般管理者(デフォルトではfwadmin/ xceladmin)を使用してWebCenter Sites管理インタフェースにログインし、次のように続行します。

1. 既存のコンテンツ管理サイトに対して各インポート済フレックス・ファミリを有効化します(フレックス・ファミリ・メンバーの名前は、ソース・システムの名前で始まります)。フレックス・ファミリに対して新しいサイトを作成することもできます。

2. パブリッシュ済コンテンツに簡単にアクセスできるようにするために、ツリー・タブ(たとえば、「FileSystem」タブや「SharePoint」タブ)を作成します。

フレックス・ファミリの有効化、サイトの作成およびツリー・タブの作成の手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

4. 次のステップである「ステップ4: (オプション)イベント通知の構成」に進みます。

31.2.4 ステップ4: (オプション)イベント通知の構成

CIP管理者にソース・システムでのイベントおよびそれらの同期について通知する必要がある場合は、インストール担当者(または管理者)が次のサンプル・ワークフローのいずれかまたはすべてを有効化できます。

注意:

次のワークフローは、アセットのパブリッシュ前にインストールし、有効化する必要があります。CIPAssetDeletedおよびCIPAssetDeletionFailed

サンプル・ワークフローのインストールの詳細および手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の「イベント通知の構成」の章を参照してください。

31.3 インストールの検証

この手順では、WebCenter Sitesにテスト・フォルダをパブリッシュします。テスト・フォルダのコンテンツを追加、削除および変更することで、同期プロセスも検証します。

CIPのインストールを検証する手順は、次のとおりです。

1. mappings.xml (Content Integration Agentをホストしているサーバー上にある)をバックアップします。

2. デフォルト・メタデータ(デフォルトmappings.xmlファイルで定義されたもの)を使用してテスト・フォルダを選択(または作成)します。つまり、次のようになります。

- そのフォルダ・タイプは、mappings.xmlのフォルダ・タイプに一致します(クイック・リファレンスは、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の表「デフォルトでサポートされているソースシステム・メタデータ」を参照してください。

- そのテスト・フォルダには、mappings.xml内のものと一致するフォルダ・タイプ、ドキュメント・タイプおよび属性を持つサブフォルダおよびドキュメントが含まれています(詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください)。

注意:

Microsoft SharePointシステムからパブリッシュ・プロセスを検証している場合は、mappings.xml (または『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の表1-1「デフォルトでサポートされるソースシステム・メタデータ」を参照)を使用してドキュメント・ライブラリおよびピクチャ・ライブラリの両方に対してテストを実行し、デフォルト・コンテンツ・タイプおよび属性を判別します。

3. パブリッシュ・プロセスをテストします。手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

4. サブフォルダおよびドキュメント(SharePointのピクチャを含む)を名前変更、移動、削除および作成することで、同期プロセスをテストします。属性を削除および追加することでそれらをテストします。(属性を追加するときは、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の「再マップ」の章の手順に従ってください。)

5. unpublishコマンドを実行することでアンパブリッシュ・プロセスをテストします(『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください)。

31.4 本番データのパブリッシュ

オブジェクトをパブリッシュする最も迅速な方法は、デフォルトmappings.xmlファイルおよびCIPで提供されるフレックス・ファミリを使用することです。ソース・システムの構成に応じて、次のいずれかの操作を行います。

- オブジェクトのスキーマがmappings.xmlのデフォルト・スキーマおよびデフォルト・フレックス・ファミリと一致している場合、そのオブジェクトはパブリッシュする準備ができています。『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の「パブリッシュ」の章の手順に従ってください。

- オブジェクトは、それらのスキーマがmappings.xmlのデフォルト・スキーマおよびデフォルト・フレックス・ファミリと異なる場合は、正常にパブリッシュできません。オブジェクトをパブリッシュする前に、スキーマを再マップしてください。これには、ソース・システムのフレックス・ファミリを更新し、mappings.xmlを再構成する必要があります。手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の「再マップ」の章を参照してください。

31.5 CIPインストールのカスタマイズ

Content Integration Platformは、多くの方法でカスタマイズできます。例:

- デフォルト・フレックス・ファミリをカスタム・シナリオに合わせて変更することも、それらをカスタム・フレックス・ファミリに置き換えることもできます。

- フレックス・ファミリにはフレックス・フィルタを追加できます。(フレックス・フィルタを実装する場合、対応するjarファイルを、WebCenter SitesとSites Agent Servicesの両方のアプリケーションに必ず追加してください。)

- 属性は、ソース・システム上で変更することも、ソース・システムに追加することもできます。

- 新規ドキュメント・タイプをソース・システムに追加できます。

- ソース・システムにおける変更に応じてWebCenter Sitesで発生した、または発生しなかったCIP関連のイベントを管理者に通知するために、ワークフローを実装できます。

CIPインストールのカスタマイズの詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』に記載されています。

32 Content Integration Platform for EMC Documentumのインストール

この章では、WebCenter SitesとDocumentumインストール間のコンテンツの転送をサポートするように、Content Integration Platform for EMC Documentumをインストールおよび構成する手順について説明します。

この章の内容は、次のとおりです。

- 第32.1項「インストールの概要」

- 第32.2項「前提条件」

- 第32.3項「パッケージ化」

- 32.4項「インストール手順」

- 第32.5項「次のステップ」

32.1 インストールの概要

Content Integration Platform for EMC Documentumによって、WebCenter SitesとEMC Documentumの間で、次のような双方向の通信が可能になります。

- WebCenter SitesへのEMC Documentumオブジェクトのパブリッシュ。

- EMC Documentum上へのWebCenter Sitesアセットのアーカイブ。

アーカイブ・プロセスでは、WebCenter SitesではなくCS DataStoreが、CIPによってデータのソースとして扱われます。CS DataStoreは、アセットがWebCenter Sitesからアーカイブが有効化されている宛先にパブリッシュされるときに作成されます。CS DataStoreは、そのファイル・システムにパブリッシュ済アセットを格納します。

CIPは、ソース・システムのメタデータをターゲット・システムに複製することで、パブリッシュおよびアーカイブをサポートします。したがって、ソース・システムのコンテンツを格納するスキーマはターゲット・システムに確立されます。ソース・システム上のコンテンツは、CIPコマンドライン・インタフェースおよびcipcommander publishコマンドを介してターゲット・システムに転送できます。パブリッシュ・セッションが終了すると、同期エンジンによって、コンテンツの変更について、ソース・システムのパブリッシュ済(またはアーカイブ済)ワークスペースの監視が開始され、変更されたコンテンツがターゲット・システムに自動的に複製されます。

この章では、要件に応じて、パブリッシュ、アーカイブまたはその両方のプロセスをサポートするようにCIPコンポーネントをインストールする方法を示します。

- パブリッシュまたはアーカイブをサポートするには、メタデータおよび関連するコンテンツを管理するContent Integration Agentをインストールする必要があります。Content Integration Agentには次のものが含まれています。

- mappings.xml。ソース・システムのメタデータをターゲット・システムにマップします。

- cipcommander。CIP publishコマンドの実行に使用されるコマンドライン・アプリケーション。同じコマンドで、WebCenter Sitesに(Sites Agent Servicesを介して)パブリッシュされ、Documentumにアーカイブされます。

- 同期エンジン。ソース・システムとターゲット・システムを一致した状態に保つために、ソースのパブリッシュ済(またはアーカイブ済)ワークスペースを監視します。

- catalog.xml。パブリッシュ済およびアーカイブ済アイテムに関する情報を格納し、同期プロセスを調整するために構成ファイルとして機能します。

- パブリッシュを有効化するには、プログラム的なパブリッシュ・インタフェースおよびパブリッシュ済オブジェクトをそれらのオブジェクト・タイプ定義も含めて格納するデータベース表をインストールします。

- このプログラム的インタフェースは、Sites Agent Servicesという名前であり、Content Integration AgentからDocumentumデータを取得し、WebCenter Sitesデータベース表に格納します。格納されるデータは、WebCenter Sites互換の書式のメタデータ、およびそのメタデータに関連付けられたオブジェクトで構成されています。

- パブリッシュ済オブジェクトを格納するためのデータベース表は、Documentumフレックス・ファミリ(WebCenter Sites管理システムにインストールされて、そのコンテンツ管理サイトの1つで有効化されている必要があるデータ・モデル)の形式です。デフォルトでは、Documentumフレックス・ファミリには、Documentumオブジェクト・タイプdm_folderおよびdm_documentの定義も含まれています。どちらのオブジェクト・タイプも、デフォルトmappings.xmlファイルでマップされています。

- アーカイブを可能にするために、Documentumにfw_assetおよびfw_documentオブジェクト・タイプをインストールし、DocumentumオブジェクトとしてWebCenter Sitesアセットを格納するためのスキーマを提供します。これらのオブジェクト・タイプは、デフォルトmappings.xmlでマップされています。

32.2 前提条件

Content Integration Platformをインストールする前に、次のように実行します。

- Oracle WebCenter Sites動作保証マトリックスおよびこのコンテンツ統合製品のリリース・ノートをダウンロードします。

- 次のものをダウンロードします。

- Microsoft Visual C++ 2008再配布可能ファイル(x86)(http://www.microsoft.comより入手)

- OpenSSL (http://www.openssl.orgより入手)

- この章をお読みになり、インストール手順を理解し、入力を求められる情報を書き留めてください。

- パブリッシュ操作用にCIPをセットアップする場合は、WebCenter Sitesステージング・システム上に、インストールするDocumentumフレックス・ファミリ用のコンテンツ管理サイトを作成または選択してください。

- アーカイブ操作では、CIPは、WebCenter Sites: Webエクスペリエンス管理(WEM)フレームワークを使用します。

- CIPインストール・プロセスの最後に、イベント通知を構成するオプションがあります。イベント通知の構成を選択する場合は、パブリッシュまたはアーカイブする前にそれを実行する必要があります。

次のインストール後のシナリオも考慮してください。WebCenter Sites配信システムが、Oracle WebCenter Sites: コミュニティ・アプリケーションを実行していて、サイト・ビジターのコメントおよびレビューをアーカイブする場合、それらのコメントおよびレビューを配信システムから別のWebCenter Sitesシステムにリアルタイム・パブリッシュする必要があります。システムでWEMフレームワークが実行されていることも必要です。手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

32.1.2 パッケージ化

Content Integration Platformは、次のファイルのセットとして配布されます。

ファイル

説明

cipagent-vNo.msi (Windowsの場合) cipagent-vNo.rpm.bin (Linuxの場合)

パブリッシュおよびアーカイブ用。これらのファイルによって、Content Integration Agent (CIPCommanderおよびservice)と、Content Integration Agentのプロセスのプロセスを制御する構成ファイルがインストールされます。

これらのファイルの1つを、サポートされるオペレーティング・システムを備え、ソースとターゲットの両方のシステムにアクセス可能なマシンにインストールする必要があります。

csagentservices.war

パブリッシュ用。このファイルによって、ログ・ファイルの詳細の設定およびWebCenter Sitesデータベースへのアクセスの制限のためのプロパティ・ファイルを含むSites Agent Servicesがインストールされます。

このファイルは、配信以外のシステムにデプロイする必要があります。そのシステムは、WebCenter Sites Sharedディレクトリにアクセスできる必要があります。

cs_documentum_schema.zip

パブリッシュ用。このファイルによって、指定したCMサイトのWebCenter SitesにDocumentumフレックス・ファミリがインストールされます。

documentum_cs_schema.dar

アーカイブ用。このファイルによって、Documentumシステムに、CS DataStoreのコンテンツをサポートするスキーマがインストールされます。

32.4 インストール手順

この項では、Content Integration Platform for EMC Documentumをインストールします。手順は次のとおりです。

- ステップ1. Content Integration Agentをインストールする

- ステップ2. CIPパブリッシュ・コンポーネントをインストールする

- ステップ3. Documentumへのアーカイブをサポートするスキーマをインストールする

- ステップ4. デフォルトmappings.xmlファイルをバックアップする

32.4.1 ステップ1. Content Integration Agentをインストールする

1. Windowsを使用している場合、Microsoft Visual C++ 2008再配布可能パッケージ(x86)をContent Integration Agentをホストするマシンにインストールします。

2. cipagentファイルを、サポートされるオペレーティング・システムを備え、ソースとターゲットのシステムにアクセス可能なマシン上で実行します。

- Windows:
cipagent-2.0.0-127.msiを実行し、プロンプトに従います。

ターゲット・ディレクトリに次のフォルダが作成されます。

bin
cipagent.exe
cipcommander.exe
conf
.. all conf files
security
.. all certificates and private keys
logs
..log file
licenses
..licenses

- Linux:
rootユーザーとしてソース・システムで次のコマンドを実行します。

./cipagent-2.0.0-128.el5.i386.rpm.bin

次のディレクトリがインストールされます。

usr
local
bin
cipagent -exe
cipcommander
lib
cipagent
..all libraries
share
cipagent
conf
security
logs
licenses

3. 構成ファイルcatalog.xml (integration_agent/conf/にある)をバックアップします。

4. catalog.xmlを編集します。
catalog.xmlファイルには、ソース・システムおよびOracle WebCenter Sitesに接続するためにContent Integration Agentが必要とする構成設定が格納されています。このファイルを編集し、Content Integration Agentにシステムの場所およびユーザー情報を提供します。

1. テキスト・エディタでcatalog.xmlを開きます。

2. Oracle WebCenter Sitesのアダプタを編集します。
csという名前で、70b1e307-26a1-499c-9295-cf0b6bd01342というIDを持つプロバイダ・エレメントを見つけ、次のパラメータを設定します。

- urlAS: WebCenter SitesとともにデプロイされるWebサービス・モジュールを指します。ホスト名およびポートのみ、変更する必要があります。通常、それらは、WebCenter Sitesが実行されているホストおよびポート番号を指定します。コンテキスト名およびコンテキスト関連パスは、それらがデフォルト(http://localhost:8080/csagentservices/InfostoriaService)と異なる場合以外は変更しないでください。

- username: WebCenter Sitesデータベース表を変更する権限を持つアカウントのユーザー名(たとえば、一般管理者のfwadmin)。

- password: 前述のユーザーのパスワード(たとえば、fwadminがユーザー名がであるとすると、xceladmin)。

- context: これは空白のままにします。

3. 次のように、EMC Documentumインストールのアダプタを編集します。
documentumという名前で、d7a96a63-e78c-407c-8d7f-e84988806e49というIDを持つプロバイダ・エレメントを見つけ、次のパラメータを設定します。

- urlDocumentum: Documentum Foundation Services (DFS)が実行されているサーバーを指すURL。コンテキスト名が含まれますが、コンテキスト関連パスは削除されます。通常、ホスト名(デフォルト値はhttp://localhost:9090)のみ変更する必要があります。

- username: パブリッシュ可能なコンテンツに対する権限を持つアカウントのユーザー名。

- password: 前述のユーザーのパスワード。

- filter: このパラメータには、パブリッシュする予定でないドキュメント・バージョンをフィルタ処理して除外するために適用されるwhere句が含まれています。たとえば、最新の承認済バージョンのドキュメントをパブリッシュするには、次のような値を指定します。
r_current_state = 1

-または-

r_policy_id = '0000000000000000'

(承認済状態は索引として1を持つことを考慮した場合)

4. catalog.xmlを保存します。

5. Content Integration Agent実行可能ファイルを再起動します。

- Windows: Content Integration Agentサービスを再起動します。

- Linux: rootユーザーとして次のように入力します。/sbin/service restart cipagent

注意:

Content Integration Agent実行可能ファイルは、スタンドアロン・プロセスとしてもシステム・デーモンとしても実行できます。この実行可能ファイルによって、デフォルト・ポート7070 (Content Integration AgentとのCIPCommander通信のために予約されている)上でシンプルなHTTPサーバーが起動されます。ポート7070は、localhostにバインドされているため、システムが追加のセキュリティ・リスクにさらされることはありません。fileserver機能のデフォルト構成は、ポート7071を使用し、ホスト名の自動検出を試みます。エージェントが実行されているマシンに複数のネットワーク・インタフェースがインストールされている場合は、autoを、Sites Agent Servicesインストールからアクセス可能なDNS名またはIPアドレスに変更することをお薦めします。ポートを変更する必要がある場合、facilities.xmlのポート指定を編集し、-p <port>をCIPCommanderを起動するすべてのコマンドに追加します。

6. facilities.xmlで、Javaの機能セクションを有効化します。ご使用のシステム上のJavaのパスを指定します。

7. 次のステップである第32.4.2項「ステップ2. CIPパブリッシュ・コンポーネントをインストールする」に進みます。

32.4.2 ステップ2. CIPパブリッシュ・コンポーネントをインストールする

アーカイブ機能のみをインストールする場合、第32.4.3項「ステップ3. Documentumへのアーカイブをサポートするスキーマをインストールする」にスキップします。それ以外の場合は、このセクションのすべての手順を完了し、パブリッシュ機能をインストールします。

32.4.2.1 A. Sites Agent Servicesをインストールする

注意:

Sites Agent Servicesは、配信以外のどのようなのWebCenter Sitesシステムにインストールできます。コンテンツ管理(ステージング)システムをお薦めします。

1. csagentservices.war内の次のファイルを編集します(それらのファイルはすべて、csagentservices/WEB-INF/classes内に配置されています)。

- commons-logging.properties: ログ・ファイルおよびログの詳細設定を定義します。

- csAgentServices.properties: WebCenter Sitesデータベースへのアクセスを有効化します。

1. テキスト・エディタを使用して、Sites Agent Servicesログ・ファイル(agentservices.log)を指すようにcommons-logging.propertiesを編集します。

2. アプリケーション・サーバー固有のデータ・ソースを作成します。(詳細は、ご使用のアプリケーション・サーバーへのWebCenter Sitesのインストールに関するガイドに記載されています。)

3. csAgentServices.propertiesを変更し、WebCenter Sitesデータベースへのアクセスを有効化します。

- テキスト・エディタを使用して、次のプロパティを設定します。
uploader.username: フレックス・ファミリを編集する権限を持つアカウントのユーザー名。

uploader.password: 前述のユーザー名のパスワード。

cs.installDir: WebCenter Sitesインストール・ディレクトリ(たとえば、C:\CS)。

cs.url: WebCenter Sites URL。WebCenter Sites Webアプリケーションを指します。デフォルト値は、http://localhost:8080/csです。

- csAgentServices.propertiesを保存します。

2. WebCenter Sitesのホスト上のアプリケーション・サーバーにcsagentservices.warをデプロイします。

3. アプリケーション・サーバーを再起動します。

4. 次のステップである第32.4.2.2項「B. Oracle WebCenter SitesにEMC Documentumスキーマをインストールする」に進みます。

32.4.2.2 B. Oracle WebCenter SitesにEMC Documentumスキーマをインストールする

この手順では、cs_documentum_schema.zipをWebCenter Sitesにインポートし、WebCenter SitesへのDocumentumオブジェクトのパブリッシュをサポートします。

Documentumスキーマをインストールする手順は、次のとおりです。

1. WebCenter Sitesインストール・ディレクトリからcatalogmover.bat (またはLinux上のcatalogmover.sh)を実行します。

注意:

CatalogMoverを使用する前に、WebCenter Sitesに接続し、「パスワード」フィールドの下で、ご使用のWebCenter Sitesインストールに適用する値を選択(または入力)します。

- 「Server」→「Connect」を選択します。

- 次の情報を指定します。
Server: 接続先のHTTPサーバーの名前、およびそのサーバーが実行されているポート。

Name:ContentServer

Password:<password>

- 「Connect」をクリックします。

2. 「Catalog」に移動し、「Auto Import Catalog(s)」を選択します。

1. インポートするファイルを選択します。

2. インポート・ダイアログで、次に示すフィールドに入力します。
Catalog Data Directory: デフォルト値のままにします。

Catalog ACL List: Browser、SiteGod、xceleditor、xceladmin

3. 一般管理者(デフォルトではfwadmin/ xceladmin)を使用してWebCenter Sitesの管理インタフェースにログインし、次のように続行します。

1. 第32.2項「前提条件」の説明のように、選択または作成したコンテンツ管理サイト上でDocumentumフレックス・ファミリを有効化します。

2. パブリッシュ済コンテンツに迅速にアクセスできるように、ツリー・タブ(たとえば、Documentumという名前のもの)を作成します。

フレックス・ファミリの有効化、サイトの作成およびツリー・タブの作成の手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

4. 次のステップである第32.4.3項「ステップ3. Documentumへのアーカイブをサポートするスキーマをインストールする」に進みます。

32.4.3 ステップ3. Documentumへのアーカイブをサポートするスキーマをインストールする

Documentum Composerを使用してdocumentum_cs_schema.darをインストールします(インストール手順およびユーザー情報は、『Documentum Composer User Guide』に記載されています)。

CREATE TYPE fw_asset (fw_id char(255),fw_name char(64),fw_createdby char(64),fw_createddate time,fw_description char(128),fw_publist char(255),fw_status char(2),fw_subtype char(32),fw_updatedby char(64),fw_updateddate time,fw_publisheddate time) WITH SUPERTYPE dm_document

CREATE TYPE fw_document (fw_publisheddate time,fw_name char(64)) WITH SUPERTYPE dm_document

32.4.4 ステップ4. デフォルトmappings.xmlファイルをバックアップする

mappings.xmlファイルは、Content Integration Agentをホストしているサーバー上にあります。

32.5 次のステップ

CIPをインストールしたら、必要に応じて、次の手順を完了します。

- Optional. ソース・システムの監視対象のワークスペース(つまり、パブリッシュ済またはアーカイブ済ワークスペース)内のデータに対する変更によって、ターゲット・システム上でトリガーされるイベントに関してCIP管理者に通知するためのイベント通知ワークフローを構成します。

注意:

イベント通知ワークフローの構成を選択する場合は、DocumentumオブジェクトをパブリッシュまたはWebCenter Sitesアセットをアーカイブする前にそれを実行する必要があります。イベント通知ワークフローの構成の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- DocumentumからWebCenter Sitesにパブリッシュするには、基本情報および手順について『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- WebCenter SitesアセットをDocumentumにアーカイブするには、基本情報および手順について『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

第IX部

リファレンス: バックアップとリカバリ

第IX部は、次の章で構成されています。

- 第33章「バックアップとリカバリ」

33 バックアップとリカバリ

このドキュメントの内容は次のとおりです。

- 第33.1項「バックアップとリカバリの前提条件」

- 第33.2項「バックアップとリカバリの手順」

- 第33.3項「リカバリ済WebCenter Sitesアプリケーションの実行」

33.1 バックアップとリカバリの前提条件

- WebCenter Sitesのどの部分であってもバックアップする前に、アプリケーション・サーバーを停止することが最も適切です。アクティブなWebCenter Sitesをバックアップする場合は、そのアクティブ・サイトが使用中でなく、そのアプリケーション・サーバーに対してリクエストが行われていないことを確認します。

- WebCenter Sitesのどの部分であってもリカバリする前に、アプリケーション・サーバーが停止していることを確認します。

33.2 バックアップとリカバリの手順

- 第33.2.1項「WebCenter Sitesインストール・ディレクトリ」

- 第33.2.2項「共有ディレクトリ」

- 第33.2.3項「Webアプリケーションの.warおよび.earファイル」

- 第33.2.4項「WebCenter Sitesのデータベース」(統計を除く)

- 第33.2.5項「LDAP」

33.2.1 WebCenter Sitesインストール・ディレクトリ

この項では、次の項目について説明します。

- 第33.2.1.1項「バックアップ」

- 33.2.1.2項「リカバリ」

33.2.1.1 バックアップ

WebCenter Sitesインストール・ディレクトリに対してjarまたはtarを実行します。

例:

tar –cvf ContentServer_backup.tar /u01/CS/Install
jar cvf ContentServer_backup.jar /u01/CS/Install

33.2.1.2 リカバリ

バックアップしたWebCenter Sitesインストール・ディレクトリに対してunjarまたはuntarを実行します。

例:

tar –xvf ContentServer_backup.tar
jar xvf ContentServer_backup.jar

33.2.2 共有ディレクトリ

この項では、次の項目について説明します。

- 第33.2.2.1項「バックアップ」

- 第33.2.2.2項「リカバリ」

33.2.2.1 バックアップ

注意:

Sharedディレクトリのバックアップは、それがWebCenter Sitesインストール・ディレクトリ内にあり、そのインストール・ディレクトリがバックアップ済である場合は不要です。

Sharedディレクトリをバックアップするには、そのディレクトリに対してjarまたはtarを実行します。

例:

tar –cvf Shared_backup.tar /u01/CS/Shared
jar cvf Shared_backup.jar /u01/CS/Shared

33.2.2.2 リカバリ

注意:

Sharedディレクトリのリカバリは、それがWebCenter Sitesインストール・ディレクトリ内にあり、そのインストール・ディレクトリがリカバリ済である場合は不要です。

Sharedディレクトリをリカバリするには、バックアップしたSharedディレクトリに対してunjarまたはuntarを実行し、それを使用して既存のものを置き換えます。

例:

tar –xvf Shared_backup.tar
jar xvf Shared_backup.jar

33.2.3 Webアプリケーションの.warおよび.earファイル

表33-1は、WebCenter Sites Webアプリケーションのどのタイプのファイルをバックアップし、リカバリする必要があるのかを示しています。

表33-1 .warおよび.earファイルのバックアップおよびリカバリ情報

.war/.earのデプロイメント・メソッド

バックアップ

リカバリ

非展開。

WebSphere上のWebCenter Sitesの場合

WebCenter Sitesインストール・ディレクトリがバックアップされている場合は不要です。

(.warおよび.earファイルは、WebCenter Sitesインストール・ディレクトリ<sites_install_dir>/ominstallinfo/app/に格納されています)

第33.2.3.2.1項「展開されていないファイルのリカバリ」の手順を参照してください。

展開済。

次の上のWebCenter Sitesの場合

- Tomcat

- WebLogic

ファイルに対するデプロイメントの変更がない場合脚注 1

次の場合、バックアップは不要です。

- デプロイメント中にファイルが変更されなかった

かつ

- WebCenter Sitesインストール・ディレクトリがバックアップされている

(.warおよび.earファイルは、WebCenter Sitesインストール・ディレクトリ<sites_install_dir>/ominstallinfo/app/に格納されています)

第33.2.3.2.2項「デプロイメントの変更がない、展開されたファイルのリカバリ」の手順を参照してください。

ファイルに対するデプロイメントの変更がある場合脚注 1

バックアップが必要です。第33.2.3.1.3項「デプロイメントの変更がある、展開されたファイルのバックアップ」の手順を参照してください。

第33.2.3.2.3項「デプロイメントの変更がある、展開されたファイルのリカバリ」の手順を参照してください。

脚注 1 「デプロイメントの変更」という用語は、コンテンツ、データ・モデル、テンプレート・コード、パブリッシュ先などに対する変更を意味します。

33.2.3.1 バックアップ

この項では、次の項目について説明します。

- 第33.2.3.1.1項「展開されていないファイルのバックアップ」

- 第33.2.3.1.2項「デプロイメントの変更がない、展開されたファイルのバックアップ」

- 第33.2.3.1.3項「デプロイメントの変更がある、展開されたファイルのバックアップ」

33.2.3.1.1 展開されていないファイルのバックアップ

表33-1を参照してください。

33.2.3.1.2 デプロイメントの変更がない、展開されたファイルのバックアップ

表33-1を参照してください。

33.2.3.1.3 デプロイメントの変更がある、展開されたファイルのバックアップ

デプロイされたWebCenter Sites Webアプリケーションに対してjarまたはtarを実行します。圧縮済cs.warファイルと区別するために、バックアップにラベルを付けます。

例:

tar -cvf cs_web_backup.tar /u01/software/Tomcat/webapps/cs
jar cvf cs_web_backup.jar /u01/software/Tomcat/webapps/cs

33.2.3.2 リカバリ

この項では、次の項目について説明します。

- 第33.2.3.2.1項「展開されていないファイルのリカバリ」

- 第33.2.3.2.2項「デプロイメントの変更がない、展開されたファイルのリカバリ」

- 第33.2.3.2.3項「デプロイメントの変更がある、展開されたファイルのリカバリ」

33.2.3.2.1 展開されていないファイルのリカバリ

1. WebCenter Sitesアプリケーションをアンデプロイします。

2. WebCenter Sitesインストール・ディレクトリをリカバリします(手順は、第33.2.1.2項「リカバリ」を参照)。

3. WebCenter Sitesアプリケーションを再デプロイします。

33.2.3.2.2 デプロイメントの変更がない、展開されたファイルのリカバリ

1. アプリケーション・サーバーを停止します。

2. 展開されたWebアプリケーションを削除します。
例:

rm -rf /u01/software/Tomcat/webapps/cs/*

3. WebCenter Sitesインストール・ディレクトリをリカバリします(手順は、第33.2.1.2項「リカバリ」を参照)。

4. バックアップしたWebCenter Sites Webアプリケーションに対してunjarを実行します。
例:

cd /u01/software/Tomcat/webapps/cs
jar xvf <sites_install_dir>/ominstallinfo/app/cs.war

33.2.3.2.3 デプロイメントの変更がある、展開されたファイルのリカバリ

1. アプリケーション・サーバーを停止します。

2. 展開されたWebアプリケーションを削除します。

rm -rf /u01/software/Tomcat/webapps/cs

3. バックアップしたWebCenter Sites Webアプリケーションに対してunjarまたはuntarを実行します。

cd /u01/software/Tomcat/webapps
tar -xvf <path to backup directory>/cs_web_backup.tar

33.2.4 WebCenter Sitesのデータベース

この項では、次の項目について説明します。

- 第33.2.4.1項「バックアップ」

- 第33.2.4.2項「リカバリ」

33.2.4.1 バックアップ

- 第33.2.4.1.1項「SQL Server 2008および2008R2のバックアップ」

- 第33.2.4.1.2項「Oracle 11gのバックアップ」

- 第33.2.4.1.3項「DB2 9.7のバックアップ」

33.2.4.1.1 SQL Server 2008および2008R2のバックアップ

1. SQL Server Management Studioを開きます。

2. データベース・サーバーに接続します。

3. 「Databases」を開きます。

4. バックアップするデータベースを右クリックします。「Tasks」→「Backup」をクリックします。

5. 「Backup type」の下の「Full」を選択します。「Destination」の下の「Add」をクリックします。

6. バックアップ・ファイルのパスおよびファイル名を入力します。「OK」をクリックします。

7. 「Destination」の下で、新しく作成したバックアップの場所を選択します。

8. 「OK」をクリックします。

33.2.4.1.2 Oracle 11gのバックアップ

1. oracleユーザーとしてサーバーにログインします。

2. ORACLE_HOMEをoracleデータベース・ディレクトリに設定し、ORACLE_SIDをデータベース名に設定します。

3. sysとしてsqlplusにログインします。次に、次の操作を実行します。

1. create directory sqlを使用して、OSディレクトリにマップします。ここに、エクスポートが格納されます。例:
SQL> create directory exp_dp_dir as '/u01/backup/exports';

2. データベース・エクスポートおよびディレクトリ・アクセスの権限を付与します。例:
SQL> grant read, write on directory exp_dp_dir to system;
SQL> grant EXP_FULL_DATABASE to system

4. expdpコマンドを実行し、エクスポートを開始します。例:

expdp system/<password> DIRECTORY=exp_dp_dir DUMPFILE=<file_name>.dmp FULL=y
SCHEMA=<YOUR_SCHEMA>;

33.2.4.1.3 DB2 9.7のバックアップ

1. db2instユーザーとしてサーバーにログインします。

2. 次のコマンドを実行します。

db2 force applications all

3. 次のコマンドを実行します。

db2 backup db <db_name> to <backup_dir>

注意:

コマンドが完了したら、タイムスタンプを書き留めます。このタイムスタンプは、データベース・バックアップ・ファイルの名前に組み込まれます。

33.2.4.2 リカバリ

- 第33.2.4.2.1項「SQL Server 2008および2008R2のリカバリ」

- 第33.2.4.2.2項「Oracle 11gのリカバリ」

- 第33.2.4.2.3項「DB2 V9.7のリカバリ」

33.2.4.2.1 SQL Server 2008および2008R2のリカバリ

1. SQL Server Management Studioを開きます。

2. 「Databases」を開きます。

3. リストアするデータベースを右クリックします。「Tasks」→「Restore」→「Database」を選択します。

4. 「Source for restore」の下の「From database」を選択します。

5. 「Select the backup sets to restore」の下で、最新のバックアップを選択します。

6. 最上部にある「Script」をクリックします。
この手順によって、restore文が表示されたクエリー・エディタが開きます。

7. WITHの後にREPLACEを追加することでクエリーを編集します。
これによって、データベース・ログが上書き可能になります。

8. 「Execute」をクリックします。

33.2.4.2.2 Oracle 11gのリカバリ

1. oracleユーザーとしてサーバーにログインします。

2. ORACLE_HOMEをoracleデータベース・ディレクトリに設定し、ORACLE_SIDをデータベース名に設定します。

3. $ORACLE_HOME/binに移動します。

4. 次のコマンドを実行します。

./impdp system/<password> DIRECTORY=exp_dp_dir DUMPFILE=<file_name>.dmp
SCHEMAS=<YOUR_SCHEMA>;

33.2.4.2.3 DB2 V9.7のリカバリ

1. db2instユーザーとしてサーバーにログインします。

2. 次のコマンドを実行します。

db2 force applications all

3. 次のコマンドを実行します。

db2 restore db <db_name> from <backup_dir> replace existing

33.2.5 LDAP

この項では、次の項目について説明します。

- 第33.2.5.1項「バックアップ」

- 第33.2.5.2項「リカバリ」

33.2.5.1 バックアップ

LDAPブラウザを使用し、LDAP構成をエクスポートします。

33.2.5.2 リカバリ

クリーンなLDAPサーバーから開始します。LDAPブラウザを使用して、バックアップしたLDAP構成をインポートします。

33.3 リカバリ済WebCenter Sitesアプリケーションの実行

1. アプリケーション・サーバーを起動する前に次のようにします。

1. 検索索引をクリアします。

rm –rf <shared_dir>/lucene/Global/*

2. Tomcatを使用している場合は、アプリケーション・サーバー・キャッシュをクリアします。

rm -rf <server_dir>/tmp/*
rm -rf <server_dir>/work/*

注意:

WebLogicアプリケーション・サーバーの場合、アプリケーションを再デプロイメントするときにキャッシュはクリアされます。

3. TomcatまたはWebLogicを使用している場合は、次のようにコンパイル済JSPをクリアします。

rm -rf <web_app_dir>/jsp/cs_deployed/*

2. アプリケーション・サーバーを起動した後、すべてのキャッシュが同期されていることを確認します。

Oracle WebCenter Sites: Analyticsアプリケーションの用語集

Analyticsデータ取得アプリケーション

センサーとも呼ばれます。

アセットの登録

アセットに対するレポートの生成を可能にします。WebCenter Sitesアセットは、WebCenter Sitesインストールに固有であるため、Analytics管理インタフェースを使用してそれらをレポートに割り当てることで、それらのアセット・タイプをAnalyticsに登録する必要があります。これによって、Analyticsで次のことが可能になります。

- WebCenter Sitesアセット・タイプを認識する。

- 「一般情報」およびコンテンツ情報レポート・グループのレポート・メニュー・オプションを構成する。

- 登録済アセット・タイプのアセットに対するレポートを生成する。

データ取得

各ビジターのクリックおよび関連情報(各クリックの日時、クリックされたアセット、クリックの発行元のIPアドレス、訪問されたサイトなど)を記録するプロセス。情報は、sensorサーブレットによってリアル・タイムに取得され、ローカル・ファイル・システム(Analyticsデータ取得アプリケーションに対してローカル)のdata.txt.tmpファイルに記録されます。data.txt.tmpファイルは、しきい値の間隔(sensor.thresholdtimeのsensor.thresholdプロパティを参照)に到達するか、アプリケーション・サーバーが再起動したときに、センサーによってdata.txtにローテーションされます。

Analyticsは、パブリッシュされたページにデータ取得のためのタグが付けられている場合にのみ、WebCenter Sitesアセットの使用およびそれらのビジターに関するデータを取得できます。Engageアセットの場合、アセット自体にデータ取得のためのタグが付けられている必要があります。

Hadoopジョブ

Hadoop分散ファイル・システムに格納されているRAWデータに対する統計を効率的に計算するために、並列かつ分散形式でジョブを実行します。

HadoopによってMap/Reduceという計算パラダイムが実装されます。それによって、大規模な計算が小さい作業フラグメントに分割され、それらをそれぞれクラスタ上の任意のノードで実行できます。Map/Reduceには、jarファイルとクラスの組合せが必要であり、それらはすべて、通常jobファイルと呼ばれる1つのjarファイルに収集されています。ジョブを実行するには、それをJobTrackerに送信します。Hadoopジョブは、次のアクションを実行することで反応します。

- ジョブをスケジュールし、JobTrackerに送信します。

- データ取得アプリケーションによって取得されたRAWデータを処理して統計データにし、その統計をAnalyticsデータベースに注入します。

(Hadoopは、HDFSを参照し、ジョブのステータスを判別するためのWebインタフェースを備えています。)

Hadoopジョブでは、レポート生成時間を短縮するために、よくリクエストされるサイトの使用統計(1つのコンテンツに対するリクエストの単位時間当たりの平均数)が事前に計算されます。統計計算は、通常、リソースを大量に消費し、時間がかかります。そのため、それは、レポートを生成するたびにその時点で実行されるのではなく、必要な時点までに使用できるように事前に実行されます。したがって、事前に計算された統計を、ただちにレポートに取得できます。統計には、たとえば次のものが含まれています。

- 各サイトへの本日の合計ヒット数、訪問した国、特定の国からの訪問の合計数、ブラウザのタイプ、平均セッション期間など現在の情報。

- 履歴結果。たとえば、次のものです。
日次、週次および月次統計。たとえば、レポート期間の特定の月に特定のサイト上の特定のアセットに対するリクエストの合計数。年次統計。過去1年間の週ごとの特定のアセットへのアクセス頻度を示すパフォーマンス・インジケータのヒストグラム。

Hadoopジョブの実行時間の長さは、最新のデータ取得時間枠、取得済データの累積量、Analyticsアプリケーションの構成など、いくつかの要因によって決まります。データ分析が完了したら、結果の統計は、いつでもレポートの生成に使用できます。

統合

AnalyticsをWebCenter Sitesシステムと統合することは、自身のオンライン・サイト上のアセット・タイプおよびユーザーに対するレポート生成が可能になることを意味します。統合には、AnalyticsへのCMサイト、WebCenter Sitesユーザーおよびアセット・タイプの登録、ページ・ビュー・オブジェクトの構成(「ページ・ビュー」レポートを使用)およびユーザーへの適切なユーザー・グループのメンバーシップを介した適切な権限の付与が含まれます。これらのタスクの実行に必要な手順は、AnalyticsとWebCenter Sitesの統合に関する項で説明します。

内部検索

ビジターによってサイトの組込み検索エンジンを使用して実行される検索。この検索では、そのサイトのコンテンツ内から結果が返されます。

オブジェクト

Analyticsの構成。レポートのサブジェクト。

情報を格納および処理するときに、Analyticsではオブジェクトが使用され、WebCenter Sitesではアセットおよびアセット・タイプが使用されます。Analyticsが、WebCenter Sitesアセット・タイプを認識し、そのタイプのアセットをトラッキングできるようにするために、管理者は、WebCenter Sitesアセット・タイプで表してAnalyticsオブジェクトを定義します。それは、オブジェクトに対してAnalyticsレポートを構成し、そのオブジェクトに目的のアセット・タイプを割り当てることによって行います。レポートの構成プロセスによって、その基礎となるアセットが定義されます。

注意: オブジェクトの特別なインスタンスは、Pageviewオブジェクトです。これは、「一般情報」グループのレポートが機能するために管理者が(「ページ・ビュー」レポートを構成することで)構成する必要があります。

「ページ・ビュー」レポートは、複数のアセット・タイプをサポートします。

オブジェクト・インプレッション

センサー・サーブレットの1回の呼出し。詳細は、オブジェクト・インプレッションに関する項を参照してください。

ページ・ビュー

Analyticsの構成。1つ以上のアセットからなる1つのグループ。そのアセット・タイプは、Analyticsデータ取得アプリケーションによるトラッキングに対して有効化されています。

アセット・タイプは、それらがページビュー・オブジェクトで定義されており、かつそれらのアセット・タイプを表示するパブリッシュ済ページがAddAnalyticsImgTag (データ取得タグ)でタグ付けされている場合に、トラッキング可能になります。トラッキングの詳細は、「データ取得」を参照してください。

Pageviewオブジェクト

「ページ・ビュー」レポートを介して構成するデフォルトAnalyticsオブジェクト。Pageviewオブジェクトは、「ページ・ビュー」、サイト情報および「クリックストリーム」レポートの基礎となるため、これらのレポートへの組込みに対して(マーケティングの視点から)最も意味があるアセットを持つアセット・タイプを割り当てる必要があります。

Pageviewオブジェクトには、複数のアセット・タイプを割り当てることができます。「ページ・ビュー」レポートには、それらのアセット・タイプの使用に関する統計が含まれます。

「ページ・ビュー」レポート

Pageviewオブジェクトに基づいたレポート。「ページ・ビュー」レポートは、自身のサイト上のページ・ビュー・アクティビティに関する統計を表示します。

処理済データ

Hadoopジョブによって統計データに処理済のビジターのアクティビティ・データ。処理が完了すると、このデータはAnalyticsデータベースに注入され、そこで、ユーザーがAnalyticsレポート作成インタフェースからリクエストしたレポートにただちに使用できるようになります。

RAWデータ

サイト上のビジターのアクティビティを記述する未処理データ。データ取得プロセス中に記録され、将来の処理のためにローカル・ファイル・システムに格納されます。これは、Hadoopジョブによってレポートに表示するために計算される統計の元になるデータです。(このデータは、レポート生成には直接使用できません。)

センサー

「Analyticsデータ取得アプリケーション」とも呼ばれます。

サイトの登録

そのサイトに対するビジターのアクティビティをAnalyticsがトラッキングできるようにするために、WebCenter Sites CMサイトをAnalyticsに特定させること。

統計データ

「処理済データ」を参照。

作業パッケージ

オブジェクト・インプレッションのコレクション。詳細は、オブジェクト・インプレッションおよび作業パッケージに関する項を参照してください。

オラクル社の法律上の注意点について

コピーライトについて

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。