13 アプリケーション・モジュールによるビジネス・サービスの実装

この章では、JDBCデータソースから導出されたOracle ADFアプリケーションのデータ・モデルをカプセル化するADFアプリケーション・モジュールの作成方法について説明します。この章では、ビジネス・サービス・メソッドをそのデータ・モデルと結合して完全なビジネス・サービスを実装する方法についても説明します。

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

• アプリケーション・モジュールについて

• アプリケーション・モジュールの作成と変更

• アプリケーション・モジュールのデータベース接続の構成

• ネストされたアプリケーション・モジュールの定義

• ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成

• 複数ページの作業ユニットのサポート

• サービス・メソッドによるアプリケーション・モジュールのカスタマイズ

• アプリケーション・モジュール・メッセージ文字列のカスタマイズ

• UIクライアントへのカスタム・サービス・メソッドの公開

• アプリケーション・モジュール・クライアント・インタフェースのプログラム的操作

• 組込みフレームワーク・メソッドの上書き

• アプリケーション・モジュールからのWebサービスのコール

アプリケーション・モジュールについて

ADFアプリケーション・モジュールでは、エンド・ユーザー・タスクを論理作業ユニットとしてカプセル化します。ユーザー・インタフェース・クライアントでは、アプリケーション・モジュールを使用してアプリケーション・データを管理します。

アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールは、ADFビジネス・コンポーネントで、エンド・ユーザー・タスクに関連する論理作業ユニットのビジネス・サービス・メソッドとデータ・モデルをカプセル化したものです。

アプリケーション開発の早期段階では、アーキテクトと設計者は通常、UMLユースケース手法およびADFタスク・フローを使用して、アプリケーションの計画済エンド・ユーザー機能の高レベルな概要を作成します。この設計段階中に識別されるエンド・ユーザーの高レベルな各ユースケースは、一般に次のものに応じて異なります。

• 対象となるドメイン・ビジネス・オブジェクト。ユースケースに関連するコア・ビジネス・データについての問題に解答します。

• 必要なビジネス・データのユーザー指向ビュー。ユースケースをサポートするために必要な列サブセット、フィルタ処理された行セット、ソート方法、グループ化方法などについての問題に解答します。

各ユースケースに関連するドメイン・オブジェクトを識別すると、ビジネス・ドメイン・レイヤー内の必要なエンティティ・オブジェクトを識別する際に便利です。必要なビジネス・データのユーザー指向ビューは、ビュー・オブジェクトとして取得された適切なSQL問合せを定義して、データをエンド・ユーザーの期待どおりに取得する際に便利です。これには、パフォーマンスを最大化するために、ユースケースのサポートに必要な最低限の詳細の取得が含まれます。これまでの説明で、ビュー・オブジェクト問合せおよびビュー基準を利用してデータを形成する方法のみならず、ビュー・リンクを使用してデータ・モデルにマスター/ディテール階層を設定し、期待どおりのエンド・ユーザー体験をユーザーに提供してユースケースを実現する方法も、すでに学習しました。

アプリケーション・モジュールは、当該のユースケースに必要な再使用可能なビュー・オブジェクトのインスタンスを含む作業ユニット・コンテナです。これらのビュー・オブジェクト・インスタンスは、エンド・ユーザー・ユースケースにより表示または変更する情報が決定される再使用可能なビジネス・ドメイン・レイヤー内の基礎となるエンティティ・オブジェクトに、メタデータを通じて関連付けられています。

アプリケーション・モジュールのユースケースと例

この章では、図13-1に示す次の概念について説明します。

• ビュー・オブジェクトのインスタンスをアプリケーション・モジュールで公開して、そのデータ・モデルを定義します。

• サービス・メソッドを記述して、タスク・レベルのビジネス・ロジックをカプセル化します。

• UIクライアントがコールするメソッドを選択し、クライアント・インタフェースで公開します。

• アプリケーション統合シナリオでプログラム的に使用するメソッドを選択し、サービス・インタフェースで公開します。

  12cから、Oracle JDeveloperではADFビジネス・コンポーネント・モデル・プロジェクトにおけるEJBセッションBean対応のアプリケーション・モジュールのサポートが非推奨となった点に注意してください。今後、JDeveloperではEJBセッションBean対応のアプリケーション・モジュールを作成または実行できません。既存のEJBセッションBean対応のアプリケーション・モジュールのかわりとして、「アプリケーション・モジュールによるSOAP Webサービスの作成」に説明されているとおり、アプリケーション・モジュール・サービスをWebサービス対応のアプリケーション・モジュールに移行できます。このアプローチは、外部サービスを使用してサービス・メソッドを公開するためのベスト・プラクティスと一貫しています。

• 複数のWebページまたはビューにまたがる可能性のある論理トランザクション中に、プールのアプリケーション・モジュール・インスタンスを使用します。

• アプリケーション・モジュールでは、データベース接続の取得と、エンティティ・オブジェクトに行われた変更の保存またはロールバックの調整を行うTransactionオブジェクトを操作します。

• 関連するSessionオブジェクトにより、現在のアプリケーション・ユーザーに関するランタイム情報が提供されます。

図13-1 作業ユニットをカプセル化するビジネス・サービス・コンポーネントとして機能するアプリケーション・モジュール

「図13-1 作業ユニットをカプセル化するビジネス・サービス・コンポーネントとして機能するアプリケーション・モジュール」の説明

アプリケーション・モジュールの追加機能

アプリケーション・モジュールを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

• 共有アプリケーション・モジュールの作成の詳細は、「アプリケーション・モジュール・ビュー・インスタンスの共有」を参照してください。

• 外部サービスを使用したADFビジネス・コンポーネント・サービス・メソッドの公開の詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。

• 「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュールの公開方法の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

• 実行時のパフォーマンスを向上させるためのアプリケーション・モジュール・インスタンス構成の詳細は、「Fusion Webアプリケーションでの状態管理の使用」および「アプリケーション・モジュール・プールのチューニング」を参照してください。

• 本番環境のパフォーマンスとスケーラビリティを最大化する方法の詳細は、『パフォーマンスのチューニング・ガイド』の「Oracle Application Development Framework (ADF)のチューニング」を参照してください。

• カスタム・アプリケーション・モジュール・クラスでよく記述、使用またはオーバーライドするコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

• oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

  • Oracle ADFモデルJava APIリファレンス

アプリケーション・モジュールの作成と変更

ユーザー・タスクの観点からアプリケーションのサイズに応じて、単一または複数のADFアプリケーション・モジュールを作成します。

大規模なアプリケーションでは、通常、粒度の粗い各エンド・ユーザー・タスクをサポートするアプリケーション・モジュールを1つずつ作成します。小規模なアプリケーションでは、アプリケーション・モジュールを1つ作成すれば、アプリケーションの全機能のニーズを十分に処理できると判断する場合もあります。「ネストされたアプリケーション・モジュールの定義」には、これに関する追加の説明があります。

アプリケーション・モジュールの作成方法

作成するビュー・オブジェクトは、1つ以上のアプリケーション・モジュールで使用できる再利用可能コンポーネントです。各ビュー・オブジェクトは、そのアプリケーション・モジュールのトランザクションのコンテキストで、カプセル化した問合せを実行します。アプリケーション・モジュールで使用される一連のビュー・オブジェクト・インスタンスは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。

既存のADFビジネス・コンポーネント・プロジェクトにアプリケーション・モジュールを追加するには、「新規ギャラリ」から使用できる「アプリケーション・モジュールの作成」ウィザードを使用します。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

アプリケーション・モジュールを手動で作成するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを作成するプロジェクトを右クリックし、「新規」および「アプリケーション・モジュール」を選択します。
2. 「アプリケーション・モジュールの作成」ウィザードの「名前」ページで、パッケージ名およびアプリケーション・モジュール名を指定します。「次へ」をクリックします。

   ノート:

   Fusion Webアプリケーションでは、アプリケーション・モジュールの名前に予約語のdata、bindings、securityおよびadfContextを使用しないでください。また、名前の先頭に_(アンダースコア)を使用することも避けてください。詳細は、「既存のアプリケーション・モジュールの編集方法」を参照してください。

3. 「データ・モデル」ページで、以前に定義したビュー・オブジェクトのインスタンスを指定し、これらのビュー・オブジェクト・インスタンスの名前を、「データ・コントロール」パネルでクライアントに対して表示される名前とまったく同じ名前に編集します。次に、「次へ」をクリックします。
4. 「Java」ページではオプションでJavaファイルを作成し、アプリケーション・モジュールの動作をプログラミングによってカスタマイズすることができます。あるいは、アプリケーション・モジュールのクライアント・インタフェースにメソッドをエクスポートして、クライアントが呼び出せるようにすることができます。XML専用のアプリケーション・モジュール・コンポーネントを生成するには、このフィールドを選択しないまま、「終了」をクリックします。

   最初に、アプリケーション・モジュールのXML定義コンポーネントのみを生成することもできます。ウィザードを完了した後に、プログラムによるアクセスが必要になる場合は、概要エディタを使用してアプリケーション・モジュール・クラス・ファイルを生成できます。アプリケーション・モジュールのプログラム的な使用の詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。

ステップごとの詳細は、「既存のアプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。

アプリケーション・モジュール作成時の処理

アプリケーション・モジュールを作成すると、JDeveloperでは、その宣言的設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリに保存されます。たとえば、summit.modelパッケージのSummit ADFサンプル・アプリケーションのBackOfficeAppModuleという名前のアプリケーション・モジュールでは、プロジェクトのソース・パスに./summit/model/BackOfficeAppModule.xmlというXMLファイルがあります。このXMLファイルには、ビュー・オブジェクト・インスタンスをアプリケーション・モジュールのデータ・モデルで再作成するために実行時に必要な情報が含まれています。

この内容を確認するには、「アプリケーション」ウィンドウでアプリケーション・モジュールのノードをダブルクリックして概要エディタを開き、アプリケーション・モジュールのXMLファイルを確認します。エディタ・ウィンドウで「ソース」タブをクリックすると、XMLファイルが表示され、その内容を確認できます。「構造」ウィンドウには、XMLファイルの構造が表示されます。

ビジネス・コンポーネントを作成すると、JDeveloperがアプリケーション・モジュールのすべての機能を含むデータ・コントロールを自動的に作成します。データ・コントロールはADFモデル抽象レイヤーで、属性、メソッド、関連する型の情報を含む補足メタデータを提供して、アプリケーション・モジュールの操作とデータ・コレクション(ビュー・オブジェクト・インスタンスの行セット)を記述します。開発者は、JDeveloperの「データ・コントロール」パネルに表示されたデータ・コントロールの表現を使用して、アプリケーション・モジュールに自動的にバインドされるUIコンポーネントを作成できます。実行時にADFモデル・レイヤーによって、適切なXMLファイルからデータ・コントロールおよびバインディングを記述したメタデータが読み取られ、ユーザー・インタフェースとビジネス・サービスの双方向の結合が実装されます。

たとえば、BackOfficeAppModuleアプリケーション・モジュールによりSummitADFアプリケーション・ワークスペースのビジネス・サービス・レイヤーが実装されます。このデータ・モデルには、複数のマスター/ディテール階層など、多数のビュー・オブジェクト・インスタンスが含まれています。コアSummit ADFサンプル・アプリケーションのビュー・レイヤーはJSFページで構成され、このページのUIコンポーネントは、BackOfficeAppModuleのデータ・モデル内のビュー・オブジェクト・インスタンスのデータと、そのクライアント・インタフェース上の組込み操作およびサービス・メソッドにバインドされています。「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュールの公開方法の詳細は、「ADFデータ・コントロールを使用したアプリケーション・モジュールの公開」を参照してください。

アプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加方法

「アプリケーション・モジュールの作成」ウィザードでアプリケーション・モジュールを作成しながらビュー・オブジェクト・インスタンスをアプリケーション・モジュールに追加することも、作成済のアプリケーション・モジュールに後で追加することもできます。

アプリケーション・モジュールの作成ウィザードの使用方法の詳細は、「アプリケーション・モジュールの作成方法」を参照してください。

既存のアプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加

作成済のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加できます。ビュー・オブジェクト・インスタンスを既存のアプリケーション・モジュールへ追加したり、オプションでビュー・オブジェクト・インスタンスをカスタマイズするには、アプリケーション・モジュールの概要エディタにある「データ・モデル」ページを使用します。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

既存のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加するには:

1. 「アプリケーション」ウィンドウで、新しいビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
3. 「データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「使用可能なビュー・オブジェクト」リストで、追加するビュー・オブジェクトを選択します。

   リストの下の「新規ビュー・インスタンス」フィールドに、データ・モデルに追加するビュー・オブジェクトの次のインスタンスを識別する際に使用される名前が示されます。

4. 目的のビュー・オブジェクトを選択し、「データ・モデル」リストに移動します。

   たとえば、図13-2に、データ・モデルに移動されてCountryVO1と表示されているSummitADFワークスペースのCountryVOビュー・オブジェクトを示します。

   図13-2 データ・モデルへのビュー・インスタンスの追加

   
5. 新規に作成したビュー・インスタンスの名前を変更するには、「新規ビュー・インスタンス」フィールドに別の名前を入力します。

   たとえば、図13-3に示すように、ビュー・インスタンス名CountryVO1をCountriesに変更できます。

   図13-3 名前変更されたビュー・インスタンスを表示している概要エディタ

   

既存のアプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加

アプリケーション・モジュールの概要エディタに表示されるデータ・モデルを使用すると、プロジェクトで定義されている既存のビュー・リンクに基づいて、ビュー・インスタンスの階層を作成できます。複数のマスター/ディテールの階層レベルで構成されるビュー・リンクを定義している場合は、アプリケーションでサポートされているレベル数までマスター/ディテールのビュー・インスタンスを作成できます。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「マスター/ディテール階層における複数表の使用」の説明に従って、ビュー・オブジェクト間の階層関係を作成します。

マスター/ディテールのビュー・オブジェクト・インスタンスをデータ・モデルに追加するには:

1. 「アプリケーション」ウィンドウで、新しいマスター/ディテール・ビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
3. 「データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを開き、「使用可能なビュー・オブジェクト」リストで、積極的に調整を行うマスターにするビュー・オブジェクトのインスタンスを選択します。

   リスト内のマスター・ビュー・オブジェクトには、このビュー・オブジェクトにビュー・リンクがあることを示すプラス記号が表示されます。ビュー・リンクは、マスター/ディテール階層の定義に必要です。

   たとえば、Summit ADFサンプル・アプリケーションのSummitADFワークスペースには、ビュー・リンクOrdCustomerIdFkLinkによって関連付けられたマスター・ビュー・オブジェクトCustomerVOとディテール・ビュー・オブジェクトOrdVOが含まれます。「使用可能なビュー・オブジェクト」リストのマスター/ディテール階層を表示するには、図13-4に示すようにCountryVOを展開します。

   図13-4 選択したマスター・ビュー・オブジェクト

   
4. 選択したマスター・ビュー・オブジェクトを「データ・モデル」リストに移動します。

   たとえば、図13-5に示すように、マスター・ビュー・オブジェクトCustomerVOをデータ・モデルに移動し、そこでビュー・インスタンス名がCustomerVO1になる場合があります。

   図13-5 作成したマスター・ビュー・インスタンス

   
5. 新規に作成したマスター・ビュー・インスタンスの名前を変更するには、「ビュー・インスタンス」フィールドに別の名前を入力します。

   たとえば、図13-6に示すように、ビュー・インスタンス名CustomerVO1をCustomersに変更できます。

   図13-6 名前変更されたビュー・インスタンスを表示している概要エディタ

   
6. 「データ・モデル」リストで、新規作成したマスター・ビュー・インスタンスを選択してハイライトしておきます。これは、追加するディテール・ビュー・インスタンスのターゲットになります。次に、「使用可能なビュー・オブジェクト」リストで、マスター・ビュー・オブジェクトの下のディテール・ビュー・オブジェクトを特定して選択します。

   たとえば、図13-7は、マスターCustomerVOの下にある、OrdVO via OrdCustomerIdFkLinkという名前のディテールOrdVOを示しています。この名前はビュー・リンクOrdCustomerIdFkLinkを表し、CustomerVOとOrdVO間のマスター/ディテール階層を定義します。データ・モデルに追加すると、OrdVOにはビュー・インスタンス名OrdersForCustomersが追加されることにも注意してください。

   図13-7 選択したディテール・ビュー・オブジェクト

   
7. 前に追加したマスター・インスタンスにディテール・インスタンスを追加するには、「データ・モデル」リストで選択したマスター・ビュー・インスタンスの下にディテール・ビュー・オブジェクトを移動し、ビュー・インスタンスの名前を変更します。

   たとえば、図13-8に示すように、OrdVO via OrdCustomerIdFkLinkを選択したマスター・ビュー・インスタンスCustomersの下のデータ・モデルに移動します。

   図13-8 作成されて名前変更されたディテール・ビュー・インスタンス

   
8. 別の階層レベルを追加するには、ステップ3から6を繰り返しますが、この場合は、新しく追加したディテール・インスタンスを「データ・モデル」リストで選択してから、新しいディテール・インスタンスを移動します。このディテール・インスタンスは、前に追加したディテール・インスタンスとマスター/ディテール関係を持ちます。

   たとえば、SummitADFワークスペースには、OrdVOビュー・オブジェクト(マスター・ビュー・オブジェクトCustomerVOのディテール)のディテールであるビュー・オブジェクトItemVO via ItemOrdIdFkLinkが含まれます。

   マスター/ディテール/ディテール・データ・モデル階層を作成するには、図13-9に示すように、ディテール・ビュー・オブジェクトItemVO via ItemOrdIdFkLinkをビュー・インスタンスOrdersForCustomers (旧名はOrdVO1)の下のデータ・モデルに移動し、新しいディテール・ビュー・インスタンスItemsForOrderの名前を変更します。「データ・モデル」リストでは、ビュー・インスタンスCustomers (旧名はCustomerVO1)は、ItemsForOrder (旧名はItemVO1)のマスターであるOrdersForCustomer (旧名はOrdVO1)のマスターです。

   図13-9 作成したマスター/ディテール/ディテール階層

   

アプリケーション・モジュールに追加するビュー・オブジェクト・インスタンスのカスタマイズ

アプリケーション・モジュールの概要エディタにある、「データ・モデル・コンポーネント」ページでビュー・オブジェクト・インスタンスのカスタマイズを任意に行えます。たとえば、次のようにマスター/ディテール・ビュー・オブジェクトの関係をコントロールする属性を設定できます。

たとえば、Summit ADFサンプル・アプリケーションのSummitADFワークスペースでは、ビュー・インスタンスSalesPeopleがBackOfficeAppModuleアプリケーション・モジュールに対して定義されており、販売スタッフを肩書きでフィルタするビュー基準FilterByTitleIdVCがこのビュー・インスタンスに対して定義されています。図13-10は、「ビュー・インスタンスの編集」ダイアログでFilterByTitleIdVCを選択し、SalesPeopleビュー・インスタンスを開いた状態を示しています。バインド変数TitleIdBindはデフォルト値の2を定義し、これによりSalesPeopleビュー・インスタンスの制御属性としてTitleId属性の値が設定されます。ビュー基準フィルタによって設定した制御属性により、一致するIDのビュー行のみを取得できます。

図13-10 ビュー基準フィルタを使用してカスタマイズしたビュー・オブジェクト・インスタンス

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

既存のアプリケーション・モジュールへ追加するビュー・オブジェクト・インスタンスをカスタマイズするには:

1. 「アプリケーション」ウィンドウで、既存のビュー・インスタンスをカスタマイズするアプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
3. 「データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「データ・モデル」リストで、カスタマイズするビュー・オブジェクト・インスタンスを選択し、「編集」ボタンをクリックします。
4. 「ビュー・インスタンスの編集」ダイアログで、次のいずれかのステップを実行し、「OK」をクリックします。

   • 「ビュー基準」グループ・ボックスで、ビュー・オブジェクト・インスタンスに適用する1つ以上のビュー基準を選択します。選択されたビュー基準は、WHERE句としてインスタンス問合せに追加されます。ビュー基準の定義の詳細は、「名前付きビュー基準の処理」を参照してください。

   • 「ビュー基準」グループ・ボックスで、「選択済」リストに追加するビュー基準ごとに、ビュー・インスタンスの必須フィルタとして1つ以上のビュー基準を選択します。現在選択されているビュー基準を常にビュー・インスタンスに適用する必要がある場合は、そのビュー基準の「必須」チェック・ボックスを選択します。通常、複数のビュー基準が1つのビュー・インスタンスに適用される場合、1つがデフォルトのビュー基準となり常に適用されます。必須ビュー基準は、アプリケーションがプログラムによってビュー基準を適用する(たとえばapplyViewCriteria()を使用)場合でも、引き続きビュー基準リストに適用されます。

   • 「バインド・パラメータ値」グループ・ボックスで、定義済のビュー基準を適用する際にインスタンスで使用する値を入力します。バインド変数の定義の詳細は、「バインド変数の使用」を参照してください。

アプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加時の処理

ビュー・オブジェクト・コンポーネントのインスタンスを追加して、アプリケーション・モジュールのデータ・モデルを定義します。図13-11に、Summitサンプル・アプリケーションのSummitADFワークスペースに表示されるBackOfficeAppModuleアプリケーション・モジュールのJDeveloperビジネス・コンポーネント・ダイアグラムを示します。

図13-11 ビュー・オブジェクト・コンポーネントの2つのインスタンスを含むアプリケーション・モジュール

「図13-11 ビュー・オブジェクト・コンポーネントの2つのインスタンスを含むアプリケーション・モジュール」の説明

例に示したアプリケーション・モジュールにはCustomerVOビュー・オブジェクト・コンポーネントの2つのインスタンスが含まれています。 メンバー名のCustomerと、それを区別するAnotherCustomerです。実行時には両方のインスタンスが同一のCustomerVOビュー・オブジェクト・コンポーネント定義を共有します。これにより、同じ属性構造とビュー・オブジェクト動作を持つようになります。ただし、それぞれを個別に使用して異なるユーザーのデータを取得できます。たとえばWHERE句やバインド変数の追加フィルタなど、一部の実行プロパティは2つのインスタンスで異なっている場合があります。

次の例は、BackOfficeAppModuleアプリケーション・モジュールにより、アプリケーション・モジュールのメンバー・ビュー・オブジェクト・インスタンスがそのXMLドキュメント・ファイルで定義される様子を示しています。

<AppModule
   Name="BackOfficeAppModule"
   ...>
   <ViewUsage
      Name="Customer"
      ViewObjectName="oracle.summit.model.appmodule.CustomerVO"/>
   <ViewUsage
      Name="AnotherCustomer"
      ViewObjectName="oracle.summit.model.appmodule.CustomerVO"/>
</AppModule>

既存のアプリケーション・モジュールの編集方法

新しいアプリケーション・モジュールを作成した後、「アプリケーション・モジュールの編集」ダイアログを使用してその設定を編集できます。エディタを起動するには、「アプリケーション」ウィンドウでアプリケーション・モジュール・ノードを右クリックして「開く」を選択するか、アプリケーション・モジュールをダブルクリックします。エディタの様々なページを開き、データ・モデル、ネストされたアプリケーション・モジュールの参照、Java生成の設定、クライアント・インタフェース・メソッド、実行時インスタンス化動作、およびカスタム・プロパティを調整できます。

アプリケーション・モジュール名を編集する場合、Oracle Application Development Framework (Oracle ADF)が定義している予約語以外の名前を選択してください。特に、アプリケーション・モジュールの名前に基づいてJDeveloperによって自動的に割り当てられるデータ・コントロールの使用名では、予約語は無効になります。Fusion Webアプリケーションでは、これらの予約語はdata、bindings、securityおよびadfContextで構成されます。たとえば、アプリケーション・モジュールの名前にはdataを使用しないでください。予約語と競合するIDのデータ・コントロールの使用名が作成されると、実行時にアプリケーションからデータ・コントロール・オブジェクトにアクセスできなくなる場合があり、ランタイムClassCastExceptionのエラーが発生することがあります。

予約語はアンダースコア(_)文字で始まる場合が多いため、名前が競合しないように、アプリケーション・モジュール名の先頭にはアンダースコアを使用しないでください。

アプリケーション・モジュール名に予約語が含まれる場合や、予約語の大文字と小文字を変更した名前が使用されている場合は、競合は発生しません。たとえば、Product_Data、Product_dataまたはDataは、全体の名前が予約語のdataとは一致しないため、すべて有効なアプリケーション・モジュール名です。

ページ作成を開始する前のデータ・コントロール名の変更方法

デフォルトでは、アプリケーション・モジュールは、「データ・コントロール」パネルにAppModuleNameDataControlという名前のアプリケーション・モジュール・データ・コントロールとして表示されます。ユーザー・インタフェース・デザイナでは、「データ・コントロール」パネルを使用して、アプリケーション・モジュールからアプリケーションのWebページにデータをバインドします。たとえば、アプリケーション・モジュールの名前がSummitAppModuleの場合、「データ・コントロール」パネルには、SummitAppModuleDataControlという名前のデータ・コントロールが表示されます。デフォルトのデータ・コントロール名を変更して、名前を短くしたり適切な名前を指定することもできます。

ユーザー・インタフェース・デザイナでデータ・コントロールを操作すると、アプリケーション・モジュールのデータ・コントロール名は、ユーザー・インタフェース・プロジェクトのDataBindings.cpxファイルおよび各データ・バインディング・ページ定義のXMLファイルに表示されます。また、アプリケーション・モジュールのサービス・インタフェースをプログラム的に操作する必要がある場合は、データ・コントロール名をコード内で参照できます。このため、アプリケーション・モジュールの名前を変更する場合は、ビュー・レイヤーを作成する前に変更する必要があります。

アプリケーション・モジュールのデータ・コントロールの詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

ノート:

1つ以上のページですでに参照した後にアプリケーション・モジュールのデータ・コントロール名を変更する場合は、データ・コントロール名が参照されているページ定義ファイルとDataBindings.cpxファイルを開き、古い名前を新しい名前に手動で更新する必要があります。

アプリケーション・モジュールのデータ・コントロール名を変更するには:

1. 「アプリケーション」ウィンドウで、データ・コントロール名を編集するアプリケーション・モジュールをダブルクリックします。
2. 「プロパティ」ウィンドウで、「その他」セクションを開き、「データ・コントロール名」フィールドに適したデータ・コントロール名を入力します。

アプリケーション・モジュールの粒度に関する必知事項

アプリケーション・モジュールに関する一般的な疑問は、「アプリケーション・モジュールがどの位の大きさになるのか」というものです。つまり、「大規模なアプリケーション・モジュールを1つ作成してエンタープライズ・アプリケーションのデータ・モデル全体を含めるか、より小規模なアプリケーション・モジュールを多数作成して機能に応じてアプリケーションを区分化するか」という問題です。答えは状況によって異なります。

一般に、アプリケーション・モジュールのサイズは、そのモジュールでの対応が想定される特定のユースケースを十分にサポートできる大きさにする必要があります。「ネストされたアプリケーション・モジュールの定義」で説明するネスト機能を使用すると、粒度の細かい複数のアプリケーション・モジュール・コンポーネントからのアセンブルが可能になります。複雑なビジネス・アプリケーションのユースケースは通常は1つではないため、Oracle ADFで実装される複雑なビジネス・アプリケーションは一般に単一アプリケーション・モジュールになりません。

実際のプラクティスでは、必要なモジュール化タイプをサポートするための粒度を選択する場合があります。たとえば、個別のデータ・ソースをサポートする必要や個別のチューニング・オプションを構成する必要がある場合は、どちらも複数のアプリケーション・モジュールを作成する方が適しています。または、主要なユースケースが1つ、バックエンドでサポートしているユースケースが1つの小規模アプリケーションの場合、アプリケーション・モジュールを2つ作成できます。ただし、簡潔にするため、数個のビュー・オブジェクトのみを含んだ2つ目のアプリケーション・モジュールを作成するのではなく、両方のユースケースを組み合せることもできます。

その他の状況では、2つ以上のルート・アプリケーション・モジュールの作成を指定することがあります。たとえば、ユーザー・セッションごとに2つ以上のトランザクションをサポートする必要がある場合は、複数のアプリケーション・モジュールを作成できます。または、「タスク・フローのトランザクションの管理」に説明されているとおり、データ・コントロール・スコープとタスク・フローを操作してトランザクションを管理できます。

ビュー・オブジェクト・コンポーネントとビュー・オブジェクト・インスタンスに関する必知事項

アプリケーション・モジュールの設計時に、ビュー・オブジェクト・コンポーネントのインスタンスを使用してそのデータ・モデルを定義します。ユーザー・インタフェースに含まれるButtonコンポーネントの2つのインスタンスに、区別するためのmyButtonおよびanotherButtonというメンバー名が付けられているように、アプリケーション・モジュールにも、CustomerVOビュー・オブジェクト・コンポーネントの2つのインスタンスに、区別するためのCustomerListおよびAnotherCustomerListというメンバー名が付けられています。

アプリケーション・モジュールのデータベース接続の構成

JDeveloperでは、すべてのアプリケーション・モジュールに対してデフォルトのランタイムJDBCデータソース接続を使用しなくても、各ADFアプリケーション・モジュールのJDBCデータソース定義を変更できます。

データ・モデル・プロジェクトを初期化してADFビジネス・コンポーネントを使用する場合、データベース接続の詳細を指定するように求められます。ADFビジネス・コンポーネント・ウィザードを実行し、データベースの表やビューを操作してビジネス・コンポーネントを作成する前に、データベース接続を指定する必要があります。接続の詳細を指定すると、JDeveloperにより、現在のプロジェクトで作成されたすべてのアプリケーション・モジュールのデフォルトのランタイム接続として使用されるJava Database Connectivity (JDBC)データソースも作成されます。

アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタを使用して、各アプリケーション・モジュールのJDBCデータ・ソース定義を個々に変更できます。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。データ・ソースを使用しない場合は、概要エディタを使用して、個別のアプリケーション・モジュールの接続タイプをJDBC URL接続タイプに変更することもできます。

JDBCデータソースまたはJDBC URL接続タイプを使用すると、Javaの実行が可能なコンテキストであればどこでもアプリケーション・モジュールを実行できます。つまり、Java Enterprise Edition (Java EE)アプリケーション・サーバー内での実行に限定されません。たとえば、Oracle ADFモデル・テスターは、スタンドアロンのJavaツールで、Java EEアプリケーション・サーバーのコンテキストでは実行できませんが、このどちらかの接続タイプを使用すれば、Oracle ADFモデル・テスターでビジネス・モデルをテストできます。アプリケーション・モジュール構成の概要エディタを使用して、「データベース」ウィンドウに表示される既存のアプリケーション・リソース接続に対して、2つの中から接続タイプを選択できます。

アプリケーション・モジュールは、デフォルトでデータソース接続タイプを使用するように構成されます。JDBCデータソースは、データベース・サーバー接続をベンダーに依存しない形式でカプセル化したものです。JDBCデータソースは、JDBC URL接続タイプでは得られない利点を提供します。データソースに基づき接続タイプを定義すると、デプロイされたアプリケーションを変更することなく、データソースの再構成が行えます。データソースはアプリケーション・サーバー・レベルで一元定義できますが、JDBC URL接続ではそれが行えません。JDBCデータソースを使用できない場合は、ADFビジネス・コンポーネントにより、データソース接続情報に基づいて実行時にデフォルトのJDBC URLが構成されます。

JDBCデータソース接続タイプの使用方法

すべてのデフォルト・アプリケーション・モジュール構成で使用される接続タイプは、JDBCデータソースです。JDBCデータソースをアプリケーション・サーバー構成情報の一部として定義すると、アプリケーション・モジュールが実行時に論理名を使用してリソースを検索します。接続タイプとしてJDBCデータソースを使用すると、アプリケーション・リソース接続の詳細が変更される場合がありますが、デプロイされているアプリケーション・モジュール構成を変更する必要はありません。JDBCデータソースがすべてのアプリケーション・モジュール構成の選択肢としてお薦されているのは、このような理由によります。図13-12に、アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタに表示されたデフォルトの選択肢を示します。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。

図13-12 JDBCデータソース接続タイプの設定

「図13-12 JDBCデータソース接続タイプの設定」の説明

ノート:

「接続タイプ」ドロップダウンに表示される、もう一方の接続タイプはJDBC URL接続です。この接続タイプは、レガシー・アプリケーション用にサポートされています。これは、JDBCデータ・ソ－ス接続タイプのかわりに使用しないでください。

次の例は、Fusion Webアプリケーションのweb.xmlファイルの<resource-ref>タグを示しています。これらは、jdbc/Summit_adfDSおよびjdbc/Summit_adfCoreDSという名前の2つの論理データソースを定義しています。アプリケーション・モジュール構成の概要エディタは、「データソース名」フィールドの接頭辞java:comp/envの後ろにあるこの論理接続名を参照します。たとえば、同じFusion WebアプリケーションのJDBCデータ・ソース名は選択可能な値java:comp/env/jdbc/summit_adfDSを表示します。このように、「データソース名」フィールドには、使用可能なすべてのアプリケーション・リソース接続名のJNDI名が事前に取り込まれます。

  <!-- In web.xml -->
  <resource-ref>
    <res-ref-name>jdbc/summit_adfDS</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>
  <resource-ref>
    <res-ref-name>jdbc/summit_adfCoreDS</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>

ターゲットのスタンドアロン・アプリケーション・サーバー上でアプリケーションを実行するために必要なグローバル・データ・ソースの接続名を指定する場合は、「データソース名」フィールドを直接編集できます。Oracle WebLogic Serverのデプロイ時、デフォルトでは、アプリケーション固有のデータ・ソースにアプリケーションはパッケージされておらず、Oracle WebLogic Serverはjava:comp/env/jdbc/applicationConnectNameDSの検索によって、jdbc/applicationConnectNameDSという名前のグローバル・データ・ソースの検索を行うように設定されています。したがって、この命名規則に従うことで、アプリケーション固有のデータ・ソースを使用してアプリケーションをJDeveloperで実行する場合や、グローバル・データ・ソースを使用してデプロイ済のスタンドアロン・サーバー上で実行する場合に、単一のデータ・ソース接続名を正しく機能させることができます。

ノート:

冗長なデータベースやバックエンドとしてのOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、アプリケーションはマルチ・データ・ソースを使用します。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースと非マルチ・データ・ソースで命名規則は同じになります。これによって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するマルチ・データ・ソースの構成の詳細は、『高可用性ガイド』のマルチ・データ・ソースに関する項を参照してください。

アプリケーション・モジュール・データベース接続作成時の処理

「構成の編集」ダイアログで接続タイプを選択すると、JDeveloperにより、アプリケーション・モジュールのXMLドキュメントに関連する./commonサブディレクトリにあるアプリケーション・モジュール構成ファイル、bc4j.xcfgが更新されます。このファイルは、1つのJavaパッケージ内の全アプリケーション・モジュールの構成を定義しています。bc4j.xcfgファイルは「アプリケーション」ウィンドウには表示されません。JDeveloperでbc4j.xcfgファイルを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックし、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。

たとえば、コアSummit ADFサンプル・アプリケーションのModelプロジェクトの./classes/oracle/summit/model/services/commonディレクトリにあるSummitAppModuleアプリケーション・モジュールでアプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタを開くと、そのアプリケーション・モジュール用に名前の付いた構成があることがわかります。

bc4j.xcfgファイルで定義された構成により、Fusion Webアプリケーションはデプロイ済の特定のアプリケーション・モジュールとの対話が可能になります。bc4j.xcfgファイルには、アプリケーション・モジュールの接続タイプに加えて、アプリケーション・モジュール名に関するメタデータ情報と、アプリケーション・モジュールに構成されたランタイム・パラメータが含まれています。名前付き接続タイプのアプリケーション・リソース・データベース接続の詳細は、「アプリケーション」ウィンドウの「接続」ノードに定義され、アプリケーションのconnection.xmlファイルに格納されています。

次の例は、コアSummit ADFサンプル・アプリケーションのbc4j.xcfgファイル例を示しています。SummitAppModuleLocalおよびSummitAppModuleの構成は、どちらもJDBCDataSource属性内のデータソース(名前はSummit_adfDS)を参照します。各構成のJDBCDataSource属性には、アプリケーション・リソース接続名のJNDI名を、java:comp/env/jdbc/applicationConnectNameDSの形式で指定します。ここで、applicationConnectNameは、JDeveloperで定義されたアプリケーション・リソース・データベース接続名(この場合はSummit_adf)です。このJNDI命名規則(アプリケーション固有ネームスペースjava:comp/env/jdbc/およびDSをアプリケーション・リソース・データベース接続名に付加したもの)により、デプロイされたFusion Webアプリケーションは、変更を加えなくてもアプリケーションのグローバル・データソースを使用してOracle WebLogic Server上で実行されます。グローバル・データ・ソースは通常、アプリケーション・サーバー管理者がOracle WebLogic Server管理コンソールを使用して定義します。

<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
   <AppModuleConfigBag ApplicationName="oracle.summit.model.services.SummitAppModule">
      <AppModuleConfig name="SummitAppModuleLocal"
                       DeployPlatform="LOCAL"
                       JDBCName="summit_adf"
                       jbo.project="oracle.summit.model.Model"
                       java.naming.factory.initial="oracle.jbo.common.JboInitialContextFactory"
                       ApplicationName="oracle.summit.model.services.SummitAppModule">
         <Database jbo.TypeMapEntries="Java"/>
         <Security AppModuleJndiName="oracle.summit.model.services.SummitAppModule"/>
         <Custom ns0:JDBCDataSource="java:comp/env/jdbc/summit_adfDS"
                                     xmlns:ns0="http://xmlns.oracle.com/bc4j/configuration"/>
      </AppModuleConfig>
      ...
   </AppModuleConfigBag>
</BC4JConfig>

アプリケーション・モジュールのランタイム構成の変更方法

アプリケーション・モジュールのXML定義の作成に加え、JDeveloperでは、アプリケーション・モジュールのXML定義ファイルを含むディレクトリを相対位置とするcommonという名前のサブディレクトリにあるbc4j.xcfgファイルにappModuleNameLocalという名前のデフォルトの構成も追加します。bc4j.xcfgファイルは「アプリケーション」ウィンドウには表示されません。JDeveloperでbc4j.xcfgファイルを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックし、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。デフォルト設定を表示したり、アプリケーション・モジュールのランタイム構成の設定を変更するには、概要エディタで「データベースとスケーラビリティ」タブを選択し、必要な変更を加えます。

始める前に:

アプリケーション・モジュール・データベース接続に関する知識があると役立つ場合があります。詳細は、「アプリケーション・モジュールのデータベース接続の構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

アプリケーション・モジュールの構成を管理するには:

1. 「アプリケーション」ウィンドウで、構成を編集するアプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「構成」ナビゲーション・タブをクリックします。
3. 「構成」ページで、編集する構成ハイパーリンクをクリックします。

   「構成」ページには次の3つのデフォルト構成が表示される可能性があります。

   • appModuleNameLocal: アプリケーション・モジュールを作成すると、自動的にローカル構成が1つ定義されます。テスト目的でアプリケーション・モジュールのランタイム・プロパティを変更する場合などは、新しいローカル構成を作成してください。

   • appModuleNameShared: 共有アプリケーション・モジュール構成が存在するのは、データ・モデル・プロジェクトの「プロジェクト・プロパティ」ダイアログで共有アプリケーション・モジュールの名前付きインスタンスが定義されている場合のみです。共有アプリケーション・モジュールは、アプリケーション全体で静的データのリストを再利用する場合に、ビュー・インスタンスをグループ化したアプリケーション・モジュールです。たとえば、共有アプリケーション・モジュールを定義して、国リストなどの参照データにアクセスするビュー・インスタンスをグループ化できます。

   • appModuleNameService (サービス・インタフェースのタイプSI): サービス・インタフェース構成が存在するのは、アプリケーション・モジュールの概要エディタの「サービス・インタフェース」ページでサービス・インタフェース(Webサービス実装ラッパー)が定義されている場合のみです。Webサービスとして公開されているアプリケーション・モジュールでは、アプリケーション・モジュールをコンポジット・アプリケーションに組み込んで、Webサービス・クライアントからデータ・アクセスやメソッド呼出しができます。同じアプリケーション・モジュールで、ADFデータ・コントロールおよびWebサービス・クライアントを使用する対話型のWebユーザー・インタフェースをサポートできます。

4. アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタで、「データベースとスケーラビリティ」タブをクリックして、目的のランタイム・プロパティをカスタマイズし変更を保存します。

プロジェクトのデータベース接続の変更方法

アプリケーションの開発時、多数の異なるユーザーやスキーマを切り替える場合があります。これには、そのビジネス・コンポーネントを含むプロジェクトのデータベース接続プロパティを変更します。選択を行うと、プロジェクトのbc4j.xcfgファイルで、JDBC URLタイプ接続を指定する各構成の接続文字列が自動的に更新されます。

始める前に:

アプリケーション・モジュール・データベース接続に関する知識があると役立つ場合があります。詳細は、「アプリケーション・モジュールのデータベース接続の構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

アプリケーション・モジュールの構成で使用する接続を変更するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールが含まれているプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。
2. 「プロジェクト・プロパティ」ダイアログで、「接続」ドロップダウン・リストから「ADFビジネス・コンポーネント」を選択し、目的の接続を選択して「編集」アイコンをクリックします。
3. 「データベース接続の編集」ダイアログで、必要な変更を行います。
4. 「OK」をクリックします。

ネストされたアプリケーション・モジュールの定義

JDeveloperでは、アプリケーション・モジュールのネストによって複合ADFアプリケーション・モジュールを作成できます。これにより、上位アプリケーション・モジュールで内部アプリケーション・モジュールの機能を使用できます。

アプリケーション・モジュールでは、高レベルな機能により複数のビジネス・ワークフローに共通なサブ機能が再使用される、ユースケースのモジュール性を模倣するソフトウェア・コンポーネントを作成する機能をサポートしています。このモジュール性は、他のアプリケーション・モジュールのインスタンスを使用してアセンブルする複合アプリケーション・モジュールを定義することで実装できます。このタスクはアプリケーション・モジュールのネストと呼ばれています。つまり、アプリケーション・モジュールにはビュー・オブジェクト・インスタンスだけでなく、1つ以上の他のアプリケーション・モジュール・インスタンスを(論理的に)含めることができます。最も外側に含まれているアプリケーション・モジュールは、ルート・アプリケーション・モジュールと呼ばれています。

ネストされたアプリケーション・モジュール定義の宣言的サポートは、図13-14に示すように、アプリケーション・モジュールの概要エディタから使用できます。アプリケーション・モジュールのAPIでも、実行時のアプリケーション・モジュールのネストがサポートされています。

アプリケーション・モジュールのインスタンスを別のアプリケーションにネストするときは、ビュー・オブジェクト・インスタンスをそのデータ・モデルに集約するのみならず、そこで定義されているカスタム・サービス・メソッドも集約します。アプリケーション・モジュールのインスタンスを別のアプリケーション・モジュール内でネストまたは再利用するこの機能は、大規模で実用的なアプリケーション・システムを実装するための、ADFビジネス・コンポーネントの重要な設計要素です。

アプリケーション・モジュールがエンド・ユーザーのユースケースまたはワークフローを表していることを考えると、一部の共有のモジュール化ユースケースで必要なデータを提供するアプリケーション・モジュールを作成でき、より複雑なユースケースをサポートするように設計されている、より複雑な別のアプリケーション・モジュール内でそれらのアプリケーション・モジュールを再使用できます。たとえば、アプリケーション・モジュールBackOfficeAMおよびCustomerSelfServiceAMを作成した後に、この両方のサービスを新しいコンポジット・サービス・アプリケーション・モジュールの不可欠な部分として使用するアプリケーションの作成が必要になったとします。図13-13は、このコンポジット・サービスがJDeveloperのビジネス・コンポーネント・ダイアグラムでどのように表示されるかを示しています。この図に示すように、SummitAppModuleなどのアプリケーション・モジュールには、ビュー・オブジェクト・インスタンスとアプリケーション・モジュール・インスタンスを含めることができます。

図13-13 アプリケーション・モジュール・インスタンスの再使用によるコンポジット・サービスのアセンブル

「図13-13 アプリケーション・モジュール・インスタンスの再使用によるコンポジット・サービスのアセンブル」の説明

ネストされたアプリケーション・モジュールの定義方法

既存のアプリケーション・モジュールのインスタンスをネストする複合ルート・アプリケーション・モジュールを指定するには、アプリケーション・モジュールの概要エディタを使用します。(アプリケーション・モジュール・インスタンスに含まれる)ネストされたすべてのコンポーネント・インスタンスでは、それらのインスタンスを再使用するルート・アプリケーション・モジュールと同じトランザクションとエンティティ・オブジェクト・キャッシュが共有されます。

たとえば、Summit ADFサンプル・アプリケーションのSummitADFワークスペースで、ネストしたアプリケーション・モジュール・インスタンスBackOfficeAMおよびCustomerSelfServiceAMは、ルート・アプリケーション・モジュールSummitAppModuleと同じトランザクションおよびエンティティ・オブジェクト・キャッシュを共有します。

ヒント:

ネストされたアプリケーション・モジュールをアプリケーションで利用する場合は、「「データ・コントロール」パネルでのネストされたアプリケーション・モジュールの表示」を必ず参照して、これらのモジュールを含むデータ・バインディングの実行時によく発生する問題を回避してください。

始める前に:

ネストされたアプリケーション・モジュールに関する知識があると役立つ場合があります。詳細は、「ネストされたアプリケーション・モジュールの定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

ネストされたアプリケーション・モジュールを定義するには:

1. 「アプリケーション」ウィンドウで、ネストされたアプリケーション・モジュールを定義するルート・アプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
3. 「データ・モデル・コンポーネント」ページの「アプリケーション・モジュール・インスタンス」セクションを展開し、「使用可能」リストで、データ・モデルに追加するアプリケーション・モジュールを選択します。

   リストの下の「新規アプリケーション・モジュール・インスタンス」フィールドに、データ・モデルに追加するネストされたアプリケーション・モジュールを識別する際に使用される名前が示されます。

4. アプリケーション・モジュールを追加する前に名前を変更するには、「新規アプリケーション・モジュール・インスタンス」フィールドに別の名前を入力します。
5. 目的のアプリケーション・モジュールを選択し、「選択済」リストに移動します。

   たとえば、Summit ADFサンプル・アプリケーションのSummitADFワークスペースで、SummitAppModuleアプリケーション・モジュールはBackOfficeAMおよびCustomerSelfServiceAMという2つのネストしたアプリケーション・モジュール・インスタンスを定義します。図13-14に、「選択済」リストに追加されたアプリケーション・モジュール・インスタンスBackOfficeAMおよびCustomerSelfServiceAMを示します。

   図13-14 データ・モデルへのアプリケーション・モジュール・インスタンスの追加

   

ルート・アプリケーション・モジュールおよびネストされたアプリケーション・モジュールの慣用名に関する必知事項

実行時に、アプリケーションはメインの、またはルートと呼ばれている、アプリケーション・モジュールを使用します。どのアプリケーション・モジュールもルート・アプリケーション・モジュールとして使用できますが、実際には、単純なCRUDアプリケーションを作成している場合を除き、より複雑なエンド・ユーザーのユースケースに対応するアプリケーション・モジュールがルートとして使用されます。ルート・アプリケーション・モジュールに別のアプリケーション・モジュールがネストされている場合、そのモジュールはすべてルート・アプリケーション・モジュールのトランザクションに関与し、同じデータベース接続および単一のエンティティ・キャッシュ・セットを共有します。この共有は、ルート・アプリケーション・モジュールおよびそのTransactionオブジェクトによって自動的に処理されます。

また、トランザクション境界を宣言的に管理するためADFバインド・タスク・フローを使用してアプリケーションを作成する場合、Oracle ADFフレームワークにより実行時にタスク・フローで使用されるアプリケーション・モジュールが自動的にネストされます。バインド・タスク・フローとトランザクションの詳細は、「タスク・フローのトランザクションの管理」を参照してください。

ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成

他のユーザーが参照できるADFアプリケーション・モジュールUMLダイアグラムを作成できます。ダイアグラムを使用してアプリケーション・モジュールの詳細を変更します。

ビジネス・サービスのデータ・モデルを開発する際、多くの場合、UMLモデルを使用して視覚化すると便利です。JDeveloperでは、他の開発者が参照できるアプリケーション・モジュール用のダイアグラムを簡単に作成できます。

アプリケーション・モジュールの編集、表示オプションの制御、メソッド名のフィルタ処理、関連するオブジェクトやファイルの表示、アプリケーションの公開、Oracle ADFモデル・テスターの起動など、多数のタスクをダイアグラム上で直接実行できます。

アプリケーション・モジュールのダイアグラムの作成方法

アプリケーション・モジュールのダイアグラムを作成するには、「新規ギャラリ」から使用できる「ビジネス・コンポーネント・ダイアグラムの作成」ダイアログを使用します。

始める前に:

UMLモデル・ダイアグラムについて理解しておくと役立つ場合があります。詳細は、「ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

アプリケーション・モジュールのダイアグラムを作成するには:

1. 「アプリケーション」ウィンドウで、ダイアグラムを作成するデータ・モデル・プロジェクトを右クリックし、「新規」→「ビジネス・コンポーネント・ダイアグラム」を選択します。
2. 「ビジネス・コンポーネントの作成」ダイアログで、ダイアグラム名と、ダイアグラムの作成先のパッケージ名を入力します。
3. 「OK」をクリックすると、空のダイアグラムが作成され、ダイアグラマを開きます。
4. 「アプリケーション」ウィンドウで、目的のアプリケーション・モジュールを選択し、それをダイアグラム上にドロップします。
5. アプリケーション・モジュール・ダイアグラム内で、目的のダイアグラム・ノードを右クリックして「ビジュアル・プロパティ」を選択し、「ビジュアル・プロパティの編集」ダイアログで必要な変更を加えます。
6. ダイアグラム・エディタで、アプリケーション・モジュール・ダイアグラム以外の任意の場所をクリックし、ダイアグラム・エディタの「プロパティ」ウィンドウを表示して次の変更を加えます。

   • レイアウト・スタイルの設定

   • フォントの変更

   • グリッドをオフ

これらのステップの完了後、ダイアグラムは図13-15のようになります。

図13-15 アプリケーション・モジュールのUMLダイアグラムの一部

「図13-15 アプリケーション・モジュールのUMLダイアグラムの一部」の説明

アプリケーション・モジュールのダイアグラム作成時の処理

ビジネス・コンポーネント・ダイアグラムを作成すると、ダイアグラムが格納されているパッケージ名と一致するプロジェクトのモデル・パスのサブディレクトリに、ダイアグラムを示す.adfbc_diagramファイルが作成されます。

デフォルトでは、「アプリケーション」ウィンドウによってプロジェクト・コンテンツのパスの表示が統一され、ソース・パスのADFコンポーネントおよびJavaファイルがプロジェクト・モデル・パスのUMLモデル・アーティファクトと同じパッケージ・ツリーに表示されます。「アプリケーション」ウィンドウで「アプリケーション・ウィンドウのオプション」→「ディレクトリの表示」ツールバー・オプションを使用して、プロジェクト・コンテンツのユニファイド・ディレクトリ・ビューとより明確なディレクトリ・パス・ビューを切り替えられます。

ダイアグラムを使用したアプリケーション・モジュールの編集方法

ビジネス・コンポーネントのUMLダイアグラムは、アプリケーション・モジュールをダイアグラムにドロップした時点の状態を示す単なる静的な図ではありません。むしろ、UMLダイアグラムは、現在のコンポーネント定義をUMLベースでレンダリングした図であるため、常に現在の状況を示しています。UMLダイアグラムは、視覚化を可能にするのみならず、視覚的なナビゲーションおよび編集ツールでもあります。

ポップアップ・メニューから「プロパティ」を選択(またはアプリケーション・モジュールをダブルクリック)すると、任意のアプリケーション・モジュールの概要エディタを起動できます。

また、ビュー・オブジェクト・インスタンス名の変更、ビュー・オブジェクト定義を「アプリケーション」ウィンドウからデータ・モデルにドロップすることによる新しいビュー・オブジェクト・インスタンスの作成、[Del]キーを押すことによるビュー・オブジェクト・インスタンスの削除など、いくつかのアプリケーション・モジュール編集タスクもダイアグラム上で直接実行できます。

ノート:

コンポーネントをダイアグラムから削除すると、その表示のダイアグラム画面からの削除のみが行われます。コンポーネントとクラスはファイル・システムと「アプリケーション」ウィンドウ内に存続します。

ダイアグラム表示オプションの制御方法

ダイアグラムでアプリケーション・モジュールを表示後、「ビジュアル・プロパティの編集」ダイアログを使用して表示オプションを制御します。ダイアグラムのダイアログを表示するには、ダイアグラム内でアプリケーション・モジュール・ノードを右クリックし、「ビジュアル・プロパティ」を選択します。

「表示」ページで、プロパティを次のように切り替えます。

• パッケージを表示 - パッケージ名を表示

• メソッドの表示 - サービス・メソッドを表示

• ステレオタイプの表示 - オブジェクトの型を表示(「<<application module>>」など)

• 使用方法の表示 - 現在のプロジェクトの他のアプリケーション・モジュールによるすべての使用を表示

「メソッド」ページでは、ダイアグラムに求められる詳細のレベルに応じて次の設定を変更します。

• 可視性の表示(「public」、「private」など)

• メソッドの戻りタイプの表示

• staticメソッドの表示

図13-16の「ビジュアル・プロパティの編集」ダイアログの設定に示すように、デフォルトでは、アプリケーション・モジュールのすべての操作が表示されます。

図13-16 デフォルトのダイアグラム・エディタのオプションを示す「ビジュアル・プロパティの編集」ダイアログ

「図13-16 デフォルトのダイアグラム・エディタのオプションを示す「ビジュアル・プロパティの編集」ダイアログ」の説明

ダイアグラムのコンテキスト・メニューでは、「表示モード」に対して次を選択することもできます。

• 圧縮 - アイコンおよび名前のみを表示

• シンボル - サービス操作を表示

• 展開済 - 操作およびデータ・モデルを表示(デフォルト)

ダイアグラム内に表示されたメソッド名のフィルタ方法

デフォルトでは、アプリケーション・モジュールのメソッドを表示すると、ダイアグラムにすべてのメソッドが表示されます。オーバーライドされたフレームワーク・メソッドとして認識されるメソッドは、すべて「Framework」操作カテゴリに表示されます。他のメソッドは、「Business」メソッド・カテゴリに表示されます。

「ビジュアル・プロパティの編集」ダイアログの「メソッド」 ページの「対象外のメソッド・フィルタ」設定は、ダイアグラムに表示したくないメソッドを除外するために使用できる正規表現です。たとえば、「対象外のメソッド・フィルタ」を次のように設定します。

findLoggedInUser.*|retrieveOrder.*|get.*

この場合、次のアプリケーション・モジュール・メソッドをすべてフィルタ処理できます。

• findLoggedInUserByEmail

• retrieveOrderById

• 生成されたビュー・オブジェクトのgetterメソッド全般

関連するオブジェクトおよび実装ファイルのダイアグラムでの表示方法

ダイアグラム上でアプリケーション・モジュール(またはそのデータ・モデル内の任意の個別ビュー・オブジェクト・インスタンス・セット)の選択後、「表示」→「関連する要素」をコンテキスト・メニューから選択し、ダイアグラムに関連するコンポーネントを表示できます。同様に、「表示」→「実装ファイル」を選択することで、アプリケーション・モジュールを実装するファイルをダイアグラムに含むことができます。求められる詳細のレベルがダイアグラムに追加されるまで、表示されている追加ダイアグラム要素に対して前述のオプションを繰り返し使用できます。

図13-17は、アプリケーション・モジュールの実装ファイルを表示した図を示しています。アプリケーション・モジュールの実装クラスの関連要素(AppModuleImpl)が表示されています。また、アプリケーション・モジュールと実装クラス間の依存性を示す追加の線も表示されています。特定のカスタム・インタフェースにアプリケーション・モジュール・インスタンスをキャストした場合でも、図のように表示されます。

図13-17 「表示」→「関連する要素」および「表示」→「実装ファイル」によるダイアグラムへの詳細の追加

アプリケーション・モジュール・ダイアグラムの公開方法

ダイアグラムをPNG、JPG、SVGまたは圧縮されたSVG書式で公開するには、ダイアグラム上でポップアップ・メニューから「ダイアグラムの公開」を選択します。

ダイアグラムからのアプリケーション・モジュールのテスト方法

ダイアグラムのアプリケーション・モジュールに対してOracle ADFモデル・テスターを起動するには、ポップアップ・メニューから「実行」を選択します。

複数ページの作業ユニットのサポート

ADFアプリケーション・モジュール・プーリングを使用して、スケーラブルなフォールト・トレラント・アプリケーションを実装します。

Fusion Webアプリケーションとの対話中に、エンド・ユーザーには次のような状況が発生する場合があります。

• 同じページを複数回表示する場合に、迅速なレスポンスを期待

• 完了までに多数のページを表示する必要がある論理作業ユニットを実行

• 未保存の保留中の変更内容の部分的なロールバックの実行を要求

• サーバー・ファームのアプリケーション・サーバー障害による、保存前の保留中の変更への不可抗力的な被害

アプリケーション・モジュール・プーリング機能および状態管理機能では、これらの要件に対処するスケーラブルで高パフォーマンスの実装を簡略化します。

ノート:

ADFバインド・タスク・フローは、トランザクションの作業ユニットを表すことができます。タスク・フローのオプションを指定して、トランザクションの処理方法を決定できます。ADFバインド・タスク・フローの宣言的な機能の詳細は、「タスク・フローのトランザクションの管理」を参照してください。

Oracle ADFモデル・テスターでの状態管理のシミュレーション方法

実行する状態管理機能をシミュレートするために、アプリケーション・モジュールでOracle ADFモデル・テスターの2つのインスタンスを起動できます。

始める前に:

状態管理に関する知識があると役立つ場合があります。詳細は、「複数ページの作業ユニットのサポート」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

Oracle ADFモデル・テスターを使用してトランザクション状態の受動化をシミュレートするには:

1. Oracle ADFモデル・テスターを実行し、ビュー・オブジェクト・インスタンスをダブルクリックしてそのデータを問い合せます。
2. 数行のいくつかの属性の現在値をノートにとります。
3. これらの属性が別々の値を持つようにこれらの行に更新します。ただし、変更はコミットしないでください。
4. Oracle ADFモデル・テスターのメイン・メニューから、「ファイル」→「トランザクション状態の保存」を選択します。

   「受動化されたトランザクション状態」ダイアログが開き、トランザクションID番号が表示されます。この番号をノートにとります。

5. Oracle ADFモデル・テスターを完全に終了します。
6. Oracle ADFモデル・テスターを再起動し、同じビュー・オブジェクト・インスタンスをダブルクリックしてそのデータを問い合せます。
7. データは変更されない点に注意してください。データから問い合せたデータは、データベースの現在の状態を示し、前述の変更は反映されていません。
8. Oracle ADFモデル・テスターのメイン・メニューから、「ファイル」→「トランザクション状態のリストア」を選択し、ステップ4でメモしたトランザクションIDを入力します。

この時点で、保留中の変更が、変更した行に再反映されます。ここでトランザクションをコミットすると、変更内容はデータベースに永続的に保存されます。

実行時に行われる処理: アプリケーションでアプリケーション・モジュール・プーリングと状態管理が使用される場合

アプリケーション・モジュールをそのビジネス・サービスとして利用するアプリケーションを作成すると、そのアプリケーションでは自動アプリケーション・モジュール・プーリング機能を使用できます。この機能では、アプリケーションに対するエンド・ユーザーの負荷(ロード)の日中の変化に応じて増減するアプリケーション・モジュール・インスタンスの構成可能なセットを管理します。アプリケーション・ユーザー・インタフェースとのエンド・ユーザーの対話に特有の思考時間の性質により、プール内のアプリケーション・モジュール・インスタンスの数は、システムを使用しているアクティブ・ユーザーの合計数より少なくなる場合があります。

図13-18に示すように、あるエンド・ユーザーがアプリケーションの複数ページを表示して論理タスクを実行する場合、各ページ・リクエストに対し、プール内のアプリケーション・モジュール・インスタンスがその1リクエストの存続時間中にプールから自動的に取得されます。リクエストの最後に、インスタンスはプールに自動的に戻され、別のユーザー・セッションで使用可能になります。エンド・ユーザーの作業をアプリケーション・サーバーの障害から保護するために、アプリケーション・モジュールでは、そのエンティティ・キャッシュ内の保留中の変更セットを示すXMLスナップショットを保存することで、その変更セットを永続ストアに格納する機能をサポートしています。スケーラビリティ上の理由から、この状態スナップショットは通常、アプリケーション・データを含むデータベース・スキーマとは別の状態管理スキーマに保存されます。

図13-18 複数ページの論理作業ユニット全体に対するプールされたアプリケーション・モジュールの使用方法

「図13-18 複数ページの論理作業ユニット全体に対するプールされたアプリケーション・モジュールの使用方法」の説明

プーリング・アルゴリズムではチューニング可能な最適化が行え、特定数のアプリケーション・モジュール・インスタンスが、プールに戻された最後のユーザー・セッションとの「スティッキー」な状態を維持しようとします。最適化は保証されていませんが、ユーザーが最適化による利益を得ることができれば、システム・ローダーが許容する限り、プール内の同じアプリケーション・モジュール・インスタンスを継続的に使用します。負荷が重すぎる場合、プーリング・アルゴリズムはプール内で使用可能な任意のインスタンスを使用してユーザーのリクエストに応え、その論理作業単位の凍結スナップショットを永続ストアから再構築して、アプリケーション・モジュールの新しいインスタンスが前回途中になったところから継続できるようにします。エンド・ユーザーは変更をコミットまたはロールバックするまで、この方法で作業を継続します。

アプリケーション・モジュールはこれらの機能を使用し、完全にステートレスなアプリケーションに近い実行時パフォーマンスを実現するアーキテクチャにおいて、複数ページのワークフローを簡単に処理できる、生産性の高いステートフルなパラダイムを実現します。これらのアプリケーション・モジュール機能の詳細は「Fusion Webアプリケーションでの状態管理の使用」を、チューニング方法の詳細は「アプリケーション・モジュール・プールのチューニング」を参照してください。

サービス・メソッドによるアプリケーション・モジュールのカスタマイズ

ビジネス機能実装の論理的側面である外部クライアント・コードをADFアプリケーション・モジュールのカスタムJavaクラスに収容できます。

アプリケーション・モジュールでは、カスタムJavaコードを必要とせずに、そのビュー・オブジェクト・インスタンスのデータ・モデルをクライアントに公開できます。このため、クライアント・コードではoracle.jboパッケージのApplicationModule、ViewObject、RowSetおよびRowというインタフェースを使用して、データ・モデル内のビュー・オブジェクトを直接操作できます。ただし、クライアント・コードで自由にビュー・オブジェクトをプログラミングで操作できても、それが必ずしもベスト・プラクティスではありません。

ビュー・オブジェクトを操作するプログラム的なコードが完全なビジネス・サービス機能を実装するための論理的な特徴を備えている場合、アプリケーション・モジュールのJavaクラスでカスタム・メソッドを記述して、詳細をカプセル化する必要があります。これには次のコードが含まれます。

• 表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成

• 集計結果を取得するための、ビュー・オブジェクト行の反復処理

• 1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行

これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。

• コードの目的が、クライアントにより明確に伝わります。

• 必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。

• ビジネス・サービス機能全体の回帰テストを簡略化できます。

• クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。

• ページ内での論理的ビジネス機能の宣言的起動が可能になります。

アプリケーション・モジュールのカスタム・クラスの生成方法

カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、まずそのカスタムJavaクラスを有効化する必要があります。IDEレベルの「ビジネス・コンポーネント」のJava生成設定で、アプリケーション・モジュール・クラスが自動的に生成されるように構成されている場合は、カスタム・クラスが発生します。図13-19に示すように、アプリケーション・モジュールにカスタムJavaクラスがあるかどうかが不明な場合は、「アプリケーション」ウィンドウでそのアプリケーション・モジュール・ノードの概要エディタを開きます。エディタの「Javaクラス」ページに、プロジェクトのアプリケーション・モジュール用に生成されたクラスの完全リストが表示されます。他のユーザーによりすでにファイルが作成されているため存在する場合、「Javaクラス」ページには「アプリケーション・モジュール・クラス」として特定された、リンクされたファイル名が表示されます。ソース・エディタで既存ファイルを開くには、対応するファイル名のリンクをクリックします。

図13-19 概要エディタのアプリケーション・モジュールのカスタムJavaクラス

プロジェクトにJavaクラスが存在しない場合、アプリケーション・モジュールの概要エディタの「Javaクラス」ページで生成できます。

始める前に:

アプリケーション・モジュールのサービス・メソッドに関する知識があると役立つ場合があります。詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

アプリケーション・モジュール・クラスのJavaファイルを生成するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」ボタンをクリックします。
3. 「Javaオプションの選択」ダイアログで、「アプリケーション・モジュール・クラスの生成」を選択します。
4. 「OK」をクリックします。

   「Javaクラス」ページに新しい.javaファイルが表示されます。

アプリケーション・モジュールのカスタム・クラス生成時の処理

アプリケーション・モジュールのカスタム・クラスを生成すると、JDeveloperではコンポーネントのXMLドキュメント・ファイルと同じディレクトリにファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleNameImpl.javaになります。

アプリケーション・モジュールに対して選択したJava生成オプションは、アプリケーション・モジュールの概要エディタの「Javaクラス」ページに後でアクセスしてもそのまま反映されています。XML定義ファイルの場合と同様、このエディタでどのような変更を行っても、カスタムJavaクラスで生成されたコードは最新の状態に保たれます。後でカスタムJavaファイルが不要になった場合は、「Javaクラス」ページから「Javaオプションの選択」ダイアログを開き、「アプリケーション・モジュール・クラスの生成」の選択を解除すると、プロジェクトからカスタムJavaファイルが削除されます。

デフォルトのコード生成に関する必知事項

デフォルトでは、アプリケーション・モジュールのJavaクラスは、最初に有効化した際、次の例のようになります。それには、データ・モデルの各ビュー・オブジェクト・インスタンス用のgetterメソッドが含まれます。

package oracle.summit.model.services;

import oracle.jbo.server.ApplicationModuleImpl;
// ---------------------------------------------------------------------
// ---    File generated by ADF Business Components Design Time.
// ---    Custom code may be added to this class.
// ---    Warning: Do not modify method signatures of generated methods.
// ---------------------------------------------------------------------
public class AppModuleImpl extends ApplicationModuleImpl {
  /** This is the default constructor (do not remove) */
  public AppModuleImpl() { }

  /** Container's getter for YourViewObjectInstance1 */
  public YourViewObjectImpl getYourViewObjectInstance1() {
    return (YourViewObjectImpl)findViewObject("YourViewObjectInstance1");
  }

  // ... Additional ViewObjectImpl getters for each view object instance

  // ... ViewLink getters for view link instances here
}

図13-20に示すように、アプリケーション・モジュール・クラスでは、カスタム・コードを追加する前にすべてのデフォルト動作を継承するようにベースADFのApplicationModuleImplクラスを拡張します。

図13-20 カスタム・アプリケーション・モジュール・クラスによるApplicationModuleImplの拡張

「図13-20 カスタム・アプリケーション・モジュール・クラスによるApplicationModuleImplの拡張」の説明

アプリケーション・モジュールへのカスタム・サービス・メソッドの追加方法

カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、アプリケーション・モジュールのカスタム・クラスに移動して、新しいメソッドのJavaコードをアプリケーション・モジュールのJava実装クラスに入力します。次のガイドラインを使用して、メソッドに適切な可視性を判断してください。

• メソッドをこのコンポーネントの実装内でヘルパー・メソッドとしてのみ使用する場合は、メソッドをprivateにします。

• アプリケーション・モジュールの最終的なサブクラスでこのメソッドを起動またはオーバーライドできるようにする場合は、メソッドをprotectedにします。

• クライアントによる起動を可能にする場合は、publicにする必要があります。

ノート:

この章のアプリケーション・モジュールの例では強く型付けされたカスタム・エンティティ・オブジェクト・クラスを使用しています。これらのエンティティ・クラスの作成方法の詳細は、「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」を参照してください。

次の例は、AppModuleアプリケーション・モジュールのAppModuleImpl.javaクラスでのprivate retrieveOrderById()ヘルパー・メソッドを示しています。ここでは、関連するエンティティ定義にアクセスするためにOrdEOImplエンティティ・オブジェクト・クラスのstatic getDefinitionObject()メソッドが使用され、注文の検索に適したKeyオブジェクトを作成するためにエンティティ・オブジェクト・クラスでcreatePrimaryKey()メソッドが使用され、エンティティ行をエンティティ・キャッシュで検索するためにエンティティ定義でfindByPrimaryKey()メソッドが使用されています。このメソッドからは、強く型付けされたOrdersImplクラス(Ordersエンティティ・オブジェクトのカスタムJavaクラス)のインスタンスが戻されます。

// In summit.model.appmodule.service.AppModuleImpl class
/*
 * Helper method to return a Order by Id
 */
private OrdersImpl retrieveOrderById(long orderId) {
  EntityDefImpl orderDef = OrdersImpl.getDefinitionObject();
  Key orderKey = OrdersImpl.createPrimaryKey(new DBSequence(orderId));
  return (OrdersImpl)orderDef.findByPrimaryKey(getDBTransaction(), orderKey);
}

次の例は、作成する注文のIDをコール元が渡すことを可能にするpublic findOrderAndCustomer()メソッドを示しています。OrdersImplエンティティ・オブジェクト・クラスのgetCustomer()メソッドを使用して、関連するエンティティ定義にアクセスします。

/*
 * Create a new Customer and Return its new id
 */  
public String findOrderAndCustomer(long orderId) {
    OrdersImpl order = retrieveOrderById(orderId);
  if (order != null) {
        CustomerImpl cust = order.getCustomer();
    if (cust != null) {
      return "Customer: " + cust.getName() + ", Location: " + cust.getCity();
    }
    else {
      return "Unassigned";
    }
  }
  else {
    return null;
  }
}

static mainメソッドを使用したカスタム・アプリケーション・モジュールのテスト方法

カスタム・アプリケーション・モジュールのメソッドをテストする準備ができたら、JDeveloperを使用してJUnitテスト・ケースを生成できます。JUnitでは、oracle.jbo packageで使用可能な任意のプログラムのAPIを使用して、アプリケーション・モジュールの操作およびカスタム・メソッドを起動が可能です。ADFビジネス・コンポーネントでのJUnit使用の詳細は、「JUnitを使用した回帰テスト」を参照してください。

JUnitテスト・ケースの代替方法として、カスタム・アプリケーション・モジュール・メソッドをテストする一般的な方法は、簡単なテスト・ケースを作成することです。たとえば、テスト用のコードをオブジェクトに作成し、そのコードをstatic main()メソッドに含めます。次の例は、これから記述するサンプル・メソッドをテストするために、カスタム・アプリケーション・モジュール・クラスに追加できるサンプルのmain()メソッドを示しています。Configurationオブジェクトを使用して(「コマンド行Javaテスト・クライアントの作成方法」を参照)、テスト用のアプリケーション・モジュールをインスタンス化および操作します。

ノート:

Configurationオブジェクトがoracle.jbo.clientパッケージ内に存在していることは、それがアプリケーション・クライアントとしてアプリケーション・モジュールへのアクセスに使用されていることを示しています。main()メソッドは一種のプログラム的なコマンド行クライアントであるため、このような使用方法に問題はありません。また、createRootApplicationModule()の戻り値をアプリケーション・モジュールの実装クラスに直接キャストするのは一般的ではありませんが、このオブジェクトはアプリケーション・モジュールのクライアントであるとしても、main()メソッドのコードがアプリケーション・モジュールの実装クラス自体の中に格納されているため、この状況でこの操作を行うことは適切です。

次の例のコードを見ると、これまでの例で作成したメソッドを使用して次が実行されていることがわかります。

1. 注文101の合計を取得します。

2. 注文101の顧客名を取得します。

3. 101の注文ステータスを「Y」の値に設定します。

package oracle.summit.model.appmodule.service;

import oracle.jbo.ApplicationModule;
import oracle.jbo.JboException;
import oracle.jbo.client.Configuration;

public class TestAM {
    public TestAM() {
        super();
    }

    /*
     * Testing method
     */

    public static void main(String[] args) {
      String amDef = "oracle.summit.model.appmodule.service.AppModule";
      String config = "AppModuleLocal";
      ApplicationModule am =
                      Configuration.createRootApplicationModule(amDef,config);
        /* 
         * NOTE: This cast to use the AppModuleImpl class is OK since this
         *       code is inside a business tier file and not in a
         *       client class that is accessing the business tier from "outside".
         */
        AppModuleImpl service = (AppModuleImpl)am;

        String customerName = service.findOrderAndCustomer(101);
        System.out.println("Customer for Order # 101 = " + customerName);
        try {
           service.updateOrderStatus(101,"Y");
        }
        catch (JboException ex) {
           System.out.println("ERROR: "+ex.getMessage());
        }
      Configuration.releaseRootApplicationModule(am,true);
    }
}

カスタム・アプリケーション・モジュール・クラスを実行すると、前述の例のmain()メソッドがコールされ、次の出力が生成されます。

anonymous
Customer for Order # 101 = Customer: Kam's Sporting Goods, Location: Hong Kong

ノート:

カスタム・アプリケーション・モジュールに作成したカスタム・サービス・メソッドを、クライアント・アプリケーションを使用して起動する方法の詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

プログラムによる行セットの反復に関する必知事項

アプリケーション・ロジックが行セットにアクセスし、プログラムによる反復を実行する場合は必ず、ユーザー・インタフェース・コンポーネントにバインドされている可能性があるので、アプリケーション・モジュールのデータ・モデル内のビュー・オブジェクト・インスタンス、またはこれらのビュー・オブジェクト・インスタンスのビュー・リンク・アクセッサ行セットを扱う際に、セカンダリ行セット・イテレータを使用する必要があります。セカンダリ・イテレータを作成するには、作業対象の行セットに対してcreateRowSetIterator()メソッドを使用します。使用を修了したら、行セットに対してcloseRowSetIterator()メソッドを呼び出し、メモリーからセカンダリ・イテレータを削除する必要があります。次の例は、データ・モデル内のCustomerView1ビュー・オブジェクト・インスタンスが、ユーザー・インタフェースにバインドされる可能性がある(現在または後で)ため、プログラムによる反復用に、セカンダリ行セット・イテレータを正しく使用する典型的なアプリケーション・モジュールのカスタム・メソッドを示しています。

// Custom method in an application module implementation class
public void doSomeCustomProcessing() {
    ViewObject vo = getCustomerView1();
    // create secondary row set iterator with system-assigned name
    RowSetIterator iter = vo.createRowSetIterator(null);
    while (iter.hasNext()) {
        Row r = iter.next();
        // Do something with the current row.
        Integer custId = (Integer)r.getAttribute("Id");
        String name  = (String)r.getAttribute("Name");
        System.out.println(custId + " " + name);
    }
    // close secondary row set iterator
    iter.closeRowSetIterator();
}

ノート:

行セットのデフォルト行セット・イテレータを使用して独自の行セットの反復を行う、ビュー・オブジェクトの実装クラス内のカスタム・コードについても同じことがお薦めされます。

このような推奨は次の2つの重要な理由のために行っています。これを行わなかった場合、現在の行が予期せず変更された場合にエンド・ユーザーを混乱させてしまいます。また、最初または最後の行、あるいは両方の行がスキップされてしまうため、検出が難しいビジネス・ロジック・エラーが発生してしまうことがあります。

• 現在の行が突然変更されることでエンド・ユーザーが混乱

  イテレータ・バインディングは、エンド・ユーザーが行セット内でどの行を現在見ているのかを判断します。プログラムによるロジックがイテレータ・バインディングと同じデフォルト行セットイテレータを使用して行セットを反復している場合、ユーザーが現在選択している行を知らない間に変更してしまい、ユーザーを混乱させてしまうことがあります。

• 最初または最後の行を知らない間にスキップして、検出しにくいビジネス・ロジック・エラーを誘発

  イテレータ・バインディングでは、行セット・イテレータを有効な行に強制的に配置して、行セットが空の場合に、UIコンポーネントがデータを表示できるようにします。これによってカスタム・ロジックが、最初の行の前のスロット、または最後の行の後ろのスロットに移動するのを防止する効果があります(イテレータ・バインディングと同じ行セット・イテレータを使用している場合)。具体的には、典型的なwhile (iter.hasNext())行セット反復ループは、次の例に示すように、最初の行ではなく2番目の行を処理することでスキップまたは開始されます。

// Reset the default row set iterator (iter) to the slot before the first row
iter.reset();
// If an iterator binding is bound to the same default row set iterator,
// then it has already forced it to navigate to the first row here instead
// of being on the slot before the first row.
// 
// If the row set iterator has only one row, the following will then return false
while (iter.hasNext()) {
  // If the row set has more than one row, the first time through the loop
  // this call to next() will return the second row rather than the first
  // row as expected.
  Row curRow = iter.next();
  // Do something with current row
}

アプリケーション・モジュール・メッセージ文字列のカスタマイズ

ADFアプリケーション・モジュール用のリソース・バンドル・ファイルを追加できます。このリソース・バンドル・ファイル(.propertiesファイル)を使用してカスタム・メッセージ文字列を保持します。

ADFアプリケーション・モジュールには通常は専用のリソース・バンドルは必要ありません。ただし、カスタム・メッセージ文字列の追加に使用できるカスタム・メッセージ文字列ファイル(.properties)を作成できます。

作成する.propertiesファイルは、完全修飾パッケージ名とカスタム・メソッド例外メッセージによって、属性プロパティを参照できます。たとえば、メッセージ・キーと文字列を次のように定義します。

test.Order.Orderno_LABEL=Order Number
INVALID=You have called the method foo in an invalid way.

リソース・バンドルでメソッドの例外メッセージ用メッセージを定義する場合、カスタム・メソッドは「アプリケーション・モジュールのクライアント・インタフェースでのカスタム・メソッドの公開方法」で説明するように、アプリケーション・モジュール・クライアント・インタフェースに表示する必要があります。

たとえば例外メッセージINVALIDのかわりに、メソッドfoo()のメッセージを定義すると、インタフェースはリソース・バンドルからメッセージを呼び出すように、このメソッドを定義する場合があります。

public void foo() {
    ResourceBundleDef r = getResourceBundleDef();
    throw new JboException(r,"INVALID",null);
}

アプリケーション・モジュールへのリソース・バンドル・ファイルの追加方法

カスタム・メッセージ文字列を含める.propertiesファイルを作成する場合は、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページのリソース・バンドル・オプションを使用して、「1ファイル当たり1バンドル」オプションを選択します。このオプションは、デフォルトで「1プロジェクト当たり1バンドル」に設定され、プロジェクトごとに1つずつ.propertiesファイルが生成されます。

始める前に:

プロジェクトでのリソース・バンドルの使用方法を理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュール・メッセージ文字列のカスタマイズ」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「アプリケーション・モジュールの作成方法」の説明に従って、該当するアプリケーション・モジュールを作成します。

2. 「リソース・バンドルの使用」の説明に従い、データ・モデル・プロジェクトのプロジェクト・プロパティを設定してファイルごとに1つずつバンドルを生成します。

アプリケーション・モジュールのリソース・バンドルを生成するには:

1. 「アプリケーション」ウィンドウで、リソース・バンドルを生成するアプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「一般」ナビゲーション・タブをクリックし、表示名を入力します。

   アプリケーション・モジュールの表示名を追加すると、表示名のメッセージ・キーとともに.propertiesファイルが生成されます。

3. ファイルを保存します。

アプリケーション・モジュールへのリソース・バンドル追加時の処理

アプリケーション・モジュールのリソース・バンドルを生成すると、JDeveloperではコンポーネントのXMLドキュメント・ファイルと同じディレクトリに.propertiesファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleNameMsgBundle.propertiesになります。

次の例は、.propertiesファイルを参照するアプリケーション・モジュールXMLドキュメントのResourceBundle要素を示しています。

<AppModule
  ...
  <ResourceBundle>
    <PropertiesBundle
      PropertiesFile=
         "oracle.summit.model.services.common.BackOfficeAppModuleMsgBundle"/>
  </ResourceBundle>
</AppModule>

UIクライアントへのカスタム・サービス・メソッドの公開

ユーザー・インタフェースでADFアプリケーション・モジュール・クラスのpublicカスタム・メソッドを起動するには、そのメソッドをアプリケーション・モジュールのUIクライアント・インタフェースに追加します。

アプリケーション・モジュール・クラスにpublicカスタム・メソッドを追加する際に、アプリケーションのUIによるそのメソッドの起動を可能にする場合、そのメソッドをアプリケーション・モジュールのUIクライアント・インタフェースに追加する必要があります。

アプリケーション・モジュールのクライアント・インタフェースでのカスタム・メソッドの公開方法

アプリケーション・モジュールのカスタムJavaクラスのpublicメソッドをクライアント・インタフェースに追加するには、アプリケーション・モジュールの概要エディタで「Javaクラス」ページを使用します。

始める前に:

クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

クライアント・インタフェースにカスタム・メソッドを公開するには:

1. 「アプリケーション」ウィンドウで、クライアント・インタフェースを定義するアプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「Java」ナビゲーション・タブをクリックし「クライアント・インタフェース」セクションで、「アプリケーション・モジュール・クライアント・インタフェースの編集」ボタンをクリックします。
3. 「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。
4. 「OK」をクリックします。

   新しいメソッドが「Javaクラス」ページの「クライアント・インタフェース」セクションに表示されます。

図13-21は、クライアント・インタフェースに追加した複数のpublicメソッドを示しています。

図13-21 アプリケーション・モジュールのクライアント・インタフェースに追加したpublicメソッド

カスタム・サービス・メソッド公開時の処理

カスタム・サービス・メソッドをクライアント・インタフェースに公開すると、図13-22に示すように、アプリケーション・モジュールと同じ名前のJavaインタフェースが、アプリケーション・モジュールが存在するパッケージのcommonサブパッケージに作成されます。summit.modelパッケージのAppModuleという名前のアプリケーション・モジュールでは、このインタフェースはAppModuleという名前になり、summit.model.commonパッケージに作成されます。このインタフェースにより、oracle.jboパッケージのベースApplicationModuleインタフェースが拡張され、アプリケーション・モジュールがApplicationModuleImplクラスから継承するすべてのベース機能へのクライアント・アクセスが可能になります。

図13-22 カスタム・クライアント・インタフェースによるベースApplicationModuleインタフェースの拡張

「図13-22 カスタム・クライアント・インタフェースによるベースApplicationModuleインタフェースの拡張」の説明

次の例に示すように、AppModuleインタフェースには、アプリケーション・モジュールのクライアント・インタフェースに配置するように選択したすべてのメソッドのメソッド・シグネチャが含まれています。

package summit.model.appmodule.service.common;
import oracle.jbo.ApplicationModule;
// ---------------------------------------------------------------------
// ---    File generated by ADF Business Components Design Time.
// ---------------------------------------------------------------------
public interface AppModule extends ApplicationModule {
    String findOrderAndCustomer(long orderId);
    void updateOrderStatus(long orderId, String newStatus);
    String findOrderTotal (long orderId);
    long createCustomer(String name, String city, Integer countryId);
}

ノート:

新しいカスタム・メソッドをクライアント・インタフェースに追加した後で、JDeveloperのコード・インサイトによる状況依存の文補完を使用したときにこのカスタム・メソッドを使用できない場合は、生成されたクライアント・インタフェースの再コンパイルを試行してください。これを実行するには、「アプリケーション」ウィンドウでアプリケーション・モジュールを選択し、「構造」ウィンドウで同じ名前のインタフェースのソース・ファイルを選択して、ポップアップ・メニューから「再ビルド」を選択します。このヒントは、ビュー・オブジェクトにかぎらず、ビュー行に追加された新しいカスタム・メソッドでも参考にしてください。

ビュー・オブジェクトおよびビュー行のクライアント・インタフェースの生成方法

アプリケーション・モジュールのクライアント・インタフェースを生成することに加えて、カスタマイズ可能な他のキー・クライアント・オブジェクトを操作するための強く型付けされたクライアント・インタフェースも生成できます。たとえば、カスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースとビュー行クライアント・インタフェースにそれぞれ追加できます。

始める前に:

クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「単一のデータベース表からのビュー・オブジェクト行の移入」の説明に従い、目的のビュー・オブジェクトを作成します。

ビュー・オブジェクトのクライアント・インタフェースにカスタム・メソッドを公開するには:

1. 「アプリケーション」ウィンドウで、クライアント・インタフェースを定義するビュー・オブジェクトをダブルクリックします。
2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「クライアント・インタフェース」セクションで、「Javaオプションの編集」ボタンをクリックします。
3. 「Java」ダイアログで「ビュー・オブジェクト・クラスの生成」を選択して、「ビュー・オブジェクト・クラスの生成」をクリックします。「OK」をクリックします。
4. 概要エディタで、「クライアント・インタフェース」セクションを開き、「ビュー・オブジェクト・クライアント・インタフェースの編集」ボタンをクリックします。
5. 「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。
6. 概要エディタで、「カスタム行インタフェース」セクションを開き、「ビュー・オブジェクト・カスタム行インタフェースの編集」ボタンをクリックします。
7. 「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。
8. 「OK」をクリックします。

   「Javaクラス」ページに新しいメソッドが表示されます。

summit.model.viewsパッケージのCustomerViewビュー・オブジェクトに対してカスタム・ビュー・オブジェクトのJavaクラスの生成を可能にし、1つ以上のカスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースに追加すると、図13-23に示すように、CustomerViewImplクラスおよびCustomerViewインタフェースが生成されます。アプリケーション・モジュール・カスタム・インタフェースと同様に、commonサブパッケージに生成されます。

図13-23 カスタム・ビュー・オブジェクト・インタフェースによるベースViewObjectインタフェースの拡張

「図13-23 カスタム・ビュー・オブジェクト・インタフェースによるベースViewObjectインタフェースの拡張」の説明

同様に、同じビュー・オブジェクトに対してカスタム・ビュー行のJavaクラスの生成を有効にして、1つ以上のカスタム・メソッドをビュー行クライアント・インタフェースに追加すると、図13-24に示すように、CustomerViewRowImplクラスおよびCustomerViewRowインタフェースが生成されます。

図13-24 カスタム・ビュー行インタフェースによるベースRowインタフェースの拡張

「図13-24 カスタム・ビュー行インタフェースによるベースRowインタフェースの拡張」の説明

Oracle ADFモデル・テスターを使用したカスタム・サービス・メソッドのテスト方法

カスタム・アプリケーション・モジュールのメソッドは、「UIクライアントへのカスタム・サービス・メソッドの公開」で説明しているように、クライアント・インタフェースに公開した後にOracle ADFモデル・テスターでテストできます。

始める前に:

クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

公開したサービス・メソッドのテスト方法:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを右クリックし、「実行」を選択します。

   または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は、「デバッグ」を選択します。「ログ」ウィンドウおよび各種デバッガ・ウィンドウのデバッガ・プロセス・パネルが開きます。Oracle ADFモデル・テスターを使用してデバッグする場合、これらのウィンドウを使用してステータス・メッセージと例外の表示、ソース・コードのステップ・インとステップ・アウト、およびブレークポイントの管理を実行できます。

   ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを受信する方法の詳細は、「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。

2. クライアント・インタフェースによって定義されたメソッドのメソッド・テスト用パネルを開くには、次のいずれかを行います。

   • アプリケーション・モジュール・クライアント・インタフェース用に公開したメソッドを実行する場合、データ・モデル・ツリーでアプリケーション・モジュール・ノードを選択し、メイン・メニューから「表示」→「操作」を選択します。アプリケーション・モジュール・ノードをダブルクリックして、メソッド・テスト・パネルを開くこともできます。

   • ビュー・オブジェクト用のクライアント・インタフェースで公開したメソッドを実行する場合、データ・モデル・ツリーで目的のビュー・オブジェクト・ノードを選択し、メイン・メニューから「表示」→「操作」を選択します。ビュー・オブジェクト・ノードを右クリックして、「操作」を選択することもできます。

3. ビュー・オブジェクト行のクライアント行インタフェースで定義したメソッドのメソッド・テスト・パネルを開くには、データ・モデル・ツリーを展開し、該当するビュー・オブジェクト・ノードを右クリックして、「表の表示」を選択します。次にビュー・インスタンスの概要パネルで目的の行を選択し、メイン・メニューから「表示」→「操作」を選択します。

   マスター・ビュー・オブジェクトではビュー行の操作は禁止されているので、データ・モデル・ツリーでマスター・ビュー・インスタンスを選択しないでください。図13-25のように、マスター/ディテール階層が指定されていないディテール・ビュー・インスタンスまたはビュー・インスタンスを必ず選択してください。

   ヒント:

   ディテール・ビュー・インスタンスの場合、マスター・ビュー・インスタンスを開いて該当する行のディテールに移動できます。Oracle ADFモデル・テスターは、開いた概要パネル内に表示されたデータを、移動先のマスター・ビュー・インスタンスと自動的に同期化します。

   図13-25 Oracle ADFモデル・テスターのビュー行操作のメニュー選択

   
4. メソッド・パネル内で、ドロップダウン・リストから該当するサービスを選択し、メソッド・パラメータとして渡す値を入力し、「実行」をクリックします。

   メソッド・テスト・パネルにはパラメータ名が表示され、渡す値をどこに入力すればよいのかがわかるようになっている点に注意してください。これはメソッド・シグネチャが同じデータ型の複数のパラメータを定義している場合には特に便利です。

   戻り値(ある場合)とテスト結果を表示できます。Oracle ADFモデル・テスターに表示される結果は、メソッドが正常に実行されたかどうかを示します。

クライアント・インタフェースのメソッド・シグネチャに関する必知事項

クライアント・インタフェースには、次の実装ルールに従うカスタム・メソッドを追加できます。

• メソッドの戻り型がvoid以外の場合、型はシリアライズ可能である必要があります。

• メソッドが任意のパラメータを受け入れる場合、その型はすべてシリアライズ可能である必要があります。

• メソッド・シグネチャにthrows句が含まれる場合、例外はoracle.jboパッケージのJboExceptionのインスタンスである必要があります。

つまり、そのメソッド・シグネチャ内のすべての型はjava.io.Serializableインタフェースを実装する必要があり、チェック済の例外はJboExceptionまたはそのサブクラスである必要があります。メソッドでは、アプリケーション・モジュールのクライアント・インタフェースで非表示になることなく、未チェックの例外(java.lang.RuntimeExceptionまたはそのサブクラス)をスローできます。

java.util.Listの型のメソッド・シグネチャは、インタフェースの実装クラスがシリアライズ可能な限り使用できる点に注意してください。たとえば、java.util.ArrayListおよびjava.util.LinkedListは両方ともシリアライズ可能なクラスです。同じ要件がコレクション内の要素型に適用されます。インタフェースを実装しているクラスをインスタンス化したにもかかわらず、java.io.Serializableインタフェースを実行しなかった場合、ADFビジネス・コンポーネント・ランタイムはエラーを生成します。

ノート:

アプリケーション・モジュール・クラスに追加したメソッドが「使用可能」リストに表示されない場合は、メソッド実装ルールのいずれか違反していないかをまず確認してください。適切なメソッドと判断できる場合は、アプリケーション・モジュールの概要エディタに再移動する前に、アプリケーション・モジュール・クラスの再コンパイルを試行してください。

データ・モデルからの情報の引渡しに関する必知事項

アプリケーション・モジュールのカスタム・メソッドのプライベート実装では、生成されたアクセッサ・メソッドを使用してデータ・モデル内のビュー・オブジェクト・インスタンスを簡単に参照できます。ビュー・オブジェクトでgetCurrentRow()メソッドをコールすると、クライアント・ユーザー・インタフェースでビュー・オブジェクトの現在行として認識されている行にアクセスできます。その結果、アプリケーション・モジュールのビジネス・サービス・メソッドの記述中には、クライアントからのパラメータの引渡しが不要な場合があります。これは、同じアプリケーション・モジュールのデータ・モデルにある他のビュー・オブジェクト・インスタンスの現在行から値を渡すのみの場合に該当します。

たとえば、次の例にあるカスタム・アプリケーション・モジュール・メソッドではパラメータを受け入れません。createOrderItem()メソッドはgetGlobals().getCurrentRow()を内部でコールし、Globalsビュー・オブジェクト・インスタンスの現在行にアクセスします。次に、強く型付けされたアクセッサ・メソッドを行で使用してDescriptionおよびLineItemId属性の値にアクセスし、この値を、新規作成されたOrderItemエンティティ・オブジェクト行の対応する属性の値として設定します。

// In AppModuleImpl.java, createOrderItem() method
GlobalsRowImpl globalsRow = (GlobalsRowImpl)getGlobals().getCurrentRow();
newOrder.setDescription(globalsRow.getDescription());
newOrder.setLineItemId(globalsRow.getLineItemId());

アプリケーション・モジュールのクライアント・インタフェースのプログラム的操作

ADFビジネス・コンポーネント・アプリケーション・モジュールのクライアント・インタフェースを使用すると、アプリケーション・モジュールをプログラムで操作できます。

メソッドをアプリケーション・モジュールのクライアント・インタフェースに公開したら、それらのメソッドをクライアントから起動できます。

アプリケーション・モジュールのクライアント・インタフェースのプログラム的な操作方法

アプリケーション・モジュールのクライアント・インタフェースをプログラム的に操作するには、次の手順を実行します。

• ApplicationModuleを、特定のクライアント・インタフェースにキャストします。

• インタフェース上のいずれかのメソッドをコールします。

ノート:

この項では、説明を簡潔にするために、カスタム・アプリケーション・モジュールのインタフェースの操作のみを重視しますが、これと同じダウンキャスト方法は、ViewObjectインタフェースをCustomersなどのビュー・オブジェクト・インタフェースとして使用するクライアントや、RowインタフェースをCustomersRowなどのカスタム・ビュー行インタフェースとして使用するクライアントにも有効です。

次の例は、これらの2つのステップを実行するTestClientEntityクラスを示しています。「static mainメソッドを使用したカスタム・アプリケーション・モジュールのテスト方法」で説明しているように、このクラスのmain()メソッドを使用して、アプリケーション・モジュール・メソッドをテストすることもできます。ここでは、クライアントからAppModuleクライアント・インタフェースを使用して同じメソッドをすべてコールするために、これを使用します。

ノート:

oracle.jboパッケージのデフォルトのApplicationModuleインタフェースを使用してアプリケーション・モジュールを操作している場合は、カスタム・メソッドにアクセスできません。この例では、特定のカスタム・インタフェース(AppModuleインタフェースなど)に、アプリケーション・モジュール・インスタンスをキャストします。

次の例の基本ロジックはこれらのステップに従います。

1. 注文1011の合計を取得します。

2. 注文1011の顧客名を取得します。

3. 1011の注文ステータスを「Y」の値に設定します。

4. 顧客名がnullの新しい顧客を作成します。

5. 顧客名を付けて新しい顧客を作成し、新しく割り当てた顧客IDを表示します。

package oracle.summit.model.appmodule.client;

import oracle.jbo.client.Configuration;
import oracle.jbo.*;
import oracle.jbo.domain.Number;
import oracle.jbo.domain.*;

import oracle.summit.model.appmodule.service.common.AppModule;

public class TestClientCustomInterface {
  public static void main(String[] args) {
      String amDef = "oracle.summit.model.appmodule.service.AppModule";
      String config = "AppModuleLocal";

      /*
       * This is the correct way to use application custom methods
       * from the client, by using the application module's automatically-
       * maintained custom service interface.
       */
      AppModule service =
               (AppModule)Configuration.createRootApplicationModule(amDef,config);
      String total = service.findOrderTotal(1011);
      System.out.println("Total for Order # 1011 = " + total);
      String custName = service.findOrderAndCustomer(1011);
      System.out.println("Customer for Order # 1011 = " + custName);
      try {
         service.updateOrderStatus(1011,"Y");
      }
      catch (JboException ex) {
         System.out.println("ERROR: "+ex.getMessage());
      }
      long id = 0;
      try {
         id = service.createCustomer(null, "Oakville", 14);
      }
      catch (JboException ex) {
         System.out.println("ERROR: "+ex.getMessage());
      }
      id = service.createCustomer("Oakville Curling Club", "Oakville", 14);
      System.out.println("New customer created successfully with id = " + id);
      Configuration.releaseRootApplicationModule(service,true);
  }
}

カスタム・アプリケーション・モジュール・クラスを実行すると、前述の例のmain()メソッドがコールされ、次の出力が生成されます。

Total for Order # 1011 = 99.99
Customer for Order # 1011 = Customer: Zibbers, Location: Boston
ERROR: JBO-27014: You must provide a value for Name.
New customer created successfully with id = 133

顧客名をnullとしてfindOrderAndCustomer()をコールしようとした初回の試みでは、Customerエンティティ・オブジェクトのName属性に対する組込み必須検証が原因で例外が発生しています。

実行時に行われる処理: アプリケーション・モジュールのクライアント・インタフェースにアクセスする場合

アプリケーション・モジュールにアクセス中のクライアント・レイヤーはJava EEアーキテクチャの同一層にあるため、アプリケーション・モジュールはローカル・モードと呼ばれるモードでデプロイされます。ローカル・モードでは、クライアント・インタフェースはカスタム・アプリケーション・モジュールのJavaクラスによって直接実装されます。JavaServer FacesアプリケーションのWeb層のアプリケーション・モジュールにアクセスするたびに、ローカル・モードでアプリケーション・モジュールにアクセスします。

Fusion Webアプリケーションでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス方法

oracle.jbo.clientパッケージのConfigurationクラスでは、テスト用のアプリケーション・モジュール・インスタンスを非常に簡単に入手できます。これにより、JUnit回帰テスト・フィクスチャの一部となるテスト・クライアント・プログラム(「JUnitを使用した回帰テスト」を参照)のように、テスト・クライアント・プログラムの記述が簡単になります。

ベスト・プラクティス:

Fusion Webアプリケーションに対しては、常にバインディング・レイヤーを使用してアプリケーション・モジュールにアクセスする必要があります。開発者はアプリケーション・モジュールにアクセスするあらゆる場合に、このクラスのcreateRootApplicationModule()メソッドとreleaseApplicationModule()メソッドを使用しがちですが、ビュー・レイヤーにおける最善の方法はADFモデル・レイヤーの宣言機能を使用することです。

データをバインドするためのADFモデル・レイヤーを使用してFusion Webアプリケーションを操作している場合、JDeveloperにより、ユーザー・インタフェース・プロジェクトにADFBindingFilterというサーブレット・フィルタが構成されます。このフィルタにより、宣言的なバインディング・メタデータに基づく適切なアプリケーション・モジュール・インスタンスの自動的な取得およびリリースが調整され、ユーザー・インタフェース・プロジェクトのページ定義ファイルで指定された既知のアクション・バインディングまたはイテレータ・バインディングを使用して、サービスをデータ・コントロールとして検索できるようになります。ADFバインディング・コンテナ、データ・コントロール、ページ定義ファイルおよびADFバインディングの詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。ここでは、ADFアクション・バインディングまたはADFイテレータ・バインディングの名前を指定することで、このDCBindingContainerからアプリケーション・モジュールのクライアント・インタフェースにアクセスできることを覚えておけば十分です。次の例(アクション・バインディングおよびイテレータ・バインディング)に示すように、JSFマネージドBeanのカスタム・クライアント・インタフェースで、バインディング・コンテキストを参照してメソッドをコールできます。

アクション・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、次の基本ステップに従います(後に例を示しています)。

1. ADFバインディング・コンテナにアクセスします。

2. 名前の付いたアクション・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルに提供されている任意のアクション・バインディング名を使用します。)

3. データ・コントロールをアクション・バインディングから名前で取得します。

4. アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。

5. アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。

6. クライアント・インタフェースにあるいずれかのメソッドをコールします。

package oracle.summit.model.viewobjects;

import oracle.summit.model.appmodule.service.common.SummitAppModule;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCDataControl;
import oracle.jbo.ApplicationModule;
import oracle.jbo.uicli.binding.JUCtrlActionBinding;
public class YourBackingBean {
  public String commandButton_action() {
    // Example using an action binding to get the data control
    public String commandButton_action() {
    // 1. Access the binding container
    DCBindingContainer bc = (DCBindingContainer)getBindings();
    // 2. Find a named action binding
    JUCtrlActionBinding action = 
                    (JUCtrlActionBinding)bc.findCtrlBinding("SomeActionBinding");
    // 3. Get the data control from the iterator binding (or method binding)
    DCDataControl dc  = action.getDataControl();
    // 4. Access the data control's application module data provider
    ApplicationModule am = (ApplicationModule)dc.getDataProvider();
    // 5. Cast the AM to call methods on the custom client interface
    SummitAppModule service = (SummitAppModule)am;
    // 6. Call a method on the client interface
    service.doSomethingInteresting();
    return "SomeNavigationRule";
  }
}

イテレータ・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、次の基本ステップに従います(後に例を示しています)。

1. ADFバインディング・コンテナにアクセスします。

2. 名前の付いたイテレータ・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルないの任意のイテレータ・バインディング名を使用します。)

3. データ・コントロールをイテレータ・バインディングから名前で取得します。

4. アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。

5. アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。

6. クライアント・インタフェースにあるいずれかのメソッドをコールします。

package oracle.summit.model.viewobjects;

import oracle.summit.model.appmodule.service.common.SummitAppModule;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCDataControl;
import oracle.adf.model.binding.DCIteratorBinding;
import oracle.jbo.ApplicationModule;
public class YourBackingBean {
  public String commandButton_action() {
    // Example using an iterator binding to get the data control
    public String commandButton_action() {
    // 1. Access the binding container
    DCBindingContainer bc = (DCBindingContainer)getBindings();
    // 2. Find a named iterator binding
    DCIteratorBinding iter = bc.findIteratorBinding("SomeIteratorBinding");
    // 3. Get the data control from the iterator binding
    DCDataControl dc  = iter.getDataControl();
    // 4. Access the data control's application module data provider
    ApplicationModule am = (ApplicationModule)dc.getDataProvider();
    // 5. Cast the AM to call methods on the custom client interface
    SummitAppModule service = (SummitAppModule)am;
    // 6. Call a method on the client interface
    service.doSomethingInteresting();
    return "SomeNavigationRule";
  }
}

これらのバッキングBeanの例は、次の例に示すヘルパー・メソッドに依存します。

public BindingContainer getBindings() {
{
        return BindingContext.getCurrent().getCurrentBindingsEntry();
}

ADFアクションに宣言的にバインドされるボタンをオーバーライドしてバッキングBeanクラスを作成すると、このメソッドがクラス内に自動的に生成されます。それ以外の場合は、ヘルパー・メソッドをクラスに手動で追加する必要があります。

組込みフレームワーク・メソッドのオーバーライド

アプリケーション・モジュールJavaクラスの組込みADFメソッドをオーバーライドして、ADFアプリケーション・モジュールのデフォルト動作を拡張できます。

ApplicationModuleImplベース・クラスには、この機能を実装する組込みメソッドが多数含まれています。「ADFビジネス・コンポーネントのよく使用されるメソッド」は、カスタム・アプリケーション・モジュール・クラスでよく記述、使用およびオーバーライドする最も一般的なコードのクイック・リファレンスとなっていますが、この項では、これらの組込みフレームワーク・メソッドの1つをオーバーライドしてデフォルトの動作を拡張する基本ステップの理解を深めることを重視しています。

組込みフレームワーク・メソッドのオーバーライド方法

アプリケーション・モジュールの組込みフレームワーク・メソッドをオーバーライドするには、「メソッドのオーバーライド」ダイアログを使用して、メイン・メニューからアプリケーション・モジュールのJavaクラスを開きます。

始める前に:

アプリケーション・モジュールのベース・クラスに関する知識があると役立つ場合があります。詳細は、「組込みフレームワーク・メソッドのオーバーライド」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

アプリケーション・モジュールのフレームワーク・メソッドをオーバーライドするには:

1. 「アプリケーション」ウィンドウで、フレームワーク・メソッドをオーバーライドするアプリケーション・モジュールをダブルクリックします。
2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、カスタマイズするアプリケーション・モジュールのJavaクラスにリンクされたファイル名をクリックします。

   ソース・エディタが開いて、クラス・ファイルが表示されます。

3. メイン・メニューから、「ソース」を選択し、次に「メソッドのオーバーライド」を選択します。

   「ソース」メニューが表示されていない場合は、目的のJavaクラス・ファイルが開いており、ソース・エディタが表示されていることを確認します。

4. 「メソッドのオーバーライド」ダイアログで、リストをスクロールして目的のメソッドを特定するか、あるいはメソッド名の最初の数文字を入力してインクリメンタル検索を実行します。
5. メソッドを1つ以上選択します。

   「メソッドのオーバーライド」ダイアログでは、任意の数のメソッドを選択して同時にオーバーライドできます。

   たとえば、図13-26に示すように、新規ユーザー・セッションでアプリケーション・モジュールのサービス・コンポーネントの操作を初めて開始したときに、アプリケーション・モジュールのprepareSession()メソッドをオーバーライドしてデフォルトの機能を拡張する場合、prepareSession(Session)メソッドの隣のチェック・ボックスを選択します。

   図13-26 組込みフレームワーク・メソッドのオーバーライド

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

組込みフレームワーク・メソッドをオーバーライドした場合の処理

「メソッドのオーバーライド」ダイアログを閉じると、図13-27に示すように、オーバーライドしたメソッドにカーソルが置かれた状態でソース・エディタに戻ります。メソッドには、super.prepareSession()をコールする単一行が表示されています。これは、ベース・クラスがこのメソッドに対して通常であれば実行したはずのデフォルトの動作を起動するJava構文です。カスタム・アプリケーション・モジュール・クラスでこの行の前または後にコードを追加して、デフォルトの機能の前または後のデフォルトの動作を拡張できます。

図13-27 オーバーライドしたメソッドに関してソース・エディタのマージンに表示されるフィードバック

「メソッドのオーバーライド」ダイアログを使用してメソッドをオーバーライドする場合、ソース・エディタにより、オーバーライドしたメソッドの直前にJDK @Override注釈が挿入されます。この注釈により、アプリケーション・モジュール・クラスのメソッドがスーパークラスのメソッドのシグネチャと一致しない場合は、コンパイル時にエラーが生成されます。

クラスにメソッド名を追加してスーパークラス内のメソッドをオーバーライドする場合は注意が必要です。オーバーライドするベース・クラス・メソッドと完全に同一のシグネチャが必要です。@Override注釈は必ずメソッドの直前に追加してください。これにより、メソッドがスーパークラスのメソッドのいずれのシグネチャとも一致しない場合は、コンパイル時にエラーが生成されます。スーパークラスの実装をコールするかわりにメソッドのコードを記述する場合は、抑止または置換する組込みコードについて理解しておく必要があります。

prepareSession()をオーバーライドして新規ユーザー・セッション用のアプリケーション・モジュールを設定する方法

prepareSession()メソッドは、新しいユーザー・セッションで初めて使用されるときにアプリケーション・モジュールによって起動されるため、カスタム・アプリケーション・モジュール・クラスをオーバーライドし、アプリケーション・モジュールを使用する新しいユーザーごとに固有のセットアップ・タスクを実行する場合に便利なメソッドです。次の例は、接続されたユーザーのデータベース・クライアント情報を指定するsetApplicationInfo()ヘルパー・メソッドを起動するAppModuleImplクラス内の、オーバーライドされたprepareSession()メソッドを示しています。

public class AppModuleImpl extends SummitApplicationModuleImpl 
                           implements AppModule {
...

    @Override
    protected void prepareSession(Session session) {
        super.prepareSession(session);
        setApplicationInfo ("AppModuleImpl", "prepareSession");
        String username = this.getUserPrincipalName();
        System.out.println(username);
    }
    
    protected void setApplicationInfo(String clientInfo, String clientIdentifier){
        DBTransactionImpl dbti = (DBTransactionImpl)getDBTransaction();
        CallableStatement statement =
            dbti.createCallableStatement("BEGIN " 
          + "DBMS_APPLICATION_INFO.SET_CLIENT_INFO (client_info => :client_info);"
          + "DBMS_SESSION.SET_IDENTIFIER (:client_identifier);"
          + "END;", 0);
        try {
            statement.setString("client_info", clientInfo);
            statement.setString("client_identifier", clientIdentifier);
            statement.execute();
        } catch (SQLException sqlerr) {
            throw new JboException(sqlerr);
        } finally {
            try {
                if (statement != null) {
                    statement.close();
                }
            } catch (SQLException closeerr) {
                throw new JboException(closeerr);
            }
        }
    }
}

アプリケーション・モジュールからのWebサービスのコール

組込みのWebサービス・ウィザードを使用してプロキシ・クラスを作成してメソッドを実装し、そのクラスを使用してWebサービス・メソッドをADFアプリケーション・モジュールでコールします。

サービス指向アーキテクチャでは、アプリケーション・モジュールに基づいていないWebサービスから提供される機能をOracle ADFアプリケーション・モジュールで利用する必要がある場合もあります。Webサービスは、任意のプログラミング言語で実装し、ネットワーク上の任意のサーバーに配置できます。各Webサービスでは、言語に依存しない標準的なXMLフォーマットで記述することにより、一連の該当するメソッドをそのAPI内で指定します。このXMLドキュメント(構文は、Web Services Description Language (WSDL)に準拠)を使用すると、Webサービスのメソッドの名前に加えて、それらのメソッドが予期するパラメータや実際の戻り値のデータ型も、JDeveloperで理解できます。

ノート:

アプリケーション・モジュールはWebサービスとして公開し、デプロイ済のFusion Webアプリケーションのモジュール間で使用することもできます。外部サービスを使用したADFビジネス・コンポーネントの再利用の詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。

JDeveloperに組み込まれているWebサービス・ウィザードを使用すると、そのようなタスクを簡単に実行できます。該当するウィザードを使用してWebサービス・プロキシ・クラスを作成し、ローカルなJavaオブジェクトに追加するメソッド・コールを使用してサービスをコールします。

外部サービスのプログラム的なコール方法

アプリケーション・モジュールからWebサービスをコールするには、起動するサービスのWebサービス・プロキシ・クラスを作成します。Webサービス・プロキシとは、該当するアプリケーション内のWebサービスを表す、生成されたJavaクラスのことです。該当するWebサービスのサービスURLをカプセル化し、サービスをコールをするための低レベルの詳細情報を処理します。

Webサービスを使用するには、該当するWSDLドキュメントを特定するURLを知る必要があります。たとえば、WSDLドキュメントは、電子メールの添付として受信し、ローカルのハード・ドライブに保存した場合、URLは次のようになります。

file:///D:/temp/SomeService.wsdl

また、URLは、次のようなHTTPベースのURLの場合もあります。

http://someserver.somecompany.com/SomeService/SomeService.wsdl

一部のWebサービスの場合、そのWSDLドキュメントは、サービスURLを変更する特殊なパラメータを使用して利用可能になります。たとえば、http://someserver.somecompany.com/SomeServiceのHTTPアドレスでリクエストを受信することが期待されているWebサービスの場合は、同一のURLの末尾に次のような追加のパラメータを付けて、対応するWSDLドキュメントを公開することもあります。

http://someserver.somecompany.com/SomeService?WSDL

標準が確立されていないため、WSDLドキュメントに対する正確なURLを知っておくのみで十分です。URL情報があれば、該当するサービスをコールするためのWebサービス・プロキシ・クラスを作成できます。

ADFビジネス・コンポーネント・サービスには次の形式のサービスへのURLがあります。

• 統合されたWebLogic Server上でのURLの形式はhttp://host:port/EJB-context-root/@WebService-name?WSDLで、たとえば、次のようになります。

  http://localhost:8888/EJB-SummitService/SummitService?WSDL
  

• Oracle WebLogic Server。URLの形式はhttp://host:port/context-root/@WebService-name?WSDLで、たとえば、次のようになります。

  http://localhost:8888/SummitService/SummitService?WSDL
  

Webサービス・プロキシ・クラスは、WebサービスのパブリックAPIに対応する一連のJavaメソッドを表します。Webサービス・プロキシ・クラスを使用すると、Webサービス内の任意のメソッドを、他の任意のローカルなJavaクラスのメソッドの場合と同じ方法でコールすることができます。

プロキシ・クラスを使用してアプリケーション・モジュールからWebサービスをコールするには、次の作業を実行します。

1. WebサービスのWebサービス・プロキシ・クラスを作成します。コールする必要のあるWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・クライアントおよびプロキシの作成ウィザードを使用します。

2. プロキシ・クラスにメソッドを実装し、目的のWebサービスにアクセスします。

3. 該当するWebサービス・プロキシ・クラスのインスタンスをアプリケーション・モジュール内で作成し、Webサービス・プロキシ・オブジェクト上でメソッドを1つ以上起動します。

サービスにプログラム的にアクセスするためのWebサービス・プロキシ・クラスの作成

コールするWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・プロキシ作成ウィザードを使用します。

始める前に:

Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

サービスにプログラム的にアクセスするためにWebサービス・プロキシ・クラスを作成するには:

1. 「アプリケーション」ウィンドウで、Webサービス・プロキシを作成するプロジェクトを右クリックし、「新規」→「Webサービス・クライアントおよびプロキシ」を選択します。
2. 「Webサービス・クライアントおよびプロキシの作成」ウィザードの「Webサービス記述の選択」ページで、アプリケーション内でコールするサービスのWSDLのURLを入力し、フィールドからタブアウトします。

   ウィザードの「次へ」が有効になっている場合は、WSDLドキュメントをJDeveloperが認識し、検証済です。「次へ」ボタンが有効にならない場合は、URLの検証後に問題を修正してこのステップを繰り返します。

3. ウィザードの以降のページに進み、Webサービス・プロキシの詳細を指定します。
4. 「終了」をクリックします。

サービスを起動するためのWebサービス・プロキシ・テンプレートのコール

Webサービス・プロキシを作成したら、目的のWebサービスにアクセスするためにプロキシ・クラスにメソッドを実装する必要があります。

始める前に:

Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

• 「サービスにプログラム的にアクセスするためのWebサービス・プロキシ・クラスの作成」の説明に従い、目的のWebサービス・プロキシ・クラスを作成します。

サービスを起動するためにWebサービス・プロキシ・テンプレートをコールするには:

1. ソース・エディタでport_nameClient.javaという名前のプロキシ・クライアント・クラスを開き、メイン・メソッド内にある// Add your own code to call the desired methodsというコメントを検索します。
2. 適切なコードを追加してWebサービスを起動します。
3. JDeveloperにより生成されたクライアント・モジュール・クラスの完全セットをデプロイし、このクラスをアプリケーションで参照します。

アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール

Webサービス・プロキシ・クラスが生成されると、次の例に示すように、アプリケーション・モジュールのカスタム・メソッド内で使用できます。該当メソッドによりWebサービス・プロキシ・クラスのインスタンスが作成され、その結果についてWebサービス・プロキシ・クラスからWebサービス・メソッドがコールされます。

// In YourModuleImpl.java
public void performSomeApplicationTask(String symbol) throws Exception {
  // application-specific code here
   :
  // Create an instance of the web service proxy class 
  StockQuoteServiceSoapHttpPortClient svc =
            new StockQuoteServiceSoapHttpPortClient();
  // Call a method on the web service proxy class and get the result
  QuoteInfo quote = svc.quoteForSymbol(symbol);
  float currentPrice = quote.getPrice();
  // more application-specific code here
}

Webサービス・プロキシの作成時の処理

JDeveloperは、WSDLドキュメント内で検出されたWebサービス・ポートの名前を反映した名前を使用して、ユーザーが指定したパッケージ内でWebサービス・プロキシ・クラスを生成します。Webサービス・ポート名は、人間が判読できるStockQuoteServiceのような名前の場合もあれば、StockQuoteServiceSoapHttpPortのようなわかりにくい名前の場合もあります。このポート名は、ユーザーが使用中のWebサービスを公開した開発者によって決定されます。たとえば、サービスのポート名がStockQuoteServiceSoapHttpPortであると仮定すると、JDeveloperはStockQuoteServiceSoapHttpPortClientという名前のWebプロキシ・クラスを生成します。

Webサービス・プロキシは、「アプリケーション」ウィンドウ内で、WebServiceNameProxyという単一の論理ノードとして表示されます。たとえば、StockQuoteService WebサービスのノードはStockQuoteServiceProxyという名前で「アプリケーション」ウィンドウに表示されます。JDeveloperでは、プロキシ・クラスの生成処理の一部として、サーバーの起動に使用するメインのWebサービス・プロキシ・クラスのみでなく、多数の補助クラスとインタフェースも生成されます。これらのファイルは、「アプリケーション」ウィンドウ内のWebServiceNameProxyノードの下に表示されます。生成されたファイルは、Webサービスを起動するための低レベルの実装の一部で使用されます。

生成された補助クラスのうち、参照する必要のあるものは、構造化されたWebサービス・パラメータまたは戻り型を保持するように作成されるクラスのみです。たとえば、WebサービスStockQuoteServiceのquoteForSymbol()メソッドが、Stringパラメータを1つ受け取り、株の時価を表す浮動小数点値を1つ返すものとします。Webサービスの設計者がシンプルな浮動小数点数を1つ返すように選択すると、Webサービス・プロキシ・クラスは次のような対応するメソッドを持つことになります。

public float quoteForSymbol(String symbol)

また、Webサービスの設計者が結果として複数の情報を返す方が便利であると考える場合は、サービスのWSDLファイルには、包含される複数の要素を記述する名前付き構造の定義が1つ含まれることになります。たとえば、シンボル名と時価が結果としてサービスから返されるとします。これら2つのデータ要素を含めるために、WSDLファイルでは、文字列型のsymbolという名前の要素と浮動小数点型のpriceという名前の要素を持つQuoteInfoという名前の構造を1つ定義する場合もあります。このような状況でJDeveloperがWebサービス・プロキシ・クラスを生成する場合、Javaメソッド・シグネチャは次のようになります。

public QuoteInfo quoteForSymbol(String symbol)

戻り型QuoteInfoでは、Webサービス・プロキシ実装を構成する補助クラスの1つを参照します。それは、WSDLドキュメントの中で定義されている構造の名前と型がプロパティに反映されているシンプルなBeanです。同様に、Webサービスが受け取るパラメータ値が構造または構造の配列である場合は、それに対応する生成されたBeanを使用して、それらの構造をJavaコード内で操作する必要があります。

新しいWebサービス接続の作成方法

Webサービス・プロキシの開発後、プロキシの接続を追加で作成し、テストやデプロイメントで使用できます。たとえば、テスト用にユーザー名とパスワードを含む接続を作成できます。

接続情報はアプリケーション内の他の接続と一緒にconnections.xmlファイルに保存されます。エンドポイントURLの抽象化によって、Enterprise Managerを使用したデプロイ後に、クライアント・コードを変更せずに接続を編集することもできます。

始める前に:

Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

Webサービス接続を作成するには:

1. 「アプリケーション」ウィンドウで、Webサービス・プロキシを右クリックし、「ADF Webサービス接続を作成しています」を選択します。

   「新規ADF Webサービス接続」ダイアログに、選択したプロキシに関連付けられた接続のデフォルト設定が表示されます。

2. 必要に応じて接続情報を変更し、「OK」をクリックします。

警告:

既存の接続と同じ名前で新しいWebサービス接続を作成すると、既存の接続が新しい情報によって上書きされます。

新しいWebサービス接続の作成後、この接続を使用するようにクライアントを変更できます。次の例に示すようなコードを使用して、クライアントから接続にアクセスできます。

Context ctx = ADFContext.getCurrent().getConnectionsContext();

WebServiceConnection wsc = (WebServiceConnection) ctx.lookup("MyAppModuleService");

MyAppModuleService proxy = wsc.getJaxWSPort(MyAppModuleService.class);

lookup()メソッドに渡す引数は、Webサービス接続に渡した名前です。この例ではMyAppModuleServiceです。

実行時に行われる処理: Webサービス・プロキシによるWebサービスの起動処理

アプリケーション・モジュールからWebサービスを起動する場合、Webサービス・プロキシ・クラスは、「SOAP」で説明したXMLベースのWebサービス・プロトコルを使用する際の低レベルの詳細処理を実行します。具体的には、次の処理を実行します。

• メソッドの起動を表すXMLドキュメントを作成

• メソッド引数をXMLにパッケージング

• HTTP POSTリクエストを使用してXMLドキュメントをサービスURLに送信

• Webサービスから受信したXMLエンコード・レスポンスのパッケージングを解除

起動対象のメソッドが戻り値を持つ場合は、アプリケーション・モジュール・コード内で操作できるように、適切な型のオブジェクトとして受信します。

Webサービス・プロキシに関する必知事項

アプリケーション内でWebサービス・プロキシを実装している場合、「try-catch」ブロックを使用してWebサービス例外を処理するか、Webサービス・プロキシ・クラスでアプリケーション・モジュールを起動します。以降の項で、この機能や、Webサービス・プロキシに関するその他の機能の詳細を説明します。

try/catchブロックによるWebサービス例外の処理

生成されたWebサービス・プロキシ・クラスを使用すると、リモートWebサービスの起動は、ローカルJavaクラス内のメソッドをコールするのと同じように簡単になります。その場合に注意が必要な唯一の違いは、HTTPリクエストに関与する問題が存在する場合にWebサービス・メソッドのコールが失敗する可能性がある点です。Webサービス・プロキシに対して実行するメソッド・コールでは、適切なtry...catchブロックを使用してコールをラップすることにより、リクエストの失敗に備える必要があります。次の例では、Webサービス例外を検出することにより、前述(「アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール」)の簡単な例を改善しています。この場合は該当するエラーをJboExceptionとして再スローしているだけですが、アプリケーションではさらに適切なエラー処理を実装することもできます。

// In YourModuleImpl.java
public void performSomeApplicationTask(String symbol) {
  // application-specific code here
  // :
  QuoteInfo quote = null;
  try {
    // Create an instance of the web service proxy class 
    StockQuoteServiceSoapHttpPortClient svc =
               new StockQuoteServiceSoapHttpPortClient();
    // Call a method on the web service proxy class and get the result
    quote = svc.quoteForSymbol(symbol);
  }
  catch (Exception ex) {
    throw new JboException(ex);
  }
  float currentPrice = quote.getPrice();
  // more application-specific code here
}

アプリケーションモジュールとWebサービスでのトランザクションの分離

参照情報にアクセスするために使用するWebサービスもあります。また、データを変更するためにコールするサービスもあります。このデータ変更は、社内の自分のチームまたは別のチームのメンバーによってサービスが記述された場合、自社のデータベースに存在する可能性があります。Webサービスが自社のファイアウォールの外部にある場合は、変更対象のデータベースは、当然、別の会社によって管理されます。

いずれの場合でも、起動するWebサービスによって実行されるデータ変更は、アプリケーション・モジュールの現在の作業ユニットとは無関係な独自のトランザクションによって実行されるということを理解しておくことが重要です。たとえば、データを変更するWebサービスを起動した後、rollback()をコールしてアプリケーション・モジュールの現在の作業ユニット内で保留中の変更を取り消しても、該当するプロセス内でコールしたWebサービスによって実行される変更に影響はありません。対応するWebサービス・メソッドを起動して、補正用の変更を実行し、アプリケーション・モジュールのトランザクションのロールバックを無効にする必要がある場合があります。

ブラウザ・プロキシ情報の設定

コール対象のWebサービスが自社ファイアウォールの外部にある場合は、HTTPプロキシ・サーバーを使用できるような適切な構成にJavaシステム・プロパティが設定されていることを確認する必要があります。構成する必要のあるJavaシステム・プロパティは、次のとおりです。

• http.proxyHost - プロキシ・サーバーの名前を設定します。

• http.proxyPort - プロキシ・サーバーのHTTPポート番号(80の場合が多い)を設定します。

• http.nonProxyHosts - プロキシ・サーバーを使用しないサーバーを縦線で区切ってリストで指定します(オプション。例 - localhost|127.0.0.1|*.yourcompany.com)。

JDeveloperでは、「設定」ダイアログの「Webブラウザとプロキシ」ページでHTTPプロキシ・サーバーを構成できます。アプリケーションを実行する際、JDeveloperの-Dコマンド行オプションを使用すると、このダイアログで指定した設定値に基づき、前述の3つのシステム・プロパティを設定できます。

Webサービス・プロキシ・クラスを使用したアプリケーション・モジュールの起動

Webサービス・プロキシ・クラスを使用してOracle ADFサービスベースのアプリケーション・モジュールを起動すると、コール側コンポーネントとコールしているサービスがコロケートしている場合にコールを最適化できなくなります。別の方法として、「アプリケーション・モジュールによるSOAP Webサービスの作成」で説明しているサービス・インタフェースによるアプローチを使用することもできます。