| Oracle WebCenter Framework開発者ガイド 10g（10.1.3.4） B50831-02 |
|
 戻る |
 次へ |
デプロイは、アプリケーション・ファイルをアーカイブ・ファイルとしてパッケージ化して、ターゲットのOracle Application Serverに転送するプロセスです。この章では、WebCenterアプリケーションのデプロイに関連する概念を示し、WebCenterアプリケーションのパッケージ化、事前デプロイ、デプロイおよびアンデプロイを行うために実行する必要のある手順を説明します。
次の各項で、WebCenterアプリケーション・デプロイの概要とその手順を学びます。
この項では、WebCenterアプリケーションのライフ・サイクルと、本番環境および開発環境におけるWebCenterアプリケーションのデプロイについて概説します。この章の内容は、次のとおりです。
WebCenterアプリケーションは、アプリケーションのページおよびこれらのページに含まれているポートレットの実行時カスタマイズをサポートしているという点で、従来のJ2EEアプリケーションとは異なります。カスタマイズは、次のように格納されます。
WebCenterアプリケーションのカスタマイズは、ファイル・システムのOracle Metadata Services（MDS）内に格納されます。
ポートレット・プロデューサのカスタマイズ（プリファレンス）は、プリファレンス・ストア内に格納されます。プリファレンス・ストアは、ファイル・ベースにすることも、データベース内に配置することもできます。
WebCenterアプリケーションは通常、様々なポートレット・プロデューサに属するポートレットを消費します。WebCenterアプリケーションは、Oracle Content Database（Oracle Content DB）やOracle Application Server Portal（OracleAS Portal）などのコンテンツ・リポジトリに接続できます。接続詳細は、WebCenterアプリケーションの.earファイル（connections.xml）内に格納されています。
このため、WebCenterアプリケーションがステージング・サーバーや本番サーバー上にデプロイされるとき、外部依存性の詳細の一部または全部が変更されている可能性があります。たとえば、次のような項目が変更された可能性があります。
ポートレット・プロデューサのエンドポイント
コンテンツ・リポジトリの接続詳細
接続の資格証明
MDSの場所
ポートレット・プロデューサのプリファレンス・ストアの場所
ポリシーおよびアイデンティティの情報
図12-1に、WebCenterアプリケーションの外部依存性を示します。
追加の要件に対応するために、Oracle WebCenter Frameworkにはデプロイ前ツールが備わっています。このツールを使用すると、WebCenterに関連付けられているカスタマイズの場所を移行できます。また、WebCenterアプリケーションを再構成できるため、デプロイ・プロセスが簡略化されます。
デプロイ・プロセスの複雑性は、主に次の2つの要因によって決まります。
デプロイ・ステージの数
カスタマイズが許可されているステージの数
Oracle JDeveloperを使用してポートレットをページに追加した後は、カスタマイズを許可するライフ・サイクルのステージ（開発、ステージングおよび本番）を決定する必要があります。開発環境で行ったポートレット（OmniPortletやWebClippintポートレットなど）のカスタマイズは保持されますが、ページのカスタマイズはMDSに書き込まれません。この場合アプリケーションは、それ以降の実行のたびに初期ページ設計で起動されます。このため、開発者がページを繰り返し変更しても、前のカスタマイズが原因でクラッシュが発生することはありません。図12-2に示すように、開発後に（ステージング環境や本番環境などで）行ったページおよびポートレットのカスタマイズは、MDS内に保持されることに注意してください。このような開発後のカスタマイズは、ベース・アプリケーションとは別個で処理されます。
WebCenterアプリケーションのシナリオ
WebCenterアプリケーション・デプロイは、次のようなフェーズに分けられます。
初期デプロイ: アプリケーションが、初めて本番システムにデプロイされます。
後続デプロイ: アプリケーションの2番目のバージョンが、前にデプロイされたバージョンの上にロールアウトされます。この場合、初期デプロイ以降に実行時変更が行われた可能性があります。
並行デプロイ: 高可用性構成で使用するために、アプリケーションが複数の本番サーバーにわたってデプロイされます。これは概念的にはそれぞれ同じですが、別個のケースとして処理されます。高可用性の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
次の各項で、様々なシナリオにおいて初期デプロイおよび後続デプロイを実行する方法を説明します。
このシナリオでは、開発者が、Oracle JDeveloperの埋込みOracle Containers for J2EE（OC4J）を使用してアプリケーションを実行するときに、ページ・カスタマイズおよびポートレット・カスタマイズを実行します。開発環境ではページ・カスタマイズは保持されないため、ポートレット・カスタマイズのみが汎用EARファイルの一部としてパッケージ化されます。次の各項で、初期デプロイおよび後続デプロイのプロセスについて説明します。
初期デプロイ
図12-3に、WebCenterアプリケーションのカスケード・デプロイを示します。
次の手順で、初期デプロイのプロセスの概要を示します。
3.1.1項「テンプレートを使用したWebCenterアプリケーションの作成」の説明に従って、WebCenterアプリケーション・テンプレートを使用してアプリケーションを作成します。
埋込みOC4J内でアプリケーションを実行し、必要に応じて、アプリケーション内に含まれるポートレットをカスタマイズします。
12.2.1.4項「汎用EARファイルの作成」の説明に従って、アプリケーションをEARファイルにデプロイします。
汎用EARファイルをステージング・プラットフォームに転送します。
ステージング・プラットフォーム上でデプロイ前ツールを実行して、そのサーバーのローカル・ファイル・システムにカスタマイズを解凍します。次の手順が環境に適用可能な場合は、実行します。
デプロイ前ツールを実行して、ステージング・サーバーがアクセスするプロデューサを参照するようにポートレットを再構成します。詳細は、12.2.2項「WebCenterアプリケーションの事前デプロイ」を参照してください。
WebCenterアプリケーションで、Oracle Content DBデータ・コントロールを使用してOracle Content DBに格納されているコンテンツを使用する場合は、「Oracle Content DBベースのコンテンツ統合アプリケーションのパラメータの再構成」の説明に従って、デプロイ前ツールを使用してプロデューサ接続用にOracle Content DBを再構成します。
WebCenterアプリケーションで、OracleAS Portalベースのコンテンツ・データ・コントロールを使用してOracleAS Portalに格納されているコンテンツを使用する場合、かつOracleAS Portalデータ・ソース内に使用されているJNDI名が開発環境で使用されたJNDI名と異なる場合は、「OracleAS Portalアダプタ、Oracle Content Serverアダプタおよびファイル・システム・アダプタの再構成」の説明に従って、connection.xmlファイル内のOracleAS Portal接続情報を更新します。
WebCenterアプリケーションで、ファイル・システム上のデータ・コントロールを使用してファイル・システムに格納されているコンテンツを使用する場合は、「OracleAS Portalアダプタ、Oracle Content Serverアダプタおよびファイル・システム・アダプタの再構成」の説明に従って、connection.xmlファイル内のファイル・システム接続情報を更新します。ただし、ファイル・システム・アダプタは開発目的でのみ使用してください。
MDSの場所が変更された場合は、12.2.2項「WebCenterアプリケーションの事前デプロイ」の説明に従い、デプロイ前ツールを使用して、新しい場所を使用するようにアプリケーションを再構成します。
12.2.6.2項「スタンドアロンOC4Jへのデプロイ」の説明に従って、デプロイ前ツールにより作成されたターゲットのEARファイルを、ステージング・プラットフォーム上のOC4Jインスタンス（スタンドアロンまたはOracle Application Server）にデプロイします。
アプリケーションで暗号化済属性（資格証明ストア内のパスワードなど）を使用する場合は、12.5項「デプロイ済アプリケーションでの資格証明の更新」の説明に従い、資格証明MBeanを使用してこれらの資格証明を変更します。
埋込みOC4Jとデプロイ・サーバーが同じアイデンティティ・ストアを使用していない場合は、デプロイ済アプリケーションのMETA-INFディレクトリ内にあるapp-jazn-data.xmlファイルに対してJAZN移行ツールを実行します。12.2.4項「セキュリティおよびアプリケーション・ロールの移行」の説明に従って、ポリシーをローカルのsystem-jazn-data.xmlポリシー・ストア内にマージするか、セントラルLDAPベースのポリシー・ストアに統合するために同等のLDIFファイルを生成します。
テスト完了後、本番サーバーでこれらの手順を繰り返します。
後続デプロイ
この場合は、すべてのカスタマイズが開発環境で実行され、実行時に後続のカスタマイズは行われていません。後続デプロイは、初期デプロイを上書きすることと考えられます。アプリケーションを更新するたびに、これらの手順を繰り返してください。
アプリケーションのカスタマイズが本番環境でのみ行われる場合、アプリケーションの後続の再デプロイで必要なのは、カスタマイズの1つのポイントのみです。このため、アップグレード中にエクスポートおよびインポートの1回のみの手順を使用すれば、再デプロイを実行できます。この項で説明する手順では、テスト・フェーズがこのデプロイとは無関係に行われることを前提としています。
|
注意: アプリケーションの後続バージョンへのアップグレード中は、アプリケーションをカスタマイズ可能でないモードで実行することをお薦めします。詳細は、第10章「WebCenterアプリケーションの保護」を参照してください。これが可能でない場合は、アプリケーションの後続バージョンの事前デプロイの前に、カスタマイズの最後のエクスポートを行ってください。 |
初期デプロイ
12.1.1.1項「シナリオ1: 開発環境でのポートレット・カスタマイズ」の「初期デプロイ」に示されている手順を実行します。
後続デプロイ
次の手順で、後続デプロイのプロセスの概要を示します。
12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをエクスポート・モード（-export）で実行することにより、本番環境で行われたページおよびポートレットのカスタマイズを別個のカスタマイズ専用アーカイブ・ファイルに抽出します。
ステージング・プロセスが完了したら、開発環境で作成した汎用EARファイルを本番サーバーに転送します。
新しい汎用EARファイルを開発環境から本番プラットフォームに事前デプロイし、その後、アプリケーションの新しいバージョンを本番アプリケーション・サーバーにデプロイします。
12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをインポート・モードで実行することにより、（アップグレード・プロセス中に行われた）エクスポート済の実行時カスタマイズをインポートします。
このシナリオでは、デプロイ済アプリケーションを本番環境にデプロイする前に、ステージング環境でカスタマイズします。次の各項で、初期デプロイおよび後続デプロイのプロセスについて説明します。
初期デプロイ
次の手順で、初期デプロイのプロセスの概要を示します。
12.1.1.1項「シナリオ1: 開発環境でのポートレット・カスタマイズ」の「初期デプロイ」に示されている手順を実行します。
ステージング環境にデプロイ後、実行時カスタマイズを実行します。
12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをエクスポート・モード（-export）で実行することにより、ステージング環境で行われたページおよびポートレットのカスタマイズを別個のカスタマイズ専用アーカイブ・ファイルに抽出します。
ステージング環境でのテストが完了したら、（開発環境で生成された）元の汎用EARファイルを本番サーバーに事前デプロイし、それに応じてアプリケーションをデプロイします。
12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをインポート・モード（-import）で実行することにより、ステージング・デプロイ中に行われた実行時カスタマイズを本番環境のアプリケーションにインポートします。
後続デプロイ
カスタマイズはデプロイ後に実行されるため、アプリケーションとは別々に格納されます。この場合は、カスタマイズがステージング・デプロイ中に行われます。ステージング環境からデプロイ後に本番プラットフォームでさらにカスタマイズが行われた場合は、後続デプロイの前にこれらのカスタマイズもエクスポートし、これをそのデプロイ用の最新のカスタマイズとして使用する必要があります。
次の手順で、後続デプロイのプロセスの概要を示します。
12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをエクスポート・モード（-export）で実行することにより、本番プラットフォームのページおよびポートレットのカスタマイズを別個のカスタマイズ専用アーカイブ・ファイルに抽出します。
|
注意: アプリケーションの後続バージョンが本番サーバーにデプロイされるまでは、アプリケーションのアップグレード・プロセス中に本番アプリケーションの追加のカスタマイズを行わないようにすることをお薦めします。詳細は、第10章「WebCenterアプリケーションの保護」を参照してください。これが可能でない場合は、カスタマイズの後続エクスポートが必要になります。 |
12.1.1.1項「シナリオ1: 開発環境でのポートレット・カスタマイズ」の「初期デプロイ」の手順5〜8の説明に従って、アプリケーションの新しいバージョンをステージング・プラットフォーム上に事前デプロイおよびデプロイします。
ステージング・プラットフォームにデプロイした後は、適切なカスタマイズ・アーカイブを入力ファイルとして使用して、本番サーバーからのエンドユーザーのカスタマイズの最新セットが含まれるようにアプリケーションを更新します。このためには、12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをインポート・モード（-import）で実行します。アプリケーションをアップグレードするときは、次の点を考慮してください。
アップグレード・プロセス中に本番アプリケーションがカスタマイズ可能でないモードで実行されている場合は、手順1で作成したカスタマイズ・アーカイブを使用してください。
アップグレード・プロセス中に本番アプリケーションのカスタマイズが許可されていた場合（たとえば、ロード・テストができるように数日ないしは数週間にわたってアップグレードがステージングされていた場合など）は、変更内容をステージング・システムに適用する前に、本番システムから新しくエクスポートしたカスタマイズを使用する必要があります。この新しいエクスポートEARファイルをデプロイ前ツールの入力ファイルとして使用してください。
これにより、アプリケーションのエンドユーザーが使用するカスタマイズでステージング環境が同期されます。
|
注意: 本番実行中にエンドユーザーが実行したカスタマイズは、アプリケーションとともにデプロイされた生成済の値よりも優先されます。カスタマイズは名前付き属性または値の組によって定義されているので、アプリケーションの新しいバージョンでカスタマイズ済オブジェクトの名前付き属性に別の値が定義されていれば、インポートされた値が新しいデプロイ済バージョンを上書きするためです。これ以外の属性についてはすべて、新しいデプロイ済バージョンが使用されます。 |
アプリケーションを本番サーバーにデプロイする準備ができたら、12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールを使用して、ステージング・サーバー上で実行された後続のカスタマイズをエクスポートする必要があります。同様に、本番システムがカスタマイズ可能でないモードで実行されていなかった場合、デプロイ前ツールをエクスポート・モードで実行することにより、本番システムからエクスポートした最新のカスタマイズを使用する必要があります。
新しい汎用EARファイルを開発環境から本番プラットフォームに事前デプロイし、その後、アプリケーションの新しいバージョンを本番アプリケーション・サーバーにデプロイします。
12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをインポート・モードで実行することにより、ステージング・デプロイ中に行われた実行時カスタマイズを本番環境のアプリケーションにインポートします。
12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをインポート・モードで実行することにより、アップグレード・プロセス中に本番システムに追加された可能性のある後続のカスタマイズを適用します。
本番環境では、アプリケーションは、Application Server Controlコンソールを使用してOracle Application ServerのOC4Jにデプロイされます。
|
注意: 他に、コマンドライン・インタフェースを使用してWebCenterアプリケーションをデプロイする方法もあります。ただし、Application Server Controlコンソールは使いやすく、短時間でのデプロイが可能なので、アプリケーションをデプロイする場合はApplication Server Controlコンソールを使用することをお薦めします。 |
図12-4に、本番環境でOracle Application ServerのOC4JインスタンスにWebCenterアプリケーションをデプロイするためのプロセス・フローを示します。この図では、開発環境でOracle JDeveloperを使用して汎用EARファイルが作成されます。次に、デプロイ前ツールを使用して、汎用EARファイルからターゲットのEARファイルが作成されます。ターゲットのEARファイル内の構成ファイルが、ターゲット・システムとともに動作するように構成されます。最後に、Application Server Controlコンソールを使用して、ターゲットのEARファイルが本番環境のOracle Application ServerのOC4Jにデプロイされます。また、この図では、JAZN移行ツールによって、XMLまたはLDAPプロバイダのセキュリティ・ロールおよびポリシーの情報が開発環境から本番環境に移行されます。
図12-4 Oracle Application ServerのOC4JへのWebCenterアプリケーションのデプロイ
汎用EARファイルを作成する手順を、パッケージ化といいます。ターゲットのEARファイルを作成する手順を事前デプロイといい、ターゲットのEARファイルをOC4Jにデプロイする手順をデプロイといいます。本番環境では、WebCenter Antタスクを使用してWebCenterアプリケーションをデプロイすることもできます。
開発者は実行時にアプリケーションを頻繁にテストする必要があるため、開発環境ではアプリケーションのデプロイをすばやく行う必要があります。Oracle JDeveloperを使用すると、WebCenterアプリケーションを次のインスタンスにデプロイできます。
Oracle JDeveloperと同じシステムで実行されている、またはMDSの場所として共有ネットワーク・ドライブを使用している、スタンドアロンのOC4Jインスタンス（図12-5を参照）
Oracle JDeveloperと同じコンピュータ上で実行されているOracle Application Server上のOC4Jインスタンス
この場合、OC4Jにデプロイすると、Oracle JDeveloperによって自動的にデプロイ前ツールが実行されます。ただし、このような単純なデプロイでは、ポートレット・プロデューサのエンド・ポイントを変更できません。また、MDSは開発環境からアクセス可能である必要があります。さらに、汎用EARファイルの一部であるapp-jazn-data.xmlファイルに対してJAZN移行ツールを実行して、アプリケーションのデプロイ先のOC4Jインスタンスに対するsystem-jazn-data.xmlファイルを更新する必要があります。詳細は、12.2.6.2項「スタンドアロンOC4Jへのデプロイ」を参照してください。
図12-5 埋込みOC4JインスタンスおよびスタンドアロンOC4JインスタンスへのWebCenterアプリケーションのデプロイ
また、Oracle JDeveloperの埋込みOC4Jを使用すると、ブラウザでアプリケーションをすばやくテストできます。詳細は、12.2.6.1項「埋込みOC4Jへのデプロイ」を参照してください。
Oracle WebCenter Suiteで使用可能なデプロイ前ツールを使用すると、ステージング環境から本番環境にポートレット・カスタマイズをトランスポートできます。ポートレット・カスタマイズの一般的なシナリオは、ポートレット・タイトルの変更やOmniPortletの定義などです。
図12-6に示すように、デプロイ前ツールを使用すると、ステージング環境で行ったカスタマイズをエクスポートして本番環境にインポートできます。同様に、本番環境からカスタマイズをエクスポートして、ステージング環境にインポートできます。このためには、12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、デプロイ前ツールをエクスポート・モードおよびインポート・モードで実行します。
Application Server Controlコンソールを使用して、WebCenterアプリケーションを本番環境にデプロイできます。このプロセスでは、WebCenterアプリケーションを汎用EARファイルまたはWARファイル内にパッケージ化します。その後、このファイルに対してデプロイ前ツールを実行して、WebCenterアプリケーションの外部依存性（ポートレット・プロデューサのエンド・ポイントとMDSの場所など）を再マップします。デプロイ前ツールを使用すると、リモート・システムにすぐにデプロイできるターゲットのEARファイルが生成されます。さらに、セキュリティ、コンテンツ統合および外部アプリケーションに関連するいくつかの作業を、デプロイ・プロセスの一部として実行する必要があることもあります。
次の各項で、デプロイ関連の作業の実行方法を学びます。
WebCenterアプリケーションをデプロイするには、すべての必要なファイルを標準のJ2EE形式およびディレクトリ構造でEARファイル内にパッケージ化する必要があります。WebCenterアプリケーションのパッケージ化およびデプロイに関する指示はすべて、デプロイメント・プロファイルを介して構成されます。デプロイメント・プロファイルにより、アプリケーションのデプロイに必要なすべてのコンポーネントが管理されます。これは基本的には構成ファイルで、ページ名、ポートレット名、カスタマイズ名、アプリケーションを構成するメタデータ名、作成するアーカイブ・ファイルのタイプと名前、依存性情報、プラットフォーム固有の指示などが含まれています。
この項の内容は、次のとおりです。
この項では、WebCenterアプリケーションをパッケージ化する前に知っておく必要のある重要な要素について説明します。この項の内容は、次のとおりです。
セキュリティ情報のパッケージ化に関する必要な知識
OC4Jのポリシー情報には、アプリケーションの権限、ユーザー、ロールおよびロール・メンバーシップが含まれます。この情報は通常、system-jazn-data.xmlファイル内に格納されています。WebCenterアプリケーション固有のポリシー情報は、app-jazn-data.xmlファイル内に格納されています。このファイルは、ポリシー情報が変更されると更新されます。本番環境では、app-jazn-data.xmlファイルは、Lightweight Directory Interchange Format（LDIF）ファイルまたは本番system-jazn-data.xmlファイルを更新するJAZN移行ツールの入力ファイルとして使用されます。LDIFファイルは、管理者が使用できるようにOracle Internet Directoryにインポートされます。詳細は、12.2.4項「セキュリティおよびアプリケーション・ロールの移行」を参照してください。
外部アプリケーションのパッケージ化に関する必要な知識
外部アプリケーションをパッケージ化するときは、次の点を考慮してください。
外部アプリケーションをパッケージ化する前に、外部アプリケーション内に事前定義されている値（ログインURLなど）が本番環境で必要な値を指していることを確認してください。これらの値は事前デプロイ・ステージでは変更できないので、これは必ず実行してください。これに対し、WebCenterアプリケーションのプロデューサURLは、ターゲットのEARファイルの生成中に変更できます。
外部アプリケーションが別のコンピュータまたはインスタンス上に存在している場合は、デプロイメント・プロファイルからEARファイルを作成する前に、外部アプリケーション・ログインURLを更新する必要があります。ログインURLの最初の部分を、新しいホスト名を反映するように変更します。たとえば、http://m1.abc.com:7777/からhttp://lbr.abc.com/に変更します。
WebCenterアプリケーションをデプロイするには、WebCenterアプリケーションWARデプロイメント・プロファイルを使用する必要があります。このプロファイルは、後で汎用EARファイルに含められます（12.2.1.4項「汎用EARファイルの作成」を参照）。
|
注意: WebCenterアプリケーションにポートレットおよびプロデューサが含まれる場合は、デプロイメント・プロファイルを作成する前に、最初のプロデューサを登録してください。プロデューサの登録については、4.3.1項「ポートレット・プロデューサの登録」を参照してください。最初のプロデューサ登録時に、MDSインスタンス定義がadf-config.xmlファイルに作成されます。MDSファイル・コントリビュータを定義するために、デプロイメント・プロファイル作成プロセスでは、このMDSインスタンス定義が使用されます。 |
デプロイメント・プロファイルを作成する手順は、次のとおりです。
アプリケーション・ナビゲータで、「ViewController」フォルダを選択します。次に、「ファイル」メニューから「新規」を選択します。新規ギャラリ・ウィンドウが表示されます。
「フィルタ方法」で「プロジェクト・テクノロジ」を選択し、「General」で「Deployment Profiles」を選択します。次に、（図12-7に示すように）「項目」リストで「WebCenterアプリケーションWAR」を選択し、「OK」をクリックします。
WebCenterアプリケーション・デプロイメント・プロファイルの作成ウィンドウが表示されます。デプロイメント・プロファイルの名前を入力し、「OK」をクリックします。デプロイメント・プロファイル（.deploy）が、「リソース」フォルダの下に作成されます。
アプリケーション・ナビゲータに移動し、「リソース」フォルダを開きます。次に、デプロイメント・プロファイルを右クリックし、「プロパティ」を選択します。WARデプロイメントのプロパティ・ダイアログ・ボックスが表示されます。
「一般」で「J2EE Webコンテキスト・ルートを指定」を選択し、対応するフィールドにJ2EEコンテキスト・ルートを入力します。
「プラットフォーム」を選択し、「ターゲット接続」から接続を選択します。接続がない場合は、12.2.6.2.1項「スタンドアロンOC4Jの接続詳細の定義」を参照してください。ユーザーは、このオプションを使用して、Oracle Application ServerのOC4Jインスタンスへの接続を指定できます。
|
注意: 「ターゲット接続」から接続を選択した場合、EARファイルを作成すると、orion-application.xmlが自動的に更新されます。接続を作成できない場合は、12.2.1.3項「orion-application.xmlファイルの手動での作成および編集」の説明に従って、手動でorion-application.xmlファイルを追加する必要があります。 |
手動でorion-application.xmlファイルを作成するには、デプロイメント・ディスクリプタを作成し、./adfライブラリ・パスを指定する必要があります。このパスは、アプリケーションの事前デプロイ中にデプロイ前ツールで使用されるadf-config.xmlファイルを指している必要があります（12.2.2項「WebCenterアプリケーションの事前デプロイ」を参照）。
orion-application.xmlファイルを手動で作成して編集する手順は、次のとおりです。
Oracle JDeveloperで、プロジェクトを選択し、「ファイル」に移動して「新規」を選択します。新規ギャラリ・ウィンドウが表示されます。
図12-8に示すように、「General」で「デプロイメント・ディスクリプタ」を選択し、「項目」で「OC4Jデプロイメント・ディスクリプタ・ウィザード」を選択します。
「OK」をクリックします。「デプロイメント・ディスクリプタの作成 - ようこそ」ページが表示されます。
「次へ」をクリックして、「ディスクリプタの選択」ページを表示します。
図12-9に示すように、orion-application.xmlを選択し、「次へ」をクリックして「バージョンを選択」ページを表示します。
図12-10に示すように、「10.0」を選択し、「次へ」をクリックします。
「終了」をクリックして、orion-application.xmlの作成を完了します。
orion-application.xmlファイルを表示するには、図12-11に示すように、アプリケーション・ナビゲータでプロジェクトに移動し、「アプリケーション・ソース」フォルダおよび「META-INF」フォルダを開きます。
「orion-application.xml」ファイルをダブルクリックして開きます。
コンポーネント・パレットがまだ開かれていない場合は、開きます。図12-12に示すように、「OC4Jアプリケーション」オプションを選択し、「ライブラリ」を選択します。
「ライブラリ」ノードをorion-application.xmlページにドロップします。<library> </library>要素が追加されます。
プロパティ・インスペクタで、pathに./adfを入力します。
「OC4Jアプリケーション」から、「jazn」を選択してページ上にドロップします。
プロパティ・インスペクタで、locationに./jazn-data.xmlを入力し、Providerに「XML」を選択します。
次に、「data-sources」を選択してページ上にドロップします。
プロパティ・インスペクタで、pathに./data-sources.xmlを入力します。例12-1に、サンプルのorion-application.xmlファイルを示します。
例12-1 サンプルのorion-application.xmlファイル
<?xml version = '1.0'?> <orion-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-application-10_0.xsd"> <library path="./adf" /> <jazn location="./jazn-data.xml" provider="XML"/> <data-sources path="./data-sources.xml"/> </orion-application>
汎用EARファイルを作成するには、「name.deploy」ファイルを右クリックし、「EARファイルにデプロイ」を選択します。「デプロイ - ログ」ウィンドウに、デプロイが完了したというメッセージが表示されます。
Windowsの場合、EARファイルのデフォルトの場所は、ORACLE_HOME\jdev\mywork\MyApplication\ViewController\deployです。
Linuxの場合、EARファイルのデフォルトの場所は、ORACLE_HOME/jdev/mywork/MyApplication/ViewController/deployです。
Oracle JDeveloperで使用されるこの場所を変更し、任意の場所にアプリケーションを作成することもできます。このためには、アプリケーション・ナビゲータでデプロイメント・プロファイル（.deploy）を右クリックし、「プロパティ」を選択します。WARデプロイメントのプロパティ・ダイアログ・ボックスの「一般」タブで、EARファイルおよびWARファイルのパスを変更します。また、アプリケーション名を変更することもできます。
汎用EARファイルは、デプロイ前ツールでターゲットのEARファイルを作成するために使用されます。このファイルは、Application Server Controlコンソールを使用して、本番環境でOracle Application ServerのOC4Jにデプロイされます。
WebCenterアプリケーションEARファイルをOracle Application ServerのOC4Jにデプロイする前に、ファイル内に含まれている開発参照を、ターゲット・インスタンスに固有になるように変更する必要があります。ターゲットのEARファイルを作成するには、デプロイ前ツールを使用します。ターゲットのEARファイルは通常、アプリケーションのデプロイ先の、Oracle Application Serverがインストールされているコンピュータ上に作成されます。これによって確実に、MDSディレクトリがターゲット・システムの適切な場所に作成され、ターゲットのEARファイルに適切なMDSパスが含まれます。ターゲットのEARファイルは、Application Server Controlコンソールを使用して、Oracle Application ServerのOC4Jにデプロイされます。
EARファイルがデプロイ前ツールを介して実行されるとき、次の処理が実行されます。
ターゲット・システム上にMDSストアが作成されます。
adf-config.xmlファイルが更新されます。このファイル内の既存のMDSディレクトリは、開発環境を指しています。MDSは、WebCenterアプリケーションに固有のメタデータ（ページ・カスタマイズなど）が格納される専用ストアです。デプロイ前ツールによって、プロンプトに従って指定した場所に基づいて、MDSディレクトリが本番環境に変更されます。
connections.xmlファイルが更新されます。このファイル内に含まれているプロデューサのURLおよびプロキシ情報は、デプロイ前ツールのプロンプトに従って指定した入力に基づいて更新されます。
ポートレット・カスタマイズがMDSエクスポート・データ・セットから本番プロデューサにインポートされます。つまり、ターゲット・システム上にMDSストアが作成されます。ただし、事前デプロイやエクスポート/インポートの間、資格証明ストアは移行されません。
この項の内容は、次のとおりです。
WebCenterアプリケーションを事前デプロイするときは、次の点を考慮してください。
デプロイ前ツールは、接続詳細やその他の公開済設定を再構成するために、いつでも実行できます。アプリケーションを事前デプロイした後は、アプリケーションを再デプロイする必要があります。
汎用EARファイルには、Oracle JDeveloperにより設定された相対パスが含まれます。複数のパスを指定するには、../../mds/;../../のように、カンマ区切りのリストで指定します。ただし、デプロイ前ツールを使用してターゲットのEARファイルにデプロイする場合、profile.xmlファイル内にはMDSパスは1つしか指定できません。また、このMDSパスは絶対パス（C:\MDS\deployなど）にする必要があります。
デプロイ前ツールでは、終わりのスラッシュ（/）がないMDSパスが受け入れられます。
共有MDSパス（つまり、ネットワークにマウントされたドライブ）は、ローカル・ドライブとして扱われます。格納されるMDSパスは、ターゲットのEARファイルのデプロイ先のコンピュータからマウントしたドライブのパスである必要があります。共有MDSを使用する場合は、デプロイ前ツールを1回のみ実行して、ターゲットのEARファイルを生成する必要があります。その後、ターゲットのEARファイルを他のOC4Jインスタンスにデプロイします。Oracle JDeveloperを使用してMDSパスを選択する方法の詳細は、12.2.6.2.2項「スタンドアロンOC4JへのWebCenterアプリケーションのデプロイ」を参照してください。
Oracle Application ServerのOC4Jの複数のインスタンスが1つのMDS場所を共有している場合は、それぞれの場所でadf-config.xmlファイルを手動で更新して、その場所からの共有MDSのパスを指定します。MDSがマウントされているドライブはインスタンスごとに異なる可能性があるため、これは必ず実行してください。たとえば、2つのOC4Jインスタンスがあり、一方のインスタンスではMDSがドライブFにマウントされていて、もう一方のインスタンスではMDSがドライブEにマウントされている場合、両方のOC4Jインスタンスでadf-config.xmlファイルを更新する必要があります。ただし、すべてのOC4Jインスタンスで常にマウント・ポイントは同一にしておけば、マウント・ポイントが異なるためにadf-config.xmlファイルを更新しなくてもよいので、この方法をお薦めします。
外部アプリケーションを事前デプロイする前に、外部アプリケーション内に事前定義されている値（ログインURLなど）が本番環境で必要な値を指していることを確認してください。これらの値はデプロイ前やデプロイ後には変更できないので、これは必ず実行してください。これに対し、WebCenterアプリケーションのプロデューサURLは、ターゲットのEARファイルの生成中に、デプロイ前ツールを使用して変更できます。
Secure Sockets Layer（SSL）対応のプロデューサにアクセスする場合で、プロデューサのセキュリティ証明書がキーストア内にリストされない場合は、アプリケーションを事前デプロイする前に、セキュリティ証明書をキーストアに登録する必要があります。このためには、10.8項「キーストアへのカスタム証明書の登録」に示された手順に従ってください。
デプロイ前ツールでは、署名付きのEARファイルはサポートされていません。
デプロイ前ツールでは、ポートレットが含まれるWebCenterアプリケーションでセキュアな接続を再構成することはサポートされていません。
デプロイ前ツールでは、ファイル・システム・アダプタ接続、OracleAS Portalアダプタ接続およびOracle Content Serverアダプタ接続の再マッピングはサポートされていません。そのため、「OracleAS Portalアダプタ、Oracle Content Serverアダプタおよびファイル・システム・アダプタの再構成」の説明に従って、これらの接続を手動で再構成する必要があります。
この項では、WebCenterアプリケーションおよびコンテンツ統合アプリケーションの事前デプロイの手順を示します。この項の内容は、次のとおりです。
デプロイ前ツールを使用したWebCenterアプリケーションの事前デプロイ
デプロイ前ツールは、汎用EARファイルからターゲットのEARファイルを作成するために使用されます。
デプロイ前ツールでは、-jar javaコマンドラインを使用します。これにより、ツールの適切なクラスパスとメイン・クラスを確認するportlet-client-deploy.jarがコールされます。デフォルトでは、デプロイ前ツールのJARおよびその依存性は、ORACLE_HOME/adfp/lib内に格納されています。
アプリケーションを事前デプロイするには、ターゲット・システムのORACLE_HOMEから次のコマンドを実行します。
|
ヒント: デプロイ前ツールへの引数に絶対パスが指定されている場合は、他の任意のディレクトリからこのコマンドを実行できます。 |
ORACLE_HOME/jdk/bin/java -jarORACLE_HOME/adfp/lib/portlet-client-deploy.jar -predeploy -source<genericEAR>-target<targetedEAR>[ -configuration<config file>[-profile<profile name>] ] -backup <directory path>
これらの意味は、次のとおりです。
portlet-client-deploy.jarは、デプロイ前ツールの実行元の事前デプロイJARファイルです。
genericEARは、Oracle JDeveloperを使用して作成された汎用EARファイルです。
targetedEARは、デプロイ前ツールによって事前デプロイ中に作成されるターゲットのEARファイルです。
config fileは、XMLマッピング・ファイルです。例12-2に示すように、これには1つ以上の事前デプロイ・プロファイルに関する情報が含まれます。1つの構成ファイルに、複数の事前デプロイ・プロファイルが含まれることもあります。その場合は、デプロイ前ツールの実行時に使用するプロファイルを指定する必要があります。構成ファイルに1つしかプロファイルがない場合、プロファイル名を指定する必要はありません。例12-3に、複数のプロファイルが含まれる構成ファイルのサンプルを示します。
profileは、XMLマッピング・ファイル内で特定の事前デプロイ・プロファイルを指定するために使用する名前です。マッピング・ファイル内にプロファイル名を指定しない場合は、ツールによってエントリが存在することがチェックされます。エントリが1つしか存在しない場合は、そのエントリがツールにより使用されます。しかし、複数のエントリが存在する場合は、どのエントリを使用するかを判断できないため、エラーが生成されます。
|
注意: WSRPポートレットでは、ポートレットのXSDファイルがOASISなどの外部サイトに存在している場合、デプロイ前ツールがその外部サイトから検証情報を取得します。デプロイ前ツールがインターネットから検証を取得できるようにするには、次の例に示すように、-jarフラグの前に標準のJavaプロキシ構成プロパティを指定します。
|
-backupはオプションです。これは、Oracle Application Serverのアプリケーション・ホーム内のターゲットのEARファイルのパス（ORACLE_HOME/j2ee/home/applications/YourApplication）を値として受け入れます。ユーザーが事前デプロイ中に入力したMDSパスがバックアップの一部として含まれるように、指定されたORACLE_HOMEのバックアップおよびリカバリ構成が更新されます。次の例に、-backupオプションの使用方法を示します。
ORACLE_HOME\jdk\bin\java -jar portlet-client-deploy.jar -sourcec:\EAR\sample.ear-targetc:\EAR\sampleTarget2.ear-predeploy -backupORACLE_HOME\j2ee\home\applications\sampleTarget2
この例では、デプロイ前ツールの実行中に指定したMDSパスが、<ORACLE_HOME>/backup_restore/config/config_misc_files.inp内で更新されています。config_misc_files.inpファイルはすでに存在しており、MDSパスが追加されています。詳細は、『Oracle Application Server管理者ガイド』のバックアップの計画および手順に関する項を参照してください。
例12-2に、1つのプロファイルが含まれる構成ファイルのサンプルを示します。
例12-2 1つのプロファイルが含まれる構成ファイルのサンプル
<?xml version = '1.0' encoding = 'UTF-8'?>
<DeployConfig xmlns="http://xmlns.oracle.com/webcenter/lifecycle/deployconfig">
<profile name="Production">
<mds_metadata_path>
/home/mydirectory/mdstest
</mds_ metadata_path>
<producers>
<producer name="MyWebProducerConnection" proxyHost="" proxyPort="0"
serviceURL="http://host_name:port/adapter/portal"/>
</producers>
</profile>
</DeployConfig>
例12-3に、複数のプロファイルが含まれる構成ファイルのサンプルを示します。
例12-3 複数のプロファイルが含まれる構成ファイルのサンプル
<?xml version = '1.0' encoding = 'UTF-8'?>
<DeployConfig xmlns="http://xmlns.oracle.com/webcenter/lifecycle/deployconfig">
<profile name="Production">
<mds_metadata_path>
/WorkEnvLifecycle/Lifecycle/jpswork/components/Lifecycle/data/MDS
</mds_metadata_path>
<producers>
<producer name="WSRPProducerConnection1" proxyHost="www-proxy.my.company.com" proxyPort="80"
serviceURL="http://host:port/adapter/portal/portletapp/portlets/WSRPBaseService?WSDL"/>
</producers>
</profile>
<profile name="portletArchiveWSRP203760">
<mds_metadata_path>
/WorkEnvLifecycle/Lifecycle/jpswork/components/Lifecycle/data/MDS
</mds_metadata_path>
<producers>
<producer name="WSRPProducerConnection1" proxyHost="www-proxy.my.company.com" proxyPort="80"
serviceURL="http://host:port/adapter/portal/nonexist/portlets?ABCD"/>
</producers>
</profile>
<profile name="portletArchiveWSRP203750">
<mds_metadata_path>
/WorkEnvLifecycle/Lifecycle/jpswork/components/Lifecycle/data/NoPermission
</mds_metadata_path>
<producers>
<producer name="WSRPProducerConnection1" proxyHost="www-proxy.my.company.com" proxyPort="80"
serviceURL="http://host:port/adapter/portal/portletapp/portlets/WSRPBaseService?WSDL"/>
</producers>
</profile>
<profile name="portletArchiveWSRP197300">
<mds_metadata_path>
/WorkEnvLifecycle/Lifecycle/jpswork/components/Lifecycle/data/MDS/197300
</mds_metadata_path>
<producers>
<producer name="WSRPProducerConnection1" proxyHost="www-proxy.my.company.com" proxyPort="80"
serviceURL="http://host:port/adapter/portal/portletapp/portlets/WSRPBaseService?WSDL"/>
</producers>
</profile>
例12-4に、デプロイ前ツールでWebCenterアプリケーションの事前デプロイ中に生成される出力のサンプルを示します。構成ファイルを指定しない場合は、デプロイ前ツールによって、情報を入力するように要求されます。サンプル内の太字の部分が、このプロンプトです。
例12-4 WebCenterアプリケーションのデプロイ前ツールの出力
http://host:port/jpdk/providers/sample$ java -jar portlet-client-deploy.jar -source /Automation/PDKValid1.ear -target /Automation/PDKValid1Target1.ear -predeploy Processing Arguments Run Mode : 1 Source : /Automation/PDKValid1.ear Target : /Automation/PDKValid1Target1.ear ... Cleaning up /tmp/predeploy/ Processing source EAR file Source EAR file processed Processing adf-config.xml ... Producer : PdkPortletProducer1_11605536060373662ab97-010e-1000-8001-984463fc1d8d Current Service URL : http://host:port/jpdk/providers/sample Current Proxy URL : Current Proxy Port : 0 Do you want to modify this connection? (Y/N [default=N]) : Y Enter new Service URL (or Enter to leave it as it is): http://newhost:newport/jpdk/providers/sample Do you want to save this new Deployment Profile (Y/N [default=N]) : Y Enter a name for this Deployment Profile (e.g. 'Production') : PDKValid1 Enter the path for the Deployment Profile XML file (e.g. 'C:\profile.xml'): /JDEV/DepFiles/PDKValid1.cml ... MDS extracted from source EAR file Creating target EAR file Processing source EAR file ... source MDS Path (temp) : /tmp/predeploy/mds Production MDS Path : /MDS/PDKValid1 Connections.xml Path : /tmp/predeploy/connections.xml.new Export ID : /export <Date> <Time> oracle.mds ... Backing up existing target EAR to /Automation/PDKValid1Target1.ear.old Moving /tmp/predeploy/PDKValid1Target1.ear to /Automation/PDKValid1Target1.ear Target EAR /Automation/PDKValid1Target1.ear created Cleaning up /tmp/predeploy/
WSRPポートレット・プロデューサの再構成
デプロイ前ツールでは、WSRPポートレット・プロデューサを再構成することはサポートされていません。このため、WS-Securityが実装されている本番環境にWebCenterアプリケーションをデプロイする場合は、Oracle JDeveloperを使用して、開発環境内にWSRPプロデューサURLを登録します。プロデューサURLを登録する方法の詳細は、4.3.1.1項「WSRPポートレット・プロデューサの登録」を参照してください。
Oracle Content DBベースのコンテンツ統合アプリケーションのパラメータの再構成
事前デプロイ・フェーズ中に、デプロイ前ツールを使用すると、Oracle Content DBベースのコンテンツ統合アプリケーションのパラメータを再構成できます。デプロイ前ツールを使用して、Oracle Content DBの10.1.3.2バージョンと10.2バージョンの両方のパラメータを再構成できます。Oracle Content DBパラメータの詳細は、5.2.4項「Oracle Content DBアダプタに基づいたコンテンツ・データ・コントロールの構成」および5.2.5項「Oracle Content DBリリース10.2に基づいたコンテンツ・データ・コントロールの構成」を参照してください。
|
注意: Oracle Content DBに基づいたコンテンツ統合アプリケーションのパラメータを再構成している間、非セキュアな接続をセキュアな接続と再マップしたり、セキュアな接続を非セキュアな接続と再マップすることはできません。このため、マップする接続は必ず同じタイプにしてください。 |
デプロイ前ツールを実行してOracle Content DBパラメータを再構成すると、表12-1に示すようなプロンプトが表示されます。
表12-1 デプロイ前ツールでプロンプト表示されるパラメータ
| パラメータ | 値（WS-Securityが実装されている場合） | 値（S2Sが実装されている場合） |
|---|---|---|
|
この接続を変更しますか。(Y/N [デフォルト=N]): |
|
|
|
''サーバーのURL''の値(変更しない場合は[Enter]を押します): |
サーバーURLを、http:// |
サーバーURLを、http:// |
|
''サーバーのバージョン''の値(変更しない場合は[Enter]を押します): |
|
|
|
''信頼できる認証方式''の値(変更しない場合は[Enter]を押します): |
|
|
|
''S2Sアプリケーション名''の値(変更しない場合は[Enter]を押します): |
空白のままにしておきます。 |
アプリケーションの名前を入力します。これは、Oracle Internet Directory内で構成され、ここではS2Sアプリケーション・パスワードとともに設定する必要があります。 |
|
''キーストア・ファイルの場所''の値(変更しない場合は[Enter]を押します): |
本番環境でキーストア・ファイルを配置する場所を入力します。 |
空白のままにしておきます。 |
|
''キーストア・タイプ''の値(変更しない場合は[Enter]を押します): |
キーストア・タイプは通常、 |
空白のままにしておきます。 |
|
''サーバーの公開鍵別名''の値(変更しない場合は[Enter]を押します): |
キーストアの構成中に指定した別名の値を入力します。 |
空白のままにしておきます。 |
|
''秘密鍵別名''の値(変更しない場合は[Enter]を押します): |
キーストアの構成中に指定した秘密鍵の別名を入力します。 |
空白のままにしておきます。 |
|
注意: セキュリティ設定が存在しない場合は、URLのみを指定し、[Enter]を押して他のパラメータをスキップします。 |
例12-5に、Oracle Content DBバージョン10.1.3.2のパラメータの再マッピングを示します。
例12-5 Oracle Content DBバージョン10.1.3.2ベースのアプリケーションに対するデプロイ前ツールのサンプル出力
Development MDS Repository Path : C:\adfsrdemojsf\mds;C:\adfsrdemojsf ... What is the value of 'Server URL' (or Enter to leave it as is): http://yourhost:port/content/ws What is the value of 'Server Version' (or Enter to leave it as is): 10.3.1.2 What is the value of 'Trusted Authentication Method' (or Enter to leave it as is): WS-Security What is the value of 'S2S Application Name' (or Enter to leave it as is): <blank> What is the value of 'KeyStore File Location' (or Enter to leave it as is):/private1/keystore/client-keystore.jks What is the value of 'KeyStore Type' (or Enter to leave it as is): JKS What is the value of 'Server Public Key Alias' (or Enter to leave it as is): server What is the value of 'Private Key Alias' (or Enter to leave it as is): keyalias
OracleAS Portalアダプタ、Oracle Content Serverアダプタおよびファイル・システム・アダプタの再構成
OracleAS Portalおよびファイル・システム・リポジトリを、別のインスタンスを指すように再構成する場合は、手動でconnections.xmlファイルを編集する必要があります。デプロイ後、connections.xmlファイルは次の場所にあります。
ORACLE_HOME/j2ee/home/applications/Application name/adf/META-INF/
例12-6に、ファイル・システム・アダプタを再構成するために変更が必要なconnections.xmlファイルのセグメントを示します。
例12-6 ファイル・システム・アダプタ用のconnections.xml
<StringRefAddr addrType="jcr_basePath">
<Contents>/private/myfiles</Contents>
</StringRefAddr>
例12-7に、OracleAS Portalアダプタを再構成するために変更が必要なconnections.xmlファイルのセグメントを示します。
例12-7 OracleAS Portalアダプタ用のconnections.xml
<StringRefAddr addrType="jcr_dataSourceName">
<Contents>jdbc/DBConnection1DS</Contents>
</StringRefAddr>
|
注意: OracleAS Portalに基づいたコンテンツ統合アプリケーションのパラメータを再構成している間、非セキュアな接続をセキュアな接続と再マップしたり、セキュアな接続を非セキュアな接続と再マップすることはできません。このため、マップする接続は必ず同じタイプにしてください。 |
例12-8に、Oracle Content Serverアダプタのwebタイプ接続を再構成するために変更が必要なconnections.xmlファイルのセグメントを示します。
例12-8 Oracle Content Serverアダプタのwebタイプ接続
<StringRefAddr addrType="jcr_oracle.stellent.jcr.configuration.server.web.url">
<Contents>http://host:port/idc/idcplg</Contents>
</StringRefAddr>
<StringRefAddr addrType="jcr_oracle.stellent.jcr.configuration.cis.config.socket.type">
<Contents>web</Contents>
</StringRefAddr>
例12-9に、Oracle Content Serverアダプタのsocketタイプ接続を再構成するために変更が必要なconnections.xmlファイルのセグメントを示します。
例12-9 Oracle Content Serverアダプタのsocketタイプ接続
<StringRefAddr addrType="jcr_oracle.stellent.jcr.configuration.server.host">
<Contents>host</Contents>
</StringRefAddr>
<StringRefAddr addrType="jcr_oracle.stellent.jcr.configuration.server.port">
<Contents>port</Contents>
</StringRefAddr>
<StringRefAddr addrType="jcr_oracle.stellent.jcr.configuration.cis.config.socket.type">
<Contents>socket</Contents>
</StringRefAddr>
この項では、Application Server Controlコンソールを使用してWebCenterアプリケーションをデプロイおよびテストする手順を示します。この項の内容は、次のとおりです。
Application Server Controlコンソールを使用してアプリケーションをデプロイするには、アプリケーションのターゲットのEARファイルが必要です。ターゲットのEARファイルは、アプリケーションをデプロイするシステム上に作成する必要があります。まだ汎用EARファイルを作成していない場合は12.2.1項「WebCenterアプリケーションのパッケージ化」を、ターゲットのEARファイルを作成していない場合は12.2.2項「WebCenterアプリケーションの事前デプロイ」を参照してください。
|
注意: アプリケーションをOC4Jにデプロイする方法の詳細は、Oracle Technology Network（OTN）のOracleAS Portalドキュメントのページで、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。 |
Application Server Controlコンソールを使用してアプリケーションをデプロイする手順は、次のとおりです。
Application Server Controlコンソールにアクセスするには、http://<host_name>.<domain>:<port>/emにナビゲートします。
たとえば、http://test.acme.com:8888/emにナビゲートします。
Application Server Controlコンソールの正確なURLを調べるには、readme.txtを参照してください。インストール後、このテキスト・ファイルは次のOracle Application Server場所に保存されます。
UNIXの場合: ORACLE_HOME/install/readme.txt
Windowsの場合: ORACLE_HOME\install\readme.txt
Application Server Controlコンソールにログインします。「クラスタ・トポロジ」ページが表示されます。
「クラスタ・トポロジ」ページで、アプリケーション・サーバーへのリンクをクリックします。
「システム・コンポーネント」で、「OC4Jインスタンスの作成」ボタンをクリックします。「OC4Jインスタンスの作成」ページが表示されます。
OC4Jインスタンスに名前（myoc4jなど）を指定します。
「作成後にこのOC4Jインスタンスを起動します。」チェック・ボックスが選択されていないことを確認します。
「作成」をクリックします。
Oracle Application Serverで、作成したOC4Jインスタンスを選択します。
「アプリケーション」タブ（図12-13）を選択し、「デプロイ」をクリックします。「デプロイ: アーカイブの選択」ページが表示されます。
図12-13 Application Server Controlコンソールの「アプリケーション」タブ
EARファイルがローカル・コンピュータに存在している場合は、図12-14に示すように、「アーカイブはローカル・ホストに存在します。アーカイブをApplication Server Controlが稼働しているサーバーにアップロードします。」オプションを選択し、EARファイルの場所を参照するか、「アーカイブはApplication Server Controlが稼働しているサーバーにすでに存在します。」オプションを選択します。次に、「次へ」をクリックします。
図12-14 Application Server Controlコンソールの「デプロイ: アーカイブの選択」
|
注意: 「再デプロイ」ボタンを使用すると、アプリケーションを再デプロイできます。また、ここからアプリケーションを停止および再起動することもできます。 |
「デプロイ: アプリケーション属性」ページ（図12-15）で、WebCenterアプリケーションのコンテキスト・ルートをアプリケーション名として入力するか、12.2.1.2項「WebCenterアプリケーションWARデプロイメント・プロファイルの作成」の説明に従ってデプロイメント・プロファイルを作成したときに構成した内容を入力します。
図12-15 Application Server Controlコンソールの「アプリケーション属性」
図12-16に示すように、「デプロイ設定」ページが表示されます。必要な場合、このページで変更を行って、「デプロイ」をクリックします。
|
注意: JAZN移行ツールを実行してセキュリティ・ポリシーの移行を完了していない場合は、「セキュリティ・プロバイダ」の選択を保留できます。 |
図12-16 Application Server Controlコンソールの「デプロイ設定」
図12-17に示すように、デプロイの「確認」ページが表示されます。
12.2.4項「セキュリティおよびアプリケーション・ロールの移行」の説明に従って、セキュリティ情報を移行します。
ブラウザ・ウィンドウを開き、アプリケーションのようこそページにナビゲートします。デプロイメント・プロファイル内に定義されているコンテキスト・ルートを使用するURL、/faces/、ページ名の順に入力する必要があります。必要なURL書式は、http://<host>:<port>/<context-root>/faces/<page-name>です。
次に例を示します。
http://localhost:8888/SRApplication/faces/Welcome.jspx
これらの意味は、次のとおりです。
12.2.1.2項「WebCenterアプリケーションWARデプロイメント・プロファイルの作成」で説明されているように、SRApplicationは、デプロイメント・プロファイル内に指定されているコンテキスト・ルートです。
WebCenterアプリケーションをデプロイした後は、JAZN移行ツールを使用して、アプリケーションのレルムおよびポリシー情報を移行する必要があります。このセキュリティ情報のデプロイを容易にするために、Oracle JDeveloperによって、アプリケーションの特定のポリシーがapp-jazn-data.xmlファイル内にパッケージ化されます。開発環境では、app-jazn-data.xmlはアプリケーションの.adf\META-INFディレクトリ内に配置されています。デプロイ後、このファイルはディレクトリORACLE_HOME/j2ee/<oc4j_instance>/applications/<app-name>/adf/META-INFに解凍されます。
app-jazn-data.xmlファイルは、Oracle JDeveloperの認可エディタを使用して、アプリケーション内でポリシーが定義されるときに作成されます。開発者がページまたはコンポーネント（イテレータやデータ・コントロールなど）のポリシーを更新するたびに、（JDEV_HOME\system\oracle.j2ee.10.1.3.xx.xx\embedded-oc4j\config内にある）Oracle JDeveloperの埋込みOC4Jのsystem-jazn-data.xmlが更新されます。同時に、これらの変更内容はファイルapp-jazn-data.xmlにも伝播されます。app-jazn-data.xmlファイルに含まれる要素および属性は、OC4Jのsystem-jazn-data.xmlファイルのサブセットです。
|
関連項目: 『Oracle Containers for J2EEセキュリティ・ガイド』の「OracleAS JAAS Provider構成ファイル」 |
JAZN移行ツールを使用してセキュリティ情報を移行する場合、この情報の宛先はファイル・ベースのプロバイダ（system-jazn-data.xmlなど）またはLDAPプロバイダのいずれかになります。宛先がLDAPプロバイダの場合、移行ツールからの出力はLDIFファイルになります。このファイルは、その後、LDAPディレクトリ（Oracle Internet Directoryなど）にロードする必要があります。
この項の内容は、次のとおりです。
JAZN移行ツールでは、次の操作モードがサポートされています。
realmモード: このモードは、ユーザーおよびロールのみを移行する場合に使用します。移行モードがrealmまたはallの場合、ソース・レルム内のすべてのユーザーが移行されます。
出力LDIFファイルが生成されると、jazn-data.xmlからのパスワードがクリア・テキストで公開されます。管理者は、自分以外の人がLDIFファイルにアクセスできないように、生成されたLDIFファイルを保守および保護します。
policyモード: このモードは、権限受領者およびこれらの権限受領者に付与された権限を移行する場合に使用します。
allモード: このモードは、ユーザー、ロール、権限受領者、およびこれらの権限受領者に付与された権限を移行する場合に使用します。権限受領者は、レルム権限受領者または非レルム権限受領者です。
開発環境で、最終的な本番ロールを表す一時ロール名のリストを定義し、ポリシー定義にこれらのロールを使用した場合は、デプロイ時に、実際の本番ロールを反映するようにこれらのポリシーを更新する必要があります。開発環境で実際の本番ロール名を使用した場合、この項はスキップしてください。詳細は、10.2.1項「保護されたWebCenterアプリケーションを開発するためのロールの定義」を参照してください。
実際の本番ロールを使用してポリシー情報を更新するには、JAZN移行ツールを実行する前に、app-jazn-data.xmlファイル内の一時開発ロールを、本番環境で使用するロールで置き換えます。
例12-10に、開発環境でmanagersロールが定義されたapp-jazn-data.xmlファイルを示します。
例12-10 managersロールが定義されたapp-jazn-data.xmlファイル
<roles>
<role>
<name>managers</name>
<guid>58B213307F7811DBBF8F39184ABB7640</guid>
<members>
</members>
</role>
</roles>
.
.
.
<grant>
<grantee>
<principals>
<principal>
<realm-name>jazn.com</realm-name>
<type>role</type>
<class>oracle.security.jazn.spi.xml.XMLRealmRole</class>
<name>managers</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>view.pageDefs.testPageDef</name>
<actions>customize,personalize,view</actions>
</permission>
</permissions>
</grant>
このロールを本番環境のdoc_managersロールにマップするには、例12-11に示すように、ロールおよびプリンシパルに指定されているname要素を更新します。
例12-11 doc_managersロールを使用して更新されたapp-jazn-data.xmlファイル
<roles>
<role>
<name>doc_managers</name>
<guid>58B213307F7811DBBF8F39184ABB7640</guid>
<members>
</members>
</role>
</roles>
.
.
.
<grant>
<grantee>
<principals>
<principal>
<realm-name>jazn.com</realm-name>
<type>role</type>
<class>oracle.security.jazn.spi.xml.XMLRealmRole</class>
<name>doc_managers</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>view.pageDefs.testPageDef</name>
<actions>customize,personalize,view</actions>
</permission>
</permissions>
</grant>
JAZN移行ツールの実行時にアイデンティティ管理ソリューション内に名前付きロールが存在しない場合、名前付きロールが追加されます。名前付きロールが存在している場合は、app-jazn-data.xmlファイル内に定義されているロールは既存のロール定義を上書きせず、アイデンティティ管理ソリューション内の既存のロールにポリシーが適用されます。
JAZN移行ツールは、実行可能なユーティリティとしてパッケージ化されており、コマンドラインから実行されます。例12-12にJAZN移行ツールの構文を示し、表12-2に構文の要素を示します。JAZN移行ツールを実行する前に、CLASSPATHをORACLE_HOME/j2ee/home/jazn.jar;ORACLE_HOME/BC4J/lib/adfshare.jarに設定する必要があります。
|
注意: JAZN移行ツールを実行してセキュリティ・ポリシーをapp-jazn-data.xmlファイルからsystem-jazn-data.xmlファイルに移行するには、その前にOC4Jを停止する必要があります。ポリシーを移行してからOC4Jを再起動します。 |
例12-12 JAZN移行ツールの構文
java oracle.security.jazn.tools.JAZNMigrationTool -help java JAZNMigrationTool [-D binddn] [-w passwd] [-h ldaphost] [-p ldapport] [-sf filename] [-df LDIF_filename] [-sr source_realm] [-dr dest_realm] [-st source_type] [-dt dest_type] [-m policy|realm|all] [-help]
表12-2 JAZN移行ツールの構文の説明
| 要素 | 説明 |
|---|---|
|
- |
Oracle Internet Directoryのユーザー名。 |
|
|
Oracle Internet Directoryのユーザー・パスワード。 |
|
|
Oracle Internet Directoryのホスト。 デフォルト: |
|
|
Oracle Internet Directoryのポート。 デフォルト: |
|
|
XMLプロバイダ・ファイルのパス。 デフォルト: |
|
|
宛先LDIFファイルのパス。 デフォルト: |
|
- |
移行するレルムの名前。 デフォルト: レルム名（レルムが1つのみ存在する場合）。 |
|
|
Oracle Internet Directory内の宛先サブスクライバ・レルムの名前。 デフォルト: レルム名（レルムが1つのみ存在し、 デフォルトのサブスクライバ・レルム（ |
|
|
ソース側のプロバイダのタイプ。デフォルト: |
|
|
宛先側のプロバイダのタイプ。使用可能なオプションは |
|
|
ツールの実行モード。使用可能なオプションは JAASポリシーを移行する必要がある場合は、 レルム・ユーザーおよびロールのみを移行する必要がある場合は、 |
|
|
使用方法を表示。 |
ldapmodifyコマンドライン・ツールを使用すると、LDIFファイルを入力として指定することにより、エントリの属性を追加、削除または置換できます。例12-15にldapmodifyの構文を示し、表12-3にldapmodifyの引数を示します。
|
注意: ldapmodifyコマンドは、アプリケーションに関連付けたOracleAS Infrastructureインストールで使用可能です。このため、ldapmodifyコマンドはOracleAS Infrastructureホストから実行してください。 |
例12-15 ldapmodifyの構文
ldapmodify -h <oid_host_name> -p <oidport> -D <binddn> -w <password> -f <ldiffile> -v -c -o <errors_ldiffile>
表12-3 ldapmodifyの引数
| 要素 | 説明 |
|---|---|
|
|
Oracle Internet Directoryサーバーのホスト名またはIPアドレス（ |
|
|
Oracle Internet Directoryサーバーへの接続に使用するポート番号（ |
|
|
Oracle Internet DirectoryユーザーのDN（ |
|
|
ディレクトリにバインドするために必要なユーザー・パスワード（ |
|
|
インポートするデータが含まれる入力ファイルのフルパスとファイル名（ |
|
|
ツールはエラーが発生しても続行し、エラーを修正して再発行できるように、エラーの原因となったLDIF行すべてを指定されたエラーLDIFファイルに書き込みます。 |
この項では、コマンドライン・インタフェースを使用してWebCenterアプリケーションをデプロイする手順を示します。コマンドライン・ツールを使用すると、デプロイ前ツールによって汎用EARファイルから生成されたターゲットのEARファイルがデプロイされます。まだ汎用EARファイルを作成していない場合は12.2.1項「WebCenterアプリケーションのパッケージ化」を、ターゲットのEARファイルを作成していない場合は12.2.2項「WebCenterアプリケーションの事前デプロイ」を参照してください。
この項では、次の作業に対してコマンドライン構文を使用します。
Oracle Application ServerのOC4JにターゲットのEARファイルをデプロイする手順は、次のとおりです。
ターゲットのEARファイルを、Oracle Application Server内のディレクトリに配置します。たとえば、ORACLE_HOME/j2ee/home/applications/に配置します。
J2EEホームに移動します。パスはORACLE_HOME/j2ee/home/のように指定します。
アプリケーションをデプロイするには、次のコマンドを実行します。
java -jar admin.jar ormi://localhost/<ormi port> <admin_username> <admin_pwd>deploy -file<full_path_of_ear_file>-deploymentName<deployment_name>
これらの意味は、次のとおりです。
admin.jarは、ORACLE_HOME/j2ee/home/で使用可能です。
ormi://localhost/<ormi port>は、Remote Method Invocation（RMI）ポートで、デフォルト値は23791です。その値は、configファイル内に格納されます。これは、<ORACLE_HOME>/j2ee/home/config内で使用可能なrmi.xmlファイルに格納されています。
<admin_username>は、Oracle Application ServerでのOC4Jの管理者のユーザー名です。
<admin_pwd>は、Oracle Application ServerでのOC4Jの管理者のパスワードです。
<deployment_name>は、進行中のデプロイに対して指定された一意の名前です。
|
注意: 1つのアプリケーションは複数回デプロイできますが、デプロイごとに一意の名前を指定します。同じ名前のデプロイがすでに存在する場合は、再デプロイとして処理されます。 |
applicationsディレクトリ内のEARファイルが開いた状態で表示されていること。applicationsディレクトリのパスは、ORACLE_HOME\j2ee\home\applicationsのようになります。
application-deploymentsディレクトリに、デプロイ済アプリケーションに関連するファイルが含まれていること。
applicationsディレクトリとapplication-deploymentsディレクトリの両方に、<deployment_name>ディレクトリが作成されていること。
OC4Jがリスニングするポートにアプリケーションをバインドする手順は、次のとおりです。
次のコマンドを実行します。
java -jar admin.jar ormi://host/<ormi_port>/<admin_username> <admin_pwd>0bindWebApp<deployment_name> <web_module_name> <webSiteName> <context_root>
これらの意味は、次のとおりです。
ormi_portはRMIポートです。その値はconfigファイル内に格納されています。
deployment_nameは、デプロイ済アプリケーションの名前です。
web_module_nameは、バインドするモジュールの名前です。これはアプリケーションに対して指定されています。
webSiteNameは、アプリケーションをデプロイするサイトのホスト名です。
context_rootは、デプロイメント・プロファイル内に格納されているWebアプリケーションのコンテキスト・ルートです。
次のような書式で適切なURLを使用して、アプリケーションにアクセスします。
http://host:port/web_site_name/context_root/faces/page_name.jspx
|
注意: デフォルトのhttp-web-siteが<webSiteName>の場合は、これをURLに含める必要はないので、URLの書式はhttp://host:port/context_root.になります。 |
これで、WebCenterアプリケーションがデプロイされ、使用可能になります。
次の手順を実行することにより、Oracle JDeveloperを使用して、WebCenterアプリケーションをスタンドアロンOC4Jにデプロイできます。
|
注意: Oracle Application ServerがOracle JDeveloperと同じコンピュータ上に存在する場合は、Oracle JDeveloperを使用して、Oracle Application Server上のOC4Jインスタンスにアプリケーションをデプロイできます。 |
埋込みOC4Jにコンテンツ・ページをデプロイし、ブラウザでこれらのページをテストするには、図12-18に示すように、プロジェクトを右クリックし、「実行」を選択します。
選択したページが、ブラウザに表示されます。
アプリケーションをデプロイするスタンドアロンOC4Jへのダイレクト接続を作成する手順は、次のとおりです。
ナビゲータで「接続」タブをクリックします。
「アプリケーション・サーバー」を右クリックし、「アプリケーション・サーバー接続の作成」を選択します。「ようこそ」ページが表示されます。
「次へ」をクリックして、「ようこそ」ページを終了します。図12-19に示すように、ステップ1/4: タイプ・ウィンドウが表示されます。
ステップ1で、「接続名」フィールドにスタンドアロンOC4J接続の名前を入力します。
次に、リストから適切な接続タイプを選択します。たとえば、「スタンドアロンOC4J 10g 10.1.3」を選択し、「次へ」をクリックします。
ステップ2で、有効なユーザー名およびパスワード（oc4jadminおよびoracle1など）を入力し、「次へ」をクリックします。
ステップ3で、スタンドアロンOC4Jのホスト名（myhost.mycompany.comなど）、そのRMIポート（23795など）を入力し、「次へ」をクリックします。
RMI情報は、ORACLE_HOME/j2ee/home/config内で使用可能なrmi.xmlファイルに格納されています。
「接続のテスト」をクリックします。図12-20に示すような「成功しました。」というメッセージが表示されます。「終了」をクリックします。テストに失敗した場合は、接続情報の修正が必要になる場合があります。
今度は、12.2.1.2項「WebCenterアプリケーションWARデプロイメント・プロファイルの作成」の説明に従って、ポートレットのデプロイに必要なデプロイメント・プロファイルにこの接続を含めます。
この項では、12.2.6.2.1項「スタンドアロンOC4Jの接続詳細の定義」で定義した接続詳細を使用して、アプリケーションをスタンドアロンOC4Jにデプロイします。この接続を使用するには、12.2.1項「WebCenterアプリケーションのパッケージ化」の説明に従って、デプロイメント・プロファイルを構成する必要があります。
|
注意: WebCenterアプリケーションをスタンドアロンOC4Jインスタンスにデプロイするとき、デプロイ前ツールが裏で実行されます。デプロイ前ツールの詳細は、12.2.2項「WebCenterアプリケーションの事前デプロイ」を参照してください。 |
アプリケーションをスタンドアロンOC4Jにデプロイするには、OC4JがOracle JDeveloperと同じコンピュータ上で実行されている必要があります。これは、Oracle JDeveloperとOC4Jの両方で、デプロイ時に指定されたMDSディレクトリへのアクセスが必要となるためです。共有MDSパス（つまり、ネットワークにマウントされたドライブ）からターゲットのEARファイルをデプロイすることにした場合、このパスがファイル・システムのローカル・ドライブとして扱われます。このため、格納されているMDSパスには、デプロイ先のシステムからマウントしたドライブのパスが含まれます。したがって、これを他の場所で使用するには、ターゲットのEARファイルをその場所にデプロイする必要があります。同様に、MDSの場所を変更した場合は、すべてのインスタンスを再デプロイする必要があります。アプリケーションのデプロイ中は、MDSパスを変更できます。ただし、このタイプのデプロイでは、プロデューサURLを変更することはできません。
Oracle JDeveloperを使用して外部アプリケーションをスタンドアロンOC4Jインスタンスにデプロイするとき、アプリケーションのテスト中に入力したユーザー資格証明はデプロイされません。
アプリケーションをデプロイする手順は、次のとおりです。
アプリケーション・ナビゲータで、「リソース」フォルダの下の「name.deploy」を右クリックし、ターゲットの接続を選択します。図12-21に示すようなターゲットMDSパスの選択ウィンドウが表示されます。
「参照」をクリックしてMDSディレクトリを選択し、「OK」をクリックします。
指定したディレクトリが存在しない場合、Oracle JDeveloperによって自動的に作成されます。
|
注意: MDSコンテンツへのブラウザ・アクセスを回避するため、MDSパスは必ず、Webコンテンツ・ルートの外部にあるディレクトリ内に指定してください。さらに、デプロイ用のMDSリポジトリは必ず、アプリケーションの作業ディレクトリの外部に作成してください。開発用とデプロイメント用に別々のMDSディレクトリを保持しておくと、混同を避けられます。また、アプリケーションのソースMDSリポジトリ内のコンテンツが上書きされることがありません。 |
EARファイルが生成され、スタンドアロンOC4Jにアップロードされます。EARファイルには、多数の構成（.xmlファイル）、およびアプリケーションで使用されるすべてのファイルとライブラリが含まれます。
図12-22に示すようなアプリケーションの構成ウィンドウが表示されます。「OK」をクリックします。
デプロイが成功すると、ページがブラウザに表示されます。
セキュリティ情報の移行
セキュリティ情報をスタンドアロンOC4Jに移行するには、12.2.4.3項「JAZN移行ツールの使用」の手順を参照してください。この項では、例12-13に示したような、XMLからXMLにセキュリティ関連データを移行するための構文を使用しています。
外部アプリケーションをデプロイするには、次の各項の手順を参照してください。
この項では、Oracle WebCenter Framework内のWebCenter Antタスクの概要を示し、Antタスクを使用してWebCenterアプリケーションのデプロイを自動化する方法を説明します。
この項の内容は、次のとおりです。
この項では、構成ファイルの自動作成、JAZNデータの移行、EARファイルの事前デプロイ、およびカスタマイズのエクスポートとインポートを行うための、次のAnother neat tool（Ant）タスクについて説明します。
ここで説明するWebCenter Antタスクは、無償で配布されているApache Antバージョン1.6.5とともに使用してください。詳細および最新のApache Ant製品ドキュメントは、http://ant.apache.org/manual/を参照してください。
webcenter:generateConfigTemplate
このタスクは、構成ファイル・テンプレートを生成し、WebCenterアプリケーションで使用されるプロデューサ接続のIDをこのテンプレートに移入します。生成されたテンプレートは、MDSパスおよびプロバイダ再マッピング詳細に含めることができます。例12-16に、generateConfigTemplateタスクの構文を示します。この項で後述するタスクを使用する前に、構成テンプレートを作成しておく必要があります。
例12-16 webcenter:generateConfigTemplate
<webcenter:generateConfigTemplate ear="Source ear file" file="Name of the config file." />
|
注意: このタスクは、デフォルトのMDSパスが含まれる構成ファイルを生成します。このパスを、適切なMDS場所を指定するように変更する必要があります。 |
webcenter:preDeploy
このタスクは、WebCenterアプリケーションを事前デプロイするために使用します。このタスクは、ローカル・アプリケーション・サーバーまたはスタンドアロンOC4JにデプロイできるターゲットのEARファイルを作成します。構成ファイルには、MDSパスおよびプロバイダの再マッピングが含まれている必要があります（存在する場合）。さらに、Antタスクではデプロイ前ツールとは異なり、デフォルト・プロファイルが作成されないため、プロファイルが1つしか存在していない場合でも、プロファイル名を指定する必要があります。例12-17に、webcenter:preDeployタスクの構文を示します。
例12-17 webcenter:preDeploy
<webcenter:predeploy sourceEAR="Source ear file."
targetEAR="Targeted ear file."
config="Configuration file with MDS path and provider remapping
details."
profile="Profile name to use from the config file."
</webcenter:preDeploy>
|
関連項目: 詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』および12.2.2.2項「WebCenterアプリケーションおよびJCRアダプタ・ベースのアプリケーションの事前デプロイ」を参照してください。 |
webcenter:exportMdsData
このタスクを使用すると、デプロイ済アプリケーションからカスタマイズ・エクスポート・アーカイブ・ファイルにMDSデータをエクスポートできます。例12-18に、webcenter:exportMdsDataタスクの構文を示します。
例12-18 webcenter:exportMdsData
<webcenter:exportMdsData ear="Target ear file."
deployedApp="Deployed application from which to export data."
mdsPath="MDS path of the jdev application."
connectionPath="Path to connections.xml."/>
webcenter:importMdsData
このタスクを使用すると、デプロイメント・アプリケーションから、すでにエクスポートされたカスタマイズ・アーカイブ・ファイルに、カスタマイズをインポートできます。例12-19に、webcenter:importMdsDataタスクの構文を示します。
例12-19 webcenter:importMdsData
<webcenter:importMdsData ear="Source ear file"
deployedApp="Import from deployed application into your EAR."/>
webcenter:generateMdsExportSet
このタスクを使用すると、WebCenterアプリケーション内のポートレットに対して設計時に行われたカスタマイズを、指定したファイル・システム・パスにエクスポートできます。例12-20に、webcenter:generateMdsExportSetタスクの構文を示します。
次の各項で、Antタスクの前提条件と、これらの前提条件を満たすための手順を説明します。
WebCenterインストールには、Ant 1.6.5と、WebCenter Antタスク用のファイルが含まれています。Antタスクを使用する前に、Antタスクを環境に組み込む必要があります。そのための手順は、次のとおりです。
次の構文を実行することにより、ORACLE_HOME環境変数を設定します。
setenv ORACLE_HOME ORACLE_HOME/oc4j
次の構文を実行することにより、ant/libを含むようにCLASSPATH環境変数を更新します。
setenv CLASSPATH ${CLASSPATH}:ORACLE_HOME/oc4j/ant/lib
次の構文を実行することにより、ANT_HOMEを設定します。
UNIXの場合:
setenv ANT_HOME ORACLE_HOME/ant
Windowsの場合:
set ANT_HOME=ORACLE_HOME\ant
|
注意: ORACLE_HOME/ant/bin内にあるantコマンドを使用して、ORACLE_HOME/ant/lib内のライブラリがロードされることを確認する必要があります。ANT_HOMEなどの変数を定義する際は、このことを覚えておいてください。他のディレクトリからantコマンドを起動すると、適切なライブラリが正常にロードされないことがあります。 |
WebCenter Framework内のAntタスクは、Oracle Application Serverの一部としてインストールされているOC4Jインスタンスでは、即時利用可能です。これらのAntタスクをスタンドアロンOC4Jインスタンス、Oracle Application Server 10.1.3.1.0以前、またはサード・パーティのアプリケーション・サーバーで使用するには、まず、Oracle ADランタイム・インストーラを実行して、次のファイルを追加する必要があります。
<OC4J_HOME>/ant/lib/ant-oracle-adfp.jar
<OC4J_HOME>/adfp/utilities/ant-adfp-classes.jar
<OC4J_HOME>/adfp/utilities/ant-oracle-adfp.xml
|
注意: Oracle Application Server 10.1.3.2.0インスタンスではADFランタイム・インストーラを実行しないでください。エラーが発生して、アプリケーション・サーバー・インスタンスを再起動できなくなる場合があります。 |
Oracle ADFランタイム・インストーラの実行が正常に完了し、適切なディレクトリ内にAnt jarが存在していることを、目で見て確認することをお薦めします。
Oracle JDeveloperで使用した同じビルド・ファイルを使用してOC4J_HOMEインスタンスからデプロイした場合は、次のコード部分がまだ有効になっていることを確認してください。
<import file="ORACLE_HOME/adfp/utilities/ant-oracle-adfp.xml"/>
これを有効にする方法は、次のとおりです。
環境変数を使用している場合は、OC4J_HOMEを指すようにORACLE_HOME環境変数を設定します。
ハードコードのパスを使用している場合は、適宜パスを更新します。
Antタスクを使用するには、次の例に示すように、build.xmlファイル内のクラス定義の名前空間を指定します。
<project name="Project1" default="all" xmlns:webcenter="antlib:oracle.adfp">
プロジェクトのxmlns属性を使用すると、WebCenter Antタスクをインポートできます。
接頭辞webcenterはカスタマイズ可能であり、ユーザーが必要に応じて変更できます。この接頭辞を変更した場合は、すべてのデプロイメント・タスクが、<prefix>:deploy、<prefix>:importのように、新しい接頭辞で始まっている必要があります。
Antタスクを使用してWebCenterアプリケーションをデプロイするには、まず、Antタスクが含まれるbuild.xmlファイルを作成する必要があります。このbuild.xmlファイルには、プロジェクトおよびターゲットが含まれます。ターゲットにはタスク要素が含まれ、ビルド・ファイルの各タスク要素はid属性を持つことができます。この属性は後で、これに指定された一意の値から参照できます。WebCenter Antタスクの詳細は、12.3.1項「WebCenter Antタスクの概要」を参照してください。
build.xmlファイルを作成する手順は、次のとおりです。
Oracle JDeveloperで、アプリケーション・ナビゲータに移動し、プロジェクトを選択します。次に、「ファイル」メニューから「新規」を選択します。「新規ギャラリ」ダイアログ・ボックスが表示されます。
図12-23に示すように、「General」で「Ant」を選択し、「項目」で「空のビルドファイル」を選択します。
「OK」をクリックします。図12-24に示すような「Antビルドファイルの作成」ダイアログ・ボックスが表示されます。
「OK」をクリックします。図12-25に示すように、「リソース」フォルダの下に「build.xml」ファイルが作成されます。
|
注意: build.xmlは、WebCenter Antビルド・ファイルに付けられる標準の名前です。変更しないでください。 |
「リソース」で、「build.xml」ファイルをダブルクリックして開きます。
ソース・モードで、例12-21に示すように、適切な値とともにAntタスクを入力します。
例12-21 サンプルのビルド・ファイル
<?xml version="1.0" encoding="US-ASCII" ?>
<project name="Project1" default="deploy2server" xmlns:webcenter="antlib:oracle.adfp"
xmlns:oracle="antlib:oracle">
<property name="ORACLE_HOME" value="c:/jdev"/>
<import file="${ORACLE_HOME}/adfp/utilities/ant-oracle-adfp.xml"/>
<property name="proj" value="c:/jdev/jdev/mywork/Application1/Project1/deploy"/>
<!-Config Task. This task generates a configuration file template. -->
<target name="config">
<webcenter:generateConfigTemplate ear="${proj}/webcenterArchive1.ear"
file="${proj}/config.xml"/>
</target>
<!--Predeploy Task. This tasks creates a targeted EAR from a generic EAR. -->
<target name="predeploy">
<webcenter:predeploy sourceEAR="${proj}/webcenterArchive1.ear"
targetEAR="${proj}/target.ear"
config="${proj}/config.xml"
profile="Template"/>
</target>
<!--Deploy to Server Task. This task deploys the targeted EAR to the specified server. -->
<target name="deploy2server" depends="predeploy">
<oracle:deploy deployerUri="deployer:oc4j:localhost:23791"
userid="oc4jadmin"
password="welcome1"
file="${proj}/target.ear"
deploymentName="webcenterArchive1"
bindAllWebApps="default-web-site"
logFile="${proj}/deploy.log"/>
<!-- Export and Import tasks Note: Do not run export and import tasks from Oracle JDeveloper.
Run these tasks in stage/production environment instead-->
</target>
<target name="export">
<webcenter:exportMdsData ear="${proj}/export.ear"
deployedApp="C:/jdev/j2ee/home/applications/webcenterArchive1"/>
</target>
<target name="import">
<webcenter:importMdsData ear="${proj}/export.ear"
deployedApp="C:/jdev/j2ee/home/applications/webcenterArchive1"/>
<!--FTP Task.-->
</target>
<target name="ftp_mds">
<ftp server="localhost" remotedir="C:/tmp"
userid="ftpuser" password="welcome1"
binary="no" verbose="yes">
<fileset dir="C:/tmp/MDS"/>
</ftp>
</target>
<!-- Note: You can use an FTP Ant task together with the oracle:deploy task to
copy the MDS directory to a remote OC4J and deploy the application.-->
<target name="ftp_and_deploy" depends="ftp_mds">
<webcenter:deploy deployerUri="deployer:oc4j:localhost:23791"
userid="oc4jadmin"
password="welcome1"
file="${proj}/target.ear"
deploymentName="webcenterArchive1"
bindAllWebApps="default-web-site"
logFile="${proj}/deploy.log"/>
</target>
</project>
build.xmlファイルを保存します。
build.xmlファイルを使用してWebCenterアプリケーションをデプロイするには、build.xmlが含まれるディレクトリからantコマンドを実行します。たとえば、例12-21に基づいてant predeployコマンドを実行すると、webcenter:predeployがコールされ、これにより汎用EARファイルからターゲットのEARファイルが作成されます。次に、webcenter:deployによって、ターゲットのEARファイルが、build.xmlファイル内に指定されているOC4Jインスタンスにデプロイされます。oracle:deployはJ2EE Antタスクであり、即時利用可能です。
|
関連項目: 『Oracle Containers for J2EEデプロイメント・ガイド』 |
すでにデプロイされているアプリケーションのページおよびポートレット（PDK-JavaおよびWSRPバージョン2のプロデューサ）に対して行われたカスタマイズをエクスポートおよびインポートするには、デプロイ前ツールをエクスポート・モードおよびインポート・モードで実行します。次の各項で、ステージング環境からカスタマイズをエクスポートして本番環境にインポートする手順を説明します。
デプロイ前ツールによって、カスタマイズはカスタマイズ・エクスポート・アーカイブ・ファイルにエクスポートされます。このカスタマイズ・エクスポート・アーカイブ・ファイルは後で、本番環境のMDSディレクトリにインポートされます。
ステージング環境から本番環境にカスタマイズをエクスポートするには、次の構文を実行します。
ORACLE_HOME/jdk/bin/java -jar adfp/lib/portlet-client-deploy.jar-export -deployedapp<deployed_app_path>-target<targetedEAR>
これらの意味は、次のとおりです。
targetedEARは、エクスポート・プロセスで作成されたカスタマイズ・エクスポート・アーカイブ・ファイルの名前です。このファイルには、別のインスタンス内にデプロイされた同じアプリケーションにインポートできるすべてのカスタマイズが含まれています。
deployed_app_pathは、カスタマイズのエクスポート元のデプロイ済アプリケーションの場所（ORACLE_HOME/j2ee/home/applications/YourApplicationなど）です。
デプロイ前ツールでは、エクスポート中にエクスポートされたカスタマイズ・アーカイブ・ファイルを使用して、カスタマイズが本番環境にインポートされます。
カスタマイズ・アーカイブ・ファイルにエクスポートしたカスタマイズは、本番環境にインポートできます。これらのカスタマイズを本番環境にインポートする手順は、次のとおりです。
コマンド・プロンプトで、次の構文を実行します。
ORACLE_HOME/jdk/bin/java -jar adfp/lib/portlet-client-deploy.jar-import -source<genericEAR>-deployedapp<deployed_app_path>
これらの意味は、次のとおりです。
genericEARは、エクスポート・モードで作成されたエクスポート済のカスタマイズ・インポート・アーカイブ・ファイルです。このファイルには、デプロイ済アプリケーションにインポートするカスタマイズが含まれています。
deployed_app_pathは、カスタマイズのインポート先のデプロイ済アプリケーションの場所（ORACLE_HOME/j2ee/home/applications/YourApplicationなど）です。
WebCenterアプリケーションにWSRPバージョン2のプロデューサも含まれている場合は、OC4Jを再起動してカスタマイズを確認する必要があります。
これで、カスタマイズが本番環境のアプリケーションにインポートされます。
WebCenterアプリケーションは、（connections.xmlに格納されている）接続に関連付けられたセキュアなプロパティを、credential-store.xmlファイル内に暗号形式で保持します。設計時には、Oracle JDeveloperでこれらのセキュアなプロパティを更新できますが、デプロイ後にターゲット・システム上でセキュアなプロパティを更新するには、資格証明Java Management Extension（JMX）MBeanを使用する必要があります。このMBeanにアクセスするには、Application Server Controlコンソールを実行します。接続のセキュアなプロパティに対して行われた変更は、credential-store.xmlファイル内で更新されます。
アプリケーションへの資格証明MBeanの組込み
資格証明MBeanを使用するには、まず、アプリケーション内で資格証明MBeanが使用可能であることと、アプリケーションが稼働中であることを確認する必要があります。このMBeanは、Oracle JDeveloperインストールの一部であるORACLE_HOME/BC4J/lib/oracle.extapp.runtime.jarファイルに含まれています。Oracle Application Serverインストールでは、このJARファイルはORACLE_HOME/adfp/libディレクトリ内で使用可能です。
資格証明MBeanは、Oracle ADF認証サーブレットが含まれるアプリケーションに対してのみ使用可能です。Oracle JDeveloperでOracle ADFセキュリティ・ウィザードを使用してセキュリティを実装した場合には、Oracle ADF認証サーブレットがアプリケーションにすでに追加されています。
アプリケーションで、ユーザー認証にOracle ADF Securityを使用しないが、セキュアなプロパティを使用した接続が存在する場合、web.xmlファイル内に次のXMLコードを追加することにより、AuthenticationServletをアプリケーションに手動で追加できます。
<servlet>
<servlet-name>AuthenticationServlet</servlet-name>
<servlet-class>
oracle.adf.share.security.authentication.AuthenticationServlet
</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
web.xmlファイルを更新した後、Oracle Application Serverインスタンスを再起動します。
アプリケーションの起動時に確実にAuthenticationServletがロードされるように、アプリケーションで使用されていなくても<load-on-startup>要素を追加する必要があります。
|
注意: MBeanは、アプリケーションが稼働中にのみ使用可能です。 |
セキュアな接続プロパティの更新
資格証明MBeanを使用してセキュアな接続プロパティを更新する手順は、次のとおりです。
Application Server Controlコンソールにログインします。「ホーム」ページが表示されます。
アプリケーションがデプロイされているOC4Jインスタンスを選択します。
図12-26に示すように、「アプリケーション」タブをクリックし、「アプリケーションMBean」ページにナビゲートします。
図12-27に示すように、左側のフレームのMBean名のリストから「資格証明」を選択します。
右側のフレームにMBeanの説明と、このMBeanを使用して実行できる4つの操作が示された「操作」タブが表示されます。
「操作: listConnections」ページで、「起動操作」をクリックして、このような接続のリストを取得します。接続の名前は、後で操作を実行するために必要になるので、書き留めておいてください。
「戻る」をクリックします。
「MBean: 接続: 資格証明」ページで「listCredentials」操作を選択して、前の手順で書き留めたすべての接続に対する資格証明を表示します。図12-28に示すような「操作: listCredentials」ページが表示されます。
接続名を指定し、「起動操作」をクリックして、その接続の保護されたプロパティを表示します。図12-29に示すように、選択した接続のすべてのセキュアなプロパティがリストされます。資格証明の名前は、後で操作を実行するために必要になるので、書き留めておいてください。
|
注意: 高レベルなセキュリティを確保するため、MBeanは既存の資格証明の値を公開しません。 |
「戻る」をクリックします。
「MBean: 接続: 資格証明」ページで「setCredential」操作を選択して、接続のセキュアなプロパティを更新します。図12-30に示すような「操作: setCredential」ページが表示されます。
図12-30 保護されたプロパティ値を設定するために使用するsetCredential操作のページ
接続名、セキュアなプロパティ名、および新しいプロパティ値を指定し、「起動操作」をクリックして、保護されたプロパティの値を変更します。図12-31に示すように、結果のページに、保護されたプロパティが正常に更新されたことが示されます。
|
注意: 接続およびプロパティ名を正しく指定したことを確認してください。プロパティの名前および値では、大/小文字が区別されます。 |
「戻る」をクリックします。
「MBean: 接続: 資格証明」ページで「resetCredential」操作を選択して、接続のセキュアなプロパティをすべてリセットします。
接続名およびセキュアなプロパティ名を指定し、「起動操作」をクリックして、セキュアなプロパティの値をリセットします。
必要に応じて、手順4〜15を繰り返します。セキュアなプロパティに対して行った変更は、即時にコミットされます。
|
注意: 4つの操作は、どのような順序でも実行できます。特定の順序に従う必要はありません。 |
開発環境へのcredential-store.xmlファイルのコピー
デプロイ済アプリケーションでセキュアな資格証明を更新すると、内部的にこの情報を使用してcredential-store.xmlファイルが更新されます。ただし、アプリケーションが開発環境から再デプロイされると、これらの資格証明は失われます。これは、アプリケーションが再デプロイされると、デプロイ済アプリケーション内のcredential-store.xmlファイルが上書きされるためです。前に更新した資格証明が再デプロイ済アプリケーション内で確実に使用可能にするためには、credential-store.xmlファイルが再デプロイするアプリケーションとともに再パッケージ化されるように、ファイルを再び開発環境にコピーする必要があります。ただし、ファイルを開発環境にコピーしてから再デプロイするまでの間に入力または変更した資格証明は失われます。
開発環境では、一部の資格証明は適切なウィザードを使用して更新する必要があることがあります。これらの資格証明がステージング環境および本番環境に固有である場合があるためです。つまり、ステージング環境および本番環境でMBeanを使用して更新した資格証明は、開発環境で機能するように元の値に更新する必要があります。さらに、デプロイ後にも、MBeanを使用して同じ資格証明を再び更新する必要があります。
クローニングは、構成を保持したまま既存のインストールを別の場所にコピーするプロセスです。この項では、WebCenterアプリケーションをクローニングするための次のシナリオについて説明します。
このシナリオでは、クラスタまたはクラスタ対応設定内に新しいノードまたは追加のノードを作成します。MDS、プロデューサ・プリファレンス、接続およびロード・バランシング・ルーター（LBR）の構成などの設定はいずれも、変更されません。
Oracle Application Serverクラスタを拡張するための前提条件は、次のとおりです。
クラスタリングに対してOracleホームが設定されている必要があります。
MDS場所が共有されている必要があります。
ポートレット・プロデューサ・プリファレンス・ストア（ファイルまたはデータベース）が共有されている必要があります。
クローニングを使用してOracle Application Serverクラスタを拡張するには、『Oracle Application Server管理者ガイド』のApplication Serverの中間層インスタンスのクローニングに関する章で、Oracle Application Serverクラスタを拡張するためのクローニングの使用例に示された手順に従ってください。クローニング済のターゲット・インスタンスを、クローニング済のソース・インスタンスとまったく同じ環境にデプロイするので、図12-1に示したような（ポートレット・プロデューサのエンドポイントなどの）外部依存性は何も変更されていないことが前提となります。したがって、『Oracle Application Server管理者ガイド』のApplication Serverの中間層インスタンスのクローニングに関する章で概説されているクローニング手順に従うだけです。
図12-1に示すように、WebCenterアプリケーションには通常、ポートレット・プロデューサやコンテンツ・リポジトリなどの多数の外部依存性が存在しています。ステージングから本番に移行するとき、これらの外部依存性の構成詳細が変更される場合があります。たとえば、Oracle Content Database（Oracle Content DB）のデータベース接続詳細は本番環境では異なる場合があります。
ステージングから本番に移行するためにクローニングを使用する手順は、次のとおりです。
『Oracle Application Server管理者ガイド』のApplication Serverの中間層インスタンスのクローニングに関する章の説明に従って、Oracleホームをクローニングします。
次の手順が環境に適用可能な場合は、実行します。
WebCenterアプリケーションで、Oracle Content DBデータ・コントロールを使用してOracle Content DBに格納されているコンテンツを使用する場合は、「Oracle Content DBベースのコンテンツ統合アプリケーションのパラメータの再構成」の説明に従って、デプロイ前ツールを使用してプロデューサ接続用にOracle Content DBを再構成します。
WebCenterアプリケーションで、OracleAS Portalベースのコンテンツ・データ・コントロールを使用してOracleAS Portalに格納されているコンテンツを使用する場合、かつOracleAS Portalデータ・ソース内に使用されているJNDI名が開発環境で使用されたJNDI名と異なる場合は、「OracleAS Portalアダプタ、Oracle Content Serverアダプタおよびファイル・システム・アダプタの再構成」の説明に従って、connection.xmlファイル内のOracleAS Portal接続情報を更新します。
アプリケーションで暗号化済属性（資格証明ストア内のパスワードなど）を使用する場合は、12.5項「デプロイ済アプリケーションでの資格証明の更新」の説明に従い、資格証明MBeanを使用してこれらの資格証明を変更します。
WebCenterアプリケーションで、ファイル・システム上のデータ・コントロールを使用してファイル・システムに格納されているコンテンツを使用する場合は、「OracleAS Portalアダプタ、Oracle Content Serverアダプタおよびファイル・システム・アダプタの再構成」の説明に従って、connection.xmlファイル内のファイル・システム接続情報を更新します。ただし、ファイル・システム・アダプタは開発目的でのみ使用してください。
MDSの場所が変更された場合は、12.2.2項「WebCenterアプリケーションの事前デプロイ」の説明に従い、デプロイ前ツールを使用して、新しい場所を使用するようにアプリケーションを再構成します。
ステージング・サーバーと本番サーバーが同じアイデンティティ・ストアを使用していない場合、12.2.4項「セキュリティおよびアプリケーション・ロールの移行」の説明に従って、ステージングから本番にセキュリティ・ポリシー情報を移行します。このプロセス中にXMLプロバイダ（sytem-jazn-data.xml）からLDAPプロバイダに移行する必要がある場合は、例12-14および例12-15の説明に従って、JAZN移行ツールおよびldapmodifyコマンドを実行する必要があります。
12.4項「複数の環境間でのカスタマイズのトランスポート」の説明に従って、ポートレットおよびページのカスタマイズをステージングから本番にエクスポートします。これらのカスタマイズは、最初にステージング環境のカスタマイズ・エクスポート・アーカイブ・ファイルにエクスポートされます。その後、このカスタマイズ・エクスポート・アーカイブ・ファイルは本番環境のMDSディレクトリにインポートされます。
クローニング済アプリケーションをテストして、予測どおりに動作するかどうか確認します。
WebCenterアプリケーションを分散環境で実行するように構成する方法の詳細は、『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』、および『Oracle Application Server高可用性ガイド』のアクティブ-アクティブ・トポロジに関する章を参照してください。
Application Server Controlコンソールまたはコマンドライン・インタフェースを使用して、アプリケーションをアンデプロイできます。Application Server Controlコンソールを使用することをお薦めしますが、この項では、より深い理解のために、コマンドライン・インタフェースを使用してWebCenterアプリケーションをアンデプロイするための構文も示しています。
次の各項で、WebCenterアプリケーションをアンデプロイする手順を学びます。
Application Server Controlコンソールにログインします。「ホーム」ページが表示されます。
「アプリケーション」タブをクリックします。図12-32に示すような「アプリケーション」ページが表示されます。
図12-32 Application Server Controlコンソールの「アプリケーション」ページ
「アンデプロイ」をクリックします。図12-33に示すような「アプリケーションのアンデプロイ」警告ページが表示されます。
「はい」をクリックして、アプリケーションをアンデプロイします。図12-34に示すようなアンデプロイの「確認」ページが表示されます。
図12-34 Application Server Controlコンソールのアンデプロイの「確認」ページ
これで、アプリケーションがアンデプロイされます。アプリケーションは、「アプリケーション」タブに表示されなくなります。ただし、アプリケーションのMDSディレクトリは引き続き使用可能です。
