| Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2(11.1.2.3.0) B69399-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2(11.1.2.3.0) B69399-02 |
|
前 |
次 |
この章では、データ・モデル・プロジェクトのJDBCデータソースの定義方法と、データ・モデルをOracle Application Development Framework (Oracle ADF)アプリケーションにカプセル化するADFアプリケーション・モジュールの作成方法について説明します。この章では、ビジネス・サービス・メソッドをそのデータ・モデルと結合して完全なビジネス・サービスを実装する方法についても説明します。
この章の内容は次のとおりです。
アプリケーション・モジュールは、ADF Business Componentsのコンポーネントで、エンド・ユーザー・タスクに関連する論理作業ユニットのビジネス・サービス・メソッドとデータ・モデルをカプセル化したものです。
アプリケーション開発の早期段階では、アーキテクトと設計者は通常、UMLユースケース手法を使用して、アプリケーションの計画済エンド・ユーザー機能の高レベルな概要を作成します。この設計段階中に識別されるエンド・ユーザーの高レベルな各ユースケースは、一般に次のものに応じて異なります。
対象となるドメイン・ビジネス・オブジェクト。ユースケースに関連するコア・ビジネス・データについての問題に解答します。
必要なビジネス・データのユーザー指向ビュー。ユースケースをサポートするために必要な列サブセット、フィルタ処理された行セット、ソート方法、グループ化方法などについての問題に解答します。
各ユースケースに関連するドメイン・オブジェクトを識別すると、ビジネス・ドメイン・レイヤー内の必要なエンティティ・オブジェクトを識別する際に便利です。必要なビジネス・データのユーザー指向ビューは、ビュー・オブジェクトとして取得された適切なSQL問合せを定義して、データをエンド・ユーザーの期待どおりに取得する際に便利です。これには、パフォーマンスを最大化するために、ユースケースのサポートに必要な最低限の詳細の取得が含まれます。これまでの説明で、ビュー・オブジェクト問合せを利用してデータを形成する方法のみならず、ビュー・リンクを使用してデータ・モデルに自然なマスター/ディテール階層を設定し、期待どおりのエンド・ユーザー体験をユーザーに提供してユースケースを実現する方法も、すでに学習しました。
アプリケーション・モジュールは、当該のユースケースに必要な再使用可能なビュー・オブジェクトのインスタンスを含む作業ユニット・コンテナです。これらのオブジェクトは、ユースケースで表示または変更している情報を含む再使用可能なビジネス・ドメイン・レイヤー内の基礎となるエンティティ・オブジェクトに、メタデータを通じて関連付けられています。
この章では、図9-1に示す次の概念について説明します。
ビュー・オブジェクトのインスタンスをアプリケーション・モジュールで使用して、そのデータ・モデルを定義します。
サービス・メソッドを記述して、タスク・レベルのビジネス・ロジックをカプセル化します。
UIクライアントがコールするメソッドを選択し、クライアント・インタフェースで公開します。
アプリケーション統合シナリオでプログラム的に使用するメソッドを選択し、サービス・インタフェースで公開します。
複数のWebページを表示できる論理トランザクション中に、プール内のアプリケーション・モジュールを使用します。
アプリケーション・モジュールでは、データベース接続の取得と、エンティティ・オブジェクトに行われた変更の保存またはロールバックの調整を行うTransactionオブジェクトを操作します。
関連するSessionオブジェクトにより、現在のアプリケーション・ユーザーに関するランタイム情報が提供されます。
アプリケーション・モジュールを使用する前に、他のADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。
共有アプリケーション・モジュールの作成の詳細は、第10章「アプリケーション・モジュール・ビュー・インスタンスの共有」を参照してください。
外部サービスを使用したADF Business Componentsの再利用の詳細は、第11章「サービス対応のアプリケーション・モジュールの統合」を参照してください。
「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュール公開方法の詳細は、第13章「Fusion WebアプリケーションでのADF Modelの使用」を参照してください。
実行時のパフォーマンスを向上させるためのアプリケーション・モジュール・インスタンス構成の詳細は、第43章「アプリケーション状態管理」および第44章「アプリケーション・モジュール・プールと接続プールのチューニング」を参照してください。
カスタム・アプリケーション・モジュール・クラスでよく記述、使用またはオーバーライドするコードについては、付録D「ADF Business Componentsのよく使用されるメソッド」を参照してください。
oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。
Oracle Fusion Middleware Oracle ADF Model Java APIリファレンス
大規模なアプリケーションでは、通常、粒度の粗い各エンド・ユーザー・タスクをサポートするアプリケーション・モジュールを1つずつ作成します。小規模なアプリケーションでは、アプリケーション・モジュールを1つ作成すれば、アプリケーションの全機能のニーズを十分に処理できると判断する場合もあります。9.4項「ネストされたアプリケーション・モジュールの定義」には、これに関する追加の説明があります。
作成するビュー・オブジェクトはすべて、1つ以上のアプリケーション・モジュールにおいて使用できる再使用可能なコンポーネントであり、そのアプリケーション・モジュールのトランザクションにおいてカプセル化される問合せを実行します。アプリケーション・モジュールで使用される一連のビュー・オブジェクトは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。
アプリケーション・モジュールを作成するには、「新規ギャラリ」から使用できるアプリケーション・モジュールの作成ウィザードを使用します。
作業を始める前に、次のようにします。
アプリケーション・モジュールの知識があると役立ちます。詳細は、9.2項「アプリケーション・モジュールの作成と変更」を参照してください。
次のタスクを完了します。
アプリケーション・モジュールを作成する方法:
アプリケーション・ナビゲータで、アプリケーション・モジュールを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で、「ビジネス層」を展開し、「ADF Business Components」、「アプリケーション・モジュール」の順に選択して、「OK」をクリックします。
アプリケーション・モジュールの作成ウィザードの「名前」ページで、パッケージ名およびアプリケーション・モジュール名を指定します。「次へ」をクリックします。
|
注意: Fusion Webアプリケーションでは、アプリケーション・モジュールの名前に予約語の |
「データ・モデル」ページで、以前に定義したビュー・オブジェクトのインスタンスを指定し、このビュー・オブジェクト・インスタンスの名前をクライアントで認識される名前とまったく同じ名前に編集します。次に、「次へ」をクリックします。
「Java」ページではオプションでJavaファイルを作成し、アプリケーション・モジュールの動作をプログラミングによってカスタマイズすることができます。あるいは、アプリケーション・モジュールのクライアント・インタフェースにメソッドをエクスポートして、クライアントが呼び出せるようにすることができます。XML専用のアプリケーション・モジュール・コンポーネントを生成するには、このフィールドを選択しないまま、「終了」をクリックします。
最初に、アプリケーション・モジュールのXML定義コンポーネントのみを生成することもできます。ウィザードを完了した後に、プログラムによるアクセスが必要になる場合は、概要エディタを使用してアプリケーション・モジュール・クラス・ファイルを生成できます。アプリケーション・モジュールのプログラム的な使用の詳細は、9.7項「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。
手順ごとの詳細は、9.2.3.2項「アプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。
アプリケーション・モジュールを作成すると、JDeveloperでは、その宣言的設定を表すXMLコンポーネント定義ファイルが作成され、そのパッケージの名前に対応するディレクトリに保存されます。たとえば、storefront.modelパッケージのStoreServiceAMという名前のアプリケーション・モジュールに対しては、プロジェクトのソース・パスに./storefront/model/StoreServiceAM.xmlというXMLファイルが作成されます。このXMLファイルには、ビュー・オブジェクト・インスタンスをアプリケーション・モジュールのデータ・モデルで再作成するために実行時に必要な情報が含まれています。
この内容を確認するには、アプリケーション・ナビゲータでStoreServiceAMノードをダブルクリックして概要エディタを開き、アプリケーション・モジュールのXMLファイルを確認します。エディタ・ウィンドウで「ソース」タブをクリックすると、XMLファイルが表示され、その内容を確認できます。構造ウィンドウには、XMLファイルの構造が表示されます。
ビジネス・コンポーネントを作成すると、JDeveloperがアプリケーション・モジュールのすべての機能を含むデータ・コントロールを自動的に作成します。データ・コントロールはADF Model抽象レイヤーで、属性、メソッド、関連する型の情報を含む補足メタデータを提供して、アプリケーション・モジュールの操作とデータ・コレクション(ビュー・オブジェクト・インスタンスの行セット)を記述します。開発者は、JDeveloperの「データ・コントロール」パネルに表示されたデータ・コントロールの表現を使用して、アプリケーション・モジュールに自動的にバインドされるUIコンポーネントを作成できます。実行時にADF Modelレイヤーによって、適切なXMLファイルからデータ・コントロールおよびバインディングを記述したメタデータが読み取られ、ユーザー・インタフェースとビジネス・サービスの双方向の結合が実装されます。
たとえば、StoreServiceAMDataControlアプリケーション・モジュールによりStoreFrontモジュール・アプリケーションのビジネス・サービス・レイヤーが実装されます。このデータ・モデルには、複数のマスター/ディテール階層など、多数のビュー・オブジェクト・インスタンスが含まれています。Fusion Order Demoアプリケーションのビュー・レイヤーはJSFページで構成され、このページのUIコンポーネントは、StoreServiceAMDataControlのデータ・モデル内のビュー・オブジェクト・インスタンスのデータと、そのクライアント・インタフェース上の組込み操作およびサービス・メソッドにバインドされています。「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュール公開方法の詳細は、13.3項「Oracle ADFデータ・コントロールを使用したアプリケーション・モジュールの公開」を参照してください。
アプリケーション・モジュールの作成ウィザードでアプリケーション・モジュールを作成しながらビュー・オブジェクトをアプリケーション・モジュールに追加することも、後で追加することもできます。
アプリケーション・モジュールの作成ウィザードの使用方法の詳細は、9.2.1項「アプリケーション・モジュールの作成方法」を参照してください。
作成済のアプリケーション・モジュールにビュー・オブジェクトを追加できます。ビュー・オブジェクトをアプリケーション・モジュールへ追加したり、オプションでビュー・オブジェクト・インスタンスをカスタマイズするには、アプリケーション・モジュールの概要エディタにある「データ・モデル・コンポーネント」ページを使用します。
作業を始める前に、次のようにします。
アプリケーション・モジュールの知識があると役立ちます。詳細は、9.2項「アプリケーション・モジュールの作成と変更」を参照してください。
次のタスクを完了します。
既存のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加する手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「選択可能なビュー・オブジェクト」リストで、追加するビュー・インスタンスを選択します。
リストの下の「新規ビュー・インスタンス」フィールドに、データ・モデルに追加するビュー・オブジェクトの次のインスタンスを識別する際に使用される名前が示されます。
ビュー・オブジェクトを追加する前に名前を変更するには、「新規ビュー・インスタンス」フィールドに別の名前を入力します。
目的のビュー・オブジェクトを選択し、「データ・モデル」リストに移動します。
図9-2では、ビュー・オブジェクトAddressVOの名前をAddressに変更してから、「データ・モデル」リストに移動しています。
アプリケーション・モジュールの概要エディタに表示されるデータ・モデルを使用すると、プロジェクトで定義されている既存のビュー・リンクに基づいて、ビュー・インスタンスの階層を作成できます。複数のマスター/ディテールの階層レベルで構成されるビュー・リンクを定義している場合は、アプリケーションでサポートされているレベル数までマスター/ディテールのビュー・インスタンスを作成できます。
作業を始める前に、次のようにします。
アプリケーション・モジュールの知識があると役立ちます。詳細は、9.2項「アプリケーション・モジュールの作成と変更」を参照してください。
次のタスクを完了します。
マスター/ディテールのビュー・オブジェクト・インスタンスをデータ・モデルに追加する手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「データ・モデル」リストで、積極的に調整を行うマスターにするビュー・オブジェクトのインスタンスを選択します。
リスト内のマスター・ビュー・オブジェクトには、このビュー・オブジェクトにビュー・リンクがあることを示すプラス記号が表示されます。ビュー・リンクは、マスター/ディテール階層の定義に必要です。
図9-3は、選択したPersonsVOと、「新規ビュー・インスタンス」フィールドで名前を変更したAuthenticatedUserを示しています。
選択したマスター・ビュー・オブジェクトを「データ・モデル」リストに移動します。
図9-4は、「データ・モデル」リストに新規作成したマスター・ビュー・インスタンスAuthenticatedUserを示しています。
「データ・モデル」リストで、新規作成したマスター・ビュー・インスタンスを選択して強調表示しておきます。これは、追加するディテール・ビュー・インスタンスのターゲットになります。次に、「選択可能なビュー・オブジェクト」リストで、マスター・ビュー・オブジェクトの下のディテール・ビュー・オブジェクトを特定して選択します。
図9-5は、マスター・ビュー・オブジェクトPersonsVOの下にある、OrdersVO via PersonsToOrdersという名前のディテール・ビュー・オブジェクトOrdersVOを示しています。この名前はビュー・リンクPersonsToOrdersを表し、PersonsVOとOrdersVO間のマスター/ディテール階層を定義します。データ・モデルに追加すると、OrdersVOにはビュー・インスタンス名のMyOrdersが追加されることにも注意してください。
追加したマスター・インスタンスにディテール・インスタンスを追加するには、「データ・モデル」リストで選択したマスター・ビュー・インスタンスの下に、ディテール・ビュー・オブジェクトを移動します。
図9-6は、データ・モデルにAuthenticatedUserのディテールとして新規作成したディテール・ビュー・インスタンスMyOrdersを示しています。
別の階層レベルを追加するには、手順3から6を繰り返しますが、この場合は、新しく追加したディテール・インスタンスを「データ・モデル」リストで選択してから、新しいディテール・インスタンスを移動します。このディテール・インスタンスは、前に追加したディテール・インスタンスとマスター/ディテール関係を持ちます。
図9-7では、MyOrders (旧のOrdersVO via PersonsToOrders)のマスターとする(その結果、MyOrderItems (旧名はOrderItemsVO via OrdersToOrderItems)のマスターになる)AuthenticatedUser (旧名はPersonsVO)インスタンスを含む、「データ・モデル」リストを示しています。
アプリケーション・モジュールの概要エディタにある、「データ・モデル・コンポーネント」ページでビュー・オブジェクト・インスタンスのカスタマイズを任意に行えます。たとえば、次のようにマスター/ディテール・ビュー・オブジェクトの関係をコントロールする属性を設定できます。
作業を始める前に、次のようにします。
アプリケーション・モジュールの知識があると役立ちます。詳細は、9.2項「アプリケーション・モジュールの作成と変更」を参照してください。
既存のアプリケーション・モジュールへ追加するビュー・オブジェクト・インスタンスをカスタマイズする手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「データ・モデル」リストで、カスタマイズするビュー・オブジェクト・インスタンスを選択し、編集ボタンをクリックします。
「ビュー・インスタンスの編集」ダイアログで、次のいずれかの手順を実行し、「OK」をクリックします。
「ビュー基準」グループ・ボックスで、ビュー・オブジェクト・インスタンスに適用する1つ以上のビュー基準を選択します。選択されたビュー基準は、WHERE句としてインスタンス問合せに追加されます。ビュー基準の定義の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
「バインド・パラメータ値」グループ・ボックスで、定義済のビュー基準を適用する際にインスタンスで使用する値を入力します。バインド変数の定義の詳細は、5.10項「バインド変数の使用」を参照してください。
図9-8は、「ビュー・インスタンスの編集」ダイアログでAuthenticatedUserByPrincipalCriteriaを選択し、AuthenticatedUserビューを開いた状態を示しています。実行時に、Groovy式の評価によってADFセキュリティ・コンテキストから現在のユーザーを取得することで値が提供されるので、バインド変数userPrincipalのデフォルト値は提供されていません。プロジェクトのデータ・モデルは、PrincipalName属性をAuthenticatedUserビュー使用の制御属性として使用することにより、マスター/ディテール関係を定義します。ビュー基準フィルタによって設定した制御属性により、現在のユーザーのビュー行だけを取得できます。
アプリケーション・モジュールへのビュー・オブジェクトの追加時に、ビュー・オブジェクト・コンポーネントのインスタンスを使用してそのデータ・モデルを定義します。図9-9は、PersonServiceアプリケーション・モジュールのJDeveloperビジネス・コンポーネント・ダイアグラムを示しています。
例に示したアプリケーション・モジュールにはPersonsビュー・オブジェクト・コンポーネントの2つのインスタンスが含まれています。 メンバー名のPersonListと、それを区別するAnotherPersonListです。実行時には両方のインスタンスが同一のPersonsVOビュー・オブジェクト・コンポーネント定義を共有します。そのため、同じ属性構造とビュー・オブジェクト動作であることを確認してください。ただし、それぞれを個別に使用して異なるユーザーのデータを取得できます。たとえばWHERE句やバインド変数の追加フィルタなど、一部の実行プロパティは2つのインスタンスで異なっている場合があります。
例9-1は、PersonServiceアプリケーション・モジュールにより、アプリケーション・モジュールのメンバー・ビュー・オブジェクト・インスタンスがそのXMLコンポーネント定義ファイルで定義される様子を示しています。
新しいアプリケーション・モジュールを作成した後、「アプリケーション・モジュールの編集」ダイアログを使用してその設定を編集できます。エディタを起動するには、アプリケーション・ナビゲータでアプリケーション・モジュール・ノードを右クリックして「開く」を選択するか、アプリケーション・モジュールをダブルクリックします。エディタの様々なページを開き、データ・モデル、ネストされたアプリケーション・モジュールの参照、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ページにデータをバインドします。たとえば、アプリケーション・モジュールの名前がStoreServiceAMの場合、「データ・コントロール」パネルには、StoreServiceAMDataControlという名前のデータ・コントロールが表示されます。デフォルトのデータ・コントロール名を変更して、名前を短くしたり適切な名前を指定することもできます。
ユーザー・インタフェース・デザイナでデータ・コントロールを操作すると、アプリケーション・モジュールのデータ・コントロール名は、ユーザー・インタフェース・プロジェクトのDataBindings.cpxファイルおよび各データ・バインディング・ページ定義のXMLファイルに表示されます。また、アプリケーション・モジュールのサービス・インタフェースをプログラム的に操作する必要がある場合は、データ・コントロール名をコード内で参照できます。このため、アプリケーション・モジュールの名前を変更する場合は、ビュー・レイヤーを作成する前に変更する必要があります。
アプリケーション・モジュールのデータ・コントロールの詳細は、第13章「Fusion WebアプリケーションでのADF Modelの使用」を参照してください。
|
注意: 1つ以上のページですでに参照した後にアプリケーション・モジュールのデータ・コントロール名を変更する場合は、データ・コントロール名が参照されているページ定義ファイルと |
アプリケーション・モジュールのデータ・コントロール名を変更する手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
プロパティ・インスペクタを開き、「その他」セクションを展開します。
「データ・コントロール名」フィールドに、適切なデータ・コントロール名を入力します。
アプリケーション・モジュールに関する一般的な疑問は、「アプリケーション・モジュールがどの位の大きさになるのか」というものです。つまり、「エンタープライズ・アプリケーションの全データ・モデルを含む1つの大きなアプリケーション・モジュールを構築するべきなのか、小さいアプリケーション・モジュールを多数構築するべきなのか」という疑問です。答えは状況によって異なります。
一般に、アプリケーション・モジュールのサイズは、そのモジュールでの対応が想定される特定のユースケースを十分にサポートできる大きさにする必要があります。9.4項「ネストされたアプリケーション・モジュールの定義」に記載されたネスト機能を使用して、微調整したアプリケーション・モジュール・コンポーネントを集めて構築することができます。複雑なビジネス・アプリケーションのユースケースは実際には1つではないので、Oracle ADFを使用して実装された複雑なビジネス・アプリケーションは複数のアプリケーション・モジュールから構成されるのが一般的です。
実際には、希望の粒度を選択できます。たとえば、主要なユースケースが1つ、バックエンドでサポートしているユースケースが1つの小規模アプリケーションの場合、アプリケーション・モジュールを2つ作成できます。ただし、簡潔にするため、数個のビュー・オブジェクトのみを含んだ2つ目のアプリケーション・モジュールを作成するのではなく、両方のユースケースを組み合せることもできます。
アプリケーション・モジュールの設計時に、ビュー・オブジェクト・コンポーネントのインスタンスを使用してそのデータ・モデルを定義します。ユーザー・インタフェースに含まれるButtonコンポーネントの2つのインスタンスに、区別するためのmyButtonおよびanotherButtonというメンバー名が付けられているように、アプリケーション・モジュールにも、Personsビュー・オブジェクト・コンポーネントの2つのインスタンスに、区別するためのPersonListおよびAnotherPersonListというメンバー名が付けられています。
データ・モデル・プロジェクトを初期化してADF Business Componentsを使用する場合、データベース接続の詳細を指定するように求められます。ADF Business Componentsウィザードを実行し、データベースの表やビューを操作してビジネス・コンポーネントを作成する前に、データベース接続を指定する必要があります。接続の詳細を指定すると、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 Business Componentsにより、データソース接続情報に基づいて実行時にデフォルトのJDBC URLが構成されます。
すべてのデフォルト・アプリケーション・モジュール構成で使用される接続タイプは、JDBCデータソースです。JDBCデータソースをアプリケーション・サーバー構成情報の一部として定義すると、アプリケーション・モジュールが実行時に論理名を使用してリソースを検索します。接続タイプとしてJDBCデータソースを使用すると、アプリケーション・リソース接続の詳細が変更される場合がありますが、デプロイされているアプリケーション・モジュール構成を変更する必要はありません。JDBCデータソースがすべてのアプリケーション・モジュール構成の選択肢としてお薦されているのは、このような理由によります。図9-10に、デフォルトが選択された「ビジネス・コンポーネント構成の編集」ダイアログを示します。
例9-2は、Fusion Webアプリケーションのweb.xmlファイルの<resource-ref>タグを示しています。このタグでは、jdbc/FODemoDSおよびjdbc/FODemoCoreDSという名前の2つの論理データソースを定義しています。「ビジネス・コンポーネント構成の編集」ダイアログは、「JDBCデータソース名」フィールドの接頭辞java:comp/envの後ろにある論理接続名を参照します。たとえば、同じFusion WebアプリケーションのJDBCデータソース接続名に選択可能な値として、java:comp/env/jdbc/FODemoDSを表示します。このように、「データソース名」フィールドには、使用可能なすべてのアプリケーション・リソース接続名のJNDI名が事前に取り込まれます。
例9-2 web.xmlに定義されている論理データソース・リソース名
<!-- In web.xml -->
<resource-ref>
<res-ref-name>jdbc/FODemoDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<resource-ref>
<res-ref-name>jdbc/FODemoCoreDS</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アプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、アプリケーションはマルチ・データ・ソースを使用します。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースと非マルチ・データ・ソースでネーミング規則は同じになります。これによって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。 |
アプリケーション・モジュール構成に使用できるもう1つの接続タイプは、JDBC URL接続です。これは、アプリケーション・モジュールを含むプロジェクトの「プロジェクト・プロパティ」ダイアログの「ビジネス・コンポーネント」ページに設定されている名前付きの接続の定義に基づいています。図9-11は、JDBC URL接続を使用する構成で、このセクションの表示内容を示しています。
|
注意: Oracle以外のJDBCドライバを使用している場合は、「ビジネス・コンポーネント構成の編集」ダイアログの「プロパティ」ページで、ドライバに適したプロパティの設定を確認し、実行時の例外を回避します。 たとえばSybase JDBCドライバを使用している場合、 |
|
注意: データベース接続プールの使用方法およびチューニング方法の詳細は、44.1.1.2項「データベース接続プール」および44.2.9,項「データベース接続プールのパラメータについて」を参照してください。 |
「ビジネス・コンポーネント構成の編集」ダイアログで接続タイプを選択すると、JDeveloperにより、アプリケーション・モジュールのXMLコンポーネント定義に関連する./commonサブディレクトリにあるアプリケーション・モジュール構成ファイル、bc4j.xcfgが更新されます。このファイルは、1つのJavaパッケージ内の全アプリケーション・モジュールの構成を定義しています。たとえば、Fusion Order DemoアプリケーションのStoreFrontプロジェクトの./classes/oracle/fodemo/storefront/store/service/commonディレクトリにあるbc4j.xcfgファイルを見ると、そのStoreServiceAMアプリケーション・モジュール用に名前の付いた構成が3つあることがわかります。
bc4j.xcfgファイルで定義された構成により、Fusion Webアプリケーションはデプロイ済の特定のアプリケーション・モジュールとの対話が可能になります。bc4j.xcfgファイルには、アプリケーション・モジュールの接続タイプに加えて、アプリケーション・モジュール名に関するメタデータ情報と、アプリケーション・モジュールに構成されたランタイム・パラメータが含まれています。名前付き接続タイプのアプリケーション・リソース・データベース接続の詳細は、アプリケーション・ナビゲータのConnectionsフォルダに定義され、アプリケーションのconnection.xmlファイルに格納されています。
例9-3に、Fusion Order Demoアプリケーションのbc4j.xcfgファイル例を示します。StoreServiceAMLocalおよびStoreServiceAMLocalWebの構成は、どちらもJDBCDataSource属性内のデータソース(名前はFODDS)を参照します。構成StoreFrontServiceは、最終的にターゲット・アプリケーション・サーバー上で定義されるデータ・ソースを参照します。各構成のJDBCDataSource属性には、アプリケーション・リソース接続名のJNDI名を、java:comp/env/jdbc/applicationConnectNameDSの形式で指定します。ここで、applicationConnectNameは、JDeveloper(この場合はFOD)で定義されたアプリケーション・リソース・データベース接続名です。このJNDIネーミング規則(アプリケーション固有ネームスペースjava:comp/env/jdbc/およびDSをアプリケーション・リソース・データベース接続名に付加したもの)により、デプロイされたFusion Webアプリケーションは、変更を加えなくてもアプリケーションのグローバル・データソースを使用してOracle WebLogic Server上で実行されます。グローバル・データ・ソースは通常、アプリケーション・サーバー管理者がOracle WebLogic Server管理コンソールを使用して定義します。
例9-3 bc4j.xcfgファイルのアプリケーション・モジュール・データベース構成
<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
<AppModuleConfigBag ApplicationName="oracle.fodemo.storefront.store.service.StoreServiceAM">
<AppModuleConfig
DeployPlatform="LOCAL"
jbo.project="StoreFrontService"
name="StoreServiceAMLocal"
ApplicationName="oracle.fodemo.storefront.store.service.StoreServiceAM">
<Database jbo.locking.mode="optimistic"/>
<Security AppModuleJndiName="oracle.fodemo.storefront.store.service.StoreServiceAM"/>
<Custom JDBCDataSource="java:comp/env/jdbc/FODDS"/>
</AppModuleConfig>
<AppModuleConfig
DeployPlatform="LOCAL"
jbo.project="StoreFrontService"
name="StoreServiceAMLocalWeb"
ApplicationName="oracle.fodemo.storefront.store.service.StoreServiceAM">
<AM-Pooling jbo.ampool.initpoolsize="1"/>
<Database jbo.locking.mode="optimistic"/>
<Security AppModuleJndiName="oracle.fodemo.storefront.store.service.StoreServiceAM"/>
<Custom JDBCDataSource="java:comp/env/jdbc/FODDS" fod.application.issoaenabled="false"/>
</AppModuleConfig>
<AppModuleConfig
DeployPlatform="SI"
jbo.project="StoreFrontService"
name="StoreFrontService"
ApplicationName="oracle.fodemo.storefront.store.service.StoreServiceAM">
<Database jbo.TypeMapEntries="Java" jbo.locking.mode="optimistic"/>
<Security AppModuleJndiName="oracle.fodemo.storefront.store.service.StoreServiceAM"/>
<Custom JDBCDataSource="java:comp/env/jdbc/FODDS"/>
</AppModuleConfig>
</AppModuleConfigBag>
</BC4JConfig>
アプリケーション・モジュールのXMLコンポーネント定義の作成に加え、JDeveloperでは、アプリケーション・モジュールのXMLコンポーネント定義ファイルを含むディレクトリを相対位置とするcommonという名前のサブディレクトリにあるbc4j.xcfgファイルにappModuleNameLocalという名前のデフォルトの構成も追加します。bc4j.xcfgファイルは、アプリケーション・ナビゲータには表示されません。デフォルト設定を表示したり、アプリケーション・モジュールのランタイム構成の設定を変更するには、図9-12に示す「ビジネス・コンポーネント構成の編集」ダイアログを使用します。
作業を始める前に、次のようにします。
アプリケーション・モジュール・データソース接続に関する知識があると役立つ場合があります。詳細は、9.3項「アプリケーション・モジュールのデータベース接続の構成」を参照してください。
アプリケーション・モジュールの構成を管理する手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「構成」ナビゲーション・タブをクリックします。
「構成」ページで、編集する構成をダブルクリックします。次の3つのデフォルト構成が表示される可能性があります。
appModuleNameLocal: アプリケーション・モジュールを作成すると、自動的にローカル構成が1つ定義されます。テスト目的でアプリケーション・モジュールのランタイム・プロパティを変更する場合などは、新しいローカル構成を作成してください。
appModuleNameShared: 共有アプリケーション・モジュール構成が存在するのは、データ・モデル・プロジェクトの「プロジェクト・プロパティ」ダイアログで共有アプリケーション・モジュールの名前付きインスタンスが定義されている場合のみです。共有アプリケーション・モジュールは、アプリケーション全体で静的データのリストを再利用する場合に、ビュー・インスタンスをグループ化したアプリケーション・モジュールです。たとえば、共有アプリケーション・モジュールを定義して、国リストなどの参照データにアクセスするビュー・インスタンスをグループ化できます。
appModuleNameService (サービス・インタフェースのタイプSI): サービス・インタフェース構成が存在するのは、アプリケーション・モジュールの概要エディタの「サービス・インタフェース」ページでサービス・インタフェース(Webサービス実装ラッパー)が定義されている場合のみです。Webサービスとして公開されているアプリケーション・モジュールでは、アプリケーション・モジュールをコンポジット・アプリケーションに組み込んで、Webサービス・クライアントからデータ・アクセスやメソッド呼出しができます。同じアプリケーション・モジュールで、ADFデータ・コントロールおよびWebサービス・クライアントを使用する対話型のWebユーザー・インタフェースをサポートできます。
「ビジネス・コンポーネント構成の編集」ダイアログで、目的の実行時プロパティを編集し、「OK」をクリックして構成の変更を保存します。
アプリケーションの開発時、多数の異なるユーザーやスキーマを切り替える場合があります。これには、そのビジネス・コンポーネントを含むプロジェクトのデータベース接続プロパティを変更します。選択を行うと、プロジェクトのbc4j.xcfgファイルで、JDBC URLタイプ接続を指定する各構成の接続文字列が自動的に更新されます。
作業を始める前に、次のようにします。
アプリケーション・モジュール・データソース接続に関する知識があると役立つ場合があります。詳細は、9.3項「アプリケーション・モジュールのデータベース接続の構成」を参照してください。
アプリケーション・モジュールの構成で使用する接続を変更する手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールが含まれているプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ビジネス・コンポーネント」を選択して現在のデータベース接続の詳細を表示する「ビジネス・コンポーネント」ページを表示します。
「編集」をクリックし、「データベース接続の編集」ダイアログで、適切な変更を行います。
「OK」をクリックします。
アプリケーション・モジュールでは、高レベルな機能により複数のビジネス・ワークフローに共通なサブ機能が再使用される、ユースケースのモジュール性を模倣するソフトウェア・コンポーネントを作成する機能をサポートしています。このモジュール性は、他のアプリケーション・モジュールのインスタンスを使用してアセンブルする複合アプリケーション・モジュールを定義することで実装できます。このタスクはアプリケーション・モジュールのネストと呼ばれています。つまり、アプリケーション・モジュールにはビュー・オブジェクトのみでなく(論理的に)1つ以上の他のアプリケーション・モジュールを含めることが可能ということです。最も外側に含まれているアプリケーション・モジュールは、ルート・アプリケーション・モジュールと呼ばれています。
ネストされたアプリケーション・モジュール定義の宣言的サポートは、図9-14に示すように、アプリケーション・モジュールの概要エディタから使用できます。アプリケーション・モジュールのAPIでも、実行時のアプリケーション・モジュールのネストがサポートされています。
アプリケーション・モジュールのインスタンスを別のアプリケーションにネストするときは、ビュー・オブジェクトをそのデータ・モデルに集約するのみならず、そこで定義されているカスタム・サービス・メソッドも集約します。アプリケーション・モジュールのインスタンスを別のアプリケーション・モジュール内でネストまたは再利用するこの機能は、大規模で実用的なアプリケーション・システムを実装するための、ADF Business Componentsの最も強力な設計要素の1つです。
アプリケーション・モジュールによりエンド・ユーザーのユースケースまたはワークフローに示される基本ロジックを使用すると、一部の共有のモジュール化ユースケースで必要なデータを提供するアプリケーション・モジュールを作成でき、より複雑なユースケースをサポートするように設計されている、より複雑な別のアプリケーション・モジュール内でそれらのアプリケーション・モジュールを再使用できます。たとえば、アプリケーション・モジュールStoreServiceAMおよびProductServiceを作成した後に、この両方のサービスを新しいCompositeServiceアプリケーション・モジュールの不可欠な部分として使用するアプリケーションの作成が必要になったとします。図9-13は、このCompositeServiceがJDeveloperのビジネス・コンポーネント・ダイアグラムでどのように表示されるかを示しています。この図に示すように、CompositeServiceなどのアプリケーション・モジュールには、ビュー・オブジェクト・インスタンスとアプリケーション・モジュール・インスタンスの両方を含めることができます。
既存のアプリケーション・モジュールのインスタンスをネストする複合ルート・アプリケーション・モジュールを指定するには、アプリケーション・モジュールの概要エディタを使用します。(アプリケーション・モジュール・インスタンスに含まれる)ネストされたすべてのコンポーネント・インスタンスでは、それらのインスタンスを再使用するルート・アプリケーション・モジュールと同じトランザクションとエンティティ・オブジェクト・キャッシュが共有されます。
|
ヒント: ネストされたアプリケーション・モジュールをアプリケーションで利用する場合は、13.3.1.4項「データ・コントロール」パネルでのネストされたアプリケーション・モジュールの表示」を必ず参照してください。また、これらのモジュールを含むデータ・バインディングの実行時によく発生する問題を回避してください。 |
作業を始める前に、次のようにします。
ネストされたアプリケーション・モジュールに関する知識があると役立つ場合があります。詳細は、9.4項「ネストされたアプリケーション・モジュールの定義」を参照してください。
次のタスクを完了します。
ネストされたアプリケーション・モジュールを定義する手順:
アプリケーション・ナビゲータで、ルート・アプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
データ・モデル・コンポーネント」ページの「アプリケーション・モジュール・インスタンス」セクションを展開し、「使用可能」リストで、データ・モデルに追加するアプリケーション・モジュールを選択します。
リストの下の「新規アプリケーション・モジュール・インスタンス」フィールドに、データ・モデルに追加するネストされたアプリケーション・モジュールを識別する際に使用される名前が示されます。
アプリケーション・モジュールを追加する前に名前を変更するには、「新規アプリケーション・モジュール・インスタンス」フィールドに別の名前を入力します。
目的のアプリケーション・モジュールを選択し、「選択済」リストに移動します。
図9-14では、アプリケーション・モジュールLookupServiceAMの名前をNestedLookupServiceAMに変更してから、「選択済」リストに移動しています。
実行時に、アプリケーションはメインの、またはルートと呼ばれている、アプリケーション・モジュールを使用します。どのアプリケーション・モジュールもルート・アプリケーション・モジュールとして使用できますが、実際には、単純なCRUDアプリケーションを作成している場合を除き、より複雑なエンド・ユーザーのユースケースに対応するアプリケーション・モジュールがルートとして使用されます。ルート・アプリケーション・モジュールに別のアプリケーション・モジュールがネストされている場合、そのモジュールはすべてルート・アプリケーション・モジュールのトランザクションに関与し、同じデータベース接続および単一のエンティティ・キャッシュ・セットを共有します。この共有は、ルート・アプリケーション・モジュールおよびそのTransactionオブジェクトによって自動的に処理されます。
また、トランザクション境界を宣言的に管理するためADFバインド・タスク・フローを使用してアプリケーションを作成する場合、Oracle ADFフレームワークにより実行時にタスク・フローで使用されるアプリケーション・モジュールが自動的にネストされます。バインド・タスク・フローとトランザクションの詳細は、22.3項「タスク・フローのトランザクションの管理」を参照してください。
ビジネス・サービスのデータ・モデルを開発する際、多くの場合、UMLモデルを使用して視覚化すると便利です。JDeveloperでは、他の開発者が参照できるアプリケーション・モジュール用のダイアグラムを簡単に作成できます。
アプリケーション・モジュールの編集、表示オプションの制御、メソッド名のフィルタ処理、関連するオブジェクトやファイルの表示、アプリケーションの公開、Oracle ADFモデル・テスターの起動など、多数のタスクをダイアグラム上で直接実行できます。
アプリケーション・モジュールのダイアグラムを作成するには、「新規ギャラリ」から使用できる「ビジネス・コンポーネント・ダイアグラムの作成」ダイアログを使用します。
アプリケーション・モジュールのダイアグラムを作成する手順:
アプリケーション・ナビゲータで、ダイアグラムを作成するプロジェクトを右クリックし、「新規」をクリックします。
「新規ギャラリ」で、「ビジネス層」を展開し、「ADF Business Components」を選択したら、「ビジネス・コンポーネント・ダイアグラム」を選択し、「OK」をクリックします。
「ビジネス・コンポーネントの作成」ダイアログで、ダイアグラム名と、ダイアグラムの作成先のパッケージ名を入力します。
「OK」をクリックすると、空のダイアグラムが作成され、ダイアグラマを開きます。
既存のアプリケーション・モジュールを開いているダイアグラムに追加するには、追加するモジュールをアプリケーション・ナビゲータで選択してダイアグラム画面にドロップします。
プロパティ・インスペクタを次の目的で使用します。
パッケージ名の非表示化
フォントの変更
グリッドおよび改ページの非表示化
ビュー・リンク・コネクタ上の終了名(マスター/ディテール)の非表示化
これらの手順の完了後、ダイアグラムは図9-15のようになります。
ビジネス・コンポーネント・ダイアグラムを作成すると、ダイアグラムが格納されているパッケージ名と一致するプロジェクトのモデル・パスのサブディレクトリに、ダイアグラムを示す.adfbc_diagramファイルが作成されます。
デフォルトでは、アプリケーション・ナビゲータによってプロジェクト・コンテンツ・パスの表示が統一され、ソース・パスのADFコンポーネントおよびJavaファイルがプロジェクト・モデル・パスのUMLモデル・アーティファクトと同じパッケージ・ツリーに表示されます。アプリケーション・ナビゲータの「ナビゲータの表示オプション」→「ディレクトリの表示」ツールバー・オプションを使用して、統一されたディレクトリ・ビューと、個々のプロジェクト・コンテンツのディレクトリ・パス・ビューを切り替えることができます。
ビジネス・コンポーネントのUMLダイアグラムは、アプリケーション・モジュールをダイアグラムにドロップした時点の状態を示す単なる静的な図ではありません。むしろ、UMLダイアグラムは、現在のコンポーネント定義をUMLベースでレンダリングした図であるため、常に現在の状況を示しています。UMLダイアグラムは、視覚化を可能にするのみならず、視覚的なナビゲーションおよび編集ツールでもあります。
ポップアップ・メニューから「プロパティ」を選択(またはアプリケーション・モジュールをダブルクリック)すると、任意のアプリケーション・モジュールの概要エディタを起動できます。
また、ビュー・オブジェクト・インスタンス名の変更、ビュー・オブジェクト定義をアプリケーション・ナビゲータからデータ・モデルにドロップすることによる新しいビュー・オブジェクト・インスタンスの作成、[Del]キーを押すことによるビュー・オブジェクト・インスタンスの削除など、いくつかのアプリケーション・モジュール編集タスクもダイアグラム上で直接実行できます。
|
注意: コンポーネントをダイアグラムから削除すると、その表示のダイアグラム画面からの削除のみが行われます。コンポーネントおよびクラスは、ファイル・システムおよびアプリケーション・ナビゲータに残ります。 |
ダイアグラムでアプリケーション・モジュールを表示後、プロパティ・インスペクタを使用してオプションを表示します。
「Display Options」カテゴリで、プロパティを次のように切り替えます。
メソッドの表示 - サービス・メソッドを表示
パッケージを表示: パッケージ名を表示
ステレオタイプの表示 - オブジェクトの型を表示(「<<application module>>」など)
使用方法の表示: 現在のプロジェクトの他のアプリケーション・モジュールによるすべての使用を表示
|
注意: operationは、メソッドに対する汎用性の高いUML名です。 |
「Operations」カテゴリでは、ダイアグラムに求められる詳細のレベルに応じて次のプロパティを変更します。
パラメータ・スタイル
戻りタイプの表示
可視性の表示(「public」、「private」など)
図9-16のプロパティ・インスペクタの設定に示すように、デフォルトでは、アプリケーション・モジュールのすべての操作が表示されます。
ダイアグラムのコンテキスト・メニューでは、「表示モード」に対して次を選択することもできます。
圧縮: アイコンおよび名前のみを表示
シンボル: サービス操作を表示
展開済 - 操作およびデータ・モデルを表示(デフォルト)
デフォルトでは、アプリケーション・モジュールの操作を表示すると、ダイアグラムにすべてのメソッドが表示されます。上書きされたフレームワーク・メソッドとして認識されるメソッドは、すべて「Framework」操作カテゴリに表示されます。他のメソッドは、「Business」メソッド・カテゴリに表示されます。
プロパティ・インスペクタの「操作」カテゴリにある「名前フィルタ」プロパティは、ダイアグラムでの表示が不要なメソッドのフィルタ処理に使用できる正規表現です。たとえば、「名前フィルタ」プロパティを次のように設定します。
findLoggedInUser.*|retrieveOrder.*|get.*
この場合、次のアプリケーション・モジュール・メソッドをすべてフィルタ処理できます。
findLoggedInUserByEmail
retrieveOrderById
生成されたビュー・オブジェクトのgetterメソッド全般
ダイアグラム上でアプリケーション・モジュール(またはそのデータ・モデル内の任意の個別ビュー・オブジェクト・インスタンス・セット)の選択後、「表示」→「関連する要素」をコンテキスト・メニューから選択し、ダイアグラムに関連するコンポーネントを表示できます。同様に、「表示」→「実装ファイル」を選択することで、アプリケーション・モジュールを実装するファイルをダイアグラムに含むことができます。求められる詳細のレベルがダイアグラムに追加されるまで、表示されている追加ダイアグラム要素に対して前述のオプションを繰り返し使用できます。
図9-17は、アプリケーション・モジュールの実装ファイルを表示した図を示しています。この図には、アプリケーション・モジュールの実装クラスの関連要素(StoreServiceAMImpl)が表示されています。また、アプリケーション・モジュールと実装クラス間の依存性を示す追加の線も表示されています。特定のカスタム・インタフェースにアプリケーション・モジュール・インスタンスをキャストした場合でも、図のように表示されます。
ダイアグラムをPNG、JPG、SVGまたは圧縮されたSVG書式で公開するには、ダイアグラム上でポップアップ・メニューから「ダイアグラムの公開」を選択します。
Fusion Webアプリケーションとの対話中に、エンド・ユーザーには次のような状況が発生する場合があります。
同じページを複数回表示する場合に、迅速なレスポンスを期待
完了までに多数のページを表示する必要がある論理作業ユニットを実行
未保存の保留中の変更内容の部分的なロールバックの実行を要求
サーバー・ファームのアプリケーション・サーバー障害による、保存前の保留中の変更への不可抗力的な被害
アプリケーション・モジュール・プーリング機能および状態管理機能では、これらの要件に対処するスケーラブルで高パフォーマンスの実装を簡略化します。
|
注意: ADFバインド・タスク・フローは、トランザクションの作業ユニットを表します。タスク・フローのオプションを指定して、トランザクションの処理方法を決定できます。ADFバインド・タスク・フローの宣言的な機能の詳細は、22.3項「タスク・フローのトランザクションの管理」を参照してください。 |
状態管理機能をシミュレートするには、アプリケーション・ナビゲータで、アプリケーション・モジュール上の2つのOracle ADFモデル・テスターのインスタンスを起動します。
作業を始める前に、次のようにします。
状態管理に関する知識があると役立つ場合があります。詳細は、9.6項「複数ページの作業ユニットのサポート」を参照してください。
Oracle ADFモデル・テスターを使用してトランザクション状態の受動化をシミュレートするには:
Oracle ADFモデル・テスターを実行し、ビュー・オブジェクト・インスタンスをダブルクリックしてそのデータを問い合せます。
数行の属性の現在の値をメモします。
これらの行の属性を別の値に更新します。ただし、変更はコミットしないでください。
Oracle ADFモデル・テスターのメイン・メニューから、「ファイル」→「トランザクション状態の保存」を選択します。
「受動化されたトランザクション状態」ダイアログが開き、トランザクションID番号が表示されます。この番号をメモします。
Oracle ADFモデル・テスターを完全に終了します。
Oracle ADFモデル・テスターを再起動し、同じビュー・オブジェクト・インスタンスをダブルクリックしてそのデータを問い合せます。
データは変更されない点に注意してください。データから問い合せたデータは、データベースの現在の状態を示し、前述の変更は反映されていません。
Oracle ADFモデル・テスターのメイン・メニューから、「ファイル」→「トランザクション状態のリストア」を選択し、ステップ4でメモしたトランザクションIDを入力します。
この時点で、保留中の変更が、変更した行に再反映されます。ここでトランザクションをコミットすると、変更内容はデータベースに永続的に保存されます。
アプリケーション・モジュールをそのビジネス・サービスとして利用するアプリケーションを作成すると、そのアプリケーションでは自動アプリケーション・モジュール・プーリング機能を使用できます。この機能では、アプリケーションに対するエンド・ユーザーの負荷(ロード)の日中の変化に応じて増減するアプリケーション・モジュール・インスタンスの構成可能なセットを管理します。アプリケーション・ユーザー・インタフェースとのエンド・ユーザーの対話に特有の思考時間の性質により、プール内のアプリケーション・モジュール・インスタンスの数は、システムを使用しているアクティブ・ユーザーの合計数より少なくなる場合があります。
図9-18に示すように、あるエンド・ユーザーがアプリケーションの複数ページを表示して論理タスクを実行する場合、各ページ・リクエストに対し、プール内のアプリケーション・モジュール・インスタンスがその1リクエストの存続時間中にプールから自動的に取得されます。リクエストの最後に、インスタンスはプールに自動的に戻され、別のユーザー・セッションで使用可能になります。エンド・ユーザーの作業をアプリケーション・サーバーの障害から保護するために、アプリケーション・モジュールでは、そのエンティティ・キャッシュ内の保留中の変更セットを示すXMLスナップショットを保存することで、その変更セットを永続ストアに格納する機能をサポートしています。スケーラビリティ上の理由から、この状態スナップショットは通常、アプリケーション・データを含むデータベース・スキーマとは別の状態管理スキーマに保存されます。
プーリング・アルゴリズムではチューニング可能な最適化が行え、特定数のアプリケーション・モジュール・インスタンスが、プールに戻された最後のユーザー・セッションとの「スティッキー」な状態を維持しようとします。最適化は保証されていませんが、ユーザーが最適化による利益を得ることができれば、システム・ローダーが許容する限り、プール内の同じアプリケーション・モジュール・インスタンスを継続的に使用します。負荷が重すぎる場合、プーリング・アルゴリズムはプール内で使用可能な任意のインスタンスを使用してユーザーのリクエストに応え、その論理作業単位の凍結スナップショットを永続ストアから再構築して、アプリケーション・モジュールの新しいインスタンスが前回途中になったところから継続できるようにします。エンド・ユーザーは変更をコミットまたはロールバックするまで、この方法で作業を継続します。
アプリケーション・モジュールはこれらの機能を使用し、完全にステートレスなアプリケーションに近い実行時パフォーマンスを実現するアーキテクチャにおいて、複数ページのワークフローを簡単に処理できる、生産性の高いステートフルな開発パラダイムを実現します。これらのアプリケーション・モジュール機能の詳細は第43章「アプリケーション状態管理」を、チューニング方法の詳細は第44章「アプリケーション・モジュール・プールと接続プールのチューニング」を参照してください。
|
注意: このアプリケーション・モジュール・プーリングおよび状態管理の機能は、デスクトップ・フィデリティのシン・クライアントSwingアプリケーションおよびWebスタイルのユーザー・インタフェースにも使用できます。 |
アプリケーション・モジュールでは、カスタムJavaコードを必要とせずに、そのビュー・オブジェクトのデータ・モデルをクライアントに公開できます。このため、クライアント・コードではoracle.jboパッケージのApplicationModule、ViewObject、RowSetおよびRowというインタフェースを使用して、データ・モデル内のビュー・オブジェクトを直接操作できます。ただし、クライアント・コードで自由にビュー・オブジェクトをプログラミングで操作できても、それが必ずしもベスト・プラクティスではありません。
ビュー・オブジェクトを操作するプログラム的なコードが完全なビジネス・サービス機能を実装するための論理的な特徴を備えている場合、アプリケーション・モジュールのJavaクラスでカスタム・メソッドを記述して、詳細をカプセル化する必要があります。これには次のコードが含まれます。
表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成
集計結果を取得するための、ビュー・オブジェクト行の反復処理
1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行
これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。
コードの目的が、クライアントにより明確に伝わります。
必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。
ビジネス・サービス機能全体の回帰テストを簡略化できます。
クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。
ページ内での論理的ビジネス機能の宣言的起動が可能になります。
カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、まずそのカスタムJavaクラスを有効化する必要があります。IDEレベルの「ビジネス・コンポーネント」のJava生成設定で、アプリケーション・モジュール・クラスが自動的に生成されるように構成されている場合は、カスタム・クラスが発生します。図9-19に示すように、アプリケーション・モジュールにカスタムJavaクラスがあるかどうかが不明な場合は、アプリケーション・ナビゲータでそのアプリケーション・モジュール・ノードの概要エディタを開きます。エディタの「Javaクラス」ページに、プロジェクトのアプリケーション・モジュール用に生成されたクラスの完全リストが表示されます。他のユーザーによりすでにファイルが作成されているため存在する場合、「Javaクラス」ページには「アプリケーション・モジュール・クラス」として特定された、リンクされたファイル名が表示されます。ソース・エディタで既存ファイルを開くには、対応するファイル名のリンクをクリックします。
プロジェクトにJavaクラスが存在しない場合、アプリケーション・モジュールの概要エディタの「Javaクラス」ページで生成できます。
作業を始める前に、次のようにします。
アプリケーション・モジュールのサービス・メソッドに関する知識があると役立つ場合があります。詳細は、9.7項「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。
次のタスクを完了します。
アプリケーション・モジュール・クラスのJavaファイルを生成する手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」ボタンをクリックします。
「Javaオプションの選択」ダイアログで、「アプリケーション・モジュール・クラスの生成」を選択します。
「OK」をクリックします。
「Javaクラス」ページに新しい.javaファイルが表示されます。
アプリケーション・モジュールのカスタム・クラスを生成すると、JDeveloperではコンポーネントのXMLコンポーネント定義ファイルと同じディレクトリにファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleNameImpl.javaになります。
アプリケーション・モジュールに対して選択したJava生成オプションは、アプリケーション・モジュールの概要エディタの「Javaクラス」ページに後でアクセスしてもそのまま反映されています。XML定義ファイルの場合と同様、このエディタでどのような変更を行っても、カスタムJavaクラスで生成されたコードは最新の状態に保たれます。後でカスタムJavaファイルが不要になった場合は、「Javaクラス」ページから「Javaオプションの選択」ダイアログを開き、「アプリケーション・モジュール・クラスの生成」の選択を解除すると、プロジェクトからカスタムJavaファイルが削除されます。
デフォルトでは、アプリケーション・モジュールのJavaクラスは、最初に有効化した際、例9-4のようになります。この内容は次のとおりです。
データ・モデル内の各ビュー・オブジェクト・インスタンス用のgetterメソッド
Oracle ADFモデル・テスターを使用したアプリケーション・モジュールのデバッグを可能にするmain()メソッド
例9-4 デフォルトで生成されるアプリケーション・モジュールのコード
package devguide.model;
import devguide.model.common.StoreServiceAM;
import oracle.jbo.server.ApplicationModuleImpl;
import oracle.jbo.server.ViewLinkImpl;
import oracle.jbo.server.ViewObjectImpl;
// ---------------------------------------------------------------------
// --- File generated by Oracle ADF Business Components Design Time.
// --- Custom code may be added to this class.
// --- Warning: Do not modify method signatures of generated methods.
// ---------------------------------------------------------------------
public class StoreServiceAMImpl extends ApplicationModuleImpl {
/** This is the default constructor (do not remove) */
public StoreServiceImpl() { }
/** Container's getter for YourViewObjectInstance1 */
public ViewObjectImpl getYourViewObjectInstance1() {
return (ViewObjectImpl)findViewObject("YourViewObjectInstance1");
}
// ... Additional ViewObjectImpl getters for each view object instance
// ... ViewLink getters for view link instances here
}
図9-20に示すように、アプリケーション・モジュール・クラスでは、カスタム・コードを追加する前にすべてのデフォルト動作を継承するようにベースADFのApplicationModuleImplクラスを拡張します。
カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、アプリケーション・モジュールのカスタム・クラスに移動して、新しいメソッドのJavaコードをアプリケーション・モジュールのJava実装クラスに入力します。次のガイドラインを使用して、メソッドに適切な可視性を判断してください。
メソッドをこのコンポーネントの実装内でヘルパー・メソッドとしてのみ使用する場合は、メソッドをprivateにします。
アプリケーション・モジュールの最終的なサブクラスでこのメソッドを起動または上書きできるようにする場合は、メソッドをprotectedにします。
クライアントによる起動を可能にする場合は、publicにする必要があります。
|
注意: この章の |
例9-5は、StoreServiceAMアプリケーション・モジュールのStoreServiceAMImpl.javaクラスでのprivate retrieveOrderById() ヘルパー・メソッドを示しています。ここでは、関連するエンティティ定義にアクセスするためにOrdersEOImplエンティティ・オブジェクト・クラスのstatic getDefinition()メソッドが使用され、注文の検索に適したKeyオブジェクトを作成するためにエンティティ・オブジェクト・クラスでcreatePrimaryKey()メソッドが使用され、エンティティ行をエンティティ・キャッシュで検索するためにエンティティ定義でfindByPrimaryKey()メソッドが使用されています。このメソッドからは、強く型付けされたOrdersEOImplクラス(OrderEOエンティティ・オブジェクトのカスタムJavaクラス)のインスタンスが戻されます。
例9-5 カスタム・アプリケーション・モジュール・クラスのprivateヘルパー・メソッド
// In devguide.model.StoreServiceAMImpl class
/*
* Helper method to return a Order by Id
*/
private OrdersEOImpl retrieveOrderById(long orderId) {
EntityDefImpl orderDef = OrdersEOImpl.getDefinitionObject();
Key orderKey =
OrdersEOImpl.createPrimaryKey(new DBSequence(orderId));
return (OrdersEOImpl)orderDef.findByPrimaryKey(getDBTransaction(),
orderKey);
}
例9-6は、作成する製品の名前および説明をコール元が渡すことを可能にするpublic createProduct()メソッドを示しています。ここでは、関連するエンティティ定義にアクセスするためにProductImplエンティティ・オブジェクト・クラスのgetDefinition()メソッドが使用され、トランザクションをコミットする前に渡されるパラメータ値が移入されるNameおよびDescription属性を持つProductImplエンティティ行を新規作成するためにcreateInstance2()メソッドが使用されています。
例9-6 カスタム・アプリケーション・モジュール・クラスのpublicメソッド
/*
* Create a new Product and Return its new id
*/
public long createProduct(String name, String description) {
EntityDefImpl productDef = ProductImpl.getDefinitionObject();
ProductImpl newProduct =
(ProductImpl)productDef.createInstance2(getDBTransaction(),null);
newProduct.setName(name);
newProduct.setDescription(description);
try {
getDBTransaction().commit();
}
catch (JboException ex) {
getDBTransaction().rollback();
throw ex;
}
DBSequence newIdAssigned = newProduct.getProdId();
return newIdAssigned.getSequenceNumber().longValue();
}
カスタム・アプリケーション・モジュールのメソッドをテストする準備ができたら、JDeveloperを使用してJUnitテスト・ケースを生成できます。JUnitでは、oracle.jbo packageで使用可能な任意のプログラムのAPIを使用して、アプリケーション・モジュールの操作およびカスタム・メソッドを起動が可能です。ADF Business ComponentsでのJUnit使用の詳細は、36.11項「JUnitを使用した回帰テスト」を参照してください。
JUnitテスト・ケースの代替方法として、カスタム・アプリケーション・モジュール・メソッドをテストする一般的な方法は、簡単なテスト・ケースを作成することです。たとえば、テスト用のコードをオブジェクトに作成し、そのコードをstatic main()メソッドに含めます。例9-7は、これから記述するサンプル・メソッドをテストするために、カスタム・アプリケーション・モジュール・クラスに追加できるサンプルのmain()メソッドを示しています。Configurationオブジェクトを使用して(6.4.2項「コマンドラインJavaテスト・クライアントの作成方法」を参照)、テスト用のアプリケーション・モジュールをインスタンス化および操作します。
|
注意:
|
例9-7のコードを見ると、これまでの例で作成した4つのメソッドを使用して次が実行されていることがわかります。
注文1011の合計を取得します。
注文1011の顧客名を取得します。
1011の注文ステータスを「CANCEL」の値に設定します。
製品名がnullの新しい製品を作成します。
製品名を付けて新しい製品を作成し、新しく割り当てた製品IDを表示します。
例9-7 カスタム・アプリケーション・モジュールを内部からテストするmainメソッドのサンプル
// Main method in StoreServiceAMImpl.java
public static void main(String[] args) {
String amDef = "devguide.model.StoreFrontService";
String config = "StoreServiceLocal";
/*
* This is the correct way to use application custom methods
* from the client, by using the application module's automatically-
* maintained custom service interface.
*/
// 1. Acquire instance of application module, cast to client interface
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
/*
* NOTE: This cast to use the StoreFrontServiceImpl class is OK since this
* code is inside a business tier *Impl.java file and not in a
* client class that is accessing the business tier from "outside".
*/
StoreFrontServiceImpl service = (StoreFrontServiceImpl)am;
String total = service.findOrderTotal(1011);
System.out.println("Total for Order # 1011 = " + total);
String customerName = service.findOrderCustomer(1011);
System.out.println("Customer for Order # 1011 = " + customerName);
try {
service.updateOrderStatus(1011,"CANCEL");
}
catch (JboException ex) {
System.out.println("ERROR: "+ex.getMessage());
}
long id = 0;
try {
id = service.createProduct(null, "NEW", "CLASS1");
}
catch (JboException ex) {
System.out.println("ERROR: "+ex.getMessage());
}
id = service.createProduct("Canon PowerShot G9", "NEW", "CLASS1");
System.out.println("New product created successfully with id = "+id);
Configuration.releaseRootApplicationModule(am,true);
}
カスタム・アプリケーション・モジュール・クラスを実行すると、例9-7のmain()メソッドがコールされ、次の出力が表示されます。
Total for Order # 1011 = 99.99 Customer for Order # 1011 = John Chen ERROR: JBO-27014: Attribute ProductName in ProductsBaseEO is required. New product created successfully with id = 133
製品名をnullとしてcreateProduct()をコールしようとした初回の試みでは、Productエンティティ・オブジェクトのName属性に対する組込み必須検証が原因で例外が発生しています。
|
注意: カスタム・アプリケーション・モジュールに作成したカスタム・サービスをクライアント・アプリケーションを使用して起動する方法の詳細は、9.9項「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。 |
アプリケーション・ロジックが行セットにアクセスし、プログラムによる反復を実行する場合は必ず、ユーザー・インタフェース・コンポーネントにバインドされている可能性があるので、アプリケーション・モジュールのデータ・モデル内のビュー・オブジェクト・インスタンス、またはこれらのビュー・オブジェクト・インスタンスのビュー・リンク・アクセッサ行セットを扱う際に、セカンダリ行イテレータを使用する必要があります。セカンダリ・イテレータを作成するには、作業対象の行セットに対してcreateRowSetIterator()メソッドを使用します。使用を修了したら、行セットに対してcloseRowSetIterator()メソッドを呼び出し、メモリーからセカンダリ・イテレータを削除する必要があります。例9-8には、プログラムによる反復のためにセカンダリ行セット・イテレータを正しく使用する典型的なアプリケーション・モジュールを示します。これは、データ・モデル内のEmpView1ビュー・オブジェクト・インスタンスが、ユーザー・インタフェースにバインドされている(現在または後で)ために使用されます。
例9-8 アプリケーション・モジュールのカスタム・メソッドにおけるセカンダリ行セット・イテレータの使用
// Custom method in an application module implementation class
public void doSomeCustomProcessing() {
ViewObject vo = getEmpView1();
// 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.
}
// close secondary row set iterator
iter.closeRowSetIterator();
}
|
注意: 行セットのデフォルト行セット・イテレータを使用して独自の行セットの反復を行う、ビュー・オブジェクトの実装クラス内のカスタム・コードについても同じことがお薦めされます。 |
このような推奨は次の2つの重要な理由のために行っています。これを行わなかった場合、現在の行が予期せず変更された場合にエンド・ユーザーを混乱させてしまいます。また、最初または最後の行、あるいは両方の行がスキップされてしまうため、検出が難しいビジネス・ロジック・エラーが発生してしまうことがあります。
現在の行が突然変更されることでエンド・ユーザーが混乱
イテレータ・バインディングは、エンド・ユーザーが行セット内でどの行を現在行として見ているのかを判断します。プログラムによるロジックがイテレータ・バインディングと同じデフォルト行セットイテレータを使用して行セットを反復している場合、ユーザーが現在選択している行を知らない間に変更してしまい、ユーザーを混乱させてしまうことがあります。
最初または最後の行を知らない間にスキップして、検出しにくいビジネス・ロジック・エラーを誘発
イテレータ・バインディングでは、行セット・イテレータを有効な行に強制的に配置して、行セットが空の場合に、UIコンポーネントがデータを表示できるようにします。これによってカスタム・ロジックが、最初の行の前のスロット、または最後の行の後ろのスロットに移動するのを防止する効果があります(イテレータ・バインディングと同じ行セット・イテレータを使用している場合)。具体的には、典型的なwhile (rowset.hasNext())反復ループは、例9-9に示したように、最初の行ではなく2番目の行を処理することでスキップまたは開始されます。
例9-9 デフォルト行セット・イテレータの使用結果
// Reset the default row set iterator to the slot before the first row
rowset.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 has only one row, the following will then return false
while (rowset.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 = rowset.next();
// Do something with current row
}
ADFアプリケーション・モジュールには独自のリソース・バンドルはなく、JDeveloperにはアプリケーション・モジュールとの連携を行う設計時はありません。ただし、カスタム・メッセージ文字列を含む.propertiesファイルを登録する場合は、アプリケーション・モジュール用に生成する定義クラス・ファイルにリソース・バンドル定義を設定できます。
アプリケーション・モジュールのカスタム定義クラス・ファイルを生成するには、アプリケーション・モジュールの概要エディタの「Javaクラス」ページで、アプリケーション・モジュール用に開く「Javaオプションの選択」ダイアログを使用します。このファイルを使用して、組込みメソッドであるfinishedLoading()をオーバーライドできます。
作業を始める前に、次のようにします。
9.2.1項「アプリケーション・モジュールの作成方法」に記載されている方法に従って、該当するアプリケーション・モジュールを作成します。
.propertiesファイルを作成し、4.7項「リソース・バンドルの使用」に記載の内容に従って、メッセージ・キーとメッセージを追加します。
作成する.propertiesファイルは、完全修飾パッケージ名とカスタム・メソッド例外メッセージによって、属性プロパティを参照できます。たとえば、メッセージ・キーと文字列を次のように定義します。
test.Order.Orderno_LABEL=Order Number INVALID=You have called the method foo in an invalid way.
リソース・バンドルでメソッドの例外メッセージ用メッセージを定義する場合、カスタム・メソッドは9.9.1項「アプリケーション・モジュールのクライアント・インタフェース上でのカスタム・メソッドの公開方法」に記載したように、アプリケーション・モジュール・クライアント・インタフェースに表示する必要があります。
たとえば例外メッセージINVALIDのかわりに、メソッドfoo()のメッセージを定義すると、インタフェースはリソース・バンドルからメッセージを呼び出すように、このメソッドを定義する場合があります。
public void foo() {
ResourceBundleDef r = getResourceBundleDef();
throw new JboException(r,"INVALID",null);
}
定義クラスを生成し、finishedLoading methodメソッドをオーバーライドするには、次の手順に従います。
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「Java」ナビゲーション・タブをクリックします。
「Javaクラス」ページで、「Javaオプションの編集」ボタンをクリックします。
「Javaオプションの選択」ダイアログで、「アプリケーション・モジュール定義クラスの生成」を選択し、「OK」をクリックします。
概要エディタの「Javaクラス」ページで、カスタマイズするアプリケーション・モジュール定義クラスにリンクされたファイル名をクリックします。ソース・エディタでクラス・ファイルが自動的に開きます。
メイン・メニューから、「ソース」→「メソッドのオーバーライド」を選択します。
メイン・メニューに「ソース」メニューが表示されていない場合は、定義クラス・ファイルが開いており、ソース・エディタが表示されていることを確認します。
「メソッドのオーバーライド」ダイアログで、リストをスクロールしてfinishedLoading()メソッドを検索し、選択して、「OK」をクリックします。
定義クラス・ファイルのソース・エディタで、メッセージ・バンドル.propertiesファイルを呼び出すコードを追加します。
たとえば、ファイルがtestパッケージ内のMyAMBundleの場合は、次のようなコードになります。
@Override
protected void finishedLoading() {
super.finishedLoading();
PropertiesBundleDef pbd = new PropertiesBundleDef(this);
pbd.setPropertiesFile("test.MyAMBundle");
setResourceBundleDef(pbd);
}
たとえば、finishedLoading()メソッドはメッセージ・バンドル定義を作成し、定義にカスタム・メッセージ・バンドルを設定します。
ファイルを保存します。
アプリケーション・モジュールのカスタム定義クラスを生成すると、JDeveloperではコンポーネントのXMLコンポーネント定義ファイルと同じディレクトリにファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleNameDefImpl.javaになります。
定義クラス・ファイル内の組込みfinishedLoading()メソッドをオーバーライドするので、実行時にアプリケーションをロードした後で、フレームワークはメソッドを呼び出し、指定された.propertiesファイルを自動的にロードします。
アプリケーション・モジュール・クラスにpublicカスタム・メソッドを追加する際に、アプリケーションのUIによるそのメソッドの起動を可能にする場合、そのメソッドをアプリケーション・モジュールのUIクライアント・インタフェースに追加する必要があります。
アプリケーション・モジュールのカスタムJavaクラスのpublicメソッドをクライアント・インタフェースに追加するには、アプリケーション・モジュールの概要エディタの「Javaクラス」ページを使用し、「クライアント・インタフェース」セクションの「編集」アイコンをクリックして、「クライアント・インタフェースの編集」ダイアログを表示します。「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして「選択済」リストに移動します。次に、「OK」をクリックしてエディタを閉じます。図9-21は、クライアント・インタフェースに追加した複数のpublicメソッドを示しています。
カスタム・サービス・メソッドをクライアント・インタフェースに公開すると、図9-22に示すように、アプリケーション・モジュールと同じ名前のJavaインタフェースが、アプリケーション・モジュールが存在するパッケージのcommonサブパッケージに作成されます。fodemo.modelパッケージのStoreServiceAMという名前のアプリケーション・モジュールでは、このインタフェースはStoreServiceAMという名前になり、fodemo.model.commonパッケージに作成されます。このインタフェースにより、oracle.jboパッケージのベースApplicationModuleインタフェースが拡張され、アプリケーション・モジュールがApplicationModuleImplクラスから継承するすべてのベース機能へのクライアント・アクセスが可能になります。
例9-10に示すように、StoreServiceAMインタフェースには、アプリケーション・モジュールのクライアント・インタフェースに配置するように選択したすべてのメソッドのメソッド・シグネチャが含まれています。
例9-10 「クライアント・インタフェース」パネルで選択されているメソッドに基づくカスタム・クライアント・インタフェース
package fodemo.model.common;
import oracle.jbo.ApplicationModule;
// ---------------------------------------------------------------------
// --- File generated by Oracle ADF Business Components Design Time.
// ---------------------------------------------------------------------
public interface StoreServiceAM extends ApplicationModule {
void deleteCurrentMyOrderItem();
void executeMyOrdersForCustomerVO();
void userRegistrationCreate(String userType);
void updateUserInterests(List pCategoryIds);
void userRegistrationCreateAddress();
}
|
注意: 新しいカスタム・メソッドをクライアント・インタフェースに追加した後で、JDeveloperのコード・インサイトによる状況依存の文補完を使用したときにこのカスタム・メソッドを使用できない場合は、生成されたクライアント・インタフェースの再コンパイルを試行してください。このためには、アプリケーション・モジュールをアプリケーション・ナビゲータで選択し、同じ名前のインタフェースのソース・ファイルを構造ウィンドウで選択し、「再ビルド」をポップアップ・メニューから選択します。このヒントは、ビュー・オブジェクトにかぎらず、ビュー行に追加された新しいカスタム・メソッドでも参考にしてください。 |
アプリケーション・モジュールのクライアント・インタフェースを生成することに加えて、カスタマイズ可能な他のキー・クライアント・オブジェクトを操作するための強く型付けされたクライアント・インタフェースも生成できます。たとえば、ビュー・オブジェクトの概要エディタで「Java」ページを開き、「クライアント・インタフェース」セクションと「カスタム行インタフェース」セクションを展開し、カスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースおよびビュー行クライアント・インタフェースにそれぞれ追加できます。
devguide.model.queriesパッケージのProductsビュー・オブジェクトに対してカスタム・ビュー・オブジェクトのJavaクラスの生成を可能にして1つ以上のカスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースに追加すると、図9-23に示すように、ProductsImplクラスおよびProductsインタフェースが生成されます。アプリケーション・モジュール・カスタム・インタフェースと同様に、commonサブパッケージに生成されます。
同様に、同じビュー・オブジェクトに対してカスタム・ビュー行のJavaクラスの生成を有効にして、1つ以上のカスタム・メソッドをビュー行クライアント・インタフェースに追加すると、図9-24に示すように、ProductsRowImplクラスおよびProductsRowインタフェースが生成されます。
カスタム・アプリケーション・モジュールのメソッドは、9.9項「UIクライアントへのカスタム・サービス・メソッドの公開」で説明しているように、クライアント・インタフェースに公開した後にOracle ADFモデル・テスターでテストできます。
公開したサービス・メソッドのテスト方法:
アプリケーション・ナビゲータで、目的のアプリケーション・モジュールおよびビュー・オブジェクトを含むプロジェクトを展開します。
アプリケーション・モジュールを右クリックし、「実行」を選択します。
または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は、「デバッグ」を選択します。JDeveloperにより、ログ・ウィンドウのデバッガ・プロセス・パネルおよび各種デバッガ・ウィンドウが開きます。Oracle ADFモデル・テスターを使用してデバッグする場合、これらのウィンドウを使用してステータス・メッセージと例外の表示、ソース・コードのステップ・インとステップ・アウト、およびブレークポイントの管理を実行できます。
ADF Business Componentsのデバッグに特有の診断メッセージを受信する方法の詳細は、6.3.8項「ADF Business Componentsデバッグ診断を有効化する方法」を参照してください。
クライアント・インタフェースによって定義されたメソッドのメソッド・テスト用パネルを開くには、次のいずれかを行います。
アプリケーション・モジュール・クライアント・インタフェース用に公開したメソッドを実行する場合、データ・モデル・ツリーでアプリケーション・モジュール・ノードを選択し、メイン・メニューから「表示」 - 「操作」を選択します。アプリケーション・モジュール・ノードをダブルクリックして、メソッド・テスト・パネルを開くこともできます。
ビュー・オブジェクト用のクライアント・インタフェースで公開したメソッドを実行する場合、データ・モデル・ツリーで該当するビュー・オブジェクト・ノードを選択し、メイン・メニューから「表示」 - 「操作」を選択します。ビュー・オブジェクト・ノードを右クリックして、「操作」を選択することもできます。
ビュー・オブジェクト行のクライアント行インタフェースで定義したメソッドのメソッド・テスト・パネルを開くには、データ・モデル・ツリーを展開し、該当するビュー・オブジェクト・ノードを右クリックして、「表の表示」を選択します。次にビュー・インスタンスの概要パネルで該当する行を選択し、メイン・メニューから「表示」 - 「操作」を選択します。
マスター・ビュー・オブジェクトではビュー行の操作は禁止されているので、データ・モデル・ツリーでマスター・ビュー・インスタンスを選択しないでください。図9-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 Business Componentsランタイムはエラーを生成します。
|
注意: アプリケーション・モジュール・クラスに追加したメソッドが「使用可能」リストに表示されない場合は、メソッド実装ルールのいずれか違反していないかをまず確認してください。適切なメソッドと判断できる場合は、アプリケーション・モジュールの概要エディタに再移動する前に、アプリケーション・モジュール・クラスの再コンパイルを試行してください。 |
アプリケーション・モジュールのカスタム・メソッドのプライベート実装では、生成されたアクセッサ・メソッドを使用してデータ・モデル内のビュー・オブジェクト・インスタンスを簡単に参照できます。ビュー・オブジェクトでgetCurrentRow()メソッドをコールすると、クライアント・ユーザー・インタフェースでビュー・オブジェクトの現在行として認識されている行にアクセスできます。その結果、アプリケーション・モジュールのビジネス・サービス・メソッドの記述中には、クライアントからのパラメータの引渡しが不要な場合があります。これは、同じアプリケーション・モジュールのデータ・モデルにある他のビュー・オブジェクト・インスタンスの現在行から値を渡すのみの場合に該当します。
たとえば、例9-11にあるカスタム・アプリケーション・モジュール・メソッドではパラメータを受け入れません。createOrderItem()メソッドはgetGlobals().getCurrentRow()を内部でコールし、Globalsビュー・オブジェクト・インスタンスの現在行にアクセスします。次に、強く型付けされたアクセッサ・メソッドを行で使用してDescriptionおよびLineItemId属性の値にアクセスし、この値を、新規作成されたOrderItemエンティティ・オブジェクト行の対応する属性の値として設定します。
メソッドをアプリケーション・モジュールのクライアント・インタフェースに公開したら、それらのメソッドをクライアントから起動できます。
アプリケーション・モジュールのクライアント・インタフェースをプログラム的に操作するには、次の手順を実行します。
ApplicationModuleを、特定のクライアント・インタフェースにキャストします。
インタフェース上のいずれかのメソッドをコールします。
|
注意: この項では、説明を簡潔にするために、カスタム・アプリケーション・モジュールのインタフェースの操作のみを重視しますが、これと同じダウンキャスト方法は、 |
例9-12は、この2つの手順を実行するTestClientCustomInterfaceクラスを示しています。9.7.5項「静的メイン・メソッドを使用したカスタム・アプリケーション・モジュールのテスト方法」に記載のように、このクラスのmain()メソッドを使用してアプリケーション・モジュール・メソッドのテストを行うこともできます。その場合は、StoreFrontServiceクライアント・インタフェースを使用して、クライアントからすべての同一メソッドをコールします。
|
注意:
|
例9-12の基本ロジックは次の手順に従います。
注文1011の合計を取得します。
注文1011の顧客名を取得します。
1011の注文ステータスを「CANCEL」の値に設定します。
製品名がnullの新しい製品を作成します。
製品名を付けて新しい製品を作成し、新しく割り当てた製品IDを表示します。
例9-12 クライアントからのアプリケーション・モジュールのカスタム・インタフェースの使用
package devguide.examples.appmodules;
import devguide.examples.appmodules.common.StoreFrontService;
import devguide.examples.entities.PersonsEOImpl;
import devguide.examples.entities.ProductsBaseEOImpl;
import oracle.jbo.ApplicationModule;
import oracle.jbo.JboException;
import oracle.jbo.Key;
import oracle.jbo.client.Configuration;
import oracle.jbo.domain.DBSequence;
import oracle.jbo.domain.Number;
import oracle.jbo.server.ApplicationModuleImpl;
import oracle.jbo.server.EntityDefImpl;
public class TestClientCustomInterface {
public static void main(String[] args) {
String amDef = "devguide.model.StoreFrontService";
String config = "StoreFrontServiceLocal";
/*
* This is the correct way to use application custom methods
* from the client, by using the application module's automatically-
* maintained custom service interface.
*/
// Acquire instance of application module, cast to client interface
StoreFrontService service =
(StoreFrontService)Configuration.createRootApplicationModule(amDef,config);
String total = service.findOrderTotal(1011);
System.out.println("Status of Order # 1011 = " + total);
String customerName = service.findOrderCustomer(1011);
System.out.println("Customer for Order # 1011 = " + customerName);
try {
service.updateOrderStatus(1011,"CANCEL");
}
catch (JboException ex) {
System.out.println("ERROR: "+ex.getMessage());
}
long id = 0;
try {
id = service.createProduct(null, "NEW", "CLASS1");
}
catch (JboException ex) {
System.out.println("ERROR: "+ex.getMessage());
}
id = service.createProduct("Canon PowerShot G9", "NEW", "CLASS1");
System.out.println("New product created successfully with id = "+id);
Configuration.releaseRootApplicationModule(am,true);
}
}
例9-12のクライアントはクライアント・インタフェースのカスタム・メソッドをコールし、次の出力を表示します。
Total for Order # 1011 = 99.99 Customer for Order # 1011 = John Chen ERROR: JBO-27014: Attribute ProductName in ProductsBaseEO is required. New product created successfully with id = 133
製品名をnullとしてcreateProduct()をコールしようとした初回の試みでは、Productエンティティ・オブジェクトのName属性に対する組込み必須検証が原因で例外が発生しています。
アプリケーション・モジュールにアクセス中のクライアント・レイヤ―はJava EEアーキテクチャの同一層にあるため、アプリケーション・モジュールはローカル・モードと呼ばれるモードでデプロイされます。ローカル・モードでは、クライアント・インタフェースはカスタム・アプリケーション・モジュールのJavaクラスによって直接実装されます。アクセス先のアプリケーション・モジュールがJavaServer FacesアプリケーションのWeb層にあるのか、Swingアプリケーションのクライアント層(クライアント/サーバーの2層式)にあるのかにかかわらず、ローカル・モードでアプリケーションにアクセスします。
oracle.jbo.clientパッケージのConfigurationクラスでは、テスト用のアプリケーション・モジュール・インスタンスを非常に簡単に入手できます。これにより、JUnit回帰テスト・フィクスチャの一部となるテスト・クライアント・プログラム(36.11項「JUnitを使用した回帰テスト」を参照)のように、テスト・クライアント・プログラムの記述が簡単になります。
|
ベスト・プラクティス: Fusion Webアプリケーションに対しては、常にバインディング・レイヤーを使用してアプリケーション・モジュールにアクセスする必要があります。開発者はアプリケーション・モジュールにアクセスするあらゆる場合に、このクラスの |
データをバインドするためのADF Modelレイヤーを使用してFusion Webアプリケーションを操作している場合、ユーザー・インタフェース・プロジェクトにADFBindingFilterというサーブレット・フィルタが構成されます。このフィルタにより、宣言的なバインディング・メタデータに基づく適切なアプリケーション・モジュール・インスタンスの自動的な取得およびリリースが調整され、ユーザー・インタフェース・プロジェクトのページ定義ファイルで指定された既知のアクション・バインディングまたはイテレータ・バインディングを使用して、サービスをデータ・コントロールとして検索できるようになります。ADFバイディング・コンテナ、データ・コントロール、ページ定義ファイルおよびバインディングの詳細は、第13章「Fusion WebアプリケーションでのADF Modelの使用」を参照してください。ここでは、ADFアクション・バインディングまたはADFイテレータ・バインディングに名前を付けることで、このDCBindingContainerからアプリケーション・モジュールのクライアント・インタフェースにアクセスできることがわかるだけで十分です。例9-13(アクション・バインディング)および例9-14(イテレータ・バインディング)に示すように、JSFマネージドBeanのカスタム・クライアント・インタフェースで、バインディング・コンテキストを参照してメソッドをコールできます。
アクション・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、例9-13に示す基本手順に従います。
ADFバインディング・コンテナにアクセスします。
名前の付いたアクション・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルに提供されている任意のアクション・バインディング名を使用します。)
データ・コントロールをアクション・バインディングから名前で取得します。
アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。
アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。
クライアント・インタフェースにあるいずれかのメソッドをコールします。
例9-13 名前付きアクション・バインディングを使用したJSFバッキングBeanでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス
package demo.view;
import oracle.fodemo.storefront.store.service.common.StoreServiceAM;
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
StoreServiceAM service = (StoreServiceAM)am;
// 6. Call a method on the client interface
service.doSomethingInteresting();
return "SomeNavigationRule";
}
}
イテレータ・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、例9-14に示す基本手順に従います。
ADFバインディング・コンテナにアクセスします。
名前の付いたイテレータ・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルないの任意のイテレータ・バインディング名を使用します。)
データ・コントロールをイテレータ・バインディングから名前で取得します。
アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。
アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。
クライアント・インタフェースにあるいずれかのメソッドをコールします。
例9-14 名前付きイテレータ・バインディングを使用したJSFバッキングBeanでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス
package demo.view;
import oracle.fodemo.storefront.store.service.common.StoreServiceAM;
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
StoreServiceAM service = (StoreServiceAM)am;
// 6. Call a method on the client interface
service.doSomethingInteresting();
return "SomeNavigationRule";
}
}
これらのバッキングBeanの例は、例9-15に示すヘルパー・メソッドによって異なります。
例9-15 バッキングBeanクラスのヘルパー・メソッド
public BindingContainer getBindings()
{
return BindingContext.getCurrent().getCurrentBindingsEntry();
}
ADFアクションに宣言的にバインドされるボタンを上書きしてバッキングBeanクラスを作成すると、このメソッドがクラス内に自動的に生成されます。それ以外の場合は、ヘルパー・メソッドをクラスに手動で追加する必要があります。
ApplicationModuleImplベース・クラスには、この機能を実装する組込みメソッドが多数含まれています。付録D「ADF Business Componentsのよく使用されるメソッド」は、カスタム・アプリケーション・モジュール・クラスでよく記述、使用およびオーバーライドする最も一般的なコードのクイック・リファレンスとなっていますが、この項では、これらの組込みフレームワーク・メソッドの1つをオーバーライドしてデフォルトの動作を拡張する基本手順の理解を深めることを重視しています。
アプリケーション・モジュールの組込みフレームワーク・メソッドを上書きするには、「メソッドのオーバーライド」ダイアログを使用して、メイン・メニューからアプリケーション・モジュールのJavaクラスを選択します。
作業を始める前に、次のようにします。
アプリケーション・モジュールのベース・クラスに関する知識があると役立つ場合があります。詳細は、9.11項「組込みフレームワーク・メソッドのオーバーライド」を参照してください。
次のタスクを完了します。
アプリケーション・モジュールのフレームワーク・メソッドを上書きする手順:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「Java」ナビゲーション・タブをクリックします。
「Javaクラス」ページで、カスタマイズするアプリケーション・モジュールのJavaクラスにリンクされたファイル名をクリックします。
ソース・エディタでクラス・ファイルが自動的に開きます。
メイン・メニューから、「ソース」→「メソッドのオーバーライド」を選択します。
「ソース」メニューが表示されていない場合は、目的のJavaクラス・ファイルが開いており、ソース・エディタが表示されていることを確認します。
「メソッドのオーバーライド」ダイアログで、リストをスクロールして目的のメソッドを特定するか、あるいはメソッド名の最初の数文字を入力してインクリメンタル検索を実行します。
メソッドを1つ以上選択します。
「メソッドのオーバーライド」ダイアログでは、任意の数のメソッドを選択して同時に上書きできます。
たとえば、図9-26に示すように、新規ユーザー・セッションでアプリケーション・モジュールのサービス・コンポーネントの操作を初めて開始したときに、アプリケーション・モジュールのprepareSession()メソッドを上書きしてデフォルトの機能を拡張する場合、prepareSession(Session)メソッドの隣のチェック・ボックスを選択します。
「OK」をクリックします。
「メソッドのオーバーライド」ダイアログを閉じると、図9-27に示すように、上書きしたメソッドにカーソルが置かれた状態でソース・エディタに戻ります。メソッドには、super.prepareSession()をコールする単一行が表示されています。これは、ベース・クラスがこのメソッドに対して通常であれば実行したはずのデフォルトの動作を起動するJava構文です。カスタム・アプリケーション・モジュール・クラスでこの行の前または後にコードを追加して、デフォルトの機能の前または後のデフォルトの動作を拡張できます。
「メソッドのオーバーライド」ダイアログを使用してメソッドを上書きする場合、ソース・エディタにより、上書きしたメソッドの直前にJDK @Override注釈が挿入されます。この注釈により、アプリケーション・モジュール・クラスのメソッドがスーパークラスのメソッドのシグネチャと一致しない場合は、コンパイル時にエラーが生成されます。
クラスにメソッド名を追加してスーパークラス内のメソッドをオーバーライドする場合は注意が必要です。オーバーライドするベース・クラス・メソッドと完全に同一のシグネチャが必要です。@Override注釈は必ずメソッドの直前に追加してください。これにより、メソッドがスーパークラスのメソッドのいずれのシグネチャとも一致しない場合は、コンパイル時にエラーが生成されます。スーパークラスの実装をコールするかわりにメソッドのコードを記述する場合は、抑止または置換する組込みコードについて理解しておく必要があります。
prepareSession()メソッドは、新しいユーザー・セッションで初めて使用されるときにアプリケーション・モジュールによって起動されるため、カスタム・アプリケーション・モジュール・クラスをオーバーライドし、アプリケーション・モジュールを使用する新しいユーザーごとに固有のセットアップ・タスクを実行する場合に便利なメソッドです。例9-16は、アプリケーションで使用する言語を初期化するsetCurrentUserLanguage()ヘルパー・メソッドを起動するoracle.fodemo.storefront.adfextensions.FODApplicationModuleImplクラス内の、オーバーライドされたprepareSession()メソッドを示しています。
例9-16 現在のユーザー・セッションで使用する言語の初期化
public class FODApplicationModuleImpl extends ApplicationModuleImpl {
public static String preferredLanguage;
public static boolean isWebUser=false;
private String[] supportedLanguages = {"EN","JA","EL","FR","DE"};
/**
* @param session
*/
@Override
protected void prepareSession(Session session) {
super.prepareSession(session);
setCurrentUserLanguage();
}
private void setCurrentUserLanguage() {
DBTransactionImpl dbti = (DBTransactionImpl)getDBTransaction();
CallableStatement statement =
dbti.createCallableStatement(("BEGIN " +
"user_context_pkg.set_app_user_lang(?); " +
"END;"), 0);
try {
statement.setString(1, getApplicationLanguage());
statement.execute();
} catch (SQLException sqlerr) {
throw new JboException(sqlerr);
} finally {
try {
if (statement != null) {
statement.close();
}
} catch (SQLException closeerr) {
throw new JboException(closeerr);
}
}
}
/**
* @return
*/
public String getApplicationLanguage(){
String appLanguage = "EN";
if (isWebUser){
for (int index=0; index<supportedLanguages.length; index++){
if (preferredLanguage.equals(supportedLanguages[index])){
appLanguage = preferredLanguage;
break;
}
}
} else{
appLanguage = getAMLanguage();
}
return appLanguage;
}
/**
* @return
*/
public String getAMLanguage(){
PropertyMetadata langProperty =
PropertyMetadata.findProperty("jbo.default.language");
String amLanguage = langProperty.getProperty();
return amLanguage.toUpperCase();
}
}
サービス指向アーキテクチャでは、アプリケーション・モジュールに基づいていないWebサービスから提供される機能をOracle ADFアプリケーション・モジュールで利用する必要がある場合もあります。Webサービスは、任意のプログラミング言語で実装し、ネットワーク上の任意のサーバーに配置できます。各Webサービスでは、言語に依存しない標準的なXMLフォーマットで記述することにより、一連の該当するメソッドをそのAPI内で指定します。このXMLドキュメント(構文は、Web Services Description Language(WSDL)に準拠)を使用すると、Webサービスのメソッドの名前に加えて、それらのメソッドが予期するパラメータや実際の戻り値のデータ型も、JDeveloperで理解できます。
|
注意: アプリケーション・モジュールはWebサービスとして公開し、デプロイ済のFusion Webアプリケーション間で使用することもできます。外部サービスを使用したADF Business Componentsの再利用の詳細は、第11章「サービス対応のアプリケーション・モジュールの統合」を参照してください。 |
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 Business Componentsサービスには次の形式のサービスへのURLがあります。
統合されたWebLogic Server上でのURLの形式はhttp://host:port/EJB-context-root/@WebService-name?WSDLで、たとえば、次のようになります。
http://localhost:8888/EJB-StoreFrontService/StoreFrontService?WSDL
Oracle Application Server。URLの形式はhttp://host:port/context-root/@WebService-name?WSDLで、たとえば、次のようになります。
http://localhost:8888/StoreFrontService/StoreFrontService?WSDL
Webサービス・プロキシ・クラスは、WebサービスのパブリックAPIに対応する一連のJavaメソッドを表します。Webサービス・プロキシ・クラスを使用すると、Webサービス内の任意のメソッドを、他の任意のローカルなJavaクラスのメソッドの場合と同じ方法でコールすることができます。
プロキシ・クラスを使用してアプリケーション・モジュールからWebサービスをコールするには、次の作業を実行します。
WebサービスのWebサービス・プロキシ・クラスを作成します。コールするWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・プロキシ作成ウィザードを使用します。
プロキシ・クラスにメソッドを実装し、目的のWebサービスにアクセスします。
該当するWebサービス・プロキシ・クラスのインスタンスをアプリケーション・モジュール内で作成し、Webサービス・プロキシ・オブジェクト上でメソッドを1つ以上起動します。
コールするWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・プロキシ作成ウィザードを使用します。
サービスにプログラム的にアクセスするためにWebサービス・プロキシ・クラスを作成する手順:
アプリケーション・ナビゲータで、Webサービス・プロキシを作成するプロジェクトを右クリックし、「新規」をクリックします。
「新規ギャラリ」で、「ビジネス層」を開き、「Webサービス」を選択します。Webサービス・プロキシ・クライアントを選択して、「OK」をクリックします。
ウィザードの「Webサービス記述を選択」ページで、生成されたWebサービス・プロキシ・クラスのJavaパッケージ名を入力または選択します。
アプリケーションでコールするサービスのWSDLのURLを入力し、このフィールドから次に進みます。
「次へ」ボタンが有効になっていない場合は、「指定不可の理由」ボタンをクリックすると、WSDLドキュメントの読込みを試行した際にJDeveloperが検出した問題がわかります。URLを検証した後、必要に応じて問題を解決し、この手順を繰り返します。
ウィザードの「次へ」が有効になっている場合は、WSDLドキュメントをJDeveloperが認識し、検証済です。「次へ」をクリックし、続行します。
ウィザードの以降のページに進み、Webサービス・プロキシの詳細を指定します。ウィザードの各ページの詳細は、[F1]を押すか、「ヘルプ」をクリックしてください。
「終了」をクリックします。
Webサービス・プロキシを作成したら、目的のWebサービスにアクセスするためにプロキシ・クラスにメソッドを実装する必要があります。
サービスを起動するためにWebサービス・プロキシ・テンプレートをコールする手順:
ソース・エディタでport_nameClient.javaという名前のプロキシ・クライアント・クラスを開き、メイン・メソッド内にある// Add your own code to call the desired methodsというコメントを検索します。
適切なコードを追加してWebサービスを起動します。
JDeveloperにより生成されたクライアント・モジュール・クラスの完全セットをデプロイし、このクラスをアプリケーションで参照します。
Webサービス・プロキシ・クラスを生成すると、その後、アプリケーション・モジュールのカスタム・メソッド内で使用できます(例9-17を参照)。該当メソッドによりWebサービス・プロキシ・クラスのインスタンスが作成され、その結果についてWebサービス・プロキシ・クラスからWebサービス・メソッドがコールされます。
例9-17 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サービス・プロキシは、アプリケーション・ナビゲータ内で、WebServiceNameProxyという単一の論理ノードとして表示されます。たとえば、WebサービスStockQuoteServiceのノードは、ナビゲータ内で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サービス・プロキシ・クラスは、「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ブロックを使用してコールをラップすることにより、リクエストの失敗に備える必要があります。例9-18では、Webサービス例外を捕捉することで、前述(9.12.1.3項「アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール」)の簡単な例を改良しています。この場合は該当するエラーをJboExceptionとして再スローしているだけですが、アプリケーションではさらに適切なエラー処理を実装することもできます。
例9-18 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サービスベースのアプリケーション・モジュールを起動すると、コール側コンポーネントとコールしているサービスがコロケートしている場合にコールを最適化できなくなります。別な方法として、第11章「サービス対応のアプリケーション・モジュールの統合」で説明しているサービス・インタフェースによる方法を使用することもできます。
