| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
前 |
次 |
この章では、ADFビジネス・コンポーネント・データ・モデル・プロジェクトを整理し、参照表やフラット・ファイルなどの静的データソースからアクセスされる読取り専用データを最も効率的に共有する方法について説明します。また、アプリケーション・レベルで共有するADFアプリケーション・モジュールとセッション・レベルで共有するADFアプリケーション・モジュールの違いを説明します。
この章の内容は次のとおりです。
Webアプリケーションでは、セッション全体で必要とされる、あまり頻繁に変更されないデータがよく使用されます。この種の統計データの例は、アプリケーション・ユーザー・インタフェースの検索リストに表示されることがあります。アプリケーションが静的データにアクセスするたびに、すべてのリクエストにおける各アプリケーション・セッションのデータベースから静的データ・キャッシュが再移入されると、不要なオーバーヘッドが発生する場合があります。ADFビジネス・コンポーネントで作業を行う場合にパフォーマンスを最適化するためには、一般的にセッションおよびリクエスト間で再使用する共有静的データをキャッシュします。
共有データ・キャッシュの宣言型サポートは、JDeveloperの「プロジェクト・プロパティ」ダイアログで提供されています。共有アプリケーション・モジュールの作成によって、複数のセッションのリクエストで、Webサーバー仮想マシン用のアプリケーション・プールで永続的に管理できる、単一のアプリケーション・モジュール・インスタンスを共有できます。
|
ベスト・プラクティス: アプリケーション全体で静的データのリストを再利用する場合は、共有アプリケーション・モジュールを使用してビュー・インスタンスをグループ化します。共有アプリケーション・モジュールは、すべてのユーザー・セッションでデータにアクセスできるように構成したり、シングル・ユーザー・セッションのUIコンポーネントのみにアクセスを制限するように構成できます。たとえば、共有アプリケーション・モジュールを使用して、国リストなどの参照データにアクセスするビュー・インスタンスをグループ化できます。共有アプリケーション・モジュールを使用すると、すべての共有リソースを1か所で管理できるため、この目的でのスコープのマネージドBeanが不要になります。 |
図10-1で示すように、「プロジェクト・プロパティ」ダイアログにより、アプリケーションレベルまたはセッションレベルでのアプリケーション・モジュールのデータ・モデルの共有を指定できます。アプリケーションレベルの共有では、任意のHTTPユーザー・セッションが共有アプリケーション・モジュールに含まれた同一のビュー・インスタンスにアクセスできます。一方、セッションレベルの共有アプリケーション・モジュールは、単一のHTTPユーザー・セッションで使用されるアプリケーション・セッション(SessionImpl)に拡張され、単一のルート・アプリケーション・モジュールに適用されます。この場合、特定のHTTPユーザー・セッションで使用する個別のルート・アプリケーション・モジュールは、セッションの有効範囲の共有アプリケーション・モジュールの独自の個別インスタンスを取得します。つまり、同一のHTTPセッションが使用している個別のルート・アプリケーションはセッションの有効範囲の共有アプリケーション・モジュール内のデータを共有しません。
共有するアプリケーション・モジュールのデータ・モデルを作成する場合、キャッシュされた行セットのデータは、アプリケーションレベルまたはセッションレベルで変更する必要はありません。たとえば、アプリケーションレベルの共有アプリケーション・モジュールでは、ビュー・インスタンスは状態コードや通貨タイプなど静的データのみを問い合せます。ビュー・オブジェクト・インスタンスが現在のユーザーに依存するデータを問い合せると、問合せはセッションレベルでキャッシュされ、行セット・キャッシュを参照するすべてのコンポーネントにより共有できます。たとえば、セッションレベルの共有アプリケーション・モジュールには、直下のレポートのリストを返すため、現在のユーザーとしてマネージャが必要なデータ・セキュリティを備えたビュー・インスタンスが含まれる場合があります。この場合、直下のレポートのキャッシュは、マネージャのHTTPユーザー・セッションの期間中存在します。HTTPユーザー・セッションにプール内の再利用アプリケーション・モジュールを割り当てた場合に、ADFビジネス・コンポーネント・アプリケーション・モジュールは、セッションの有効範囲のアプリケーション・モジュールを再度作成します。これによってHTTPセッションが同じルート・アプリケーション・モジュール・インスタンスを使用可能であるかぎり、セッションの有効範囲のアプリケーション・モジュール期間がHTTPセッションに結び付けられます。セッションレベルの共有アプリケーション・モジュールの直下のレポートのキャッシュは、異なるルート・アプリケーション・モジュールをまたがってアクセスできない点に注意してください。
共有アプリケーション・モジュール・インスタンスを作成するには、「プロジェクト・プロパティ」ダイアログを使用します。アプリケーションの読取り専用データを保持する個別の独立したルート・アプリケーション・モジュールの論理名を定義します。
作業を始める前に、次のようにします。
9.2.1項「アプリケーション・モジュールの作成方法」に記載されている方法に従って、共有するアプリケーション・モジュールを作成します。
共有アプリケーション・モジュール・インスタンスを作成するには:
アプリケーション・ナビゲータで、共有アプリケーション・モジュールを作成するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ビジネス・コンポーネント」を展開し、「アプリケーション・モジュール・インスタンス」を選択します。
「使用可能なアプリケーション・モジュール」リストで、該当するモジュールを選択し、「アプリケーション・モジュール・インスタンス」 リストに移動します。
アプリケーション・モジュールに一意のインスタンス名を割り当てます。
共有アプリケーション・モジュール・インスタンス(いずれかのスコープ)には、一意のインスタンス名が必要です。意味のある名前を指定することにより、指定された慣用名が参照している共有アプリケーション・モジュール・インスタンスを明確にすることもできます。
共有アプリケーション・モジュールの「キャッシュ・レベル」を選択します。
アプリケーションのコンテキストについて共有アプリケーション・モジュールを定義する場合は、「アプリケーション」を選択します。
現在のユーザー・セッションのコンテキストについて共有アプリケーション・モジュールを定義する場合は、「セッション」を選択します。
「OK」をクリックします。
アプリケーション・モジュールを作成すると、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)を変更すると、アプリケーション・モジュールは共有アプリケーション・モジュール・インスタンスとして使用できなくなります。
たとえば、Fusion Order DemoアプリケーションのStoreFrontServiceプロジェクトの./src/oracle/fodemo/storefront/lookups/commonディレクトリの中にあるbc4j.xcfgファイルを見ると、例10-1のように、LookupServiceAMアプリケーション・モジュール用に名前の付いた構成が2つあることがわかります。特に、LookupServiceAMShared構成によりjbo.ampool実行時プロパティが共有アプリケーション・モジュール・インスタンスに設定されます。ADFビジネス・コンポーネント・アプリケーション・モジュール・プールおよびアプリケーション・モジュールの実行時構成の詳細は、第41章「アプリケーション・モジュール・プールと接続プールのチューニング」を参照してください。
例10-1 bc4j.xcfgファイルのLookupServiceAMShared構成
<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
<AppModuleConfigBag
ApplicationName="oracle.fodemo.storefront.lookups.LookupServiceAM">
<AppModuleConfig DeployPlatform="LOCAL"
JDBCName="FOD"
jbo.project="StoreFrontService"
name="LookupServiceAMLocal"
ApplicationName="oracle.fodemo.storefront.lookups.LookupServiceAM">
<Database jbo.locking.mode="optimistic"/>
<Security
AppModuleJndiName="oracle.fodemo.storefront.lookups.LookupServiceAM"/>
</AppModuleConfig>
<AppModuleConfig DeployPlatform="LOCAL"
JDBCName="FOD"
jbo.project="StoreFrontService"
name="LookupServiceAMShared"
ApplicationName="oracle.fodemo.storefront.lookups.LookupServiceAM">
<AM-Pooling jbo.ampool.dynamicjdbccredentials="false"
jbo.ampool.isuseexclusive="false"
jbo.ampool.maxpoolsize="1"
jbo.ampool.resetnontransactionalstate="false"/>
<Database jbo.locking.mode="optimistic"/>
<Security
AppModuleJndiName="oracle.fodemo.storefront.lookups.LookupServiceAM"/>
</AppModuleConfig>
</AppModuleConfigBag>
</BC4JConfig>
共有アプリケーション・モジュールは同じアプリケーション・ワークスペースのビジネス・コンポーネント・プロジェクトからアクセスできるため、ビジネス・コンポーネント・プロジェクト構成ファイル(.jpx)にある共有アプリケーション・モジュールのスコープが保持されます。このファイルは、プロジェクトのsrcディレクトリに保存されています。たとえば、Fusion Order DemoアプリケーションのStoreFrontServiceプロジェクトの./srcサブディレクトリの中にあるStoreFrontService.jpxファイルを見ると、例10-2に示すように、SharedLookupServiceアプリケーション・モジュールの慣用名定義でアプリケーションレベル共有に従ってSharedScope = 2を指定していることがわかります。セッションレベルの共有に設定するアプリケーション・モジュールは、SharedScope = 1を表示します。
例10-2 .jpxファイルのアプリケーション・モジュールの慣用名の構成
<JboProject
xmlns="http://xmlns.oracle.com/bc4j"
Name="StoreFrontService"
SeparateXMLFiles="true"
PackageName="">
. . .
<AppModuleUsage
Name="SharedLookupService"
FullName="oracle.fodemo.storefront.lookups.LookupServiceAM"
ConfigurationName="oracle.fodemo.storefront.lookups.LookupServiceAMShared"
SharedScope="2"/>
</JboProject>
「プロジェクト・プロパティ」ダイアログで共有アプリケーション・モジュールを定義すると、アプリケーション・モジュールのデータ・モデルは同じアプリケーション・ワークスペースに属する他のビジネス・コンポーネント・プロジェクトに対してのみ使用できるようになります。アプリケーション・ワークスペースの範囲を超えてデータ・モデルを使用可能にする場合、第33章「アプリケーション・コンポーネントの再利用」で説明するようにデータ・モデルをADFライブラリとして公開できます。
構造ウィンドウで、DataBindings.cpxファイルからデータ・コントロールの使用方法を表示する場合は、「構成」プロパティを共有アプリケーション・モジュール構成に設定しないでください。AppModuleNameという名前のアプリケーション・モジュールの場合、「プロパティ・インスペクタ」には、デフォルトでAppModuleNameSharedおよびAppModuleNameLocalという名前の構成が表示されます。Oracle Application Development Framework (Oracle ADF)では、アプリケーションを共有アプリケーション・モジュールとして構成すると、実行時に共有構成が自動的に使用されますが、アプリケーション・モジュールのデータ・コントロールで使用されるように設計されていません。データ・コントロールの使用の詳細は、12.4項「DataBindings.cpxファイルでの作業」を参照してください。
JDeveloperでは、プロジェクトのビジネス・コンポーネント定義で、共有アプリケーション・モジュールのビュー・インスタンスへのアクセスを許可するビュー・アクセッサを定義する必要があります。ビュー・アクセッサにより、1つのビジネス・コンポーネント・プロジェクトのエンティティ・オブジェクトまたはビュー・オブジェクト定義から共有アプリケーション・モジュールのビュー・オブジェクト定義またはビュー・インスタンスへポイントできます。この目的でのビュー・アクセッサ作成の詳細は、10.4項「共有サービスのビュー・インスタンスへのアクセス」を参照してください。
ADFビジネス・コンポーネントにおけるアプリケーション・モジュール・プールと同様に、共有問合せコレクションは問合せコレクション・プールに格納されています。問合せコレクション・プールを管理するために、ADFビジネス・コンポーネントのフレームワークは、最大アイドル時間の設定に基づき、問合せコレクションを削除します。この動作によってキャッシュの拡大を制限し、使用頻度の低い問合せコレクションがメモリー領域を占有しないようにします。
アプリケーション・モジュールと接続プールと同様に、問合せコレクション・プール・モニターは、ユーザーが指定したスリープ間隔後にウェイクアップし、クリーンアップ操作を開始します。最大アイドル時間(最後に使用してからの時間の長さ)を超えた問合せコレクションは、プールから削除されます。
共有問合せコレクションの最大アイドル時間(デフォルトは900000 ms/15分) と、そのプール・モニターのスリープ時間(デフォルトは1800000 ms/30分)のデフォルト値を変更できます。これらの値を設定するには、「ビジネス・コンポーネント構成の編集」ダイアログを開き、AppModuleNameの「共有」構成を選択し、エディタの「プロパティ」ページでこれらのプロパティを設定します。
jbo.qcpool.monitorsleepinterval 1回のプール・チェックから次のプール・チェックまでの間に接続プール・モニターがスリープする時間(ms)。
jbo.qcpool.maxinactiveage 接続をプールから削除する前に非アクティブのまま保持する最大時間(ms)。
すべてのアプリケーション・モジュールの接続動作として、ルート・アプリケーション・モジュールごとに独自のデータベース接続を許可します。アプリケーションで複数の共有アプリケーション・モジュールを定義する場合、使用する各ルート・アプリケーション・モジュールに名前付きのトランザクションを定義して、デフォルトを変更し、データベース接続を最適化することができます。トランザクション名は、ルート・アプリケーション・モジュールのbc4j.xcfgファイルに対して、エディタの「プロパティ」ページのjbo.shared.txnプロパティで設定した任意の文字列です。実行時には、同じjbo.shared.txnプロパティ文字列(提供する文字列によって定義)を含むルート・アプリケーション・モジュールが、同じデータベース接続とエンティティ・キャッシュを共有します。この種の最適化によってアプリケーションが使用するデータベース・リソース量が減ります。これは読取り専用でトランザクション・アプリケーション・モジュールよりも長く存在する共有アプリケーション・モジュールの場合は特に有効です。
現在、アプリケーション・モジュールの構成パラメータであるjbo.doconnectionpooling=trueは、共有アプリケーション・モジュールではサポートされていません。この機能はJDBC接続オブジェクトをデータベース接続プールに解放することが望ましい場合に、非共有アプリケーション・モジュールを構成するために提供されています。
共有アクセス状態の管理によって発生するパフォーマンス低下を防止するために、共有アプリケーションではこの機能は意図的にサポートしていません。かわりに、デフォルトでjbo.doconnectionpooling=falseを使用することを推奨しています。
デフォルト接続プーリング構成により、アプリケーション・モジュール・プールからアプリケーション・モジュール・インスタンスが削除されるまで、各共有アプリケーション・モジュール・インスタンスはプールから取得したJDBC接続オブジェクトを必ず維持します。jbo.doconnectionpoolingパラメータと接続プール動作の詳細は、41.2.6項「データベースとアプリケーション・モジュール・プールの連携方法について」を参照してください。
アプリケーションで静的データを表示する必要がある場合は、参照表にアクセスする可能性が高いビュー・インスタンスで共有アプリケーション・モジュールを定義できます。参照表は、アプリケーションにより参照されるデータの静的な変換リストです。参照表のデータは、様々な方法でデータベースに配置できます。関連する検索データを個別の表に格納できる一方、単一の表内にアプリケーションの参照情報をすべて結合すると便利です。たとえば、ORDERS_LOOKUPS表向けに作成された列LOOKUP_TYPEは、値である「はい」および「いいえ」のFWK_TBX_YES_NO、国名のFWK_TBX_COUNTRY、国の通貨の名前を表すFWK_TBK_CURRENCYという様々なコードを含む1つの表を分割する役割を果します。
データベース・スキーマにより単一のデータベース表の検索データが配置される場合、一連のデータごとに個別の問合せを作成することを避ける必要があります。かわりに、概要エディタを使用して、定義したビュー・オブジェクト属性に参照表の目的の列をマップする単一のベース・ビュー・オブジェクトを定義します。問合せ文ではLOOKUP_TYPE列の値のみ変更する必要があるため、ビュー・オブジェクト定義にビュー基準を追加して、LOOKUP_TYPE値を設定するLOOKUP_TYPE句を指定できます。これにより、単一のビュー・オブジェクト定義の参照表データへのアクセスがカプセル化され、LOOKUP_TYPE値が変更された場合やアプリケーションで追加の参照タイプを問い合せる必要がある場合にメンテナンスが簡単になります。
参照表の列を問い合せるベース・ビュー・オブジェクトは、データの更新処理の必要がないため、またはエンティティ・ベースのビュー・オブジェクトで提供される利点が不要なため、読取り専用ビュー・オブジェクトとなります。(これらの利点については、5.1.2項「エンティティ・ベースのビュー・オブジェクト固有の実行時機能」を参照してください。)
|
注意: 参照表にアクセスするために作成する読取り専用ビュー・オブジェクトは、共有アプリケーション・モジュールに組み込むには理想的ですが、共有アプリケーション・モジュール・インスタンスでビュー・オブジェクトを共有する場合は、共有アプリケーション・モジュールと同じパッケージにビュー・オブジェクトを作成する必要があります。 |
読取り専用ビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能なビュー・オブジェクトの作成ウィザードを使用します。
参照表のベース・ビュー・オブジェクトを作成するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成する作成済の共有アプリケーション・モジュールを特定し、そのパッケージ・ノードを右クリックして、「新規」を選択します。
「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択します。次に「ビュー・オブジェクト」を選択し、「OK」を選択します。
ビュー・オブジェクトの作成ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。
パッケージに名前を付ける場合は、別の参照用パッケージを作成することを検討してください。
「SQL問合せによる読取り専用アクセス 」を選択して、このビュー・オブジェクトが読取り専用アクセスでデータを管理することを指定し、「次へ」をクリックします。
「問合せ」ページの「問合せ文」ボックスに、SQL文を直接入力します。
参照表の列の問合せ名は、図10-2に示すSQL文のようになります。この文では、LOOKUP_CODES表のLOOKUP_CODE列、MEANING列およびDESCRIPTION列を問い合せます。
問合せ文を入力したら、他の変更は必要ありません。「次へ」をクリックします。
「バインド変数」ページで、「次へ」をクリックします。
「属性マッピング」ページで、表示されているマップされたビュー・オブジェクト属性名をメモし、「次へ」をクリックします。
デフォルトでは、ウィザードによってSELECTリスト列名に対応するJavaに適したビュー・オブジェクト属性名が作成されます。
「属性の設定」ページでは、「属性の選択」ドロップダウンを使用して、問合せ表の主キーに対応する属性を選択し、「キー属性 」チェックボックスを有効にします。
読取り専用のビュー・オブジェクトはエンティティ・オブジェクトには基づいていないため、ビュー・オブジェクトの作成ウィザードはデフォルトではキー属性を定義しません。キー属性を定義しなかった場合、読取り専用ビュー・オブジェクト・コレクションに基づくデータを持つADF Facesコンポーネントが、実行時に予期しない動作をするこことがあります。読取り専用ビュー・オブジェクトの場合は、図10-3のようにキー属性を定義します。
各属性に適した名前を使用するために属性名を変更する場合、「属性の選択」ドロップダウンから属性を選択し、該当する名前を「名前」フィールドに入力します。終了したら、「次へ」をクリックします。
たとえば、Fusion Order Demoアプリケーションでは、デフォルト属性LookupTypeおよびLookupCodeは、それぞれTypeおよびValueに名前が変更されます。ビュー・オブジェクト定義に変更を加えても、基礎となる問合せは変更されません。
「Java」ページで、「次へ」をクリックします。
「アプリケーション・モジュール」ページでは、ビュー・オブジェクトのインスタンスをアプリケーション・モジュールのデータ・モデルに追加しません。「終了」をクリックします。
共有アプリケーション・モジュールのデータ・モデルは、ベース・ビュー・オブジェクト定義に追加するビュー基準に基づくビュー・インスタンスを含みます。これにより、LOOKUP_TYPE値を問合せするたびに個別にビュー・オブジェクトを作成する必要はありません。データ・モデルへのビュー・オブジェクト・インスタンスの追加の詳細は、9.2.3.2項「アプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。
参照表のビュー・オブジェクト定義を作成する際、JDeveloperでは最初にSELECTリストの列から次を推測する問合せが記述されます。
Javaに適したビュー属性名(LOOKUP_TYPEのかわりにLookupTypeなど)
デフォルトでは、ウィザードによってSELECTリスト列名に対応するJavaに適したビュー・オブジェクト属性名が作成されます。
各属性のSQLおよびJavaデータ型
次に、JDeveloperでビュー・オブジェクトの宣言設定を表すXMLコンポーネント定義ファイルが作成され、そのパッケージの名前に対応するディレクトリ内に格納されます。たとえば、lookupsパッケージのLookupsBaseVOという名前のビュー・オブジェクトに対して作成されたXMLファイルは、プロジェクトのソース・パスの./lookups/LookupsBaseVO.xmlになります。
ビュー・オブジェクト設定を表示するには、アプリケーション・ナビゲータで目的のビュー・オブジェクトを展開し、展開されたビュー・オブジェクトのXMLファイルを選択して、構造ウィンドウを開きます。構造ウィンドウは、SQL問合せや各属性のプロパティなど定義のリストを表示します。エディタでファイルを開くには、対応する.xmlノードをダブルクリックします。例10-3に示すように、LookupsBaseVO.xmlファイルでは、マップされた各列に<SQLQuery>定義および<ViewAttribute>定義を1つずつ定義します。問合せ結果をフィルタするビュー基準がないと、ビュー・オブジェクト問合せによりLOOKUP_CODE、LOOKUP_MEANINGおよびLOOKUP_DESCRIPTIONが返され、それぞれValue、Name、Descriptionのビュー・インスタンス属性値にマップされます。ベース・ビュー・オブジェクト・コレクションがADF Facesコンポーネントにバインドされている場合に適切な行セットのナビゲーションを行うように、キー属性を定義します。
例10-3 LookupsBaseVO SQL問合せおよび属性マッピング定義
<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句条件をカッコで囲む論理積は必要ありません。
検索ビュー・オブジェクトのLOOKUP_TYPEビュー基準を作成するには:
アプリケーション・ナビゲータで、定義した検索ベース・ビュー・オブジェクトをダブルクリックします。
概要エディタで、「問合せ」ナビゲーション・タブをクリックします。
「問合せ」ページで、「ビュー基準」セクションを展開して「新規ビュー基準の作成」ボタンをクリックします。
「ビュー基準」ページの「ビュー基準の作成」ダイアログで、「アイテムの追加」ボタンをクリックしてビュー基準グループに基準アイテムを1つ追加します。
「基準アイテム」パネルで、次のように基準項目を定義します。
属性として「型」(またはビュー・オブジェクトがLOOKUP_TYPE列にマップする属性に定義した他の名前)を選択します。
演算子として「次と等しい」を選択します。
オペランドの選択を「リテラル」のままにして、目的の型を定義する値の名前を入力します。たとえば、配偶者の有無コードを問い合せるには、LOOKUP_TYPE列に対応する値MARITAL_STATUS_CODEを入力します。
その他の設定はすべて変更しません。
エディタに表示されるビュー・オブジェクトのWHERE句には、図10-4に示すようにシンプルな基準が表示されます。値MARITAL_STATUS_CODEはLOOKUP_TYPE列をフィルタするように設定されます。
「OK」をクリックします。
問い合せるLOOKUP_TYPEごとに1つのビュー基準を定義するには、この手順を繰り返します。
JDeveloperの 「ビュー基準の作成」ダイアログで、ビュー基準を簡単に作成し、名前付き定義として保存できます。これらの名前付きビュー基準定義により、メタデータがターゲット・ビュー・オブジェクト独自の定義に追加されます。定義すると、名前付きビュー基準はビュー・オブジェクトの概要エディタの「問合せ」ページに名前で表示されます。
次に、JDeveloperでビュー・オブジェクトの宣言設定を表すXMLコンポーネント定義ファイルが作成され、そのパッケージの名前に対応するディレクトリ内に格納されます。たとえば、lookupsパッケージのLookupsBaseVOという名前のビュー・オブジェクトに対して作成されたXMLファイルは、プロジェクトのソース・パスの./lookups/LookupsBaseVO.xmlになります。
ビュー基準を表示するには、アプリケーション・ナビゲータで目的のビュー・オブジェクトを展開し、展開されたビュー・オブジェクトのXMLファイルを選択して、構造ウィンドウを開き、「ビュー基準」ノードを展開します。例10-4に示すように、LookupsBaseVO.xmlファイルでは、LookupsBaseVOに配偶者の有無のタイプのみ戻す<ViewCriteria>定義を指定します。簡潔にするため、この例ではLookupsBaseVOに追加された他のビュー基準は省略されています。
例10-4 検索ビュー・オブジェクト定義のlistMaritalStatusTypesビュー基準
<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.fodemo.storefront.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ビジネス・コンポーネントのビュー・アクセッサは、エンティティ・オブジェクト属性(またはビュー・オブジェクト)から、同じアプリケーション・ワークスペースのリンク先ビュー・オブジェクトまたは共有ビュー・インスタンスをポイントする、値のアクセッサ・オブジェクトです。ビュー・アクセッサにより、デフォルトですべての行を含む行セットがリンク先ビュー・オブジェクから戻されます。ビュー・アクセッサにビュー基準を適用することにより、必要に応じてこの行をフィルタできます。ビュー・アクセッサおよびリンク先ビュー・オブジェクトを作成する場合のベース・エンティティ・オブジェクトまたはビュー・オブジェクトは、同じプロジェクトまたはアプリケーション・モジュールにある必要はありませんが、同じアプリケーション・ワークスペースにある必要があります。
ビュー・アクセッサはアプリケーション・モジュール全体に到達し、問合せデータにアクセスできる柔軟性を備えているため、共有アプリケーション・モジュールのビュー・インスタンスへのアクセスに理想的です。共有アプリケーション・モジュールでビュー・インスタンスのデータ・モデルを作成する方法の詳細は、10.2.1項「共有アプリケーション・モジュール・インスタンスの作成方法」を参照してください。
異なるアプリケーション・モジュールのビュー・オブジェクトにアクセスするこの機能により、ビュー・アクセッサは次の場合に特に便利です。
エンティティ・オブジェクトの属性に設定する検証規則。この場合、ビュー・アクセッサにより共有アプリケーション・モジュールのビュー・インスタンス属性に対応する検索データから検証規則の値が導出されます。
ビュー・オブジェクトの属性に対して有効にする値リスト(LOV)。この場合、ビュー・アクセッサにより共有アプリケーション・モジュールのビュー・インスタンス属性に対応する検索データから値リストが導出されます。
アクセッサによる検証規則は、ユーザーに対するUIに値リストを表示させない場合に便利ですが、有効値のリストは制限する必要があります。ビュー・オブジェクト属性のLOVを定義して、ユーザー・インタフェースでのリスト・コントロールを使用した作業を簡略化することもできます。ビジネス・コンポーネントの個々の属性にLOVを定義するため、属性に対してLOV使用をカスタマイズすると、属性が表示されるフォームでリスト・コントロールを参照できます。
エンティティ・ベースのビュー・オブジェクトは、そのベース・エンティティ・オブジェクトを定義するビュー・アクセッサを継承します。そのため、エンティティ・オブジェクト自体でビュー・アクセッサを一度定義すると、エンティティ・オブジェクト属性に検証規則を定義するか、そのエンティティ・オブジェクトのビュー・オブジェクトにLOV有効属性を作成するかに関係なく、同じビュー・アクセッサを再利用できます。ただし、検証規則にビュー・アクセッサを使用しない場合は、LOV有効属性を定義するビュー・オブジェクトにビュー・アクセッサを直接追加できます。
|
ベスト・プラクティス: アプリケーションでLOVが有効な属性を公開する必要がある場合は、一意のビュー・アクセッサを作成することをお薦めします。LOV結果は実行時にフィルタされることが多いため、複数の値リストを作成するためにビュー・アクセッサを再利用することはお薦めしません。たとえば、エンド・ユーザーが検索基準の適用を解除するまで、保存済の検索の結果により、ターゲット・ビュー・オブジェクトの行セットがフィルタされ続けます。したがって、この同じリンク先ビュー・オブジェクトに適用されるビュー・アクセッサの結果もフィルタされます。ビュー・アクセッサが実行時に常に意図された行セットを返すようにするには、使用するたびに一意のビュー・アクセッサを作成します。 |
エンティティ・オブジェクトに基づいて作成するビュー・オブジェクトはベース・エンティティ・オブジェクトのビュー・アクセッサを継承するため、エンティティ・オブジェクトに基づいてビュー・アクセッサを定義する際には注意が必要です。エンティティ・オブジェクト自体に基づいてビュー・アクセッサを一度定義する場合には同じビュー・アクセッサを再利用できますが、そのビュー・アクセッサを別のアプリケーション・シナリオで使用しないでください。エンティティ・オブジェクト属性に対する検証規則を定義し、そのエンティティ・オブジェクトのビュー・オブジェクトに対してLOV有効属性を作成する場合は、別々のビュー・アクセッサを作成することをお薦めします。
たとえばFusion Order DemoアプリケーションのStoreFrontModuleパッケージにあるAddressEOエンティティ・オブジェクトは、Shared_CountriesVAビュー・アクセッサを定義し、AddressesVOビュー・オブジェクトはこのビュー・アクセッサを継承します。この場合、エンティティ・オブジェクトに基づいてビュー・アクセッサを定義することは有用です。AddressEOに対するアクセッサはCountryId属性に対する検証規則を定義します。ただし、そのCountryId属性に対してLOVを有効にするには、AddressesVOに対する別のビュー・アクセッサを使用する必要があります。
共有アプリケーション・モジュールからビュー・インスタンスにアクセスするビュー・アクセッサを作成する場合は、ビュー・アクセッサの名前にShared_などの接頭辞を使用してください。エンティティ・オブジェクトまたはビュー・オブジェクトにビュー・アクセッサを選択する必要がある場合、このネーミング規則を使用すると、ビュー・アクセッサの識別が容易になります。
ビュー・オブジェクトで定義するビュー基準を適用することで、ビュー・アクセッサにより戻されるリストを再調整できます。ビュー・アクセッサで使用するビュー基準の作成方法は、10.3.3項「ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法」を参照してください。
ビュー・アクセッサを作成するには:
アプリケーション・ナビゲータで、ビュー・アクセッサを定義するエンティティ・オブジェクトまたはビュー・オブジェクトをダブルクリックします。
ビュー・アクセッサをエンティティ・オブジェクトで作成するか、ビュー・オブジェクトで作成するかは、ビュー・アクセッサの目的の用途に応じて決まります。通常は、エンティティ・オブジェクトでビュー・アクセッサを作成した方が幅広い用途に使用できます。
概要エディタで「ビュー・アクセッサ」 ナビゲーション・タブをクリックし、「新規ビュー・アクセッサの作成」ボタンをクリックして、現在編集中のエンティティ・オブジェクトまたはビュー・オブジェクト定義にアクセッサを追加します。
「ビュー・アクセッサ」ダイアログで、共有アプリケーション・モジュールのノードから参照表に作成したビュー・インスタンス名を選択し、ビュー・アクセッサ・リストに移動します。
たとえば、Fusion Order Demoアプリケーションの「ビュー・アクセッサ」ダイアログには、図10-5に示すように、共有アプリケーション・モジュールのLookupServiceAMとビュー・インスタンスのリストが表示されます。
このダイアログには、アプリケーションのビュー・オブジェクトおよびビュー・インスタンスがすべて表示されます。アプリケーション・モジュールの共有をまだ有効にしていない場合は、ビュー・インスタンスを選択する前に有効にする必要があります。詳細は、10.2.1項「共有アプリケーション・モジュール・インスタンスの作成方法」を参照してください。
デフォルトでは、作成されるビュー・アクセッサにはビュー・オブジェクト・インスタンスと同じ名前が表示されます(または、そのインスタンスを同名の子ビュー・オブジェクトと区別する必要がある場合は、整数が追加されます)。「アクセッサ名」を編集して一意の名前を付けることができます。
たとえば、図10-5の「ビュー・アクセッサ」ダイアログでは、共有アプリケーション・モジュールLookupServiceAMでAddressUsageTypesビュー・インスタンスを選択した場合に、ビュー・アクセッサSharedLookupService_AddressUsageTypesVAが表示されます。このビュー・アクセッサは、ベース・エンティティ・オブジェクトAddressUsagesEOで作成され、AddressUsageTypesビュー・インスタンスの行セットにアクセスします。
必要に応じて、既存のビュー基準を適用してアクセッサをフィルタする場合は、概要エディタでビュー・アクセッサを選択し、「編集」アイコンをクリックします。
「ビュー・アクセッサの編集」ダイアログで、「編集」をクリックして次の手順を実行し、ビュー基準を適用します。
適用するビュー基準を選択し、「選択済」リストに移動します。
追加のビュー基準を追加すると、複数のフィルタ(実行時に論理積(AND)演算子を実行)を適用できます。
ビュー・アクセッサの行セットに制御属性を定義するバインド変数の属性名を入力します。
ビュー・オブジェクトで直接設定するビュー基準(ビュー・インスタンスを作成する場合など)と異なり、ビュー・アクセッサのビュー基準の制御属性では、ビュー・アクセッサのベース・ビュー・オブジェクトから値が導出されます。
「OK」をクリックして、「ビュー・アクセッサ」ダイアログに戻ります。
「OK」をクリックします。
リンク先ビュー・オブジェクトの行セットにアクセスするために作成するビュー・アクセッサを使用して、実行時にエンド・ユーザーから求められるデータを検証できます。たとえば、エンド・ユーザーが登録フォームに記入する場合、個々の検証規則により肩書、配偶者の有無、連絡先コードを、共有アプリケーション・モジュールのビュー・インスタンスにより問合せされた参照表データに対して検証できます。
エンティティ・オブジェクトに定義したビュー・アクセッサをこれらの組込みの宣言的検証規則に適用できます。
Compare Validatorは、エンティティ属性と値の論理比較を実行します。使用可能な値を決定するためにビュー・アクセッサを指定する場合、Compare Validatorにより、選択するEquals、NotEquals、GreaterThan、LessThan、LessOrEqualTo、GreaterOrEqualToの各演算子が適用され、ビュー・アクセッサで戻された値と比較されます。
List Validatorにより、エンティティ属性と値リストが比較されます。有効なリスト値を決定するためにビュー・アクセッサを指定する場合、List Validatorにより、選択するInまたはNotIn演算子がビュー・アクセッサで戻された値に対して適用されます。
Collection Validatorは、コレクション属性について実行された演算と値の論理比較を実行します。使用可能な値を決定するためにビュー・アクセッサを指定する場合、Collection Validatorにより、選択されたコレクション属性にSum、Average、Count、Min、Maxの各演算が適用され、ビュー・アクセッサで戻された値と比較されます。
エンティティ・ベースのビュー・オブジェクトのデータを実行時に検証できるよう定義する検証規則は、常にエンティティ・オブジェクトの属性に定義されます。エンティティ・オブジェクト・エディタを使用して個々の属性に検証規則を定義します。定義された検証規則を持つエンティティ・オブジェクトから導出され、後で定義するビュー・オブジェクトは、属性値の検証を自動的に受け取ります。
作業を始める前に、次のようにします。
4.2.1項「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。
比較、リスト、またはコレクション・タイプのビュー・アクセッサに対する検証を行うには:
アプリケーション・ナビゲータで、目的のエンティティ・オブジェクトをダブルクリックします。
概要エディタで、「ビジネス・ルール」ナビゲーション・タブをクリックします。
「ビジネス・ルール」ページで、検証する属性を選択し、次に「新規バリデータの作成 」ボタンをクリックして、エンティティ・オブジェクトの属性を追加します。
「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「比較」、「リスト」、または「コレクション」を選択します。
バリデータの選択で必要な選択をします。
「比較」または「リスト・タイプ」ドロップダウン・リストで、「ビュー・アクセッサ属性」を選択します。
「ビュー・アクセッサ属性の選択」グループ・ボックスで、共有サービスから目的のビュー・アクセッサを展開し、検証として提供する属性を選択します。
図10-6は、List Validatorを使用してビュー・アクセッサ属性を選択する場合のダイアログを示しています。
「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるメッセージを入力します。
「OK」をクリックします。
Listバリデータを使用すると、<ListValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。例10-5は、Addressエンティティ・オブジェクトのCountryId属性のXMLコードを示しています。Listバリデータが使用され、Countriesビュー・インスタンスからビュー・アクセッサが取得した国IDのリストに対して、ユーザー入力が検証されます。
例10-5 View Accessorリスト・タイプを持つList ValidatorのXMLコード
<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>
リンク先ビュー・オブジェクトのビュー行にアクセスするために作成するビュー・アクセッサを使用して、実行時に値リストをエンド・ユーザーに表示できます。目的のビュー・インスタンスをデータソースとして使用してビュー・アクセッサを最初に作成すると、表示するビュー・オブジェクトのLOVが有効な属性にそのビュー・アクセッサを追加できます。ビュー・インスタンスの特定の参照属性をポイントするよう、LOVが有効な属性のビュー・アクセッサ定義を編集します。問合せでは、行セット・キャッシュに静的データを移入する必要があるため、共有アプリケーション・モジュールの関連先ビュー・インスタンスを特定します。
リストの使用方法は、UIリスト・コントロールにバインドされるビュー・オブジェクトの属性で定義されますが、ビュー・アクセッサ定義は、ビュー・オブジェクトまたはビュー・オブジェクトのベース・エンティティ・オブジェクトのいずれかに存在します。ビュー・オブジェクトのエンティティ・オブジェクトでビュー・アクセッサを作成するように選択した場合、ビュー・オブジェクトの概要エディタの「ビュー・アクセッサ」ページには、図10-7に示すように、継承されたビュー・アクセッサが表示されます。属性のビュー・オブジェクトでビュー・アクセッサを作成するように選択した場合は、概要エディタの「ビュー・アクセッサ」ページまたはLOV定義のエディタから実行できます。
LOV有効属性の使用方法の詳細は、5.12項「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
参照表から値を表示するLOVを作成するには:
アプリケーション・ナビゲータで該当する属性を含むビュー・オブジェクトを右クリックし、「開く」 ViewObjectNameを選択します。
概要エディタで、「ビュー・アクセッサ」ナビゲーション・タブをクリックします。
「ビュー・アクセッサ」ページで、ビュー・オブジェクトが目的のビュー・アクセッサをベース・エンティティ・オブジェクトから継承しているかどうかを確認します。ビュー・アクセッサがない場合は、目的のエンティティ・オブジェクトでビュー・アクセッサを作成するか、「新規ビュー・アクセッサの作成」ボタンをクリックして、現在編集中のビュー・オブジェクトにアクセッサを追加します。
定義する検証規則は、常にビュー・オブジェクトのベース・エンティティ・オブジェクトの属性に定義されます。このため、ビュー・アクセッサ・リストを使用してエンティティ・オブジェクト属性も検証することが明確な場合は、ベース・エンティティ・オブジェクトのレベルでビュー・アクセッサを定義すると便利です。
ビュー・アクセッサの作成の詳細は、10.4.1項「エンティティ・オブジェクトまたはビュー・オブジェクトのビュー・アクセッサの作成方法」を参照してください。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、LOVを表示する属性を選択し、「値リスト」セクションを展開して、「値リストの追加」ボタンをクリックします。
「値リスト」ダイアログで、「リスト・データソース」ドロップダウン・リストからビュー・アクセッサを選択します。
選択したビュー・アクセッサは、参照表のビュー・オブジェクト・インスタンスに作成したビュー・アクセッサになり、データソースとして使用されます。
次に、「リスト属性」ドロップダウン・リストで、このビュー・アクセッサから現在編集中の属性の値リストを戻す属性を選択します。
エディタにより、ビュー・オブジェクト属性とLOV有効属性との間のデフォルト・マッピングが作成されます。この場合、属性は同じになります。たとえば、OrdersViewビュー・オブジェクトの属性OrderIdは、Shared_OrdersVAビュー・アクセッサの属性OrderIdにマップされます。
必要に応じて、リストによりベース・ビュー・オブジェクトに戻される値を追加で指定する場合、「リスト戻り値」の「追加」アイコンをクリックし、目的のビュー・オブジェクト属性をビュー・アクセッサによりアクセスされた同じ属性にマップします。あわせて更新するため、属性のリスト選択をユーザーには要求せず、現在の行で決定している属性値を必要とする場合、追加属性の戻り値が便利です。
たとえば、OrdersViewビュー・オブジェクトの属性StartDateをマップするには、Shared_OrdersVAビュー・アクセッサの属性StartDateを選択します。リストが定義される属性のデフォルト属性マッピングは削除しないでください。
「OK」をクリックします。
LOVをビュー・オブジェクト属性に追加すると、ビュー・オブジェクトのXMLファイルは<ViewAttribute>要素のLOVNameプロパティで更新されます。LOVの定義は、新しい<ListBinding>要素に表示されます。例10-6のメタデータでは、MaritalStatusCode属性がLOVのMaritalStatusLOVを参照し、LOVを表示するchoiceコントロール・タイプを設定していることがわかります。MaritalStatusLOVのLOV定義は、<ListBinding>要素に表示されます。
例10-6 LOVリスト・バインディングXMLコードを持つビュー・オブジェクト
<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="CustomerRegistrationVO"
...
<ViewAttribute Name="MaritalStatusCode" IsNotNull="true" PrecisionRule="true"
EntityAttrName="MaritalStatusCode" EntityUsage="PersonEO"
AliasName="MARITAL_STATUS_CODE"
LOVName="MaritalStatusCodeLOV">
<Properties>
<SchemaBasedProperties>
<CONTROLTYPE Value="choice"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>
...
<ListBinding
Name="MaritalStatusLOV"
ListVOName="PersonEO.MaritalStatusVA"
ListRangeSize="-1"
NullValueFlag="start"
NullValueId="LOVUIHints_NullValueId"
MRUCount="0">
<AttrArray Name="AttrNames">
<Item Value="MaritalStatusCode"/>
</AttrArray>
<AttrArray Name="ListAttrNames">
<Item Value="Value"/>
</AttrArray>
<AttrArray Name="ListDisplayAttrNames">
<Item Value="Name"/>
</AttrArray>
<DisplayCriteria/>
<AttrArray Name="DerivedAttrNames"/>
</ListBinding>
...
</ViewObject>
ビュー・アクセッサが参照表から常に最新のデータを問い合せるようにする必要がある場合は、リンク先ビュー・オブジェクトで「自動リフレッシュ」プロパティを設定します。このプロパティにより、データベースが変更されると、ビュー・オブジェクト・インスタンスを自動的にリフレッシュできます。これは、リンク先ビュー・オブジェクトにビュー・アクセッサを定義する場合の一般的なユースケースです。
自動リフレッシュ機能はデータベースの変更通知機能を使用するため、ビュー・オブジェクトで自動リフレッシュを有効にする場合は、これらの制限事項に従ってください。
ビュー・オブジェクトで読取り専用の表の問合せを実行する場合は、表の数をできるだけ少なくしてください。これにより、パフォーマンスが最適化され、データベースで無効なキューが増大するのを防ぐことができます。
データベース・ユーザーには、データベースの通知権限を付与する必要があります。たとえば、SQL*Plusコマンドを使用して通知権限を付与するには、grant change notification to <ユーザー名>を使用します。
これらの制限事項に従うと、Oracleデータベースの変更通知機能によってリフレッシュが実行されます。フレームワークでは、ビュー・オブジェクトの問合せを実行する前に、データベース通知の問合せを登録するためのJDBC APIを使用します。通知が到着すると、アプリケーション・モジュールが次にチェックアウトするときに、対応するビュー・オブジェクト・インスタンスの行セットにリフレッシュのマークが付きます。共有アプリケーション・モジュールは次のチェックアウトまで待機するため、現在のトランザクションの行セットの状態が維持され、更新によってエンド・ユーザーの操作が妨げられることはありません。
たとえば、LOVに郵便番号リストが表示されており、データベース管理者が読取り専用の方法で管理していると仮定します。管理者が新しい郵便番号をデータベースの行として追加すると、共有アプリケーション・モジュールが残っているリクエストがない時を検出し、郵便番号リストにアクセスするビュー・インスタンスに対して保留中の通知がないことを判断します。その時点で、ビュー・オブジェクトはデータのリフレッシュを行い、それ以降のすべてのリクエストは新しい郵便番号を参照します。
共有アプリケーション・モジュールのビュー・インスタンスで自動リフレッシュを有効にするには:
アプリケーション・ナビゲータで、データベースの変更通知を受け取るビュー・オブジェクトをダブルクリックします。
「プロパティ・インスペクタ」で「データベース取得のチューニング」セクションを展開し、「自動リフレッシュ」プロパティで「True」を選択します。
ADFビジネス・コンポーネント実行時に、ビュー行およびエンティティ・オブジェクトの属性セッターに機能が追加され、LOVが有効な属性の動作が実現されます。ユーザー・インタフェースにLOVが有効な属性値を表示するために、LOVの機能によりデータソースをフェッチし、該当する行の属性とマップされたターゲット属性を検索します。
エンティティ・ベースのビュー・オブジェクトとは異なり、エキスパート・モードで作成する読取り専用ビュー・オブジェクトはデフォルトではキー属性を定義しません。キー属性を定義せずに読取り専用オブジェクトを作成することはできますが、エキスパート・モードでは問合せた表の主キーに対応する属性を選択し、キー属性としてマーキングしておくのがベスト・プラクティスです。キー属性があると、実行時に行セット・ナビゲーションを正しく動作させることができます。たとえば、ユーザー・インタフェース開発者は読取り専用ビュー・オブジェクト・コレクションに基づき、LOVコンポーネントを作成できます。行キー値を指定するキー属性がなければ、LOVが正しく機能せず、実行時エラーが発生することがあります。
ビュー・オブジェクトにより他のビュー・オブジェクトが拡張される場合、ベース・オブジェクトにLOVが有効な属性を作成できます。概要エディタで子ビュー・オブジェクトを定義すると、対応するビュー・オブジェクト属性にLOV定義が表示されます。この継承メカニズムにより、LOVが有効な属性を1回定義し、後で同じ属性の複数のビュー・オブジェクト・インスタンス全体にその属性を適用できます。他のビュー・オブジェクト定義からビュー・オブジェクトを拡張する方法の詳細は、37.8.2項「コンポーネントを作成後に拡張する方法」を参照してください。
また、概要エディタを使用して継承LOV定義を拡張できます。たとえば、ベース・ビュー・オブジェクトの問合せによりすでに定義されている属性を追加して、選択リストに表示できます。あるいは、カスタムのWHERE句を使用するビュー・オブジェクト・インスタンスを作成して、ベース・ビュー・オブジェクトによりまだ問合せされていない追加属性を問合せできます。エンティティ・ベース・ビュー・オブジェクトのカスタマイズの詳細は、5.10項「バインド変数の使用」を参照してください。
ビュー・オブジェクトにLOVが有効な属性を作成した場合、List Validatorを使用して属性を検証する必要はありません。ユーザー・インタフェースにリストを表示せず、有効値のリストを制限する必要がある場合のみ属性バリデータを使用します。List Validatorは、単純な静的リスト、または定義するビュー・アクセッサから取得した使用可能な値のリストです。UIに表示された属性がキー値(主キー、外部キー、または代替キー)を参照する属性の場合には、Key Exists Validatorを使用します。ADFビジネス・コンポーネントでの宣言的な検証の詳細は、第7章「検証とビジネス・ルールの宣言的な定義」を参照してください。
JDeveloperには、アプリケーション・ユーザー・インタフェースを使用せず、またはテスト・クライアントのプログラムを記述せずに、データ・モデルのすべての面をテストできるようにする、対話型アプリケーション・モジュール・テスト・ツールが用意されています。ビジネス・コンポーネント・ブラウザの実行は一般的には、開発時にビジネス・サービスのデータ機能を実行する最も迅速な方法です。
アプリケーション・モジュールは、ビジネス・コンポーネント・ブラウザ(またはUIクライアント)がアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールで使用される一連のビュー・オブジェクトは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。ビジネス・コンポーネント・ブラウザを使用して、定義したアクセッサが予測どおりに検証結果を出して、正しいLOV属性値を表示するかテストできます。
アプリケーション・モジュールを作成するには、「新規ギャラリ」から使用できるアプリケーション・モジュールの作成ウィザードを使用します。詳細は、9.2項「アプリケーション・モジュールの作成と変更」を参照してください。
アプリケーション・モジュールに追加したビュー・オブジェクトをテストするには、アプリケーション・ナビゲータからアクセスできるビジネス・コンポーネント・ブラウザを使用します。
アプリケーション・モジュール構成でビュー・オブジェクトをテストするには:
アプリケーション・ナビゲータで、目的のアプリケーション・モジュールおよびビュー・オブジェクトを含むプロジェクトを展開します。
アプリケーション・モジュールを右クリックし、「実行」を選択します。
または、デバッグを有効にしたビジネス・コンポーネント・ブラウザでアプリケーションを実行する場合は「デバッグ」を選択します。たとえば、ビジネス・コンポーネント・ブラウザを使用してデバッグする場合、ステータス・メッセージと例外を表示し、ソース・コードをステップ・インおよびステップ・アウトし、ブレークポイントを管理できます。JDeveloperにより、ログ・ウィンドウのデバッガ・プロセス・パネルおよび各種デバッガ・ウィンドウが開きます。
ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを受信する方法の詳細は、6.3.8項「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。
「ビジネス・コンポーネント構成の選択」ダイアログで、「ビジネス・コンポーネントの構成名」リストから目的のアプリケーション・モジュール構成を選択し、ビジネス・コンポーネント・ブラウザを実行します。
デフォルトでは、アプリケーション・モジュールには、AppModuleNameLocalおよびAppModuleNameSharedという名前のデフォルトの構成のみがあります。アプリケーション・モジュール用として別の追加構成を作成してある場合、かわりにこれらの1つを使用してアプリケーション・モジュールをテストするには、「接続」をクリックする前に、「接続」ダイアログの「ビジネス・コンポーネントの構成名」ドロップダウン・リストから目的の構成を選択します。
「接続」をクリックし、選択した構成を使用してアプリケーション・モジュールを起動します。
ビジネス・コンポーネント・ブラウザでビュー・オブジェクトを実行するには、ツリー・リストを展開し、目的のビュー・オブジェクト・ノードをダブルクリックします。
ビュー・オブジェクト・インスタンスはすでにテスト・セッションで実行されているように表示される場合があります。この場合、右側のテスター・パネルには、図10-8で示しているように、すでにビュー・オブジェクト・インスタンスの問合せ結果が表示されています。読取り専用ビュー・オブジェクトのテスター・パネルのフィールドは、そのビュー・オブジェクトで表されるデータが編集できないため、常に無効として表示されます。
ビュー・オブジェクト属性に作成したLOVをテストするには、アプリケーション・ナビゲータからアクセスできるビジネス・コンポーネント・ブラウザを使用します。ビジネス・コンポーネント・ブラウザの表示およびサポートされるコントロール・タイプの詳細は、5.12.7項「ビジネス・コンポーネント・ブラウザを使用したLOVが有効な属性のテスト方法」を参照してください。
ビジネス・コンポーネント・ブラウザを起動する場合、JDeveloperでは別のプロセスでテスター・ツールが起動され、ビジネス・コンポーネント・ブラウザが表示されます。ダイアログの左側のツリーには、アプリケーション・モジュールのデータ・モデルのすべてのビュー・オブジェクト・インスタンスが表示されます。図10-8は、展開されたツリーにProductImagesと呼ばれるインスタンス1つのみを示しています。目的のビュー・オブジェクト・インスタンスをダブルクリックすると、図10-8に示しているように、問合せ結果を検査するパネルがビジネス・コンポーネント・ブラウザに表示されます。
データは編集できないため、表示する読取り専用のビュー・オブジェクトすべてに対して、テスト・パネルは無効になっています。ただし、読取り専用のビュー・オブジェクトの場合でも、ツールはいくつかの有用な機能を備えています。
「ラベル・テキスト」のコントロール・ヒントに基づいたUIヒント、およびフォーマット・マスクが正しく定義されているかどうかを検証できます。
ツールバー・ボタンを使用してデータのスクロールもできます。
6.3.2項「エンティティ・ベースのビュー・オブジェクトの対話的テスト方法」で説明しているように、行の挿入、更新および削除をシミュレートできるエンティティ・ベースのビュー・オブジェクトを作成する場合、ビジネス・コンポーネント・ブラウザのほうが便利です。
アプリケーション・スコープを備えた共有アプリケーション・モジュールがLOVによりリクエストされると、その使用方法のためADFビジネス・コンポーネント実行時にApplicationPoolオブジェクトが作成されます。ビジネス・コンポーネント・プロジェクト・ファイル(.jpx)に定義された共有使用方法ごとにApplicationPoolは1つのみ作成されます。その後、実行時にApplicationPoolが使用され、データの取得にユーザー・アプリケーション・モジュールのように使用されるアプリケーション・モジュール・インスタンスが取得されます。共有アプリケーション・モジュール・インスタンスへの参照は、アプリケーション・スコープのアプリケーション・モジュールがリセットされると、解放されます。モジュール参照は、管理されていない解放の実行時またはセッション・タイムアウトで常に解放されます。
共有アプリケーション・モジュールのデータ・キャッシュは複数のスレッドでアクセスされるため、イテレータのスペースを分割して異なるセッションのイテレータ間の競合を回避する必要があります。これにより、あるセッションからの次のリクエストによって、別のセッションで使用中のイテレータの状態が変更されることはなくなります。実行時に、単一のRowSetの上部の複数のイテレータに対してADFビジネス・コンポーネントのサポートを受け、これらの競合を回避します。したがって、実行時に各RowSetのアクティブ・セッションと同じ数のイテレータがインスタンス化されます。
アプリケーション・スコープの共有アプリケーション・モジュール・ライフサイクルはApplicationPoolオブジェクトで管理されるアプリケーション・モジュールのライフサイクルと類似しています。たとえば、すべてのアクティブ・セッションがその共有アプリケーション・モジュールを解放すると、アプリケーション・モジュールはApplicationPoolオブジェクトにより収集されるガベージになります。共有プールは、特定のアプリケーション要件を満たすようにチューニングできます。
セッション・スコープの共有アプリケーション・モジュールは、ルートのユーザー・アプリケーション・モジュールのデータ・モデル内で、ネストされたアプリケーション・モジュール・インスタンスとして単純に作成されます。ネストされたアプリケーション・モジュールの詳細は、9.4項「ネストされたアプリケーション・モジュールの定義」を参照してください。
