| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
|
前 |
次 |
この章の内容は次のとおりです。
複数のセッションからの複数のリクエストで単一のアプリケーション・モジュールを共有できるようにする共有ADFビジネス・コンポーネント・アプリケーション・モジュールを作成できます。これにより、データ・キャッシュの再移入による不要なオーバーヘッドを防止できます。
Webアプリケーションでは、セッション全体で必要とされる、あまり頻繁に変更されないデータがよく使用されます。この種の統計データの例は、アプリケーション・ユーザー・インタフェースの検索リストに表示されることがあります。アプリケーションが静的データにアクセスするたびに、すべてのリクエストにおける各アプリケーション・セッションのデータベースから静的データ・キャッシュが再移入されると、不要なオーバーヘッドが発生する場合があります。ADFビジネス・コンポーネントで作業を行う場合にパフォーマンスを最適化するためには、一般的にセッションおよびリクエスト間で再使用する共有静的データをキャッシュします。共有アプリケーション・モジュールの作成によって、複数のセッションのリクエストで、Webサーバー仮想マシン用のアプリケーション・プールで永続的に管理できる、単一のアプリケーション・モジュール・インスタンスを共有できます。
ADFビジネス・コンポーネントのビュー・アクセッサは、エンティティ・オブジェクト属性(またはビュー・オブジェクト)から、同じアプリケーション・ワークスペースのリンク先ビュー・オブジェクトまたは共有ビュー・インスタンスをポイントする、値のアクセッサ・オブジェクトです。
異なるアプリケーション・モジュールのビュー・オブジェクトにアクセスするこの機能により、ビュー・アクセッサは次の場合に特に便利です。
エンティティ・オブジェクトの属性に設定する検証規則。たとえば、エンド・ユーザーが登録フォームに記入する場合、個々の検証規則により肩書、配偶者の有無、連絡先コードを、共有アプリケーション・モジュールのビュー・インスタンスにより問合せされた参照表データに対して検証できます。
ビュー・オブジェクトの属性に対して有効にする値リスト(LOV)。たとえば、実行時にエンド・ユーザーに値リストを表示する場合です。
共有アプリケーション・モジュールを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。
実行時のパフォーマンスを向上させるためのアプリケーション・モジュール・インスタンス構成の詳細は、「Fusion Webアプリケーションでの状態管理の使用」および「アプリケーション・モジュール・プールのチューニング」を参照してください。
カスタム・アプリケーション・モジュール・クラスでよく記述、使用またはオーバーライドするコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。
oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。
Oracle ADFモデルJava APIリファレンス
JDeveloperでは、アプリケーション・レベルまたはセッション・レベルのADFアプリケーション・モジュール・データ・モデルの共有を指定できます。
共有データ・キャッシュの宣言型サポートは、JDeveloperの「プロジェクト・プロパティ」ダイアログで提供されています。共有アプリケーション・モジュールの作成によって、複数のセッションのリクエストで、Webサーバー仮想マシン用のアプリケーション・プールで永続的に管理できる、単一のアプリケーション・モジュール・インスタンスを共有できます。
ベスト・プラクティス:
アプリケーション全体で静的データのリストを再利用する場合は、共有アプリケーション・モジュールを使用してビュー・インスタンスをグループ化します。共有アプリケーション・モジュールは、すべてのユーザー・セッションでデータにアクセスできるように構成したり、シングル・ユーザー・セッションのUIコンポーネントのみにアクセスを制限するように構成できます。たとえば、共有アプリケーション・モジュールを使用して、国リストなどの参照データにアクセスするビュー・インスタンスをグループ化できます。共有アプリケーション・モジュールを使用すると、すべての共有リソースを1か所で管理できるため、この目的でのスコープのマネージドBeanが不要になります。
図14-1で示すように、「プロジェクト・プロパティ」ダイアログにより、アプリケーションレベルまたはセッションレベルでのアプリケーション・モジュールのデータ・モデルの共有を指定できます。アプリケーションレベルの共有では、任意のHTTPユーザー・セッションが共有アプリケーション・モジュールに含まれた同一のビュー・インスタンスにアクセスできます。一方、セッションレベルの共有アプリケーション・モジュールは、単一のHTTPユーザー・セッションで使用されるアプリケーション・セッション(SessionImpl)に拡張され、単一のルート・アプリケーション・モジュールに適用されます。この場合、特定のHTTPユーザー・セッションで使用する個別のルート・アプリケーション・モジュールは、セッションの有効範囲の共有アプリケーション・モジュールの独自の個別インスタンスを取得します。つまり、同一のHTTPセッションが使用している個別のルート・アプリケーションはセッションの有効範囲の共有アプリケーション・モジュール内のデータを共有しません。
図14-1 共有アプリケーション・モジュール・インスタンスを定義する「プロジェクト・プロパティ」ダイアログ
共有するアプリケーション・モジュールのデータ・モデルを作成する場合、キャッシュされた行セットのデータは、アプリケーションレベルまたはセッションレベルで変更する必要はありません。たとえば、アプリケーションレベルの共有アプリケーション・モジュールでは、ビュー・インスタンスは状態コードや通貨タイプなど静的データのみを問い合せます。ビュー・オブジェクト・インスタンスが現在のユーザーに依存するデータを問い合せると、問合せはセッションレベルでキャッシュされ、行セット・キャッシュを参照するすべてのコンポーネントにより共有できます。たとえば、セッションレベルの共有アプリケーション・モジュールには、直下のレポートのリストを返すため、現在のユーザーとしてマネージャが必要なデータ・セキュリティを備えたビュー・インスタンスが含まれる場合があります。この場合、直下のレポートのキャッシュは、マネージャのHTTPユーザー・セッションの期間中存在します。HTTPユーザー・セッションにプール内の再利用アプリケーション・モジュールを割り当てた場合に、ADFビジネス・コンポーネント・アプリケーション・モジュール・プールは、セッションの有効範囲のアプリケーション・モジュールを再度作成します。これによってHTTPセッションが同じルート・アプリケーション・モジュール・インスタンスを使用可能であるかぎり、セッションの有効範囲のアプリケーション・モジュール期間がHTTPセッションに結び付けられます。セッションレベルの共有アプリケーション・モジュールの直下のレポートのキャッシュは、異なるルート・アプリケーション・モジュールをまたがってアクセスできない点に注意してください。
共有アプリケーション・モジュール・インスタンスを作成するには、「プロジェクト・プロパティ」ダイアログを使用します。アプリケーションの読取り専用データを保持する個別の独立したルート・アプリケーション・モジュールの論理名を定義します。
始める前に:
参照データに関する知識が役立つ場合があります。詳細は、「ベース・ビュー・オブジェクトを参照表で使用するための定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
共有アプリケーション・モジュール・インスタンスを作成するには:
アプリケーション・モジュールを作成すると、JDeveloperによりAppModuleNameShared構成が自動的に作成されます。bc4j.xcfgファイル内のこの構成の存在により、JDeveloperにアプリケーション・モジュールが共有の候補であることが通知され、「プロジェクト・プロパティ」ダイアログの「アプリケーション・モジュールの慣用名」ページの「使用可能なアプリケーション・モジュール」リストにアプリケーション・モジュールを表示させることができます。
AppModuleNameShared構成により、アプリケーション・モジュールのこれらのプロパティが共有を有効にして、実行時の共有リソースの効率的な使用を維持するように設定されます。
jbo.ampool.isuseexclusiveがfalseに設定され、複数のセッションからのリクエストがアプリケーション・モジュールの単一インスタンスを共有できるようになります。これはWebサーバーの仮想マシンのライフタイムを通して、アプリケーション・プールが管理します。アプリケーション・モジュールの共有を有効化しない場合は、JDeveloperが値trueを設定して、リクエストごとに各アプリケーション・セッションのデータベースからデータ・キャッシュを再度取り込みます。
jbo.ampool.maxpoolsizeは1 (1)に設定され、ADFビジネス・コンポーネント・アプリケーション・モジュール・プールについて単一のアプリケーション・モジュール・インスタンスのみが作成されるように指定します。この設定により共有アプリケーション・モジュール・リソースが効率的に使用され、共有アプリケーション・モジュールの不要な複数インスタンスが実行時に作成されることを回避できます。
概要エディタでアプリケーション・モジュールを開き、ナビゲーション・メニューから「構成」を選択すると、共有アプリケーション・モジュールの構成を表示できます。JDeveloperでは、bc4j.xcfgファイルは、アプリケーション・モジュールのXMLドキュメントを相対位置とする./commonサブディレクトリに保存されます。構成を削除したり、jbo.ampool実行時プロパティの値(isuseexclusive, maxpoolsize)を変更すると、アプリケーション・モジュールは共有アプリケーション・モジュール・インスタンスとして使用できなくなります。
たとえば、SummitADFアプリケーション・ワークスペースの./src/oracle/summit/model/services/commonディレクトリの中にあるbc4j.xcfgファイルを見ると、次の例のように、そのBackOfficeAppModuleアプリケーション・モジュール用に名前の付いた構成が2つあることがわかります。特に、BackOfficeAppModuleShared構成によりjbo.ampool実行時プロパティが共有アプリケーション・モジュール・インスタンスに設定されます。ADFビジネス・コンポーネント・アプリケーション・モジュール・プールおよびアプリケーション・モジュールのランタイム構成の詳細は、「アプリケーション・モジュール・プールのチューニング」を参照してください。
<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
...
<AppModuleConfigBag
ApplicationName="oracle.summit.model.services.BackOfficeAppModule">
<AppModuleConfig
name="BackOfficeAppModuleLocal"
jbo.project="oracle.summit.model.Model"
ApplicationName="oracle.summit.model.services.BackOfficeAppModule"
DeployPlatform="LOCAL" JDBCName="summit_adf">
<Database jbo.TypeMapEntries="Java"/>
<Security
AppModuleJndiName="oracle.summit.model.services.BackOfficeAppModule"/>
</AppModuleConfig>
<AppModuleConfig
name="BackOfficeAppModuleShared"
jbo.project="oracle.summit.model.Model"
ApplicationName="oracle.summit.model.services.BackOfficeAppModule"
DeployPlatform="LOCAL" JDBCName="summit_adf">
<AM-Pooling jbo.ampool.maxpoolsize="1"
jbo.ampool.isuseexclusive="false"/>
<Database jbo.TypeMapEntries="Java"/>
<Security
AppModuleJndiName="oracle.summit.model.services.BackOfficeAppModule"/>
</AppModuleConfig>
</AppModuleConfigBag>
</BC4JConfig>
共有アプリケーション・モジュールは同じアプリケーション・ワークスペースの任意のデータ・モデル・プロジェクト(ADFビジネス・コンポーネント・ベースのもの)からアクセスできるため、ADFビジネス・コンポーネント・プロジェクト構成ファイル(.jpx)にある共有アプリケーション・モジュールのスコープがJDeveloperによって保持されます。このファイルは、プロジェクトのsrcディレクトリに保存されています。たとえば、アプリケーションのModelプロジェクトの./srcディレクトリの中にあるModel.jpxファイルを見ると、次の例に示すように、SharedLookupServiceアプリケーション・モジュールの慣用名定義でアプリケーション・レベル共有に従ってSharedScope = 2を指定していることがわかります。セッションレベルの共有に設定するアプリケーション・モジュールは、SharedScope = 1を表示します。
<JboProject
xmlns="http://xmlns.oracle.com/bc4j"
Name="Model"
SeparateXMLFiles="true"
PackageName="oracle.summit.model">
. . .
<AppModuleUsage
Name="SharedLookupService"
FullName="oracle.summit.model.services.BackOfficeAppModule"
ConfigurationName="oracle.summit.model.services.BackOfficeAppModuleShared"
SharedScope="2"/>
</JboProject>
「プロジェクト・プロパティ」ダイアログで共有アプリケーション・モジュールを定義すると、そのアプリケーション・モジュールのデータ・モデルは、同じアプリケーション・ワークスペースに属する他のデータ・モデル・プロジェクトでのみ使用できます。アプリケーション・ワークスペースの範囲を超えてデータ・モデルを使用可能にする場合、「アプリケーション・コンポーネントの再利用」で説明するようにデータ・モデルをADFライブラリとして公開できます。
「構造」ウィンドウで、DataBindings.cpxファイルからデータ・コントロールの使用方法を表示する場合は、「構成」プロパティを共有アプリケーション・モジュール構成に設定しないでください。AppModuleNameという名前のアプリケーション・モジュールの場合、「プロパティ」ウィンドウには、デフォルトでAppModuleNameSharedおよびAppModuleNameLocalという名前の構成が表示されます。Oracle Application Development Framework (Oracle ADF)では、アプリケーションを共有アプリケーション・モジュールとして構成すると、実行時に共有構成が自動的に使用されますが、アプリケーション・モジュールのデータ・コントロールで使用されるように設計されていません。データ・コントロールの使用方法の詳細は、「DataBindings.cpxファイルでの作業」を参照してください。
データ・モデル・プロジェクトのビジネス・コンポーネント定義で、共有アプリケーション・モジュールのビュー・インスタンスへのアクセスを許可するビュー・アクセッサを定義します。このビュー・アクセッサにより、1つのデータ・モデル・プロジェクトのエンティティ・オブジェクトまたはビュー・オブジェクト定義から共有アプリケーション・モジュールのビュー・オブジェクト定義またはビュー・インスタンスをポイントできます。この目的でのビュー・アクセッサ作成の詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。
ADFビジネス・コンポーネントにおけるアプリケーション・モジュール・プールと同様に、共有問合せコレクションは問合せコレクション・プールに格納されています。問合せコレクション・プールを管理するために、ADFビジネス・コンポーネントのフレームワークは、最大アイドル時間の設定に基づき、問合せコレクションを削除します。この動作によってキャッシュの拡大を制限し、使用頻度の低い問合せコレクションがメモリー領域を占有しないようにします。
アプリケーション・モジュールと接続プールと同様に、問合せコレクション・プール・モニターは、ユーザーが指定したスリープ間隔後にウェイクアップし、クリーンアップ操作を開始します。最大アイドル時間(最後に使用してからの時間の長さ)を超えた問合せコレクションは、プールから削除されます。
共有問合せコレクションの最大アイドル時間(デフォルトは900000 ms/15分) と、そのプール・モニターのスリープ時間(デフォルトは1800000 ms/30分)のデフォルト値を変更できます。アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタを使用して、選択したAppModuleNameShared構成にこれらの値を設定できます。
アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、共有構成のハイパーリンクをクリックします。アプリケーション・モジュール構成の概要エディタで「プロパティ」タブを選択し、「プロパティの追加」をクリックして「プロパティの追加」ダイアログから次のプロパティを選択し、「OK」をクリックします。
jbo.qcpool.monitorsleepinterval
jbo.qcpool.maxinactiveage
次に、「プロパティ」リストで、設定するアイドル時間とスリープ時間をミリ秒単位で入力します。
jbo.qcpool.monitorsleepinterval 1回のプール・チェックから次のプール・チェックまでの間に接続プール・モニターがスリープする時間(ms)。
jbo.qcpool.maxinactiveage 接続をプールから削除する前に非アクティブのまま保持する最大時間(ms)。
すべてのアプリケーション・モジュールの接続動作として、ルート・アプリケーション・モジュールごとに独自のデータベース接続を許可します。アプリケーションで複数の共有アプリケーション・モジュールを定義する場合、単一のデータベース接続を使用するために、それらを同じトランザクション下にネストするようアプリケーションを構成できます。この最適化により、共有アプリケーション・モジュールのインスタンスで同じ接続を共有できるようになり、アプリケーションで使用するデータベース・リソースを削減できます。これは読取り専用でトランザクション・アプリケーション・モジュールよりも長く存在する共有アプリケーション・モジュールの場合は特に有効です。
ベスト・プラクティス:
共有アプリケーション・モジュールを単一のトランザクション下にネストして、アプリケーションで必要とされるデータベース・リソースを減らすことをお薦めします。アプリケーションが定義する各共有アプリケーション・モジュール構成に対して同じトランザクション名(ユーザーが指定する任意の識別子)を使用するようjbo.shared.txnプロパティを設定することにより、この共有アプリケーション・モジュールの最適化を実行できます。
アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタを使用して、jbo.shared.txnプロパティを設定します。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウで共有アプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。アプリケーション・モジュール構成の概要エディタで「プロパティ」タブを選択し、「プロパティの追加」をクリックして「プロパティの追加」ダイアログから次のプロパティを選択し、「OK」をクリックします。
jbo.shared.txn
次に、「プロパティ」リストで、プロパティのトランザクション名を入力します(SharedAMOptimizationは任意の名前)。
jbo.shared.txn = SharedAMOptimization
アプリケーションが定義する各共有アプリケーション・モジュール構成に対して同じトランザクション名を使用して、jbo.shared.txnプロパティの設定を繰り返します。
現在、アプリケーション・モジュールの構成パラメータであるjbo.doconnectionpooling=trueは、共有アプリケーション・モジュールではサポートされていません。この機能はJDBC接続オブジェクトをデータベース接続プールに解放することが望ましい場合に、非共有アプリケーション・モジュールを構成するために提供されています。
共有アクセス状態の管理によって発生するパフォーマンス低下を防止するために、共有アプリケーションではこの機能は意図的にサポートしていません。かわりに、デフォルトでjbo.doconnectionpooling=falseを使用することをお薦めします。
デフォルト接続プーリング構成により、アプリケーション・モジュール・プールからアプリケーション・モジュール・インスタンスが削除されるまで、各共有アプリケーション・モジュール・インスタンスはプールから取得したJDBC接続オブジェクトを必ず維持します。jbo.doconnectionpoolingパラメータおよび接続プールの動作の詳細は、「デプロイメント環境のシナリオとプーリング」を参照してください。
ADFアプリケーション・モジュールを使用して、データベース参照表で定義された静的データにアクセスします。ADFビジネス・コンポーネントの共有アプリケーション・モジュールでは、このような参照表にアクセスして静的データを表示します。
アプリケーションで静的データを表示する必要がある場合は、参照表にアクセスする可能性が高いビュー・インスタンスで共有アプリケーション・モジュールを定義できます。参照表は、アプリケーションにより参照されるデータの静的な変換リストです。参照表のデータは、様々な方法でデータベースに配置できます。関連する検索データを個別の表に格納できる一方、単一の表内にアプリケーションの参照情報をすべて結合すると便利です。たとえば、ORDERS_LOOKUPS表向けに作成された列LOOKUP_TYPEは、値である「はい」および「いいえ」のFWK_TBX_YES_NO、国名のFWK_TBX_COUNTRY、国の通貨の名前を表すFWK_TBK_CURRENCYという様々なコードを含む1つの表を分割する役割を果します。
データベース・スキーマにより単一のデータベース表の検索データが配置される場合、一連のデータごとに個別の問合せを作成することを避ける必要があります。かわりに、概要エディタを使用して、定義したビュー・オブジェクト属性に参照表の目的の列をマップする単一のベース・ビュー・オブジェクトを定義します。問合せ文ではLOOKUP_TYPE列の値のみ変更する必要があるため、ビュー・オブジェクト定義にビュー基準を追加して、LOOKUP_TYPE値を設定するWHERE句を指定できます。これにより、単一のビュー・オブジェクト定義の参照表データへのアクセスがカプセル化され、LOOKUP_TYPE値が変更された場合やアプリケーションで追加の参照タイプを問い合せる必要がある場合にメンテナンスが簡単になります。
参照表の列を問い合せるベース・ビュー・オブジェクトは、データの更新処理の必要がないため、またはエンティティ・ベースのビュー・オブジェクトで提供される利点が不要なため、読取り専用ビュー・オブジェクトとなります。(これらの利点の詳細は、「ビュー・オブジェクトについて」を参照。)
注意:
参照表にアクセスするために作成する読取り専用ビュー・オブジェクトは、共有アプリケーション・モジュールに組み込むには理想的ですが、共有アプリケーション・モジュール・インスタンスでビュー・オブジェクトを共有する場合は、共有アプリケーション・モジュールと同じパッケージにビュー・オブジェクトを作成する必要があります。
読取り専用ビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能な「ビュー・オブジェクトの作成」ウィザードを使用します。
始める前に:
参照データに関する知識が役立つ場合があります。詳細は、「ベース・ビュー・オブジェクトを参照表で使用するための定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
参照表のベース・ビュー・オブジェクトを作成するには:
参照表の列の問合せ名は、図14-2に示すSQL文のようになります。この文では、LOOKUP_CODES表のLOOKUP_CODE列、MEANING列およびDESCRIPTION列を問い合せます。
読取り専用のビュー・オブジェクトはエンティティ・オブジェクトには基づいていないため、「ビュー・オブジェクトの作成」ウィザードはデフォルトではキー属性を定義しません。キー属性を定義しなかった場合、読取り専用ビュー・オブジェクト・コレクションに基づくデータを持つADF Facesコンポーネントが、実行時に予期しない動作をすることがあります。読取り専用ビュー・オブジェクトの場合は、図14-3に示すように、キー属性を定義します。
図14-3 「ビュー・オブジェクトの作成」ウィザードの「属性の設定」ページ
参照表のビュー・オブジェクト定義を作成する際、JDeveloperでは最初にSELECTリストの列から次を推測する問合せが記述されます。
Javaに適したビュー属性名(LOOKUP_TYPEのかわりにLookupTypeなど)
デフォルトでは、ウィザードによってSELECTリスト列名に対応するJavaに適したビュー・オブジェクト属性名が作成されます。
各属性のSQLおよびJavaデータ型
次に、JDeveloperでビュー・オブジェクトの宣言設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリ内に格納されます。たとえば、lookupsパッケージのLookupsBaseVOという名前のビュー・オブジェクトに対して作成されたXMLファイルは、プロジェクトのソース・パスの./lookups/LookupsBaseVO.xmlになります。
ビュー・オブジェクト設定を表示するには、「アプリケーション」ウィンドウで目的のビュー・オブジェクトを開き、開いたビュー・オブジェクトのXMLファイルを選択して、「構造」ウィンドウを開きます。「構造」ウィンドウは、SQL問合せや各属性のプロパティなど定義のリストを表示します。エディタでファイルを開くには、対応する.xmlノードをダブルクリックします。次の例に示すように、LookupsBaseVO.xmlファイルでは、マップされた各列に<SQLQuery>定義および<ViewAttribute>定義を1つずつ定義します。問合せ結果をフィルタするビュー基準がないと、ビュー・オブジェクト問合せによりLOOKUP_CODE、LOOKUP_MEANINGおよびLOOKUP_DESCRIPTIONが返され、それぞれValue、Name、Descriptionのビュー・インスタンス属性値にマップされます。ベース・ビュー・オブジェクト・コレクションがADF Facesコンポーネントにバインドされている場合に適切な行セットのナビゲーションを行うように、キー属性を定義します。
<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="LookupsBaseVO"
BindingStyle="OracleName"
CustomQuery="true"
PageIterMode="Full"
UseGlueCode="false"
FetchMode="FETCH_AS_NEEDED"
FetchSize="500">
<SQLQuery>
<![CDATA[SELECT L.LOOKUP_TYPE
,L.LOOKUP_CODE
,L.MEANING
,L.DESCRIPTION
FROM LOOKUP_CODES L
WHERE L.LANGUAGE = USERENV('CLIENT_INFO')
ORDER BY L.MEANING]]>
</SQLQuery>
<DesignTime>
<Attr Name="_codeGenFlag2" Value="Access|VarAccess"/>
<Attr Name="_isExpertMode" Value="true"/>
</DesignTime>
<ViewAttribute
Name="Type"
IsUpdateable="false"
IsPersistent="false"
IsNotNull="true"
PrecisionRule="true"
Precision="255"
Type="java.lang.String"
ColumnType="VARCHAR2"
AliasName="LOOKUP_TYPE"
Expression="LOOKUP_TYPE"
SQLType="VARCHAR">
<DesignTime>
<Attr Name="_DisplaySize" Value="30"/>
</DesignTime>
...
</ViewAttribute>
<ViewAttribute
Name="Value"
IsUpdateable="false"
IsPersistent="false"
IsNotNull="true"
PrecisionRule="true"
Precision="30"
Type="java.lang.String"
ColumnType="VARCHAR2"
AliasName="LOOKUP_CODE"
Expression="LOOKUP_CODE"
SQLType="VARCHAR">
<DesignTime>
<Attr Name="_DisplaySize" Value="30"/>
</DesignTime>
...
</ViewAttribute>
<ViewAttribute
Name="Name"
IsUpdateable="false"
IsPersistent="false"
IsNotNull="true"
PrecisionRule="true"
Precision="80"
Type="java.lang.String"
ColumnType="VARCHAR2"
AliasName="MEANING"
Expression="MEANING"
SQLType="VARCHAR">
<DesignTime>
<Attr Name="_DisplaySize" Value="80"/>
</DesignTime>
...
</ViewAttribute>
<ViewAttribute
Name="Description"
IsUpdateable="false"
IsPersistent="false"
PrecisionRule="true"
Precision="240"
Type="java.lang.String"
ColumnType="VARCHAR2"
AliasName="DESCRIPTION"
Passivate="true"
Expression="DESCRIPTION"
SQLType="VARCHAR">
<DesignTime>
<Attr Name="_DisplaySize" Value="240"/>
</DesignTime>
...
</ViewAttribute>
<AttrArray Name="KeyAttributes">
<Item Value="Type"/>
<Item Value="Value"/>
</AttrArray>
. . .
</ViewObject>
ビュー・オブジェクト結果をフィルタする必要がある場合、名前付きビュー基準定義をデータ・モデル・プロジェクトに作成します。設計時に定義するビュー基準は、データのフィルタリングが必要となるUIシナリオで使用されます。
「ビュー基準の編集」ダイアログを使用して、参照表の問合せ用に定義した検索ベース・ビュー・オブジェクトのビュー基準定義を作成します。このエディタでは、ターゲット・ビュー・オブジェクトの対応するSQL列名のかわりに属性名を使用してWHERE句を作成できます。得られた結果の定義は、次のとおりです。
検索ビュー・オブジェクトのType属性を定義する単一のビュー基準項目のある1つのビュー基準グループで構成される、1つのビュー基準行。
ビュー基準項目は、Type属性名、Equal演算子、および問合せ結果をフィルタするLOOKUP_TYPEの値で構成されます。
単一のビュー基準が定義されているため、WHERE句条件をカッコで囲む論理積は必要ありません。
始める前に:
参照データに関する知識が役立つ場合があります。詳細は、「ベース・ビュー・オブジェクトを参照表で使用するための定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
また、ビュー基準に関する知識が役立つ場合があります。詳細は、「名前付きビュー基準の処理」を参照してください。
次のタスクを完了する必要があります。
検索ビュー・オブジェクトのLOOKUP_TYPEビュー基準を作成するには:
JDeveloperの 「ビュー基準の作成」ダイアログで、ビュー基準を簡単に作成し、名前付き定義として保存できます。これらの名前付きビュー基準定義により、メタデータがターゲット・ビュー・オブジェクト独自の定義に追加されます。定義すると、名前付きビュー基準はビュー・オブジェクトの概要エディタの「ビュー基準」ページに名前で表示されます。
次に、JDeveloperでビュー・オブジェクトの宣言設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリ内に格納されます。たとえば、lookupsパッケージのLookupsBaseVOという名前のビュー・オブジェクトに対して作成されたXMLファイルは、プロジェクトのソース・パスの./lookups/LookupsBaseVO.xmlになります。
ビュー基準を表示するには、「アプリケーション」ウィンドウで目的のビュー・オブジェクトを開き、開いたビュー・オブジェクトのXMLファイルを選択して、「構造」ウィンドウを開きます。次の例に示すように、LookupsBaseVO.xmlファイルでは、LookupsBaseVOに配偶者の有無のタイプのみ戻す<ViewCriteria>定義を指定します。簡潔にするため、この例ではLookupsBaseVOに追加された他のビュー基準は省略されています。
<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="LookupsBaseVO"
BindingStyle="OracleName"
CustomQuery="true"
PageIterMode="Full"
UseGlueCode="false">
<SQLQuery>
<![CDATA[SELECT L.LOOKUP_TYPE
,L.LOOKUP_CODE
,L.MEANING
,L.DESCRIPTION
FROM LOOKUP_CODES L
WHERE L.LANGUAGE = SYS_CONTEXT('USERENV','LANG')
ORDER BY L.MEANING]]>
</SQLQuery>
...
<ViewCriteria
Name="listMaritalStatusTypes"
ViewObjectName="oracle.summit.model.lookups.LookupsBaseVO"
Conjunction="AND"
Mode="3"
<Properties>
<CustomProperties>
<Property
Name="autoExecute"
Value="false"/>
<Property
Name="showInList"
Value="true"/>
<Property
Name="mode"
Value="Basic"/>
</CustomProperties>
</Properties>
<ViewCriteriaRow
Name="vcrow24">
<ViewCriteriaItem
Name="Type"
ViewAttribute="Type"
Operator="="
Conjunction="AND"
Value="MARITAL_STATUS_CODE"
Required="Optional"/>
</ViewCriteriaRow>
</ViewCriteria>
ADFビジネス・コンポーネントのビュー・アクセサを使用して共有アプリケーション・モジュール全体のビュー・インスタンスにアクセスします。検証ルールまたはLOVを設定し、ビュー・アクセサを使用して共有ビュー・インスタンスにアクセスできます。
ADFビジネス・コンポーネントのビュー・アクセッサは、エンティティ・オブジェクト属性(またはビュー・オブジェクト)から、同じアプリケーション・ワークスペースのリンク先ビュー・オブジェクトまたは共有ビュー・インスタンスをポイントする、値のアクセッサ・オブジェクトです。ビュー・アクセッサにより、デフォルトですべての行を含む行セットがリンク先ビュー・オブジェクから戻されます。ビュー・アクセッサにビュー基準を適用することにより、必要に応じてこの行をフィルタできます。ビュー・アクセッサおよびリンク先ビュー・オブジェクトを作成する場合のベース・エンティティ・オブジェクトまたはビュー・オブジェクトは、同じプロジェクトまたはアプリケーション・モジュールにある必要はありませんが、同じアプリケーション・ワークスペースにある必要があります。
ビュー・アクセッサはアプリケーション・モジュール全体に到達し、問合せデータにアクセスできる柔軟性を備えているため、共有アプリケーション・モジュールのビュー・インスタンスへのアクセスに理想的です。共有アプリケーション・モジュールでビュー・インスタンスのデータ・モデルを作成する方法の詳細は、「共有アプリケーション・モジュール・インスタンスの作成方法」を参照してください。
異なるアプリケーション・モジュールのビュー・オブジェクトにアクセスするこの機能により、ビュー・アクセッサは次の場合に特に便利です。
エンティティ・オブジェクトの属性に設定する検証規則。この場合、ビュー・アクセッサにより共有アプリケーション・モジュールのビュー・インスタンス属性に対応する検索データから検証規則の値が導出されます。
ビュー・オブジェクトの属性に対して有効にする値リスト(LOV)。この場合、ビュー・アクセッサにより共有アプリケーション・モジュールのビュー・インスタンス属性に対応する検索データから値リストが導出されます。
アクセッサによる検証規則は、ユーザーに対するUIに値リストを表示させない場合に便利ですが、有効値のリストは制限する必要があります。ビュー・オブジェクト属性のLOVを定義して、ユーザー・インタフェースでのリスト・コントロールを使用した作業を簡略化することもできます。ビジネス・コンポーネントの個々の属性にLOVを定義するため、属性に対してLOV使用をカスタマイズすると、属性が表示されるフォームでリスト・コントロールを参照できます。
ビュー・アクセッサは、アプリケーション・モードに依存せずにデータ・ソースにアクセスする手段を提供します。ビュー・アクセッサは、エンティティ・オブジェクト・レベルまたは個々のビュー・オブジェクト・レベルで定義できます。ただし、実行時にはビュー・アクセッサの結果は関連する用途に基づいてフィルタ処理されることが多いため、アプリケーション内の各用途ごとに一意のビュー・アクセッサを作成することをお薦めします。
ベスト・プラクティス:
アプリケーションでLOVが有効な属性を公開する必要がある場合は、一意のビュー・アクセッサを作成することをお薦めします。LOV結果は実行時にフィルタされることが多いため、複数の値リストを作成するためにビュー・アクセッサを再利用することはお薦めしません。たとえば、エンド・ユーザーが検索基準の適用を解除するまで、保存済の検索の結果により、ターゲット・ビュー・オブジェクトの行セットがフィルタされ続けます。したがって、この同じリンク先ビュー・オブジェクトに適用されるビュー・アクセッサの結果もフィルタされます。ビュー・アクセッサが実行時に常に意図された行セットを返すようにするには、使用するたびに一意のビュー・アクセッサを作成します。
エンティティ・オブジェクトに基づいて作成するビュー・オブジェクトはベース・エンティティ・オブジェクトのビュー・アクセッサを継承するため、エンティティ・オブジェクトに基づいてビュー・アクセッサを定義する際には注意が必要です。エンティティ・オブジェクト自体に基づいてビュー・アクセッサを一度定義する場合には同じビュー・アクセッサを再利用できますが、そのビュー・アクセッサを別のアプリケーション・シナリオで使用しないでください。エンティティ・オブジェクト属性に対する検証規則を定義し、そのエンティティ・オブジェクトのビュー・オブジェクトに対してLOV有効属性を作成する場合は、別々のビュー・アクセッサを作成することをお薦めします。
たとえば、AddressEOエンティティ・オブジェクトは、Shared_CountriesVAビュー・アクセッサを定義し、AddressesVOビュー・オブジェクトはこのビュー・アクセッサを継承するとします。この場合、エンティティ・オブジェクトに基づいてビュー・アクセッサを定義することは有用です。AddressEOに対するアクセッサはCountryId属性に対する検証規則を定義します。ただし、そのCountryId属性に対してLOVを有効にするには、AddressesVOに対する別のビュー・アクセッサを使用する必要があります。
共有アプリケーション・モジュールからビュー・インスタンスにアクセスするビュー・アクセッサを作成する場合は、ビュー・アクセッサの名前にShared_などの接頭辞を使用してください。エンティティ・オブジェクトまたはビュー・オブジェクトにビュー・アクセッサを選択する必要がある場合、この命名規則を使用すると、ビュー・アクセッサの識別が容易になります。
始める前に:
ビュー・アクセッサに関する知識が役立つ場合があります。詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」および「ビュー・オブジェクトを使用したSQL問合せの定義」の説明に従って、アクセスするエンティティ・オブジェクトまたはビュー・オブジェクトを作成します。
「共有アプリケーション・モジュール・インスタンスの作成方法」の説明に従って、アプリケーション・モジュールの共有を有効にします。
「参照表のベース・ビュー・オブジェクト定義の作成方法」の説明に従って、参照データのベース・ビュー・オブジェクトを作成してください。
オプションとして、ビュー・オブジェクトで定義するビュー基準を適用することで、ビュー・アクセッサにより戻されるリストを再調整できます。ビュー・アクセッサで使用するビュー基準の作成方法は、「ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法」を参照してください。
ビュー・アクセッサを作成するには:
「アプリケーション」ウィンドウで、ビュー・アクセッサを定義するエンティティ・オブジェクトまたはビュー・オブジェクトをダブルクリックします。
ビュー・アクセッサをエンティティ・オブジェクトで作成するか、ビュー・オブジェクトで作成するかは、ビュー・アクセッサの目的の用途に応じて決まります。通常は、エンティティ・オブジェクトでビュー・アクセッサを作成した方が幅広い用途に使用できます。
概要エディタで「アクセッサ」ナビゲーション・タブをクリックし、「ビュー・アクセッサ」セクションで、「新規ビュー・アクセッサの作成」ボタンをクリックして、現在編集中のエンティティ・オブジェクトまたはビュー・オブジェクト定義にアクセッサを追加します。
「ビュー・アクセッサ」ダイアログで、共有アプリケーション・モジュールのノードから参照表に作成したビュー・インスタンス名を選択し、ビュー・アクセッサ・リストに移動します。
このダイアログには、アプリケーションのビュー・オブジェクトおよびビュー・インスタンスがすべて表示されます。たとえば、「ビュー・アクセッサ」ダイアログには、図14-5に示すように、共有アプリケーション・モジュールのLookupServiceAMとビュー・インスタンスのリストが表示されます。
デフォルトでは、作成されるビュー・アクセッサにはビュー・オブジェクト・インスタンスと同じ名前が表示されます(または、そのインスタンスを同名の子ビュー・オブジェクトと区別する必要がある場合は、整数が追加されます)。「アクセッサ名」を編集して一意の名前を付けることができます。
たとえば、図14-5の「ビュー・アクセッサ」ダイアログでは、共有アプリケーション・モジュールLookupServiceAMでAddressUsageTypesビュー・インスタンスを選択した場合として、ビュー・アクセッサAddressUsageTypesVAが表示されています。このビュー・アクセッサは、ベース・エンティティ・オブジェクトAddressUsagesEOで作成され、AddressUsageTypesビュー・インスタンスの行セットにアクセスします。
図14-5 エンティティ・オブジェクトでのビュー・アクセッサの定義
既存のビュー基準を適用してアクセッサをフィルタする場合は、概要エディタでビュー・アクセッサを選択し、「編集」アイコンをクリックします。
「ビュー・アクセッサの編集」ダイアログで、「編集」をクリックして次の手順を実行し、ビュー基準を適用します。
適用するビュー基準を選択し、「選択済」リストに移動します。
追加のビュー基準を追加すると、複数のフィルタ(実行時に論理積(AND)演算子を実行)を適用できます。
ビュー・アクセッサの行セットに制御属性を定義するバインド変数の属性名を入力します。
ビュー・オブジェクトで直接設定するビュー基準(ビュー・インスタンスを作成する場合など)と異なり、ビュー・アクセッサのビュー基準の制御属性では、ビュー・アクセッサのベース・ビュー・オブジェクトから値が導出されます。
「OK」をクリックします。
「ビュー・アクセッサ」ダイアログで、「OK」をクリックします。
リンク先ビュー・オブジェクトの行セットにアクセスするために作成するビュー・アクセッサを使用して、実行時にエンド・ユーザーから求められるデータを検証できます。たとえば、エンド・ユーザーが登録フォームに記入する場合、個々の検証規則により肩書、配偶者の有無、連絡先コードを、共有アプリケーション・モジュールのビュー・インスタンスにより問合せされた参照表データに対して検証できます。
エンティティ・オブジェクトに定義したビュー・アクセッサをこれらの組込みの宣言的検証規則に適用できます。
比較バリデータは、エンティティ属性と値の論理比較を実行します。使用可能な値を決定するためにビュー・アクセッサを指定する場合、比較バリデータにより、選択するEquals、NotEquals、GreaterThan、LessThan、LessOrEqualTo、GreaterOrEqualToの各演算子が適用され、ビュー・アクセッサで戻された値と比較されます。
リスト・バリデータにより、エンティティ属性と値リストが比較されます。有効なリスト値を決定するためにビュー・アクセッサを指定する場合、リスト・バリデータにより、選択するInまたはNotIn演算子がビュー・アクセッサで戻された値に対して適用されます。
コレクション・バリデータは、コレクション属性について実行された演算と値の論理比較を実行します。使用可能な値を決定するためにビュー・アクセッサを指定する場合、コレクション・バリデータにより、選択されたコレクション属性にSum、Average、Count、Min、Maxの各演算が適用され、ビュー・アクセッサで戻された値と比較されます。
エンティティ・ベースのビュー・オブジェクトのデータを実行時に検証できるよう定義する検証規則は、常にエンティティ・オブジェクトの属性に定義されます。エンティティ・オブジェクト・エディタを使用して個々の属性に検証規則を定義します。定義された検証規則を持つエンティティ・オブジェクトから導出され、後で定義するビュー・オブジェクトは、属性値の検証を自動的に受け取ります。
始める前に:
ビュー・アクセッサに関する知識が役立つ場合があります。詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
比較、リスト、またはコレクション・タイプのビュー・アクセッサを検証するには:
図14-6は、リスト・バリデータを使用してビュー・アクセッサ属性を選択する場合のダイアログを示しています。
Listバリデータを使用すると、<ListValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。次の例は、Addressエンティティ・オブジェクトのCountryId属性のXMLコードを示しています。Listバリデータが使用され、Countriesビュー・インスタンスからビュー・アクセッサが取得した国IDのリストに対して、ユーザー入力が検証されます。
<Attribute
Name="CountryId"
IsNotNull="true"
Precision="2"
ColumnName="COUNTRY_ID"
Type="java.lang.String"
ColumnType="CHAR"
SQLType="VARCHAR"
TableName="ADDRESSES">
RetrievedOnUpdate="true"
RetrievedOnInsert="true">
<DesignTime>
<Attr Name="_DisplaySize" Value="2"/>
</DesignTime>
<ListValidationBean
xmlns="http://xmlns.oracle.com/adfm/validation"
Name="CountryId_Rule_1"
ResId="CountryId_Rule_0"
OnAttribute="CountryId"
OperandType="VO_USAGE"
Inverse="false"
ViewAccAttrName="Value"
ViewAccName="SharedCountriesVA">
<ResExpressions>
<Expression
Name="0"><![CDATA[SharedCountriesVA.Value]]>
</Expression>
</ResExpressions>
</ListValidationBean>
<Properties>
<SchemaBasedProperties>
<LABEL
ResId="CountryId_LABEL"/>
</SchemaBasedProperties>
</Properties>
</Attribute>
ビュー・オブジェクトのAPIであるsetWhereClause()メソッドを使用すると、設計時にビュー基準が指定されているビュー・アクセッサを持つビュー・インスタンスに動的WHERE句を追加できます。実行時に、ビュー・アクセッサとそのビュー基準がビュー・インスタンスに適用された状態で、そのビュー・インスタンスでsetWhereClause()メソッドをコールしてWHERE句を追加すると、プログラム的に設定されたそのWHERE句が、すでに適用済のビュー基準のWHERE句にANDで結合されます。
リンク先ビュー・オブジェクトのビュー行にアクセスするために作成するビュー・アクセッサを使用して、実行時に値リストをエンド・ユーザーに表示できます。目的のビュー・インスタンスをデータソースとして使用してビュー・アクセッサを最初に作成すると、表示するビュー・オブジェクトのLOVが有効な属性にそのビュー・アクセッサを追加できます。ビュー・インスタンスの特定の参照属性をポイントするよう、LOVが有効な属性のビュー・アクセッサ定義を編集します。問合せでは、行セット・キャッシュに静的データを移入する必要があるため、共有アプリケーション・モジュールの関連先ビュー・インスタンスを特定します。
リストの使用方法は、UIリスト・コントロールにバインドされるビュー・オブジェクトの属性で定義されますが、ビュー・アクセッサ定義は、ビュー・オブジェクトまたはビュー・オブジェクトのベース・エンティティ・オブジェクトのいずれかに存在します。ビュー・オブジェクトのエンティティ・オブジェクトでビュー・アクセッサを作成するように選択した場合、ビュー・オブジェクトの概要エディタの「アクセッサ」ページには、図14-7に示すように、継承されたビュー・アクセッサが表示されます。属性のビュー・オブジェクトでビュー・アクセッサを作成するように選択した場合は、概要エディタの「アクセッサ」ページまたはLOV定義のエディタから実行できます。
LOVのビュー・アクセッサがデータベース表から常に最新のデータを問い合せるようにするために、ビュー・アクセッサのリンク先ビュー・オブジェクトで自動リフレッシュ機能を有効にできます。
始める前に:
ビュー・アクセッサに関する知識が役立つ場合があります。詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
LOV有効属性の使用方法の追加の例を理解しておくと役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
次のタスクを完了する必要があります。
「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」に従って、ビュー・アクセッサのデータソースとなるビュー・オブジェクトを作成します。
「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」に従って、ビュー・アクセッサのデータソースとなるビュー・オブジェクトを作成します。
オプションで、「ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法」の説明に従ってビュー・オブジェクトの自動リフレッシュを有効にします。
ビュー・アクセッサが参照表から常に最新のデータを問い合せるようにする必要がある場合は、リンク先ビュー・オブジェクトで「自動リフレッシュ」プロパティを設定します。このプロパティにより、データベースが変更されると、ビュー・オブジェクト・インスタンスを自動的にリフレッシュできます。これは、リンク先ビュー・オブジェクトにビュー・アクセッサを定義する場合の一般的なユースケースです。
参照表から値を表示するLOVを作成するには:
LOVをビュー・オブジェクト属性に追加すると、ビュー・オブジェクトのXMLファイルは<ViewAttribute>要素のLOVNameプロパティで更新されます。LOVの定義は、新しい<ListBinding>要素に表示されます。次の例のメタデータでは、PaymentTypeId属性がLOVのLOV_PaymentTypeIdを参照し、LOVを表示するchoiceコントロール・タイプを設定していることがわかります。LOV_PaymentTypeIdのLOV定義は、<ListBinding>要素に表示されます。
<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="CustomerRegistrationVO"
...
<ViewAttribute Name="PaymentTypeId"
LOVName="LOV_PaymentTypeId"
PrecisionRule="true"
EntityAttrName="PaymentTypeId"
EntityUsage="OrdEO"
AliasName="PAYMENT_TYPE_ID">
<Properties>
<SchemaBasedProperties>
<CONTROLTYPE Value="choice"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>
...
<ListBinding
Name="LOV_PaymentTypeId"
ListVOName="PaymentTypeVA"
ListRangeSize="-1"
NullValueFlag="start"
NullValueId="LOVUIHints_NullValueId"
MRUCount="0">
<AttrArray Name="AttrNames">
<Item Value="PaymentTypeId"/>
</AttrArray>
<AttrArray Name="ListAttrNames">
<Item Value="Id"/>
</AttrArray>
<AttrArray Name="ListDisplayAttrNames">
<Item Value="Payment Type"/>
</AttrArray>
<DisplayCriteria/>
</ListBinding>
...
</ViewObject>
ADFビジネス・コンポーネント実行時に、ビュー行およびエンティティ・オブジェクトの属性セッターに機能が追加され、LOVが有効な属性の動作が実現されます。ユーザー・インタフェースにLOVが有効な属性値を表示するために、LOVの機能によりデータソースをフェッチし、該当する行の属性とマップされたターゲット属性を検索します。
エンティティ・ベースのビュー・オブジェクトとは異なり、作成するカスタムSQLビュー・オブジェクトはデフォルトではキー属性を定義しません。キー属性を定義せずに読取り専用オブジェクトを作成することはできますが、カスタムSQLモードでは問い合せた表の主キーに対応する属性を選択し、キー属性としてマーキングしておくのがベスト・プラクティスです。キー属性があると、実行時に行セット・ナビゲーションを正しく動作させることができます。たとえば、ユーザー・インタフェース開発者は、読取り専用ビュー・オブジェクト・コレクションに基づいてLOVコンポーネントを作成することがあります。行キー値を指定するキー属性がなければ、LOVが正しく機能せず、実行時エラーが発生することがあります。
データバインドされたUIコンポーネントをWebページに作成するときは、「ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法」の説明に従って、対応するビュー・オブジェクトで自動リフレッシュ機能を有効にできます。この場合、ADFモデル・レイヤーおよびADFビジネス・コンポーネントが実行時にデータベース変更通知を処理し、共有アプリケーション・モジュール・キャッシュが自動的に更新されます。ただし、共有アプリケーション・モジュールのビュー・インスタンスをプログラム的にリフレッシュするメソッドを作成する場合は、ビュー・インスタンスをリフレッシュする前に、そのメソッドで共有アプリケーション・モジュールに対してprocessChangeNotification()メソッドを起動する必要があります。ビュー・インスタンスをリフレッシュする前にprocessChangeNotification()メソッドをコールすると、対応する問い合せたデータがデータベースで変更されている場合に、共有アプリケーション・モジュール・キャッシュが更新されます。
共有アプリケーション・モジュールのビュー・インスタンスをプログラムで更新するには、(SummitADF_ExamplesワークスペースのprocessChangeTestClient.javaの例の次の例に示すように)次の手順に従ってください。
processChangeNotification()メソッドをコールします。
共有アプリケーション・モジュールからビュー・インスタンスを取得します。
ビュー・インスタンスをリフレッシュします。
public class processChangeTestClient {
public static void main(String[] args) {
processChangeTestClient processChangeTestClient = new processChangeTestClient();
ApplicationModuleHandle handle = null;
String amDef = "oracle.summit.model.services.BackOfficeAppModule";
String config = "BackOfficeAppModuleLocal";
try {
handle = Configuration.createRootApplicationModuleHandle(amDef, config);
ApplicationModule am = handle.useApplicationModule();
// 1. Update the shared application module cache with changed data.
am.processChangeNotifications();
// 2. Get the view instance to refresh.
ViewObject vo = am.findViewObject("Inventory");
// 3. Refresh the view instance with updated data.
((ViewObjectImpl)vo).refreshCollection(null, false, false);
vo.reset();
while (vo.hasNext()) {
Row r = vo.next();
System.out.println((String)r.getAttribute("Name"));
}
} finally {
if (handle != null)
Configuration.releaseRootApplicationModuleHandle(handle, false);
}
}
}
ビュー・オブジェクトにより他のビュー・オブジェクトが拡張される場合、ベース・オブジェクトにLOVが有効な属性を作成できます。概要エディタで子ビュー・オブジェクトを定義すると、対応するビュー・オブジェクト属性にLOV定義が表示されます。この継承メカニズムにより、LOVが有効な属性を1回定義し、後で同じ属性の複数のビュー・オブジェクト・インスタンス全体にその属性を適用できます。他のビュー・オブジェクト定義からビュー・オブジェクトを拡張する方法の詳細は、「コンポーネントを作成後に拡張する方法」を参照してください。
また、概要エディタを使用して継承LOV定義を拡張できます。たとえば、ベース・ビュー・オブジェクトの問合せによりすでに定義されている属性を追加して、選択リストに表示できます。あるいは、カスタムのWHERE句を使用するビュー・オブジェクト・インスタンスを作成して、ベース・ビュー・オブジェクトによりまだ問合せされていない追加属性を問合せできます。エンティティ・ベース・ビュー・オブジェクトのカスタマイズの詳細は、「バインド変数の使用」を参照してください。
ビュー・オブジェクトにLOVが有効な属性を作成した場合、List Validatorを使用して属性を検証する必要はありません。ユーザー・インタフェースにリストを表示せず、有効値のリストを制限する必要がある場合のみ属性バリデータを使用します。List Validatorは、単純な静的リスト、または定義するビュー・アクセッサから取得した使用可能な値のリストです。UIに表示された属性がキー値(主キー、外部キー、または代替キー)を参照する属性の場合には、Key Exists Validatorを使用します。ADF Business Componentsでの宣言的な検証の詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。
JDeveloperの対話型ADFビジネス・コンポーネント・アプリケーション・モジュール・テスト・ツールを使用してデータ・モデルをテストします。これにより、アプリケーション・ユーザー・インタフェースまたはテスト・クライアント・プログラムを必要とせずに、テストを実行できます。
JDeveloperには、アプリケーション・ユーザー・インタフェースを使用せず、またはテスト・クライアントのプログラムを記述せずに、データ・モデルのすべての面をテストできるようにする、対話型アプリケーション・モジュール・テスト・ツールが用意されています。多くの場合、Oracle ADFモデル・テスターを実行すると、開発時にビジネス・サービスのデータ機能を最も迅速に実行できます。
アプリケーション・モジュールは、Oracle ADFモデル・テスター(またはUIクライアント)がアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールで使用される一連のビュー・オブジェクトは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。Oracle ADFモデル・テスターを使用すると、定義したアクセッサで予測どおりの検証結果が得られ、正しいLOV属性値が表示されるかをテストできます。
アプリケーション・モジュールに追加したビュー・オブジェクトをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。
始める前に:
Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「共有アプリケーション・モジュールでのビュー・オブジェクト・インスタンスのテスト」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを理解しておくと役立つ場合があります。詳細は、「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・モジュール構成でビュー・オブジェクトをテストするには:
ビュー・オブジェクト・インスタンスはすでにテスト・セッションで実行されているように表示される場合があります。この場合、右側のテスター・パネルには、図14-8で示しているように、すでにビュー・オブジェクト・インスタンスの問合せ結果が表示されています。読取り専用ビュー・オブジェクトのテスター・パネルのフィールドは、そのビュー・オブジェクトで表されるデータが編集できないため、常に無効として表示されます。
図14-8 Oracle ADFモデル・テスターでのデータ・モデルのテスト
ビュー・オブジェクト属性に作成したLOVをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。テスターの表示およびサポートされるコントロール・タイプの詳細は、「Oracle ADFモデル・テスターを使用してLOV有効属性をテストする方法」を参照してください。
Oracle ADFモデル・テスターを起動すると、JDeveloperによってテスター・ツールが別プロセスで開始され、Oracle ADFモデル・テスターが表示されます。ダイアログの左側のツリーには、アプリケーション・モジュールのデータ・モデルのすべてのビュー・オブジェクト・インスタンスが表示されます。図14-8は、展開されたツリーにProductImagesと呼ばれるインスタンス1つのみを示しています。目的のビュー・オブジェクト・インスタンスをダブルクリックすると、図14-8に示すように、問合せ結果を検査するパネルがOracle ADFモデル・テスターに表示されます。
データは編集できないため、表示する読取り専用のビュー・オブジェクトすべてに対して、テスト・パネルは無効になっています。ただし、読取り専用のビュー・オブジェクトの場合でも、ツールはいくつかの有用な機能を備えています。
「ラベル・テキスト」のコントロール・ヒントに基づいたUIヒント、およびフォーマット・マスクが正しく定義されているかどうかを検証できます。
ツールバー・ボタンを使用してデータのスクロールもできます。
「エンティティ・ベースのビュー・オブジェクトの対話的テスト方法」で説明しているように、行の挿入、更新および削除をシミュレートできるエンティティ・ベースのビュー・オブジェクトを作成する場合は、Oracle ADFモデル・テスターをより便利に使用できます。
アプリケーション・スコープを備えた共有アプリケーション・モジュールがLOVによりリクエストされると、その使用方法のためADFビジネス・コンポーネント実行時にApplicationPoolオブジェクトが作成されます。ApplicationPoolは、ADFビジネス・コンポーネント・プロジェクト構成ファイル(.jpx)に定義されている共有使用ごとに1つのみ作成されます。その後、実行時にApplicationPoolが使用され、データの取得にユーザー・アプリケーション・モジュールのように使用されるアプリケーション・モジュール・インスタンスが取得されます。共有アプリケーション・モジュール・インスタンスへの参照は、アプリケーション・スコープのアプリケーション・モジュールがリセットされると、解放されます。モジュール参照は、管理されていない解放の実行時またはセッション・タイムアウトで常に解放されます。
共有アプリケーション・モジュールのデータ・キャッシュは複数のスレッドでアクセスされるため、イテレータのスペースを分割して異なるセッションのイテレータ間の競合を回避する必要があります。これにより、あるセッションからの次のリクエストによって、別のセッションで使用中のイテレータの状態が変更されることはなくなります。実行時に、単一のRowSetの上部の複数のイテレータに対してADFビジネス・コンポーネントのサポートを受け、これらの競合を回避します。したがって、実行時に各RowSetのアクティブ・セッションと同じ数のイテレータがインスタンス化されます。
アプリケーション・スコープの共有アプリケーション・モジュール・ライフサイクルはApplicationPoolオブジェクトで管理されるアプリケーション・モジュールのライフサイクルと類似しています。たとえば、すべてのアクティブ・セッションがその共有アプリケーション・モジュールを解放すると、アプリケーション・モジュールはApplicationPoolオブジェクトにより収集されるガベージになります。共有プールは、特定のアプリケーション要件を満たすようにチューニングできます。
セッション・スコープの共有アプリケーション・モジュールは、ルートのユーザー・アプリケーション・モジュールのデータ・モデル内で、ネストされたアプリケーション・モジュール・インスタンスとして単純に作成されます。ネストされたアプリケーション・モジュールの詳細は、「ネストされたアプリケーション・モジュールの定義」を参照してください。
