| Oracle® Fusion Middleware Oracle WebCenter Portal開発者ガイド 11g リリース1 (11.1.1.7.0) B72084-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portal開発者ガイド 11g リリース1 (11.1.1.7.0) B72084-02 |
|
前 |
次 |
この章では、WebCenter Portal: Frameworkアプリケーションをライフ・サイクルを通して管理するためのタスク、ツールおよびテクニックを説明します。
ポータルのライフ・サイクルとは、ポータルの開発から本稼働までの過程を表します。ライフ・サイクルのフェーズには、通常、開発、テスト、ステージングおよび本稼働が含まれます。各フェーズでは特定のタスクを実行する必要があります。コンテンツ・リポジトリの設定など、一部のタスクは一度だけ実行します。その他のタスクは、夜間ビルドなどで頻繁に実行されます。ポータルのライフ・サイクルのフェーズについては、表9-1で説明しています。
表9-1 ポータルのライフ・サイクルのフェーズ
| ライフ・サイクル・フェーズ | 主要なアクター/ロール | 説明 |
|---|---|---|
|
開発 |
|
開発ポータルは主にソース・コントロールであり、ファイルベースです。開発者はJDeveloperでローカルの作業をし、統合WebLogic Serverにデプロイします。開発ポータルは、通常、テストのデータとコンテンツを使用します。ライフ・サイクルのこのフェーズで開発される機能の一部は、次のとおりです。
開発環境からのコードは、(通常夜間に)ビルドされ、クリーンで独立したターゲット環境にデプロイされます。WebCenterには、この目的に適応できるビルド・スクリプトが用意されています。第9.7項「夜間ビルド・スクリプトの構成」を参照してください。 |
|
テスト |
|
開発ポータルは、(通常夜間に)ビルドされ、独立したテスト環境にデプロイされます。テスト環境には、通常、Metadata Service (MDS)とデータベース・ベースのポリシー・ストア、および専用のOracle WebCenter Contentインスタンスが含まれています。 テスト環境には、本番ポータルには組み込まれないテスト・データやテスト・コンテンツが含まれることもあります。 ポートレット・プロデューサは、テスト環境と開発環境で共有される場合もあります。ただし、使用負荷が高い場合には、個別インスタンスの作成をお薦めします。 |
|
ステージング |
|
ステージング環境では、ポータルが本番に移行する前に最終的な構成およびテストが行われる安定した環境が提供されます。コンテンツ・コントリビュータはコンテンツを追加して、ポータルの構造を調整します。 一般に、ステージング環境には、専用のOracle WebCenter Contentサーバーおよび専用のポートレット・プロデューサ・サーバーが含まれます。ステージング・サーバーは、通常、本番サイトのミラーとして保持されます。 |
|
本番 |
|
本番ポータルはライブで、エンド・ユーザーも使用できます。本番ポータルは、リソース・マネージャ、Oracle WebCenter Portalのコンポーザなどのツールで変更できます。たとえば、管理者はポータルにポートレットをさらに追加したり、ポータルのコンテンツを再構成できます。 適切な権限を持った個々のユーザーは、ビューをカスタマイズすることも可能です。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』を参照してください。 WebCenterでは、メタデータを本番環境に移行する伝播ツールが用意されています。第9.13項「ステージングから本番に伝播させる伝播ツールの使用」を参照してください。 コンテンツは、Oracle WebCenter Contentレプリケーション・ツールを使用してプロビジョニングされます。第9.14項「Oracle WebCenter Contentからのコンテンツの伝播」を参照してください。 WebCenterでは、ポートレット・プリファレンスをインポートおよびエクスポートするためのWLSTコマンドを用意しています。詳細は、第9.16項「ポートレット・プリファレンスの移行」を参照してください。 |
ライフ・サイクルの各フェーズでは、特定のタスクを実行するアクター(開発者、管理者、コンテンツ・コントリビュータなど)が必要です。ここでは、ポータルのライフ・サイクルの各フェーズで実行されるタスクの種類の概要を示します。
開発、ビルド/テスト、ステージングおよび本番の各環境を設定するには、特定の準備手順を実行する必要があります。表9-2に、これらの予備設定タスクおよびそれを適用する環境のリストを示します。第9.7項「夜間ビルド・スクリプトの構成」および第9.8項「ステージング環境または本番環境の初期設定」も参照してください。
表9-2 一般的な1回かぎりの設定タスク
| 設定タスク | 開発 | ビルド/テスト | ステージング | 本番 |
|---|---|---|---|---|
|
JDeveloperのインストール |
はい |
いいえ |
いいえ |
いいえ |
|
Oracle WebCenter Portalのインストール |
はい |
はい |
はい |
はい |
|
Oracle WebLogic Serverのインストール(ドメインおよび管理対象サーバーの作成) |
いいえ |
はい |
はい |
はい |
|
RCUによる必要なデータベース・スキーマの作成 |
いいえ |
はい |
はい |
はい |
|
Oracle WebCenter Contentのインストールおよび構成 |
はい |
はい |
はい |
はい |
|
Oracle Access Managerなどのアイデンティティ管理コンポーネントのインストール |
いいえ |
はい |
はい |
はい |
|
ポリシー・ストアでの必要なOracle Platformセキュリティ・サービス・ポリシーの作成 |
いいえ |
はい |
はい |
はい |
|
資格証明ストアでの必要なユーザー資格証明の作成 |
いいえ |
はい |
はい |
はい |
|
バックエンド・サーバーへの接続の作成 |
はい |
はい |
はい |
はい |
|
ビルド・スクリプトの作成 |
はい |
いいえ |
いいえ |
いいえ |
|
デプロイおよび構成スクリプトの作成 |
いいえ |
いいえ |
はい |
はい |
|
WebCenter Portalのパーソナライズの統合/構成 |
はい |
はい |
はい |
はい |
* WebCenter Portalのパーソナライズの詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWebCenter Portalのパーソナライズの管理に関する項および第66章「WebCenter Portalアプリケーションのパーソナライズ」を参照してください。
環境の初期設定のもう1つのテクニックは、既存のインスタンスのクローニングです。通常、これはステージング・インスタンスから本番インスタンスをクローニングする際に使用します。この「テストから本番へ」の手法の詳細は、『Oracle Application Server管理者ガイド』のテスト環境から本番環境への移行に関する項を参照してください。
開発環境では、各開発者にはローカルのJDeveloperインスタンスがあり、これがソース・コントロール・システムおよび共有Oracle WebCenter Contentリポジトリに接続されています。開発者はメタデータとコードをソース・コントロールに保存します。ポートレットは個々にプロデューサ・サーバーにデプロイされ、ポータルで使用されます。
開発環境では、開発者は通常、統合WebLogic Serverを使用してアプリケーションをローカルに構築し、実行します。ローカルの開発環境では、MDSおよびポリシー・ストアはどちらもファイルベースです。
詳細は、第1章「開発者向けクイック・スタート・ガイド」、第3章「開発環境の準備」および第4章「チームでの効率的な作業」を参照してください。
通常、開発者はJDeveloperで作業してコード変更をローカルに統合WebLogic Serverで実行します。コード変更はソース・コントロール・システムにチェックインされます。
毎日夜間にビルドされるクリーンな環境を作成するビルド環境を設定する場合には、各ビルドについて次のような特定のタスクを実行する必要があります。
スキーマの作成(通常、Oracleリポジトリ作成ユーティリティ(RCU)を使用)
ドメインの作成および設定
管理対象サーバーの作成および構成
アプリケーションのデプロイ
WebCenterには、環境に対して変更および使用できるビルド・スクリプトのサンプルが用意されています。第9.7項「夜間ビルド・スクリプトの構成」を参照してください。夜間ビルドは、通常、QAエンジニア、テクニカル・ライター、マネージャなどの組織内の人間が使用できます。第9.4項「構築環境およびテスト環境の理解」も参照してください。
WebCenter Portalのパーソナライズの開発環境への統合については、第66.2項「アプリケーションへのパーソナライズの統合」を参照してください。
通常、テスト環境はQAエンジニアがアクセスする夜間ビルド環境のミラーです。クリーンなテスト環境の提供に関与するタスクは、通常、クリーンなビルド環境の作成と同じです。第9.4項「構築環境およびテスト環境の理解」も参照してください。
実行時ツールは、開発環境よりもステージング環境でさらに大きな役割を果たします。ただし、開発の更新をステージ環境に対して不定期にデプロイする必要があります。これらがさらに断続的な更新になるように、WebCenterでは、使用環境に合せてコピーと変更が可能なデプロイおよび構成スクリプトのセットを備えています。デプロイおよび構成スクリプトは、環境間の変数である情報(サーバー名、ポート、コンテンツ管理接続など)を区分けします。詳細は、第9.5.1項「ステージング環境のプロビジョニング」および第9.11項「ターゲットのサーバーでのアプリケーションのデプロイおよび構成」を参照してください。
パーソナライズの統合および構成については、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWebCenter Portalのパーソナライズの前提条件に関する項を参照してください。
ステージング環境で変更をテストして承認したら、これらを本番環境にプッシュする必要があります。WebCenterでは、WebCenter Portal管理コンソールに、すべてのポータルのメタデータをステージングから本番サーバーに移行する伝播ツールが用意されています。詳細は、第9.13項「ステージングから本番に伝播させる伝播ツールの使用」を参照してください。
WebCenterでは、ポートレット・プリファレンスをインポートおよびエクスポートするためのWLSTコマンドを用意しています。詳細は、第9.16項「ポートレット・プリファレンスの移行」を参照してください。
様々な人がポータルのライフ・サイクルに関与します。一般に、これらの人々(表9-1の主要なアクター)は、次の1つ以上の一般的なロールに分類されます。
開発者: JDeveloperおよび第9.7項「夜間ビルド・スクリプトの構成」で説明するビルド・スクリプトを使用します。
IT管理者: 第9.11項「ターゲットのサーバーでのアプリケーションのデプロイおよび構成」で説明するデプロイおよび構成スクリプトを使用します。
サイト・マネージャ: Frameworkアプリケーションに対する管理権限を持っています。サイト・マネージャはWebCenter Portal管理コンソールを使用して、ポータルのレイアウト、コンテンツおよびセキュリティ設定を変更します。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』および第9.15項「ライフ・サイクルを通したセキュリティの管理」を参照してください。
コンテンツ・モデラー: Oracle WebCenter ContentのSite Studioデザイナを使用してコンテンツをモデリングします。詳細は、Site StudioおよびOracle WebCenter Contentのドキュメントを参照してください。
コンテンツ・ディストリビュータ: イメージ、ドキュメント・ファイル、ビデオおよびオーディオ・コンテンツなど、ポータルに表示される、またはポータルから使用できるすべてのコンテンツを開発します。
開発者は通常、ローカルにビルドして実行しますが、自動的に夜間に実行されるビルド環境をお薦めします。ビルド環境とは、Frameworkアプリケーションのクリーンなデプロイメントを意味します。
ビルド環境を設定するには、一度バックエンド・サーバーおよび接続をインストールして作成する必要があります。たとえば、ビルド環境にはWebLogic Serverインスタンスが必要で、通常、インストールされたOracle WebCenter Contentインスタンスへのアクセスが含まれます。さらに、ビルド環境にはデータベースに基づくMDSとポリシー・ストアが含まれます。
図9-1に、構築する開発からテスト環境への一般的なフローを示します。
|
注意: 図9-1は、考えられるすべてのポータル機能を表してはいません。たとえばWebCenter Portalのパーソナライズはこの図には描かれていません。詳細は、第9.12項「WebCenter Portalのパーソナライズのファイルの構築とデプロイ」を参照してください。 |
Antベースのビルド・スクリプトを使用して、ソース・コントロールからEARを構築してデプロイする方法が一般的です。EARには、メタデータ、コードおよびシード済ポリシーが含まれます。また、ビルド・スクリプトは、ポートレットに対して行われたカスタマイズをEARメタデータにパッケージ化します。第9.7項「夜間ビルド・スクリプトの構成」を参照してください。夜間ビルドで実行されるタスクには、次のようなものがあります。
スキーマの作成(RCUを使用)
管理対象サーバーおよびドメインの設定
EARの構築およびデプロイ
その他の設定タスクの実行
ベスト・プラクティスとして、Oracle WebCenter Contentアーカイブ・ツールを使用して、Oracle WebCenter Contentのテスト・コンテンツとWebアセットを環境間で移動します。第9.14項「Oracle WebCenter Contentからのコンテンツの伝播」を参照してください。ポートレットのデプロイについては、第61章「ポートレット・プロデューサのデプロイ」を参照してください。
WebCenter Portalのパーソナライズの開発環境への統合については、第66.2項「アプリケーションへのパーソナライズの統合」を参照してください。
この項では、ポータルのライフ・サイクルのステージング・フェーズおよび本番フェーズについて説明します。図9-2に、ステージング環境から本番環境への一般的な流れを示します。
|
注意: 図9-2は、考えられるすべてのポータル機能を表してはいません。たとえばWebCenter Portalのパーソナライズはこの図には描かれていません。詳細は、第9.12項「WebCenter Portalのパーソナライズのファイルの構築とデプロイ」を参照してください。 |
ステージング環境では、ポータルが本番に移行する前に最終的な構成およびテストが行われる安定した環境が提供されます。一般に、ステージング環境には、専用のOracle WebCenter Contentサーバーおよび専用のポートレット・プロデューサ・サーバーが含まれます。一般的な設定タスクは、表9-2を参照してください。
初めてステージング環境を設定する場合には、第9.8項「ステージング環境または本番環境の初期設定」を参照してください。ステージング環境への増分変更の詳細は、第9.11項「ターゲットのサーバーでのアプリケーションのデプロイおよび構成」を参照してください。
必要な場合は、Oracle WebCenter Contentアーカイブ・ツールを使用して、Oracle WebCenter ContentのコンテンツとWebアセットをテスト環境とステージング環境との間で移動できます。第9.14項「Oracle WebCenter Contentからのコンテンツの伝播」を参照してください。ポートレットの移行については、第9.16項「ポートレット・プリファレンスの移行」を参照してください。
パーソナライズの要件、依存性およびオプションの全リストは、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWebCenter Portalのパーソナライズの前提条件に関する項を参照してください。
コンテンツ開発者は、Oracle WebCenter Contentコンテンツ・コントリビューション・ツールやドキュメント・サービスを使用して、コンテンツをステージング・サーバーに直接追加できます。Oracle WebCenter Contentのコンテンツ・ワークフロー機能を使用して、コンテンツの承認を管理できます。また、WebCenterにはコンテンツの作成および編集用の実行時ツールが備わっています。たとえば、次のことが可能です。
既存のOracle WebCenter Contentのリージョン・データ・ファイルの編集
新規Oracle WebCenter Contentのリージョン・データ・ファイルの作成
既存のHTMLコンテンツの編集
新規イメージのアップロード
さらに、ドキュメント・サービスではHTMLコンテンツやその他のファイル・タイプのフォルダベースの作成および編集ができます。第29章「ドキュメント・サービスの統合」も参照してください。
ステージング環境は、プロビジョニングおよびテストが完了すると、本番環境に移行してユーザーがアクセスできるようになります。ライブ本番環境では、自動スクリプトやレプリケーション・テクニックを使用してメタデータ、コンテンツ、Webアセットに対する増分更新を実行できます。
通常、そのような更新は個々のコンテンツ・ディストリビュータではなく、サイト・マネージャが実行します。詳細は、第9.13項「ステージングから本番に伝播させる伝播ツールの使用」を参照してください。
コンテンツ・モデルやリージョン定義の変更は、サイト・マネージャにより本番サーバーにプッシュされます。Oracle WebCenter Contentレプリケーションを使用して、ステージングおよび本番サーバー間でコンテンツをレプリケートできます。第9.14項「Oracle WebCenter Contentからのコンテンツの伝播」を参照してください。
WebCenterでは、ポートレット・プリファレンスをインポートおよびエクスポートするためのWLSTコマンドを用意しています。詳細は、第9.16項「ポートレット・プリファレンスの移行」を参照してください。
WebCenter PortalはJDeveloperおよびOracle ADFの上に構築されます。そのため、アプリケーションのライフ・サイクル管理では、次のような利点があります。
開発フレームワーク: JDeveloperおよびOracle ADFには、アプリケーションの構築および更新に使用できるツールとフレームワークが備わっています。Frameworkアプリケーションへのポートレット、コンテンツおよびカスタマイズ機能の追加は、目的のオブジェクトをソースまたはWYSIWYG環境にドラッグ・アンド・ドロップするだけで済みます。
反復開発: WebCenterには、チームの生産性を大きく向上させる反復開発機能が備わっています。第1.5項「反復開発の準備」を参照してください。
ラウンドトリップ開発: ラウンドトリップ開発とは、メンテナンスや拡張のため、デプロイされた実行時ポータルからJDeveloperにリソースを戻すことができる機能および技法です。ラウンドトリップ開発の詳細は、第16.3項「ポータルの実行時管理の有効化」および第16.4項「リソースのラウンドトリップ開発の有効化」を参照してください。
エンタープライズ・デプロイメント: アプリケーションを本番環境にデプロイする準備ができたら、WebCenterで提供されるデプロイメント・スクリプトを使用できます。詳細は、第9.11項「ターゲットのサーバーでのアプリケーションのデプロイおよび構成」と第9.13項「ステージングから本番に伝播させる伝播ツールの使用」を参照してください。デプロイメントの詳細は、第69章「WebCenter Portal: Frameworkアプリケーションのデプロイおよびテスト」を参照してください。
|
注意: WebCenter Portal: Servicesでは、通常、Oracle WebCenter Portalのディスカッション・サーバーのようなバックエンドが開発環境で使用できる必要があります。 |
規格に基づいた管理: ブラウザベースのツールにより、管理者はFrameworkアプリケーションとWebCenter Portal: Servicesをデプロイ、構成および管理できます。さらに、業界標準に基づいたJMXメソッドで構築されたツールにより、管理者はヘルス・ステータス、パフォーマンス、人気に関する精度の高い制御と監視メカニズムを提供します。長期にわたる過去のパフォーマンスやステータスのレポート(単独のOracle Application Serverコンテキスト内)を取得するツールも備わっています。Frameworkアプリケーション・メトリックは、使い慣れたApplication Server Controlの監視および管理インタフェースを使用して提供されます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』を参照してください。
Frameworkアプリケーションを作成すると、Antビルド・スクリプトとプロパティ・ファイルがファイルシステム上のメイン・アプリケーション・ディレクトリに自動的に作成されます。作成されるファイルは、次のとおりです。
build.xml: アプリケーションのクリーニング、コンパイル、構築およびデプロイのための標準のターゲット一式が含まれています。このファイルをソース・コントロールにチェックインして開発者が使用できるようにします。
build.properties: アプリケーション用のJDeveloperワークスペース・ファイル(.jwsファイル)の場所とアプリケーションのWARファイルの出力フォルダを指定します。build.xmlファイルにはbuild.propertiesファイルが含まれ、これによりbuild.xmlはこれらの環境固有の変数を取り込むことができます。プロパティ・ファイルをカスタマイズして、ビルド環境で使用する設定および環境変数を一致させることができます。
ビルド・スクリプトを実行する前に、JAVA_HOME環境変数とANT_HOME環境変数が適切に設定されていることを確認します。例:
JAVA_HOME = /path_to_your_java_installation/jdk ANT_HOME = /path_to_your_ant_installation
アプリケーションを構築およびデプロイするには、antターゲットallを使用します。例:
ant all
WebCenter Portal用のパーソナライズを使用してポータルのパーソナライズ機能を提供している場合、手動でbuild.xmlファイルを更新する必要があります。詳細は、第9.12.1項「WCPS MARファイルの構築」を参照してください。
ステージング環境または本番環境の初期設定およびプロビジョニングの詳細は、『Oracle Application Server管理者ガイド』のOracle WebCenter Portalの新しい本番環境への移動に関する項を参照してください。セキュリティ・ポリシーおよび資格証明の環境への最初の移動については、第9.15項「ライフ・サイクルを通したセキュリティの管理」も参照してください。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』も参照してください。
このシナリオでは、Oracle WebCenter Portalがインストールおよび構成されている作業用本番環境があり、変更内容を本番環境にローリングする前に、アプリケーションや構成の変更をテストします。たとえば、既存のセキュリティ・ポリシーや構成を変更したとします。
デプロイ・スクリプトと構成スクリプトによる既存の環境の更新をお薦めします。サンプル・スクリプトはWebCenterに用意されているので、それを環境に合うように自由に変更できます。詳細は、第9.11項「ターゲットのサーバーでのアプリケーションのデプロイおよび構成」および第9.12項「WebCenter Portalのパーソナライズのファイルの構築とデプロイ」を参照してください。
WebCenterには、WebCenter Portal管理コンソールに組み込まれた伝播ツールが備わっています。伝播ツールは、アプリケーションをステージング環境から本番環境へ移動するためのものです。第9.13項「ステージングから本番に伝播させる伝播ツールの使用」を参照してください。
Oracle WebCenter Contentのコンテンツの移動の詳細は、第9.14項「Oracle WebCenter Contentからのコンテンツの伝播」を参照してください。
セキュリティ・ポリシーと資格証明の移動の詳細は、第9.15項「ライフ・サイクルを通したセキュリティの管理」を参照してください。
詳細は、『Oracle Application Server管理者ガイド』のOracle WebCenter Portalの既存の本番環境への移動に関する項を参照してください。
JDeveloperで作業するFrameworkアプリケーション開発者は、通常、統合WebLogic Serverにアプリケーションをローカルにデプロイします。ライフ・サイクルの他のフェーズ(テスト、ステージングおよび本番)では、適切な管理対象サーバーへのデプロイメントをお薦めします。あるいは、ポートレット開発の場合、サービス・プロデューサ管理対象サーバーにデプロイする必要があります。管理対象サーバーへのデプロイの詳細は、第69.3項「WebLogic管理対象サーバーへのFrameworkアプリケーションのデプロイ」を参照してください。
ライフ・サイクルの間、通常のポータルはテスト・サーバー、ステージング・サーバーおよび本番サーバーへデプロイされます。この項では、Frameworkアプリケーションをターゲットのサーバーでデプロイおよび構成する手法について説明します。
WebCenterに用意された構成可能スクリプトで、アプリケーションを容易に該当するサーバーのインスタンスにデプロイして構成できます。ビルドおよびデプロイ・スクリプトは、ターゲットのサーバーにサーバーと接続の情報を指定する、シンプルなプロパティ・ファイル・パラメータを取ります。各ターゲットのサーバーに対して一度だけこのプロパティ・ファイルを作成する必要があります。その後、デプロイを実行し、パラメータとして適切なプロパティ・ファイルを使用してスクリプトを構成します。
アプリケーションのデプロイには、ojdeployを使用するのではなく、この項で説明するスクリプトを使用することをお薦めします。ベスト・プラクティスは、JDeveloperにより提供されるAntタスクを使用してアプリケーションを構築し、この項で説明するスクリプトを使用してアプリケーションをデプロイおよび構成することです。ojdeployコマンドライン・ユーティリティを使用すると、JDeveloper IDEを起動しないでJDeveloperからアプリケーションをデプロイできます。
|
注意: 第9.13項「ステージングから本番に伝播させる伝播ツールの使用」で説明する伝播ツールは、主に、サイト管理者が承認されたサイト構造の変更内容を停止時間が生じることなく本番環境にプッシュする際に使用します。 |
|
ヒント: ビルド・スクリプトおよびデプロイ・スクリプトは、サーバー名、ポート、コンテンツ管理接続、データベース接続など、環境間で可変の情報を分離します。Frameworkアプリケーションの大半の部分では、アプリケーションを別のサーバーに再デプロイする際に変更する必要はありません。たとえば、アプリケーションの名前は変更しません。 |
この項で説明するデプロイおよび構成スクリプトを使用するのは、主に、本番アプリケーションがほとんど読取り専用でライブの場合のみです。このシナリオでは、コンテンツ・ディストリビュータがステージングされたアプリケーションに対してアクティブな変更を加え、コンテンツを本番へ移行する前にコンテンツの承認を受けます。自動コンテンツ・レプリケーションを使用して、適切なワークフローの承認後にコンテンツをステージングから本番へ移行することをお薦めします。第9.14項「Oracle WebCenter Contentからのコンテンツの伝播」を参照してください。
セキュリティ変更は、デプロイおよび構成スクリプトによる影響を受けません。本番へのサイト構造の変更をプッシュするには、管理者は、第9.13項「ステージングから本番に伝播させる伝播ツールの使用」で説明するように伝播ツールを使用できます。第9.15項「ライフ・サイクルを通したセキュリティの管理」も参照してください。
アプリケーションをターゲットの環境にデプロイして構成するには:
端末のウィンドウで、デプロイおよび構成スクリプトを含むディレクトリに移動します。これらのスクリプトはcreate_profile.cshおよびdeploy_and_config.cshと呼ばれます。これらのファイルはWEBCENTER_HOME/webcenter/scripts/stage2prodにあります。WEBCENTER_HOMEは、WebCenterがインストールされるディレクトリです。
|
注意:
|
まず、ターゲットのサーバーのURL、ユーザー名、パスワードなどのターゲット環境に固有の情報をsetup.propertiesファイルに記述する必要があります。setup.propertiesファイルはWEBCENTER_HOME/webcenter/scripts/stage2prod/setupにあります。それには、setup.propertiesファイルを開いて、ターゲット環境の該当する値を追加します。例9-1に、サンプル・ファイルを示します。
|
注意: WebLogic Serverデプロイメントでは、WebSphereサーバー・プロパティの下にリストされたプロパティは無視してかまいません。Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドのWebSphereにデプロイされたアプリケーションのデプロイおよび構成スクリプトの使用に関する項も参照してください。 |
create_profile.cshとdeploy_and_config.cshを更新して、デプロイ環境に反映させます。
setenv WC_HOME <webcenter_home> setenv SCRIPTS_DIR <scripts_home>
WC_HOMEはWebCenterのホームで、SCRIPTS_DIRはスクリプトが置かれている場所です。デフォルトでは、スクリプトの場所は$WC_HOME/webcenter/scripts/stage2prodです。スクリプトを別の場所にコピーした場合は、SCRIPTS_DIRをその場所に設定してください。
create_profileスクリプトを実行します。このスクリプトへの入力は、setup.properitesファイルです。たとえば、Linux環境では次のように入力します。
./create_profile.csh
このスクリプトは、アプリケーション環境を調べ、WEBCENTER_HOME/webcenter/scripts/stage2prod/setupにwcconfig.propertiesという出力プロパティ・ファイルを作成します。
必要に応じて、出力ファイルwcconfig.propertiesの名前を、ターゲット環境を反映する名前に変更します。たとえば、ターゲット環境がステージング環境の場合には、出力ファイルの名前をwstage.propertiesのように変更できます。
wcconfig.propertiesファイルは、ターゲット環境でのポータルの実行に必要なすべての構成情報を指定します。たとえば、コンテンツ管理リポジトリ、omniポートレット、WSRPプロデューサ、WebCenter Portalのパーソナライズなどの設定が含まれます。例9-2に、wcconfig.propertiesサンプル・ファイルを示します。
例9-2 wcconfig.propertiesサンプル・ファイル
webcenter.wcps.app.name=wcps-services webcenter.wcps.app.server=WC_Utilities admin.jmx.url=t3\://hostname\:myport doclib.Content.cis.socket.host=hostname app.mds.jndi=jdbc/mds/SpacesDS webcenter.app.archive=/net/hostname/scratch/webapp.ear doclib.Content.cis.socket.port=myport webcenter.wcps.archive=/net/hostname/scratch/wcps.mar webcenter.app.name=webapp admin.user=weblogic app.mds.repository=mds-SpacesDS app.mds.partition=wcps-services webcenter.app.version=V2.0 web.OmniPortlet.url=http\://hostname\:myport/portalTools/omniPortlet/providers/omniPortlet app.restart=false webcenter.app.server=WC_CustomPortal
|
注意:
|
create_profile.cshを実行して、ターゲット環境ごとのプロパティ・ファイルを作成します。たとえば、テスト、ステージングおよび本番環境にそれぞれファイルを作成できます。
wcconfig.propertiesファイル(あるいは名前を変更した場合はそのファイル)を入力として受け入れるようにdeploy_and_configスクリプトを編集します。
deploy_and_confgスクリプトを実行します。たとえば、Linux環境では次のように入力できます。
./deploy_and_config.csh
deploy_and_configスクリプトは、入力として2つのモードのうちの1つを取ります。2つのモードとは、deploy_configとp13n_metadataです。例:
./deploy_and_config.csh p13n_metadata
deploy_configモードは、入力がdeploy_and_config.cshに渡されない場合のデフォルト・モードです。deploy_configモードは、デプロイと構成のタスクを実行します。パーソナライズ・メタデータの更新を更新するだけの場合には、スクリプトの入力としてp13n_metadataに渡してデフォルト動作をオーバーライドできます。
このスクリプトは、Frameworkアプリケーションをデプロイして構成し、ターゲット環境で実行します。
アプリケーションのデプロイ後に実行されたWebCenter Portal構成の変更はすべて、MDSにカスタマイズとして保存されます。たとえば、アプリケーションにconnections.xmlで定義された接続があり、その後別の管理対象サーバーにアプリケーションをデプロイし、Oracle Enterprise Manager Fusion Middleware ControlコンソールまたはWLSTを使用して構成を実行した場合、その変更内容はMDSにカスタマイズとして保存されます。それ以降、新しいEARファイルをデプロイしても、それ以前に実行した接続の変更内容は有効のままで、EARファイル内の接続の定義をオーバーライドします。Fusion Middleware ControlコンソールまたはWLSTで実行した構成の変更内容は、再デプロイ後も存続します。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のOracle WebCenter Portal管理ツールに関する項も参照してください。
|
注意: ポートレット・プロデューサ・アプリケーションのカスタマイズもMDSに保存されます。ポートレット・プロデューサをデプロイする際には、カスタマイズは現在構成されているプロデューサの接続にアップロードされます。デプロイおよび構成スクリプトを使用して、プロデューサ接続を管理する(デプロイ後に再構成してからアプリケーションを再デプロイするのではなく)ことをお薦めします。デプロイおよび構成スクリプトでは、接続情報が変更されるたびにプロデューサのカスタマイズが適切に再デプロイされます。 |
この項では、WebCenter Portalのパーソナライズのファイルを構築してデプロイする方法を説明します。
|
注意: パーソナライズの統合および構成については、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWebCenter Portalのパーソナライズの前提条件に関する項を参照してください。 |
WebCenterには、WCPS MARファイル構築用のAntタスクが用意されています。WCPSを使用している場合、このタスクを夜間ビルド・スクリプトに追加することをお薦めします。
Frameworkアプリケーション用のAntビルド・スクリプトを作成します。詳細は、第9.7項「夜間ビルド・スクリプトの構成」を参照してください。
build.xmlファイルをエディタで開きます。
build-marタスクのAntターゲットを、例9-3に示すように、build.xmlファイルに追加します。
|
注意: Antタスクは、ネストされた |
例9-3 サンプルのdeploy-wcps-marターゲット要素
<target name="build-wcps-mar">
<taskdef name="build-mar"
classname="oracle.wcps.tools.ant.BuildMARTask"
uri="oracle:webcenter:wcps"> <classpath> <pathelement path="${oracle.jdeveloper.home}/jdev/extensions/oracle.wcps.tools.common/oracle.wcps.tools.ant.jar"/>
</classpath>
</taskdef>
<basename property="application.name"
file="${oracle.jdeveloper.workspace.dir}"/>
<wcps:build-mar xmlns:wcps="oracle:webcenter:wcps"
destFile="deploy/${application.name}-wcps.mar"
appName="${application.name}"
scenarionamespace="SomeThingElse"
failonfilescanerror="false" failonempty="true"> <fileset dir="${oracle.jdeveloper.workspace.dir}">
<include name="Portal/**/*.xml"/>
<exclude name="Portal/public_html/**"/>
</fileset>
</wcps:build-mar>
</target>
|
注意: 例9-3では、
|
allターゲットのdepends属性にタスクを追加します。例:
<target name="all" depends="deploy,build-wcps-mar"/>
build.xmlファイルを保存します。
このbuild-mar Antタスクは、表9-3に示した属性をサポートします。
表9-3 Antタスクにサポートされる属性
| 属性 | 必須 | 説明 |
|---|---|---|
|
destfile |
はい |
書き込む |
|
appname |
はい |
アプリケーション名です。通常、 |
|
scenarionamespace |
いいえ |
シナリオのネームスペースです。デフォルトではアプリケーション名と同じ設定となります(JDeveloperと同様)。 |
|
failonfilescanerror |
いいえ |
(Boolean)タスクが指定されたファイルをスキャンできない場合、タスクが構築に失敗するようにするかどうか指定します。デフォルト値はtrueです。 |
|
fileonempty |
いいえ |
(Boolean) WCPSファイルが見つからない場合、タスクが構築に失敗するようにするかどうか指定します。デフォルトは |
failonfilescanerror="false"を設定しない場合、次のようなエラーが表示されます。
BUILD FAILED: Unable to read C:\opt\jdev-applications\Application1\Model\classes\.data\00000000\00000000.jdb
または、ファイル・セットを絞り込むか(たとえば、*.xmlを使用して)、failonfilescanerror="false"を指定(この場合、単に警告が表示されます)します。
WCPSファイルをサーバーにデプロイするには:
JDeveloperでポータル・プロジェクトを開きます。WLSTコマンドを使用してこのデプロイを実行する場合には、第9.12.4項「MARファイルのインポートとエクスポート」を参照してください。
「アプリケーション」メニューから、「パーソナライズ・ファイルのデプロイ」を選択して「サーバーへ」を選択します。
「サーバーへのデプロイ」ダイアログで、サービスをデプロイするサーバーを選択します。図9-3を参照してください。
|
注意: オプションで、「追加」ボタンをクリックして、サーバーをリストに追加できます。 |
「...」ボタンをクリックして、特定のサーバー・インスタンスを選択します。たとえば、実行中のDefaultServerなどです。
終わったら、「OK」をクリックします。
「メッセージ - ログ」ウィンドウで、デプロイの詳細をチェックします。ログに、メタデータ・ファイルのデプロイが正常に完了したかどうかが表示されます。
ファイル・システムで、WCSPファイルをメタデータ・アーカイブ(MAR)ファイルにデプロイできます。MARファイルをデプロイするには:
JDeveloperでポータル・プロジェクトを開きます。
「アプリケーション」メニューから、「パーソナライズ・ファイルのデプロイ」を選択して「ファイルシステムへ」を選択します。
「ファイルシステムへのデプロイ」ダイアログで、「メタデータ・アーカイブの作成」を選択して、MARファイルの場所と名前を指定します。
その後、コマンドライン・ユーティリティを使用して、MARファイルをサーバーに更新できます。詳細は、第9.12.4項「MARファイルのインポートとエクスポート」を参照してください。
WCPSサーバーをメタデータ・アーカイブ(MAR)ファイルから新しいファイルを使用して更新するには、次のWLSTコマンドでサーバーに接続してメタデータをインポートします。
wlst:> connect('<username>', '<password>', 't3://admin-server-hostname:myport')
wlst:> importMetadata(application='wcps-services', server='WC_Utilities', fromLocation='<mar file>', remote='true')
WCPSをファイルシステムでサーバーからMARファイルにエクスポートするには、これらのWLSTコマンドでサーバーに接続してメタデータをエクスポートします。
wlst:> connect('<username>', '<password>', 't3://admin-server-hostname:myport')
wlst:> exportMetadata(application='wcps-services', server='WC_Utilities', toLocation='<mar file>', remote='true')
MDS WLSTコマンドの詳細は、Oracle Technology Networkで『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
開発環境の統合WebLogic Serverで実行中の場合、接続URLはt3://localhost:7101で、サーバーはDefaultServerです。
WebCenter Portal管理コンソールには、ポータル・メタデータをステージングから本番サーバーへ移行する伝播ツールが備わっています。サイト管理者はこのツールを時々使用して、承認されたサイト構造の変更内容を停止時間が生じることなく本番サーバーにプッシュします。
|
注意: 伝播ツールは、ポータルのメタデータとWebCenter Portalのパーソナライズのファイルの伝播をサポートしています。詳細は、第9.13.4項「WCPSファイルの伝播」を参照してください。 |
|
注意: WebCenterでは、ポートレット・プリファレンスをインポートおよびエクスポートするためのWLSTコマンドを用意しています。そのコマンドを使用して、ステージング・サーバーと本番サーバーの間でポートレット・プリファレンス・データをレプリケートします。詳細は、第9.16項「ポートレット・プリファレンスの移行」を参照してください。 |
WebCenterには、ポータル・メタデータをステージングから本番に移行する伝播ツールが備わっています。実際には、ステージング環境と本番はステージング・ポータルに変更が施されるまでは同一のままです。変更内容はテストして承認されると、管理者は伝播ツールを使用して変更内容を本番サーバーにプッシュします。この転送の際には、本番サーバーを再起動する必要はありません。
適切に構成されていれば、伝播ツールは図9-4に示すようにWebCenter Portal管理コンソールにタブとして表示されます。
「伝播」タブの「ラベル履歴」部分には、各伝播に作成されたラベル、「伝播」タブの外側に作成されたラベル、デプロイ中に作成されたラベルやWLSTを使用して作成されたラベルなどのリストが表示されます。各ラベルには、最後の伝播が実行されてから変更されたファイルのリストが表示されます。ラベルの内容を表示するには、図9-5に示すように、ラベル名の左の矢印ボタンをクリックします。
|
注意: 伝播ツールの使用で、いずれかのMDSドキュメントのファイル名にマルチバイトのNLS文字が含まれている場合、ステージング・マシンはそのNLSに対して構成する必要があります。 |
「伝播」タブは、ステージング・サーバーにデプロイされたポータルでURL接続が構成されている場合、WebCenter Portal管理コンソールに表示されるのみです。このURL接続は本番サーバーを指しており、ProductionURLConnectionという名前である必要があります。
このURL接続の構成には、Fusion Middleware Controlコンソールを使用するかOracle WebLogic Scripting Tool (WLST)を使用するかの2つの選択肢があります。この項では、両方のテクニックを説明します。
Fusion Middleware ControlコンソールでURL接続を構成するには:
ブラウザで、ステージング・サーバー・ドメインのFusion Middleware Controlコンソールを開きます。Fusion Middleware Controlコンソールの起動の詳細は、『Oracle Enterprise Manager管理者ガイド』を参照してください。
ナビゲーション・ツリーで、「アプリケーションのデプロイ」フォルダを開き、アプリケーションをクリックします。図9-6を参照してください。
右側のアプリケーション・ペインで、「アプリケーションのデプロイ」メニューを開き、「ADF」サブメニューから「ADF接続の構成」を選択します。図9-6に示すように、「ADF接続構成」パネルが開きます。
図9-6 Fusion Middleware Controlコンソールでのアプリケーションの選択
「接続の作成」ボックスで、URLの「接続タイプ」を選択して「接続名」にProductionURLConnectionと入力します。図9-7を参照してください。
|
注意: 接続の名前は |
「URL接続」ボックスで、「編集」をクリックします。
「URL接続」ダイアログ・ボックスに次のとおり入力します。
URL: 本番サーバーのURL(ホスト名とポート番号を含む)を入力します。
ユーザー名: 接続用ユーザー名を入力します。
パスワード: 接続用パスワードを入力します。
認証レルム: 「認証レルム」の値を入力する必要があります。このフィールドを空白のままにしないでください。ProductionRealmなどの任意の文字列を入力できます。
残りのフィールドには、デフォルト値をそのまま使用できます。図9-8を参照してください。
「URL接続」ダイアログに入力したら、「OK」をクリックします。
Fusion Middleware Controlコンソール・ウィンドウの右上隅にある「適用」をクリックします。
Oracle WebLogic Scripting Tool (WLST)コマンドを使用してURL接続を作成できます。コマンドへのパラメータは、前述の項第9.13.2.1項「Oracle Enterprise Manager Fusion Middleware ControlコンソールによるURL接続の構成」で説明した、Fusion Middleware Controlコンソールの「URL接続」ダイアログに入力した値と同じであることに注意してください。
次に示すのは、各パラメータに指定されたサンプル値を使用したWLSTコマンドの例です。ここの値を本番サーバーに関連する値に置換します。
adf_createHttpURLConnection(appName='portalApp', name='ProductionURLConnection', url='http://production_adminserver_host:myport', user='weblogic', password='password_for_weblogic', realm='ProductionRealm'
WLSTの詳細は、Oracle Technology Networkの『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
ステージング・ポータル上で施した変更を本番ポータルに移動するには、伝播ツールを使用します。
|
注意: ステージング・ポータルでページを削除する場合、ソースおよびターゲット・ポータルのページ・データが完全に同じになるように伝播が行われる前に、本番ポータルでページを手動で削除することをお薦めします。新しいページとページの更新はターゲットに伝播されますが、伝播プロセスはページの削除を伝播しません。 |
伝播ツールは、第9.13.2項「伝播ツールの構成」の説明に従って、必ず構成しておいてください。伝播ツールを使用するには、管理者の権限を取得しておく必要があります。
WebCenter Portal管理コンソールを開きます。デフォルトでは、管理コンソールは次のURLにあります。
http://<server>:<port>/<context_root>/admin
WebCenter Portal管理コンソールの使用の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWebCenter Portal管理コンソールの使用に関する項を参照してください。
「伝播」タブを選択します。
「伝播」をクリックして、ファイルを本番サーバーに転送します。
伝播ツールは、WebCenter Portalのパーソナライズのファイルのステージングから本番への移動をサポートします。伝播ツールはソース・サーバーのアプリケーションのMDSリポジトリから自動的にメタデータをエクスポートし、それをターゲット・サーバーのアプリケーションのMDSリポジトリにインポートします。
伝播ツールのWCPSファイル移動機能は、次の条件によって決まります。
FrameworkアプリケーションのMDSリポジトリは、mds-wcpsDSデータソースと同じデータベースを指している必要があります。これがデフォルトの構成です。一般的な図は、図9-2を参照してください。通常、デフォルトのデータベース構成を変更しなければ、伝播は正確に機能します。
ソース・サーバーと移動先のサーバーの両方で、アプリケーションMDSストアはwcps-servicesのMDSストアと同一のパーティション名を使用する必要があります。標準のポータルの構成では、このパーティションはwebcenter-portalです。
|
注意: 通常、伝播ツールの初期化とMDS変更のWCPS RESTサービスへの通知の間に1から2分の遅延があります。この遅延は、第9.12.4項「MARファイルのインポートとエクスポート」の説明のとおり、WLSTコマンドを使用してWCPSファイルを伝播する際に発生します。 |
手動または自動によるレプリケーションを使用して、ある環境から別の環境にコンテンツを移動することをお薦めします。あるいは、コンテンツを手動で伝播する方法もありますが、このオプションは、ソース・サーバーとターゲット・サーバーが相互通信できない場合のみお薦めします。
Oracle WebCenter Contentのコンテンツを伝播するツールとオプションの詳細は、Oracle WebCenter Content Content Serverシステム管理者ガイドのシステムの移行とアーカイブの管理に関する項を参照してください。その章には、アーカイブ・ファイルのエクスポートとインポートによるOracle WebCenter Contentのコンテンツの伝播についての説明があります。また、レプリケーションの設定方法と使用方法の説明もあります。レプリケーションでは、エクスポート、インポートおよび転送の各機能を自動化できます。たとえば、レプリケーションを使用して自動的に、あるコンテンツ・サーバーのインスタンスからエクスポートし、そのアーカイブを別のコンピュータに転送し、別のコンテンツ・サーバー・インスタンスにインポートできます。
この項では、セキュリティ・ポリシーと資格証明を1つの環境から別の環境へ移行するテクニックについて説明します。移行は自動でも手動でも実行できます。自動的な移行は、通常、アプリケーションを初めてデプロイする際に使用されます。手動の移行は再デプロイで使用されます。
アプリケーション・ポリシーが記載されたjazn-data.xmlをEARファイルにパッケージ化する際に、Oracle Platform Security Services (OPSS)ではweblogic-application.xmlのアプリケーション構成設定に基づいてポリシーの移行が実行されます。例9-4に、初回デプロイで自動的にポリシー移行を実現できるweblogic-application.xmlの推奨設定を示します。
例9-4 ポリシーの自動移行の設定(weblogic-application.xml)
<wls:application-param>
<wls:param-name>jps.policystore.migration</wls:param-name>
<wls:param-value>MERGE</wls:param-value>
</wls:application-param>
<wls:application-param>
<wls:param-name>jps.policystore.removal</wls:param-name>
<wls:param-value>OFF</wls:param-value>
</wls:application-param>
<wls:listener>
<wls:listener-class>oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener</wls:listener-class>
</wls:listener>
JpsApplicationLifecycleListenerをweblogic-application.xmlで指定して、ポリシーと資格証明の移行を有効化する必要があります。jps.policystore.migrationをMERGEに設定するようお薦めします。この構成では、jazn-data.xmlにパッケージ化されているポリシーが初回デプロイ時に必ず移行されます。アプリケーションのアンデプロイ時にアプリケーション・ポリシーがポリシー・ストアから削除されないように、jps.policystore.removalはOFFに設定してください。
再デプロイ時には、本番システムで変更されたポリシーの上書きを回避することが重要です。jps.policystore.migrationパラメータがMERGEに設定されていると、ステージング環境からのすべての新規ポリシーは本番ポリシーにマージされます。この設定では、既存ポリシーへの変更(ロールの権限の変更、ロールの削除、ロールのメンバーシップの削除など)は、競合の原因となる恐れがあるため再デプロイ時には移行されません。
本番ポリシーをjazn-data.xmlにパッケージ化されているステージング環境のセキュリティ・ポリシーで上書きする場合には、migrateSecurityStore WLSTコマンドを使用します。migrateSecurityStoreコマンドの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
アプリケーションの資格証明の移行サポートは、アプリケーションのポリシーの移行と似ています。JpsApplicationLifecycleListenerでは、別のセキュリティ施行によるアプリケーションのデプロイと再デプロイでの資格証明の移行に対応しています。
cwallet.ssoのアプリケーション資格証明とMETA-INF/ディレクトリ内のEARファイルにパッケージ化されたアプリケーション資格証明を使用して、OPSSではweblogic-application.xmlに記載された構成設定に基づいて、資格証明がシステムの資格証明ストアに移行されます。
例9-4に、初回デプロイで自動的に資格証明の移行を実現できるweblogic-application.xmlの推奨設定を示します。
例9-5 資格証明の自動移行の設定(weblogic-application.xml)
<wls:application-param>
<wls:param-name>jps.credstore.migration</wls:param-name>
<wls:param-value> MERGE </wls:param-value>
</wls:application-param>
すべての新規資格証明がデプロイおよび再デプロイ時に移行されるように、jps.credstore.migrationをMERGEに設定してください。この設定では、cwallet.ssoからの新規資格証明のキー/値のみが移行されます。既存の資格証明のキーへの変更は移行されません。
WebCenterでは、ポートレット・プリファレンスをインポートおよびエクスポートするためのWLSTコマンドを用意しています。エクスポートされたプリファレンス(カスタマイズおよびパーソナライズ)をターゲット・アプリケーションにインポートできます(ステージング・アプリケーションからのエクスポートや本番アプリケーションへのインポートなど)。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のOracle WebCenter PortalカスタムWLSTコマンドに関する項に記載されたexportPortletClientMetadataとimportPortletClientMetadataを参照してください。また、エクスポートとインポートが有効化されていることを確認してください。第59.3.14項「設計時にポートレット・プロデューサをエクスポートおよびインポートする方法」を参照してください。
まれに、本番サーバーにプッシュした変更をステージングからロールバックする必要が生じることがあります。この章で説明する伝播モデルは、ステージング・インスタンスへの少量の変更を伝播ツールで本番にプッシュすることを前提としています。変更をロールバックする必要が生じたら、手動でその変更をステージング・インスタンスで元に戻し、新たに変更したステージング・インスタンスを適切な検証とテストの後に本番にプッシュしなおしてください。このプロセスで、元の変更がロールバックされ、本番システムは元の状態に戻されます。
