Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.1.2) E48099-02 |
|
![]() 前 |
![]() 次 |
この章では、JDBCデータ・ソースから導出されたOracle ADFアプリケーションのデータ・モデルをカプセル化するADFアプリケーション・モジュールの作成方法について説明します。この章では、ビジネス・サービス・メソッドをそのデータ・モデルと結合して完全なビジネス・サービスを実装する方法についても説明します。
この章には次の項が含まれます:
アプリケーション・モジュールは、ADFビジネス・コンポーネントで、エンド・ユーザー・タスクに関連する論理作業ユニットのビジネス・サービス・メソッドとデータ・モデルをカプセル化したものです。
アプリケーション開発の早期段階では、アーキテクトと設計者は通常、UMLユースケース手法およびADFタスク・フローを使用して、アプリケーションの計画済エンド・ユーザー機能の高レベルな概要を作成します。この設計段階中に識別されるエンド・ユーザーの高レベルな各ユースケースは、一般に次のものに応じて異なります。
対象となるドメイン・ビジネス・オブジェクト。ユースケースに関連するコア・ビジネス・データについての問題に解答します。
必要なビジネス・データのユーザー指向ビュー。ユースケースをサポートするために必要な列サブセット、フィルタ処理された行セット、ソート方法、グループ化方法などについての問題に解答します。
各ユースケースに関連するドメイン・オブジェクトを識別すると、ビジネス・ドメイン・レイヤー内の必要なエンティティ・オブジェクトを識別する際に便利です。必要なビジネス・データのユーザー指向ビューは、ビュー・オブジェクトとして取得された適切なSQL問合せを定義して、データをエンド・ユーザーの期待どおりに取得する際に便利です。これには、パフォーマンスを最大化するために、ユースケースのサポートに必要な最低限の詳細の取得が含まれます。これまでの説明で、ビュー・オブジェクト問合せおよびビュー基準を利用してデータを形成する方法のみならず、ビュー・リンクを使用してデータ・モデルに自然なマスター/ディテール階層を設定し、期待どおりのエンド・ユーザー体験をユーザーに提供してユースケースを実現する方法も、すでに学習しました。
アプリケーション・モジュールは、当該のユースケースに必要な再使用可能なビュー・オブジェクトのインスタンスを含む作業ユニット・コンテナです。これらのビュー・オブジェクト・インスタンスは、エンド・ユーザー・ユースケースにより表示または変更する情報が決定される再使用可能なビジネス・ドメイン・レイヤー内の基礎となるエンティティ・オブジェクトに、メタデータを通じて関連付けられています。
この章では、図13-1に示す次の概念について説明します。
ビュー・オブジェクトのインスタンスをアプリケーション・モジュールで公開して、そのデータ・モデルを定義します。
サービス・メソッドを記述して、タスク・レベルのビジネス・ロジックをカプセル化します。
UIクライアントがコールするメソッドを選択し、クライアント・インタフェースで公開します。
アプリケーション統合シナリオでプログラム的に使用するメソッドを選択し、サービス・インタフェースで公開します。
12cから、Oracle JDeveloperではADFビジネス・コンポーネント・モデル・プロジェクトにおけるEJBセッションBean対応のアプリケーション・モジュールのサポートが非推奨となった点に注意してください。今後、JDeveloperではEJBセッションBean対応のアプリケーション・モジュールを作成または実行できません。既存のEJBセッションBean対応のアプリケーション・モジュールのかわりとして、第15章「サービス対応アプリケーション・モジュールの統合」に説明されているとおり、アプリケーション・モジュール・サービスをWebサービス対応のアプリケーション・モジュールに移行できます。このアプローチは外部サービスを使用してサービス・メソッドを公開するためのベスト・プラクティスと一貫しています。
複数のWebページまたはビューにまたがる論理トランザクションでは、プールからのアプリケーション・モジュール・インスタンスを使用します。
アプリケーション・モジュールでは、データベース接続の取得と、エンティティ・オブジェクトに行われた変更の保存またはロールバックの調整を行うTransaction
オブジェクトを操作します。
関連するSession
オブジェクトにより、現在のアプリケーション・ユーザーに関するランタイム情報が提供されます。
アプリケーション・モジュールを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。
共有アプリケーション・モジュールの作成の詳細は、第14章「アプリケーション・モジュール・ビュー・インスタンスの共有」を参照してください。
外部サービスを使用したADFビジネス・コンポーネント・サービス・メソッドの公開の詳細は、第15章「サービス対応のアプリケーション・モジュールの統合」を参照してください。
「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュール公開方法の詳細は、第17章「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。
実行時のパフォーマンスを向上させるためのアプリケーション・モジュール・インスタンス構成の詳細は、第49章「Fusion Webアプリケーションでの状態管理の使用」および第50章「アプリケーション・モジュール・プールと接続プールのチューニング」を参照してください。
本番環境のパフォーマンスとスケーラビリティを最大化する方法の詳細は、パフォーマンスのチューニングの「Oracle Application Development Frameworkのパフォーマンス・チューニング」の章を参照してください。
カスタム・アプリケーション・モジュール・クラスでよく記述、使用またはオーバーライドするコードについては、付録D「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。
oracle.jbo
パッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。
Oracle ADFモデルJava APIリファレンス
大規模なアプリケーションでは、通常、粒度の粗い各エンド・ユーザー・タスクをサポートするアプリケーション・モジュールを1つずつ作成します。小規模なアプリケーションでは、アプリケーション・モジュールを1つ作成すれば、アプリケーションの全機能のニーズを十分に処理できると判断する場合もあります。13.4項「ネストされたアプリケーション・モジュールの定義」には、これに関する追加の説明があります。
作成するビュー・オブジェクトは、1つ以上のアプリケーション・モジュールで使用できる再利用可能コンポーネントです。各ビュー・オブジェクトは、そのアプリケーション・モジュールのトランザクションのコンテキストで、カプセル化した問合せを実行します。アプリケーション・モジュールで使用される一連のビュー・オブジェクト・インスタンスは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。
既存のADFビジネス・コンポーネント・プロジェクトにアプリケーション・モジュールを追加するには、「新規ギャラリ」から使用できる「アプリケーション・モジュールの作成」ウィザードを使用します。
始める前に:
アプリケーション・モジュールの知識があると役立ちます。詳細は、13.2項「アプリケーション・モジュールの作成と変更」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュールを手動で作成するには:
「アプリケーション」ウィンドウで、アプリケーション・モジュールを作成するプロジェクトを右クリックし、「新規」および「アプリケーション・モジュール」を選択します。
「アプリケーション・モジュールの作成」ウィザードの「名前」ページで、パッケージ名およびアプリケーション・モジュール名を指定します。「次へ」をクリックします。
注意: Fusion Webアプリケーションでは、アプリケーション・モジュールの名前に予約語の |
「データ・モデル」ページで、以前に定義したビュー・オブジェクトのインスタンスを指定し、これらのビュー・オブジェクト・インスタンスの名前を、「データ・コントロール」パネルでクライアントに対して表示される名前とまったく同じ名前に編集します。次に、「次へ」をクリックします。
「Java」ページではオプションでJavaファイルを作成し、アプリケーション・モジュールの動作をプログラミングによってカスタマイズすることができます。あるいは、アプリケーション・モジュールのクライアント・インタフェースにメソッドをエクスポートして、クライアントが呼び出せるようにすることができます。XML専用のアプリケーション・モジュール・コンポーネントを生成するには、このフィールドを選択しないまま、「終了」をクリックします。
最初に、アプリケーション・モジュールのXML定義コンポーネントのみを生成することもできます。ウィザードを完了した後に、プログラムによるアクセスが必要になる場合は、概要エディタを使用してアプリケーション・モジュール・クラス・ファイルを生成できます。アプリケーション・モジュールのプログラム的な使用の詳細は、13.7項「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。
手順ごとの詳細は、13.2.3.2項「アプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。
アプリケーション・モジュールを作成すると、JDeveloperでは、その宣言的設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリに保存されます。たとえば、summit.model
パッケージのBackOfficeAppModule
という名前のアプリケーション・モジュールに対しては、プロジェクトのソース・パスに./summit/model/BackOfficeAppModule.xml
というXMLファイルが作成されます。このXMLファイルには、ビュー・オブジェクト・インスタンスをアプリケーション・モジュールのデータ・モデルで再作成するために実行時に必要な情報が含まれています。
この内容を確認するには、「アプリケーション」ウィンドウでアプリケーション・モジュールのノードをダブルクリックして概要エディタを開き、アプリケーション・モジュールのXMLファイルを確認します。エディタ・ウィンドウで「ソース」タブをクリックすると、XMLファイルが表示され、その内容を確認できます。構造ウィンドウには、XMLファイルの構造が表示されます。
ビジネス・コンポーネントを作成すると、JDeveloperがアプリケーション・モジュールのすべての機能を含むデータ・コントロールを自動的に作成します。データ・コントロールはADFモデル抽象レイヤーで、属性、メソッド、関連する型の情報を含む補足メタデータを提供して、アプリケーション・モジュールの操作とデータ・コレクション(ビュー・オブジェクト・インスタンスの行セット)を記述します。開発者は、JDeveloperの「データ・コントロール」パネルに表示されたデータ・コントロールの表現を使用して、アプリケーション・モジュールに自動的にバインドされるUIコンポーネントを作成できます。実行時にADFモデル・レイヤーによって、適切なXMLファイルからデータ・コントロールおよびバインディングを記述したメタデータが読み取られ、ユーザー・インタフェースとビジネス・サービスの双方向の結合が実装されます。
たとえば、BackOfficeAppModule
アプリケーション・モジュールによりSummitADF
アプリケーション・ワークスペースのビジネス・サービス・レイヤーが実装されます。このデータ・モデルには、複数のマスター/ディテール階層など、多数のビュー・オブジェクト・インスタンスが含まれています。コアSummit ADFサンプル・アプリケーションのビュー・レイヤーはJSFページで構成され、このページのUIコンポーネントは、BackOfficeAppModule
のデータ・モデル内のビュー・オブジェクト・インスタンスのデータと、そのクライアント・インタフェース上の組込み操作およびサービス・メソッドにバインドされています。「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュール表示方法の詳細は、17.3項「ADFデータ・コントロールでのアプリケーション・モジュールの表示」を参照してください。
「アプリケーション・モジュールの作成」ウィザードでアプリケーション・モジュールを作成しながらビュー・オブジェクト・インスタンスをアプリケーション・モジュールに追加することも、作成済のアプリケーション・モジュールに後で追加することもできます。
アプリケーション・モジュールの作成ウィザードの使用方法の詳細は、13.2.1項「アプリケーション・モジュールの作成方法」を参照してください。
作成済のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加できます。ビュー・オブジェクト・インスタンスを既存のアプリケーション・モジュールへ追加したり、オプションでビュー・オブジェクト・インスタンスをカスタマイズするには、アプリケーション・モジュールの概要エディタにある「データ・モデル」ページを使用します。
始める前に:
アプリケーション・モジュールの知識があると役立ちます。詳細は、13.2項「アプリケーション・モジュールの作成と変更」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
既存のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加するには:
「アプリケーション」ウィンドウで、新しいビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「選択可能なビュー・オブジェクト」リストで、追加するビュー・インスタンスを選択します。
リストの下の「新規ビュー・インスタンス」フィールドに、データ・モデルに追加するビュー・オブジェクトの次のインスタンスを識別する際に使用される名前が示されます。
ビュー・オブジェクトを追加する前に名前を変更するには、「新規ビュー・インスタンス」フィールドに別の名前を入力します。
目的のビュー・オブジェクトを選択し、「データ・モデル」リストに移動します。
図13-2では、ビュー・オブジェクトCountriesVO
の名前をCountries
に変更してから、「データ・モデル」リストに移動しています。
アプリケーション・モジュールの概要エディタに表示されるデータ・モデルを使用すると、プロジェクトで定義されている既存のビュー・リンクに基づいて、ビュー・インスタンスの階層を作成できます。複数のマスター/ディテールの階層レベルで構成されるビュー・リンクを定義している場合は、アプリケーションでサポートされているレベル数までマスター/ディテールのビュー・インスタンスを作成できます。
始める前に:
アプリケーション・モジュールの知識があると役立ちます。詳細は、13.2項「アプリケーション・モジュールの作成と変更」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
マスター/ディテールのビュー・オブジェクト・インスタンスをデータ・モデルに追加するには:
「アプリケーション」ウィンドウで、新しいマスター/ディテール・ビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
「データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを開き、「使用可能なビュー・オブジェクト」リストで、積極的に調整を行うマスターにするビュー・オブジェクトのインスタンスを選択します。
リスト内のマスター・ビュー・オブジェクトには、このビュー・オブジェクトにビュー・リンクがあることを示すプラス記号が表示されます。ビュー・リンクは、マスター/ディテール階層の定義に必要です。
図13-3は、選択したCountriesVO
と、「新規ビュー・インスタンス」フィールドで名前を変更したCountries
を示しています。
選択したマスター・ビュー・オブジェクトを「データ・モデル」リストに移動します。
図13-4は、「データ・モデル」リストに新規作成したマスター・ビュー・インスタンスCountries
を示しています。
「データ・モデル」リストで、新規作成したマスター・ビュー・インスタンスを選択して強調表示しておきます。これは、追加するディテール・ビュー・インスタンスのターゲットになります。次に、「選択可能なビュー・オブジェクト」リストで、マスター・ビュー・オブジェクトの下のディテール・ビュー・オブジェクトを特定して選択します。
図13-5は、マスターCustomerVO
の下にある、OrdVO via OrdCustomerIdFkLink
という名前のディテールOrdersVO
を示しています。この名前はビュー・リンクOrdCustomerIdFkLink
を表し、CustomerVO
とOrdVO
間のマスター/ディテール階層を定義します。データ・モデルに追加すると、OrdVO
にはビュー・インスタンス名のOrdersForCustomers
が追加されることにも注意してください。
追加したマスター・インスタンスにディテール・インスタンスを追加するには、「データ・モデル」リストで選択したマスター・ビュー・インスタンスの下に、ディテール・ビュー・オブジェクトを移動します。
図13-6は、データ・モデルにCustomers
のディテールとして新規作成したディテール・ビュー・インスタンスOrdersForCustomers
を示しています。
別の階層レベルを追加するには、手順3から6を繰り返しますが、この場合は、新しく追加したディテール・インスタンスを「データ・モデル」リストで選択してから、新しいディテール・インスタンスを移動します。このディテール・インスタンスは、前に追加したディテール・インスタンスとマスター/ディテール関係を持ちます。
図13-7では、OrdersForCustomer
(旧名はOrdVO via OrdCustomerIdFkLink
)のマスターとする(その結果、ItemsForOrder
(旧名はItemVo via ItemOrdIdFkLink
)のマスターになる)Customers
(旧名はCustomerVO
)インスタンスを含む、「データ・モデル」リストを示しています。
アプリケーション・モジュールの概要エディタにある、「データ・モデル・コンポーネント」ページでビュー・オブジェクト・インスタンスのカスタマイズを任意に行えます。たとえば、次のようにマスター/ディテール・ビュー・オブジェクトの関係をコントロールする属性を設定できます。
始める前に:
アプリケーション・モジュールの知識があると役立ちます。詳細は、13.2項「アプリケーション・モジュールの作成と変更」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
既存のアプリケーション・モジュールへ追加するビュー・オブジェクト・インスタンスをカスタマイズするには:
「アプリケーション」ウィンドウで、既存のビュー・インスタンスをカスタマイズするアプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「データ・モデル」リストで、カスタマイズするビュー・オブジェクト・インスタンスを選択し、編集ボタンをクリックします。
「ビュー・インスタンスの編集」ダイアログで、次のいずれかの手順を実行し、「OK」をクリックします。
「ビュー基準」グループ・ボックスで、ビュー・オブジェクト・インスタンスに適用する1つ以上のビュー基準を選択します。選択されたビュー基準は、WHERE
句としてインスタンス問合せに追加されます。ビュー基準の定義の詳細は、5.9項「名前付きビュー基準の処理」を参照してください。
「ビュー基準」グループ・ボックスで、「選択済」リストに追加するビュー基準ごとに、ビュー・インスタンスの必須フィルタとして1つ以上のビュー基準を選択します。現在選択されているビュー基準を常にビュー・インスタンスに適用する必要がある場合は、そのビュー基準の「必須」チェック・ボックスを選択します。通常、複数のビュー基準が1つのビュー・インスタンスに適用される場合、1つがデフォルトのビュー基準となり常に適用されます。必須ビュー基準は、アプリケーションがプログラムによってビュー基準を適用する(たとえばapplyViewCriteria()
を使用)場合でも、引き続きビュー基準リストに適用されます。
「バインド・パラメータ値」グループ・ボックスで、定義済のビュー基準を適用する際にインスタンスで使用する値を入力します。バインド変数の定義の詳細は、5.10項「バインド変数の使用」を参照してください。
図13-8は、「ビュー・インスタンスの編集」ダイアログでFilterByTitleIdVC
を選択し、SalesPeople
ビュー・インスタンスを開いた状態を示しています。バインド変数TitleIdBind
はデフォルト値の2を定義し、これによりSalesPeople
ビュー・インスタンスの制御属性としてTitleId
属性の値が設定されます。ビュー基準フィルタによって設定した制御属性により、一致するIDのビュー行のみを取得できます。
ビュー・オブジェクト・コンポーネントのインスタンスを追加して、アプリケーション・モジュールのデータ・モデルを定義します。図13-9は、BackOfficeAppModule
アプリケーション・モジュールのJDeveloperビジネス・コンポーネント・ダイアグラムを示しています。
例に示したアプリケーション・モジュールにはCustomerVO
ビュー・オブジェクト・コンポーネントの2つのインスタンスが含まれています。 メンバー名のCustomer
と、それを区別するAnotherCustomer
です。実行時には両方のインスタンスが同一のCustomerVO
ビュー・オブジェクト・コンポーネント定義を共有します。これにより、同じ属性構造とビュー・オブジェクト動作を持つようになります。ただし、それぞれを個別に使用して異なるユーザーのデータを取得できます。たとえばWHERE
句やバインド変数の追加フィルタなど、一部の実行プロパティは2つのインスタンスで異なっている場合があります。
例13-1は、BackOfficeAppModule
アプリケーション・モジュールにより、アプリケーション・モジュールのメンバー・ビュー・オブジェクト・インスタンスがそのXMLドキュメント・ファイルで定義される様子を示しています。
新しいアプリケーション・モジュールを作成した後、「アプリケーション・モジュールの編集」ダイアログを使用してその設定を編集できます。エディタを起動するには、「アプリケーション」ウィンドウでアプリケーション・モジュール・ノードを右クリックして「開く」を選択するか、アプリケーション・モジュールをダブルクリックします。エディタの様々なページを開き、データ・モデル、ネストされたアプリケーション・モジュールの参照、Java生成の設定、クライアント・インタフェース・メソッド、実行時インスタンス化動作、およびカスタム・プロパティを調整できます。
アプリケーション・モジュール名を編集する場合、Oracle Application Development Framework (Oracle ADF)が定義している予約語以外の名前を選択してください。特に、アプリケーション・モジュールの名前に基づいてJDeveloperによって自動的に割り当てられるデータ・コントロールの使用名では、予約語は無効になります。Fusion Webアプリケーションでは、予約語はdata
、bindings
、security
およびadfContext
で構成されます。たとえば、アプリケーション・モジュールの名前にはdata
を使用しないでください。予約語と競合するIDのデータ・コントロールの使用名が作成されると、実行時にアプリケーションからデータ・コントロール・オブジェクトにアクセスできなくなる場合があり、ランタイムClassCastException
のエラーが発生することがあります。
予約語はアンダースコア(_
)文字で始まる場合が多いため、名前が競合しないように、アプリケーション・モジュール名の先頭にはアンダースコアを使用しないでください。
アプリケーション・モジュール名に予約語が含まれる場合や、予約語の大文字と小文字を変更した名前が使用されている場合は、競合は発生しません。たとえば、Product_Data
、Product_data
またはData
は、全体の名前が予約語のdata
とは一致しないため、すべて有効なアプリケーション・モジュール名です。
アプリケーション・モジュールは、「データ・コントロール」パネルにデフォルトでAppModuleName
DataControl
という名前のデータ・コントロールとして表示されます。ユーザー・インタフェース・デザイナでは、「データ・コントロール」パネルを使用して、アプリケーション・モジュールからアプリケーションのWebページにデータをバインドします。たとえば、アプリケーション・モジュールの名前がSummitAppModule
の場合、「データ・コントロール」パネルには、SummitAppModuleDataControl
という名前のデータ・コントロールが表示されます。デフォルトのデータ・コントロール名を変更して、名前を短くしたり適切な名前を指定することもできます。
ユーザー・インタフェース・デザイナでデータ・コントロールを操作すると、アプリケーション・モジュールのデータ・コントロール名は、ユーザー・インタフェース・プロジェクトのDataBindings.cpx
ファイルおよび各データ・バインディング・ページ定義のXMLファイルに表示されます。また、アプリケーション・モジュールのサービス・インタフェースをプログラム的に操作する必要がある場合は、データ・コントロール名をコード内で参照できます。このため、アプリケーション・モジュールの名前を変更する場合は、ビュー・レイヤーを作成する前に変更する必要があります。
アプリケーション・モジュールのデータ・コントロールの詳細は、第17章「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。
注意: 1つ以上のページですでに参照した後にアプリケーション・モジュールのデータ・コントロール名を変更する場合は、データ・コントロール名が参照されているページ定義ファイルと |
アプリケーション・モジュールのデータ・コントロール名を変更するには:
「アプリケーション」ウィンドウで、データ・コントロール名を編集するアプリケーション・モジュールをダブルクリックします。
「プロパティ」ウィンドウで、「その他」セクションを開き、「データ・コントロール名」フィールドに適したデータ・コントロール名を入力します。
アプリケーション・モジュールに関する一般的な疑問は、「アプリケーション・モジュールがどの位の大きさになるのか」というものです。つまり、「大規模なアプリケーション・モジュールを1つ作成してエンタープライズ・アプリケーションのデータ・モデル全体を含めるか、より小規模なアプリケーション・モジュールを多数作成して機能に応じてアプリケーションを区分化するか」という問題です。答えは状況によって異なります。
一般に、アプリケーション・モジュールのサイズは、そのモジュールでの対応が想定される特定のユースケースを十分にサポートできる大きさにする必要があります。13.4項「ネストされたアプリケーション・モジュールの定義」に記載されたネスト機能を使用して、微調整したアプリケーション・モジュール・コンポーネントを集めて構築することができます。複雑なビジネス・アプリケーションのユースケースは実際には1つではないので、Oracle ADFを使用して実装された複雑なビジネス・アプリケーションは複数のアプリケーション・モジュールから構成されるのが一般的です。
実際のプラクティスでは、必要なモジュール化タイプをサポートするための粒度を選択する場合があります。たとえば、個別のデータ・ソースをサポートする必要や個別のチューニング・オプションを構成する必要がある場合は、どちらも複数のアプリケーション・モジュールを作成する方が適しています。または、主要なユースケースが1つ、バックエンドでサポートしているユースケースが1つの小規模アプリケーションの場合、アプリケーション・モジュールを2つ作成できます。ただし、簡潔にするため、数個のビュー・オブジェクトのみを含んだ2つ目のアプリケーション・モジュールを作成するのではなく、両方のユースケースを組み合せることもできます。
その他の状況では、2つ以上のルート・アプリケーション・モジュールの作成を指定することがあります。たとえば、ユーザー・セッションごとに2つ以上のトランザクションをサポートする必要がある場合は、複数のアプリケーション・モジュールを作成できます。または、24.3項「タスク・フローのトランザクションの管理」に説明されているとおり、データ・コントロール・スコープとタスク・フローを操作してトランザクションを管理できます。
アプリケーション・モジュールの設計時に、ビュー・オブジェクト・コンポーネントのインスタンスを使用してそのデータ・モデルを定義します。ユーザー・インタフェースに含まれるButton
コンポーネントの2つのインスタンスに、区別するためのmyButton
およびanotherButton
というメンバー名が付けられているように、アプリケーション・モジュールにも、CustomerVO
ビュー・オブジェクト・コンポーネントの2つのインスタンスに、区別するためのCustomerList
およびAnotherCustomerList
というメンバー名が付けられています。
データ・モデル・プロジェクトを初期化してADFビジネス・コンポーネントを使用する場合、データベース接続の詳細を指定するように求められます。ADFビジネス・コンポーネント・ウィザードを実行し、データベースの表やビューを操作してビジネス・コンポーネントを作成する前に、データベース接続を指定する必要があります。接続の詳細を指定すると、JDeveloperにより、現在のプロジェクトで作成されたすべてのアプリケーション・モジュールのデフォルトのランタイム接続として使用されるJava Database Connectivity (JDBC)データソースも作成されます。「構成の編集」ダイアログを使用すると、各アプリケーション・モジュールの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データソースがすべてのアプリケーション・モジュール構成の選択肢としてお薦されているのは、このような理由によります。図13-10に、デフォルトが選択された「構成の編集」ダイアログを示します。
例13-2は、Fusion Webアプリケーションのweb.xml
ファイルの<resource-ref>
タグを示しています。これらは、jdbc/Summit_adfDS
およびjdbc/Summit_adfCoreDS
という名前の2つの論理データソースを定義しています。「構成の編集」ダイアログは、「JDBCデータソース名」フィールドの接頭辞java:comp/env
の後ろにあるこの論理接続名を参照します。たとえば、同じFusion WebアプリケーションのJDBCデータ・ソース名は選択可能な値java:comp/env/jdbc/summit_adfDS
を表示します。このように、「データソース名」フィールドには、使用可能なすべてのアプリケーション・リソース接続名のJNDI名が事前に取り込まれます。
例13-2 web.xmlに定義されている論理データソース・リソース名
<!-- 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/
applicationConnectName
DS
の検索によって、jdbc/
applicationConnectName
DS
という名前のグローバル・データ・ソースの検索を行うように設定されています。したがって、この規則に従うことで、アプリケーション固有のデータ・ソースを使用してアプリケーションをJDeveloperで実行する場合や、グローバル・データ・ソースを使用してデプロイ済のスタンドアロン・サーバー上で実行する場合に、単一のデータ・ソース接続名を正しく機能させることができます。
注意: 冗長なデータベースやバックエンドとしてのOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、アプリケーションはマルチ・データ・ソースを使用します。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースと非マルチ・データ・ソースでネーミング規則は同じになります。これによって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するマルチ・データ・ソースの構成の詳細は、『高可用性ガイド』を参照してください。 |
アプリケーション・モジュール構成に使用できるもう1つの接続タイプは、JDBC URL接続です。これは、アプリケーション・モジュールを含むプロジェクトの「プロジェクト・プロパティ」ダイアログの「ビジネス・コンポーネント」ページに設定されている名前付きの接続の定義に基づいています。図13-11は、JDBC URL接続を使用する構成で、このセクションの表示内容を示しています。
注意: Oracle以外のJDBCドライバを使用している場合は、「構成の編集」ダイアログの「プロパティ」ページで、ドライバに適したプロパティの設定を確認し、実行時の例外を回避します。 |
注意: データベース接続プールの使用方法およびチューニング方法の詳細は、50.1.1.2項「データベース接続プール」および50.2.9,項「データベース接続プールのパラメータに関する必知事項」を参照してください。 |
「構成の編集」ダイアログで接続タイプを選択すると、JDeveloperにより、アプリケーション・モジュールのXMLドキュメントに関連する./common
サブディレクトリにあるアプリケーション・モジュール構成ファイル、bc4j.xcfg
が更新されます。このファイルは、1つのJavaパッケージ内の全アプリケーション・モジュールの構成を定義しています。たとえば、コアSummit ADFサンプル・アプリケーションのModel
プロジェクトの./classes/oracle/summit/model/services/common
ディレクトリにあるbc4j.xcfg
ファイルを見ると、そのアプリケーション・モジュール用に名前の付いた構成があることがわかります。
bc4j.xcfg
ファイルで定義された構成により、Fusion Webアプリケーションはデプロイ済の特定のアプリケーション・モジュールとの対話が可能になります。bc4j.xcfg
ファイルには、アプリケーション・モジュールの接続タイプに加えて、アプリケーション・モジュール名に関するメタデータ情報と、アプリケーション・モジュールに構成されたランタイム・パラメータが含まれています。名前付き接続タイプのアプリケーション・リソース・データベース接続の詳細は、「アプリケーション」ウィンドウの「接続」ノードに定義され、アプリケーションのconnection.xml
ファイルに格納されています。
例13-3に、コアSummit ADFサンプル・アプリケーションのbc4j.xcfg
ファイル例を示します。SummitAppModuleLocal
およびSummitAppModule
の構成は、どちらもJDBCDataSource
属性内のデータソース(名前はSummit_adfDS
)を参照します。各構成のJDBCDataSource
属性には、アプリケーション・リソース接続名のJNDI名を、java:comp/env/jdbc/
applicationConnectName
DS
の形式で指定します。ここで、applicationConnectName
は、JDeveloperで定義されたアプリケーション・リソース・データベース接続名(この場合はSummit_adf
)です。このJNDIネーミング規則(アプリケーション固有ネームスペースjava:comp/env/jdbc/
およびDS
をアプリケーション・リソース・データベース接続名に付加したもの)により、デプロイされたFusion Webアプリケーションは、変更を加えなくてもアプリケーションのグローバル・データソースを使用してOracle WebLogic Server上で実行されます。グローバル・データ・ソースは通常、アプリケーション・サーバー管理者がOracle WebLogic Server管理コンソールを使用して定義します。
例13-3 bc4j.xcfgファイルのアプリケーション・モジュール・データベース構成
<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
ファイルにappModuleName
Local
という名前のデフォルトの構成も追加します。bc4j.xcfg
ファイルは「アプリケーション」ウィンドウには表示されません。JDeveloperでbc4j.xcfg
ファイルを表示するには、アプリケーション・モジュールの概要エディタの「構成」ページを開き、bc4j.xcfg
へのリンクをクリックします。デフォルト設定を表示したり、アプリケーション・モジュールのランタイム構成の設定を変更するには、概要エディタで構成を選択し「編集」ボタンをクリックして図13-12に示す「構成の編集」ダイアログを開きます。
始める前に:
アプリケーション・モジュール・データベース接続に関する知識があると役立つ場合があります。詳細は、13.3項「アプリケーション・モジュールのデータベース接続の構成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
アプリケーション・モジュールの構成を管理するには:
「アプリケーション」ウィンドウで、構成を編集するアプリケーション・モジュールをダブルクリックします。
概要エディタで、「構成」ナビゲーション・タブをクリックします。
「構成」ページで、編集する構成を選択し、「選択した構成オブジェクトの編集」ボタンをクリックします。
「構成」ページには次の3つのデフォルト構成が表示される可能性があります。
appModuleName
Local
: アプリケーション・モジュールを作成すると、自動的にローカル構成が1つ定義されます。テスト目的でアプリケーション・モジュールのランタイム・プロパティを変更する場合などは、新しいローカル構成を作成してください。
appModuleName
Shared
: 共有アプリケーション・モジュール構成が存在するのは、データ・モデル・プロジェクトの「プロジェクト・プロパティ」ダイアログで共有アプリケーション・モジュールの名前付きインスタンスが定義されている場合のみです。共有アプリケーション・モジュールは、アプリケーション全体で静的データのリストを再利用する場合に、ビュー・インスタンスをグループ化したアプリケーション・モジュールです。たとえば、共有アプリケーション・モジュールを定義して、国リストなどの参照データにアクセスするビュー・インスタンスをグループ化できます。
appModuleName
Service
(サービス・インタフェースのタイプSI): サービス・インタフェース構成が存在するのは、アプリケーション・モジュールの概要エディタの「サービス・インタフェース」ページでサービス・インタフェース(Webサービス実装ラッパー)が定義されている場合のみです。Webサービスとして公開されているアプリケーション・モジュールでは、アプリケーション・モジュールをコンポジット・アプリケーションに組み込んで、Webサービス・クライアントからデータ・アクセスやメソッド呼出しができます。同じアプリケーション・モジュールで、ADFデータ・コントロールおよびWebサービス・クライアントを使用する対話型のWebユーザー・インタフェースをサポートできます。
「構成の編集」ダイアログで、目的の実行時プロパティを編集し、「OK」をクリックして構成の変更を保存します。
アプリケーションの開発時、多数の異なるユーザーやスキーマを切り替える場合があります。これには、そのビジネス・コンポーネントを含むプロジェクトのデータベース接続プロパティを変更します。選択を行うと、プロジェクトのbc4j.xcfg
ファイルで、JDBC URLタイプ接続を指定する各構成の接続文字列が自動的に更新されます。
始める前に:
アプリケーション・モジュール・データベース接続に関する知識があると役立つ場合があります。詳細は、13.3項「アプリケーション・モジュールのデータベース接続の構成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
アプリケーション・モジュールの構成で使用する接続を変更するには:
「アプリケーション」ウィンドウで、アプリケーション・モジュールが含まれているプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「接続」ドロップダウン・リストから「ADFビジネス・コンポーネント」を選択し、目的の接続を選択して「編集」アイコンをクリックします。
「データベース接続の編集」ダイアログで、必要な変更を行います。
「OK」をクリックします。
アプリケーション・モジュールでは、高レベルな機能により複数のビジネス・ワークフローに共通なサブ機能が再使用される、ユースケースのモジュール性を模倣するソフトウェア・コンポーネントを作成する機能をサポートしています。このモジュール性は、他のアプリケーション・モジュールのインスタンスを使用してアセンブルする複合アプリケーション・モジュールを定義することで実装できます。このタスクはアプリケーション・モジュールのネストと呼ばれています。つまり、アプリケーション・モジュールにはビュー・オブジェクト・インスタンスだけでなく、1つ以上の他のアプリケーション・モジュール・インスタンスを(論理的に)含めることができます。最も外側に含まれているアプリケーション・モジュールは、ルート・アプリケーション・モジュールと呼ばれています。
ネストされたアプリケーション・モジュール定義の宣言的サポートは、図13-14に示すように、アプリケーション・モジュールの概要エディタから使用できます。アプリケーション・モジュールのAPIでも、実行時のアプリケーション・モジュールのネストがサポートされています。
アプリケーション・モジュールのインスタンスを別のアプリケーションにネストするときは、ビュー・オブジェクト・インスタンスをそのデータ・モデルに集約するのみならず、そこで定義されているカスタム・サービス・メソッドも集約します。アプリケーション・モジュールのインスタンスを別のアプリケーション・モジュール内でネストまたは再利用するこの機能は、大規模で実用的なアプリケーション・システムを実装するための、ADFビジネス・コンポーネントの重要な設計要素です。
アプリケーション・モジュールがエンド・ユーザーのユースケースまたはワークフローを表していることを考えると、一部の共有のモジュール化ユースケースで必要なデータを提供するアプリケーション・モジュールを作成でき、より複雑なユースケースをサポートするように設計されている、より複雑な別のアプリケーション・モジュール内でそれらのアプリケーション・モジュールを再使用できます。たとえば、アプリケーション・モジュールBackOfficeAM
およびCustomerSelfServiceAM
を作成した後に、この両方のサービスを新しいコンポジット・サービス・アプリケーション・モジュールの不可欠な部分として使用するアプリケーションの作成が必要になったとします。図13-13は、このコンポジット・サービスがJDeveloperのビジネス・コンポーネント・ダイアグラムでどのように表示されるかを示しています。この図に示すように、SummitAppModule
などのアプリケーション・モジュールには、ビュー・オブジェクト・インスタンスとアプリケーション・モジュール・インスタンスを含めることができます。
既存のアプリケーション・モジュールのインスタンスをネストする複合ルート・アプリケーション・モジュールを指定するには、アプリケーション・モジュールの概要エディタを使用します。(アプリケーション・モジュール・インスタンスに含まれる)ネストされたすべてのコンポーネント・インスタンスでは、それらのインスタンスを再使用するルート・アプリケーション・モジュールと同じトランザクションとエンティティ・オブジェクト・キャッシュが共有されます。
ヒント: ネストされたアプリケーション・モジュールをアプリケーションで利用する場合は、17.3.1.4項「データ・コントロール」パネルでのネストされたアプリケーション・モジュールの表示」を必ず参照してください。また、これらのモジュールを含むデータ・バインディングの実行時によく発生する問題を回避してください。 |
始める前に:
ネストされたアプリケーション・モジュールに関する知識があると役立つ場合があります。詳細は、13.4項「ネストされたアプリケーション・モジュールの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
ネストされたアプリケーション・モジュールを定義するには:
「アプリケーション」ウィンドウで、ネストされたアプリケーション・モジュールを定義するルート・アプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
データ・モデル・コンポーネント」ページの「アプリケーション・モジュール・インスタンス」セクションを展開し、「使用可能」リストで、データ・モデルに追加するアプリケーション・モジュールを選択します。
リストの下の「新規アプリケーション・モジュール・インスタンス」フィールドに、データ・モデルに追加するネストされたアプリケーション・モジュールを識別する際に使用される名前が示されます。
アプリケーション・モジュールを追加する前に名前を変更するには、「新規アプリケーション・モジュール・インスタンス」フィールドに別の名前を入力します。
目的のアプリケーション・モジュールを選択し、「選択済」リストに移動します。
図13-14では、アプリケーション・モジュールBackOfficeAM
およびCustomerSelfServiceAM
を「選択済」リストに移動しています。
実行時に、アプリケーションはメインの、またはルートと呼ばれている、アプリケーション・モジュールを使用します。どのアプリケーション・モジュールもルート・アプリケーション・モジュールとして使用できますが、実際には、単純なCRUDアプリケーションを作成している場合を除き、より複雑なエンド・ユーザーのユースケースに対応するアプリケーション・モジュールがルートとして使用されます。ルート・アプリケーション・モジュールに別のアプリケーション・モジュールがネストされている場合、そのモジュールはすべてルート・アプリケーション・モジュールのトランザクションに関与し、同じデータベース接続および単一のエンティティ・キャッシュ・セットを共有します。この共有は、ルート・アプリケーション・モジュールおよびそのTransaction
オブジェクトによって自動的に処理されます。
また、トランザクション境界を宣言的に管理するためADFバインド・タスク・フローを使用してアプリケーションを作成する場合、Oracle ADFフレームワークにより実行時にタスク・フローで使用されるアプリケーション・モジュールが自動的にネストされます。バインド・タスク・フローとトランザクションの詳細は、24.3項「タスク・フローのトランザクションの管理」を参照してください。
ビジネス・サービスのデータ・モデルを開発する際、多くの場合、UMLモデルを使用して視覚化すると便利です。JDeveloperでは、他の開発者が参照できるアプリケーション・モジュール用のダイアグラムを簡単に作成できます。
アプリケーション・モジュールの編集、表示オプションの制御、メソッド名のフィルタ処理、関連するオブジェクトやファイルの表示、アプリケーションの公開、Oracle ADFモデル・テスターの起動など、多数のタスクをダイアグラム上で直接実行できます。
アプリケーション・モジュールのダイアグラムを作成するには、「新規ギャラリ」から使用できる「ビジネス・コンポーネント・ダイアグラムの作成」ダイアログを使用します。
始める前に:
UMLモデル・ダイアグラムについて理解しておくと役立つ場合があります。詳細は、13.5項「ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュールのダイアグラムを作成するには:
「アプリケーション」ウィンドウで、ダイアグラムを作成するデータ・モデル・プロジェクトを右クリックし、「新規」→「ビジネス・コンポーネント・ダイアグラム」を選択します。
「ビジネス・コンポーネントの作成」ダイアログで、ダイアグラム名と、ダイアグラムの作成先のパッケージ名を入力します。
「OK」をクリックすると、空のダイアグラムが作成され、ダイアグラマを開きます。
「アプリケーション」ウィンドウで、目的のアプリケーション・モジュールを選択し、それをダイアグラム上にドロップします。
アプリケーション・モジュール・ダイアグラム内で、目的のダイアグラム・ノードを右クリックして「ビジュアル・プロパティ」を選択し、「ビジュアル・プロパティの編集」ダイアログで必要な変更を加えます。
ダイアグラム・エディタで、アプリケーション・モジュール・ダイアグラム以外の任意の場所をクリックし、ダイアグラム・エディタの「プロパティ」ウィンドウを表示して次の変更を加えます。
レイアウト・スタイルの設定
フォントの変更
グリッドをオフ
これらの手順の完了後、ダイアグラムは図13-15のようになります。
ビジネス・コンポーネント・ダイアグラムを作成すると、ダイアグラムが格納されているパッケージ名と一致するプロジェクトのモデル・パスのサブディレクトリに、ダイアグラムを示す.adfbc_diagram
ファイルが作成されます。
デフォルトでは、「アプリケーション」ウィンドウによってプロジェクト・コンテンツのパスの表示が統一され、ソース・パスのADFコンポーネントおよびJavaファイルがプロジェクト・モデル・パスのUMLモデル・アーティファクトと同じパッケージ・ツリーに表示されます。「アプリケーション」ウィンドウで「アプリケーション・ウィンドウのオプション」→「ディレクトリの表示」ツールバー・オプションを使用して、プロジェクト・コンテンツのユニファイド・ディレクトリ・ビューとより明確なディレクトリ・パス・ビューを切り替えられます。
ビジネス・コンポーネントのUMLダイアグラムは、アプリケーション・モジュールをダイアグラムにドロップした時点の状態を示す単なる静的な図ではありません。むしろ、UMLダイアグラムは、現在のコンポーネント定義をUMLベースでレンダリングした図であるため、常に現在の状況を示しています。UMLダイアグラムは、視覚化を可能にするのみならず、視覚的なナビゲーションおよび編集ツールでもあります。
ポップアップ・メニューから「プロパティ」を選択(またはアプリケーション・モジュールをダブルクリック)すると、任意のアプリケーション・モジュールの概要エディタを起動できます。
また、ビュー・オブジェクト・インスタンス名の変更、ビュー・オブジェクト定義を「アプリケーション」ウィンドウからデータ・モデルにドロップすることによる新しいビュー・オブジェクト・インスタンスの作成、[Del]キーを押すことによるビュー・オブジェクト・インスタンスの削除など、いくつかのアプリケーション・モジュール編集タスクもダイアグラム上で直接実行できます。
注意: コンポーネントをダイアグラムから削除すると、その表示のダイアグラム画面からの削除のみが行われます。コンポーネントとクラスはファイル・システムと「アプリケーション」ウィンドウ内に存続します。 |
ダイアグラムでアプリケーション・モジュールを表示後、「ビジュアル・プロパティの編集」ダイアログを使用して表示オプションを制御します。ダイアグラムのダイアログを表示するには、ダイアグラム内でアプリケーション・モジュール・ノードを右クリックし、「ビジュアル・プロパティ」を選択します。
「表示」ページで、プロパティを次のように切り替えます。
パッケージを表示 - パッケージ名を表示
メソッドの表示 - サービス・メソッドを表示
ステレオタイプの表示 - オブジェクトの型を表示(「<<application module>>
」など)
使用方法の表示 - 現在のプロジェクトの他のアプリケーション・モジュールによるすべての使用を表示
「メソッド」ページでは、ダイアグラムに求められる詳細のレベルに応じて次の設定を変更します。
可視性の表示(「public」、「private」など)
メソッドの戻りタイプの表示
staticメソッドの表示
図13-16の「ビジュアル・プロパティの編集」ダイアログの設定に示すように、デフォルトでは、アプリケーション・モジュールのすべての操作が表示されます。
ダイアグラムのコンテキスト・メニューでは、「表示モード」に対して次を選択することもできます。
圧縮 - アイコンおよび名前のみを表示
シンボル - サービス操作を表示
展開済 - 操作およびデータ・モデルを表示(デフォルト)
デフォルトでは、アプリケーション・モジュールのメソッドを表示すると、ダイアグラムにすべてのメソッドが表示されます。オーバーライドされたフレームワーク・メソッドとして認識されるメソッドは、すべて「Framework」操作カテゴリに表示されます。他のメソッドは、「Business」メソッド・カテゴリに表示されます。
「ビジュアル・プロパティの編集」ダイアログの「メソッド」 ページの「対象外のメソッド・フィルタ」設定は、ダイアグラムに表示したくないメソッドを除外するために使用できる正規表現です。たとえば、「対象外のメソッド・フィルタ」を次のように設定します。
findLoggedInUser.*|retrieveOrder.*|get.*
この場合、次のアプリケーション・モジュール・メソッドをすべてフィルタ処理できます。
findLoggedInUserByEmail
retrieveOrderById
生成されたビュー・オブジェクトのgetterメソッド全般
ダイアグラム上でアプリケーション・モジュール(またはそのデータ・モデル内の任意の個別ビュー・オブジェクト・インスタンス・セット)の選択後、「表示」→「関連する要素」をコンテキスト・メニューから選択し、ダイアグラムに関連するコンポーネントを表示できます。同様に、「表示」→「実装ファイル」を選択することで、アプリケーション・モジュールを実装するファイルをダイアグラムに含むことができます。求められる詳細のレベルがダイアグラムに追加されるまで、表示されている追加ダイアグラム要素に対して前述のオプションを繰り返し使用できます。
図13-17は、アプリケーション・モジュールの実装ファイルを表示した図を示しています。アプリケーション・モジュールの実装クラスの関連要素(AppModuleImpl
)が表示されています。また、アプリケーション・モジュールと実装クラス間の依存性を示す追加の線も表示されています。特定のカスタム・インタフェースにアプリケーション・モジュール・インスタンスをキャストした場合でも、図のように表示されます。
ダイアグラムをPNG
、JPG
、SVG
または圧縮されたSVG
書式で公開するには、ダイアグラム上でポップアップ・メニューから「ダイアグラムの公開」を選択します。
Fusion Webアプリケーションとの対話中に、エンド・ユーザーには次のような状況が発生する場合があります。
同じページを複数回表示する場合に、迅速なレスポンスを期待
完了までに多数のページを表示する必要がある論理作業ユニットを実行
未保存の保留中の変更内容の部分的なロールバックの実行を要求
サーバー・ファームのアプリケーション・サーバー障害による、保存前の保留中の変更への不可抗力的な被害
アプリケーション・モジュール・プーリング機能および状態管理機能では、これらの要件に対処するスケーラブルで高パフォーマンスの実装を簡略化します。
注意: ADFバインド・タスク・フローは、トランザクションの作業ユニットを表します。タスク・フローのオプションを指定して、トランザクションの処理方法を決定できます。ADFバインド・タスク・フローの宣言的な機能の詳細は、24.3項「タスク・フローのトランザクションの管理」を参照してください。 |
実行する状態管理機能をシミュレートするために、アプリケーション・モジュールでOracle ADFモデル・テスターの2つのインスタンスを起動できます。
始める前に:
状態管理に関する知識があると役立つ場合があります。詳細は、13.6項「複数ページの作業ユニットのサポート」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
Oracle ADFモデル・テスターを使用してトランザクション状態の受動化をシミュレートするには:
Oracle ADFモデル・テスターを実行し、ビュー・オブジェクト・インスタンスをダブルクリックしてそのデータを問い合せます。
数行のいくつかの属性の現在値をメモします。
これらの属性が別々の値を持つようにこれらの行に更新します。ただし、変更はコミットしないでください。
Oracle ADFモデル・テスターのメイン・メニューから、「ファイル」→「トランザクション状態の保存」を選択します。
「受動化されたトランザクション状態」ダイアログが開き、トランザクションID番号が表示されます。この番号をメモします。
Oracle ADFモデル・テスターを完全に終了します。
Oracle ADFモデル・テスターを再起動し、同じビュー・オブジェクト・インスタンスをダブルクリックしてそのデータを問い合せます。
データは変更されない点に注意してください。データから問い合せたデータは、データベースの現在の状態を示し、前述の変更は反映されていません。
Oracle ADFモデル・テスターのメイン・メニューから、「ファイル」→「トランザクション状態のリストア」を選択し、ステップ4でメモしたトランザクションIDを入力します。
この時点で、保留中の変更が、変更した行に再反映されます。ここでトランザクションをコミットすると、変更内容はデータベースに永続的に保存されます。
アプリケーション・モジュールをそのビジネス・サービスとして利用するアプリケーションを作成すると、そのアプリケーションでは自動アプリケーション・モジュール・プーリング機能を使用できます。この機能では、アプリケーションに対するエンド・ユーザーの負荷(ロード)の日中の変化に応じて増減するアプリケーション・モジュール・インスタンスの構成可能なセットを管理します。アプリケーション・ユーザー・インタフェースとのエンド・ユーザーの対話に特有の思考時間の性質により、プール内のアプリケーション・モジュール・インスタンスの数は、システムを使用しているアクティブ・ユーザーの合計数より少なくなる場合があります。
図13-18に示すように、あるエンド・ユーザーがアプリケーションの複数ページを表示して論理タスクを実行する場合、各ページ・リクエストに対し、プール内のアプリケーション・モジュール・インスタンスがその1リクエストの存続時間中にプールから自動的に取得されます。リクエストの最後に、インスタンスはプールに自動的に戻され、別のユーザー・セッションで使用可能になります。エンド・ユーザーの作業をアプリケーション・サーバーの障害から保護するために、アプリケーション・モジュールでは、そのエンティティ・キャッシュ内の保留中の変更セットを示すXMLスナップショットを保存することで、その変更セットを永続ストアに格納する機能をサポートしています。スケーラビリティ上の理由から、この状態スナップショットは通常、アプリケーション・データを含むデータベース・スキーマとは別の状態管理スキーマに保存されます。
プーリング・アルゴリズムではチューニング可能な最適化が行え、特定数のアプリケーション・モジュール・インスタンスが、プールに戻された最後のユーザー・セッションとの「スティッキー」な状態を維持しようとします。最適化は保証されていませんが、ユーザーが最適化による利益を得ることができれば、システム・ローダーが許容する限り、プール内の同じアプリケーション・モジュール・インスタンスを継続的に使用します。負荷が重すぎる場合、プーリング・アルゴリズムはプール内で使用可能な任意のインスタンスを使用してユーザーのリクエストに応え、その論理作業単位の凍結スナップショットを永続ストアから再構築して、アプリケーション・モジュールの新しいインスタンスが前回途中になったところから継続できるようにします。エンド・ユーザーは変更をコミットまたはロールバックするまで、この方法で作業を継続します。
アプリケーション・モジュールはこれらの機能を使用し、完全にステートレスなアプリケーションに近い実行時パフォーマンスを実現するアーキテクチャにおいて、複数ページのワークフローを簡単に処理できる、生産性の高いステートフルなパラダイムを実現します。これらのアプリケーション・モジュール機能の詳細は第49章「Fusion Webアプリケーションでの状態管理の使用」を、チューニング方法の詳細は第50章「アプリケーション・モジュール・プールと接続プールのチューニング」を参照してください。
アプリケーション・モジュールでは、カスタムJavaコードを必要とせずに、そのビュー・オブジェクト・インスタンスのデータ・モデルをクライアントに公開できます。このため、クライアント・コードではoracle.jbo
パッケージのApplicationModule
、ViewObject
、RowSet
およびRow
というインタフェースを使用して、データ・モデル内のビュー・オブジェクトを直接操作できます。ただし、クライアント・コードで自由にビュー・オブジェクトをプログラミングで操作できても、それが必ずしもベスト・プラクティスではありません。
ビュー・オブジェクトを操作するプログラム的なコードが完全なビジネス・サービス機能を実装するための論理的な特徴を備えている場合、アプリケーション・モジュールのJavaクラスでカスタム・メソッドを記述して、詳細をカプセル化する必要があります。これには次のコードが含まれます。
表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成
集計結果を取得するための、ビュー・オブジェクト行の反復処理
1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行
これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。
コードの目的が、クライアントにより明確に伝わります。
必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。
ビジネス・サービス機能全体の回帰テストを簡略化できます。
クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。
ページ内での論理的ビジネス機能の宣言的起動が可能になります。
カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、まずそのカスタムJavaクラスを有効化する必要があります。IDEレベルの「ビジネス・コンポーネント」のJava生成設定で、アプリケーション・モジュール・クラスが自動的に生成されるように構成されている場合は、カスタム・クラスが発生します。図13-19に示すように、アプリケーション・モジュールにカスタムJavaクラスがあるかどうかが不明な場合は、「アプリケーション」ウィンドウでそのアプリケーション・モジュール・ノードの概要エディタを開きます。エディタの「Javaクラス」ページに、プロジェクトのアプリケーション・モジュール用に生成されたクラスの完全リストが表示されます。他のユーザーによりすでにファイルが作成されているため存在する場合、「Javaクラス」ページには「アプリケーション・モジュール・クラス」として特定された、リンクされたファイル名が表示されます。ソース・エディタで既存ファイルを開くには、対応するファイル名のリンクをクリックします。
プロジェクトにJavaクラスが存在しない場合、アプリケーション・モジュールの概要エディタの「Javaクラス」ページで生成できます。
始める前に:
アプリケーション・モジュールのサービス・メソッドに関する知識があると役立つ場合があります。詳細は、13.7項「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュール・クラスのJavaファイルを生成するには:
「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」ボタンをクリックします。
「Javaオプションの選択」ダイアログで、「アプリケーション・モジュール・クラスの生成」を選択します。
「OK」をクリックします。
「Javaクラス」ページに新しい.java
ファイルが表示されます。
アプリケーション・モジュールのカスタム・クラスを生成すると、JDeveloperではコンポーネントのXMLドキュメント・ファイルと同じディレクトリにファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleName
Impl.java
になります。
アプリケーション・モジュールに対して選択したJava生成オプションは、アプリケーション・モジュールの概要エディタの「Javaクラス」ページに後でアクセスしてもそのまま反映されています。XML定義ファイルの場合と同様、このエディタでどのような変更を行っても、カスタムJavaクラスで生成されたコードは最新の状態に保たれます。後でカスタムJavaファイルが不要になった場合は、「Javaクラス」ページから「Javaオプションの選択」ダイアログを開き、「アプリケーション・モジュール・クラスの生成」の選択を解除すると、プロジェクトからカスタムJavaファイルが削除されます。
デフォルトでは、アプリケーション・モジュールのJavaクラスは、最初に有効化した際、例13-4のようになります。それには、データ・モデルの各ビュー・オブジェクト・インスタンス用のgetterメソッドが含まれます。
例13-4 デフォルトで生成されるアプリケーション・モジュールのコード
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
クラスを拡張します。
カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、アプリケーション・モジュールのカスタム・クラスに移動して、新しいメソッドのJavaコードをアプリケーション・モジュールのJava実装クラスに入力します。次のガイドラインを使用して、メソッドに適切な可視性を判断してください。
メソッドをこのコンポーネントの実装内でヘルパー・メソッドとしてのみ使用する場合は、メソッドをprivate
にします。
アプリケーション・モジュールの最終的なサブクラスでこのメソッドを起動またはオーバーライドできるようにする場合は、メソッドをprotected
にします。
クライアントによる起動を可能にする場合は、public
にする必要があります。
注意: この章のアプリケーション・モジュールの例では強く型付けされたカスタム・エンティティ・オブジェクト・クラスを使用しています。これらのエンティティ・クラスの作成方法の詳細は、第4章「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」を参照してください。 |
例13-5は、AppModule
アプリケーション・モジュールのAppModuleImpl.java
クラスでのprivate retrieveOrderById()
ヘルパー・メソッドを示しています。ここでは、関連するエンティティ定義にアクセスするためにOrdEOImpl
エンティティ・オブジェクト・クラスのstatic
getDefinitionObject()
メソッドが使用され、注文の検索に適したKeyオブジェクトを作成するためにエンティティ・オブジェクト・クラスでcreatePrimaryKey()
メソッドが使用され、エンティティ行をエンティティ・キャッシュで検索するためにエンティティ定義でfindByPrimaryKey()
メソッドが使用されています。このメソッドからは、強く型付けされたOrdersImpl
クラス(Orders
エンティティ・オブジェクトのカスタムJavaクラス)のインスタンスが戻されます。
例13-5 カスタム・アプリケーション・モジュール・クラスのprivateヘルパー・メソッド
// 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); }
例13-6は、作成する注文のIDをコール元が渡すことを可能にするpublic findOrderAndCustomer()
メソッドを示しています。OrdersImpl
エンティティ・オブジェクト・クラスのgetCustomer()
メソッドを使用して、関連するエンティティ定義にアクセスします。
例13-6 カスタム・アプリケーション・モジュール・クラスのpublicメソッド
/* * 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; } }
カスタム・アプリケーション・モジュールのメソッドをテストする準備ができたら、JDeveloperを使用してJUnitテスト・ケースを生成できます。JUnitでは、oracle.jbo package
で使用可能な任意のプログラムのAPIを使用して、アプリケーション・モジュールの操作およびカスタム・メソッドを起動が可能です。ADFビジネス・コンポーネントでのJUnit使用の詳細は、42.11項「JUnitを使用した回帰テスト」を参照してください。
JUnitテスト・ケースの代替方法として、カスタム・アプリケーション・モジュール・メソッドをテストする一般的な方法は、簡単なテスト・ケースを作成することです。たとえば、テスト用のコードをオブジェクトに作成し、そのコードをstatic main()
メソッドに含めます。例13-7は、これから記述するサンプル・メソッドをテストするために、カスタム・アプリケーション・モジュール・クラスに追加できるサンプルのmain()
メソッドを示しています。Configuration
オブジェクトを使用して(8.4.2項「コマンドラインJavaテスト・クライアントの作成方法」を参照)、テスト用のアプリケーション・モジュールをインスタンス化および操作します。
注意:
|
例13-7のコードを見ると、これまでの例で作成したメソッドを使用して次が実行されていることがわかります。
注文101の合計を取得します。
注文101の顧客名を取得します。
101の注文ステータスを「Y」の値に設定します。
例13-7 カスタム・アプリケーション・モジュールを内部からテストするmainメソッドのサンプル
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); } }
カスタム・アプリケーション・モジュール・クラスを実行すると、例13-7のmain()
メソッドがコールされ、次の出力が表示されます。
anonymous Customer for Order # 101 = Customer: Kam's Sporting Goods, Location: Hong Kong
注意: カスタム・アプリケーション・モジュールに作成したカスタム・サービスをクライアント・アプリケーションを使用して起動する方法の詳細は、13.9項「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。 |
アプリケーション・ロジックが行セットにアクセスし、プログラムによる反復を実行する場合は必ず、ユーザー・インタフェース・コンポーネントにバインドされている可能性があるので、アプリケーション・モジュールのデータ・モデル内のビュー・オブジェクト・インスタンス、またはこれらのビュー・オブジェクト・インスタンスのビュー・リンク・アクセッサ行セットを扱う際に、セカンダリ行イテレータを使用する必要があります。セカンダリ・イテレータを作成するには、作業対象の行セットに対してcreateRowSetIterator()
メソッドを使用します。使用を修了したら、行セットに対してcloseRowSetIterator()
メソッドを呼び出し、メモリーからセカンダリ・イテレータを削除する必要があります。例13-8には、データ・モデル内のCustomerView1
ビュー・オブジェクト・インスタンスが、ユーザー・インタフェースにバインドされる可能性がある(現在または後で)ため、プログラムによる反復用に、セカンダリ行セット・イテレータを正しく使用する典型的なアプリケーション・モジュールを示します。
例13-8 アプリケーション・モジュールのカスタム・メソッドにおけるセカンダリ行セット・イテレータの使用
// 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())
行セット反復ループは、例13-9に示したように、最初の行ではなく2番目の行を処理することでスキップまたは開始されます。
例13-9 デフォルト行セット・イテレータの使用結果
// 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
ファイルを作成する場合は、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページのリソース・バンドル・オプションを使用して、「1ファイル当たり1バンドル」オプションを選択します。このオプションは、デフォルトで「1プロジェクト当たり1バンドル」に設定され、プロジェクトごとに1つずつ.properties
ファイルが生成されます。
作成する.properties
ファイルは、完全修飾パッケージ名とカスタム・メソッド例外メッセージによって、属性プロパティを参照できます。たとえば、メッセージ・キーと文字列を次のように定義します。
test.Order.Orderno_LABEL=Order Number INVALID=You have called the method foo in an invalid way.
リソース・バンドルでメソッドの例外メッセージ用メッセージを定義する場合、カスタム・メソッドは13.9.1項「アプリケーション・モジュールのクライアント・インタフェース上でのカスタム・メソッドの公開方法」に記載したように、アプリケーション・モジュール・クライアント・インタフェースに表示する必要があります。
たとえば例外メッセージINVALID
のかわりに、メソッドfoo()
のメッセージを定義すると、インタフェースはリソース・バンドルからメッセージを呼び出すように、このメソッドを定義する場合があります。
public void foo() { ResourceBundleDef r = getResourceBundleDef(); throw new JboException(r,"INVALID",null); }
始める前に:
プロジェクトでのリソース・バンドルの使用方法を理解しておくと役立つ場合があります。詳細は、13.8項「アプリケーション・モジュール・メッセージ文字列のカスタマイズ」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
13.2.1項「アプリケーション・モジュールの作成方法」に記載されている方法に従って、該当するアプリケーション・モジュールを作成します。
4.7項「リソース・バンドルの使用」の説明に従い、データ・モデル・プロジェクトのプロジェクト・プロパティを設定してファイルごとに1つずつバンドルを生成します。
アプリケーション・モジュールのリソース・バンドルを生成するには:
「アプリケーション」ウィンドウで、リソース・バンドルを生成するアプリケーション・モジュールをダブルクリックします。
概要エディタで、「一般」ナビゲーション・タブをクリックし、表示名を入力します。
アプリケーション・モジュールの表示名を追加すると、表示名のメッセージ・キーとともに.properties
ファイルが生成されます。
ファイルを保存します。
アプリケーション・モジュールのリソース・バンドルを生成すると、JDeveloperではコンポーネントのXMLドキュメント・ファイルと同じディレクトリに.properties
ファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleName
MsgBundle.properties
になります。
例13-10は、.properties
ファイルを参照するアプリケーション・モジュールXMLドキュメントのResourceBundle
要素を示しています。
アプリケーション・モジュール・クラスにpublic
カスタム・メソッドを追加する際に、アプリケーションのUIによるそのメソッドの起動を可能にする場合、そのメソッドをアプリケーション・モジュールのUIクライアント・インタフェースに追加する必要があります。
アプリケーション・モジュールのカスタムJavaクラスのpublicメソッドをクライアント・インタフェースに追加するには、アプリケーション・モジュールの概要エディタで「Javaクラス」ページを使用します。
始める前に:
クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、13.9項「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
クライアント・インタフェースにカスタム・メソッドを公開するには:
「アプリケーション」ウィンドウで、クライアント・インタフェースを定義するアプリケーション・モジュールをダブルクリックします。
概要エディタで、「Java」ナビゲーション・タブをクリックし「クライアント・インタフェース」セクションで、「アプリケーション・モジュール・クライアント・インタフェースの編集」ボタンをクリックします。
「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。
「OK」をクリックします。
新しいメソッドが「Javaクラス」ページの「クライアント・インタフェース」セクションに表示されます。
図13-21は、クライアント・インタフェースに追加した複数のpublicメソッドを示しています。
カスタム・サービス・メソッドをクライアント・インタフェースに公開すると、図13-22に示すように、アプリケーション・モジュールと同じ名前のJavaインタフェースが、アプリケーション・モジュールが存在するパッケージのcommon
サブパッケージに作成されます。summit.model
パッケージのAppModule
という名前のアプリケーション・モジュールでは、このインタフェースはAppModule
という名前になり、summit.model.common
パッケージに作成されます。このインタフェースにより、oracle.jbo
パッケージのベースApplicationModule
インタフェースが拡張され、アプリケーション・モジュールがApplicationModuleImpl
クラスから継承するすべてのベース機能へのクライアント・アクセスが可能になります。
例13-11に示すように、AppModule
インタフェースには、アプリケーション・モジュールのクライアント・インタフェースに配置するように選択したすべてのメソッドのメソッド・シグネチャが含まれています。
例13-11 「クライアント・インタフェース」パネルで選択されているメソッドに基づくカスタム・クライアント・インタフェース
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のコード・インサイトによる状況依存の文補完を使用したときにこのカスタム・メソッドを使用できない場合は、生成されたクライアント・インタフェースの再コンパイルを試行してください。これを実行するには、「アプリケーション」ウィンドウでアプリケーション・モジュールを選択し、「構造」ウィンドウで同じ名前のインタフェースのソース・ファイルを選択して、ポップアップ・メニューから「再ビルド」を選択します。このヒントは、ビュー・オブジェクトにかぎらず、ビュー行に追加された新しいカスタム・メソッドでも参考にしてください。 |
アプリケーション・モジュールのクライアント・インタフェースを生成することに加えて、カスタマイズ可能な他のキー・クライアント・オブジェクトを操作するための強く型付けされたクライアント・インタフェースも生成できます。たとえば、カスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースとビュー行クライアント・インタフェースにそれぞれ追加できます。
始める前に:
クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、13.9項「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
ビュー・オブジェクトのクライアント・インタフェースにカスタム・メソッドを公開するには:
「アプリケーション」ウィンドウで、クライアント・インタフェースを定義するビュー・オブジェクトをダブルクリックします。
概要エディタで、「Java」ナビゲーション・タブをクリックし、「クライアント・インタフェース」セクションで、「Javaオプションの編集」ボタンをクリックします。
「Java」ダイアログで「ビュー・オブジェクト・クラスの生成」を選択して、「ビュー・オブジェクト・クラスの生成」をクリックします。「OK」をクリックします。
概要エディタで、「クライアント・インタフェース」セクションを開き、「ビュー・オブジェクト・クライアント・インタフェースの編集」ボタンをクリックします。
「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。
概要エディタで、「カスタム行インタフェース」セクションを開き、「ビュー・オブジェクト・カスタム行インタフェースの編集」ボタンをクリックします。
「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。
「OK」をクリックします。
「Javaクラス」ページに新しいメソッドが表示されます。
summit.model.views
パッケージのCustomerView
ビュー・オブジェクトに対してカスタム・ビュー・オブジェクトのJavaクラスの生成を可能にし、1つ以上のカスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースに追加すると、図13-23に示すように、CustomerViewImpl
クラスおよびCustomerView
インタフェースが生成されます。アプリケーション・モジュール・カスタム・インタフェースと同様に、common
サブパッケージに生成されます。
同様に、同じビュー・オブジェクトに対してカスタム・ビュー行のJavaクラスの生成を有効にして、1つ以上のカスタム・メソッドをビュー行クライアント・インタフェースに追加すると、図13-24に示すように、CustomerViewRowImpl
クラスおよびCustomerViewRow
インタフェースが生成されます。
カスタム・アプリケーション・モジュールのメソッドは、13.9項「UIクライアントへのカスタム・サービス・メソッドの公開」で説明しているように、クライアント・インタフェースに公開した後にOracle ADFモデル・テスターでテストできます。
始める前に:
クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、13.9項「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
公開したサービス・メソッドのテスト方法:
「アプリケーション」ウィンドウで、アプリケーション・モジュールを右クリックし、「実行」を選択します。
または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は、「デバッグ」を選択します。「ログ」ウィンドウおよび各種デバッガ・ウィンドウのデバッガ・プロセス・パネルが開きます。Oracle ADFモデル・テスターを使用してデバッグする場合、これらのウィンドウを使用してステータス・メッセージと例外の表示、ソース・コードのステップ・インとステップ・アウト、およびブレークポイントの管理を実行できます。
ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを受信する方法の詳細は、8.3.10項「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。
クライアント・インタフェースによって定義されたメソッドのメソッド・テスト用パネルを開くには、次のいずれかを行います。
アプリケーション・モジュール・クライアント・インタフェース用に公開したメソッドを実行する場合、データ・モデル・ツリーでアプリケーション・モジュール・ノードを選択し、メイン・メニューから「表示」→「操作」を選択します。アプリケーション・モジュール・ノードをダブルクリックして、メソッド・テスト・パネルを開くこともできます。
ビュー・オブジェクト用のクライアント・インタフェースで公開したメソッドを実行する場合、データ・モデル・ツリーで目的のビュー・オブジェクト・ノードを選択し、メイン・メニューから「表示」→「操作」を選択します。ビュー・オブジェクト・ノードを右クリックして、「操作」を選択することもできます。
ビュー・オブジェクト行のクライアント行インタフェースで定義したメソッドのメソッド・テスト・パネルを開くには、データ・モデル・ツリーを展開し、該当するビュー・オブジェクト・ノードを右クリックして、「表の表示」を選択します。次にビュー・インスタンスの概要パネルで目的の行を選択し、メイン・メニューから「表示」→「操作」を選択します。
マスター・ビュー・オブジェクトではビュー行の操作は禁止されているので、データ・モデル・ツリーでマスター・ビュー・インスタンスを選択しないでください。図13-25のように、マスター/ディテール階層が指定されていないディテール・ビュー・インスタンスまたはビュー・インスタンスを必ず選択してください。
ヒント: ディテール・ビュー・インスタンスの場合、マスター・ビュー・インスタンスを開いて該当する行のディテールに移動できます。Oracle ADFモデル・テスターは、開いた概要パネル内に表示されたデータを、移動先のマスター・ビュー・インスタンスと自動的に同期化します。 |
メソッド・パネル内で、ドロップダウン・リストから該当するサービスを選択し、メソッド・パラメータとして渡す値を入力し、「実行」をクリックします。
メソッド・テスト・パネルにはパラメータ名が表示され、渡す値をどこに入力すればよいのかがわかるようになっている点に注意してください。これはメソッド・シグネチャが同じデータ型の複数のパラメータを定義している場合には特に便利です。
戻り値(ある場合)とテスト結果を表示できます。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()
メソッドをコールすると、クライアント・ユーザー・インタフェースでビュー・オブジェクトの現在行として認識されている行にアクセスできます。その結果、アプリケーション・モジュールのビジネス・サービス・メソッドの記述中には、クライアントからのパラメータの引渡しが不要な場合があります。これは、同じアプリケーション・モジュールのデータ・モデルにある他のビュー・オブジェクト・インスタンスの現在行から値を渡すのみの場合に該当します。
たとえば、例13-12にあるカスタム・アプリケーション・モジュール・メソッドではパラメータを受け入れません。createOrderItem()
メソッドはgetGlobals().getCurrentRow()
を内部でコールし、Globals
ビュー・オブジェクト・インスタンスの現在行にアクセスします。次に、強く型付けされたアクセッサ・メソッドを行で使用してDescription
およびLineItemId
属性の値にアクセスし、この値を、新規作成されたOrderItem
エンティティ・オブジェクト行の対応する属性の値として設定します。
メソッドをアプリケーション・モジュールのクライアント・インタフェースに公開したら、それらのメソッドをクライアントから起動できます。
アプリケーション・モジュールのクライアント・インタフェースをプログラム的に操作するには、次の手順を実行します。
ApplicationModule
を、特定のクライアント・インタフェースにキャストします。
インタフェース上のいずれかのメソッドをコールします。
注意: この項では、説明を簡潔にするために、カスタム・アプリケーション・モジュールのインタフェースの操作のみを重視しますが、これと同じダウンキャスト方法は、 |
例13-13は、この2つの手順を実行するTestClientEntity
クラスを示しています。13.7.5項「静的メイン・メソッドを使用したカスタム・アプリケーション・モジュールのテスト方法」に記載したように、このクラスのmain()
メソッドを使用してアプリケーション・モジュール・メソッドのテストを行うこともできます。その場合は、AppModule
クライアント・インタフェースを使用して、クライアントからすべての同一メソッドをコールします。
注意:
|
例13-13の基本ロジックは次の手順に従います。
注文1011の合計を取得します。
注文1011の顧客名を取得します。
1011の注文ステータスを「Y」の値に設定します。
顧客名がnullの新しい顧客を作成します。
顧客名を付けて新しい顧客を作成し、新しく割り当てた顧客IDを表示します。
例13-13 カスタム・アプリケーション・モジュールを内部からテストするmainメソッドのサンプル
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); } }
カスタム・アプリケーション・モジュール・クラスを実行すると、例13-13の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層のアプリケーション・モジュールにアクセスするたびに、ローカル・モードでアプリケーション・モジュールにアクセスします。
oracle.jbo.client
パッケージのConfiguration
クラスでは、テスト用のアプリケーション・モジュール・インスタンスを非常に簡単に入手できます。これにより、JUnit回帰テスト・フィクスチャの一部となるテスト・クライアント・プログラム(42.11項「JUnitを使用した回帰テスト」を参照)のように、テスト・クライアント・プログラムの記述が簡単になります。
ベスト・プラクティス: Fusion Webアプリケーションに対しては、常にバインディング・レイヤーを使用してアプリケーション・モジュールにアクセスする必要があります。開発者はアプリケーション・モジュールにアクセスするあらゆる場合に、このクラスの |
データをバインドするためのADFモデル・レイヤーを使用してFusion Webアプリケーションを操作している場合、ユーザー・インタフェース・プロジェクトにADFBindingFilter
というサーブレット・フィルタが構成されます。このフィルタにより、宣言的なバインディング・メタデータに基づく適切なアプリケーション・モジュール・インスタンスの自動的な取得およびリリースが調整され、ユーザー・インタフェース・プロジェクトのページ定義ファイルで指定された既知のアクション・バインディングまたはイテレータ・バインディングを使用して、サービスをデータ・コントロールとして検索できるようになります。ADFバイディング・コンテナ、データ・コントロール、ページ定義ファイルおよびバインディングの詳細は、第17章「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。ここでは、ADFアクション・バインディングまたはADFイテレータ・バインディングに名前を付けることで、このDCBindingContainer
からアプリケーション・モジュールのクライアント・インタフェースにアクセスできることがわかるだけで十分です。例13-14(アクション・バインディング)および例13-15(イテレータ・バインディング)に示すように、JSFマネージドBeanのカスタム・クライアント・インタフェースで、バインディング・コンテキストを参照してメソッドをコールできます。
アクション・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、例13-14に示す基本手順に従います。
ADFバインディング・コンテナにアクセスします。
名前の付いたアクション・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルに提供されている任意のアクション・バインディング名を使用します。)
データ・コントロールをアクション・バインディングから名前で取得します。
アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。
アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。
クライアント・インタフェースにあるいずれかのメソッドをコールします。
例13-14 名前付きアクション・バインディングを使用したJSFバッキングBeanでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス
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"; } }
イテレータ・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、例13-15に示す基本手順に従います。
ADFバインディング・コンテナにアクセスします。
名前の付いたイテレータ・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルないの任意のイテレータ・バインディング名を使用します。)
データ・コントロールをイテレータ・バインディングから名前で取得します。
アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。
アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。
クライアント・インタフェースにあるいずれかのメソッドをコールします。
例13-15 名前付きイテレータ・バインディングを使用したJSFバッキングBeanでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス
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の例は、例13-16に示すヘルパー・メソッドによって異なります。
例13-16 バッキングBeanクラスのヘルパー・メソッド
public BindingContainer getBindings() { { return BindingContext.getCurrent().getCurrentBindingsEntry(); }
ADFアクションに宣言的にバインドされるボタンをオーバーライドしてバッキングBeanクラスを作成すると、このメソッドがクラス内に自動的に生成されます。それ以外の場合は、ヘルパー・メソッドをクラスに手動で追加する必要があります。
ApplicationModuleImpl
ベース・クラスには、この機能を実装する組込みメソッドが多数含まれています。付録D「ADFビジネス・コンポーネントのよく使用されるメソッド」は、カスタム・アプリケーション・モジュール・クラスでよく記述、使用およびオーバーライドする最も一般的なコードのクイック・リファレンスとなっていますが、この項では、これらの組込みフレームワーク・メソッドの1つをオーバーライドしてデフォルトの動作を拡張する基本手順の理解を深めることを重視しています。
アプリケーション・モジュールの組込みフレームワーク・メソッドをオーバーライドするには、「メソッドのオーバーライド」ダイアログを使用して、メイン・メニューからアプリケーション・モジュールのJavaクラスを開きます。
始める前に:
アプリケーション・モジュールのベース・クラスに関する知識があると役立つ場合があります。詳細は、13.11項「組込みフレームワーク・メソッドのオーバーライド」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュールのフレームワーク・メソッドをオーバーライドするには:
「アプリケーション」ウィンドウで、フレームワーク・メソッドをオーバーライドするアプリケーション・モジュールをダブルクリックします。
概要エディタで、「Java」ナビゲーション・タブをクリックし、カスタマイズするアプリケーション・モジュールのJavaクラスにリンクされたファイル名をクリックします。
ソース・エディタが開いて、クラス・ファイルが表示されます。
メイン・メニューから、「ソース」を選択し、次に「メソッドのオーバーライド」を選択します。
「ソース」メニューが表示されていない場合は、目的のJavaクラス・ファイルが開いており、ソース・エディタが表示されていることを確認します。
「メソッドのオーバーライド」ダイアログで、リストをスクロールして目的のメソッドを特定するか、あるいはメソッド名の最初の数文字を入力してインクリメンタル検索を実行します。
メソッドを1つ以上選択します。
「メソッドのオーバーライド」ダイアログでは、任意の数のメソッドを選択して同時にオーバーライドできます。
たとえば、図13-26
に示すように、新規ユーザー・セッションでアプリケーション・モジュールのサービス・コンポーネントの操作を初めて開始したときに、アプリケーション・モジュールのprepareSession()
メソッドをオーバーライドしてデフォルトの機能を拡張する場合、prepareSession(Session)メソッドの隣のチェック・ボックスを選択します。
「OK」をクリックします。
「メソッドのオーバーライド」ダイアログを閉じると、図13-27に示すように、オーバーライドしたメソッドにカーソルが置かれた状態でソース・エディタに戻ります。メソッドには、super.prepareSession()
をコールする単一行が表示されています。これは、ベース・クラスがこのメソッドに対して通常であれば実行したはずのデフォルトの動作を起動するJava構文です。カスタム・アプリケーション・モジュール・クラスでこの行の前または後にコードを追加して、デフォルトの機能の前または後のデフォルトの動作を拡張できます。
「メソッドのオーバーライド」ダイアログを使用してメソッドをオーバーライドする場合、ソース・エディタにより、オーバーライドしたメソッドの直前にJDK @Override
注釈が挿入されます。この注釈により、アプリケーション・モジュール・クラスのメソッドがスーパークラスのメソッドのシグネチャと一致しない場合は、コンパイル時にエラーが生成されます。
クラスにメソッド名を追加してスーパークラス内のメソッドをオーバーライドする場合は注意が必要です。オーバーライドするベース・クラス・メソッドと完全に同一のシグネチャが必要です。@Override
注釈は必ずメソッドの直前に追加してください。これにより、メソッドがスーパークラスのメソッドのいずれのシグネチャとも一致しない場合は、コンパイル時にエラーが生成されます。スーパークラスの実装をコールするかわりにメソッドのコードを記述する場合は、抑止または置換する組込みコードについて理解しておく必要があります。
prepareSession()
メソッドは、新しいユーザー・セッションで初めて使用されるときにアプリケーション・モジュールによって起動されるため、カスタム・アプリケーション・モジュール・クラスをオーバーライドし、アプリケーション・モジュールを使用する新しいユーザーごとに固有のセットアップ・タスクを実行する場合に便利なメソッドです。例13-17は、接続されたユーザーのデータベース・クライアント情報を指定するsetApplicationInfo()
ヘルパー・メソッドを起動するAppModuleImpl
クラス内の、オーバーライドされたprepareSession()
メソッドを示しています。
例13-17 現在のユーザー・セッションで使用するクライアント・データの初期化
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サービスから提供される機能をOracle ADFアプリケーション・モジュールで利用する必要がある場合もあります。Webサービスは、任意のプログラミング言語で実装し、ネットワーク上の任意のサーバーに配置できます。各Webサービスでは、言語に依存しない標準的なXMLフォーマットで記述することにより、一連の該当するメソッドをそのAPI内で指定します。このXMLドキュメント(構文は、Web Services Description Language (WSDL)に準拠)を使用すると、Webサービスのメソッドの名前に加えて、それらのメソッドが予期するパラメータや実際の戻り値のデータ型も、JDeveloperで理解できます。
注意: アプリケーション・モジュールはWebサービスとして公開し、デプロイ済のFusion Webアプリケーション間で使用することもできます。外部サービスを使用したADFビジネス・コンポーネントの再利用の詳細は、第15章「サービス対応のアプリケーション・モジュールの統合」を参照してください。 |
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サービスをコールするには、次の作業を実行します。
WebサービスのWebサービス・プロキシ・クラスを作成します。コールする必要のあるWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・クライアントおよびプロキシの作成ウィザードを使用します。
プロキシ・クラスにメソッドを実装し、目的のWebサービスにアクセスします。
該当するWebサービス・プロキシ・クラスのインスタンスをアプリケーション・モジュール内で作成し、Webサービス・プロキシ・オブジェクト上でメソッドを1つ以上起動します。
コールするWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・プロキシ作成ウィザードを使用します。
始める前に:
Webサービスについて理解しておくと役立つ場合があります。詳細は、13.12項「アプリケーション・モジュールからのWebサービスのコール」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
サービスにプログラム的にアクセスするためにWebサービス・プロキシ・クラスを作成するには:
「アプリケーション」ウィンドウで、Webサービス・プロキシを作成するプロジェクトを右クリックし、「新規」→「Webサービス・クライアントおよびプロキシ」を選択します。
Webサービス・クライアントおよびプロキシの作成ウィザードの「Webサービス記述の選択」ページで、アプリケーション内でコールするサービスのWSDLのURLを入力し、フィールドからタブアウトします。
ウィザードの「次へ」が有効になっている場合は、WSDLドキュメントをJDeveloperが認識し、検証済です。「次へ」ボタンが有効にならない場合は、URLの検証後に問題を修正してこの手順を繰り返します。
ウィザードの以降のページに進み、Webサービス・プロキシの詳細を指定します。
「終了」をクリックします。
Webサービス・プロキシを作成したら、目的のWebサービスにアクセスするためにプロキシ・クラスにメソッドを実装する必要があります。
始める前に:
Webサービスについて理解しておくと役立つ場合があります。詳細は、13.12項「アプリケーション・モジュールからのWebサービスのコール」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
サービスを起動するためにWebサービス・プロキシ・テンプレートをコールするには:
ソース・エディタでport_name
Client.java
という名前のプロキシ・クライアント・クラスを開き、メイン・メソッド内にある// Add your own code to call the desired methods
というコメントを検索します。
適切なコードを追加してWebサービスを起動します。
JDeveloperにより生成されたクライアント・モジュール・クラスの完全セットをデプロイし、このクラスをアプリケーションで参照します。
Webサービス・プロキシ・クラスを生成すると、その後、アプリケーション・モジュールのカスタム・メソッド内で使用できます(例13-18を参照)。該当メソッドによりWebサービス・プロキシ・クラスのインスタンスが作成され、その結果についてWebサービス・プロキシ・クラスからWebサービス・メソッドがコールされます。
例13-18 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
}
JDeveloperは、WSDLドキュメント内で検出されたWebサービス・ポートの名前を反映した名前を使用して、ユーザーが指定したパッケージ内でWebサービス・プロキシ・クラスを生成します。Webサービス・ポート名は、人間が判読できるStockQuoteService
のような名前の場合もあれば、StockQuoteServiceSoapHttpPort
のようなわかりにくい名前の場合もあります。このポート名は、ユーザーが使用中のWebサービスを公開した開発者によって決定されます。たとえば、サービスのポート名がStockQuoteServiceSoapHttpPort
であると仮定すると、JDeveloperはStockQuoteServiceSoapHttpPortClient
という名前のWebプロキシ・クラスを生成します。
Webサービス・プロキシは、「アプリケーション」ウィンドウ内で、WebServiceName
Proxy
という単一の論理ノードとして表示されます。たとえば、StockQuoteService
WebサービスのノードはStockQuoteServiceProxy
という名前で「アプリケーション」ウィンドウに表示されます。JDeveloperでは、プロキシ・クラスの生成処理の一部として、サーバーの起動に使用するメインのWebサービス・プロキシ・クラスのみでなく、多数の補助クラスとインタフェースも生成されます。これらのファイルは、「アプリケーション」ウィンドウ内のWebServiceName
Proxy
ノードの下に表示されます。生成されたファイルは、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サービス・プロキシの開発後、プロキシの接続を追加で作成し、テストやデプロイメントで使用できます。たとえば、テスト用にユーザー名とパスワードを含む接続を作成できます。
接続情報はアプリケーション内の他の接続と一緒にconnections.xml
ファイルに保存されます。エンドポイントURLの抽象化によって、Enterprise Managerを使用したデプロイ後に、クライアント・コードを変更せずに接続を編集することもできます。
始める前に:
Webサービスについて理解しておくと役立つ場合があります。詳細は、13.12項「アプリケーション・モジュールからのWebサービスのコール」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、13.1.2項「アプリケーション・モジュールの追加機能」を参照してください。
Webサービス接続の作成方法:
「アプリケーション」ウィンドウで、Webサービス・プロキシを右クリックし、「ADF Webサービス接続を作成しています」を選択します。
「新規ADF Webサービス接続」ダイアログに、選択したプロキシに関連付けられた接続のデフォルト設定が表示されます。
必要に応じて接続情報を変更し、「OK」をクリックします。
警告: 既存の接続と同じ名前で新しいWebサービス接続を作成すると、既存の接続が新しい情報によって上書きされます。 |
新しいWebサービス接続の作成後、この接続を使用するようにクライアントを変更できます。例13-19に示すようなコードを使用して、クライアントから接続にアクセスできます。
例13-19 クライアントからWebサービス接続へのアクセス
Context ctx = ADFContext.getCurrent().getConnectionsContext(); WebServiceConnection wsc = (WebServiceConnection) ctx.lookup("MyAppModuleService
");MyAppModuleService
proxy = wsc.getJaxWSPort(MyAppModuleService
.class);
lookup()
メソッドに渡す引数は、Webサービス接続に渡した名前です。この例ではMyAppModuleService
です。
アプリケーション・モジュールからWebサービスを起動する場合、Webサービス・プロキシ・クラスは、「SOAP」で説明したXMLベースのWebサービス・プロトコルを使用する際の低レベルの詳細処理を実行します。具体的には、次の処理を実行します。
メソッドの起動を表すXMLドキュメントを作成
メソッド引数をXMLにパッケージング
HTTP POST
リクエストを使用してXMLドキュメントをサービスURLに送信
Webサービスから受信したXMLエンコード・レスポンスのパッケージングを解除
起動対象のメソッドが戻り値を持つ場合は、アプリケーション・モジュール・コード内で操作できるように、適切な型のオブジェクトとして受信します。
アプリケーション内でWebサービス・プロキシを実装している場合、「try-catch」ブロックを使用してWebサービス例外を処理するか、Webサービス・プロキシ・クラスでアプリケーション・モジュールを起動します。以降の項で、この機能や、Webサービス・プロキシに関するその他の機能の詳細を説明します。
生成されたWebサービス・プロキシ・クラスを使用すると、リモートWebサービスの起動は、ローカルJavaクラス内のメソッドをコールするのと同じように簡単になります。その場合に注意が必要な唯一の違いは、HTTPリクエストに関与する問題が存在する場合にWebサービス・メソッドのコールが失敗する可能性がある点です。Webサービス・プロキシに対して実行するメソッド・コールでは、適切なtry...catch
ブロックを使用してコールをラップすることにより、リクエストの失敗に備える必要があります。例13-20では、Webサービス例外を捕捉することで、前述(13.12.1.3項「アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール」)の簡単な例を改良しています。この場合は該当するエラーをJboException
として再スローしているだけですが、アプリケーションではさらに適切なエラー処理を実装することもできます。
例13-20 try-catchブロックを使用したWebサービス・メソッド・コールのラップ
// 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サービスを起動した後、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サービス・プロキシ・クラスを使用してOracle ADFサービスベースのアプリケーション・モジュールを起動すると、コール側コンポーネントとコールしているサービスがコロケートしている場合にコールを最適化できなくなります。別な方法として、第15章「サービス対応のアプリケーション・モジュールの統合」で説明しているサービス・インタフェースによる方法を使用することもできます。