Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1) E70030-02 |
|
![]() 前 |
![]() 次 |
この章の内容は次のとおりです。
デプロイは、アプリケーション・ファイルをアーカイブ・ファイルとしてパッケージ化し、ターゲット・アプリケーション・サーバーに転送するプロセスです。JDeveloperを使用して、Oracle ADFアプリケーションをアプリケーション・サーバー(Oracle WebLogic Serverなど)に直接デプロイしたり、間接的にアーカイブ・ファイルをデプロイメント・ターゲットにしてデプロイしてから、そのアーカイブ・ファイルをターゲット・サーバーにインストールできます。アプリケーション開発の際には、JDeveloperを使用して、統合WebLogic Serverでアプリケーションを実行することもできます。JDeveloperではサーバー・クラスタへのデプロイがサポートされていますが、JDeveloperを使用して、クラスタのメンバーである個々の管理対象サーバーにデプロイすることはできません。
図54-1に、デプロイメント・プロセス全体を説明したフロー・ダイアグラムを示します。ADFランタイムのインストールによるデプロイ用のターゲット・アプリケーション・サーバーの準備については、『Oracle ADFアプリケーションの管理』を参照してください。
注意:
通常、JDeveloperは開発やテストの目的でアプリケーションをデプロイする場合に使用します。Oracle ADFアプリケーションを本番用にデプロイする場合は、Enterprise Managerまたはスクリプトを使用して、本番レベルのアプリケーション・サーバーにデプロイできます。
後期段階のテスト環境または本番環境へのデプロイの詳細は、『Oracle ADFアプリケーションの管理』を参照してください。
ADF Java EEアプリケーションは、標準化されたモジュール型コンポーネントに基づいており、次のアプリケーション・サーバーにデプロイできます。
Oracle WebLogic Server
Oracle WebLogic Serverは、そうしたモジュール用のサービス一式を備えており、細かいアプリケーション動作の多くを自動的に処理するため、プログラミングは必要ありません。JDeveloperと互換性のあるOracle WebLogic Serverのバージョンについては、動作保証情報のWebサイト(http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html
)を参照してください。
Fusion Webアプリケーションのデプロイは、標準的なJava EEアプリケーションのデプロイとは多少異なります。ADF Facesコンポーネントを含むJSFアプリケーションには、次の追加デプロイ要件があります。
ADF Facesには、SunのJSF Reference Implementation 1.2およびMyFaces 1.0.8(またはそれ以降)が必要です。
JDeveloperを使用して、次の作業を実行できます。
統合WebLogic Serverでのアプリケーションの実行
統合WebLogic Serverを使用してアプリケーションを実行およびデバッグし、スタンドアロンWebLogic Serverにデプロイできます。
スタンドアロン・アプリケーション・サーバーへの直接デプロイ
アプリケーションをスタンドアロン・アプリケーション・サーバーに直接デプロイするには、サーバーへの接続を作成し、そのサーバーの名前をデプロイメント・ターゲットとして選択します。
アーカイブ・ファイルへのデプロイ
デプロイメント・ターゲットとしてEARファイルを選択することによって、間接的にアプリケーションをデプロイすることができます。アーカイブ・ファイルは、ターゲット・アプリケーション・サーバーに後でインストールできます。
Oracle ADFのSummitサンプル・アプリケーションに、Fusion Webアプリケーション・テクノロジ・スタックを使用してトランザクション・ベースのWebアプリケーションを作成する方法が示されています。Summitサンプル・アプリケーションは、統合WebLogic Serverを使用してJDeveloperで実行できます。Summit ADFサンプル・アプリケーションの詳細は、「ADFサンプル・アプリケーションの概要」を参照してください。
JDeveloperでアプリケーションを開発していて、統合WebLogic Serverでアプリケーションを実行する場合、Oracle WebLogic Serverに直接、またはアーカイブ・ファイルにデプロイするために必要なタスクを実行する必要はありません。JDeveloperには統合WebLogic Serverへのデフォルトの接続があるため、デプロイメント・プロファイルやデプロイメント・ディスクリプタは不要です。統合WebLogic Serverには、Oracle ADFアプリケーションの実行に必要なADFライブラリを含む事前構成済ドメイン、および-Djps.app.credential.overwrite.allowed=true
の設定が用意されています。JDeveloperのメイン・メニューから「実行」を選択すれば、アプリケーションを実行できます。
「ADFコンポーネントのテストとデバッグ」で説明した機能を使用して、アプリケーションをデバッグできます。
通常、スタンドアロン・サーバーにデプロイするためには、統合WebLogic Serverでアプリケーションを実行してテストと開発を行います。その後、アプリケーションをスタンドアロンのOracle WebLogic Serverに開発モードでデプロイして本番環境を厳密にシミュレートし、アプリケーションのテストをさらに実施することができます。
一般にJDeveloperでは、次の作業を行って、デプロイに向けてアプリケーションまたはプロジェクトを準備します。
ターゲット・アプリケーション・サーバーへの接続の作成
デプロイメント・プロファイルを作成(必要な場合)
デプロイメント・ディスクリプタを作成(必要な場合、およびターゲット・アプリケーション・サーバーに固有の場合)
application.xml
とweb.xml
を更新してアプリケーション・サーバーとの互換性を確保(必要な場合)
web.xml
でアプリケーションをReal User Experience Insight (RUEI)に対して有効化(希望する場合)
アプリケーション・レベルのセキュリティ・ポリシー・データをドメインレベルのセキュリティ・ポリシー・ストアに移行
Oracle Single Sign-On (Oracle SSO)を使用してWebアプリケーションを実行する場合は、ドメインのjps-config.xml
ファイルでOracle SSOのサービスおよびプロパティを構成
アプリケーション・サーバーがすでにインストールされている必要があります。Oracle WebLogic Serverの場合は、Oracle 12c InstallerまたはOracle Fusion Middleware 12c Application Developer Installerを使用してインストールできます。他のアプリケーション・サーバーについては、対象アプリケーション・サーバーのドキュメントの説明に従ってサーバーを取得し、インストールしてください。
また、Fusion Webアプリケーションのデプロイに向けてアプリケーション・サーバーを準備する必要もあります。詳細は、『Oracle ADFアプリケーションの管理』のスタンドアロン・アプリケーション・サーバーのデプロイの準備に関する項を参照してください。
ADFランタイムを使用して、Oracle WebLogic ServerドメインをADF互換に拡張
WebLogicの場合は、必要に応じて、Oracle WebLogic Server資格証明ストアの上書きを設定(-Djps.app.credential.overwrite.allowed=true
設定)。
データ・ソースへの接続を必要とするアプリケーションのためのグローバルなJDBCデータ・ソースの作成
アプリケーションとアプリケーション・サーバーの準備が完了したら、次の作業を行うことができます。
JDeveloperを使用して次を実行します。
デプロイメント・プロファイルとアプリケーション・サーバー接続を使用して、アプリケーション・サーバーに直接デプロイします。
デプロイメント・プロファイルを使用して、EARファイルにデプロイします。Oracle ADFアプリケーションの場合、WARファイルとMARファイルはEARファイルの一部としてのみデプロイできます。
Enterprise Manager、スクリプト、またはアプリケーション・サーバーの管理ツールを使用して、JDeveloperで作成したEARファイルをデプロイします。詳細は、『Oracle ADFアプリケーションの管理』を参照してください。
JDeveloperは、統合WebLogic Serverとともにインストールされますが、この統合WebLogic Serverをアプリケーションのテストと開発に使用できます。開発目的では、統合WebLogic Serverで十分なことがほとんどです。アプリケーションをテストする準備が整ったら、実行ターゲットを選び、メイン・メニューから「実行」コマンドを選択します。
注意:
アプリケーションを統合WebLogic Serverで初めて実行する際、「デフォルト・ドメインの作成」ダイアログが表示され、新しいドメインの管理パスワードを定義します。
アプリケーション・ターゲットを実行すると、プロジェクトとワークスペースのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプが自動的に検出されます。次に、アプリケーションを統合WebLogic Serverにデプロイするためのメモリー内デプロイメント・プロファイルが作成されます。プロジェクトとアプリケーション・ワークスペースのファイルは、展開EARディレクトリ構造にコピーされます。このファイル構造は、アプリケーションをEARファイルにデプロイする場合のEARファイル構造を忠実に模したものです。続いて、標準のデプロイ手順に従って、展開EARファイルが統合WebLogic Serverに登録およびデプロイされます。展開EAR方式を取ることで、実際のEARファイルのパッケージ化とパッケージ化解除によって生じるパフォーマンス・オーバーヘッドが軽減されます。
要約すれば、実行ターゲットを選択して統合WebLogic Serverでアプリケーションを実行すると、JDeveloperによって次のことが行われます。
プロジェクトとアプリケーションのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプを検出
メモリー内にデプロイメント・プロファイルを作成
プロジェクトとアプリケーションのファイルを、アプリケーションの展開EARファイルをシミュレートしたファイル構造を持つ作業ディレクトリにコピー
模擬EARを統合WebLogic Serverに登録およびデプロイするためのデプロイ・タスクを実行
アイデンティティ、資格証明およびポリシーを自動的に移行
後で、スタンドアロンのWebLogic Serverインスタンスにアプリケーションをデプロイする予定がある場合は、このセキュリティ情報の移行が必要になります。詳細は、「ADFセキュリティを有効にしたアプリケーションのデプロイ方法」を参照してください。
注意:
統合WebLogic Serverでアプリケーションを実行する際、アプリケーションに対して作成されたデプロイメント・プロファイルは無視されます。
アプリケーションは、統合WebLogic Serverの基本ドメインで実行されます。この基本ドメインは、スタンドアロンのWebLogic Serverインスタンスの基本ドメインと同じ構成になっています。つまり、この基本ドメインは、Oracle Fusion Middleware構成ウィザードを使用して、スタンドアロンのWebLogic Serverインスタンスにデフォルト・オプションで基本ドメインを作成した場合と同一です。
JDeveloperでは、JDeveloperテクノロジ拡張に基づいて、この基本ドメインが必要なドメイン拡張テンプレートで拡張されます。たとえば、JDeveloper Studioをインストールした場合、統合WebLogic Server環境がADFランタイム・テンプレート(JRF Fusion Middlewareランタイム・ドメイン拡張テンプレート)で自動的に構成されます。
統合WebLogic Serverのデフォルト・ドメインを明示的に作成することもできます。このデフォルト・ドメインを使用して、アプリケーションを実行およびテストできます。「アプリケーション・サーバー」ウィンドウを開き、IntegratedWebLogicServerを右クリックして、「デフォルト・ドメインの作成」を選択します。
アプリケーションを統合WebLogic Serverで実行して、テストすることができます。ブレークポイントを設定して、ADF宣言デバッガでアプリケーションを実行することも可能です。
始める前に:
統合WebLogic Serverでアプリケーションを実行するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「統合WebLogic ServerでのFusion Webアプリケーションの実行」を参照してください。
統合WebLogic Serverでアプリケーションを実行するには:
アプリケーションが統合WebLogic Serverで実行されている場合、MAR(メタデータ・アーカイブ)プロファイルそのものはリポジトリにデプロイされませんが、MARに含まれるメタデータ情報を反映した模擬MDSリポジトリがアプリケーション用に構成されます。このメタデータ情報はシミュレートされ、ソース・コントロール内のこの場所を基準にアプリケーションが実行されます。
アプリケーションによって作成されたカスタマイズ内容やドキュメントのうち、他のMDSリポジトリに格納するよう構成されていないものは、この模擬MDSリポジトリのディレクトリに書き込まれます。たとえば、オブジェクトをカスタマイズした場合、その内容は模擬MDSリポジトリに書き込まれます。新しいメタデータ・オブジェクトを作成するコードを実行した場合、この新しいメタデータ・オブジェクトも模擬MDSリポジトリの同じ場所に書き込まれます。このディレクトリは、デフォルトの場所(ORACLE_HOME\jdeveloper\
systemXX.XX\o.mds.dt\adrs\
Application\AutoGeneratedMar\mds_adrs_writedir
)をそのまま使用することも、別のディレクトリに設定することも可能です。アプリケーションが複数回実行される間、このディレクトリをずっと保持するか、それとも各実行の前に削除するかも選択できます。
ワークスペースに異なるワーキング・セットがある場合、ワーキング・セットとその依存オブジェクトで定義されたプロジェクトのメタデータのみがMARに組み込まれます。「アプリケーション」ウィンドウでプロジェクトを右クリックして「プロジェクト・プロパティ」を選択し、「依存性」を選択すると、プロジェクトの依存性の表示または変更が行えます。たとえば、アプリケーションに複数のプロジェクトがあるが、workingsetA
はviewcontroller2
およびviewcontroller5
として定義され、viewcontroller5
はmodelproject1
に依存しているとします。workingsetA
を実行またはデバッグすると、viewcontroller2
、viewcontroller5
およびmodelproject1
のメタデータのみがデプロイ用のMARに組み込まれます。
始める前に:
統合WebLogic Serverでメタデータを使用してアプリケーションを実行するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「統合WebLogic ServerでのFusion Webアプリケーションの実行」を参照してください。
次のタスクを完了する必要があります。
MARプロファイルを統合WebLogic Serverにデプロイするには:
Fusion Webアプリケーションをスタンドアロン・アプリケーション・サーバーにデプロイする前に、JDeveloperで必須のタスクを実行し、デプロイに向けてアプリケーションを準備する必要があります。
図54-3 に、アプリケーションをデプロイ用に準備する場合のプロセス・フローを示します。『Oracle ADFアプリケーションの管理』で説明されているようにアプリケーションが準備され、アプリケーション・サーバーが準備された後、「アプリケーションのデプロイ」の説明に従ってアプリケーションをデプロイできます。
JDeveloperアプリケーション・サーバー接続を介して、アプリケーション・サーバーにアプリケーションをデプロイできます。
アプリケーションにMDSを使用したカスタマイズが加えられている場合は、MDSリポジトリをアプリケーション・サーバーに登録してください。
WebLogicの場合: MDSをWebLogicドメインに登録
WebLogicでのMDSの登録の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
MDSの登録の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
始める前に:
デプロイメント用のアプリケーションを準備するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・サーバーへの接続の作成方法:
デプロイメント・プロファイルでは、ターゲット環境にデプロイされるアーカイブにアプリケーションがパッケージ化される方法が定義されています。デプロイメント・プロファイルには、次の役割があります。
作成されるアーカイブ・ファイルのフォーマットと内容を指定します。
パッケージ対象となるソース・ファイル、デプロイメント・ディスクリプタ、およびその他の補助ファイルをリストします。
作成されるアーカイブ・ファイルのタイプおよび名前を記述します。
依存情報、プラットフォーム固有の指示、およびその他の情報を示します。
アプリケーションにデプロイするWebユーザー・インタフェース・プロジェクトそれぞれにWARデプロイメント・プロファイルが必要です。シード・カスタマイズをパッケージ化する場合や、ベース・メタデータをMDSリポジトリに保存する場合は、アプリケーション・レベルのメタデータ・アーカイブ(MAR)・デプロイメント・プロファイルも必要になります。シード・カスタマイズの詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。アプリケーションにカスタマイズ・クラスがある場合は、そのクラスを格納するJARファイルが必要であり、EARファイルの作成時にそのJARを追加する必要があります。さらに、アプリケーション・レベルのEARデプロイメント・プロファイルも必要です。WARプロファイルやMARプロファイル、カスタマイズ・クラスのJARファイルなど、その中に組み込むプロジェクトをリストから選択する必要があります。アプリケーションがデプロイされるとき、EARファイルは、デプロイメント・プロファイルで選択されたすべてのプロジェクトを組み込みます。
注意:
ADF Fusion Web Applicationテンプレートを使用してプロジェクトまたはアプリケーションを作成する場合、JDeveloperによりデフォルトのWAR、EAR、MARおよびJARデプロイメント・プロファイルが自動的に作成されます。通常、デプロイメント・プロファイルを手動で編集または作成する必要はありません。
Oracle ADFアプリケーションの場合、アプリケーションはEARファイルとしてのみデプロイできます。デプロイメント・プロファイルを作成する際に、アプリケーションの一部となるWARファイルとMARファイルをEARファイルに組み込む必要があります。
注意:
デプロイするビジネス・サービスがFusion Webアプリケーションにある場合は、ビジネス・コンポーネント・サービス・インタフェース・デプロイメント・プロファイルを作成してデプロイする必要があります。ビジネス・サービスの詳細は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。
アプリケーションにパッケージ化するWebベースのプロジェクトごとに、WARデプロイメント・プロファイルを作成する必要があります。通常、WARプロファイルには必要な依存データ・モデル・プロジェクトが組み込まれます。
始める前に:
WARデプロイメント・プロファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
次のタスクを完了する必要があります。
アプリケーションのWARデプロイメント・プロファイルを作成するには:
MDSリポジトリに保存するシード・カスタマイズやベース・メタデータがある場合は、MARデプロイメント・プロファイルを作成する必要があります。
adf-config.xml
ファイルの<mds-config>
におけるMARコンテンツのネームスペース構成は、「MARデプロイメント・プロファイルのプロパティ」ダイアログでの選択内容に基づいて生成されます。
まれなことですが、1つのエンタープライズ・アプリケーション(1つのEARにパッケージ化)に複数のWebアプリケーション・プロジェクト(複数のWARにパッケージ化)が含まれている場合があります。しかし、このようなWebアプリケーションのメタデータはすべて、単一のメタデータ・アーカイブ(MAR)にパッケージ化されます。これらそれぞれの個別のWebアプリケーションから取り込まれたメタデータは、グローバル(すべてのWebアプリケーションで使用可能)である場合と、その特定のWebアプリケーションに対してローカルの場合があります。
グローバル・スコープを持つメタデータの名前の競合を防止するために、すべてのメタデータ・オブジェクトおよび要素が、アプリケーション全体の一部を形成するすべてのWebアプリケーション・プロジェクトを通して一意の名前を持つようにします。
「プロジェクト・プロパティ」ダイアログの「ADFビュー」ページで「ユーザー・カスタマイズの有効化」オプションと「MDSを使用したセッション間」オプションを選択した場合、またはadf-config.xml
ファイルにデプロイメント・ターゲット・ディレクトリを明示的に指定した場合は、自動生成MARが作成されます。
始める前に:
MARデプロイメント・プロファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
次のタスクを完了する必要があります。
MARデプロイメント・プロファイルを作成するには:
EARファイルには、アプリケーション・サーバーでアプリケーションを実行するために必要なアプリケーション・アーティファクトがすべて含まれています。ADF Fusion Webアプリケーション・テンプレートを使用した場合は、すでにデフォルトのEARデプロイメント・ファイルが存在します。EARファイルの詳細は、「EARファイルとパッケージ化に関する必知事項」を参照してください。
始める前に:
EARデプロイメント・プロファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
次のタスクを完了する必要があります。
「JARへのカスタマイズ・クラスの追加」の説明に従って、JARファイルにクラスを追加します。
「WARデプロイメント・プロファイルの作成」の説明に従って、WARデプロイメント・プロファイルを作成します。
アプリケーションのEARデプロイメント・プロファイルを作成するには:
「アプリケーション」ウィンドウで、アプリケーションを右クリックして、「新規」→「ギャラリから」を選択します。
アプリケーションのEARプロファイルを作成します。
「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「EARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。
「デプロイメント・プロファイルの作成 -- EARファイル」ダイアログで、アプリケーション・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。
「EARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。
次の手順を必ず実行してください。
「アプリケーション・アセンブリ」を選択し、続いて「Java EEモジュール」リストで、デプロイメントに組み込むすべてのプロジェクト・プロファイルを選択します(WARまたはMARプロファイルを含む)。
「プラットフォーム」を選択し、デプロイ先となるアプリケーション・サーバーを選択した後、「ターゲット接続」ドロップダウン・リストから、ターゲット・アプリケーション接続を選択します。
注意:
JAZNを使用した認証でカスタムのJAAS LoginModuleを使用している場合は、コンテキスト・ルート名によって、JAAS LoginModuleの検索に使用されるアプリケーション名も定義されます。
アプリケーションにカスタマイズ・クラスがある場合は、そのクラスがEARレベルのアプリケーション・クラス・ローダーからロードされるように構成する必要があります。
注意:
アプリケーションの拡張プロジェクトにカスタマイズ・クラスを作成し、「アプリケーションのプロパティ」ダイアログの「ライブラリとクラスパス」ページを使用してこれらを含めた場合、これらはデフォルトでEARレベルにパッケージ化されるため、この手順は不要です。
「EARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「アプリケーション・アセンブリ」を選択します。
カスタマイズ・クラスを含むJARデプロイメント・プロファイルを選択して、ダイアログの一番下にある「EARのパス」フィールドにlib
を入力します。
注意:
このJARは、「JARへのカスタマイズ・クラスの追加」の説明に従って作成したものです。
カスタマイズ・クラスを含むJARファイルが、EARファイルのlib
ディレクトリに追加されます。
注意:
アプリケーションにカスタマイズ・クラスがある場合は、カスタマイズ・クラスがWARからロードされないようにする必要があります。デフォルトでは、データ・モデル・プロジェクトのライブラリおよびクラスパスに追加されるカスタマイズ・クラスは、WARクラス・パスにパッケージ化されます。
カスタマイズ・クラスをコンシューミング・アプリケーションのデータ・モデル・プロジェクトで作成した場合は、「WARデプロイメント・プロファイルのプロパティの編集」ダイアログの「フィルタ」ページですべてのカスタマイズ・クラスを選択解除します。
再度「OK」をクリックして、「EARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。
「OK」を再度クリックして、アプリケーション・プロパティのダイアログを終了します。
注意:
カスタマイズ・クラスがEARクラス・パスに正しく追加されていることを検証するには、EARプロファイルをファイル・システムにデプロイします。その後、EARを調べ、カスタマイズ・クラスJARがEARクラス・パス(EAR/lib
ディレクトリ)で使用でき、WARクラス・パス(WEB-INF/lib
ディレクトリおよびWEB-INF/classes
ディレクトリ)で使用できないことを確認します。
アプリケーションにカスタマイズ・クラスがある場合は、そのカスタマイズ・クラスのみを格納するJARを作成します。このJARは、EARを作成する際にEARアセンブリに追加できます。WebプロジェクトのWARプロファイルを作成する場合は、このプロファイルにカスタマイズ・クラスのJARを組み込まないようにする必要があります。
始める前に:
カスタマイズ・クラスを追加するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
次のタスクを完了する必要があります。
JARにカスタマイズ・クラスを追加するには:
「アプリケーションレベルのEARデプロイメント・プロファイルの作成」で説明しているように、カスタマイズ・クラスをEARに追加する別の方法として、カスタマイズ・クラスを共有ライブラリとしてコンシューミング・アプリケーションに追加することもできます。
注意:
この手順では、Oracle Weblogic Serverにデプロイする場合の、共有ライブラリの作成および使用方法について説明します。
始める前に:
カスタマイズ・クラス用に共有ライブラリを作成および使用するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
次のタスクを完了する必要があります。
カスタマイズ・クラスの共有ライブラリを作成および使用するには:
デプロイメント・プロファイルを作成したら、そのプロパティを表示および変更できます。
始める前に:
デプロイメント・プロファイルを表示するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
プロジェクトのデプロイメント・プロファイルを作成、編集、または削除するには:
デプロイメント・ディスクリプタは、アプリケーションのデプロイ構成を定義するサーバー構成ファイルで、必要に応じてJava EEアプリケーションとともにデプロイされます。プロジェクトに必要なデプロイメント・ディスクリプタは、プロジェクトが使用しているテクノロジとターゲット・アプリケーション・サーバーのタイプによって異なります。デプロイメント・ディスクリプタは、ソース・ファイルとして作成および編集できるXMLファイルですが、JDeveloperは、ほとんどのディスクリプタ・タイプについて、プロパティの表示と設定に使用できるダイアログまたは概要エディタを備えています。これらのファイルを宣言的に編集できない場合、その内容を編集できるようにソースエディタでXMLファイルが開きます。
標準のJava EEデプロイメント・ディスクリプタ(application.xml
およびweb.xml
など)に加えて、ターゲット・アプリケーション・サーバーに固有のデプロイメント・ディスクリプタも使用できます。たとえば、Oracle WebLogic Serverにデプロイする場合、weblogic.xml
、weblogic-application.xml
およびweblogic-ejb-jar.xml
を使用できます。
WebLogic Serverの場合は、アプリケーションのEARファイルに、adf.oracle.domain
への参照を含むweblogic-application.xml
ファイルが組み込まれていること、そしてデプロイ作業とアンデプロイ作業の間にアプリケーション・リソースをクリーンアップするためのADFApplicationStateListener
が組み込まれていることを確認してください。次の例は、weblogic-application.xml
ファイルのサンプルを示しています。
<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-application"> <listener> <listener-class>oracle.adf.share.weblogic.listeners. ADFApplicationStateListener</listener-class> </listener> <listener> <listener-class>oracle.mds.lcm.weblogic.WLLifecycleListener</listener-class> </listener> <library-ref> <library-name>adf.oracle.domain</library-name> </library-ref> </weblogic-application>
Webサービスをデプロイする場合は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」の説明に従って、weblogic-application.xml
ファイルとweb.xml
ファイルを変更する必要が生じることがあります。
アプリケーションに対してReal User Experience Insight (RUEI)によるモニタリングを行えるようにするには、「RUEIの適用とクリック履歴の有効化」の説明に従って、web.xml
ファイルにパラメータを追加する必要があります。
デプロイ時には、アプリケーションとともにEARファイルにデプロイされるweblogic-application.xml
ファイルに、アプリケーションのセキュリティ・プロパティが書き込まれます。詳細は、「セキュリティ・デプロイメント・オプション構成時の処理」を参照してください。
Oracle WebLogic ServerはJava EEプラットフォーム上で動作するため、application.xml
ファイルとweb.xml
ファイルを変更してアプリケーション・サーバーと互換性を持たせることが必要になる場合があります。
必要なデプロイメント・ディスクリプタの多くは、自動的に作成されます。必要なデプロイメント・ディスクリプタが存在しない場合や、追加のディスクリプタを作成する必要がある場合は、JDeveloperを使用して作成できます。
始める前に:
デプロイメント・ディスクリプタを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
次のタスクを完了する必要があります。
デプロイメント・ディスクリプタの作成方法:
注意:
EARファイルの場合は、1つのアプリケーションまたはワークスペースに同じタイプの複数のデプロイメント・ディスクリプタを作成しないでください。これらのファイルはプロジェクトに割当て可能ですが、アプリケーション・ワークスペース・スコープがあります。アプリケーションの複数のプロジェクトが同じデプロイメント・ディスクリプタを使用すると、起動されたプロジェクトに属するディスクリプタが他のディスクリプタより優先されます。この制約は、application.xml
、weblogic-jdbc.xml
、jazn-data.xml
およびweblogic.xml
に適用されます。
アプリケーション・レベルのディスクリプタを作成するのに最適な場所は、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」ノードです。アプリケーションは、確実に、正しいディスクリプタとともに作成されます。
プロジェクトで作成されたアプリケーション・レベル・ディスクリプタは、実行時に無視されます。実行時には、アプリケーション・リソースのディスクリプタ、またはEARレベルで生成されたディスクリプタのみが使用されます。
デプロイメント・ディスクリプタを作成したら、JDeveloperの各種ダイアログを使用するか、ソース・エディタでファイルを編集することで、そのプロパティを変更できます。デプロイメント・ディスクリプタは、通常「アプリケーション・ソース」ノードにあるXMLファイル(application.xml
など)です。
始める前に:
デプロイメント・ディスクリプタを表示するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
デプロイメント・ディスクリプタのプロパティの表示または変更方法:
ご使用のJava EEバージョンに準拠するようにapplication.xml
ファイルを構成しなければならないことがあります。
注意:
通常、プロジェクトには互換性のあるapplication.xml
ファイルがあるため、この手順を実行する必要はありません。
始める前に:
application.xml
の構成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
application.xmlファイルを構成するには:
application.xml
ファイルを適切な値で編集します。ご使用のJava EEバージョンに準拠するようにweb.xml
ファイルを構成しなければならないことがあります。詳細は、「web.xml」を参照してください。
注意:
通常、プロジェクトには互換性のあるweb.xml
ファイルがあるため、この手順を実行する必要はありません。プロジェクトを作成すると、初期のweb.xml
ファイルが自動的に作成されます。
始める前に:
web.xml
の構成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。
web.xmlファイルを構成するには:
Real User Experience Insight (RUEI)はWebベースのユーティリティで、ネットワークからリクエストされる、またはネットワークで生成される実際のユーザーのトラフィックに対してレポートを作成します。ネットワーク・インフラストラクチャの最も重要となるポイントで、ページやトランザクションのレスポンス時間を測定します。セッション診断情報を使用すれば、根本原因分析を実行できます。
RUEIでは、実際のユーザー体験に基づいてサーバーおよびネットワーク時間を表示し、キー・パフォーマンス・インディケータ(KPI)とサービス・レベル合意(SLA)をモニターし、定義済のターゲットに違反するインシデントが発生した場合にアラート通知をトリガーすることが可能です。ページ・コンテンツ、サイト・エラー、およびトランザクションの機能要件に関するチェックを実施できます。この情報を使用することで、業務面、技術面から運用を検証できます。RUEIで認識されるすべての項目の可用性、スループットおよびトラフィックに関して、カスタム・アラートを設定することもできます。
RUEIの詳細は、http://www.oracle.com/technetwork/documentation/realuserei-091455.html
にあるOracle Real User Experience Insightドキュメントを参照してください。
クリック履歴は、ボタンのクリックやマウスのスクロールなどのUIコンポーネントに対するユーザー・アクションをレポートする、ADFに組み込まれた機能です。クリック履歴は、web.xml
およびweblogic.xml
ファイルを使用してWebLogicサーバーで、またアプリケーション内で有効にする必要があります。
クリック履歴の詳細およびそれをWebLogicサーバーで有効にする方法は、『Oracle ADFアプリケーションの管理』のクリック履歴に関する項を参照してください。
web.xmlファイルでRUEIおよびクリック履歴を有効にする手順:
「アプリケーション」ウィンドウで、WEB-INFを開き、web.xmlをダブルクリックします。
次の例に示すように、概要エディタで、context-param
タグをweb.xml
ファイルに追加します。
<context-param> <description>This parameter notifies ADF Faces that the ExecutionContextProvider service provider is enabled. When enabled, this will start monitoring and aggregating user activity information for the client initiated requests. By default this param is not set or is false. </description> <param-name> oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER </param-name> <param-value>true</param-value> </context-param>
クリック履歴では、web.xml
ファイルへのパラメータの追加に加えて、weblogic.xml
ファイルにodl.clickhistory.webapp
ライブラリを定義する必要もあります。
weblogic.xmlファイルを使用してクリック履歴の有効化を完了する手順:
「アプリケーション」ウィンドウで、WEB-INFを開き、weblogic.xmlをダブルクリックします。
次の例に示すように、概要エディタで、ライブラリ・エントリをweblogic.xml
ファイルに追加します。
<library-ref> <library-name>odl.clickhistory.webapp</library-name> </library-ref>
EndUserMonitoringService
サービス・プロバイダが使用可能な場合、これをアプリケーションに登録することで、これを使用してパフォーマンス・メトリックとデータをロギングできます。EndUserMonitoringService
クラスを開いて、このサービス・プロバイダを実装しておく必要があります。このクラスの詳細は、Javadocを参照してください。
ADFアプリケーション内でEndUserMonitoringServive
プロバイダを使用する場合は、コンテキスト・パラメータoracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER
を設定する必要があります。
アプリケーションでエンド・ユーザー・モニタリングを有効にするには:
統合WebLogic Serverを使用してJDeveloperでアプリケーションを開発する場合、アプリケーション・セキュリティ・デプロイメント・プロパティがデフォルトで構成されます。つまり、開発目的で再デプロイするたびに、アプリケーションとセキュリティの資格証明およびポリシーが上書きされることになります。ただし、アプリケーション・セキュリティ・デプロイメント・プロパティは、統合WebLogic ServerおよびスタンドアロンのWebLogic Serverの両方で同じです。
デフォルト動作は、「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明されているように「アプリケーション・プロパティ」ダイアログで変更できます。
ADFセキュリティを有効にしたWebアプリケーションを、アプリケーション・サーバーにデプロイして実行するには、ターゲット・サーバーの管理者がOracle Access Manager (OAM)セキュリティ・プロバイダのドメインレベルのjps-config.xml
ファイルを構成する必要があります。この構成タスクを実行するため、JDeveloperに付属しているOracle WebLogic Scripting Tool (WLST)を使用できます。WLSTの実行方法(コマンドaddOAMSSOProvider(loginuri, logouturi, autologinuri)
を使用)の詳細は、『Oracle Access Management管理者ガイド』の付録A「Oracle ADFアプリケーションとOracle Access Manager SSOの統合」にあるOracle ADFセキュリティおよびOPSS SSOフレームワークを使用したAccess ManagerとWebアプリケーションの統合に関する項を参照してください。
addOAMSSOProvider()
コマンドを実行することで、ADFセキュリティ・フレームワークが確実にOAMサービス・プロバイダに従って、ObSSOCookie
トークンをクリアするようになります。OAMでは、このトークンを使用して認証済ユーザーのアイデンティティが保存されるため、ログアウト中にトークンがクリアされないかぎり、ユーザーはログアウトできません。
システム管理者がターゲット・サーバーに対してコマンドを実行すると、ドメインのjps-config.xml
ファイルに、ADFセキュリティ固有の次のセキュリティ・プロバイダ定義が追加されます。
<propertySet name="props.auth.uri"> <property name="login.url.FORM" value="/${app.context}/adfAuthentication"/> <property name="logout.url" value=""/> </propertySet>
また、SSOに必要な認証タイプはCLIENT-CERT
です。デプロイ済アプリケーションのweb.xml
認証構成に、<auth-method>
要素を次のいずれかのCLIENT-CERT
タイプとして指定する必要があります。
WebLogicでは、次の2種類の認証方式をサポートしています。
FORM
タイプの認証方式の場合、次のような要素を指定します。
<login-config> <auth-method>CLIENT-CERT,FORM</auth-method> <realm-name>myrealm</realm-name> <form-login-config> <form-login-page>/login.html</form-login-page> <form-error-page>/error.html</form-error-page> </form-login-config> </login-config>
BASIC
タイプの認証方式の場合、次のような要素を指定します。
<login-config> <auth-method>CLIENT-CERT,BASIC</auth-method> <realm-name>myrealm</realm-name> </login-config>
web.xml
ファイルは、Webアプリケーションをデプロイする前でも後でも構成可能です。シングル・サインオンの認証方法の設定の詳細は、『Oracle Access Management管理者ガイド』の第IV部「Access Manager SSO、ポリシーおよびテストの管理」を参照してください。
開発環境では、サーバーが開発モードに設定されている場合にのみ、アプリケーション・レベルの資格証明、アイデンティティおよびポリシーがスタンドアロンWebLogic Serverインスタンスへ自動的に移行されます。統合WebLogic Serverはデフォルトで開発モードに設定されています。Oracle WebLogic Serverドメインの作成時に、Oracle Fusion Middleware構成ウィザードを使用して、スタンドアロンWebLogic Serverを開発モードに設定できます。Oracle WebLogic Serverドメインの構成の詳細は、『構成ウィザードによるWebLogicドメインの作成』を参照してください。
本番モードでは、アプリケーション・レベルのセキュリティ資格証明はWebLogic Server設定に移行されません。本番環境では一般に、管理者はEnterprise ManagerまたはWLSTを使用してアプリケーション(セキュリティ要件を含む)をデプロイします。
アプリケーションをWebLogic Serverにデプロイすると、資格証明(cwallet.sso
ファイルに含まれる)およびセキュリティ・ポリシー(jazn-data.xml
ファイルに含まれる)は、WebLogic Serverのドメインレベルの資格情報ストアを上書きするか、これらとマージされます。上書きとマージのどちらが行われるかは、weblogic-application.xml
のオプションがOVERWRITE
またはMERGE
のいずれに設定されているかによって決まります。本番モードのWebLogic Serverでは、セキュリティ・リスクを回避するため、MERGE
しか使用できません。開発モードのWebLogic Serverでは、モードをOVERWRITE
に設定して、ユーザー名とパスワードをテストできます。また、オプションを設定するには、setDomainEnv.cmd
またはsetDomainEnv.sh
を実行できます。その際、コマンド(通常はORACLE_HOME/user_projects/domains/
MyDomain
/bin
にあります)に次のオプションを追加します。
setDomainEnv.cmd
の場合:
set EXTRA_JAVA_PROPERTIES=-Djps.app.credential.overwrite.allowed=true %EXTRA_JAVA_PROPERTIES%
setDomainEnv.sh
の場合:
EXTRA_JAVA_PROPERTIES="-Djps.app.credential.overwrite.allowed=true ${EXTRA_JAVA_PROPERTIES}" export EXTRA_JAVA_PROPERTIES
管理サーバーがすでに稼働している場合、この設定を有効にするにはサーバーを再起動する必要があります。
WebLogic Serverが本番モードかどうかをチェックするには、Oracle WebLogic Server管理コンソールを使用するか、WebLogic Serverのconfig.xml
ファイルで次の行を確認します。
<production-mode-enabled>true</production-mode-enabled>
デフォルトでは、アプリケーションの資格証明、アイデンティティおよびポリシーはOVERWRITE
モードに設定されます。つまり、「アプリケーションのプロパティ」ダイアログの「デプロイメント」ページで、「アプリケーション・ポリシー」、「資格証明」、「ユーザーとグループ」の各オプションがデフォルトで選択されます。ただし、アプリケーションの資格証明が移行されるのは、ターゲットとなるWebLogic Serverインスタンスが-Djps.app.credential.overwrite.allowed=true
の指定によって開発モードに設定されている場合のみです。
ポリシーの移行は開発モードでのみ実行されます。アイデンティティの移行が実行できるのは、開発または本番モードにかかわらず、JDeveloperを使用してWebLogic Serverに直接デプロイする場合のみです。
アプリケーションを本番環境にデプロイする準備ができたら、jazn-data.xml
ファイルからアイデンティティを削除するか、「アプリケーションのプロパティ」ダイアログで「ユーザーとグループ」を選択解除して、アイデンティティの移行を無効にしてください。アプリケーションの資格証明は、JDeveloperの外部で、手動で移行する必要があります。
注意:
jazn-data.xml
ファイルを本番環境に移行する前に、ポリシー・ストアに、重複する権限付与のためのパーミッションがないか確認します。ファイル内に重複するパーミッション(同じ名前とクラスを持つパーミッション)がある場合は、ポリシー・ストアを移行する管理者にエラーが表示され、ポリシーの移行が停止します。jazn-data.xml
ファイルを手動で編集して、権限付与の定義から重複するパーミッションをすべて削除する必要があります。
アプリケーションの資格証明およびその他のjazn-data
ユーザー資格証明の移行の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」を参照してください。
アプリケーションにJDBC URL接続を使用するコンポーネントがある場合、接続のユーザー名とパスワードもアプリケーション・レベルの資格証明およびポリシー・ストアに格納されます。デプロイされたアプリケーションがJDBC URLを使用してデータベースに接続できるようにする場合は、これらの資格証明とポリシーを移行する必要があります。すなわち、WebLogic Serverが本番モードの場合、システム管理者はこのセキュリティ情報を移行する必要があります。WebLogic Serverが開発モードの場合は、ドメインレベルの資格証明とポリシー・ストアをOVERWRITE
に設定して、セキュリティ情報の移行を許可する必要があります。
クラスタ環境での実行を想定したアプリケーションをデプロイする場合、存続期間が1つのリクエストより長いマネージドBeanがすべてシリアライズ可能であること、そしてOracle ADFがADFスコープ(ビュー・スコープとページ・フロー・スコープ)に格納されるマネージドBeanへの変更を認識することを確認する必要があります。
詳細は、「サーバー/クラスタ環境でのマネージドBeanメモリー・スコープの設定方法」を参照してください。
Fusion Webアプリケーションでは、多くのXMLファイルを使用して構成情報が設定されています。これらの3つの構成ファイルには、アプリケーションとともにデプロイされ、構成ファイルと同じ役割を果すADF MBeanがあります。アプリケーションがデプロイされたら、Enterprise Manager Fusion Middleware ControlのMBeanブラウザを使用してADF MBeanにアクセスし、構成プロパティを変更することができます。
ADF MBeanを有効にするには、これをweb.xml
ファイルに登録します。次の例は、接続、構成およびビジネス・コンポーネントのリスナー・エントリを含むweb.xml
ファイルを示しています。
<listener> <listener-class> oracle.adf.mbean.share.connection.ADFConnectionLifeCycleCallBack </listener-class> </listener> <listener> <listener-class> oracle.adf.mbean.share.config.ADFConfigLifeCycleCallBack</listener-class> </listener> <listener> <listener-class> oracle.bc4j.mbean.BC4JConfigLifeCycleCallBack</listener-class> </listener>
また、ADF接続MBeanを使用したconnections.xml
のデプロイメント後の構成、およびADFビジネス・コンポーネントMBeanを使用したbc4j.xcfg
のデプロイメント後の構成を有効にするために、書込み可能なMDSリポジトリを構成する必要があります。
データベース・ベースのMDSを使用する場合のadf-config.xml
ファイルのMDS構成エントリを次の例に示します。MDSの構成の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config"> <mds-config xmlns="http://xmlns.oracle.com/mds/config" version="11.1.1.000"> <persistence-config> <metadata-store-usages> <metadata-store-usage default-cust-store="true" deploy-target="true" id="myStore"> </metadata-store-usage> </metadata-store-usages> </persistence-config> </mds-config> </adf-mds-config>
本番環境では、データベースを使用するMDSリポジトリが必要です。JDeveloper、Enterprise Manager Fusion Middleware Controlまたはスクリプトのいずれかを使用して、ファイルベースのリポジトリからデータベースのMDSリポジトリに切り替えることができます。
また、複数のアプリケーションが同じMDS構成を共有している場合は、adf-config.xml
ファイルでadf:adf-properties-child
プロパティを定義して、各アプリケーションに異なるカスタマイズ・レイヤーを持たせることができます。このエントリは、アプリケーションの作成時に自動的に生成されます。adf-config.xml
ファイルにこのエントリがない場合は、ここに示すようなコードを使用してファイルに追加できます。
<adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties"> <adf-property name="adfAppUID" value="Application3-4434"/> <adf-property name="partition_customizations_by_application_id" value="true"/> </adf:adf-properties-child>
value
属性は、JDeveloperで自動的に生成するか、アプリケーションのデプロイ先となるサーバー・ファーム内で一意の識別子に設定します。この値は、adfAppUID
プロパティのvalue
属性に設定できます。
adf-property name
をadfAppUid
に設定した場合は、対応するvalue
プロパティをアプリケーションの名前に設定する必要があります。デフォルトでは、value
プロパティはアプリケーションのパッケージ名を使用して生成されます。パッケージ名を指定していない場合、value
プロパティはワークスペース名と4桁の乱数を使用して生成されます。
ADF MBeanを使用したADFアプリケーションの構成の詳細は、『Oracle ADFアプリケーションの管理』を参照してください。
ADFアプリケーションでは、データベース接続にJDBCデータ・ソースとJDBC URLのいずれかを使用することができます。JDBCデータ・ソースを構成するには、Oracle WebLogic Server管理コンソールを使用します。データベース・アクセスの詳細は、「アプリケーション・モジュールのデータベース接続の構成」を参照してください。
注意:
Fusion Webアプリケーションは、JDBC XAドライバで定義されたデータ・ソースと互換性がありません。Oracle WebLogic Serverでデータソースを作成する場合、忘れずにFusion Webアプリケーション・データソースのJDBCドライバをOracleのドライバ(Thin XA)からOracleのドライバ(Thin)に変更してください。XAデータ・ソースはコミット時にすべてのカーソルをクローズするため、XAデータ・ソースを使用してFusion Webアプリケーションを実行すると、ランダムにJBO-27122エラーおよび文のクローズ・エラーが発生することがあります。
Fusion Webアプリケーションのデータ・モデル・プロジェクト内のアプリケーション・モジュールは、JDBC URL接続タイプ、JDBCデータソース接続タイプまたはこの2つのタイプの組合せを使用するように構成できます。デフォルトでは、Fusion Webアプリケーション・モジュールはJDBC URL接続を使用します。JDBC URLを使用するコンポーネントは、JDBC URLを使ってデータベースへの直接接続を試みて、WebLogic Serverで使用可能なJDBCデータソース(グローバルまたはアプリケーション・レベル)を無視します。アプリケーションからWebLogic ServerへのJDBC URLセキュリティ情報(ユーザー名とパスワード)の移行の詳細は、「ADFセキュリティを有効にしたアプリケーションのデプロイ方法」を参照してください。
Fusion Webアプリケーションでは、データベースへの接続にJDBCデータソースを使用できます。JDBCデータ・ソースには、グローバル、アプリケーションレベル、パスワード・インダイレクション機能を持つアプリケーションレベルの3種類があります。通常、グローバルなJDBCデータ・ソースはWebLogic Serverで設定します。データベースにアクセスする必要のあるアプリケーションは、そのJDBCデータ・ソースを使用できます。アプリケーションには、アプリケーション・レベルのJDBCデータソースを組み込むこともできます。アプリケーションをデプロイメント用にパッケージ化する際に、「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」オプションを選択すると、定義した接続ごとにconnection_name
-jdbc.xml
ファイルが作成されます。各接続の情報は、対応するconnection_name
-jdbc.xml
ファイルに書き込まれます(weblogic-application.xml
とweb.xml
のエントリも変更されます)。アプリケーションがWebLogic Serverにデプロイされると、サーバーはグローバル・データソースを検索する前に、アプリケーション・レベルのデータソース情報を検索します。
パスワード・インダイレクションをtrue
に設定してアプリケーションをデプロイすると、WebLogic Serverは、connection_name
-jdbc.xml
ファイルを探してユーザー名情報を確認し、そのユーザー名に対応するアプリケーション・レベルの資格証明マップを特定してパスワードを入手しようとします。JDeveloperを使用してアプリケーションをWebLogic Serverに直接デプロイする場合は、資格証明マップが自動的に作成され、MBeanコールを介してサーバーに組み込まれます。
ただし、EARファイルをデプロイする場合は、JDeveloperでWebLogic ServerへのMBeanコールを行えません。Oracle WebLogic管理コンソールを使用して、資格証明マップを設定する必要があります。グローバルなJDBCデータ・ソースを設定した場合でも、資格証明マッピングを設定していなければ、WebLogic Serverは資格証明をパスワードにマップできず、接続は失敗します。
データ・ソースがOracle WebLogic Serverで作成されたら、アプリケーション・モジュールで使用できます。詳細は、『Oracle ADFアプリケーションの管理』のスタンドアロン・アプリケーション・サーバーのデプロイの準備に関する項を参照してください。
ADFアプリケーションは、JDeveloperを使用してスタンドアロン・アプリケーション・サーバーに直接デプロイすることも、アーカイブ・ファイルを作成し、他のツールを使用してアプリケーション・サーバーにデプロイすることもできます。
注意:
Oracle ADFを使用するアプリケーションをスタンドアロン・アプリケーション・サーバーにデプロイし始める前に、ADFランタイムのインストール、およびドメインまたはセルの作成や拡張といったタスクを実行して、アプリケーション・サーバー環境を準備しておく必要があります。詳細は、『Oracle ADFアプリケーションの管理』のスタンドアロン・アプリケーション・サーバーのデプロイの準備に関する項を参照してください。
図54-5 に、ターゲット・スタンドアロン・アプリケーション・サーバーへのアプリケーションのデプロイとカスタマイズのデプロイのプロセス・フローを示します。
表54-1 に、アプリケーションのデプロイおよびデプロイ・サイクル中に使用できる一般的なデプロイ方法を示します。開発環境でのデプロイから本番環境のデプロイまでの順序でデプロイ方法をリストしています。本番環境では、システム管理者がEnterprise Manager Fusion Middleware Controlまたはスクリプトを使用してアプリケーションをデプロイします。
表54-1 開発環境または本番環境でのデプロイ方法
デプロイ方法 | 環境 | 使用するとき |
---|---|---|
JDeveloperから直接実行 |
テストまたは開発 |
この方法は、アプリケーションの開発中に使用します。編集プロセスとデプロイ・プロセスを何度も繰り返す必要があるからです。 JDeveloperには統合WebLogic Serverが含まれています。この統合WebLogic Serverでアプリケーションを実行してテストできます。 |
JDeveloperを使用してターゲット・アプリケーション・サーバーに直接デプロイ |
テストまたは開発 |
この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。 テスト用サーバーでは、開発用サーバーで使用できない機能(LDAPやOracle Single Sign-Onなど)をテストできます。 テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。 |
JDeveloperを使用してEARファイルにデプロイし、ターゲット・アプリケーション・サーバーのデプロイ用ツールを使用 |
テストまたは開発 |
この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。JDeveloperから直接デプロイするかわりに、EARファイルにデプロイしてから、他のツールを使用してアプリケーション・サーバーにデプロイすることができます。 テスト用サーバーでは、開発用サーバーで使用できない機能(LDAPやOracle Single Sign-Onなど)をテストできます。 テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。 |
Enterprise ManagerまたはWLSTを使用してアプリケーションをデプロイ |
本番 |
アプリケーションがテスト環境と本番環境にある場合です。本番環境では、システム管理者がEnterprise Manager Fusion Middleware Controlを使用するか、WLSTを実行して、アプリケーションをデプロイするのが一般的です。 |
必要なMDSリポジトリをすべてアプリケーション・サーバーに登録する必要があります。MDSリポジトリがデータベースの場合、リポジトリはMDS固有の要件を備えたデータソースにマップされます。
アプリケーションをOracle WebLogic Serverにデプロイする前に、このデータ・ソースのターゲットをWebLogic管理サーバー、およびアプリケーションのデプロイ先となるすべての管理対象サーバーに設定する必要があります。MDSの登録の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
adf-config.xml
のMDSリポジトリ構成を必要とするEARファイルとしてパッケージ化されたアプリケーションを、アプリケーション・サーバーの管理コンソールまたはスクリプトを使用してデプロイする場合は、EARファイルをデプロイする前に、getMDSArchiveConfig
コマンドを実行してMDSを構成する必要があります。MDS構成は、EARファイルにMARファイルが含まれる場合、またはアプリケーションがDT@RT (Design Time At RunTime)に対して有効化されている場合に必要です。
WLSTコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』を参照してください。
アプリケーションのデプロイ後に、ADF MBeanを使用してADF接続情報、ADFビジネス・コンポーネント情報またはadf-config.xml
を構成する予定の場合は、アプリケーションがMDSを使用するように構成されていること、およびweb.xml
ファイルでMBeanリスナーが有効になっていることを確認してください。詳細は、「アプリケーションをADF MBeanに対して有効化する方法」を参照してください。
注意:
WebLogic Serverにデプロイするビジネス・サービスがFusion Webアプリケーションにある場合は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。
始める前に:
アプリケーションをデプロイするときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションのデプロイ」を参照してください。
次のタスクを完了する必要があります。
注意:
JDeveloperからOracle WebLogic Serverにデプロイする場合は、Oracle WebLogic Server管理コンソールで、HTTPトンネリング・プロパティが有効になっていることを確認してください。このプロパティは、「サーバー」→ServerName→「プロトコル」の下にあります。ServerNameは、Oracle WebLogic Serverの名前です。
注意:
JDeveloperは、クラスタに属する個々の管理対象サーバーへのアプリケーションのデプロイをサポートしていません。Oracle WebLogic Server管理コンソールやその他のOracle WebLogicツールを使用してクラスタ内の1つ以上の管理対象サーバーをターゲットに設定することは可能ですが、クラスタに悪影響を及ぼす可能性があります。Oracle WebLogic Serverクラスタへのデプロイの詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
JDeveloperからターゲット・アプリケーション・サーバーへのデプロイ方法:
デプロイメント・プロファイルを使用してアーカイブ・ファイル(EARファイル)を作成することもできます。作成したアーカイブ・ファイルは、Enterprise Manager、Oracle WebLogic Scripting Tool (WLST)、Oracle WebLogic Server管理コンソールのいずれかを使用してデプロイできます。
Fusion WebアプリケーションはEARファイル(通常はWAR、MAR、JARのコンポーネントを含む)にカプセル化されますが、部分的にEARではデプロイされないことがあります。たとえば、ADFビジネス・サービスはJARとしてデプロイできます。ビジネス・サービスの詳細は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。
始める前に:
デプロイするためにEARファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションのデプロイ」を参照してください。
次のタスクを完了する必要があります。
EARアーカイブ・ファイルを作成するには:
ヒント:
「表示」→「ログ」を選択し、アーカイブ・ファイルの作成時に生成されたメッセージを表示します。
ADFライブラリ用に新しいカスタマイズを作成した場合は、MARプロファイルを使用して、このカスタマイズをADFライブラリを使用する任意のデプロイ済アプリケーションにデプロイできます。たとえば、ADFLibraryB
を使用するapplicationA
がスタンドアロン・アプリケーション・サーバーにデプロイされるとします。その後、新しいカスタマイズがADFLibraryB
に追加された場合は、この更新されたカスタマイズをapplicationA
にデプロイするだけで済みます。アプリケーション全体を再パッケージ化したり再デプロイする必要はありません。また、MDSリポジトリに手動でパッチを適用する必要もありません。
注意:
この手順は、ADFライブラリのカスタマイズ変更を、スタンドアロン・アプリケーション・サーバーのデプロイ済アプリケーションに適用するためのものです。カスタマイズを初めてMARにパッケージ化し、最終的にEARの一部とするための手順ではありません。MARを使用したカスタマイズの初回パッケージ化の詳細は、「MARデプロイメント・プロファイルの作成」を参照してください。
ADFライブラリのカスタマイズをデプロイするには、新しいMARプロファイルを作成し、デプロイするカスタマイズのみを格納し、JDeveloperを使用して次を実行します。
カスタマイズをスタンドアロン・アプリケーション・サーバーのMDSリポジトリに直接デプロイします。
カスタマイズをJARにデプロイします。次に、Fusion Middleware Controlなどのツールを使用して、JARをMDSリポジトリにインポートします。
カスタマイズは、JDeveloperからスタンドアロン・アプリケーション・サーバーのデプロイ済アプリケーションのMDSリポジトリに直接エクスポートできます。
始める前に:
カスタマイズを直接アプリケーション・サーバーにエクスポートするときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションのデプロイ」を参照してください。
次のタスクを完了する必要があります。
カスタマイズをアプリケーション・サーバーに直接エクスポートするには:
ADFライブラリのカスタマイズをJARにデプロイする場合は、MARプロファイルに定義されているとおりにコンテンツをパッケージ化します。
始める前に:
カスタマイズをJARとしてデプロイするときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションのデプロイ」を参照してください。
次のタスクを完了する必要があります。
カスタマイズをJARとしてデプロイするには::
ADFライブラリは、ADFコンポーネント(ADFタスク・フロー、ページ、アプリケーション・モジュールなど)に対して登録されたJARサービスを含むJARファイルです。プロジェクトのADFコンポーネントを再利用する場合は、プロジェクトのADFライブラリ・デプロイメント・プロファイルを作成してから、そのプロファイルに基づいたADFライブラリJARを作成します。
「リソース」ウィンドウを使用するか、手動でライブラリのクラスパスに追加する方法でADFライブラリJARを追加すると、アプリケーションまたはプロジェクトでそのADFライブラリJARを使用できるようになります。「デフォルトでデプロイ済」オプションが選択されている場合、プロジェクトに追加されたADFライブラリJARは、プロジェクトのWARファイルに組み込まれます。
詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。
Fusion WebアプリケーションをEARファイルにパッケージ化する場合、EARファイルには次のものを組み込むことができます。
WARファイル: Webベースのビュー・コントローラ・プロジェクトはそれぞれWARファイルにパッケージ化します。
MARファイル: アプリケーションとともにデプロイするカスタマイズ内容がある場合、カスタマイズ内容はMARにパッケージ化します。
ADFライブラリJARファイル: アプリケーションでADFライブラリJARが使用される場合、そのJARファイルはEARにパッケージ化できます。
その他のJARファイル: アプリケーションに必要な依存JARファイルが他にもある場合があります。それらはEARにパッケージ化できます。
コマンドを使用してアプリケーションをデプロイし、そのコマンドをスクリプトに記述してプロセスを自動化することができます。ojdeploy
コマンドを使用すると、JDeveloperなしでアプリケーションをデプロイできます。Antスクリプトを使用してアプリケーションをデプロイすることもできます。JDeveloperには、Antスクリプトの作成に役立つ機能が用意されています。要件によっては、通常のスクリプトをAntスクリプトと組み合せることも可能です。
コマンド、スクリプト、Antの詳細は、『Oracle ADFアプリケーションの管理』を参照してください。
ADFモデルを使用せずにADF Facesのみを使用するアプリケーションを開発できます。この場合、ADF Faces JARをアプリケーションとともにアプリケーション・サーバーにデプロイできます。
始める前に:
Webベースのプロジェクトを使用してアプリケーションを作成します。Fusion Web Application (ADF)テンプレートを使用した場合は、すでにデフォルトのWARデプロイメント・ファイルが存在します。
ADF Faces JARをアプリケーションの一部としてデプロイするには:
アプリケーションをWebLogic Serverにデプロイしたら、構成タスクを実行できます。
Fusion WebアプリケーションをWebLogic Server間で移行する場合は、初回のデプロイの際と同じステップの一部を実行する必要があります。
一般に、アプリケーションを移行する際には、次の作業を行います。
ターゲットとなるアプリケーション・サーバーにADFランタイムをロードします(まだインストールされていない場合)。
詳細は、『Oracle ADFアプリケーションの管理』のスタンドアロン・アプリケーション・サーバーのデプロイの準備に関する項を参照してください。
ターゲットとなるアプリケーション・サーバーを正しいデータベース接続情報またはURL接続情報で構成します。
セキュリティ情報をソースからターゲットに移行します。
手順は、「ADFセキュリティを有効にしたアプリケーションのデプロイ方法」を参照してください。
Enterprise Manager、管理コンソール、スクリプトのいずれかを使用してアプリケーションをデプロイします。
詳細は、『Oracle ADFアプリケーションの管理』を参照してください。
ADF MBeanが有効化され、デプロイ済アプリケーションとともにパッケージ化されている場合、Enterprise ManagerのMBeanブラウザを使用してADFプロパティを構成できます。アプリケーションをMBeanに対して有効化する手順は、「アプリケーションをADF MBeanに対して有効化する方法」を参照してください。
ADF MBeanを使用したADFアプリケーションの構成方法の詳細は、『Oracle ADFアプリケーションの管理』を参照してください。
アプリケーションは、デプロイが完了したら、アプリケーション・サーバーからテストできます。ADFアプリケーションをテストするには、ブラウザ・ウィンドウを開き、次のURLを入力します。
Faces以外のページの場合: http://<host>:port/<context root>/<page>
Facesページの場合: http://<host>:port/<context root>/faces/<view_id
>
<view_id>
は、ADFタスク・フローにおけるビュー・アクティビティのビューIDです。
ヒント:
アプリケーションのコンテキスト・ルートは、ユーザー・インタフェース・プロジェクト設定に、デフォルトでApplicationName
/ProjectName
/context-root
として設定されています。この名前を短くするには、ターゲット・アプリケーション・サーバー全体で一意の名前を指定します。ユーザー・インタフェース・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。「プロジェクト・プロパティ」ダイアログで、「Java EEアプリケーション」を選択し、コンテキスト・ルートの一意の名前を入力します。
注意:
FacesページのURLには、/faces
が含まれている必要があります。これは、JDeveloperがFacesサーブレットとの関連付けのために、/faces
というURLパターンを使用するようweb.xml
ファイルを構成するためです。Facesサーブレットは、リクエスト単位処理を実行し、URL内の/faces
部を取り除いた後、そのURLをJSPに転送します。URLに/faces
を指定しないと、Facesサーブレットは関与しません(URLパターンが一致しないためです)。JSPは必要なJSFリクエスト単位処理なしで実行されます。