14 アプリケーション・モジュール・ビュー・インスタンスの共有
この章の内容は次のとおりです。
共有アプリケーション・モジュールについて
複数のセッションからの複数のリクエストで単一のアプリケーション・モジュールを共有できるようにする共有ADFビジネス・コンポーネント・アプリケーション・モジュールを作成できます。これにより、データ・キャッシュの再移入による不要なオーバーヘッドを防止できます。
Webアプリケーションでは、セッション全体で必要とされる、あまり頻繁に変更されないデータがよく使用されます。この種の統計データの例は、アプリケーション・ユーザー・インタフェースの検索リストに表示されることがあります。アプリケーションが静的データにアクセスするたびに、すべてのリクエストにおける各アプリケーション・セッションのデータベースから静的データ・キャッシュが再移入されると、不要なオーバーヘッドが発生する場合があります。ADFビジネス・コンポーネントで作業を行う場合にパフォーマンスを最適化するためには、一般的にセッションおよびリクエスト間で再使用する共有静的データをキャッシュします。共有アプリケーション・モジュールの作成によって、複数のセッションのリクエストで、Webサーバー仮想マシン用のアプリケーション・プールで永続的に管理できる、単一のアプリケーション・モジュール・インスタンスを共有できます。
共有アプリケーション・モジュールのユースケースと例
ADFビジネス・コンポーネントのビュー・アクセッサは、エンティティ・オブジェクト属性(またはビュー・オブジェクト)から、同じアプリケーション・ワークスペースのリンク先ビュー・オブジェクトまたは共有ビュー・インスタンスをポイントする、値のアクセッサ・オブジェクトです。
異なるアプリケーション・モジュールのビュー・オブジェクトにアクセスするこの機能により、ビュー・アクセッサは次の場合に特に便利です。
-
エンティティ・オブジェクトの属性に設定する検証規則。たとえば、エンド・ユーザーが登録フォームに記入する場合、個々の検証規則により肩書、配偶者の有無、連絡先コードを、共有アプリケーション・モジュールのビュー・インスタンスにより問合せされた参照表データに対して検証できます。
-
ビュー・オブジェクトの属性に対して有効にする値リスト(LOV)。たとえば、実行時にエンド・ユーザーに値リストを表示する場合です。
共有アプリケーション・モジュールの追加機能
共有アプリケーション・モジュールを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。
-
実行時のパフォーマンスを向上させるためのアプリケーション・モジュール・インスタンス構成の詳細は、「Fusion Webアプリケーションでの状態管理の使用」および「アプリケーション・モジュール・プールのチューニング」を参照してください。
-
カスタム・アプリケーション・モジュール・クラスでよく記述、使用またはオーバーライドするコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。
-
oracle.jbo
パッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。
アプリケーション・モジュール・インスタンスの共有
JDeveloperでは、アプリケーション・レベルまたはセッション・レベルのADFアプリケーション・モジュール・データ・モデルの共有を指定できます。
共有データ・キャッシュの宣言型サポートは、JDeveloperの「プロジェクト・プロパティ」ダイアログで提供されています。共有アプリケーション・モジュールの作成によって、複数のセッションのリクエストで、Webサーバー仮想マシン用のアプリケーション・プールで永続的に管理できる、単一のアプリケーション・モジュール・インスタンスを共有できます。
ベスト・プラクティス:
アプリケーション全体で静的データのリストを再利用する場合は、共有アプリケーション・モジュールを使用してビュー・インスタンスをグループ化します。共有アプリケーション・モジュールは、すべてのユーザー・セッションでデータにアクセスできるように構成したり、シングル・ユーザー・セッションのUIコンポーネントのみにアクセスを制限するように構成できます。たとえば、共有アプリケーション・モジュールを使用して、国リストなどの参照データにアクセスするビュー・インスタンスをグループ化できます。共有アプリケーション・モジュールを使用すると、すべての共有リソースを1か所で管理できるため、この目的でのスコープのマネージドBeanが不要になります。
図14-1で示すように、「プロジェクト・プロパティ」ダイアログにより、アプリケーションレベルまたはセッションレベルでのアプリケーション・モジュールのデータ・モデルの共有を指定できます。アプリケーションレベルの共有では、任意のHTTPユーザー・セッションが共有アプリケーション・モジュールに含まれた同一のビュー・インスタンスにアクセスできます。一方、セッションレベルの共有アプリケーション・モジュールは、単一のHTTPユーザー・セッションで使用されるアプリケーション・セッション(SessionImpl
)に拡張され、単一のルート・アプリケーション・モジュールに適用されます。この場合、特定のHTTPユーザー・セッションで使用する個別のルート・アプリケーション・モジュールは、セッションの有効範囲の共有アプリケーション・モジュールの独自の個別インスタンスを取得します。つまり、同一のHTTPセッションが使用している個別のルート・アプリケーションはセッションの有効範囲の共有アプリケーション・モジュール内のデータを共有しません。
図14-1 共有アプリケーション・モジュール・インスタンスを定義する「プロジェクト・プロパティ」ダイアログ
![図14-1の説明が続きます 図14-1の説明が続きます](img/shared_am_project_props.png)
「図14-1 共有アプリケーション・モジュール・インスタンスを定義する「プロジェクト・プロパティ」ダイアログ」の説明
共有するアプリケーション・モジュールのデータ・モデルを作成する場合、キャッシュされた行セットのデータは、アプリケーションレベルまたはセッションレベルで変更する必要はありません。たとえば、アプリケーションレベルの共有アプリケーション・モジュールでは、ビュー・インスタンスは状態コードや通貨タイプなど静的データのみを問い合せます。ビュー・オブジェクト・インスタンスが現在のユーザーに依存するデータを問い合せると、問合せはセッションレベルでキャッシュされ、行セット・キャッシュを参照するすべてのコンポーネントにより共有できます。たとえば、セッションレベルの共有アプリケーション・モジュールには、直下のレポートのリストを返すため、現在のユーザーとしてマネージャが必要なデータ・セキュリティを備えたビュー・インスタンスが含まれる場合があります。この場合、直下のレポートのキャッシュは、マネージャのHTTPユーザー・セッションの期間中存在します。HTTPユーザー・セッションにプール内の再利用アプリケーション・モジュールを割り当てた場合に、ADFビジネス・コンポーネント・アプリケーション・モジュール・プールは、セッションの有効範囲のアプリケーション・モジュールを再度作成します。これによってHTTPセッションが同じルート・アプリケーション・モジュール・インスタンスを使用可能であるかぎり、セッションの有効範囲のアプリケーション・モジュール期間がHTTPセッションに結び付けられます。セッションレベルの共有アプリケーション・モジュールの直下のレポートのキャッシュは、異なるルート・アプリケーション・モジュールをまたがってアクセスできない点に注意してください。
共有アプリケーション・モジュール・インスタンスの作成方法
共有アプリケーション・モジュール・インスタンスを作成するには、「プロジェクト・プロパティ」ダイアログを使用します。アプリケーションの読取り専用データを保持する個別の独立したルート・アプリケーション・モジュールの論理名を定義します。
始める前に:
参照データに関する知識が役立つ場合があります。詳細は、「ベース・ビュー・オブジェクトを参照表で使用するための定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
- 「アプリケーション・モジュールの作成方法」の説明に従って、共有するアプリケーション・モジュールを作成します。
共有アプリケーション・モジュール・インスタンスを作成するには:
共有アプリケーション・モジュール定義時の処理
アプリケーション・モジュールを作成すると、JDeveloperによりAppModuleName
Shared
構成が自動的に作成されます。bc4j.xcfg
ファイル内のこの構成の存在により、JDeveloperにアプリケーション・モジュールが共有の候補であることが通知され、「プロジェクト・プロパティ」ダイアログの「アプリケーション・モジュールの慣用名」ページの「使用可能なアプリケーション・モジュール」リストにアプリケーション・モジュールを表示させることができます。
AppModuleName
Shared
構成により、アプリケーション・モジュールのこれらのプロパティが共有を有効にして、実行時の共有リソースの効率的な使用を維持するように設定されます。
-
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機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
- 「アプリケーション・モジュールの作成方法」の説明に従って、共有するアプリケーション・モジュールを作成します。
参照表のベース・ビュー・オブジェクトを作成するには:
ベース・ビュー・オブジェクトの作成時の処理
参照表のビュー・オブジェクト定義を作成する際、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>
ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法
ビュー・オブジェクト結果をフィルタする必要がある場合、名前付きビュー基準定義をデータ・モデル・プロジェクトに作成します。設計時に定義するビュー基準は、データのフィルタリングが必要となる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機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
次のタスクを完了する必要があります。
比較、リスト、またはコレクション・タイプのビュー・アクセッサを検証するには:
ビュー・アクセッサ・バリデータ定義時の処理
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が有効な属性にそのビュー・アクセッサを追加できます。ビュー・インスタンスの特定の参照属性をポイントするよう、LOVが有効な属性のビュー・アクセッサ定義を編集します。問合せでは、行セット・キャッシュに静的データを移入する必要があるため、共有アプリケーション・モジュールの関連先ビュー・インスタンスを特定します。
リストの使用方法は、UIリスト・コントロールにバインドされるビュー・オブジェクトの属性で定義されますが、ビュー・アクセッサ定義は、ビュー・オブジェクトまたはビュー・オブジェクトのベース・エンティティ・オブジェクトのいずれかに存在します。ビュー・オブジェクトのエンティティ・オブジェクトでビュー・アクセッサを作成するように選択した場合、ビュー・オブジェクトの概要エディタの「アクセッサ」ページには、図14-7に示すように、継承されたビュー・アクセッサが表示されます。属性のビュー・オブジェクトでビュー・アクセッサを作成するように選択した場合は、概要エディタの「アクセッサ」ページまたはLOV定義のエディタから実行できます。
LOVのビュー・アクセッサがデータベース表から常に最新のデータを問い合せるようにするために、ビュー・アクセッサのリンク先ビュー・オブジェクトで自動リフレッシュ機能を有効にできます。
始める前に:
ビュー・アクセッサに関する知識が役立つ場合があります。詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
LOV有効属性の使用方法の追加の例を理解しておくと役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
次のタスクを完了する必要があります。
-
「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」に従って、ビュー・アクセッサのデータソースとなるビュー・オブジェクトを作成します。
-
「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」に従って、ビュー・アクセッサのデータソースとなるビュー・オブジェクトを作成します。
-
オプションで、「ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法」の説明に従ってビュー・オブジェクトの自動リフレッシュを有効にします。
ビュー・アクセッサが参照表から常に最新のデータを問い合せるようにする必要がある場合は、リンク先ビュー・オブジェクトで「自動リフレッシュ」プロパティを設定します。このプロパティにより、データベースが変更されると、ビュー・オブジェクト・インスタンスを自動的にリフレッシュできます。これは、リンク先ビュー・オブジェクトにビュー・アクセッサを定義する場合の一般的なユースケースです。
参照表から値を表示するLOVを作成するには:
ビュー・オブジェクト属性の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); } } }
AttributeDefプロパティの継承に関する必知事項
ビュー・オブジェクトにより他のビュー・オブジェクトが拡張される場合、ベース・オブジェクトに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モデル・テスターを使用したベース・ビュー・オブジェクトのテスト方法
アプリケーション・モジュールは、Oracle ADFモデル・テスター(またはUIクライアント)がアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールで使用される一連のビュー・オブジェクトは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。Oracle ADFモデル・テスターを使用すると、定義したアクセッサで予測どおりの検証結果が得られ、正しいLOV属性値が表示されるかをテストできます。
アプリケーション・モジュールに追加したビュー・オブジェクトをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。
始める前に:
Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「共有アプリケーション・モジュールでのビュー・オブジェクト・インスタンスのテスト」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。
ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを理解しておくと役立つ場合があります。詳細は、「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。
次のタスクを完了する必要があります。
- 「アプリケーション・モジュールの作成と変更」の説明に従って、ビュー・インスタンスを持つアプリケーション・モジュールを作成します。
アプリケーション・モジュール構成でビュー・オブジェクトをテストするには:
Oracle ADFモデル・テスターを使用してLOV有効属性をテストする方法
ビュー・オブジェクト属性に作成したLOVをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。テスターの表示およびサポートされるコントロール・タイプの詳細は、「Oracle ADFモデル・テスターを使用してLOV有効属性をテストする方法」を参照してください。
Oracle ADFモデル・テスター使用時の処理
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
オブジェクトにより収集されるガベージになります。共有プールは、特定のアプリケーション要件を満たすようにチューニングできます。
セッション・スコープの共有アプリケーション・モジュールは、ルートのユーザー・アプリケーション・モジュールのデータ・モデル内で、ネストされたアプリケーション・モジュール・インスタンスとして単純に作成されます。ネストされたアプリケーション・モジュールの詳細は、「ネストされたアプリケーション・モジュールの定義」を参照してください。