Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
前 |
次 |
この章の内容は次のとおりです。
ADFアプリケーション・モジュールでは、エンド・ユーザー・タスクを論理作業ユニットとしてカプセル化します。ユーザー・インタフェース・クライアントでは、アプリケーション・モジュールを使用してアプリケーション・データを管理します。
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールは、ADFビジネス・コンポーネントで、エンド・ユーザー・タスクに関連する論理作業ユニットのビジネス・サービス・メソッドとデータ・モデルをカプセル化したものです。
アプリケーション開発の早期段階では、アーキテクトと設計者は通常、UMLユースケース手法およびADFタスク・フローを使用して、アプリケーションの計画済エンド・ユーザー機能の高レベルな概要を作成します。この設計段階中に識別されるエンド・ユーザーの高レベルな各ユースケースは、一般に次のものに応じて異なります。
対象となるドメイン・ビジネス・オブジェクト。ユースケースに関連するコア・ビジネス・データについての問題に解答します。
必要なビジネス・データのユーザー指向ビュー。ユースケースをサポートするために必要な列サブセット、フィルタ処理された行セット、ソート方法、グループ化方法などについての問題に解答します。
各ユースケースに関連するドメイン・オブジェクトを識別すると、ビジネス・ドメイン・レイヤー内の必要なエンティティ・オブジェクトを識別する際に便利です。必要なビジネス・データのユーザー指向ビューは、ビュー・オブジェクトとして取得された適切なSQL問合せを定義して、データをエンド・ユーザーの期待どおりに取得する際に便利です。これには、パフォーマンスを最大化するために、ユースケースのサポートに必要な最低限の詳細の取得が含まれます。これまでの説明で、ビュー・オブジェクト問合せおよびビュー基準を利用してデータを形成する方法のみならず、ビュー・リンクを使用してデータ・モデルにマスター/ディテール階層を設定し、期待どおりのエンド・ユーザー体験をユーザーに提供してユースケースを実現する方法も、すでに学習しました。
アプリケーション・モジュールは、当該のユースケースに必要な再使用可能なビュー・オブジェクトのインスタンスを含む作業ユニット・コンテナです。これらのビュー・オブジェクト・インスタンスは、エンド・ユーザー・ユースケースにより表示または変更する情報が決定される再使用可能なビジネス・ドメイン・レイヤー内の基礎となるエンティティ・オブジェクトに、メタデータを通じて関連付けられています。
この章では、図13-1に示す次の概念について説明します。
ビュー・オブジェクトのインスタンスをアプリケーション・モジュールで公開して、そのデータ・モデルを定義します。
サービス・メソッドを記述して、タスク・レベルのビジネス・ロジックをカプセル化します。
UIクライアントがコールするメソッドを選択し、クライアント・インタフェースで公開します。
アプリケーション統合シナリオでプログラム的に使用するメソッドを選択し、サービス・インタフェースで公開します。
12cから、Oracle JDeveloperではADFビジネス・コンポーネント・モデル・プロジェクトにおけるEJBセッションBean対応のアプリケーション・モジュールのサポートが非推奨となった点に注意してください。今後、JDeveloperではEJBセッションBean対応のアプリケーション・モジュールを作成または実行できません。既存のEJBセッションBean対応のアプリケーション・モジュールのかわりとして、「アプリケーション・モジュールによるSOAP Webサービスの作成」に説明されているとおり、アプリケーション・モジュール・サービスをWebサービス対応のアプリケーション・モジュールに移行できます。このアプローチは、外部サービスを使用してサービス・メソッドを公開するためのベスト・プラクティスと一貫しています。
複数のWebページまたはビューにまたがる可能性のある論理トランザクション中に、プールのアプリケーション・モジュール・インスタンスを使用します。
アプリケーション・モジュールでは、データベース接続の取得と、エンティティ・オブジェクトに行われた変更の保存またはロールバックの調整を行うTransaction
オブジェクトを操作します。
関連するSession
オブジェクトにより、現在のアプリケーション・ユーザーに関するランタイム情報が提供されます。
図13-1 作業ユニットをカプセル化するビジネス・サービス・コンポーネントとして機能するアプリケーション・モジュール
アプリケーション・モジュールを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。
共有アプリケーション・モジュールの作成の詳細は、「アプリケーション・モジュール・ビュー・インスタンスの共有」を参照してください。
外部サービスを使用したADFビジネス・コンポーネント・サービス・メソッドの公開の詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。
「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュールの公開方法の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。
実行時のパフォーマンスを向上させるためのアプリケーション・モジュール・インスタンス構成の詳細は、「Fusion Webアプリケーションでの状態管理の使用」および「アプリケーション・モジュール・プールのチューニング」を参照してください。
本番環境のパフォーマンスとスケーラビリティを最大化する方法の詳細は、『パフォーマンスのチューニング・ガイド』の「Oracle Application Development Framework (ADF)のチューニング」を参照してください。
カスタム・アプリケーション・モジュール・クラスでよく記述、使用またはオーバーライドするコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。
oracle.jbo
パッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。
Oracle ADFモデルJava APIリファレンス
ユーザー・タスクの観点からアプリケーションのサイズに応じて、単一または複数のADFアプリケーション・モジュールを作成します。
大規模なアプリケーションでは、通常、粒度の粗い各エンド・ユーザー・タスクをサポートするアプリケーション・モジュールを1つずつ作成します。小規模なアプリケーションでは、アプリケーション・モジュールを1つ作成すれば、アプリケーションの全機能のニーズを十分に処理できると判断する場合もあります。「ネストされたアプリケーション・モジュールの定義」には、これに関する追加の説明があります。
作成するビュー・オブジェクトは、1つ以上のアプリケーション・モジュールで使用できる再利用可能コンポーネントです。各ビュー・オブジェクトは、そのアプリケーション・モジュールのトランザクションのコンテキストで、カプセル化した問合せを実行します。アプリケーション・モジュールで使用される一連のビュー・オブジェクト・インスタンスは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。
既存のADFビジネス・コンポーネント・プロジェクトにアプリケーション・モジュールを追加するには、「新規ギャラリ」から使用できる「アプリケーション・モジュールの作成」ウィザードを使用します。
始める前に:
アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュールを手動で作成するには:
手順ごとの詳細は、「既存のアプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。
アプリケーション・モジュールを作成すると、JDeveloperでは、その宣言的設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリに保存されます。たとえば、summit.model
パッケージのSummit ADFサンプル・アプリケーションのBackOfficeAppModule
という名前のアプリケーション・モジュールでは、プロジェクトのソース・パスに./summit/model/BackOfficeAppModule.xml
というXMLファイルがあります。このXMLファイルには、ビュー・オブジェクト・インスタンスをアプリケーション・モジュールのデータ・モデルで再作成するために実行時に必要な情報が含まれています。
この内容を確認するには、「アプリケーション」ウィンドウでアプリケーション・モジュールのノードをダブルクリックして概要エディタを開き、アプリケーション・モジュールのXMLファイルを確認します。エディタ・ウィンドウで「ソース」タブをクリックすると、XMLファイルが表示され、その内容を確認できます。「構造」ウィンドウには、XMLファイルの構造が表示されます。
ビジネス・コンポーネントを作成すると、JDeveloperがアプリケーション・モジュールのすべての機能を含むデータ・コントロールを自動的に作成します。データ・コントロールはADFモデル抽象レイヤーで、属性、メソッド、関連する型の情報を含む補足メタデータを提供して、アプリケーション・モジュールの操作とデータ・コレクション(ビュー・オブジェクト・インスタンスの行セット)を記述します。開発者は、JDeveloperの「データ・コントロール」パネルに表示されたデータ・コントロールの表現を使用して、アプリケーション・モジュールに自動的にバインドされるUIコンポーネントを作成できます。実行時にADFモデル・レイヤーによって、適切なXMLファイルからデータ・コントロールおよびバインディングを記述したメタデータが読み取られ、ユーザー・インタフェースとビジネス・サービスの双方向の結合が実装されます。
たとえば、BackOfficeAppModule
アプリケーション・モジュールによりSummitADF
アプリケーション・ワークスペースのビジネス・サービス・レイヤーが実装されます。このデータ・モデルには、複数のマスター/ディテール階層など、多数のビュー・オブジェクト・インスタンスが含まれています。コアSummit ADFサンプル・アプリケーションのビュー・レイヤーはJSFページで構成され、このページのUIコンポーネントは、BackOfficeAppModule
のデータ・モデル内のビュー・オブジェクト・インスタンスのデータと、そのクライアント・インタフェース上の組込み操作およびサービス・メソッドにバインドされています。「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュールの公開方法の詳細は、「ADFデータ・コントロールを使用したアプリケーション・モジュールの公開」を参照してください。
「アプリケーション・モジュールの作成」ウィザードでアプリケーション・モジュールを作成しながらビュー・オブジェクト・インスタンスをアプリケーション・モジュールに追加することも、作成済のアプリケーション・モジュールに後で追加することもできます。
アプリケーション・モジュールの作成ウィザードの使用方法の詳細は、「アプリケーション・モジュールの作成方法」を参照してください。
作成済のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加できます。ビュー・オブジェクト・インスタンスを既存のアプリケーション・モジュールへ追加したり、オプションでビュー・オブジェクト・インスタンスをカスタマイズするには、アプリケーション・モジュールの概要エディタにある「データ・モデル」ページを使用します。
始める前に:
アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
既存のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加するには:
アプリケーション・モジュールの概要エディタに表示されるデータ・モデルを使用すると、プロジェクトで定義されている既存のビュー・リンクに基づいて、ビュー・インスタンスの階層を作成できます。複数のマスター/ディテールの階層レベルで構成されるビュー・リンクを定義している場合は、アプリケーションでサポートされているレベル数までマスター/ディテールのビュー・インスタンスを作成できます。
始める前に:
アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
マスター/ディテールのビュー・オブジェクト・インスタンスをデータ・モデルに追加するには:
アプリケーション・モジュールの概要エディタにある、「データ・モデル・コンポーネント」ページでビュー・オブジェクト・インスタンスのカスタマイズを任意に行えます。たとえば、次のようにマスター/ディテール・ビュー・オブジェクトの関係をコントロールする属性を設定できます。
たとえば、Summit ADFサンプル・アプリケーションのSummitADF
ワークスペースでは、ビュー・インスタンスSalesPeople
がBackOfficeAppModule
アプリケーション・モジュールに対して定義されており、販売スタッフを肩書きでフィルタするビュー基準FilterByTitleIdVC
がこのビュー・インスタンスに対して定義されています。図13-10は、「ビュー・インスタンスの編集」ダイアログでFilterByTitleIdVC
を選択し、SalesPeople
ビュー・インスタンスを開いた状態を示しています。バインド変数TitleIdBind
はデフォルト値の2を定義し、これによりSalesPeople
ビュー・インスタンスの制御属性としてTitleId
属性の値が設定されます。ビュー基準フィルタによって設定した制御属性により、一致するIDのビュー行のみを取得できます。
図13-10 ビュー基準フィルタを使用してカスタマイズしたビュー・オブジェクト・インスタンス
始める前に:
アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
既存のアプリケーション・モジュールへ追加するビュー・オブジェクト・インスタンスをカスタマイズするには:
ビュー・オブジェクト・コンポーネントのインスタンスを追加して、アプリケーション・モジュールのデータ・モデルを定義します。図13-11に、Summitサンプル・アプリケーションのSummitADFワークスペースに表示されるBackOfficeAppModule
アプリケーション・モジュールのJDeveloperビジネス・コンポーネント・ダイアグラムを示します。
図13-11 ビュー・オブジェクト・コンポーネントの2つのインスタンスを含むアプリケーション・モジュール
例に示したアプリケーション・モジュールにはCustomerVO
ビュー・オブジェクト・コンポーネントの2つのインスタンスが含まれています。 メンバー名のCustomer
と、それを区別するAnotherCustomer
です。実行時には両方のインスタンスが同一のCustomerVO
ビュー・オブジェクト・コンポーネント定義を共有します。これにより、同じ属性構造とビュー・オブジェクト動作を持つようになります。ただし、それぞれを個別に使用して異なるユーザーのデータを取得できます。たとえばWHERE
句やバインド変数の追加フィルタなど、一部の実行プロパティは2つのインスタンスで異なっている場合があります。
次の例は、BackOfficeAppModule
アプリケーション・モジュールにより、アプリケーション・モジュールのメンバー・ビュー・オブジェクト・インスタンスがそのXMLドキュメント・ファイルで定義される様子を示しています。
<AppModule Name="BackOfficeAppModule" ...> <ViewUsage Name="Customer" ViewObjectName="oracle.summit.model.appmodule.CustomerVO"/> <ViewUsage Name="AnotherCustomer" ViewObjectName="oracle.summit.model.appmodule.CustomerVO"/> </AppModule>
新しいアプリケーション・モジュールを作成した後、「アプリケーション・モジュールの編集」ダイアログを使用してその設定を編集できます。エディタを起動するには、「アプリケーション」ウィンドウでアプリケーション・モジュール・ノードを右クリックして「開く」を選択するか、アプリケーション・モジュールをダブルクリックします。エディタの様々なページを開き、データ・モデル、ネストされたアプリケーション・モジュールの参照、Java生成の設定、クライアント・インタフェース・メソッド、実行時インスタンス化動作、およびカスタム・プロパティを調整できます。
アプリケーション・モジュール名を編集する場合、Oracle Application Development Framework (Oracle ADF)が定義している予約語以外の名前を選択してください。特に、アプリケーション・モジュールの名前に基づいてJDeveloperによって自動的に割り当てられるデータ・コントロールの使用名では、予約語は無効になります。Fusion Webアプリケーションでは、これらの予約語はdata
、bindings
、security
およびadfContext
で構成されます。たとえば、アプリケーション・モジュールの名前にはdata
を使用しないでください。予約語と競合するIDのデータ・コントロールの使用名が作成されると、実行時にアプリケーションからデータ・コントロール・オブジェクトにアクセスできなくなる場合があり、ランタイムClassCastException
のエラーが発生することがあります。
予約語はアンダースコア(_
)文字で始まる場合が多いため、名前が競合しないように、アプリケーション・モジュール名の先頭にはアンダースコアを使用しないでください。
アプリケーション・モジュール名に予約語が含まれる場合や、予約語の大文字と小文字を変更した名前が使用されている場合は、競合は発生しません。たとえば、Product_Data
、Product_data
またはData
は、全体の名前が予約語のdata
とは一致しないため、すべて有効なアプリケーション・モジュール名です。
デフォルトでは、アプリケーション・モジュールは、「データ・コントロール」パネルにAppModuleName
DataControl
という名前のアプリケーション・モジュール・データ・コントロールとして表示されます。ユーザー・インタフェース・デザイナでは、「データ・コントロール」パネルを使用して、アプリケーション・モジュールからアプリケーションのWebページにデータをバインドします。たとえば、アプリケーション・モジュールの名前がSummitAppModule
の場合、「データ・コントロール」パネルには、SummitAppModuleDataControl
という名前のデータ・コントロールが表示されます。デフォルトのデータ・コントロール名を変更して、名前を短くしたり適切な名前を指定することもできます。
ユーザー・インタフェース・デザイナでデータ・コントロールを操作すると、アプリケーション・モジュールのデータ・コントロール名は、ユーザー・インタフェース・プロジェクトのDataBindings.cpx
ファイルおよび各データ・バインディング・ページ定義のXMLファイルに表示されます。また、アプリケーション・モジュールのサービス・インタフェースをプログラム的に操作する必要がある場合は、データ・コントロール名をコード内で参照できます。このため、アプリケーション・モジュールの名前を変更する場合は、ビュー・レイヤーを作成する前に変更する必要があります。
アプリケーション・モジュールのデータ・コントロールの詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。
注意:
1つ以上のページですでに参照した後にアプリケーション・モジュールのデータ・コントロール名を変更する場合は、データ・コントロール名が参照されているページ定義ファイルとDataBindings.cpx
ファイルを開き、古い名前を新しい名前に手動で更新する必要があります。
アプリケーション・モジュールのデータ・コントロール名を変更するには:
アプリケーション・モジュールに関する一般的な疑問は、「アプリケーション・モジュールがどの位の大きさになるのか」というものです。つまり、「大規模なアプリケーション・モジュールを1つ作成してエンタープライズ・アプリケーションのデータ・モデル全体を含めるか、より小規模なアプリケーション・モジュールを多数作成して機能に応じてアプリケーションを区分化するか」という問題です。答えは状況によって異なります。
一般に、アプリケーション・モジュールのサイズは、そのモジュールでの対応が想定される特定のユースケースを十分にサポートできる大きさにする必要があります。「ネストされたアプリケーション・モジュールの定義」で説明するネスト機能を使用すると、粒度の細かい複数のアプリケーション・モジュール・コンポーネントからのアセンブルが可能になります。複雑なビジネス・アプリケーションのユースケースは通常は1つではないため、Oracle ADFで実装される複雑なビジネス・アプリケーションは一般に単一アプリケーション・モジュールになりません。
実際のプラクティスでは、必要なモジュール化タイプをサポートするための粒度を選択する場合があります。たとえば、個別のデータ・ソースをサポートする必要や個別のチューニング・オプションを構成する必要がある場合は、どちらも複数のアプリケーション・モジュールを作成する方が適しています。または、主要なユースケースが1つ、バックエンドでサポートしているユースケースが1つの小規模アプリケーションの場合、アプリケーション・モジュールを2つ作成できます。ただし、簡潔にするため、数個のビュー・オブジェクトのみを含んだ2つ目のアプリケーション・モジュールを作成するのではなく、両方のユースケースを組み合せることもできます。
その他の状況では、2つ以上のルート・アプリケーション・モジュールの作成を指定することがあります。たとえば、ユーザー・セッションごとに2つ以上のトランザクションをサポートする必要がある場合は、複数のアプリケーション・モジュールを作成できます。または、「タスク・フローのトランザクションの管理」に説明されているとおり、データ・コントロール・スコープとタスク・フローを操作してトランザクションを管理できます。
アプリケーション・モジュールの設計時に、ビュー・オブジェクト・コンポーネントのインスタンスを使用してそのデータ・モデルを定義します。ユーザー・インタフェースに含まれるButton
コンポーネントの2つのインスタンスに、区別するためのmyButton
およびanotherButton
というメンバー名が付けられているように、アプリケーション・モジュールにも、CustomerVO
ビュー・オブジェクト・コンポーネントの2つのインスタンスに、区別するためのCustomerList
およびAnotherCustomerList
というメンバー名が付けられています。
JDeveloperでは、すべてのアプリケーション・モジュールに対してデフォルトのランタイムJDBCデータソース接続を使用しなくても、各ADFアプリケーション・モジュールのJDBCデータソース定義を変更できます。
データ・モデル・プロジェクトを初期化してADFビジネス・コンポーネントを使用する場合、データベース接続の詳細を指定するように求められます。ADFビジネス・コンポーネント・ウィザードを実行し、データベースの表やビューを操作してビジネス・コンポーネントを作成する前に、データベース接続を指定する必要があります。接続の詳細を指定すると、JDeveloperにより、現在のプロジェクトで作成されたすべてのアプリケーション・モジュールのデフォルトのランタイム接続として使用されるJava Database Connectivity (JDBC)データソースも作成されます。
アプリケーション・モジュール構成(bc4j.xcfg
ファイル)の概要エディタを使用して、各アプリケーション・モジュールのJDBCデータ・ソース定義を個々に変更できます。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。データ・ソースを使用しない場合は、概要エディタを使用して、個別のアプリケーション・モジュールの接続タイプをJDBC URL接続タイプに変更することもできます。
JDBCデータソースまたはJDBC URL接続タイプを使用すると、Javaの実行が可能なコンテキストであればどこでもアプリケーション・モジュールを実行できます。つまり、Java Enterprise Edition (Java EE)アプリケーション・サーバー内での実行に限定されません。たとえば、Oracle ADFモデル・テスターは、スタンドアロンのJavaツールで、Java EEアプリケーション・サーバーのコンテキストでは実行できませんが、このどちらかの接続タイプを使用すれば、Oracle ADFモデル・テスターでビジネス・モデルをテストできます。アプリケーション・モジュール構成の概要エディタを使用して、「データベース」ウィンドウに表示される既存のアプリケーション・リソース接続に対して、2つの中から接続タイプを選択できます。
アプリケーション・モジュールは、デフォルトでデータソース接続タイプを使用するように構成されます。JDBCデータソースは、データベース・サーバー接続をベンダーに依存しない形式でカプセル化したものです。JDBCデータソースは、JDBC URL接続タイプでは得られない利点を提供します。データソースに基づき接続タイプを定義すると、デプロイされたアプリケーションを変更することなく、データソースの再構成が行えます。データソースはアプリケーション・サーバー・レベルで一元定義できますが、JDBC URL接続ではそれが行えません。JDBCデータソースを使用できない場合は、ADFビジネス・コンポーネントにより、データソース接続情報に基づいて実行時にデフォルトのJDBC URLが構成されます。
すべてのデフォルト・アプリケーション・モジュール構成で使用される接続タイプは、JDBCデータソースです。JDBCデータソースをアプリケーション・サーバー構成情報の一部として定義すると、アプリケーション・モジュールが実行時に論理名を使用してリソースを検索します。接続タイプとしてJDBCデータソースを使用すると、アプリケーション・リソース接続の詳細が変更される場合がありますが、デプロイされているアプリケーション・モジュール構成を変更する必要はありません。JDBCデータソースがすべてのアプリケーション・モジュール構成の選択肢としてお薦されているのは、このような理由によります。図13-12に、アプリケーション・モジュール構成(bc4j.xcfg
ファイル)の概要エディタに表示されたデフォルトの選択肢を示します。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。
注意:
「接続タイプ」ドロップダウンに表示される、もう一方の接続タイプはJDBC URL接続です。この接続タイプは、レガシー・アプリケーション用にサポートされています。これは、JDBCデータ・ソ-ス接続タイプのかわりに使用しないでください。
次の例は、Fusion Webアプリケーションのweb.xml
ファイルの<resource-ref>
タグを示しています。これらは、jdbc/Summit_adfDS
およびjdbc/Summit_adfCoreDS
という名前の2つの論理データソースを定義しています。アプリケーション・モジュール構成の概要エディタは、「データソース名」フィールドの接頭辞java:comp/env
の後ろにあるこの論理接続名を参照します。たとえば、同じFusion WebアプリケーションのJDBCデータ・ソース名は選択可能な値java:comp/env/jdbc/summit_adfDS
を表示します。このように、「データソース名」フィールドには、使用可能なすべてのアプリケーション・リソース接続名のJNDI名が事前に取り込まれます。
<!-- In web.xml --> <resource-ref> <res-ref-name>jdbc/summit_adfDS</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> <resource-ref> <res-ref-name>jdbc/summit_adfCoreDS</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>
ターゲットのスタンドアロン・アプリケーション・サーバー上でアプリケーションを実行するために必要なグローバル・データ・ソースの接続名を指定する場合は、「データソース名」フィールドを直接編集できます。Oracle WebLogic Serverのデプロイ時、デフォルトでは、アプリケーション固有のデータ・ソースにアプリケーションはパッケージされておらず、Oracle WebLogic Serverはjava:comp/env/jdbc/
applicationConnectName
DS
の検索によって、jdbc/
applicationConnectName
DS
という名前のグローバル・データ・ソースの検索を行うように設定されています。したがって、この命名規則に従うことで、アプリケーション固有のデータ・ソースを使用してアプリケーションをJDeveloperで実行する場合や、グローバル・データ・ソースを使用してデプロイ済のスタンドアロン・サーバー上で実行する場合に、単一のデータ・ソース接続名を正しく機能させることができます。
注意:
冗長なデータベースやバックエンドとしてのOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、アプリケーションはマルチ・データ・ソースを使用します。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースと非マルチ・データ・ソースで命名規則は同じになります。これによって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するマルチ・データ・ソースの構成の詳細は、『高可用性ガイド』のマルチ・データ・ソースに関する項を参照してください。
「構成の編集」ダイアログで接続タイプを選択すると、JDeveloperにより、アプリケーション・モジュールのXMLドキュメントに関連する./common
サブディレクトリにあるアプリケーション・モジュール構成ファイル、bc4j.xcfg
が更新されます。このファイルは、1つのJavaパッケージ内の全アプリケーション・モジュールの構成を定義しています。bc4j.xcfg
ファイルは「アプリケーション」ウィンドウには表示されません。JDeveloperでbc4j.xcfg
ファイルを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックし、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。
たとえば、コアSummit ADFサンプル・アプリケーションのModel
プロジェクトの./classes/oracle/summit/model/services/common
ディレクトリにあるSummitAppModule
アプリケーション・モジュールでアプリケーション・モジュール構成(bc4j.xcfg
ファイル)の概要エディタを開くと、そのアプリケーション・モジュール用に名前の付いた構成があることがわかります。
bc4j.xcfg
ファイルで定義された構成により、Fusion Webアプリケーションはデプロイ済の特定のアプリケーション・モジュールとの対話が可能になります。bc4j.xcfg
ファイルには、アプリケーション・モジュールの接続タイプに加えて、アプリケーション・モジュール名に関するメタデータ情報と、アプリケーション・モジュールに構成されたランタイム・パラメータが含まれています。名前付き接続タイプのアプリケーション・リソース・データベース接続の詳細は、「アプリケーション」ウィンドウの「接続」ノードに定義され、アプリケーションのconnection.xml
ファイルに格納されています。
次の例は、コアSummit ADFサンプル・アプリケーションのbc4j.xcfg
ファイル例を示しています。SummitAppModuleLocal
およびSummitAppModule
の構成は、どちらもJDBCDataSource
属性内のデータソース(名前はSummit_adfDS
)を参照します。各構成のJDBCDataSource
属性には、アプリケーション・リソース接続名のJNDI名を、java:comp/env/jdbc/
applicationConnectName
DS
の形式で指定します。ここで、applicationConnectName
は、JDeveloperで定義されたアプリケーション・リソース・データベース接続名(この場合はSummit_adf
)です。このJNDI命名規則(アプリケーション固有ネームスペースjava:comp/env/jdbc/
およびDS
をアプリケーション・リソース・データベース接続名に付加したもの)により、デプロイされたFusion Webアプリケーションは、変更を加えなくてもアプリケーションのグローバル・データソースを使用してOracle WebLogic Server上で実行されます。グローバル・データ・ソースは通常、アプリケーション・サーバー管理者がOracle WebLogic Server管理コンソールを使用して定義します。
<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration"> <AppModuleConfigBag ApplicationName="oracle.summit.model.services.SummitAppModule"> <AppModuleConfig name="SummitAppModuleLocal" DeployPlatform="LOCAL" JDBCName="summit_adf" jbo.project="oracle.summit.model.Model" java.naming.factory.initial="oracle.jbo.common.JboInitialContextFactory" ApplicationName="oracle.summit.model.services.SummitAppModule"> <Database jbo.TypeMapEntries="Java"/> <Security AppModuleJndiName="oracle.summit.model.services.SummitAppModule"/> <Custom ns0:JDBCDataSource="java:comp/env/jdbc/summit_adfDS" xmlns:ns0="http://xmlns.oracle.com/bc4j/configuration"/> </AppModuleConfig> ... </AppModuleConfigBag> </BC4JConfig>
アプリケーション・モジュールのXML定義の作成に加え、JDeveloperでは、アプリケーション・モジュールのXML定義ファイルを含むディレクトリを相対位置とするcommon
という名前のサブディレクトリにあるbc4j.xcfg
ファイルにappModuleName
Local
という名前のデフォルトの構成も追加します。bc4j.xcfg
ファイルは「アプリケーション」ウィンドウには表示されません。JDeveloperでbc4j.xcfg
ファイルを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックし、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。デフォルト設定を表示したり、アプリケーション・モジュールのランタイム構成の設定を変更するには、概要エディタで「データベースとスケーラビリティ」タブを選択し、必要な変更を加えます。
始める前に:
アプリケーション・モジュール・データベース接続に関する知識があると役立つ場合があります。詳細は、「アプリケーション・モジュールのデータベース接続の構成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
アプリケーション・モジュールの構成を管理するには:
アプリケーションの開発時、多数の異なるユーザーやスキーマを切り替える場合があります。これには、そのビジネス・コンポーネントを含むプロジェクトのデータベース接続プロパティを変更します。選択を行うと、プロジェクトのbc4j.xcfg
ファイルで、JDBC URLタイプ接続を指定する各構成の接続文字列が自動的に更新されます。
始める前に:
アプリケーション・モジュール・データベース接続に関する知識があると役立つ場合があります。詳細は、「アプリケーション・モジュールのデータベース接続の構成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
アプリケーション・モジュールの構成で使用する接続を変更するには:
JDeveloperでは、アプリケーション・モジュールのネストによって複合ADFアプリケーション・モジュールを作成できます。これにより、上位アプリケーション・モジュールで内部アプリケーション・モジュールの機能を使用できます。
アプリケーション・モジュールでは、高レベルな機能により複数のビジネス・ワークフローに共通なサブ機能が再使用される、ユースケースのモジュール性を模倣するソフトウェア・コンポーネントを作成する機能をサポートしています。このモジュール性は、他のアプリケーション・モジュールのインスタンスを使用してアセンブルする複合アプリケーション・モジュールを定義することで実装できます。このタスクはアプリケーション・モジュールのネストと呼ばれています。つまり、アプリケーション・モジュールにはビュー・オブジェクト・インスタンスだけでなく、1つ以上の他のアプリケーション・モジュール・インスタンスを(論理的に)含めることができます。最も外側に含まれているアプリケーション・モジュールは、ルート・アプリケーション・モジュールと呼ばれています。
ネストされたアプリケーション・モジュール定義の宣言的サポートは、図13-14に示すように、アプリケーション・モジュールの概要エディタから使用できます。アプリケーション・モジュールのAPIでも、実行時のアプリケーション・モジュールのネストがサポートされています。
アプリケーション・モジュールのインスタンスを別のアプリケーションにネストするときは、ビュー・オブジェクト・インスタンスをそのデータ・モデルに集約するのみならず、そこで定義されているカスタム・サービス・メソッドも集約します。アプリケーション・モジュールのインスタンスを別のアプリケーション・モジュール内でネストまたは再利用するこの機能は、大規模で実用的なアプリケーション・システムを実装するための、ADFビジネス・コンポーネントの重要な設計要素です。
アプリケーション・モジュールがエンド・ユーザーのユースケースまたはワークフローを表していることを考えると、一部の共有のモジュール化ユースケースで必要なデータを提供するアプリケーション・モジュールを作成でき、より複雑なユースケースをサポートするように設計されている、より複雑な別のアプリケーション・モジュール内でそれらのアプリケーション・モジュールを再使用できます。たとえば、アプリケーション・モジュールBackOfficeAM
およびCustomerSelfServiceAM
を作成した後に、この両方のサービスを新しいコンポジット・サービス・アプリケーション・モジュールの不可欠な部分として使用するアプリケーションの作成が必要になったとします。図13-13は、このコンポジット・サービスがJDeveloperのビジネス・コンポーネント・ダイアグラムでどのように表示されるかを示しています。この図に示すように、SummitAppModule
などのアプリケーション・モジュールには、ビュー・オブジェクト・インスタンスとアプリケーション・モジュール・インスタンスを含めることができます。
図13-13 アプリケーション・モジュール・インスタンスの再使用によるコンポジット・サービスのアセンブル
既存のアプリケーション・モジュールのインスタンスをネストする複合ルート・アプリケーション・モジュールを指定するには、アプリケーション・モジュールの概要エディタを使用します。(アプリケーション・モジュール・インスタンスに含まれる)ネストされたすべてのコンポーネント・インスタンスでは、それらのインスタンスを再使用するルート・アプリケーション・モジュールと同じトランザクションとエンティティ・オブジェクト・キャッシュが共有されます。
たとえば、Summit ADFサンプル・アプリケーションのSummitADF
ワークスペースで、ネストしたアプリケーション・モジュール・インスタンスBackOfficeAM
およびCustomerSelfServiceAM
は、ルート・アプリケーション・モジュールSummitAppModule
と同じトランザクションおよびエンティティ・オブジェクト・キャッシュを共有します。
ヒント:
ネストされたアプリケーション・モジュールをアプリケーションで利用する場合は、「「データ・コントロール」パネルでのネストされたアプリケーション・モジュールの表示」を必ず参照して、これらのモジュールを含むデータ・バインディングの実行時によく発生する問題を回避してください。
始める前に:
ネストされたアプリケーション・モジュールに関する知識があると役立つ場合があります。詳細は、「ネストされたアプリケーション・モジュールの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
ネストされたアプリケーション・モジュールを定義するには:
実行時に、アプリケーションはメインの、またはルートと呼ばれている、アプリケーション・モジュールを使用します。どのアプリケーション・モジュールもルート・アプリケーション・モジュールとして使用できますが、実際には、単純なCRUDアプリケーションを作成している場合を除き、より複雑なエンド・ユーザーのユースケースに対応するアプリケーション・モジュールがルートとして使用されます。ルート・アプリケーション・モジュールに別のアプリケーション・モジュールがネストされている場合、そのモジュールはすべてルート・アプリケーション・モジュールのトランザクションに関与し、同じデータベース接続および単一のエンティティ・キャッシュ・セットを共有します。この共有は、ルート・アプリケーション・モジュールおよびそのTransaction
オブジェクトによって自動的に処理されます。
また、トランザクション境界を宣言的に管理するためADFバインド・タスク・フローを使用してアプリケーションを作成する場合、Oracle ADFフレームワークにより実行時にタスク・フローで使用されるアプリケーション・モジュールが自動的にネストされます。バインド・タスク・フローとトランザクションの詳細は、「タスク・フローのトランザクションの管理」を参照してください。
他のユーザーが参照できるADFアプリケーション・モジュールUMLダイアグラムを作成できます。ダイアグラムを使用してアプリケーション・モジュールの詳細を変更します。
ビジネス・サービスのデータ・モデルを開発する際、多くの場合、UMLモデルを使用して視覚化すると便利です。JDeveloperでは、他の開発者が参照できるアプリケーション・モジュール用のダイアグラムを簡単に作成できます。
アプリケーション・モジュールの編集、表示オプションの制御、メソッド名のフィルタ処理、関連するオブジェクトやファイルの表示、アプリケーションの公開、Oracle ADFモデル・テスターの起動など、多数のタスクをダイアグラム上で直接実行できます。
アプリケーション・モジュールのダイアグラムを作成するには、「新規ギャラリ」から使用できる「ビジネス・コンポーネント・ダイアグラムの作成」ダイアログを使用します。
始める前に:
UMLモデル・ダイアグラムについて理解しておくと役立つ場合があります。詳細は、「ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュールのダイアグラムを作成するには:
これらの手順の完了後、ダイアグラムは図13-15のようになります。
ビジネス・コンポーネント・ダイアグラムを作成すると、ダイアグラムが格納されているパッケージ名と一致するプロジェクトのモデル・パスのサブディレクトリに、ダイアグラムを示す.adfbc_diagram
ファイルが作成されます。
デフォルトでは、「アプリケーション」ウィンドウによってプロジェクト・コンテンツのパスの表示が統一され、ソース・パスのADFコンポーネントおよびJavaファイルがプロジェクト・モデル・パスのUMLモデル・アーティファクトと同じパッケージ・ツリーに表示されます。「アプリケーション」ウィンドウで「アプリケーション・ウィンドウのオプション」→「ディレクトリの表示」ツールバー・オプションを使用して、プロジェクト・コンテンツのユニファイド・ディレクトリ・ビューとより明確なディレクトリ・パス・ビューを切り替えられます。
ビジネス・コンポーネントのUMLダイアグラムは、アプリケーション・モジュールをダイアグラムにドロップした時点の状態を示す単なる静的な図ではありません。むしろ、UMLダイアグラムは、現在のコンポーネント定義をUMLベースでレンダリングした図であるため、常に現在の状況を示しています。UMLダイアグラムは、視覚化を可能にするのみならず、視覚的なナビゲーションおよび編集ツールでもあります。
ポップアップ・メニューから「プロパティ」を選択(またはアプリケーション・モジュールをダブルクリック)すると、任意のアプリケーション・モジュールの概要エディタを起動できます。
また、ビュー・オブジェクト・インスタンス名の変更、ビュー・オブジェクト定義を「アプリケーション」ウィンドウからデータ・モデルにドロップすることによる新しいビュー・オブジェクト・インスタンスの作成、[Del]キーを押すことによるビュー・オブジェクト・インスタンスの削除など、いくつかのアプリケーション・モジュール編集タスクもダイアグラム上で直接実行できます。
注意:
コンポーネントをダイアグラムから削除すると、その表示のダイアグラム画面からの削除のみが行われます。コンポーネントとクラスはファイル・システムと「アプリケーション」ウィンドウ内に存続します。
ダイアグラムでアプリケーション・モジュールを表示後、「ビジュアル・プロパティの編集」ダイアログを使用して表示オプションを制御します。ダイアグラムのダイアログを表示するには、ダイアグラム内でアプリケーション・モジュール・ノードを右クリックし、「ビジュアル・プロパティ」を選択します。
「表示」ページで、プロパティを次のように切り替えます。
パッケージを表示 - パッケージ名を表示
メソッドの表示 - サービス・メソッドを表示
ステレオタイプの表示 - オブジェクトの型を表示(「<<application module>>
」など)
使用方法の表示 - 現在のプロジェクトの他のアプリケーション・モジュールによるすべての使用を表示
「メソッド」ページでは、ダイアグラムに求められる詳細のレベルに応じて次の設定を変更します。
可視性の表示(「public」、「private」など)
メソッドの戻りタイプの表示
staticメソッドの表示
図13-16の「ビジュアル・プロパティの編集」ダイアログの設定に示すように、デフォルトでは、アプリケーション・モジュールのすべての操作が表示されます。
図13-16 デフォルトのダイアグラム・エディタのオプションを示す「ビジュアル・プロパティの編集」ダイアログ
ダイアグラムのコンテキスト・メニューでは、「表示モード」に対して次を選択することもできます。
圧縮 - アイコンおよび名前のみを表示
シンボル - サービス操作を表示
展開済 - 操作およびデータ・モデルを表示(デフォルト)
デフォルトでは、アプリケーション・モジュールのメソッドを表示すると、ダイアグラムにすべてのメソッドが表示されます。オーバーライドされたフレームワーク・メソッドとして認識されるメソッドは、すべて「Framework」操作カテゴリに表示されます。他のメソッドは、「Business」メソッド・カテゴリに表示されます。
「ビジュアル・プロパティの編集」ダイアログの「メソッド」 ページの「対象外のメソッド・フィルタ」設定は、ダイアグラムに表示したくないメソッドを除外するために使用できる正規表現です。たとえば、「対象外のメソッド・フィルタ」を次のように設定します。
findLoggedInUser.*|retrieveOrder.*|get.*
この場合、次のアプリケーション・モジュール・メソッドをすべてフィルタ処理できます。
findLoggedInUserByEmail
retrieveOrderById
生成されたビュー・オブジェクトのgetterメソッド全般
ダイアグラム上でアプリケーション・モジュール(またはそのデータ・モデル内の任意の個別ビュー・オブジェクト・インスタンス・セット)の選択後、「表示」→「関連する要素」をコンテキスト・メニューから選択し、ダイアグラムに関連するコンポーネントを表示できます。同様に、「表示」→「実装ファイル」を選択することで、アプリケーション・モジュールを実装するファイルをダイアグラムに含むことができます。求められる詳細のレベルがダイアグラムに追加されるまで、表示されている追加ダイアグラム要素に対して前述のオプションを繰り返し使用できます。
図13-17は、アプリケーション・モジュールの実装ファイルを表示した図を示しています。アプリケーション・モジュールの実装クラスの関連要素(AppModuleImpl
)が表示されています。また、アプリケーション・モジュールと実装クラス間の依存性を示す追加の線も表示されています。特定のカスタム・インタフェースにアプリケーション・モジュール・インスタンスをキャストした場合でも、図のように表示されます。
図13-17 「表示」→「関連する要素」および「表示」→「実装ファイル」によるダイアグラムへの詳細の追加
ダイアグラムをPNG
、JPG
、SVG
または圧縮されたSVG
書式で公開するには、ダイアグラム上でポップアップ・メニューから「ダイアグラムの公開」を選択します。
ADFアプリケーション・モジュール・プーリングを使用して、スケーラブルなフォールト・トレラント・アプリケーションを実装します。
Fusion Webアプリケーションとの対話中に、エンド・ユーザーには次のような状況が発生する場合があります。
同じページを複数回表示する場合に、迅速なレスポンスを期待
完了までに多数のページを表示する必要がある論理作業ユニットを実行
未保存の保留中の変更内容の部分的なロールバックの実行を要求
サーバー・ファームのアプリケーション・サーバー障害による、保存前の保留中の変更への不可抗力的な被害
アプリケーション・モジュール・プーリング機能および状態管理機能では、これらの要件に対処するスケーラブルで高パフォーマンスの実装を簡略化します。
注意:
ADFバインド・タスク・フローは、トランザクションの作業ユニットを表すことができます。タスク・フローのオプションを指定して、トランザクションの処理方法を決定できます。ADFバインド・タスク・フローの宣言的な機能の詳細は、「タスク・フローのトランザクションの管理」を参照してください。
実行する状態管理機能をシミュレートするために、アプリケーション・モジュールでOracle ADFモデル・テスターの2つのインスタンスを起動できます。
始める前に:
状態管理に関する知識があると役立つ場合があります。詳細は、「複数ページの作業ユニットのサポート」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
Oracle ADFモデル・テスターを使用してトランザクション状態の受動化をシミュレートするには:
この時点で、保留中の変更が、変更した行に再反映されます。ここでトランザクションをコミットすると、変更内容はデータベースに永続的に保存されます。
アプリケーション・モジュールをそのビジネス・サービスとして利用するアプリケーションを作成すると、そのアプリケーションでは自動アプリケーション・モジュール・プーリング機能を使用できます。この機能では、アプリケーションに対するエンド・ユーザーの負荷(ロード)の日中の変化に応じて増減するアプリケーション・モジュール・インスタンスの構成可能なセットを管理します。アプリケーション・ユーザー・インタフェースとのエンド・ユーザーの対話に特有の思考時間の性質により、プール内のアプリケーション・モジュール・インスタンスの数は、システムを使用しているアクティブ・ユーザーの合計数より少なくなる場合があります。
図13-18に示すように、あるエンド・ユーザーがアプリケーションの複数ページを表示して論理タスクを実行する場合、各ページ・リクエストに対し、プール内のアプリケーション・モジュール・インスタンスがその1リクエストの存続時間中にプールから自動的に取得されます。リクエストの最後に、インスタンスはプールに自動的に戻され、別のユーザー・セッションで使用可能になります。エンド・ユーザーの作業をアプリケーション・サーバーの障害から保護するために、アプリケーション・モジュールでは、そのエンティティ・キャッシュ内の保留中の変更セットを示すXMLスナップショットを保存することで、その変更セットを永続ストアに格納する機能をサポートしています。スケーラビリティ上の理由から、この状態スナップショットは通常、アプリケーション・データを含むデータベース・スキーマとは別の状態管理スキーマに保存されます。
図13-18 複数ページの論理作業ユニット全体に対するプールされたアプリケーション・モジュールの使用方法
プーリング・アルゴリズムではチューニング可能な最適化が行え、特定数のアプリケーション・モジュール・インスタンスが、プールに戻された最後のユーザー・セッションとの「スティッキー」な状態を維持しようとします。最適化は保証されていませんが、ユーザーが最適化による利益を得ることができれば、システム・ローダーが許容する限り、プール内の同じアプリケーション・モジュール・インスタンスを継続的に使用します。負荷が重すぎる場合、プーリング・アルゴリズムはプール内で使用可能な任意のインスタンスを使用してユーザーのリクエストに応え、その論理作業単位の凍結スナップショットを永続ストアから再構築して、アプリケーション・モジュールの新しいインスタンスが前回途中になったところから継続できるようにします。エンド・ユーザーは変更をコミットまたはロールバックするまで、この方法で作業を継続します。
アプリケーション・モジュールはこれらの機能を使用し、完全にステートレスなアプリケーションに近い実行時パフォーマンスを実現するアーキテクチャにおいて、複数ページのワークフローを簡単に処理できる、生産性の高いステートフルなパラダイムを実現します。これらのアプリケーション・モジュール機能の詳細は「Fusion Webアプリケーションでの状態管理の使用」を、チューニング方法の詳細は「アプリケーション・モジュール・プールのチューニング」を参照してください。
ビジネス機能実装の論理的側面である外部クライアント・コードをADFアプリケーション・モジュールのカスタムJavaクラスに収容できます。
アプリケーション・モジュールでは、カスタムJavaコードを必要とせずに、そのビュー・オブジェクト・インスタンスのデータ・モデルをクライアントに公開できます。このため、クライアント・コードではoracle.jbo
パッケージのApplicationModule
、ViewObject
、RowSet
およびRow
というインタフェースを使用して、データ・モデル内のビュー・オブジェクトを直接操作できます。ただし、クライアント・コードで自由にビュー・オブジェクトをプログラミングで操作できても、それが必ずしもベスト・プラクティスではありません。
ビュー・オブジェクトを操作するプログラム的なコードが完全なビジネス・サービス機能を実装するための論理的な特徴を備えている場合、アプリケーション・モジュールのJavaクラスでカスタム・メソッドを記述して、詳細をカプセル化する必要があります。これには次のコードが含まれます。
表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成
集計結果を取得するための、ビュー・オブジェクト行の反復処理
1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行
これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。
コードの目的が、クライアントにより明確に伝わります。
必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。
ビジネス・サービス機能全体の回帰テストを簡略化できます。
クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。
ページ内での論理的ビジネス機能の宣言的起動が可能になります。
カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、まずそのカスタムJavaクラスを有効化する必要があります。IDEレベルの「ビジネス・コンポーネント」のJava生成設定で、アプリケーション・モジュール・クラスが自動的に生成されるように構成されている場合は、カスタム・クラスが発生します。図13-19に示すように、アプリケーション・モジュールにカスタムJavaクラスがあるかどうかが不明な場合は、「アプリケーション」ウィンドウでそのアプリケーション・モジュール・ノードの概要エディタを開きます。エディタの「Javaクラス」ページに、プロジェクトのアプリケーション・モジュール用に生成されたクラスの完全リストが表示されます。他のユーザーによりすでにファイルが作成されているため存在する場合、「Javaクラス」ページには「アプリケーション・モジュール・クラス」として特定された、リンクされたファイル名が表示されます。ソース・エディタで既存ファイルを開くには、対応するファイル名のリンクをクリックします。
図13-19 概要エディタのアプリケーション・モジュールのカスタムJavaクラス
プロジェクトにJavaクラスが存在しない場合、アプリケーション・モジュールの概要エディタの「Javaクラス」ページで生成できます。
始める前に:
アプリケーション・モジュールのサービス・メソッドに関する知識があると役立つ場合があります。詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュール・クラスのJavaファイルを生成するには:
アプリケーション・モジュールのカスタム・クラスを生成すると、JDeveloperではコンポーネントのXMLドキュメント・ファイルと同じディレクトリにファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleName
Impl.java
になります。
アプリケーション・モジュールに対して選択したJava生成オプションは、アプリケーション・モジュールの概要エディタの「Javaクラス」ページに後でアクセスしてもそのまま反映されています。XML定義ファイルの場合と同様、このエディタでどのような変更を行っても、カスタムJavaクラスで生成されたコードは最新の状態に保たれます。後でカスタムJavaファイルが不要になった場合は、「Javaクラス」ページから「Javaオプションの選択」ダイアログを開き、「アプリケーション・モジュール・クラスの生成」の選択を解除すると、プロジェクトからカスタムJavaファイルが削除されます。
デフォルトでは、アプリケーション・モジュールのJavaクラスは、最初に有効化した際、次の例のようになります。それには、データ・モデルの各ビュー・オブジェクト・インスタンス用のgetterメソッドが含まれます。
package oracle.summit.model.services; import oracle.jbo.server.ApplicationModuleImpl; // --------------------------------------------------------------------- // --- File generated by ADF Business Components Design Time. // --- Custom code may be added to this class. // --- Warning: Do not modify method signatures of generated methods. // --------------------------------------------------------------------- public class AppModuleImpl extends ApplicationModuleImpl { /** This is the default constructor (do not remove) */ public AppModuleImpl() { } /** Container's getter for YourViewObjectInstance1 */ public YourViewObjectImpl getYourViewObjectInstance1() { return (YourViewObjectImpl)findViewObject("YourViewObjectInstance1"); } // ... Additional ViewObjectImpl getters for each view object instance // ... ViewLink getters for view link instances here }
図13-20に示すように、アプリケーション・モジュール・クラスでは、カスタム・コードを追加する前にすべてのデフォルト動作を継承するようにベースADFのApplicationModuleImpl
クラスを拡張します。
図13-20 カスタム・アプリケーション・モジュール・クラスによるApplicationModuleImplの拡張
カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、アプリケーション・モジュールのカスタム・クラスに移動して、新しいメソッドのJavaコードをアプリケーション・モジュールのJava実装クラスに入力します。次のガイドラインを使用して、メソッドに適切な可視性を判断してください。
メソッドをこのコンポーネントの実装内でヘルパー・メソッドとしてのみ使用する場合は、メソッドをprivate
にします。
アプリケーション・モジュールの最終的なサブクラスでこのメソッドを起動またはオーバーライドできるようにする場合は、メソッドをprotected
にします。
クライアントによる起動を可能にする場合は、public
にする必要があります。
注意:
この章のアプリケーション・モジュールの例では強く型付けされたカスタム・エンティティ・オブジェクト・クラスを使用しています。これらのエンティティ・クラスの作成方法の詳細は、「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」を参照してください。
次の例は、AppModule
アプリケーション・モジュールのAppModuleImpl.java
クラスでのprivate retrieveOrderById()
ヘルパー・メソッドを示しています。ここでは、関連するエンティティ定義にアクセスするためにOrdEOImpl
エンティティ・オブジェクト・クラスのstatic
getDefinitionObject()
メソッドが使用され、注文の検索に適したKeyオブジェクトを作成するためにエンティティ・オブジェクト・クラスでcreatePrimaryKey()
メソッドが使用され、エンティティ行をエンティティ・キャッシュで検索するためにエンティティ定義でfindByPrimaryKey()
メソッドが使用されています。このメソッドからは、強く型付けされたOrdersImpl
クラス(Orders
エンティティ・オブジェクトのカスタムJavaクラス)のインスタンスが戻されます。
// In summit.model.appmodule.service.AppModuleImpl class /* * Helper method to return a Order by Id */ private OrdersImpl retrieveOrderById(long orderId) { EntityDefImpl orderDef = OrdersImpl.getDefinitionObject(); Key orderKey = OrdersImpl.createPrimaryKey(new DBSequence(orderId)); return (OrdersImpl)orderDef.findByPrimaryKey(getDBTransaction(), orderKey); }
次の例は、作成する注文のIDをコール元が渡すことを可能にするpublic findOrderAndCustomer()
メソッドを示しています。OrdersImpl
エンティティ・オブジェクト・クラスのgetCustomer()
メソッドを使用して、関連するエンティティ定義にアクセスします。
/* * Create a new Customer and Return its new id */ public String findOrderAndCustomer(long orderId) { OrdersImpl order = retrieveOrderById(orderId); if (order != null) { CustomerImpl cust = order.getCustomer(); if (cust != null) { return "Customer: " + cust.getName() + ", Location: " + cust.getCity(); } else { return "Unassigned"; } } else { return null; } }
カスタム・アプリケーション・モジュールのメソッドをテストする準備ができたら、JDeveloperを使用してJUnitテスト・ケースを生成できます。JUnitでは、oracle.jbo package
で使用可能な任意のプログラムのAPIを使用して、アプリケーション・モジュールの操作およびカスタム・メソッドを起動が可能です。ADFビジネス・コンポーネントでのJUnit使用の詳細は、「JUnitを使用した回帰テスト」を参照してください。
JUnitテスト・ケースの代替方法として、カスタム・アプリケーション・モジュール・メソッドをテストする一般的な方法は、簡単なテスト・ケースを作成することです。たとえば、テスト用のコードをオブジェクトに作成し、そのコードをstatic main()
メソッドに含めます。次の例は、これから記述するサンプル・メソッドをテストするために、カスタム・アプリケーション・モジュール・クラスに追加できるサンプルのmain()
メソッドを示しています。Configuration
オブジェクトを使用して(「コマンド行Javaテスト・クライアントの作成方法」を参照)、テスト用のアプリケーション・モジュールをインスタンス化および操作します。
注意:
Configuration
オブジェクトがoracle.jbo.client
パッケージ内に存在していることは、それがアプリケーション・クライアントとしてアプリケーション・モジュールへのアクセスに使用されていることを示しています。main()
メソッドは一種のプログラム的なコマンド行クライアントであるため、このような使用方法に問題はありません。また、createRootApplicationModule()
の戻り値をアプリケーション・モジュールの実装クラスに直接キャストするのは一般的ではありませんが、このオブジェクトはアプリケーション・モジュールのクライアントであるとしても、main()
メソッドのコードがアプリケーション・モジュールの実装クラス自体の中に格納されているため、この状況でこの操作を行うことは適切です。
次の例のコードを見ると、これまでの例で作成したメソッドを使用して次が実行されていることがわかります。
注文101の合計を取得します。
注文101の顧客名を取得します。
101の注文ステータスを「Y」の値に設定します。
package oracle.summit.model.appmodule.service; import oracle.jbo.ApplicationModule; import oracle.jbo.JboException; import oracle.jbo.client.Configuration; public class TestAM { public TestAM() { super(); } /* * Testing method */ public static void main(String[] args) { String amDef = "oracle.summit.model.appmodule.service.AppModule"; String config = "AppModuleLocal"; ApplicationModule am = Configuration.createRootApplicationModule(amDef,config); /* * NOTE: This cast to use the AppModuleImpl class is OK since this * code is inside a business tier file and not in a * client class that is accessing the business tier from "outside". */ AppModuleImpl service = (AppModuleImpl)am; String customerName = service.findOrderAndCustomer(101); System.out.println("Customer for Order # 101 = " + customerName); try { service.updateOrderStatus(101,"Y"); } catch (JboException ex) { System.out.println("ERROR: "+ex.getMessage()); } Configuration.releaseRootApplicationModule(am,true); } }
カスタム・アプリケーション・モジュール・クラスを実行すると、前述の例のmain()
メソッドがコールされ、次の出力が生成されます。
anonymous Customer for Order # 101 = Customer: Kam's Sporting Goods, Location: Hong Kong
注意:
カスタム・アプリケーション・モジュールに作成したカスタム・サービス・メソッドを、クライアント・アプリケーションを使用して起動する方法の詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。
アプリケーション・ロジックが行セットにアクセスし、プログラムによる反復を実行する場合は必ず、ユーザー・インタフェース・コンポーネントにバインドされている可能性があるので、アプリケーション・モジュールのデータ・モデル内のビュー・オブジェクト・インスタンス、またはこれらのビュー・オブジェクト・インスタンスのビュー・リンク・アクセッサ行セットを扱う際に、セカンダリ行セット・イテレータを使用する必要があります。セカンダリ・イテレータを作成するには、作業対象の行セットに対してcreateRowSetIterator()
メソッドを使用します。使用を修了したら、行セットに対してcloseRowSetIterator()
メソッドを呼び出し、メモリーからセカンダリ・イテレータを削除する必要があります。次の例は、データ・モデル内のCustomerView1
ビュー・オブジェクト・インスタンスが、ユーザー・インタフェースにバインドされる可能性がある(現在または後で)ため、プログラムによる反復用に、セカンダリ行セット・イテレータを正しく使用する典型的なアプリケーション・モジュールのカスタム・メソッドを示しています。
// Custom method in an application module implementation class public void doSomeCustomProcessing() { ViewObject vo = getCustomerView1(); // create secondary row set iterator with system-assigned name RowSetIterator iter = vo.createRowSetIterator(null); while (iter.hasNext()) { Row r = iter.next(); // Do something with the current row. Integer custId = (Integer)r.getAttribute("Id"); String name = (String)r.getAttribute("Name"); System.out.println(custId + " " + name); } // close secondary row set iterator iter.closeRowSetIterator(); }
注意:
行セットのデフォルト行セット・イテレータを使用して独自の行セットの反復を行う、ビュー・オブジェクトの実装クラス内のカスタム・コードについても同じことがお薦めされます。
このような推奨は次の2つの重要な理由のために行っています。これを行わなかった場合、現在の行が予期せず変更された場合にエンド・ユーザーを混乱させてしまいます。また、最初または最後の行、あるいは両方の行がスキップされてしまうため、検出が難しいビジネス・ロジック・エラーが発生してしまうことがあります。
現在の行が突然変更されることでエンド・ユーザーが混乱
イテレータ・バインディングは、エンド・ユーザーが行セット内でどの行を現在見ているのかを判断します。プログラムによるロジックがイテレータ・バインディングと同じデフォルト行セットイテレータを使用して行セットを反復している場合、ユーザーが現在選択している行を知らない間に変更してしまい、ユーザーを混乱させてしまうことがあります。
最初または最後の行を知らない間にスキップして、検出しにくいビジネス・ロジック・エラーを誘発
イテレータ・バインディングでは、行セット・イテレータを有効な行に強制的に配置して、行セットが空の場合に、UIコンポーネントがデータを表示できるようにします。これによってカスタム・ロジックが、最初の行の前のスロット、または最後の行の後ろのスロットに移動するのを防止する効果があります(イテレータ・バインディングと同じ行セット・イテレータを使用している場合)。具体的には、典型的なwhile (iter.hasNext())
行セット反復ループは、次の例に示すように、最初の行ではなく2番目の行を処理することでスキップまたは開始されます。
// Reset the default row set iterator (iter) to the slot before the first row iter.reset(); // If an iterator binding is bound to the same default row set iterator, // then it has already forced it to navigate to the first row here instead // of being on the slot before the first row. // // If the row set iterator has only one row, the following will then return false while (iter.hasNext()) { // If the row set has more than one row, the first time through the loop // this call to next() will return the second row rather than the first // row as expected. Row curRow = iter.next(); // Do something with current row }
ADFアプリケーション・モジュール用のリソース・バンドル・ファイルを追加できます。このリソース・バンドル・ファイル(.propertiesファイル)を使用してカスタム・メッセージ文字列を保持します。
ADFアプリケーション・モジュールには通常は専用のリソース・バンドルは必要ありません。ただし、カスタム・メッセージ文字列の追加に使用できるカスタム・メッセージ文字列ファイル(.properties
)を作成できます。
作成する.properties
ファイルは、完全修飾パッケージ名とカスタム・メソッド例外メッセージによって、属性プロパティを参照できます。たとえば、メッセージ・キーと文字列を次のように定義します。
test.Order.Orderno_LABEL=Order Number INVALID=You have called the method foo in an invalid way.
リソース・バンドルでメソッドの例外メッセージ用メッセージを定義する場合、カスタム・メソッドは「アプリケーション・モジュールのクライアント・インタフェースでのカスタム・メソッドの公開方法」で説明するように、アプリケーション・モジュール・クライアント・インタフェースに表示する必要があります。
たとえば例外メッセージINVALID
のかわりに、メソッドfoo()
のメッセージを定義すると、インタフェースはリソース・バンドルからメッセージを呼び出すように、このメソッドを定義する場合があります。
public void foo() { ResourceBundleDef r = getResourceBundleDef(); throw new JboException(r,"INVALID",null); }
カスタム・メッセージ文字列を含める.properties
ファイルを作成する場合は、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページのリソース・バンドル・オプションを使用して、「1ファイル当たり1バンドル」オプションを選択します。このオプションは、デフォルトで「1プロジェクト当たり1バンドル」に設定され、プロジェクトごとに1つずつ.properties
ファイルが生成されます。
始める前に:
プロジェクトでのリソース・バンドルの使用方法を理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュール・メッセージ文字列のカスタマイズ」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
「アプリケーション・モジュールの作成方法」の説明に従って、該当するアプリケーション・モジュールを作成します。
「リソース・バンドルの使用」の説明に従い、データ・モデル・プロジェクトのプロジェクト・プロパティを設定してファイルごとに1つずつバンドルを生成します。
アプリケーション・モジュールのリソース・バンドルを生成するには:
アプリケーション・モジュールのリソース・バンドルを生成すると、JDeveloperではコンポーネントのXMLドキュメント・ファイルと同じディレクトリに.properties
ファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleName
MsgBundle.properties
になります。
次の例は、.properties
ファイルを参照するアプリケーション・モジュールXMLドキュメントのResourceBundle
要素を示しています。
<AppModule ... <ResourceBundle> <PropertiesBundle PropertiesFile= "oracle.summit.model.services.common.BackOfficeAppModuleMsgBundle"/> </ResourceBundle> </AppModule>
ユーザー・インタフェースでADFアプリケーション・モジュール・クラスのpublicカスタム・メソッドを起動するには、そのメソッドをアプリケーション・モジュールのUIクライアント・インタフェースに追加します。
アプリケーション・モジュール・クラスにpublic
カスタム・メソッドを追加する際に、アプリケーションのUIによるそのメソッドの起動を可能にする場合、そのメソッドをアプリケーション・モジュールのUIクライアント・インタフェースに追加する必要があります。
アプリケーション・モジュールのカスタムJavaクラスのpublicメソッドをクライアント・インタフェースに追加するには、アプリケーション・モジュールの概要エディタで「Javaクラス」ページを使用します。
始める前に:
クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
クライアント・インタフェースにカスタム・メソッドを公開するには:
図13-21は、クライアント・インタフェースに追加した複数のpublicメソッドを示しています。
図13-21 アプリケーション・モジュールのクライアント・インタフェースに追加したpublicメソッド
カスタム・サービス・メソッドをクライアント・インタフェースに公開すると、図13-22に示すように、アプリケーション・モジュールと同じ名前のJavaインタフェースが、アプリケーション・モジュールが存在するパッケージのcommon
サブパッケージに作成されます。summit.model
パッケージのAppModule
という名前のアプリケーション・モジュールでは、このインタフェースはAppModule
という名前になり、summit.model.common
パッケージに作成されます。このインタフェースにより、oracle.jbo
パッケージのベースApplicationModule
インタフェースが拡張され、アプリケーション・モジュールがApplicationModuleImpl
クラスから継承するすべてのベース機能へのクライアント・アクセスが可能になります。
図13-22 カスタム・クライアント・インタフェースによるベースApplicationModuleインタフェースの拡張
次の例に示すように、AppModule
インタフェースには、アプリケーション・モジュールのクライアント・インタフェースに配置するように選択したすべてのメソッドのメソッド・シグネチャが含まれています。
package summit.model.appmodule.service.common; import oracle.jbo.ApplicationModule; // --------------------------------------------------------------------- // --- File generated by ADF Business Components Design Time. // --------------------------------------------------------------------- public interface AppModule extends ApplicationModule { String findOrderAndCustomer(long orderId); void updateOrderStatus(long orderId, String newStatus); String findOrderTotal (long orderId); long createCustomer(String name, String city, Integer countryId); }
注意:
新しいカスタム・メソッドをクライアント・インタフェースに追加した後で、JDeveloperのコード・インサイトによる状況依存の文補完を使用したときにこのカスタム・メソッドを使用できない場合は、生成されたクライアント・インタフェースの再コンパイルを試行してください。これを実行するには、「アプリケーション」ウィンドウでアプリケーション・モジュールを選択し、「構造」ウィンドウで同じ名前のインタフェースのソース・ファイルを選択して、ポップアップ・メニューから「再ビルド」を選択します。このヒントは、ビュー・オブジェクトにかぎらず、ビュー行に追加された新しいカスタム・メソッドでも参考にしてください。
アプリケーション・モジュールのクライアント・インタフェースを生成することに加えて、カスタマイズ可能な他のキー・クライアント・オブジェクトを操作するための強く型付けされたクライアント・インタフェースも生成できます。たとえば、カスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースとビュー行クライアント・インタフェースにそれぞれ追加できます。
始める前に:
クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
ビュー・オブジェクトのクライアント・インタフェースにカスタム・メソッドを公開するには:
summit.model.views
パッケージのCustomerView
ビュー・オブジェクトに対してカスタム・ビュー・オブジェクトのJavaクラスの生成を可能にし、1つ以上のカスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースに追加すると、図13-23に示すように、CustomerViewImpl
クラスおよびCustomerView
インタフェースが生成されます。アプリケーション・モジュール・カスタム・インタフェースと同様に、common
サブパッケージに生成されます。
図13-23 カスタム・ビュー・オブジェクト・インタフェースによるベースViewObjectインタフェースの拡張
同様に、同じビュー・オブジェクトに対してカスタム・ビュー行のJavaクラスの生成を有効にして、1つ以上のカスタム・メソッドをビュー行クライアント・インタフェースに追加すると、図13-24に示すように、CustomerViewRowImpl
クラスおよびCustomerViewRow
インタフェースが生成されます。
カスタム・アプリケーション・モジュールのメソッドは、「UIクライアントへのカスタム・サービス・メソッドの公開」で説明しているように、クライアント・インタフェースに公開した後にOracle ADFモデル・テスターでテストできます。
始める前に:
クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
公開したサービス・メソッドのテスト方法:
クライアント・インタフェースには、次の実装ルールに従うカスタム・メソッドを追加できます。
メソッドの戻り型がvoid
以外の場合、型はシリアライズ可能である必要があります。
メソッドが任意のパラメータを受け入れる場合、その型はすべてシリアライズ可能である必要があります。
メソッド・シグネチャにthrows句が含まれる場合、例外はoracle.jbo
パッケージのJboException
のインスタンスである必要があります。
つまり、そのメソッド・シグネチャ内のすべての型はjava.io.Serializable
インタフェースを実装する必要があり、チェック済の例外はJboException
またはそのサブクラスである必要があります。メソッドでは、アプリケーション・モジュールのクライアント・インタフェースで非表示になることなく、未チェックの例外(java.lang.RuntimeException
またはそのサブクラス)をスローできます。
java.util.List
の型のメソッド・シグネチャは、インタフェースの実装クラスがシリアライズ可能な限り使用できる点に注意してください。たとえば、java.util.ArrayList
およびjava.util.LinkedList
は両方ともシリアライズ可能なクラスです。同じ要件がコレクション内の要素型に適用されます。インタフェースを実装しているクラスをインスタンス化したにもかかわらず、java.io.Serializable
インタフェースを実行しなかった場合、ADFビジネス・コンポーネント・ランタイムはエラーを生成します。
注意:
アプリケーション・モジュール・クラスに追加したメソッドが「使用可能」リストに表示されない場合は、メソッド実装ルールのいずれか違反していないかをまず確認してください。適切なメソッドと判断できる場合は、アプリケーション・モジュールの概要エディタに再移動する前に、アプリケーション・モジュール・クラスの再コンパイルを試行してください。
アプリケーション・モジュールのカスタム・メソッドのプライベート実装では、生成されたアクセッサ・メソッドを使用してデータ・モデル内のビュー・オブジェクト・インスタンスを簡単に参照できます。ビュー・オブジェクトでgetCurrentRow()
メソッドをコールすると、クライアント・ユーザー・インタフェースでビュー・オブジェクトの現在行として認識されている行にアクセスできます。その結果、アプリケーション・モジュールのビジネス・サービス・メソッドの記述中には、クライアントからのパラメータの引渡しが不要な場合があります。これは、同じアプリケーション・モジュールのデータ・モデルにある他のビュー・オブジェクト・インスタンスの現在行から値を渡すのみの場合に該当します。
たとえば、次の例にあるカスタム・アプリケーション・モジュール・メソッドではパラメータを受け入れません。createOrderItem()
メソッドはgetGlobals().getCurrentRow()
を内部でコールし、Globals
ビュー・オブジェクト・インスタンスの現在行にアクセスします。次に、強く型付けされたアクセッサ・メソッドを行で使用してDescription
およびLineItemId
属性の値にアクセスし、この値を、新規作成されたOrderItem
エンティティ・オブジェクト行の対応する属性の値として設定します。
// In AppModuleImpl.java, createOrderItem() method GlobalsRowImpl globalsRow = (GlobalsRowImpl)getGlobals().getCurrentRow(); newOrder.setDescription(globalsRow.getDescription()); newOrder.setLineItemId(globalsRow.getLineItemId());
ADFビジネス・コンポーネント・アプリケーション・モジュールのクライアント・インタフェースを使用すると、アプリケーション・モジュールをプログラムで操作できます。
メソッドをアプリケーション・モジュールのクライアント・インタフェースに公開したら、それらのメソッドをクライアントから起動できます。
アプリケーション・モジュールのクライアント・インタフェースをプログラム的に操作するには、次の手順を実行します。
ApplicationModule
を、特定のクライアント・インタフェースにキャストします。
インタフェース上のいずれかのメソッドをコールします。
注意:
この項では、説明を簡潔にするために、カスタム・アプリケーション・モジュールのインタフェースの操作のみを重視しますが、これと同じダウンキャスト方法は、ViewObject
インタフェースをCustomers
などのビュー・オブジェクト・インタフェースとして使用するクライアントや、Row
インタフェースをCustomersRow
などのカスタム・ビュー行インタフェースとして使用するクライアントにも有効です。
次の例は、これらの2つの手順を実行するTestClientEntity
クラスを示しています。「static mainメソッドを使用したカスタム・アプリケーション・モジュールのテスト方法」で説明しているように、このクラスのmain()
メソッドを使用して、アプリケーション・モジュール・メソッドをテストすることもできます。ここでは、クライアントからAppModule
クライアント・インタフェースを使用して同じメソッドをすべてコールするために、これを使用します。
注意:
oracle.jbo
パッケージのデフォルトのApplicationModule
インタフェースを使用してアプリケーション・モジュールを操作している場合は、カスタム・メソッドにアクセスできません。この例では、特定のカスタム・インタフェース(AppModule
インタフェースなど)に、アプリケーション・モジュール・インスタンスをキャストします。
次の例の基本ロジックはこれらの手順に従います。
注文1011の合計を取得します。
注文1011の顧客名を取得します。
1011の注文ステータスを「Y」の値に設定します。
顧客名がnullの新しい顧客を作成します。
顧客名を付けて新しい顧客を作成し、新しく割り当てた顧客IDを表示します。
package oracle.summit.model.appmodule.client; import oracle.jbo.client.Configuration; import oracle.jbo.*; import oracle.jbo.domain.Number; import oracle.jbo.domain.*; import oracle.summit.model.appmodule.service.common.AppModule; public class TestClientCustomInterface { public static void main(String[] args) { String amDef = "oracle.summit.model.appmodule.service.AppModule"; String config = "AppModuleLocal"; /* * This is the correct way to use application custom methods * from the client, by using the application module's automatically- * maintained custom service interface. */ AppModule service = (AppModule)Configuration.createRootApplicationModule(amDef,config); String total = service.findOrderTotal(1011); System.out.println("Total for Order # 1011 = " + total); String custName = service.findOrderAndCustomer(1011); System.out.println("Customer for Order # 1011 = " + custName); try { service.updateOrderStatus(1011,"Y"); } catch (JboException ex) { System.out.println("ERROR: "+ex.getMessage()); } long id = 0; try { id = service.createCustomer(null, "Oakville", 14); } catch (JboException ex) { System.out.println("ERROR: "+ex.getMessage()); } id = service.createCustomer("Oakville Curling Club", "Oakville", 14); System.out.println("New customer created successfully with id = " + id); Configuration.releaseRootApplicationModule(service,true); } }
カスタム・アプリケーション・モジュール・クラスを実行すると、前述の例のmain()
メソッドがコールされ、次の出力が生成されます。
Total for Order # 1011 = 99.99 Customer for Order # 1011 = Customer: Zibbers, Location: Boston ERROR: JBO-27014: You must provide a value for Name. New customer created successfully with id = 133
顧客名をnullとしてfindOrderAndCustomer()
をコールしようとした初回の試みでは、Customer
エンティティ・オブジェクトのName
属性に対する組込み必須検証が原因で例外が発生しています。
アプリケーション・モジュールにアクセス中のクライアント・レイヤーはJava EEアーキテクチャの同一層にあるため、アプリケーション・モジュールはローカル・モードと呼ばれるモードでデプロイされます。ローカル・モードでは、クライアント・インタフェースはカスタム・アプリケーション・モジュールのJavaクラスによって直接実装されます。JavaServer FacesアプリケーションのWeb層のアプリケーション・モジュールにアクセスするたびに、ローカル・モードでアプリケーション・モジュールにアクセスします。
oracle.jbo.client
パッケージのConfiguration
クラスでは、テスト用のアプリケーション・モジュール・インスタンスを非常に簡単に入手できます。これにより、JUnit回帰テスト・フィクスチャの一部となるテスト・クライアント・プログラム(「JUnitを使用した回帰テスト」を参照)のように、テスト・クライアント・プログラムの記述が簡単になります。
ベスト・プラクティス:
Fusion Webアプリケーションに対しては、常にバインディング・レイヤーを使用してアプリケーション・モジュールにアクセスする必要があります。開発者はアプリケーション・モジュールにアクセスするあらゆる場合に、このクラスのcreateRootApplicationModule()
メソッドとreleaseApplicationModule()
メソッドを使用しがちですが、ビュー・レイヤーにおける最善の方法はADFモデル・レイヤーの宣言機能を使用することです。
データをバインドするためのADFモデル・レイヤーを使用してFusion Webアプリケーションを操作している場合、JDeveloperにより、ユーザー・インタフェース・プロジェクトにADFBindingFilter
というサーブレット・フィルタが構成されます。このフィルタにより、宣言的なバインディング・メタデータに基づく適切なアプリケーション・モジュール・インスタンスの自動的な取得およびリリースが調整され、ユーザー・インタフェース・プロジェクトのページ定義ファイルで指定された既知のアクション・バインディングまたはイテレータ・バインディングを使用して、サービスをデータ・コントロールとして検索できるようになります。ADFバインディング・コンテナ、データ・コントロール、ページ定義ファイルおよびADFバインディングの詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。ここでは、ADFアクション・バインディングまたはADFイテレータ・バインディングの名前を指定することで、このDCBindingContainer
からアプリケーション・モジュールのクライアント・インタフェースにアクセスできることを覚えておけば十分です。次の例(アクション・バインディングおよびイテレータ・バインディング)に示すように、JSFマネージドBeanのカスタム・クライアント・インタフェースで、バインディング・コンテキストを参照してメソッドをコールできます。
アクション・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、次の基本手順に従います(後に例を示しています)。
ADFバインディング・コンテナにアクセスします。
名前の付いたアクション・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルに提供されている任意のアクション・バインディング名を使用します。)
データ・コントロールをアクション・バインディングから名前で取得します。
アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。
アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。
クライアント・インタフェースにあるいずれかのメソッドをコールします。
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"; } }
イテレータ・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、次の基本手順に従います(後に例を示しています)。
ADFバインディング・コンテナにアクセスします。
名前の付いたイテレータ・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルないの任意のイテレータ・バインディング名を使用します。)
データ・コントロールをイテレータ・バインディングから名前で取得します。
アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。
アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。
クライアント・インタフェースにあるいずれかのメソッドをコールします。
package oracle.summit.model.viewobjects; import oracle.summit.model.appmodule.service.common.SummitAppModule; import oracle.adf.model.binding.DCBindingContainer; import oracle.adf.model.binding.DCDataControl; import oracle.adf.model.binding.DCIteratorBinding; import oracle.jbo.ApplicationModule; public class YourBackingBean { public String commandButton_action() { // Example using an iterator binding to get the data control public String commandButton_action() { // 1. Access the binding container DCBindingContainer bc = (DCBindingContainer)getBindings(); // 2. Find a named iterator binding DCIteratorBinding iter = bc.findIteratorBinding("SomeIteratorBinding"); // 3. Get the data control from the iterator binding DCDataControl dc = iter.getDataControl(); // 4. Access the data control's application module data provider ApplicationModule am = (ApplicationModule)dc.getDataProvider(); // 5. Cast the AM to call methods on the custom client interface SummitAppModule service = (SummitAppModule)am; // 6. Call a method on the client interface service.doSomethingInteresting(); return "SomeNavigationRule"; } }
これらのバッキングBeanの例は、次の例に示すヘルパー・メソッドに依存します。
public BindingContainer getBindings() { { return BindingContext.getCurrent().getCurrentBindingsEntry(); }
ADFアクションに宣言的にバインドされるボタンをオーバーライドしてバッキングBeanクラスを作成すると、このメソッドがクラス内に自動的に生成されます。それ以外の場合は、ヘルパー・メソッドをクラスに手動で追加する必要があります。
アプリケーション・モジュールJavaクラスの組込みADFメソッドをオーバーライドして、ADFアプリケーション・モジュールのデフォルト動作を拡張できます。
ApplicationModuleImpl
ベース・クラスには、この機能を実装する組込みメソッドが多数含まれています。「ADFビジネス・コンポーネントのよく使用されるメソッド」は、カスタム・アプリケーション・モジュール・クラスでよく記述、使用およびオーバーライドする最も一般的なコードのクイック・リファレンスとなっていますが、この項では、これらの組込みフレームワーク・メソッドの1つをオーバーライドしてデフォルトの動作を拡張する基本手順の理解を深めることを重視しています。
アプリケーション・モジュールの組込みフレームワーク・メソッドをオーバーライドするには、「メソッドのオーバーライド」ダイアログを使用して、メイン・メニューからアプリケーション・モジュールのJavaクラスを開きます。
始める前に:
アプリケーション・モジュールのベース・クラスに関する知識があると役立つ場合があります。詳細は、「組込みフレームワーク・メソッドのオーバーライド」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュールのフレームワーク・メソッドをオーバーライドするには:
「メソッドのオーバーライド」ダイアログを閉じると、図13-27に示すように、オーバーライドしたメソッドにカーソルが置かれた状態でソース・エディタに戻ります。メソッドには、super.prepareSession()
をコールする単一行が表示されています。これは、ベース・クラスがこのメソッドに対して通常であれば実行したはずのデフォルトの動作を起動するJava構文です。カスタム・アプリケーション・モジュール・クラスでこの行の前または後にコードを追加して、デフォルトの機能の前または後のデフォルトの動作を拡張できます。
図13-27 オーバーライドしたメソッドに関してソース・エディタのマージンに表示されるフィードバック
「メソッドのオーバーライド」ダイアログを使用してメソッドをオーバーライドする場合、ソース・エディタにより、オーバーライドしたメソッドの直前にJDK @Override
注釈が挿入されます。この注釈により、アプリケーション・モジュール・クラスのメソッドがスーパークラスのメソッドのシグネチャと一致しない場合は、コンパイル時にエラーが生成されます。
クラスにメソッド名を追加してスーパークラス内のメソッドをオーバーライドする場合は注意が必要です。オーバーライドするベース・クラス・メソッドと完全に同一のシグネチャが必要です。@Override
注釈は必ずメソッドの直前に追加してください。これにより、メソッドがスーパークラスのメソッドのいずれのシグネチャとも一致しない場合は、コンパイル時にエラーが生成されます。スーパークラスの実装をコールするかわりにメソッドのコードを記述する場合は、抑止または置換する組込みコードについて理解しておく必要があります。
prepareSession()
メソッドは、新しいユーザー・セッションで初めて使用されるときにアプリケーション・モジュールによって起動されるため、カスタム・アプリケーション・モジュール・クラスをオーバーライドし、アプリケーション・モジュールを使用する新しいユーザーごとに固有のセットアップ・タスクを実行する場合に便利なメソッドです。次の例は、接続されたユーザーのデータベース・クライアント情報を指定するsetApplicationInfo()
ヘルパー・メソッドを起動するAppModuleImpl
クラス内の、オーバーライドされたprepareSession()
メソッドを示しています。
public class AppModuleImpl extends SummitApplicationModuleImpl implements AppModule { ... @Override protected void prepareSession(Session session) { super.prepareSession(session); setApplicationInfo ("AppModuleImpl", "prepareSession"); String username = this.getUserPrincipalName(); System.out.println(username); } protected void setApplicationInfo(String clientInfo, String clientIdentifier){ DBTransactionImpl dbti = (DBTransactionImpl)getDBTransaction(); CallableStatement statement = dbti.createCallableStatement("BEGIN " + "DBMS_APPLICATION_INFO.SET_CLIENT_INFO (client_info => :client_info);" + "DBMS_SESSION.SET_IDENTIFIER (:client_identifier);" + "END;", 0); try { statement.setString("client_info", clientInfo); statement.setString("client_identifier", clientIdentifier); statement.execute(); } catch (SQLException sqlerr) { throw new JboException(sqlerr); } finally { try { if (statement != null) { statement.close(); } } catch (SQLException closeerr) { throw new JboException(closeerr); } } } }
組込みのWebサービス・ウィザードを使用してプロキシ・クラスを作成してメソッドを実装し、そのクラスを使用してWebサービス・メソッドをADFアプリケーション・モジュールでコールします。
サービス指向アーキテクチャでは、アプリケーション・モジュールに基づいていないWebサービスから提供される機能をOracle ADFアプリケーション・モジュールで利用する必要がある場合もあります。Webサービスは、任意のプログラミング言語で実装し、ネットワーク上の任意のサーバーに配置できます。各Webサービスでは、言語に依存しない標準的なXMLフォーマットで記述することにより、一連の該当するメソッドをそのAPI内で指定します。このXMLドキュメント(構文は、Web Services Description Language (WSDL)に準拠)を使用すると、Webサービスのメソッドの名前に加えて、それらのメソッドが予期するパラメータや実際の戻り値のデータ型も、JDeveloperで理解できます。
注意:
アプリケーション・モジュールはWebサービスとして公開し、デプロイ済のFusion Webアプリケーションのモジュール間で使用することもできます。外部サービスを使用したADFビジネス・コンポーネントの再利用の詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。
JDeveloperに組み込まれているWebサービス・ウィザードを使用すると、そのようなタスクを簡単に実行できます。該当するウィザードを使用してWebサービス・プロキシ・クラスを作成し、ローカルなJavaオブジェクトに追加するメソッド・コールを使用してサービスをコールします。
アプリケーション・モジュールからWebサービスをコールするには、起動するサービスのWebサービス・プロキシ・クラスを作成します。Webサービス・プロキシとは、該当するアプリケーション内のWebサービスを表す、生成されたJavaクラスのことです。該当するWebサービスのサービスURLをカプセル化し、サービスをコールをするための低レベルの詳細情報を処理します。
Webサービスを使用するには、該当するWSDLドキュメントを特定するURLを知る必要があります。たとえば、WSDLドキュメントは、電子メールの添付ファイルとして受信し、ローカルのハード・ドライブに保存した場合、URLは次のようになります。
file:///D:/temp/SomeService
.wsdl
また、URLは、次のようなHTTPベースのURLの場合もあります。
http://someserver
.somecompany
.com/SomeService
/SomeService
.wsdl
一部のWebサービスの場合、そのWSDLドキュメントは、サービスURLを変更する特殊なパラメータを使用して利用可能になります。たとえば、http://
someserver.somecompany
.com/
SomeService
のHTTPアドレスでリクエストを受信することが期待されているWebサービスの場合は、同一のURLの末尾に次のような追加のパラメータを付けて、対応するWSDLドキュメントを公開することもあります。
http://someserver
.somecompany
.com/SomeService
?WSDL
標準が確立されていないため、WSDLドキュメントに対する正確なURLを知っておくのみで十分です。URL情報があれば、該当するサービスをコールするためのWebサービス・プロキシ・クラスを作成できます。
ADFビジネス・コンポーネント・サービスには次の形式のサービスへのURLがあります。
統合されたWebLogic Server上でのURLの形式はhttp://host:port/EJB-context-root/@WebService-name?WSDL
で、たとえば、次のようになります。
http://localhost:8888/EJB-SummitService/SummitService?WSDL
Oracle WebLogic Server。URLの形式はhttp://host:port/context-root/@WebService-name?WSDL
で、たとえば、次のようになります。
http://localhost:8888/SummitService/SummitService?WSDL
Webサービス・プロキシ・クラスは、WebサービスのパブリックAPIに対応する一連のJavaメソッドを表します。Webサービス・プロキシ・クラスを使用すると、Webサービス内の任意のメソッドを、他の任意のローカルなJavaクラスのメソッドの場合と同じ方法でコールすることができます。
プロキシ・クラスを使用してアプリケーション・モジュールからWebサービスをコールするには、次の作業を実行します。
WebサービスのWebサービス・プロキシ・クラスを作成します。コールする必要のあるWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・クライアントおよびプロキシの作成ウィザードを使用します。
プロキシ・クラスにメソッドを実装し、目的のWebサービスにアクセスします。
該当するWebサービス・プロキシ・クラスのインスタンスをアプリケーション・モジュール内で作成し、Webサービス・プロキシ・オブジェクト上でメソッドを1つ以上起動します。
コールするWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・プロキシ作成ウィザードを使用します。
始める前に:
Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
サービスにプログラム的にアクセスするためにWebサービス・プロキシ・クラスを作成するには:
Webサービス・プロキシを作成したら、目的のWebサービスにアクセスするためにプロキシ・クラスにメソッドを実装する必要があります。
始める前に:
Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
サービスを起動するためにWebサービス・プロキシ・テンプレートをコールするには:
port_name
Client.java
という名前のプロキシ・クライアント・クラスを開き、メイン・メソッド内にある// Add your own code to call the desired methods
というコメントを検索します。Webサービス・プロキシ・クラスが生成されると、次の例に示すように、アプリケーション・モジュールのカスタム・メソッド内で使用できます。該当メソッドによりWebサービス・プロキシ・クラスのインスタンスが作成され、その結果についてWebサービス・プロキシ・クラスからWebサービス・メソッドがコールされます。
// In YourModuleImpl
.java
public void performSomeApplicationTask(String symbol) throws Exception {
// application-specific code here
:
// Create an instance of the web service proxy class
StockQuoteServiceSoapHttpPortClient svc =
new StockQuoteServiceSoapHttpPortClient();
// Call a method on the web service proxy class and get the result
QuoteInfo quote = svc.quoteForSymbol(symbol);
float currentPrice = quote.getPrice();
// more application-specific code here
}
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サービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。
Webサービス接続の作成方法:
警告:
既存の接続と同じ名前で新しいWebサービス接続を作成すると、既存の接続が新しい情報によって上書きされます。
新しい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
ブロックを使用してコールをラップすることにより、リクエストの失敗に備える必要があります。次の例では、Webサービス例外を検出することにより、前述(「アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール」)の簡単な例を改善しています。この場合は該当するエラーをJboException
として再スローしているだけですが、アプリケーションではさらに適切なエラー処理を実装することもできます。
// In YourModuleImpl.java public void performSomeApplicationTask(String symbol) { // application-specific code here // : QuoteInfo quote = null; try { // Create an instance of the web service proxy class StockQuoteServiceSoapHttpPortClient svc = new StockQuoteServiceSoapHttpPortClient(); // Call a method on the web service proxy class and get the result quote = svc.quoteForSymbol(symbol); } catch (Exception ex) { throw new JboException(ex); } float currentPrice = quote.getPrice(); // more application-specific code here }
参照情報にアクセスするために使用するWebサービスもあります。また、データを変更するためにコールするサービスもあります。このデータ変更は、社内の自分のチームまたは別のチームのメンバーによってサービスが記述された場合、自社のデータベースに存在する可能性があります。Webサービスが自社のファイアウォールの外部にある場合は、変更対象のデータベースは、当然、別の会社によって管理されます。
いずれの場合でも、起動するWebサービスによって実行されるデータ変更は、アプリケーション・モジュールの現在の作業ユニットとは無関係な独自のトランザクションによって実行されるということを理解しておくことが重要です。たとえば、データを変更するWebサービスを起動した後、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サービスベースのアプリケーション・モジュールを起動すると、コール側コンポーネントとコールしているサービスがコロケートしている場合にコールを最適化できなくなります。別の方法として、「アプリケーション・モジュールによるSOAP Webサービスの作成」で説明しているサービス・インタフェースによるアプローチを使用することもできます。