Oracle® Fusion Middleware

Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

12c (12.2.1.1.0)

E77397-02(原本部品番号:E67042-03)

2016年8月

ADFビジネス・コンポーネント、ADFタスク・フローおよびADF Facesを使用するWebベース・アプリケーションの開発およびデプロイ方法について説明する、Oracle Application Development Framework (Oracle ADF)の開発者のためのドキュメント。

Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発, 12c (12.2.1.1.0)

E77397-02

Copyright © 2013, 2016, Oracle and/or its affiliates.  All rights reserved.

原本著者: Ralph Gordon (リード)、Vaibhav Gupta、Sandhya Hombardi、Ayonee Sengupta、Sandhya Sriram、Alyona Stashkova、Sreejith Unnikrishnan

原本協力者: Lynn Munsinger

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

リリース12cにおけるこのマニュアルの新機能 (12.2.1.1.0)

- リリース12c (12.2.1.1.0)の新機能と変更された機能

- リリース12c (12.2.1.1.0)に関するこのドキュメントにおけるその他の大きな変更

第I部 Fusion Webアプリケーションのスタート・ガイド

1 Oracle ADFを使用したFusion Webアプリケーションの構築の概要

- 1.1 Oracle ADFの概要

- 1.2 Oracle ADFアーキテクチャ

- 1.3 Oracle ADFによるアプリケーションの構築の概要

- 1.3.1 アプリケーション・ワークスペースの作成

- 1.3.2 データベース・オブジェクト定義によるモデリング

- 1.3.3 ユースケースの作成

- 1.3.4 ADFタスク・フローを使用したアプリケーション・コントロールおよびナビゲーションの設計

- 1.3.5 共有リソースの識別

- 1.3.6 ADFビジネス・コンポーネントを使用してデータにアクセスするデータ・モデルの作成

- 1.3.6.1 表のビジネス・ドメイン・オブジェクトのレイヤーの作成

- 1.3.6.2 ビジネス・サービスの構築

- 1.3.6.3 Oracle ADFモデル・テスターによるビジネス・サービスのテストとデバッグ

- 1.3.7 JSFによるユーザー・インタフェースの実装

- 1.3.8 ADFモデルのデータバインディング

- 1.3.9 検証およびエラー処理

- 1.3.10 セキュリティの追加

- 1.3.11 Webクライアント・アプリケーションのテストとデバッグ

- 1.3.12 アプリケーション・アーティファクトのリファクタ

- 1.3.13 Fusion Webアプリケーションのデプロイ

- 1.3.14 Fusion Webアプリケーションの統合

- 1.4 チーム作業による生産性の向上

- 1.4.1 標準の適用

- 1.4.2 ソース・コントロール・システムの使用

- 1.5 Oracle JHeadstartを使用した、完全なWeb階層の生成

- 1.6 Oracle ADFの学習に関する他のリソース

2 ADFサンプル・アプリケーションの概要

- 2.1 Oracle ADF用Summitサンプル・アプリケーションについて

- 2.2 Oracle ADF用Summitサンプル・アプリケーションの設定

- 2.2.1 アプリケーション・リソースのダウンロード方法

- 2.2.2 Summit ADFスキーマのインストール方法

- 2.2.3 Summit ADFスキーマのインストール時の処理

- 2.2.4 Oracle ADF用Summitサンプル・アプリケーションのデータベース接続の作成方法

- 2.3 SummitADFワークスペースでのコアSummit ADFサンプル・アプリケーションの実行

- 2.3.1 コアSummit ADFサンプル・アプリケーションの実行方法

- 2.3.2 SummitADFワークスペースにおけるサンプル・アプリケーションの考察

- 2.3.2.1 アプリケーションの参照

- 2.3.2.1.1 顧客リストの参照

- 2.3.2.1.2 顧客の検索

- 2.3.2.1.3 顧客の詳細の表示

- 2.3.2.1.4 注文の詳細の表示

- 2.3.2.2 注文プロセス

- 2.4 SummitADF_Examplesワークスペースからのスタンドアロン・サンプルの実行

- 2.4.1 Summit ADFスタンドアロン・サンプル・アプリケーションの実行方法

- 2.4.1.1 Javaテスト・クライアントからのスタンドアロン・サンプル・アプリケーションの実行

- 2.4.1.2 テスト・クライアントなしのスタンドアロン・アプリケーションの実行

- 2.4.2 Summit ADFスタンドアロン・サンプル・アプリケーションの概要

- 2.5 SummitADF_TaskFlowsワークスペースでのサンプル・アプリケーションの実行

- 2.5.1 ADFタスク・フローのSummitサンプル・アプリケーションの実行方法

- 2.5.2 ADFタスク・フローのSummitサンプル・アプリケーションの概要

- 2.6 SummitADF_DVTワークスペースでのスタンドアロン・サンプルの実行

- 2.6.1 Summit ADF DVTスタンドアロン・サンプルの概要

- 2.6.2 Summit ADF DVTサンプル・アプリケーション・ページの実行方法

第II部 ビジネス・サービスの構築

3 ADFビジネス・コンポーネントのスタート・ガイド

- 3.1 ADFビジネス・コンポーネントについて

- 3.1.1 ADFビジネス・コンポーネントのユースケースと例

- 3.1.2 ADFビジネス・コンポーネントの追加機能

- 3.2 ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成

- 3.2.1 ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成方法

- 3.2.2 既存のアプリケーションへのADFビジネス・コンポーネント・データ・モデル・プロジェクトの追加方法

- 3.2.3 データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法

- 3.2.4 オフライン・データベース・オブジェクトで作業するためのデータ・モデル・プロジェクトの変更方法

- 3.2.5 アプリケーション・サーバーまたはデータベース依存性に関する必知事項

- 3.2.6 ADFビジネス・コンポーネントのデータ型に関する必知事項

- 3.2.7 数値の表示に関する必知事項

- 3.2.8 ADFビジネス・コンポーネントのモデル・プロジェクト・プロパティのカスタマイズ方法

- 3.2.9 ADFビジネス・コンポーネント・プリファレンスのカスタマイズ方法

- 3.3 ビジネス・コンポーネントの作成および編集

- 3.3.1 ウィザードを使用した新規コンポーネントの作成方法

- 3.3.2 ポップアップ・メニューを使用した新規コンポーネントの作成方法

- 3.3.3 ビジネス・コンポーネント作成時の処理

- 3.3.4 モデル・プロジェクト組織に関する必知事項

- 3.3.5 パッケージの命名規則に関する必知事項

- 3.3.6 コンポーネントの名前変更に関する必知事項

- 3.3.7 コンポーネントの概要エディタを使用したコンポーネントの編集方法

- 3.4 ビジネス・コンポーネントのテスト、リファクタおよび仮想化

- 3.4.1 Oracle ADFモデル・テスターの使用方法 /

- 3.4.2 Oracle ADFソース・コードの取得に関する必知事項

- 3.4.3 データ・モデル・プロジェクトでのビジネス・コンポーネントの使用方法を検索する方法

- 3.4.4 データ・モデル・プロジェクトでビジネス・コンポーネントの依存性を探索する方法

- 3.4.5 データ・モデル・プロジェクトでのビジネス・コンポーネントのリファクタ方法

- 3.4.6 オフライン・データベース・オブジェクトのリファクタおよびビジネス・コンポーネントの更新方法

- 3.4.7 ダイアグラム使用による関連ビジネス・コンポーネントの表示方法

- 3.4.8 UMLダイアグラムの使用に関する必知事項

- 3.5 ビジネス・コンポーネントのカスタマイズ

- 3.5.1 ビジネス・コンポーネントJavaサブクラスの生成方法

- 3.5.2 ビジネス・コンポーネント・メソッドのクライアントへの公開方法

- 3.5.3 カスタム・クラス生成時の処理

- 3.5.4 カスタム・インタフェースのサポートに関する必知事項

- 3.5.5 汎用APIと強く型付けされたAPIの相違に関する必知事項

- 3.6 ビジネス・コンポーネントでのGroovyスクリプト言語の使用

- 3.6.1 ビジネス・コンポーネントにGroovy式を入力する方法

- 3.6.2 式を入力したときの処理

- 3.6.3 Groovyプロジェクトの設定に関する必知事項

- 3.6.4 Groovy式を使用できる場所に関する必知事項

- 3.6.5 Groovy式の構文に関する必知事項

- 3.6.5.1 Groovy式でのビジネス・コンポーネントの参照に関する必知事項

- 3.6.5.2 信頼できないGroovy式に関する必知事項

- 3.6.5.3 Groovy式でのカスタム・ビジネス・コンポーネント・メソッドと属性の参照に関する必知事項

- 3.6.5.3.1 同一のビジネス・コンポーネントのメンバーの参照

- 3.6.5.3.2 他のビジネス・コンポーネントのメンバーの参照

- 3.6.5.4 Groovy式でのビジネス・コンポーネント属性値の操作に関する必知事項

- 3.6.6 Groovyスニペットの移行に関する必知事項

4 エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成

- 4.1 エンティティ・オブジェクトについて

- 4.1.1 エンティティ・オブジェクトのユースケースと例

- 4.1.2 エンティティ・オブジェクトの追加機能

- 4.2 エンティティ・オブジェクトおよびアソシエーションの作成

- 4.2.1 既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法

- 4.2.2 「エンティティの作成」ウィザードで単一のエンティティ・オブジェクトを作成する方法

- 4.2.3 既存の表からのエンティティ・オブジェクトおよびアソシエーション作成時の処理

- 4.2.3.1 エンティティ・オブジェクトが表から導入されたときに生成された外部キー・アソシエーション

- 4.2.3.2 表に主キーがないときに生成されるエンティティ・オブジェクト・キー

- 4.2.4 シノニムまたはビューのエンティティ・オブジェクトの作成時の処理

- 4.2.5 既存のエンティティ・オブジェクトまたはアソシエーションの編集方法

- 4.2.6 エンティティ・オブジェクトからのデータベース表の作成方法

- 4.2.7 データベース表の変更とエンティティを同期化する方法

- 4.2.7.1 ドロップされた列に関連付けられた属性の削除

- 4.2.7.2 基礎となる表でのデータ型の変更処理

- 4.2.8 特定の時点に関するデータを格納する方法

- 4.2.9 有効日が指定されたエンティティ・オブジェクトの作成時の処理

- 4.2.10 表からのエンティティの作成に関する必知事項

- 4.3 アソシエーションの作成および構成

- 4.3.1 アソシエーションの作成方法

- 4.3.2 アソシエーション作成時の処理

- 4.3.3 エンティティ・アソシエーションのアクセッサ名の変更方法

- 4.3.4 アソシエーションの名前変更および別のパッケージへの移動方法

- 4.3.5 アソシエーションでのカスタム・ビュー・オブジェクトの使用に関する必知事項

- 4.3.6 コンポジット・アソシエーションに関する必知事項

- 4.4 ビジネス・レイヤーのエンティティ・オブジェクトの図の作成

- 4.4.1 ビジネス・コンポーネント・ダイアグラムでのエンティティ・オブジェクトの表示方法

- 4.4.2 エンティティ・ダイアグラム作成時の処理

- 4.4.3 XMLコンポーネント・ディスクリプタに関する必知事項

- 4.4.4 コンポーネント名の変更に関する必知事項

- 4.5 プロパティ・セットの定義

- 4.5.1 プロパティ・セットの定義方法

- 4.5.2 プロパティ・セットの適用方法

- 4.6 エンティティ・オブジェクトの属性のコントロール・ヒントの定義

- 4.6.1 属性のコントロール・ヒントの追加方法

- 4.6.2 属性のコントロール・ヒント追加時の処理

- 4.6.3 フォーマッタとマスクについて

- 4.6.4 フォーマット・マスクの定義方法

- 4.7 リソース・バンドルの使用

- 4.7.1 メッセージ・バンドル・オプションの設定方法

- 4.7.2 複数のリソース・バンドルの使用方法

- 4.7.3 日付フォーマットの国際化方法

- 4.8 ビジネス・ロジック・グループの定義

- 4.8.1 ビジネス・ロジック・グループの作成方法

- 4.8.2 ビジネス・ロジック・ユニットの作成方法

- 4.8.3 ビジネス・ロジック・ユニットへのロジックの追加方法

- 4.8.4 ビジネス・ロジック・ユニットの属性のオーバーライド方法

- 4.8.5 ビジネス・ロジック・グループの作成時の処理

- 4.8.6 実行時の処理: ビジネス・ロジック・グループの呼出し方法

- 4.9 宣言的な実行時動作の構成

- 4.9.1 宣言的な実行時動作の構成方法

- 4.9.2 宣言的な実行時動作の構成時の処理

- 4.9.3 バッチ更新の使用方法

- 4.10 属性プロパティの設定

- 4.10.1 エンティティ・オブジェクト属性のデータベースおよびJavaデータ型を設定する方法

- 4.10.2 データ型の長さ、精度およびスケールの指定方法

- 4.10.3 属性の更新可能性の制御方法

- 4.10.4 属性を必須化する方法

- 4.10.5 エンティティの主キーの定義方法

- 4.10.6 静的なデフォルト値を定義する方法

- 4.10.7 式を使用してデフォルト値を定義する方法

- 4.10.8 Groovy式を使用したデフォルト値の作成時の処理

- 4.10.9 トリガーによって割り当てられた値を同期化する方法

- 4.10.10 トリガーによってデータベース順序から割り当てられた主キー値の取得方法

- 4.10.11 主キー値の変更に関する必知事項

- 4.10.12 同時更新によるデータの消失を防ぐ方法

- 4.10.13 履歴列を使用して作成および変更した日付を追跡する方法

- 4.10.14 コンポジット動作の構成方法

- 4.10.14.1 新しく構成されるエンティティ・オブジェクトでの親のない行の保護

- 4.10.14.2 データベースに保存される変更の順序付け

- 4.10.14.3 Refresh-On-Insert主キーからの構成される側の詳細エンティティのカスケード更新

- 4.10.14.4 カスケード削除のサポート

- 4.10.14.5 主キーの変更時の外部キー属性のカスケード更新

- 4.10.14.6 コンポジット親エンティティ・オブジェクトのロック

- 4.10.14.7 コンポジット・エンティティ・オブジェクトでのバッチ更新の使用

- 4.10.14.8 構成する側の親の履歴属性の更新

- 4.10.15 エンティティ・オブジェクト継承階層の識別子属性の設定方法

- 4.10.16 代替キー値の定義方法

- 4.10.17 代替キー値定義時の処理

- 4.10.18 代替キー値に関する必知事項

- 4.11 エンティティ・オブジェクトへの一時属性および計算属性の追加

- 4.11.1 一時属性の追加方法

- 4.11.2 一時属性の追加時の処理

- 4.11.3 Groovy式に準拠した一時属性の作成方法

- 4.11.4 Groovy式に準拠した一時属性の作成時の処理

- 4.11.5 エンティティ・クラスへの計算実行用Javaコードの追加方法

- 4.12 ビジネス・イベントの作成

- 4.12.1 イベントの定義

- 4.12.2 イベント・ポイント

- 4.12.3 イベント・ポイントに関する必知事項

- 4.12.4 ビジネス・イベントの作成方法

- 4.12.5 ビジネス・イベント作成時の処理内容

- 4.12.6 ペイロードに関する必知事項

- 4.12.7 ビジネス・イベントの公開ポイントの定義方法

- 4.12.8 ビジネス・イベントをサブスクライブする方法

- 4.13 エンティティ・オブジェクトのカスタムJavaクラスの生成

- 4.13.1 カスタム・クラスの生成方法

- 4.13.2 カスタム・クラス生成時の処理

- 4.13.3 エンティティ属性アクセッサの生成時の処理

- 4.13.4 カスタムJavaファイルの操作方法

- 4.13.5 カスタムJavaクラスに関する必知事項

- 4.13.5.1 エンティティ・オブジェクトのフレームワーク・ベース・クラス

- 4.13.5.2 カスタム・コンポーネント・ファイルに安全に追加する方法

- 4.13.5.3 デフォルトのJava生成設定の構成

- 4.13.5.4 属性索引およびInvokeAccessor生成コード

- 4.13.6 カスタム・エンティティ・クラス参照を使用した比較のプログラム的な例

- 4.14 エンティティ・オブジェクトおよびアソシエーションのプログラム的操作

- 4.14.1 主キーによるエンティティ・オブジェクトの検索方法

- 4.14.2 アクセッサ属性を使用して関連付けられたエンティティへのアクセス方法

- 4.14.3 既存のエンティティ行の更新または削除方法

- 4.14.4 新しいエンティティ行の作成方法

- 4.14.5 Oracle順序を使用した主キー値の割当て

- 4.14.6 行の削除にかわる削除済フラグを更新する方法

- 4.14.6.1 行が削除されたときの削除済フラグの更新

- 4.14.6.2 削除のかわりの更新DML操作の強制

- 4.14.7 制約違反を防ぐためのエンティティ・ポスト順序を制御する方法

- 4.14.7.1 デフォルトの後処理順序

- 4.14.7.2 コンポジットとデフォルトの後処理順序

- 4.14.7.3 ポスト順序を制御するためのpostChanges()のオーバーライド

- 4.14.7.3.1 実際のポスト順序の問題の観察

- 4.14.7.3.2 従業員より前に部門をポストを強制

- 4.14.7.3.3 DBSequenceの値が設定される主キーに基づくアソシエーション

- 4.14.7.3.4 DBSequence割当ての外部キーに対する参照の更新

- 4.14.8 エンティティ・アソシエーションの高度な手法

- 4.14.8.1 複雑なアソシエーションを実装するためのアソシエーションSQL句の変更

- 4.14.8.2 エンティティ・レベルでのビュー・リンク・アクセッサ属性の公開

- 4.14.9 カスタム・エンティティ・オブジェクトのメソッドに関する必知事項

- 4.15 カスタム・データ・ソースおよびFramework Base Class ProgrammaticEntityImplを使用したプログラム的操作

- 4.15.1 ProgrammaticEntityImplを拡張してエンティティ・オブジェクト・クラスを作成する方法

- 4.15.2 ProgrammaticEntityImplベースのエンティティ・オブジェクト用にオーバーライドする主要なフレームワーク・メソッド

- 4.16 ドメインを使用したカスタム検証済データ型の作成

- 4.16.1 ドメインの作成方法

- 4.16.2 ドメインの作成時の処理

- 4.16.3 ドメインに関する必知事項

- 4.16.3.1 エンティティ・オブジェクトおよびビュー・オブジェクトの属性としてのドメイン

- 4.16.3.2 カスタムvalidate()メソッドのDataCreationException

- 4.16.3.3 StringドメインとString値集約

- 4.16.3.4 簡単なドメインと組込みデータ型

- 4.16.3.5 不変なJavaクラスとしての単純なドメイン

- 4.16.3.6 Oracleオブジェクト型に対するドメインの作成

- 4.16.3.7 共通JARにパッケージ化されたドメイン

- 4.16.3.8 エンティティ・オブジェクトとビュー・オブジェクトにおけるカスタム・ドメイン・プロパティと属性

- 4.16.3.9 エンティティ・オブジェクトとビュー・オブジェクトにおけるドメインの継承された制限プロパティ

- 4.17 新規履歴タイプの作成

- 4.17.1 新規履歴タイプの作成方法

- 4.17.2 履歴タイプの削除方法

- 4.18 PL/SQLパッケージAPIに基づくエンティティ・オブジェクト

- 4.18.1 ビューを基にしてエンティティ・オブジェクトを作成する方法

- 4.18.2 ビューを基にしてエンティティ・オブジェクトを作成するときに行われる処理

- 4.18.3 PL/SQLベースのエンティティに関する詳細をベース・クラスに集中化する方法

- 4.18.4 DML操作のストアド・プロシージャ呼出しを実装する方法

- 4.18.5 選択処理およびロック処理を追加する方法

- 4.18.5.1 ロックと選択を処理するためのPLSQLEntityImplベース・クラスの更新

- 4.18.5.2 Productエンティティに対するロックおよび選択の実装

- 4.18.5.3 RowInconsistentException後のエンティティ・オブジェクトのリフレッシュ

- 4.19 結合ビューまたはリモートDBLinkに基づくエンティティ・オブジェクト

- 4.19.1 RETURNING句の使用を無効にする方法

- 4.19.2 実行時の処理: RETURNING句が無効な場合のリフレッシュ動作

- 4.20 ビジネス・ドメイン・レイヤーでの継承の使用

- 4.20.1 継承が有効な状況の理解

- 4.20.2 継承階層内にエンティティ・オブジェクトを作成する方法

- 4.20.2.1 識別子列と個別の値の識別

- 4.20.2.2 エンティティの種類に関連する属性のサブセットの識別

- 4.20.2.3 継承階層へのベース・エンティティ・オブジェクトの作成

- 4.20.2.4 継承階層へのサブタイプ・エンティティ・オブジェクトの作成

- 4.20.3 継承階層内のエンティティ・オブジェクトにメソッドを追加する方法

- 4.20.3.1 階層内の全エンティティ・オブジェクトに共通するメソッドの追加

- 4.20.3.2 サブタイプ・エンティティでの共通メソッドのオーバーライド

- 4.20.3.3 サブタイプ・エンティティ・オブジェクトに固有のメソッドの追加

- 4.20.4 継承の使用に関する必知事項

- 4.20.4.1 新しいベース・エンティティの導入

- 4.20.4.2 サブタイプ・エンティティ・オブジェクトとfindByPrimaryKey()メソッド

- 4.20.4.3 多相エンティティ・オブジェクトの慣用名を持つビュー・オブジェクト

5 ビュー・オブジェクトを使用したSQL問合せの定義

- 5.1 ビュー・オブジェクトについて

- 5.1.1 ビュー・オブジェクトのユースケースと例

- 5.1.2 ビュー・オブジェクトの追加機能

- 5.2 単一のデータベース表からのビュー・オブジェクト行の移入

- 5.2.1 エンティティ・ベースのビュー・オブジェクトの作成方法

- 5.2.1.1 エンティティ・オブジェクトのすべての属性を持つビュー・オブジェクトの作成

- 5.2.1.2 単一表からのエンティティ・ベースのビュー・オブジェクトの作成

- 5.2.2 エンティティ・ベースのビュー・オブジェクトの作成時の処理

- 5.2.3 更新不可のビュー・オブジェクトに関する必知事項

- 5.2.4 ビュー・オブジェクトの編集方法

- 5.2.4.1 基礎となるエンティティ・オブジェクト属性の継承プロパティのオーバーライド

- 5.2.4.2 概要エディタでのビュー・オブジェクトの属性表示のカスタマイズ

- 5.2.4.3 ビュー・オブジェクトのソース・ファイルの属性の順番の変更

- 5.2.5 ビジネス・コンポーネント・ダイアグラムでのビュー・オブジェクトの表示方法

- 5.3 宣言SQLモードでのビュー・オブジェクトの使用

- 5.3.1 宣言的SQLビュー・オブジェクトを作成する方法

- 5.3.2 表結合が適用された場合に宣言SQLベースのビュー・オブジェクトをフィルタリングする方法

- 5.3.3 宣言SQLモードでマスター/ディテール関連のビュー・オブジェクトをフィルタリングする方法

- 5.3.4 宣言SQLモードのビュー・オブジェクトにおけるプログラム実行をサポートする方法

- 5.3.4.1 宣言SQLモードのすべてのビュー・オブジェクトに対する属性問合せの強制実行

- 5.3.4.2 宣言SQLモードの特定のビュー・オブジェクトに対する属性問合せの強制実行

- 5.3.5 宣言SQLモードでビュー・オブジェクトを作成するときに行われる処理

- 5.3.6 実行時に行われる処理: 宣言SQLモードでのSQL

- 5.3.7 宣言SQLモードでのビュー・オブジェクトのプログラムによる処理に関する必知事項

- 5.4 静的データが移入されたビュー・オブジェクトの作成

- 5.4.1 入力したデータを使用して性的データ・ビュー・オブジェクトを作成する方法

- 5.4.2 インポートしたデータを使用して性的データ・ビュー・オブジェクトを作成する方法

- 5.4.3 静的データ・ビュー・オブジェクトの作成時の処理

- 5.4.4 静的データ・ビュー・オブジェクトを編集する方法

- 5.4.5 静的データ・ビュー・オブジェクトに関する必知事項

- 5.5 ビュー・オブジェクトへの計算属性および一時属性の追加

- 5.5.1 SQL計算属性の追加方法

- 5.5.2 SQL計算属性を追加するときに行われる処理

- 5.5.3 SQL計算属性に関する必知事項

- 5.5.4 一時属性の追加方法

- 5.5.5 エンティティ・オブジェクトによって定義された一時属性を追加する方法

- 5.5.6 一時属性への検証規則の追加方法

- 5.5.7 一時属性の追加時の処理

- 5.5.8 一時属性と計算値に関する必知事項

- 5.5.9 一時属性によって定義された主キーによるビュー・オブジェクト問合せに関する必知事項

- 5.6 有効日付範囲を使用したビュー・オブジェクト行の制限

- 5.6.1 有効日が指定されたビュー・オブジェクトの作成方法

- 5.6.2 有効日が指定されたビュー・オブジェクトを使用した新規ビュー行の作成方法

- 5.6.3 有効日が指定されたビュー行の更新方法

- 5.6.4 有効日が指定されたビュー行の削除方法

- 5.6.5 有効日が指定されたビュー・オブジェクトの作成時の処理

- 5.6.6 有効日が指定されたビュー・オブジェクトとビュー・リンクに関する必知事項

- 5.7 結合問合せ結果での複数表の使用

- 5.7.1 エンティティ・ベースのビュー・オブジェクトに対する結合の作成方法

- 5.7.2 必要に応じたデフォルトの結合句の外部結合への変更

- 5.7.3 参照エンティティ・オブジェクトの慣用名からの追加属性の選択方法

- 5.7.4 参照エンティティ・オブジェクトの慣用名からの不要なキー属性の削除方法

- 5.7.5 参照エンティティ・オブジェクトの慣用名の主キー属性を非表示にする方法

- 5.7.6 ビュー・オブジェクトの複数のエンティティを参照するときに行われる処理

- 5.7.7 外部結合に関する必知事項

- 5.7.8 エンティティ・ベースの結合とエンティティのカーディナリティに関する必知事項

- 5.7.9 エンティティ・ベースの結合と行削除サポートに関する必知事項

- 5.7.10 コンポジット・アソシエーションと結合に関する必知事項

- 5.7.11 読取り専用ビュー・オブジェクトに対する結合の作成方法

- 5.7.12 結合ビューのテスト方法

- 5.7.13 読取り専用オブジェクトに「SQL文」ダイアログを使用する方法

- 5.8 ビュー・オブジェクトとカスタムSQLの操作

- 5.8.1 カスタムSQLモード・ビュー・オブジェクトの作成方法

- 5.8.2 カスタムSQLビュー・オブジェクトの作成時に行われる処理

- 5.8.3 カスタムSQLモードでSQL文をカスタマイズする方法

- 5.8.4 カスタムSQLモードを有効にしたときに行われる処理

- 5.8.5 カスタムSQLモードに関する必知事項

- 5.8.5.1 カスタムSQLモードの計算式の属性名

- 5.8.5.2 カスタムSQLモードの属性マッピング支援

- 5.8.5.3 カスタムSQLモードのカスタム編集

- 5.8.5.4 カスタムSQLモードでのSQL式の変更

- 5.8.5.5 カスタムSQLモードでのエンティティ属性を変更するSQL計算

- 5.8.5.6 カスタムSQLモードのSQL文の書式設定

- 5.8.5.7 カスタムSQLモードの問合せ句

- 5.8.5.8 実行時のインライン・ビュー・ラッピング

- 5.8.5.9 依存オブジェクトに対するカスタムSQLの影響

- 5.8.5.10 ビュー・オブジェクト問合せの自動リフレッシュに対するカスタムSQLの影響

- 5.8.5.11 カスタムSQLモードの属性のSQLタイプ

- 5.9 名前付きビュー基準の処理

- 5.9.1 名前付きビュー基準を宣言的に作成する方法

- 5.9.2 名前付きビュー基準の作成時の処理

- 5.9.3 ビュー基準のバインド変数に関する必知事項

- 5.9.4 ネストされたビュー基準の式に関する必知事項

- 5.9.5 ビュー基準にユーザー・インタフェース・ヒントを設定して検索フォームをサポートする方法

- 5.9.6 Oracle ADFモデル・テスターを使用してビュー基準をテストする方法

- 5.9.7 ビュー基準を使用して現在のユーザーのビュー・オブジェクトをフィルタリングする方法

- 5.9.8 プログラムによるビュー基準の作成方法

- 5.9.9 実行時に行われる処理: ビュー基準がビュー・オブジェクトに適用される方法

- 5.9.10 ビュー基準APIに関する必知事項

- 5.9.10.1 ビュー基準での属性名の参照

- 5.9.10.2 ビュー基準でのバインド変数の参照

- 5.9.10.3 属性がNULLである行の検索

- 5.9.10.4 データ圧縮を使用した行の検索

- 5.9.10.5 属性値がリストの値に一致する行の検索

- 5.9.10.6 大/小文字を区別しない検索

- 5.9.10.7 有効なビュー基準のクリア

- 5.9.10.8 複数ビュー基準を使用した複合検索条件の変更

- 5.9.11 Query-By-Example基準に関する必知事項

- 5.10 バインド変数の使用

- 5.10.1 ビュー・オブジェクト定義にビュー基準のバインド変数を追加する方法

- 5.10.2 ビュー・オブジェクト定義にWHERE句のバインド変数を追加する方法

- 5.10.3 名前付きバインド変数の追加時の処理

- 5.10.4 名前付きバインド変数のテスト方法

- 5.10.5 実行時に名前付きバインド変数を含むWHERE句を追加する方法

- 5.10.6 実行時に既存のWHERE句のバインド変数値を設定する方法

- 5.10.7 実行時に行われる処理: 動的な読取り専用ビュー・オブジェクトのWHERE句

- 5.10.8 名前付きバインド変数に関する必知事項

- 5.10.8.1 バインド変数の名前に関連するエラー

- 5.10.8.2 バインド変数のNULLのデフォルト値

- 5.11 行検索の使用

- 5.11.1 ビュー・オブジェクト定義に行検索を追加する方法

- 5.11.2 行検索の定義時の処理

- 5.11.3 ビュー基準と行検索の使用方法に関する必知事項

- 5.11.4 プログラムによる行検索の呼出し

- 5.12 ビュー・オブジェクト属性の値リスト(LOV)での作業

- 5.12.1 単一のLOVが有効なビュー・オブジェクトの属性を定義する方法

- 5.12.2 LOVが有効なビュー・オブジェクトの属性に対してカスケード・リストを定義する方法

- 5.12.2.1 カスケード・リストを制御するデータ・ソース・ビュー・オブジェクトの作成

- 5.12.2.2 カスケード・リストをフィルタリングするビュー・アクセッサの作成

- 5.12.3 単一のLOVが有効なビュー・オブジェクト属性に複数のLOVを指定する方法

- 5.12.4 LOVを定義して参照属性を表示する方法

- 5.12.5 ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法

- 5.12.6 リスト・タイプUIコンポーネントの日付変換処理方法

- 5.12.7 ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法

- 5.12.8 Oracle ADFモデル・テスターを使用してLOV有効属性をテストする方法

- 5.12.9 ビュー・オブジェクト属性のLOVの定義時の処理

- 5.12.10 実行時に行われる処理: LOVでリスト・データソースを問い合せる方法

- 5.12.11 リストに関する必知事項

- 5.12.11.1 親ビュー・オブジェクト属性からのAttributeDefプロパティの継承

- 5.12.11.2 バリデータを使用した属性値の検証

- 5.13 ビュー・オブジェクトのUIヒントの定義

- 5.13.1 属性固有のUIヒントの追加方法

- 5.13.2 ビュー・オブジェクトUIヒントの追加方法

- 5.13.3 EL式を使用してUIヒントにアクセスする方法

- 5.13.4 UIヒント追加時の処理

- 5.13.5 UIカテゴリ・ヒントを定義する方法

- 5.13.6 属性をUIカテゴリに割り当てる際の処理

- 5.13.7 リソース・バンドルに関する必知事項

6 マスター/ディテール関連のビュー・オブジェクトの定義

- 6.1 マスター/ディテール・ビュー・オブジェクトについて

- 6.1.1 マスター/ディテール・ビュー・オブジェクトのユースケースと例

- 6.1.2 ビュー・オブジェクトの追加機能

- 6.2 マスター/ディテール階層における複数表の使用

- 6.2.1 エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法

- 6.2.2 ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法

- 6.2.3 ビュー・リンクを使用したマスター/ディテール階層の作成時の処理

- 6.2.4 データ・モデルでアクティブなマスター/ディテール調整を有効化する方法

- 6.2.5 マスター/ディテールの調整のテスト方法

- 6.2.6 ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法

- 6.2.6.1 名前による行の属性へのアクセス

- 6.2.6.2 ビュー・リンク・アクセッサを使用したディテール・コレクションへのプログラムによるアクセス

- 6.2.6.3 マスター/ディテール・データを表示するためのビュー・リンク・アクセッサのアクセスの最適化

- 6.2.7 ビュー・リンク・アクセッサとデータ・モデル・ビュー・リンク・インスタンスの相違に関する必知事項

- 6.2.7.1 アクティブなマスター/ディテール調整による動的ディテール行セットの有効化

- 6.2.7.2 ビュー・リンク・アクセッサ属性を使用したディテール行セットへのプログラムによるアクセス

- 6.2.7.3 実行時に行われる処理: ビュー・リンク・アクセッサを使用したプログラムによるアクセスを組み合せるタイミング

- 6.2.8 複数のマスターがあるマスター/ディテール階層を作成する方法

- 6.2.9 エンティティ・オブジェクト用に一時のみ属性によるマスター/ディテール階層を作成する方法

- 6.2.10 行検索を使用したマスター・ビュー・オブジェクトの行の検索方法

- 6.2.10.1 マスター・ビュー・オブジェクトに対する行検索の定義

- 6.2.10.2 マスター・ビュー・オブジェクトの行検索作成時の処理

- 6.3 再帰的なマスター/ディテール階層における単一表の使用

- 6.3.1 エンティティ・ベースのビュー・オブジェクトに対する再帰的マスター/ディテール階層の作成方法

- 6.3.1.1 アソシエーション・ベースの自己参照型ビュー・リンクの作成

- 6.3.1.2 ビュー・インスタンスの公開とビュー基準によるフィルタ

- 6.3.2 再帰的マスター/ディテール階層の作成時の処理

- 6.4 ビュー基準でのマスター/ディテール関連ビュー・オブジェクトの使用

7 多相ビュー・オブジェクトの定義

- 7.1 多相ビュー・オブジェクトについて

- 7.1.1 多相エンティティ・オブジェクトの慣用名と多相ビュー行の慣用名

- 7.2 多相エンティティ・オブジェクトの慣用名での作業

- 7.2.1 多相エンティティ・オブジェクトの慣用名を持つサブタイプ・ビュー・オブジェクトを作成する方法

- 7.2.2 多相エンティティ・オブジェクトの慣用名によりサブタイプ・ビュー・オブジェクトを作成すると行われる処理

- 7.2.3 多相エンティティ・オブジェクトの慣用名に関する必知事項

- 7.2.3.1 問合せでは期待するエンティティ・サブタイプに行を制限する必要がある

- 7.2.3.2 委譲を使用したビュー行での選択したエンティティ・メソッドの公開

- 7.2.3.3 目的のエンティティ・サブタイプでの新しい行の作成

- 7.3 多相ビュー行関連の作業

- 7.3.1 多相ビュー行を持つビュー・オブジェクトの作成方法

- 7.3.2 多相ビュー行を持つビュー・オブジェクトを作成する場合の処理

- 7.3.3 多相ビュー行に関する必知事項

- 7.3.3.1 拡張されたビュー・オブジェクトでのサブタイプ固有の属性の選択

- 7.3.3.2 エンティティ・オブジェクトの慣用名をオーバーライドした後のサブタイプ固有のメソッドへの委譲

- 7.3.3.3 クライアント・コードでの異なるビュー行インタフェース型の使用

- 7.4 識別子属性に関する必知事項

- 7.5 サブタイプ・オブジェクトの慣用名を表示するためのアプリケーション・モジュールの更新

- 7.5.1 データ・モデル上でのサブタイプ・オブジェクトの慣用名の公開方法

- 7.5.2 サブタイプ・ビュー・オブジェクトをアプリケーション・モジュールに追加した場合に行われる処理

8 ビュー・インスタンスの問合せのテスト

- 8.1 ビュー・インスタンスの問合せについて

- 8.1.1 ビュー・インスタンスのユースケースと例

- 8.1.2 ビュー・インスタンスのテストの追加機能

- 8.2 ビュー・インスタンスをテストするためのアプリケーション・モジュールの作成

- 8.2.1 個別のビュー・オブジェクト・インスタンスを使用したアプリケーション・モジュールの作成方法

- 8.2.2 マスター/ディテール・ビュー・オブジェクト・インスタンスを使用したアプリケーション・モジュールの作成方法

- 8.3 Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト

- 8.3.1 Oracle ADFモデル・テスターの実行方法

- 8.3.2 構成を使用したOracle ADFモデル・テスターの実行方法

- 8.3.3 言語メッセージ・バンドルおよびUIヒントのテスト方法

- 8.3.4 エンティティ・ベースのビュー・オブジェクトの対話的テスト方法

- 8.3.5 Oracle ADFモデル・テスターを更新してプロジェクトの変更を表示する方法

- 8.3.6 Oracle ADFモデル・テスター使用時の処理

- 8.3.7 Oracle ADFモデル・テスターでのエンド・ユーザーによる対話のシミュレーション方法

- 8.3.7.1 マスター/ディテール調整のテスト

- 8.3.7.2 UIヒントのテスト

- 8.3.7.3 ビジネス・ドメイン・レイヤーの検証のテスト

- 8.3.7.4 エンティティ・オブジェクトの慣用名を参照するビュー・オブジェクトのテスト

- 8.3.7.5 行の作成およびデフォルト値の生成のテスト

- 8.3.7.6 新しいディテール行の外部キーが正しいかどうかのテスト

- 8.3.8 Oracle ADFモデル・テスターでのマルチ・ユーザー・シナリオのテスト方法

- 8.3.9 テスターを実行する前の構成オプションのカスタマイズ方法

- 8.3.10 ADFビジネス・コンポーネント・デバッグ診断を有効化する方法

- 8.3.11 実行時のビュー・オブジェクトとエンティティ・オブジェクトの連携処理

- 8.3.11.1 ビュー・オブジェクトによる問合せ実行後の処理

- 8.3.11.2 ビュー行属性変更後の実行時の処理

- 8.3.11.3 外部キー属性変更後の実行時の処理

- 8.3.11.4 トランザクションのコミット後の実行時の処理

- 8.3.11.5 ビュー・オブジェクトによるデータ再問合せ後の実行時の処理

- 8.3.11.5.1 問合せの再実行時の変更なしの属性の処理

- 8.3.11.5.2 問合せの再実行時の変更されたの属性の処理

- 8.3.11.5.3 問合せの再実行時の属性のサブセットのオーバーラップの処理

- 8.3.12 ビュー・オブジェクトの実行時パフォーマンスの最適化に関する必知事項

- 8.4 ビュー・オブジェクト・インスタンスのプログラムによるテスト

- 8.4.1 ビュー・オブジェクトのデフォルト行セットを使用した操作のViewObjectインタフェース・メソッド

- 8.4.1.1 ビュー行またはエンティティ行におけるキー・オブジェクトの役割

- 8.4.1.2 エンティティ・キャッシュがトランザクションで果す役割

- 8.4.2 コマンド行Javaテスト・クライアントの作成方法

- 8.4.2.1 スケルトン・コードを使用したテスト・クライアントの作成

- 8.4.2.2 スケルトン・コードの変更によるテスト・クライアントの作成

- 8.4.3 テスト・クライアント・プログラム実行時の処理

- 8.4.4 テスト・クライアントの実行に関する必知事項

- 8.4.5 行セットにおける行数計算の方法

- 8.4.6 ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法

- 8.4.7 マスター/ディテール/ディテール階層の反復方法

- 8.4.8 行の検索および外部キー値の更新の方法

- 8.4.9 ビュー・オブジェクト・インスタンスの新しい行の作成方法

- 8.4.10 行を識別する行キーの取得方法

- 8.4.11 findByKey()での部分キーの使用に関する必知事項

- 8.4.12 テスト・クライアントでのテスト・ユーザー認証方法

9 ビュー・オブジェクトのパフォーマンス・チューニング

- 9.1 ビュー・オブジェクトのチューニングについて

- 9.2 同じエンティティに基づくビュー・オブジェクトでの新しい行の一貫性の保持

- 9.2.1 実行時に行われる処理: ビュー・リンクの一貫性が有効な場合

- 9.2.2 ビュー・リンク一貫性のデフォルト設定の変更に関する必知事項

- 9.2.3 行セットに追加されるポストされていない新規行を制限するためのRowMatchの使用方法

- 9.2.4 動的なWHERE句とビュー・リンク一貫性に関する必知事項

- 9.3 パラメータ付き問合せのためのバインド変数の使用方法

- 9.3.1 問合せの再解析を防ぐためのバインド変数の使用

- 9.3.2 SQLインジェクション攻撃を避けるためのバインド変数の使用

- 9.3.3 バインド・パラメータ値のロギング

- 9.4 複数の行セットと行セット・イテレータの使用

- 9.5 読取り専用データへのエンティティ・ベースのビュー・オブジェクトの使用方法

- 9.6 異常な問合せを識別するためのSQLトレースの使用方法

- 9.7 適切なビュー・オブジェクト・チューニング設定の使用方法

- 9.7.1 「データベースから取得」オプションに関する必知事項

- 9.7.2 一度に1行のフェッチが適切かどうかの検討

- 9.7.3 必要に応じた問合せオプティマイザ・ヒントの指定

- 9.8 ビュー・オブジェクトの最大フェッチ・レコード数を制限するためのフェッチ・サイズの使用方法

- 9.9 範囲サイズを使用したページ単位でのデータの提示およびスクロール

- 9.10 大きい結果セットを効率的にスクロールするための範囲ページ移動の使用方法

- 9.10.1 上位N問合せのサポート方法の理解

- 9.10.2 ビュー・オブジェクトの範囲ページ移動を有効にする方法

- 9.10.3 範囲ページ移動を有効にしたときに行われる処理

- 9.10.4 範囲ページ移動を使用するときのビュー行のキャッシュ時の処理

- 9.10.5 範囲ページ移動を使用して特定のページ番号にスクロールする方法

- 9.10.6 範囲ページ移動を使用するときの行セット内のページ数の推定方法

- 9.10.7 範囲ページ移動モードを使用するときのトレードオフ

- 9.11 ビュー行のキャッシュを避ける前方のみモードの使用方法

- 9.12 「行セットの保存」を使用したビュー・リンク・アクセッサのアクセスの最適化

- 9.13 UIの状態を格納するためのビュー・オブジェクトでの動的属性の使用方法

10 ビュー・オブジェクトのプログラムによる操作

- 10.1 ビュー・オブジェクトのカスタムJavaクラスの生成

- 10.1.1 カスタム・クラスの生成方法

- 10.1.1.1 バインド変数アクセッサの生成

- 10.1.1.2 ビュー行属性アクセッサの生成

- 10.1.1.3 クライアントへのビュー行アクセッサの公開

- 10.1.1.4 デフォルトのJava生成設定の構成

- 10.1.2 カスタム・クラス生成時の処理

- 10.1.2.1 カスタムJavaファイルの表示および操作

- 10.1.3 カスタム・クラスに関する必知事項

- 10.1.3.1 ビュー・オブジェクトのフレームワーク・ベース・クラスについて

- 10.1.3.2 カスタム・コンポーネント・ファイルに安全に追加できるコード

- 10.1.3.3 属性索引およびInvokeAccessor生成コード

- 10.1.3.4 親アプリケーション・モジュール・タイプにおける依存性の作成の回避

- 10.2 複数の名前付きビュー基準のプログラム的処理

- 10.2.1 名前付きビュー基準の適用

- 10.2.2 適用されたすべての名前付きビュー基準の除去

- 10.2.3 実行時の名前付き基準の使用

- 10.3 行セットのメモリー内でのソート処理とフィルタ処理の実行

- 10.3.1 ビュー・オブジェクトのSQLモード

- 10.3.2 メモリー内のビュー・オブジェクト行のソート処理

- 10.3.2.1 メモリー内ソートでのsetSortByとsetQueryModeの組合せ

- 10.3.2.2 簡素化されたメモリー内ソート処理

- 10.3.2.3 メモリー内ソート処理の拡張ポイント

- 10.3.3 ビュー基準によるメモリー内フィルタ処理の実行

- 10.3.4 RowMatchによるメモリー内フィルタ処理の実行

- 10.3.4.1 ビュー・オブジェクトへのRowMatchの適用

- 10.3.4.2 個別の行をテストするためのRowMatchの使用

- 10.3.4.3 データベースからフェッチされた行に対するRowMatchの影響

- 10.4 XMLの読取りと書込み

- 10.4.1 問合せ済データのXMLの生成方法

- 10.4.2 XMLを生成するときに行われる処理

- 10.4.3 XMLの読取りと書込みに関する必知事項

- 10.4.3.1 XMLの要素名の制御

- 10.4.3.2 NULL値属性の要素抑止の制御

- 10.4.3.3 生成されたXMLの印刷またはXPathを使用した検索

- 10.4.3.4 生成されるXMLの属性マップによるきめ細かい制御

- 10.4.3.5 双方向ビュー・リンクでの属性マップ手法の使用

- 10.4.3.6 生成されたXMLのXSLTスタイルシートによる変換

- 10.4.3.7 単一行に対するXMLの生成

- 10.4.4 XMLドキュメントを使用して変更を適用する方法

- 10.4.5 XMLドキュメントを使用するときに行われる処理

- 10.4.5.1 ViewObject.readXML()によるXMLドキュメントの処理方法

- 10.4.5.2 単一行でXMLを処理するためのreadXML()の使用

- 10.5 カスタム・データ・ソースおよびFramework Base Class ProgrammaticViewObjectImplを使用したプログラム的操作

- 10.5.1 ProgrammaticViewObjectImplを拡張してビュー・オブジェクト・クラスを作成する方法

- 10.5.2 ProgrammaticViewObjectImplベースのビュー・オブジェクトをオーバーライドする主要なフレームワーク・メソッド

- 10.5.3 ProgrammaticViewRowImplベースのビュー・オブジェクトをオーバーライドする主要なフレームワーク・メソッド

- 10.6代替データ・ソースに対するクラシック・スタイル・プログラムでのビュー・オブジェクトの使用

- 10.6.1 プログラムで読取り専用のビュー・オブジェクトを作成する方法

- 10.6.2 プログラムでエンティティ・ベースのビュー・オブジェクトを作成する方法

- 10.6.3 プログラムのビュー・オブジェクト用にオーバーライドする主要なフレームワーク・メソッド

- 10.6.4 REF CURSORでのビュー・オブジェクトの作成方法

- 10.6.4.1 create()メソッドのオーバーライド

- 10.6.4.2 executeQueryForCollection()メソッドのオーバーライド

- 10.6.4.3 createRowFromResultSet()メソッドのオーバーライド

- 10.6.4.4 hasNextForCollectionMethod()のオーバーライド

- 10.6.4.5 releaseUserDataForCollection()メソッドのオーバーライド

- 10.6.4.6 getQueryHitCount()メソッドのオーバーライド

- 10.7 複数の更新可能エンティティによるビュー・オブジェクトの作成

- 10.7.1 複数の更新可能エンティティ・オブジェクト慣用名を持つ新規行をプログラムで作成する方法

- 10.7.2 実行時の処理: ビュー行の作成

- 10.8 プログラムによるビュー定義とビュー・オブジェクトの作成

- 10.8.1 MDSリポジトリの構成に関する必知事項

- 10.8.2 実行時のビュー・オブジェクト作成に関する必知事項

- 10.9 挿入、更新および削除の宣言による禁止

11 検証とビジネス・ルールの宣言的な定義

- 11.1 宣言的な検証について

- 11.1.1 宣言的な検証のユースケースと例

- 11.1.2 宣言的な検証の追加機能

- 11.2 検証を実装する場所の決定

- 11.3 検証サイクルの理解

- 11.3.1 エンティティ・オブジェクト検証規則のタイプ

- 11.3.1.1 属性レベルの検証規則

- 11.3.1.2 エンティティ・レベルの検証規則

- 11.3.2 コミット処理と検証の理解

- 11.3.3 検証順序に対するコンポジットの影響の理解

- 11.3.4 無限検証サイクルの回避

- 11.3.5 検証が失敗したときに行われる処理

- 11.3.6 エンティティ・オブジェクト行の状態の理解

- 11.3.7 バンドル例外モードの理解

- 11.4 エンティティ・オブジェクトおよび属性への検証規則の追加

- 11.4.1 エンティティまたは属性への検証規則の追加方法

- 11.4.2 エンティティ・オブジェクトまたは属性の検証規則の表示および編集方法

- 11.4.3 検証規則の追加時の処理

- 11.4.4 エンティティおよび属性の検証規則に関する必知事項

- 11.4.5 値リストおよび属性検証規則に関する必知事項

- 11.5 組込みの宣言的な検証規則の使用

- 11.5.1 キー値の一意性を確認する方法

- 11.5.2 一意キー・バリデータの使用時の処理

- 11.5.3 比較に基づく検証方法

- 11.5.4 比較に基づく検証時の処理

- 11.5.5 値リストを使用した検証方法

- 11.5.6 リスト値を使用した検証時の処理

- 11.5.7 リスト・バリデータに関する必知事項

- 11.5.8 値が特定の範囲内にあることを確認する方法

- 11.5.9 範囲バリデータの使用時の処理

- 11.5.10 バイトまたは文字数に対する検証方法

- 11.5.11 バイトまたは文字数に対する検証時の処理

- 11.5.12 正規表現を使用した検証方法

- 11.5.13 正規表現を使用した検証時の処理

- 11.5.14 Average、Count、またはSumを使用したコレクションの検証方法

- 11.5.15 コレクション検証の使用時の処理

- 11.5.16 キーの存在の判別方法

- 11.5.17 キー存在バリデータの使用時の処理

- 11.5.18 宣言的バリデータとビュー・アクセッサに関する必知事項

- 11.6 エンティティ・レベルのトリガーの使用方法

- 11.6.1 エンティティ・レベルのトリガーを使用したビジネス・ルールの実装方法

- 11.6.2 エンティティ・レベルのトリガーの作成時の処理

- 11.7 ビジネス・ルールとトリガーでのGroovy式の使用

- 11.7.1 Groovy式でのエンティティ・オブジェクト・メソッドの参照方法

- 11.7.2 true/false式を使用した検証方法

- 11.7.3 Groovy式の追加時の処理

- 11.8 検証実行のトリガー

- 11.8.1 検証を起動する属性の指定方法

- 11.8.2 属性のトリガーによる検証実行制約時の処理

- 11.8.3 検証の事前条件の設定方法

- 11.8.4 トランザクション・レベルの検証の設定方法

- 11.8.5 検証実行の順序に関する必知事項

- 11.9 検証エラー・メッセージの作成

- 11.9.1 バリデータとトリガーのエラー・メッセージの作成方法

- 11.9.2 検証メッセージのローカライズ方法

- 11.9.3 Groovyを使用して条件付きでエラー・メッセージを呼び出す方法

- 11.9.4 エラー・メッセージにGroovy式を埋め込む方法

- 11.10 検証例外の重大度レベルの設定

- 11.11 SQLでのバルク検証

12 プログラムによる検証とビジネス・ルールの実装

- 12.1 プログラム的なビジネス・ルールについて

- 12.1.1 プログラム的なビジネス・ルールのユースケースと例

- 12.1.2 プログラム的なビジネス・ルールの追加機能

- 12.2 メソッド・バリデータの使用

- 12.2.1 属性レベルのメソッド・バリデータの作成方法

- 12.2.2 属性レベルのメソッド・バリデータを作成するときに行われる処理

- 12.2.3 エンティティ・レベルのメソッド・バリデータの作成方法

- 12.2.4 エンティティ・レベルのメソッド・バリデータを作成するときに行われる処理

- 12.2.5 検証規則エラー・メッセージの翻訳に関する必知事項

- 12.3 プログラム的な導出属性値の割当て

- 12.3.1 新しい行に対する作成時のデフォルト値の指定方法

- 12.3.1.1 create()メソッドとinitDefaultExpressionAttributes()メソッドのいずれかの選択

- 12.3.1.2 データベース順序からの属性値のデフォルト設定

- 12.3.2 保存前の導出値の割当て方法

- 12.3.3 属性値が設定されている場合の、導出値の割当て方法

- 12.4 refreshメソッドを使用した、エンティティに対する保留中の変更の取消し

- 12.4.1 リフレッシュ中の新規行の動作の制御方法

- 12.4.2 構成される側の子エンティティ行へのリフレッシュのカスケード方法

- 12.5 検証でのビュー・オブジェクトの使用

- 12.5.1 ビュー・オブジェクトに対する検証用ビュー・アクセッサの使用方法

- 12.5.2 指定された型のすべてのエンティティに関連する条件の検証方法

- 12.5.3 ビュー・アクセッサによる行セットのアクセスに関する必知事項

- 12.6 アソシエーション・アクセッサを使用した、関連するエンティティ行へのアクセス

- 12.6.1 関連するエンティティ行へのアクセス方法

- 12.6.2 関連するエンティティ行セットへのアクセス方法

- 12.7 認証されたユーザーに関する情報の参照

- 12.8 元の属性値へのアクセス

- 12.9 現在のユーザー・セッションに関する情報の格納

- 12.9.1 現在のユーザー・セッションに関する情報の格納方法

- 12.9.2 現在のユーザー・セッション情報へのアクセスにGroovyを使用する方法

- 12.10 現在の日時へのアクセス

- 12.11 正常に完了したコミットに関する通知の送信

- 12.12 エンティティ行削除の条件付き禁止

- 12.13 属性に対する条件付きの更新可能性の判断

- 12.14 カスタム検証規則の実装

- 12.14.1 カスタム検証規則の作成方法

- 12.14.2 JDeveloperでのカスタム規則の登録および使用方法

- 12.14.2.1 プロジェクト・レベルでのカスタム・バリデータの登録

- 12.14.2.2 IDEレベルでのカスタム・バリデータの登録

13 アプリケーション・モジュールによるビジネス・サービスの実装

- 13.1 アプリケーション・モジュールについて

- 13.1.1 アプリケーション・モジュールのユースケースと例

- 13.1.2 アプリケーション・モジュールの追加機能

- 13.2 アプリケーション・モジュールの作成と変更

- 13.2.1 アプリケーション・モジュールの作成方法

- 13.2.2 アプリケーション・モジュール作成時の処理

- 13.2.3 アプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加方法

- 13.2.3.1 既存のアプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加

- 13.2.3.2 既存のアプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加

- 13.2.3.3 アプリケーション・モジュールに追加するビュー・オブジェクト・インスタンスのカスタマイズ

- 13.2.4 アプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加時の処理

- 13.2.5 既存のアプリケーション・モジュールの編集方法

- 13.2.6 ページ作成を開始する前のデータ・コントロール名の変更方法

- 13.2.7 アプリケーション・モジュールの粒度に関する必知事項

- 13.2.8 ビュー・オブジェクト・コンポーネントとビュー・オブジェクト・インスタンスに関する必知事項

- 13.3 アプリケーション・モジュールのデータベース接続の構成

- 13.3.1 JDBCデータソース接続タイプの使用方法

- 13.3.2 アプリケーション・モジュール・データベース接続作成時の処理

- 13.3.3 アプリケーション・モジュールのランタイム構成の変更方法

- 13.3.4 プロジェクトのデータベース接続の変更方法

- 13.4 ネストされたアプリケーション・モジュールの定義

- 13.4.1 ネストされたアプリケーション・モジュールの定義方法

- 13.4.2 ルート・アプリケーション・モジュールおよびネストされたアプリケーション・モジュールの慣用名に関する必知事項

- 13.5 ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成

- 13.5.1 アプリケーション・モジュールのダイアグラムの作成方法

- 13.5.2 アプリケーション・モジュールのダイアグラム作成時の処理

- 13.5.3 ダイアグラムを使用したアプリケーション・モジュールの編集方法

- 13.5.4 ダイアグラム表示オプションの制御方法

- 13.5.5 ダイアグラム内に表示されたメソッド名のフィルタ方法

- 13.5.6 関連するオブジェクトおよび実装ファイルのダイアグラムでの表示方法

- 13.5.7 アプリケーション・モジュール・ダイアグラムの公開方法

- 13.5.8 ダイアグラムからのアプリケーション・モジュールのテスト方法

- 13.6 複数ページの作業ユニットのサポート

- 13.6.1 Oracle ADFモデル・テスターでの状態管理のシミュレーション方法

- 13.6.2 実行時に行われる処理: アプリケーションでアプリケーション・モジュール・プーリングと状態管理が使用される場合

- 13.7 サービス・メソッドによるアプリケーション・モジュールのカスタマイズ

- 13.7.1 アプリケーション・モジュールのカスタム・クラスの生成方法

- 13.7.2 アプリケーション・モジュールのカスタム・クラス生成時の処理

- 13.7.3 デフォルトのコード生成に関する必知事項

- 13.7.4 アプリケーション・モジュールへのカスタム・サービス・メソッドの追加方法

- 13.7.5 static mainメソッドを使用したカスタム・アプリケーション・モジュールのテスト方法

- 13.7.6 プログラムによる行セットの反復に関する必知事項

- 13.8 アプリケーション・モジュール・メッセージ文字列のカスタマイズ

- 13.8.1 アプリケーション・モジュールへのリソース・バンドル・ファイルの追加方法

- 13.8.2 アプリケーション・モジュールへのリソース・バンドル追加時の処理

- 13.9 UIクライアントへのカスタム・サービス・メソッドの公開

- 13.9.1 アプリケーション・モジュールのクライアント・インタフェースでのカスタム・メソッドの公開方法

- 13.9.2 カスタム・サービス・メソッド公開時の処理

- 13.9.3 ビュー・オブジェクトおよびビュー行のクライアント・インタフェースの生成方法

- 13.9.4 Oracle ADFモデル・テスターを使用したカスタム・サービス・メソッドのテスト方法

- 13.9.5 クライアント・インタフェースのメソッド・シグネチャに関する必知事項

- 13.9.6 データ・モデルからの情報の引渡しに関する必知事項

- 13.10 アプリケーション・モジュールのクライアント・インタフェースのプログラム的操作

- 13.10.1 アプリケーション・モジュールのクライアント・インタフェースのプログラム的な操作方法

- 13.10.2 実行時に行われる処理: アプリケーション・モジュールのクライアント・インタフェースにアクセスする場合

- 13.10.3 Fusion Webアプリケーションでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス方法

- 13.11 組込みフレームワーク・メソッドのオーバーライド

- 13.11.1 組込みフレームワーク・メソッドのオーバーライド方法

- 13.11.2 組込みフレームワーク・メソッドをオーバーライドした場合の処理

- 13.11.3 prepareSession()をオーバーライドして新規ユーザー・セッション用のアプリケーション・モジュールを設定する方法

- 13.12 アプリケーション・モジュールからのWebサービスのコール

- 13.12.1 外部サービスのプログラム的なコール方法

- 13.12.1.1 サービスにプログラム的にアクセスするためのWebサービス・プロキシ・クラスの作成

- 13.12.1.2 サービスを起動するためのWebサービス・プロキシ・テンプレートのコール

- 13.12.1.3 アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール

- 13.12.2 Webサービス・プロキシの作成時の処理

- 13.12.3 新しいWebサービス接続の作成方法

- 13.12.4 実行時に行われる処理: Webサービス・プロキシによるWebサービスの起動処理

- 13.12.5 Webサービス・プロキシに関する必知事項

- 13.12.5.1 try/catchブロックによるWebサービス例外の処理

- 13.12.5.2 アプリケーションモジュールとWebサービスでのトランザクションの分離

- 13.12.5.3 ブラウザ・プロキシ情報の設定

- 13.12.5.4 Webサービス・プロキシ・クラスを使用したアプリケーション・モジュールの起動

14 アプリケーション・モジュール・ビュー・インスタンスの共有

- 14.1 共有アプリケーション・モジュールについて

- 14.1.1 共有アプリケーション・モジュールのユースケースと例

- 14.1.2 共有アプリケーション・モジュールの追加機能

- 14.2 アプリケーション・モジュール・インスタンスの共有

- 14.2.1 共有アプリケーション・モジュール・インスタンスの作成方法

- 14.2.2 共有アプリケーション・モジュール定義時の処理

- 14.2.3 共有アプリケーション・モジュールの設計時間範囲に関する必知事項

- 14.2.4 共有アプリケーション・モジュールのビュー・インスタンスの設計時間範囲に関する必知事項

- 14.2.5 共有問合せコレクション数の管理に関する必知事項

- 14.2.6 共有アプリケーション・モジュールと接続プールに関する必知事項

- 14.3 ベース・ビュー・オブジェクトを参照表で使用するための定義

- 14.3.1 参照表のベース・ビュー・オブジェクト定義の作成方法

- 14.3.2 ベース・ビュー・オブジェクトの作成時の処理

- 14.3.3 ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法

- 14.3.4 エディタでのビュー基準の作成時の処理

- 14.3.5 ビュー・インスタンスが検索データにアクセスする場合の実行時の処理

- 14.4 共有サービスのビュー・インスタンスへのアクセス

- 14.4.1 エンティティ・オブジェクトまたはビュー・オブジェクトのビュー・アクセッサの作成方法

- 14.4.2 ビュー・アクセッサによって指定された属性値に対する検証方法

- 14.4.3 ビュー・アクセッサ・バリデータ定義時の処理

- 14.4.4 ビュー・アクセッサを使用した動的フィルタリングに関する必知事項

- 14.4.5 参照表を基にしてLOVを作成する方法

- 14.4.6 ビュー・オブジェクト属性のLOVの定義時の処理

- 14.4.7 属性の値リストが表示される場合の実行時の処理

- 14.4.8 参照表からの値のリストの表示に関する必知事項

- 14.4.9 プログラム的に起動されるデータベース変更通知に関する必知事項

- 14.4.10 AttributeDefプロパティの継承に関する必知事項

- 14.4.11 バリデータの使用に関する必知事項

- 14.5 共有アプリケーション・モジュールでのビュー・オブジェクト・インスタンスのテスト

- 14.5.1 Oracle ADFモデル・テスターを使用したベース・ビュー・オブジェクトのテスト方法

- 14.5.2 Oracle ADFモデル・テスターを使用してLOV有効属性をテストする方法

- 14.5.3 Oracle ADFモデル・テスター使用時の処理

- 14.5.4 共有アプリケーション・モジュール・キャッシュが別のサービスによってアクセスされた場合の実行時の処理

15 アプリケーション・モジュールによるSOAP Webサービスの作成

- 15.1 サービス対応アプリケーション・モジュールについて

- 15.1.1 サービス対応アプリケーション・モジュールのユースケースと例

- 15.1.2 サービス対応アプリケーション・モジュールの追加機能

- 15.2 サービス対応アプリケーション・モジュールの公開

- 15.2.1 アプリケーション・モジュール・サービス・インタフェースの有効化の方法

- 15.2.2 アプリケーション・モジュール・サービス・インタフェース作成時の処理

- 15.2.2.1 Webサービス・インタフェースで生成される注釈

- 15.2.2.2 Webサービス・スキーマ・ファイルで生成されるWebサービス・スキーマ

- 15.2.2.3 Webサービス定義ファイルで生成されるWSDL

- 15.2.2.4 サービス実行クラスにより指定されるステートレス・セッションBean

- 15.2.2.5 connections.xmlファイルで定義される参照

- 15.2.3 多相ビュー・オブジェクトを持つアプリケーション・モジュール・サービス・インタフェース作成すると行われる処理

- 15.2.4 ADF Webサービス・インタフェース上のメソッド・シグネチャに関する必知事項

- 15.2.5 行ファインダとADF Webサービス操作に関する必知事項

- 15.2.6 個別のビュー・オブジェクトのサービス対応化の方法

- 15.2.7 サービス対応ビュー・オブジェクトのSDOプロパティのカスタマイズ方法

- 15.2.7.1 生成されたSDOコンポーネントでの個別SDOプロパティの除外

- 15.2.7.2 複合データ型を使用した関連するSDOプロパティの関連付け

- 15.2.8 サービス対応マスター/ディテール・ビュー・オブジェクトにおけるネスト処理のサポート方法

- 15.2.9 SDOクラス作成時の処理

- 15.2.9.1 SDOインタフェース内で生成されるプロパティ・アクセッサ

- 15.2.9.2 SDOクラスにより実装されるビュー・オブジェクト・インタフェース

- 15.2.9.3 SDOスキーマ・ファイルで生成されるビュー・オブジェクト・スキーマ

- 15.2.9.4 SDO結果クラスおよびインタフェースにより実装されるコンテナ・オブジェクト

- 15.2.10 必須バインド変数による宣言的検索操作の公開方法

- 15.2.11 必須バインド変数でフィルタするカスタム検索メソッドの公開方法

- 15.2.12 非同期ADF Webサービス・メソッドの生成方法

- 15.2.13 非同期ADF Webサービス・メソッドの生成時の処理

- 15.2.14 実行時の非同期コール時の処理

- 15.2.15 ADF Webサービス・インタフェース生成用プリファレンスの設定方法

- 15.2.16 サービス・ビュー・インスタンスと属性の表示名の設定方法

- 15.2.17 SOAPクライアントによるアクセス用にADF Webサービスを保護する方法

- 15.2.18 RMIクライアントによるアクセス用にADF Webサービスを保護する方法

- 15.2.18.1 RMIクライアント認証の有効化

- 15.2.18.2 RMIクライアントの認可の構成

- 15.2.19 サービスへのアクセスをテスト・ユーザーに許可する方法

- 15.2.20 SOAPクライアント用バイナリ添付サポートの有効化の方法

- 15.2.21 ClobDomainタイプ属性の文字エンコーディングの指定方法

- 15.2.22 Integrated WebLogic Serverを使用したWebサービスのテスト方法

- 15.2.23 カスタム・サービス・メソッドのタイムアウトの防止方法

- 15.2.24 Oracle WebLogic ServerへのWebサービスのデプロイ方法

- 15.3 サービス対応アプリケーション・モジュールによるリモート・データのアクセス

- 15.3.1 サービス対応エンティティ・オブジェクトとビュー・オブジェクトの使用方法

- 15.3.1.1 SDOサービスにバックアップされたエンティティ・オブジェクトの作成

- 15.3.1.2 サービスバック・エンティティ・オブジェクト属性を持つ複合データ型の使用

- 15.3.1.3 SDOサービスにバックアップされたビュー・オブジェクトの作成

- 15.3.2 サービスバック・ビジネス・コンポーネント作成時の処理

- 15.3.3 サービスバック・ビジネス・コンポーネントのデータ・モデルの更新方法

- 15.3.4 サービスバック・ビジネス・コンポーネント・ランタイムの構成方法

- 15.3.4.1 クラスパスへのSDOクライアント・ライブラリの追加

- 15.3.4.2 コンシューミング・アプリケーションのEJB RMIプロトコル用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

- 15.3.4.3 コンシューミング・アプリケーションのSOAPプロトコル用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

- 15.3.4.4 コンシューミング・アプリケーションのファブリックSDOバインディング用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

- 15.3.5 Oracle ADFモデル・テスターでのサービスバック・コンポーネントのテスト方法

- 15.3.6 コンシューミング・アプリケーションでのサービスバック・コンポーネント操作起動方法

- 15.3.7 コンシューミング・アプリケーションでのサービス・データ・オブジェクトの作成に関する必知事項

- 15.3.8 コンシューミング・アプリケーションでの組込みサービス・メソッドの呼出しに関する必知事項

- 15.3.9 アプリケーションが公開済のアプリケーション・モジュールにアクセスする場合の実行時の処理

- 15.3.10 サービスバック・エンティティ・オブジェクトおよびビュー・オブジェクトに関する必知事項

- 15.4 コンシューミング・アプリケーションでの多相コレクションへのアクセス

- 15.4.1 サービス対応アプリケーション・モジュールからWebサービス・クライアント・プロキシ・クラスを作成する方法

- 15.4.2 生成したプロキシ・クラスを使用して多相ビュー・オブジェクトの操作を呼び出す方法

- 15.4.3 SDOスキーマを使用してJavaプロキシ・クラスを作成する際に行われる処理

- 15.4.4 クライアント・アプリケーションでのサービス・メソッドの呼出しに関する必知事項

- 15.5 コンシューミング・アプリケーションでの検索メソッド・フィルタ・モデルの使用

- 15.5.1 SOAPリクエストを使用した検索メソッド動作の制御方法

- 15.5.2 Javaクライアントを使用した検索メソッド動作の制御方法

16 アプリケーション・モジュールによるRESTful Webサービスの作成

- 16.1 RESTful WebサービスおよびADFビジネス・コンポーネントについて

- 16.1.1 RESTful Webサービスのユースケースと例

- 16.1.2 RESTful Webサービスの追加機能

- 16.2 アプリケーション・モジュールを使用したADF RESTリソースの作成

- 16.2.1 ビュー・オブジェクト・インスタンスからのADF RESTリソースの作成方法

- 16.2.2 ADFビジネス・コンポーネント・プロジェクトのRESTリソースを作成する場合の処理

- 16.2.3 ADF RESTリソース定義の編集方法

- 16.2.4 ADF RESTリソースでの子リソースの公開方法

- 16.2.5 同じビュー・インスタンスに基づくリソースを追加および削除する方法

- 16.2.6 ADF RESTリソースの名前を変更する方法

- 16.2.7 ADF RESTリソースのネーミングに関する必知事項

- 16.2.8 ADF RESTリソースの属性を非表示にしたり公開したりする方法

- 16.2.9 ADF RESTリソース構造の変更に関する必知事項

- 16.2.10 ADF RESTリソースおよびLOB属性に関する必知事項

- 16.2.11 ADF RESTリソースのLOVアクセッサに関する必知事項

- 16.3 ADF RESTリソース表現およびメソッドのカスタマイズ

- 16.3.1 ADF RESTリソースでの正規リソースの公開方法

- 16.3.2 ADF RESTリソースで行検索キーを有効化する方法

- 16.3.3 ADF RESTリソース・リクエストでの行検索に関する必知事項

- 16.3.4 ADF RESTリソースでサブタイプ・ビュー・オブジェクトを公開する方法

- 16.3.5 ADF RESTリソースで標準のHTTPアクションを公開する方法

- 16.3.6 LOV属性を使用したADF RESTリソースの作成操作のサポート方法

- 16.3.7 ADF RESTリソースの取得操作の最適化に関する必知事項

- 16.3.8 ADF RESTリソースでカスタム・メソッドを公開する方法

- 16.4 ADF RESTリソースのバージョニング

- 16.4.1 ADF RESTリソースのバージョニング方法

- 16.4.2 ADF RESTリソースのバージョニングに関する必知事項

- 16.4.3 実行時に行われる処理: ADF RESTリソースのバージョンの起動

- 16.5 ADF RESTリソースへのクライアント・アクセスの付与

- 16.5.1 ADF RESTリソースに対するリソース権限の作成方法

- 16.6 ADF RESTリソースのデプロイ

- 16.6.1 統合WebLogic ServerへのADF RESTリソースのデプロイ方法

- 16.6.2 スタンドアロンOracle WebLogic Serverのデプロイメントに対するADF RESTリソースのデプロイメント・プロファイルの構成方法

- 16.6.3 スタンドアロンOracle WebLogic ServerへのADF RESTリソースのデプロイ方法

- 16.6.4 サービス・クライアントによって使用されるターゲットURLの変更に関する必知事項

- 16.6.5 ADF RESTリソースのデプロイとMDSカスタマイズ・サポートに関する必知事項

- 16.7 統合WebLogic Serverを使用したADF RESTリソースのテスト

17 ビジネス・コンポーネント機能の拡張

- 17.1 ビジネス・コンポーネント機能の拡張について

- 17.1.1 ビジネス・コンポーネントの拡張の追加機能

- 17.2 ADFビジネス・コンポーネント拡張クラスの作成

- 17.2.1 フレームワーク拡張クラスの作成方法

- 17.2.2 フレームワーク拡張クラス作成時の処理

- 17.2.3 フレームワークの拡張ベース・クラスのカスタマイズに関する必知事項

- 17.2.4 フレームワーク拡張クラスをビジネス・コンポーネントの基礎にする方法

- 17.2.5 すべての新規コンポーネントのフレームワーク拡張クラスを定義する方法

- 17.2.6 すべての新規プロジェクトのフレームワーク拡張クラスを定義する方法

- 17.2.7 フレームワーク拡張クラスをコンポーネントの基礎にするときの処理

- 17.2.7.1 XMLのみのコンポーネント

- 17.2.7.2 カスタムJavaクラスのあるコンポーネント

- 17.2.8 カスタム・コンポーネントのJavaファイルのExtends句の更新に関する必知事項

- 17.2.9 フレームワーク拡張レイヤーをJARファイルにパッケージする方法

- 17.2.10 フレームワーク拡張JARファイルのライブラリ定義の作成方法

- 17.3 拡張クラスによるフレームワークの動作のカスタマイズ

- 17.3.1 ビュー・オブジェクトおよびエンティティ・オブジェクトのランタイム・メタデータにアクセスする方法

- 17.3.2 ランタイム・メタデータを使用した汎用機能の実装方法

- 17.3.3 カスタム・プロパティによって駆動される汎用機能の実装方法

- 17.3.4 属性の種類に関する必知事項

- 17.3.5 カスタム・プロパティに関する必知事項

- 17.4 汎用拡張インタフェースの作成

- 17.5 ストアド・プロシージャとストアド・ファンクションの呼出し

- 17.5.1 引数のないストアド・プロシージャの呼出し方法

- 17.5.2 IN引数のみのストアド・プロシージャの呼出し方法

- 17.5.3 IN引数のみのストアド・ファンクションの呼出し方法

- 17.5.4 他の種類のストアド・プロシージャの呼出し方法

- 17.6 現在のデータベース・トランザクションへのアクセス

- 17.7 ビジネス・コンポーネントのエラー・メッセージのカスタマイズ

- 17.7.1 基になっているADFビジネス・コンポーネントのエラー・メッセージをカスタマイズする方法

- 17.7.2 基になっているADFビジネス・コンポーネントのエラー・メッセージをカスタマイズするときに行われる処理

- 17.7.3 カスタマイズ・エラー・メッセージをネストされた例外として表示する方法

- 17.7.4 データベース制約違反のエラー・メッセージのカスタマイズ方法

- 17.7.5 カスタム制約エラー処理ルーチンの実装方法

- 17.7.5.1 カスタム・データベース・トランザクション・フレームワーク拡張クラスの作成

- 17.7.5.2 カスタム・データベース・トランザクション・クラスを使用するためのアプリケーション・モジュールの構成

- 17.8 継承を使用する拡張コンポーネントの作成

- 17.8.1 別のコンポーネントを拡張するコンポーネントの作成方法

- 17.8.2 コンポーネントを作成後に拡張する方法

- 17.8.3 別のコンポーネントを拡張するコンポーネントの作成時の処理

- 17.8.3.1 親コンポーネントから継承された拡張コンポーネントの属性

- 17.8.3.2 拡張コンポーネントのXMLディスクリプタに追加される属性

- 17.8.3.3 拡張コンポーネントに生成されたJavaクラス

- 17.8.4 コンポーネントの拡張に関する必知事項

- 17.8.4.1 拡張コンポーネントの親のクラスとインタフェース

- 17.8.4.2 拡張コンポーネントに生成されたクラス

- 17.8.4.3 ビジネス・コンポーネントのタイプ

- 17.8.4.4 拡張コンポーネントの新しい属性

- 17.9 提供されるアプリケーションでの拡張コンポーネントの置換え

- 17.9.1 拡張コンポーネントの置換方法

- 17.9.2 置換時の処理

- 17.9.3 基のアプリケーションで置換コンポーネントを有効化する方法

第III部 ADFモデル・レイヤーの使用

18 Fusion WebアプリケーションでのADFモデルの使用

- 18.1 Fusion WebアプリケーションでのADFモデルの使用について

- 18.1.1 ADFデータ・コントロールについて

- 18.1.2 JSFデータ・バインディングについて

- 18.1.3 ADFデータ・バインディングについて

- 18.2 ADFモデル・レイヤーの追加機能

- 18.3 ADFデータ・コントロールを使用したアプリケーション・モジュールの公開

- 18.3.1 「データ・コントロール」パネルでのアプリケーション・モジュールのデータ・コントロールの表示

- 18.3.1.1 「データ・コントロール」パネルでのデータ・モデルおよびサービス・メソッドの表示

- 18.3.1.2 「データ・コントロール」パネルでのトランザクション制御操作の表示

- 18.3.1.3 「データ・コントロール」パネルでのビュー・オブジェクトの表示

- 18.3.1.4 「データ・コントロール」パネルでのネストされたアプリケーション・モジュールの表示

- 18.3.1.5 「データ・コントロール」パネルでの行検索の表示

- 18.3.2 「データ・コントロール」パネルの表示方法

- 18.3.3 「データ・コントロール」パネルのリフレッシュ方法

- 18.3.4 別のプロジェクトで使用するデータ・コントロールのパッケージ化

- 18.4 「データ・コントロール」パネルの使用

- 18.4.1 「データ・コントロール」パネルの使用方法

- 18.4.2 「データ・コントロール」パネルの使用時の処理

- 18.4.3 実行時に行われる処理: バインディング・コンテキストの動作方法

- 18.5 DataBindings.cpxファイルでの作業

- 18.5.1 JDeveloperによるDataBindings.cpxファイルの作成方法

- 18.5.2 DataBindings.cpxファイルの作成時の処理

- 18.6 ADFバインディング・フィルタの構成

- 18.6.1 ADFバインディング・フィルタの構成方法

- 18.6.2 ADFバインディング・フィルタを構成した場合の処理

- 18.6.3 実行時に行われる処理: ADFバインディング・フィルタの動作方法

- 18.7 ページ定義ファイルでの作業

- 18.7.1 ページ定義ファイルの作成方法

- 18.7.2 ページ定義ファイルの作成時の処理

- 18.7.2.1 ページ定義ファイルで定義されるコントロール・バインディング・オブジェクト

- 18.7.2.2 ページ定義ファイルで定義されるExecutablesバインディング・オブジェクト

- 18.8 ADFデータ・バインディングEL式の作成

- 18.8.1 ADFデータ・バインディングEL式の作成方法

- 18.8.1.1 「プロパティ」ウィンドウから式ビルダーを開く手順

- 18.8.1.2 式ビルダーの使用

- 18.8.2 ADFバインディング・プロパティに関する必知事項

- 18.9 最初にシンプルUIを開発する機能の使用

- 18.9.1 ADFモデル・データ・バインディングの既存のUIコンポーネントへの適用方法

- 18.9.2 ADFモデル・データ・バインディングのUIコンポーネントへの適用時の処理

19 ADFモデル・レイヤーでの検証の使用

- 19.1 ADFモデル・レイヤー検証について

- 19.1.1 ADFモデル・レイヤー検証のユースケースと例

- 19.1.2 ADFモデル・レイヤー検証の追加機能

- 19.2 ADFモデル・レイヤーでの検証規則の定義

- 19.2.1 ADFモデル・レイヤー検証の追加方法

- 19.2.2 実行時に行われる処理: Model検証規則

- 19.2.3 デフォルトのエラー処理に関する必知事項

- 19.3 エラー処理のカスタマイズ

- 19.3.1 メッセージの詳細部分のカスタマイズ方法

- 19.3.2 カスタム・エラー・ハンドラから情報メッセージを表示する方法

- 19.3.3 複数スレッドを処理するエラー・ハンドラの記述方法

20 プレースホルダ・データ・コントロールによるページの設計

- 20.1 プレースホルダ・データ・コントロールについて

- 20.1.1 プレースホルダ・データ・コントロールのユースケースと例

- 20.1.2 プレースホルダ・データ・コントロールの追加機能

- 20.2 プレースホルダ・データ・コントロールの作成

- 20.2.1 プレースホルダ・データ・コントロールの作成方法

- 20.2.2 プレースホルダ・データ・コントロールの作成時の処理

- 20.3 プレースホルダ・データ型の作成

- 20.3.1 プレースホルダ・データ型の作成方法

- 20.3.2 属性とサンプル・データをプレースホルダ・データ型に追加する方法

- 20.3.2.1 プレースホルダ・データ型への属性の手動による追加

- 20.3.2.2 サンプルデータを手動で追加

- 20.3.2.3 属性とサンプル・データをプレースホルダ・データ型にインポートする方法

- 20.3.2.4 サンプル・データの追加時の処理

- 20.3.3 プレースホルダ・データ型の作成時の処理

- 20.3.4 プレースホルダ・データ型の属性を値リストに構成する方法

- 20.3.4.1 固定LOVにする属性の構成

- 20.3.4.2 動的LOVにする属性の構成

- 20.3.5 マスター/ディテール・データ型の作成方法

- 20.3.6 マスター/ディテール・データ型の作成時の処理

- 20.4 プレースホルダ・データ・コントロールの使用

- 20.4.1 プレースホルダ・データ・コントロールの制限

- 20.4.2 レイアウトの作成

- 20.4.3 検索フォームの作成

- 20.4.4 コンポーネントのバインド

- 20.4.5 コンポーネントのリバインド

- 20.4.6 ADFライブラリJARへのプレースホルダ・データ・コントロールのパッケージ化

21 ADF RESTデータ・コントロールを使用したRESTful Webサービスの使用方法

- 21.1 アプリケーション・モジュールに基づくRESTful Webサービスのデータ・コントロールについて

- 21.1.1 REST Webサービス・データ・コントロールのユースケースと例

- 21.1.2 REST Webサービス・データ・コントロールの追加機能

- 21.2 RESTデータ・コントロールを使用した、ビジネス・コンポーネントのRESTリソースとしての使用

- 21.2.1 REST接続の作成方法

- 21.2.1.1 REST接続の作成時の処理

- 21.2.1.2 ADF RESTリソースからデータ・コントロールを作成する方法

- 21.2.2 Webサービス・データ・コントロール・ウィザードを使用したADFデータ・コントロールの作成方法

- 21.2.3 REST接続に基づいてデータ・コントロールを作成する場合の処理

- 21.3 RESTデータ・コントロールの使用方法

- 21.4 アプリケーション・モジュールによって公開されたRESTデータ・コントロールの構成

- 21.4.1 RESTデータ・コントロールの構成方法

- 21.4.2 データ・コントロール編集時の処理

- 21.4.3 RESTデータ・コントロールの主キーに関する必知事項

22 ADF RESTフレームワークを使用したRESTful Webサービスの使用方法

- 22.1 ADF RESTフレームワークについて

- 22.1.1 ADF RESTリソースのユースケースと例

- 22.1.2 RESTful Webサービスの追加機能

- 22.1.3 この章のリソース・サンプルについて

- 22.1.3.1 サンプル・プロジェクト・ファイルとデータ・モデル

- 22.1.3.2 サンプル・プロジェクト・リソースとリソース・バージョン識別子

- 22.1.3.3 エンティティ・オブジェクトとビュー・オブジェクトのカスタマイズ

- 22.2 ADFビジネス・コンポーネントのリソースの理解

- 22.3 ADF RESTリソースの記述の取得

- 22.3.1 使用可能なすべてのリソースの記述

- 22.3.2 リソース・コレクションの記述

- 22.3.3 リソース・アイテムの記述

- 22.3.4 ネストされたリソースの記述

- 22.3.5 ADF RESTの記述内のlinksオブジェクト構造の理解

- 22.3.5.1 rel属性の値

- 22.3.5.2 href属性の値

- 22.3.5.3 cardinality属性の値

- 22.4 リソース・バージョンの取得

- 22.4.1 使用可能なすべてのバージョン・リリース名の取得

- 22.4.2 特定バージョンのリソースの取得

- 22.5 ADF RESTリソースの取得

- 22.5.1 リソース・コレクションのフェッチ

- 22.5.2 リソース・コレクションのページング

- 22.5.3 主キー値によるリソース・コレクションのフィルタ処理

- 22.5.4 問合せパラメータによるリソース・コレクションのフィルタ処理

- 22.5.5 リソース・アイテムのフェッチ

- 22.5.6 ネストされた子リソースのフェッチ

- 22.5.7 リソース・コレクションのソート

- 22.6 リソース・アイテムの作成

- 22.6.1 コレクションでのリソース・アイテムの作成

- 22.6.2 子リソース・アイテムの作成

- 22.7 リソース・アイテムの更新

- 22.8 リソース・アイテムの削除

- 22.9 データ整合性のチェック

- 22.9.1 ADF RESTリソース・アイテムの更新時のデータ整合性のチェック

- 22.9.2 ADF RESTリソース・アイテムの取得時のデータ整合性のチェック

- 22.10 添付ファイルの使用

- 22.10.1 リソース・アイテムのエンクロージャ・リンクを使用した添付ファイルのストリーミング

- 22.10.2 Base64を使用したLOBコンテンツの置換

- 22.11 LOVの使用

- 22.11.1 既存のリソース・アイテムのLOV有効属性値の取得

- 22.11.2 リソース・アイテム作成時のLOV有効属性値の取得

- 22.12 高度な操作

- 22.12.1 属性のフィルタ処理による問合せ(部分取得)

- 22.12.2 行検索によるリソース・コレクションのフィルタ処理

- 22.12.3 ペイロードのリソース・データのみを返す

- 22.12.4 リソース・アイテムの推定カウントを返す

- 22.12.5 カスタム・アクションの実行

- 22.12.6 HTTPメソッドのオーバーライドおよび更新の実行

- 22.12.7 バッチ・リクエストの実行

- 22.13 ADF RESTフレームワーク・リファレンス

- 22.13.1 ADF RESTペイロード圧縮のサポート

- 22.13.2 ADF RESTメディア・タイプ

- 22.13.3 ADF RESTデータ型

- 22.13.4 ADF REST HTTPコード

- 22.13.5 ADF REST HTTPヘッダー・サポート

- 22.13.6 ADF REST HTTPメソッドおよびペイロードのサポート

- 22.13.6.1 GETメソッドの操作

- 22.13.6.2 POSTメソッドの操作

- 22.13.6.3 PATCHメソッドの操作

- 22.13.6.4 DELETEメソッド

第IV部 ADFタスク・フローの作成

23 ADFタスク・フローの概説

- 23.1 ADFタスク・フローについて

- 23.1.1 バインドなしタスク・フローについて

- 23.1.2 バインド・タスク・フローについて

- 23.1.3 制御フローについて

- 23.1.4 ADFタスク・フローのユース・ケースと例

- 23.1.5 ADFタスク・フローの追加機能

- 23.2 タスク・フローの作成

- 23.2.1 タスク・フローの作成方法

- 23.2.2 タスク・フロー作成時の処理

- 23.2.3 バインド・タスク・フローのデフォルト・アクティビティに関する必知事項

- 23.2.4 タスク・フローのメモリー・スコープに関する必知事項

- 23.2.5 タスク・フローのソース・ファイルに関する必知事項

- 23.3 タスク・フローへのアクティビティの追加

- 23.3.1 タスク・フローにアクティビティを追加する方法

- 23.3.2 タスク・フローへのアクティビティ追加時の処理

- 23.4 タスク・フローへの制御フロー・ルールの追加

- 23.4.1 タスク・フローに制御フロー・ルールを追加する方法

- 23.4.2 ワイルドカード制御フロー・ルールの追加方法

- 23.4.3 制御フロー・ルールの作成時の処理

- 23.4.4 実行時に行われる処理: タスク・フローで制御フロー・ルールを評価する方法

- 23.5 タスク・フローのテスト

- 23.5.1 ページを含むバインド・タスク・フローの実行方法

- 23.5.2 ページ・フラグメントを使用するバインド・タスク・フローの実行方法

- 23.5.3 パラメータのあるバインド・タスク・フローの実行方法

- 23.5.4 タスク・フローのテスト時にJSFページを実行する方法

- 23.5.5 バインドなしタスク・フローの実行方法

- 23.5.6 プロジェクトの実行構成を設定する方法

- 23.5.7 実行時に行われる処理: タスク・フローのテスト

- 23.6 新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ

- 23.6.1 既存のタスク・フローからバインド・タスク・フローを抽出する方法

- 23.6.2 既存のタスク・フローからのバインド・タスク・フローの抽出時に行われる処理

- 23.6.3 JSFページからのタスク・フローの作成方法

- 23.6.4 バインド・タスク・フローの変換方法

24 タスク・フロー・アクティビティの使用

- 24.1 タスク・フロー・アクティビティについて

- 24.1.1 タスク・フロー・アクティビティのユース・ケースと例

- 24.1.2 タスク・フロー・アクティビティの追加機能

- 24.2 ビュー・アクティビティの使用方法

- 24.2.1 ビュー・アクティビティ間の制御の受渡し

- 24.2.1.1 ビュー・アクティビティ間で制御を渡す方法

- 24.2.1.2 ビュー・アクティビティ間での制御の受渡し時の処理

- 24.2.2 ビュー・アクティビティのブックマーク

- 24.2.2.1 ブックマーク可能なビュー・アクティビティの作成方法

- 24.2.2.2 ブックマーク可能としてのビューの指定時の処理

- 24.2.3 ビュー・アクティビティへのHTTPリダイレクトの指定

- 24.2.3.1 ビュー・アクティビティにHTTPリダイレクトを指定する方法

- 24.2.3.2 ビュー・アクティビティへのHTTPリダイレクト指定時の処理

- 24.2.4 ビュー・アクティビティのURL別名の指定

- 24.2.4.1 ビュー・アクティビティにURL別名を指定する方法

- 24.2.4.2 ビュー・アクティビティへのURL別名指定時の処理

- 24.3 URLビュー・アクティビティの使用

- 24.3.1 タスク・フローへのURLビュー・アクティビティの追加方法

- 24.3.2 タスク・フローへのURLビュー・アクティビティ追加時の処理

- 24.3.3 URLビュー・アクティビティに関する必知事項

- 24.4 ルーター・アクティビティの使用方法

- 24.4.1 ルーター・アクティビティを使用した制御フローの構成方法

- 24.4.2 ルーター・アクティビティを使用した制御フロー構成時の処理

- 24.5 メソッド・コール・アクティビティの使用

- 24.5.1 メソッド・コール・アクティビティの追加方法

- 24.5.2 メソッド・パラメータおよび戻り値の指定方法

- 24.5.3 メソッド・コール・アクティビティ追加時の処理

- 24.6 タスク・フロー・コール・アクティビティの使用

- 24.6.1 タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール方法

- 24.6.2 タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール時の処理

- 24.6.3 タスク・フロー・コール・アクティビティへの入力パラメータの指定方法

- 24.6.4 URLを使用したバインド・タスク・フローのコール方法

- 24.6.5 URLによるバインド・タスク・フロー起動構成時の処理

- 24.6.6 URLを使用したバインド・タスク・フローのコールに関する必知事項

- 24.6.7 タスク・フロー・コール・アクティビティにbefore listenerおよびafter listenerを指定する方法

- 24.6.8 タスク・フロー・コール・アクティビティ追加時の処理

- 24.6.9 実行時に行われる処理: タスク・フロー・コール・アクティビティがタスク・フローを起動する方法

- 24.7 タスク・フロー・リターン・アクティビティの使用

- 24.7.1 タスク・フロー・リターン・アクティビティをバインド・タスク・フローに追加する方法

- 24.7.2 バインド・タスク・フローへのタスク・フロー・リターン・アクティビティ追加時の処理

- 24.8 ページ定義ファイルのあるタスク・フロー・アクティビティの使用

- 24.8.1 タスク・フロー・アクティビティにページ定義ファイルを関連付ける方法

- 24.8.2 タスク・フロー・アクティビティへのページ定義ファイルの関連付け時の処理

25 タスク・フローのパラメータの使用

- 25.1 タスク・フローのパラメータの使用について

- 25.1.1 タスク・フロー・パラメータのユース・ケースと例

- 25.1.2 パラメータを使用したタスク・フローの追加の機能

- 25.2 ビュー・アクティビティへのパラメータ渡し

- 25.2.1 ビュー・アクティビティにパラメータを渡す方法

- 25.2.2 ビュー・アクティビティにパラメータを渡すときの処理

- 25.2.3 パラメータ値の指定に関する必知事項

- 25.3 バインド・タスク・フローへのパラメータ渡し

- 25.3.1 バインド・タスク・フローに入力パラメータを渡す方法

- 25.3.2 バインド・タスク・フローに入力パラメータを渡すときの処理

- 25.4 バインド・タスク・フローの戻り値の構成

- 25.4.1 バインド・タスク・フローからの戻り値の構成方法

- 25.4.2 バインド・タスク・フローからの戻り値を構成したときの動作

26 リージョンとしてのタスク・フローの使用

- 26.1 ADFリージョンでのタスク・フローの使用について

- 26.1.1 ページ・フラグメントおよびADFリージョンについて

- 26.1.2 ビュー・ポートおよびADFリージョンについて

- 26.1.3 タスク・フローおよびADFリージョンのユースケースと例

- 26.1.4 ADFリージョンにレンダリングされるタスク・フローの追加の機能

- 26.2 ADFリージョンの作成

- 26.2.1 ADFリージョンの作成方法

- 26.2.2 ADFリージョン作成時の処理

- 26.3 ADFリージョンのパラメータの指定

- 26.3.1 ADFリージョンにパラメータを指定する方法

- 26.3.2 ADFリージョンのパラメータ指定時の処理

- 26.4 パラメータ・マップを使用したADFリージョンのパラメータの指定

- 26.4.1 ADFリージョンの入力パラメータを指定するためのパラメータ・マップの作成方法

- 26.4.2 入力パラメータを指定するためのパラメータ・マップ作成時の処理

- 26.5 ADFリージョンのリフレッシュの構成

- 26.5.1 ADFリージョンのリフレッシュの構成方法

- 26.5.2 ADFリージョンのリフレッシュの構成に関する必知事項

- 26.6 ADFリージョンのアクティブ化の構成

- 26.6.1 ADFリージョンのアクティブ化の構成方法

- 26.6.2 ADFリージョンのアクティブ化構成時の処理

- 26.7 ADFリージョンのタスク・フロー外への移動

- 26.7.1 ADFリージョンのタスク・フロー外へのナビゲーションをトリガーする方法

- 26.7.2 タスク・フロー外へのナビゲーション構成時の処理

- 26.7.3 ページによるADFリージョンの機能の特定方法に関する必知事項

- 26.8 ADFリージョンのトランザクション管理の構成

- 26.9 ADF動的リージョンの作成

- 26.9.1 ADF動的リージョンの作成方法

- 26.9.2 ADF動的リージョン作成時の処理

- 26.10 ADF動的リージョンへのタスク・フローの追加

- 26.10.1 ADF動的リージョン・リンクの作成方法

- 26.10.2 ADF動的リージョン作成時の処理

- 26.11 複数の不明なリージョンをレンダリングするページの構成

- 26.11.1 複数の不明なリージョンをレンダリングするページの構成方法

- 26.11.2 複数の不明なリージョンをレンダリングするページの構成時の処理

- 26.11.3 複数の不明なリージョンをレンダリングするページの構成に関する必知事項

- 26.12 未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理

- 26.12.1 未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理方法

- 26.12.2 未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理

- 26.13 Fusion Webアプリケーションでのリモート・リージョンの作成

- 26.13.1 リモート・リージョンで使用するタスク・フローを作成するようにアプリケーションを構成する方法

- 26.13.2 リモート・リージョンで使用するタスク・フロー作成時の処理

- 26.13.3 リモート・リージョンの保護に関する必知事項

- 26.13.4 リモート・リージョンをレンダリングするようにアプリケーションを構成する方法

- 26.13.5 リモート・リージョンをレンダリングするようにアプリケーションを構成する場合の処理

- 26.13.6 実行時の処理: アプリケーションによるリモート・リージョンのレンダリング方法

- 26.13.7 カスタム・エラー・メッセージをリモート・リージョンに追加する方法

- 26.13.8 ADFスキンとリモート・リージョンに関する必知事項

27 複雑なタスク・フローの作成

- 27.1 複雑なタスク・フローの作成について

- 27.1.1 複雑なタスク・フローのユース・ケースと例

- 27.1.2 複雑なタスク・フローの追加の機能

- 27.2 タスク・フロー間のデータ・コントロールの共有

- 27.2.1 タスク・フロー間のデータ・コントロールの共有方法

- 27.2.2 タスク・フロー間でのデータ・コントロールの共有時の処理

- 27.2.3 実行時に行われる処理: タスク・フローでデータ・コントロールを共有する方法

- 27.3 タスク・フローのトランザクションの管理

- 27.3.1 バインド・タスク・フローでトランザクションを有効化する方法

- 27.3.2 「Transaction」オプション指定時の処理

- 27.3.3 データ・コントロールの共有およびトランザクションの管理に関する必知事項

- 27.3.3.1 完全に切り離されたトランザクションの作成

- 27.3.3.2 コール先のバインド・タスクと既存のトランザクションとの結合の保証

- 27.3.3.3 可能であれば既存のトランザクションを使用

- 27.3.4 ADFビジネス・コンポーネントのデータベース接続とタスク・フローのトランザクション・オプションに関する必知事項

- 27.4 バインド・タスク・フローの再開

- 27.4.1 再開動作の設定方法

- 27.4.2 結果依存オプションの設定方法

- 27.4.3 再入力のバインド・タスク・フロー構成時の処理

- 27.5 タスク・フローでの例外の処理

- 27.5.1 例外ハンドラとしてアクティビティを指定する方法

- 27.5.2 例外ハンドラとしてアクティビティを指定した場合の処理

- 27.5.3 例外ハンドラとしてカスタム・コードを指定する方法

- 27.5.4 例外ハンドラとしてカスタム・コードを指定した場合の処理

- 27.5.5 トランザクション中の例外の処理に関する必知事項

- 27.5.6 検証エラーの処理に関する必知事項

- 27.6 セーブポイントを使用するためのアプリケーションの構成

- 27.6.1 セーブポイントを使用するためのFusion Webアプリケーションの構成方法

- 27.6.2 セーブポイントを使用するためにFusion Webアプリケーションを構成した場合の処理

- 27.6.3 セーブポイントのデータベース表に関する必知事項

- 27.7 タスク・フローでのセーブポイントの使用

- 27.7.1 タスク・フローへのセーブポイントの追加方法

- 27.7.2 タスク・フローにセーブポイントを追加した場合の処理

- 27.7.3 セーブポイントのリストア方法

- 27.7.4 セーブポイントのリストア時の処理

- 27.7.5 セーブポイント・リストア・ファイナライザの使用方法

- 27.7.6 タスク・フローによるセーブポイント・リストア・ファイナライザ起動時の処理

- 27.7.7 暗黙的なセーブポイントを有効化する方法

- 27.7.8 暗黙的セーブポイントの有効化に関する必知事項

- 27.7.9 セーブポイントの存続時間に関する必知事項

- 27.8 アプリケーションでのアクティブなルート・ビュー・ポート数の最小化

- 27.8.1 アクティブ・ルート・ビュー・ポート数を最小化する方法

- 27.8.2 アクティブ・ルート・ビュー・ポート数を最小化した場合の処理

- 27.9 バインド・タスク・フローでのトレイン・コンポーネントの使用

- 27.9.1 タスク・フローのトレインとしての作成

- 27.9.1.1 バインド・タスク・フローでのトレインの作成方法

- 27.9.1.2 トレインとしてのタスク・フローの作成時の処理

- 27.9.2 トレイン・ストップの子バインド・タスク・フローの起動

- 27.9.2.1 トレイン・ストップから子バインド・タスク・フローを起動する方法

- 27.9.3 トレイン・ストップ間で実行するタスク・フロー・アクティビティのグループ化

- 27.9.4 トレインでのトレイン・ストップの順次動作の無効化

- 27.9.4.1 トレインの順次動作の無効化方法

- 27.9.4.2 トレイン・ストップの順次動作の無効化時の処理

- 27.9.5 トレイン・ストップのラベルの変更

- 27.9.5.1 トレイン・ストップのラベルの変更方法

- 27.9.5.2 トレイン・ストップのラベル変更時の処理

- 27.9.6 トレイン・ストップを省略するトレインの構成

- 27.9.6.1 トレイン・ストップを省略するトレインの構成方法

- 27.9.6.2 トレイン・ストップを省略するトレインの構成時の処理

- 27.10 タスク・フロー・テンプレートの作成

- 27.10.1 タスク・フロー・テンプレートの作成方法

- 27.10.2 タスク・フロー・テンプレートの作成時の処理

- 27.10.3 タスク・フロー・テンプレートに関する必知事項

- 27.11 タスク・フローを使用したページ階層の作成

- 27.11.1 ページ階層の作成方法

- 27.11.1.1 XMLMenuModelメタデータ・ファイルの作成方法

- 27.11.1.2 グループ・ノードおよび子ノードの階層でのサブメニューの作成方法

- 27.11.1.3 メニュー階層を別のメニュー階層に添付する方法

- 27.11.2 ページ階層の作成時の処理

- 27.12 Oracle Fusion Middleware診断フレームワークへのインシデントのレポート

28 アプリケーションでのダイアログの使用

- 28.1 アプリケーションでのダイアログの使用について

- 28.1.1 アプリケーションのユース・ケースと例でのダイアログの使用

- 28.1.2 アプリケーションでダイアログを使用するための追加機能

- 28.2 モーダル・ダイアログ内でのバインド・タスク・フローの実行

- 28.2.1 モーダル・ダイアログ内でのバインド・タスク・フローの実行方法

- 28.2.2 モーダル・ダイアログから値を戻す方法

- 28.2.3 モーダル・ダイアログが戻った場合のページのリフレッシュ方法

- 28.2.4 タスク・フローを使用するアプリケーションのダイアログに関する必知事項

- 28.3 バインド・タスク・フローのかわりとしてのADF Facesダイアログ・フレームワークの使用

- 28.3.1 ダイアログを開くためのJSFナビゲーション・ルールの定義方法

- 28.3.2 ダイアログを開くJSFページの作成方法

- 28.3.3 ダイアログ・ページを作成してダイアログ値を戻す方法

- 28.3.4 実行時に行われる処理: ダイアログからの戻りイベントの呼出し方法

- 28.3.5 ダイアログに値を渡す方法

- 28.3.6 実行時の処理: LaunchEventの処理方法

- 28.3.7 戻り値の処理方法

- 28.3.8 実行時に行われる処理: 起動元コンポーネントのReturnEventの処理方法

第V部 データバインドされたWebユーザー・インタフェースの作成

29 Webインタフェースの概説

- 29.1 ADF Facesを使用したWebアプリケーション開発について

- 29.1.1 ページ・テンプレートおよびマネージドBeanのユースケースと例

- 29.1.2 ページ・テンプレートおよびマネージドBeanの追加機能

- 29.2 ページ・テンプレートの使用方法

- 29.2.1 ADFページ・テンプレートでのADFデータ・バインディングの使用方法

- 29.2.2 ページ・テンプレートにADFモデル・レイヤー・バインディングを使用するときに行われる処理

- 29.2.3 データバインドされたページ・テンプレートをページに動的に追加する方法

- 29.2.4 実行時に行われる処理: ページでのテンプレートの使用方法

- 29.3 Webページの作成

- 29.3.1 Webページの作成方法

- 29.3.2 空白Webページの作成に関する必知事項

- 29.3.3 Webページのセキュリティ保護に関する必知事項

- 29.4 Fusion WebアプリケーションでのマネージドBeanの使用

- 29.4.1 マネージドBeanを使用した情報の格納方法

- 29.4.2 マネージドBeanの作成時に行われる処理

- 29.4.3 サーバー/クラスタ環境でのマネージドBeanメモリー・スコープの設定方法

30 Fusionページ・ライフサイクルの理解

- 30.1 Fusionページ・ライフサイクルについて

- 30.2 JSFページ・ライフサイクルとADFページ・ライフサイクルについて

- 30.2.1 部分ページ・レンダリングおよびイテレータ・バインディングに関する必知事項

- 30.2.2 タスク・フローとライフサイクルに関する必知事項

- 30.3 オブジェクト・スコープ・ライフサイクルについて

- 30.3.1 オブジェクト・スコープとタスク・フローに関する必知事項

- 30.4 ADFページ・ライフサイクルのカスタマイズ

- 30.4.1 カスタム・フェーズ・リスナーの作成方法

- 30.4.2 リスナーをグローバルに登録する方法

- 30.4.3 リスナーの順序に関する必知事項

- 30.4.4 単一ページのライフサイクル・リスナーの登録方法

31 データバインドされた基本的なページの作成

- 31.1 データバインドされた基本的なページの作成について

- 31.1.1 ADFによるデータバインドされたフォームのユースケースと例

- 31.1.2 データバインド・ページの追加機能

- 31.2 データ・コントロール属性を使用したテキスト・フィールドの作成

- 31.2.1 テキスト・フィールドの作成方法

- 31.2.2 テキスト・フィールドの作成時の処理

- 31.2.2.1 ページ定義ファイルに作成されるイテレータ・バインディング

- 31.2.2.2 ページ定義ファイルに作成される値バインディング

- 31.2.2.3 JSFページに作成されるコンポーネント・タグ

- 31.3 データ・コントロールのコレクションを使用した基本的なフォームの作成

- 31.3.1 データ・コントロール・コレクションを使用したフォームの作成方法

- 31.3.2 データ・コントロール・コレクションを使用したフォームの作成時の処理

- 31.4 データ・コントロール操作を使用したコマンド・コンポーネントの作成

- 31.4.1 操作からコマンド・コンポーネントを作成する方法

- 31.4.2 操作を使用したコマンド・コンポーネント作成時の処理

- 31.4.2.1 操作に対して作成されるアクション・バインディング

- 31.4.2.2 定義されるイテレータのRangeSize属性

- 31.4.2.3 操作へバインドするために作成されるEL式

- 31.4.3 実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法

- 31.4.4 宣言メソッドのオーバーライドに関する必知事項

- 31.5 レンジ・ナビゲーションのフォームへの組入れ

- 31.5.1 フォームへのナビゲーション・コントロールの手動の挿入方法

- 31.5.2 手動でナビゲーション・ボタンを追加する場合の処理

- 31.5.3 実行時に行われる処理: ナビゲーション・コントロール

- 31.5.4 ブラウザの「戻る」ボタンおよびレコード間の移動に関する必知事項

- 31.5.5 CacheResultsプロパティに関する必知事項

- 31.6 既存レコードを編集するフォームの作成

- 31.6.1 編集フォームの作成方法

- 31.6.2 フォームの作成時の処理

- 31.6.3 ステートレス・ビジネス・サービスのデータ・コントロールに関する必知事項

- 31.7 フォームを作成するためのパラメータの使用

- 31.7.1 パラメータを使用するフォームの作成方法

- 31.7.2 パラメータ・フォームの作成時の処理

- 31.7.3 実行時に行われる処理: パラメータの移入方法

- 31.8 入力フォームの作成

- 31.8.1 入力フォームの作成方法

- 31.8.1.1 バインド・タスク・フローを使用した入力フォームの作成

- 31.8.1.2 タスク・フロー内でリターン・アクティビティのかわりにコマンド・ボタンを使用する方法

- 31.8.1.3 単一トランザクションでの複数エントリを許可する入力フォームの作成

- 31.8.2 入力フォームの作成時の処理

- 31.8.3 実行時に行われる処理: メソッド・アクティビティからのCreateInsertアクション

- 31.8.4 順序番号の表示に関する必知事項

- 31.8.5 ステートレス・サービスにバックアップされた入力フォームに関する必知事項

- 31.9 動的コンポーネントを使用したフォームの作成

- 31.9.1 動的コンポーネントについて

- 31.9.2 動的フォームの作成方法

- 31.9.3 動的フォームの作成時に発生する処理

- 31.9.3.1 動的フォームに対して作成されるバインディング

- 31.9.3.2 グループ化しないで動的フォームに対して作成されるタグ

- 31.9.3.3 グループ化して動的フォームに対して作成されるタグ

- 31.9.4 実行時に行われる処理: 属性値の動的な決定方法

- 31.9.5 コンバータおよびバリデータの動的コンポーネントへの適用方法

- 31.9.6 動的コンポーネントと静的コンポーネントの混在に関する必知事項

- 31.9.7 動的コンポーネント動作をプログラム的に設定する方法

- 31.9.8 動的コンポーネントをプログラム的にアクセスする方法

- 31.9.9 動的コンポーネントのバインディング・インスタンスにプログラム的にアクセスする方法

- 31.10 フォーム上のUIコンポーネントおよびバインディングの変更

- 31.10.1 UIコンポーネントおよびバインディングの変更方法

- 31.10.2 属性およびバインディングを変更した場合の処理

32 ADFによるデータバインドされた表の作成

- 32.1 ADFによるデータバインドされた表の作成について

- 32.1.1 ADFによるデータバインドされた表のユースケースと例

- 32.1.2 データバインド表の追加機能

- 32.2 基本表の作成

- 32.2.1 基本表の作成方法

- 32.2.2 表の作成時の処理

- 32.2.2.1 表のイテレータと値バインディング

- 32.2.2.2 ADF Faces表のJSFページのコード

- 32.2.3 表での現在行の設定に関する必知事項

- 32.2.4 プログラムを使用した行データの取得に関する必知事項

- 32.2.5 表のスクロール動作と行数に関する必知事項

- 32.3 編集可能な表の作成

- 32.3.1 編集可能な表の作成方法

- 32.3.2 編集可能な表の作成時の処理

- 32.4 入力表の作成

- 32.4.1 入力表の作成方法

- 32.4.2 入力表の作成時の処理

- 32.4.3 実行時に行われる処理: CreateInsertおよび部分ページ更新の動作方法

- 32.4.4 行の作成および列のソートに関する必知事項

- 32.4.5 CreateおよびCreateInsertに関する必知事項

- 32.4.6 JPAベースのデータ・コントロールでの複数行の保存に関する必知事項

- 32.5 コレクションのリスト・ビューの作成

- 32.5.1 データバインドされたリスト・ビューの作成方法

- 32.5.2 データバインド・リスト・ビューの作成時の処理

- 32.6 動的コンポーネントを使用した表の作成

- 32.6.1 動的表の作成方法

- 32.6.2 動的コンポーネント使用時の処理

- 32.6.2.1 グループ化しないで動的表に対して作成されるタグ

- 32.6.2.2 グループ化して動的表に対して作成されるタグ

- 32.6.3 実行時に行われる処理: 属性値の動的な決定方法

- 32.6.4 detailStampファセットを使用した動的表の作成方法

- 32.7 表に表示される属性の変更

- 32.7.1 表示される属性の変更方法

- 32.7.2 表のバインディングの変更方法

- 32.7.3 バインディングまたは表示される属性の変更時に発生する処理

33 ビュー・レイヤーで各機能を起動するコマンド・コンポーネントの使用

- 33.1 コマンド・コンポーネントについて

- 33.1.1 コマンド・コンポーネントのユースケースと例

- 33.1.2 コマンド・コンポーネントの追加機能

- 33.2 メソッドを実行するためのコマンド・コンポーネントの作成

- 33.2.1 カスタム・メソッドにバインドされたコマンド・コンポーネントの作成方法

- 33.2.2 メソッドを使用したコマンド・コンポーネント作成時の処理

- 33.2.2.1 アクション・バインディング

- 33.2.2.2 メソッドのパラメータ

- 33.2.2.3 ADF Facesコンポーネント・コード

- 33.2.2.4 EL式を使用したメソッドへのバインド

- 33.2.2.5 メソッド・コールからの戻り値の使用

- 33.2.3 実行時に行われる処理: コマンド・ボタンのメソッド・バインディング

- 33.3 コマンド・コンポーネントを使用したパラメータ値の設定

- 33.3.1 コマンド・コンポーネント内でのsetPropertyListenerを使用したパラメータの設定方法

- 33.3.2 setPropertyListenerを使用したパラメータ設定時の処理

- 33.3.3 実行時に行われる処理: コマンド・コンポーネントに対するsetPropertyListener

- 33.4 宣言メソッドのオーバーライド

- 33.4.1 宣言メソッドのオーバーライド方法

- 33.4.2 宣言メソッドのオーバーライド時の処理

34 マスター/ディテール・データの表示

- 34.1 マスター/ディテール・データの表示について

- 34.1.1 マスター/ディテールの表、フォームおよびツリーのユースケースと例

- 34.1.2 マスター/ディテール表、フォームおよびツリーの追加機能

- 34.2 マスター/ディテール表、フォームおよびツリーの前提条件

- 34.2.1 「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別方法

- 34.3 表およびフォームを使用したマスター/ディテール・オブジェクトの表示

- 34.3.1 マスター/ディテール・ウィジェットを使用して表およびフォームにマスター/ディテール・オブジェクトを表示する方法

- 34.3.2 個別のコンポーネントからマスター/ディテール・フォームを作成する方法

- 34.3.3 マスター/ディテール表およびフォームの作成時の処理

- 34.3.3.1 マスター/ディテールJSFページで生成されるコード

- 34.3.3.2 マスター/ディテール・ページ定義ファイルで定義されるバインディング・オブジェクト

- 34.3.4 実行時に行われる処理: マスター/ディテール表およびフォームのADFイテレータ

- 34.3.5 個別のページにマスター/ディテール・コンポーネントを表示する方法

- 34.4 ツリーを使用したマスター/ディテール・オブジェクトの表示

- 34.4.1 ツリーでのマスター/ディテール・オブジェクトの表示方法

- 34.4.2 ADFデータバインド・ツリーの作成時の処理

- 34.4.2.1 JSFページで生成されるコード

- 34.4.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

- 34.4.3 実行時に行われる処理: ADFデータバインド・ツリーの表示方法

- 34.4.4 ページの他の部分をツリーの選択と同期する方法

- 34.5 ツリー表を使用したマスター/ディテール・オブジェクトの表示

- 34.5.1 ツリー表でのマスター/ディテール・オブジェクトの表示方法

- 34.5.2 データバインド・ツリー表の作成時の処理

- 34.5.2.1 JSFページで生成されるコード

- 34.5.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

- 34.5.3 実行時に行われる処理: ツリー表のイベント

- 34.6 リスト・ビューを使用したマスター/ディテール・オブジェクトの表示

- 34.6.1 リスト・ビューでのマスター/ディテール・オブジェクトの表示方法

- 34.6.2 マスター/ディテール・リスト・ビューの作成時の処理

- 34.7 ツリーおよびツリー表での選択イベントについて

35 データバインドされた選択リストおよびシャトルの作成

- 35.1 選択リストおよびシャトルについて

- 35.1.1 選択リストとシャトルのユースケースと例

- 35.1.2 選択リストとシャトルの追加機能

- 35.2 値リスト(LOV)のコンポーネントの作成

- 35.2.1 LOVの作成方法

- 35.2.2 LOVの作成時の処理

- 35.2.3 リスト・バリデータとLOVに関する必知事項

- 35.2.4 InputComboboxListOfValuesおよびNULL値に関する必知事項

- 35.3 選択リストの作成

- 35.3.1 モデルドリブン・リストの作成方法

- 35.3.2 モデルドリブン選択リストの作成時の処理

- 35.3.3 固定値を含む選択リストの作成方法

- 35.3.4 固定選択リストの作成時の処理

- 35.3.5 動的に生成される値を含む選択リストの作成方法

- 35.3.6 動的選択リストの作成時の処理

- 35.3.7 選択リストの値に関する必知事項

- 35.4 ナビゲーション・リスト・バインディングを持つリストの作成

- 35.4.1 ナビゲーション・リスト・バインディングを持つリストの作成方法

- 35.4.2 ナビゲーション・リスト・バインディングの作成時の処理

- 35.5 データバインド・シャトルの作成

- 35.5.1 データバインドされたシャトルの作成方法

- 35.5.2 データバインドされたシャトルの作成時の処理

36 ADFによるデータバインドされた検索フォームの作成

- 36.1 検索フォームの作成について

- 36.1.1 暗黙的ビュー基準と名前付きビュー基準

- 36.1.2 値リスト(LOV)入力フィールド

- 36.1.3 検索フォームのユースケースと例

- 36.1.4 検索フォームの追加機能

- 36.2 問合せ検索フォームの作成

- 36.2.1 結果表またはツリー表付きの問合せ検索フォームの作成方法

- 36.2.2 問合せ検索フォームを作成した後で結果コンポーネントを追加する方法

- 36.2.3 保存済の検索をMDSに保存する方法

- 36.2.4 検索フォームの名前付きバインド変数に関する必知事項

- 36.2.5 デフォルトの検索バインディング動作に関する必知事項

- 36.2.6 依存基準に関する必知事項

- 36.2.7 問合せフォーム作成時の処理

- 36.2.8 実行時に行われる処理: 検索フォーム

- 36.3 検索フォーム・プロパティの設定

- 36.3.1 ビュー基準に検索フォーム・プロパティを設定する方法

- 36.3.2 問合せコンポーネントに検索フォーム・プロパティを設定する方法

- 36.3.3 Timestamp属性に対するTimezoneコントロール・ヒントの設定方法

- 36.3.4 カスタム演算子の作成方法

- 36.3.5 標準演算子の削除方法

- 36.3.6 均一な演算子フィールド幅の設定方法

- 36.4 クイック問合せ検索フォームの作成

- 36.4.1 結果表またはツリー表付きのクイック問合せ検索フォームの作成方法

- 36.4.2 クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法

- 36.4.3 クイック問合せのレイアウト書式を設定する方法

- 36.4.4 クイック問合せ検索フォームの作成時の処理

- 36.4.5 実行時に行われる処理: クイック問合せ

- 36.5 スタンドアロンのフィルタ処理された検索表を名前付きビュー基準から作成

- 36.5.1 フィルタ処理された表と例示問合せ検索の作成方法

37 データバインドされたカレンダおよびカルーセル・コンポーネントの作成

- 37.1 データバインドされたADF Facesカレンダおよびカルーセル・コンポーネントについて

- 37.1.1 データバインドされたADF Facesカレンダおよびカルーセル・コンポーネントのユースケースと例

- 37.1.2 データバインドされたADF Facesカレンダおよびカルーセル・コンポーネントの追加機能

- 37.2 ADF Faces Calendarコンポーネントの使用方法

- 37.2.1 ADF Faces Calendarの作成方法

- 37.2.2 カレンダの作成時に行われる処理

- 37.2.3 実行時に行われる処理: カレンダ・バインディングの動作方法

- 37.3 ADF Faces Carouselコンポーネントの使用方法

- 37.3.1 データバインドされたCarouselコンポーネントの作成方法

- 37.3.2 カルーセルの作成時に行われる処理

38 データバインドされたチャート・コンポーネント、統計図表コンポーネントおよびゲージ・コンポーネントの作成

- 38.1 ADFデータ視覚化チャート、統計図表およびゲージ・コンポーネントについて

- 38.1.1 データ視覚化コンポーネントのユースケースと例

- 38.1.2 エンド・ユーザー機能およびプレゼンテーション機能

- 38.1.3 データ視覚化コンポーネントの追加機能

- 38.2 データバインドされたチャートの作成

- 38.2.1 データ・コントロールを使用して面チャート、棒グラフ、複合チャート、横棒グラフまたは折れ線グラフを作成する方法

- 38.2.2 「データ・コントロール」パネルによるチャート作成時の処理

- 38.2.3 データバインドされたファンネル・チャートの作成方法

- 38.2.4 データバインドされた円グラフの作成方法

- 38.2.5 データ・コントロールを使用したデータバインドされたスパーク・チャートの作成

- 38.2.6 データバインドされたバブル・チャートと散布図の作成方法

- 38.2.7 データバインドされた極チャートおよびレーダー・チャートを作成する方法

- 38.2.8 データバインドされた株価チャートの作成方法

- 38.2.9 属性ラベルの使用に関する必知事項

- 38.3 データバインドされたゲージの作成

- 38.3.1 データバインドされたダイアル・ゲージの作成方法

- 38.3.2 データ・コントロールからのダイアル・ゲージの作成時の処理

- 38.3.3 データバインドされた評価ゲージの作成方法

- 38.3.4 データバインドされたADF表へのゲージの組込み

- 38.3.4.1 データバインドされたADF表にゲージを組み込む方法

- 38.3.4.2 ADF表へのゲージの組込み時の処理

- 38.4 データバインドされた統計図表の作成

- 38.4.1 データバインドされた統計図表の作成方法

- 38.4.2 データ・コントロールからの統計図表の作成時の処理

39 データバインドされたNBoxコンポーネントの作成

- 39.1 ADFデータ視覚化NBoxコンポーネントについて

- 39.1.1 エンド・ユーザー機能およびプレゼンテーション機能

- 39.1.2 データ視覚化コンポーネントのユースケースと例

- 39.1.3 データ視覚化コンポーネントの追加機能

- 39.2 データバインドされたNBoxコンポーネントの作成

- 39.2.1 ADFデータ・コントロールを使用したNBoxコンポーネントの作成方法

- 39.2.2 データバインドされたNBoxを作成すると行われる処理

- 39.2.2.1 NBoxコンポーネントのバインディング

- 39.2.2.2 NBoxバインディングの編集

- 39.2.2.3 NBoxコンポーネントのJSFページのコード

- 39.2.2.4 NBoxのプロパティとレイアウトの変更

40 データバインドされたピボット・テーブルおよびピボット・フィルタ・バー・コンポーネントの作成

- 40.1 ADFデータ視覚化ピボット・テーブル・コンポーネントおよびピボット・フィルタ・バー・コンポーネントについて

- 40.1.1 データ視覚化コンポーネントのユースケースと例

- 40.1.2 エンド・ユーザー機能およびプレゼンテーション機能

- 40.1.3 データ視覚化コンポーネントの追加機能

- 40.2 データバインドされたピボット・テーブルの作成

- 40.2.1 ADFデータ・コントロールを使用したピボット・テーブルの作成方法

- 40.2.2 「データ・コントロール」パネルによるピボット・テーブルの作成時の処理

- 40.2.3 ピボット・テーブルの属性の集計に関する必知事項

- 40.2.3.1 重複するデータ行のデフォルトの集計

- 40.2.3.2 重複行のカスタム集計

- 40.2.4 ピボット・テーブルへの初期ソートの指定に関する必知事項

- 40.2.5 編集可能なデータ・セルの構成に関する必知事項

41 データバインドされた地理マップ・コンポーネントおよびテーマ・マップ・コンポーネントの作成

- 41.1 ADFデータ視覚化マップ・コンポーネントについて

- 41.1.1 ユースケースと例

- 41.1.2 エンド・ユーザー機能およびプレゼンテーション機能

- 41.1.3 データ視覚化コンポーネントの追加機能

- 41.2 データバインドされた地理マップの作成

- 41.2.1 地理ベース・マップの構成方法

- 41.2.2 点テーマを使用して地図を作成する方法

- 41.2.3 点テーマの点スタイル・アイテムの作成方法

- 41.2.4 点テーマを使用した地図の作成時の処理

- 41.2.5 マップ点テーマへのカスタム点スタイル・アイテムの追加に関する必知事項

- 41.2.6 色テーマを使用して地理マップを作成する方法

- 41.2.7 地図へのカラー・テーマの追加時の処理

- 41.2.8 マップ・カラー・テーマでの色のカスタマイズに関する必知事項

- 41.2.9 円グラフまたは棒グラフのテーマを使用した地理マップの作成方法

- 41.2.10 地理マップへの円グラフ・テーマまたは棒グラフ・テーマの追加時の処理

- 41.3 データバインドされたテーマ・マップの作成

- 41.3.1 ADFデータ・コントロールを使用してテーマ・マップを作成する方法

- 41.3.2 データ・コントロールを使用したテーマ・マップ作成時の処理

- 41.3.3 テーマ・マップにデータ・レイヤーを追加する方法

- 41.3.3.1 マップ・レイヤーに面データ・レイヤーを追加する方法

- 41.3.3.2 マップ・レイヤーに点データ・レイヤーを追加する方法

- 41.3.4 データを表示するためのエリア、マーカーおよびイメージのスタイル設定

- 41.3.4.1 エリアをスタイル設定してデータを表示する方法

- 41.3.4.2 デフォルト・スタンプを使用してデータを表示するためにマーカーをスタイル設定する方法

- 41.3.4.3 カテゴリ・グループを使用してデータを表示するためにマーカーをスタイル設定する方法

- 41.3.4.4 マーカーのスタイル設定に関する必知事項

- 41.3.4.5 属性グループのデフォルトのスタイル値に関する必知事項

- 41.3.4.6 イメージを使用したデータの表示方法

- 41.3.4.7 マーカー・イメージ・ソースを使用してデータを表示する方法

- 41.3.5 基準となるマップの位置IDに関する必知事項

- 41.3.6 マスター/ディテール関係の構成に関する必知事項

- 41.3.7 カスタム・マップ・レイヤーの定義方法

- 41.3.8 テーマ・マップでドリルを構成する方法

- 41.3.9 データバインドされた凡例の作成

42 データバインドされたガント・チャート・コンポーネントおよび時系列コンポーネントの作成

- 42.1 ADFデータ視覚化コンポーネントについて

- 42.1.1 データ視覚化コンポーネントのユースケースと例

- 42.1.2 エンド・ユーザー機能およびプレゼンテーション機能

- 42.1.3 データ視覚化コンポーネントの追加機能

- 42.2 データバインドされたガント・チャートの作成

- 42.2.1 データバインドされたプロジェクト・ガント・チャートの作成方法

- 42.2.2 データ・コントロールからのプロジェクト・ガント・チャートの作成時の処理

- 42.2.3 データバインドされたリソース使用率ガント・チャートの作成方法

- 42.2.4 リソース使用率ガント・チャート作成時の処理

- 42.2.5 データバインドされたスケジュール・ガント・チャートの作成方法

- 42.2.6 スケジュール・ガント・チャート作成時の処理

- 42.2.7 データ変更イベントの処理に関する必知事項

- 42.3 データバインドされた時系列の作成

- 42.3.1 ADFデータ・コントロールを使用した時系列の作成方法

- 42.3.2 データ・コントロールを使用した時系列作成時の処理

- 42.3.3 データ・コントロールを使用した二重時系列の作成に関する必知事項

43 データバインドされた階層ビューア、ツリーマップおよびサンバースト・コンポーネントの作成

- 43.1 ADFデータ視覚化コンポーネントについて

- 43.1.1 エンド・ユーザー機能およびプレゼンテーション機能

- 43.1.2 データ視覚化コンポーネントのユースケースと例

- 43.1.3 データ視覚化コンポーネントの追加機能

- 43.2 データバインドされた階層ビューアの作成

- 43.2.1 ADFデータ・コントロールを使用して階層ビューアを作成する方法

- 43.2.2 データバインドされた階層ビューアの作成時の処理

- 43.2.3 データバインドされたパネル・カード用に代替ビュー・オブジェクトを構成する方法

- 43.2.3.1 階層ビューアのパネル・カードに代替ビュー・オブジェクトを使用する場合の処理

- 43.2.4 階層ビューアでのデータバインドされた検索の作成方法

- 43.3 データバインドされたツリーマップおよびサンバーストの作成

- 43.3.1 ADFデータ・コントロールを使用したツリーマップおよびサンバーストの作成方法

- 43.3.2 データバインドされたツリーマップまたはサンバーストの作成時の処理

- 43.3.3 実行時に行われる処理: データバインドされたサンバーストまたはツリーマップの初期表示

44 データバインドされたダイアグラム・コンポーネントの作成

- 44.1 ADFデータ視覚化ダイアグラム・コンポーネントについて

- 44.1.1 エンド・ユーザー機能およびプレゼンテーション機能

- 44.1.2 データ視覚化コンポーネントのユースケースと例

- 44.1.3 データ視覚化コンポーネントの追加機能

- 44.2 データバインドされたダイアグラム・コンポーネントの作成

- 44.2.1 ADFデータ・コントロールを使用したダイアグラムの作成方法

- 44.2.2 データバインドされたダイアグラムを作成すると行われる処理

- 44.2.2.1 ダイアグラム・コンポーネントのバインディング

- 44.2.2.2 ダイアグラム・コンポーネントのJSFページのコード

- 44.2.2.3 デフォルト・クライアント・レイアウトのファイルおよび場所

- 44.2.2.4 ダイアグラムのプロパティとレイアウトの変更

45 データバインドされたタグ・クラウド・コンポーネントの作成

- 45.1 ADFデータ視覚化タグ・クラウド・コンポーネントについて

- 45.1.1 データ視覚化コンポーネントのユースケースと例

- 45.1.2 エンド・ユーザー機能およびプレゼンテーション機能

- 45.1.3 データ視覚化コンポーネントの追加機能

- 45.2 データバインドされたタグ・クラウド・コンポーネントの作成

- 45.2.1 データバインドされたタグ・クラウドの作成方法

- 45.2.2 データバインドされたタグ・クラウドの作成時の処理

46 コンテキスト・イベントの使用

- 46.1 コンテキスト・イベントの作成について

- 46.1.1 コンテキスト・イベントのユースケースと例

- 46.1.2 コンテキスト・イベントのその他の機能

- 46.2 コンテキスト・イベントの宣言的な作成

- 46.2.1 コンテキスト・イベントの公開方法

- 46.2.2 コンテキスト・イベントをサブスクライブおよび使用する方法

- 46.2.3 コンテキスト・イベントの作成時の処理

- 46.2.4 コンテキスト・イベント・ディスパッチの制御方法

- 46.2.5 実行時に行われる処理: コンテキスト・イベント

- 46.3 コンテキスト・イベントの手動作成

- 46.3.1 コンテキスト・イベントの手動作成方法

- 46.4 マネージドBeanを使用したコンテキスト・イベントの作成

- 46.4.1 マネージドBeanを使用したコンテキスト・イベントの作成方法

- 46.4.2 マネージドBeanを使用したコンテキスト・イベントの作成時の処理

- 46.4.3 マネージドBeanを使用したコンテキスト・イベントの動的作成および操作の方法

- 46.5 プレーンJavaオブジェクト(POJO)を使用したコンテキスト・イベントの作成

- 46.5.1 タスク・フローに対して汎用コールバック・メッセージ・ハンドラを構成する方法

- 46.6 JavaScriptを使用したコンテキスト・イベントの作成

- 46.7 イベント・マップの手動作成

- 46.7.1 イベント・マップの手動による作成方法

- 46.8 カスタム・ディスパッチャの登録

- 46.8.1 カスタム・ディスパッチャの登録方法

第VI部 アプリケーションの完成

47 Fusion WebアプリケーションでのADFセキュリティの有効化

- 47.1 ADFセキュリティについて

- 47.1.1 ADFセキュリティとJavaセキュリティの統合

- 47.1.2 ADFセキュリティのユースケースと例

- 47.1.3 ADFセキュリティの追加機能

- 47.2 ADFセキュリティ・プロセスの概要

- 47.3 ADFセキュリティの有効化

- 47.3.1 ADFセキュリティを有効化する方法

- 47.3.2 ADFセキュリティを有効にしたときの処理

- 47.3.3 デフォルトのフォームベース・ログイン・ページ生成時の処理

- 47.3.4 「ADFセキュリティの構成」ウィザードに関する必知事項

- 47.3.5 ADF認証に関する必知事項

- 47.3.6 組込みtest-allロールに関する必知事項

- 47.3.7 valid-usersロールに関する必知事項

- 47.4 アプリケーション・ロールの作成

- 47.4.1 アプリケーション・ロールを作成する方法

- 47.4.2 アプリケーション・ロール作成時の処理

- 47.4.3 エンタープライズ・ロールとアプリケーション・ロールに関する必知事項

- 47.5 ADFセキュリティ・ポリシーの定義

- 47.5.1 ADFリソースを公開する方法

- 47.5.2 ADFリソースの公開時の処理

- 47.5.3 実行時に行われる処理: 組込みロールの使用方法

- 47.5.4 ADFバインド・タスク・フローのポリシーを定義する方法

- 47.5.5 ページ定義を参照するWebページのポリシーを定義する方法

- 47.5.6 ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法

- 47.5.6.1 ADFメソッドへのアクセスを制御するリソース権限の作成

- 47.5.6.2 ユーザー・インタフェースによるリソース権限の施行

- 47.5.7 セキュリティ・ポリシーの定義時の処理

- 47.5.8 実行時に行われる処理: ADFセキュリティ・ポリシーの実施方法

- 47.5.9 ADFバインドなしのページのポリシー定義に関する必知事項

- 47.5.10 正規表現を使用したリソース・グループのポリシーの定義方法

- 47.5.11 データのポリシーを定義する方法

- 47.5.11.1 ADFエンティティ・オブジェクトに対する権限マップの定義

- 47.5.11.2 ADFエンティティ・オブジェクト属性に対する権限マップの定義

- 47.5.11.3 ADFエンティティ・オブジェクトおよびエンティティ属性に対する権限の付与

- 47.5.12 リソース権限を資格付与として集約する方法

- 47.5.13 資格作成後の処理

- 47.6 テスト・ユーザーの作成

- 47.6.1 JDeveloperでテスト・ユーザーを作成する方法

- 47.6.2 テスト・ユーザー作成時の処理

- 47.6.3 テスト・ユーザーとアプリケーション・ロールを関連付ける方法

- 47.6.4 アプリケーション・ロール構成時の処理

- 47.7 ログイン・ページの作成

- 47.7.1 明示的な認証用にログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法

- 47.7.2 明示的な認証用のログイン・ページを作成する方法

- 47.7.2.1 バッキングBeanのログイン・コードの作成

- 47.7.2.2 明示的な認証用のADF Facesベースのログイン・ページの作成

- 47.7.2.3 ログイン・ページのパブリック化の確認

- 47.7.3 カスタム・ログイン・ページのリソースを明示的な認証時にアクセス可能にする方法

- 47.7.4 パブリックなようこそページの作成方法

- 47.7.4.1 ようこそページのパブリック化の確認

- 47.7.4.2 ログイン・リンクおよびログアウト・リンクの追加

- 47.7.4.3 セキュアなページへのリンクの非表示化

- 47.7.5 認証後にユーザーをリダイレクトする方法

- 47.7.6 暗黙的な認証用のカスタム・ログイン・ページをトリガーする方法

- 47.7.7 リダイレクト宛先ページを確実に使用可能にする方法

- 47.7.8 異なるホスト・サーバーへのリダイレクトに関する必知事項

- 47.7.9 Fusion Webアプリケーション・ログアウトおよびブラウザ・キャッシュに関する必知事項

- 47.7.10 IBM WebSphere Application Serverに関する必知事項

- 47.7.11 Internet Explorerでのエラー・ページの表示に関する必知事項

- 47.8 JDeveloperでのセキュリティのテスト

- 47.8.1 セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法

- 47.8.2 セキュリティ・デプロイメント・オプション構成時の処理

- 47.8.3 組込みtest-allアプリケーション・ロールを使用する方法

- 47.8.4 実行時に行われる処理: ADFセキュリティによる認証の処理

- 47.8.5 実行時に行われる処理: ADFセキュリティによる認可の処理

- 47.9 セキュア・アプリケーションのデプロイの準備

- 47.9.1 アプリケーション・ポリシー・ストアからtest-allロールを削除する方法

- 47.9.2 アプリケーション・アイデンティティ・ストアからテスト・ユーザーを削除する方法

- 47.9.3 URL制約を使用してリソース・ファイルをセキュリティ保護する方法

- 47.10 ADFセキュリティの無効化

- 47.10.1 ADFセキュリティを無効化する方法

- 47.10.2 ADFセキュリティを無効にしたときの処理

- 47.11 高度なトピックとベスト・プラクティス

- 47.11.1 ADFセキュリティでの式言語(EL)の使用

- 47.11.1.1 ELを使用したポリシーの評価方法

- 47.11.1.2 「式ビルダー」ダイアログの使用時の処理

- 47.11.1.3 ELの遅延評価に関する必知事項

- 47.11.2 OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法

- 47.11.2.1 カスタム・リソース・タイプの作成

- 47.11.2.2 カスタム・リソース・タイプに対するリソース権限の作成

- 47.11.2.3 UIコンポーネントのレンダリングとリソース権限との関連付け

- 47.11.3 エンティティ・オブジェクト操作の認可チェックの実行方法

- 47.11.4 ADFセキュリティ・コンテキストからの情報の取得

- 47.11.4.1 セキュリティが有効かどうかの判定方法

- 47.11.4.2 ユーザーが認証済かどうかの判定方法

- 47.11.4.3 現在のユーザー名の判別方法

- 47.11.4.4 Java EEセキュリティ・ロールのメンバーシップの判別方法

- 47.11.4.5 Javaを使用して権限を判別する方法

- 47.11.5 ADFセキュリティの操作のベスト・プラクティス

48 ADFコンポーネントのテストとデバッグ

- 48.1 ADFのデバッグについて

- 48.2 単純なOracle ADFコンパイル・エラーの修正

- 48.3 単純なOracle ADFランタイム・エラーの修正

- 48.4 統合WebLogic ServerのOracle ADFのメタデータのリロード

- 48.5 ADFコントローラのメタデータの検証

- 48.6 ADFロガーの使用

- 48.6.1 ADFロギング・レベルを設定する方法

- 48.6.2 Oracle ADFデバッグ構成の作成方法

- 48.6.3 Oracle ADF以外のロガーの診断ロギングを有効化する方法

- 48.6.4 ログ・アナライザを使用してログ・メッセージを表示する方法

- 48.6.4.1 ログ・アナライザでの診断メッセージの表示

- 48.6.4.2 ADFリクエストを分析するためのログ・アナライザの使用

- 48.6.4.3 ADFイベントに基づく診断メッセージのソート

- 48.6.5 ADFロガーおよびログ・レベルに関する必知事項

- 48.6.6 ADFロギングおよびログ出力に関する必知事項

- 48.6.7 ADFロギングとOracle WebLogic Serverに関する必知事項

- 48.7 テストとデバッグのためのOracle ADFモデル・テスターの使用

- 48.7.1 デバッグ・モードでの実行方法およびOracle ADFモデル・テスターでのテスト方法

- 48.7.2 Oracle ADFモデル・テスターを実行して特定のアプリケーション・モジュール構成を使用してテストする方法

- 48.7.3 デバッグ・モードでOracle ADFモデル・テスター実行時の処理

- 48.7.4 Oracle ADFモデル・テスターで実行時アーティファクトを確認する方法

- 48.7.5 アプリケーションの変更内容でOracle ADFモデル・テスターをリフレッシュする方法

- 48.8 ADF宣言デバッガの使用

- 48.8.1 デバッガでのADFソース・コードの使用

- 48.8.2 ADFソース・ユーザー・ライブラリの設定方法

- 48.8.3 ADFソース・ライブラリのプロジェクトへの追加方法

- 48.8.4 EL式エバリュエータの使用

- 48.8.5 スタック・トレース情報を表示およびエクスポートする方法

- 48.9 ADF宣言ブレークポイントの設定

- 48.9.1 タスク・フロー・アクティビティ・ブレークポイントの設定方法および使用方法

- 48.9.2 ページ定義実行可能ファイル・ブレークポイントの設定方法および使用方法

- 48.9.3 ページ定義アクション・バインディング・ブレークポイントの設定方法および使用方法

- 48.9.4 ページ定義値バインディング・ブレークポイントの設定方法および使用方法

- 48.9.5 ページ定義コンテキスト・イベント・ブレークポイントの設定方法および使用方法

- 48.9.6 ADFライフサイクル・フェーズ・ブレークポイントの設定方法および使用方法

- 48.9.7 「ADF構造」ウィンドウの使用方法

- 48.9.8 ADFデータ・ウィンドウの使用方法

- 48.9.9 ADF宣言ブレークポイント設定時の処理

- 48.10 JavaコードとGroovyスクリプトのブレークポイントの設定

- 48.10.1 Groovyスクリプトのブレークポイントの設定方法

- 48.10.2 クラスおよびメソッド上にJavaブレークポイントを設定する方法

- 48.10.3 ソース・エディタの使用を最適化する方法

- 48.10.4 ADFソース・コードを使用してブレークポイントを設定およびデバッグする方法

- 48.10.5 シンボリック・デバッグでデバッグ・ライブラリを使用する方法

- 48.10.6 Javaコード・ブレークポイントの設定に関する必知事項

- 48.10.7 コントロール向上のためのブレークポイントの編集方法

- 48.10.8 クラス・メンバーのビューのフィルタリング方法

- 48.10.9 Oracle ADFブレークポイントに関する必知事項

- 48.11 ビジネス・コンポーネント内のGroovy式のデバッグ

- 48.11.1 Groovy式をデバッグする方法

- 48.11.2 Groovyのデバッグを制御する方法

- 48.11.3 Groovy式のデバッグ時の処理

- 48.12 JUnitを使用した回帰テスト

- 48.12.1 JUnit拡張機能を取得する方法

- 48.12.2 JUnitテスト・ケースの作成方法

- 48.12.3 JUnitテスト・フィクスチャの作成方法

- 48.12.4 JUnitテスト・スイートの作成方法

- 48.12.5ビジネス・コンポーネント・テスト・スイートの作成方法

- 48.12.6ビジネス・コンポーネント・テスト・フィクスチャの作成方法

- 48.12.7 Antビルド・スクリプトの一部としてのJUnitテスト・スイートの実行方法

49 Fusion Webアプリケーションのリファクタ

- 49.1 Fusion Webアプリケーションのリファクタについて

- 49.1.1 リファクタのユースケースと例

- 49.1.2 リファクタの追加機能

- 49.2 ファイルの名前の変更

- 49.3 JSFページの移動

- 49.4 pagedef.xmlバインディング・オブジェクトのリファクタ

- 49.5 ADFビジネス・コンポーネントのリファクタ

- 49.6 ADFビジネス・コンポーネント・オブジェクト属性のリファクタ

- 49.7 名前付き要素のリファクタ

- 49.8 ADFタスク・フローのリファクタ

- 49.9 DataBindings.cpxファイルのリファクタ

- 49.10 リファクタの制限

- 49.11 ADFビジネス・コンポーネント・プロジェクト構成ファイル (.jpx)の移動

50 アプリケーション・コンポーネントの再利用

- 50.1 再利用可能なコンポーネントについて

- 50.1.1 再利用可能なコンポーネントの作成

- 50.1.1.1 ネーミング規則

- 50.1.1.1.1 パッケージのネーミングに関する考慮事項

- 50.1.1.1.2 接続のネーミングに関する考慮事項

- 50.1.1.1.3 EJBプロジェクトを含むアプリケーションのネーミングに関する考慮事項

- 50.1.1.2 ADFライブラリJARデプロイメント・プロファイルのネーミング・プロセス

- 50.1.1.3 関連プロジェクトの保持

- 50.1.1.4 関連機能の選択

- 50.1.1.5 パスおよびフォルダの選択

- 50.1.1.6 再利用可能なコンポーネント内への接続の組込み

- 50.1.2 再利用可能なADFコンポーネントのユースケースと例

- 50.1.3 再利用可能なADFコンポーネントの追加機能

- 50.1.4 再利用可能なADFコンポーネントの共通機能

- 50.1.4.1 拡張機能ライブラリの使用方法

- 50.1.4.2 「リソース」ウィンドウの使用

- 50.2 ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化

- 50.2.1 コンポーネントをADFライブラリJARにパッケージ化する方法

- 50.2.2 ADFライブラリJARへのプロジェクトのパッケージ化時の処理

- 50.2.2.1 JARにパッケージ化されるアプリケーション・モジュール・ファイル

- 50.2.2.2 JARにパッケージ化されるデータ・コントロール・ファイル

- 50.2.2.3 JARにパッケージ化されるタスク・フロー・ファイル

- 50.2.2.4 JARにパッケージ化されるページ・テンプレート・ファイル

- 50.2.2.5 JARにパッケージ化される宣言コンポーネント・ファイル

- 50.2.3 JARファイルの配置方法とアクセス方法

- 50.3 プロジェクトへのADFライブラリ・コンポーネントの追加

- 50.3.1 「リソース」ウィンドウを使用してプロジェクトにADFライブラリJARを追加する方法

- 50.3.2 ADFライブラリJARをプロジェクトに手動で追加する方法

- 50.3.3 プロジェクトへのADFライブラリJARの追加時の処理

- 50.3.4 ADFライブラリのコンポーネントの使用に関する必知事項

- 50.3.4.1 データ・コントロールの使用方法

- 50.3.4.2 アプリケーション・モジュールの使用方法

- 50.3.4.3 ビジネス・コンポーネントの使用方法

- 50.3.4.4 タスク・フローの使用方法

- 50.3.4.5 ページ・テンプレートの使用方法

- 50.3.4.6 宣言コンポーネントの使用方法

- 50.3.5 ADFライブラリのコンポーネントの区別に関する必知事項

- 50.3.6 実行時に行われる処理: プロジェクトへのADFライブラリの追加方法

- 50.4 プロジェクトからのADFライブラリJARの削除

- 50.4.1 「リソース」ウィンドウを使用してプロジェクトからADFライブラリJARを削除する方法

- 50.4.2 ADFライブラリJARをプロジェクトから手動で削除する方法

51 MDSによるアプリケーションのカスタマイズ

- 51.1 カスタマイズおよびMDSについて

- 51.1.1 カスタマイズおよびレイヤーのユースケースおよび例

- 51.1.2 静的および動的なカスタマイズ・コンテンツ

- 51.1.3 カスタマイズの追加機能

- 51.2 カスタマイズ可能なアプリケーションの開発

- 51.2.1 カスタマイズ・クラスの作成方法

- 51.2.1.1 カスタマイズ・クラス

- 51.2.1.2 カスタマイズ・クラスでのgetValue()メソッドの実装

- 51.2.1.3 カスタマイズ・クラスの作成

- 51.2.2 カスタマイズ・クラスに関する必知事項

- 51.2.3 カスタマイズ・クラスの使用方法

- 51.2.3.1 設計時にJDeveloperでカスタマイズ・クラスを使用可能にする

- 51.2.3.2 実行時にアプリケーションでカスタマイズ・クラスを使用可能にする

- 51.2.4 ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法

- 51.2.5 既存のページでシード・カスタマイズを有効化する方法

- 51.2.6 リソース・バンドルでカスタマイズを有効化する方法

- 51.2.7 adf-config.xmlファイルの構成方法

- 51.2.8 カスタマイズ可能アプリケーション作成時の処理内容

- 51.2.9 カスタマイズ可能なオブジェクトおよびアプリケーションに関する必知事項

- 51.3 アプリケーションのカスタマイズ

- 51.3.1 「カスタマイズ開発者」ロールの概要

- 51.3.2 JDeveloperでの「カスタマイズ開発者」ロールへの切替え

- 51.3.3 ヒント・レイヤーの概要

- 51.3.4 カスタマイズ・レイヤーの構成方法

- 51.3.4.1 レイヤー値をグローバルに構成

- 51.3.4.2 Studio開発者ロールでのワークスペースレベルのレイヤー値の構成

- 51.3.4.3 「カスタマイズ開発者」ロールでのワークスペースレベルのレイヤー値の構成

- 51.3.5 JDeveloperでメタデータをカスタマイズする方法

- 51.3.6 アプリケーションのカスタマイズ時の処理内容

- 51.3.7 JDeveloperでADFライブラリ・アーティファクトをカスタマイズする方法

- 51.3.7.1 ADFライブラリ・アーティファクトのカスタマイズ

- 51.3.7.2 ADFライブラリのカスタマイズの場所の指定

- 51.3.8 エクスポートしたJARからのADFライブラリ・ランタイム・カスタマイズの表示方法

- 51.3.9 ADFライブラリ・アーティファクトのカスタマイズ時の処理内容

- 51.3.10 実行時の処理: カスタマイズの適用方法

- 51.3.11 カスタマイズしたアプリケーションに関する必知事項

- 51.3.11.1 カスタマイズおよび統合ソース・コントロール

- 51.3.11.2 カスタマイズしたアプリケーションでのリソース・バンドルの編集

- 51.4 カスタマイズしたアプリケーションをパッケージ化してデプロイする方法

- 51.4.1 MARプロファイルの暗黙的作成

- 51.4.2 MARプロファイルの明示的作成

- 51.5 拡張メタデータ・プロパティ

- 51.5.1 拡張メタデータ・プロパティを編集する方法

- 51.5.2 実行時のデザインタイムのカスタマイズを有効化する方法

- 51.5.2.1 「プロパティ」ウィンドウでのカスタマイズ・プロパティの編集

- 51.5.2.2 スタンドアロン注釈ファイルを使用してタイプ・レベル・カスタマイズ・プロパティを指定する

- 51.6 カスタマイズ構成の実行時変更の有効化

52 実行時のユーザー・カスタマイズの許可

- 52.1 ユーザー・カスタマイズについて

- 52.1.1 実行時ユーザー・カスタマイズのユースケースおよび例

- 52.1.2 実行時ユーザー・カスタマイズの追加機能

- 52.2 Fusion Webアプリケーションの実行時ユーザー・カスタマイズの有効化

- 52.2.1 ユーザー・カスタマイズを有効にする方法

- 52.2.2 ユーザー・カスタマイズを有効化する場合の処理

- 52.3 ユーザー・カスタマイズの構成

- 52.3.1 変更永続性の構成方法

- 52.3.2 変更永続性の構成時の処理

- 52.4 個々のJSFページでのユーザー・カスタマイズの制御

- 52.4.1 JSFページでのユーザー・カスタマイズの制御方法

- 52.4.2 実行時の処理: 変更をどのように永続させるか

- 52.4.3 テンプレートおよび領域での変更永続性の使用に関する必知事項

- 52.5 カスタム・ユーザー・カスタマイズの実装

- 52.5.1 変更永続性フレームワークAPIに関する必知事項

- 52.5.2 カスタム・ユーザー・カスタマイズ用のコードを作成する方法

- 52.6 カスタム・コンポーネントでの暗黙的な変更永続性の作成

- 52.6.1 イベントを使用する属性値への暗黙的な変更永続性の設定方法

- 52.6.2 他の属性値への暗黙的な変更永続性の設定方法

53 アクティブ・データ・サービスの使用

- 53.1 アクティブ・データ・サービスについて

- 53.1.1 アクティブ・データ・サービスのユースケースおよび例

- 53.1.2 アクティブ・データ・サービス・フレームワークの制限

- 53.1.3 アクティブ・データ・サービス・フレームワーク

- 53.1.4 データ・トランスポート・モード

- 53.2 アクティブ・データ・サービスの構成

- 53.2.1 アクティブ・データ・サービスの構成方法

- 53.2.2 ADSトランスポート・モードの構成に関する必知事項

- 53.2.3 アクティブ・データ・サービスのセッション・タイムアウトの構成方法

- 53.3 アクティブ・データ・サービスの使用に向けたコンポーネントの構成

- 53.3.1 アクティブ・データ・プロキシを使わずに、アクティブ・データ・サービスの使用に向けたコンポーネントを構成する方法

- 53.3.2 アクティブ・データ・プロキシを使ったアクティブ・データ・サービスの使用に向けたコンポーネントを構成する方法

- 53.3.3 ADFツリーでのアクティブ・データの表示に関する必知事項

- 53.3.4 実行時に行われる処理: アクティブ・データにバインドされている場合のコンポーネントのレンダリング方法

- 53.3.5 Google ChromeブラウザでのADSの実行に関する必知事項

- 53.4 アクティブ・データ・プロキシの使用

- 53.4.1 アクティブ・データ・プロキシの使用方法

- 53.5 読取り一貫性の維持に関する必知事項

- 53.6 アクティブ・データとスカラー・モデルの併用

- 53.6.1 アクティブ・データとスカラー・モデルの併用方法

54 Fusion Webアプリケーションの高可用性の構成

- 54.1 Oracle ADF高可用性について

- 54.1.1 Oracle ADFスコープとセッション状態の考慮事項

- 54.1.2 Oracle ADFのフェイルオーバーおよび予想される動作の考慮事項

- 54.1.2.1 セッションのフェイルオーバー要件

- 54.1.2.2 アプリケーションのフェイルオーバーで予想される動作

- 54.1.3 Oracle RACのADFアプリケーション・モジュールの考慮事項

- 54.2 高可用性のためのOracle ADFの構成

- 54.2.1 高可用性のためのアプリケーション・モジュールの構成方法

- 54.2.2 HTTPセッション状態のレプリケートのサポートを有効にする方法

- 54.2.3 マネージドBeanの変更からOracle ADFが通知を受信することを確認する方法

- 54.2.4 クラスタ環境でのアプリケーション・スコープのマネージドBeanの使用に関する必知事項

- 54.2.5 設計時の最適化を無効にする方法

- 54.3 高可用性のためのFusion Webアプリケーションのトラブルシューティング

- 54.3.1 フェイル・オーバー・モードが有効なFusion Webアプリケーションをテストする方法

- 54.3.2 設計時の高可用性の問題をトラブルシューティングする方法

- 54.3.3 デプロイメント後の高可用性の問題をトラブルシューティングする方法

- 54.3.3.1 JRFランタイムのインストールの確認

- 54.3.3.2 すべてのアプリケーションが正常にデプロイされたかどうかの確認

- 54.3.4 Oracle ADFのレプリケーションおよびフェイルオーバーの問題をトラブルシューティングする方法

55 Fusion Webアプリケーションのデプロイ

- 55.1 Fusion Webアプリケーションのデプロイについて

- 55.1.1 統合WebLogic Serverを使用したアプリケーションの開発

- 55.1.2 スタンドアロン・アプリケーション・サーバーにデプロイするためのアプリケーションの開発

- 55.2 統合WebLogic ServerでのFusion Webアプリケーションの実行

- 55.2.1 統合WebLogic Serverでのアプリケーションの実行方法

- 55.2.2 統合WebLogic Serverでのメタデータを含むアプリケーションの実行方法

- 55.3 アプリケーションの準備

- 55.3.1 ターゲット・アプリケーション・サーバーへの接続の作成方法

- 55.3.2 デプロイメント・プロファイルの作成方法

- 55.3.2.1 WARデプロイメント・プロファイルの作成

- 55.3.2.2 MARデプロイメント・プロファイルの作成

- 55.3.2.3 アプリケーション・レベルのEARデプロイメント・プロファイルの作成

- 55.3.2.4 JARへのカスタマイズ・クラスの追加

- 55.3.2.5 共有ライブラリとしてのカスタマイズ・クラスの配布

- 55.3.2.6 デプロイメント・プロファイル・プロパティの表示および変更

- 55.3.3 デプロイメント・ディスクリプタの作成および編集方法

- 55.3.3.1 デプロイメント・ディスクリプタの作成

- 55.3.3.2 デプロイメント・ディスクリプタ・プロパティの表示または変更

- 55.3.3.3 アプリケーション・サーバー互換のapplication.xmlファイルの構成

- 55.3.3.4 アプリケーション・サーバー互換のweb.xmlファイルの構成

- 55.3.3.5 RUEIの適用とクリック履歴の有効化

- 55.3.4 ADFセキュリティを有効にしたアプリケーションのデプロイ方法

- 55.3.4.1 Oracle Single Sign-On (SSO)を使用して実行するアプリケーション

- 55.3.4.2 Weblogic Serverのセキュリティ構成

- 55.3.4.2.1 WebLogic用のJDBC URLを使用するアプリケーション

- 55.3.4.2.2 WebLogic用のJDBCデータ・ソースを使用するアプリケーション

- 55.3.4.3 WebSphere Application Serverのセキュリティ構成

- 55.3.4.3.1 WebSphere用のJDBC URLを使用するアプリケーション

- 55.3.4.3.2 WebSphere用のJDBCデータ・ソースを使用するアプリケーション

- 55.3.4.3.3 web.xmlファイルの編集によるWebSphereのアプリケーション・ルートの保護

- 55.3.5 クラスタ環境でのメモリー・スコープのレプリケート方法

- 55.3.6 アプリケーションをADF MBeanに対して有効化する方法

- 55.3.7 Oracle WebLogic Server用のJDBCデータソースに関する必知事項

- 55.4 アプリケーションのデプロイ

- 55.4.1 JDeveloperからアプリケーション・サーバーへのデプロイ方法

- 55.4.2 デプロイメント用のEARファイルの作成方法

- 55.4.3 ADFライブラリに適用された新しいカスタマイズのデプロイ方法

- 55.4.3.1 デプロイ済アプリケーションへのカスタマイズのエクスポート

- 55.4.3.2 JARへのカスタマイズのデプロイ

- 55.4.4 ADFライブラリに関する必知事項

- 55.4.5 EARファイルとパッケージ化に関する必知事項

- 55.4.6 スクリプトとAntを使用したアプリケーションのデプロイ方法

- 55.4.7 ADF FacesライブラリJARをアプリケーションとともにデプロイする方法

- 55.4.8 JDeveloperランタイム・ライブラリに関する必知事項

- 55.5 デプロイメント後の構成

- 55.5.1 アプリケーションの移行方法

- 55.5.2 ADF MBeanを使用したアプリケーションの構成方法

- 55.5.3 結果セットを再利用するためのWebSphereの構成方法

- 55.6 アプリケーションのテストとデプロイの検証

56 Fusion Webアプリケーションでの状態管理の使用

- 56.1 Fusion Webアプリケーションの状態管理について

- 56.1.1 マルチステップ・タスクに関する必知事項

- 56.1.2 ステートレスHTTPプロトコルに関する必知事項

- 56.1.3 セッションCookieに関する必知事項

- 56.1.4 HttpSessionの使用に関する必知事項

- 56.2 受動化とアクティブ化が行われるタイミングの管理

- 56.2.1 Fusion Webアプリケーションがオプティミスティック・ロックを使用していることを確認する方法

- 56.2.2 HTTPリクエストでの保留中の変更に関する必知事項

- 56.2.3 解放レベルおよびpostChanges()メソッドに関する必知事項

- 56.3 アプリケーション・モジュールの能動化が安全であることの確認テスト

- 56.3.1 能動化をテストするためにアプリケーション・モジュール・プーリングを無効化する方法

- 56.3.2 jbo.ampool.doampooling構成パラメータに関する必知事項

- 56.3.3 状態管理とデータの整合性に関する必知事項

- 56.3.4 状態管理とサブクラス化エンティティ・オブジェクトに関する必知事項

- 56.4 モデル状態が保存される場所の制御

- 56.4.1 状態管理表が存在するスキーマの制御方法

- 56.4.2 受動化ストアを構成する方法

- 56.4.3 実行時に行われる処理: 保存されるモデル状態とそのクリーンアップのタイミング

- 56.5 モデル状態のクリーンアップ

- 56.5.1 受動化で生じる一時格納表のクリーンアップ方法

- 56.5.2 実行時に行われる処理: 受動化レコードを更新するタイミング

- 56.5.3 実行時に行われる処理: 受動化スナップショットを管理対象外のリリースで削除するタイミング

- 56.5.4 実行時に行われる処理: フェイルオーバー・モードで保持される受動化スナップショット

- 56.6 Fusion WebアプリケーションでのHttpSessionの管理

- 56.6.1 ユーザーの非アクティブ状態による暗黙のタイムアウトの構成方法

- 56.6.2 明示的なHttpSessionタイムアウトのコーディング方法

- 56.6.3 実行時に行われる処理: HTTPがタイムアウトしたときのアプリケーション・モジュールに対する処理

- 56.7 受動化時のカスタム・ユーザー固有情報の管理

- 56.7.1 カスタム・ユーザー固有情報の受動化方法

- 56.7.2 カスタム情報の受動化時の処理

- 56.7.3 カスタム情報の能動化に関する必知事項

- 56.8 受動化時のビュー・オブジェクトの状態の管理

- 56.8.1 ビュー・オブジェクトの状態の管理方法

- 56.8.2 ビュー・オブジェクトの受動化に関する必知事項

- 56.8.3 一時ビュー・オブジェクトおよび属性の状態の管理方法

- 56.8.4 一時ビュー・オブジェクトの受動化に関する必知事項

- 56.8.5 一時ビュー・オブジェクトを使用してセッションレベルのグローバル変数を格納する方法

57 アプリケーション・モジュール・プールのチューニング

- 57.1 アプリケーション・モジュール・プーリングについて

- 57.1.1 アプリケーション・モジュール・プール

- 57.1.2 デプロイメント環境のシナリオとプーリング

- 57.1.2.1 Oracle WebLogic Serverドメインが1つ、Oracle WebLogic Serverインスタンスが1つ、JVMが1つの場合

- 57.1.2.2 Oracle WebLogic Serverドメインが複数、Oracle WebLogic Serverインスタンスが複数、JVMが複数の場合

- 57.2 プール構成パラメータの設定

- 57.2.1 構成プロパティの宣言的設定方法

- 57.2.2 構成プロパティを宣言的に設定した場合の処理

- 57.2.3 構成プロパティをプログラム的に設定する方法

- 57.2.4 構成プロパティのスコープに関する必知事項

- 57.2.5 アプリケーション・モジュール・プールの構成パラメータに関する必知事項

- 57.2.5.1 プールの動作に関するパラメータ

- 57.2.5.2 プールのサイズ指定に関するパラメータ

- 57.2.5.3 プールのクリーンアップに関するパラメータ

- 57.2.6 アプリケーション・モジュール・プーリングの最適化に関する必知事項

- 57.3 データベースの状態の初期化とプーリングに関する考慮事項

- 57.3.1 ユーザー単位でのデータベース状態の設定方法

付録

A Oracle ADF XMLファイル

- A.1 ADFメタデータ・ファイルについて

- A.2 ADFファイルの概要図

- A.2.1 Oracle ADFデータ・コントロール・ファイル

- A.2.2 Oracle ADFデータ・バインディング・ファイル

- A.2.3 Web構成ファイル

- A.3 ADFファイルの構文図

- A.4 adfm.xml

- A.5 modelProjectName.jpx

- A.6 bc4j.xcfg

- A.7 DataBindings.cpx

- A.7.1 DataBindings.cpxの構文

- A.7.2 DataBindings.cpxの例

- A.8 pageNamePageDef.xml

- A.8.1 PageDef.xmlの構文

- A.9 adfc-config.xml

- A.10 task-flow-definition.xml

- A.11 adf-config.xml

- A.12 adf-settings.xml

- A.13 web.xml

- A.14 logging.xml

B ADFバインディング・プロパティ

C ADFセキュリティ権限の付与

D ADFビジネス・コンポーネントのよく使用されるメソッド

- D.1 フレームワーク・ベース・クラスの独自のレイヤーを作成するメソッド

- D.2 クライアント層で使用されるメソッド

- D.2.1 ApplicationModuleインタフェース

- D.2.2 Transactionインタフェース

- D.2.3 ViewObjectインタフェース

- D.2.4 RowSetインタフェース

- D.2.5 RowSetIteratorインタフェース

- D.2.6 Rowインタフェース

- D.2.7 StructureDefインタフェース

- D.2.8 AttributeDefインタフェース

- D.2.9 AttributeHintsインタフェース

- D.3 ビジネス・サービス層で使用されるメソッド

- D.3.1 コンポーネントでのカスタムJavaファイルの制御

- D.3.2 ApplicationModuleImplクラス

- D.3.2.1 ApplicationModuleImpl上でよくコールされるメソッド

- D.3.2.2 カスタムなApplicationModuleImplサブクラスでよく記述されるメソッド

- D.3.2.3 カスタムなApplicationModuleImplサブクラスでよくオーバーライドされるメソッド

- D.3.3 DBTransactionImpl2クラス

- D.3.3.1 DBTransaction上でよくコールされるメソッド

- D.3.3.2 カスタムなDBTransactionImpl2サブクラスでよくオーバーライドされるメソッド

- D.3.4 EntityImplクラス

- D.3.4.1 EntityImpl上でよくコールされるメソッド

- D.3.4.2 カスタムなEntityImplサブクラスでよく記述されるメソッド

- D.3.4.3 カスタムなEntityImplサブクラスでよくオーバーライドされるメソッド

- D.3.5 EntityDefImplクラス

- D.3.5.1 EntityDefImpl上でよくコールされるメソッド

- D.3.5.2 カスタムなEntityDefImplクラスでよく記述されるメソッド

- D.3.5.3 カスタムなEntityDefImplでよくオーバーライドされるメソッド

- D.3.6 ViewObjectImplクラス

- D.3.6.1 ViewObjectImpl上でよくコールされるメソッド

- D.3.6.2 カスタムなViewObjectImplサブクラスでよく記述されるメソッド

- D.3.6.3 カスタムなViewObjectImplサブクラスでよくオーバーライドされるメソッド

- D.3.7 ViewRowImplクラス

- D.3.7.1 ViewRowImpl上でよくコールされるメソッド

- D.3.7.2 カスタムなViewRowImplクラスでよく記述されるメソッド

- D.3.7.3 カスタムなViewRowImplサブクラスでよくオーバーライドされるメソッド

E ADFビジネス・コンポーネントJava EEデザイン・パターン・カタログ

F 一般的なOracle Formsのトリガーに相当するADFの機能

- F.1 検証とデフォルト設定(ビジネス・ロジック)

- F.2 問合せ処理

- F.3 データベース接続

- F.4 トランザクション後の処理(レコード・キャッシュ)

- F.5 エラー処理

G Oracle ADFでの一般的なOracle Formsのタスクの実行

- G.1 Oracle Forms開発者が理解しやすい概念

- G.2 データ関連タスクの実行

- G.2.1 外部キーに対する検索表示値の取得方法

- G.2.2 データベースからのシステム日付の取得方法

- G.2.3 読取り一貫性のない分離モードの実装方法

- G.2.4 計算済フィールドの実装方法

- G.2.5 ミラー・アイテムの実装方法

- G.2.6 タイプCLOBまたはBLOBのデータベース列の使用方法

- G.3 ユーザー・インタフェース関連タスクの実行

- G.3.1 ページのレイアウト方法

- G.3.2 キャンバスのスタック方法

- G.3.3 マスター/ディテール画面の実装方法

- G.3.4 問合せ入力画面の実装方法

- G.3.5 更新可能な複数レコード表の実装方法

- G.3.6 ポップアップ値リストの作成方法

- G.3.7 ドロップダウン・リストの値リストとしての実装方法

- G.3.8 別表からの値のあるドロップダウン・リストの実装方法

- G.3.9 即時ロックの実装方法

- G.3.10 レコードがロックされた場合のエラーのスロー方法

H GlassFishへのADFアプリケーションのデプロイ

- H.1 GlassFish ServerへのADFアプリケーションのデプロイについて

- H.1.1 統合WebLogic Serverを使用したアプリケーションの開発

- H.1.2 スタンドアロンGlassFish Serverにデプロイするためのアプリケーションの開発

- H.2 統合WebLogic ServerでのADFアプリケーションの実行

- H.2.1 統合WebLogic Serverでのアプリケーションの実行方法

- H.3 アプリケーションの準備

- H.3.1 ターゲット・アプリケーション・サーバーへの接続の作成方法

- H.3.2 デプロイメント・プロファイルの作成方法

- H.3.2.1 WARデプロイメント・プロファイルの作成

- H.3.2.2 アプリケーションレベルのEARデプロイメント・プロファイルの作成

- H.3.2.3 デプロイメント・プロファイル・プロパティの表示および変更

- H.3.3 デプロイメント・ディスクリプタの作成および編集方法

- H.3.3.1 デプロイメント・ディスクリプタの作成

- H.3.3.2 デプロイメント・ディスクリプタ・プロパティの表示または変更

- H.3.3.3 アプリケーション・サーバー互換のapplication.xmlファイルの構成

- H.3.3.4 GlassFish Server互換のweb.xmlファイルの構成

- H.3.4 GlassFish用JDBCデータソースの有効化方法

- H.3.5 初期コンテキスト・ファクトリの変更方法

- H.4 アプリケーションのデプロイ

- H.4.1 JDeveloperからアプリケーション・サーバーへのデプロイ方法

- H.4.2 JDeveloperからのデプロイに関する必知事項

- H.4.3 デプロイメント用のEARファイルの作成方法

- H.4.4 ADFライブラリに関する必知事項

- H.4.5 EARファイルとパッケージ化に関する必知事項

- H.4.6 アプリケーション・サーバーへのasadminコマンドを使用したデプロイ方法

- H.4.7 スクリプトとAntを使用したアプリケーションのデプロイ方法

- H.5 アプリケーションのテストとデプロイの検証

はじめに

『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』へようこそ。

対象読者

このドキュメントは、Oracle Application Development Framework (Oracle ADF)を使用してサービス指向アーキテクチャでデータベース中心のJava EEアプリケーションを作成およびデプロイする必要のあるエンタープライズ開発者を対象としています。このガイドでは、ADFビジネス・コンポーネント、ADFコントローラ、ADF FacesおよびJavaServer Facesを使用してFusion Webアプリケーションを作成する方法を説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracleサポートへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

詳細は、以下のドキュメントを参照してください。

- Oracle Application Development Frameworkの理解

- ADF FacesによるWebユーザー・インタフェースの開発

- Oracle ADFデスクトップ統合によるアプリケーションの開発

- Oracle ADFデータ・コントロールによるアプリケーションの開発

- Oracle JDeveloperによるアプリケーションの開発

- 『ADFスキンの開発』

- Oracle ADFアプリケーションの管理

- 『パフォーマンスのチューニング・ガイド』

- 『高可用性ガイド』

- 『Oracle JDeveloperのインストール』

- Oracle JDeveloperのオンライン・ヘルプ

- Oracle JDeveloperリリース・ノート(JDeveloperインストール内およびOracle Technology Networkから入手)

- Oracle ADFモデルJava APIリファレンス

- Oracle ADF ControllerのJava APIリファレンス

- Oracle ADFライフサイクルJava APIリファレンス

- Oracle ADF FacesのJava APIリファレンス

- Oracle ADF Faces JavaScript APIリファレンス

- Oracle ADFデータ視覚化コンポーネントのJava APIリファレンス

- Oracle ADF共有Java APIリファレンス

- Oracle ADFモデル・テスターのJava APIリファレンス

- Oracle汎用ドメインJava APIリファレンス

- Oracle Metadata Service (MDS)のJava APIリファレンス

- Oracle ADFリソース・バンドルJava APIリファレンス

- Oracle ADF Facesタグ・リファレンス

- Oracle ADF Facesスキン・セレクタ・タグ・リファレンス

- Oracle ADF Facesデータ視覚化ツール・タグ・リファレンス

- Oracle ADFデータ視覚化ツール・スキン・セレクタ・タグ・リファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、ユーザーが選択するオプションなどのgraphical user interface要素(メニューやメニュー項目、ボタン、タブ、ダイアログ・コントロールなど)を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、言語や構文の要素、ディレクトリおよびファイル名、URL、画面に表示されるテキスト、または入力するテキストを示します。

リリース12cにおけるこのマニュアルの新機能 (12.2.1.1.0)

次のトピックはOracle JDeveloperとOracle Application Development Framework (Oracle ADF)の新機能と変更された機能、およびこのガイドで説明されているその他の重要な変更点について概要を示しています。以前のJDeveloperリリースでは、このドキュメントは『Oracle Application Development Framework Fusion開発者ガイド』というタイトルでした。

リリース12c (12.2.1.1.0)の新機能と変更された機能

Oracle JDeveloperおよびOracle Application Development Framework (Oracle ADF)のOracle Fusion Middlewareリリース12c (12.2.1.1)には、次の新しい開発機能と変更された開発機能が含まれています。これらの機能について、このガイドで説明します。

- ADFビジネス・コンポーネント

- 新しいADFビジネス・コンポーネント・フレームワークのベース・クラス・セットは、プログラムによるビュー・オブジェクトとプログラムによるエンティティ・オブジェクトの共通メソッドを実装します。これらのフレームワーク・クラスは、ライフサイクルの知識を必要とせずに様々なライフサイクル・フェーズ中にビュー行と対話するフック・ポイントを提供します。詳細は、「カスタム・データ・ソースおよびFramework Base Class ProgrammaticViewObjectImplを使用したプログラム的操作」および「カスタム・データ・ソースおよびFramework Base Class ProgrammaticEntityImplを使用したプログラム的操作」を参照してください。

- JDeveloperで入力したGroovy式を、ビジネス・コンポーネントに関連する.bcsファイルに移入できるようになりました。.bcsファイルではコンパイル時にGroovy式のタイプ・チェックを実行できます。詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。

- 「データ・コントロール」パネルでビュー・オブジェクトに定義した行検索を公開できるようになりました。詳細は、「「データ・コントロール」パネルでの行検索の表示」を参照してください。

- 「Webサービス・データ・コントロールの作成」ウィザードを使用して、ADFビジネス・コンポーネントからADF RESTデータ・コントロールを作成できるようになりました。詳細は、「Webサービス・データ・コントロール・ウィザードを使用したADFデータ・コントロールの作成方法」を参照してください。

- bc4j.xcfg (アプリケーション・モジュール構成)ファイル用の新しい概要エディタを使用して、ADFビジネス・コンポーネント・モデル・プロジェクト内のアプリケーション・モジュールのプロパティをカスタマイズできるようになりました。詳細は、「構成プロパティの宣言的設定方法」を参照してください。

- ADFデータ視覚化コンポーネント

- 新しいチャート・コンポーネントであるADF DVT株価チャートが使用可能になりました。株価チャートは株式の出来高や株価を表示するときに使用します。クライアント側の株価チャートは、レガシーのサーバー側の株価チャートよりも推奨されます。詳細は、「データバインドされた株価チャートの作成方法」を参照してください。

- 新しいデータ視覚化コンポーネントであるADF DVT統計図表が使用可能になりました。統計図表は汎用性の高いデータ視覚化ツールで、情報を見栄えよく表現できます。統計図表は絶対数や母集団の中の部分集合を表現するのに使用され、様々な用途で使用できます。詳細は、「データバインドされた統計図表の作成」を参照してください。

- 新しいデータ視覚化コンポーネント、ADF DVTタグ・クラウドが使用可能になりました。タグ・クラウドはタグ・メタデータや文字列メトリックをクラウドまたは長方形のレイアウトの中に表示するデータ視覚化ツールです。タグを色でグループ化したり、相対的なサイズや重要度を割り当てタグのフォント・サイズに反映できます。詳細は、「データバインドされたタグ・クラウド・コンポーネントの作成」を参照してください。

リリース12c (12.2.1.1.0)に関するこのドキュメントにおけるその他の大きな変更

リリース12c (12.2.1.1.0)について、このドキュメントの一部が更新されています。次の表に、追加または変更された項を示します。

第II部 ビジネス・サービスの構築

- 項を改訂し、Groovy式が信頼できないとして評価されること、およびアクセスが汎用Java APIに限定されることについて詳しく記載しました。「信頼できないGroovy式に関する必知事項」および「ビュー基準を使用して現在のユーザーのビュー・オブジェクトをフィルタリングする方法」を参照してください。

- コンシューミング・アプリケーションでADF SDOを使用して公開された検索メソッドを起動する方法を説明する新しい項が追加されました。項「コンシューミング・アプリケーションでの検索メソッド・フィルタ・モデルの使用」を参照してください。

- 宣言SQLモードを使用してビュー・オブジェクトを作成し、それらをADF RESTリソースとして公開するためのベスト・プラクティスを説明する項が改訂されました。「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

- 演算子のリストが問合せ検索コンポーネントのモードに応じて制限される可能性がある場合に、問合せ検索コンポーネントのビュー基準演算子の検出に使用される「演算子の表示」ヒント設定の役割を説明する項が改訂されました。「ビュー基準にユーザー・インタフェース・ヒントを設定して検索フォームをサポートする方法」の項を参照してください。

第III部 モデル・レイヤーの使用方法

- ADF RESTフレームワークで主キー・ファインダを使用してリソース・コレクションをフィルタ処理する方法を説明する新しい項が追加されました。「主キー値によるリソース・コレクションのフィルタ処理」の項を参照してください。

- 新しい項を追加し、ADF RESTデータ型がADF RESTフレームワークによってADF RESTリソース・アイテムとそれらの基礎となるADFビジネス・コンポーネント・エンティティ・オブジェクト属性との間でマップされることについて記載しました。項「ADF RESTデータ型」を参照してください。

第V部 データバインドされたWebユーザー・インタフェースの作成

- 項を改訂し、コンテキスト・イベント使用時の自動リージョン・リフレッシュの無効化を制御するプロパティについて記載しました。項「コンテキスト・イベントの作成について」を参照してください。

- 項を改訂し、リモート・リージョンなどのリモート・コンシューマに対してイベントを公開する方法について記載しました。項「コンテキスト・イベントの公開方法」を参照してください。

- プログラム的なコンテキスト・イベント定義を作成し、イベント・プロデューサを登録して、コンテキスト・イベントをトリガーする方法を説明する新しい項が追加されました(これはデータ制御に依存したバインディングの実行に対する代替の方法です)。「マネージドBeanを使用したコンテキスト・イベントの動的作成および操作の方法」を参照してください。

- ビュー基準後方問合せ検索コンポーネントで指定される事前定義された演算子の役割を説明するように、項が改訂されました。「ビュー基準に検索フォーム・プロパティを設定する方法」の項を参照してください。

第VI部 アプリケーションの完成

- ユーザーがパブリック・ページにアクセスするときにログインを求められた場合に、ADFセキュリティ・コンテキストから現在のユーザー・データを取得する方法を説明するように項が改訂されました。項「ADF認証に関する必知事項」を参照してください。

- ユーザーのログインおよびログアウト時のADFセキュリティ・リダイレクト宛先ページをグローバルに定義するようにconnections.xmlファイルを構成する方法を説明する新しい項が追加されました。「リダイレクト宛先ページを確実に使用可能にする方法」の項を参照してください。

- 項を改訂し、読取り専用ビュー・オブジェクトをいつ受動化するかについてのパフォーマンスのヒントに詳しい説明を加えました。項「ビュー・オブジェクトの状態の管理方法」を参照してください。

第I部 Fusion Webアプリケーションのスタート・ガイド

この部では、ADFビジネス・コンポーネント、ADFモデル、ADF ControllerおよびADF Facesを使用するFusion Webアプリケーション(フルFusionテクノロジ・スタック)の構築に使用されるOracle Application Development Framework (Oracle ADF)のアーキテクチャと主要機能について説明します。

第I部は、次の章で構成されています。

- Oracle ADFを使用したFusion Webアプリケーションの構築の概要

- ADFサンプル・アプリケーションの概要

1 Oracle ADFを使用したFusion Webアプリケーションの構築の概要

この章では、ADFビジネス・コンポーネント、ADFモデル、ADF ControllerおよびADF Facesを使用するFusion Webアプリケーション(フルFusionテクノロジ・スタック)の構築に使用されるOracle Application Development Framework (Oracle ADF)のアーキテクチャと主要機能について説明します。また、高度な開発プラクティスについても説明します。

この章の内容は次のとおりです。

- Oracle ADFの概要

- Oracle ADFアーキテクチャ

- Oracle ADFによるアプリケーションの構築の概要

- チームでの効率的な作業

- Oracle JHeadstartを使用した、完全なWeb階層の生成

- Oracle ADFの学習に関する他のリソース

このマニュアルおよびこの他のマニュアルに、なじみのない用語が出てきた場合は、用語集で定義を確認してください。

1.1 Oracle ADFの概要

Oracle Application Development Framework (Oracle ADF)は、JavaプラットフォームEnterprise Edition (Java EE)標準とオープン・ソース・テクノロジを基盤とするエンドツーエンドのアプリケーション・フレームワークです。Oracle ADFを使用すると、Web、ワイヤレス、デスクトップまたはWebサービス・インタフェースを使用してデータを検索、表示、作成、変更および検証するエンタープライズ・ソリューションを実装できます。宣言的な機能を提供するOracle ADFにより、ユーザーはコードの詳細ではなくアプリケーション作成ロジックに焦点を当てることができ、開発を簡易化および迅速化できます。Oracle JDeveloperとOracle ADFを組み合せて使用すると、設計からデプロイに至る開発ライフサイクル全体に対応した環境が提供され、ドラッグ・アンド・ドロップによるデータ・バインディング、ビジュアルUI設計、チーム開発などの組込み機能を使用できます。

ヒント:

また、ADFアプリケーションはOracle Enterprise Pack for Eclipse (OEPE)を使用して開発することもできます。OEPEはJava EE環境をサポートするためにEclipse IDE向けに設計された一連のプラグインです。また、OEPEにはADFアプリケーション開発のサポート機能も含まれていますが、そのサポート機能はJDeveloperによって提供されている機能より限定されています。詳細は、http://www.oracle.com/technetwork/developer-tools/eclipse/overview/index.htmlを参照してください。

Fusion Webアプリケーション(フルFusionテクノロジ・スタックで構築されたアプリケーション)、ADFビジネス・コンポーネント、ADFモデル、ADF ControllerおよびADF Facesコンポーネントを備えたJavaServer Facesページを開発できます。このガイドの補足として、このガイド(および他のOracle Fusion Middleware開発者ガイド)の概念と手順を具体的に示すうえで役立つOracle ADF用のSummitサンプル・アプリケーションをダウンロードして表示できます。このサンプル・アプリケーションの例は、Fusion Webアプリケーション・テクノロジ・スタックを使用して作成されています。このアプリケーションのスクリーンショットおよびコード例は、このガイド全体で使用され、Oracle ADFテクノロジの実際の使用例を示しています。Summit ADFサンプル・アプリケーションのダウンロードおよび使用方法の詳細は、「ADFサンプル・アプリケーションの概要」を参照してください。

1.2 Oracle ADFアーキテクチャ

Fusion Webテクノロジ・スタックを使用してアプリケーションを構築すると、業界のベスト・プラクティスに従うように、モデル・ビュー・コントローラ・アーキテクチャに準拠したビジネス・ロジック、ページ・ナビゲーション、ユーザー・インタフェースの明確な分離が実現します。図1-1に示すように、MVCアーキテクチャでは次のような構成になります。

- モデル・レイヤーは、現在のページに関連するデータ値とともに、データ値に対して使用されるモデルレベル・ビジネス・ルール、セキュリティおよびアプリケーション・ロジックを表します。

- ビュー・レイヤーには、データの表示および変更に使用するUIページがあります。

- コントローラ・レイヤーは、ユーザー入力を処理し、ページ・ナビゲーションを決定します。

- ビジネス・サービス・レイヤーは、データ・アクセスを処理し、ビジネス・ロジックをカプセル化します。

図1-1 MVCアーキテクチャによる、UI、ビジネス・ロジック、ページ・ナビゲーションの明確な分離

図1-2は、Fusion Webアプリケーション・アーキテクチャを構成する各ADFモジュールの場所を示しています。このフレームワークの中核モジュールは、データバインディング機能であるADFモデルです。ADFモデルにより、統一化されたアプローチを使用して、各ユーザー・インタフェースをコード記述なしで任意のビジネス・サービスにバインドできます。Fusion Webアプリケーション・テクノロジ・スタックを構成するその他のモジュールは、次のとおりです。

- ADFビジネス・コンポーネント: ビジネス・サービスの構築作業を簡略化します。

- ADF Faces: JavaServer Faces (JSF)で構築されるWebアプリケーションに豊富なAjax対応のUIコンポーネント・ライブラリを提供します。

- ADF Controller: JSFをADFモデルに統合します。ADF Controllerは、複数のJSFページ間のみだけでなく、メソッド・コールやその他のタスク・フローなど、他のアクティビティ間に制御を渡す再利用可能なタスク・フローなどの追加機能を提供することにより、標準JSFコントローラを拡張します。ADF Controllerもデータ・モデルと連携し、各リクエストまたはリージョンで適切なデータが使用されるようにします。

注意:

ADF Facesに加えて、Oracle ADFはJavaおよび標準のJSFビュー・テクノロジの使用もサポートしています。これらのテクノロジの詳細は、『Oracle JDeveloperによるアプリケーションの開発』を参照してください。Oracle ADFでは、アプリケーションのビュー・レイヤーとしてのMicrosoft Excelの使用もサポートされます。詳細は、『Oracle ADFデスクトップ統合によるアプリケーションの開発』を参照してください。

図1-2 シンプルなOracle ADFアーキテクチャ

Oracle ADFアーキテクチャおよび個々のADFテクノロジの詳細は、『Oracle Application Development Frameworkの理解』を参照してください。

1.3 Oracle ADFによるアプリケーションの構築の概要

Oracle ADFでは、開発プロセスを通して宣言的なプログラミング・パラダイムを使用することが重視されます。これによって、ユーザーは、アプリケーション作成のロジックに集中でき、実装の詳細を知る必要がなくなります。Oracle ADFとともにJDeveloperを使用すると、データ・アクセス、検証、ページ・コントロールおよびナビゲーション、ユーザー・インタフェース設計、データ・バインディングでアプリケーションの宣言的メタデータを自動的に管理する生産性の高い環境が実現します。

高レベルのFusion Webアプリケーションの開発プロセスには通常、次の過程が含まれます。

- アプリケーション・ワークスペースの作成: ウィザードを使用して、選択したテクノロジに必要なライブラリと構成の追加およびパッケージとディレクトリを含むプロジェクトへのアプリケーションの構成が、JDeveloperによって自動的に行われます。

- データベース・オブジェクトのモデル化: オンライン・データベースまたはデータベースのオフライン・レプリカを作成し、JDeveloperのエディタとダイアグラマを使用して定義の編集やスキーマの更新を行うことができます。

- ユースケースの作成: UMLモデラーを使用して、アプリケーションのユースケースを作成できます。

- アプリケーション・コントロールおよびナビゲーションの設計: ダイアグラマを使用して、アプリケーション・コントロールおよびナビゲーションのフローを視覚的に決定します。JDeveloperによって、ベースとなるXMLが作成されます。

- 共有リソースの識別: アプリケーションにドラッグ・アンド・ドロップするだけで、インポートされたライブラリを表示したり、使用できるリソース・ライブラリを使用します。

- データにアクセスするためのビジネス・コンポーネントの作成: データベース表から、ウィザードまたはダイアログを使用してエンティティ・オブジェクトを作成します。これらのエンティティ・オブジェクトから、アプリケーション内のページが使用するビュー・オブジェクトを作成します。エディタを使用して、検証規則およびその他のタイプのビジネス・ロジックを実装できます。

- JSFによるユーザー・インタフェースの実装: JDeveloperの「データ・コントロール」パネルには、アプリケーションのビュー・オブジェクトが表示されます。ユーザー・インタフェースの作成は簡単で、オブジェクトをページにドラッグし、ベースとなるデータを表示するUIコンポーネントを選択するだけです。データバインドされていないUIコンポーネントの場合、「コンポーネント」ウィンドウを使用してコンポーネントをドラッグ・アンド・ドロップします。JDeveloperによってページ・コードが作成されます。

- ADFモデルを使用したUIコンポーネントとデータのバインディング: 「データ・コントロール」パネルからオブジェクトをドラッグすると、JDeveloperによってページとデータ・モデルとの間にバインディングが自動的に作成されます。

- 検証およびエラー処理の組込み: アプリケーションを作成したら、エディタを使用して、検証を追加し、エラー処理を定義します。

- アプリケーションの保護: エディタを使用してロールを作成し、ユーザーに実装します。フラット・ファイル・エディタを使用して、これらのロールにセキュリティ・ポリシーを定義し、アプリケーション内の特定のリソースに割り当てます。

- テストとデバッグ: JDeveloperには、統合されたアプリケーション・サーバーが含まれていて、パッケージ化してデプロイすることなく、アプリケーションを完全にテストできます。JDeveloperには、ブレークポイントを設定してデータを調べることができるツールのADF宣言デバッガも含まれています。

- アプリケーションのデプロイ: ウィザードとエディタを使用して、デプロイメント・ディスクリプタ、JARファイルおよびアプリケーション・サーバー接続を作成します。

1.3.1 アプリケーション・ワークスペースの作成

新規アプリケーションを作成する最初の手順は、アプリケーションに名前を割り当て、そのソース・ファイルを保存するディレクトリを指定することです。JDeveloperから提供されるアプリケーション・テンプレートを使用してアプリケーションを作成すると、作成するアプリケーションのタイプで必要とされる多くの構成ファイルが作成され、ワークスペースとともにプロジェクトに構成されます。

これらのテンプレートの1つがADF Fusion Webアプリケーション・テンプレートで、ビューに対してADF Faces、ページ・フローに対してADFコントローラ、ビジネス・サービスに対してADFビジネス・コンポーネントを使用するWebアプリケーションを作成するために必要な正確に構成されたプロジェクトのセットを提供します。このテンプレートを使用してアプリケーション・ワークスペースを作成する場合、アプリケーションに必要なJSFおよびADF構成ファイルがJDeveloperにより自動的に作成されます。

「アプリケーション概要」の構成要素の1つに、「Fusion Webアプリケーションのクイック・スタート・チェックリスト」があります。このチェックリストは、Fusion Webアプリケーション作成の基本手順を提供します。図1-3に示すように、関連ドキュメント、前提条件、チェックリスト内の各手順のステータスを追跡する機能へのリンクが含まれています。

図1-3「Fusion Webアプリケーションのクイック・スタート・チェックリスト」

JDeveloperでは、アプリケーション内のビジネス・サービスに関連するすべてのソース・ファイルを含みModelという名前のプロジェクトと、ADF Facesビュー・レイヤーおよびモデル・レイヤー用のすべてのソース・ファイル(コントローラ用のファイルを含む)を含みViewControllerという名前のプロジェクトも作成されます。

関連付けられたライブラリを自分で追加する手間を省くため、一度ビジネス・コンポーネントを作成すると、JDeveloperでは、自動的に次のライブラリをデータ・モデル・プロジェクトに追加します。

- ADFモデル・ランタイム

- BC4J Oracleドメイン

- BC4Jランタイム

- BC4Jセキュリティ

- MDSランタイム

- MDSランタイム依存性

- Oracle JDBC

JDeveloperでは、ビュー・オブジェクトに次のライブラリも追加されます。

- JSPランタイム

- JSF 2.1

- JSTL 1.2

- ADF Page Flowランタイム

- ADF Controllerランタイム

- ADF Controllerスキーマ

- ADF Facesランタイム11

- ADF共通ランタイム

- ADF Webランタイム

- MDSランタイム

- MDSランタイム依存性

- Commons Beanutils 1.6

- Commons Logging 1.0.4

- Commons Collections 3.1

- ADF DVT Facesランタイム

- ADF DVT Facesデータバインディング・ランタイム

- ADF DVT FacesデータバインディングMDSランタイム

JSFページを追加すると、JDeveloperによってOracle JEWTライブラリが追加されます。

その場合、JDeveloperを使用して追加のプロジェクトを作成し、アプリケーションに必要なパッケージとファイルを追加できます。

注意:

アプリケーションのアーティファクト(タスク・フローなど)を再利用する場合、「アプリケーション・コンポーネントの再利用」のネーミング・ガイドラインに従って、名前の競合を回避する必要があります。

ヒント:

アプリケーション・テンプレートで使用するデフォルト値を編集したり、独自のテンプレートを作成できます。その場合は、「アプリケーション」→「テンプレートの管理」を選択します。

図1-4は、「アプリケーション」ウィンドウに表示されるSummit ADFサンプル・アプリケーションの様々なプロジェクト、パッケージ、ディレクトリおよびファイルを示しています。

図1-4 Summit ADFサンプル・アプリケーションのプロジェクト、パッケージおよびディレクトリ

詳細は、『Oracle JDeveloperによるアプリケーションの開発』のアプリケーションおよびプロジェクトの管理に関する項を参照してください。

図1-5に示すように、ファイルの操作時には主に「アプリケーション」ウィンドウ、エディタ・ウィンドウ、「構造」ウィンドウおよび「プロパティ」ウィンドウを使用します。エディタ・ウィンドウでは、WYSIWYG環境に多くのファイルを表示でき、概要エディタにファイルを表示して宣言的に変更したり、ファイルのソース・コードを表示できます。「構造」ウィンドウには、現在選択されているファイルの構造が示されます。このウィンドウでオブジェクトを選択した後、選択したオブジェクトのプロパティを「プロパティ」ウィンドウで編集できます。

図1-5 JDeveloperのワークスペース

1.3.2 データベース・オブジェクト定義によるモデリング

JDeveloperでは、オンラインのデータベースで作業することも、アプリケーション・ワークスペースの作成後にデータベース・スキーマからオフライン・データベースまたはプロジェクトにデータベース・オブジェクトをコピーし、.xmlファイルとして保存されたオフライン・データベース・オブジェクトとして利用することもできます。オンラインまたはオフラインのどちらのデータベースでも、プロジェクト内でデータベース・オブジェクト定義を作成および編集できます。また、オフライン・データベース・オブジェクトを他のオフラインまたは稼働中のデータベース・スキーマと比較したり、SQL文(CREATE、REPLACEおよびALTERを含む)を生成したりできます。

たとえば、アプリケーションによって定義されているデータベース接続からデータベース・ダイアグラムに表をドラッグすると、JDeveloperでは、稼働中またはオフラインのデータベースをモデリングする(オブジェクトの.xmlファイル表現を作成する)ことができます。表および外部キーなどのデータベース定義のモデリングによって、スキーマの基本的な情報を視覚的に取得できます。ダイアグラムでは、列とキーをドラッグ・アンド・ドロップして、外部キー関係を複製、移動および作成できます。オフライン・モードでダイアグラム上でノードをモデル化する場合は、JDeveloperによって基礎となるオフライン・オブジェクトが作成され、「アプリケーション」ウィンドウに表示されます。稼働中のスキーマを操作する場合は、ダイアグラムを修正すると、JDeveloperによってデータベース・オブジェクトが更新されます。同一のオフライン・データベース・オブジェクトから複数のダイアグラムを作成し、複数のプロジェクトにオフライン・データベースを展開できます。

図1-6に示すようなデータベース・ダイアグラムを使用すると、次の要素を視覚化できます。

- 表とその列

- 表間の外部キー関係

- ビュー

- オフラインの順序とシノニム

データベース・オブジェクトを直接作成および編集する場合は、ダイアグラムだけでなく、特定のデータベース・オブジェクト・エディタでも作業できます。オフライン・データベース・オブジェクトでの作業が終了したら、更新された新しいデータベース定義をオンライン・データベース・スキーマに生成できます。

データベース・ダイアグラムで作業する場合は、ダイアグラムをカスタマイズして、レイアウトの変更や、オブジェクトの表示方法とグループ化方法の変更を行ったり、依存性やリンク(URLなど)を指定する注釈をダイアグラムに追加したり、ダイアグラムの色およびフォント要素などの視覚的なプロパティを変更したりできます。

図1-6 Payments Groupingのデータベース・ダイアグラム

データベース・ダイアグラムを使用したデータベース定義のモデル化の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のデータベース・オブジェクトの作成、編集およびドロップに関する項を参照してください。

1.3.3 ユースケースの作成

アプリケーション・ワークスペースを作成した後、ユースケースをモデル化して構築対象のアプリケーションに関するエンド・ユーザー要件を取得して伝達すると、開発プロセスを開始できます。図1-7は、JDeveloperのUMLモデラーを使用して設計されることのある新規従業員を作成しているHR管理者向けの簡単なダイアグラムを示しています。ダイアグラムの注釈を使用すると、ユースケースを実装する画面上でエンド・ユーザーが参照する必要がある内容に関する特定の要件を取り込むことができます。たとえば、このユースケースでは、ユーザーがすべての従業員のリストを表示しながら新規従業員を作成することを選択しています。

図1-7 オーダー履歴を表示するユースケース・ダイアグラム

ユースケース・ダイアグラムの作成方法の詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「モデル化を使用したアプリケーションの開発」を参照してください。

1.3.4 ADFタスク・フローを使用したアプリケーション・コントロールおよびナビゲーションの設計

ユースケースのモデル化により、エンド・ユーザー要件を実装するために必要なユーザー・インタフェース・ページの種類を把握していきます。この時点で、次の3つのダイアグラムをアプリケーション・フローの設計を開始するために役立つドキュメント・ツールとして使用できます。Fusion Webアプリケーションでは、標準JSFナビゲーション・フローではなくADFタスク・フローを使用します。タスク・フローでは、ナビゲーションおよびアプリケーション・コントロールに対してよりモジュール化されたトランザクション対応のアプローチを使用します。標準JSFナビゲーション・フローと同様、タスク・フローには主に表示可能なページ(またはページ・フラグメント)が含まれます。ナビゲーションとは別に、タスク・フローには、組み合せることでページ・フローとアプリケーション動作に影響を与えることができる否ビジュアル的なアクティビティも含まれます。たとえば、これらの否ビジュアル的なアクティビティでは、マネージドBeansへのメソッド呼出し、EL式の評価、または別のタスク・フローの呼出しが可能です。これにより、ビジネス・ロジックは表示されているページとは関係なく呼び出すことができるため、再利用しやすくなります。

図1-8は従業員を作成するためのタスク・フローを示しています。このタスク・フローでは、GeneralInfoおよびConfirmationはページを表示するビュー・アクティビティであり、CreateInsertはメソッド・コール・アクティビティです。ユーザーがこのフローを開始すると、CreateInsertアクティビティ(緑色の円で示したフローのエントリ・ポイント)が呼び出され、対応するメソッドがコールされます。これはメソッドへのコールであり、メソッド自体はタスク・フローに含まれていないため、アプリケーションの別の場所でメソッドを再利用できます。また、メソッド内のロジックはページ・フローのメタデータに影響を及ぼさずに変更できます。そこから、フローはGeneralInfoページに続き、データが送信されると、Confirmationページへと続きます。

図1-8 従業員を作成するためのタスク・フロー

ADF Controllerでは、コントロール・フロー・ルールを使用してナビゲーションを定義するメカニズムを提供しています。コントロール・フロー・ルールの情報は、フローに関する他の情報とともに構成ファイルに保存されます。図1-9はタスク・フローの「構造」ウィンドウを示しています。このウィンドウは、コントロール・フロー・ルールなど、フローに構成された各項目を示しています。「プロパティ」ウィンドウ(デフォルトでは右下の位置)を使用すると、フローの様々な要素の値を設定できます。

図1-9 「構造」ウィンドウおよび「プロパティ」ウィンドウのタスク・フロー要素

ページとは別に、タスク・フローではページ・フラグメントを調整することもできます。ページ・フラグメントとは、別のJSFページのコンテンツとしてレンダリングされるJSFドキュメントです。ページ・フラグメントおよびページ・フラグメント間の制御は、ページを作成する場合と同様にバインド・タスク・フローに作成し、タスク・フロー全体をリージョンとして別のページに挿入できます。リージョンは別のタスク・フローになるため、これによりメソッドの実行、式の評価およびコンテンツの表示を個別に実行できますが、格納するページの残りのコンテンツは同じ状態のままです。

また、リージョンによって再利用が可能になります。タスク・フローをリージョンとして作成し、タスクに必要な情報とタスクから返される情報を決定し、それらをリージョンのパラメータとして定義して値を戻すと、リージョンをアプリケーションの任意のページにドロップできます。パラメータの値によっては、異なるビューが表示される場合があります。

「ADFタスク・フローの作成」では、タスク・フローの使用方法を詳しく説明しています。タスク・フローおよびその作成の詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。タスク・フロー・アクティビティの詳細は、「タスク・フロー・アクティビティの使用」を参照してください。パラメータをタスク・フローに、またはタスク・フローから渡す必要がある場合は、「タスク・フローのパラメータの使用」を参照してください。リージョンの詳細は、「リージョンとしてのタスク・フローの使用」を参照してください。トランザクション機能やページの必須の順序(トレイン)の作成など、タスク・フローで提供できる高度な機能の詳細は、「複雑なタスク・フローの作成」を参照してください。タスク・フローを使用したダイアログの作成の詳細は、「アプリケーションでのダイアログの使用」を参照してください。

1.3.5 共有リソースの識別

アプリケーションの設計時に、アプリケーションの一部をアプリケーション全体で再利用できる場合があります。たとえば、ビジネス・コンポーネントを作成する開発者が1名、Webインタフェースを作成する開発者が1名いる場合があります。ビジネス・コンポーネント開発者はプロジェクトをライブラリとして保存してパッケージ化できます。このライブラリは他の開発者に送信可能で、受信した開発者はリソース・カタログにこれを追加でき、そこから必要なページにドラッグ・アンド・ドロップできます。図1-10はJDeveloperの「リソース」ウィンドウのリソース・カタログを示しています。

図1-10 JDeveloperの「リソース」ウィンドウ

再利用の候補となるすべてのタスクに注意が必要です。ADFライブラリとしてパッケージ化および再利用できるADFアーティファクト、およびライブラリの作成と使用手順の詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

1.3.6 ADFビジネス・コンポーネントを使用してデータにアクセスするデータ・モデルの作成

通常、ビジネス・ロジックをADFビジネス・コンポーネントとして実装する場合は、次の手順を実行します。

- アプリケーションが実行するトランザクションの対象となる表を示すエンティティ・オブジェクトを作成します。エンティティ・オブジェクトは実際に既存のデータベース・スキーマから作成できます。必要に応じて、検証規則およびビジネス・ルールを追加します。

- データベースの問合せを実行するエンティティ・オブジェクトと連動するビュー・オブジェクトを作成します。これらのビュー・オブジェクトを使用して、ビュー・レイヤーに表示できるデータを作成します。また、読取り専用ビュー・オブジェクトを作成でき、静的リストを表示するために使用できます。エンティティ・オブジェクトと同様に、ビュー・オブジェクトは既存のデータベース・スキーマから作成できます。

- UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントであるアプリケーション・モジュールを作成します。アプリケーション・モジュールはビジネス・サービスへのインタフェースになり、これらのサービス(アプリケーションのUIレイヤーなど)の使用者によって使用されます。このアプリケーション・モジュールには、アプリケーションのWebページを介してユーザーが対話するデータ・モデルのビュー・オブジェクト・インスタンスとカスタム・メソッドが含まれます。

- 必要に応じて、リモート呼び出し用のWebサービスとしてサービスを公開します。

「ビジネス・サービスの構築」では、これらのアーティファクトの作成方法を詳しく説明しています。「アプリケーションの完成」の各章にはビジネス・オブジェクトの拡張、チューニング、状態管理などの追加情報が記載されています。

1.3.6.1 表のビジネス・ドメイン・オブジェクトのレイヤーの作成

アプリケーションで表示され操作されるデータについて理解すると、まだデータベースを構築していない場合はデータベースを構築できます(詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Oracle JDeveloper内でのデータベースの設計」を参照)。データベース表が準備されている場合、これらの表を示す一連のエンティティ・オブジェクトを作成し、表に含まれるデータの変更を簡略化できます。エンティティ・オブジェクトを使用して表に関するデータ・アクセスおよび検証をカプセル化することにより、今日または将来作成するこれらの表と連携するページを一貫性のある方法で検証できます。表の間の関係は、対応するエンティティ・オブジェクト間のアソシエーションとして反映されます。

エンティティ・オブジェクトが作成されると、エンティティのUIでの表示を簡略化するコントロールと属性のヒントを定義できるだけでなく、オブジェクトに動作を追加することもできます。詳細は、「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」を参照してください。

1.3.6.2 ビジネス・サービスの構築

ビジネス・オブジェクトの再利用可能なレイヤーが作成されると、UIクライアントが動作できるサービス・メソッドとアプリケーション・モジュールのデータ・モデルを実装できます。

アプリケーション・モジュールのデータ・モデルは、必要な問合せのカプセル化のために作成したビュー・オブジェクト・コンポーネントのインスタンスで構成されています。ビュー・オブジェクトでは、ユーザー・インタフェースで表されるエンド・ユーザーのタスクが必要とする形に、データを結合、計画、フィルタ、ソートおよび集約できます。エンド・ユーザーがデータを更新する必要がある場合、ビュー・オブジェクトでは、再使用可能なビジネス・ドメイン・レイヤー内のエンティティ・オブジェクトを参照します。ビュー・オブジェクトは、再利用可能であり、複数のアプリケーション・モジュールで使用できます。詳細は、「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。

図1-11はアプリケーションによって必要とされる多数の問合せを含むoracle.summit.model.viewパッケージを示しています。

図1-11 Summit ADFサンプル・アプリケーション内のビュー・オブジェクト

さらに、外部アプリケーションに機能を公開する必要がある場合があります。このとき、サービス・インタフェースを通じてこの機能を公開できます。たとえば、ServiceAppModuleアプリケーション・モジュールは、Webサービスとして公開されます。このWebサービスは、図1-12に示すように、CustomersViewおよびOrdersViewビュー・インスタンスを公開します。詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。

図1-12 WebサービスとしてのServiceAppModuleアプリケーション・モジュール

1.3.6.3 Oracle ADFモデル・テスターによるビジネス・サービスのテストとデバッグ

アプリケーションを開発する場合、Oracle ADFモデル・テスターを使用してビジネス・サービスを繰り返しテストできます。テスターにより、サービスをテストするユーザー・インタフェースまたはその他のクライアントを使用したり作成せずに、ビジネス・サービスの問合せ、ビジネス・ロジックおよび検証をテストできます。テスターを使用すると、追加した最新の問合せまたはビジネス・ルールをテストし、問題の診断に要する時間を節約できます。アプリケーション・モジュールの開発およびテストの詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

またテスターはADF宣言デバッガと対話し、ビジネス・サービスのデバッグができます。作成する任意のカスタム・メソッドにブレークポイントを設定できます。詳細は、「テストとデバッグのためのOracle ADFモデル・テスターの使用」を参照してください。

1.3.7 JSFによるユーザー・インタフェースの実装

計画段階で作成したページ・フローからページ・アイコンをダブルクリックすると、実際のJSFファイルを作成できます。ADF FacesアプリケーションのJSFページを作成する場合は、.jsf拡張子を使用するFacelets XHTMLファイルを作成します。Faceletsは、JSPエンジンの代替として使用できるJSF中心のXMLビュー定義テクノロジです。

ヒント:

Faceletページでは任意の整形式のXMLファイルを使用できますが、JDeveloperでFaceletページを作成する場合は、XHTMLファイルとして作成されます。

ADF Facesには、ページのレイアウト全体の定義に使用できる多数のコンポーネントが用意されています。JDeveloperには、これらのコンポーネントを使用した事前定義済のクイック・スタート・レイアウトが含まれており、効率的に正しくページのレイアウトを決定できます。1列、2列または3列のレイアウトから選択でき、列の動作を指定できます。また、レイアウトに適用するテーマを選択すると、コンポーネントの一部に色が追加されます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のクイック・スタート・レイアウトの使用に関する項を参照してください。

またOracle ADFでは、独自のページ・テンプレートを作成して使用できます。テンプレートを作成する場合は、ページのレイアウトを決定し(クィック・レイアウト・テンプレートのいずれかを使用するか手動でレイアウトを作成する)、すべてのページで表示する必要のある静的コンテンツを提供して、各ページで有効な値に置き換えることができるプレースホルダー属性を作成します。レイアウトの変更など、テンプレートが変更されるたびに、テンプレートを使用するページにも更新が反映されます。

「データバインドされたWebユーザー・インタフェースの作成」では、基本的なフォームから複雑な検索機能まで、異なるタイプのUI機能の作成方法を詳しく説明しています。

1.3.8 ADFモデルのデータバインディング

通常のJSFアプリケーションでは、UIコンポーネント属性を管理対象Beanのプロパティまたはメソッドにバインドします。JSFランタイムでは、EL式でBeanを最初に参照した際に、Beanのオンデマンドのインスタンス化が管理されます。ただし、ADFモデルを使用しているアプリケーション内では、JDeveloperは汎用データ・バインド機能を駆動するXML構成ファイルを使用しているADFモデルにUIコンポーネント属性を自動的にバインドします。これには、ユーザー・インタフェース・テクノロジとビジネス・サービス実装の分離を可能にする概念(データ・コントロールと宣言的バインディング)が実装されています。

データ・コントロールでは、サービスの記述にXML構成ファイルを使用します。設計時に、JDeveloperのようなビジュアル・ツールでメタデータを操作し、任意のデータ・コントロール操作やデータ・コレクションにUIコンポーネントを宣言的にバインドして、バインディングを作成できます。たとえば、図1-13は、JDeveloperの「データ・コントロール」パネルに表示されるBackOfficeAppModuleDataControlデータ・コントロールを示しています。

図1-13 BackOfficeAppModuleDataControl

パネルに表示されるコレクションは、BackOfficeAppModuleDataControlアプリケーション・モジュールに含まれる各ビュー・オブジェクト・インスタンスでの問合せによって返される行セットを表します。たとえば、「データ・コントロール」パネルのCountriesデータ・コレクションは、BackOfficeAppModuleDataControl'sデータ・モデルのCountriesビュー・オブジェクト・インスタンスを表します。それぞれのデータ・コレクションの各行で使用可能な属性は、子ノードとして表示されています。データ・コレクション・レベルの「操作」ノードには、ADFモデルでサポートされるデータ・コレクションに対する組込み操作(previous、next、first、lastなど)が含まれます。

注意:

Webサービス、URLから取得されたXMLデータ、JavaBeans、EJBを操作するために別の種類のデータ・コントロールを作成する場合、これらは「データ・コントロール」パネルにも適切に表示されます。プロジェクトでこれらのデータ・コントロールのいずれかを作成する場合、JDeveloperでは構成情報を含むメタデータ・ファイルが作成されます。Oracle ADFアプリケーション・モジュールを操作する場合、アプリケーション・モジュールがすでにメタデータ駆動型のコンポーネントであり、ADFモデル・データ・コントロールとして自動的に公開するために必要なすべての情報を含んでいるため、これらの追加ファイルを明示的に作成する必要はありません。

「データ・コントロール」パネルを使用して、データ・コレクションをビジュアル・エディタのページ上にドラッグ・アンド・ドロップすると、必要なバインディングが作成されます。図1-14は、「データ・コントロール」パネルからドラッグされ、JSFページにフォームとしてドロップされるCountriesコレクションを示しています。

図1-14 「データ・コントロール」パネルを使用したフォームの宣言的作成

「データ・コントロール」パネルからデータバインドされたコンポーネントが最初にページにドロップされたときに、JDeveloperによりそのコンポーネントの関連ページ定義ファイルが作成されます。このXMLファイルは、ページ上でUIコンポーネントをサポートするバインディングのグループについて記述しています。ADFモデルでは実行時にこのファイルが使用され、ページのバインディングがインスタンス化されます。これらのバインディングは、バインディング・コンテナと呼ばれるリクエスト・スコープ・マップに保持されます。「データ・コントロール」パネルを使用してコンポーネントをページに追加するたびに、適切なバインディング・エントリがこのページ定義ファイルに追加されます。さらに、ドラッグ・アンド・ドロップによるデータ・バインディング操作を実行すると、JDeveloperにより、JSFページのJSF UIコンポーネントを示す必要なタグが作成されます。「データ・コントロール」パネルの使用の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

データを表示または更新するフォームおよび表の他に、検索フォーム、およびデータがバインドされた図とグラフを作成することもできます。データ・コントロールを使用して様々なタイプのページを作成する方法の詳細は、「データバインドされたWebユーザー・インタフェースの作成」の各章を参照してください。「データ・コントロール」パネル、およびUIデータがバインドされたコンポーネントを作成するためのその使用方法の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。ADFモデルの詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』を参照してください。

1.3.9 検証およびエラー処理

エンティティ・オブジェクトおよびビュー・オブジェクトでは、概要エディタを使用してビジネス・オブジェクトに検証を宣言的に追加できます。エンティティの場合、ビジネス・ルールは常に属性に定義されたデータ・タイプの制約を反映します。

図1-15は、EmpEOエンティティ・オブジェクトの概要エディタの「ビジネス・ルール」ページを示しています。

図1-15 概要エディタでの検証の設定

このタブでは、検証規則に加えて、検証が失敗した場合のエラー・メッセージの表示設定も行います。このような宣言的な検証を補足する場合は、Groovyスクリプト式も使用できます。サービス・レベルでの検証の作成の詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

また、ADF Faces入力コンポーネントには、組込みの検証機能があります。required属性を設定するか、事前作成済のADF Facesバリデータを使用して、コンポーネントに1つ以上のバリデータを設定します。ビジネス・ニーズに合せて、独自のカスタム・バリデータを作成することもできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「入力の検証および変換」を参照してください。

カスタムのエラー・ハンドラを作成して、アプリケーションの実行中に発生したエラーをレポートできます。エラー・ハンドラを作成すると、アプリケーションの構成ファイルの1つにハンドラを登録するだけです。

1.3.10 セキュリティの追加

Oracle ADFは、Java Authentication and Authorization Service (JAAS)に基づくセキュリティ実装を提供します。アプリケーションでのユーザーの認証と認可の実施を可能にします。Oracle ADFのJAASの実装は、パーミッションベースです。これらのパーミッションを定義したあと、アプリケーションのユーザーに関連付けるアプリケーション・ロールに付与します。アプリケーションのセキュリティ保護の詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

1.3.11 Webクライアント・アプリケーションのテストとデバッグ

Oracle ADF Webアプリケーションのテストは、他の任意のJava EEアプリケーションのテストとデバッグに似ています。大半のエラーの原因は、ページのADFバインディング・コンテナのランタイム・オブジェクトにアクセスするEL式内またはアプリケーションで定義される宣言情報内において単純で容易に修正できる問題です。多くのケースでは、宣言ファイルおよびEL式を検証すると大半の問題を解決できます。

宣言的ファイルまたはEL式が原因ではないエラーの場合、ADFロガーを使用してADFモデルAPIからランタイム・トレース・メッセージを取得できます。このトレースには、アプリケーション・エラーの原因をすぐに特定できるランタイム・メッセージが含まれます。ログ出力から特定のエラーを検索することもできます。

JDeveloperには、バインディング・レイヤーやタスクフローなど、Oracle ADFの宣言的部分でブレークポイントを設定してデータを調べることができるツールのADF宣言デバッガも含まれています。ブレークポイントに達すると、アプリケーションの実行が一時停止され、ADFバインディング・コンテナの作業対象データを調べて、予測されるデータと比較することができます。「ADFコンポーネントのテストとデバッグ」には、Fusion Webアプリケーションを正常にデバッグする方法についての有用な情報およびヒントが記載されています。

JDeveloperでは、テストのためのJUnitとの統合が提供されます。ウィザードを使用して、回帰テスト・ケースを生成します。詳細は、「JUnitを使用した回帰テスト」を参照してください。

1.3.12 アプリケーション・アーティファクトのリファクタ

JDeveloperを使用すると、アプリケーション内の異なるコンポーネントの名前を変更したり移動できます。JDeveloperを使用してデータ・モデル・プロジェクトのビジネス・コンポーネントをリファクタすると、コンポーネントの名前を変更したり、それらを別のパッケージに移動でき、さらにJDeveloperはリファクタされたコンポーネントへのすべての参照を検出し、更新します。可能な場合は常に、JDeveloperのリファクタ・アクションを使用してエラーを招き易いプロジェクトの手動での編集を回避できます。詳細は、「Fusion Webアプリケーションのリファクタ」を参照してください。

1.3.13 Fusion Webアプリケーションのデプロイ

Fusion Webアプリケーションは、JDeveloper内の統合WebLogic Serverまたはサポートされるスタンドアロン・インスタンスのいずれかにデプロイできます。デプロイメントの詳細は、「Fusion Webアプリケーションのデプロイ」を参照してください。

1.3.14 Fusion Webアプリケーションの統合

Fusion Webアプリケーションは、Oracle SOA Suiteによって提供されるサービス指向アーキテクチャ(SOA)プリンシパルを使用して、既存または新規の任意のアプリケーションと統合できます。Oracle SOA Suiteに含まれる宣言型開発ツールにより、サービス、イベント、ビジネス・ルール、ビジネス・プロセス・フロー、その他のSOAテクノロジを使用して、複数のアプリケーションを容易に統合できます。

Fusion Webアプリケーションを構築して、容易に他のアプリケーションと統合できます。アプリケーション・モジュールは、サービスとして公開できます。たとえばビジネス・プロセスを開始するために使用できるイベントを作成することもできます。詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。アプリケーション・モジュールで、他のWebサービスを直接コールすることもできます。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。タスク・フローを使用してアプリケーションを統合することもできます。たとえば、タスク・フローを使用してビジネス・プロセス・フローを開始できます。

Oracle SOA Suiteの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。

1.4 チーム作業による生産性の向上

多くの場合、アプリケーションはチーム開発環境で構築されます。チームベースの開発プロセスは、「Oracle ADFによるアプリケーションの構築の概要」で説明した開発サイクルに従って進めますが、開発者は通常、アプリケーションの様々な部分を同時に作成します。生産性の向上とは、効率的なアプリケーション開発を実現するため、チーム・メンバーが作業を分担し、標準の適用方法を理解し、ソース・コントロール・システムによってソース・ファイルを管理することを意味します。

大規模なアプリケーション開発を開始する前に、設計段階では通常、ユースケースの評価、タスク・フローおよび画面の計画、共有されるリソースの識別を行う必要があります。

次のリストは、初期設計が適用された場合の一般的なFusion Webアプリケーションの作業の分類方法を示しています。

- インフラストラクチャ
管理者は、完成したアプリケーションの構築およびデプロイのためのAntスクリプト(またはその他のスクリプト・ファイル)を作成します。SQLスクリプトを開発して、アプリケーションで使用されるデータベース・スキーマを作成します。

- エンティティ・オブジェクト
大規模な開発環境では、個別の開発グループがアプリケーションのすべてのエンティティ・オブジェクトを構築することがあります。残りのアプリケーションはこれらのオブジェクトに依存するため、エンティティ・オブジェクトはアプリケーションの開発で手順の1つとして、またはアプリケーションの一部として最初に完了する必要があります。

エンティティ・オブジェクトが完了すると、Oracle ADFライブラリを使用して他のチームと共有できます(詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照)。その後、その他のチームが「リソース」ウィンドウでそれらをカタログに追加することでオブジェクトにアクセスします。自社アプリケーション開発プロセスでは、このように作業を分担しないことを選択できます。多くのアプリケーションでは、エンティティ・オブジェクトとビュー・オブジェクトは同じチーム(または1人)により開発され、1つのプロジェクト内に格納されます。

- ビュー・オブジェクト
エンティティ・オブジェクトが作成され、ライブラリまたはプロジェクト内のいずれかに配置されると、(UIを構成する場合に)データ表示に必要なビュー・オブジェクトが必要に応じて作成されるか、または(SOAインフラストラクチャの他のアプリケーションがデータを必要とする場合に)サービス・データ・オブジェクトが提供されます。

開発中は、複数のビュー・オブジェクトが同じ機能を提供している場合があります。これらのビュー・オブジェクトは、オブジェクトの1つの問合せを変更して簡単に組み合せることができるため、各開発者のページまたはサービスのニーズに応じることができます。特に、ビュー基準によって開発者は容易に問合せを個々の用途に適応させることができます。

ビュー・オブジェクトが配置された後は、アプリケーション・モジュールおよびデータ・コントロールを作成し、必要なカスタム・メソッドを追加できます。ビュー・オブジェクトの作成、冗長性の確認、およびアプリケーション・モジュールへのこれらの追加のプロセスは、繰返しのプロセスである場合があります。

- ユーザー・インタフェース(UI)の作成
UI設計を適用し、ビュー・オブジェクトを配置し、データ・コントロールを作成すると、ビュー・オブジェクトを作成したチーム(これについては前項で説明済)または別のチームがUIを作成することができます。データ・コントロールを定義する前にUI設計者がページを作成する、UIファーストの手法を採用して開発することもできます。Oracle ADFでは、UI設計者が開発サイクルの初期に使用できるプレースホルダ・データ・コントロールが提供されます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

1.4.1 標準の適用

別個のチームに分けられた多数のスタッフがアプリケーションを開発することから、開発を始める前に多数の標準を施行して、アプリケーションのすべてのコンポーネントが効率的に連携するようにする必要があります。チーム環境で作業する場合の標準化のために必要なアプリケーション内の領域を次に示します。

- コード・レイアウト・スタイル
複数の人が効率よくコードを使用して作業できるようにするため、特定のコード・スタイルに準拠します。JDeveloperを使用すると、組込みコード・エディタの動作方法を選択できます。ほとんどの設定は、ユーザーのコード・エディタとの対話方法(表示設定など)に影響し、一部の設定はコードのフォーマット方法に影響します。たとえば、左の大カッコの配置位置やインデントのサイズなどを指定するコード・スタイルを選択できます。また、所有している既存のコード・スタイルをインポートしたり、独自のコード・スタイルを作成してエクスポートし、チームで使用できるようにします。詳細は、『Oracle JDeveloperによるアプリケーションの開発』のソース・エディタ用プリファレンスの設定方法に関する項を参照してください。

- パッケージの命名規則
パッケージのネーミング方法のみでなく、各パッケージを構成するオブジェクトの数と種類の粒度も指定する必要があります。

- ページ
「JSFによるユーザー・インタフェースの実装」で説明しているように、UIに関して作業しているすべての開発者が使用するテンプレートを作成できます。すべてのページのルック・アンド・フィールを揃えるのみでなく、テンプレートを変更し、テンプレートを使用するすべてのページにこの変更を適用することもできます。詳細は、「ページ・テンプレートの使用方法」を参照してください。

テンプレートの使用とは別に、ページのネーミング標準を設定する必要もあります。たとえば、ページのアプリケーション内での使用箇所を名前に反映する場合があります。この目標を実現するために、サブディレクトリを作成してレイヤー構成を追加できます。

- 接続名: ほとんどのJDeveloperとOracle ADFのオブジェクトは、プロジェクトごとに一度のみ作成され、参照および使用するユーザーに関係なく、定義によって同じ名前を持ちますが、データベースの接続名は、同じ接続名の詳細にマッピングする場合でも、個々のチーム・メンバーによって作成できます。名前の不一致によって、不要な競合が生じる場合があります。まず、チーム・メンバーが大文字/小文字が区別される共通の接続名に同意し、該当チームの全メンバーがそれを使用する必要があります。

1.4.2 ソース・コントロール・システムの使用

チーム環境で作業する場合、ソース・コントロール・システムを使用する必要があります。デフォルトでは、JDeveloperはSubversionのソース・コントロール・システムのサポートを提供しており、その他(CVSなど)は拡張機能を通じて利用できます。JDeveloperの別のシステムで作業できるように、拡張子を作成することもできます。これらのシステムをJDeveloper内で使用する方法の詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「ソース・コントロールによるアプリケーションのバージョニング」を参照してください。

Fusion Webアプリケーションでのソース・コントロール使用の提案を次に示します。

- ファイルのチェックアウト
JDeveloperを使用すると、ソース・コントロール・サーバーへの接続を作成し、ソース・コントロール・ウィンドウを使用してソースをチェックアウトできます。ファイルをローカルで操作する場合、変更されたファイルは保留中の変更ウィンドウにより通知されます。JDeveloperに組み込まれているApache Antを使用すると、スクリプトを作成できます。作成したスクリプトを使用して、すべてのアプリケーション・ワークスペースをローカルでビルドできます。これにより、変更されたファイルをソース・コントロール・リポジトリにチェックインする前にソース・ファイルをコンパイルできます。Apache Antを使用してスクリプトを作成する方法の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のApache Antによる構築に関する項を参照してください。

- ビルドの自動化
連続的な統合ツールを実行するようにしてください。ファイルがソース・サーバーにチェックインされると、このツールを使用して、ファイルが変更されたかどうかを認識したり、変更されたファイルを指定した間隔でチェックしたりできます。この時点で、このツールを使ってサーバーでAntスクリプトを実行して、完全なソースをコピーし(チェックアウトではなくコピー)、これらのファイルをコンパイルすることができ、コンパイルが成功すると、アプリケーションの(開発者用ではなく)コンシューマが使用するZIPファイルが作成されます。このスクリプトによって、次にソース・ディレクトリがクリーンアップされます。連続的な統合ツールを実行すると、リポジトリ内のコードの品質が向上し、開発者が頻繁に更新を行うようになるため、更新の量と競合の数が減少します。Hudson(http://hudson-ci.org/)は、連続的な統合ツールの例です。

- ファイルの更新およびコミット
Subversionの処理時、更新およびコミットは各ファイルではなく「作業用コピー」レベルで行う必要があります。各ファイルをコミットおよび更新しようとしている場合、サポートするメタデータ・ファイルがなく、そのためアプリケーションのコミット済コピーが破損する場合があります。

- マージ競合の解決
ADFビジネス・コンポーネントのデータ・モデル・プロジェクトでビジネス・コンポーネントの追加または削除を実行すると、JDeveloperはそれをプロジェクト・ファイル(.jpr)に反映します。作成(またはリファクタ)によって新しいパッケージにコンポーネントが格納されると、JDeveloperはそれをプロジェクト・ファイルとADFビジネス・コンポーネント・プロジェクト構成ファイル(.jpx)に反映します。XMLフォーマットのこれらのプロジェクト管理ファイルはマージ競合の発生が減るように最適化されていますが、マージ競合は発生する可能性があり、それらのマージ競合は、影響を受ける各ファイルのポップアップ・メニューにある「競合の解決」オプションを使用してJDeveloperで解決する必要があります。

ADFビジネス・コンポーネントのXMLコンポーネント・ディスクリプタ・ファイル、データ・モデル・プロジェクトのプロジェクト・ファイル(.jpr)または対応するADFビジネス・コンポーネント・プロジェクト構成ファイル(.jpx)でマージ競合が解決した後は、プロジェクトを一度閉じてから再度開き、最新バージョンのコンポーネント定義を使用していることを確認してください。これを実行するには、「アプリケーション」ウィンドウでプロジェクトを選択し、JDeveloperメイン・メニューから「ファイル」→「閉じる」を選択し、「アプリケーション」ウィンドウで再度プロジェクトを開きます。

1.5 Oracle JHeadstartを使用した、完全なWeb階層の生成

このガイドの後半で説明するように、JDeveloperおよびOracle ADFでは、宣言的な開発経験を最大限に活用し、機能豊富でデータベース中心のJava EEアプリケーションを構築するための、生産性の高いビジュアルな環境を提供します。しかし、Oracle Designerのように、高レベルなアプリケーション構造定義に基づく完全なユーザー・インタフェース生成を提供するツールの使用経験がある場合、Java EE開発でも同様の機能が必要になる場合があります。その場合は、Oracle JHeadstart Application Generatorが適しています。これはOracle ADFの組込み機能を使用するJDeveloperの拡張機能で、アプリケーション・モジュールに対して完全なWeb階層の生成を実現します。ADFビジネス・サービスのために設計したデータ・モデルを開始点として、JHeadstartによりJDeveloper環境に追加された統合エディタを使用し、より高レベルのアプリケーション構造の定義を繰り返し修正できます。これらのエディタでは、生成されたWebユーザー・インタフェースのビュー・オブジェクト情報の機能と組織を制御します。チェック・ボックスのチェック、およびドロップダウン・リストからの様々なオプションの選択によって、検索するリージョン、検証を含めた値リスト(LOV)、シャトル・コントロール、ネストされた表およびその他の機能などの様々な形式を含む、ページの論理階層を表すことができます。このような宣言的な選択では、Oracle FormsやDesignerのユーザーが使い慣れた用語が使用されるため、Web開発がさらに容易になります。アプリケーション構造定義に基づき、Oracle ADFおよびJSFが提供する最も高度な機能を容易に活用して、このガイドに示すベスト・プラクティスを自動的に実装する完全なWebアプリケーションを生成できます。

JHeadstart Application Generatorを実行する場合は、コードが生成されるのではなく、Oracle ADFベースのWebアプリケーションのすべての宣言的なビューおよびコントロール・レイヤーのアーティファクトが作成(または再生成)されます。これらのアーティファクトは、ADFモデルを使用し、ビジネス・サービスとしてADFアプリケーション・モジュールと連携します。生成されたファイルは、JDeveloperに組み込まれたビジュアル・エディタを使用して生成するファイルと同様のものです。JHeadstartにおける相違点は、高レベルの定義に基づいてファイルをバルク・ベースで作成し、生成されたページがエンド・ユーザーの要件に可能なかぎり一致するまで繰り返し修正できるということです。生成されるファイルは次のとおりです。

- データバインドされたADF Faces UIコンポーネントを含むJSFページ

- 各ページのデータ・バインディングを表すADFモデル・ページ定義XMLファイル

- ページ・フローを処理するJSFナビゲーション・ルール

- ローカライズ可能なUI文字列を含むリソース・ファイル

アプリケーションのWebユーザー・インタフェースを最大数まで生成した後は、JDeveloperの生産性の高い環境で結果を調整し、特に注意が必要なモデルとなるページに集中できます。生成したページを変更した後は、Application Generatorのページの実行時に再生成されないように設定を調整できます。また、生成されたページとカスタム設計のページが同一のADF Faces UIコンポーネントを利用しているため、すべてのページに同一のルック・アンド・フィールが自動的に継承されます。価格、サポートおよび追加サービスを含め評価用のフル機能装備のJHeadstart試用版を入手する方法の詳細は、次のOracle Technology NetworkのJHeadstartのページを参照してください。

http://www.oracle.com/technetwork/developer-tools/jheadstart/ overview/index.html

1.6 Oracle ADFの学習に関する他のリソース

この開発者ガイドに加えて、アプリケーションでのOracle ADFの活用方法を理解するために役立つ次のリソースも用意されています。

- チュートリアル: JDeveloperキュー・カードはOracle ADFを使用したアプリケーション開発プロセスを段階的にサポートします。それらは、用意されている例とサンプル・スキーマを使用するように設計されていますが、独自のデータを使用することもできます。チュートリアルには、詳細な背景情報を紹介したトピック、各ステップの進め方をカード形式で説明するビューレットおよびコード・サンプルも含まれています。チュートリアルでは、簡単なエンドツーエンドのタスクにより、Oracle ADFの基本機能および操作方法を迅速かつ簡単に理解できます。

- ADF Insider、Oracle ADFをより短期間で習得するために役立つ記録されたセッションを含むOracle Technology Network上のテクニカル・ペーパー、サンプルなど

- Oracle PressおよびPackt Publishingでは、JDeveloperやOracle ADFに関する書籍を多数出版しています。http://www.oracle.com/technetwork/developer-tools/adf/learnmore/index.htmlを参照してください。

- Oracle Universityでは、Oracle ADFのトレーニングと認定を行っています。詳細はhttp://education.oracle.comを参照してください。

- Oracle ADFテクノロジをサポートしている他の開発者ガイド: オラクル社では、データ・コントロール(ADFビジネス・コンポーネント用以外)、ADF Faces、ADFデスクトップ統合用の開発者ガイドなどを多数用意しています。関連ガイドの詳細は、このマニュアルの「はじめに」で「関連ドキュメント」を参照してください。

2 ADFサンプル・アプリケーションの概要

この章では、Oracle ADF用のSummitサンプル・アプリケーションを実行する方法を説明します。これらのサンプルはFusion Webアプリケーション・テクノロジ・スタックを使用してトランザクションベースのWebアプリケーションを作成する方法を具体的に示すために用意されています。Oracle ADF用Summitサンプル・アプリケーションを実装するスキーマと機能の詳細も記載されています。

各コンポーネントとそれらのソース・コードについて深く考察する前に、Oracle ADF用Summitサンプル・アプリケーションをインストールしてその機能に慣れておくことをお薦めします。このデモ・アプリケーションは、要点やコード・サンプルを説明する例として、このガイド全体を通して使用されます。

この章の内容は次のとおりです。

- Oracle ADF用Summitサンプル・アプリケーションについて

- Oracle ADF用Summitサンプル・アプリケーションの設定

- SummitADFワークスペースでのコアSummit ADFサンプル・アプリケーションの実行

- SummitADF_Examplesワークスペースからのスタンドアロン・サンプルの実行

- SummitADF_TaskFlowsワークスペースでのサンプル・アプリケーションの実行

- SummitADF_DVTワークスペースでのスタンドアロン・サンプルの実行

2.1 Oracle ADF用Summitサンプル・アプリケーションについて

Oracle ADF用Summitサンプル・アプリケーションは、Oracle ADFテクノロジ・スタック(ADFビジネス・コンポーネント、ADF Faces、ADFデータ視覚化ツール(DVT)、ADF ControllerおよびADFデスクトップ統合)のコンポーネント間の統合を含め、Fusion Webアプリケーションに共通するユースケースを具体的に示す目的で開発された一連のアプリケーションです。

サンプル・アプリケーションはADFコンポーネント機能の特定の機能に重点を置いたいくつかのJDeveloperアプリケーション・ワークスペースから構成されています。各アプリケーション・ワークスペースは同じ基礎となるデータベース・スキーマを使用します。このアプローチはソース・コードへのアクセスを非常に容易にするとともにワークスペースでのサンプルの実行時動作を非常に円滑化します。これらのサンプル・アプリケーションはFusion Webアプリケーション用の広範なOracle ADF機能をカバーし、総称してOracle ADF用Summitサンプル・アプリケーションと呼ばれています。このガイドの各章で、これらのサンプル・アプリケーションから抜粋したサンプル・コードについて説明しています。

基礎となるSummit ADFスキーマによってサポートされるコアSummit ADFサンプル・アプリケーションはOracle ADFへの適切な導入部分としての役割を果たします。架空の顧客管理Webサイトに基づいて実行可能なアプリケーションが提供され、Oracle ADFの多数のユーザー・インタフェース設計およびデータベース・トランザクション機能が具体的に示されます。コアSummit ADFサンプル・アプリケーションとそれが実装する機能の詳細は、「SummitADFワークスペースにおけるサンプル・アプリケーションの考察」を参照してください。

その他のSummit ADFサンプル・アプリケーションはOracle ADF機能へのより包括的な導入部分の役割を果たし、中には小規模なスタンドアロン・サンプルもあれば、コア・サンプル・アプリケーションの拡張版もあります。Summit ADFサンプル・アプリケーション・ワークスペースと各サンプルが提供する機能の説明の一覧は、表2-1を参照してください。

アプリケーション・ワークスペースからサンプルのいずれかを表示および実行するには、Oracle JDeveloper Studioをインストールする必要があります。その後、Summit ADFスキーマとこのデモンストレーション用のサンプル・アプリケーションを含むZIPアーカイブ・ファイルをダウンロードする必要があります。これらのタスクを完了する手順は、この章で説明します。開始手順は、「Oracle ADF用Summitサンプル・アプリケーションの設定」を参照してください。

2.2 Oracle ADF用Summitサンプル・アプリケーションの設定

Oracle ADF用Summitサンプル・アプリケーションはOracleデータベースとJDeveloperを使用して実行します。サポートされるプラットフォームは、JDeveloperによってサポートされるプラットフォームと同じです。

環境を準備しサンプル・アプリケーションを実行するには、必要なアプリケーション・リソースをダウンロードする必要があります。それらのリソースは、Summit ADFサンプル・アプリケーション・ワークスペースが含まれるZIPアーカイブ・ファイルに含まれています。

表2-1はOracle Technology Network (OTN) Webサイトからダウンロードして入手できるサンプル・アプリケーション・アーカイブ・ファイルを示しています。すべてのサンプル・アプリケーションを単一のアーカイブ・ファイルでダウンロードすることも選択できれば、特定のOracle ADFテクノロジに重点を置いている場合はアーカイブ・ファイルの中から目的のサンプルのみをダウンロードするように選択することもできます。

表2-1 Summitサンプル・アプリケーションのダウンロード可能なZIPアーカイブ・ファイル

ダウンロード可能なサンプル

ZIPアーカイブの説明

SummitADF1221.zip

Oracle ADF用Summitサンプル・アプリケーションがすべて含まれた、1回のみのダウンロードで済む便利なファイル。また、データベースにSummit ADFスキーマをインストールするために必要なビルド・ファイルも含まれています。

注意: このZIPファイルを開くと、下にリストしたサンプル・アプリケーションごとに個別のアプリケーション・ワークスペースが作成されます。

SummitADF_Schema1221.zip

データベースにSummit ADFスキーマをインストールするために必要なビルド・ファイルを含むアプリケーション・ワークスペースが含まれています。Summit ADFスキーマはSummit ADFサンプル・アプリケーションを実行するために必要です。スキーマのインストール方法の詳細は、「Summit ADFスキーマのインストール方法」を参照してください。

SummitADF_Core1221.zip

コアSummit ADFサンプル・アプリケーションを含むアプリケーション・ワークスペースが含まれています。この基本アプリケーションは、Fusion WebアプリケーションでOracle ADFテクノロジを示すためのWebユーザー・インタフェースとビジネス・サービス・レイヤーで構成されています。このアプリケーションの詳細は、「SummitADFワークスペースにおけるサンプル・アプリケーションの考察」を参照してください。

SummitADF_TaskFlows1221.zip

ADF用Summitサンプル・アプリケーション・タスク・フローを含むアプリケーション・ワークスペースが含まれています。このアプリケーションはADFタスク・フローをフルに活用することでコアSummit ADFサンプル・アプリケーション上に構築され、Fusion WebアプリケーションでADFセキュリティ、コンテキスト・イベントおよびタスク・フローを示します。

SummitADF_DVT1221.zip

ADF DVTコンポーネント用Summitサンプル・アプリケーションを含むアプリケーション・ワークスペースが含まれています。このアプリケーション・ワークスペースはADF DVTコンポーネントの作成および構成方法を示します。

SummitADF_Examples1221.zip

Oracle ADF用Summitスタンドアロン・サンプル・アプリケーションを含むアプリケーション・ワークスペースが含まれています。このアプリケーション・ワークスペースは、どのサンプル・アプリケーションにも表れないOracle ADF機能を調査できる小規模なサンプル・アプリケーションで構成されています。

SummitADF_DI1221.zip

ADFデスクトップ統合用Summitサンプル・アプリケーションを含むアプリケーション・ワークスペースが含まれています。このサンプル・アプリケーションはADFデスクトップ統合機能をフルに活用することでコアSummitサンプル・アプリケーション上に構築されています。

注意: このサンプルはこのガイドでは説明されていません。ADFデスクトップ統合用Summitサンプルの詳細は、『Oracle ADFデスクトップ統合によるアプリケーションの開発』のADFデスクトップ統合サンプル・アプリケーションの概要に関する項を参照してください。

2.2.1 アプリケーション・リソースのダウンロード方法

Oracle ADF用Summitサンプル・アプリケーションでは、そのデータ用に既存のOracleデータベースが必要です。JDeveloperを使用してサンプル・アプリケーションを実行します。

サンプル・アプリケーションをインストールする前に次のことを実行します。

アプリケーション・リソースをダウンロードして環境を準備するには:

1. 『Oracle JDeveloperのインストール』の説明に従い、Oracle JDeveloperリリース12cをインストールします。

アプリケーションのプロジェクトを表示し、アプリケーションを統合WebLogic Serverで実行するには、Oracle JDeveloperリリース12cのStudio構成をインストールする必要があります。JDeveloperは、次のURLからダウンロードできます。

http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html

注意:

JDeveloperをダウンロードしてインストールする際、Java構成ではなくStudio構成を確認してください。これらの詳細は、JDeveloperで「ヘルプ」→「バージョン情報」メニュー・オプションの順に選択して確認できます。

2. 表2-1に示すように、目的のSummit ADFサンプル・アプリケーション・ワークスペースのZIPアーカイブ・ファイルをダウンロードします。使用可能なサンプルをすべてインストールする場合は、単一のアーカイブ・ファイルSummitADF1221.zipをダウンロードできます。

Summit ADFサンプル・アプリケーション・アーカイブ・ファイルをOracle Technology Networkの次のWebページからダウンロードします。

http://www.oracle.com/pls/topic/lookup?ctx=E26099_01&id=jdevcodesamples

3. Oracleデータベースをインストールします。

Oracleデータベース用にSQLスクリプトが作成されているため、11gやOracle Database Express Edition (Oracle Database XE)などのOracle RDBMSの特定のバージョンが必要になります。スクリプトはOracle Database Liteにはインストールされません。Oracle Database Liteやその他のデータベースを使用する場合は、データベース・スクリプトを適宜変更する必要があります。Oracleデータベースは、次のURLからダウンロードできます。

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html

特に、ローカル・マシンにデータベースを設定するには、容量を節約できるOracle Database XEが最適です。Oracle Express Editionは次の場所からダウンロードできます。

http://www.oracle.com/technetwork/database/database-technologies/express-edition/downloads/index.html

2.2.2 Summit ADFスキーマのインストール方法

Summit ADFスキーマをインストールするには、スキーマ・ファイルを解凍し、データベース接続を構成して、build_summit_schema.sqlスクリプトをJDeveloperで実行します。

始める前に:

Oracle ADF用Summitサンプル・アプリケーションが使用しているスキーマについて理解しておくと役立つ場合があります。詳細は、「Summit ADFスキーマのインストール時の処理」を参照してください。

次のタスクを完了する必要があります。

- Oracle JDeveloper Studioをインストールし、インストールの前提条件を満たします。Oracle ADF用Summitサンプル・アプリケーションでは、既存のOracleデータベースが必要です。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFスキーマ・アプリケーション・ワークスペースを含むSummit ADFアーカイブ・ファイルをOracle Technology Networkからローカル・ディレクトリにダウンロードします。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

Summit ADFスキーマをデータベースにインストールするには:

1. Summit ADFスキーマ・アーカイブ・ファイルをダウンロードした場所に移動し、それを解凍します。

2. JDeveloperを起動し、メイン・メニューから「ファイル」→「開く」を選択します。

3. 「開く」ダイアログで、SummitADF_SchemaディレクトリのZIPファイルを開いた場所へ移動し、Summit_Schema.jwsアプリケーション・ワークスペースを選択して「開く」をクリックします。

注意:

単一のアーカイブ・ファイルSummitADF1221.zipをダウンロードした場合は、Summit_Schema.jwsファイルがSchemaフォルダに存在します。Schemaフォルダをダブルクリックします。「Summit_Schema.jws」を選択し、「開く」をクリックします。

4. 「アプリケーション」ウィンドウで、「アプリケーション・リソース」パネルを開きます。

5. 「接続」を右クリックし、「新規接続」→「データベース」を選択します。

6. 「データベース接続の作成」ダイアログで、表2-2のように各自の環境に合せてプロパティを変更します。ダイアログのヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

表2-1 Summit ADFサンプル・アプリケーションのインストールに必要なプロパティ

プロパティ

説明

接続名

接続のわかりやすい名前。この名前は、system_for_summitなどの有効なJava識別子にする必要があります。

ユーザー名

データベースのシステム・ユーザー。次に例を示します。

system

パスワード

システム・ユーザーのパスワード。

ドライバ

データベースのJDBCドライバ。ドロップダウン・メニューから値を選択します。デフォルトはthinで、これは、Oracle Database XEおよびOracle Call Interface (OCI)を使用しない他のOracleデータベースの場合に指定するデフォルト値でもあります。

ホスト名

Oracleデータベースを実行しているサーバーの名前。IPアドレスまたはTCP/IPによって解決可能なホスト名を使用します。デフォルト値はlocalhostです。

SID

Oracle Databaseインスタンスの一意のシステム識別子(SID)。デフォルトはXEで、これはデータベース・サーバーがOracle Database XEを実行する場合に指定するデフォルト値でもあります。サーバーが別のOracleデータベースを実行している場合、SIDは通常ORCLです。

JDBCポート

データベースのポート。デフォルト値は1521です。

注意:

サーバーがリモート・マシンに存在する場合は、スキーマを作成するスクリプトも変更する必要が生じることがあります。スクリプトを開くには、「build_summit_schema.sql」を右クリックして、「開く」を選択します。

図2-1は完成した「データベース接続の作成」ダイアログを示しています。この例では、ローカル・マシンに存在するOracle Database XEインスタンスへの接続が確立されています。

図2-1 Summit ADFスキーマの「データベース接続の作成」ダイアログ

7. 「接続のテスト」をクリックして、稼働中の接続があることを確認します。

8. 「OK」をクリックして接続を作成し、ダイアログを終了します。

9. 「アプリケーション」ウィンドウの「プロジェクト」パネルで「データベース」→「リソース」の順に開きます。

10. 「build_summit_schema.sql」を右クリックし、「SQL*Plusで実行」、接続名の順に選択します。

表示された接続名は、手順6で構成されたものです。

11. 「SQL*Plus接続」ダイアログで、情報が手順6で指定した構成に一致することを確認し「OK」をクリックします。

12. 「SQL*Plusの場所」ダイアログで、「参照」をクリックしデータベース用の実行可能ファイルsqlplus.exeを見つけます。

通常、実行可能ファイルは$ORACLE_HOMEの下のBINディレクトリにインストールされます。$ORACLE_HOMEはOracleデータベース・インストールへのパスを表しています。

13. 「開く」をクリックして実行可能ファイル「sqlplus.exe」を選択し、次に「OK」を選択してダイアログを終了します。

14. 「SQL*Plus」ウィンドウで、手順6で指定したシステム・ユーザーのパスワードを入力します。

パスワードを入力すると、Antビルド・スクリプトがSummit ADFサンプル・アプリケーション・ユーザーを作成し、Summit ADFスキーマの表に移入します。メッセージ - ログ・ウィンドウに、一連のSQLスクリプトが表示され、最終的に次のようになります。

Commit complete.

Commit complete.
SQL>

15. SQLプロンプトで、quitと入力し「SQL*Plus」ウィンドウを終了します。

16. JDeveloperでメイン・メニューから「アプリケーション」→「閉じる」を選択し、Summit ADFスキーマ・アプリケーションを閉じます。

2.2.3 Summit ADFスキーマのインストール時の処理

図2-2は、Oracle ADF用Summitサンプル・アプリケーションのスキーマの概要を示しています。ダイアグラム内の青色の図形は、中核となる7つの表を表しています。その他の表は黄色の図形で示されています。一部の表は順序を使用しますが、ここでは中核の表によって使用されるもののみを示しています。交差する線の数を最小限にするため、スキーマは下から上への階層で表示されます。

図2-2 Oracle ADF用Summitサンプル・アプリケーションのスキーマ・ダイアグラム

青色のダイアグラム要素で示されている中核の表には、次のものがあります。

- S_ITEM: 各注文では、多くの注文品目が記録される場合があります。この表には各注文品目の単価と数量が格納されます。注文の明細品目とその注文IDにより、各注文品目が一意に識別されます。

- S_ORD: この表は、特定の顧客のアクティビティを示します。注文が作成されると、注文日、注文の合計額、その作成者の顧客ID、営業担当者の名前が記録されます。注文が履行されると、注文のステータスと注文の出荷日が更新されます。すべての注文は、順序の割り当てられたIDによって一意に識別されます。

- S_CUSTOMER: この表にはすべてのSummit顧客の名前と住所が格納されます。各顧客は順序の割り当てられたIDによって一意に識別されます。表には、各顧客とSummit営業担当者を関連付ける外部キーも含まれています。

- S_EMP: この表にはシステムと対話するすべての従業員が格納されます。各ユーザーの姓と名、電子メール・アドレス、住所の詳細が格納されます。各ユーザーは、IDによって一意に識別されます。その他のIDは役職および部門情報が格納された表への外部キーを提供し、従業員のマネージャの場合は自己参照型のアソシエーションになります。

- S_PRODUCT: この表には、店舗で入手可能なすべての製品が格納されます。製品ごとに名前と提案される卸売価格が記録されます。すべての製品は、順序の割り当てられたIDによって一意に識別されます。製品の画像とその説明は別々の表に格納され、それぞれが製品IDを参照します。

- S_WAREHOUSE: この表にはSummit製品の在庫を搬送する各倉庫の場所とマネージャが格納されます。倉庫ごとに場所とマネージャが記録されます。倉庫は、順序の割り当てられたIDによって一意に識別されます。

- S_INVENTORY: この表にはSummit製品のインベントリ・データが格納されます。製品を搬送する倉庫ごとに各製品の在庫数、再発注点および最大インベントリ・レベルが記録されます。

中核の表で使用される順序には、次のものがあります。

- S_ITEM_ID: 各新規注文品目のIDを移入します。

- S_ORD_ID: 各新規注文のIDを移入します。

- S_CUSTOMER_ID: 各新規顧客のIDを移入します。

- S_EMP_ID: 各新規従業員のIDを移入します。

- S_PRODUCT_ID: 各新規製品のIDを移入します。

2.2.4 Oracle ADF用Summitサンプル・アプリケーションのデータベース接続の作成方法

Oracle ADF用Summitサンプル・アプリケーションにはデータ・アクセスのためのSummitデータベースへの接続が必要です。デフォルトでは、各アプリケーションはOracleデータベースへのローカル接続を使用するように構成されるため、使用している環境の必要に応じて確認および変更する必要があります。Oracle ADF用Summitサンプル・アプリケーションのデータベース接続を変更する手順はすべてのワークスペースで同一となり、JDeveloperでアプリケーションを開いた後に実行されます。

始める前に:

Summit ADFスキーマについて理解しておくと役立つ場合があります。詳細は、「Summit ADFスキーマのインストール時の処理」を参照してください。

次のタスクを完了する必要があります。

- アプリケーション・リソースをダウンロードして環境を準備するすべての手順を完了します。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFスキーマをインストールします。詳細は、「Summit ADFスキーマのインストール方法」を参照してください。

- アプリケーションの指示に従い、接続先のサンプル・アプリケーションを開きます。

- コアSummit ADFサンプル・アプリケーションの実行方法

- Summit ADFスタンドアロン・サンプル・アプリケーションの実行方法

- ADFタスク・フローのSummitサンプル・アプリケーションの実行方法

- Summit ADF DVTサンプル・アプリケーション・ページの実行方法

Oracle ADF用Summitサンプル・アプリケーションのデータベース接続を作成するには:

1. 「アプリケーション」ウィンドウで、「アプリケーション・リソース」パネルを開きます。

2. 「アプリケーション・リソース」パネルで、「接続」→「データベース」の順に開きます。

既存のデータベース接続が表示されます。コアSummit ADFアプリケーションの場合、データベース接続はsummit_adfです。

3. データベース接続を右クリックし「プロパティ」を選択します。

たとえば、「summit_adf」を右クリックして「プロパティ」を選択します。

4. 「データベース接続の編集」ダイアログで、表2-3のように各自の環境に合せてプロパティを変更します。ダイアログのヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

表2-3 Summit ADFサンプル・アプリケーションのデータベース接続を作成するためのプロパティ

プロパティ

説明

ユーザー名

Summit ADFサンプル・データベースのユーザー名。このプロパティの場合はc##summit_adfを使用する必要があります。Oracle Database 12cでは、ユーザー名がc##で開始する必要があります。

パスワード

Summit ADFサンプル・データベースのパスワード。この値にはsummit_adfを使用する必要があります。

ドライバ

データベースのJDBCドライバ。ドロップダウン・メニューから値を選択します。デフォルトはthinで、これは、Oracle Database XEおよびOracle Call Interface (OCI)を使用しない他のOracleデータベースの場合に指定するデフォルト値でもあります。

ホスト名

データベースのホスト名。次に例を示します。

localhost

JDBCポート

データベースのポート。次に例を示します。

1521

SID

Oracle Databaseインスタンスの一意のシステム識別子(SID)。デフォルトはXEで、これはデータベース・サーバーがOracle Database XEを実行する場合に指定するデフォルト値でもあります。サーバーが別のOracleデータベースを実行している場合、SIDは通常ORCLです。

図2-3は完成した「データベース接続の編集」ダイアログを示しています。この例では、ローカル・マシンに存在するOracle Database XEインスタンスへの接続が確立されています。

図2-3 Summit ADFサンプル・アプリケーションの「データベース接続の編集」ダイアログ

5. 「接続のテスト」をクリックして、稼働中の接続があることを確認します。

6. 「OK」をクリックして接続を作成し、ダイアログを終了します。

7. 「アプリケーション」ウィンドウの「プロジェクト」パネルで、「モデル」→「Model.jprの再ビルド」の順に開きます。

2.3 SummitADFワークスペースでのコアSummit ADFサンプル・アプリケーションの実行

コアSummit ADFサンプル・アプリケーションでは、Summit Managementと呼ばれる架空のスポーツ用品サプライヤによって国際的な顧客向けスポーツ用品器具が販売されています。Summit Managementの従業員は、Webサイトにアクセスして、製品在庫のステータスをモニタリングしながら製品の注文を履行することで顧客の注文を管理できます。このコア・サンプル・アプリケーションの機能は、Oracle ADFテクノロジを初めて使用する方にわかりやすいように限られた数のFusion Webアプリケーション・ユースケースのデモを行うように意図的に制限されています。

コアSummit ADFサンプル・アプリケーションは、Webユーザー・インタフェースとビジネス・サービス・レイヤーで構成されます。特に、次のプロジェクトはコアSummit ADFサンプル・アプリケーションの一部です。

- Model: 顧客管理データにアクセスし、顧客情報および注文データを更新するためのトランザクションをサポートします。

- ViewController: Summitユーザーが顧客リストの参照、注文、注文の詳細の表示、注文のステータスのチェック、製品在庫の確認を行うJSF WebページとJSFFページ・フラグメントを提供します。

2.3.1 コアSummit ADFサンプル・アプリケーションの実行方法

ViewControllerプロジェクトでindex.jspxページを実行することでJDeveloper内でコアSummit ADFサンプル・アプリケーションを実行します。ViewControllerプロジェクトでは、ビュー・テクノロジとしてJavaServer Faces (JSF)を使用し、ModelプロジェクトのADFビジネス・コンポーネントと対話するためにADFモデル・レイヤーを使用します。コアSummit ADFサンプル・アプリケーションの詳細とその実装の詳細は、「SummitADFワークスペースにおけるサンプル・アプリケーションの考察」を参照してください。

始める前に:

Summit ADFスキーマについて理解しておくと役立つ場合があります。詳細は、「Summit ADFスキーマのインストール時の処理」を参照してください。

次のタスクを完了する必要があります。

- Oracle JDeveloper Studioをインストールし、インストールの前提条件を満たします。コアSummit ADFサンプル・アプリケーションには、既存のOracleデータベースが必要です。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFアーカイブ・ファイルをOracle Technology Networkからローカル・ディレクトリにダウンロードし、コアSummit ADFサンプル・アプリケーションを解凍します。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFスキーマをインストールします。詳細は、「Summit ADFスキーマのインストール方法」を参照してください。

SummitADFアプリケーション・ワークスペースでサンプル・アプリケーションを実行するには:

1. JDeveloperでアプリケーションを開きます。

a. メイン・メニューで「ファイル」→「開く」を選択します。

b. SummitADFディレクトリのZIPファイルを開いた場所へ移動し、SummitADF.jwsアプリケーション・ワークスペースを選択して「開く」をクリックします。
図2-4はJDeveloperでSummitADF.jwsアプリケーション・ワークスペース・ファイルを開いた後の「アプリケーション」ウィンドウを示しています。ワークスペースの各プロジェクトの詳細は、「SummitADFワークスペースにおけるサンプル・アプリケーションの考察」を参照してください。

図2-4 SummitADFアプリケーション・ワークスペースのプロジェクト

2. Summitデータベースへの接続を作成します。詳細は、「Oracle ADF用Summitサンプル・アプリケーションのデータベース接続の作成方法」を参照してください。

3. 「アプリケーション」ウィンドウで ViewControllerを開きindex.jsfを右クリックして「実行」を選択します。
アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

ViewControllerプロジェクト内のindex.jspxページが実行ターゲットになります。ページを実行すると、JDeveloperによってブラウザが起動されSummit ADFサンプル・アプリケーションのSummit Management Webページが表示されます。

Summit Management Webページが表示されたら、Webサイトを参照できます。コアSummit ADFサンプル・アプリケーションはOracle ADFアプリケーション・リソースのセキュリティを実装していないため、ログインは必要ありません。

2.3.2 SummitADFワークスペースにおけるサンプル・アプリケーションの考察

JDeveloperでプロジェクトを開くと、各プロジェクト内のアーティファクトの確認を開始できます。コアSummit ADFサンプル・アプリケーションの開発環境は、ModelとViewControllerの2つのプロジェクトに分けられています。

Modelプロジェクトには、製品データをWebアプリケーションに表示できるようにする、データ・モデルに関連付けられたクラスが含まれます。図2-5は、Modelプロジェクトおよび関連するディレクトリを示しています。

図2-5 SummitADFワークスペースのデータ・モデル・プロジェクト

ViewControllerプロジェクトには、ユーザー・インタフェースに関連付けられた次のフォルダが含まれます。

- アプリケーション・ソース: 製品データのアクセスに使用するファイルが格納されます。データをビューにバインドするために、Oracle ADFによって使用されるメタデータ・ファイルが含まれています。

- META-INF: デプロイに使用するファイルが格納されます。

ViewControllerプロジェクトには、バッキングBean、デプロイメント・ファイル、JSFおよびJSFFファイルなどのWebインタフェース用のファイルが含まれています。図2-6は、ViewControllerプロジェクトおよび関連するフォルダを示しています。

図2-6 SummitADFワークスペースのViewControllerプロジェクト

ViewControllerプロジェクトには次のディレクトリが格納されています。

- アプリケーション・ソース: マネージドBeanおよびバッキングBean、国際化に使用するプロパティ・ファイル、Oracle ADFによってバインド・データの表示に使用されるメタデータなど、Webクライアントで使用されるコードが格納されます。

- Webコンテンツ: JSPファイル、イメージ、スキン・ファイル、デプロイメント・ディスクリプタ、ライブラリなどのWebファイルが格納されます。

2.3.2.1 アプリケーションの参照

ViewControllerプロジェクトでindex.jspxページを実行することでコアSummit ADFサンプル・アプリケーションを起動します。デフォルト・ターゲットindex.jsfを使用したアプリケーションの実行方法の詳細は、「SummitADFワークスペースでのコアSummit ADFサンプル・アプリケーションの実行」を参照してください。

index.jsfページは、ページの構造を提供するADFページ・テンプレートによって作成され、各タブ・パネルに表示するためのページ・フラグメントを識別するaf:panelTabbedコンポーネントが使用されています。

Summit ADF Webサイトにアクセスすると、「Welcome」、「Summit Management」および「Inventory Control」の3つのタブが表示されたインデックス・ページ上にサイトが開きます。各タブをクリックすると、インデックス・ページによってリージョンとして参照される個別のページ・フラグメントが表示されます。

「Summit Management」リージョンは顧客とそれらの注文のリストを参照できるメイン・リージョンです。このリージョンはcustomers.jsffページ・フラグメントによって定義され、それ自体はタブ付きパネルを提供するADF Facesコンポーネントによって作成されています。「Browse and Search」パネルは1つのaf:panelTabbedコンポーネントで、「Customer」、「Order」および「Order Dashboard」の各パネルは別のaf:panelTabbedコンポーネントに属しています。

図2-7は「Summit Management」リージョンに表示されるインデックスページと注文を示しています。

図2-7 複数のリージョンがあるインデックス・ページ

実装の詳細の参照先

次は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のうち、データバインドWebページの作成方法を説明している項です。

- Webページの構造の提供
インデックス・ページでは、アプリケーションの機能がリージョンに分割されており、ADF FacesテンプレートとJavaServer Faces (JSF)ページ・フラグメントの組合せを使用して実装されています。ADF Facesテンプレートとフラグメントにより、ADFデータバインド・コンポーネントを追加できます。データバインドされたユーザー・インタフェース・コンポーネントをWebページに追加する前に実行する手順の詳細は、「ADF Facesを使用したWebアプリケーション開発について」を参照してください。

- 様々なコンポーネントを使用したユーザー・インタフェースの設計
JDeveloperでは、データバインドされたコンポーネントをJSFページ用に宣言的に作成できるため、ページのほとんどの内容をコードを見ずに設計できます。「データ・コントロール」パネルから項目をドラッグ・アンド・ドロップすることで、JDeveloperはADFバインディングを使用してADF Faces UIコンポーネントとADFデータ視覚化グラフ・コンポーネントをデータ・コントロールの属性に宣言的にバインドします。ADF FacesコンポーネントでのデータバインドWebページの作成の詳細は、「データバインドされた基本的なページの作成について」を参照してください。

- アプリケーションのエントリ・ポイントの管理
インデックス・ページのページ・フラグメントは個々のADFタスク・フローによってサポートされています。一般的に、Fusion Webアプリケーションでは、ADF Controllerのこの機能を利用してアプリケーションへのエントリ・ポイントを定義します。アプリケーションが複数のページを使用している場合は、アプリケーションのエントリ・ポイントを制御するためにバインドなしタスク・フローを定義します。JDeveloperの「コンポーネント」ウィンドウからドラッグ・アンド・ドロップするビジュアル設計要素はタスク・フローの作成に役立ちます。ADFバインドなしタスク・フローを使用してアプリケーションのエントリ・ポイントを指定する方法の詳細は、「ADFタスク・フローについて」を参照してください。

2.3.2.1.1 顧客リストの参照

顧客リストを表示するには、「Customers」ツリーで「Browse」タブをクリックし、国ノードを開いてその国の顧客リストを表示します。顧客リストはADF Faces af:treeコンポーネントによって作成された閉じられたノードでレイアウトされています。ツリー・コンポーネントのドロップダウン・メニューを使用して国別または営業担当者別のブランチを作成できます。ツリーのノードは、各顧客の名前とIDに対応したデータベースからのデータを表示します。

図2-8は顧客ノードの選択肢を示す展開されたツリーを示しています。

図2-8 顧客名とIDを表示するデータバインド・ツリー・コンポーネント

実装の詳細の参照先

次は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のうち、製品詳細の参照をサポートするために使用されるコンポーネントを開発する方法を説明している項です。

- Webページでのデータの表示
データ・モデルからのデータを表示するため、Webページのユーザー・インタフェース・コンポーネントは、JSF式言語(EL)式を使用してADFモデル・レイヤー・バインディング・オブジェクトにバインドされます。たとえば、ユーザーが「Customers」ツリーで国ノードを展開するとその国の顧客リストが表示され、JSFランタイムがUIコンポーネントのEL式を評価し、ADFモデル・レイヤーから値を取得します。設計時に「データ・コントロール」パネルを使用してデータ・コレクションの項目の属性をWebページにドラッグし、ADF Facesコンポーネントを選択して値を表示すると、関連データを表示および更新するために必要なすべてのJSFタグとバインディング・コードがJDeveloperによって作成されます。「データ・コントロール」パネルおよび宣言的なバインディング機能の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

2.3.2.1.2 顧客の検索

顧客リストを検索するには、「Summit Management」リージョンで「Search」タブをクリックします。タブをクリックすると、問合せ検索フォームに検索基準を入力し、下の表に検索結果を表示できるように「Browse」パネルが変わります。検索パネルのレイアウトはADF Faces af:queryコンポーネントによって定義されます。

「Search」フォームの入力フィールドを使用して、顧客名や都市などすべての顧客に共通する属性を対象に簡単なキーワード検索を実行します。たとえば、特定の文字で始まる顧客のリストをデータベースに問合せることができます。

図2-9は「S」で始める都市を所在地とする顧客について戻された検索結果を示しています。

図2-9 問合せ検索コンポーネントによってフィルタされた顧客リスト

実装の詳細の参照先

次は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のうち、問合せを定義し問合せ検索フォームを作成する方法を説明している項です。

- 表示する問合せ検索フォームの定義
問合せは、データベースに対して特定の問合せを定義するためにデータ・モデル・プロジェクトで作成するADFビジネス・コンポーネント・ビュー・オブジェクトに関連付けられています。特に、問合せコンポーネントは、ビュー・オブジェクトに定義されたビュー基準を図示したものです。ビュー基準が複数定義されている場合、各ビュー基準は「保存済の検索」ドロップダウン・リストから選択できます。これらの保存済の検索は、開発者によって設計時に作成されます。そのビュー・オブジェクトに関連付けられている問合せを実行すると、両方のビュー基準が選択可能になります。詳細は、「検索フォームの作成について」を参照してください。

- 検索フォームの作成
問合せ検索フォームは、名前付きビュー基準項目を「データ・コントロール」パネルからページにドロップして作成します。ドロップするものとして、検索パネルのみ、検索パネルと結果表、検索パネルとツリー表のいずれかを選択できます。詳細は、「問合せ検索フォームの作成」を参照してください。

- 問合せ検索の結果の表示
通常は、問合せ検索パネルとともに結果表またはツリー表をドロップします。JDeveloperは自動的に結果表またはツリー表を問合せパネルと関連付けます。問合せパネルのみをドロップし、独立した結果コンポーネントが必要な場合は、問合せコンポーネントのresultComponentId属性を結果コンポーネントの相対表現に設定できます。詳細は、「問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。

2.3.2.1.3 顧客の詳細の表示

顧客の注文の参照を開始するには、「Summit Management」タブをクリックして、「Browse」タブまたは「Search」タブから展開された「Customers」ツリーを選択します。このアクションは、「Summit Customer Management」タブに表示されている詳細を選択した顧客に関する詳細を表示するように変更します。

「Customer details」タブでパネルを開閉し選択した顧客の様々な詳細を表示できます。最初の3つのパネルには顧客の詳細に対応する個々の入力フィールドで構成された入力フォームが表示されます。選択した顧客は「Orders」パネルに1つ以上の注文が表として表示され、各行は単一の注文とその詳細で構成されています。

この顧客と注文の関係は、マスターとディテールとして知られるビジネス・オブジェクトの関係を表しています。この場合、マスター(親オブジェクト)は多数のディテール行(子オブジェクト)を持つことができます。Summit ADFサンプル・アプリケーションのビジネス・オブジェクトは順番に、データベース内のS_CUSTOMER表とS_ORD表に対応しています。

注文の表はADF Faces af:tableコンポーネントによって定義されています。表ヘッダーのセルにあるソート・ボタンをクリックすると表の行をソートできます。

図2-10は上部に顧客の詳細が表示され、下部に顧客固有の注文リストが表示される顧客ページのフラグメントを示しています。

図2-10 注文リストを示す「Customers」ページ・フラグメント

実装の詳細の参照先

次は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のうち、表とフォームを使用してマスター/ディテール関連のオブジェクトを表示する方法を説明している項です。

- マスター・コンポーネントとディテール・コンポーネントのドラッグ・アンド・ドロップ
「データ・コントロール」パネルを使用して、マスター/ディテール・データを表示するページを作成できます。「データ・コントロール」パネルにはマスター/ディテール関係にあるオブジェクトが階層に表示されますが、ADFアプリケーション・モジュールのデータ・モデルでの定義が反映され、ディテール・オブジェクトがマスター・オブジェクトの子となります。そのために必要な操作は、コレクションをページにドロップして、使用するコンポーネントのタイプを選択することのみです。たとえば、コアSummit ADFサンプル・アプリケーションのcustomers.jsffページ・フラグメントでは、af:treeコンポーネントに顧客カテゴリのマスター・リストが表示され、af:tableコンポーネントに注文のディテール・リストが表示されます。データ・モデルの詳細は、「ADFデータ・コントロールを使用したアプリケーション・モジュールの公開」を参照してください。マスター/ディテール関係のあるデータが表示される様々なタイプのページの詳細は、「マスター/ディテール・データの表示について」を参照してください。

- 表に表示されるデータのソート
ADF Faces表コンポーネントを作成する場合は、表をコレクション全体にバインドするか、データ・オブジェクトの範囲にコレクションからバインドします。これにより、列にデータを表示する特定のコンポーネントがコレクションの属性にバインドされます。イテレータ・バインディングによって各オブジェクトの適切なデータが表示され、表コンポーネントによって各オブジェクトが1行で表示されます。イテレータでorder-by問合せを実行して順序を決定する場合は、任意の列に対して「ソート」プロパティを設定できます。データ・モデル・プロジェクトのビュー・オブジェクトで定義されている問合せに対して、ORDER BY句を指定することもできます。表コンポーネントをコレクションにバインドする方法の詳細は、「ADFによるデータバインドされた表の作成について」を参照してください。データ・モデルのデータをソートする問合せを作成する方法の詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。

2.3.2.1.4 注文の詳細の表示

既存の注文の詳細を更新するには、「Customer」タブに表示されている「Orders」表から注文を選択し「Order」タブをクリックします。「Order」タブに選択した行に表示されたデータと同じデータが表示されるが、更新可能なフィールドを持つ編集フォームとして編成されています。たとえば、注文のステータスを変更するために、「OrderFilled」ラジオ・ボタンから選択肢を選択できます。ADF Faces af:selectOneRadioコンポーネントで行われた選択は対応するS_ORD表の列を更新します。

図2-11は「Customer details」タブで注文1075が選択された「Order」ページ・フラグメントを示しています。「Order」フォームと「Customer details」タブの両方の注文1075のデータはデータベース内の変更を反映するようにアプリケーションによって調整されます。「OrderFilled」のステータスを「Yes」に変更し「Customer details」タブに戻ってステータスが一貫していることを確認します。

図2-11 注文の詳細を表示する「Orders」ページ・フラグメント

日付や通貨などのその他のデータ型は値の形式を処理するためのADF Facesコンポーネントを使用して表示できます。図2-12は「Date Shipped」フィールドの基礎となっている属性に定義されたデータ形式を示すシステム・エラーが表示された「Order」ページを示しています。

図2-12 フォーマット・マスク・エラーを示す「Orders」ページ・セグメント

Groovy計算式に基づく検証ルールをデータ更新に定義できます。図2-13は「CREDIT」の「Payment Type」を選択可能にする前に顧客のクレジット・スコアを計算した際の検証エラーを表示した「Order」ページ・フラグメントを示しています。

図2-13 支払タイプ検証エラーを表示した「Orders」ページ・フラグメント

実装の詳細の参照先

次は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のうち、編集フォームの作成方法を説明している項です。

- データバインドされた編集フォームの作成
ユーザーが入力した値を取得する基本フォームを作成する場合、JDeveloperでは、属性を個別にドロップする必要はなく、オブジェクトのすべての属性を入力フォームとして一度にドロップできます。値を表示するフォーム、ユーザーが値を編集できるフォームおよび値を収集するフォームを作成できます。たとえば、コアSummit ADFサンプル・アプリケーションではページ・フラグメントOrders.jsffは注文情報を表示するためのフォームを表示します。詳細は、「既存レコードを編集するフォームの作成」を参照してください。

- フォームを完了するためのデータの要求
入力フォームには、「データ・コントロール」パネルからドロップしたデータ・コレクションの属性が表示されます。このフォームで個々のコンポーネントのrequiredプロパティを設定し、属性値を必須にするかどうかを制御できます。requiredプロパティをカスタマイズする方法の詳細は、「データ・コントロール属性を使用したテキスト・フィールドの作成」を参照してください。または、表示のコントロール・ヒントのプロパティを、ADFビジネス・コンポーネント・エンティティ・オブジェクトによって定義されている属性に直接設定できます。エンティティ・オブジェクトは、データベース内の特定の表の行を表し、関連付けられた属性の変更を簡略化するためのデータ・モデル・コンポーネントです。コントロール・ヒントを使用して属性を必須にする方法の詳細は、「属性プロパティの設定」を参照してください。

- 選択リストの値リストの定義
ユーザー・インタフェースに表示される入力フォームでは、データバインドADF Faces選択コンポーネントを使用して、データ・コレクションの個々の属性の値リスト(LOV)を表示できます。この一般的な設計タスクを容易にするために、ADFビジネス・コンポーネントでは、データ・モデル・プロジェクトの属性のLOVの使用法を指定する宣言的な方法をサポートしています。たとえば、コアSummit ADFサンプル・アプリケーションではページ・フラグメントOrders.jsffに表示された支払タイプ・フィールドのaf:selectOneChoiceコンポーネントはOrdVOビュー・オブジェクトに構成されたLOV対応の属性にバインドされます。属性に対するLOV構成の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

- フォームのフォーマット・マスクの定義
フォーマット・マスクにより、ユーザーは必要なフォーマットに属性値を指定できます。このタスクを容易にするために、ADFビジネス・コンポーネントでは、データ・モデル・プロジェクトの属性に対してコントロール・ヒントと呼ばれる宣言的サポートを提供します。たとえば、コアSummit ADFサンプル・アプリケーションでは、出荷日を指定するために使用されているOrdVOビュー・オブジェクトの属性はフォーマット・マスク・ヒントとともに構成されページ・フラグメントOrders.jsffに適用されます。入力フォーム・コンポーネントのフォーマット・マスク定義の詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

- データ更新の検証ルールの定義
検証ルールはユーザーが特定のビジネス・ニーズを満たす属性値を提供するように確保するうえで役立ちます。このタスクを容易にするために、ADFビジネス・コンポーネントでは、データ・モデル・プロジェクトの属性に対して宣言的検証を提供しています。たとえば、コアSummit ADFサンプル・アプリケーションでは、支払タイプを指定するために使用されているOrdEOエンティティ・オブジェクトの属性は検証ルールとともに構成されページ・フラグメントOrders.jsffに適用されます。エンティティ・オブジェクトとビュー・オブジェクトにおける属性の検証ルールの定義方法の詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

2.3.2.2 注文プロセス

新しい顧客注文を作成するには、Summitインベントリの製品の残量を減らす一方顧客の注文レコードを更新するデータベース・トランザクションが必要です。「Customer」ページで注文リストの上にある「New」をクリックすると、アプリケーションによって日付のみが表示された新しい注文フォームが作成されます。

図2-14は製品が追加されていない新しい注文フォームを示しています。

図2-14 新しい注文がまだ空の「Order」ページ・フラグメント

注文を作成するには、空の製品リストの上にある「New」をクリックします。次に、「ProductId」フィールドの横にある「Search」アイコンをクリックします。af:inputListOfValuesコンポーネントが製品のデータベースを検索するために使用できるポップアップ・ウィンドウを起動します。検索をより容易にするため、ポップアップ・ウィンドウには製品IDや製品名を含む、S_PRODUCT表からの限られた数のフィールドが表示されます。ランタイムの表示のフィルタ・タイプはデータバインドされたaf:inputListOfValuesコンポーネントに戻るADFバインディングによって実行されます。

ポップアップ・ウィンドウで製品を選択し「OK」をクリックします。「Order」タブは製品表での選択を表示するように更新されます。

図2-15は、注文が製品の注文で構成された「Order」タブを示しています。

図2-15 注文エントリを示す「Order」ページ・フラグメント

注文を完了するため、営業担当者のIDを入力し、「Summit Customer Management」ページの右上隅にある「Commit」ボタンをクリックします。これによりデータベースは新しい注文の詳細で更新され製品のインベントリは減らされます。

顧客の注文履歴を視覚化するため、「Orders Dashboard」タブをクリックします。ダッシュボードにはADF Faces DVTコンポーネントを使用して様々なグラフが表示されます。Shipping Timeグラフはdvt:barChartコンポーネントです。このコンポーネントは注文出荷日が更新されたときにのみ計算される情報に依存しています。表示する日付はランタイムに決定する必要があるためデータベース表からは取得されません。Shipping Timeデータを表示するために棒グラフは各注文の出荷に要する日数を戻すADFビジネス・コンポーネント・メソッド・コールに依存します。

図2-16はAcme Sporting Goods会社による3つの注文に関するダッシュボード情報を示しています。

図2-16 ダッシュボードの詳細を示す「Order」ページ・フラグメント

注文による製品インベントリへの影響を視覚化するため、「Inventory Control」タブをクリックし、次に「Summit Management」タブをクリックします。「Inventory Control」ページには再注文しきい値を下回る製品のみが表示されます。手薄な在庫が視覚的なaf:carouselコンポーネントと表形式のaf:tableコンポーネントの両方で表示されます。手薄な在庫のカルーセルから品目を選択すると選択した品目が現在の行になるように表が更新されることがわかります。表内の現在の行は強調表示されています。これらの2つのコンポーネントはADFモデル・レイヤーを通じてカルーセルが選択されたときに実行されるJavaメソッド・コールに同期されます。

図2-17は26品目のうち13品目の在庫ステータスを示しています。手薄な在庫の表での現在の行選択は在庫カルーセルで表示されている選択を反映しています。

図2-17 手薄な在庫品目を表示する「Inventory Control」ページ・フラグメント

実装の詳細の参照先

次は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のうち、「Orders」および「Inventory Control」ページ・フラグメントでデータベースを更新するために使用されるようなデータベース・フォームを開発する方法を説明している項です。

- コマンド・コンポーネントによるデータ更新のトリガー
データ更新をサポートするために、「Summit Management」リージョンの「Orders」ページではaf:buttonコンポーネントとして表されるコマンド・コンポーネントを使用して、宣言的なADFページ定義ファイルでの特定のADFデータ・コントロール操作の実行を可能にしています。ADFデータ・コントロールの組込み操作によって、レコード間のナビゲート、変更のデータベースへのコミットなどの共通のフォーム機能を宣言的に処理できます。大半の操作はデータ・コントロール内の個々のデータ・コレクションに対応しています。コミットおよびロールバック操作はデータ・コントロール全体に対して使用できます。「データ・コントロール」パネルから操作をドラッグ・アンド・ドロップすると、ボタンやリンクなどの作成するコマンド・コンポーネントの種類を選択するように求められます。組込み操作のトリガー方法の詳細は、「データ・コントロール操作を使用したコマンド・コンポーネントの作成」を参照してください。

- コマンド・コンポーネントによるバッキングBeanメソッド・コールのトリガー
データベースとの対話を処理するためにカスタム・ロジックが必要となることがある操作をサポートするために、「Summit Management」リージョンのInventoryControlページ・フラグメントではaf:carouselコンポーネント上でcarouselSpinListenerを使用してバッキングBeanのInventoryControl.javaに定義されたカスタム・メソッドhandleCarouselSpin()をトリガーしています。カルーセルで品目を選択すると、アクション・リスナーによってaf:tableコンポーネント・イテレータ・バインディングの現在行を更新するバッキングBeanメソッドがトリガーされます。バッキングBeanでのJavaコードの実行方法の詳細は、「データバインドされたCarouselコンポーネントの作成方法」を参照してください。

- 一時セッション情報の追跡とビジネス・コンポーネント・メソッド・コールのトリガー
基礎となる表内の列に属性がマップされるデータ・モデル・プロジェクトを作成する場合、ADFビュー・オブジェクトには、(JavaやGroovy式などを使用して)計算された値を表示する一時属性や値ホルダーである一時属性を組み込むことができます。たとえば、コアSummit ADFサンプル・アプリケーションでは、ページ・フラグメントOrders.jsffの「Orders Dashboard」タブにOrdVOビュー・オブジェクトで定義された式によって計算されたTimeToShip属性の値が表示されます。calculateTimeToShip式はビュー行のOrdVORowImpl.javaクライアント・インタフェースでメソッドを起動します。一時属性をデータ・モデル・プロジェクトで定義する方法の詳細は、「エンティティ・オブジェクトへの一時属性および計算属性の追加」を参照してください。ビュー・オブジェクトにおけるカスタムJavaメソッドの実装の詳細は、「ビュー・オブジェクトおよびビュー行のクライアント・インタフェースの生成方法」を参照してください。

2.4 SummitADF_Examplesワークスペースからのスタンドアロン・サンプルの実行

Oracle ADF用のSummitスタンドアロン・サンプル・アプリケーションには、SummitADFワークスペースに表示されないOracle ADF機能を調査できるように、一連のサンプル・パッケージが含まれています。これらのサンプル・パッケージを総称してSummit ADFスタンドアロン・サンプル・アプリケーションと呼んでいます。スタンドアロン・アプリケーションはSummit ADFスタンドアロン・サンプル・アプリケーションZIPファイルを解凍したSummitADF_Examplesフォルダ内にあるSummitADF_Examplesアプリケーション・ワークスペースのModelプロジェクト内に表示されます。

一般に、スタンドアロン・アプリケーションはADFビジネス・コンポーネントとデータ・モデル・プロジェクトの概念を示します。これらのスタンドアロン・アプリケーションへの参照は、この開発者ガイドの「ビジネス・サービスの構築」に含まれる章全体にわたって登場します。このガイドを読み進めるうちに、概念をさらに詳しく検証するために、対応するスタンドアロン・アプリケーションを実行する必要が生じる場合があります。各スタンドアロン・アプリケーションの概要とドキュメントへのリンクは、「Summit ADFスタンドアロン・サンプル・アプリケーションの概要」の表を参照してください。

2.4.1 Summit ADFスタンドアロン・サンプル・アプリケーションの実行方法

JDeveloperでスタンドアロン・アプリケーションを実行するために使用するアプローチは、個々のパッケージで異なります。一部のパッケージは、JDeveloperがADFビジネス・コンポーネント・データ・モデル・プロジェクトに提供する対話型テスト・ツール(Oracle ADFモデル・テスターと呼ばれます)を使用するように設定されています。それ以外のアプリケーションは、ADFビジネス・コンポーネントAPIを使用して問合せを実行し、結果を表示するJavaテスト・クライアント(TestClientAaa.javaのようなファイル名を持ちます)を提供します。Oracle ADFモデル・テスターの場合は、ツール内ですべての操作を行い、ビジネス・コンポーネントと対話するための便利なユーザー・インタフェースが提供されます。Javaクライアントの場合は、プログラム・ファイルによって結果が出力され、JDeveloperの「ログ」ウィンドウに文が表示されます。

2.4.1.1 Javaテスト・クライアントからのスタンドアロン・サンプル・アプリケーションの実行

スタンドアロン・アプリケーションで、プログラム的にADFビジネス・コンポーネントAPIを実行するテスト・クライアントが提供されている場合は、そのテスト・クライアントを使用してアプリケーションを実行します。

始める前に:

個々のSummit ADFスタンドアロン・サンプル・アプリケーションについて理解しておくと役立つ場合があります。詳細は、「Summit ADFスタンドアロン・サンプル・アプリケーションの概要」を参照してください。

次のタスクを完了する必要があります。

- Oracle JDeveloper Studioをインストールし、インストールの前提条件を満たします。スタンドアロン・アプリケーションには既存のOracleデータベースが必要です。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFアーカイブ・ファイルをOracle Technology Networkからローカル・ディレクトリにダウンロードし、Summit ADFスタンドアロン・サンプル・アプリケーションを解凍します。詳細は、「Oracle ADF用Summitサンプル・アプリケーションの設定」を参照してください。

- Summit ADFスキーマをインストールします。詳細は、「Summit ADFスキーマのインストール方法」を参照してください。

提供されるテスト・クライアントからスタンドアロン・アプリケーションを実行するには:

1. JDeveloperでアプリケーションを開きます。

a. メイン・メニューで「ファイル」→「開く」を選択します。

b. SummitADF_ExamplesディレクトリのZIPファイルを開いた場所へ移動し、SummitADF_Examples.jwsアプリケーション・ワークスペースを選択して「開く」をクリックします。

2. スタンドアロン・アプリケーションのデータベース接続を作成します。詳細は、「Oracle ADF用Summitサンプル・アプリケーションのデータベース接続の作成方法」を参照してください。

3. JDeveloperでSQLスクリプトが必要なスタンドアロン・サンプルに対してSQLスクリプトを実行します。一部のスタンドアロン・アプリケーションは、変更されたバージョンのSummit ADFスキーマと連携します。スキーマの変更を必要とするスタンドアロン・アプリケーションの場合、JDeveloper内で実行する必要があるSQLスクリプトがアプリケーション・プロジェクトに含まれています。スタンドアロン・アプリケーションを一通り実行したら、スクリプトを使用してスキーマの変更を元に戻すことができます。

4. 「アプリケーション」ウィンドウで、プロジェクト・ノードを開きテスト・クライアント(.java)ファイル・ノードを見つけます。テスト・クライアントは、「アプリケーション・ソース」ノードの下にあるパッケージ内に追加されている場合があります。それ以外の場合は、「リソース」ノードにテスト・クライアントはあります。
たとえば、図2-18は、inMemoryOperationsノードを開き、Javaファイル・ノードTestClientRowMatch.javaを選択した例を示しています。

図2-18 「アプリケーション」ウィンドウで選択されたテスト・クライアント

5. テスト・クライアントを右クリックし、「実行」を選択します。
スタンドアロン・アプリケーションに用意されているテスト・クライアントの名前と場所は、「Summit ADFスタンドアロン・サンプル・アプリケーションの概要」の表を参照してください。

実行可能ファイルの初回実行時に統合WebLogic Serverで新規ドメインを起動すると「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

6. JDeveloperの「ログ」ウィンドウでテスト・クライアントの出力を検証します。
予期される結果の詳細は、参照ドキュメントを参照してください。

2.4.1.2 テスト・クライアントなしのスタンドアロン・アプリケーションの実行

スタンドアロン・アプリケーションで、プログラム的にADFビジネス・コンポーネントAPIを実行するテスト・クライアントが提供されない場合は、Oracle ADFモデル・テスターと呼ばれる対話式テスト・ツールを使用します。

始める前に:

個々のSummit ADFスタンドアロン・サンプル・アプリケーションについて理解しておくと役立つ場合があります。詳細は、「Summit ADFスタンドアロン・サンプル・アプリケーションの概要」を参照してください。

また、Oracle ADFモデル・テスターについて理解しておくと役立つ場合があります。詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

次のタスクを完了する必要があります。

- Oracle JDeveloper Studioをインストールし、インストールの前提条件を満たします。スタンドアロン・アプリケーションには既存のOracleデータベースが必要です。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFアーカイブ・ファイルをOracle Technology Networkからローカル・ディレクトリにダウンロードし、Summit ADFスタンドアロン・サンプル・アプリケーションを解凍します。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFスキーマをインストールします。詳細は、「Summit ADFスキーマのインストール方法」を参照してください。

Oracle ADFモデル・テスターでスタンドアロン・アプリケーションを実行するには:

1. JDeveloperでアプリケーションを開きます。

a. メイン・メニューで「ファイル」→「開く」を選択します。

b. SummitADF_ExamplesディレクトリのZIPファイルを開いた場所へ移動し、SummitADF_Examples.jwsアプリケーション・ワークスペース・ファイルを選択して「開く」をクリックします。

2. スタンドアロン・アプリケーションのデータベース接続を作成します。詳細は、「Oracle ADF用Summitサンプル・アプリケーションのデータベース接続の作成方法」を参照してください。

3. JDeveloperでSQLスクリプトが必要なスタンドアロン・サンプルに対してSQLスクリプトを実行します。一部のスタンドアロン・アプリケーションは、変更されたバージョンのSummit ADFスキーマと連携します。スキーマの変更を必要とするスタンドアロン・アプリケーションの場合、JDeveloper内で実行する必要があるSQLスクリプトがアプリケーション・プロジェクトに含まれています。スタンドアロン・アプリケーションを一通り実行したら、スクリプトを使用してスキーマの変更を元に戻すことができます。

4. 「アプリケーション」ウィンドウで、プロジェクト・ノードを開きApplication Sourcesノードの下でパッケージ内のアプリケーション・モジュールを見つけます。
たとえば、図2-19は、controlpostorderプロジェクトを開いてアプリケーション・モジュールAppModuleを選択し、ノードのツールチップが表示された例を示しています。

図2-19 「アプリケーション」ウィンドウで選択されたアプリケーション・モジュール・ノード

5. アプリケーション・モジュール・ノードを右クリックし、「実行」を選択します。
実行可能なアプリケーション・モジュールの名前は、「Summit ADFスタンドアロン・サンプル・アプリケーションの概要」の表を参照してください。

実行可能ファイルの初回実行時に統合WebLogic Serverで新規ドメインを起動すると「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

6. Oracle ADFモデル・テスターを使用して、スタンドアロン・アプリケーションのビュー・インスタンスを操作します。
アプリケーションの詳細は、参照ドキュメントを参照してください。テスターを使用してデータ・モデルを操作する方法の詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

2.4.2 Summit ADFスタンドアロン・サンプル・アプリケーションの概要

SummitADF_Examplesアプリケーション・ワークスペースの2つのスタンドアロン・アプリケーションは、テスト・クライアントを使用して、プログラム的にADFビジネス・コンポーネント・フレームワークに関連する概念を示します。その他のアプリケーションは、Oracle ADFモデル・テスターで実行されたときに、フレームワークの機能を示します。

図2-20はSummitADF_Examplesアプリケーション・ワークスペースを開いた後の「アプリケーション」ウィンドウを示しています。

図2-20 SummitADF_Examplesワークスペースのスタンドアロン・アプリケーション

スタンドアロン・アプリケーションのテスト・クライアントはADFビジネス・コンポーネントAPIのメソッドの実行方法を理解するために適した出発点となることに留意してください。また、データ・モデル・プロジェクトのビジネス・コンポーネント問合せをテストするために作成するテスト・クライアントの有益なサンプルにもなります。テスト・クライアントの操作の詳細は、「ビュー・オブジェクト・インスタンスのプログラムによるテスト」を参照してください。

注意:

ADFビジネス・コンポーネントAPIは、ビジネス・コンポーネントのデフォルトの実行時動作を拡張するカスタム・クラスを生成する必要がある場合に使用できます。ADFビジネス・コンポーネント・フレームワークの詳細は、「ADFビジネス・コンポーネントのスタート・ガイド」を参照してください。

表2-4にSummitADF_Examplesアプリケーション・ワークスペース内のスタンドアロン・アプリケーションを示します。これらのアプリケーションは、このガイドの「ビジネス・サービスの構築」に含まれる章全体にわたって登場します。

表2-4 SummitADF_Examplesアプリケーション・ワークスペース内のスタンドアロン・アプリケーション

パッケージ名

実行可能クラスまたはプロジェクト・ターゲット

ドキュメント

amservice

Oracle ADFモデル・テスターを使用してServiceAppModuleを実行します。

アプリケーション・モジュール・サービス・インタフェースの詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

appmodule

serviceノードの下でTestAM.javaを実行します。

serviceノードの下でTestCustomEntity.javaを実行します。

これらのテスト・クライアントはアプリケーション・モジュールのクライアント・インタフェースのカスタム・メソッドを実行し、JDeveloperの「ログ」ウィンドウに出力して結果を示します。

テスト・クライアントの詳細は、「アプリケーション・モジュールのクライアント・インタフェースのプログラム的な操作方法」を参照してください。

クライアント・インタフェースのメソッドの詳細は、「エンティティ・オブジェクトおよびアソシエーションのプログラム的操作」を参照してください。

buslogic

Oracle ADFモデル・テスターを使用してAppModuleを実行します。

ビジネス・ロジック・ユニットおよびグループの詳細は、「ビジネス・ロジック・グループの定義」を参照してください。

controlpostorder

Oracle ADFモデル・テスターを使用してAppModuleを実行します。

関連するエンティティ・オブジェクト数の変更を保存するためにDML操作に起因するポスト順序を制御する方法の詳細は、「制約違反を防ぐためのエンティティ・ポスト順序を制御する方法」を参照してください。

custommessages

Oracle ADFモデル・テスターを使用してAppModuleを実行します。

カスタム・メッセージ・バンドルでビルドイン・エラー・コードにかわりのメッセージ文字列を提供する方法の詳細は、「ビジネス・コンポーネントのエラー・メッセージのカスタマイズ」を参照してください。

declblock

Oracle ADFモデル・テスターを使用してAppModuleを実行します。

ビュー・オブジェクトへの挿入、更新および削除を制御するカスタム・メタデータ・プロパティの使用方法の詳細は、「挿入、更新および削除の宣言による禁止」を参照してください。

domains

Oracle ADFモデル・テスターを使用してAppModuleを実行します。

カスタム・データ型の作成方法の詳細は、「ドメインを使用したカスタム検証済データ型の作成」を参照してください。

extend

TestClient.javaを実行します。

このクライアントはproductByName.first()メソッドの結果をProductViewRowインタフェースにキャストすることで、メソッド・コールを実行してJDeveloperの「ログ」ウィンドウに出力し、結果を表示できるようにします。

ビジネス・コンポーネントを拡張してオリジナルのカスタマイズ・バージョンを作成する方法の詳細は、「継承を使用する拡張コンポーネントの作成」を参照してください。

ビュー行アクセッサ属性を使用してコレクションを反復処理する方法の詳細は、「クライアントへのビュー行アクセッサの公開」を参照してください。

inMemoryOperations

次のテスト・クライアントを実行します。

- TestClientFilterEntityCache.java

- TestClientFindByViewCriteria.java

- TestClientRowMatch.java

- TestClientSetSortBy.java

これらのテスト・クライアントは、oracle.jboパッケージ内のインタフェースでメソッドを使用して、クライアント側からメモリー内ソート処理およびフィルタ処理機能を使用し、JDeveloperの「ログ」ウィンドウに結果を出力する方法を示します。

データベースへの不必要なトリップを避けるために、ビュー・オブジェクトを使用してメモリー内で検索とソートを実行する方法の詳細は、「行セットのメモリー内でのソート処理とフィルタ処理の実行」を参照してください。

invokingstoredprocedure

例に必要な追加のデータベース・オブジェクトを設定するには、summit_adfデータベース接続に対してExampleSQLPackage.sqlスクリプトを実行します。

TestClient.javaを実行します。

テスト・クライアントは、アプリケーション・モジュールのクライアント・インタフェースのカスタム・メソッドを実行してデータベース・ストアド・プロシージャおよびファンクションを起動し、JDeveloperの「ログ」ウィンドウに出力して結果を示します。

データベースのストアド・プロシージャとストアド・ファンクションを起動するビジネス・コンポーネント用のカスタムJavaクラスのコーディング方法の詳細は、「ストアド・プロシージャとストアド・ファンクションの呼出し」を参照してください。

multieoupdate

Oracle ADFモデル・テスターを使用してAppModuleを実行します。

新しい行の作成をサポートするために複数の更新可能エンティティを持つビュー・オブジェクトを作成する方法の詳細は、「複数の更新可能エンティティによるビュー・オブジェクトの作成」を参照してください。

multinamedviewcriteria

MultiNamedViewCriteriaTestClient.javaを実行します。

テスト・クライアントはビュー・オブジェクト・インタフェースのカスタム・メソッドを実行し、JDeveloperの「ログ」ウィンドウに出力して結果を表示します。

プログラムによる問合せ結果のフィルタ方法の詳細は、「複数の名前付きビュー基準のプログラム的処理」を参照してください。

polymorphic

Oracle ADF Model Testerを使用してPolymorphicAppModuleを実行すると(serviceノードの下で)、アメリカの顧客(CountryId=4)のサブタイプ・ビュー・インスタンスが表示されます。サブタイプ・ビューの慣用名には、サブタイプ属性Stateが表示されます。

このサンプルは、エンティティ・ベースの多相ビュー・オブジェクトを示します。

エンティティ・オブジェクト継承階層の作成の詳細は、「ビジネス・ドメイン・レイヤーでの継承の使用」を参照し、それらのエンティティ・オブジェクトのビューの慣用名の作成の詳細は、「多相エンティティ・オブジェクトの慣用名での作業」を参照してください。

polymorphicvo

Oracle ADF Model Testerを使用してAppModuleを実行すると(serviceノードの下で)、営業部門従業員(TitleId=2)のサブタイプ・ビュー行が表示されます。サブタイプ・ビュー行には、サブタイプ属性CommissionPctが表示されます。

このサンプルは、ビュー行ベースの多相ビュー・オブジェクトを示します。

ビュー行のサブタイプの作成の詳細は、「多相ビュー行関連の作業」を参照してください。

PolymorphicVO_WSClient

(これは、polymorphicvoパッケージのクライアント・プロジェクトです。)

最初に、モデル・プロジェクトのpolymorphicvoパッケージのAppModuleServiceImpl.javaを実行し、次に、Webサービス・クライアントAppModuleServiceSoapHttpPortClient (com.oracle.xmlns.apps.hr.service.typesノードの下)を実行します。クライアント・ファイルによって、新しいsalesmanサブタイプが作成され、JDeveloperのログに出力されます。

このサンプルは、SOAP Webサービス・クライアントでの多相コレクションの操作方法を示します。

サブタイプ・ビュー・オブジェクトの操作方法の詳細は、「コンシューミング・アプリケーションでの多相コレクションへのアクセス」を参照してください。

processChange

processChangeTestClient.javaを実行します。

テスト・クライアントはビュー・オブジェクト・インタフェースのカスタム・メソッドを実行し、JDeveloperの「ログ」ウィンドウに出力して結果を表示します。

データベースの変更通知の起動方法の詳細は、「プログラム的に起動されるデータベース変更通知に関する必知事項」を参照してください。

テスト・クライアントの詳細は、「アプリケーション・モジュールのクライアント・インタフェースのプログラム的な操作方法」を参照してください。

readandwritexml

clientノードの下のTestClientReadXML.javaを実行し、次にTestClientWriteXML.javaを実行します。

問い合わせたデータからXMLを作成する方法の詳細は、「XMLの読取りと書込み」を参照してください。

rest_WS

このパッケージは、将来の使用のために予約されています。

アプリケーション・モジュールのビュー・インスタンスからのRESTful Webサービスの作成の詳細は、「アプリケーション・モジュールによるRESTful Webサービスの作成」を参照してください。

rowfinder

EmpViewで定義された行検索EmpByTitleIdをプログラム的に実行するために、TestClient.javaを実行します。行検索は、テスト・クライアント内でプログラム的に起動することも、SOAP Webサービスで公開されたサービス・データ・オブジェクト(SDO)操作のメソッドから起動することもできます。

または、EmpServiceアプリケーション・モジュール・ノードのserviceinterfaceフォルダを展開して、EmpServiceServiceImpl.javaを実行し、HTTPアナライザで行検索をテストします。HTTPアナライザで、updateEmpView1操作を選択し、TrTitleIdに1と入力し、次に、役職IDが1である個人に基づいて更新するための任意の名前を入力します。

ビュー・オブジェクトのキー属性を要求することなく、任意の属性を使用したレコード参照をサポートするために、ビュー・オブジェクトに行検索を定義できます。

行検索の定義とプログラム的な起動の詳細は、「行検索の使用」を参照してください。

SOAP Webサービスにおける行検索操作の使用の詳細は、「行ファインダとADF Webサービス操作に関する必知事項」を参照してください。

sdo

このパッケージにより、HRAppModuleアプリケーション・モジュールのDeptView1およびEmpView1の各ビュー・インスタンスに基づく、SOAP Webサービスで使用するためのサービス・データ・オブジェクト(SDO)が実装されます。このパッケージはEmpView1 SDOの検索操作を公開します。公開された検索操作をテストするためにクライアント・プロジェクトを実行する手順は、SDO_ClientおよびSDO_WSClientを参照してください。

アプリケーション・モジュールからSDOを作成する方法の詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。

SDO_Client

SDOClientServlet.java SOAP Webサービス・サーブレットを実行します。テスト・クライアントは、モデル・プロジェクトのサービス・パッケージのSOAP Webサービスのビュー基準検索操作として実装されたfindEmpView1()メソッドを実行します。サーブレットtestFindEmps()メソッドによって、動的なビュー基準が作成され、これがfindEmpView1()に渡されることで、従業員の指定された部門でのフィルタ処理と、テスト結果の検証が行われます。これは、SDO_WSClientプロジェクトのサーブレットのバージョンです。

操作の公開の詳細は、「必須バインド変数でフィルタするカスタム検索メソッドの公開方法」を参照してください。

SDO_WSClient

HRAppModuleServiceSoapHttpPortClient.java SOAP WebサービスHTTPポート・クライアントを実行します。テスト・クライアントは、モデル・プロジェクトのサービス・パッケージのSOAP Webサービスのビュー基準検索操作として実装されたfindEmpView1()メソッドを実行します。サーブレットtestFindEmps()メソッドによって、動的なビュー基準が作成され、これがfindEmpView1()に渡されることで、従業員の指定された部門でのフィルタ処理と、テスト結果の検証が行われます。これは、SDO_ClientプロジェクトのWebサービス・クライアント・バージョンです。

ADFサービス・データ・オブジェクトの操作の公開の詳細は、「必須バインド変数でフィルタするカスタム検索メソッドの公開方法」を参照してください。

TaskFlowProducer

ビュー・コントローラ・プロジェクトのWeb Contentフォルダで、RemoteViewer.jsfページを実行します。ページには、コンシューマ・アプリケーションが使用できるリモート起動可能タスク・フローが表示されます。

リモート・タスク・フローの作成の詳細は、「リモート・リージョンをレンダリングするようにアプリケーションを構成する方法」を参照してください。

このサンプル・アプリケーションをデプロイすると、「Fusion Webアプリケーションでのリモート・リージョンの作成」で説明しているように、リモート起動可能タスク・フローを使用できるようになります。

validation

Oracle ADFモデル・テスターを使用してAppModuleを実行します。OrdersView1をクリックし、Data Orderedフィールドを編集すると、プログラムによる検証メソッドを使用した属性レベルでの検証の例を確認できます。

プログラム的なバリデータを作成する方法の詳細は、「プログラムによる検証とビジネス・ルールの実装」を参照してください。

viewobjectonrefcursor

例に必要な追加のデータベース・オブジェクトを設定するには、summit_adfデータベース接続に対してCreateRefCursorPackage.sqlスクリプトを実行します。

Oracle ADFモデル・テスターを使用してAppModuleを実行します。

PL/SQLを使用し、カーソルを開いて問合せの結果を反復処理する方法の詳細は、「REF CURSORでのビュー・オブジェクトの作成方法」を参照してください。

viewobjects

TestClient.javaを実行します。

ビジネス・コンポーネントAPI RowIteratorインタフェースのメソッドを使用して顧客ビュー・インスタンスをプログラム的に反復処理し、JDeveloperの「ログ」ウィンドウに出力します。

コレクションの反復処理の詳細は、「行セットにおける行数計算の方法」を参照してください。

テスト・クライアントの作成方法の詳細は、「ビュー・オブジェクト・インスタンスのプログラムによるテスト」を参照してください。

TestClient2.javaを実行します。

顧客ビュー・インスタンスをプログラム的に反復処理し、ビュー・リンク・アクセッサ属性を使用してディテール・コレクションにアクセスし、JDeveloperの「ログ」ウィンドウに出力します。

ディテール・コレクションの反復処理の詳細は、「ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法」を参照してください。

テスト・クライアントの詳細は、「ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法」を参照してください。

TestClient3.javaを実行します。

外部キーの値を検索および更新してJDeveloperの「ログ」ウィンドウに出力します。

詳細は、「行の検索および外部キー値の更新の方法」を参照してください。

TestClient4.javaを実行します。

ビュー・インスタンスを検索し、新しい行を作成して、それを行セットに挿入し、JDeveloperの「ログ」ウィンドウに出力します。

詳細は、「ビュー・オブジェクト・インスタンスの新しい行の作成方法」を参照してください。

TestClient5.javaを実行します。

ビュー・インスタンスを検索し、行セットにアクセスして、行を反復処理してキーを表示し、JDeveloperの「ログ」ウィンドウに出力します。

詳細は、「行を識別する行キーの取得方法」を参照してください。

wrapplsql

Oracle ADFモデル・テスターを使用してAppModuleを実行します。

基礎となる表に対する挿入、更新および削除のアクセスをカプセル化するPL/SQL APIパッケージのメソッドを起動するために、エンティティ・オブジェクトに対するデフォルトのDML処理イベントをオーバーライドする方法の詳細は、「PL/SQLパッケージAPIに基づくエンティティ・オブジェクト」を参照してください。

2.5 SummitADF_TaskFlowsワークスペースでのサンプル・アプリケーションの実行

ADFタスク・フロー用のSummitサンプル・アプリケーションはFusion Webアプリケーションでセキュリティ、コンテキスト・イベントおよびタスク・フローを実装する方法を示します。

2.5.1 ADFタスク・フローのSummitサンプル・アプリケーションの実行方法

Summit ADFタスク・フロー・サンプル・アプリケーションを実行する最も簡単な方法は、ViewControllerプロジェクトを開き、このプロジェクト内からindex.jsfページを実行することです。

始める前に:

Summit ADFタスク・フロー・サンプル・アプリケーションが使用しているスキーマについて理解しておくと役立つ場合があります。詳細は、「Summit ADFスキーマのインストール時の処理」を参照してください。

次のタスクを完了する必要があります。

- Oracle JDeveloper Studioをインストールし、インストールの前提条件を満たします。Summit ADFタスク・フロー・サンプル・アプリケーションには、既存のOracleデータベースが必要です。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFアーカイブ・ファイルをOracle Technology Networkからローカル・ディレクトリにダウンロードし、ADFタスク・フロー用のSummitサンプル・アプリケーションを解凍します。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFスキーマをインストールします。詳細は、「Summit ADFスキーマのインストール方法」を参照してください。

ADFタスク・フローのSummitサンプル・アプリケーションを実行するには:

1. JDeveloperでアプリケーションを開きます。

a. メイン・メニューで「ファイル」→「開く」を選択します。

b. SummitADF_TaskflowsディレクトリのZIPファイルを開いた場所へ移動し、SummitADF_Taskflows.jwsアプリケーション・ワークスペースを選択して「開く」をクリックします。
図2-21はSummitADF_Taskflows.jwsアプリケーション・ワークスペース・ファイルを開き多数のノードを開いた後の「アプリケーション」ウィンドウを示しています。ワークスペースの各タスク・フローの詳細は、「ADFタスク・フローのSummitサンプル・アプリケーションの概要」を参照してください。

図2-21 Summit ADFタスク・フロー・アプリケーション・ワークスペース内のプロジェクト

2. Summit ADFタスク・フロー・サンプル・アプリケーションのデータベース接続を作成します。詳細は、「Oracle ADF用Summitサンプル・アプリケーションのデータベース接続の作成方法」を参照してください。

3. 「アプリケーション」ウィンドウで「ViewController」および「Webコンテンツ」ノードを開き、「index.jsf」を右クリックして「実行」を選択します。
アプリケーションの初回実行時に統合WebLogic Serverで新規ドメインを起動すると「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

4. ブラウザでindex.jsfページをレンダリングすると、表2-5にリストされたユーザー・アカウントのいずれかを使用してログインし、アプリケーション内で従業員または顧客向けに構成されている機能を表示できます。

表2-5 Summit ADFタスク・フロー・サンプル・アプリケーションで提供されているユーザー

ユーザー名

パスワード

アプリケーション・ロール

注意

cmagee

welcome1

アプリケーションの従業員ロール

これはSummit ADFタスク・フロー・サンプル・アプリケーションで従業員として事前登録されている唯一のユーザーです。

214

welcome1

アプリケーションの顧客ロール

これはSummit ADFタスク・フロー・サンプル・アプリケーションで顧客として事前登録されている唯一のユーザーです。顧客のユーザーID「Ojibway Retail」はユーザー名として使用されます。

2.5.2 ADFタスク・フローのSummitサンプル・アプリケーションの概要

SummitADF_Taskflowsワークスペース内のアプリケーションはFusion Webアプリケーションでセキュリティ、コンテキスト・イベントおよびタスク・フローを実装する方法を示します。

次のリストは、SummitADF_Taskflowsワークスペース内のタスク・フローのファイル名を示しています。これらのタスク・フローを表示するには、「アプリケーション」ウィンドウでViewControllerの下にある「ページ・フロー」ノードを開きます。

|   adfc-config.xml
|
\---flows
|   customers-task-flow-definition.xml
|   edit-customer-task-flow-definition.xml
|   emp-reg-task-flow-definition.xml
|   product-inventory-task-flow-definition.xml
|   show-products-task-flow-definition.xml
|
\---orders
create-edit-orders-task-flow-definition.xml
orders-select-many-items.xml

表2-6には、これらのタスク・フローの概要とこれらのタスク・フローを使用してセキュリティ、コンテキスト・イベント、データ・レンダリングおよびデータ入力に関する概念を示しているこのガイド内の項への参照が記載されています。

これらのタスク・フローの他に、SummitADF_TaskflowsワークスペースにはJDeveloperがアプリケーションのポリシー・ストアとアイデンティティ・ストアのすべての変更を保存するjazn-data.xmlファイルも含まれています。このファイルとその使用方法の詳細は、「ADFセキュリティ・プロセスの概要」を参照してください。

表2-6 Summit ADFタスク・フロー・サンプル・アプリケーション内のタスク・フロー

タスク・フロー名

ドキュメント

adfc-config.xml

すべてのFusion Webアプリケーションにこのファイルが含まれています。Fusion Webアプリケーションを作成するとデフォルトでJDeveloperによって作成されるバインドなしタスク・フローのソース・ファイルです。

Summit ADFタスク・フロー・サンプル・アプリケーションでは、このタスク・フローにはランタイムにエンド・ユーザーに表示されるindex.jsfページをレンダリングするインデックス・ビュー・アクティビティが含まれます。

また、このタスク・フローは認証が必要なリソースへのアクセスを希望するユーザーの認証を処理する管理対象Bean (oracle.summit.bean.LoginBean)の登録も行います。詳細は、「明示的な認証用にログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法」を参照してください。

customers-task-flow-definition.xml

このタスク・フローには認証済の顧客をその顧客がCustomer.jsffページ・フラグメント内で選択した行へナビゲートするためのルーター、ビューおよびメソッド・コール・アクティビティが含まれます。詳細は、「タスク・フロー・アクティビティの使用」を参照してください。

ADFセキュリティは、認証済の顧客のみがこのタスク・フローで構成された機能または公開されたWebページにアクセスできるようにセキュリティを確保します。詳細は、「ADFセキュリティについて」を参照してください。

edit-customer-task-flow-definition.xml

このタスク・フローは認証済ユーザーによるデータの編集を制御するADFリージョン内の多数のページ・フラグメントをレンダリングします。詳細は、「タスク・フローおよびADFリージョンのユースケースと例」を参照してください。

emp-reg-task-flow-definition.xml

Summit ADFタスク・フロー・サンプル・アプリケーションは、エンド・ユーザーがランタイムにindex.jsfページに表示された「Register as Employee」リンクをクリックしたときにADF動的リージョン内でこのタスク・フローをレンダリングします。詳細は、「ADF動的リージョンの作成」を参照してください。

他のタスク・フロー(たとえば、customers-task-flow-definition.xml)と異なり、このタスク・フローにアクセスするためにユーザーを認証する必要はありません。このため、「セキュリティ・ポリシーの定義時の処理」に説明されているとおり、このタスク・フローのセキュリティ・ポリシーでは組込みのanonymous-roleアプリケーション・ロールにview権限を付与します。

product-inventory-task-flow-definition.xml

このタスク・フローは「Inventory Control」タブに表示されるshowInventory.jsffページ・フラグメントをレンダリングします。このタブは従業員としてログインすると有効になります。アプリケーションは、エンド・ユーザーによる別のADFリージョンでのデータ選択に応答して、showInventory.jsffページ・フラグメントにどのデータを表示するかをコンテキスト・イベントを使用して決定します。

タスク・フローによるコンテキスト・イベントの使用方法の詳細は、「コンテキスト・イベントの使用方法」を参照してください。

show-products-task-flow-definition.xml

このタスク・フローは製品に関するデータを含むADF Faces tableコンポーネントをレンダリングするshowProducts.jsffページ・フラグメントをレンダリングします。ランタイムにエンド・ユーザーの製品選択によってproduct-inventory-task-flow-definition.xmlタスク・フローが使用するコンテキスト・イベントがブロードキャストされ、それによって製品の在庫を表示できるようにします。

タスク・フローによるコンテキスト・イベントの使用方法の詳細は、「コンテキスト・イベントの使用方法」を参照してください。

create-edit-orders-task-flow-definition.xml

このタスク・フローはエンド・ユーザーが注文に新しい製品を追加できるOrders.jsffページ・フラグメントをレンダリングします。また、「タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール方法」で説明されているとおり、別のタスク・フロー(orders-select-many-items)もコールします。

orders-select-many-items.xml

「モーダル・ダイアログ内でのバインド・タスク・フローの実行」で説明されているとおり、このタスク・フローはモーダル・ダイアログをレンダリングします。

2.6 SummitADF_DVTワークスペースでのスタンドアロン・サンプルの実行

ADF DVTコンポーネント用のSummitサンプル・アプリケーションにはADFビジネス・コンポーネントとデータ・バインディングを使用したADF DVTコンポーネントの作成と構成を示す一連のスタンドアロン・サンプル・ページが含まれています。

これらのスタンドアロン・ページへの参照は次の章の全体を通じて示されています。

- データバインドされたチャート・コンポーネントおよびゲージ・コンポーネントの作成

- データバインドされたピボット・テーブルおよびピボット・フィルタ・バー・コンポーネントの作成

- データバインドされた地理マップ・コンポーネントおよびテーマ・マップ・コンポーネントの作成

- データバインドされたガント・チャート・コンポーネントおよび時系列コンポーネントの作成

- データバインドされた階層ビューア、ツリーマップおよびサンバースト・コンポーネントの作成

2.6.1 Summit ADF DVTスタンドアロン・サンプルの概要

Summit ADF DVTサンプル・アプリケーションの各スタンドアロン・ページはSummit ADFスキーマを使用してデータバインドされたOracle ADFデータ視覚化コンポーネントの作成と構成を示します。

図2-22はSummitADF_DVTアプリケーション・ワークスペースを開いた後の「アプリケーション」ウィンドウを示しています。

図2-22 Summit ADF DVTアプリケーション・ワークスペース内の実行可能ページ

表2-7にSummitADF_DVTアプリケーション・ワークスペース内のスタンドアロン・ページを示します。各ページはそれ自身で実行可能です。

表2-7 Summit ADF DVTアプリケーション・ワークスペース内のスタンドアロン・ページ

ページ名

ページの説明

ドキュメント

bubbleChartDemo.jsf

データ・コントロールからのDVTバブル・チャートの作成を示します。

データバインドされたバブル・チャートと散布図の作成方法

comboChartDemo,jsf

データ・コントロールからのDVT複合チャートの作成を示します。

データ・コントロールを使用して面チャート、棒グラフ、複合チャート、横棒グラフまたは折れ線グラフを作成する方法

gaugeDemo.jsf

データ・コントロールからのDVTダイアル・ゲージの作成を示します。

データバインドされたゲージの作成

gaugeInTableDemo.jsf

列のいずれかにステータス・メーター・ゲージがスタンプされたデータバインドされたADF表の作成を示します。

データバインドされたADF表へのゲージの組込み

hvDemo.jsf

Summit従業員の組織図をレンダリングするデータバインドされた階層ビューアの作成を示す。

ADFデータ・コントロールを使用して階層ビューアを作成する方法

hvPanelCardVODemo.jsf

パネル・カードのいずれかの代替ビュー・オブジェクトを使用したデータバインドされた階層ビューアの作成を示す。

データバインドされたパネル・カード用に代替ビュー・オブジェクトを構成する方法

hvSearchDemo.jsf

階層ビューアの検索構成を示します。

階層ビューアでのデータバインドされた検索の作成方法

pivotTableBarDemo.jsf

データ・コントロールを使用したピボット・テーブルおよびピボット・フィルタ・バーの作成を示します。

ADFデータ・コントロールを使用したピボット・テーブルの作成方法

projectGanttDemo.jsf

データ・コントロールを使用したプロジェクト・ガント・チャートの作成を示します。

データバインドされたプロジェクト・ガント・チャートの作成方法

RUGGanttDemo.jsf

データ・コントロールを使用したリソース使用率ガント・チャートの作成を示します。

データバインドされたリソース使用率ガント・チャートの作成方法

scatterChartDemo.jsf

データ・コントロールからのDVT散布図の作成を示します。

データバインドされたバブル・チャートと散布図の作成方法

schedGanttDemo.jsf

データ・コントロールを使用したスケジュール・ガント・チャートの作成を示します。

データバインドされたスケジュール・ガント・チャートの作成方法

sunburstDemo.jsf

データ・コントロールを使用したサンバーストの作成を示します。

ADFデータ・コントロールを使用したツリーマップおよびサンバーストの作成方法

thematicMapDemo.jsf

データ・コントロールを使用したテーマ・マップの作成を示します。

ADFデータ・コントロールを使用してテーマ・マップを作成する方法

timelineDemo.jsf

データ・コントロールを使用した時系列コンポーネントの作成を示します。

ADFデータ・コントロールを使用した時系列の作成方法

treemapDemo.jsf

データ・コントロールを使用したツリーマップの作成を示します。

ADFデータ・コントロールを使用したツリーマップおよびサンバーストの作成方法

2.6.2 Summit ADF DVTサンプル・アプリケーション・ページの実行方法

Summit ADF DVTサンプル・アプリケーションJSFページを実行するには、アプリケーションを開き、View Controllerプロジェクトを開いてsample.jsfファイルのいずれかを実行します。

始める前に:

Summit ADF DVTサンプル・アプリケーションが使用しているスキーマについて理解しておくと役立つ場合があります。詳細は、「Summit ADFスキーマのインストール時の処理」を参照してください。

次のタスクを完了する必要があります。

- Oracle JDeveloper Studioをインストールし、インストールの前提条件を満たします。Oracle ADF DVTサンプル・アプリケーションには、既存のOracleデータベースが必要です。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFアーカイブ・ファイルをOracle Technology Networkからローカル・ディレクトリにダウンロードし、ADF DVT用のSummitサンプル・アプリケーションを解凍します。詳細は、「アプリケーション・リソースのダウンロード方法」を参照してください。

- Summit ADFスキーマをインストールします。詳細は、「Summit ADFスキーマのインストール方法」を参照してください。

Summit ADF DVTサンプル・アプリケーション・ページを実行するには:

1. JDeveloperでアプリケーションを開きます。

a. メイン・メニューで「ファイル」→「開く」を選択します。

b. SummitADF_DVTディレクトリのZIPファイルを開いた場所へ移動し、SummitADF_DVT.jwsアプリケーション・ワークスペースを選択して「開く」をクリックします。

2. Summit ADF DVTサンプル・アプリケーションのデータベース接続を作成します。詳細は、「Oracle ADF用Summitサンプル・アプリケーションのデータベース接続の作成方法」を参照してください。

3. 「アプリケーション」ウィンドウで、 ViewControllerおよびWeb Contentノードを開きます。
図2-22はSummit ADF DVTサンプル・アプリケーションのSummitADF_DVT.jwsアプリケーション・ワークスペースを開き、View ControllerおよびWeb Contentノードを開いた後の「アプリケーション」ウィンドウを示しています。アプリケーションの各ページの詳細は、表2-7を参照してください。

4. ページを実行するには、対象の.jsfページを右クリックし、「実行」を選択します。
アプリケーションの初回実行時に統合WebLogic Serverで新規ドメインを起動すると「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

第II部 ビジネス・サービスの構築

この部では、Fusion Webアプリケーションのビジネス・コンポーネントを作成するときに開発者が実行できるタスクについて説明します。

第II部は、次の章で構成されます。

- ADFビジネス・コンポーネントのスタート・ガイド

- エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成

- ビュー・オブジェクトを使用したSQL問合せの定義

- マスター/ディテール関連のビュー・オブジェクトの定義

- 多相ビュー・オブジェクトの定義

- ビュー・インスタンスの問合せのテスト

- ビュー・オブジェクトのパフォーマンス・チューニング

- ビュー・オブジェクトのプログラムによる操作

- 検証とビジネス・ルールの宣言的な定義

- プログラムによる検証とビジネス・ルールの実装

- アプリケーション・モジュールによるビジネス・サービスの実装

- アプリケーション・モジュール・ビュー・インスタンスの共有

- アプリケーション・モジュールによるSOAP Webサービスの作成

- アプリケーション・モジュールによるRESTful Webサービスの作成

- ビジネス・コンポーネント機能の拡張

3 ADFビジネス・コンポーネントのスタート・ガイド

この章では、Oracle ADFアプリケーションのADFビジネス・コンポーネントの使用を開始するための手順を説明します。設計時ウィザード、概要エディタおよびADFモデル・テスターなどの主な機能を説明します。また、データ・モデル・プロジェクトでビジネス・コンポーネントを作成するときに従うプロセスの概要を示しています。

この章の内容は次のとおりです。

- ADFビジネス・コンポーネントについて

- ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成

- ビジネス・コンポーネントの作成および編集

- ビジネス・コンポーネントのテスト、リファクタおよび仮想化

- ビジネス・コンポーネントのカスタマイズ

- ビジネス・コンポーネントでのGroovyスクリプト言語の使用

3.1 ADFビジネス・コンポーネントについて

Fusion Webアプリケーションでは、ビジネス・サービス・レイヤーがデータベースへの接続、データの取得、データベース・レコードのロックおよびトランザクションの管理を処理します。ビジネス・サービス・レイヤーの次の3つの単純な例について考えます。

- 新規データの対応する画面への、再問合せなしの表示
ユーザーは、カスタマ管理アプリケーションにログインし、顧客と既存の注文を表示します。次に新しい注文を作成する際に注文する製品の在庫を表示すると、データベースに再問合せする必要なく製品の在庫量が更新されます。

- ビジネス・ドメイン・ロジックによる変更の自動反映
バック・オフィス・アプリケーションによって、発注状況が更新されます。ビジネス・ドメイン・レイヤーのOrdersエンティティ・オブジェクトにカプセル化されたビジネス・ロジックには、発注状況の属性に変更があった場合は常に最新更新日を更新する簡単なルールが含まれています。ユーザー・インタフェースは、ビジネス・ドメイン・レイヤーのロジックが変更された最新更新日を自動的に反映するよう更新されます。

- ADFモデル・レイヤーのバインディングによりビジネス・サービス・メソッドが起動されると、データの再問合せと現在行の設定が実行されます。
ツリー表示で、エンド・ユーザーがツリー内のあるノードをクリックします。この操作により、アプリケーション・モジュール内のADFツリー・バインディングでビジネス・サービス・メソッドが宣言的に起動され、マスター/ディテール情報の再問合せが実行され、行セットの適切な行に現在行を設定します。画面は新規マスター/ディテール・データと現在行の表示を反映するよう更新されます。

JDeveloperでの設計時に一般的な開発タスクを全体的に宣言的にするため、開発者はADFビジネス・コンポーネントを使用してビジネス・サービスを構築する時間を節約できます。特に、JDeveloperではADFビジネス・コンポーネントによる宣言的開発をサポートし、次のタスクを行います。

- 自動的にデータベースと統合するコンポーネント内のビジネス・ロジックの、記述およびテスト

- 複数のアプリケーションタスクをサポートする、データの複数のSQLベースのビューを介したビジネス・ロジックの再使用

- ブラウザ、デスクトップ、モバイル、Webサービス・クライアントからの、ビューへのアクセスおよび更新

- 配布したアプリケーションの修正を必要としないレイヤー単位のアプリケーション機能のカスタマイズ

ADFビジネス・コンポーネントは、次のビジネス・コンポーネントと連携してビジネス・サービス・レイヤーをサポートします。

- エンティティ・オブジェクト
エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのデータ操作言語(DML)操作を処理することでデータ変更を簡略化します。また、該当する行のビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。

- ビュー・オブジェクト
ビュー・オブジェクトは、SQL問合せを表します。使い慣れたSQL言語を十分に活用し、エンド・ユーザーのタスクが必要とする形に、データを正確に結合、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のビュー・オブジェクトにリンクし、複雑度にかかわらずマスター/ディテール階層を作成する機能も含まれます。エンド・ユーザーがユーザー・インタフェースを使用してデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。

- アプリケーション・モジュール
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。

図3-1は、ADFビジネス・コンポーネントのすべてのコンポーネントとそれらの関係を示しています。

図3-1 ADFビジネス・コンポーネントの概要

3.1.1 ADFビジネス・コンポーネントのユースケースと例

ADFビジネス・コンポーネントは、次の例で示される機能をビジネス・サービス・レイヤーによって活用できる、Javaクラスの基盤を提供します。

データ・アクセスの簡略化

- 必要なデータのみをクライアントに表示するデータ・モデルの設計

- データ・モデルの一部としての複雑なマスター/ディテール階層の組込み

- コード記述を必要としない、エンド・ユーザーのQuery-By-Exampleデータ・フィルタの実装

- ビジネス・サービス・レイヤーとのデータ・モデル変更の自動調整

- データベースに対する変更の自動検証および保存

ビジネス・ドメインの検証およびビジネス・ロジックの実行

- 必須フィールド、主キーの一意性、データの精度と規模および外部キー参照の宣言的な実行

- マルチレベルでの検証サポートを含めた、プログラムまたは宣言による、簡単なビジネス・ルールと高度なビジネス・ルール両方の簡単な取得および実行

- ビジネス・ドメイン・オブジェクト間の関係のナビゲートおよび複合コンポーネント関連の制約の実行

複数ページの作業ユニットとのユーザー・インタフェースのサポート

- ビジネス・サービス・アプリケーション・ロジックによるユーザー・インタフェースにおける変更の自動反映

- 関連する表からの参照情報の取得と、エンド・ユーザーによる外部キー値の変更時の自動保持

- Web階層の自動的な状態管理による、複数ステップのWebベース・ビジネス・トランザクションの簡略化

- コードを必要としない、イメージ、ビデオ、音声およびドキュメントの処理

- データの複数ビューにおける、保留中のデータ変更の同期化

- 複数アプリケーションにおける、プロンプト、ツールチップ、フォーマット・マスク、エラー・メッセージの一環した適用

- メタデータ駆動型ユーザー・インタフェースまたはアプリケーション機能をサポートする、ビジネス・コンポーネントに対するカスタム・メタデータの定義

- 行単位の状態管理を簡略化する動的属性の、実行時の追加

サービス指向アーキテクチャの実装

- コードを記述せずにビジネス統合できる高機能Webサービス・インタフェースのサポート

- ベスト・プラクティスであるインタフェース・ベースのプログラミング・スタイルの適用

- 自動JAAS統合および監査メンテナンスによるアプリケーション・セキュリティの簡略化

- 「一度記述すれば、どこでも実行可能」: プレーンなJavaクラスまたはWebサービスと同様のビジネス・サービスの使用

アプリケーションのカスタマイズのサポート

- ソース・コードの変更を必要としない、提供後のコンポーネント機能の拡張

- アプリケーションの修正を必要としない、提供済コンポーネントの拡張版へのグローバルな代替

- カスタマイズが失われない、または下方カスタマイズの手動での再適用を必要としない、アプリケーション・アップグレードの提供

3.1.2 ADFビジネス・コンポーネントの追加機能

ADFビジネス・コンポーネントを使用する前に、関連するOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- ADFビジネス・コンポーネントによって実装されるJava EEデザイン・パターンの詳細は、「ADFビジネス・コンポーネントJava EEデザイン・パターン・カタログ」を参照してください。

- ADFビジネス・コンポーネントのインタフェースとクラスのメソッド・コールの詳細は、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

- Oracle ADFで実装される一般的なOracle Formsタスクの詳細は、「Oracle ADFでの一般的なOracle Formsのタスクの実行」を参照してください。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

3.2 ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成

JDeveloperは、ADFビジネス・コンポーネントに対する包括的な設計時サポートを提供します。これらの機能では、ビジネス・コンポーネントの作成、編集、ダイアグラム表示、テストおよびリファクタを一括して実行できます。

3.2.1 ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成方法

JDeveloperは、Oracle ADFにデータバインドされたWebアプリケーションの作成に役立つアプリケーション・テンプレートを提供しています。ADF Fusion Webアプリケーション・テンプレートを使用する場合、アプリケーションはデータ・モデル用の1つのプロジェクト(ADFビジネス・コンポーネント)とビューおよびコントローラ・コンポーネント用の別のプロジェクト(ADF FacesおよびADFタスク・フロー)から構成されます。

始める前に:

Fusion Webアプリケーションを理解しておくと役立つ場合があります。詳細は、「Oracle ADFを使用したFusion Webアプリケーションの構築の概要」を参照してください。

また、データ・モデル・プロジェクトでグローバルに指定できるADFビジネス・コンポーネント・プリファレンスを理解するうえで役立つこともあります。詳細は、「ADFビジネス・コンポーネント・プリファレンスのカスタマイズ方法」を参照してください。

また、アプリケーションを作成および管理するためにJDeveloperが提供するツールおよび機能について理解を深めるうえでも役立つことがあります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Oracle JDeveloperによるアプリケーション開発のスタート・ガイド」を参照してください。

ADF Fusion Webアプリケーション・テンプレートを使用してデータ・モデル・プロジェクトを作成するには:

1. メイン・メニューで「ファイル」を選択し、次に「アプリケーション」→「新規」を選択します。

2. 「新規ギャラリ」の「アイテム」リストで、「ADF Fusion Webアプリケーション」をダブルクリックします。

3. ADF Fusion Webアプリケーションの作成・ウィザードで、名前やディレクトリなどのアプリケーションの詳細を入力します。ウィザードに関するヘルプを表示するには、[F1]を押します。

ウィザードのプロジェクト1名前ページに、データ・モデル・プロジェクトを完了するために必要な機能のリストが表示されます。プロジェクト機能「ADFビジネス・コンポーネント」がリストに表示されます。

4. 「終了」をクリックします。

3.2.2 既存のアプリケーションへのADFビジネス・コンポーネント・データ・モデル・プロジェクトの追加方法

事前定義されたテクノロジ・テンプレートを使用せずに作成するアプリケーションは、「新規ギャラリ」からプロジェクト・フォルダに追加することで作成できます。ADFビジネス・コンポーネントのプロジェクトを追加する場合は、「新規ギャラリ」のリストから「ADFモデル・プロジェクト」を選択します。これにより、ADFビジネス・コンポーネントに依存するADF Webアプリケーションのデータ・モデルを定義するプロジェクトが作成されます。

始める前に:

Fusion Webアプリケーションを理解しておくと役立つ場合があります。詳細は、「Oracle ADFを使用したFusion Webアプリケーションの構築の概要」を参照してください。

また、アプリケーションを作成および管理するためにJDeveloperが提供するツールおよび機能について理解を深めるうえでも役立つことがあります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Oracle JDeveloperによるアプリケーション開発のスタート・ガイド」を参照してください。

データ・モデル・プロジェクトをアプリケーションに追加する手順:

1. 「アプリケーション」ウィンドウで既存のプロジェクトを選択し、メインメニューで「ファイル」、次に「新規」→「プロジェクト」を選択します。

2. 「新規ギャラリ」の「アイテム」リストで、「ADFモデル・プロジェクト」をダブルクリックします。

3. 「ADFモデル・プロジェクトの作成」ウィザードで、名前やディレクトリなどのプロジェクトの詳細を入力します。ウィザードに関するヘルプを表示するには、[F1]を押します。

ウィザードのプロジェクト名ページに、モデル・プロジェクトを完了するために必要な機能のリストが表示されます。プロジェクト機能「ADFビジネス・コンポーネント」がリストに表示されます。

4. 「終了」をクリックします。

3.2.3 データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法

初めてADFビジネス・コンポーネント・モデル・プロジェクトでビジネスコンポーネントを作成する場合は、図3-2に示すように、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示されます。このダイアログでは、このデータ・モデル・プロジェクトのビジネス・コンポーネントで作業する際に使用する、設計時のアプリケーション・リソース接続を選択したり、既存のIDEレベルの接続をコピーして新規のアプリケーション・リソース接続を作成します。ビジネス・コンポーネントを作成するためにJDeveloperが使用するデータベースをオンラインにするかオフラインにするかを指定できます。ダイアログではデフォルトでオンライン・データベースに指定されています。オフライン・データベースでの作業の詳細は、「オフライン・データベース・オブジェクトで作業するためのデータ・モデル・プロジェクトの変更方法」を参照してください。

図3-2 「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログ

このダイアログは最初のビジネス・コンポーネントを作成する前に表示されるため、これを使用して、ビュー・オブジェクトがSQL文を策定するために使用するSQLプラットフォームをグローバルに制御します。選択できるSQLプラットフォームは次のとおりです。

- Oracleデータベース接続用のOracle SQLプラットフォーム(デフォルト)

- Oracle Liteデータベース用のOLite

- Microsoft SQL Serverデータベース用のSQLServer

- IBM DB2データベース用のDB2

- その他のサポートされるSQL92準拠のデータベース用のSQL92

注意:

OracleデータベースとOracle以外のデータベースの両方に対してアプリケーションを実行する予定がある場合、後ではなくアプリケーションを構築し始める際に、SQL92 SQLプラットフォームを選択する必要があります。これにより、Oracle SQLプラットフォームを使用する場合に特有の、Oracle固有の最適化機能の一部は使用できなくなりますが、OracleデータベースとOracle以外のデータベースの両方に適用できるアプリケーションを構築できます。

このダイアログでは、データ・モデル・プロジェクトで使用するデータ型のセットも決定できます。JDeveloperはデータ型の選択を使用して、データ・モデル・プロジェクト内でエンティティ・オブジェクトおよびビュー・オブジェクトを作成する際に使用される属性のデータ型を定義します。したがって、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで設定を保存する前に適切な選択を行うことが重要です。このダイアログには、次のオプションがあります。

- JDeveloperによりOracleデータベース・ドライバを使用していることが検出されると、「Oracle用拡張Java」型マップがデフォルトで選択されます。「Oracle用拡張Java」型マップでは、一般的なデータ型として、標準Java型およびoracle.jbo.domainパッケージに含まれる最適化されたデータ型を使用します。

ヒント:

新しいFusion Webアプリケーションでは、デフォルトの「Oracle用拡張Java」型を使用する必要があります。

- 「Java」型マップは、Oracle以外のデータベース上で実行され、SQL92準拠を使用して作成するアプリケーションをサポートするために提供されています。この場合、基本のJavaデータ型のみをグローバルに使用するように、データ型マップを「Java」に設定します。

- 「数値の表示に関する必知事項」で説明されているように、下位互換性を保つためや、ADF Facesをビュー・レイヤー・テクノロジとして使用していないADFアプリケーションのために、「Oracleドメイン」型マップが用意されています。JDeveloperリリース11.1.1.4.0以前で開発されたアプリケーションを移行する際、アプリケーションでは引き続き「Oracleドメイン」型マップが使用され、現在のデフォルト型マップの「Oracle用拡張Java」に変更されません。

「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログでプロジェクトの選択を保存すると、プロジェクトは初期化されたものとみなされます。初期化されたプロジェクトのデータ・タイプ・マップは変更できず、ビジネス・コンポーネントが作成された後にSQLプラットフォームを変更することはお薦めしません。

始める前に:

JDeveloperのリソースとしてのデータベース接続について理解しておくと役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「データベースへの接続と作業」を参照してください。

次のタスクを完了する必要があります。

- 「ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成方法」の説明に従い、ADFビジネス・コンポーネントのデータ・モデル・プロジェクトを作成します。

- 作成するビジネス・コンポーネントのデータ・ソースとして使用するデータベース用の接続の資格証明を取得します。

データ・モデル・プロジェクトを初期化するには:

1. 「アプリケーション」ウィンドウで、ビジネス・コンポーネントを作成するモデル・プロジェクトを右クリックし、「新規」→「表からのビジネス・コンポーネント」を選択します。

他のADFビジネス・コンポーネント・オプションを選択することもできますが、表からビジネス・コンポーネントを作成するオプションは、必要だと予測されるビジネス・コンポーネントの最初のパスを生成する際に特に役立ちます。ポップアップ・メニューにADFビジネス・コンポーネント・オプションが表示されない場合は、ADFビジネス・コンポーネント用に作成されたモデル・プロジェクトが「アプリケーション」ウィンドウで選択済として表示されているか確認します。

2. 「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、「オンライン・データベース」は選択したままにし、ドロップダウン・リストから既存のデータベース・リソースを選択するか、「新規データベース接続を作成します。」アイコンをクリックします。

データベース接続を作成する場合は、「データベース接続の作成」ダイアログに接続情報を入力します。このダイアログでヘルプを参照するには、[F1]を押します。「オフライン・データベース・オブジェクトで作業するためのデータ・モデル・プロジェクトの変更方法」で説明されているとおり、いつでもオフライン・データベース・オブジェクトで作業を開始できます。

3. ビジネス・コンポーネントが使用するSQLプラットフォームを選択します。

データ・モデル・プロジェクトの初回初期化時のにこのダイアログでSQLプラットフォームを選択できます。プロジェクトを初期化したら、adf-config.xmlファイルに対する概要エディタの「ビジネス・コンポーネント」ページでSQLプラットフォームをオーバーライドできますが、これはプロジェクトにビジネス・コンポーネントを追加する前に行う必要があります。このファイルは、「アプリケーション・リソース」パネルで「ディスクリプタ」→「ADF META-INF」ノードを開くと見つかります。adf-config.xmlファイルでデータ型を指定することにより、デプロイ済のFusion Webアプリケーションの実際のデータベース型を必要とするSQL文を実行時に生成することがサポートされます。

4. ビジネス・コンポーネントが使用するデータ・タイプ・マップを選択します。ADFビジネス・コンポーネントのデータ・モデル・プロジェクトを初期化した後はデータ・タイプ・マップを変更できない点に注意してください。

Oracleデータベースに対して実行中のアプリケーションの場合は、通常、可能な場合は常に標準Javaタイプを使用し、番号や日付などの共通のデータ・タイプ用にカスタムOracleドメイン・タイプを提供するデフォルトの「Oracle用拡張Java」を受け入れることができます。その他のサポートされているデータ・タイプ・マップには「Oracleドメイン」(後方互換性用に提供される)と「Java」(Oracle以外のデータベース上で実行するSQL92互換のアプリケーションとともに使用する場合に選択)があります。

5. 「OK」をクリックします。

3.2.4 オフライン・データベース・オブジェクトで作業するためのデータ・モデル・プロジェクトの変更方法

ADFビジネス・コンポーネントはデータベース・オブジェクト・プロバイダとしてのオフライン・データベースの使用をサポートしています。データ・モデル・プロジェクトを初期化してデータベースを指定した後、オフライン・モードのデータベースでの作業に切り替えることができます。モデル・プロジェクトでビジネス・コンポーネントを作成するためのオフライン・データベースでの作業では、接続されていない状態で作業し、準備が整った時点でデータベースへの変更を取得します。また、ビジネス・オブジェクトを強制的に変更するスキーマの変更からプロジェクトを分離したままにします。

オフライン・データベースの作成時または既存のオフライン・データベースの選択時には、引き続きオンライン接続が必要で、これはテスト用に使用されます (Oracle ADFモデル・テスターを使用)およびデプロイメント用に使用されます。設計時は、オフライン・データベースが使用されます。ソース・データベースと同期化するためにオフライン・データベースを更新することもできます。データベース・オブジェクト比較機能によって、各相違を受容または拒否するために使用できるビジュアル・マッピングを取得できます。

始める前に:

JDeveloperのオフライン・データベースについて理解しておくと役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「データベースへの接続と作業」を参照してください。

次のタスクを完了する必要があります。

- 「ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成方法」の説明に従い、ADFビジネス・コンポーネントのデータ・モデル・プロジェクトを作成します。

- 「データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法」の説明に従い、ビジネス・コンポーネントのテスト時に使用するデータベース接続を作成します。

オフライン・データベース・オブジェクトで作業するためにデータ・モデル・プロジェクトを変更するには:

1. 「アプリケーション」ウィンドウで、オフライン・データベースを作成するデータ・モデル・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで「ADFビジネス・コンポーネント」を選択します。

3. 「ADFビジネス・コンポーネント」ページで、「オフライン・データベース」を選択し、新規オフライン・データベースの作成アイコンをクリックします。

4. 「オフライン・データベースの作成」ダイアログで、データ・モデル・プロジェクトが表示するデータベースとスキーマの名前を入力し、その他のオプションを選択してダイアログを完成させ、「OK」をクリックします。
データ・モデル・プロジェクトは新しい「オフライン・データベース・ソース」フォルダで更新され、オフライン・データベースの名前の付いた空のフォルダが含まれます。

5. 「接続」リストで、データ・モデル・プロジェクトのビジネス・コンポーネントをテストするときに接続するオンライン・データベースを選択します。
選択するオンライン・データベースとオフライン・データベースは、データベース・オブジェクト名を確保しテストを有効化するため、同じスキーマを保持している必要があります。ビジネス・コンポーネントのテストの詳細は、「Oracle ADFモデル・テスターの使用方法」を参照してください。

6. 「OK」をクリックします。

データ・モデル・プロジェクトでオフライン・データベース定義を作成するには:

1. 「アプリケーション」ウィンドウで、オフライン・データベースを作成するフォルダを右クリックし、「新規」→「ソース・データベースからのオフライン・データベース・オブジェクト」を選択します。

2. データベース・オブジェクトのリバース・エンジニアリング・ウィザードの「データベース」ページで、オンライン・データベース接続が「ソース・データベース」として表示されていることを確認し、「次へ」をクリックします。

3. 「オブジェクトの選択」ページで、「問合せ」をクリックして「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。

4. 「終了」をクリックします。

3.2.5 アプリケーション・サーバーまたはデータベース依存性に関する必知事項

ADFビジネス・コンポーネントを使用して構築されたアプリケーションは、OracleがADFアプリケーション対応として動作保証している任意のアプリケーション・サーバー(Oracle WebLogic ServerやGlassFishなど)にデプロイし、実行できます。ビジネス・コンポーネントは、プレーンなJavaクラスとXMLファイルを使用して実装されているため、Java仮装マシンが存在するすべての実行環境で使用可能です。つまり、ADFビジネス・コンポーネントを使用して構築されたサービスは、実行時にアプリケーションのコンテナと呼ばれるJava EEサーバーの内部と、サーバーの外部の両方で簡単に使用できます。ADFアプリケーションのデプロイとサポートされているアプリケーション・サーバーの詳細は、「Fusion Webアプリケーションのデプロイ」を参照してください。

顧客は、コマンド行のバッチ・プログラム、Webサービス、カスタム・サーブレット、JSPページなどの様々な構成でアプリケーション・モジュールを日常的に使用します。

「データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法」で説明されているように、Oracle以外のデータベースと連携するアプリケーションを構築することもできます。ただし、Oracleデータベースを対象とするアプリケーションでは、ADF Business Componentsに対して様々な最適化が構築されています。

3.2.6 ADFビジネス・コンポーネントのデータ型に関する必知事項

ADFビジネス・コンポーネントは、文字列、日付、数値データを含めJava言語が提供する組込みのデータ型と互換性があります。これらのJavaデータ型に加え、ADFビジネス・コンポーネントのoracle.jbo.domainパッケージはOracleデータベースに最適化された型を提供しています。表3-2はJava言語が提供する組込みの型以外に使用できるADFビジネス・コンポーネント固有の型を示しています。

表3-1 oracle.jbo.domainパッケージでの基本データ型

データ型

パッケージ

説明

DBSequence

oracle.jbo.domain

データベース・トリガーにより割り当てられた、連続した整数

RowID

oracle.jbo.domain

OracleデータベースのROWID

BFileDomain

oracle.jbo.domain

バイナリ・ファイル(BFILE)オブジェクト

BlobDomain

oracle.jbo.domain

バイナリ・ラージ・オブジェクト(Binary Large Object: BLOB)

ClobDomain

oracle.jbo.domain

キャラクタ・ラージ・オブジェクト(CLOB)

Struct

oracle.jbo.domain

ユーザー定義オブジェクト型

Array

oracle.jbo.domain

ユーザー定義コレクション・タイプ(例: VARRAY)

後方互換性のために、ADFビジネス・コンポーネントは引き続き、Javaの型が標準になる前に使用可能だったoracle.jbo.domainパッケージの一連のデータ型を選択するためのオプションを提供しています。表3-2は、後方互換性が必要な場合に使用できる型を示しています。

表3-2 oracle.jbo.domainパッケージの後方互換可能なデータ型

データ型

パッケージ

説明

Number(デフォルトで使用されません)

oracle.jbo.domain

すべての数値データ。「Numberは抽象クラスです」に関係するコンパイラ・エラーまたは実行時エラーが発生した場合は、oracle.jbo.domain.Numberではなくjava.lang.Numberを使用していることを示しています。クラスの先頭のpackage行の後に次の行を追加すると、この種類のエラーを防止できます。

import oracle.jbo.domain.Number;

Date

oracle.jbo.domain

日付および(オプションの)時間

Timestamp

oracle.jbo.domain

タイムスタンプ値

TimestampTZ

oracle.jbo.domain

タイムスタンプ値およびタイム・ゾーン情報

TimestampLTZ

oracle.jbo.domain

JavaVMまたはADF Context(アプリケーションのadf-config.xmlでEL式を使用して構成されている場合)から取得したタイムゾーン値およびローカルのタイム・ゾーン情報:

<user-time-zone-config xmlns=
"http://xmlns.oracle.com/adf/usertimezone/config">
<user-timezone expression= "EL exp" />
</user-time-zone-config>

このEL式が評価されて現在のエンド・ユーザーのタイム・ゾーンが決定されるか、この値はJavaVMのタイム・ゾーンにデフォルト設定されます。

3.2.7 数値の表示に関する必知事項

「Oracle用拡張Java」型マップと「Oracleドメイン」型マップとでは、数値データの処理が異なります。新しいアプリケーションを作成する際、デフォルト型マップの「Oracle用拡張Java」により数値データをjava.math.BigDecimalクラスにマップし、java.math.Numberから継承します。java.math.BigDecimalのデフォルト値は、Fusion Webアプリケーションのビュー・レイヤーの方法に一致し、ADF Facesコンポーネントで構成されますが、数値データ(WebページでADF Faces入力フィールドにより表示される数値など)の位置合せが維持されます。「Oracleドメイン」型マップでは数値データをoracle.jbo.domain.Numberクラスにマップしますが、ADF Facesコンポーネントで期待される位置合せでデータは表示されない場合があります。この位置合せ問題とは別にして、「Oracleドメイン」型マップは有効な選択肢であり、ADF Facesコンポーネントのないアプリケーションは問題なく機能します。

3.2.8 ADFビジネス・コンポーネントのモデル・プロジェクト・プロパティのカスタマイズ方法

ビジネス・コンポーネントの作成を開始する前に、ADFビジネス・コンポーネントを構成するために使用できる多数のプロジェクト・プロパティについて理解を深めておくことをお薦めします。「プロジェクト・プロパティ」ダイアログで行った選択は、編集中のデータ・モデル・プロジェクトに適用されます。データ・モデル・プロジェクト用に生成したビジネス・コンポーネントやサブパッケージの名前の接尾辞命名規則をはじめ様々なプロパティを指定できます。

始める前に:

JDeveloperのプロジェクトの管理について理解しておくと役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Oracle JDeveloperによるアプリケーション開発のスタート・ガイド」を参照してください。

また、データ・モデル・プロジェクトでグローバルに指定できるプリファレンスを理解するうえで役立つこともあります。詳細は、「ADFビジネス・コンポーネント・プリファレンスのカスタマイズ方法」を参照してください。

次のタスクを完了する必要があります。

- 「ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成方法」の説明に従い、ADFビジネス・コンポーネントのデータ・モデル・プロジェクトを作成します。

データ・モデル・プロジェクト・プロパティをカスタマイズするには:

1. 「アプリケーション」ウィンドウで、共有アプリケーション・モジュールを作成するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで「ADFビジネス・コンポーネント」を開き、ツリー内で目的のノードを選択します。ダイアログのどのページでもヘルプを参照するには、[F1]を押します。

3.2.9 ADFビジネス・コンポーネント・プリファレンスのカスタマイズ方法

ADFビジネス・コンポーネント用に構成される設計時および実行時の多数のオプションがJDeveloperプリファレンス・レベルで指定されます。ADFビジネス・コンポーネントのこれらのプリファレンスについて理解を深めておくことをお薦めします。「プリファレンス」ダイアログで行った選択は、作成する各データ・モデル・プロジェクトに適用されます。

「ADFビジネス・コンポーネントのモデル・プロジェクト・プロパティのカスタマイズ方法」で説明されているとおり、グローバルに指定した特定のプリファレンスは個々のデータ・モデル・プロジェクトでオーバーライドできます。

始める前に:

また、個々のデータ・モデル・プロジェクトに指定できるプリファレンスを理解するうえで役立つこともあります。詳細は、「ADFビジネス・コンポーネントのモデル・プロジェクト・プロパティのカスタマイズ方法」を参照してください。

次のタスクを完了する必要があります。

- 「ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成方法」の説明に従い、ADFビジネス・コンポーネントのデータ・モデル・プロジェクトを作成します。

ADFビジネス・コンポーネント・プリファレンスをカスタマイズするには:

1. JDeveloperで、「ツール」→「プリファレンス」の順に選択します。

2. 「プリファレンス」ダイアログで「ADFビジネス・コンポーネント」を開き、ツリー内で目的のノードを選択します。ダイアログのどのページでもヘルプを参照するには、[F1]を押します。

3.3 ビジネス・コンポーネントの作成および編集

JDeveloperにはデータ・モデル・プロジェクトのビジネス・コンポーネントを作成およびカスタマイズするための包括的な設計時サポートが含まれています。これらの機能によって、専用ウィザードを使用したコンポーネントの作成、概要エディタでのプロパティの変更およびソース・エディタでの定義ファイルの表示を実行できます。

3.3.1 ウィザードを使用した新規コンポーネントの作成方法

「新規ギャラリ」の「ADFビジネス・コンポーネント」カテゴリでは、JDeveloperはそれぞれのビジネス・コンポーネントを作成するためのウィザードを提供しています。各ウィザードでは、新規コンポーネントのコンポーネント名を指定し、どのパッケージにコンポーネントを配置するかを選択できます。パッケージがまだ存在しない場合、新規コンポーネントがそのパッケージの最初のコンポーネントになります。

各ウィザードには、コンポーネント・タイプを作成するために必要な情報を収集する、一連のページが表示されます。「終了」をクリックすると、XMLドキュメント・ファイルが保存され、新規コンポーネントが作成されます。さらに、Javaクラス・ファイルを生成するために「プロジェクト・プロパティ」ダイアログの「ADFビジネス・コンポーネント」→「オプション」ページでデフォルトの「コード生成」オプションを変更すると、JDeveloperではXMLドキュメント・ファイルに加え初期カスタムJavaクラス・ファイルも作成できます。

表からのビジネス・コンポーネントの作成ウィザードは、様々なビジネス・コンポーネント・タイプの生成を単一のエンドツーエンドのプロセスに組み合せた唯一のウィザードであるため、JDeveloperで特に役立ちます。このウィザードを使用すると、多数のビジネス・コンポーネントを迅速かつ容易に作成できます。オンラインまたはオフラインのデータベースに基づいてエンティティ・オブジェクトを作成し、その後、エンティティ・ベースのビュー・オブジェクトまたは問合せベースのビュー・オブジェクトのいずれかとデータ・モデルのビュー・インスタンスを含むアプリケーション・モジュールを作成できます。最後に、ウィザードは連携しているビジネス・コンポーネント間の関係を表示するためのビジネス・コンポーネント・ダイアグラムを生成するオプションを提供します。

ウィザードを使用した後、作成するビジネス・コンポーネントを編集して、後で新規ビジネス・コンポーネントを追加できます。

始める前に:

様々なADFビジネス・コンポーネントを理解しておくと役立つ場合があります。詳細は、「ADFビジネス・コンポーネントについて」を参照してください。

次のタスクを完了する必要があります。

- 「ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成方法」の説明に従い、ビジネス・コンポーネントを含むデータ・モデル・プロジェクトを作成します。

連携するビジネス・コンポーネントを1回で作成するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「表からのビジネス・コンポーネント」を選択し、「OK」をクリックします。

これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。「データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法」の説明に従い、ダイアログを完了します。

3. 表からのビジネス・コンポーネントの作成ウィザードの「エンティティ・オブジェクト」ページで、使用可能なデータベース・オブジェクトを表示するためのデータベース・スキーマをフィルタリングし、エンティティ・オブジェクトを作成するデータベース・オブジェクトを選択します。「次へ」をクリックします。

デフォルトのパッケージ名を変更する場合は、パッケージ名にrestなどの予約語を使用しないでください。パッケージの命名の詳細は、「パッケージの命名規則に関する必知事項」を参照してください。

4. 「エンティティ・ベースのビュー・オブジェクト」ページで、エンティティ・オブジェクト定義の更新可能なビュー・オブジェクト定義を作成するための使用可能なエンティティ・オブジェクトを選択します。「次へ」をクリックします。

このウィザードで作成するビュー・オブジェクト定義には、エンティティ・オブジェクトの1回の使用が含まれ、そのオブジェクト内のすべての属性を公開する点に注意してください。

5. 「問合せベースのビュー・オブジェクト」ページで、読取り専用のビュー・オブジェクト定義を作成するための使用可能なデータベース・オブジェクトを選択します。「次へ」をクリックします。

6. 「アプリケーション・モジュール」ページで、デフォルト選択は未変更のままにし、「次へ」をクリックします。

7. 「ダイアグラム」ページで、「ビジネス・コンポーネント・ダイアグラムに追加」を選択し、「次へ」をクリックします。

8. 「サマリー」ページで、ウィザードによって作成されるビジネス・コンポーネントのリストを確認し、「終了」をクリックします。

3.3.2 ポップアップ・メニューを使用した新規コンポーネントの作成方法

「アプリケーション」ウィンドウにパッケージが存在していれば、「アプリケーション」ウィンドウに表示したコンテキスト・メニューからコンポーネントを選択することで、任意のタイプの追加のビジネス・コンポーネントをすばやく作成できます。コンポーネントを追加するには、コンポーネントを配置するデータ・モデル・プロジェクト内のパッケージを右クリックし、「新規」メニューからコンポーネントを選択します。「新規」メニューに表示されるコンポーネントは、選択したプロジェクトのタイプによって異なります。

図3-3に、データ・モデル・プロジェクトでパッケージを右クリックした後で、「アプリケーション」ウィンドウのコンテキスト・メニューに「新規」メニューがどのように表示されるかを示します。コンテキスト・メニューはADFビジネス・コンポーネント・データ・モデル・プロジェクトに表示されるため、使用可能なコンポーネントはADFビジネス・コンポーネントに限定されます。

図3-3 各種ビジネス・コンポーネント作成用のパッケージのポップアップ・メニュー・オプション

「アプリケーション」ウィンドウのポップアップ・メニューには、右クリックするとそのプロジェクトに適したオプションが表示されます。ポップアップ・メニューに「ADFビジネス・コンポーネント」オプションが表示されない場合は、右クリックしたプロジェクトがADFビジネス・コンポーネント・モデル・プロジェクトであることを確認してください。

始める前に:

様々なADFビジネス・コンポーネントを理解しておくと役立つ場合があります。詳細は、「ADFビジネス・コンポーネントについて」を参照してください。

次のタスクを完了する必要があります。

- 「ADFビジネス・コンポーネントのデータ・モデル・プロジェクトの作成方法」の説明に従い、ビジネス・コンポーネントを含むデータ・モデル・プロジェクトを作成します。

個々のビジネス・コンポーネントをデータ・モデル・プロジェクトに追加するには:

1. 「アプリケーション」ウィンドウで、新規ビジネス・コンポーネントを作成するモデル・プロジェクト内のパッケージを右クリックし、「新規」→ビジネス・コンポーネント名を選択します。

2. ビジネス・コンポーネントのウィザードで、ウィザードのページを完了し、「終了」をクリックします。ウィザードのどのページでもヘルプを参照するには、[F1]を押します。

3.3.3 ビジネス・コンポーネント作成時の処理

ADFビジネス・コンポーネントの各コンポーネントには、宣言的な設定によって制御される、組込みランタイム機能が付属しています。これらの設定は、コンポーネントと同じ名前のXMLドキュメント・ファイルに格納されています。

図3-4は、「アプリケーション」ウィンドウにデータ・モデル・プロジェクトの各ビジネス・コンポーネントのXMLドキュメント・ファイルがどのように表示されるかを示しています。「アプリケーション」ウィンドウにXMLドキュメント・ファイルを表示するには、JDeveloperでビジネス・コンポーネントを作成したときに割り当てられた名前のノードを展開します。たとえば、ビュー・オブジェクト・ノードSDeptViewを展開して、関連付けられたXMLドキュメント・ファイルSDeptView.xmlを表示できます。コンポーネントの概要エディタを表示するには、XMLドキュメント・ファイルまたはそのコンポーネント・ノードをダブルクリックします。

図3-4 コンポーネントXMLファイルを表示している「アプリケーション」ウィンドウ

図3-5は、com.yourcompany.yourappパッケージ内で作成した、アプリケーション・モジュールYourServiceなどのアプリケーション固有のコンポーネントに対するXMLドキュメント・ファイルを示しています。対応するXMLドキュメントは、データ・モデル・プロジェクトのソース・パスのルート・ディレクトリ内のサブディレクトリ./com/yourcompany/yourappに保存されます。そのXMLファイルには、実行時にアプリケーション・モジュール実装を提供するJavaクラスの名前が記録されます。この場合、XMLにはOracle ADFが提供するoracle.jbo.server.ApplicationModuleImplベース・クラスの名前が記録されます。

図3-5 アプリケーション・モジュールのXMLドキュメント・ファイル

カスタマイズを行わずに使用した場合、コンポーネントは、XMLドキュメントで完全に定義されており、コンポーネントのカスタムJavaコードやJavaクラス・ファイルをまったく必要とせず、十分な機能を備えています。ADFビジネス・コンポーネントのコンポーネントの組込み機能を拡張する必要がない場合、また、組込みイベントを処理するカスタム・コードを記述する必要がない場合、このXMLのみの方法でコンポーネントを使用できます。

「ビジネス・コンポーネントJavaサブクラスの生成方法」に説明されているとおり、コンポーネントの動作を拡張するなど、コンポーネントのカスタム・コードを記述する必要がある場合、該当するコンポーネントに対するオプションのカスタムJavaクラスを有効にできます。

3.3.4 モデル・プロジェクト組織に関する必知事項

ADFビジネス・コンポーネントはJavaで実装されているため、クラスおよびインタフェースはパッケージ化されています。Javaパッケージは、ピリオドで区切った名前で識別され、開発者は階層型のネーミング構造でコードを整理できます。

ADFビジネス・コンポーネントにより提供されたソース・コードを構成するクラスおよびインタフェースは、oracle.jboパッケージおよび多数のサブパッケージに含まれます。ただし、ADFビジネス・コンポーネントを使用した日常作業においては、主に次の2つの主要パッケージに含まれるクラスやインタフェースを使用します。

- ビジネス・サービス・クライアントの連携のために設計されたすべてのインタフェースが含まれる、oracle.jboパッケージ

- これらのインタフェースを実装するクラスが含まれるoracle.jbo.serverパッケージ

注意:

ここでのクライアントという用語は、ビジネス・サービスとしてアプリケーション・モジュール・コンポーネントにアクセスするモデル・レイヤー、ビュー・レイヤーまたはコントローラ・レイヤー内のコードを意味します。

図3-6に、アプリケーション・モジュール・コンポーネントの具体的な例を示します。アプリケーション・モジュールのためのクライアント・インタフェースは、oracle.jboパッケージの中のApplicationModuleインタフェースです。このインタフェースは、クライアントがアプリケーション・モジュールとの連携に利用可能なメソッドの名前やシグネチャを定義しますが、その機能の実装の仕様は含まれていません。アプリケーション・モジュール・コンポーネントのベースとなる機能を実装するクラスは、oracle.jbo.serverパッケージに含まれているApplicationModuleImplというクラスです。

図3-6 ADFビジネス・コンポーネントによるインタフェースと実装の分離

3.3.5 パッケージの命名規則に関する必知事項

ADFビジネス・コンポーネントはJavaで実装されているため、クラス、インタフェース、およびメタデータ・ファイルなどアプリケーションのコンポーネントもパッケージ化されます。

コンポーネントが他の組織の再使用可能なコンポーネントと競合しないように、パッケージ名の先頭に組織名またはWebドメイン名を付けます。たとえば、Apacheでは、Tomcat Webサーバーと関連付けるためにパッケージ名としてorg.apache.tomcatを指定しており、Oracleでは、XML Parserのパッケージ名としてoracle.xml.parserを指定しています。自社アプリケーション用に作成したコンポーネントは、com.yourcompany.yourappなどの名前でパッケージおよびそのサブパッケージに配置されます。

指定するパッケージ名では、すでにADFビジネス・コンポーネント・プロジェクト内に存在するか、特定のテクノロジの名前を含んでいるオブジェクトの名前(restなど)を参照することはできません。ADFビジネス・コンポーネント・ウィザードでデフォルト・パッケージ名を変更して、予約語を使用しようとしても、アラート・ダイアログが表示され、実行できません。たとえば、restは予約語なので、JDeveloperでパッケージにadf.sample.adfbc.restのような名前を付けることは規則違反です。

具体的な例として、Oracle ADFのSummitサンプル・アプリケーションの主要なビジネス・サービスを構成するビジネス・コンポーネントは、oracle.summit.modelパッケージおよびサブパッケージに配置されています。図3-7に示すように、これらのコンポーネントはSummitADFワークスペースのModelプロジェクトにあり、次のように配置されています。

- oracle.summit.model.diagramにはビジネス・コンポーネント・ダイアグラムが含まれています。

- oracle.summit.model.entitiesには、エンティティ・オブジェクトが含まれています。

- oracle.summit.model.servicesには、SummitAppModuleアプリケーション・モジュールが含まれています。

- oracle.summit.model.viewsには、ビュー・オブジェクトが含まれています。

図3-7 コアSummit ADFサンプル・アプリケーションでのADFビジネス・コンポーネントの配置

自社アプリケーションでは、最適なパッケージ構成を選択できます。具体的には、同じタイプのコンポーネントを1つのパッケージにまとめる必要はありません。

パッケージに最適なコンポーネント数はありません。ただし、最適な構造は二極間(すべてのコンポーネントを1つのパッケージにまとめる構造と各コンポーネントを個々のパッケージに分ける構造)のどこかに収まります。

プロジェクトは、他のデータ・モデル・プロジェクトでの再使用のためにJDeveloperがサポートする最小レベルの単位であることを考慮に入れる必要があります。そのため、コンポーネントをどのように配置するかを考慮する場合もあります。詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。

3.3.6 コンポーネントの名前変更に関する必知事項

JDeveloperは、アプリケーションの発展につれ変更内容を統合するために役立つリファクタ・アクションを通じてコンポーネントのリファクタをサポートしています。JDeveloperを使用してデータ・モデル・プロジェクトのビジネス・コンポーネントをリファクタすると、コンポーネントの名前を変更したり、それらを別のパッケージに移動でき、さらにJDeveloperはリファクタされたコンポーネントへのすべての参照を検出し、更新します。可能な場合は常に、JDeveloperのリファクタ・アクションを使用してエラーを招き易いプロジェクトの手動での編集を回避できます。データ・モデル・プロジェクトのビジネス・コンポーネントのリファクタの用途と制限の詳細は、「Fusion Webアプリケーションのリファクタ」を参照してください。

3.3.7 コンポーネントの概要エディタを使用したコンポーネントの編集方法

ビジネス・コンポーネントが作成された後は、「アプリケーション」ウィンドウでコンポーネントをダブルクリックするか、コンポーネントを選択し、ポップアップ・メニューから「開く」オプションを選択することにより、対応する概要エディタを使用してそのプロパティを編集することができます。

概要エディタには、ウィザードに表示されるのと同じ編集オプションが表示されますが、表示項目の配置が異なる場合があります。概要エディタでは、コンポーネントのすべての特徴を変更できます。コンポーネントのエディタで変更を加えると、コンポーネントのXMLドキュメント・ファイルが更新され、関連するすべてのカスタムJavaファイルが必要に応じて更新されます。概要エディタは、モーダル・ダイアログではなくJDeveloperの編集ウィンドウであるため、必要な数のコンポーネントの概要エディタを開いて表示できます。

始める前に:

プロジェクトを管理するために使用できるツールについて理解しておくと役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Oracle JDeveloperでの作業」を参照してください。

次のタスクを完了する必要があります。

- 「ウィザードを使用した新規コンポーネントの作成方法」の説明に従って、データ・モデル・プロジェクトのビジネス・コンポーネントを作成します。

データ・モデル・プロジェクトのビジネス・コンポーネントのプロパティを編集するには:

1. 「アプリケーション」ウィンドウで、編集するビジネス・コンポーネントを右クリックし、「開く」を選択します。

2. ビジネス・コンポーネントの概要エディタで、ビューの左側にあるナビゲーション・タブをクリックし、関連するプロパティ・グループを編集します。概要エディタのどのページでもヘルプを参照するには、[F1]を押します。

3. 概要エディタで、「ソース」タブをクリックしXML定義ソース内の変更を表示します。

4. 概要エディタで、「履歴」タブをクリックしてリビジョン履歴を表示し、現在の概要エディタで表示されているXMLソースの内容と過去のリビジョンの内容を比較します。

ファイルのバージョン管理の詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「ソース制御によるアプリケーションのバージョン管理」を参照してください。

5. JDeveloperで、「ファイル」→「保存」を選択し、プロパティの変更をビジネス・コンポーネントのXML定義ファイルに保存します。

3.4 ビジネス・コンポーネントのテスト、リファクタおよび仮想化

JDeveloperにはデータ・モデル・プロジェクトで作成するビジネス・コンポーネント数の急増を管理するための包括的な設計時サポートが含まれています。これらの機能では、ビジネス・コンポーネントのテスト、リファクタおよび視覚化を実行できます。

3.4.1 Oracle ADFモデル・テスターの使用方法 /

アプリケーション・モジュール・コンポーネントの作成後は、組込みのOracle ADFモデル・テスターを使用し、繰り返しテストできます。Oracle ADFモデル・テスターを起動するには、「アプリケーション」ウィンドウでアプリケーション・モジュールを選択するか、またはビジネス・コンポーネント・ダイアグラムでポップアップ・メニューから「実行」または「デバッグ」 を選択します。

図3-8 Oracle ADFモデル・テスター

図3-8に示すとおり、Oracle ADFモデル・テスターではアプリケーション・モジュールのデータ・モデルにビュー・オブジェクト・インスタンスを提供し、動的に生成されるユーザー・インタフェースを使用してユーザーとインスタンスとの対話を可能にします。このツールでは、アプリケーション・モジュールのクライアント・インタフェース・メソッドのリストも提供され、アプリケーション・モジュールのノードをダブルクリックすると、対話的にテストできます。このツールは、Webページのビュー・レイヤー作成の前後において、ビジネス・サービスのテストやデバッグに必要不可欠なものです。

始める前に:

データ・モデル・プロジェクトの実行時動作について理解しておくと役立つ場合があります。詳細は、「ビュー・インスタンスの問合せのテスト」を参照してください。

また、ADFビジネス・コンポーネントを含めOracle ADFアプリケーションをテストするために使用できる機能について理解しておくと役立つことがあります。詳細は、「ADFコンポーネントのテストとデバッグ」を参照してください。

次のタスクを完了する必要があります。

- 「ウィザードを使用した新規コンポーネントの作成方法」の説明に従って、データ・モデル・プロジェクトのビジネス・コンポーネントを作成します。

アプリケーション・モジュール構成内のビュー・インスタンスをテストするには:

1. 「アプリケーション」ウィンドウで、テストするアプリケーション・モジュールを右クリックし、「実行」を選択します。

または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は、「デバッグ」を選択します。このオプションの詳細は、「テストとデバッグのためのOracle ADFモデル・テスターの使用」を参照してください。

2. Oracle ADFモデル・テスターでビュー・オブジェクトを実行するには、データ・モデル・ツリーを開き、目的のビュー・オブジェクト・ノードをダブルクリックします。

3. データ・モデル・ツリー内のノードを右クリックして、そのノードのポップアップ・メニューを表示します。たとえば、ビュー・インスタンス・ノードでは、問合せを必要に応じて再実行し、データ・モデル・ツリーからのビュー・インスタンスの削除およびその他のタスクを実行できます。

4. タブのポップアップ・メニューを表示するには、開いているデータ・ビューアのタブを右クリックします。たとえば、データ・ビューアを閉じたり、別のウィンドウで開くことができます。

5. Oracle ADFモデル・テスターのヘルプを表示するには、[F1]を押します。

3.4.2 Oracle ADFソース・コードの取得に関する必知事項

ADFビジネス・コンポーネントはビジネス上非常に重要なアプリケーションにおいて使用されることが多いため、サポート契約を締結しているお客様は、ADFビジネス・コンポーネントを含めてOracle ADFの完全なソースをOracle Worldwide Supportから入手できます。「ADF宣言デバッガの使用」に説明されているように、Oracle ADFの完全なソース・コードは、問題の診断を支援するための重要なツールです。「拡張クラスによるフレームワークの動作のカスタマイズ」に説明されているように、Oracle ADFの完全なソース・コードを使用すると、必要に応じてベース・フレームワーク機能を適切に拡張する方法を理解するためにも役立ちます。

3.4.3 データ・モデル・プロジェクトでのビジネス・コンポーネントの使用方法を検索する方法

オフライン・データベースのデータベース・オブジェクトの名前またはADFビジネス・コンポーネントの名前を変更する前に、選択したアイテムを参照するすべてのオブジェクトを表示できます。「ログ」ウィンドウの「使用方法の検索」ページを使用して、選択したアイテムのデータ・モデル・プロジェクトの使用方法をすべて表示できます。

始める前に:

JDeveloperのリファクタのサポートについて理解しておくと役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Javaコードでの作業」を参照してください。

また、ADFビジネス・コンポーネントのリファクタの制限について理解しておくと役立つことがあります。詳細は、「ADFビジネス・コンポーネント・オブジェクト属性のリファクタ」を参照してください。

次のタスクを完了する必要があります。

- 「ウィザードを使用した新規コンポーネントの作成方法」の説明に従って、データ・モデル・プロジェクトのビジネス・コンポーネントを作成します。

ADFビジネス・コンポーネントによって使用されているアイテムを検索するには:

1. 「アプリケーション」ウィンドウのデータ・モデル・プロジェクト内で、データ・モデル・プロジェクトを開き、使用方法を検索するアイテムを選択します。

データベース・オブジェクトの使用方法を検索するには、「オフライン・データベース・ソース」フォルダを開き、目的のデータベース・オブジェクトを選択します。

2. 項目を右クリックして「使用方法の検索」を選択します。

データベース列の使用方法を検索するには、「構造」ウィンドウを表示し、「構造」ウィンドウ内の列を右クリックします。

3. 「ログ」ウィンドウで、選択したアイテムを参照しているビジネス・コンポーネントを確認します。

「ログ」ウィンドウの「使用方法の検索」ページでは、名前付きアイテムがJDeveloper内のエディタにリンクされます。必要に応じて、リスト内のアイテムをクリックし、JDeveloper内でその詳細を表示します。

3.4.4 データ・モデル・プロジェクトでビジネス・コンポーネントの依存性を探索する方法

依存性エクスプローラでは、展開できるダイアグラムを通じてデータ・モデル・プロジェクト内のアーティファクトの使用関係を視覚化できます。データ・モデル・プロジェクト内のビジネス・コンポーネントの数が増えると、ビジネス・コンポーネントとその他のプロジェクト・アーティファクト間の関係を探索することが必要になる場合があります。ダイアグラムを展開するときに、選択したコンポーネントを参照するアーティファクトと選択したコンポーネントで参照されるアーティファクトを表示できます。このように、依存性エクスプローラは、「使用方法の検索」ログ・ウィンドウで返された使用情報よりも包括的な関係情報を表示します。

ダイアグラムでデータ・モデル・プロジェクトに対して表示されるアーティファクトには、様々なビジネス・コンポーネントXML定義ファイル(ビュー・オブジェクト、エンティティ・オブジェクト、アプリケーション・モジュールなど)、プロジェクト構成ファイル(bc4j.xmlやModel.jpxなど)、リソース・バンドル・ファイル(ModelBundle.propertiesなど)、Java実装ファイル(SummitViewObjectImpl.javaやSummitEntityImpl.javaなど)、ADFビジネス・コンポーネント・フレームワーク・ソース・ファイル(Oracle ADFビジネス・コンポーネントの型クラスなど)が含まれます。

図3-9に、ビュー・オブジェクト用のCountryVO.xmlファイルにフォーカスを置いた依存性エクスプローラを示します。左側のノードにはCountryVOを参照するアーティファクトが表示され、右側のノードはCountryVOによって参照されているアーティファクトです。右クリック・メニューから「開く」を選択して、JDeveloperソース・エディタにこれらのアーティファクトのいずれかを開き、詳細な参照を表示できます。

図3-9 ADFビジネス・コンポーネント・アーティファクトを表示している依存性エクスプローラ

始める前に:

JDeveloperで提供される共通開発ツールに関する知識が役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Oracle JDeveloperでの作業」を参照してください。

次のタスクを完了する必要があります。

- 「ウィザードを使用した新規コンポーネントの作成方法」の説明に従って、データ・モデル・プロジェクトのビジネス・コンポーネントを作成します。

ADFビジネス・コンポーネントとその他のプロジェクト・アーティファクト間の依存性を検証する手順:

1. 「アプリケーション」ウィンドウのデータ・モデル・プロジェクト内で、データ・モデル・プロジェクトを展開し、依存性を検証するビジネス・コンポーネントを選択します。

2. 項目を右クリックして「依存性の参照」を選択します。

3. 依存性エクスプローラで、ダイアグラム・ノードのプラス・アイコンをクリックして、ダイアグラムを展開します。ダイアグラムの左側を展開して、選択したコンポーネントを参照するアーティファクトを表示するか、右側を展開して、コンポーネントにより参照されるアーティファクトを表示します。

選択したコンポーネントの左側のノードを展開すると、アプリケーションでアーティファクトが使用されている場所を確認できます。これらは、コンポーネントで「使用方法の検索」を選択したときに「ログ」ウィンドウの「使用方法の検索」ページに表示されるのと同じ項目です。

4. ダイアグラム・ノードの横のリンク付きの数字をクリックして、参照の詳細リストを表示し、参照をクリックして参照を含むファイルを開きます。

依存性エクスプローラの詳細は、[F1]をクリックします。

3.4.5 データ・モデル・プロジェクトでのビジネス・コンポーネントのリファクタ方法

「アプリケーション」ウィンドウででコンポーネントを選択し、ポップアップ・メニューから「リファクタ」→「名前の変更」を選択すると、いつでもコンポーネントの名前を変更できます。「構造」ウィンドウには、アプリケーション・モジュール・データ・モデルのビュー・オブジェクト属性やビュー・インスタンスなど「アプリケーション」ウィンドウには表示されないコンポーネントの詳細のための「名前の変更」ポップアップ・メニュー・オプションも表示されます。また、「アプリケーション」ウィンドウ内で[Ctrl]キーを押しながらクリックして1つ以上のコンポーネントを選択し、次にポップアップ・メニューから「リファクタ」→「移動」を選択すると、選択したコンポーネントを新規パッケージに移動できます。現在のデータ・モデル・プロジェクト内の古いコンポーネント名やパッケージへの参照は、自動的に修正されます。

始める前に:

JDeveloperのリファクタのサポートについて理解しておくと役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Javaコードでの作業」を参照してください。

また、ADFビジネス・コンポーネントのリファクタの制限について理解しておくと役立つことがあります。詳細は、「ADFビジネス・コンポーネント・オブジェクト属性のリファクタ」を参照してください。

次のタスクを完了する必要があります。

- 「ウィザードを使用した新規コンポーネントの作成方法」の説明に従って、データ・モデル・プロジェクトのビジネス・コンポーネントを作成します。

データ・モデル・プロジェクトでビジネス・コンポーネントをリファクタするには:

1. 「アプリケーション」ウィンドウで、ビジネス・コンポーネントを右クリックして、「リファクタ」→「名前の変更」または「リファクタ」→「移動」を選択します。

2. オブジェクトを削除するには、「削除」を選択します。

オブジェクトがアプリケーションの他の箇所で使用される場合、ダイアログに次のオプションが表示されます。

- 無視: 解決されていない慣用名は、未定義参照としてコードに残ります。

- 使用方法の表示: コンパイラ・ログに、要素の慣用名のプレビューが表示されます。ログを使用して、残りの慣用名を調査および解決することができます。

3.4.6 オフライン・データベース・オブジェクトのリファクタおよびビジネス・コンポーネントの更新方法

データ・モデル・プロジェクトとともにオフライン・データベース・ソースを使用している場合、データベース、個々の表および個々の列の名前を変更できます。JDeveloperは、データ・モデル・プロジェクトのADFビジネス・コンポーネントおよびオフライン・データベース自体とともにこれらのデータベース・オブジェクトのリファクタをサポートしています。加えた変更は、データベース・オブジェクトを参照する定義を持つビジネス・コンポーネントに自動的に適用されます。たとえば、オフライン・データベースでデータベース表の名前を変更した場合、その表を参照するビュー・オブジェクト問合せは新しい名前を使用するように変更されます。

始める前に:

JDeveloperのリファクタのサポートについて理解しておくと役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Javaコードでの作業」を参照してください。

また、ADFビジネス・コンポーネントのリファクタの制限について理解しておくと役立つことがあります。詳細は、「ADFビジネス・コンポーネント・オブジェクト属性のリファクタ」を参照してください。

次のタスクを完了する必要があります。

1. 「ウィザードを使用した新規コンポーネントの作成方法」の説明に従って、データ・モデル・プロジェクトのビジネス・コンポーネントを作成します。

2. 「オフライン・データベース・オブジェクトで作業するためのデータ・モデル・プロジェクトの変更方法」の説明に従い、データ・モデル・プロジェクトでオフライン・データベースを作成します。

ADFビジネス・コンポーネントのオフライン・データベース表の名前をリファクタするには:

1. 「アプリケーション」ウィンドウで、データ・モデル・プロジェクトを開き、編集したいデータベース・オブジェクトを選択します。

2. メイン・メニューから「リファクタ」→「名前の変更」を選択します。
また、データベース・オブジェクトを右クリックして「リファクタ」→「名前の変更」を選択することもできます。

3. 「名前の変更」ダイアログで、新しい名前を入力して「 プレビュー」をクリックします。

4. 「ログ」ウィンドウで、データベース・オブジェクト名を参照しているビジネス・コンポーネントを確認します。
「ログ」ウィンドウの「名前の変更」ページで名前付きアイテムがJDeveloper内のエディタにリンクされます。必要に応じて、リスト内のアイテムをクリックし、JDeveloper内でその詳細を表示します。

5. 「リファクタ」をクリックし、「ログ」ウィンドウに表示された新しい名前を適用します。

ADFビジネス・コンポーネントのオフライン・データベース列の名前をリファクタするには:

1. 「アプリケーション」ウィンドウのデータ・モデル・プロジェクト内で「オフライン・データベース・ソース」フォルダを開き、編集する列を含むデータベース表を選択します。

2. 「構造」ウィンドウで、列名をダブルクリックします。

また、データベース・オブジェクトを右クリックして「宣言に移動」を選択することもできます。

3. オフライン・データベース表の概要エディタで、列名を編集し、[Enter]を押します。

4. 「ログ」ウィンドウで、列名を参照しているビジネス・コンポーネントを確認します。

「ログ」ウィンドウの「名前の変更」ページで名前付きアイテムがJDeveloper内のエディタにリンクされます。必要に応じて、リスト内のアイテムをクリックし、JDeveloper内でその詳細を表示します。

5. 「リファクタ」をクリックし、「ログ」ウィンドウに表示された名前の変更を適用します。

3.4.7 ダイアグラム使用による関連ビジネス・コンポーネントの表示方法

プロジェクトが定義するビジネス・コンポーネントの数が増大すると、コンポーネントをリファクタして、最初に作成された関係を変更する場合があります。データ・モデル・プロジェクトにおける複数のコンポーネントの関係を把握するには、ビジネス・コンポーネントを概要エディタで開き、「ダイアグラム」タブをクリックします。エディタの関係ダイアグラムでは、編集するコンポーネントを太字で識別します。関連コンポーネントは、クリックするとリンクで識別されるコンポーネントを表示できるテキスト・リンクとして表示されます。

たとえば、図3-10は、ProductVOビュー・オブジェクトのエディタの「ダイアグラム」タブを示しています。ProductVOがアクセスできるエンティティ・オブジェクト(たとえば、ProductEO)、関連ビュー・オブジェクトに対するビュー・オブジェクトの関係を定義するビュー・リンク(たとえば、ProductVOとItemVOの間のリンクにマウス・ポインタを置くとItemProductIdFkLinkビュー・リンクが表示される)およびビュー・リンクにより命名された関連ビュー・オブジェクト(この例では、ItemVO)をダイアグラムにより識別します。これらの各関連コンポーネントは、クリックするとエディタの「ダイアグラム」タブでコンポーネントを開くことができるリンクとして表示されます。関連コンポーネントのリンクをクリックすると、ダイアグラムを使用して、プロジェクトで定義するコンポーネント関係にナビゲートできます。

図3-10 関係ダイアグラムにおけるメイン・オブジェクトとすべての関連コンポーネントの表示

始める前に:

JDeveloperにおけるUMLクラス・ダイアグラムによるアプリケーションのモデル化のサポートについて理解しておくと役立つ場合があります。詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「モデル化を使用したアプリケーションの開発」を参照してください。

次のタスクを完了する必要があります。

- 「ウィザードを使用した新規コンポーネントの作成方法」の説明に従って、データ・モデル・プロジェクトのビジネス・コンポーネントを作成します。

データ・モデル・プロジェクトのビジネス・コンポーネントの関係ダイアグラムを表示するには:

1. 「アプリケーション」ウィンドウで、表示するビジネス・コンポーネントを右クリックし、「開く」を選択します。

2. 概要エディタで、「ダイアグラム」タブをクリックして関係ダイアグラムに編集中のコンポーネントとそれに関連するすべてのコンポーネントを表示します。

関係ダイアグラムでは、編集中のコンポーネントは太字で識別されます。関連コンポーネントは、クリックするとリンクで識別されるコンポーネントを表示できるテキスト・リンクとして表示されます。関連コンポーネントのリンクをクリックすると、ダイアグラムを使用して、プロジェクトで定義するコンポーネント関係にナビゲートできます。

3.4.8 UMLダイアグラムの使用に関する必知事項

JDeveloperでは、ADFビジネス・コンポーネントに対する充実したUMLダイアグラム・サポートが提供されます。作成済の既存のコンポーネントは、ビジネス・コンポーネント・ダイアグラムに追加して視覚化できます。また、コンポーネントの作成および変更にダイアグラムを使用することもできます。ダイアグラムは、エディタでの変更と同期しています。

新しいビジネス・コンポーネント・ダイアグラムを作成するには、JDeveloperの「新規ギャラリ」の「ADFビジネス・コンポーネント」カテゴリから、「ビジネス・コンポーネント・ダイアグラム」アイテムを使用します。このカテゴリは、Business Tierの選択肢の一部です。

3.5 ビジネス・コンポーネントのカスタマイズ

コンポーネントのベース機能を拡張するため、またはイベントを処理するためにカスタム・コードを追加する必要がある場合、アプリケーション・モジュール、エンティティ・オブジェクト、ビュー・オブジェクトを含め作成するADFビジネス・コンポーネントのすべての主要タイプに対してカスタムJavaクラスを作成する必要があります。

たとえば、特定のビジネス・ロジックを実行する場合は、アプリケーション・モジュールのJavaクラスにカスタム・メソッドを追加できます。これには次のコードが考えられますが、これらのコードに限定されるものではありません。

- 表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成

- 集計結果を取得するための、ビュー・オブジェクト行の反復処理

- 1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行

これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。

- コードの目的が、クライアントにより明確に伝わります。

- 必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。

- ビジネス・サービス機能全体の回帰テストを簡略化できます。

- クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。

- ページ内での論理的ビジネス機能の宣言的起動が可能になります。

3.5.1 ビジネス・コンポーネントJavaサブクラスの生成方法

エンティティ・オブジェクト、ビュー・オブジェクトおよびデータ・モデル・プロジェクトのアプリケーション・モジュールに会社レベルのサブクラスを指定できます。生成する新しいビジネス・コンポーネントがこれらのカスタム・クラスに基づくようにこのオプションを有効にするには、ADFビジネス・コンポーネント実装クラスを拡張するJavaソース・ファイルを作成する必要があり(oracle.jboパッケージ内)、このファイルが拡張された機能の最終的な追加先となる場合があります。これを実行すると、アプリケーション内のサブクラスによって選択可能なベース・フレームワーク・クラスへ後から柔軟に変更を加えることができます。その後、「プロジェクト・プロパティ」ダイアログで「ADFビジネス・コンポーネント」→「ベース・クラス」を選択しサブクラスの名前を指定します。

さらに、個々のコンポーネントのビジネス・コンポーネント用に生成するカスタム・クラスの生成を有効にできます。各概要エディタのJavaページでこのオプションを有効にすると、JDeveloperにより、構成可能なネーミングの標準に準拠した名前のコンポーネントに関連するカスタム・クラスのJavaソース・ファイルが作成されます。このクラスの名前は、コンポーネントのXMLドキュメントに記録され、コンポーネントでのみ必要とされるカスタムJavaコードは、このクラス内に記述できます。コンポーネントのカスタムJavaクラスを有効にしたら、「アプリケーション」ウィンドウでコンポーネントを開きJavaクラスをダブルクリックしてクラスを編集します。

または、JDeveloperが各コンポーネント・タイプのJavaクラスを生成する方法を制御するプロジェクトレベルの設定を変更できます。変更するには、「ツール」→「プリファレンス」を選択し、「ADFビジネス・コンポーネント」ページを開きます。選択した設定は、今後作成するすべてのビジネス・コンポーネントに適用されます。

ベスト・プラクティス

ADFビジネス・コンポーネントを初めて使用する開発者には、ベース・フレームワーク・クラスをオーバーライドして、すべての生成されたカスタムJavaクラスがカスタマイズされた動作を選択できるようにすることをお薦めします。この方法は、個々のエンティティ・オブジェクトおよびビュー・オブジェクトのカスタム・クラスの作成より優先されます。カスタム・コンポーネントを生成するときは、「プロジェクト・プロパティ」ダイアログの「ADFビジネス・コンポーネント」→「ベース・クラス」ページで、フレームワーク・クラスをオーバーライドするように指定します。

始める前に:

ビジネス・コンポーネントのプログラム的操作について理解しておくと役立つ場合があります。詳細は、次の各項を参照してください。

- アプリケーション・モジュール・クライアント・インタフェースのプログラム的操作

- エンティティ・オブジェクトおよびアソシエーションのプログラム的操作

- 複数の名前付きビュー基準のプログラム的処理

次のタスクを完了する必要があります。

- 「ウィザードを使用した新規コンポーネントの作成方法」の説明に従って、データ・モデル・プロジェクトのビジネス・コンポーネントを作成します。

カスタム・クラスでフレームワーク・ビジネス・コンポーネント・クラスをオーバーライドするには:

1. 「アプリケーション」ウィンドウで、カスタム・クラスを作成するコンポーネントをダブルクリックします。

2. コンポーネントの概要エディタで、「Java」ナビゲーション・タブを選択します。

3. 「Java」ページで、「Javaオプションの編集」アイコンをクリックします。

4. 「Javaオプションの選択」ダイアログで、目的の実装クラスを作成するためのJavaクラス生成オプションを選択します。

- アプリケーション・モジュール・クラスの生成: 完全なビジネス・サービスの論理面となる機能をカプセル化するためのカスタム・メソッドを含めることができるアプリケーション・モジュール実装クラスを生成します。

- エンティティ・オブジェクト・クラスの生成: 基礎となるデータベース表の各行の表示を処理するためのカスタム・メソッドを含めることができるエンティティ・オブジェクト実装クラスを生成します。

- ビュー・オブジェクト・クラスの生成: アプリケーション・モジュール定義内の特定のビュー・オブジェクト定義を処理するためのカスタム・メソッドを含めることができるビュー・オブジェクト実装クラスを生成します。

- ビュー行クラスの生成: ビュー・オブジェクトによって返される単一行の表示を処理するためのカスタム・メソッドを含めることができるビュー行実装クラスを生成します。

5. カスタム・コードをサポートするメソッドを生成するためのオプションを選択します。

「Javaオプションの選択」ダイアログで、クラスを作成し「アクセッサを含める」を選択した場合、JDeveloperはビジネス・コンポーネントによって定義されたすべての属性に対してアクセッサを生成します。JDeveloperはアクセッサ・メソッド名に属性名を使用するため、これらの属性名はリファクタが困難となり、カスタム・コードが使用しないメソッドを削除するには生成されたクラス・ファイルを編集する必要があります。

6. 「OK」をクリックします。

7. 「アプリケーション」ウィンドウでクラスを作成するビジネス・コンポーネントを開いて、componentNameImpl.javaファイルをダブルクリックします。

8. エンティティ・オブジェクト・クラスまたはビュー行クラスを作成した場合は、ファイルを編集してビジネス・ユースケース向けに公開する必要のない属性に対して生成されたアクセッサ・メソッドを削除します。

ヒント:

生成されたクラス・ファイルを編集して、カスタム・ロジックによって使用されていない生成されたコードを削除し、全体的なパフォーマンスを改善します。

3.5.2 ビジネス・コンポーネント・メソッドのクライアントへの公開方法

クライアントからコール可能にするカスタム・コードをADFビジネス・コンポーネントに追加する場合は、クライアントに表示されるコンポーネントすべてについて、その機能をクライアントに公開できます。JDeveloperでは、クライアント・インタフェース上で1つ以上のカスタム・メソッドをクライアントに公開している各コンポーネントに対して、関連するJavaインタフェース・ファイルが自動的に保持されます。そのため、SummitAppModuleなどのアプリケーション・モジュールで作業していると仮定すると、次のようなカスタム・インタフェースを利用できます。

- カスタム・アプリケーション・モジュール・インタフェース

SummitAppModule extends ApplicationModule

- カスタム・ビュー・オブジェクト・インタフェース

OrderItemsInfo extends ViewObject

- カスタム・ビュー行インタフェース

OrderItemsInfoRowClient extends Row

これにより、クライアント・コードでは、汎用クライアント・インタフェースをより詳細なインタフェースにキャストできます。詳細なインタフェースには、特定のコンポーネントに対して選択した、クライアントからアクセス可能な一連のメソッドが含まれます。

始める前に:

カスタム・コードでオーバーライドできるADFビジネス・コンポーネント・インタフェースのメソッドについて理解しておくと役立つ場合があります。詳細は、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

次のタスクを完了する必要があります。

- 「ビジネス・コンポーネントJavaサブクラスの生成方法」の説明に従い、アプリケーション・モジュールまたはビュー・オブジェクトの実装クラスを生成し、クライアントに公開するカスタム・メソッドを追加します。

コンポーネント実装クラスからクライアント・メソッドを公開するには:

1. 「アプリケーション」ウィンドウで、カスタム・クラスを作成するコンポーネントをダブルクリックします。

2. コンポーネントの概要エディタで、「Java」ナビゲーション・タブを選択します。

3. 「Java」ページで、「クライアント・インタフェースの編集」アイコンをクリックします。

4. 「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。

5. 「OK」をクリックします。

3.5.3 カスタム・クラス生成時の処理

生成するカスタムJavaクラスを1つ以上選択すると、指定したJavaファイルが作成されます。たとえば、oracle.summit.model.service.SummitAppModuleという名前のアプリケーション・モジュールの場合、そのカスタムJavaファイルのデフォルト名は、アプリケーション・モジュール・クラスに対してはSummitAppModuleImpl.java、アプリケーション・モジュール定義クラスに対してはSummitAppModuleDefImpl.javaになります。どちらのファイルも、コンポーネントのXMLドキュメント・ファイルと同じ./oracle/summit/model/servicesディレクトリに作成されます。

注意:

このガイドの例では、生成済のカスタム・コンポーネント・クラスやインタフェースの名前には、デフォルトの設定を使用しています。自社アプリケーションでこれらのデフォルトを変更するには、JDeveloperの「プリファレンス」ダイアログの「ADFビジネス・コンポーネント: クラス・ネーミング」ページを使用してください。ここでの変更は、新しく作成したコンポーネントにのみ反映されます。

ビジネス・コンポーネントのJava生成オプションは、概要エディタの「Java」ページに後でアクセスしてもそのまま反映されています。XML定義ファイルの場合と同様、このエディタでどのような変更を行っても、カスタムJavaクラスで生成されたコードは最新の状態に保たれます。後でカスタムJavaファイルが必要なくなった場合は、「Java」ページで関連するオプションを無効にすると対応するカスタムJavaファイルを削除できます。

図3-11は、YourServiceアプリケーション・モジュールに対してカスタムJavaクラスを有効にするとどうなるかを示しています。YourServiceImpl.javaソース・コード・ファイルが、コンポーネントのXMLドキュメント・ファイルと同じソース・パス・ディレクトリに作成されます。YourServiceImpl.xmlファイルでは、ApplicationModuleImplクラスではなく、com.yourcompany.yourapp.YourServiceImplベース・クラスを実行時に使用するよう、変更が反映されます。

図3-11 カスタムJavaクラスのあるコンポーネント

3.5.4 カスタム・インタフェースのサポートに関する必知事項

oracle.jboパッケージのJavaインタフェースによって、クライアントがアクセス可能なビジネス・サービスに対するAPIが提供されます。クライアント・コードが次のようにインタフェースと連携します。

- ApplicationModule: アプリケーション・モジュールを処理します。

- ViewObject: ビュー・オブジェクトを処理します。

- Row: ビュー行を処理します。

ビジネス・サービスの次のコンポーネントのみがクライアントに表示されます。

- アプリケーション・モジュール: サービス自体を表します。

- ビュー・オブジェクト: 問合せコンポーネントを表します。

- ビュー行: 指定された問合せコンポーネントの結果の各行を表します。

このパッケージには、Entityインタフェース、またはクライアントがエンティティ・オブジェクトを直接操作できるようにするメソッドは含まれていません。ビジネス・サービス実装におけるエンティティ・オブジェクトは、クライアントから直接参照されるように設計されていません。かわりに、クライアントは、アプリケーション・モジュールのデータ・モデルの一部として、ビュー・オブジェクトによる問合せデータを処理します。実際には、ビュー・オブジェクトはビジネス・サービス・レイヤー内のエンティティ・オブジェクトと自動的に連携し、エンド・ユーザーが変更したデータの検証と保存を調整します。この実行時の対話処理の詳細は、「実行時のビュー・オブジェクトとエンティティ・オブジェクトの連携処理」を参照してください。

3.5.5 汎用APIと強く型付けされたAPIの相違に関する必知事項

アプリケーション・モジュール、ビュー・オブジェクトやエンティティ・オブジェクトで作業を行う際、汎用APIを使用するか、そのコンポーネントに強く型付けされたAPIを有効にするために、JDeveloperでコードをカスタムJavaクラスに生成できます。たとえば、ビュー・オブジェクトでの作業中、次のような汎用APIを使用し、結果のすべての行の属性値にアクセスできます。

Row row = ordersVO.getCurrentRow();
Date shippedDate = (Date)row.getAttribute("OrderShippedDate");

汎用APIを使用した場合、パラメータの文字列名をアクセッサに渡し、戻り値の型をこの例のDateのように予想される型にキャストする必要があります。

一方、強く型付けされた作業スタイルを有効にした場合、次のようにコードを記述できます。

OrdersRow row = (OrdersRow)ordersVO.getCurrentRow();
Date shippedDate = row.getOrderShippedDate();

この場合、文字列名を渡して結果をキャストするのではなく、戻り型がコンパイル時に判明する生成済メソッド名を使用します。コンパイル時の安全性を犠牲にせずに、ビジネス・ロジック・コードからメソッドを起動する必要がある場合は、通常、強く型付けされたアクセッサを使用する必要があります。この方法は、setterメソッド内でカスタム検証ロジックを記述する場合にも役立ちますが、この場合は、ビジネス・コンポーネントでエンティティおよびビュー行実装クラスを生成するかわりに、Groovy式の使用を検討する必要が生じる場合もあります。後続の章では、Javaを使用した実装を選択するビジネス・ロジックのJavaクラスを生成して、強く型付けされた作業スタイルを有効化する方法について説明します。

3.6 ビジネス・コンポーネントでのGroovyスクリプト言語の使用

Groovyは、Javaプラットフォーム用のスクリプト言語で、Javaと同様の構文を持ちます。ADFビジネス・コンポーネントのGroovy言語式は、ビジネス・コンポーネントのカスタムJavaクラスで使用するJavaコードとは異なります。Groovyスクリプト言語では、ドット区切り表記法の採用により、コードの作成が簡素化されていますが、コレクション、文字列およびJavaBeansを操作する構文は引き続きサポートされています。

現在Groovy式は、エンティティ・オブジェクトとビュー・オブジェクトのビジネス・コンポーネントでサポートされています。ユーザーはADFビジネス・コンポーネント内のGroovy式を利用して、ビュー基準やバインド変数、エンティティまたはビュー・オブジェクト属性のデフォルト値、ビジネス・ルール、トリガーについて、実行時にそれらの値を指定できます。さらに、ADFビジネス・コンポーネントには、Groovy式で使用できる組込みキーワードの限定されたセットが用意されています。Groovyスクリプト言語の使用用途の詳細は、モデル・プロジェクト内の「Groovy式を使用できる場所に関する必知事項」を参照してください。

ビジネス・コンポーネント・スクリプト(.bcs)ファイルの生成

エンティティ・オブジェクトまたはビュー・オブジェクトにGroovy式を入力すると、それらのGroovy式はすべてビジネス・コンポーネントの.bcs (ビジネス・コンポーネント・スクリプト)ファイルに移入されます。ビジネス・コンポーネントの.bcsファイルは、特定のエンティティ・オブジェクトまたはビュー・オブジェクトに属するアーティファクト(Javaクラス、XMLファイル、Operations XMLファイルなど)のリストに含まれる項目の1つと考えられます。コンテキストや目的に応じて、JDeveloperの様々なUIコンテキストでGroovy式を入力する方法は、「ビジネス・コンポーネントにGroovy式を入力する方法」を参照してください。.bcsファイルにはデバッグ機能があり、通常のJavaエディタのように機能します。ブレークポイントの設定や注釈パッケージのインポート、Groovy構文のコンパイル、「ログ」ウィンドウに表示されたエラーの修正が可能です。

Groovy式のタイプ・チェックのサポート

JDeveloperはGroovy式のタイプ・チェックをサポートしています。タイプ・チェックは設計時に作成されたGroovy式の構文を精査し、エラーを検出してJDeveloperの「ログ」ウィンドウに表示します。これらのGroovy式が実行時にエラーなしで実行されるように、ADFモデル・プロジェクト内のこれらのエラーは修正してください。デフォルトで、タイプ・チェックは有効になっています。タイプ・チェックは無効化できます。タイプ・チェックを無効にした場合、実行時にのみタイプ・チェックが実行されます。Groovy式のタイプ・チェックは実行前に済ませておくことをお薦めします。Groovyのタイプ・チェックは、作成したすべてのプロジェクトまたは特定のプロジェクトを対象に有効化または無効化できます。Groovyタイプ・チェックのアプリケーション全体およびプロジェクト固有の設定の詳細は、「Groovyプロジェクトの設定に関する必知事項」を参照してください。

3.6.1 ビジネス・コンポーネントにGroovy式を入力する方法

JDeveloperでは、エンティティ・オブジェクト、ビュー・オブジェクトおよびビュー・オブジェクト慣用名(アプリケーション・モジュール上)に対してGroovy式を定義できます。「式エディタの編集」ダイアログにGroovy式を入力します。このエディタはアプリケーションの様々なUIコンテキストで呼び出します。

ADFビジネス・コンポーネントは、エンティティ・オブジェクトの属性やビュー・オブジェクトの属性へのアクセスが有用な場所でGroovyスクリプト言語の使用をサポートしており、これには属性バリデータ(エンティティ・オブジェクトの場合)、属性のデフォルト値(エンティティ・オブジェクトまたはビュー・オブジェクトの場合)、一時属性値の計算(エンティティ・オブジェクトまたはビュー・オブジェクトの場合)、バインド変数のデフォルト値(ビュー・オブジェクトの問合せ文およびビュー基準フィルタの場合)、およびエラー・メッセージのプレースホルダ(エンティティ・オブジェクトの検証ルールの場合)などが含まれます。

ADFビジネス・コンポーネントでは、次のタスクを実行するGroovy言語式に対してのサポートが特に強化されています。

- スクリプト式バリデータまたは比較バリデータの追加(「ビジネス・ルールとトリガーでのGroovy式の使用」を参照)

- 検証エラーを処理するエラー・メッセージ・トークンの定義(「エラー・メッセージにGroovy式を埋め込む方法」を参照)

- バリデータの条件付き実行の処理(「Groovyを使用して条件付きでエラー・メッセージを呼び出す方法」を参照)

- ビュー・オブジェクト問合せ文のバインド変数のデフォルト値の設定(「バインド変数の使用」を参照)

- ビュー基準文の基準アイテムを指定するバインド変数のデフォルト値の設定(「名前付きビュー基準の処理」を参照)。

- エンティティ・オブジェクト属性のデフォルト値およびオプションの再計算条件の定義(「静的なデフォルト値を定義する方法」を参照)

- エンティティ・オブジェクトまたはビュー・オブジェクトの一時属性の値の算出(「エンティティ・オブジェクトへの一時属性および計算属性の追加」および「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照)

注意:
次に示すGroovy式による属性のデフォルト値の定義手順は、「式エディタの編集」ダイアログにGroovy式を入力する方法を説明するための例です。この理由から、同様に「式エディタの編集」ダイアログを使用して定義する「式値のリフレッシュ」に関する言及が含まれています。「式値のリフレッシュ」は属性のデフォルト値の定義に特有のものです。そのため、「式エディタの編集」ダイアログにGroovy式を入力する作業に、「式値のリフレッシュ」の定義に関連する作業が必ずしも含まれるとはかぎりません。

Groovy式を使用して属性のデフォルト値を定義する手順:

1. エンティティ・オブジェクトまたはビュー・オブジェクトのXMLエディタ・ビューを開きます。たとえば、Countryという名前のエンティティ・オブジェクトの場合は、CountryEO.xmlをダブルクリックしてエンティティ・オブジェクトの概要エディタを開きます。

2. 「属性」タブをクリックします。

3. 「属性」タブの「詳細」ページにナビゲートし、「デフォルト値」セクションに移動します。

4. 「式」ラジオ・ボタンを選択します。

5. 横にあるアイコンをクリックし「式エディタの編集」ダイアログを開き、デフォルト値を算出するGroovy式を定義して、「OK」をクリックします。

6. 必要であれば、前述の手順で説明したとおりデフォルト値式のすぐ下のフィールドで、「式値のリフレッシュ」を入力します。前述の手順と同じ方法で、「式値のリフレッシュ」を定義します。

3.6.2 式を入力したときの処理

エンティティ・オブジェクトやビュー・オブジェクトなどのビジネス・コンポーネントにGroovy式を入力してプロジェクトを保存すると、入力したGroovy式がコンポーネントに関連する.bcsファイルに移入されます。

この処理が正しく実行されるようにするため、「Groovyプロジェクトの設定に関する必知事項」の説明のとおり、Groovyファイルの生成を制御する設定は無効にしないでください。エンティティ・オブジェクトまたはビュー・オブジェクトの様々なUIコンテキストでGroovy式を入力するメカニズムが用意されています。ビジネス・コンポーネントに関連する.bcsファイルに追加されたGroovy式を表示します。

次のUIコンテキストでビジネス・コンポーネントにGroovy式を追加したときに、Groovy式がハイパーリンクとして表現されます。

- 属性のデフォルト値としてGroovy式を定義した後、または式値のリフレッシュを設定した後。

- 属性に、ラベル、ツールチップなどのUIヒントを定義した後。

図3-12は、ビュー・オブジェクトに追加されたGroovy式を示しており、ビュー・オブジェクトの属性のデフォルト値を設定しています。式はハイパーリンクとして表現されます。ハイパーリンクのリンクは.bcsファイル内の式スクリプトにリンクしています。このハイパーリンクをクリックすると、このビジネス・コンポーネントに関連する.bcsファイルが開きます。

図3-12 ハイパーリンクとして表示されたGroovy式

エンティティ・オブジェクトまたはビュー・オブジェクトに対して追加されたGroovy式はコンポーネントの「構造」ウィンドウにも表示されます。図3-13は、OrdEOコンポーネントのDateOrdered属性に対して追加されたGroovy式が、画面左下の「構造」ウィンドウに表示されているところを示しています。

図3-13 コンポーネントの「構造」ウィンドウに表示されたGroovy式

JDeveloperでは、エンティティ・オブジェクトおよびビュー・オブジェクトのXMLソース(ビジネス・コンポーネントの概要エディタの「ソース」タブで表示)と、そのコンポーネントの.bcsファイル内で、Groovy式が表現されます。ビジネス・コンポーネントのXMLソース・ビューではXML構造によってGroovy式への参照が定義され、ビジネス・コンポーネントの.bcsファイルではそのGroovy式はスクリプトとして表現されます。.bcsファイル内の注釈は、Groovy式が定義されているビジネス・コンポーネントや属性名など、スクリプトに関する情報を提供します。そのため、Groovy式のXML定義の一部として含まれている情報の一部は注釈で利用されます。Groovy式のXML定義では、Groovy式がスクリプトとして含まれている.bcsファイルを示すために、CodeSourceName値を使用します。CodeSourceName値にはoperations.xmlファイルの値が割り当てられます。operations.xmlファイルはビジネス・コンポーネントに関連付けられるさらに別のXMLファイルで、ここに.bcsファイルのURIが含まれています。

次のサンプルはOrdEOエンティティ・オブジェクトのDateOrdered属性の結果のXMLソースです。Groovy式を参照するXML定義を示しています。

<Attribute
Name="DateOrdered"
ColumnName="DATE_ORDERED"
SQLType="TIMESTAMP"
Type="java.sql.Date"
ColumnType="DATE"
TableName="S_ORD">
<DesignTime>
<Attr Name="_DisplaySize" Value="7"/>
</DesignTime>
<TransientExpression
Name="ExpressionScript"
CodeSourceName="OrdEORow"/>
</Attribute>

また、次のサンプルはDateOrdered属性のGroovyスクリプト定義を表示する.bcsファイルを示しています。

@TransientValueExpression(attributeName="DateOrdered")
def DateOrdered_ExpressionScript_Expression()
{
adf.currentDate
}

XMLソースと.bcsファイルのサンプルからわかるように、XMLソースのname="DateOrderedは、.bcsファイルの注釈内のメソッド名DateOrdered_ExpressionScript_Expression()に対応しています。これらの値は、このDateOrdered属性のGroovy式を定義している式スクリプト・メソッド名を示しています。XMLソース内のCodeSourceName="OrdEORow"はoperations.xmlファイルを示しており、OrdEOエンティティ・オブジェクトの場合はOrdEOOperations.xmlです。operations.xmlファイルには、.bcsファイルを指し示すURIが含まれています。

3.6.3 Groovyプロジェクトの設定に関する必知事項

Groovyタイプ・チェックを有効にすると、.bcsファイルに含まれているGroovy式のタイプ・チェックが実行されます。Groovyファイル生成を有効にすると、コンポーネントのすべてのGroovy式が関連する.bcsファイルに移入されます。

Groovyタイプ・チェックとGroovyファイル生成は、特定のモデル・プロジェクトまたはすべてのプロジェクトに対して有効化または無効化できます。

Groovy式タイプの検証

JDeveloperのメイン・メニューから、「アプリケーション」→「プロジェクト・プロパティ」にナビゲートし、「プロジェクト・プロパティ」ダイアログから「ADFビジネス・コンポーネント」を選択し、プラス記号のアイコンをクリックして展開し、「オプション」を選択します。「オプション」ページで「Groovy式タイプの検証」チェック・ボックスを選択し、JDeveloperでこの特定のモデル・プロジェクトに対してGroovy式タイプ検証が実行されるようにします。このプロパティをアプリケーションのすべてのプロジェクトに対して設定するには、「ツール」→「プリファレンス」にナビゲートし、「プリファレンス」ダイアログ・ボックスから「ADFビジネス・コンポーネント」を選択します。プラス記号のアイコンをクリックして展開し「一般」を選択します。「一般」ページで「Groovy式タイプの検証」チェック・ボックスを選択します。プロジェクトをコンパイルすると、エンティティ・オブジェクトおよびビュー・オブジェクト固有のビジネス・コンポーネント・スクリプト(.bcs)ファイルに含まれるGroovy式がコンパイルされ、JDeveloperの「ログ」ウィンドウにエラーが表示されます。.bcsファイル内に定義されているGroovy式スクリプトのタイプ・チェックを実行しない場合は、このオプションの選択を解除します。これ以降作成する新しいプロジェクトに対してタイプ・チェックが実行されなくなります。既存のプロジェクトについては引き続きタイプ・チェックが実行されます。コンポーネントの.bcsファイルに含まれるGroovy式スクリプトのデバッグをサポートするため、このオプションは有効(デフォルト)にしておくことをお薦めします。タイプ・チェックを無効にすることでGroovy式のデバッグが無効になるわけではありませんが、タイプ・チェックを有効にしておくと問題を実行時ではなくコンパイルの時点で検出できるため、Groovyスクリプトのデバッグが容易になります。

注意:
.bcsファイルの注釈を使用して、タイプ検証をスクリプト・レベルで無効にすることもできます。.bcsファイルで、Groovy式の前に注釈@TypeChecked(TypeCheckingMode.SKIP)を入力します。.bcsファイルのヘッダー・セクション内のimport groovy.transform.TypeCheckingModeおよびimport groovy.transform.TypeCheckedというimport文によって、指定した注釈に従った処理が実行されます。.bcsファイル内のGroovy式をコンパイルするときに、この注釈が付与された式のタイプ・チェックはスキップまたは省略されます。

Groovyファイル生成の有効化

JDeveloperのメイン・メニューから、「アプリケーション」→「プロジェクト・プロパティ」にナビゲートし、「プロジェクト・プロパティ」ダイアログから「ADFビジネス・コンポーネント」を選択し、プラス記号のアイコンをクリックして展開し、「オプション」を選択します。「オプション」ページで「Groovyファイル生成の有効化」チェック・ボックスを選択し、Groovy式を含むエンティティ・オブジェクトおよびビュー・オブジェクトのビジネス・コンポーネント・スクリプト(.bcs)ファイルが、このモデル・プロジェクト内に生成されるようにします。コンポーネントの概要エディタでGroovy式を定義すると(エンティティ・オブジェクトの属性にデフォルト値式を入力する、検証ルール式を入力するなど)、コンポーネントに.bcsファイルが作成されます。Groovy式が.bcsファイルに集積されないようにするには、このオプションの選択を解除します。

このチェック・ボックスを選択した状態でGroovy式を入力し、その後にチェック・ボックスの選択を解除した場合、生成された.bcsファイルには以前に追加されたGroovy式が残りますが、後から定義したGroovy式は.bcsファイルに移入されず、コンポーネントのXML定義ファイル(.xml)に保存されます。すべての式がエンティティ・オブジェクトおよびビュー・オブジェクト固有の.bcsファイルに集積されるように、このオプションは有効(デフォルト)にしておくことをお薦めします。このファイルで、Groovy式スクリプトを編集したり、コンパイルしてエラーがないかをチェックできます。また、式をビジネス・コンポーネント・スクリプト・ファイルに集積しておくことで、実行時のパフォーマンスを極限まで高めることができます。

注意:
ADFアプリケーションをJDeveloperリリース12.2.1以降に移行するときに、このチェック・ボックスの選択を解除すると、モデル・プロジェクト・コンポーネントの.xmlファイル内の式を維持できます。ただ、このチェック・ボックスは選択しておき、JDeveloperの移行機能を活用してすべてのGroovy式を.bcsファイルに移動することをお薦めします。Javaソース・エディタでのスクリプト編集とコンパイルのパフォーマンスを向上できるためです。

3.6.4 Groovy式を使用できる場所に関する必知事項

Groovy式はADFビジネス・コンポーネントのエンティティ・オブジェクト、ビュー・オブジェクトおよびアプリケーション・モジュールで使用します。このアプリケーションにはビジネス・コンポーネントの複数のコンテキスト/場所でGroovy式を定義する機能があります。

表3-3 ADFビジネス・コンポーネントでのGroovy式の使用

式の使用

コンポーネント使用

XML要素/親XML要素

説明

一時属性値

エンティティ・オブジェクト/ビュー・オブジェクト

TransientExpression/Attribute

行レベルで一時属性値を計算します。スクリプトは行レベルで定義されます。

属性のデフォルト値

エンティティ・オブジェクト/ビュー・オブジェクト

TransientExpression/Attribute

属性のデフォルト値を計算します。スクリプトは行レベルで定義されます。

属性デフォルト値の再計算

エンティティ・オブジェクト/ビュー・オブジェクト

RecalcCondition/Attribute

値がtrueの場合、デフォルト値が再計算されます。スクリプトは行レベルで定義されます。

変数のデフォルト値

エンティティ・オブジェクト/ビュー・オブジェクト

TransientExpression/Variable

変数のデフォルト値を計算します。スクリプトはオブジェクト・レベルで定義されます。

式バリデータ

エンティティ・オブジェクト/ビュー・オブジェクト

TransientExpression/ExpressionValidationBean (Attribute、ViewAttributeまたはEntity)

この式を実行して、個々の属性またはエンティティ全体の現在の内容を検証します。スクリプトは行レベルで定義されます。

比較バリデータ

エンティティ・オブジェクト/ビュー・オブジェクト

TransientExpression/CompareValidationBean (Attribute、ViewAttribute、Entityの下)

新しい属性値と比較する値を計算します。スクリプトは行レベルで定義されます。

バリデータOnCondition

エンティティ・オブジェクト/ビュー・オブジェクト

OnCondition/ExpressionValidationBean、CompareValidationBeanなど(Attribute、ViewAttribute、Entityの下)

新しい属性値と比較する値を計算します。スクリプトは行レベルで定義されます。

バリデータ・メッセージ・パラメータ

エンティティ・オブジェクト/ビュー・オブジェクト

Expression/ResExpressions (すべての検証タイプの下)

バリデータ内に、バリデータがエラーを検出したときのエラー・メッセージのテキスト・リソースを含めることができます。テキスト・リソース文字列内で、中カッコ{}を使用して変数名を指定できます。この変数はテキスト・リソースに埋め込まれる値を計算するGroovy式を参照します。スクリプトは行レベルで定義されます。

UIヒント

エンティティ・オブジェクト/ビュー・オブジェクト

TransientExpression/LABEL

各属性には多数のSchemaBasedPropertiesが含まれており、その属性のUIをどのように表示する必要があるかのヒントをUI開発者に提供しています。LABELのようなテキスト・リソースの場合もあれば、DISPLAYWIDTHのように値だけの場合もあります。これらのUIヒントにGroovy式を使用して、UIヒントの値を計算させることができます。スクリプトは行レベルで定義されます。

エンティティ・トリガー

エンティティ・オブジェクト

TransientExpression/ExpressionValidationBean (Triggerの下)

trigger要素の下にあるnameプロパティはこのトリガーのタイプを示しています。この式はトリガー・イベントが発生したときに発動されます。スクリプトは行レベルで定義されます。

ビュー・アクセッサのパラメータ

エンティティ・オブジェクト/ビュー・オブジェクト

TransientExpression/PIMap (ViewAccessorの下にあるParaeterMapの下)

ビュー・アクセッサでビュー基準が使用されていて、ビュー基準内のアイテムがバインド変数を使用している場合、この式によってバインド変数の値が提供されます。スクリプトはオブジェクト・レベルで定義されます。

ビュー慣用名のパラメータ

アプリケーション・モジュール

TransientExpression/PIMap (ViewUsageの下のParaeterMapの下)

ビュー慣用名でビュー基準が使用されていて、ビュー基準内のアイテムがバインド変数を使用している場合、この式によってバインド変数の値が提供されます。スクリプトはオブジェクト・レベルで定義されます。

RowFinderパラメータ

ビュー・オブジェクト

TransientExpression/ PIMap (ViewUsageの下のParaeterMapの下)

rowfinderでビュー基準が使用されていて、ビュー基準内のアイテムがバインド変数を使用している場合、この式によってバインド変数の値が提供されます。スクリプトはオブジェクト・レベルで定義されます。

ビュー基準のCompOper

ビュー・オブジェクト

TransientExpression/CompOper

ビュー基準にカスタム演算子が実装されている場合、この式を使用してカスタム演算子を実行します。スクリプトはオブジェクト・レベルで定義されます。

3.6.5 Groovy式の構文に関する必知事項

次の項では、ADFモデル・プロジェクト内でのGroovy式言語の構文に関する重要な内容を説明します。Groovy式でビジネス・コンポーネントを参照する方法や、信頼されていない/信頼されているGroovy式の管理方法についても説明します。

Groovy式はADFビジネス・コンポーネントとの対話型の連携により、様々なタスクの実行を可能にします。Groovy式でadf.contextを使用してADFContextオブジェクトを参照したり、Groovy式のtrustModeプロパティを管理したり、組込み集計関数を使用してビジネス・コンポーネントの属性値を操作したりなど、Groovyスクリプトを使用して様々なタスクを実行できます。

3.6.5.1 Groovy式でのビジネス・コンポーネントの参照に関する必知事項

フレームワークでGroovyスクリプトを使用できるオブジェクトにアクセス可能な、adfという名前のトップレベルのオブジェクトが用意されています。Oracle ADFオブジェクトをGroovyスクリプト言語で参照する際、Oracle ADFランタイムではクラスの実際の具体的な型に対応しないラッパー・オブジェクトを戻します。これらのラッパー・オブジェクトでは、ラップされるオブジェクトのメソッドとフィールド型のすべてがサポートされています。あたかも実際のオブジェクトのように、式ではラッパー・オブジェクトを使用できます。ただし、ラッパー・オブジェクトを具体的な型にキャストしようとすると、ClassCastExceptionで失敗します。一般的に、Groovy言語で作業する際、明示的なキャストを使用する必要はなく、これらのラップされたADFビジネス・コンポーネント・オブジェクトの場合、これを行うと例外が発生します。

アクセス可能なOracle ADFオブジェクトの構成は次のとおりです。

- adf.context - ADFContextオブジェクトを参照します。

- adf.object - 式が適用されているオブジェクトを参照します(接頭辞adfを使用せずにキーワードobjectを使用して参照可能)。アクセス可能な他のメンバー名は、Groovyスクリプトが適用されたコンテキストに由来します。

- エンティティ・オブジェクト属性: コンテキストはエンティティ実装クラスのインスタンスです。このオブジェクトを介して、カスタム・エンティティ実装クラスのカスタム・メソッドと、JavadocのEntityImplに指定されたベース実装クラスで定義されているすべてのメソッドを参照できるほか、エンティティ・インスタンスの属性を参照できます。

- エンティティ・オブジェクト・スクリプト検証規則: コンテキストは、バリデータが適用されるエンティティにマージされるバリデータ・オブジェクト(JboValidatorContext)です。このコンテキストで使用できるキーワードの詳細は、「同一のビジネス・コンポーネントのメンバーの参照」を参照してください。

- ビュー・オブジェクト属性: コンテキストはビュー行実装クラスのインスタンスです。このオブジェクトを介して、カスタム・ビュー行実装クラスのカスタム・メソッドとJavadocのViewRowImplに指定されたベース実装クラスで定義されているすべてのメソッドを参照できるほか、問合せ行セットで定義されているビュー行インスタンスの属性を参照できます。この

- ビュー・オブジェクト問合せ文のバインド変数: コンテキストはビュー行ではなく変数オブジェクト自体です。structureDefプロパティを参照すると他の情報にアクセスでき、viewObjectプロパティを参照するとバインド変数を適用したビュー・オブジェクトにアクセスできます。viewObjectプロパティを介したビュー・オブジェクト属性へのアクセスはサポートされていない点に注意してください。

- ビュー基準のバインド変数: コンテキストは現在のビュー基準行です。バインド変数が定義されているビュー基準は、バインド変数が検索基準値のリストを提供できる問合せ検索フォーム・コンポーネントを作成するために使用できます。ビュー基準行にアクセスするにはstructureDefプロパティを参照している必要があり、その後、findAttributeDef()メソッドを参照して指定した属性から値を派生させることができます。viewObjectプロパティを使用して、ビュー基準が定義されているビュー・オブジェクトにアクセスすることはできません。

- ビュー・アクセッサのバインド変数: コンテキストは現在のビュー行です。バインド変数を使用するビュー・アクセッサは、カスケード値リスト(LOV)の作成に使用されます。ビュー・アクセッサは、有効な選択肢リストを編成するために使用されるビュー・アクセッサ・ビュー・オブジェクトの現在のビュー行からGroovyドリブン値を導出できます。ビュー行にアクセスするにはstructureDefプロパティを参照している必要があり、その後、findAttributeDef()メソッドを参照して指定した属性から値を派生させることができます。viewObjectプロパティを使用して、ビュー・アクセッサが定義されているビュー・オブジェクトにアクセスすることはできません。

- 一時属性: コンテキストは現在のエンティティまたはビュー行です。属性が表示されるエンティティまたはビュー行の名前で属性を参照できるだけでなく、そのエンティティまたはビュー行のpublicメソッドも参照できます。現在のオブジェクトのメソッドにアクセスするには、objectキーワードを使用して現在のオブジェクトを参照する必要があります(例: object.methodName( ))。objectキーワードは、Javaのthisキーワードと同じです。一時式でこのキーワードを使用しないと、動的にコンパイルされたGroovyスクリプト・オブジェクト自体にメソッドが存在すると判断されます。

- adf.error - 検証規則において、検証式で例外または警告を生成できるエラー・ハンドラにアクセスします。

- adf.userSession - ADFビジネス・コンポーネント・ユーザー・セッションへの参照を返します(セッションの一部であるuserDataハッシュマップの値の参照に使用できます)。

次の式を使用して現在の日付(時間を切捨て)または現在の日付と時間を参照することもできます。

- adf.currentDate

- adf.currentDateTime

3.6.5.2 信頼できないGroovy式に関する必知事項

ADF Groovyエンジンによって、Groovyによる汎用Java APIへのアクセスは制限されます。これは不正/安全でないメソッド呼出しやプロパティ・アクセスを阻止することで行われます。アプリケーション開発者は、アプリケーションJava APIで定義したカスタム・メソッドを@AllowUntrustedScriptAccessを使用して含め、セキュリティ・ポリシーを強化できます。

3.6.5.3 Groovy式でのカスタム・ビジネス・コンポーネント・メソッドと属性の参照に関する必知事項

Groovyスクリプト言語により、エンティティ・オブジェクトとビュー・オブジェクトのメソッドと属性へのアクセスのために記述するコードを容易に作成できます。

3.6.5.3.1 同一のビジネス・コンポーネントのメンバーの参照

ビジネス・コンポーネントのメンバー(エンティティ・オブジェクトとビュー・オブジェクトで定義されるメソッドと属性を含む)の参照の最も単純な例は、式を適用する属性と同一のエンティティ・オブジェクトまたはビュー・オブジェクト内に存在する属性の参照です。

たとえば、従業員の月給を指定する属性Salを持つエンティティ・オブジェクトの一時属性AnnualSalaryの値を計算するGroovy式を定義できます。

Sal * 12

または、次のような構文を使用して、単一のビュー・オブジェクトの属性を比較する単純な検証規則をGroovyで作成できます。

PromotionDate > HireDate

Javaを使用すると、同じ比較は次のようになります。

((Date)getAttribute("PromotionDate")).compareTo((Date)getAttribute("HireDate")) > 0

現在のオブジェクトは、thisオブジェクトとしてスクリプトに渡されるため、属性名を使用するだけで現在のオブジェクトの属性を参照できます。たとえば、属性レベルまたはエンティティ・レベルのスクリプト式バリデータで、HireDateという名前の属性を参照するには、スクリプトでHireDateを参照するだけですみます。

属性の参照と同様に、エンティティ実装クラスでカスタム・メソッドを定義する場合は、式の一部としてこれらのメソッドを起動できます。たとえば、次のように、属性のデフォルト値を定義します。

adf.object.getDefaultSalaryForGrade()

メソッド参照は接頭辞adf.objectを必要とし、これによって式が適用される属性を定義する同じエンティティを参照できます。これと同じ接頭辞を使用して、カスタム実装クラスが拡張するエンティティ実装クラス(EntityImpl.java)のベース・クラスのメソッドも参照できます。

検証規則でエンティティ実装クラスのメソッドを参照する場合は、接頭辞sourceを使用します。

source.getDefaultSalaryForGrade()

objectキーワードは、(メソッドが定義されている)エンティティ・オブジェクトではなく、検証規則オブジェクトを指すため、バリデータではsource接頭辞を使用する必要があります。

バリデータ・オブジェクトのメンバーを参照できるようにするために(JboValidatorContext)、検証ルール式で次のキーワードを使用できます。

- newValue: 属性レベルのバリデータで、設定されている属性値にアクセスします。

- oldValue: 属性レベルのバリデータで、設定されている現在の属性値にアクセスします。

たとえば、次の式を使用して、販売員の給与の動的検証ルール・チェックを指定できます。

if (Job == "SALESMAN")
{
return newValue < source.getMaxSalaryForGrade(Job)
}
else
return true

3.6.5.3.2 他のビジネス・コンポーネントのメンバーの参照

エンティティ・オブジェクトおよびビュー・オブジェクトで定義されているメソッドおよび属性を式で参照し、別のエンティティ・オブジェクトの属性または検証規則に適用することもできます。そのためには、エンティティ・アソシエーションのアクセッサを参照します。

たとえば、エンティティにDeptとEmpのマスター/ディテール・アソシエーションを定義する場合、デフォルトでエンティティ・アソシエーションのアクセッサにはDeptとEmpという名前が付けられ、関連元と関連先のデータ・ソースが指定されます。Groovy式でこのアクセッサを使用し、部門の場所に基づいて新しい従業員の給与のデフォルト値を設定します。

adf.object.getDefaultSalaryForGrade(Dept.Loc)

この式では、アソシエーションのアクセッサと同じ名前(Dept)であっても、エンティティを参照しません。そのかわりに、部門と従業員のマスター/ディテール関係を前提としてアクセッサを参照するため、従業員エンティティ・オブジェクトに対するGroovy式はマスターの部門エンティティを参照し、そのマスターからLoc値を渡します。

3.6.5.4 Groovy式でのビジネス・コンポーネント属性値の操作に関する必知事項

Oracle Business Components RowSetオブジェクトでは、次の組込みの集計関数を使用できます。

- rowSetAttr.sum(GroovyExpr)

- rowSetAttr.count(GroovyExpr)

- rowSetAttr.avg(GroovyExpr)

- rowSetAttr.min(GroovyExpr)

- rowSetAttr.max(GroovyExpr)

これらの集計関数は、文字列値引数を使用し、これはGroovy式として解釈され、集計が計算される際に行セットの各行のコンテキストで評価されます。Groovy式は数値(または数字のドメイン)を返す必要があります。

たとえば、Deptエンティティ・オブジェクトには、次の式によって計算されるすべての従業員の給与の合計を表示する一時属性を追加できます。

EmployeesInDept.sum("Sal")

特定の部門の従業員を参照するために、式ではマスター/ディテール・アソシエーションの関連先Empエンティティのアクセッサ名を指定します。この場合、アクセッサはEmployeesInDeptで、給与はEmpエンティティ・オブジェクトのレコードごとに解釈されます。

または、各従業員の職務によって異なる福利厚生を含めて、特定の部門の給与合計を計算する場合には、次のようにします。

EmployeesInDept.sum("Sal + adf.object.getBenefitsValue(Job)")

3.6.6 Groovyスニペットの移行に関する必知事項

以前のリリースからJDeveloper 12.2.1に移行するときに、Groovyスニペットを.bcsファイルに移行できます。

JDeveloper 12.2.1より前のリリースでは、エンティティ・オブジェクトやビュー・オブジェクトなどのビジネス・コンポーネントで定義されたGroovy式は、そのビジネス・コンポーネントのXMLソースに含まれていました。12.2.1以降では、Groovyファイルの生成が有効化されている場合、ビジネス・コンポーネントで定義されたGroovy式はそのビジネス・コンポーネントに関連付けられた.bcsファイルに集積されます。現在のプロジェクトまたはすべてのプロジェクトに対してタイプ・チェックが有効になっている場合、コンパイル時に.bcsファイル内でタイプ・チェックが実行されます。Groovyのタイプ・チェックおよびGroovyファイル生成を有効または無効にする方法の詳細は、「Groovyプロジェクトの設定に関する必知事項」を参照してください。

JDeveloper 12.2.1以降、.bcsファイルへのGroovyファイル生成と.bcsファイル内のGroovy式のタイプ・チェックを有効にする設定は、デフォルトで有効になっています。そのためADFアプリケーションを以前のリリースからJDeveloper 12.2.1に移行する際、ビジネス・コンポーネントのXMLソースの左余白にプロンプトが表示されます。プロンプトをクリックすると、Groovy式を.bcsファイルに移動するオプションが表示されます。図3-14は、XMLソース内のGroovyスニペットに対してJDeveloperが表示したプロンプトを示しています(ビジネス・コンポーネントの概要エディタの「ソース」タブに表示されます)。

図3-14 コード・アシストがGroovyスニペットの移行を実行

- 「外部コードソースへの移動」を選択すると、このプロンプトが表示されているGroovyスニペットが、このビジネス・コンポーネントの.bcsファイルに移動します。

- 「タイプ・チェックをオフにした、外部コードソースへの移動」を選択すると、このプロンプトが表示されているGroovyスニペットが、タイプ・チェックをオフにした状態で、このビジネス・コンポーネントの.bcsファイルに移動します。

- 「"Groovy codesource"をJDeveloper名(処理の指示の抑制)によって抑制」を選択すると、これらのプロンプトがオフになります。オフにすると、Groovy式を含む移行対象のいずれのビジネス・コンポーネントでも、XMLソースにプロンプトが表示されなくなります。

GroovyスニペットがXMLソースから.bcsファイルに移行されると、XMLソースのXML定義に、Groovyスニペットの移行先である.bcsファイルへの参照が表示されます。移行されたGroovy式は(その他のGroovy式と同じように)XMLソースのXML定義内で、.bcsファイル内の注釈に含まれる情報と部分的に一致する共通の情報を持つことになります。この共通の情報は、XMLソースと.bcsファイル間でのGroovy式の特定に役立ちます。XMLソースと.bcsファイルのコンテキストにわたるGroovy式の共通情報に関する詳細は、「式を入力したときの処理」を参照してください。

注意:
JDeveloperにはアプリケーションを開いたときに実行される監査ルールがあり、これが移行機能を促進します。監査ルールは、監査ルールの集合である監査プロファイルの一部です。事前に有効にしたGroovy固有の監査ルールが移行を成功に導きます。これらのフラグを表示するには、JDeveloperのメイン・メニューから「ツール」にナビゲートし、「プリファレンス」を選択します。「プリファレンス」ダイアログで「監査」を選択します。監査プロファイルのリストを表示するには、「プロファイルの管理」をクリックします。このリストから「Application Development Framework (ADF)」監査プロファイルを選択して展開し、サブルールのリストを表示します。「ADFbc監査ルール」を選択して展開し、このルール内のサブルールのリストを表示します。「共通」を選択して展開し、事前に有効にされているGroovy固有の監査ルールを表示します。これによりGroovyスニペットの移行が促進されます。監査ルールの詳細は、『Oracle JDeveloperによるアプリケーションの開発』の監査ルールの理解を参照してください。

4 エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成

この章では、ADFエンティティ・オブジェクトを使用して、Oracle ADFアプリケーションでビジネス・ドメインについて記述しているJavaオブジェクトの再使用可能なビジネス・レイヤーを作成する方法について説明します。

この章の内容は次のとおりです。

- エンティティ・オブジェクトについて

- エンティティ・オブジェクトおよびアソシエーションの作成

- アソシエーションの作成と構成

- ビジネス・レイヤーのエンティティ・オブジェクトの図の作成

- プロパティ・セットの定義

- エンティティ・オブジェクトの属性のコントロール・ヒントの定義

- リソース・バンドルの使用

- ビジネス・ロジック・グループの定義

- 宣言的な実行時動作の構成

- 属性プロパティの設定

- エンティティ・オブジェクトへの一時属性および計算属性の追加

- ビジネス・イベントの作成

- エンティティ・オブジェクトのカスタムJavaクラスの生成

- エンティティ・オブジェクトおよびアソシエーションのプログラム的操作

- カスタム・データ・ソースおよびFramework Base Class ProgrammaticEntityImplを使用したプログラム的操作

- ドメインを使用したカスタム検証済データ型の作成

- 新規履歴タイプの作成

- PL/SQLパッケージAPIに基づくエンティティ・オブジェクト

- 結合ビューまたはリモートDBLinkに基づくエンティティ・オブジェクト

- ビジネス・ドメイン・レイヤーでの継承の使用

4.1 エンティティ・オブジェクトについて

エンティティ・オブジェクトは、指定したデータソース内の行を表し(一般に単一のデータベース表、ビューまたはシノニム)、関連付けられた属性の変更を簡略化するためのADFビジネス・コンポーネントです。重要なことは、エンティティ・オブジェクトを使用すると、ドメイン・ビジネス・ロジックをカプセル化できるため、ビジネス・ポリシーおよびビジネス・ルールを一貫性のある方法で検証できるということです。

4.1.1 エンティティ・オブジェクトのユースケースと例

エンティティ・オブジェクトは、データの有効性を強化するために様々な宣言的ビジネス・ロジック機能をサポートしています。通常、追加のカスタム・アプリケーション・ロジックおよびビジネス・ルールで宣言的な検証に補完することにより、各エンティティ・オブジェクトに最大の量のドメイン・ビジネス・ロジックを効率的にカプセル化します。関連付けられた一連のエンティティ・オブジェクトによって、複数のアプリケーションで活用できる再利用可能なビジネス・ドメインが形成されます。

エンティティ・オブジェクト(図4-1に示します)の主要な概念は次のとおりです。

- エンティティ・オブジェクトを定義するには、エンティティ・オブジェクトが示す行が含まれるデータベース表を指定します。

- エンティティ・オブジェクト間の関連を反映するアソシエーションを作成できます。

- 実行時には、エンティティ行はエンティティ定義オブジェクトによって管理されます。

- 各エンティティ行は、関連する行キーによって識別されます。

- エンティティ行は、データベース・トランザクションを提供するアプリケーション・モジュールのコンテキストで取得および変更します。

図4-1 エンティティ・オブジェクトによる表のビジネス・ロジックのカプセル化

4.1.2 エンティティ・オブジェクトの追加機能

エンティティ・オブジェクトで作業を開始する前に、その他のOracle ADF機能を理解しておくと役に立つ場合があります。次に、関連する他の機能へのリンクを示します。

- エンティティ・オブジェクトでの宣言的な検証を使用する方法の詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

4.2 エンティティ・オブジェクトおよびアソシエーションの作成

すでに使用しているデータベース・スキーマがある場合、エンティティ・オブジェクトおよびアソシエーションを作成する最も簡単な方法は、これらを既存の表からリバース・エンジニアリングする方法です。必要な場合には、エンティティ・オブジェクトを最初から作成し、後でこのエンティティ・オブジェクト用の表を生成することもできます。

4.2.1 既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法

1つ以上のエンティティ・オブジェクトを作成するには、「新規ギャラリ」で使用できる「表からのビジネス・コンポーネント」ウィザードを使用します。

始める前に:

エンティティ・オブジェクト作成用オプションに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

既存の表から1つ以上のエンティティ・オブジェクトおよびアソシエーションを作成するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「表からのビジネス・コンポーネント」を選択し、「OK」をクリックします。

これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。

3. 「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規データベース接続を作成します。」アイコンを選択して接続を作成します。「OK」をクリックします。

4. 「エンティティ・オブジェクト」ページで、次の操作を実行してエンティティ・オブジェクトを作成します。

- すべてのエンティティ・オブジェクトが作成されるパッケージ名を入力します。

- 「使用可能」リストからエンティティ・オブジェクトを作成する表を選択します。
「自動問合せ」チェック・ボックスを選択すると、使用可能な表のリストが即座に表示されます。必要に応じて、「名前フィルタ」フィールドで表名またはその一部を入力して、使用可能な表をリアルタイムでフィルタ処理できます。自動問合せ機能を使用するかわりに、「問合せ」ボタンをクリックしてオプションの表の名前フィルタに基づいてリストを取得することもできます。名前フィルタが入力されていない場合は、JDeveloperにより、選択したスキーマに対するすべての表オブジェクトが取得されます。

- 使用可能なデータベース・オブジェクトのうち、サブセットのみを表示する場合は、「フィルタ・タイプ」をクリックします。表、ビューまたはシノニムをフィルタ処理できます。

「使用可能」リストから表を選択した後、「選択済」リストに、この表について提案されるエンティティ・オブジェクト名とともに、関連する表名がカッコで囲まれて表示されます。

- 「選択済」リストでエンティティ・オブジェクト名を選択すると、「エンティティ名」フィールドを使用してデフォルトのエンティティ・オブジェクト名を変更できます。

ベスト・プラクティス

各エンティティ・オブジェクト・インスタンスは特定の表の単一行を表しているため、エンティティ・オブジェクトの名前には、複数形の名詞ではなく、単数形の名詞(Address、Order、Personなど)を使用してください。図4-2に、Summit ADFスキーマでS_COUNTRIES表を選択し、パッケージ名としてsummit.model.entitiesを設定し、エンティティ・オブジェクトの名前を単数形に変更した後のウィザード・ページを示します。

図4-2 表からのビジネス・コンポーネントの作成ウィザードの「エンティティ・オブジェクト」ページ

5. 目的の表オブジェクトとそれに対応するエンティティ・オブジェクトの名前を選択したら、「終了」をクリックします。

「アプリケーション」ウィンドウに指定したパッケージのエンティティ・オブジェクトが表示されます。

ベスト・プラクティス

アソシエーションを作成したら、エンティティ・オブジェクトとは別に表示および管理できるように、すべてのアソシエーションを別のパッケージに移動します。図4-3では、アソシエーションはサブパッケージ(assoc)に移動されているため、「アプリケーション」ウィンドウのentitiesパッケージには表示されません。詳細は、「アソシエーションの名前変更および別のパッケージへの移動方法」を参照してください。

図4-3 「アプリケーション」ウィンドウの新規エンティティ・オブジェクト

4.2.2 「エンティティの作成」ウィザードで単一のエンティティ・オブジェクトを作成する方法

単一のエンティティ・オブジェクトを作成するには、「新規ギャラリ」から使用可能なエンティティ・オブジェクト作成ウィザードを使用します。

注意:

エンティティ・オブジェクト作成ウィザードを使用すると、アソシエーションは生成されません。ただし、「表からのビジネス・コンポーネント」ウィザードを使用すると、アソシエーションは生成されますエンティティ・オブジェクトの作成ウィザードを使用して、エンティティ・オブジェクトを作成する場合、対応するアソシエーションを手動で作成する必要があります。

始める前に:

エンティティ・オブジェクト作成用オプションに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

単一のエンティティ・オブジェクトを作成するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「エンティティ・オブジェクト」を選択し、「OK」をクリックします。

これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。

3. 「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規」を選択して接続を作成します。「OK」をクリックします。

4. 「名前」ページで、次の操作を実行してエンティティ・オブジェクトを作成します。

- エンティティ・オブジェクトの名前を入力します。

- エンティティ・オブジェクトが作成されるパッケージ名を入力します。

- 「参照」(「スキーマ・オブジェクト」フィールドの横)をクリックし、エンティティ・オブジェクトを作成する表を選択します。
または、表を後で作成する場合は、現在使用されていない名前を入力できます。

5. 「スキーマ・オブジェクト」フィールドに表の名前を手動で入力する場合、ウィザードの「属性」ページで、各属性を定義する必要があります。「次へ」をクリックします。

「エンティティ・オブジェクトからのデータベース表の作成方法」で説明するように、この表は手動で作成または生成できます。

6. 目的の表オブジェクトとそれに対応するエンティティ・オブジェクトの名前の操作が完了したら、「終了」をクリックします。

4.2.3 既存の表からのエンティティ・オブジェクトおよびアソシエーション作成時の処理

既存の表からエンティティ・オブジェクトを作成する場合、最初に、次の情報を推測するためにデータ・ディクショナリからデータが取得されます。

- 表の列名に基づくJavaに適したエンティティ属性名(USER_ID→UserIdなど)

- 基礎となる列のデータ型に基づく各属性のSQLおよびJavaデータ型

- 各属性の長さと精度

- 主キーと一意キーの属性

- NOT NULL制約に基づく属性の必須フラグ

- 外部キーの制約に基づく新規エンティティ・オブジェクトとその他のエンティティ間の関連

注意:

エンティティ・オブジェクトはデータベース行を表しているため、エンティティ行と呼ぶのが自然です。または、エンティティ行は実行時にそのデータベース行のビジネス・ロジックをカプセル化するJavaオブジェクト・インスタンスであるため、エンティティ・インスタンスという、よりオブジェクト指向の呼び方も適しています。このため、これらの2つの用語は同義です。

JDeveloperは、宣言的設定を表すXMLドキュメント・ファイルを作成し、パッケージ名と対応するディレクトリに保存します。たとえば、Orderという名前のエンティティがgenericbcmodel.entitiesパッケージに含まれる場合、JDeveloperによりそのプロジェクトのソース・パスにgenericbcmodel/entities/Order.xmlというXMLファイルが作成されます。このXMLファイルには、表の名前、各エンティティ属性の名前とデータ型、および各属性の列名が含まれます。

概要エディタでオブジェクトを開き、「ソース」タブをクリックすると、エンティティ・オブジェクトのXML記述内容を検証できます。

注意:

IDEレベルのビジネス・コンポーネントのJava生成設定で指定されている場合、オプションのカスタム・エンティティ・オブジェクト・クラス(OrderImpl.javaなど)もウィザードで生成される場合があります。

4.2.3.1 エンティティ・オブジェクトが表から導入されたときに生成された外部キー・アソシエーション

エンティティ・オブジェクト以外に、エンティティ・オブジェクト間の関連に関する情報を取得する名前付きアソシエーション・コンポーネントも「表からのビジネス・コンポーネント」ウィザードにより生成されます。たとえば、図4-4のデータベース・ダイアグラムを参照すると、外部キー制約名をJavaに適した名前に変換してAssoc接尾辞を付けることにより、SItemOrdIdFkAssocなどのデフォルトのアソシエーション名がJDeveloperにより導出されることを確認できます。作成されたアソシエーションごとに、適切なXMLドキュメント・ファイルが作成され、パッケージ名と対応するディレクトリに保存されます。

注意:

「表からのビジネス・コンポーネント」ウィザードを使用すると、アソシエーションは生成されます。ただし、エンティティ・オブジェクト作成ウィザードでは、アソシエーションは生成されません。エンティティ・オブジェクトの作成ウィザードを使用して、エンティティ・オブジェクトを作成する場合、対応するアソシエーションを手動で作成する必要があります。

デフォルトでは、外部キーからリバース・エンジニアリングされたアソシエーションは、エンティティと同じパッケージ内に作成されます。たとえば、summit.model.entitiesパッケージ内にあるエンティティへのアソシエーションSItemOrdIdFkAssocに対しては、JDeveloperにより../summit/model/entities/SItemOrdIdFkAssoc.xmlという名前のアソシエーションXMLファイルが作成されます。

図4-4 外部キーによって関連付けられたS_ITEM表およびS_ORD表

4.2.3.2 表に主キーがないときに生成されるエンティティ・オブジェクト・キー

表に主キー制約がない場合、JDeveloperは、エンティティ・オブジェクトの主キーを推測できません。すべてのエンティティ・オブジェクトには少なくとも1つの属性が主キーとしてマークされている必要があるため、ウィザードでは、エンティティの主キーの一部としてすべての列がマークされています。必要な場合、後でエンティティ・オブジェクトを編集し、別の属性を主キーとしてマークし、その他の属性の設定を削除できます。エンティティ・オブジェクト作成ウィザードを使用する場合、その他の属性を主キーとして設定していないと、すべての列を主キーとして使用するよう求められます。

4.2.4 シノニムまたはビューのエンティティ・オブジェクトの作成時の処理

「表からのビジネス・コンポーネント」ウィザードまたはエンティティ・オブジェクトの作成ウィザードを使用してエンティティ・オブジェクトを作成する場合、オブジェクトは基礎となる表、シノニム、またはビューを表すことができます。フレームワークは、データ・ディクショナリ内のデータベースの主キーおよび外部キー制約を調べることにより、主キーおよび関連するアソシエーションを推測できます。

ただし、選択したスキーマ・オブジェクトがデータベース・ビューである場合、データベース・ビューにはデータベース制約がないため、主キーもアソシエーションも推測できません。この場合、「表からのビジネス・コンポーネント」ウィザードを使用すると、主キーはRowIDにデフォルト設定されます。エンティティ・オブジェクト作成ウィザードを使用する場合、少なくとも1つの属性を主キーとしてマークすることにより、主キーを手動で指定する必要があります。詳細は、「表に主キーがないときに生成される行識別子」を参照してください。

選択したスキーマ・オブジェクトがシノニムである場合、結果には2種類あります。シノニムが表のシノニムである場合、ウィザードおよびエディタは、表を指定した場合と同じように動作します。かわりに、シノニムがデータベース・ビューを参照している場合、ウィザードおよびエディタは、ビューを指定した場合と同じように動作します。

4.2.5 既存のエンティティ・オブジェクトまたはアソシエーションの編集方法

新しいエンティティ・オブジェクトまたはアソシエーションを作成した後、概要エディタでその設定を編集できます。エディタを起動するには、「アプリケーション」のエンティティ・オブジェクトまたはアソシエーションのポップアップ・メニューで「開く」を選択するか、オブジェクトをダブルクリックします。エディタの別のタブをクリックすることにより、オブジェクトを定義する設定や、その実行時の動作を制御する設定を調整できます。

4.2.6 エンティティ・オブジェクトからのデータベース表の作成方法

エンティティ・オブジェクトに基づいてデータベース表を作成するには、エンティティ・オブジェクトが含まれる「アプリケーション」ウィンドウでパッケージを右クリックし、ポップアップ・メニューから「データベース・オブジェクトの作成」を選択します。ダイアログが表示され、表の作成元のエンティティを選択できます。このツールを使用して、作成したエンティティ・オブジェクトの表を最初から生成することも、既存の表をドロップして再作成することもできます。

注意:

データベースに対して操作が直接実行され、既存の表がドロップされます。この機能では、後で実行するスクリプトは生成されません。作業に進む前に、この処理を実行するかどうかを確認するダイアログが表示されます。既存の表に基づくエンティティの場合、慎重に作業してください。

アソシエーションの概要エディタの「アソシエーション・プロパティ」ページにある「データベース・キー制約の使用」チェック・ボックスにより、エンティティ・オブジェクトの表の作成時に、関連する外部キー制約を生成するかどうかを制御します。このオプションを選択しても、実行時には影響しません。

4.2.7 データベース表の変更とエンティティを同期化する方法

すでにエンティティ・オブジェクトを作成した表も、自分で(またはDBAが)変更する必要がある場合があります。基礎となる表に属性が追加されても既存のエンティティに混乱が生じることはありませんが、Java EEアプリケーションで表内の新しい列にアクセスするには、エンティティ・オブジェクトをデータベース表と同期化する必要があります。

たとえば、SQL*Plusコマンド・プロンプトで次を実行し、新しいSECURITY_QUESTION列をPERSONS表に追加したとします。

ALTER TABLE PERSONS ADD (security_question VARCHAR2(60));

同期化機能を使用すると、エンティティ・オブジェクトに新規列を属性として追加できます。

始める前に:

エンティティ・オブジェクト作成用オプションに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

データベース表の変更とエンティティを同期化するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトを右クリックし、「データベースとの同期化」を選択します。

「データベースとの同期化」ダイアログに、ビジネス・ロジック層とデータベースの同期化に実行可能なアクションのリストが表示されます。

2. 実行するアクションを選択します。

- 選択した項目を同期化するには、リストからアクションを1つ以上選択し、「同期化」をクリックします。

- リスト内のすべてのアクションを実行するには、「すべて同期化」をクリックします。

- アクション・リストをテキスト・ファイルに保存するには、「保存」をクリックします。この機能では、変更内容を追跡できます。

3. 「OK」をクリックします。

4.2.7.1 ドロップされた列に関連付けられた属性の削除

同期化機能では、ドロップされた列は処理されません。エンティティ・オブジェクトの作成後に基礎となるデータベースから列がドロップされた場合は、対応する属性をエンティティ・オブジェクトから削除できます。属性がアプリケーションの他の部分で使用される場合は、それらの使用方法も削除する必要があります。

始める前に:

エンティティ・オブジェクト作成用オプションに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティ属性を削除するには:

1. 「アプリケーション」ウィンドウで、削除する属性を含むエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで属性を右クリックし、「削除」を選択します。

他の使用方法がある場合は、「削除の確認」ダイアログに「使用方法が見つかりました。」のメッセージが表示されます。

4. 使用方法が見つかった場合は、「使用方法の表示」をクリックします。

ダイアログに、属性のすべての使用方法が表示され、クリックするとソース・エディタで使用方法を表示できます。

5. 「プレビュー」をクリックすると「ログ」ウィンドウに属性の使用方法が表示され、リストで作業してエンティティ属性のすべての使用方法を削除できます。

4.2.7.2 基礎となる表でのデータ型の変更処理

同期化機能では、変更されたデータ型は処理されません。基礎となる表でのデータ型の変更(精度の向上など)では、属性のすべての使用方法を特定して、必要に応じて手動で変更する必要があります。

始める前に:

エンティティ・オブジェクト作成用オプションに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティ属性のすべての使用方法を特定するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで属性を右クリックし、「使用方法の検索」を選択します。

他の使用方法がある場合は、「ログ」ウィンドウに表示されます。

4.2.8 特定の時点に関するデータを格納する方法

特定の時点に関するデータセットを表示する場合は、有効日が指定された表が使用されます。有効日が指定された表は、次のような問合せを処理するHRMSやPayrollなどのアプリケーションで広く使用されています。

- 2005年8月31日現在の従業員への課税率はどの程度か。

- 2004年10月現在の従業員の給料はどの程度か。

この2つのいずれかについて、従業員のデータがそれ以降変更されている場合があります。

有効日が指定されたエンティティ・タイプと日付が指定されたエンティティ・タイプの主な違いは、日付が指定されたエンティティ・タイプでは、更新および削除中に行が分割されないことです。

注意:

マスター/ディテール関係の親エンティティ・オブジェクトで有効日を使用しないでください。子オブジェクトは親オブジェクトに対するイベントを呼び出すことができ、有効日が指定されたエンティティ・オブジェクトは更新および削除操作中に行が分割されるため、親と子が同じトランザクション中に更新されると、子オブジェクトは間違った親オブジェクトに対するイベントを呼び出す可能性があります。

有効日が指定されたエンティティ・オブジェクトを作成する場合は、エンティティを有効日指定として識別し、開始日と終了日を表すエンティティの属性を指定します。開始日と終了日の属性はDate型にする必要があります。

また、有効日が指定されたエンティティの順序を表す属性や、順序のフラグを表す属性を指定することもできます。これらの属性では、1日に行われた複数の変更を追跡できます。

始める前に:

エンティティ・オブジェクト作成用オプションに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

有効日が指定されたエンティティ・オブジェクトを作成するには

1. 「アプリケーション」ウィンドウで、有効日を使用可能にするエンティティ・オブジェクトをダブルクリックします。

2. 「プロパティ」ウィンドウで、「タイプ」カテゴリを開きます。

必要に応じて、「ウィンドウ」メニューから「プロパティ」を選択し、「プロパティ」ウィンドウを表示します。

「プロパティ」ウィンドウに「タイプ」カテゴリが表示されていない場合は、概要エディタの「一般」タブをクリックし、適切なフォーカスを設定します。

3. 「有効日タイプ」のプロパティ・メニューから、「編集」を選択します。

プロパティ・メニューを表示するには、プロパティ・フィールドの横の下矢印をクリックします。

4. 「プロパティの編集」ダイアログで、次の設定を指定します。

- 「有効日タイプ」で、EffectiveDatedを選択します。

- 「開始日属性」で、開始日に対応する属性を選択します。

- 「終了日属性」で、終了日に対応する属性を選択します。

5. 必要に応じて、1日に行われた複数の変更の追跡を可能にする属性を指定することもできます。

- 「有効日シーケンス」で、変更の順序を格納する属性を選択します。

- 「有効日シーケンス・フラグ」で、順序内の最新の変更を示すフラグを格納する属性を選択します。

「有効日シーケンス」属性と「有効日シーケンス・フラグ」属性を指定しない場合、有効日指定のデフォルトの粒度は1日になります。このため、1日に複数の変更を行うことはできなくなります。1日にエンティティを複数回更新しようとすると、例外がスローされます。これらの2つの属性を指定すると、フレームワークには、1日に行われた複数の変更の追跡に必要な値が挿入されて更新されます。

6. 「OK」をクリックします。

注意:

「プロパティ」ウィンドウを使用して、該当の属性に開始日と終了日の属性を指定することもできます。この場合は、概要エディタで該当の属性を選択し、「プロパティ」ウィンドウで「開始日」プロパティまたは「終了日」プロパティを「true」に設定します。

4.2.9 有効日が指定されたエンティティ・オブジェクトの作成時の処理

有効日が指定されたエンティティ・オブジェクトを作成すると、SysEffectiveDateと呼ばれる一時属性が作成され、行の有効日が格納されます。通常は、挿入、更新および削除の操作によって一時属性が変更されますが、ADFビジネス・コンポーネント・フレームワークでは、「有効日開始」と「有効日終了」で適切な値を決定します。

次の例は、有効日が指定されたエンティティを作成したときに生成されるサンプルのXMLエントリの一部を示しています。有効日が指定されたオブジェクトの使用方法の詳細は、「有効日付範囲を使用したビュー・オブジェクト行の制限」を参照してください。

// In the effective dated entity
<Entity
...
EffectiveDateType="EffectiveDated">

// In the attribute identified as the start date
<Attribute
...
IsEffectiveStartDate="true">

// In the attribute identified as the end date
<Attribute
...
IsEffectiveEndDate="true">

// The SysEffectiveDate transient attribute
<Attribute
Name="SysEffectiveDate"
IsQueriable="false"
IsPersistent="false"
ColumnName="$none$"
Type="oracle.jbo.domain.Date"
ColumnType="$none$"
SQLType="DATE"/>

4.2.10 表からのエンティティの作成に関する必知事項

「表からのビジネス・コンポーネント」ウィザードを使用すると、同時に多くのビジネス・コンポーネントを簡単に作成できます。とはいえ、単にこの処理が可能だという理由でこのウィザードを使用して、データベース・スキーマ内のすべての表についてエンティティ・オブジェクトを即座に作成する必要はありません。アプリケーションですべての表が必要な場合は、この方法が適しています。ただし、このウィザードは必要であればいつでも使用できるため、アプリケーションに必要なことがわかっている表についてエンティティ・オブジェクトを作成することをお薦めします。

「ネストされたアプリケーション・モジュールの定義」では、ビジネス・サービスのユースケース駆動型設計方法について説明されており、アプリケーションのビジネス・ロジックのニーズをサポートするために必要なエンティティ・オブジェクトを理解する上で役立ちます。エンティティ・オブジェクトは、必要に応じて後でいつでも追加できます。

4.3 アソシエーションの作成と構成

データベース表に外部キー制約が定義されていない場合、作成されたエンティティ・オブジェクト間のアソシエーションはJDeveloperにより推測されません。一部のADFビジネス・コンポーネント・ランタイム機能はエンティティ・アソシエーションが存在しているかどうかに依存するため、外部キーが存在しない場合は、エンティティ・アソシエーションを手動で作成することをお薦めします。

4.3.1 アソシエーションの作成方法

アソシエーションを作成するには、「新規ギャラリ」から使用できる新規アソシエーション作成ウィザードを使用します。

始める前に:

アソシエーションを作成する理由に関する知識が役立つ場合があります。詳細は、「アソシエーションの作成と構成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

アソシエーションを作成するには、次のようにします。

1. 「アプリケーション」ウィンドウで、アソシエーションを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択したら、「アソシエーション」を選択し、「OK」をクリックします。

3. 「アソシエーションの作成」ウィザードの「名前」ページで次のことを実行します。

- アソシエーションが作成されるパッケージ名を入力します。

- アソシエーション・コンポーネントの名前を入力します。

- 「次へ」をクリックします。

4. 「エンティティ・オブジェクト」ページで、ソースおよびリンク先のエンティティ属性を選択します。

- アソシエーションに含まれ、マスターとして機能するエンティティ・オブジェクトの1つからソース属性を選択します。

- アソシエーションに含まれるその他のエンティティ・オブジェクトから、対応するリンク属性を選択します。

たとえば、図4-5では、OrdEOエンティティ・オブジェクトからソース・エンティティ属性としてId属性が選択されています。ItemEOの各行には、これらの行を特定のOrdEO行に関連付けるオーダーIDが含まれるため、ItemEOエンティティ・オブジェクトでこのOrdId外部キー属性をリンク先属性として選択します。

図4-5 アソシエーション作成ウィザードにおける2つの定義済エンティティ・オブジェクトを関連付ける属性ペア

5. 「追加」をクリックし、対応する属性ペアを、下にあるソース属性とリンク先属性のペアの表に追加します。

デフォルトでは、ソース属性とリンク先属性の両方で「バインド済」チェックボックスが選択されています。このチェックボックスでは、(選択する側に応じて)ソース・エンティティからターゲット・エンティティ、またはターゲット・エンティティからソース・エンティティに移動する際に内部で作成されるアソシエーションSQL文に値をバインドするかどうかを指定できます。

値が定数であるためにエンティティを取得するためのアソシエーションSQL文に含めない一時エンティティ属性である関連内の属性のチェック・ボックスは、通常は選択を解除します。

6. アソシエーションを定義するために複数の属性ペアが必要な場合、これらのステップを繰り返し、ソース/ターゲット属性ペアをさらに追加できます。

7. 最後に、「カーディナリティ」ドロップダウンに表示されているアソシエーションのカーディナリティが正しいことを確認します。デフォルトは1対多関係です。「次へ」をクリックします。

たとえば、OrdEO行と対応するItemEO行間の関連は1対多であるため、デフォルト設定のままでかまいません。

8. 「アソシエーションSQL」ページで、ソース・エンティティ・オブジェクトの特定のインスタンスに関連するリンク先エンティティ・オブジェクトにアクセスするために実行時に使用するアソシエーションSQL述語をプレビューできます。

9. 一方向関連を表すアソシエーションを作成する場合は、「アソシエーション・プロパティ」ページで、ソース・エンティティ・オブジェクトまたはリンク先エンティティ・オブジェクトの「アクセッサの公開」チェック・ボックスの選択を解除します。ビジネス検証ロジックを作成する場合、双方向関連ナビゲーションの方が便利なため、通常これらのデフォルトのチェック・ボックス設定のままにしておきます。

たとえば、図4-6は、どちら側のエンティティ・オブジェクトも必要に応じて反対側の関連エンティティ行にアクセスできる双方向関係を表しています。つまり、この例では、OrdEOエンティティ・オブジェクトのインスタンスを操作している場合、関連するOrderItemEO行のコレクションに簡単にアクセスできます。また、OrderItemEOエンティティ・オブジェクトのインスタンスを使用して、これが属するOrderにも簡単にアクセスできます。

図4-6 アソシエーション・プロパティによる実行時の動作の制御

10. 目的のアソシエーションを定義したら、「終了」をクリックします。

4.3.2 アソシエーション作成時の処理

アソシエーションを作成すると、適切なXMLドキュメント・ファイルが作成され、パッケージ名と対応するディレクトリに保存されます。たとえば、oracle.summit.model.entities.assocサブパッケージ内にSItemOrderIdFkAssocという名前のアソシエーションを作成した場合、アソシエーションXMLファイルがSItemOrderIdFkAssoc.xmlという名前で../oracle/summit/model/entities/assocディレクトリに作成されます。実行時には、エンティティ・オブジェクトはこのアソシエーション情報を使用して、一連の関連エンティティの操作を自動化します。

4.3.3 エンティティ・アソシエーションのアクセッサ名の変更方法

「アソシエーション・プロパティ」ページのアクセッサ名のデフォルト設定について検討し、これらの名前をより直感的なものに変更した方が適切かどうかを決定する必要があります。このデフォルト設定により、実行時に関連の反対側のエンティティにプログラム的にアクセスするときに使用するアクセッサ属性の名前が定義されます。デフォルトでは、これらのアクセッサ名は、反対側のエンティティ・オブジェクトの名前になります。エンティティのアクセッサ名は、エンティティ・オブジェクト属性とその他のアクセッサ間で一意である必要があるため、1つのエンティティが複数の方法で別のエンティティに関連付けられている場合、デフォルトのアクセッサ名は、名前を一意にするために数値接尾辞を使用して変更されます。

既存のアソシエーションでは、「アソシエーション・プロパティ」ダイアログを使用してアクセッサの名前を変更できます。

始める前に:

アソシエーションを作成する理由に関する知識が役立つ場合があります。詳細は、「アソシエーションの作成と構成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

アソシエーション内のエンティティ・アクセッサの名前を変更するには:

1. 「アプリケーション」ウィンドウで、名前を変更するエンティティ・アソシエーションを含むアソシエーションをダブルクリックします。

2. 概要エディタで、「関連」ナビゲーション・タブをクリックします。

3. 「関連」ページで、「アクセッサ」カテゴリを開き、「編集」アイコンをクリックします。

「アソシエーション・プロパティ」ダイアログに、アソシエーションのアクセッサの現在の設定が表示されます。

4. 「アソシエーション・プロパティ」ダイアログで、必要に応じて名前を変更し、「OK」をクリックします。

4.3.4 アソシエーションの名前変更および別のパッケージへの移動方法

アソシエーションは、通常はプロジェクトの最初に構成し、それ以降はそれほど頻繁に変更しないコンポーネントであるため、アソシエーションを別のパッケージに移動し、エンティティ・オブジェクトを見やすくできます。

コンポーネントの名前変更と別のパッケージへの移動は両方とも、JDeveloperのリファクタ機能を使用して直接実行します。ただし、参照が失われるとアプリケーションが破壊されることがあるため、ADFビジネス・コンポーネント・オブジェクトの手動での名前の変更や移動はお薦めしません。JDeveloperのリファクタ機能の詳細は、「Fusion Webアプリケーションのリファクタ」を参照してください。

始める前に:

アソシエーションを作成する理由に関する知識が役立つ場合があります。詳細は、「アソシエーションの作成と構成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

別のパッケージにビジネス・コンポーネントのセットを移動するには:

1. 「アプリケーション」ウィンドウで、移動するコンポーネントを選択します。

2. 選択したコンポーネントを右クリックし、「リファクタ」→「移動」を選択します。

3. 「ビジネス・コンポーネントを移動」ダイアログで、コンポーネントを移動するパッケージの名前を入力するか、「参照」をクリックしてパッケージに移動して選択します。

4. 「OK」をクリックします。

コンポーネント名を変更する場合は、名前を変更するコンポーネントを右クリックし、「リファクタ」→「名前の変更」を選択します。ADFビジネス・コンポーネントをリファクタする場合、コンポーネントに関連するXMLファイルおよびJavaファイルがJDeveloperにより移動されるとともに、これらを参照するその他のコンポーネントが更新されます。

図4-7は、すべてのアソシエーションの名前を変更し、これらをoracle.summit.model.entities.assocサブパッケージに移動した後の「アプリケーション」ウィンドウの様子を示しています。任意のパッケージ名を選択してアソシエーションをリファクタすることにより、サブパッケージを使用してアソシエーションとエンティティとの論理的な関連を維持しながらアソシエーションのパッケージを閉じることができるため、「アプリケーション」ウィンドウに表示するファイルをより効率的に管理できます。

図4-7 アソシエーションのリファクタ後の「アプリケーション」ウィンドウ

4.3.5 アソシエーションでのカスタム・ビュー・オブジェクトの使用に関する必知事項

カスタム・ビュー・オブジェクトをエンティティ・アソシエーションのリンク元またはリンク先(あるいは両方)に関連付けることができます。

コード内でエンティティ・アソシエーションをトラバースするときに、エンティティがキャッシュにない場合は、ADFビジネス・コンポーネント・フレームワークによって問合せが実行され、エンティティ(複数可)がキャッシュに取り込まれます。デフォルトでは、エンティティをキャッシュに取り込むために実行される問合せは、主キーによる検索の問合せで、基礎となる表からすべての永続エンティティ属性の値を選択します。アプリケーションでプログラム的なエンティティ・アソシエーションのトラバースが多く実行される場合、すべての属性を取得することは、無理なユースケースになる場合があります。

エンティティ・アソシエーションでは、カスタムのエンティティ・ベースのビュー・オブジェクトをアソシエーション内のソース・エンティティまたは関連先エンティティ(あるいは両方)に関連付けることができます。指定するエンティティ・ベースのビュー・オブジェクトのプライマリ・エンティティ・オブジェクトの慣用名は、それを使用するアソシエーションの端のエンティティ・タイプに一致する必要があります。

カスタム・ビュー・オブジェクトの問合せには少ない列を含めることが可能で、ORDER BY句を含めることができるため、カスタム・ビュー・オブジェクトを使用する方が便利な場合があります。これにより、アソシエーションのトラバースによりエンティティがキャッシュに取り込まれる際に取得されるデータの量だけでなく、関連するエンティティのコレクションの順序も制御できます。

カスタム・ビュー・オブジェクトの作成の詳細は、「プログラムでエンティティ・ベースのビュー・オブジェクトを作成する方法」を参照してください。

4.3.6 コンポジット・アソシエーションに関する必知事項

アソシエーションは、Orderが参照するCustomerや、Orderに含まれるItemなどのエンティティ間の関連を表しています。アソシエーションを作成する場合、表現可能な関連の種類や様々なオプションについて理解していると役に立ちます。

エンティティ・オブジェクト間の関連を使用して、次のようなソース・エンティティの状態に応じて2つのスタイルの関連を表現できます。

- 関連先エンティティを参照している

- ネストされた論理的部分として関連先エンティティが含まれる

図4-8は、この2つのスタイルの関連を表すアプリケーション・ビジネス・レイヤーを示しています。たとえば、OrdEOエントリはCustomerEOを参照しています。これらの関連は、第一種のアソシエーションを示し、CustomerEOまたはOrdEOエンティティ・オブジェクトは互いに独立して存在できます。また、Orderを削除しても、これが参照していたCustomerがカスケード削除されることはありません。

一方、OrdEOと関連するItemEOディテールのコレクション間の関係は、単純な参照よりも強力です。ItemEOエントリは、OrdEO全体の論理部分を構成しています。つまり、OrdEOはItemEOエントリで構成されています。ItemEOエンティティ行にとって、OrdEOから独立して存在することは意味をなさず、(削除が許可されていて)OrdEOを削除する場合には、その構成部分もすべて削除する必要があります。このタイプの論理関係は、コンポジットと呼ばれる第二種のアソシエーションを示します。図4-8のUMLダイアグラムでは、アソシエーションで他方を構成する側に黒い菱形を使用して、より強力なコンポジット関連を示しています。

図4-8 ItemEOエントリで構成され、CustomerEOとPaymentTypeEOの両方を参照するOrdEO

「表からのビジネス・コンポーネント」ウィザードでは、ON DELETE CASCADEオプションを持つ外部キーに対してデフォルトでコンポジット・アソシエーションが作成されます。アソシエーション作成ウィザードまたはアソシエーションの概要エディタを使用すると、アソシエーションをコンポジット・アソシエーションとして指定できます。「アソシエーションの作成」ウィザードの「アソシエーション・プロパティ」ページ、または概要エディタの「関連」ページで、「コンポジット・アソシエーション」チェック・ボックスを選択します。

注意:

コンポジット・アソシエーションは、一時属性をベースに作成できません。

コンポジット・アソシエーションがある場合、エンティティ・オブジェクトには実行時に別の動作が追加されます。動作の制御設定については、「コンポジット動作の構成方法」を参照してください。

4.4 ビジネス・レイヤーのエンティティ・オブジェクトの図の作成

ビジネス・ドメイン・オブジェクトのレイヤーはチームにとって再使用可能な主要資産となるため、多くの場合、UMLモデルを使用して視覚化すると使いやすくなります。JDeveloperでは、自分やチームのメンバーが参照用として使用できるビジネス・ドメイン・レイヤーのダイアグラムを簡単に作成できるようサポートされています。

ビジネス・コンポーネントのUMLダイアグラムは、エンティティ・オブジェクトをダイアグラムにドロップしたときを示す静的な図のみではありません。むしろ、UMLダイアグラムは、現在のコンポーネント定義をUMLベースでレンダリングした図であるため、常に現在の状況を示しています。さらに、UMLダイアグラムは、視覚的なサポートとナビゲーションを提供するツールであるとともに、編集用のツールでもあります。ダイアグラムでエンティティ・オブジェクトについて概要エディタを開くには、目的のオブジェクトを右クリックして「開く」を選択します。また、エンティティ・オブジェクトおよびエンティティ属性の名前変更や属性の追加または削除など、エンティティ・オブジェクトの編集タスクをダイアグラム上で直接実行することもできます。ただし、ビジネス・コンポーネント・ダイアグラムでのエンティティ・オブジェクトへの変更は、基礎となるデータベース・オブジェクトには影響しません。

4.4.1 ビジネス・コンポーネント・ダイアグラムでのエンティティ・オブジェクトの表示方法

エンティティ・オブジェクトのダイアグラムを作成するには、「新規ギャラリ」から使用可能な「ビジネス・コンポーネント・ダイアグラムの作成」ダイアログを使用できます。

始める前に:

エンティティ・ダイアグラムがアプリケーションで使用される方法に関する知識が役立つ場合があります。詳細は、「ビジネス・レイヤーのエンティティ・オブジェクトの図の作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

既存のエンティティ・オブジェクトをモデル化するビジネス・コンポーネント・ダイアグラムを作成する手順

1. 「アプリケーション」ウィンドウで、エンティティ・ダイアグラムを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「ビジネス・コンポーネント・ダイアグラム」を選択し、「OK」をクリックします。

3. このダイアログで、次の操作を実行してダイアグラムを作成します。

- ダイアグラムの名前を入力します(Business Domain Objectsなど)。

- ダイアグラムが作成されるパッケージ名を入力します。たとえば、myproject.model.designなどのサブパッケージ内にダイアグラムを作成します。

4. 「OK」をクリックします。

5. 既存のエンティティ・オブジェクトをダイアグラムに追加するには、「アプリケーション」ウィンドウでこれらのオブジェクトを選択し、ダイアグラムにドロップします。

ダイアグラムを作成したら、「プロパティ」ウィンドウを使用してダイアグラムのビジュアル・プロパティを調整できます。たとえば、次の操作が可能です。

- パッケージ名の表示と非表示の切替え

- フォントの変更

- グリッドおよび改ページの切替え

- アソシエーション名の表示(表示しないと曖昧になる場合)

ダイアグラム上でポップアップ・メニューから「ダイアグラムの公開」を選択すると、ダイアグラムのイメージをPNG、JPG、SVGまたは圧縮されたSVG書式で作成することもできます。

図4-9は、ビジネス・ドメイン・レイヤーの様々なエンティティ・オブジェクトをモデル化したサンプル・ダイアグラムを示しています。

図4-9 ビジネス・ドメイン・レイヤーのUMLダイアグラム

4.4.2 エンティティ・ダイアグラム作成時の処理

ビジネス・コンポーネント・ダイアグラムを作成すると、ダイアグラムが格納されているパッケージ名と一致するプロジェクトのモデル・パスのサブディレクトリに、ダイアグラムを示すXMLファイル*.adfbc_diagramが作成されます。

デフォルトでは、「アプリケーション」ウィンドウによってプロジェクト・コンテンツ・パスの表示が統一され、ソース・パスのADFコンポーネントおよびJavaファイルがプロジェクト・モデル・パスのUMLモデル・アーティファクトと同じパッケージ・ツリーに表示されます。ただし、図4-10のように、「アプリケーション」ウィンドウの「アプリケーション・ウィンドウのオプション」ボタンを使用すると、必要に応じて、プロジェクト・コンテンツ・パスのルート・ディレクトリを個別に表示できます。

図4-10 個々のコンテンツ・パス・ディレクトリの表示の切替え

4.4.3 XMLコンポーネント・ディスクリプタに関する必知事項

エンティティ・オブジェクトなどのビジネス・コンポーネントをUMLダイアグラムに含めると、次の例のように、コンポーネントのXMLコンポーネント・ディスクリプタの<Data>セクションにメタデータが追加されます。この追加情報が使用されるのは設計時のみです。

<Entity Name="OrderEO" ... >
<Data>
<Property Name ="COMPLETE_LIBRARY" Value ="FALSE" />
<Property Name ="ID"
Value ="ff16fca0-0109-1000-80f2-8d9081ce706f::::EntityObject" />
<Property Name ="IS_ABSTRACT" Value ="FALSE" />
<Property Name ="IS_ACTIVE" Value ="FALSE" />
<Property Name ="IS_LEAF" Value ="FALSE" />
<Property Name ="IS_ROOT" Value ="FALSE" />
<Property Name ="VISIBILITY" Value ="PUBLIC" />
</Data>
:
</Entity>

4.4.4 コンポーネント名の変更に関する必知事項

エンティティ・ダイアグラムでは、エンティティ・オブジェクト、属性およびアソシエーションの名前を、わかりやすいものに変更できます。ダイアグラムの名前を変更しても基礎となるデータ名は変更されません。この名前の変更はダイアグラムでのみ保持されます。新しい名前には、読みやすくするために、スペースおよび大/小文字を含めることができます。実際のエンティティ・オブジェクト名、属性名またはアソシエーション名を変更する場合は、概要エディタでエンティティ・オブジェクトまたはアソシエーションを開きます。

4.5 プロパティ・セットの定義

プロパティ・セットとはプロパティの名前付きコレクションで、各プロパティが名前/値のペアとして定義されています。プロパティ・セットは、プロパティをグループ化し、それらを他のADFビジネス・コンポーネント・オブジェクトから参照するための便利なメカニズムです。プロパティ・セットは、エンティティ・オブジェクトとその属性、ビュー・オブジェクトとその属性、およびアプリケーション・モジュールで使用できます。

プロパティ・セットは、コントロール・ヒントやエラー・メッセージなど、様々な機能に使用できます。各プロパティ・セットには、コントロール・ヒントなどのカスタム・プロパティを含めることができ、それらを別のオブジェクトの複数の属性に関連付けることもできます。

プロパティ・セット内で定義されたプロパティは、翻訳可能に構成でき、そのようなケースでは、翻訳されたプロパティはプロパティ・セットが所有するメッセージ・バンドル・ファイルに格納されます。プロパティセットはスキーマ・ドリブンであるため、名前の追加以外に説明も追加できます。

翻訳可能なコンテンツを含むプロパティセットを定義する場合は、異なるコンテンツで共通の用語をオーバーロードしないようにしてください。ソース言語では複数のコンテンツで同じ用語にできる場合でも、コンテンツごとに区別できる用語を使用するようにしてください。たとえば、ある言語で「Name」という用語がオブジェクトと個人の両方に適用できるフィールド・ラベルとして使用されているが、ターゲット言語では2つの異なる用語に翻訳される場合があります。この場合、ソース言語の値が両方の「Name」になるような2つの名前/値ペアを提供します。その後、オブジェクト名はある用語で、個人名は別の用語でターゲット言語に翻訳すると、各用語を適切に翻訳できます。プロパティの説明を使用して用語ごとに個別のコンテキストを提供できます。

4.5.1 プロパティ・セットの定義方法

プロパティ・セットを定義するには、ダイアログを使用して新規のプロパティ・セットを作成し、「プロパティ」ウィンドウを使用してプロパティを指定します。

始める前に:

プロパティ・セットを使用できる方法に関する知識が役立つ場合があります。詳細は、「プロパティ・セットの定義」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

プロパティ・セットを定義するには:

1. 「アプリケーション」ウィンドウで、プロパティ・セットを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「プロパティ・セット」を選択し、「OK」をクリックします。

図4-11 「新規ギャラリ」の「プロパティ・セット」

3. 「プロパティ・セットの作成」ダイアログで、プロパティ・セットの名前および場所を入力し、「OK」をクリックします。

4. メイン・メニューから、「ウィンドウ」→「プロパティ」を選択します。

5. 「プロパティ」ウィンドウで、プロパティ・セットのプロパティを定義します。

4.5.2 プロパティ・セットの適用方法

プロパティ・セットを作成すると、プロパティ・セットをエンティティ・オブジェクトやエンティティ属性に適用できるだけでなく、定義されたプロパティを使用(必要に応じてオーバーライド)することもできます。

始める前に:

プロパティ・セットを使用できる方法に関する知識が役立つ場合があります。詳細は、「プロパティ・セットの定義」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティ・オブジェクトまたはビュー・オブジェクトにプロパティ・セットを適用するには:

1. 「アプリケーション」ウィンドウで、プロパティ・セットを適用するオブジェクト(エンティティ・オブジェクトまたはビュー・オブジェクト)をダブルクリックします。

2. 概要エディタの「一般」ナビゲーション・タブをクリックし、「プロパティ・セット」の横の「編集」アイコンをクリックします。

3. 「プロパティ・セット」ダイアログで、適切なプロパティ・セットを選択し、「OK」をクリックします。

プロパティ・セットを属性に適用するには:

1. 「アプリケーション」ウィンドウで、プロパティ・セットを適用する属性を含むオブジェクト(エンティティ・オブジェクトまたはビュー・オブジェクト)をダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックしてから、編集する属性を選択し、「詳細」タブをクリックします。

3. 「詳細」ページで、「プロパティ・セット」ドロップダウン・リストから適切なプロパティ・セットを選択します。

4.6 エンティティ・オブジェクトの属性のコントロール・ヒントの定義

コントロール・ヒントを使用すると、エンティティ・オブジェクト属性のラベル・テキスト、ツールチップおよびフォーマット・マスクのヒントを定義できます。必要に応じて、Groovy式を使用してUIヒントの値を計算できます。ビジネス・ドメイン・レイヤーで定義するUIヒントは、エンティティ・ベースのビュー・オブジェクトによっても継承されます。また、ビュー・オブジェクトやアプリケーション・モジュールでも同様にコントロール・ヒントを追加設定できます。

4.6.1 属性のコントロール・ヒントの追加方法

属性のコントロール・ヒントをエンティティ・オブジェクトに追加するには、概要エディタを使用します。

始める前に:

コントロール・ヒントがエンティティ・オブジェクトで使用される方法に関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトの属性のコントロール・ヒントの定義」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

属性のコントロール・ヒントをエンティティ・オブジェクトに追加するには:

1. 「アプリケーション」ウィンドウで、コントロール・ヒントを追加する属性が含まれているエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、編集する属性を選択します。

3. 「属性」ページで、「UIヒント」タブをクリックして、必要に応じてコントロール・ヒントを指定します。

例として、図4-12は、PaymentOptionEOエンティティ・オブジェクトの属性ExpireDateに定義されたコントロール・ヒントを示しています。定義されるヒントは、次のとおりです。

- フォーマットの種類: Simple Date

- 「フォーマット」マスク: mm/yy

図4-12 概要エディタ、「属性」ページ、「UIヒント」タブ

4. Groovy式を使用してUIヒントを定義する場合は、テキスト・ボックスの横の矢印をクリックし、「式の表示」を選択します。「新規式メソッド。」ハイパーリンクが表示されます。このハイパーリンクをクリックすると、「式エディタの編集」が表示されます。このエディタ内にGroovy式を入力し、「OK」をクリックします。

注意:

Javaで定義される数値および日付のフォーマット・マスクの標準セットは、OracleデータベースのSQLおよびPL/SQL言語によって使用されるものとは異なります。詳細は、java.text.DecimalFormatおよびjava.text.SimpleDateFormatクラスのJavadocを参照してください。

4.6.2 属性のコントロール・ヒント追加時の処理

エンティティ・オブジェクトの属性のコントロール・ヒントを定義すると、これらを格納するリソース・バンドル・ファイルが作成されます。定義したヒントは、関連付けられたビュー・クライアントにおいて生成されたフォームおよび表によって使用できます。ファイルのタイプとその粒度は、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」オプションで指定します。詳細は、「リソース・バンドルの使用」を参照してください。

4.6.3 フォーマッタとマスクについて

(「UIヒント」タブで)属性(たとえば、Simple Date)の「フォーマット・タイプ」コントロール・ヒントを設定する場合、この属性にフォーマット・マスクも指定して、UIでの値の表示方法をカスタマイズできます。使用するマスクが「フォーマット」ドロップダウン・リストに表示されない場合は、フィールドに直接入力できます。

すべてのフォーマッタがフォーマット・マスクを必要とするわけではありません。フォーマット・マスクは、フォーマッタ・タイプによって必要とされる場合にのみ指定が必要です。たとえば、日付フォーマッタにはフォーマット・マスクが必要ですが、通貨フォーマッタには必要ありません。実際、通貨フォーマッタではフォーマット・マスクはサポートされていません。

使用できるマスク要素は、関連するJavaフォーマット・クラスで定義されています。Simple Dateフォーマット・タイプのマスク要素の詳細は、Javadocのjava.text.SimpleDateFormatを参照してください。Numberフォーマット・タイプのマスク要素の詳細は、Javadocのjava.text.DecimalFormatを参照してください。

コントロール・ヒントで使用するために、フォーマッタをドメインにマッピングする場合、oracle.jbo.formatパッケージで提供されているデフォルト・フォーマッタの1つを修正するか、oracle.jbo.format.Formatterクラスを拡張して新しいフォーマッタ・クラスを作成できます。JDeveloperに用意されているデフォルトのフォーマッタは、java.textパッケージで提供されているフォーマッタを集約したものです。

フォーマット・マスクを定義してJDeveloperの「UIヒント」タブから使用する方法の詳細は、「フォーマット・マスクの定義方法」を参照してください。

4.6.4 フォーマット・マスクの定義方法

今後繰り返し使用するフォーマット・マスクがある場合は、「UIヒント」タブの「フォーマット」ドロップダウン・リストで利用できるように、formatinfo.xmlファイルに追加できます。このファイルのエントリでは、ドメイン・クラスのフォーマット・マスクおよびフォーマッタ・クラスを定義します。次の例は、java.util.Dateドメインのフォーマット定義を示しています。

<?xml version="1.0"?><FORMATTERS>
. . .
<DOMAIN CLASS="java.util.Date">
<FORMATTER name="Simple Date" class="oracle.jbo.format.DefaultDateFormatter">
<FORMAT text="yyyy-MM-dd" />
<FORMAT text="EEE, MMM d, ''yy"  />
<FORMAT text="dd-MM-yy" />
<FORMAT text="dd-MMM-yyyy" />
<FORMAT text="dd/MMM/yyyy" />
</FORMATTER>
</DOMAIN>
. . .
</FORMATTERS>

formatinfo.xmlファイルは、JDeveloperシステム・ディレクトリのBC4Jサブディレクトリにあります(たとえば、C:\Documents and Settings\username\Application Data\JDeveloper\system##\o.BC4J\formatinfo.xmlです)。

フォーマット・マスクの定義は、フォーマッタおよびドメイン・クラスに属し、「UIヒント」タブに表示されるマスクのテキスト指定が含まれています。特定のタイプの属性(DOMAIN CLASS)にフォーマット・タイプ(FORMATTER name)を指定すると、「フォーマット」ドロップダウン・リストにマスク(FORMAT text)が表示されます。

フォーマッタをマッピングする上で新規のドメインを作成する必要はありません。ビジネス・コンポーネント・プロジェクトに、フォーマッタと同じデータ型のドメインが含まれている場合は、既存のドメインを使用できます。

始める前に:

コントロール・ヒントがエンティティ・オブジェクトで使用される方法に関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトの属性のコントロール・ヒントの定義」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

新しいマスクをJDeveloperで使用できるようにする手順は次のとおりです。

1. テキスト・エディタでformatinfo.xmlファイルを開きます。

2. フォーマット・マスクを追加するドメイン・クラスとフォーマッタ名を探します。

3. FORMATTER要素内に新しいFORMATエントリを挿入します。

フォーマット・マスクの新しいドメインを作成する場合は、フォーマッタのXML定義に、FORMATTER (名前とクラスを含む)およびフォーマッタ・クラスで指定するFORMAT定義のリストに加えて新しいDOMAIN CLASSを含める必要があります。

フォーマット・マスクを定義したら、「UIヒント」タブの「フォーマット」ドロップダウン・リストから新しいフォーマット・マスクを選択できます。

4.7 リソース・バンドルの使用

翻訳可能な文字列(バリデータ・エラー・メッセージや、エンティティ・オブジェクトまたはビュー・オブジェクトの属性コントロール・ヒントなど)を定義する場合、デフォルトでは、プロジェクト・レベルのリソース・バンドル・ファイルが作成され、そこに翻訳可能文字列が格納されます。たとえば、Modelプロジェクトでエンティティ・オブジェクトのコントロール・ヒントを定義すると、パッケージには、ModelBundle.xxxという名前のメッセージ・バンドル・ファイルが作成されます。定義したヒントは、関連付けられたビュー・クライアントにおいて生成されたフォームおよび表によって使用できます。

JDeveloperで使用されるリソース・バンドルのオプションは、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページのオプションで指定します。このオプションは、デフォルトで「プロパティ・バンドル」に設定され、.propertiesファイルが生成されます。このオプションおよびその他のリソース・バンドル・オプションの詳細は、「メッセージ・バンドル・オプションの設定方法」を参照してください。

「アプリケーション」ウィンドウでオブジェクトを選択し、「構造」ウィンドウの対応する「ソース 」ノードを参照して、エンティティ・オブジェクトのメッセージ・バンドル・ファイルを検証できます。「構造」ウィンドウには、「アプリケーション」ウィンドウで選択したコンポーネントの実装ファイルが表示されます。

次の例は、コントロール・ヒントの情報が表示されたメッセージ・バンドル・ファイルのサンプルを示しています。各String配列の最初のエントリはメッセージ・キーで、2番目のエントリはこのキーに対応するロケール固有のString値です。

oracle.summit.model.views.ItemVO.QuantityShipped_LABEL=Shipped
oracle.summit.model.views.ItemVO.ItemTotal_LABEL=Item Total
oracle.summit.model.views.ItemVO.ItemTotal_FMT_FORMATTER=oracle.jbo.format.DefaultCurrencyFormatter
oracle.summit.model.views.ItemVO.Price_FMT_FORMATTER=oracle.jbo.format.DefaultCurrencyFormatter
oracle.summit.model.views.OrdVO.DateOrdered_FMT_FORMATTER=oracle.jbo.format.DefaultDateFormatter
oracle.summit.model.views.OrdVO.DateOrdered_FMT_FORMAT=dd-MM-yyyy
oracle.summit.model.views.OrdVO.DateShipped_FMT_FORMATTER=oracle.jbo.format.DefaultDateFormatter
oracle.summit.model.views.OrdVO.DateShipped_FMT_FORMAT=dd-MM-yyyy
oracle.summit.model.entities.OrdEO_Rule_0=You cannot have a shipping date that is before the order date
oracle.summit.model.entities.OrdEO.CustomerId_Rule_0=This is an invalid customer id
errorId=This customer must pay cash
oracle.summit.model.entities.ItemEO.ProductId_Rule_0=Invalid Product Id
oracle.summit.model.views.OrdVO.Total_LABEL=Order Total
oracle.summit.model.views.OrdVO.Total_FMT_FORMATTER=oracle.jbo.format.DefaultCurrencyFormatter
oracle.summit.model.views.OrdVO.OrderFilled_LABEL=Order Filled
. . .

4.7.1 メッセージ・バンドル・オプションの設定方法

JDeveloperでコントロール・ヒントおよびその他の翻訳可能文字列の保存に使用されるリソース・バンドル・オプションは、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページのオプションで指定します。このオプションは、デフォルトで「プロパティ・バンドル」に設定され、.propertiesファイルが生成されます。

始める前に:

リソース・バンドルが使用される方法に関する知識が役立つ場合があります。詳細は、「リソース・バンドルの使用」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

プロジェクトのリソース・バンドル・オプションを設定するには:

1. 「アプリケーション」ウィンドウで、リソース・バンドル・オプションを指定するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「リソース・バンドル」をクリックします。

3. 「リソース・バンドル」ページで、プロジェクトまたはカスタム設定のいずれを使用するかを指定します。

「カスタム設定を使用」を選択すると、現在のプロジェクトの作業のみに設定が適用されます。これらの設定はセッション間で保存されますが、プロジェクトには記録されないため、他のユーザーとは共有できません。「プロジェクト設定を使用」を選択すると、選択内容がプロジェクトに記録され、プロジェクトを使用する他のユーザーと共有できます。

4. 次のオプションを選択または宣言して、設定を指定します。

- バンドルの自動同期化

- ハードコード化された変換可能な文字列に関して警告

- 常に説明の入力を要求

これらのオプションの詳細は、「ヘルプ」をクリックしてオンライン・ヘルプを参照してください。

5. リソース・バンドルの粒度を選択します。

- 1プロジェクト当たり1バンドル(デフォルト)

- 1ファイル当たり1バンドル

- 複数の共有バンドル(ADFビジネス・コンポーネントでは使用不可)

6. 使用するファイルのタイプを選択します。

- リスト・リソース・バンドル
ListResourceBundleクラスは、名前/値の配列でリソースを管理します。各ListResourceBundleクラスは、Javaクラス・ファイルに格納されます。ListResourceBundleクラスには、ロケール固有のオブジェクトを格納できます。

- プロパティ・バンドル(デフォルト)
翻訳可能なテキストを名前/値のペアで格納するテキスト・ファイルです。プロパティ・ファイル(「メッセージ・バンドル・オプションの設定方法」に示すようなファイル)には、Stringオブジェクトのみに対応する値を格納できます。他のタイプのオブジェクトを格納する必要がある場合は、かわりにListResourceBundleを使用する必要があります。

- Xliffリソース・バンドル
XML Localization Interchange File Format (XLIFF)は、ローカリゼーション・データの交換に対応したXMLベースのフォーマットです。

7. 「OK」をクリックします。

4.7.2 複数のリソース・バンドルの使用方法

翻訳可能な文字列(属性コントロール・ヒントなど)を定義する場合は、「テキスト・リソースの選択」ダイアログで新しい文字列を入力したり、オブジェクトのデフォルトのリソース・バンドルで定義済の文字列を選択できます。必要に応じて、異なるリソース・バンドルを使用することもできます。これは、プロジェクト間で共有される共通のリソース・バンドルを使用する場合に便利です。

始める前に:

リソース・バンドルが使用される方法に関する知識が役立つ場合があります。詳細は、「リソース・バンドルの使用」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

デフォルト以外のリソース・バンドルの設定を使用するには:

1. 「テキスト・リソースの選択」ダイアログで、使用するバンドルを「リソース・バンドル」ドロップダウン・リストから選択します。

目的のリソース・バンドルが「リソース・バンドル」ドロップダウン・リストにない場合は、「参照」アイコンをクリックして、使用するリソース・バンドルを検索して選択します。

ダイアログには、選択したリソース・バンドルで現在定義されている文字列が表示されます。

2. 既存の文字列を選択し、「選択」をクリックするか、新しい文字列を入力して「保存して選択」をクリックします。

新しい文字列を入力すると、選択したリソース・バンドルに書き込まれます。

4.7.3 日付フォーマットの国際化方法

ADFビジネス・コンポーネントを使用して作成したアプリケーションのモデル・レイヤーを国際化するには、各コンポーネントのメッセージ・バンドル・ファイルの翻訳バージョンを生成する必要があります。たとえば、OrdersImplMsgBundleメッセージ・バンドルのイタリア語バージョンは、OrdersImplMsgBundle_itという名前のクラスになり、さらに限定されたスイス・イタリア語バージョンは、OrdersImplMsgBundle_it_chという名前になります。通常は、これらのクラスによってベース・メッセージ・バンドル・クラスが拡張され、これらのクラスにローカライズが必要なメッセージ・キーのエントリとともにローカライズされたこれらの翻訳が含まれます。

次の例は、エンティティ・オブジェクトのメッセージ・バンドルのイタリア語バージョンを示しています。このイタリア語バージョンでは、RequestDateおよびAssignedDateのフォーマット・マスクがdd/MM/yyyy HH:mmに変更されています。これにより、イタリア語のユーザーには、2006年5月3日の日付値は、デフォルトのメッセージ・バンドルのフォーマット・マスクで生成される05/03/2006 15:55ではなく03/05/2006 15:55として表示されます。オーバーライドされたgetContents()メソッドに注意してください。これは、スーパークラス・バンドルからオーバーライドされていない文字列にマージされた、より限定された翻訳文字列によるメッセージ配列を戻します。実行時には、現在のユーザーのロケール設定に基づいて適切なメッセージ・バンドルが自動的に使用されます。

package oracle.summit.model;
import oracle.jbo.common.JboResourceBundle;
public class ModelImplMsgBundle_it
extends ModelImplMsgBundle {
static final Object[][] sMessageStrings = {
{ "AssignedDate_FMT_FORMAT", "dd/MM/yyyy HH:mm" },
{ "AssignedDate_LABEL", "Assegnato il" },
{ "AssignedTo_LABEL", "Assegnato a" },
{ "CreatedBy_LABEL", "Aperto da" },
{ "ProblemDescription_LABEL", "Problema" },
{ "RequestDate_FMT_FORMAT", "dd/MM/yyyy HH:mm" },
{ "RequestDate_LABEL", "Aperto il" },
{ "RequestDate_TOOLTIP", "La data in cui il ticket è stato aperto" },
{ "Status_LABEL", "Stato" },
{ "SvrId_LABEL", "Ticket" }
};
public Object[][] getContents() {    return super.getMergedArray(sMessageStrings, super.getContents());  }
}

4.8 ビジネス・ロジック・グループの定義

ビジネス・ロジック・グループでは、関連するコントロール・ヒント、デフォルト値および検証ロジックをカプセル化できます。ビジネス・ロジック・グループは、ベース・エンティティとは別に独自のファイルに保存され、現在の行のコンテンツ値に基づいて動的に有効にできます。

これは、ロケールごとの専門チームによって管理される多数のロケール固有の検証(国別識別子や税法チェックなど)が定義されるHRアプリケーションなどで有効です。ビジネス・ロジック・グループでは、これらの検証を個別のファイルに格納するため管理が容易になり、必要時にのみロードすることでパフォーマンスが最適化されます。

各ビジネス・ロジック・グループには、ビジネス・ロジック・ユニットのセットが格納されます。各ユニットでは、ビジネス・ロジック・グループに関連付けられた属性値に基づいて、エンティティでロードされるビジネス・ロジックのセットを識別します。

たとえば、Employeeエンティティ・オブジェクトにビジネス・ロジック・グループを定義し、EmpRegion属性を識別子として指定できます。次に、リージョンごとにビジネス・ロジック・ユニットを定義し、各リージョンで従業員の給与に範囲バリデータを指定します。Employeeエンティティから行がロードされると、(EmpRegion属性の値に基づいて)EmpSalary属性の適切なバリデータがロードされます。

別の例をあげると、Ordersエンティティ・オブジェクトは識別子属性としてOrderFilledを使用するFilledOrderGroupと呼ばれるビジネス・ロジック・グループを持ちます。この属性には2つの有効な値(NおよびY)があるため、対応するビジネス・ロジック・ユニットが2つあります。

このシナリオでは、各ビジネス・ロジック・ユニットにはそのユーザー・タイプのみに関連する新規または修正済ビジネス・ロジックが含まれます。

- Orders_FilledOrderGroup_Nビジネス・ロジック・ユニットには、まだ入力されていない注文に関連するロジックが含まれます。たとえば、DateShipped属性を非表示にするように構成できます。

- Orders_FilledOrderGroup_Yビジネス・ロジック・ユニットには、入力されている注文に関連するロジックが含まれます。たとえば、DateShipped属性を表示するように構成できます。

4.8.1 ビジネス・ロジック・グループの作成方法

エンティティ・オブジェクトのビジネス・ロジック・グループは、概要エディタから作成します。

始める前に:

ビジネス・ロジック・グループが使用される方法に関する知識が役立つ場合があります。詳細は、「ビジネス・ロジック・グループの定義」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

ビジネス・ロジック・グループを作成するには:

1. 「アプリケーション」ウィンドウで、ビジネス・ロジック・グループを作成するエンティティをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

3. 「一般」ページで、「ビジネス・ロジック・グループ」セクションを拡張し、「追加」アイコンをクリックします。

4. 作成ダイアログで、適切なグループ識別子属性を選択し、グループの名前を指定します。

ヒント:

コードの可読性を高めるには、識別子を反映するようなグループ名にします。たとえば、グループ識別子属性がOrderFilledの場合は、ビジネス・ロジック・グループの名前をFilledOrderGroupにします。

5. 「OK」をクリックします。

新しいビジネス・ロジック・グループが概要エディタの表に追加されます。グループを作成すると、ビジネス・ロジック・ユニットを追加できます。

4.8.2 ビジネス・ロジック・ユニットの作成方法

ビジネス・ロジック。ユニットは「新規ギャラリ」から作成できます。また、ビジネス・ロジック・グループを格納するエンティティのポップアップ・メニューから直接作成することもできます。

始める前に:

ビジネス・ロジック・グループが使用される方法に関する知識が役立つ場合があります。詳細は、「ビジネス・ロジック・グループの定義」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

ビジネス・ロジック・ユニットを作成するには:

1. 「アプリケーション」ウィンドウで、ビジネス・ロジック・グループを格納するエンティティ・オブジェクトを右クリックし、新規エンティティ・ビジネス・ロジック・ユニットを選択します。

2. 「ビジネス・ロジック・ユニットの作成」ダイアログで、ベース・エンティティの名前を指定し、適切なビジネス・ロジック・グループを選択します。

3. ビジネス・ロジック・ユニットの名前を入力します。

各ビジネス・ロジック・ユニットの名前には、このビジネス・ロジック・グループに関連付けられているグループ識別子属性の有効値を反映する必要があります。たとえば、グループ識別子属性がOrderFilledの場合、YのOrderFilled値に関連付けられているビジネス・ロジック・ユニットの名前はYにする必要があります。

4. ビジネス・ロジック・ユニットのパッケージを指定します。

注意:

ビジネス・ロジック・ユニットのパッケージは、ベース・エンティティまたはビジネス・ロジック・グループのパッケージと同じにする必要はありません。これにより、コア・アプリケーションと別にビジネス・ロジック・ユニットを開発して配信できます。

5. 「OK」をクリックします。

JDeveloperでは、概要エディタでビジネス・ロジック・ユニットを作成して開きます。「アプリケーション」ウィンドウのビジネス・ロジック・ユニットに表示される名前は、EntityName_BusLogicGroupName_BusLogicUnitNameの形式で、エンティティ・オブジェクトの名前とビジネス・ロジック・グループが含まれます。たとえば、Ordersエンティティ・オブジェクトのFilledOrderGroupビジネス・ロジック・グループにYという名前でビジネス・ロジック・ユニットを作成する場合、表示されるビジネス・ロジック・ユニット名はOrders_FilledOrderGroup_Yになります。

ビジネス・ロジック・ユニットを作成すると、そのビジネス・ロジック・ユニットに対してビジネス・ロジックを再定義できます。

4.8.3 ビジネス・ロジック・ユニットへのロジックの追加方法

ビジネス・ロジック・ユニットを作成したら、これを概要エディタで開き、ベース・エンティティで行う場合(エンティティレベルのバリデータを追加するなど)と同様に、ビジネス・ロジックを追加できます。

始める前に:

ビジネス・ロジック・グループが使用される方法に関する知識が役立つ場合があります。詳細は、「ビジネス・ロジック・グループの定義」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

ビジネス・ロジック・ユニットにエンティティ・バリデータを追加するには:

1. 「アプリケーション」ウィンドウで、エンティティ・バリデータを追加するビジネス・ロジック・ユニットをダブルクリックします。

2. 概要エディタで、「ビジネス・ルール」ナビゲーション・タブをクリックします。

3. 「ビジネス・ルール」ページで、「エンティティ・バリデータ」ノードを選択し、「追加」アイコンをクリックします。

4. 「検証ルールの追加」ダイアログで、検証ルールを定義し、「OK」をクリックします。

4.8.4 ビジネス・ロジック・ユニットの属性のオーバーライド方法

概要エディタでビジネス・ロジック・ユニットの「属性」ページを表示すると、属性表の「拡張」列に、属性がビジネス・ロジック・ユニットで拡張されていることが表示されます。拡張属性は、ビジネス・ロジック・ユニットではなく、ベース・エンティティでのみ編集できます。ベース・エンティティではなくビジネス・ロジック・ユニットで変更する場合は、編集する前に、ビジネス・ロジック・ユニットで属性をオーバーライド済として定義する必要があります。

始める前に:

ビジネス・ロジック・グループが使用される方法に関する知識が役立つ場合があります。詳細は、「ビジネス・ロジック・グループの定義」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

ビジネス・ロジック・ユニットの属性をオーバーライドするには:

1. 「アプリケーション」ウィンドウで、オーバーライドする属性を含むビジネス・ロジック・ユニットをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、目的の属性を選択し、 「オーバーライド」ボタンをクリックします。

属性をオーバーライドしたら、次の表にあるタブで通常どおりに属性を編集できます。オーバーライドされた属性では、コントロール・ヒント、バリデータおよびデフォルト値の編集のみ行えます。

4.8.5 ビジネス・ロジック・グループの作成時の処理

ビジネス・ロジック・グループを作成すると、次のようにベース・エンティティのXMLファイルのグループに参照が追加されます。

<BusLogicGroup
Name="FilledOrderGroup"
DiscrAttrName="OrderFilled"/>

ビジネス・ロジック・ユニットを作成すると、エンティティ・オブジェクトのXMLファイルと同様のXMLファイルが生成されます。次の例は、ビジネス・ロジック・ユニットのXMLコードを示しています。

注意:

ビジネス・ロジック・ユニットのパッケージは、ベース・エンティティまたはビジネス・ロジック・グループのパッケージと同じにする必要はありません。これにより、コア・アプリケーションと別にビジネス・ロジック・ユニットを開発して配信できます。

<Entity
xmlns="http://xmlns.oracle.com/bc4j"
Name="Orders_FilledOrderGroup_N"
Version="12.1.2.66.11"
Extends="oracle.summit.model.buslogic.Orders"
InheritPersonalization="merge"
DBObjectType="table"
DBObjectName="S_ORD"
BindingStyle="OracleName"
BusLogicGroupName="FilledOrderGroup"
BusLogicUnitName="N">
<Attribute
Name="Total"
Precision="11"
Scale="2"
ColumnName="TOTAL"
SQLType="NUMERIC"
Type="java.math.BigDecimal"
ColumnType="NUMBER"
TableName="S_ORD">
<DesignTime>
<Attr Name="_OverrideAttr" Value="true"/>
</DesignTime>
<Properties>
<SchemaBasedProperties>
<LABEL
ResId="oracle.summit.model.buslogic.Orders_FilledOrderGroup_N.Total_LABEL"/>
</SchemaBasedProperties>
</Properties>
</Attribute>
<Attribute
Name="DateShipped"
ColumnName="DATE_SHIPPED"
SQLType="DATE"
Type="java.sql.Date"
ColumnType="DATE"
TableName="S_ORD">
<DesignTime>
<Attr Name="_OverrideAttr" Value="true"/>
</DesignTime>
<Properties>
<SchemaBasedProperties>
<DISPLAYHINT
Value="Hide"/>
</SchemaBasedProperties>
</Properties>
</Attribute>
<ResourceBundle>
<PropertiesBundle
PropertiesFile="oracle.summit.model.ModelBundle"/>
</ResourceBundle>
</Entity>

4.8.6 実行時の処理: ビジネス・ロジック・グループの呼出し方法

実行時にアプリケーションで行がロードされると、適用するビジネス・ロジック・ユニットがエンティティ・オブジェクトによって決定されます。

ベース・エンティティには、ビジネス・ロジック・グループのリストが格納されています。各グループは、エンティティの属性値を参照し、この値によってそれぞれのグループにロードするビジネス・ロジック・ユニットが決定されます。この評価は、ロードされる行ごとに実行されます。

ロードするビジネス・ロジック・ユニットを決定するロジックが簡単な属性値ではなく複雑な場合は、エンティティ・オブジェクトに一時属性を作成し、Groovy式を使用して一時属性の値を指定できます。

4.9 宣言的な実行時動作の構成

エンティティ・オブジェクトには、通常のエンタープライズ・ビジネス・アプリケーションの実装を簡略化するための様々な宣言的機能が用意されています。タスクによっては、宣言的機能のみでニーズが満たされる場合があります。エンティティ・オブジェクトの基本的な永続機能を記述する宣言的なランタイム機能はこの項で説明しますが、宣言的な検証およびビジネス・ルールについては、「検証とビジネス・ルールの宣言的な定義」で説明します。

注意:

必要に応じて、宣言的動作を超えて、より複雑なビジネス・ロジックまたは検証規則をビジネス・ドメイン・レイヤーに実装することができます。カスタム・コードを使用した最も一般的なエンティティ・オブジェクトの拡張方法は、「プログラムによる検証とビジネス・ルールの実装」を参照してください。

またアプリケーションを開発する際の注意点として、プログラム的または宣言的にビジネス・ロジックを実装する場合、エンティティ・オブジェクトまたはビュー行の属性が特定の順序に従って設定されることを想定しないようにすることが重要です。順序が想定されていると、それとは異なる順序でエンド・ユーザーが属性値を入力した場合に問題が発生します。

4.9.1 宣言的な実行時動作の構成方法

エンティティ・オブジェクトの宣言的な実行時動作を構成するには、概要エディタを使用します。

始める前に:

実行時動作の宣言的な構成に関する知識が役立つ場合があります。詳細は、「宣言的な実行時動作の構成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティ・オブジェクトの宣言的な実行時動作を構成するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックしてエンティティ・オブジェクトの名前およびパッケージを表示し、関連付けられたスキーマ、代替キー、カスタム・プロパティおよびセキュリティなど、オブジェクトのエンティティ・レベルでの様々な構成を行います。

- 「代替キー」セクションでは、代替主キーとして機能できる、データベースにマッピングされたエンティティ・オブジェクト属性を選択できます。代替キーの詳細は、「代替キー値の定義方法」を参照してください。

- 「チューニング」セクションでは、単一のトランザクションで同じタイプの複数のエンティティを作成、変更または削除するときのデータベース操作をより効率的にするためのオプションを設定できます。詳細は、「バッチ更新の使用方法」を参照してください。

- 「カスタム・プロパティ」セクションでは、実行時にエンティティでアクセス可能なカスタム・メタデータを定義できます。

- 「セキュリティ」セクションでは、エンティティについてロール・ベースの更新可能権限を定義できます。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

- 「ビジネス・ロジック・グループ」セクションでは、ビジネス・ロジック・グループと追加および削除できます。詳細は、「ビジネス・ロジック・グループの定義」を参照してください。

3. 「属性」ナビゲーション・タブをクリックして、エンティティ・オブジェクトに関連するデータを示す属性を作成または削除し、検証規則、カスタム・プロパティおよびセキュリティなど、属性の様々な構成を行います。

属性を選択し、「編集」アイコンをクリックして属性のプロパティにアクセスします。これらのプロパティの設定方法の詳細は、「属性プロパティの設定」を参照してください。

注意:

エンティティの属性名のリストが長い場合、目的の属性を簡単に見つける方法があります。「構造」ウィンドウの「属性」ノードが開かれた状態で属性名を入力すると、入力した文字に応じて属性がインクリメンタル検索され、ツリー内のその名前が表示されます。

4. 「ビジネス・ルール」ナビゲーション・タブをクリックして、エンティティ・オブジェクトとその属性の宣言的バリデータを定義します。スクリプト・ボックスではビジネス・ルール用のGroovyスクリプトを表示および編集でき、デバッグ用のブレークポイントを設定できます。詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

5. 「Java」ナビゲーション・タブをクリックし、カスタムJava実装に対して生成するクラスを選択します。Javaクラスは、プログラム的なビジネス・ルールの定義などに使用できます(「プログラムによる検証とビジネス・ルールの実装」を参照)。

6. 「ビジネス・イベント」ナビゲーション・タブをクリックし、エンティティ・オブジェクトが、その状態の変更を他に通知する際に使用できるイベント(およびオプションで、配信イベントに含めるエンティティ・オブジェクトの属性の一部または全部)を定義します。ビジネス・イベントの詳細は、「ビジネス・イベントの作成」を参照してください。

7. 「ビュー・アクセッサ」ナビゲーション・タブをクリックし、ビュー・アクセッサを作成および管理します。詳細は、「エンティティ・オブジェクトまたはビュー・オブジェクトのビュー・アクセッサの作成方法」を参照してください。

4.9.2 宣言的な実行時動作の構成時の処理

エンティティ・オブジェクトの実行時動作を記述および制御する宣言的設定は、XMLドキュメント・ファイルに格納されます。概要エディタを使用してエンティティの設定を変更する場合、JDeveloperによりコンポーネントのXML定義ファイルおよびオプションのカスタムJavaファイルが更新されます。

4.9.3 バッチ更新の使用方法

バッチ更新を使用すると、複数のエンティティ変更の際に発行されるDML文の数を減らすことができます。

デフォルトで、ADFビジネス・コンポーネント・フレームワークは、指定されたエンティティ定義型の変更済エンティティ1つにつき、1つのDML文(DELETE、INSERT、UPDATE)を実行します。たとえば、Employeeエンティティ・オブジェクト型があり、アプリケーションの通常使用でその複数のインスタンスが変更されたとします。4つのインスタンスが作成され、2つの既存のインスタンスが変更され、3つの既存のインスタンスが削除された場合、それらの変更を保存するために、トランザクション・コミット時間に、フレームワークにより9つのDML文(4つのDELETE、2つのINSERT、3つのUPDATE)が発行されます。

トランザクションで、ある型の複数のエンティティを頻繁に更新する場合、そのエンティティ定義型に対してバッチ更新機能を使用することを検討してください。この例では、バッチ更新(しきい値は1)でフレームワークが発行するDML文は、4件の削除を処理する1つの一括DELETE文、2件の挿入を処理する1つの一括INSERT文および3件の更新を処理する1つの一括UPDATE文の3つのみです。

しきい値は、個別に処理された特定の操作ごとの変更済エンティティ行の数を示しています。変更済エンティティ行の数がしきい値を超えると、その操作では一括処理が使用されます。この例では、しきい値が3の場合、DELETEは一括更新実行しますが(4つのDELETE文のため)、INSERTとUPDATEは一括処理を使用しません(INSERT文は2つのみで、UPDATE文は3つのため)。

注意:

バッチ更新がコンポジット関連と組み合せてエンティティ・オブジェクトで使用されている場合に、親オブジェクトが1より大きいしきい値を定義する場合は、すべての構成される子オブジェクトでは、1より大きいしきい値を定義する必要があります。

次のいずれかの場合、バッチ更新機能は無効になります。

- エンティティ・オブジェクトにはBLOB型またはCLOB型の属性があります。ストリーミング・データ型を持つバッチDMLはサポートされていません。

- Refresh After InsertまたはRefresh After Updateに設定されている属性がエンティティ・オブジェクトにあります。1回のラウンド・トリップでトリガー割当て値のすべてを一括で戻すメソッドがないため、属性の取得や更新を行う処理はバッチDMLで動作しません。

- 主キーがない表からエンティティ・オブジェクトを作成しました。表に主キーがなく、その表からエンティティ・オブジェクトのリバース・エンジニアリングを行った場合、ROWID値属性が作成されて、かわりに主キーとして割り当てられます。ROWID値は、挿入時に取得スタイルの値として管理されるため、バッチDMLで動作しません。

始める前に:

実行時動作の宣言的な構成に関する知識が役立つ場合があります。詳細は、「宣言的な実行時動作の構成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティに対してバッチ更新を有効化する手順:

1. 「アプリケーション」ウィンドウで、一括更新するエンティティをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

3. 「一般」ページで「チューニング」セクションを開き、「バッチ更新を使用」チェック・ボックスを選択して、適切なしきい値を指定します。

これにより、それを超えるとOracle ADFが一括DML操作を使用して変更を処理する、バッチ処理のしきい値が指定されます。

4.10 属性プロパティの設定

宣言的なフレームワークによって、属性プロパティを簡単に設定できます。いずれの場合も、これらのプロパティは概要エディタの「属性」ページで設定します。

4.10.1 エンティティ・オブジェクト属性のデータベースおよびJavaデータ型を設定する方法

「永続的」プロパティにより、基礎となる表内の列に属性値が対応するか、単なる一時的な値であるかを制御します。属性が永続的である場合、「データベース列」領域を使用して、属性に対応する基礎となる列の名前を変更し、精度およびスケール情報を使用してその列型を指定できます(VARCHAR2(40)やNUMBER(4,2)など)。エンティティ・オブジェクトは、実行時にこの情報に基づいて、属性値の最大長または精度/スケールを設定し、値が要件を満たさない場合は例外をスローします。

「表からのビジネス・コンポーネント」ウィザードと「エンティティ・オブジェクトの作成」ウィザードでは、各エンティティ・オブジェクト属性のJava型は、関連付けられている列のデータベース列型のSQL型から推測されます。

注意:

プロジェクトの「型マップ」設定は、Javaデータ型の決定にも役割を果します。ビジネス・コンポーネント・プロジェクトを初期化する場合は、ビジネス・コンポーネントが作成される前に「型マップ」設定を指定します。詳細は、「データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法」を参照してください。

(「詳細」タブの)「型」フィールドでは、エンティティ属性のJava型を目的の型に変更できます。「列の型」フィールドには、属性がマップされている、基礎となるデータベース列のSQL型が表示されます。「列名」フィールドの値により、属性がマップされる列が制御されます。

エンティティ・オブジェクトは、表4-1に示す様々な列型の表を処理できます。デフォルトのJava属性タイプはすべてoracle.jbo.domainおよび各種javaパッケージに格納されており、対応する型のOracleデータベースのデータを効率的に処理できるようサポートされています。「型」フィールドのドロップダウン・リストには、その他の多くの共通型が含まれており、これらもサポートされています。

表4-1 デフォルトのエンティティ・オブジェクトの属性タイプのマッピング

Oracleの列型

エンティティの列型

エンティティのJava型

NVARCHAR2(n)、VARCHAR2(n)、NCHAR VARYING(n)、VARCHAR(n)

VARCHAR2

java.lang.String

NUMBER

NUMBER

oracle.jbo.domain.Number java.math.BigDecimal java.math.BigInteger java.lang.Integer java.lang.Long

DATE

DATE

java.sql.Timestamp

TIMESTAMP(n)、TIMESTAMP(n) WITH TIME ZONE、TIMESTAMP(n) WITH LOCAL TIME ZONE

TIMESTAMP

java.sql.Timestamp

LONG

LONG

java.lang.String

RAW(n)

RAW

oracle.jbo.domain.Raw

LONG RAW

LONG RAW

oracle.jbo.domain.Raw

ROWID

ROWID

oracle.jbo.domain.RowID

NCHAR, CHAR

CHAR

oracle.jbo.domain.Char

CLOB

CLOB

oracle.jbo.domain.ClobDomain

NCLOB

NCLOB

oracle.jbo.domain.NClobDomain

BLOB

BLOB

oracle.jbo.domain.BlobDomain

BFILE

BFILE

oracle.jbo.domain.BFileDomain

注意:

ここで示した型以外にも、oracle.jbo.domain.DomainInterfaceインタフェースが実装されていることを前提に、任意のJavaオブジェクト型をエンティティ・オブジェクトの属性の型として使用できます。

4.10.2 データ型の長さ、精度およびスケールの指定方法

VARCHAR2(n)などの最大長の定義をサポートする型を使用する場合、(「詳細」タブの)「列の型」フィールドには、値の一部として属性の最大長が含まれます。たとえば、データベースのVARCHAR2(10)列に基づく属性の場合、データベース列の型としてVARCHAR2(10)が表示され、最初に最大長として10文字が示されます。なんらかの理由により、String値の属性の最大長を、基礎となる列で使用可能な文字数より少ない文字数に制限する必要がある場合は、「列の型」の値の最大長を変更します。

たとえば、PERSONS表のEMAIL列がVARCHAR2(50)である場合、デフォルトでは、Personsエンティティ・オブジェクトのEmail属性も同じ型に設定されます。ただし、実際の電子メール・アドレスが常に8文字以下である場合は、Email属性のデータベース列の型をVARCHAR2(8)に更新し、エンティティ・オブジェクト・レベルでの最大長を8文字に設定できます。

これは、NUMBER(p[,s])のように精度やスケールの定義をサポートするデータベース列の型に関連する属性についても同様です。たとえば、データベースのNUMBER(7,2)列に基づく属性の精度を5、スケールを1に制限するには、「列の型」フィールドの値をNUMBER(5,1)に更新します。

注意:

この機能は注意して使用してください。他のアプリケーションがこのデータベース列にアクセス可能な場合は、他のアプリケーションがより厳しい制限に準じるかどうかを確認できません。

4.10.3 属性の更新可能性の制御方法

「更新可能」プロパティにより、特定の属性値をいつ更新できるかを制御します。次の値を選択できます。

- 常に: 属性は常に更新可能です。

- なし: 属性は読取り専用です。

- 新規の間: エンティティ行を初めて作成するトランザクション中は属性を設定できますが、データベースへのコミットが成功した後、属性は読取り専用になります。

注意:

更新可能性の静的な宣言に加えて、エンティティのisAttributeUpdateable()メソッドにカスタム・コードを追加して、実行時に属性の更新可能性を決定することもできます。

4.10.4 属性を必須化する方法

フィールドが必須の場合は、「必須」チェック・ボックスを選択します。必須プロパティは、実行時、(属性バリデータの実行時ではなく)エンティティ・レベルの検証が行われる際に適用されます。

4.10.5 エンティティの主キーの定義方法

「主キー」プロパティにより、属性がエンティティを一意に識別するキーの一部であるかどうかを指定します。通常、主キーには単一属性を使用しますが、複数属性の主キーも完全にサポートされています。

実行時には、getKey()メソッドを使用して任意のエンティティ行に関連するKeyオブジェクトにアクセスすると、このKeyオブジェクトには、このエンティティ・オブジェクトの主キー属性の値が含まれます。このエンティティ・オブジェクトに複数の主キー属性がある場合、Keyオブジェクトにはこれらの各値が含まれます。これらの値が、エンティティ・オブジェクト定義で対応する主キー属性と同じ相対順序で表示されると理解することが重要です。

たとえば、ItemEOエンティティ・オブジェクトには、OrdIdおよびItemIdという複数の主キー属性があります。概要エディタの「属性」ページでは、OrdIdが先頭で、ItemIdが2番目です。ItemEO型のエンティティ行のKeyオブジェクトによってカプセル化された値の配列では、これらの2つの属性値がこれとまったく同じ順序になります。

「エンティティ属性」ページでは、複数の主キー属性がどのような順序で表示されているかを理解しておくことが非常に重要です。findByPrimaryKey()を使用して複数属性の主キーを持つエンティティを検索する場合、作成したKeyオブジェクトでこれら複数の主キー属性の順序が間違っていると、エンティティ行が期待したとおりに検出されません。

さらに、主キーを新しい行に移入するには、トリガーを使用してデータベースから値を割り当てる場合もあります。詳細は、「トリガーによってデータベース順序から割り当てられた主キー値の取得方法」を参照してください

4.10.6 静的なデフォルト値を定義する方法

値のタイプが「リテラル」に設定されている場合、「詳細」タブの「値」フィールドには、属性のデフォルト値を静的に指定できます。たとえば、ServiceRequestエンティティ・オブジェクトのStatus属性のデフォルト値をOpenに設定したり、Userエンティティ・オブジェクトのUserRole属性のデフォルト値をuserに設定できます。

注意:

1つのエンティティ・オブジェクトに複数の属性がデフォルト設定される場合は、エンティティ・オブジェクトのXMLファイルにおいてそれらの属性が表示されている順にデフォルト設定されます。

4.10.7 式を使用してデフォルト値を定義する方法

属性のデフォルト値は、Groovy式またはSQL文を使用して定義できます。実行時にデフォルト値を動的に定義できるようにする場合はこの方法が便利ですが、デフォルト値が常に同じ場合は、(「詳細」タブの)「リテラル」型のフィールドを使用すると、より簡単に値を表示および管理できます。Groovyの使用の一般的な情報は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。

始める前に:

属性プロパティの設定方法の知識があると役立ちます。詳細は、「属性プロパティの設定」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

式を使用してデフォルト値を定義するには:

1. 「アプリケーション」ウィンドウで、デフォルト値を定義する属性が含まれているエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで編集する属性を選択し、「詳細」タブをクリックします。

4. 「詳細」ページで、値タイプを選択して、「値」フィールドの「編集」アイコンをクリックします。

- Groovy式を使用する場合は、「式」を選択します。

- SELECT文を使用する場合は、「SQL」を選択します。

5. 次を入力するには:

- SQL文の場合: 表示されるフィールドに文を入力し、「OK」をクリックします。SQL文を入力できるのは一時属性のみです。

- Groovy式の場合: 横にあるアイコンをクリックし、「式エディタの編集」ダイアログを開きます。「式エディタの編集」ダイアログで、表示されているフィールドに式を入力します。参照する属性には、ビジネス・コンポーネントで定義されている任意の属性を使用できます。属性を使用可能から選択済に移動して、この属性が依存する属性を指定します。「OK」をクリックして、式を保存します

4.10.8 Groovy式を使用したデフォルト値の作成時の処理

Groovy式を使用してデフォルト値を定義すると、<TransientExpression>タグがビジネス・オブジェクトのXMLファイルの適切な属性内に追加されます。次の例は、CountryVOビュー・オブジェクトのID属性に追加されたGroovy式のXMLコードを示しています。このXML定義は、このGroovy式スクリプトが含まれている.bcsファイルはoperations.xmlによって指し示されることを示しており、この例ではCodeSourceName=”CountryVOOperations.xml”がこれに当たります。operations.xmlファイルには.bcsファイルを指し示すURIが含まれています。

<View Attribute
Name="Id"
IsNotNull="true"
PrecisionRule="true"
EntityAttrName="Id"
EntityUsage="CountryEO"
AliasName="ID">
<TransientExpression
Name="ExpressionScript"
trustMode="untrusted"
CodeSourceName="CountryVORow"/>

</ViewAttribute>

注意:
Groovyファイル生成がこのモデル・プロジェクトまたはアプリケーション全体に対して有効になっている場合、このビジネス・コンポーネントの概要エディタ・ページ上の「デフォルト値」セクションの下に、Groovy式がハイパーリンクとして表示されます。このハイパーリンクをクリックすると、このビジネス・コンポーネントに関連する.bcsファイルが開きます。プロジェクト設定の詳細は、「Groovyプロジェクトの設定に関する必知事項」を参照してください。入力したGroovy式がどのように処理されるかについては、「式を入力したときの処理」を参照してください。

4.10.9 トリガーによって割り当てられた値を同期化する方法

基礎となる列値が、挿入または更新の操作時にデータベース・トリガーによって更新される場合、「詳細」タブの「挿入時にリフレッシュ」チェック・ボックスまたは「更新時にリフレッシュ」チェック・ボックスをそれぞれ選択することにより、変更された値をフレームワークが自動的に取得し、エンティティ・オブジェクトとデータベース行を同期化できます。エンティティ・オブジェクトは、INSERTまたはUPDATEを実行しながらOracle SQLのRETURNING INTO機能を使用して、変更された列を1回のデータベースのラウンドトリップでアプリケーションに戻します。

注意:

DBLINKを介してリモート表に解決されるシノニムのエンティティ・オブジェクトを作成する場合、この機能を使用すると、実行時に次のようなエラーが発生します。

JBO-26041: Failed to post data to database during "Update"
## Detail 0 ##
ORA-22816: unsupported feature with RETURNING clause

このようなデータベース制限を回避する技術は、「結合ビューまたはリモートDBLinkに基づくエンティティ・オブジェクト」を参照してください。

4.10.10 トリガーによってデータベース順序から割り当てられた主キー値の取得方法

挿入後に属性がリフレッシュされる一般的なケースは、主キー属性の値がBEFORE INSERT FOR EACH ROWトリガーによって割り当てられる場合です。多くの場合、このトリガーにより、次の例に示すようなPL/SQLロジックを使用してデータベース順序から主キーが割り当てられます。

CREATE OR REPLACE TRIGGER ASSIGN_SVR_ID
BEFORE INSERT ON SERVICE_REQUESTS FOR EACH ROW
BEGIN
IF :NEW.SVR_ID IS NULL OR :NEW.SVR_ID < 0 THEN
SELECT SERVICE_REQUESTS_SEQ.NEXTVAL
INTO :NEW.SVR_ID
FROM DUAL;
END IF;
END;

注意:

稼働中のデータベース内でトリガーを作成することもできれば、かわりにオフライン・データベースでトリガーを作成してからそれを稼働中のデータベースにインポートすることもできます。オフライン・データベース・オブジェクトの操作の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のデータベース・オブジェクトの作成、編集およびドロップに関する項を参照してください。

「詳細」タブ(概要エディタの「属性」ページ)で、「型」フィールドの値を組込みデータ型(名前はDBSequence)に設定でき、主キーが自動的にデータベース順序によって割り当てられます。このデータ型を設定すると、「挿入時にリフレッシュ」チェック・ボックスが自動的に選択されます。

注意:

「順序」タブに表示されている順序名が設計時に使用されるのは、「エンティティ・オブジェクトからのデータベース表の作成方法」で説明されているデータベース表の作成機能を使用する場合のみです。ここで示す順序は、エンティティ・オブジェクトの基礎となる表とともに作成されます。

主キーがDBSequenceである新しいエンティティ行を作成すると、一意の負の数値が一時値として割り当てられます。この値は、このエンティティ行を作成するトランザクション中、主キーとして機能します。同じトランザクション内で一連の相関エンティティを作成する場合、その他の新しい関連エンティティ行にこの一時値を外部キー値として割り当てることができます。トランザクションのコミット時に、エンティティ・オブジェクトは、RETURNING INTO句を使用してINSERT操作を発行し、実際にデータベースのトリガーによって割り当てられた主キー値を取得します。コンポジット関連では、先にこの一時的な負の値を外部キーとして使用していた新しい関連エンティティでは、マスターの実際の新しい主キーを反映してこの値が更新されます。

通常は、DBSequence値を持つ主キーの「更新可能」プロパティも「なし」に設定します。一時IDはエンティティ・オブジェクトによって割り当てられ、INSERT操作の後に実際のID値を使用してリフレッシュされます。エンド・ユーザーがこの値を更新する必要はありません。

コンポジット以外のアソシエーションでこの機能を実装する方法の詳細は、「DBSequenceの値が設定される主キーに基づくアソシエーション」を参照してください。

注意:

DBSequenceのかわりにメタデータ駆動型の方法を使用する場合は、「Oracle順序を使用した主キー値の割当て」を参照してください。

4.10.11 主キー値の変更に関する必知事項

ユーザー・インタフェースを使用した主キー値の更新は、ADFビジネス・コンポーネントではサポートされていません。ただし、DBSequenceを使用するか(「トリガーによってデータベース順序から割り当てられた主キー値の取得方法」を参照)、プログラムによって(「Oracle順序を使用した主キー値の割当て」を参照)主キー値を更新することはできます。このようなユーザー・インタフェース動作は、ユーザーに主キーの変更を許可するのではなく、サロゲート・キーを使用して実装できる場合があります。

4.10.12 同時更新によるデータの消失を防ぐ方法

実行時には、フレームワークによりエンティティ・オブジェクトの更新の上書きが検出され、作業中に別のユーザーによって更新およびコミットされたデータであることに気付かずにユーザーがこのデータを変更できないようにします。通常、このチェックは、基礎となる行がロックされているときにデータベース内で対応する現在の列値と各永続エンティティ属性の元の値を比較することによって実行されます。行の更新前に、エンティティ・オブジェクトによって、更新される行とデータベースの現在の状態の間に一貫性があるかどうかが検証されます。行とデータベースの状態の間に一貫性がない場合、エンティティ・オブジェクトではRowInconsistentExceptionが発生します。

更新の上書きの検出をより効率的にするには、エンティティが変更されるたびに値が更新されるエンティティの属性を特定します。通常、このような値には、行内のバージョン番号列や更新日付列などがあります。(「詳細」タブの)「挿入時にリフレッシュ」オプションまたは「更新時にリフレッシュ」オプションを選択したので、作成したデータベース・トリガーによって更新識別子の属性値を割り当て、エンティティ・オブジェクトでこれらの値をリフレッシュできます。また、「履歴列を使用して作成および変更した日付を追跡する方法」で説明する履歴属性の機能を使用してエンティティ・オブジェクトによって更新識別子の属性値の更新が管理されるように指定できます。

ユーザーによる問合せ以降にエンティティ行が変更されたかどうかを最も効率的な方法で検出するには、「更新識別子」オプションを選択し、更新識別子の属性値のみを比較します。更新識別子属性のないエンティティ・オブジェクトはすべての属性の値がデータ一貫性チェックで使用されるため効率が低下する場合があります。更新識別子属性のないエンティティ・オブジェクトは、ユーザー・セッションがアプリケーション・モジュールとのアフィニティを失った(アプリケーション・モジュール・プールが使用されている場合)ときにデータの一貫性を失う可能性もあります。詳細は、「状態管理とデータの整合性に関する必知事項」を参照してください。アプリケーション・モジュール・プールの詳細は、「アプリケーション・モジュール・プールのチューニング」を参照してください。

4.10.13 履歴列を使用して作成および変更した日付を追跡する方法

エンティティの作成日時や変更日時、作成者や変更者、エンティティの変更回数など、エンティティ・オブジェクトで履歴情報を追跡する必要がある場合、「変更履歴のトラッキング」オプションが選択されている属性を指定します(「詳細」タブ)。

属性のデータ型がNumber、StringまたはDateであり、主キーの一部ではない場合、このプロパティを有効化して履歴監査用の属性値を自動的に管理できます。フレームワークにおける属性の処理方法は、次のような履歴属性のタイプの中からどれを指定するかによって異なります。

- 作成日付: この属性には、行が作成された日付のタイム・スタンプが移入されます。タイム・スタンプはデータベースから取得されます。

- 作成者: この属性には、行を作成したユーザーの名前が移入されます。ユーザー名は、SessionオブジェクトのgetUserPrincipalName()メソッドを使用して取得されます。

- 変更日付: この属性には、行が更新/作成された日付のタイム・スタンプが移入されます。

- 変更者: この属性には、行を作成/更新したユーザーの名前が移入されます。

- バージョン番号: この属性には、行が作成または更新されるたびに増分するlong値が移入されます。

4.10.14 コンポジット動作の構成方法

エンティティ・オブジェクトでは、ItemEOエンティティを作成するOrdEOエンティティなど、他のエンティティを作成(または構成)する場合、コンポジット動作が示されます。この付加的な実行時動作により、ネストされた他のエンティティ・オブジェクト部分の論理コンテナとしての役割が決定されます。この関係により、コンポジット・アソシエーションは、一時属性をベースに作成できません。

注意:

コンポジットは、エンティティが検証される順序にも影響を与えます。詳細は、「検証順序に対するコンポジットの影響の理解」を参照してください。

エンティティ・オブジェクトの構成で常に有効な機能については、次の項を参照してください。

- 新しく構成されるエンティティ・オブジェクトでの親のない行の保護

- データベースに保存される変更の順序付け

- Refresh-On-Insert主キーからの構成される側の詳細エンティティのカスケード更新

別の機能およびこれらの動作に影響するプロパティについては、次の項を参照してください。

- カスケード削除のサポート

- 主キーの変更時の外部キー属性のカスケード更新

- コンポジット親エンティティ・オブジェクトのロック

- コンポジット・エンティティ・オブジェクトでのバッチ更新の使用

- 構成する側の親の履歴属性の更新

4.10.14.1 新しく構成されるエンティティ・オブジェクトでの親のない行の保護

構成されるエンティティ・オブジェクトが作成されると、この値が既存のエンティティを所有する親のエンティティとして識別しているか確認するため、外部キー属性の値の存在がチェックされます。作成時に外部キーが検出されなかった場合や、既存のエンティティ・オブジェクトを識別しない値が検出された場合、エンティティ・オブジェクトでは、親エンティティが識別されていない状態で親のない子行が作成されないように、InvalidOwnerExceptionがスローされます。

注意:

外部キー属性の値の存在がチェックされたことにより、現在のトランザクションで新しい保留エンティティが検索される他、必要に応じてデータベース内の既存のエンティティが検索されます。

4.10.14.2 データベースに保存される変更の順序付け

コンポジット動作により、構成する側のエンティティ・オブジェクトと構成される側のエンティティ・オブジェクトの両方が含まれるトランザクションで実行されるデータ操作言語(DML)操作が正しい順序で実行されたかどうかを確認します。たとえば、構成する側の新しい親エンティティ・オブジェクトに対するINSERT文は、構成される側の子エンティティ・オブジェクトに関連するDML操作の前に実行されます。

4.10.14.3 Refresh-On-Insert主キーからの構成される側の詳細エンティティのカスケード更新

主キーが挿入時にリフレッシュするように構成されている新しいエンティティ行を保存すると、トリガーによって割り当てられた主キー値の取得後に、構成される側のエンティティの外部キー属性値が更新されて新しい主キー値が反映されます。

これ以外にも、アソシエーション作成ウィザードの「アソシエーション・プロパティ」ページまたは概要エディタの設定を介して制御可能なコンポジット関連機能が多数用意されています。図4-13は、2つのエンティティ・オブジェクトItemEOとOrdEOの間のSItemOrdIdFkAssocアソシエーションが表示された「関連」ページを示しています。

4.10.14.4 カスケード削除のサポート

構成される側の子が存在していても、構成する側の親の削除を有効化または禁止できます。「カスケード削除の実装」オプション(図4-13を参照)の選択が解除されている場合に、構成する側の親に構成される側の子が含まれる場合、構成する側のエンティティ・オブジェクトの削除は禁止されます。

図4-13 概要エディタの「関連」ページのアソシエーション動作設定

このオプションが選択されている場合、構成する側のエンティティ・オブジェクトを、構成される側の子エンティティとともに無条件に削除できます。関連する「データベースのカスケード削除用に最適化」オプションの選択が解除されている場合、構成される側のエンティティ・オブジェクトでは、トランザクションのコミット時に通常のDELETE文が実行され、変更が永続的になります。このオプションが選択されている場合、データベースのON DELETE CASCADE制約によって対応する行の削除が処理されることを前提に、構成される側のエンティティではDELETE文は実行されません。

4.10.14.5 主キーの変更時の外部キー属性のカスケード更新

「カスケード更新キー属性」オプション(図4-13を参照)を選択すると、構成する側のエンティティの主キー値が変更される場合に、構成される側のエンティティの外部キー属性値が自動で更新されるよう設定できます。

4.10.14.6 コンポジット親エンティティ・オブジェクトのロック

「最上位コンテナのロック」オプション(図4-13を参照)を選択すると、構成される側の詳細エンティティ行の追加、削除または変更時に、変更を保存する前に、構成する側のエンティティをロックするかどうかを制御できます。

4.10.14.7 コンポジット・エンティティ・オブジェクトでのバッチ更新の使用

バッチ更新がコンポジット関連と組み合せてエンティティ・オブジェクトで使用されている場合に、親オブジェクトが1より大きいしきい値を定義する場合は、すべての構成される子オブジェクトでは、1より大きいしきい値を定義する必要があります。

4.10.14.8 構成する側の親の履歴属性の更新

「トップレベルの履歴列の更新」オプション(図4-13を参照)を選択すると、構成される側の詳細エンティティ・オブジェクトの追加、削除または変更時に、構成する側の親エンティティの「変更者」および「変更日付」履歴属性を更新するかどうかを制御できます。

4.10.15 エンティティ・オブジェクト継承階層の識別子属性の設定方法

場合によっては、論理的に関連付けられた様々なオブジェクトに関する情報が1つのデータベース表に格納されることがあります。たとえば、給与計算アプリケーションでは、アルバイト、正社員、契約社員すべてが、EMPLOYEE_TYPE列を持つ1つのEMPLOYEES表に格納されることがあります。この場合、EMPLOYEE_TYPE列では、H、S、Cなどの値を使用して、特定の行がそれぞれアルバイト(Hourly)、正社員(Salaried)、契約社員(Contract)のいずれを表すのかを示します。多くの属性や動作はすべての従業員で同一の場合もありますが、特定のプロパティやビジネス・ロジックは従業員のタイプによって異なることがあります。

関連するオブジェクトの間に共通情報が存在する場合は、継承階層を使用してこのような異なるタイプのエンティティ・オブジェクトを表すと便利です。たとえば、すべての従業員に共通の属性およびメソッドは、ベースとなるEmployeeエンティティ・オブジェクトの一部とし、HourlyEmployee、SalariedEmployeeおよびContractEmployeeなどのサブタイプのエンティティ・オブジェクトでは、ベースとなるEmployeeオブジェクトを拡張し、別のプロパティや動作を追加します。「多相化識別子」属性設定を使用して、行のタイプを識別する属性の値を示します。継承の設定方法および使用方法は、「ビジネス・ドメイン・レイヤーでの継承の使用」を参照してください。

4.10.16 代替キー値の定義方法

データベースの主キーは順序から生成されることが多く、様々な理由からユーザーへの公開を避けることが必要な場合があります。このため、多くのケースでは一意の代替キー値を使用すると便利です。たとえば、すべての顧客に一意の電子メール・アドレスを持たせるとします。顧客は電子メール・アドレスを変更する可能性があるため、主キーとしてはこの値を使用できませんが、それぞれの顧客に対してログインなどの目的で使用できる一意のフィールドを持たせる必要があります。

代替キーは、メソッドのfindByKeyクラスを介して直接行を参照する場合に便利です。代替キーは、中間層で効率的な一意性チェックを行う場合にもよく使用されます。値が一意であるかどうかの確認方法の詳細は、「キー値の一意性を確認する方法」を参照してください。

代替キーの定義には、「エンティティ制約の作成」ウィザードを使用します。

始める前に:

属性プロパティの設定方法の知識があると役立ちます。詳細は、「属性プロパティの設定」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

代替キー値を定義するには:

1. 「アプリケーション」ウィンドウで、代替キーを定義するエンティティ・オブジェクトを右クリックし、新規のエンティティ制約を選択します。

2. 「エンティティ制約の作成」ウィザードの手順に従って、制約の名前を指定し、キーとして使用する属性(複数可)を選択します。

3. 「プロパティ」ページで、「代替キー」を選択し、適切な「キー・プロパティ」オプションを選択します。

「キー・プロパティ」の詳細情報は、[F1]キーを押すか「ヘルプ」をクリックすると参照できます。

4.10.17 代替キー値定義時の処理

代替キー値を定義するとハッシュマップが作成され、すでにメモリーにあるエンティティへのアクセスが高速になります。

4.10.18 代替キー値に関する必知事項

一意キー制約は、データベース内のUNIQUE制約の順方向生成にのみ使用され、代替キー値には使用されません。

4.11 エンティティ・オブジェクトへの一時属性および計算属性の追加

基礎となる表内の列にマップされる属性のみでなく、エンティティ・オブジェクトには、値ホルダーである一時属性や(JavaやGroovyなどを使用して)計算された値を表示する一時属性を組み込むことができます。たとえば、FullNameなどの作成した一時属性は、FirstName属性の値とLastName属性の値を連結した値に基づいて計算できます。

一時属性を作成すると、エンティティ・オブジェクトのJavaクラスで計算を実行したり、属性定義でGroovy式を使用してデフォルト値を指定できます。

実行時に値を計算する方法を変更できるようにする必要がある場合は、Groovy式を使用します。値を計算する方法が変更される可能性が低い場合は(明細項目の合計など)、エンティティ・オブジェクトのJavaクラス内で直接計算できます。

4.11.1 一時属性の追加方法

一時属性を作成するには、概要エディタの「属性」ページを使用します。

始める前に:

一時属性および計算属性の使用に関する知識があると役立ちます。詳細は、「エンティティ・オブジェクトへの一時属性および計算属性の追加」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティ・オブジェクトに一時属性を追加するには:

1. 「アプリケーション」ウィンドウで、一時属性を追加するエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規」アイコンをクリックして、「新規属性」を選択します。

3. 「新規属性」ダイアログで、属性の名前を入力し、「タイプ」ドロップダウン・リストからJava属性を選択し、「OK」をクリックします。

4. 概要エディタの「属性」ページで、「詳細」タブをクリックし、「一時」ラジオ・ボタンを選択します。

5. 値が計算される場合は、「更新可能」 ドロップダウン・リストから「使用しない」を選択します。

4.11.2 一時属性の追加時の処理

一時属性を追加すると、エンティティ・オブジェクトのXMLドキュメントが更新され、新しい属性が反映されます。次の例に示すように、一時属性の<Attribute>タグには、TableNameまたはColumnNameはありません。

<Attribute
Name="FullName"
IsUpdateable="false"
IsQueriable="false"
IsPersistent="false"
Type="java.lang.String"
SQLType="VARCHAR" >
</Attribute>

これに対し、永続的エンティティ属性には、次の例のようにTableNameとColumnNameの両方があります。

<Attribute
Name="FirstName"
IsNotNull="true"
Precision="30"
ColumnName="FIRST_NAME"
Type="java.lang.String"
ColumnType="VARCHAR2"
SQLType="VARCHAR"
TableName="USERS" >
</Attribute>

4.11.3 Groovy式に準拠した一時属性の作成方法

一時属性を作成する場合、デフォルト値の指定にGroovy式を使用できます。

始める前に:

一時属性および計算属性の知識があると役立ちます。詳細は、「エンティティ・オブジェクトへの一時属性および計算属性の追加」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

Groovy式に基づいて一時属性を作成するには:

1. 「アプリケーション」ウィンドウで、一時属性を追加するエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規」アイコンをクリックして、「新規属性」を選択します。

3. 「新規属性」ダイアログで、属性の名前を入力し、「タイプ」ドロップダウン・リストからJava属性を選択し、「OK」をクリックします。

4. 概要エディタの「属性」ページで、「詳細」タブをクリックし、「一時」オプションを選択します。

5. 値が計算される場合は、「更新可能」 ドロップダウン・リストから「使用しない」を選択します。

6. 「デフォルト値」の下の「式」チェック・ボックスを選択し、横にあるアイコンをクリックして「式エディタの編集ダイアログを開きます。

定義した式は、Groovyスクリプト言語を使用して評価されます(「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照)。Groovyプログラミング言語を使用して式と変数を文字列に入力します。この式は、エンティティ・オブジェクト定義の一部として保存されます。

7. 「式エディタの編集」ダイアログで、表示されているフィールドに式を入力します。

参照する属性には、エンティティ・オブジェクトで定義されている任意の属性を使用できます。エンティティ・オブジェクトで定義されていない属性を式内で参照する場合は、適切なコンテキスト・オブジェクトを使用する必要があります。

図4-14 式エディタの編集

8. この属性が依存する属性を指定します。これらの属性を使用可能から選択済に移動します。

9. 「OK」をクリックして、式を保存します。

10. 必要であれば、再計算式を適用します。これはtrueと評価された場合にデフォルト式を再計算します。「式値のリフレッシュ」フィールドで、横にあるアイコンをクリックして「式エディタの編集」ダイアログを開きます。デフォルト式を定義したときと同じ手順で、再計算式も定義します。

たとえば、次の式は「式エディタの編集」ダイアログを使用して「式値のリフレッシュ」フィールド用に定義されたものですが、この式はQuantityShipped属性またはPrice属性が変更された場合に属性を再計算します。

return (adf.object.isAttributeChanged("QuantityShipped") || adf.object.isAttributeChanged("Price"));

注意:

値式またはオプションの再計算式がベース・エンティティ・オブジェクトの属性を参照する場合は、これを依存性として定義する必要があります。式を定義したときに「式エディタの編集」ダイアログで依存性を指定しなかった場合は、「依存性」タブ(「属性」ページ)でそれを実行できます。「依存性」タブで、「使用可能」リストで属性を特定し、それぞれを「選択済」リストに移動します。

4.11.4 Groovy式に準拠した一時属性の作成時の処理

一時属性がGroovy式に準拠している場合は、次の例に示すように<TransientExpression>タグがエンティティ・オブジェクトのXMLファイルの適切な属性内に追加されます。

<Attribute
Name="QuantityTotal"
ColumnName="QUANTITY_TOTAL"
...
<TransientExpression
Name="ExpressionScript"
trustMode="untrusted"
CodeSourceName="ItemEORow"/>
<Dependencies>
<Item
Value="Price"/>
<Item
Value="QuantityShipped"/>
</Dependencies>
</Attribute>

4.11.5 エンティティ・クラスへの計算実行用Javaコードの追加方法

一時属性は、データ値のプレースホルダです。一時属性の「更新可能」プロパティを「新規の間」または「常に」に変更すると、エンド・ユーザーは属性値を入力できるようになります。一時属性に計算値を表示する場合は通常、「更新可能」プロパティを「なし」に設定し、値を計算するカスタムJavaコードを記述します。

エンティティ・オブジェクトに一時属性を追加した後、この属性計算属性にするには、次のようにする必要があります。

- 概要エディタの「Java」ページでカスタム・エンティティ・オブジェクト・クラスを有効にし、アクセッサ・メソッドの生成を選択します。

- 一時属性のアクセッサ・メソッドの内部で、計算済値を戻すJavaコードを記述します。

- 「属性」ページの「依存性」タブで、一時属性の依存属性をそれぞれ指定します。

たとえば、ビュー行クラスを生成した後、一時属性の計算値を戻すJavaコードは、次の例のように属性のgetterメソッド(FullNameなど)にあります。

// Getter method for FullName calculated attribute in UserImpl.java
public String getFullName() {
// Commented out original line since we'll always calculate the value
// return (String)getAttributeInternal(FULLNAME);
return getFirstName()+" "+getLastName();
}

エンド・ユーザーによって、連結される属性(LastNameやFirstNameなど)が変更されるたびに、一時属性が再評価されるようにするには、一時属性の依存属性を指定します。コード内で計算を実行する場合でも、依存属性の値が変更されたときにUIをリフレッシュする適切なイベントを起動するには依存性が必要です。依存属性を指定するには、「属性」ページの「依存性」タブで、「使用可能」リストで属性を特定し、それぞれを「選択済」リストに移動します。

4.12 ビジネス・イベントの作成

モデル・レイヤーから呼び出されたビジネス・イベントは、ビジネス・プロセスを起動する際や外部システム同期化をトリガーする際に役立ちます。

モデル・レイヤーから呼び出されたビジネス・イベントは、ビジネス・プロセスを起動する際や、Oracle SOA SuiteのコンポーネントであるOracle Mediator経由で外部システム同期化をトリガーする際に役立ちます。

注意:

Oracle Mediatorは、軽量なフレームワークを提供し、コンポジット・アプリケーション内の様々なコンポーネントを仲介します。また、様々なコンポーネントで公開される様々なインタフェース間での通信が容易になるようにデータを変換します。これらのコンポーネントは接続されて、SOAコンポジット・アプリケーションが構築されます。たとえば、Oracle Mediatorでは、アプリケーションまたはサービスからテキスト・ファイルに格納されたデータを受け入れ、顧客リポジトリとして使用するデータベースの更新に適した書式に変換し、変換したデータをそのデータベースにルーティングおよび配信できます。

Oracle Mediatorでは、ビジネス・イベントをアクションにマッピングする宣言的サブスクリプションがサポートされています。つまり、あるコンポーネントでビジネス・イベント(新規顧客作成など)を定義して公開した後、別のコンポーネントでこのイベントをサブスクライブすると、このビジネス・プロセスが発生したときに通知されます。次に、サブスクライブ中のコンポーネントで、そのイベントに割り当てているアクション(新規顧客への挨拶メールの送信など)を実行できます。

ビジネス・イベントはエンティティ・レベルで宣言的に定義します。また、それらのイベントを呼び出す条件を指定できます。指定の基準を満たすビジネス・イベントは、変更されたデータが正常にコミットされたときに呼び出されます。ビジネス・イベントは、エンティティ・オブジェクトが正常に作成、更新または削除されたときにMediatorに発行されます。

ビジネス・イベントを実装するには、次の処理を実行します。

1. 「ビジネス・イベントの作成方法」の説明に従ってイベント定義を作成します。

2. 「ビジネス・イベントの公開ポイントの定義方法」の説明に従って、イベント定義をイベント・ポイントにマップし、そのイベント定義を公開します。

「ビジネス・イベントをサブスクライブする方法」の説明に従って、ビジネス・イベントが公開されたら、別のコンポーネントからそのイベントをサブスクライブできます。

4.12.1 イベントの定義

イベント定義には、イベント・システムMediatorで公開および呼び出されるイベントが記述されます。イベント定義は、表4-2に示す要素とともに、エンティティ・オブジェクトのXMLファイルに格納されます。

表4-2 エンティティ・オブジェクトのイベント定義要素

要素

説明

イベント名

イベントの名前(OrderUpdatedなど)

ペイロード

サブスクライバに送信される属性のリスト。オプションとしてマークされた属性は、変更された場合のみペイロードに表示されます。

4.12.2 イベント・ポイント

イベント・ポイントは、イベントを呼び出せる場所です。コミットが正常に行われた時点で、表4-3に示すいずれかのイベント・ポイントをトランザクションのエンティティごとにMediatorに呼び出せます。

表4-3 Mediatorに呼び出されたイベント・ポイントの例

DML型

イベント名

イベントの説明

CREATE

EntityCreated

新しいエンティティが作成されました。

UPDATE

EntityUpdated

既存のエンティティが更新されました。

DELETE

EntityDeleted

既存のエンティティが削除されました。

イベントはデフォルトで呼び出されることはなく、すべてのイベントがカスタムです。イベントを作成する場合、名前とDML操作を適宜指定できます。

イベント・ポイントごとに、どのイベント定義を特定のイベント・ポイントで呼び出すかを指定する必要があります。つまり、各イベント定義をイベント・ポイントに宣言的にマッピングする必要があります。

4.12.3 イベント・ポイントに関する必知事項

イベント・デリバリは現在のデータベース・トランザクションの外部で発生し、非同期です。そのため、次がサポートされています。

- イベント配信がトランザクションの一部であるトランザクション・イベント配信は、このフレームワークではサポートされていません。

- サブスクライバがイベントの受信を確認するまで公開元がその後の処理を待機する同期化イベントは、このフレームワークではサポートされていません。

4.12.4 ビジネス・イベントの作成方法

ビジネス・イベントを作成するには、概要エディタの「ビジネス・イベント」ページを使用します。

始める前に:

ビジネス・イベントの動作方法に関する知識が役立つ場合があります。詳細は、「ビジネス・イベントの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

ビジネス・イベントを作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、ビジネス・イベントを定義するエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビジネス・イベント」ナビゲーション・タブをクリックします。

3. 「ビジネス・イベント」ページで、「イベント定義」セクションを拡張し、「新規」アイコンをクリックします。

4. 「ビジネス・イベント定義の作成」ダイアログで、EmployeeContactInfoChangedなど、このイベントを説明する名前を指定します。

5. ペイロード表で、「新規」および「削除」をクリックし、このイベントの適切な属性を選択します。

または、セルをダブルクリックして、適切な属性を選択します。

注意:

エンティティ属性列には、サポートされているタイプの属性のみ表示されます。ClobDomain属性はサポートされていますが、非常に大きいCLOBデータはパフォーマンスに影響を与えることがあります。

6. 「送信された値」フィールドで、値を「常に」送信するか、「変更された場合のみ」送信するか選択します。

「変更された場合のみ」オプションを選択すると、ペイロードでは属性がオプションとみなされるため、最高のパフォーマンスが得られます。デフォルトの「常に」のままにすると、値が変更されているかどうかを問わず、ペイロードは属性を必要とします。ペイロードの効率性の詳細は、「ペイロードに関する必知事項」を参照してください。

7. 矢印ボタンを使用して、属性の順序を並べ替えます。

属性が表示される順序により、生成されたXSDでの順序が定義されます。XSDを使用してファブリック・メディエータとBPELプロセスを作成するため、最も頻繁にアクセスする属性を最上位に配置できます。

8. 「OK」をクリックします。

定義するビジネス・イベントごとにこの手順を繰り返します。イベントを公開するには、「ビジネス・イベントの公開ポイントの定義方法」を参照してください。

4.12.5 ビジネス・イベント作成時の処理内容

ビジネス・イベントを作成すると、次の例に示すように、エンティティ・オブジェクトのXMLファイルがイベント定義により更新されます。

<EventDef
Name="CustBusEvent1">
<Payload>
<PayloadItem
AttrName="Id"/>
<PayloadItem
AttrName="PaymentOptionId"/>
<PayloadItem
AttrName="PaymentTypeEO.Id"
SendOnlyIfChanged="true"/>
</Payload>
</EventDef>

またJDeveloperでは、イベント・スキーマの関連XSDファイルおよびエンティティ・オブジェクトのイベント定義(EDL)ファイルが生成されます。次の例に示すように、EDLファイルにはイベント定義があります。

<definitions
targetNamespace="http://oracle/summit/model/entities/events/edl/OrdEO"
xmlns:ns0="http://oracle/summit/model/entities/events/schema/OrdEO"
xmlns="http://schemas.oracle.com/events/edl">
<schema-import
namespace="http://oracle/summit/model/entities/events/schema/OrdEO"
location="OrdEO.xsd"/>
<event-definition name="CustBusEvent1">
<content element="ns0:CustBusEvent1Info"/>
</event-definition>
</definitions>

XSDファイルでは、必須の属性とオプションの属性を指定できます。必須属性は、「送信された値」-「常に」に設定されたもので、オプション属性は、「送信された値」を「変更された場合のみ」に変更されたものです。

次の例は、ビジネス・イベントのXSDイベント・スキーマを示しています。

<?xml version = '1.0' encoding = 'UTF-8'?>
<xs:schema targetNamespace="http://oracle/summit/model/entities/events/schema/OrdEO" xmlns="http://oracle/summit/model/entities/events/schema/OrdEO"
elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CustBusEvent1Info">
<xs:complexType>
<xs:sequence>
<xs:element name="Id" type="DecimalValuePair" minOccurs="1"/>
<xs:element name="PaymentOptionId" type="IntValuePair" minOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="ValuePair" abstract="true"/>
<xs:complexType name="IntValuePair">
<xs:complexContent>
<xs:extension base="ValuePair">
<xs:sequence>
<xs:element name="newValue" minOccurs="0">
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="value" type="xs:int"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="oldValue" minOccurs="0">
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="value" type="xs:int"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="DecimalValuePair">
<xs:complexContent>
<xs:extension base="ValuePair">
<xs:sequence>
<xs:element name="newValue" minOccurs="0">
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="value" type="xs:decimal"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="oldValue" minOccurs="0">
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="value" type="xs:decimal"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>

4.12.6 ペイロードに関する必知事項

ビジネス・イベントのペイロードは、関連付けられたエンティティ・オブジェクトの属性で構成されます。ビジネス・イベントのペイロード属性は、イベントの作成者によって定義されます。自動的に最適化されるわけではありません。イベントを定義するときに、属性を「常に」または「変更された場合のみ」送信するとしてマークできます。作成時に起動されるイベントでは、新しい値のみが送信されます。更新または削除時に起動されるイベントでは、新規および既存の値が送信されますが、「送信された値」設定に基づいて該当の属性のみです。最高のパフォーマンスを得るには、削除イベントでは主キー属性のみを含める必要があります。

コンポジット・シナリオ(発注書と明細項目など)をサポートするために、子エンティティは親エンティティで定義されたイベントを呼び出すことができ、子エンティティで定義されたイベントには親エンティティからの属性を含めることができます。子エンティティが親エンティティのイベントを呼び出す場合、子エンティティによるイベントの呼出し回数に関係なく、トランザクションごとに特定のトップレベル・エンティティについて1つのイベントのみが呼び出されます。

エンティティ・サブタイプのケースでは(たとえば、Staffエンティティ・オブジェクトはPersonsエンティティのサブタイプです)、ADFビジネス・コンポーネントではビジネス・イベントのオーバーライドはサポートされません。ビジネス・イベントのサブスクライバは、イベント名を使用してイベントをリスンするため、イベントをオーバーライドすると、イベントのサブスクライバは自分に対するものではないペイロード・データを受信してしまう可能性があります。したがって、この機能はサポートされていません。

ビジネス・イベントを定義する際は、ClobDomain属性はサポートされていますが、非常に大きなCLOBデータはパフォーマンスに影響が与える可能性があることを考慮してください。

4.12.7 ビジネス・イベントの公開ポイントの定義方法

ビジネス・イベントの公開ポイントを定義するには、エンティティ・オブジェクトの概要エディタの「ビジネス・イベント」ページを使用します。

始める前に:

ビジネス・イベントがアプリケーションで使用される方法に関する知識が役立つ場合があります。詳細は、「ビジネス・イベントの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

「ビジネス・イベントの作成方法」の説明に従って、イベント定義が公開前に作成されている必要があります。

ビジネス・イベントの公開ポイントを定義する方法:

1. 「アプリケーション」ウィンドウで、公開するビジネス・イベント含むエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビジネス・イベント」ナビゲーション・タブをクリックします。

3. 「ビジネス・イベント」ページで、「イベント公開」セクションを拡張し、「イベント公開の編集」アイコンをクリックします。

4. 「イベント公開の編集」ダイアログで、「新規」をクリックし、新しいイベントを作成します。

5. イベント列で新しいセルをダブルクリックし、適切なイベントを選択します。

6. 「イベント・ポイント」列で対応するセルをクリックし、適切なイベント・ポイント・アクションを選択します。

7. オプションで、呼出し条件Raise Conditions表を使用して、イベントを呼び出す条件を定義できます。

8. 「OK」をクリックします。

4.12.8 ビジネス・イベントをサブスクライブする方法

ビジネス・イベントを作成したら、そのイベントをサブスクライブし、応答することができます。

注意:

ビジネス・イベントをサブスクライブしたり、JDeveloperでSOAコンポジット・アプリケーションとプロジェクトを作成してデプロイしたりするには、Oracle SOA Suite拡張機能をインストールする必要があります。JDeveloperのこの拡張機能のインストールの手順は、『Oracle JDeveloperのインストール』を参照してください。Oracle SOA Suiteの機能の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。

始める前に:

ビジネス・イベントに関する知識が役立つ場合があります。詳細は、「ビジネス・イベントの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

また、次のタスクを完了する必要があります。

- 「ビジネス・イベントの公開ポイントの定義方法」の説明に従ってビジネス・イベントを公開します。

ビジネス・イベントをサブスクライブするには:

1. ファイル・システムを使用して、ビジネス・イベントのXSDおよびイベント定義ファイルをSCAプロジェクトのソース・パスにコピーします。

2. JDeveloperで、ビジネス・イベントをサブスクライブするSCAプロジェクトを開きます。

3. 「アプリケーション」ウィンドウで、ビジネス・イベントをサブスクライブするSCAプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

4. 「新規ギャラリ」で、「SOA層」を展開し、「サービス・コンポーネント」を選択したら、「メディエータ」を選択し、「OK」をクリックします。

5. 「メディエータの作成」ダイアログで、図4-15に示すように、「イベントのサブスクライブ」テンプレートを選択します。

図4-15 「メディエータの作成」ダイアログの「イベントのサブスクライブ」

6. 「追加」アイコンをクリックして、イベントを追加します。

7. 「イベント・チューザ」ダイアログで、「参照」アイコンをクリックしてイベントの定義ファイルにナビゲートして選択し、「OK」をクリックします。

8. 「メディエータの作成」ダイアログでは、オプションで「一貫性」オプションを選択し、イベントの「フィルタ」を選択できます。

9. 「OK」をクリックします。

結果として生成されたメディエータ(.mplanファイル)が概要エディタに表示されます。

10. 概要エディタで、「ルーティング・ルール」セクションの「追加」アイコンをクリックして、イベントへの対応方法のルールを追加します。

4.13 エンティティ・オブジェクトのカスタムJavaクラスの生成

この章でこれまで説明してきたように、エンティティ・オブジェクトのデータベース対話機能および多くの宣言的実行時機能はすべて、カスタムJavaコードを使用せずに実現できます。これらの宣言的機能を超えてエンティティにカスタム・ビジネス・ロジックを実装する必要がある場合、カスタム・コードを必要とするエンティティに対してJava生成を有効化する必要があります。通常、カスタム・エンティティ・オブジェクトおよびエンティティ定義クラスで記述、使用およびオーバーライドする一般的なコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

ベスト・プラクティス

ADFビジネス・コンポーネントを初めて使用する開発者には、ベース・フレームワーク・クラスをオーバーライドして、すべての生成されたカスタムJavaクラスがカスタマイズされた動作を選択できるようにすることをお薦めします。この方法は、個々のエンティティ・オブジェクトおよびビュー・オブジェクトのカスタム・クラスの作成より優先されます。カスタム・コンポーネントを生成するときは、「プロジェクト・プロパティ」ダイアログの「ADFビジネス・コンポーネント」→「ベース・クラス」ページで、フレームワーク・クラスをオーバーライドするように指定します。詳細は、「ビジネス・コンポーネント機能の拡張」を参照してください。

4.13.1 カスタム・クラスの生成方法

エンティティ・オブジェクトのカスタムJavaクラスの生成を有効にするには、概要エディタの「Java」ページを使用します。

始める前に:

カスタムJavaクラスに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトのカスタムJavaクラスの生成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティ・オブジェクトのカスタムJavaクラスを生成するには:

1. 「アプリケーション」ウィンドウで、カスタムJavaクラスを生成するエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」アイコンをクリックします。

3. 「Javaオプションの選択」ダイアログで、生成するJavaクラスのタイプを選択します。

- エンティティ・オブジェクト・クラス - 最も頻繁にカスタマイズします。このクラスは、基礎となるデータベース表の各行を示します。

- エンティティ・コレクション・クラス - カスタマイズすることはまれです。

- エンティティ定義クラス - カスタマイズする頻度は低くなります。このクラスは、エンティティ行を管理し、その構造を定義する関連クラスを示します。

4. 「OK」をクリックします。

4.13.2 カスタム・クラス生成時の処理

生成するカスタムJavaクラスを1つ以上選択すると、指定したJavaファイルが作成されます。たとえば、summit.model.entities.OrdEOという名前のエンティティ・オブジェクトの場合、そのカスタムJavaファイルのデフォルト名は、エンティティ・オブジェクト・クラスに対してはOrdEOImpl.java、エンティティ定義クラスに対してはOrdEODefImpl.javaになります。これらのファイルは両方とも、コンポーネントのXMLドキュメント・ファイルと同じ../summit/model/entitiesディレクトリに作成されます。

エンティティ・オブジェクトのJava生成オプションは、概要エディタの「Java」ページに後でアクセスしてもそのまま反映されています。XML定義ファイルの場合と同様、このエディタでどのような変更を行っても、カスタムJavaクラスで生成されたコードは最新の状態に保たれます。後でなんらかの理由によりカスタムJavaファイルが必要なくなった場合は、「Java」ページで関連するオプションを無効にすると、カスタムJavaファイルを削除できます。

4.13.3 エンティティ属性アクセッサの生成時の処理

カスタム・エンティティ・オブジェクト・クラスの生成を有効にする場合、「アクセッサ」オプションも有効にすると、エンティティ・オブジェクトの属性ごとにgetterメソッドおよびsetterメソッドが生成されます。

注意:

最終的なハードコードされたメソッド名によりエンティティ行とビュー行の最適化またはカスタマイズが制限されるため、アクセッサはビジネス・ニーズ(ビュー行をJavaインタフェースとしてクライアントに公開する必要があるなど)がある場合のみ生成します。

たとえば、OrdEOエンティティ・オブジェクトには、対応するカスタム・クラスOrdEOImpl.javaがあり、(次の例に示すような)メソッドがあります。

public DBSequence getId() { ... }
public void setId(DBSequence value) { ... }

public Date getDateOrdered() { ... }
public void setDateOrdered(Date value) { ... }

public Integer getPaymentTypeId() { ... }
public void setPaymentTypeId(Integer value) { ... }

public Number getCustomerId() { ... }
public void setCustomerId(Number value) { ... }

public String getOrderFilled() { ... }
public void setOrderFilled(String value) { ... }

これらのメソッドを使用して行データを操作すると、コンパイル時にデータ型の使用方法が正しいかどうかがチェックされます。つまり、CustomerId属性の値を取得するために次のようなコードを記述するかわりに、

Number customerId = (Number)order.getAttribute("CustomerId");

次のようなコードを記述できます。

Number customerId = order.getCustomerId();

後者の方法では、CustomerIdではなく誤ってCustomerCodeと入力したときにJavaコンパイラによって入力ミスが捕捉されます。

// spelling name wrong gives compile error
Number customerId = order.getCustomerCode();

エンティティ・オブジェクトのアクセッサ・メソッドが生成されていない場合、次のような不適切なコード行をコンパイラで捕捉できません。

// Both attribute name and type cast are wrong, but compiler cannot catch it
String customerId = (String)order.getAttribute("CustomerCode");

これには、スペルが正しくない属性名とキャストの型が誤っている戻り値getAttribute()が両方とも含まれています。EntityImplベース・クラスが実装するRowインタフェース上で汎用APIを使用する場合、このようなエラーはコンパイル時に捕捉されないため、実行時に例外が発生します。

4.13.4 カスタムJavaファイルの操作方法

図4-16のように、カスタムJavaクラスの生成を有効にした場合、これらは、エンティティ・オブジェクトの「アプリケーション・ソース」ノードの下にも子ノードとして表示されます。すべてのADFコンポーネントと同様、「アプリケーション」ウィンドウでエンティティ・オブジェクトを選択すると、「構造」ウィンドウには、エンティティの構造ビューが表示されます。カスタムJavaファイルのソース・コードを表示または操作する必要がある場合、ソース・エディタでファイルを開く方法は複数あります。

- 図4-16のように、Javaファイルを右クリックし、「開く」を選択します。

- 「構造」ウィンドウでノードの項目を右クリックし、「ソースへ移動」を選択します。

- 概要エディタのJavaページのリンクをクリックできます。

図4-16 エンティティ・オブジェクトのカスタムJavaクラスの表示および操作

4.13.5 カスタムJavaクラスに関する必知事項

JDeveloperで生成されるカスタムJavaクラスにより、エンティティ・オブジェクトのベース・クラスを拡張して、生成コードの整合性を維持しながらカスタム・コードを実装できる柔軟性があります。次の各項では、カスタムJavaクラスの詳細について説明しています。

4.13.5.1 エンティティ・オブジェクトのフレームワーク・ベース・クラス

XML専用エンティティ・オブジェクトを使用する場合、実行時には、その機能はデフォルトのADFビジネス・コンポーネント実装クラスによって提供されます。生成される各カスタムJavaクラスによって適切なADFビジネス・コンポーネント・ベース・クラスが拡張されるため、コードでは、デフォルトの動作を継承し、このクラスを簡単に追加またはカスタマイズできます。エンティティ・オブジェクト・クラスはEntityImplを拡張し、エンティティ定義クラスはEntityDefImplを拡張し、エンティティ・コレクション・クラスはEntityCacheを拡張します。これらのベース・クラスはoracle.jbo.serverパッケージ内にあります。

4.13.5.2 カスタム・コンポーネント・ファイルに安全に追加する方法

開発者によっては、生成されたJavaソース・ファイルに独自のコードを追加することを躊躇する場合があります。JDeveloperによって作成および管理される各カスタムJavaソース・コード・ファイルには、独自のカスタム・コードをこのファイルに追加しても安全であることを示す、次のようなコメントがファイルの上部に記載されています。

// ---------------------------------------------------------------------
// ---    File generated by ADF Business Components Design Time.
// ---    Custom code may be added to this class.
// ---    Warning: Do not modify method signatures of generated methods.
// ---------------------------------------------------------------------

「編集」ダイアログで「OK」または「適用」ボタンをクリックしても、ファイルが知らぬ間に再生成されることはありません。かわりに、管理が必要なメソッドはスマートに更新され、独自のカスタム・コードはそのまま残されます。

4.13.5.3 デフォルトのJava生成設定の構成

ビュー・オブジェクトの実行時動作をカスタマイズする必要がある場合や、バインド変数またはビュー行属性へ強く型付けされたアクセスのみ行う場合、ビュー・オブジェクトのカスタムJavaクラスを生成できます。

ADFビジネス・コンポーネントのカスタムJava生成のデフォルト設定を構成するには、メイン・メニューから「ツール」→「プリファレンス」を選択して、「ビジネス・コンポーネント」ページを開き、後で作成するビジネス・コンポーネントで使用するプリファレンスを設定します。ADFビジネス・コンポーネントを初めて使用する開発者には、カスタムJavaクラスを生成しないよう設定することをお薦めします(デフォルト設定)。カスタムJavaコードが必要な状況になった場合、そのコンポーネントに必要なカスタムJavaコードのみを有効にできます。経験を積むにつれ、どのようなデフォルト設定の組合せが最適であるかがわかるようになります。

4.13.5.4 属性索引およびInvokeAccessor生成コード

エンティティ・オブジェクトは、XMLのみ、またはカスタムJavaクラスと組み合せたXMLドキュメントに基づいて機能するように設計されています。このどちらとして使用するかを選択できるように、属性値はエンティティのクラス(XML専用モードでは存在しないファイル)のプライベート・メンバー・フィールドには格納されません。デフォルトでは、実行時にリフレクションを使用して属性列挙が割り当てられ、属性アクセッサが起動されます。

プロジェクトに対してリフレクションを無効にすると、属性には、エンティティのXMLドキュメント・ファイル内の<Attribute>およびアソシエーション関連の<AccessorAttribute>タグのゼロベースの順序に基づいて、このファイルの名前と数値索引が割り当てられます。実行時には、エンティティ行の属性値は、エンティティの属性リスト内における属性の数値的位置による索引が付けられた状態で、EntityImplベース・クラスによって管理される疎配列構造に格納されます。

注意:

リフレクションを無効にするには、「プロジェクト・プロパティ」ダイアログの「オプション」ページにある(「ADFビジネス・コンポーネント」の下の)「リフレクションを使用して属性アクセサを起動」の選択を解除します。

多くの場合、このプライベート実装に関する詳細は、エンティティ・オブジェクトを使用する開発者は理解する必要がないため、重要ではありません。ただし、エンティティ・オブジェクトのカスタムJavaクラスを有効にする場合、エンティティ・オブジェクト・クラスで管理される生成コードの一部にこの実装の詳細が関わってきます。この場合、コードの使用目的を理解している方が賢明です。たとえば、Ordersエンティティ・オブジェクトのカスタムJavaクラスの場合、属性またはアクセッサ属性ごとに対応する生成済の整数列挙があります。JDeveloperでは、これらの定数の値がXMLドキュメント内の属性の順序を正しく反映しているかどうかが確認されます。

また、自動的に管理される、エンティティ・オブジェクト・クラスで強く型付けされたgetterメソッドおよびsetterメソッドでは、これらの属性列挙は次の例のように使用されます。

// In oracle.summit.model.appmodule.OrdersImpl class
/**
* Gets the attribute value for DateOrdered, using the alias name DateOrdered.
* @return the value of DateOrdered
*/
public Date getDateOrdered() {
return (Date)getAttributeInternal(DATEORDERED);
}
/**
* Sets <code>value</code> as the attribute value for DateOrdered.
* @param value to set the DateOrdered
*/
public void setDateOrdered(Date value) {
setAttributeInternal(DATEORDERED, value);
}

エンティティ属性定数に関連する管理コードのもう1つの側面は、getAttrInvokeAccessor()およびsetAttrInvokeAccessor()メソッドです。これらのメソッドにより、数値索引を使用した属性アクセスのパフォーマンスが最適化され、汎用処理の実行時にEntityImplベース・クラスの汎用コードが属性値にアクセスするときの通常のパフォーマンスと同じになります。getAttrInvokeAccessor()メソッドの例を次の例に示します。もう1つのsetAttrInvokeAccessor()メソッドの場合も同様です。

// In oracle.summit.model.appmodule.OrdersImpl class
/**
* getAttrInvokeAccessor: generated method. Do not modify.
* @param index the index identifying the attribute
* @param attrDef the attribute
* @return the attribute value
* @throws Exception
*/

protected Object getAttrInvokeAccessor(int index, AttributeDefImpl attrDef)
throws Exception {
if ((index >= AttributesEnum.firstIndex()) && (index < AttributesEnum.count())) {
return AttributesEnum.staticValues()[index - AttributesEnum.firstIndex()].get(this);
}
return super.getAttrInvokeAccessor(index, attrDef);
}

属性と索引に関連して生成されたこのコードに関する経験則は、次のとおりです。

推奨事項

- 必要に応じて、強く型付けされた属性のgetterメソッドおよびsetterメソッドの内部にカスタム・コードを追加してください。

- 概要エディタを使用して、エンティティ・オブジェクト属性の順序または型を変更してください。
getterメソッドおよびsetterメソッドのJavaシグネチャや関連するXMLドキュメントは、自動的に変更されます。

非推奨事項

- getAttrInvokeAccessor()メソッドおよびsetAttrInvokeAccessor()メソッドは変更しないでください。

- 属性索引番号の値は手動で変更しないでください。

注意:

ソース・コントロールのマージ競合やその他の理由により、生成された属性列挙を手動で編集する必要がある場合、対応するエンティティ・オブジェクトのXMLドキュメントの<Attribute>および<AccessorAttribute>タグの順序がゼロベースの順序に反映されていることを確認する必要があります。

4.13.6 カスタム・エンティティ・クラス参照を使用した比較のプログラム的な例

カスタム・エンティティ・クラスを参照する強く型付けされたエンティティを使用する場合と汎用エンティティ参照で作業する場合の違いをより明確に評価するには、次の例を検討してください。次の例は、カスタム・アプリケーション・モジュール・クラス(AppModuleImpl.java)内の強く型付けされたエンティティ参照のバージョンの1つを示しています。重要な違いは、次のとおりです。

- 属性アクセスは、強く型付けされた属性アクセッサを使用して実行されます。

- アソシエーションのアクセッサ属性により、アソシエーションの反対側にある強く型付けされたエンティティ・クラスが戻されます。

- カスタム・エンティティ・クラスのgetDefinitionObject()メソッドを使用すると、完全修飾されたエンティティ定義名を文字列として使用しないようにできます。

- カスタム・エンティティ・クラスのcreatePrimaryKey()メソッドにより、エンティティのKeyオブジェクトの作成を簡略化します。

package oracle.summit.model.appmodule.service;

import oracle.jbo.ApplicationModule;
import oracle.jbo.JboException;
import oracle.jbo.Key;
import oracle.jbo.Row;
import oracle.jbo.RowSetIterator;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;
import oracle.jbo.domain.DBSequence;
import oracle.jbo.domain.Number;
import oracle.jbo.server.EntityDefImpl;
import oracle.jbo.server.EntityImpl;
import oracle.jbo.server.ViewLinkImpl;

import oracle.summit.base.SummitApplicationModuleImpl;
import oracle.summit.base.SummitViewObjectImpl;
import oracle.summit.model.appmodule.CustomerImpl;
import oracle.summit.model.appmodule.OrdersImpl;
import oracle.summit.model.appmodule.service.common.AppModule;

// ---------------------------------------------------------------------
// ---    File generated by Oracle ADF Business Components Design Time.
// ---    Custom code may be added to this class.
// ---    Warning: Do not modify method signatures of generated methods.
// ---------------------------------------------------------------------
public class AppModuleImpl extends SummitApplicationModuleImpl
implements AppModule {
/* This is the default constructor (do not remove). */
public AppModuleImpl() {
}

private OrdersImpl retrieveOrderById(long orderId) {
EntityDefImpl orderDef = OrdersImpl.getDefinitionObject();
Key orderKey = OrdersImpl.createPrimaryKey(new DBSequence(orderId));
return (OrdersImpl)orderDef.findByPrimaryKey(getDBTransaction(),orderKey);
}

public String findOrderAndCustomer(long orderId) {
OrdersImpl order = retrieveOrderById(orderId);
if (order != null) {
CustomerImpl cust = order.getCustomer();
if (cust != null) {
return "Customer: " + cust.getName() + ", Location: " + cust.getCity();
}
else {
return "Unassigned";
}
}
else {
return null;
}
}

/* Find an Order by Id */
public String findOrderTotal(long orderId) {
OrdersImpl order = retrieveOrderById(orderId);
if (order != null) {
return order.getTotal().toString();
}
return null;
}

/* Update the status of an existing order */
public void updateOrderStatus(long orderId, String newStatus) {
OrdersImpl order = retrieveOrderById(orderId);
if (order != null) {
order.setOrderFilled(newStatus);
try {
getDBTransaction().commit();
}
catch (JboException ex) {
getDBTransaction().rollback();
throw ex;
}
}
}

/* Create a new Customer and Return the new id */
public long createCustomer(String name, String city, Integer countryId) {
EntityDefImpl customerDef = CustomerImpl.getDefinitionObject();
CustomerImpl newCustomer =                (CustomerImpl)customerDef.createInstance2(getDBTransaction(),null);
newCustomer.setName(name);
newCustomer.setCity(city);
newCustomer.setCountryId(countryId);
try {
getDBTransaction().commit();
}
catch (JboException ex) {
getDBTransaction().rollback();
throw ex;
}
DBSequence newIdAssigned = newCustomer.getId();
return newIdAssigned.getSequenceNumber().longValue();
}

/* Custom method in an application module implementation class */
public void doSomeCustomProcessing() {
ViewObject vo = getCustomerView1();
// create secondary row set iterator with system-assigned name
RowSetIterator iter = vo.createRowSetIterator(null);
while (iter.hasNext()) {
Row r = iter.next();
// Do something with the current row.
Integer custId = (Integer)r.getAttribute("Id");
String name  = (String)r.getAttribute("Name");
System.out.println(custId + " " + name);
}
// close secondary row set iterator
iter.closeRowSetIterator();
}

/* Container's getter for CustomerView1.
* @return CustomerView1 */
public SummitViewObjectImpl getCustomerView1() {
return (SummitViewObjectImpl) findViewObject("CustomerView1");
}

/* Container's getter for ItemView1.
* @return ItemView1 */
public SummitViewObjectImpl getItemView1() {
return (SummitViewObjectImpl) findViewObject("ItemView1");
}

/* Container's getter for OrderView1.
* @return OrderView1 */
public SummitViewObjectImpl getOrderView1() {
return (SummitViewObjectImpl) findViewObject("OrderView1");
}

/* Container's getter for ItemView2.
* @return ItemView2 */
public SummitViewObjectImpl getItemView2() {
return (SummitViewObjectImpl) findViewObject("ItemView2");
}

/* Container's getter for OrderView2.
* @return OrderView2 */
public SummitViewObjectImpl getOrderView2() {
return (SummitViewObjectImpl) findViewObject("OrderView2");
}

/*Container's getter for SItemOrdIdFkLink1.
* @return SItemOrdIdFkLink1 */
public ViewLinkImpl getSItemOrdIdFkLink1() {
return (ViewLinkImpl) findViewLink("SItemOrdIdFkLink1");
}

/* Container's getter for SOrdCustomerIdFkLink1.
* @return SOrdCustomerIdFkLink1 */
public ViewLinkImpl getSOrdCustomerIdFkLink1() {
return (ViewLinkImpl) findViewLink("SOrdCustomerIdFkLink1");
}
}

4.14 エンティティ・オブジェクトおよびアソシエーションのプログラム的操作

エンティティ・オブジェクトを直接操作する場合、UIベースのクライアントまたはプログラム的クライアントは常に必要ではありません。アプリケーション・モジュールにアクセスし、そのデータ・モデル内のビュー・オブジェクトを直接操作する際、外部クライアント・プログラム以外には使用する必要がない場合もあります。「ビュー・オブジェクトを使用したSQL問合せの定義」では、強力なアプリケーションを構築するために、ビュー・オブジェクトの柔軟なSQL問合せ機能に、エンティティ・オブジェクトのビジネス・ロジックとデータベースとの自動対話機能とを組み合せる簡単な方法について説明します。この組合せにより、現在のエンド・ユーザーのタスク上のニーズに対応するよう設計され、再使用可能なドメイン・ビジネス・オブジェクト・レイヤー内で一元管理されたビジネス・ロジックを共有する、完全に更新可能なアプリケーション・モジュールのデータ・モデルを作成できます。

ただし、まず重要なのは、ビュー・オブジェクトとエンティティ・オブジェクトを組み合せた能力の利用方法について学習する前に、これらのオブジェクト自体の使用方法について理解することです。これらのオブジェクトについて詳細に学習することにより、これらを単体で使用する必要があるときと、独自のアプリケーションでこれらを組み合せる必要があるときについて理解が深まります。

クライアントはエンティティ・オブジェクトを直接操作できないため、エンティティ・オブジェクトをプログラム的に操作するために記述するコードは、通常カスタム・アプリケーション・モジュール・クラス内または別のエンティティ・オブジェクトのカスタム・クラス内のカスタム・コードになります。

4.14.1 主キーによるエンティティ・オブジェクトの検索方法

エンティティ行にアクセスするには、エンティティ定義と呼ばれる関連オブジェクトを使用します。実行時には、エンティティ・オブジェクトごとに対応するエンティティ定義を利用して、エンティティの構造を記述し、それにしたがってエンティティ・オブジェクトのインスタンスを管理します。アプリケーション・モジュールを作成し、そのカスタムJavaクラスを有効化した後に、特定の注文を戻すメソッドを作成する必要があるとします。これは、次のサンプル・コードに示すretrieveOrderById()メソッドのようになります。

始める前に:

エンティティ・オブジェクトとアソシエーションで動作するためにプログラム的な方法を使用するタイミングに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションのプログラム的操作」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

主キーによるエンティティ・オブジェクトを検索するには:

1. エンティティ定義を検索します。

エンティティ・オブジェクト(Ordersなど)のエンティティ定義を取得するには、EntityDefImplクラスからインポートされた静的なgetDefinitionObject()メソッドにその完全修飾名を渡します。oracle.jbo.serverパッケージ内のEntityDefImplクラスにより、各エンティティ・オブジェクトのエンティティ定義が実装されます。

2. キーを作成します。

検索する主キー属性が含まれるKeyオブジェクトを作成します。たとえば、Ordersエンティティ・オブジェクトの場合、メソッドに引数として渡される単一のorderId値が含まれるキーを作成します。

3. キーを使用してエンティティ・オブジェクトを検索します。

エンティティ定義のfindByPrimaryKey()メソッドを使用して、キーによってエンティティ・オブジェクトを検索し、getDBTransaction()メソッドを使用してアプリケーション・モジュールから取得できる現在のトランザクション・オブジェクトを渡します。エンティティ・オブジェクト行を示す具体的なクラスは、oracle.jbo.server.EntityImplクラスです。

4. オブジェクトまたはそのデータの一部をコール元に戻します。

次のサンプル・コードは、この基本手順を使用して開発したretrieveOrderById()メソッドを示しています。

/* Helper method to return an Order by Id  */
private OrdersImpl retrieveOrderById(long orderId) {
EntityDefImpl orderDef = OrdersImpl.getDefinitionObject();
Key orderKey = OrdersImpl.createPrimaryKey(new DBSequence(orderId));
return (OrdersImpl)orderDef.findByPrimaryKey(getDBTransaction(),orderKey);
}

注意:

oracle.jbo.Keyオブジェクト・コンストラクタは、より一般的な単一の属性値のキー以外にも、複数の属性キーの作成もサポートするためのオブジェクト配列を使用できます。

4.14.2 アクセッサ属性を使用して関連付けられたエンティティへのアクセス方法

SQLコードを必要としないアクセッサ属性に基づいて、関連付けられたエンティティへアクセスするためのメソッドを作成できます。たとえば、メソッドfindOrderAndCustomer()によりオーダーを検索してから、オーダーに割り当てられた顧客を表す、関連付けられたCustomerエンティティ・オブジェクトにアクセスします。アソシエーションを使用して1つのエンティティ・オブジェクトから別のエンティティ・オブジェクトへ簡単にアクセスする方法の詳細は、「アソシエーションの作成と構成」を参照してください。

同じアクセッサ属性を使用して同じ関連付けられたエンティティを検索するアプリケーション・モジュールの既存メソッドとの競合を防ぐため、この機能をヘルパー・メソッドにリファクタし、必要に応じてアプリケーション・モジュールの任意の場所で再使用できます。たとえば、次のサンプル・コードに示すように、retrieveOrderById()メソッドを作成して注文を検索する機能をリファクタできます。

始める前に:

エンティティ・オブジェクトとアソシエーションで動作するためにプログラム的な方法を使用するタイミングに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションのプログラム的操作」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

アクセッサ属性を使用して関連付けられたエンティティ・オブジェクトにアクセスするには:

1. アクセッサ属性を使用して、関連付けられたエンティティを検索します。

たとえば、findOrderAndCustomer()メソッドでは、retrieveOrderById()ヘルパー・メソッドを使用して、IDによってOrdersエンティティ・オブジェクトを取得します。

2. アクセッサ属性を使用して関連付けられたエンティティにアクセスします。

属性のgetterメソッドを使用して、アソシエーション・アクセッサ名を渡し、関連の反対側にあるエンティティ・オブジェクトを取得できます。(アソシエーション・アクセッサをより直感的な名前に変更する方法の詳細は、「エンティティ・アソシエーションのアクセッサ名の変更方法」を参照。)

3. データの一部をコール元に戻します。

たとえば、indOrderAndCustomer()メソッドでは、戻されたCustomerエンティティに対してgetterメソッドを使用して、割り当てられた顧客の名前と場所を戻します。

関連するCustomerエンティティにアクセスするためにSQLを記述する必要はありません。Ordersエンティティ・オブジェクトとCustomerエンティティ・オブジェクト間のADFアソシエーションで取得された関連情報のみで、データ・ナビゲーションの一般的なタスクを自動化できます。

次の例は、ヘルパー・メソッドを使用するfindOrderCustomer()のコードを示しています。

/*  Access an associated Customer entity from the Order entity   */
public String findOrderAndCustomer(long orderId) {
OrdersImpl order = retrieveOrderById(orderId);
if (order != null) {
CustomerImpl cust = order.getCustomer();
if (cust != null) {
return "Customer: " + cust.getName() + ", Location: " + cust.getCity();
}
else {
return "Unassigned";
}
}
else {
return null;
}
}

4.14.3 既存のエンティティ行の更新または削除方法

エンティティ行を取得した後、エンティティ行は簡単に更新または削除できます。たとえば、このタスクは、次のサンプル・コードに示すupdateOrderStatus()のようなメソッドを追加することにより実行できます。

始める前に:

エンティティ・オブジェクトとアソシエーションで動作するためにプログラム的な方法を使用するタイミングに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションのプログラム的操作」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティ行を更新するには:

1. IDによってOrderを検索します。

updateOrderStatus()メソッドでは、retrieveOrderById()ヘルパー・メソッドを使用して、IDによってOrdersエンティティ・オブジェクトを取得します。

2. 1つ以上の属性を新しい値に設定します。

updateOrderStatus()メソッドでは、EntityImplクラスのsetAttribute()メソッドを使用して、OrderFilled属性の値を渡された新しい値に更新します。

3. トランザクションをコミットします。

アプリケーション・モジュールのgetDBTransaction()メソッドを使用して、現在のトランザクション・オブジェクトにアクセスし、commit()メソッドをコールしてトランザクションをコミットする必要があります。

/* Update the status of an existing order */
public void updateOrderStatus(long orderId, String newStatus) {
OrdersImpl order = retrieveOrderById(orderId);
if (order != null) {
order.setOrderFilled(newStatus);
}
}

エンティティ行の削除のコードもこれと同じですが、既存のエンティティを検索した後、トランザクションをコミットする前に、次の行を使用してエンティティを削除する点が異なります。

// Remove the entity instead
order.remove();

4.14.4 新しいエンティティ行の作成方法

エンティティ定義を使用して既存のエンティティ行を検索する以外にも、エンティティ定義を使用して新しいエンティティ行を作成することもできます。Customerエンティティの場合、次の例のようなcreateCustomer()メソッドを記述することにより、新しい顧客の名前や説明を取得し、この顧客に割り当てられた新しい顧客IDを戻すことができます。この例は、Customerエンティティ・オブジェクトのId属性がすでに更新され、その型がDBSequence型になっていること(「トリガーによってデータベース順序から割り当てられた主キー値の取得方法」を参照)が前提となります。この設定により、アプリケーション・スキーマの表の順序から割り当てられたトリガーの値が、対応するデータベース表から反映されるように属性値がリフレッシュされます。

/* Create a new Customer and Return the new id */
public long createCustomer(String name, String city, Integer countryId) {
EntityDefImpl customerDef = CustomerImpl.getDefinitionObject();
CustomerImpl newCustomer = (CustomerImpl)customerDef.createInstance2(getDBTransaction(),null);
newCustomer.setName(name);
newCustomer.setCity(city);
newCustomer.setCountryId(countryId);
try {
getDBTransaction().commit();
}
catch (JboException ex) {
getDBTransaction().rollback();
throw ex;
}
DBSequence newIdAssigned = newCustomer.getId();
return newIdAssigned.getSequenceNumber().longValue();
}

始める前に:

エンティティ・オブジェクトとアソシエーションで動作するためにプログラム的な方法を使用するタイミングに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションのプログラム的操作」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

エンティティ行を作成するには:

1. エンティティ定義を検索します。

createCustomer()メソッドでは、getDefinitionObject()メソッドを使用して、Customerエンティティのエンティティ定義を検索します。

2. 新しいインスタンスを作成します。

createCustomer()メソッドでは、エンティティ定義に対してcreateInstance2()メソッドを使用して、エンティティ・オブジェクトの新しいインスタンスを作成します。

注意:

このメソッド名の末尾には2があります。「ADFビジネス・コンポーネントのよく使用されるメソッド」の「EntityImplクラス」で説明するように、正規のcreateInstance()メソッドはprotectedアクセス権があり、カスタマイズされるよう設計されています。AttributeList型の2番目の引数は、作成時に指定する必要がある属性値を指定するために使用し、リスト内のすべての属性値を初期化する目的では使用しません。たとえば、このAPIを使用して構成される側の子エンティティ行の新しいインスタンスを作成する場合、構成する側の親エンティティの外部キー属性を2番目の引数としてAttributeListオブジェクトに指定します。これを指定しない場合、InvalidOwnerExceptionが発生します。

3. 属性値を設定します。

createCustomer()メソッドでは、エンティティ・オブジェクトに対して属性のsetterメソッドを使用して、新しいエンティティ行にNameやCityなどの属性の値を割り当てます。

4. トランザクションをコミットします。

createCustomer()メソッドでは、現在のトランザクション・オブジェクトに対してcommit()をコールし、トランザクションをコミットします。

5. トリガーによって割り当てられた顧客IDをコール元に戻します。

createCustomer()メソッドでは、属性のgetterメソッドを使用してId属性の値をDBSequenceとして取得し、さらにgetSequenceNumber().longValue()をコールして、順序番号をlong値としてコール元に戻します。

4.14.5 Oracle順序を使用した主キー値の割当て

新規行を作成する場合、トリガーにより割り当てられた値を使用する(「トリガーによってデータベース順序から割り当てられた主キー値の取得方法」を参照)かわりに、Oracle順序を使用して値を主キーに割り当てることができます。このメタデータ駆動型の方法を使用すると、主キーを取得するためのコードの管理を、複数のエンティティ・オブジェクトにより再使用可能なJavaファイルに一元化できます。

次の例は、エンティティ・オブジェクトが基づくCustomEntityImplという簡単なフレームワーク拡張クラスを示しています。このクラスのオーバーライドされたcreate()メソッドにより、SequenceNameという名前のカスタム属性レベルのメタデータ・プロパティが存在するかどうかがテストされ、検出された場合は、その順序内の次の番号から属性のデフォルト値が移入されます。

始める前に:

エンティティ・オブジェクトとアソシエーションで動作するためにプログラム的な方法を使用するタイミングに関する知識が役立つ場合があります。詳細は、「エンティティ・オブジェクトおよびアソシエーションのプログラム的操作」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

Oracle順序を使用して主キー値を割り当てるには:

1. プロジェクト内にCustomEntityImpl.javaファイルを作成し、次のサンプルに示すコードを挿入します。

2. 「アプリケーション」ウィンドウで、編集するエンティティをダブルクリックします。

3. 概要エディタで、「属性」ナビゲーション・タブをクリックし、編集する属性を選択します。

4. 「詳細」タブをクリックし、 「タイプ」ドロップダウン・リストから「数」を選択します。

5. 「カスタム・プロパティ」タブをクリックし、「追加」アイコンをクリックします。

6. 名前はSequenceNameで値はデータベース・シーケンスの名前にしてカスタム・プロパティを作成します。

たとえば、Deptエンティティでは、DEPT_TABLE_SEQという値を持つDeptno属性に対して、カスタム・プロパティSequenceNameを定義できます。

package sample;

import oracle.jbo.AttributeDef;
import oracle.jbo.AttributeList;
import oracle.jbo.server.EntityImpl;
import oracle.jbo.server.SequenceImpl;

public class CustomEntityImpl extends EntityImpl {
protected void create(AttributeList attributeList) {
super.create(attributeList);
for (AttributeDef def : getEntityDef().getAttributeDefs()) {
String sequenceName = (String)def.getProperty("SequenceName");
if (sequenceName != null) {
SequenceImpl s = new SequenceImpl(sequenceName,getDBTransaction());
setAttribute(def.getIndex(),s.getSequenceNumber());
}
}
}
}

4.14.6 行の削除にかわる削除済フラグを更新する方法

監査のため、表に追加した行を表から物理的に削除できない場合があります。そのような場合は、エンド・ユーザーがユーザー・インタフェースで行を削除する際に、DELETED列の値をNからYに変更し、削除済としてマークします。この処理を行うために、2つのメソッドのオーバーライドを使用して、エンティティ・オブジェクトのデフォルト動作を変更できます。

そのためには、次のタスクを実行する必要があります。

- 「行が削除されたときの削除済フラグの更新」の説明に従って、行が削除されたときに削除済フラグを更新します。

- 「削除のかわりの更新DML操作の強制」の説明に従って、エンティティ・オブジェクトを削除するのではなく更新します。

4.14.6.1 行が削除されたときの削除済フラグの更新

行が削除されたときに削除済フラグを更新するには、エンティティ・オブジェクトのカスタムJavaクラスを有効にし、remove()メソッドをオーバーライドして、super.remove()メソッドを呼び出す前に削除済フラグを設定するようにします。次の例は、エンティティ・オブジェクトのカスタムJavaクラスが、この変更でどのようになるかを示しています。削除された行の属性を設定しようとするとDeadEntityAccessExceptionが発生するため、super.remove()を呼び出す前に属性を設定することが重要です。

この例では、表を変更してDELETED列を追加し、エンティティ・オブジェクトとデータベースの同期を取って、対応するDeleted属性を追加してあるものとします。

行は行セットから削除されますが、エンティティ・キャッシュでDeletedフラグの値はYに変更されています。この動作の実装の第2の部分は、DML操作の実行を要求されたときに、エンティティにDELETEのかわりにUPDATEの実行を強制することです。完全なソリューションのためには、両方の部分を実装する必要があります。

// In your custom Java entity class
public void remove() {
setDeleted("Y");
super.remove();
}

4.14.6.2 削除のかわりの更新DML操作の強制

エンティティ・オブジェクトを削除のかわりに更新するには、doDML()メソッドをオーバーライドし、operationフラグを条件付きで変更するコードを記述します。操作フラグがDML_DELETEの場合は、このコードでかわりにDML_UPDATEに変更します。次の例は、エンティティ・オブジェクトのカスタムJavaクラスが、この変更でどのようになるかを示しています。

この例では、表を変更してDELETED列を追加し、エンティティ・オブジェクトとデータベースの同期を取って、対応するDeleted属性を追加してあるものとします。

オーバーライドしたdoDML()メソッドを配置し、「行が削除されたときの削除済フラグの更新」で説明したオーバーライドされたremove()メソッドを補完することで、対応するエンティティ・オブジェクトの慣用名を持つビュー・オブジェクトからエンティティを削除しようとすると、行が物理的に削除されるかわりに、列DELETEDが更新されます。削除された製品がビュー・オブジェクトの問合せ結果に表示されることを防ぐため、WHERE DELETED = 'N'の製品のみを含むようにWHERE句を変更する必要があります。

// In your custom Java entity class
protected void doDML(int operation, TransactionEvent e) {
if (operation == DML_DELETE) {
operation = DML_UPDATE;
}
super.doDML(operation, e);
}

4.14.7 制約違反を防ぐためのエンティティ・ポスト順序を制御する方法

データベース制約のため、同じトランザクション内でDML操作を実行して複数の関連するエンティティ・オブジェクトに変更を保存するときは、操作の実行順序が重要になる場合があります。外部キー参照を含む新しい行を、参照されている行を挿入する前に挿入しようとすると、データベースで制約違反が発生する可能性があります。コミット時のエンティティ・オブジェクトのデフォルトの処理順序、および必要に応じてその順序をプログラムで変更する方法を理解している必要があります。

注意:

この項の例は、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.controlpostorderパッケージを参照しています。

4.14.7.1 デフォルトの後処理順序

デフォルトでは、トランザクションをコミットすると、保留中の変更リスト内のエンティティ・オブジェクトは、時間順、つまりエンティティがリストに追加された順序で処理されます。つまり、たとえば、新しい従業員(EmpEOエンティティ・オブジェクト)を作成、その後その製品に関連する新しい部門(DeptEOエンティティ・オブジェクト)を作成すると、最初に新しいEmpEOが、2番目に新しいDeptEOが挿入されます。

4.14.7.2 コンポジットとデフォルトの後処理順序

2つのエンティティ・オブジェクトがコンポジットで関連付けられていると、厳密な時間順序が自動的に変更されて、コンポジット関係にある親と子のエンティティ行が制約に違反しない順序で保存されることが保証されます。たとえば、コンポジットされる新しい子のエンティティ行より前に、新しい親のエンティティ行が挿入されます。

4.14.7.3 ポスト順序を制御するためのpostChanges()のオーバーライド

関係のあるエンティティが関連付けられてはいてもコンポジットではない場合は、コードを少し作成して、関連するエンティティが正しい順序で保存されるようにする必要があります。

4.14.7.3.1 実際のポスト順序の問題の観察

次の例のAppModuleアプリケーション・モジュールのnewEmployeeForNewDepartment()カスタム・メソッドについて考えます。このメソッドは、一連のパラメータを受け取って、次の処理を行います。

1. 新しい従業員を作成します。

2. 新しい部門を作成します。

3. 従業員が関係する部門IDを設定します。

4. トランザクションをコミットします。

5. 新しい従業員IDと部門IDを保持するためのResult Java Beanを作成します。

6. 結果を返します。

注意:

このコードでは、EmpEO.IdとDeptEO.Idには、順序に基づいて主キーを設定するためDBSequenceにデータ型が設定されているものと想定しています。

// In AppModuleImpl.java
public Result newEmployeeForNewDepartment(String deptName,
Number regionId,
String lastName,
String firstName,
Number salary)  {

oracle.jbo.domain.Date today = new Date(Date.getCurrentDate());
Number objectId = new Number(0);

// 1. Create a new employee
EmpEOImpl newEmp = createNewEmp();
// 2. Create a new department
DeptEOImpl newDept = createNewDept();
newDept.setName(deptName);
newDept.setRegionId(regionId);
// 3. Set the department id to which the employee pertains
newEmp.setDeptId(newDept.getId().getSequenceNumber());
newEmp.setLastName(lastName);
newEmp.setFirstName(firstName);
newEmp.setUserid((firstName + "." + lastName).substring(8));
newEmp.setSalary(salary);
// 4. Commit the transaction
getDBTransaction().commit();
// 5. Construct a bean to hold new department id and employee id
Result result = new Result();
result.setEmpId(newEmp.getId().getSequenceNumber());
result.setDeptId(newDept.getId().getSequenceNumber());
// 6. Return the result
return result;
}
private DeptEOImpl createNewDept(){
EntityDefImpl deptDef = DeptEOImpl.getDefinitionObject();
return (DeptEOImpl) deptDef.createInstance2(getDBTransaction(), null);
}
private EmpEOImpl createNewEmp(){
EntityDefImpl empDef = EmpEOImpl.getDefinitionObject();
return (EmpEOImpl) empDef.createInstance2(getDBTransaction(), null);
}

このメソッドをアプリケーション・モジュールのクライアント・インタフェースに追加し、テスト用のクライアント・プログラムからテストすると、エラーが発生します。

oracle.jbo.DMLConstraintException: JBO-26048:
Constraint "S_EMP_DEPT_ID_FK" is violated during post operation
"Insert" using SQL statement
"BEGIN INSERT INTO S_EMP(ID,LAST_NAME,FIRST_NAME,USERID,DEPT_ID,SALARY)
VALUES (:1,:2,:3,:4,:5,:6) RETURNING ID INTO :7; END;".
: ORA-02291: integrity constraint (SUMMIT_ADF.S_EMP_DEPT_ID_FK)
violated - parent key not found

S_EMP行が挿入されたとき、その外部キーDEPT_IDの値に対応する行がS_DEPT表に存在しないというエラーをデータベースが出力します。これは次の理由で発生します。

- コードにより、部門の前に従業員が作成された。

- エンティティ・オブジェクトEmpEOとDeptEOが、関連付けられてはいるがコンポジットではない。

- 新しいエンティティ行を保存するDML操作が時間順に行われるため、新しいDeptEOより前に新しいEmpEOが挿入される。

4.14.7.3.2 従業員より前に部門をポストを強制

まだ有効でない部門IDで従業員を追加しようとする問題を修復するには、例のコード行を並べ替えて、最初にDeptEOを、次にEmpEOを作成できます。目先の問題にはこれで対処できますが、別のアプリケーション開発者が間違った順序でエンティティを作成する可能性が残っています。

さらによい解決策は、エンティティ・オブジェクト自体がポスト順序を処理するようにして、作成順序に関係なくポストが正しく動作するようにすることです。そのためには、関連するエンティティ・オブジェクトを参照する外部キー属性を含むエンティティのpostChanges()メソッドをオーバーライドし、次の例に示すようなコードを記述します。この例では、DeptEOエンティティに対する外部キーが含まれているのはEmpEOであるため、EmpEOを更新し、条件によっては、サービス・リクエストをポストする前に関連する新しいDeptEOを強制的にポストするようにします。

このコードでは、ポストしているエンティティがSTATUS_NEW状態またはSTATUS_MODIFIED状態のいずれかであるかを検査します。その場合は、getDeptEO()アソシエーション・アクセッサを使用して、関連する製品を取得します。関連するDeptEOのポスト状態もSTATUS_NEWである場合は、super.postChanges()をコールして自分のDMLを実行する前に、まず関連する親行のpostChanges()をコールします。

この例を実行すると、newEmployeeForNewDepartment()メソッドのコードの作成順序を変更しなくても、エンティティは、新しいDeptEOが先で新しいEmpEOが後という正しい順序でポストされます。しかし、まだ問題があります。まだ制約違反が発生しますが、今度は理由が異なります。

DeptEOエンティティ・オブジェクトの主キーがユーザーによって割り当てられている場合は、次の例のコードのみで、ポスト順序を修正して制約違反に対処できます。しかし、DeptEO.Idはデータベース順序から割り当てられ、ユーザー割当てではありません。そのため、新しいDeptEOエンティティ行がポストされる時点で、データベースが割り当てる順序値を反映するように、Id属性が更新されます。新しいサプライヤを参照するEmpEO.DeptId属性の外部キー値は、サプライヤID値のこの更新により親を失います。製品行が保存されるときには、S_DEPT_IDの値と一致する行がS_DEPT表にまだ存在しないため、制約違反が再び発生します。次の2つの項では、このような親を失うという問題に対処するための解決策について説明します。

// In EmpEOImpl.java
public void postChanges(TransactionEvent transactionEvent) {
/* If current entity is new or modified */
if (getPostState() == STATUS_NEW ||
getPostState() == STATUS_MODIFIED) {
/* Get the associated dept for the employee */
DeptEOImpl dept = getDeptEO();
/* If there is an associated dept */
if (dept != null) {
/* And if it's post-status is NEW */
if (dept.getPostState() == STATUS_NEW) {
/*
* Post the department first, before posting this
* entity by calling super below
*/
dept.postChanges(transactionEvent);
}
}
}
super.postChanges(transactionEvent);
}

注意:

このプログラム的な手法(Java EEアプリケーション・レイヤーで問題を解決する)のかわりに、データベース・レイヤーで遅延可能制約を使用する方法もあります。データベース・スキーマを制御できる場合は、外部キー制約をDEFERRABLE INITIALLY DEFERREDとして定義する(または変更する)ことを検討します。このデータベース設定により、データベースは制約の検査をトランザクションのコミット時まで遅延します。これが実行されると、COMMIT時までにすべての適切な関連する行が保存されている場合、アプリケーションはDML操作を任意の順序で実行でき、親/子の順序は緩和されます。ただし、親の主キーが順序から割り当てられる場合は、外部キーの値をカスケード更新するために、「DBSequenceの値が設定される主キーに基づくアソシエーション」と「DBSequence割当ての外部キーに対する参照の更新」で説明するコードを作成する必要があります。

4.14.7.3.3 DBSequenceの値が設定される主キーに基づくアソシエーション

「トリガーによってデータベース順序から割り当てられた主キー値の取得方法」で説明されているように、エンティティ・オブジェクトの主キー属性がDBSequence型の場合は、そのオブジェクトが作成されるトランザクションの間、キーの数値は一時的に一意の負の値になります。同じトランザクション内で関連するエンティティの値を作成すると、これらの間の関連は、この一時的な負のキー値に基づくことになります。DBSequenceの値が主キーであるエンティティ・オブジェクトをポストすると、その主キーはデータベースが割り当てる正しい順序番号を反映して更新されますが、それに関連付けられたエンティティは一時的な負の外部キー値を保持したままで親を失います。

コンポジットに基づくエンティティ・オブジェクトの場合は、親エンティティ・オブジェクトのDBSequence値が設定されている主キーが更新されると、コンポジットされる子エンティティ行の一時的な負の外部キー値は、親の更新されたデータベース割当ての主キーを反映して、自動的に更新されます。つまり、コンポジット・エンティティの場合、親を失うという問題は発生しません。

ただし、エンティティ・オブジェクトがコンポジットではないアソシエーションによって関連付けられている場合は、コードを作成して、一時的に負の値を参照する関連エンティティ行を、更新されたデータベース割当ての主キー値で更新する必要があります。次の項では、必要なコードについて説明します。

4.14.7.3.4 DBSequence割当ての外部キーに対する参照の更新

この例のDeptEOのようなエンティティがDBSequence値の主キーを持ち、それと関連付けられた(ただしコンポジットではない)他のエンティティによって外部キーとして参照される場合は、次のサンプル・コードに示すように、この新しいDeptEO行を参照する可能性のあるエンティティ行の行セットに対する参照を保存するように、postChanges()メソッドをオーバーライドする必要があります。

現在のDeptEO行のステータスがNewの場合は、getEmp()アソシエーション・アクセッサから戻るRowSetの値を、super.postChanges()をコールする前に、newEmployeesBeforePostメンバー・フィールドに割り当てます。

この保存したRowSetオブジェクトは、後で次の例で示されているオーバーライドされたrefreshFKInNewContainees()メソッドで使用します。新しいエンティティ行は、このメソッドを呼び出すことで、postChanges()を呼び出す前にそれを参照していた他のエンティティ行を更新された主キー値でカスケード更新できます。newEmployeesBeforePost行セット(NULLでない場合)のEmpEOImpl行を反復処理し、それぞれのサプライヤID値に、新しくポストされたDeptEOエンティティの、順序から割り当てられた新しいサプライヤ値を設定します。

// In DeptEOImpl.java
protected void refreshFKInNewContainees() {
if (newEmployeesBeforePost != null) {
Number newDeptId = getId().getSequenceNumber();
/*
* Process the rowset of employees that referenced
* the new department prior to posting, and update their
* Id attribute to reflect the refreshed Id value
* that was assigned by a database sequence during posting.
*/
while (newEmployeesBeforePost.hasNext()){
EmpEOImpl emp =
(EmpEOImpl)newEmployeesBeforePost.next();
emp.setDeptId(newDeptId);
}
closeNewProductRowSet();
}
}

この変更を実装すると、「実際のポスト順序の問題の観察」のサンプルは、データベース制約違反を起こさないで動作するようになります。

// In DeptEOImpl.java
RowSet newEmployeesBeforePost = null;
public void postChanges(TransactionEvent transactionEvent) {
/* Only bother to update references if Department is a NEW one */
if (getPostState() == STATUS_NEW) {
/*
* Get a rowset of employees related
* to this new department before calling super
*/
newEmployeesBeforePost = (RowSet)getEmpEO();
}
super.postChanges(transactionEvent);
}

4.14.8 エンティティ・アソシエーションの高度な手法

ここでは、エンティティ・オブジェクト間のアソシエーションの処理に関する高度な手法について説明します。

4.14.8.1 複雑なアソシエーションを実装するためのアソシエーションSQL句の変更

対応する属性の等価性のみに基づく関連より複雑なエンティティ間の関連を表す必要があるときは、アソシエーションのSQL句を変更して、さらに複雑な条件を組み込むことができます。たとえば、2つのエンティティ間の関連が有効期間に依存する場合があります。ProductをSupplierと関連付けることができても、サプライヤの名前が時間とともに変化する場合は、その製品行が使用されている(または、使用されていた)期間を記録するEFFECTIVE_FROM列とEFFECTIVE_UNTIL列が、SUPPLIERS表の各行に追加されている可能性があります。その場合、Productとそれが関連付けられるSupplierの間の関係は、SupplierId属性の一致と、製品のRequestDateがサプライヤのEffectiveFromの日付とEffectiveUntilの日付の間にあるという条件の組合せによって記述されます。

このような複雑な関係は、概要エディタで、アソシエーションに対して設定できます。まず、「関係」ページで、必要な追加属性のペアを追加します。この例では、(EffectiveFrom、RequestDate)のペアと、(EffectiveUntil、RequestDate)のペアです。次に、「問合せ」ページで「WHERE」フィールドを編集して、WHERE句を次のように変更できます。

(:Bind_SupplierId = Product.SUPPLIER_ID) AND
(Product.REQUEST_DATE BETWEEN :Bind_EffectiveFrom
AND :Bind_EffectiveUntil)

アソシエーションの作成の詳細は、「アソシエーションの作成と構成」を参照してください。

4.14.8.2 エンティティ・レベルでのビュー・リンク・アクセッサ属性の公開

2つのエンティティ・ベースのビュー・オブジェクト間のビュー・リンクを作成する際、「ビュー・リンク・プロパティ」ページに、ビュー・オブジェクト・レベルとエンティティ・オブジェクト・レベルの両方でビュー・リンク・アクセッサ属性を公開するオプションがあります。デフォルトでは、ビュー・リンク・アクセッサは、リンク先ビュー・オブジェクトのビュー・オブジェクト・レベルでのみ公開されます。「エンティティ・オブジェクト: SourceEntityName」チェックボックスまたは「エンティティ・オブジェクト: DestinationEntityName」チェックボックスから適切なものを選択することで、リンク元またはリンク先のエンティティ・オブジェクトの一方または両方にビュー・リンク属性をJDeveloperにより含めることができます。これにより、エンティティ・オブジェクトが関連するビュー行のセットにアクセスするための便利な方法が提供されます。特に、行を生成するための問合せが現在の行の属性にのみ依存する場合に有効です。

4.14.9 カスタム・エンティティ・オブジェクトのメソッドに関する必知事項

エンティティ・オブジェクト・クラスで実装するカスタム・メソッドは、アプリケーション・モジュールの戻り型に依存できません。実行時には、ある場合、そのような依存性を持って実行されるメソッドがClassCastExceptionをスローすることがあります。戻されたアプリケーション・モジュールが、期待された型と一致しないからです。そのため、実装するカスタム・メソッドには、次に示すように、特定のアプリケーション・モジュールやビュー・オブジェクトの実装を取得するコードを記述しないことをお薦めします。

((MyAM)getTransaction().getRootApplicationModule()).getMyVO

特に、次のシナリオにおいて、上のコードがClassCastExceptionで失敗します。

- コード内のエンティティ・オブジェクトが、別のビュー・オブジェクト(メソッドで参照しているビュー・オブジェクト以外)のコンテキストで使用されている場合。アプリケーションでは、複数のビュー・オブジェクト定義が同じエンティティ・オブジェクトにマップされることがあるため、ビュー・オブジェクトへの依存性を持つメソッドが、ADFビジネス・コンポーネント・ランタイムで一貫性を持って実行されることは保証できません。

- ルート・アプリケーション・モジュールの下に、手動でアプリケーション・モジュールをネストする場合。この場合、ネストされたアプリケーション・モジュールが同じTransactionオブジェクトを共有するため、前述のコードによって、期待されるアプリケーション・モジュールの型が戻される保証はありません。

- ADFビジネス・コンポーネント・フレームワークの実装がリリースを追うごとに変化する場合。たとえば、以前のリリースでは、アプリケーションがADFタスク・フローを使用して定義した宣言トランザクションを制御するために、フレームワークで内部的なルート・アプリケーション・モジュールが作成されていました。

4.15 カスタム・データ・ソースおよびFramework Base Class ProgrammaticEntityImplを使用したプログラム的操作

ADFビジネス・コンポーネントはユーザーが作成できるプログラム・エンティティ・オブジェクトをサポートして、カスタム・データ・ソースと対話します。

ADFモデル・オブジェクトでエンティティ・オブジェクトのEntityObjectImplクラスを生成するときに、フレームワーク・ベース・クラスoracle.jbo.server.ProgrammaticEntityImplを使用して、カスタム・データ・ソースの各行に対する作成/削除/更新/ロック/ロールバック操作の実行を制御できます。エンティティの移入、コミット、またはロールバックの各ライフサイクルという様々なフェーズで、フレームワークはこれらのフック・ポイントを呼出し、フレームワーク・ベース実装クラスはアプリケーション開発者に、カスタム・データ・ソースとの対話およびこれらの操作の実行の制御を付与します。

注意:

ProgrammaticEntityImplベース・クラスの前に、アプリケーションはベース・クラスoracle.jbo.server.EntityImplから拡張し、カスタム動作の多くのライフサイクルをオーバーライドしています。プログラム的にエンティティ・ベース・クラスを使用するということは、エンティティ・ライフサイクル全体を理解する必要なく、カスタム・データ・ソースとの統合がアプリケーション開発者により実行されることを意味します。

ADFモデル・オブジェクトのエンティティ・オブジェクトをプログラム的に操作するには、エンティティ・オブジェクトの作成ウィザードでプログラムオプションを選択します。こうすると、ウィザードで生成するエンティティ・オブジェクトJavaクラスは、クラシック・スタイルのフレームワーク・クラスoracle.jbo.server.EntityImplではなく、フレームワーク・ベース・クラスoracle.jbo.server.ProgrammaticEntityImplからデフォルトで拡張します。

注意:

エンティティ・オブジェクトを作成する際にこの動作を確実に実行するには、ADFビジネス・コンポーネントの設定ダイアログで、ベース・クラスoracle.jbo.server.EntityImplからの拡張を有効にする機能を選択解除する必要があります。ツール-設定ダイアログのADFビジネス・コンポーネント-ビュー・オブジェクトページのオプションはクラシック・プログラム・ビューです(選択解除してProgrammaticEntityImplからの拡張を可能にする)。

4.15.1 ProgrammaticEntityImplを拡張してエンティティ・オブジェクト・クラスを作成する方法

oracle.jbo.server.ProgrammaticEntityImplを拡張するエンティティ・オブジェクトをプログラム的に作成するには、エンティティ・オブジェクト作成ウィザードを使用して、プログラムデータ・ソース・オプションを選択します。

始める前に:

クラシック・スタイルのプログラム的なエンティティ・オブジェクト生成を無効にする必要があります。ツール-設定ダイアログのADFビジネス・コンポーネント-ビュー・オブジェクトページで、オプションクラシック・プログラム・ビューの選択を解除します。このオプションを選択したまま(デフォルト)にしておくと、JDeveloperはoracle.jbo.server.EntityImplを拡張するエンティティ・オブジェクトJavaクラスを生成します。クラシック・モードの詳細は、「代替データ・ソースに対するクラシック・スタイル・プログラムでのビュー・オブジェクトの使用」を参照してください。

ProgrammaticEntityImplを拡張してプログラムによるエンティティ・オブジェクトを作成するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「エンティティ・オブジェクト」を選択し、「OK」をクリックします。

3. エンティティ・オブジェクト作成ウィザードの「名前」ページで、エンティティ・オブジェクトの名前とパッケージを入力します。データ・ソースについて、「プログラム関連」を選択します。

4. 「属性」ページで、「新規」を複数回クリックし、プログラムによるエンティティ・オブジェクトが必要とするエンティティ・オブジェクト属性を定義します。

5. 「属性の設定」ページで、定義した属性に必要な設定を調節します。

6. Javaページでエンティティ・オブジェクト・クラスの生成を選択し、カスタム・エンティティ・クラス(ProgrammaticEntityImpl)がユーザー・コードを含めるようにします。

7. 「終了」をクリックし、エンティティ・オブジェクトを作成します。
エンティティ・オブジェクトのカスタムJavaクラスで、「ProgrammaticEntityImplベースのエンティティ・オブジェクト用にオーバーライドする主要なフレームワーク・メソッド」で説明されているメソッドをオーバーライドし、独自のデータ取得方法を実装します。

4.15.2 ProgrammaticEntityImplベースのエンティティ・オブジェクト用にオーバーライドする主要なフレームワーク・メソッド

プログラムによるエンティティ・オブジェクトで生成するEntityObjectImpl.javaには、オーバーライドする必要がある次のメソッドがあります。

- postDataProvider(int operationType , ArrayList retAttrNames)
このメソッドはdoDML実行中に呼び出されます。デフォルトで、フレームワークはベース実装から例外をスローします。operationType引数に指定できる値はEntityImpl.DML_INSERT、EntityImpl.DML_UPDATEまたはEntityImpl.DML_DELETEです。操作タイプに基づき、アプリケーションはカスタム・データ・ソース(または、セカンダリ・キャッシュを維持している場合は、セカンダリ・キャッシュ)の行を挿入/更新/削除する必要があります。retAttrNames引数には、行が更新/挿入された後にアプリケーションが戻す値の属性名のリストが含まれます。

- getRowFromDataSource(HashMap[String , Object] origPrimaryKeyMap)
アプリケーションがカスタム・データ・ソースから最新の行データを戻すには、このAPIをオーバーライドする必要があります。エンティティのフォールトイン、コミットまたは再移入の間、フレームワークは複数ユーザー・アクセスのユース・ケースを処理するために、最新の行データを知る必要があります。origPrimaryKeyMap引数は、主要属性のいずれかをアプリケーションが変更しても、元のプライマリ主要情報を含みます。

- lockDataProvider(boolean lock)
アプリケーションがカスタム・データ・ソースの該当する行をロック/ロック解除するためには、このAPIをオーバーライドする必要があります。データベースの動作と同様、フレームワークは複数ユーザーによる同時コミットを避けるために、カスタム行DataProviderのロックを試みます。行がすでにロックされている場合、アプリケーションはoracle.jbo.AlreadyLockedException例外をスローします。

- rollbackDataProvider()
カスタムDataSourceが中間キャッシュも維持している場合、アプリケーションはロールバックを実行するためにこのAPIをオーバーライドできます。コミット/postChangesフェーズ中にどの例外も発生しなければ、フレームワークはこのAPIを呼び出します。

- commitDataProvider(ProgrammaticEntityImpl.CommitActionType commitActionType)
カスタムDataSourceが中間キャッシュも維持している場合、アプリケーションはこのAPIをオーバーライドすることにより、キャッシュをオリジナル・データとマージします。commitActionType引数に指定できる値は次のとおりです。

- CommitActionType.DELETE - キャッシュおよび元のカスタムDSから行を削除します

- CommitActionType.MERGE - キャッシュの行を元のカスタムDSにマージします

- CommitActionType.IGNORE - キャッシュされたこの行を無視し、元の行に対してNOアクションを実行します

他の有益な保護API

- getPrimaryKeyMap(boolean orig)
orig引数に基づき、このAPIはプライマリ・キーの値マップを返します。origがTRUEの場合はデータ・ソースから読み取られたプライマリ・キー値が返され、それ以外の場合は現在のプライマリ・キー値が返されます。

- getChangedAttributeMap()
このAPIは変更されたすべての属性のHashMapを返します。

4.16 ドメインを使用したカスタム検証済データ型の作成

複数のエンティティ・オブジェクトで似た属性値に対して同じ妥当性検査を繰り返し行っている場合は、この検証をカプセル化した独自のデータ型を作成することで、時間と労力を節約できます。たとえば、ビジネス・ドメイン・レイヤーに、電子メール・アドレスを表す文字列を格納する大量のエンティティ・オブジェクト属性がある場合を考えてみてください。ビジネス・ドメイン・レイヤーのどこでもエンド・ユーザーが有効な電子メール・アドレスを入力できるように保証する方法としては、次のようなものがあります。

- 各属性に対して基本のStringデータ型を使用

- Javaコードを使用して属性レベルのメソッド・バリデータを追加し、属性ごとにString値の形式が有効な電子メール・アドレスであることを確認

しかし、このような方法は、大規模なアプリケーションでは急速に冗漫になります。ADFビジネス・コンポーネントで提供されている代替手段を使用すると、電子メール・アドレスを表す独自のEmailAddressデータ型を作成できます。電子メール・アドレスの値に関するすべての妥当性検査をこの新しいカスタム・データ型にまとめた後は、アプリケーション内にある電子メール・アドレスを表すすべての属性の型として、EmailAddressを使用できます。このようにすると、属性値の意図が他の開発者に対していっそう明確になり、検証処理が1か所にまとまるためアプリケーションのメンテナンスが簡単になります。ADFビジネス・コンポーネントでは、これを開発者作成のデータ型ドメインと呼びます。

ドメインとは、String、Number、Dateなどの基本データ型を拡張するJavaクラスであり、関連する妥当性検査に候補値が合格することを保証するコンストラクタ時の検証が追加されています。基本データ型検証、書式設定、カスタム・メタデータ・プロパティなどの横断的動作でカスタム・データ型を定義する手段を、ドメインを属性のJava型として使用する任意のエンティティ・オブジェクトまたはビュー・オブジェクトによって継承される方法で提供します。

注意:

この項の例は、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.domainsパッケージを参照しています。

4.16.1 ドメインの作成方法

ドメインを作成するには、ドメイン作成ウィザードを使用します。このウィザードは、「ADFビジネス・コンポーネント」カテゴリの「新規ギャラリ」で使用できます。

始める前に:

ドメインの使用に関する知識があると役立ちます。詳細は、「ドメインを使用したカスタム検証済データ型の作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

ドメインを作成するには:

1. 「アプリケーション」ウィンドウで、ドメインを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから、「ドメイン」を選択し、「OK」をクリックします。

3. ドメイン作成ウィザードの「名前」ページで、ドメインの名前とドメインが存在するパッケージを指定します。単純なJava型に基づくドメインを作成する場合は、「Oracleオブジェクト型のドメイン」を選択しないでおきます。

4. 「次へ」をクリックします。

5. 「設定」ページで、ドメインのベース型と、マップするデータベース列の型を指定します。

たとえば、8文字の短い電子メール・アドレスを保持するShortEmailAddressという名前のドメインを作成する場合は、ベース型にStringを設定し、「データベース列の型」にVARCHAR2(8)を設定します。このパネルでは、他の共通属性も設定できます。

6. 「終了」をクリックします。

4.16.2 ドメインの作成時の処理

ドメインを作成すると、プロジェクトのソース・パスのサブディレクトリに、選択したパッケージ名に対応するXMLドキュメントが作成されます。たとえば、summit.model.domainsパッケージにShortEmailAddressドメインを作成すると、./summit/model/domainsサブディレクトリにShortEmailAddress.xmlファイルが作成されます。ドメインには常に対応するJavaクラスがあり、ドメインが存在するパッケージのcommonサブパッケージに作成されます。つまり、summit.model.domains.commonパッケージにShortEmailAddress.javaクラスが作成されます。ドメインのJavaクラスは、組込みデータ型と同じように動作する適切なコードを備えて生成されます。

4.16.3 ドメインに関する必知事項

ドメインは様々に異なる型として作成でき、標準の属性ではなく異なる特性を持ちます。ここでは、ドメインを使用する際に理解しておく必要のある事項について説明します。

4.16.3.1 エンティティ・オブジェクトおよびビュー・オブジェクトの属性としてのドメイン

プロジェクトでドメインを作成すると、エンティティ・オブジェクトおよびビュー・オブジェクトのウィザードとダイアログで「属性」の「型」ドロップダウン・リストに、使用可能なデータ型の1つとして表示されます。特定の属性の型としてドメインを使用するには、リストから選択します。

注意:

エンティティ・ベースのビュー・オブジェクトのエンティティにマップされた属性は、対応する基礎となるエンティティ・オブジェクト属性からデータ型を継承します。したがって、エンティティ属性でドメイン・タイプを使用する場合、一致するビュー・オブジェクト属性も同様になります。ビュー・オブジェクトの一時属性またはSQL導出属性の場合は、基礎のエンティティから継承しないため、ドメインを使用するように型を直接設定できます。

4.16.3.2 カスタムvalidate()メソッドのDataCreationException

通常、ドメインについてユーザーが行う必要のある唯一のコーディング作業は、生成されるvalidate()メソッドの内部のカスタム・コードを記述することです。validate()メソッドの実装では、設定している候補値の妥当性検査を行い、検証が失敗した場合はoracle.jboパッケージでDataCreationExceptionをスローします。

翻訳可能な例外メッセージをスローするには、次の例で示されているようなメッセージ・バンドル・クラスを作成できます。このクラスは、ドメイン・クラス自体と同じパッケージに作成します。メッセージ・バンドルは、{MessageKeyString、TranslatableMessageString}というペアの配列を返します。

注意:

リソース・バンドルでは、XLIFFなどの追加の形式を使用できます。詳細は、「リソース・バンドルの使用」を参照してください。

package oracle.summit.model.domains;

import java.util.ListResourceBundle;

public class ErrorMessages extends ListResourceBundle {
public static final String INVALID_SHORTEMAIL = "30002";
public static final String INVALID_EVENNUMBER = "30003";
private static final Object[][] sMessageStrings = new String[][] {
{ INVALID_SHORTEMAIL,
"A valid short email address has no @-sign or dot."},
{ INVALID_EVENNUMBER,
"Number must be even."}
};

/**
* Return String Identifiers and corresponding Messages
* in a two-dimensional array.
*/
protected Object[][] getContents() {
return sMessageStrings;
}
}

4.16.3.3 StringドメインとString値集約

StringはJDKのベース型であるため、Stringに基づくドメインは、private mData Stringメンバー・フィールドを集約して、ドメインが表す値を保持します。その後、クラスはADFランタイムが期待するDomainInterfaceとともにSerializableインタフェースも実装するので、Oracle ADFコンポーネントのカスタム・クライアント・インタフェースのメソッドの引数または戻り型でドメインを使用できます。

次の例は、簡単なShortEmailAddressドメイン・クラスのvalidate()メソッドを示しています。このメソッドは、mData値にアットマークまたはドットが含まれないていないことを確認し、含まれている場合は、翻訳可能なエラー・メッセージの適切なメッセージ・バンドルとメッセージ・キーを参照するDataCreationExceptionをスローします。

public class ShortEmailAddress implements DomainInterface, Serializable {
private String mData;
// . . .
protected void validate() {
/**Implements domain validation logic and throws a JboException on error. */
int atpos = mData.indexOf('@');
int dotpos = mData.lastIndexOf('.');
if (atpos > -1 || dotpos > -1) {
throw new DataCreationException(ErrorMessages.class,
ErrorMessages.INVALID_SHORTEMAIL,null,null);
}
}
// . . .
}

4.16.3.4 簡単なドメインと組込みデータ型

oracle.jbo.domainパッケージの組込み型に基づく他の簡単なドメインは、次の例に示すように、ベース型を拡張します。この例では、偶数を表すEvenNumberという名前のNumberベースのドメインに対するvalidate()メソッドが示されています。

public class EvenNumber extends Number {
// . . .
/**
* Validates that value is an even number, otherwise
* throws a DataCreationException with a custom
* error message.
*/
protected void validate() {
if (getValue() % 2 == 1) {
throw new DataCreationException(ErrorMessages.class,
ErrorMessages.INVALID_EVENNUMBER,null,null);
}
}
// . . .
}

4.16.3.5 不変なJavaクラスとしての単純なドメイン

基本データ型に基づいて作成された単純なドメインは、不変なクラスになります。つまり、次のようにして新しいインスタンスを作成します。

ShortEmailAddress email = new ShortEmailAddress("emailaddress1");

このようにして作成したインスタンスの値は変更できません。別の短い電子メール・アドレスを参照する場合は、別のインスタンスを作成します。

ShortEmailAddress email = new ShortEmailAddress("emailaddress2");

これは新しい概念ではなく、String、Number、Dateなどのクラスと同じ動作です。

4.16.3.6 Oracleオブジェクト型に対するドメインの作成

Oracle Databaseでは、データベースでユーザー定義型を作成できます。たとえば、次のDDL文を使用してPOINT_TYPEという名前の型を作成できます。

create type point_type as object (
x_coord number,
y_coord number
);

POINT_TYPEのようなユーザー定義型を使用する場合は、その型に基づくドメインを作成したり、オブジェクト型の列を含む表をリバース・エンジニアリングしてドメインを自動的に作成したりできます。ドメイン作成ウィザードを使用して、Oracleオブジェクト型のドメインを手動で作成できます。

Oracleオブジェクト型のドメインを手動で作成するには:

1. 「アプリケーション」ウィンドウで、ドメインを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから、「ドメイン」を選択し、「OK」をクリックします。

3. ドメイン作成ウィザードの「名前」ページで、「Oracleオブジェクト型のドメイン」チェック・ボックスを選択し、「使用可能な型」リストからドメインを作成するオブジェクト型を選択します。

4. 「次へ」をクリックします。

5. 「設定」ページで、「属性」ドロップダウン・リストを使用して複数のドメイン・プロパティを切り替え、適切に設定します。

6. 「終了」をクリックします。

Oracleオブジェクト型のドメインをリバース・エンジニアリングするには:

オブジェクト型ドメインを手動で作成する以外にも、表からのビジネス・コンポーネント・ウィザードを使用してOracleオブジェクト型の列を含む表を選択すると、JDeveloperによってそれらのオブジェクト型のドメインがリバース・エンジニアリング・プロセスの一部として作成されます。たとえば、POINT_TYPE型の列を含む次のような表を作成するものとします。

create table interesting_points(
id number primary key,
coordinates point_type,
description varchar2(20)
);

表からのビジネス・コンポーネント・ウィザードでINTERESTING_POINTS表に対するエンティティ・オブジェクトを作成すると、InterestingPointsエンティティ・オブジェクトとPointTypeドメインの両方を取得できます。後者がPOINT_TYPEオブジェクト型に基づいて生成されるのは、InterestingPointsエンティティ・オブジェクトのCoordinates属性のデータ型として必要であるためです。

単純なドメインとは異なり、オブジェクト型ドメインは可変です。オブジェクト型の構造体の各要素に対し、ドメイン・クラスにgetterメソッドとsetterメソッドが生成されます。ドメインのプロパティを変更した後、そのドメインをビュー・オブジェクトまたはエンティティ・オブジェクトの属性として設定するとき、ドメインは1つの単位として扱われます。Oracle ADFは、ドメインのプロパティの変更は追跡せず、ドメインが値として使用される属性値の変更のみを追跡します。

注意:

Oracleオブジェクト型に基づくドメインは、基礎となる型がOracleオブジェクト型であるデータをプログラムで処理するときに便利です。また、ストアド・プロシージャとの間における構造体情報の授受も簡単になります。ただし、ADFバインディング・レイヤーでのオブジェクト型ドメインの処理のサポートは完全ではないため、宣言的にデータバインドされたユーザー・インタフェースでオブジェクト・ドメイン値属性を使用することは容易ではありません。

4.16.3.7 共通JARにパッケージ化されたドメイン

「コンポーネントをADFライブラリJARにパッケージ化する方法」で説明されているように、ビジネス・コンポーネントのADFライブラリJARを作成すると、プロジェクトのソース・パスの*.commonサブディレクトリにあるドメイン・クラスとメッセージ・バンドル・ファイルは、*CSCommon.jarにパッケージ化されます。これらは、サポートする必要のある中間層アプリケーション・サーバーと最終的なリモート・クライアントの両方に共通のクラスです。

4.16.3.8 エンティティ・オブジェクトとビュー・オブジェクトにおけるカスタム・ドメイン・プロパティと属性

ドメインではカスタム・メタデータ・プロパティを定義できます。そのようなドメインに基づくエンティティ・オブジェクトまたはビュー・オブジェクトの属性は、属性自体で定義されている場合と同じように、これらのカスタム・プロパティを継承します。エンティティ・オブジェクトまたはビュー・オブジェクトの属性で同じカスタム・プロパティが定義されている場合は、その設定が、ドメインから継承する値より優先されます。

4.16.3.9 エンティティ・オブジェクトとビュー・オブジェクトにおけるドメインの継承された制限プロパティ

JDeveloperでは、ドメイン定義レベルで適用されている宣言的な設定を施行します。この設定は、ドメイン型に基づく属性のエンティティ・オブジェクトまたはビュー・オブジェクトでは制限を緩和できません。たとえば、ドメインの「更新可能」プロパティを「新規の間」に設定した場合、そのドメインをエンティティ・オブジェクト属性のJava型として使用するときに、「更新可能」を「なし」(より厳しい制限)に設定することはできますが、「常に」に設定することはできません。同様に、ドメインを「永続的」に定義した場合、後でそれを一時的なものにすることはできません。アプリケーションで使用するときは、ドメインの宣言的プロパティはできるかぎり緩く設定し、後で必要に応じて厳しくできるようにします。

4.17 新規履歴タイプの作成

履歴タイプは、ある時点に固有のデータの追跡に使用されます。JDeveloperにはいくつかの履歴タイプが付属していますが、独自のものも作成できます。標準の履歴タイプとその使用方法の詳細は、「履歴列を使用して作成および変更した日付を追跡する方法」を参照してください。

4.17.1 新規履歴タイプの作成方法

付属の履歴タイプに限定されることなく、「プリファレンス」ダイアログの「履歴タイプ」ページを使用してカスタム履歴タイプを追加または削除してから、カスタムJavaコードを記述して目的の動作を実装できます。カスタム履歴タイプを処理するコードは、再利用できるようアプリケーション全体にわたるエンティティ・ベース・クラスで記述します。

図4-17は、タイプIDが11のlast update loginカスタム・タイプです。last_update_loginがFND_LOGINS表の外部キーであると仮定します。

図4-17 概要エディタでの新規履歴タイプ

始める前に:

履歴タイプに関する知識が役立つ場合があります。詳細は、「新規履歴タイプの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

カスタム履歴列タイプを作成するには:

1. メイン・メニューから、「ツール」→「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を展開し、「履歴タイプ」をクリックします。

3. 「履歴タイプ」ページの「プリファレンス」ダイアログで、「新規」をクリックします。

4. 「新規履歴タイプ」ダイアログで、名前(空白は使用可)の文字列値および数値IDを入力します。

「タイプID」は11 - 126の整数である必要があります。0 - 10の数値は内部用に予約されています。表示文字列は、次に概要エディタを使用する際、「変更履歴のトラッキング」ドロップダウン・リストに表示されます。図4-18は、「設定」ダイアログでの新規履歴タイプを示します。

図4-18 「設定」でのカスタム履歴列タイプ

5. エンティティ・オブジェクトのJavaクラス・ファイル(またはそれを基礎としている拡張クラス)を開き、次の定義と同じ定義を追加します。

private static final byte LASTUPDATELOGIN_HISTORY_TYPE = 11;

6. 次のようなコードで、EntityImplベース・クラスのgetHistoryContextForAttribute(AttributeDefImpl attr)メソッドをオーバーライドします。

@Override
protected Object getHistoryContextForAttribute(AttributeDefImpl attr) {
if (attr.getHistoryKind() == LASTUPDATELOGIN_HISTORY_TYPE) {
// Custom History type logic goes here
}
else {
return super.getHistoryContextForAttribute(attr);
}
}

4.17.2 履歴タイプの削除方法

履歴タイプは通常、アプリケーションの存続期間中は値の監査に使用されるため、削除する必要はありません。ただし、削除する必要がある場合は、次の作業を実行します。

1. 「プリファレンス」ダイアログで、JDeveloper履歴タイプ・リストから目的の履歴タイプを削除します。

2. エンティティ・オブジェクトのJavaクラス・ファイル(またはそれを基礎としている拡張クラス)のgetHistoryContextForAttributeメソッドで履歴タイプをサポートするために実装したカスタム・コードを削除します。

3. エンティティ属性メタデータの履歴タイプのすべての慣用名を削除します。この履歴タイプを使用するように定義した属性があれば、編集する必要があります。

始める前に:

履歴タイプに関する知識が役立つ場合があります。詳細は、「新規履歴タイプの作成」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

JDeveloper履歴タイプ・リストから目的の履歴タイプを削除するには:

1. メイン・メニューから、「ツール」→「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を展開し、「履歴タイプ」をクリックします。

3. 「履歴タイプ」ページの「プリファレンス」ダイアログで、削除する履歴タイプを選択して「削除」をクリックします。

4.18 PL/SQLパッケージAPIに基づくエンティティ・オブジェクト

基礎となる表に対する挿入、更新、および削除のアクセスをカプセル化するPL/SQLパッケージがある場合は、その表を表すエンティティ・オブジェクトに対するデフォルトのDML処理イベントをオーバーライドし、かわりにPL/SQL APIの中でプロシージャを呼び出すことができます。通常、このようなPL/SQLパッケージは、付随するデータベース・ビューと組み合せて使用されます。クライアント・プログラムは、データベース・ビューを使用して基になる表からデータを読み取り、PL/SQLパッケージのプロシージャを使用してデータを表に書き戻します。

たとえば、このようなビューとパッケージの組合せに基づいてProductエンティティ・オブジェクトを作成するとします。

Summit ADFスキーマのS_PRODUCT表を使用し、次のDDL文を使用して作成されるPRODUCT_Vという名前のデータベース・ビューについて考えます。

create or replace view product_v
as select id,name,image_id,short_desc from s_product;

さらに、基になるS_PRODUCT表に対する挿入、更新、削除権限をカプセル化する、次に示されるような簡単なPRODUCTS_APIパッケージを使用します。

create or replace PACKAGE PRODUCTS_API as
procedure insert_product(p_id number,
p_name varchar2,
p_short_desc varchar2,
p_longtext_id number,
p_image_id number,
p_suggested_whlsl_price number,
p_whlsl_units varchar2);
procedure update_product(p_id number,
p_name varchar2,
p_short_desc varchar2,
p_longtext_id number,
p_image_id number,
p_suggested_whlsl_price number,
p_whlsl_units varchar2);
procedure delete_product(p_id number);
end products_api;

この組合せのデータベース・ビューとPL/SQLパッケージに基づいてエンティティ・オブジェクトを作成するには、次の手順を実行します。

1. 「ビューを基にしてエンティティ・オブジェクトを作成する方法」の説明に従ってビューを基にしたエンティティ・オブジェクトを作成します。

2. 「PL/SQLベースのエンティティに関する詳細をベース・クラスに集中化する方法」の説明に従ってエンティティ・オブジェクトのベース・クラスを作成します。

3. 「DML操作のストアド・プロシージャ呼出しを実装する方法」の説明に従って適切なストアド・プロシージャ・コールを実装します。

4. 必要に応じて、「選択処理およびロック処理を追加する方法」の説明に従って選択機能とロック機能を処理します。

注意:

この項の例は、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.wrapplsqlパッケージを参照しています。

例ではビューベースのエンティティ・オブジェクトではなく表ベースのエンティティ・オブジェクトが使用されていますが、構成の詳細は同一です。

4.18.1 ビューを基にしてエンティティ・オブジェクトを作成する方法

ビューを基にしてエンティティ・オブジェクトを作成するには、エンティティ・オブジェクト作成ウィザードを使用します。

始める前に:

エンティティ・オブジェクトでPS/SQL APIを使用できる方法に関する知識が役立つ場合があります。詳細は、「PL/SQLパッケージAPIに基づくエンティティ・オブジェクト」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

「エンティティの作成ウィザードで単一のエンティティ・オブジェクトを作成する方法」の説明に従って、エンティティ・オブジェクトの作成ウィザードを起動してウィザードを実行する必要がありますが、次の手順で示す例外があります。

ビューを基にしてエンティティ・オブジェクトを作成するには:

1. 「名前」ページで、エンティティの名前を入力します。

2. 「スキーマ・オブジェクトの選択」ダイアログの 「オブジェクト・タイプ」セクションで、「ビュー」チェック・ボックスを選択します。

「問合せ」をクリックした際に現在のスキーマで使用できるデータベース・ビューを表示できます。

3. 「使用可能なオブジェクト」リストで目的のデータベース・ビューを選択します。

4. 「属性の設定」ページで、「属性の選択」ドロップダウン・リストを使用して、主キーとして機能する属性を選択し、その属性の「主キー」チェック・ボックスを選択します。

注意:

ビューを基にしてエンティティを定義するときは、データ・ディクショナリにデータベース・ビューに関連する制約がないため、主キー属性を自動的に決定することはできません。

4.18.2 ビューを基にしてエンティティ・オブジェクトを作成するときに行われる処理

ビューに基づくエンティティ・オブジェクトは、デフォルトで、基礎となるデータベース・ビューに対して次のすべての文を直接実行します。

- SELECT文(findByPrimaryKey()の場合)

- SELECT FOR UPDATE文(lock()の場合)

- INSERT、UPDATE、DELETE文(doDML()の場合)

ストアド・プロシージャ・コールを使用するには、(「PL/SQLベースのエンティティに関する詳細をベース・クラスに集中化する方法」の説明に従って)doDML()操作をオーバーライドし、必要に応じて(「DML操作のストアド・プロシージャ呼出しを実装する方法」の説明に従って)lock()およびfindByPrimaryKey()の処理をオーバーライドする必要があります。

4.18.3 PL/SQLベースのエンティティに関する詳細をベース・クラスに集中化する方法

PL/SQL APIに基づくエンティティ・オブジェクトが複数ある場合は、一般的な詳細をベース・フレームワーク拡張クラスに抽象化するのがよい方法です。この場合、「ビジネス・コンポーネント機能の拡張」で説明されている概念のいくつかを利用します。まず、PL/SQLベースの各エンティティでベース・クラスとして使用できるEntityImplベース・クラスを拡張するPLSQLEntityImplクラスを作成します。

注意:

エンティティにすでに拡張したエンティティ実装クラスを使用している場合、PLSQLEntityImplクラスを使用してさらに拡張できます。たとえば、zzEntityImplというフレームワーク拡張クラスがある場合、zzEntityImplクラスを拡張するPLSQLEntityImplクラスを作成します。

次に示すように、ベース・クラスのdoDML()メソッドをオーバーライドし、操作に基づいて異なるヘルパー・メソッドを起動します。

// In PLSQLEntityImpl.java
protected void doDML(int operation, TransactionEvent e) {
// super.doDML(operation, e);
if (operation == DML_INSERT)
callInsertProcedure(e);
else if (operation == DML_UPDATE)
callUpdateProcedure(e);
else if (operation == DML_DELETE)
callDeleteProcedure(e);
}

ベース・クラスPLSQLEntityImpl.javaでは、次に示すように、デフォルトの処理を実行するようにヘルパー・メソッドを記述できます。

// In PLSQLEntityImpl.java
/* Override in a subclass to perform nondefault processing */
protected void callInsertProcedure(TransactionEvent e) {
super.doDML(DML_INSERT, e);
}
/* Override in a subclass to perform nondefault processing */
protected void callUpdateProcedure(TransactionEvent e) {
super.doDML(DML_UPDATE, e);
}
/* Override in a subclass to perform nondefault processing */
protected void callDeleteProcedure(TransactionEvent e) {
super.doDML(DML_DELETE, e);
}

このインフラストラクチャを配置した後、PLSQLEntityImplクラスに基づくエンティティ・オブジェクトでは、「ソース」→「メソッドのオーバーライド」メニュー項目を使用して、callInsertProcedure()、callUpdateProcedure()およびcallDeleteProcedure()の各ヘルパー・メソッドをオーバーライドして、その特定のエンティティに適したストアド・プロシージャ呼出しを実行できます。

注意:

これらのヘルパー・メソッドをサブクラスでオーバーライドしない場合、スーパークラスで定義されているデフォルトの処理が実行されます。代替処理を提供するdoDML()メソッドで操作のオーバーライドのみを行います。

これらのコールを実装するタスクを簡単にするには、(「ストアド・プロシージャとストアド・ファンクションの呼出し」で説明した)callStoredProcedure()ヘルパー・メソッドをPLSQLEntityImplクラスに追加することもできます。このようにすると、このクラスを拡張するPL/SQLベースのエンティティ・オブジェクトはすべて、ヘルパー・メソッドを利用できます。

4.18.4 DML操作のストアド・プロシージャ呼出しを実装する方法

DML操作に対するストアド・プロシージャ呼出しを実装するには、エンティティ・オブジェクトのカスタムJavaクラスを作成して、その中の操作をオーバーライドする必要があります。

始める前に:

PL/SQLパッケージAPIに基づくエンティティ・オブジェクトに関する知識が役立つ場合があります。詳細は、「PL/SQLパッケージAPIに基づくエンティティ・オブジェクト」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

メソッドのオーバーライドでカスタムJavaクラスを作成するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」アイコンをクリックします。

3. 「Javaオプションの選択」ダイアログで、「クラスの拡張」をクリックします。

4. 「ベース・クラスのオーバーライド」ダイアログで、「行」フィールドにPLSQLEntityImplクラスのパッケージとクラスを入力するか、「参照」をクリックして検索して選択します。

5. 「エンティティ・オブジェクト・クラスの生成」を選択して「OK」をクリックします。

6. 「アプリケーション」ウィンドウで、生成されたエンティティ・オブジェクト・クラスをダブルクリックします。

7. メイン・メニューから、「ソース」→「メソッドのオーバーライド」を選択します。

8. 「メソッドのオーバーライド」ダイアログで、callInsertProcedure()、callUpdateProcedure()およびcallDeleteProcedure()の各メソッドを選択し、次に「OK」をクリックします。

9. ソース・エディタで、必要なコードを入力し、これらのプロシージャをオーバーライドします。

次の例は、挿入、更新、削除プロシージャを起動するためにこれらのオーバーライドしたヘルパー・メソッドで記述するサンプル・コードを示しています。

// In ProductImpl.java
protected void callInsertProcedure(TransactionEvent e) {
callStoredProcedure("products_api.insert_product(?,?,?,?,?,?,?)",
new Object[] { getId(), getName(), getShortDesc(), getLongtextId(),
getImageId(), getSuggestedWhlslPrice(), getWhlslUnits() });
}
protected void callUpdateProcedure(TransactionEvent e) {
callStoredProcedure("products_api.update_product(?,?,?,?,?,?)",
new Object[] { getId(), getName(), getShortDesc(), getLongtextId(),
getImageId(), getSuggestedWhlslPrice(), getWhlslUnits() });
}
protected void callDeleteProcedure(TransactionEvent e) {
callStoredProcedure("products_api.delete_product(?)",
new Object[] { getId() });
}

この段階で、Productエンティティ・オブジェクトに対してProductViewという名前でデフォルトのエンティティ・ベースのビュー・オブジェクトを作成し、そのインスタンスをAppModuleアプリケーション・モジュールに追加すると、Oracle ADFモデル・テスターで、ProductViewビュー・オブジェクト・インスタンスの行の挿入、更新、削除を簡単にテストできます。

通常は、挿入、更新、および削除の操作をオーバーライドするのみで十分です。データベース・ビューに対してfindByPrimaryKey()のSELECT文およびlock()のSELECT FOR UPDATE 文を実行するデフォルトの動作は、ほとんどの基本的な種類のビューで動作します。

ただし、ビューが複雑でSELECT FOR UPDATEをサポートしない場合、または他のストアド・プロシージャAPIを使用してfindByPrimaryKey()機能およびlock()機能を実行する必要がある場合、「選択処理およびロック処理を追加する方法」に説明されている方法を実行できます。

4.18.5 選択処理およびロック処理を追加する方法

必要に応じて、ストアド・プロシージャを呼び出して、エンティティ・オブジェクトのlock()およびfindByPrimaryKey()機能を処理できます。PRODUCTS_APIパッケージを更新し、次に示されている2つのプロシージャを追加したものとします。

/* Added to PRODUCTS_API package */
procedure lock_product(p_id number,
p_name OUT varchar2,
p_short_desc OUT varchar2,
p_longtext_id OUT number,
p_image_id OUT number,
p_suggested_whlsl_price OUT number,
p_whlsl_units OUT varchar2);
procedure select_product(p_id number,
p_name OUT varchar2,
p_short_desc OUT varchar2,
p_longtext_id OUT number,
p_image_id OUT number,
p_suggested_whlsl_price OUT number,
p_whlsl_units OUT varchar2);

lock_productプロシージャとselect_productプロシージャはどちらも、INパラメータとして主キー属性を受け取り、OUTパラメータを使用して残りの属性の値を返します。

選択処理およびロック処理を追加するには、次のタスクを実行する必要があります。

1. 「ロックと選択を処理するためのPLSQLEntityImplベース・クラスの更新」の説明に従って、ロックと選択を処理するためにベース・クラスを更新します。

2. 「Productエンティティに対するロックおよび選択の実装」の説明に従って、ロックと選択の動作を実装するためにエンティティ・オブジェクト実装クラスを更新します。

3. 「RowInconsistentException後のエンティティ・オブジェクトのリフレッシュ」の説明に従って、RowInconsistentExceptionが発生した後、エンティティ・オブジェクト実装クラスのlock()メソッドをオーバーライドし、エンティティ・オブジェクトをリフレッシュします。

4.18.5.1 ロックと選択を処理するためのPLSQLEntityImplベース・クラスの更新

挿入、更新、削除用に追加したものと似たヘルパー・メソッドを使用して、lock()およびfindByPrimaryKey()のオーバーライドを処理するように、PLSQLEntityImplベース・クラスを拡張できます。実行時には、lock()操作とfindByPrimaryKey()操作はどちらも、doSelect(boolean lock)という名前の下位レベルのエンティティ・オブジェクト・メソッドを呼び出します。lock()操作はパラメータをtrue値にしてdoSelect()を呼び出しますが、findByPrimaryKey()操作はfalseを渡して呼び出します。

次の例は、必要に応じてサブクラスがオーバーライドできる2つのヘルパー・メソッドに委譲するようオーバーライドされたPLSQLEntityImplのdoSelect()メソッドを示しています。

// In PLSQLEntityImpl.java
protected void doSelect(boolean lock) {
if (lock) {
callLockProcedureAndCheckForRowInconsistency();
} else {
callSelectProcedure();
}
}

2つのヘルパー・メソッドは、ベース・クラスPLSQLEntityImplのデフォルト機能を実行するためだけに記述されています。

// In PLSQLEntityImpl.java
/* Override in a subclass to perform nondefault processing */
protected void callLockProcedureAndCheckForRowInconsistency() {
super.doSelect(true);
}
/* Override in a subclass to perform nondefault processing */
protected void callSelectProcedure() {
super.doSelect(false);
}

ロックを実行するヘルパー・メソッドの名前がcallLockProcedureAndCheckForRowInconsistency()であることに注意してください。これは、行をロックするときに、エンティティ・キャッシュ内のエンティティ・オブジェクトが現在のデータベース値であると認識している値と新規選択行の値が同じかどうかを検出する検査を実行する必要があることを、伝えています。

この古い値と新しい値の属性の比較をサブクラスが実行するのを助けるため、次のようなfinalのヘルパー・メソッドをPLSQLEntityImplクラスに追加できます。

// In PLSQLEntityImpl
protected void compareOldAttrTo(int attrIndex, Object newVal) {
if ((getPostedAttribute(attrIndex) == null && newVal != null) ||
(getPostedAttribute(attrIndex) != null && newVal == null) ||
(getPostedAttribute(attrIndex) != null && newVal != null &&
!getPostedAttribute(attrIndex).equals(newVal))) {
throw new RowInconsistentException(getKey());
}
}

4.18.5.2 Productエンティティに対するロックおよび選択の実装

追加のインフラストラクチャをベース・クラスPLSQLEntityImplに置くと、エンティティ・オブジェクト実装クラス(ProductImplなど)のcallSelectProcedure()およびcallLockProcedureAndCheckForRowInconsistency()ヘルパー・メソッドをオーバーライドできます。select_productプロシージャとlock_productプロシージャはOUT引数を持っているため、「他の種類のストアド・プロシージャの呼出し方法」で説明したように、JDBCのCallableStatementオブジェクトを使用してこれらの呼出しを実行する必要があります。

次の例は、ProductImplエンティティ・オブジェクト実装クラスのselect_productプロシージャを起動して主キーで行を選択するために使用するコードを示しています。このコードが実行する基本的な手順は次のとおりです。

1. PL/SQLブロックが呼び出すCallableStatementを作成します。

2. 1から始まるバインド変数位置で、OUTパラメータと型を登録します。

3. INパラメータの値を設定します。

4. 文を実行します。

5. 更新された列の値を取得します。

6. 更新された属性値を行に移入します。

7. 文を閉じます。

// In ProductImpl.java
protected void callSelectProcedure() {
String stmt = "begin products_api.select_product(?,?,?,?,?,?,?);end;";
// 1. Create a CallableStatement for the PLSQL block to invoke
CallableStatement st = getDBTransaction().createCallableStatement(stmt, 0);
try {
// 2. Register the OUT parameters and types
st.registerOutParameter(2, VARCHAR2);
st.registerOutParameter(3, VARCHAR2);
st.registerOutParameter(4, NUMBER);
st.registerOutParameter(5, NUMBER);
st.registerOutParameter(6, NUMBER);
st.registerOutParameter(7, VARCHAR2);
// 3. Set the IN parameter value
st.setObject(1, getId());
// 4. Execute the statement
st.executeUpdate();
// 5. Retrieve the possibly updated column values
String possiblyUpdatedName = st.getString(2);
String possiblyUpdatedShortDesc = st.getString(3);
String possiblyUpdatedLongTextId = st.getString(4);
String possiblyUpdatedImageId = st.getString(5);
String possiblyUpdatedSuggestedPrice = st.getString(6);
String possiblyUpdatedWhlslUnits = st.getString(7);
// 6. Populate the possibly updated attribute values in the row
populateAttribute(NAME, possiblyUpdatedName, true, false,
false);
populateAttribute(SHORTDESC, possiblyUpdatedShortDesc, true,
false, false);
populateAttribute(LONGTEXTID, possiblyUpdatedLongTextId, true,
false, false);
populateAttribute(IMAGEID, possiblyUpdatedImageId, true, false,
false);
populateAttribute(SUGGESTEDWHLSLPRICE, possiblyUpdatedSuggestedPrice,
true, false, false);
populateAttribute(WHLSLUNITS, possiblyUpdatedWhlslUnits, true,
false, false);
} catch (SQLException e) {
throw new JboException(e);
} finally {
if (st != null) {
try {
// 7. Closing the statement
st.close();
} catch (SQLException e) {
}
}
}
}

次の例は、lock_productプロシージャを起動するためのコードを示しています。基本的には前記と同じ手順を行いますが、次の2点のみ異なります。

- OUTパラメータから更新された可能性のある列の値を取得した後、PLSQLEntityImplから継承されたcompareOldAttrTo()ヘルパー・メソッドを使用して、行ロック試行の結果としてRowInconsistentExceptionをスローする必要があるかどうかを判定します。

- catch (SQLException e)ブロックでは、データベースがエラーをスローしたかどうかを検査しています。

ORA-00054: resource busy and acquire with NOWAIT specified

例外がスローされている場合は、lock()機能のデフォルトのエンティティ・オブジェクトの実装がこのような状況で行うのと同じように、再びADFビジネス・コンポーネントのAlreadyLockedExceptionをスローします。

これらのメソッドを配置すると、すべてのデータベース操作についてPL/SQLパッケージをラップするエンティティ・オブジェクト(この場合、PRODUCTS_APIパッケージのProductエンティティ・オブジェクト)ができます。ビュー・オブジェクトのデータ問合せ機能およびエンティティ・オブジェクトのデータ検証と保存機能を明確に分離するため、通常のエンティティ・オブジェクトを使用するのと同じように、このエンティティ・オブジェクトを利用できます。このエンティティ・オブジェクトをエンティティ慣用名として使用する異なるビュー・オブジェクトを、必要な数だけ作成できます。

// In ProductsImpl.java
protected void callLockProcedureAndCheckForRowInconsistency() {
String stmt = "begin products_api.lock_product(?,?,?,?,?,?,?);end;";
CallableStatement st =
getDBTransaction().createCallableStatement(stmt, 0);
try {
st.registerOutParameter(2, VARCHAR2);
st.registerOutParameter(3, VARCHAR2);
st.registerOutParameter(4, NUMBER);
st.registerOutParameter(5, NUMBER);
st.registerOutParameter(6, NUMBER);
st.registerOutParameter(7, VARCHAR2);
st.setObject(1, getId());
st.executeUpdate();
String possiblyUpdatedName = st.getString(2);
String possiblyUpdatedShortDesc = st.getString(3);
String possiblyUpdatedLongTextId = st.getString(4);
String possiblyUpdatedImageId = st.getString(5);
String possiblyUpdatedSuggestedPrice = st.getString(6);
String possiblyUpdatedWlhslUnits = st.getString(7);
compareOldAttrTo(NAME, possiblyUpdatedName);
compareOldAttrTo(SHORTDESC, possiblyUpdatedShortDesc);
compareOldAttrTo(LONGTEXTID, possiblyUpdatedLongTextId);
compareOldAttrTo(IMAGEID, possiblyUpdatedImageId);
compareOldAttrTo(SUGGESTEDWHLSLPRICE, possiblyUpdatedSuggestedPrice);
compareOldAttrTo(WHLSLUNITS, possiblyUpdatedWlhslUnits);
} catch (SQLException e) {
if (Math.abs(e.getErrorCode()) == 54) {
throw new AlreadyLockedException(e);
} else {
throw new JboException(e);
}
} finally {
if (st != null) {
try {
st.close();
} catch (SQLException e) {
}
}
}
}

4.18.5.3 RowInconsistentException後のエンティティ・オブジェクトのリフレッシュ

RowInconsistentExceptionが発生した後で、lock()メソッドをオーバーライドして、エンティティ・オブジェクトをリフレッシュすることができます。次の例は、エンティティ・オブジェクト実装クラスに追加してRowInconsistentExceptionを捕捉しエンティティ・オブジェクトをリフレッシュできるコードを示しています。

// In the entity object implementation class
@Override
public void lock() {
try {
super.lock();
}
catch (RowInconsistentException ex) {
this.refresh(REFRESH_UNDO_CHANGES);
throw ex;
}
}

4.19 結合ビューまたはリモートDBLinkに基づくエンティティ・オブジェクト

次のいずれかに基づくエンティティ・オブジェクトを作成する必要がある場合があります。

- DBLINKを介したリモート表に解決されるシノニム

- INSTEAD OFトリガーを持つビュー

このような場合、いずれかの属性がRefresh on InsertまたはRefresh on Updateとしてマークされていると、次のようなエラーが発生します。

JBO-26041: Failed to post data to database during "Update"
## Detail 0 ##
ORA-22816: unsupported feature with RETURNING clause

これらの種類のスキーマ・オブジェクトはRETURNING句をサポートしません。この句は、デフォルトでは、INSERT操作またはUPDATE操作が実行されたものと同じデータベース・ラウンドトリップでリフレッシュされた値をより効率よく返すために、エンティティ・オブジェクトが使用します。

4.19.1 RETURNING句の使用を無効にする方法

これらの種類のスキーマ・オブジェクトはRETURNING句をサポートしていないので、RETURNING句をエンティティ・オブジェクトで無効にする必要がある場合があります。次の各手順では、実行方法について説明します。

始める前に:

RETURNING句をサポートしていないスキーマ・オブジェクトの種類に関する知識があると役立ちます。詳細は、「結合ビューまたはリモートDBLinkに基づくエンティティ・オブジェクト」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

この種のエンティティ・オブジェクトでRETURNING句の使用を無効にするには:

1. エンティティ・オブジェクトのカスタム・エンティティ定義クラスを有効にします。

2. カスタム・エンティティ定義クラスで、createDef()メソッドをオーバーライドしてsetUseReturningClause(false)を呼び出します。

3. Refresh on Insert属性がエンティティ・オブジェクトの主キーである場合は、「一意キー」プロパティを設定して、エンティティの他の属性を代替一意キーとして指定する必要があります。

4.19.2 実行時の処理: RETURNING句が無効な場合のリフレッシュ動作

「RETURNING句の使用を無効にする方法」の説明に従って、RETURNING句の使用を無効にすると、実行時には、エンティティ・オブジェクトが別のSELECT文を使用してRefresh on Insert動作およびRefresh on Update動作を実装し、挿入または更新の後でリフレッシュするための値を取得します。

4.20 ビジネス・ドメイン・レイヤーでの継承の使用

継承はオブジェクト指向開発の強力な機能であり、適切に使用すれば開発とメンテナンスを簡単にできます。「継承を使用する拡張コンポーネントの作成」で説明されているように、ADFビジネス・コンポーネントでは、継承を使用して既存のコンポーネントを拡張する新しいコンポーネントを作成し、新しいプロパティまたは動作を追加したり、親コンポーネントの動作を変更したりできます。継承は、再利用可能なビジネス・ドメイン・レイヤーで異なる種類のエンティティをモデリングする際に便利です。

注意:

この項の例は、SummitADF_Examplesワークスペースのoracle.summit.model.polymorphicパッケージの拡張です。

4.20.1 継承が有効な状況の理解

アプリケーションのデータベース・スキーマでは、同じ表の行に論理的に異なる種類のビジネス情報が格納される場合があります。このような表には、通常、各行に格納される情報の種類を決定する値を含む列があります。たとえば、アプリケーションのS_CUSTOMER表では、国内および国際の両方の顧客に関する情報が同一の表に格納されます。また、CUSTOMER_TYPE_CODE列の値によって、その行が表すS_CUSTOMERの種類が決まります。

Summit ADFサンプル・アプリケーションの実装にはこの区別は含まれていませんが、アプリケーションの改訂では次のことが必要になることが考えられます。

- 国内顧客に固有または国際顧客に固有の追加のデータベース利用の属性を管理する

- 国内顧客または国際顧客によって違いがあるすべてのユーザー向けに共通の動作を実装する

- 国内顧客のみまたは国際顧客のみに固有な新機能を実装する

図4-19は、Customers、Domestics、Internationalsの各エンティティ・オブジェクトを個別に作成し、異なる種類のビジネス情報をアプリケーション内でより形式的に区別できるようにした場合の、ビジネス・ドメイン・レイヤーの様子を示しています。国内および国際は顧客の特別な種類であるため、それに対応するエンティティ・オブジェクトはベース・エンティティ・オブジェクトのCustomersを拡張します。このベースのCustomersエンティティ・オブジェクトには、すべての種類のユーザーに共通する属性とメソッドがすべて含まれています。図のperformCustomerFunction()メソッドは、共通メソッドの1つを表しています。

その後、DomesticsおよびInternationalsエンティティ・オブジェクトの場合は、その種類のユーザーに対して一意の特定の追加属性とメソッドを追加できます。たとえば、Domesticsには型がStringの追加のState属性があり、国内顧客が所在する州を追跡できます。また、国内顧客に固有のperformDomesticFunction()メソッドもあります。同様に、Internationalsエンティティ・オブジェクトには、顧客が英語を話すかどうかを追跡するLanguage属性が追加されています。performInternationalFunction()は国際顧客に固有のメソッドです。

図4-19 継承を使用した顧客、国内、国際の区別

異なる種類の顧客を、ビジネス・ドメイン・レイヤーの継承階層において異なるエンティティ・オブジェクトとしてモデル化することで、共通するデータや動作の共有が簡単になり、ユーザーを区別するアプリケーションの部分を実装できます。

4.20.2 継承階層内にエンティティ・オブジェクトを作成する方法

継承階層にエンティティ・オブジェクトを作成するには、エンティティ・オブジェクト作成ウィザードを使用して各エンティティを作成します。

継承階層にエンティティ・オブジェクトを作成するには、次の作業を行います。

1. 「識別子列と個別の値の識別」の説明に従って、識別子列と値を識別します。

2. 「エンティティの種類に関連する属性のサブセットの識別」の説明に従って、エンティティ・オブジェクトごとに属性のサブセットを識別します。

3. 「継承階層へのベース・エンティティ・オブジェクトの作成」の説明に従って、ベース・エンティティ・オブジェクトを作成します。

4. 「継承階層へのサブタイプ・エンティティ・オブジェクトの作成」の説明に従って、サブタイプ・エンティティ・オブジェクトを作成します。

4.20.2.1 識別子列と個別の値の識別

異なる種類の情報を含む表に基づいて継承階層にエンティティ・オブジェクトを作成する前にまず、行の種類を区別するために使用されている表の列を識別する必要があります。

たとえば、S_CUSTOMER表では、これがCUSTOMER_TYPE_CODE列になることがあります。このような列は表の行を異なるグループに分離つまり識別するのに役立つため、識別子列と呼ばれます。

次に、表の識別子列で有効な値を決定します。値がわからない場合は、JDeveloperの「SQLワークシート」で簡単なSQL文を実行して答えを得ることもできます。ワークシートを使用するには次のようにします。

1. JDeveloperで開いたアプリケーションで、メイン・メニューから 「ウィンドウ」→「データベース」→「データベース」を選択します。

2. ワークスペース・ノードを開いて、接続を選択します。

3. データベース接続を右クリックし、「SQLワークシートを開く」を選択します。

図4-20は、「SQLワークシート」で、S_CUSTOMER表のCUSTOMER_TYPE_CODE列に対してSELECT DISTINCT問合せを実行した結果を示しています。これは、CUSTOMER_TYPE_CODE識別子の値DOMESTICおよびINTERNATIONALに基づいて行が2つのグループに分類されることを示しています。

図4-20 「SQLワークシート」を使用した識別子列の異なる値の検索

4.20.2.2 エンティティの種類に関連する属性のサブセットの識別

表に格納されている異なるビジネス・エンティティの種類の数がわかると、個別の項目をモデル化するために作成する必要のあるエンティティ・オブジェクトの数もわかります。通常は、項目の種類ごとに1つのエンティティ・オブジェクトを作成します。次に、階層のベースとして機能するエンティティを識別するため、各項目の種類に関係する属性のサブセットを特定する必要があります。

たとえば、StateとLanguageを除いてすべての属性はすべてのユーザーに関連することと次のことを調べると仮定します。

- Stateは国内顧客に固有である。

- Languageは国際顧客に固有である。

この情報からCustomersエンティティ・オブジェクトを階層のベースとし、DomesticsおよびInternationalsエンティティ・オブジェクトがそれぞれCustomersを拡張して固有の属性を追加するように決定できます。

4.20.2.3 継承階層へのベース・エンティティ・オブジェクトの作成

継承階層にベース・エンティティ・オブジェクトを作成するには、エンティティ・オブジェクト作成ウィザードを使用します。

始める前に:

継承階層のエンティティ・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビジネス・ドメイン・レイヤーでの継承の使用」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

また、「識別子列と個別の値の識別」の説明に従って、識別子列と値を判別し、「エンティティの種類に関連する属性のサブセットの識別」の説明に従って、エンティティ・オブジェクトごとに属性を判別する必要があります。

ベース・エンティティ・オブジェクトを作成する手順

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトを追加するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「エンティティ・オブジェクト」を選択し、「OK」をクリックします。

3. エンティティ・オブジェクト作成ウィザードの「名前」ページで、エンティティの名前とパッケージを指定し、エンティティのベースとなるスキーマ・オブジェクトを選択します。

この例では、エンティティ・オブジェクトをCustomersと名付け、これがS_CUSTOMER表に基づくようにします。

4. 「属性」ページで、ベース・エンティティ・オブジェクトに関係のない属性(ある場合)を「エンティティ属性」リストで選択し、「削除」をクリックして削除します。

この例では、State属性とLanguage属性をリストから削除します。

5. 「属性の設定」ページで、「属性の選択」ドロップダウン・リストを使用して、継承されるエンティティ・オブジェクトのファミリの識別子として機能する属性を選択し、「多相化識別子」チェック・ボックスを選択してそのことを示します。重要なこととして、このベース・エンティティ・タイプの行を識別するため、この識別子属性に対する「デフォルト値」を指定する必要もあります。

この例では、CustomerTypeCode属性を選択して識別子属性としてマークし、「デフォルト値」に値CUSTOMERを設定します。

注意:

識別子属性の「デフォルト値」を空白のままにしてもかまいません。空白のデフォルト値は、識別子列の値がIS NULLである行がこのベース・エンティティ・タイプとして扱われることを意味します。

6. 次に、「終了」をクリックします。

4.20.2.4 継承階層へのサブタイプ・エンティティ・オブジェクトの作成

継承階層にサブタイプ・エンティティ・オブジェクトを作成するには、エンティティ・オブジェクト作成ウィザードを使用します。

始める前に:

継承階層のエンティティ・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビジネス・ドメイン・レイヤーでの継承の使用」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

また、次のタスクを実行する必要があります。

1. 「識別子列と個別の値の識別」の説明に従って識別子列と値を調べます。

2. 「エンティティの種類に関連する属性のサブセットの識別」の説明に従って、エンティティ・オブジェクトごとに属性を調べます。

3. 「継承階層へのベース・エンティティ・オブジェクトの作成」の説明に従って、新しいエンティティ・オブジェクトが拡張する元となる親エンティティ・オブジェクトを作成します。

4. 親エンティティで識別子属性がすでに識別されていることを確認します。
識別されていない場合は、継承された子を作成する前に、概要エディタを使用して親エンティティの識別子属性で「多相化識別子」プロパティを設定します。

階層にサブタイプ・エンティティ・オブジェクトを作成するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトを追加するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「エンティティ・オブジェクト」を選択し、「OK」をクリックします。

3. エンティティ・オブジェクト作成ウィザードの「名前」ページで、エンティティの名前とパッケージを指定し、「拡張」フィールドの隣の「参照」ボタンをクリックして、作成しているエンティティが拡張される元となる親エンティティを選択します。

この例では、新しいエンティティをDomesticsと名付け、「拡張」フィールドでCustomersエンティティ・オブジェクトを選択します。

4. 「属性」ページの「エンティティ属性」リストに、基礎となる表からベース・エンティティ・オブジェクトに含まれない属性が表示されます。このエンティティ・オブジェクトに含めない属性を選択し、「削除」をクリックします。

この例では、Domesticsエンティティを作成しているため、Language属性を削除し、State属性はそのままにします。

5. 「オーバーライド」をクリックして識別子属性を選択し、属性メタデータをカスタマイズしてDomesticsエンティティ・サブタイプに個別の「デフォルト値」を提供できるようにします。

この例では、CustomerTypeCode属性をオーバーライドします。

6. 「属性の設定」ページで、「属性の選択」ドロップダウン・リストを使用して識別子属性を選択します。「デフォルト値」フィールドを変更し、作成しているエンティティ・サブタイプを定義する識別子属性に個別のデフォルト値を設定します。

この例では、CustomerTypeCode属性を選択し、「デフォルト値」を値DOMESTICに変更します。

7. 「終了」をクリックします。

注意:

同じ手順を繰り返して、Customersを拡張するInternationalsエンティティ・オブジェクトを定義し、Language属性を追加し、CustomerTypeCode識別子属性の「デフォルト値」を値INTERNATIONALに変更できます。

4.20.3 継承階層内のエンティティ・オブジェクトにメソッドを追加する方法

継承階層内のエンティティ・オブジェクトにメソッドを追加するには、エンティティ・オブジェクトでカスタムJavaクラスを有効にし、ソース・エディタを使用してメソッドを追加します。階層内のすべてのエンティティ・オブジェクトに共通するメソッドをベース・エンティティに追加し、サブタイプに固有のメソッドをサブタイプに追加します。また、必要に応じてサブタイプにおいてベース・エンティティ・オブジェクトのメソッドをオーバーライドできます。

4.20.3.1 階層内の全エンティティ・オブジェクトに共通するメソッドの追加

階層内のすべてのエンティティ・オブジェクトに共通するメソッドを追加するには、ベース・エンティティ・オブジェクトの実装クラスにメソッドを追加します。

始める前に:

継承階層のエンティティ・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビジネス・ドメイン・レイヤーでの継承の使用」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

また、次のタスクを実行する必要があります。

1. また、「継承階層内にエンティティ・オブジェクトを作成する方法」の説明に従って、ベース・エンティティ・オブジェクトとサブタイプを階層に作成します。

2. 「エンティティ・オブジェクトのカスタムJavaクラスの生成」の説明に従い、ベース・エンティティ・オブジェクトのカスタムJava実装クラスを作成します。

階層内の全エンティティ・オブジェクトに共通するメソッドを追加するには:

1. 「アプリケーション」ウィンドウで、ベース・エンティティ・オブジェクト実装クラス(CustomersImpl.javaなど)をダブルクリックします。

2. ソース・エディタで、メソッドを追加します。

たとえば、ベースCustomersエンティティ・オブジェクトのCustomersImplクラスに次のメソッドを追加します。

// In CustomersImpl.java
public void performCustomerFunction() {
System.out.println("## performCustomerFunction as Customer");
}

これはベース・エンティティ・オブジェクトのクラスなので、ここで実装するメソッドは、階層のすべてのサブタイプ・エンティティ・オブジェクトによって継承されます。

4.20.3.2 サブタイプ・エンティティでの共通メソッドのオーバーライド

階層内のすべてのエンティティ・オブジェクトに共通するサブタイプ・エンティティ・オブジェクトをオーバーライドするには、ベース・エンティティ・オブジェクトから継承した共通メソッドをサブタイプ・エンティティ・オブジェクトの実装クラスで修正します。

始める前に:

継承階層のエンティティ・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビジネス・ドメイン・レイヤーでの継承の使用」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

また、次のタスクを実行する必要があります。

1. また、「継承階層内にエンティティ・オブジェクトを作成する方法」の説明に従って、ベース・エンティティ・オブジェクトとサブタイプを階層に作成します。

2. 「階層内の全エンティティ・オブジェクトに共通するメソッドの追加」の説明に従って、ベース・エンティティ・オブジェクトの共通メソッドを作成します(サブタイプ・エンティティ・オブジェクトがオーバーライドします)。

3. 「エンティティ・オブジェクトのカスタムJavaクラスの生成」の説明に従い、サブタイプ・エンティティ・オブジェクトのカスタムJava実装クラスを作成します。

サブタイプ・エンティティ・オブジェクトのメソッドをオーバーライドするには:

1. 「アプリケーション」ウィンドウで、サブタイプ・エンティティ・オブジェクト実装クラス(DomesticsImpl.javaなど)をダブルクリックします。

2. サブタイプ・エンティティ・オブジェクト実装クラスをソース・エディタで開き、メイン・メニューから「ソース」→「メソッドのオーバーライド」を選択します。

3. 「メソッドのオーバーライド」ダイアログで、オーバーライドするメソッド(たとえば、performCustomerFunction()メソッド)を選択して、「OK」をクリックします。

4. ソース・エディタで、オーバーライドするメソッドの実装をカスタマイズします。

たとえば、Domesticsサブタイプ・エンティティ・オブジェクトのDomesticsImplクラスでperformCustomerFunction()メソッドをオーバーライドし、実装を次のように変更できます。

// In DomesticsImpl.java
public void performCustomerFunction() {
System.out.println("## performCustomerFunction as Domestics");
}

サブタイプ階層でエンティティ・オブジェクトのインスタンスについての作業を行う場合、複数の異なるサブタイプのインスタンスを処理することがあります。DomesticsおよびInternationalsエンティティ・オブジェクトはCustomersの特別な種類であるため、それらに共通するすべてが含まれるより汎用的なCustomersImpl型を使用して、それらのすべてで動作するコードを記述できます。階層内のサブタイプ・ファミリであるクラスのこのような汎用処理を行うとき、Javaは、使用可能なメソッドで最も固有性の高いオーバーライドを常に呼び出します。

つまり、CustomersImplのインスタンスでperformCustomerFunction()メソッドを呼び出し、実際にはさらに固有のDomesticsImplサブタイプがある場合、結果の出力は次のようになります。

## performCustomerFunction as Domestics

これに対し、標準のCustomersImplインスタンスによるデフォルトの出力結果は次のようになります。

## performCustomerFunction as Customer

4.20.3.3 サブタイプ・エンティティ・オブジェクトに固有のメソッドの追加

階層内のサブタイプ・エンティティ・オブジェクトに特有のメソッドを追加するには、ソース・エディタを使用してサブタイプの実装クラスにメソッドを追加します。

始める前に:

継承階層のエンティティ・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビジネス・ドメイン・レイヤーでの継承の使用」を参照してください。

他のエンティティ・オブジェクト機能を使用して追加できる追加機能に関する知識が役立つ場合もあります。詳細は、「エンティティ・オブジェクトの追加機能」を参照してください。

また、次のタスクを実行する必要があります。

1. また、「継承階層内にエンティティ・オブジェクトを作成する方法」の説明に従って、ベース・エンティティ・オブジェクトとサブタイプを階層に作成します。

2. 「エンティティ・オブジェクトのカスタムJavaクラスの生成」の説明に従い、サブタイプ・エンティティ・オブジェクトのカスタムJava実装クラスを作成します。

サブタイプ・エンティティ・オブジェクトに固有のメソッドを追加するには:

1. 「アプリケーション」ウィンドウで、サブタイプ・エンティティ・オブジェクト実装クラス(InternationalsImpl.javaなど)をダブルクリックします。

2. ソース・エディタで、メソッドを追加します。

たとえば、Internationalsサブタイプ・エンティティ・オブジェクトのInternationalsImplクラスに、performInternationalFunction()メソッドを追加できます。

// In InternationalsImpl.java
public void performInternationalFunction() {
System.out.println("## performInternationalFunction called");
}

4.20.4 継承の使用に関する必知事項

継承を使用すると、新しいベース・エンティティの導入、主キーによるサブタイプ・エンティティの検索、および多相エンティティ・オブジェクトの慣用名を持つビュー・オブジェクトの作成も行うことができます。

4.20.4.1 新しいベース・エンティティの導入

たとえば、Customersエンティティ・オブジェクトがS_CUSTOMERS表の実際の行に対応する場合は、継承階層でベース・エンティティの役割も果たします。つまり、そのすべての属性は、階層内の全エンティティ・オブジェクトに共通でした。しかし、Customersエンティティ・オブジェクトに国内または国際顧客に共通しない顧客固有のプロパティが必要な場合が発生することがあります。

このような場合は、階層内でベース・エンティティとして機能する新しいエンティティ・オブジェクト(BaseCustomersなど)を導入できます。これには、Customers、Domestics、Internationalsのすべてのエンティティ・オブジェクトに共通するすべての属性が含まれます。そして、この表に出現する具体的な行に対応する3つの各エンティティは、BaseCustomersから継承する属性と、個々のサブタイプに固有の属性を保持できます。BaseCustomers型では、CustomerTypeCode属性を識別子属性としてマークするかぎり、「デフォルト値」を空白にしておいてかまいません(または、表のCUSTOMER_TYPE_CODE列に出現しない他の値にします)。BaseCustomersエンティティのインスタンスはアプリケーションで使用されないため、識別子のデフォルト値は問題ではありません。

4.20.4.2 サブタイプ・エンティティ・オブジェクトとfindByPrimaryKey()メソッド

エンティティ定義でfindByPrimaryKey()メソッドを使用するときは、それを呼び出すエンティティ・オブジェクト型のエンティティ・キャッシュのみが検索されます。前述の例では、CustomersImpl.getDefinitionObject()をコールしてCustomersエンティティ・オブジェクトのエンティティ定義にアクセスする場合、そこでfindByPrimaryKey()をコールすると、たまたま顧客であるキャッシュ内のエントリのみが検索結果となります。これが求める動作である場合もあります。

しかし、主キーで継承階層内のサブタイプも含めてエンティティ・オブジェクトを検索する場合は、かわりにEntityDefImplクラスのfindByPKExtended()メソッドを使用できます。

たとえば、Customersエンティティ・オブジェクトのサブタイプを作成した場合、この代替検索メソッドを使用すると、エンティティ・オブジェクトが顧客、国内または国際のいずれであっても、主キーで検索できます。その後は、Javaのinstanceof演算子を使用して発見された型を検査し、CustomersImplオブジェクトをさらに固有のエンティティ・オブジェクト型にキャストして、そのサブタイプに固有の機能で作業できます。

4.20.4.3 多相エンティティ・オブジェクトの慣用名を持つビュー・オブジェクト

継承階層のベース・エンティティ・オブジェクトに対応するエンティティ・オブジェクトの慣用名を持つエンティティ・ベースのビュー・オブジェクトを作成するときは、ベース・エンティティのサブタイプ階層の複数の異なるサブタイプに対応する行を問い合せるように、ビュー・オブジェクトを構成できます。ビュー・オブジェクトの各行は、識別子属性の値の対応に基づいて、適切なサブタイプ・エンティティ・オブジェクトをエンティティ行の部分として使用します。このようなビュー・オブジェクトを設定して使用する方法に関する固有の指示は、「多相エンティティ・オブジェクトの慣用名を持つサブタイプ・ビュー・オブジェクトを作成する方法」を参照してください。

5 ビュー・オブジェクトを使用したSQL問合せの定義

この章では、ADFビュー・オブジェクトを作成して、Oracle ADFアプリケーションで使用するデータの結合、フィルタ、ソートおよび集約を行うSQL問合せを作成する方法について説明します。SQL派生属性をデータベース表の列や他の静的データソース(フラット・ファイルなど)にビュー・オブジェクトによりマップする方法も説明します。

この章の内容は次のとおりです。

- ビュー・オブジェクトについて

- 単一のデータベース表からのビュー・オブジェクト行の移入

- 宣言SQLモードでのビュー・オブジェクトの使用

- 静的データが移入されたビュー・オブジェクトの作成

- ビュー・オブジェクトへの計算属性および一時属性の追加

- 有効日付範囲を使用したビュー・オブジェクト行の制限

- 結合問合せ結果での複数表の使用

- ビュー・オブジェクトとカスタムSQLの操作

- 名前付きビュー基準の処理

- バインド変数の使用

- 行検索の使用

- ビュー・オブジェクト属性の値リスト(LOV)での作業

- ビュー・オブジェクトのUIヒントの定義

5.1 ビュー・オブジェクトについて

ビュー・オブジェクトは、SQL問合せをカプセル化しその結果の作業を簡略化するOracle Application Development Framework (Oracle ADF)コンポーネントです。データ・モデル・プロジェクトで作成できるビュー・オブジェクトにはいくつかのタイプがあります。

- データの更新を実行する場合のエンティティ・ベースのビュー・オブジェクト

- エンティティ・オブジェクトによるサポートのない場合の、エンティティに基づかないビュー・オブジェクト

- ビュー・オブジェクト自体によって定義されるデータに対する静的データ・ビュー・オブジェクト

- プログラムで移入されたビュー・オブジェクト(詳細は、「代替データソースに対するプログラムでのビュー・オブジェクトの使用」を参照)

エンティティ・ベースのビュー・オブジェクトでは、その属性が1つ以上の既存エンティティ・オブジェクトの属性とマップされるビュー・オブジェクトを作成する際に、更新可能な行をサポートするように構成できます。マッピングされたエンティティ・オブジェクトは、ビュー・オブジェクト定義にエンティティ・オブジェクトの慣用名として保存されます。このように、エンティティ・ベースのビュー・オブジェクトでは、エンティティ・オブジェクトと自動的に連携することにより、完全に更新可能なデータ・モデルが実現します。エンティティ・ベースのビュー・オブジェクトの慣用名では、クライアント側のタスクに必要なデータのみを問い合せ、マップされたエンティティ・オブジェクトとその行のエンティティ・キャッシュを活用してビュー行に対する変更を自動的に検証および保存します。エンティティ・ベースのビュー・オブジェクトは、SQL問合せをカプセル化し、マスター/ディテール階層にリンクしたり、アプリケーション・モジュールのデータ・モデルで使用できます。問い合せたデータに対する更新は、基礎となるエンティティ・キャッシュによって管理されます。これにより、同じエンティティ・オブジェクトに基づく各ビュー・オブジェクトの慣用名は、重複データをその慣用名に格納するのではなく、行のエンティティ・キャッシュをポイントするようになります。

エンティティ・ベースのビュー・オブジェクトとは異なり、エンティティのないビュー・オブジェクトでは、SQL問合せ言語を使用して問合せを記述する必要があります。エンティティを基礎としないビュー・オブジェクトにはエンティティから導出されたデフォルト値は使用されず、保留中の変更および更新された参照情報は反映されません。一方、エンティティ・ベースのビュー・オブジェクトでは、「ビュー・オブジェクトの作成」ウィザードおよび概要エディタを使用してSQL問合せを宣言的に構成できるため、問合せの記述が容易です。さらに、エンティティ・ベースのビュー・オブジェクトは、エンティティ・キャッシュを使用して問い合せたデータを管理するため、ビュー・オブジェクトの行キャッシュに対する更新に特別なランタイム処理を必要とする、エンティティ・オブジェクトの慣用名を持たないビュー・オブジェクトよりも、パフォーマンスが高くなります。そのため、ほとんどの場合は、データの読取りにのみ使用するビュー・オブジェクトを作成するときでも、エンティティにマップされたビュー・オブジェクトを作成することをお薦めします。

ただし、状況によっては、SQLベースの検証、UNION、GROUP BY問合せなど、エンティティにマップされていないビュー・オブジェクトを作成してデータの読取りに使用する方が適切な場合もあります。

設計時にSQL文を指定するビュー・オブジェクトを作成するかわりに、SQL文を含まないエンティティ・ベースのビュー・オブジェクトを作成することもできます。ADFビジネス・コンポーネントの設計時および実行時のこの機能は、宣言SQLモードと呼ばれます。ビュー・オブジェクト用のウィザードやエディタを宣言SQLモードで使用する場合、ビジネス・コンポーネント開発者にSQLの知識は必要ありません。宣言SQLモードでは、ランタイムの問合せ文はデータバインドされたUIコンポーネント内の属性の使用方法のみに基づいたものになります。

ビュー・オブジェクトに基礎となるエンティティ・オブジェクトの慣用名が1つ以上ある場合、新しい行の作成や、問合せ結果の行の変更または削除が可能です。エンティティ・ベースのビュー・オブジェクトは基礎となるエンティティ・オブジェクトと連携して、ビジネス・ルールを適用し、データベースに対する変更を永続的に保存します。また、エンティティ・ベースのビュー・オブジェクトは、エンティティのないビュー・オブジェクトにはない次のような機能を備えています。

- エンティティで管理されるキャッシュ内の変更(更新、挿入、削除)は、ビュー・オブジェクトの実行後も保持されます。

- 同じトランザクションの他のビュー・オブジェクトを介して行われた、関連するエンティティ・オブジェクト属性に対する変更は即時に反映されます。

- 新しい行の属性値は、基礎となるエンティティ・オブジェクト属性の値で初期化されます。

- 外部キー属性値が変更されると、参照情報が更新されます。

- 行(エンティティ)レベルの検証がサポートされています。

- 検証、ロック、順序付けられた更新などのコンポジット機能がサポートされています。

- 有効日指定、更新識別子およびビジネス・イベントがサポートされています。

5.1.1 ビュー・オブジェクトのユースケースと例

この章では、図5-1に示すようなビュー・オブジェクトの概念についてわかりやすく説明します。

- SQL問合せを作成する(明示的または宣言的に定義する)ことによりビュー・オブジェクトを定義します。

- ビュー・オブジェクト・インスタンスは、問合せのデータベース・トランザクションを提供するアプリケーション・モジュールと関連して使用します。

- ビュー・オブジェクトを1つ以上の他のビュー・オブジェクトにリンクして、マスター/ディテール階層を作成できます。

- 実行時には、ビュー・オブジェクトにより問合せが実行され、(RowSetオブジェクトで表される)行セットが生成されます。

- 各行は、対応する行キーによって識別されます。

- 行セット・イテレータを使用して、行セットの行を反復します。

- 一連のQuery-By-Example基準行を適用すると、ビュー・オブジェクトにより生成される行セットをフィルタリングできます。

図5-1 問合せを定義し、行の行セットを生成するビュー・オブジェクト

この章では、アプリケーション・モジュールのデータ・モデルでエンティティ・ベースのビュー・オブジェクトのインスタンスを使用して、再使用可能なビジネス・ドメイン・オブジェクトが持つ明確なオブジェクト指向カプセル化能力にSQLの完全なデータ形成能力を組み合せることにより、クライアントがビジネス・サービス・レイヤー情報を検索、更新、挿入および削除できるようにする方法について説明します。また、これらすべての作業についてコード行は必要ありません。この章では、図5-2に示すように、エンティティ・ベースのビュー・オブジェクトの概念についてわかりやすく説明します。

- 更新可能なビュー・オブジェクトは、1つ以上のエンティティ・オブジェクトの属性を参照して定義します。

- 関連付けられた複数のエンティティ・オブジェクトを使用することにより、参照情報の操作を簡略化できます。

- 基礎となるエンティティ・アソシエーションに基づいてビュー・リンクを定義できます。

- エンティティ・ベースのビュー・オブジェクトは、トランザクションを提供するアプリケーション・モジュールとの関連で使用します。

- 実行時に、ビュー行は、属性の格納および検証を基礎となるエンティティ・オブジェクトに委譲します。

図5-2 ビュー・オブジェクトとエンティティ・オブジェクトの連携による更新可能なデータ・モデルの有効化

5.1.2 ビュー・オブジェクトの追加機能

ビュー・オブジェクトで作業を開始する前に、その他のOracle ADF機能を理解しておくと役に立つ場合があります。次に、関連する他の機能へのリンクを示します。

- ビュー・オブジェクト定義で式がサポートされている場所でGroovyスクリプトを使用する方法の詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。

- 対話型のOracle ADFモデル・テスターを使用して、ビュー・オブジェクトの問合せ結果を検証する方法の詳細は、「ビュー・インスタンスの問合せのテスト」を参照してください。

- エンティティ・ベースのビュー・オブジェクトを含むトランザクションでエンティティ・キャッシュが果たす役割の詳細は、「実行時のビュー・オブジェクトとエンティティ・オブジェクトの連携処理」を参照してください。

- ビュー・オブジェクト・インスタンスで構成されるデータ・モデルを作成する方法の詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

- 通常、カスタム・ビュー・オブジェクト・クラスで記述、使用およびオーバーライドする一般的なコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

5.2 単一のデータベース表からのビュー・オブジェクト行の移入

ビュー・オブジェクトは、データソースからデータを取得する手段を備えています。ほとんどの場合、データベースがデータソースとなり、データの取得にはSQL問合せが使用されます。ADFビジネス・コンポーネントでは、JDBCと連携することによってこの問合せをデータベースに渡し、結果を取得できます。

ビュー・オブジェクトでSQL問合せが使用される場合、問合せ列がそのビュー・オブジェクトのビュー・オブジェクト属性にマップされます。これらの属性の定義は、ビュー・オブジェクトのXML定義ファイルに保存され、データ型および精度とスケールの指定など、これらの列の様々なプロパティを反映しています。

パフォーマンスに関するヒント

ビュー・オブジェクトに関連付けられた問合せに、実行ごとに値が変更される問合せパラメータが含まれる場合は、バインド変数を使用します。問合せでバインド変数を使用すると、データベースで問合せを再解析する必要なく、問合せを再実行できます。バインド変数は、ビュー・オブジェクトの概要エディタの「問合せ」ページでビュー・オブジェクトに追加できます。詳細は、「バインド変数の使用」を参照してください。

「ビュー・オブジェクトの作成」ウィザードでは、既存のエンティティ・オブジェクトの属性にマップされるビュー・オブジェクトもマップされないビュー・オブジェクトも作成できます。エンティティ・ベースのビュー・オブジェクトのみが、マップされたエンティティ・オブジェクトと自動的に連携し、ビジネス・ルールの適用とデータ・モデルの変更の永続的な保存が可能です。また、エンティティ・ベースのビュー・オブジェクトの「更新可能」機能を無効にし、読取り専用データの問合せを完全に宣言的に実行できます。ウィザードまたはエディタのカスタムSQLモードを使用してSQL問合せ言語を直接使用することもできますが、この場合、作成したビュー・オブジェクトでは、エンティティ・ベースのビュー・オブジェクトのトランザクション機能はサポートされません。

エンティティ・ベースのビュー・オブジェクトを作成する場合は、ビュー・オブジェクト定義全体を宣言的にしながらも、カスタマイズ可能なビュー・オブジェクトを維持できます。また、カスタムSQL問合せ編集に切り替えて、エンティティ・オブジェクトのみでは表現できない、ユニオンやグループ化などの問合せを作成することもできます。さらに、カスタムSQLビュー・オブジェクトは、ビュー・オブジェクト・ベースのキー存在バリデータによって使用されるSQLベースの検証問合せでも便利です。カスタムSQLモードを使用してビュー・オブジェクトを作成すると、ビュー・オブジェクトが更新可能であることを示すカスタム・コードを使用しないかぎり、ビュー・オブジェクトは読取り専用になります。

エンティティ・ベースのビュー・オブジェクトとエンティティのないビュー・オブジェクトの違いの詳細は、「ビュー・オブジェクトについて」を参照してください。

5.2.1 エンティティ・ベースのビュー・オブジェクトの作成方法

ビュー・オブジェクトの作成では、エンティティ・ベースのビュー・オブジェクトの作成が最も簡単な方法です。これは作成時にSQL文を自分で入力する必要がないため、カスタムSQLビュー・オブジェクトより簡単に作成できます。また、エンティティ・ベースのビュー・オブジェクトの方が、カスタムSQLビュー・オブジェクトより非常に多くの実行時機能が用意されています。

エンティティ・ベースのビュー・オブジェクトでは、ビュー・オブジェクトとエンティティ・オブジェクトが果す役割が明確に区別されています。

- ビュー・オブジェクトは、データ・ソースで、SQLを使用してデータを取得します。

- エンティティ・オブジェクトは、データ・シンクで、データの変更を検証および保存します。

ビュー・オブジェクトとエンティティ・オブジェクトの役割は明確に区別されているため、再使用可能なエンティティ・オブジェクトを変更せずに、異なるビュー・オブジェクトを複数作成でき、アプリケーションごとのユーザー・インタフェースで求められる方法で、データを計画、フィルタ、結合およびソートできます。実際、エンティティ・オブジェクトのコア・ビジネス・サービス・レイヤーを担当する開発チームを、エンド・ユーザー環境のサポートに必要な特定のアプリケーション・モジュールおよびビュー・オブジェクトを担当するチームから完全に独立させることができます。このような関係は、エンティティ・ベースのビュー・オブジェクトによってカプセル化されるメタデータによって実現されます。このメタデータでは、基礎となる1つ以上のエンティティ・オブジェクトの属性に対してSELECTリストの列がどのように関連付けられるかが指定されます。

使用するエンティティ・ベースのビュー・オブジェクトは、複数のデータベース表を基にできます。データベース結合を使用して複数の表をビュー・オブジェクトに追加するには、「結合問合せ結果での複数表の使用」を参照してください。

5.2.1.1 エンティティ・オブジェクトのすべての属性を持つビュー・オブジェクトの作成

基礎となるエンティティ・オブジェクトのすべての属性をクライアントが操作できるようにする場合は、「デフォルト・ビュー・オブジェクトの作成」ダイアログを使用すると、「アプリケーション」ウィンドウで選択したエンティティ・オブジェクトからすばやくビュー・オブジェクトを作成できます。デフォルト・ビュー・オブジェクトを作成するには、エンティティ・オブジェクトを選択して右クリックし、新規デフォルト・ビュー・オブジェクトを選択します。ビュー・オブジェクトにすべての属性を含めない場合は、「単一表からのエンティティ・ベースのビュー・オブジェクトの作成」で説明するように、ビュー・オブジェクトの作成ウィザードを使用して必要な属性のみを選択できます。

始める前に:

エンティティ・ベースのビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、目的のエンティティ・オブジェクトを自分で作成するか、エンティティ・オブジェクトの作成を担当する開発者に相談し、問合せ対象となるデータを知らせます。

デフォルトのエンティティ・ベースのビュー・オブジェクトを作成する手順:

1. 「アプリケーション」ウィンドウでエンティティ・オブジェクトを右クリックし、新規デフォルト・ビュー・オブジェクトを選択します。

このポップアップ・メニュー・オプションを使用すると、選択した単一のエンティティ・オブジェクトに基づいてビュー・オブジェクトを作成できます。ビュー・オブジェクト定義にさらにエンティティ・オブジェクトを追加する必要がある場合は、ビュー・オブジェクトの作成後に、ビュー・オブジェクトの概要エディタの「エンティティ・オブジェクト」ページを使用できます。

2. 「デフォルト・ビュー・オブジェクトを作成」ダイアログで、新しいビュー・オブジェクトのパッケージ名およびコンポーネント名を指定します。

「デフォルト・ビュー・オブジェクトを作成」ダイアログでは、「参照」をクリックして、既存のパッケージのリストからパッケージ名を選択できます。たとえば、図5-3では、「参照」をクリックして、アプリケーションのModelプロジェクトのクラスパス上にあるoracle.summit.model.entitiesパッケージを特定しています。

図5-3 エンティティ・オブジェクトのデフォルト・ビュー・オブジェクトの簡単な作成方法

作成される新しいエンティティ・ベースのビュー・オブジェクトは、「ビュー・オブジェクトの作成」ウィザードで作成できるものと同一のものです。これには、デフォルトで、「アプリケーション」ウィンドウで選択したエンティティ・オブジェクトを参照する単一のエンティティ・オブジェクトの慣用名があり、そのすべての属性が含まれます。最初は、このビュー・オブジェクトにはWHERE句もORDER BY句もないため、次のビュー・オブジェクトの操作には概要エディタを使用する必要があります。

- 不要な属性の削除

- WHERE句を使用した選択内容の限定

- ORDER BY句による結果の順序付け

- ビュー・オブジェクトのプロパティのカスタマイズ

5.2.1.2 単一表からのエンティティ・ベースのビュー・オブジェクトの作成

エンティティ・ベースのビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能な「ビュー・オブジェクトの作成」ウィザードを使用します。

始める前に:

エンティティ・ベースのビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。

単一表からエンティティ・ベースのビュー・オブジェクトを作成する手順:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するデータ・モデル・プロジェクトのパッケージを右クリックし、新規、「ビュー・オブジェクト」の順に選択します。

2. 「ビュー・オブジェクトの作成」ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。デフォルト設定の「エンティティ」を選択したままにして、このビュー・オブジェクトとその基礎となるエンティティ・オブジェクトの連動によってデータを管理します。「次へ」をクリックします。

3. 「エンティティ・オブジェクト」ページで、ビュー・オブジェクトでデータを使用するエンティティ・オブジェクトを選択します。「次へ」をクリックします。

このリストのエントリは、ビュー・オブジェクトが使用するエンティティ・オブジェクトを記録するため、エンティティ・オブジェクトの慣用名と呼ばれます。また、ビュー・オブジェクトがこのエンティティの属性を参照するため、各エントリはエンティティ参照とも呼ばれます。表結合を使用してエンティティ・オブジェクトの慣用名を追加で作成する方法の詳細は、「結合問合せ結果での複数表の使用」を参照してください。

たとえば、図5-4は、ProductEOエンティティ・オブジェクトを「選択済」リストに移動した結果を示しています。

図5-4 「ビュー・オブジェクトの作成」ウィザードの「エンティティ・オブジェクト」ページ

4. 「属性」ページで、各エンティティ・オブジェクトの慣用名から組み込む属性を「使用可能」リストから選択し、「選択済」リストに移動します。「次へ」をクリックします。

たとえば、図5-5は、ProductEOから属性が選択されたことを示しています。

図5-5 「ビュー・オブジェクトの作成」ウィザードの「属性」ページ

5. 「属性の設定」ページでは、「属性の選択」ドロップダウン・リストを使用してビュー・オブジェクト属性を切り替え、名前や初期設定を変更できます。

属性設定の詳細は、[F1]キーを押すか、「ヘルプ」をクリックしてください。

6. 「問合せ」ページで、実行時に最適化された問合せを計算を選択解除し、オプションで問合せにWHEREおよびORDER BY句を追加して、必要に応じてデータのフィルタ処理と並替えを行います。選択したエンティティ属性に基づいて、SELECT文が自動的に生成されます。

「WHERE」フィールドおよび「ORDER BY」フィールドの値には、WHEREキーワードやORDER BYキーワードを含めないでください。これらのキーワードは、実行時に問合せを実行する際に追加されます。

たとえば、図5-6では、名前と希望小売価格を基準にしてデータを順序付けるたために、ORDER BY句が指定されています。

図5-6 「ビュー・オブジェクトの作成」ウィザードの「問合せ」ページ

7. 「終了」をクリックします。

5.2.2 エンティティ・ベースのビュー・オブジェクトの作成時の処理

ビュー・オブジェクトを作成する際、JDeveloperでビュー・オブジェクトの宣言的設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリに保存されます。たとえば、viewsパッケージに追加されたビュー・オブジェクトProductVOには、プロジェクトのソース・パスにXMLファイル./views/ProductVO.xmlが作成されます。

ビュー・オブジェクト設定を表示するには、「アプリケーション」ウィンドウで目的のビューを選択して、「構造」ウィンドウを開きます。「構造」ウィンドウは、SQL問合せ、エンティティ・オブジェクトの慣用名および各属性のプロパティなどXML定義のリストを表示します。エディタでXML定義を開くには、対応するノードを右クリックして「ソースに移動」を選択します。

注意:

ADFビジネス・コンポーネントに対してデフォルトのJavaクラスを生成するようにJDeveloperの設定を構成すると、ウィザードにより、オプションのカスタム・ビュー・オブジェクト・クラス(ProductVOImpl.javaなど)またはカスタム・ビュー行クラス(ProductVORowImpl.javaなど)あるいはその両方も作成されます。設定の詳細は、「ADFビジネス・コンポーネントのモデル・プロジェクト・プロパティのカスタマイズ方法」を参照してください。

図5-7は、エンティティ・ベースのビュー・オブジェクトProductVOと、この問合せ文で参照される1つのエンティティの慣用名を示しています。点線は、問合せのSELECTリストの列を、ビュー・オブジェクトで使用されるエンティティ・オブジェクトの属性にマップする、エンティティ・ベースのビュー・オブジェクトのXMLドキュメントで取得されるメタデータを表します。

図5-7 SQL問合せとエンティティ属性マッピング・メタデータをカプセル化するビュー・オブジェクト

5.2.3 更新不可のビュー・オブジェクトに関する必知事項

「ビュー・オブジェクトの作成」ウィザードを使用してエンティティ・ベースのビュー・オブジェクトを作成する場合、ビュー・オブジェクトの属性はデフォルトで更新可能になります。ビュー・オブジェクトのすべての属性を読取り専用にする場合は、ウィザードでエンティティ・オブジェクトを追加するときに「更新可能」の選択を解除できます。作成した後に、SQLにマップされた表の列を更新できるようにビュー・オブジェクトを変換できます。ただし、属性の「更新可能」プロパティを変更するのみでは、この目的は達成できません。読取り専用のビュー・オブジェクトを削除してから、目的の属性が更新可能になるようにエンティティ・ベースのビュー・オブジェクトを再作成する必要があります。

5.2.4 ビュー・オブジェクトの編集方法

ビュー・オブジェクトを作成した後、ビュー・オブジェクトの概要エディタでその設定を編集できます。

パフォーマンスに関するヒント

データをフェッチするためにビュー・オブジェクトをどのように構成するかは、ビュー・オブジェクトの実行時パフォーマンスにおいて重要な役割を果します。パフォーマンスを最適化するために編集可能なチューニング・パラメータの詳細は、「ビュー・オブジェクトの実行時パフォーマンスの最適化に関する必知事項」を参照してください。

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

ビュー・オブジェクト定義を編集するには:

1. 「アプリケーション」ウィンドウで、編集するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、目的のナビゲーション・タブをクリックします。

ビュー・オブジェクトの概要エディタの各ページでは、SQL問合せの調整、属性名の変更、名前付きバインド変数の追加、UIコントロール・ヒントの追加、Java生成オプションの制御およびその他の設定の編集を実行できます。

5.2.4.1 基礎となるエンティティ・オブジェクト属性の継承プロパティのオーバーライド

エンティティ・ベースのビュー・オブジェクトに関して興味深い特徴の1つは、基礎となるエンティティ・オブジェクト属性に関連する各属性がその属性のプロパティを継承することです。図5-8は、継承された属性が選択されている状態でビュー・オブジェクト・エディタの「属性」ページの「詳細」セクションを示しています。ここでは、Javaの属性タイプや問合せ列のタイプなどのフィールドは無効になっており、これらの値は、このビュー・オブジェクトが関連付けられている基礎となるエンティティ・オブジェクトの関連属性から継承されています。属性のデータ型などの一部のプロパティは継承され、ビュー・オブジェクト・レベルでは変更できません。

QueryableおよびUpdatableなどの他のプロパティは継承されますが、オーバーライド後の設定の方が継承された設定より制限が大きい場合、これらのプロパティをオーバーライドできます。たとえば、基礎となるエンティティ・オブジェクトの属性に対する「更新可能」設定は、「常に」です。図5-8のように、ビュー・オブジェクトの概要エディタで「属性」ページの「詳細」セクションにより、対応するビュー・オブジェクト属性を、制限がより大きい「新規の間」または「なし」などに設定できます。ただし、基礎となるエンティティ・オブジェクトの属性に対する「更新可能」設定が「なし」である場合、エディタでは、ビュー・オブジェクトの関連属性をより制限の小さい「常に」などに設定できません。

図5-8 基礎となるエンティティ・オブジェクトから継承されたビュー・オブジェクト属性のプロパティ

5.2.4.2 概要エディタでのビュー・オブジェクトの属性表示のカスタマイズ

概要エディタでビュー・オブジェクトを編集するときに、概要エディタの「属性」ページをカスタマイズし、表示されるビュー・オブジェクトの属性表を有効活用することができます。

属性表でカスタマイズできるのは、属性表に列として表示する属性プロパティのリスト、属性表に表示される列の順序(左から右)、列のソート順、列の幅などです。表示可能な列の全リストは、属性で編集できるプロパティに対応します。

たとえば、ビュー・オブジェクトのどの属性が更新可能かを即座に把握する必要がある場合は、属性表に表示する列として「更新可能」プロパティを追加できます。また、属性の「ラベル」プロパティを列として追加し、エンド・ユーザーに表示されるものと同じ説明を表示できます。また、エンティティ・オブジェクトの慣用名に基づいて属性のリストを表示する必要があるとします。その場合は、「エンティティ・オブジェクトの慣用名」列を表示して、この列に基づいて属性表全体をソートできます。

最も有益な列のリストを含めるように属性表を設定した後、属性表を右クリックして「すべてのビュー・オブジェクトに適用」を選択すると、他のビュー・オブジェクトに表示される属性表にも同じ列セットを適用することができます。

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

属性表の表示をカスタマイズするには:

1. 「アプリケーション」ウィンドウで、属性表の表示をカスタマイズするビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、属性列ヘッダー右(属性表のボタン・バー下)のドロップダウン・メニュー・アイコンをクリックし、「列の選択」を選択します。

図5-9 概要エディタに表示する属性列の変更

4. 「列の選択」ダイアログで、次のアクションを実行します。

a. 概要エディタの属性表に表示される列のリストを変更するには、左/右シャトル・ボタンをクリックします。概要エディタには、「選択されたもの」リストに表示される属性プロパティに対応する列のみが表示されます。

b. 概要エディタの属性表の列の位置を変更するには、選択項目を移動のボタンの1つをクリックします。概要エディタの属性プロパティは、「選択されたもの」リストの上位にあるプロパティから、左から右に配置されて表示されます。

5. 「OK」をクリックします。

6. 概要エディタの「属性」ページで、次のアクションを実行します。

a. 概要エディタの属性表の列の位置を変更するには、列ヘッダーを選択してドラッグします。

b. 選択した列を基準として属性表のすべての列をソートするには、列ヘッダーをクリックします。
この機能は、特定の列に注目する必要がある場合に特に有益です。たとえば、エンティティ・ベースのビュー・オブジェクトの場合、「エンティティ・オブジェクトの慣用名」列ヘッダーをクリックして、基礎となるエンティティ・オブジェクトごとに属性表の属性をグループ化できます。

c. 属性表の列の幅を調節するには、列ヘッダーの境界線をクリックしてドラッグします。

d. 現在の属性表に表示されている列を変更するには、列ヘッダー右のドロップダウン・リストをクリックし、表示されている列のリストから選択します。
現在のビュー・オブジェクトの概要エディタの属性表表示を簡易化する場合に、この機能によって容易に列を非表示にできます。

7. 列の変更(列のリスト、列の順序、列のソート、列幅を含む)をすべての他のビュー・オブジェクトの概要エディタに拡張する場合は、列ヘッダー右のドロップダウン・メニューをクリックし、「すべてのビュー・オブジェクトに適用」をクリックします。
この機能により、ビュー・オブジェクト全体で同じ属性を容易に比較できます。概要エディタにより、「列の選択」ダイアログで選択した列(および順序)、および現在の属性表の列ソートと列幅が、ユーザーが編集するすべてのビュー・オブジェクトに適用されます。開いている概要エディタに現在表示中のビュー・オブジェクトは、これらの設定によって更新されないため、ビュー・オブジェクトの概要エディタを閉じてからもう一度開き、このビュー・オブジェクトをもう一度開いて設定が適用されたことを確認してください。

5.2.4.3 ビュー・オブジェクトのソース・ファイルの属性の順番の変更

ビュー・オブジェクト定義を作成した後、ビュー・オブジェクトが問い合せる属性の順序を変更できます。このビュー・オブジェクト編集機能により、ビュー・オブジェクトの概要エディタの「属性」ページに表示される属性表の属性の順序を容易に変更できます。この機能は、特定の属性に対して作用し、現在のビュー・オブジェクトのXML定義を変更するため、ユーザーが編集する別のビュー・オブジェクトには適用されません。または、概要エディタの属性表の列ヘッダーをクリックして、ソース・ファイルに影響を与えずに、ビュー・オブジェクトの概要エディタの「属性」ページの属性表示をソートする方法もあります。

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

ビュー・オブジェクトのソース・ファイルの属性の順序を変更する手順:

1. 「アプリケーション」ウィンドウで、変更するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、「ソース・オーダーの設定」をクリックします。

3. 「ソース・オーダーの設定」ダイアログで、位置を変更する属性を選択し、選択項目を移動のボタンの1つをクリックします。

4. 「OK」をクリックします。

この機能は、ユーザーが編集する他のビュー・オブジェクトには影響せず、現在のビュー・オブジェクトにのみ適用されます。

5.2.5 ビジネス・コンポーネント・ダイアグラムでのビュー・オブジェクトの表示方法

JDeveloperのUMLダイアグラムを使用すると、ビジネス・コンポーネント・ダイアグラムを作成してビジネス・サービス・レイヤーを視覚化できます。JDeveloperのUMLダイアグラムでは、エンティティ・オブジェクトのサポートのみならず、ビュー・オブジェクトをダイアグラムにドロップして、その構造とエンティティ・オブジェクトの慣用名を視覚化できます。たとえば、oracle.summit.modelパッケージに新しいビジネス・コンポーネント・ダイアグラムを作成し、CustomerAddressVOビュー・オブジェクトを「アプリケーション」ウィンドウからダイアグラムにドラッグすると、図5-10に示すように、そのエンティティ・オブジェクトの慣用名が表示されます。ノードを拡張して表示すると、ダイアグラムには、ビュー・オブジェクトのエンティティ・オブジェクトの慣用名を含む部分が表示されます。

図5-10 ビジネス・コンポーネント・ダイアグラム内のビュー・オブジェクトおよびそのエンティティ・オブジェクトの慣用名

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。

エンティティ・ダイアグラムの作成方法を理解しておくと役立つ場合があります。「ビジネス・レイヤーのエンティティ・オブジェクトの図の作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

既存のビュー・オブジェクトをモデル化するビジネス・コンポーネント・ダイアグラムを作成する手順:

1. 「アプリケーション」ウィンドウで、ビジネス・コンポーネント・ダイアグラムを作成するデータ・モデル・プロジェクトのパッケージを右クリックし、「新規」、「ビジネス・コンポーネント・ダイアグラム」の順に選択します。

2. ビジネス・コンポーネント・ダイアグラムの作成ダイアログで、ダイアグラム名と、ダイアグラムの作成先のパッケージ名を入力します。追加のダイアグラム機能があれば、選択します。

3. 「OK」をクリックします。

4. 既存のビュー・オブジェクトをダイアグラムに追加するには、「アプリケーション」ウィンドウでこれらのオブジェクトを選択し、ダイアグラムにドロップします。

5.3 宣言SQLモードでのビュー・オブジェクトの使用

実行時に、ADFビジネス・コンポーネントとJDBCが連携して問合せをデータベースに渡し、その結果を取得する場合、データの取得にはSQL問合せが使用されます。設計時にSQL文を指定するビュー・オブジェクトを作成するかわりに、SQL文を含まないエンティティ・ベースのビュー・オブジェクトを作成することもできます。ADFビジネス・コンポーネントの設計時および実行時のこの機能は、宣言SQLモードと呼ばれます。データ・モデルの開発者がビュー・オブジェクト用のウィザードやエディタを宣言SQLモードで使用する場合は、SQLの知識は必要ありません。宣言SQLモードでは、ビュー・オブジェクトに定義する必要のあるメタデータに基づいて、ADFビジネス・コンポーネント・ランタイムによって次のようにSQL問合せ文が生成されます。

- レンダリング済WebページのデータバインドされたUIコンポーネントに、エンティティ・オブジェクトの属性が1つ以上使用されていることに基づいて、SELECTリストおよびFROMリストを生成します。
実行時問合せ文を最適化するには、ビュー・オブジェクトの属性ごとに制御できるIsSelectedプロパティ設定を変更し、データバインドされたUIコンポーネントが使用する属性のみに基づくように指定します。デフォルトでは、宣言SQLモードでビュー・オブジェクトに追加した属性ごとに、このプロパティはIsSelected=trueに設定されています。このデフォルト設定では、データバインドされたコンポーネントによってUIに公開されるかどうかにかかわらず、追加された属性はSQL文で選択されます。実行時問合せ文を最適化するためにプロパティ設定を変更する方法の詳細は、「宣言的SQLビュー・オブジェクトを作成する方法」を参照してください。

- ADF RESTfulウェブ・サービスの場合、URL問合せパラメータ・フィールドを使用して指定された属性のリストに基づいて、SELECT句を生成します。
ADF RESTリソースのバッキング・ビュー・オブジェクトで実行されるSQL SELECT文は、実行時に、ビュー・オブジェクトがどのように作成されるかに基づきます。宣言SQLモードを有効にして作成するビュー・オブジェクトのみが、問合せパラメータfieldsにより命名された属性のリストのみを使用して作成した最適化されたSQL SELECT文をサポートします。非宣言ビュー・オブジェクトで実行されるSELECT文は、ビュー・オブジェクト定義のすべての属性を含みます。実行時の最適化を実現するには、ADF Business Componentsデベロッパで、宣言SQLモードのみを使用してADF RESTリソースに対するビュー・オブジェクトを作成することをお薦めします。

- ビュー・オブジェクト定義に追加するビュー基準に基づいて、WHERE句を生成します。

- ビュー・オブジェクト定義に追加するソート基準に基づいて、ORDER BY句を生成します。

- ビュー・オブジェクト定義に追加する名前付きビュー基準に基づいて、表の結合がサポートされるようにWHERE句を拡張します。

- ビュー・リンク定義のリンク元またはリンク先に追加するビュー基準に基づいて、マスター/ディテール・ビュー・フィルタリングがサポートされるようにWHERE句を拡張します。

また、宣言SQLモードのビュー・オブジェクトによって実行時に生成されるSQL文は、「プロジェクト・プロパティ」ダイアログの「ビジネス・コンポーネント」ページで指定されるSQLプラットフォームによって決まります。

注意:

現在、ランタイムSQL生成用にサポートされているプラットフォームには、SQL92 (ANSI)およびOracleスタイルがあります。SQLプラットフォームをプロジェクト用に設定する方法の詳細は、「データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法」を参照してください。

宣言SQLモードの選択は、JDeveloperで、「ビュー・オブジェクトの作成」ウィザードで作成するすべてのビュー・オブジェクトのデフォルト設定としてサポートされます。ウィザードでは、設計時にカスタムSQLを作成するときに作成したビュー・オブジェクトについて、宣言SQLモードの設定をオーバーライドできます。

カスタムSQLを操作する場合、設計時に作成するビュー・オブジェクト定義には、常にアプリケーション・モジュールの定義済データベース接続に必要なSQLプラットフォームに基づいたSQL文全体が含まれます。そのため、SQLに依存しない機能は、カスタムSQLモードで作成したビュー・オブジェクトには適用されません。設計時にSQLが必要な場合にビュー・オブジェクトをカスタマイズするためのウィザードおよびエディタの使用の詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。

5.3.1 宣言的SQLビュー・オブジェクトを作成する方法

JDeveloperで作成するビュー・オブジェクトはすべて、同一の設計時ウィザードおよびエディタに依存します。ただし、宣言SQLモードを有効にした場合、このウィザードおよびエディタでは、SQLの表示や入力を行うことなくビュー・オブジェクト定義をカスタマイズできるようになります。たとえば、「ビュー・オブジェクトの作成」ウィザードの「問合せ」ページでは、宣言SQLモードが有効になると、標準モードでは表示された生成されたSQLフィールドが表示されません。

さらに、宣言SQLモードの場合、ウィザードやエディタではWHERE句およびORDER BY句を入力できないため、それぞれビュー基準とソート基準を定義し、これらの句と同等の機能を用意します。宣言SQLモードでは、これらの基準は、ビュー・オブジェクトのメタデータ定義内に記述され、実行時に対応するSQL句に変換されます。データバインドされたUIコンポーネントで、フィルタリングされたデータやソートされたデータを表示する必要がない場合は、ビュー・オブジェクト定義でビュー基準やソート基準を省略できます。

このようなデータを表示する必要がある場合は、宣言SQLモードを有効にした後、基本的にはエンティティ・ベースのビュー・オブジェクトの作成と同じ手順に従って、SQLに依存しないビュー・オブジェクトを作成します。たとえば、ビュー・オブジェクトでは、目的の実行時問合せをサポートするために必要なエンティティ・オブジェクト・メタデータのカプセル化が必要です。また、エンティティ・ベースのビュー・オブジェクトを使用する場合と同様、実行時に生成されるFROMリストの列は、ビュー・オブジェクトの基礎となる1つ以上のエンティティ・オブジェクトの属性に関連付けられている必要があります。宣言SQLモードでは、ビュー・オブジェクト定義におけるエンティティ・オブジェクトの属性を追加または削除する際にウィザードまたはエディタを使用することによって、この要件は自動的に満たされます。

宣言SQL問合せを最適化し、ビュー・オブジェクトに追加する属性がデータバインドされたUIコンポーネントによって実行時にレンダリングされるかどうかのみに基づいてSQL問合せ文のSELECT句とFROM句を生成する場合には、追加したすべての属性の「問合せで選択済」チェックボックスの選択を解除する(ビュー・オブジェクト定義でIsSelected=falseに設定する)必要があります。デフォルトでは、IsSelected=trueプロパティは、宣言SQLモードでビュー・オブジェクトに追加した各属性に対してtrueに設定されています。このデフォルト設定は、属性がデータバインドされたUIコンポーネントによって公開されるかどうかにかかわらず、追加された属性がSQL文で選択されることを意味します。宣言SQLモードで新しいビュー・オブジェクトを作成する場合、「ビュー・オブジェクトの作成」ウィザードの「属性の設定」ページを使用して各属性の設定を変更できます。ビュー・オブジェクトを作成した後にこの設定を変更する必要がある場合は、「プロパティ」ウィンドウを使用して、ビュー・オブジェクト・エディタの「属性」ページで選択した1つ以上の属性の「問合せで選択済」設定を変更できます。

パフォーマンスに関するヒント

SQL文を動的に生成するように構成されたビュー・オブジェクト・インスタンスは、同じキー・エンティティ・オブジェクトのリストを持つすべての属性のサブセットが後続のページ・ナビゲーションで使用される場合、ページ・ナビゲーション中にデータベースに再問合せを実行します。このため、必要なすべての属性のスーパーセットをアクティブ化して後続の問合せ実行を排除すると、パフォーマンスを向上できます。

始める前に:

宣言SQLモードに関する知識が役立つ場合があります。詳細は、「宣言的SQLビュー・オブジェクトを作成する方法」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

宣言SQLベースのビュー・オブジェクトを作成する手順:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するデータ・モデル・プロジェクトのパッケージを右クリックし、「新規」、「ビュー・オブジェクト」の順に選択します。

2. 「ビュー・オブジェクトの作成」ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。デフォルト設定の「エンティティ」を選択したままにして、このビュー・オブジェクトとその基礎となるエンティティ・オブジェクトの連動によってデータを管理します。「次へ」をクリックします。

データ選択についてこれ以外を選択した場合、「ビュー・オブジェクトの作成」ウィザードでは宣言SQLモードは無効になります。

3. 「エンティティ・オブジェクト」ページで、ビュー・オブジェクトでデータを使用するエンティティ・オブジェクトを選択します。「次へ」をクリックします。

エンティティ・オブジェクトを結合するビュー・オブジェクトを作成する場合は、セカンダリ・エンティティ・オブジェクトをリストに追加できます。より複雑なエンティティ・ベースのビュー・オブジェクトを作成する方法は、「エンティティ・ベースのビュー・オブジェクトに対する結合の作成方法」を参照してください。

4. 「属性」ページで、「使用可能」リストからエンティティ・オブジェクトの慣用名の属性を少なくとも1つ選択し、それを「選択済」リストに移動します。選択しなかった属性は、ビュー基準およびソート基準には使用できません。「次へ」をクリックします。

(「属性の設定」ページで)属性をカスタマイズする場合、または(「問合せ」ページで)ビュー基準またはソート基準に属性を使用する場合は、それらの属性を選択します。また、実行時に生成される問合せのFROMリストに表示される表は、選択したエンティティ・オブジェクトの属性に対応する表に限定されます。

5. 「属性の設定」ページで、「属性の選択」ドロップダウン・リストを使用してビュー・オブジェクトの属性を切り替え、「問合せで選択済」で、実行時までSQL文への追加を遅らせる各属性の選択を解除します。

デフォルトでは、宣言SQLモードで追加したすべてのオブジェクト属性の「問合せで選択済」チェックボックスが選択されています。このデフォルト設定により、追加されたすべての属性が選択された状態でSQL文が生成されます。属性のこのチェックボックスの選択を解除すると、IsSelectedプロパティがfalseに設定され、この属性が選択されるかどうかは、データバインドされたUIコンポーネントが使用する属性によって、実行時に決定されます。

6. 必要に応じて、属性名や属性の初期設定を変更します。「次へ」をクリックします。

7. 「問合せ」ページで、まだ表示されていない場合は実行時に最適化された問合せを計算を選択します。ウィザードにより、宣言SQLモードに変更されます。

「ビュー・オブジェクトの作成」ウィザードでは、宣言SQLモードがデフォルトで有効になります。デフォルト・モードでは、設計時にSQLに依存しないエンティティ・ベースのビュー・オブジェクトを作成できます。宣言SQLモードはカスタムSQLモードの代替であり、「ビュー・オブジェクトの作成」ウィザードでSQL文を直接作成できます。実行時に最適化された問合せを計算を選択解除すると、カスタムSQLモードが有効になります。

8. 必要に応じて、データのフィルタリングや順序付けを行うためにWHERE基準およびORDER BY基準を定義します。実行時には、作成した基準に基づいて、対応するSQL文がADFビジネス・コンポーネントにより自動的に生成されます。

「WHERE」フィールドの横にある「編集」をクリックし、データのフィルタリングに使用するビュー基準を定義します。入力したビュー基準は、実行時にWHERE句に変換された上で問合せ文に適用されます。ビュー基準の指定の詳細は、「名前付きビュー基準の処理」を参照してください。

「ORDER BY」フィールドで、「使用可能」リストから目的の属性を選択し、「選択」リストに移動します。選択しなかった属性は、実行時に生成されるSQLのORDER BY句には使用されません。結果を複数の列でソートする場合は、さらに他の属性を「選択済」リストに追加します。ソートの優先順位に従って、選択した属性をリスト内で並べ替えます。次に、それぞれのソート属性に対して、ソートを昇順で実行するか降順で実行するかを指定します。それぞれの属性にソート順序を指定すると、UIコンポーネントでは無視される属性に対して必要なソート順序が適用されます。

たとえば、図5-11に示すように、CustomerCardStatusビュー・オブジェクトに対して、CUSTOMERS表の行のうち特定のクレジット・カード・コードを持つ顧客の行のみが表示されるように制限するには、「WHERE」フィールドのビュー基準によって、CardTypeCode属性を実行時に決定される値に制限します。顧客IDおよび顧客のカードの有効期限を基準にデータを並べ替えるには、「ORDER BY」フィールドで、それらの属性を「選択済」リストに指定します。

図5-11 宣言SQLモードが選択された「ビュー・オブジェクトの作成」ウィザードの「問合せ」ページ

9. 「終了」をクリックします。

5.3.2 表結合が適用された場合に宣言SQLベースのビュー・オブジェクトをフィルタリングする方法

エンティティ・ベースのビュー・オブジェクトを作成する場合、ビュー・オブジェクト定義では複数のエンティティ・オブジェクトを参照できます。宣言SQLモードで作成するビュー・オブジェクトの場合、ベース・エンティティ・オブジェクトがビュー・オブジェクト定義からアクティブ化されるかどうかは、実行時におけるデータバインドされたUIコンポーネントの要件によって決まります。UIコンポーネントに複数のエンティティ・オブジェクトの属性値が表示される場合、実行時に生成されたSQLには、目的の表に対して問合せを行うためのJOIN演算子が含まれます。

作成する他のビュー・オブジェクトと同様に、名前付きビュー基準を適用すると、表結合から得られる結果をフィルタリングできます。標準モードのビュー・オブジェクトの場合、すべてのエンティティ・オブジェクトおよびその属性は、ビュー・オブジェクト定義により参照され、ビュー・オブジェクトのSQL文に自動的に取り込まれます。ただし、宣言SQLモードを使用する場合、実行時までSQLは生成されないため、ビュー基準が適用されるかどうかは判断できません。

注意:

宣言SQLモードでは、ビュー・オブジェクト定義を作成する際に、WHERE句を指定するためのビュー基準を定義できます(オプション)。このタイプのビュー基準が存在する場合は、デフォルトで実行時に適用されます。このようなビュー基準の使用方法の詳細は、「宣言的SQLビュー・オブジェクトを作成する方法」を参照してください。

UIコンポーネントには、宣言SQLモードで定義された複数のエンティティ・オブジェクトを持つビュー・オブジェクトのSQL JOINを実行できるだけの十分な属性が表示されない場合があるため、問合せ結果をフィルタリングするために定義した名前付きビュー基準を実行時に条件付きで適用する必要があります。つまり、宣言SQLベースのビュー・オブジェクトに対して作成した名前付きビュー基準は、自動フィルタとして必ず適用する必要はありません。宣言SQLモードをサポートするため、宣言SQLモードで作成されたビュー・オブジェクトに対する名前付きビュー基準の適用は、そのビュー基準が参照する属性にUIコンポーネントがバインドされる場合に限定するよう設定できます。ただし、名前付きビュー基準が、一度適用されると、フィルタリングされた結果セットを表示するというUIコンポーネントの要件がサポートされます。

始める前に:

実行時におけるSQL非依存性に関する知識が役立つ場合があります。詳細は、「宣言SQLモードでのビュー・オブジェクトの使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「宣言的SQLビュー・オブジェクトを作成する方法」の説明に従って、宣言SQLモードを有効にしてビュー・オブジェクトを作成します。

- 「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー基準を作成し、表結合の結果をフィルタリングします。
名前付きビュー基準を作成するには、「ビュー基準の編集」ダイアログを使用して、結合されたエンティティ・オブジェクトから1つ以上の属性を選択します。その後、「プロパティ」ウィンドウでAppliedIfJoinSatisfiedを設定して条件付きの使用を可能にします。

結合が要件を満たしている場合にのみフィルタリングするビュー基準を定義するには:

1. 「アプリケーション」ウィンドウで、表結合をサポートする宣言的SQLビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビュー基準」ナビゲーション・タブをクリックします。

3. 「ビュー基準」ページで、宣言的SQLビュー・オブジェクトをフィルタリングするために作成したビュー基準を選択します。

結合のビュー基準は、結合されたエンティティ・オブジェクトの属性のみを参照している必要があります。

4. 「プロパティ」ウィンドウで、結合されたエンティティ・オブジェクトから1つ以上の属性を選択したら、「AppliedIfJoinSatisfied」ドロップダウン・リストから「true」を選択します。

プロパティの値をtrueに設定すると、ビュー基準によって参照される属性がUIコンポーネントで必要になる場合のみ、ビュー基準が適用されます。デフォルト値のfalseでは、ビュー基準は実行時に自動的に適用されます。宣言SQLモード・ベースのビュー・オブジェクトの場合、値をtrueに設定すると、ビュー・オブジェクトのデータバインドされたUIコンポーネントの要件に応じて問合せフィルタが適用されます。

5.3.3 宣言SQLモードでマスター/ディテール関連のビュー・オブジェクトをフィルタリングする方法

標準モードのビュー・オブジェクトを使用する場合と同様に、宣言SQLモードで作成したビュー・オブジェクトを他のビュー・オブジェクトにリンクし、任意の複雑さでマスター/ディテール階層を構成できます。ビュー・リンクの作成手順は、「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」で説明した他のエンティティ・ベースのビュー・オブジェクトの作成手順と同じです。ただし、宣言SQLモードで作成するビュー・オブジェクトの場合、ビュー・リンクの作成ウィザードまたはビュー・リンク用の概要エディタで事前に定義されたビュー基準を選択すると、ビュー・リンクの「関連元SQL」ダイアログまたは「関連先SQL」ダイアログでビュー・オブジェクトの結果をさらに絞り込めます。

始める前に:

実行時におけるSQL非依存性に関する知識が役立つ場合があります。詳細は、「宣言SQLモードでのビュー・オブジェクトの使用」を参照してください。

他のビュー・オブジェクト機能を使用して追加できる機能に関する知識が役立つ場合もあります。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「宣言的SQLビュー・オブジェクトを作成する方法」の説明に従って、宣言SQLモードを有効にしてマスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトを作成します。

2. リンク元(マスター)・ビュー・オブジェクトまたはリンク先(ディテール)ビュー・オブジェクトに対して、目的のビュー基準を定義します(「表結合が適用された場合に宣言SQLベースのビュー・オブジェクトをフィルタリングする方法」を参照)。

3. 「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」の説明に従って、ビュー・リンクを作成します。

ビュー・リンクのリンク元またはリンク先をフィルタリングするには:

1. 「アプリケーション」ウィンドウで、マスター/ディテール階層を形成するために作成したビュー・リンクをダブルクリックします。

2. 概要エディタで、「問合せ」ナビゲーション・タブをクリックします。

3. 「問合せ」ページで「リンク元」または「リンク先」セクションを開き、「ビュー基準」ドロップダウン・リストから目的のビュー基準を選択します。

このビュー・オブジェクトに対するビュー基準が存在しない場合は、ドロップダウン・リストには何も表示されません。

ヒント:

概要エディタにビュー基準選択のドロップダウン・リストが表示されない場合、ビュー・リンクで選択したビュー・オブジェクトは宣言SQLモードで作成されていません。ビュー・オブジェクトを標準モードまたはカスタムSQLモードで作成している場合は、必要に応じてWHERE句を編集してデータをフィルタリングする必要があります。

5.3.4 宣言SQLモードのビュー・オブジェクトにおけるプログラム実行をサポートする方法

宣言SQLモードのビュー・オブジェクトを定義する場合、実行時に問合せが行われる属性は、通常、データバインドされたUIコンポーネントがWebページにレンダリングされる際の要件によって決まります。この実行時生成機能により、ビュー・オブジェクトを、設計時のデータベースのSQLプラットフォームに依存しないようにできます。ただし、このようなビュー・オブジェクトは、UIのADFバインディングに公開せず、プログラムによって実行が必要となる場合もあります。この場合、「すべての属性を実行時生成問合せに含めます」オプションを有効にすると、プログラムによって実行されたビュー・オブジェクトからすべてのエンティティ・オブジェクトへのアクセスを可能にできます。図5-12に、有効に設定されているグローバル・プリファレンス「すべての属性を実行時生成問合せに含めます」を示します。

図5-12 宣言SQLモードが有効になっている場合の「プリファレンス」ダイアログ

注意:

「すべての属性を実行時生成問合せに含めます」オプションは、プログラムによって実行されるビュー・オブジェクトに対してのみ使用します。この設定を有効にしたビュー・オブジェクトをデータバインドされたUIコンポーネントに公開した場合、ランタイム問合せにはすべての属性が取り込まれます。

「すべての属性を実行時生成問合せに含めます」オプションは、グローバル設定として指定することも、個々のビュー・オブジェクトに対する設定とすることもできます。この2つの設定は、次のように組み合せて使用できます。

- 作成する各ビュー・オブジェクトですべての属性がランタイム問合せ文に取り込まれるようにグローバル設定を有効にします。

- グローバル設定を有効にする一方で、プログラムにより実行されず、そのため一部の属性がランタイム問合せ文に取り込まれないビュー・オブジェクトに対しては設定を無効にします。

- グローバル設定を無効(デフォルト)にする一方で、プログラムによって実行され、そのためすべての属性がランタイム問合せ文に取り込まれるビュー・オブジェクトに対しては設定を有効にします。

5.3.4.1 宣言SQLモードのすべてのビュー・オブジェクトに対する属性問合せの強制実行

グローバル設定を有効化して宣言SQLモードのすべてのビュー・オブジェクトに属性問合せをデフォルト・モードとして強制実行することも、このオプションを無効にしたまま特定ビュー・オブジェクトの概要エディタでオプションを直接選択することもできます。

始める前に:

「すべての属性を実行時生成問合せに含めます」オプションで宣言SQLモードのビュー・オブジェクトのプログラム実行をサポートする方法に関する知識が役立つ場合があります。詳細は、「宣言SQLモードのビュー・オブジェクトにおけるプログラム実行をサポートする方法」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

グローバル設定を有効にして問合せにすべての属性が取り込まれるようにする手順:

1. メイン・メニューで、「ツール」、「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を展開し、「ビュー・オブジェクト」を選択します。

3. 「すべての属性を実行時生成問合せに含めます」を選択して、ビュー・オブジェクトの基礎となるエンティティ・オブジェクトのすべての属性が問合せに強制的に取り込まれるようにし、「OK」をクリックします。

このオプションを有効にすると、ビュー・オブジェクト定義内にフラグが設定されますが、選択したエンティティ・オブジェクトおよびエンティティ・オブジェクトの属性をビュー・オブジェクト定義に追加する必要があります。

5.3.4.2 宣言SQLモードの特定のビュー・オブジェクトに対する属性問合せの強制実行

特定のビュー・オブジェクトのすべての属性がビュー・オブジェクトの問合せに強制的に取り込まれるようにする場合は、概要エディタの「一般」ページの「チューニング」セクションでその指定ができます。すでにビュー・オブジェクトを宣言SQLモードで作成している場合、概要エディタには、「すべての属性を実行時生成問合せに含めます」オプションのみが表示されます。

始める前に:

「すべての属性を実行時生成問合せに含めます」オプションで宣言SQLモードのビュー・オブジェクトのプログラム実行をサポートする方法に関する知識が役立つ場合があります。詳細は、「宣言SQLモードのビュー・オブジェクトにおけるプログラム実行をサポートする方法」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「宣言的SQLビュー・オブジェクトを作成する方法」の説明に従って、ビュー・オブジェクトの作成ウィザードでビュー・オブジェクトを作成し、宣言SQLモードを有効にしたことを確認してください。

ビュー・オブジェクト固有の設定によってすべての属性が問合せに取り込まれるようにする手順:

1. 「アプリケーション」ウィンドウで、宣言的SQLビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

ビュー・オブジェクトが宣言SQLモードで作成されているかどうかは、概要エディタで確認できます。概要エディタで「問合せ」ナビゲーション・タブをクリックし、「問合せ」ページで、「モード」ドロップダウン・リストに「宣言」が選択されていることを確認します。

3. 「一般」ページで、「チューニング」 セクションを展開し、「すべての属性を実行時生成問合せに含めます」を選択します。

このオプションを有効にすると、ビュー・オブジェクトの基礎となるエンティティ・オブジェクトのすべての属性が問合せに強制的に取り込まれます。このオプションを有効にすると、ビュー・オブジェクト定義内にフラグが設定されますが、選択したエンティティ・オブジェクトおよびエンティティ・オブジェクトの属性をビュー・オブジェクト定義に追加する必要があります。

5.3.5 宣言SQLモードでビュー・オブジェクトを作成するときに行われる処理

宣言SQLモードでビュー・オブジェクトを作成する場合、SelectListFlags、FromListFlagsおよびWhereFlagsの3つのプロパティがビュー・オブジェクトのメタデータに追加されます。宣言SQLモードに含まれないプロパティは、標準モードのビュー・オブジェクトのプロパティSelectList、FromListおよびWhere(または、カスタムSQLモードの場合はSQLQuery要素)で、これらには実際のSQL文が指定されます。次の例は、宣言SQLモードで有効にされるビュー・オブジェクトのメタデータの3つのフラグを示したもので、これによりSQLは、ビュー・オブジェクト定義内のメタデータとして指定されるのではなく、実行時に生成されます。

<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="CustomerCardStatus"
SelectListFlags="1"
FromListFlags="1"
WhereFlags="1"
...

標準モードまたはカスタムSQLモードで作成するビュー・オブジェクトと同様、このビュー・オブジェクトのメタデータには、「ビュー・オブジェクトの作成」ウィザードの「属性」ページで選択した各属性に対するViewAttribute要素も含まれます。ただし、宣言SQLモードでは、ウィザードで属性を選択する場合(または概要エディタで属性を追加する場合)、設計時にはFROMリストまたはSELECTリストを作成しません。ビュー・オブジェクトのメタデータに含まれる属性定義では、実行時に生成される文に取り込まれる可能性のあるエンティティおよび属性のリストのみが決定されます。このようなADFビジネス・コンポーネントでのSQLリストの生成の詳細は、「実行時に行われる処理: 宣言SQLモードでのSQL」を参照してください。

次の例は、オプションの宣言WHERE句(DeclarativeWhereClause要素)およびオプションの宣言ORDERBY句(SortCriteria要素)を含む宣言SQLモードのビュー・オブジェクトの追加機能を示しています。

<DeclarativeWhereClause>
<ViewCriteria
Name="CustomerStatusWhereCriteria"
ViewObjectName="oracle.summit.model.views.CustomerCardStatus"
Conjunction="AND"
Mode="3"
AppliedIfJoinSatisfied="false">
<ViewCriteriaRow
Name="vcrow60">
<ViewCriteriaItem
Name="CardTypeCode"
ViewAttribute="CardTypeCode"
Operator="STARTSWITH"
Conjunction="AND"
Required="Optional">
<ViewCriteriaItemValue
Value=":cardtype"
IsBindVarValue="true"/>
</ViewCriteriaItem>
</ViewCriteriaRow>
</ViewCriteria>
</DeclarativeWhereClause>
<SortCriteria>
<Sort
Attribute="CustomerId"/>
<Sort
Attribute="CardTypeCode"/>
</SortCriteria>

5.3.6 実行時に行われる処理: 宣言SQLモードでのSQL

実行時に宣言SQLモードの問合せが生成されると、メタデータのViewCriteria要素およびSortCriteria要素から定義されている属性が、ADFビジネス・コンポーネントによって特定されます。次に、これらの属性を使用してWHERE句およびORDER BY句が生成されます。次に、メタデータのViewAttribute要素によって定義されたエンティティ・オブジェクトの慣用名に対応する表に基づいて、ランタイムによりFROMリストが生成されます。最後に、エンド・ユーザーがUIを使用してどの属性を選択したかに基づいて、ランタイムによりSELECT文が作成されます。このように、宣言SQLモードのビュー・オブジェクトにより、実行時にすべてのSQL句が完全な形で生成されます。実行時に生成されるSQL文は、プロジェクト・プロパティの設定に含まれるSQLプラットフォームに基づいています。現在、ランタイムでサポートされているSQLスタイルは、SQL92 (ANSI)およびOracleスタイルのプラットフォームです。

5.3.7 宣言SQLモードでのビュー・オブジェクトのプログラムによる処理に関する必知事項

開発者の便宜を考慮して、個々の属性の選択および選択解除は、ビュー・オブジェクト実装のAPIを介してプログラムにより実行できるようになっています。このAPIは、宣言SQLモードで作成してプログラムにより実行するビュー・オブジェクトと組み合せると有用な場合があります。次の例は、SQLモードを有効にして構成済の属性に属性のサブセットを追加する場合に、ビュー・オブジェクトでselectAttributeDefs()をコールする方法を示しています。

ApplicationModule am = Configuration.createRootApplicationModule(amDef, config);
ViewObjectImpl vo = (ViewObjectImpl) am.findViewObject("CustomerVO");
vo.resetSelectedAttributeDefs(false);
vo.selectAttributeDefs(new String[] {"FirstName, "LastName"});
vo.executeQuery();

selectAttributeDefs()をコールすると、配列内の属性がViewObjectImplのプライベート・メンバー変数に追加されます。プライベート・メンバー変数の属性は、executeQuery()をコールすると実際の選択リストに転送されます。これらのViewObjectImpl属性コールはクライアント・レイヤーには適用されず、中間層のビュー・オブジェクトのImplクラス内でしかアクセスできないことを理解しおくことが重要です。

また、「すべての属性を実行時生成問合せに含めます」 オプションを有効にした後、一部の属性のサブセットの選択を解除する場合は、ビュー・オブジェクト上でunselectAttributeDefs()をコールします。または、「すべての属性を実行時生成問合せに含めます」 オプションを無効にした後、一部の属性のサブセットを選択する場合は、ビュー・オブジェクト上でselectAttributeDefs()をコールします。

注意:

「すべての属性を実行時生成問合せに含めます」オプションの値以外に使用される値はないため、このAPIで実行される宣言SQLモードのビュー・オブジェクトは、UIに対して公開しないように注意してください。

5.4 静的データが移入されたビュー・オブジェクトの作成

ADFビジネス・コンポーネントでは、設計時に移入した行を使用して、各自のデータ・モデル・プロジェクトでビュー・オブジェクトを作成できます。通常、保持するデータ量が少なく、それらのデータを変更する頻度が低いと予想される場合は、静的データ・ビュー・オブジェクトを作成します。データベースの参照表を使用するか、ハードコードされた値のリストに基づいて静的データ・ビュー・オブジェクトを使用するかは、データのサイズおよび性質に基づいて決定します。リストのエントリ数が100未満の場合は、静的データ・ビュー・オブジェクトの方が便利です。行が相当数ある場合は、従来の表ベースのビュー・オブジェクトを使用してデータベースから読み取る必要があります。静的データ・ビュー・オブジェクトには、属性値がリソース・バンドルに格納されているので簡単に変換できるという利点があります。ただし、静的データ・ビュー・オブジェクトの行はすべて一括で取得されるため、使用するエントリ数が100未満であれば最適なパフォーマンスが得られます。

ベスト・プラクティス

データ量が少ない静的データのリストにアクセスするためにビュー・オブジェクトを作成する必要がある場合は、データベースに問い合せるよりも静的データ・ビュー・オブジェクトを使用することをお薦めします。静的データ・ビュー・オブジェクトは、データの行数が100を超えないリストで使用することが理想的です。「ビュー・オブジェクトの作成」ウィザードでは、データはリソース・メッセージ・ファイルに保存されるため、これらのデータの変換は簡単です。

データベースに対する問合せによって値のリストを取得することが適切でない場合は、静的データ・ビュー・オブジェクトをLOVデータソースとして使用できます。たとえば、注文に対して未処理、処理済、保留中というステータスがあるとします。これらの値を使用して静的データ・ビュー・オブジェクトを作成し、その静的データ・ビュー・オブジェクトのステータス属性に基づいてLOVを定義できます。ウィザードではステータス・ビュー・オブジェクトの値が変換可能なリソース・ファイルに格納されるため、アプリケーションの現在のロケールに対応したリソース・ファイルを使用して、UIにステータス値が表示されます。

5.4.1 入力したデータを使用して性的データ・ビュー・オブジェクトを作成する方法

静的データ・ビュー・オブジェクトの作成には、「ビュー・オブジェクトの作成」ウィザードを使用します。このウィザードでは、目的の属性(列)を定義し、必要な数の行を入力できます。このウィザードには、作成したとおりに静的データ表が表示されます。

注意:

静的データ・ビュー・オブジェクトは、その中のデータがデータベース表からのものではないため、読取り専用です。

「ビュー・オブジェクトの作成」ウィザードでは、スプレッドシート・ファイルなどのカンマ区切り(CSV)ファイル形式のデータに基づいて属性を作成することもできます。

始める前に:

静的データ・ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「静的データが移入されたビュー・オブジェクトの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

静的データ・ビュー・オブジェクトの属性を手動で作成するには:

1. 「アプリケーション」ウィンドウで、静的データ・ビュー・オブジェクトを作成するデータ・モデル・プロジェクトのパッケージを右クリックし、「新規」、「ビュー・オブジェクト」の順に選択します。

2. 「ビュー・オブジェクトの作成」ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。「静的リスト」を選択し、このビュー・オブジェクトに対して静的データが取り込まれるよう指定します。「次へ」をクリックします。

3. 「属性」ページで、「新規」をクリックし、静的リスト表の列に対応する属性を追加します。「新規ビュー・オブジェクト属性」ダイアログで、名前を入力して属性タイプを選択します。「OK」をクリックしてウィザードに戻り、「次へ」をクリックします。

4. 「属性の設定」ページでは、何も行わず「次へ」をクリックします。

5. 「静的リスト」ページで、「追加」ボタンをクリックし、ウィザード・ページにデータを直接入力します。定義した属性は、静的データ表の列として表示されます。

6. 「アプリケーション・モジュール」ページでは、何も行わず「次へ」をクリックします。

7. 「サマリー」ページで「終了」をクリックします。

5.4.2 インポートしたデータを使用して性的データ・ビュー・オブジェクトを作成する方法

「ビュー・オブジェクトの作成」ウィザードの「インポート」機能を使用すると、スプレッドシート・ファイルなどのカンマ区切り(CSV)ファイル形式のデータに基づく属性によって、静的データ・ビュー・オブジェクトを作成できます。このウィザードでは、属性の識別にはCSVフラット・ファイルの先頭行が使用され、それぞれの属性のデータに対してはCSVファイルの後続行が使用されます。たとえば、アプリケーションで国際通貨を表示する必要がある場合は、図5-13のように、最初の行にSymbol、Country、Descriptionの列を定義し、行を追加して各通貨タイプのデータを定義します。

図5-13 CSVフラット・ファイルからインポートして用意したサンプル・データ

始める前に:

静的データ・ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「静的データが移入されたビュー・オブジェクトの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

フラット・ファイルに基づいて静的データ・ビュー・オブジェクトの属性を作成するには:

1. 「アプリケーション」ウィンドウで、静的データ・ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」、「ビュー・オブジェクト」の順に選択します。

2. 「ビュー・オブジェクトの作成」ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。「静的リスト」を選択し、このビュー・オブジェクトに対して静的データが取り込まれるよう指定します。「次へ」をクリックします。

3. CSVフラット・ファイルの最初の行に列名が定義されていない場合は、「属性」ページの「新規」をクリックし、静的データ表の列名に対応する属性を追加します。「新規ビュー・オブジェクト属性」ダイアログで、名前を入力して属性タイプを選択します。「OK」をクリックしてウィザードに戻り、「次へ」をクリックします。

追加する各属性は、フラット・ファイルで定義されたデータ列の順序と一致している必要があります。作成する属性の数が列数より少ない場合、余分な列はインポート中に無視されます。逆に、作成する属性の数が列数より多い場合は、余分な属性に値NULLが定義されます。

4. 「属性の設定」ページでは、何も行わず「次へ」をクリックします。

5. 「静的リスト」ページで、「インポート」をクリックし、ウィザードにデータを表示します。データを確認し、必要に応じて編集します。

属性名を自分で作成した場合、CSVファイルの最初の行に列名が表示されていると、列名がウィザードにデータとして表示されるため、削除する必要があります。属性値を編集するには、値フィールドをダブルクリックします。

6. 必要に応じて、「追加」ボタンまたは「削除」ボタンをクリックし、データの行数を変更します。「次へ」をクリックします。

新しい行の属性値を入力するには、値フィールドをダブルクリックします。

7. 「アプリケーション・モジュール」ページでは、何も行わず「次へ」をクリックします。

8. 「サマリー」ページで「終了」をクリックします。

5.4.3 静的データ・ビュー・オブジェクトの作成時の処理

静的データ・ビュー・オブジェクトを作成すると、ウィザードで定義したデータの行がビュー・オブジェクトの概要エディタに表示されます。エディタを使用すると、図5-14に示すように追加データを定義できます。

図5-14 「静的値」ページでのデータの表示

静的データ・ビュー・オブジェクトの生成済XML定義には、データの列ごとに一時属性が1つずつ格納されます。たとえば、国際通貨のデータが格納されたCSVファイルをインポートすると、静的データ・ビュー・オブジェクトには、次の例のように、Symbol、CountryおよびDescriptionの一時属性が格納されます。

<ViewObject
...
<!-- Transient attribute for first column -->
<ViewAttribute
Name="Symbol"
IsUpdateable="false"
IsSelected="false"
IsPersistent="false"
PrecisionRule="true"
Precision="255"
Type="java.lang.String"
ColumnType="VARCHAR2"
AliasName="Symbol"
SQLType="VARCHAR"/>
<!-- Transient attribute for second column -->
<ViewAttribute
Name="Country"
IsUpdateable="false"
IsPersistent="false"
PrecisionRule="true"
Precision="255"
Type="java.lang.String"
ColumnType="VARCHAR"
AliasName="Country"
SQLType="VARCHAR"/>
<!-- Transient attribute for third column -->
<ViewAttribute
Name="Description"
IsUpdateable="false"
IsPersistent="false"
PrecisionRule="true"
Precision="255"
Type="java.lang.String"
ColumnType="VARCHAR"
AliasName="Description"
SQLType="VARCHAR"/>
<StaticList
Rows="4"
Columns="3"/>
<!-- Reference to file that contains static data -->
<ResourceBundle>
<PropertiesBundle
PropertiesFile="model.ModelBundle"/>
</ResourceBundle>
</ViewObject>

データは静的であるため、概要エディタには「問合せ」ページは表示されず、静的データ・ビュー・オブジェクトの生成済XML定義に問合せ文は含まれません。かわりに、XML定義の<ResourceBundle>要素がリソース・バンドル・ファイルを参照します。次の例では、ファイルの参照がPropertiesFile="model.ModelBundle"として示されています。リソース・バンドル・ファイルには、データの行が記述されるため、データのローカライズも可能です。デフォルトのリソース・バンドル・タイプが使用されている場合は、次の例のように、データ・モデル・プロジェクトにModelBundle.propertiesファイルが表示されます。

model.ViewObj.SL_0_0=USD
model.ViewObj.SL_0_1=United States of America
model.ViewObj.SL_0_2=Dollars
model.ViewObj.SL_1_0=CNY
model.ViewObj.SL_1_1=P.R. China
model.ViewObj.SL_1_2=Yuan Renminbi
model.ViewObj.SL_2_0=EUR
model.ViewObj.SL_2_1=Europe
model.ViewObj.SL_2_2=Euro
model.ViewObj.SL_3_0=JPY
model.ViewObj.SL_3_1=Japan
model.ViewObj.SL_3_2=Yen

5.4.4 静的データ・ビュー・オブジェクトを編集する方法

静的リスト表に対して変更を加える必要がある場合は、「アプリケーション」ウィンドウでビュー・オブジェクトをダブルクリックし、そのビュー・オブジェクトの概要エディタを開きます。この概要エディタを使用すると、属性(静的リスト表の列)の追加および削除、行(静的リスト表のデータ)の追加または削除、個別行のソート、個々の属性値の変更を実行できます。またこのエディタでは、ビュー・オブジェクト定義ファイルが更新され、変更された属性値がメッセージ・バンドル・ファイルに保存されます。メッセージ・バンドルのローカライズの詳細は、「リソース・バンドルの使用」を参照してください。

5.4.5 静的データ・ビュー・オブジェクトに関する必知事項

アプリケーション・モジュールのデータ・モデルにおける静的データ・ビュー・オブジェクトの用途は限定されています。エンティティ・ベースのビュー・オブジェクトとは異なり、静的データ・ビュー・オブジェクトは更新できません。静的データ・ビュー・オブジェクトは、エンド・ユーザーに対して読取り専用データを表示する必要があり、データベース表の作成が必要になるほど静的リスト表に含まれるデータ量が多くはない場合に使用します。

5.5 ビュー・オブジェクトへの計算属性および一時属性の追加

ビュー・オブジェクトには、基礎となるエンティティ・オブジェクトにマップされた属性以外にも、エンティティ・オブジェクトの属性値にマップされない計算属性を組み込むこともできます。計算属性としては、次の2種類があります。

- SQL計算属性(値がSQL問合せのSELECTリスト内の式として取得される場合)

- 一時属性(値が問合せの一部として取得されない場合)

ビュー・オブジェクトには、エンティティ・オブジェクト・レベルではそれ自体が一時属性である、エンティティにマップされた属性を組み込むことができます。

5.5.1 SQL計算属性の追加方法

SQL計算属性を追加するには、ビュー・オブジェクトの概要エディタを使用します。

始める前に:

計算属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

SQL計算属性をビュー・オブジェクトに追加するには:

1. 「アプリケーション」ウィンドウで、SQL計算属性を定義するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規属性の作成」ボタンをクリックします。

3. 「新規ビュー・オブジェクト属性」ダイアログで、属性の名前を入力します。

4. 概要エディタの「属性」ページで、新しい属性を選択します。

5. 「詳細」タブをクリックし、Javaタイプを適切な値に設定します。

たとえば、名前と姓を連結する計算属性の型は、図5-15に示すようにString型になります。

6. 「デフォルト値」セクションで「SQL」を選択し、式フィールドにSQL式を指定します。

たとえば、名前と姓の順序を変更するには、図5-15に示すように、LAST_NAME||', '||FIRST_NAMEと式を記述します。

図5-15 新しいのSQL計算属性

7. 属性名と一致するようにSQL列の別名を変更するかどうかを検討します。

8. データベースの問合せ列の型を確認し、必要に応じて長さ(または精度/スケール)を調整します。

5.5.2 SQL計算属性を追加するときに行われる処理

ビュー・オブジェクトの概要エディタでSQL計算属性を追加すると、ビュー・オブジェクトのXMLドキュメントが更新され、新しい属性が反映されます。エンティティにマップされた属性の<ViewAttribute>タグは、次の例に示すサンプルのようになります。エンティティにマップされた属性のプロパティの大部分は、基礎となるエンティティの属性からマップ先に継承されます。

<ViewAttribute
Name="LastName"
IsNotNull="true"
EntityAttrName="LastName"
EntityUsage="EmpEO"
AliasName="LAST_NAME" >
</ViewAttribute>

これに対し、SQL計算属性の<ViewAttribute>タグは、次の例に示すサンプルのようになります。想定どおり、このタグにはEntityUsageまたはEntityAttrNameプロパティはなく、次のようにデータ型情報とともにSQL式が含まれます。

<ViewAttribute
Name="LastCommaFirst"
IsUpdatable="false"
IsPersistent="false"
PrecisionRule="true"
Type="java.lang.String"
ColumnType="VARCHAR2"
AliasName="FULL_NAME"
SQLType="VARCHAR" >
Precision="62"
Expression="LAST_NAME||', '||FIRST_NAME">
</ViewAttribute>

5.5.3 SQL計算属性に関する必知事項

ビュー・オブジェクトには、実行時に問合せのSELECTリストにSQL計算属性のSQL式が含まれます。この式はデータベースが評価し、結果を問合せ内のその列の値として戻します。この値は、問合せを実行するたびに再評価されます。

5.5.4 一時属性の追加方法

一時属性は通常、データベースに格納されない小計などの計算式を使用可能にする場合に使用されます。

始める前に:

一時属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

定義する一時属性は、Groovy式言語を使用して評価できます。Groovyを使用すると、式や変数を文字列に挿入できます。この式は、ビュー・オブジェクト定義の一部として保存されます。詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。

一時属性を使用する場合の制限を理解しておく必要があります。詳細は、「一時属性によって定義された主キーによるビュー・オブジェクト問合せに関する必知事項」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

一時属性をビュー・オブジェクトに追加するには:

1. 「アプリケーション」ウィンドウで、一時属性を定義するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規属性の作成」ボタンをクリックします。

3. 「新規ビュー・オブジェクト属性」ダイアログで、属性の名前を入力し、「タイプ」ドロップダウンからJava属性タイプを選択し、「OK」をクリックします。

4. 概要エディタの「属性」ページで、「詳細」タブをクリックし、「一時」オプションを選択します。

5. 一時属性のデフォルト値が式で計算される場合は、「デフォルト値」の下の「式」チェック・ボックスを選択し、横にあるアイコンをクリックして「式エディタの編集」ダイアログを開きます。

6. 「式エディタの編集」ダイアログで、属性のデフォルト値を計算するデフォルト値式を入力します。
一時属性の式では、ビュー・オブジェクトで定義された永続的属性から値を導出できます。エンティティ属性を参照する必要がある場合は、その属性をビュー・オブジェクト定義に追加しておく必要があります。

図5-16 式エディタの編集

7. この属性が依存する属性を指定します。これらの属性を使用可能から選択済に移動します。

8. 「OK」をクリックして、「式エディタの編集」ダイアログに入力した式を保存します。

9. 必要に応じて、式の再計算をいつ実行するかの条件を「式値のリフレッシュ」フィールドで指定できます。再計算式を定義する手順は、デフォルト値式を定義するのと同じです。再計算式がtrueに評価された場合、デフォルト値式の再計算が行われます。
たとえば、次の式値のリフレッシュGroovy式は、Country属性またはRegionId属性が変更されたときに属性が再計算されます。

return (adf.object.isAttributeChanged("Country") || adf.object.isAttributeChanged("RegionId"));

注意:
定義した値式またはオプションの再計算式がベース・エンティティ・オブジェクトの属性を参照する場合は、「式エディタの編集」ダイアログでこれを依存性として定義する必要があります。「使用可能」リストでそれぞれの属性を特定し、それを「選択済」リストに移動します。

5.5.5 エンティティ・オブジェクトによって定義された一時属性を追加する方法

ビュー・オブジェクトには、エンティティ・オブジェクト・レベルではそれ自体が一時属性である、エンティティにマップされた属性を組み込むことができます。

始める前に:

一時属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

エンティティ・ベースのビュー・オブジェクトにエンティティ・オブジェクトの一時属性を追加するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトの慣用名に基づいて一時属性を追加するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規属性の作成」ボタンをクリックして「エンティティからの属性の追加」を選択し、エンティティから導出された利用可能な属性のリストを表示します。

3. 「属性」ダイアログで、目的の一時属性を「使用可能」リストから「選択済」リストに移動します。

4. 「OK」をクリックします。

5.5.6 一時属性への検証規則の追加方法

特定のビュー・オブジェクト一時属性に対する属性レベルの検証規則は、エンド・ユーザーまたはプログラム・コードによる属性値の変更が試行されるとトリガーされます。属性を設定する順序は指定できないため、属性レベルの検証規則は、規則の成否がその属性の候補値のみに依存する場合にのみ使用する必要があります。

ビュー・オブジェクト一時属性に検証規則を追加する手順は、宣言的検証規則の作成方法と同じで、「検証ルールの追加」ダイアログを使用します。このダイアログを開くには、ビュー・オブジェクトの概要エディタで、「属性」ページの「検証ルール」セクションの「検証ルールの追加」ボタンをクリックします。まず、属性リストから一時属性を選択し、一時属性を更新可能として定義する必要があります。検証規則は、読取り専用の一時属性で定義できません。

始める前に:

属性UIヒントの知識があると役立ちます。詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

また、異なるタイプの定義可能な検証規則を理解していると役立ちます。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

一時属性に検証規則を追加するには:

1. 「アプリケーション」ウィンドウで、目的のビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、一時属性を選択してから「詳細」タブをクリックし、「更新可能」で「常に」が表示されていることを確認します。

一時属性の検証規則は更新可能にする必要があります。「なし」値により、読取り専用属性を指定します。

4. 「属性」ページで、「検証ルール」タブをクリックし、「検証ルールの追加」アイコンをクリックします。

5. 「検証ルールの追加」ダイアログで、「タイプ」ドロップダウン・リストから、目的の検証ルールのタイプを選択します。

6. 「ルール定義」タブで、ダイアログの設定を使用して新しいルールを構成します。

このコントロールの内容は、選択する検証規則の種類によって異なります。様々な検証ルールの詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

7. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、「検証エラー・メッセージの作成」を参照してください。

8. 「OK」をクリックします。

5.5.7 一時属性の追加時の処理

ビュー・オブジェクトの概要エディタで一時属性を追加すると、ビュー・オブジェクトのXMLドキュメントが更新され、新しい属性が反映されます。XMLでは、一時属性の<ViewAttribute>タグは、SQL計算属性の場合と類似していますが、Expressionプロパティがありません。

一時属性がGroovy式に準拠している場合は、適切な属性内に<TransientExpression>タグが作成されます。次の例は、Groovy式のXMLコードを示しています。Groovy式がOrdVOビュー・オブジェクトのSalesRepName属性に追加されています。このXML定義は、このGroovy式スクリプトが含まれている.bcsファイルがこのXML定義の一部であることを示しています(CodeSourceName=”OrdVORow”)。そのため、.bcsのファイル名はOrdVORow.bcsです。operations.xmlファイルもあり、この例ではOrdVOOperations.xmlという名前です。このoperations.xmlファイルには.bcsファイルを指し示すURIが含まれています。

<ViewAttribute
Name="SalesRepName"
IsUpdateable="false"
IsSelected="false"
IsPersistent="false"
PrecisionRule="true"
Type="java.lang.String"
ColumnType="CHAR"
AliasName="VIEW_ATTR"
SQLType="VARCHAR">
<TransientExpression
Name="ExpressionScript"
trustMode="untrusted"
CodeSourceName="OrdVORow"/>
</ViewAttribute>

5.5.8 一時属性と計算値に関する必知事項

一時属性は、データ値のプレースホルダです。一時属性の「更新可能」プロパティを「常に」に変更すると、エンド・ユーザーは属性値を入力できるようになります。一時属性に計算値を表示する場合は、通常、「更新可能」プロパティを「なし」に設定し、ビュー・オブジェクトの概要エディタの「属性」ページにGroovy言語式を記述します。

また、一時属性を計算するためのJavaコードを記述する場合は、ビュー・オブジェクトの概要エディタにある「Java」ページの「編集」アイコンをクリックして開く「Java」ダイアログで、カスタム・ビュー行クラスを有効にし、アクセッサ・メソッドの生成を選択する必要があります。次に、一時属性のアクセッサ・メソッドの内部で、計算済値を戻すJavaコードを記述します。次の例に示すCustomerVORowImpl.javaビュー行クラスには、getFirstDotLast()メソッドの計算値を戻すJavaコードが含まれています。

// In CustomerVORowImpl.java
public String getFirstDotLast() {
// Commented out this original line since we're not storing the value
// return (String) getAttributeInternal(FIRSTDOTLAST);
return getFirstName().substring(0,1)+". "+getLastName();
}

5.5.9 一時属性によって定義された主キーによるビュー・オブジェクト問合せに関する必知事項

一般に、一時属性ではアクセスのたびに主キー属性の再評価が強制されるため、一時属性による主キーの定義が適していないユースケースもあります。特に、複数の問合せが生成される可能性のあるADF Facesコンポーネント(ADFツリー・コンポーネントなど)にバインドされるビュー・オブジェクトでは、一時属性を使用した主キーの定義は避けることをお薦めします。このような状況では、主キーである一時属性の再評価が必要となるため、アプリケーションのパフォーマンスが低下します。

また、プログラムによるビュー・オブジェクトの問合せで主キーが一時属性に依存する場合、ユーザーがビュー・オブジェクトのキャッシュ行の外にUIをスクロールすると、NULLポインタ例外を受け取る可能性があることにも注意してください。この場合、ビュー・オブジェクト問合せがデータベース表から生成されないため、ビュー・オブジェクト実装は、ViewObjectImplクラスのretrieveByKey()メソッドをオーバーライドし、行を返す(または、行がない場合には空の配列を返す)必要があります。

このメソッドをオーバーライドすると、ADFビジネス・コンポーネントでfindByKey()を実行し、キャッシュからリクエストされた行を最初に検索できます。(主キーが一時属性であるために)これに失敗した場合、ADFビジネス・コンポーネントは、retrieveByKey()オーバーライドを実行し、入力されるキーと一致する行を取得するように定義した操作を実行します。このメソッドのデフォルトの実装は、データベース問合せを発行し、データベースから行を取得しようとします。

protected Row[] retrieveByKey(ViewRowSetImpl rs, Key key,
int maxNumOfRows, boolean skipWhere)

このメソッドには次の引数があります。

maxNumOfRowsは、findByKey()の呼出しに渡したmaxNumOfRowsです。これは、1 .. nまたは-1です。nは、渡されたキーと一致するキーを持つ行をn行検索していることを意味します。-1はすべての行が一致することを意味します。キーが部分キーでビュー・オブジェクトが複数のエンティティ・オブジェクトに基づいている場合、ビュー・オブジェクトの複数の行がキーと一致する可能性があります。

skipWhereは、findByKey()が基本ビュー・オブジェクトとして同じWHERE句を適用する必要があるかどうかを制御します。基本ビュー・オブジェクトにWHERE句DEPTNO = 10があり、skipWhereがfalseの場合、バッキング・ストアから行を検索しているときに同じWHERE句を適用することを想定されます。skipWhereがtrueの場合、基本ビュー・オブジェクトからのWHERE句は関係ありません。

5.6 有効日付範囲を使用したビュー・オブジェクト行の制限

特定の日付範囲を通してデータの問合せを行う必要があるアプリケーションでは、有効日が指定された行セットを生成できます。有効日が指定されたビュー・オブジェクトを定義するには、有効日が指定されたエンティティ・オブジェクトに基づくエンティティ・ベースのビュー・オブジェクトを作成する必要があります。ビュー・オブジェクトの有効日をどのように使用するかについては、設計時にビュー・オブジェクトに関するメタデータを使用してユーザーが制御できます。実行時には、ADFビジネス・コンポーネントにより、有効日に基づいてビュー行を制限するための問合せフィルタが生成されます。

5.6.1 有効日が指定されたビュー・オブジェクトの作成方法

有効日に関する問合せフィルタが生成されるかどうかは、ビュー・オブジェクトの「プロパティ」ウィンドウに表示される「有効日指定」プロパティの値によって決まります(このプロパティを表示するには、ビュー・オブジェクトの概要エディタの「一般」タブをクリックして、「プロパティ」ウィンドウの「名前」セクションを開きます)。

ビュー・オブジェクトの概要エディタでは、WHERE句に含まれる有効日指定の問合せ句は表示されません。「問合せのテスト」ダイアログを使用すると、この句を表示できます。有効日の問合せフィルタは通常、次のようになります。

(:Bind_SysEffectiveDate BETWEEN CustomerVO.EFFECTIVE_START_DATE AND CustomerVO.EFFECTIVE_END_DATE)

実行時に、問合せに対するバインド値がルート・アプリケーション・モジュールのプロパティから取得されるか、バインド値をビュー・オブジェクトに直接割り当てることができます。トランザクションに対して有効日を設定する場合は、次のようなコード・スニペットを使用します。

am.setProperty(ApplicationModule.EFF_DT_PROPERTY_STR, new Date("2008-10-01));

アプリケーション・モジュール上でEFF_DT_PROPERTY_STRを設定しない場合、問合せフィルタでは現在の日付が使用され、ビュー・オブジェクトからは現在の日付でフィルタリングされた有効な行が戻されます。

ビュー・オブジェクトには、ビュー行に対する有効日の設定に使用できるSysEffectiveDateという独自の一時属性があります。この一時属性は、有効日を指定できるようにビュー・オブジェクトを設定すると、ビュー・オブジェクト内に生成されます。有効日を設定しない場合、新規行およびデフォルト行に対するSysEffectiveDate属性の値は、アプリケーション・モジュールから導出されます。ADFビジネス・コンポーネントでは、DML操作中にのみビュー行からエンティティ・オブジェクトに有効日が伝播されます。

始める前に:

有効日が指定された行セットに関する知識が役立つ場合があります。詳細は、「有効日付範囲を使用したビュー・オブジェクト行の制限」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「特定の時点に関するデータを格納する方法」の説明に従い、有効日が指定されたエンティティ・オブジェクトを作成します。

2. 「エンティティ・ベースのビュー・オブジェクトの作成方法」の説明に従い、ビュー・オブジェクトの作成ウィザードを使用して、エンティティ・ベースのビュー・オブジェクトを作成します。
作成するビュー・オブジェクトは、作成済の有効日が指定されたエンティティ・オブジェクトに基づいている必要があります。ウィザードの「属性」ページで、エンティティ・オブジェクトの開始日と終了日を指定した有効日指定の属性を、ビュー・オブジェクトの「選択されたもの」リストに追加してください。

SysEffectiveDate属性を使用してビュー・オブジェクトに有効日を設定するには:

1. 「アプリケーション」ウィンドウで、有効日が指定されたエンティティ・オブジェクトに基づいて作成したビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

3. 「プロパティ」ウィンドウで「名前」セクションを開き、「有効日指定」ドロップダウン・メニューに「True」と表示されていることを確認します。

「プロパティ」ウィンドウに「名前」セクションが表示されない場合は、概要エディタの「一般」ナビゲーション・タブをクリックし、適切なフォーカスを設定します。

4. 図5-17に示すように、概要エディタで「属性」ナビゲーション・タブをクリックしてから、開始日の属性を選択し、「詳細」タブをクリックしてから、「有効日」が有効で「開始」が選択されていることを確認します。

図に示すように、終了日の属性も正しく選択されていることを確認します。ビュー・オブジェクトで編集不可であることを示すため、これらのフィールドはグレー表示されています。

図5-17 ビュー・オブジェクトの概要エディタに表示される有効日設定

有効日が指定されたエンティティ・オブジェクトから、必要な属性がビュー・オブジェクトに継承されていることを確認したら、追加の手順は必要ありません。

5.6.2 有効日が指定されたビュー・オブジェクトを使用した新規ビュー行の作成方法

有効日が指定された行は、通常のビュー行と同じように作成(挿入)できます。開始日および終了日は次のように指定できます。

- ユーザーがアプリケーション・モジュールで有効日を指定します。開始日はこの有効日に設定され、終了日は指定可能な最後の日付に設定されます。
ADFビジネス・コンポーネントでは、指定可能な最後の日付は4712年12月31日と定義されています。

- ユーザーが開始日および終了日のそれぞれの値を指定します(詳細設定)。

どちらの場合も、エンティティの検証中には、新規行によってギャップや重複が生じないようにチェックが実行されます。またポスト時には、ADFビジネス・コンポーネントにより、行の挿入時にギャップや重複が生じないよう、直前の行に対してロックが取得されます。

5.6.3 有効日が指定されたビュー行の更新方法

有効日が指定された行は、有効日が指定されていない行と同様に、Row.setAttribute()コールを使用して更新されます。ただし、目的の操作を有効にするためには、更新の前に、行に有効日のモードを設定しておく必要があります。ADFビジネス・コンポーネントでは、行の更新を開始するための様々なモードがサポートされています。

更新モードを設定するには、oracle.jbo.Rowクラスで定義された次のいずれかのモード定数を指定して、Row.setEffectiveDateMode(int mode)メソッドをコールします。

- CORRECTION (修正モード)
有効開始日および有効終了日は変更されません。それ以外の属性値は変更される場合があります。これは行の更新に関する標準の動作です。

- UPDATE (更新モード)
最新行の有効終了日が有効日として設定されます。この行では、ユーザーにより変更された行の値がすべて元に戻されます。また、変更された値のある行が新たに作成されます。新規行の有効開始日は有効日の翌日に設定され、有効終了日は指定可能な最後の日付に設定されます。新規行は、トランザクションがデータベースにポストされた後に表示されます。

- OVERRIDE(更新オーバーライド・モード)
変更された行の有効終了日が有効日として設定されます。次の行の有効開始日は有効日の翌日に設定され、次の行の有効終了日は指定可能な最後の日付に設定されます。

- CHANGE_INSERT(変更挿入モード)
更新モードと似ていますが、変更挿入モードは、最新行ではなく過去の行に対する操作です。変更された行の有効終了日が有効日として設定されます。この行では、ユーザーにより変更された行の値がすべて元に戻されます。また、変更された値を持つ行が新たに作成されます。新規行の有効開始日は有効日の翌日に設定され、有効終了日は次の行の有効開始日の前日に設定されます。新規行は、トランザクションがデータベースにポストされた後に表示されます。

5.6.4 有効日が指定されたビュー行の削除方法

ADFビジネス・コンポーネントでは、行の削除を開始するための様々なモードがサポートされています。RowSet.removeCurrentRow()やRow.remove()などのAPIコールを使用することにより、削除するビュー行をマークできます。

削除モードを設定するには、oracle.jbo.Rowクラスで定義された次のいずれかのモード定数を指定して、Row.setEffectiveDateMode(int mode)メソッドを起動します。

- DELETE (削除モード)
行の有効終了日が有効日として設定されます。この行に対する操作は、削除から更新に変更されます。有効日でないキー値が同じであり、有効開始日が有効日より後になっている行はすべて削除されます。

- NEXT_CHANGE(次の変更を削除するモード)
行の有効終了日が、有効日でないキー値が同じである次の行の有効終了日に設定されます。この行に対する操作は、削除から更新に変更されます。削除されるのは次の行です。

- FUTURE_CHANGE(将来の変更を削除するモード)
行の有効終了日が指定可能な最後の日付に設定されます。この行に対する操作は、削除から更新に変更されます。有効日でないキー値が同じである将来の行はすべて削除されます。

- ZAP (ZAPモード)
有効日でないキー値が同じである行がすべて削除されます。

有効日のモード定数は行インタフェースでも定義されます。

5.6.5 有効日が指定されたビュー・オブジェクトの作成時の処理

有効日が指定されたビュー・オブジェクトを作成すると、一時属性のSysEffectiveDateがエンティティ・オブジェクトから継承され、行の有効日が格納されます。通常は、挿入、更新および削除の操作によって一時属性が変更されますが、Oracle ADFフレームワークでは、有効日開始と有効日終了で適切な値を決定します。

概要エディタに表示される有効日が指定されたビュー・オブジェクトの問合せには、有効日の範囲のフィルタリングに必要なWHERE句は表示されません。WHERE句も含めて、有効日が指定されたビュー・オブジェクトの完全な問合せを表示するには、概要エディタの「問合せ」ページで問合せを編集し、「テストおよび説明」をクリックします。次のサンプルは、有効日の一般的な問合せと問合せフィルタを示しています。

SELECT OrdersVO.ORDER_ID,        OrdersVO.CREATION_DATE,
OrdersVO.LAST_UPDATE_DATE
FROM ORDERS OrdersVO
WHERE (:Bind_SysEffectiveDate BETWEEN OrdersVO.CREATION_DATE AND
OrdersVO.LAST_UPDATE_DATE)

次の例は、有効日が指定されたビュー・オブジェクトの作成時に生成されるサンプルのXMLエントリを示しています。

<ViewObject
...
<!-- Property that enables date-effective view object. -->
IsEffectiveDated="true">
<EntityUsage
Name="Orders1"
Entity="model.OrdersDatedEO"
JoinType="INNER JOIN"/>
<!-- Attribute identified as the start date -->
<ViewAttribute
Name="CreationDate"
IsNotNull="true"
PrecisionRule="true"
IsEffectiveStartDate="true"
EntityAttrName="CreationDate"
EntityUsage="Orders1"
AliasName="CREATION_DATE"/>
<!-- Attribute identified as the end date -->
<ViewAttribute
Name="LastUpdateDate"
IsNotNull="true"
PrecisionRule="true"
IsEffectiveEndDate="true"
EntityAttrName="LastUpdateDate"
EntityUsage="Orders1"
AliasName="LAST_UPDATE_DATE"/>
<!-- The SysEffectiveDate transient attribute -->
<ViewAttribute
Name="SysEffectiveDate"
IsPersistent="false"
PrecisionRule="true"    Type="oracle.jbo.domain.Date"
ColumnType="VARCHAR2"
AliasName="SysEffectiveDate"
Passivate="true"
SQLType="DATE"/>
</ViewObject>

5.6.6 有効日が指定されたビュー・オブジェクトとビュー・リンクに関する必知事項

有効日が指定されたアソシエーションおよびビュー・リンクを使用すると、有効日を考慮した問合せを作成できます。この問合せの実行中には、駆動行の有効日がバインド・パラメータとして渡されます。

「アソシエーションの作成」ウィザードまたは「ビュー・リンクの作成」ウィザードを使用すると、2つのエンティティの間に有効日が指定されていないアソシエーションを作成できますが、JDeveloperでは、どちらかの終了日が有効日であれば、アソシエーションまたはリンクは有効日が指定されたものとしてデフォルトで作成されます。ただし、有効日が指定されたオブジェクトと指定されていないオブジェクトとの間にアソシエーションまたはビュー・リンクが存在する場合は、実行時にADFビジネス・コンポーネントによって、問合せ句の生成と有効日のバインドが行われる前に、ビュー・オブジェクトまたはエンティティ・オブジェクトに対して有効日の指定が検証されます。有効日は、最初に駆動行から取得されます。駆動行から取得できない場合は、ルート・アプリケーション・モジュールのEFF_DT_PROPERTY_STRプロパティから取得されます。アプリケーション・モジュール上でEFF_DT_PROPERTY_STRを設定しない場合、駆動行に対する問合せフィルタでは現在の日付が使用され、さらにアソシエーションまたはビュー・リンクの相手側にも現在の日付が適用されます。

5.7 結合問合せ結果での複数表の使用

使用する問合せは、その多くが外部キーによって関連付けられた複数の表を対象としています。このシナリオでは、それらの表を1つのビュー・オブジェクト問合せに結合し、メインの問合せ結果の各行に追加情報を表示します。宣言オプションを使用する問合せの定義には、「ビュー・オブジェクトの作成」ウィザードを使用します。ビュー・オブジェクトを読取り専用にするかエンティティ・ベースにするかによって、結合の定義方法は異なります。

- エンティティ・ベースのビュー・オブジェクトを使用する場合、「ビュー・オブジェクトの作成」ウィザードでは、エンティティ間に定義されている既存のアソシエーションが使用され、ビュー・オブジェクトの結合WHERE句が自動的に作成されます。エンティティ・オブジェクトから得られる結合のタイプは宣言的に指定できます。内部結合(等価結合)と外部結合のどちらもサポートされています。

- 非エンティティ・ベースのビュー・オブジェクトを使用する場合は、「SQL Builder」ダイアログを使用してビュー・オブジェクトの結合WHERE句を構築できます。この場合、結合する表から列を選択する必要があります。

図5-18は、結合問合せを定義するビュー・オブジェクトによって、問い合せられた2つの表から取得した行を示しています。この結合は、単一のフラット化された結果です。

図5-18 結合問合せ結果

5.7.1 エンティティ・ベースのビュー・オブジェクトに対する結合の作成方法

ビジネス・アプリケーションでは、外部キー属性が示す内容をエンド・ユーザーが理解しやすいようにするために、プライマリ・ビジネス・ドメイン・オブジェクトとともにセカンダリ参照情報から情報を補足するのが一般的です。ItemEOエンティティ・オブジェクトを例として考えてみます。このオブジェクトには、次のようなNumber型の外部キー属性が含まれます。

- ItemId: 発注項目が関係する製品を示します。

このような未処理の数値のみをエンド・ユーザーに示しても、あまり役立ちません。アプリケーションの使いやすさを向上させるには、ビュー・オブジェクトに関連付けられたエンティティ・オブジェクトからの参照情報の表示が理想的です。一般的な解決方法の1つとして、プライマリ情報と参照情報の組合せを取得する結合問合せを実行する方法があります。この方法は、参照表に対する特別な問合せに基づいて、問合せ対象の行ごとに参照情報とともにダミー・フィールドを移入するのと同じです。

エンド・ユーザーがデータを編集して外部キー値を変更できる場合、この方法は別の課題をもたらします。この場合、エンティティ・ベースのビュー・オブジェクトは、常に最新の状態の参照情報を簡単に組み込む機能をサポートしています。この機能を活用するには、ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトの慣用名として機能するエンティティ・オブジェクトと、参照情報を提供するエンティティ・オブジェクト間にアソシエーションが確立されていることが必要です。

結合ビュー・オブジェクトに参照エンティティを取り込む場合は、「ビュー・オブジェクトの作成」ウィザードを使用します。「ビュー・オブジェクトの作成」ウィザードでは、次のいずれかの結合タイプを指定します。

- 内部結合
ビュー・オブジェクトから、(各エンティティが同じ主キー列を定義している)2つ以上のエンティティ・オブジェクト間のすべての行を戻す場合に選択します。結合されたエンティティに主キー値がない場合は、内部結合ビュー・オブジェクトから戻される行はありません。

- 外部結合
ビュー・オブジェクトから、1つのエンティティ・オブジェクトに存在するすべての行を(それに対応する行が結合されたエンティティ・オブジェクトになくても)戻す場合に選択します。左外部結合と右外部結合両方がサポートされています。左および右を指定すると、アソシエーションで指定された関連元(左)および関連先(右)のエンティティ・オブジェクトが参照されます。デフォルトの内部結合を外部結合に変更する方法の詳細は、「必要に応じたデフォルトの結合句の外部結合への変更」を参照してください。一致する外部エンティティ行が見つからない(存在しない)場合の詳細は、「外部結合に関する必知事項」を参照してください。

内部結合と外部結合のどちらにおいても、次のオプションを使用できます。

- 参照
エンティティ・オブジェクトのデータをビュー・オブジェクトの参照情報として使用する場合に選択します。データの自動参照がサポートされているため、制御キー属性が変更される場合は、属性値がエンティティ・キャッシュから動的にフェッチされます。この設定が実行時動作に与える影響の詳細は、「実行時の処理: ビュー行の作成」を参照してください。

- 更新可能
ビュー・オブジェクトによってエンティティ・オブジェクトの任意のエンティティ属性が変更されないようにする場合は選択を解除します。デフォルトでは、「選択済」リストの先頭にあるエンティティ・オブジェクト(プライマリ)は更新可能であり、後続のエンティティ・オブジェクト(セカンダリ)は更新できません。複数の更新可能なエンティティ・オブジェクトの慣用名を使用して結合ビュー・オブジェクトを作成する方法の詳細は、「多相エンティティ・オブジェクトの慣用名を持つサブタイプ・ビュー・オブジェクトを作成する方法」を参照してください。

- 行削除のサポート
エンティティが更新可能として定義されており、かつUIの行削除のアクションにより関連する参照エンティティ・オブジェクトが削除されるようにする場合に選択します。このオプションは、プライマリ・エンティティに対しては無効で、主として外部結合されたエンティティに使用されます。たとえば、注文項目は削除できますが、結合ビュー・オブジェクトから行削除がコールされた場合、その注文は削除できないようにする必要があります。この設定が様々な結合タイプのビューの行削除に及ぼす影響の詳細は、「エンティティ・ベースの結合と行削除サポートに関する必知事項」および「コンポジット・アソシエーションと結合に関する必知事項」を参照してください。

始める前に:

ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

結合問合せに関連したOracle Databaseの機能を理解しておくと役に立つ場合があります。詳細は、「SQL問合せおよび副問合せ」を参照してください。

次のタスクを完了する必要があります。

- 「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。

エンティティ・オブジェクトを結合するビュー・オブジェクトを作成するには:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するデータ・モデル・プロジェクトのパッケージを右クリックし、「新規」、「ビュー・オブジェクト」の順に選択します。

2. 「ビュー・オブジェクトの作成」ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。デフォルト設定の「エンティティ」を有効にしたままにして、このビュー・オブジェクトとその基礎となるエンティティ・オブジェクトの連動によってデータを管理します。「次へ」をクリックします。

3. 「エンティティ・オブジェクト」ページの、「選択されたもの」リストの先頭にあるエンティティ・オブジェクトの慣用名は、ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトの慣用名と呼ばれます。「使用可能」リストからプライマリ・エンティティ・オブジェクトを選択し、それを「選択済」リストに移動します。

このリストへの移動は、1つのプライマリ・エンティティ・オブジェクトの慣用名には限定されません。

4. さらに、セカンダリ・エンティティ・オブジェクトをビュー・オブジェクトに追加する場合は、これらを「使用可能」リストから選択し、「選択済」リストに移動します。

「アソシエーション」ドロップダウン・リストには、選択したセカンダリ・エンティティ・オブジェクトの慣用名をプライマリ・エンティティ・オブジェクトの慣用名に関連付けるアソシエーションの名前が表示されます。たとえば、図5-19は、プライマリ・エンティティ・オブジェクトの慣用名ItemEOの他に、セカンダリの参照エンティティ・オブジェクトの慣用名ProductEOを1つ追加した結果を示しています。このセカンダリ・エンティティ・オブジェクトの慣用名に関連するアソシエーションは、SItemProductIdFkAssoc.ProductEOです。

図5-19 「ビュー・オブジェクトの作成」ウィザードの「エンティティ・オブジェクト」ページ

5. デフォルト名が明確でない場合は、「エンティティ・オブジェクトの慣用名」フィールドを使用して、より意味のある名前をエンティティ・オブジェクトの慣用名として指定することもできます。

6. 同じエンティティに対して複数のエンティティ・オブジェクトの慣用名を追加する場合、「アソシエーション」ドロップダウン・リストを使用して、このオブジェクトの慣用名とプライマリ・エンティティ・オブジェクトの慣用名との関連を示すアソシエーションを選択します。「次へ」をクリックします。

各セカンダリ・エンティティ・オブジェクトの慣用名に対しては、「参照」オプションが有効にされており、これは各エンティティが参照情報を提供すること、およびプライマリ・エンティティではないことを示します。「更新可能」オプションは無効にされています。この組合せが一般的に使用されます。ただし、複数の更新可能なエンティティ・オブジェクトの慣用名を使用して結合ビュー・オブジェクトを作成する必要がある場合は、「多相エンティティ・オブジェクトの慣用名を持つサブタイプ・ビュー・オブジェクトを作成する方法」を参照してください。

更新可能なセカンダリ・エンティティ・オブジェクトの慣用名に対しては、「行削除のサポート」オプションを有効にすることもできます。これにより、プライマリ・エンティティが表示される際、セカンダリ・エンティティ属性にNULL値を表示できます。

7. 「属性」ページで、各エンティティ・オブジェクトの慣用名からビュー・オブジェクトに取り込む属性を選択します。「次へ」をクリックします。

8. 「属性の設定」ページでは、属性の名前がわかりにくい場合はその名前を変更できます。

参照エンティティ・オブジェクトやセカンダリ・エンティティ・オブジェクトが同じ表から導出される場合は、属性名が重複することがあります。図5-20では、「属性の選択」ドロップダウン・リストの属性Idが、「名前」フィールドでProductIdという名前に変更されています。

図5-20 「ビュー・オブジェクトの作成」ウィザードの「属性の設定」ページ

9. 「終了」をクリックします。

5.7.2 必要に応じたデフォルトの結合句の外部結合への変更

セカンダリ・エンティティ・オブジェクトの慣用名をビュー・オブジェクトに追加する場合、このエンティティ・オブジェクトの慣用名は、選択済エンティティのリストで上位にあるエンティティ・オブジェクトの慣用名に関連付けられます。この関係は、ビュー・オブジェクトの概要エディタの「エンティティ・オブジェクト」ページの「アソシエーション」ドロップダウン・リストに表示されるエンティティ・アソシエーションによって確立されます。エディタの「アソシエーション」ドロップダウン・リストを使用して、セカンダリ・エンティティ・オブジェクトの慣用名を、「選択されたもの」リストの上位にある目的のエンティティ・オブジェクトの慣用名に関連付けるエンティティ・アソシエーションを選択します。上位のエンティティ・オブジェクトの慣用名の名前は、「ソースの使用方法」ドロップダウン・リストで指定されます。

プライマリ・エンティティ・オブジェクトの慣用名の表とそれに関連付けられているセカンダリ・エンティティ・オブジェクトの慣用名の表の間に結合用のWHERE句が作成される場合、デフォルトでは常に内部結合が作成されます。必要であれば、デフォルトの内部結合句を左または右外部結合として変更もできます。左を指定すると、選択したアソシエーションで指定した関連元エンティティ・オブジェクトが参照されます。これは、「ソースの使用方法」ドロップダウン・リストで指定されたエンティティです。右を指定すると「選択されたもの」リストで選択している現在のセカンダリ・エンティティ・オブジェクトの慣用名が参照されます。

左外部結合では、(現在選択しているセカンダリ・エンティティ・オブジェクトに関連する)右の表に対応する行がない場合でも、(「ソースの使用方法」リストで指定したエンティティ・オブジェクトに関連する)左の表のすべての行が結合に含まれます。右外部結合では、その逆で、(現在選択しているセカンダリ・エンティティ・オブジェクトに関連する)左の表に対応する行がない場合でも、(「選択されたもの」リストで指定したエンティティ・オブジェクトに関連する)右の表のすべての行が結合に含まれます。

たとえば、ユーザーにまだメンバーシップ・ステータスが割り当てられていないとします。この場合、MembershipId属性はNULLになります。デフォルトの内部結合条件では、MEMBERSHIPS_BASE表からこれらのユーザーは取得されません。MembershipDiscountsVOビュー・オブジェクトを介して、メンバーシップ・ステータスを持たないユーザーを表示可能および更新可能にする必要がある場合は、概要エディタにある「エンティティ・オブジェクト」ページを使用して、ビュー・オブジェクトについての問合せを、MEMBERSHIP_ID列のnullになる可能性のある値についてのMEMBERSHIPS_BASE表に対する左外部結合に変更できます。ユーザー・エンティティをビュー・オブジェクトに追加する場合は、「結合タイプ」として「左外部結合」を選択します。図5-21に示すように、アソシエーションPersonsMembershipsBaseFkAssocでは、結合の左側としてソースの慣用名MembershipBaseEO、右側として選択済エンティティ・オブジェクトの慣用名PersonEOを指定します。ビュー・オブジェクトMembershipDiscountsVOでは、これら両方のエンティティ・オブジェクトに関連する行が結合され、またPersonEOに対する左外部結合の定義により、このビュー・オブジェクトは、PersonEOに関連する表に対応する行がない場合でも、MembershipBaseEOに関連する表の行を返すことができます。

図5-21 結合されたエンティティからNULLの行を返す外部結合の設定

ビュー・オブジェクトの更新されたWHERE句の等号の右側では、データを左外部結合に含む必要のない関連表に対して(+)演算子が追加されています。

PersonEO.MEMBERSHIP_ID = MembershipBaseEO.MEMBERSHIP_ID(+)

始める前に:

ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。

内部結合を外部結合に変更するには:

1. 「アプリケーション」ウィンドウで、変更するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「エンティティ・オブジェクト」ナビゲーション・タブをクリックします。

選択するエンティティ・オブジェクトは、結合の右側の表を表します。

3. 「エンティティ・オブジェクト」ページの「選択されたもの」リストで、結合タイプを変更するエンティティ・オブジェクトを選択します。

選択するエンティティ・オブジェクトは、結合の右側の表を表します。

4. 「アソシエーション」ドロップダウン・リストで、定義が1つのみの場合は選択されているままにし、それ以外の場合は、セカンダリ・エンティティ・オブジェクトを目的のエンティティ・オブジェクトに関連付けるエンティティ・オブジェクト・アソシエーションのリストから選択します。

結合された表を表すエンティティ・オブジェクトの慣用名が、「ソースの使用方法」ドロップダウン・リストに表示されます。アソシエーションの選択を通じて選択する、「ソースの使用方法」ドロップダウン・リストのエンティティ・オブジェクトは、結合の左側の表を表します。

5. 「結合タイプ」ドロップダウン・リストで、ビュー・オブジェクトが結合されたエンティティ・オブジェクトから行を返す方法を指定します。

- 「左外部結合」では、右の表に対応する行がない場合でも、結合に左の表の行が含まれます。

- 「右外部結合」では、左の表に対応する行がない場合でも、結合に右の表の行が含まれます。

「ソースの使用方法」ドロップダウン・リストは、結合の左側を表し、 「選択されたもの」リストの現在のエンティティ・オブジェクトの慣用名は、結合の右側を表します。

5.7.3 参照エンティティ・オブジェクトの慣用名からの追加属性の選択方法

セカンダリ・エンティティ・オブジェクトの慣用名を追加したら、ビュー・オブジェクトの概要エディタを使用して、ビュー・オブジェクトに組み込むこれらの新しいオブジェクトの慣用名から特定の追加属性を選択できます。

ヒント:

概要エディタでは、「属性」ページに表示される属性を、エンティティ・オブジェクトの慣用名を基準にソートできます。デフォルトでは、属性表には、基礎となるエンティティ・オブジェクトに表示される順番に属性が表示されます。エンティティ・オブジェクトの慣用名を基準に属性をソートするには、属性表の「エンティティ・オブジェクトの慣用名」列のヘッダーをクリックします。属性表に「エンティティ・オブジェクトの慣用名」列が表示されない場合は、表の右上隅(ボタン・バーの下)のドロップダウン・メニューをクリックし、「列の選択」を選択して、この列を「選択されたもの」リストに追加します。

始める前に:

ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。

結合問合せに関連したOracle Databaseの機能を理解しておくと役に立つ場合があります。詳細は、「SQL問合せおよび副問合せ」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。

セカンダリ・エンティティ・オブジェクトの慣用名から属性を選択するには:

1. 「アプリケーション」ウィンドウで、変更するエンティティ・ベースのビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規属性の作成」ボタンをクリックして「エンティティからの属性の追加」を選択し、エンティティから導出された利用可能な属性のリストを表示します。

3. 「属性」ページで、目的の属性を選択し、「選択されたもの」ボタンをクリックします。

これらを組み込む意図がなかったとしても、各エンティティ・オブジェクトの慣用名の主キー属性が「選択済」リストの一部であるかどうかが自動的に検証されます。これらがリストに含まれていない場合は自動的に追加されます。処理が終了すると、概要エディタの「問合せ」ページには、JDeveloperによって新規の列がSELECT文に取り込まれたことを示すメッセージが表示されます。

4. 「OK」をクリックします。

5.7.4 参照エンティティ・オブジェクトの慣用名からの不要なキー属性の削除方法

プライマリ・エンティティ・オブジェクトの慣用名の主キー属性に対応するビュー・オブジェクト属性は、ビュー行を識別するための主キーとして機能します。セカンダリ・エンティティ・オブジェクトの慣用名を追加すると、これらの主キー属性に対応するビュー・オブジェクト属性はビュー行キーの一部としてマークされます。ビュー・オブジェクトが単一の更新可能なプライマリ・エンティティ・オブジェクトの慣用名と多くの参照エンティティ・オブジェクトの慣用名で構成されている場合、ビュー行を一意に識別するにはプライマリ・エンティティ・オブジェクトの慣用名の主キー属性で十分です。セカンダリ・エンティティ・オブジェクトの慣用名から取り込まれた追加キー属性は不要になるため、これらの「キー属性」設定を無効にする必要があります。

たとえば、プライマリ・エンティティ・オブジェクトの慣用名ShippingOptionEOを持つビュー・オブジェクトに基づいて、エンティティ・オブジェクトの慣用名ShippingOptionTranslationEOの「キー属性」プロパティを無効にすることができ、これにより、この追加キー属性ShippingTranslationsIdに対してこのプロパティは選択されなくなります。

ただし、ビュー・オブジェクトが複数の更新可能なプライマリ・エンティティ・オブジェクトの慣用名で構成されている場合、ビュー行を識別するための主キーは、少なくともビュー・オブジェクトに含まれるすべての更新可能なエンティティ・オブジェクトの慣用名のすべてのキー属性で構成されている必要があります。

始める前に:

ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。

不要なキー属性を削除するには:

1. 「アプリケーション」ウィンドウで、変更するエンティティ・ベースのビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページの属性表で、キー属性(「名前」のキー・アイコンで識別)を選択し、「詳細」タブをクリックし、「キー属性」プロパティの選択を解除します。

5.7.5 参照エンティティ・オブジェクトの慣用名の主キー属性を非表示にする方法

通常、ビュー・オブジェクトに自動的に追加された主キー属性は表示する必要がないため、属性の「ヒントの表示」プロパティを「非表示」に設定できます。

始める前に:

ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。

主キー属性を非表示にするには:

1. 「アプリケーション」ウィンドウで、変更するエンティティ・ベースのビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、主キー属性(「名前」列のキー・アイコンで識別)を選択し、「UIヒント」タブをクリックして、「表示」タイプに「非表示」を選択します。

5.7.6 ビュー・オブジェクトの複数のエンティティを参照するときに行われる処理

図5-7は、エンティティ・ベースのビュー・オブジェクトItemVOと、この問合せ文で参照される2つのエンティティ・オブジェクトの慣用名を示しています。点線は、問合せのSELECTリストの列を、ビュー・オブジェクトで使用されるエンティティ・オブジェクトの属性にマップする、エンティティ・ベースのビュー・オブジェクトのXMLドキュメントで取得されるメタデータを表します。エンティティ・ベースのビュー・オブジェクトの問合せにより、プライマリ・エンティティ・オブジェクトの慣用名(ItemEO)のデータと、セカンダリの参照エンティティ・オブジェクトの慣用名(ProductEO)のデータが結合されます。

図5-22 複数のエンティティ・オブジェクトの属性をマップするビュー・オブジェクト

結合ビュー・オブジェクトを作成して、参照別のセカンダリ・エンティティ・オブジェクトの慣用名を1つ以上組み込むと、ビュー・オブジェクトのXMLドキュメントが更新され、追加のエンティティ・オブジェクトの慣用名に関する情報が組み込まれます。たとえば、ビュー・オブジェクトのItemVO.xmlファイルに、別の参照エンティティ・オブジェクトの慣用名が含まれているとします。この情報は、複数の<EntityUsage>要素に記録されていることがわかります。たとえば、図5-5は、プライマリ・エンティティ・オブジェクトの慣用名を定義するエンティティ・オブジェクトの慣用名のエントリを示しています。

<EntityUsage
Name="ItemEO"
Entity="oracle.summit.model.entities.ItemEO"/>

セカンダリの参照エンティティ・オブジェクトの慣用名のエントリはこれとは若干異なり、次の例に示すエンティティ・オブジェクトの慣用名のように、これをプライマリ・エンティティ・オブジェクトの慣用名に関連付けるアソシエーションに関する情報が含まれます。

<EntityUsage
Name="ProductEO"
Entity="oracle.summit.model.entities.ProductEO"
Association="oracle.summit.model.entities.assoc.SItemProductIdFkAssoc"
AssociationEnd="oracle.summit.model.entities.assoc.
SItemProductIdFkAssoc.ProductEO"
SourceUsage="oracle.summit.model.views.ItemVO.ItemEO"
ReadOnly="true"
Reference="true"
Participant="false"
JoinType="INNER JOIN/>

XMLファイル内の各属性エントリは、参照先のエンティティ・オブジェクトの慣用名を示します。たとえば、次の例のOrdId属性のエントリは、これがItemEOエンティティ・オブジェクトの慣用名に関連付けられており、Name属性がProductEOエンティティ・オブジェクトの慣用名に関連付けられていることを示しています。

<ViewAttribute
Name="OrdId"
IsNotNull="true"
EntityAttrName="OrdId"
EntityUsage="ItemEO"
AliasName="ORD_ID" >
</ViewAttribute>
...
<ViewAttribute
Name="Name"
IsUpdatable="true"
IsNotNull="true"
EntityAttrName="Name"
EntityUsage="ProductEO"
AliasName="NAME" >
</ViewAttribute>

「ビュー・オブジェクトの作成」ウィザードでは、このアソシエーション情報が設計時に使用され、ビュー・オブジェクトの結合WHERE句が自動的に作成されます。この情報が実行時に使用されることにより、エンド・ユーザーによって外部キー属性値が変更されたときに参照情報を最新の状態に保つことが可能になります。

5.7.7 外部結合に関する必知事項

外部結合を指定した場合、一致する外部エンティティ行が見つからないときには、問合せのその部分に関して、データベースからNULLが返されます。たとえば、外部結合のDeptEmpViewでDeptエンティティとEmpエンティティを結合するときに、Dept 40に従業員が存在しないとします。その場合は、Dept 40の行に達すると、データベースから[40, null]が返され、ADFビジネス・コンポーネントでDept 40のエンティティ行と空白のEmpエンティティ行が作成されます。ビュー・オブジェクトのEmpエンティティが更新可能と設定されている場合は、この空白のエンティティ行に属性値を設定できます。その後、トランザクションをコミットすると、新しいエンティティ行が挿入されます。

5.7.8 エンティティ・ベースの結合とエンティティのカーディナリティに関する必知事項

CustomerとOrderというエンティティ・オブジェクトがあり、エンティティ・アソシエーションCustOrderIdFKAssoc (Customerのカーディナリティはmanyで、Orderのカーディナリティは1)に基づいてビュー・オブジェクト結合を作成するとします。

Orderエンティティ(カーディナリティが1のプライマリ・エンティティ)からCustomerエンティティ(カーディナリティがmanyのセカンダリ・エンティティ)への結合である、1対多の結合ビュー・オブジェクトOrderCustVOを作成すると、多数のOrder行に対して同じCustomerエンティティ行が返されます。

Customer(プライマリ、many)からOrder(セカンダリ、1)への結合である、多対1の結合ビュー・オブジェクトCustOrderVOを作成すると、多数のOrder行を持つ同じCustomerエンティティ行が返されます。

OrderCustVO (1対多)の場合は、Customerが参照エンティティであり、エンド・ユーザーが行を削除するとOrderエンティティ行のみが削除され、Customerは影響を受けません。同様に、CustOrderView(多対1)の場合は、Orderが参照エンティティであり、エンド・ユーザーが行を削除するとCustomerエンティティ行のみが削除され、Orderは影響を受けません。

ただし、CustOrderVO(多対1)の場合は、エンド・ユーザーが1つの行を削除すると、結合ビュー・インスタンスから複数の行が削除されます。たとえば、Customer 10に3つの発注(A、B、C)があるとします。エンド・ユーザーがこの中の最初の結合ビュー行である[10, A]を削除すると、実際には[10, A]、[10, B]および[10, C]の3つのビュー行が削除されます。エンティティ・レベルでは、Orderは参照エンティティであるため、Customer 10エンティティ行のみが削除されます。

5.7.9 エンティティ・ベースの結合と行削除サポートに関する必知事項

1対多の結合(たとえばOrderCustVOビュー・オブジェクト)と多対1の結合(たとえばCustOrderVOビュー・オブジェクト)を作成し、セカンダリ・エンティティ・オブジェクトでは「行削除のサポート」が有効になっているとします(また、Customer 10にはOrder A、B、Cがあるものとします)。

1対多の結合OrderCustVOを作成し、Customerエンティティ・オブジェクトで「行削除のサポート」が有効になっていると仮定すると、エンド・ユーザーが[A, 10]を削除すると、Order Aエンティティ行が最初に削除され、その後Customer 10エンティティ行が削除されます。このCustomer 10が削除されるときには、実際にはそのエンティティ行を参照するすべてのビュー行が削除されます。つまり、[A, 20]と[A, 30]も削除されます(合計3つのビュー行)。

多対1の結合CustOrderVOを作成し、Orderエンティティ・オブジェクトで「行削除のサポート」が有効になっていると仮定すると、エンド・ユーザーが[10, A]を削除すると、Customer 10エンティティ行が最初に削除されます。その後、そのエンティティ行を参照しているすべてのビュー行が削除されます。つまり、[20, A]と[30, A]もビューから削除されます。その後、Order Aエンティティ行が削除されます。

5.7.10 コンポジット・アソシエーションと結合に関する必知事項

エンティティ・オブジェクトOrderおよびOrderItemの間のアソシエーションがコンポジット・アソシエーションで、これらのエンティティに基づいてビュー・オブジェクト結合を作成するとします。Order AにはItem 1、2、3が含まれるものとします。

ItemOrdVOビュー・オブジェクトの場合、Order(セカンダリ)は参照エンティティであり、エンド・ユーザーが[1, A]を削除しても、1のOrderItemエンティティ行のみが削除され、問題は発生しません。しかし、Orderエンティティ・オブジェクトで「行削除のサポート」が有効になっている場合は、エンド・ユーザーが[1, A]を削除すると、Item 1のエンティティ行の削除後、Order Aの削除も試行されます。ただし、コンポジット関係があるため、この操作は失敗し、RemoveWithDetailsExceptionがスローされます。これは、Order AにはまだOrder Aに属するOrderItem 2とOrderItem 3が存在するからです。

OrdItemVOビュー・オブジェクトの場合は、Item(セカンダリ)エンティティが参照エンティティであり、エンド・ユーザーが[A, 1]を削除するとOrder Aのエンティティ行の削除も試行されます。ただし、コンポジット関係があるため、この操作は失敗し、RemoveWithDetailsExceptionがスローされます。これは、Order AにはまだOrder Aに属するItem 1、Item 2およびItem 3が存在するからです。

Item(セカンダリ)エンティティ・オブジェクトで「行削除のサポート」が有効になっている場合は、[A, 1]を削除すると、Order Aに子の行があるために同じ例外が発生します。

エンティティ・アソシエーションで、「コンポジット・アソシエーション」の「カスケード削除の実装」が有効である場合は、異なる状況になります。

ItemOrderVOビュー・オブジェクトの場合、Orderは参照エンティティであり、エンド・ユーザーが[1, A]を削除しても、Item Aのエンティティ行が削除されるのみです(例外はスローされません)。Orderエンティティ・オブジェクトで「行削除のサポート」が有効になっている場合は、エンド・ユーザーが[1, A]を削除すると、Item Aが最初に削除され、その後Order Aが削除されます。カスケード削除が有効になっているため、Order Aの削除により、Item 2およびItem 3を含む、Order Aの残りのすべての子も削除されます。その結果、ビュー行[2, A]および[3, A]がビュー・インスタンスから削除されます。

同様に、OrderItemVOビュー・オブジェクトの場合は、Itemが参照エンティティであり、エンド・ユーザーが[A, 1]を削除するとOrder Aが削除されます。「カスケード削除の実装」が有効になっているため、Item 1、2および3を含む、Order Aのすべての子も削除されます。その結果、ビュー行[A, 2]、[A, 2]および[A, 3]がビュー・インスタンスから削除されます。

Itemエンティティ・オブジェクトで「行削除のサポート」が有効になっている場合は、同じ動作になり、3つのビュー行すべてが削除されます。

5.7.11 読取り専用ビュー・オブジェクトに対する結合の作成方法

2つの表を結合する読取り専用ビュー・オブジェクトを作成するには、「ビュー・オブジェクトの作成」ウィザードを使用します。

始める前に:

ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

2つの表を結合する読取り専用ビュー・オブジェクトを作成するには:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」、「ビュー・オブジェクト」の順に選択します。

2. データ・モデル・プロジェクトにまだデータベース接続を作成していない場合は、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規」を選択して接続を作成します。「OK」をクリックします。

これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。

3. 「ビュー・オブジェクトの作成」ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。「カスタムSQL問合せ」を選択して、このビュー・オブジェクトが読取り専用アクセスでデータを管理することを指定します。「次へ」をクリックします。

4. 「問合せ」ページでは、目的の表を結合するSQL問合せ文を作成するため、次のいずれかの操作を行います。

- 有効なSQL文を「選択」ボックスに入力するか、貼り付けます。

- 「クエリー・ビルダー」をクリックして「SQL文」ダイアログを開き、「読取り専用オブジェクトに「SQL文」ダイアログを使用する方法」の説明に従って問合せ文を作成します。

5. 問合せ文を入力または作成した後、「次へ」をクリックします。

6. 「バインド変数」ページで、次のいずれかを実行します。

- 問合せがバインド変数を参照しない場合は、「次へ」をクリックして、ステップ3を省略します。

- バインド変数を追加し、それを問合せの中で使用する場合は、「ビュー・オブジェクト定義にWHERE句のバインド変数を追加する方法」を参照してください。

7. 「属性マッピング」ページと「属性」ページで「次へ」をクリックします。

8. 「属性の設定」ページで、「終了」をクリックします。

5.7.12 結合ビューのテスト方法

新規ビュー・オブジェクトをテストするには、アプリケーション・モジュールを編集し、「データ・モデル」ページで新規ビュー・オブジェクトのインスタンスをデータ・モデルに追加します。次にOracle ADFモデル・テスターを使用して、結合問合せが予期したとおりに動作しているかどうかを検証します。データ・モデルを編集してOracle ADFモデル・テスターを実行する方法の詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

5.7.13 読取り専用オブジェクトに「SQL文」ダイアログを使用する方法

「SQL文」ダイアログの「クイックピック・オブジェクト」ページでは、他の表に関連する外部キーも含め、自分のスキーマで表を参照できます。問合せの選択リストに列を組み込む場合は、目的の列を「使用可能」リストから「選択済」リストに移動します。たとえば、図5-23は、S_PRODUCT_CATEGORIES表からCATEGORY列を選択すると同時に、S_PRODUCT表からID、NAMEおよびSUGGESTED_WHLSL_PRICEの各列を選択した結果を示しています。2番目の表の列は、「使用可能」リストのS_PRODUCT_CATEGORY_ID_FK外部キーの下に表示されています。外部キーによって結合された表から列を選択すると、必要な結合句が「SQL文」ダイアログで自動的に決定されます。

図5-23 結合を定義する、ビュー・オブジェクトの「SQL文」ダイアログ

必要に応じて、「SQL文」ダイアログの「WHERE句」ページで式を定義します。問合せの作成を終了する場合は、「SQL文」ダイアログの「OK」をクリックします。概要エディタの「問合せ」ページに、次の例に示すような問合せが表示されます。

SELECT
S_PRODUCT.ID ID,
S_PRODUCT.NAME NAME,
S_PRODUCT.SUGGESTED_WHLSL_PRICE SUGGESTED_WHLSL_PRICE,
S_PRODUCT_CATEGORIES.CATEGORY CATEGORY
FROM
S_PRODUCT JOIN S_PRODUCT_CATEGORIES ON S_PRODUCT.CATEGORY_ID =
S_PRODUCT_CATEGORIES.ID

「ビュー・オブジェクトの作成」ウィザードの「属性」ページでは、作成プロセスの一部としてビュー・オブジェクト属性の名前を直接変更できます。ここでビュー・オブジェクトの名前を変更しておくと、使用する属性名がわかっている場合にビュー・オブジェクトを再度編集する必要がなくなります。また、列の別名を割り当てることにより、Javaに適したデフォルトのビュー・オブジェクト属性名を変更することもできます。「カスタムSQLモードの計算式の属性名」を参照してください。

5.8 ビュー・オブジェクトとカスタムSQLの操作

標準モードでエンティティ・ベースのビュー・オブジェクトを定義する場合、WHERE句とORDER BY句はすべてを指定できますが、デフォルトでは、FROM句とSELECTリストは自動的に導出されます。FROM句は関係するエンティティ・オブジェクトの慣用名に関連する表の名前から決定されますが、SELECTリストは次のものが基になります。

- 関係するエンティティ・マップ属性の基礎となる列名

- SQL計算属性のSQL式

問合せでSELECT句またはFROM句を完全に制御する必要がある場合は、カスタムSQLモードを有効にできます。

ヒント:

JDeveloperのビュー・オブジェクト・エディタとウィザードでは、選択内容に応じたSQLの生成が完全にサポートされています。たとえば、そのような2つのオプションを使用すると、外部結合を宣言的に定義して、宣言SQLモード(実行時までSQLが生成されない)で作業することができます。

5.8.1 カスタムSQLモード・ビュー・オブジェクトの作成方法

SQL文を完全に制御する必要がある場合は、「ビュー・オブジェクトの作成」ウィザードでカスタムSQLモードを使用してその指定ができます。作成したカスタムSQLビュー・オブジェクトは、主に、UNIONまたはGROUP BY問合せを記述する必要がある場合に役立ちます。また、キー属性をマークしている場合は、ビュー・オブジェクト・ベースのキー存在バリデータで使用されるSQLベースの検証問合せを作成する必要がある場合に、カスタムSQLビュー・オブジェクトを作成できます。

エンティティ・ベースのビュー・オブジェクトを使用する場合とエンティティ・オブジェクトに基づかないカスタムSQLビュー・オブジェクトを使用する場合のトレードオフの詳細は、「読取り専用データへのエンティティ・ベースのビュー・オブジェクトの使用方法」を参照してください。

カスタムSQLビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能な「ビュー・オブジェクトの作成」ウィザードを使用します。

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

カスタムSQLビュー・オブジェクトを作成する手順:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するパッケージを右クリックし、「新規」、「ビュー・オブジェクト」の順に選択します。

2. データ・モデル・プロジェクトにまだデータベース接続を作成していない場合は、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規」を選択して接続を作成します。「OK」をクリックします。

これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。

3. 「ビュー・オブジェクトの作成」ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。「カスタムSQL問合せ」を選択して、このビュー・オブジェクトではエンティティ・オブジェクトを利用せずにデータを管理することを指定します。「次へ」をクリックします。

4. 「問合せ」ページでは、次のいずれかの操作を行います。

- 有効なSQL文を「選択」テキスト・ボックスに入力するか、貼り付けます。問合せ文では、WHERE句とOrder By句を使用できます。たとえば、図5-24は、WHERE句とOrder By句を使用して、アプリケーションで使用される言語の国コードのリストを問い合せる文を示しています。

- 「クエリー・ビルダー」をクリックして「SQL文」ダイアログを開き、そこで問合せ文を作成します。

図5-24 「ビュー・オブジェクトの作成」ウィザードの「問合せ」ページ

注意:

「問合せ」ページではなく、「エンティティ・オブジェクト」ページが表示された場合は、ウィザードのステップ1に戻り、「カスタムSQL問合せ」を選択してあることを確認してください。

5. 問合せ文を入力または作成した後、「次へ」をクリックします。

6. 「バインド変数」ページで、次のいずれかを実行します。

- 問合せがバインド変数を参照しない場合は、「次へ」をクリックしてこのページを省略します。

- バインド変数を追加し、それを問合せの中で使用する場合は、「ビュー・オブジェクト定義にWHERE句のバインド変数を追加する方法」を参照してください。

7. 「属性の設定」ページでは、「属性の選択」ドロップダウンを使用して、問合せ表の主キーに対応する属性を選択し、「キー属性」チェック・ボックスが選択されていることを確認します。

「ビュー・オブジェクトの作成」ウィザードでは、図5-25のように、データベースからキー属性が自動検出され、「キー属性」チェック・ボックスが選択されます。キー属性を定義しなかった場合、ビュー・オブジェクト・コレクションに基づくデータ・コントロールを持つADF Facesコンポーネントが、実行時に予期しない動作をすることがあります。

図5-25 「ビュー・オブジェクトの作成」ウィザードの「属性の設定」ページ

8. 「終了」をクリックします。

注意:

「ADFビジネス・コンポーネント」ウィザードおよびエディタのデフォルトの規則では、属性名に頭文字が大文字表記の名前を使用します。これは、最初の文字を大文字で表し、名前が複数の単語で構成されている場合には、読みやすくするために名前の途中でも大文字を使用する表記法です。

5.8.2 カスタムSQLビュー・オブジェクトの作成時に行われる処理

カスタムSQLモードを使用してビュー・オブジェクトを作成する際、JDeveloperでは最初にSELECTリストの列から次を推測する問合せが解析されます。

- Javaに適したビュー属性名(COUNTRY_NAMEではなくCountryNameなど)
デフォルトでは、SELECTリスト列名に対応する、Javaに適したビュー・オブジェクト属性名がウィザードによって作成されます(図5-26を参照)。

ビュー・オブジェクト属性の名前を使用して、ビュー・オブジェクトの名前別結果セットの任意の行のデータにアクセスする方法は、「ビュー・オブジェクト・インスタンスのプログラムによるテスト」を参照してください。

- 各属性のSQLおよびJavaデータ型

図5-26 「ビュー・オブジェクトの作成」ウィザードの「属性マッピング」ページ

SOME_COLUMN_NAMEのようにアンダースコアで区切られた列名の各部分は、SomeColumnNameのような単語の最初を大文字にした属性名に変えられます。ビュー・オブジェクト属性名はSELECTリストの基礎となる問合せ列に対応しますが、ビュー・オブジェクト・レベルでの属性名とは必ずしも一致しません。

ヒント:

ビュー・オブジェクト属性の名前は、基礎となる問合せを変更しなくても、より適切な名前に変更できます。

次に、JDeveloperでビュー・オブジェクトの宣言設定を表すXMLドキュメントが作成され、そのパッケージの名前に対応するディレクトリ内に格納されます。たとえば、lookupsパッケージのCountriesVOという名前のビュー・オブジェクトに対しては、プロジェクトのソース・パスに./lookups/CountriesVO.xmlというXMLファイルが作成されます。

ビュー・オブジェクト設定を表示するには、「アプリケーション」ウィンドウで目的のビューを選択して、「構造」ウィンドウを開きます。「構造」ウィンドウは、SQL問合せや属性のリストなどXML定義のリストを表示します。エディタでXML定義を開くには、対応するノードを右クリックして「ソースに移動」を選択します。

5.8.3 カスタムSQLモードでSQL文をカスタマイズする方法

カスタムSQLモードを有効にするには、「ビュー・オブジェクトの作成」ウィザードの「問合せ」ページで「カスタムSQLの書込み」を選択します。ビュー・オブジェクトの概要エディタで、既存のエンティティ・ベースのビュー・オブジェクトのSQL文を変更することもできます。概要エディタで、「問合せ」ページに移動し、「カスタムSQLの書込み」を選択します。

5.8.4 カスタムSQLモードを有効にしたときに行われる処理

カスタムSQLモードを有効にすると、概要エディタまたはウィザードの「問合せ」ページの「選択」テキスト・ボックスが完全に編集可能になり、SQL文全体が表示されます。このテキスト・ボックスを使用して、SQL問合せのすべての部分を変更できます。

カスタムSQLモードでの作業中は、「選択」テキスト・ボックスにORDER BY句を直接追加できますが、ランタイム・エンジンで問合せにWHERE句を追加しなければならない場合があるため、句のORDER BYの部分を分離したままにすると便利です。ORDER BY句を別に保持することで、正しく適用されるようになります。

5.8.5 カスタムSQLモードに関する必知事項

カスタムSQLモードを使用してSQL問合せを定義する場合は、エディタに直接SQL言語文を入力します。このモードを使用する場合、ビジネス・コンポーネントの開発者は、ビュー・オブジェクトによって問合せ定義に基づくメタデータがどのように処理されるのかを理解しておく必要があります。この後の説明で、カスタムSQLモードで作成した問合せを編集する場合の操作方法を確認してください。

5.8.5.1 カスタムSQLモードの計算式の属性名

SQL問合せに計算式が含まれている場合は、「ビュー・オブジェクトの作成」ウィザードで列に対してJavaに適した名前を指定する際、SQLの別名を使用します。次の例は、計算式を含むSQL問合せを示しています。

select CUSTOMER_ID, EMAIL,
SUBSTR(FIRST_NAME,1,1)||'. '||LAST_NAME
from CUSTOMERS
order by EMAIL

次の例は、ビュー・オブジェクトの作成ウィザードで列に対してJavaに適した名前を指定する際にSQLの別名USER_SHORT_NAMEを使用した例です。ウィザードには、この計算式から導出された属性名としてUserShortNameが表示されます。

select CUSTOMER_ID, EMAIL,
SUBSTR(FIRST_NAME,1,1)||'. '||LAST_NAME AS USER_SHORT_NAME
from CUSTOMERS
order by EMAIL

5.8.5.2 カスタムSQLモードの属性マッピング支援

ビュー・オブジェクトと基礎になるエンティティ・オブジェクトの自動的な協調は、XMLドキュメントに保存されている正確な属性マッピング・メタデータに依存します。この情報は、ビュー・オブジェクトの属性と、関係するエンティティ・オブジェクトの慣用名の対応する属性を関連付けます。この属性マッピング情報は、通常のエンティティ・ベースのビュー・オブジェクトについては完全に自動的に維持されます。しかし、ビュー・オブジェクトでカスタムSQLモードを使用するときは、SELECTリストに対して行う変更に注意する必要があります。これは、SQL問合せの中で属性マッピングに直接関係する部分です。カスタムSQLモードでも、SELECTリストに対して次のことを行うときは、JDeveloperが属性マッピング・メタデータの維持を引き続きある程度支援します。

- 列別名を変更しない式の並替え
JDeveloperによって、対応するビュー・オブジェクト属性の並替えおよび属性マッピングの維持が行われます。

- 新しい式の追加
JDeveloperによって、新しい式の列別名に基づいた対応名(頭文字が大文字表記)を持つ新しいSQL計算済ビュー・オブジェクト属性が追加されます。

- 式の削除
JDeveloperによって、その式に関連している対応するSQL計算済属性またはエンティティ・マップ済属性が一時属性に変換されます。

ただし、SELECTリストで列別名を変更した場合は、JDeveloperにはそれを検出する方法がなく、古い列式を削除して別の名前で新しい列式を追加したかのように扱われます。

問合せのSELECTリストを変更した後は、概要エディタの「属性マッピング」ページで、属性マッピング・メタデータが正しいことを確認してください。このページの表は、標準モードではビュー・オブジェクトに対しては無効になっていますが、カスタムSQLモードのビュー・オブジェクトに対しては有効です。各ビュー・オブジェクト属性について、対応するSQL列別名を表で確認できます。「ビュー属性」列のセルをクリックすると、ドロップダウン・リストが表示され、エンティティ・マップ・ビュー属性が対応する必要のある適切なエンティティ・オブジェクト属性を選択できます。

注意:

ビュー属性がSQL計算属性または一時属性の場合は、それを示す「SQL」アイコンの付いた対応する属性が「ビュー属性」列に表示されます。これらのタイプの属性は、基礎となるエンティティ・オブジェクトと関連していないため、エンティティ属性関連情報は必要ありません。

5.8.5.3 カスタムSQLモードのカスタム編集

ビュー・オブジェクトに対するカスタムSQLモードを無効にすると、SELECT句とFROM句は再び導出された状態に戻ります。その際、SQL文に対するカスタム編集が失われることを伝える警告が表示されます。失われてもかまわない場合は、この警告を確認すると、オブジェクトのSQL問合せがデフォルトに戻ります。

5.8.5.4 カスタムSQLモードでのSQL式の変更

Productsビュー・オブジェクトで、SQL式がSUBSTR(NAME,1,10)と定義されたShortensという名前のSQL計算属性について考えます。このビュー・オブジェクトをカスタムSQLモードに切り替えると、「選択」テキスト・ボックスに次の例のようなSQL問合せが表示されます。

SELECT Products.PROD_ID,
Products.NAME,
Products.IMAGE,
Products.DESCRIPTION,
SUBSTR(NAME,1,10) AS SHORT_NAME
FROM PRODUCTS Products

Shortens属性の属性定義に戻り、「SQL式」フィールドをSUBSTR(NAME,1,10)からSUBSTR(NAME,1,15)に変更すると、ビュー・オブジェクトのXMLドキュメントに変更が保存されます。ただし、「選択」テキスト・ボックスのSQL問合せは元の式のままになることに注意してください。これは、JDeveloperではカスタムSQL文のテキストの変更が試行されないためです。カスタムSQLモードでは、開発者がすべてを制御します。JDeveloperは、開発者がカスタムSQL文に対して行うある種の変更の結果としてメタデータの調節を試みますが、逆の処理は行いません。したがって、ビュー・オブジェクト・メタデータを変更しても、カスタムSQL文はそれを反映するために更新されません。

したがって、カスタムSQL文自体で式を更新する必要があります。完全に行うには、属性メタデータおよびカスタムSQL文の両方で変更する必要があります。これにより、後でカスタムSQLモードを無効に切り替えることがあっても、自動的に導出されるSELECTリストに正しいSQL導出式が含まれるようになります。

注意:

カスタムSQLモードのビュー・オブジェクトのビュー・オブジェクト・メタデータを大量に変更する必要がある場合は、カスタマイズした問合せのテキストを一時バックアップ・ファイルにコピーすると、SQL文に対して及ぼす影響を手作業で変換する必要がありません。次に、ビュー・オブジェクトのカスタムSQLモードを無効にし、変更が失われることを伝える警告を確認できます。この時点で、JDeveloperは新しく行われたメタデータの変更に基づいて、正しく生成されたSQL文を再び導出します。最後に、再度カスタムSQLモードを有効にして、SQLのカスタマイズを再適用します。

5.8.5.5 カスタムSQLモードでのエンティティ属性を変更するSQL計算

エンティティ・マップ済の属性データの変更されたバージョンを表示する必要がある場合は、適切な式を含む新しいSQL計算属性を導入して処理します。カスタムSQLモードでは、エンティティ・マップ済属性に対応するSELECTリスト式を編集する場合は、データを取得する際に属性の値を変更するSQL計算をSQL文に導入しないでください。

SQL文にSQL計算を導入した場合に発生する問題を説明するために、次の例に示すProductsという単純なエンティティ・ベースのビュー・オブジェクトに対する問合せを考えてみます。

SELECT Products.PROD_ID,
Products.NAME,
Products.IMAGE,
Products.DESCRIPTION
FROM PRODUCTS Products

製品の問合せの名前の先頭10文字のみを表示するよう、名前列を制限するものとします。これを行う正しい方法は、ShortNameなどのSUBSTR(Products.NAME,1,10)のような式の新しいSQL計算フィールドを導入することです。その上で避ける必要があるのは、次の例に示すように、ビュー・オブジェクトをカスタムSQLモードに切り替え、エンティティにマップされたNAME列のSELECTリストの式を変更して、SQL計算式を導入することです。

SELECT Products.PROD_ID,
SUBSTR(Products.NAME,1,10) AS NAME,
Products.IMAGE,
Products.DESCRIPTION
FROM PRODUCTS Products

この代替方法は、最初はうまくいくように見えます。実行時には、名前の値が意図したとおりに切り捨てられます。しかし、行を変更すると、基礎となるエンティティ・オブジェクトは、行をロックしようとして次の処理を行います。

- SELECT FOR UPDATE文を発行し、行をロックしようとしてすべての列を取得します。

- エンティティ・オブジェクトは、行のロックに成功すると、データベースから最後に取得されてエンティティ・キャッシュに格納されているすべての一時属性の元の値と、ロック操作の間にデータベースから取得した属性の値を比較します。

- いずれかの値が異なっていると、次のエラーがスローされます。

(oracle.jbo.RowInconsistentException)
JBO-25014: Another user has changed the row with primary key [...]

システムをテストしているユーザーが1人だけでも、実行時にこのようなエラーが発生する場合は、カスタムSQLビュー・オブジェクトに、エンティティ・マップされた属性の選択値を変更したSQL関数を導入したことが原因であると考えられます。前の例では、導入したSUBSTR(Products.NAME,1,10)関数によって、Name属性の選択された元の値が切り捨てられます。行ロックSQL文は、NAME列の値を選択するときに、値全体を選択します。これにより、前の例で示した比較が失敗し、別のユーザーが行を変更したというファントム・エラーが発生します。

カスタムSQLモードでSQL関数を適用し、エンティティ・マップ済属性に対して取得された値を切り捨てたり変更したりすると、NUMBER値やDATE値の属性でも同じことが発生します。

5.8.5.6 カスタムSQLモードのSQL文の書式設定

ビュー・オブジェクトをカスタムSQLモードに変更すると、そのXMLドキュメントは、別々のXML属性に問合せの一部を格納する状態から、問合せ全体を1つの<SQLQuery>要素に保存する状態に変更されます。問合せはXML CDATAセクションにラップされて、複雑な問合せを理解しやすくするために開発者が行った可能性のある行の書式設定を保持します。

5.8.5.7 カスタムSQLモードの問合せ句

カスタムSQLビュー・オブジェクトが次のような場合:

- 概要エディタの「問合せ」ページの「ORDER BY」フィールドに設計時に指定されたORDERBY句を含む場合

- setWhereClause()またはsetOrderByClause()を使用して実行時に適用される動的なWHERE句またはORDER BY句を含む場合

このような場合、問合せは句を適用する前にインライン・ビューにネストされます。たとえば、カスタムSQL問合せが次の例のように定義されているものとします。

select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME
from CUSTOMERS
union all
select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME
from INACTIVE_CUSTOMERS

実行時に、email = :TheUserEmailのような追加のWHERE句を設定すると、ビュー・オブジェクトは元の問合せを次の例のようにインライン・ビューにネストします。

SELECT * FROM(
select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME
from CUSTOMERS
union all
select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME
from INACTIVE_CUSTOMERS) QRSLT

そして、ビュー・オブジェクトにより動的なWHERE句の条件が最後に追加され、データベースで確認される最終的な問合せは次の例のようになります。

SELECT * FROM(
select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME
from CUSTOMERS
union all
select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME
from INACTIVE_CUSTOMERS) QRSLT
WHERE email = :TheUserEmail

元の問合せが複雑で、SQLのUNION、INTERSECT、MINUSまたは複数の問合せを単一の結果に結合する他の演算子を含んでいる可能性があるため、カスタムSQL問合せの場合は一般にこのような問合せのラッピングが必要です。このような場合、実行時に追加のWHERE句を問合せテキストの最後に単純に付加したのでは、予想外の結果が生成される可能性があります。たとえば、UNIONで結合された複数の文の最後の文にのみ適用される可能性があります。元の問合せをそのままインライン・ビューにネストすることで、ビュー・オブジェクトは、元の問合せがどれほど複雑であっても、元の問合せの結果をフィルタ処理するために追加のWHERE句が正しく使用されることを保証します。

5.8.5.8 実行時のインライン・ビュー・ラッピング

カスタムSQLビュー・オブジェクトはインライン・ビュー・ラッピングされるので、動的に追加されるWHERE句は、元の問合せのSELECTリストの列のみを参照できます。このような制限を回避する必要がある場合は、setNestedSelectForFullSql(false)を呼び出すことで、インライン・ビュー・ラッピングの使用を無効にできます。

5.8.5.9 依存オブジェクトに対するカスタムSQLの影響

ビュー・オブジェクトを含むビュー・リンクをすでに作成した後や、ビュー・オブジェクトを拡張する他のビュー・オブジェクトを作成した後に、そのビュー・オブジェクトの問合せをカスタムSQLモードに変更すると、図5-27の警告が表示されます。この警告には、これらの依存コンポーネントでSQL文がまだ正しい問合せを反映していることを確認するよう示されます。

図5-27 依存コンポーネントの確認を促す事前注意

たとえば、カスタムSQLモードが使用されるようにOrdersVOビュー・オブジェクトを変更する場合、そのビュー・オブジェクトはOrdersByStatusVOビュー・オブジェクトによって拡張されているため、変更された親コンポーネントの拡張が現在も論理的には問合せに反映されていることを、拡張されたコンポーネントで確認する必要があります。

5.8.5.10 ビュー・オブジェクト問合せの自動リフレッシュに対するカスタムSQLの影響

カスタムSQLモードでビュー・オブジェクト問合せ文を作成し、Oracle Database変更通知を使用した自動問合せ更新を有効にした場合、問合せ文で問合せ結果変更通知との互換性をテストする必要があります。ビュー・オブジェクト概要エディタの「問合せ」ページで「テストおよび説明」ボタンをクリックして、「問合せのテスト」ダイアログで問合せをテストできます。「問合せのテスト」ダイアログの「変更通知」タブで、変更通知に対して問合せを登録できるかどうかを確認します。問合せ文に互換性がない場合は、Oracle Database問合せ結果の変更通知登録要件の要求に従って問合せを改訂する必要があります。詳細は、「ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法」を参照してください。

5.8.5.11 カスタムSQLモードの属性のSQLタイプ

JDeveloperでは、カスタムSQLモードで自動作成されたビュー・オブジェクトの属性にマップされた列のSQL型の推測を試みます。属性の「型」プロパティは、VARCHAR2列の長さ情報やNUMBER列の精度およびスケール情報も含めて、列のSQL型を記録します。ただし、一部のSQL式では、推測値がデフォルトでVARCHAR2(255)になります。

このような型の属性に対して正しい長さがわかっている場合は、「型」の値を更新してその長さを反映します。たとえば、図5-28でState属性に対する「型」として示されているVARCHAR2(20)は、最大文字数が20文字であることを意味しています。NUMBER列の場合、小数点以下7桁の精度と2桁のスケールを持つ属性について、NUMBER(7,2)の「型」を示します。

パフォーマンスに関するヒント

それぞれのSQL式では、データベースの記述から通知される列の長さを制御できます。それには、既存の式に対してSUBSTR()関数を使用します。たとえば、SUBSTR(yourexpression, 1, 15)と指定すると、データベースからの記述により、JDeveloperに列の最大長が15文字であることが通知されます。

図5-28 SQLで導出された属性の「詳細」セクションのカスタム属性設定

エンティティ・ベースのビュー・オブジェクトの場合は、エンティティ・オブジェクト用に表示される概要エディタの「属性」ページの「詳細」セクションで「型」プロパティを編集する必要があります(「データ型の長さ、精度およびスケールの指定方法」を参照)。

5.9 名前付きビュー基準の処理

ビュー基準により、ビュー・オブジェクト・コレクションの行に関するフィルタ情報を指定できます。ビュー基準オブジェクトは1つ以上のビュー基準グループの行セットであり、この属性にはビュー・オブジェクト内の属性がミラーリングされます。ビュー基準の定義には、ターゲット・ビュー・オブジェクトのWHERE句を拡張するための問合せ条件が含まれています。ただし、ビュー・オブジェクトの問合せ文で定義されたWHERE句がビュー・オブジェクトのすべてのインスタンスに適用されるのとは異なり、ビュー基準の問合せ条件は特定のビュー・オブジェクト・インスタンスに追加されます。そのため、ターゲット・ビュー・オブジェクトの個々の属性に適用される問合せ条件を使用することで、ターゲット・ビュー・オブジェクト定義に特定の使用方法を作り出すことができます。

ビュー基準定義では、Query-By-Example演算子がサポートされるため、ユーザーはOrderId > 304などの条件を入力できます。

「ビュー基準の編集」ダイアログでは、ビュー基準を作成し、それをビュー・オブジェクト定義の一部として保存すると、名前付きビュー基準として表示されます。特定のビュー・オブジェクトに対してビュー基準を定義する場合は、概要エディタの「ビュー基準」ページを使用します。設計時に定義するビュー基準は、実行時に結果のフィルタリングが必要となる次のようなシナリオで使用されます。

- ターゲット・ビュー・オブジェクトの属性に対するエンド・ユーザーによる値の指定を可能にするQuery-By-Example検索フォームをサポートする場合。
たとえば、エンド・ユーザーは、顧客名の値および日付を入力することによって、CustomerOrdersビュー・オブジェクトの行が表示されるWebページで結果をフィルタリングできます。Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルに表示される名前付きビュー基準とADFビジネス・コンポーネントのデータ・コントロールを基に、検索フォームを容易に作成できます。「データ・コントロール」パネルに表示される名前付きビュー基準の利用方法の詳細は、「問合せ検索フォームの作成」を参照してください。

- アプリケーションが非キー属性を使用した行参照を実行する目的で使用する行検索操作をサポートする場合。
たとえば、一般に、行のキー値(多くの場合ID)がわからなくてもエンド・ユーザーが行を更新できるようにしておくほうが適切です。このような場合は、ビュー基準に適用する行検索により、ユーザー名やユーザーの電子メール・アドレスなどの識別しやすい属性値を使用した行の特定をサポートします。詳細は、「行検索の使用」を参照してください。

- エンド・ユーザーが(UIにLOVコンポーネントとして表示される)1つの属性リストから選択できる値リスト(LOV)コンポーネントをフィルタリングする場合。
Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルに表示されるビュー・オブジェクトの属性を基に、LOVコントロールを容易に作成できます。「データ・コントロール」パネルに表示されるLOV有効属性の利用方法の詳細は、「選択リストの作成」を参照してください。

- ビュー・アクセッサ結果のフィルタリングのため、ビュー基準が適用されているビュー・アクセッサを使用して属性値を検証する場合。
ビュー・アクセッサのバリデータを作成する方法の詳細は、「ビュー・アクセッサによって指定された属性値に対する検証方法」を参照してください。

- ビュー・インスタンスごとに一意のビュー基準が適用されている単一のビュー・オブジェクト定義からアプリケーション・モジュールのデータ・モデルを作成する場合。
ビュー基準によって変更される単一のビュー・オブジェクトの問合せは、アプリケーション全体で共有する必要がある参照データで有効です。この場合は、ベース・ビュー・オブジェクトの定義によってデータベース内の参照表に対して問合せが行われ、ビュー基準によって参照表のTYPE列が設定され、これによってアプリケーション固有のビューが定義されます。ベース・ビュー・オブジェクトの定義に対して作成するビュー基準によってデータ・モデル内にビュー・インスタンスを定義する方法は、「ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法」を参照してください。

さらに、ビュー基準ではAPIが完全にサポートされているため、ビュー基準の作成およびビュー・オブジェクトへの適用をプログラムによって実行できます。

5.9.1 名前付きビュー基準を宣言的に作成する方法

実行時に宣言問合せに適用することに加えて、ビュー基準には多くの使用方法があります。すべての使用方法では、名前付きビュー基準定義は、個々のビュー・オブジェクト結果をフィルタリングするために指定する属性要件のセットで構成されます。使用できるビュー基準定義の機能は、その意図する使用方法によって異なります。

フィルタリングするビュー・オブジェクトに対してビュー基準を定義するには、概要エディタでそのビュー・オブジェクトを開き、「ビュー基準」ページの「作成」ボタンをクリックします。専用のエディタ(「ビュー基準の作成」ダイアログ)では、ターゲット・ビュー・オブジェクトの対応するSQL列名ではなく、属性名を使用してWHERE句を作成できます。名前付きビュー基準は、1つのビュー・オブジェクトに対して複数定義できます。

「ビュー基準の作成」ダイアログを使用して名前付きビュー基準を作成する場合は、その前に、「名前付きビュー基準の処理」で説明している使用方法を確認します。この章を参照すると、「ビュー基準の作成」ダイアログの適切な機能の使用方法の事前把握に役立ちます。たとえば、ビュー基準を作成して、検索フォームの検索可能属性を指定すると、ビュー基準条件により属性(ビュー・オブジェクトの属性のサブセット)の単純リストが定義され、ユーザーに提示されますが、ビュー基準定義ではUIヒント(モデルレベル・プロパティ)を指定して検索フォームにおけるこれらの属性の動作を制御することが必要です。「ビュー基準の作成」ダイアログにより、定義するビュー基準のために選択した個別のタブ付きページにすべてのUIヒントが表示されます。一方、ビュー・インスタンスをデータ・モデルで指定するためにビュー基準を対象とする場合、複雑な問合せフィルタ条件を任意に定義できますが、「ビュー基準の作成」ダイアログによって表示されるUIヒント機能を無視できます。

ビュー基準の定義はそれぞれ、次の要素で構成されています。

- 任意の数のビュー基準グループまたは現在のビュー・オブジェクトに対して定義されている別の名前付きビュー基準への任意の数の参照。

- 属性名、属性に適した演算子およびオペランドで構成される任意の数のビュー基準アイテム(ビュー基準グループ別)。オペランドには、フィルタの値が定義されている場合はリテラル値か、または、属性のプロパティ値へのドット表記アクセスを含むスクリプト式がオプションで利用可能なバインド変数を使用できます。
式の記述には、Groovyスクリプト言語を使用します(「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照)。

ビュー基準を定義する場合は、フィルタリングされた結果のソースを制御します。フィルタリングされたビュー・オブジェクトの結果は、次のいずれかに制限できます。

- データベース問合せ結果のみ。

- ビュー・オブジェクト問合せのメモリー内の結果のみ。たとえば、ユーザーが追加した新規の行。

- データベースおよびビュー・オブジェクト問合せのメモリー内の結果の両方。

データベース表とビュー・オブジェクトのメモリー内の結果の両方でフィルタリングを実行する場合、トランザクションで作成されており、データベースのコミット前である行もフィルタリングできます。

「ビュー基準の編集」ダイアログで作成するビュー基準の式では、論理積により、選択した基準アイテム(または基準グループ)とその前にあるアイテム(またはグループ)を式の中でどのように結合するかを指定できます。

- AND結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。それぞれのビュー基準アイテムを追加する場合は、この結合がデフォルトになります。

- OR結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。ビュー基準グループに対しては、この結合がデフォルトになります。

また、ビュー・リンクされたディテール・ビューに対する基準に基づいて現在のビュー・オブジェクトの行をフィルタリングする場合は、ネストされたビュー基準を作成できます。ネストされたビュー基準グループは、任意の数のネストされたビュー基準アイテムで構成されます。ネストされたビュー基準を使用すると、様々なビュー基準アイテムの論理積をより詳細に制御できます。ネストされた基準では、その親ビュー基準グループの中で基準を満たしている行が制限されます。たとえば、給与がSalary > 3000という基準を満たし、かつ所属部署がDeptNo = 10またはDeptNo = 20という基準を満たしている従業員のリストを問い合せる場合があります。この場合、1つの項目Salary > 3000を含む第1のグループを使用してビュー基準と、2つの項目DeptNo = 10およびDeptNo =20を含む第2のグループを使用してネストされたビュー基準を定義できます。

始める前に:

ビュー基準を使用できる方法に関する知識があると役立ちます。実行する使用方法は、名前付きビュー基準を作成するためのベスト・プラクティスに影響を与えます。サポート対象の使用方法の詳細は、「名前付きビュー基準の処理」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

- ビュー基準がオペランドでバインド変数を使用する場合は、「ビュー・オブジェクト定義にビュー基準のバインド変数を追加する方法」の説明に従ってバインド変数を作成します。

名前付きビュー基準を定義するには:

1. 「アプリケーション」ウィンドウで、名前付きビュー基準を作成するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビュー基準」ナビゲーション・タブをクリックし、「新規ビュー基準の作成」ボタンをクリックします。

3. 「ビュー基準の作成」ダイアログで、ビュー基準の名前を入力し、アプリケーション内での用途を識別できるようにします。

4. 「問合せ実行モード」ドロップダウン・リストで、ビュー基準によってビュー・オブジェクトの問合せ結果をどのようにフィルタリングするかを決定します。

フィルタリングのビュー基準は、ビュー・オブジェクト問合せにより指定されたデータベース表、問合せにより生成されたメモリー内の行セット、またはデータベース表とメモリー内の結果の両方に制限できます。

適用したビュー・リンクの一貫性の結果として作成された行を含める場合は、「両方」を選択することが適切です。この場合は、最初のフェッチの後にメモリー内フィルタリングが実行されます。ビュー・リンクの一貫性の詳細は、「同じエンティティに基づくビュー・オブジェクトでの新しい行の一貫性の保持」を参照してください。

5. 「基準の定義」タブで、次の追加ボタンのいずれかをクリックして、ビュー基準を定義します。

- 単一の基準アイテムを追加するには、「アイテムの追加」を選択します。エディタによって、現在のグループまたは選択したビュー基準の下の階層にアイテムが追加されます。デフォルトでは、アイテムを追加するたびに、エディタによって次の属性が選択され、基準アイテムが定義されます。属性は、ビュー・オブジェクト問合せで定義されている属性に変更できます。

- 新しいグループを追加して、構成する基準アイテムをそのグループに追加するには、「グループの追加」を選択します。新しいグループを追加すると、エディタによって階層にOR結合が挿入されます。この結合は必要に応じて変更できます。

- 定義するビュー基準を追加するには、「基準の追加」を選択します。この選択は、ビュー・オブジェクト定義にすでに存在する名前付き基準を追加するかわりになります。新しいビュー基準を追加すると、エディタによって階層にAND結合が挿入されます。この結合は必要に応じて変更できます。別のビュー基準を追加するたびに、階層で現在選択しているビュー基準の下に新しいビュー基準がエディタによってネストされます。階層のルート・ノードでは、現在編集中の名前付きビュー基準が定義されます。
UIデザイナによりビュー基準から作成される検索フォームでは、直接ネストされたビュー基準を使用できません。検索フォームで使用するネストされた式の定義の詳細は、「ネストされたビュー基準の式に関する必知事項」を参照してください。

- ビュー・オブジェクトで定義されているビュー基準を追加するには、「名前付き基準の追加」を選択します。名前付き基準は、ビュー基準を定義しているビュー・オブジェクトの概要エディタに表示される必要があります。

6. ビュー基準階層のビュー基準アイテム・ノードを選択し、追加したノードを「基準アイテム」セクションで定義します。

- 基準アイテムで、必要な「属性」を選択します。デフォルトでは、リストの最初のノードがエディタによって追加されます。
現在編集中のビュー・オブジェクトにビュー・リンクが存在する場合は、必要に応じて、ネストされたビュー基準をインラインで追加できます。リンク先ビュー・オブジェクトの名前は、「属性」ドロップダウン・リストに表示されます。ビュー・オブジェクトを選択すると、ビュー・リンクの関係に従ってネストされたビュー基準のビュー基準アイテムに基づいて、ビュー基準をフィルタリングできます。たとえば、EmpVOがPaymentOptionsVOにリンクされており、PaymentOptionsVOのビュー基準定義に、リンク先ビュー・オブジェクトのAddressVOが表示されるとします。図5-29に示すように、ネストされたビュー基準を定義することにより、CustomerId基準アイテムで指定した現在の顧客のCountryId属性に基づいて、支払いオプションをフィルタリングできます。

図5-29 ネストされたビュー基準を指定した「ビュー基準の編集」ダイアログ

- 必要な「演算子」を選択します。
リストには、選択した属性またはビュー・オブジェクトに適切な演算子のみが表示されます。ビュー・オブジェクトの場合、exists演算子はオペランドとして定義(または参照)するビュー基準に適用されます。 String型およびDate型属性の場合、「次の間にある」および「次の間にない」演算子では、範囲を定義するために2つのオペランド値を指定する必要があります。Date型属性の場合、日付または日付の範囲をテストする演算子を選択できます(YYYY-MM-DDの書式で入力された日付値について)。たとえば、2010年12月16日の場合、2010-12-16と入力します。

JDeveloperでは、IN演算子をサポートしていません。ただし、「プログラムによるビュー基準の作成方法」で説明するように、APIを使用すると、IN演算子でビュー基準を作成できます。

7. 選択したビュー基準アイテムで、必要な「オペランド」を選択します。

- 属性に値を指定したり、Query-by-Example検索フォームに対するユーザー指定の検索フィールドにデフォルト値を定義する場合は、「リテラル」を選択します。ビュー基準でユーザー・インタフェースの問合せ検索フォームを定義する場合は、「値」フィールドが空のままでも構いません。この場合は、ユーザーが値を指定します。検索フィールドのデフォルト値として機能する値を指定して、ユーザーがオーバーライドできるようにすることもできます。「値」フィールドに指定する値には、ワイルドカード文字の*または%を含めることができます。

- バインド変数を使用して実行時に値を決定する場合は、「バインド変数」を選択します。ビュー基準にすでに変数が定義されている場合は、「パラメータ」ドロップダウン・リストから選択します。そうでない場合は、「新規」をクリックして「新規変数」ダイアログを表示し、そこでビュー基準に対する新しいバインド変数の名前を指定します。
ビュー基準で使用する既存のバインド変数をドロップダウン・リストから選択する場合は、ビュー・オブジェクトの問合せまたはビュー基準に対して定義されたバインド変数を選択できます。この2つのバインド変数セットの違いは、問合せのバインド変数(概要エディタの「問合せ」ページで定義)は一般にビュー・オブジェクトの問合せ文内で使用されるものであるため、ビュー基準で定義されたバインド変数より多様な検証のユースケースをサポートすることです。一般に、ビュー基準の場合は、概要エディタの「ビュー基準」ページで定義されたバインド変数を常に選択します。

ビュー基準でバインド変数とリテラルを使用するケースの詳細は、「ビュー基準のバインド変数に関する必知事項」を参照してください。

8. 定義する各アイテム、グループまたはネストされたビュー基準に対して、必要に応じてデフォルト設定の論理積を変更し、アイテムの結合方法を指定します。

- AND結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。それぞれのビュー基準アイテムまたはネストされたビュー基準を追加する場合は、この結合がデフォルトになります。

- OR結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。ビュー基準グループに対しては、この結合がデフォルトになります。

9. 次のいずれかを実行して、ビュー基準の定義が有効かどうかを検証します。

- 「実行計画」をクリックし、生成されたビュー基準のWHERE句を視覚的に検証します。

- 「テスト」をクリックし、JDeveloperでWHERE句が有効かどうかを検証します。

10. 実行時に指定される値が大文字か小文字かに基づいた、大/小文字を区別した属性のフィルタリングを無効にする場合は、「大/小文字を区別しない」が選択された状態のままにします。

基準アイテムには、定義したリテラル値またはエンド・ユーザーが入力するランタイム・パラメータを使用できます。このオプションは、String型の属性に対してのみサポートされています。デフォルトでは、大/小文字の区別のある検索は使用できません。

11. 「検証」ドロップダウン・リストで、生成されたWHERE句での属性値の比較の際にビュー基準アイテムを必須とするかオプションとするかを指定します。

- 「選択的に必須」を選択すると、ビュー基準アイテムに基準値が入力されず、かつ基準値を持つ基準アイテムが同じビュー基準グループに少なくとも1つ存在する場合、WHERE句では実行時にそのビュー基準アイテムが無視されます。それ以外の場合は、例外がスローされます。

- 「オプション」を選択すると、値がNULLでない場合にのみビュー基準(または検索フィールド)がWHERE句に追加されます。新規の各ビュー基準アイテムに対してデフォルトの「オプション」を選択すると、NULL値に対しても例外は生成されません。

- 「必須」を選択すると、基準アイテムに値が入力されなかった場合は、WHERE句が実行されず例外がスローされます。

12. ビュー基準でオペランドとしてバインド変数を使用する場合に、IS NULL条件がWHERE句で生成されるかどうかを指定します。バインド変数の検証に「オプション」を選択した場合のみ、このフィールドが有効になります。

- 実行時にバインド変数値が入力されていない場合でもビュー基準が結果を返すようにする場合、「Null値の無視」を選択したままにしておきます(デフォルト)。たとえば、子リストの制御属性としてcountryIDを取得するバインド変数を通じて、ユーザーが国と州(または郡)のカスケード・リストを表示できるようにするビュー基準を定義するとします。この場合、ビュー基準実行のデフォルトの動作では、ユーザーが親LOVで選択を行わない(countryIdフィールドが空)と、すべての州のリストが戻されます。生成されたWHERE句は、(((CountryEO.COUNTRY_ID =:bvCountryId) OR (:bvCountryId IS NULL)))のようになります(null値のテストにより、バインド変数が設定されない場合でも、子リストに結果が表示されることが保証されます)。検証が「必須」または「選択的に必須」に設定されている場合、ビュー基準は値を必要とするため、このNULL値を無視するオプションは無効になります。

- 実行時にバインド変数値が入力されない場合にビュー基準がnullの結果を返すようにする場合、「Null値の無視」の選択を解除します。カスケード・リストの例の場合、ビュー基準実行では、ユーザーが選択を行わなずcountryIdフィールドが空だと、州は戻されません。このケースでは、生成されたWHERE句は、((CountryEO.COUNTRY_ID=:bvCountryId))のようになります(null値のテストは行われず、問合せはnull値のバインド変数で正常に動作します)。NULL値とオプションで組み合せる検証は、必須のバインド変数の場合にのみ可能であることに注意してください。必須のバインド変数とは、概要エディタの「問合せ」ページで定義され、問合せのWHERE句で使用されるものです。
検証の設定を「必須」または「選択的に必須」にした場合もNULL値の条件が削除されますが、選択解除した「Null値の無視」設定をこれらと組み合せて使用することで、異なるユースケースをサポートできます。これらの設定の相互作用の詳細は、「ビュー基準のバインド変数に関する必知事項」を参照してください。

13. 「OK」をクリックします。

14. 定義したビュー基準条件の中にバインド変数を参照するものがある場合は、「ビュー基準」ページでそのバインド変数を選択し、「詳細」セクションの「値」タブをクリックして、必要に応じてそのバインド変数のデフォルト値を指定します。

- 実行時に式から値が決定されるようにするには、Groovyスクリプト言語の式を入力し、値タイプ「式」を選択して、「値」フィールドに式を入力します。

- デフォルト値を定義する場合は、値のタイプ「リテラル」を選択し、「値」フィールドにリテラル値を入力します。

15. バインド変数の値がユーザー・インタフェースから定義されるようにする場合は、「更新可能」を選択したままにします。

「更新可能」チェック・ボックスでは、エンド・ユーザーがユーザー・インタフェースを使用してバインド変数の値を変更できるようになるかどうかを制御します。バインド変数が更新可能でない(プログラムでもエンド・ユーザーの操作でも変更できない)場合は、「更新可能」の選択を解除します。

16. 「ビュー基準」ページで「UIヒント」タブをクリックし、「ラベル」、「フォーマットの種類」、「フォーマット」マスクなどのヒントを指定します。

名前付きバインド変数の値を入力できる検索ページなどのユーザー・インタフェースを作成する場合、ビュー・レイヤーではバインド変数のUIヒントが使用されます。フォーマットは、Date型または任意の数値データ型で定義されたバインド変数でのみサポートされることに注意してください。

17. ビュー基準定義で参照する予定のないバインド変数を作成した場合は、そのバインド変数を選択して「削除」ボタンをクリックします。

図5-30に示すように、カーソルをバインド変数名フィールド上に移動して、ビュー基準内でバインド変数名が指定されていることを確認します。JDeveloperでは、参照されていないバインド変数は、名前フィールドの枠線がオレンジ色で表示されることによってわかるようになっています。

図5-30 バインド変数の参照について確認するためのオレンジ色の枠線

5.9.2 名前付きビュー基準の作成時の処理

JDeveloperの 「ビュー基準の作成」ダイアログで、ビュー基準を簡単に作成し、名前付き定義として保存できます。これらの名前付きビュー基準定義により、ターゲット・ビュー・オブジェクトの宣言的設定を表すXMLドキュメント・ファイルにメタデータが追加されます。定義すると、名前付きビュー基準はビュー・オブジェクトの概要エディタの「ビュー基準」ページに名前で表示されます。

ビュー基準を表示するには、「アプリケーション」ウィンドウで目的のビュー・オブジェクトを開き、開いたビュー・オブジェクトのXMLファイルを選択後、「構造」ウィンドウを開いて、「ビュー基準」ノードを開きます。ビュー・オブジェクトのそれぞれのビュー基準定義には、「ビュー基準の作成」ダイアログで定義したグループの数に対応する、1つ以上の<ViewCriteriaRow>要素が含まれます。次の例は、<ViewCriteria>定義であるFindByProductNameCriteriaと、開発者が定義した製品検索フォームをバインド変数:bvProductNameを使用して定義する単一の<ViewCriteriaRow>を含む、ProductsVO.xmlファイルを示しています。開発者が定義した検索フォームの動作をカスタマイズするために選択したUIヒントは、<ViewCriteria>定義に<CustomProperties>要素の属性として表示されます。ビュー基準の固有のUIヒントの詳細は、「ビュー基準にユーザー・インタフェース・ヒントを設定して検索フォームをサポートする方法」を参照してください。

<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="ProductsVO"
... >
<SQLQuery>
...
</SQLQuery>
...
<ViewCriteria
Name="FindByProductNameCriteria"
ViewObjectName="oracle.summit.model.views.ProductsVO"
Conjunction="AND">
<Properties>
<CustomProperties>
<Property
Name="mode"
Value="Basic"/>
<Property
Name="autoExecute"
Value="false"/>
<Property
Name="showInList"
Value="true"/>
<Property
Name="displayName"
Value="Find Products By Name"/>
<Property
Name="displayOperators"
Value="InAdvancedMode"/>
<Property
Name="allowConjunctionOverride"
Value="true"/>
</CustomProperties>
</Properties>
<ViewCriteriaRow
Name="vcrow87">
<ViewCriteriaItem
Name="ProductName"
ViewAttribute="ProductName"
Operator="CONTAINS"
Conjunction="AND"
Value=":bvProductName"
UpperColumns="1"
IsBindVarValue="true"
Required="Optional"/>
</ViewCriteriaRow>
</ViewCriteria>
...
</ViewObject>

また、ビュー・オブジェクトを作成し、アプリケーション・モジュールでインスタンスとして指定する場合、JDeveloperにより、アプリケーション・モジュールに含まれるコレクション(ビュー・インスタンス)をカプセル化するデータ・コントロールが自動的に作成されます。次に、これらのコレクションと定義済のビュー基準が「データ・コントロール」パネルに移入されます(「「データ・コントロール」パネルでのビュー・オブジェクトの表示」を参照)。

5.9.3 ビュー基準のバインド変数に関する必知事項

バインド変数を使用して定義したビュー基準フィルタは、実行時にその値を取得します。この機能は、様々なユーザー・インタフェース・シナリオで有益です。特定の使用例をサポートできるように、表5-1に示した「検証」および「Null値の無視」設定の組合せを覚えるようにしてください。

表5-1 ビュー基準のバインド変数オプションの使用例

検証

Null値の無視

ユースケース

注意

Optional

True (デフォルト)

親LOV値がオプションのカスケード値リスト(LOV)を構成します。

検索フォームのオプション検索フィールドを生成します。

この組合せでは、SQL問合せ(ProductName = :bind) OR (:bind IS NULL)が生成されます。

カスケードLOVで使用する場合、親LOVが選択されないと子LOVのすべての行が戻されます。

検索の実行前に、すべての行が返されないようにしておくために、リテラル・オペランド(バインド変数ではない)を持つビュー基準アイテムタイプの使用をお薦めします。ビュー基準に対するバインド変数(オプションで検証を使用するもの)が解決されない場合、結果としてすべての行が返されます。

Optional

False(この組合せを実現するには、問合せのWHERE句で定義された必須のバインド変数の選択が必要)

親LOV値が必須のカスケードLOVを構成します。

この組合せでは、SQL問合せ(ProductName = :bind)が生成されます。

カスケードLOVで使用する場合、親LOVが選択されないと子LOVの行が戻されません。

ユーザーが検索フィールドを空白のままにすると、検索ではこのフィールドが明示的にnullに設定されている行を見つけようとするため、検索フォームではこの組合せを使用しないでください。これを行うには、詳細検索モードで「IS NULL」演算子を明示的に選択するほうが効率的です。

Required

False(デフォルトであり、この組合せの場合は変更不可)

検索フォームの必須検索フィールドを生成します。

この組合せでは、SQL問合せProductName = :bindが生成されます。

親LOVが選択されない場合、検証エラーが発生するため、カスケードLOVに対してこの設定を使用しないでください。

NULL以外の検索結果の存在を検索実行前に確認するために、リテラル・オペランド(バインド変数ではない)を持つビュー基準アイテム・タイプの使用をお薦めします。ビューに対するバインド変数(必須で検証を使用するもの)が解決されない場合、結果として行は返されません。

5.9.4 ネストされたビュー基準の式に関する必知事項

ビュー基準からUIデザイナによって作成される検索フォームでは、すべてのタイプのネストされた式が動作するわけではありません。特に、検索フォームでは、直接ネストされたビュー基準が含まれる式がサポートされていません。このタイプのネストされた式では、1つのビュー基準を別のビュー基準の直接の子として定義します。それ自体がビュー基準の子である基準アイテムの子としてビュー基準をネストしたネストされた式は、問合せ検索フォームでサポートされています。ビュー基準を使用した検索フォームの作成の詳細は、「暗黙的ビュー基準と名前付きビュー基準」を参照してください。

5.9.5 ビュー基準にユーザー・インタフェース・ヒントを設定して検索フォームをサポートする方法

ビュー・オブジェクト・コレクションに対して作成された名前付きビュー基準は、Webページ・デザイナがQuery-By-Example検索フォームを作成する際に使用できます。Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルから名前付きビュー基準を選択して、Fusion Webアプリケーション用の検索フォームを作成します。Webページの検索フォームでは、「データ・コントロール」パネルで選択した名前付きビュー基準に最初にバインドされるADF Faces問合せ検索コンポーネントが利用されます。実行時、エンド・ユーザーは、「データ・コントロール」パネルに表示されるその他すべての名前付きビュー基準の中からいずれかを選択できます。エンド・ユーザーが検索フォームで選択できる名前付きビュー基準は、開発者定義のシステム検索と呼ばれます。問合せコンポーネントでは、「保存済の検索」ドロップダウン・リストに、これらのシステム検索が自動的に表示されます。検索フォームの作成およびADF問合せ検索コンポーネントの使用方法の詳細は、「問合せ検索フォームの作成」を参照してください。

注意:

デフォルトでは「ビュー基準の編集」ダイアログで作成するすべての名前付きビュー基準が、「データ・コントロール」パネルに表示されます。「ビュー基準の編集」ダイアログの「UIヒント」ページで「リストに表示」オプションが選択されているかぎり、名前付きビュー基準は開発者定義のシステム検索として使用可能であるとみなされます。作成する名前付きビュー基準が検索フォームを介してエンド・ユーザーに表示されないようにする場合は、ダイアログで「リストに表示」オプションの選択を解除します。たとえば、LOV有効属性に対してのみ名前付きビュー基準を作成する場合は、「リストに表示」オプションの選択を解除する必要があります。

開発者定義のシステム検索はモデル・プロジェクト内で作成されるため、「ビュー基準の編集」ダイアログの「UIヒント」ページでは、問合せコンポーネントにおける個々の名前付きビュー基準の実行時の使用方法に対して、デフォルト・プロパティを指定できます。実行時の問合せコンポーネントの動作は、次のシステム検索プロパティに何を選択するかによって決まります。

検索リージョン・モード: 問合せコンポーネントでシステム検索を表示する際のモードを選択します。「基本」モードでは、表示された検索基準フィールドをエンド・ユーザーが動的に変更することはできませんが、それ以外は使用できる機能は「詳細」モードとまったく同じです。「ビュー基準の編集」ダイアログで定義するビュー基準のデフォルトのモードは、「基本」モードです。

自動的に問合せ: 名前付きビュー基準に関連付けられた問合せを実行し、その結果をWebページに表示する場合に選択します。このオプションが有効になっている開発者定義のシステム検索は、エンド・ユーザーが問合せコンポーネントの「保存済の検索」リストから選択すると、自動的に実行されます。Webページ・デザイナの意向により、エンド・ユーザーがフォーム上の検索基準値を送信するまで以前の結果を更新しないようにする場合は、選択を解除します。また、タスク・フローから検索フォームが起動される場合は、このオプションの選択が解除されていると検索フォームは空白になり、選択されると移入されます。このオプションは、デフォルトでは、「ビュー基準の編集」ダイアログで定義するビュー基準に対して無効になっています。

「演算子の表示」: 問合せコンポーネントでエンド・ユーザーにビュー基準アイテムの演算子の選択フィールドを表示する方法を指定します。ユーザーが詳細から基本に問合せコンポーネントのモードを変更したときに、問合せコンポーネントにより表示される演算子は、「演算子の表示」の設定方法によって異なることに気をつけてください。問合せコンポーネントは、ユーザーが演算子の表示を常に表示に設定して両方のモードで演算子の完全なリストを表示できるようにした場合にのみ、2つのモード間でユーザーの選択を保持します。ただし、「演算子の表示」を詳細モードに設定して、詳細モードでのみ完全な演算子リストを表示する場合は、選択を行って基本モードに切り替えた後に、演算子はビュー基準で定義されたデフォルトに戻るため、ユーザーの選択が変更されたように見えます。ユーザーが定義した演算子だけを使用してビュー基準を実行する場合は、表示しないを選択します(この場合、演算子の完全なリストは基本モードでも詳細モードでも表示されません)。検索フォームには問合せのWHERE句で使用される任意のバインド変数が検索基準として表示されますが、「演算子の表示」設定ではこれらのバインド変数式に関連付けられた演算子の表示はサポートされません。

すべてに一致といずれかに一致を表示: 問合せコンポーネントで「すべてに一致」および「いずれかに一致」ラジオ・ボタンをエンド・ユーザーに表示する場合に選択します。これらのボタンが表示されている場合、エンド・ユーザーはこれらのボタンを使用して検索条件を変更し、すべてのビュー基準アイテムに一致またはいずれかのビュー基準アイテムに一致する結果を戻すことができます。これは、ビュー基準アイテム間にAND結合(すべてに一致)またはOR結合(いずれかに一致)を適用するのと同等です。定義されているビュー基準アイテム論理積を使用してビュー基準を実行する場合は、選択を解除します。この場合、問合せコンポーネントにラジオ・ボタンの選択は表示されません。

表示されたモード: ビュー基準ツリー・コンポーネントから個々のビュー基準アイテムを選択し、さらに、エンド・ユーザーが問合せコンポーネントのモードを「基本」と「詳細」の間で切り替える際に、選択したアイテムが検索フォームに表示されるようにするかどうかを選択します。それぞれのビュー基準アイテムに対するデフォルト設定は「すべて」です。このデフォルトのモードの場合、問合せコンポーネントでは、「基本」と「詳細」のどちらのモードでもアイテムをレンダリングできます。個々のビュー基準アイテムの「表示されたモード」設定を変更すると、実行時の検索フォームの外観をカスタマイズできます。たとえば、「基本」モードで簡略化した検索フォームをエンド・ユーザーに表示し、すべてのビュー基準アイテムのある検索フォームを表示できる「詳細」モードを予約する必要があるとします。この場合は、問合せコンポーネントの「基本」モードで表示しないビュー基準アイテムに対しては「詳細」を選択します。一方、選択したビュー基準アイテムを「基本」モードでのみレンダリングする場合は、「基本」を選択します。検索フォームで「基本」モードでも「詳細」モードでも表示しないアイテムに対しては「なし」を設定します。

注意:

ユーザーに公開しないアイテムがビュー基準に含まれている場合、「表示されたモード」設定に「なし」を使用して、検索フォームでそのアイテムを非表示にします。たとえば、ログインした顧客のカート内にある製品を検索するためのビュー基準は作成できますが、ユーザーが顧客IDを変更して別の顧客のカート内にある製品を表示することのないようにする必要があります。このようなシナリオでは、名前付きバインド変数を使用して、顧客IDに対応するビュー基準アイテムを現在の顧客IDに設定します。バインド変数定義で変数が任意または更新不可に指定されている場合がありますが、UIヒント・プロパティの「表示」が「非表示」に設定されている場合は、「表示されたモード」の設定によってのみ、検索フォームに値が表示されるかどうかが決まります。

「複数の値の選択をサポート」: エンド・ユーザーが問合せコンポーネントに表示される各基準アイテムの複数の選択を行えるようにする場合に選択します。このオプションは、ビュー基準アイテムによって指定されるビュー・オブジェクト属性に、値リスト(LOV)が定義されている場合にのみ有効になります。また、エンド・ユーザーが演算子equal toまたはnot equal toを選択している場合、複数の選択は問合せコンポーネントによってのみサポートされます。たとえば、基準アイテムで属性CountryIdが指定され、この属性が関連付けられたLOVによってアクセスされる国IDのリストから値を導出する場合、このオプションを選択すると、エンド・ユーザーは複数の国を選択して問合せを送信できます。実行時に、問合せコンポーネントはエンド・ユーザーが選択した演算子に基づいて適切な問合せ句を生成します。

「表示幅」: この基準アイテムを問合せコンポーネントに表示するコントロールにより使用される文字幅を入力します。基準アイテムの対応ビュー・オブジェクト属性用に定義された表示幅コントロール・ヒントを入力値によりオーバーライドします。たとえば、編集フォームでは属性コントロール・ヒントにおけるテキストの長さは1024まで可能ですが、検索フォームでは基準アイテムのフィールドにおける文字の長さを20文字に制限する場合があります。

「リストに表示」: ビュー基準を開発者がシードした問合せとして定義する場合に選択します。定義する名前付きビュー基準が、検索フォームを表示する問合せ検索コンポーネントで使用されないようにする場合は、選択を解除します。ここでの選択により、使用可能なシステム検索の問合せ検索コンポーネントの「保存済の検索」ドロップダウン・リストに、名前付きビュー基準が表示されるかどうかが決まります。このオプションは、デフォルトでは、「ビュー基準の編集」ダイアログで定義するビュー基準に対して有効になっています。

表示名: 問合せコンポーネントの「保存済の検索」ドロップダウン・リストに表示するシステム検索の名前を入力するか、「...」ボタン(編集フィールドの右)をクリックしてビュー・オブジェクトに関連付けられているリソース・バンドルからメッセージ文字列を選択します。表示名は、エンド・ユーザーがシステム検索を識別する名前になります。リソース・バンドルからメッセージ文字列を選択すると、この文字列に対応するメッセージ・キーがビュー・オブジェクト定義ファイルに保存されます。実行時に、UIはこの文字列を特定し、エンド・ユーザーのロケール設定とローカライズされたリソース・バンドルのメッセージ・キーに基づいて表示します。表示名が指定されていない場合、デフォルトでは、「ビュー基準の編集」ダイアログに表示されるビュー基準の名前が使用されます。

ADF問合せ検索コンポーネントで使用するシステム検索を作成する場合は、「ビュー基準の編集」ダイアログの「UIヒント」ページで、「リストに表示」を選択します。エンド・ユーザーの検索フォームにビュー基準を表示しない場合は、「リストに表示」の選択を解除します。

始める前に:

ビュー基準に関する知識が役立つ場合があります。詳細は、「名前付きビュー基準の処理」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

- 「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー基準を作成します。

ユーザー・インタフェースに使用する名前付きビュー基準をカスタマイズするには:

1. 「アプリケーション」ウィンドウで、システム検索として使用する名前付きビュー基準を定義しているビュー・オブジェクトをダブルクリックします。

2. 概要エディタで「ビュー基準」ナビゲーション・タブをクリックし、システム検索で許可する名前付きビュー基準を選択して、「選択したビュー基準の編集」ボタンをクリックします。

3. 「ビュー基準の編集」ダイアログで、「UIヒント」タブをクリックして「リストに表示」が選択されていることを確認します。

この選択により、問合せコンポーネントによってシステム検索が「保存済の検索」ドロップダウン・リストに表示されるかどうかが決まります。

4. 問合せコンポーネントの「保存済の検索」ドロップダウン・リストに追加するシステム検索に対して、わかりやすい表示名を入力します。

何も入力しない場合、問合せコンポーネントでは、「ビュー基準の編集」ダイアログに表示されるビュー基準の名前が使用されます。

5. エンド・ユーザーが「保存済の検索」ドロップダウン・リストからシステム検索を選択するたびに、検索結果が自動的に問合せコンポーネントに表示されるようにする場合は、「自動的に問合せ」を有効にします。

デフォルトでは、検索結果は表示されません。

6. 必要に応じて、「基準アイテムUIのヒント」を適用して、エンド・ユーザーが検索フォームのモードを「基本」と「詳細」の間で切り替える際に、問合せコンポーネントで個々の基準アイテムをレンダリングするかどうかをカスタマイズします。

デフォルトでは、システム検索で定義したビュー基準アイテムはすべて、どちらかのモードで表示されます。

レンダリングされた基準アイテムがDate型の場合、対応するビュー・オブジェクト属性のUIヒントも定義する必要があります。「属性固有のUIヒントの追加方法」の説明に従って、ビュー・オブジェクト属性の「フォーマット・タイプ」のヒントを「簡単な日付」に設定し、フォーマット・マスクを適切な値に設定します。これによって検索フォームで日付値を使用できるようになります。

7. 「OK」をクリックします。

5.9.6 Oracle ADFモデル・テスターを使用してビュー基準をテストする方法

ビュー・オブジェクトに追加したビュー基準をテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。

参照するビュー・オブジェクト・インスタンスをOracle ADFモデル・テスターで開くと、「ビュー基準」ダイアログが表示されます(図5-31を参照)。ダイアログで、1つ以上のビュー基準グループから構成されるビュー基準を作成できます。

単一のビュー基準グループから基準属性を適用するには、ブラウザの「ビュー基準の指定」ツールバー・ボタンをクリックして、目的のフィールドにQuery-By-Example基準を入力し、「検索」をクリックします。

Oracle ADFモデル・テスターを使用してビュー基準をテストするには:

1. 「アプリケーション」ウィンドウで、目的のアプリケーション・モジュールおよびビュー・オブジェクトを含むプロジェクトを開きます。

2. アプリケーション・モジュールを右クリックし、「実行」を選択します。

3. Oracle ADFモデル・テスターで、フィルタリングするビュー・インスタンスをダブルクリックし、ビュー・インスタンスを右クリックして「検索」を選択します。

または、ビュー・インスタンスをダブルクリックした後、「ビュー基準の指定」ツールバー・ボタンをクリックしてビュー基準をテストできます。

4. 「ビュー基準」ダイアログで、次のいずれかのタスクを実行します。

- プロジェクトのビュー・オブジェクトに追加したビュー基準をテストするには、リストから選択して「検索」をクリックします。「非定型基準」パネルに入力した追加の基準は、フィルタに追加されます。

- 単一のビュー基準グループから非定型基準属性をテストするには、ビュー基準に必要な値を入力し、「検索」をクリックします。たとえば、図5-31は、名前が"S"で始まり、居住地がCA(カリフォルニア州)であるすべての顧客を返すためのフィルタを示しています。

- 追加の非定型ビュー基準グループをテストするには、「OR」タブをクリックして、それぞれが固有のビュー基準グループを表すページを切り替えるために表示される追加タブを使用します。「検索」をクリックすると、Oracle ADFモデル・テスターによって、結果をフィルタリングするビュー基準が作成されて適用されます。

図5-31 ADFモデル・テスターの「ビュー基準」ダイアログ

5.9.7 ビュー基準を使用して現在のユーザーのビュー・オブジェクトをフィルタリングする方法

Groovy式adf.context.getSecurityContext().getUserName()を使用して、ビュー・インスタンス・フィルタの現在のユーザーの指定に使用する名前付きバインド変数のデフォルト値を設定できます。具体的には、プロジェクトのデータ・モデルのビュー・オブジェクト・インスタンスをフィルタリングするために定義する名前付きビュー基準で、バインド変数を使用できます。たとえば、名前付きバインド変数UserPrincipalは、図5-32に示すように、概要エディタの「ビュー基準」ページで定義されています。adf.context.getSecurityContext()methodName()のような式を使用してセキュリティ・コンテキストにアクセスするGroovy式をビジネス・コンポーネントに記述できます。たとえば、このセキュリティ・コンテキストからは、ユーザー名や特定のロールに所属しているかなど、現在のユーザーに関する情報にアクセスできます。ADFセキュリティ・コンテキストの詳細は、「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。

図5-32 UserPrincipalバインド変数の設定に使用されるGroovy式

CustomerVOビュー・オブジェクトでは、AuthenticatedUserByPrincipalCriteriaビュー基準も定義されています。このビュー基準で定義されているPersonsVOのPrincipalName属性のフィルタには、バインド変数userPrincipalによって値が指定されます。この例では、バインド変数userPrincipalが定義され、「更新可能」が有効にされています。これにより、ビュー基準は、ADFセキュリティ・コンテキストから実行時に取得する値を設定できるようになります。バインド変数は、PersonsVOビュー・オブジェクトのSQLのWHERE句で使用されないため、「必須」フィールドの選択が解除されています。これによりこの値は任意になり、バインド変数が解決されない場合でも実行時例外はスローされません。

CustomerVOで慣用名AuthenticatedUserのビュー定義が指定されているデータ・モデルでは、名前付きバインド変数を含むビュー基準AuthenticatedUserByPrincipalCriteriaがビュー慣用名の実行時フィルタとして定義されています。プロジェクトのデータ・モデルのビュー・インスタンスの作成の詳細は、「アプリケーション・モジュールに追加するビュー・オブジェクト・インスタンスのカスタマイズ」を参照してください。

5.9.8 プログラムによるビュー基準の作成方法

次の例は、フィルタリングするCustomerListビュー・オブジェクト・インスタンスを検索し、このビュー・オブジェクトの属性のビュー基準を作成して、このビュー基準をビュー・オブジェクトに適用するmain()メソッドを示しています。

ビュー基準をプログラムによって作成するには、次の基本的な手順に従います(SummitADF_Examplesワークスペースのサンプルoracle.summit.model.viewobjects.ProgrammaticVOCriteria.javaからの例である、次の例を参照)。

1. フィルタリングするビュー・オブジェクト・インスタンスを検索します。

2. ビュー・オブジェクトに対するビュー基準行セットを作成します。

3. ビュー基準を使用して、1つ以上の空のビュー基準グループを作成します。

4. 適切なビュー基準グループでフィルタリングする属性値を設定します。
または、ビュー基準グループのensureCriteriaItem()、setOperator()およびsetValue()の各メソッドを使用して、フィルタ対象となる属性名、比較演算子および値を個別に設定します。

5. ビュー基準グループをビュー基準行セットに追加し、ビュー基準をビュー・オブジェクトに適用します。

6. 問合せを実行します。

新しく適用されたビュー基準は次の実行でビュー・オブジェクトのSQL問合せにのみ適用されるため、問合せの実行の最後の手順は重要です。

public class ProgrammaticVOCriteria {
public static void main(String[] args) {

// get the application module
String amDef = "oracle.summit.model.viewobjects.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);

// 1. Find the View Object you want to filter
ViewObject customerList = am.findViewObject("SCustomerView1");

// Work with your appmodule and view object here

// iterate through all the rows first, just to see to full VO results
customerList.executeQuery();
while (customerList.hasNext()) {
Row customer = customerList.next();
System.out.println("Customer: " + customer.getAttribute("Name") + "
State: " + customer.getAttribute("State"));

System.out.println("********* Set View Criteria and requery *********");

// 2. Create a view criteria row set for this view object
ViewCriteria vc = customerList.createViewCriteria();

// 3. Use view criteria row set to create at least one view criteria group
ViewCriteriaRow vcr1 = vc.createViewCriteriaRow();

// 4. Set attribute values to filter on
ViewCriteriaItem vci = vcr1.ensureCriteriaItem("State");
vci.setOperator("=");
vci.setValue("TX");

// 5. Add the view criteria group to the view criteria row set
vc.add(vcr1);

// 6. Apply the view criteria to the view object
customerList.applyViewCriteria(vc, true);

// 7. Execute the query
customerList.executeQuery();

// Iterate throught the rows to see the new results
while (customerList.hasNext()) {
Row customer = customerList.next();
System.out.println("Customer: " + customer.getAttribute("Name") + "
State: " + customer.getAttribute("State"));
}

System.out.println("********* Set View Criteria and requery *********");

// set the attribute to a different value
vcr1.setAttribute("State", "CA");

// Add the view criteria group to the view criteria row set
vc.add(vcr1);

// Apply the view criteria to the view object
customerList.applyViewCriteria(vc);

// Execute the query
customerList.executeQuery();

// iterate throught the rows to see the new results
while (customerList.hasNext()) {
Row customer = customerList.next();
System.out.println("Customer: " + customer.getAttribute("Name") + "
State: " + customer.getAttribute("State"));
}

Configuration.releaseRootApplicationModule(am, true);
}
}

ProgrammaticVOCriteria.javaテスト・クライアントを実行すると、問合せが実行されるたびに1つずつレコード・セットが生成されます。最初の問合せには基準が適用されておらず(すべてのレコードを表示)、2番目の問合せには1つの基準セットがあります(TXのレコードのみを表示)。3番目の問合せではこの基準が変更されています(CAのレコードのみを表示)。

Customer: Great Gear   State: TX
Customer: Acme Outfitters   State: TX
Customer: Athena's Closet   State: TX
Customer: Big John's Sports Emporium   State: CA
Customer: Perfect Purchase   State: CA
Customer: Father Gym's   State: CA
...
********* Set View Criteria and requery *********
Customer: Great Gear   State: TX
Customer: Acme Outfitters   State: TX
Customer: Athena's Closet   State: TX
...
********* Set View Criteria and requery *********
Customer: Big John's Sports Emporium   State: CA
Customer: Perfect Purchase   State: CA
Customer: Father Gym's   State: CA
...

5.9.9 実行時に行われる処理: ビュー基準がビュー・オブジェクトに適用される方法

1つ以上のビュー基準グループを含むビュー基準をビュー・オブジェクトに適用すると、次に実行されるときに、ビュー基準グループに移入したQuery-By-Example基準に対応する追加のWHERE句条件を使用してビュー・オブジェクトのSQL問合せが拡張されます。図5-33のように、複数のビュー基準グループを含むビュー基準を適用すると、ビュー・オブジェクトでは、各ビュー基準グループの非NULLの例の基準属性に基づいて付加的な実行時WHERE句を追加することにより、設計時のWHERE句が拡張されます。

ビュー基準機能の当然の結果として、新規ビュー基準を適用(または既存のビュー基準を削除)するたびに、ビュー・オブジェクトのSQL問合せのテキストが効率的に変更されます。SQL問合せの変更は、データベースが次に実行されるときに文を再解析する原因になります。「Query-By-Example基準に関する必知事項」で説明するように、この再解析は省略できるため、ビュー基準のパフォーマンスが向上します。

図5-33 ビュー・オブジェクトでビュー基準グループを付加的な実行時WHEREフィルタに自動的に変換

5.9.10 ビュー基準APIに関する必知事項

「ビュー基準の編集」ダイアログでサポートされていないタスクを実行する必要がある場合は、ビュー基準APIを使用できます。たとえば、複数のビュー基準グループを使用した複合検索条件の変更、NULL属性値を持つ行の検索、大/小文字を区別しない検索、有効なビュー基準のクリアはいずれも、プログラムによって実行できます。

5.9.10.1 ビュー基準での属性名の参照

setWhereClause()メソッドを使用すると、ビュー・オブジェクトに動的WHERE句を追加できます(「ビュー・オブジェクトのデフォルト行セットを使用した操作のViewObjectインタフェース・メソッド」を参照)。また、次のようなリテラル・データベース列名を含む文字列を渡す場合にもsetWhereClause()を使用できます。

vo.setWhereClause("LAST_NAME LIKE UPPER(:NameToFind)");

これに対して、ビュー基準のメカニズムを使用する場合は、「プログラムによるビュー基準の作成方法」の説明に従って、かわりに次のようにビュー・オブジェクト属性名を参照する必要があります。

ViewCriteriaItem vc_item1 = vc_row1.ensureCriteriaItem("UserId");
vc_item1.setOperator(">");
vc_item1.setValue("304");

ビュー基準の属性値の設定に、過去のリリースのドキュメントに記載されていたvcr.setAttribute("UserId", "> 304")などのメソッド・コールは使用しないでください。

ビュー基準グループは、その後、ビュー・オブジェクトにより、当該の列名を参照する当該のWHERE句条件に変換されます。プログラムで設定するWHERE句は、設計時にビュー・オブジェクト用に定義されたビュー基準のWHERE句で論理積(AND)されます。

5.9.10.2 ビュー基準でのバインド変数の参照

ビュー基準アイテムの値をバインド変数に設定する場合は、次のようにsetIsBindVarValue(true)を使用します。

ViewCriteriaItem vc_item1 = vc_row1.ensureCriteriaItem("UserId");
vc_item1.setIsBindVarValue(true);
vc_item1.setValue(":VariableName");

5.9.10.3 属性がNULLである行の検索

NULLを列に含む行を検索するには、対応するビュー基準グループ属性にIS NULLという値を移入するか、ViewCriteriaItem.setOperator("ISBLANK")を使用します。

5.9.10.4 データ圧縮を使用した行の検索

ビュー基準アイテムの日付値の比較を実行する場合は、次の事前定義済の演算子を使用します。

- BEFORE

- AFTER

- ONORBEFORE

- ONORAFTER

たとえば、値が特定の日付より後のDATE型属性を含む行を検索するには、ViewCriteriaItem.setOperator("AFTER")を使用します。

<、>、<=、>=のような演算子は、日付値に対して不正確な結果を生成する文字列比較を実行するため、使用しないでください。

5.9.10.5 属性値がリストの値に一致する行の検索

列の値が指定する値リストのいずれかの値に一致するすべての行を検索するには、コンマ区切り値リストを使用して対応するビュー基準グループ属性を移入し、IN演算子を使用します。たとえば、IDが204および206に一致するユーザーのリストをフィルタリングするには、次のようにします。

ViewCriteriaItem vci = vcr.ensureCriteriaItem("CustomerId");
vci.setOperator("IN");
vci.setValue(0, 204);
vci.setValue(1, 206);

5.9.10.6 大/小文字を区別しない検索

大/小文字を区別しないで検索するには、区別しない検索を適用するビュー基準グループのsetUpperColumns(true)をコールします。これは、ビュー・オブジェクトのString値の属性に対して生成されたWHERE句条件に影響を与え、COLUMN_NAMEではなくUPPER(COLUMN_NAME)が条件に使用されます。これらのString値の属性に対して提供されるビュー基準グループ属性の値は、大文字であるる必要があります。そでない場合は、条件が一致しません。UPPER()は、条件のみでなく、値に対しても使用できます。たとえば、UPPER(ename) = UPPER("scott")という設定が可能です。

5.9.10.7 有効なビュー基準のクリア

有効な任意のビュー基準をクリアするには、ビュー・オブジェクトでgetViewCriteria()をコールし、remove()メソッドを使用し、削除する基準行のゼロベースのインデックスを渡して、ビュー基準グループをすべて削除します。他のビュー基準グループを再度追加しない場合は、ビュー基準名を渡してビュー・オブジェクトのremoveApplyViewCriteriaName("namedViewCriteria")をコールするのみでも、すべての有効なビュー基準をクリアできます。

5.9.10.8 複数ビュー基準を使用した複合検索条件の変更

複数のビュー基準を追加する場合、ビュー基準のsetConjunction()メソッドをコールして、そのビュー基準に対応する条件とその前のビュー基準に対する条件の間で使用される結合を変更できます。引数として渡す有効な定数は、次のとおりです。

- ViewCriteriaComponent.VC_CONJ_AND

- ViewCriteriaComponent.VC_CONJ_NOT

- ViewCriteriaComponent.VC_CONJ_UNION

- ViewCriteriaComponent.VC_CONJ_OR(デフォルト)

次のようなフィルタ基準を作成するために、NOT値をANDまたはORと組み合せることができます。

( PredicateForViewCriteria1 ) AND (NOT ( PredicateForViewCriteria2 ) )

または

( PredicateForViewCriteria1 ) OR (NOT ( PredicateForViewCriteria2 ) )

複合検索条件を実現する構文には、次のようにJavaのビット単位OR演算子を使用する必要があります。

vc2.setConjunction(ViewCriteriaComponent.VC_CONJ_AND | ViewCriteriaComponent.VC_CONJ_NOT);

パフォーマンスに関するヒント

UNION問合せで索引を活用できる場合は、OR句のかわりにUNION値を使用します。たとえば、ビュー基準でsal > 2000 or job = 'CLERK'が検索される場合、この問合せでは全表スキャンが開始されることがあります。2つの内部ビュー基準の結合として問合せを指定し、データベース表のsalとjobに索引が存在する場合、問合せではこれらの索引を活用でき、問合せのパフォーマンスは大規模なデータ・セットに対して大幅に向上します。

UNION句の制限は、1つのビュー・オブジェクトに対して定義する必要がある点です。つまり、SELECTとFROMリストは、UNION句の複数の内部問合せで同じになります。UNION問合せを指定するには、次のように外部ビュー基準のsetConjunction()をコールします。

vc.setConjunction(ViewCriteriaComponent.VC_CONJ_UNION);

外部ビュー基準には、結果同士が結合される内部問合せが含まれている必要があります。たとえば、次の2つのビュー基準の結合を指定する必要があるとします。

- Job = 'SALESMAN'を検索するビュー基準MyEmpJob

- Sal = 1500を検索するビュー基準MyEmpSalary

これらの2つのビュー基準のUNION問合せを作成するには、次の例に示すコールを作成します。

vcu = voEmp.createViewCriteria();
vcm = voEmp.getViewCriteriaManager();

vcu.setConjunction(ViewCriteria.VC_CONJ_UNION);
vcu.add(vcm.getViewCriteria("MyEmpJob"));
vcu.add(vcm.getViewCriteria("MyEmpSal"));

voEmp.applyViewCriteria(vcu);

このビュー基準を適用すると、JobがSALESMAN、またはSalが1500より大きい行が返されます。

UNIONビュー基準を使用する場合は、適用するビュー基準の1つのみにUNION結合を含めるようにしてください。適用する別のビュー基準は、UNION問合せの各内部問合せに適用されます。

5.9.11 Query-By-Example基準に関する必知事項

次の2つのケースでは、パフォーマンス上の理由から、バインド変数をビュー基準アイテムの値として設定しないようにしてください。

- ビュー基準アイテムの値が選択的に必須として定義されており、NULL以外の値からNULLに変更される特殊な場合
この場合は、NULL以外の値からNULLに変更されるたびに、ビュー基準のSQL文が再生成されます。

- ビュー基準アイテムの値が任意で、そのアイテムが索引列の属性を参照している場合
任意のビュー基準アイテムの場合は、追加のSQL句のOR (:Variable IS NULL)が生成されます。この句は列索引の使用をサポートしません。

これらのいずれかの場合であれば、「ビュー・オブジェクト定義にWHERE句のバインド変数を追加する方法」で説明するように、WHERE句に名前付きバインド変数が含まれるビュー・オブジェクトを使用することにより、パフォーマンスが向上します。

5.10 バインド変数の使用

バインド変数を使用すると、実行時にビュー・オブジェクトまたはビュー基準に属性値を組み込むことができます。バインド変数はすべて、ビュー・オブジェクトのレベルで定義され、次のいずれかの方法で使用されます。

- ビュー・オブジェクトで開いた「ビュー基準の編集」ダイアログでは、バインド変数を選択リストから選択して、ビュー基準に使用する属性値を定義できます。この場合、バインド変数により、ビュー・オブジェクトの行セットのフィルタリングに使用する属性の値を変更できます。ビュー・オブジェクトの行セットのフィルタリングの詳細は、「名前付きビュー基準の処理」を参照してください。
UI開発者定義の検索フォームでビュー基準を使用する場合は、エンド・ユーザーがバインド変数を更新できるようにすることができます。この更新可能オプションを使用する場合、エンド・ユーザーはビュー・オブジェクト問合せに対応する検索フォームに値を入力する必要があります。

- バインド変数をビュー・オブジェクトの問合せのWHERE句に直接入力し、実行ごとに変更される値を組み込むことができます。この場合、バインド変数はSQL文字列内のプレースホルダとして機能し、SQL文字列自体のテキストを変更することなく、実行時に簡単にその値を変更できます。問合せは変更しないため、データベースでは、同一の解析済問合せ表現を複数の実行で効率的に再使用できるようになり、結果としてアプリケーションの実行時パフォーマンスが向上します。

ビュー・オブジェクト実行の際に必ず必要とされる、問合せのWHERE句のバインド変数とは対照的に、ビュー基準に対して定義するバインド変数は、ビュー基準が適用される場合にのみ必要になります。

注意:

アプリケーションでは、問合せのWHERE句にフィルタをハードコーディングするのではなく、ビュー基準を使用してビュー・オブジェクトをフィルタリングすることをお薦めします。ビュー基準を使用すると、検索基準の値に変更があっても、そのたびにビュー・オブジェクトのSQL文のテキストを変更しなくても値の変更ができます。

バインド変数に対しては、デフォルト値を定義するか、属性プロパティ値へのドット表記法によるアクセスが可能なスクリプト式を記述できます。式の記述には、Groovyスクリプト言語を使用します(「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照)。

5.10.1 ビュー・オブジェクト定義にビュー基準のバインド変数を追加する方法

ビュー基準にバインド変数の使用を指定する際は、ビュー・オブジェクト定義にバインド変数を追加する必要があります。ビュー基準定義にバインド変数の使用を追加する場合は、ビュー・オブジェクトにバインド変数定義がないと、そのビュー基準を適用したときにランタイム例外が発生します。バインド変数定義を作成するには、該当のビュー・オブジェクトの概要エディタの「ビュー基準」ページを使用します。エディタで変数を定義すると、バインド変数が実行時に値を受け取ります。この値を定義しないままにすると、NULLになります。デフォルト値であるNULLは、一部のシナリオには適していますが、そうでない場合もあります。NULLでない値が必要な場合は、バインド変数定義にデフォルト値を指定するか、エンド・ユーザーが実行時に値を指定するようにできます(たとえば、問合せ検索フォームの場合は検索基準を使用するなど)。

ビュー基準のバインド変数をビュー・オブジェクトに追加するには、そのビュー・オブジェクトの概要エディタの「ビュー基準」ページを使用します。

始める前に:

バインド変数をビュー・オブジェクトのレベルでサポートすることに関する知識が役立つ場合があります。詳細は、「バインド変数の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

ビュー基準の名前付きバインド変数を定義するには:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビュー基準」ナビゲーション・タブをクリックします。

3. 「問合せ」ページの「バインド変数」セクションで、「新規バインド変数の作成」ボタンをクリックします。

4. 「新規変数」ダイアログで、バインド変数の名前を入力し、データ型を選択します。「OK」をクリックします。

バインド変数はビュー・オブジェクト属性と同じネームスペースを共有するため、既存のビュー・オブジェクト属性名と競合しない名前を指定します。ビュー・オブジェクト属性と同様に、バインド変数名は最初が大文字という規則で作成されますが、必要に応じて名前を変更することもできます。

5. 必要に応じて、「ビュー基準」ページの「詳細」セクションで、「値」タブをクリックし、バインド変数のデフォルト値を指定します。

- 実行時に式から値が決定されるようにするには、Groovyスクリプト言語の式を入力し、値タイプ「式」を選択して、「値」フィールドに式を入力します。たとえば、現在のユーザーに基づいてビュー・インスタンスをフィルタリングするバインド変数を定義できます(「ビュー基準を使用して現在のユーザーのビュー・オブジェクトをフィルタリングする方法」を参照)。

- デフォルト値を定義する場合は、値のタイプ「リテラル」を選択し、「値」フィールドにリテラル値を入力します。

- 名前付きバインド変数にデフォルト値を指定しない場合、変数は実行時にNULLにデフォルト設定され、そのビュー基準では行が返されなくなります。

6. バインド変数の値がユーザー・インタフェースから定義されるようにする場合は、「更新可能」を選択したままにします。

「更新可能」チェック・ボックスでは、エンド・ユーザーがユーザー・インタフェースを使用してバインド変数の値を変更できるようになるかどうかを制御します。バインド変数が更新可能でない(プログラムでもエンド・ユーザーの操作でも変更できない)場合は、「更新可能」の選択を解除します。

7. 「ビュー基準」ページで「UIヒント」タブをクリックし、「ラベル」、「フォーマットの種類」、「フォーマット」マスクなどのヒントを指定します。

名前付きバインド変数の値を入力できる検索フォームなどのユーザー・インタフェースを作成する場合、ビュー・レイヤーではバインド変数のUIヒントが使用されます。フォーマットは、Date型または任意の数値データ型で定義されたバインド変数でのみサポートされることに注意してください。

8. ビュー・オブジェクトのビュー基準に定義したバインド変数を参照します。

バインド変数は、実行時に参照するか、ビュー・オブジェクトの問合せ定義の中で使用する必要があります。「バインド変数の名前に関連するエラー」で説明するように、概要エディタで構成したバインド変数で、参照されていないものがあると、実行時エラーが発生します。

9. ビュー基準で名前を指定したり、プログラムで参照したりする予定のないバインド変数を作成した場合は、そのバインド変数を選択して「削除」ボタンをクリックします。

図5-35に示すように、カーソルをバインド変数名フィールド上に移動して、ビュー基準内でバインド変数が指定されていることを確認します。JDeveloperでは、参照されていないバインド変数は、名前フィールドの枠線がオレンジ色で表示されることによってわかるようになっています。

図5-34 バインド変数の参照について確認するためのオレンジ色の枠線

5.10.2 ビュー・オブジェクト定義にWHERE句のバインド変数を追加する方法

問合せのWHERE句にバインド変数の使用を指定する際は、ビュー・オブジェクト定義にもバインド変数を追加する必要があります。問合せ文にバインド変数の使用を追加する場合は、ビュー・オブジェクトにバインド変数定義がないと、ランタイム例外が発生します。バインド変数定義を作成するには、該当のビュー・オブジェクトの概要エディタの「問合せ」ページを使用します。エディタで変数を定義すると、バインド変数が実行時に値を受け取ります。この値を定義しないままにすると、NULLになります。デフォルト値であるNULLは、一部のシナリオには適していますが、そうでない場合もあります。NULLでない値が必要な場合は、バインド変数定義にデフォルト値を指定するか、実行時に値を設定できます(「実行時に既存のWHERE句のバインド変数値を設定する方法」を参照)。

WHERE句のバインド変数をビュー・オブジェクトに追加するには、そのビュー・オブジェクトの概要エディタの「問合せ」ページを使用します。必要な数のバインド変数を定義できます。

注意:

「バインド変数の名前に関連するエラー」で説明するように、概要エディタで構成したバインド変数で、参照されていないものがあると、実行時エラーが発生します。ビュー・オブジェクト定義でこれに名前を付けるか、プログラムで参照する場合を除いて、すべてのバインド変数定義を概要エディタから削除します。

始める前に:

バインド変数をビュー・オブジェクトのレベルでサポートすることに関する知識が役立つ場合があります。詳細は、「バインド変数の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

WHERE句の名前付きバインド変数を定義するには:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「問合せ」ナビゲーション・タブをクリックします。

3. 「問合せ」ページの「バインド変数」セクションで、「新規バインド変数の作成」ボタンをクリックします。

4. 「新規変数」ダイアログで、バインド変数の名前を入力し、データ型を選択します。「OK」をクリックします。

バインド変数はビュー・オブジェクト属性と同じネームスペースを共有するため、既存のビュー・オブジェクト属性名と競合しない名前を指定します。ビュー・オブジェクト属性と同様に、バインド変数名は最初が大文字という規則で作成されますが、必要に応じて名前を変更することもできます。

5. 必要に応じて、「問合せ」ページの「詳細」セクションで、「値」タブをクリックし、バインド変数のデフォルト値を指定します。

- 実行時に式から値が決定されるようにするには、Groovyスクリプト言語の式を入力し、値タイプ「式」を選択して、「値」フィールドに式を入力します。

- デフォルト値を定義する場合は、値のタイプ「リテラル」を選択し、「値」フィールドにリテラル値を入力します。

- 名前付きバインド変数にデフォルト値を指定しない場合、変数は実行時にNULLにデフォルト設定され、その問合せでは行が返されなくなります。これがアプリケーションで意味を持つ場合は、「バインド変数のNULLのデフォルト値」で説明するように、このような場合を処理するSQL関数を使用できます。

6. バインド変数の値がユーザー・インタフェースから定義されるようにする場合は、「更新可能」を選択したままにします。

「更新可能」チェック・ボックスでは、エンド・ユーザーがユーザー・インタフェースを使用してバインド変数の値を変更できるようになるかどうかを制御します。バインド変数が更新可能でない(プログラムでもエンド・ユーザーの操作でも変更できない)場合は、「更新可能」の選択を解除します。

7. 「問合せ」ページで「UIヒント」タブをクリックし、「ラベル」、「フォーマットの種類」、「フォーマット」マスクなどのヒントを指定します。

名前付きバインド変数の値を入力できる検索ページなどのユーザー・インタフェースを作成する場合、ビュー・レイヤーではバインド変数のUIヒントが使用されます。フォーマットは、Date型または任意の数値データ型で定義されたバインド変数でのみサポートされることに注意してください。

8. ビュー・オブジェクトのSQL文に定義したバインド変数を参照します。

バインド変数は、実行時に参照するか、ビュー・オブジェクトの問合せ定義の中で使用する必要があります。「バインド変数の名前に関連するエラー」で説明するように、概要エディタで構成したバインド変数で、参照されていないものがあると、実行時エラーが発生します。

SQL構文によりバインド変数がSELECTリストとWHERE句の両方に表示されるようになりますが、通常はWHERE句の一部としてバインド変数を使用します。たとえば、次の例は、ビュー・オブジェクトの概要エディタの「問合せ」ページで作成したSQL文に導入されるLowUserIdおよびHighUserIdのバインド変数を示しています。

select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME
from CUSTOMERS
where (upper(FIRST_NAME) like upper(:TheName)||'%'
or  upper(LAST_NAME)  like upper(:TheName)||'%')
and CUSTOMER_ID between :LowUserId and :HighUserId
order by EMAIL

:TheNameや:LowUserIdなどのようにコロンを名前の前に付けることによって、SQL文でバインド変数を参照していることに注意してください。任意の順序でバインド変数を参照し、SQL文の中で必要な回数のみ繰り返すことができます。

9. ビュー・オブジェクトのSQL問合せで名前を指定したり、プログラムで参照したりする予定のないバインド変数を作成した場合は、そのバインド変数を選択して「削除」ボタンをクリックします。

図5-35に示すように、カーソルをバインド変数名フィールド上に移動して、ビュー・オブジェクトの問合せ内でバインド変数が指定されていることを確認します。JDeveloperでは、参照されていないバインド変数は、名前フィールドの枠線がオレンジ色で表示されることによってわかるようになっています。

図5-35 バインド変数の参照について確認するためのオレンジ色の枠線

5.10.3 名前付きバインド変数の追加時の処理

ビュー・オブジェクトに1つ以上の名前付きバインド変数を追加すると、これらの変数の値を実行時に簡単に参照および設定する機能を使用できます。各バインド変数の名前、型およびデフォルト値の情報は、ビュー・オブジェクトのXMLドキュメント・ファイルに保存されます。バインド変数に対してUIヒントを定義した場合、この情報はビュー・オブジェクトの他のUIヒントとともにビュー・オブジェクトのコンポーネント・メッセージ・バンドル・ファイルに保存されます。

概要エディタでは、定義されてもビュー・オブジェクトの問合せで使用されていないバインド変数の変数名の周囲にオレンジ色の警告ボックスが表示されます。問合せ文またはビュー基準定義から参照されていないバインド変数は必ず削除してください。「バインド変数の名前に関連するエラー」で説明するように、ビュー・オブジェクトの問合せの実行時に1つ以上のバインド変数定義が参照されないままになっていると、実行時エラーが発生します。

5.10.4 名前付きバインド変数のテスト方法

Oracle ADFモデル・テスターでは、ビュー・オブジェクトに対する名前付きバインド変数の値を対話型で検査および変更ができ、名前付きバインド・パラメータを使用する場合にアプリケーション・モジュールのデータ・モデルを簡単に試すことができます。データ・モデルを編集してOracle ADFモデル・テスターを実行する方法の詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

データ・ビュー・ページに結果を表示するために、Oracle ADFモデル・テスターでビュー・オブジェクトを初めて実行する場合、図5-36に示すように、「バインド変数」ダイアログが表示されます。

「バインド変数」ダイアログでは次のような操作が可能です。

- リストから選択した特定のバインド変数の名前、デフォルト値および現在の値を表示します。

- 対応する「値」フィールドを更新してバインド変数の値を更新してから「OK」をクリックし、バインド変数値を設定して問合せを実行します。

- ツールバーの「バインド・パラメータの編集」ボタン(アイコンが:idのように表示されます)を使用して、現在のデータ・ビュー・ページに表示されているビュー・オブジェクトに対するバインド変数を検査および設定します。

- 「バインド変数」リストにラベル・テキスト・ヒントを表示するか、それぞれのフォーマット・マスクを使用して「値」属性をフォーマットすることにより、UIヒントが正しく設定されていることを確認します。

図5-36 Oracle ADFモデル・テスター内のバインド変数の設定

「バインド変数」ダイアログでバインド変数を定義する際、「必須」チェック・ボックスの選択を解除すると、ビュー基準をテストし、必要に応じてバインド変数に値を指定できます。一方、「必須」チェック・ボックスが選択されている場合(デフォルト)、Oracle ADFモデル・テスターでバインド変数の値を1つ指定する必要があります。Oracle ADFモデル・テスターでは、SQL文で使用しているバインド変数の値の指定では解決されないビュー・オブジェクトに対しては、実行時と同じ例外がスローされます。

5.10.5 実行時に名前付きバインド変数を含むWHERE句を追加する方法

ビュー・オブジェクトのsetWhereClause()メソッドを使用して、実行時にフィルタリングの句をさらに追加できます。この実行時に追加されるWHERE句条件は、設計時に生成された条件のかわりに使用せずに、既存の設計時WHERE句に追加して問合せ結果をさらに絞り込みます。動的に追加された句が、アプリケーションの有効期間中に変化することのある値を参照するときは、WHERE句条件にリテラル値を連結するのではなく、常に名前付きバインド変数を使用してください。

たとえば、表のCUSTOMER_TYPE_CODE列の値に基づいて実行時にビュー・オブジェクトCustomerListをさらにフィルタリングすると仮定します。さらに、CUSTOMER_TYPE_CODE = 'CUST'である行、またはCUSTOMER_TYPE_CODE = 'SUPP'である行を検索する予定であると仮定します。コード行はわずかに少なくなりますが、次の例は好ましくありません。それは、同じCUSTOMER_TYPE_CODE列の異なる2つの値を問い合わせるためだけにWHERE句が2回変更されているからです。

// Don't use literal strings if you plan to change the value!
vo.setWhereClause("customer_type_code = 'CUST'");
// execute the query and process the results, and then later...
vo.setWhereClause("customer_type_code = 'SUPP'");

かわりに、次の例のような、実行時に定義する名前付きバインド変数を参照するWHERE句条件を追加する必要があります。

vo.setWhereClause("customer_type_code = :TheCustomerType");
vo.defineNamedWhereClauseParam("TheCustomerType", null, null);
vo.setNamedWhereClauseParam("TheCustomerType","CUST");
// execute the query and process the results, and then later...
vo.setNamedWhereClauseParam("TheCustomerType","SUPP");

これにより、問い合せる必要があるCUSTOMER_TYPE_CODEの値にかかわらず、SQL文のテキストが同じままになります。問合せテキストが複数の実行全体で同じ状態の場合は、問合せの再解析を行わずに結果がデータベースから戻されます。

これらのテクニックを示している更新済テスト・クライアント・クラスは、次の例のようになります。この場合、結果を数回ループする機能は、別個のexecuteAndShowResults()メソッドにリファクタされています。プログラムでは、最初に付加的なWHERE句のcustomer_id = :TheCustomerIdが追加されてから、後で第2句のcustomer_type_code = :TheCustomerTypeに置換されます。

package devguide.examples.readonlyvo.client;

import oracle.jbo.ApplicationModule;
import oracle.jbo.Row;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;

public class TestClientBindVars {
public static void main(String[] args) {
String        amDef = "devguide.examples.readonlyvo.CustomerService";
String        config = "CustomerServiceLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
ViewObject vo = am.findViewObject("CustomerList");
// Set the two design time named bind variables
vo.setNamedWhereClauseParam("TheName","shelli%");
vo.setNamedWhereClauseParam("HighUserId", 215);
executeAndShowResults(vo);
// Add an extra where clause with a new named bind variable
vo.setWhereClause("customer_type_code = :TheCustomerId");
vo.defineNamedWhereClauseParam("TheCustomerId", null, null);
vo.setNamedWhereClauseParam("TheCustomerId",116);
executeAndShowResults(vo);
vo.removeNamedWhereClauseParam("TheCustomerId");
// Add an extra where clause with a new named bind variable
vo.setWhereClause("customer_type_code = :TheCustomerType");
vo.defineNamedWhereClauseParam("TheCustomerType", null, null);
vo.setNamedWhereClauseParam("TheCustomerType","SUPP");
// Show results when :TheCustomerType = 'SUPP'
executeAndShowResults(vo);
vo.setNamedWhereClauseParam("TheCustomerType","CUST");
// Show results when :TheCustomerType = 'CUST'
executeAndShowResults(vo);
Configuration.releaseRootApplicationModule(am,true);
}
private static void executeAndShowResults(ViewObject vo) {
System.out.println("---");
vo.executeQuery();
while (vo.hasNext()) {
Row curUser = vo.next();
System.out.println(curUser.getAttribute("CustomerId")+" "+
curUser.getAttribute("ShortName"));
}
}
}

ただし、このテスト・プログラムを実行すると、実際には次の例のような実行時エラーが発生することがあります。

oracle.jbo.SQLStmtException: JBO-27122: SQL error during statement preparation.
Statement:
SELECT * FROM (select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME
from PERSONS
where (upper(FIRST_NAME) like upper(:TheName)||'%'
or  upper(LAST_NAME)  like upper(:TheName)||'%')
and PERSON_ID between :LowUserId and :HighUserId
order by EMAIL) QRSLT  WHERE (person_type_code = :TheCustomerType)
## Detail 0 ##
java.sql.SQLException: ORA-00904: "PERSON_TYPE": invalid identifier

PERSONS表にPERSON_TYPE_CODE列は確実に存在していますが、スタック・トレースの## Detail 0 ##の後に表示されている根本原因は、PERSON_TYPE_CODE列が存在しないというデータベースのレポートによるSQL解析エラーです。この問題は、ビュー・オブジェクトが読取り専用問合せの最初の部分で追加実行時WHERE句を適用するためにデフォルトで使用するメカニズムによって発生します。この問題の解決方法の詳細は、「実行時に行われる処理: 動的な読取り専用ビュー・オブジェクトのWHERE句」を参照してください。

5.10.6 実行時に既存のWHERE句のバインド変数値を設定する方法

実行時に名前付きバインド変数を設定するには、ViewObjectインタフェース上でsetNamedWhereClauseParam()メソッドを使用します。JDeveloperで、「リファクタ」→「複製」をメイン・メニューから選択すると、既存のTestClient.javaクラスに基づいてTestClientBindVarsクラスを新規に作成できます(「コマンド行Javaテスト・クライアントの作成方法」を参照)。このテスト・クライアント・クラスでは、コードを数行追加することにより、バインド変数の値を設定できます。たとえば、次の例に示すように、setNamedWhereClauseParam()の引数として、バインド変数HighUserIdおよびTheNameを使用できます。

// changed lines in TestClient class
ViewObject vo = am.findViewObject("CustomerList");
vo.setNamedWhereClauseParam("TheName","alex%");
vo.setNamedWhereClauseParam("HighUserId", 315);
vo.executeQuery();
// etc.

テスト・クライアント・クラスを実行すると、バインド変数によるデータのフィルタリングが行われます。たとえば、前の例のsetNamedWhereClauseParam()メソッドの結果行では、次の結果に示すように、alexという名前に基づく2つの一致のみ表示されます。

303 ahunold
315 akhoo

ビュー・オブジェクトの問合せが実行されるときは必ず、実行時デバッグ診断で、実際のバインド変数値が次の結果の例のように表示されます。

[256] Bind params for ViewObject: CustomerList
[257] Binding param "LowUserId": 0
[258] Binding param "HighUserId": 315
[259] Binding param "TheName": alex%

アプリケーションをデバッグする際、この情報が非常に役立つ場合があります。コードでLowUserIdバインド変数の値が設定されなかったために、設計時にデフォルト値として0(ゼロ)が指定されたことに注意してください。さらに、WHERE句およびバインド変数の周囲でUPPER()関数を使用することにより、TheNameのバインド変数値を使用した照合が大/小文字の区別なしで確実に実行されたことに注意してください。サンプルのコードは、バインド変数値を小文字のaを使用するalex%に設定し、その結果がAlexanderと一致したことを示します。

5.10.7 実行時に行われる処理: 動的な読取り専用ビュー・オブジェクトのWHERE句

実行時に付加的なWHERE句を読取り専用ビュー・オブジェクトに動的に追加する場合、その問合せは付加的なWHERE句を適用する前にインライン・ビューにネストされた状態になります。

たとえば、問合せが次の例のように定義されたと仮定します。

select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME
from PERSONS
where (upper(FIRST_NAME) like upper(:TheName)||'%'
or  upper(LAST_NAME)  like upper(:TheName)||'%')
and PERSON_ID between :LowUserId and :HighUserId
order by EMAIL

実行時に、「実行時に名前付きバインド変数を含むWHERE句を追加する方法」のテスト・プログラムで示すperson_type_code = :TheCustomerTypeのような付加的なWHERE句を設定する場合、次の例のように、フレームワークにより元の問合せがインライン・ビューにネストされます。

SELECT * FROM(
select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME
from PERSONS
where (upper(FIRST_NAME) like upper(:TheName)||'%'
or  upper(LAST_NAME)  like upper(:TheName)||'%')
and PERSON_ID between :LowUserId and :HighUserId
order by EMAIL) QRSLT

そして、フレームワークにより動的なWHERE句の条件が最後に追加され、データベースで確認される最終的な問合せは次の例のようになります。

SELECT * FROM(
select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME
from PERSONS
where (upper(FIRST_NAME) like upper(:TheName)||'%'
or  upper(LAST_NAME)  like upper(:TheName)||'%')
and PERSON_ID between :LowUserId and :HighUserId
order by EMAIL) QRSLT
WHERE person_type_code = :TheCustomerType

元の問合せが複雑で、SQLのUNION、INTERSECT、MINUSまたは複数の問合せを単一の結果に結合する他の演算子を含んでいる可能性があるため、通常はこのような問合せのラッピングが必要です。このような場合、実行時に追加のWHERE句を問合せテキストの最後に付加するだけでは、予想外の結果が生成される可能性があり、たとえば、UNIONで結合された複数の文の最後の文に対してのみ適用されることがあります。元の問合せをそのままインライン・ビューにネストすることで、ビュー・オブジェクトは、元の問合せがどれほど複雑であっても、元の問合せの結果をフィルタ処理するために追加のWHERE句が正しく使用されることを保証します。重要なのは、動的に追加されるWHERE句が、元の問合せで選択されている列しか参照できないことです(ORA-00904エラーにつながります)。

これを解決する最も簡単な方法は、ビュー・オブジェクトの概要エディタの「問合せ」ページで、問合せのSELECTリストの末尾に動的問合せの列名を追加することです。既存のSELECTリストの末尾にカンマを前に付けた新規の列名を追加するだけで、ORA-00904エラーを回避することができ、JDeveloperでは、問合せ文と同期して自動的にビュー・オブジェクトの属性リストが保持されます。または、このような問合せのネストが不要な場合にネストを無効にする方法は、「実行時のインライン・ビュー・ラッピング」を参照してください。

「実行時に名前付きバインド変数を含むWHERE句を追加する方法」で説明するテスト・クライアント・プログラムにより、次の結果が生成されました。

---
116 S. Baida
---
116 S. Baida
---
---
116 S. Baida

5.10.8 名前付きバインド変数に関する必知事項

名前付きバインド変数について知っておく必要のあることがいくつかあります。これには、バインド変数の名前が不一致である場合に表示される実行時エラー、バインド変数のデフォルト値などがあります。

5.10.8.1 バインド変数の名前に関連するエラー

SQL文で参照する名前付きバインド変数のリストは、ビュー・オブジェクトの概要エディタにある「問合せ」ページの「バインド変数」セクションで定義した名前付きバインド変数のリストと必ず一致している必要があります。これらの2つの変数を正しく一致させることができない場合、実行時に次の2つのエラーのどちらかが発生します。

SQL文で名前付きバインド変数を使用しても、それを定義していない場合は、次のようなエラー・メッセージを受け取ります。

(oracle.jbo.SQLStmtException) JBO-27122: SQL error during statement preparation.
## Detail 0 ##
(java.sql.SQLException) Missing IN or OUT parameter at index:: 1

一方、名前付きバインド変数を定義しても、その変数をSQLで参照するのを忘れたか、名前の入力ミスをした場合、次のようなエラーが表示されます。

oracle.jbo.SQLStmtException: JBO-27122: SQL error during statement preparation.
## Detail 0 ##
java.sql.SQLException: Attempt to set a parameter name that does not occur in the SQL: LowUserId

これらのエラーを解決するには、SQL内の名前付きバインド変数のリストが、概要エディタの「問合せ」ページの「バインド変数」セクションの名前付きバインド変数のリストと一致していることを再度確認します。

5.10.8.2 バインド変数のNULのデフォルト値

名前付きバインド変数にデフォルト値を指定しない場合、変数は実行時にNULLにデフォルト設定されます。つまり、次のようなWHERE句を持つ場合です。

PERSON_ID = :TheCustomerId

このとき、バインド変数TheCustomerIdにデフォルト値を指定しない場合は、デフォルトでNULLになるように設定され、問合せから行が戻されなくなります。アプリケーションとって意味を持つ場合は、必要に応じて状況に対処するために、NVL()、CASE、DECODE()などのSQL関数やその他の関数を活用できます。たとえば、次のようなWHERE句のフラグメントを使用すると、:TheNameの値がnullの場合、ビュー・オブジェクトの問合せに対してすべての名前が一致します。

upper(FIRST_NAME) like upper(:TheName)||'%'

5.11 行検索の使用

行検索は、ビュー基準を使用して行セットの中の特定の行を見つけるためにアプリケーションで使用されるオブジェクトです。行検索は、行セットに対して行参照操作を実行する必要があり、かつ、アプリケーションで行参照の指定に行のキー属性を使用しない場合に定義できます。

現在は、実行時に行キー以外の属性の参照が必要な場合に、次のシナリオで、設計時に定義した行検索を参加させることができます。

- ADFビジネス・コンポーネントWebサービスで行検索を公開する場合。エンド・ユーザーは、サービス・ビュー・インスタンスの特定の行(行検索にマップされた、1つ以上の非キー属性値に一致する)に対して行更新を開始できます。このユースケースの詳細は、「ビュー基準と行検索の使用方法に関する必知事項」を参照してください。

- 行検索にマップされた、1つ以上の非キー属性値に一致する行セットを、アプリケーションでプログラムにより取得する場合。このユースケースの詳細は、「プログラムによる行検索の呼出し」を参照してください。

行検索では、一致した行をすべて特定するか、指定した数のみ特定するように指定できます。指定したフェッチ制限を超える数の行が行検索で特定された場合は、行検索から例外をスローするようにできます。

行検索を含むビュー・オブジェクト定義には、次の要素が含まれます。

1. 1つ以上のビュー基準アイテムを適用してビュー・オブジェクトをフィルタリングする、指定されたビュー基準。ビュー基準アイテムは、一致する行を決定するビュー・オブジェクト属性に対して定義され、これらは、行検索で実行時に値を指定できるように、バインド変数によって定義されている必要があります。

2. ビュー基準のバインド変数と値のソース(ビュー・オブジェクトの一時属性または属性値の式)の間のマッピング。

たとえば、EmpVOに属性emailがある場合、EmpVOの行検索では、EmpVOに定義されたビュー基準と従業員の電子メール・アドレスを使用して、特定の従業員の行を見つけることができます。EmpVOのビュー基準は次の例のようになります。この例では、ビュー・オブジェクトEmpVOの電子メール属性の値を設定するために、ビュー基準の文にバインド変数EmailBindVarが使用されています。

( (UPPER(EmpEO.EMAIL) = UPPER(:EmailBindVar) ) )

アプリケーションでは、マップされたビュー基準のバインド変数に次のような様々な方法で値を適用することにより、行検索を起動します。

- 更新操作が有効なADFビジネス・コンポーネントWebサービスで、入力フィールドを持つフォームを表示できます。入力フィールドは、行検索でビュー基準のバインド変数にマップされるビュー・オブジェクトの一時属性にバインドされています。
ビジネス・コンポーネントのWebサービスの操作を有効化する方法の詳細は、「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」を参照してください。

- アプリケーションでビュー・オブジェクトの行検索を起動し、マップされたビュー・オブジェクト属性の値をプログラムでビュー基準のバインド変数に設定できます。
詳細は、「プログラムによる行検索の呼出し」を参照してください。

5.11.1 ビュー・オブジェクト定義に行検索を追加する方法

行検索を定義するには、ビュー・オブジェクトの概要エディタの「行検索」ページを使用します。エディタで、選択したビュー基準の各バインド変数の値のソースを定義します。ビュー・オブジェクトの属性と、属性値の式は、どちらも行検索によって定義されたバインド変数のソースとして有効です。

定義する行検索では、ビュー基準の任意の数のバインド変数を、値の有効なソースにマップできます。行検索定義でマップする追加の変数を多くすると、一致する行がより制限されます。この意味で、行検索は、行セットを変更しない問合せ検索操作に似ています。アプリケーションでは、適切に定義された行検索を使用して特定の1行を検索し、エンド・ユーザーがその行に更新を実行できるようにすることができます。

図5-37の概要エディタには、ビュー基準findEmpByEmpEmailで指定されたビュー基準のバインド変数EmailBindVarを、ビュー・オブジェクトEmpVOによって定義された一時属性TrEmpEmail(値のソース)にマップする行検索が表示されています。

図5-37 行検索を表示したビュー・オブジェクトの概要エディタ

注意:

マスター/ディテール階層で、ディテール・ビュー・オブジェクトの属性でマスターをフィルタリングする必要がある場合は、マスター・ビュー・オブジェクトに行検索を定義できます。このシナリオでは、「行検索を使用したマスター・ビュー・オブジェクトの行の検索方法」で説明しているように、ビュー基準でインライン・ビュー基準が使用されます。

始める前に:

行検索に関する知識が役立つ場合があります。詳細は、「行検索の使用」を参照してください。

ビュー基準に関する知識が役立つ場合があります。詳細は、「名前付きビュー基準の処理」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 目的のビュー・オブジェクトを作成します。「単一のデータベース表からのビュー・オブジェクト行の移入」または「結合問合せ結果での複数表の使用」を参照してください。

- 「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー・オブジェクトにビュー基準を定義します。

- オプションで、「一時属性の追加方法」の説明に従い、更新可能な一時属性をビュー・オブジェクトに追加します。一時属性は、実行時に評価される属性値式の代替となります。一時属性は、アプリケーションでプログラムにより設定するか、ADFビジネス・コンポーネントWebサービス・ペイロードで公開してエンド・ユーザーに値を要求できます。基準参照値を受け取るには、一時属性を更新可能として定義する必要があります。

ビュー・オブジェクトの行検索を作成するには:

1. 「アプリケーション」ウィンドウで、行検索を作成するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「行検索」ナビゲーション・タブをクリックし、「行検索の追加」ボタンをクリックします。

3. 「名前」フィールドで、行検索の名前を変更します。

たとえば、電子メール・アドレスから従業員を特定する目的で定義する行検索であれば、EmpByEmailRowFinderなどの名前です。

4. 「行検索」リストで新しい行検索を選択し、「ビュー基準」ドロップダウンで、ビュー・オブジェクトの行セットをフィルタリングする行基準を選択します。

図5-37のように、目的の行検索が強調表示されます。行検索で使用するビュー基準を作成していない場合、ビュー基準のリストは空になります。

5. ADFビジネス・コンポーネントWebサービスのエンド・ユーザーが値を指定するようにする場合は、「属性」を選択したままにしてリストからバインド変数を選択し、「属性」ドロップダウンで、実行時にバインド変数の値を提供するビュー・オブジェクトの一時属性を選択します。

ここで選択する一時属性が、エンド・ユーザーが基準の属性値を指定するために更新する属性になります。たとえば、従業員の電子メール・アドレスで従業員レコードを照合する行検索には、EmpVOビュー・オブジェクトに定義された一時属性TrEmpEmailが含まれている可能性があります。

注意: ビュー・オブジェクトの概要エディタで一時属性を作成する際には、基準参照値を受け取れるようにするために、その一時属性を「更新可能」として定義してください。

6. 行検索で一致が許可される行数を指定する場合は、「すべてをフェッチ」の選択を解除します。

「フェッチ制限」に行数を入力した場合は、さらに「制限超過エラー」を選択することで、「フェッチ制限」で指定された数を超えた一致行がデータベースに存在する場合に、Oracle ADFで例外をスローできるようになります。

5.11.2 行検索の定義時の処理

ビュー・オブジェクトの行検索を作成する場合は、行検索自体の定義も含めて、行検索で必要とされるすべてのメタデータをビュー・オブジェクト定義に含めます。次の例に示すように、行検索RowFinderのメタデータとして、ビュー・オブジェクト定義には、<Variable>要素にバインド変数EmailBindVar、<ViewAttribute>要素に一時属性TrEmpEmail、<ViewCriteria>要素にビュー基準findEmpByEmpEmailおよびビュー基準行EmpVOCriteria_Row0があり、最後に<RowFinders>要素に行検索EmpByEmailRowFinderが含まれています。

行検索の<VarAttributeMapping>サブ要素は、ビュー基準のバインド変数EmailBindVarをビュー・オブジェクトの一時属性TrEmpEmailにマップしています。これにより、エンド・ユーザーが実行時に値を指定し、アプリケーションで必要な基準属性を使用して行検索を起動できるようになっています。<ViewCriteriaItem>サブ要素は、基準属性Emailを、バインド変数EmailBindVarの値に設定しています。

実行時に、行ファインダがビュー・オブジェクトに対して起動される場合、1つ以上の基準属性に渡される一時属性値は行セット内の一致する行を識別します。この例では、従業員の電子メールアドレスを使用して、EMPLOYEE表の従業員レコードが照合されています。行検索では、行のキー値を渡さなくても従業員のレコードが特定されます。

<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="EmpVO"
SelectList="EmpEO.ID,
EmpEO.LAST_NAME,
EmpEO.FIRST_NAME"
EmpEO.USERID"
EmpEO.DEPT_ID"
EmpEO.EMAIL"
FromList="S_EMP EmpEO"
...
<Variable
Name="EmailBindVar"
Kind="viewcriteria"
Type="java.lang.String"/>
<EntityUsage
Name="EmpEO"
Entity="model.entities.EmpEO"/>
...
<ViewAttribute
Name="TrEmpEmail"
IsUpdateable="false"
IsSelected="false"
IsPersistent="false"
PrecisionRule="true"
Type="java.lang.String"
ColumnType="CHAR"
AliasName="VIEW_ATTR"
SQLType="VARCHAR"/>
...
<ViewCriteria
Name="findEmpByEmpEmail"
ViewObjectName="model.views.EmpVO"
Conjunction="AND">
...
<ViewCriteriaRow
Name="EmpVOCriteria_row_0"
UpperColumns="1">
<ViewCriteriaItem
Name="Email"
ViewAttribute="Email"
Operator="="
Conjunction="AND"
Value=":EmailBindVar"
IsBindVarValue="true"
Required="Optional"/>
</ViewCriteriaRow>
</ViewCriteria>
...
<RowFinders>
<AttrValueRowFinder
Name="EmpByEmailRowFinder"
FetchLimit="1"
ErrorOnExceedingLimit="true">
<ViewCriteriaUsage
Name="findEmpByEmpEmail"
FullName="model.views.EmpVO.findEmpByEmpEmail"/>
<VarAttributeMap>
<VariableAttributeMapping
Variable="EmailBindVar"
Attribute="TrEmpEmail"/>
</VarAttributeMap>
</AttrValueRowFinder>
</RowFinders>
</ViewObject>

5.11.3 ビュー基準と行検索の使用方法に関する必知事項

行検索とビュー基準は、どちらもプログラムまたは宣言により使用して、ビュー・オブジェクト行セットをフィルタできます。行検索は、ビュー・オブジェクトおよびビュー基準属性バインド変数を定義する一時属性間のマップを定義するため、ビュー基準とは異なります。最終的に、行検索は、実行時に解決される一時属性値で定義されたバインド変数を持つビュー・オブジェクトにビュー基準を適用することで、ビュー・オブジェクトの1つ以上の行を照合します。

行検索によってマップされた一時属性により、アプリケーションで使用される行検索は、ビュー基準単体には適していないアプリケーション・ユースケースで使用できます。特に、行検索は、ADFビジネス・コンポーネントWebサービスがCRUD操作を有効にした場合に最も役立ちます。この場合、行検索はADFビジネス・コンポーネントWebサービスの開発者に、あいまいな行キー値を必要とせずにCRUD操作を公開する機能を提供します。

Fusion Webアプリケーション開発者は、Webサービス・データ・コントロールを作成して、JDeveloperの「データ・コントロール」パネルでADFビジネス・コンポーネントWebサービスのビュー・オブジェクトを公開できます。ビュー・オブジェクトの公開された行検索でマップされた一時属性を使用して、エンド・ユーザーが目的の更新を行える入力フォームを設計できます。たとえば、エンド・ユーザーは、個人の電子メール・アドレスなどの使い慣れた属性の値を提供して、特定の個人の行を照合し、名前変更を可能にする操作などの更新操作をその行の任意の属性に対して開始できます。

ADF Webサービスでの行検索サポートの詳細は、「行ファインダとADF Webサービス操作に関する必知事項」を参照してください。ADF Webサービスに基づくデータ・コントロールの作成の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』を参照してください。

「行検索を使用したマスター・ビュー・オブジェクトの行の検索方法」で説明するように、キー以外の属性を使用して行を照合する行検索の機能は、マスター/ディテール関連ビュー・オブジェクトに拡張されます。

5.11.4 プログラムによる行検索の呼出し

行検索を定義したら、ビュー・オブジェクトに対して行検索を起動します。行検索定義で行制限が指定されている場合、実行された行検索ではRowFinderFetchLimitExceededException例外がスローされます。

ビュー・オブジェクトに定義した行検索を起動するには、次の基本手順に従います(後に例を示しています)。

1. 行検索を定義しているビュー・オブジェクトを見つけます。

2. ビュー・オブジェクトから行検索を見つけます。

3. 行検索の各バインド変数のマッピング用に、名前と値のペアを作成します。

4. 行検索でマップされた一時属性を使用して、各バインド変数を設定します。

5. 目的のビュー・オブジェクトに対して行検索を起動します。

6. 一致する行数が行検索のフェッチ制限を超える場合は、例外をスローします。

実行時に、行検索がビュー・オブジェクトに対して起動される場合、setAttribute()によって移入された、行検索でマップされた一時属性値が基準属性に設定されて、行セット内の一致する行を識別します。次の例では、従業員の電子メール・アドレスを使用して、EmpViewビュー・オブジェクトの従業員レコードが照合されています。行検索EmpByEmailRowFinderは、一時属性TrEmpEmailを使用して、行キー値を渡す必要なしに条件属性を指定して、従業員のレコードを特定します。

package model;

import oracle.jbo.*;
import oracle.jbo.client.Configuration;
import oracle.jbo.server.RowFinder;
import oracle.jbo.server.ViewObjectImpl;

public class TestClient
{
public TestClient()
{
super();
}

public static void main(String[] args)
{
TestClient testClient = new TestClient();
String amDef = "model.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);

// 1. Find the view object with the row finder
ViewObjectImpl vo = (ViewObjectImpl)am.findViewObject("EmpView1");
Row r;
RowIterator ri;

// 2. Find the row finder
RowFinder finder = vo.lookupRowFinder("EmpByEmailRowFinder");
// 3. Create name value pairs for the row finder
NameValuePairs nvp = new NameValuePairs();
// 4. Set the row-finder mapped transient attribute
nvp.setAttribute("TrEmpEmail", "cee.mague@company.com");
// 5. Invoke the row finder
try
{
ri = finder.execute(nvp, vo);
}
// 6. Throw an exception when row match exceeds specified limit
catch(RowFinderFetchLimitExceededException e)
{
System.out.println("Warning: more than one row match exists.");
}

while (ri.hasNext())
{
r = ri.next();
System.out.println("Find emp row by email finder: " +
r.getAttribute("FirstName") + "/" + r.getAttribute("LastName"));
}

Configuration.releaseRootApplicationModule(am, true);
}
}

5.12 ビュー・オブジェクト属性の値リスト(LOV)での作業

アプリケーションのユーザー・インタフェース部分に表示される編集フォームでは、データ・モデルで定義するLOV有効属性を利用して、個々の入力フィールドの値リストを事前に指定できます。たとえば、編集フォームに国のリストが表示され、その編集フォーム内の対応する住所フィールドに値が移入されるようになっている場合があります。この一般的な設計タスクを容易にするために、ADFビジネス・コンポーネントでは、ユーザー・インタフェースでの属性のLOVの使用法を指定する宣言的な方法をサポートしています。

データ・モデル・プロジェクトでビュー・オブジェクトの属性に対してLOVを定義すると、ユーザー・インタフェースでリスト・コントロールを使用するタスクが大幅に簡略化されます。ビュー・オブジェクトの個々の属性にLOVを定義するため、属性に対してLOV使用をカスタマイズすると、属性が表示されるフォームでリスト・コンポーネントを参照できます。

注意:

LOVをUIに表示するには、ユーザー・インタフェース・デザイナによってデータバインドされたフォームが作成される前に、LOVの使用方法を指定しておく必要があります。既存のフォームから参照される属性に対してLOVの使用方法を定義しても、LOVに表示するフォームのコンポーネントは変更されません。

ユーザー・インタフェースに表示する任意のビュー・オブジェクト属性に対しては、LOVを選択リストとして定義できます。属性のLOV定義の特性は、ユーザー・インタフェースの要件に応じて異なります。ユーザー・インタフェース・デザイナから収集する情報により、最適な解決策が決定されます。たとえば、次のような場合に対してLOV属性を定義できます。

- ビジネス・ドメイン・オブジェクトに対してビュー・オブジェクト問合せから取得した属性値を表示する必要がある場合。
たとえば、LOV属性を定義して発注書にサプライヤのリストを表示する場合などです。

- ビュー・オブジェクト問合せから取得した属性値を表示すると同時に、LOV属性の現在行の任意の属性からパラメータ値を使用して、その属性値をフィルタリングする必要がある場合。
たとえば、LOV属性を定義して発注書にサプライヤのアドレス・リストを表示すると同時に、現在のサプライヤを基にアドレス・リストを制限する場合などです。

必要に応じて、2番目のLOVは、ユーザーの選択に基づくパラメータ値の制御に使用できます。たとえば、ユーザーが現在のサプライヤを選択するとそのサプライヤのアドレス・リストを操作できるようにします。この場合、2つのLOVはカスケード・リストと呼ばれます。

LOV属性を定義するには、LOVによって表示する属性値に対して適切な行を問い合せるデータソース・ビュー・オブジェクトを、データ・モデル・プロジェクト内にあらかじめ作成しておく必要があります。その後、ベース・ビュー・オブジェクトでLOVを定義するためのすべての処理を行います。ベース・ビュー・オブジェクトとは、ユーザー・インタフェースに表示するプライマリ・データを含むビュー・オブジェクトです。LOVの使用方法により、次のビュー・オブジェクト・メタデータが追加定義されます。

- LOV属性のデータソースにアクセスするためのビュー・アクセッサ。ビュー・アクセッサとは、データソース・ビュー・オブジェクトの行セットから可能な値のリストを取得するためのADFビジネス・コンポーネントのメカニズムです。

- リストが定義されているデータソース属性以外のベース・ビュー・オブジェクトの属性に対してデータソースから戻される追加の値(オプション)。

- 表示するリスト・コンポーネントのタイプを含むユーザー・インタフェース・ヒント、複数の表示属性が必要な場合に現在行から表示する属性、および選択リスト・コンポーネントに固有のオプション。

注意:

LOV機能では、表示リストを検証するための属性検証の使用はサポートされていません。リストの表示時には、データ・ソース属性(サプリメンタル属性を含む)に対して定義されている検証規則は抑制されるため、LOVリストは制限されません。開発者は、データ・ソース・ビュー・オブジェクトから返される値のリストに、必要で有効な値のみが含まれるようにする必要があります。

LOV有効属性を定義するプロセスでは通常、ベース・ビュー・オブジェクト属性に対して表示する「値リストの作成」ダイアログを使用します。

LOV有効属性を定義するには、通常は次のプロセスに従います。

1. ベース属性の「値リストの作成」ダイアログを開きます。

2. 新規のビュー・アクセッサ定義を作成してデータソース・ビュー・オブジェクトを指定するか、またはベース・ビュー・オブジェクトによって定義済の既存のビュー・アクセッサを選択します。
サポートしたいユースケースごとに新しいビュー・アクセッサを必ず作成してください。同じデータ・ソースに依存する複数のLOVリストを定義するために1つのビュー・アクセッサを再利用しないでください。ビュー・アクセッサを再利用すると、実行時に予期しない結果が発生することがあります。

3. 必要に応じて、ベース・ビュー・オブジェクトの現在行の任意の属性から値を取得するバインド変数を使用してビュー基準を作成することにより、ビュー・アクセッサをフィルタリングできます。
ビュー基準を作成してデータ・ソース・ビュー・オブジェクトをフィルタリングする場合は、ビュー基準のバインド変数への値の入力に使用するベース・ビュー・オブジェクトの属性に必須LOVを設定することもできます。このように連携するLOVリストは、カスケードLOVリストと呼ばれます。ユーザーによる属性の選択によって2番目の属性リストに表示されるオプションを制御する場合は、カスケードLOVリストを設定します。

4. ビュー・アクセッサのデータソース・ビュー・オブジェクトからリスト属性を選択します。
これにより、選択した属性がベース・ビュー・オブジェクトの現在の属性にマップされます。

5. 必要に応じて、リスト戻り値を選択し、リストによりベース・ビュー・オブジェクトに戻される追加の値をマップします。

6. ユーザー・インタフェース・ヒントを選択して、リストの表示機能を指定します。

7. 属性の変更内容を保存します。

LOV有効属性を作成した後、ユーザー・インタフェース・デザイナでは、「データ・コントロール」パネルからLOV有効属性のコレクションをドラッグするとリスト・コンポーネントをWebページに作成できます。リストを表示するWebページの作成の詳細は、「データバインドされた選択リストおよびシャトルの作成」を参照してください。特に、WebページでのLOV有効属性の処理の詳細は、「モデルドリブン・リストの作成方法」を参照してください。

5.12.1 単一のLOVが有効なビュー・オブジェクトの属性を定義する方法

編集フォームに表示されるリスト値が、編集フォーム内の別の選択内容に依存しないようにする場合は、ビュー・アクセッサを定義してリスト・データソースを指定できます。たとえば、ユーザーが注文項目のサプライヤを選択する必要があるフィールドが発注書に含まれているとします。この例では、最初にデータソース・ビュー・オブジェクト(SuppliersView)を指定するビュー・アクセッサを作成します。次に、ベース・ビュー・オブジェクト(PurchaseOrdersView)のSupplierDesc属性にLOVを設定します。最後に、ベース・ビュー・オブジェクトのLOV有効属性(SupplierDesc)からビュー・アクセッサを参照し、データソース属性(SupplierDesc)を選択します。

ベース・ビュー・オブジェクトのLOV有効属性を定義するには、「値リストの作成」ダイアログを使用します。このダイアログでは、既存のビュー・アクセッサを選択したり、新規のビュー・アクセッサを作成してLOV属性定義とともに保存できます。

始める前に:

LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

ビュー・オブジェクト属性の値を表示するLOVを定義するには:

1. 「アプリケーション」ウィンドウで、LOVとして有効にする属性が含まれているビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、LOVを表示する属性を選択し、「値リスト」タブをクリックして、「値リストの追加」ボタンをクリックします。

概要エディタの属性リストで現在選択している属性にLOVを作成するには、「値リストの作成」ダイアログを使用します。JDeveloperにより、LOVの使用方法を識別する一意の名前が割り当てられます。たとえば、属性SupplierDescのメタデータでは、この属性がLOV対応であることを示すSupplierDescLOVという名前が指定されます。

4. 「値リストの作成」ダイアログの「構成」タブで、「新規ビュー・アクセッサの作成」ボタンをクリックし、現在編集中のビュー・オブジェクトにビュー・アクセッサを追加します。

または、「リスト・データソース」を展開し、既存のアクセッサから選択できます。ドロップダウン・リストには、編集中のビュー・オブジェクトに追加したすべてのアクセッサが表示されます。

5. 「ビュー・アクセッサ」ダイアログで、属性のデータソースを定義するビュー・オブジェクト定義または共有ビュー・インスタンスを選択し、それをビュー・アクセッサ・リストに移動します。

デフォルトでは、作成したビュー・アクセッサにはビュー・オブジェクトと同じ名前が表示されます。アクセッサ名を編集して一意の名前を付けることができます。たとえば、SuppliersViewビュー・オブジェクトにSuppliersViewAccessorという名前を割り当てます。

ビュー・インスタンスは、共有アプリケーション・モジュールのデータ・モデルで定義したビュー・オブジェクトの使用方法になります。LOVでの共有ビュー・インスタンスの使用の詳細は、「参照表を基にしてLOVを作成する方法」を参照してください。

6. 「OK」をクリックして、ビュー・オブジェクトのビュー・アクセッサ定義を保存します。

7. 「値リストの作成」ダイアログで、「リスト・データソース」を展開し、ベース・ビュー・オブジェクトに対して作成したデータ・ソースとして使用するビュー・アクセッサを選択します。次に、このビュー・アクセッサから、LOV有効属性のリスト・データを取得する同じ属性を選択します。

エディタにより、リスト・データソース属性とLOV有効属性の間のデフォルト・マッピングが作成されます。たとえば、PurchaseOrdersViewビュー・オブジェクトの属性SuppliersDescは、SuppliersViewAccessorビュー・アクセッサの属性SuppliersDescにマップされます。

このエディタでは、リストが定義されている属性のデフォルト属性マッピングは削除できません。

8. リストによりベース・ビュー・オブジェクトに戻される値を追加で指定する場合、「リスト戻り値」セクションの「戻り属性マップを作成します」ボタンをクリックし、目的のベース・ビュー・オブジェクト属性をビュー・アクセッサによりアクセスされる属性にマップします。

あわせて更新するため、属性のリスト選択をユーザーには要求せず、現在の行で決定している属性値を必要とする場合、追加属性の戻り値が便利です。たとえば、PurchaseOrdersViewビュー・オブジェクトの属性SupplierAddressをマップする場合は、SuppliersViewAccessorビュー・アクセッサの属性SupplierAddressを選択します。

9. 「OK」をクリックします。

5.12.2 LOVが有効なビュー・オブジェクトの属性に対してカスケード・リストを定義する方法

アプリケーションのユーザー・インタフェースで、1つの入力フィールドの値リストが、別のフィールドへのユーザー入力値に依存する場合は、ユーザー・インタフェースにカスケード・リストとして表示される属性を作成できます。この場合は、LOV有効属性として使用可能な値のリストは、行ごとに異なります。LOV値は、ユーザーが現在行を変更するたびに、LOV有効属性のビュー行にある1つ以上の制御属性の値に基づいて変化します。制御属性をLOV有効属性に適用するには、データソース・ビュー・オブジェクトにアクセスするためのビュー・アクセッサを作成し、そのアクセッサに対して、使用可能な値リストを制御属性の現在値に基づいてフィルタリングするという要件を追加します。LOV有効属性をフィルタリングするには、ビュー・アクセッサを編集して、ユーザーの選択を取得するためのバインド変数を持つ名前付きビュー基準を追加します。

たとえば、発注フォームに、ユーザーがサプライヤ固有のサイトを選択する必要があるフィールドが含まれており、利用可能なサイトは注文で指定済のサプライヤによって決まるとします。この要件を満たすには、まず、データ・ソース・ビュー・オブジェクトを指定するビュー・アクセッサを作成します。データ・ソース・ビュー・オブジェクトは、ユーザーが選択したサプライヤに基づいて利用可能なサプライヤ・サイトをフィルタリングする問合せを実行する必要があるため、LOVの使用方法に固有のものになります。このデータ・ソース・ビュー・オブジェクトの定義にSupplierIdsForCurrentSupplierSiteという名前を指定することにより、データ・モデル内にすでに存在するSupplierSitesViewビュー・オブジェクトと区別できます。データ・ソース・ビュー・オブジェクトでは、制御属性(SupplierId)についてユーザーの選択を取得するためのバインド変数(TheSupplierId)でビュー基準アイテムを1つ設定した名前付きビュー基準(SupplierCriteria)が使用されます。

次に、ベース・ビュー・オブジェクト(PurchaseOrdersView)のSupplierSiteId属性にLOVを設定します。これにより、ベース・ビュー・オブジェクトのLOV有効属性(PurchaseOrdersView.SupplierSiteId)から、データベース・ビュー・オブジェクトを指定するビュー・アクセッサを参照できます。最後に、LOV有効属性のビュー・アクセッサ定義を編集することにより、ビュー・オブジェクトから対応する属性(SupplierIdsForCurrentSupplierSite.SupplierSiteId)をデータソースとして指定し、同時に、属性SupplierIdを使用してビュー行の結果からバインド変数の値を指定する必要があります。

LOVが有効なビュー・オブジェクトの属性に対してカスケード・リストを定義するには:

1. カスケード・リストを制御するデータ・ソース・ビュー・オブジェクトを作成します。

2. カスケード・リストをフィルタリングするビュー・アクセッサを作成します。

5.12.2.1 カスケード・リストを制御するデータ・ソース・ビュー・オブジェクトの作成

データ・ソース・ビュー・オブジェクトでは、LOV有効属性の制御属性を定義します。制御属性をベース・ビュー・オブジェクトのLOV有効属性からアクセス可能にするには、別の属性の値に基づいてデータ・ソース属性をフィルタリングする名前付きビュー基準を定義する必要があります。制御属性の値は実行時に変更されるため、ビュー基準では、バインド変数を使用して制御属性を設定します。

始める前に:

LOV有効属性のカスケードに関する知識が役立つ場合があります。詳細は、「LOVが有効なビュー・オブジェクトの属性に対してカスケード・リストを定義する方法」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

LOV有効属性が参照可能なデータ・ソースのビュー基準を定義する手順:

1. 「アプリケーション」ウィンドウで、制御属性として使用可能なすべての値のリストを問い合せるために作成したビュー・オブジェクトをダブルクリックします。

たとえば、LOV有効属性SupplierSiteIdが制御属性SupplierIdの値に依存する場合は、すべてのサプライヤ・サイトのリストを問い合せるデータソース・ビュー・オブジェクトSupplierIdsForCurrentSupplierSiteがすでに作成されています。

2. 概要エディタで、「問合せ」ナビゲーション・タブをクリックします。

3. 「問合せ」ページの「バインド変数」セクションで、「新規バインド変数の作成」ボタンをクリックし、データソース・ビュー・オブジェクトにバインド変数を追加します。

たとえば、すべてのサプライヤのサイトのリストを問い合せるためのデータソース・ビュー・オブジェクトSupplierIdsForCurrentSupplierSiteは、LOV有効属性の制御属性となるため、これに対してバインド変数TheSupplierIdを作成します。

4. 「新規変数」ダイアログで、バインド変数の名前を入力し、型を選択して、「OK」をクリックします。

デフォルトでは、作成したビュー・アクセッサには、ビュー・オブジェクト・インスタンスと同じ名前が表示されます。アクセッサ名を編集して一意の名前を付けることができます。たとえば、CurrencyLookupViewビュー・オブジェクト・インスタンスにCurrencyLookupViewAccessorという名前を割り当てます。

5. 概要エディタで「ビュー基準」ナビゲーション・タブをクリックし、「新規ビュー基準の作成」ボタンをクリックして、現在編集中のデータソース・ビュー・オブジェクトにビュー基準を追加します。

6. 「ビュー基準の作成」ダイアログで、「グループの追加」をクリックし、次のようにグループに対して1つの「基準アイテム」を定義します。

- ビュー基準を識別する「基準名」を入力します。たとえば、SupplierIdsForCurrentSupplierSiteに対してはSupplierCriteriaという名前を入力します。

- 「属性」リストから制御属性を選択します。たとえば、SupplierIdsForCurrentSupplierSiteからSupplierSiteId属性を選択します。

- ビュー基準の「演算子」リストから「次と等しい」を選択します。

- ビュー基準の「オペランド」リストから「バインド変数」を選択します。

- 「パラメータ」リストから事前に定義されているバインド変数の名前を選択します。

- 次のバインド変数構成オプションから選択して、親LOVが値を必要とするかどうかを指定します。
親LOV値が必要とされるカスケードLOVを構成する場合は、「検証」メニューの「オプション」で、「Null値の無視」の選択を解除します。この組合せは、親LOVを選択しない場合に子LOVの行が返されないカスケードLOV使用例をサポートします。「ビュー基準の編集」ダイアログには、((SupplierIdsForCurrentSupplierSite.SUPPLIER_ID = :TheSupplierId))という形のWHERE句が表示されます。

親LOV値がオプションのカスケードLOVを構成する場合は、「検証」メニューの「オプション」で、「Null値の無視」を選択します(デフォルト)。この組合せは、親LOVを選択しない場合に子LOVの行がすべて返されるカスケードLOV使用例をサポートします。「ビュー基準の編集」ダイアログには、(((SupplierIdsForCurrentSupplierSite.SUPPLIER_ID = :TheSupplierId) OR ( :TheSupplierId IS NULL )))のようなWHERE句が表示されます。

これらの設定の詳細は、「ビュー基準のバインド変数に関する必知事項」を参照してください。親LOVが選択されない場合は、検証エラーが発生するため、カスケードLOVの検証オプションに対して「必須」を選択しないでください。

7. 「OK」をクリックします。

5.12.2.2 カスケード・リストをフィルタリングするビュー・アクセッサの作成

カスケードLOV有効属性を移入するには、まずデータ・ソース・ビュー・オブジェクトで名前付きビュー基準を設定する必要があります。ベース・ビュー・オブジェクトのLOV有効属性がデータ・ソース・ビュー・オブジェクトの制御属性に依存するようにするために、ベース・ビュー・オブジェクトのLOV有効属性にビュー・アクセッサを追加し、以前に定義済のデータ・ソース・ビュー・オブジェクトの名前付きビュー基準を参照します。

始める前に:

LOV有効属性のカスケードに関する知識が役立つ場合があります。詳細は、「LOVが有効なビュー・オブジェクトの属性に対してカスケード・リストを定義する方法」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「カスケード・リストを制御するデータソース・ビュー・オブジェクトの作成」の説明に従って、データソース・ビュー・オブジェクトと名前付きビュー基準を作成します。

LOV有効属性に対する表示値を、同じビュー行にある別の属性値に基づいてフィルタリングするためのビュー・アクセッサを作成する手順:

1. 「アプリケーション」ウィンドウで、フィルタ対象のビュー・アクセッサをリスト・データソースとして使用する属性を含むベース・ビュー・オブジェクトをダブルクリックします。

たとえば、ベース・ビュー・オブジェクトPurchaseOrdersViewには、制御属性SupplierIdの値に依存する属性SupplierSiteIdが含まれています。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、カスケードLOVをフィルタリングする属性を選択し、「値リスト」タブをクリックして、「値リストの追加」ボタンをクリックします。

4. 「値リストの作成」ダイアログで、「新規ビュー・アクセッサの作成」ボタンをクリックし、現在編集中のビュー・オブジェクトにビュー・アクセッサを追加します。

または、「リスト・データソース」を展開し、既存のアクセッサから選択できます。ドロップダウン・リストには、編集中のビュー・オブジェクトに追加したすべてのアクセッサが表示されます。

5. 「ビュー・アクセッサ」ダイアログで、データソース・ビュー・オブジェクトに対して作成したビュー・オブジェクト・インスタンス名を選択し、そのインスタンスをビュー・アクセッサ・リストに移動します。

6. ダイアログで新規のビュー・アクセッサを選択し、「編集」をクリックします。

7. 「ビュー・アクセッサの編集」ダイアログで、事前に定義されているビュー基準をビュー・アクセッサに適用し、次の手順に従ってバインド変数に値を指定します。

- 「使用可能」リストでデータソース・ビュー・オブジェクトのビュー基準をクリックし、選択したビュー基準を「選択済」リストに追加します。たとえば、SupplierIdsForCurrentSupplierSiteビュー・オブジェクト定義からSupplierCriteriaを選択します。

- バインド変数の値を制御属性の名前に設定します。この属性名は、ベース・ビュー・オブジェクトの制御属性の名前と一致している必要があります。たとえば、ベース・ビュー・オブジェクトPurchaseOrdersViewに、制御属性SupplierIdの値に依存するLOV有効属性SupplierSiteIdが含まれている場合、バインド変数値としてSupplierIdを入力します。

- 「パラメータ」リストから事前に定義されているバインド変数の名前を選択します。

- 「使用方法」ドロップダウン・リストから「必須」を選択します。

8. 「OK」をクリックして、ベース・ビュー・オブジェクトのビュー・アクセッサ定義を保存します。

9. 概要エディタの「属性」ページで、LOVを表示する属性を選択してから、「値リスト」タブをクリックし、「値リストの追加」ボタンをクリックします。

10. 「値リストの作成」ダイアログで、「リスト・データソース」を展開し、データ・ソース・ビュー・オブジェクト・インスタンスに対して作成したビュー・アクセッサを選択して、データ・ソースとして使用します。次に、このビュー・アクセッサから、現在編集中の属性をフィルタリングするための制御属性を選択します。

エディタにより、ビュー・オブジェクト属性とLOV有効属性との間のデフォルト・マッピングが作成されます。ユーザーによる制御属性の選択によって設定されるバインド変数でLOV有効属性をフィルタリングできるようにするには、個別の属性を使用します。たとえば、PurchaseOrdersViewビュー・オブジェクトのLOV有効属性SupplierIdは、SupplierIdsForCurrentSupplierSiteViewAccessorに対する制御属性SupplierSiteIdにマップされます。ランタイムでは、行セットとベース行属性が異なるこれら2つのカスケードLOVが自動的にサポートされます。

11. 「OK」をクリックします。

5.12.3 単一のLOVが有効なビュー・オブジェクト属性に複数のLOVを指定する方法

アプリケーションのユーザー・インタフェースに表示される値リストを変化させるもう1つの方法は、単一のLOV有効ビュー・オブジェクト属性に複数の値リストを定義することです。依存するLOVリスト選択に基づいてリストの内容を変化させるカスケード・リストとは対照的に、複数のLOVを含むLOV有効切替え属性により、LOV全体を変化させることができます。表示されるLOVの選択は、適用するLOV名の解決のために特別に定義した属性値によって実行時に制御されます。

たとえば、フォームの作成や編集で適用する1つのLOVと、検索コンポーネントに適用するもう1つのLOVを定義するとします。最初のケースでは、フォームが使用できるLOV有効属性は、エンティティを参照するすべてのビュー・オブジェクトで共有されるエンティティ・ベースのビュー・アクセッサになります。単一のアクセッサ定義をフォームの同じLOVの各インスタンスに適用できるので、エンティティ・ベースのビュー・アクセッサは、ユーザー・インタフェース・フォームで便利です。ただし、検索コンポーネントの場合は、基礎をなすエンティティから導出されたビュー・アクセッサに基づいたLOV定義は機能しません。検索コンポーネントのLOV定義は、ビュー・オブジェクトで定義されたビュー・アクセッサに基づいている必要があります。ユーザーが検索を開始すると、基準行の値がWHERE句のパラメータに変換されます。作成または編集タイプのフォームに表示される通常のビュー行とは異なり、基準行はエンティティを基礎としません。このシナリオでは、1つ目のLOVはデータ・ソースとしてエンティティ・ベースのアクセッサを使用し、2つ目のLOVはデータ・ソースとしてビュー・オブジェクトベースのアクセッサを使用します。

この要件に対応して同一の属性にアクセスする複数のLOVを定義するには、ベース・ビュー・オブジェクトに切替え属性を追加します。たとえば、Ordersビュー・オブジェクトに対して、式を通じて表示するLOVの名前を解決するShipperLOVSwitcher属性を追加できます。このような式では、ShipperID属性に適用できる2つのLOVを指定できます。

(adf.isCriteriaRow) ?"LOV_ShipperID_ForSearch" : "LOV_ShipperID"

この式は、切替え属性の「値」フィールドに表示されます。検索コンポーネントの場合は、実行時に、この式はビュー・オブジェクトベースのアクセッサのLOVを識別する値になります。作成または編集フォームの場合は、この式はエンティティ・ベースのアクセッサのLOVを識別する値になります。

ベース・ビュー・オブジェクトの属性に複数のLOVを追加するには、「値リストの作成」ダイアログを使用します。ベース・ビュー・オブジェクトの概要エディタの「属性」ページの「値リスト」セクションでは、表示するデフォルトのLOVと適用する切替え属性も定義できます。

始める前に:

LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、属性の最初のLOVリストを作成します。
切替え属性シナリオでは、一意のビュー・アクセッサを作成する必要があることに注意してください。複数のLOVリストを定義するために1つのビュー・アクセッサを再利用しないでください。様々なユース・ケースに対してビュー・アクセッサを再利用すると、実行時に予期しない結果が発生することがあります。

ビュー・オブジェクト属性に既存のLOVを使用して追加LOVリストを指定するには:

1. 「アプリケーション」ウィンドウで、複数のLOVリストを指定する属性が含まれているビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、目的の属性を選択してから、「値リスト」タブをクリックし、「値リストの追加」ボタンをクリックします。

4. 「値リストの作成」ダイアログで、「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、最初のLOVを定義します。

LOVを定義するときに、属性によって返される値と一致するようにLOV名を変更します(これを使用して、アプリケーションによってLOV有効属性に適用されるLOVを決定します)。

5. 1つ目のLOVを定義したら、概要エディタの「属性」ページの「値リスト」タブに戻り、元の属性を選択したまま、「値リストの追加」ボタンをクリックします。

概要エディタの「属性」ページで正しい属性を選択すると、「値リスト」セクションには先に定義したLOVが表示されます。

6. 「値リストの作成」ダイアログで、「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」で説明されている手順を繰り返し、後続の各LOVを定義します。

各LOVの名前は、属性によって返される(LOV有効属性を適用するLOVを決定する)一意の値に対応させる必要があります。

2つ目LOVは一意のビュー・アクセッサを使用して定義する必要がありますが、属性は任意のものを使用できます。複数のLOVリストが指定された属性に追加できるLOVリストのタイプに制限はありません。

2つ目のLOVを定義すると、ビュー・オブジェクトの概要エディタの「値リスト」セクションが変更され、LOVの選択の制御に使用する追加機能が表示されます。

7. 概要エディタの「属性」ページで、「値リスト」タブをクリックし、「値リストの切替え」ドロップダウン・リストで、使用する値リストの名前を返す属性を選択します。

ドロップダウン・リストにベース・ビュー・オブジェクトの属性が表示されます。アプリケーションで、定義済の複数のLOVからLOVを動的に適用する場合には、ビュー・オブジェクトに、値が定義済のLOVの名前に変換される属性を定義する必要があります。この属性をビュー・オブジェクトに追加していない場合は、ドロップダウン・リストに<未指定>が表示されることを確認してください。この場合、実行時にアプリケーションのLOV有効属性にデフォルトのLOVが表示され、別のLOVを適用することはできません。

8. 実行時に適用されるデフォルトのLOVを変更するには、目的のLOV定義に対応する「デフォルト」ラジオ・ボタンを選択します。

デフォルトで選択されたLOVにより、「値リストの切替え」ドロップダウン・リストに<未指定>が表示されている場合にアプリケーションに表示される値リストが決定します。最初は、概要エディタの「値リスト」セクションの1つ目のLOVがデフォルトになります。

9. アプリケーションが様々なLOVリストを表示するために使用するコンポーネントを変更するには、「リスト・タイプUIヒント」ドロップダウン・リストから目的のコンポーネントを選択します。

選択したコンポーネントがすべてのLOVリストに適用されます。使用可能なコンポーネントの詳細は、表5-2を参照してください。

5.12.4 LOVを定義して参照属性を表示する方法

ビュー・オブジェクトで定義する参照属性は適切な属性である場合があり、LOVリストのソースとして使用されます。ビュー・オブジェクトに追加したセカンダリ・エンティティ・オブジェクト慣用名に参照属性は属し、エンティティ・オブジェクトの慣用名の主キー属性よりも意味のある情報を示します。たとえば、OrderInfoビュー・オブジェクトを作成すると、ビュー・オブジェクトによりPaymentOptionsEO用にセカンダリ・エンティティ・オブジェクトの慣用名が定義され、エンド・ユーザーがアカウントに追加したクレジット・カードのリストを含めて、順序用に請求情報が含まれる場合があります。

セカンダリ・エンティティ・オブジェクト用に定義したLOVは、プライマリ属性値を更新できる必要がありますが、エンド・ユーザーにとって意味のあるように、通常プライマリ属性はリストで非表示にし、かわりに参照属性を1つ以上表示します。この場合、LOVではクレジット・カードのリストが会社名別に表示される場合がありますが、エンド・ユーザーの選択により更新される支払いオプションID値は非表示になる場合があります。図5-38は、InstitutionName参照属性が定義されたLOVを示します。「値リストの作成」ダイアログの「リスト戻り値」セクションでは参照属性をリストしてから主キー属性のPaymentOptionIdをリストし、追加値を用意します。

図5-38 参照属性が指定されている「ビュー基準の作成」ダイアログ

始める前に:

セカンダリ・エンティティ・オブジェクトの慣用名における参照属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- エンティティ・ベースのビュー・オブジェクトを作成して、「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従い、目的のLOV属性を定義するセカンダリ・エンティティ・オブジェクトの慣用名を追加します。デフォルトでは、セカンダリ・エンティティ・オブジェクトの慣用名には、LOVで更新する主キー属性が含まれています。

LOVの参照属性を定義するには:

1. 「アプリケーション」ウィンドウで、LOVとして有効にするセカンダリ・エンティティ・オブジェクトの慣用名が含まれているビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、LOVを表示する適切な参照属性を選択し、「値リスト」タブをクリックして、「値リストの追加」ボタンをクリックします。

概要エディタの属性リストで現在選択している属性にLOVを作成するには、「値リストの作成」ダイアログを使用します。JDeveloperにより、LOVの使用方法を識別する一意の名前が割り当てられます。たとえば、属性SupplierDescのメタデータでは、この属性がLOV対応であることを示すSupplierDescLOVという名前が指定されます。

4. 「値リストの作成」ダイアログで、「新規ビュー・アクセッサの作成」ボタンをクリックし、現在編集中のビュー・オブジェクトにビュー・アクセッサを追加します。

または、「リスト・データソース」を展開し、既存のアクセッサから選択できます。ドロップダウン・リストには、編集中のビュー・オブジェクトに追加したすべてのアクセッサが表示されます。

5. 「ビュー・アクセッサ」ダイアログで、属性のデータソースを定義するビュー・オブジェクト定義または共有ビュー・インスタンスを選択し、それをビュー・アクセッサ・リストに移動します。

デフォルトでは、作成したビュー・アクセッサにはビュー・オブジェクトと同じ名前が表示されます。アクセッサ名を編集して一意の名前を付けることができます。たとえば、SuppliersViewビュー・オブジェクトにSuppliersViewAccessorという名前を割り当てます。

6. 「OK」をクリックして、ビュー・オブジェクトのビュー・アクセッサ定義を保存します。

7. 「値リストの作成」ダイアログで、「リスト・データソース」を展開し、ベース・ビュー・オブジェクトに対して作成したデータ・ソースとして使用するビュー・アクセッサを選択します。次に、このビュー・アクセッサから、LOV有効属性のリスト・データを取得する同じ属性を選択します。

エディタにより、リスト・データソース属性とLOV有効属性の間のデフォルト・マッピングが作成されます。たとえば、PurchaseOrdersViewビュー・オブジェクトの属性SuppliersDescは、SuppliersViewAccessorビュー・アクセッサの属性SuppliersDescにマップされます。

このエディタでは、リストが定義されている属性のデフォルト属性マッピングは削除できません。

8. リストによりベース・ビュー・オブジェクトに戻される値を追加で指定する場合、「リスト戻り値」セクションの「戻り属性マップを作成します」ボタンをクリックし、目的のベース・ビュー・オブジェクト属性をビュー・アクセッサによりアクセスされる属性にマップします。

あわせて更新するため、属性のリスト選択をユーザーには要求せず、現在の行で決定している属性値を必要とする場合、追加属性の戻り値が便利です。たとえば、PurchaseOrdersViewビュー・オブジェクトの属性SupplierAddressをマップする場合は、SuppliersViewAccessorビュー・アクセッサの属性SupplierAddressを選択します。

9. 「OK」をクリックします。

5.12.5 ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法

LOVとして定義するビュー・オブジェクト属性がユーザー・インタフェースにどのように表示されるかが明確な場合は、LOVの追加プロパティを指定してその表示特性を指定できます。これらのプロパティ(UIヒント)により、ADFビジネス・コンポーネントで任意のビュー・オブジェクト属性に設定できる属性ヒント・プロパティを拡張できます。LOV有効属性のLOV UIヒントには、ユーザー・インタフェースでリストの表示に使用されるコンポーネントがあります。使用可能なコンポーネントの詳細は、表5-2を参照してください。(表5-2に示すように、すべてのADF Facesコンポーネントがデフォルトのリスト・タイプをサポートしているとはかぎりません。)

表5-2 リスト・タイプのUIヒントのリスト・コンポーネント・タイプ

LOVのリスト・コンポーネント・タイプ

用途

選択リスト

このコンポーネントでは、ドロップダウン・リストからの選択のみ可能で、テキスト入力はできません。

コンボ・ボックス

このコンポーネントでは、テキスト入力もドロップダウン・リストからの選択も可能です。このコンポーネントでは、ユーザーによる入力にオートコンプリートがサポートされる場合があります。

このコンポーネントは、ADF Facesではサポートされていません。

値リストを持つコンボ・ボックス

このコンポーネントは、一番下にあるエントリ(「詳細」)を選択すると、UIヒントのLOV属性に対して有効にした場合に問合せでフィルタリングがサポートされる「値リスト」参照ダイアログが開くこと以外は、コンボ・ボックスと同じです。デフォルトのUIヒントでは、すべての属性に対して問合せが有効になります。

ただし、LOV属性が表コンポーネントに表示される場合、リスト・タイプは、「値リストを使用した入力テキスト」コンポーネントに変わります。

値リストのある入力テキスト

このコンポーネントでは、横にLOVボタンのある入力テキスト・フィールドが表示されます。このボタンをクリックするか、テキスト・フィールドに無効な値を入力すると、「値リスト」参照ダイアログが表示されます。このコンポーネントの「値リスト」ダイアログでは、UIヒントのLOV属性に対して有効にした場合に、問合せでフィルタリングがサポートされます。デフォルトのUIヒントでは、すべての属性に対して問合せが有効になります。

このコンポーネントでも、一致対象が1つになる場合は、オートコンプリートがサポートされます。

リスト・ボックス

このコンポーネントでは、(ユーザーがクリックするまで1行分の領域しか表示されない選択リストとは異なり)画面上に一定の大きさの領域が表示され、スクロール操作が可能です。

ラジオ・グループ

このコンポーネントには、LOV属性値で指定した選択項目で構成されるラジオ・ボタン・グループが表示されます。このコンポーネントは、項目の少ない固定リストには非常に有用です。

始める前に:

LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、属性のLOVリストを作成します。

LOV有効属性に対してビュー・オブジェクト属性のUIヒントを設定するには:

1. 「アプリケーション」ウィンドウで、カスタマイズする属性を含むビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、目的の属性を選択し、「値リスト」タブをクリックします。

4. 「値リスト」ページで、カスタマイズするLOVリストを選択し、「値リストの編集」ボタンをクリックします。

5. 「値リストの編集」ダイアログで、「UIヒント」タブをクリックします。

6. 「UIヒント」ページで、リストを表示するコンポーネントのタイプとして、「デフォルトのリスト・タイプ」を選択します。
使用可能なコンポーネントの詳細は、表5-2を参照してください。

Webページに表示されるリスト・コンポーネントと、ビュー・オブジェクトのデフォルトのリスト・タイプは実行時に一致する必要があり、一致しない場合は実行時例外(method-not-found)が発生します。このエラーを回避するには、ユーザー・インタフェース・デザイナで目的のリスト・コンポーネントを確認します。これらが一致するようにデフォルト・リストを編集できるので、その後ユーザー・インタフェース・デザイナでWebページで使用されるコンポーネントを変更しても、2つの同期が維持されます。

7. 必要に応じて、さらに「属性の表示」を選択し、値を表示に追加します。
追加属性のリストは、LOV有効属性のビュー行から導出されます。追加属性の値を使用すると、エンド・ユーザーによるリストからの項目選択が容易になります。

8. 「値リストを使用したコンボ・ボックス」タイプ・コンポーネントを選択すると、デフォルトでは、コンポーネントのドロップダウン・リストにはデータ・ソースから最初の10レコードが表示されます。この制限により、ビュー・オブジェクトの小さいフェッチ・サイズも維持できます。「値リストを使用したコンボ・ボックス」コンポーネントのドロップダウン・リストに表示できるレコード数を変更するには、「問合せ限度」にレコード数を入力します。
ユーザーがレコードの全セットを表示できるようにする場合は、その目的に「問合せ限度」を使用しないでください。「問合せ限度」は、ビュー・オブジェクトでフェッチされる行数も制御(ビュー・オブジェクト定義のListRangeSizeプロパティを設定)しているため、最適なパフォーマンスを実現するうえで、この値は小さくしておく必要があります。レコードの全セットにアクセスする必要のあるエンド・ユーザーは、コンポーネントの参照アイコンをクリックしてLOV参照ダイアログを開き、そこでレコードを表示するようにしてください。

「問合せ限度」は、他のすべてのコンポーネント・タイプでは無効になっており、これらのコンポーネントでは、LOVがアクセスする行数は制限されません。

ListRangeSizeプロパティの詳細は、「実行時に行われる処理: LOVでリスト・データソースを問い合わせる方法」を参照してください。

9. 値リストの参照ダイアログを開いてユーザーが値リストを選択できるようにするコンポーネント・タイプ(「値リストを使用したコンボ・ボックス」タイプ・コンポーネントや「値リストを使用した入力テキスト」タイプ・コンポーネントを含む)を選択した場合、参照ダイアログには、データ・ソース・ビュー・オブジェクトのすべての問合せ可能属性を検索できる検索フォーム(LOV有効属性のビュー・アクセッサによって定義されたもの)が表示されます。これらのコンポーネントのカスタマイズ方法を指定します。

a. 「値リストを使用したコンボ・ボックス」タイプ・コンポーネントを選択し、「選択されたもの」リストに多数の属性を追加済の場合は、「コンボ・ボックスに表示」を使用してこのコンポーネントのドロップダウン・リスト部分を読みやすくします。「値リストを使用したコンボ・ボックス」コンポーネントに表示されるドロップダウン・リストに含まれる属性列を制限するには、「コンボ・ボックスに表示」から「最初」を選択し、ドロップダウン・リストに表示する、「選択されたもの」リストの最上部からの属性の数に対応する数字を入力します(この組合せでは、「値リストの作成」ダイアログの「選択されたもの」リストから表示する最初のx個の属性を指定します)。ドロップダウン・リストに表示される属性列数を制限することにより、ユーザーは完全なリストを確認するために水平にスクロールする必要がなくなりますが、これによって「値リスト」参照ダイアログに表示される属性列の数が制限されるわけではありません。このオプションは、「値リストを使用したコンボ・ボックス」を除くすべてのリスト・コンポーネント・タイプで無効にされています。

b. 「検索リージョンを含む」ドロップダウン・リストからビュー基準を選択すると、「値リスト」参照ダイアログに表示する属性を制限できます。ドロップダウン・リストにビュー基準を表示するには、そのビュー基準がデータソース・ビュー・オブジェクト(LOV有効属性のビュー・アクセッサで定義したオブジェクト)で定義されている必要があります。選択したビュー基準の検索フォーム・プロパティを設定するには、「ビュー基準の編集」ボタンをクリックします。検索フォームのビュー基準のカスタマイズの詳細は、「ビュー基準にユーザー・インタフェース・ヒントを設定して検索フォームをサポートする方法」を参照してください。

c. 「リストを自動的に問合せ」を選択すると、「値リスト」参照ダイアログの結果表に事前に移入できます。ユーザーが「値リスト」参照ダイアログを開くと、問合せの結果が表示されます。このオプションの選択を解除したままだと、ユーザーが検索フォームを送信するまで結果は表示されません。

10. また、「値リスト」参照ダイアログに検索リージョンを表示したくない場合は、「検索リージョンを含む」ドロップダウン・リストから<検索なし>を選択します。この場合、「値リスト」参照ダイアログには、「属性の表示」リストに追加した属性しか表示されません。

11. リストに表示する選択タイプ・コンポーネントを選択した場合は、選択可能なすべての値を表示する代替手段として、「最近使用されたカウント」を指定できます。
たとえば、発注書に入力するSupplierId値の選択リストがフォームに表示されることがあります。このケースでは、最近表示されたサプライヤのリストからユーザーが選択できるようにし、入力するカウント数によってサプライヤの選択肢の数を指定できます。デフォルトのカウント0(ゼロ)では、選択リストに属性のすべての値が表示されます。

12. リストを表示するコンポーネントとして「値リストを使用したコンボ・ボックス」タイプを選択した場合、「コンボ・ボックスのフィルタ基準」ドロップダウン・リストからビュー基準を選択し、LOVに表示される有効な値のリストを制限できます。
「コンボ・ボックスのフィルタ基準」を有効にすると、ドロップダウン・リストには、LOVのビュー・アクセッサに関連するビュー・オブジェクト定義から既存のビュー基準が表示されます。ドロップダウン・リストにビュー基準が表示されない場合は、データ・ソース・ビュー・オブジェクトにビュー基準が定義されていません。この機能を有効にしない場合、「値リストを使用したコンボ・ボックス」コンポーネントは、ビュー・アクセッサから戻された完全な行セットからその値を導出します。「値リストを使用したコンボ・ボックス」のフィルタは、ポップアップ検索ダイアログでLOVを使用する場合や、有効な選択肢が限定されたドロップダウン・リストでLOVを使用する場合に便利な機能です。ユーザー・インタフェースでの「値リストを使用したコンボ・ボックス」コンポーネントの使用の詳細は、「値リスト(LOV)入力フィールド」を参照してください。

13. リスト・コンポーネントに表示されるNULL値の選択肢をリスト・コンポーネントが処理する方法を決定します。このオプションは、選択可能なすべてのリスト・コンポーネント・タイプで有効にされていません。
「"選択なし"アイテムを含める」を有効にすると、ドロップダウン・リストから選択して、NULL値の選択肢がリストに表示される方法も決定できます。たとえば、ラベル付きアイテムを選択する場合は、ドロップダウン・リストの編集フィールドに目的のラベルを入力するか、「...」ボタン(編集フィールドの右)をクリックしてビュー・オブジェクトに関連付けられているリソース・バンドルからメッセージ文字列を選択することができます。リソース・バンドルからメッセージ文字列を選択すると、この文字列に対応するメッセージ・キーがビュー・オブジェクト定義ファイルに保存されます。実行時に、UIはこの文字列を特定し、現在のユーザーのロケール設定とローカライズされたリソース・バンドルのメッセージ・キーに基づいて表示します。

14. 「OK」をクリックします。

5.12.6 リスト・タイプUIコンポーネントの日付変換処理方法

ビュー・オブジェクトのLOV有効属性が日付情報(属性OrderShippedDateなど)にバインドされている場合、Oracle ADFでは、デフォルトで、日付と時間を組み合せたyyyy-MM-dd hh:mm:ssのようなフィールドのフォーマットとみなされます。この日付と時間を組み合せたフォーマットは、ADFビジネス・コンポーネントDateドメイン・クラス(jbo.domain.Date)で指定されており、ユーザーがLOV有効属性によって指定される日付を選択するとADF Facesコンポーネントの変換の問題が生じます。ADF Facesコンポーネントがドメイン・タイプをDateタイプに変換できない場合、ユーザー・インタフェースによって入力フィールドが無効にされ、エラー: 日付の書式が正しくありません。というメッセージが表示されます。

このような変換エラーの発生を回避するために、LOVを有効にするビュー・オブジェクトの日付値属性に対してUIヒントを構成します。指定するUIヒントでは、yyyy-MM-ddのような日付のみのマスクを定義します。その後、この属性を参照するADF Facesコンポーネントは、そのEL値バインディング式(#{bindings.Hiredate.formatなど)によって指定されたパターンに基づいて変換を実行し、ADFビジネス・コンポーネント・ドメインの日付/時間ではなく、UIヒント・フォーマットを参照します。変換エラーは、フォーマット・マスクが指定されていないために、EL式でNULLと評価された場合に発生します。

始める前に:

LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

UIヒントをビュー・オブジェクトのレベルでサポートすることに関する知識が役立つ場合があります。UIヒントの詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、属性のLOVリストを作成します。

LOV有効属性の日付フォーマットに一致するUIヒントを設定するには:

1. 「アプリケーション」ウィンドウで、LOV有効属性が含まれているビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、UIヒントを使用してカスタマイズする日付値属性を選択し、「UIヒント」タブをクリックします。

4. 「UIヒント」ページで、「簡単な日付」を「フォーマット・タイプ」で選択し、日付のみのマスクのフォーマットを選択します。

ADFビジネス・コンポーネント・ドメイン・タイプと、使用可能なフォーマッタとのマッピングは、JDeveloperシステム・ディレクトリのBC4Jサブディレクトリにあるformatinfo.xmlファイルで指定されます(たとえば、C:\Documents and Settings\<username>\Application Data\JDeveloper\system<version#>\o.BC4J.\formatinfo.xml)。

5.12.7 ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法

ビュー・アクセッサがデータベース表から常に最新のデータを問い合せるようにする必要がある場合は、データ・ソース・ビュー・オブジェクトで「自動リフレッシュ」プロパティを設定できます。このプロパティにより、データベースが変更されると、ビュー・オブジェクト・インスタンスを自動的にリフレッシュできます。アプリケーション・モジュールで定義する読取り専用ビュー・インスタンスに対して、この機能を有効にできます。ビュー・オブジェクトでこのプロパティを有効にすると、ユーザーがデータベース表にコミットする変更は、同一のデータベース表を利用して作業しているすべての他のユーザーに利用可能になります。一般的には、ビュー・アクセッサにLOV有効ビュー・オブジェクト属性を定義するときに、データソース・ビュー・オブジェクトの自動リフレッシュが有効にされます。

自動リフレッシュ機能はOracle Databaseの変更通知機能を使用するため、ビュー・オブジェクトで自動リフレッシュを有効にする場合は、これらの制限事項に従ってください。

- ビュー・オブジェクトで読取り専用の表のみ問い合せて、表の数をできるだけ少なくしてください。これにより、パフォーマンスが最適化され、データベースで無効なキューが増大するのを防ぐことができます。

- 更新可能な自動リフレッシュ・ビュー・インスタンスが含まれるアプリケーション・モジュールは、共有し、更新中に行をロックするように構成します。

- データベース・ユーザーに、データベースの通知権限があることを確認します。たとえば、SQL*Plusコマンドを使用して通知権限を付与するには、grant change notification to <ユーザー名>を使用します。

- ビュー・オブジェクトの自動リフレッシュを有効にする前に、問合せで問合せ結果変更通知との互換性をテストします。すべての問合せ定義が、問合せ結果変更通知の要件を満たすとはかぎりません。

ビュー・オブジェクトの自動リフレッシュを有効にし、これらの制限事項に従うと、Oracleデータベースの変更通知機能によってリフレッシュが実行されます。実行時のビュー・オブジェクト問合せの実行前に、このフレームワークではJDBC APIを使用してビュー・オブジェクト問合せを登録し、基礎となるデータの変更に関するデータベース変更通知を受け取ります。(基礎となるデータが変更されたため)ビュー・オブジェクトが通知を受け取ると、ビュー・オブジェクトの行セットはダーティとしてマークされ、このフレームワークではクライアントから中間層への次のサーバー・トリップでこの行セットがリフレッシュされます。この時点で、ダーティ・コレクションは破棄され、更新されたデータがリクエストされると、ビュー・オブジェクトによって新しい問合せ実行がトリガーされます。アプリケーション・モジュールは次のチェックアウトまで待機するため、現在のトランザクションの行セットの状態が維持され、更新によってエンド・ユーザーの操作が妨げられることはありません。

たとえば、ユーザーはカレンダのエントリを作成または編集可能で、他のユーザーが追加したカレンダ・エントリの編集はできないとします。ユーザーが新しいエントリを作成し、コミットすると、同じサーバー・トリップで、他のユーザーが変更または入力したカレンダ・エントリが更新されます。しかし、もう1人のユーザーがカレンダ・エントリを作成すると、ビュー・オブジェクトは通知を受け取り、次のサーバー・トリップまで待機してからリフレッシュを行うため、この更新実行までの遅延により、同じデータを読み取る複数のユーザー間の競合を回避できます。

別の例では、LOVに郵便番号リストが表示されており、データベース管理者が読取り専用の方法で管理しています。管理者が新しい郵便番号をデータベースの行として追加すると、アプリケーション・モジュールが残っているリクエストがない時を検出し、郵便番号リストにアクセスするビュー・インスタンスに対して保留中の通知がないことを判断します。その時点で、ビュー・オブジェクトはデータのリフレッシュを行い、それ以降のすべてのリクエストは新しい郵便番号を参照します。

注意:

Webアプリケーションには、オプティミスティック行ロックを使用します。デフォルト構成で設定されているオプティミスティック・ロックでは、相互に影響を与えずに複数のトランザクションを完了できることが前提になります。したがって、オプティミスティック・ロックにより、リフレッシュ対象の行をロックせずに自動リフレッシュを開始できます。ペシミスティック行ロックでは、行セットのリフレッシュは妨げられ、行セットに保留中のトランザクションがある場合(たとえば、ユーザーが新しい行を追加中の場合)は例外がスローされます。アプリケーション・モジュール構成でオプティミスティック行ロックを確実に使用するには、adf-config.xml概要エディタの「ビジネス・コンポーネント」ページを開き、「ロック・モード」 (jbo.locking.modeプロパティに対応)がoptimisticに設定されていることを確認します(「Fusion Webアプリケーションがオプティミスティック・ロックを使用していることを確認する方法」を参照。)

始める前に:

LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

問合せ結果変更通知に問合せを登録するための問合せ定義要件について理解しておくことが役立つ場合があります。詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』の「連続問合せ通知の使用」の章を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要もあります。

- 「エンティティ・オブジェクトまたはビュー・オブジェクトのビュー・アクセッサの作成方法」の説明に従って、ビュー・アクセッサを作成します。

データ変更通知を受け取るビュー・オブジェクトを登録するには:

1. 「アプリケーション」ウィンドウで、データベースの変更通知を受け取るビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「問合せ」ナビゲーション・タブをクリックします。

3. 「問合せ」ページで、「テストおよび説明」をクリックします。

4. 「問合せのテスト」ダイアログで、「変更通知」タブをクリックして、問合せがOracle Databaseの変更通知と互換であることを確認します。

「問合せのテスト」ダイアログに、問合せが変更通知の互換性に合格しないことが表示された場合は、ビュー・オブジェクトに対して自動リフレッシュを有効にできません。すべての問合せ定義が、問合せ結果変更通知の要件を満たすとはかぎりません。詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』の「連続問合せ通知の使用」の章を参照してください。

5. 問合せが変更通知と互換の場合は、概要エディタで、「一般」ナビゲーション・タブをクリックします。

6. 「プロパティ」ウィンドウで「チューニング」セクションを開き、「自動リフレッシュ」ドロップダウン・リストから「True」を選択します。

「プロパティ」ウィンドウに「チューニング」セクションが表示されない場合は、概要エディタの「一般」ナビゲーション・タブをクリックし、適切なフォーカスを設定します。

5.12.8 Oracle ADFモデル・テスターを使用してLOV有効属性をテストする方法

ビュー・オブジェクト属性に作成したLOVをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。

Oracle ADFモデル・テスターでは、「値リスト」ダイアログの「UIヒント」ページで選択可能な2つのコンポーネント・タイプのいずれかを使用して、参照するビュー・オブジェクト・インスタンスについてLOVが有効な属性が表示されます。現時点では、選択リストのコンポーネント・タイプと値リストのある入力テキストのコンポーネント・タイプのみがサポートされています。それ以外の場合は、Oracle ADFモデル・テスターによってデフォルトの選択リストのタイプが使用され、LOV有効属性が表示されます。

始める前に:

LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

Oracle ADFモデル・テスターを使用してLOVをテストするには:

1. 「アプリケーション」ウィンドウで、目的のアプリケーション・モジュールおよびビュー・オブジェクトを含むプロジェクトを開きます。

2. アプリケーション・モジュールを右クリックし、「実行」を選択します。

3. Oracle ADFモデル・テスターで、左側のセクションから目的のビュー・オブジェクトを選択します。Oracle ADFモデル・テスターには、リスト値のある入力テキストのUIヒントとしてコンポーネント・タイプを指定しないかぎり、LOV有効属性値がドロップダウン・リストとして表示されます。

図5-39は、入力テキスト・フィールドと、UIヒント・リスト・タイプとしての値リスト・ダイアログを指定する、CustomerVOのLOV有効属性SalesRepIdを示しています。「値リストを使用した入力テキスト」コンポーネントは、独立したLOVダイアログに選択肢を表示する場合に便利です。他のリスト・タイプはOracle ADFモデル・テスターではサポートされていません。

図5-39 Oracle ADFモデル・テスター内のLOV有効属性の表示

5.12.9 ビュー・オブジェクト属性のLOVの定義時の処理

ビュー・オブジェクト属性に対してLOVを定義する場合、ビュー・オブジェクト・メタデータにより、次のように追加情報が定義されます(CustomerVO.SalesRepId属性に関する次の例を参照)。

- <ViewAttribute>要素では、属性に名前を付けてLOV動作を定義するリスト・バインディング要素を指し、Webページに表示するコンポーネント・タイプを指定します。たとえば、LOV有効属性のSalesRepIdは、LOV_SalesRepIdという名前のリスト・バインディングを指し、LOVデータを表示するリスト(input_text_lov)を使用してCONTROLTYPE入力テキスト・フィールドを定義します。
ユーザー・インタフェース・デザイナで「データ・コントロール」パネルを使用してWebページを作成する場合、JDeveloperによってWebページに追加されるコンポーネントは、<CONTROLTYPE Value="namedType"/>定義によって決定されます。データ・モデル・プロジェクトのコンポーネント・タイプ定義とWebページに表示されるコンポーネント・タイプが一致しない場合は、ランタイム例外が発生します。詳細は、「実行時に行われる処理: LOVでリスト・データソースを問い合わせる方法」を参照してください。

- <ListBinding>要素では、LOVの動作を定義します。また、LOV有効属性のデータソースにアクセスするためのビュー・アクセッサも指定します。ビュー・アクセッサとは、データソース・ビュー・オブジェクトの行セットから可能な値のリストを取得するためのADFビジネス・コンポーネントのメカニズムです。たとえば、ListVOName="EmpVO1"は、ビュー・オブジェクトEmpVOにアクセスするEmpVO1ビュー・アクセッサを指します。

- <ListBinding>要素では、リスト・データソース属性をLOV有効属性にマップします。たとえば、ListAttrNames項目のIdは、LOV有効属性SalesRepIdにマップされます。

- <ListBinding>要素では、現在行から表示する属性を1つ以上指定し、選択リスト・タイプのコンポーネントに固有のオプションも指定します。たとえば、ListDisplayAttrNames項目のFirstNameとLastNameは、LOV有効属性SalesRepIdによって表示される追加の属性です。この例では、NullValueFlagのnone値は、リストから空白項目を選択できないことを意味します。

<ViewAttribute
Name="SalesRepId"
LOVName="LOV_SalesRepId"
PrecisionRule="true"
EntityAttrName="SalesRepId"
EntityUsage="CustomerEO"
AliasName="SALES_REP_ID">
<Properties>
<SchemaBasedProperties>
<LABEL
ResId="oracle.summit.model.views.CustomerVO.SalesRepId_LABEL"/>
<CONTROLTYPE
Value="input_text_lov"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>
. . .
<ListBinding
Name="LOV_SalesRepId"
ListVOName="EmpVO1"
ListRangeSize="10"
NullValueFlag="none"
MRUCount="0">
<AttrArray Name="AttrNames">
<Item Value="SalesRepId"/>
</AttrArray>
<AttrArray Name="ListAttrNames">
<Item Value="Id"/>
</AttrArray>
<AttrArray Name="ListDisplayAttrNames">
<Item Value="Id"/>
<Item Value="FirstName"/>
<Item Value="LastName"/>
</AttrArray>
<DisplayCriteria
Hint="hide"/>
</ListBinding>
. . .
<ViewAccessor
Name="EmpVO1"
ViewObjectName="oracle.summit.model.views.EmpVO"
OrderBy="EmpEO.LAST_NAME">
<ViewCriteriaUsage
Name="FilterByTitleIdVC"
FullName="oracle.summit.model.views.EmpVO.FilterByTitleIdVC"/>
<ParameterMap>
<PIMap Variable="TitleIdBind">
<TransientExpression><![CDATA[2]]></TransientExpression>
</PIMap>
</ParameterMap>
</ViewAccessor>

5.12.10 実行時に行われる処理: LOVでリスト・データソースを問い合せる方法

ADFビジネス・コンポーネント・ランタイムにより、ビュー行およびエンティティ・オブジェクトの属性セッターにビュー・アクセッサが追加され、LOV有効属性の動作が実現されます。ユーザー・インタフェースにLOVが有効な属性値を表示するために、LOVの機能によりデータソースをフェッチし、該当する行の属性とマップされたターゲット属性を検索します。データ・バインドされたリスト・コンポーネントのデフォルトのAutoSubmitプロパティ設定はfalseで、エンド・ユーザーが値を選択した場合にのみブラウザでサーバーとのラウンドトリップが行われるようになっています。ラウンドトリップの結果、ADFモデル・レイヤー内の同じLOV有効属性から派生したすべてのリスト・バインディングが更新され、ユーザー・インタフェースの対応するリスト・コンポーネントにエンド・ユーザーの選択が反映されます。

LOV機能によりフェッチされるデータ・オブジェクト数は、部分的には、ビュー・オブジェクトの概要エディタの属性に表示される「値リストの編集」ダイアログで指定される、LOV有効属性のリスト・バインディング定義のListRangeSize設定で決定されます。デフォルトで、LOV問合せでは、すべてのリスト・コンポーネント・タイプ(LOVタイプと非LOVタイプのリスト・コンポーネントを含む)でレコードが打ち切られることなくフェッチされます。ListRangeSizeで指定されるデフォルト値-1は、ユーザーがデータ・ソースからすべてのデータ・オブジェクトを表示できることを意味します。ただし、フェッチされたレコードの数が多く、リスト・コンポーネントでのレコード表示で一部の値を切り捨てたい場合は、ListRangeSizeでフェッチするレコード数の値を指定します。ListRangeSize値は、2つのLOVタイプのコンポーネントに対して表示される参照ダイアログでエンド・ユーザーが検索できるレコードに影響を与えません。各リスト・コンポーネントによる値の表示方法の詳細は、「ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法」を参照してください。

<ListBinding>要素のメタデータ定義でListRangeSize値を変更することもできますが、値を別のレコード数(ListRangeSize="5"など)に設定すると、必要な選択項目が表示されなくなる可能性が高くなります。かわりに、値を-1 (リスト・コンポーネントのデフォルト)にすると、リスト・コンポーネントが表示するレコード数に制限は設定されず、ユーザーは完全な値セットにアクセスできます。

パフォーマンスに関するヒント

値セットを制限するために、LOV表示では、「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」で説明するように、ビュー・アクセッサを使用してLOVバインディングをフィルタリングします。また、選択リストを表示するコンポーネント・タイプの場合は、「ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法」で説明するように、「最近使用されたカウント」設定を変更して、ユーザーが前に選択した項目のリスト表示を制限できます。

ビュー・オブジェクトのCONTROLTYPE定義に一致しないLOV有効属性のUIコンポーネントがWebページに表示されると、ランタイム例外が発生します。ユーザー・インタフェース・デザイナで、「データ・コントロール」パネルを使用してJDeveloperのページを作成すると、「リスト・タイプUIヒント」ダイアログで、ビュー・オブジェクトのLOV有効属性に対して「デフォルトのリスト・タイプ」で指定したリスト・コンポーネントが自動的に挿入されます。ただし、Webページの作成後にユーザー・インタフェース・デザイナでリスト・タイプを変更した場合は、「リスト・タイプUIヒント」ダイアログで選択した項目が一致するように編集する必要があります。

5.12.11 リストに関する必知事項

ビュー・オブジェクトの属性に定義するLOVについていくつか知っておく必要があります。たとえば、既存のビュー・オブジェクトの展開による、親ビュー・オブジェクトから子ビュー・オブジェクトへのLOVが有効な属性を伝播する方法や、LOVのかわりにバリデータを使用して値リストを管理するケースなどがあります。

5.12.11.1 親ビュー・オブジェクト属性からのAttributeDefプロパティの継承

ビュー・オブジェクトにより他のビュー・オブジェクトが拡張される場合、ベース・オブジェクトにLOVが有効な属性を作成できます。概要エディタで子ビュー・オブジェクトを定義すると、対応するビュー・オブジェクト属性にLOV定義が表示されます。この継承メカニズムにより、LOVが有効な属性を1回定義し、後で同じ属性の複数のビュー・オブジェクト・インスタンス全体にその属性を適用できます。

また、概要エディタを使用して継承LOV定義を拡張できます。たとえば、ベース・ビュー・オブジェクトの問合せによりすでに定義されている属性を追加して、選択リストに表示できます。あるいは、カスタムのWHERE句を使用するビュー・オブジェクトを定義して、ベース・ビュー・オブジェクトによりまだ問合せされていない追加属性を問合せできます。エンティティ・ベース・ビュー・オブジェクトのカスタマイズの詳細は、「バインド変数の使用」を参照してください。

5.12.11.2 バリデータを使用した属性値の検証

ビュー・オブジェクトにLOVが有効な属性を作成した場合、リスト・バリデータを使用して属性を検証する必要はありません。ユーザー・インタフェースにリストを表示せず、有効値のリストを制限する必要がある場合のみ属性バリデータを使用します。リスト検証は、単純な静的データ、または定義するビュー・アクセッサから取得した使用可能な値のリストです。UIに表示された属性がキー値(主キー、外部キー、または代替キー)を参照する属性の場合には、キーの存在検証を使用します。ADF Business Componentsでの宣言的な検証の詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

5.13 ビュー・オブジェクトのUIヒントの定義

ADFビジネス・コンポーネントの組込み機能の1つに、ビュー・オブジェクトとビュー・オブジェクトの属性についてのUIヒントを定義する機能があります。UIヒントは、ロケールに依存した一貫性のある方法で問合せ情報を自動表示する際にビュー・レイヤーで使用される設定です。たとえば、Webページでは、bindingsネーム・スペースで定義されADFバインディング・インスタンス名に対して指定されたEL式ユーティリティ・メソッドを入力することによりUIヒント値にUI開発者はアクセスできます。

JDeveloperでは、多言語アプリケーションを容易にローカライズできるリソース・バンドル・ファイルにヒントを格納します。

5.13.1 属性固有のUIヒントの追加方法

ビュー・オブジェクトのUIヒントを作成するには、「アプリケーション」ウィンドウからアクセスできる、ビュー・オブジェクトの概要エディタを使用します。また、属性の「プロパティ」ウィンドウを表示してUIヒントを表示および編集することもできます。

始める前に:

属性UIヒントの知識があると役立ちます。詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

UIヒントを使用してビュー・オブジェクト属性をカスタマイズするには:

1. 「アプリケーション」ウィンドウで、UIヒントをカスタマイズするビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、UIヒントを使用してカスタマイズする属性を選択し、「UIヒント」タブをクリックし、適切なヒントを定義します。

たとえば、UserIdという属性の場合、その「ラベル・テキスト」ヒントにIdなどの値を入力するか、または「フォーマットの種類」を「Number」に設定し、「フォーマット」にフォーマット・マスクとして00000と入力します。

注意:

Javaで定義される数値および日付のフォーマット・マスクの標準セットは、OracleデータベースのSQLおよびPL/SQL言語によって使用されるものとは異なります。詳細は、java.text.DecimalFormatおよびjava.text.SimpleDateFormatクラスのJavadocを参照してください。

5.13.2 ビュー・オブジェクトUIヒントの追加方法

ビュー・オブジェクトのUIヒントを作成するには、「アプリケーション」ウィンドウからアクセスできる、ビュー・オブジェクトの概要エディタを使用します。ビュー・オブジェクトで表示する「プロパティ」ウィンドウを使用しても、複数の追加のUIヒントを表示および編集できます。

始める前に:

UIヒントの知識があると役立ちます。詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

UIヒントを使用してビュー・オブジェクトをカスタマイズするには:

1. 「アプリケーション」ウィンドウで、UIヒントをカスタマイズするビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

3. 「一般」ページで、「表示名」を入力し、ビュー・オブジェクト名に対してELでアクセス可能なヒントを定義します。

たとえば、ビュー・オブジェクトOrdersVOの場合には、「表示名」ヒントに「Order」のような値を入力できます。

4. 概要エディタで「一般」ページを表示したまま、ビュー・オブジェクトの「プロパティ」ウィンドウを開き、「UIヒント」セクションを開いて、必要に応じて追加のヒントを入力します。

たとえば、ビュー・オブジェクトOrdersVOに対しては、「表示名(複数)」ヒントに「Orders」のような値を入力し、「説明」ヒントには「customer orders」のような値を入力できます。

5.13.3 EL式を使用してUIヒントにアクセスする方法

UI開発者は、EL式を使用してUIヒントにアクセスし、Webページにデータとしてヒント値を表示できます。UIヒントには、データバインドされたコンポーネントをWebページにドロップした後に作成するADFバインディング・インスタンスを通じてアクセスできます。

ビュー・オブジェクト・ヒントの場合は、UI開発者はそのビュー・オブジェクトに対して定義済のコレクション・バインディングを介してアクセスします。たとえば、次のようなビュー・オブジェクトUIヒントを構成したとします。

- OrdersVOビュー・オブジェクト「表示名」ヒント = Order

- OrdersVOビュー・オブジェクト「表示名(複数)」ヒント = Orders

- OrdersVOビュー・オブジェクト「説明」ヒント = customer orders

UI開発者は、これらのヒントを活用するヘッダーを次のように表示できます。

Showing customer orders number 10 of 51 Orders.

次の例は、前に示したテキストを生成するEL式を示しています。このEL式では、コレクション・バインディングOrdersVO1によってビュー・オブジェクト・ヒントへのアクセスが提供されます。EL式ユーティリティ・メソッド名は、ビュー・オブジェクトXML定義ファイルのUIヒントで定義されているプロパティ名と一致します。たとえば、「表示名(複数)」ヒントを定義するビュー・オブジェクトのプロパティ名labelPluralは、式bindings.OrdersVO1.hints.labelPluralで使用されているユーティリティ・メソッド名と一致します。

<af:panelHeader id="ph1"
text="Showing #{bindings.OrdersVO1.hints.description} number
#{bindings.OrdersVO1.Orderno.inputValue} of
#{bindings.OrdersVO1.estimatedRowCount}
#{bindings.OrdersVO1.hints.labelPlural}.">

5.13.4 UIヒント追加時の処理

ビュー・オブジェクトまたはビュー・オブジェクトの属性に属性UIヒントを定義すると、属性UIヒントはデフォルトでリソース・バンドル・ファイルに格納されます。これにより、定義したヒントを生成されたユーザー・インタフェースのフォームや表に合わせてローカライズできます。

JDeveloperで使用されるリソース・バンドル・ファイルのタイプとファイルの粒度は、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページで決定されます。デフォルトでは、このオプションは「プロパティ・バンドル」に設定され、データ・モデル・プロジェクト全体に対して1つの.propertiesファイルが生成されます。たとえば、Modelプロジェクトでビュー・オブジェクトのUIヒントを定義すると、パッケージには、ModelBundle.propertiesというバンドル・ファイルがJDeveloperにより作成されます。

また、「プロジェクト・プロパティ」ダイアログでオプションを選択して、ファイルごとに1つのリソース・バンドルを生成する場合は、「アプリケーション」ウィンドウでオブジェクトを選択し、「構造」ウィンドウの対応「ソース」ノードを参照して、ビュー・オブジェクトのメッセージ・バンドル・ファイルを検証できます。「構造」ウィンドウには、「アプリケーション」ウィンドウで選択したコンポーネントの実装ファイルが表示されます。図5-40に示すように、「アプリケーション」ウィンドウで目的のビュー・オブジェクトの親パッケージを開くと、ビュー・オブジェクトのリソース・バンドル・ファイルを検査できます。

図5-40 「アプリケーション」ウィンドウのリソース・バンドル・ファイル

選択可能なリソース・バンドル・オプションの詳細は、「メッセージ・バンドル・オプションの設定方法」を参照してください。

次の例は、UIヒントの情報が表示されたメッセージ・バンドル・ファイルのサンプルを示しています。各String配列の最初のエントリはメッセージ・キーで、2番目のエントリはこのキーに対応するロケール固有のString値です。

oracle.summit.model.views.CustomerVO.Id_FMT_FORMATTER=
oracle.jbo.format.DefaultNumberFormatter
oracle.summit.model.views.CustomerVO.Id_FMT_FORMAT=00000
oracle.summit.model.views.CustomerVO.Id_LABEL=Id
oracle.summit.model.views.CustomerVO.Email_LABEL=Email Address
oracle.summit.model.views.CustomerVO.LastName_LABEL=Surname
oracle.summit.model.views.CustomerVO.FirstName_LABEL=Given Name

5.13.5 UIカテゴリ・ヒントを定義する方法

ビュー・オブジェクトにより定義する属性をグループ化する方法がUIカテゴリにより実現されます。作成したカテゴリ名は、表示用に属性をグループ化するために動的レンダリング・ユーザー・インタフェースで使用される識別子です。ユーザー・インタフェースでは、同じカテゴリの他の属性を使用して属性がレンダリングされます。カテゴリ・ヒントを使用すると、ユーザー・インタフェースによって、ビュー・オブジェクト属性の大量のリストをカテゴリで関連付けられた小さいグループに分割することが容易になります。

さらに、ユーザー・インタフェースでそのカテゴリ内で属性値がレンダリングされる方法を並べ替えるフィールド順ヒントを指定できます。たとえば、ビュー・オブジェクトで4つの属性(attributeA、attributeB、attributeCおよびattributeD)を定義し、属性ごとにそれぞれフィールド順を4、3、2および1に指定した場合、ユーザー・インタフェースでカテゴリがレンダリングされると、そのカテゴリの属性は、attributeD、attributeC、attributeBおよびattributeAの順序で表示されます。

注意:

ビュー・オブジェクトの概要エディタにある「UIカテゴリ」ページを使用して、作成したカテゴリ内にリストされる属性の順序を変更します。JDeveloperによって自動的に割り当てられ、リストの順序に基づいた属性のフィールド順値が維持されるので、数値を編集してフィールド順ヒントを定義する必要はありません。

カテゴリとフィールド順のヒントは、動的フォームと検索フォームを含めて、属性を表示するすべての動的レンダリング・ユーザー・インタフェースで使用されます。

- 動的フォームの場合、各カテゴリの属性は別のタブに表示されます。

- 検索フォームの場合、フォームの個別ビュー基準の順序は、ビュー基準アイテムのベースとなる属性に割り当てられたフィールド順とカテゴリにより決まります。

ビュー・オブジェクトの属性に対してUIカテゴリを作成するには、「アプリケーション」ウィンドウからアクセスできるビュー・オブジェクトの概要エディタを使用します。図5-41に示すように、「UIカテゴリ」ページを使用して、ビュー・オブジェクト全体でカテゴリの作成や編集ができます。

図5-41 ビュー・オブジェクトの概要エディタにおける属性の「UIカテゴリ」

「UIカテゴリ」ページに作成されたカテゴリにビュー・オブジェクト属性を割り当てると、カテゴリ・リストに表示された属性の順序によりその数値フィールド順が決まります。「UIカテゴリ」ページにより、属性をリスト内でドラッグ・アンド・ドロップすると、カテゴリに割り当てた属性のフィールド順序を変更できます。属性をカテゴリ・リストにドラッグ・アンド・ドロップすると、JDeveloperにより自動的にフィールド順序ヒントの適切な順序がカテゴリ内で維持され、個々の属性のフィールド順序値が「UIカテゴリ」ページの「属性UIヒント」リストに表示されます。「UIカテゴリ」ページに表示されるその他の属性レベルUIヒントは、ビュー・オブジェクト・エディタの「属性」ページの「UIヒント」タブの設定と同期されます。

各カテゴリにはラベルとツールチップ・テキストの文字列リソースを持たせることができ、カテゴリがレンダリングされる際にユーザー・インタフェースによって使用できます。エントリ格納用に選択したリソース・バンドル・ファイルにあるこれらのリソース文字列をローカライズできます。たとえば、図5-42では、属性LastNameとCreditRatingIdが、Sales Rep NameとCredit Ratingというラベルで、Personal Informationというラベルのカテゴリに示されています。

図5-42 Oracle ADFモデル・テスターで表示されるUIカテゴリ

始める前に:

UIヒントの知識があると役立ちます。詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

- オプションで、「属性固有のUIヒントの追加方法」の説明に従い、属性UIヒントを指定します。属性UIヒントは、ビュー・オブジェクト・エディタの「UIカテゴリ」ページで、読取り専用として表示されます。

ユーザー・インタフェースのカテゴリを作成し、表示用に属性の順序を変更するには:

1. 「アプリケーション」ウィンドウで、ユーザー・インタフェースのカテゴリをカスタマイズするビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「UIカテゴリ」ナビゲーション・タブをクリックします。

3. 「UIカテゴリ」ページで、「新規カテゴリの作成」ボタンをクリックしてカテゴリを作成してから、新しいカテゴリを右クリックして「名前の変更」を選択します。

4. 「名前の変更」ダイアログで、カテゴリ名を入力します。

5. 概要エディタの「UIヒント」セクションで、カテゴリでユーザー・インタフェースの「ラベル・テキスト」と「ツールチップ・テキスト」を入力します。

「UIヒント追加時の処理」で説明するように、入力するテキストは、プロジェクトのデフォルト・リソース・バンドル・ファイルに追加されます。別のリソース・バンドル・ファイルを選択して、ラベルおよびツールチップ文字列を保存するには、テキスト・フィールドの横の参照(「. . .」)ボタンをクリックします。

6. 「カテゴリ」リストで、「未分類」リストを展開し、属性のリストをスクロールして、カテゴリに追加する属性を検索します。

「未分類」リストには、編集中のビュー・オブジェクトが定義するすべての属性が表示されます。このリストは、UIカテゴリ・ヒントを作成するための選択リストとして概要エディタにより表示されます。「未分類」リストに残す属性は、デフォルトで、ユーザー・インタフェースに表示される属性カテゴリの上に表示されます。

7. 目的の属性を選択し、作成した新しいカテゴリにドラッグします。カテゴリに複数の属性がある場合、リストにドロップする属性の位置によりそのフィールド順序値が決まります。

「UIカテゴリ」リスト内に表示される属性の順序に基づいてフィールド順序ヒントに数値が開発者によって自動的に割り当てられます。カテゴリ・リストの上部に配置する属性が、ユーザー・インタフェースにより最初にレンダリングされ、次にリストで2番目の属性がレンダリングされ、以後同様になります。フィールド順序ヒントは、「UIカテゴリ」ページの「属性UIヒント」リストに表示され、編集できません。ヒント値はビュー・オブジェクト定義のソースにも表示され、ソースで編集できません。

5.13.6 属性をUIカテゴリに割り当てる際の処理

ビュー・オブジェクトの属性UIカテゴリを定義すると、JDeveloperによりビュー・オブジェクトのXMLドキュメント・ファイルが更新されます。JDeveloperは、CATEGORYとFIELDORDERのUIヒントを<ViewAttribute>要素の<SchemaBasedProperties>要素に追加します。カテゴリの定義は新しい<Category>要素に表示されます。

次の例のメタデータは、CustomerId属性のCATEGORYヒントがAccountInformationカテゴリを参照し、FirstName属性のCATEGORYヒントがUserInformationカテゴリを参照していることを示しています。両方のカテゴリの定義は<Category>要素に表示されます。属性ごとのFIELDORDERヒントにより数値を指定し、概要エディタで作成したUIカテゴリ・リストにおける属性の順序に基づいてJDeveloperによって割り当てられて維持されます。次の例に示すように、FIELDORDERヒントは10進数値です。10進数値がJDeveloperにより使用され、新しい属性をカテゴリに挿入でき、その際JDeveloperで既存の属性値をすべて変更する必要がなく、適切な順序を維持できます。

カテゴリで最初の属性におけるデフォルトのフィールド順値はJDeveloperにより0.0に割り当てられます。フィールド順の値は、カテゴリ・リストをソートするための数値に変更できますが、インデックスではありません。フィールド順の数値は連続している必要はありません。

<Category
Name="AccountInformation">
<Properties>
<SchemaBasedProperties>
<LABEL
ResId="CUSTOMER_DETAILS"/>
<TOOLTIP
ResId="AccountInformation_TOOLTIP"/>
</SchemaBasedProperties>
</Properties>
</Category>
<Category
Name="UserInformation">
<Properties>
<SchemaBasedProperties>
<TOOLTIP
ResId="UserInformation_TOOLTIP"/>
<LABEL
ResId="CUSTOMER_DETAILS"/>
</SchemaBasedProperties>
</Properties>
</Category>
...
<ViewAttribute
Name="CustomerId"
IsNotNull="true"
PrecisionRule="true"
EntityAttrName="CustomerId"
EntityUsage="CustomerEO"
AliasName="CUSTOMER_ID">
<Data>
<Property
Name="OWNER_SCOPE"
Value="INSTANCE"/>
...
</Data>
<Properties>
<SchemaBasedProperties>
<CATEGORY
Value="AccountInformation"/>
<FIELDORDER
Value="0.0"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>
...
<ViewAttribute
Name="FirstName"
PrecisionRule="true"
EntityAttrName="FirstName"
EntityUsage="CustomerEO"
AliasName="FIRST_NAME">
<Data>
<Property
Name="OWNER_SCOPE"
Value="INSTANCE"/>
...
</Data>
<Properties>
<SchemaBasedProperties>
<CATEGORY
Value="UserInformation"/>
<FIELDORDER
Value="0.0"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>

5.13.7 リソース・バンドルに関する必知事項

ADFビジネス・コンポーネントを使用して作成されたアプリケーションのモデル・レイヤーを国際化するには、各コンポーネントのリソース・バンドル・ファイルの翻訳バージョンを作成する必要があります。たとえば、QueryDataWithViewObjectsBundle.propertiesファイルのイタリア語バージョンはQueryDataWithViewObjectsBundle_it.propertiesという名前のファイルになり、より限定されたスイス・イタリア語バージョンはQueryDataWithViewObjectsBundle_it_ch.propertiesという名前のファイルになります。

リソース・バンドル・ファイルには、ローカライズが必要なメッセージ・キーのエントリと、そのローカライズ済の翻訳が含まれています。たとえば、イタリア語ロケールに対する数値フォーマット・マスクの翻訳が不要であったと仮定すると、QueryDataWithViewoObjectsビュー・オブジェクトのメッセージ・キーのイタリア語バージョンは、次の例のようになります。実行時には、現在のユーザーのロケール設定に基づいてリソース・バンドルが自動的に使用されます。

oracle.summit.model.views.CustomerVO.Id_FMT_FORMATTER=
oracle.jbo.format.DefaultNumberFormatter
oracle.summit.model.views.CustomerVO.Id_FMT_FORMAT=00000
oracle.summit.model.views.CustomerVO.Id_LABEL=Codice Utente
oracle.summit.model.views.CustomerVO.Email_LABEL=Indirizzo Email
oracle.summit.model.views.CustomerVO.LastName_LABEL=Cognome
oracle.summit.model.views.CustomerVO.FirstName_LABEL=Nome

モデル・プロジェクトの各リソース・バンドルは、Fusion Webアプリケーションの国際化の1つの特徴の要因になります。特定のロケールに対応した国際化では、ユーザー・インタフェースのADF Facesページのローカライズも必要になります。ADF Facesページのローカライズ方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ページの国際化およびローカライズ」を参照してください。

6 マスター/ディテール関連のビュー・オブジェクトの定義

この章では、ADFビュー・オブジェクトを他のビュー・オブジェクトにリンクし、Oracle ADFアプリケーションに任意の複雑さのマスター/ディテール階層を形成する方法を説明します。

この章の内容は次のとおりです。

- マスター/ディテール・ビュー・オブジェクトについて

- マスター/ディテール階層における複数表の使用

- 再帰的なマスター/ディテール階層における単一表の使用

- ビュー基準でのマスター/ディテール関連ビュー・オブジェクトの使用

6.1 マスター/ディテール・ビュー・オブジェクトについて

マスター/ディテール関係は、2つのビュー・オブジェクト・インスタンスを関連付けるビュー・リンクが作成されたときに確立されます。ビュー・リンクは2つのビュー・オブジェクト間の関係を表します。通常は基礎となるデータ表間の外部キー関係に基づきますが、そうである必要はありません。ビュー・リンクは、1つのビュー・オブジェクト・インスタンス(マスター・オブジェクト)の行を別のビュー・オブジェクト・インスタンス(ディテール・オブジェクト)の1つ以上の行に関連付けます。

6.1.1 マスター/ディテール・ビュー・オブジェクトのユースケースと例

この章では、図6-1に示すようなビュー・オブジェクトの概念についてわかりやすく説明します。

- ビュー・オブジェクトを1つ以上の他のビュー・オブジェクトにリンクして、任意の複雑さのマスター/ディテール階層を作成できます。

- 実行時にマスター・ビュー・インスタンスの現在行に合せてディテール・ビュー・インスタンスが能動的に調整されるように、アプリケーション・モジュールのコンテキスト内で親子のビュー・オブジェクト・インスタンスを調整できます。

- 設計時にビュー・リンク・アクセッサを定義できます。ビュー・リンク・アクセッサは、実行時にディテール・コレクション行セットを返すためにマスター・コレクションで使用されるアクセッサ属性を指定します。

- マスター/ディテール関係のマスター・ビュー・オブジェクトに指定するビュー・リンク・アクセッサ属性を使用して、プログラムでディテール・コレクション行セットにアクセスできます。

- ディテール・ビュー・インスタンスの行セットをキャッシュしてマスター/ディテール・コレクションの問合せを調整すると、ADF Facesツリー・コンポーネントのような、ツリー内の各マスター・ノードが個別にディテール行セットを保持する必要があるUIコンポーネントをサポートできます。

- ビュー基準を使用して行検索条件を作成し、マスター・ビュー・オブジェクト内の特定の行を見つけることができます。

- リンク元とリンク先のビュー・リンク属性が単一の表から導出されるように自己参照型のマスター/ディテール階層を定義できます。

- インライン・ビュー基準を定義して、ディテール・ビュー・オブジェクトの属性で指定された属性値を使用してマスター・ビュー・オブジェクトの行セットをフィルタリングできます。

図6-1 問合せを定義し、行の行セットを生成するビュー・オブジェクト

6.1.2 ビュー・オブジェクトの追加機能

ビュー・オブジェクトで作業を開始する前に、その他のOracle ADF機能を理解しておくと役に立つ場合があります。次に、関連する他の機能へのリンクを示します。

- 対話型のOracle ADFモデル・テスターを使用して、ビュー・オブジェクトの問合せ結果を検証する方法の詳細は、「ビュー・インスタンスの問合せのテスト」を参照してください。

- ビュー・オブジェクト・インスタンスで構成されるデータ・モデルを作成する方法の詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

- 通常、カスタム・ビュー・オブジェクト・クラスで記述、使用およびオーバーライドする一般的なコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

6.2 マスター/ディテール階層における複数表の使用

使用する問合せは、その多くが外部キーによって関連付けられた複数の表を対象としています。このシナリオでは、関連情報を問い合せる別個のビュー・オブジェクトを作成し、ソース・ビュー・オブジェクトを1つ以上のターゲット・ビュー・オブジェクトにリンクして、マスター/ディテール階層を形成します。

この状況に対処する方法は2つあります。次のいずれかを実行できます。

- ソース・ビュー・オブジェクトとターゲット・ビュー・オブジェクトが、基礎となるエンティティ・オブジェクトのアソシエーションに基づいている場合は、そのエンティティ・オブジェクト間のアソシエーションに基づいてビュー・リンクを作成します。

- ソース・ビュー・オブジェクトとターゲット・ビュー・オブジェクトの関連付けを定義するビュー・リンクを作成します。

アソシエーションの有無は、エンティティ・オブジェクトがいつ作成されたかによって決まります。デフォルトでは、エンティティ・オブジェクト・アソシエーションは、データ・ソースの階層関係をモデル化しています。たとえば、外部キーで関連付けられたデータベース表に基づくエンティティ・オブジェクトは、このような関係をエンティティ・アソシエーションで取り込みます。ビュー・リンクが既存のエンティティ・アソシエーションに基づいている場合、ビュー・リンクをビュー・オブジェクトにのみ基づいて定義しても、パフォーマンス的に不利になることはありません。どちらの場合も、「ビュー・リンクの作成」ウィザードでマスター/ディテールの関係を定義します。

注意:

1つのビュー・リンクにより、2つのビュー・オブジェクト間の基本的なマスター/ディテール関係が定義されます。ただし、より多くのビュー・リンクを作成することにより、次のものを含む複雑なマスター/ディテール階層を構成できます。

- マルチレベルのマスター/ディテール/ディテール

- 複数の(ピア)ディテールがあるマスター

- 複数のマスターがあるディテール

このような複雑な階層を定義する手順は、ビュー・オブジェクトのみに基づいて関係を作成する場合も、エンティティ・アソシエーションを持つビュー・オブジェクトに基づいて関係を作成する場合も同じです。どちらの場合も、追加の各階層を、一度に1ビュー・リンクずつ作成する必要があります。

図6-2は、リンクされたマスター/ディテール問合せにより生成されたマルチレベルの結果を示しています。

図6-2 リンクされたマスター/ディテール問合せ

6.2.1 エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法

ユーザーにマスター行のセットを表示し、マスター行ごとに調整されたディテール行のセットを表示する必要がある場合、ビュー・リンクを作成して、マスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトをどのように関連付けるかを定義できます。たとえば、部門のマスター/ディテール階層および各部門に定義された従業員セットを作成する場合は、DeptVOビュー・オブジェクトとEmpVOビュー・オブジェクトをリンクさせます。このようなビュー・オブジェクトが既存のアソシエーションによって関連付けられたエンティティを基礎としている場合は、そのアソシエーションを選択してマスター/ディテール・ビュー・リンクを定義できます。

アソシエーション・ベースのビュー・リンクを作成するには、「ビュー・リンクの作成」ウィザードを使用します。

始める前に:

マスター/ディテール階層を作成する方法に関する知識があると役立ちます。詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。

エンティティ・アソシエーションの作成方法を理解しておくと役に立つ場合があります。詳細は、「既存の表からのエンティティ・オブジェクトおよびアソシエーション作成時の処理」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」の説明に従って、必要なエンティティ・ベースのビュー・オブジェクトを作成します。

アソシエーション・ベースのビュー・リンクの作成方法:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するプロジェクトのパッケージ・ノードを右クリックし、「新規」、「ビュー・リンク」の順に選択します。

2. 「ビュー・リンクの作成」ウィザードの「名前」ページで、パッケージ名とコンポーネント名を指定します。

たとえば、ビュー・リンクの目的を考えた場合、DeptToEmpFkLinkなどは、リンクが外部キーに基づいており、部門リストとその従業員の間のリンクであることを示しているので、名前として有効です。

3. 「ビュー・オブジェクト」ページの「ソース属性の選択」ツリーで、目的のパッケージのソース・ビュー・オブジェクトを開きます。「関連先属性の選択」ツリーで、リンク先ビュー・オブジェクトを開きます。

ビュー・オブジェクト属性の他にも、エンティティ・ベースのビュー・オブジェクトの場合、リストには関連するアソシエーションも表示されます。

4. ソースのツリーおよび宛先のツリーで同じアソシエーションを選択します。その後、「追加」をクリックして、次の表にアソシエーションを追加します。

たとえば、図6-3では、ソースのツリーおよび宛先のツリーの両方で同じSEmpDeptIdFkAssocアソシエーションが選択されています。

図6-3 アソシエーションの選択によるマスターとディテールの関連付け

5. 「終了」をクリックします。

6.2.2 ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法

アソシエーションに基づくビュー・リンクの場合と同様に、ビュー・オブジェクトを他のビュー・オブジェクトに直接リンクし、任意の複雑さでマスター/ディテール階層を形成できます。唯一異なるのは、マスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトのどちらも既存のアソシエーションによって関連付けられていない場合の作成手順です。この場合、これらのオブジェクトを関連付ける一連のソース属性と関連先属性のペアを取得するためのアソシエーションがないため、ベースとなるビュー・オブジェクト属性を示してビュー・リンクを作成します。

ビュー・リンクを作成するには、「ビュー・リンクの作成」ウィザードを使用します。

始める前に:

マスター/ディテール階層を作成する方法に関する知識があると役立ちます。詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、必要な読取り専用ビュー・オブジェクトを作成します。

ビュー・オブジェクト間のビュー・リンクを作成するには:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するプロジェクトのパッケージ・ノードを右クリックし、「新規」、「ビュー・リンク」の順に選択します。

2. 「ビュー・リンクの作成」ウィザードの「名前」ページで、パッケージ名とビュー・リンク名を入力します。「次へ」をクリックします。

たとえば、ビュー・リンクの目的を考えた場合、OrdersPlacedByなどは、顧客リストとその注文の間のリンクであることを示しているので、名前として有効です。

3. 「ビュー・オブジェクト」ページで、マスターとして動作するビュー・オブジェクトからソース属性を選択します。

たとえば図6-4は、この役割を実行するCustomerVOビュー・オブジェクトから選択したId属性を示しています。「次へ」をクリックします。

4. 「ビュー・オブジェクト」ページで、ディテールとして動作するビュー・オブジェクトから、対応するリンク先属性を選択します。

たとえば、ディテール問合せにより、現在選択している顧客からの注文が表示されるようにする場合は、この役割を実行するOrdersVOからId属性を選択します。

5. 「追加」をクリックし、対応する属性ペアを、下にあるソース属性とリンク先属性のペアの表に追加します。マスター/ディテール・リンクの定義が終了したら、「次へ」をクリックします。

図6-4では、ペアが1つのみ(CustomerVO.Id、OrderVO.Id)選択されています。ただし、マスターとディテールの間のリンクを定義するために必要な属性ペアが複数ある場合、「ビュー・オブジェクト」ページでこれらのステップを繰り返して、ソース/ターゲット属性ペアをさらに追加できます。

図6-4 ビュー・リンク作成中のソース/ターゲット属性ペアの定義

6. 「ビュー・リンク・プロパティ」ページでは、「アクセッサ名」フィールドを使用して、リンク先ビュー・オブジェクトへのプログラムによるアクセスを可能にするアクセッサのデフォルト名を変更できます。

デフォルトでは、アクセッサ名は、リンク先ビュー・オブジェクトの名前と一致します。たとえば、デフォルトのアクセッサ名をOrdersVO1からCustomerOrdersに変更すると、アクセッサで定義されるマスター/ディテール関係が明確になります。

7. また、「ビュー・リンク・プロパティ」ページで、ビュー・リンクが一方向と双方向のどちらを表すのかを制御できます。

デフォルトでは、ビュー・リンクは、ソース(マスター)の現在行をリンク先(ディテール)ビュー・オブジェクトの関連する行のセットにアクセスできるようにする一方向関係です。階層的なUIコンポーネント(たとえばマスター・ビュー・オブジェクトで生成されたアクセッサを持つビュー・リンク・アクセッサを必要とするデータバインドされたツリーなど)のサポートを有効にする場合は、「アクセッサの生成」のデフォルト設定はそのまま変更しないでください。

たとえば、図6-5におけるチェック・ボックスの設定では、CustomerVOの現在行のOrdersVOから行のディテール・コレクションにはアクセスできますが、逆方向のアクセスはできません。この場合の動作は、OrdersVOの「宛先アクセッサ」グループ・ボックスのチェック・ボックス(「アクセッサの生成」の「ビュー・オブジェクト: CustomerVO」ボックスを選択)と、CustomerVOの「リンク元アクセッサ」グループ・ボックスのチェック・ボックス(「アクセッサの生成」の「ビュー・オブジェクト: OrdersVO」ボックスの選択を解除)の設定によって指定します。

図6-5 ビュー・リンク・プロパティ・コントロール名およびアクセッサの方向

8. 「ソース問合せの編集」ページで、実行時にソース・ビュー・オブジェクトのマスター行へのアクセスに使用されるビュー・リンクのSQL述語をプレビューし、「次へ」をクリックします。

9. 「関連先問合せの編集」ページで、実行時にソース・ビュー・オブジェクトの現在行に対するリンク先ビュー・オブジェクトから相関ディテール行へのアクセスに使用されるビュー・リンクのSQL述語をプレビューし、「次へ」をクリックします。

10. 「アプリケーション・モジュール」ページで、目的のアプリケーション・モジュールのデータ・モデルにビュー・リンクを追加し、「終了」をクリックします。

デフォルトでは、ビュー・リンクはアプリケーション・モジュールのデータ・モデルに追加されません。ビュー・リンクは、後でアプリケーション・モジュールの概要エディタを使用してデータ・モデルに追加できます。

6.2.3 ビュー・リンクを使用したマスター/ディテール階層の作成時の処理

ビュー・リンク、またはアソシエーションベースのビュー・リンクを作成する場合、JDeveloperでその宣言的設定を表すXMLドキュメントが作成され、そのパッケージの名前に対応するディレクトリ内に保存されます。たとえば、DeptToEmpFkLinkという名前のビュー・リンクが作成され、views.linksパッケージに表示された場合、プロジェクトのソース・パスに作成されるXMLファイルは、./views/links/DeptToEmpFkLink.xmlになります。このXMLファイルには、指定したソース属性とリンク先属性のペアに関する宣言情報が含まれ、ビュー・リンクがアソシエーションベースの場合は、指定したソース・ビュー・オブジェクトとリンク先ビュー・オブジェクトを関連付けるアソシエーションに関する宣言情報が含まれます。

ビュー・リンク・コンポーネント定義自体を保存するのみでなく、JDeveloperはビュー・リンク関係でのリンク元ビュー・オブジェクトのXML定義を更新して、定義したビュー・リンク・アクセッサに関する情報を追加します。これを確認するため、「アプリケーション」ウィンドウでソース・ビュー・オブジェクトを選択し、「構造」ウィンドウでその詳細を検証できます。図6-6に示すように、DeptVOソース・ビュー・オブジェクトのViewLink Accessorsノードの下には、リンク先のEmpVOビュー・オブジェクトにアクセスするデフォルトのリンク先アクセッサEmpVOAccessorがあります。これにより、ソース・ビュー・オブジェクトはビュー・リンク・アクセッサを使用して、ビュー・リンクのリンク先側を横断できます。ソース・ビュー・オブジェクトのビュー・リンク・アクセッサ定義に加えて、ビュー・リンクを直接カスタマイズすることにより、リンク先ビュー・オブジェクトにビュー・リンク・アクセッサを定義できます。

図6-6 「構造」ウィンドウにビュー・リンク・アクセッサが表示されるビュー・オブジェクト

6.2.4 データ・モデルでアクティブなマスター/ディテール調整を有効化する方法

「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」で説明したように、ビュー・リンクを定義して、相関ディテールの行セットにプログラムで移動できるようにする場合、ビュー・リンクは、コードから要求された際、調整されたディテール行セットの取得に必要な情報を定義するのみという受動的な役割を担います。ビュー・リンク・アクセッサ属性が存在し、ビュー・リンクのソース・ビュー・オブジェクトの任意のインスタンスから任意の結果行でプログラムによるアクセスが可能です。つまり、プログラムによるアクセスでは、アプリケーション・モジュールのデータ・モデルを変更する必要はありません。

ただし、マスター/ディテール・ユーザー・インタフェースは、エンタープライズ・アプリケーション内で頻繁に発生するため、マスター/ディテール画面をプログラムで調整する必要性をなくすために、ビュー・リンクをより能動的に使用することもできます。ビュー・リンクされたビュー・オブジェクトのインスタンスをアプリケーション・モジュールのデータ・モデルに 明示的に追加することにより、この能動的なマスター/ディテール調整を実行できます。

マスター/ディテールの調整を有効にするには、概要エディタでアプリケーション・モジュールを開き、「データ・モデル」ページを選択します。

始める前に:

マスター/ディテール階層を作成する方法に関する知識があると役立ちます。詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。

アプリケーション・モジュールの役割を理解しておくと役に立つ場合があります。詳細は、「アプリケーション・モジュールについて」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

- 「アプリケーション・モジュールの作成方法」の説明に従って、アプリケーション・モジュールを作成します。

ビュー・オブジェクトのディテール・インスタンスを追加する方法:

1. 「アプリケーション」ウィンドウで、新しいビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。

3. 「データ・モデル」ページで、「ビュー・オブジェクト・インスタンス」セクションを展開し、 「使用可能なビュー・オブジェクト」リストで、マスター・ビュー・オブジェクトの下でインデントされたディティール・ビュー・オブジェクト・ノードを選択します。

このリストには、ディティール・ビュー・オブジェクトが、それ自体として1回、およびビュー・リンクを介するディティール・ビュー・オブジェクトとして1回の計2回表示されることに注意してください。たとえば、図6-7では、EmpVOのラベルのビュー・オブジェクト(この場合は、強調表示されているビュー・オブジェクトの下に表示)ではなく、EmpVO via DeptToEmpFkLinkディテール・ビュー・オブジェクトを選択しています。

図6-7 「選択可能なビュー・オブジェクト」から選択されたディテール・ビュー・オブジェクト

4. 「使用可能なビュー・オブジェクト」リストの下のビュー・インスタンスの名前の指定フィールドに、作成しようとしているディテール・インスタンスの名前を入力します。

たとえば、図6-7では、ディテール・ビューであるEmpVOビュー・オブジェクトのインスタンスの名前はEmpDetailsVOです。

5. 「データ・モデル」リストで、アクティブに調整するマスターにする必要があるビュー・オブジェクトのインスタンスを選択します。

6. 「インスタンスの追加」をクリックして、データ・モデル内で現在選択されているマスター・インスタンスに、自分が選択した名前でディテール・インスタンスを追加します。

たとえば、図6-8では、「データ・モデル」リストに、ビュー・オブジェクト・インスタンスのマスター/ディテール階層(ディテール・ビュー・オブジェクトはEmpDetailsVO)が表示されています。

図6-8 ビュー・リンクされたビュー・オブジェクトによるデータ・モデル

6.2.5 マスター/ディテールの調整のテスト方法

マスター/ディテールのアクティブな調整をテストするには、「アプリケーション」ウィンドウのポップアップ・メニューから「実行」を選択して、アプリケーション・モジュール上でOracle ADFモデル・テスターを起動します。Oracle ADFモデル・テスターのデータ・モデル・ツリーには、マスター・ビュー・オブジェクト・インスタンスでディテール・ビュー・オブジェクト・インスタンスをアクティブに調整するビュー・リンク・インスタンスが表示されます。ツリーでビュー・リンク・インスタンス・ノードをダブルクリックすると、Oracle ADFモデル・テスターのマスター/ディテール・データ・ビュー・ページが開きます。ツールバー・ボタンを使用してマスター・ビュー・オブジェクト内で移動する(結果としてビュー・オブジェクトの現在行を変更する)場合に、調整されたディテールのセットが自動的にリフレッシュされ、ユーザー・インタフェースは同期を維持します。

マスターまたはディテールとして定義されていない別のビュー・オブジェクトをダブルクリックすると、2番目のタブが開き、そのデータが表示されます。この場合、そのビュー・オブジェクトに対してはビュー・リンクによるアクティブな調整が行われないため、その問合せはマスター・ビュー・オブジェクトの現在行による制約を受けません。

データ・モデルを編集してOracle ADFモデル・テスターを実行する方法の詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

6.2.6 ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法

ビュー・リンクを効果的に使用するためには、ビュー・リンク・アクセッサ属性によりRowSetオブジェクトが戻されることや、ディテール・コレクションへのビュー・リンク・アクセッサでのプログラムによるアクセスが可能になることを理解しておく必要があります。

6.2.6.1 名前による行の属性へのアクセス

実行時に、RowオブジェクトにあるgetAttribute()メソッドにより、ビュー・オブジェクトの名前別の結果セットで行の属性にアクセスできます。ビュー・リンク・アクセッサは、ソース・ビュー・オブジェクトの現在行の追加属性のような動作をするため、同じgetAttribute()メソッドを使用してその値を取得できます。通常のビュー属性とビュー・リンク・アクセッサ属性との実際の相違点は、そのデータ型のみです。通常のビュー属性は、一般に303やngreenbeのような値を持つスカラー・データ型であるのに対し、ビュー・リンク・アクセッサ属性の値はゼロまたは1つ以上の相関ディテール行の行セットです。curUserがOrdersビュー・オブジェクトのいくつかのインスタンスからのRowオブジェクトであると仮定すると、注文項目のディテール行セットを取得するための、次のコードを1行作成することができます。

RowSet items = (RowSet)curUser.getAttribute("OrderItems");

注意:

ビュー行のカスタムJavaクラスを生成する場合、ビュー・リンク・アクセッサのタイプはRowIteratorになります。実行時に、戻り値が必ずRowSetオブジェクトになるため、ビュー・リンク属性値をRowSetにキャストするのが安全です。

6.2.6.2 ビュー・リンク・アクセッサを使用したディテール・コレクションへのプログラムによるアクセス

次の例に示すように、ビュー・リンク・アクセッサを使用してディテール行のRowSetオブジェクトを取得すると、ビュー・オブジェクトの結果の行セットをループする場合と同じように、それが含まれる行全体をループできます。

while (items.hasNext()) {
Row curItem = items.next();
System.out.println("--> (" + curItem.getAttribute("LineItemId") + ") " +
curItem.getAttribute("LineItemTotal"));
}

テスト・クライアントの作成の詳細は、「ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法」を参照してください。

6.2.6.3 マスター/ディテール・データを表示するためのビュー・リンク・アクセッサのアクセスの最適化

新しいディテール行セット作成の問合せの再実行に関連する若干のオーバーヘッドがアプリケーションで発生しないようにする場合は、ビュー・リンク・アクセッサ行セットのキャッシュを有効にできます。たとえば、マスター行ビュー・アクセッサ属性が変更されないかぎり、ビュー・アクセッサ行セットは安定した状態を維持し、ADF Facesツリー・コンポーネントのようなUIコンポーネントの行セットを再作成する必要がありませんが、ツリー内の各マスター・ノードのデータは、個別のディテール行のセットを維持する必要があります。

ビュー・リンク・アクセッサのソースであるビュー・オブジェクトについて、概要エディタを使用してビュー・リンク・アクセッサ行セットの保存を有効にできます。ソース・ビュー・オブジェクトの概要エディタの「ビュー・アクセッサ」ページで、「行セットの保存」フラグを選択します。

パフォーマンスに関するヒント

ユーザー・インタフェース開発者がビュー・リンクを使用して、ディテール・コレクションが安定しているデータバインド型マスター・ディテール・コンポーネント(ADF Facesツリー・コンポーネントなど)を作成することが予想される場合は、「行セットの保存」フラグを有効にしてください。実行時に、この設定によってディテール・コレクションごとにアクセッサが1回実行されます。パフォーマンスにおけるこの改善の代償としては、フラグを有効にせずにディテール・コレクションにアクセスすることに比べて、アクセスされるコレクションではより多くのメモリー領域を占有する場合があります。

ビュー・リンク・アクセッサ行セットの保存を有効にするには:

1. 「アプリケーション」ウィンドウで、ビュー・リンクを定義するソース・ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビュー・アクセッサ」ナビゲーション・タブをクリックします。

3. 「ビュー・アクセッサ」ページで「ビュー・リンク・アクセッサ」セクションを開き、「行セットの保存」チェック・ボックスを選択します。

6.2.7 ビュー・リンク・アクセッサとデータ・モデル・ビュー・リンク・インスタンスの相違に関する必知事項

ビュー・オブジェクトは、次の2種類のスタイルのマスター/ディテール調整をサポートします。

- データ・モデルのマスター/ディテール調整のためのビュー・リンク・インスタンス。「アクティブなマスター/ディテール調整による動的ディテール行セットの有効化」を参照してください。

- ディテール行セットにオン・デマンドでプログラム的にアクセスするためのビュー・リンク・アクセッサ属性。「ビュー・リンク・アクセッサ属性を使用したディテール行セットへのプログラムによるアクセス」を参照してください。

- 「実行時に行われる処理: ビュー・リンク・アクセッサを使用したプログラムによるアクセスを組み合せるタイミング」の説明に従って、両方のスタイルを結合できます。

6.2.7.1 アクティブなマスター/ディテール調整による動的ディテール行セットの有効化

ビュー・リンク・インスタンスをアプリケーション・モジュールのデータ・モデルに追加するときは、2つの特定のビュー・オブジェクト・インスタンスを接続します。ビュー・リンク・インスタンスの使用は、2つの間にアクティブなマスター/ディテール調整が必要なことを示します。実行時には、データ・モデル内のビュー・リンク・インスタンスにより、このコーディネーションを有効にするイベント処理が容易になります。マスター・ビュー・オブジェクト・インスタンスで現在行が変更されるたびに、イベントが発生し、マスター・ビュー・オブジェクトの新しい現在行に対する新しいバインド・パラメータのセットでexecuteQuery()が自動的に呼び出されることで、ディテール・ビュー・オブジェクトがリフレッシュされます。

このデータ・モデル・マスター/ディテールの重要な特徴は、マスターおよびディテール・ビュー・オブジェクト・インスタンスが、クライアントのユーザー・インタフェースがバインディングを確立できる固定のオブジェクトであることです。マスターで現在行が変化すると、新しいディテール・ビュー・オブジェクト・インスタンスが生成されるのではなく、既存のディテール・ビュー・オブジェクト・インスタンスが、マスターの新しい現在行に関連する行のセットを含むように、デフォルトの行セットを更新します。さらに、ユーザー・インタフェースのバインディング・オブジェクトはイベントを受け取り、ディテール・ビュー・オブジェクトのリフレッシュされた行セットを含むように表示を更新できます。

データ・モデル階層のみが備えるもう1つの重要な機能は、1つのディテール・ビュー・オブジェクト・インスタンスが複数のマスター・ビュー・オブジェクト・インスタンスを持つことができることです。たとえば、PaymentOptionsビュー・オブジェクト・インスタンスは、Customersビュー・オブジェクト・インスタンスとOrdersビュー・オブジェクト・インスタンスの両方のディテールになることができます。CustomersまたはOrdersのビュー・オブジェクト・インスタンスの現在行が変わるたびに、ディテールPaymentOptionsビュー・オブジェクト・インスタンスのデフォルトの行セットは、現在の顧客および現在のオーダーの支払情報の行を含むようにリフレッシュされます。複数のマスターがあるディテール・ビュー・オブジェクト・インスタンスを設定する方法の詳細は、「複数のマスターがあるマスター/ディテール階層を作成する方法」を参照してください。

6.2.7.2 ビュー・リンク・アクセッサ属性を使用したディテール行セットへのプログラムによるアクセス

ビュー・リンクによりビュー・オブジェクト行に関係するディテール行セットにプログラムでアクセスする必要がある場合は、ビュー・リンク・アクセッサ属性を使用できます。ビュー・リンク・アクセッサ属性のファインダ名は、ビュー・リンクの概要エディタから指定します。「関連」ページの「アクセッサ」セクションにある「編集」アイコンをクリックし、「ビュー・リンク・プロパティの編集」ダイアログでビュー・リンク・アクセッサ属性の名前を編集します。

次の例は、<Attr>要素の_findername値を定義するビュー・リンクのXMLを示しています。

<ViewLinkDefEnd
Name="Orders"
Cardinality="1"
Owner="devguide.advanced.multiplemasters.Orders"
Source="true">
<AttrArray Name="Attributes">
<Item Value="devguide.advanced.multiplemasters.Orders.PaymentOptionId"/>
</AttrArray>
<DesignTime>
<Attr Name="_minCardinality" Value="1"/>
<Attr Name="_isUpdateable" Value="true"/>
<Attr Name="_finderName" Value="Orders"/>
</DesignTime>
</ViewLinkDefEnd>

アクセッサ属性の名前がAccessorAttrNameであるとすると、次のような汎用getAttribute() APIを使用してディテール行セットにアクセスできます。

RowSet detail = (RowSet)currentRow.getAttribute("AccessorAttrName");

マスター・ビュー・オブジェクトに対するカスタム・ビュー行クラスを生成し、クライアント・ビュー行インタフェースでビュー・リンク・アクセッサ属性に対するgetterメソッドを公開してある場合は、次のような強く型付けされたコードを使用してディテール行セットにアクセスできます。

RowSet detail = (RowSet)currentRow.getAccessorAttrName();

データ・モデル・マスター/ディテールとは異なり、ビュー・リンク・アクセッサ属性のプログラムによるアクセスでは、アプリケーション・モジュールのデータ・モデルにディテール・ビュー・オブジェクト・インスタンスは必要ありません。ビュー・リンク・アクセッサ属性を呼び出すたびに、呼出しを行ったマスター行に関連するディテール行のセットを含むRowSetが返されます。

ビュー・リンク・アクセッサ属性を使用すると、ディテール・データ行は不変になります。マスター行のビュー・リンク定義に関係する属性値が変わらないかぎり、ディテール・データ行は変化しません。マスターの現在行が変化しても、特定のマスター行にアタッチされているディテール行セットは影響を受けません。このため、ビュー・リンク・アクセッサ属性は、ディテール行の汎用的なプログラム・アクセスに便利なだけでなく、ツリー・コントロールのようなUIオブジェクトにも適しています。ツリー・コントロールでは、ツリー内の各マスター・ノードのデータは、個別のディテール行のセットを維持する必要があります。

6.2.7.3 実行時に行われる処理: ビュー・リンク・アクセッサを使用したプログラムによるアクセスを組み合せるタイミング

Oracle ADFは、データ・モデル・マスター/ディテールとビュー・リンク・アクセッサの行セットを区別する必要があります。データ・モデル・マスター/ディテールと、ビュー・リンク・アクセッサを使用するディテール行セットのプログラムによるアクセスを組み合せるときは、これらが個別のメカニズムであることを理解することが重要です。たとえば、次のことを行うものとします。

- PersonsVOおよびOrdersVOビュー・オブジェクトを定義します。

- これらの間のビュー・リンクを定義し、ビュー・リンク・アクセッサにPersonsToOrdersという名前を付けます。

- これらのインスタンスを、ビュー・リンク・インスタンスによってアクティブに調整されるmaster (PersonsVO型)およびdetail (OrdersVO型)という名前の、アプリケーション・モジュールのデータ・モデルに追加します。

masterビュー・オブジェクトのインスタンスで人物を検索すると、detailビュー・オブジェクトのインスタンスが更新され、予測どおりに対応する順序が表示されます。この時点で、現在のPersonsVO行のPersonsToOrdersビュー・リンク・アクセッサ属性にプログラムでアクセスするカスタム・メソッドを呼び出すと、OrdersVO行のセットを含むRowSetが取得されます。一般には、プログラムでアクセスされたこのRowSetはデータ・モデルのdetailビュー・オブジェクト・インスタンスに由来するものと考えられますが、そうではありません。

ビュー・リンク・アクセッサによって返されるRowSetは、常に内部的に作成されたビュー・オブジェクト・インスタンスからのものであり、ユーザーがデータ・モデルに追加したものではありません。この内部的なビュー・オブジェクト・インスタンスは、必要に応じて作成され、システムが定義する名前でルート・アプリケーション・モジュールに追加されます。

内部的に作成される個別のビュー・オブジェクト・インスタンスが使用される最大の理由は、データ・モデル内のビュー・オブジェクト・インスタンスに対して開発者が行う変更によって、インスタンスが影響を受けないようにするためです。たとえば、ビュー行が、ビュー・リンク・アクセッサのRowSetに対してデータ・モデル内のディテール・ビュー・オブジェクトを使用する場合、開発者が次のようなことを動的に行うと、結果の行セットが誤って影響を受ける可能性があります。

1. 新しい名前付きバインド・パラメータを含むWHERE句を追加する。
このようなビュー・オブジェクト・インスタンスがビュー・リンク・アクセッサの結果に使用されると、動的に追加されたWHERE句のバインド・パラメータ値はビュー・リンク・アクセッサのRowSetに提供されていないため、予想外の結果またはエラーが発生します。このような値が提供されるのは、データ・モデル内のディテール・ビュー・オブジェクト・インスタンスのデフォルト行セットのみです。

2. データ・モデルのディテール・ビュー・オブジェクト・インスタンスにマスター・ビュー・オブジェクト・インスタンスを追加する。
このシナリオでは、アクセッサのセマンティクスが変更されます。アクセッサが現在のPersonsVO行に対するOrdersVO行を返すかわりに、たとえば現在ログインしている顧客によって作成された現在のPersonsVOに対するOrdersVO行のみを突然返し始めます。

3. ディテール・ビュー・オブジェクト・インスタンスまたはそれを含むアプリケーション・モジュール・インスタンスを削除する。
このシナリオでは、プログラムでアクセスされたディテールRowSetのすべての行が無効になります。

さらに、Oracle ADFは、特定の操作について、データ・モデル・マスター/ディテールとビュー・リンク・アクセッサの行セットを区別する必要があります。たとえば、ディテール・ビュー・オブジェクトで新しい行を作成すると、フレームワークは、ビュー・リンクに含まれる属性に、マスターの対応する値を自動的に移入します。データ・モデル・マスター/ディテールの場合は、このような値を、データ・モデルの場合によっては複数のマスター・ビュー・オブジェクト・インスタンスの現在行から取得します。ビュー・リンク・アクセッサによって返されるRowSetに新しい行を作成する場合は、アクセッサが呼び出されたマスター行からの値を移入します。

6.2.8 複数のマスターがあるマスター/ディテール階層を作成する方法

役に立つ場合には、同じディテール・ビュー・オブジェクトのインスタンスに対して複数のマスター・ビュー・オブジェクトのインスタンスが存在するように、データ・モデルを設定できます。Customers、Orders、およびPaymentOptionsという名前のビュー・オブジェクトと、次のように定義されたビュー・リンクについて考えます。

- CustomersとPaymentOptions

- OrdersとPaymentOptions

図6-9は、CustomersとOrdersの両方のビュー・オブジェクト・インスタンスが、同じPaymentOptionsビュー・オブジェクト・インスタンスのマスターになるように構成した場合の、データ・モデル・パネルの表示を示しています。

図6-9 同じディテールに対する複数のマスター・ビュー・オブジェクト・インスタンス

図6-9のようなデータ・モデルを設定するには、アプリケーション・モジュールの概要エディタで、「データ・モデル」ページを使用します。

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトについて」を参照してください。

複数のマスター・ビュー・オブジェクトを持つビュー・インスタンスを作成するには:

1. 最初のマスター・ビュー・オブジェクトのインスタンスをデータ・モデルに追加します。

名前はCustomersとします。

2. 2番目のマスター・ビュー・オブジェクトのインスタンスをデータ・モデルに追加します。

名前はOrdersとします。

3. 「データ・モデル」リストから、最初のマスター・ビュー・オブジェクトのインスタンスを選択します。

4. 「使用可能なビュー・オブジェクト」リストで、最初のマスター・ビュー・オブジェクトの下にインデントされているディテール・ビュー・オブジェクトを選択し、「新規インスタンス名」フィールドにビュー・オブジェクト・インスタンスの名前を入力します。次に、>をクリックして、既存のCustomersビュー・オブジェクト・インスタンスのディテールとしてデータ・モデルに移動します。

5. 「データ・モデル」リストから、2番目のマスター・ビュー・オブジェクトのインスタンスを選択します。

6. 「使用可能なビュー・オブジェクト」リストで、2番目のマスター・ビュー・オブジェクトの下にインデントされているディテール・ビュー・オブジェクトを選択し、「新規インスタンス名」フィールドに、直前に入力したディテール・ビュー・オブジェクトの場合と同じビュー・オブジェクト・インスタンス名を入力します。次に、>をクリックして、既存のOrdersビュー・オブジェクト・インスタンスのディテールとしてデータ・モデルに移動します。

次の警告が表示されます: PaymentOptionsVOという名前のビュー・オブジェクトのインスタンスはデータ・モデルですでに使用されています。同じインスタンスを使用しますか。

7. 「はい」をクリックして、このディテール・ビュー・オブジェクト・インスタンスを、2番目のビュー・オブジェクト・インスタンスのディテールにもすることを確認します。

6.2.9 エンティティ・オブジェクト用に一時のみ属性によるマスター/ディテール階層を作成する方法

エンティティ・ベースのビュー・オブジェクトをリンクしてマスター/ディテール階層を形成すると通常、ビュー・オブジェクトとこれらの各慣用名がアソシエーションによって関連付けられます。実行時に、アソシエーションにより内部アソシエーション・ビュー・オブジェクトが作成され、これによって問合せの実行が有効になり、マスター/ディテール調整が有効にされます。アソシエーションに参加するエンティティ・オブジェクトが非永続属性のみで構成される場合は、このシナリオに例外が発生します。実行時にプログラムで移入する一時属性でエンティティ・オブジェクトを定義すると、これが発生する場合があります。この場合、非永続エンティティ・オブジェクトにリンクするアソシエーション概要エディタを使用して、アソシエーション・ビュー・オブジェクトを選択し、問合せを実行できます。

始める前に:

アソシエーションの知識があると役立ちます。詳細は、「既存の表からのエンティティ・オブジェクトおよびアソシエーション作成時の処理」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」の説明に従って、非永続エンティティ・オブジェクト用にエンティティ・ベースのビュー・オブジェクトを作成します。

- 「アソシエーションの作成」ウィザードを使用して、非永続エンティティ・オブジェクトとデータベース派生エンティティ・オブジェクトとの間におけるアソシエーションを作成します。アソシエーションの作成の詳細は、「アソシエーションの作成と構成」を参照してください。

非永続エンティティ・オブジェクトのアソシエーションをカスタマイズするには:

1. 「アプリケーション」ウィンドウで、カスタマイズするアソシエーションをダブルクリックします。

2. 概要エディタで「チューニング」ナビゲーション・タブをクリックし、「カスタム・ビュー・オブジェクト」セクションの「アクセッサの編集」アイコンをクリックします。

3. 「カスタム・ビュー」ダイアログで、非永続エンティティ・オブジェクトの「カスタム・ビュー・オブジェクトの使用」を選択します。

4. 「ビュー・オブジェクトの選択」リストで、非永続エンティティ・オブジェクトに基づいて作成したビュー・オブジェクトを選択します。

5. 「OK」をクリックします。

6.2.10 行検索を使用したマスター・ビュー・オブジェクトの行の検索方法

行検索は、ビュー基準を使用して行セットの中の特定の行を見つけるためにアプリケーションで使用されるオブジェクトです。マスター行セットに対して行検索を起動して、ディテール行セットにより提供された1つ以上の一致する基準属性を特定できます。

現在は、実行時に行キー以外の属性の参照が必要な場合に、次のマスター/ディテール・シナリオで、設計時に定義した行検索を参加させることができます。

- ADFビジネス・コンポーネントWebサービスで行検索を公開する場合。エンド・ユーザーは、マスター・サービス・ビュー・インスタンスの特定の行(行検索にマップされた、ディテール・サービス・ビュー・インスタンスの1つ以上の属性値に一致する)に対して行更新を開始できます。このユースケースの詳細は、「ビュー基準と行検索の使用方法に関する必知事項」を参照してください。

- 行検索にマップされた、ディテール・ビュー・インスタンスの1つ以上の非キー属性値に一致するマスター・ビューの行セットを、アプリケーションでプログラムにより取得する場合。このユースケースの詳細は、「プログラムによる行検索の呼出し」を参照してください。

注意:

ビュー・オブジェクトで定義する行検索は、現在のところADFビジネス・コンポーネント・データ・コントロールのビュー・プロジェクト用にはサポートされていません。したがって、アプリケーションによって「データ・コントロール」パネルでコレクションとして公開されるビュー・オブジェクトの行検索マップ属性は、行検索の参照操作に関与しません。

ビュー基準により定義されるビュー基準属性は、必ずしも行のキー属性である必要はなく、ディテール・ビュー・オブジェクトで定義された任意の属性でかまいません。たとえば、PersonVOがマスター・ビュー・オブジェクト、AddressVOがディテール・ビュー・オブジェクトであるマスター/ディテール関係で、属性EmailAddressにより、AddressVOの行セット内で個人の電子メール・アドレスが一致する個人行が特定されるとします。

ディテール・ビュー・オブジェクトから提供される基準属性を使用してマスター・ビュー・オブジェクトの行を特定する行検索を作成するには、次の手順を実行します。

1. マスター・ビュー・オブジェクトに、ディテール・ビュー・オブジェクトを参照するためのインライン・ビュー基準を定義し、バインド変数で定義されたビュー基準アイテムとして基準属性を指定します。

2. マスター・ビュー・オブジェクトに、各基準属性の値を受け取る更新可能な一時属性を定義します。実行時に、一時属性をプログラムで設定するかWebサービス・ペイロードで公開して、エンド・ユーザーが基準属性値(電子メール・アドレスなど)を入力できるようにすることができます。

3. ビュー基準を選択し、各基準属性のバインド変数をマスター・ビュー・オブジェクトの対応する一時属性に設定して、マスター・ビュー・オブジェクトに行検索を定義します。

6.2.10.1 マスター・ビュー・オブジェクトに対する行検索の定義

マスター・ビュー・オブジェクトの行セットをフィルタリングするために定義する行検索は、全体がマスター・ビュー・オブジェクトで定義されます。行検索では、インライン・ビュー基準内に指定された基準属性と実行時に取得された値が照合されます。基準属性値を受け取るために、マスター・ビュー・オブジェクトでは一時属性を定義できます。この一時属性は、アプリケーションがビュー・オブジェクトに対して行検索メソッドを使用してプログラムで設定するか、Webサービス・ペイロードが公開して、ユーザーにより提供された値を受け取ることができます。

行検索を定義するには、マスター・ビュー・オブジェクトの概要エディタの「行検索」ページを使用します。エディタで、選択したビュー基準の各バインド変数の値のソースを定義します。ビュー・オブジェクトの属性と、属性と値の式は、どちらも行検索によって定義されたバインド変数のソースとして有効です。

図6-10の概要エディタには、ビュー基準findPersonByEmailで指定されたビュー基準のバインド変数EmailBindVarを、マスター・ビュー・オブジェクトPersonVOによって定義された一時属性TrEmailAddress(値のソース)にマップする行検索が表示されています。

図6-10 行検索を表示したビュー・オブジェクトの概要エディタ

注意:

また、「行検索の使用」で説明しているように、行検索はマスター/ディテール階層に参加していないビュー・オブジェクトに対しても定義できます。

始める前に:

マスター/ディテール・ビュー・オブジェクトの行検索に関する知識が役立つ場合があります。詳細は、「行検索を使用したマスター・ビュー・オブジェクトの行の検索方法」を参照してください。

マスター/ディテール・ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「マスター/ディテール・ビュー・オブジェクトについて」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」または「ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法」の説明に従って、目的のマスター/ディテール・ビュー・オブジェクトを作成します。

- 「ビュー基準でのマスター/ディテール関連ビュー・オブジェクトの使用」の説明に従って、マスター・ビュー・オブジェクトに対してインライン・ビュー基準を定義します。インライン・ビュー基準は、ディテール・ビュー・オブジェクトを参照し、1つ以上のディテールの属性をビュー基準アイテムとして指定します。

- オプションで、「ビュー・オブジェクトへの計算属性および一時属性の追加」の説明に従って、更新可能な一時属性をマスター・ビュー・オブジェクトに追加します。一時属性は、アプリケーションでプログラムにより設定するか、ADFビジネス・コンポーネントWebサービス・ペイロードで公開してエンド・ユーザーに値を要求できます。基準参照値を受け取るには、一時属性を更新可能として定義する必要があります。

マスター・ビュー・オブジェクトの行検索を作成する手順:

1. 「アプリケーション」ウィンドウで、新しい行検索でカスタマイズするマスター・ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「行検索」ナビゲーション・タブをクリックし、「行検索の追加」ボタンをクリックします。

3. 「名前」フィールドで、行検索の名前を変更します。

たとえば、電子メール・アドレスから個人のレコードを特定する目的で定義する行検索であれば、PersonByEmailFinderなどの名前です。

4. 「行検索」リストで新しい行検索を選択し、「ビュー基準」ドロップダウンで、ビュー・オブジェクトの行セットをフィルタリングする行基準を選択します。

図6-10のように、目的の行検索が強調表示されます。行検索で使用するビュー基準を作成していない場合、ビュー基準のリストは空になります。

5. ADFビジネス・コンポーネントWebサービスのエンド・ユーザーが値を指定するようにする場合は、「属性」を選択したままにしてリストからバインド変数を選択し、「属性」ドロップダウンで、実行時にバインド変数の値を提供するマスター・ビュー・オブジェクトの一時属性を選択します。

ここで選択する一時属性は、行検索が基準の属性値を指定するために使用されます。たとえば、AddressVOの電子メール・アドレスに基づいて行を照合するマスター・ビュー・オブジェクトPersonVOには、TrEmailAddressという名前で定義した一時属性が含まれている可能性があります。

注意: ビュー・オブジェクトの概要エディタで一時属性を作成する際には、基準参照値を受け取れるようにするために、その一時属性を「更新可能」として定義してください。

6. 行検索で一致が許可される行数を指定する場合は、「すべてをフェッチ」の選択を解除します。

「フェッチ制限」に行数を入力した場合は、さらに「制限超過エラー」を選択することで、「フェッチ制限」で指定された数を超えた一致行がデータベースに存在する場合に、Oracle ADFで例外をスローできるようになります。

6.2.10.2 マスター・ビュー・オブジェクトの行検索作成時の処理

マスター・ビュー・オブジェクトの行検索を作成する場合は、行検索自体の定義も含めて、行検索で必要とされるすべてのメタデータをビュー・オブジェクト定義に含めます。次の例に示すように、行検索PersonByEmailFinderのメタデータとして、ビュー・オブジェクト定義には、<Variable>要素にバインド変数EmailBindVar、<ViewAttribute>要素に一時属性TrEmailAddress、<ViewCriteria>要素にビュー基準findPersonByEmailおよびインライン・ビュー基準AddressVONestedCriteriaがあり、最後に<RowFinders>要素に行検索PersonByEmailFinderが含まれています。

行検索の<VarAttributeMapping>サブ要素は、ビュー基準のバインド変数EmailBindVarをマスター・ビュー・オブジェクトの一時属性TrEmailAddressにマップしています。これにより、エンド・ユーザーが実行時に値を指定し、アプリケーションで必要な基準属性を使用して行検索を起動できるようになっています。インラインの<ViewCriteriaItem>サブ要素は、ディテール・ビュー・オブジェクトの基準属性EmailAddressを、バインド変数の値に設定しています。

実行時にマスター・ビュー・オブジェクトで行検索が起動されると、1つ以上のディテール基準属性により、マスター行セットから一致する行が特定されます。この例では、電子メール・アドレスを使用して、その電子メール・アドレスが属している個人が照合されています。行検索では、行のキー値を渡さなくても個人のレコードが特定されます。

<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="PersonVO"
SelectList="PersonEO.ID,
PersonEO.FIRST_NAME
PersonEO.LAST_NAME"
FromList="PERSON PersonEO"
...
<Variable
Name="EmailBindVar"
Kind="viewcriteria"
Type="java.lang.String"/>
<EntityUsage
Name="PersonEO"
Entity="model.entities.PersonEO"/>
...
<ViewAttribute
Name="TrEmailAddress"
IsUpdateable="false"
IsSelected="false"
IsPersistent="false"
PrecisionRule="true"
Type="java.lang.String"
ColumnType="CHAR"
AliasName="VIEW_ATTR"
SQLType="VARCHAR"/>
<ViewCriteria
Name="findPersonByEmail"
ViewObjectName="model.views.PersonVO"
Conjunction="AND">
...
<ViewCriteriaRow
Name="PersonVOCriteria_row_0"
UpperColumns="1">
<ViewCriteriaItem
Name="PersonVOCriteria_PersonVOCriteria_row_0_AddressVO"
ViewAttribute="AddressVO"
Operator="EXISTS"
Conjunction="AND"
IsNestedCriteria="true"
Required="Optional">
<ViewCriteria
Name="AddressVONestedCriteria"
ViewObjectName="model.views.AddressVO"
Conjunction="AND">
<ViewCriteriaRow
Name="AddressVONestedCriteria_row_0"
UpperColumns="1">
<ViewCriteriaItem
Name="AddressVONestedCriteria_row_0_EmailAddress"
ViewAttribute="EmailAddress"
Operator="="
Conjunction="AND"
Value=":EmailBindVar"
IsBindVarValue="true"
Required="Optional"/>
</ViewCriteriaRow>
</ViewCriteria>
</ViewCriteriaItem>
</ViewCriteriaRow>
</ViewCriteria>
...
<RowFinders>
<AttrValueRowFinder
Name="PersonByEmailFinder"
FetchLimit="1">
<ViewCriteriaUsage
Name="findPersonByEmail"
FullName="model.views.PersonVO.findPersonByEmail"/>
<VarAttributeMap>
<VariableAttributeMapping
Variable="EmailBindVar"
Attribute="TrEmailAddress"/>
</VarAttributeMap>
</AttrValueRowFinder>
</RowFinders>
</ViewObject>

6.3 再帰的なマスター/ディテール階層における単一表の使用

再帰的なデータ・モデルは、単一の表に基づくマスター/ディテール関係の関連元属性と関連先属性の名前を指定する単一の問合せを活用するものです。通常のマスター/ディテール関係では、関連元属性はマスター・ビュー・オブジェクトの主キー属性によって指定され、関連先属性はディテール・ビュー・オブジェクトの外部キー属性によって指定されます。たとえば、一般的なマスター/ディテール関係では、DEPARTMENT表のDepartmentId属性と、対応するEMPLOYEE表のDepartmentId属性が関連付けられます。しかし、再帰的モデルでは、関連元属性EmployeeIdと関連先属性ManagerIdがともにEMPLOYEE表に存在します。したがって、この関係に対する問合せで使用するのは、単一のビュー・オブジェクトのみです。このシナリオでは、両方の属性を指定する単一のベース・エンティティ・オブジェクトのビュー・オブジェクトを作成してから、自己参照型のビュー・リンクを定義し、このビュー・オブジェクトを「関連元」ビュー・オブジェクトおよび「関連先」ビュー・オブジェクト両方として構成してマスター/ディテール階層を形成します。

ビュー・リンクを作成したら、2つの方法でデータ・モデル・プロジェクトの再帰的マスター/ディテール階層を操作できます。次のいずれかを実行できます。

- 同一のビュー・オブジェクトの2つのインスタンス(ビュー・リンク・インスタンスによって能動的に調整され、マスターとしての役割を果たすものと、ディテールとしての役割を果たすもの)を公開するデータ・モデルを作成します。これは、2つの別々の表で同時に単一レベルのマスター行とディテール行を表示する必要があるときに有益です。

- ビュー・オブジェクトの単一のインスタンスのみを公開するデータ・モデルを作成し、各行のビュー・リンク・アクセッサ属性を使用してディテール行セットにアクセスします。再帰的マスター/ディテール階層のデータが存在する任意のレベルを表示(またはプログラム的に操作)できるため、2つのうち、この方法が一般的に使用されます。たとえば、treeまたはtreeTableコンポーネントの再帰的階層を表示する場合は、「ツリーでのマスター/ディテール・オブジェクトの表示方法」で説明されているように、このアプローチを使用します。

6.3.1 エンティティ・ベースのビュー・オブジェクトに対する再帰的マスター/ディテール階層の作成方法

再帰的マスター/ディテール階層では、ビュー・リンクで選択するリンク元およびリンク先のビュー・オブジェクトの属性は、通常、基礎となるエンティティ・オブジェクト間の自己参照型アソシエーションを定義する属性ペアと同じになります(このアソシエーションが存在する場合)。基礎をなすこのアソシエーションはビュー・リンクの作成には不要ですが、これによりビュー・リンクの作成が容易になるため、まず、ビュー・オブジェクトのベース・エンティティ・オブジェクトに対する外部キーを作成します。

再帰的マスター/ディテール階層を作成するには:

1. ビュー・オブジェクトのベース・エンティティ・オブジェクトを使用して、自己参照型ビュー・リンクを作成します。

2. 階層の「ルート」に表示する行のみを含めるようにビュー・インスタンスの結果をフィルタリングするビュー基準を持ったビュー・オブジェクトを公開します。

6.3.1.1 アソシエーション・ベースの自己参照型ビュー・リンクの作成

アソシエーションを作成するには、「アソシエーションの作成」ウィザードを使用します。「ビュー・リンクの作成」ウィザードを使用するときに、このアソシエーションが選択肢として表示されます。関連元ビュー・オブジェクトと関連先ビュー・オブジェクトに対して選択するアソシエーションでは、単一のデータベース表から導出された同じエンティティ・オブジェクトの名前を指定するため、このビュー・リンクは自己参照型になります。

始める前に:

再帰的なデータ・モデルに関する知識が役立つ場合があります。詳細は、「再帰的なマスター/ディテール階層における単一表の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- ビュー・リンクを作成する場合、エンティティ・オブジェクトの関連元属性と関連先属性間のアソシエーションは推測されません。再帰的階層をサポートするために、「アソシエーションの作成」ウィザードを使用して、関連元属性と関連先属性間のアソシエーションを作成できます。「エンティティ・オブジェクト」ページで、同一のエンティティ・オブジェクトを選択して関連元属性と関連先属性を指定し、ウィザードの他のすべてのデフォルト設定をそのままにします。アソシエーションの作成の詳細は、「アソシエーションの作成と構成」を参照してください。
たとえば、再帰的マスター/ディテール階層に、管理階層に基づく従業員のリストを表示するとします。このシナリオでは、Employeesエンティティ・オブジェクトに基づいてアソシエーションを作成します。「アソシエーションの作成」ウィザードの「エンティティ・オブジェクト」ページで、関連元属性としてEmployees.EmployeeIdを、関連先属性としてEmployee.ManagerIdを選択します。エンティティ・オブジェクトEmployeesによって両方の属性が指定されるため、このアソシエーションは自己参照型になります。

アソシエーション・ベースの自己参照型ビュー・リンクを作成する手順:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。

「ビュー・リンクの作成」ウィザードでパッケージ名の入力を省略するには、「アプリケーション」ウィンドウで、linksパッケージ・ノードのポップアップ・メニューから「新規」、「ビュー・リンク」の順に選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから、「ビュー・リンク」を選択し、「OK」をクリックします。

3. 「ビュー・リンクの作成」ウィザードの「名前」ページで、パッケージ名とコンポーネント名を指定します。

4. 「ビュー・オブジェクト」ページの「ソース属性の選択」ツリーで、目的のパッケージのソース・ビュー・オブジェクトを開きます。「関連先属性の選択」ツリーで、リンク先ビュー・オブジェクトを開きます。

ビュー・オブジェクト属性の他にも、エンティティ・ベースのビュー・オブジェクトの場合、リストには関連するアソシエーションも表示されます。

5. ソースのツリーおよび宛先のツリーで同じアソシエーションを選択します。その後、「追加」をクリックして、次の表にアソシエーションを追加します。

たとえば、図6-11では、関連元のツリーおよび関連先のツリーの両方で同じEmpManagersFkAssocアソシエーションが選択されています。アソシエーションの定義で、同じエンティティ・オブジェクト(この場合はEmployees)上で関連元属性と関連先属性が指定されているため、このビュー・リンクは自己参照型です。

図6-11 自己参照型アソシエーションの選択によるマスターとディテールの関連付け

6. 「ビュー・リンク・プロパティ」ページで、デフォルトの選択をそのままにしますが、関連先アクセッサのアクセッサ名を意味のわかりやすい名前に変更します。

たとえば、図6-12では、関連先アクセッサ名はEmployeesViewからStaffListに変更されています。この名前は、ユーザー・インタフェース開発者がこのアクセッサを選択してADF Facesツリー・コンポーネントを移入するときにバインディング・エディタで公開されます。ここで指定する名前により、UI開発者はこのアクセッサの目的(このケースでは、各管理者に関連付けられた従業員リストの生成)を理解します。

図6-12 ビュー・リンクの名前が変更された関連先アクセッサ

7. 「終了」をクリックします。

6.3.1.2 ビュー・インスタンスの公開とビュー基準によるフィルタ

プロジェクトのデータ・モデルのビュー・オブジェクトを公開する準備ができたら、ビュー基準を使用してツリーのルートの最初の値をフィルタリングするように、データ・モデルのビュー・インスタンスを構成します。たとえば、再帰的マスター/ディテール階層に、管理階層に基づく従業員のリストを表示するとします。このシナリオでは、階層全体のルート値にする従業員の従業員IDを指定するように、ビュー基準のバインド変数を構成します。この場合、管理者と従業員の再帰的階層のルート値は、組織で最高レベルの管理者の従業員IDにします。

始める前に:

再帰的なデータ・モデルに関する知識が役立つ場合があります。詳細は、「再帰的なマスター/ディテール階層における単一表の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- エンティティ・ベースのビュー・オブジェクトを作成し、階層の「ルート」に表示する行のみを含めるようにビュー・インスタンスの結果をフィルタリングするビュー基準を作成します。バインド変数を使用してビュー・オブジェクトをフィルタリングするビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。
たとえば、管理者と従業員の再帰的階層で、エンティティ・ベースのビュー・オブジェクトEmployeesViewを作成します。「アソシエーションの作成」ウィザードでビュー・オブジェクトを作成したら、概要エディタの「問合せ」ページで、階層の最上部に表示する従業員を特定するバインド変数とビュー基準を作成します。階層のルートに表示する従業員を1人にする必要がある場合、このシナリオのビュー基準では、従業員ID(関連元属性に対応)のバインド変数を使用してフィルタリングすると、「ビュー基準の作成」ダイアログに表示されるWHERE句は、((Employees.EMPLOYEE_ID = :TheEmployeeId ))のようになります(TheEmployeeIdはバインド変数名)。バインド変数を使用してビュー・オブジェクトをフィルタリングするビュー基準作成の詳細は、「カスケード・リストを制御するデータソース・ビュー・オブジェクトの作成」を参照してください。

既存のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを定義する手順:

1. 「アプリケーション」ウィンドウで、新しいビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。

3. 「データ・モデル」ページで、「ビュー・オブジェクト・インスタンス」セクションを展開し、「使用可能なビュー・オブジェクト」リストで、フィルタリング対象のビュー基準を定義したビュー・オブジェクト定義を選択します。

リストの下の「新規ビュー・インスタンス」フィールドに、データ・モデルに追加するビュー・オブジェクトの次のインスタンスを識別する際に使用される名前が示されます。

4. ビュー・オブジェクトを追加する前に名前を変更するには、「新規ビュー・インスタンス」フィールドに別の名前を入力します。

5. 目的のビュー・オブジェクトを選択し、「データ・モデル」リストに移動します。

図6-13では、ビュー・オブジェクトEmployeesViewの名前をEmployeesに変更してから、「データ・モデル」リストに移動しています。

図6-13 データ・モデルへのビュー・オブジェクト・インスタンスの追加

6. ビュー・オブジェクト・インスタンスをフィルタリングして階層のルート値を指定するには、追加したビュー・オブジェクト・インスタンスを選択し、「編集」をクリックします。

7. 「ビュー・インスタンスの編集」ダイアログで、作成したビュー基準を「選択されたもの」リストに移動し、階層のルートに対応するバインド・パラメータ値を入力します。

図6-14は、ビュー・オブジェクトのByEmployeeIdビュー基準と、階層の最高レベルの従業員に対応する値100に設定されているバインド・パラメータTheEmployeeIdを示しています。

図6-14 ビュー基準によるビュー・インスタンスのフィルタ

8. 「OK」をクリックします。

6.3.2 再帰的マスター/ディテール階層の作成時の処理

自己参照型ビュー・リンクを作成する場合、JDeveloperでその宣言的設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリ内に保存されます。このXMLファイルには、選択したアソシエーションで指定した関連元属性と関連先属性のペアに関する宣言情報と、選択した関連元および関連先ビュー・オブジェクトを関連付けるアソシエーションに関する宣言情報が含まれます。

次の例では、EmpManagerFkLinkのXMLドキュメント・ファイルで、関連元と関連先に同じビュー・オブジェクトEmployeesViewを定義しています。

<ViewLink
xmlns="http://xmlns.oracle.com/bc4j"
Name="EmpManagerFkLink"
EntityAssociation="test.model.EmpManagerFkAssoc">
<ViewLinkDefEnd
Name="EmployeesView1"
Cardinality="1"
Owner="test.model.EmployeesView"
Source="true">
<DesignTime>
<Attr Name="_finderName" Value="ManagerIdEmployeesView"/>
<Attr Name="_isUpdateable" Value="true"/>
</DesignTime>
<AttrArray Name="Attributes">
<Item Value="test.model.EmployeesView.EmployeeId"/>
</AttrArray>
</ViewLinkDefEnd>
<ViewLinkDefEnd
Name="EmployeesView2"
Cardinality="-1"
Owner="test.model.EmployeesView">
<DesignTime>
<Attr Name="_finderName" Value="StaffList"/>
<Attr Name="_isUpdateable" Value="true"/>
</DesignTime>
<AttrArray Name="Attributes">
<Item Value="test.model.EmployeesView.ManagerId"/>
</AttrArray>
</ViewLinkDefEnd>
</ViewLink>

ビュー・リンク・コンポーネント定義自体が保存されるだけでなく、JDeveloperによりビュー・オブジェクトのXML定義も更新され、定義されたビュー・リンク・アクセッサに関する情報が追加されます。これを確認するため、「アプリケーション」ウィンドウでビュー・オブジェクトを選択し、「構造」ウィンドウでその詳細を検証できます。図6-15に示すように、EmpManagerFkLinkビュー・リンクのEmployeesViewビュー・オブジェクトに定義されたアクセッサは、「ビュー・リンク・アクセッサ」ノードに表示されています。

図6-15 「構造」ウィンドウにビュー・リンク・アクセッサが表示されるビュー・オブジェクト

6.4 ビュー基準でのマスター/ディテール関連ビュー・オブジェクトの使用

ビュー基準を使用すると、ビュー・オブジェクト自体の問合せに適用されるビュー・オブジェクト問合せフィルタを宣言的な方法で定義できます。ディテール・ビュー・オブジェクトの属性を使用してマスター・ビュー・オブジェクトをフィルタリングしなければならない場合があります。マスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトが関係するビュー基準は、EXISTS演算子と、問合せフィルタを定義するためのインライン・ビュー基準に依存しています。EXISTS演算子により、インライン・ビュー基準はディテール・ビュー・オブジェクトを参照し、基準アイテムとして選択された属性を適用できます。たとえば、ビュー基準を行検索と組み合せて使用すると、マスター行セットをフィルタリングし、ディテール・ビュー・オブジェクトの基準アイテムを使用して行セットの特定の行を見つけることができます。

マスター・ビュー・オブジェクトにビュー基準を定義する場合は、そのビュー・オブジェクトの概要エディタの「ビュー基準」ページを使用します。たとえば、ディテールAddressVOのEmailAddress属性を使用してマスターPersonVOの行をフィルタリングするビュー基準findPersonByEmailは、次の例のようになります。この例では、ディテール・ビュー・オブジェクトAddressVOの電子メール属性の値を実行時に取得するために、ビュー基準の文にバインド変数EmailBindVarが使用されています。

( (EXISTS(SELECT 1 FROM ADDRESS AddressEONQ1 WHERE
(UPPER(AddressEONQ1.EMAIL_ADDRESS LIKE UPPER (:EmailBindVar || '%') ) )
AND
(PersonEO.PERSON_ID = AddressEONQ1.PERSON_ID) ) ) )

始める前に:

マスター・ビュー・オブジェクトに作用する行検索に関する知識が役立つ場合があります。詳細は、「行検索を使用したマスター・ビュー・オブジェクトの行の検索方法」を参照してください。

ビュー基準に関する知識が役立つ場合があります。詳細は、「名前付きビュー基準の処理」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」または「ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法」の説明に従って、目的のマスター/ディテール・ビュー・オブジェクトを作成します。

インライン・ビュー基準を作成する手順:

1. 「アプリケーション」ウィンドウで、新しいインライン・ビュー基準でカスタマイズするマスター・ビュー・オブジェクトをダブルクリックします。

インライン・ビュー基準の作成先のビュー・オブジェクトは、マスター/ディテール階層のマスター・ビュー・オブジェクトである必要があります。

2. 概要エディタで、「ビュー基準」ナビゲーション・タブをクリックし、「新規ビュー基準の作成」ボタンをクリックします。

3. 「ビュー基準の作成」ダイアログで、ビュー基準の名前を入力し、アプリケーション内での用途を識別できるようにします。

たとえば、個人の行セットを従業員の電子メールでフィルタリングするには、findPersonByEmailのようなビュー基準名を指定します。

4. 「問合せ実行モード」ドロップダウン・リストで、デフォルトの「データベース」を選択したままにします。

デフォルト・モードでは、ビュー・オブジェクトの問合せで指定されたデータベース表をビュー基準でフィルタリングできます。

5. 「基準の定義」タブで、「アイテムの追加」をクリックして、ビュー基準を定義します。

6. ビュー基準階層で、「グループ」の下にある割り当てられていないビュー基準アイテム・ノードを選択し、「基準アイテム」セクションで「属性」ドロップダウンを選択して、リストからディテール・ビュー・オブジェクトを選択します。

現在編集中のビュー・オブジェクトにビュー・リンクが存在している場合は、ディテール・ビュー・オブジェクトを選択して、インラインにネストされたビュー基準を持つビュー基準を作成できます。ディテール・ビュー・オブジェクトの名前が「属性」ドロップダウン・リストに表示されます。たとえば、図6-16に示すように、PersonVOはAddressVOにリンクされ、findPersonByEmailのビュー基準定義により、ディテール・ビュー・オブジェクトAddressVOの属性でマスター・ビュー・オブジェクトPersonVOがフィルタリングされます。

図6-16 インライン・ビュー基準を指定した「ビュー基準の編集」ダイアログ

7. 「演算子」と「オペランド」のデフォルトの選択肢は変更しないでおきます。

ビュー・オブジェクトの基準アイテムを含むインライン・ビュー基準を作成する場合は、デフォルトの選択肢として、エディタに演算子「存在する」とオペランド「インライン・ビュー基準」が指定されます。「ビュー基準でのマスター/ディテール関連ビュー・オブジェクトの使用」で説明しているように、実行時、EXISTS演算子はディテール・ビュー・オブジェクトに属性値が存在するかどうかをテストし、マスター・ビュー・オブジェクトの行をフィルタ処理します。

8. ビュー基準階層で、「グループ」の下にある新しいビュー基準アイテム・ノードを選択し、「基準アイテム」セクションで次のように入力します。

- 「属性」ドロップダウンで、フィルタ基準とするディテール・ビュー・オブジェクトの属性を選択します。
ディテールの属性は、マスター・ビュー・オブジェクトをフィルタリングするために使用される属性です。基準アイテムにバインド変数が定義されている場合は、この属性の値をエンド・ユーザーが指定できます。

- 「演算子」ドロップダウンで、必要なフィルタ演算子を選択します。

- 「オペランド」ドロップダウンで、「バインド変数」を選択し、ディテールの属性のバインド変数名を指定します。ビュー基準にすでに変数が定義されている場合は、「パラメータ」ドロップダウン・リストから選択します。そうでない場合は、「新規」をクリックして「新規変数」ダイアログを表示し、そこでビュー基準に対する新しいバインド変数の名前を指定します。
注意: ビュー基準で使用する既存のバインド変数をドロップダウン・リストから選択する場合は、ビュー・オブジェクトの問合せ用に定義されたバインド変数を選択しないでください(これらは概要エディタの「問合せ」ページに表示されます)。概要エディタの「ビュー基準」ページで定義したバインド変数のみを選択してください。

9. 実行時に指定される値が大文字か小文字かに基づいた、大/小文字を区別した属性のフィルタリングを無効にする場合は、「大/小文字を区別しない」が選択された状態のままにします。

このオプションは、String型の属性に対してのみサポートされています。デフォルトでは、大/小文字の区別のある検索は使用できません。

10. 「検証」ドロップダウン・リストでは、デフォルトである「オプション」を選択したままにします。

「オプション」を選択すると、値がNULLでない場合にのみビュー基準(または検索フィールド)がWHERE句に追加されます。新規の各ビュー基準アイテムに対してデフォルトの「オプション」を選択すると、NULL値に対しても例外は生成されません。たとえば、図6-17は、findPersonByEmailビュー基準定義により、ディテール・ビュー・オブジェクトAddressVOのEmail属性でマスター・ビュー・オブジェクトPersonVOがフィルタリングされ、値がNULLでも許可されることを示しています。

図6-17 バインド変数の基準アイテムを指定した「ビュー基準の編集」ダイアログ

11. 「OK」をクリックします。

12. 概要エディタの「ビュー基準」ページでバインド変数を選択し、「詳細」セクションのデフォルトの設定は、次のように、変更しないでおきます。

- 「リテラル」は選択したままにしますが、デフォルト値は指定しないでください。値は実行時にエンド・ユーザーから取得されます。

- 「更新可能」を選択したままにして、バインド変数の値がユーザー・インタフェースから定義されるようにします。

13. 「ビュー基準」ページで「UIヒント」タブをクリックし、「ラベル」、「フォーマットの種類」、「フォーマット」マスクなどのヒントを指定します。

名前付きバインド変数の値を入力できる検索ページなどのユーザー・インタフェースを作成する場合、ビュー・レイヤーではバインド変数のUIヒントが使用されます。フォーマットは、Date型または任意の数値データ型で定義されたバインド変数でのみサポートされることに注意してください。

7 多相ビュー・オブジェクトの定義

この章では、ADFビジネス・コンポーネントの継承を使用して、Oracle ADFアプリケーションで複数のビュー行型を公開するADFビュー・オブジェクトを作成する方法を説明します。また、この章では、エンティティ・オブジェクトの継承を使用するかわりの方法として、ビュー・オブジェクトの継承階層を定義して異種ビュー行を生成する方法についても説明します。

この章の内容は次のとおりです。

- 多相ビュー・オブジェクトについて

- 多相エンティティ・オブジェクトの慣用名での作業

- 多相ビュー行関連の作業

- 識別子属性に関する必知事項

- サブタイプ・オブジェクトの慣用名を表示するためのアプリケーション・モジュールの更新

7.1 多相ビュー・オブジェクトについて

ビュー・オブジェクトでは、ベース・エンティティ・オブジェクトによって表現される表を作成できます。一般に、エンティティ・ベースのビュー・オブジェクトを作成するときには、Domestics(国内の顧客に関連する固有の属性を含むと考えられる)など、単一の型を持つエンティティ行を操作するようにビュー・オブジェクトを作成します。また、場合によっては、同じ行セットでエンティティ・オブジェクト継承階層に基づいて行を問い合せて更新することもあります。たとえば、同じ行セットで、Customers、DomesticsおよびInternationalsの各エンティティ・オブジェクトの継承階層に共通する属性を処理することがあります。ここで、DomesticsとInternationalsは、親のCustomersエンティティ・オブジェクトのサブタイプ・エンティティ・オブジェクトです。このようなビュー・オブジェクトは多相ビュー・オブジェクトと呼ばれます。クライアントで多相ビュー・オブジェクトが適切に使用されるようにするために、ビュー・オブジェクトでは、異種混在の行セット内の各行について、委譲先のエンティティ・オブジェクトを認識しておく必要があります。行の型を識別するために、多相ビュー・オブジェクトは、各行の対応する表を特定する識別子属性に依存しています。

ADFビジネス・コンポーネントは、次のタイプのポリモフィズムをサポートします。

- エンティティ・オブジェクトは多相サブタイプを定義しますが、ビュー・オブジェクトはしません。
これは、バックエンド・ビジネス・ロジックは各種タイプを認識する必要があるが、プレゼンテーション・レイヤーはビュー・インスタンスを単一のタイプとみなす必要がある場合に役立ちます。この場合、ビュー・インスタンスは、エンティティ・サブタイプによって定義された各属性の共通のセットを含みます。

- エンティティ・オブジェクトとビュー・オブジェクトの慣用名は、どちらも多相サブタイプを定義します。
この場合、バックエンド・ビジネス・ロジックとプレゼンテーション・レイヤーは、どちらも各種サブタイプを区別する必要があります。

- エンティティ・オブジェクトは多相サブタイプを定義しませんが、ビュー・オブジェクトの慣用名は多相サブタイプを定義します。
この場合、プレゼンテーション・レイヤーはビュー・サブタイプを区別する必要がありますが、バックエンド・ビジネス・ロジックは一意ではありません。

多相ビュー・オブジェクト(エンティティ・サブタイプの継承に基づくもの)を作成する場合、クライアントに様々なエンティティ・サブタイプが公開されることはありません。クライアントが関係する範囲では、ビュー・オブジェクトの結果セットの各行は同じ属性セットと同じ行の型を持ちます。このようになるのは、ADFビジネス・コンポーネントによって、識別子属性の値に基づいて必ず正しいエンティティ・オブジェクト行サブタイプが作成されるようになっているからです。つまり、多相エンティティ・オブジェクトの慣用名を使用することで、ビュー行の型は一定でありながら、ビュー行のエンティティ行の部分でのみ型が変更できるようになっています。

一方、(エンティティ・サブタイプでなく)ビュー・オブジェクト階層によって定義される継承に基づいて多相ビュー・オブジェクトを作成する場合は、アプリケーション・モジュールを構成して、結果に1つ以上のビュー行サブタイプが存在するようにできます。クライアントに表示されるビュー行の型に異なる複数のサブタイプを生成できるのは、多相ビュー行を使用した場合のみです。また、多相エンティティ・オブジェクトの慣用名から派生したビュー・オブジェクトとは異なり、ビュー行のサブタイプに属性を追加してクライアントに公開できることも、多相ビュー行のみの特徴です。

注意:

この章の概念を説明する例を試すには、「SummitADF_Examplesワークスペースからのスタンドアロン・サンプルの実行」.の説明に従ってSummitADF_Examplesワークスペースを使用します。Summit ADFスタンドアロン・サンプル・アプリケーションを取得およびインストールする方法の詳細は、「Oracle ADF用Summitサンプル・アプリケーションの設定」を参照してください。

7.1.1 多相エンティティ・オブジェクトの慣用名と多相ビュー行の慣用名

いずれかのタイプのポリモーフィズムを使用したり、2つを結合したりできます。

通常は一緒に使用する方が役に立ちますが、ビュー行ポリモーフィズム機能と多相エンティティ・オブジェクト慣用名機能は異なるものであり、個別に使用できます。特に、ビュー行ポリモーフィズムの機能は、読取り専用ビュー・オブジェクトにも、エンティティ・ベースのビュー・オブジェクトにも使用できます。両方のメカニズムを組み合せると、多相のエンティティ行部分とビュー行型の両方を持つことができます。

ビュー・オブジェクトまたはエンティティ・オブジェクトでビュー行ポリモーフィズムを使用するには、それぞれに個別の識別子属性プロパティを構成する必要があることに注意してください。これが必要になるのは、読取り専用ビュー・オブジェクトには、識別子情報を推測する関連エンティティ・オブジェクトの慣用名が含まれていないためです。

識別子属性が1レベルを超えない深さで定義されるビュー・オブジェクトを必要とする多相ビュー・オブジェクトの場合は、制限があります。プロジェクトで行のサブタイプを指定する識別子属性を持つ多相ビュー・オブジェクを定義する場合がありますが、このとき別のビュー・オブジェクトを使用して、最初の多相ビュー・オブジェクトに基づいてさらにサブ行を指定すると、サブ行の表示でエラーが発生します。多相ビュー・オブジェクトを作成する場合は、識別子属性の定義を1レベルに制限してください。

要約すると、多相エンティティ・オブジェクトの慣用名を含むビュー・オブジェクトを作成するには、次のことを行います。

1. 継承階層のルート・エンティティ・オブジェクトのエンティティ・オブジェクト・レベルで、識別子にする属性を構成します。

2. 継承されるエンティティ・オブジェクトの階層を定義し、階層内のエンティティ・オブジェクトのそれぞれでオーバーライドを行って、そのエンティティ・オブジェクト・レベルの識別子属性のサブタイプ値プロパティに個別の値を設定します。

3. ビュー・オブジェクトのサブタイプのリストに、サブクラス化されたエンティティ・オブジェクトのリストを入れます。

4. アプリケーション・モジュールを更新して、この階層のエンティティ・ベースのサブタイプ・ビュー・オブジェクトを、アプリケーション・モジュールのサブタイプのリストに公開します。

このため、ビュー行のポリモフィズムを使用する場合は、次の手順を実行します。

1. 継承階層のベース・ビュー・オブジェクトのビュー・オブジェクト・レベルで、識別子にする属性を構成します。

2. 継承されるビュー・オブジェクトの階層を定義し、階層内の各ビュー・オブジェクトのビュー・オブジェクト・レベルの識別子属性に、サブタイプ値プロパティとして個別値(ビュー・オブジェクト定義ファイルの属性のDefaultValueとして識別される)を指定します。

3. アプリケーション・モジュールを更新して、この階層のサブクラス化されたサブタイプ・ビュー・オブジェクトを、アプリケーション・モジュールのサブタイプのリストに公開します。

7.2 多相エンティティ・オブジェクトの慣用名での作業

多相エンティティ・オブジェクトの慣用名とは、継承階層のベース・エンティティ・オブジェクトを参照し、そのエンティティのサブタイプも処理するように構成されているものです。図7-1は、多相エンティティ・オブジェクトの慣用名でビュー・オブジェクトを使用した結果を示しています。エンティティ・ベースのCustomerListビュー・オブジェクトには、プライマリ・エンティティ・オブジェクトの慣用名としてCustomersエンティティ・オブジェクトがあります。ビュー・オブジェクトは、データベースから取得された各行を、Customersの様々なサブタイプに固有の属性を持つエンティティ行に分割します。識別子属性の値の検査に基づいて、適切なエンティティ行サブタイプを作成します。たとえば、CustomerListの問合せで、国内企業ABC Companyの1行と国際企業Simms Athleticsの1行が取得された場合、基礎になっているエンティティ行は図で示されているようになります。

図7-1 多相エンティティ・オブジェクトの慣用名を持つビュー・オブジェクトによるエンティティ・サブタイプの処理

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.polymorphicパッケージを参照します。

7.2.1 多相エンティティ・オブジェクトの慣用名を持つサブタイプ・ビュー・オブジェクトを作成する方法

多相エンティティ・オブジェクトの慣用名で作成するビュー・オブジェクトは、ベース・エンティティ・オブジェクトおよびエンティティ・サブタイプの1つ以上の属性を継承できます。エンティティ・オブジェクトから選択する属性は、ビュー・オブジェクト属性定義によってオーバーライドされます。エンティティ・ベースのビュー・オブジェクトが識別子属性を持つエンティティ・オブジェクトを参照していると、Oracle ADFはその識別子属性も(主キー属性に加えて)問合せに含まれるようにします。

始める前に:

多相ビュー・オブジェクト(この項では、サブタイプ・ビュー・オブジェクトとも呼びます)について理解しておくと役立ちます。詳細は、「多相ビュー・オブジェクトについて」を参照してください。

次のタスクを完了する必要があります。

1. ビュー・オブジェクトの基礎となるベース・エンティティ・オブジェクトおよびエンティティ・サブタイプを作成します。ベース・エンティティ・オブジェクトおよびエンティティ・サブタイプの作成の詳細は、「継承階層内にエンティティ・オブジェクトを作成する方法」を参照してください。

2. ベース・エンティティ・オブジェクトからエンティティ・ベースのビュー・オブジェクトを作成し、サブタイプ・ビュー・オブジェクトに共通する属性を選択します。ベース・ビュー・オブジェクトは、各サブタイプ・ビュー・オブジェクトによって表される属性のスーパーセットを含む必要があります。エンティティ・ベースのビュー・オブジェクトの作成の詳細は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。

3. 作成するベース・ビュー・オブジェクトで、作成する各サブタイプ・ビュー・オブジェクトに対応するエンティティ・サブタイプを選択します。JDeveloperは、作成予定の多相エンティティの慣用名セレクションに作成できるサブタイプ・ビュー・オブジェクトを制限します。
ベース・ビュー・オブジェクトでエンティティ・サブタイプを選択する手順:

a. 概要エディタでベース・ビュー・オブジェクトを開き、「エンティティ・オブジェクト」ナビゲーション・タブをクリックします。

b. 「エンティティ・オブジェクト」ページで「サブタイプ」をクリックし、「サブタイプの選択」ダイアログで、エンティティ・サブタイプを「選択済」リストに追加します。

たとえば、図7-2に示すように、エンティティ・サブタイプDomesticsおよびInternationalsが、それぞれのサブタイプ・ビュー・オブジェクトの作成を予期して選択されています。

図7-2 エンティティ・サブタイプによる、可能なサブタイプ・ビュー・オブジェクトの定義

多相エンティティ・オブジェクトの慣用名でサブタイプ・ビュー・オブジェクトを作成する手順:

1. 「アプリケーション」ウィンドウでデータ・モデル・プロジェクトを右クリックし、「新規」、「ビュー・オブジェクト」の順に選択します。

2. 「ビュー・オブジェクトの作成」ウィザードで、サブタイプ・ビュー・オブジェクトの名前を指定し、「拡張」フィールドの横にある「参照」をクリックします。
たとえば、サブタイプ・ビュー・オブジェクトがベース・ビュー・オブジェクトCustomerListを拡張する場合、サブタイプ・ビュー・オブジェクトにDomesticListまたはInternationalListを指定することがありえます。この場合、DomesticsとInternationalsの各サブタイプ・エンティティ・オブジェクトの多相エンティティ・オブジェクト慣用名を使用したサブタイプ・ビュー・オブジェクト作成をサポートするために、データ・モデル・プロジェクトでベースのCustomersエンティティ・オブジェクトを定義できます。

3. 「親の選択」ダイアログで、拡張するエンティティ・ベースのビュー・オブジェクトを選択して、「OK」をクリックします。
選択したビュー・オブジェクトが、属性のスーパーセットを定義するベース・ビュー・オブジェクトであり、サブタイプ・ビュー・オブジェクトが拡張するビュー・オブジェクトです。たとえば、図7-3に示すように、サブタイプ・ビュー・オブジェクトDomesticListを作成する場合、拡張するベース・ビュー・オブジェクトCustomerListを選択します。

図7-3 サブタイプ・ビュー・オブジェクトによるベース・ビュー・オブジェクトの拡張

4. ビュー・オブジェクト作成ウィザードで、データ・ソースとして「エンティティ」が選択されていることを確認して、「次へ」をクリックします。

5. 「エンティティ・オブジェクト」ページの「使用可能」リストで、サブタイプ・ビュー・オブジェクトの多相エンティティの慣用名として定義するエンティティ・サブタイプを見つけ、「追加」をクリックします。
この手順の前提条件で説明したように、使用できるエンティティ・サブタイプのリストはベース・エンティティ・オブジェクトの継承階層で定義されます。たとえば、ベース・ビュー・オブジェクトCustomerListのサブタイプ・ビュー・オブジェクトDomesticListを作成する場合、図7-4に示すように、「使用可能」リストから、エンティティ・サブタイプとしてDomesticsを追加します。

図7-4 多相エンティティ・オブジェクトの慣用名が選択されたサブタイプ・ビュー・オブジェクト

6. 「ビジネス・コンポーネント」ダイアログで「はい」をクリックすると、目的の多相エンティティ・オブジェクトの慣用名で、サブタイプ・ビュー・オブジェクトのエンティティ・オブジェクトの慣用名をオーバーライドします。
ビジネス・コンポーネント」ダイアログで、ベース・エンティティ・オブジェクトの慣用名の属性をエンティティ・サブタイプでオーバーライドする旨の警告が示されます(図7-5を参照)。

ダイアログで「いいえ」をクリックすると、ベース・エンティティ・オブジェクト慣用名の属性をオーバーライドせずに、追加の慣用名が追加される点に注意してください。通常は、「はい」をクリックして、目的のエンティティ・サブタイプで、ベース・エンティティ・オブジェクトの慣用名をオーバーライドします。

図7-5 多相エンティティ・オブジェクトの慣用名によるサブタイプ・ビュー・オブジェクトのオーバーライド

7. 「選択済」リストで、オーバーライドされたエンティティ・オブジェクト慣用名を選択して、「サブタイプ」をクリックします。

8. 「サブタイプの選択」で、シャトル・ボタンを使用して「選択済」リストに目的の多相エンティティ・サブタイプのみを残して、「OK」をクリックします。
「サブタイプの選択」ダイアログを使用すると、ビュー・オブジェクト作成ウィザードの「エンティティ・オブジェクト」ページで定義したオブジェクトの慣用名が参照するエンティティ・サブタイプを指定できます。この手順の前提条件で説明したように、使用できるエンティティ・サブタイプのリストはベース・オブジェクトにより定義されます。通常、オーバーライド対象として選択したものと同じエンティティ・サブタイプを選択します(図7-5参照)。

たとえば、サブタイプ・ビュー・オブジェクトDomesticListを作成する場合、図7-6に示すように、ベース・エンティティ・オブジェクトCustomersの単一エンティティ・サブタイプとしてDomesticsを選択(および、「選択済」リストからInternationalsを選択解除)します。

図7-6 単一の多相エンティティ・オブジェクトの慣用名が適用されたサブタイプ・ビュー・オブジェクト

9. ビュー・オブジェクトの作成ウィザードの「エンティティ・オブジェクト」ページで、「次へ」をクリックし、ウィザードの「属性」ページで必要な属性をエンティティ・サブタイプから「選択済」リストに移動します。
たとえば、DomesticListビュー・オブジェクト用に、エンティティ・サブタイプDomesticsからState属性を選択します(図7-7を参照)。

図7-7 エンティティ・サブタイプの属性が追加されたビュー・オブジェクト

10. 「属性」ページで、拡張されたビュー・オブジェクトが単一の主キー属性を定義するように主キー属性を削除し、次に識別子属性を選択して、「オーバーライド」をクリックし、「次へ」をクリックします。
たとえば、DomesticListビュー・オブジェクトの場合、図7-8に示すように、サブタイプ・ビュー・オブジェクトの選択済リストからCountryId属性を削除して、CountryId属性をオーバーライドします。

図7-8 オーバーライドされた識別子属性を持つビュー・オブジェクト

11. 「属性の選択」ページで、ドロップダウンから識別子属性を選択して、サブタイプを定義する「デフォルト値」を入力し、Finishをクリックしてウィザードを完了します。
たとえば、DomesticListビュー・オブジェクトの場合、図7-9に示すように、DOMESTICと入力します。

図7-9 オーバーライドされた識別子属性を持つビュー・オブジェクト

12. この手順を繰り返して、一意の多相エンティティ・オブジェクトの慣用名を持つ、追加のサブタイプ・ビュー・オブジェクトを作成します。
たとえば、InternationalListビュー・オブジェクトは、CustomerListを拡張する2番目のサブタイプです。このオブジェクトでは、CustomerTypeCode識別子属性に値INTERNATIONALを設定しています。

サブタイプ・ビュー・オブジェクトを作成した後で、「サブタイプ・オブジェクトの慣用名を表示するためのアプリケーション・モジュールの更新」の説明に従い、ビュー・オブジェクト・ポリモフィズムに参加するサブタイプのリストを定義する必要があります。たとえば、ビュー・インスタンスCustomerList1を持つCustomersModuleアプリケーション・モジュールは、DomesticListおよびInternationalListの各サブタイプ・ビュー・オブジェクトを指定するように構成する必要があります。

7.2.2 多相エンティティ慣用名によりサブタイプ・ビュー・オブジェクトを作成すると行われる処理

概要エディタの「エンティティ・オブジェクト」ページに、選択されたエンティティ・オブジェクトとエンティティ・オブジェクト慣用名オーバーライドが表示されます。たとえば、DomesticListビュー・オブジェクトの概要エディタに、Customers (Domestics): overriddenのように、オーバーライドされたエンティティ・オブジェクト慣用名とカッコで囲まれたオーバーライドするサブタイプが表示されます(図7-10を参照)。

図7-10 ビュー・オブジェクト・エディタでのエンティティ・オブジェクトの慣用名のオーバーライド

多相エンティティ・オブジェクトの慣用名でエンティティ・ベースのビュー・オブジェクトを作成すると、JDeveloperにより、許可されるエンティティ・サブタイプに関する情報がベース・ビュー・オブジェクトのXMLドキュメントに追加されます。たとえば、CustomerListビュー・オブジェクトを作成すると、許可されるサブタイプ・エンティティ・オブジェクトの名前が<AttrArray>タグに記録されます。XMLプロパティDiscrColumnは、CountryTypeCodeを、次のようなベース・ビュー・オブジェクトの多相識別子属性として識別します。

<ViewObject Name="CustomerList" ... >
<EntityUsage
Name="Customers"
Entity="oracle.summit.model.polymorphics.entities.Customers" >
</EntityUsage>
<AttrArray Name="EntityImports">
<Item Value="oracle.summit.model.polymorphic.entities.Domestics" />
<Item Value="oracle.summit.model.polymorphic.entities.Internationals" />
</AttrArray>
...
<ViewAttribute
Name="CountryTypeCode"
PrecisionRule="true"
EntityAttrName="CountryTypeCode"
EntityUsage="Customers"
AliasName="COUNTRY_TYPE_CODE"
DiscrColumn="true">
</ViewAttribute>
...
</ViewObject>

こうして、多相エンティティ・オブジェクトの慣用名でサブタイプ・ビュー・オブジェクトを作成すると、JDeveloperにより、ベース・ビュー・オブジェクトに関する情報がサブタイプ・ビュー・オブジェクトのXMLドキュメントに追加されます。たとえば、次の例は、ベース・ビュー・オブジェクトの名前がExtendsプロパティ内に記録されたDomesticListサブタイプ・ビュー・オブジェクトを示しています。XMLプロパティDiscrColumnは、オーバーライドされたCountryTypeCode属性を、DOMESTICのサブタイプ値を持つ多相識別子属性として識別します。サブタイプ・ビュー・オブジェクトに固有の追加の属性Stateのみが、XMLドキュメントに表示されます。

<ViewObject
Name="DomesticList"
Extends="oracle.summit.model.polymorphic.views.CustomerList"
...>
<EntityUsage
Name="Customers"
Entity="oracle.summit.model.polymorphic.entities.Domestics"/>
<AttrArray Name="EntityImports">
<Item Value="oracle.summit.model.polymorphicsample.Domestics"/>
</AttrArray>
<ViewAttribute
Name="CountryTypeCode"
PrecisionRule="true"
DiscrColumn="true"
EntityAttrName="CountryTypeCode"
EntityUsage="Customers"
AliasName="COUNTRY_TYPE_CODE"
DefaultValue="DOMESTIC">
<DesignTime>
<Attr Name="_OverrideAttr" Value="true"/>
</DesignTime>
</ViewAttribute>
<ViewAttribute
Name="State"
PrecisionRule="true"
EntityAttrName="State"
EntityUsage="Customers"
AliasName="STATE"/>
</ViewObject>

同様に、次に示すように、InternationalListサブタイプ・ビュー・オブジェクトのXMLドキュメントでは、同じCustomerListベース・ビュー・オブジェクトの名前がそのXMLドキュメントのExtendsプロパティ内に指定されていますが、INTERNATIONALというサブタイプ値を持つ多相識別子属性と、そのサブタイプに固有の追加属性Languageが定義されています。

<ViewObject
Name="InternationalList"
Extends="oracle.summit.model.polymorphic.views.CustomerList"
... >
<EntityUsage
Name="Customers"
Entity="oracle.summit.model.polymorphic.entities.Internationals"/>
<AttrArray Name="EntityImports">
<Item Value="oracle.summit.model.polymorphicsample.Internationals"/>
</AttrArray>
<ViewAttribute
Name="CountryTypeCode"
PrecisionRule="true"
DiscrColumn="true"
EntityAttrName="CountryTypeCode"
EntityUsage="Customers"
AliasName="COUNTRY_TYPE_CODE"
DefaultValue="INTERNATIONAL">
<DesignTime>
<Attr Name="_OverrideAttr" Value="true"/>
</DesignTime>
</ViewAttribute>
<ViewAttribute
Name="Language"
PrecisionRule="true"
EntityAttrName="Language"
EntityUsage="Customers"
AliasName="LANGUAGE"/>
</ViewObject>

サブタイプ・ビュー・オブジェクト定義の<AttrArray>タグが、各サブタイプで許可されたエンティティ・オブジェクトを識別している点に注意してください。したがって、各サブタイプ・ビュー・オブジェクトは、単一のサブタイプ・エンティティ・オブジェクトを指定するはずです。サブタイプ・ビュー・オブジェクト定義の<AttrArray>タグが複数のエンティティ・オブジェクトを指定している場合、未使用のものを削除できます。この状況は、図7-6に示すように、ビュー・オブジェクトの作成ウィザードを使用してサブタイプ・ビュー・オブジェクトを作成したが、「サブタイプの選択」ダイアログでデフォルト・サブタイプ・エンティティ・オブジェクトのリストを縮小しなかった場合に発生します。デフォルトで、このダイアログではすべてのサブタイプ・エンティティ・オブジェクトが選択されます。

7.2.3 多相エンティティ・オブジェクトの慣用名に関する必知事項

多相エンティティ・オブジェクトの慣用名からビュー・オブジェクトを派生させる場合は、識別子属性による問合せのフィルタリングによって期待するサブタイプのみが含まれるように、次のベスト・プラクティスに従うことをお薦めします。

7.2.3.1 問合せでは期待するエンティティ・サブタイプに行を制限する必要がある

ビュー・オブジェクトが階層で使用可能なエンティティ・サブタイプのサブセットのみを使用する場合は、識別子列が期待するエンティティ・タイプと一致する行のみを返すように問合せを制限する適切なWHERE句を含める必要があります。問合せでサブタイプのフィルタリングを行うときには、識別子属性のみに依存しないでください。問合せを絞り込むための属性を追加しないと、ビュー・オブジェクトでは事実上すべての行に問合せが実行され、どの識別子の値にも一致しない列がクライアントで破棄されることになります。

7.2.3.2 委譲を使用したビュー行での選択したエンティティ・メソッドの公開

設計上、クライアントはエンティティ・オブジェクトを直接使用しません。かわりに、当面のタスクに関連する情報のセットを表す適切なビュー・オブジェクトのビュー行を通して、間接的にエンティティ・オブジェクトを使用します。ビュー・オブジェクトは、当面のタスクに関連する1つまたは複数のエンティティ・オブジェクトの基礎となる属性の特定のセットを公開できるのと同じように、これらのエンティティから選択されたメソッドのセットも公開できます。そのためには、カスタム・ビュー行のJavaクラスを有効にし、次のビュー行クラスでメソッドを記述します。

- ビュー行で生成されるエンティティ・アクセッサを使用して基礎となる適切なエンティティ行にアクセス

- そのメソッドの呼出し

たとえば、Customersエンティティ・オブジェクトに、そのCustomersImplクラスのperformCustomerFeature()メソッドが含まれているとします。このメソッドをCustomerListビュー行でクライアントに公開するには、カスタム・ビュー行のJavaクラスを有効にし、次の例に示すようにメソッドを記述します。

// In CustomerListRowImpl.java
public void performCustomerFeature() {
getTheCustomer().performCustomerFeature();
}

JDeveloperは、エンティティ・オブジェクトの慣用名の別名に基づいて、関係する各エンティティ・オブジェクトの慣用名に対するビュー行クラスで、エンティティ・アクセッサ・メソッドを生成します。CustomerListビュー・オブジェクトでのCustomersエンティティの別名はTheCustomerであるため、そのエンティティ・オブジェクトの慣用名に関係するエンティティ行部分を返すためのgetTheCustomer()メソッドを生成します。

ビュー行のperformCustomerFeature()メソッドのコードでは、このgetTheCustomer()メソッドを使用して基礎となるCustomersImplエンティティ行クラスにアクセスし、そのperformCustomerFeature()メソッドを呼び出します。このコーディング・スタイルは委譲と呼ばれるもので、ビュー行メソッドはそのメソッドの1つの実装を、基礎となるエンティティ・オブジェクトの対応するメソッドに委譲します。多相エンティティ・オブジェクトの慣用名のあるビュー行で委譲が使用されると、委譲されたメソッド呼出しは、基礎となる適切なエンティティ行サブタイプによって処理されます。つまり、CustomersImplクラス、DomesticsImplクラスおよびInternationalsImplクラスが異なる方法でperformCustomerFeature()メソッドを実装している場合は、現在行のエンティティ・サブタイプに応じて、適切な実装が使用されます。

クライアント行インタフェースでこのメソッドを公開すると、クライアント・プログラムは、カスタム行インタフェースを使用して、特定のビュー行でカスタム・ビジネス機能を呼び出すことができます。次の例は、TestEntityPolymorphismクラスのコード行を示しています。CustomerListビュー・オブジェクト・インスタンスのすべての行を反復し、各行をカスタムのCustomerListRowインタフェースにキャストして、performCustomerFeature()メソッドを呼び出しています。

CustomerList customerlist = (CustomerList)am.findViewObject("CustomerList");
customerlist.executeQuery();
while (customerlist.hasNext()) {
CustomerListRow customer = (CustomerListRow)customerlist.next();
System.out.print(customer.getEmail()+"->");
customer.performCustomerFeature();
}

前述の例のクライアント・コードを実行すると、次のような出力が生成されます。

austin->## performCustomerFeature as Domestics
hbaer->## performCustomerFeature as Internationals
:
sking->## performCustomerFeature as Domestic
:

Customersエンティティに関連する行では、CustomersImplクラスのperformCustomerFeature()メソッドが使用されたことを確認するメッセージが表示されます。Domesticsエンティティに関連する行とInternationalsエンティティに関連する行では異なるメッセージが表示され、DomesticsImplクラスとInternationalsImplクラスが継承されたperformCustomerFeature()メソッドに関して持っている異なる実装がはっきり示されます。

7.2.3.3 目的のエンティティ・サブタイプでの新しい行の作成

多相エンティティ・オブジェクトの慣用名のあるビュー・オブジェクトでは、新しいビュー行を作成すると、それにはベース・エンティティ・オブジェクトの慣用名と一致する型を持つ新しいエンティティ行部分が含まれます。かわりにいずれかのエンティティ・サブタイプで新しいビュー行を作成するには、createAndInitRow()メソッドを使用します。

次の例は、CustomerListビュー・オブジェクトのJavaクラスにおける2つのカスタム・メソッドを示しており、これらのメソッドでは、createAndInitRow()を使用して、クライアントがDomesticsまたはInternationalsサブタイプのエンティティ行を持つ新しい行を作成できるようにしています。createAndInitRow()を使用するには、例で示されているように、NameValuePairsオブジェクトのインスタンスを作成し、それに識別子属性の適切な値を設定します。次に、そのNameValuePairsをcreateAndInitRow()メソッドに渡し、指定した識別子属性の値に基づいて、適切なエンティティ行サブタイプを持つ新しいビュー行を作成します。

// In CustomerListImpl.java
public CustomerListRow createCustomersRow() {
NameValuePairs nvp = new NameValuePairs();
nvp.setAttribute("CustomerTypeCode","DOMESTIC");
return (CustomerListRow)createAndInitRow(nvp);
}
public CustomerListRow createInternationalsRow() {
NameValuePairs nvp = new NameValuePairs();
nvp.setAttribute("CustomerTypeCode","INTERNATIONAL");
return (CusotmersListRow)createAndInitRow(nvp);
}

このようなメソッドをビュー・オブジェクトのカスタム・インタフェースで公開すると、実行時に、クライアントはそれを呼び出して、適切なエンティティ・サブタイプを持つ新しいビュー行を作成できます。次の例は、TestEntityPolymorphismクラスのこの機能に関連する行を示しています。最初に、createRow()メソッド、createDomesticsRow()メソッドおよびcreateInternationalsRow()メソッドを使用して、3つの新しいビュー行を作成します。次に、新しい行のそれぞれで、CustomerListRowカスタム・インタフェースからperformCustomerFeature()メソッドを呼び出します。

// In TestEntityPolymorphism.java
CustomerListRow newCustomer = (CustomerListRow)CustomerList.createRow();
CustomerListRow newDomestic  = Customerlist.createDomesticsRow();
CustomerListRow newInternational = Customerlist.createInternationalsRow();
newCustomer.performCustomerFeature();
newDomestic.performCustomerFeature();
newInternational.performCustomerFeature();

各行は期待したとおりに関連するエンティティ行のサブタイプに固有の方法でメソッドを処理し、結果を生成します。

## performCustomerFeature as Customer
## performCustomerFeature as Domestic
## performCustomerFeature as International

7.3 多相ビュー行関連の作業

「多相エンティティ・オブジェクトの慣用名での作業」で示されている例では、「舞台裏」であるエンティティ・オブジェクト・レベルでポリモフィズムが発生していました。クライアント・コードは同じCustomerListRowインタフェースを使用してすべてのビュー行を処理するので、Domesticsエンティティ・オブジェクトに基づく行と、Customersエンティティ・オブジェクトに基づく行を区別することはできません。コードは、基礎となるエンティティ・サブタイプのすべての型に共通するビュー行属性とメソッドの同じセットを使用して、すべてのビュー行を処理します。

多相ビュー行をサポートするようにビュー・オブジェクトを構成すると、クライアントは、行の型に固有のビュー行インタフェースを使用して、異なる型のビュー行を処理できます。このようにすると、クライアントは、必要に応じて、特定のサブタイプに固有のビュー属性にアクセスしたり、ビュー行メソッドを呼び出したりできます。図7-11は、前述のCustomerListの例に対してこの機能を有効にするビュー・オブジェクトの階層を示しています。DomesticListとInternationalListは、ベース(または親)のCustomerListビュー・オブジェクトを拡張した子ビュー・オブジェクトです。それぞれが、エンティティ・オブジェクトの慣用名として保持する、Customersのそのサブタイプに固有の追加属性を含んでいることに注意してください。DomesticListにはState追加属性が含まれ、InternationalListにはState属性はないものの、Language属性が含まれています。ビュー行ポリモフィズム用に構成されている場合、クライアントは次のものを使用してCustomerListビュー・オブジェクトの結果を処理できます。

- 顧客に関係するビュー行のCustomerListRowインタフェース

- 国内顧客に関係するビュー行のDomesticListRowインタフェース

- 国際顧客に関係するビュー行のInternationalListRowインタフェース

これにより、クライアントは、特定のサブタイプのビュー行に固有の追加属性とビュー行メソッドにアクセスできます。

図7-11 ビュー行ポリモーフィズムを有効にするビュー・オブジェクト・サブタイプの階層

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.polymorphicvoパッケージを参照します。

7.3.1 多相ビュー行を持つビュー・オブジェクトの作成方法

多相ビュー行によって作成するビュー・オブジェクトは、それぞれに固有のベース・エンティティ・オブジェクトを持つビュー・オブジェクトの階層から、1つ以上の属性を継承できます。拡張されたビュー・オブジェクトから選択する属性は、親ビュー・オブジェクトの多相ビュー行定義によってオーバーライドされます。

多相ビュー行を持つビュー・オブジェクトを作成するには:

1. Application Navigatorで、継承階層にある、ベース・ビュー・オブジェクトにするビュー・オブジェクトをダブルクリックします。
たとえば、CustomerListビュー・オブジェクトは、DomesticListビュー・オブジェクトのベースです。

2. ビュー・オブジェクトの概要エディタで「属性」ナビゲーション・タブをクリックし、ビュー行の、使用するビュー行インタフェースを区別する識別子属性を選択して、「選択した属性の編集」ボタンをクリックします。
たとえば、CustomerTypeCodeは、CustomerListの識別子属性です。

3. 「属性の編集」ダイアログで、Discriminatorチェック・ボックスを選択して、「デフォルト値」を入力し、「OK」をクリックします。
ベース・ビュー・オブジェクトのビュー行インタフェースが使用するものと予想される属性値に一致する値を、「デフォルト値」フィールドで指定する必要があります。たとえば、CustomerListビュー・オブジェクトでは、CustomerTypeCode属性を識別子属性としてマークし、デフォルト値をCUSTOMERにします。

4. ビュー・オブジェクトの概要エディタの「属性」ページで、サブタイプ・ビュー・オブジェクトに固有のすべての属性を削除します。
たとえば、属性Statesは、DomesticListサブタイプ・ビュー・オブジェクトのみによって使用されるため、ベース・ビュー・オブジェクトから削除されます。

5. 概要エディタで「Java」ナビゲーション・タブをクリックして、ベース・ビュー・オブジェクトのカスタム・ビュー行クラスを有効にし、少なくとも1つのメソッドをクライアント行インタフェースで公開します。このメソッドとしては、ビュー行属性アクセッサ・メソッドの1つまたは全部、および任意のカスタム・ビュー行メソッドを使用できます。

6. ベース・ビュー・オブジェクトを拡張する新しいサブタイプ・ビュー・オブジェクトを作成します。

a. Application Navigatorでベース・ビュー・オブジェクトを右クリックして新規拡張オブジェクトを選択し、拡張オブジェクトの作成ダイアログで、サブタイプ・ビュー・オブジェクトを指名します。
この例では、CustomerListビュー・オブジェクトがベースで、サブタイプ・ビュー・オブジェクトは指定されたDomesticListです。

b. サブタイプ・ビュー・オブジェクトの概要エディタで「属性」ナビゲーション・タブをクリックして、「追加」ボタンのドロップダウンから「エンティティからの属性の追加」を選択し、「属性」ダイアログで、サブタイプ・ビュー・オブジェクトに固有の属性を追加して、「OK」をクリックします。
この例では、サブタイプDomesticListが追加の属性Stateを定義します。

c. 概要エディタの「属性」ページでビュー行の識別子属性を選択し、「オーバーライド」をクリックして、「選択した属性の編集」ボタンをクリックします。

d. 「属性の編集」ダイアログで、識別子属性に別個のデフォルト値を指定して拡張ビュー・オブジェクトのサブタイプを定義し、「OK」をクリックします。
たとえば、DomesticListビュー・オブジェクトは、CustomerTypeCode識別子属性にDOMESTICという値を設定しています。

e. 概要エディタで「Java」ナビゲーション・タブをクリックして、拡張ビュー・オブジェクトのカスタム・ビュー行クラスを有効にします。
妥当な場合は、新しいカスタム・ビュー行メソッドを追加するか、または親ビュー・オブジェクトの行クラスから継承するカスタム・ビュー行メソッドをオーバーライドします。

f. 必要に応じて繰り返し、他の拡張されたビュー・オブジェクトを追加します。
たとえば、InternationalListは、CustomerListを拡張する2番目のビュー・オブジェクトです。このオブジェクトでは、CustomerTypeCode識別子属性に値INTERNATIONALを設定しています。

ビュー・オブジェクトの階層を設定した後、「サブタイプ・オブジェクトの慣用名を表示するためのアプリケーション・モジュールの更新」の説明に従い、ビュー行ポリモフィズムに参加するビュー・オブジェクト・サブタイプのリストを定義する必要があります。たとえば、ビュー・インスタンスCustomerList1を持つCustomersModuleアプリケーション・モジュールは、DomesticListおよびInternationalListの各サブタイプ・ビュー・オブジェクトを指定するように構成する必要があります。

7.3.2 多相ビュー行を持つビュー・オブジェクトを作成する場合の処理

多相ビュー行定義を持つ子ビュー・オブジェクトを定義するために使用するベース・ビュー・オブジェクトを作成する場合、JDeveloperはベース・ビュー・オブジェクトのXMLドキュメントに、識別子属性に関する情報を追加します。たとえば、CustomerListビュー・オブジェクトを作成すると、XMLプロパティDiscrColumnは、CountryTypeCodeを、ベース・ビュー・オブジェクトの多相識別子属性として識別し、次のようにサブタイプ値をCUSTOMERとします。

<ViewObject
Name="CustomerList" ... >
<EntityUsage
Name="Customers"
Entity="oracle.summit.model.polymorphics.entities.Customers" >
</EntityUsage>
...
<ViewAttribute
Name="CountryTypeCode"
PrecisionRule="true"
EntityAttrName="CountryTypeCode"
EntityUsage="Customers"
AliasName="COUNTRY_TYPE_CODE"
DiscrColumn="true"
DefaultValue="CUSTOMER">
</ViewAttribute>
...
</ViewObject>

続いて、多相ビュー行定義を持つ子ビュー・オブジェクトを作成する場合、JDeveloperは、子ビュー・オブジェクトのXMLドキュメントに、ビュー行定義に関する情報を追加します。たとえば、次の例は、ベース・ビュー・オブジェクトの名前がExtendsプロパティ内に記録されたDomesticList子ビュー・オブジェクトを示しています。XMLプロパティDiscrColumnは、オーバーライドされたCountryTypeCode属性を、DOMESTICのサブタイプ値を持つ多相識別子属性として識別します。サブタイプに固有の追加の属性Stateのみが、子ビュー・オブジェクトのXMLドキュメントに表示されます。

<ViewObject
Name="DomesticList"
Extends="oracle.summit.model.polymorphic.views.CustomerList"
...>
<ViewAttribute
Name="CountryTypeCode"
PrecisionRule="true"
DiscrColumn="true"
EntityAttrName="CountryTypeCode"
EntityUsage="Customers"
AliasName="COUNTRY_TYPE_CODE"
DefaultValue="DOMESTIC">
<DesignTime>
<Attr Name="_OverrideAttr" Value="true"/>
</DesignTime>
</ViewAttribute>
<ViewAttribute
Name="State"
PrecisionRule="true"
EntityAttrName="State"
EntityUsage="Customers"
AliasName="STATE"/>
</ViewObject>

同様に、次に示すように、InternationalList子ビュー・オブジェクトのXMLドキュメントでは、同じベース・ビュー・オブジェクトの名前がそのXMLドキュメントのExtendsプロパティ内に指定されていますが、INTERNATIONALというサブタイプ値を持つ多相識別子属性と、そのサブタイプに固有の追加属性Languageが定義されています。

<ViewObject
Name="InternationalList"
Extends="oracle.summit.model.polymorphic.views.CustomerList"
... >
<ViewAttribute
Name="CountryTypeCode"
PrecisionRule="true"
DiscrColumn="true"
EntityAttrName="CountryTypeCode"
EntityUsage="Customers"
AliasName="COUNTRY_TYPE_CODE"
DefaultValue="INTERNATIONAL">
<DesignTime>
<Attr Name="_OverrideAttr" Value="true"/>
</DesignTime>
</ViewAttribute>
<ViewAttribute
Name="Language"
PrecisionRule="true"
EntityAttrName="Language"
EntityUsage="Customers"
AliasName="LANGUAGE"/>
</ViewObject>

「多相エンティティ慣用名によりサブタイプ・ビュー・オブジェクトを作成すると行われる処理」で説明した多相エンティティ慣用名の例とは異なり、多相ビュー行を持つビュー・インスタンスは継承およびオーバーライド属性を使用して、たとえば、Domesticsエンティティ・オブジェクトをベースとする行と、Customersエンティティ・オブジェクトをベースとする行とを区別します。このように、許可されたサブタイプ・エンティティ・オブジェクトの定義は、多相ビュー行の場合、ビュー・オブジェクトのXMLドキュメントには存在しません(多相エンティティ・オブジェクトの慣用名の場合は、<AttrArray>タグで定義されます)。

7.3.3 多相ビュー行に関する必知事項

多相ビュー行を操作する場合は、行の型を扱って、表示する属性をカスタマイズするか、ビュー行のエンティティ・サブタイプに固有のメソッドに委譲を行うことができます。

7.3.3.1 拡張されたビュー・オブジェクトでのサブタイプ固有の属性の選択

拡張されたビュー・オブジェクトを作成すると、そのオブジェクトは親のエンティティ・オブジェクトの慣用名を継承します。親のビュー・オブジェクトのエンティティ・オブジェクトの慣用名がドメイン・レイヤーのサブタイプを持つエンティティ・オブジェクトに基づいている場合は、継承した親のエンティティ・オブジェクトの慣用名型ではなく、これらのサブタイプのいずれかを拡張されたビュー・オブジェクトが使用するようにする場合があります。このようにするには2つの理由があります。

- エンティティ・サブタイプに固有の属性を選択するため

- エンティティ・サブタイプに固有のメソッドに委譲するビュー行メソッドを作成できるようにするため

これを行うには、継承されたエンティティ・オブジェクトの慣用名をオーバーライドして、目的のエンティティ・サブタイプを参照する必要があります。そのためには、拡張されたビュー・オブジェクトの概要エディタで次の手順を行います。

ビュー・オブジェクトのエンティティ・オブジェクト慣用名をオーバーライドするには:

1. 「アプリケーション」ウィンドウで、オーバーライドするエンティティ・オブジェクトの慣用名を含むビュー・オブジェクトをダブルクリックします。

2. 概要エディタで「エンティティ・オブジェクト」ナビゲーション・タブをクリックして、拡張されたエンティティ・オブジェクトの慣用名を使用していることを確認します。

たとえば、DomesticListビュー・オブジェクトを拡張するDomesticListビュー・オブジェクトを作成するときは、最初、「選択済」リストに、TheCustomerという別名を使用するエンティティ・オブジェクトの慣用名が「TheCustomer(Customers): 拡張済」のように表示されます。エンティティ・オブジェクトの慣用名の型はカッコ内で示され、「拡張済」というラベルはエンティティ・オブジェクトの慣用名が現在は親から継承されていることを示します。

3. 「使用可能」リストで、継承されたものをオーバーライドする目的のエンティティ・サブタイプを選択します。既存のエンティティ・オブジェクトの慣用名型のサブタイプ・エンティティである必要があります。

たとえば、Customersエンティティ型に基づいて継承されたエンティティ・オブジェクトの慣用名をオーバーライドするには、「使用可能」リストでDomesticsエンティティ・オブジェクトを選択します。

4. 「>」をクリックして、「選択済」リストに移動します。

5. 表示される警告に応答し、既存の継承されたエンティティ・オブジェクトの慣用名をオーバーライドすることを確認します。

この手順を実行すると、「選択済」リストが更新されて、オーバーライドされたエンティティ・オブジェクトの慣用名を反映するようになります。たとえば、DomesticListビュー・オブジェクトの場合は、Customersベースのエンティティ・オブジェクトの慣用名をDomesticsエンティティ・サブタイプでオーバーライドすると、表示が「TheCustomer (Domestics): オーバーライド済」に更新されます。

エンティティ・オブジェクトの慣用名をエンティティ・サブタイプに関係するようにオーバーライドした後は、エディタの「属性」タブを使用して、そのサブタイプに固有の追加属性を選択できます。たとえば、DomesticsListビュー・オブジェクトには、Domesticsエンティティ・オブジェクトに固有の、Stateという名前の追加属性が含まれます。

7.3.3.2 エンティティ・オブジェクトの慣用名をオーバーライドした後のサブタイプ固有のメソッドへの委譲

拡張されたビュー・オブジェクトのエンティティ・オブジェクトの慣用名をサブタイプ・エンティティを参照するようにオーバーライドした後は、サブタイプ・エンティティ・クラスに固有のメソッドに委譲するビュー行メソッドを作成できます。

次の例は、InternationalListビュー・オブジェクトに対するカスタム・ビュー行クラスのperformInternationalFeature()メソッドのコードを示しています。getTheCustomer()エンティティ行アクセッサからの戻り値をサブタイプInternationalsImplにキャストした後、Internationalsエンティティ・オブジェクトに固有のperformInternationalFeature()メソッドをコールしています。

// In InternationalListRowImpl.java
public void performInternationalFeature() {
InternationalsImpl international = (InternationalsImpl)getTheCustomer();
international.performInternationalFeature();
}

注意:

JDeveloperでは、InternationalListRowImplのようなサブクラスがgetTheCustomer()のようなメソッドをオーバーライドしてその戻り型を変更できるようにする共変戻り型と呼ばれるJDKの機能がまだ採用されていないため、ここではエンティティ・サブタイプに明示的にキャストする必要があります。

7.3.3.3 クライアント・コードでの異なるビュー行インタフェース型の使用

次の例、次の手順を実行するTestViewRowPolymorphismクラスのコード行を示しています。

1. CustomerListビュー・オブジェクトの行を反復処理します。
ループでは、各行について、Javaのinstanceof演算子を使用して、現在の行がDomesticListRowまたはInternationalListRowのインスタンスかどうかを検査しています。

2. 行がDomesticListRowの場合は、行をこのさらに具体的な型にキャストした後、次の処理を行います。

- DomesticListRowインタフェースに固有のperformDomesticFeature()メソッドをコールします。

- DomesticListビュー・オブジェクトに固有のState属性の値にアクセスします。

3. 行がInternationalListRowの場合は、行をこのさらに具体的な型にキャストした後、次の処理を行います。

- InternationalListRowインタフェースに固有のperformInternationalFeature()メソッドをコールします。

- InternationalListビュー・オブジェクトに固有のLanguage属性の値にアクセスします。

4. それ以外の場合は、CustomerListRowでメソッドをコールします。

// In TestViewRowPolymorphism.java
ViewObject vo = am.findViewObject("CustomerList");
vo.executeQuery();
// 1. Iterate over the rows in the CustomerList view object
while (vo.hasNext()) {
CustomerListRow Customer = (CustomerListRow)vo.next();
System.out.print(Customer.getEmail()+"->");
if (Customer instanceof DomesticListRow) {
// 2. If the row is a DomesticListRow, cast it
DomesticListRow mgr = (DomesticListRow)Customer;
mgr.performDomesticFeature();
System.out.println("State: "+domestic.getState());
}
else if (Customer instanceof InternationalListRow) {
// 3. If the row is an InternationalListRow, cast it
InternationalListRow international = (InternationalListRow)Customer;
international.performInternationalFeature();
System.out.println("Speaks English: "+international.getLanguage());
}
else {
// 4. Otherwise, just call a method on the CustomerListRow
Customer.performCustomerFeature();
}
}

前述の例のコードを実行すると、次のような出力が生成されます。

daustin->## performInternationalFeature called
English spoken: Yes
hbaer->## performCustomerFeature as Customer
:
sking->## performDomesticFeature called
State: CA
:

これは、ビュー行ポリモーフィズムの機能を使用することで、クライアントが異なる型のビュー行を区別し、ビュー行の各サブタイプに固有のメソッドと属性にアクセスできたことを示します。

7.4 識別子属性に関する必知事項

ビュー・オブジェクトが、識別子属性を持つエンティティ・オブジェクトを参照する場合に、その識別子属性を(主キー属性に加えて)問合せに含めるには、ビュー・オブジェクトの概要エディタの「属性」ページの「詳細」タブで、継承した識別子属性に対応する「多相識別子」チェック・ボックスを選択します。

チェック・ボックスを有効化する場合、「詳細」タブの「多相識別子」オプションを使用して、ビュー・オブジェクトがサブタイプ・ビュー・オブジェクトとして定義されるかどうかを構成できます。

- オプション「View」を有効化すると、多相ビュー行は有効化されます。

- オプション「エンティティ」を有効化すると、ビュー行の識別子機能が無視され、そのかわりに属性がデフォルト値でインスタンス化されます。
「エンティティ」オプションは、識別子属性が、複数のバッキング・エンティティ・オブジェクトを持つエンティティ・ベースのビュー・オブジェクトによって継承されているが、多相ビュー行では都合が悪い状況で役立ちます。

図7-12は、DomesticListビュー・オブジェクトの「詳細」タブで、その、Customersエンティティ・オブジェクトから継承したCustomerTypeCode識別子属性が有効化されていることを示しています。「View」を選択するとは、この識別子属性がビュー・オブジェクト・ポリモフィズムに参加し、値DOMESTICがサブタイプ・ビュー・オブジェクトの行タイプを決定することを意味します。

図7-12 識別子属性選択によるビュー行ポリモフィズムの有効化

7.5 サブタイプ・オブジェクトの慣用名を表示するためのアプリケーション・モジュールの更新

ビュー行ポリモフィズムまたはエンティティ・オブジェクト・ポリモフィズムを使用してビュー・オブジェクト階層を作成した後で、実行時にビュー・オブジェクト・ポリモフィズムに参加するビュー・オブジェクト・サブタイプのリストを定義する必要があります。これを達成するには、ベース・ビュー・インスタンスのサブタイプ・ビュー・オブジェクトを指定してアプリケーション・モジュール定義を更新します。実行時に、ADFは、起動されたビュー・インスタンスの名前付きサブタイプの定義に基づいて多相ビュー行を作成します。

7.5.1 データ・モデル上でのサブタイプ・オブジェクトの慣用名の公開方法

ビュー行ポリモフィズムまたはエンティティ・オブジェクト・ポリモフィズムを使用してビュー・オブジェクト階層を作成した後で、ビュー・オブジェクト・ポリモフィズムに参加するビュー・オブジェクト・サブタイプのリストを定義する必要があります。これを達成するには、ベース・ビュー・インスタンスのサブタイプ・ビュー・オブジェクトを指定してアプリケーション・モジュール定義を更新します。

図7-13に示すように、ベース・ビュー・オブジェクトの慣用名CustomerList1を公開するデータ・モデルは変わりませんが、「サブタイプの選択」ダイアログを使用して、ベース・ビュー・オブジェクトの、可能性のある多相ビュー・オブジェクトの慣用名が定義されます。

Figure 7-13 サブタイプ・ビュー・オブジェクトによるアプリケーション・モジュール定義の更新

始める前に:

多相ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「多相ビュー行関連の作業」を参照してください。

ビュー・オブジェクトがエンティティ・サブタイプの継承から導出する多相エンティティ・オブジェクトの慣用名に基づいてサブタイプ・ビュー・オブジェクトを作成する場合は、ベースのエンティティ・ベース・ビュー・オブジェクトを拡張するサブタイプ・ビュー・オブジェクトを作成します。詳細は、「多相エンティティ・オブジェクトの慣用名での作業」を参照してください。

定義するビュー・オブジェクト階層から導出された多相ビュー行に基づいてサブタイプ・ビュー・オブジェクトを作成する場合は、多相識別子属性を持つサブタイプ・ビュー・オブジェクトを作成します。詳細は、「多相ビュー行関連の作業」を参照してください。

アプリケーション・モジュール定義にサブタイプ・ビュー・オブジェクトを追加する手順:

1. アプリケーション・モジュールの概要エディタで「データ・モデル」ナビゲーション・タブをクリックし、アプリケーション・モジュールのデータ・モデルに、ベース・ビュー・オブジェクトのインスタンスを追加します。

たとえば、CustomerListビュー・オブジェクトが2つのサブタイプ、DomesticListおよびInternationalListビュー・オブジェクトをサポートする場合、AppModuleアプリケーション・モジュールは、ベース・ビュー・インスタンスCustomerList1を持ちます。

2. 「データ・モデル」ページで、「ビュー・オブジェクト・インスタンス」セクションを展開し、「データ・モデル」リストで、「サブタイプ」ボタンをクリックします。

ボタンをクリックするために、「データ・モデル」リストでビュー・インスタンスを選択する必要はありません。

3. 「サブタイプ」ダイアログで、目的に応じてベース・ビュー・インスタンスのビュー・オブジェクト・サブタイプを「使用可能」から「選択済」リストに移動し(またはその逆)、「OK」をクリックします。

たとえば、サブタイプ・ビュー・オブジェクトDomesticListおよびInternationalListを持つCustomerList1ビュー・インスタンスの場合、図7-13に示すように、両方のビュー・オブジェクトを「選択済」リストに移動します。

7.5.2 サブタイプ・ビュー・オブジェクトをアプリケーション・モジュールに追加した場合に行われる処理

アプリケーション・モジュールにサブタイプ・ビュー・オブジェクトを追加すると、JDeveloperは、許可されているビュー・サブタイプに関する情報をアプリケーション・モジュールのXMLドキュメントに追加します。たとえば、2つの可能なサブタイプ・オブジェクトの慣用名を持つビュー・インスタンスCustomerList1を定義する場合、許可されているサブタイプ・ビュー・オブジェクトの名前が、次のように<AttrArray>タグに記録されます。

<AppModule
...
<ViewUsage
Name="CustomerList1"
ViewObjectName="oracle.summit.model.polymorphicsample.CustomerList"/>
<AttrArray Name="ViewImports">
<Item Value="oracle.summit.model.polymorphicsample.DomesticList"/>
<Item Value="oracle.summit.model.polymorphicsample.InternationalList"/>
</AttrArray>
</AppModule>

8 ビュー・インスタンスの問合せのテスト

この章では、JDeveloperで提供されるOracle ADFモデル・テスターを使用して、ADFビュー・オブジェクト問合せ結果を対話的にテストする方法について説明します。この章では、ADFビジネス・コンポーネントAPIを使用してJDeveloper外部のテスト・クライアントに含まれるビュー・オブジェクト・インスタンスにアクセスする方法についても説明します。

この章の内容は次のとおりです。

- ビュー・インスタンスの問合せについて

- ビュー・インスタンスをテストするためのアプリケーション・モジュールの作成

- Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト

- ビュー・オブジェクト・インスタンスのプログラムによるテスト

8.1 ビュー・インスタンスの問合せについて

JDeveloperには、アプリケーション・ユーザー・インタフェースを使用せず、またはテスト・クライアントのプログラムを記述せずに、データ・モデルのすべての面をテストできるようにする、対話型アプリケーション・モジュール・テスト・ツールが用意されています。多くの場合、Oracle ADFモデル・テスターを実行すると、開発時にビジネス・サービスのデータ機能を最も迅速に実行できます。

注意:

アプリケーション・モジュールをプログラムによってテストする場合は、テスト・クライアントを記述できます。詳細は、「コマンド行Javaテスト・クライアントの作成方法」を参照してください。

8.1.1 ビュー・インスタンスのユースケースと例

Oracle ADFモデル・テスターを使用すると、独自のカスタム・ユーザー・インタフェースを作成する前に、エンド・ユーザーとアプリケーション・モジュールのデータ・モデルとの対話をシミュレートできます。UIページを作成した後も、Oracle ADFモデル・テスターは問題発生時の診断に役立ちます。Oracle ADFモデル・テスターで問題を再現して、問題がアプリケーションのビュー・レイヤーまたはコントローラ・レイヤーにあるのか、あるいはビジネス・サービス・レイヤーのアプリケーション・モジュール自体にあるのかを確認できます。

8.1.2 ビュー・インスタンスのテストの追加機能

ビュー・インスタンスで作業を開始する前に、その他のOracle ADF機能を理解しておくと役に立つ場合があります。次に、関連する他の機能へのリンクを示します。

- Oracle ADFモデル・テスターを実行する場合のデバッグ・ツールの使用方法の詳細は、「テストとデバッグのためのOracle ADFモデル・テスターの使用」を参照してください。

- ビュー・オブジェクト・インスタンスで構成されるデータ・モデルを作成する方法の詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

- ADFビジネス・コンポーネントのカスタム・クラスでよく記述、使用またはオーバーライドするコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

8.2 ビュー・インスタンスをテストするためのアプリケーション・モジュールの作成

データ・モデル・プロジェクトで作成したビュー・オブジェクトをテストするには、テスト対象のビュー・オブジェクトのインスタンスを定義するアプリケーション・モジュールを作成する必要があります。アプリケーション・モジュールは、Oracle ADFモデル・テスター(またはUIクライアント)がアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールで使用される一連のビュー・オブジェクトは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。

アプリケーション・モジュールに追加したビュー・オブジェクトをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。Oracle ADFモデル・テスターの使用方法の詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

8.2.1 個別のビュー・オブジェクト・インスタンスを使用したアプリケーション・モジュールの作成方法

個別のビュー・オブジェクトのインスタンスを定義するアプリケーション・モジュールを作成するには、「新規ギャラリ」から使用できる「アプリケーション・モジュールの作成」ウィザードを使用します。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「ビュー・インスタンスをテストするためのアプリケーション・モジュールの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・インスタンスのテストの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

個別のビュー・オブジェクト・インスタンスをテストするためのアプリケーション・モジュールを作成するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを作成するプロジェクトを右クリックし、「新規」、「アプリケーション・モジュール」の順に選択します。

2. 「アプリケーション・モジュールの作成」ウィザードの「名前」ページで、パッケージ名およびアプリケーション・モジュール名を指定します。「次へ」をクリックします。

3. 「データ・モデル」ページで、以前に定義したビュー・オブジェクトのインスタンスを指定し、このビュー・オブジェクト・インスタンスの名前をクライアントで認識される名前とまったく同じ名前に編集します。次に、「終了」をクリックします。

「データ・モデル」ページに表示されるデフォルトのインスタンス名を受け入れるかわりに、インスタンス名をわかりやすい名前に変更できます(たとえば、デフォルト名OrderItems1のかわりに、AllOrderItemsに名前を変更できます)。

8.2.2 マスター/ディテール・ビュー・オブジェクト・インスタンスを使用したアプリケーション・モジュールの作成方法

「アプリケーション・モジュールの作成」ウィザードを使用して、ビュー・オブジェクトが表すマスター/ディテール関係に基づいてアプリケーション・モジュールのビュー・オブジェクトの階層を作成することもできます。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「ビュー・インスタンスをテストするためのアプリケーション・モジュールの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・インスタンスのテストの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「マスター/ディテール階層における複数表の使用」の説明に従って、ビュー・オブジェクト間の階層関係を作成します。

ビュー・オブジェクト関連に基づいてアプリケーション・モジュールを作成するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを作成するプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「アプリケーション・モジュール」を選択し、「OK」をクリックします。

3. 「アプリケーション・モジュールの作成」ウィザードで、「データ・モデル」ノードを選択します。

4. 「使用可能なビュー・オブジェクト」リストで、アクティブに調整するマスターとするビュー・オブジェクトのインスタンスを選択します。

リスト内のマスター・ビュー・オブジェクトには、このビュー・オブジェクトにビュー・リンクがあることを示すプラス記号が表示されます。ビュー・リンクは、マスター/ディテール階層の定義に必要です。

たとえば、図8-1は、選択したPersonsVOと、「新規ビュー・インスタンス」フィールドで名前を変更したAuthenticatedUserを示しています。

図8-1 選択したマスター・ビュー・オブジェクト

5. 選択したマスター・ビュー・オブジェクトを「データ・モデル」リストに移動します。

たとえば、図8-2は、「データ・モデル」リストに追加した後の新規作成したマスター・ビュー・インスタンスAuthenticatedUserを示しています。

図8-2 作成したマスター・ビュー・インスタンス

6. 「データ・モデル」リストで、新規作成したマスター・ビュー・インスタンスを選択してハイライトしておきます。これは、追加するディテール・ビュー・インスタンスのターゲットになります。次に、「使用可能なビュー・オブジェクト」リストで、マスター・ビュー・オブジェクトの下のディテール・ビュー・オブジェクトを特定して選択します。

たとえば、図8-3は、マスター・ビュー・オブジェクトPersonsVOの下にある、OrdersVO via PersonsToOrdersという名前のディテール・ビュー・オブジェクトOrdersVOを示しています。この名前はビュー・リンクPersonsToOrdersを表し、PersonsVOとOrdersVO間のマスター/ディテール階層を定義します。ディテール・ビュー・インスタンスの名前はMyOrdersに変更されます。

図8-3 選択したディテール・ビュー・オブジェクト

7. 追加したマスター・インスタンスにディテール・インスタンスを追加するには、「データ・モデル」リストで選択したマスター・ビュー・インスタンスの下に、ディテール・ビュー・オブジェクトを移動します。

図8-4は、データ・モデルにAuthenticatedUserのディテールとして新規作成したディテール・ビュー・インスタンスMyOrdersを示しています。

図8-4 作成したマスター・ビュー・インスタンス

8. 別の階層レベルを追加するには、新しく追加したディテール・インスタンスを「データ・モデル」リストで選択してから、新しいディテール・インスタンスを移動します。このディテール・インスタンスは、前に追加したディテール・インスタンスとマスター/ディテール関係を持ちます。

データ・モデルには、ビュー・オブジェクト関係でサポートされているだけの数の階層レベルを含めることができます。たとえば、図8-5には、「データ・モデル」リストに、インスタンスAuthenticatedUser (PersonsVOから名前を変更)がMyOrders (OrdersVO via PersonsToOrdersから名前を変更)のマスターとして、またこれがMyOrderItems (OrderItemsVO via OrdersToOrderItemsから名前を変更)のマスターとして表示されています。ディテール・ビュー・オブジェクトのMyOrderItemsは、別のビュー・オブジェクトのマスターではないため、階層の最後のレベルになります。

図8-5 作成したマスター/ディテール/ディテール階層

8.3 Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト

Oracle ADFモデル・テスターを使用すると、独自のカスタム・ユーザー・インタフェースを作成する前に、エンド・ユーザーとアプリケーション・モジュールのデータ・モデルとの対話をシミュレートできます。UIページを作成した後も、Oracle ADFモデル・テスターは問題発生時の診断に役立ちます。Oracle ADFモデル・テスターで問題を再現して、問題がアプリケーションのビューまたはコントローラ・レイヤーにあるのか、あるいはビジネス・サービス・レイヤーのアプリケーション・モジュール自体にあるのかを確認できます。

8.3.1 Oracle ADFモデル・テスターの実行方法

アプリケーション・モジュールに追加したビュー・オブジェクトをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。「アプリケーション」ウィンドウからテスターを実行すると、デフォルトのアプリケーション・モジュール構成を使用してデータベースへの接続が行われます。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

テスターを実行する場合のデバッグ・ツールの使用方法を理解しておくと役に立つ場合があります。詳細は、「テストとデバッグのためのOracle ADFモデル・テスターの使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・インスタンスのテストの追加機能」を参照してください。

アプリケーション・モジュール構成を使用してビュー・オブジェクトをテストするには:

1. 「アプリケーション」ウィンドウで、実行するアプリケーション・モジュールを右クリックし、「実行」を選択します。

または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は、「デバッグ」を選択します。JDeveloperにより、「ログ」ウィンドウのデバッガ・プロセス・パネルおよび各種デバッガ・ウィンドウが開きます。たとえば、Oracle ADFモデル・テスターを使用してデバッグする場合、ステータス・メッセージと例外を表示し、ソース・コードをステップ・インおよびステップ・アウトし、ブレークポイントを管理できます。

ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを受信する方法の詳細は、「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。

2. Oracle ADFモデル・テスターでビュー・オブジェクトを実行するには、データ・モデル・ツリーを開き、目的のビュー・オブジェクト・ノードをダブルクリックします。

ビュー・オブジェクト・インスタンスはすでにテスト・セッションで実行されているように表示される場合があります。この場合、Oracle ADFモデル・テスターの右側のデータ・ビュー・ページには、すでにビュー・オブジェクト・インスタンスの問合せ結果が表示されています。Oracle ADFモデル・テスターでは、読取り専用ビュー・オブジェクトのデータ・ビュー・ページのフィールドは常に無効として表示されます。これは、このビュー・オブジェクトで表されるデータが編集できないためです。たとえば、図8-6では、ビュー・インスタンスProductsのデータがテスターに表示されています。「製品ID」、「言語」、「カテゴリ」などのフィールドは、属性を編集できないため、無効として表示されます。

図8-6 Oracle ADFモデル・テスターでのデータ・モデルのテスト

3. データ・モデル・ツリー内のノードを右クリックして、そのノードのポップアップ・メニューを表示します。たとえば、ビュー・オブジェクト・ノードでは、データ・モデル・ツリーからのビュー・オブジェクトの削除、およびその他のタスクの実行のため、必要に応じて問合せを再実行できます。

4. タブのポップアップ・メニューを表示するには、図8-7で示すように、開いているデータ・ビューアのタブを右クリックします。たとえば、データ・ビューアを閉じたり、別のウィンドウで開くことができます。

図8-7 Oracle ADFモデル・テスターのデータ・ビューアのタブのポップアップ・メニュー

8.3.2 構成を使用したOracle ADFモデル・テスターの実行方法

アプリケーション・モジュールに追加したビュー・オブジェクトをテストするには、Oracle ADFモデル・テスターを使用し、特定の構成でテスターを実行します。選択する構成によって、テスターで使用されるデータベース接続が決まります。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

テスターを実行する場合のデバッグ・ツールの使用方法を理解しておくと役に立つ場合があります。詳細は、「テストとデバッグのためのOracle ADFモデル・テスターの使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・インスタンスのテストの追加機能」を参照してください。

特定のアプリケーション・モジュール構成を使用してビュー・オブジェクトをテストするには:

1. 「アプリケーション」ウィンドウで、実行するアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「構成」ナビゲーション・タブをクリックします。

3. 「構成」ページで、「デフォルト構成」ドロップダウン・リストから、Oracle ADFモデル・テスターの実行に使用するアプリケーション・モジュール構成を選択します。

デフォルトでは、アプリケーション・モジュールには、AppModuleNameLocalおよびAppModuleNameSharedという名前のデフォルトの構成のみがあります。たとえば、図8-8では、データベースへの接続にBackOfficeAppModuleShared構成が選択されています。

図8-8 アプリケーション・モジュールの概要エディタでの構成の選択

4. 選択した構成を右クリックして、「実行」を選択します。

または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は、「デバッグ」を選択します。JDeveloperにより、「ログ」ウィンドウのデバッガ・プロセス・パネルおよび各種デバッガ・ウィンドウが開きます。たとえば、Oracle ADFモデル・テスターを使用してデバッグする場合、ステータス・メッセージと例外を表示し、ソース・コードをステップ・インおよびステップ・アウトし、ブレークポイントを管理できます。

ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを受信する方法の詳細は、「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。

8.3.3 言語メッセージ・バンドルおよびUIヒントのテスト方法

アプリケーションにおいて、リソース・メッセージ・バンドル内に代替言語を定義する場合、これらの言語を認識するようにOracle ADFモデル・テスターを構成できます。Oracle ADFモデル・テスターで「ロケール」メニューを表示し、利用可能な言語の中から選択できます。

Oracle ADFモデル・テスターのデフォルト言語を指定するには:

1. メイン・メニューで、「ツール」、「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を開き、「テスター」を選択します。

3. Oracle ADFモデル・テスター・ページで、リソース・メッセージ・バンドルを作成したロケールを「選択済」リストに追加します。

または、特定のアプリケーション・モジュール構成に対してADFビジネス・コンポーネントのランタイム構成プロパティを設定することによっても、デフォルト言語を構成できます。これらのランタイム・プロパティにより、Oracle ADFモデル・テスターでデフォルトとして表示される言語も決定されます。ランタイム構成のプロパティを設定するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。アプリケーション・モジュール構成の概要エディタ(bc4j.xcfgファイル)で「プロパティ」タブを選択し、「プロパティの追加」をクリックして「プロパティの追加」ダイアログから次のプロパティを選択し、「OK」をクリックします。

- jbo.default.country

- jbo.default.language

次に、「プロパティ」リストで、国および言語の国コードを入力します。たとえば、イタリア語を指定するには、次の2つのプロパティに対してITおよびitと入力します。

- jbo.default.country = IT

- jbo.default.language = it

Oracle ADFモデル・テスターで言語メッセージ・バンドルをテストすることで、UIヒントの翻訳が正しく配置されているかどうかを検証できます。または、メッセージ・バンドルが特定の属性の日付書式を定義している場合は、ツールによって日付書式の変更(たとえば、04/12/2013から12/04/2013へ)を検証できます。

8.3.4 エンティティ・ベースのビュー・オブジェクトの対話的テスト方法

エンティティ・ベースのビュー・オブジェクトの対話的テストは、読取り専用ビュー・オブジェクトと同じ方法で行います。目的のビュー・オブジェクトのインスタンスをアプリケーション・モジュールのデータ・モデルに追加してから、Oracle ADFモデル・テスターを使用してこのアプリケーション・モジュールをテストします。

Oracle ADFモデル・テスターでは、アプリケーション・モジュールを簡単にテストおよびデバッグできるので、非常に便利です。表8-1に、エンティティ・ベースのビュー・オブジェクトを表示した場合にOracle ADFモデル・テスターのツールバー・ボタンで実行される操作の概要を示します。

表8-1 Oracle ADFモデル・テスターのツールバー・ボタン

ボタン

操作

用途

別の行に移動

Oracle ADFモデル・テスターで表示される現在の行を変更します。最初、前、次、または最後の行に移動します。

新規行を挿入

新規の行を作成して挿入します。

現在の行を削除

現在の行を削除します。

データベースへの変更を保存

ADFビジネス・コンポーネント・キャッシュに加えた変更をポストしてコミットします。

前回の保存以降の変更をすべて取消し

ADFビジネス・コンポーネント・キャッシュで加えた変更を破棄して元の値に戻し、データベースにポストされたすべての変更をロールバックします。

ビュー基準の指定

「ビュー基準」ダイアログが表示されます。ここでビュー基準を作成して、マスター・ビュー・オブジェクト・インスタンスに適用できます。

行の検証

すべてのエンティティ・オブジェクト・インスタンスに対して定義済の検証規則を適用し、現在の行を検証します。最低1つのフィールドが編集可能でないと、使用できません。

バインド変数の編集

「バインド変数」ダイアログが表示され、ビュー・オブジェクト問合せで使用されるバインド・パラメータの値を入力できます。問合せ文のビュー・オブジェクト問合せでバインド・パラメータが使用されていないと、使用できません。

アプリケーション・モジュールに追加したエンティティ・ベースのビュー・オブジェクトをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・インスタンスのテストの追加機能」を参照してください。

アプリケーション・モジュール構成を使用してエンティティ・ベースのビュー・オブジェクトをテストするには:

1. 「アプリケーション」ウィンドウで、テストするアプリケーション・モジュールを右クリックし、「実行」を選択します。

2. Oracle ADFモデル・テスターでデータ・モデル・ツリーを開き、目的のエンティティ・ベースのビュー・オブジェクト・ノードをダブルクリックします。

読取り専用ビュー・オブジェクトと異なり、データ・ビュー・ページに表示されるフィールドは、そのビュー・オブジェクトで表されるデータを編集できるため、有効として表示されます。

3. 個々の値を更新し、入力したデータの検証チェックを実行するには、編集可能なフィールドを使用します。

参照されるエンティティを持つビュー・インスタンスの場合は、外部キー値を変更して、参照部分の変更を確認できます。

4. 行の移動、作成、削除、現在の行の検証など、行レベルの操作を実行するには、ツールバー・ボタンを使用します。

エンド・ユーザーによるデータ・ビュー・ページ操作のシミュレーションの詳細は、「Oracle ADFモデル・テスターでのエンド・ユーザーによる対話のシミュレーション方法」を参照してください。

8.3.5 Oracle ADFモデル・テスターを更新してプロジェクトの変更を表示する方法

通常、データ・モデル・プロジェクトに対して行う変更は、Oracle ADFモデル・テスターを実行しても自動的に取得されません。ただし、表示されたデータ・モデルとデータ・モデル・プロジェクトの同期を取る必要があるときはいつでも、Oracle ADFモデル・テスターがデータ・モデル・プロジェクトからメタデータをリロードできます。このオプションを使用すると、Oracle ADFモデル・テスターを終了してプロジェクトを編集しOracle ADFモデル・テスターを再実行しなくても、最新の変更を表示できます。

「アプリケーションのリロード」オプションを使用すると、特にOracle ADFモデル・テスターとJDeveloperを繰り返し切り替えて作業する場合に時間を節約できます。たとえば、Oracle ADFモデル・テスターの実行中に、新しいビュー・インスタンスを使用してデータ・モデルを変更する必要が生じたり、ビュー・インスタンスにLOV属性定義が足りないことが判明することがあります。JDeveloperに戻り、ビジネス・コンポーネントの概要エディタを使用して変更操作を行い、データ・モデルのメタデータを変更します。その後、プロジェクトを再コンパイルした後(必須の手順)、Oracle ADFモデル・テスターに戻って、プロジェクトのクラス・パスから更新済のメタデータをリロードできます。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・インスタンスのテストの追加機能」を参照してください。

稼働中のOracle ADFモデル・テスターにデータ・モデルのメタデータを再ロードするには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを右クリックし、「実行」を選択します。

2. Oracle ADFモデル・テスターで、データ・モデルをテストして、必要な変更を判別します。Oracle ADFモデル・テスターは終了しないでください。

3. JDeveloperで、目的の変更を行い、データ・モデル・プロジェクトを再コンパイルします(たとえば、「アプリケーション」ウィンドウでデータ・モデル・プロジェクトを右クリックし、「メイク」を選択して再コンパイル手順を完了します。)

メタデータに対して行う変更とプロジェクトのコンパイルに関連性はありませんが、メタデータをクラス・パスにコピーし、Oracle ADFモデル・テスターでリロードできるようにするには、コンパイル手順を実行する必要があります。

4. ADFモデル・テスターに戻り、データ・モデル・ツリーの上にある「アプリケーション・メタデータのリロード」ボタンをクリックします。Oracle ADFモデル・テスターの開いているウィンドウがすべて閉じます。

また、Oracle ADFモデル・テスターの「ファイル」メニューから、「アプリケーションのリロード」を選択してもかまいません。

5. 目的のウィンドウを再度開き、行った変更を表示します。

8.3.6 Oracle ADFモデル・テスター使用時の処理

Oracle ADFモデル・テスターを起動すると、JDeveloperによってこのツールが別プロセスで開始され、Oracle ADFモデル・テスターが表示されます。ダイアログの左側のツリーには、アプリケーション・モジュールのデータ・モデルのすべてのビュー・オブジェクト・インスタンスが表示されます。目的のビュー・オブジェクト・インスタンスをダブルクリックすると、Oracle ADFモデル・テスターでデータ・ビュー・ページが表示され、問合せ結果をインスペクトできます。たとえば、図8-9は、展開されたツリーでビュー・インスタンスProductsをダブルクリックし、右側のデータ・ビュー・ページにこのビュー・インスタンスのデータが表示された様子を示しています。

データは編集できないため、表示する読取り専用のビュー・オブジェクトすべてに対して、データ・ビュー・ページは無効になっています。ただし、読取り専用のビュー・オブジェクトの場合でも、ツールはいくつかの有用な機能を備えています。

- 「ラベル・テキスト」ヒントに基づいたUIヒント、およびフォーマット・マスクが正しく定義されているかどうかを検証できます。

- ツールバー・ボタンを使用してデータのスクロールもできます。

- Query-By-Example基準を入力して、検査対象のデータのある特定の行を検索できます。ツールバーの「ビュー基準の指定」ボタンをクリックすると、「ビュー基準」ダイアログに使用可能なQuery-by-Example基準のリストが表示されます。
たとえば、図8-9に示すように、FindByProductNameCriteriaなどのビュー基準を選択し、ProductName属性にP%などの問合せ基準を入力して「検索」をクリックすると、検索対象を文字Pで始まる名前の製品のみに絞り込むことができます。

「エンティティ・ベースのビュー・オブジェクトの対話的テスト方法」で説明しているように、行の挿入、更新および削除をシミュレートできるエンティティ・ベースのビュー・オブジェクトを作成する場合は、Oracle ADFモデル・テスターをより便利に使用できます。

図8-9 組込みQuery-By-Example機能

8.3.7 Oracle ADFモデル・テスターでのエンド・ユーザーによる対話のシミュレーション方法

Oracle ADFモデル・テスターを起動すると、アプリケーション・モジュールのデータ・モデルで定義されているビュー・オブジェクト・インスタンスの階層が左側のツリーに表示されます。データ・モデルにマスター/ディテールのビュー・インスタンス関係が定義されている場合、ツリーには親ノードと子コードとして関係が表示されます。マスター/ディテールのビュー・インスタンス間のノードは、マスターで現在の行が変更されたときにマスター/ディテールをアクティブに調整するビュー・リンク・インスタンスを示します。たとえば、図8-10では、ツリーが開かれ、マスター・ビュー・インスタンスProductsとディテール・ビュー・インスタンスWarehouseStockLevelsのマスター/ディテール関係が示されています。選択されているノード、ProductsToWarehouseStockLevels1は、マスター/ディテール関係が定義されているビュー・リンク・インスタンスです。

図8-10 Oracle ADFモデル・テスターのアプリケーション・モジュールのデータ・モデル

ビュー・リンク・インスタンスをダブルクリックすると、マスター・オブジェクトが実行され、データ・ビュー・ページにマスター/ディテール・データが表示されます。たとえば、図8-11では、ツリーのProductsToWarehouseStockLevels1ビュー・リンク・インスタンスをダブルクリックすると、データ・ビュー・ページ上部のProductsマスター・ビュー・インスタンスと、データ・ビュー・ページ下部のWarehouseStockLevelsビュー・インスタンスが実行されます。ビュー・オブジェクト・ノード上に表示される追加ポップアップ・メニュー項目では、データ・モデル・パネルからのビュー・オブジェクトの削除、およびその他のタスクの実行のため、必要に応じて問合せを再実行できます。

マスター/ディテール・データ・ビュー・ページでは、問合せ結果をスクロールできます。また、エンティティ・ベースのビュー・オブジェクトのインスタンスは完全に編集可能なため、読取り専用ビュー・オブジェクトの読取り専用のデータを表示している無効な UIコントロールを表示するかわりに、データ・ビュー・ページには編集可能なフィールドが表示されます。作成、挿入、更新、検証、コミットおよびロールバックを自由に試すことができます。

図8-11 Oracle ADFモデル・テスターのマスター/ディテール・データ・ビュー・ページ

たとえば、複数のデータ・ビュー・ページを同時に開いて、マスター/ディティール階層の複数レベルを表示できます。「連結解除」ポップアップ・メニュー項目を使用して、任意のタブを別のウィンドウで開き、複数のビュー・オブジェクトのデータを同時に視覚化します。

マスター/ディテール・データ・ビュー・ページを使用して、アプリケーションの様々な機能領域をテストできます。

8.3.7.1 マスター/ディテール調整のテスト

Oracle ADFモデル・テスターのツールバーのナビゲーション・ボタンをクリックすると、現在のマスター・ビュー・オブジェクトの行が正しく調整されているかどうかを確認できます。たとえば、図8-11は、製品と倉庫のマスター/ディテール階層を示しています。マスター・パネルの次の行ボタンをクリックすると、(製品IDで識別された)次の製品がマスター・パネルに表示され、ディテール・パネルが更新されてこの製品を在庫として持つ倉庫と数量のリストが表示されます。

8.3.7.2 UIヒントのテスト

エンティティ・ベースのビュー・オブジェクトの属性は、基礎となるエンティティ・オブジェクト属性からUIヒントを継承します。データ・ビュー・ページに表示されるプロンプトを見ると、属性ごとにわかりやすいラベル・テキストUIヒントが正しく定義されているかどうかを確認できます。エンティティ・オブジェクトにヒントを設定する方法の詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

8.3.7.3 ビジネス・ドメイン・レイヤーの検証のテスト

定義した検証規則に応じて、無効な値を入力して検証例外のトリガーおよび検証を試行できます。たとえば、レンジ検証規則を定義した場合、レンジ外の値を入力し、次のようなエラーが表示されるのを確認します。

(oracle.jbo.AttrSetValException) Valid product codes are between 100 and 999

ツールバーで「ロールバック」ボタンをクリックし、データを以前の状態に戻してください。

8.3.7.4 エンティティ・オブジェクトの慣用名を参照するビュー・オブジェクトのテスト

データをスクロールするか、Oracle ADFモデル・テスターのツールバーにある「ビュー基準の指定」ボタンを使用して検索すると、エンティティ・ベースのビュー・オブジェクトの問合せのWHERE句を正しく変更し、外部結合を使用するようにしたかどうかを検証できます。想定どおりに行が表示されるはずです。

マスター・ビュー・オブジェクトの主キー属性の変更も試行できます。これにより、対応する参照情報が新しい主キー値を反映するように自動的に更新されているかどうかを検証できます。

ビュー・オブジェクト・レベルで定義したUIヒントによって、通常は基礎となるエンティティ・オブジェクトから継承されるUIヒントがオーバーライドされたかどうかは、Oracle ADFモデル・テスターを使用して検証します。複数の属性が同じラベル・テキストを共有していることに気付いた場合は、ビュー・オブジェクト・レベルで目的の属性に対するUIヒントを編集できます。たとえば、「ラベル・テキスト」ヒントを、RegisteredDate 属性は「Member Since」、ProvisionedFlag属性は「Provisioned?」に設定します。

8.3.7.5 行の作成およびデフォルト値の生成のテスト

エンティティ・ベースのビュー・オブジェクトを表示する際に、ビュー・オブジェクト・インスタンスに対してOracle ADFモデル・テスターのツールバーの行の作成ボタンをクリックすると、新しい空白の行が作成されます。宣言的なデフォルト値があるフィールドの場合、その値が空白行に表示されます。DBSequence値の属性を使用すると、新しい行に一時値が表示されます。すべての必須フィールドに入力した後、「コミット」ボタンをクリックしてトランザクションをコミットします。コミットが成功した後、トリガーによって割り当てられた実際の主キーがフィールドに表示されます。

8.3.7.6 新しいディテール行の外部キーが正しいかどうかのテスト

Oracle ADFモデル・テスターのツールバーの行の作成をクリックして、既存のディテール・エンティティ・ベースのビュー・オブジェクト・インスタンスに新しい行を追加しようとすると、ビュー・リンクによって、新しい行の外部キー属性値が現在のマスター・ビュー・インスタンス行の値に自動的に設定されることがわかります。

8.3.8 Oracle ADFモデル・テスターでのマルチ・ユーザー・シナリオのテスト方法

ビュー・オブジェクトとエンティティ・オブジェクトが実行時に連携する場合、マルチユーザー環境でアプリケーションを実行すると2つの例外が発生する可能性があります。これらの例外に備えて、Oracle ADFモデル・テスターを使用して、テスト目的のマルチ・ユーザー環境をシミュレートできます。たとえば、アプリケーションにビュー・オブジェクト問合せの編集フォームが表示される場合に、2人のユーザーがフォームで同じ属性を編集しようとすると、どのような動作が予想されるでしょうか。

予想される動作を理解するために、アプリケーション・モジュール上でOracle ADFモデル・テスターの2つのインスタンスを開き、同一のビュー・オブジェクト属性を編集する2人のユーザーをシミュレートします。2つのインスタンスを開いたまま、どのようにマルチユーザー例外が発生するかを表す次の2つのテストを実行します。

- Oracle ADFモデル・テスターの1つのインスタンスで、既存のビュー・オブジェクトの属性を変更し、このフィールドから次に進みます。次に、テスターのもう1つのインスタンスで、同じビュー・オブジェクトの属性をなんらかの形で変更してみます。2人目のユーザーには、oracle.jbo.AlreadyLockedExceptionが発生します。
ここで、Oracle ADFモデル・テスターの「接続」ダイアログの「プロパティ」ページで、jbo.locking.modeの値をpessimisticに変更し、テストを繰り返して試行します(デフォルト・モードはoptimisticに設定されています)。エラーが発生するのは、2人目のユーザーが変更をコミットした後ではなく、値を変更した直後であることがわかります。

- Oracle ADFモデル・テスターの1つのインスタンスで、既存のビュー・オブジェクトの属性を変更し、このフィールドから次に進みます。次に、テスターのもう1つのインスタンスで、同じビュー・オブジェクトの属性を変更せずに取得してみます。最初のウィンドウに戻り、変更をコミットします。2人目のユーザーが同じ属性を変更しようとすると、oracle.jbo.RowInconsistentExceptionが発生します。これは、2人目のユーザーが行をエンティティ・キャッシュに取得した後に、行が別のユーザーによって変更されてコミットされたためです。

8.3.9 テスターを実行する前の構成オプションのカスタマイズ方法

アプリケーション・モジュールの概要エディタを使用して、事前定義済の構成を選択し、実行時構成プロパティの名前付きセットを使用してツールを実行できます。概要エディタの「構成」ページでは、アプリケーション・モジュール構成(bc4j.xcfgファイルで定義)の概要エディタを開き、テスターを実行する前に構成のプロパティを指定することもできます。

アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。アプリケーション・モジュール構成の概要エディタで「プロパティ」タブを選択し、「プロパティの追加」をクリックして「プロパティの追加」ダイアログで目的のプロパティを選択し、「OK」をクリックします。

たとえば、構成を編集し「プロパティ」タブを選択して、次の2つのプロパティを追加して目的の国コード(この場合はイタリアを表すIT)を設定することにより、UIヒントのデフォルト言語を変更できます。

- jbo.default.country = IT

- jbo.default.language = it

8.3.10 ADFビジネス・コンポーネント・デバッグ診断を有効化する方法

oracle.jboログ出力に診断ロギングを構成している場合、Oracle ADFモデル・テスターを起動すると、JDeveloperによりADFビジネス・コンポーネントのデバッグ診断メッセージがJDeveloperの「ログ」ウィンドウにリダイレクトされます。図8-12に、ADFビジネス・コンポーネントのデバッグ診断が有効になるようにFINESTに設定されたoracle.jboログ出力を示します。

図8-12 ADFビジネス・コンポーネントのデバッグ用のログ出力の構成

oracle.jboログ出力は、統合WebLogic Serverでアプリケーションを実行する前、またはアプリケーションの実行中に構成できます。ロギングは、サーバーを再起動しなくても開始されます。診断メッセージのログ出力を得るためにアプリケーションをデバッグ・モードで実行する必要はありません。

oracle.jboのログ出力が構成された状態で、次にOracle ADFモデル・テスターを実行してビュー・オブジェクトをダブルクリックすると、次の例に示すように、「ログ」ウィンドウに詳細な診断出力が表示されます。oracle.jboログ出力にログ・レベルFINESTを構成すると、ADFビジネス・コンポーネント・フレームワークのコンポーネントによってアプリケーションに実行されるすべての内容を表示できます。

:
[355] Oracle SQLBuilder: Registered driver: oracle.jdbc.OracleDriver
[356] Creating a new pool resource
[357] **** DBTransactionImpl establishNewConnection
[358] Successfully logged in
[359] JDBCDriverVersion: xx.xx.x.x-Production
[360] DatabaseProductName: Oracle
[361] DBTransactionImpl initTransaction
[362] Replacing: null with: StoreServiceAM_AddressesPageDef
[363] Replacing: null with: StoreServiceAM_MostPopularProductsByCategoriesPageDef
...
[537] Orders ViewRowSetImpl.execute caused params to be "un"changed
[538] Column count: 41
[539] ViewObject: Orders Created new QUERY statement
[540] Orders>#q computed SQLStmtBufLen: 952, actual=865, storing=895
[541] SELECT OrderEO.ORDER_ID, OrderEO.ORDER_DATE, OrderEO.ORDER_SHIPPED_DATE,
FROM ORDERS OrderEO ORDER BY OrderEO.ORDER_DATE desc
[542] Bind params for ViewObject: Orders

後方互換性の目的で、データ・モデル・プロジェクトに対し従来のようにJavaシステム・プロパティjbo.debugoutput=consoleを使用して、ADFビジネス・コンポーネント・デバッグ診断を有効化できます。このプロパティを設定するには、データ・モデル・プロジェクトの「プロジェクト・プロパティ」ダイアログの実行/デバッグ/プロファイル・ページを開きます。「編集」をクリックして選択した実行構成を編集し、ページ内の「Javaオプション」フィールドに-Djbo.debugoutput=consoleを追加します。このプロパティの他の有効な値は、silent(指定されていない場合、デフォルト)およびfileです。fileオプションを選択すると、診断はsystem tempディレクトリに書き込まれます。

-Djbo.debugoutputシステム・プロパティの他の有効な値は、silent(指定されていない場合、デフォルト)およびfileです。fileオプションを入力すると、診断はシステムのtempディレクトリに書き込まれます。

8.3.11 実行時のビュー・オブジェクトとエンティティ・オブジェクトの連携処理

ビュー・オブジェクトとエンティティ・オブジェクトにより、すべてのエンタープライズ・アプリケーション開発者が実行する必要のある次の2つの重要なジョブが単独で簡略化されます。

- SQL問合せ結果の操作

- データベース表内の行の変更および検証

エンティティ・ベースのビュー・オブジェクトは、エンド・ユーザーが表示または変更できるようにする必要のあるデータを任意に選択して問い合せることができます。エンド・ユーザーによる変更が可能なデータは、再使用可能なビジネス・ドメイン・レイヤーによって検証および保存されます。開発者が指定するのは、開発者のみが把握できる重要事項です。

- ビジネス・ドメイン・レイヤーにどのビジネス・ロジックを適用するかの決定

- 画面に表示する必要のあるデータを記述する問合せの決定

これらにより、開発者のアプリケーションが独自のものになります。実装の残りの詳細部分は、エンティティ・ベースのビュー・オブジェクトに組み込まれた機能によって処理されます。

注意:

行キーおよびエンティティ・キャッシュがトランザクションで果す役割について理解することは、エンティティ・ベースのビュー・オブジェクトの本質を明確にするために役立つ重要な概念です。これら2つの概念は、「ビュー・オブジェクトのデフォルト行セットを使用した操作のViewObjectインタフェース・メソッド」で説明します。

8.3.11.1 ビュー・オブジェクトによる問合せ実行後の処理

エンティティ・ベースのビュー・オブジェクトのインスタンスをアプリケーション・モジュールのデータ・モデルに追加した後、問合せの実行時に行われる処理を確認できます。読取り専用ビュー・オブジェクトの場合と同様、エンティティ・ベースのビュー・オブジェクトが標準のJDBC (Java Database Connectivity) APIを使用してデータベースにSQL問合せを直接送信し、データベースが結果セットを生成します。ただし、読取り専用ビュー・オブジェクトの場合とは異なり、エンティティ・ベースのビュー・オブジェクトは、データベースの結果セットの各行を取得するときに、関連付けられているエンティティ・オブジェクトの慣用名に基づいて行属性を分割します。この分割の際、各ビュー・オブジェクトのエンティティ・オブジェクトの慣用名に適切なタイプのエンティティ・オブジェクト行が作成され、問合せによって取得された関連属性がこれらのエンティティ行に移入され、このようなエンティティ行がそれぞれ個別のエンティティ・キャッシュに格納されます。これにより、データの複製コピーを格納するかわりに、ビュー行は、これを構成するエンティティ行部分を指し示すだけでになります。

図8-13は、エンティティ・キャッシュにより、2つのエンティティ・ベース・ビュー・オブジェクトの結果セット属性がどのように分割されるかを示しています。この例では、データベース結果セットで強調表示された行は、主キー112のOrderエンティティ行と、主キー301のCustomerInfoエンティティ行に分割されています。

「エンティティ・キャッシュがトランザクションで果す役割」で説明するように、findByPrimaryKey()を使用してキャッシュに取り込んだエンティティ行には、エンティティ・オブジェクトのすべての属性が含まれています。一方、エンティティ・ベースのビュー・オブジェクトの問合せ結果の行を分割して作成されたエンティティ行には、問合せ結果に表れる属性の値のみが含まれます。これには完全な属性セットは含まれていません。このようにエンティティ行が部分的に移入されることにより、実行時のパフォーマンスが大幅に最適化されます。

一般的なエンタープライズ・アプリケーションで変更される行と比較して、取得される行の比率が非常に高くなるため、表示する必要がある属性のみをメモリーに読み込むことにより、常にすべての属性をメモリーに読み込む場合よりもメモリーを節約できます。

図8-13 エンティティ・キャッシュのエンティティ行に分割されるビュー行

このような方法で問合せ結果のデータを基礎となるエンティティ行の構成要素部分に分割すると、現在のトランザクションが変更された場合、問い合せた結果のデータを含むすべての行で整合している結果が表示されるという、重要な利点が得られます。つまり、あるビュー・オブジェクトで顧客301のPaymentType属性を変更できる場合、顧客301のPaymentType属性を表示する任意のエンティティ・ベースのビュー・オブジェクトのすべての行が即座に更新され、変更が反映されます。顧客301に関連付けられたデータがCustomerInfoエンティティ・キャッシュで主キー301を持つエンティティ行に格納されるのは1回のみであるため、オーダーのPaymentType属性を問い合せたビュー行はどれも、この単一のエンティティ行を指し示すことになります。

このような実装の詳細は、ビュー・オブジェクトの行セット内の行を操作するクライアントに対しては完全に非表示にされます。クライアントは、ビュー行を操作して属性を取得して設定する際、これらの属性がその背後でどのようにエンティティ行に関連付けられているかには気付きません。

8.3.11.2 ビュー行属性変更後の実行時の処理

ユーザーがビュー行属性を変更しようとすると、基礎となるエンティティ行に応じてこのビュー行属性の変更を自動的に調整する一連の手順が実行されます。これらの手順により、エンティティ・マップ属性で定義された検証規則は、値が変更される前にトリガーされます。

図8-14は、ユーザーがエンティティ・マップされた属性を更新しようとするときに実行時に発生する基本的な手順を示しています。この例では、変更される属性Statusが、検証規則が定義されているエンティティ・オブジェクトの慣用名にマップされています。

1. ユーザーがStatus属性の値をShipに設定しようとします。

2. StatusはOrderエンティティ・オブジェクトの慣用名にマップされた属性であるため、ビュー行は、Orderエンティティ・キャッシュ内で主キー112を持つ、基礎となるエンティティ行に設定されている属性を委譲します。

3. Orderエンティティ・オブジェクトのStatus属性に対する属性レベルの検証規則が評価され、規則が失敗した場合は変更が失敗します。
Status属性の検証規則によってShipDate属性がプログラム的に参照されるとします(たとえば、Orderは発注日と同日に出荷済にはできないというビジネス・ルールを適用する必要がある場合など)。ShipDateは、問合せによって取得されたOrder属性ではないため、Orderエンティティ・キャッシュ内に部分的に移入されたエンティティ行にはありません。

4. ビジネス・ルールでエンティティ・オブジェクトのすべての属性を常に参照可能にするため、エンティティ・オブジェクトはこの状況を検出し、主キーによって変更されるエンティティ行についてOrder エンティティ・オブジェクト属性のセット全体を失敗にします(主キーはビュー・オブジェクトに適用される各エンティティ・オブジェクトの慣用名に表示されます)。

5. 属性レベルの検証がすべて成功した後、エンティティ・オブジェクトでは、最初の属性の変更を許可する前にORDERS表でこの行にロックをかけます。

6. この行をロックできた場合、行内のStatus属性の設定が成功し、エンティティ行でこの値が変更されます。

注意:

jbo.locking.mode構成プロパティは、行のロック方法を制御します。デフォルト値はoptimisticです。通常、Fusion Webアプリケーションでは、このデフォルト設定のoptimisticを使用するため、トランザクションのコミット時まで行はロックされません。pessimisticロック・モードの場合、エンティティ・キャッシュで行に対する変更を許可する前に行のロックを可能にする必要があります。

図8-14 エンティティに委譲されるビュー行属性の更新

8.3.11.3 外部キー属性変更後の実行時の処理

ユーザーが外部キーの属性を変更しようとすると、基礎となるエンティティ行に応じてこのビュー行属性の変更を自動的に調整する一連の手順が実行されます。これらの手順により、外部キーのエンティティ・マップ属性で定義された検証規則は、値が変更される前にトリガーされます。また、変更された外部キー属性のビュー行に、すべての参照されたエンティティ・オブジェクトの正しい属性が反映されます。

図8-15は、ユーザーが外部キーのエンティティ・マップ属性を更新しようとするときに実行時に発生する基本的な手順を示しています。この例では、変更される属性CustomerInfoIdは、エンティティ・オブジェクトの慣用名Orderにマップされており、ここでこの属性は別のエンティティ・オブジェクトであるCustomerInfoと関連付けられます。

1. ユーザーがCustomerInfoId属性の値を300に設定しようとします。

2. CustomerInfoIdはOrderエンティティ・オブジェクトの慣用名にマップされた属性であるため、ビュー行は、Orderエンティティ・キャッシュ内で主キー112を持つ、基礎となるエンティティ行に設定されている属性を委譲します。

3. Orderエンティティ・オブジェクトのCustomerInfoId属性に対する属性レベルの検証規則が評価され、規則が失敗した場合は変更が失敗します。

4. この行はすでにロックされているため、行内のCustomerInfoId属性の設定が成功し、エンティティ行でこの値が変更されます。

5. Orderエンティティ・オブジェクトの慣用名のCustomerInfoId属性は、CustomerInfoエンティティ・オブジェクトに関連付けられているため、外部キー値をこのように変更すると、ビュー行で、顧客301の現在のエンティティ行部分が、新しいCustomerInfoId = 300に対応するエンティティ行に置き換えられます。これにより、オーダー112のビュー行が300のエンティティ行を指し示すよう効率的に変更できるため、ビュー行のPaymentTypeの値が更新され、この新しく割り当てられた顧客の参照情報が正しく反映されます。

図8-15 外部キーの更新後に新しいエンティティを指し示すビュー行

8.3.11.4 トランザクションのコミット後の実行時の処理

変更に問題がなく、トランザクションをコミットするとします。図8-16に示すとおり、次の2つの基本手順があります。

1. Transactionオブジェクトにより、保留中の変更リスト内の無効なエンティティ行が検証されます。

2. 保留中の変更リスト内のエンティティ行がデータベースに保存されます。

この図は、1つの変更済エンティティ・オブジェクトの検証処理が他のエンティティ・オブジェクトに対する変更にプログラム的に影響する前に行う、手順1のループを示します。保留中の変更リスト上で無効なエンティティのリストが処理された後、リストにまだエンティティが残されている場合、トランザクションで別のパスが実行されます。リストのパススルーは最大10回行われます。この時点でまだ無効なエンティティ行がある場合は通常、ビジネス・ロジックにエラーがあり、このビジネス・ロジックを調査する必要があるため、例外がスローされます。

図8-16 トランザクションのコミット時に行われる無効なエンティティの検証とエンティティの保存

8.3.11.5 ビュー・オブジェクトによるデータ再問合せ後の実行時の処理

ビュー・オブジェクトの問合せを再実行する場合、デフォルトでは、最新の結果セットを読み込むための準備中、現在の行セット内のビュー行は無視されます。ただし、このビュー・オブジェクト操作はエンティティ・キャッシュには直接影響しません。この場合、ビュー・オブジェクトがデータベースに対してSQLを送信することによってプロセスが再開され、データベースの結果セット行が取得され、エンティティ行部分に分割されます。

注意:

通常、ビュー・オブジェクトでデータの問合せを再実行する場合、この操作では最新のデータベース情報を取得します。かわりにビュー・オブジェクトの問合せ対象をキャッシュ内の既存のエンティティ行のみに制限する場合や、すでにビュー・オブジェクトの行セット内にある既存の行に制限して、データベースのラウンドトリップを回避する場合は、「行セットのメモリー内でのソート処理とフィルタ処理の実行」を参照してください。

8.3.11.5.1 問合せの再実行時の変更なしの属性の処理

問合せの再実行時におけるこのエンティティ行分割プロセスの一環として、エンティティ行の属性が変更されていない場合、エンティティ・キャッシュ内の値が更新され、新しい問合せ結果の値が反映されます。

8.3.11.5.2 問合せの再実行時の変更されたの属性の処理

一方、現在のトランザクションでエンティティ行属性の値が変更されている場合、問合せ再実行時のエンティティ行の分割プロセスでは、値はリフレッシュされません。現在のトランザクションでコミットされない変更はそのまま残されるため、エンド・ユーザーの論理作業ユニットは保持されます。任意のエンティティ属性値の場合と同様、これらの保留中の変更は、変更済エンティティ行を参照する任意のエンティティ・ベースのビュー・オブジェクト行に継続して表示されます。

注意:

エンド・ユーザーによる行の挿入および削除はエンティティ・キャッシュでも管理されるため、問合せの再実行時に、新規行を表示して削除済の行をスキップできます。新しい行の動作の詳細は、「同じエンティティに基づくビュー・オブジェクトでの新しい行の一貫性の保持」を参照してください。

たとえば、図8-17は、ユーザーがOrdersビュー・オブジェクト・インスタンスを使用する別のページにドリルダウンし、オーダー112に関する詳細を取得するシナリオを示しており、これは現在のトランザクションの保留中の変更のコンテキストで発生します。このビュー・オブジェクトには、プライマリOrdersの慣用名と、CustomerInfoの参照の慣用名の、2つのエンティティ・オブジェクトの慣用名があります。問合せ結果がエンティティ行に分割されると、前のOrderInfoビュー行で変更されたものと同じOrderエンティティ行を指し示すことになります。つまり、エンド・ユーザーには保留中の変更が正しく表示され、オーダーはこのトランザクションのsking に割り当てられています。

図8-17 エンティティ・キャッシュにマージされる、個別ビュー・オブジェクトのエンティティ属性セット

8.3.11.5.3 問合せの再実行時の属性のサブセットのオーバーラップの処理

2つの異なるビュー・オブジェクトが、参照情報の2つの異なるサブセットを取得でき、属性の一致するセットの有無にかかわらず、結果がマージされます。たとえば、図8-17もこの状況を示しており、Ordersビュー・オブジェクトはユーザーのEmailを問い合せていますが、OrderInfoビュー・オブジェクトはユーザーのPaymentOptionを問い合せています。この図は、実行時に行われる処理を示しており、取得した行を分割する際に、すでにキャッシュ内にある部分的に移入されたエンティティ行とは異なる属性セットがエンティティ行部分に含まれる場合、属性はマージされます。その結果、キャッシュ内の部分的に移入されたエンティティ行に、オーバーラップするユーザー属性のサブセットが統合されます。一方、キャッシュ内になかったjchen(ユーザー302)の場合、新しいエンティティ行にはEmail属性のみが含まれ、PaymentOptionは含まれません。

8.3.12 ビュー・オブジェクトの実行時パフォーマンスの最適化に関する必知事項

ビュー・オブジェクトには、SQLの実行方法とデータベースからデータをフェッチする方法を制御するチューニング・パラメータが用意されています。これらのチューニング・パラメータは、ビュー・オブジェクトの実行時パフォーマンスで重要な役割を果たします。アプリケーションでフェッチ・オプションが正常にチューニングされないと、ビュー・オブジェクトが必要以上の量のデータをフェッチし、データベースへのラウンドトリップの回数が非常に増える場合があります。

表8-2に示すように、概要エディタの「一般」ページの「チューニング」セクションでは、フェッチ・オプションを設定できます。

表8-2 ビュー・オブジェクトのパフォーマンスをチューニングするためのパラメータ

フェッチをチューニングするパラメータ

用途

フェッチ・モード

デフォルトのフェッチ・オプションは「すべての行」オプションで、「必要に応じて」(FetchMode="FETCH_AS_NEEDED")、または「一度にすべて」(FetchMode="FETCH_ALL")のどちらのオプションが適切かに応じて取得されます。「必要に応じて」オプションでは、ビュー・オブジェクトでのexecuteQuery()操作において、まず表示の最初のページを埋めるために必要な数の行のみが取得されます(この行数は、ビュー・オブジェクトの範囲サイズに基づいて設定されます)。

フェッチ・サイズ

「次の単位で」フィールドでは、「フェッチ・モード」オプションと連携して、データベースから一度にフェッチされるレコード数(ビュー・オブジェクトXMLのFetchSize)を制御します。デフォルト値は1です(1行のみがフェッチされる場合を除き、パフォーマンスが低下します)。推奨構成として、この値をn+3に設定することをお薦めします。nはユーザー・インタフェースに表示される行数です。このパラメータがメモリー要件にどのような影響を及ぼすかの詳細は、「一度に1行のフェッチが適切かどうかの検討」を参照してください。

最大フェッチ・サイズ

ビュー・オブジェクトのデフォルトの最大フェッチ・サイズは-1で、ビュー・オブジェクトでフェッチできる行数に制限がないことを示します。結果セットにn行のデータしか含まれない場合は、「行番号までのみ」のオプションを選択して、nに設定してください。開発者は、setMaxFetchSize(n)をコールしてプログラム的に設定することも、ビュー・オブジェクトXMLにパラメータMaxFetchSizeを手動で追加することもできます。

WHERE句が単一の行を取得すると予想されるビュー・オブジェクトの場合は、オプションを「最大で1行」に設定します。このオプションを指定すると、ビュー・オブジェクトはユーザーがそれ以上の行を期待していないことを認識し、さらに行がある場合に通常行うテストをスキップします。

前述のように、最大フェッチ・サイズを0に設定すると、ビュー・オブジェクトは挿入専用になります。この場合は、選択問合せは発行されないため、行はフェッチされません。

アプリケーションのすべてのビュー・オブジェクト問合せに対してグローバルなしきい値を指定する必要がある場合は、adf-config.xmlファイルで「行フェッチ制限」プロパティを設定できます。このプロパティを設定することで、個別の問合せ操作に対して「最大フェッチ・サイズ」の変更を行う必要がなくなります。個別のビュー・オブジェクトにフェッチ制限を設定する場合、これらのケースでは「行フェッチ制限」設定は無視されます。「行フェッチ制限」の詳細は、「ビュー・オブジェクトの最大フェッチ・レコード数を制限するためのフェッチ・サイズの使用方法」を参照してください。

「前方検索のみ」モード

データセットのトラバースで転送しか実行されない場合は、転送専用モードを使用すると、データセットを反復する場合のパフォーマンスが向上します。転送専用モードは、ビュー・オブジェクトでsetForwardOnly(true)をコールしてプログラム的に設定できます。転送専用モードを設定すると、データセットがトラバースされるときに、前の行セットがキャッシュされるのを防ぐこともできます。

ビュー・オブジェクトをチューニングする場合は、次の点も考慮する必要があります。

- 大規模なデータ・セット: ビュー・オブジェクトは、ユーザーが結果の特定のページにジャンプできるように、大規模なデータ・セット内でページ移動するメカニズムを備えています。この機能は、ビュー・オブジェクトでsetRangeSize(n)、setAccessMode(RowSet.RANGE_PAGING)の順にコールすることによって設定します(nは、1ページに含める行数)。ユーザーがデータ・セット内の特定のページに移動する場合、アプリケーションはビュー・オブジェクトでscrollToRangePage(P)をコールするとページPに移動できます。範囲ページングでは、現在のページの行のみがフェッチされて、ビュー・オブジェクトの行キャッシュに入れられるため、1ページのデータを取得するたびに問合せ実行のコストがかかります。範囲ページングは、すべての行をフェッチしてビュー・オブジェクトの行キャッシュに入れるほうが有利な場合には適していません(たとえば、データ・セットのすべての行を読み取ってLOVを生成したり、小さいデータ・セットのレコードを前後にページ移動したりする必要がある場合です)。

- スピルオーバー: JVMコンテナでメモリーが不足した場合に、データ・ソースを仮想メモリーとして使用する機能が用意されています。デフォルトでは、この機能は無効になっていますが、メモリーが不足した場合の最後の手段として、jbo.use.pers.coll=trueに設定することにより有効にできます。スピルオーバーを有効にすると、パフォーマンスが大きく影響を受ける場合があります。

- SQLプラットフォーム: SQL92準拠の汎用データベースへの接続に汎用SQL92 SQLプラットフォームを使用すると、ビュー・オブジェクトの一部のチューニング・オプションが正常に機能しなくなります。汎用SQL92 SQLプラットフォームを選択することにより最も影響を受けるパラメータは、フェッチ・サイズです。SQL92 SQLプラットフォームを使用すると、ビュー・オブジェクトの構成に関係なく、フェッチ・サイズがデフォルトで10行に設定されます。SQLプラットフォームは、データベース接続を定義するときに設定したり、adf-config.xmlファイル内にグローバルなプロジェクト設定として定義できます。デフォルトでは、SQLプラットフォームはOracleになります。SQLプラットフォームを手動でオーバーライドする場合は、起動時にパラメータ-Djbo.SQLBuilder="SQL92"をJVMに渡すこともできます。

また、データベースのパフォーマンスを向上するために、ビュー・オブジェクトの関連するSQLをチューニングするための次のオプションも用意されています。

- バインド変数: ビュー・オブジェクトに関連付けられた問合せに、実行ごとに変更される可能性がある値が含まれる場合は、バインド変数を使用します。問合せでバインド変数を使用すると、データベースで問合せを再解析する必要なく、問合せを再実行できます。バインド変数は、ビュー・オブジェクトの概要エディタの「問合せ」ページでビュー・オブジェクトに追加できます。詳細は、「バインド変数の使用」を参照してください。

- 問合せオプティマイザ・ヒント: ビュー・オブジェクトでは、ヒントをデータベースに渡して、関連する問合せに使用される実行計画に影響を与えることができます。オプティマイザ・ヒントは、ビュー・オブジェクトの概要エディタの「チューニング」セクションの「データベースから取得」グループ・ボックスで指定できます。オプティマイザ・ヒントの詳細は、「必要に応じた問合せオプティマイザ・ヒントの指定」を参照してください。

8.4 ビュー・オブジェクト・インスタンスのプログラムによるテスト

少なくとも1つのビュー・オブジェクト・インスタンスを含む、操作中のアプリケーション・モジュールをテストする準備ができたら、単純なテスト・クライアント・プログラムを構築して、含まれるビュー・オブジェクト・インスタンスにあるデータを使用したプログラムによる操作の基礎を示すことができます。

アプリケーション・モジュールのデータ・モデルにアクセスするクライアントの視点からは、読取り専用ビュー・オブジェクトを操作するAPIと、エンティティ・ベースのビュー・オブジェクトを操作するAPIは同一のものです。機能的な主な相違点は、エンティティ・ベースのビュー・オブジェクトでは、ビュー・オブジェクトのデータを完全に更新できる点です。エンティティ・ベースのビュー・オブジェクトを含むアプリケーション・モジュールは、作業ユニットを定義し、トランザクションを管理します。この項では、SummitADF_Examplesワークスペースを操作するテスト・クライアント・プログラムを使用して次について説明します。

- マスター/ディテール/ディテール階層の反復

- 行の検索および外部キー値の更新

- 新規注文の作成

- 行を識別する行キーの取得

8.4.1 ビュー・オブジェクトのデフォルト行セットを使用した操作のViewObjectインタフェース・メソッド

oracle.jboパッケージのViewObjectインタフェースには、データ取得タスクを簡単に実行するメソッドが用意されています。例に使用されるこれらのメソッドの一部には、次のものが含まれます。

- executeQuery(): ビュー・オブジェクトの問合せを実行し、その結果の行セットを移入します。

- setWhereClause(): 実行時に動的条件を追加して検索を絞り込みます。

- setNamedWhereClauseParam(): 名前付きバインド変数の値を設定します。

- hasNext(): 行セット・イテレータが結果の最終行に到達したかどうかをテストします。

- next(): 行セット・イテレータを行セット内の次の行へ進めます。

- getEstimatedRowCount(): ビュー・オブジェクトの問合せが戻す行の数をカウントします。

ビュー・オブジェクトを操作する場合は、通常、単一の結果行セットのみを1回で操作します。このきわめて一般的なユースケースを単純化するために、図8-18に示すように、ビュー・オブジェクトにはデフォルトのRowSetが含まれ、ここにデフォルトのRowSetIteratorが含まれています。デフォルトのRowSetIteratorにより、デフォルト行セットに自動的に適用されることを認識しながら、ViewObjectコンポーネント自体でデータ取得メソッドのすべてを直接コールできるようになります。

図8-18 デフォルトのRowSetおよびRowSetIteratorが含まれているビュー・オブジェクト

注意:

「多相ビュー・オブジェクトの定義」では、単一のビュー・オブジェクトを使用して複数の異なる結果行セットを生成する状況が示されています。また、1つの行セットに対して複数の異なる行セット・イテレータを作成するシナリオも説明されています。ただし、多くの場合は単一のイテレータのみ必要です。

このガイドで「ビュー・オブジェクトの行を使用して操作中」という表現を使用した場合は、正確にはビュー・オブジェクトのデフォルト行セットの行を使用して操作するということを意味しています。同様に、「ビュー・オブジェクトの行全体で反復処理する」という表現は、正確にはビュー・オブジェクトのデフォルト行セットのデフォルト行セット・イテレータを使用して、その行をループするという意味です。

8.4.1.1 ビュー行またはエンティティ行におけるキー・オブジェクトの役割

ビュー行を操作するときは、oracle.jboパッケージの中のRowインタフェースを使用します。図8-19に示すように、このインタフェースには、任意の行を識別するKeyオブジェクトへのアクセスに使用できる、getKey()と呼ばれるメソッドが含まれています。Rowインタフェースは、oracle.jbo.serverパッケージ内の Entityインタフェースによって拡張されます。この関係は、エンティティ行という用語が適切であることの具体的な理由になります。エンティティ行がビジネス・ロジックのカプセル化やデータベース・アクセスの処理のための追加機能をサポートしている場合でも、エンティティ行はRowとしてそのまま扱うことができます。

エンティティ・ベースのビュー・オブジェクトは、キーによる行の検索タスクを、基礎となるエンティティ行部分に委譲します。

前述のとおり、ビュー行とエンティティ行はどちらも単一属性または複数属性のキーをサポートしているため、特定のRowに関連付けられたKeyオブジェクトにより、キーを構成するすべての属性がカプセル化されます。Keyオブジェクトがある場合は、任意の行セットに対してfindByKey()メソッドを使用して、Keyオブジェクトに基づいて行を検索できます。findByKey()メソッドを使用してキーによってビュー行を検索すると、ビュー行ではエンティティ定義のfindByPrimaryKey()メソッドを使用して、ビュー行キーに属性を提供する各エンティティ行が検索されます。

読取り専用ビュー・オブジェクトの場合、このタスクを委譲する基礎となるエンティティ行がないため、主キー属性が1つでも検出されると、ビュー・オブジェクトの実装により、manageRowsByKeyフラグが自動的に有効になります。このため、読取り専用ビュー・オブジェクトの場合は、findByKey()メソッドが成功します。manageRowsByKeyフラグが有効でない場合、キーを使用して現在の行を設定するなどのUI操作は、findByKey()メソッドに依存するため機能しません。

図8-19 識別キーの取得をサポートしているビュー行またはエンティティ行

注意:

エンティティ・ベースのビュー・オブジェクトを定義する場合、デフォルトでは、すべてのエンティティ・オブジェクトの慣用名の主キー属性は、「キー属性」プロパティの設定がtrueとしてマークされます。更新不可能な参照エンティティ・オブジェクトの慣用名では、キー属性の「キー属性」プロパティを無効にしてください。更新可能なエンティティ・オブジェクトの慣用名の主キーに関連するビュー・オブジェクト属性は、複合ビュー行キーの一部である必要があるため、「キー属性」プロパティを無効にできません。

8.4.1.2 エンティティ・キャッシュがトランザクションで果す役割

アプリケーション・モジュールは、論理的な作業ユニットのトランザクション・コンテナです。実行時には、指定された名前の構成情報を使用してデータベース接続を確立し、トランザクション管理を付属のTransactionオブジェクトに委譲します。論理作業ユニットには、様々なタイプの複数のエンティティ行の検索や変更が含まれる場合があるため、Transactionオブジェクトには、現在のユーザーのトランザクションに関連するエンティティ行を保持するための作業領域として、エンティティ・キャッシュが用意されています。各エンティティ・キャッシュには単一のエンティティ・タイプの行が含まれるため、2つ以上のエンティティ・オブジェクトが関連するトランザクションでは、これらのエンティティ行の作業用コピーが個別キャッシュに保持されます。

エンティティ・オブジェクトの関連エンティティ定義を使用して、アプリケーション・モジュールで既存のエンティティ行を検索し、変更するためのコードを記述できます。図8-20に示すとおり、Orderエンティティ・オブジェクトのエンティティ定義に対してfindByPrimaryKey()をコールすると、そのキーを持つ行を取得できます。この行がまだエンティティ・キャッシュ内にない場合、エンティティ・オブジェクトによってこの行をデータベースから取得するための問合せが実行されます。この問合せにより、基礎となる表からエンティティ・オブジェクトのすべての持続属性が選択され、エンティティ・オブジェクトの主キー属性に対応する列に適したWHERE句を使用して行が検索されます。同一トランザクション中に同じエンティティ行をキーによって引き続き検索する場合、この行をキャッシュ内で検索することにより、データベースへのトリップを回避します。特定のエンティティ・キャッシュでは、主キーによってエンティティ行が索引付けされます。これにより、キャッシュ内でのエンティティ行の検索処理が速くなります。

アソシエーション・アクセッサ・メソッドを使用して関連エンティティ行にアクセスする場合、これらの行はエンティティ・キャッシュからも取得されます。関連エンティティ行がキャッシュ内にない場合は、データベースから取得されます。最後に、エンティティ・キャッシュは、新しいエンティティ行が保存されるまで保持される場所でもあります。つまり、createInstance2()メソッドを使用してエンティティ定義に対して新しいエンティティ行を作成する場合、このエンティティ行はエンティティ・キャッシュに追加されます。

図8-20 トランザクション中にエンティティ・キャッシュに格納されるエンティティ行

エンティティ行を作成、変更または削除すると、このエンティティ行はトランザクションの保留中の変更リストに自動的に登録されます。Transactionオブジェクトに対してcommit()をコールすると、保留中の変更リストが処理され、まだ無効の新規または変更済エンティティ行があるかどうかが検証されます。保留リスト内のエンティティ行がすべて有効である場合、Transactionにより、データベースのSAVEPOINTが発行され、データベースへのエンティティ行の保存が調整されます。すべて正常に完了すると、最終的にデータベースのCOMMIT文が発行されます。問題が発生した場合、TransactionによってROLLBACK TO SAVEPOINTが実行され、ユーザーはエラーを修正するか、または再試行できるようになります。

アプリケーション・モジュールで使用されるTransactionオブジェクトは、単一のエンド・ユーザー・トランザクション用のエンティティ行の作業セットです。設計上、これは共有のグローバル・キャッシュではありません。データベース・エンジン自体は、複数の同時ユーザーを対象とした非常に効率的な共有グローバル・キャッシュです。ADFビジネス・コンポーネントでは、すべての作業で行われてきたデータベースの共有グローバル・キャッシュ機能の微調整を繰り返すのではなく、その結果が意識的に採用されています。refresh()メソッドをコールすると、データベースから単一のエンティティ・オブジェクトのデータをいつでもリフレッシュできます。Transactionオブジェクトに対してsetClearCacheOnCommit()またはsetClearCacheOnRollback()を使用すると、コミットまたはロールバック時にエンティティ・キャッシュを消去するかどうかを制御できます。デフォルトはそれぞれfalseとtrueです。また、TransactionオブジェクトにはclearEntityCache()メソッドも用意されており、このメソッドを使用して、特定のエンティティ・タイプ(またはすべてのタイプ)のエンティティ行をプログラムで消去できます。エンティティ・キャッシュを消去すると、そのタイプのエンティティ行は、主キーによって次に検出されるか、エンティティ・ベースのビュー・オブジェクトによって取得されるときに、データベースから取得できます。

8.4.2 コマンド行Javaテスト・クライアントの作成方法

テスト・クライアント・プログラムを作成するには、「新規ギャラリ」からアクセス可能な「Javaクラスの作成」ウィザードを使用します。

8.4.2.1 スケルトン・コードを使用したテスト・クライアントの作成

テスト・クライアント・プログラムを作成するときに「Javaクラスの作成」ウィザードを使用すると、プログラム・ファイルがソース・エディタで開き、事前定義済のコード・テンプレートからコードを追加してテスト・クライアントを作成することができます。

始める前に:

プログラムによるテストに関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト・インスタンスのプログラムによるテスト」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・インスタンスのテストの追加機能」を参照してください。

スケルトンJavaテスト・クライアントを作成するには:

1. 「アプリケーション」ウィンドウで、テスト・クライアントを作成するプロジェクトを右クリックし、「新規」、「Javaクラス」の順に選択します。

2. 「Javaクラスの作成」ダイアログで、クラス名とパッケージ名を入力し、「拡張」フィールドがjava.lang.Objectとなっていることを確認します。

3. 「オプション属性」で、「スーパークラスからのコンストラクタ」の選択を解除し、「mainメソッド」を選択します。

4. 「OK」をクリックします。

.javaはソース・エディタで開き、次の例に示すように、スケルトン・コードが示されます。この例では、TestClientがクラス名で、oracle.summit.model.testがパッケージ名です。

package oracle.summit.model.test;

public class TestClient {
public static void main(String[] args) {
TestClient testClient = new TestClient();
}
}

8.4.2.2 スケルトン・コードの変更によるテスト・クライアントの作成

テスト・クライアントのスケルトン・コードを作成したら、作成したスケルトン・コード・テンプレートを使用してファイルの編集を開始できます。

始める前に:

プログラムによるテストに関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト・インスタンスのプログラムによるテスト」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・インスタンスのテストの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「スケルトン・コードを使用したテスト・クライアントの作成」の説明に従って、テスト・クライアントのスケルトン・コードを作成します。

スケルトン・コードを挿入するには:

1. main()メソッドの本体にある空白行にカーソルを置き、テスト・クライアント・クラス名を入力して、[Ctrl]キーを押しながら[Enter]キーを押します。

2. bc4jclientという文字を入力し、[Ctrl]キーを押しながら[Enter]キーを押します。

3. amDefおよびconfig変数の値を調整して、アプリケーション・モジュール定義の名前と使用する構成の名前をそれぞれ反映します。

次の例では、変更した行は次のようになります。

String amDef = "oracle.summit.model.viewobjects.AppModule";
String config = "AppModuleLocal";

4. 最後に、コール内のビュー・オブジェクト・インスタンス名を、作業するfindViewObject()に変更します。アプリケーション・モジュールの概要エディタの「データ・モデル」ページで「データ・モデル」ツリーに表示される名前を正確に指定します。

変更後の行は次のようになります。

ViewObject customerList = am.findViewObject("SCustomerView1");

アプリケーション・モジュールに対するスケルトン・テスト・クライアントには、次の例に示すようなソース・コードが含まれている必要があります。

注意:

「アプリケーション・モジュールのクライアント・インタフェースのプログラム的操作」における例では、このテスト・クライアント・サンプルコードが拡張され、カスタム・アプリケーション・モジュール・サービス・メソッドのコールも説明されます。

package oracle.summit.model.viewobjects;

import oracle.jbo.ApplicationModule;
import oracle.jbo.Row;
import oracle.jbo.RowSet;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;

public class TestClient {

public static void main(String[] args) {
String  amDef = "oracle.summit.model.viewobjects.AppModule";
String  config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
// 1. Find the Customer view object instance.
ViewObject customerList = am.findViewObject("SCustomerView1");
// Work with your appmodule and view object here
Configuration.releaseRootApplicationModule(am,true);
}
}

メソッド・コールcreateRootApplicationModule()により、テスト・クライアントは、ADFモデル・レイヤーが使用できない場所でアプリケーション・モジュール・インスタンスを作成できます。通常、Fusion Webアプリケーションでは、コードはADFバインディング・オブジェクトを介してアプリケーション・モジュール上のビュー・オブジェクトを見つけます。ADFモデル・レイヤーの操作方法の詳細は、「Fusion Webアプリケーションでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス方法」を参照してください。

// Work with your appmodule and view object hereを、テスト対象のビュー・オブジェクトを実行するコードに置き換えます。たとえば、ビュー・オブジェクトの問合せを実行して戻される行数を表示し、結果をループしてデータをフェッチし、コンソールに出力するには、次の例に示すコードを、使用しているデータ・モデル・プロジェクトのコンポーネントに合うように変更します。

// 2. Execute the query
customerList.executeQuery();
// 3. Iterate over the resulting rows
while (customerList.hasNext()) {
Row customer = customerList.next();
// 4. Print the customer's name
System.out.println("Customer: " + customer.getAttribute("Name"));
// 5. Get related rowset of Orders using view link accessor attribute
RowSet orders = (RowSet)customer.getAttribute("SOrdView");
// 6. Iterate over the Orders rows
while (orders.hasNext()) {
Row order = orders.next();
// 7. Print out some order attribute values
System.out.println(" ["+order.getAttribute("CustomerId")+"] "+
order.getAttribute("Id")+": "+
order.getAttribute("Total"));
if(!order.getAttribute("OrderFilled").equals("Y")) {
// 8. Get related rowset of OrderItems
RowSet items = (RowSet)order.getAttribute("SItemView");
// 9. Iterate over the OrderItems rows
while (items.hasNext()) {
Row item = items.next();
// 10. Print out some order items attributes
System.out.println("  "+item.getAttribute("ItemId")+": "+
item.getAttribute("Price"));
}
}
}
}

最初の行では、executeQuery()メソッドをコールして、ビュー・オブジェクト問合せを実行します。これにより、ビュー・オブジェクトのhasNext()メソッドがfalseを戻すまで反復処理を行うwhile文を使用してループできる、ゼロまたは1行以上の行セットを生成します。ループ内では、コードで現行のRowをcustomerという変数に入れてから、この現在のRowオブジェクト上でgetAttribute()メソッドを2回コールし、Name属性とOrders属性の値を取得して、オーダー情報をコンソールに出力します。2番目のwhile文では、オーダーの明細項目に対して同じタスクを実行します。

8.4.3 テスト・クライアント・プログラム実行時の処理

ConfigurationオブジェクトでのcreateRootApplicationModule()へのコールによって、使用するアプリケーション・モジュールのインスタンスが戻されます。デバッグ診断出力で示されるとおり、ADFビジネス・コンポーネント・ランタイム・クラスによって、必要に応じてXMLドキュメントがロードされ、設計時にデータ・モデルで定義されたアプリケーション・モジュールとビュー・オブジェクト・コンポーネントのインスタンスがインスタンス化されます。アプリケーション・モジュール上のfindViewObject()メソッドによって、アプリケーション・モジュールのデータ・モデルからビュー・オブジェクト・インスタンスを名前で検索します。「スケルトン・コードの変更によるテスト・クライアントの作成」で示されているループの後、テスト・クライアントはConfigurationオブジェクトでreleaseRootApplicationModule()を実行します。これにより、アプリケーション・モジュールを使用して処理したことが通知され、アプリケーション・モジュールに使用されたデータベース接続のように、フレームワークでリソースをクリーン・アップできるようになります。

8.4.4 テスト・クライアントの実行に関する必知事項

createRootApplicationModule()およびreleaseRootApplicationModule()メソッドは、アプリケーション・モジュール・コンポーネントへのコマンド行アクセスの場合に非常に便利です。ただし、通常、ADFベースのWebアプリケーションのコンテキストでは、これら2行のコードを記述する必要はありません。このような場合は、ADFモデル・レイヤーとADFビジネス・サービス・レイヤーの自動的な連携により、ADFアプリケーション・モジュール・コンポーネントが取得およびリリースされます。ADFモデル・レイヤーの操作方法の詳細は、「Fusion Webアプリケーションでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス方法」を参照してください。

8.4.5 行セットにおける行数計算の方法

getEstimatedRowCount()メソッドは、含まれている行数を判断するために、RowSetで使用されます。

long numOrders = orders.getEstimatedRowCount();

getEstimatedRowCount()の実装によって最初にSELECT COUNT(*)の問合せが発行され、問合せから戻される行の数を計算します。問合せは、次のような文のビュー・オブジェクトの問合せ全体をラップすることにより、計算式で表されます。

SELECT COUNT(*) FROM ( ... your view object's SQL query here ... )

SELECT COUNT(*)問合せを使用すると、必ずしもすべての行自体を取得しなくても、ビュー・オブジェクトの行数にアクセスできるようになります。このアプローチにより、大量の行数を戻す問合せを操作する場合や、問合せの結果を操作する前に問合せから戻さうる行数をテストする場合に、重要な最適化を図ることができます。

推定行数が計算されると、後続のメソッドへのコールではCOUNT(*)問合せは再実行されません。この値は、次にこのビュー・オブジェクトの問合せが実行されるまでキャッシュされます(データベースから戻される新しい問合せ結果セットに、前回の問合せ実行時より多い、少ない、または異なる行が含まれる可能性があるためです)。推定行数は、現行トランザクションで保留中の変更、関連する新規行の数の追加、および戻された数から削除された行数の差引を考慮して自動的に調整されます。

getEstimatedRowCount()をオーバーライドして、アプリケーションの必要性に合せて、カスタムのカウント問合せを実行することもできます。

8.4.6 ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法

「ビュー・リンク・アクセッサを使用したディテール・コレクションへのプログラムによるアクセス」で説明しているように、ビュー・リンク・アクセッサを使用してディテール行のRowSetを取得すると、ビュー・オブジェクトの結果行セットで使用されるパターンと同じパターンを使用して、その行セットに含まれる行全体をループできます(次の例を参照)。

while (orders.hasNext()) {
Row curOrder = orders.next();
System.out.println("--> (" + curOrder.getAttribute("Id") + ") " +
curOrder.getAttribute("Total"));
}

次の例は、CustomerViewビュー・オブジェクト・インスタンスを制限してcredit_rating_idの値が4であるユーザーのみを表示するために、動的なWHERE句を設定するmain()メソッドを示しています。さらに、executeAndShowResults()メソッドは、ビュー・リンク・アクセッサ属性(SOrdView)にアクセスし、各顧客のオーダーのIdおよびTotal属性を出力します。

ビュー・リンク・アクセッサを使用してディテール・コレクションにアクセスするには、次の基本手順に従います(後に例を示しています)。

1. マスター・ビュー・オブジェクト・インスタンスを検索します。

2. 問合せを実行します。

3. マスター・ビュー・オブジェクトの行を反復処理します。

4. ビュー・リンク・アクセッサ属性を使用して、関連するディテール・ビュー・オブジェクトの行セットを取得します。

5. ディテール・ビュー・オブジェクトの行を反復処理します。

6. 必要に応じて、ディテール行セット属性を操作します。

パフォーマンスに関するヒント

行をループするために記述するコードで行を表示する必要がない場合は、終了した行セットでcloseRowSet()メソッドをコールできます。この方法では、メモリー使用を効率化できます。行セットの問合せは、その行セットに次にアクセスしたときに再実行されます。

package oracle.summit.model.viewobjects;

import oracle.jbo.ApplicationModule;
import oracle.jbo.Row;
import oracle.jbo.RowSet;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;

public class TestClient2 {
public static void main(String[] args) {
String        amDef = "oracle.summit.model.viewobjects.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);
ViewObject vo = am.findViewObject("SCustomerView1");
// Add an extra where clause with a new named bind variable
vo.setWhereClause("credit_rating_id = :theCreditRating");
vo.defineNamedWhereClauseParam("theCreditRating", null, null);
vo.setNamedWhereClauseParam("theCreditRating", "4");
// Show results when :theCreditRating = '4'
executeAndShowResults(vo);
Configuration.releaseRootApplicationModule(am, true);
}
private static void executeAndShowResults(ViewObject vo) {
System.out.println("---");
vo.executeQuery();
while (vo.hasNext()) {
Row curCustomer = vo.next();
// Access the row set of details using the view link accessor attr.
RowSet orders = (RowSet)curCustomer.getAttribute("SOrdView");
long numOrders = orders.getEstimatedRowCount();
System.out.println(curCustomer.getAttribute("Id") + " " +
curCustomer.getAttribute("Name")+" ["+
numOrders+" orders]");
while (orders.hasNext()) {
Row curOrder = orders.next();
System.out.println("--> (" + curOrder.getAttribute("Id") + ") " +
curOrder.getAttribute("Total"));
}
}
}
}

TestClient2.javaを実行すると、次の例に示すような出力が「ログ」ウィンドウに出力されます。各顧客がリストされ、オーダーのある顧客ごとに、オーダーのIDと合計が顧客名の下に表示されます。

---
202 Simms Athletics [11 orders]
--> (98) 595
--> (113) 4990
--> (114) 567
--> (115) 866.7
--> (116) 3661.24
--> (117) 17489
212 Hamada Sport [22 orders]
--> (108) 149570
--> (196) 761
--> (197) 516.75
...

デバッグ診断を有効にしてTestClient2.javaを実行すると、ビュー・オブジェクトによって実行されたSQL問合せが表示されます。ビュー・リンクのWHERE句条件は、CustomerViewビュー・オブジェクトで現在行のディテール・サービス・リクエスト行のフィルタリングを自動実行するために使用されます。

8.4.7 マスター/ディテール/ディテール階層の反復方法

別のネスト・レベルが含まれるマスター/ディテールの反復処理を行うには、次の基本手順に従います(後に例を示しています)。

1. マスター・ビュー・オブジェクト・インスタンスを検索します。

2. 問合せを実行します。

3. 結果の行を反復処理します。

4. 必要に応じて、マスター行セット属性を操作します。

5. ビュー・リンク・アクセッサ属性を使用して、関連するディテール・ビュー・オブジェクトの行セットを取得します。

6. ディテール行セットの行を反復処理します。

7. 必要に応じて、ディテール行セット属性を操作します。

8. ビュー・リンク・アクセッサ属性を使用して、関連する2番目のディテール・ビュー・オブジェクトの行セットを取得します。

9. 2番目のディテール・行セットの行を反復処理します。

10. 必要に応じて、2番目のディテール行セット属性を操作します。

次の例では、もう1つネスト・レベルが追加されている以外は、「ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法」で説明した、マスター/ディテール読取り専用ビュー・オブジェクトを反復するTestClientプログラムと同じAPIを使用しています。

既存のTestClient.javaクラスでJDeveloperの「リファクタ」→「複製」機能を使用する場合、それを簡単にクローニングしてTestClient2.javaクラスを作成できます。たとえば、「ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法」で説明しているTestClient.javaクラスはこの手法に適しています。

package oracle.summit.model.viewobjects;

import oracle.jbo.ApplicationModule;
import oracle.jbo.Row;
import oracle.jbo.RowSet;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;

public class TestClient {
public static void main(String[] args) {
TestClient testClient = new TestClient();
String amDef = "oracle.summit.model.viewobjects.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
// Work with your appmodule and view object here
// 1. Find the Customer view object instance.
ViewObject customerList = am.findViewObject("SCustomerView1");
// 2. Execute the query
customerList.executeQuery();
// 3. Iterate over the resulting rows
while (customerList.hasNext()) {
Row customer = customerList.next();
// 4. Print the person's email
System.out.println("Customer: " + customer.getAttribute("Name"));
// 5. Get related rowset of Orders using view link accessor attr.
RowSet orders = (RowSet)customer.getAttribute("SOrdView");
// 6. Iterate over the Orders rows
while (orders.hasNext()) {
Row order = orders.next();
// 7. Print out some order attribute values
System.out.println(" ["+order.getAttribute("CustomerId")+"] "+
order.getAttribute("Id")+": "+
order.getAttribute("Total"));
if(order.getAttribute("OrderFilled").equals("Y")) {
// 8. Get related rowset of Items
RowSet items = (RowSet)order.getAttribute("SItemView");
// 9. Iterate over the Items rows
while (items.hasNext()) {
Row item = items.next();
// 10. Print out some order items attributes
System.out.println("  "+
item.getAttribute("ItemId")+": $"+
item.getAttribute("Price"));
}
}
}
}
}
}

このプログラムを実行すると、次の例に示す出力が生成されます。

Customer: Unisports
[201] 97: 84000
210: $9
211: $1500
Customer: Simms Athletics
[202] 98: 595
212: $85
[202] 113: 4990
328: $9
[202] 114: 567
329: $28
330: $40.95
331: $25
...

8.4.8 行の検索および外部キー値の更新の方法

行を検索して外部キーの値を更新するには、次の基本手順に従います(後に例を示しています)。

1. ビュー・オブジェクト・インスタンスを検索します。

2. Keyオブジェクトを作成し、ビュー・インスタンスの行を参照します。

3. findByKey()を使用して行を検索します。

4. 必要に応じて、行の属性を操作します。

次の例は、外部キーの値を検索して更新し、Ordersビュー・オブジェクト・インスタンスの行を検索するmain()メソッドを示しています。このサンプルでは、行の値が変更される前に、既存のOrderStatusCode属性の値が出力されます。

package oracle.summit.model.viewobjects;

import java.text.ParseException;
import java.text.SimpleDateFormat;

import java.util.Calendar;
import java.util.Date;

import oracle.jbo.ApplicationModule;
import oracle.jbo.JboException;
import oracle.jbo.Key;
import oracle.jbo.Row;
import oracle.jbo.RowSet;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;

public class TestClient3 {
public TestClient3() {
super();
}

public static void main(String[] args) {
String amDef = "oracle.summit.model.viewobjects.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);
// 1. Find the Orders view object instance
ViewObject vo = am.findViewObject("SOrdView1");
// 2. Construct a new Key to find Order # 100
Key orderKey = new Key(new Object[] { 100 });
// 3. Find the row matching this key
Row[] ordersFound = vo.findByKey(orderKey, 1);
if (ordersFound != null && ordersFound.length > 0) {
Row order = ordersFound[0];
// 4. Print some order information
Date dateOrdered = (Date) order.getAttribute("DateOrdered");
String orderDate = dateOrdered.toString();
System.out.println("Order Date is: " + orderDate);

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
Calendar c = Calendar.getInstance();
try {
c.setTime(sdf.parse(orderDate));
} catch (ParseException e) {
}
c.add(Calendar.DAY_OF_MONTH, -2);
// // number of days to add
orderDate = sdf.format(c.getTime());
System.out.println(orderDate);
try {
// 5. Try setting the ship date to an illegal value
order.setAttribute("DateShipped", orderDate);
am.getTransaction().commit();
} catch (JboException ex) {
System.out.println("ERROR: " + ex.getMessage());
}
// 6. Set the ship date to a legal value
order.setAttribute("DateShipped", orderDate);
// 7. Show the value of the ship date was updated successfully
System.out.println("Ship date is: " +
order.getAttribute("DateShipped"));
// 8. Show the current value of the customer for this order
System.out.println("Customer: " + order.getAttribute("CustomerId"));
// 9. Reassign the order to customer # 210
order.setAttribute("CustomerId", 210);
// 10. Show the value of the reference information now
System.out.println("Customer: " + order.getAttribute("CustomerId"));
// 11. Rollback the transaction
am.getTransaction().rollback();
System.out.println("Transaction canceled");
}
Configuration.releaseRootApplicationModule(am, true);
}

}

この例を実行すると、次の例に示す出力が生成されます。

Order Date is: 2012-08-29
2012-08-27
ERROR: JBO-oracle.summit.model.viewobjects.SOrd_Rule_0:
You cannot have a shipping date that is before the order date
Ship date is: 2012-08-27
Customer: 204
Customer: 210
Transaction canceled

8.4.9 ビュー・オブジェクト・インスタンスの新しい行の作成方法

新しいビュー行インスタンスを作成するには、次の基本手順に従います(後に例を示しています)。

1. ビュー・オブジェクト・インスタンスを検索します。

2. 新しい行を作成し、行セットに挿入します。

3. 新しい行の必須属性の値を設定します。

4. トランザクションをコミットします。

次の例は、OrdViewビュー・オブジェクト・インスタンスを検索し、新しい行を行セットに挿入するmain()メソッドを示しています。OrdViewビュー・オブジェクトはエンティティ・ベースなので、CreatedBy属性は、マップされたエンティティ・オブジェクト属性から値を導出します。このサンプルでは、トランザクションのコミット前に、残りの属性の値が設定されます。

package oracle.summit.model.viewobjects;

import java.util.Date;

import oracle.jbo.ApplicationModule;
import oracle.jbo.Row;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;
import oracle.jbo.domain.DBSequence;

public class TestClient4 {

public static void main(String[] args) {
String amDef = "oracle.summit.model.viewobjects.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);

// 1. Find the Orders view object instance.
ViewObject orders = am.findViewObject("SOrdView1");

// 2. Create a new row and insert it into the row set
Row newOrder = orders.createRow();
orders.insertRow(newOrder);
// Show the entity object-related defaulting for DateOrdered attribute
System.out.println("DateOrdered defaults to: " +
newOrder.getAttribute("DateOrdered"));

// 3. Set values for some of the required attributes
newOrder.setAttribute("CustomerId", 201);
newOrder.setAttribute("SalesRepId", 12);
newOrder.setAttribute("PaymentTypeId", 2);
newOrder.setAttribute("OrderFilled", "N");

// 4. Commit the transaction
am.getTransaction().commit();

// 5. Retrieve and display the trigger-assigned order id
DBSequence id = (DBSequence)newOrder.getAttribute("Id");
System.out.println("Thanks, reference number is " +
id.getSequenceNumber());
Configuration.releaseRootApplicationModule(am, true);
}
}

この例を実行すると、次の例に示す結果が生成されます。

DateOrdered defaults to: 2013-3-11
Thanks, reference number is 6

8.4.10 行を識別する行キーの取得方法

行キーを取得して行を特定するには、次の基本手順に従います(後に例を示しています)。

1. ビュー・オブジェクト・インスタンスを検索します。

2. 指定された値を使用してキーを作成します。

3. このキーを使用して行を検索します。

4. 必要に応じて、行のキーを操作します。

次の例は、OrdViewビュー・オブジェクト・インスタンスを検索し、行キーを作成してオーダー番号を検索するmain()メソッドを示しています。findByKey()メソッドでは、指定されたキーによりOrdView行が検索されます。このサンプルでは、次に行のキーが表示され、ItemViewビュー・リンク・アクセッサを使用して行セットがアクセスされ、行を反復処理して各ItemView行のキーが表示されます。

package oracle.summit.model.viewobjects;

import oracle.jbo.ApplicationModule;
import oracle.jbo.Key;
import oracle.jbo.Row;
import oracle.jbo.RowSet;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;

public class TestClient5 {
public static void main(String[] args) {
String amDef = "oracle.summit.model.viewobjects.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);
// 1. Find the Orders view object instance
ViewObject vo = am.findViewObject("SOrdView1");
// 2. Construct a key to find order number 100
Key orderKey = new Key(new Object[] { 100 });
// 3. Find the Orders row with the key
Row[] ordersFound = vo.findByKey(orderKey, 1);
if (ordersFound != null && ordersFound.length > 0) {
Row order = ordersFound[0];
// 4. Displays the key of the Orders row
showKeyFor(order);
// 5. Accesses row set of Orders using OrderItems view link accessor
RowSet items = (RowSet)order.getAttribute("SItemView");
// 6. Iterates over the Items row
while (items.hasNext()) {
Row itemRow = items.next();
// 4. Displays the key of each Items row
showKeyFor(itemRow);
}
}
Configuration.releaseRootApplicationModule(am, true);
}

private static void showKeyFor(Row r) {
// get the key for the row passed in
Key k = r.getKey();
// format the key as "(val1,val2)"
String keyAttrs = formatKeyAttributeNamesAndValues(k);
// get the serialized string format of the key, too
String keyStringFmt = r.getKey().toStringFormat(false);
System.out.println("Key " + keyAttrs + " has string format " +
keyStringFmt);
}

// Build up "(val1,val2)" string for key attributes
private static String formatKeyAttributeNamesAndValues(Key k) {
StringBuffer sb = new StringBuffer("(");
int attrsInKey = k.getAttributeCount();
for (int i = 0; i < attrsInKey; i++) {
if (i > 0)
sb.append(",");
sb.append(k.getAttributeValues()[i]);
}
sb.append(")");
return sb.toString();
}
}

この例を実行すると、次の例に示す結果が生成されます。シリアライズされたキーの文字列フォーマットは16進数で、キー内のすべての属性を示す単一文字列に情報が含まれています。

Key (100) has string format 000100000003313030
Key (100,156) has string format 000200000003C2020200000002C102
Key (100,157) has string format 000200000003C2020200000002C102
...

8.4.11 findByKey()での部分キーの使用に関する必知事項

複数のエンティティ・オブジェクトの慣用名に基づくビュー・オブジェクトでは、部分的に移入されたキーを指定してビュー行を検索できます。部分キーは、複数属性のKeyオブジェクトで、一部の属性がnullに設定されたものです。ただし、findByKey()を実行するために使用できる部分キーの種類には、厳密な規則があります。

ビュー・オブジェクトがn個のエンティティ・オブジェクトの慣用名(n > 1)に基づいている場合、ビュー行のキーは、デフォルトで、関連するすべてのエンティティ・オブジェクトの慣用名のすべての主キー属性で構成されます。ビュー行のキーに参加する必要があるのは最初のエンティティ・オブジェクトの主キーのみですが、デフォルトですべての主キーが使用されます。

一部のセカンダリ・エンティティ・オブジェクトの慣用名のキー属性をビュー行レベルのキー属性として残す場合は、そのエンティティ・オブジェクトの主キーを構成するすべての属性をビュー行のキーの一部として残しておく必要があります。n個のエンティティ・オブジェクトの慣用名のうちのm個について(m <= n)、ビュー行の1つ以上のキー属性を残した場合、findByKey()を使用し、m個のエンティティ・オブジェクトの慣用名の任意のサブセットに基づいて行を検索できます。Keyオブジェクトで値を指定するそれぞれのエンティティ・オブジェクトの慣用名について、そのエンティティの主キーのすべての属性にNULLではない値を指定する必要があります。

ビュー・オブジェクトが1つ以上のエンティティ・オブジェクトの慣用名に基づいている場合、そのfindByKey()メソッドは、ビュー行キーでの属性がNULLではない最初のエンティティ・オブジェクトの慣用名に対応するエンティティ定義のfindByPrimaryKey()メソッドに委譲することで行を検索するため、この規則に従う必要があります。エンティティ定義のfindByPrimaryKey()メソッドでキャッシュ内のエンティティ行を検索するには、特定のエンティティ・オブジェクトに対するすべてのキー属性がNULL以外である必要があります。

具体的な例としては、OrderInfoVOビュー・オブジェクトで、OrderEOエンティティ・オブジェクトがそのプライマリ・エンティティ・オブジェクト慣用名で、AddressEOエンティティがセカンダリ参照エンティティ・オブジェクト慣用名である場合を考えてみてください。さらに、次の両方のビュー行属性のキー属性プロパティを、trueに設定したままにするものとします。

- OrderId - OrderEOエンティティの主キー

- AddressId - AddressEOエンティティの主キー

したがって、ビュー行のキーは、OrderIdとAddressIdの組合せになります。findByKey()を呼び出すときは、次のような内容のKeyオブジェクトを渡すことができます。

- 基礎となるOrderEOエンティティの完全に指定されたキー

Key k = new Key(new Object[]{new Number(200), null});

- 基礎となるAddressEOエンティティの完全に指定されたキー

Key k = new Key(new Object[]{null, new Number(118)});

- 両方のエンティティの完全に指定されたキー

Key k = new Key(new Object[]{new Number(200), new Number(118)});

有効な部分キーを指定すると、findByKey()メソッドは、キー・オブジェクトで指定されていないエンティティ・オブジェクト慣用名の属性をワイルドカードとして扱い、結果として複数の行を返すことができます。

8.4.12 テスト・クライアントでのテスト・ユーザー認証方法

アプリケーションに対してADFセキュリティを有効にし、テスト・ユーザーにjazn-data.xmlファイルをプロビジョニングしている場合は、テスト・クライアントを実行する前に、ユーザーを認証するためのメソッド・コールを組み込む必要があります。テスト・クライアントでユーザーを認証するには、次の基本的な手順に従います(次の例を参照)。

1. 認証サービスを作成します。

2. jazn-data.xmlファイルに定義されている、テスト・ユーザー用のログイン資格証明を渡します。

3. 認証が成功したら、アプリケーション・モジュールをテストします。

4. ユーザーをログアウトします。

ADFセキュリティの構成ウィザードを実行してADFセキュリティを有効にする方法、およびJDeveloperのアイデンティティ・ストアにテスト・ユーザーを作成する方法の詳細は、「ADFセキュリティ・プロセスの概要」を参照してください。

package oracle.summit.model.test;
import oracle.jbo.ApplicationModule;
import oracle.jbo.Key;
import oracle.jbo.Row;
import oracle.jbo.RowSet;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;

import oracle.adf.share.security.AuthenticationService;
import oracle.adf.share.security.authentication.AuthenticationServiceUtil;
import oracle.adf.share.ADFContext;
import oracle.adf.share.security.SecurityContext;
import oracle.adf.share.security.SecurityEnv;

import javax.security.auth.Subject;

public class TestAuthenticationClient {
public static void main(String[] args) {
String amDef = "test.TestAuthModule";
String config = "TestAuthModuleLocal";

// 1. Create authentication service.
AuthenticationService authService =
AuthenticationServiceUtil.getAuthenticationService();
try
{
// 2. Pass in user id and password defined in local identity store.
authService.login("tester1", "welcome1");
}
catch (Exception e)
{

}

// Uncomment to output authentication status
// String userName =
ADFContext.getCurrent().getSecurityContext().getUserName();

// System.out.println("*** userName : " + userName);
// Subject subject =
ADFContext.getCurrent().getSecurityContext().getSubject();
// System.out.println("Subject : " + subject);

// 3. Test application module if authentication succeeds.
if (ADFContext.getCurrent().getSecurityContext().isAuthenticated()) {
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
ViewObject vo = am.findViewObject("TestView");
// Work with your appmodule and view object here
Configuration.releaseRootApplicationModule(am,true);

// 4. Log out test user.
authService.logout();

// Uncomment to report logout success
// boolean isAuthenticated =
ADFContext.getCurrent().getSecurityContext().isAuthenticated();
// System.out.println("*** isAuthenticated : " + isAuthenticated);
}

}
}

9 ビュー・オブジェクトのパフォーマンス・チューニング

この章では、Oracle ADFアプリケーションでADFビュー・オブジェクトを設計および利用するときに使用できる高度な手法について説明します。

この章の内容は次のとおりです。

- ビュー・オブジェクトのチューニングについて

- 同じエンティティに基づくビュー・オブジェクトでの新しい行の一貫性の保持

- パラメータ付き問合せのためのバインド変数の使用方法

- 複数の行セットと行セット・イテレータの使用

- 読取り専用データへのエンティティ・ベースのビュー・オブジェクトの使用方法

- 異常な問合せを識別するためのSQLトレースの使用方法

- 適切なビュー・オブジェクト・チューニング設定の使用方法

- ビュー・オブジェクトの最大フェッチ・レコード数を制限するためのフェッチ・サイズの使用方法

- 範囲サイズを使用したページ単位でのデータの提示およびスクロール

- 大きい結果セットを効率的にスクロールするための範囲ページ移動の使用方法

- ビュー行のキャッシュを避ける前方のみモードの使用方法

- 「行セットの保存」を使用したビュー・リンク・アクセッサのアクセスの最適化

- UIの状態を格納するためのビュー・オブジェクトでの動的属性の使用方法

9.1 ビュー・オブジェクトのチューニングについて

ビュー・オブジェクトを使用すると、データの行の読取り、一時的データの行の作成と格納、およびエンド・ユーザーが基礎のビジネス・オブジェクトに対して行う挿入、更新、削除の自動的な調整を行うことができます。ビュー・オブジェクトを設計および使用する方法が、実行時のパフォーマンスに影響を与える場合があります。ADFビジネス・コンポーネント用のJDeveloperデザインタイムには、最適なパフォーマンスを得るためのビュー・オブジェクトの構成に使用できる数多くの機能があります。

9.2 同じエンティティに基づくビュー・オブジェクトでの新しい行の一貫性の保持

1つのアプリケーション・モジュールで、エンティティ・ベースのビュー・オブジェクトの複数インスタンスが同じエンティティ・オブジェクトに基づいているときは、1つのインスタンスで作成された新しい行を、他のインスタンスの行セットに(再問合せを行うことなく)自動的に追加して、ユーザー・インタフェースの整合性を保つか、保留中のトランザクションの異なるアプリケーション・ページに新しい行を一貫して反映できます。顧客のオーダーのリストを表示するアプリケーションを考えてみます。顧客が新しいオーダーを作成する場合、このタスクは別のビュー・オブジェクトを介して実行され、カスタム・アプリケーション・モジュールのメソッドによって処理されます。このビュー・オブジェクトの新規行の整合機能を使用すると、新しく作成されたオーダーが、データベースに再度問い合せることなく、顧客の未処理オーダーのリストに自動的に表示されます。

歴史的な理由から、この機能はビュー・リンクの一貫性機能と呼ばれています。これは、Oracle Application Development Framework (Oracle ADF)の以前のリリースでは、アソシエーションに基づくビュー・リンクでの詳細ビュー・オブジェクト・インスタンスのサポートは、他の関連する行セットに対する新規行の追加にかぎられていたためです。現在では、このビュー・リンク一貫性機能は、ビュー・リンクに関連性があるかどうかには関係なく、この機能が有効になっているすべてのビュー・オブジェクトで機能します。

9.2.1 実行時に行われる処理: ビュー・リンクの一貫性が有効な場合

同じOrdersエンティティ・オブジェクトに基づく2つのエンティティ・ベースのビュー・オブジェクトOrdersViewSummaryとOrdersViewについて考えます。一方のビュー・オブジェクト(OrdersViewなど)の行セットで新しい行が作成され、行の主キー行が設定されると、同じOrdersエンティティ・オブジェクトに基づくビュー・オブジェクト(OrdersViewSummaryなど)の他の行セットは、新しい行が作成されたことを示すイベントを受け取ります。ビュー・リンク一貫性フラグが有効になっていると、新しい行のコピーの行セットへの挿入も行われます。

注意:

デフォルトでは、ビュー・リンク一貫性のメカニズムにより、新しい行は無条件に追加されます。関係するすべてのビュー・オブジェクトの行セットに新規行が追加されないようにする場合は、RowMatchオブジェクトにフィルタ式を記述して、行セットに追加される前に行を制限できます。詳細は、「行セットに追加されるポストされていない新規行を制限するためのRowMatchの使用方法」を参照してください。

9.2.2 ビュー・リンク一貫性のデフォルト設定の変更に関する必知事項

アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタで、jbo.viewlink.consistent構成パラメータを使用してビュー・リンク一貫性機能のデフォルト設定を制御できます。

アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。アプリケーション・モジュール構成の概要エディタで「プロパティ」タブを選択し、「プロパティの追加」をクリックして「プロパティの追加」ダイアログからプロパティを選択し、「OK」をクリックします。

このパラメータのデフォルト設定はDEFAULTで、次のような意味があります。ビュー・オブジェクトが次の状態であるものとします。

- 単一のエンティティ・オブジェクトの慣用名、ビュー・リンク一貫性は有効

- 複数のエンティティ・オブジェクトの慣用名、かつ

- すべてのセカンダリ・エンティティ・オブジェクトの慣用名が寄与する参照情報としてマークされている場合は、ビュー・リンク一貫性が有効

- いずれかのセカンダリ・エンティティ・オブジェクトの慣用名が参照としてマークされていない場合は、ビュー・リンク一貫性が無効

この場合は、構成でjbo.viewlink.consistentに値falseを設定することで、この機能をグローバルに無効にできます。逆に、jbo.viewlink.consistentに値trueを設定するとこの機能をグローバルに有効にできますが、このように設定することはお薦めしません。有効に設定すると、現時点ではビュー・リンク一貫性機能がサポートされていない参照としてマークされていないセカンダリ・エンティティ・オブジェクトの慣用名を持つビュー・オブジェクトに対しても、強制的にビュー・リンク一貫性が設定されます。

この機能をプログラムで設定するには、任意のRowSetでsetAssociationConsistent() APIを使用します。ビュー・オブジェクトでこのメソッドを呼び出すと、デフォルトの行セットに適用されます。

9.2.3 行セットに追加されるポストされていない新規行を制限するためのRowMatchの使用方法

ビュー・オブジェクトでビュー・リンク一貫性が有効になっている場合は、同じエンティティ・オブジェクトに基づく別のビュー・オブジェクトで作成された新しい行が、行セットに追加されます。デフォルトでは、新しい行は無条件に追加されます。ビュー・オブジェクトに、行の特定のサブセットのみを問い合せる設計時WHERE句がある場合は、ビュー・オブジェクトにRowMatchオブジェクトを適用して、同じフィルタ処理をメモリー内で実行できます。指定するRowMatchオブジェクトのフィルタ式により、そのオブジェクトに表示しても意味のない新規行は追加されません。

たとえば、OrdersByStatusビュー・オブジェクトには、次のような設計時WHERE句が含まれることがあります。

WHERE /* ... */ AND STATUS LIKE NVL(:StatusCode,'%')

そのカスタムJavaクラスでは、create()メソッドが次の例に示すようにオーバーライドされており、ビュー・リンク一貫性を強制的に有効にします。また、Status属性が:StatusCode名前付きバインド変数の値と一致する行(または:StatusCode ='%'の場合はすべての行)に一致するフィルタ式を含むRowMatchオブジェクトを適用します。ビュー・リンク一貫性メカニズムは、このRowMatchフィルタを使用して、行セットに追加する候補の行を限定します。RowMatchで適格とされた行は追加されます。そうでない行は追加されません。

// In OrdersByStatusImpl.java
protected void create() {
super.create();
setAssociationConsistent(true);
setRowMatch(new RowMatch("Status = :StatusCode or :StatusCode = '%'"));
}

RowMatchオブジェクトの作成と使用の詳細は、「RowMatchによるメモリー内フィルタ処理の実行」を参照してください。サポートされているSQL演算子のリストは、表10-2を参照してください。サポートされているSQL関数のリストは、表10-3を参照してください。

注意:

RowMatch機能では十分に制御できない場合は、ビュー・オブジェクトのrowQualifies()メソッドをオーバーライドして、カスタム・フィルタ処理ソリューションを実装できます。コードを使用して、新しい行をビュー・リンク一貫性メカニズムで追加するかどうかを決定できます。

9.2.4 動的なWHERE句とビュー・リンク一貫性に関する必知事項

ビュー・オブジェクトでsetWhereClause()を呼び出して動的WHERE句を設定すると、そのビュー・オブジェクトのビュー・リンク一貫性機能は無効になります。行セットに追加する新しい行を限定するために適切なカスタムRowMatchオブジェクトを提供していた場合は、setWhereClause()の後でsetAssociationConsistent(true)を呼び出すことで、ビュー・リンク一貫性を再び有効にできます。

行セットでビュー・リンク一貫性が有効になっている場合、他の行セットで作成されたために追加される新しい行は、行セットの最後に追加されます。

行セットでビュー・リンク一貫性が有効になっている場合、executeQuery()メソッドを呼び出すと、適格なポストされていない新規行は、問合せによってデータベースから取得された行が追加される前に、行セットの先頭に追加されます。

9.3 パラメータ付き問合せのためのバインド変数の使用方法

問合せのWHERE句に実行のたびに変化する可能性のある値が含まれる場合は常に、名前付きバインド変数を使用する必要があります。ビュー・オブジェクトの概要エディタの「問合せ」ページで表示される「ビュー基準の作成」ダイアログを使用すると、そのようなタスクを簡単に実行できます。また、名前付きバインド変数を使用することで、悪質なエンド・ユーザーによるSQLインジェクション攻撃からアプリケーションを保護することもできます。バインド変数によるビュー基準の定義の詳細は、「名前付きビュー基準を宣言的に作成する方法」を参照してください。

9.3.1 問合せの再解析を防ぐためのバインド変数の使用

バインド変数は、SQL文字列内のプレースホルダであり、SQL文字列自体のテキストを変更することなく、実行時に簡単に値を変更できます。問合せのテキストは実行ごとに変化しないので、データベースは同じ解析済の文を毎回効率よく再利用できます。文の再解析を避けることで、データベースでは問合せ最適化プランを絶えず再決定する必要が軽減され、この解析操作の間に使用される他の貴重なデータベース・リソースに対する複数のエンド・ユーザーによる競合をなくすことができます。これらの減少により、実行時のアプリケーションのパフォーマンスが向上します。名前付きバインド変数の使用方法の詳細は、「ビュー・オブジェクト定義にWHERE句のバインド変数を追加する方法」を参照してください。

9.3.2 SQLインジェクション攻撃を避けるためのバインド変数の使用

パラメータを使用するWHERE句の値に対してバインド変数を使用することは、その値をアプリケーションのエンド・ユーザーが提供する場合に特に重要です。次に例を示します。この例は、ユーザーが指定したパラメータ値を文に連結して構成された動的なWHERE句を追加します。

// EXAMPLE OF BAD PRACTICE, Do not follow this approach!
String userSuppliedValue = ... ;
yourViewObject.setWhereClause("BANK_ACCOUNT_ID = "+userSuppliedValue);

悪質な意図を持つユーザーは、アプリケーションの基礎にあるデータベース・スキーマの詳細を知ることができれば、慎重に構成された銀行口座番号を、次のようにフィールド値またはURLパラメータとして提供できます。

BANK_ACCOUNT_ID

前述の例のコードで、動的に適用されるWHERE句にこの値を連結すると、データベースには次のような問合せ述語が示されます。

WHERE (BANK_ACCOUNT_ID = BANK_ACCOUNT_ID)

このWHERE句では現在のユーザーの口座だけでなくすべての銀行口座が取得され、ハッカーは他人の口座の個人情報を見ることができます。悪質な目的で作成されたパラメータ値をSQL文に提供することでアプリケーションのWHERE句を短絡するこのような手法のことを、SQLインジェクション攻撃と呼びます。このような場合は、かわりに次の例に示すように名前付きバインド変数を使用することで、脆弱性を回避できます。

// Best practice using named bind variables
String userSuppliedValue = ... ;
yourViewObject.setWhereClause("BANK_ACCOUNT_ID = :BankAcccountId");
yourViewObject.defineNamedWhereClauseParam("BankAcccountId", null, null);
yourViewObject.setNamedWhereClauseParam("BankAcccountId",userSuppliedValue);

この場合に悪質なユーザーが不正な値を提供すると、予想しないデータを取得するのではなく、アプリケーションが処理できるエラーを受け取ります。

9.3.3 バインド・パラメータ値のロギング

ビュー・オブジェクト問合せの実行に使用されるバインド・パラメータ値がわかるようにする必要がある場合は、テストの実行前またはデバッグ・セッション中に、ログ・レベルを構成できます。指定するログ・レベルによって、ログ・メッセージのタイプと量が決まります。バインド・パラメータの情報を表示するには、最低でもJavaログ・レベルCONFIGを設定する必要があります。ログ・アナライザの使用と構成の詳細は、「ログ・アナライザを使用してログ・メッセージを表示する方法」を参照してください。

また、ビュー・オブジェクトのViewObjectImplクラスのbindParametersForCollection()メソッドをオーバーライドすることにより、バインド・パラメータ値をプログラムでログに記録することもできます。このメソッドは、問合せで使用されるバインド・パラメータの名前と値をログに記録する場合に使用されます。これを実装してバインド・パラメータの値をログに記録できます。この機能は、バインド・パラメータがランタイムで生成されるようなシナリオで特に便利です。たとえば、ADF Facesツリー・コンポーネントがビュー・リンク・アソシエーションを使用して作成される場合、ノードにはバインド・パラメータで値が移入されますが、これをログに記録できます。次の例は、この目的でbindParametersForCollection()メソッドを定義する方法を示しています。

@Override protected void bindParametersForCollection(QueryCollection qc,
Object[] params,
PreparedStatement stmt) throws
SQLException {        String vrsiName = null;
if (qc != null) {
ViewRowSetImpl vrsi = qc.getRowSetImpl();
vrsiName = vrsi.isDefaultRS() ? "<Default>" : vrsi.getName();
}
String voName = getName();
String voDefName = getDefFullName();
if (qc != null) {
System.out.println("----[Exec query for VO=" + voName + ", RS=" +
vrsiName + "]----");
} else {
System.out.println("----[Exec COUNT query for VO=" + voName +
"]----");
}
System.out.println("VODef =" + voDefName);
System.out.println(getQuery());
if (params != null) {
if (getBindingStyle() == SQLBuilder.BINDING_STYLE_ORACLE_NAME) {
StringBuilder binds = new StringBuilder("BindVars:(");
int paramNum = 0;
for (Object param : params) {
paramNum++;
Object[] nameValue = (Object[])param;
String name = (String)nameValue[0];
Object value = nameValue[1];
if (paramNum > 1) {
binds.append(",");
}
binds.append(name).append("=").append(value);
}
binds.append(")");
System.out.println(binds);
}
}
super.bindParametersForCollection(qc, params, stmt);

9.4 複数の行セットと行セット・イテレータの使用

通常はビュー・オブジェクトのデフォルトの行セットを使用しますが、ViewObjectインタフェースのcreateRowSet()メソッドを呼び出して、同じビュー・オブジェクトの問合せに基づく行セットである、二次的な名前付きの行セットを作成できます。こうすることに意味のある状況の1つは、ビュー・オブジェクトのSQL問合せに名前付きバインド変数が含まれる場合です。各RowSetオブジェクトはバインド変数値の独自のコピーを格納するので、単一のビュー・オブジェクトを使用して、異なる組合せのバインド変数値に基づく複数の行セットを生成および処理できます。作成した名前付き行セットは、findRowSet()メソッドを使用して検索できます。セカンダリ行セットの使用が終了したら、closeRowSet()メソッドを呼び出します。

RowSetに対し、通常はデフォルトの行セット・イテレータを使用しますが、RowSetインタフェースのcreateRowSetIterator()メソッドを呼び出して、二次的な名前付きの行セット・イテレータを作成できます。作成した名前付き行セット・イテレータは、findRowSetIterator()メソッドを使用して検索できます。セカンダリ行セット・イテレータの使用が終了したら、closeRowSetIterator()メソッドを呼び出します。

パフォーマンスに関するヒント

結果セットに対してプログラム的に反復を実行する必要があるとき、デフォルトの行セット・イテレータの現在行が妨害されることを避けるために、セカンダリ・イテレータを作成します。たとえば、ADF Modelの宣言的データ・バインディング・レイヤーを通して、アプリケーションのユーザー・インタフェース・ページは、アプリケーション・モジュールのデータ・モデル内にあるビュー・オブジェクトのデフォルト行セットのデフォルト行セット・イテレータと連携します。このシナリオでは、ビュー・オブジェクトのデフォルト行セットに対して反復処理を行うビジネス・ロジックを担当する行セットのセカンダリ・イテレータを作成しない場合、結果的にユーザー・インタフェース・レイヤーによって使用されるデフォルトの行セット・イテレータの現在行が変更されます。

9.5 読取り専用データへのエンティティ・ベースのビュー・オブジェクトの使用方法

一般に、SQLベースの検証のため、およびドロップダウン・リストに有効な選択肢のリストを表示するために使用されるビュー・オブジェクトは、読取り専用でかまいません。アプリケーションに必要な機能の種類を判断し、それに応じてビュー・オブジェクトを設計する必要があります。

ベスト・プラクティス

以前のリリースでは、読取り専用データに関するベスト・プラクティスとして、読取り専用のカスタムSQLビュー・オブジェクトを作成することが推奨されていました。この推奨の意図は、エンティティ・オブジェクト・キャッシュに関連する行を格納するオーバーヘッドを回避することでした。現在は、このベスト・プラクティスを考慮する必要のない、最適化された対処法があります。

現在のリリースの場合、データを参照するために読取り専用ビュー・オブジェクトを作成する必要があるときは、エンティティ・ベースのビュー・オブジェクトを使用し、ビュー・オブジェクトの概要エディタの「エンティティ・オブジェクト」ページで「更新可能」オプションの選択を解除してください。この手法には、2つの利点があります。第一は、SQL問合せの生成に役立つ設計時エディタを利用できることであり、第二は、ビュー・オブジェクトを更新可能にすることにした場合に、すでに更新可能なエンティティ・オブジェクトがその基礎となっていることです。

読取り専用のカスタムSQLビュー・オブジェクトを作成するという、これに替わる方法にも、本格的なSQL問合せを指定できるという利点があり、エンティティ・オブジェクトの使用ではユニオンやグループ化を表現できないような場合に、特に役立ちます。

ビュー・オブジェクトは、基礎になっているエンティティ・オブジェクトに関連付けることも、関連付けないこともできます。ビュー・オブジェクトが基礎になっているエンティティ・オブジェクトと関連付けられていると、デフォルト動作で新しい行の作成、および問合せで得られた行の変更や削除がサポートされます。ただし、更新機能は、エンティティ・ベースのビュー・オブジェクトの概要エディタで「更新可能」の選択を解除して無効にできます(図9-1を参照)。

図9-1 エンティティ・ベースのビュー・オブジェクトでの「更新可能」オプションの選択の解除

かわりの方法として、読取り専用ビュー・オブジェクトを作成し、概要エディタの「問合せ」ページで「カスタムSQLの書込み」を選択して、SQL問合せを定義することもできます。エディタによって問合せ作成作業が簡素化されるため、複雑なSQL文の構築に慣れていないビジネス・コンポーネント開発者にとっては、エンティティ・オブジェクトに基づいて更新不可のビュー・オブジェクトを作成する方が、常に便利です。更新不可に設定したエンティティ・ベースのビュー・オブジェクトは、読取り専用のカスタムSQLビュー・オブジェクトと比べて、次の点で有利です。

- ユーザー・インタフェースに必要とされる属性のみが含まれるように、実行時に選択リストを最適化できます。

- エンティティ・オブジェクトを使用したローカル・キャッシュの作成による、大幅なパフォーマンスの劣化はありません。

- ビュー・オブジェクト内のデータは、読取り操作ごとにデータベースに戻す必要はなく、むしろローカル・キャッシュの状態を表します。

- 定義した別のビュー・オブジェクトで更新不可のビュー・オブジェクトのベース・エンティティ・オブジェクトの更新が必要になっても、ローカル・キャッシュ内のデータは一貫性を維持します。

このため、ビュー・オブジェクト行とエンティティ・オブジェクト行の間の調整には、実行時に若干のオーバーヘッド(概算では5%未満のオーバーヘッド)が生じますが、ビュー・オブジェクト定義を完全に宣言的に維持し、カスタマイズ可能なビュー・オブジェクトをメンテナンスする機能と比較検討してください。カスタムSQLビュー・オブジェクトはカスタマイズ不可ですが、エンティティ・オブジェクトでは表現できないUNIONおよびGROUP BY問合せの実行に使用できます。カスタムSQLビュー・オブジェクトは、ビュー・オブジェクト・ベースのキー存在バリデータによって使用されるSQLベースの検証問合せでも便利です。

データが読取り専用でないとき、最善の(そして唯一の)選択肢はエンティティ・ベースのビュー・オブジェクトを作成することです。更新可能(デフォルト動作)なエンティティ・ベースのビュー・オブジェクトは、エンティティから導出される属性のデフォルト値の取得、同じトランザクション内の他のビュー・オブジェクトを介して関連エンティティ・オブジェクトに行われた保留中の変更の反映、およびエンティティ・ベースのビュー・オブジェクトを使用するために外部キー属性値が変更されたときに更新された参照情報の反映の唯一の方法です。

9.6 異常な問合せを識別するためのSQLトレースの使用方法

ビュー・オブジェクトをエンティティにマップするかどうかを決定した後は、次に問合せ自体に注目します。ビュー・オブジェクトの概要エディタの「問合せ」ページで、「テストおよび説明」ボタンをクリックし、データベースの問合せオプティマイザで使用される問合せ計画を表示します。計画が全表スキャンを行っている場合は、索引を追加するか、または概要エディタの「一般」ページの「チューニング」セクションで、「問合せオプティマイザ・ヒント」フィールドの値を指定することを検討する必要があります。これにより、使用される問合せ計画を明示的に制御できます。これらの機能は、個別のビュー・オブジェクトSQL文について問合せ計画を評価するための便利なツールを開発者に提供します。ただし、これらのツールの使用は、本番環境のデータ量とエンド・ユーザー数においてパフォーマンスの悪い問合せを識別するための、アプリケーション全体のSQLのトレースにかわるものではありません。

OracleデータベースのSQLトレース機能を使用すると、アプリケーションが実行する全SQL文の完全なログが生成されます。すべてのバージョンのOracleデータベースで動作する方法としては、次のコマンドを発行します。

ALTER SESSION SET SQL_TRACE TRUE

特にOracle 10gでは、このコマンドを実行するために、DBAはALTER SESSION権限を付与する必要があります。

このコマンドを実行すると、現在のデータベース・セッションのトレースが有効になり、ALTER SESSION SET SQL_TRACE FALSEを入力するまで、または接続を閉じるまで、すべてのSQL文がサーバー側のトレース・ファイルに記録されます。このオプションの有効化を簡単にしてFusion Webアプリケーションをトレースするには、次の例に示すように、アプリケーション・モジュール(またはカスタム・アプリケーション・モジュール・フレームワーク拡張クラス)のafterConnect()メソッドをオーバーライドし、Javaシステム・プロパティが存在するかどうかに基づいて、条件付きでALTER SESSIONコマンドを実行してSQLトレースを有効にします。

// In YourCustomApplicationModuleImpl.java
protected void afterConnect() {
super.afterConnect();
if (System.getProperty("enableTrace") != null) {
getDBTransaction().executeCommand("ALTER SESSION SET SQL_TRACE TRUE");
}
}

トレース・ファイルを生成した後は、データベースに付属するTKPROFユーティリティを使用して情報を書式設定することで、次のように実行された各問合せに関する情報を理解しやすくなります。

- (再)解析された回数

- 実行された回数

- アプリケーション・サーバーとデータベースの間で行われたラウンドトリップの回数

- 問合せの実行時間に関する様々な定量的測定値

これらの手法を使用することで、アプリケーションが実行する特定の問合せの時間を短縮するために必要な追加索引や、問合せ最適化計画を改善するために変更できる問合せを判断できます。TKPROFユーティリティでの作業の詳細は、「アプリケーション・トレースの実行」、SQLトレースとTKPROFの理解に関する項およびSQLトレース機能とTKPROFの使用に関する項を参照してください。

注意:

Oracleデータベースが提供するDBMS_MONITORパッケージでは、SQLトレースがさらに簡単になっており、Oracle Enterprise Managerと統合してアプリケーションが最も頻繁に実行する問合せ文を視覚的にモニタリングできます。

9.7 適切なビュー・オブジェクト・チューニング設定の使用方法

ビュー・オブジェクトの概要エディタの「一般」ページの「チューニング」セクションでは、問合せのパフォーマンスに劇的な影響を与える可能性のある様々なオプションを設定できます。図9-2に、新しいビュー・オブジェクトで定義されているデフォルトのオプションを示します。

図9-2 ビュー・オブジェクトのデフォルト・チューニング・オプション

9.7.1 「データベースから取得」オプションに関する必知事項

ビュー・オブジェクトの概要エディタの「一般」ページにある、「データベースから取得」グループ・ボックスは、ビュー・オブジェクトがデータベース・サーバーから行を取得する方法を制御します。フェッチ・モードのオプションは、「すべての行」、「行番号までのみ」、「最大で1行」および「行なし」です。ほとんどのビュー・オブジェクトはデフォルトの「すべての行」オプションを使用し、「必要に応じて」(デフォルト)または「一度にすべて」のいずれか選択されているオプションに従って取得されます。

注意:

「同時」オプションでは、ビュー・オブジェクト問合せで指定された行をフェッチするためのデータベース・ラウンドトリップを一切強制しません。「必要に応じて」および「同時」オプションは、「バッチ」(フェッチ・サイズとも呼ばれます)の値と連携して、ラウンドトリップ数を決定します。データベース・アクセスのパフォーマンスを最高に保つには、「一度に1行のフェッチが適切かどうかの検討」の説明に従ってフェッチ・サイズを変更することを検討してください。

「必要に応じて」オプションを指定すると、ビュー・オブジェクトでのexecuteQuery()操作は最初に、表示する最初のページに必要な数の行のみを取得します。この行数は、ビュー・オブジェクトの範囲サイズに基づいて設定されます。「必要に応じて」を使用する場合、最初の範囲サイズ(「レンジ・サイズ」オプションで定義される)で指定された行数を取得するために必要な回数だけ、データベース・ラウンドトリップが要求されます。「同時」を使用する場合、アプリケーションでは、「バッチ」(フェッチ・サイズ)の値と問合せによって識別された行数に基づいて、すべての行を取得するために必要な回数のラウンドトリップが実行されます。

WHERE句が単一の行を取得すると予想されるビュー・オブジェクトの場合は、オプションを「最大で1行」に設定すると最良のパフォーマンスが得られます。このオプションを指定すると、ビュー・オブジェクトはユーザーがそれ以上の行を期待していないことを認識し、さらに行がある場合に通常行うテストをスキップします。最後に、ビュー・オブジェクトを新規行の作成のみを目的として使用する場合は、最適なパフォーマンスを得るために、このオプションを「行なし」に設定すると、問合せは実行されなくなります。

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトについて」を参照してください。

行オブジェクトの行フェッチ・オプションを設定するには:

1. 「アプリケーション」ウィンドウで、編集するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックし、「チューニング」セクションを開きます。

3. 「データベースから取得」グループ・ボックスで、データベースからフェッチする行数を制御するオプションを選択します。

4. ビュー・オブジェクトの問合せを最適化するためにデータベースで使用される、「問合せオプティマイザ・ヒント」を入力します。
実行時、このヒントは問合せのSELECTキーワードの直後に追加されます。たとえば、すべての行をできるだけ迅速に取得する必要がある場合は、ALL_ROWSと入力します。また、(すべての行の取得を最適化しないで)最初の行をできるだけ迅速に取得する場合は、FIRST_ROWSと入力します。

9.7.2 一度に1行のフェッチが適切かどうかの検討

フェッチ・サイズは、データベースへの各ラウンドトリップで返される行数を制御します。デフォルトでは、フレームワークは一度に1行のバッチで行をフェッチします。複数の行をフェッチする場合、ビュー・オブジェクト概要エディタの「一般」ページの「チューニング」セクションにあるこの「次の単位で」の値を設定して効率を上げます。

本当に1行のみフェッチするのでないかぎり、「次の単位で」フィールドをデフォルトのフェッチ・サイズである1のままにしておくことはお薦めしません。これは、アプリケーション・サーバーとデータベースの間で必要以上に多くのラウンドトリップが発生するためです。各ビュー・オブジェクトのフェッチ・サイズに適した値を検討することを強くお薦めします。

ユーザー・インタフェースで一度にn行の結果を表示する場合は、簡単なWebページでは、データベースへの1回のラウンドトリップで各ページの結果を取得できるよう、フェッチ・サイズを少なくともn+3に設定するのがよい方法です。ただし、この値を大きくすると、クライアント側で必要なバッファが大きくなるため、この数を、Oracle JDBCフェッチ・サイズの推奨を超える値に設定しないでください。

通常、フェッチ・サイズはOracleデータベース12cの推奨事項と一致している必要があります。つまり、フェッチ・サイズが100程度であっても、場合によってはそれよりも大きなサイズが適切になります。詳細は、Oracle Database 12cの『Oracle JDBC Memory Management』(http://www.oracle.com/technetwork/database/application-development/jdbc-memory-management-12c-1964666.pdf)を参照してください。

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトについて」を参照してください。

ビュー・オブジェクトのデータベース・ラウンドトリップ数を制限するには:

1. 「アプリケーション」ウィンドウで、編集するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックし、「チューニング」セクションを開きます。

3. 「データベースから取得」グループ・ボックスで、「すべての行」または「行番号までのみ」を選択します。

4. 「次の単位で」フィールドに、各データベース・ラウンドトリップで返す行数を入力します。

5. フェッチされた行数が行セットを表示するWebページに収まるかどうかに関係なく、すべての行をフェッチする場合は、オプション「一度にすべて」を選択します。そうではなく、行セットを表示するWebページの最初のページを埋めるために必要な行数のみをフェッチする場合は、デフォルト設定である「必要に応じて」のままにします。
「一度にすべて」を選択する場合、アプリケーションでは、「次の単位で」(フェッチ・サイズ)の値と問合せによって特定された行数に基づいて、すべての行を取得するために必要な回数のラウンドトリップが実行されます。

9.7.3 必要に応じた問合せオプティマイザ・ヒントの指定

「問合せオプティマイザ・ヒント」フィールドでは、Oracle問合せオプティマイザに対するオプションのヒントを指定して、使用される実行計画に影響を与えることができます。図9-2に示すように、このヒントは、ビュー・オブジェクトの概要エディタの「チューニング」ページで設定することができます。

実行時には、指定したヒントが問合せのSELECTキーワードの直後に追加され、特殊なコマンド構文/*+ YOUR_HINT */でラップされます。一般的な2つのオプティマイザ・ヒントを次に示します。

- FIRST_ROWS - できるかぎり早く最初の行を取得することを示します。

- ALL_ROWS - できるかぎり早くすべての行を取得することを示します。

他にも多くのオプティマイザ・ヒントがありますが、このマニュアルの範囲からは外れます。使用できるヒントの詳細は、Oracleのデータベース・リファレンス・マニュアルを参照してください。

始める前に:

ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトについて」を参照してください。

ビュー・オブジェクト定義を編集するには:

1. 「アプリケーション」ウィンドウで、編集するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックし、「チューニング」セクションを開きます。

3. 「データベースから取得」グループ・ボックスで、データベースからフェッチする行数を制御するオプションを選択します。

4. ビュー・オブジェクトの問合せを最適化するためにデータベースで使用される、「問合せオプティマイザ・ヒント」を入力します。
実行時、このヒントは問合せのSELECTキーワードの直後に追加されます。たとえば、すべての行をできるだけ迅速に取得する必要がある場合は、ALL_ROWSと入力します。また、(すべての行の取得を最適化しないで)最初の行をできるだけ迅速に取得する場合は、FIRST_ROWSと入力します。

9.8 ビュー・オブジェクトの最大フェッチ・レコード数を制限するためのフェッチ・サイズの使用方法

アプリケーションでビュー・オブジェクトの問合せ結果行を反復処理する必要がある場合は、フェッチするレコードの最大数を指定することをお薦めします。ビュー・オブジェクトのデフォルトの最大フェッチ・サイズは-1で、フェッチできる行数に制限がないことを示します。デフォルトでは、行は必要に応じてフェッチされるので、-1という値はビュー・オブジェクトがすべての行をフェッチする必要があることを意味するわけではありません。問合せ結果のすべての行を反復処理しようとした場合に、すべての行が取得されることを意味しているにすぎません。

ビュー・オブジェクトで取得される行の最大数に上限を設けるには、次の設定を使用します。

- adf-config.xmlファイルの概要エディタの「ビジネス・コンポーネント」ページで、「行フェッチ制限」プロパティを使用して、すべてのビュー・オブジェクト問合せのグローバルしきい値を構成できます。このファイルは、「アプリケーション・リソース」パネルで「ディスクリプタ」および「ADF META-INF」ノードを開いて特定できます。
注意: 行フェッチ制限ではそのアプリケーションのすべての問合せ操作のグローバルしきい値が指定されるため(イテレータ結果セットの予測行カウントを決定するイテレータ・バインディング・プロパティRowCountThresholdを含む)、このプロパティを使用すると、その操作のデフォルト動作ではすべての行をフェッチできる場合に、個々の問合せ操作の設定を変更しなくて済みます。個々のビュー・オブジェクトに「最大フェッチ・サイズ」を使用してフェッチ制限を指定する場合、「行フェッチ制限」の設定は無視されます。ビュー・オブジェクトに適した値を返すようにビュー・オブジェクトの実装クラスでgetRowLimit()をオーバーライドする場合は、「行フェッチ制限」の設定も無視されます。

- ビュー・オブジェクトの概要エディタの「一般」ページにある「チューニング」セクションで、「行番号までのみ」フィールドを選択すると、特定のビュー・オブジェクト問合せのしきい値を構成できます。プロパティ・インスペクタでは、この設定が「最大フェッチ・サイズ」プロパティに表示されることに注意してください。

ヒント:

「行フェッチ制限」を使用して問合せ操作のグローバルしきい値を設定する際、特定のビュー・オブジェクト問合せで使用可能なすべての行が戻されるようにする場合は、該当するビュー・オブジェクトの「行番号までのみ」フィールドを非常に大きい数値にして「最大フェッチ・サイズ」を設定できます。

たとえば、ORDER BY句を含む問合せを作成し、ページに上位N項目を表示するために最初のn行を返す場合は、ビュー・オブジェクトの概要エディタを使用して、「一般」ページの「チューニング」セクションにある「行番号までのみ」フィールドの値を指定できます。たとえば、最初の5行のみをフェッチするには、このフィールドに5を入力します。これは、ビュー・オブジェクトでsetMaxFetchSize()メソッドをコールして最大フェッチ・サイズを5に設定するのと同じです。ビュー・オブジェクトは、最大フェッチ・サイズに達すると行のフェッチを停止します。通常は、この手法と組み合せて、概要エディタの「一般」ページの「チューニング」セクションで、FIRST_ROWSの「問合せオプティマイザ・ヒント」も指定します。これにより、すべての行の取得の最適化を試みるのではなく、できるかぎり早く最初の何行かを取得するよう、データベースにヒントが提供されます。

9.9 範囲サイズを使用したページ単位でのデータの提示およびスクロール

1ページずつデータを提示およびスクロールするために、適切なサイズの行範囲がビュー・オブジェクトで管理されるように構成できます。範囲機能を使用すると、クライアントは、行セット内の行のサブセットを簡単に表示および更新でき、一度にn行ずつ簡単に後のページにスクロールできます。1ページに表示するデータの行数を定義するには、setRangeSize()を呼び出します。デフォルトの範囲サイズは1行です。-1という範囲サイズは、範囲が行セットのすべての行を含むことを示します。

注意:

ADFモデル・レイヤーの宣言的バインディングを使用する場合、ページ定義ファイルのイテレータ・バインディングにRangeSize属性があります。実行時に、イテレータ・バインディングは対応する行セット・イテレータでsetRangeSize()メソッドを呼び出し、このRangeSize属性の値を渡します。ADFの設計時には、デフォルトで、ほとんどのイテレータ・バインディングについて、RangeSize属性に10行が設定されます。例外は、ドロップダウン・リストなどのUIコンポーネントに対する有効値の設定を提供するリスト・バインディングに指定される範囲サイズです。この場合は、デフォルトの範囲サイズは-1であり、範囲は行セットのすべての行を含むことができます。

1より大きい範囲サイズを設定するときは、イテレータ・モードを使用して行セットのページ移動動作を制御します。次の2つのイテレータ・モード・フラグを、setIterMode()メソッドに渡すことができます。

- RowIterator.ITER_MODE_LAST_PAGE_PARTIAL
このモードでは、最終ページに含まれる行数は、範囲サイズより少なくてもかまいません。たとえば、範囲サイズを10に設定し、行セットに23行が含まれる場合は、3ページ目には3行のみ含まれます。これは、Fusion Webアプリケーションに対して最善のスタイルです。

- RowIterator.ITER_MODE_LAST_PAGE_FULL
このモードでは、最終ページにも1ページ分の行数が表示され、前のページの下部に表示されていた行が、最後のページの上部に表示される場合があります。たとえば、範囲サイズを10に設定し、行セットに23行が含まれる場合は、3ページ目にも10行が表示され、3ページ目の最初から7行には、2ページ目の最後の7行が表示されます。これは、Swingを使用するデスクトップ・フィデリティ・アプリケーションに最適なスタイルです。

9.10 大きい結果セットを効率的にスクロールするための範囲ページ移動の使用方法

一般的な規則として、パフォーマンスを最高にするため、非常に大きな問合せ結果をエンド・ユーザーがスクロールすることがないような方法でアプリケーションを作成することをお薦めします。この推奨事項を実現するには、実際に問合せを実行してユーザーが操作を継続できるようにする前に、ビュー・オブジェクトでgetEstimatedRowCount()メソッドを呼び出して、ユーザーの問合せで返される行数を判定します。推定される行カウントが不当に大きい場合は、さらに検索基準を提供するようエンド・ユーザーに要求できます。

ただし、非常に大きな結果セット(通常、100行超)を処理する必要がある場合は、範囲ページ移動と呼ばれるビュー・オブジェクトのアクセス・モードを使用して、パフォーマンスを向上することができます。この機能を使用すると、大きなデータ・セットについてデフォルトのスクロール可能アクセス・モードより効率的な方法で、一度にある行範囲のページ単位で、前方および後方にデータを移動できます。

範囲ページ移動アクセス・モードは、通常、読取り専用行セットのページ移動に使用され、読取り専用ビュー・オブジェクトで使用されるのが普通です。ユーザーは範囲ページ移動アクセス・モードを使用し、大きな行セットをページ移動して対象行を検出できます。その後、その行のKeyを使用し、編集用に別のビュー・オブジェクトで選択されている行を検索できます。

ビュー・オブジェクトの場合の範囲ページ移動は、標準アクセス・モードと、範囲ページ移動と結果セット・スクロールの利点を組み合せてデータベース・アクセス回数を最小限に抑える標準アクセス・モードのバリエーションをサポートしています。次に、ビュー・オブジェクト範囲ページ移動機能のこれらのモードについて説明します。

- RANGE_PAGING: 標準アクセス・モードで、範囲サイズで指定された行数をフェッチします。このモードでは、データベースに再問合せを行わずにスクロールできる行数は、設定した範囲サイズで決まります。デフォルトでは1行をフェッチしますが、範囲サイズは、ユーザーが次の結果セットまでスクロールせずに表示できる行数と同じ数に設定するものと想定されています。エンド・ユーザーが範囲外の行にアクセスするたびに、アプリケーションはデータベースに再問合せを行います。このため、行セットを前後にスクロールすると、データベースに再問合せが行われます。このデータベース中心のページ移動方針の説明は、「上位N問合せのサポート方法の理解」を参照してください。

- RANGE_PAGING_INCR: インクリメンタル・アクセス・モードを使用して、一度に表示できる行数をUI設計者がより柔軟に決定でき、データベース問合せ回数も最小限に抑えます。このモードでは、UIは結果セットをメモリー・キャッシュから逐次表示するため、スクロールは1回のデータベース問合せの範囲内でサポートします。エンド・ユーザーが1回の問合せでスクロールできる行数は、範囲サイズと、設定した範囲ページ移動キャッシュ・ファクタによって決まります。たとえば、範囲サイズを4、キャッシュ・ファクタを5に設定したとします。この場合、メモリーにキャッシュする最大行数は、4*5 = 20です。キャッシュの動作の詳細は、「範囲ページ移動を使用するときのビュー行のキャッシュ時の処理」を参照してください。

注意:

さらに、ビュー・オブジェクトは、行セットの行の挿入と削除に対応するために、RANGE_PAGING_AUTO_POSTアクセス・モードをサポートします。このモードはRANGE_PAGINGモードと同じように動作しますが、行セットに対してなんらかの変更が行われたときには常に、データベース・トランザクションでpostChanges()を呼び出すところが異なります。ただし、このモードは通常、同一のHTTPリクエスト内でのトランザクションのコミットまたはロールバックが必ず実行される場合を除き、Fusion Webアプリケーションでの使用には適していません。使用した場合、複数の異なるクライアントにより、アプリケーション・モジュールとデータベース接続の両方がプールされ、シリアルに共有されるという事態が環境内で発生する可能性があります。

9.10.1 上位N問合せのサポート方法の理解

Oracleデータベースは、問合せで順序付けされた最初のn行を効率よく返すための、上位N問合せと呼ばれる機能をサポートします。たとえば、次のような問合せがあるものとします。

SELECT EMPNO, ENAME,SAL FROM EMP ORDER BY SAL DESC

給与順に上位5人の従業員を取得する場合は、問合せを次のように記述できます。

SELECT * FROM (
SELECT X.*,ROWNUM AS RN FROM (
SELECT EMPNO,ENAME,SAL FROM EMP ORDER BY SAL DESC
) X
) WHERE RN <= 5

結果は次のようになります。

EMPNO ENAME       SAL   RN
---------- -------- ------ ----
7839 KING       5000    1
7788 SCOTT      3000    2
7902 FORD       3000    3
7566 JONES      2975    4
7698 BLAKE      2850    5

この機能は、順番に先頭のn行を取得できるだけではありません。一番外側のWHERE句の基準を調節することにより、問合せのソートされた順序で任意の範囲の行を効率よく取得できます。たとえば、問合せを次のように変更することで、6行目から10行目までを取得できます。

SELECT * FROM (
SELECT X.*,ROWNUM AS RN FROM  (
SELECT EMPNO,ENAME,SAL FROM EMP ORDER BY SAL DESC
) X
) WHERE RN BETWEEN 6 AND 10

この考え方を一般化して、問合せ結果のPページ目を見たい場合は、1ページがR行であるとすると、次のような問合せを作成します。

SELECT * FROM (
SELECT X.*,ROWNUM AS RN FROM (
SELECT EMPNO,ENAME,SAL FROM EMP ORDER BY SAL DESC
) X
) WHERE RN BETWEEN ((:P - 1) * :R) + 1 AND (:P) * :R

考えられる結果セットがより大きくなる場合、この手法を使用したページ移動の効率がさらに上がります。何百または何千もの行をデータベースからネットワーク経由で取得し、そのうちの10行のみをページに表示するかわりに、Pページ目のR行のみをデータベースから取得する賢明な問合せを作成できます。この方法を使用すると、ネットワーク経由で返す必要のある行数はほんのわずかで済みます。

このデータベース中心のページ移動方法をアプリケーションで実装するには、適切な問合せを自分で作成し、バインド変数:Rおよび:Pの適切な値を管理するコードを記述する必要があります。または、ビュー・オブジェクトの範囲ページ移動アクセス・モードを使用すると、このような機能が自動的に実装されます。

9.10.2 ビュー・オブジェクトの範囲ページ移動を有効にする方法

ビュー・オブジェクトの概要エディタの「チューニング」パネルを使用して、アクセス・モードを、標準の範囲ページ移動とインクリメンタル範囲ページ移動のいずれかに設定できます。「範囲ページング・インクリメンタル」を選択すると、「範囲ページング・キャッシュ・ファクタ」フィールドは編集のみ可能になります。図9-3に、ビュー・オブジェクトのアクセス・モードを示します。「範囲ページング」(標準モード)に設定されており、範囲サイズはデフォルトの1です。2つのアクセス・モードでの行セット・キャッシュの動作の詳細は、「範囲ページ移動を使用するときのビュー行のキャッシュ時の処理」を参照してください。

図9-3 ビュー・オブジェクトの概要エディタのアクセス・モード

ビュー・オブジェクトの標準範囲ページ移動をプログラム的に有効にするには、最初にsetRangeSize()をコールして1ページの行数を定義した後、必要に応じていずれかのモードで次のメソッドをコールします。

yourViewObject.setAccessMode(RowSet.RANGE_PAGING | RANGE_PAGING_INCR);

RANGE_PAGING_INCRを設定した場合、次のメソッドもコールして、定義済の範囲サイズに対してキャッシュ・ファクタを設定する必要があります。

yourViewObject.setRangePagingCacheFactor(int f);

9.10.3 範囲ページ移動を有効にしたときに行われる処理

ビュー・オブジェクトのアクセス・モードをRANGE_PAGINGに設定すると、ビュー・オブジェクトは次のような問合せをデフォルトとして使用します。

SELECT EMPNO, ENAME, SAL FROM EMP ORDER BY SAL DESC

そして、これを自動的にラップし、上位N問合せを生成します。

最善のパフォーマンスのため、文ではBETWEEN演算子のかわりに、より大と、より小の基準の組合せが使用されますが、論理的な結果は、先に示した上位Nのラッピングの問合せと同じになります。基本になる問合せは次のようなものです。

SELECT EMPNO, ENAME, SAL FROM EMP ORDER BY SAL DESC

これがラップされて、実際には次のような問合せが生成されます。

SELECT * FROM (
SELECT /*+ FIRST_ROWS */ IQ.*, ROWNUM AS Z_R_N FROM (
SELECT EMPNO, ENAME, SAL FROM EMP ORDER BY SAL DESC
) IQ  WHERE ROWNUM < :0)
WHERE Z_R_N > :1

2つのバインド変数は、次のようにバインドされます。

- :1は、現在のページの先頭行のインデックスです。

- :0は、現在のページの最終行にバインドされます。

9.10.4 範囲ページ移動を使用するときのビュー行のキャッシュ時の処理

ビュー・オブジェクトがRANGE_PAGINGアクセス・モードで動作するとき、ビュー行キャッシュのメモリー内に一度に保持するのは、現在の行範囲(つまりページ)のみです。つまり、一度に10ずつ結果をページ移動する場合、最初のページでは、1から10行がビュー行キャッシュに保持されます。2ページ目に移動すると、キャッシュには11から20行が格納されます。これは、大きな行セットの場合に、単に前後にスクロールできるようにするという理由で大量の行がキャッシュされないようにするためにも役立ちます。

ビュー・オブジェクトがRANGE_PAGING_INCRアクセス・モードで動作するとき、特定の範囲サイズに対して、メモリーにキャッシュする行数は、キャッシュ・ファクタにより決まります。たとえば、範囲サイズを4、キャッシュ・ファクタを5に設定したとします。この場合、メモリーはコレクション中に最大4*5 = 20行を保持します。この例では、範囲が初めてリフレッシュされるとき、範囲ページ移動の問合せが行0 - 19(合計20行)を取得するためにバインドされていても、メモリーには4行のみが保持されます。範囲が4行目を過ぎてスクロールされると、より多くの行が現在の結果セットから読み込まれます。これが、20行すべてが問合せ結果から読み込まれるまで続きます。ユーザーのアクションにより次の行セットが取得される場合、新しい行番号バインド値で問合せが再実行されます。正確な行番号バインド値は、新しい範囲開始位置とキャッシュに保持できる行数で決まります。たとえば、20行すべてにデータが入っており、ユーザーが範囲開始位置を18 (0ベース)に移動するよう指示していると想定します。これは、メモリーが行18と行19を保持でき、範囲を満たすためにはあと2行必要であることを意味します。行20および21に対して問合せが再実行されます。

9.10.5 範囲ページ移動を使用して特定のページ番号にスクロールする方法

ビュー・オブジェクトがRANGE_PAGINGアクセス・モードで動作しているときに、ページ番号nにスクロールするには、scrollToRangePage()メソッドを呼び出し、パラメータ値としてnを渡します。

9.10.6 範囲ページ移動を使用するときの行セット内のページ数の推定方法

ビュー・オブジェクトがRANGE_PAGINGアクセス・モードで動作している場合、問合せ結果全体が生成する総ページ数の推定は、getEstimatedRangePageCount()メソッドを使用して取得できます。

9.10.7 範囲ページ移動モードを使用するときのトレードオフ

常にRANGE_PAGINGまたはRANGE_PAGING_INCRモードを使用すればよい、というわけではありません。それは、範囲ページ移動を使用すると、ビュー・オブジェクトの行を前後に移動したときに実行される問合せの総量が増加する可能性があるためです。次のような状況では、RANGE_PAGINGモードの使用を避ける必要があります。

- 行セットのすべての行をただちに読み取ろうと考えている場合(たとえば、ドロップダウン・リストに移入するため)。
この場合は、範囲サイズを-1に設定し、すべての行を含む単一のページのみが存在するため、範囲ページ移動のメリットはなくなります。

- 小さいサイズの行セットで前後にページ移動する必要がある場合。
行数が100以下で、RANGE_PAGINGモードを使用して10行ずつページ移動する場合、前後の新しいページに移動するために問合せが実行されます。デフォルトのスクロール可能モードでは、読み取ったビュー・オブジェクト行はキャッシュされ、前のページに戻る方向にページ移動しても、すでに表示された行を表示するために再び問合せが実行されることはありません。別の方法として、RANGE_PAGING_INCRモードを使用して、指定した行セット・キャッシュ・ファクタに基づいてメモリー内の結果をスクロールできるようにすることもできます。

非常に大きい(または予想不可能な大きさの)行セットの場合、問合せ(それぞれで、データベースから最大でRangeSizeの数だけ行が戻される)の実行回数が多少増える可能性があるというトレードオフは、表示済の行をすべてキャッシュすることに比べれば効率的です。結果のリストの任意のページにジャンプできるようにする場合は、このことが特に顕著です。デフォルトのスクロール可能モードでこれを行うには、現在のページとジャンプ先のページの間にあるすべての行をフェッチしてキャッシュする必要があります。RANGE_PAGINGモードでは、そのページの行をデータベースに要求するのみです。その後、ユーザーがすでに移動したことのあるページの行へ戻る場合、RANGE_PAGINGモードでは現在のページの行のみがメモリー内に保持されているため、これらの行は再度問合せる必要があります。このインクリメンタル範囲ページ移動アクセス・モード、RANGE_PAGING_INCRでは、標準の範囲ページ移動とスクロール可能アクセス・モードの両方の側面が組み合されています。アプリケーションはより多くの行をメモリーにキャッシュでき、ユーザーは再問合せする必要もなく、それらの行の任意の組合せにジャンプできます。

9.11 ビュー行のキャッシュを避ける前方のみモードの使用方法

ビュー・オブジェクトの結果をプログラムで反復処理するコードを作成することがよくあります。よくある状況は、問合せ結果の複数の行を処理して属性またはエンティティが有効かどうかを判定する必要があるカスタム検証コードです。このような場合、行セット内の各行を1回のみ読み取り、戻る方向にスクロールしたり、後で行セットを再び反復処理したりする必要がない場合は、前方のみモードを使用することで、取得した行のキャッシュを回避できます。前方のみモードを有効にするには、ビュー・オブジェクトでsetForwardOnly(true)を呼び出します。

注意:

前方のみモードで読取り専用ビュー・オブジェクト(エンティティ・オブジェクトの慣用名がない)を使用し、フェッチ・サイズを適切にチューニングするのが、データをプログラムで読み取る最も効率のよい方法です。

また、行セットを後方にスクロールすることがなく、reset()を呼び出してイテレータを最初の行に設定することがない場合は、データを挿入、更新、または削除するときにも、前方のみモードを使用することで行のキャッシュを避けることができます。前方のみモードは、範囲サイズが1の場合にのみ機能します。

9.12 「行セットの保存」を使用したビュー・リンク・アクセッサのアクセスの最適化

デフォルトでは、ビュー・リンク・アクセッサの行セットを取得するたびに、ビュー・オブジェクトによって新しいRowSetオブジェクトが作成され、ユーザーが行を操作できるようにします。これは、そのたびに問合せを再実行して結果を生成するという意味ではなく、RowSetオブジェクトの新しいインスタンスを作成してデフォルトのイテレータを先頭行の前のスロットにリセットするだけです。行セットをデータベースの行で強制的に更新するには、executeQuery()メソッドを呼び出します。

新しいディテール行セット作成に関連する若干のオーバーヘッドがアプリケーションで発生しないようにする場合は、ビュー・リンク・アクセッサ行セットのキャッシュを有効にできます。たとえば、ビュー・アクセッサ行セットは、マスター行ビュー・アクセッサ属性が変更されないかぎりは安定した状態を維持し、ツリー・コントロール(ツリー内の各マスター・ノードのデータが個別のディテール行セットを維持する必要がある)のようなUIコンポーネントの行セットを再作成する必要がありません。ビュー・リンク・アクセッサのディテール行セットにプログラムでアクセスすることもできます。この場合、アプリケーションで同じビュー・リンク・アクセッサ属性に対して多数のコールを行うときに、ビュー・リンク・アクセッサ行セットのキャッシングを検討できます。マスター/ディテール関係の管理のスタイルは、データ・モデルでのビュー・リンク・インスタンス作成とは異なります(「ビュー・リンク・アクセッサとデータ・モデル・ビュー・リンク・インスタンスの相違に関する必知事項」を参照)。

ビュー・リンク・アクセッサのソースであるビュー・オブジェクトについて、概要エディタを使用してビュー・リンク・アクセッサ行セットの保存を有効にできます。ビュー・オブジェクトの概要エディタの「ビュー・アクセッサ」ページで、「行セットの保存」を選択します。

かわりに、ビュー・オブジェクトでカスタムJavaクラスを有効にし、create()メソッドをオーバーライドして、パラメータとしてtrueを渡して、setViewLinkAccessorRetained()メソッドを呼び出す行を、super.create()の後に追加できます。これは、そのビュー・オブジェクトのすべてのビュー・リンク・アクセッサ属性に適用されます。

ビュー・オブジェクトに対してこの機能を有効にすると、ビュー・リンク・アクセッサの行セットが毎回再作成されないため、デフォルトの行セット・イテレータの現在行も維持されるという副作用があります。つまり、デフォルト行セット・イテレータの現在行をリセットして先頭行の前のスロットに戻すには、ビュー・リンク・アクセッサから取得した行セットに対して、reset()メソッドを明示的に呼び出す必要があります。

ただし、アクセッサの保持を有効にすると、アクセッサ行セットの行を反復処理する前にいつでもreset()を呼び出すようにしないと、微妙で検出が困難なエラーがアプリケーションで発生する可能性があることに注意してください。たとえば、ビュー・リンク・アクセッサの行セットの行を次のようにして反復処理し、合計を計算するものとします。

RowSet rs = (RowSet)row.getAttribute("OrdersShippedToPurchaser");
while (rs.hasNext()) {
Row r = rs.next();
// Do something important with attributes in each row
}

アクセッサ行セットを最初に処理するときには、このコードは正しく動作します。しかし、行セット(およびそのデフォルトの行セット・イテレータ)が保持されるため、2回目以降の行セットへのアクセスでは、現在行はすでに行セットの末尾にあり、rs.hasNext()がfalseになるためwhileループはスキップされます。この機能を有効にする場合は、アクセッサの反復コードは次のように記述する必要があります。

RowSet rs = (RowSet)row.getAttribute("OrdersShippedToPurchaser");
rs.reset(); // Reset default row set iterator to slot before first row!
while (rs.hasNext()) {
Row r = rs.next();
// Do something important with attributes in each row
}

ビュー・リンク一貫性が有効になっている場合は、アクセッサが保持されると、ポストされていない新しい行は行セットの最後に表示されます。これは、アクセッサが保持されない(デフォルト)場合と若干異なり、アクセッサが保持されないときは、ポストされていない新しい行は、アクセッサの行セットの先頭に表示されます。

9.13 UIの状態を格納するためのビュー・オブジェクトでの動的属性の使用方法

addDynamicAttribute()メソッドを使用すると、実行時に1つまたは複数の動的属性をビュー・オブジェクトに追加できます。動的属性は、値として任意のシリアライズ可能オブジェクトを保持できます。通常は、グローバルで汎用的な方法でフレームワークに追加する機能を実装するために、行ごとに追加の一時的な状態を格納する必要がある、汎用のフレームワーク拡張コードを作成するときに、動的属性の使用を検討します。

10 ビュー・オブジェクトのプログラムによる操作

この章では、Oracle ADFアプリケーションでADFビュー・オブジェクトを設計および利用するときに使用できる、ADFビジネス・コンポーネントAPIのプログラムによる使用方法について説明します。

この章の内容は次のとおりです。

- ビュー・オブジェクトのカスタムJavaクラスの生成

- 複数の名前付きビュー基準のプログラム的処理

- 行セットのメモリー内でのソート処理とフィルタ処理の実行

- XMLの読取りと書込み

- カスタム・データ・ソースおよびFramework Base Class ProgrammaticViewObjectImplを使用したプログラム的操作

- 代替データ・ソースに対するクラシック・スタイル・プログラムでのビュー・オブジェクトの使用

- 複数の更新可能エンティティによるビュー・オブジェクトの作成

- プログラムによるビュー定義とビュー・オブジェクトの作成

- 挿入、更新および削除の宣言による禁止

10.1 ビュー・オブジェクトのカスタムJavaクラスの生成

前述したとおり、ビュー・オブジェクトの基本的な問合せ機能はすべて、カスタムJavaコードを使用せずに実行できます。クライアントは、ビュー・オブジェクト開発者の役割でカスタム・コードを実行しなくても、SQL問合せのデータを取得して繰り返すことができます。要するに、多くのビュー・オブジェクトでは、SQL文を定義すればそれで完了です。ただし、必要になった場合に備えて、ビュー・オブジェクトでのカスタムJava生成を有効化する方法を理解しておくことが重要です。たとえば、カスタムJavaクラスでコードを作成する理由には次のようなものがあります。

- 検証メソッドを追加するため(ただし、Groovyスクリプトの式でサポートされているため、それを使用すればJavaは不要)

- カスタム・ロジックを追加するため

- 組込み動作を拡張するため

通常、カスタム・ビュー・オブジェクトおよびビュー行クラスで記述、使用およびオーバーライドする一般的なコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

10.1.1 カスタム・クラスの生成方法

ビュー・オブジェクトのカスタムJavaクラスの生成を有効にするには、ビュー・オブジェクトの概要エディタの「Java」ページを使用します。図10-1に示すように、ビュー・オブジェクトに関連付けることができるオプションのJavaクラスが3つあります。リストの初めの2つは、非常によく使用されます。

- 問合せを実行し、実行のライフサイクルを制御するコンポーネントを表すビュー・オブジェクト・クラス

- 問合せ結果の各行を表すビュー行クラス

図10-1 ビュー・オブジェクトのカスタムJava生成オプション

10.1.1.1 バインド変数アクセッサの生成

カスタム・ビュー・オブジェクト・クラスの生成を有効にする場合、図10-1に示すように「バインド変数アクセッサを含める」チェック・ボックスも選択すると、JDeveloperによりビュー・オブジェクト・クラスにgetterメソッドおよびsetterメソッドが生成されます。ProductViewビュー・オブジェクトには、バインド変数(bv_ProductName)があるため、カスタムのProductViewImpl.javaビュー・オブジェクト・クラスの対応するメソッドは次のようになります。

public String getbv_ProductName() {...}
public void setbv_ProductName(String value){...}

これらのメソッドを使用すると、バインド変数にコンパイル時型検証を設定できるため、適切な型の値を設定していることを確認できます。つまり、bv_ProductNameの値を設定する場合、次のようなコードは、さらに簡略化できます。

vo.setNamedWhereClauseParam("bv_ProductName","ball");

簡略化したコードを次に示します。

vo.setbv_ProductName("ball");

後者の方法では、setbv_ProductNameではなく誤ってsetbv_Nameと入力したときにJavaコンパイラによって入力ミスが捕捉されます。

// spelling name wrong gives compile error
vo.setbv_Name("ball");

または、String値ではなく「150」を渡すなど、不適切なデータ型の値を渡した場合は、次のようになります。

// passing Integer where String expected gives compile error
vo.setbv_ProductName(150);

バインド変数アクセッサが生成されていない場合、次のような不適切なコード行をコンパイラで捕捉できません。

// Both variable name and value wrong, but compiler cannot catch it.
// Note the method setNamedWhereClauseParam() sets the value only on the efault
// RowSet and not on the secondary RowSet.
vo.setNamedWhereClauseParam("bv_Name",150);

これには、スペルが正しくないバインド変数名とデータ型が誤っているバインド変数値が両方とも含まれています。ViewObjectインタフェース上で汎用APIを使用する場合、このようなエラーはコンパイル時に捕捉されないため、実行時に例外が発生します。

10.1.1.2 ビュー行属性アクセッサの生成

カスタム・ビュー行クラスの生成を有効にする場合に、図10-1に示すように「アクセッサを含める」チェック・ボックスも選択すると、JDeveloperではビュー行の属性ごとにgetterメソッドおよびsetterメソッドが生成されます。たとえば、ProductViewビュー・オブジェクトの場合、対応するカスタムのProductViewRowImpl.javaクラスには次のようなメソッドが生成されます。

public String getName() {...}
public void setName(String value) {...}
public String getShortDesc() {...}
public void setShortDesc(String value) {...}
public String getImageId() {...}
public void setImageId(Integer value) {...}
public String getSuggestedWhlslPrice() {...}
public void setSuggestedWhlslPrice(BigDecimal value) {...}

これらのメソッドを使用して行データを操作すると、コンパイル時にデータ型の使用方法が正しいかどうかがチェックされます。つまり、Name属性の値を取得する次のようなコードは、さらに簡略化できます。

String name = row.getAttribute("Name");

次のようなコードを記述できます。

String name = row.getName();

後者の方法では、Nameではなく誤ってFullNameと入力したときにJavaコンパイラによって入力ミスが捕捉されます。

// spelling name wrong gives compile error
String name = row.getFullName();

ビュー行アクセッサ・メソッドが生成されていない場合、次のような不適切なコード行をコンパイラで捕捉できません。

// Both attribute name and type cast are wrong, but compiler cannot catch it
Integer name = (Integer)row.getAttribute("FullName");

これには、スペルが正しくない属性名とキャストの型が誤っている戻り値getAttribute()が両方とも含まれています。Rowインタフェース上で汎用APIを使用する場合、このようなエラーはコンパイル時に捕捉されないため、実行時に例外が発生します。

10.1.1.3 クライアントへのビュー行アクセッサの公開

カスタム・ビュー行クラスの生成を有効にする場合に、ビュー行属性アクセッサを生成する場合は、「クライアントへのアクセッサの公開」チェック・ボックスも選択できます。これにより、生成される付加的なカスタム行インタフェース(アプリケーション・クライアントで使用可能)が、実装クラスに直接依存することなく行のカスタム・メソッドにアクセスできるようになります。

ベスト・プラクティス

ビジネス・コンポーネントのクライアント・コードを作成する場合、具体的なクラスのかわりにビジネス・サービス・インタフェースを使用する必要があります。実装クラスではなくインタフェースを使用することで、サーバー側の実装が変更されてもクライアント・コードを変更する必要が生じません。クライアント・コードの使用の詳細は、「カスタム・インタフェースのサポートに関する必知事項」を参照してください。

たとえば、ProductViewビュー・オブジェクトの場合、クライアントへのアクセッサの公開によって、ProductViewRowという名前のカスタム行インタフェースが生成されます。このインタフェースは、ビュー・オブジェクトがあるパッケージのcommonサブパッケージに作成されます。行インタフェースを持つことにより、クライアントでは、強く型付けされた方式で問合せ結果の属性にアクセスするコードを記述できるようになります。次の例は、printAllAttributes()やtestSomethingOnProductRows()のようなメソッドをコールできるようにProductViewRowインタフェースへのproductByName.first()メソッドの結果をキャストする、TestClientサンプル・クライアント・プログラムを示しています。

package oracle.summit.model.extend;

import oracle.jbo.*;
import oracle.jbo.client.Configuration;

import oracle.summit.model.extend.common.ProductView;
import oracle.summit.model.extend.common.ProductViewEx;
import oracle.summit.model.extend.common.ProductViewExRow;
import oracle.summit.model.extend.common.ProductViewRow;

public class TestClient {
public static void main(String[] args) {
String amDef = "oracle.summit.model.extend.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
ProductView products = (ProductView)am.findViewObject("ProductView1");
products.executeQuery();
ProductViewRow product = (ProductViewRow)products.first();
printAllAttributes(products,product);
testSomethingOnProductsRow(product);
products = (ProductView)am.findViewObject("ProductViewEx1");
ProductViewEx productsByName = (ProductViewEx)products;
productsByName.setbv_ProductName("bunny");
productsByName.executeQuery();
product = (ProductViewRow)productsByName.first();
printAllAttributes(productsByName,product);
testSomethingOnProductsRow(product);
am.getTransaction().rollback();
Configuration.releaseRootApplicationModule(am,true);
}
private static void testSomethingOnProductsRow(ProductViewRow product) {
try {
if (product instanceof ProductViewExRow) {
ProductViewExRow productByName = (ProductViewExRow)product;
productByName.someExtraFeature("Test");
}
product.setName("Q");
System.out.println("Setting the Name attribute to 'Q' succeeded.");
}
catch (ValidationException v) {
System.out.println(v.getLocalizedMessage());
}
}
private static void printAllAttributes(ViewObject vo, Row r) {
String viewObjName = vo.getName();
System.out.println("Printing attribute for a row in VO '"+ viewObjName+"'");
StructureDef def = r.getStructureDef();
StringBuilder sb = new StringBuilder();
int numAttrs = def.getAttributeCount();
AttributeDef[] attrDefs = def.getAttributeDefs();
for (int z = 0; z < numAttrs; z++) {
Object value = r.getAttribute(z);
sb.append(z > 0 ? "  " : "")
.append(attrDefs[z].getName())
.append("=")
.append(value == null ? "<null>" : value)
.append(z < numAttrs - 1 ? "\n" : "");
}
System.out.println(sb.toString());
}
}

10.1.1.4 デフォルトのJava生成設定の構成

これまでの説明で、ビュー・オブジェクトの実行時動作をカスタマイズする必要がある場合や、バインド変数またはビュー行属性へ強く型付けされたアクセスのみ行う場合のビュー・オブジェクトのカスタムJavaクラスの生成方法を示しました。

JDeveloperによるJavaクラスの生成を制御するデフォルト設定を変更するには、「ツール」→「プリファレンス」を選択し、「ADFビジネス・コンポーネント」ページを開きます。選択した設定は、今後作成するすべてのビジネス・コンポーネントに適用されます。

ADFビジネス・コンポーネントを初めて使用する開発者には、デフォルトではカスタムJavaクラスを生成しないよう設定することをお薦めします。必要になった場合、その1つのコンポーネントに必要なカスタムJavaコードのみを有効にできます。経験を積むにつれ、どのようなデフォルト設定の組合せが最適であるかがわかるようになります。

10.1.2 カスタム・クラス生成時の処理

1つ以上のカスタムJavaクラスを生成する場合、指定したJavaファイルがJDeveloperにより作成されます。

たとえば、oracle.summit.model.extend.ProductViewという名前のビュー・オブジェクトの場合、カスタムJavaファイルのデフォルト名は、ビュー・オブジェクト・クラスについてはProductViewImpl.java、ビュー行クラスについてはProductViewRowImpl.javaになります。どちらのファイルも、同じ./model/extendディレクトリに、コンポーネントのXMLドキュメント・ファイルとして生成されます。

ビュー・オブジェクトのJava生成オプションは、ビュー・オブジェクトの概要エディタの「Java」ページに後でアクセスしてもそのまま反映されています。XML定義ファイルの場合と同様、このエディタでどのような変更を行っても、カスタムJavaクラスで生成されたコードは最新の状態に保たれます。後でなんらかの理由によりカスタムJavaファイルが必要なくなった場合は、「Java」ページで関連するオプションの選択を解除すると、カスタムJavaファイルを削除できます。

10.1.2.1 カスタムJavaファイルの表示および操作

図10-2に示すように、カスタムJavaクラスの生成を有効にした場合、これらのクラスは、ビュー・オブジェクトのノードの下にも表示されます。カスタムJavaファイルのソース・コードを表示または操作する必要がある場合、ソース・エディタでこのファイルを開く方法には2通りあります。

- 図10-2に示すように、ポップアップ・メニューで「開く」選択します。

- 「アプリケーション」ウィンドウでJavaファイル・ノードが選択された状態で、構造ウィンドウでノードをダブルクリックします。

図10-2 ビュー・オブジェクトのカスタムJavaクラスの表示および操作

10.1.3 カスタム・クラスに関する必知事項

この項では、カスタムJavaクラスの使用に役立つ追加情報を提供します。

10.1.3.1 ビュー・オブジェクトのフレームワーク・ベース・クラスについて

XML専用ビュー・オブジェクトを使用する場合、実行時には、その機能はデフォルトのADFビジネス・コンポーネント実装クラスによって提供されます。生成される各カスタムJavaクラスによって適切なADFビジネス・コンポーネントのベース・クラスが自動的に拡張されるため、コードでは、デフォルトの動作を継承し、このクラスを簡単に追加またはカスタマイズできます。ビュー・オブジェクト・クラスはViewObjectImplを拡張し、ビュー行クラスはViewRowImplを拡張します(これらは両方ともoracle.jbo.serverパッケージ内にあります)。

10.1.3.2 カスタム・コンポーネント・ファイルに安全に追加できるコード

開発者によっては、以前に大変な経験をしたために、生成されたJavaソース・ファイルに独自のコードを追加することを躊躇する場合があります。JDeveloperによって作成および管理される各カスタムJavaソース・コード・ファイルには、独自のカスタム・コードをこのファイルに追加しても安全であることを示す、次のようなコメントがファイルの上部に記載されています。

// ---------------------------------------------------------------------
// ---    File generated by ADF Business Components Design Time.
// ---    Custom code may be added to this class.
// ---    Warning: Do not modify method signatures of generated methods.
// ---------------------------------------------------------------------

コンポーネント・ダイアログで「OK」または「適用」ボタンをクリックしても、ファイルが知らぬ間に再生成されることはありません。かわりに、管理が必要なメソッドはスマートに更新され、独自のカスタム・コードはそのまま残されます。

10.1.3.3 属性索引およびInvokeAccessor生成コード

ビュー・オブジェクトは、XML専用モードで機能するか、XMLドキュメントとカスタムJavaクラスの組合せを使用して機能するように設計されています。属性値はビュー行クラスのプライベート・メンバー・フィールドには格納されないため、XML専用モードの場合、このようなクラスは存在しません。かわりに、属性はAttributesEnumタイプとして定義されます。このタイプでは、ビュー・オブジェクトのXMLドキュメントに基づいて、そのファイルの<ViewAttribute>タグ、関連<ViewLinkAccessor>タグおよび<ViewAccessor>タグの順序で、属性名(および各属性のアクセッサ)が指定されます。実行時には、ビュー行の属性値は、ビュー・オブジェクトの属性リスト内における属性の数値的位置による索引が付けられた状態で、ViewRowImplベース・クラスによって管理される構造に格納されます。

多くの場合、このプライベート実装に関する詳細は重要ではありません。ただし、ビュー行のカスタムJavaクラスを有効にする場合、ビュー行クラスでJDeveloperにより自動的に管理される生成コードの一部にこの実装の詳細が関連し、コードの使用目的を理解できます。たとえば、Usersビュー行のカスタムJavaクラスの場合、次の例に示されているように、属性、ビュー・リンク・アクセッサ属性またはビュー・アクセッサ属性ごとに対応する生成済のAttributesEnum列挙があります。JDeveloperは、複数の開発者が新しい属性をXMLドキュメントに追加した結果発生する可能性があるマージ競合を防ぐために、定数ではなく列挙定数を定義します。

public class RowImpl extends SummitViewRowImpl implements ProductViewRow {
/**
* AttributesEnum: generated enum for identifying attributes and accessors.
* Do not modify.
*/
public enum AttributesEnum {...}
public static final int ID = AttributesEnum.Id.index();
public static final int NAME = AttributesEnum.Name.index();
public static final int SHORTDESC = AttributesEnum.ShortDesc.index();
public static final int LONGTEXTID = AttributesEnum.LongtextId.index();
public static final int IMAGEID = AttributesEnum.ImageId.index();
public static final int SUGGESTEDWHLSLPRICE =
AttributesEnum.SuggestedWhlslPrice.index();
public static final int WHLSLUNITS = AttributesEnum.WhlslUnits.index();
public static final int SOMEVALUE = AttributesEnum.SomeValue.index();
public static final int SFADSF = AttributesEnum.sfadsf.index();
...

また、自動的に管理される、ビュー行クラスで強く型付けされたgetterメソッドおよびsetterメソッドでは、これらの属性定数は次のように使用されます。

public Integer getId() {
return (Integer) getAttributeInternal(ID); // <-- Attribute constant
}
public void setId(Integer value) {
setAttributeInternal(ID, value);// <-- Attribute constant
}

AttributesEnumタイプで定義されたビュー行属性定数に関連する自動管理コードの最後の2つの側面は、getAttrInvokeAccessor()メソッドおよびsetAttrInvokeAccessor()メソッドです。これらのメソッドは数値順索引によって属性アクセスのパフォーマンスを最適化します。これは、ViewRowImplベース・クラスの汎用コードが属性値にアクセスするときの通常の方法です。getAttrInvokeAccessor()メソッドの例は、次のProductViewRowImpl.javaクラスのようになります。もう1つのsetAttrInvokeAccessor()メソッドの場合も同様です。

protected Object getAttrInvokeAccessor(int index, AttributeDefImpl attrDef) throws Exception {
if ((index >= AttributesEnum.firstIndex()) && (index < AttributesEnum.count())) {
return AttributesEnum.staticValues()[index - AttributesEnum.firstIndex()].get(this);
}
return super.getAttrInvokeAccessor(index, attrDef);
}

属性に関連して生成されたこのコードに関する経験則は、次のとおりです。

推奨事項

- 必要に応じて、強く型付けされた属性のgetterメソッドおよびsetterメソッドの内部にカスタム・コードを追加してください。

- ビュー・オブジェクトの概要エディタを使用して、ビュー・オブジェクト属性の順序または型を変更してください。
getterメソッドおよびsetterメソッドのJavaシグネチャや関連するXMLドキュメントは、自動的に変更されます。

非推奨事項

- 生成されたAttributesEnum列挙定数のリストは変更しないでください。

- getAttrInvokeAccessor()メソッドおよびsetAttrInvokeAccessor()メソッドは変更しないでください。

10.1.3.4 親アプリケーション・モジュール・タイプにおける依存性の作成の回避

ビュー・オブジェクト・クラスまたはビュー・オブジェクト行クラスで実装するカスタム・メソッドは、アプリケーション・モジュールの戻り型に依存できません。実行時には、ある場合、そのような依存性を持って実行されるメソッドがClassCastExceptionをスローすることがあります。戻されたアプリケーション・モジュールが、期待された型と一致しないからです。そのため、実装するカスタム・メソッドには、次に示すように、特定のアプリケーション・モジュールやビュー・オブジェクトの実装を取得するコードを記述しないことをお薦めします。

((MyAM)getRootApplicationModule()).getMyVO

特に、次のシナリオにおいて、上のコードがClassCastExceptionで失敗します。

- ADFビジネス・コンポーネント・フレームワークによって、ビュー・オブジェクトが定義されているコンテナとは別のコンテナ・アプリケーション・モジュールでインスタンス化される場合。通常、ビュー・オブジェクトは、その使用方法を宣言するコンテナ・アプリケーション・モジュール(XML定義)でインスタンス化されますが、ADFビジネス・コンポーネント・ランタイムでは、各アプリケーション・モジュールに関連付けられたコンテナを固定することが保証されていません。つまり、親アプリケーション・モジュール・タイプで依存性を持つメソッドを実装しても、それらのメソッドが一貫性を持って実行されない場合があります。

- ルート・アプリケーション・モジュールの下に、手動でアプリケーション・モジュールをネストする場合。この場合、ネストされたアプリケーション・モジュールが同じTransactionオブジェクトを共有するため、前述のコードによって、期待されるアプリケーション・モジュールの型が戻される保証はありません。

- ADFビジネス・コンポーネント・フレームワークの実装がリリースを追うごとに変化する場合。たとえば、以前のリリースでは、アプリケーションがADFタスク・フローを使用して定義した宣言トランザクションを制御するために、フレームワークで内部的なルート・アプリケーション・モジュールが作成されていました。

10.2 複数の名前付きビュー基準のプログラム的処理

ビュー・オブジェクトの概要エディタで複数の名前付きビュー基準を定義し、必要に応じて実行時にその任意の組合せをビュー・オブジェクトに選択的に適用できます。設計時の名前付きビュー基準の処理の詳細は、「名前付きビュー基準を宣言的に作成する方法」を参照してください。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.multinamedviewcriteriaパッケージを参照します。

10.2.1 名前付きビュー基準の適用

名前付きビュー基準を適用するには、setApplyViewCriteriaNames()メソッドを使用します。このメソッドは、適用する基準の名前のString配列を受け取ります。複数の名前付き基準を適用する場合は、実行時に生成されるWHERE句の中でANDにより結合されます。setApplyViewCriteriaNames()メソッドで適用した新しいビュー基準は、以前適用されたすべてのビュー基準を上書きします。以前適用されたビュー基準に単一のビュー基準を追加する場合、setApplyViewCriteriaName()メソッドを使用することもできます。

複数の名前付きビュー基準を適用する必要があるとき、ビュー・オブジェクトのクライアント・インタフェースでカスタム・メソッドを公開し、適用する名前付きビュー基準の組合せをカプセル化できます。たとえば、次の例で示されているカスタム・メソッドshowCustomersForSalesRep()、showCustomersForCreditRating()およびshowCustomersForSalesRepForCreditRating()は、それぞれがsetApplyViewCriteriaNames()メソッドを使用して、名前付きビュー基準の適切な組合せを適用しています。これらのメソッドをビュー・オブジェクトのクライアント・インタフェースで公開すると、実行時に、クライアントは必要に応じてこれらのメソッドを呼び出し、ビュー・オブジェクトによって表示される情報を変更できます。

// In CustomerViewImpl.java
public void showCustomersForSalesRep() {
// reset the view criteria
setApplyViewCriteriaNames(null);
// set the view criteria to show all the customers for the given sales rep
setApplyViewCriteriaName("SalesRepIsCriteria");
executeQuery();
}

public void showCustomersForCreditRating() {
setApplyViewCriteriaNames(null);
setApplyViewCriteriaName("CreditRatingIsCriteria");
executeQuery();
}

public void showCustomersForSalesRepForCreditRating() {
// reset the view criteria
setApplyViewCriteriaNames(null);
// apply both view criteria to show all the customers that match both
setApplyViewCriteriaNames(new String[]{"SalesRepIsCriteria",
"CreditRatingIsCriteria"});
executeQuery();
}

10.2.2 適用されたすべての名前付きビュー基準の除去

現在適用されている名前付きビュー基準を除去するには、setApplyViewCriteriaNames(null)を使用します。たとえば、次の例のshowAllCustomers()メソッドをCustomersViewビュー・オブジェクトに追加し、クライアント・インタフェースで公開できます。このようにすると、クライアントは必要に応じてフィルタ処理されないデータのビューに戻すことができます。

行レベル・バインド変数値が行セットに対してすでに適用されている可能性があるため、設計時ビュー基準は削除しないでください。確実を期すため、設計時にビュー・アクセッサに対して定義された名前付きビュー基準は、ビュー基準のライフサイクル・メソッドによって削除されないように、ビュー・オブジェクト・インスタンスに必須のビュー基準として適用されます。

// In CustomerViewImpl.java
public void showAllCustomers() {
setApplyViewCriteriaNames(null);
executeQuery();
}

注意:

setApplyViewCriterias(null)は適用されているすべてのビュー基準を除去しますが、後でビュー基準の任意の組合せを再度適用できます。これに対し、clearViewCriterias()メソッドはすべての名前付きビュー基準を削除します。clearViewCriterias()を呼び出した後、ビュー基準を適用するには、まず再びputViewCriteria()を使用して新しい名前付き基準を定義する必要があります。

10.2.3 実行時の名前付き基準の使用

実行時に、アプリケーションでは、単一のビジネス・オブジェクト・インタフェースで異なるクライアント・メソッドを呼び出し、異なるフィルタ処理が行われたデータのセットを戻すことができます。次の例は、前述のCustomerViewビュー・オブジェクトを使用するテスト・クライアント・クラスの興味深い行を示しています。showResults()メソッドは、ビュー・オブジェクトの行を反復処理して属性を表示するヘルパー・メソッドです。

// In MultiNamedViewCriteriaTestClient.java
CustomerView vo = (CustomerView) am.findViewObject("CustomerView");

// Show list of all rows in the CustomerView, without applying any view criteria.
showResults(vo,"All Customers");

// Use  type safe set method to set the value of the bind variable used by the
// view criteria
vo.setbv_SalesRepId(12);
vo.showCustomersForSalesRep();
showResults(vo, "All Customers with SalesRepId = 12");

// Set the sales rep id to 11 and show the results.
vo.setbv_SalesRepId(11);
vo.showCustomersForSalesRep();
showResults(vo, "All Customers with SalesRepId = 11");

// use type safe method to set value of bind variable used by the view criteria
vo.setbv_CreditRatingId(2);

// This method applies both view criteria to the VO so the results match
// both criteria, but we do not set the bind variable for sales rep as it
// was already set. The results will show all the customers with a sales
// rep of 11 and a credit rating of 2.
vo.showCustomersForSalesRepForCreditRating();
showResults(vo, "Customers with SalesRepId = 11 and CreditRating = 2");

// Now show all the customers again. The showAllCustomers method resets
// the view criteria.
vo.showAllCustomers();
showResults(vo, "All Customers");

MultiNamedViewCriteriaTestClient.javaを実行すると、次のような出力が生成されます。

---All Customers ---

Unisports Sao Paulo [12, 1]
Simms Athletics Osaka [14, 4]
Delhi Sports New Delhi [14, 2]
...
---All Customers with SalesRepId = 12 ---

Unisports Sao Paulo [12, 1]
Futbol Sonora Nogales [12, 1]
Stuffz Sporting Goods Madison [12, 3]
...
---All Customers with SalesRepId = 11 ---

Womansport Seattle [11, 3]
Beisbol Si! San Pedro de Macon's [11, 1]
Big John's Sports Emporium San Francisco [11, 1]
Ojibway Retail Buffalo [11, 3]
...
---Customers with SalesRepId = 11 and CreditRating = 2 ---

Max Gear New York [11, 2]
MoreAndMoreStuffz Dallas [11, 2]
Schindler's Sports St Louis [11, 2]
...
---All Customers ---

Unisports Sao Paulo [12, 1]
Simms Athletics Osaka [14, 4]
Delhi Sports New Delhi [14, 2]
...

10.3 行セットのメモリー内でのソート処理とフィルタ処理の実行

デフォルトでは、ビュー・オブジェクトはデータベースに対して問合せを実行し、結果の行セットに行を取得します。ただし、ビュー・オブジェクトを使用して、メモリー内で検索とソートを実行し、データベースへの不必要なトリップを避けることもできます。この種の操作は、ビュー・オブジェクト行セットのまだポストされていない新しい行をソートおよびフィルタ処理する場合に最適です。この操作が行われないと、ポストされていない行は行セットの先頭に追加されます。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.inMemoryOperationsパッケージを参照します。

10.3.1 ビュー・オブジェクトのSQLモード

ビュー・オブジェクトのSQLモードは、行を取得して行セットに移入するために使用されるソースを制御します。setQueryMode()を使用すると、使用するモードまたはモードの組合せを制御できます。

- ViewObject.QUERY_MODE_SCAN_DATABASE_TABLES
データベースから結果を取得するデフォルトのモードです。

- ViewObject.QUERY_MODE_SCAN_VIEW_ROWS
すでに行セットに存在する行をソースとして使用し、メモリー内フィルタ処理をとおして行セットの内容を段階的に調整できます。

- ViewObject.QUERY_MODE_SCAN_ENTITY_ROWS
エンティティ・ベースのビュー・オブジェクトに対してのみ有効なモードで、エンティティ・キャッシュに現在存在するエンティティ行をソースとして使用し、キャッシュの内容に基づいて結果を生成します。

モードを個別に使用することも、Javaの論理OR演算子(X | Y)を使用して組み合せることもできます。たとえば、エンティティ・キャッシュでポストされていない新しいエンティティ行を問い合せ、同時にデータベースで既存の行を問い合せるビュー・オブジェクトを作成するには、次のようなコードを使用します。

setQueryMode(ViewObject.QUERY_MODE_SCAN_DATABASE_TABLES |
ViewObject.QUERY_MODE_SCAN_ENTITY_ROWS)

SQLモードを組み合せると、ビュー・オブジェクトは重複する行のスキップを自動的に処理します。さらに、検出された結果には暗黙の順序があります。

1. スキャン・ビュー行(指定されていた場合)

2. スキャン・エンティティ・キャッシュ(指定されていた場合)

3. SQL問合せの発行によるスキャン・データベース表(指定されていた場合)

setQueryMode()メソッドを呼び出してSQLモードを変更した場合、新しい設定は次にexecuteQuery()メソッドを呼び出すと有効になります。

10.3.2 メモリー内のビュー・オブジェクト行のソート処理

実行時にビュー・オブジェクトの行をソートするには、setSortBy()メソッドを使用してソート順序を制御します。または、ビュー・オブジェクトのプロパティPROP_ALWAYS_USE_SORTをtrueに設定して、システムがデフォルトでメモリー内ソートを処理できるようにすることもできます。

ソート順序を制御する場合は、SQLのORDER BY句のようなソート式を渡します。ただし、表の列名を参照するかわりに、ビュー・オブジェクトの属性名を使用します。たとえば、CreditRatingIdおよびZipCodeという名前の属性を含むビュー・オブジェクトの場合、次のメソッドを呼び出すことで、最初にCustomerの降順で、次にDaysOpenで、ビュー・オブジェクトをソートできます。

setSortBy("CreditRatingId desc, ZipCode");

または、次のように、ソート処理句の中ではゼロから始まる属性インデックス位置を使用することもできます。

setSortBy("3 desc, 2");

setSortBy()メソッドを呼び出した後、次にexecuteQuery()メソッドを呼び出すと行がソートされます。ビュー・オブジェクトは、このソート句を適切な書式に変換し、ビュー・オブジェクトのSQLモードに基づいた行の並替えに使用します。デフォルトのSQLモードを使用すると、SortBy句は適切なORDER BY句に変換され、データベースに送信されるSQL文の一部として使用されます。いずれかのメモリー内SQLモードの場合は、SortBy句は1つまたは複数のSortCriteriaオブジェクトに変換され、メモリー内ソートの実行で使用されます。

注意:

SQL ORDER BY式では列名の大文字と小文字は区別されませんが、SortBy式の属性名では大文字と小文字が区別されます。

10.3.2.1 メモリー内ソートでのsetSortByとsetQueryModeの組合せ

setSortBy()およびsetQueryMode()メソッドを使用して、読取り専用のビュー・オブジェクトによって生成された行に対してメモリー内ソートを実行できます。次の例は、読取り専用のビュー・オブジェクトCustomersInTxによって生成された行に対してメモリー内ソートを実行するために、setSortBy()とsetQueryMode()を使用する、TestClientSetSortByクラスの興味深いコード行を示しています。

// In TestClientSetSortBy.java
am.getTransaction().executeCommand("ALTER SESSION SET SQL_TRACE TRUE");
ViewObject vo = am.findViewObject("CustomersInTx");
vo.executeQuery();
showRows(vo,"Initial database results");
vo.setSortBy("Name");
vo.setQueryMode(ViewObject.QUERY_MODE_SCAN_VIEW_ROWS);
vo.executeQuery();
showRows(vo,"After in-memory sorting by Customer Name ");
vo.setSortBy("CreditRatingId desc, ZipCode");
vo.executeQuery();
showRows(vo,"After in-memory sorting by CreditRating desc, and ZipCode");

この例を実行すると、次のような結果が生成されます。

--- Initial database results ---

36,Great Gear,1500 Barton Springs Rd,78704, 2, TX
37,Acme Outfitters,3500 Guadalupe St,78705, 3, TX
38,Athena's Closet,1209 Red River St,78701, 1, TX
39,BuyMyJunk,5610 E Mockingbird Ln,75206, 3, TX
...

--- After in-memory sorting by Customer Name  ---

37,Acme Outfitters,3500 Guadalupe St,78705, 3, TX
38,Athena's Closet,1209 Red River St,78701, 1, TX
43,Big Bad Sports,2920 Hillcroft St,77057, 1, TX
39,BuyMyJunk,5610 E Mockingbird Ln,75206, 3, TX
...

--- After in-memory sorting by CreditRating desc, and ZipCode ---

42,Field Importers,2111 Norfolk St,77098, 4, TX
39,BuyMyJunk,5610 E Mockingbird Ln,75206, 3, TX
37,Acme Outfitters,3500 Guadalupe St,78705, 3, TX
41,MoreAndMoreStuffz,3501 McKinney Ave,75204, 2, TX
...

executeCommand()のコールを含む前述のテスト・クライアントの1行目では、ALTER SESSION SET SQL TRACEコマンドを発行して、現在のデータベース・セッションでSQLトレースを有効にしています。これにより、Oracleデータベースは、実行されるすべてのSQL文をサーバー側のトレース・ファイルに記録します。データベースが文を解析した回数や、問合せ結果を取得する間に行のバッチをフェッチするためにクライアントが行ったラウンドトリップの回数など、各SQL文のテキストに関する情報が記録されます。

注意:

ALTER SESSIONコマンドを実行してSQL出力のトレースを行うには、DBAによるSummitアカウントへの権限付与が必要になる場合があります。

生成されたトレース・ファイルは、データベースに付属するTKPROFユーティリティを使用して書式設定できます。

tkprof xe_ora_3916.trc trace.prf

TKPROFユーティリティでの作業の詳細は、「アプリケーション・トレースの実行」、SQLトレースとTKPROFの理解に関する項およびSQLトレース機能とTKPROFの使用に関する項を参照してください。

これにより、trace.prfファイルが生成されます。このファイルには、CustomersInTxビュー・オブジェクトによって実行されたSQL文に関する、次の例のような興味深い情報が含まれます。最初に1回の実行で6行のデータを問い合せてデータベースからフェッチした後、その後に行われたこれらの結果に対する2回のソートでは実行が行われていないことがわかります。コードでSQLモードがViewObject.QUERY_MODE_SCAN_VIEW_ROWSに設定されているため、setSortBy()の後のexecuteQuery()ではメモリー内でソートが実行されました。

SELECT
S_CUSTOMER.ID ID,
S_CUSTOMER.NAME NAME,
S_CUSTOMER.PHONE PHONE,
S_CUSTOMER.ADDRESS ADDRESS,
S_CUSTOMER.CITY CITY,
S_CUSTOMER.STATE STATE,
S_CUSTOMER.ZIP_CODE ZIP_CODE,
S_CUSTOMER.CREDIT_RATING_ID CREDIT_RATING_ID
FROM
S_CUSTOMER
WHERE
S_CUSTOMER.STATE = 'TX'

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.02          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        9      0.00       0.00          0         14          0           8
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       11      0.00       0.02          0         14          0           8

10.3.2.2 簡素化されたメモリー内ソート処理

メモリー内の行ソート方法を制御する必要がない場合は、ビュー・オブジェクト・インタフェースに用意されたPROP_ALWAYS_USE_SORTプロパティを使用して、メモリー内の行をソースとして使用するようにビュー・オブジェクトの問合せモードを変更したときに、ソート処理が強制されるようにできます。このプロパティは、ビュー・プロパティの行セットが小さく、クライアントがメモリー内ソートの実行を必要としている場合に使用できます。次のように、問合せモードを設定後、このビュー・オブジェクト・プロパティを設定して、デフォルトのメモリー内ソート処理を指定します。

vo.setQueryMode(ViewObject.QUERY_MODE_SCAN_ENTITY_ROWS);
vo.setProperty(ViewObject.PROP_ALWAYS_USE_SORT, "true");

10.3.2.3 メモリー内ソート処理の拡張ポイント

メモリー内での行のソート方法をカスタマイズする必要がある場合は、次の2つの手段を自由に使用できます。

- 次のメソッドをオーバーライドできます。

public void sortRows(Row[] rows)

このメソッドは、行のメモリー内ソート処理を実際に行います。このメソッドをオーバーライドすることで、必要に応じてかわりのソート方法を組み込むことができます。

- 次のメソッドをオーバーライドできます。

public Comparator getRowComparator()

このメソッドのデフォルトの実装はoracle.jbo.RowComparatorを返します。RowComparatorはcompareTo()メソッドを呼び出して、2つのデータ値を比較します。これらのメソッドとオブジェクトをオーバーライドし、カスタム比較ルーチンを提供できます。

10.3.3 ビュー基準によるメモリー内フィルタ処理の実行

ViewCriteriaを使用して行セットの内容をフィルタするために、次のメソッドを呼び出すことができます。

- applyViewCriteria()またはsetApplyViewCriteriaNames()を呼び出してからexecuteQuery()を呼び出すと、フィルタ処理された新しい行セットが生成されます。

- findByViewCriteria()を呼び出すと、元の行セットの内容を変更することなく、プログラムで処理するための新しい行セットが取得されます。

これらの方法はどちらも、ビュー基準モードに応じて、データベースに対して、またはメモリー内フィルタ処理を実行するために、あるいはその両方に使用できます。基準モードは、ViewCriteriaオブジェクトでsetCriteriaMode()メソッドを使用して設定します。このメソッドには、次の整数フラグのどちらか一方、または両方の論理ORを渡すことができます。

- ViewCriteria.CRITERIA_MODE_QUERY

- ViewCriteria.CRITERIA_MODE_CACHE

ビュー基準によるメモリー内フィルタ処理で使用できる演算子を表10-1に示します。カッコを使用して副次式をグループ化でき、副次式の間にはANDとORの演算子を使用できます。

表10-1 ビュー基準によるメモリー内フィルタ処理でサポートされているSQL演算子

演算子

操作

=、>、<、<=、>=、<>、LIKE、BETWEEN、IN

比較

NOT

論理否定

AND

論理積

OR

論理和

次の例は、前述のデータベースに対するものとメモリー内の2つの機能を使用するTestClientFindByViewCriteriaクラスの興味深い行を示しています。この例は、CustomerListビュー・オブジェクトのインスタンスを使用し、次の基本的な手順を実行します。

1. データベースで姓がCで始まる顧客を問い合せて、次のような出力を生成します。

--- Initial database results with applied view criteria ---
John Chen
Emerson Clabe
Karen Colmenares

2. メモリー内で、手順1の結果から、名がJで始まる顧客のみのサブセットを作成します。そのために、ビュー基準に2番目のビュー基準行を追加し、ANDを使用する論理積を設定しています。次のような出力が生成されます。

--- After augmenting view criteria and applying in-memory ---
John Chen

3. 論理積をORに戻し、基準を再びデータベースに適用して、姓が'J%'または名が'C%'の顧客を問い合せます。次のような出力が生成されます。

--- After changing view criteria and applying to database again ---
John Chen
Jose Manuel Urman
Emerson Clabe
Karen Colmenares
Jennifer Whalen

4. 姓または名に文字oを含む顧客をメモリー内で検索する新しい基準を定義します。

5. (サブセットを作成するのではなく、) findByViewCriteria()を使用して新しい行セットを作成し、出力を生成します。

--- Rows returned from in-memory findByViewCriteria ---
John Chen
Jose Manuel Urman
Emerson Clabe
Karen Colmenares

6. findByViewCriteria()を使用しても元の行セットが変化していないことを示し、出力を生成します。

--- Note findByViewCriteria didn't change rows in the view ---
John Chen
Jose Manuel Urman
Emerson Clabe
Karen Colmenares
Jennifer Whalen

// In TestClientFindByViewCriteria.java
ViewObject vo = am.findViewObject("CustomerList");
// 1. Show customers with a last name starting with a 'M'
ViewCriteria vc = vo.createViewCriteria();
ViewCriteriaRow vcr1 = vc.createViewCriteriaRow();
vcr1.setAttribute("LastName","LIKE 'M%'");
vo.applyViewCriteria(vc);
vo.executeQuery();
vc.add(vcr1);
vo.executeQuery();
showRows(vo, "Initial database results with applied view criteria");
// 2. Subset results in memory to those with first name starting with 'S'
vo.setQueryMode(ViewObject.QUERY_MODE_SCAN_VIEW_ROWS);
ViewCriteriaRow vcr2 = vc.createViewCriteriaRow();
vcr2.setAttribute("FirstName","LIKE 'S%'");
vcr2.setConjunction(ViewCriteriaRow.VCROW_CONJ_AND);
vc.setCriteriaMode(ViewCriteria.CRITERIA_MODE_CACHE);
vc.add(vcr2);
vo.executeQuery();
showRows(vo,"After augmenting view criteria and applying in-memory");
// 3. Set conjuction back to OR and reapply to database query to find
// customers with last name like 'H%' or first name like 'S%'
vc.setCriteriaMode(ViewCriteria.CRITERIA_MODE_QUERY);
vo.setQueryMode(ViewObject.QUERY_MODE_SCAN_DATABASE_TABLES);
vcr2.setConjunction(ViewCriteriaRow.VCROW_CONJ_OR);
vo.executeQuery();
showRows(vo,"After changing view criteria and applying to database again");
// 4. Define new critera to find customers with first or last name like '%o%'
ViewCriteria nameContainsO = vo.createViewCriteria();
ViewCriteriaRow lastContainsO = nameContainsO.createViewCriteriaRow();
lastContainsO.setAttribute("LastName","LIKE '%o%'");
ViewCriteriaRow firstContainsO = nameContainsO.createViewCriteriaRow();
firstContainsO.setAttribute("FirstName","LIKE '%o%'");
nameContainsO.add(firstContainsO);
nameContainsO.add(lastContainsO);
// 5. Use findByViewCriteria() to produce new rowset instead of subsetting
nameContainsO.setCriteriaMode(ViewCriteria.CRITERIA_MODE_CACHE);
RowSet rs = (RowSet)vo.findByViewCriteria(nameContainsO,
-1,ViewObject.QUERY_MODE_SCAN_VIEW_ROWS);
showRows(rs,"Rows returned from in-memory findByViewCriteria");
// 6. Show that original rowset hasn't changed
showRows(vo,"Note findByViewCriteria didn't change rows in the view");

10.3.4 RowMatchによるメモリー内フィルタ処理の実行

RowMatchオブジェクトは、メモリー内フィルタ処理の基準を表現するためのさらに便利な方法を提供します。RowMatchオブジェクトを作成するには、次のように、問合せ条件式をコンストラクタに渡します。

RowMatch rm =
new RowMatch("LastName = 'Popp' or (FirstName like 'A%' and LastName like 'K%')");

SortBy句と同じように、ビュー・オブジェクトの属性名に関するRowMatchの式を、表10-2に示す、サポートされる演算子を使用して表現します。カッコを使用して副次式をグループ化でき、副次式の間にはANDとORの演算子を使用できます。

表10-2 RowMatchによるメモリー内フィルタ処理でサポートされているSQL演算子

演算子

操作

=、>、<、<=、>=、<>、LIKE、BETWEEN、IN

比較

NOT

論理否定

論理否定演算NOT INはRowMatch式ではサポートされていないことに注意してください。

IN演算子を否定するには、かわりに次の構造を使用してください(カッコの使用に注意)。

NOT (EmpID IN ( 'VP','PU'))

AND

論理積

OR

論理和

表10-3に示すように、RowMatch式ではSQL機能の一部も使用できます。

表10-3 RowMatchによるメモリー内フィルタ処理でサポートされているSQL関数

演算子

操作

UPPER

文字列内のすべての文字を大文字に変換する。

TO_CHAR

数または日付を文字列に変換する。

TO_DATE

文字列を日付形式に変換する。

TO_TIMESTAMP

文字列をタイムスタンプに変換する。

注意:

SQL問合せ条件では列名の大文字と小文字は区別されませんが、RowMatch式の属性名では大文字と小文字が区別されます。

10.3.4.1 ビュー・オブジェクトへのRowMatchの適用

ビュー・オブジェクトにRowMatchを適用するには、setRowMatch()メソッドを呼び出します。ViewCriteriaとは異なり、RowMatchはメモリー内フィルタ処理にのみ使用するため、設定する一致モードはありません。サポートされるすべてのSQLモードのビュー・オブジェクトに対してRowMatchを使用でき、適用した結果は、次にexecuteQuery()メソッドを呼び出したときに表示されます。

ビュー・オブジェクトにRowMatchを適用するとき、RowMatchの式では、SQL文で使用するものと同じ:VarName表記法を使用して、ビュー・オブジェクトの名前付きバインド変数を参照できます。たとえば、ビュー・オブジェクトにStatusCodeという名前の名前付きバインド変数がある場合は、次の式でRowMatchを適用できます。

Status = :StatusCode or :StatusCode = '%'

次の例は、活動中のRowMatchを示すTestClientRowMatchクラスの興味深い行を示しています。例で使用されているCustomerListビュー・オブジェクトには、Selectedという名前の一時Boolean属性があります。このコードが実行する基本的な手順は次のとおりです。

1. 顧客の完全なリストを問い合せて、出力を生成します。

--- Initial database results ---
Neena Kochhar [null]
Lex De Haan [null]
Nancy Greenberg [null]
:

2. 奇数行のSelected属性にBoolean.TRUEを設定し、奇数番号の行を選択済としてマークします。出力を生成します。

--- After marking odd rows selected ---
Neena Kochhar [null]
Lex De Haan [true]
Nancy Greenberg [null]
Daniel Faviet [true]
John Chen [null]
Ismael Sciarra [true]
:

3. RowMatchを使用して、選択されている行、つまりSelected = trueの行のみを含む行セットのサブセットを作成します。次のような出力が生成されます。

--- After in-memory filtering on only selected rows ---
Lex De Haan [true]
Daniel Faviet [true]
Ismael Sciarra [true]
Luis Popp [true]
:

4. より複雑なRowMatch式を使用して、行セットのサブセットをさらに絞り込みます。出力を生成します。

--- After in-memory filtering with more complex expression ---
Lex De Haan [true]
Luis Popp [true]

// In TestClientRowMatch.java
// 1. Query the full customer list
ViewObject vo = am.findViewObject("CustomerList");
vo.executeQuery();
showRows(vo,"Initial database results");
// 2. Mark odd-numbered rows selected by setting Selected = Boolean.TRUE
markOddRowsAsSelected(vo);
showRows(vo,"After marking odd rows selected");
// 3. Use a RowMatch to subset row set to only those with Selected = true
RowMatch rm = new RowMatch("Selected = true");
vo.setRowMatch(rm);
// Note: Only need to set SQL mode when not defined at design time
vo.setQueryMode(ViewObject.QUERY_MODE_SCAN_VIEW_ROWS);
vo.executeQuery();
showRows(vo, "After in-memory filtering on only selected rows");
// 5. Further subset rowset using more complicated RowMatch expression
rm = new RowMatch("LastName = 'Popp' "+
"or (FirstName like 'A%' and LastName like 'K%')");
vo.setRowMatch(rm);
vo.executeQuery();
showRows(vo,"After in-memory filtering with more complex expression");
// 5. Remove RowMatch, set query mode back to database, requery to see full list
vo.setRowMatch(null);
vo.setQueryMode(ViewObject.QUERY_MODE_SCAN_DATABASE_TABLES);
vo.executeQuery();
showRows(vo,"After requerying to see a full list again");

10.3.4.2 個別の行をテストするためのRowMatchの使用

RowMatchを使用して行セットをフィルタするのみでなく、rowQualifies()メソッドを使用すると、それがカプセル化している基準に個別の行が一致するかどうかをテストすることもできます。次に例を示します。

RowMatch rowMatch = new RowMatch("CountryId = 'US'");
if (rowMatch.rowQualifies(row)) {
System.out.println("Customer is from the United States ");
}

10.3.4.3 データベースからフェッチされた行に対するRowMatchの影響

RowMatchを適用すると、ビュー・オブジェクトのSQLモードがデータベースからの行の取得に設定されている場合、executeQuery()を呼び出すと、フェッチされた行にRowMatchが適用されます。フェッチされた行が認定されない場合、その行は行セットに追加されません。

SQLのWHERE句とは異なり、RowMatchは、一時ビュー・オブジェクト属性およびまだポストされていない属性値を含む式でも評価できます。これは、Javaで値が計算される一時ビュー行属性を含むRowMatch式に基づいて、問い合された行をフィルタするのに便利です。ただし、この興味深い機能は、アプリケーションが大きな行セットを処理する必要がある場合には注意して使用する必要があります。最初にデータベース・レベルのフィルタ処理を使用してできるかぎり小さい行セットを取得した後、RowMatchを使用してメモリーでそのリストからサブセットを作成することをお薦めします。

10.4 XMLの読取りと書込み

Worldwide Web Consortium (W3C)が定めるExtensible Markup Language (XML)標準では、電子データ交換用の言語に依存しない方式が定義されています。厳密な一連の規則により、判読可能なテキスト・ドキュメントを使用して、データに固有の構造を簡単にエンコードし、正確に解釈できます。

ビュー・オブジェクトでは、問い合されたデータに基づいて、XMLドキュメントを記述することができます。また、XMLドキュメントを読み取って、挿入、更新、削除などの変更をデータに適用することもできます。ビュー・リンクを導入すると、このXML機能は、任意の複雑さのマスター/ディテール階層の複数レベルでネストされた情報の読取りと書込みをサポートします。ビュー・オブジェクトが生成および使用するXMLは正規書式に従いますが、ビュー・オブジェクトのXML機能とXML Stylesheet Language Transformations (XSLT)を組み合せることで、正規のXML書式と使用する必要のある任意の書式の間の変換を簡単に行うことができます。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.readandwriteパッケージを参照します。

10.4.1 問合せ済データのXMLの生成方法

ビュー・オブジェクトからXMLを生成するために、writeXML()メソッドを使用します。2種類の方法で生成されるXMLを制御できます。

1. 生成されるXMLを正確に制御するには、ネストされた詳細情報に対してアクセスする必要のあるビュー・リンク・アクセッサ属性など、使用する必要のある属性を示すビュー・オブジェクト属性マップを指定できます。

Node writeXML(long options, HashMap voAttrMap)

2. すべての属性を含むXMLを生成するには、結果を生成するためにトラバースする必要のあるビュー・リンク・アクセッサ属性のレベル数を示す深さレベルを指定するだけで済みます。

Node writeXML(int depthCount, long options)

optionsパラメータは整数のフラグ・フィールドで、次のビット・フラグのいずれかを設定できます。

- XMLInterface.XML_OPT_ALL_ROWS
設定するビュー・オブジェクトのすべての行をXMLに含めます。

- XMLInterface.XML_OPT_LIMIT_RANGE
現在の範囲内の行のみをXMLに含めます。

現在のトランザクションにあるポストされていない新しい行をXML出力に含める場合は、論理OR演算子を使用して、前述のフラグとXMLInterface.XML_OPT_ASSOC_CONSISTENTフラグを組み合せることができます。

どちらのバージョンのwriteXML()メソッドも、オプションで(指定された場合には)、返される前のXML出力を変換するために使用されるXSLTスタイルシートとして第3の引数を受け取ります。

また、両方のバージョンのwriteXML()メソッドで、引数depthCount=ignoreを設定して、深さカウントを無視し、指定されたoptionsパラメータ・フラグに基づくデータ・モデルにあるもののみをレンダリングすることを指示できます。

10.4.2 XMLを生成するときに行われる処理

writeXML()を使用してXMLを生成すると、ビュー・オブジェクトは最初に、ラップするXML要素を作成します。そのデフォルト名は、ビュー・オブジェクト定義の名前と一致しています。たとえば、CustomersViewビュー・オブジェクトの場合は、生成されるXMLをラップする一番外側のタグはCustomersViewタグになります。

次に、ビュー・オブジェクトは、適切な行の属性データをXML要素に変換します。デフォルトでは、各行のデータは、ビュー・オブジェクトの名前に接尾辞Rowを付加した名前の行要素でラップされます。たとえば、CustomersViewという名前のビュー・オブジェクトの各データ行は、CustomersViewRow要素でラップされます。各行の属性データを表す要素は、この行要素内にネストされた子として記述されます。

いずれかの属性がビュー・リンク・アクセッサ属性であり、writeXML()に渡されたパラメータによって有効になっている場合は、ビュー・リンク・アクセッサによって返されるディテール行セットのデータも含められます。このネストされたデータは、ビュー・リンク・アクセッサ属性の名前によって名前が決まる要素でラップされます。writeXML()メソッドの戻り値は、W3Cの標準のNodeインタフェースを実装するオブジェクトで、生成されたXMLのルート要素を表します。

注意:

writeXML()メソッドは、ビュー・リンク・アクセッサ属性を使用して、プログラムでディテール・コレクションにアクセスします。データ・モデルにビュー・リンクのインスタンスを追加する必要はありません。

たとえば、CustomersViewビュー・オブジェクト・インスタンスのすべての行に対するXML要素を生成し、存在するレベルの深さまでビュー・リンク・アクセッサをたどる場合は、次の例に示すようなコードが必要です。

ViewObject vo = am.findViewObject("CustomersView");
printXML(vo.writeXML(-1,XMLInterface.XML_OPT_ALL_ROWS));

CustomersViewビュー・オブジェクトは、その個人が作成したオーダーを表すOrdersビュー・オブジェクトにリンクされています。そして、Ordersビュー・オブジェクトは、顧客がオーダーした品目の詳細を提供するOrderItemsビュー・オブジェクトにリンクされています。次の例のコードを実行すると、ビュー・リンクによって定義されているネストされた構造を反映した、次の例に示すXMLが生成されます。

...
<CustomersViewRow>
<Id>211</Id>
<Name>Kuhn's Sports</Name>
<Phone>42-111292</Phone>
<Address>7 Modrany</Address>
<City>Prague</City>
<CountryId>11</CountryId>
<CreditRatingId>2</CreditRatingId>
<SalesRepId>15</SalesRepId>
<OrdersView>
<OrdersViewRow>
<Id>107</Id>
<CustomerId>211</CustomerId>
<DateOrdered>2012-12-13</DateOrdered>
<DateShipped>2012-12-14</DateShipped>
<SalesRepId>15</SalesRepId>
<Total>142171</Total>
<PaymentTypeId>2</PaymentTypeId>
<PaymentOptionId>1082</PaymentOptionId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>183</Id>
<CustomerId>211</CustomerId>
<DateOrdered>2013-02-24</DateOrdered>
<DateShipped>2013-02-27</DateShipped>
<SalesRepId>13</SalesRepId>
<Total>3742</Total>
<PaymentTypeId>1</PaymentTypeId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>184</Id>
<CustomerId>211</CustomerId>
<DateOrdered>2012-11-19</DateOrdered>
<DateShipped>2012-11-22</DateShipped>
<SalesRepId>12</SalesRepId>
<Total>987</Total>
<PaymentTypeId>1</PaymentTypeId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>185</Id>
<CustomerId>211</CustomerId>
<DateOrdered>2012-08-08</DateOrdered>
<DateShipped>2012-08-12</DateShipped>
<SalesRepId>12</SalesRepId>
<Total>2525.25</Total>
<PaymentTypeId>1</PaymentTypeId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>186</Id>
<CustomerId>211</CustomerId>
<DateOrdered>2012-04-26</DateOrdered>
<DateShipped>2012-04-30</DateShipped>
<SalesRepId>12</SalesRepId>
<Total>307.25</Total>
<PaymentTypeId>1</PaymentTypeId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>187</Id>
<CustomerId>211</CustomerId>
<DateOrdered>2012-12-23</DateOrdered>
<DateShipped>2012-12-30</DateShipped>
<SalesRepId>13</SalesRepId>
<Total>3872.9</Total>
<PaymentTypeId>1</PaymentTypeId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>188</Id>
<CustomerId>211</CustomerId>
<DateOrdered>2013-01-14</DateOrdered>
<DateShipped>2013-01-15</DateShipped>
<SalesRepId>12</SalesRepId>
<Total>12492</Total>
<PaymentTypeId>1</PaymentTypeId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
...
</OrdersView>
</CustomersViewRow>
...

10.4.3 XMLの読取りと書込みに関する必知事項

この項では、XMLの使用に役立つ追加情報を提供します。

10.4.3.1 XMLの要素名の制御

ビュー・オブジェクトの正規XML書式で使用されるデフォルトのXML要素名は、「プロパティ」ウィンドウを使用していくつかプロパティを設定することで変更できます。これを実現するには、ビュー・オブジェクトの概要エディタを開き、次の操作を行います。

- 「属性」ページで属性を選択し、「プロパティ」ウィンドウで「カスタム・プロパティ」ナビゲーション・タブを選択して、カスタム属性レベルのプロパティ「XML要素」に値SomeOtherNameを設定すると、その属性に使用されるXML要素の名前が<SomeOtherName>に変わります。
たとえば、CustomersViewビュー・オブジェクトのEmail属性で定義されているこのプロパティは、「XMLを生成するときに行われる処理」で説明されているXML要素を<Email>から<EmailAddress>に変更します。

- 「プロパティ」ウィンドウの「一般」ナビゲーション・タブを選択し、カスタム・ビュー・オブジェクト・レベルのプロパティ「XML行要素」に値SomeOtherRowNameを設定すると、そのビュー・オブジェクトに使用されるXML要素の名前が<SomeOtherRowName>に変わります。
たとえば、CustomersViewビュー・オブジェクトで定義されているこのプロパティは、「XMLを生成するときに行われる処理」で説明されている行のXML要素名を<CustomersViewRow>から<Customer>に変更します。

- ビュー・リンク・アクセッサ属性からのネストされた行セット・データをラップする要素の名前を変更するには、「ビュー・リンク・プロパティ」ダイアログを使用します。ダイアログを開くには、ビュー・リンクの概要エディタで、「関連」ページの「アクセッサ」セクションにある「アクセッサの編集」アイコンをクリックします。「アクセッサ名」フィールドに、ビュー・リンク・アクセッサ属性の適切な名前を入力します。

10.4.3.2 NULL値属性の要素抑止の制御

デフォルトでは、ビュー行属性がnullの場合、生成されるXMLから対応する要素が省略されます。概要エディタの「属性」ページで属性を選択し、「プロパティ」ウィンドウで「カスタム・プロパティ」ナビゲーション・タブを選択して、カスタム属性レベルのプロパティ「XML明示的なNull」に任意の値(たとえばtrueやyes)を設定すると、値がNULLの属性についても要素が生成されます。たとえば、AssignedDateという名前の属性にこのプロパティを設定すると、割当て日がnullの行には、対応するAssignedDate null="true"/要素が含まれます。この動作をビュー・オブジェクトのすべての属性に適用する場合は、属性ごとにプロパティを定義するかわりに、ビュー・オブジェクト・レベルでXml Explicit Nullカスタム・プロパティを定義できます。

10.4.3.3 生成されたXMLの印刷またはXPathを使用した検索

writeXML()から返されるXML Nodeオブジェクトに関する最も一般的な処理は次の2つです。

1. ネットワーク経由での送信やファイルへの保存などのために、ノードをシリアライズされたテキスト表現に印刷

2. 生成されたXMLをW3C XPath式を使用して検索

残念ながら、標準のW3C Document Object Model (DOM) APIには、これらの役に立つ操作を行うためのメソッドは含まれません。しかし大丈夫です。ADFビジネス・コンポーネントはDOMのOracle XMLパーサーの実装を使用しているので、writeXML()からのNode戻り値をOracle固有のクラスであるXMLNodeやXMLElement (oracle.xml.parser.v2パッケージ内)にキャストして、次のような便利な追加機能にアクセスできます。

- print()メソッドを使用した、シリアライズされたテキスト形式へのXML要素の印刷

- selectNodes()メソッドを使用した、メモリー内のXML要素のXPath式による検索

- valueOf()メソッドを使用した、XML要素に関連するXPath式の値の検出

次の例は、TestClientWriteXMLのprintXML()メソッドを示しています。NodeパラメータをXMLNodeにキャストし、print()メソッドを呼び出してXMLをコンソールにダンプします。

// In TestClientWriteXML.java
private static void printXML(Node n) throws IOException {
((XMLNode)n).print(System.out);
}

10.4.3.4 生成されるXMLの属性マップによるきめ細かい制御

生成されるXMLに含める属性をきめ細かく制御する必要がある場合は、HashMapを受け取るバージョンのwriteXML()メソッドを使用します。次の例は、この手法を使用するTestClientWriteXMLクラスの興味深い行を示しています。HashMapを作成した後、String[]値のエントリを設定します。このエントリは、XMLに含める属性の名前であり、キーとしてはこれらの属性が属しているビュー定義の完全修飾名を使用します。例には、CustomersViewビュー・オブジェクトの属性Name、CityおよびOrdersViewと、OrdersViewビュー・オブジェクトの属性Id、DateOrderedおよびTotalが含まれます。

注意:

旧バージョンのADFビジネス・コンポーネントとの互換性のため、writeXML()メソッドが受け取るHashMapはcom.sun.java.util.collectionsパッケージのものです。

特定のビュー・オブジェクト・インスタンスのビュー行に対しては、次のような処理が行われます。

- そのビュー・オブジェクトの完全修飾ビュー定義名とキーが一致する項目が属性マップに存在する場合は、対応するString配列に名前のある属性のみがXMLに含められます。
さらに、文字列配列にビュー・リンク・アクセッサ属性の名前が含まれる場合は、そのディテール行セットのネストされた内容がXMLに含められます。ビュー・リンク・アクセッサ属性名が文字列配列に出現しない場合は、ディテール行セットの内容は含められません。

- キーが一致する項目がマップ内に存在しない場合は、その行のすべての属性がXMLに含められます。

HashMap viewDefMap = new HashMap();
viewDefMap.put("oracle.summit.model.readandwritexml.queries.CustomersView",
new String[]{"Name","City",
"OrdersView" /* View link accessor attribute */
});
viewDefMap.put("oracle.summit.model.readandwritexml.queries.OrdersView",
new String[]{"Id","DateOrdered","Total"});
printXML(vo.writeXML(XMLInterface.XML_OPT_ALL_ROWS,viewDefMap));

前述の例を実行すると、提供された属性マップで指定されている属性とビュー・リンク・アクセッサのみが含まれる次のXMLが生成されます。

<CustomersViewRow>
<Id>211</Id>
<Name>Kuhn's Sports</Name>
<City>Prague</City>
<OrdersView>
<OrdersViewRow>
<Id>107</Id>
<DateOrdered>2012-12-13</DateOrdered>
<Total>142171</Total>
</OrdersViewRow>
<OrdersViewRow>
<Id>183</Id>
<DateOrdered>2013-02-24</DateOrdered>
<Total>3742</Total>
</OrdersViewRow>
<OrdersViewRow>
<Id>184</Id>
<DateOrdered>2012-11-19</DateOrdered>
<Total>987</Total>
</OrdersViewRow>
<OrdersViewRow>
<Id>185</Id>
<DateOrdered>2012-08-08</DateOrdered>
<Total>2525.25</Total>
</OrdersViewRow>
<OrdersViewRow>
<Id>186</Id>
<DateOrdered>2012-04-26</DateOrdered>
<Total>307.25</Total>
</OrdersViewRow>
<OrdersViewRow>
<Id>187</Id>
<DateOrdered>2012-12-23</DateOrdered>
<Total>3872.9</Total>
</OrdersViewRow>
<OrdersViewRow>
<Id>188</Id>
<DateOrdered>2013-01-14</DateOrdered>
<Total>12492</Total>
</OrdersViewRow>
...
</OrdersView>
</CustomersViewRow>
...

10.4.3.5 双方向ビュー・リンクでの属性マップ手法の使用

ビュー・オブジェクトが、双方向に構成されたビュー・リンクを通して関連付けられている場合は、属性マップを使用するwriteXML()方式を使用する必要があります。双方向ビュー・リンクの状況でwriteXML()方式を使用し、最大深度に-1を指定して存在するビュー・リンクの全レベルを含めるようにすると、writeXML()メソッドは、双方向のビュー・リンクを前後に移動して無限ループに陥り、メモリーを使い果すまで重複したデータを含む深くネストしたXMLを生成します。このような場合は、かわりに属性マップを指定してwriteXML()を使用してください。この方法を使用すること以外に、XMLに含める、または含めないビュー・リンク・アクセッサを制御し、XML生成中の無限再帰を回避する方法はありません。

10.4.3.6 生成されたXMLのXSLTスタイルシートによる変換

writeXML()によって生成される正規のXML書式が要件を満たさない場合は、オプションの引数として、XSLTスタイルシートを提供できます。通常と同じようにXMLが生成されますが、最終的なXMLが呼出し元に返される前に、指定したスタイルシートを使用して結果の変換が行われます。

次の例に示すXSLTスタイルシートについて考えます。これは、「生成されるXMLの属性マップによるきめ細かい制御」で生成されるXMLのルート要素と一致して、新しいCustomerNames要素を結果に作成する、テンプレートが1つのみの簡単な変換です。このテンプレートは、xsl:for-each命令を使用してすべてのCustomersView要素を処理します。対象であることが確認されたCustomersView要素ごとに、結果にCustomerNames要素を作成し、そのContact属性に、CustomersViewのName子要素の値を移入します。

<?xml version="1.0" encoding="windows-1252" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<CustomerNames>
<xsl:for-each
select="/CustomersView/CustomersViewRow)">
<xsl:sort select="Name"/>
<Customer Contact="{Name}"/>
</xsl:for-each>
</CustomerNames>
</xsl:template>
</xsl:stylesheet>

次の例は、writeXML()をコールするとこのXSLTスタイルシートを実行するTestClientWriteXMLクラスの興味深い行を示しています。

// In TestClientWriteXML.java
XSLStylesheet xsl = getXSLStylesheet();
printXML(vo.writeXML(XMLInterface.XML_OPT_ALL_ROWS,viewDefMap,xsl));

前述の例のコードを実行すると、次のような変換されたXMLが生成されます。

<CustomerNames>
<Customer Contact="ABC Company"/>
<Customer Contact="Acme Outfitters"/>
<Customer Contact="Acme Sporting Goods"/>
<Customer Contact="All Baseball"/>
...
<Customer Contact="The Sports Emporium"/>
<Customer Contact="Unisports"/>
<Customer Contact="Value Valley"/>
<Customer Contact="Wally's Mart"/>
<Customer Contact="Wally's Weights"/>
<Customer Contact="Westwind Sports"/>
<Customer Contact="Womansport"/>
<Customer Contact="Your Choice Sporting Goods"/>
<Customer Contact="Z-Mart"/>
<Customer Contact="Zibbers"/>
<Customer Contact="Zip City"/>
</CustomerNames>

次の例で示されているgetXSLStylesheet()ヘルパー・メソッドも、実行時にクラスパスからXSLTスタイルシートなどのリソースを読み込む方法を学習するためのよい例です。このコードでは、Example.xslスタイルシートがTestClientWriteXMLクラスと同じディレクトリにあるものと想定しています。.class演算子を使用してTestClientWriteXMLクラスのClassオブジェクトを参照することで、コードはgetResource()メソッドを使用してリソースに対するURLを取得します。その後、URLをXSLProcessorクラスのnewXSLStylesheet()メソッドに渡して、返すための新しいXSLStylesheetオブジェクトを作成します。このオブジェクトは、*.xslファイルから読み込まれたXSLTスタイルシートのコンパイル済バージョンを表しています。

private static XSLStylesheet getXSLStylesheet()
throws XMLParseException, SAXException,IOException,XSLException {
String xslurl = "Example.xsl";
URL xslURL = TestClientWriteXML.class.getResource(xslurl);
XSLProcessor xslProc = new XSLProcessor();
return xslProc.newXSLStylesheet(xslURL);
}

注意:

XSLTスタイルシートのように、コンパイル済のJavaクラスやXMLメタデータとともに出力ディレクトリに格納するリソースを扱うときは、「プロジェクト・プロパティ」ダイアログの「コンパイラ」ページで、「ファイル・タイプの出力ディレクトリへのコピー」フィールドを更新し、セミコロンで区切られたリストに.xslを含めることができます。

10.4.3.7 単一行に対するXMLの生成

writeXML()は、ビュー・オブジェクトで呼び出すのみでなく、同じパラメータおよびオプションを指定して、任意のRowで呼び出すこともできます。writeXML()を呼び出すRowオブジェクトがエンティティ行である場合、変更したエンティティ属性のみをXMLで使用する場合は、追加のXMLInterface.XML_OPT_CHANGES_ONLYフラグをビット単位のORで指定できます。

10.4.4 XMLドキュメントを使用して変更を適用する方法

ビュー・オブジェクトがXMLドキュメントを使用して挿入、更新、および削除を行うようにするには、readXML()メソッドを使用します。

void readXML(Element elem, int depthcount)

readXML()が受け入れる正規の書式は、同じビュー・オブジェクトでwriteXML()メソッドを呼び出すと生成されるものと同じです。処理するXMLドキュメントが正規の書式に対応していない場合は、readXML()に対するオプションの第3引数としてXSLTスタイルシートを提供し、ファイルを読み込んで処理する前に、入力XMLドキュメントを正規の書式に変換できます。

10.4.5 XMLドキュメントを使用するときに行われる処理

ビュー・オブジェクトは、正規の書式のXMLドキュメントを使用するとき、ドキュメントを処理して、行要素、その属性要素の子、およびビュー・リンク・アクセッサ属性を表すネストされた要素を認識します。depthcountパラメータで指定されている最大レベルまで、再帰的にドキュメントを処理します。XMLドキュメントの全レベルを処理するよう要求するには、depthcountに-1を渡します。

10.4.5.1 ViewObject.readXML()によるXMLドキュメントの処理方法

認識する行要素ごとに、readXML()メソッドは次の処理を行います。

- 行を処理するために関連するビュー・オブジェクトを識別します。

- 子属性要素を読み取り、行の主キー属性の値を取得します。

- 主キー属性を使用してfindByKey()を実行し、行がすでに存在するかどうかを判定します。

- 行が存在する場合は、次の処理を行います。

- 行要素にマーカー属性bc4j-action="remove"が含まれる場合は、既存の行を削除します。

- それ以外の場合は、XMLの現在の行要素の、属性要素の子の値を使用して、行の属性を更新します。

- 行が存在しない場合は、新しい行を作成し、ビュー・オブジェクトの行セットに挿入します。その属性は、XMLの現在の行要素の、属性要素の子の値を使用して移入します。

10.4.5.2 単一行でXMLを処理するためのreadXML()の使用

Rowオブジェクトに対しても、同じreadXML()メソッドを使用できます。このメソッドが受け入れる正規のXMLの書式は、同じ行に対してwriteXML()を呼び出すと生成される書式と同じです。行でreadXML()メソッドを呼び出し、次の処理を行うことができます。

- 属性の値をXMLで更新します。

- 対応する行要素にbc4j-action="remove"マーカー属性がある場合は、行を削除します。

- ビュー・リンク・アクセッサを介して、ネストされた行を挿入、更新、または削除します。

次の例に示すXMLドキュメントについて考えます。これは、CustomersViewビュー・オブジェクトの単一行で期待される正規の書式です。ルートのCustomersViewRow要素の内部にネストされているCity属性は、顧客の住む市を表します。ネストされたOrdersView要素はOrdersViewビュー・リンク・アクセッサ属性に対応し、3つのOrdersViewRow要素を含みます。それぞれが、OrdersView行の主キーを表すId要素を含みます。

<CustomersViewRow>
<Id>16</Id>
<!-- This will update Customer's ConfirmedEmail attribute -->
<City>Houston</City>
<OrdersView>
<!-- This will be an update since it does exist -->
<OrdersViewRow>
<Id>1018</Id>
<DateShipped>2013-03-13</DateShipped>
</OrdersViewRow>
<!-- This will be an insert since it doesn't exist -->
<OrdersViewRow>
<Id>9999</Id>
<CustomerId>16</CustomerId>
<Total>9999.00</Total>
</OrdersViewRow>
<!-- This will be deleted -->
<OrdersViewRow bc4j-action="remove">
<Id>1008</Id>
</OrdersViewRow>
</OrdersView>
</CustomersViewRow>

次の例は、TestClientReadXMLクラスの興味深いコード行を示しています。このクラスは、CustomersViewビュー・オブジェクトの特定の行に、このXMLデータグラムを適用します。TestClientReadXMLクラスが実行する基本的な手順は次のとおりです。

1. キーにより、ターゲット行を検索します(たとえば、顧客であるThe Sports Emporium)。

2. 変更を適用する前に、行に対して生成されたXMLを表示します。

3. ヘルパー・メソッドを使用して適用する変更を含む解析されたXMLドキュメントを取得します。

4. 行に変更を適用するためにXMLドキュメントを読み込みます。

5. 適用された保留中変更を含むXMLを表示します。
TestClientReadXMLクラスは、「問合せ済データのXMLの生成方法」で説明されているXMLInterface.XML_OPT_ASSOC_CONSISTENTフラグを使用して、ポストされていない新しい行をXMLに含めています。

ViewObject vo = am.findViewObject("CustomersView");
Key k = new Key(new Object[] { 16 });
// 1. Find a target row by key (e.g. for customer "The Sports Emporium")
Row sports = vo.findByKey(k, 1)[0];
// 2. Show the XML produced for the row before changes are applied
printXML(sports.writeXML(-1, XMLInterface.XML_OPT_ALL_ROWS));
// 3. Obtain parsed XML document with changes to apply using helper method
Element xmlToRead = getInsertUpdateDeleteXMLGram();
printXML(xmlToRead);
// 4. Read the XML document to apply changes to the row
sports.readXML(getInsertUpdateDeleteXMLGram(), -1);
// 5. Show the XML with the pending changes applied
printXML(sports.writeXML(-1, XMLInterface.XML_OPT_ALL_ROWS |
XMLInterface.XML_OPT_ASSOC_CONSISTENT));

前述の例のコードを実行すると、最初に、The Sports Emporiumの変更前の情報が表示されます。次の点に注意してください。

- City属性の値はLapeerです。

- オーダーID 1018にはShippedDate属性がありません。

- オーダーID 1008にはオーダー行があり、

- オーダーID 9999に関連するオーダー行はありません。

<CustomersViewRow>
<Id>16</Id>
<Name>The Sports Emporium</Name>
<Address>222 E Nepessing St</Address>
<City>Lapeer</City>
<State>MI</State>
<CountryId>4</CountryId>
<ZipCode>48446</ZipCode>
<CreditRatingId>1</CreditRatingId>
<SalesRepId>13</SalesRepId>
<OrdersView>
<OrdersViewRow>
<Id>1018</Id>
<CustomerId>16</CustomerId>
<DateOrdered>2013-02-25</DateOrdered>
<SalesRepId>11</SalesRepId>
<Total>195.99</Total>
<PaymentTypeId>2</PaymentTypeId>
<PaymentOptionId>1009</PaymentOptionId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>1008</Id>
<CustomerId>16</CustomerId>
<DateOrdered>2013-02-26</DateOrdered>
<SalesRepId>14</SalesRepId>
<Total>100.97</Total>
<PaymentTypeId>2</PaymentTypeId>
<PaymentOptionId>1009</PaymentOptionId>
<OrderFilled>N</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>1023</Id>
<CustomerId>16</CustomerId>
<DateOrdered>2013-01-11</DateOrdered>
<DateShipped>2013-01-15</DateShipped>
<SalesRepId>11</SalesRepId>
<Total>2451.97</Total>
<PaymentTypeId>2</PaymentTypeId>
<PaymentOptionId>1009</PaymentOptionId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
</OrdersView>
</CustomersViewRow>

readXML()を使用してXMLドキュメントの変更を行に適用した後、writeXML()を使用して再びXMLを表示すると、次のようになります。

- City属性には、今度はHoustonが表示されます。

- オーダー9999の新規オーダー行が作成されました。

- オーダー行1018の出荷日は2013-03-13に設定され、

- オーダー1008のオーダー行は削除されました。

<CustomersViewRow>
<Id>16</Id>
<Name>The Sports Emporium</Name>
<Address>222 E Nepessing St</Address>
<City>Houston</City>
<State>MI</State>
<CountryId>4</CountryId>
<ZipCode>48446</ZipCode>
<CreditRatingId>1</CreditRatingId>
<SalesRepId>13</SalesRepId>
<OrdersView>
<OrdersViewRow>
<Id>9999</Id>
<CustomerId>16</CustomerId>
<Total>9999.00</Total>
</OrdersViewRow>
<OrdersViewRow>
<Id>1018</Id>
<CustomerId>16</CustomerId>
<DateOrdered>2013-02-25</DateOrdered>
<DateShipped>2013-03-13</DateShipped>
<SalesRepId>11</SalesRepId>
<Total>195.99</Total>
<PaymentTypeId>2</PaymentTypeId>
<PaymentOptionId>1009</PaymentOptionId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
<OrdersViewRow>
<Id>1023</Id>
<CustomerId>16</CustomerId>
<DateOrdered>2013-01-11</DateOrdered>
<DateShipped>2013-01-15</DateShipped>
<SalesRepId>11</SalesRepId>
<Total>2451.97</Total>
<PaymentTypeId>2</PaymentTypeId>
<PaymentOptionId>1009</PaymentOptionId>
<OrderFilled>Y</OrderFilled>
</OrdersViewRow>
</OrdersView>
</CustomersViewRow>

注意:

この例では、readXML()を使用して単一の行に変更を適用する場合が示されています。XMLドキュメントに、ラップするCustomersView行が含まれ、そのネストされた1つ以上のCustomersViewRow要素のそれぞれに主キー属性が含まれている場合は、CustomersViewビュー・オブジェクトのreadXML()メソッドを使用してドキュメントを処理し、複数のCustomersView行に対する操作を処理できます。

10.5 カスタム・データ・ソースおよびFramework Base Class ProgrammaticViewObjectImplを使用したプログラム的操作

ADFビジネス・コンポーネントはユーザーが作成できるプログラム・ビュー・オブジェクトをサポートして、カスタム・データ・ソースと対話します。

フレームワーク・ベース・クラスoracle.jbo.server.ProgrammaticViewObjectImplおよびoracle.jbo.serverProgrammaticViewRowImplを使用すれば、カスタム・データ・ソースとの対話の制御や、データ収集を戻すことが可能になります。ADFはデータ・オブジェクトを内部的にViewRowに変換します。

こうしたフレームワーク・ベース実装クラスは、アプリケーション開発者に対してカスタム・データ・ソースとの対話と操作の実行を行うための特定のフック・ポイントを提供します。フレームワーク・ベース・クラスを使用した場合、ADFは所定のコレクションに対するアクティブ化/受動化などの機能をサポートします。以前とは異なり、開発者は行をプログラム的に自動入力するために、ビュー・オブジェクト・ライフサイクルの様々な段階に対する理解を必要とする、多様なメソッドをコード化する必要がありません。

注意:

ProgrammaticViewObjectImplベース・クラスの前に、アプリケーションはベース・クラスoracle.jbo.server.ViewObjectImplから拡張し、カスタム動作の多くのライフサイクルをオーバーライドしています。プログラム的にビュー・オブジェクトを使用するということは、様々なステージのビュー・オブジェクト・ライフサイクルを理解する必要なく、カスタム・データ・ソースとの統合がアプリケーション開発者により実行されることを意味します。

ADFモデル・オブジェクトのビュー・オブジェクトをプログラム的に操作するには、ビュー・オブジェクトの作成ウィザードでプログラムオプションを選択します。こうすると、ウィザードで生成するビュー・オブジェクトJavaクラスは、クラシック・スタイルのフレームワーク・クラスoracle.jbo.server.ViewObjectImplおよびoracle.jbo.server.ViewRowImplではなく、フレームワーク・ベース・クラスoracle.jbo.server.ProgrammaticViewObjectImplおよびoracle.jbo.server.ProgrammaticViewRowImplからデフォルトで拡張します。

注意:

ビュー・オブジェクトをプログラム的に作成する際にこの動作を確実に実行するには、ADFビジネス・コンポーネントの設定ダイアログで、ベース・クラスoracle.jbo.server.ViewObjectImplからの拡張を有効にする機能を選択解除する必要があります。ツール-設定ダイアログのADFビジネス・コンポーネント-ビュー・オブジェクトページのオプションはクラシック・プログラム・ビューです(選択解除してProgrammaticViewObjectImplからの拡張を可能にする)。

10.5.1 ProgrammaticViewObjectImplを拡張してビュー・オブジェクト・クラスを作成する方法

oracle.jbo.server.ProgrammaticViewObjectImplまたはoracle.jbo.server.ProgrammaticViewRowImpを拡張するビュー・オブジェクトをプログラム的に作成するには、ビュー・オブジェクト作成ウィザードを使用して、プログラムデータ・ソース・オプションを選択します。

始める前に:

クラシック・スタイルのプログラム的なビュー・オブジェクト生成を無効にする必要があります。ツール-設定ダイアログのADFビジネス・コンポーネント-ビュー・オブジェクトページで、オプションクラシック・プログラム・ビューの選択を解除します。このオプションを選択したまま(デフォルト)にしておくと、JDeveloperはoracle.jbo.server.ViewObjectImplおよびoracle.jbo.server.ViewRowImplを拡張するビュー・オブジェクトJavaクラスを生成します。クラシック・モードの詳細は、「代替データ・ソースに対するクラシック・スタイル・プログラムでのビュー・オブジェクトの使用」を参照してください。

ProgrammaticViewObjectImplを拡張してプログラムによるビュー・オブジェクトを作成するには:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で「ビジネス層」を展開し、「ADFビジネス・コンポーネント」、「ビュー・オブジェクト」を選択して、「OK」をクリックします。

3. ビュー・オブジェクト作成ウィザードの「名前」ページで、ビュー・オブジェクトの名前とパッケージを入力します。データ・ソースについて、「プログラム関連」を選択します。

4. 「属性」ページで、「新規」を複数回クリックし、プログラムによるビュー・オブジェクトが必要とするビュー・オブジェクト属性を定義します。

5. 「属性の設定」ページで、定義した属性に必要な設定を調節します。

6. 「Java」ページで「ビュー・オブジェクト・クラスの生成」を選択して、カスタム・ビュー・オブジェクト・クラス(ProgrammaticViewObjectImpl)にコードを含められるようにします。

7. 「終了」をクリックして、ビュー・オブジェクトを作成します。
ビュー・オブジェクトのカスタムJavaクラスで、「ProgrammaticViewObjectImplベースのビュー・オブジェクトをオーバーライドする主要なフレームワーク・メソッド」で説明されているメソッドをオーバーライドし、独自のデータ取得方法を実装します。

10.5.2 ProgrammaticViewObjectImplベースのビュー・オブジェクトをオーバーライドする主要なフレームワーク・メソッド

ビュー・オブジェクトのアクセス・モードプロパティの設定方法に応じて、次の2つのメソッドのいずれかがオーバーライドされます。

アクセス・モード・プロパティは、ビュー・オブジェクト・クエリによって戻される行数を決定します。このプロパティのデフォルト設定であるSCROLLABLEでは、読み込むビュー・オブジェクトの行数がキャッシュされます。RANGEPAGING設定は、範囲サイズで指定された行数をフェッチします。アクセス・モードの詳細は、「大きい結果セットを効率的にスクロールするための範囲ページ移動の使用方法」を参照してください。

SCROLLABLE

アクセス・モードがSCROLLABLEの場合は、getScrollableData() APIをオーバーライドして具体的な実装を提供する必要があります。

- protected Collection<Object> getScrollableData(ScrollableDataFilter dataFilter)
スクロール可能なプログラムによるビュー・オブジェクトの場合、フレームワークは次のAPIコールの結果として完全なdatasetを提供する拡張機能を期待します。フレームワークは、クライアントがコレクション内の次の行または前の行を問い合せた際にAPIコールを内部的に管理します。

RANGEPAGING

アクセス・モードがRANGEPAGINGの場合、アプリケーションは次の2つのAPIメソッドを一緒にオーバーライドする必要があります。

- /Apps should return the collection within a current Range.
protected Collection<Object> getRangePagingData(RangePagingDataFilter dataFilter)

- protected Collection<Object> retrieveDataByKey(Key key , int size).

ページ範囲移動ビュー・オブジェクトの場合、フレームワークは現在の範囲の行コレクションのみを提供する拡張機能を期待します。フレームワークに異なる範囲の行が必要な場合、次のフォローアップAPIコールが行われます。現在の範囲の開始インデックスおよびサイズ情報は、引数として渡されるRangePagingDataFilterオブジェクトから取得できます。

10.5.3 ProgrammaticViewRowImplベースのビュー・オブジェクトをオーバーライドする主要なフレームワーク・メソッド

フレームワーク・ベース・クラスoracle.jbo.server.ProgrammaticViewRowImplはプログラム的なViewRowの実装クラスです。

Oracle ADFは様々なライフサイクル・フェーズ間にプログラム的なビュー行と対話するための複数のフックポイントを提供します。次のすべてのAPIメソッドでオーバーライドが必須だというわけではありません。

- createRowData(HashMap attrNameValueMap)
ユース・ケースでプログラム的なビュー・オブジェクトの作成が必要な場合は、次のAPIをオーバーライドします。このフックポイントでは、アプリケーションがこの新たに作成された行のDataProviderを作成し、それをフレームワークに返してさらに管理することができます。

- updateDataProvider(Object rowDataProvider , ViewAttributeDefImpl attrDef , Object newValue)
基礎となるエンティティ・オブジェクトなしでプログラム的なビュー・オブジェクトが作成された場合は、このAPIをオーバーライドして、行の変更された属性値を保持します。アプリケーションは次のAPIをオーバーライドして、newvalueをDataProviderに更新する必要があります。

- convertToSourceType(ViewAttributeDefImpl vad, String sourceType , Object val)
アプリケーションは必要に応じて次のAPIをオーバーライドし、値をJavaTypeからsourceTypeに変換するカスタム実装を提供する必要があります。フレームワークはDataProviderのvalueを更新する前に、このフックポイントを呼び出します。

- convertToAttributeType(AttributeDefImpl attrDef, Class javaTypeClass , Object val)
アプリケーションは必要に応じて次のAPIをオーバーライドし、値をsourceTypeからJavaTypeに変換するカスタム実装を提供する必要があります。フレームワークは値をDataProviderからフェッチするときに、このフックポイントを呼び出します。

10.6 代替データ・ソースに対するクラシック・スタイル・プログラムでのビュー・オブジェクトの使用

デフォルトのビュー・オブジェクトは、データベースからデータを読み取り、データベースの結果セットを処理するためにJava Database Connectivity (JDBC)レイヤーを使用するタスクを自動化します。これに対し、カスタムJavaクラスで適切なメソッドをオーバーライドすることにより、REF CURSOR、メモリー内の配列、Javaの*.propertiesファイルなどの様々な代替データソースからプログラムでデータを取得するビュー・オブジェクトを作成できます。

注意:

代替データ・ソースについて説明している項は、以前の目的のために残されています。JDeveloperリリース12.2.1.1.0から、ADF Business Componentsではプログラム的なビュー・オブジェクトに対する拡張サポートが提供されるようになりました。プログラム的なビュー・オブジェクトの新たなフレームワーク・ベース・クラスは、カスタム・データ・ソースに対する共通メソッドを実装し、ビュー・オブジェクト・ライフサイクルの様々な段階でビュー行と対話するためのフックポイントを提供します。この機能はツール-設定ダイアログの「ビュー・オブジェクト」ページで有効にする必要があります。詳細は、「ProgrammaticViewObjectImplを拡張してビュー・オブジェクト・クラスを作成する方法」を参照してください。

プログラムによるビュー・オブジェクトをデータベース以外で操作できるようにする一般的なプロセスでは、データ・ソースにビュー・オブジェクトのデフォルトのライフサイクル・メソッドのオーバーライドが含まれます。ライフサイクル・メソッドの詳細は、「プログラムのビュー・オブジェクト用にオーバーライドする主要なフレームワーク・メソッド」を参照してください。

代替データ・ソースに対してプログラムによるビュー・オブジェクトを有効にするには、次の一般的なプロセスに従います。

1. ビュー・オブジェクト・ウィザードでビュー・オブジェクトを作成し、データ・ソースに対して「プログラム関連」を選択します。

2. ビュー・オブジェクトの概要エディタで、カスタム・ビュー・オブジェクト実装クラス(ViewObjImpl.java)を生成します。

3. カスタム・ビュー・オブジェクト実装クラスで、create()をオーバーライドして、プログラムによるビュー・オブジェクトに必要な状態を初期化します。少なくとも、このビュー・オブジェクトのSQL問合せのトレースをすべて削除します。

4. executeQueryForCollection()をオーバーライドし、setUserDataForCollection()をコールして、カスタム問合せの結果をUserDataオブジェクトに関連付けます。

5. hasNextForCollection()をオーバーライドし、UserDataオブジェクトを反復して、取得する他のレコードをテストします。hasNextForCollection()がtrueを返す間、次の操作が行われます。

a. createRowFromResultSet()をオーバーライドして、ビュー・オブジェクト問合せコレクションに行を作成します。

b. オーバーライドされたcreateRowFromResultSet()メソッドで、getUserDataForCollection()メソッドをコールして格納されているUserDataオブジェクトのインスタンスを取得し、createNewRowForCollection()をコールして新しい空白行を作成します。

c. 必要に応じて、各レコードをADFビジネス・コンポーネント・ビュー・オブジェクト属性でサポートされている属性データ型に変換し、populateAttributeForRow()をコールして問合せコレクションに属性値を格納します。

d. hasNextForCollection()がfalseを返す場合は、setFetechCompleteForCollection()をコールすることで問合せコレクションが移入されたことをビュー・オブジェクトに通知します。

6. releaseUserDataForCollection()をオーバーライドして結果セットをリリースします。

ビュー・オブジェクト・コンポーネントは、実行時に複数のアクティブな行セットと関連付けられる可能性があるため、これらのライフサイクル・メソッドの多くは、Objectパラメータ(問合せコレクション)を受け取ります。このパラメータで、ADFビジネス・コンポーネント・フレームワークは、カスタム・コードが設定する行のコレクションと、特定のコレクションにどの行が移入されるかに影響する可能性のあるバインド変数値の配列を渡します。

UserDataオブジェクトを行の各コレクションとともに格納して、カスタム・データ・ソース実装が必要なデータ・ソース・コンテキスト情報を関連付けられるようにすることができます。フレームワークでは、このコレクションごとのコンテキスト情報を取得および設定するために、setUserDataForCollection()メソッドとgetUserDataForCollection()メソッドが提供されています。オーバーライドされたフレームワーク・メソッドのいずれかが呼び出されるたびに、getUserDataForCollection()メソッドを使用して、フレームワークが移入する行のコレクションと関連付けられた正しいResultSetオブジェクトを取得できます。

10.6.1 プログラムで読取り専用のビュー・オブジェクトを作成する方法

プログラムで読取り専用のビュー・オブジェクトを作成するには、ビュー・オブジェクト作成ウィザードを使用します。

プログラムで読取り専用のビュー・オブジェクトを作成するには:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で「ビジネス層」を展開し、「ADFビジネス・コンポーネント」、「ビュー・オブジェクト」を選択して、「OK」をクリックします。

3. ビュー・オブジェクト作成ウィザードの「名前」ページで、ビュー・オブジェクトの名前とパッケージを入力します。データ・ソースについて、「プログラム関連」を選択します。

4. 「属性」ページで、「新規」を複数回クリックし、プログラムによるビュー・オブジェクトが必要とするビュー・オブジェクト属性を定義します。

5. 「属性の設定」ページで、定義した属性に必要な設定を調節します。

6. 「Java」ページで「ビュー・オブジェクト・クラスの生成」を選択して、カスタム・ビュー・オブジェクト・クラス(ViewObjImpl)にコードを含められるようにします。

7. 「終了」をクリックして、ビュー・オブジェクトを作成します。

ビュー・オブジェクトのカスタムJavaクラスで、「プログラムのビュー・オブジェクト用にオーバーライドする主要なフレームワーク・メソッド」で説明されているメソッドをオーバーライドし、独自のデータ取得方法を実装します。

10.6.2 プログラムでエンティティ・ベースのビュー・オブジェクトを作成する方法

プログラムでデータを取得するエンティティ・ベースのビュー・オブジェクトを作成するには、通常の方法でビュー・オブジェクトを作成し、カスタムJavaクラスを有効にし、次の項で説明されているメソッドをオーバーライドして独自のデータ取得方法を実装します。

10.6.3 プログラムのビュー・オブジェクト用にオーバーライドする主要なフレームワーク・メソッド

プログラムによるビュー・オブジェクトでは、通常、ViewObjectImplベース・クラスの次のメソッドをすべてオーバーライドして、データ取得の独自方法を実装します。

- create()
このメソッドは、ビュー・オブジェクトのインスタンスが作成されるときに呼び出され、プログラムによるビュー・オブジェクトが必要とする任意の状態を初期化するために使用できます。このオーバーライドされるメソッドには、少なくとも次の行を組み込んで、プログラムによるビュー・オブジェクトが関係するSQL問合せをトレースしないようにします。

// Wipe out all traces of a query for this VO
getViewDef().setQuery(null);
getViewDef().setSelectClause(null);
setQuery(null);

- executeQueryForCollection()
このメソッドは、ビュー・オブジェクトの問合せを実行する(または再実行する)必要があるたびにコールされます。実装では、このメソッドをオーバーライドせず、問合せを完全に変更するか、パラメータ・リストを変更する必要があります。実装のベスト・プラクティスは、「executeQueryForCollection()メソッドのオーバーライド」を参照してください。

- hasNextForCollection()
このメソッドは、このビュー・オブジェクトから作成される行セットの行セット・イテレータでhasNext()メソッドをサポートするために呼び出されます。実装では、プログラムのデータ・ソースから取得する行がまだある場合はtrueを返します。

- createRowFromResultSet()
このメソッドは、取得されたデータの各行を移入するために呼び出されます。実装では、createNewRowForCollection()を呼び出して新しい空白の行を作成した後、populateAttributeForRow()を呼び出して行に対するデータの各属性を移入します。populateAttributeForRow()のコールでは、各属性に、ADFビジネス・コンポーネント・ビュー・オブジェクトで許可されている正しい型の値を移入する必要があります。メソッドは、データ型変換を処理しないため、各値のデータ型が許可されるビュー・オブジェクト属性タイプと一致することはプログラムで確認する必要があります。

- getQueryHitCount()
このメソッドは、getEstimatedRowCount()メソッドをサポートするために呼び出されます。実装では、プログラムによるビュー・オブジェクトの問合せで取得される行数のカウントまたは予想されるカウントを返します。

- getCappedQueryHitCount()
この行カウントの問合せは、グローバルな行フェッチ制限によって指定されている上限値を超える行が問合せによって返されるかどうかを判断するために最適化されています。制限より多くの行が返される可能性がある場合、メソッドは負の数値を返します。ユーザー・インタフェースのスクロール・バーでは、正確なスクロール位置を示すための行カウント問合せを使用できない場合がありますが、この行カウント問合せは大規模な表でも適切に機能します。この実装により、Cap値を確認し、実際の行カウントを返すことができます。フレームワークでは、adf-config.xmlファイルで指定された行フェッチ制限からCap値が取得されます。oldCapは使用されないことに注意してください。

このメソッドは、値がCap以下の場合に行カウントを返し、それ以外の場合は負の数値を返します。実装では、この情報を使用して、パフォーマンスの高い行カウント問合せを構築できます。パフォーマンスが重要でないときには、getQueryHitCount()と同じ値を返すだけの場合もありますが、getCappedQueryHitCount()では、検索される行数に関する追加情報も得られるようになりました。たとえば、DEPT表に100万行が含まれているとします。getQueryHitCount()をコールすると、フレームワークにより、データベースに対してSELECT COUNT(*) FROM DEPTが実行され、100万行すべてが返されます。しかし、最大500行を表示する予定であれば、グローバルな行フェッチ制限を設定してgetCappedQueryHitCount()をコールできます。この場合は、フレームワークによりSELECT COUNT(*) FROM DEPT WHERE ROWNUM <= 500が実行されます。この問合せはずっと高速に完了し、パフォーマンスも向上します。このメソッドは、ビュー・オブジェクト問合せを、SELECT COUNT(*) FROM (SELECT DEPTNO, LOC FROM DEPT) WHERE ROWNUM <= :cap (SELECT DEPTNO, LOC FROM DEPTがビュー・オブジェクト問合せ文とする)のようなネストされた句にラップします。

- protected void releaseUserDataForCollection()
コードでは、各行セットでユーザー・データ・コンテキスト・オブジェクトを格納および取得できます。このメソッドを呼び出すと、閉じられた行セットと関連付けられているリソースを解放できます。

以降の項の各例では、これらのメソッドをオーバーライドして、異なる種類のプログラムによるビュー・オブジェクトを実装しています。

10.6.4 REF CURSORでのビュー・オブジェクトの作成方法

アプリケーションでは、ストアド・プロシージャ内にカプセル化された問合せの結果を使用することが必要になる場合があります。PL/SQLを使用すると、カーソルを開いて問合せの結果を反復処理し、このカーソルへの参照をクライアントに返すことができます。このいわゆるREF CURSORは、クライアントが問合せの結果を反復処理するために使用できるハンドルです。これは、クライアントが元のSQL SELECT文を実際に発行していない場合であっても可能です。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.viewobjectonrefcursorパッケージを参照します。

REF CURSORを返すファンクションを含むPL/SQLパッケージの宣言は簡単です。パッケージは次の例のようになります。

CREATE OR REPLACE PACKAGE RefCursorExample IS
TYPE ref_cursor IS REF CURSOR;
FUNCTION get_orders_for_customer(p_custId NUMBER) RETURN ref_cursor;
FUNCTION count_orders_for_customer(p_custId NUMBER) RETURN NUMBER;
END RefCursorExample;
.
/
show errors
CREATE OR REPLACE PACKAGE BODY RefCursorExample IS
FUNCTION get_orders_for_customer(p_custIdl NUMBER) RETURN ref_cursor IS
the_cursor ref_cursor;
BEGIN
OPEN the_cursor FOR
SELECT o.id, o.date_ordered, o.total
FROM s_ord o, s_customer c
WHERE o.customer_id = c.id
AND c.id = p_custId;
RETURN the_cursor;
END get_orders_for_customer;

FUNCTION count_orders_for_customer(p_custId NUMBER) RETURN NUMBER IS
the_count NUMBER;
BEGIN
SELECT COUNT(*)
INTO the_count
FROM s_ord o, s_customer c
WHERE o.customer_id = c.id
AND c.id = p_cust_id;
RETURN the_count;
END count_orders_for_customer;
END RefCursorExample;
.
/
show errors

Orderエンティティ・オブジェクトに対するエンティティ・オブジェクトの慣用名を使用してエンティティ・ベースのOrdersForCustomerビュー・オブジェクトを定義した後、そのカスタムJavaクラスOrdersForCustomerImpl.javaに移動します。次に、以降の項で説明するように、ビュー・オブジェクトのメソッドをオーバーライドします。

10.6.4.1 create()メソッドのオーバーライド

create()メソッドは、このビュー・オブジェクトに対するSQL問合せのすべてのトレースを削除します。次の例は、この目的でcreate()メソッドをオーバーライドする方法を示しています。

protected void create() {
getViewDef().setQuery(null);
getViewDef().setSelectClause(null);
setQuery(null);
}

10.6.4.2 executeQueryForCollection()メソッドのオーバーライド

executeQueryForCollection()メソッドは、このビュー・オブジェクトに基づいて、フレームワークが問合せコレクションのデータベース問合せを発行する必要があるときに実行されます。1つのビュー・オブジェクトは、多数の関連結果セットを生成でき、それぞれが異なるバインド変数値の結果である可能性があります。問合せの行セットがフレームワーク調整したマスター/ディテール・ビュー・リンクと関連性がある場合、params配列には、ソース・ビュー・オブジェクトのバインド・パラメータのフレームワークが提供した1つ以上の名前と値のペアが含まれます。ユーザーが提供したバインド・パラメータ値がある場合、これはparams配列においてフレームワークが提供したバインド変数値よりも優先され、ユーザー・パラメータの数はnumUserParams引数の値によって示されます。

このメソッドは、ヘルパー・メソッドretrieveRefCursor()を呼び出して、ストアド・ファンクションを実行してREF CURSOR戻り値を返し、JDBC ResultSetとしてキャストします。次の例は、この目的でexecuteQueryForCollection()メソッドをオーバーライドする方法を示しています。

protected void executeQueryForCollection(Object qc,Object[] params,
int numUserParams) {
storeNewResultSet(qc,retrieveRefCursor(qc,params));
super.executeQueryForCollection(qc, params, numUserParams);
}

次に、ヘルパー・メソッドstoreNewResultSet()を呼び出します。このヘルパー・メソッドは、setUserDataForCollection()メソッドを使用して、フレームワークが問合せの実行を要求している行のコレクションとともにこのResultSetを格納します。次の例は、この目的でstoreNewResultSet()メソッドを定義する方法を示しています。

private void storeNewResultSet(Object qc, ResultSet rs) {
ResultSet existingRs = getResultSet(qc);
// If this query collection is getting reused, close out any previous rowset
if (existingRs != null) {
try {existingRs.close();} catch (SQLException s) {}
}
setUserDataForCollection(qc,rs);
hasNextForCollection(qc); // Prime the pump with the first row.
}

retrieveRefCursor()メソッドは、「ストアド・プロシージャとストアド・ファンクションの呼出し」で説明されているヘルパー・メソッドを使用して、ストアド・ファクションを起動し、REF CURSORを返します。次の例は、この目的でretrieveRefCursor()メソッドを定義する方法を示しています。

private ResultSet retrieveRefCursor(Object qc, Object[] params) {
ResultSet rs = (ResultSet)callStoredFunction(OracleTypes.CURSOR,
"RefCursorExample.get_orders_for_customer(?)",
new Object[]{getNamedBindParamValue("bv_custId",params)});
return rs ;
}

10.6.4.3 createRowFromResultSet()メソッドのオーバーライド

フレームワークは、データ・ソースからフェッチする必要のある行ごとに、オーバーライドされたcreateRowFromResultSet()メソッドを呼び出します。この実装では、コレクション固有のResultSetオブジェクトがユーザー・データ・コンテキストから取得されます。これは、getResultSet()メソッド使用して結果セット・ラッパーを問合せコレクション・ユーザー・データから取得し、createNewRowForCollection()メソッドを使用して新しい空白の行をコレクション内に作成した後、populateAttributeForRow()メソッドを使用して、ビュー・オブジェクトの概要エディタで設計時に定義された各属性に属性値を移入します。

注意:

populateAttributeForRow()のコールでは、ビュー・オブジェクトに移入する属性値がADFビジネス・コンポーネント・ビュー・オブジェクト属性で期待されるデータ型にすでに準拠していることを想定します。メソッドは、データ型変換を処理しないため、移入される値のデータ型から許可されるビュー・オブジェクト属性タイプへの変換はプログラムで行う必要があります。

次の例は、この目的でcreateRowFromResultSet()メソッドをオーバーライドする方法を示しています。

protected ViewRowImpl createRowFromResultSet(Object qc, ResultSet rs) {
/*
* We ignore the JDBC ResultSet passed by the framework (null anyway) and
* use the resultset that we've stored in the query-collection-private
* user data storage
*/
rs = getResultSet(qc);

/*
* Create a new row to populate
*/
ViewRowImpl r = createNewRowForCollection(qc);
try {
/*
* Populate new row by type correct attribute slot number for current row
* in Result Set
*/
populateAttributeForRow(r,0, rs.getLong(1));
populateAttributeForRow(r,1, rs.getString(2));
populateAttributeForRow(r,2, rs.getString(3));
}
catch (SQLException s) {
throw new JboException(s);
}
return r;
}

10.6.4.4 hasNextForCollectionMethod()のオーバーライド

フレームワーク・メソッドhasNextForCollection()のオーバーライドされた実装は、フェッチする行がまだあるかどうかに基づいて、trueまたはfalseを返します。最後に達したら、setFetchCompleteForCollection()を呼び出して、このコレクションは移入が終了したことをビュー・オブジェクトに伝えます。次の例は、この目的でhasNextForCollection()メソッドをオーバーライドする方法を示しています。

protected boolean hasNextForCollection(Object qc) {
ResultSet rs = getResultSet(qc);
boolean nextOne = false;
try {
nextOne = rs.next();
/*
* When were at the end of the result set, mark the query collection
* as "FetchComplete".
*/
if (!nextOne) {
setFetchCompleteForCollection(qc, true);
/*
* Close the result set, we're done with it
*/
rs.close();
}
}
catch (SQLException s) {
throw new JboException(s);
}
return nextOne;
}

10.6.4.5 releaseUserDataForCollection()メソッドのオーバーライド

コレクションのフェッチ処理が終了すると、オーバーライドされたreleaseUserDataForCollection()メソッドが呼び出されて、データベース・カーソルが開いたままにならないように確実にResultSetを閉じます。次の例は、この目的でreleaseUserDataForCollection()メソッドをオーバーライドする方法を示しています。

protected void releaseUserDataForCollection(Object qc, Object rs) {
ResultSet userDataRS = getResultSet(qc);
if (userDataRS != null) {
try {
userDataRS.close();
}
catch (SQLException s) {
/* Ignore */
}
}
super.releaseUserDataForCollection(qc, rs);
}

10.6.4.6 getQueryHitCount()メソッドのオーバーライド

最後に、ビュー・オブジェクトのgetEstimatedRowCount()メソッドを正しくサポートするため、オーバーライドされたgetQueryHitCount()メソッドは、すべての行が行セットからフェッチされた場合に取得された行のカウントを返します。ここでは、コードでストアド・ファンクションを使用してこの作業を完了しています。問合せはストアド・ファンクションAPIの背後に完全にカプセル化されているため、コードもカウント・ロジックの実装およびこの機能のサポートをPL/SQLパッケージに依存しています。次の例は、この目的でgetQueryHitCount()メソッドをオーバーライドする方法を示しています。

public long getQueryHitCount(ViewRowSetImpl viewRowSet) {
Long result = (Long)callStoredFunction(NUMBER,
"RefCursorExample.count_orders_for_customer(?)",
viewRowSet.getParameters(true));
return result.longValue();
}

10.7 複数の更新可能エンティティによるビュー・オブジェクトの作成

デフォルトでは、複数のエンティティ・オブジェクト慣用名を持つビュー・オブジェクトを作成するとき、概要エディタでビュー・オブジェクトに追加する2次エンティティ・オブジェクト慣用名それぞれが次の設定で構成されます。

- 「更新可能」チェック・ボックスを選択解除

- 「参照」チェック・ボックスを選択

ビュー・オブジェクト概要エディタの「エンティティ・オブジェクト」ページの「選択済」リストで「使用方法」を選択して、「更新可能」チェック・ボックスを選択し、デフォルトの動作を、2次エンティティ・オブジェクトの慣用名を更新可能にできます。

また、各セカンダリ・エンティティ・オブジェクト慣用名に関して、「参照」を選択したままにして、エンティティ参照情報が変更されたときにセカンダリ・エンティティの属性をリフレッシュするかどうかを決定できます。デフォルトでは、「参照」が選択されていて、各2次エンティティ・オブジェクトの属性がリフレッシュされます。複数のエンティティ・オブジェクト慣用名を使用する行の挿入を許可する場合のこの設定の詳細は、「実行時の処理: ビュー行の作成」を参照してください。

表10-4に、ビュー・オブジェクトにセカンダリ・エンティティ・オブジェクト慣用名を定義する際に選択できる組合せをまとめます。

表10-4 ビュー行作成動作を制御するビュー・オブジェクト・プロパティ

更新可能

参照

ビュー行の動作

true

true

この組合せでは、エンティティ・オブジェクト慣用名の属性を更新し、その属性の主キーの値との同期を保ちます。この組合せは、ビュー・リンク一貫性機能での動作が良好であるため、これを使用して、ビュー・オブジェクトにある、挿入を行うエンティティ・オブジェクト慣用名を1つにできます。

true

false

この組合せでは、エンティティ・オブジェクト慣用名の属性を更新しますが、その属性は主キー参照によって変更されません。これはかなり稀な組合せで、ビュー・オブジェクトを既存のデータの更新または削除のみに使用する状況に最適です。この組合せでは、ユーザーは非参照の更新可能なエンティティ・オブジェクト慣用名に関連する属性を更新でき、ビュー行は適切な基礎のエンティティ行に変更を委譲します。

注意: ビュー・リンク一貫性機能で、ビュー・オブジェクトの一部のセカンダリ・エンティティ・オブジェクト慣用名がUpdatable=true、Reference=falseに設定されている場合は、アプリケーションに不要で余分な新しいエンティティが作成される場合があります。

false

true

「エンティティ・ベースのビュー・オブジェクトに対する結合の作成方法」で説明するように、これはデフォルトの動作です。この組合せは、エンティティ・オブジェクト慣用名を更新しないことを想定しています。

新しい行の作成をサポートするための複数の更新可能エンティティ(Updatable=true、Reference=false)と、コンポジットでないエンティティ・オブジェクト間のアソシエーションを持つビュー・オブジェクトが必要な場合は、「複数の更新可能エンティティ・オブジェクト慣用名を持つ新規行をプログラムで作成する方法」の説明に従って、コードを少し記述する必要があります。

10.7.1 複数の更新可能エンティティ・オブジェクト慣用名を持つ新規行をプログラムで作成する方法

新しい行の作成をサポートするための複数の更新可能エンティティ(Updatable=true、Reference=false)と、コンポジットでないエンティティ・オブジェクト間のアソシエーションを持つビュー・オブジェクトが必要な場合は、ビュー・オブジェクトのカスタム・ビュー行クラスのcreate()メソッドをオーバーライドしてこれを有効にし、正しく動作するようにする必要があります。

注意:

作成する必要があるのは、更新可能なエンティティ間のアソシエーションがコンポジットでない場合に新しい行の作成を処理するコードのみです。アソシエーションがコンポジットである場合は、ADFビジネス・コンポーネントにより自動的に処理されます。

複数の更新可能エンティティを持つビュー・オブジェクトでcreateRow()を呼び出すと、更新可能なエンティティ・オブジェクトの慣用名ごとに新しいエンティティ行の部分が作成されます。このシナリオの複数エンティティはアソシエーションによって関連付けられているので、新しい関連のあるエンティティ行を正常に保存できるようにするには、3つのコードを実装する必要があります。

1. 正しいポスト順序を制御するために含まれるエンティティ・オブジェクトで、postChanges()メソッドをオーバーライドすることが必要な場合があります。

2. 関連付けられたエンティティの主キーがDBSequenceを使用してデータベース順序によって移入され、複数のエンティティ・オブジェクトが関連付けられてはいても、コンポジットではない場合は、postChanges()メソッドとrefreshFKInNewContainees()メソッドをオーバーライドし、更新された主キー値を、一時的な値を参照していた関連行にカスケードする必要があります。

3. ビュー・オブジェクトのカスタム・ビュー行クラスのcreate()メソッドをオーバーライドし、親エンティティ・オブジェクトのコンテキストを新しく作成される子エンティティに渡すよう、デフォルトの行作成動作を変更する必要があります。

手順1および2のコードを理解するには、「制約違反を防ぐためのエンティティ・ポスト順序を制御する方法」で説明する、関連するエンティティ・オブジェクトの例を参照してください。最後に理解しておく必要があることは、ビュー行でcreate()メソッドをオーバーライドする方法です。プライマリ・エンティティ・オブジェクト慣用名がProductで、セカンダリ・エンティティ・オブジェクト慣用名がInventoryである、ProductInventoryVOビュー・オブジェクトについて考えます。エンティティ・オブジェクトの慣用名Productは、更新可能で非参照としてマークされ、エンティティ・オブジェクトの慣用名Inventoryは、参照エンティティ・オブジェクト慣用名であるものとします。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.multieoupdateパッケージを参照します。

次の例は、ビュー行作成操作の間に、複数の更新可能エンティティ行部分を正しい順序で作成するために必要なコメント付きのコードを示しています。

/**
* By default, the framework will automatically create the new
* underlying entity object instances that make up this
* view object row being created.
*
* We override this default view object row creation to explicitly
* pre-populate the new (detail) InventoryImpl instance using
* the new (master) ProductImpl instance. Since all entity objects
* implement the AttributeList interface, we can directly pass the
* new ProductImpl instance to the InventoryImpl create()
* method that accepts an AttributeList.
*/
protected void create(AttributeList attributeList) {
// The view row will already have created "blank" entity instances
// so be sure to use the respective names of the entity instance.
ProductImpl newProduct = getProduct();
InventoryImpl newInventory = getInventory();
try {
// Let inventory "blank" entity instance to do programmatic defaulting
newProduct.create(attributeList);
// Let inventory "blank" entity instance to do programmatic
// defaulting passing in new ProductImpl instance so its attributes
// are available to the ProductInventoryVORowImpl's create method.
newInventory.create(newProduct);
}
catch (JboException ex) {
newProduct.revert();
newInventory.revert();
throw ex;
}
catch (Exception otherEx) {
newProduct.revert();
newInventory.revert();
throw new RowCreateException(true      /* EO Row? */,
"Inventory" /* EO Name */,
otherEx   /* Details */);
}
}

このProductInventoryVOビュー・オブジェクトのビュー行クラス(ProductInventoryVORowImplクラス)で、Productエンティティ・オブジェクトおよびInventoryエンティティ・オブジェクトの保護されたcreate()メソッドを呼び出せるようにするには、各エンティティ・オブジェクト・クラスで次のようにcreate()メソッドをオーバーライドし、メソッドへのアクセスを可能にする必要があります。

/**
* Overridding this method in this class allows friendly access
* to the create() method by other classes in this same package, like the
* ProductInventoryVO view object implementation class, whose overridden
* create() method needs to call this.
* @param nameValuePair
*/
protected void create(AttributeList nameValuePair) {
super.create(nameValuePair);
}

create()メソッドをオーバーライドするとき、メソッドの宣言は次の条件によって異なります

- ビュー・オブジェクトとエンティティ・オブジェクトが同じパッケージ内にある場合、オーバーライドされたcreate()メソッドは保護されたアクセスが可能で、ProductInventoryVORowImplクラスがこれらにアクセスします。

- いずれかのエンティティ・オブジェクトが異なるパッケージにある場合、ProductImpl.create()とInventoryImpl.create()(どちらが別のパッケージにある場合でも)は、ProductInventoryVORowImplクラスがこれらを呼び出すことができるように、public宣言される必要があります。

10.7.2 実行時の処理: ビュー行の作成

新しい行の作成をサポートするための複数の更新可能エンティティを持つビュー・オブジェクトが必要な場合、Referenceフラグがビュー行作成に関する動作および情報の自動アソシエーション・ドリブン参照を制御することを理解する必要があります。指定のエンティティ・オブジェクト慣用名のReferenceフラグを無効にすると、次のようになります。

- 新しいビュー行が作成されるたびに、そのエンティティ・オブジェクト慣用名に対して新しいエンティティ・インスタンスが作成されます。

- そのエンティティ・オブジェクト慣用名に関するビュー行属性のストレージに対してビュー行が指すエンティティ行は、フレームワークによって自動的に変更されなくなります。

逆に、エンティティ・オブジェクト慣用名のReferenceフラグを有効のまま(デフォルト)にすると、次のようになります。

- 新しいビュー行が作成されても、そのエンティティ・オブジェクト慣用名に対して新しいエンティティ・インスタンスは作成されません。

- そのエンティティ・オブジェクト慣用名に関するビュー行属性のストレージに対してビュー行が指すエンティティ行は、前記のエンティティのアソシエーションを行ったビュー行の属性に対して実行された変更との同期が自動的に保たれます。

PRODUCT表とINVENTORY表の情報を結合するProductInventoryVOビュー・オブジェクトを考えてみます。これは、ProductId、PName、ProductInventoryId (ProductInventoryVOの属性であることがわかるようにビュー・オブジェクト・エディタで選択された名前)、InventoryInventoryId (ProductInventoryVOの属性であることがわかるようにビュー・オブジェクト・エディタで選択された名前)およびAmountInStockの各属性を表示します。

ここで、updatableとreferenceの両方のマークを付けられたセカンダリ・エンティティ・オブジェクトを設定するデフォルトのケースの実行時の処理について考えてみます。

- Productエンティティ・オブジェクトは、プライマリ・エンティティ・オブジェクト慣用名です。

- Inventoryエンティティ・オブジェクトはセカンダリ・エンティティ・オブジェクト慣用名で、Referenceのマークを付けられています。

ユーザーが新しい行をProductInventoryVOに作成すると、ADFビジネス・コンポーネントでは新しいProductエンティティ・インスタンスのみが作成されます(Inventoryエンティティ・オブジェクト慣用名のReferenceフラグが有効であるため)。ユーザーが製品のInventoryInventoryId属性を10に変更すると、ADFビジネス・コンポーネントでは、エンティティ・キャッシュで主キー10のInventoryエンティティが自動的に検索され(まだキャッシュされていない場合にはデータベースから読み込む)、この新しいビュー行のInventoryエンティティ・オブジェクト慣用名がこの在庫10のエンティティを指すようになります。その結果、在庫10の正しいAmountInStock値が自動的に反映されます。

デフォルトのシナリオでは、Inventoryのエンティティ・オブジェクト慣用名がreferenceとしてマークされていることと、ProductエンティティとInventoryエンティティの間にアソシエーションが存在することの両方によって、参照検索が発生します。アソシエーション定義を介して、ADFビジネス・コンポーネントは、どの属性がこのアソシエーションのどちら側と関連性があるかを認識します。ProductToInventoryアソシエーションのProduct側の任意の属性が変更された場合、Inventoryエンティティ・オブジェクト慣用名がReferenceとマークされていると、ADFビジネス・コンポーネントにより自動参照検索が実行されます。ユーザーがこの新しいビュー行でAmountInStockを20に変更すると、変更のコミット後、データベースには在庫10に対応する新しい製品が格納され、在庫量10が20に更新されます。

ここで、updatableとマークを付けられたセカンダリ・エンティティ・オブジェクトを設定し、referenceは無効にした場合の実行時の処理について考えてみます。

- Productエンティティ・オブジェクトは、プライマリ・エンティティ・オブジェクト慣用名です。

- Inventoryエンティティ・オブジェクトはセカンダリ・エンティティ・オブジェクト慣用名ですが、この慣用名はReferenceのマークを付けられていません。

このシナリオでは、ユーザーが新しい行をProductInventoryVOに作成すると、ADFビジネス・コンポーネントで新しいProductエンティティ・インスタンスと新しいInventoryエンティティ・インスタンスの両方が作成されます(Inventoryエンティティ・オブジェクト慣用名のReferenceフラグが無効であるため)。ユーザーが製品のInventoryId属性を10に変更しても、行に表示されているAmountInStock属性の値には影響しません。また、ユーザーがこの新しいビュー行でInventoryInventoryIdを99に、AmountInStockを20に設定すると、変更のコミット後、データベースには在庫10に対応する新しい製品と、新しい在庫数99の両方が格納されます。

10.8 プログラムによるビュー定義とビュー・オブジェクトの作成

oracle.jbo.server.ViewDefImplクラスでは、ビュー・オブジェクト・インスタンスのビュー定義メタオブジェクトを動的に定義できます。ビュー定義は、ビュー・オブジェクトの構造を示します。

一般に、アプリケーションでは、JDeveloperの概要エディタを使用して作成したXMLファイルをロードして、ビュー定義オブジェクトを作成します。アプリケーションでビュー・オブジェクト・インスタンスを作成する必要がある場合、ビュー定義名を使用してビュー・オブジェクトのビュー定義についてMetaObjectManagerに問い合せます。その後、XMLファイルを検索し、開いて解析して、メモリー内にビュー定義オブジェクトを作成します。

ViewDefImplクラスのメソッドを使用して、プログラムでビュー定義を作成することもできます。プログラムでビュー定義を作成する場合、アプリケーション・コードは次のようなコードで始まります。

ViewDefImpl viewDef = new ViewDefImpl("MyViewDef");
viewDef.setFullName("sessiondef.mypackage.MyViewDef");

作成するビュー定義は、その完全な名前により一意に識別される必要があります。この場合、完全な名前はパッケージ修飾名です。したがって、ビュー定義オブジェクトのパッケージ修飾名(たとえばsessiondef.mypackage.MyViewDef)を渡すためにsetFullName()をコールします。

最初に渡すMyViewDef名は、作成するビュー定義の短縮名です。APIからビュー定義名が要求されたときにアプリケーションは短縮名を渡す場合があります。たとえば、ApplicationModule.createViewObject(String, String)を呼び出すときにアプリケーションはdefNameパラメータをリクエストできます。

ビュー定義を作成した後、この定義に基づいてビュー・オブジェクト・インスタンスを作成するには、次の基本手順に従います(後に例を示しています)。

1. ビュー定義オブジェクトを作成して、完全な名前を設定します。

2. ビュー・オブジェクトSQL文を定義します。

3. ビュー定義を解決して、MDSリポジトリに保存します。

4. ビュー定義を使用して、ビュー定義に基づくビュー・オブジェクトのインスタンスを作成します。

注意:

ビュー定義をMDSリポジトリに保存するには、保存されるビュー定義に対してadf-config.xmlファイルが適切に構成されている必要があります。adf-config.xmlファイルの構成の詳細は、「MDSリポジトリの構成に関する必知事項」を参照してください。

/*
* 1. Create the view definition object.
*/
ViewDefImpl v = new ViewDefImpl("DefNameForTheObject");

v.setFullName("sessiondef.some.unique.DefNameForTheObject");

/*
* 2. Then, define the view object's SQL statement by either using a fully-
* specified custom SQL query.
*/
v.setQuery("select e.empno,e.ename,e.sal,e.deptno,d.dname,d.loc,"+
"d.deptno,trunc(sysdate)+1 tomorrow_date, "+
"e.sal + nvl(e.comm,0) total_compensation, "+
"to_char(e.hiredate,'dd-mon-yyyy') formated_hiredate"+
"  from emp e, dept d "+
" where e.deptno = d.deptno (+)"+
" order by e.ename");
v.setFullSql(true);

/*
* Or, you can construct the SQL statement in parts like this.
*/
v.setSelectClause("e.empno,e.ename,e.sal,e.deptno,d.dname,d.loc,"+
"d.deptno,trunc(sysdate)+1 tomorrows_date,"+
"e.sal + nvl(e.comm,0) total_compensation, "+
"to_char(e.hiredate,'dd-mon-yyyy') formated_hiredate");
v.setFromClause("emp e, dept d");
v.setWhereClause("e.deptno = d.deptno (+)"); v.setOrderByClause("e.ename");

/*
* 3. Then resolve and save the view definition.
*/
v.resolveDefObject();
v.writeXMLContents();
v.saveXMLContents();

/*
* 4. Finally, use the dynamically-created view definition to construct
* instances of view objects based on it.  myAM is an instance of
* oracle.jbo.ApplicationModule that will parent this VO instance.
*/
ViewObject vo = myAM.createViewObject("SomeInstanceName", v.getFullName());

10.8.1 MDSリポジトリの構成に関する必知事項

ビュー定義を作成したら、ビュー定義を記述してMDSリポジトリに保存することが重要です。正しく保存しないと、リクエストがクラスタ内の別のノードにリダイレクトされた場合に、他のノードから定義をロードしてアクセスできないため、問題が発生することがあります。

定義を保存するには、adf-config.xmlのmds-config要素を定義する必要があります。たとえば、adf-config.xmlファイルには、次の例に示すような定義を含める必要があります。

<mds-config version="11.1.1.000">
<persistence-config>
<!-- metadata-namespaces must define /sessiondef and /persdef namespaces -->
<metadata-namespaces>
<namespace path="/sessiondef" metadata-store-usage="mymdsstore">
<namespace path="/persdef" metadata-store-usage="mymdsstore">
</metadata-namespaces>

<metadata-store-usages>
<metadata-store-usage id="mymdsstore" default-cust-store="true">
<metadata-store name="fs1"
class-name="oracle.mds.persistence.stores.file.FileMetadataStore">
<!-- metadata-path value should be the absolute dir path where you want
the metadata documents to be written -->
<property name="metadata-path" value="/tmp">
</metadata-store>
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>

<cust-config>
<match path="/">
<customization-class name="oracle.adf.share.config.UserCC">
</match>
</cust-config>
</mds-config>

adf-config.xmlファイルですでにmetadata-store-usage要素が定義されている場合は、metadata-store-usage定義を使用するように、2つのネームスペース/sessiondefと/persdefを定義できます。adf-config.xmlファイルのMDS構成エントリの詳細は、「adfc-config.xml」を参照してください。MDSリポジトリの構成の詳細は、『Oracle Fusion Middlewareの管理』の「メタデータ・リポジトリの管理」を参照してください。

10.8.2 実行時のビュー・オブジェクト作成に関する必知事項

「プログラムによるビュー定義とビュー・オブジェクトの作成」で説明しているように、実行時のビュー・オブジェクトの作成に関連するオーバーヘッドを理解しておくことが重要です。ビジネス要件でどうしても必要でないかぎり、行わないようにしてください。たとえば、アプリケーションで発行する問合せで、対象の表の名前が設計時にわかっていて、取得する列のリストも固定している場合は、設計時にビュー・オブジェクトを作成します。このようにすると、SQL文は適切にカプセル化され、開発中に簡単に説明およびチューニングでき、結果の行の構造とデータ型を検出するために実行時にオーバーヘッドをかけることがなくなります。

これに対し、実行時にApplicationModuleインタフェースでcreateViewObjectFromQueryStmt() APIを使用すると、問合せはコードに埋もれてしまい、前もってSQLをチューニングすることが困難になり、ビュー・オブジェクトを作成するたびにパフォーマンスが犠牲になります。理論上、動的に作成されるビュー・オブジェクトのSQL問合せ文は、このAPIを使用して新しいインスタンスが作成されるたびに異なるので、実行中に問合せ結果の形状を検出するために、余分なデータベース・ラウンドトリップが必要になります。問い合せる表の名前が実行時までわからない場合にのみ、問合せを動的に作成します。それ以外のほとんどの要件には、設計時に作成するビュー・オブジェクトと、固定のWHERE句にバインド変数を設定する、または実行時にWHERE句(オプションのバインド変数を含む)を追加するランタイムAPIを組み合せることで対応できます。

10.9 挿入、更新および削除の宣言による禁止

Oracle Formsなどの一部の4GLツールでは、特定のデータ・コレクションが挿入、更新または削除を許可するかどうかを制御する宣言的プロパティが提供されています。現在のリリースでは、まだビュー・オブジェクトはこれを組込み機能としてサポートしていませんが、ビュー・オブジェクトでの挿入、更新または削除を制御するための開発者提供のフラグとしてカスタム・メタデータ・プロパティを利用するフレームワーク拡張クラスを使用すれば、この機能を簡単に追加できます。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.declblockパッケージを参照します。

開発者が個別のビュー・オブジェクト・インスタンスを制御できるようにするには、ビュー・オブジェクト・インスタンスと同じ名前でアプリケーション・モジュール・カスタム・プロパティを使用するという規則を導入します。たとえば、アプリケーション・モジュールにProductsInsertOnly、ProductsUpdateOnly、ProductsNoDeleteおよびProductsという名前のビュー・オブジェクト・インスタンスがある場合、汎用コードでは、これらと同じ名前でアプリケーション・モジュール・カスタム・プロパティを検索します。プロパティ値にInsertが含まれている場合は、そのビュー・オブジェクト・インスタンスでは挿入が有効です。プロパティにUpdateが含まれる場合は、更新が許可されています。同様に、プロパティ値にDeleteが含まれる場合は、削除が許可されています。次のようなヘルパー・メソッドを使用してこれらのアプリケーション・モジュール・プロパティを検査し、挿入、更新および削除が特定のビュー・オブジェクトに対して許可されているかどうかを判定できます。

private boolean isInsertAllowed() {
return isStringInAppModulePropertyNamedAfterVOInstance("Insert");
}
private boolean isUpdateAllowed() {
return isStringInAppModulePropertyNamedAfterVOInstance("Update");
}
private boolean isDeleteAllowed() {
return isStringInAppModulePropertyNamedAfterVOInstance("Delete");
}
private boolean isStringInAppModulePropertyNamedAfterVOInstance(String s) {
String voInstName = getViewObject().getName();
String propVal = (String)getApplicationModule().getProperty(voInstName);
return propVal != null ? propVal.indexOf(s) >= 0 : true;
}

次の例は、ビュー行が実装を完了するために、カスタム・フレームワーク拡張クラスで必要な他のコードを示しています。これは、次のメソッドをオーバーライドします。

- isAttributeUpdateable()
挿入が許可されていない場合に新しい行のフィールドを無効にするため、または更新が許可されていない場合に既存の行のフィールドを無効にするために、ユーザー・インタフェースを有効化します。

- setAttributeInternal()
挿入が許可されていない場合に新しい行の属性値が設定されないようにします。また、更新が許可されていない場合に既存の行の属性が設定されないようにします。

- remove()
削除が許可されない場合に削除を禁止します。

- create()
挿入が許可されない場合に作成を禁止します。

public class CustomViewRowImpl extends ViewRowImpl {
public boolean isAttributeUpdateable(int index) {
if (hasEntities() &&
((isNewOrInitialized() && !isInsertAllowed()) ||
(isModifiedOrUnmodified() && !isUpdateAllowed()))) {
return false;
}
return super.isAttributeUpdateable(index);
}
protected void setAttributeInternal(int index, Object val) {
if (hasEntities()) {
if (isNewOrInitialized() && !isInsertAllowed())
throw new JboException("No inserts allowed in this view");
else if (isModifiedOrUnmodified() && !isUpdateAllowed())
throw new JboException("No updates allowed in this view");
}
super.setAttributeInternal(index, val);
}
public void remove() {
if (!hasEntities() || isDeleteAllowed() || isNewOrInitialized())
super.remove();
else
throw new JboException("Delete not allowed in this view");
}
protected void create(AttributeList nvp) {
if (isInsertAllowed()) {
super.create(nvp);
} else {
throw new JboException("Insert not allowed in this view");
}
}
// private helper methods omitted from this example
}

11 検証とビジネス・ルールの宣言的な定義

この章では、Oracle ADFアプリケーションに宣言的検証を実装するビジネス・ルールを記述するためにADFエンティティ・オブジェクトを使用する方法について説明します。

この章の内容は次のとおりです。

- 宣言的な検証について

- 検証を実装する場所の決定

- 検証サイクルの理解

- エンティティ・オブジェクトおよび属性への検証規則の追加

- 組込みの宣言的な検証規則の使用

- ビジネス・ルールとトリガーでのGroovy式の使用

- 検証実行のトリガー

- 検証エラー・メッセージの作成

- 検証例外の重大度レベルの設定

- SQLでのバルク検証

11.1 宣言的な検証について

検証ルールを作成および管理する最も容易な方法は、宣言的検証ルールを使用することです。宣言的検証規則は概要エディタを使用して定義され、一旦作成されると、エンティティ・オブジェクトのXMLファイルに保存されます。宣言的検証は、エンティティ・オブジェクトのJavaファイルに保存されているプログラムによる検証(「プログラムによる検証とビジネス・ルールの実装」)とは異なります。

Oracle ADFでは、大部分のビジネス上のニーズを満たすことができる組込みの宣言的な検証ルールが用意されています。再利用するカスタム検証規則がある場合は、コーディングを行ってIDEに追加し、JDeveloperから直接規則を利用できます。カスタム検証ルールは高度なトピックとなり、「カスタム検証規則の実装」で説明されています。「ビジネス・ルールとトリガーでのGroovy式の使用」で説明されているように、Groovy式を検証の基礎にすることもできます。

検証ルールを追加する際、適切なエラー・メッセージを提供し、後に必要に応じて容易に他の言語に翻訳できます。検証のトリガー方法を定義し、重大度レベルを設定することもできます。

11.1.1 宣言的な検証のユースケースと例

ADFビジネス・コンポーネントを含むFusion Webアプリケーションでは、検証コードの大半がエンティティ・オブジェクト内で定義されます。ビジネス・ロジックをこのように再利用可能な共有コンポーネントにカプセル化することにより、ビジネス情報にアクセスするすべてのビュー・オブジェクトやクライアントで情報が一貫して検証され、検証の保管先を集中化することによって管理が容易になります。

宣言的検証を使用する場合のもう1つの利点は、独自に検証を作成する場合とは異なり、検証のフレームワークによってバッチ検証の複雑な例外処理が自動的に行われることです。これにより、アプリケーション固有の検証規則ロジックに専念できます。

モデル・レイヤーでは、ADFモデル検証規則をコレクションの属性に設定できます。エンティティ・オブジェクトで利用できる宣言的検証機能の多くはモデル・レイヤーでも利用でき、アプリケーションはビジネス・レイヤー検証に加えてモデル・レイヤー検証の使用も保証する必要があります。詳細は、「ADFモデル・レイヤーでの検証の使用」を参照してください。

ADFビジネス・コンポーネント・アプリケーション・モジュールのデータ・コントロールを使用する場合、モデル・レイヤー検証を使用する必要はありません。可能であれば、すべての検証規則を、ビジネス・レイヤー内の再使用と管理が容易で一元管理されたエンティティ・オブジェクトに定義することを検討してください。その他のデータ・コントロール・タイプでは、ADFモデル・レイヤー検証のほうが便利です。

11.1.2 宣言的な検証の追加機能

宣言的な検証を使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。必要に応じて、宣言的動作を超えて、より複雑な検証規則をビジネス・ドメイン・レイヤーに実装することができます。次に、関連する他の機能へのリンクを示します。

- 「メソッド・バリデータの使用」では、メソッド・バリデータを使用したカスタム検証コードの起動方法を説明しています。

- 「カスタム検証規則の実装」では、基本的な宣言的ルール・セットを独自のカスタム・ルールで拡張する方法を詳しく説明しています。

11.2 検証を実装する場所の決定

「Oracle ADFアーキテクチャ」で説明したように、Fusion WebアプリケーションのModel-View-Controller (MVC)アーキテクチャには、ビジネス・ロジック、ページ・ナビゲーション、ユーザー・インタフェースの明確な分離を提供する複数のレイヤーがあります。これらのレイヤーは、検証の実装に複数のオプションを提供し、各レイヤーでの検証の使用には利点と欠点があります。検証を実装するために選択する場所は、特定のビジネス・ニーズまたはユースケースによって決まります。一般に、検証を行う場所がデータ・ソースに近いほど、集中化されるため保守が簡単になり、ユーザー・インタフェースに近いほど、実行時にフィードバックがより即時に提供されます。

データ・サービス・レイヤー: データベースであるか、Webサービスであるか、その他のデータ・ソースであるかにかかわらず、データ・サービス・レイヤーは、一般にアプリケーション自体のコンテキストの外部に存在し、各データ・フィールドの性質を定義する制約を採用します。データ・サービス制約は、通常は格納されるデータのすべての部分に対して定義され、そのデータの完全性を維持するために非常に重要です。ただし、データがデータ・ソースに到達する(通常はアプリケーションがトランザクションをコミットしようとしたとき)までは施行されないため、これらの制約のみに依存することは効果的でも効率的でもありません。これには、クライアントUIからデータ・ソースへのラウンド・トリップが必要であり、単一レコードでの単一のエラーがトランザクション全体のロールバックの原因となることがあります。

ビジネス・サービス・レイヤー: ADFビジネス・コンポーネント(エンティティ・オブジェクトやビュー・オブジェクトなど)のビジネス・サービス・レイヤーで実装するビジネス・ルールは、データ・ソースとのラウンド・トリップを必要としないため、データ・サービス制約よりも効率的です。また、特定のエンティティ・オブジェクトの属性に対して定義されたビジネス・ルールは、そのエンティティ・オブジェクトを使用するすべてのページに適用されるため、これらはビュー・レイヤーに実装されたバリデータよりも保守が簡単です。属性レベルのバリデータに加えて、ある属性の値の有効性が別の属性の値に依存する場合は、エンティティ・レベルのバリデータを実装することもできます。たとえば、DateShippedはDateOrderedよりも大きい必要があります。この章では、この種類のビジネス・ルールについて説明します。

モデル・レイヤー: 他の種類のビジネス・ルールほど一般的には使用されませんが、モデル・レイヤー検証も役立つ場合があります。ビジネス・サービスへのバインドに対してビジネス・ルールを定義できます。この機能は、たとえばアプリケーションが外部Webサービスを使用するため、ビジネス・サービスに検証を実装できない場合に役立つことがあります。詳細は、「ADFモデル・レイヤーでの検証の使用」を参照してください。

ビュー・レイヤー: ユーザーの観点から、ビュー・レイヤー検証が最も効率的です。これらは、ユーザーがデータを入力してから特定のフィールドを離れた(タブ移動した)場合に即時のフィードバックを提供します。アプリケーション・サーバーとの通信は必要としません。ただし、ビュー・レイヤー・バリデータはページに実装されるため、特定のデータ・フィールドへのアクセスを提供するすべてのページで、そのフィールドに対する検証を定義する必要があります。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「入力の検証および変換」を参照してください。

11.3 検証サイクルの理解

それぞれのエンティティ行は、データが有効であるかどうかを追跡します。既存のエンティティ行をデータベースから取得すると、エンティティは有効であると判断されます。既存のエンティティ行の最初の持続属性が変更された場合、または、新しいエンティティ行が作成された場合、エンティティは無効であるとマークされます。

エンティティが無効な状態にある場合、エンティティを有効にする前に、構成した宣言的な検証と、実装したプログラム的な検証規則が再度評価されます。あるエンティティ行が実行時に有効であるかどうかは、その行でisValid()メソッドをコールして確認できます。

注意:

属性は(デフォルトで)空欄のままにできるため、属性に値が含まれていない場合、検証はトリガーされません。たとえば、ユーザーが新しいエンティティ行を作成して特定の属性の値を入力しなかった場合、その属性に関する検証は実行されません。この状況で検証を強制的に実行するには、属性に必須フラグを設定します。

11.3.1 エンティティ・オブジェクト検証規則のタイプ

エンティティ・オブジェクト検証規則は、属性レベルおよびエンティティレベルのいずれかの基本カテゴリに分類できます。

11.3.1.1 属性レベルの検証規則

特定のエンティティ・オブジェクト属性に対する属性レベルの検証規則は、エンド・ユーザーまたはプログラム・コードによる属性値の変更が試行されるとトリガーされます。属性を設定する順序は指定できないため、属性レベルの検証規則は、規則の成否がその属性の候補値のみに依存する場合にのみ使用する必要があります。

属性レベルの検証を次に示します。

- 注文のOrderDateの値には、過去の日付は設定できません。

- 製品のProductId属性は、既存の製品である必要があります。

11.3.1.2 エンティティ・レベルの検証規則

その他のすべての検証規則は、エンティティ・レベルの検証規則となります。これらの規則には、実装の際、規則の成否の決定に2つ以上のエンティティ属性、または、構成される子エンティティ行を考慮する必要があります。

エンティティ・レベルの検証を次に示します。

- OrderShippedDateの値は、OrderDateより後の日付を設定します。

- 注文のProductId属性は、既存の製品である必要があります。

エンティティ・レベルの検証規則は、Rowに対しvalidate()メソッドをコールするとトリガーされます。次の場合にトリガーされます。

- エンティティ・オブジェクトにおいてメソッドを明示的にコールした場合

- 無効なエンティティ行を含むビュー行においてメソッドを明示的にコールした場合

- ビュー・オブジェクトのイテレータにより、現在の行の変更を許可する前に、ビュー・オブジェクトの現在の行に対してメソッドがコールされた場合

- トランザクションのコミット時、データベースへ変更を送信する前に、保留中の変更リスト内の無効なエンティティが処理によって有効にされた場合

トランザクションのコミット処理の一環として、エンティティ・レベルの検証規則は複数回起動できます(指定された限度回数まで)。詳細は、「無限検証サイクルの回避」を参照してください。

11.3.2 コミット処理と検証の理解

トランザクションのコミット処理は、3つの基本的なフェーズに分かれています。

1. 保留中の変更リスト内のすべての無効エンティティ行が有効であることを確認します。

2. 適切なDML操作を実行し、保留中の変更をデータベースに送信します。

3. トランザクションをコミットします。

エンティティ・オブジェクト内に、SELECT文内の送信済の変更の参照に応じて問合せまたはストアド・プロシージャを実行するようなビジネス検証ロジックがある場合、「ビュー・アクセッサによる行セットのアクセスに関する必知事項」に示すbeforeCommit()メソッドを使用してコーディングする必要があります。このメソッドは、すべてのDML文が適用された後に実行されるため、そのメソッドが実行した問合せやストアド・プロシージャでは、保存された、コミット前の保留中の変更をすべて参照できます。

注意:

同一のHTTPリクエスト内でトランザクションのコミットまたはロールバックが必ず実行される場合を除き、Webアプリケーションでトランザクション・レベルのpostChanges()メソッドを使用しないでください。このメソッドは、検証前の変更をコミットせず、トランザクションから強制的に送信します。使用した場合、複数の異なるクライアントにより、アプリケーション・モジュールとデータベース接続の両方がプールされ、シリアルに共有されるという事態が環境内で発生する可能性があります。

11.3.3 検証順序に対するコンポジットの影響の理解

構成される側の子エンティティ行は、それを構成する親エンティティ・オブジェクトに不可欠であるとみなされるため、構成される側の子エンティティ行になんらかの変更を加えると、親エンティティは無効であるとマークされます。たとえば、注文の明細項目を変更する場合、注文全体が変更されるか無効であるとみなされます。

したがって、コンポジット・エンティティを検証する場合、現在無効な構成される側の子エンティティが最初に検証されます。この動作は再帰的で、無効な構成される側の子が存在する場合、さらに深くドリルします。

11.3.4 無限検証サイクルの回避

現在のエンティティや他のエンティティの属性を更新するコードが検証規則に含まれている場合、エンティティの検証により、対象のエンティティやその他のエンティティが無効になる場合があります。保留中の変更リスト内のすべての無効なエンティティを検証するトランザクションのコミット処理フェーズの一環として、このトランザクションは、保留中のすべてのエンティティ行が有効になるまで、1回につき保留中の変更リストを複数回(指定された限度回数まで)パスします。

検証のパスの最大回数は、トランザクション・レベルの検証しきい値設定によって指定します。この設定のデフォルト値は10です。後続のパスで自身を検証するための適切なロジックが関連のエンティティに含まれている場合は、しきい値の回数を増やすことができます。

10回パスした後に、リスト内に無効なエンティティが残っている場合、次の例外が発生します。

JBO-28200: Validation threshold limit reached. Invalid Entities still in cache

これは、意図しないエンティティの無効化を繰り返すような処理を回避するため、検証規則コードをデバッグする必要があることを示しています。

検証しきい値を変更するには:

1. 「アプリケーション」ウィンドウで、目的のアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「構成」ナビゲーション・タブをクリックし、検証しきい値を調整する構成のハイパーリンクを選択します。

3. アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタで、「プロパティ」タブをクリックし、「プロパティの追加」をクリックします。

4. 「プロパティの追加」ダイアログで、jbo.validation.thresholdプロパティを選択し、「OK」をクリックします。

5. 概要エディタの「プロパティ」リストに、jbo.validation.thresholdプロパティの新しい値を入力し、変更を保存します。

検証しきい値は、次に示すようにSetValidationThreshold()メソッドを使用してプログラム的に変更することもできます。この例では新しいしきい値が12です。

oracle.jbo.server.DBTransaction::setValidationThreshold(12)

11.3.5 検証が失敗したときに行われる処理

エンティティ・オブジェクトの検証規則で例外がスローされた場合、その例外はバンドルされ、クライアントに戻されます。トランザクションのpostChanges処理中、イベントを処理するためオーバーライドしたメソッドによって検証の失敗がスローされる場合、現在のpostChangesサイクルですでに実行されている可能性のあるデータベースのINSERT、UPDATEおよびDELETE文がロールバックされます。

注意:

例外のバンドルは、ADFモデル・ベースのWebアプリケーションのデフォルトの動作ですが、Oracle ADFモデル・テスターまたはSwingのバインディングではデフォルト動作ではありません。Oracle ADFモデル・テスターまたはSwingのクライアントでは、例外のバンドルに追加の構成が必要です。

11.3.6 エンティティ・オブジェクト行の状態の理解

エンティティ行がメモリー内にある場合、行の論理状態を反映したエンティティ状態になります。図11-1に、異なるエンティティ行の状態と、エンティティ行の状態の変化を示します。エンティティ行が最初に作成される場合、状態はNewです。setNewRowState()メソッドを使用すると、エンティティをInitializedとしてマーキングできます。これにより、エンティティはトランザクションの保留中の変更リストから除外され、ユーザーが1つ以上の属性を設定したときにNew状態に戻ります。これによって、複数の初期化行を作成し、ユーザーが修正したものだけをポストできます。

Unmodified状態とは、データベースから取得されてから、まだ変更されていないエンティティの状態を表します。また、NewまたはModified状態のエンティティがトランザクションのコミット完了後に遷移する状態でもあります。トランザクション内で削除のために保留中の場合は、Unmodifiedエンティティ行はDeleted状態へと遷移します。最終的に、New状態の行がトランザクションのコミット前に削除されたり、Unmodified状態の行が正常に削除された場合、その行はDead状態へと遷移します。

図11-1 エンティティ行の状態と遷移のダイアグラム

getEntityState()およびgetPostState()メソッドを使用すると、ビジネス・ロジック・コードのエンティティ行の現在の状態にアクセスできます。getEntityState()メソッドは、トランザクションに関するエンティティ行の現在の状態を返します。また、getPostState()メソッドは、postChanges()メソッドを使用してトランザクションをコミットせずに保留中の変更をポストした後の、データベースに関するエンティティ行の現在の状態を返します。

たとえば新しい行を開始すると、getEntityState()とgetPostState()の両方がSTATUS_NEWを返します。その後、行をポストすると(コミットやロールバックの前)、その行のエンティティ状態はSTATUS_NEWになり、ポスト状態はSTATUS_UNMODIFIEDになります。その後その行を削除しても、トランザクションにとってその行はまだ新規のため、エンティティ状態はSTATUS_NEWのままになります。ただしポスト状態はSTATUS_DEADになります。

11.3.7 バンドル例外モードの理解

アプリケーション・モジュールにはバンドル例外モードと呼ばれる機能があり、Webアプリケーションは発生した最初のエラーのみでなく、失敗した検証例外の最大セットをエンド・ユーザーに簡単に提示できます。ADFビジネス・コンポーネント・アプリケーション・モジュール・プールでは、Webアプリケーションに対してバンドル例外モードをデフォルトで有効にしています。

このデフォルト設定は、通常変更する必要はありません。ただし、検証例外がスローされる方法に影響を与えることからデフォルトで有効になっていることを理解することが重要です。Java言語およびJavaランタイムは単一例外オブジェクトのスローのみをサポートするため、バンドルされた検証例外は、例外のセットを、それを含む新しい親例外の詳細としてラップすることで実装されます。たとえば、単一エンティティ・オブジェクトの複数の属性で属性レベルの検証ができない場合、これら複数のValidationExceptionオブジェクトは、RowValExceptionにラップされます。このラップ例外には、検証できなかった行の行キーが含まれています。トランザクションのコミット時に、コミット中に実行された検証を複数の行で渡せなかった場合、すべてのRowValExceptionオブジェクトは、包含するTxnValExceptionオブジェクトにラップされます。

カスタム・エラー処理コードを記述するときは、JboException基本例外クラスのgetDetails()メソッドを使用すると、内部にバンドルされている例外を再帰的に処理できます。

注意:

ここに記載されている例外クラスはすべて、oracle.jboパッケージのクラスです。

11.4 エンティティ・オブジェクトおよび属性への検証規則の追加

エンティティ・オブジェクトに検証規則を追加する手順は、ほとんどの検証規則と同じで、「検証ルールの追加」ダイアログを使用します。このダイアログは、「ビジネス・ルール」ページの「追加」アイコンをクリックして、概要エディタから開くことができます。

「検証ルールの追加」ダイアログを使用して規則を宣言的に定義すると、その規則定義が属性またはエンティティ・オブジェクトの有効な条件を指定することに注意する必要があります。実行時に、ユーザーが入力したエントリが規則定義に対して評価され、エントリが指定された基準を満たさない場合、エラーまたは警告が発せられます。たとえば、12より小さいか等しい必要のある属性に対して長さのバリデータを指定した場合、エントリが12文字よりも長いと検証が失敗し、エラーまたは警告が発行されます。

11.4.1 エンティティまたは属性への検証規則の追加方法

エンティティ・オブジェクトに宣言的な検証規則を追加するには、概要エディタの「ビジネス・ルール」ページを使用します。

始める前に:

エンティティ・オブジェクトと属性での検証規則の使用方法に関する知識があると役立つ場合があります。詳細は、「エンティティ・オブジェクトおよび属性への検証規則の追加」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

検証規則を追加するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、検証規則を追加するオブジェクトを選択して、「追加」アイコンをクリックします。

- エンティティ・オブジェクト・レベルで検証規則を追加するには、「エンティティ」を選択します。

- 属性の検証規則を追加するには、「属性」を展開し、目的の属性を選択します。

新しい検証規則を追加すると、「検証ルールの追加」ダイアログが表示されます。

3. 「検証ルールの追加」ダイアログで、「ルール・タイプ」ドロップダウン・リストから、目的の検証ルールのタイプを選択します。

4. ダイアログの設定を使用して新しい規則を構成します。

このコントロールの内容は、選択する検証規則の種類によって異なります。

様々な検証ルールの詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

5. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。

詳細は、「検証実行のトリガー」を参照してください。

注意:

Key ExistsおよびMethodエンティティ・バリデータの場合は、「検証実行」タブを使用して検証レベルを指定することもできます。

6. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。

詳細は、「検証エラー・メッセージの作成」を参照してください。

7. 「OK」をクリックします。

11.4.2 エンティティ・オブジェクトまたは属性の検証規則の表示および編集方法

エンティティ・オブジェクトの概要エディタの「ビジネス・ルール」ページには、エンティティの検証規則とその属性がツリー・コントロールで表示されます。エンティティ全体に適用する検証規則を表示するには、「エンティティ」ノードを展開します。属性に適用する検証規則を表示するには、「属性」ノードを展開し、属性を展開します。

概要エディタの「ビジネス・ルール」ページに表示される検証規則には、定義した規則だけでなく、必須や精度などのデータベース制約も含まれます。検証規則を開いて編集するには、その規則をダブルクリックするか選択し、「編集」アイコンをクリックします。

11.4.3 検証規則の追加時の処理

エンティティ・オブジェクトに検証ルールを追加すると、エンティティ・オブジェクトのXMLドキュメントが更新され、使用したルールと入力したルール・プロパティを示すエントリが含まれます。たとえば、次の例に示すように、レンジ検証ルールをDiscountAmount属性に追加すると、XMLファイルにRangeValidationBeanエントリが含まれます。

<Attribute
Name="DiscountAmount"
IsNotNull="true"
ColumnName="DISCOUNT_AMOUNT"
. . .
<validation:RangeValidationBean
xmlns="http://xmlns.oracle.com/adfm/validation"
Name="DiscountAmount_Rule_0"
ResId="DiscountAmount_RangeError_0"
OnAttribute="DiscountAmount"
OperandType="LITERAL"
Inverse="false"
MinValue="0"
MaxValue="40"/>
. . .
</Attribute>

実行時に、この規則はこの宣言情報に基づいてエンティティ・オブジェクトによって適用されます。

11.4.4 エンティティおよび属性の検証規則に関する必知事項

宣言的検証は、規則を配置した場所に応じて、エンティティ・レベルおよび属性レベルの両方の検証に適用されます。エンティティ・レベルの検証規則は、ユーザーが保留中の変更をコミットしようとした場合または行を移動しようとした場合に適用されます。また、ユーザーが関連属性の値を変更する場合、属性レベルの検証規則が適用されます。

一意キー・バリデータ(「キー値の一意性を確認する方法」で説明している)はエンティティ・レベルでのみ使用できます。内部ではUnique Keyバリデータが属性レベルのバリデータとして機能します。したがって、ユーザーはバリデータが検証中のキーのキー属性をタブ・アウトすると、検証エラーが確認できます。エンティティの内部キャッシュには重複を含むことができず、属性値を設定するとこれに違反するため、この操作を行います。キャッシュの一貫性チェックは属性値の設定中に行われるため、このチェックは属性値を設定する際に行う必要があります。

ベスト・プラクティス

1つの属性の有効性が1つ以上の他の属性に依存する場合は、属性の検証ではなくエンティティの検証を使用してこの規則を適用します。この処理を実行する例には次のようなものがあります。

- ある属性を別のものと比較する比較バリデータがある場合

- 他の属性の値を調査して式のブランチ化を制御し、この他の属性の値に応じて様々な方法で属性を検証する式バリデータがある場合

- 条件付き実行を使用する場合、および事前条件式に検証しているもの以外の属性が含まれている場合

エンティティ・オブジェクト・バリデータは、エンティティのいずれかが変更された場合に必ずトリガーされます。パフォーマンスを改善するには、規則内でロールを担う属性を示し、この種の属性が1つ以上変更された場合にのみ、規則をトリガーさせます。属性のトリガーの詳細は、「検証実行のトリガー」を参照してください。

11.4.5 値リストおよび属性検証規則に関する必知事項

開発者は、ユーザー・インタフェースでの選択リストの表示をサポートするために、ビュー・オブジェクトに対して値リスト(LOV)属性を定義できます。ビュー・オブジェクトのLOV属性は、表示する値を提供するために、データ・ソース・ビュー・オブジェクトに依存します。LOV機能では問い合せるデータ・ソースには有効な値のみが含まれていることを前提としているため、ユーザー・インタフェースに選択リストが表示される前に、データ・ソース・ビュー・オブジェクト属性に対して定義されている検証規則は抑制されます。したがって、LOVを定義する開発者は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」で説明しているように、データソース・ビュー・オブジェクトにより返される値リストには有効な値のみが含まれるようにする必要があります。

11.5 組込みの宣言的な検証規則の使用

組込みの宣言的な検証規則は、大部分のビジネス上のニーズを満たすことができます。このような規則は、コードの記述がないため実装が簡単です。検証のタイプとその使用方法を選択するには、ユーザー・インタフェース・ツールを使用します。

組込みの宣言的な検証規則を使用すると、次のことが可能です。

- キー値が一意であるかの確認(主キーまたはその他の一意キー)

- キー値の存在の判別

- 属性とリテラル値からSQL問合せまでのすべての値の比較

- リテラル・リスト、SQL問合せ、またはビュー属性の可能性がある値のリストに対する検証

- 値が一定の範囲内にあるか、または特定のバイト数または文字数に制限されるかの確認

- 正規表現による検証またはGroovy式の評価

- アクセッサで使用可能な子エンティティで、集約によって定義された関係を値が満たしているかどうかの確認

- Javaメソッドに定義した検証条件を使用した、エンティティでの検証

11.5.1 キー値の一意性を確認する方法

一意キー・バリデータは、エンティティ・オブジェクトの主キー値が常に一意であるかどうかを確認します。また、一意キー・バリデータは、その属性が代替キーとして定義されている場合、非主キー属性にも使用できます。代替キーの定義方法は、「代替キー値の定義方法」を参照してください。

キー属性値が変更されるたびに、この規則は、新しいキーがこのエンティティ・オブジェクト・クラスの他のエンティティ・オブジェクト・インスタンスに属していないことを検証します。(データベースの一意制約のビジネス・ロジック層に相当します。)エンティティ・オブジェクトの1つでキーが見つかった場合、TooManyObjectsExceptionがスローされます。検証チェックはエンティティ・キャッシュとデータベースの両方で行います。

一意キー検証を使用しても、データベースで重複行を防ぐことができない場合があります。また、2つのアプリケーション・モジュール・セッションが同時に同じキーのレコードを作成しようとする場合もあります。これを回避するには、適用する一意の制約に対して、データベースに一意索引を作成します。

始める前に:

組込み検証規則に関する一般知識があると役立つ場合があります。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

キー値の一意性を確認するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、「エンティティ」ノードを選択して、「追加」アイコンをクリックします。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」・ドロップダウン・リストで「UniqueKey」を選択します。

4. 「キー」ボックスで、主キーまたは代替キーを選択します。

5. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。

詳細は、「検証実行のトリガー」を参照してください。

ベスト・プラクティス

一意キー・バリデータの事前条件の追加が可能ですが、ベスト・プラクティスではありません。一意キー・バリデータが起動できない場合でもキャッシュの一貫性チェックが実行されるため、エラーが返されます。通常は、バリデータおよびわかりやすいエラー・メッセージを追加するのが適切です。

6. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。

詳細は、「検証エラー・メッセージの作成」を参照してください。

7. 「OK」をクリックします。

11.5.2 一意キー・バリデータの使用時の処理

Unique Key Validatorを使用すると、<UniqueKeyValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。次の例は、一意キー・バリデータのXMLを示しています。

<validation:UniqueKeyValidationBean
Name="CustomerEORule0"
KeyName="SCustomerIdPk">
<validation:OnAttributes>
<validation:Item
Value="Id"/>
</validation:OnAttributes>
</validation:UniqueKeyValidationBean>

11.5.3 比較に基づく検証方法

比較バリデータは、エンティティ属性と値の論理比較を実行します。比較バリデータの追加時に、演算子および比較対象を指定します。次のものを比較できます。

- リテラル値
比較バリデータでリテラル値を使用すると、属性の値は指定したリテラル値と比較されます。この種類の比較を使用する場合は、データの型と書式を考慮することが重要です。リテラル値は、規則を適用するエンティティ属性のデータ型で指定した書式に準拠する必要があります。すべての場合において、型はエンティティ属性のタイプ・マッピングに対応します。

たとえば、列タイプDATEの属性はoracle.jbo.domain.Dateクラスにマッピングされますが、これはjava.sql.TimeStampおよびjava.sql.Dateによって受け入れられるのと同じ書式で日付と時間を受け入れます。書式マスクを使用することにより、属性の値の書式が指定されたリテラルに一致するよう指定できます。エンティティ・オブジェクトの属性タイプのマッピングの詳細は、「エンティティ・オブジェクト属性のデータベースおよびJavaデータ型を設定する方法」を参照してください。特定のタイプに必要なフォーマットの詳細は、Javadocのタイプ・クラスを参照してください。

- 問合せ結果
このタイプのバリデータを使用すると、バリデータが実行されるたびにSQL問合せが実行されます。バリデータは問合せ結果から最初の行を取得し、比較する値として問合せの最初の列(その最初の行の)の値を使用します。この問合せは内部にバインド変数を所有できないため、この機能が使用されるのは、現行の行の値に依存しないデータの1つの行の1つの列を選択するときのみです。

- ビュー・オブジェクト属性
このタイプのバリデータを使用すると、バリデータが実行されるたびにビュー・オブジェクトのSQL問合せが実行されます。バリデータは問合せ結果から最初の行を取得し、比較する値としてその行から選択されたビュー・オブジェクト属性の値を使用します。ビュー・オブジェクトの名前付きバインド変数は値に関連付けできないので、そのような変数が利用できる値はデフォルト値のみです。したがって、この機能が使用されるのは、現行の行の値に依存しないデータの1つの行の属性を選択するときのみです。

- ビュー・アクセッサ属性
ビュー・アクセッサの定義時、検証ビュー・オブジェクトのバインド変数に行固有の値を割り当てることができます。

- 式
式のオプションの詳細は、「ビジネス・ルールとトリガーでのGroovy式の使用」を参照してください。

- エンティティ属性
エンティティ属性オプションは、エンティティ・レベルの比較バリデータに対してのみ利用可能です。

始める前に:

組込み検証規則に関する一般知識があると役立つ場合があります。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

比較に基づいて検証するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、バリデータの追加先を選択して、「追加」アイコンをクリックします。

- エンティティ・レベルのバリデータを追加するには、「エンティティ」ノードを選択します。

- 属性レベルのバリデータを追加するには、「属性」ノードを開き、適切な属性を選択します。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「比較」を選択します。選択に応じて下位のフィールドは変わります。

4. 適切な演算子を選択します。

5. 「比較」リストで項目を選択し、選択項目に基づいて適切な比較値を指定します。

6. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。

詳細は、「検証実行のトリガー」を参照してください。

7. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。

詳細は、「検証エラー・メッセージの作成」を参照してください。

8. 「OK」をクリックします。

図11-2は、エンティティ・オブジェクト属性でエンティティ・レベルのCompareバリデータを使用する場合のダイアログを示しています。

図11-2 エンティティ・オブジェクト属性を使用したCompareバリデータ

11.5.4 比較に基づく検証時の処理

Compareバリデータを作成すると、<CompareValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。次の例は、OrdEOエンティティ・オブジェクトのエンティティ・レベル・バリデータのXMLコードを示しています。

<validation:CompareValidationBean
Name="OrdEO_Rule_0"
ResId="oracle.summit.model.entities.OrdEO_Rule_0"
OnAttribute="DateShipped"
OperandType="ATTR"
Inverse="false"
CompareType="GREATERTHANEQUALTO"
CompareValue="DateOrdered">
<validation:OnAttributes>
<validation:Item
Value="DateShipped"/>
<validation:Item
Value="DateOrdered"/>
</validation:OnAttributes>
</validation:CompareValidationBean>

11.5.5 値リストを使用した検証方法

リスト・バリデータにより、属性と値リスト(LOV)が比較されます。リスト・バリデータの追加時に、選択対象のリストのタイプを指定します。

- リテラル値 - バリデータは、エンティティ属性が値リスト内(指定された場合はリスト外)にあることを確認します。

- SQL問合せ - バリデータは、エンティティ属性が問合せの結果セットの最初の列内(指定された場合は列外)にあることを確認します。SQL問合せバリデータではバインド変数を使用できないので、表から問い合せる必要のある一定の小規模なリストでのみ使用する必要があります。問合せのすべての行はメモリーに取得されます。

- ビューオブジェクト属性 - バリデータは、エンティティ属性がビュー属性内(指定された場合はビュー属性外)にあることを確認します。ビュー属性バリデータではバインド変数を使用できないため、表から問い合せる必要のある一定の小規模なリストでのみ使用する必要があります。問合せのすべての行はメモリーに取得されます。

- ビュー・アクセッサ属性 - バリデータは、エンティティ属性がビュー・アクセッサ属性内(またはビュー・アクセッサ属性外)にあることを確認します。ビュー・アクセッサにはバインド変数が利用可能で、ユーザー・インタフェース上にLOVを作成するとビュー・アクセッサが必要になるため、ビュー・アクセッサはおそらく最も便利なオプションです。

ベスト・プラクティス

リスト・バリデータの使用時は、ビュー・アクセッサ上でビュー基準を定義し、適宜ビュー・データのフィルタが行えるので、ビュー・アクセッサが最も便利です。一般的に、ビュー属性でLOVを定義する場合は、ビュー基準を設定してビュー・アクセッサを使用します。

始める前に:

組込み検証規則に関する一般知識があると役立つ場合があります。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

値リストを使用して検証するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、バリデータの追加先を選択して、「追加」アイコンをクリックします。

- エンティティ・レベルのバリデータを追加するには、「エンティティ」ノードを選択します。

- 属性レベルのバリデータを追加するには、「属性」ノードを開き、適切な属性を選択します。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「リスト」を選択します。

4. 「属性」リストで、適切な属性を選択します。

5. 「演算子」フィールドで、包含的リストか排他的リストかに応じて「In」または「NotIn」を選択します。

6. 「リスト・タイプ」フィールドで、適切なリスト・タイプを選択します。

7. 選択したリストのタイプに応じて、リスト値(新規行の各値)の入力、SQL問合せの入力、またはビュー・オブジェクト属性かビュー・アクセッサ属性の選択ができます。

8. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。

詳細は、「検証実行のトリガー」を参照してください。

9. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。

詳細は、「検証エラー・メッセージの作成」を参照してください。

10. 「OK」をクリックします。

図11-3は、ビュー・オブジェクト属性でListバリデータを使用する場合のダイアログを示しています。

図11-3 ビュー・オブジェクト属性を使用するListバリデータ

11.5.6 リスト値を使用した検証時の処理

リスト値を使用して検証すると、<ListValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。次の例は、リスト・バリデータのビュー・オブジェクト属性を使用するCustomerEO.CountryId属性を示しています。

<validation:ListValidationBean
Name="CountryIdRule0"
OnAttribute="CountryId"
OperandType="JBO"
Inverse="false"
ListValue="oracle.summit.model.views.CountryVO.Id"/>

11.5.7 リスト・バリデータに関する必知事項

リスト・バリデータは、比較的小さい値セットに対して属性を検証するためのものです。「問合せ結果」または「ビュー・オブジェクト属性」タイプのリスト検証を選択する場合、検証対象の属性値がリスト内の属性と一致するかどうかを検証するためにメモリー内スキャンが実行される前に、問合せ結果のすべての行が取得されることに注意してください。バリデータのSQLまたはビュー・オブジェクト問合せによって実行される問合せでは、問合せのWHERE句で検証される値は参照されません。

ユーザーが入力した製品コードが、膨大な量の製品が含まれる表に存在するかどうかを判別する必要がある場合、検証規則を使用することは効率的ではありません。かわりに、データベースに対して目的の検証問合せを実行するためにビュー・オブジェクトを使用してSQLベースの検証を効率的に実行するための技術は、「検証でのビュー・オブジェクトの使用」を参照してください。「バリデータを使用した属性値の検証」も参照してください。

また、比較する属性がキーの場合、リスト値の検証よりもキー存在バリデータが効率的であり、これらの選択を翻訳する必要がある場合、リテラルの選択のかわりに静的ビュー・オブジェクトを使用します。

11.5.8 値が特定の範囲内にあることを確認する方法

範囲バリデータは、エンティティ属性と値の範囲の論理比較を実行します。範囲バリデータの追加時に、最小および最大のリテラル値を指定します。範囲バリデータは、エンティティ属性の値が範囲内(指定された場合は、範囲外)にあることを検証します。

最小および最大値を動的に算出する必要がある場合や、エンティティの他の属性を参照する必要がある場合は、Script Expression Validatorを使用し、Groovy式を指定します。詳細は、「Groovy式でのビジネス・コンポーネントの参照に関する必知事項」と「Groovy式でのビジネス・コンポーネント属性値の操作に関する必知事項」を参照してください。

始める前に:

組込み検証規則に関する一般知識があると役立つ場合があります。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

特定の範囲内を検証するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、バリデータの追加先を選択して、「追加」アイコンをクリックします。

- エンティティ・レベルのバリデータを追加するには、「エンティティ」ノードを選択します。

- 属性レベルのバリデータを追加するには、「属性」ノードを開き、適切な属性を選択します。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「範囲」を選択します。

4. 「属性」リストで、適切な属性を選択します。

5. 「演算子」フィールドで、「Between」または「NotBetween」を選択します。

6. 「最小値」および「最大値」フィールドに適切な値を入力します。

7. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。

詳細は、「検証実行のトリガー」を参照してください。

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。

詳細は、「検証エラー・メッセージの作成」を参照してください。

9. 「OK」をクリックします。

11.5.9 範囲バリデータの使用時の処理

Rangeを検証すると、<RangeValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。次の例は、最小値が1で最大値が99のItemEO.Quantity属性を示しています。

<validation:RangeValidationBean
Name="QuantityRule0"
OnAttribute="Quantity"
OperandType="LITERAL"
Inverse="false"
MinValue="1"
MaxValue="99"/>

11.5.10 バイトまたは文字数に対する検証方法

長さバリデータは、属性値の文字列長(文字またはバイト)が、指定した数より小さい、等しい、それより大きい、またはその範囲内かどうかを検証します。

始める前に:

組込み検証規則に関する一般知識があると役立つ場合があります。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

バイトまたは文字数を検証するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、バリデータの追加先を選択して、「追加」アイコンをクリックします。

- エンティティ・レベルのバリデータを追加するには、「エンティティ」ノードを選択します。

- 属性レベルのバリデータを追加するには、「属性」ノードを開き、適切な属性を選択します。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「長さ」を選択します。

4. 「属性」リストで、適切な属性を選択します。

5. 「演算子」フィールドで、値を評価する方法を選択します。

6. 「比較タイプ」フィールドで、「バイト」または「文字」を選択し、長さを入力します。

7. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。詳細は、「検証実行のトリガー」を参照してください。

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、「検証エラー・メッセージの作成」を参照してください。

9. 「OK」をクリックします。

11.5.11 バイトまたは文字数に対する検証時の処理

長さを使用して検証すると、次の例に示すように、<LengthValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。たとえば、ユーザーがパスワードまたはPINを入力するフィールドがあり、アプリケーションによってそれが6文字以上、10文字以下であることを検証するとします。Length ValidatorでBetween演算子を使用し、最小値および最大値をそれぞれ設定します。

<validation:LengthValidationBean
OnAttribute="pin"
CompareType="BETWEEN"
DataType="CHARACTER"
MinValue="6"
MaxValue="10"
Inverse="false"/>

11.5.12 正規表現を使用した検証方法

正規表現バリデータは、Java正規表現によって指定されたマスクに対して属性値を比較します。

メタデータでパーソナライズできる式を作成する場合は、Script Expression Validatorを使用できます。詳細は、「ビジネス・ルールとトリガーでのGroovy式の使用」を参照してください。

始める前に:

組込み検証規則に関する一般知識があると役立つ場合があります。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

正規表現を使用して検証するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、バリデータの追加先を選択して、「追加」アイコンをクリックします。

- エンティティ・レベルのバリデータを追加するには、「エンティティ」ノードを選択します。

- 属性レベルのバリデータを追加するには、「属性」ノードを開き、適切な属性を選択します。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「正規表現」を選択します。

4. 「演算子」フィールドで、「一致」または「不一致」を選択します。

5. 事前定義された式(ある場合)を使用するには、ドロップダウン・リストから選択して「パターンの使用」をクリックします。事前定義された式を使用しない場合は、表示されているフィールドに独自の正規表現を記述します。

注意:

事前定義された式のリストに独自の式を追加することもできます。事前定義された式を追加するには、JDeveloperシステム・ディレクトリのBC4JサブディレクトリにあるPredefinedRegExp.propertiesファイル(例: C:\Documents and Settings\username\Application Data\JDeveloper\system##\o.BC4J\PredefinedRegExp.properties)にエントリを追加します。

6. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。詳細は、「検証実行のトリガー」を参照してください。

7. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、「検証エラー・メッセージの作成」を参照してください。

8. 「OK」をクリックします。

図11-4は、正規表現バリデータを選択して、Email属性が事前定義されたEmail Address式に一致することを検証する場合のダイアログを示しています。

図11-4 電子メール・アドレスを照合する正規表現バリデータ

11.5.13 正規表現を使用した検証時の処理

正規表現を使用して検証すると、<RegExpValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。次の例は、正規表現に一致する必要のあるEmail属性を示しています。

<validation:RegExpValidationBean
Name="EmailPrimaryRule0"
OnAttribute="EmailPrimary"
Pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}"
Flags="CaseInsensitive"
Inverse="false"/>

11.5.14 Average、Count、またはSumを使用したコレクションの検証方法

コレクションのAverage、Count、Sum、Min、またはMaxに対してコレクション検証を使用できます。このバリデータは、エンティティ・レベルでのみ使用できます。このバリデータは、子エンティティ(アソシエーションの多数の端)に対するエンティティ・アクセッサを介した、関連エンティティのコレクションに対する集計計算の検証に便利です。コレクション・バリデータを定義するには、アソシエーション・アクセッサを選択する必要があります。

始める前に:

組込み検証規則に関する一般知識があると役立つ場合があります。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

集約計算を使用した検証方法は次のとおりです。

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、「エンティティ」ノードを選択して、「追加」アイコンをクリックします。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「コレクション」を選択します。

4. 「操作」フィールドで、コレクションで比較に実行する操作(Sum、Average、Count、MinまたはMax)を選択します。

5. 検証に使用する適切なアクセッサと属性を選択します。

コンポジット・アソシエーション・アクセッサを選択する必要があります。この種のアクセッサのプロパティは、ドロップダウン・リストに表示されます。

6. 演算子を指定し、比較タイプと値を指定します。

7. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。詳細は、「検証実行のトリガー」を参照してください。

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、「検証エラー・メッセージの作成」を参照してください。

9. 「OK」をクリックします。

11.5.15 コレクション検証の使用時の処理

コレクション・バリデータを使用して検証すると、次の例のように、<CollectionValidationBean>タグがエンティティ・オブジェクトのXMLファイルに追加されます。

<validation:CollectionValidationBean
Name="OrdEORule01"
Accessor="ItemEO"
CollAttribute="Quantity"
OperandType="LITERAL"
Inverse="false"
CompareType="GREATERTHAN"
CompareValue="5"
Operation="min"/>

11.5.16 キーの存在の判別方法

キー存在バリデータは、キー値(主キー、外部キー、代替キーのいずれか)が存在するかどうか判別するために使用されます。

キー存在バリデータの使用には、次のようないくつかの利点があります。

- キー存在バリデータは、最初にキャッシュをチェックし、必要な場合にのみデータベースをチェックするため、パフォーマンスが向上します。

- キー存在バリデータはキャッシュを使用するため、現行トランザクションに追加されているが、まだデータベースにコミットされていないキー値を検出します。たとえば、新規のDepartmentを追加してから、そこにEmployeeをリンクします。

始める前に:

組込み検証規則に関する一般知識があると役立つ場合があります。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

値の存在を判別するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、バリデータの追加先を選択して、「追加」アイコンをクリックします。

- エンティティ・レベルのバリデータを追加するには、「エンティティ」ノードを選択します。

- 属性レベルのバリデータを追加するには、「属性」ノードを開き、適切な属性を選択します。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「キーの存在」を選択します。

4. 検証ターゲットのタイプ(「エンティティ・オブジェクト」、「ビュー・オブジェクト」またはビュー・アクセッサ」)を選択します。

このエンティティ属性を使用するすべてのビュー・オブジェクトにキー存在バリデータを使用する場合は、「エンティティ・オブジェクト」を選択します。

5. 検証ターゲットに応じて、アソシエーションまたはキー値を選択できます。

「検証ターゲット属性」リストにない属性を検索している場合は、キー値として定義されていない可能性があります。代替キーを作成するには、「代替キー値の定義方法」を参照してください。

6. 必要に応じて、「検証実行」タブをクリックして、依存属性や検証レベル(エンティティまたはトランザクション)などのルールの実行基準を入力できます。詳細は、「検証実行のトリガー」を参照してください。

7. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、「検証エラー・メッセージの作成」を参照してください。

8. 「OK」をクリックします。

図11-5は、PersonEOエンティティ・オブジェクトに入力したMembershipIdがMembershipBaseEOエンティティ・オブジェクトに存在するかどうかを検証するキー存在バリデータを示しています。

図11-5 エンティティ属性に対するキー存在バリデータ

11.5.17 キー存在バリデータの使用時の処理

キー存在バリデータを使用すると、次の例のように、<ExistsValidationBean>タグがエンティティ・オブジェクトのXMLファイルに作成されます。

<validation:ExistsValidationBean
Name="CustomerId_Rule_0"
ResId="oracle.summit.model.entities.OrdEO.CustomerId_Rule_0"
OperandType="EO"
AssocName="oracle.summit.model.entities.assoc.SOrdCustomerIdFkAssoc"/>

11.5.18 宣言的バリデータとビュー・アクセッサに関する必知事項

宣言的バリデータを使用する場合は、想定される入力値で検証がどのように実行されるかを考慮する必要があります。宣言的バリデータとビュー・アクセッサを組み合せることにより、簡単かつ強力なコーディングの代用として機能します。ただし、これらを組み合せると強力になる反面、データ構成がパフォーマンスに与える影響も考慮する必要があります。

次のようなシナリオを検討します。

- Product属性とRequestType属性を持つServiceRequestEOエンティティ・オブジェクト、およびRequestTypeVOビュー・オブジェクトへのアクセスを可能にするビュー・アクセッサ

- Product属性をバインド・パラメータとして指定する問合せを持つRequestTypeVOビュー・オブジェクト

RequestTypeの有効なリストは、Productによって変わります。このため、RequestType属性を検証するには、ビュー・アクセッサを使用するリスト・バリデータを使用します。

最初に、新規サービス・リクエストのセットを追加します。最初のサービス・リクエスト(行)に対して、リスト・バリデータはProduct属性の値をビュー・アクセッサに追加して実行します。次に、後続の各サービス・リクエストに対して、Product属性の新しい値と現時点でバインドされている値を比較します。

- Productの値が一致する場合、現在のRowSetオブジェクトは維持されます。

- Productの値が変更されている場合、新しい値がバインドされ、ビュー・アクセッサが再実行されます。

次に、想定される入力データの構成を検討します。たとえば、入力データに同じ製品が複数回現れるとします。受注品のデータを検証すると、次のようになっているとします。

1. ドライヤー(最初の問合せ)

2. 洗濯機(ビュー・アクセッサを再実行)

3. 食器洗浄機(ビュー・アクセッサを再実行)

4. 洗濯機(ビュー・アクセッサを再実行)

5. ドライヤー(ビュー・アクセッサを再実行)

この場合、バリデータは問合せを5回実行し、個別の行セットを3つ取得します。また、RequestTypeVOにORDER BY句を追加して、Product別にソートすることもできます。この場合、バリデータは洗濯機とドライヤーに対して問合せをそれぞれ1回のみ実行します。

1. 食器洗浄機(最初の問合せ)

2. ドライヤー(ビュー・アクセッサを再実行)

3. ドライヤー

4. 洗濯機(ビュー・アクセッサを再実行)

5. 洗濯機

このサイズのデータセットでは違いがあまり出ませんが、データセットのサイズが膨大になりユーザー数が多くなると、その差が大きな問題となります。ORDER BY句ですべての問題に対応できるとはかぎりませんが、この例は、データ構成がパフォーマンスにどのように影響を与えるかを示しています。

11.6 エンティティ・レベルのトリガーの使用方法

エンティティ・レベルのトリガーを使用すると、挿入操作の前や削除の後など、エンティティ・オブジェクトのライフサイクル内のトリガー・ポイントに対応して実行される式を実装できます。

たとえば、エンティティ・オブジェクトの挿入前やエンティティ・オブジェクトの更新後に、属性の値を評価またはアサートできます。使用可能なトリガー・ポイントのリストは、オンライン・ヘルプを参照してください。

11.6.1 エンティティ・レベルのトリガーを使用したビジネス・ルールの実装方法

Groovyスクリプトを使用して、エンティティ・レベルのトリガーに対応して実行されるビジネス・ルールを実装できます。

始める前に:
エンティティ・レベルのトリガーについて理解しておくと役立つ場合があります。詳細は、「エンティティ・レベルのトリガーの使用方法」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

トリガーを追加する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、トリガーを追加するエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビジネス・ルール」ナビゲーション・タブをクリックします。

3. 「ビジネス・ルール」ページで、エンティティ・レベルのトリガーのノードを選択し、「新規トリガーの作成」アイコンをクリックします。

4. 「タイプ」ドロップダウン・リストから適切なトリガー・ポイントを選択します。

5. Groovy式を入力します。

6. 「失敗処理」タブをクリックして、式が失敗した場合にユーザーに表示されるエラー・メッセージを入力または選択します。詳細は、「検証エラー・メッセージの作成」を参照してください。

Groovy式は、実行時に評価されるとき、信頼できる式として明示的に指定されていないかぎり、信頼できないと想定されます。実行時例外を回避するには、「プロパティ」ウィンドウを使用し、信頼できる式としてその式を指定します。詳細は、「信頼できないGroovy式に関する必知事項」を参照してください。

11.6.2 エンティティ・レベルのトリガーの作成時の処理

トリガーを作成すると、次の例に示すように、<Trigger>タグがエンティティ・オブジェクトのXMLファイルに追加されます。

<Trigger
Name="BeforeUpdate">
<validation:ExpressionValidationBean
Name="BeforeUpdateExpression0"
OperandType="EXPR"
Inverse="false">
<validation:TransientExpression
Name="ValidationRuleScript"
trustMode="untrusted"
hasReturn="false"
CodeSourceName="ItemEORow"/>
</validation:ExpressionValidationBean>
</Trigger>

11.7 ビジネス・ルールとトリガーでのGroovy式の使用

Groovy式はJavaのようなスクリプト・コードで、エンティティ・オブジェクトのXML定義とそのエンティティ・オブジェクトに関連する.bcsファイルに格納されます。Groovy式は.bcsファイルに格納されるため、このファイルで式の値を変更できます。

エンティティ・オブジェクトのビジネス・ロジックでのGroovyスクリプトの使用方法の詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。

11.7.1 Groovy式でのエンティティ・オブジェクト・メソッドの参照方法

現在のオブジェクトのsourceプロパティを使用すると、現在のエンティティ・インスタンスでメソッドをコールできます。sourceプロパティでは、エンティティ・インスタンスにアクセスできます。

メソッドがブール型以外で、メソッド名が引数なしのgetXyzAbc()の場合、XyzAbcという名前のプロパティのようにその値にアクセスします。ブール値プロパティの場合は、同じ条件が当てはまりますが、JavaBeanのgetterメソッドの命名パターンが変更され、getXyzAbc()ではなくisXyzAbc()を再認識します。エンティティ・オブジェクトのメソッドがJavaBeanのgetterメソッドの命名パターンに一致しない場合や、1つ以上の引数を使用する場合は、完全名を使用したメソッドのようにコールする必要があります。

たとえば、次の例に示すように、4つのメソッドを持つエンティティ・オブジェクトがあるとします。

public boolean isNewRow() {
System.out.println("## isNewRow() accessed ##");
return true;
}

public boolean isNewRow(int n) {
System.out.println("## isNewRow(int n) accessed ##");
return true;
}

public boolean testWhetherRowIsNew() {
System.out.println("## testWhetherRowIsNew() accessed ##");
return true;
}

public boolean testWhetherRowIsNew(int n) {
System.out.println("## testWhetherRowIsNew(int n) accessed ##");
return true;
}

次のGroovy検証条件では、この例に示すように、すべてを実行し、そのうちの1つは2回実行します。

newRow && source.newRow && source.isNewRow(5) && source.testWhetherRowIsNew() && source.testWhetherRowIsNew(5)

この例を実行してエンティティ検証を適用すると、次の診断結果がログ・ウィンドウに表示されます。

## isNewRow() accessed ##
## isNewRow() accessed ##
## isNewRow(int n) accessed ##
## testWhetherRowIsNew() accessed ##
## testWhetherRowIsNew(int n) accessed ##

名前がJavaBeansプロパティのgetterメソッドの命名パターンに一致するメソッドの参照では、構文にほとんど差がありません。newRowとsource.newRowは、両方とも、引数のないブール値のJavaBeans getterスタイル・メソッドにアクセスします。testWhetherRowIsNewメソッドは、JavaBeansのgetterメソッドのネーミング・パターンに一致せず、3番目のisNewRow()メソッドは引数を使用するため、完全名を使用するメソッドのようにコールする必要があります。

11.7.2 true/false式を使用した検証方法

Groovy式を使用してtrue/false文を返すことができます。スクリプト式バリデータでは、必ず式がtrueまたはfalseを返す必要があり、そうでなければadf.error.raise/warn()メソッドがコールされます。この機能の一般的な用途は、属性値の検証です(アカウント番号が有効であるかの確認など)。

注意:

adf.error.raise()メソッドを使用することにより(単純にtrueまたはfalseを返すかわりに)、ユーザーに表示するメッセージ・テキストを定義でき、エンティティレベル・バリデータを特定の属性に関連付けることができます。詳細は、「Groovyを使用して条件付きでエラー・メッセージを呼び出す方法」を参照してください。

始める前に:

検証規則でのGroovyの使用方法に関する知識があると役立つ場合があります。詳細は、「ビジネス・ルールとトリガーでのGroovy式の使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

true/false式を使用して検証するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、バリデータの追加先を選択して、プラス記号のアイコンのドロップダウンをクリックし、「新規バリデータ」を選択します。

- エンティティ・レベルのバリデータを追加するには、「エンティティ」ノードを選択します。

- 属性レベルのバリデータを追加するには、「属性」ノードを開き、適切な属性を選択します。

3. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで、「式」を選択します。

4. 「式」フィールドに検証式を入力します。

5. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を「式」フィールドに入力します。詳細は、「検証実行のトリガー」を参照してください。

6. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、「検証エラー・メッセージの作成」を参照してください。

7. 「OK」をクリックします。

次のGroovyスクリプトの例では、広範に使用されているチェックサムのLuhnアルゴリズムに基づいて口座番号を検証します。

@ValidatorExpression(name="PaymentOptionIdRule0", attributeName="PaymentOptionId")
def PaymentOptionId_PaymentOptionIdRule0_ValidationRuleScript_ValidationRule()
{
String acctnumber = newValue;
sumofdigits = 0;
digit = 0;
addend = 0;
timesTwo = false;
range = acctnumber.length()-1..0
range.each {i ->
digit = Integer.parseInt (acctnumber.substring (i, i + 1));
if (timesTwo) {
addend = digit * 2;
if (addend > 9) {
addend -= 9;
}
}
else {
addend = digit;
}
sumofdigits += addend;
timesTwo = !timesTwo;
}
modulus = sumofdigits % 10;
return modulus == 0;
}

11.7.3 Groovy式の追加時の処理

Groovy式を作成すると、エンティティ・オブジェクトのXMLコンポーネントに保存されます。次の例は、エンティティ・オブジェクトのDateOrdered属性を示しています。Groovy式は<validation:ExpressionValidationBean>タグで囲まれています。XML定義のCodeSourceName="OrdEORow”が示すとおり、GroovyスクリプトはOrdEO.bcsファイルに格納されています。

<Attribute
Name="DateOrdered"
ColumnName="DATE_ORDERED"
SQLType="TIMESTAMP"
Type="java.sql.Date"
ColumnType="DATE"
TableName="S_ORD">
<DesignTime>
<Attr Name="_DisplaySize" Value="7"/>
</DesignTime>
<validation:ExpressionValidationBean
Name="DateOrderedRule0"
OperandType="EXPR"
Inverse="false">
<validation:TransientExpression
Name="ValidationRuleScript"
trustMode="untrusted"
CodeSourceName="OrdEORow"/>
</validation:ExpressionValidationBean>
</Attribute>

図11-6は、「検証規則の編集」ダイアログの検証式を示しています。

図11-6 Date Ordered属性の検証式

11.8 検証実行のトリガー

JDeveloperでは、検証をトリガーする属性を選択できるため、トリガー属性のいずれかの内容が保証されない場合にのみ検証実行が発生します。JDeveloperの以前のリリースでは、全体としてのエンティティの内容が保証されない場合は常に属性に対してエンティティ・レベルのバリデータが起動されていました。この機能については、「検証を起動する属性の指定方法」を参照してください。

JDeveloperでは、バリデータ実行の事前条件を指定することもできます(「検証の事前条件の設定方法」を参照)。また、トランザクション・レベルの検証を設定することもできます(「トランザクション・レベルの検証の設定方法」を参照)。

11.8.1 検証を起動する属性の指定方法

エンティティ・レベルでバリデータを定義する場合、変更時にバリデータの実行をトリガーする、エンティティ・オブジェクトの1つ以上の属性を選択するオプションがあります。

注意:

1つの属性の有効性が別の属性に依存する場合、検証は属性の検証ではなくエンティティの検証として実行する必要があります。エンティティ・レベルや属性レベルで検証実行の順序を設定できます。

依存属性を1つ以上指定しないと、エンティティの内容が保証されていない場合にバリデータが常に起動します。必要な場合にのみ検証を実行することで、アプリケーションをより高性能にします。

始める前に:

検証規則のトリガー方法に関する知識があると役立つ場合があります。詳細は、「検証実行のトリガー」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

検証を起動する属性を指定するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、「エンティティ」ノードを選択して、「編集」アイコンをクリックします。

3. 「検証規則の編集」ダイアログで、「検証実行」タブをクリックします。

4. 検証を起動する属性を選択します。

5. 「OK」をクリックします。

たとえば、SummitADFアプリケーション・ワークスペースで、OrdEOエンティティ・オブジェクトにはDateOrdered属性より後のDateShipped属性が必要なエンティティ・レベルのバリデータがあります。図11-7に示すように、このバリデータはDateShipped属性またはDateOrdered属性の変更時にのみ、エンティティ・オブジェクト上で実行するように設定されています。

図11-7 「検証ルールの編集」ダイアログの「検証実行」タブでのトリガー属性

11.8.2 属性のトリガーによる検証実行制約時の処理

「検証ルールの編集」ダイアログの「検証実行」タブでトリガー属性を指定すると、JDeveloperは<validation:OnAttributes>タグを、エンティティ・オブジェクトのXMLファイルのバリデータ定義に追加します。次の例は、コアSummit ADFサンプル・アプリケーションにおけるOrdEOエンティティ・オブジェクトのエンティティ・レベルのバリデータのXMLコードを示しています。

<validation:CompareValidationBean
Name="OrdEO_Rule_0"
ResId="oracle.summit.model.entities.OrdEO_Rule_0"
OnAttribute="DateShipped"
OperandType="ATTR"
Inverse="false"
CompareType="GREATERTHANEQUALTO"
CompareValue="DateOrdered">
<validation:OnAttributes>
<validation:Item
Value="DateShipped"/>
<validation:Item
Value="DateOrdered"/>
</validation:OnAttributes>
</validation:CompareValidationBean>

11.8.3 検証の事前条件の設定方法

「検証実行」タブ(検証規則の追加/編集ダイアログ)で、事前条件として機能するGroovy式を追加できます。「条件付実行式」ボックスに式を入力すると、条件がTrueに評価された場合のみ、バリデータが実行されます。

ベスト・プラクティス

一意キー・バリデータの事前条件の追加が可能ですが、ベスト・プラクティスではありません。一意キー・バリデータが起動できない場合でもキャッシュの一貫性チェックが実行されるため、エラーが返されます。通常は、バリデータおよびわかりやすいエラー・メッセージを追加するのが適切です。

11.8.4 トランザクション・レベルの検証の設定方法

トランザクション・レベル(エンティティ・レベルではなく)での検証は、すべてのエンティティ・レベルの検証の実行後に実行されます。このため、バリデータがプロセスの終了時に実行されることを確認する場合に便利です。

さらにKey Existsバリデータをトランザクション・レベルで実行すると、エンティティごとではなく、トランザクション内の全エンティティ(同じ型の)に対して1度だけ実行されるので、 大量のトランザクションでは高いパフォーマンスが得られます。これにより、バリデータをデータベースに使用する場合はパフォーマンスの改善につながります。

注意:

トランザクション・レベルの検証は、Key ExistsおよびMethodエンティティ・バリデータにのみ適用できます。

始める前に:

検証規則のトリガー方法に関する知識があると役立つ場合があります。詳細は、「検証実行のトリガー」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

エンティティ・レベルまたはトランザクション・レベルの検証を指定するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、エンティティ・レベルの検証ルールを選択して、「編集」アイコンをクリックします。

3. 「検証規則の編集」ダイアログで、「検証実行」タブをクリックします。

4. 「エンティティ・レベルで実行」または「トランザクション・レベルの遅延実行」を選択します。

5. 「OK」をクリックします。

11.8.5 検証実行の順序に関する必知事項

属性の検証順序は制御できません。エンティティ定義の順番で常に検証されます。特定の属性(またはエンティティ)の検証の順番を指定することはできますが、属性自体の順番を変更することはできません。

11.9 検証エラー・メッセージの作成

検証エラー・メッセージはユーザーにとって重要な情報であり、メッセージは不具合やその修正方法を伝達する必要があります。

11.9.1 バリデータとトリガーのエラー・メッセージの作成方法

検証ルールまたはトリガーを作成または編集する場合、ユーザーがエラーの原因を判断するために有用なテキストを入力できます。

始める前に:

検証規則のエラー・メッセージに関する知識があると役立つ場合があります。詳細は、「検証エラー・メッセージの作成」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「宣言的な検証の追加機能」を参照してください。

バリデータまたはトリガーのエラー・メッセージを作成する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで「ビジネス・ルール」ナビゲーション・タブをクリックし、検証ルールまたはトリガーを選択して、「編集」アイコンをクリックします。

3. 「編集」ダイアログで、「失敗処理」タブをクリックします。

4. 「メッセージ・テキスト」フィールドで、エラー・メッセージを入力します。

メッセージ・バンドル・ファイルにエラー・メッセージを定義することもできます。定義済のエラー・メッセージを選択する場合や、メッセージ・バンドル・ファイルに新しいエラー・メッセージを定義する場合は、「メッセージの選択」アイコンをクリックします。

注意:

トリガーおよびスクリプト式バリデータでは、複数のエラー・メッセージを入力できます。これは、条件によって異なるエラーメッセージや警告メッセージを検証スクリプトで戻す場合に便利です。詳細は、「Groovyを使用して条件付きでエラー・メッセージを呼び出す方法」を参照してください。

5. 必要に応じて、メッセージの本文にメッセージ・トークンを含めることができます。メッセージ・トークンは、「トークン・メッセージ式」リストで定義します。

図11-8は、メッセージ・トークンを含むOrdEOエンティティ・オブジェクトの検証ルールの失敗メッセージを示しています。この機能の詳細は、「エラー・メッセージにGroovy式を埋め込む方法」を参照してください。

6. 「OK」をクリックします。

11.9.2 検証メッセージのローカライズ方法

エラー・メッセージは翻訳可能文字列であり、エンティティ・オブジェクトのメッセージ・バンドル・クラスの翻訳可能UIコントロール・ヒントと同じように管理されます。メッセージ・バンドル・クラス内の定義済規則のエラー・メッセージを表示するには、そのバリデータに関するXMLドキュメント・エントリのResIdプロパティに対応するメッセージ・バンドルのStringキーを探します。たとえば、次の例は、NAME_CANNOT_BEGIN_WITH_Uキーがデフォルト・ロケールのエラー・メッセージとともに表示されるメッセージ・バンドルを示しています。

アプリケーションのリソース・バンドルは、リスト・リソース・バンドル(次の例を参照)、プロパティ・バンドル、またはXLIFFリソース・バンドルとして作成できます。リソース・バンドルでの変換可能な文字列の使用の詳細は、「リソース・バンドルの使用」を参照してください。

package devguide.advanced.customerrors;
import java.util.ListResourceBundle;

public class CustomMessageBundle extends ListResourceBundle {
private static final Object[][] sMessageStrings = new String[][] {
// other strings here
{"NAME_CANNOT_BEGIN_WITH_U", "The name cannot begin with the letter u!"},
// other strings here
};
// etc.
}

11.9.3 Groovyを使用して条件付きでエラー・メッセージを呼び出す方法

adf.error.raise()およびadf.error.warn()メソッドを使用して、Groovy式の分岐に応じて様々なエラー・メッセージを条件付きで呼び出すことができます。たとえば、属性値がxの場合は次のように検証し、検証が失敗した場合はエラーメッセージAを呼び出し、一方、属性値がyの場合は別の検証を実行し、検証が失敗した場合はエラーメッセージBを呼び出します。

式でfalseが戻される(raise()メソッドを使用して特定のエラー・メッセージが呼び出されるのに対して)場合、バリデータは、そのバリデータに関連付けられた最初のエラー・メッセージをコールします。

raise()メソッドの構文は必須パラメータを1つ(メッセージ・バンドルから使用するためのmsgId)利用し、オプションでattrNameパラメータを利用することができます。AttrNameに渡すと、検証がエンティティに割り当てられている場合でも、エラーはその属性に関連付けられます。

例外をスローするか、処理を継続するかに応じて、adf.error.raise()またはadf.error.warn()のいずれかのメソッドを使用できます(「検証例外の重大度レベルの設定」を参照)。

11.9.4 エラー・メッセージにGroovy式を埋め込む方法

バリデータのエラー・メッセージには、実行時にサーバーによって解決できる埋込み式を含めることができます。この機能にアクセスするには、Groovy式の結果を表示させるエラー・メッセージ・テキストに名前付きトークン{#}({2}や{errorParam}など)を入力するのみです。

「検証規則の編集」ダイアログの「失敗処理」タブで、エラー・メッセージのテキストにトークンを入力すると、ダイアログの下部の「トークン・メッセージ式」表で行が表示され、トークンのGroovy式を入力できます。図11-8は、メッセージ・トークンを含むOrdEOエンティティ・オブジェクトの検証ルールの失敗メッセージを示しています。

図11-8 失敗メッセージでのメッセージ・トークンの使用

図11-8に示された式は、指定したフィールドのラベルを返すGroovy式です。Groovy式を使用して属性値やその他のビジネス・コンポーネント・オブジェクトにアクセスすることもできます。たとえば、Groovy式newValueを使用して入力された値を戻すことができます。

ビュー・アクセッサから値を取得するためのGroovy構文は、accessorName.currentRow.AttributeNameです。たとえば、Groovy式MyEmpAccessor.currentRow.Jobは、MyEmpAccessorビュー・アクセッサの現在の行のJob属性値を返します。

次の例のように複雑なGroovy式を使用して、OrdEOエンティティ・オブジェクト内のPaymentTypeId属性のList検証ルールのエラー・メッセージに式を表示することもできます。

cr = CustomerEO.CreditRatingId
ratings = [1, 2]
if (cr  in ratings)
{return true}
else
{return false}

Groovyを使用したビジネス・コンポーネント・オブジェクトへのアクセスの詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。

11.10 検証例外の重大度レベルの設定

検証例外の重大度レベルについて、「情報警告」および「エラー」の2つのレベルを設定できます。重大度レベルを「情報警告」に設定すると、エラー・メッセージが表示されますが、処理は継続します。検証レベルを「エラー」に設定すると、エラーが修正されるまでユーザーは処理を続行できません。

通常、検証例外には「エラー」レベルを使用するため、これがデフォルト設定です。ただし、ユーザーが特定の機密取扱い資格を保持する場合は、情報警告メッセージを実装できます。たとえば、店長は事務員が同じことをした場合に、エラーとして表示されるように変更できます。

重大度レベルが「情報警告」に設定されている場合、エラー・アイコンではなく警告アイコンとともにエラー・メッセージが表示され、警告を確認した後に変更の保存に進むことができます。

検証例外の重大度レベルを設定するには、「検証ルールの追加」ダイアログの「失敗処理」タブを使用します。

検証例外の重大度レベルを設定するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビジネス・ルール」ナビゲーション・タブをクリックします。

3. 「ビジネス・ルール」ページで、既存の検証規則を選択して「編集」アイコンをクリックするか、「追加」アイコンをクリックして新規の規則を作成します。

4. 検証規則の追加/編集ダイアログで、「失敗処理」タブをクリックし、「エラー」または「情報警告」のいずれかのオプションを選択します。

5. 「OK」をクリックします。

11.11 SQLでのバルク検証

データ同期プログラムなどのバッチロード・アプリケーションのパフォーマンスを向上させるため、Oracle ADFでは、主キー(代替キーを含む)および外部キーにバルク検証を採用しています。

トランザクションがコミットするまで検証を遅延するようにキー存在バリデータを構成している場合や、ADFビジネス・コンポーネントのサービス・レイヤーのprocessXXXメソッドで行が更新または挿入されている場合、検証キャッシュが事前ロードされます。この動作は通常の行ごとの導出および検証ロジックを使用しますが、データベースに問い合せる前にメモリー・キャッシュをチェックする検証ロジックを使用します。パフォーマンスは、インバウンド・データに基づいてバルクSQL操作を使用するメモリー・キャッシュの事前ロードによって向上します。

12 プログラムによる検証とビジネス・ルールの実装

この章では、ADFエンティティ・オブジェクトのイベントと機能を使用して、ビジネス・ルールをOracle ADFアプリケーション内でプログラム的に実装する方法について説明します。また、setterメソッドを使用したエンティティ行への移入など、カスタム検証コードの起動方法についても説明します。

この章の内容は次のとおりです。

- プログラム的なビジネス・ルールについて

- メソッド・バリデータの使用

- プログラム的な導出属性値の割当て

- refreshメソッドを使用した、エンティティに対する保留中の変更の取消し

- 検証でのビュー・オブジェクトの使用

- アソシエーション・アクセッサを使用した、関連するエンティティ行へのアクセス

- 認証されたユーザーに関する情報の参照

- 元の属性値へのアクセス

- 現在のユーザー・セッションに関する情報の格納

- 現在の日時へのアクセス

- 正常に完了したコミットに関する通知の送信

- エンティティ行削除の条件付き禁止

- 属性に対する条件付きの更新可能性の判断

- カスタム検証規則の実装

12.1 プログラム的なビジネス・ルールについて

内蔵された宣言型検証機能を補完するため、エンティティ・オブジェクトとビュー・オブジェクトにはJavaコードを使用してカプセル化されたビジネス・ロジックをプログラミングによって実装できる操作可能なメソッド・バリデータといくつかのイベントがあります。これらの概念を、図12-1に示します。

- 属性レベルのメソッド・バリデータは、属性値が変更されると、検証コードをトリガーします。

- エンティティ・レベルのメソッド・バリデータは、エンティティ行が検証されると、検証コードをトリガーします。

- あるエンティティに対して、次の主要メソッドをカスタムJavaクラスでオーバーライドできます。

- create(): 行の作成時にデフォルト値を割り当てます。

- initDefaultExpressionAttributes(): 行の作成時、または新規行のリフレッシュ時にデフォルト値を割り当てます。

- remove(): 条件付きで削除を制限します。

- isAttributeUpdateable(): 属性を条件付きで更新可能にします。

- setAttribute(): 属性レベルのメソッド・バリデータをトリガーします。

- validateEntity(): エンティティ・レベルのメソッド・バリデータをトリガーします。

- prepareForDML(): エンティティ行が保存される前に属性値を割り当てます。

- beforeCommit(): 指定された型のすべてのエンティティ行に関連する規則を実行します。

- afterCommit(): エンティティ・オブジェクトの状態の変更に関する通知を送信します。

図12-1 プログラム的なビジネス・ロジックにおける主要なエンティティ・オブジェクトの機能とイベント

注意:

新規行と変更された行のみがトランザクション検証の対象となります。削除された行はトランザクションの一部ですが、検証には含まれません。

プログラム的なビジネス・ルールをコーディングする場合、検証サイクルを正確に把握しておくことが重要です。詳細は、「検証サイクルの理解」を参照してください。

12.1.1 プログラム的なビジネス・ルールのユースケースと例

ほとんどの検証は基本的な宣言的操作で実装できますが、メソッド・バリデータを使用してカスタム検証コードを起動することにより、必要に応じてビジネス・ドメイン・レイヤーにより複雑なビジネス・ルールを実装できます。

プログラム的なビジネス・ルールを使用する場合としては、次の例があります。

- データベース順序からの属性値のデフォルト設定

- 複雑な計算から導出された値の割当て

- エンティティ・オブジェクトに対する保留中の変更の取消し

- 現在のユーザー・セッションに関する情報のアクセスと格納

- 属性の条件付き更新可能性の判断

12.1.2 プログラム的なビジネス・ルールの追加機能

プログラム的な検証を使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- ビジネス・ルールをプログラム的に実装する前に、宣言的検証でアプリケーションのニーズに対応できるかどうかを確認する必要があります。詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

- リソース・バンドルを使用して、ローカライズ可能な検証エラー・メッセージを用意できます。「リソース・バンドルの使用」を参照してください。

- 「トリガーによって割り当てられた値を同期化する方法」で、主キーの属性にDBSequence型を使用する方法を説明しています。この種の属性の値は、コミット時にデータベース・シーケンスによって取り込む必要があります。

- 認証されたユーザーに関する情報へのアクセス方法など、Oracle Fusion Webアプリケーションのセキュリティ機能の詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

- エンティティ・オブジェクトのビジネス・ロジックでのGroovyスクリプトの使用方法の詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。

12.2 メソッド・バリデータの使用

メソッド・バリデータは、独自のJavaコードを使用した宣言的な検証規則とGroovyスクリプト式を補完する主要な手段です。メソッド・バリデータでは、独自の検証メソッド内に記述したJavaコードが、エンティティ・オブジェクト検証サイクルにおいて適切なタイミングでトリガーされます。メソッド・バリデータにより、属性またはエンティティ全体で、様々な型の検証をコーディングできます。

それぞれがコード内の異なるメソッド名をトリガーしていれば、任意の数の属性レベルまたはエンティティレベルのメソッドを追加できます。すべての検証メソッド名はvalidateというワードで開始する必要があります。ただし、この規則にさえ従っていれば、機能を明確に示す任意の方法で名前を付けることができます。属性レベルのバリデータでは、メソッドはエンティティ属性と同じ型の引数を1つだけ取ります。エンティティレベルのバリデータでは、メソッドは引数を取りません。メソッドはパブリックで、ブール値を返す必要があります。メソッドからfalseが返されると、検証は失敗します。

注意:

これらの規則を知っておくことは必要ですが、JDeveloperを使用してメソッド・バリデータを作成する場合、そのクラスの正しいインタフェースが作成されます。

実行時には、メソッド・バリデータにより、エンティティ属性がエンティティ・オブジェクト・クラスで実装されているメソッドに渡されます。

次の例では、メソッドは大文字で始まり、NULL値で例外をスローする文字列、空の文字列、および大文字で始まらない文字列を受け取ります。

public boolean validateIsCapped(String text)
{
if (text != null &&
text.length() != 0 &&
text[0] >= 'A' &&
text[0] <= 'Z')
{
return true;
}
}

12.2.1 属性レベルのメソッド・バリデータの作成方法

メソッド・バリデータの使用は、宣言的検証規則をプログラム的に補完する手段です。

始める前に:

メソッド・バリデータに関する知識があると役立つ場合があります。詳細は、「メソッド・バリデータの使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「プログラム的なビジネス・ルールの追加機能」を参照してください。

属性レベルのメソッド・バリデータを作成するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックします。

Javaページには、そのエンティティ・オブジェクトに対して現在有効なJava生成オブジェクトが表示されます。エンティティ・オブジェクトにカスタム・エンティティ・オブジェクト・クラスがない場合は、Methodバリデータの追加前に生成しておく必要があります。カスタムJavaクラスを生成するには、「編集」アイコンをクリックし、次に「エンティティ・オブジェクト・クラスの生成」を選択し、「OK」をクリックして、*.javaファイルを生成します。

3. 「ビジネス・ルール」ナビゲーション・タブをクリックし、「属性」セクションを開いて、検証する属性を選択します。

4. 「新規」アイコンをクリックし、検証規則を追加します。

5. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「メソッド」を選択します。

図12-2 属性レベルのメソッド・バリデータの追加

「検証ルールの追加」ダイアログに、属性レベルの検証メソッドで期待されるメソッド・シグネチャが表示されます。次のいずれかを選択できます。

- エンティティ・オブジェクトのカスタムJavaクラスに、適切なシグネチャのあるメソッドがすでに存在する場合、リストに表示されます。これは「メソッドの作成と選択」チェック・ボックスの選択を解除した後に選択できます。

- 「メソッドの作成と選択」チェック・ボックスを選択したままにすると(図12-2を参照)、validateから始まるどのようなメソッド名でも「メソッド名」ボックスに入力できます。「OK」をクリックすると、適切なシグネチャとともに、メソッドがエンティティ・オブジェクトのカスタムJavaクラスに追加されます。

6. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。詳細は、「検証実行のトリガー」を参照してください。

7. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。

詳細は、「検証エラー・メッセージの作成」を参照してください。

12.2.2 属性レベルのメソッド・バリデータを作成するときに行われる処理

メソッド・バリデータを新たに追加すると、JDeveloperでは新しい検証ルールを反映するように、XMLドキュメントが更新されます。メソッドの作成を指定した場合、そのメソッドはエンティティ・オブジェクトのカスタムJavaクラスに追加されます。次の例は、注文のOrderShippedDateが現在月の日付であることを確認する、簡単な属性レベルの検証ルールを示しています。メソッドには、対応する属性と同じ型の引数が与えられ、その条件付きのロジックはこの入力パラメータの値に基づいています。属性バリデータの起動時、属性値は対象となる新しい新しい値にはまだ設定されていません。したがって、getOrderShippedDate()メソッドをOrderShippedDate属性に対する属性バリデータ内でコールしても、クライアントが設定しようとしている候補値ではなく、属性の現在の値が返されます。

注意:

compareTo()メソッドの戻り値は、2つの日付が等しい場合はゼロ(0)、最初の日付が次の日付より前の場合はマイナス1(-1)、最初の日付が次の日付より後の場合はプラス1 (1)となります。

public boolean validateOrderShippedDate(Date  data) {
if (data != null && data.compareTo(getFirstDayOfCurrentMonth()) <= 0) {
return false;
}
return true;
}

12.2.3 エンティティ・レベルのメソッド・バリデータの作成方法

エンティティ・レベルのメソッド・バリデータは、有効範囲がより広く、単一の属性ではなくエンティティ全体が範囲になる点を除けば、属性レベルのメソッド・バリデータと似ています。

さらに、エンティティレベルのメソッド・バリデータを使用している場合は、バリデータの実行をトランザクションの時間まで遅延できます。

始める前に:

メソッド・バリデータに関する知識があると役立つ場合があります。詳細は、「メソッド・バリデータの使用」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「プログラム的なビジネス・ルールの追加機能」を参照してください。

エンティティ・レベルのメソッド・バリデータを作成するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックします。

Javaページには、そのエンティティ・オブジェクトに対して現在有効なJava生成オブジェクトが表示されます。エンティティ・オブジェクトにカスタム・エンティティ・オブジェクト・クラスがない場合は、Methodバリデータの追加前に生成しておく必要があります。カスタムJavaクラスを生成するには、「編集」アイコンをクリックし、次に「エンティティ・オブジェクト・クラスの生成」を選択し、「OK」をクリックして、*.javaファイルを生成します。

3. 「ビジネス・ルール」ナビゲーション・タブをクリックして「エンティティ」ノードを選択し、「新規」アイコンをクリックして検証ルールを追加します。

4. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「メソッド」を選択します。

「検証ルールの追加」ダイアログに、エンティティレベルの検証メソッドで期待されるメソッド・シグネチャが表示されます。次のいずれかを選択できます。

- エンティティ・オブジェクトのカスタムJavaクラスに、適切なシグネチャのあるメソッドがすでに存在する場合、リストに表示されます。これは「メソッドの作成と選択」チェック・ボックスの選択を解除した後に選択できます。

- 「メソッドの作成と選択」チェック・ボックスを選択したままにすると(図12-3を参照)、validateから始まるどのようなメソッド名でも「メソッド名」ボックスに入力できます。「OK」をクリックすると、適切なシグネチャとともに、メソッドがエンティティ・オブジェクトのカスタムJavaクラスに追加されます。

5. 必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などのルールの実行基準を入力します。詳細は、「検証実行のトリガー」を参照してください。

図12-3 エンティティ・レベルのメソッド・バリデータの追加

Methodエンティティ・バリデータの場合は、「検証実行」タブを使用して検証レベルを指定することもできます。「トランザクション・レベルの遅延実行」を選択した場合は、エンティティがコミットされるとバリデータが起動します。これは、1つの表に編集対象の複数の行が表示される場合に役立ちます。

6. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。

詳細は、「検証エラー・メッセージの作成」を参照してください。

12.2.4 エンティティ・レベルのメソッド・バリデータを作成するときに行われる処理

メソッド・バリデータを新たに追加すると、JDeveloperでは新しい検証ルールを反映するように、XMLドキュメントが更新されます。メソッドの作成を指定した場合、そのメソッドはエンティティ・オブジェクトのカスタムJavaクラスに追加されます。次の例は、注文のDateShippedがDateOrderedより後であることを確認する、簡単なエンティティ・レベルの検証ルールを示しています。

public boolean validateDateShippedAfterDateOrdered() {
Date DateShipped = getDateShipped();
Date DateOrdered  = getDateOrdered();
if (DateShipped != null && DateShipped.compareTo(DateOrdered) < 0) {
return false;
}
return true;
}

「検証ルールの追加」ダイアログの「検証実行」タブで「トランザクション・レベルの遅延実行」を選択し、エンティティ・オブジェクトを表示するページでSkipValidation="skipDataControls"と設定した場合は、トランザクションの時間まで検証を延期できます。これにより、1つの表で複数の行を変更してから、ユーザーのコミット時にそれらをグループとして検証できます。次の例は、エンティティ行の集合の部門名がNULLでないことを検証するメソッド・バリデータを示しています。

// Validation method for Departments.
public boolean validateDepartments(ArrayList ctxList) {
Iterator iter = ctxList.iterator();
while (iter.hasNext()) {
JboValidatorContext entValContext = (JboValidatorContext)iter.next();
DepartmentsImpl deptEO = (DepartmentsImpl)entValContext.getSource();
if (deptEO.getDepartmentName() == null) {
// if Dept is null, throw error
return false;
}
}
return true;
}

12.2.5 検証規則エラー・メッセージの翻訳に関する必知事項

エンティティ・オブジェクト属性のロケール固有のUIコントロールのヒントと同様に、検証規則のエラー・メッセージは、エンティティ・オブジェクトのコンポーネント・メッセージ・バンドル・ファイルに追加されます。メッセージ・バンドル内のこれらのエンティティは、アプリケーションのデフォルトのロケールの文字列を表します。検証エラー・メッセージの翻訳バージョンについては、「リソース・バンドルの使用」で説明したUIコントロール・ヒントの翻訳と同様の手順で追加してください。

12.3 プログラム的な導出属性値の割当て

宣言的なデフォルト設定では不十分なとき、次の場合にエンティティ・オブジェクトでプログラムによるデフォルト設定を実行できます。

- エンティティ行が最初に作成される場合

- エンティティ行が最初に作成される場合、またはリフレッシュされてNULL値に設定される場合

- エンティティ行がデータベースに保存される場合

- エンティティ属性値が設定される場合

12.3.1 新しい行に対する作成時のデフォルト値の指定方法

create()メソッドは、エンティティ行の最初の作成時にデフォルト値の初期化処理を可能にするエンティティ・オブジェクト・イベントを提供します。次の例は、エンティティ・オブジェクトの作成メソッドのオーバーライドを示しています。このメソッドは、新しい注文エンティティ行に、DateOrdered属性を移入する属性のsetterメソッドをコールします。

デフォルト値は、Groovy式を使用して定義することもできます。詳細は、「静的なデフォルト値を定義する方法」を参照してください。

注意:

オーバーライドされたcreate()メソッド内でsetAttribute()メソッドをコールした場合、新規行はユーザー変更の行としてマークされません。このようにプログラム的に割り当てられたデフォルト値は、宣言的に割り当てられたデフォルト値のように動作します。また、create()メソッドに加えた変更はすべてsuper.create()のコール後に実行される点にも注意してください。

// In entity object implementation class
protected void create(AttributeList nameValuePair) {
super.create(nameValuePair);
this.setDateOrdered(new Date());
}

12.3.1.1 create()メソッドとinitDefaultExpressionAttributes()メソッドのいずれかの選択

行が最初に作成されたとき、および初期化状態にリフレッシュされたときの両方で実行するプログラム的なデフォルト設定ロジックでは、initDefaultExpressionAttributes()メソッドをオーバーライドする必要があります。

エンティティ行がNew状態であり、そのエンティティ行に対してrefresh()メソッドをコールした場合、REFRESH_REMOVE_NEW_ROWSフラグまたはREFRESH_FORGET_NEW_ROWSフラグを指定しないと、そのエンティティ行はInitialized状態に戻ります。このプロセスの一環として、エンティティ・オブジェクトのinitDefaultExpressionAttributes()メソッドが実行されますが、create()メソッドは再度実行されません。

12.3.1.2 データベース順序からの属性値のデフォルト設定

「トリガーによって割り当てられた値を同期化する方法」で、主キーの属性にDBSequence型を使用する方法を説明しています。この種の属性の値は、コミット時にデータベース・シーケンスによって取り込む必要があります。エンティティ行の作成時にユーザーが値を参照でき、この値がデータ保存時に変更されないように、順序番号を事前に割り当てる必要が生じることがあります。そのためには、次の例に示すように、オーバーライドされたcreate()メソッドでoracle.jbo.serverパッケージのSequenceImplヘルパー・クラスを使用します。これは、エンティティ・オブジェクトのカスタムJavaクラスからのコードを示しています。super.create()をコールした後に、順序名と現在のトランザクション・オブジェクトを渡し、SequenceImplオブジェクトの新規インスタンスを作成します。続いてSequenceImplのgetSequenceNumber()メソッドからの戻り値を含むsetWarehouseId()属性のsetterメソッドをコールします。

注意:

このアプローチに対するメタデータ駆動型の代替の詳細は、「Oracle順序を使用した主キー値の割当て」を参照してください。

// In entity object implementation class
import oracle.jbo.server.SequenceImpl;
// Default WarehouseId value from WAREHOUSE_SEQ sequence at entity row create time
protected void create(AttributeList attributeList) {
super.create(attributeList);
SequenceImpl sequence = new SequenceImpl("WAREHOUSE_SEQ",getDBTransaction());
setWarehouseId(sequence.getSequenceNumber());
}

12.3.2 保存前の導出値の割当て方法

行を保存する前に、プログラムによるデフォルト値をエンティティ・オブジェクトの属性値に割り当てる場合は、prepareForDML()メソッドをオーバーライドし、適切な属性のsetterメソッドをコールして、導出された属性値を移入します。INSERT、UPDATEまたはDELETEの処理中にのみ割当てを実行するには、DML_INSERT、DML_UPDATE、DML_DELETEのそれぞれの整数値の定数と、このメソッドに渡されたoperationパラメータの値を比較できます。

次の例は、導出値を割り当てるオーバーライドされたprepareForDML()メソッドを示しています。

protected void prepareForDML(int operation, TransactionEvent e) {
super.prepareForDML(operation, e);
//Populate GL Date
if (operation == DML_INSERT) {
if (this.getGlDate() == null) {
String glDateDefaultOption =
(String)this.getInvoiceOption().getAttribute("DefaultGlDateBasis");
if ("I".equals(glDateDefaultOption)) {
setAttribute(GLDATE, this.getInvoiceDate());
} else {
setAttribute(GLDATE, this.getCurrentDBDate());
}
}
}

//Populate Exchange Rate and Base Amount if null
if ((operation == DML_INSERT) || (operation == DML_UPDATE)) {
BigDecimal defaultExchangeRate = new BigDecimal(1.5);
if ("Y".equals(this.getInvoiceOption().getAttribute("UseForeignCurTrx"))) {
if (!(this.getInvoiceCurrencyCode().equals(
this.getLedger().getAttribute("CurrencyCode")))) {
if (this.getExchangeDate() == null) {
setAttribute(EXCHANGEDATE, this.getInvoiceDate());
}
if (this.getExchangeRateType() == null) {
String defaultConvRateType =
(String)this.getInvoiceOption().getAttribute("DefaultConvRateType");
if (defaultConvRateType != null) {
setAttribute(EXCHANGERATETYPE, defaultConvRateType);
} else {
setAttribute(EXCHANGERATETYPE, "User");
}
}
if (this.getExchangeRate() == null) {
setAttribute(EXCHANGERATE, defaultExchangeRate);
}
if ((this.getExchangeRate() != null) &&
(this.getInvoiceAmount() != null)) {
setAttribute(INVAMOUNTFUNCCURR,
(this.getExchangeRate().multiply(this.getInvoiceAmount())));
}
} else {
setAttribute(EXCHANGEDATE, null);
setAttribute(EXCHANGERATETYPE, null);
setAttribute(EXCHANGERATE, null);
setAttribute(INVAMOUNTFUNCCURR, null);
}
}
}
}

12.3.3 属性値が設定されている場合の、導出値の割当て方法

他の属性値が設定されているときに、導出された属性値を割り当てるには、最後の属性のsetterメソッドにコードを追加します。次の例は、エンティティ・オブジェクトのAssignedTo属性に対するsetterメソッドを示しています。

setAttributeInternal()をコールしてAssignedTo属性の値を設定すると、AssignedDate属性のsetterメソッドにより、現在日時の値が設定されます。

注意:

ここで説明した生成済の属性のgetterメソッドとsetterメソッドへのカスタム・コードの追加は、安全に行うことができます。JDeveloperでクラスのコードが変更された場合でも、カスタム・コードはそのまま保持されます。

public void setAssignedTo(Number value) {
setAttributeInternal(ASSIGNEDTO, value);
setAssignedDate(getCurrentDateWithTime());
}

12.4 refreshメソッドを使用した、エンティティに対する保留中の変更の取消し

refresh(int flag)メソッドを行に対して使用すると、保留中のすべての変更をリフレッシュできます。refresh()メソッドの動作は、パラメータとして渡すフラグによって決まります。この動作を制御する3つの主要なフラグの値は、Rowインタフェースの次の定数です。

- REFRESH_WITH_DB_FORGET_CHANGESは、現在のトランザクションによる行への変更を破棄し、行データがデータベースからリフレッシュされます。行が変更されたかどうかにかかわらず、現在の行はデータベースの最新データで上書きされます。

- REFRESH_WITH_DB_ONLY_IF_UNCHANGEDは、unmodified以外は、REFRESH_WITH_DB_FORGET_CHANGESと同一の機能をします。現在のトランザクションで行がすでに変更されている場合は、行はリフレッシュされません。

- REFRESH_UNDO_CHANGESは、unmodified行に対してREFRESH_WITH_DB_FORGET_CHANGESと同一の機能をします。変更された行については、このモードは、トランザクションの開始時点での属性値でリフレッシュします。リフレッシュ操作前に現在のトランザクション内でこの行がポスト済だったが未コミットの場合、この行は修正済状態を維持します。

12.4.1 リフレッシュ中の新規行の動作の制御方法

デフォルトでは、refresh()を実行したNew状態のすべてのエンティティ行がInitialized状態の空白行に戻ります。宣言的なデフォルト値と、initDefaultExpressionAttributes()メソッドに記述されたプログラム的なデフォルトはリセットされますが、エンティティ・オブジェクトのcreate()メソッドは、この無効化のプロセスでは実行されません。

このデフォルトの動作は、次の2つのフラグのうちの1つと、「refreshメソッドを使用した、エンティティに対する保留中の変更の取消し」のフラグの1つをビット単位のOR演算子によって組み合せて変更できます。

- REFRESH_REMOVE_NEW_ROWS: リフレッシュ時に新しい行が削除されます。

- REFRESH_FORGET_NEW_ROWS: 新しい行はDeadとマークされます。

12.4.2 構成される側の子エンティティ行へのリフレッシュのカスケード方法

REFRESH_CONTAINEESフラグと、「refreshメソッドを使用した、エンティティに対する保留中の変更の取消し」および「リフレッシュ中の新規行の動作の制御方法」で説明した有効なフラグの組合せをビット単位のOR演算子を使用して、構成される側の子エンティティ行をrefresh()操作でカスケードできます。このため、エンティティにより、構成される側の子エンティティに対し、同じモードでrefresh()が実行されます。

12.5 検証でのビュー・オブジェクトの使用

ビジネス・ロジックでSQL問合せの実行が必要とされる場合、一般的には、そのタスクの実行にはビュー・オブジェクトを使用します。検証のために実行するSQL文では、エンティティ・ベースのビュー・オブジェクトであれば、エンティティ・キャッシュ内の保留中の変更が参照されます。読取り専用ビュー・オブジェクトでは、データベースに送信されたデータのみを取得します。

12.5.1 ビュー・オブジェクトに対する検証用ビュー・アクセッサの使用方法

エンティティ・オブジェクトは任意のアプリケーション・シナリオで再利用されるので、特定のアプリケーション・モジュールのデータ・モデル内のビュー・オブジェクト・インスタンスに直接依存してはなりません。依存する場合、他のアプリケーション・モジュールで再使用ができないという事態が発生します。

かわりに、ビュー・アクセッサを使用して、ビュー・オブジェクトに対して検証する必要があります。詳細は、「エンティティ・オブジェクトまたはビュー・オブジェクトのビュー・アクセッサの作成方法」を参照してください。

次の例に示すように、検証コードはビュー・アクセッサを使用してビュー・オブジェクトにアクセスし、バインド変数を設定します。

// Sample entity-level validation method
public boolean validateSomethingUsingViewAccessor() {
RowSet rs = getMyValidationVO();
rs.setNamedBindParameter("Name1", value1);
rs.setNamedBindParameter("Name2", value2);
rs.executeQuery();
if ( /* some condition */) {
/*
* code here returns true if the validation succeeds
*/
}
return false;
}

ベスト・プラクティス

プログラミングで行セットにアクセスする際は、必ず行セットのセカンダリ・イテレータの作成を検討してください。これにより、ビュー・オブジェクトをユーザー・インタフェース・プロジェクトのデータ・コントロールとして表示する場合に使用される、デフォルト行セット・イテレータの現在の行セットに混乱が生じないようにします。作業中の行セットに対してcreateRowSetIterator()をコールし、セカンダリとして指定する行セット・イテレータを作成します。プログラミングによる反復を修了すると、コードは行セットに対してcloseRowSetIterator()をコールし、セカンダリ・イテレータをメモリーから削除する必要があります。

サンプル・コードで示すように、検証に使用されるビュー・オブジェクトには通常、1つ以上の名前付きのバインド変数が含まれます。この例では、setNamedBindParameter()メソッドを使用してバインド変数を設定します。ただし、ビュー・アクセッサ定義用ページでGroovy式を使用して、JDeveloperで変数を宣言して設定することもできます。

ビュー・オブジェクトが取得するデータの種類によって、この例の「/* some condition */」式は異なります。たとえば、ビュー・オブジェクトのSQL問合せがCOUNT()などの集約関数を選択した場合、条件では一般的にrs.first()メソッドを使用して最初の行にアクセスし、続いてgetAttribute()メソッドを使用して属性値にアクセスし、そのカウントに対してデータベースが戻す結果を参照します。

問合せから0行または1行のどちらが戻されたかによって、検証が成功または失敗した場合、この条件はrs.first()がnullを戻したかどうかのみを検証します。rs.first()がnullを戻した場合、最初の行は存在しません。つまり、問合せで行は検出されていません。また、ビュー・オブジェクトから取得された1つ以上の問合せ結果に対し、検証の成否を繰り返し確認することもあります。

12.5.2 指定された型のすべてのエンティティに関連する条件の検証方法

データベースに変更がポストされた後、コミットされる前に、変更保留中のリストの各エンティティに対して、beforeCommit()メソッドがコールされます。これは、特定の型のすべてのエンティティ行に対して規則を適用する必要のある、ビュー・オブジェクト・ベースの検証を実行する場合に役立つメソッドです。

注意:

トランザクション・レベルのバリデータを使用して宣言的に検証を実行することもできます(「トランザクション・レベルの検証の設定方法」を参照)。

beforeCommit()ロジックで例外ValidationExceptionがスローされた場合、構成中にjbo.txn.handleafterpostexcプロパティをtrueに設定する必要があります。これにより、フレームワークは現在のコミット・サイクルにおいて、データベースに送信済(かつコミット前)の他のエンティティ・オブジェクトのメモリー内の状態のロールバックを自動的に処理します。

たとえば、次の例に示す、オーバーライドされたbeforeCommit()について考えます。この例では、多相エンティティ・オブジェクトに基づいた3つのビュー・オブジェクト(Persons、StaffおよびSupplier)があり、それらが多相化識別子としてPersonTypeCode属性を持っています。PersonsImpl.javaファイルには、検証メソッドをコールするようにオーバーライドされたbeforeCommit()メソッドがあります。この検証メソッドでは、各ユーザー・タイプを通じてプリンシパル名が一意になっていることを確認するための4番目のビュー・オブジェクト、PersonsValidatorが使用されています。たとえば、Staffビュー・オブジェクトのPrincipalNameとしてSKINGが存在する場合、このユーザー・タイプまたは他のユーザー・タイプに別のSKINGにできません。

// In entity object implementation class
. . .
@Override
public void beforeCommit(TransactionEvent transactionEvent) throws ValidationException {
String principalName = getPrincipalName();
if (!validatePrincipalNameIsUniqueUsingViewAccessor(principalName)) {
throw new ValidationException("Principal Name must be unique across person types");
}
super.beforeCommit(transactionEvent);
}

public boolean validatePrincipalNameIsUniqueUsingViewAccessor(String principalName) {
RowSet rs = getPersonsValidatorVO();
rs.setNamedWhereClauseParam("principalName", principalName);
rs.setRangeSize(-1);
rs.executeQuery();
Row[] validatorRows = rs.getAllRowsInRange();
if (validatorRows.length > 1)
// more than one row has the same princpalName
{
return false;
}
rs.closeRowSetIterator();
return true;
}

12.5.3 ビュー・アクセッサによる行セットのアクセスに関する必知事項

エンティティ・オブジェクトまたはビュー・オブジェクトのビジネス・ロジックが独自のビュー・アクセッサ行セット上で反復処理を行い、そのビュー・アクセッサがモデルによって定義された値のリストでも使用されていない場合、セカンダリ行セット・イテレータを使用する必要はありません。たとえば、ある名前のバインド・パラメータを取るビュー・オブジェクトのAirportValidationVAという名前のビュー・アクセッサがエンティティ・オブジェクトにある場合、GroovyスクリプトまたはJavaを使用して独自のアクセッサ行セットでの反復処理を行うことができます。次の例は、ビュー・アクセッサ行セット上で反復処理を行うGroovyスクリプトを示しています。

AirportValidationVA.setNamedWhereClauseParam("VarTla",newValue)
AirportValidationVA.executeQuery();
return AirportValidationVA.first() != null;

次の例は、ビュー・アクセッサ行セット上で反復処理を行うJavaメソッド・バリデータを示しています。

public boolean validateJob(String job) {
getAirportValidationVA().setNamedWhereClauseParam("VarTla",job);
getAirportValidationVA().executeQuery();
return getAirportValidationVA().first() != null;
}

12.6 アソシエーション・アクセッサを使用した、関連するエンティティ行へのアクセス

関連するエンティティ・オブジェクトから情報にアクセスするには、エンティティ・オブジェクトのカスタムJavaクラスにあるアソシエーション・アクセッサ・メソッドを使用します。アクセッサ・メソッドをコールすると、アソシエーションのカーディナリティに応じて、すべての関連するエンティティ行、またはエンティティ行のセットに簡単にアクセスできます。

12.6.1 関連するエンティティ行へのアクセス方法

アクセッサを使用して関連するエンティティ行にアクセスできます。次の例は、EmpEOエンティティ・オブジェクトのカスタムJavaクラス内のオーバーライドされたpostChanges()メソッドを示す、SummitADFアプリケーション・ワークスペース内のcontrolpostorderモジュールからのコードを示しています。getDeptEO()アソシエーション・アクセッサを使用して、従業員の関連部門を取得しています。

// In EmpEOImpl.java
public void postChanges(TransactionEvent transactionEvent) {
/* If current entity is new or modified */
if (getPostState() == STATUS_NEW ||
getPostState() == STATUS_MODIFIED) {
/* Get the associated dept for the employee */
DeptEOImpl dept = getDeptEO();
/* If there is an associated dept */
if (dept != null) {
/* And if it's post-status is NEW */
if (dept.getPostState() == STATUS_NEW) {
/*
* Post the department first, before posting this
* entity by calling super below
*/
dept.postChanges(transactionEvent);
}
}
}
super.postChanges(transactionEvent);
}

12.6.2 関連するエンティティ行セットへのアクセス方法

アソシエーションのカーディナリティが、複数の行が戻されるようになっている場合、アソシエーション・アクセッサを使用してエンティティ行のセットを戻すことができます。

次の例は、DeptEOエンティティ・オブジェクトのカスタムJavaクラス内のオーバーライドされたpostChanges()メソッドのコードを示しています。setDeptId()アソシエーション・アクセッサを使用して各行のDeptId属性を更新するために、getEmpEO()アソシエーション・アクセッサを使用してEmpEO行のRowSetオブジェクトを取得する方法を示しています。

// In DeptEOImpl.java in the controlpostorder module
// of the SummitADF application workspace
RowSet newEmployeesBeforePost = null;
@Override
public void postChanges(TransactionEvent transactionEvent) {
/* Update references only if Department is a NEW one */
if (getPostState() == STATUS_NEW) {
/*
* Get a rowset of employees related
* to this new department before calling super
*/
newEmployeesBeforePost = (RowSet)getEmpEO();
}
super.postChanges(transactionEvent);
}
@Override
protected void refreshFKInNewContainees() {
if (newEmployeesBeforePost != null) {
Number newDeptId = getId().getSequenceNumber();
/*
* Process the rowset of employees that referenced
* the new department prior to posting, and update their
* Id attribute to reflect the refreshed Id value
* that was assigned by a database sequence during posting.
*/
while (newEmployeesBeforePost.hasNext()){
EmpEOImpl emp = (EmpEOImpl)newEmployeesBeforePost.next();
emp.setDeptId(newDeptId);
}
closeNewProductRowSet();
}
}

12.7 認証されたユーザーに関する情報の参照

アプリケーションで「ADFセキュリティの構成」ウィザードを実行して、ADF認証サーブレットによるユーザーのログインとログアウトのサポートを有効にした場合、oracle.jbo.server.SessionImplオブジェクトでは、認証されたユーザーの名前と、そのユーザーの属するロールを取得するメソッドを使用できます。これは、クライアントがアクセス可能なoracle.jbo.Sessionインタフェースの実装クラスです。

認証されたユーザーに関する情報へのアクセス方法の詳細は、「Java EEセキュリティ・ロールのメンバーシップの判別方法」を参照してください。

Oracle Fusion Webアプリケーションのセキュリティ機能の詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

12.8 元の属性値へのアクセス

エンティティ属性値が現在のトランザクション内で変更されている場合、属性getterメソッドをその属性値に対してコールすると、この保留中の変更値が戻されます。変更前の元の値を取得する場合があります。getPostedAttribute()メソッドを使用すると、エンティティ・オブジェクトのビジネス・ロジックで、エンティティ行が変更される前にデータベースから読み取った、属性の元の値を確認できます。このメソッドは属性indexを引数として取るので、JDeveloperに保管されている正しく生成された属性インデックス列挙を渡します。

12.9 現在のユーザー・セッションに関する情報の格納

現在のユーザー・セッションに関連した情報を、エンティティ・オブジェクトのビジネス・ロジックにより参照可能な方法で格納する必要がある場合、Sessionオブジェクトで提供されるユーザー・データのハッシュ表を使用できます。

12.9.1 現在のユーザー・セッションに関する情報の格納方法

新規ユーザーがアプリケーション・モジュールに初めてアクセスする場合、prepareSession()メソッドがコールされます。次の例に示すように、アプリケーション・モジュールはprepareSession()をオーバーライドし、ビュー・オブジェクト・インスタンスのretrieveUserInfoForAuthenticatedUser()メソッドをコールして、認証されたユーザーに関する情報を取得します。次に、ユーザーの数値IDをユーザー・データ・ハッシュ表に保存するため、setUserIdIntoUserDataHashtable()ヘルパー・メソッドをコールします。

// In the application module
protected void prepareSession(Session session) {
super.prepareSession(session);
/*
* Query the correct row in the VO based on the currently logged-in
* user, using a custom method on the view object component
*/
getLoggedInUser().retrieveUserInfoForAuthenticatedUser();
setUserIdIntoUserDataHashtable();
}

次の例は、ビュー・オブジェクトのretrieveUserInfoForAuthenticatedUser()メソッドのコードを示しています。これは、それ自体のEmailAddressバインド変数を、セッションの認証されたユーザー名に設定し、executeQuery()をコールしてUSERS表から追加のユーザー情報を取得します。

// In the view object's custom Java class
public void retrieveUserInfoForAuthenticatedUser() {
SessionImpl session = (SessionImpl)getDBTransaction().getSession();
setEmailAddress(session.getUserPrincipalName());
executeQuery();
first();
}

ビュー・オブジェクトが取得する、認証されたユーザーの情報の1つには、メソッドの結果として戻されるユーザーの数値ID番号があります。たとえば、ユーザーskingには、数値のUserIdとして300が割り当てられています。

次の例は、前述の例のprepareSession()コードで使用される、setUserIdIntoUserDataHashtable()ヘルパー・メソッドを示しています。このメソッドでは、文字列定数CURRENT_USER_IDで指定されるキーを使用して、この数値ユーザーIDをユーザー・データ・ハッシュ表に格納します。

// In the application module
private void setUserIdIntoUserDataHashtable() {
Integer userid = getUserIdForLoggedInUser();
Hashtable userdata = getDBTransaction().getSession().getUserData();
userdata.put(CURRENT_USER_ID, userid);
}

この例の対応するエンティティ・オブジェクトでは、次の例のようなヘルパー・メソッドを使用して、この数値ユーザーIDを参照するcreate()メソッドをオーバーライドできます。オーバーライドされたメソッドでは、CreatedBy属性を現在認証されているユーザーの数値ユーザーIDの値にプログラム的に設定します。

protected Number getCurrentUserId() {
Hashtable userdata = getDBTransaction().getSession().getUserData();
Integer userId = (Integer)userdata.get(CURRENT_USER_ID);
return userdata != null ? Utils.intToNumber(userId):null;
}

// In the application module
protected void prepareSession(Session session) {
super.prepareSession(session);
/*
* Query the correct row in the VO based on the currently logged-in
* user, using a custom method on the view object component
*/
getLoggedInUser().retrieveUserInfoForAuthenticatedUser();
setUserIdIntoUserDataHashtable();
}

12.9.2 現在のユーザー・セッション情報へのアクセスにGroovyを使用する方法

フレームワークでGroovyスクリプトを使用できる、オブジェクトにアクセス可能なadfという名前のトップレベルのオブジェクトが用意されています。adf.userSessionオブジェクトは、ADFビジネス・コンポーネント・ユーザー・セッションへの参照を返します。これを使用してセッションに含まれているuserDataハッシュ・マップ内の値を参照できます。

次の例は、MyKeyという名前のuserDataハッシュ・マップ・キーの参照に使用するGroovyスクリプトを示しています。

adf.userSession.userData.MyKey

12.10 現在の日時へのアクセス

エンティティ・オブジェクトのビジネス・ロジックにおいては、現在の日時の参照が役立つ場合があります。次のGroovyスクリプト式を使用すると、現在の日付または現在の日付と時間を参照できます。

- adf.currentDate - 現在の日付(時間を切捨て)を戻します。

- adf.currentDateTime - 現在の日付と時間を戻します。

エンティティ・オブジェクトのビジネス・ロジックでのGroovyスクリプトの使用方法の詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。

12.11 正常に完了したコミットに関する通知の送信

変更保留中のリストに含まれていた各エンティティ行に対してafterCommit()メソッドがコールされ、データベースに正しく格納されます。このメソッドを使用して、コミットに関する通知を送信できます。

コミット成功時に通知を送信するもっとよい方法は、ビジネス・イベントを宣言する方法です。ビジネス・イベントの作成方法の詳細は、「ビジネス・イベントの作成」を参照してください。

12.12 エンティティ行削除の条件付き禁止

remove()メソッドは、エンティティ行削除の前に、その行に対して起動します。remove()メソッドでは、JboExceptionをスローし、該当する条件を満たさない場合は行の削除を回避するよう設定できます。

たとえばremove()メソッド内で、エンティティ・オブジェクトの状態を判断するテストを追加し、それが新規レコードの場合にのみ削除可能にすることができます。次の例ではこの方法を説明しています。

注意:

このエンティティ・オブジェクトでは、既存の構成される側の子行がある場合、マスター・エンティティ行の削除が宣言的に回避されます。このオプションは、アソシエーションの概要エディタの「関連」ページで設定します。

// In entity object custom Java class
private boolean isDeleteAllowed() {
byte s = this.getEntityState();
return s==STATUS_NEW;
}

/**
* Add entity remove logic in this method.
*/
public void remove() {
if (isDeleteAllowed())
super.remove();
else
throw new JboException("Delete not allowed in this view");
}

12.13 属性に対する条件付きの更新可能性の判断

エンティティ・オブジェクト・クラス内のisAttributeUpdateable()メソッドをオーバーライドすると、特定の属性が更新可能かどうかを、実行時に適切な条件に従ってプログラム的に判断できます。

次の例は、現在の認証されたユーザーがスタッフ・メンバーである場合にのみPersonTypeCode属性を更新可能にするため、エンティティ・オブジェクトによりisAttributeUpdateable()がどのようにオーバーライドされるかを示しています。エンティティ・オブジェクトでは、このメソッドを実行する際、更新可能性の確認対象となる整数属性索引を渡します。

特定の属性に対する条件付きの更新可能性ロジックは、属性索引に基づいて、if文またはswitch文内に実装できます。ここでは、PERSONTYPECODEがエンティティ・オブジェクトのカスタムJavaクラスに保持されている整数属性の索引列挙を参照します。

注意:

エンティティ・ベースのビュー・オブジェクトは、エンティティ・オブジェクト内でカプセル化された他の要素と同様に、この条件付きの更新可能性も継承します。この種の条件付き更新可能性ロジックを、一時ビュー・オブジェクト属性に固有の方法で実装する必要がある場合、または、ビュー・オブジェクト内の複数のエンティティ・オブジェクトのデータを含む一部の条件を適用する場合、ビュー・オブジェクトのビュー行クラス内の同じメソッドをオーバーライドすると、目的の結果が得られます。

// In the entity object custom Java class
public boolean isAttributeUpdateable(int index) {
if (index == PERSONTYPECODE) {
if (!currentUserIsStaffMember()) {
return super.isAttributeUpdateable(index);
}
return CUSTOMER_TYPE.equals(getPersonTypeCode()) ? false : true;
}
return super.isAttributeUpdateable(index);
}

12.14 カスタム検証規則の実装

ADFビジネス・コンポーネントには、開発者が使用できる組込みの宣言的検証規則の基本セットが付属しています。ただし、エンティティ・オブジェクト用のバリデータ・アーキテクチャの強力な機能は、独自のカスタム検証規則を作成できることです。同じ種類の検証コードを繰り返し作成している場合は、カスタム検証規則クラスを作成し、このような共通の検証パターンをパラメータ化された方法で取得できます。

定義したカスタム検証規則クラスは、JDeveloperに登録し、組込み規則と同じように簡単に使用できます。実際、カスタム検証規則をカスタムUIパネルにバンドルすることもできます。JDeveloperはこれを利用して、検証規則で必要とするパラメータを開発者が簡単に使用および構成できるようにします。

12.14.1 カスタム検証規則の作成方法

エンティティ・オブジェクト用のカスタム検証規則を作成するには、oracle.jbo.rulesパッケージのJboValidatorInterfaceを実装するJavaクラスが必要です。「新規ギャラリ」からスケルトン・クラスを作成できます。

始める前に:

カスタム検証規則に関する知識があると役立つ場合があります。詳細は、「カスタム検証規則の実装」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「プログラム的なビジネス・ルールの追加機能」を参照してください。

カスタム・バリデータを作成するには:

1. 「アプリケーション」ウィンドウで、バリデータを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「ビジネス層」を開き、「ADFビジネス・コンポーネント」を選択してから、「検証ルール」を選択し、「OK」をクリックします。

3. 「検証ルール・クラスの作成」ダイアログで、ルールの名前とパッケージを入力します。

4. 表示名と説明を入力して、「OK」をクリックします。

次の例に示すように、JBOValidatorInterfaceには、1つのメインvalidate()メソッドと、Descriptionプロパティ用のgetterおよびsetterメソッドが含まれます。

package oracle.jbo.rules;
public interface JboValidatorInterface {
void validate(JboValidatorContext valCtx) { }
java.lang.String getDescription() { }
void setDescription(String description) { }
}

検証規則の動作がパラメータ化されて柔軟性が増してから、検証クラスの各パラメータにBeanプロパティを追加します。たとえば、次の例のコードによりDateMustComeAfterRuleという名前のカスタム検証ルールが実装され、これによりある日付属性が別の日付属性より後でなければならないことを検証します。規則を使用する開発者が検証対象の2つの日付として使用する日付属性の名前を構成できるように、このクラスではinitialDateAttrNameとlaterDateAttrNameという2つのプロパティが定義されています。

次の例は、カスタム検証ルールを実装するコードを示しています。これは、AbstractValidatorを拡張し、エンティティ・オブジェクトのカスタム・メッセージ・バンドルの使用を継承しています。開発者がエンティティ・オブジェクトの規則を使用すると、JDeveloperは検証エラー・メッセージをここに保存します。

検証規則のvalidate()メソッドは、実行時に規則クラスが機能を実行する必要がある場合に常に呼び出されます。このコードが実行する基本的な手順は次のとおりです。

1. エンティティ・レベルでバリデータが正しくアタッチされていることを確認します。

2. 検証するエンティティ行を取得します。

3. 先の日と後の日の属性の値を取得します。

4. 先の日が後の日より前であることを検証します。

5. 検証が失敗した場合は例外をスローします。

カスタム検証規則を簡単に再利用できるように、通常は、規則を利用するアプリケーションでの参照用として規則をJARファイルにパッケージします。

// package and imports omitted
public class DateMustComeAfterRule extends AbstractValidator
implements JboValidatorInterface {
/**
* This method is invoked by the framework when the validator should do its job
*/
public void validate(JboValidatorContext valCtx) {
// 1. If validator is correctly attached at the entity level...
if (validatorAttachedAtEntityLevel(valCtx)) {
// 2. Get the entity row being validated
EntityImpl eo = (EntityImpl)valCtx.getSource();
// 3. Get the values of the initial and later date attributes
Date initialDate = (Date) eo.getAttribute(getInitialDateAttrName());
Date laterDate = (Date) eo.getAttribute(getLaterDateAttrName());
// 4. Validate that initial date is before later date
if (!validateValue(initialDate,laterDate)) {
// 5. Throw the validation exception
RulesBeanUtils.raiseException(getErrorMessageClass(),
getErrorMsgId(),
valCtx.getSource(),
valCtx.getSourceType(),
valCtx.getSourceFullName(),
valCtx.getAttributeDef(),
valCtx.getNewValue(),
null, null);
}
}
else {
throw new RuntimeException("Rule must be at entity level");
}
}
/**
* Validate that the initialDate comes before the laterDate.
*/
private boolean validateValue(Date initialDate, Date laterDate) {
return (initialDate == null) || (laterDate == null) ||
(initialDate.compareTo(laterDate) < 0);
}
/**
* Return true if validator is attached to entity object
* level at runtime.
*/
private boolean validatorAttachedAtEntityLevel(JboValidatorContext ctx) {
return ctx.getOldValue() instanceof EntityImpl;
}
// NOTE: Getter and Setter Methods omitted
private String description;
private String initialDateAttrName;
private String laterDateAttrName;
}

12.14.2 JDeveloperでのカスタム規則の登録および使用方法

カスタム検証規則は作成後、JDeveloper IDEのプロジェクトまたはアプリケーションレベルに追加できるため、他の開発者がその規則を宣言的に使用できます。

12.14.2.1 プロジェクト・レベルでのカスタム・バリデータの登録

カスタム検証規則をプロジェクト・レベルで登録した場合は、プロジェクト内でその検証規則を使用できます。

始める前に:

カスタム検証規則に関する知識があると役立つ場合があります。詳細は、「カスタム検証規則の実装」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「プログラム的なビジネス・ルールの追加機能」を参照してください。

カスタム検証ルールを登録するには、「カスタム検証規則の作成方法」で説明しているように、先にその検証ルールを作成しておく必要があります。

エンティティ・オブジェクトを含むプロジェクトでカスタム検証規則を登録するには:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトを含むプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「ADFビジネス・コンポーネント」を開き、「登録済ルール」を選択します。

3. 「登録済の規則」ページで、「追加」をクリックします。

4. 「検証ルールの登録」ダイアログで、作成した検証ルールを参照して検索し、「OK」をクリックします。

12.14.2.2 IDEレベルでのカスタム・バリデータの登録

カスタム検証規則をJDeveloperのIDEレベルで登録すると、現在のプロジェクトのみでなく、他のプロジェクトでもその検証規則を使用できます。

始める前に:

カスタム検証規則に関する知識があると役立つ場合があります。詳細は、「カスタム検証規則の実装」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「プログラム的なビジネス・ルールの追加機能」を参照してください。

カスタム検証ルールを登録するには、「カスタム検証規則の作成方法」で説明しているように、先にその検証ルールを作成しておく必要があります。

IDEレベルのカスタム・バリデータを登録するには:

1. メイン・メニューから、「ツール」→「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を開き、「ルールの登録」を選択します。

3. 「ルールの登録」ページから、1つ以上の検証規則を追加できます。

検証ルールを追加するときは、検証ルール・クラスの完全修飾名を指定し、JDeveloperの使用可能なバリデータのリストで表示される検証ルールの名前を設定します。

13 アプリケーション・モジュールによるビジネス・サービスの実装

この章では、JDBCデータソースから導出されたOracle ADFアプリケーションのデータ・モデルをカプセル化するADFアプリケーション・モジュールの作成方法について説明します。この章では、ビジネス・サービス・メソッドをそのデータ・モデルと結合して完全なビジネス・サービスを実装する方法についても説明します。

この章の内容は次のとおりです。

- アプリケーション・モジュールについて

- アプリケーション・モジュールの作成と変更

- アプリケーション・モジュールのデータベース接続の構成

- ネストされたアプリケーション・モジュールの定義

- ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成

- 複数ページの作業ユニットのサポート

- サービス・メソッドによるアプリケーション・モジュールのカスタマイズ

- アプリケーション・モジュール・メッセージ文字列のカスタマイズ

- UIクライアントへのカスタム・サービス・メソッドの公開

- アプリケーション・モジュール・クライアント・インタフェースのプログラム的操作

- 組込みフレームワーク・メソッドの上書き

- アプリケーション・モジュールからのWebサービスのコール

13.1 アプリケーション・モジュールについて

アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールは、ADFビジネス・コンポーネントで、エンド・ユーザー・タスクに関連する論理作業ユニットのビジネス・サービス・メソッドとデータ・モデルをカプセル化したものです。

アプリケーション開発の早期段階では、アーキテクトと設計者は通常、UMLユースケース手法およびADFタスク・フローを使用して、アプリケーションの計画済エンド・ユーザー機能の高レベルな概要を作成します。この設計段階中に識別されるエンド・ユーザーの高レベルな各ユースケースは、一般に次のものに応じて異なります。

- 対象となるドメイン・ビジネス・オブジェクト。ユースケースに関連するコア・ビジネス・データについての問題に解答します。

- 必要なビジネス・データのユーザー指向ビュー。ユースケースをサポートするために必要な列サブセット、フィルタ処理された行セット、ソート方法、グループ化方法などについての問題に解答します。

各ユースケースに関連するドメイン・オブジェクトを識別すると、ビジネス・ドメイン・レイヤー内の必要なエンティティ・オブジェクトを識別する際に便利です。必要なビジネス・データのユーザー指向ビューは、ビュー・オブジェクトとして取得された適切なSQL問合せを定義して、データをエンド・ユーザーの期待どおりに取得する際に便利です。これには、パフォーマンスを最大化するために、ユースケースのサポートに必要な最低限の詳細の取得が含まれます。これまでの説明で、ビュー・オブジェクト問合せおよびビュー基準を利用してデータを形成する方法のみならず、ビュー・リンクを使用してデータ・モデルにマスター/ディテール階層を設定し、期待どおりのエンド・ユーザー体験をユーザーに提供してユースケースを実現する方法も、すでに学習しました。

アプリケーション・モジュールは、当該のユースケースに必要な再使用可能なビュー・オブジェクトのインスタンスを含む作業ユニット・コンテナです。これらのビュー・オブジェクト・インスタンスは、エンド・ユーザー・ユースケースにより表示または変更する情報が決定される再使用可能なビジネス・ドメイン・レイヤー内の基礎となるエンティティ・オブジェクトに、メタデータを通じて関連付けられています。

13.1.1 アプリケーション・モジュールのユースケースと例

この章では、図13-1に示す次の概念について説明します。

- ビュー・オブジェクトのインスタンスをアプリケーション・モジュールで公開して、そのデータ・モデルを定義します。

- サービス・メソッドを記述して、タスク・レベルのビジネス・ロジックをカプセル化します。

- UIクライアントがコールするメソッドを選択し、クライアント・インタフェースで公開します。

- アプリケーション統合シナリオでプログラム的に使用するメソッドを選択し、サービス・インタフェースで公開します。
12cから、Oracle JDeveloperではADFビジネス・コンポーネント・モデル・プロジェクトにおけるEJBセッションBean対応のアプリケーション・モジュールのサポートが非推奨となった点に注意してください。今後、JDeveloperではEJBセッションBean対応のアプリケーション・モジュールを作成または実行できません。既存のEJBセッションBean対応のアプリケーション・モジュールのかわりとして、「アプリケーション・モジュールによるSOAP Webサービスの作成」に説明されているとおり、アプリケーション・モジュール・サービスをWebサービス対応のアプリケーション・モジュールに移行できます。このアプローチは、外部サービスを使用してサービス・メソッドを公開するためのベスト・プラクティスと一貫しています。

- 複数のWebページまたはビューにまたがる可能性のある論理トランザクション中に、プールのアプリケーション・モジュール・インスタンスを使用します。

- アプリケーション・モジュールでは、データベース接続の取得と、エンティティ・オブジェクトに行われた変更の保存またはロールバックの調整を行うTransactionオブジェクトを操作します。

- 関連するSessionオブジェクトにより、現在のアプリケーション・ユーザーに関するランタイム情報が提供されます。

図13-1 作業ユニットをカプセル化するビジネス・サービス・コンポーネントとして機能するアプリケーション・モジュール

13.1.2 アプリケーション・モジュールの追加機能

アプリケーション・モジュールを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- 共有アプリケーション・モジュールの作成の詳細は、「アプリケーション・モジュール・ビュー・インスタンスの共有」を参照してください。

- 外部サービスを使用したADFビジネス・コンポーネント・サービス・メソッドの公開の詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。

- 「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュールの公開方法の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

- 実行時のパフォーマンスを向上させるためのアプリケーション・モジュール・インスタンス構成の詳細は、「Fusion Webアプリケーションでの状態管理の使用」および「アプリケーション・モジュール・プールのチューニング」を参照してください。

- 本番環境のパフォーマンスとスケーラビリティを最大化する方法の詳細は、『パフォーマンスのチューニング・ガイド』の「Oracle Application Development Framework (ADF)のチューニング」を参照してください。

- カスタム・アプリケーション・モジュール・クラスでよく記述、使用またはオーバーライドするコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

13.2 アプリケーション・モジュールの作成と変更

大規模なアプリケーションでは、通常、粒度の粗い各エンド・ユーザー・タスクをサポートするアプリケーション・モジュールを1つずつ作成します。小規模なアプリケーションでは、アプリケーション・モジュールを1つ作成すれば、アプリケーションの全機能のニーズを十分に処理できると判断する場合もあります。「ネストされたアプリケーション・モジュールの定義」には、これに関する追加の説明があります。

13.2.1 アプリケーション・モジュールの作成方法

作成するビュー・オブジェクトは、1つ以上のアプリケーション・モジュールで使用できる再利用可能コンポーネントです。各ビュー・オブジェクトは、そのアプリケーション・モジュールのトランザクションのコンテキストで、カプセル化した問合せを実行します。アプリケーション・モジュールで使用される一連のビュー・オブジェクト・インスタンスは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。

既存のADFビジネス・コンポーネント・プロジェクトにアプリケーション・モジュールを追加するには、「新規ギャラリ」から使用できる「アプリケーション・モジュールの作成」ウィザードを使用します。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

アプリケーション・モジュールを手動で作成するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを作成するプロジェクトを右クリックし、「新規」および「アプリケーション・モジュール」を選択します。

2. 「アプリケーション・モジュールの作成」ウィザードの「名前」ページで、パッケージ名およびアプリケーション・モジュール名を指定します。「次へ」をクリックします。

注意:

Fusion Webアプリケーションでは、アプリケーション・モジュールの名前に予約語のdata、bindings、securityおよびadfContextを使用しないでください。また、名前の先頭に_(アンダースコア)を使用することも避けてください。詳細は、「既存のアプリケーション・モジュールの編集方法」を参照してください。

3. 「データ・モデル」ページで、以前に定義したビュー・オブジェクトのインスタンスを指定し、これらのビュー・オブジェクト・インスタンスの名前を、「データ・コントロール」パネルでクライアントに対して表示される名前とまったく同じ名前に編集します。次に、「次へ」をクリックします。

4. 「Java」ページではオプションでJavaファイルを作成し、アプリケーション・モジュールの動作をプログラミングによってカスタマイズすることができます。あるいは、アプリケーション・モジュールのクライアント・インタフェースにメソッドをエクスポートして、クライアントが呼び出せるようにすることができます。XML専用のアプリケーション・モジュール・コンポーネントを生成するには、このフィールドを選択しないまま、「終了」をクリックします。

最初に、アプリケーション・モジュールのXML定義コンポーネントのみを生成することもできます。ウィザードを完了した後に、プログラムによるアクセスが必要になる場合は、概要エディタを使用してアプリケーション・モジュール・クラス・ファイルを生成できます。アプリケーション・モジュールのプログラム的な使用の詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。

手順ごとの詳細は、「既存のアプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。

13.2.2 アプリケーション・モジュール作成時の処理

アプリケーション・モジュールを作成すると、JDeveloperでは、その宣言的設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリに保存されます。たとえば、summit.modelパッケージのSummit ADFサンプル・アプリケーションのBackOfficeAppModuleという名前のアプリケーション・モジュールでは、プロジェクトのソース・パスに./summit/model/BackOfficeAppModule.xmlというXMLファイルがあります。このXMLファイルには、ビュー・オブジェクト・インスタンスをアプリケーション・モジュールのデータ・モデルで再作成するために実行時に必要な情報が含まれています。

この内容を確認するには、「アプリケーション」ウィンドウでアプリケーション・モジュールのノードをダブルクリックして概要エディタを開き、アプリケーション・モジュールのXMLファイルを確認します。エディタ・ウィンドウで「ソース」タブをクリックすると、XMLファイルが表示され、その内容を確認できます。「構造」ウィンドウには、XMLファイルの構造が表示されます。

ビジネス・コンポーネントを作成すると、JDeveloperがアプリケーション・モジュールのすべての機能を含むデータ・コントロールを自動的に作成します。データ・コントロールはADFモデル抽象レイヤーで、属性、メソッド、関連する型の情報を含む補足メタデータを提供して、アプリケーション・モジュールの操作とデータ・コレクション(ビュー・オブジェクト・インスタンスの行セット)を記述します。開発者は、JDeveloperの「データ・コントロール」パネルに表示されたデータ・コントロールの表現を使用して、アプリケーション・モジュールに自動的にバインドされるUIコンポーネントを作成できます。実行時にADFモデル・レイヤーによって、適切なXMLファイルからデータ・コントロールおよびバインディングを記述したメタデータが読み取られ、ユーザー・インタフェースとビジネス・サービスの双方向の結合が実装されます。

たとえば、BackOfficeAppModuleアプリケーション・モジュールによりSummitADFアプリケーション・ワークスペースのビジネス・サービス・レイヤーが実装されます。このデータ・モデルには、複数のマスター/ディテール階層など、多数のビュー・オブジェクト・インスタンスが含まれています。コアSummit ADFサンプル・アプリケーションのビュー・レイヤーはJSFページで構成され、このページのUIコンポーネントは、BackOfficeAppModuleのデータ・モデル内のビュー・オブジェクト・インスタンスのデータと、そのクライアント・インタフェース上の組込み操作およびサービス・メソッドにバインドされています。「データ・コントロール」パネルでのUI開発者向けのアプリケーション・モジュールの公開方法の詳細は、「ADFデータ・コントロールを使用したアプリケーション・モジュールの公開」を参照してください。

13.2.3 アプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加方法

「アプリケーション・モジュールの作成」ウィザードでアプリケーション・モジュールを作成しながらビュー・オブジェクト・インスタンスをアプリケーション・モジュールに追加することも、作成済のアプリケーション・モジュールに後で追加することもできます。

アプリケーション・モジュールの作成ウィザードの使用方法の詳細は、「アプリケーション・モジュールの作成方法」を参照してください。

13.2.3.1 既存のアプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加

作成済のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加できます。ビュー・オブジェクト・インスタンスを既存のアプリケーション・モジュールへ追加したり、オプションでビュー・オブジェクト・インスタンスをカスタマイズするには、アプリケーション・モジュールの概要エディタにある「データ・モデル」ページを使用します。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

既存のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを追加するには:

1. 「アプリケーション」ウィンドウで、新しいビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。

3. 「データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「使用可能なビュー・オブジェクト」リストで、追加するビュー・オブジェクトを選択します。

リストの下の「新規ビュー・インスタンス」フィールドに、データ・モデルに追加するビュー・オブジェクトの次のインスタンスを識別する際に使用される名前が示されます。

4. 目的のビュー・オブジェクトを選択し、「データ・モデル」リストに移動します。

たとえば、図13-2に、データ・モデルに移動されてCountryVO1と表示されているSummitADFワークスペースのCountryVOビュー・オブジェクトを示します。

図13-2 データ・モデルへのビュー・インスタンスの追加

5. 新規に作成したビュー・インスタンスの名前を変更するには、「新規ビュー・インスタンス」フィールドに別の名前を入力します。

たとえば、図13-3に示すように、ビュー・インスタンス名CountryVO1をCountriesに変更できます。

図13-3 名前変更されたビュー・インスタンスを表示している概要エディタ

13.2.3.2 既存のアプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加

アプリケーション・モジュールの概要エディタに表示されるデータ・モデルを使用すると、プロジェクトで定義されている既存のビュー・リンクに基づいて、ビュー・インスタンスの階層を作成できます。複数のマスター/ディテールの階層レベルで構成されるビュー・リンクを定義している場合は、アプリケーションでサポートされているレベル数までマスター/ディテールのビュー・インスタンスを作成できます。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「マスター/ディテール階層における複数表の使用」の説明に従って、ビュー・オブジェクト間の階層関係を作成します。

マスター/ディテールのビュー・オブジェクト・インスタンスをデータ・モデルに追加するには:

1. 「アプリケーション」ウィンドウで、新しいマスター/ディテール・ビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。

3. 「データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを開き、「使用可能なビュー・オブジェクト」リストで、積極的に調整を行うマスターにするビュー・オブジェクトのインスタンスを選択します。

リスト内のマスター・ビュー・オブジェクトには、このビュー・オブジェクトにビュー・リンクがあることを示すプラス記号が表示されます。ビュー・リンクは、マスター/ディテール階層の定義に必要です。

たとえば、Summit ADFサンプル・アプリケーションのSummitADFワークスペースには、ビュー・リンクOrdCustomerIdFkLinkによって関連付けられたマスター・ビュー・オブジェクトCustomerVOとディテール・ビュー・オブジェクトOrdVOが含まれます。「使用可能なビュー・オブジェクト」リストのマスター/ディテール階層を表示するには、図13-4に示すようにCountryVOを展開します。

図13-4 選択したマスター・ビュー・オブジェクト

4. 選択したマスター・ビュー・オブジェクトを「データ・モデル」リストに移動します。

たとえば、図13-5に示すように、マスター・ビュー・オブジェクトCustomerVOをデータ・モデルに移動し、そこでビュー・インスタンス名がCustomerVO1になる場合があります。

図13-5 作成したマスター・ビュー・インスタンス

5. 新規に作成したマスター・ビュー・インスタンスの名前を変更するには、「ビュー・インスタンス」フィールドに別の名前を入力します。

たとえば、図13-6に示すように、ビュー・インスタンス名CustomerVO1をCustomersに変更できます。

図13-6 名前変更されたビュー・インスタンスを表示している概要エディタ

6. 「データ・モデル」リストで、新規作成したマスター・ビュー・インスタンスを選択してハイライトしておきます。これは、追加するディテール・ビュー・インスタンスのターゲットになります。次に、「使用可能なビュー・オブジェクト」リストで、マスター・ビュー・オブジェクトの下のディテール・ビュー・オブジェクトを特定して選択します。

たとえば、図13-7は、マスターCustomerVOの下にある、OrdVO via OrdCustomerIdFkLinkという名前のディテールOrdVOを示しています。この名前はビュー・リンクOrdCustomerIdFkLinkを表し、CustomerVOとOrdVO間のマスター/ディテール階層を定義します。データ・モデルに追加すると、OrdVOにはビュー・インスタンス名OrdersForCustomersが追加されることにも注意してください。

図13-7 選択したディテール・ビュー・オブジェクト

7. 前に追加したマスター・インスタンスにディテール・インスタンスを追加するには、「データ・モデル」リストで選択したマスター・ビュー・インスタンスの下にディテール・ビュー・オブジェクトを移動し、ビュー・インスタンスの名前を変更します。

たとえば、図13-8に示すように、OrdVO via OrdCustomerIdFkLinkを選択したマスター・ビュー・インスタンスCustomersの下のデータ・モデルに移動します。

図13-8 作成されて名前変更されたディテール・ビュー・インスタンス

8. 別の階層レベルを追加するには、手順3から6を繰り返しますが、この場合は、新しく追加したディテール・インスタンスを「データ・モデル」リストで選択してから、新しいディテール・インスタンスを移動します。このディテール・インスタンスは、前に追加したディテール・インスタンスとマスター/ディテール関係を持ちます。

たとえば、SummitADFワークスペースには、OrdVOビュー・オブジェクト(マスター・ビュー・オブジェクトCustomerVOのディテール)のディテールであるビュー・オブジェクトItemVO via ItemOrdIdFkLinkが含まれます。

マスター/ディテール/ディテール・データ・モデル階層を作成するには、図13-9に示すように、ディテール・ビュー・オブジェクトItemVO via ItemOrdIdFkLinkをビュー・インスタンスOrdersForCustomers (旧名はOrdVO1)の下のデータ・モデルに移動し、新しいディテール・ビュー・インスタンスItemsForOrderの名前を変更します。「データ・モデル」リストでは、ビュー・インスタンスCustomers (旧名はCustomerVO1)は、ItemsForOrder (旧名はItemVO1)のマスターであるOrdersForCustomer (旧名はOrdVO1)のマスターです。

図13-9 作成したマスター/ディテール/ディテール階層

13.2.3.3 アプリケーション・モジュールに追加するビュー・オブジェクト・インスタンスのカスタマイズ

アプリケーション・モジュールの概要エディタにある、「データ・モデル・コンポーネント」ページでビュー・オブジェクト・インスタンスのカスタマイズを任意に行えます。たとえば、次のようにマスター/ディテール・ビュー・オブジェクトの関係をコントロールする属性を設定できます。

たとえば、Summit ADFサンプル・アプリケーションのSummitADFワークスペースでは、ビュー・インスタンスSalesPeopleがBackOfficeAppModuleアプリケーション・モジュールに対して定義されており、販売スタッフを肩書きでフィルタするビュー基準FilterByTitleIdVCがこのビュー・インスタンスに対して定義されています。図13-10は、「ビュー・インスタンスの編集」ダイアログでFilterByTitleIdVCを選択し、SalesPeopleビュー・インスタンスを開いた状態を示しています。バインド変数TitleIdBindはデフォルト値の2を定義し、これによりSalesPeopleビュー・インスタンスの制御属性としてTitleId属性の値が設定されます。ビュー基準フィルタによって設定した制御属性により、一致するIDのビュー行のみを取得できます。

図13-10 ビュー基準フィルタを使用してカスタマイズしたビュー・オブジェクト・インスタンス

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「アプリケーション・モジュールの作成と変更」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

既存のアプリケーション・モジュールへ追加するビュー・オブジェクト・インスタンスをカスタマイズするには:

1. 「アプリケーション」ウィンドウで、既存のビュー・インスタンスをカスタマイズするアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。

3. 「データ・モデル・コンポーネント」ページの「ビュー・オブジェクト・インスタンス」セクションを展開し、「データ・モデル」リストで、カスタマイズするビュー・オブジェクト・インスタンスを選択し、「編集」ボタンをクリックします。

4. 「ビュー・インスタンスの編集」ダイアログで、次のいずれかの手順を実行し、「OK」をクリックします。

- 「ビュー基準」グループ・ボックスで、ビュー・オブジェクト・インスタンスに適用する1つ以上のビュー基準を選択します。選択されたビュー基準は、WHERE句としてインスタンス問合せに追加されます。ビュー基準の定義の詳細は、「名前付きビュー基準の処理」を参照してください。

- 「ビュー基準」グループ・ボックスで、「選択済」リストに追加するビュー基準ごとに、ビュー・インスタンスの必須フィルタとして1つ以上のビュー基準を選択します。現在選択されているビュー基準を常にビュー・インスタンスに適用する必要がある場合は、そのビュー基準の「必須」チェック・ボックスを選択します。通常、複数のビュー基準が1つのビュー・インスタンスに適用される場合、1つがデフォルトのビュー基準となり常に適用されます。必須ビュー基準は、アプリケーションがプログラムによってビュー基準を適用する(たとえばapplyViewCriteria()を使用)場合でも、引き続きビュー基準リストに適用されます。

- 「バインド・パラメータ値」グループ・ボックスで、定義済のビュー基準を適用する際にインスタンスで使用する値を入力します。バインド変数の定義の詳細は、「バインド変数の使用」を参照してください。

13.2.4 アプリケーション・モジュールへのビュー・オブジェクト・インスタンスの追加時の処理

ビュー・オブジェクト・コンポーネントのインスタンスを追加して、アプリケーション・モジュールのデータ・モデルを定義します。図13-11に、Summitサンプル・アプリケーションのSummitADFワークスペースに表示されるBackOfficeAppModuleアプリケーション・モジュールのJDeveloperビジネス・コンポーネント・ダイアグラムを示します。

図13-11 ビュー・オブジェクト・コンポーネントの2つのインスタンスを含むアプリケーション・モジュール

例に示したアプリケーション・モジュールにはCustomerVOビュー・オブジェクト・コンポーネントの2つのインスタンスが含まれています。 メンバー名のCustomerと、それを区別するAnotherCustomerです。実行時には両方のインスタンスが同一のCustomerVOビュー・オブジェクト・コンポーネント定義を共有します。これにより、同じ属性構造とビュー・オブジェクト動作を持つようになります。ただし、それぞれを個別に使用して異なるユーザーのデータを取得できます。たとえばWHERE句やバインド変数の追加フィルタなど、一部の実行プロパティは2つのインスタンスで異なっている場合があります。

次の例は、BackOfficeAppModuleアプリケーション・モジュールにより、アプリケーション・モジュールのメンバー・ビュー・オブジェクト・インスタンスがそのXMLドキュメント・ファイルで定義される様子を示しています。

<AppModule
Name="BackOfficeAppModule"
...>
<ViewUsage
Name="Customer"
ViewObjectName="oracle.summit.model.appmodule.CustomerVO"/>
<ViewUsage
Name="AnotherCustomer"
ViewObjectName="oracle.summit.model.appmodule.CustomerVO"/>
</AppModule>

13.2.5 既存のアプリケーション・モジュールの編集方法

新しいアプリケーション・モジュールを作成した後、「アプリケーション・モジュールの編集」ダイアログを使用してその設定を編集できます。エディタを起動するには、「アプリケーション」ウィンドウでアプリケーション・モジュール・ノードを右クリックして「開く」を選択するか、アプリケーション・モジュールをダブルクリックします。エディタの様々なページを開き、データ・モデル、ネストされたアプリケーション・モジュールの参照、Java生成の設定、クライアント・インタフェース・メソッド、実行時インスタンス化動作、およびカスタム・プロパティを調整できます。

アプリケーション・モジュール名を編集する場合、Oracle Application Development Framework (Oracle ADF)が定義している予約語以外の名前を選択してください。特に、アプリケーション・モジュールの名前に基づいてJDeveloperによって自動的に割り当てられるデータ・コントロールの使用名では、予約語は無効になります。Fusion Webアプリケーションでは、これらの予約語はdata、bindings、securityおよびadfContextで構成されます。たとえば、アプリケーション・モジュールの名前にはdataを使用しないでください。予約語と競合するIDのデータ・コントロールの使用名が作成されると、実行時にアプリケーションからデータ・コントロール・オブジェクトにアクセスできなくなる場合があり、ランタイムClassCastExceptionのエラーが発生することがあります。

予約語はアンダースコア(_)文字で始まる場合が多いため、名前が競合しないように、アプリケーション・モジュール名の先頭にはアンダースコアを使用しないでください。

アプリケーション・モジュール名に予約語が含まれる場合や、予約語の大文字と小文字を変更した名前が使用されている場合は、競合は発生しません。たとえば、Product_Data、Product_dataまたはDataは、全体の名前が予約語のdataとは一致しないため、すべて有効なアプリケーション・モジュール名です。

13.2.6 ページ作成を開始する前のデータ・コントロール名の変更方法

デフォルトでは、アプリケーション・モジュールは、「データ・コントロール」パネルにAppModuleNameDataControlという名前のアプリケーション・モジュール・データ・コントロールとして表示されます。ユーザー・インタフェース・デザイナでは、「データ・コントロール」パネルを使用して、アプリケーション・モジュールからアプリケーションのWebページにデータをバインドします。たとえば、アプリケーション・モジュールの名前がSummitAppModuleの場合、「データ・コントロール」パネルには、SummitAppModuleDataControlという名前のデータ・コントロールが表示されます。デフォルトのデータ・コントロール名を変更して、名前を短くしたり適切な名前を指定することもできます。

ユーザー・インタフェース・デザイナでデータ・コントロールを操作すると、アプリケーション・モジュールのデータ・コントロール名は、ユーザー・インタフェース・プロジェクトのDataBindings.cpxファイルおよび各データ・バインディング・ページ定義のXMLファイルに表示されます。また、アプリケーション・モジュールのサービス・インタフェースをプログラム的に操作する必要がある場合は、データ・コントロール名をコード内で参照できます。このため、アプリケーション・モジュールの名前を変更する場合は、ビュー・レイヤーを作成する前に変更する必要があります。

アプリケーション・モジュールのデータ・コントロールの詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

注意:

1つ以上のページですでに参照した後にアプリケーション・モジュールのデータ・コントロール名を変更する場合は、データ・コントロール名が参照されているページ定義ファイルとDataBindings.cpxファイルを開き、古い名前を新しい名前に手動で更新する必要があります。

アプリケーション・モジュールのデータ・コントロール名を変更するには:

1. 「アプリケーション」ウィンドウで、データ・コントロール名を編集するアプリケーション・モジュールをダブルクリックします。

2. 「プロパティ」ウィンドウで、「その他」セクションを開き、「データ・コントロール名」フィールドに適したデータ・コントロール名を入力します。

13.2.7 アプリケーション・モジュールの粒度に関する必知事項

アプリケーション・モジュールに関する一般的な疑問は、「アプリケーション・モジュールがどの位の大きさになるのか」というものです。つまり、「大規模なアプリケーション・モジュールを1つ作成してエンタープライズ・アプリケーションのデータ・モデル全体を含めるか、より小規模なアプリケーション・モジュールを多数作成して機能に応じてアプリケーションを区分化するか」という問題です。答えは状況によって異なります。

一般に、アプリケーション・モジュールのサイズは、そのモジュールでの対応が想定される特定のユースケースを十分にサポートできる大きさにする必要があります。「ネストされたアプリケーション・モジュールの定義」で説明するネスト機能を使用すると、粒度の細かい複数のアプリケーション・モジュール・コンポーネントからのアセンブルが可能になります。複雑なビジネス・アプリケーションのユースケースは通常は1つではないため、Oracle ADFで実装される複雑なビジネス・アプリケーションは一般に単一アプリケーション・モジュールになりません。

実際のプラクティスでは、必要なモジュール化タイプをサポートするための粒度を選択する場合があります。たとえば、個別のデータ・ソースをサポートする必要や個別のチューニング・オプションを構成する必要がある場合は、どちらも複数のアプリケーション・モジュールを作成する方が適しています。または、主要なユースケースが1つ、バックエンドでサポートしているユースケースが1つの小規模アプリケーションの場合、アプリケーション・モジュールを2つ作成できます。ただし、簡潔にするため、数個のビュー・オブジェクトのみを含んだ2つ目のアプリケーション・モジュールを作成するのではなく、両方のユースケースを組み合せることもできます。

その他の状況では、2つ以上のルート・アプリケーション・モジュールの作成を指定することがあります。たとえば、ユーザー・セッションごとに2つ以上のトランザクションをサポートする必要がある場合は、複数のアプリケーション・モジュールを作成できます。または、「タスク・フローのトランザクションの管理」に説明されているとおり、データ・コントロール・スコープとタスク・フローを操作してトランザクションを管理できます。

13.2.8 ビュー・オブジェクト・コンポーネントとビュー・オブジェクト・インスタンスに関する必知事項

アプリケーション・モジュールの設計時に、ビュー・オブジェクト・コンポーネントのインスタンスを使用してそのデータ・モデルを定義します。ユーザー・インタフェースに含まれるButtonコンポーネントの2つのインスタンスに、区別するためのmyButtonおよびanotherButtonというメンバー名が付けられているように、アプリケーション・モジュールにも、CustomerVOビュー・オブジェクト・コンポーネントの2つのインスタンスに、区別するためのCustomerListおよびAnotherCustomerListというメンバー名が付けられています。

13.3 アプリケーション・モジュールのデータベース接続の構成

データ・モデル・プロジェクトを初期化してADFビジネス・コンポーネントを使用する場合、データベース接続の詳細を指定するように求められます。ADFビジネス・コンポーネント・ウィザードを実行し、データベースの表やビューを操作してビジネス・コンポーネントを作成する前に、データベース接続を指定する必要があります。接続の詳細を指定すると、JDeveloperにより、現在のプロジェクトで作成されたすべてのアプリケーション・モジュールのデフォルトのランタイム接続として使用されるJava Database Connectivity (JDBC)データソースも作成されます。

アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタを使用して、各アプリケーション・モジュールのJDBCデータ・ソース定義を個々に変更できます。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。データ・ソースを使用しない場合は、概要エディタを使用して、個別のアプリケーション・モジュールの接続タイプをJDBC URL接続タイプに変更することもできます。

JDBCデータソースまたはJDBC URL接続タイプを使用すると、Javaの実行が可能なコンテキストであればどこでもアプリケーション・モジュールを実行できます。つまり、Java Enterprise Edition (Java EE)アプリケーション・サーバー内での実行に限定されません。たとえば、Oracle ADFモデル・テスターは、スタンドアロンのJavaツールで、Java EEアプリケーション・サーバーのコンテキストでは実行できませんが、このどちらかの接続タイプを使用すれば、Oracle ADFモデル・テスターでビジネス・モデルをテストできます。アプリケーション・モジュール構成の概要エディタを使用して、「データベース」ウィンドウに表示される既存のアプリケーション・リソース接続に対して、2つの中から接続タイプを選択できます。

アプリケーション・モジュールは、デフォルトでデータソース接続タイプを使用するように構成されます。JDBCデータソースは、データベース・サーバー接続をベンダーに依存しない形式でカプセル化したものです。JDBCデータソースは、JDBC URL接続タイプでは得られない利点を提供します。データソースに基づき接続タイプを定義すると、デプロイされたアプリケーションを変更することなく、データソースの再構成が行えます。データソースはアプリケーション・サーバー・レベルで一元定義できますが、JDBC URL接続ではそれが行えません。JDBCデータソースを使用できない場合は、ADFビジネス・コンポーネントにより、データソース接続情報に基づいて実行時にデフォルトのJDBC URLが構成されます。

13.3.1 JDBCデータソース接続タイプの使用方法

すべてのデフォルト・アプリケーション・モジュール構成で使用される接続タイプは、JDBCデータソースです。JDBCデータソースをアプリケーション・サーバー構成情報の一部として定義すると、アプリケーション・モジュールが実行時に論理名を使用してリソースを検索します。接続タイプとしてJDBCデータソースを使用すると、アプリケーション・リソース接続の詳細が変更される場合がありますが、デプロイされているアプリケーション・モジュール構成を変更する必要はありません。JDBCデータソースがすべてのアプリケーション・モジュール構成の選択肢としてお薦されているのは、このような理由によります。図13-12に、アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタに表示されたデフォルトの選択肢を示します。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。

図13-12 JDBCデータソース接続タイプの設定

注意:

「接続タイプ」ドロップダウンに表示される、もう一方の接続タイプはJDBC URL接続です。この接続タイプは、レガシー・アプリケーション用にサポートされています。これは、JDBCデータ・ソ－ス接続タイプのかわりに使用しないでください。

次の例は、Fusion Webアプリケーションのweb.xmlファイルの<resource-ref>タグを示しています。これらは、jdbc/Summit_adfDSおよびjdbc/Summit_adfCoreDSという名前の2つの論理データソースを定義しています。アプリケーション・モジュール構成の概要エディタは、「データソース名」フィールドの接頭辞java:comp/envの後ろにあるこの論理接続名を参照します。たとえば、同じFusion WebアプリケーションのJDBCデータ・ソース名は選択可能な値java:comp/env/jdbc/summit_adfDSを表示します。このように、「データソース名」フィールドには、使用可能なすべてのアプリケーション・リソース接続名のJNDI名が事前に取り込まれます。

<!-- In web.xml -->
<resource-ref>
<res-ref-name>jdbc/summit_adfDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<resource-ref>
<res-ref-name>jdbc/summit_adfCoreDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

ターゲットのスタンドアロン・アプリケーション・サーバー上でアプリケーションを実行するために必要なグローバル・データ・ソースの接続名を指定する場合は、「データソース名」フィールドを直接編集できます。Oracle WebLogic Serverのデプロイ時、デフォルトでは、アプリケーション固有のデータ・ソースにアプリケーションはパッケージされておらず、Oracle WebLogic Serverはjava:comp/env/jdbc/applicationConnectNameDSの検索によって、jdbc/applicationConnectNameDSという名前のグローバル・データ・ソースの検索を行うように設定されています。したがって、この命名規則に従うことで、アプリケーション固有のデータ・ソースを使用してアプリケーションをJDeveloperで実行する場合や、グローバル・データ・ソースを使用してデプロイ済のスタンドアロン・サーバー上で実行する場合に、単一のデータ・ソース接続名を正しく機能させることができます。

注意:

冗長なデータベースやバックエンドとしてのOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、アプリケーションはマルチ・データ・ソースを使用します。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースと非マルチ・データ・ソースでネーミング規則は同じになります。これによって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するマルチ・データ・ソースの構成の詳細は、『高可用性ガイド』を参照してください。

13.3.2 アプリケーション・モジュール・データベース接続作成時の処理

「構成の編集」ダイアログで接続タイプを選択すると、JDeveloperにより、アプリケーション・モジュールのXMLドキュメントに関連する./commonサブディレクトリにあるアプリケーション・モジュール構成ファイル、bc4j.xcfgが更新されます。このファイルは、1つのJavaパッケージ内の全アプリケーション・モジュールの構成を定義しています。bc4j.xcfgファイルは「アプリケーション」ウィンドウには表示されません。JDeveloperでbc4j.xcfgファイルを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックし、概要エディタで「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。

たとえば、コアSummit ADFサンプル・アプリケーションのModelプロジェクトの./classes/oracle/summit/model/services/commonディレクトリにあるSummitAppModuleアプリケーション・モジュールでアプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタを開くと、そのアプリケーション・モジュール用に名前の付いた構成があることがわかります。

bc4j.xcfgファイルで定義された構成により、Fusion Webアプリケーションはデプロイ済の特定のアプリケーション・モジュールとの対話が可能になります。bc4j.xcfgファイルには、アプリケーション・モジュールの接続タイプに加えて、アプリケーション・モジュール名に関するメタデータ情報と、アプリケーション・モジュールに構成されたランタイム・パラメータが含まれています。名前付き接続タイプのアプリケーション・リソース・データベース接続の詳細は、「アプリケーション」ウィンドウの「接続」ノードに定義され、アプリケーションのconnection.xmlファイルに格納されています。

次の例は、コアSummit ADFサンプル・アプリケーションのbc4j.xcfgファイル例を示しています。SummitAppModuleLocalおよびSummitAppModuleの構成は、どちらもJDBCDataSource属性内のデータソース(名前はSummit_adfDS)を参照します。各構成のJDBCDataSource属性には、アプリケーション・リソース接続名のJNDI名を、java:comp/env/jdbc/applicationConnectNameDSの形式で指定します。ここで、applicationConnectNameは、JDeveloperで定義されたアプリケーション・リソース・データベース接続名(この場合はSummit_adf)です。このJNDI命名規則(アプリケーション固有ネームスペースjava:comp/env/jdbc/およびDSをアプリケーション・リソース・データベース接続名に付加したもの)により、デプロイされたFusion Webアプリケーションは、変更を加えなくてもアプリケーションのグローバル・データソースを使用してOracle WebLogic Server上で実行されます。グローバル・データ・ソースは通常、アプリケーション・サーバー管理者がOracle WebLogic Server管理コンソールを使用して定義します。

<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
<AppModuleConfigBag ApplicationName="oracle.summit.model.services.SummitAppModule">
<AppModuleConfig name="SummitAppModuleLocal"
DeployPlatform="LOCAL"
JDBCName="summit_adf"
jbo.project="oracle.summit.model.Model"
java.naming.factory.initial="oracle.jbo.common.JboInitialContextFactory"
ApplicationName="oracle.summit.model.services.SummitAppModule">
<Database jbo.TypeMapEntries="Java"/>
<Security AppModuleJndiName="oracle.summit.model.services.SummitAppModule"/>
<Custom ns0:JDBCDataSource="java:comp/env/jdbc/summit_adfDS"
xmlns:ns0="http://xmlns.oracle.com/bc4j/configuration"/>
</AppModuleConfig>
...
</AppModuleConfigBag>
</BC4JConfig>

13.3.3 アプリケーション・モジュールのランタイム構成の変更方法

アプリケーション・モジュールのXML定義の作成に加え、JDeveloperでは、アプリケーション・モジュールのXML定義ファイルを含むディレクトリを相対位置とするcommonという名前のサブディレクトリにあるbc4j.xcfgファイルにappModuleNameLocalという名前のデフォルトの構成も追加します。bc4j.xcfgファイルは「アプリケーション」ウィンドウには表示されません。JDeveloperでbc4j.xcfgファイルを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックし、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。デフォルト設定を表示したり、アプリケーション・モジュールのランタイム構成の設定を変更するには、概要エディタで「データベースとスケーラビリティ」タブを選択し、必要な変更を加えます。

始める前に:

アプリケーション・モジュール・データベース接続に関する知識があると役立つ場合があります。詳細は、「アプリケーション・モジュールのデータベース接続の構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

アプリケーション・モジュールの構成を管理するには:

1. 「アプリケーション」ウィンドウで、構成を編集するアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「構成」ナビゲーション・タブをクリックします。

3. 「構成」ページで、編集する構成ハイパーリンクをクリックします。

「構成」ページには次の3つのデフォルト構成が表示される可能性があります。

- appModuleNameLocal: アプリケーション・モジュールを作成すると、自動的にローカル構成が1つ定義されます。テスト目的でアプリケーション・モジュールのランタイム・プロパティを変更する場合などは、新しいローカル構成を作成してください。

- appModuleNameShared: 共有アプリケーション・モジュール構成が存在するのは、データ・モデル・プロジェクトの「プロジェクト・プロパティ」ダイアログで共有アプリケーション・モジュールの名前付きインスタンスが定義されている場合のみです。共有アプリケーション・モジュールは、アプリケーション全体で静的データのリストを再利用する場合に、ビュー・インスタンスをグループ化したアプリケーション・モジュールです。たとえば、共有アプリケーション・モジュールを定義して、国リストなどの参照データにアクセスするビュー・インスタンスをグループ化できます。

- appModuleNameService (サービス・インタフェースのタイプSI): サービス・インタフェース構成が存在するのは、アプリケーション・モジュールの概要エディタの「サービス・インタフェース」ページでサービス・インタフェース(Webサービス実装ラッパー)が定義されている場合のみです。Webサービスとして公開されているアプリケーション・モジュールでは、アプリケーション・モジュールをコンポジット・アプリケーションに組み込んで、Webサービス・クライアントからデータ・アクセスやメソッド呼出しができます。同じアプリケーション・モジュールで、ADFデータ・コントロールおよびWebサービス・クライアントを使用する対話型のWebユーザー・インタフェースをサポートできます。

4. アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタで、「データベースとスケーラビリティ」タブをクリックして、目的のランタイム・プロパティをカスタマイズし変更を保存します。

13.3.4 プロジェクトのデータベース接続の変更方法

アプリケーションの開発時、多数の異なるユーザーやスキーマを切り替える場合があります。これには、そのビジネス・コンポーネントを含むプロジェクトのデータベース接続プロパティを変更します。選択を行うと、プロジェクトのbc4j.xcfgファイルで、JDBC URLタイプ接続を指定する各構成の接続文字列が自動的に更新されます。

始める前に:

アプリケーション・モジュール・データベース接続に関する知識があると役立つ場合があります。詳細は、「アプリケーション・モジュールのデータベース接続の構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

アプリケーション・モジュールの構成で使用する接続を変更するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールが含まれているプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「接続」ドロップダウン・リストから「ADFビジネス・コンポーネント」を選択し、目的の接続を選択して「編集」アイコンをクリックします。

3. 「データベース接続の編集」ダイアログで、必要な変更を行います。

4. 「OK」をクリックします。

13.4 ネストされたアプリケーション・モジュールの定義

アプリケーション・モジュールでは、高レベルな機能により複数のビジネス・ワークフローに共通なサブ機能が再使用される、ユースケースのモジュール性を模倣するソフトウェア・コンポーネントを作成する機能をサポートしています。このモジュール性は、他のアプリケーション・モジュールのインスタンスを使用してアセンブルする複合アプリケーション・モジュールを定義することで実装できます。このタスクはアプリケーション・モジュールのネストと呼ばれています。つまり、アプリケーション・モジュールにはビュー・オブジェクト・インスタンスだけでなく、1つ以上の他のアプリケーション・モジュール・インスタンスを(論理的に)含めることができます。最も外側に含まれているアプリケーション・モジュールは、ルート・アプリケーション・モジュールと呼ばれています。

ネストされたアプリケーション・モジュール定義の宣言的サポートは、図13-14に示すように、アプリケーション・モジュールの概要エディタから使用できます。アプリケーション・モジュールのAPIでも、実行時のアプリケーション・モジュールのネストがサポートされています。

アプリケーション・モジュールのインスタンスを別のアプリケーションにネストするときは、ビュー・オブジェクト・インスタンスをそのデータ・モデルに集約するのみならず、そこで定義されているカスタム・サービス・メソッドも集約します。アプリケーション・モジュールのインスタンスを別のアプリケーション・モジュール内でネストまたは再利用するこの機能は、大規模で実用的なアプリケーション・システムを実装するための、ADFビジネス・コンポーネントの重要な設計要素です。

アプリケーション・モジュールがエンド・ユーザーのユースケースまたはワークフローを表していることを考えると、一部の共有のモジュール化ユースケースで必要なデータを提供するアプリケーション・モジュールを作成でき、より複雑なユースケースをサポートするように設計されている、より複雑な別のアプリケーション・モジュール内でそれらのアプリケーション・モジュールを再使用できます。たとえば、アプリケーション・モジュールBackOfficeAMおよびCustomerSelfServiceAMを作成した後に、この両方のサービスを新しいコンポジット・サービス・アプリケーション・モジュールの不可欠な部分として使用するアプリケーションの作成が必要になったとします。図13-13は、このコンポジット・サービスがJDeveloperのビジネス・コンポーネント・ダイアグラムでどのように表示されるかを示しています。この図に示すように、SummitAppModuleなどのアプリケーション・モジュールには、ビュー・オブジェクト・インスタンスとアプリケーション・モジュール・インスタンスを含めることができます。

図13-13 アプリケーション・モジュール・インスタンスの再使用によるコンポジット・サービスのアセンブル

13.4.1 ネストされたアプリケーション・モジュールの定義方法

既存のアプリケーション・モジュールのインスタンスをネストする複合ルート・アプリケーション・モジュールを指定するには、アプリケーション・モジュールの概要エディタを使用します。(アプリケーション・モジュール・インスタンスに含まれる)ネストされたすべてのコンポーネント・インスタンスでは、それらのインスタンスを再使用するルート・アプリケーション・モジュールと同じトランザクションとエンティティ・オブジェクト・キャッシュが共有されます。

たとえば、Summit ADFサンプル・アプリケーションのSummitADFワークスペースで、ネストしたアプリケーション・モジュール・インスタンスBackOfficeAMおよびCustomerSelfServiceAMは、ルート・アプリケーション・モジュールSummitAppModuleと同じトランザクションおよびエンティティ・オブジェクト・キャッシュを共有します。

ヒント:

ネストされたアプリケーション・モジュールをアプリケーションで利用する場合は、「「データ・コントロール」パネルでのネストされたアプリケーション・モジュールの表示」を必ず参照して、これらのモジュールを含むデータ・バインディングの実行時によく発生する問題を回避してください。

始める前に:

ネストされたアプリケーション・モジュールに関する知識があると役立つ場合があります。詳細は、「ネストされたアプリケーション・モジュールの定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

ネストされたアプリケーション・モジュールを定義するには:

1. 「アプリケーション」ウィンドウで、ネストされたアプリケーション・モジュールを定義するルート・アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。

3. 「データ・モデル・コンポーネント」ページの「アプリケーション・モジュール・インスタンス」セクションを展開し、「使用可能」リストで、データ・モデルに追加するアプリケーション・モジュールを選択します。

リストの下の「新規アプリケーション・モジュール・インスタンス」フィールドに、データ・モデルに追加するネストされたアプリケーション・モジュールを識別する際に使用される名前が示されます。

4. アプリケーション・モジュールを追加する前に名前を変更するには、「新規アプリケーション・モジュール・インスタンス」フィールドに別の名前を入力します。

5. 目的のアプリケーション・モジュールを選択し、「選択済」リストに移動します。

たとえば、Summit ADFサンプル・アプリケーションのSummitADFワークスペースで、SummitAppModuleアプリケーション・モジュールはBackOfficeAMおよびCustomerSelfServiceAMという2つのネストしたアプリケーション・モジュール・インスタンスを定義します。図13-14に、「選択済」リストに追加されたアプリケーション・モジュール・インスタンスBackOfficeAMおよびCustomerSelfServiceAMを示します。

図13-14 データ・モデルへのアプリケーション・モジュール・インスタンスの追加

13.4.2 ルート・アプリケーション・モジュールおよびネストされたアプリケーション・モジュールの慣用名に関する必知事項

実行時に、アプリケーションはメインの、またはルートと呼ばれている、アプリケーション・モジュールを使用します。どのアプリケーション・モジュールもルート・アプリケーション・モジュールとして使用できますが、実際には、単純なCRUDアプリケーションを作成している場合を除き、より複雑なエンド・ユーザーのユースケースに対応するアプリケーション・モジュールがルートとして使用されます。ルート・アプリケーション・モジュールに別のアプリケーション・モジュールがネストされている場合、そのモジュールはすべてルート・アプリケーション・モジュールのトランザクションに関与し、同じデータベース接続および単一のエンティティ・キャッシュ・セットを共有します。この共有は、ルート・アプリケーション・モジュールおよびそのTransactionオブジェクトによって自動的に処理されます。

また、トランザクション境界を宣言的に管理するためADFバインド・タスク・フローを使用してアプリケーションを作成する場合、Oracle ADFフレームワークにより実行時にタスク・フローで使用されるアプリケーション・モジュールが自動的にネストされます。バインド・タスク・フローとトランザクションの詳細は、「タスク・フローのトランザクションの管理」を参照してください。

13.5 ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成

ビジネス・サービスのデータ・モデルを開発する際、多くの場合、UMLモデルを使用して視覚化すると便利です。JDeveloperでは、他の開発者が参照できるアプリケーション・モジュール用のダイアグラムを簡単に作成できます。

アプリケーション・モジュールの編集、表示オプションの制御、メソッド名のフィルタ処理、関連するオブジェクトやファイルの表示、アプリケーションの公開、Oracle ADFモデル・テスターの起動など、多数のタスクをダイアグラム上で直接実行できます。

13.5.1 アプリケーション・モジュールのダイアグラムの作成方法

アプリケーション・モジュールのダイアグラムを作成するには、「新規ギャラリ」から使用できる「ビジネス・コンポーネント・ダイアグラムの作成」ダイアログを使用します。

始める前に:

UMLモデル・ダイアグラムについて理解しておくと役立つ場合があります。詳細は、「ビジネス・サービス用アプリケーション・モジュールのダイアグラムの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

アプリケーション・モジュールのダイアグラムを作成するには:

1. 「アプリケーション」ウィンドウで、ダイアグラムを作成するデータ・モデル・プロジェクトを右クリックし、「新規」→「ビジネス・コンポーネント・ダイアグラム」を選択します。

2. 「ビジネス・コンポーネントの作成」ダイアログで、ダイアグラム名と、ダイアグラムの作成先のパッケージ名を入力します。

3. 「OK」をクリックすると、空のダイアグラムが作成され、ダイアグラマを開きます。

4. 「アプリケーション」ウィンドウで、目的のアプリケーション・モジュールを選択し、それをダイアグラム上にドロップします。

5. アプリケーション・モジュール・ダイアグラム内で、目的のダイアグラム・ノードを右クリックして「ビジュアル・プロパティ」を選択し、「ビジュアル・プロパティの編集」ダイアログで必要な変更を加えます。

6. ダイアグラム・エディタで、アプリケーション・モジュール・ダイアグラム以外の任意の場所をクリックし、ダイアグラム・エディタの「プロパティ」ウィンドウを表示して次の変更を加えます。

- レイアウト・スタイルの設定

- フォントの変更

- グリッドをオフ

これらの手順の完了後、ダイアグラムは図13-15のようになります。

図13-15 アプリケーション・モジュールのUMLダイアグラムの一部

13.5.2 アプリケーション・モジュールのダイアグラム作成時の処理

ビジネス・コンポーネント・ダイアグラムを作成すると、ダイアグラムが格納されているパッケージ名と一致するプロジェクトのモデル・パスのサブディレクトリに、ダイアグラムを示す.adfbc_diagramファイルが作成されます。

デフォルトでは、「アプリケーション」ウィンドウによってプロジェクト・コンテンツのパスの表示が統一され、ソース・パスのADFコンポーネントおよびJavaファイルがプロジェクト・モデル・パスのUMLモデル・アーティファクトと同じパッケージ・ツリーに表示されます。「アプリケーション」ウィンドウで「アプリケーション・ウィンドウのオプション」→「ディレクトリの表示」ツールバー・オプションを使用して、プロジェクト・コンテンツのユニファイド・ディレクトリ・ビューとより明確なディレクトリ・パス・ビューを切り替えられます。

13.5.3 ダイアグラムを使用したアプリケーション・モジュールの編集方法

ビジネス・コンポーネントのUMLダイアグラムは、アプリケーション・モジュールをダイアグラムにドロップした時点の状態を示す単なる静的な図ではありません。むしろ、UMLダイアグラムは、現在のコンポーネント定義をUMLベースでレンダリングした図であるため、常に現在の状況を示しています。UMLダイアグラムは、視覚化を可能にするのみならず、視覚的なナビゲーションおよび編集ツールでもあります。

ポップアップ・メニューから「プロパティ」を選択(またはアプリケーション・モジュールをダブルクリック)すると、任意のアプリケーション・モジュールの概要エディタを起動できます。

また、ビュー・オブジェクト・インスタンス名の変更、ビュー・オブジェクト定義を「アプリケーション」ウィンドウからデータ・モデルにドロップすることによる新しいビュー・オブジェクト・インスタンスの作成、[Del]キーを押すことによるビュー・オブジェクト・インスタンスの削除など、いくつかのアプリケーション・モジュール編集タスクもダイアグラム上で直接実行できます。

注意:

コンポーネントをダイアグラムから削除すると、その表示のダイアグラム画面からの削除のみが行われます。コンポーネントとクラスはファイル・システムと「アプリケーション」ウィンドウ内に存続します。

13.5.4 ダイアグラム表示オプションの制御方法

ダイアグラムでアプリケーション・モジュールを表示後、「ビジュアル・プロパティの編集」ダイアログを使用して表示オプションを制御します。ダイアグラムのダイアログを表示するには、ダイアグラム内でアプリケーション・モジュール・ノードを右クリックし、「ビジュアル・プロパティ」を選択します。

「表示」ページで、プロパティを次のように切り替えます。

- パッケージを表示 - パッケージ名を表示

- メソッドの表示 - サービス・メソッドを表示

- ステレオタイプの表示 - オブジェクトの型を表示(「<<application module>>」など)

- 使用方法の表示 - 現在のプロジェクトの他のアプリケーション・モジュールによるすべての使用を表示

「メソッド」ページでは、ダイアグラムに求められる詳細のレベルに応じて次の設定を変更します。

- 可視性の表示(「public」、「private」など)

- メソッドの戻りタイプの表示

- staticメソッドの表示

図13-16の「ビジュアル・プロパティの編集」ダイアログの設定に示すように、デフォルトでは、アプリケーション・モジュールのすべての操作が表示されます。

図13-16 デフォルトのダイアグラム・エディタのオプションを示す「ビジュアル・プロパティの編集」ダイアログ

ダイアグラムのコンテキスト・メニューでは、「表示モード」に対して次を選択することもできます。

- 圧縮 - アイコンおよび名前のみを表示

- シンボル - サービス操作を表示

- 展開済 - 操作およびデータ・モデルを表示(デフォルト)

13.5.5 ダイアグラム内に表示されたメソッド名のフィルタ方法

デフォルトでは、アプリケーション・モジュールのメソッドを表示すると、ダイアグラムにすべてのメソッドが表示されます。オーバーライドされたフレームワーク・メソッドとして認識されるメソッドは、すべて「Framework」操作カテゴリに表示されます。他のメソッドは、「Business」メソッド・カテゴリに表示されます。

「ビジュアル・プロパティの編集」ダイアログの「メソッド」 ページの「対象外のメソッド・フィルタ」設定は、ダイアグラムに表示したくないメソッドを除外するために使用できる正規表現です。たとえば、「対象外のメソッド・フィルタ」を次のように設定します。

findLoggedInUser.*|retrieveOrder.*|get.*

この場合、次のアプリケーション・モジュール・メソッドをすべてフィルタ処理できます。

- findLoggedInUserByEmail

- retrieveOrderById

- 生成されたビュー・オブジェクトのgetterメソッド全般

13.5.6 関連するオブジェクトおよび実装ファイルのダイアグラムでの表示方法

ダイアグラム上でアプリケーション・モジュール(またはそのデータ・モデル内の任意の個別ビュー・オブジェクト・インスタンス・セット)の選択後、「表示」→「関連する要素」をコンテキスト・メニューから選択し、ダイアグラムに関連するコンポーネントを表示できます。同様に、「表示」→「実装ファイル」を選択することで、アプリケーション・モジュールを実装するファイルをダイアグラムに含むことができます。求められる詳細のレベルがダイアグラムに追加されるまで、表示されている追加ダイアグラム要素に対して前述のオプションを繰り返し使用できます。

図13-17は、アプリケーション・モジュールの実装ファイルを表示した図を示しています。アプリケーション・モジュールの実装クラスの関連要素(AppModuleImpl)が表示されています。また、アプリケーション・モジュールと実装クラス間の依存性を示す追加の線も表示されています。特定のカスタム・インタフェースにアプリケーション・モジュール・インスタンスをキャストした場合でも、図のように表示されます。

図13-17 「表示」→「関連する要素」および「表示」→「実装ファイル」によるダイアグラムへの詳細の追加

13.5.7 アプリケーション・モジュール・ダイアグラムの公開方法

ダイアグラムをPNG、JPG、SVGまたは圧縮されたSVG書式で公開するには、ダイアグラム上でポップアップ・メニューから「ダイアグラムの公開」を選択します。

13.5.8 ダイアグラムからのアプリケーション・モジュールのテスト方法

ダイアグラムのアプリケーション・モジュールに対してOracle ADFモデル・テスターを起動するには、ポップアップ・メニューから「実行」を選択します。

13.6 複数ページの作業ユニットのサポート

Fusion Webアプリケーションとの対話中に、エンド・ユーザーには次のような状況が発生する場合があります。

- 同じページを複数回表示する場合に、迅速なレスポンスを期待

- 完了までに多数のページを表示する必要がある論理作業ユニットを実行

- 未保存の保留中の変更内容の部分的なロールバックの実行を要求

- サーバー・ファームのアプリケーション・サーバー障害による、保存前の保留中の変更への不可抗力的な被害

アプリケーション・モジュール・プーリング機能および状態管理機能では、これらの要件に対処するスケーラブルで高パフォーマンスの実装を簡略化します。

注意:

ADFバインド・タスク・フローは、トランザクションの作業ユニットを表すことができます。タスク・フローのオプションを指定して、トランザクションの処理方法を決定できます。ADFバインド・タスク・フローの宣言的な機能の詳細は、「タスク・フローのトランザクションの管理」を参照してください。

13.6.1 Oracle ADFモデル・テスターでの状態管理のシミュレーション方法

実行する状態管理機能をシミュレートするために、アプリケーション・モジュールでOracle ADFモデル・テスターの2つのインスタンスを起動できます。

始める前に:

状態管理に関する知識があると役立つ場合があります。詳細は、「複数ページの作業ユニットのサポート」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

Oracle ADFモデル・テスターを使用してトランザクション状態の受動化をシミュレートするには:

1. Oracle ADFモデル・テスターを実行し、ビュー・オブジェクト・インスタンスをダブルクリックしてそのデータを問い合せます。

2. 数行のいくつかの属性の現在値をメモします。

3. これらの属性が別々の値を持つようにこれらの行に更新します。ただし、変更はコミットしないでください。

4. Oracle ADFモデル・テスターのメイン・メニューから、「ファイル」→「トランザクション状態の保存」を選択します。

「受動化されたトランザクション状態」ダイアログが開き、トランザクションID番号が表示されます。この番号をメモします。

5. Oracle ADFモデル・テスターを完全に終了します。

6. Oracle ADFモデル・テスターを再起動し、同じビュー・オブジェクト・インスタンスをダブルクリックしてそのデータを問い合せます。

7. データは変更されない点に注意してください。データから問い合せたデータは、データベースの現在の状態を示し、前述の変更は反映されていません。

8. Oracle ADFモデル・テスターのメイン・メニューから、「ファイル」→「トランザクション状態のリストア」を選択し、ステップ4でメモしたトランザクションIDを入力します。

この時点で、保留中の変更が、変更した行に再反映されます。ここでトランザクションをコミットすると、変更内容はデータベースに永続的に保存されます。

13.6.2 実行時に行われる処理: アプリケーションでアプリケーション・モジュール・プーリングと状態管理が使用される場合

アプリケーション・モジュールをそのビジネス・サービスとして利用するアプリケーションを作成すると、そのアプリケーションでは自動アプリケーション・モジュール・プーリング機能を使用できます。この機能では、アプリケーションに対するエンド・ユーザーの負荷(ロード)の日中の変化に応じて増減するアプリケーション・モジュール・インスタンスの構成可能なセットを管理します。アプリケーション・ユーザー・インタフェースとのエンド・ユーザーの対話に特有の思考時間の性質により、プール内のアプリケーション・モジュール・インスタンスの数は、システムを使用しているアクティブ・ユーザーの合計数より少なくなる場合があります。

図13-18に示すように、あるエンド・ユーザーがアプリケーションの複数ページを表示して論理タスクを実行する場合、各ページ・リクエストに対し、プール内のアプリケーション・モジュール・インスタンスがその1リクエストの存続時間中にプールから自動的に取得されます。リクエストの最後に、インスタンスはプールに自動的に戻され、別のユーザー・セッションで使用可能になります。エンド・ユーザーの作業をアプリケーション・サーバーの障害から保護するために、アプリケーション・モジュールでは、そのエンティティ・キャッシュ内の保留中の変更セットを示すXMLスナップショットを保存することで、その変更セットを永続ストアに格納する機能をサポートしています。スケーラビリティ上の理由から、この状態スナップショットは通常、アプリケーション・データを含むデータベース・スキーマとは別の状態管理スキーマに保存されます。

図13-18 複数ページの論理作業ユニット全体に対するプールされたアプリケーション・モジュールの使用方法

プーリング・アルゴリズムではチューニング可能な最適化が行え、特定数のアプリケーション・モジュール・インスタンスが、プールに戻された最後のユーザー・セッションとの「スティッキー」な状態を維持しようとします。最適化は保証されていませんが、ユーザーが最適化による利益を得ることができれば、システム・ローダーが許容する限り、プール内の同じアプリケーション・モジュール・インスタンスを継続的に使用します。負荷が重すぎる場合、プーリング・アルゴリズムはプール内で使用可能な任意のインスタンスを使用してユーザーのリクエストに応え、その論理作業単位の凍結スナップショットを永続ストアから再構築して、アプリケーション・モジュールの新しいインスタンスが前回途中になったところから継続できるようにします。エンド・ユーザーは変更をコミットまたはロールバックするまで、この方法で作業を継続します。

アプリケーション・モジュールはこれらの機能を使用し、完全にステートレスなアプリケーションに近い実行時パフォーマンスを実現するアーキテクチャにおいて、複数ページのワークフローを簡単に処理できる、生産性の高いステートフルなパラダイムを実現します。これらのアプリケーション・モジュール機能の詳細は「Fusion Webアプリケーションでの状態管理の使用」を、チューニング方法の詳細は「アプリケーション・モジュール・プールのチューニング」を参照してください。

13.7 サービス・メソッドによるアプリケーション・モジュールのカスタマイズ

アプリケーション・モジュールでは、カスタムJavaコードを必要とせずに、そのビュー・オブジェクト・インスタンスのデータ・モデルをクライアントに公開できます。このため、クライアント・コードではoracle.jboパッケージのApplicationModule、ViewObject、RowSetおよびRowというインタフェースを使用して、データ・モデル内のビュー・オブジェクトを直接操作できます。ただし、クライアント・コードで自由にビュー・オブジェクトをプログラミングで操作できても、それが必ずしもベスト・プラクティスではありません。

ビュー・オブジェクトを操作するプログラム的なコードが完全なビジネス・サービス機能を実装するための論理的な特徴を備えている場合、アプリケーション・モジュールのJavaクラスでカスタム・メソッドを記述して、詳細をカプセル化する必要があります。これには次のコードが含まれます。

- 表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成

- 集計結果を取得するための、ビュー・オブジェクト行の反復処理

- 1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行

これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。

- コードの目的が、クライアントにより明確に伝わります。

- 必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。

- ビジネス・サービス機能全体の回帰テストを簡略化できます。

- クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。

- ページ内での論理的ビジネス機能の宣言的起動が可能になります。

13.7.1 アプリケーション・モジュールのカスタム・クラスの生成方法

カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、まずそのカスタムJavaクラスを有効化する必要があります。IDEレベルの「ビジネス・コンポーネント」のJava生成設定で、アプリケーション・モジュール・クラスが自動的に生成されるように構成されている場合は、カスタム・クラスが発生します。図13-19に示すように、アプリケーション・モジュールにカスタムJavaクラスがあるかどうかが不明な場合は、「アプリケーション」ウィンドウでそのアプリケーション・モジュール・ノードの概要エディタを開きます。エディタの「Javaクラス」ページに、プロジェクトのアプリケーション・モジュール用に生成されたクラスの完全リストが表示されます。他のユーザーによりすでにファイルが作成されているため存在する場合、「Javaクラス」ページには「アプリケーション・モジュール・クラス」として特定された、リンクされたファイル名が表示されます。ソース・エディタで既存ファイルを開くには、対応するファイル名のリンクをクリックします。

図13-19 概要エディタのアプリケーション・モジュールのカスタムJavaクラス

プロジェクトにJavaクラスが存在しない場合、アプリケーション・モジュールの概要エディタの「Javaクラス」ページで生成できます。

始める前に:

アプリケーション・モジュールのサービス・メソッドに関する知識があると役立つ場合があります。詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

アプリケーション・モジュール・クラスのJavaファイルを生成するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」ボタンをクリックします。

3. 「Javaオプションの選択」ダイアログで、「アプリケーション・モジュール・クラスの生成」を選択します。

4. 「OK」をクリックします。

「Javaクラス」ページに新しい.javaファイルが表示されます。

13.7.2 アプリケーション・モジュールのカスタム・クラス生成時の処理

アプリケーション・モジュールのカスタム・クラスを生成すると、JDeveloperではコンポーネントのXMLドキュメント・ファイルと同じディレクトリにファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleNameImpl.javaになります。

アプリケーション・モジュールに対して選択したJava生成オプションは、アプリケーション・モジュールの概要エディタの「Javaクラス」ページに後でアクセスしてもそのまま反映されています。XML定義ファイルの場合と同様、このエディタでどのような変更を行っても、カスタムJavaクラスで生成されたコードは最新の状態に保たれます。後でカスタムJavaファイルが不要になった場合は、「Javaクラス」ページから「Javaオプションの選択」ダイアログを開き、「アプリケーション・モジュール・クラスの生成」の選択を解除すると、プロジェクトからカスタムJavaファイルが削除されます。

13.7.3 デフォルトのコード生成に関する必知事項

デフォルトでは、アプリケーション・モジュールのJavaクラスは、最初に有効化した際、次の例のようになります。それには、データ・モデルの各ビュー・オブジェクト・インスタンス用のgetterメソッドが含まれます。

package oracle.summit.model.services;

import oracle.jbo.server.ApplicationModuleImpl;
// ---------------------------------------------------------------------
// ---    File generated by ADF Business Components Design Time.
// ---    Custom code may be added to this class.
// ---    Warning: Do not modify method signatures of generated methods.
// ---------------------------------------------------------------------
public class AppModuleImpl extends ApplicationModuleImpl {
/** This is the default constructor (do not remove) */
public AppModuleImpl() { }

/** Container's getter for YourViewObjectInstance1 */
public YourViewObjectImpl getYourViewObjectInstance1() {
return (YourViewObjectImpl)findViewObject("YourViewObjectInstance1");
}

// ... Additional ViewObjectImpl getters for each view object instance

// ... ViewLink getters for view link instances here
}

図13-20に示すように、アプリケーション・モジュール・クラスでは、カスタム・コードを追加する前にすべてのデフォルト動作を継承するようにベースADFのApplicationModuleImplクラスを拡張します。

図13-20 カスタム・アプリケーション・モジュール・クラスによるApplicationModuleImplの拡張

13.7.4 アプリケーション・モジュールへのカスタム・サービス・メソッドの追加方法

カスタム・サービス・メソッドをアプリケーション・モジュールに追加するには、アプリケーション・モジュールのカスタム・クラスに移動して、新しいメソッドのJavaコードをアプリケーション・モジュールのJava実装クラスに入力します。次のガイドラインを使用して、メソッドに適切な可視性を判断してください。

- メソッドをこのコンポーネントの実装内でヘルパー・メソッドとしてのみ使用する場合は、メソッドをprivateにします。

- アプリケーション・モジュールの最終的なサブクラスでこのメソッドを起動またはオーバーライドできるようにする場合は、メソッドをprotectedにします。

- クライアントによる起動を可能にする場合は、publicにする必要があります。

注意:

この章のアプリケーション・モジュールの例では強く型付けされたカスタム・エンティティ・オブジェクト・クラスを使用しています。これらのエンティティ・クラスの作成方法の詳細は、「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」を参照してください。

次の例は、AppModuleアプリケーション・モジュールのAppModuleImpl.javaクラスでのprivate retrieveOrderById()ヘルパー・メソッドを示しています。ここでは、関連するエンティティ定義にアクセスするためにOrdEOImplエンティティ・オブジェクト・クラスのstatic getDefinitionObject()メソッドが使用され、注文の検索に適したKeyオブジェクトを作成するためにエンティティ・オブジェクト・クラスでcreatePrimaryKey()メソッドが使用され、エンティティ行をエンティティ・キャッシュで検索するためにエンティティ定義でfindByPrimaryKey()メソッドが使用されています。このメソッドからは、強く型付けされたOrdersImplクラス(Ordersエンティティ・オブジェクトのカスタムJavaクラス)のインスタンスが戻されます。

// In summit.model.appmodule.service.AppModuleImpl class
/*
* Helper method to return a Order by Id
*/
private OrdersImpl retrieveOrderById(long orderId) {
EntityDefImpl orderDef = OrdersImpl.getDefinitionObject();
Key orderKey = OrdersImpl.createPrimaryKey(new DBSequence(orderId));
return (OrdersImpl)orderDef.findByPrimaryKey(getDBTransaction(), orderKey);
}

次の例は、作成する注文のIDをコール元が渡すことを可能にするpublic findOrderAndCustomer()メソッドを示しています。OrdersImplエンティティ・オブジェクト・クラスのgetCustomer()メソッドを使用して、関連するエンティティ定義にアクセスします。

/*
* Create a new Customer and Return its new id
*/
public String findOrderAndCustomer(long orderId) {
OrdersImpl order = retrieveOrderById(orderId);
if (order != null) {
CustomerImpl cust = order.getCustomer();
if (cust != null) {
return "Customer: " + cust.getName() + ", Location: " + cust.getCity();
}
else {
return "Unassigned";
}
}
else {
return null;
}
}

13.7.5 static mainメソッドを使用したカスタム・アプリケーション・モジュールのテスト方法

カスタム・アプリケーション・モジュールのメソッドをテストする準備ができたら、JDeveloperを使用してJUnitテスト・ケースを生成できます。JUnitでは、oracle.jbo packageで使用可能な任意のプログラムのAPIを使用して、アプリケーション・モジュールの操作およびカスタム・メソッドを起動が可能です。ADFビジネス・コンポーネントでのJUnit使用の詳細は、「JUnitを使用した回帰テスト」を参照してください。

JUnitテスト・ケースの代替方法として、カスタム・アプリケーション・モジュール・メソッドをテストする一般的な方法は、簡単なテスト・ケースを作成することです。たとえば、テスト用のコードをオブジェクトに作成し、そのコードをstatic main()メソッドに含めます。次の例は、これから記述するサンプル・メソッドをテストするために、カスタム・アプリケーション・モジュール・クラスに追加できるサンプルのmain()メソッドを示しています。Configurationオブジェクトを使用して(「コマンド行Javaテスト・クライアントの作成方法」を参照)、テスト用のアプリケーション・モジュールをインスタンス化および操作します。

注意:

Configurationオブジェクトがoracle.jbo.clientパッケージ内に存在していることは、それがアプリケーション・クライアントとしてアプリケーション・モジュールへのアクセスに使用されていることを示しています。main()メソッドは一種のプログラム的なコマンド行クライアントであるため、このような使用方法に問題はありません。また、createRootApplicationModule()の戻り値をアプリケーション・モジュールの実装クラスに直接キャストするのは一般的ではありませんが、このオブジェクトはアプリケーション・モジュールのクライアントであるとしても、main()メソッドのコードがアプリケーション・モジュールの実装クラス自体の中に格納されているため、この状況でこの操作を行うことは適切です。

次の例のコードを見ると、これまでの例で作成したメソッドを使用して次が実行されていることがわかります。

1. 注文101の合計を取得します。

2. 注文101の顧客名を取得します。

3. 101の注文ステータスを「Y」の値に設定します。

package oracle.summit.model.appmodule.service;

import oracle.jbo.ApplicationModule;
import oracle.jbo.JboException;
import oracle.jbo.client.Configuration;

public class TestAM {
public TestAM() {
super();
}

/*
* Testing method
*/

public static void main(String[] args) {
String amDef = "oracle.summit.model.appmodule.service.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
/*
* NOTE: This cast to use the AppModuleImpl class is OK since this
*       code is inside a business tier file and not in a
*       client class that is accessing the business tier from "outside".
*/
AppModuleImpl service = (AppModuleImpl)am;

String customerName = service.findOrderAndCustomer(101);
System.out.println("Customer for Order # 101 = " + customerName);
try {
service.updateOrderStatus(101,"Y");
}
catch (JboException ex) {
System.out.println("ERROR: "+ex.getMessage());
}
Configuration.releaseRootApplicationModule(am,true);
}
}

カスタム・アプリケーション・モジュール・クラスを実行すると、前述の例のmain()メソッドがコールされ、次の出力が生成されます。

anonymous
Customer for Order # 101 = Customer: Kam's Sporting Goods, Location: Hong Kong

注意:

カスタム・アプリケーション・モジュールに作成したカスタム・サービス・メソッドを、クライアント・アプリケーションを使用して起動する方法の詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

13.7.6 プログラムによる行セットの反復に関する必知事項

アプリケーション・ロジックが行セットにアクセスし、プログラムによる反復を実行する場合は必ず、ユーザー・インタフェース・コンポーネントにバインドされている可能性があるので、アプリケーション・モジュールのデータ・モデル内のビュー・オブジェクト・インスタンス、またはこれらのビュー・オブジェクト・インスタンスのビュー・リンク・アクセッサ行セットを扱う際に、セカンダリ行セット・イテレータを使用する必要があります。セカンダリ・イテレータを作成するには、作業対象の行セットに対してcreateRowSetIterator()メソッドを使用します。使用を修了したら、行セットに対してcloseRowSetIterator()メソッドを呼び出し、メモリーからセカンダリ・イテレータを削除する必要があります。次の例は、データ・モデル内のCustomerView1ビュー・オブジェクト・インスタンスが、ユーザー・インタフェースにバインドされる可能性がある(現在または後で)ため、プログラムによる反復用に、セカンダリ行セット・イテレータを正しく使用する典型的なアプリケーション・モジュールのカスタム・メソッドを示しています。

// Custom method in an application module implementation class
public void doSomeCustomProcessing() {
ViewObject vo = getCustomerView1();
// create secondary row set iterator with system-assigned name
RowSetIterator iter = vo.createRowSetIterator(null);
while (iter.hasNext()) {
Row r = iter.next();
// Do something with the current row.
Integer custId = (Integer)r.getAttribute("Id");
String name  = (String)r.getAttribute("Name");
System.out.println(custId + " " + name);
}
// close secondary row set iterator
iter.closeRowSetIterator();
}

注意:

行セットのデフォルト行セット・イテレータを使用して独自の行セットの反復を行う、ビュー・オブジェクトの実装クラス内のカスタム・コードについても同じことがお薦めされます。

このような推奨は次の2つの重要な理由のために行っています。これを行わなかった場合、現在の行が予期せず変更された場合にエンド・ユーザーを混乱させてしまいます。また、最初または最後の行、あるいは両方の行がスキップされてしまうため、検出が難しいビジネス・ロジック・エラーが発生してしまうことがあります。

- 現在の行が突然変更されることでエンド・ユーザーが混乱
イテレータ・バインディングは、エンド・ユーザーが行セット内でどの行を現在見ているのかを判断します。プログラムによるロジックがイテレータ・バインディングと同じデフォルト行セットイテレータを使用して行セットを反復している場合、ユーザーが現在選択している行を知らない間に変更してしまい、ユーザーを混乱させてしまうことがあります。

- 最初または最後の行を知らない間にスキップして、検出しにくいビジネス・ロジック・エラーを誘発
イテレータ・バインディングでは、行セット・イテレータを有効な行に強制的に配置して、行セットが空の場合に、UIコンポーネントがデータを表示できるようにします。これによってカスタム・ロジックが、最初の行の前のスロット、または最後の行の後ろのスロットに移動するのを防止する効果があります(イテレータ・バインディングと同じ行セット・イテレータを使用している場合)。具体的には、典型的なwhile (iter.hasNext())行セット反復ループは、次の例に示すように、最初の行ではなく2番目の行を処理することでスキップまたは開始されます。

// Reset the default row set iterator (iter) to the slot before the first row
iter.reset();
// If an iterator binding is bound to the same default row set iterator,
// then it has already forced it to navigate to the first row here instead
// of being on the slot before the first row.
//
// If the row set iterator has only one row, the following will then return false
while (iter.hasNext()) {
// If the row set has more than one row, the first time through the loop
// this call to next() will return the second row rather than the first
// row as expected.
Row curRow = iter.next();
// Do something with current row
}

13.8 アプリケーション・モジュール・メッセージ文字列のカスタマイズ

ADFアプリケーション・モジュールには通常は専用のリソース・バンドルは必要ありません。ただし、カスタム・メッセージ文字列の追加に使用できるカスタム・メッセージ文字列ファイル(.properties)を作成できます。

作成する.propertiesファイルは、完全修飾パッケージ名とカスタム・メソッド例外メッセージによって、属性プロパティを参照できます。たとえば、メッセージ・キーと文字列を次のように定義します。

test.Order.Orderno_LABEL=Order Number
INVALID=You have called the method foo in an invalid way.

リソース・バンドルでメソッドの例外メッセージ用メッセージを定義する場合、カスタム・メソッドは「アプリケーション・モジュールのクライアント・インタフェースでのカスタム・メソッドの公開方法」で説明するように、アプリケーション・モジュール・クライアント・インタフェースに表示する必要があります。

たとえば例外メッセージINVALIDのかわりに、メソッドfoo()のメッセージを定義すると、インタフェースはリソース・バンドルからメッセージを呼び出すように、このメソッドを定義する場合があります。

public void foo() {
ResourceBundleDef r = getResourceBundleDef();
throw new JboException(r,"INVALID",null);
}

13.8.1 アプリケーション・モジュールへのリソース・バンドル・ファイルの追加方法

カスタム・メッセージ文字列を含める.propertiesファイルを作成する場合は、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページのリソース・バンドル・オプションを使用して、「1ファイル当たり1バンドル」オプションを選択します。このオプションは、デフォルトで「1プロジェクト当たり1バンドル」に設定され、プロジェクトごとに1つずつ.propertiesファイルが生成されます。

始める前に:

プロジェクトでのリソース・バンドルの使用方法を理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュール・メッセージ文字列のカスタマイズ」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「アプリケーション・モジュールの作成方法」の説明に従って、該当するアプリケーション・モジュールを作成します。

2. 「リソース・バンドルの使用」の説明に従い、データ・モデル・プロジェクトのプロジェクト・プロパティを設定してファイルごとに1つずつバンドルを生成します。

アプリケーション・モジュールのリソース・バンドルを生成するには:

1. 「アプリケーション」ウィンドウで、リソース・バンドルを生成するアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックし、表示名を入力します。

アプリケーション・モジュールの表示名を追加すると、表示名のメッセージ・キーとともに.propertiesファイルが生成されます。

3. ファイルを保存します。

13.8.2 アプリケーション・モジュールへのリソース・バンドル追加時の処理

アプリケーション・モジュールのリソース・バンドルを生成すると、JDeveloperではコンポーネントのXMLドキュメント・ファイルと同じディレクトリに.propertiesファイルが作成されます。そのカスタムJavaファイルのデフォルト名はAppModuleNameMsgBundle.propertiesになります。

次の例は、.propertiesファイルを参照するアプリケーション・モジュールXMLドキュメントのResourceBundle要素を示しています。

<AppModule
...
<ResourceBundle>
<PropertiesBundle
PropertiesFile=
"oracle.summit.model.services.common.BackOfficeAppModuleMsgBundle"/>
</ResourceBundle>
</AppModule>

13.9 UIクライアントへのカスタム・サービス・メソッドの公開

アプリケーション・モジュール・クラスにpublicカスタム・メソッドを追加する際に、アプリケーションのUIによるそのメソッドの起動を可能にする場合、そのメソッドをアプリケーション・モジュールのUIクライアント・インタフェースに追加する必要があります。

13.9.1 アプリケーション・モジュールのクライアント・インタフェースでのカスタム・メソッドの公開方法

アプリケーション・モジュールのカスタムJavaクラスのpublicメソッドをクライアント・インタフェースに追加するには、アプリケーション・モジュールの概要エディタで「Javaクラス」ページを使用します。

始める前に:

クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

クライアント・インタフェースにカスタム・メソッドを公開するには:

1. 「アプリケーション」ウィンドウで、クライアント・インタフェースを定義するアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし「クライアント・インタフェース」セクションで、「アプリケーション・モジュール・クライアント・インタフェースの編集」ボタンをクリックします。

3. 「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。

4. 「OK」をクリックします。

新しいメソッドが「Javaクラス」ページの「クライアント・インタフェース」セクションに表示されます。

図13-21は、クライアント・インタフェースに追加した複数のpublicメソッドを示しています。

図13-21 アプリケーション・モジュールのクライアント・インタフェースに追加したpublicメソッド

13.9.2 カスタム・サービス・メソッド公開時の処理

カスタム・サービス・メソッドをクライアント・インタフェースに公開すると、図13-22に示すように、アプリケーション・モジュールと同じ名前のJavaインタフェースが、アプリケーション・モジュールが存在するパッケージのcommonサブパッケージに作成されます。summit.modelパッケージのAppModuleという名前のアプリケーション・モジュールでは、このインタフェースはAppModuleという名前になり、summit.model.commonパッケージに作成されます。このインタフェースにより、oracle.jboパッケージのベースApplicationModuleインタフェースが拡張され、アプリケーション・モジュールがApplicationModuleImplクラスから継承するすべてのベース機能へのクライアント・アクセスが可能になります。

図13-22 カスタム・クライアント・インタフェースによるベースApplicationModuleインタフェースの拡張

次の例に示すように、AppModuleインタフェースには、アプリケーション・モジュールのクライアント・インタフェースに配置するように選択したすべてのメソッドのメソッド・シグネチャが含まれています。

package summit.model.appmodule.service.common;
import oracle.jbo.ApplicationModule;
// ---------------------------------------------------------------------
// ---    File generated by ADF Business Components Design Time.
// ---------------------------------------------------------------------
public interface AppModule extends ApplicationModule {
String findOrderAndCustomer(long orderId);
void updateOrderStatus(long orderId, String newStatus);
String findOrderTotal (long orderId);
long createCustomer(String name, String city, Integer countryId);
}

注意:

新しいカスタム・メソッドをクライアント・インタフェースに追加した後で、JDeveloperのコード・インサイトによる状況依存の文補完を使用したときにこのカスタム・メソッドを使用できない場合は、生成されたクライアント・インタフェースの再コンパイルを試行してください。これを実行するには、「アプリケーション」ウィンドウでアプリケーション・モジュールを選択し、「構造」ウィンドウで同じ名前のインタフェースのソース・ファイルを選択して、ポップアップ・メニューから「再ビルド」を選択します。このヒントは、ビュー・オブジェクトにかぎらず、ビュー行に追加された新しいカスタム・メソッドでも参考にしてください。

13.9.3 ビュー・オブジェクトおよびビュー行のクライアント・インタフェースの生成方法

アプリケーション・モジュールのクライアント・インタフェースを生成することに加えて、カスタマイズ可能な他のキー・クライアント・オブジェクトを操作するための強く型付けされたクライアント・インタフェースも生成できます。たとえば、カスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースとビュー行クライアント・インタフェースにそれぞれ追加できます。

始める前に:

クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「単一のデータベース表からのビュー・オブジェクト行の移入」の説明に従い、目的のビュー・オブジェクトを作成します。

ビュー・オブジェクトのクライアント・インタフェースにカスタム・メソッドを公開するには:

1. 「アプリケーション」ウィンドウで、クライアント・インタフェースを定義するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「クライアント・インタフェース」セクションで、「Javaオプションの編集」ボタンをクリックします。

3. 「Java」ダイアログで「ビュー・オブジェクト・クラスの生成」を選択して、「ビュー・オブジェクト・クラスの生成」をクリックします。「OK」をクリックします。

4. 概要エディタで、「クライアント・インタフェース」セクションを開き、「ビュー・オブジェクト・クライアント・インタフェースの編集」ボタンをクリックします。

5. 「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。

6. 概要エディタで、「カスタム行インタフェース」セクションを開き、「ビュー・オブジェクト・カスタム行インタフェースの編集」ボタンをクリックします。

7. 「クライアント・インタフェースの編集」ダイアログで、「使用可能」リストから目的のメソッドを1つ以上選択し、「追加」ボタンをクリックして、それらを「選択済」リストに移動します。

8. 「OK」をクリックします。

「Javaクラス」ページに新しいメソッドが表示されます。

summit.model.viewsパッケージのCustomerViewビュー・オブジェクトに対してカスタム・ビュー・オブジェクトのJavaクラスの生成を可能にし、1つ以上のカスタム・メソッドをビュー・オブジェクト・クライアント・インタフェースに追加すると、図13-23に示すように、CustomerViewImplクラスおよびCustomerViewインタフェースが生成されます。アプリケーション・モジュール・カスタム・インタフェースと同様に、commonサブパッケージに生成されます。

図13-23 カスタム・ビュー・オブジェクト・インタフェースによるベースViewObjectインタフェースの拡張

同様に、同じビュー・オブジェクトに対してカスタム・ビュー行のJavaクラスの生成を有効にして、1つ以上のカスタム・メソッドをビュー行クライアント・インタフェースに追加すると、図13-24に示すように、CustomerViewRowImplクラスおよびCustomerViewRowインタフェースが生成されます。

図13-24 カスタム・ビュー行インタフェースによるベースRowインタフェースの拡張

13.9.4 Oracle ADFモデル・テスターを使用したカスタム・サービス・メソッドのテスト方法

カスタム・アプリケーション・モジュールのメソッドは、「UIクライアントへのカスタム・サービス・メソッドの公開」で説明しているように、クライアント・インタフェースに公開した後にOracle ADFモデル・テスターでテストできます。

始める前に:

クライアント・インタフェースの目的について理解しておくと役立つ場合があります。詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

公開したサービス・メソッドのテスト方法:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを右クリックし、「実行」を選択します。

または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は、「デバッグ」を選択します。「ログ」ウィンドウおよび各種デバッガ・ウィンドウのデバッガ・プロセス・パネルが開きます。Oracle ADFモデル・テスターを使用してデバッグする場合、これらのウィンドウを使用してステータス・メッセージと例外の表示、ソース・コードのステップ・インとステップ・アウト、およびブレークポイントの管理を実行できます。

ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを受信する方法の詳細は、「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。

2. クライアント・インタフェースによって定義されたメソッドのメソッド・テスト用パネルを開くには、次のいずれかを行います。

- アプリケーション・モジュール・クライアント・インタフェース用に公開したメソッドを実行する場合、データ・モデル・ツリーでアプリケーション・モジュール・ノードを選択し、メイン・メニューから「表示」→「操作」を選択します。アプリケーション・モジュール・ノードをダブルクリックして、メソッド・テスト・パネルを開くこともできます。

- ビュー・オブジェクト用のクライアント・インタフェースで公開したメソッドを実行する場合、データ・モデル・ツリーで目的のビュー・オブジェクト・ノードを選択し、メイン・メニューから「表示」→「操作」を選択します。ビュー・オブジェクト・ノードを右クリックして、「操作」を選択することもできます。

3. ビュー・オブジェクト行のクライアント行インタフェースで定義したメソッドのメソッド・テスト・パネルを開くには、データ・モデル・ツリーを展開し、該当するビュー・オブジェクト・ノードを右クリックして、「表の表示」を選択します。次にビュー・インスタンスの概要パネルで目的の行を選択し、メイン・メニューから「表示」→「操作」を選択します。

マスター・ビュー・オブジェクトではビュー行の操作は禁止されているので、データ・モデル・ツリーでマスター・ビュー・インスタンスを選択しないでください。図13-25のように、マスター/ディテール階層が指定されていないディテール・ビュー・インスタンスまたはビュー・インスタンスを必ず選択してください。

ヒント:

ディテール・ビュー・インスタンスの場合、マスター・ビュー・インスタンスを開いて該当する行のディテールに移動できます。Oracle ADFモデル・テスターは、開いた概要パネル内に表示されたデータを、移動先のマスター・ビュー・インスタンスと自動的に同期化します。

図13-25 Oracle ADFモデル・テスターのビュー行操作のメニュー選択

4. メソッド・パネル内で、ドロップダウン・リストから該当するサービスを選択し、メソッド・パラメータとして渡す値を入力し、「実行」をクリックします。

メソッド・テスト・パネルにはパラメータ名が表示され、渡す値をどこに入力すればよいのかがわかるようになっている点に注意してください。これはメソッド・シグネチャが同じデータ型の複数のパラメータを定義している場合には特に便利です。

戻り値(ある場合)とテスト結果を表示できます。Oracle ADFモデル・テスターに表示される結果は、メソッドが正常に実行されたかどうかを示します。

13.9.5 クライアント・インタフェースのメソッド・シグネチャに関する必知事項

クライアント・インタフェースには、次の実装ルールに従うカスタム・メソッドを追加できます。

- メソッドの戻り型がvoid以外の場合、型はシリアライズ可能である必要があります。

- メソッドが任意のパラメータを受け入れる場合、その型はすべてシリアライズ可能である必要があります。

- メソッド・シグネチャにthrows句が含まれる場合、例外はoracle.jboパッケージのJboExceptionのインスタンスである必要があります。

つまり、そのメソッド・シグネチャ内のすべての型はjava.io.Serializableインタフェースを実装する必要があり、チェック済の例外はJboExceptionまたはそのサブクラスである必要があります。メソッドでは、アプリケーション・モジュールのクライアント・インタフェースで非表示になることなく、未チェックの例外(java.lang.RuntimeExceptionまたはそのサブクラス)をスローできます。

java.util.Listの型のメソッド・シグネチャは、インタフェースの実装クラスがシリアライズ可能な限り使用できる点に注意してください。たとえば、java.util.ArrayListおよびjava.util.LinkedListは両方ともシリアライズ可能なクラスです。同じ要件がコレクション内の要素型に適用されます。インタフェースを実装しているクラスをインスタンス化したにもかかわらず、java.io.Serializableインタフェースを実行しなかった場合、ADFビジネス・コンポーネント・ランタイムはエラーを生成します。

注意:

アプリケーション・モジュール・クラスに追加したメソッドが「使用可能」リストに表示されない場合は、メソッド実装ルールのいずれか違反していないかをまず確認してください。適切なメソッドと判断できる場合は、アプリケーション・モジュールの概要エディタに再移動する前に、アプリケーション・モジュール・クラスの再コンパイルを試行してください。

13.9.6 データ・モデルからの情報の引渡しに関する必知事項

アプリケーション・モジュールのカスタム・メソッドのプライベート実装では、生成されたアクセッサ・メソッドを使用してデータ・モデル内のビュー・オブジェクト・インスタンスを簡単に参照できます。ビュー・オブジェクトでgetCurrentRow()メソッドをコールすると、クライアント・ユーザー・インタフェースでビュー・オブジェクトの現在行として認識されている行にアクセスできます。その結果、アプリケーション・モジュールのビジネス・サービス・メソッドの記述中には、クライアントからのパラメータの引渡しが不要な場合があります。これは、同じアプリケーション・モジュールのデータ・モデルにある他のビュー・オブジェクト・インスタンスの現在行から値を渡すのみの場合に該当します。

たとえば、次の例にあるカスタム・アプリケーション・モジュール・メソッドではパラメータを受け入れません。createOrderItem()メソッドはgetGlobals().getCurrentRow()を内部でコールし、Globalsビュー・オブジェクト・インスタンスの現在行にアクセスします。次に、強く型付けされたアクセッサ・メソッドを行で使用してDescriptionおよびLineItemId属性の値にアクセスし、この値を、新規作成されたOrderItemエンティティ・オブジェクト行の対応する属性の値として設定します。

// In AppModuleImpl.java, createOrderItem() method
GlobalsRowImpl globalsRow = (GlobalsRowImpl)getGlobals().getCurrentRow();
newOrder.setDescription(globalsRow.getDescription());
newOrder.setLineItemId(globalsRow.getLineItemId());

13.10 アプリケーション・モジュールのクライアント・インタフェースのプログラム的操作

メソッドをアプリケーション・モジュールのクライアント・インタフェースに公開したら、それらのメソッドをクライアントから起動できます。

13.10.1 アプリケーション・モジュールのクライアント・インタフェースのプログラム的な操作方法

アプリケーション・モジュールのクライアント・インタフェースをプログラム的に操作するには、次の手順を実行します。

- ApplicationModuleを、特定のクライアント・インタフェースにキャストします。

- インタフェース上のいずれかのメソッドをコールします。

注意:

この項では、説明を簡潔にするために、カスタム・アプリケーション・モジュールのインタフェースの操作のみを重視しますが、これと同じダウンキャスト方法は、ViewObjectインタフェースをCustomersなどのビュー・オブジェクト・インタフェースとして使用するクライアントや、RowインタフェースをCustomersRowなどのカスタム・ビュー行インタフェースとして使用するクライアントにも有効です。

次の例は、これらの2つの手順を実行するTestClientEntityクラスを示しています。「static mainメソッドを使用したカスタム・アプリケーション・モジュールのテスト方法」で説明しているように、このクラスのmain()メソッドを使用して、アプリケーション・モジュール・メソッドをテストすることもできます。ここでは、クライアントからAppModuleクライアント・インタフェースを使用して同じメソッドをすべてコールするために、これを使用します。

注意:

oracle.jboパッケージのデフォルトのApplicationModuleインタフェースを使用してアプリケーション・モジュールを操作している場合は、カスタム・メソッドにアクセスできません。この例では、特定のカスタム・インタフェース(AppModuleインタフェースなど)に、アプリケーション・モジュール・インスタンスをキャストします。

次の例の基本ロジックはこれらの手順に従います。

1. 注文1011の合計を取得します。

2. 注文1011の顧客名を取得します。

3. 1011の注文ステータスを「Y」の値に設定します。

4. 顧客名がnullの新しい顧客を作成します。

5. 顧客名を付けて新しい顧客を作成し、新しく割り当てた顧客IDを表示します。

package oracle.summit.model.appmodule.client;

import oracle.jbo.client.Configuration;
import oracle.jbo.*;
import oracle.jbo.domain.Number;
import oracle.jbo.domain.*;

import oracle.summit.model.appmodule.service.common.AppModule;

public class TestClientCustomInterface {
public static void main(String[] args) {
String amDef = "oracle.summit.model.appmodule.service.AppModule";
String config = "AppModuleLocal";

/*
* This is the correct way to use application custom methods
* from the client, by using the application module's automatically-
* maintained custom service interface.
*/
AppModule service =
(AppModule)Configuration.createRootApplicationModule(amDef,config);
String total = service.findOrderTotal(1011);
System.out.println("Total for Order # 1011 = " + total);
String custName = service.findOrderAndCustomer(1011);
System.out.println("Customer for Order # 1011 = " + custName);
try {
service.updateOrderStatus(1011,"Y");
}
catch (JboException ex) {
System.out.println("ERROR: "+ex.getMessage());
}
long id = 0;
try {
id = service.createCustomer(null, "Oakville", 14);
}
catch (JboException ex) {
System.out.println("ERROR: "+ex.getMessage());
}
id = service.createCustomer("Oakville Curling Club", "Oakville", 14);
System.out.println("New customer created successfully with id = " + id);
Configuration.releaseRootApplicationModule(service,true);
}
}

カスタム・アプリケーション・モジュール・クラスを実行すると、前述の例のmain()メソッドがコールされ、次の出力が生成されます。

Total for Order # 1011 = 99.99
Customer for Order # 1011 = Customer: Zibbers, Location: Boston
ERROR: JBO-27014: You must provide a value for Name.
New customer created successfully with id = 133

顧客名をnullとしてfindOrderAndCustomer()をコールしようとした初回の試みでは、Customerエンティティ・オブジェクトのName属性に対する組込み必須検証が原因で例外が発生しています。

13.10.2 実行時に行われる処理: アプリケーション・モジュールのクライアント・インタフェースにアクセスする場合

アプリケーション・モジュールにアクセス中のクライアント・レイヤーはJava EEアーキテクチャの同一層にあるため、アプリケーション・モジュールはローカル・モードと呼ばれるモードでデプロイされます。ローカル・モードでは、クライアント・インタフェースはカスタム・アプリケーション・モジュールのJavaクラスによって直接実装されます。JavaServer FacesアプリケーションのWeb層のアプリケーション・モジュールにアクセスするたびに、ローカル・モードでアプリケーション・モジュールにアクセスします。

13.10.3 Fusion Webアプリケーションでのアプリケーション・モジュール・クライアント・インタフェースへのアクセス方法

oracle.jbo.clientパッケージのConfigurationクラスでは、テスト用のアプリケーション・モジュール・インスタンスを非常に簡単に入手できます。これにより、JUnit回帰テスト・フィクスチャの一部となるテスト・クライアント・プログラム(「JUnitを使用した回帰テスト」を参照)のように、テスト・クライアント・プログラムの記述が簡単になります。

ベスト・プラクティス

Fusion Webアプリケーションに対しては、常にバインディング・レイヤーを使用してアプリケーション・モジュールにアクセスする必要があります。開発者はアプリケーション・モジュールにアクセスするあらゆる場合に、このクラスのcreateRootApplicationModule()メソッドとreleaseApplicationModule()メソッドを使用しがちですが、ビュー・レイヤーにおける最善の方法はADFモデル・レイヤーの宣言機能を使用することです。

データをバインドするためのADFモデル・レイヤーを使用してFusion Webアプリケーションを操作している場合、JDeveloperにより、ユーザー・インタフェース・プロジェクトにADFBindingFilterというサーブレット・フィルタが構成されます。このフィルタにより、宣言的なバインディング・メタデータに基づく適切なアプリケーション・モジュール・インスタンスの自動的な取得およびリリースが調整され、ユーザー・インタフェース・プロジェクトのページ定義ファイルで指定された既知のアクション・バインディングまたはイテレータ・バインディングを使用して、サービスをデータ・コントロールとして検索できるようになります。ADFバインディング・コンテナ、データ・コントロール、ページ定義ファイルおよびADFバインディングの詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。ここでは、ADFアクション・バインディングまたはADFイテレータ・バインディングの名前を指定することで、このDCBindingContainerからアプリケーション・モジュールのクライアント・インタフェースにアクセスできることを覚えておけば十分です。次の例(アクション・バインディングおよびイテレータ・バインディング)に示すように、JSFマネージドBeanのカスタム・クライアント・インタフェースで、バインディング・コンテキストを参照してメソッドをコールできます。

アクション・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、次の基本手順に従います(後に例を示しています)。

1. ADFバインディング・コンテナにアクセスします。

2. 名前の付いたアクション・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルに提供されている任意のアクション・バインディング名を使用します。)

3. データ・コントロールをアクション・バインディングから名前で取得します。

4. アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。

5. アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。

6. クライアント・インタフェースにあるいずれかのメソッドをコールします。

package oracle.summit.model.viewobjects;

import oracle.summit.model.appmodule.service.common.SummitAppModule;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCDataControl;
import oracle.jbo.ApplicationModule;
import oracle.jbo.uicli.binding.JUCtrlActionBinding;
public class YourBackingBean {
public String commandButton_action() {
// Example using an action binding to get the data control
public String commandButton_action() {
// 1. Access the binding container
DCBindingContainer bc = (DCBindingContainer)getBindings();
// 2. Find a named action binding
JUCtrlActionBinding action =
(JUCtrlActionBinding)bc.findCtrlBinding("SomeActionBinding");
// 3. Get the data control from the iterator binding (or method binding)
DCDataControl dc  = action.getDataControl();
// 4. Access the data control's application module data provider
ApplicationModule am = (ApplicationModule)dc.getDataProvider();
// 5. Cast the AM to call methods on the custom client interface
SummitAppModule service = (SummitAppModule)am;
// 6. Call a method on the client interface
service.doSomethingInteresting();
return "SomeNavigationRule";
}
}

イテレータ・バインディングを使用して、アプリケーション・モジュールのカスタム・インタフェースにアクセスするには、次の基本手順に従います(後に例を示しています)。

1. ADFバインディング・コンテナにアクセスします。

2. 名前の付いたイテレータ・バインディングを検索します。(ユーザー・インタフェース・プロジェクトのページ定義ファイルないの任意のイテレータ・バインディング名を使用します。)

3. データ・コントロールをイテレータ・バインディングから名前で取得します。

4. アプリケーション・モジュールのデータ・プロバイダにデータ・コントロールからアクセスします。

5. アプリケーション・モジュールをそのクライアント・インタフェースにキャストします。

6. クライアント・インタフェースにあるいずれかのメソッドをコールします。

package oracle.summit.model.viewobjects;

import oracle.summit.model.appmodule.service.common.SummitAppModule;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCDataControl;
import oracle.adf.model.binding.DCIteratorBinding;
import oracle.jbo.ApplicationModule;
public class YourBackingBean {
public String commandButton_action() {
// Example using an iterator binding to get the data control
public String commandButton_action() {
// 1. Access the binding container
DCBindingContainer bc = (DCBindingContainer)getBindings();
// 2. Find a named iterator binding
DCIteratorBinding iter = bc.findIteratorBinding("SomeIteratorBinding");
// 3. Get the data control from the iterator binding
DCDataControl dc  = iter.getDataControl();
// 4. Access the data control's application module data provider
ApplicationModule am = (ApplicationModule)dc.getDataProvider();
// 5. Cast the AM to call methods on the custom client interface
SummitAppModule service = (SummitAppModule)am;
// 6. Call a method on the client interface
service.doSomethingInteresting();
return "SomeNavigationRule";
}
}

これらのバッキングBeanの例は、次の例に示すヘルパー・メソッドに依存します。

public BindingContainer getBindings() {
{
return BindingContext.getCurrent().getCurrentBindingsEntry();
}

ADFアクションに宣言的にバインドされるボタンをオーバーライドしてバッキングBeanクラスを作成すると、このメソッドがクラス内に自動的に生成されます。それ以外の場合は、ヘルパー・メソッドをクラスに手動で追加する必要があります。

13.11 組込みフレームワーク・メソッドの上書き

ApplicationModuleImplベース・クラスには、この機能を実装する組込みメソッドが多数含まれています。「ADFビジネス・コンポーネントのよく使用されるメソッド」は、カスタム・アプリケーション・モジュール・クラスでよく記述、使用およびオーバーライドする最も一般的なコードのクイック・リファレンスとなっていますが、この項では、これらの組込みフレームワーク・メソッドの1つをオーバーライドしてデフォルトの動作を拡張する基本手順の理解を深めることを重視しています。

13.11.1 組込みフレームワーク・メソッドのオーバーライド方法

アプリケーション・モジュールの組込みフレームワーク・メソッドをオーバーライドするには、「メソッドのオーバーライド」ダイアログを使用して、メイン・メニューからアプリケーション・モジュールのJavaクラスを開きます。

始める前に:

アプリケーション・モジュールのベース・クラスに関する知識があると役立つ場合があります。詳細は、「組込みフレームワーク・メソッドのオーバーライド」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従い、目的のアプリケーション・モジュールを作成します。

アプリケーション・モジュールのフレームワーク・メソッドをオーバーライドするには:

1. 「アプリケーション」ウィンドウで、フレームワーク・メソッドをオーバーライドするアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、カスタマイズするアプリケーション・モジュールのJavaクラスにリンクされたファイル名をクリックします。

ソース・エディタが開いて、クラス・ファイルが表示されます。

3. メイン・メニューから、「ソース」を選択し、次に「メソッドのオーバーライド」を選択します。

「ソース」メニューが表示されていない場合は、目的のJavaクラス・ファイルが開いており、ソース・エディタが表示されていることを確認します。

4. 「メソッドのオーバーライド」ダイアログで、リストをスクロールして目的のメソッドを特定するか、あるいはメソッド名の最初の数文字を入力してインクリメンタル検索を実行します。

5. メソッドを1つ以上選択します。

「メソッドのオーバーライド」ダイアログでは、任意の数のメソッドを選択して同時にオーバーライドできます。

たとえば、図13-26に示すように、新規ユーザー・セッションでアプリケーション・モジュールのサービス・コンポーネントの操作を初めて開始したときに、アプリケーション・モジュールのprepareSession()メソッドをオーバーライドしてデフォルトの機能を拡張する場合、prepareSession(Session)メソッドの隣のチェック・ボックスを選択します。

図13-26 組込みフレームワーク・メソッドのオーバーライド

6. 「OK」をクリックします。

13.11.2 組込みフレームワーク・メソッドをオーバーライドした場合の処理

「メソッドのオーバーライド」ダイアログを閉じると、図13-27に示すように、オーバーライドしたメソッドにカーソルが置かれた状態でソース・エディタに戻ります。メソッドには、super.prepareSession()をコールする単一行が表示されています。これは、ベース・クラスがこのメソッドに対して通常であれば実行したはずのデフォルトの動作を起動するJava構文です。カスタム・アプリケーション・モジュール・クラスでこの行の前または後にコードを追加して、デフォルトの機能の前または後のデフォルトの動作を拡張できます。

図13-27 オーバーライドしたメソッドに関してソース・エディタのマージンに表示されるフィードバック

「メソッドのオーバーライド」ダイアログを使用してメソッドをオーバーライドする場合、ソース・エディタにより、オーバーライドしたメソッドの直前にJDK @Override注釈が挿入されます。この注釈により、アプリケーション・モジュール・クラスのメソッドがスーパークラスのメソッドのシグネチャと一致しない場合は、コンパイル時にエラーが生成されます。

クラスにメソッド名を追加してスーパークラス内のメソッドをオーバーライドする場合は注意が必要です。オーバーライドするベース・クラス・メソッドと完全に同一のシグネチャが必要です。@Override注釈は必ずメソッドの直前に追加してください。これにより、メソッドがスーパークラスのメソッドのいずれのシグネチャとも一致しない場合は、コンパイル時にエラーが生成されます。スーパークラスの実装をコールするかわりにメソッドのコードを記述する場合は、抑止または置換する組込みコードについて理解しておく必要があります。

13.11.3 prepareSession()をオーバーライドして新規ユーザー・セッション用のアプリケーション・モジュールを設定する方法

prepareSession()メソッドは、新しいユーザー・セッションで初めて使用されるときにアプリケーション・モジュールによって起動されるため、カスタム・アプリケーション・モジュール・クラスをオーバーライドし、アプリケーション・モジュールを使用する新しいユーザーごとに固有のセットアップ・タスクを実行する場合に便利なメソッドです。次の例は、接続されたユーザーのデータベース・クライアント情報を指定するsetApplicationInfo()ヘルパー・メソッドを起動するAppModuleImplクラス内の、オーバーライドされたprepareSession()メソッドを示しています。

public class AppModuleImpl extends SummitApplicationModuleImpl
implements AppModule {
...

@Override
protected void prepareSession(Session session) {
super.prepareSession(session);
setApplicationInfo ("AppModuleImpl", "prepareSession");
String username = this.getUserPrincipalName();
System.out.println(username);
}

protected void setApplicationInfo(String clientInfo, String clientIdentifier){
DBTransactionImpl dbti = (DBTransactionImpl)getDBTransaction();
CallableStatement statement =
dbti.createCallableStatement("BEGIN "
+ "DBMS_APPLICATION_INFO.SET_CLIENT_INFO (client_info => :client_info);"
+ "DBMS_SESSION.SET_IDENTIFIER (:client_identifier);"
+ "END;", 0);
try {
statement.setString("client_info", clientInfo);
statement.setString("client_identifier", clientIdentifier);
statement.execute();
} catch (SQLException sqlerr) {
throw new JboException(sqlerr);
} finally {
try {
if (statement != null) {
statement.close();
}
} catch (SQLException closeerr) {
throw new JboException(closeerr);
}
}
}
}

13.12 アプリケーション・モジュールからのWebサービスのコール

サービス指向アーキテクチャでは、アプリケーション・モジュールに基づいていないWebサービスから提供される機能をOracle ADFアプリケーション・モジュールで利用する必要がある場合もあります。Webサービスは、任意のプログラミング言語で実装し、ネットワーク上の任意のサーバーに配置できます。各Webサービスでは、言語に依存しない標準的なXMLフォーマットで記述することにより、一連の該当するメソッドをそのAPI内で指定します。このXMLドキュメント(構文は、Web Services Description Language (WSDL)に準拠)を使用すると、Webサービスのメソッドの名前に加えて、それらのメソッドが予期するパラメータや実際の戻り値のデータ型も、JDeveloperで理解できます。

注意:

アプリケーション・モジュールはWebサービスとして公開し、デプロイ済のFusion Webアプリケーションのモジュール間で使用することもできます。外部サービスを使用したADFビジネス・コンポーネントの再利用の詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。

JDeveloperに組み込まれているWebサービス・ウィザードを使用すると、そのようなタスクを簡単に実行できます。該当するウィザードを使用してWebサービス・プロキシ・クラスを作成し、ローカルなJavaオブジェクトに追加するメソッド・コールを使用してサービスをコールします。

13.12.1 外部サービスのプログラム的なコール方法

アプリケーション・モジュールからWebサービスをコールするには、起動するサービスのWebサービス・プロキシ・クラスを作成します。Webサービス・プロキシとは、該当するアプリケーション内のWebサービスを表す、生成されたJavaクラスのことです。該当するWebサービスのサービスURLをカプセル化し、サービスをコールをするための低レベルの詳細情報を処理します。

Webサービスを使用するには、該当するWSDLドキュメントを特定するURLを知る必要があります。たとえば、WSDLドキュメントは、電子メールの添付ファイルとして受信し、ローカルのハード・ドライブに保存した場合、URLは次のようになります。

file:///D:/temp/SomeService.wsdl

また、URLは、次のようなHTTPベースのURLの場合もあります。

http://someserver.somecompany.com/SomeService/SomeService.wsdl

一部のWebサービスの場合、そのWSDLドキュメントは、サービスURLを変更する特殊なパラメータを使用して利用可能になります。たとえば、http://someserver.somecompany.com/SomeServiceのHTTPアドレスでリクエストを受信することが期待されているWebサービスの場合は、同一のURLの末尾に次のような追加のパラメータを付けて、対応するWSDLドキュメントを公開することもあります。

http://someserver.somecompany.com/SomeService?WSDL

標準が確立されていないため、WSDLドキュメントに対する正確なURLを知っておくのみで十分です。URL情報があれば、該当するサービスをコールするためのWebサービス・プロキシ・クラスを作成できます。

ADFビジネス・コンポーネント・サービスには次の形式のサービスへのURLがあります。

- 統合されたWebLogic Server上でのURLの形式はhttp://host:port/EJB-context-root/@WebService-name?WSDLで、たとえば、次のようになります。

http://localhost:8888/EJB-SummitService/SummitService?WSDL

- Oracle WebLogic Server。URLの形式はhttp://host:port/context-root/@WebService-name?WSDLで、たとえば、次のようになります。

http://localhost:8888/SummitService/SummitService?WSDL

Webサービス・プロキシ・クラスは、WebサービスのパブリックAPIに対応する一連のJavaメソッドを表します。Webサービス・プロキシ・クラスを使用すると、Webサービス内の任意のメソッドを、他の任意のローカルなJavaクラスのメソッドの場合と同じ方法でコールすることができます。

プロキシ・クラスを使用してアプリケーション・モジュールからWebサービスをコールするには、次の作業を実行します。

1. WebサービスのWebサービス・プロキシ・クラスを作成します。コールする必要のあるWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・クライアントおよびプロキシの作成ウィザードを使用します。

2. プロキシ・クラスにメソッドを実装し、目的のWebサービスにアクセスします。

3. 該当するWebサービス・プロキシ・クラスのインスタンスをアプリケーション・モジュール内で作成し、Webサービス・プロキシ・オブジェクト上でメソッドを1つ以上起動します。

13.12.1.1 サービスにプログラム的にアクセスするためのWebサービス・プロキシ・クラスの作成

コールするWebサービス用のWebサービス・プロキシ・クラスを作成するには、Webサービス・プロキシ作成ウィザードを使用します。

始める前に:

Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

サービスにプログラム的にアクセスするためにWebサービス・プロキシ・クラスを作成するには:

1. 「アプリケーション」ウィンドウで、Webサービス・プロキシを作成するプロジェクトを右クリックし、「新規」→「Webサービス・クライアントおよびプロキシ」を選択します。

2. 「Webサービス・クライアントおよびプロキシの作成」ウィザードの「Webサービス記述の選択」ページで、アプリケーション内でコールするサービスのWSDLのURLを入力し、フィールドからタブアウトします。

ウィザードの「次へ」が有効になっている場合は、WSDLドキュメントをJDeveloperが認識し、検証済です。「次へ」ボタンが有効にならない場合は、URLの検証後に問題を修正してこの手順を繰り返します。

3. ウィザードの以降のページに進み、Webサービス・プロキシの詳細を指定します。

4. 「終了」をクリックします。

13.12.1.2 サービスを起動するためのWebサービス・プロキシ・テンプレートのコール

Webサービス・プロキシを作成したら、目的のWebサービスにアクセスするためにプロキシ・クラスにメソッドを実装する必要があります。

始める前に:

Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「サービスにプログラム的にアクセスするためのWebサービス・プロキシ・クラスの作成」の説明に従い、目的のWebサービス・プロキシ・クラスを作成します。

サービスを起動するためにWebサービス・プロキシ・テンプレートをコールするには:

1. ソース・エディタでport_nameClient.javaという名前のプロキシ・クライアント・クラスを開き、メイン・メソッド内にある// Add your own code to call the desired methodsというコメントを検索します。

2. 適切なコードを追加してWebサービスを起動します。

3. JDeveloperにより生成されたクライアント・モジュール・クラスの完全セットをデプロイし、このクラスをアプリケーションで参照します。

13.12.1.3 アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール

Webサービス・プロキシ・クラスが生成されると、次の例に示すように、アプリケーション・モジュールのカスタム・メソッド内で使用できます。該当メソッドによりWebサービス・プロキシ・クラスのインスタンスが作成され、その結果についてWebサービス・プロキシ・クラスからWebサービス・メソッドがコールされます。

// In YourModuleImpl.java
public void performSomeApplicationTask(String symbol) throws Exception {
// application-specific code here
:
// Create an instance of the web service proxy class
StockQuoteServiceSoapHttpPortClient svc =
new StockQuoteServiceSoapHttpPortClient();
// Call a method on the web service proxy class and get the result
QuoteInfo quote = svc.quoteForSymbol(symbol);
float currentPrice = quote.getPrice();
// more application-specific code here
}

13.12.2 Webサービス・プロキシの作成時の処理

JDeveloperは、WSDLドキュメント内で検出されたWebサービス・ポートの名前を反映した名前を使用して、ユーザーが指定したパッケージ内でWebサービス・プロキシ・クラスを生成します。Webサービス・ポート名は、人間が判読できるStockQuoteServiceのような名前の場合もあれば、StockQuoteServiceSoapHttpPortのようなわかりにくい名前の場合もあります。このポート名は、ユーザーが使用中のWebサービスを公開した開発者によって決定されます。たとえば、サービスのポート名がStockQuoteServiceSoapHttpPortであると仮定すると、JDeveloperはStockQuoteServiceSoapHttpPortClientという名前のWebプロキシ・クラスを生成します。

Webサービス・プロキシは、「アプリケーション」ウィンドウ内で、WebServiceNameProxyという単一の論理ノードとして表示されます。たとえば、StockQuoteService WebサービスのノードはStockQuoteServiceProxyという名前で「アプリケーション」ウィンドウに表示されます。JDeveloperでは、プロキシ・クラスの生成処理の一部として、サーバーの起動に使用するメインのWebサービス・プロキシ・クラスのみでなく、多数の補助クラスとインタフェースも生成されます。これらのファイルは、「アプリケーション」ウィンドウ内のWebServiceNameProxyノードの下に表示されます。生成されたファイルは、Webサービスを起動するための低レベルの実装の一部で使用されます。

生成された補助クラスのうち、参照する必要のあるものは、構造化されたWebサービス・パラメータまたは戻り型を保持するように作成されるクラスのみです。たとえば、WebサービスStockQuoteServiceのquoteForSymbol()メソッドが、Stringパラメータを1つ受け取り、株の時価を表す浮動小数点値を1つ返すものとします。Webサービスの設計者がシンプルな浮動小数点数を1つ返すように選択すると、Webサービス・プロキシ・クラスは次のような対応するメソッドを持つことになります。

public float quoteForSymbol(String symbol)

また、Webサービスの設計者が結果として複数の情報を返す方が便利であると考える場合は、サービスのWSDLファイルには、包含される複数の要素を記述する名前付き構造の定義が1つ含まれることになります。たとえば、シンボル名と時価が結果としてサービスから返されるとします。これら2つのデータ要素を含めるために、WSDLファイルでは、文字列型のsymbolという名前の要素と浮動小数点型のpriceという名前の要素を持つQuoteInfoという名前の構造を1つ定義する場合もあります。このような状況でJDeveloperがWebサービス・プロキシ・クラスを生成する場合、Javaメソッド・シグネチャは次のようになります。

public QuoteInfo quoteForSymbol(String symbol)

戻り型QuoteInfoでは、Webサービス・プロキシ実装を構成する補助クラスの1つを参照します。それは、WSDLドキュメントの中で定義されている構造の名前と型がプロパティに反映されているシンプルなBeanです。同様に、Webサービスが受け取るパラメータ値が構造または構造の配列である場合は、それに対応する生成されたBeanを使用して、それらの構造をJavaコード内で操作する必要があります。

13.12.3 新しいWebサービス接続の作成方法

Webサービス・プロキシの開発後、プロキシの接続を追加で作成し、テストやデプロイメントで使用できます。たとえば、テスト用にユーザー名とパスワードを含む接続を作成できます。

接続情報はアプリケーション内の他の接続と一緒にconnections.xmlファイルに保存されます。エンドポイントURLの抽象化によって、Enterprise Managerを使用したデプロイ後に、クライアント・コードを変更せずに接続を編集することもできます。

始める前に:

Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールからのWebサービスのコール」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーション・モジュールの追加機能」を参照してください。

Webサービス接続の作成方法:

1. 「アプリケーション」ウィンドウで、Webサービス・プロキシを右クリックし、「ADF Webサービス接続を作成しています」を選択します。

「新規ADF Webサービス接続」ダイアログに、選択したプロキシに関連付けられた接続のデフォルト設定が表示されます。

2. 必要に応じて接続情報を変更し、「OK」をクリックします。

警告:

既存の接続と同じ名前で新しいWebサービス接続を作成すると、既存の接続が新しい情報によって上書きされます。

新しいWebサービス接続の作成後、この接続を使用するようにクライアントを変更できます。次の例に示すようなコードを使用して、クライアントから接続にアクセスできます。

Context ctx = ADFContext.getCurrent().getConnectionsContext();

WebServiceConnection wsc = (WebServiceConnection) ctx.lookup("MyAppModuleService");

MyAppModuleService proxy = wsc.getJaxWSPort(MyAppModuleService.class);

lookup()メソッドに渡す引数は、Webサービス接続に渡した名前です。この例ではMyAppModuleServiceです。

13.12.4 実行時に行われる処理: Webサービス・プロキシによるWebサービスの起動処理

アプリケーション・モジュールからWebサービスを起動する場合、Webサービス・プロキシ・クラスは、「SOAP」で説明したXMLベースのWebサービス・プロトコルを使用する際の低レベルの詳細処理を実行します。具体的には、次の処理を実行します。

- メソッドの起動を表すXMLドキュメントを作成

- メソッド引数をXMLにパッケージング

- HTTP POSTリクエストを使用してXMLドキュメントをサービスURLに送信

- Webサービスから受信したXMLエンコード・レスポンスのパッケージングを解除

起動対象のメソッドが戻り値を持つ場合は、アプリケーション・モジュール・コード内で操作できるように、適切な型のオブジェクトとして受信します。

13.12.5 Webサービス・プロキシに関する必知事項

アプリケーション内でWebサービス・プロキシを実装している場合、「try-catch」ブロックを使用してWebサービス例外を処理するか、Webサービス・プロキシ・クラスでアプリケーション・モジュールを起動します。以降の項で、この機能や、Webサービス・プロキシに関するその他の機能の詳細を説明します。

13.12.5.1 try/catchブロックによるWebサービス例外の処理

生成されたWebサービス・プロキシ・クラスを使用すると、リモートWebサービスの起動は、ローカルJavaクラス内のメソッドをコールするのと同じように簡単になります。その場合に注意が必要な唯一の違いは、HTTPリクエストに関与する問題が存在する場合にWebサービス・メソッドのコールが失敗する可能性がある点です。Webサービス・プロキシに対して実行するメソッド・コールでは、適切なtry...catchブロックを使用してコールをラップすることにより、リクエストの失敗に備える必要があります。次の例では、Webサービス例外を検出することにより、前述(「アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール」)の簡単な例を改善しています。この場合は該当するエラーをJboExceptionとして再スローしているだけですが、アプリケーションではさらに適切なエラー処理を実装することもできます。

// In YourModuleImpl.java
public void performSomeApplicationTask(String symbol) {
// application-specific code here
// :
QuoteInfo quote = null;
try {
// Create an instance of the web service proxy class
StockQuoteServiceSoapHttpPortClient svc =
new StockQuoteServiceSoapHttpPortClient();
// Call a method on the web service proxy class and get the result
quote = svc.quoteForSymbol(symbol);
}
catch (Exception ex) {
throw new JboException(ex);
}
float currentPrice = quote.getPrice();
// more application-specific code here
}

13.12.5.2 アプリケーションモジュールとWebサービスでのトランザクションの分離

参照情報にアクセスするために使用するWebサービスもあります。また、データを変更するためにコールするサービスもあります。このデータ変更は、社内の自分のチームまたは別のチームのメンバーによってサービスが記述された場合、自社のデータベースに存在する可能性があります。Webサービスが自社のファイアウォールの外部にある場合は、変更対象のデータベースは、当然、別の会社によって管理されます。

いずれの場合でも、起動するWebサービスによって実行されるデータ変更は、アプリケーション・モジュールの現在の作業ユニットとは無関係な独自のトランザクションによって実行されるということを理解しておくことが重要です。たとえば、データを変更するWebサービスを起動した後、rollback()をコールしてアプリケーション・モジュールの現在の作業ユニット内で保留中の変更を取り消しても、該当するプロセス内でコールしたWebサービスによって実行される変更に影響はありません。対応するWebサービス・メソッドを起動して、補正用の変更を実行し、アプリケーション・モジュールのトランザクションのロールバックを無効にする必要がある場合があります。

13.12.5.3 ブラウザ・プロキシ情報の設定

コール対象のWebサービスが自社ファイアウォールの外部にある場合は、HTTPプロキシ・サーバーを使用できるような適切な構成にJavaシステム・プロパティが設定されていることを確認する必要があります。構成する必要のあるJavaシステム・プロパティは、次のとおりです。

- http.proxyHost - プロキシ・サーバーの名前を設定します。

- http.proxyPort - プロキシ・サーバーのHTTPポート番号(80の場合が多い)を設定します。

- http.nonProxyHosts - プロキシ・サーバーを使用しないサーバーを縦線で区切ってリストで指定します(オプション。例 - localhost|127.0.0.1|*.yourcompany.com)。

JDeveloperでは、「設定」ダイアログの「Webブラウザとプロキシ」ページでHTTPプロキシ・サーバーを構成できます。アプリケーションを実行する際、JDeveloperの-Dコマンド行オプションを使用すると、このダイアログで指定した設定値に基づき、前述の3つのシステム・プロパティを設定できます。

13.12.5.4 Webサービス・プロキシ・クラスを使用したアプリケーション・モジュールの起動

Webサービス・プロキシ・クラスを使用してOracle ADFサービスベースのアプリケーション・モジュールを起動すると、コール側コンポーネントとコールしているサービスがコロケートしている場合にコールを最適化できなくなります。別の方法として、「アプリケーション・モジュールによるSOAP Webサービスの作成」で説明しているサービス・インタフェースによるアプローチを使用することもできます。

14 アプリケーション・モジュール・ビュー・インスタンスの共有

この章では、ADFビジネス・コンポーネント・データ・モデル・プロジェクトを整理し、参照表やフラット・ファイルなどの静的データソースからアクセスされる読取り専用データを最も効率的に共有する方法について説明します。また、アプリケーション・レベルで共有するADFアプリケーション・モジュールとセッション・レベルで共有するADFアプリケーション・モジュールの違いを説明します。

この章の内容は次のとおりです。

- 共有アプリケーション・モジュールについて

- アプリケーション・モジュール・インスタンスの共有

- ベース・ビュー・オブジェクトを参照表で使用するための定義

- 共有サービスのビュー・インスタンスへのアクセス

- 共有アプリケーション・モジュールでのビュー・オブジェクト・インスタンスのテスト

14.1 共有アプリケーション・モジュールについて

Webアプリケーションでは、セッション全体で必要とされる、あまり頻繁に変更されないデータがよく使用されます。この種の統計データの例は、アプリケーション・ユーザー・インタフェースの検索リストに表示されることがあります。アプリケーションが静的データにアクセスするたびに、すべてのリクエストにおける各アプリケーション・セッションのデータベースから静的データ・キャッシュが再移入されると、不要なオーバーヘッドが発生する場合があります。ADFビジネス・コンポーネントで作業を行う場合にパフォーマンスを最適化するためには、一般的にセッションおよびリクエスト間で再使用する共有静的データをキャッシュします。共有アプリケーション・モジュールの作成によって、複数のセッションのリクエストで、Webサーバー仮想マシン用のアプリケーション・プールで永続的に管理できる、単一のアプリケーション・モジュール・インスタンスを共有できます。

14.1.1 共有アプリケーション・モジュールのユースケースと例

ADFビジネス・コンポーネントのビュー・アクセッサは、エンティティ・オブジェクト属性(またはビュー・オブジェクト)から、同じアプリケーション・ワークスペースのリンク先ビュー・オブジェクトまたは共有ビュー・インスタンスをポイントする、値のアクセッサ・オブジェクトです。

異なるアプリケーション・モジュールのビュー・オブジェクトにアクセスするこの機能により、ビュー・アクセッサは次の場合に特に便利です。

- エンティティ・オブジェクトの属性に設定する検証規則。たとえば、エンド・ユーザーが登録フォームに記入する場合、個々の検証規則により肩書、配偶者の有無、連絡先コードを、共有アプリケーション・モジュールのビュー・インスタンスにより問合せされた参照表データに対して検証できます。

- ビュー・オブジェクトの属性に対して有効にする値リスト(LOV)。たとえば、実行時にエンド・ユーザーに値リストを表示する場合です。

14.1.2 共有アプリケーション・モジュールの追加機能

共有アプリケーション・モジュールを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- 実行時のパフォーマンスを向上させるためのアプリケーション・モジュール・インスタンス構成の詳細は、「Fusion Webアプリケーションでの状態管理の使用」および「アプリケーション・モジュール・プールのチューニング」を参照してください。

- カスタム・アプリケーション・モジュール・クラスでよく記述、使用またはオーバーライドするコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

14.2 アプリケーション・モジュール・インスタンスの共有

共有データ・キャッシュの宣言型サポートは、JDeveloperの「プロジェクト・プロパティ」ダイアログで提供されています。共有アプリケーション・モジュールの作成によって、複数のセッションのリクエストで、Webサーバー仮想マシン用のアプリケーション・プールで永続的に管理できる、単一のアプリケーション・モジュール・インスタンスを共有できます。

ベスト・プラクティス

アプリケーション全体で静的データのリストを再利用する場合は、共有アプリケーション・モジュールを使用してビュー・インスタンスをグループ化します。共有アプリケーション・モジュールは、すべてのユーザー・セッションでデータにアクセスできるように構成したり、シングル・ユーザー・セッションのUIコンポーネントのみにアクセスを制限するように構成できます。たとえば、共有アプリケーション・モジュールを使用して、国リストなどの参照データにアクセスするビュー・インスタンスをグループ化できます。共有アプリケーション・モジュールを使用すると、すべての共有リソースを1か所で管理できるため、この目的でのスコープのマネージドBeanが不要になります。

図14-1で示すように、「プロジェクト・プロパティ」ダイアログにより、アプリケーションレベルまたはセッションレベルでのアプリケーション・モジュールのデータ・モデルの共有を指定できます。アプリケーションレベルの共有では、任意のHTTPユーザー・セッションが共有アプリケーション・モジュールに含まれた同一のビュー・インスタンスにアクセスできます。一方、セッションレベルの共有アプリケーション・モジュールは、単一のHTTPユーザー・セッションで使用されるアプリケーション・セッション(SessionImpl)に拡張され、単一のルート・アプリケーション・モジュールに適用されます。この場合、特定のHTTPユーザー・セッションで使用する個別のルート・アプリケーション・モジュールは、セッションの有効範囲の共有アプリケーション・モジュールの独自の個別インスタンスを取得します。つまり、同一のHTTPセッションが使用している個別のルート・アプリケーションはセッションの有効範囲の共有アプリケーション・モジュール内のデータを共有しません。

図14-1 共有アプリケーション・モジュール・インスタンスを定義する「プロジェクト・プロパティ」ダイアログ

共有するアプリケーション・モジュールのデータ・モデルを作成する場合、キャッシュされた行セットのデータは、アプリケーションレベルまたはセッションレベルで変更する必要はありません。たとえば、アプリケーションレベルの共有アプリケーション・モジュールでは、ビュー・インスタンスは状態コードや通貨タイプなど静的データのみを問い合せます。ビュー・オブジェクト・インスタンスが現在のユーザーに依存するデータを問い合せると、問合せはセッションレベルでキャッシュされ、行セット・キャッシュを参照するすべてのコンポーネントにより共有できます。たとえば、セッションレベルの共有アプリケーション・モジュールには、直下のレポートのリストを返すため、現在のユーザーとしてマネージャが必要なデータ・セキュリティを備えたビュー・インスタンスが含まれる場合があります。この場合、直下のレポートのキャッシュは、マネージャのHTTPユーザー・セッションの期間中存在します。HTTPユーザー・セッションにプール内の再利用アプリケーション・モジュールを割り当てた場合に、ADFビジネス・コンポーネント・アプリケーション・モジュール・プールは、セッションの有効範囲のアプリケーション・モジュールを再度作成します。これによってHTTPセッションが同じルート・アプリケーション・モジュール・インスタンスを使用可能であるかぎり、セッションの有効範囲のアプリケーション・モジュール期間がHTTPセッションに結び付けられます。セッションレベルの共有アプリケーション・モジュールの直下のレポートのキャッシュは、異なるルート・アプリケーション・モジュールをまたがってアクセスできない点に注意してください。

14.2.1 共有アプリケーション・モジュール・インスタンスの作成方法

共有アプリケーション・モジュール・インスタンスを作成するには、「プロジェクト・プロパティ」ダイアログを使用します。アプリケーションの読取り専用データを保持する個別の独立したルート・アプリケーション・モジュールの論理名を定義します。

始める前に:

参照データに関する知識が役立つ場合があります。詳細は、「ベース・ビュー・オブジェクトを参照表で使用するための定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従って、共有するアプリケーション・モジュールを作成します。

共有アプリケーション・モジュール・インスタンスを作成するには:

1. 「アプリケーション」ウィンドウで、共有アプリケーション・モジュールを作成するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「ADFビジネス・コンポーネント」を開き、「アプリケーション・モジュール・インスタンス」を選択します。

3. 「ADFビジネス・コンポーネント」の「アプリケーション・モジュール・インスタンス」ページで、次のいずれかのタブを選択します。

- アプリケーションのコンテキストについて共有アプリケーション・モジュールを定義する場合は、「アプリケーション」タブを選択します。

- 現在のユーザー・セッションのコンテキストについて共有アプリケーション・モジュールを定義する場合は、「セッション」タブを選択します。

4. 「使用可能なアプリケーション・モジュール」リストで、該当するモジュールを選択し、「アプリケーション・モジュール・インスタンス」 リストに移動します。

5. アプリケーション・モジュールに一意のインスタンス名を割り当てます。

共有アプリケーション・モジュール・インスタンス(いずれかのスコープ)には、一意のインスタンス名が必要です。意味のある名前を指定することにより、指定された慣用名が参照している共有アプリケーション・モジュール・インスタンスを明確にすることもできます。

6. 「OK」をクリックします。

14.2.2 共有アプリケーション・モジュール定義時の処理

アプリケーション・モジュールを作成すると、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>

14.2.3 共有アプリケーション・モジュールの設計時間範囲に関する必知事項

「プロジェクト・プロパティ」ダイアログで共有アプリケーション・モジュールを定義すると、そのアプリケーション・モジュールのデータ・モデルは、同じアプリケーション・ワークスペースに属する他のデータ・モデル・プロジェクトでのみ使用できます。アプリケーション・ワークスペースの範囲を超えてデータ・モデルを使用可能にする場合、「アプリケーション・コンポーネントの再利用」で説明するようにデータ・モデルをADFライブラリとして公開できます。

「構造」ウィンドウで、DataBindings.cpxファイルからデータ・コントロールの使用方法を表示する場合は、「構成」プロパティを共有アプリケーション・モジュール構成に設定しないでください。AppModuleNameという名前のアプリケーション・モジュールの場合、「プロパティ」ウィンドウには、デフォルトでAppModuleNameSharedおよびAppModuleNameLocalという名前の構成が表示されます。Oracle Application Development Framework (Oracle ADF)では、アプリケーションを共有アプリケーション・モジュールとして構成すると、実行時に共有構成が自動的に使用されますが、アプリケーション・モジュールのデータ・コントロールで使用されるように設計されていません。データ・コントロールの使用方法の詳細は、「DataBindings.cpxファイルでの作業」を参照してください。

14.2.4 共有アプリケーション・モジュールのビュー・インスタンスの設計時間範囲に関する必知事項

データ・モデル・プロジェクトのビジネス・コンポーネント定義で、共有アプリケーション・モジュールのビュー・インスタンスへのアクセスを許可するビュー・アクセッサを定義します。このビュー・アクセッサにより、1つのデータ・モデル・プロジェクトのエンティティ・オブジェクトまたはビュー・オブジェクト定義から共有アプリケーション・モジュールのビュー・オブジェクト定義またはビュー・インスタンスをポイントできます。この目的でのビュー・アクセッサ作成の詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。

14.2.5 共有問合せコレクション数の管理に関する必知事項

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)。

14.2.6 共有アプリケーション・モジュールと接続プールに関する必知事項

すべてのアプリケーション・モジュールの接続動作として、ルート・アプリケーション・モジュールごとに独自のデータベース接続を許可します。アプリケーションで複数の共有アプリケーション・モジュールを定義する場合、単一のデータベース接続を使用するために、それらを同じトランザクション下にネストするようアプリケーションを構成できます。この最適化により、共有アプリケーション・モジュールのインスタンスで同じ接続を共有できるようになり、アプリケーションで使用するデータベース・リソースを削減できます。これは読取り専用でトランザクション・アプリケーション・モジュールよりも長く存在する共有アプリケーション・モジュールの場合は特に有効です。

ベスト・プラクティス

共有アプリケーション・モジュールを単一のトランザクション下にネストして、アプリケーションで必要とされるデータベース・リソースを減らすことをお薦めします。アプリケーションが定義する各共有アプリケーション・モジュール構成に対して同じトランザクション名(ユーザーが指定する任意の識別子)を使用するよう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パラメータおよび接続プールの動作の詳細は、「デプロイメント環境のシナリオとプーリング」を参照してください。

14.3 ベース・ビュー・オブジェクトを参照表で使用するための定義

アプリケーションで静的データを表示する必要がある場合は、参照表にアクセスする可能性が高いビュー・インスタンスで共有アプリケーション・モジュールを定義できます。参照表は、アプリケーションにより参照されるデータの静的な変換リストです。参照表のデータは、様々な方法でデータベースに配置できます。関連する検索データを個別の表に格納できる一方、単一の表内にアプリケーションの参照情報をすべて結合すると便利です。たとえば、ORDERS_LOOKUPS表向けに作成された列LOOKUP_TYPEは、値である「はい」および「いいえ」のFWK_TBX_YES_NO、国名のFWK_TBX_COUNTRY、国の通貨の名前を表すFWK_TBK_CURRENCYという様々なコードを含む1つの表を分割する役割を果します。

データベース・スキーマにより単一のデータベース表の検索データが配置される場合、一連のデータごとに個別の問合せを作成することを避ける必要があります。かわりに、概要エディタを使用して、定義したビュー・オブジェクト属性に参照表の目的の列をマップする単一のベース・ビュー・オブジェクトを定義します。問合せ文ではLOOKUP_TYPE列の値のみ変更する必要があるため、ビュー・オブジェクト定義にビュー基準を追加して、LOOKUP_TYPE値を設定するLOOKUP_TYPE句を指定できます。これにより、単一のビュー・オブジェクト定義の参照表データへのアクセスがカプセル化され、LOOKUP_TYPE値が変更された場合やアプリケーションで追加の参照タイプを問い合せる必要がある場合にメンテナンスが簡単になります。

14.3.1 参照表のベース・ビュー・オブジェクト定義の作成方法

参照表の列を問い合せるベース・ビュー・オブジェクトは、データの更新処理の必要がないため、またはエンティティ・ベースのビュー・オブジェクトで提供される利点が不要なため、読取り専用ビュー・オブジェクトとなります。(これらの利点の詳細は、「ビュー・オブジェクトについて」を参照。)

注意:

参照表にアクセスするために作成する読取り専用ビュー・オブジェクトは、共有アプリケーション・モジュールに組み込むには理想的ですが、共有アプリケーション・モジュール・インスタンスでビュー・オブジェクトを共有する場合は、共有アプリケーション・モジュールと同じパッケージにビュー・オブジェクトを作成する必要があります。

読取り専用ビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能な「ビュー・オブジェクトの作成」ウィザードを使用します。

始める前に:

参照データに関する知識が役立つ場合があります。詳細は、「ベース・ビュー・オブジェクトを参照表で使用するための定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従って、共有するアプリケーション・モジュールを作成します。

参照表のベース・ビュー・オブジェクトを作成するには:

1. 「アプリケーション」ウィンドウで、共有アプリケーション・モジュールを特定し、そのパッケージ・ノードを右クリックし、「新規」、「ビュー・オブジェクト」の順に選択します。

2. 「ビュー・オブジェクトの作成」ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。

パッケージに名前を付ける場合は、別の参照用パッケージを作成することを検討してください。

3. 「カスタムSQL問合せ」を選択して、このビュー・オブジェクトが読取り専用アクセスでデータを管理することを指定し、「次へ」をクリックします。

4. 「問合せ」ページの「選択」テキスト・ボックスに、SQL文を直接入力します。

参照表の列の問合せ名は、図14-2に示すSQL文のようになります。この文では、LOOKUP_CODES表のLOOKUP_CODE列、MEANING列およびDESCRIPTION列を問い合せます。

図14-2 「ビュー・オブジェクトの作成」ウィザード、参照表に対するSQL問合せ

5. 問合せ文を入力したら、他の変更は必要ありません。「次へ」をクリックします。

6. 「バインド変数」ページで、「次へ」をクリックします。

7. 「属性マッピング」ページで、表示されているマップされたビュー・オブジェクト属性名をメモし、「次へ」をクリックします。

デフォルトでは、ウィザードによってSELECTリスト列名に対応するJavaに適したビュー・オブジェクト属性名が作成されます。

8. 「属性の設定」ページでは、「属性の選択」ドロップダウンを使用して、問合せ表の主キーに対応する属性を選択し、「キー属性 」チェックボックスを有効にします。

読取り専用のビュー・オブジェクトはエンティティ・オブジェクトには基づいていないため、「ビュー・オブジェクトの作成」ウィザードはデフォルトではキー属性を定義しません。キー属性を定義しなかった場合、読取り専用ビュー・オブジェクト・コレクションに基づくデータを持つADF Facesコンポーネントが、実行時に予期しない動作をすることがあります。読取り専用ビュー・オブジェクトの場合は、図14-3に示すように、キー属性を定義します。

図14-3 「ビュー・オブジェクトの作成」ウィザードの「属性の設定」ページ

9. 各属性に適した名前を使用するために属性名を変更する場合、「属性の選択」ドロップダウンから属性を選択し、該当する名前を「名前」フィールドに入力します。終了したら、「次へ」をクリックします。

たとえば、デフォルト属性LookupTypeおよびLookupCodeは、それぞれTypeおよびValueに名前を変更できます。ビュー・オブジェクト定義に変更を加えても、基礎となる問合せは変更されません。

10. 「Java」ページで、「次へ」をクリックします。

11. 「アプリケーション・モジュール」ページでは、ビュー・オブジェクトのインスタンスをアプリケーション・モジュールのデータ・モデルに追加しません。「終了」をクリックします。

共有アプリケーション・モジュールのデータ・モデルは、ベース・ビュー・オブジェクト定義に追加するビュー基準に基づくビュー・インスタンスを含みます。これにより、LOOKUP_TYPE値を問合せするたびに個別にビュー・オブジェクトを作成する必要はありません。データ・モデルへのビュー・オブジェクト・インスタンスの追加の詳細は、「既存のアプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。

14.3.2 ベース・ビュー・オブジェクトの作成時の処理

参照表のビュー・オブジェクト定義を作成する際、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>

14.3.3 ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法

ビュー・オブジェクト結果をフィルタする必要がある場合、名前付きビュー基準定義をデータ・モデル・プロジェクトに作成します。設計時に定義するビュー基準は、データのフィルタリングが必要となるUIシナリオで使用されます。

「ビュー基準の編集」ダイアログを使用して、参照表の問合せ用に定義した検索ベース・ビュー・オブジェクトのビュー基準定義を作成します。このエディタでは、ターゲット・ビュー・オブジェクトの対応するSQL列名のかわりに属性名を使用してWHERE句を作成できます。得られた結果の定義は、次のとおりです。

- 検索ビュー・オブジェクトのType属性を定義する単一のビュー基準項目のある1つのビュー基準グループで構成される、1つのビュー基準行。

- ビュー基準項目は、Type属性名、Equal演算子、および問合せ結果をフィルタするLOOKUP_TYPEの値で構成されます。

単一のビュー基準が定義されているため、WHERE句条件をカッコで囲む論理積は必要ありません。

始める前に:

参照データに関する知識が役立つ場合があります。詳細は、「ベース・ビュー・オブジェクトを参照表で使用するための定義」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。

また、ビュー基準に関する知識が役立つ場合があります。詳細は、「名前付きビュー基準の処理」を参照してください。

次のタスクを完了する必要があります。

- 「参照表のベース・ビュー・オブジェクト定義の作成方法」の説明に従って、参照データのベース・ビュー・オブジェクトを作成してください。

検索ビュー・オブジェクトのLOOKUP_TYPEビュー基準を作成するには:

1. 「アプリケーション」ウィンドウで、定義した参照ベース・ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビュー基準」ナビゲーション・タブをクリックし、「新規ビュー基準の作成」ボタンをクリックします。

3. 「ビュー基準」ページの「ビュー基準の作成」ダイアログで、「アイテムの追加」ボタンをクリックしてビュー基準グループに基準アイテムを1つ追加します。

4. 「基準アイテム」パネルで、次のように基準項目を定義します。

- 属性として「型」(またはビュー・オブジェクトがLOOKUP_TYPE列にマップする属性に定義した他の名前)を選択します。

- 演算子として「次と等しい」を選択します。

- オペランドの選択を「リテラル」のままにして、目的の型を定義する値の名前を入力します。たとえば、配偶者の有無コードを問い合せるには、LOOKUP_TYPE列に対応する値MARITAL_STATUS_CODEを入力します。

その他の設定はすべて変更しません。

エディタに表示されるビュー・オブジェクトのWHERE句には、図14-4に示すようにシンプルな基準が表示されます。値MARITAL_STATUS_CODEはLOOKUP_TYPE列をフィルタするように設定されます。

5. 「OK」をクリックします。

6. 問い合せるLOOKUP_TYPEごとに1つのビュー基準を定義するには、この手順を繰り返します。

図14-4 検索ビュー・オブジェクト・ビュー基準を指定した「ビュー基準の編集」ダイアログ

14.3.4 エディタでのビュー基準の作成時の処理

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>

14.3.5 ビュー・インスタンスが検索データにアクセスする場合の実行時の処理

ビュー基準に基づいてビュー・インスタンスを作成する場合は、次にビュー・インスタンスが実行されるときに、ビュー基準行に移入したビュー基準に対応する追加のWHERE句条件を使用してビュー・オブジェクトのSQL問合せを拡張します。

14.4 共有サービスのビュー・インスタンスへのアクセス

ADFビジネス・コンポーネントのビュー・アクセッサは、エンティティ・オブジェクト属性(またはビュー・オブジェクト)から、同じアプリケーション・ワークスペースのリンク先ビュー・オブジェクトまたは共有ビュー・インスタンスをポイントする、値のアクセッサ・オブジェクトです。ビュー・アクセッサにより、デフォルトですべての行を含む行セットがリンク先ビュー・オブジェクから戻されます。ビュー・アクセッサにビュー基準を適用することにより、必要に応じてこの行をフィルタできます。ビュー・アクセッサおよびリンク先ビュー・オブジェクトを作成する場合のベース・エンティティ・オブジェクトまたはビュー・オブジェクトは、同じプロジェクトまたはアプリケーション・モジュールにある必要はありませんが、同じアプリケーション・ワークスペースにある必要があります。

ビュー・アクセッサはアプリケーション・モジュール全体に到達し、問合せデータにアクセスできる柔軟性を備えているため、共有アプリケーション・モジュールのビュー・インスタンスへのアクセスに理想的です。共有アプリケーション・モジュールでビュー・インスタンスのデータ・モデルを作成する方法の詳細は、「共有アプリケーション・モジュール・インスタンスの作成方法」を参照してください。

異なるアプリケーション・モジュールのビュー・オブジェクトにアクセスするこの機能により、ビュー・アクセッサは次の場合に特に便利です。

- エンティティ・オブジェクトの属性に設定する検証規則。この場合、ビュー・アクセッサにより共有アプリケーション・モジュールのビュー・インスタンス属性に対応する検索データから検証規則の値が導出されます。

- ビュー・オブジェクトの属性に対して有効にする値リスト(LOV)。この場合、ビュー・アクセッサにより共有アプリケーション・モジュールのビュー・インスタンス属性に対応する検索データから値リストが導出されます。

アクセッサによる検証規則は、ユーザーに対するUIに値リストを表示させない場合に便利ですが、有効値のリストは制限する必要があります。ビュー・オブジェクト属性のLOVを定義して、ユーザー・インタフェースでのリスト・コントロールを使用した作業を簡略化することもできます。ビジネス・コンポーネントの個々の属性にLOVを定義するため、属性に対してLOV使用をカスタマイズすると、属性が表示されるフォームでリスト・コントロールを参照できます。

14.4.1 エンティティ・オブジェクトまたはビュー・オブジェクトのビュー・アクセッサの作成方法

ビュー・アクセッサは、アプリケーション・モードに依存せずにデータ・ソースにアクセスする手段を提供します。ビュー・アクセッサは、エンティティ・オブジェクト・レベルまたは個々のビュー・オブジェクト・レベルで定義できます。ただし、実行時にはビュー・アクセッサの結果は関連する用途に基づいてフィルタ処理されることが多いため、アプリケーション内の各用途ごとに一意のビュー・アクセッサを作成することをお薦めします。

ベスト・プラクティス

アプリケーションでLOVが有効な属性を公開する必要がある場合は、一意のビュー・アクセッサを作成することをお薦めします。LOV結果は実行時にフィルタされることが多いため、複数の値リストを作成するためにビュー・アクセッサを再利用することはお薦めしません。たとえば、エンド・ユーザーが検索基準の適用を解除するまで、保存済の検索の結果により、ターゲット・ビュー・オブジェクトの行セットがフィルタされ続けます。したがって、この同じリンク先ビュー・オブジェクトに適用されるビュー・アクセッサの結果もフィルタされます。ビュー・アクセッサが実行時に常に意図された行セットを返すようにするには、使用するたびに一意のビュー・アクセッサを作成します。

エンティティ・オブジェクトに基づいて作成するビュー・オブジェクトはベース・エンティティ・オブジェクトのビュー・アクセッサを継承するため、エンティティ・オブジェクトに基づいてビュー・アクセッサを定義する際には注意が必要です。エンティティ・オブジェクト自体に基づいてビュー・アクセッサを一度定義する場合には同じビュー・アクセッサを再利用できますが、そのビュー・アクセッサを別のアプリケーション・シナリオで使用しないでください。エンティティ・オブジェクト属性に対する検証規則を定義し、そのエンティティ・オブジェクトのビュー・オブジェクトに対してLOV有効属性を作成する場合は、別々のビュー・アクセッサを作成することをお薦めします。

たとえば、AddressEOエンティティ・オブジェクトは、Shared_CountriesVAビュー・アクセッサを定義し、AddressesVOビュー・オブジェクトはこのビュー・アクセッサを継承するとします。この場合、エンティティ・オブジェクトに基づいてビュー・アクセッサを定義することは有用です。AddressEOに対するアクセッサはCountryId属性に対する検証規則を定義します。ただし、そのCountryId属性に対してLOVを有効にするには、AddressesVOに対する別のビュー・アクセッサを使用する必要があります。

共有アプリケーション・モジュールからビュー・インスタンスにアクセスするビュー・アクセッサを作成する場合は、ビュー・アクセッサの名前にShared_などの接頭辞を使用してください。エンティティ・オブジェクトまたはビュー・オブジェクトにビュー・アクセッサを選択する必要がある場合、この命名規則を使用すると、ビュー・アクセッサの識別が容易になります。

始める前に:

ビュー・アクセッサに関する知識が役立つ場合があります。詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」および「ビュー・オブジェクトを使用したSQL問合せの定義」の説明に従って、アクセスするエンティティ・オブジェクトまたはビュー・オブジェクトを作成します。

- 「共有アプリケーション・モジュール・インスタンスの作成方法」の説明に従って、アプリケーション・モジュールの共有を有効にします。

- 「参照表のベース・ビュー・オブジェクト定義の作成方法」の説明に従って、参照データのベース・ビュー・オブジェクトを作成してください。

- オプションとして、ビュー・オブジェクトで定義するビュー基準を適用することで、ビュー・アクセッサにより戻されるリストを再調整できます。ビュー・アクセッサで使用するビュー基準の作成方法は、「ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法」を参照してください。

ビュー・アクセッサを作成するには:

1. 「アプリケーション」ウィンドウで、ビュー・アクセッサを定義するエンティティ・オブジェクトまたはビュー・オブジェクトをダブルクリックします。
ビュー・アクセッサをエンティティ・オブジェクトで作成するか、ビュー・オブジェクトで作成するかは、ビュー・アクセッサの目的の用途に応じて決まります。通常は、エンティティ・オブジェクトでビュー・アクセッサを作成した方が幅広い用途に使用できます。

2. 概要エディタで「アクセッサ」ナビゲーション・タブをクリックし、「ビュー・アクセッサ」セクションで、「新規ビュー・アクセッサの作成」ボタンをクリックして、現在編集中のエンティティ・オブジェクトまたはビュー・オブジェクト定義にアクセッサを追加します。

3. 「ビュー・アクセッサ」ダイアログで、共有アプリケーション・モジュールのノードから参照表に作成したビュー・インスタンス名を選択し、ビュー・アクセッサ・リストに移動します。
このダイアログには、アプリケーションのビュー・オブジェクトおよびビュー・インスタンスがすべて表示されます。たとえば、「ビュー・アクセッサ」ダイアログには、図14-5に示すように、共有アプリケーション・モジュールのLookupServiceAMとビュー・インスタンスのリストが表示されます。

デフォルトでは、作成されるビュー・アクセッサにはビュー・オブジェクト・インスタンスと同じ名前が表示されます(または、そのインスタンスを同名の子ビュー・オブジェクトと区別する必要がある場合は、整数が追加されます)。「アクセッサ名」を編集して一意の名前を付けることができます。

たとえば、図14-5の「ビュー・アクセッサ」ダイアログでは、共有アプリケーション・モジュールLookupServiceAMでAddressUsageTypesビュー・インスタンスを選択した場合として、ビュー・アクセッサAddressUsageTypesVAが表示されています。このビュー・アクセッサは、ベース・エンティティ・オブジェクトAddressUsagesEOで作成され、AddressUsageTypesビュー・インスタンスの行セットにアクセスします。

図14-5 エンティティ・オブジェクトでのビュー・アクセッサの定義

4. 既存のビュー基準を適用してアクセッサをフィルタする場合は、概要エディタでビュー・アクセッサを選択し、「編集」アイコンをクリックします。
「ビュー・アクセッサの編集」ダイアログで、「編集」をクリックして次の手順を実行し、ビュー基準を適用します。

a. 適用するビュー基準を選択し、「選択済」リストに移動します。
追加のビュー基準を追加すると、複数のフィルタ(実行時に論理積(AND)演算子を実行)を適用できます。

b. ビュー・アクセッサの行セットに制御属性を定義するバインド変数の属性名を入力します。
ビュー・オブジェクトで直接設定するビュー基準(ビュー・インスタンスを作成する場合など)と異なり、ビュー・アクセッサのビュー基準の制御属性では、ビュー・アクセッサのベース・ビュー・オブジェクトから値が導出されます。

c. 「OK」をクリックします。

5. 「ビュー・アクセッサ」ダイアログで、「OK」をクリックします。

14.4.2 ビュー・アクセッサによって指定された属性値に対する検証方法

リンク先ビュー・オブジェクトの行セットにアクセスするために作成するビュー・アクセッサを使用して、実行時にエンド・ユーザーから求められるデータを検証できます。たとえば、エンド・ユーザーが登録フォームに記入する場合、個々の検証規則により肩書、配偶者の有無、連絡先コードを、共有アプリケーション・モジュールのビュー・インスタンスにより問合せされた参照表データに対して検証できます。

エンティティ・オブジェクトに定義したビュー・アクセッサをこれらの組込みの宣言的検証規則に適用できます。

- 比較バリデータは、エンティティ属性と値の論理比較を実行します。使用可能な値を決定するためにビュー・アクセッサを指定する場合、比較バリデータにより、選択するEquals、NotEquals、GreaterThan、LessThan、LessOrEqualTo、GreaterOrEqualToの各演算子が適用され、ビュー・アクセッサで戻された値と比較されます。

- リスト・バリデータにより、エンティティ属性と値リストが比較されます。有効なリスト値を決定するためにビュー・アクセッサを指定する場合、リスト・バリデータにより、選択するInまたはNotIn演算子がビュー・アクセッサで戻された値に対して適用されます。

- コレクション・バリデータは、コレクション属性について実行された演算と値の論理比較を実行します。使用可能な値を決定するためにビュー・アクセッサを指定する場合、コレクション・バリデータにより、選択されたコレクション属性にSum、Average、Count、Min、Maxの各演算が適用され、ビュー・アクセッサで戻された値と比較されます。

エンティティ・ベースのビュー・オブジェクトのデータを実行時に検証できるよう定義する検証規則は、常にエンティティ・オブジェクトの属性に定義されます。エンティティ・オブジェクト・エディタを使用して個々の属性に検証規則を定義します。定義された検証規則を持つエンティティ・オブジェクトから導出され、後で定義するビュー・オブジェクトは、属性値の検証を自動的に受け取ります。

始める前に:

ビュー・アクセッサに関する知識が役立つ場合があります。詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。

比較、リスト、またはコレクション・タイプのビュー・アクセッサを検証するには:

1. 「アプリケーション」ウィンドウで、目的のエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「ビジネス・ルール」ナビゲーション・タブをクリックします。

3. 「ビジネス・ルール」ページで、検証する属性を選択し、次に「新規バリデータの作成 」ボタンをクリックして、エンティティ・オブジェクトの属性を追加します。

4. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「比較」、「リスト」、または「コレクション」を選択します。

5. バリデータの選択で必要な選択をします。

6. 「比較」または「リスト・タイプ」ドロップダウン・リストで、「ビュー・アクセッサ属性」を選択します。

7. 「ビュー・アクセッサ属性の選択」グループ・ボックスで、共有サービスから目的のビュー・アクセッサを展開し、検証として提供する属性を選択します。

図14-6は、リスト・バリデータを使用してビュー・アクセッサ属性を選択する場合のダイアログを示しています。

図14-6 ビュー・アクセッサを使用するリスト・バリデータ

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるメッセージを入力します。

9. 「OK」をクリックします。

14.4.3 ビュー・アクセッサ・バリデータ定義時の処理

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>

14.4.4 ビュー・アクセッサを使用した動的フィルタリングに関する必知事項

ビュー・オブジェクトのAPIであるsetWhereClause()メソッドを使用すると、設計時にビュー基準が指定されているビュー・アクセッサを持つビュー・インスタンスに動的WHERE句を追加できます。実行時に、ビュー・アクセッサとそのビュー基準がビュー・インスタンスに適用された状態で、そのビュー・インスタンスでsetWhereClause()メソッドをコールしてWHERE句を追加すると、プログラム的に設定されたそのWHERE句が、すでに適用済のビュー基準のWHERE句にANDで結合されます。

14.4.5 参照表を基にしてLOVを作成する方法

リンク先ビュー・オブジェクトのビュー行にアクセスするために作成するビュー・アクセッサを使用して、実行時に値リストをエンド・ユーザーに表示できます。目的のビュー・インスタンスをデータソースとして使用してビュー・アクセッサを最初に作成すると、表示するビュー・オブジェクトのLOVが有効な属性にそのビュー・アクセッサを追加できます。ビュー・インスタンスの特定の参照属性をポイントするよう、LOVが有効な属性のビュー・アクセッサ定義を編集します。問合せでは、行セット・キャッシュに静的データを移入する必要があるため、共有アプリケーション・モジュールの関連先ビュー・インスタンスを特定します。

リストの使用方法は、UIリスト・コントロールにバインドされるビュー・オブジェクトの属性で定義されますが、ビュー・アクセッサ定義は、ビュー・オブジェクトまたはビュー・オブジェクトのベース・エンティティ・オブジェクトのいずれかに存在します。ビュー・オブジェクトのエンティティ・オブジェクトでビュー・アクセッサを作成するように選択した場合、ビュー・オブジェクトの概要エディタの「アクセッサ」ページには、図14-7に示すように、継承されたビュー・アクセッサが表示されます。属性のビュー・オブジェクトでビュー・アクセッサを作成するように選択した場合は、概要エディタの「アクセッサ」ページまたはLOV定義のエディタから実行できます。

LOVのビュー・アクセッサがデータベース表から常に最新のデータを問い合せるようにするために、ビュー・アクセッサのリンク先ビュー・オブジェクトで自動リフレッシュ機能を有効にできます。

図14-7 概要エディタの「アクセッサ」ページ

始める前に:

ビュー・アクセッサに関する知識が役立つ場合があります。詳細は、「共有サービスのビュー・インスタンスへのアクセス」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。

LOV有効属性の使用方法の追加の例を理解しておくと役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」に従って、ビュー・アクセッサのデータソースとなるビュー・オブジェクトを作成します。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」に従って、ビュー・アクセッサのデータソースとなるビュー・オブジェクトを作成します。

- オプションで、「ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法」の説明に従ってビュー・オブジェクトの自動リフレッシュを有効にします。
ビュー・アクセッサが参照表から常に最新のデータを問い合せるようにする必要がある場合は、リンク先ビュー・オブジェクトで「自動リフレッシュ」プロパティを設定します。このプロパティにより、データベースが変更されると、ビュー・オブジェクト・インスタンスを自動的にリフレッシュできます。これは、リンク先ビュー・オブジェクトにビュー・アクセッサを定義する場合の一般的なユースケースです。

参照表から値を表示するLOVを作成するには:

1. 「アプリケーション」ウィンドウで、目的に属性のあるビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「アクセッサ」ナビゲーション・タブをクリックします。

3. 「ビュー・アクセッサ」リストの「アクセッサ」ページで、ビュー・オブジェクトが目的のビュー・アクセッサをベース・エンティティ・オブジェクトから継承しているかどうかを確認します。ビュー・アクセッサがない場合は、目的のエンティティ・オブジェクトでビュー・アクセッサを作成するか、「新規ビュー・アクセッサの作成」ボタンをクリックして、現在編集中のビュー・オブジェクトにアクセッサを追加します。

定義する検証規則は、常にビュー・オブジェクトのベース・エンティティ・オブジェクトの属性に定義されます。このため、ビュー・アクセッサ・リストを使用してエンティティ・オブジェクト属性も検証することが明確な場合は、ベース・エンティティ・オブジェクトのレベルでビュー・アクセッサを定義すると便利です。

4. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

5. 「属性」ページで、LOVを表示する属性を選択し、「値リスト」タブをクリックして、「値リストの追加」ボタンをクリックします。

6. 「値リストの作成」ダイアログで、「リスト・データソース」ドロップダウン・リストからビュー・アクセッサを選択します。

選択したビュー・アクセッサは、参照表のビュー・オブジェクト・インスタンスに作成したビュー・アクセッサになり、データソースとして使用されます。

7. 次に、「リスト属性」ドロップダウン・リストで、このビュー・アクセッサから現在編集中の属性の値リストを戻す属性を選択します。

エディタにより、ビュー・オブジェクト属性とLOV有効属性との間のデフォルト・マッピングが作成されます。この場合、属性は同じになります。たとえば、OrdersViewビュー・オブジェクトの属性OrderIdは、Shared_OrdersVAビュー・アクセッサの属性OrderIdにマップされます。

8. リストによりベース・ビュー・オブジェクトに戻される値を追加で指定する場合、「リスト戻り値」の「追加」ボタンをクリックし、目的のビュー・オブジェクト属性をビュー・アクセッサによりアクセスされた同じ属性にマップします。

あわせて更新するため、属性のリスト選択をユーザーには要求せず、現在の行で決定している属性値を必要とする場合、追加属性の戻り値が便利です。

たとえば、OrdersViewビュー・オブジェクトの属性StartDateをマップするには、Shared_OrdersVAビュー・アクセッサの属性StartDateを選択します。リストが定義される属性のデフォルト属性マッピングは削除しないでください。

9. 「OK」をクリックします。

14.4.6 ビュー・オブジェクト属性の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>

14.4.7 属性の値リストが表示される場合の実行時の処理

ADFビジネス・コンポーネント実行時に、ビュー行およびエンティティ・オブジェクトの属性セッターに機能が追加され、LOVが有効な属性の動作が実現されます。ユーザー・インタフェースにLOVが有効な属性値を表示するために、LOVの機能によりデータソースをフェッチし、該当する行の属性とマップされたターゲット属性を検索します。

14.4.8 参照表からの値のリストの表示に関する必知事項

エンティティ・ベースのビュー・オブジェクトとは異なり、作成するカスタムSQLビュー・オブジェクトはデフォルトではキー属性を定義しません。キー属性を定義せずに読取り専用オブジェクトを作成することはできますが、カスタムSQLモードでは問い合せた表の主キーに対応する属性を選択し、キー属性としてマーキングしておくのがベスト・プラクティスです。キー属性があると、実行時に行セット・ナビゲーションを正しく動作させることができます。たとえば、ユーザー・インタフェース開発者は、読取り専用ビュー・オブジェクト・コレクションに基づいてLOVコンポーネントを作成することがあります。行キー値を指定するキー属性がなければ、LOVが正しく機能せず、実行時エラーが発生することがあります。

14.4.9 プログラム的に起動されるデータベース変更通知に関する必知事項

データバインドされたUIコンポーネントをWebページに作成するときは、「ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法」の説明に従って、対応するビュー・オブジェクトで自動リフレッシュ機能を有効にできます。この場合、ADFモデル・レイヤーおよびADFビジネス・コンポーネントが実行時にデータベース変更通知を処理し、共有アプリケーション・モジュール・キャッシュが自動的に更新されます。ただし、共有アプリケーション・モジュールのビュー・インスタンスをプログラム的にリフレッシュするメソッドを作成する場合は、ビュー・インスタンスをリフレッシュする前に、そのメソッドで共有アプリケーション・モジュールに対してprocessChangeNotification()メソッドを起動する必要があります。ビュー・インスタンスをリフレッシュする前にprocessChangeNotification()メソッドをコールすると、対応する問い合せたデータがデータベースで変更されている場合に、共有アプリケーション・モジュール・キャッシュが更新されます。

共有アプリケーション・モジュールのビュー・インスタンスをプログラムで更新するには、(SummitADF_ExamplesワークスペースのprocessChangeTestClient.javaの例の次の例に示すように)次の手順に従ってください。

1. processChangeNotification()メソッドをコールします。

2. 共有アプリケーション・モジュールからビュー・インスタンスを取得します。

3. ビュー・インスタンスをリフレッシュします。

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);
}

}
}

14.4.10 AttributeDefプロパティの継承に関する必知事項

ビュー・オブジェクトにより他のビュー・オブジェクトが拡張される場合、ベース・オブジェクトにLOVが有効な属性を作成できます。概要エディタで子ビュー・オブジェクトを定義すると、対応するビュー・オブジェクト属性にLOV定義が表示されます。この継承メカニズムにより、LOVが有効な属性を1回定義し、後で同じ属性の複数のビュー・オブジェクト・インスタンス全体にその属性を適用できます。他のビュー・オブジェクト定義からビュー・オブジェクトを拡張する方法の詳細は、「コンポーネントを作成後に拡張する方法」を参照してください。

また、概要エディタを使用して継承LOV定義を拡張できます。たとえば、ベース・ビュー・オブジェクトの問合せによりすでに定義されている属性を追加して、選択リストに表示できます。あるいは、カスタムのWHERE句を使用するビュー・オブジェクト・インスタンスを作成して、ベース・ビュー・オブジェクトによりまだ問合せされていない追加属性を問合せできます。エンティティ・ベース・ビュー・オブジェクトのカスタマイズの詳細は、「バインド変数の使用」を参照してください。

14.4.11 バリデータの使用に関する必知事項

ビュー・オブジェクトにLOVが有効な属性を作成した場合、List Validatorを使用して属性を検証する必要はありません。ユーザー・インタフェースにリストを表示せず、有効値のリストを制限する必要がある場合のみ属性バリデータを使用します。List Validatorは、単純な静的リスト、または定義するビュー・アクセッサから取得した使用可能な値のリストです。UIに表示された属性がキー値(主キー、外部キー、または代替キー)を参照する属性の場合には、Key Exists Validatorを使用します。ADF Business Componentsでの宣言的な検証の詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

14.5 共有アプリケーション・モジュールでのビュー・オブジェクト・インスタンスのテスト

JDeveloperには、アプリケーション・ユーザー・インタフェースを使用せず、またはテスト・クライアントのプログラムを記述せずに、データ・モデルのすべての面をテストできるようにする、対話型アプリケーション・モジュール・テスト・ツールが用意されています。多くの場合、Oracle ADFモデル・テスターを実行すると、開発時にビジネス・サービスのデータ機能を最も迅速に実行できます。

14.5.1 Oracle ADFモデル・テスターを使用したベース・ビュー・オブジェクトのテスト方法

アプリケーション・モジュールは、Oracle ADFモデル・テスター(またはUIクライアント)がアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールで使用される一連のビュー・オブジェクトは、それ自体のデータ・モデル、つまり、クライアントがユーザー・インタフェースを介して表示および操作できる一連のデータを定義します。Oracle ADFモデル・テスターを使用すると、定義したアクセッサで予測どおりの検証結果が得られ、正しいLOV属性値が表示されるかをテストできます。

アプリケーション・モジュールに追加したビュー・オブジェクトをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「共有アプリケーション・モジュールでのビュー・オブジェクト・インスタンスのテスト」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「共有アプリケーション・モジュールの追加機能」を参照してください。

ADFビジネス・コンポーネントのデバッグに特有の診断メッセージを理解しておくと役立つ場合があります。詳細は、「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、ビュー・インスタンスを持つアプリケーション・モジュールを作成します。

アプリケーション・モジュール構成でビュー・オブジェクトをテストするには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを右クリックして「実行」を選択します。

または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は、「デバッグ」を選択します。たとえば、Oracle ADFモデル・テスターを使用してデバッグする場合、ステータス・メッセージと例外を表示し、ソース・コードをステップ・インおよびステップ・アウトし、ブレークポイントを管理できます。「ログ」ウィンドウおよび各種デバッガ・ウィンドウのデバッガ・プロセス・パネルが開きます。

2. Oracle ADFモデル・テスターで、ツリー・リストを開き、目的のビュー・オブジェクト・ノードをダブルクリックします。

ビュー・オブジェクト・インスタンスはすでにテスト・セッションで実行されているように表示される場合があります。この場合、右側のテスター・パネルには、図14-8で示しているように、すでにビュー・オブジェクト・インスタンスの問合せ結果が表示されています。読取り専用ビュー・オブジェクトのテスター・パネルのフィールドは、そのビュー・オブジェクトで表されるデータが編集できないため、常に無効として表示されます。

図14-8 Oracle ADFモデル・テスターでのデータ・モデルのテスト

14.5.2 Oracle ADFモデル・テスターを使用してLOV有効属性をテストする方法

ビュー・オブジェクト属性に作成したLOVをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。テスターの表示およびサポートされるコントロール・タイプの詳細は、「Oracle ADFモデル・テスターを使用してLOV有効属性をテストする方法」を参照してください。

14.5.3 Oracle ADFモデル・テスター使用時の処理

Oracle ADFモデル・テスターを起動すると、JDeveloperによってテスター・ツールが別プロセスで開始され、Oracle ADFモデル・テスターが表示されます。ダイアログの左側のツリーには、アプリケーション・モジュールのデータ・モデルのすべてのビュー・オブジェクト・インスタンスが表示されます。図14-8は、展開されたツリーにProductImagesと呼ばれるインスタンス1つのみを示しています。目的のビュー・オブジェクト・インスタンスをダブルクリックすると、図14-8に示すように、問合せ結果を検査するパネルがOracle ADFモデル・テスターに表示されます。

データは編集できないため、表示する読取り専用のビュー・オブジェクトすべてに対して、テスト・パネルは無効になっています。ただし、読取り専用のビュー・オブジェクトの場合でも、ツールはいくつかの有用な機能を備えています。

- 「ラベル・テキスト」のコントロール・ヒントに基づいたUIヒント、およびフォーマット・マスクが正しく定義されているかどうかを検証できます。

- ツールバー・ボタンを使用してデータのスクロールもできます。

「エンティティ・ベースのビュー・オブジェクトの対話的テスト方法」で説明しているように、行の挿入、更新および削除をシミュレートできるエンティティ・ベースのビュー・オブジェクトを作成する場合は、Oracle ADFモデル・テスターをより便利に使用できます。

14.5.4 共有アプリケーション・モジュール・キャッシュが別のサービスによってアクセスされた場合の実行時の処理

アプリケーション・スコープを備えた共有アプリケーション・モジュールがLOVによりリクエストされると、その使用方法のためADFビジネス・コンポーネント実行時にApplicationPoolオブジェクトが作成されます。ApplicationPoolは、ADFビジネス・コンポーネント・プロジェクト構成ファイル(.jpx)に定義されている共有使用ごとに1つのみ作成されます。その後、実行時にApplicationPoolが使用され、データの取得にユーザー・アプリケーション・モジュールのように使用されるアプリケーション・モジュール・インスタンスが取得されます。共有アプリケーション・モジュール・インスタンスへの参照は、アプリケーション・スコープのアプリケーション・モジュールがリセットされると、解放されます。モジュール参照は、管理されていない解放の実行時またはセッション・タイムアウトで常に解放されます。

共有アプリケーション・モジュールのデータ・キャッシュは複数のスレッドでアクセスされるため、イテレータのスペースを分割して異なるセッションのイテレータ間の競合を回避する必要があります。これにより、あるセッションからの次のリクエストによって、別のセッションで使用中のイテレータの状態が変更されることはなくなります。実行時に、単一のRowSetの上部の複数のイテレータに対してADFビジネス・コンポーネントのサポートを受け、これらの競合を回避します。したがって、実行時に各RowSetのアクティブ・セッションと同じ数のイテレータがインスタンス化されます。

アプリケーション・スコープの共有アプリケーション・モジュール・ライフサイクルはApplicationPoolオブジェクトで管理されるアプリケーション・モジュールのライフサイクルと類似しています。たとえば、すべてのアクティブ・セッションがその共有アプリケーション・モジュールを解放すると、アプリケーション・モジュールはApplicationPoolオブジェクトにより収集されるガベージになります。共有プールは、特定のアプリケーション要件を満たすようにチューニングできます。

セッション・スコープの共有アプリケーション・モジュールは、ルートのユーザー・アプリケーション・モジュールのデータ・モデル内で、ネストされたアプリケーション・モジュール・インスタンスとして単純に作成されます。ネストされたアプリケーション・モジュールの詳細は、「ネストされたアプリケーション・モジュールの定義」を参照してください。

15 アプリケーション・モジュールによるSOAP Webサービスの作成

この章では、ADFアプリケーション・モジュールの公開方法と、SOAPサービス・インタフェース接続を定義してFusion Webアプリケーションで外部Webサービスとして使用できるようにする方法を説明します。また、公開されたアプリケーション・モジュールを外部サービスとしてFusion Webアプリケーションに組み込む方法についても説明します。

この章の内容は次のとおりです。

- サービス対応アプリケーション・モジュールについて

- サービス対応アプリケーション・モジュールの公開

- サービス対応アプリケーション・モジュールによるリモート・データのアクセス

- コンシューミング・アプリケーションでの多相コレクションへのアクセス

- コンシューミング・アプリケーションでの検索メソッド・フィルタ・モデルの使用

15.1 サービス対応アプリケーション・モジュールについて

サービス対応アプリケーション・モジュールは、サービス・インタフェースを通じてサービス・コンシューマに通知するADFアプリケーション・モジュールです。サービス利用者がサービス対応アプリケーション・モジュールの利用には、Webサービス・アクセス、Service Component Architecture (SCA)コンポジット・アクセス、および別なADFアプリケーション・モジュールからのアクセスという3つのシナリオがあります。

Service Component Architecture (SCA)は、リモートで使用可能なサービスを実装するためのオープンで技術に中立なモデルを提供します。SCAはビジネス機能の観点から定義されており、アプリケーション開発者によるミドルウェア機能のアクセスを容易にします。ADFビジネス・コンポーネントはサービス・インタフェースで公開可能なアプリケーション・モジュールにより、SCA準拠ソリューションをサポートしています。

アプリケーション・モジュールをサービス対応にすると、JDeveloperが必要なアーティファクトを作成します。その構成内容は次のとおりです。1) サービスを定義しているJavaインタフェース、2) Javaインタフェースを実装するEJB 3.0セッションBean、3) サービスの操作を記述したWSDLファイル、および4) サービスのデータ構造を定義したXMLスキーマ・ドキュメント(XSD)。サービス・インタフェースはWSDLとXSDを組み合せた中立言語で、Fusion Webアプリケーション・クライアント用に記述されます。

SCAは次の2種類のサービスを定義します。

- リモート対応可能なサービス。通常はきめが粗く、結合が緩いSOAアーキテクチャでのリモート公開用に設計されます。

- ローカル・サービス。通常はきめが細かく、緊密に結合されたアーキテクチャ内で同時にデプロイされる他の実装でのローカルな使用のために設計されます。

ADFビジネス・コンポーネント・サービスは最初のカテゴリに分類され、リモート対応可能サービスとしてのみ使用する必要があります。

リモート・アプリケーション・モジュールによって定義されたADFビジネス・コンポーネント・サービス(データ・アクセスとメソッド・コールを含む)は、その他のあらゆるアプリケーション・モジュールとの相互運用が可能です。これは、同じアプリケーション・モジュールで、ADFデータ・コントロールおよびWebサービス・クライアントを使用している対話型のWebユーザー・インタフェースをサポートできるということを意味しています。

15.1.1 サービス対応アプリケーション・モジュールのユースケースと例

サービス対応アプリケーション・モジュールは、開発チームが公開し、Fusion Webアプリケーションに提供できます。リモートWebサービスからアセンブルされたFusion Webアプリケーションも、単一のアプリケーション・サーバー上で稼働するための参加サービスが不要です。

Webアプリケーションは異なる複数のアプリケーション・サーバーで実行されることがありますが、SCAは統合アプリケーションのように見えます。利用するクライアント・プロジェクトはADFサービス・ファクトリ検索メカニズムを使用して、データおよびサービス対応アプリケーション・モジュールによってカプセル化されたあらゆるビジネス・メソッドにアクセスします。実行時は、サービスの起動に使用されるプロトコル(SOAPまたはRMI)に応じて、コール元のクライアントとADF Webサービスが同じトランザクションに参加する場合とそうでない場合があります。RMIプロトコルとJava Transaction API (JTA)マネージド・トランザクションのみで、コール元のクライアントと同じトランザクションでサービスをコールすることができます。デフォルトでは、ADF Webサービスは、RMIプロトコルをサポートするために、同じトランザクションに参加するように構成されます。

15.1.2 サービス対応アプリケーション・モジュールの追加機能

ADFビジネス・コンポーネント・サービスを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- SCAおよびサービス・データ・オブジェクト(SDO)標準の詳細は、http://www.oasis-opencsa.orgにあるOpen Composite Services Architecture (CSA)を通じてOrganization for the Advancement of Structured Information Standards (OASIS)のWebサイトの仕様の項を参照してください。

- WebサービスおよびOracle WebLogic ServerのWebサービス・サポートの背景は、『Webサービスの理解』を参照してください。

- Business Process Execution Language (BPEL)エンティティ変数を使用してSDOデータ・プロバイダにデータ操作を委譲する方法の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のBPELプロセスでのXMLデータの操作の章を参照してください。

- RMIクライアントの認可を有効にするために使用されるbinding_permission_authorization_policyを含め、Oracle Web Services Manager (OWSM)によりサポートされる事前定義済の認可ポリシーの詳細については。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の付録「事前定義済ポリシー」を参照してください。

- ローカル・サービス・サポートには、「アプリケーション・モジュールのクライアント・インタフェースのプログラム的操作」で説明しているApplicationModuleインタフェースとViewObjectインタフェース・サポートを使用します。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

15.2 サービス対応アプリケーション・モジュールの公開

アプリケーション・モジュールは、ビジネス・ロジックを関連する一連のビジネス機能としてカプセル化するADFビジネス・コンポーネント・フレームワーク・コンポーネントです。アプリケーション・モジュールはサービスにマップされます。アプリケーション・モジュールの概要エディタを使用して、Webサービス・インタフェースを有効化し、ビュー・オブジェクト・データの行をサービス・データ・オブジェクト(SDO)コンポーネントとして公開します。

SDOコンポーネントの基礎になっているSDOフレームワークによって、ビュー・オブジェクトのデータが抽出され、JavaとXML間でのデータ構造のやり取りが標準化されます。この種のデータ抽出によってサービス指向アーキテクチャ(SOA)での異種環境データ・ソースの処理が簡略化され、対話型のWebユーザー・インタフェースとWebサービス・クライアントに同じビュー・オブジェクトを使用することで、ビュー・オブジェクトを選択してサービス対応にできます。

JDeveloperでは、アプリケーション・モジュールをWebサービスとして公開できます。このようなWebサービスでは、アプリケーション・モジュールで定義されたビュー・インスタンスに基づくSDOコンポーネントを使用して、JavaとXML間のデータ構造のやり取りが標準化されます。JDeveloperは、Webサービス・クライアントがコンシューミング・アプリケーションで使用するWSDLサービス記述も生成します。

注意:

JDeveloperでは、サービス対応アプリケーション・モジュールのビュー・オブジェクトのSDOコンポーネント生成のみをサポートします。現時点では、これ以外のADFビジネス・コンポーネントをSDOコンポーネントとして定義できません。

サービス対応アプリケーション・モジュールは、ビュー・オブジェクト、カスタム・メソッド、組込みデータ処理操作、および指定されたビュー基準に基づく特殊な検索方法を公開し、クライアントが使用できるようにします。アプリケーション・モジュール・サービス・インタフェースの有効後、ADFビジネス・コンポーネントService Interfaceデプロイメント・プロファイルを作成して、ターゲット・アプリケーション・サーバーにデプロイする必要があります。

Business Process Execution Language (BPEL)プロセス・サービス・コンポーネントで使用する、ビュー・インスタンス・データ処理操作も公開する必要があります。BPELは、複数のサービスからエンドツーエンドのビジネス・プロセスを構成するための言語です。BPELエンティティ変数を使用してデータ操作をSDOデータ・プロバイダに委譲する方法の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の「BPELプロセスでのXMLデータの操作」の章のXMLデータ操作のデータ・プロバイダ・サービスへの委譲を参照してください。

注意:

SDOパラメータを使用して直接メソッドを実装するのではない点が重要です。SDOフレームワークを使用して、実行時にのみビュー行のタイプをラップします。

15.2.1 アプリケーション・モジュール・サービス・インタフェースの有効化の方法

JDeveloperでアプリケーション・モジュールを編集して、最上位のビュー・オブジェクトを公開し、サポートしているサービス操作を定義するWebサービス・インタフェースを作成します。サービスを有効化でき、サービス・クライアントがアクセス可能にできる最上位のビュー・オブジェクトは、次のとおりです。

- スタンドアロン・ビュー・オブジェクトのビュー・インスタンス(階層関係に参加しません)

- マスター詳細関連ビュー・オブジェクトのマスター・ビュー・インスタンス(子ビュー・インスタンスを含みません)

- 親ビュー・オブジェクトを拡張するビュー・オブジェクトのビュー・インスタンス(多相ビュー・オブジェクトを定義するためのサブタイプ識別子属性を含む必要はありません)

サービス・インタフェースに自動的に参加しないビュー・オブジェクトは、次のとおりです。

- マスター詳細関連ビュー・オブジェクトの子ビュー・インスタンス
サービス・インタフェースには、個々に子ビュー・オブジェクトを追加できます。子ビュー・オブジェクトのSDOクラスの作成方法の詳細は、「個別のビュー・オブジェクトのサービス対応化の方法」を参照してください。

- 多相ビュー・オブジェクトのビュー・インスタンス(サブタイプ識別子属性によって定義されます)
JDeveloperで、多相ビュー・オブジェクトに対するアクセスや操作を可能にする、Webサービス・プロキシ・クライアントを作成できます。JAX-WSクライアントの例は、「コンシューミング・アプリケーションでの多相コレクションへのアクセス」を参照してください。

標準的なサービス操作の目的は、ビュー・オブジェクトのデータ処理操作を公開することです。標準のサービス操作を起動することで、基になるフレームワーク・オブジェクトで定義したあらゆるビジネス・ロジック(たとえばビジネス・ルールの評価など)が、適用されます。

表15-1は、サービス・ビュー・インスタンスがサポートしている標準操作のリストです。

表15-1 標準ビュー・インスタンス・データ処理操作

操作

メソッド名

操作の説明

Create

create<VOName>

1つのADFビジネス・コンポーネント・ビュー行を作成します。

Update

update<VOName>

1つのADFビジネス・コンポーネント・ビュー行を更新します。

Delete

delete<VOName>

1つのADFビジネス・コンポーネント・ビュー行を削除します。

Merge

merge<VOName>

ADFビジネス・コンポーネント・ビュー行があれば更新し、なければ新しく作成します。

GetByKey

get<VOName>

主キーによって、単一のADFビジネス・コンポーネント・ビュー行を取得します。

Find (ビュー・オブジェクト問合せ文に適用されるビュー基準による)

find<VOName>

選択したビュー・オブジェクトの問合せ文に適用されるSDOベースのビュー基準を使用して、ADFビジネス・コンポーネントのビュー行のリストを検索して戻します。

問合せでは、問合せの実行に必要として定義されたバインド変数は指定してはなりません。サービス・インタフェースは実行時には必須バインド変数を公開しません。このシナリオ用の検索メソッドの作成の詳細は、「必須バインド変数によってフィルタされる宣言的検索操作の公開方法」を参照してください。

Find (ビュー基準による)

find<VOName><VCName>

必要なバインド変数の名前付きビュー基準と値により、ADFビジネス・コンポーネントのビュー行のリストを検索して戻します。これは必須バインド変数に依存しているADFビジネス・コンポーネント・ビュー行のフィルタには適した方法です。

Process

process<VOName>

ADFビジネス・コンポーネント・ビュー行リストに対する作成、更新、削除、またはマージ操作を実行します。指定した操作が特定のリスト内のすべてのオブジェクトに対して適用されます。

ProcessChangeSummary

processCS<VOName>

ADFビジネス・コンポーネント・ビュー行リストに対する作成、更新、または削除操作を実行します。ChangeSummaryオブジェクトでの指定内容に応じて、異なるオブジェクトに対して異なる操作が適用されます。

また、複数の組込みメソッドをオプションでアプリケーション・モジュール(AppModuleService.java)のクライアント・サービス・インタフェースに追加できます。表15-2に、有効にするサービス・ビュー・インスタンスのランタイム・サポートを提供する組込みメソッドのリストを示します。

表15-2 組込みサービス・インタフェース・メソッド

操作

メソッド名と非同期メソッド名

メソッドの説明

オブジェクトと属性のコントロール・ヒント操作の生成

getDfltObjAttr Hints()

getDfltObjAttr HintsAsync()

特定のロケールに基づくオブジェクトについて、オブジェクトと属性の表示名ラベルを含むベースUIヒントを返します。メソッドは、サービスでオブジェクトの名前を受け取り、ベース・ヒントのローカリゼーションを駆動するヒントおよびロケール名(ISO 639-1形式)を取得します。

このメソッドを、Webサービス・コンシューミング・アプリケーションで使用して、サービス・ビュー・インスタンスとその属性の適切なラベルでユーザー・インタフェースを生成できます。表示名UIヒントの指定の詳細は、「サービス・ビュー・インスタンスと属性の表示名の設定方法」を参照してください。

最終更新時間操作の生成

getServiceLast UpdateTime()

getServiceLast UpdateTimeAsync Response()

SOAPサービス・エンドポイントのサービス・スキーマ・ファイルの最終変更時刻を返します。

このメソッドは、オブジェクトがいつ更新されたかを判断するためにサービス・ビュー・インスタンス・スキーマ・ファイル(XSD)をキャッシュするWebサービス・コンシューミング・アプリケーションで使用できます。

エンティティ・リスト操作の生成

getEntityList()

getEntityListAsync()

サービス・ビュー・インスタンス名と、SOAPサービス・エンドポイントの各サービス・ビュー・オブジェクトが「作成」、「更新」、「マージ」および「削除」操作をサポートするかどうかを示すフラグのリストを返します。

このメソッドは、カスタム・オブジェクト・サービスを使用して使用可能な操作を判断するWebサービス・コンシューミング・アプリケーションで使用できます。カスタム・オブジェクト・サービスは、設計時にADFビジネス・コンポーネントWebサービスを使用して作成されず、このドキュメントでは説明しません。

始める前に:

SDOフレームワークによって、サービス対応ADFアプリケーション・モジュールがどのようにサポートされ、Webサービス・クライアントのデータ行アクセスやサービス操作がどのように有効化されるかについて、理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

サービス対応アプリケーション・モジュールは、標準Webサービス(@WebServiceの注釈の付いたJavaクラスまたはJavaインタフェース)がすでに含まれているプロジェクトには作成しないでください。JDeveloperのデプロイメント・プロファイルでは、同じプロジェクトに属する標準WebサービスとADFビジネス・サービスのデプロイはサポートされません。標準Webサービスと同じプロジェクトに属するADFビジネス・サービスのWebサービスをデプロイしようとすると、Oracle WebLogic Server例外エラーが発生してデプロイメントが失敗します。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

- 「アプリケーション・モジュールの作成方法」の説明に従って、該当するアプリケーション・モジュールを作成します。

- オプションで、JDeveloperプリファレンスを設定して、生成されるSDOクラス名のデフォルト接尾辞の指定、サービス共通のインタフェースとクラスが入るサブパッケージの変更、および生成されるSDOスキーマとWebサービスのデフォルトのネームスペース接頭辞の設定を行います。「ADF Webサービス・インタフェース生成用プリファレンスの設定方法」を参照してください。

- サービスでカスタム検索操作を公開する場合は、「名前付きビュー基準を宣言的に作成する方法」の説明に従って、宣言的なビュー基準を作成してカスタム問合せを指定します。

Webサービス・インタフェースを作成するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「サービス・インタフェース」のナビゲーション・タブをクリックして、「サービス・インタフェースのサポートを有効にします。」ボタンをクリックします。
「サービス・インタフェースの作成」ウィザードを使用して、該当するオプションを構成します。

3. 「サービス・インタフェースの作成」ウィザードの「サービス・インタフェース」ページで、Webサービスの名前とターゲット・ネームスペースを入力します。
ターゲット・ネームスペースはサービスのURIで、同じURIを入力することで、類似のサービスをグループ化するために割り当てることができます。デフォルトのターゲット・ネームスペースは、「プリファレンス」ダイアログで指定したパッケージ名と組み合せたアプリケーション・モジュールのパッケージ名です。

ヒント:

URIを成形するJDeveloperプリファレンスを定義し、サービスの一意のターゲット・ネームスペースを定義できます。ネームスペースURI成形プリファレンスの詳細は、「ADF Webサービス・インタフェース生成用プリファレンスの設定方法」を参照してください。

4. アプリケーション・モジュールのメソッドを非同期サービス・メソッドとして公開し、Webサービスで同期と非同期の両方の操作を有効にするには、「非同期Webサービス・メソッドの生成」を選択します。
デフォルトでは、Webサービスは同期サービス・メソッドをサポートしています。これによってクライアント・アプリケーションを強制的に起動して待機させ、レスポンスが返されるまで作業を続行できません。レスポンスが即座に返る場合、このWebサービス呼出しの方法が一般的です。しかし、リクエスト処理が遅延する場合もあるため、クライアント・アプリケーションは先に処理を続行し、後でレスポンスを処理するほうが効率的なことも少なくありません。

5. 以前に定義したカスタマイズ・ロールに基づいてロール形成が定義されていないかぎり、Service Categoriesリストは空白になります。組織でサービスを分類していないかぎり、「選択済」は空白のままにしてください。
この機能はサービスWSDLファイルに影響がなく、Webサービス操作に関係しません。

6. 「サービス組込みメソッド」ページで、オプションで「オブジェクトと属性のコントロール・ヒント操作の生成」を選択して、ビュー・インスタンスに定義された静的コントロール・ヒント(UIヒント)とその属性を返すメソッドを生成します。
このオプションを有効にすると、ウィザードがgetDfltObjAttrHints()メソッドをクライアント・サービス・インタフェース(AppModuleService.java)に追加します。Webサービス・コンシューミング・アプリケーションは、このメソッドを起動して、データベース・ラウンドトリップを必要とせずにサーバー上のUIヒントを解決できます。メソッドはサービス・ビュー・オブジェクト名とロケール名を受け取り、特定のロケールに基づくオブジェクトについて、オブジェクトと属性の表示名ラベルを含むベースUIヒントを返します。ロケール名が指定されていない場合、メソッドはデフォルト・ロケールを使用します。

7. オプションで、「最終更新時間操作の生成」を選択して、サービス・スキーマ・ファイルの最終変更時刻を返すメソッドを生成します。
このオプションを有効にすると、ウィザードがgetServiceLastUpdateTime()メソッドをクライアント・サービス・インタフェース(AppModuleService.java)に追加します。カスタマイズが行われる前に、このメソッドは最終更新スキーマ・ファイルのファイル・タイムスタンプを返します。スキーマが実行時にカスタマイズされると、最終更新タイムスタンプが更新され、この最新のタイムスタンプが返されます。この機能は、主に、サービスXSDをキャッシュするWebサービス・コンシューミング・アプリケーションで役立ちます。

8. オプションで、「エンティティ・リスト操作の生成」を選択して、サービス・ビュー・インスタンスのリストを返すメソッドを生成します。
このオプションを有効にすると、ウィザードがgetEntityList()メソッドをクライアント・サービス・インタフェース(AppModuleService.java)に追加します。メソッドは、サービス・ビュー・インスタンス名、XSDタイプ、およびサービス・ビューが「作成」、「更新」、「マージ」および「削除」操作をサポートするかどうかを示すフラグのリストを返します。この機能は、主に、カスタマイズを必要とするWebサービス・コンシューミング・アプリケーションで役立ちます。

9. 「サービス・カスタム・メソッド」ページで、サービス・インタフェースに公開するカスタム・メソッドを追加し、各メソッドのパラメータと戻り値のデータ型を定義します。
有効にするカスタム・サービス・メソッドのパラメータとvoid以外の戻り値は、サービス・インタフェースでサポートされているデータ型(Javaプリミティブ・タイプなど)またはそのようなデータ型のリスト(oracle.jbo.server.ViewRowImpl、java.util.List<ViewRowImpl>、oracle.jbo.AttributeList、java.util.List<AttributeList>、java.util.List<PrimitiveType>など)である必要があります。

ViewRowImplおよびAttributeListの両方のデータ型は、Webサービス・クライアントに対して同一の行構造で公開されますが、実行時には基本的な違いがあります。サポートされているデータ型の詳細は、「ADF Webサービス・インタフェース上のメソッド・シグネチャに関する必知事項」を参照してください。

ViewRowImplまたはAttributeListデータ型を使用して、各パラメータと戻り値に対して、サービス・インタフェース内で使用可能なカスタム・メソッドを選択後、行構造に対応するビュー・オブジェクト・インスタンスの名前を選択する必要があります。

a. 「選択済」リストで、returnまたはparametersを展開して、項目を選択します。

b. Java要素データ型を「要素Javaタイプ」に入力します。

c. Java要素型がViewRowImplまたはAttributeListの場合は、「要素のビュー・オブジェクト」に行構造を識別するビュー・オブジェクト・インスタンス名を入力します。
たとえば、CustomerInfoビュー・オブジェクト・インスタンスの単一行を定義する場合、次のようなカスタム・メソッド・シグネチャが必要になります。

public ViewRowImpl findCustomerInfo(int id)

次にサービス・インタフェース内での表示用にfindCustomerInfo()カスタム・メソッドを選択した後、その戻り値をツリー内で選択し、「ビュー・オブジェクト」プロパティを、実行時に行構造を使用するビュー・インスタンスの名前であるCustomerInfoに設定します。

10. カスタム・メソッドの警告のサービス情報メッセージやプロセス処理メソッドの警告を公開するには、「戻りサービス・データ・オブジェクトに警告を含める」を選択します。
たとえば、従業員給与の合計を返すメソッドで合計が望ましい範囲を超えている場合に、情報メッセージを表示するとします。

「戻りサービス・データ・オブジェクトに警告を含める」が選択されていない場合、サービス・レスポンスとともに情報メッセージは返されません。

このオプションは、メソッドがビュー行やビュー行のリストを返さない場合にのみ有効になります。メソッドがビュー行を返す場合、メソッドで警告がサポートされるかどうかは、「個別のビュー・オブジェクトのサービス対応化の方法」で説明しているように、基礎となるビュー・オブジェクトによって決定されます。

情報メッセージ(および警告)は、戻りオブジェクトの一部として報告されます。JDeveloperにより、戻りオブジェクトとして適切なラッパーが生成され、このラッパーに実際のメソッド戻り値と情報メッセージが含まれています。

11. 「サービス・ビュー・インスタンス」ページで、サービス・インタフェースで公開する、アプリケーション・モジュール内の最上位ビュー・インスタンスを選択します。
最上位のビュー・レベル・インスタンスのビュー・オブジェクト・サブタイプは、自動的にサービス対応になります。

このページで、公開したメソッドでサポートされる、使用可能なデータ処理操作も有効にできます(図15-1を参照)。

図15-1 ビュー・インスタンスとCRUD操作の選択

12. 「基本操作」タブで、現在選択されているビュー・インスタンスのデータ処理操作を選択し、「メソッド名」フィールドで、選択したサービスの操作の名称を、サービス・インタフェースで公開する名前に変更します。
標準的なサービス操作の目的は、ビュー・オブジェクトのデータ処理操作を公開することです。サービス操作を起動することで、基になるフレームワーク・オブジェクトで定義したあらゆるビジネス・ロジック(たとえばビジネス・ルールの評価など)が、適用されます。サービス・ビュー・インスタンスでサポートされている操作の詳細は、表15-1を参照してください。

選択可能な検索メソッド操作の場合、検索メソッドはビュー・オブジェクトの問合せ文で必須バインド変数を参照してはなりません。必須バインド変数は、有効なバインド変数値がなければ問合せの実行ができないようにするものです。サービス・インタフェースは実行時には必須バインド変数を公開しません。このシナリオ用の検索操作の定義の詳細は、「必須バインド変数によってフィルタされる宣言的検索操作の公開方法」を参照してください。

13. 宣言的検索操作を公開するには、「ビュー基準の検索操作」タブを選択し、「ビュー基準の追加」アイコンをクリックします。
カスタム検索操作を定義して、事前に定義された問合せの実行をサービスにサポートさせることができます。名前付きビュー基準の定義の詳細は、「名前付きビュー基準の処理」を参照してください。

注意:

サービス・インタフェースの検索操作は、プロジェクトで定義された特定のビュー基準に基づいています。したがって、ビュー基準のバインド変数が対応する検索操作メソッドのパラメータと一致しなければなりません。検索操作を定義しサービス・インタフェースを生成した後、バインド変数の数や順番を変更すると、対応するメソッドが実行時に実行されなくなります。したがって基にあるビュー基準を変更したら、サービス・インタフェースを生成しなおす必要があります。

a. 「ビュー基準検索操作の構成」ダイアログで、検索操作用の名前付きビュー基準を選択します。
このダイアログには、参照先のビュー・オブジェクトが公開しているビュー基準のリストが表示されます。たとえば、OrdersViewはオーダーIDを指定するバインド変数OrdIdを使用して、OrdersViewCriteriaを定義しています(図15-2を参照)。

図15-2 名前付きビュー基準に基づく専用検索メソッド

b. ビュー基準でバインド変数が使用されている場合、XML名をダブルクリックして、XML定義内でそのサービスが表示される名前をカスタマイズできます。

14. 「次」をクリックして、サービス・ビュー・インスタンスによって公開されるカスタム・メソッドを確認します。

15. 「終了」をクリックします。

15.2.2 アプリケーション・モジュール・サービス・インタフェース作成時の処理

JDeveloperはサービス・インタフェース・クラスを生成し、選択したすべてのビュー・インスタンス・オプションを有効にします(図15-3を参照)。

サービス対応アプリケーション・モジュール用に生成されたファイルは変更しないでください。生成されたファイルにより、サービス・インタフェースに必要なメソッドが実装されます。この例外となるのは、サービス実装クラスにJava注釈を追加する必要があるユースケースです。たとえば、サービス・インタフェース実装クラスに注釈を追加することにより、「SOAPクライアントによるアクセス用にADF Webサービスを保護する方法」で説明しているように、セキュリティ・ポリシーを追加できます。

図15-3 アプリケーション・モジュールの概要エディタの「サービス・インタフェース」ページ

次の種類のファイルが生成され、「アプリケーション」ウィンドウの「プロジェクト」パネルで、アプリケーション・モジュールの「serviceinterface」ノードの下に表示されます(図15-4を参照)。

- Webサービス・インタフェース(例: ServiceAppModuleService.java)

- Webサービス・スキーマ・ファイル(例: ServiceAppModuleService.xsd)

- Webサービス定義ファイル(例: ServiceAppModuleService.wsdl)

- Webサービス実装クラス(例: ServiceAppModuleServiceImpl.java)

図15-4 アプリケーション・モジュールの下に表示されるサービス・インタフェース・ファイル

さらに、ADFビジネス・コンポーネント・サービスを初めて作成すると、connections.xmlファイルが作成されます。このファイルは、Webサービス・クライアント(コンシューミング・アプリケーション)のみで使用されますが、便宜的にサービス対応アプリケーションも一緒に生成されます。このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードの下に表示されます。

15.2.2.1 Webサービス・インタフェースで生成される注釈

Webサービス・インタフェースはWebサービス仕様(JSR-181)で指定されたメタデータの注釈を使用して、インタフェースをWebサービスとして公開する方法を指定します。この例は、SummitADF_Examplesワークスペースのoracle.summit.model.amserviceパッケージ内のServiceAppModuleアプリケーション・モジュールのWebサービス・インタフェース・クラスである、ServiceAppModuleService.javaの一部を示しています。

package oracle.summit.model.amservice.common.serviceinterface;
...
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.soap.SOAPBinding;
...
import oracle.summit.model.amservice.common.CustomerViewSDO;
import oracle.summit.model.amservice.common.OrderViewSDO;
...
import oracle.webservices.annotations.PortableWebService;
import oracle.webservices.annotations.SDODatabinding;
...
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.WRAPPED, style=SOAPBinding.Style.DOCUMENT)
@PortableWebService(targetNamespace="http://www.globalcompany.com/ServiceAppModuleService",
name="ServiceAppModuleService",
wsdlLocation=
"oracle/summit/model/amservice/common/serviceinterface/ServiceAppModuleService.wsdl")
@SDODatabinding(schemaLocation=
"oracle/summit/model/amservice/common/serviceinterface/ServiceAppModuleService.xsd")
public interface ServiceAppModuleService
{
public static final String NAME = ("http://www.globalcompany.com/ServiceAppModuleService")

@WebMethod(action="www.globalcompany.example.com/createCustomersView",
operationName="createCustomersView")
@RequestWrapper(targetNamespace="www.globalcompany.example.com/types/",
localName="createCustomersView")
@ResponseWrapper(targetNamespace="www.globalcompany.example.com/types/",
localName="createCustomersViewResponse")
@WebResult(name="result")
CustomersViewSDO createCustomersView(@WebParam(mode = WebParam.Mode.IN, name="customerView")
CustomersViewSDO customersView) throws ServiceException;
...
}

15.2.2.2 Webサービス・スキーマ・ファイルで生成されるWebサービス・スキーマ

Webサービス・スキーマ・ファイルはWebサービス・スキーマを示すXMLスキーマ・ファイルです(図15-5を参照)。

図15-5 Webサービス・スキーマ・ファイル

15.2.2.3 Webサービス定義ファイルで生成されるWSDL

Webサービス定義ファイルは、Web Service Definition Language (WSDL)仕様に準拠したXML構造化ドキュメント・ファイルで、生成されたWebサービスをエンドポイント、すなわちポートの集合として記述します。ポートは、ネットワーク・アドレスを再利用可能なバインドに関連付けることで定義されます。Webサービスに接続したクライアント・アプリケーションはWSDLを読み取り、サーバー上で提供されている機能を判断します。WSDLはサービス自体のエンドポイントも指定しており、デプロイ済のサービスの検索およびテストに使用できます。

図15-6は、WSDLビジュアル・エディタ内でServiceAppModuleアプリケーション・モジュール用に生成されたWebサービス用のWSDLを示しています。「ソース」タブを選択すると、WSDLをXMLドキュメントとして表示できます。

図15-6 WSDLドキュメント

15.2.2.4 サービス実行クラスにより指定されるステートレス・セッションBean

サービス実装クラスとは、Webサービス・インタフェースを実装し、ADFビジネス・コンポーネントの汎用的なサービス実装であるoracle.jbo.server.svc.ServiceImplクラスを拡張する、EJB 3.0ステートレス・セッションBeanです。次の例は、SummitADF_Examplesワークスペースのoracle.summit.model.amserviceパッケージ内のServiceAppModuleアプリケーション・モジュールのサービス実装クラスである、ServiceAppModuleServiceImpl.javaの一部を示しています。

package oracle.summit.model.amservice.server.serviceinterface;
...
import oracle.summit.model.amservice.common.CustomersViewSDO;
import oracle.summit.model.amservice.common.OrdersViewSDO;
import oracle.summit.model.amservice.common.serviceinterface.ServiceAppModuleService;

...
import oracle.webservices.annotations.PortableWebService;

@Interceptors({ ServiceContextInterceptor.class })
@Stateless(name="oracle.summit.model.amservice.common.ServiceAppModuleServiceBean",
mappedName="ServiceAppModuleServiceBean")
@Remote(ServiceAppModuleService.class)
@PortableWebService(targetNamespace="http://www.globalcompany.com/ServiceAppModuleService",
serviceName="ServiceAppModuleService", portName="ServiceAppModuleServiceSoapHttpPort",
endpointInterface="oracle.summit.model.amservice.common.
serviceinterface.ServiceAppModuleService")
public class ServiceAppModuleServiceImpl extends ServiceImpl implements ServiceAppModuleService
{
...
public CustomersViewSDO createCustomersView(CustomersViewSDO customersView)
throws ServiceException {
return (CustomersViewSDO) create(customersView, "CustomersView");
}

public CustomersViewSDO updateCustomersView(CustomersViewSDO customersView)
throws ServiceException {
return (CustomersViewSDO) update(customersView, "CustomersView");
}
...
}

15.2.2.5 connections.xmlファイルで定義される参照

connections.xmlファイルを使用すると、Webサービス・クライアントでファクトリ・クラスoracle.jbo.client.svc.ServiceFactoryを使用してサービスを検索できます。ADFビジネス・コンポーネント・サービス・ファクトリは、サービス・クライアントによるサービス検索を可能にするメカニズムです。サービス・ファクトリでは、ADF接続アーキテクチャとconnections.xmlファイルによって、サービス・エンドポイントの場所を管理します。ADFビジネス・コンポーネント・サービスを初めて作成すると、connections.xmlファイルが作成されます。このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードの下に表示されます。

次の例は、ADFビジネス・コンポーネント・サービスを初めて作成した際にJDeveloperによって作成される、最初のconnections.xmlエントリを示しています。

<Reference name="{http://www.globalcompany.com}ServiceAppModuleService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
<StringRefAddr addrType="serviceInterfaceName">
<Contents>oracle.summit.model.amservice.common.serviceinterface.
ServiceAppModuleService</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceEndpointProvider">
<Contents>ADFBC</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiName">
<Contents>ServiceAppModuleServiceBean#oracle.summit.model.amservice.
common.serviceinterface.ServiceAppModuleService</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaName">
<Contents>ServiceAppModuleService.xsd</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaLocation">
<Contents>oracle/summit/model/amservice/common/
serviceinterface/</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>

15.2.3 多相ビュー・オブジェクトを持つアプリケーション・モジュール・サービス・インタフェース作成すると行われる処理

モデル・プロジェクトがベース・ビュー・オブジェクトを拡張するサブタイプ・ビュー・オブジェクトを定義している場合、生成されたSDOサービス・インタフェースは、ベース・ビュー・オブジェクトに対しては厳密に型指定されますが、多相サブタイプに対しては異なります。たとえば、SalespersonViewExがSEmpViewを拡張し、属性CommissionPctを追加してサブタイプを定義すると想定します。サービス対応ビュー・インスタンス用のサービス・インタフェースを生成する場合、図15-7に示すように、「アプリケーション」ウィンドウに、サービス・インタフェースとサービス・オブジェクトが表示されます。

図15-7 多相サブタイプ用に生成されたサービス・オブジェクト

注意:

ベース・ビュー・オブジェクトとサブタイプ・ビュー・オブジェクトを定義するADFモデル・プロジェクトからSDOサービス・インタフェースを生成した後、生成されたサービス・スキーマ定義は、ベース・ビュー・オブジェクトに対しては厳密に型指定されますが、多相サブタイプに対しては異なります。このため、多相サブタイプ・ビュー・オブジェクトにアクセスする必要があるWebサービス・クライアントは、「コンシューミング・アプリケーションでの多相コレクションへのアクセス」で説明されているアプローチを使用します。

多相サブタイプは、アプリケーション・モジュール・データ・モデルで、ベース・サービス対応ビュー・インスタンスへのインポートとして指定されるため、JDeveloperはベース・サービス・オブジェクトからサブタイプ・サービス・オブジェクトを自動的に生成します。次の例は、追加の属性CommissionPctが定義されたSalespsersonViewExSDO.xsdサブタイプ・スキーマ定義を示しています。サブタイプ・スキーマは、ベース・サービス・オブジェクトSEmpViewSDOの属性を含みます。

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="/oracle/model/polymorphicvo/views/common/"
xmlns="/oracle/model/polymorphicvo/views/common/" elementFormDefault="qualified">
<xsd:include schemaLocation="SEmpViewSDO.xsd"/>
<xsd:complexType name="SalespersonViewExSDO">
<xsd:annotation>
<xsd:appinfo source="http://xmlns.oracle.com/adf/svc/metadata/">
<key xmlns="http://xmlns.oracle.com/adf/svc/metadata/">
<attribute>Id</attribute>
</key>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="SEmpViewSDO">
<xsd:sequence>
<xsd:element name="CommissionPct" type="xsd:decimal"
minOccurs="0" nillable="true"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="salespersonViewExSDO" type="SalespersonViewExSDO"/>
</xsd:schema>

生成されたサービス・インタフェースは、XSD <import>要素を使用して、多相サブタイプを公開します。次の例は、SalespersonViewExSDOサブタイプのインポート定義を含むサービス・インタフェースXSD AppModuleService.xsdを示しています。

<schema xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com/apps/hr/service/types/"     xmlns:tns="http://xmlns.oracle.com/apps/hr/service/types/"
xmlns:ns0="/oracle/model/polymorphicvo/views/common/"     xmlns:ns1="http://xmlns.oracle.com/adf/svc/types/">     <import namespace="http://xmlns.oracle.com/adf/svc/types/"
schemaLocation="classpath:/META-INF/wsdl/BC4JService.xsd"/>     <import namespace="/oracle/model/polymorphicvo/views/common/"
schemaLocation="../../../views/common/SalespersonViewExSDO.xsd"/>
<import namespace="/oracle/model/polymorphicvo/views/common/"
schemaLocation="../../../views/common/SDeptViewSDO.xsd"/>     <import namespace="/oracle/model/polymorphicvo/views/common/"
schemaLocation="../../../views/common/SEmpViewSDO.xsd"/>

図15-8は、Webサービス・スキーマが、各種の厳密に型指定されたサービス・オブジェクトと、多相サブタイプSalespersonViewExSDO用のインポート定義を表す方法を示しています。

図15-8 Web サービス・スキーマによる多相ビュー・オブジェクトの慣用名のインポート

15.2.4 ADF Webサービス・インタフェース上のメソッド・シグネチャに関する必知事項

アプリケーション・モジュールに対して、クライアント・インタフェースとサービス・インタフェースという2種類のインタフェースを定義できます。クライアント・インタフェースは、ADFモデルがUIクライアント用に使用します。サービス・インタフェースはアプリケーションの統合用で、外部のWebサービスまたはその他のアプリケーション・サービスによって使用されます(プログラミングによって、またはサービス対応エンティティ機能を使用して自動的に)。

アプリケーション・モジュールではインタフェースをまったくサポートしないことも、クライアント・インタフェースまたはサービス・インタフェースのいずれかだけをサポートすることも、両方を組み合せてサポートすることもできます。ただし、それぞれのインタフェース用に定義するカスタム・メソッドのパラメータや戻り値としてサポートされているデータ型は、2種類のインタフェースで異なっている点に注意してください。クライアント・インタフェースでサポートされている型の詳細は、「クライアント・インタフェースのメソッド・シグネチャに関する必知事項」を参照してください。

サービス・インタフェースは、クライアント・インタフェースよりも限定的なカスタム・メソッド・パラメータと戻り値をサポートしています(次に限定されている)。

- Javaプリミティブ・タイプとそのオブジェクト・ラッパー型(int、Integer、Longなど)

- java.lang.String

- java.math.BigDecimal

- java.math.BigInteger

- java.sql.Date

- java.sql.Time

- java.sql.Timestamp

- java.util.Date

- oracle.jbo.AttributeList

- oracle.jbo.domain.BlobDomain

- oracle.jbo.domain.Char

- oracle.jbo.domain.ClobDomain

- oracle.jbo.domain.DBSequence

- oracle.jbo.domain.Date

- oracle.jbo.domain.NClobDomain

- oracle.jbo.domain.Number

- oracle.jbo.domain.Timestamp

- oracle.jbo.domain.TimestampLTZ

- oracle.jbo.domain.TimestampTZ

- oracle.jbo.server.ViewRowImplまたは任意のサブタイプ

- java.util.List<aType>(aTypeは、Javaプリミティブ・タイプなど、サービス・インタフェースでサポートされている任意のデータ型)
注意: サービス・インタフェースは特にJava Mapコレクションをサポートしていません。つまり、型の異なるオブジェクトのコレクションを返すことはできません。ただし、コレクションはビュー行属性には限定されません。戻り型は、サービス・インタフェースでサポートされている任意のデータ型のリストとして定義できます。たとえば、List<DataObject>、List<AttributeList>およびList<String>はすべて有効な型です。

クライアント開発者が属性リストを使用して、カスタム操作を実行することで、カスタム・メソッドの実行前にフレームワークを使用しなくてもよくする場合は、AttributeListの型を戻すカスタム・メソッドを定義できます。あるいは、クライアント開発者がフレームワークを使用して行を管理(作成、検索および移入)する場合は、かわりにViewRowImplまたはList<ViewRowImpl>を戻すカスタム・メソッドを定義します。したがって、メソッド・シグネチャでデータ型としてViewRowImplまたはList<ViewRowImpl>が定義されている場合は、アプリケーションは自動的に次を行います。

1. 主キー、代替キーのいずれかまたは両方で、対応するビュー・オブジェクト・インスタンス内の行を検索

2. 行が検出されない場合は、新しい行を作成

3. 検出された行または新規行に属性の変更を適用

メソッド・シグネチャでAttributeListのデータ型が定義されている場合は自動動作は行われず、カスタム・メソッドで実行されるアクションおよび変更されるデータは、カスタム・メソッドのコードに限定されます。

15.2.5 行ファインダとADF Webサービス操作に関する必知事項

ビュー・オブジェクト行検索を作成すると、公開されるサービス・ビュー・インスタンスのサービス操作は、行検索により定義されるキー以外の属性を使用した行の参照をサポートします。たとえば、サービスで行検索を起動して、従業員ID (行キー属性)のかわりに従業員の電子メール・アドレスを使用して従業員を検索できます。行検索がビュー・オブジェクトの非キー属性で定義されていて、エンド・ユーザーがこの属性の値をWebサービス・ペイロードで指定する場合、サービスは自動的に行検索を起動して一致する行を特定します。電子メール・アドレスが行検索の唯一の必須の値である場合は、サービスの更新操作により、エンド・ユーザーは電子メール・アドレスでのみ識別される従業員のレコードを更新できます。サービス・ビュー・インスタンスで使用するための行検索の定義の詳細は、「行検索の使用」を参照してください。

15.2.6 個別のビュー・オブジェクトのサービス対応化の方法

アプリケーション・モジュール用の概要エディタを使用してWebサービス・インタフェースを有効にすることで、JDeveloperは親のビュー・インスタンス選択をService Data Object (SDO)コンポーネントとして自動的に有効化します。各ビュー・インスタンス用に生成されたSDOコンポーネントは同じネームスペースを参照し、警告のサポートの有無など、同じオプション設定で構成されます。概要エディタの「Java」ページを使用して、既存のサービス対応ビュー・オブジェクトのSDO定義をカスタマイズできます。「Java」ページを使用して、サービス・インタフェースにまだ追加されていなかったビュー・オブジェクトをサービス対応にすることもできます。たとえば、マスター/ディテール関係でマスターとなる親ビュー・オブジェクトを選択しても、子ビュー・オブジェクトは自動的にサービス対応となりません。子ビュー・オブジェクトの概要エディタで「Java」ページを使用して、サービス・インタフェースに個別に追加できます。

ビュー・オブジェクトの概要エディタで「Java」ページを使用して、ビュー・オブジェクトのSDO名とネームスペースを構成するか、子ビュー・オブジェクトを個別に選択してサービス対応にします。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

2. 「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」の説明に従って、アプリケーション・モジュールのサービス・インタフェースを有効にします。

3. オプションで、JDeveloperプリファレンスを設定して、生成されるSDOクラス名のデフォルト接尾辞の指定、サービス共通のインタフェースとクラスが入るサブパッケージの変更、および生成されるSDOスキーマとWebサービスのデフォルトのネームスペース接頭辞の設定を行います。「ADF Webサービス・インタフェース生成用プリファレンスの設定方法」を参照してください。

ビュー・オブジェクトのSDO名とネームスペースを設定する手順:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」ボタンをクリックします。

3. 「Javaオプションの選択」ダイアログの「サービス・データ・オブジェクト」セクションで、「サービス・データ・オブジェクト・クラスの生成」を選択します。サービス・オブジェクト名と、サービス・データ・オブジェクトのターゲット・ネームスペースの値を入力します。

ターゲット・ネームスペースは、SDOコンポーネントのURIです。同じURIを入力して類似のSDOコンポーネントをグループ化する場合に割り当てることができます。

SDOコンポーネントのパッケージ名を基に、ピリオドを「/」に置き換えたデフォルトのSDOネームスペースが作成されます。「プリファレンス」ダイアログの「サービス」ページで、ネームスペースの接頭辞を定義している場合は、実行時に、その接頭辞がネームスペースの冒頭に追加されます。たとえば、図15-9はパッケージ名に基づくデフォルト・ネームスペースを示しています。

図15-9 サービス・データ・オブジェクト名とネームスペース・オプション

4. サービス・インタフェース・オブジェクトのビュー行に関連する警告を抽出できるようにする場合は、「警告のサポート」を選択します。

たとえば、ビュー・オブジェクトに、Salary属性に対して定義された範囲バリデータがあり、このバリデータの失敗処理が情報警告として指定されているとします。

「警告のサポート」が選択されていない場合、サービス・レスポンスとともに情報メッセージは返されません。

警告が有効になっており、基礎となるADFビジネス・コンポーネント・オブジェクトから標準のサービス操作またはカスタム操作のいずれかに警告が生成された場合は、レスポンス・オブジェクトによって警告情報が取得されます。「SDO結果クラスおよびインタフェースにより実装されるコンテナ・オブジェクト」で説明しているように、サービス・オブジェクト結果クラスに対して生成されたメソッドを使用して、ビュー行からメッセージを抽出できます。

5. 「OK」をクリックします。

15.2.7 サービス対応ビュー・オブジェクトのSDOプロパティのカスタマイズ方法

ビュー・オブジェクトの概要エディタを使用して、サービス対応ビュー・オブジェクトのSDOコンポーネント定義をカスタマイズできます。デフォルトでは、サービス対応ビュー・オブジェクトはSDOプロパティとして公開されます。ビュー・オブジェクト定義をカスタマイズすることで、サービス・インタフェースから個別のSDOプロパティを除外できます。数値を定義するSDOプロパティの場合は、2つのプロパティを関連付けて、サービス・インタフェースに単一の複合型として表示させることができます。たとえば、通貨または測定単位を定義する1つのプロパティを、数値を表示する別なプロパティに関連付けることができます。現在サポートされているのは、AmountType(通貨コード)およびMeasureType(測定単位)の複合サービス型だけです。

15.2.7.1 生成されたSDOコンポーネントでの個別SDOプロパティの除外

アプリケーション・モジュール用の概要エディタを使用してWebサービス・インタフェースを有効にすることで、JDeveloperは親のビュー・インスタンス選択をSDOコンポーネントとして自動的に有効化します。さらに、子ビュー・オブジェクトを個別に選択してサービス対応とし、SDOコンポーネントを生成できます。デフォルトでは、生成されたSDOコンポーネントは、基本ビュー・オブジェクト定義のすべての属性をSDOプロパティとして公開します。サービス・インタフェースにSDOプロパティとして戻させたくない属性は、非表示にできます。

概要エディタの「属性」ページを使用して、サービス・インタフェースから除外するビュー・オブジェクト属性を選択します。 次に、ビュー・オブジェクトの概要エディタの「詳細」タブを使用して、選択した属性をSDOコンポーネントで非表示にします。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

2. 「個別のビュー・オブジェクトのサービス対応化の方法」の説明に従って、該当するビュー・オブジェクトをサービス対応にします。

サービス対応ビュー・オブジェクトからSDOプロパティを除外する手順:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、除外するプロパティに対応する属性を選択し、「詳細」タブをクリックして、「SDOプロパティ」の選択を解除します。

15.2.7.2 複合データ型を使用した関連するSDOプロパティの関連付け

ビュー・オブジェクトをサービス対応にすると、JDeveloperは基になっているビュー・オブジェクトのデータ型に対応するXSD定義済のサービス・タイプとして、SDOプロパティを自動的に公開します。数値を定義する属性の場合は、次のいずれかの事前定義済サービス・タイプを使用して関係のあるプロパティに関連付けるように、SDOプロパティのサービス・タイプを変更できます。

- AmountTypeサービス・タイプは、通貨コードを定義する任意のプロパティ用です。

- MeasureTypeサービス・タイプは、測定単位を定義する任意のプロパティ用です。

SDOプロパティのサービス・タイプをこのいずれかの複合型に変更すると、サービス・インタフェースが2つのプロパティを一緒に関連付け、単一のXML要素として戻します。SDOコンポーネントの両方のプロパティを、基本サービス対応ビュー・オブジェクトの属性で定義しておく必要があります。

たとえば、ビュー・オブジェクトでOrderTotal属性およびCurrencyCode属性を定義し、対象の国での通貨コードを指定すると仮定します。デフォルトでは、サービス・インタフェースはこれらの属性をSDOプロパティとして公開し、各プロパティを個別のXML要素として戻します。

<OrderTotal>100.00</Price>
<CurrencyCode>USD</CurrencyCode>

OrderTotalプロパティの型を(XSDファイルがこのプロパティをdecimal型として定義していると仮定)から複合型AmountTypeに変更し、CurrencyCodeプロパティを関連付けた場合、サービス・インタフェースはそれらを単一のXML要素として戻します。

<OrderTotal CurrencyCode="USD">123.00</OrderTotal>

また、「アプリケーション・モジュールでプロキシ・クラスを使用したWebサービス・メソッドのコール」で説明しているように、Webサービス・プロキシを生成すると、2つの値はクラスで1つのオブジェクトとして扱われます。

AmountType price;
...
price.setValue(123.00);
price.setCurrencyCode("USD");

概要エディタの「属性」ページを使用して、カスタマイズするサービス・タイプのビュー・オブジェクト属性を選択します。 概要エディタの「属性」ページから表示される「属性の編集」ダイアログを使用して、選択した属性のSDOプロパティを関連付け、事前定義済の複合サービス・タイプを選択します。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

2. 「個別のビュー・オブジェクトのサービス対応化の方法」の説明に従って、該当するビュー・オブジェクトをサービス対応にします。

サービス対応ビュー・オブジェクト内のSDOプロパティを関連付ける手順:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、別のSDOプロパティに関連付けるプロパティに対応する属性を選択します。

選択する属性は、数値型を定義する必要があります。たとえば、通貨コードを、顧客が支払った金額を表示する属性と関連付けるには、Ordersサービス対応ビュー・オブジェクトのOrderTotal属性を選択します。

4. 属性を選択したら、「詳細」タブをクリックして、「XSDタイプ」ドロップダウン・リストから目的のサービス・タイプを選択します。

「XSDタイプ」ドロップダウンが有効でない場合は、概要リストに戻って数値型の属性を選択します。値が数値型ではない属性を、使用可能な複合サービス・タイプに関連付けることはできません。

SDOフレームワークは、複合サービス・タイプ、AmountTypeおよびMeasureTypeをサポートしています。関連付けるプロパティが通貨情報を指定する場合は、AmountTypeを選択します。関連するプロパティが測定単位を指定する場合は、MeasureTypeを選択します。

5. currencyCodeまたはunitCodeドロップダウン・リストで、ビュー・オブジェクト属性を選択して複合型を定義します。

ダイアログが切り替わり、XSDタイプの選択に応じたドロップダウン・リストが表示されます。通貨コードまたは測定単位を決定するために使用される属性を選択します。

15.2.8 サービス対応マスター/ディテール・ビュー・オブジェクトにおけるネスト処理のサポート方法

データ・モデルで親と子のビュー・オブジェクト間のマスター/ディテール関係を定義した場合、マスター・ビュー・オブジェクトに対して有効化するサービス操作が、ディテール・ビュー・オブジェクトでは自動的に実行されない場合があります。デフォルトでは、ディテール・ビュー・オブジェクトに対するポスト操作は、マスター・ビュー・オブジェクトのプライマリ関連元エンティティ・オブジェクトがディテール・ビュー・オブジェクトのプライマリ関連先エンティティ・オブジェクトで構成されている場合にのみサポートされます。このマスター/ディテール関係はコンポジット・アソシエーションとして知られ、「コンポジット・アソシエーションに関する必知事項」で説明するように、関連元エンティティ・オブジェクトにネストされた論理的部分として関連先エンティティ・オブジェクトが含まれる場合にJDeveloperで作成されます。

親とともに子の詳細をポストする、作成、マージ、更新および処理メソッドをサポートするには、次のいずれかのシナリオに従ってビュー・リンクを作成し、マスター/ディテール関係を作成する必要があります。

- ビュー・リンクがコンポジット・アソシエーションを使用しており、ディテール・ビュー・オブジェクトに対するポスト操作がデフォルトでサポートされる場合。

- ビュー・リンクがアソシエーションに基づいており、アソシエーションにリンク先アクセッサが生成されており、アソシエーションにカスタム・プロパティSERVICE_PROCESS_CHILDREN=trueが定義されている場合。

- ビュー・リンクはアソシエーションに基づいていないが、カスタム・プロパティSERVICE_PROCESS_CHILDREN=trueが定義されている場合。

カスタム・プロパティは、ビュー・リンクが定義された任意のビュー・オブジェクトで、コンポジット・アソシエーションを使用せずにネストされた処理をサポートできる便利な方法です。概要エディタでSERVICE_PROCESS_CHILDRENを、ビュー・リンクまたはビュー・リンクのアソシエーション(存在する場合)のカスタム・プロパティとして定義できます。

親と一緒に子の詳細も入手する取得および検索メソッドをサポートするには、マスターおよびディテール・ビュー・オブジェクト間のビュー・リンクでリンク先アクセッサを生成しておく必要があります。リンク先アクセッサでにより、マスターから詳細なビュー・オブジェクトまでの階層が通過できます。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

ビュー・リンクまたはエンティティ・アソシエーションを使用したマスター・ディテール関係の定義方法を理解しておくと、役立つ場合があります。

- ビュー・リンクの詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。

- アソシエーションの詳細は、「アソシエーションの作成と構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 該当するビュー・オブジェクトを作成し、「個別のビュー・オブジェクトのサービス対応化の方法」の説明に従い、マスター/ディテール階層の子ビュー・オブジェクトをサービス対応にします。

2. ビュー・リンクがアソシエーションに基づいていない場合は、概要エディタでビュー・リンクを開き、「関係」ページを表示して、そのビュー・リンクのリンク先アクセッサがあることを確認します。アクセッサを生成し、「関係」ページに表示させるには、「アクセッサの編集」ボタンをクリックし、「ビュー・リンク」ダイアログ内でリンク先アクセッサに対してビュー・オブジェクトでアクセッサを作成を選択します。
ビュー・リンクがアソシエーションに基づいている場合は、アソシエーションのリンク先のエンティティ・オブジェクトに対して、リンク先アクセッサが存在している必要があります。リンク先アクセッサを作成するには、アソシエーションの概要エディタの「関連」ページを使用します。

マスター/ディテール階層でのネスト処理のサポート手順:

1. マスター/ディテール階層のビュー・リンクがアソシエーションに基づいていない場合は、「アプリケーション」ウィンドウで、ビュー・リンクをダブルクリックします。ビューがアソシエーションに基づいている場合は、「アプリケーション」ウィンドウ内でアソシエーションをダブルクリックします。

概要エディタの「関係」ページで、ビュー・リンクの作成方法を確認できます。「属性」セクションで、リンク元とリンク先の属性名を指定します。リンクがアソシエーションに基づいている場合は、属性ハイパーリンクにアソシエーション名が含まれます。それ以外の場合は、ハイパーリンクに基本エンティティ・オブジェクトの名前が含まれます。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

ビュー・リンクの概要エディタとアソシエーションに、同様の選択内容が表示されます。

3. 「一般」ページの「カスタム・プロパティ」セクションを開き、「カスタム・プロパティの追加」アイコンをクリックして、プロパティにSERVICE_PROCESS_CHILDRENを、プロパティ値にtrueを入力します(図15-10を参照)。

図15-10 ネスト処理をサポートするカスタム・プロパティ

15.2.9 SDOクラス作成時の処理

SDOクラスを作成すると、次のファイルが生成され、「アプリケーション」ウィンドウ内の所有ビュー・オブジェクトの下に表示されます。

- サービス・データ・オブジェクト・インタフェース

- サービス・データ・オブジェクト・クラス

- サービス・データ・スキーマ・ファイル

- サービス・データ・オブジェクト結果クラスとインタフェースは、「Javaオプションの選択」ダイアログで「警告のサポート」を有効化すると生成されます。

サービス対応ビュー・オブジェクト用に生成されたファイルは変更しないでください。生成されたファイルにより、ビュー・オブジェクトのSDOインタフェースに必要なメソッドが実装されます。

15.2.9.1 SDOインタフェース内で生成されるプロパティ・アクセッサ

次の例に示すように、ビュー・オブジェクトSDOインタフェースには、SDOプロパティに対して強く型付けされたアクセッサが含まれています。

package oracle.summit.model.amservice.common;
public interface OrdersViewSDO extends java.io.Serializable {
public java.math.Integer getId();
public void setId(java.lang.Integer value);
...}

15.2.9.2 SDOクラスにより実装されるビュー・オブジェクト・インタフェース

ビュー・オブジェクトSDOクラスはビュー・オブジェクトSDOインタフェースを実装し、OracleによるSDO仕様の実装であるSDODataObjectクラスを拡張します。

実行時は、SDOオブジェクトのインスタンスはメモリー内の行を示します。

SDOクラスはビュー行クラスと類似しています(次の例を参照)。

package oracle.summit.model.amservice.common;
import org.eclipse.persistence.sdo.SDODataObject;
public class OrdersViewSDOImpl extends SDODataObject implements OrdersViewSDO
{
...
}

15.2.9.3 SDOスキーマ・ファイルで生成されるビュー・オブジェクト・スキーマ

図15-16に示すようなビュー・オブジェクトSDOスキーマ・ファイルは、SDOスキーマを示すXMLスキーマ・ファイルです。

図15-11 生成されたSDOスキーマ

15.2.9.4 SDO結果クラスおよびインタフェースにより実装されるコンテナ・オブジェクト

ビュー・オブジェクトSDO結果クラスは、サービス操作がビュー行のリスト(サービス・データ・オブジェクトでラップされている)およびこれらのビュー行に関連付けられた警告リストを戻せるようにする、コンテナ・オブジェクトです。具体的には、サービスの取得操作で元のオブジェクトが返され、作成、更新、マージ、検索および処理操作で元のオブジェクトのリストと情報メッセージのリストを含むラッパー・オブジェクトが、削除操作では情報メッセージのみが返されます。サービス対応ビュー・オブジェクトの「警告のサポート」オプションを有効にしている場合は、生成されたメソッド結果インタフェースを使用して警告を抽出できます。

次の例に示すようなビュー・オブジェクトSDO結果クラスは、ビュー行クラスに類似しています。

package oracle.summit.model.amservice.common;
import oracle.sdo.SDODataObject;
public class OrdersViewSDOResultImpl extends
oracle.jbo.common.service.types.MethodResultImpl implements OrdersViewResult {

public static final int START_PROPERTY_INDEX =
oracle.jbo.common.service.types.MethodResultImpl.END_PROPERTY_INDEX + 1;
public static final int END_PROPERTY_INDEX = START_PROPERTY_INDEX + 0;
public OrdersViewResultImpl() {}
public java.util.List getValue() {
return getList(START_PROPERTY_INDEX + 0);
}

public void setValue(java.util.List value) {
set(START_PROPERTY_INDEX + 0 , value);
}
}

15.2.10 必須バインド変数による宣言的検索操作の公開方法

ADFサービス・インタフェース・フレームワークにより、宣言的検索操作を公開して、選択したビュー・オブジェクトによる問合せ定義を行えます。ただし、その問合せがバインド変数を使用して問合せ結果をフィルタしている場合は、バインド変数を「必須」および「更新可能」として指定する必要があります。サービス・インタフェースは必須の更新可能バインド変数を公開しないので、この種のビュー・オブジェクトに対して実行する検索操作では、結果が戻されません。

バインド変数を使用して問合せ結果をフィルタする場合は、ビュー基準を使用して、サービス・インタフェース上での検索操作として公開します。作成するビュー基準に基づくサービス・インタフェースの検索操作には、必須バインド変数を指定できます。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

また、バインド変数を使用したビュー・オブジェクト問合せのフィルタ処理方法を理解しておくと役立つ場合があります。詳細は、「バインド変数の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「アプリケーション・モジュールの作成方法」の説明に従って、該当するアプリケーション・モジュールを作成します。

2. 「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー基準を作成します。「ビュー基準の編集」ダイアログで、基準アイテムをバインド変数として設定し、「検証」フィールドを「必須」に設定します。このような選択によって、有効な値がなければ問合せが実行されなくなります。

必須バインド変数のあるビュー基準に対して検索操作を公開する手順:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「サービス・インタフェース」ナビゲーション・タブをクリックして、「サービス・インタフェースの属性を編集します。」アイコンをクリックします。

サービス・インタフェースを定義済の場合は、かわりに「サービス・カスタム・メソッドの編集」を選択することもできます。

3. 「サービス・インタフェースの編集」で、ナビゲーション・リストから「サービス・ビュー・インスタンス」を選択し、名前付きのビュー基準でフィルタするビュー・オブジェクトを「選択済」リストに追加します。

4. 検索操作を公開するには、ビュー・インスタンスを選択し、「ビュー基準の検索操作」タブをクリックし、「ビュー基準の追加」ボタンをクリックします。

5. 「ビュー基準検索操作の構成」ダイアログで、検索操作用の名前付きビュー基準を選択します。

ダイアログには、選択したビュー基準のバインド標準が表示されます。

6. サービスのXML定義で表示されるバインド変数名をカスタマイズする場合は、「検索操作パラメータ」セクションでXML名をダブルクリックして名前を編集します。

7. 「OK」をクリックします。

15.2.11 必須バインド変数でフィルタするカスタム検索メソッドの公開方法

ビュー基準に依存する宣言的検索操作を公開するかわりに、データ・モデル・プロジェクトのアプリケーション・モジュール実装クラス内でサービス・メソッドを定義できます。この目的で作成するクラスでは、ビジネス・サービス機能を、実装する単一メソッドにカプセル化できます。カスタム・アプリケーション・モジュールの目的の詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」を参照してください。

次の例は、AppModuleNameImpl.javaファイルで実装されているカスタム検索メソッドを示しています。このメソッドは、バインド変数を設定し、ビュー・オブジェクト・インスタンス問合せを行います。ビュー・オブジェクト・インスタンス上でsetNamedWhereClauseParam()を使用して、バインド変数を設定します。問合せ実行前に、検索メソッドが前方のみモードでビュー・オブジェクトを設定し、検索メソッドが繰り返し処理するビュー行のキャッシングを行わないようにします。

public class AppModuleImpl extends ApplicationModuleImpl
{
public List<ViewRowImpl> findProducts(String location)
{
List<ViewRowImpl> result = new ArrayList<ViewRowImpl>();
ViewObjectImpl vo = getProductsView1();
vo.setNamedWhereClauseParam("TheLocation", location);
vo.setForwardOnly(true);
vo.executeQuery();
while (vo.hasNext()) {
result.add((ViewRowImpl)vo.next());
}
return result;
}
}

始める前に:

SDOフレームワークによって、サービス対応ビュー・オブジェクトがどのようにサポートされ、Webサービス・クライアントのデータ行アクセスやサービス操作がどのように有効化されるかについて、理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

また、バインド変数を使用したビュー・オブジェクト問合せのフィルタ処理方法を理解しておくと役立つ場合があります。詳細は、「バインド変数の使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「アプリケーション・モジュールのカスタム・クラスの生成方法」の説明に従い、カスタム・アプリケーション・モジュール・クラスを作成します。

2. 「実行時に名前付きバインド変数を含むWHERE句を追加する方法」の説明に従い、問合せ結果をプログラム的にフィルタし、必要なバインド変数を設定するための、カスタム検索メソッドを作成します。

必須バインド変数を設定する検索メソッドの公開手順:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「サービス・インタフェース」ナビゲーション・タブをクリックして、「サービス・インタフェースの属性を編集します。」アイコンをクリックします。

サービス・インタフェースをすでに定義している場合は、「サービス・カスタム・メソッドの編集」アイコンをクリックしてもかまいません。

3. 「サービス・インタフェースの編集」ダイアログで、ナビゲーション・リストから「サービス・ビュー・インスタンス」を選択し、定義した検索メソッドを「選択済」リストに追加します。

4. 「OK」をクリックします。

15.2.12 非同期ADF Webサービス・メソッドの生成方法

デフォルトでは、Webサービスは同期サービス・メソッドをサポートしています。これによってクライアント・アプリケーションを強制的に起動して待機させ、レスポンスが返されるまで作業を続行できません。レスポンスが即座に返る場合、このWebサービス呼出しの方法が一般的です。しかし、リクエスト処理が遅延する場合もあるため、クライアント・アプリケーションは先に処理を続行し、後でレスポンスを処理するほうが効率的なことも少なくありません。

始める前に:

SDOフレームワークによって、サービス対応ビュー・オブジェクトがどのようにサポートされ、Webサービス・クライアントのデータ行アクセスやサービス操作がどのように有効化されるかについて、理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

また、非同期のリクエストとレスポンスを使用したWebサービスの起動について理解しておくと役立つ場合があります。詳細は、『Oracle Infrastructure Webサービスの開発』の「非同期Webサービスの開発」、非同期Webサービスの概要に関する項を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 非同期Webサービスをデプロイする前に、リクエストおよびレスポンスを格納するためのキューを構成する必要があります。リクエストおよびレスポンス・キューの構成の詳細は、『Oracle Infrastructure Webサービスの開発』の「非同期Webサービスの開発」、リクエストおよびレスポンス・キューの作成に関する項を参照してください。

非同期Webサービス・メソッドの公開手順:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「サービス・インタフェース」ナビゲーション・タブをクリックして、「サービス・インタフェースの属性を編集します。」アイコンをクリックします。

3. 「サービス・インタフェース」ページの「サービス・インタフェースの編集」ダイアログで、「非同期Webサービス・メソッドの生成」を選択します。

4. 「OK」をクリックします。

15.2.13 非同期ADF Webサービス・メソッドの生成時の処理

JDeveloperはWebサービスのサービス・インタフェースを生成し、非同期サービス操作を有効にします。次の例に示すように、クラスの注釈@AsyncWebServiceはEmpServiceサービス・インタフェースを非同期と宣言し、インタフェース内の各同期メソッドに対して、サービスが同じメソッド名にAsyncが付加された非同期メソッドを公開します。

同じインタフェース内で同期および非同期の両方のメソッドを公開することで、Webサービス・クライアント開発者は、Webサービス・プロキシによる操作(適切な名前が付いたメソッドのコール)の起動方法を決定できます。開発者は、oracle.jbo.client.svc.ServiceFactory.getServiceProxy()メソッドから戻されるADFビジネス・コンポーネント・サービス・プロキシで非同期メソッドを起動してはならない点に注意してください。

この例では、EmpServiceサービスが非同期操作用に有効化されているため、インタフェースはgetEmployeeAsync()メソッドを公開して、@CallbackMethod(exclude=true)メソッド注釈を使用してデフォルト操作をオーバーライドし、getEmployee()メソッドを同期として宣言しています(非同期サービス内のメソッドを同期として宣言しているのは、exclude=trueの部分)。クラス注釈@AsyncWebServiceがある場合は、非同期サービス・メソッドの宣言に注釈は不要です。

import javax.xml.ws.Action;
...
import oracle.webservices.annotations.async.AsyncWebService;
import oracle.webservices.annotations.async.CallbackMethod;

@SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.WRAPPED, style=SOAPBinding.Style.DOCUMENT)
@PortableWebService(targetNamespace="http://xmlns.example.com/apps/service/", name="EmpService",
wsdlLocation="oracle/apps/service/EmpService.wsdl")
@SDODatabinding(schemaLocation="oracle/apps/service/EmpService.xsd")
@AsyncWebService
public interface EmpService
{
...

@WebMethod(action="http://xmlns.example.com/apps/service/getEmployee",
operationName="getEmployee")
@RequestWrapper(targetNamespace="http://xmlns.example.com/apps/service/types/",
localName="getEmployee")
@ResponseWrapper(targetNamespace="http://xmlns.example.com/apps/service/types/",
localName="getEmployeeResponse")
@WebResult(name="result")
@CallbackMethod(exclude=true)
Emp getEmployee(@WebParam(mode = WebParam.Mode.IN, name="empno") Integer empno)
throws ServiceException;

@WebMethod(action="http://xmlns.example.com/apps/service/getEmployeeAsync",
operationName="getEmployeeAsync")
@RequestWrapper(targetNamespace="http://xmlns.example.com/apps/service/types/",
localName="getEmployeeAsync")
@ResponseWrapper(targetNamespace="http://xmlns.example.com/apps/service/types/",
localName="getEmployeeAsyncResponse")
@WebResult(name="result")
@Action(input="http://xmlns.example.com/apps/service/getEmployeeAsync",
output="http://xmlns.example.com/apps/service/getEmployeeAsyncResponse")
Emp getEmployeeAsync(@WebParam(mode = WebParam.Mode.IN, name="empno") Integer empno);
}

重複した非同期メソッドはサービス実装で同期メソッドに移譲されます(次の例を参照)。これにより、基になっているビジネス・ロジックが、同期または非同期として宣言された操作と同一になります。

...
import oracle.webservices.annotations.async.AsyncWebService;

@Stateless(name="oracle.apps.service.EmpServiceBean", mappedName="EmpServiceBean")
@Remote(EmpService.class)
@PortableWebService(targetNamespace="http://xmlns.oracle.com/apps/service/",
serviceName="EmpService", portName="EmpServiceSoapHttpPort",
endpointInterface="oracle.apps.service.EmpService")
@Interceptors(ServiceContextInterceptor.class)
@AsyncWebService
public class EmpServiceImpl extends ServiceImpl implements EmpService
{
...

/**
* getEmployee: generated method. Do not modify.
*/
public Emp getEmployee(Integer empno)
throws ServiceException
{
return (Emp) get(new Object[] { empno }, "Employee", Emp.class);
}

/**
* getEmployeeAsync: generated method. Do not modify.
*/
public Emp getEmployeeAsync(Integer empno)
throws ServiceException
{
return getEmployee(empno);
}
}

15.2.14 実行時の非同期コール時の処理

クライアントから見ると、非同期コールは一方向の2つのメッセージ交換から構成されます。図15-12のシーケンス図は、次のフローを示しています。

1. クライアントが非同期操作をコールします。(図中のステップ1。)

2. 非同期サービスはリクエストを受信し、リクエストを実際には処理せずに、HTTP確認をクライアントに戻します。(図中のステップ2。)

3. 最終的には非同期操作が完了し、サーバー側のモジュールがレスポンスをクライアント側に送信します。(図中のステップ3。)
クライアント側でレスポンスを受信するには、クライアントにサーブレットまたはWebサービスなど、なんらかのHTTPリスナーが必要です。

4. クライアント側で生成されたWebサービス(コールバック・サービス)が、非同期レスポンスを受信します。(図中のステップ4。)
ステップ3ではサーバー側のモジュールが、コールバック・サービスに対してクライアントのように機能するので、コールバック・クライアントと呼ばれます。

図15-12 非同期コール・シーケンス

15.2.15 ADF Webサービス・インタフェース生成用プリファレンスの設定方法

JDeveloperで生成されたサービスに対しては、追加のコントロールが可能です。JDeveloperプリファレンスを設定して、次のタスクを実行できます。

- 生成されたSDOクラスの名前のデフォルトの接尾辞の指定

- サービス・インタフェースとクラスが存在するデフォルト・サブパッケージの変更

- デフォルトのネームスペース接頭辞の設定およびURIから除外するパッケージの名前の指定による、生成されたSDOスキーマおよびWebサービス・ターゲット・ネームスペースのURIの成形。

SDOクラス名接尾辞の設定手順:

1. メイン・メニューで、「ツール」、「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を開き、「クラス・ネーミング」を選択します。

3. 「ビュー・オブジェクト」接尾辞リストに、たとえばSDOのような、SDOの接尾辞を入力します。

生成されたサービス・インタフェースにデフォルト・サブパッケージを設定する手順:

1. メイン・メニューで、「ツール」、「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」 を展開し、「パッケージ」を選択します。

3. 「クラスに対する関連パッケージの指定」リストで、デフォルト・パッケージ名を指定します。

- サービス・インタフェース・パッケージ名を設定するには、「クライアント・インタフェース」に値を入力します。(「サービス・インタフェース」に、クライアント・インタフェースに指定したのと同じパッケージ名が表示されます)。デフォルト・パッケージ名はcommonです。

- 「サービス・インタフェース」の「サービス・インタフェース・サブパッケージ」に値を入力します。デフォルトのサブパッケージ名はserviceinterfaceです。

たとえば「サービス・インタフェース」にcommon、「サービス・インタフェース・サブパッケージ」にserviceinterface(デフォルト)を入力すると、データ・モデル・パッケージoracle.summit.model.amservice内のデータ・モデル・コンポーネントのサービス・インタフェースが、サブパッケージoracle.summit.model.amservice.common.serviceinterfaceに配置されます。

生成されたSDOスキーマおよびサービス・インタフェース・ターゲット・ネームスペースのURIを成形する手順:

1. メイン・メニューで、「ツール」、「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログで、「ADFビジネス・コンポーネント」を展開し、「サービス」を選択します。

3. 「デフォルト・ネームスペース接頭辞」の値を入力し、生成されるSDOスキーマとWebサービスの冒頭に追加されるようにします。

たとえば、「ビュー・オブジェクトの作成」ウィザードのJavaページの「サービス・データ・オブジェクト・クラスの生成」を有効にすると、ネームスペース接頭辞www.globalcompany.example.comがSDOのパッケージ名に追加され、ターゲット・ネームスペースwww.globalcompany.example.com/oracle/summit/model/amservice/common/が作成されます。

4. 「除外するパッケージ」のパッケージ名のセミコロン区切りリストを入力して、デフォルトのターゲット・ネームスペースのURIを成形します。

たとえば、ネームスペース接頭辞www.globalcompany.example.comを入力し、SDOのパッケージ名がglobalcompany.summit.model.amservice/の場合、生成されるターゲット・ネームスペースはパッケージ名globalcompanyを間違って複製します。この状況では、パッケージ名globalcompanyを除外して、ターゲット・ネームスペースのURIをwww.globalcompany.example.com/summit/model/amservice/common/として成形できます。

複数のパッケージ名をセミコロン区切りリストで除外できます。a;a.bは<namespace-prefix>/c/dを生成します。サブパッケージ名の場合は、完全修飾パッケージ名を指定してください。たとえば、パッケージ名a.b.c.dでパッケージcを除外するには、a.b.cと入力します。この場合、デフォルトのターゲット・ネームスペースは<namespace-prefix>/a/b/d/を生成します。

15.2.16 サービス・ビュー・インスタンスと属性の表示名の設定方法

表示名は、ユーザー・インタフェースをプログラムで生成し、サービス・ビュー・インスタンスとその属性を正しい識別ラベルとともに表示するために、Webサービス・コンシューミング・アプリケーションをサポートするラベルです。コンシューミング・アプリケーションで実行時にこれらの表示名にアクセスできるようにするには、「サービス・インタフェースの作成」ウィザードを使用して、組込みメソッドgetDfltObjAttrHints()をリモート・クライアント・サービス・インタフェースに追加します。このメソッドでは、コンシューミング・アプリケーションの開発者が、サービス・ビュー・インスタンスとその属性に関連付けられた「表示名」UIヒントをプログラムで取得できます。ビュー・オブジェクトの「プロパティ」ウィンドウでUIヒントを定義します。ここでは、各ビュー・インスタンス名と属性名の単一ラベルおよび複数ラベルを定義できます。たとえば、図15-13に示すように、OrdersVOビュー・オブジェクトのUIヒントをラベルOrderおよびOrdersで定義できます。

図15-13 ビュー・オブジェクトの表示名UIヒント

始める前に:

次のタスクを完了する必要があります。

- 「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」で説明するように、組込みメソッドgetDfltObjAttrHints()をリモート・クライアント・サービス・インタフェースに定義します。

ビュー・インスタンスのUIヒント・ラベルとその属性を設定する手順:

1. 「アプリケーション」ウィンドウで、SDOのビュー・インスタンスを定義するアプリケーション・モジュールをダブルクリックします。

2. 「データ・モデル」リストで、ビュー・インスタンス名を選択し、リストの下にある「ビュー定義」リンクをクリックします。

3. ビュー・オブジェクトの概要エディタで、「一般」ナビゲーション・タブをクリックします。

4. メイン・メニューで、「表示」、「プロパティ・インスペクタ」の順に選択します。

5. 「プロパティ・インスペクタ」で、ビュー・オブジェクト・インスタンスのラベルを設定するには、「UIヒント」を展開し、「表示名」と「表示名(複数)」のラベルを入力します。

6. ビュー・オブジェクトの概要エディタで、「属性」ナビゲーション・タブをクリックし、ラベルを付ける属性を選択します。

7. 「プロパティ・インスペクタ」で、ビュー・オブジェクト属性のラベルを設定するには、「UIヒント」を展開し、「ラベル」と「表示名(複数)」のラベルを入力します。

15.2.17 SOAPクライアントによるアクセス用にADF Webサービスを保護する方法

実行時、Webサービス・クライアントはSOAPプロトコルを使用して、アプリケーション・モジュールのサービス対応メソッドを起動します。Oracle Web Service Manager (OWSM)セキュリティ・ポリシーの構成によって、サービスの認証と許可を有効化できます。選択するセキュリティ・ポリシーでは、SOAPクライアント・コールによってSOAPヘッダーの一部として資格証明(SAMLトークン)を提供する必要があります。たとえば受信するSOAPリクエストなどに対するメッセージ保護(整合性および機密保護)を有効化するその他のポリシーも構成できます。

SOAPクライアント用にWebサービスを保護するには:

1. OWSM認証ポリシーを構成します。

2. OWSM許可ポリシーを構成します。

認証を有効にして、サービス・インタフェース上のサービス・メソッドへのアクセス前に、ユーザーに資格証明の提供を求めることができます。必要な認証タイプは、OWSM認証ポリシー注釈を使用しているサービス実装で構成します。

権限チェックを有効化し、十分な権限を持つユーザーだけに、サービス・インタフェース上のサービス・メソッド起動を許可できます。権限チェックは、このOWSM許可注釈を使用して、サービス実装クラスで構成します。

- binding_permission_authorization_policy
このポリシーは、SOAPバインディング・レベルの認証されたサブジェクトに基づき、リクエストに対して簡単な権限ベースの認可を行います。このポリシーは、サブジェクトに操作を実行する権限があることを保証します。このポリシーは、サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。

権限チェック・ポリシーのかわりに、ロールベースのOWSMセキュリティ・ポリシーのいずれかを構成することもできます。

- binding_authorization_denyall_policy
このポリシーは、SOAPバインディング・レベルの認証されたサブジェクトに基づき、リクエストに対して簡単なロールベースの認可を行います。このポリシーは、任意のロールを持つすべてのユーザーを拒否します。サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。

- binding_authorization_permitall_policy
このポリシーは、SOAPバインディング・レベルの認証されたサブジェクトに基づき、リクエストに対して簡単なロールベースの認可を行います。このポリシーは、任意のロールを持つすべてのユーザーを許可します。サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。

認可ポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の付録「事前定義済ポリシー」、セキュリティ・ポリシー: 認可のみに関する項を参照してください。

ADFサービス・インタフェース・フレームワークには、EJBインターセプタであるServicePermissionCheckInterceptorも用意されています。これは、oracle/binding_permission_authorization_policyと同じチェックを実施し、さらにサービスに対するRMI起動にも対応します。サービスが常にSOAPを使用して起動される場合は、OWSMの許可ポリシーoracle/binding_permission_authorization_policyを添付してください。サービスがRMIを使用しても起動される場合は、EJBインターセプタServicePermissionCheckInterceptorを添付してください。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

また、OWSMでサポートされる事前定義済認証ポリシーについても理解しておくと役立つ場合があります。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の付録「事前定義済ポリシー」、セキュリティ・ポリシー: 認証のみに関する項を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「サービスへのアクセスをテスト・ユーザーに許可する方法」の説明に従って、ユーザーにサービスへのアクセスを許可します。

認証と許可を構成するには:

1. 「アプリケーション」ウィンドウでアプリケーション・モジュールを開き、「serviceinterface」ノードを開いて、サービス実装クラス(AppModuleServiceImpl.javaノード)をダブルクリックします。
SummitADF_Examplesワークスペースのoracle.summit.model.amserviceパッケージ内のServiceAppModuleアプリケーション・モジュールから生成されたWebサービスでは、サービス実装クラスはServiceAppModuleServiceImpl.javaです。

2. サービスが常にSOAPを使用してのみ起動される(RMIは使用しない)場合は、次の手順に従ってOWSM許可ポリシーを使用する必要があります。

a. サービス実装クラスのソースで、カーソルを@PortableWebService注釈上に配置します。
たとえば、ServiceAppModuleServiceImpl.javaでは、サービスの注釈が次のように表示されます。

...
@PortableWebService(
targetNamespace="/oracle/summit/model/amservice/common/",
serviceName="ServiceAppModuleService",
portName="ServiceAppModuleServiceSoapHttpPort",
endpointInterface=
"oracle.summit.model...common.serviceinterface.ServiceAppModuleService")

b. 「プロパティ」ウィンドウで、「ポリシー」 セクションを開き、「複数ポリシー」フィールドの横にあるボタンをクリックします。

c. 「プロパティの編集: 複数ポリシー」ダイアログで、目的のセキュリティ・ポリシーを選択し、「OK」をクリックします。
OWSMでサポートされるセキュリティ・ポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の付録「事前定義済ポリシー」、セキュリティ・ポリシー: 認可のみに関する項を参照してください。

d. ソース・ファイルに戻り、注釈@PolicySetの構成を確認します。
サービス実装クラスに対して定義した@PolicySetという注釈は、潜在的なクライアントに対するセキュリティ要件を指定します。この例では、注釈に権限チェック許可ポリシー(oracle/binding_permission_authorization_policy)と認証ポリシーの両方が表示されます。

...
@PortableWebService(
targetNamespace="/oracle/summit/model/amservice/common/",
serviceName="ServiceAppModuleService",
portName="ServiceAppModuleServiceSoapHttpPort",
endpointInterface=
"oracle.summit.model...common.serviceinterface.ServiceAppModuleService")
@PolicySet(references = {
@PolicyReference(value =
"oracle/wss_username_token_service_policy"),
@PolicyReference(value =
"oracle/binding_permission_authorization_policy")
})

3. サービスがSOAPとRMIを使用して起動される場合は、次の手順に従って、ServicePermissionCheckInterceptorのみを使用してください(OWSM許可ポリシーを使用する必要はありません)。
ソース・エディタで@Interceptors注釈にカーソルを置き、ServicePermissionCheckInterceptor.classを追加して、実行時の権限チェックを有効にします。

...
@Interceptors({ ServiceContextInterceptor.class,
ServicePermissionCheckInterceptor.class })
@Stateless(name=
"oracle.summit.model.amservice.common.ServiceAppModuleServiceBean",
mappedName="ServiceAppModuleServiceBean")

4. サービス実装クラス・ファイルを保存します。

15.2.18 RMIクライアントによるアクセス用にADF Webサービスを保護する方法

ADF WebサービスはEJBとして実装され、Oracle WebLogic Server上でOracle Web ServiceのPortableWebServiceとしてデプロイされるので、クライアント・アプリケーションは、RMIプロトコルを使用してアプリケーション・モジュールのサービス対応メソッドを起動できます。

RMIクライアント用にWebサービスを保護するには:

1. JNDIコンテキスト・プロパティを構成して認証を有効にします。

2. 権限チェックを有効にして、許可ポリシーを構成します。

始める前に:

OWSMでサポートされる事前定義済許可ポリシーについて理解しておくと役立つ場合があります。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の付録「事前定義済ポリシー」、セキュリティ・ポリシー: 認可のみに関する項を参照してください。

15.2.18.1 RMIクライアント認証の有効化

RMIを使用してADF Webサービスを起動すると、共通のJAASログイン・モジュールによって認証が処理されます。ログイン・モジュールは、コール元のアプリケーションでEJBの当初のJNDIコンテキストの一部として、プリンシパルおよび資格証明を受け取ります。JNDIコンテキスト・プロパティを定義しなかった場合、ログイン・モジュールはコール元の現在のセキュリティ・コンテキストを取得しようとします。

リモートJNDIコンテキスト情報を定義した場合、次の4つのJNDIコンテキスト・プロパティをconnections.xmlファイルに追加する必要があります。

注意:

Integrated WebLogic Serverを使用してJDeveloperでサービスのテストを行う場合、サービスのデプロイ前に、connections.xmlファイルで直接JNDIコンテキスト・プロパティを編集できます。ただし、スタンドアロンOracle WebLogic Serverにサービスをデプロイする場合は、Oracle Enterprise Managerを使用してJNDIコンテキスト・プロパティを構成します。

- jndiFactoryInitialはweblogic.jndi.WLInitialContextFactoryに設定する必要があります。

- jndiProviderURLはJNDIプロバイダのURLで、JNDIサーバーの場所を示します。URLはt3://<hostname>:<server port>という構成でなければなりません。
JDeveloperでサービスをテストし、サービスをIntegrated WebLogic Serverにデプロイする場合は、Integrated WebLogic ServerのJNDIプロバイダのURLにt3://<hostname>:7101を指定します。

リモートOracle WebLogic Serverにサービスをデプロイする場合は、t3://localhost:8888のようなURLを指定します。ここでt3はOracle WebLogicプロトコル、localhostはリモートOracle WebLogic Serverインスタンスを実行するホスト名、8888はポート番号です。

- jndiSecurityPrincipalは、リモートJNDIへのアクセス権のあるプリンシパル(ユーザー名)を指定します。
JDeveloperの統合WebLogic Serverでサービスをテストする場合は、Integrated WebLogic Server上でJNDIサーバーのセキュリティが構成されていないため、このコンテキスト・プロパティは省略する必要があります。

スタンドアロンOracle WebLogic Serverにデプロイすると、ユーザー名をファイルから読み取ることができます。

- jndiSecurityCredentialsは、セキュリティ・プリンシパルに使用する資格証明(パスワード)を指定します。
JDeveloperの統合WebLogic Serverでサービスをテストする場合は、Integrated WebLogic Server上でJNDIサーバーのセキュリティが構成されていないため、このコンテキスト・プロパティは省略する必要があります。

サービスをテスト環境内のスタンドアロンOracle WebLogic Serverにデプロイする際は、JNDIプロバイダ用の資格証明をプレーン・テキストで指定できます。たとえば、Oracle WebLogic ServerのJNDIプロバイダにアクセスするための十分な権限を持つ、デフォルト管理者のユーザー名/パスワード資格証明である、weblogic/weblogic1を指定できます。

サービスを本番環境にデプロイする場合は、セキュリティの脆弱性を回避するために、プレーン・テキストのパスワードを削除する必要があり、かつ、connections.xmlファイルには、パスワードを設定せずに<SecureRefAddr addrType="jndiSecurityCredentials"/>を含める必要があります。スタンドアロンOracle WebLogic Server用のサービス・パスワードを構成するには、Oracleの資格証明ストアに暗号化されたパスワードを保存するOracle Enterprise Managerを使用する必要があります。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

認証処理用にJNDIコンテキスト・プロパティを構成する手順:

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開き、「connections.xml」ファイルをダブルクリックします。

2. ソース・エディタの場合は、JNDIコンテキスト・プロパティを使用してプリンシパルと資格証明を指定します。

JDeveloperの統合WebLogic Serverでサービスをテストする場合は、次の例に示すように、jndiProviderURLプロパティを指定するだけでかまいません。

<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="{www.globalcompany.com}ServiceAppModuleService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
...
<StringRefAddr addrType="jndiFactoryInitial">
<Contents>weblogic.jndi.WLInitialContextFactory</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiProviderURL">
<Contents>t3://a_hostname:7101</Contents>
</StringRefAddr>
...
</RefAddresses>
</Reference>
...
</References>

Oracle WebLogic Serverでのテスト用にサービスをデプロイする場合は、connections.xmlファイルを使用してJNDIプロバイダの資格証明を指定できます。次の例に示すように、Oracle WebLogic ServerのJNDIプロバイダにアクセスするための十分な権限を持つ、デフォルト管理者のユーザー名/パスワード資格証明である、weblogic/weblogic1を指定できます。

<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="{www.globalcompany.com}ServiceAppModuleService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
...
<StringRefAddr addrType="jndiFactoryInitial">
<Contents>weblogic.jndi.WLInitialContextFactory</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiProviderURL">
<Contents>t3://localhost:8888</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiSecurityPrincipal">
<Contents>weblogic</Contents>
</StringRefAddr>
<SecureRefAddr addrType="jndiSecurityCredentials">
<Contents>weblogic1</Contents>
</SecureRefAddr>
...
</RefAddresses>
</Reference>
...
</References>

本番Oracle WebLogic Serverにサービスをデプロイする場合は、connections.xmlファイルを使用してユーザー名を指定できます。次の例に示すように、パスワードの指定は行わないでください。

<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="{www.globalcompany.com}ServiceAppModuleService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
...
<StringRefAddr addrType="jndiFactoryInitial">
<Contents>weblogic.jndi.WLInitialContextFactory</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiProviderURL">
<Contents>t3://localhost:8888</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiSecurityPrincipal">
<Contents>a_username</Contents>
</StringRefAddr>
<SecureRefAddr addrType="jndiSecurityCredentials/">
...
</RefAddresses>
</Reference>
...
</References>

3. ファイルを保存します。

15.2.18.2 RMIクライアントの認可の構成

権限チェックを有効化し、十分な権限を持つユーザーのみに、サービス・インタフェース上のサービス・メソッド起動を許可できます。権限チェックを有効にするために、ADFサービス・インタフェース・フレームワークはServicePermissionCheckInterceptorという名前のEJBインターセプタを提供しています。このEJBインターセプタにより、実行時に権限チェックが確実に実行されます。現在、インターセプタはOWSMが許可ポリシーbinding_permission_authorization_policyに対して実装するものと同じロジックでコード化されています。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「RMIクライアント認証の有効化」の説明に従って、クライアント・アプリケーション(サービスを起動するアプリケーション)のconnections.xmlファイルで、サービスの認証ポリシーを構成します。

2. 「サービスへのアクセスをテスト・ユーザーに許可する方法」の説明に従って、ユーザーにサービスへのアクセスを許可します。

権限ベースの許可ポリシーを構成するには:

1. 「アプリケーション」ウィンドウで、Webサービス・プロジェクトの「META-INF」ノードを開き、「ejb-jar.xml」ノードをダブルクリックします。

2. ソース・エディタで、アプリケーションのロール評価のためのEJBに必要な、次のJpsInterceptor定義を追加します。

<?xml version = '1.0' encoding = 'windows-1252'?>
<ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/j2ee/ejb-jar_3_0.xsd" version="3.0"
xmlns="http://java.sun.com/xml/ns/javaee">
<enterprise-beans>
...
</enterprise-beans>
<interceptors>
<interceptor>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ApplicationName</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</injection-target-class>
<injection-target-name>
application_name
</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar>

3. 「アプリケーション」ウィンドウでアプリケーション・モジュールを開き、「serviceinterface」ノードを開いて、サービス実装クラス(AppModuleServiceImpl.javaノード)をダブルクリックします。

4. ソース・エディタで注釈セクションの最後にカーソルを配置し、ServicePermissionCheckInterceptorという名前の注釈を追加して、実行時の権限チェックを有効にします。

...
@Stateless(name="oracle.summit.model.amservice.common.
ServiceAppModuleServiceBean")
@Remote(ServiceAppModuleService.class)
@PortableWebService(targetNamespace="http://www.globalcompany.com/
ServiceAppModuleService",
serviceName="ServiceAppModuleService",
portName="ServiceAppModuleServiceSoapHttpPort",
endpointInterface="oracle.summit.model.amservice.
common.serviceinteface.ServiceAppModuleService")
@CallByReference
@Interceptors({ServiceContextInterceptor.class,
ServicePermissionCheckInterceptor.class})

5. ファイルを保存します。

15.2.19 サービスへのアクセスをテスト・ユーザーに許可する方法

サービスの認可ポリシーを構成後、Oracle Platform Security Services (OPSS)セキュリティ・プロバイダを構成して、サービスにメソッドを起動できるユーザーを指定する必要があります。設計時にjazn-data.xml構成ファイルを編集して、アプリケーション・ロールの作成と該当するアプリケーション・ロールへの起動権限許可を行うことでこのタスクを実行します。その後サービスをデプロイする際には、ターゲットOracle WebLogic Serverの管理者が、指定したアプリケーション・ロールをエンタープライズ・ユーザーに関連付けます。これによって、サービス・メソッドの起動権利を、そのアプリケーション・ロールのメンバーである任意のユーザーに付与できます。起動権限が付与されていないロール・メンバーであるユーザーは、サービス・メソッドへのアクセスを拒否されます。

Oracle Web Servicesの起動権限は、oracle.wsm.security.WSFunctionPermissionクラスで定義されています。サービスの全メソッドまたは個別のメソッドに対して、定義するアプリケーション・ロールの権限を付与できます。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

また、アプリケーション・ロールとOPSSセキュリティ・プロバイダについても理解しておくと役立つ場合があります。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「Oracle Platform Security Servicesの概要」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「SOAPクライアントによるアクセス用にADF Webサービスを保護する方法」または「RMIクライアントによるアクセス用にADF Webサービスを保護する方法」の説明に従って、サービスの認証および許可ポリシーを構成します。

2. jazn-data.xmlデプロイメント・ディスクリプタを作成して、OPSSセキュリティ・プロバイダ構成ファイルをプロジェクトに追加します。デプロイメント・ディスクリプタの詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「アプリケーションのデプロイ」を参照してください。
JDeveloper内の「新規ギャラリ」を開いて「一般」を展開し、「デプロイメント・ディスクリプタ」→「Oracleデプロイメント・ディスクリプタ」を選択して、「OK」をクリックします。

3. 「アプリケーション・ロールの作成」の説明に従って、付与対象のアプリケーション・ロールを作成します。

4. JDeveloperで統合WebLogic Serverを使用してWebサービスをテストするために、「テスト・ユーザーの作成」の説明に従って、アプリケーション・ロールにテスト・ユーザーを追加できます。

jazn-data.xmlファイルでアプリケーション・ロールへのWebサービス権限を付与する手順:

1. メイン・メニューから、「アプリケーション」→「保護」→「リソース権限」または「アプリケーション」→「保護」→「資格付与」を選択します。

複数の権限を資格セットとしてアプリケーション・ロールに付与したり、リソースに対して個々の権限を付与できます。資格付与を作成するには、特定のエンド・ユーザー職務を保護する複数の権限を集約する場合です。資格付与の詳細は、「リソース権限を資格付与として集約する方法」を参照してください。

2. jazn-data.xmlファイルのエディタ・ウィンドウで「ソース」タブをクリックします。

3. jazn-data.xmlファイルのソースで、<policy-store>要素を展開し、アプリケーション用に定義済のすべてのADFセキュリティ・ポリシーを表示します。

現在、このリリースではアプリケーション・セキュリティ・ポリシー作成用のエディタが提供されていません。jazn-data.xmlファイルのソースで、ポリシーを手動で作成する必要があります。

4. <jazn-policy>要素内に、該当するアプリケーション・ロールを指定した<grantee>を定義する<grant>要素と、OWSM権限クラスの完全修飾クラス名(oracle.wsm.security.WSFunctionPermission)、サービス・メソッドを一意に識別する権限ターゲット名、およびアプリケーション・ロール・プリンシパルに付与する起動メソッド・アクションを指定した<permission>を作成します。

完成したソースは次のようになります。

<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>customers</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.wsm.security.WSFunctionPermission</class>
<name>www.globalcompany.example.com/
ServiceAppModuleService#CreateAccount</name>
<actions>invoke</actions>
</permission>
</permissions>
</grant>

<principal>要素は、アプリケーション・ロール・クラス名oracle.security.jps.service.policystore.ApplicationRoleおよび作成済のアプリケーション・ロール名によって定義されます。たとえば、アプリケーション・ロールcustomersを作成済で、そのロールのメンバーに起動サービス・メソッドの権限を付与する場合は、customersと入力します。

<permission>要素は、OWSMクラス名oracle.wsm.security.WSFunctionPermissionおよび権限ターゲット名によって定義されます。権限ターゲット名は、/serviceInterfaceNameおよび#serviceMethodName(またはワイルドカード文字)をサービス・ターゲット・ネームスペースに付加して作成します。

ヒント:

ターゲット・ネームスペースとサービス名は、サービスのWSDL定義ファイルで検索できます。「アプリケーション」ウィンドウでserviceinterfaceノードの下のWSDLファイルをダブルクリックし、nameおよびtargetNamespace定義を表示します。

たとえば、Summit ADFサンプル・アプリケーションのWSDL定義ファイルでは、次の名前とネームスペースが定義されている場合があります。

<wsdl:definitions
name="ServiceAppModuleService"
targetNamespace="www.globalcompany.example.com"

サービス・インタフェース上で、これらのSummitADF_Examplesワークスペース名とネームスペースを使用して、認可されたユーザーにCreateOrderサービス・メソッドの起動権限を付与する場合は、次のようなターゲット名を入力します。

www.globalcompany.example.com/ServiceAppModuleService#CreateOrder

あるいはワイルドカード*を使用してターゲット名を入力し、1つの権限でサービス・インタフェースのすべての操作を許可することもできます。

www.globalcompany.example.com/ServiceAppModuleService#*

入力可能なアクションは権限クラスによって定義されています。この場合、oracle.wsm.security.WSFunctionPermissionは単一のアクションであるinvokeを定義します。

5. jazn-data.xmlファイルに変更を保存します。

15.2.20 SOAPクライアント用バイナリ添付サポートの有効化の方法

ADFサービス・インタフェースは、Message Transmission Optimization Mechanism (MTOM)を使用して、BlobDomain/ClobDomain属性のViewRowに対して機能するサービス・メソッドでのバイナリ・データ送信処理をサポートしています。これによって、保険金請求書類に画像が必要な場合など、バイナリ・データにXMLメッセージを添付できます。サービス対応アプリケーション・モジュールのSDOデータ・オブジェクトは、BlobDomain/ClobDomainをjavax.activation.DataHandlerにマップします。SOAPプロトコルを使用してWebサービスをコールする際、SDOデータ・オブジェクトのマーシャリング/アンマーシャリング中に、これらのDataHandlerプロパティを添付データとして渡すことができます。

SOAPプロトコルのMTOMサポートを有効化するには、@MTOMという注釈をサービス実装クラス(たとえばServiceAppModuleServiceImpl.java)に追加し、また、BlobDomain/ClobDomain属性を持つビュー行に対してメソッドが機能する必要があります。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「ClobDomainタイプ属性の文字エンコーディングの指定方法」で説明するように、ADFサービス・インタフェース・フレームワークがビュー・オブジェクトによってClobDomain属性として定義されたデータを変換するために使用できる文字エンコーディング形式を構成します。

バイナリ・データ添付の送信サポートを有効化する手順:

1. 「アプリケーション」ウィンドウでアプリケーション・モジュールを開き、serviceinterfaceノードを開いて、サービス実装クラス(AppModuleServiceImpl.javaファイル)をダブルクリックします。

SummitADF_Examplesワークスペースのoracle.summit.model.amserviceパッケージ内のServiceAppModuleアプリケーション・モジュールから生成されたWebサービスでは、サービス実装クラスはServiceAppModuleServiceImpl.javaです。

2. サービス実装クラスのソースで、カーソルを注釈セクション上の任意の場所に配置します。

たとえば、ServiceAppModuleServiceImpl.javaでは、サービスの注釈セクションは次のようになります。

...
@Stateless(name="oracle.summit.model....common.ServiceAppModuleServiceBean",
mappedName="ServiceAppModuleServiceBean")
@Remote(ServiceAppModuleService.class)
@PortableWebService(targetNamespace="www.globalcompany.example.com",
serviceName="ServiceAppModuleService",
portName="ServiceAppModuleServiceSoapHttpPort",
endpointInterface=
"oracle.summit.model...common.serviceinterface.ServiceAppModuleService")
...

3. 「プロパティ」ウィンドウで、「Webサービス」セクションを開き、「MTOMの有効化」を選択します。

JDeveloperが注釈@MTOMを、ファイルの注釈セクションに追加します。

...
@Stateless(name="oracle.summit.model....common.ServiceAppModuleServiceBean",
mappedName="ServiceAppModuleServiceBean")
@Remote(ServiceAppModuleService.class)
@PortableWebService(targetNamespace="www.globalcompany.example.com",
serviceName="ServiceAppModuleService",
portName="ServiceAppModuleServiceSoapHttpPort",
endpointInterface=
"oracle.summit.model...common.serviceinterface.ServiceAppModuleService")
@MTOM
...

15.2.21 ClobDomainタイプ属性の文字エンコーディングの指定方法

データベースでCLOB型として定義された大きな文字列データの作業の結果は、文字列データとバイナリ・データ間の変換時に使用する文字エンコーディングです。ClobDomain属性をサービス・データ・オブジェクトで処理した場合、ADFサービス・インタフェース・フレームワークは属性値をbase64でエンコードされたSDOプロパティにマッピングすることでデータをストリーミングします。このbase64バイナリ・ストリームへのマッピングには、元のデータの文字セットは含まれません。

文字列データとバイナリ・データ間の変換をサポートするために、ADFサービス・インタフェース・フレームワークでは、ビュー・オブジェクトの個々のClobDomain属性のエンコーディング文字セットを構成できます。または、すべてのClobDomain属性を同じ文字エンコーディング・スキームを使用して変換する場合は、ビュー・オブジェクト定義のレベルでエンコーディング文字セットを構成できます。

フレームワークでバイナリ・ストリームとClobDomain属性の文字間の変換が必要な場合は、ビュー・オブジェクトに対して定義したこれらのカスタム・プロパティの値として指定された文字エンコーディングを適用できます。

- SERVICE_USE_SERVER_DEFAULT_CHARSET

- SERVICE_CLOB_CONVERSION_CHARSET

カスタム・プロパティSERVICE_USE_SERVER_DEFAULT_CHARSETは、データベースで使用される特定の文字エンコーディングがわからない場合に役立ちます。サーバーJVMの文字セットはロケールに依存するため、サーバーのエンコーディング文字セットをいつデフォルトに設定するかを考慮する必要があります。

ClobDomain属性の理想的な構成は、カスタム・プロパティSERVICE_CLOB_CONVERSION_CHARSETおよび指定する文字エンコーディングに依存します。この構成では、ADFサービス・インタフェース・フレームワークが異なるエンコーディング文字セットを使用して変換しないように、ターゲット・データの文字エンコーディングを検証できることを想定します。

注意:

カスタム・プロパティが文字エンコーディングを構成するようにビュー・オブジェクトに定義されていない場合、実行時に、ADFサービス・インタフェース・フレームワークはデフォルトでUTF-8文字エンコーディング・スキームを使用してClobDomainデータの変換を処理します。UTF-8は、Oracle DatabaseでサポートされるCLOBデータに多言語サポートを提供するUnicodeエンコーディングです。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「SOAPクライアント用バイナリ添付サポートの有効化の方法」の説明に従い、@MTOM注釈をサービス実装クラスに追加してMTOMサポートを有効にし、サービス・メソッドがClobDomain属性を持つビュー行を操作できるようにします。

ビュー・オブジェクトの個々のClobDomain属性の文字エンコーディングを構成する手順:

1. 「アプリケーション」ウィンドウで、ClobDomain属性が含まれているビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、「タイプ」列にClobと表示されている属性を選択します。

4. 「カスタム・プロパティ」タブをクリックし、「追加」アイコンをクリックし、ドロップダウン・リストから「変換不能プロパティ」を選択して、「プロパティ」名フィールドに次の事前定義済カスタム・プロパティの1つを入力します。
SERVICE_USE_SERVER_DEFAULT_CHARSET - JVMの文字エンコーディングをデータの変換に使用する場合。「値」にtrueと入力します。

SERVICE_CLOB_CONVERSION_CHARSET - データの文字エンコーディングに対応する既知の文字エンコーディングを指定する場合。「値」に目的の文字エンコーディングを入力します。たとえば、UTF-16と入力します。値を指定しない場合は、デフォルトのUTF-8が使用されます。

ビュー・オブジェクトのすべてのClobDomain属性の文字エンコーディングを構成する手順:

1. 「アプリケーション」ウィンドウで、ClobDomain属性が含まれているビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

3. 「一般」ページで、「カスタム・プロパティ」セクションを展開し、「追加」アイコンをクリックし、ドロップダウン・リストから「変換不能プロパティ」を選択して、「プロパティ」名フィールドに次の事前定義済カスタム・プロパティの1つを入力します。

SERVICE_USE_SERVER_DEFAULT_CHARSET - JVMの文字エンコーディングをデータの変換に使用する場合。「値」にtrueと入力します。

SERVICE_CLOB_CONVERSION_CHARSET - データの文字エンコーディングに対応する既知の文字エンコーディングを指定する場合。「値」に目的の文字エンコーディングを入力します。たとえば、UTF-16と入力します。値を指定しない場合は、デフォルトのUTF-8が使用されます。

15.2.22 Integrated WebLogic Serverを使用したWebサービスのテスト方法

Integrated WebLogic Serverを使用して、JDeveloperでWebサービスを実行できます。Oracle WebLogic ServerにWebサービスをデプロイして、サービスをテストすることもできます。

Integrated WebLogic Serverを使用した実行とテストの手順:

1. 「アプリケーション」ウィンドウでアプリケーション・モジュールを開き、「serviceinterface」ノードを開いて、サービス実装クラス(AppModuleServiceImpl.javaファイル)を選択します。

SummitADF_Examplesワークスペースのoracle.summit.model.amserviceパッケージ内のServiceAppModuleアプリケーション・モジュールから生成されたWebサービスでは、サービス実装クラスはServiceAppModuleServiceImpl.javaです。

2. サービス実装クラス・ファイルを右クリックし、「実行」または「デバッグ」を選択します。

アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

JDeveloperがサーバー・インスタンスを初期化し、アプリケーションをデプロイしてWebサービスを開始します。この間、これらプロセスからの出力が「ログ」ウィンドウの「実行中」タブに表示されます。Webサービスの開始後、ターゲットURLも「ログ」ウィンドウに表示されます。

ヒント:

「ログ」ウィンドウでターゲットURLリンクをクリックすると、HTTPアナライザを起動できます。これは、JDeveloperと統合されたWebLogic Serverでテストを実行する場合のショートカットとして便利です。HTTPアナライザの詳細は、『Oracle JDeveloperによるアプリケーションの開発』の「Javaプロジェクトの監査とモニタリング」を参照してください。

3. 「ログ」ウィンドウからターゲットURL (http://で始まる)をコピーします。

「ログ」ウィンドウにはたとえば次が表示されます。

http://<ipaddress>/ADFServiceDemo-ADFModel-context-root

統合WebLogic Serverにより、サービス・エンドポイントのURLが表示されます。そのため、サービス名を追加する必要はありません。

4. Webブラウザを起動し、「ログ」ウィンドウからコピーしたターゲットURLをブラウザのアドレス・フィールドにペーストして、HTTPリクエストを送信します。

5. テスト・ページで、起動する操作を「操作」ドロップダウン・リストから選択し、パラメータ・フィールドにサンプル・データを入力します。

6. 準備ができたら、「起動」を押して操作を発行し、「テスト結果」ページで操作結果を確認します。

「テスト結果」ページには、操作で戻された情報のXML Soap形式が表示されます。

15.2.23 カスタム・サービス・メソッドのタイムアウトの防止方法

Webサービスをテストすると、一部のカスタム・メソッドがJava Transaction API (JTA)で設定されたタイムアウト制限を超えていることに気付く場合があります。JTAタイムアウト設定では、サービス・メソッドの実行制限時間をデフォルトでは30秒以内に設定しています。Oracle WebLogic Server管理コンソールを使用して、JTAタイムアウト設定を延長できます。それでもタイムアウト例外を受信する場合や、サービス・インタフェースのカスタム・メソッドの実行に長時間かかることが予想される場合は、ステートレス・セッションBean用のEJBトランザクション属性を指定して、EJBがJTAトランザクションでこれらのメソッドを実行しないようにします。

カスタム・メソッドでタイムアウトが発生しないようにするには、「プロパティ」ウィンドウでそのメソッドに対してTransactionAttributeType.NOT_SUPPORTEDを設定します。次の例に示すように、JDeveloperは注釈@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)を追加して、メソッドを更新します。

@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void updateCustomerInterests(List<String> pCategoryIds) throws
ServiceException {
invokeCustom((Method) _map.get("updateCustomerInterests"),
new Object[] { pCategoryIds }, new String[] { null }, false);
}

このトランザクション属性が設定されたメソッドはJTAトランザクションでは実行されないため、oracle.jbo.ApplicationModule and oracle.jbo.TransactionインタフェースのADFビジネス・コンポーネント・メソッドを使用して各自でトランザクションの制御を行う必要があります。たとえば、次の例に示すように、サービス対応にしたアプリケーション・モジュールの実装クラスのメソッドでは、am.getDBTransaction().commit()またはrollback()をコールして、トランザクションを完了する必要があります。

public void updateCustomerInterests(List pCategoryIds) {
try
{
if (pCategoryIds != null && pCategoryIds.size() > 0) {
List<Integer> copyOfCategoryIds = (List<Integer>)
this.cloneList(pCategoryIds);
ViewObject selectedCategories =
this.getSelectedCategoriesShuttleList();
RowSetIterator rsi = selectedCategories.createRowSetIterator(null);
// remove rows for the current user not in the list of product keys
while (rsi.hasNext()) {
Row r = rsi.next();
Number interestId = (Number)r.getAttribute("CategoryId");
// existing row is in the list, we're ok, so remove from list.
if (copyOfCategoryIds.contains(interestId)) {
copyOfCategoryIds.remove(interestId);
}
// if the existing row is in not list, remove it.
else {
r.remove();
}
}
rsi.closeRowSetIterator();
// at this point, add new rows for the keys that are left
for (int i =0 ;i < copyOfCategoryIds.size(); i++ )  {
Row newRow = selectedCategories.createRow();
selectedCategories.insertRow(newRow);
newRow.setAttribute("CategoryId", (String)
copyOfCategoryIds.get(i).toString());
}
this.getTransaction().commit();
}
}
catch (JboException e)
{
this.getTransaction().rollback();
throw e;
}
}

サービス・インタフェース用に生成した標準サービス・メソッドのデフォルト・トランザクション属性設定は、変更しないでください(表15-1を参照)。標準メソッドは、JTAトランザクション用に設定されたデフォルト実行境界内で実行されます。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

カスタム・メソッドがJTAトランザクションで実行されないようにする手順:

1. 「アプリケーション」ウィンドウでアプリケーション・モジュールを開き、「serviceinterface」ノードを開いて、サービス実装クラス(AppModuleServiceImpl.javaファイル)をダブルクリックします。

SummitADF_Examplesワークスペースのoracle.summit.model.amserviceパッケージ内のServiceAppModuleアプリケーション・モジュールから生成されたWebサービスでは、サービス実装クラスはServiceAppModuleServiceImpl.javaです。

2. ソース・エディタで、タイムアウトさせたくないカスタム・メソッドを検索して、そのメソッド上にカーソルを置きます。

3. 「プロパティ」ウィンドウで「ステートレス・セッションBean」を開き、「TransactionAttribute」ドロップダウン・リストから「TransactionAttributeType.NOT_SUPPORTED」を選択します。

前に示したサービス・メソッドの例で、NOT_SUPPORTED注釈のupdateCustomerInterests()に示されているように、JDeveloperによって、カスタム・サービス・メソッドが注釈付きで更新されます。

4. サービス実装クラスを保存します。

5. 「アプリケーション」ウィンドウで、アプリケーション・モジュール実装クラス(AppModuleImpl.java)のファイルをダブルクリックします。

この実装クラスはサービス・インタフェースで公開されるカスタム・メソッドを定義します。SummitADF_Examplesワークスペースでは、アプリケーション・モジュール実装クラスはoracle.summit.model.amservice.ServiceAppModuleImpl.javaです。

6. ソース・エディタで、TransactionAttributeプロパティを設定したサービス・メソッドを実装するカスタム・メソッドに、トランザクションのコミットとロールバックを行うカスタム・コードを追加します。

前に示したサービス・メソッドの実装例で示されているように、updateCustomerInterests()という名前のサービス・メソッドにTransactionAttributeプロパティを構成した場合、アプリケーション・モジュールの実装クラスを開き、カスタム・メソッドupdateCustomerInterests()を検索して、am.getDBTransaction().commit()およびrollback()をメソッドのtryおよびcatch文に追加します。

7. アプリケーション・モジュール実装クラスを保存します。

15.2.24 Oracle WebLogic ServerへのWebサービスのデプロイ方法

たとえば、サービスのテストの第2段階を実行するために、Oracle WebLogic ServerにWebサービスをデプロイすることができます。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. プロジェクトに標準Webサービス(@WebService注釈付きのJavaクラスまたはJavaインタフェース)が含まれている場合は、ビジネス・コンポーネントのWebサービスをデプロイする前に、該当Javaクラスから@WebService注釈を削除する必要があります。標準Webサービスと同じプロジェクトに属するビジネス・コンポーネントのWebサービスをデプロイしようとすると、Oracle WebLogic Server例外エラーが発生してデプロイメントが失敗します。そのため、標準Webサービスは、ADFビジネス・コンポーネント・サービスとは別のプロジェクトに作成する必要があります。

2. 非同期Webサービスを作成した場合は、サービスのデプロイ前に、リクエストおよびレスポンスを格納するためのキューを構成する必要があります。リクエストおよびレスポンス・キューの構成の詳細は、『Oracle Infrastructure Webサービスの開発』の「非同期Webサービスの開発」、リクエストおよびレスポンス・キューの作成に関する項を参照してください。

3. 「SOAPクライアントによるアクセス用にADF Webサービスを保護する方法」の説明に従ってWebサービスの認可を構成した場合は、weblogic-application.xmlファイルを編集して、アプリケーションIDパラメータを定義します。このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」および「META-INF」ノードの下に表示されます。
次の<application-param>定義を最初の要素として追加します。

<weblogic-application xmlns="http://www.bea.com/ns/weblogic/weblogic-application"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.bea.com/ns/weblogic/weblogic-application.xsd">
<application-param>
<param-name>jps.policystore.applicationid</param-name>
<param-value>ApplicationName</param-value>
</application-param>
...
</weblogic-application>

入力するApplicationNameは、 jazn-data.xmlポリシー・ストア定義内の名前と一致する必要があります。

<jazn-data>
<policy-store>
<applications>
<application>
<name>ApplicationName</name>
<app-roles>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
</applications>
</policy-store>
</jazn-data>

4. ejb-jar.xmlファイルを編集して、EJBでのアプリケーション・ロール評価に必要な、次のJpsInterceptor定義を追加します。このファイルは「アプリケーション」ウィンドウの、Webサービス・プロジェクトの「META-INF」ノードの下にあります。

<?xml version = '1.0' encoding = 'windows-1252'?>
<ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/j2ee/ejb-jar_3_0.xsd" version="3.0"
xmlns="http://java.sun.com/xml/ns/javaee">
<enterprise-beans>
...
</enterprise-beans>
<interceptors>
<interceptor>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ApplicationName</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</injection-target-class>
<injection-target-name>
application_name
</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor
</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar>

ApplicationNameも、jazn-data.xmlポリシー・ストア定義内のアプリケーション名と一致する必要がある点に注意してください。

Oracle WebLogic Serverへのデプロイ手順:

1. Oracle WebLogic Serverにアプリケーション・サーバーの接続を作成する手順:

a. メイン・メニューで、「ウィンドウ」、「アプリケーション・サーバー」を選択します。

b. 「アプリケーション・サーバー」ウィンドウで、「アプリケーション・サーバー」ノードを右クリックし、「新規アプリケーション・サーバー」を選択して、「アプリケーション・サーバー接続の作成」ウィザードを完了します。

2. サービス・デプロイメント・プロファイルの作成:

a. 「アプリケーション」ウィンドウで、Webサービスが含まれているプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

b. 「プロジェクト・プロパティ」ダイアログの「デプロイメント」ページを開き、 「新規」をクリックします。

c. 「デプロイメント・プロファイルの作成」ダイアログで、アーカイブ・タイプとして「ビジネス・コンポーネント・サービス・インタフェース」を選択します(図15-14を参照)。

図15-14 ビジネス・コンポーネント・サービス・デプロイメント・プロファイルの作成用ダイアログ

3. メイン・メニューで、作成したデプロイメント・プロファイルに対して、「アプリケーション」→「デプロイ」を選択し、作成したデプロイメント・プロファイルを選択します。

4. 「デプロイ」ウィザードの「デプロイメント・アクション」ページで、「アプリケーション・サーバーへのデプロイ」を選択し、「次へ」をクリックします。

5. 「サーバーの選択」ページで、アプリケーション・サーバー接続を選択します。

6. 「OK」をクリックします。

15.3 サービス対応アプリケーション・モジュールによるリモート・データのアクセス

ADFビジネス・コンポーネント・アプリケーションはWebサービス用の組込みサポート、およびビュー・オブジェクト・データをサービス・データ・オブジェクト(SDO)として公開するための組込みサポートを提供しています。ローカル・データ・モデル・プロジェクト内で作成するエンティティ・オブジェクトは、サービス対応アプリケーション・モジュールがそのサービス・インタフェースで公開するSDOサービスを利用できます。ローカル・オブジェクト内でサービスバック・エンティティ・オブジェクトを作成することで、すべての共通Webサービス・データ・アクセス・タスクに対して、サービス・プロキシとSDOをプログラミングによって直接扱う必要がなくなります。

「サービス対応エンティティ・オブジェクトとビュー・オブジェクトの使用方法」に説明するように、エンティティ・オブジェクトの作成ウィザードを使用すると、エンティティ・オブジェクトを作成するときに、ローカル・データベースとADFビジネス・コンポーネントのWebサービスの間で選択することが容易になります。このようにすると、サービス対応アプリケーション・モジュールにより、データベースでローカルに使用できないデータにアクセスするための代替の方法が提供されます。

サービスバック・エンティティ・オブジェクトを作成すると、ビュー・オブジェクト、ビュー・リンクおよびビュー基準を作成して、実行時にデータをフィルタできるようになります。また、あたかもデータベース表からローカルに提供されたデータにアクセスして作業しているかのように、これらのビュー・データをデータ・モデルで活用することもできます。

次の各項では、サービス対応ADFアプリケーション・モジュールを使用して、データ・モデル・プロジェクトを強化する方法を説明します。

15.3.1 サービス対応エンティティ・オブジェクトとビュー・オブジェクトの使用方法

次のいずれかの状況が発生した場合に、アプリケーション設計戦略の一環として、サービスバック・コンポーネントを使用できます。

- クライアント・データ・モデル・プロジェクトで、別なビジネス・プロセスに含まれているサービス対応アプリケーションを使用する必要がある場合。

- クライアント・データ・モデル・プロジェクトで、プラガブルな外部サービスを使用する必要がある場合。

最初の場合は、サービスの両側を提供します。2番目の場合は、外部サービスが不明なことがあるので、次を行う必要があります。

1. サービスのFusion実装は必要ないかもしれませんが、サービス対応アプリケーション・モジュールのサービス・インタフェースがプラガブル機能のサポート単位になっており、サービスバック・エンティティ・オブジェクトおよびビュー・オブジェクト作成方法としてサポートされているので、「標準的な」プラガブル・サービスに求める形状をサービス・インタフェースに記述してアプリケーション・モジュールを作成します。

2. 「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」の説明に従ってサービス対応アプリケーション・モジュールを生成した後、サービスバック・エンティティ・オブジェクトとビュー・オブジェクトを作成する必要があります。

3. 最後にステップ2で作成した「標準的」なサービス対応アプリケーション・モジュールと同じサービス・インタフェースをサポートするEJBセッションBean(またはSCAコンポジット)を作成し、このサービス・インタフェースに基づくサービス対応ビジネス・コンポーネントを含むクライアント・プロジェクトのconnections.xmlファイルが、この「プラグイン」バージョンを使用するように構成します。

アプリケーション・モジュールをWebサービスとして公開する方法の詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

15.3.1.1 SDOサービスにバックアップされたエンティティ・オブジェクトの作成

「エンティティ・オブジェクトの作成」ウィザードで、アプリケーション・サーバー上ですでに稼働しているデプロイ済サービスを記述したWSDLドキュメントのURLを指定して、サービスバック・エンティティ・オブジェクトを作成します。WSDLは、UDDIレジストリ、またはURLエンドポイントが使用できない場合はダウンロードしたWSDLドキュメント内にあります。このウィザードはWSDLサービス記述を使用して、使用可能なサービス・ビュー・インスタンスのリストを表示します。ウィザードで、表示されたビュー・インスタンスの中から選択して、エンティティ・オブジェクトのデータ・ソースを指定します。ウィザードの実行時、WSDLドキュメントを検索するためにサービス・エンドポイントへのアクセスが可能でなければなりません。

セキュリティ保護されない(HTTP)サービス・エンドポイントを使用してのみ、サービスバックのエンティティ・オブジェクトを作成できます。セキュリティ保護された(HTTPS)サービス・エンドポイントにアクセスしようとすると、「エンティティ・オブジェクトの作成」ウィザードはでエラーが表示されます。

始める前に:

クライアントFusion WebアプリケーションでADFビジネス・コンポーネント・サービスにアクセスする方法を理解しておくと役立つ場合があります。詳細は、「サービス対応アプリケーション・モジュールによるリモート・データのアクセス」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. デプロイ済のサービスを記述するWSDLドキュメントのURLを入手します。セキュリティ保護されていないHTTP URLにアクセスできない場合、サービスのWSDLファイルをダウンロードし、ダウンロードしたWSDLを使用してローカル・ファイル・システムからサービスを取得します。

2. 「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」の説明に従い、Webサービスとしてアプリケーション・モジュールを公開します。

3. 「個別のビュー・オブジェクトのサービス対応化の方法」の説明に従い、特定のビュー・オブジェクトをサービス対応にします。

4. 「複合データ型を使用した関連するSDOプロパティの関連付け」の説明に従って、サービス対応ビュー・オブジェクトの属性に対して複合型(通貨コードまたは測定単位を含む)を必要に応じて定義します。

データ・ソースとしてサービス・ビュー・インスタンスを使用するエンティティ・オブジェクトを作成する手順:

1. 「アプリケーション」ウィンドウで、エンティティ・オブジェクトを作成するプロジェクトを右クリックし、「新規」、「エンティティ・オブジェクト」の順に選択します。

2. エンティティ・オブジェクトの作成ウィザードの「名前」ページで、次の操作を実行してエンティティ・オブジェクトを作成します。

a. エンティティ・オブジェクトが作成されるパッケージ名を入力し、エンティティ・オブジェクト名を入力します。

b. 「サービス・インタフェース」を、エンティティ・オブジェクト作成用のデータ・ソースとして選択します。

c. 公開済サービスのURLのWSDLドキュメントを入力するか、「参照」をクリックして「UDDIレジストリ」を選択し、「Webサービスの検索」ウィザードを使用してUDDIレジストリでWebサービスを検索します。URLエンドポイントにアクセスできない場合、WSDLファイルをローカル・ファイル・システムにコピーし、「参照」をクリックして「ファイル・システム」を選択し、ファイルに移動します。
JDeveloperはサービス・エンドポイントに接続して、WSDLサービス記述からサービス・ビュー・インスタンスのリストにデータを移入しようとします。エンドポイントが使用できな場合は、リストは空のままです。

d. 「サービス・ビュー・インスタンス」ドロップダウンから、データ・ソースとして適切なサービス・ビュー・インスタンスを選択します(図15-15を参照)。

図15-15 エンティティ・オブジェクトの作成ウィザードにおけるデータ・ソースとしてのサービス・インタフェース

3. 「次へ」をクリックして、エンティティ・オブジェクトの属性設定を変更してから、ウィザードを終了します。
たとえば「属性の設定」ページで、エンティティの変更時には常に変更が予想される属性について、「リフレッシュ」の「挿入後」および「リフレッシュ」の「更新後」オプションを有効化できます。通常、このような値には、行内のバージョン番号列や更新日付列などがあります。

4. 「終了」をクリックします。

15.3.1.2 サービスバック・エンティティ・オブジェクト属性を持つ複合データ型の使用

サービスバック・エンティティ・オブジェクトを作成すると、ベース・サービス対応ビュー・オブジェクトのSDOプロパティにより定義されている属性が、JDeveloperによって自動的に公開されます。エンティティ・オブジェクトに複合型の属性が含まれる場合、エンティティ・オブジェクトから複合型の関連属性を選択する必要があります。たとえば、サービスバック・エンティティ・オブジェクトでOrderTotal属性およびCurrencyCode属性を定義し、対象の国での通貨コードを指定すると仮定します。この場合、関連属性CurrencyCodeを、サービス対応ビュー・オブジェクトにより指定されるSDOプロパティのタイプにマップする必要があります。複合型でサポートされているサービス・タイプは次のとおりです。

- AmountTypeサービス・タイプは、通貨コードを定義する任意のプロパティ用です。

- MeasureTypeサービス・タイプは、測定単位を定義する任意のプロパティ用です。

概要エディタの「属性」ページを使用して、複合型として定義されたエンティティ・オブジェクトを選択します。概要エディタの「属性」ページから表示される「詳細」ダイアログを使用して、選択した属性の複合型を適切な型の関連属性にマップします。

始める前に:

クライアントFusion WebアプリケーションでADFビジネス・コンポーネント・サービスにアクセスする方法を理解しておくと役立つ場合があります。詳細は、「サービス対応アプリケーション・モジュールによるリモート・データのアクセス」を参照してください。

複合型とSDOプロパティに関する知識が役立つ場合があります。詳細は、「複合データ型を使用した関連するSDOプロパティの関連付け」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」の説明に従い、Webサービスとしてアプリケーション・モジュールを公開します。

2. 「個別のビュー・オブジェクトのサービス対応化の方法」の説明に従って、該当するビュー・オブジェクトをサービス対応にします。

3. 「複合データ型を使用した関連するSDOプロパティの関連付け」の説明に従って、サービス対応ビュー・オブジェクトの個々の属性に対して複合型を指定します。

4. 「SDOサービスにバックアップされたエンティティ・オブジェクトの作成」の説明に従って、サービス対応ビュー・オブジェクトからサービスバック・エンティティ・オブジェクトを作成します。

サービスバック・エンティティ・オブジェクトで複合型を使用して属性を関連付けるには:

1. 「アプリケーション」ウィンドウで、サービスバック・エンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、サービス対応ビュー・オブジェクトで複合型として定義された属性をベースとする属性を選択します。

選択した属性は、サービス対応ビュー・オブジェクトのSDOプロパティにより数値型として定義されます。

4. 属性を選択し、「詳細」タブをクリックして、「サービス」セクションで、「currencyCode」または「unitCode」ドロップダウン・リストから、複合型に関連付けるエンティティ・オブジェクト属性を選択します。

ドロップダウン・リストには、エンティティ・オブジェクトにより定義されているすべてのString属性が表示されます。複合型定義に関連属性としてマッピングするために適した属性を選択します。たとえば、通貨コードを、顧客が支払った金額を表示するOrderTotal属性と関連付けるには、Ordersサービスバック・エンティティ・オブジェクトのCurrencyCode属性を選択します。

SDOフレームワークは、関連サービス属性値currencyCodeおよびunitCodeをサポートしています。エディタにcurrencyCodeが表示される場合には、関連付ける属性は通貨情報を指定する必要があります。エディタにunitCodeが表示される場合には、関連付ける属性は測定単位を指定する必要があります。

15.3.1.3 SDOサービスにバックアップされたビュー・オブジェクトの作成

プロジェクトにサービスバック・エンティティ・オブジェクトを追加したら、サービスバック・ビュー・オブジェクトを作成して、ユーザー・インタフェースで使用するWebサービス・データの問合せが行え、オプションでフィルタもできます。サービスバック・ビュー・オブジェクトは、そのエンティティを単独で使用すると、SDOサービスでバックアップされたエンティティ・オブジェクトを参照するビュー・オブジェクトです。既存のビュー・オブジェクトをサービスバックにできません。ビュー・オブジェクトを作成する際に、エンティティをサービスバック・エンティティ・オブジェクト用に使用する場合は、新しいビュー・オブジェクトが自動的にサービスバックになります。

始める前に:

クライアントFusion WebアプリケーションでADFビジネス・コンポーネント・サービスにアクセスする方法を理解しておくと役立つ場合があります。詳細は、「サービス対応アプリケーション・モジュールによるリモート・データのアクセス」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「SDOサービスにバックアップされたエンティティ・オブジェクトの作成」の説明に従って、サービスバック・エンティティ・オブジェクトを作成します。

サービスバック・エンティティ・オブジェクトからビュー・オブジェクトを作成する手順:

1. 「アプリケーション」ウィンドウで、サービスバック・エンティティ・オブジェクトを右クリックし、新規デフォルト・ビュー・オブジェクトを選択します。

2. 「デフォルト・ビュー・オブジェクトの作成」ダイアログで、ビュー・オブジェクトを作成するパッケージ名を入力し、ビュー・オブジェクト名を入力します(図15-16を参照)。

生成されたビュー・オブジェクトには、エンティティ・オブジェクトと同じ属性が含まれます。オプションで、概要エディタでビュー・オブジェクトを編集し、問合せをカスタマイズできます。Webサービスのデータをフィルタする場合は、ビュー・オブジェクトのビュー基準も定義できます。問合せ結果のフィルタの詳細は、「名前付きビュー基準の処理」を参照してください。

図15-16 サービスバック・エンティティ・オブジェクトからのビュー・オブジェクトの作成

15.3.2 サービスバック・ビジネス・コンポーネント作成時の処理

サービスバック・エンティティ・オブジェクトはアクセスの詳細、および必要に応じてADFビジネス・コンポーネントWebサービスからのデータ行の変更の詳細をカプセル化するエンティティ・オブジェクトです。「エンティティ・オブジェクトの作成」ウィザードを使用してサービスバック・エンティティ・オブジェクトを作成後、JDeveloperが追加のサービス関連メタデータを、エンティティ・コンポーネント定義の<Datasource>要素に保存します。エンティティ・コンポーネント定義には、複合型定義を持つ属性も含め、サービス対応ビュー・オブジェクト・インスタンスから選択したすべての属性が含まれます(次の例を参照)。

サービスバック・ビュー・オブジェクトは、エンティティ・ベースのビュー・オブジェクトと同様に、そのメタデータ内の単一のサービスバック・エンティティ・オブジェクトを参照します。サービスバック・ビュー・オブジェクトは、他のビュー・オブジェクトと同様に使用できます。ビュー・オブジェクトに関する作業方法の詳細は、「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。ADFランタイムは、ADFビジネス・コンポーネントWebサービスとの対話を処理します。

<Entity
xmlns="http://xmlns.example.com/bc4j"
Name="Customer_ServiceBasedEO"
InheritPersnalization="true"
AliasName="CustomerSEO"
BindingStyle="OracleName"
UseGlueCode="false">
<DataSource
DataSourceClass="oracle.jbo.datasource.svc.SIEODataSourceImpl"
Type="ServiceInterface">
<ServiceInterface
ServiceName="{http://www.globalcompany.com/oesvc/}OrderEntryService"
SDOName="{http://www.globalcompany.com/oesvc/}CustomersSVO"
SVIName="{http://www.globalcompany.com/oesvc/}CustomersSVO"
CreateOpName="createCustomer"
UpdateOpName="updateCustomer"
DeleteOpName="deleteCustomer"
GetOpName="getCustomer"
FindOpName="findCustomers"
ProcessOpName="processCustomers"/>
</DataSource>
<Attribute
Name="CustomerId"
ColumnName="CustomerId"
SQLType="NUMERIC"
Type="oracle.jbo.domain.Number"
ColumnType="NUMBER"
PrimaryKey="true"/>
<!-- ... Attribute that is associated with complex type attribute ... -->
<Attribute
Name="CurrencyCode"
Precision="255"
ColumnName="CurrencyCode"
SQLType="VARCHAR"
Type="java.lang.String"
ColumnType="VARCHAR2"/>
<!-- ... Attribute with complex type mapping ... -->
<Attribute
Name="OrderTotal"
ColumnName="OrdTotal"
SQLType="NUMERIC"
Type="java.math.BigDecimal"
ColumnType="NUMBER"
<Properties>
<SchemaBasedProperties>
<DomainAttrMappings>
<DomainAttrMapping
MappedAttrName="CurrencyCode"
Name="currencyCode"/>
</DomainAttrMappings>
</SchemaBasedProperties>
</Properties>
</Attribute>
<!-- ... Other Attribute elements here ... -->
</Entity>

15.3.3 サービスバック・ビジネス・コンポーネントのデータ・モデルの更新方法

サービス・インタフェースは各ビュー・インスタンスを公開するので、コンシューミング・プロジェクトで、サービスバック・エンティティ・オブジェクト間の階層関係の定義(アソシエーションによる)、およびサービスバック・ビュー・オブジェクトの階層関係の定義(ビュー・リンクによる)を行う必要があります。サービスバック・ビジネス・コンポーネントを作成しても、ビュー・リンクとアソシエーションは自動的には作成されません。たとえば、公開済のADFビジネス・コンポーネント・サービスのアプリケーション・モジュールで、使用するマスター/ディテール関係が定義されている場合、プロジェクト内で対応するビュー・オブジェクトのビュー・リンクを定義して、この階層を維持する必要があります。

さらに、ローカルなデータとサービスバック・ビュー・オブジェクトを問い合せる(またはその逆)、ビュー・オブジェクト間のビュー・リンクは作成できますが、ビュー・リンクを一度定義すると、次のようなオブジェクト慣用名では、エンティティ・ベースのビュー・オブジェクトを作成できません。

- ビュー・オブジェクトは、サービスバック・エンティティ・オブジェクトであるセカンダリ・エンティ慣用名を参照できません。

- ビュー・オブジェクトは、セカンダリ・エンティティの慣用名付きのサービスバック・エンティティ・オブジェクトである、プライマリ・エンティ慣用名を参照できません。

クライアント・プロジェクト内の通常のエンティティ・オブジェクトとサービスバック・エンティティ・オブジェクト間のアソシエーションにも同じ制約が適用されます。アソシエーションは作成できますが、ビュー・オブジェクトは作成できません。

「ビュー・リンクの作成」ウィザードを使用して、プロジェクトで定義されたビュー・オブジェクト間の関係を指定します(図15-17を参照)。ビュー・リンクの作成の詳細は、「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」を参照してください。

図15-17 「ビュー・リンクの作成」ウィザードで定義された1対多の関係

作成するビュー・リンクでは、ローカルにアクセスしたデータベース表に問い合せるサービスバック・ビューとビュー・オブジェクト間の関係を定義できます。たとえば、サービスバック・マスター・ビュー・オブジェクトで、データベースから派生したディテール・ビュー・オブジェクトを実行する場合があります。表15-3に示す組合せで、ビュー・リンクを作成できます。

表15-3 サービスバック・ビュー・オブジェクトに関連する、サポートされているビュー・リンクの組合せ

ユースケース

マスター・ビュー・オブジェクト・タイプ

ビュー・リンク・ディテール・ビュー・オブジェクト・タイプ

ビュー・リンク・カーディナリティ

リモート・ディテールのあるローカル・マスター行

問合せベース

サービスバック

1対多

ローカル・ディテールのあるリモート・マスター行

サービスバック

問合せベース

1対多

リモート参照情報のあるローカル・マスター行

問合せベース

サービスバック

多対1

ローカル参照情報のあるリモート・マスター行

サービスバック

問合せベース

多対1

該当するビュー階層を定義したら、「ビュー・リンクの作成」ウィザードを使用して、プロジェクトのアプリケーション・モジュールの概要エディタで、データ・モデルの新しいビュー・インスタンスを定義します(図15-18を参照)。更新したデータ・モデルによって、Fusion Webアプリケーションのユーザー・インタフェースのコンポーネントとのデータバインドを可能にするADFデータ・コントロールとして、ビュー・オブジェクトを公開できます。データ・モデルの更新の詳細は、「アプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」を参照してください。

図15-18 サービス・ビュー・インスタンスが含まれたデータ・モデル

15.3.4 サービスバック・ビジネス・コンポーネント・ランタイムの構成方法

アプリケーションを実行し、公開済のサービス対応ADFアプリケーションとの対話を行ってサービス操作を起動する前に、サービス・エンドポイント・プロバイダ・タイプおよびその他の構成情報を含む、公開済サービスの記述を行う必要があります。ADFビジネス・コンポーネントのServiceFactoryクラス (oracle.jbo.client.svc.ServiceFactory)はサービスのプロキシを戻し、サービス・プロキシを使用してサービス操作を起動します。サービス・ファクトリは、3つの異なるサービス・エンドポイント・プロバイダのプロキシを戻して、これらのトランスポート・プロトコルをサポートできます。

- サービス・エンドポイント・プロバイダがADFビジネス・コンポーネントの場合は、トランスポート・プロトコルはEJB RMIです。

- サービス・エンドポイント・プロバイダがSOA Fabricの場合は、トランスポート・プロトコルはSOA Fabric SDOバインディングです。

- サービス・エンドポイント・プロバイダがSOAP (JAX-WSクライアント用)の場合は、トランスポート・プロトコルはSOAPです。

公開済のサービス操作を起動するようにコンシューミング・アプリケーションを構成する手順:

1. SDO生成クラスのbcProfileName_Common.jarファイルを、クライアント・プロジェクトのクラスパスに追加します。

2. クライアント・プロジェクトの.adf/META-INFフォルダ内のconnections.xmlファイルを更新して、公開済ADFビジネス・コンポーネント・サービスを記述します。
このファイルでの更新内容はアプリケーションで使用しているトランスポート・プロトコルがEJB RMIプロトコル、SOA Fabric SDOバインディング、またはSOAPプロトコル(JAX-WSクライアント用)のいずれかによって異なります。

15.3.4.1 クラスパスへのSDOクライアント・ライブラリの追加

アプリケーションで公開済サービスにアクセスできるようになるには、サービス・コンシューミング・プロジェクトから生成されたSDOクラスとそのスキーマ定義にアクセスできなければなりません。これらのファイルは、サービス公開を担当する開発チームが生成したbcProfileName_Common.jarファイルにパッケージされています。

アプリケーションでSDOクラスとそのスキーマ定義を使用できるようにするには、サービス・プロバイダ・チームからbcProfileName_Common.jarファイルを入手し、このJARファイルをローカル・プロジェクト・フォルダに配置します。たとえば、JARファイルをプロジェクトのdeployフォルダにコピーできます。次にJDeveloperを使用してJARファイルを、作成したSDOクライアント・ライブラリとともにプロジェクトのクラスパスに追加できます。SDOクラスJARファイルの生成手順は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。

始める前に:

クライアントFusion WebアプリケーションでADFビジネス・コンポーネント・サービスにアクセスする方法を理解しておくと役立つ場合があります。詳細は、「サービス対応アプリケーション・モジュールによるリモート・データのアクセス」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

SDOクライアント・ライブラリをクラスパスに追加する手順:

1. 「アプリケーション」ウィンドウで、SDOクラスが含まれているプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」を選択し、「ライブラリの追加」をクリックします。

3. 「ライブラリの追加」ダイアログで、「新規」をクリックして、SDOクライアント・ライブラリを作成します。

4. 「ライブラリの作成」ダイアログで、「エントリの追加」をクリックしてクラスパス・エントリを追加します。

5. 「パス・エントリの選択」ダイアログで、bcProfileName_Common.jarファイルが含まれたフォルダに移動して、そのファイルを選択し、「ライブラリの作成」ダイアログに表示します。

「パス・エントリの選択」ダイアログでは、ファイル・システムまたはローカル・エリア・ネットワークを参照して、JARファイルを検索できます。サービス・プロバイダのアプリケーション・ワークスペースのdeployフォルダを参照してJARファイルを入手できない場合、ファイルを入手して自分のプロジェクト・フォルダにコピーする必要があります。たとえば、JARファイルをプロジェクトのdeployフォルダにコピーします。

6. ダイアログで「OK」をクリックすると、SDOクライアント・ライブラリを選択した状態で「プロジェクト・プロパティ」ダイアログが表示されます。「OK」をクリックして、ライブラリをクラスパスに追加します。

図15-19に、ServiceProvider_Common.jarという名前が選択された、SDOクライアント・ライブラリを示します。この場合は、ライブラリ名はJARファイル名と同じです。オプションで、「ライブラリの作成」ダイアログでライブラリ名を編集できます。

図15-19 SDOクライアント・ライブラリ・クラスパス・エントリ

15.3.4.2 コンシューミング・アプリケーションのEJB RMIプロトコル用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

サービス・エンドポイント・プロバイダがADFビジネス・コンポーネントの場合は、サービス・ファクトリがEJBコンテナ内で実行中のステートレス・セッションBeanにバインドされた、EJBオブジェクト・プロキシを戻します。JNDIコンテキスト情報を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。

公開済ADFビジネス・コンポーネント・サービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xmlファイル内(アプリケーションに相対的な.adf/META-INFフォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。

公開済データがコンシューミング・アプリケーションでローカルに(同じJVM内で)実行されているのか、コンシューミング・アプリケーションとはな別なサーバーでリモートに実行されているのかによって、提供するJNDI検索情報は異なります。通常、ADFビジネス・コンポーネント・サービスはコンシューミング・アプリケーションとは異なっており、したがってリモートに実行されています。

公開済サービスをクライアント・アプリケーションに登録するには、次の例に示すように、connections.xmlファイルを更新します。ADFビジネス・コンポーネント・サービスがコンシューミング・アプリケーションでローカルに実行されている場合(JDeveloper内での実行時のように)、サービス・ファクトリはJNDI名さえあればサービスを検索できます。

注意:

スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、connections.xmlファイルを編集するかわりにOracle Enterprise Managerを使用してJNDIコンテキスト・プロパティを構成します。手順は、Oracle Enterprise Managerのオンライン・ドキュメントを参照してください。

<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="{www.globalcompany.com}ServiceAppModuleService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
<StringRefAddr addrType="serviceInterfaceName">
<Contents>oracle.summit.model.amservice.common.
serviceinterface.ServiceAppModuleService</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceEndpointProvider">
<Contents>ADFBC</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiName">
<Contents>ServiceAppModuleServiceBean#oracle.summit.model.amservice.common.
serviceinterface.ServiceAppModuleService</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaName">
<Contents>ServiceAppModuleService.xsd</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaLocation">
<Contents>oracle/summit/model/amservice/common/serviceinterface/</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>
...
</References>

ADFビジネス・コンポーネント・サービスがコール元クライアントに対してリモートに実行すると、リモートJNDIコンテキスト情報をconnections.xmlファイルに追加する必要があります。connections.xmlファイルにあるこれらのJNDIコンテキスト・プロパティを編集できます(次のサンプルを参照)。

- jndiFactoryInitialはweblogic.jndi.WLInitialContextFactoryに設定する必要があります。

- jndiProviderURLはJNDIプロバイダのURLで、JNDIサーバーの場所を示します。URLはt3://<hostname>:<server port>という構成でなければなりません。
たとえば、t3://localhost:8888のようなURLを指定します。ここでt3はOracle WebLogicプロトコルで、localhostはリモートOracle WebLogic Serverインスタンスが実行するホスト名、8888はポート番号です。

- jndiSecurityPrincipalは、リモートJNDIへのアクセス権のあるプリンシパル(ユーザー名)を指定します。
スタンドアロンOracle WebLogic Serverにデプロイすると、ユーザー名をファイルから読み取ることができます。

- jndiSecurityCredentialsは、セキュリティ・プリンシパルに使用する資格証明(パスワード)を指定します。
サービスをテスト環境内のスタンドアロンOracle WebLogic Serverにデプロイする際は、JNDIプロバイダ用の資格証明をプレーン・テキストで指定できます。たとえば、Oracle WebLogic ServerのJNDIプロバイダにアクセスするための十分な権限を持つ、デフォルト管理者のユーザー名/パスワード資格証明である、weblogic/weblogic1を指定できます。

サービスを本番環境にデプロイする場合は、プレーン・テキストのパスワードを削除して、セキュリティの脆弱性を回避する必要があります。次の例に示すように、connections.xmlファイルには、パスワードを設定せずに<SecureRefAddr addrType="jndiSecurityCredentials"/>を含む必要があります。スタンドアロンOracle WebLogic Server用のサービス・パスワードを構成するには、Oracleの資格証明ストアに暗号化されたパスワードを保存するOracle Enterprise Managerを使用する必要があります。

<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="{www.globalcompany.com}ServiceAppModuleService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
<StringRefAddr addrType="serviceInterfaceName">
<Contents>oracle.summit.model.amservice.common.
serviceinterface.ServiceAppModuleService</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceEndpointProvider">
<Contents>ADFBC</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiName">
<Contents>ServiceAppModuleServiceBean#oracle.summit.model.amservice.common.
serviceinterface.ServiceAppModuleService</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiFactoryInitial">
<Contents>weblogic.jndi.WLInitialContextFactory</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiProviderURL">
<Contents>t3://localhost:8888</Contents>
</StringRefAddr>
<StringRefAddr addrType="jndiSecurityPrincipal">
<Contents>a_username</Contents>
</StringRefAddr>
<SecureRefAddr addrType="jndiSecurityCredentials"/>
<StringRefAddr addrType="serviceSchemaName">
<Contents>ServiceAppModuleService.xsd</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaLocation">
<Contents>oracle/summit/model/amservice/common/serviceinterface/</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>
...
</References>

15.3.4.3 コンシューミング・アプリケーションのSOAPプロトコル用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

サービス・エンドポイント・プロバイダがSOAPの場合、サービス・ファクトリは動的なJAX-WSクライアント・プロキシを作成します。WSDL URLとポート名を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。さらに、SOAPクライアント用には、SOAPヘッダーの一部として、OWSMクライアント・セキュリティ・ポリシーを添付できます。

公開済ADFビジネス・コンポーネント・サービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xmlファイル内(アプリケーションに相対的な.adf/META-INFフォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。

注意:

スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、connections.xmlファイルを編集するかわりにOracle Enterprise Managerを使用してJNDIコンテキスト・プロパティを構成します。手順は、Oracle Enterprise Managerのオンライン・ドキュメントを参照してください。

SOAPプロトコル用にクライアント・アプリケーションに公開済サービスを登録するには、アプリケーションがアイデンティティ伝播とアイデンティティ切替えのどちらを使用しているかによって、次の例に従ってconnections.xmlファイルを更新します。アイデンティティ伝播と切替えは、各プロセスでアイデンティティを伝播するという点では同様です。Fusion Webアプリケーションでは、アイデンティティ伝播によって現在コードを実行中のアイデンティティが伝播されます。一方、アイデンティティ切替えでは、現在コードを実行中のものとは異なるアプリケーション・アイデンティティを伝播します。

公開済サービスをクライアント・アプリケーションに登録し、ユーザー・アイデンティティが資格証明キーに基づいて切り替わるようにするには、次の例に示すように、connections.xmlファイル内でクライアント側のポリシー、oracle/wss11_username_token_with_message_protection_client_policyを指定します。

注意:

connections.xmlファイルは、OWSMセキュリティ・ポリシー・クライアントのオーバーライドをサポートしています。セキュリティ・ポリシーがoracle/wss11_username_token_with_message_protection_client_policyの場合、csf-keyプロパティにオーバーライドして、コンシューミング・アプリケーションの資格証明を指定できます。

<Reference name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
<StringRefAddr addrType="serviceInterfaceName">
<Contents>oracle.apps.sample.hrService.HrService</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceEndpointProvider">
<Contents>SOAP</Contents>
</StringRefAddr>
<StringRefAddr addrType="webServiceConnectionName">
<Contents>HrServiceConnection</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaName">
<Contents>HrService.xsd</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaLocation">
<Contents>oracle/apps/sample/hrService/</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>
<Reference name="HrServiceConnection"
className="oracle.adf.model.connection.webservice.impl.WebServiceConnectionImpl" xmlns="">
<Factory
className="oracle.adf.model.connection.webservice.api.WebServiceConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="WebServiceConnection">
<Contents>
<wsconnection
description="http://rws65094fwks:7202/MySampleSvc/HrService?WSDL"
service="{http://xmlns.oracle.com/apps/sample/hrService/}HrService">
<model
name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService"
xmlns="http://oracle.com/ws/model">
<service name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService">
<port name="HrServiceSoapHttpPort"
binding="{http://xmlns.oracle.com/apps/sample/hrService/}HrServiceSoapHttp"
portType="http://xmlns.oracle.com/apps/sample/hrService/}HrService">
<call-properties xmlns="http://oracle.com/adf">
<call-property id="csf-key" xmlns="">
<name>csf-key</name>
<value>meuser.credentials</value>
</call-property>
</call-properties>
<policy-references xmlns="http://oracle.com/adf">
<policy-reference category="security"
uri="oracle/wss11_username_token_with_message_protection_client_policy"
enabled="true"
id="oracle/wss11_username_token_with_message_protection_client_policy"
xmlns=""/>
</policy-references>
<soapaddressUrl="http://rws65094fwks:7202/MySampleSvc/HrService"
xmlns="http://schemas.xmlsoap.org/wsdl/soap/"/>
</port>
</service>
</model>
</wsconnection>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>

公開済サービスをクライアント・アプリケーションに登録し、ユーザー・アイデンティティをコール元に伝播させるには、次の例に示すように、connections.xmlファイル内で、クライアント側のポリシー、oracle/wss11_saml_token_with_message_protection_client_policyを指定します。

<Reference name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
<StringRefAddr addrType="serviceInterfaceName">
<Contents>oracle.apps.sample.hrService.HrService</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceEndpointProvider">
<Contents>SOAP</Contents>
</StringRefAddr>
<StringRefAddr addrType="webServiceConnectionName">
<Contents>HrServiceConnection</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaName">
<Contents>HrService.xsd</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaLocation">
<Contents>oracle/apps/sample/hrService/</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>
<Reference name="HrServiceConnection"
className="oracle.adf.model.connection.webservice.impl.WebServiceConnectionImpl" xmlns="">
<Factory
className="oracle.adf.model.connection.webservice.api.WebServiceConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="WebServiceConnection">
<Contents>
<wsconnection
description="http://rws65094fwks:7202/MySampleSvc/HrService?WSDL"
service="{http://xmlns.oracle.com/apps/sample/hrService/}HrService">
<model
name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService"
xmlns="http://oracle.com/ws/model">
<service
name="{http://xmlns.oracle.com/apps/sample/hrService/}HrService">
<port name="HrServiceSoapHttpPort"
binding="{http://xmlns.oracle.com/apps/sample/hrService/}HrServiceSoapHttp"
portType="http://xmlns.oracle.com/apps/sample/hrService/}HrService">
<policy-references xmlns="http://oracle.com/adf">
<policy-reference category="security"
uri="oracle/wss11_saml_token_with_message_protection_client_policy"
enabled="true"
id="oracle/wss11_saml_token_with_message_protection_client_policy"
xmlns=""/>
</policy-references>
<soap addressUrl="http://rws65094fwks:7202/MySampleSvc/HrService"
xmlns="http://schemas.xmlsoap.org/wsdl/soap/"/>
</port>
</service>
</model>
</wsconnection>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>

15.3.4.4 コンシューミング・アプリケーションのファブリックSDOバインディング用connections.xmlへの、ADFビジネス・コンポーネント・サービスの登録

サービス・エンドポイント・プロバイダがファブリックの場合は、サービス・ファクトリによってSOAファブリック・コンポジット・プロキシが戻され、ファブリックのSDOバインディングを使用してファブリック・コンポジット内で実行中のサービスがコールされます。ファブリック・コンポジット名を提供して、コンシューミング・アプリケーションが公開済サービスを検索できるようにする必要があります。

公開済ADFビジネス・コンポーネント・サービスの登録用に提供する検索情報は、Fusion Webのコンシューミング・アプリケーションのconnections.xmlファイル内(アプリケーションに相対的な.adf/META-INFフォルダ内)にあります。ADF接続アーキテクチャはこのファイルを使用してサービス・エンドポイント・プロバイダの詳細をカプセル化します。

注意:

スタンドアロンOracle WebLogic Serverにコール元アプリケーションをデプロイする場合は、connections.xmlファイルを編集するかわりにOracle Enterprise Managerを使用してJNDIコンテキスト・プロパティを構成します。手順は、Oracle Enterprise Managerのオンライン・ドキュメントを参照してください。

公開済サービスをファブリック・プロトコルのクライアント・アプリケーションに登録するには、次の例に示すように、connections.xmlファイルを更新します。ここで、fabricAddressは公開済サービスのファブリック・コンポジット名です。

<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="{www.globalcompany.com}ServiceAppModuleService"
className="oracle.jbo.client.svc.Service" xmlns="">
<Factory className="oracle.jbo.client.svc.ServiceFactory"/>
<RefAddresses>
<StringRefAddr addrType="serviceInterfaceName">
<Contents>oracle.summit.model.amservice.common.
serviceinterface.ServiceAppModuleService</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceEndpointProvider">
<Contents>Fabric</Contents>
</StringRefAddr>
<StringRefAddr addrType="fabricAddress">
<Contents>fabric_ServiceAppModuleService</Contents>
<StringRefAddr addrType="serviceSchemaName">
<Contents>ServiceAppModuleService.xsd</Contents>
</StringRefAddr>
<StringRefAddr addrType="serviceSchemaLocation">
<Contents>oracle/summit/model/amservice/common/serviceinterface/</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>
...
</References>

15.3.5 Oracle ADFモデル・テスターでのサービスバック・コンポーネントのテスト方法

「サービスバック・ビジネス・コンポーネント・ランタイムの構成方法」に説明するように、Oracle ADFモデル・テスターを起動する前に、プロジェクトがランタイム要件を満たす必要があります。Oracle ADFモデル・テスターでは、リモートWebサービスから作成したビュー・オブジェクトが表示され、サービスと対話して標準的なCRUD操作を実行できます。

実行するアプリケーション・モジュールはローカルに問い合せたデータとリモートに問い合せたデータに一緒にアクセスできるので、サービスバック・ビュー・オブジェクトとデータベースから派生したビュー・オブジェクトが同じテスターに表示されます。Oracle ADFモデル・テスターで、サービスバック・ビュー・オブジェクトを選択したときにエンドポイントが使用できない場合は、ランタイム例外が発生します。

Oracle ADFモデル・テスターの実行方法の詳細は、「構成を使用したOracle ADFモデル・テスターの実行方法」を参照してください。

15.3.6 コンシューミング・アプリケーションでのサービスバック・コンポーネント操作起動方法

ADFビジネス・コンポーネント・サービス・インタフェースでは、サービス・プロキシを戻して、起動した操作が公開済サービスで指定したトランスポート・プロトコルを使用していることを確認する必要があります。

始める前に:

クライアントFusion WebアプリケーションでADFビジネス・コンポーネント・サービスにアクセスする方法を理解しておくと役立つ場合があります。詳細は、「サービス対応アプリケーション・モジュールによるリモート・データのアクセス」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- コンシューミング・アプリケーションが、クラスパス上に正しいライブラリを持っていることを確認してください。「アプリケーション」ウィンドウでプロジェクトをダブルクリックし、「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」を選択し、次のライブラリが表示されることを確認します。

- Java EE 1.5

- Oracle XML Parserバージョン2

- BC4Jサービス・クライアント

- JAX-WSクライアント

- サービスの共通JARファイル

次の例に示すように、操作を起動する際、次のタスクを実行します。

1. oracle.jbo.client.svc.ServiceFactoryクラスと公開済サービス・クラスをインポートします。

2. サービス・ファクトリ・オブジェクト上でgetServiceProxy()をコールし、<serviceName>.NAMEの形式でサービス名を渡します。ADFサービス・ファクトリはこの方法で戻されたサービス・プロキシ・オブジェクトにSDOHelperContext IDを組み込み、最新のADFビジネス・コンポーネント・サービス・スキーマ・メタデータがSDOに提供されるようにします。

サービス・オブジェクトのスキーマ(.xsdファイル)は通常MDSに保存されており、たとえばビジネス・コンポーネント属性の追加、既存の型の拡張、新しい型の定義などのために拡張されている場合があります。ローカル・ヘルパー・コンテキストにより、他のサービスのSDOメタデータに影響を及ぼすことなく、アプリケーションの再起動を行わなくても、各サービス・スキーマ定義のカスタマイズが可能です。

3. データ・ファクトリ・オブジェクト上でcreate()をコールし、プロキシ・オブジェクトをgetServiceProxy()コールで入手します。

4. プロキシ・オブジェクト上で操作を起動すると、データ・オブジェクトが戻されます。

5. 戻されたデータ・オブジェクトをXMLとして保存します。

import commonj.sdo.DataObject;
import commonj.sdo.helper.DataFactory;
import commonj.sdo.helper.XMLHelper;
import hr.common.Dept;
import hr.common.serviceinterface.HRAppService;
import oracle.jbo.client.svc.ServiceFactory;
...
{
HRAppService proxy = (HRAppService) ServiceFactory.getServiceProxy(HRAppService.NAME);

Dept dept = (Dept)
ServiceFactory.getDataFactory(proxy).create("http://example.com/hr/common/" "Dept");
dept.setDname("ENGINEERING");
...
dept = proxy.createDept(dept);
String xml = ServiceFactory.getXMLHelper(proxy).save((DataObject) dept,
"http://example.com/hr/common/", "dept");
out.print(xml);
}

15.3.7 コンシューミング・アプリケーションでのサービス・データ・オブジェクトの作成に関する必知事項

ADFサービス・インタフェース・フレームワークは、一連の共通データ・オブジェクト(oracle.jbo.common.service.types.FindCriteria、oracle.jbo.common.service.types.FindControl、oracle.jbo.common.service.types.ProcessControlなど)を定義します。これらのデータ・オブジェクトは、標準のfindXxx()メソッドおよびprocessXxx()メソッドの各コールで使用されます。これらのデータ・オブジェクトは、コンシューミング・アプリケーションで作成して、標準サービス・メソッドに渡すことができます。次の例に示すように、データ・ファクトリ・クラスのcreate()メソッドをコールして、findXxx()またはprocessXxx()メソッドに渡す前に、これらのデータ・オブジェクトを作成する必要がある場合があります。

FindCriteria fc = (FindCriteria) ServiceFactory.getDataFactory(proxy).create
("http://xmlns.oracle.com/adf/svc/types/", "FindCriteria");

15.3.8 コンシューミング・アプリケーションでの組込みサービス・メソッドの呼出しに関する必知事項

表15-2で説明するように、ADFサービス・インタフェース・フレームワークは、getDftlObjAttrHints()、getServiceLastUpdateTime()、and getEntityList()など、サービス・ビュー・インスタンスに対してオプションで有効にできるいくつかの組込みSOAPサービス・メソッドを定義します。これらのメソッドは、主に、コンシューミング・アプリケーションによるサービス・エンドポイントとのプログラムによる対話をサポートし、データ・コントロールによって設計時にはサポートされません。

15.3.9 アプリケーションが公開済のアプリケーション・モジュールにアクセスする場合の実行時の処理

ADFランタイムはデータ・ソース情報をサービスバック・エンティティ・オブジェクトXML定義から入手し、必要に応じてサービス・インタフェース・メソッドとの対話を自動化します。サービスバック・エンティティ・オブジェクトを使用することで、すべての共通Webサービスのデータ・アクセス・タスクに対して、サービス・プロキシおよびサービス・データ・オブジェクトを直接プログラミングする必要がなくなります。ADFサービス・ファクトリはサービスを検索し、connections.xmlで指定したサービス・インタフェースを使用して、サービス・メソッドを起動します。

アプリケーションがADFビジネス・コンポーネントWebサービスにアクセスする際、各リモート・コールはステートレスで、リモート・サービスは、サービス対応のアプリケーション・モジュールのサービス・インタフェースを使用するビジネス・コンポーネントと同じトランザクションには関与しません。

ほとんどの場合、リモート・サービスへのコールは情報提供を目的としたもので、リモート・オブジェクトは変更されません。ただし、リモート・サービスを使用して変更を行う必要がある場合は、次の点に注意してください。

- リモート・サービスにスローされた例外によって、ローカル・トランザクションが失敗します。

- データ変更を伴うリモート・サービス・コールが成功した後、なんらかの理由でローカル・トランザクションが失敗した場合、エラー処理コードを使用して、リモート・サービスに対して復元トランザクションを行い、過去の変更を「取り消す」必要があります。

15.3.10 サービスバック・エンティティ・オブジェクトおよびビュー・オブジェクトに関する必知事項

参照情報にアクセスするために使用するWebサービスもあります。また、データを変更するためにコールするサービスもあります。サービスが社内の自分自身のチームまたは別のチームによって記述されていた場合、このデータ変更が自社のデータベース内で発生する可能性があります。Webサービスが自社のファイアウォールの外部にある場合は、変更対象のデータベースは、当然、別の会社によって管理されます。いずれの場合でも、起動するWebサービスによって実行されるデータ変更は、サービス対応のアプリケーション・モジュールの現在の作業ユニットとは無関係な独自のトランザクションによって実行されるということを理解しておくことが重要です。たとえば、データを変更するWebサービスを起動した後、rollback()をコールしてアプリケーション・モジュールの現在の作業ユニット内で保留中の変更を取り消しても、該当するプロセス内でコールしたWebサービスで実行した変更に対しては、ロールバックの影響はありません。対応するWebサービス・メソッドを起動して、補正用の変更を実行し、アプリケーション・モジュールのトランザクションのロールバックを無効にする必要がある場合があります。

実行時、ADFはADFビジネス・コンポーネントWebサービスとの対話を処理します。ただし、サービスバック・ビジネス・コンポーネントには、次のような設計時の制約があり、これによってアプリケーションの実行時の動作が制限されることがある点を認識しておく必要があります。

- 作成するビュー・オブジェクトは、サービスバック・エンティティ・オブジェクトを、セカンダリ・エンティティ・オブジェクト慣用名として参照できません。

- 作成するビュー・オブジェクトは、関連する複数のエンティティ・オブジェクトのいずれかがサービスバック・エンティティ・オブジェクトの場合、これらのエンティティ・オブジェクトからフラット化された結合を生成できません。

- サービスバック・エンティティ・オブジェクトから作成するサービスバック・ビュー・オブジェクトは、セカンダリ・エンティ慣用名を参照しません。

設計時におけるこれらの制約の適用の詳細は、「サービスバック・ビジネス・コンポーネントのデータ・モデルの更新方法」を参照してください。

15.4 コンシューミング・アプリケーションでの多相コレクションへのアクセス

ADFモデル・プロジェクトは、共通ベース・ビュー・オブジェクトから導出された1つ以上のサブタイプ・ビュー・オブジェクトを定義するベース・ビュー・オブジェクトを含むことができます。ビジネス・コンポーネント開発者は、ベース・ビュー・オブジェクト・インスタンスの多相オブジェクトの慣用名を公開する場合、ADFデータ・モデルにサブタイプを追加します。ただし、開発者がアプリケーション・モジュール・ビュー・インスタンスからSDOサービス・インタフェースを作成する場合、多相サブタイプ・ビュー・オブジェクトのサブタイプSDOは、SDOサービス・インタフェースで直接参照されません。

ベース・ビュー・オブジェクトとサブタイプ・ビュー・オブジェクトを定義するADFモデル・プロジェクトからSDOインタフェースを生成した後、生成されたXMLスキーマ(.xsd)は、ベース・ビュー・オブジェクトに対しては厳密に型指定されますが、多相サブタイプに対しては異なります。このため、多相サブタイプ・ビュー・オブジェクトにアクセスする必要があるWebサービス・クライアントは、他の手法を使用して、SDOインタフェースの公開済操作を起動します。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのカスタム・プロジェクトPolymorphicVO_WSClientを参照します。クライアント・プロジェクトは、同じワークスペースのモデル・プロジェクトのoracle.summit.model.polymorphicvoパッケージ内に作成されたSDOサービス・インタフェースにアクセスします。

15.4.1 サービス対応アプリケーション・モジュールからWebサービス・クライアント・プロキシ・クラスを作成する方法

JDeveloperでは、Webサービス・クライアント・プロジェクトに追加したリモート・サービス対応アプリケーション・モジュールWebサービスへのプロキシとして機能するJavaクラスを生成できます。これを実現するには、Webサービス・クライアントおよびプロキシの作成ウィザードを使用して、デプロイ済サービスにWSDL URLを入力します。ウィザードは、プロキシ・クラスを使用するクライアント・ファイルを作成して、WebサービスにアクセスするためのJavaメソッド・コールを実行できるようにします。

始める前に:

SDOフレームワークによるサービス対応ADFビュー・オブジェクトのサポート方法と、Webサービス・クライアントによるデータ行のアクセスやサービス操作の許可方法を理解しておくと便利です。詳細は、「サービス対応アプリケーション・モジュールの公開」を参照してください。

JAX-WS Webサービス・クライアントとプロキシ・クラスを作成することによって、JDeveloperがJavaアプリケーションにおけるWebサービスへのアクセスをどのようにサポートするかを理解しておくと役に立ちます。詳細は、『Oracle JDeveloperによるアプリケーションの開発』のJAX-WS Webサービスとクライアントの作成に関する項を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「サービス対応アプリケーション・モジュールの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「多相ビュー・オブジェクトの定義」の説明に従って、目的のサブタイプ・ビュー・オブジェクトを作成し、サブタイプを使用してアプリケーション・モジュール・ビュー・インスタンスで多相慣用名を構成します。

2. 「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」の説明に従って、アプリケーション・モジュールのサービス・インタフェースを有効にします。

3. サービス・メソッドを起動するために使用するWebサービス・プロキシ・クラスを含むクライアント・プロジェクトを作成します。
ヒント: JDeveloperでJavaクライアント・プロジェクトを未作成の場合、カスタム・プロジェクトを作成してWebサービス・プロキシ・クラスを含めます(『Oracle JDeveloperによるアプリケーションの開発』のアプリケーションとプロジェクトの作成に関する項を参照)。

4. JDeveloperでWebサービスを実行して、WSDLドキュメントの場所を指定するために使用するサービス・エンドポイントURLを取得します。
ヒント: 「Integrated WebLogic Serverを使用したWebサービスのテスト方法」の説明に従って、Integrated WebLogic Serverでサービスを実行し、「ログ」ウィンドウからサービス・エンドポイントURLを取得します。

サービス・クライアントとプロキシ・ファイルを生成する手順:

1. 「アプリケーション」ウィンドウで、クライアント・プロキシ・クラスを含めるクライアント・プロジェクトを選択し、「ファイル」→「新規ギャラリ」を選択して、「カテゴリ」リストから、「ビジネス層」と「Webサービス」を展開し、「Webサービス・クライアントおよびプロキシ」を選択します。

2. Webサービス・クライアントおよびプロキシの作成ウィザードの「Webサービス記述を選択」ページで、「ログ」ウィンドウからコピーしたサービス・エンドポイントURLを「WSDLドキュメントURL」フィールドに貼り付け、URLの終わりに?WSDLを追加し、すべてのデフォルトを了承して、「終了」をクリックします。

たとえば、デプロイするADF Webサービスの名前がADFModuleServiceの場合、?WSDLを追加したWSDLドキュメントURLは、次のようになります。

http://<ipaddress>/ADFServiceDemo-ADFModel-context-root/AppModuleService?WSDL

15.4.2 生成したプロキシ・クラスを使用して多相ビュー・オブジェクトの操作を呼び出す方法

JDeveloperで、Webサービス・スキーマから生成されたクラスを使用して、JAXB (Java Architecture for XML Binding)を介してWebサービスにアクセスするJavaクライアントを作成できます。JAXBパッケージ、プロキシ・クラスおよびインタフェースを生成するために、クライアント開発者は、ADFビジネス・コンポーネント・サービス・スキーマ(WSDL)に対して、JAXBバインディング・コンパイラを実行します。開発者は、プロキシ・クラス関連の作業で、サービスXMLの知識を要求しません。

生成されたプロキシ・クラスを使用すると、開発者は、クライアント・プロジェクトのJavaクラス・ファイルで実行するメソッド・コールで多相コレクションにアクセスし、操作できます。そのようなファイルのサンプルは、生成されたSOAPサービス・クライアントJavaクラス・ファイルです。生成されたクライアント・ファイルは、WSDLドキュメントURLとともに入力したデプロイ済ADF Webサービスに対して命名されます。たとえば、デプロイするADF Webサービスの名前がADFModuleServiceの場合、SOAPサービス・クライアントJavaクラスはAppModuleServiceSoapHttpPortClient.javaと命名されます。

始める前に:

多相コレクションがリモート・サービスとしてアクセスできない理由を理解しておくと役に立ちます。詳細は、「コンシューミング・アプリケーションでの多相コレクションへのアクセス」を参照してください。

次のタスクを完了する必要があります。

- サービス対応アプリケーション・モジュールWebサービス用のJavaプロキシ・クラスを含むJavaクライアント・プロジェクトを作成します。詳細は、「サービス対応アプリケーション・モジュールからWebサービス・クライアント・プロキシ・クラスを生成する方法」を参照してください。

- 「アプリケーション」ウィンドウで、クライアント・プロジェクトを展開し、SOAPサービス顧客ファイルを見つけます。図15-17に示すように、AppModuleServiceSoapHttpPortClient.javaファイルはクライアント・プロジェクトのcom.oracle.xmlnsパッケージにあります。

図15-20 JAXB生成済SOAPサービス・クライアント・ファイル

さらに、ベースおよびサブタイプ・ビュー・オブジェクトの公開操作を呼び出すためのSOAPサービス顧客ファイルの編集に進むことができます。サブタイプ・ビュー・オブジェクトにファクトリ・オブジェクトを作成する例を次に示します。

1. サブタイプ・ビュー・オブジェクトのファクトリ・メソッドを使用してコレクションを作成します。

この例では、サービス・ファクトリ・オブジェクト上でcreateSalespersonViewExSDO()をコールすると、サブタイプSalespersonの従業員が作成されます。

2. サービス・ファクトリ・オブジェクトのセッターをコールして、サブタイプのベース・ビュー・オブジェクトが定義する、必須およびオプションの属性を設定します。

オプション属性の値は、特殊なタイプfactory.createViewAttrNameタイプとしてキャストする必要があります(「クライアント・アプリケーションでのサービス・メソッドの呼出しに関する必知事項」を参照)。

3. サービス・ファクトリ・オブジェクトのセッターをコールして、サブタイプ・ビュー・オブジェクトが定義する、必須およびオプションの属性を設定します。

この例では、Salespersonサブタイプは、営業部従業員の売上げ手数料に当たる単一の必須属性CommissionPctを定義します。

4. コレクション上で他の操作を呼び出します。

この例では、deleteSEmpView1()はEmployeeコレクション上の作成済Salesperson行を削除し、findSEmpView1ByDept()が部門ごとの従業員のリストを検索します。

package com.oracle.xmlns.apps.hr.service;

...

import oracle.summit.model.polymorphicvo.views.common.ObjectFactory;
import oracle.summit.model.polymorphicvo.views.common.SEmpViewSDO;

import oracle.summit.model.polymorphicvo.views.common.SalespersonViewExSDO;

...

public class AppModuleServiceSoapHttpPortClient {
public static void main(String[] args) {
AppModuleService_Service appModuleService_Service =
new AppModuleService_Service();
AppModuleService appModuleService =
appModuleService_Service.getAppModuleServiceSoapHttpPort();

...

// Add your code to call the desired methods.
try {
SEmpViewSDO emp = testCreate(appModuleService);
testFind(appModuleService);
testDelete(appModuleService, emp);
testFind(appModuleService);
} catch (ServiceException e) {
}

}

...
// 1. Create an employee of subtype Salesperson
private static SEmpViewSDO testCreate(AppModuleService deptService) throws
ServiceException
{
oracle.summit.model.polymorphicvo.views.common.ObjectFactory factory = new
oracle.summit.model.polymorphicvo.views.common.ObjectFactory();

System.out.println("\n*** Testing createEmp ***\n");
SalespersonViewExSDO salesperson = factory.createSalespersonViewExSDO();
// 2. Set the attrs of the base SEmpView view object
salesperson.setId(8001);
salesperson.setFirstName(factory.createSEmpViewSDOFirstName("Lynn"));
salesperson.setLastName("Munsinger");
salesperson.setEmail(factory.createSEmpViewSDOEmail
("lmunsing@summit.com"));
salesperson.setTitleId(factory.createSEmpViewSDOTitleId
(new BigDecimal(2)));
salesperson.setSalary(factory.createSEmpViewSDOSalary
(new BigDecimal(2000)));
// 3. Set the attrs of the subtype SalespersonView view object
salesperson.setCommissionPct
(factory.createSalespersonViewExSDOCommissionPct
(new BigDecimal(20)));
salesperson.setDeptId(factory.createSEmpViewSDODeptId(31));

return printEmp(deptService.createSEmpView1(salesperson));
}

// 4. Delete the employee of type Salesperson
private static void testDelete(AppModuleService deptService, SEmpViewSDO emp)
throws ServiceException
{
System.out.println("\n*** Testing deleteEmp ***\n");
deptService.deleteSEmpView1(emp);
}

// 5. Print
private static SEmpViewSDO printEmp(SEmpViewSDO emp)
{
System.out.print(emp.getId() + "\t" + emp.getEmail().getValue() + "\t" +
emp.getTitle().getValue() + "\t" +
"\t" + emp.getSalary().getValue());
if (emp instanceof SalespersonViewExSDO)
{
System.out.print("\t" + ((SalespersonViewExSDO)
emp).getCommissionPct().getValue());
}
System.out.println();
return emp;
}

// 6. Find employees by department
private static void testFind(AppModuleService deptService) throws
ServiceException
{
com.oracle.xmlns.adf.svc.types.ObjectFactory factory = new
com.oracle.xmlns.adf.svc.types.ObjectFactory();

System.out.println("\n*** Testing findEmpsByDept ***\n");
FindCriteria fc = factory.createFindCriteria();
fc.setFetchStart(0);
fc.setFetchSize(-1);

List<SEmpViewSDO> empList =
deptService.findSEmpView1ByDept(fc, "SALES", null);
for (SEmpViewSDO emp : empList)
{
printEmp(emp);
}
}
}

JDeveloperでAppModuleServiceSoapHttpPortClient.javaクライアントを実行すると、「ログ」ウィンドウに次の出力が生成されます。createEmpメソッドは、営業部門に従業員を、EmpViewコレクションのSalespersonサブタイプとして作成します。属性値20は、新しい多相ビュー行のCommission属性です。findEmpsByDeptメソッドは、EmpViewベース・ビュー行とSalespersonViewサブタイプ行の混合を表示します。残りのメソッドは、EmpViewコレクションから作成済販売員を削除して、結果を出力します。

*** Testing createEmp ***

8001 lmunsing@summit.com    Sales Representative    2000   20

*** Testing findEmpsByDept ***

3     mnagayam@summit.com   VP, Operations          1400
11    cmagee@summit.com     Sales Representative    1400   10
13    ysedeghi@summit.com   Sales Representative    1515   10
14    mnguyen@summit.com    Sales Representative    1525   15
15    adumas@summit.com     Sales Representative    1450   17.5
23    rpatel@summit.com     Stock Clerk             795
8001  lmunsing@summit.com   Sales Representative    2000   20

*** Testing deleteEmp ***

*** Testing findEmpsByDept ***

3   mnagayam@summit.com    VP, Operations           400
11  cmagee@summit.com      Sales Representative     1400   10
13  ysedeghi@summit.com    Sales Representative     1515   10
14  mnguyen@summit.com     Sales Representative     1525   15
15  adumas@summit.com      Sales Representative     1450   17.5
23  rpatel@summit.com      Stock Clerk              795

15.4.3 SDOスキーマを使用してJavaプロキシ・クラスを作成する際に行われる処理

JAXBバインディング・コンパイラは、サービス・インタフェースWSDLによって公開される各種SDOビュー・インスタンスのためのアプリケーション・モジュール・サービスとオブジェクト・ファクトリ・クラスのためのJavaプロキシ・クラスを生成します。多相ビュー・オブジェクトは、ベース・ビュー・オブジェクトのタイプ階層で定義されるため、厳密に型指定されたプロキシ・クラスも持ちます。図15-21に示すように、SalespersonViewSDO.javaプロキシ・クラスは、ベース・ビュー・オブジェクトSEmpViewのプロキシ・クラス SEmpViewSDO.javaとともに表示されます。

図15-21 JAXB生成済SOAPサービス・クライアント・プロキシ・クラス

次の例に示すように、EmployeeViewビュー・オブジェクトにサブタイプSalespersonViewビュー・オブジェクトが定義されている場合、生成されるWebサービス・クライアントには、ベース・プロキシ・クラス(SEmpViewSDO)を拡張してcommissionPct属性のアクセッサ・メソッドを定義するプロキシ・クラスSalespersonViewSDO.javaが含まれます。

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "SalespersonViewExSDO", propOrder = { "commissionPct" })
public class SalespersonViewExSDO extends SEmpViewSDO {

@XmlElementRef(name = "CommissionPct", namespace =
"/oracle/summit/model/polymorphicvo/views/common/",
type = JAXBElement.class, required = false)
protected JAXBElement<BigDecimal> commissionPct;
/**
* Gets the value of the commissionPct property.
*
* @return
*     possible object is
*     {@link JAXBElement }{@code <}{@link BigDecimal }{@code >}
*
*/
public JAXBElement<BigDecimal> getCommissionPct() {
return commissionPct;
}

/**
* Sets the value of the commissionPct property.
*
* @param value
*     allowed object is
*     {@link JAXBElement }{@code <}{@link BigDecimal }{@code >}
*
*/
public void setCommissionPct(JAXBElement<BigDecimal> value) {        this.commissionPct = value;
}
}

15.4.4 クライアント・アプリケーションでのサービス・メソッドの呼出しに関する必知事項

オプションで、ADFビジネス・コンポーネント・サービス・インタフェースの生成済サービス・ファクトリ・クラスが定義する組込みメソッドを有効化して、サービス・ビュー・インスタンスを作成できます。たとえば、多相ビュー・オブジェクトの場合、createSalespersonView()を有効化して、多相ビュー・オブジェクトのインスタンスを作成できます。ファクトリ作成メソッドを使用してビュー・インスタンスの属性を定義する場合、ビュー・オブジェクトの必須属性のメソッド・シグネチャは、オプションで定義できる属性とは異なります。

たとえば、SalepersonViewSDO.javaがビュー・オブジェクトの必須属性のセッターを定義する場合、クライアント・コードは必須属性にJavaプリミティブ値を使用できます。ただし、オプション属性のセッターは、XML要素がなく、ただの空の値でないことを示す特殊な型を使用する必要があります。ファクトリ・オブジェクト・メソッドは、オプションのビュー・オブジェクト属性の特殊な型をサポートします。次の例は、setFirstNameのメソッド・シグネチャがfactory.createSEmpViewSDOFirstNameを起動し、その一方で必須属性のメソッド・シグネチャ(setIdやsetLastNameなど)が整数および文字列値を取得することを示しています。

private static SEmpViewSDO testCreate(AppModuleService deptService) throws
ServiceException
{
oracle.summit.model.polymorphicvo.views.common.ObjectFactory factory = new
oracle.summit.model.polymorphicvo.views.common.ObjectFactory();

System.out.println("\n*** Testing createEmp ***\n");
SalespersonViewExSDO salesperson = factory.createSalespersonViewExSDO();
salesperson.setId(8001);
salesperson.setFirstName(factory.createSEmpViewSDOFirstName("Lynn"));
salesperson.setLastName("Munsinger");
salesperson.setEmail
(factory.createSEmpViewSDOEmail("lmunsing@summit.com"));
salesperson.setTitleId
(factory.createSEmpViewSDOTitleId(new BigDecimal(2)));
salesperson.setSalary
(factory.createSEmpViewSDOSalary(new BigDecimal(2000)));
salesperson.setCommissionPct
(factory.createSalespersonViewExSDOCommissionPct(new BigDecimal(20)));
salesperson.setDeptId(factory.createSEmpViewSDODeptId(31));

return printEmp(deptService.createSEmpView1(salesperson));
}

15.5 コンシューミング・アプリケーションでの検索メソッド・フィルタ・モデルの使用

ADFでは、SOAPリクエストまたはクライアント・コードとしてプログラム的に起動される検索メソッドの制御をSOAPクライアントで可能にするFindCriteriaオブジェクトに対して、次のフィルタ・モデルが定義されます。

フィルタ—>グループ—>アイテム

フィルタは、すべての実行時条件を含み、ADF内のビュー基準に対応します。ビュー基準は、定義されたフィルタに一致する行に返されるデータを制限します。実行時に、表示オブジェクトに対するデータ・フィルタを提供するために、フィルタはSQL WHERE句に変換されます。フィルタ内で、グループは、SDOの1つ以上の属性に対する実行時フィルタ条件のセットを含みます。

注意:

検索メソッド問合せに参加する属性は、バッキング表示オブジェクトにより問合せ可能に定義する必要があります。アイテムは、1つのフィルタ条件を特定の属性に定義します。

FindCriteriaオブジェクトのXSDダイアグラムは、検索メソッドの引数が作成される方法を詳細に説明します。

図15-22 FindCriteria XSDダイアグラム

結合(And、Or、Not、AndNot、OrNot)を指定して、複数のアイテムをグループで定義すると、定義フィルタ条件が互いに関係して評価されます。たとえば、AND結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。OR結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。結合が省略されると、Andの動作であると判断されます。

次のブロック・ダイアグラムは、FindCriteriaオブジェクトの包含モデルを別の方法で示します。

図15-23 FindCriteria包含階層

FindCriteriaに、フィルタitemを指定するには、クライアントで次を定義する必要があります。

- Attributeは、フィルタ条件でフィルタ処理される属性名で、大/小文字を区別します。

- Operatorは、フィルタ条件に適用されます。演算子は、属性タイプに適しており、oracle.jbo.common.JboCompOperによって定義されます。例外については、後述の「注意」を参照してください。

- Valueは、属性フィルタ基準を指定し、非先導型の%ワイルドカードを含むことができます。

注意:

SOAPサービス・クライアントでは、oracle.jbo.common.JboCompOperで定義されるすべての演算子を使用して条件を指定できます。ただし、LIKE (かわりにCONTAINSを使用)、INおよびNOTINは除外されます。演算子INおよびNOTINには、実行時にサポートされているため、プログラム的に適用されます。演算子CONTAINSALLおよびCONTAINSDELIMITEDIDは、複数選択の属性でサポートされています。

加えて、クライアントは、次のFindCriteria要素を指定して、結果セットのレスポンスを形式化します。

- FetchStart (必須)は、ゼロから始まる列索引を指定します。デフォルトは0 (最初の行)です。

- FetchSize (必須)は、受信する行の最大数を指定します。

- SortOrder (オプション)には、昇順または降順で結果セットをソートするディレクティブが含まれます。

- FindAttribute (オプション)は、フィルタ基準が満たされた場合に取得する属性のサブセットを指定します。何も満たされない場合は、すべての属性がフェッチされます。

- ExcludeAttribute (オプション)は、Trueに設定される場合のブール・フラッグで、FindAttributeで指定される属性は返されません。

子オブジェクトの属性が条件的に評価される必要があるまたはペイロードで返される場合(あるいはその両方)、childFindCriteria構造は、FindCriteria構造内に追加されます。childFindCriteriaの要素は、FindCriteria構造で使用されるものと同様で、加えて、childAttrNameは、フィルタ基準に適用する子オブジェクトを指定します。単一の子オブジェクトのブロック・ダイアグラムを次に示します。

図15-24 子検索基準のFindCriteria包含階層

15.5.1 SOAPリクエストを使用した検索メソッド動作の制御方法

SDOの検索リクエスト・ペイロードを作成するには、検索メソッド・フィルタ・モデルの包含階層を理解する必要があります。ペイロード作成ブロックは、検索メソッドXSDで定義された要素から導出されます。包含階層の詳細は、「コンシューミング・アプリケーションでの検索メソッド・フィルタ・モデルの使用」を参照してください。

FindCriteriaのSOAPリクエストを定義するには、次の手順を実行します。

1. 結果セットの行数および開始する行を指定します(必須)。

2. 親オブジェクトのフィルタ条件を定義し、1つ以上のビュー基準アイテムを指定します(必須)。

3. 必要に応じ、結果のソート順序を指定します(オプション)。デフォルトは降順です。

4. フィルタ条件が満たされた場合に取得する1つ以上の属性を指定します(オプション)。

5. 存在する場合、子オブジェクトのフィルタ条件を指定します(オプション)。図15-25を参照してください。

次のリクエストは、親オブジェクトでのこの説明に一致する結果セットを返します。
Country属性値が、USまたはIEである場所を、50まで検索します。Country、State、ProvinceおよびCity属性のみを返します。結果セットを降順のCountryでソートします。翻訳された値で返さないようにします。

図15-25 親オブジェクトの検索リクエスト

次のリクエストは、この説明に一致するフィルタ済子オブジェクトに対する結果セットを返します。

結果セットの各行(資格を満たすオブジェクト・インスタンス)に対し、EffectiveStartDateが設定されている場合または日付が指定された後に、FloorNumber、Building、City、State、Province、CountryおよびEffectiveStartDate属性を含むLocationProfileを含めます。

図15-26 親および子オブジェクトの検索リクエスト

15.5.2 Javaクライアントを使用した検索メソッド動作の制御方法

標準検索メソッドAPIは、問合せ動作を制御します。APIを使用するには、検索メソッド・フィルタ・モデルの包含階層を理解する必要があります。包含階層の詳細は、「コンシューミング・アプリケーションでの検索メソッド・フィルタ・モデルの使用」を参照してください。

次のサンプルでは、FindCriteriaオブジェクトをプログラム的に作成する手順を示します。

1. 新しいFindCriteria (フィルタ)を作成します。

2. 新しいViewCriteriaItem (アイテム)を作成します。

3. 新しいViewCriteriaRow (グループ)を作成します。

4. 作成したアイテムおよびグループをFindCriteriaに追加します。

//1. Create FindCriteria
final FindCriteria findCriteria = (FindCriteria)DataFactory.INSTANCE.create(FindCriteria.class);
findCriteria.setFetchStart(0);
findCriteria.setFetchSize(-1);
findCriteria.setExcludeAttribute(false);

//2. Create ViewCriteriaItem
final ViewCriteriaItem viewCriteriaItem = (ViewCriteriaItem)DataFactory.INSTANCE.create(ViewCriteriaItem.class);
viewCriteriaItem.setConjunction("AND"); //Can also be OR
viewCriteriaItem.setUpperCaseCompare(true);
viewCriteriaItem.setAttribute("EmpName");
viewCriteriaItem.setOperator("LIKE"); //LIKE used for WILDCARD comparison
final List<Object> item_values = new ArrayList<Object>(5);
item_values.add(viewCriteriaItem);
viewCriteriaItem.setValue(item_values);

//3. Create ViewCriteriaRow.
//4. Further add ViewCriteriaItem into ViewCriteriaRow and ViewCriteriaRow into FindCriteria.
final ViewCriteriaRow viewCriteriaRow = (ViewCriteriaRow)DataFactory.INSTANCE.create(ViewCriteriaRow.class);
viewCriteriaRow.setConjunction("AND");
viewCriteriaRow.setUpperCaseCompare(true);
final List<Object> item = new ArrayList<Object>(5);
item.add(viewCriteriaItem);
viewCriteriaRow.setItem(item);
findCriteria.getFilter().getGroup().add(viewCriteriaRow);

部分属性リストのリストを使用して問合せをする場合

デフォルトで、検索操作は、すべての詳細を含むすべての属性を返します。一部の属性のみを必要とする場合、検索メソッドのFindCriteriaパラメータに部分属性を設定する必要があります。次の場合に、これを実行します。

- SDOがLOBを含む場合で、これは取得および転送するのに非常に費用がかかります。

- SDOが翻訳など不要な詳細を含む場合。詳細の問合せもまた費用がかかります。

注意: 標準getXXX関数は、FindCriteriaを使用しないため、この関数は常にすべてを返します。返される属性を絞り込むには、findXXXを使用します。

次の例では、部分属性を設定して、DeptからDname、Locのみを含め、EmpからEmpnoを除外する方法を示します。

FindCriteria fc = (FindCriteria)datafactory.create(FindCriteria.class);
List l = new ArrayList();
l.add("Dname");
l.add("Loc");
l.add("Emp");
fc.setFindAttribute(l);
List cfcl = new ArrayList();
ChildFindCriteria cfc = (ChildFindCriteria)datafactory.create(ChildFindCriteria.class);
cfc.setChildAttrName("Emp");
List cl = new ArrayList();
cl.add("Empno");
cfc.setFindAttribute(cl);
cfc.setExcludeAttribute(true);
cfcl.add(cfc);
fc.setChildFindCriteria(cfcl);
DeptResult res = svc.findDept(fc, null);

次の例では、部分属性を設定して、PurchaseOrderからPurchaseOrderLineを除外する方法を示します。

FindCriteria fc = (FindCriteria)datafactory.create(FindCriteria.class);
List l = new ArrayList();
fc.setExcludeAttribute(true);
l.add("PurchaseOrderLine");
fc.setFindAttribute(l);
PchaseOrderResult res = svc.findPurchaseOrder(fc, null);

ビュー基準を使用して結果をフィルタ処理する場合

検索APIにより、WHERE句を問合せに指定できます。WHERE句は、SDOの任意のレベルで設定できます。

次の例では、10より数が大きい部門番号で、名前が"A"で始まる子従業員のみを取得する方法を示します。

FindCriteria fc = (FindCriteria)datafactory.create(FindCriteria.class);
//create the view criteria item
List value = new ArrayList();
value.add(new Integer(10));
ViewCriteriaItem vci = (ViewCriteriaItem)datafactory.create(ViewCriteriaItem.class);
vci.setValue(value);
vci.setAttribute("Deptno");
List<ViewCriteriaItem> items = new ArrayList(1);
items.add(vci);
//create view criteria row
ViewCriteriaRow vcr = (ViewCriteriaRow) datafactory.create(ViewCriteriaRow.class);
vcr.setItem(items);
//create the view criteria
List group = new ArrayList();
group.add(vcr);
ViewCriteria vc = (ViewCriteria)datafactory.create(ViewCriteria.class);
vc.setGroup(group);
//set filter
fc.setFilter(vc);

List cfcl = new ArrayList();
//create the child find criteria
ChildFindCriteria cfc = (ChildFindCriteria)datafactory.create(ChildFindCriteria.class);
cfc.setChildAttrName("Emp");
//create the child view criteira
ViewCriteria cvc = (ViewCriteria)datafactory.create(ViewCriteria.class);
cfc.setFilter(cvc);
//create the view criteria item
List cvalue = new ArrayList();
cvalue.add("A%");
ViewCriteriaItem cvci = (ViewCriteriaItem)datafactory.create(ViewCriteriaItem.class);
cvci.setValue(value);
cvci.setAttribute("Dname");
cvci.setOperator("LIKE");
List<ViewCriteriaItem> citems = new ArrayList(1);
citems.add(cvci);
//create child view criteria row
ViewCriteriaRow cvcr = (ViewCriteriaRow) datafactory.create(ViewCriteriaRow.class);
cvcr.setItem(citems);
List cgroup = new ArrayList();
cgroup.add(cvcr);
cvc.setGroup(cgroup);

DeptResult dres = svc.findDept(fc, null);

特定の基準を満たす親と子を問い合せることもできます。たとえば、次の例では、給与が$10,000を超える従業員がいる部門を取得します。

//create the view criteria item on the employees
List nvalue = new ArrayList();
nvalue.add(new BigDecimal(10000));
ViewCriteriaItem nvci = (ViewCriteriaItem)datafactory.create(ViewCriteriaItem.class);
nvci.setValue(nvalue);
nvci.setAttribute("Salary");
nvci.setOperation(">");
List<ViewCriteriaItem> nitems = new ArrayList(1);
nitems.add(nvci);
//create view criteria row
ViewCriteriaRow nvcr = (ViewCriteriaRow) datafactory.create(ViewCriteriaRow.class);
nvcr.setItem(nitems);
//create the nested view criteria
List ngroup = new ArrayList();
ngroup.add(nvcr);
ViewCriteria nvc = (ViewCriteria)datafactory.create(ViewCriteria.class);
nvc.setGroup(ngroup);

//create the view criteria item on the department
ViewCriteriaItem vci = (ViewCriteriaItem)datafactory.create(ViewCriteriaItem.class);
vci.setAttribute("Emp");
vci.setNested(nvc);
List<ViewCriteriaItem> items = new ArrayList(1);
items.add(vci);
//create view criteria row
ViewCriteriaRow vcr = (ViewCriteriaRow) datafactory.create(ViewCriteriaRow.class);
vcr.setItem(items);
//create view criteria on department
ViewCriteria vc = (ViewCriteria)datafactory.create(ViewCriteria.class);
List group = new ArrayList();
group.add(vcr);
vc.setGroup(group);
//set filter
FindCriteria fc = (FindCriteria)datafactory.create(FindCriteria.class);
fc.setFilter(vc);

DeptResult dres = svc.findDept(fc, null);

結果をページングする場合

問合せで返されるデータが大量であることを事前に知っている場合、複数のサービスを起動し、setFetchStartおよびsetFetchSizeを使用して取得するデータの量を制御する必要があります。

次の例では、2番目の従業員および従業員の部門のみを取得する方法を示します。

FindCriteria fc = (FindCriteria)datafactory.create(FindCriteria.class);
List cfcl = new ArrayList();
ChildFindCriteria cfc = (ChildFindCriteria)datafactory.create(ChildFindCriteria.class);
cfc.setChildAttrName("Emp");
cfc.setFetchStart(1);
cfc.setFetchSize(1);
cfcl.add(cfc);
fc.setChildFindCriteria(cfcl);
DeptResult dres = svc.findDept(fc, null);

16 アプリケーション・モジュールによるRESTful Webサービスの作成

この章では、ADFアプリケーション・モジュールのビュー・オブジェクト・インスタンスに基づいてADF RESTリソースを作成し、Fusion WebアプリケーションでこれらのリソースをRESTful Webサービスとして使用できるようにする方法を説明します。

この章の内容は次のとおりです。

- RESTful WebサービスおよびADFビジネス・コンポーネントについて

- アプリケーション・モジュールを使用したADF RESTリソースの作成

- ADF RESTリソース表現およびメソッドのカスタマイズ

- ADF RESTリソースのバージョニング

- ADF RESTリソースへのクライアント・アクセスの付与

- ADF RESTリソースのデプロイ

- 統合WebLogic Serverを使用したADF RESTリソースのテスト

16.1 RESTful WebサービスおよびADFビジネス・コンポーネントについて

REpresentational State Transfer (REST)は、WebサービスがそれらのURLによって識別されるリソースとして表示されるステートレス・クライアント/サーバー・アーキテクチャをサポートします。GETやPOSTなどのHTTPリクエスト・メソッドは、HTTP URLによって表現されるリソースに対して実行する必要がある、作成、読取り、更新および削除(CRUD)アクションを記述するために、Webサービス・クライアント・リクエスト・メッセージで開発者が使用できる動詞です。RESTでは、HTTP、URL、URI、XML、HTMLなどの規格の使用やリソース・タイプおよびMIMEタイプを規定しています。そのため、RESTは規格ではなく、Webサービスのアーキテクチャ・スタイルの提案となります。

RESTの設計制約に準拠するWebサービスはRESTfulと呼ばれます。このタイプのWebサービスでは、HTTPクライアントとHTTPサーバーがURLによって識別されるリソース情報を交換できます。リクエストおよびレスポンスには、特定の形式でリソースの表現が含まれ、これにより、実際のリソースの状態が定義されます。

Fusion Webアプリケーションにおいては、RESTful Webサービスによって操作されるADF RESTリソースは、ADFビジネス・コンポーネント・モデル・プロジェクトのデータ・モデルで公開されるビュー・オブジェクト・インスタンスが基礎となっています。ADFモデル・プロジェクトで作業するADFビジネス・コンポーネント開発者は、基礎となるビュー・オブジェクトから公開する属性のセット、使用可能にするアクション(標準CRUD操作、およびビュー・オブジェクト・インタフェースまたはビュー行インタフェースのいずれかで定義されているカスタム・メソッドの両方)、および結果として生成されたリソースを保存するビュー・リンク関係を決定できます。

注意:

ADF RESTリソースとして公開する目的でビュー・オブジェクトを作成する場合、ビュー・オブジェクトの作成・ウィザードで「問合せ」ページのDeclarativeオプションを使用して、宣言SQLモード・オプションが有効なビュー・オブジェクトを作成します。設計時に宣言SQLモードで作成されたビュー・オブジェクトは、ADF RESTフレームワーク実行時最適化をサポートし、リソース・コレクションは、URL問合せパラメータfieldsで作成されたクライアント・リクエストを使用して効果的にフィルタ処理されます。

ADFビジネス・コンポーネント開発者による設計時の選択内容は、RESTリソース定義XMLファイルで取得されます。Webサービス・クライアントの開発者は、ADF RESTランタイムで有効化されているREST APIによってこれらのリソース定義と対話できます。これにより、使用するサービス・クライアントはCRUD操作を起動して、RESTリソースおよびADFビジネス・オブジェクトと対話できます。データは、親子関係はそのままで、リソースの基礎となるビュー・オブジェクト・インスタンスによって形成されます。

ADFビジネス・コンポーネント・プロジェクトでの最初のRESTリソースを作成するとき、JDeveloperによって、ADF RESTサーブレットを登録する個別のRESTful Webサービス・プロジェクトも生成されます。図16-1に、JDeveloperによって生成されるweb.xmlファイルを示します。このプロジェクトを使用してRESTful Webサービスを実行およびデプロイします。

図16-1 RESTful Webサービス・プロジェクトを表示する「アプリケーション」ウィンドウ

ADF RESTリソースのセキュリティは、Fusion Webアプリケーションを保護する方法に類似したRESTful Webサービスで適用されます。JDeveloperで、ADFセキュリティの構成ウィザードを実行して、ADFモデル・プロジェクトにセキュリティを適用します。ウィザードを実行した後、デプロイされたRESTful WebサービスのRESTリソースはデフォルトで保護されているため、このサービスの操作に対してアクセス権を付与することが必要になります。

JDeveloperでセキュリティをテストするには、テスト・ユーザーを作成してこれらのユーザーにリソースへのアクセス権限を付与します。次に、これらのアクセス権を付与するセキュリティ・ポリシーをアプリケーション・レベルからドメイン・レベルのセキュリティ・ポリシー・ストアに移行します。セキュリティ・ポリシー・ストアで、エンタープライズ・ユーザーにアクセス権がプロビジョニングされます。

16.1.1 RESTful Webサービスのユースケースと例

開発チームはADF RESTリソースを公開し、Fusion Webアプリケーションに提供できます。

クライアントとサーバーによるリソース情報の交換をサポートするADF RESTフレームワークの固有のランタイム機能には、次のものがあります。

- RESTリソースとの対話は、リソース、アクション実行、およびアクション実行の結果に対して、個別のJSONベース・メディア・タイプ構造によってサポートされています。

- GET、POST、PATCH、DELETEなどの標準HTTPリクエスト・メソッドを使用してRESTリクエストと対話します。

- クライアントでの制限によりRESTリソースとの対話に標準HTTPメソッドを使用できない場合は、POSTリクエスト・メソッドを使用するX-HTTP-Method-Overrideヘッダーを使用してHTTPメソッドを実行します。

- RESTリソース・アイテム(特定の従業員など)やRESTリソース・コレクション(すべての従業員のコレクションなど)の特定は、ADFビジネス・コンポーネント・モデル・プロジェクトで定義されているリソース名に基づくREST準拠のURIパス名によってサポートされます。

- RESTリソース(リソース属性および使用可能なアクションなど)の説明の取得は、特定のメディア・タイプとdescribeアクションによってサポートされます。

- 正規RESTリソースへのリンクは、更新可能エンティティのスーパーセットを持つリソースが定義されている場合にサポートされます。正規のリンクでは、基礎となるビュー・オブジェクトの代替リンクがサポートされます。

- RESTリソースのフィルタ処理は、クライアントが特定のリソースにアクセスするために指定されたURIの問合せ文字列パラメータによりサポートされています。

- 圧縮および解凍を有効化するために、エンコーディング形式がRESTリソースでサポートされています。

- RESTリソースにより公開されるBLOB属性とCLOB属性のコンテンツのストリーミングは、ADF RESTフレームワークでサポートされています。

- RESTful Webサービス起動時のデータ整合性チェックの実行は、ADF RESTフレームワークでサポートされています。この機能では、データベースのバージョン履歴を使用して、クライアントがリソース自体の更新に応じてHTTPペイロードを管理できるようにします。

- ユーザーに対するRESTリソースへのアクセスの認可は、ADFセキュリティ権限の付与によって有効化されます。

16.1.2 RESTful Webサービスの追加機能

RESTful Webサービスを使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。次に、関連するサポート機能へのリンクを示します。

- 推奨される宣言SQLモードでビュー・オブジェクトを作成し、実行時に効果的にリソース・コレクションのフィルタ処理をサポートする方法の詳細は、「宣言SQLモードでのビュー・オブジェクトの使用」を参照してください。

- サービス・クライアントでデータの一貫性チェックがサポートされるようにする場合に、エンティティ・オブジェクトに対して更新識別子属性を有効にする方法の詳細は、「同時更新によるデータの消失を防ぐ方法」を参照してください。

- ADF RESTリソースのファインダを公開する場合に、ビュー・オブジェクトで行検索を作成する方法の詳細は、「行検索の使用」を参照してください。

- ADF RESTリソースのLOVリンクを公開する場合に、LOVの有効なビュー・オブジェクト属性を作成する方法の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

- ADF RESTリソースのカスタム・メソッドを公開する場合に、ビュー・オブジェクトのクライアント・インタフェースでカスタム・メソッドを作成する方法の詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

- ADF RESTリソースのサブタイプ・ビューのビュー行を公開する多相ビュー・オブジェクトの作成の詳細は、「多相ビュー行関連の作業」を参照してください。

- REST APIを使用したADF RESTリソースへの実行時アクセスを有効にするADF RESTフレームワークの詳細は、「ADF RESTフレームワークを使用したRESTful Webサービスの使用方法」を参照してください。

- ADF RESTデータ・コントロールを使用したユーザー・インタフェースの設計の詳細は、「ADF RESTデータ・コントロールを使用したRESTful Webサービスの使用方法」を参照してください。

16.2 アプリケーション・モジュールを使用したADF RESTリソースの作成

アプリケーション・モジュールは、ビュー・オブジェクト・インスタンスおよびカスタム・メソッドとして公開される、一連の関連するビジネス機能としてビジネス・ロジックをカプセル化する、ADFビジネス・コンポーネント・フレームワーク・コンポーネントです。アプリケーション・モジュールのデータ・モデルに出現する1つ以上のビュー・オブジェクト・インスタンスをADF RESTリソースにマップできます。アプリケーション・モジュールの概要エディタを使用して、ADF RESTリソースを作成します。ADFモデル・プロジェクトに追加するRESTリソースは、RESTアーキテクチャ・スタイルに従うWebサービスとして公開される場合があります。

注意:

ADF RESTリソースとして公開する目的でビュー・オブジェクトを作成する場合、ビュー・オブジェクトの作成・ウィザードで「問合せ」ページのDeclarativeオプションを使用して、宣言SQLモード・オプションが有効なビュー・オブジェクトを作成します。設計時に宣言SQLモードで作成されたビュー・オブジェクトは、ADF RESTフレームワーク実行時最適化をサポートし、リソース・コレクションは、URL問合せパラメータfieldsで作成されたクライアント・リクエストを使用して効果的にフィルタ処理されます。

16.2.1 ビュー・オブジェクト・インスタンスからのADF RESTリソースの作成方法

ビュー・オブジェクト・インスタンスは、Fusion Webアプリケーションで操作するビジネス・オブジェクトです。ADFアプリケーション・モジュールは、それが定義するデータ・モデルでこれらのビジネス・オブジェクトを公開して、サービス・クライアントが表示および操作できるデータを指定します。ADF RESTリソースは、アプリケーション・モジュールの概要エディタを使用して、ビュー・オブジェクト・インスタンスに対して直接定義します。

ADF RESTリソースの追加は、アプリケーション・モジュールの概要エディタの「Webサービス」ページに表示されるオプションです。図16-2に、AppModuleアプリケーション・モジュールのビュー・オブジェクト・インスタンスに作成されているRESTリソースがエディタでどのように表示されるかを示します。エディタでは、アプリケーション・モジュールのRESTリソースは割り当てられたリリース固有のバージョン名(この例では、11.0、11.1および11.2)ごとに編成されていることに注意してください。

図16-2 アプリケーション・モジュールに定義されているADF RESTリソース

注意:

ADF RESTリソースを作成する場合は、JDeveloperによってリソースのバージョン・リリース名を指定するように求められます。バージョンは、複数のリリース間でADFモデル・プロジェクトに追加するリソースの現在および後続のバージョンの管理に役立つ英数字識別子です。

ビュー・オブジェクト・インスタンスを選択し、RESTリソースに名前を付けてバージョンを選択すると、RESTリソースの概要エディタでリソースが開きます。概要エディタを使用して、ビュー・オブジェクト・アクセッサ、使用可能な操作およびカスタム・メソッドをRESTful Webサービスのペイロード・オブジェクトおよびアクションとして公開することによって、RESTリソース表現を編集します。JDeveloperでは、RESTリソース定義ファイルは、割り当てられたリリース・バージョン名によって編成された、ADFアプリケーション・モジュールのサブパッケージとして保存されます。

RESTリソースのカスタマイズの詳細は、「ADF RESTリソース定義の編集方法」を参照してください。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、Webサービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成方法」の説明に従い、RESTリソースで公開するビュー・オブジェクト・インスタンスを含むアプリケーション・モジュールのデータ・モデルを作成します。

- adf-config.xmlファイルでリリース・バージョン識別子を作成し、作成するADF RESTリソースを特定のバージョンに関連付けます。「ADF RESTリソースのバージョニング」の説明に従い、ADFモデル・プロジェクトに追加するADF RESTリソースの現在および後続のバージョンの管理に役立つように、各RESTリソースをリリース・バージョンに関連付ける必要があります。

ADF RESTリソースを作成する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、ADF RESTリソースを作成するビュー・インスタンスを含むアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「Webサービス」ナビゲーション・タブをクリックして「REST」タブをクリックし、「RESTサービスのサポートの有効化」追加アイコンをクリックします。
最初のRESTリソースを作成するとき、JDeveloperによって、ADF RESTサーブレットを登録する個別のRESTful Webサービス・プロジェクトも生成されます。

3. 「RESTリソースの作成」ダイアログで、RESTful Webサービスで公開するルート・ビュー・インスタンスを選択します。
ダイアログに、アプリケーション・モジュールのデータ・モデルで定義されたビュー・インスタンスが表示されます。マスター/ディテール階層のルート・ビュー・インスタンスのみ選択できます。

4. RESTリソース・コレクションの「リソース名」を入力し、ドロップダウン・リストからリリース・バージョンを選択して「OK」をクリックします。
リソース名は、サービス・クライアントがビュー・インスタンスとの対話に使用する識別子です。たとえば、次の図に示すように、DeptView1ビュー・インスタンスに基づくコレクションに名前を付ける場合、完全なコレクション名を示すために名前にDepartmentsを入力できます。ネーミングの詳細は、「ADF RESTリソースのネーミングに関する必知事項」を参照してください。

リリース・バージョンは、JDeveloperでリソースの作成を管理するためにadf-config.xmlファイル内に作成する必要がある識別子です。「ADF RESTリソースのバージョニング」で説明するように、バージョンは、サービス・クライアントが特定のRESTリソースの操作を起動するために使用するURLの一部となります。

図16-3 ADF RESTリソースのリリース・バージョンへの割当て

5. RESTリソースの概要エディタで、次のいずれかのタスクを実行することによって、リソースとその構造の編集に進むことができます。

a. ビュー・リンク・アクセッサで定義された子リソースを追加および削除します。詳細は、「ADF RESTリソース定義の編集方法」を参照してください。

b. 同じ基礎となるビュー・インスタンスで定義されたリソースを追加および削除します。詳細は、「同じビュー・インスタンスに基づくリソースを追加および削除する方法」を参照してください。

c. 属性を追加および削除します。詳細は、「ADF RESTリソースの属性を非表示にしたり公開したりする方法」を参照してください。

d. HTTPメソッド、正規のリンク、行検索フィルタ、サブタイプ・ビューの慣用名およびカスタム・メソッドで定義された標準操作へのアクセスを変更します。詳細は、「ADF RESTリソース表現およびメソッドのカスタマイズ」を参照してください。

6. 「ファイル」、「すべて保存」の順にクリックして、このリソースの選択を保存します。
「ADFビジネス・コンポーネント・プロジェクトのRESTリソースを作成する場合の処理」で説明するように、JDeveloperでは、概要エディタで行われるRESTリソース選択をリソースのリソース定義ファイルに保存します。

16.2.2 ADFビジネス・コンポーネント・プロジェクトのRESTリソースを作成する場合の処理

JDeveloperによってRESTリソースが生成され、図16-4に示すように、モデル・プロジェクトで編成された「アプリケーション」ウィンドウで、これらのリソースがバージョン・リリース名ごとに表示されます。

また、JDeveloperによって、ADF RESTサーブレットを登録する個別のRESTful Webサービス・プロジェクト(RESTWebService)も生成されます。図16-4に、JDeveloperによって生成されるweb.xmlファイルを示します。このプロジェクトを使用してRESTful Webサービスを実行およびデプロイします。

モデル・プロジェクトに含まれているResourceRegistry.rpxファイルでは、RESTful Webサービスとして公開されるRESTリソースのリストを指定するために、メタデータ注釈を使用しています。

adf-config.xmlファイルは、バージョン・リリース名を作成すると更新されます。このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードの下に表示されます。ADFビジネス・コンポーネントを初めて作成すると、同じフォルダにconnections.xmlファイルが作成されます。

図16-4 アプリケーション・モジュール・ノードの下に表示されるRESTリソース

16.2.3 ADF RESTリソース定義の編集方法

ADFモデル・プロジェクトにADF RESTリソース定義を追加すると、アプリケーション・モジュールの概要エディタのRESTセクションに、作成したリソースの名前が表示されます。リスト内のリソース名をクリックすることによって、個別のエディタでRESTリソース定義を開くことができます(図16-2を参照)。

RESTリソースの概要エディタに、リソースの構造を編集するためのオプションが表示されます。RESTful Webサービスの観点から、RESTリソース構造によって実行時にRESTコールによって起動される使用可能なデータが決定されます。

設計時に、リソースの基礎となるビュー・オブジェクト階層から、公開する必要があるリソースのみを選択するようにRESTリソース定義を編集できます。RESTリソースを初めて作成するときには、アプリケーション・モジュールのデータ・モデルによって公開される、リソースの基礎となるビュー・オブジェクトを選択する必要があります。この元のビュー・オブジェクトの選択によりRESTリソースのルート・リソースが定義されます。オプションで、追加の子ビュー・オブジェクトを公開できます(存在する場合)。

たとえば、図16-5に示すRESTリソース・エディタの左側には、リソースDepartmentsのデフォルトの構造が表示されています。リソース構造はルート・リソースを表すルート・ノードを持つツリーとして表示されます(この場合はDepartmentsView1)。ツリーのリーフ・ノードは子リソースを表します。この例では、Departmentsリソースは、ルート・リソースDepartmentsView1および様々な子リソース(EmployeesおよびJobHistoryなど)で構成されています。DepartmentsView1、EmployeesおよびJobHistoryのリソースはデータ・モデルのビュー・インスタンスとして関連付けられているため、階層に表示されます。リーフ・ノードの横のチェックボックスを使用して、リソース構造に対して子リソースを追加および削除できます。

図16-5 リソース構造が表示されている概要エディタ

注意:

RESTリソース・エディタの右側に、「構造」ツリーで行うノード選択に対応する使用可能なオプションが表示されます。

表16-1に、リソース構造ツリーのノードの概要を示します。

表16-1 リソース構造ツリーのノード

ノード

説明

編集オプション

ルート・リソース・ノード:

ルート・リソースの選択の基礎となるビュー・オブジェクト・インスタンスを表します。

ルート・リソースの基礎となるビュー・オブジェクト・インスタンスを変更または削除することはできません。

このノードを選択すると、ルート・リソースでオプションを選択できます。これらのオプションの詳細は、「ADF RESTリソース表現およびメソッドのカスタマイズ」を参照してください。

子リソース・ノード:

ルート・リソースの選択の基礎となるビュー・オブジェクト・インスタンスに対して定義されている、マスター/ディテール関係を定義するためにデータ・モデルで使用されているビュー・リンク・アクセッサを表します。

注意: 子ノードは、ルート・リソースのビュー・オブジェクト・インスタンスがマスター/ディテール関係に含まれていない場合は表示されません。

子リソースはデフォルトでは無効です。リソース表現で子リソースを公開するには、チェックボックスを選択します。リソース表現から子リソースを削除するには、チェックボックスの選択を解除します。

子リソース・ノードを選択すると、子リソースでオプションを選択できます。これらのオプションの詳細は、「ADF RESTリソース表現およびメソッドのカスタマイズ」を参照してください。

始める前に:

ADF RESTによって、アプリケーション・モジュールがどのようにサポートされ、Webサービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

ADF RESTリソース構造を編集する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. 概要エディタで、必要な選択を行います。

[F1]キーを押すと、概要エディタのJDeveloperヘルプ・センター・トピックが表示されます。

3. 「ファイル」、「すべて保存」の順に選択して、このリソースでの変更を保存します。

「ADFビジネス・コンポーネント・プロジェクトのRESTリソースを作成する場合の処理」で説明するように、JDeveloperでは、リソースのリソース定義ファイルに変更が保存されます。

16.2.4 ADF RESTリソースでの子リソースの公開方法

アプリケーション・モジュールのデータ・モデルで1つ以上の階層のマスター/ディテール関係を指定する場合は、ADF RESTリソースで子リソースを公開できます。データ・モデルの各マスター/ディテール関係に対して、ADFビジネス・コンポーネント・モデル・プロジェクトでは、関連する親と子のビュー・オブジェクトを指定するビュー・リンク・アクセッサを定義する必要があり、これにより、親、つまりマスター・ビュー・オブジェクト・インスタンス内に、子、つまりディテール・ビュー・オブジェクト・インスタンスをネストします。

実行時に、ネストされたビュー・インスタンスを公開するRESTリソースでは、1回のラウンドトリップで、マスターおよびディテールのコレクションを戻すことをサポートします。このため、マスター/ディテール・データの操作が必要なサービス・クライアントについては、設計時に子リソースを公開することが役立ちます。

JDeveloperのRESTリソースの概要エディタでは、マスター/ディテール関係が、ルート・リソースのリーフ・ノードとして子リソースが表示される、リソース構造ツリーとして表示されます。たとえば、図16-6は、概要エディタでの、次のネストされたリソース構造を持つDepartmentsリソースを示しています。

- DepartmentsView1は、マスター・ビュー・インスタンスとして、ルート・リソースの基礎となります。

- EmployeesはDepartmentsView1の下にネストされたディテール・ビュー・インスタンスであり、ツリー・ノードのチェックボックスが選択され、Departmentsリソースで子リソースが公開されていることを示します。

- JobHistoryは、EmployeesViewの下にネストされた別のディテール・ビュー・インスタンスであり、ツリー・ノードのチェックボックスが選択され、Departmentsリソースで子リソースが公開されていることを示します。

デフォルトでは、選択された基礎となるビュー・インスタンスに基づき、JDeveloperによってRESTリソースが作成されますが、子リソースは含められません。リソース構造ツリーで、デフォルトでは、子リソースは選択されていない状態で表示され、これらのリソースが公開されていないことを示します。このチェックボックスを選択または選択解除することによって、子リソースを公開したり非表示にしたりすることができます。

図16-6 概要エディタで有効な子リソース

注意:

子リソースはデフォルトでは公開されないため、リソースでこれらを公開するには、概要エディタで選択する必要があります。

始める前に:

ADF RESTがアプリケーション・モジュールをどのようにサポートし、サービス・クライアントのデータ行アクセスやサービス操作の実行をどのように有効化するかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

ネストされたリソースを公開する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「構造」ツリーを展開し、ルート・リソースの子リソースのチェックボックスを選択します。

「構造」ツリーで、デフォルトでは、子リソース・ノードは選択されていない状態で表示され、ネストされたリソースがリソース内で公開されていないことを示します。

データ・モデルで、ルート・リソースの基礎となるビュー・インスタンスに対してマスター/ディテール階層が定義されていない場合は、「構造」ツリーに子リソース・ノードは表示されません。「構造」ノードの詳細は、表16-1を参照してください。

3. 「構造」ツリーで別の子リソースのチェックボックスを選択すると、そのリソースで、そのネストされたリソースが有効になります。

16.2.5 同じビュー・インスタンスに基づくリソースを追加および削除する方法

JDeveloperで、RESTリソースの概要エディタを使用して、同じビュー・インスタンスに対して複数のリソースを定義できます。1つのリソース定義がサービス・クライアントのすべてのユースケースをサポートしていない場合は、リソースを追加できます。リソースを追加した後で、目的のユースケースをサポートするために、操作、属性のリストおよびリソース構造の他のアイテムを変更できます。定義する各リソースは、サービス・クライアントに対して一意のリソース・コレクションを表すため、リソース名がその違いを反映している必要があります。

RESTリソースの概要エディタでは、「リソース」ドロップダウンに、追加するリソースのリストが表示されます。たとえば、図16-7では、同じ基礎となるビュー・オブジェクトEmployeesViewについて、概要エディタに、EmployeesリソースおよびEmployeesAllAttrsリソースが表示されています。

図16-7 RESTリソース定義で複数のリソースをサポートするリソース・リスト

注意:

JDeveloperでは、RESTリソースの概要エディタで追加されているリソース定義を削除できます。ただし、空の定義ファイルが「アプリケーション」ウィンドウに表示されます。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、リソースを追加または削除するRESTリソースを作成します。

概要エディタでリソースを追加および削除する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、リソースを追加または削除するADF RESTリソースが定義されているリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「リソース」ドロップダウンからリソースを選択し、「リソースの削除」をクリックして、ビュー・オブジェクトに対してすでに定義されているリソースを削除します。
「リソースの削除」を使用してルート・リソース定義を削除するとリソースは削除されますが、空の定義ファイルが「アプリケーション」ウィンドウに表示されます。

3. RESTリソースの概要エディタで、ビュー・オブジェクトに対して作成するリソースを追加するには、「リソースの追加」をクリックします。

4. 「ビュー・オブジェクト」ダイアログの「リソースの追加」で、選択したルート・ビュー・インスタンスに対して追加するRESTリソース・コレクションの「リソース名」を入力し、「OK」をクリックします。

5. RESTリソースの概要エディタで、「リソース」ドロップダウンから新規リソースを選択し、そのリソース定義を編集します。

a. ビュー・リンク・アクセッサで定義された子リソースを追加および削除します。詳細は、「ADF RESTリソース定義の編集方法」を参照してください。

b. 属性を追加および削除します。詳細は、「ADF RESTリソースの属性を非表示にしたり公開したりする方法」を参照してください。

c. HTTPメソッド、正規のリンク、行検索フィルタ、サブタイプ・ビューの慣用名およびカスタム・メソッドで定義された標準操作へのアクセスを変更します。詳細は、「ADF RESTリソース表現およびメソッドのカスタマイズ」を参照してください。

16.2.6 ADF RESTリソースの名前を変更する方法

ADF RESTリソースの開発中、RESTリソースの概要エディタを使用して、リソース定義ファイルでリソースの名前を変更できます。サービス・クライアントでは、必要なRESTリソース・コレクションとの対話にリソース名を使用するため、サービスを本番環境にデプロイする前に、ADF RESTリソースの名前を確定することが重要です。

デプロイ後にADF RESTリソースの名前を変更する必要がある場合は、「ADF RESTリソースのバージョニング方法」で説明するように、リソースの完全な新規バージョンを作成することで、このことを最適に処理できます。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、RESTリソースを作成します。

本番デプロイメントの前にリソースの名前を変更する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、名前を変更するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「リソース」ドロップダウンから対象のリソースを選択します。

リソース定義ファイルで追加のリソースを作成していない場合は、基礎となるビュー・オブジェクトに対して作成された元のリソースがリストに表示されます。

3. 概要エディタの「表現」タブをクリックし、「リソース名」フィールドに新しい名前を入力します。

16.2.7 ADF RESTリソースのネーミングに関する必知事項

RESTリソース名は、サービス・クライアントが、公開されているリソース・コレクションを識別して対話する手段です。通常、RESTリソース名で、利用するクライアントがアクセスするビュー・オブジェクトを識別します。そのため、RESTリソース名は動詞ではなく名詞です。

16.2.8 ADF RESTリソースの属性を非表示にしたり公開したりする方法

JDeveloperで、RESTリソースの概要エディタを使用して、同じビュー・インスタンスに対して複数のリソースを定義できます。1つのリソース定義がサービス・クライアントのすべてのユースケースをサポートしていない場合は、リソースを追加できます。リソースを追加した後で、目的のユースケースをサポートするために、必要に応じて、公開されている属性のリストおよびリソース構造の他のアイテムを変更できます。

RESTリソースの概要エディタでは、「属性」タブに、公開されている属性のリストが表示されます。リストは、ルート・リソースの基礎となるビュー・オブジェクトで定義した、RESTサービス形状の選択によって移入されます。たとえば、図16-8は、EmployeesViewビュー・オブジェクトに対して2つの属性以外をすべて公開するサービス形状定義EmployeesView_ForHRを示しています。

図16-8 RESTサービス形状定義の選択によって公開される属性

注意:

公開されている属性のリストはRESTリソースの概要エディタで直接変更しません。かわりに、基礎となるビュー・オブジェクトでサービス形状定義を作成し、対象の「REST形状」定義を現在の「リソース」ドロップダウン選択に適用する必要があります。

サービス・クライアントのユースケースをサポートするには、各ビュー・オブジェクトに対して必要な数のサービス形状定義を定義できます。「アプリケーション」ウィンドウでは、ビュー・オブジェクト・ノードの下のpersdefフォルダに、そのビュー・オブジェクトに対して作成したサービス形状定義が表示されます。たとえば、図16-9では、EmployeesViewビュー・オブジェクトの下に2つのサービス形状定義ファイルEmployeesView_forHR.xmlおよびEmployeesView_ForBenefits.xmlが表示されています。

図16-9 「アプリケーション」ウィンドウでのRESTサービス形状定義ファイル

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、RESTリソースを作成します。

RESTサービス形状定義をRESTリソースに適用する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「ビュー・オブジェクト」リンクをクリックします。

3. ビュー・オブジェクトの概要エディタで、サービス形状ナビゲーション・タブをクリックします。

4. 「サービス形成」ページで、「サービス形成オブジェクトの作成」ボタンをクリックし、「サービス形状の作成」ダイアログで、サービス形状定義を一意に識別する接尾辞名を入力します。

入力する接尾辞はサービス形状定義ファイルの名前を形成します。たとえば、接尾辞ForHRはビュー・オブジェクトEmployeesViewに追加され、図16-10に示すようにサービス形状定義名EmployeesView_ForHRを形成します。

図16-10 使用可能な属性を定義するビュー・オブジェクトのサービス形状定義

5. 「サービス形成」ページで、シャトル・ボタンを使用して「非表示」および「選択されたもの」の属性のリストを変更し、ビュー・オブジェクト定義を保存します。

RESTリソースの概要エディタでサービス形状を変更すると、JDeveloperによりビュー・オブジェクトのサービス形状定義ファイルが更新されます。サービス形状を参照するADF RESTリソースのリソース構造も更新されます。

6. RESTリソースの概要エディタで、「リソース」ドロップダウンから対象のリソースを選択します。

7. 概要エディタの「属性」タブをクリックし、公開する属性のリストを定義する「サービス形成オブジェクト」を選択します。

16.2.9 ADF RESTリソース構造の変更に関する必知事項

図16-11に示すように、リソースを作成してバージョン識別子を割り当てると、RESTリソースの概要エディタの右上隅にバージョンが表示され、編集中のバージョンの識別に役立ちます。

図16-11 バージョンが表示されているRESTリソース・エディタ

開発サイクル中は、リソースをバージョニングする必要なく、ADF RESTリソースに変更を加えることができます。ただし、RESTful Webサービスをデプロイした後、ADF RESTリソースにアクセスするサービス・クライアントでそれらのユースケースが満たされることは、リソース・コレクションの安定性に依存します。

時間の経過に伴い、ユースケースが変化したり、RESTリソースの基礎となるビュー・オブジェクトが変化したりすることによって、すでにデプロイされているリソースのリソース構造を変更することが必要になる場合があります。このとき、既存のADF RESTリソースに対する変更に、デプロイされているRESTサービスとの後方互換性がない場合があり、新しいバージョン識別子およびそのバージョンのADF RESTリソースを作成することが必要になる場合があります。RESTリソースをバージョニングするタイミングの詳細は、「ADF RESTリソースのバージョニングに関する必知事項」を参照してください。

JDeveloperでは、ADF META-INFフォルダにあるadf-config.xmlファイルの概要エディタの「リリース・バージョン」ページでリソースのバージョンを管理できます。ADF RESTリソースの新規バージョンの作成方法の詳細は、「ADF RESTリソースのバージョニング」を参照してください。

16.2.10 ADF RESTリソースおよびLOB属性に関する必知事項

BLOBまたはCLOBタイプ属性を公開するリソースには、実行時にストリーミング・メディアとしてアクセスできます。デフォルトでは、ビュー・オブジェクト属性は、一般的なコンテンツ・タイプapplication/octet-streamを使用してADF RESTランタイムによって処理されます。特定のコンテンツ・タイプをサポートする場合は、LOBタイプ属性のカスタム・プロパティとして特別なプロパティcontentTypeを構成できます。たとえば、PNGイメージ・ファイルを使用する場合は、設計時に次のコンテンツ・タイプを構成できます。

- カスタム・プロパティ: contentType

- 値: image/png

図16-12に示すように、カスタム・プロパティcontentTypeは、ビュー・オブジェクトの概要エディタでPicture属性のビュー・オブジェクト定義に追加されています。

図16-12 LOB属性に対して構成されているカスタム・コンテンツ・タイプ

16.2.11 ADF RESTリソースのLOVアクセッサに関する必知事項

値リスト(LOV)属性は、そのデータソースを別のビュー・オブジェクトに依存するビュー・オブジェクトの属性です。通常、データソース・ビュー・オブジェクトでは、LOV有効属性に対して使用可能な値の固定リストを指定します。ビュー・オブジェクトでLOV有効属性を明示的に定義すると、ADF RESTランタイムがADF RESTリソースでLOV子リソースとして自動的に公開するLOVビュー・アクセッサが、ADFビジネス・コンポーネントによって定義されます。このため、実行時にリソースでLOV有効属性が検出されると、サービス・クライアントによってLOVビュー・アクセッサが起動され、LOV有効属性のデータソースが取得されて、エンド・ユーザーに選択項目が表示される場合があります。

注意:

デフォルトでは、LOVアクセッサ・リソースはリソースで公開され、リソース概要エディタの構造ツリーには表示されません。LOV有効属性の作成の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

16.3 ADF RESTリソース表現およびメソッドのカスタマイズ

ADF RESTリソースの概要エディタを使用して、ADF RESTリソース定義を編集します。リソース構造ツリーで選択することによって、HTTPアクションを有効にし、行検索を公開し、ツリーの各ノードに対する正規のリソース・リンクを有効にできます。

ADFモデル・プロジェクトでRESTリソースに行うカスタマイズは、最終的に、実行時にこれらのリソースと対話するサービス・クライアントの機能に影響します。このため、この項では様々なデザインタイム・カスタマイズについて説明していますが、必要なADF RESTランタイム機能をサポートするサービス・クライアントのユースケースの要件を理解することが重要です。

ADF RESTランタイムの詳細は、「ADF RESTフレームワークを使用したRESTful Webサービスの使用方法」を参照してください。

16.3.1 ADF RESTリソースでの正規リソースの公開方法

ADF RESTリソース表現では、実行時のレスポンスで返される属性が、リソースの基礎となるビュー・オブジェクトによって問い合わされた属性に制限されます。そのため、設計時にビュー・オブジェクト問合せを定義する場合は、サービス・クライアントの特定のユースケースをサポートするために必要な属性のみを公開することが重要になります。ただし、サービス・クライアントが部分的なRESTリソース表現から同じデータの完全表現に移動できるようにするために、正規リソースへのリンクを構成できます。

通常、正規リソースは真のソースとみなされるため、特定のデータソースの完全表現を指定します。正規リソースの例は、managerインスタンスを記述するリソースへのリンクを持つemployeesリソースによって示すことができます。このシナリオ(マネージャ名のみが必要な一般的なユースケース)では、非正規のmanagerリソースに名前属性のみが含まれています。さらに、名前がマネージャの識別には十分でない場合は、非正規リソースがmanagerインスタンスのすべての属性(名前、ID、部門、入社日など)を公開する正規リソースにリンクする場合があります。したがって、正規リソースと非正規リソースは次のような状態で存在します。

- 非正規リソースと正規リソースは、同じデータソースの異なる表現を公開します。

- 非正規リソースはサービス・クライアントのユースケースのサポートに必要なデータソースの表現のみを公開するため、部分表現となります。

- 非正規リソースを定義するときには、その正規の完全表現へのリンクが含められます。

リソースの概要エディタで、リソース構造ツリーの各リソース・ノードに対して、ADFモデル・プロジェクトによって定義されている既存のRESTリソースから正規リソースを選択するか、アプリケーションのconnections.xmlファイルの既存のURL接続によって定義されている外部リソースを選択できます。

RESTリソースの概要エディタで選択できる内部正規リソースは、次の基準を満たす必要があります。

1. ADFモデル・プロジェクトでは、既存の部分的な表現リソースの基礎となる、同じデータソースにアクセスするビュー・オブジェクトを定義する必要があります。ビュー・オブジェクトはエンティティ・ベースまたは非エンティティ・ベースとなります。

2. ビュー・オブジェクトでは、非正規リソースによって問い合わされた使用可能な属性のスーパーセットを問い合わせる必要があります。

3. スーパーセットの表現ビュー・オブジェクトは、アプリケーション・モジュールのデータ・モデルでビュー・インスタンスとして指定する必要があります。

図16-13に、概要エディタのEmployeesViewルート・リソース・ノードの選択および「リソース」ドロップダウンの選択HREmployeesを示します(内部正規リソースEmployeesが有効化されています)。この場合、各基礎となるビュー・オブジェクトによって指定されるデータベース表は、HREmployeesとEmployeesリソースで同じになります。この例では、Employeesは正規リソースで、基礎となるビュー・オブジェクトのすべての属性が含まれる一方、HREmployeesリソースは同じビュー・オブジェクトに基づきますが、特定のユースケースのサポートに必要な属性のみを問い合わせます。

図16-13 概要エディタで有効な正規リソース

注意:

リソース(resource_partial)が正規(resource_full)として別のリソースを選択できるのは、resource_fullにresource_partialが公開するすべての属性が含まれている場合のみです。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

- RESTリソースの正規リンクで内部正規リソースが公開されるようにする場合は、データソース(非正規RESTリソースと同じデータソースである必要があります)から使用可能な属性のスーパーセットを問い合わせるビュー・オブジェクト定義を作成して、データ・モデルでそのビュー・オブジェクトを公開し、内部正規リソースのためのリソースを作成します。リソースの作成の詳細は、「ビュー・オブジェクト・インスタンスからのADF RESTリソースの作成方法」を参照してください。

- RESTリソースの正規リンクで外部正規リソースが公開されるようにする場合は、アプリケーション接続ファイル(connections.xml)でURL接続を作成します(JDeveloperのオンライン・ヘルプのURL接続の作成ダイアログに関するトピックを参照)。

正規リソース・リンクを公開する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「リソース」ドロップダウンから対象のリソースを選択し、「構造」ツリーを展開して、正規リソース・リンクを定義するノードを選択します。

リソース・ツリーの各リソース・ノードに対して正規リンクを定義できます。「構造」ノードの詳細は、表16-1を参照してください。

3. 「構造」ツリーで選択したリソース・ノードの場合、概要エディタの「表現」タブをクリックし、「正規のリンク」を選択します。

現在のリソース・アクセッサ・ノードの選択に対して正規リソースを公開しない場合は、「正規のリンク」を選択解除します。

4. 「正規のリンク」セクションで、正規リソースが「内部」か「外部」かを選択し、ドロップダウン・リストから対象のリソースを選択してリソースの正規バージョンを示します。

内部リソースのドロップダウン・リストは、現在のリソースに追加したリソースによって移入されます。これらは、アプリケーション内部のリソースであり、現在のリソースと同じデータソースに基づく必要があります。

外部リソースのドロップダウン・リストは、アプリケーションに対して定義し、アプリケーション接続ファイル(connections.xml)で登録したURL接続によって移入されます。

16.3.2 ADF RESTリソースで行検索キーを有効化する方法

サービス・クライアントがリソースの主キー(ほとんどの場合は数値)を使用してリソースの問合せができないようにする場合は、ビジネス・コンポーネント開発者は、名前によって一意に識別できる値を持つビュー・オブジェクト属性に基づく行検索キーを指定する行検索を作成できます。この例の1つとして、電子メール属性の最初の文字による従業員の検索があります。

行検索がADF RESTリソースで名前が付けられているビュー・オブジェクトで明示的に定義されている場合は、ADF RESTリソースの概要エディタで、リソース・コレクションをフィルタ処理する行検索を有効にするオプションを使用できます。行検索はデフォルトでは有効化されていません。名前による行検索キーを選択し、これをリソース構造の現在のノード選択に適用する必要があります。

JDeveloperのADF RESTリソースの概要エディタでは、「Rowfinderキー」ドロップダウンに使用可能な行検索のリストが表示されます。リストは、リソース構造ツリーにおけるノード選択の基礎となるビュー・オブジェクト定義で定義されている行検索によって移入されます。たとえば、図16-14は、Employeesが行検索EmpByEmailFinderを含むビュー・インスタンスを定義するノードであるEmpByEmailFinder行検索キーを示しています。

図16-14 ADF RESTリソースのルートで有効な行検索キー

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

- 「アプリケーション・モジュールの作成方法」の説明に従い、RESTリソースで公開するビュー・オブジェクト・インスタンスを含むアプリケーション・モジュールのデータ・モデルを作成します。

- 「行検索の使用」の説明に従い、RESTリソースで公開するビュー・インスタンスで行検索を作成します。

行検索フィルタを公開する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「リソース」ドロップダウンから対象のリソースを選択し、「構造」ツリーを展開して、行検索を公開するリソース・ノードを選択します。

データ・モデルで、ルート・リソースの基礎となるビュー・インスタンスに対してマスター/ディテール階層が定義されていない場合は、「構造」ツリーにビュー・リンク・アクセッサ・ノードは表示されません。「構造」ノードの詳細は、表16-1を参照してください。

3. 概要エディタの「表現」タブをクリックし、「Rowfinderキー」で、現在の「構造」ツリー選択に対する行検索を選択します。

「Rowfinderキー」ドロップダウンは、リソースで正規のリンクが有効化され、かつ正規リソース自体で行検索キーが有効化されている場合は、無効として表示されることがあります。「ADF RESTリソース・リクエストの行検索に関する必知事項」で説明するように、ADF RESTリソースの概要エディタで行検索キー・フィールドが無効になり、部分リソースに行検索キーが自動的に反映されます。

4. オプションで、行検索選択で現在のノード選択を示す正規リソースがフィルタ処理されるようにする場合は、「正規のリンク」をクリックします。

正規のリンクを有効にする場合は、正規リソースに対して内部または外部のソースを選択することも必要となります。

5. 「構造」ツリーで別のノードを選択して、別の行検索を公開します。

16.3.3 ADF RESTリソース・リクエストでの行検索に関する必知事項

実行時、行検索キーが有効化されているADF RESTリソースには、サービス・クライアントで行検索キー属性によってアクセスする必要があります。行検索は、行検索キー属性のみを使用して、行検索が有効なリソースについて、コレクションまたはインスタンスを戻すことをサポートします。このため、エンド・ユーザーに対してデータベースの主キー値の知識を要求することなく、サービス・クライアントがRESTリソースにアクセスできます。たとえば、Employeesリソース・コレクションの特定の従業員を取得する次の2つのGETリクエストを比較します。

行検索なし:

http://localhost:7101/RESTSample_App/rest/11.1/Employees/101

行検索あり:

http://localhost:7101/RESTSample_App/rest/11.1/Employees/NSMITH

行検索キーが定義されていない最初のURLでは、従業員のリソース・アイテムの特定に従業員のIDが必要です。2つ目のURLでは、リソース・パスに行検索キー値(従業員の電子メール・アドレス)を使用します。行検索キーが設計時にリソースで有効化されていると、サービス・クライアントは、ADF RESTランタイムによってリクエスト・ペイロード内に生成されたリンクを使用して、行検索キー値でリソースにアクセスできます。

オプションで、ADF RESTリソースで定義した正規リソースに行検索を適用できます。行検索キーを含む正規リソースが、行検索キーが有効化されているADF RESTリソースで定義されている場合は、両側が同じキー構造によって定義されている必要があります。キー属性は、同じ型で、同じ順序である必要があります。行検索キーを含む正規リソースを作成した後、正規のリンクを含む部分リソースを作成すると、ADF RESTリソースの概要エディタで行検索キー・フィールドが無効になり、部分リソースに行検索キーが自動的に反映されます。正規リソースの詳細は、「ADF RESTリソースでの正規リソースの公開方法」を参照してください。

16.3.4 ADF RESTリソースでサブタイプ・ビュー・オブジェクトを公開する方法

サブタイプ・ビュー・オブジェクトは、継承階層のベース・ビュー・オブジェクトを拡張するビュー・オブジェクトです。サブタイプ・ビュー・オブジェクトは、ベース・ビュー・オブジェクトから属性のそのリストを継承し、サブタイプに固有の独自の属性を提供します。このようなサブタイプ・ビュー・オブジェクトは多相ビュー・オブジェクトと呼ばれます。実行時、多相ビュー・オブジェクトによって、ベース・ビュー・オブジェクトの属性および定義サブタイプ・ビュー・オブジェクトの属性で構成されるサブタイプ・ビュー行が定義されます。

サブタイプ・ビュー行を問い合わせるには、サブタイプ・ビュー・オブジェクトで特定のタイプを判別する識別子属性を指定する必要があります。たとえば、識別子属性JobIdを含むEmployeesViewベース・ビュー・オブジェクトは、使用可能なジョブ(経理担当者、営業担当者など)に基づいてサブタイプ・ビュー行をインスタンス化でき、サブタイプ・ビュー行の属性は、指定されたジョブID値によって決定されます。たとえば、ジョブIDがSA_REPの営業担当者には、サブタイプ・ビュー行属性CommissionPctがありますが、他のジョブ・タイプのサブタイプ・ビュー行ではこの属性は省略されます。

ノードの基礎となるビュー・オブジェクトによって識別子属性が定義される場合は、RESTリソースの概要エディタで、構造ツリーの各ノードのサブタイプ・ビュー・オブジェクトを公開できます。たとえば、図16-7では、概要エディタでEmployeesリソースとEmployeesView2リソース・ノードが選択されています。基礎となるビュー・オブジェクトEmployeesViewは、識別子属性JobIdを定義し、サブタイプ・ビュー・オブジェクトSalesEmployeeViewは、サブタイプSA_REPを定義しています。エディタで、「識別子サブタイプを含める」を有効にし、「識別子名」を指定して識別子属性値を省略することによって、SalesEmployeesViewサブタイプ・ビュー・オブジェクトが公開されます。JobId識別子属性値を省略することにより、リクエストされた従業員のJobId値に基づくEmployeesのサービス・クライアント・リクエストで、確実にサブタイプ属性が返されます。

図16-15 RESTリソース定義での識別子属性の定義

注意:

識別子属性は基礎となるビュー・オブジェクトで定義され、サブタイプ・ビュー行をサポートします。サブタイプ・ビュー・オブジェクトは設計時にADF RESTリソースとして公開されません。サブタイプ定義はアプリケーション・モジュールで、ADF RESTランタイムによって指定されます。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

ビュー・オブジェクトでサブタイプ・ビュー行がどのようにサポートされるかを理解しておくと役立つ場合があります。詳細は、「多相ビュー行関連の作業」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「多相ビュー行を持つビュー・オブジェクトの作成方法」の説明に従って、多相ビュー・オブジェクトを作成します。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、リソースを追加または削除するRESTリソースを作成します。

リソース定義でサブタイプ・ビュー行を公開する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「リソース」ドロップダウンから対象のリソースを選択し、「構造」ツリーを展開して、サブタイプ・ビュー・オブジェクトを公開するリソース・ノードを選択します。

データ・モデルで、ルート・リソースの基礎となるビュー・インスタンスに対してマスター/ディテール階層が定義されていない場合は、「構造」ツリーにビュー・リンク・アクセッサ・ノードは表示されません。「構造」ノードの詳細は、表16-1を参照してください。

3. 概要エディタの「表現」タブをクリックし、「識別子サブタイプを含める」を選択して、現在の「構造」ツリー選択でサブタイプ・ビュー行を有効にします。

4. 「識別子名」ドロップダウンからサブタイプ識別子属性を選択し、サブタイプ・ビュー・オブジェクトでサブタイプ識別子属性値が定義される場合は、対象のサブタイプ・ビュー行を定義する値を省略します。

「識別子名」ドロップダウンは、基礎となるビュー・オブジェクトの識別子属性定義によって移入されます。たとえば、EmployeesViewビュー・オブジェクトは、識別子属性JobId属性を、サブタイプ・ビュー・オブジェクトSaleEmployeesViewを持つ識別子属性として定義できます。ほとんどの場合、サブタイプ・ビュー・オブジェクトはサブタイプ識別子属性値を定義するため、リソース定義で属性値を空にしておくことができます。たとえば、サブタイプ・ビュー・オブジェクトSalesEmployeesViewで、SA_REP (営業担当者)がJobId識別子属性値として定義されている場合、Employeesリソースに対して行われるリクエストには、リソースで定義されたサブタイプではなく、従業員のジョブIDに基づくサブタイプ属性が含められます。リソースで識別子属性サブタイプ値を定義すると、同じタイプがリソース・アイテムに適用されます。

16.3.5 ADF RESTリソースで標準のHTTPアクションを公開する方法

ADF RESTリソースで公開する標準のデータ処理操作は、リソースの基礎となるビュー・インスタンスのアクションに対応しています。実行時、サービス・クライアントは、RESTful Webサービスでこれらの操作をHTTPアクションとして起動します。

表16-2に、RESTリソースの概要エディタにおいてデフォルトで公開される標準操作をリストします。リソース・ツリーで行った各リソース選択のリストから操作を選択解除することにより、別の操作セットを公開できます。GETメソッドは常にリソースに対して公開されることに注意してください。

表16-2 標準ビュー・インスタンス・データ処理操作

操作選択

HTTPメソッド名

操作の説明

作成

POST

1つのADFビジネス・コンポーネント・ビュー行またはビュー行セットを作成します。

更新

PATCH

1つのADFビジネス・コンポーネント・ビュー行の指定されたアイテムを更新します。成功するには、この操作に対してビュー行が存在する必要があります。

削除

DELETE

1つのADFビジネス・コンポーネント・ビュー行またはビュー行セットを削除します。

なし

GET

1つのADFビジネス・コンポーネント・ビュー行またはビュー行セットを読み取ります。この操作は、リソースの作成時にデフォルトで使用できることに注意してください。

注意:

ADF RESTリソース・リクエストでHTTP PUTメソッドを実行する機能は推奨されていないことに注意してください。現在のリリースでは、基礎となるビュー・オブジェクトで更新操作が有効になっている場合は、ADF RESTリソースの記述でPUTアクションが引き続き表示されています(操作でPUTおよびPATCHメソッドを有効にします)が、この機能は今後のリリースではサポートされないため、ADF RESTサービス・クライアントで、PUTリクエスト(ビュー行のすべてのアイテムが置き換えられます)を行わないでください。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

HTTPアクションを公開する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「リソース」ドロップダウンから対象のリソースを選択し、「構造」ツリーを展開して、編集するリソース・アクセッサ・ノードを選択します。

ルート・リソースおよび子リソースに対して操作を公開できます。「構造」ノードの詳細は、表16-1を参照してください。

3. 概要エディタの「表現」タブをクリックし、「使用可能な操作」セクションで、現在の「構造」ツリー選択に対して公開する操作を選択します。

4. 「構造」ツリーで別のノードを選択して、リソース構造の別のリソース・アクセッサで操作を公開します。

16.3.6 LOV属性を使用したADF RESTリソースの作成操作のサポート方法

値リスト(LOV)を要求するリソース操作にリスト移入の行コンテキストがなくても、それらの操作がADF RESTリソースでサポートされるようにするには、LOVリソースを作成する必要があります。たとえば、サービス・クライアントがRESTリソースでリソース・アイテムの作成操作を呼び出し、LOVリストに使用する行コンテキストがないとします。この場合、LOVリソースが子リソースとして存在していないため、作成しようとしているリソース・アイテムとは別にサービス・クライアントから実行時にアクセスする必要があります。

注意:

サービス・クライアントが既存のリソース・アイテムにアクセスする場合は、LOV対応属性を持つリソースをサポートするための設計時変更は不要です。設計時にLOVリソースを作成する必要があるのは、サービス・クライアントが新しいリソース・アイテムを作成し、そのリソース・アイテムがLOV対応属性に基づく場合のみです。既存のリソース・アイテムの場合は、リソース・アイテムがリソース・コレクション内の行コンテキストを提供するため、ADF RESTランタイムが自動的にLOVリンクを子リソースとして生成します。LOV子リソースの詳細は、「ADF RESTリソースのLOVアクセッサに関する必知事項」を参照してください。

JDeveloperでは、ビュー・オブジェクトの概要エディタを使用して、「属性」ページで個々の属性のLOV定義を作成します。これと同じページを使用して静的LOVリソースを定義します。たとえば図16-16は、Employeesリソースの基礎となるビュー・オブジェクトの概要エディタに表示されているEmployeesViewビュー・オブジェクトとLOV対応属性JobIdを示しています。静的LOVリソースはそれがサポートとしている特定のADF RESTリソースによって特定され、この場合はv2 (Jobsリソースの内部バージョン識別子)です。静的LOVリソースの下にあるのが、ビュー・オブジェクトのLOV対応属性によって使用されるLOV定義です。

図16-16 静的LOVリソースがRESTリソースの作成操作をサポート

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従って、ビュー・オブジェクトの属性のLOVを有効化します。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従って、作成操作を公開するLOV対応属性を持つビュー・オブジェクトのRESTリソースを作成します。

注意:

ビュー・オブジェクトでLOVリソースを定義するときには、LOV対応属性のLOV定義で必要となる属性が、ビュー・オブジェクトのサービス形状定義によって非表示にされないようにしてください。必要なLOV属性は、LOVデータ・ソースにマップされる属性やLOV表示属性などです。サービス形状およびADF RESTリソースの詳細は、「ADF RESTリソースの属性を非表示にしたり公開したりする方法」を参照してください。

ADF RESTリソースに使用する静的LOVリソースを定義する手順:

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「ビュー・オブジェクト」リンクをクリックします。

3. ビュー・オブジェクトの概要エディタで、「属性」ナビゲーション・タブをクリックします。

4. 「属性」ページでLOVセクションを展開し、「LOVリソースを属性に作成」ボタンをクリックします。

5. LOVリソースの作成ダイアログで「リリース・バージョン」識別子を選択し、LOV対応属性を公開するADF RESTリソースの「リソース名」を選択して、リソース構造ツリーから定義リソースを選択します。

「リソース名」リストのデータはモデル・プロジェクト内のADF RESTリソース定義によって移入されます。選択したRESTリソースのビュー・オブジェクト定義は、LOV属性データ・ソースを定義しているビュー・オブジェクトと同じである必要があります。たとえばEmployeesリソースを作成していて、EmployeesViewビュー・オブジェクトがLOV属性JobsIdを定義しているとします。LOVリソースの作成エディタで、図16-17のとおり、ADF RESTリソースJobsを選択し、Jobsリソースのリソース構造ツリーからルート・リソースJobsView1を選択します。

図16-17 REST作成操作のための静的LOVリソースの作成

6. 「OK」をクリックし、LOVリソース定義を保存します。

16.3.7 ADF RESTリソースの取得操作の最適化に関する必知事項

すべてのADF RESTリソースでは、サービス・クライアントによる読取り操作がサポートされます。効率的な読取り操作(HTTP GETリクエスト)をサポートするには、ADF RESTリソースの基礎となるビュー・オブジェクト定義で、HTTPリクエスト・ペイロードでのコレクションのページングをサポートするように設定されたアクセス・モードを定義する必要があります。範囲ページングの詳細は、「ビュー・オブジェクトの範囲ページ移動を有効にする方法」を参照してください。

16.3.8 ADF RESTリソースでカスタム・メソッドを公開する方法

ADF RESTリソースで公開するカスタム・メソッドは、リソースの基礎となるビュー・インスタンスのクライアント・インタフェースによって公開されるカスタム・メソッドに対応しています。実行時、サービス・クライアントは、RESTful WebサービスでHTTP POSTを使用してこれらのメソッドを起動します。

JDeveloperのRESTリソースの概要エディタでは、「カスタム・メソッド」タブにカスタム・メソッドのリストが表示されます。リストは、ルート・リソースの基礎となるビュー・オブジェクト定義で定義されているメソッドによって移入されます。たとえば、図16-18は、EmployeesView1ビュー・インスタンスのクライアント行インタフェースで公開されているmultipleSalaryメソッドを示しています。

図16-18 RESTリソースのルートで公開されるカスタム・メソッド

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「UIクライアントへのカスタム・サービス・メソッドの公開」の説明に従い、RESTリソースで公開するビュー・オブジェクトのクライアント・インタフェースまたはクライアント行インタフェースでカスタム・メソッドを作成します。

カスタム・メソッドを公開する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、編集するADF RESTリソースを定義するリソース定義ファイルをダブルクリックします。

2. RESTリソースの概要エディタで、「リソース」ドロップダウンから対象のリソースを選択し、「構造」ツリーで、ルート・リソース・ノードを選択します。

「構造」ノードの詳細は、表16-1を参照してください。

3. 概要エディタの「カスタム・メソッド」タブをクリックし、「クライアント・インタフェース」セクションで、公開するメソッドごとに「有効」をクリックします。「カスタム行インタフェース」セクションで、公開する行レベルのメソッドごとに「有効」をクリックします。

このタブは、「構造」ツリーで選択する子リソース・ノードには表示されません。

16.4 ADF RESTリソースのバージョニング

開発サイクル中は、リソースをバージョニングする必要なく、ADF RESTリソースに変更を加えることができます。ただし、RESTful Webサービスをデプロイした後、ADF RESTリソースにアクセスするサービス・クライアントでそれらのユースケースが満たされることは、リソース・コレクションの安定性に依存します。

時間の経過に伴い、ユースケースが変化したり、RESTリソースの基礎となるビュー・オブジェクトが変化したりすることによって、すでにデプロイされているリソースのリソース構造を変更することが必要になる場合があります。このとき、既存のADF RESTリソースに対する変更に、デプロイされているRESTサービスとの後方互換性がない場合があり、新しいバージョン識別子およびそのバージョンのADF RESTリソースを作成することが必要になる場合があります。

16.4.1 ADF RESTリソースのバージョニング方法

adf-config.xmlファイルの概要エディタを使用して、新しいバージョン識別子を作成し、既存のバージョンのライフサイクル・ステータスを更新します。ライフサイクル・ステータスは、active、deprecatedまたはdesupportedのいずれかになります。サービス・クライアントが、リクエストされたバージョンに存在しないリソースをリクエストすると、ADF RESTランタイムによって、ステータスがactiveまたはdeprecatedになっている前のバージョンにフォールバックされます

リリース・バージョン・リスト内のリリース名識別子の順序は重要です。ADF RESTランタイムは、最上位のリリース名を最新バージョンとして認識します。リストの最上位の名前の下に続くリリース名は、バージョンの順序リストを形成します。図16-19に示すように、11.0は最初のバージョンであるため、リストの一番下に表示される必要があり、後続のバージョンはその上にリストされます。ここでは、11.2が最新バージョンです。

図16-19 ADF RESTリソースのバージョン管理

注意:

バージョンの順序リストでリリース識別子の位置を変更するには、概要エディタの「リリース・バージョン」ページで矢印を使用して、識別子をリストの上(より新しいバージョン)または下(以前のバージョン)に移動できます。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、どのような編集によって、後方互換性のない変更がリソースに発生し、新規バージョンのリソースの作成が必要となるかを理解しておくと役立つ場合があります。詳細は、「ADF RESTリソースのバージョニングに関する必知事項」を参照してください。

また、サービス・クライアントによるリクエストがリソースのバージョン識別子にどのように依存するかについても、理解しておくと役立つ場合があります。詳細は、「実行時に行われる処理: ADF RESTリソースのバージョンの起動」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

ADF RESTのバージョンを管理する手順は次のとおりです。

1. 「アプリケーション」ウィンドウの「アプリケーション・リソース」ペインで、DescriptorsおよびADF META-INFノードを開き、adf-config.xmlファイルをダブルクリックします。

2. adf-config.xmlファイルの概要エディタで、「リリース・バージョン」ナビゲーション・タブをクリックし、「新規リリース・バージョンの作成」アイコン・ボタンをクリックして新しいリソース・バージョン識別子を作成します。

3. ランタイムに影響するバージョンの順序を変更する場合は、表からバージョンを選択し、表の右にある矢印を使用して、バージョンのリスト内でその階層を変更します。

ADF RESTランタイムは、リストの最上位のバージョンをリソースの最新バージョンとして認識します。

4. オプションで、対象のリソース・ライフサイクルに適合するように、ステータス(active、desupported、deprecated)を選択します。

バージョンを作成してRESTリソースに割り当てた後で、バージョン識別子をadf-config.xmlファイルから削除する必要があります。バージョンを効率的に削除するには、そのステータスをdesupportedに変更する方法が適しています。

16.4.2 ADF RESTリソースのバージョニングに関する必知事項

次に、すでにデプロイされているRESTful Webサービスと後方互換性がないとみなす必要があるADF RESTリソース構造への変更の例を示します。

- 公開されている属性の名前変更

- すでに公開されている属性の削除または非表示

- すでに公開されている子リソースの削除

- 標準操作の無効化またはカスタム・メソッドの削除

- LOVビュー・アクセッサの無効化または別のビュー・オブジェクトに対するLOVの変更

特定の状況では、リソースをバージョニングしないで、ADF REST構造を変更できます。次の変更は後方互換性があるとみなされるため、すでにデプロイされているADF RESTリソースの新規バージョンを作成する必要はありません。

- 属性を必須として定義しない新規属性および基礎となるビュー・オブジェクトの公開
必須として定義された属性を公開する場合は、リソースをバージョニングする必要があることに注意してください。

- 標準操作の公開または新しいカスタム・メソッドの公開

- 新しい子リソースの公開

- すでに公開されている属性に対するLOVビュー・アクセッサの定義

16.4.3 実行時に行われる処理: ADF RESTリソースのバージョンの起動

指定するバージョン識別子は、サービス・クライアントがRESTリソースの操作の起動に使用するURLを形成します。たとえば、次のGETリクエストでは、URLパラメータ11.0および11.1を指定して、Departmentsリソースの2つの異なるバージョンにアクセスします。

http://localhost:7101/RESTSample_App/rest/11.0/Departments

http://localhost:7101/RESTSample_App/rest/11.1/Departments

adf-config.xmlファイルの概要エディタを使用して、既存のバージョンのライフサイクル・ステータスを更新する場合は、各バージョンにactive、deprecatedまたはdesupportedのいずれかのタグを付けます。ステータスdeprecatedは実行時の影響はなく、ドキュメントの目的で提供されていますが、ステータスをdesupportedにすると、デプロイされているリソースにアクセスできなくなります。

adf-config.xmlファイルのリリース・バージョン・リスト内のリリース名識別子の順序は重要です。ADF RESTランタイムは、最上位のリリース名を最新バージョンとして認識します。リストの最上位の名前の下のリリース名は、バージョンの順序リストを形成します。たとえば、次のGETリクエストでは、URLパラメータlatestを指定して、Departmentsリソースの11.1を取得します。ここで、11.1は、リリース・バージョン・リストの最上位です。

http://localhost:7101/RESTSample_App/rest/latest/Departments

サービス・クライアントが、リクエストされたバージョンに存在しないリソースをリクエストすると、ADF RESTランタイムによって、ステータスがactiveまたはdeprecatedになっている前のバージョンにフォールバックされます。このため、Departmentsリソースのバージョン11.0および11.1が存在し、11.2が存在しない場合は、バージョン11.2へのリクエストに対して、次に最新のリソースであるバージョン11.1が返されます。

16.5 ADF RESTリソースへのクライアント・アクセスの付与

RESTリクエストでのアクションの起動に対してユーザー認証が要求されるようにする場合は、ADF RESTリソースに対してセキュリティを有効にできます。ADFセキュリティの構成ウィザードを実行し、ウィザードでWebプロジェクトとしてRESTWebService.jprを選択すると、セキュリティはすべてのFusion Webアプリケーションのように処理され、有効化されます。Webサービス・プロジェクトでADFセキュリティを有効にすることは、デプロイされているサービスにデフォルトではアクセスできず、ユーザーには特定のアクセス権限を付与するセキュリティ権限が必要となることを意味します。

RESTful Webサービスのユーザーに付与できる権限は、次のクラスによって定義されます。

- RESTリソースで定義されている標準のアクションに対する認可付与を定義するoracle.adf.share.security.authorization.RestServicePermission。

表16-3に、ユーザーに付与できるADF REST権限クラスによって定義されているアクションをリストします。

表16-3 ADF RESTリソースのセキュリティ保護されたアクション

許可できるアクション

RESTリソースへの影響

describe

RESTリソースのコレクションおよびインスタンスを記述できるようにします。

get

RESTリソースのコレクションまたはインスタンスを返すことができるようにします。

update

RESTリソースのコレクションまたはインスタンスを更新できるようにします。

delete

RESTリソースのコレクションまたはインスタンスを削除する権限。

create

RESTリソースのコレクションまたはインスタンスを作成できるようにします。

invoke

この権限で、RESTリソースのカスタム・メソッドを起動できるようにします。このアクションは、個々のメソッドではなく、すべてのカスタム・メソッドへのアクセス権を付与することに注意してください。

ADF RESTリソースのアクションを起動するユーザーを認証する一般的なプロセスは、次のとおりです。

1. RESTリソースに対する必要な標準のアクションを有効にします。

2. RESTリソースに対する必要なカスタム・メソッドを有効にします。

3. RESTWebServiceプロジェクトで、ADFセキュリティ・ウィザードを実行します。

4. RESTリソースのためのリソース権限を作成します。

16.5.1 ADF RESTリソースに対するリソース権限の作成方法

セキュリティ・ポリシーの概要エディタを使用して、リソースで公開した操作をセキュリティ保護する権限を作成します。JDeveloperによって、リソース・タイプの定義とOPSS権限クラスoracle.adf.share.security.authorization.RestServicePermissionが照合されます(表16-3を参照)。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「ビュー・オブジェクト・インスタンスからのADF RESTリソースの作成方法」の説明に従い、必要なRESTリソースを作成します。

- 「ADF RESTリソースで標準のHTTPアクションを公開する方法」の説明に従い、RESTリソースでセキュリティ保護する標準操作を有効にします。

- 「ADF RESTリソースでカスタム・メソッドを公開する方法」の説明に従い、必要なカスタム・メソッドを作成してADF RESTリソース表現で公開します。

- ADFセキュリティの構成ウィザードを実行してセキュリティを適用し、RESTリソース・メソッドがデフォルトで保護されるようにします。ウィザードの「認証タイプ」ページで、ViewControllerを選択するかわりに、「ADFセキュリティの有効化」で説明するように、ADF RESTリソースを定義するADFビジネス・コンポーネント・モデル・プロジェクトを選択します。

ADF RESTリソース権限を作成する手順は次のとおりです。

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウンから「ADF RESTリソース」を選択します。

3. リソースを定義するモデル・プロジェクトを見つけて、これを「ソース・プロジェクト」フィールドに追加します。

4. 「リソース」列で、このリソースを選択します。

5. 「付与先」列で、「権限受領者の追加」アイコンをクリックして「ユーザーの追加」を選択し、「ユーザーの選択」ダイアログで、「追加」アイコンをクリックしてtestUserという名前のユーザーを作成し、「OK」をクリックします。

6. 「付与先」列で選択したユーザーに対して、「アクション」リストから必要なアクションを選択します。

図16-20のように、概要エディタにリソース権限が表示されます。

図16-20 ADF RESTリソースに対する権限の作成

16.6 ADF RESTリソースのデプロイ

JDeveloperの統合WebLogic ServerまたはスタンドアロンOracle WebLogic Serverに、RESTful Webサービスをデプロイできます。

16.6.1 統合WebLogic ServerへのADF RESTリソースのデプロイ方法

図16-21に示すように、RESTWebServiceプロジェクトで選択したデフォルトの「実行」オプションを使用して、JDeveloperの統合WebLogic ServerにRESTful Webサービスをデプロイできます。

図16-21 RESTWebServiceプロジェクトでのデフォルトの「実行」オプションの使用

統合WebLogic Serverにサービスをデプロイすると、「ログ」ウィンドウでターゲットURLをクリックして、JDeveloperのHTTPアナライザ・ツールでサービスにアクセスし、リクエスト(GETまたはPOSTなど)を作成する構文を使用してテストを実行できます。RESTful Webサービスのテストの詳細は、「統合WebLogic Serverを使用したADF RESTリソースのテスト」を参照してください。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

- オプションで、デフォルト・ドメインの使用に関する項の説明に従い、統合WebLogic Server接続を作成し、デフォルト・ドメインを構成します。接続が作成されていない場合は、JDeveloperにより接続を作成するように要求されます。

- オプションで、デプロイされているRESTful Webサービスへのアクセスに使用されるターゲットURLに出現するように、RESTサーブレットのURLパターンおよびコンテキスト・ルートを編集します。URLパターンの編集の詳細は、「サービス・クライアントによって使用されるターゲットURLの変更に関する必知事項」を参照してください。

Webサービスを統合WebLogic Serverにデプロイする手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、RESTWebServiceプロジェクト・ノードを選択し、右クリックして「実行」を選択します。

統合WebLogic Serverが構成されていない場合は、JDeveloperによりデフォルト・ドメインを構成するように要求されます。

JDeveloperによってアプリケーションがデプロイされ、Webサービスが開始されます。この間、これらのプロセスからの出力が「ログ」ウィンドウの実行中: IntegratedWebLogicServerタブに表示されます。図16-22に示すように、Webサービスが開始された後、ターゲットURLがログの下部に表示されます。

図16-22 ターゲットURLが表示された「ログ」ウィンドウ

2. Webサービスのデプロイ後、「ログ」ウィンドウの実行中: IntegratedWebLogicServerタブで、ターゲットURLをクリックしてHTTPアナライザでWebサービスにアクセスし、JDeveloperでデプロイされているサービス上でテストを実行します。

たとえば、「ログ」ウィンドウの実行中: IntegratedWebLogicServerタブに、クリック可能な次のターゲットURLが表示される場合があります。ここで、7101はポート番号で、その後にサービス・コンテキスト・ルートおよびRESTサーブレットのURLパターンが続きます。

http://<hostname>:7101/RESTSample_App-context-root/rest

3. または、Webブラウザを使用してWebサービスを表示するには、「ログ」ウィンドウのターゲットURLをブラウザのアドレス・フィールドに貼り付けて、ADF RESTリソースを識別するようにURLを変更し、HTTP GETリクエストを発行します。

たとえば、Departmentsリソースのバージョン11.1に対するGETリクエストは次のようになります。

http://localhost:7101/RESTSample_App-context-root/rest/11.1/Departments

構成したリソースのバージョン番号をURLに含めてください。この例では、図16-23に示すように、Departmentsリソースのバージョンとして11.1が構成されました。

図16-23 ブラウザを使用したGET RESTリクエストの実行

16.6.2 スタンドアロンOracle WebLogic Serverのデプロイメントに対するADF RESTリソースのデプロイメント・プロファイルの構成方法

RESTful WebサービスをスタンドアロンOracle WebLogic Serverにデプロイする前に、ADF RESTリソースのデプロイメント・プロファイルを構成し、ADF RESTアプリケーションEARファイルの依存モジュールとしてRESTWebServiceプロジェクトを宣言する必要があります。このプロジェクトには、サービス・クライアントが確実にRESTリソースにアクセスできるようにするweb.xmlファイルおよびweblogic.xmlファイルが含まれています。

JDeveloperで、「EARデプロイメント・プロファイルのプロパティの編集」ダイアログの「アプリケーション・アセンブリ」ページを使用して、モジュールの依存性をアプリケーションに追加します。次に、ADF RESTアプリケーションをデプロイすると、選択したRESTWebServiceプロジェクトの2つのファイルが、デプロイされているEARファイルにWARファイルとしてアセンブルされます。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

デプロイメント・プロファイルを構成する手順は次のとおりです。

1. RESTWebServiceプロジェクトをアプリケーションのEARデプロイメント・プロファイルの依存性として追加します。

a. 「アプリケーション」ウィンドウで、アプリケーションを選択し、メイン・メニューから「アプリケーション」→「アプリケーション・プロパティ」を選択します。

b. 「アプリケーション・プロパティ」ダイアログで、「デプロイメント」を選択してからアプリケーション・モジュール・デプロイメント・プロファイルを選択し、「プロファイルの編集」をクリックします。

c. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「アプリケーション・アセンブリ」を選択してRESTWebService.jprモジュールを開き、図16-24に示すようにプロジェクトを選択して「OK」をクリックします。

図16-24 RESTWebServiceプロジェクトへのデプロイメントの依存性の追加

16.6.3 スタンドアロンOracle WebLogic ServerへのADF RESTリソースのデプロイ方法

スタンドアロンOracle WebLogic ServerにRESTful Webサービスをデプロイできます。

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

- 「スタンドアロンOracle WebLogic Serverのデプロイメントに対するADF RESTリソースのデプロイメント・プロファイルの構成方法」の説明に従い、デプロイメント・プロファイルを変更して、依存性としてRESTWebServiceプロジェクトを追加し、Webサービスをデプロイします。

- Oracle Metadata Services (MDS)フレームワークによって提供されるカスタマイズ機能がアプリケーションで使用され、かつ形成定義がADF RESTリソースに適用されている場合は、「ADF RESTリソースのデプロイとMDSカスタマイズ・サポートに関する必知事項」の説明に従い、カスタマイズ機能のMARプロファイルを変更する必要があります。

- オプションで、デプロイされているRESTful Webサービスへのアクセスに使用されるターゲットURLに出現するように、RESTサーブレットのURLパターンおよびコンテキスト・ルートを編集します。URLパターンの編集の詳細は、「サービス・クライアントによって使用されるターゲットURLの変更に関する必知事項」を参照してください。

スタンドアロンOracle WebLogic ServerにWebサービスをデプロイする手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、アプリケーションを選択し、メイン・メニューから「アプリケーション」→「デプロイ」→deployment_profile→server_nameを選択します。

JDeveloperによってアプリケーションがデプロイされ、Webサービスが開始されます。この間、これらのプロセスからの出力が「ログ」ウィンドウの「デプロイメント」タブに表示されます。Webサービスの開始後、ターゲットURLも「ログ」ウィンドウに表示されます。

2. Webサービスのデプロイ後、「ログ」ウィンドウの「デプロイメント」を開き、ターゲットURLをクリックしてWebサービスにアクセスし、デプロイされているサービス上でテストを実行します。

16.6.4 サービス・クライアントによって使用されるターゲットURLの変更に関する必知事項

サービス・クライアントがサービスへのアクセスに使用するURLに出現するように、RESTサーブレットのURLパターンを編集できます。デフォルトでは、サーブレット・マッピングでURLパターンのrestを使用します。

http://localhost:7101/RESTSample_App-context-root/rest/11.1/Departments

サーブレット・マッピング・パターンを編集するには、「アプリケーション」ウィンドウで、RESTWebServiceプロジェクトを開いてweb.xmlファイルをダブルクリックし、図16-25に示すように、web.xmlファイルのエディタでRESTサーブレットのURLパターンを編集します。

図16-25 RESTサーブレット・マッピングのURLパターンの編集

サービスにアクセスするURLに出現するように、コンテキスト・ルートも編集できます。デフォルトでは、コンテキスト・ルートはアプリケーション名に基づいており、必要に応じて短縮できます。コンテキスト・ルートを編集するには、「アプリケーション」ウィンドウで、RESTWebServiceプロジェクトを右クリックして「プロジェクト・プロパティ」を選択し、「プロジェクト・プロパティ」ダイアログで「Java EEアプリケーション」をクリックして、図16-26に示すように「Java EEコンテキスト・ルート」を編集して「OK」をクリックします。

図16-26 RESTWebServiceプロジェクトでのデフォルトのコンテキスト・ルートの編集

16.6.5 ADF RESTリソースのデプロイとMDSカスタマイズ・サポートに関する必知事項

モデル・プロジェクトでビュー・オブジェクト形成定義を定義し、アプリケーションでOracle Metadata Services (MDS)フレームワークの機能を使用してエンド・ユーザーのカスタマイズをサポートする場合は、userディレクトリに/persdef/を含むMARプロファイルを作成する必要があります。

ADF REST形成定義で共有するネームスペース・パスがMDSカスタマイズによって定義されるため、このことが必要になります。

<namespace path="/persdef/" metadata-store-usage="reposX"/>

この場合、adf-config.xmlファイルでは、対応するmetadata-store-usage要素に対してdeploy-target="true"を定義する必要があります。

カスタマイズしたメタデータをパッケージ化する方法の詳細は、「カスタマイズしたアプリケーションをパッケージ化してデプロイする方法」を参照してください。

16.7 統合WebLogic Serverを使用したADF RESTリソースのテスト

JDeveloperを使用して、RESTful Webサービスを統合WebLogic Serverにデプロイし、デプロイメント・プロセスによって生成されるターゲットURLを使用してADF RESTリソースにアクセスします。生成されたURLを使用すると、ADFモデル・プロジェクトのADF RESTリソースをテストするリクエストを実行できます。

次のいずれかの方法を使用して、必要なペイロードを返すようにデプロイされているサービスのURLを変更することによって、デプロイされているRESTful Webサービスをテストできます。

- JDeveloperのHTTPアナライザで、「HTTPリクエストの作成」オプションを使用

- Webブラウザ(通常GETリクエストに限定されています)

- コマンド・ウィンドウからのcURLコマンド行ツール
cURLはサードパーティ・ツールで、これをインストールして、コマンド・ウィンドウを使用してRESTリクエストを実行するように構成できます。

デプロイされているRESTful Webサービスを使用したADFリソースをテストするには、ADF RESTランタイムによって有効化されているREST API構文を理解していることが必要です。ただし、このドキュメントの手順を使用すると、基本的なGETリクエストを実行してリソース・コレクションを表示できます。

たとえば、すべてのリソースのすべてのバージョンを返すGETリクエストは次のようになります。

http://<server>/<context-root>/rest

たとえば、特定のバージョンのすべてのリソースを返すGETリクエストは次のようになります。

http://<server>/<context-root>/rest/<versionID>/describe

たとえば、特定のリソース・コレクションの特定のバージョンを返すGETリクエストは次のようになります。

http://<server>/<context-root>/rest/<versionID>/<resourceName>

始める前に:

ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。

ADF RESTフレームワークおよびHTTPメソッドを使用してAPIコールを行う構文も理解しておくと役立つ場合があります。詳細は、「ADF RESTフレームワークを使用したRESTful Webサービスの使用方法」を参照してください。

また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、必要なRESTリソースを作成します。

- 「統合WebLogic ServerへのADF RESTリソースのデプロイ方法」の説明に従い、ADF RESTリソースを統合WebLogic Serverにデプロイします。

- RESTリソースに対してRESTful Webサービス操作をテストするためのツールを使用するには、コマンド行ツールcURLをダウンロードします。

HTTP GETを使用してWebサービスをテストする手順は次のとおりです。

1. JDeveloperのHTTPアナライザを使用してテストするには、メイン・メニューから「ツール」→「HTTPアナライザ」を選択し、HTTPアナライザの「ログ」ウィンドウで「新規HTTPリクエストの作成」を選択し、HTTPアナライザの「HTTPコンテンツ」タブを選択して、「ログ」ウィンドウからコピーしたターゲットURLを「URL」フィールドに貼り付け、RESTリソースを識別するURLを変更し、対象の「メソッド」を選択して「リクエストの送信」をクリックします。

構成したリソースのバージョン番号をURLに含めてください。この例では、図16-27に示すように、11.1はDepartmentsリソースのアクセスに使用されるリリース名バージョン識別子です。

図16-27 HTTPアナライザを使用したGET RESTリクエストの実行

HTTPアナライザではSOAP、標準のHTTPおよびRESTタイプのリクエストがサポートされることに注意してください。ただし、汎用RESTful Webサービスを定義するためにHTTPアナライザに通常指定するWADLでは、ADF RESTリソースの記述形式はサポートされていません。そのため、HTTPアナライザを使用して、デプロイされているADF RESTリソースをテストする場合は、RESTリクエストではなく、新規のHTTPタイプのリクエストを作成する必要があります。

2. サードパーティのcURLコマンド行ツールを使用してテストするには、コマンド・プロンプトを開き、次のようなRESTリソースに対するcURLコマンドを入力します。ここで、-vはcURLによって送信された内容を表示するオプションで、-Xはリクエスト・オプションです。

curl -v -X GET http://127.0.0.1:7101/RESTDemo/rest/11.1/Departments

構成したリソースのバージョン番号をURLに含めてください。この例では、図16-28に示すように、11.1はDepartmentsリソースのアクセスに使用されるリリース名バージョン識別子です。

図16-28 cURLを使用したRESTリクエストの実行

17 ビジネス・コンポーネント機能の拡張

この章では、すべてのタイプのADFビジネス・コンポーネントにカスタム・コードを組み込んだり、ADFビジネス・コンポーネント・フレームワークの動作を拡張したりする場合に使用できる手法について説明します。

この章の内容は次のとおりです。

- ビジネス・コンポーネント機能の拡張について

- ADFビジネス・コンポーネント拡張クラスの作成

- 拡張クラスによるフレームワークの動作のカスタマイズ

- 汎用拡張インタフェースの作成

- ストアド・プロシージャとストアド・ファンクションの呼出し

- 現在のデータベース・トランザクションへのアクセス

- ビジネス・コンポーネントのエラー・メッセージのカスタマイズ

- 継承を使用する拡張コンポーネントの作成

- 提供されるアプリケーションでの拡張コンポーネントの置換え

17.1 ビジネス・コンポーネント機能の拡張について

フレームワーク・ベースの開発の強力な機能の1つは、基本フレームワークを拡張して、組込み機能の動作を変更したり、すべてのアプリケーションが使用できる新機能を追加したりできることです。

ADFビジネス・コンポーネント・フレームワークのベース・クラスを拡張して、フレームワーク内のすべてのタイプのコンポーネントにカスタム・コードを組み込んだり、ADFビジネス・コンポーネント・フレームワークの動作を拡張できます。

カスタマイズを行わずに使用した場合、ビジネス・コンポーネントは、XMLドキュメントで完全に定義されており、コンポーネントのカスタムJavaコードやJavaクラス・ファイルをまったく必要とせず、十分な機能を備えています。ADFビジネス・コンポーネントのコンポーネントの組込み機能を拡張する必要がない場合、また、組込みイベントを処理するカスタム・コードを記述する必要がない場合、このXMLのみの方法でコンポーネントを使用できます。ただし、ADFビジネス・コンポーネント・フレームワークを拡張する場合も、JDeveloperでXMLドキュメントを操作できます。

フレームワーク拡張クラスを作成した後は、ベース・クラスではなくカスタマイズしたフレームワーク・クラスに基づいて、新しいビジネス・コンポーネントを作成できます。また、いつでも既存のコンポーネントの定義を更新して、新しいフレームワーク拡張クラスを使用するようにできます。

17.1.1 ビジネス・コンポーネントの拡張の追加機能

ADFビジネス・コンポーネント・フレームワークを使用する前に、他のOracle ADF機能について理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- 再利用可能なライブラリを作成してフレームワーク拡張レイヤー・クラスのパッケージ化を容易にする場合の詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

- Oracle Metadata Services (MDS)のカスタマイズ機能を使用して顧客によるカスタマイズとその後のデプロイが可能なアプリケーションを作成する場合の詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。

- カスタム・クラスでよく記述、使用またはオーバーライドするコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。

- oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。

- Oracle ADFモデルJava APIリファレンス

17.2 ADFビジネス・コンポーネント拡張クラスの作成

ADFビジネス・コンポーネント・フレームワーク拡張クラスは、次のことを目的としてユーザーが作成する、フレームワークの基本クラスの1つを拡張するJavaクラスです。

- 追加の汎用的な機能で組込み機能を補強する

- 組込み機能の動作方法を変更する

- 検出された不具合を一般的な方法で回避する

アプリケーション固有のビジネス・コンポーネントの開発を始める前に、フレームワーク拡張クラスの完全なレイヤーを作成し、そのレイヤーをデフォルトで使用するようプロジェクト・レベルで設定することを検討することをお薦めします。当初はこれらのフレームワーク拡張クラスにカスタム・コードを追加することを想定していないかもしれませんが、このような設定は実際にカスタマイズが必要になった場合に役に立ちます。

これにより、新しい汎用機能や、組込み機能の補強や、不具合の一般的な回避といったことが、プロジェクトの途中ですべてのエンティティ・オブジェクトで必要になった場合でも、大きな不都合が起きることを回避できます。

注意:

この章の例を試すには、「SummitADF_Examplesワークスペースからのスタンドアロン・サンプルの実行」の説明に従って、SummitADF_Examplesワークスペースを使用します。Summit ADFスタンドアロン・サンプル・アプリケーションを取得およびインストールする方法の詳細は、「Oracle ADF用Summitサンプル・アプリケーションの設定」を参照してください。

17.2.1 フレームワーク拡張クラスの作成方法

カスタム・コードを追加してADFビジネス・コンポーネント・フレームワークの基本機能を拡張する必要がある場合は、作成するビジネス・コンポーネントの任意の主要タイプに対し、カスタムJavaクラスを有効にできます。コンポーネントのカスタム・クラスの生成は、JDeveloperの対応する概要エディタの「Java」ページで有効にします。このオプションを有効にすると、JDeveloperにより、構成可能な命名の標準に準拠したコンポーネントに関連するカスタム・クラスのJavaソース・ファイルが作成されます。このクラスの名前は、コンポーネントのXMLドキュメントに記録され、コンポーネントで必要とされるカスタムJavaコードは、このクラス内に記述できます。

フレームワーク拡張クラスを作成するには:

1. フレームワーク拡張クラスを組み込むプロジェクトを識別します。

あるプロジェクトのコンポーネントのみで使用されることが明らかな場合は、ビジネス・サービス・コンポーネントと同じプロジェクトに作成できます。あるいは、複数のFusion Webアプリケーションでフレームワーク拡張クラスを再利用する場合は、モデル・プロジェクトを別に作成して、フレームワーク拡張クラスを格納することもできます。

2. BC4Jランタイム・ライブラリがプロジェクトのライブラリ・リストに含まれることを確認します。

「プロジェクト・プロパティ」ダイアログの「ライブラリとクラスパス」ページを使用してこれを検証し、ない場合はライブラリを追加します。

3. 「アプリケーション」ウィンドウで、拡張クラスを作成するプロジェクトを右クリックし、「新規」、「Javaクラス」の順に選択します。

4. 「Javaクラスの作成」ダイアログで、「拡張」フィールドのoracle.jbo.serverパッケージから適切なフレームワーク・ベース・クラスを指定します。

図17-1は、com.yourcompany.fwkextパッケージにCustomAppModuleImplという名前のカスタム・フレームワーク拡張クラスを作成して、基本アプリケーション・モジュール・コンポーネントの機能をカスタマイズする様子を示しています。目的のベース・クラスをすばやく見つけるには、拡張フィールドの隣の「参照」ボタンを使用して、JDeveloperの「クラス・ブラウザ」を起動します。「検索」タブを使用し、クラス名の一部(ワイルドカードとして*を使用できます)を入力してクラスのリストをすばやく絞り込み、目的のクラスを見つけることができます。

図17-1 アプリケーション・モジュールのフレームワーク拡張クラスの作成

「OK」をクリックすると、ユーザーが選択したパッケージ名に対応するプロジェクトのソース・パスのディレクトリに、カスタム・フレームワーク拡張クラスが作成されます。

注意:

一部のADFビジネス・コンポーネント・クラスは、サーバー側とリモート・クライアント・バージョンの両方に存在します。たとえば、JDeveloperの「クラス・ブラウザ」を使用して、「検索」タブの「クラス名を一致」フィールドにApplicationModuleImplと入力すると、結果のリストでは、oracle.jbo.serverパッケージとoracle.jbo.client.remoteパッケージに2つのApplicationModuleImplクラスが表示されます。フレームワーク拡張クラスを作成するときは、oracle.jbo.serverパッケージのベースADFビジネス・コンポーネント・クラスを使用します。

17.2.2 フレームワーク拡張クラス作成時の処理

新しいフレームワーク拡張クラスを作成しても、アプリケーションはそれを自動的には使用しません。フレームワーク拡張クラスを使用するプロジェクトのコンポーネントを指定する必要があります。次の項では、独自のフレームワーク拡張クラスに基づいてビジネス・コンポーネントを作成する方法について説明します。

17.2.3 フレームワークの拡張ベース・クラスのカスタマイズに関する必知事項

フレームワーク拡張レイヤー・クラスを再利用可能なライブラリとしてパッケージしやすくするため、これらを使用するプロジェクトとは別のプロジェクトでこれらを作成します。

ユーザーが選択したパッケージ名(com.yourcompany.fwkextなど。それぞれがoracle.jbo.server.*パッケージをインポート)のカスタマイズされたフレームワーク・ベース・クラスの共通セットは、次のクラスで構成されます。

- public class CustomEntityImpl extends EntityImpl

- public class CustomEntityDefImpl extends EntityDefImpl

- public class CustomViewObjectImpl extends ViewObjectImpl

- public class CustomViewRowImpl extends ViewRowImpl

- public class CustomApplicationModuleImpl extends ApplicationModuleImpl

- public class CustomDBTransactionImpl extends DBTransactionImpl2

- public class CustomDatabaseTransactionFactoryImpl extends DatabaseTransactionFactory

カスタムのDBTransactionImpl2およびDatabaseTransactionFactoryクラスの使用の詳細は、「カスタム・データベース・トランザクション・クラスを使用するためのアプリケーション・モジュールの構成」を参照してください。

完璧を期すため、次のクラスについてもカスタマイズしたフレームワーク・クラスを作成する場合もありますが、これらのクラスの内容をオーバーライドすることはほとんど必要がないことに注意してください。

- public class CustomViewDefImpl extends ViewDefImpl

- public class CustomEntityCache extends EntityCache

- public class CustomApplicationModuleDefImpl extends ApplicationModuleDefImpl

17.2.4 フレームワーク拡張クラスをビジネス・コンポーネントの基礎にする方法

任意のADFビジネス・コンポーネント・ウィザードまたはエディタの「Java」ページを使用して、ビジネス・コンポーネントのベース・クラスを設定できます。

始める前に:

- 「フレームワーク拡張クラスの作成方法」の説明に従って、フレームワーク拡張クラスを作成します。

- フレームワーク拡張クラスを別のプロジェクトに作成した場合は、ビジネス・コンポーネントを含むプロジェクトの「プロジェクト・プロパティ」ダイアログの「依存性」ページで、「ビルド出力」を選択して、フレームワーク拡張プロジェクトをプロジェクト依存関係として追加します。

- フレームワーク拡張クラスをJavaアーカイブ(JAR)ファイルにパッケージする場合は、JARファイルを参照するための名前付きライブラリ定義を作成し、ビジネス・コンポーネントを含むプロジェクトのライブラリ・リストにもそのライブラリを加えます。ライブラリがない場合に作成するには、「ツール」→「ライブラリの管理」メイン・メニュー項目から開くことのできる「ライブラリの管理」ダイアログを使用します。プロジェクトのライブラリ・リストを確認または変更するには、「プロジェクト・プロパティ」ダイアログの「ライブラリ」ページを使用します。

フレームワーク・クラスを参照できることを確認した後、ビジネス・コンポーネントを作成できます。すべてのADFビジネス・コンポーネント・ウィザードおよびエディタの「Java」ページには同じ「クラスの拡張」ボタンが表示されるので、この方法を使用して、新規コンポーネントと既存コンポーネントの両方に対して目的のフレームワーク拡張ベース・クラスを選択できます。

作成するフレームワーク拡張クラスのレベルの数には固定の制限はありません。たとえば、会社で作成するすべてのFusion Webアプリケーションのすべてのアプリケーション・モジュールで使用する会社レベルのCustomAppModuleImplを作成した後、一部のプロジェクト・チームでそのフレームワーク拡張クラスをさらにカスタマイズすることが必要になったとします。そのようなチームでは、CustomAppModuleImplを拡張するSomeProjectCustomAppModuleImplクラスを作成し、プロジェクト固有のカスタム・アプリケーション・モジュールのコードをそこに含めることができます(次の例を参照)。

public class SomeProjectCustomAppModuleImpl
extends CustomAppModuleImpl {
/*
* Custom application module code specific to the
* "SomeProject" project goes here.
*/
}

その後、この特定のプロジェクトの実装の一部として作成されるアプリケーション・モジュールでは、CustomAppModuleImplのかわりにSomeProjectCustomAppModuleImplをベース・クラスとして使用できます。

フレームワーク拡張クラスに基づいてビジネス・コンポーネントを作成するには:

1. 「アプリケーション」ウィンドウで、目的のコンポーネントをダブルクリックします。

2. 概要エディタで、「Java」ナビゲーション・タブをクリックし、「Javaオプションの編集」ボタンをクリックします。

3. 「Javaオプションの選択」ダイアログで、「クラスの拡張」をクリックします。

4. 「ベース・クラスのオーバーライド」ダイアログで、オーバーライドするフレームワーク・ベース・クラスの完全修飾名を入力します。「参照」ボタンを使用して、JDeveloperクラス・ブラウザでクラスをすばやく検索することもできます。

クラス・ブラウザを使用してコンポーネントのカスタム・ベース・クラスを選択する際、使用可能なクラスが自動的にフィルタリングされて、適切なクラスのみが表示されます。たとえば、図17-2で「参照」をクリックしてアプリケーション・モジュールの「オブジェクト」のベース・クラスを選択するときは、oracle.jbo.server.ApplicationModuleクラスを直接または間接に拡張する現在のプロジェクトのライブラリ・リストで使用できるクラスのみがリストに表示されます。探しているクラスが表示されない場合は、正しくないベース・クラスを拡張しているか、または誤ったコンポーネント・クラス名をオーバーライドするように選択しています。

図17-2 新規アプリケーション・モジュールのカスタム・ベース・クラスの指定

17.2.5 すべての新規コンポーネントのフレームワーク拡張クラスを定義する方法

フレームワーク拡張クラスの特定のセットを任意のプロジェクトの標準として使用する場合、「プロジェクト・プロパティ」ダイアログを使用して各コンポーネント・タイプの優先ベース・クラスを定義できます。ベース・クラスに対するこれらの優先指定を設定しても、プロジェクト内の既存コンポーネントには影響ありませんが、コンポーネント・ウィザードが作成する新しいコンポーネントにはこの設定が使用されます。

フレームワーク拡張クラスのプロジェクト・レベルのプリファレンスを定義するには:

1. 「アプリケーション」ウィンドウで、拡張クラスを含むモデル・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「ADFビジネス・コンポーネント」→「ベース・クラス」の順に開き、「アプリケーション・モジュール・オブジェクト・クラス」の名前フィールドにベース・クラスの完全修飾名を入力します。

たとえば、プロジェクトで作成された新規アプリケーション・モジュールがデフォルトでCustomAppModuleImplクラスを使用するように指定するには、図17-3に示すように、componentNameオブジェクトのクラス名フィールドにそのクラスの完全修飾名を入力します。

図17-3 ビジネス・コンポーネントのベース・クラスに対するプロジェクト・レベルの設定

17.2.6 すべての新規プロジェクトのフレームワーク拡張クラスを定義する方法

JDeveloperで作成するそれぞれの新しいプロジェクトに同じベース・クラス設定を適用する場合、「プリファレンス」ダイアログを使用してグローバル・レベルで設定を定義できます。グローバル・レベルで指定するベース・クラスは、ビジネス・コンポーネントを含む既存のプロジェクトを変更しません。

フレームワーク拡張クラスのグローバル・プリファレンスを定義するには:

1. メイン・メニューで、「ツール」、「プリファレンス」を選択します。

2. 「プリファレンス」ダイアログのツリーで「ADFビジネス・コンポーネント」→「ベース・クラス」を開きます。

3. 「ビジネス・コンポーネント」ページのcomponentNameオブジェクトのクラス名フィールドにそのクラスの完全修飾名を入力します。

ページには、各コンポーネント・タイプに対して優先ベース・クラスを指定するために、図17-3に示すものと同じオプションが表示されます。

17.2.7 フレームワーク拡張クラスをコンポーネントの基礎にするときの処理

作成するビジネス・コンポーネントがカスタムADFビジネス・コンポーネント・フレームワーク拡張クラスを拡張するときは、選択したカスタム・クラス名を反映するように、JDeveloperがXMLドキュメントの定義を更新します。

17.2.7.1 XMLのみのコンポーネント

たとえば、CustomAppModuleImplをカスタム・アプリケーション・モジュール・ベース・クラスにして、com.yourcompany.yourappパッケージにYourServiceアプリケーション・モジュールを作成したものとします。コンポーネントをカスタムJavaファイルのないXMLのみのコンポーネントにした場合、そのXMLドキュメント(YourService.xml)は、次の例のようになります。実行時にAppModuleタグのComponentClass属性の値が読み取られて、コンポーネントを表すために使用するJavaクラスが識別されます。

<AppModule
Name="YourService"
ComponentClass="com.yourcompany.fwkext.CustomAppModuleImpl" >
<!-- etc. -->
</AppModule>

図17-4は、XMLのみのYourServiceアプリケーション・モジュールとカスタム拡張クラスの関係を示したものです。実行時には、ApplicationModuleImplクラスから基本動作を継承するCustomAppModuleImplクラスを使用します。

図17-4 拡張フレームワーク・ベース・クラスを参照するXMLのみのコンポーネント

17.2.7.2 カスタムJavaクラスのあるコンポーネント

コンポーネントでJavaクラスが必要な場合は、前の項で示したように、コンポーネント・エディタの「Java」ページを開き、適切なチェック・ボックスを選択して有効にします。たとえば、YourServerアプリケーション・モジュールに対してカスタム・アプリケーション・モジュール・クラスを有効にすると、適切なYourServiceImpl.javaクラスが作成されます。次の例に示すように、コンポーネントのXMLドキュメントも更新されて、カスタム・コンポーネント・クラスの名前が反映されます。

<AppModule
Name="YourService"
ComponentClass="com.yourcompany.yourapp.YourServiceImpl" >
<!-- etc. -->
</AppModule>

また、次の例に示すように、コンポーネントのカスタムJavaクラスのextends句も変更されて、新しいカスタム・フレームワーク・ベース・クラスが反映されます。

package com.yourcompany.yourapp;
import com.yourcompany.fwkext.CustomAppModuleImpl;
// ---------------------------------------------------------------------
// ---    File generated by Oracle ADF Business Components Design Time.
// ---    Custom code may be added to this class.
// ---    Warning: Do not modify method signatures of generated methods.
// ---------------------------------------------------------------------
public class YourServiceImpl extends CustomAppModuleImpl {
/**This is the default constructor (do not remove)   */
public YourServiceImpl() {}
// etc.
}

図17-5は、カスタムYourServiceImplクラスを含むYourServiceアプリケーション・モジュールとフレームワーク拡張クラスの関係を示したものです。実行時には、ベースApplicationModuleImplクラスを拡張するCustomAppModuleImplフレームワーク拡張クラスから基本動作を継承するYourServiceImplクラスを使用します。

図17-5 カスタマイズされたフレームワーク・ベース・クラスを拡張するカスタムJavaのあるコンポーネント

17.2.8 カスタム・コンポーネントのJavaファイルのExtends句の更新に関する必知事項

カスタムJavaクラスを含むビジネス・コンポーネントがあり、後でコンポーネントをADFビジネス・コンポーネント・フレームワーク拡張クラスに基づくように変更する場合は、「Javaオプションの選択」ダイアログの「クラスの拡張」ボタンを使用して、コンポーネントのベース・クラスを変更してください。このダイアログは、コンポーネントの概要エディタの「Java」ページから開けます。これを行うと、コンポーネントのXMLドキュメントが新しいベース・クラスを反映して更新され、さらにコンポーネントのカスタムJavaクラスのextends句が変更されます。

注意:

コンポーネント・エディタを使用せずに手動でextends句を更新すると、コンポーネントのXMLドキュメントに新しい継承が反映されず、次にエディタを開いたときに、手動で変更したextends句は、コンポーネント・エディタが正しいコンポーネント・ベース・クラスであるとする値で上書きされます。

17.2.9 フレームワーク拡張レイヤーをJARファイルにパッケージする方法

フレームワーク拡張レイヤーのクラスを含むJARファイルを作成するには、「デプロイメント・プロファイルの作成 -- JARファイル」ダイアログを使用します。これは、「新規ギャラリ」の「一般」→「デプロイメント・プロファイル」カテゴリで使用できます。

デプロイメント・プロファイルにFrameworkExtensionsのような名前を設定し、「OK」をクリックします。デフォルトでは、JARファイルにはプロジェクト内のすべてのクラス・ファイルが格納されます。これが求める結果であるため、「JARデプロイメント・プロファイルのプロパティ」ダイアログが表示されたら、「OK」をクリックして終了してかまいません。

注意:

ADFライブラリJARアーカイブ・タイプを使用してフレームワーク拡張機能レイヤーをパッケージ化しないでください。再使用可能な構成要素をパッケージ化してJDeveloperリソース・カタログで共有する場合は、ADFライブラリJARファイルを作成します。ビジネス・コンポーネントおよびADFライブラリJARアーカイブ・タイプでの作業の詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。

最後に、JARファイルを作成するには、「アプリケーション」ウィンドウでプロジェクト・ノードを右クリックし、ポップアップ・メニューから「デプロイ」→YourProfileName→「JARファイルへ」を選択します。JDeveloperの「ログ・ウィンドウ」の「デプロイ」タブに、次のようなフィードバックが表示されます。

----  Deployment started.  ----    Feb 14, 2013 1:42:39 PM
Running dependency analysis...
Wrote JAR file to ...\FrameworkExtensions\deploy\FrameworkExtensions.jar
Elapsed time for deployment:  2 seconds
----  Deployment finished.  ----    Reb 14, 2013 1:42:41 PM

17.2.10 フレームワーク拡張JARファイルのライブラリ定義の作成方法

JDeveloperは、再利用可能なコンポーネント・ライブラリで構成されるJARファイルを編成するための簡便な方法として、名前付きのライブラリを使用します。

フレームワーク拡張JARファイルのライブラリを定義するには:

1. メイン・メニューで、「ツール」、「ライブラリの管理」を選択します。

2. 「ライブラリの管理」ダイアログの「ライブラリ」タブをクリックし、「ユーザー」を選択して「新規」をクリックします。

3. 表示される「ライブラリの作成」ダイアログで、ライブラリにFramework Extension Layerという名前を設定し、「クラス・パス」ノードを選択して、「エントリの追加」をクリックします。

4. 「パス・エントリの選択」ダイアログで、フレームワーク拡張コンポーネントのクラス・ファイルを含むJARファイルを選択し、「選択」をクリックします。

5. 「ソース・パス」ノードを選択し、「エントリの追加」をクリックします。

6. 表示される「パス・エントリの選択」ダイアログで、フレームワーク拡張クラスのソース・ファイルが存在するディレクトリを選択し、「選択」をクリックします。

たとえば、JARファイルFrameworkExtensions.jarに対して..\FrameworkExtensions\srcを選択します。

7. 「OK」をクリックします。

終了すると、図17-6に示すように、新しいユーザー定義ライブラリFramework Extension Layerが表示されます。この後は、ビジネス・サービスを作成するプロジェクトのライブラリ・リストにこのライブラリを追加することで、優先使用するコンポーネント・ベース・クラスとしてカスタム・フレームワーク拡張クラスが参照されるようになります。

図17-6 フレームワーク拡張レイヤーの新しいユーザー定義ライブラリ

17.3 拡張クラスによるフレームワークの動作のカスタマイズ

フレームワーク拡張クラスで行う共通のタスクの1つは、カスタム・アプリケーション機能の実装です。フレームワーク拡張コードは特定の種類の全コンポーネントで使用されるように記述するので、これらのクラスで記述するコードでは、通常、一般的な方法でコンポーネントの属性を処理する必要があります。この要件に対処するために、ADFビジネス・コンポーネントではランタイムにコンポーネント・メタデータにアクセスできるようにするAPIを提供します。また、カスタム・メタデータのプロパティとコンポーネントまたは属性を関連付ける機能も提供されています。作成する汎用的なフレームワーク拡張コードでは、ランタイム・メタデータとカスタム・プロパティを使用して、必要な場合には特定のカスタム・プロパティが存在する場合にのみ使用される、一般的な機能を作成できます。

17.3.1 ビュー・オブジェクトおよびエンティティ・オブジェクトのランタイム・メタデータにアクセスする方法

図17-7は、ビュー・オブジェクトおよびエンティティ・オブジェクトに関するランタイム・メタデータにアクセスするためにADFビジネス・コンポーネントで提供されている3つの主要なインタフェースを示しています。ViewObjectインタフェースは、StructureDefインタフェースを拡張します。エンティティ定義を表すクラス(EntityDefImpl)も、このインタフェースを実装します。名前が示すように、StructureDefは構造とコンポーネントを定義しており、ビュー・オブジェクト行またはエンティティ行の各属性に関するランタイム・メタデータを提供するAttributeDefオブジェクトのコレクションへのアクセスを提供します。AttributeDefを使用することで、それに付随するAttributeHintsオブジェクトにアクセスし、表示ラベル、フォーマット・マスク、ツールチップなどのヒントを参照できます。

図17-7 ビュー・オブジェクトおよびエンティティ・オブジェクトで使用できるランタイム・メタデータ

17.3.2 ランタイム・メタデータを使用した汎用機能の実装方法

「ビュー・オブジェクトのデフォルト行セットを使用した操作のViewObjectインタフェース・メソッド」で説明したように、読取り専用のビューの場合、findByKey()メソッドおよびsetCurrentRowWithKey組込み操作は、setManageRowsByKey(true)をコールするようにビュー・オブジェクトのcreate()メソッドをオーバーライドした場合にのみ動作します。多くの読取り専用ビュー・オブジェクトを作成する場合、このような詳細を記憶しておくのは大変であるため、ビュー・オブジェクトのフレームワーク拡張クラスで自動化する機能の有力な候補となります。

FrameworkExtensionsプロジェクトには、アプリケーション内の全ビュー・オブジェクトに対するベース・クラスであるSummitViewObjectImplクラスが含まれるものとします。ビュー・オブジェクトに対するこのフレームワーク拡張クラスは、次の例に示すように、ViewObjectImplベース・クラスを拡張し、create()メソッドをオーバーライドして、このタスクを自動化します。実行時にビュー・オブジェクト・インスタンスを作成するとき、super.create()を呼び出してデフォルトのフレームワーク機能を実行した後、このコードは、ビュー・オブジェクトが少なくとも1つの属性がキー属性としてマークされている読取り専用のビュー・オブジェクトかどうかを検査します。そうである場合は、setManageRowsByKey(true)を呼び出します。

isReadOnlyNonEntitySQLViewWithAtLeastOneKeyAttribute()ヘルパー・メソッドは、次の条件の組合せを検査することで、ビュー・オブジェクトが読取り専用かどうかを判定します。

- isFullSql()がtrue
このメソッドは、ビュー・オブジェクトの問合せが、含まれるエンティティ・オブジェクトの慣用名に基づいて選択リストを自動的に生成するのではなく、開発者によって完全に指定されている場合は、trueを返します。

- getEntityDefs()がnull
このメソッドは、ビュー・オブジェクトのエンティティ・オブジェクト慣用名を表すEntityDefImplオブジェクトの配列を返します。nullを返す場合は、ビュー・オブジェクトにはエンティティ・オブジェクトの慣用名がありません。

次に、getAttributeDefs()メソッドが返すAttributeDef配列をループして、ビュー・オブジェクトにキー属性があるかどうかを判定します。リストのいずれかの属性定義に対してisPrimaryKey()メソッドがtrueを返す場合、そのビュー・オブジェクトにはキーがあります。

public class SummitViewObjectImpl extends ViewObjectImpl {
protected void create() {
super.create();
if (isReadOnlyNonEntitySQLViewWithAtLeastOneKeyAttribute()) {
setManageRowsByKey(true);
}
}
boolean isReadOnlyNonEntitySQLViewWithAtLeastOneKeyAttribute() {
if (getViewDef().isFullSql() && getEntityDefs() == null) {
for (AttributeDef attrDef : getAttributeDefs()) {
if (attrDef.isPrimaryKey()) {
return true;
}
}
}
return false;
}
// etc.
}

17.3.3 カスタム・プロパティによって駆動される汎用機能の実装方法

アプリケーション・モジュール、ビュー・オブジェクトおよびエンティティ・オブジェクトを作成するときに、これらのビジネス・コンポーネントの概要エディタの「一般」ナビゲーション・タブを選択し、「カスタム・プロパティ」セクションを開くと、任意のコンポーネントのカスタム・メタデータ・プロパティを定義できます。カスタム・メタデータ・プロパティは名前と値のペアであり、これを使用することで、コンポーネントに関する追加の宣言情報を、フレームワーク拡張クラスで作成する汎用コードに伝えることができます。コードでは、getProperty()メソッドを使用することで、特定のカスタム・メタデータ・プロパティの存在または値に基づいて、条件付きで汎用機能を実行できます。

たとえば、SummitViewObjectImplフレームワーク拡張クラスでは、ビュー・オブジェクトのinsertRow()メソッド(次の例を参照)をオーバーライドし、条件付きで、行セットの最後の行として表示される行を挿入しています。このフレームワーク拡張クラスを拡張するビュー・オブジェクトでInsertNewRowsAtEndという名前のカスタム・メタデータ・プロパティが定義されている場合、この汎用コードは末尾への新しい行の挿入を実行します。ビュー・オブジェクトでこのプロパティが定義されていない場合は、insertRow()のデフォルトの動作が実行されます。

public class SummitViewObjectImpl extends ViewObjectImpl {
private static final String INSERT_NEW_ROWS_AT_END = "InsertNewRowsAtEnd";
public void insertRow(Row row) {
super.insertRow(row);
if (getProperty(INSERT_NEW_ROWS_AT_END) != null) {
row.removeAndRetain();
last();
next();
getDefaultRowSet().insertRow(row);
}
}
// etc.
}

コンポーネント・レベルでカスタム・プロパティを定義するだけでなく、ビュー・オブジェクト属性、エンティティ・オブジェクト属性、およびドメインでも、プロパティを定義できます。実行時にこれらのプロパティにアクセスするには、特定の属性に対するAttributeDefインタフェースのgetProperty()メソッドを使用します。

17.3.4 属性の種類に関する必知事項

属性の名前、Java型、SQL型、および他の多くの有用な情報を提供するだけでなく、AttributeDefインタフェースのgetAttributeKind()メソッドを使用することで、属性が表す種類を判定することができます。このメソッドは、表17-1で示されているAttributeDefインタフェースのパブリック定数のいずれかに対応するbyte値を返します。

表17-1 エンティティ・オブジェクトとビュー・オブジェクトの属性の種類

パブリックAttributeDef定数

属性の種類の説明

ATTR_PERSISTENT

永続的属性

ATTR_TRANSIENT

一時的属性

ATTR_ENTITY_DERIVED

エンティティ・レベルの一時的属性にマップされるビュー・オブジェクト属性

ATTR_SQL_DERIVED

SQL計算属性

ATTR_DYNAMIC

動的属性

ATTR_ASSOCIATED_ROWITERATOR

0以上のRowsのセットのRowSetを返すアクセッサ属性

ATTR_ASSOCIATED_ROW

単一のRowを返すアクセッサ属性

17.3.5 カスタム・プロパティに関する必知事項

実行時にカスタム・プロパティの値をプログラムで設定すると便利な場合があります。この機能を実行するためのsetProperty() APIは、設計上、oracle.jboパッケージのViewObject、ApplicationModuleまたはAttributeDefインタフェースのクライアントでは利用できませんが、ビジネス・コンポーネントのカスタムJavaクラスで記述したコードでは使用できます。

17.4 汎用拡張インタフェースの作成

フレームワーク拡張クラスの作成に加えて、すべてのコンポーネントがデフォルトで実装できるカスタム・インタフェースも作成できます。クライアント・インタフェースは、たとえばUIクライアントから起動されるアプリケーション・モジュールからメソッドを公開する際に、非常に便利です。ここではアプリケーション・モジュールの例について説明しますが、カスタム拡張ビュー・オブジェクトおよびビュー行インタフェースに対しても同じ機能を作成できます。クライアント・インタフェースの詳細は、「UIクライアントへのカスタム・サービス・メソッドの公開」および「アプリケーション・モジュールのクライアント・インタフェースのプログラム的操作」も参照してください。

ApplicationModuleImplを拡張するCustomApplicationModuleImplクラスがあり、次のような2つのカスタム・メソッドを公開するものとします。

public void doFeatureOne(String arg);
public int anotherFeature(String arg);

カスタム拡張インタフェースCustomApplicationModuleを作成し、CustomApplicationModuleImplクラスでそれを実装するには、次の手順を実行します。

1. アプリケーション・モジュール・コンポーネントでグローバルに公開するメソッドを含むカスタム・インタフェースを作成します。このシナリオでは、このインタフェースは次のようになります。

package devguide.advanced.customintf.fwkext;
/**
* NOTE: This does not extend the
* ====  oracle.jbo.ApplicationModule interface.
*/
public interface CustomApplicationModule  {
public void doFeatureOne(String arg);
public int anotherFeature(String arg);
}

このインタフェースがoracle.jbo.ApplicationModuleインタフェースを拡張していないことに注意してください。

2. CustomApplicationModuleImplアプリケーション・モジュール・フレームワーク拡張クラスを変更し、この新しいCustomApplicationModuleインタフェースを実装します。

package devguide.advanced.customintf.fwkext;
import oracle.jbo.server.ApplicationModuleImpl;
public class CustomApplicationModuleImpl
extends ApplicationModuleImpl
implements CustomApplicationModule {
public void doFeatureOne(String arg) {
System.out.println(arg);
}
public int anotherFeature(String arg) {
return arg == null ? 0 : arg.length();
}
}

3. プロジェクトを再ビルドします。
ADFビジネス・コンポーネントの概要エディタでは、インタフェースが正常にコンパイルされた後にのみインタフェースを認識できます。

CustomApplicationModuleImplクラスを実装すると、新しいアプリケーション・モジュールを作成できます。このモジュールはグローバル拡張インタフェースを公開し、カスタム・フレームワーク拡張クラスに基づくものです。この作成には、アプリケーション・モジュールの概要エディタを使用します。

カスタム・アプリケーション・モジュールを作成するには:

1. 「アプリケーション」ウィンドウで、カスタム・インタフェースを作成するアプリケーション・モジュールをダブルクリックします。

たとえば、グローバル拡張インタフェースCustomApplicationModuleを公開し、CustomApplicationModuleImplフレームワーク拡張クラスに基づく新しいProductModuleアプリケーション・モジュールを作成するとします。

2. 概要エディタで、「Java」ナビゲーション・タブを選択し、「Javaオプションの編集」アイコンをクリックします。

「Javaクラス」ページには、「アプリケーション・モジュール・クラス」として識別されたアプリケーション・モジュールの既存のJavaクラスが表示されます。

デフォルトでは、作成するアプリケーション・モジュール用のJavaクラスがJDeveloperにより生成されます。ただし、この機能を無効にした場合は、「Javaクラス」セクションの「Javaオプションの編集」ボタンをクリックし、続いて「アプリケーション・モジュール・クラスの生成」を選択します。「OK」をクリックして、カスタム・インタフェースの作成元となるプロジェクトにJavaクラスを追加します。

3. 「Javaオプションの選択」ダイアログで、「クラスの拡張」をクリックします。

4. 「ベース・クラスのオーバーライド」ダイアログで、オーバーライドするフレームワーク・ベース・クラスの名前を指定して、「OK」をクリックします。

たとえば、アプリケーション・モジュールのベース・クラスとしてCustomApplicationModuleImplを選択します。

5. 概要エディタの「Javaクラス」ページで、「クライアント・インタフェース」セクションを展開し、「アプリケーション・モジュール・クライアント・インタフェースの編集」ボタンをクリックします。

6. 「クライアント・インタフェースの編集」ダイアログで、「インタフェース」ボタンをクリックします。

7. 「拡張するインタフェースの選択」ダイアログで、利用可能なリストから目的のカスタム・アプリケーション・モジュール・インタフェースを選択して「OK」をクリックします。

たとえば、CustomApplicationModuleインタフェースを「選択済」リストに移動してコンポーネントで使用できるカスタム・インタフェースの1つとなるようにします。

8. 「クライアント・インタフェースの編集」ダイアログで、「選択済」リストに、少なくとも1つのメソッドが表示されることを確認します。

注意:

グローバル拡張インタフェースのメソッドの1つを重複して選択することになるとしても、「クライアント・インタフェース」ダイアログの「選択済」リストでは少なくとも1つのメソッドを選択する必要があります。JDeveloperでカスタム・インタフェースを生成するには、どのメソッドでもかまいません。

9. 「OK」をクリックします。

「Javaクラス」ページには、「アプリケーション・モジュール・クライアント・インタフェース」として識別された、アプリケーション・モジュール用の新しいカスタム・インタフェースが表示されます。

「クライアント・インタフェースの編集」ダイアログを終了してアプリケーション・モジュールの概要エディタに戻ると、JDeveloperによりアプリケーション・モジュール・カスタム・インタフェースが生成されます。たとえば、カスタム・インタフェースProductModuleにより、次のように、ApplicationModule基本インタフェースとCustomApplicationModule拡張インタフェースの両方が自動的に拡張されます。

package devguide.advanced.customintf.common;
import devguide.advanced.customintf.fwkext.CustomApplicationModule;

import oracle.jbo.ApplicationModule;
// ---------------------------------------------------------------------
// ---    File generated by ADF Business Components Design Time.
// ---------------------------------------------------------------------
public interface ProductModule
extends CustomApplicationModule, ApplicationModule {
void doSomethingProductRelated();
}

これが済むと、クライアント・コードは、ProductModuleアプリケーション・モジュールをCustomApplicationModuleインタフェースにキャストし、それに含まれる汎用拡張メソッドを強く型付けされた方法で呼び出すことができます。

注意:

ViewObjectImplフレームワーク拡張クラスおよびViewRowImpl拡張クラスのメソッドを公開する場合も、基本的な手順は同じです。

17.5 ストアド・プロシージャとストアド・ファンクションの呼出し

ビジネス・コンポーネント用のカスタムJavaクラスにコードを記述し、データベースのストアド・プロシージャとストアド・ファンクションを呼び出すことができます。ここでは、PL/SQLパッケージのプロシージャとファンクションに基づく簡単な例をいくつか示しますが、同じ手法を使用して、パッケージの一部ではないプロシージャやファンクションを呼び出すこともできます。

次の例のPL/SQLパッケージについて考えてみます。

create or replace package invokestoredprocpkg as
procedure proc_with_no_args;
procedure proc_with_three_args(n number, d date, v varchar2);
function  func_with_three_args(n number, d date, v varchar2) return varchar2;
procedure proc_with_out_args(n number, d out date, v in out varchar2);
end invokestoredprocpkg;

以降の項では、このパッケージのプロシージャおよびファンクションの各例を呼び出す方法について説明します。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.invokingstoredprocedureパッケージを参照します。

17.5.1 引数のないストアド・プロシージャの呼出し方法

引数を受け取らないストアド・プロシージャを起動する必要がある場合は、(次の例に示すようにoracle.jbo.serverパッケージ内の)DBTransactionインタフェースのexecuteCommand()メソッドを使用できます。

// In InvokingStoredProcAppModuleImpl.java
public void callProcWithNoArgs() {
getDBTransaction().executeCommand(
"begin invokestoredprocpkg.proc_with_no_args; end;");
}

17.5.2 IN引数のみのストアド・プロシージャの呼出し方法

INモード引数のみを受け取るストアド・プロシージャ(何も指定しない場合のデフォルトのPL/SQLパラメータ・モード)を呼び出すには、JDBC PreparedStatementオブジェクトを使用する必要があります。DBTransactionインタフェースでは、現在のデータベース接続のコンテキストでこのオブジェクトを作成するためのcreatePreparedStatement()メソッドが提供されています。次の例で示すようなヘルパー・メソッドを使用することで、PreparedStatementを使用してこの種のストアド・プロシージャを起動する処理が簡単になります。重要なこととして、ヘルパー・メソッドを使用することにより、実行後にJDBC PreparedStatementを閉じるコードをカプセル化できます。このコードが実行する基本的な処理は次のとおりです。

1. 渡される文のためのJDBC PreparedStatementを作成し、PL/SQLのbegin...endブロック内にラップします。

2. バインド変数が渡された場合は、値のループ処理を行います。

3. 各バインド変数の値を文に設定します。

JDBCのバインド変数APIは1から始まる番号付けを使用するため、0から始まるforループのインデックス変数にコードで1を加えていることに注意してください。

4. 文を実行します。

5. 文を閉じます。

protected void callStoredProcedure(String stmt, Object[] bindVars) {
PreparedStatement st = null;
try {
// 1. Create a JDBC PreparedStatement for
st = getDBTransaction().createPreparedStatement("begin "+stmt+";end;",0);
if (bindVars != null) {
// 2. Loop over values for the bind variables passed in, if any
for (int z = 0; z < bindVars.length; z++) {
// 3. Set the value of each bind variable in the statement
st.setObject(z + 1, bindVars[z]);
}
}
// 4. Execute the statement
st.executeUpdate();
}
catch (SQLException e) {
throw new JboException(e);
}
finally {
if (st != null) {
try {
// 5. Close the statement
st.close();
}
catch (SQLException e) {}
}
}
}

このようなヘルパー・メソッドを使用した場合、前の例のproc_with_three_argsプロシージャのコールは次のようになります。

// In StoredProcTestModuleImpl.java
public void callProcWithThreeArgs(Number n, Date d, String v) {
callStoredProcedure("callStoredProcedure.proc_with_three_args(?,?,?)",
new Object[]{n,d,v});
}

ファンクションに渡される引数のJDBCバインド変数のプレースホルダとして疑問符が使用されていることに注意してください。JDBCは名前付きのバインド変数の使用もサポートしますが、ヘルパー・メソッドは位置でバインド変数の値を設定するのみであるため、このように単純な位置によるバインド変数を使用しても問題ありません。

17.5.3 IN引数のみのストアド・ファンクションの呼出し方法

INモードの引数のみを受け取るストアド・ファンクションの呼出しでは、文を実行した後でファンクションの結果の値にアクセスするために、JDBC CallableStatementオブジェクトを使用する必要があります。DBTransactionインタフェースでは、現在のデータベース接続のコンテキストでこのオブジェクトを作成するためのcreateCallableStatement()メソッドが提供されています。次の例に示すようにヘルパー・メソッドを使用することで、CallableStatementを使用してこの種のストアド・ファンクションを起動する処理が簡単になります。ヘルパー・メソッドは、使用するJDBC文の作成とクリーン・アップの両方をカプセル化します。

このコードが実行する基本的な処理は次のとおりです。

1. 渡される文のためのJDBC CallableStatementを作成し、PL/SQLのbegin...endブロック内にラップします。

2. 最初のバインド変数をファンクションの戻り値に登録します。

3. バインド変数が渡された場合は、値のループ処理を行います。

4. ユーザーが提供した各バインド変数の値を文に設定します。

JDBCのバインド変数APIは1から始まる番号付けを使用していて、ファンクションの戻り値は文の最初のバインド変数であるため、0から始まるforループのインデックス変数にコードで2を加えていることに注意してください。

5. 文を実行します。

6. 最初のバインド変数の値を返します。

7. 文を閉じます。

// Some constants
public static int NUMBER = Types.NUMERIC;
public static int DATE = Types.DATE;
public static int VARCHAR2 = Types.VARCHAR;

protected Object callStoredFunction(int sqlReturnType, String stmt,
Object[] bindVars) {
CallableStatement st = null;
try {
// 1. Create a JDBC CallabledStatement
st = getDBTransaction().createCallableStatement(
"begin ? := "+stmt+";end;",0);
// 2. Register the first bind variable for the return value
st.registerOutParameter(1, sqlReturnType);
if (bindVars != null) {
// 3. Loop over values for the bind variables passed in, if any
for (int z = 0; z < bindVars.length; z++) {
// 4. Set the value of user-supplied bind vars in the stmt
st.setObject(z + 2, bindVars[z]);
}
}
// 5. Set the value of user-supplied bind vars in the stmt
st.executeUpdate();
// 6. Return the value of the first bind variable
return st.getObject(1);
}
catch (SQLException e) {
throw new JboException(e);
}
finally {
if (st != null) {
try {
// 7. Close the statement
st.close();
}
catch (SQLException e) {}
}
}
}

このようなヘルパー・メソッドを使用した場合、前の例のfunc_with_three_argsプロシージャのコールは次のようになります。

// In InvokingStoredProcAppModuleImpl.java
public String callFuncWithThreeArgs(Number n, Date d, String v) {
return (String)callStoredFunction(VARCHAR2,
"invokestoredprocpkg.func_with_three_args(?,?,?)",
new Object[]{n,d,v});
}

ファンクションに渡される引数のJDBCバインド変数のプレースホルダとして疑問符が使用されていることに注意してください。JDBCは名前付きのバインド変数の使用もサポートしますが、ヘルパー・メソッドは位置でバインド変数の値を設定するのみであるため、このように単純な位置によるバインド変数を使用しても問題ありません。

17.5.4 他の種類のストアド・プロシージャの呼出し方法

OUTモードまたはIN OUTモードの引数を含むinvokestoredprocpkg.proc_with_out_argsのようなストアド・プロシージャまたはストアド・ファンクションの呼出しでは、前の項の場合と同じようにCallableStatementを使用する必要がありますが、ヘルパー・メソッドへの一般化は少し難しくなります。次の例は、invokestoredprocpkg.proc_with_out_argsプロシージャを起動するために必要なJDBCコードを示しています。

このコードが実行する基本的な処理は次のとおりです。

1. 文が呼び出すPL/SQLブロックを定義します。

2. PL/SQLブロックに対するCallableStatementを作成します。

3. OUTパラメータの位置と型を登録します。

4. INパラメータのバインド変数を設定します。

5. 文を実行します。

6. 複数の戻り値を保持するためのJavaBeanを作成します。

DateAndStringBeanクラスには、dateValおよびstringValという名前のBeanプロパティが含まれます。

7. 最初のOUTパラメータを使用して、dateValプロパティの値を設定します。

8. 2番目のOUTパラメータを使用して、stringValプロパティの値を設定します。

9. 結果を返します。

10. JDBC CallableStatementを閉じます。

public DateAndStringBean callProcWithOutArgs(Number n, String v) {
CallableStatement st = null;
try  {
// 1. Define the PL/SQL block for the statement to invoke
String stmt = "begin invokestoredprocpkg.proc_with_out_args(?,?,?); end;";
// 2. Create the CallableStatement for the PL/SQL block
st = getDBTransaction().createCallableStatement(stmt,0);
// 3. Register the positions and types of the OUT parameters
st.registerOutParameter(2,Types.DATE);
st.registerOutParameter(3,Types.VARCHAR);
// 4. Set the bind values of the IN parameters
st.setObject(1,n);
st.setObject(3,v);
// 5. Execute the statement
st.executeUpdate();
// 6. Create a bean to hold the multiple return values
DateAndStringBean result = new DateAndStringBean();
// 7. Set value of dateValue property using first OUT param
result.setDateVal(new Date(st.getDate(2)));
// 8. Set value of stringValue property using 2nd OUT param
result.setStringVal(st.getString(3));
// 9. Return the result
return result;
} catch (SQLException e)  {
throw new JboException(e);
} finally  {
if (st != null) {
try {
// 10. Close the JDBC CallableStatement
st.close();
}
catch (SQLException e) {}
}
}
}

前の例で使用されているDateAndString Beanは、次のような2つのBeanプロパティを持つ簡単なJavaBeanです。

package oracle.summit.model.invokingstoredprocedure;

import java.io.Serializable;
import oracle.jbo.domain.Date;

public class DateAndStringBean implements Serializable {
Date dateVal;
String stringVal;
public void setDateVal(Date dateVal) {this.dateVal=dateVal;}
public Date getDateVal() {return dateVal;}
public void setStringVal(String stringVal) {this.stringVal=stringVal;}
public String getStringVal() {return stringVal;}
}

注意:

カスタム・メソッドを、アプリケーション・モジュールのカスタム・サービス・インタフェースに組み込む正当な候補にできるようにするには(望ましい場合)、Beanがjava.io.Serializableインタフェースを実装する必要があります。これはマーカー・インタフェースであるため、implements Serializableキーワードを追加するのみでよく、インタフェースのメソッドの実装をコーディングする必要はありません。

17.6 現在のデータベース・トランザクションへのアクセス

ADFビジネス・コンポーネントは下位レベルのデータベース・プログラミングの詳細をすべて抽象化しているので、通常は、JDBCのConnectionオブジェクトに直接アクセスする必要はありません。実行時に、異なるWebページ・リクエスト間でまったく同じアプリケーション・モジュール・インスタンスまたはJDBC接続インスタンスをアプリケーションが使用することは保証されません。この種のプールされたサービス環境でJDBC Connectionオブジェクトへの参照を誤って保持すると、実行時に想定外の動作が発生する可能性があるため、設計として、ADFビジネス・コンポーネントにはJDBC Connectionを直接取得するAPIはありません。これは、その直接的な使用および不注意による誤用を防ぐために意図的に行われていることです。

ただし、サード・パーティのコードをADFビジネス・コンポーネントと統合する場合はこれが可能であると便利なため、次の例に示すようなヘルパー・メソッドを使用して接続にアクセスできます。

/**
* Put this method in your XXXImpl.java class where you need
* to access the current JDBC connection
*/
private Connection getCurrentConnection() throws SQLException {
/* Note that we never execute this statement, so no commit really happens */
PreparedStatement st = getDBTransaction().createPreparedStatement("commit",1);
Connection conn = st.getConnection();
st.close();
return conn;
}

注意:

上の例のヘルパー・メソッドを使用して取得したJDBC接続を、独自のコード内のどこにもキャッシュしないでください。かわりに、各接続に対してヘルパー・メソッドをコールすることで、JDBC接続に対する参照を誤って保持し、それが後で別のユーザーによる別のリクエストで使用されるのを防ぐようにします。Oracle ADFランタイム環境のプールされたサービスの性質上、保持している参照を閉じないでください。ただし、文は閉じるようにしてください。

17.7 ビジネス・コンポーネントのエラー・メッセージのカスタマイズ

カスタム・メッセージ・バンドルでエラー・コードに対してかわりのメッセージ文字列を提供することにより、組み込まれているADFビジネス・コンポーネントのエラー・メッセージをカスタマイズできます。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.custommessagesパッケージを参照します。

17.7.1 基になっているADFビジネス・コンポーネントのエラー・メッセージをカスタマイズする方法

次の組込みエラー・メッセージをカスタマイズするとします。

JBO-27014: Attribute OrderFilled in SOrd is required

Oracle Worldwide SupportからOracle Application Development Framework (Oracle ADF)のソース・コードを入手している場合は、oracle.jboパッケージのCSMessageBundle.javaファイルを見ると、このエラー・メッセージが次の行の組合せと関連していることがわかります。

public class CSMessageBundle extends CheckedListResourceBundle {
// etc.
public static final String EXC_VAL_ATTR_MANDATORY = "27014";
// etc.
private static final Object[][] sMessageStrings = {
// etc.
{EXC_VAL_ATTR_MANDATORY, "Attribute {2} in {1} is required"},
// etc.
}
}

番号付きのトークン{2}および{1}は、エラー・メッセージのプレースホルダです。この例では、実行時に、{l}はエンティティ・オブジェクトの名前に置き換えられ、{2}は属性の名前に置き換えられます。

カスタムのメッセージ・バンドル・ファイルを作成するには、次のようにします。

1. 「アプリケーション」ウィンドウで、メッセージ・バンドル・ファイルを追加するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで「ビジネス・コンポーネント」→「オプション」を選択し、「新規」をクリックします。

3. 「MessageBundleクラスの作成」ダイアログで、カスタム・メッセージ・バンドルの名前とパッケージを入力し、「OK」をクリックします。

注意:

カスタム・メッセージ・バンドル・ファイルの完全修飾名が「このプロジェクトで使用するカスタム・メッセージ・バンドル」リストに表示されない場合は、「削除」ボタンをクリックした後、「追加」ボタンをクリックして、作成した新しいメッセージ・バンドル・ファイルを追加してください。カスタム・メッセージ・バンドル・ファイルが正しく登録されると、その完全修飾クラス名がリストに表示されます(図17-8を参照)。

図17-8 リソース・メッセージ・バンドルが表示されたプロジェクト・プロパティ

4. 「プロジェクト・プロパティ」ダイアログで、「OK」をクリックして「プロジェクト・プロパティ」ダイアログを閉じ、新しいカスタム・メッセージ・バンドル・クラスをソース・エディタで開きます。

5. カスタム・メッセージ・バンドル・クラスの2次元のString配列を編集し、使用するカスタマイズしたメッセージを入力します。

次のサンプルは、名前付き属性の値を指定する必要があることをユーザーに知らせるJBO-27014エラーのエラー・メッセージ文字列をオーバーライドするカスタム・メッセージ・バンドル・クラスを示しています。2つ目のカスタム・エラー・メッセージは、ORD_ORDER_FILLED_CKという名前のデータベース制約に違反しているときに表示され、期待されるOrder Filled値をユーザーに通知します。制約のエラー・メッセージのカスタマイズの詳細は、「データベース制約違反のエラー・メッセージのカスタマイズ方法」を参照してください。

package oracle.summit.model.custommessages;

import java.util.ListResourceBundle;

public class CustomMessageBundle extends ListResourceBundle {
private static final Object[][] sMessageStrings
= new String[][] {
{"27014","You must provide a value for {2}"},
{"S_ORD_ORDER_FILLED_CK", "The order filled value must be Y or N"}
};

/* Return String Identifiers and corresponding Messages in a
* two-dimensional array.
*/
protected Object[][] getContents() {
return sMessageStrings;
}
}

17.7.2 基になっているADFビジネス・コンポーネントのエラー・メッセージをカスタマイズするときに行われる処理

このメッセージをカスタム・メッセージ・バンドル・ファイルに追加した後、Oracle ADFモデル・テスターを使用してアプリケーションをテストし、必須属性の値を空白にすると、デフォルトではなくカスタムのエラー・メッセージが表示されます。

JBO-27014: You must provide a value for Order Filled

必要なだけいくつでも、メッセージ・バンドルにメッセージを追加できます。エラー・コード・キーが組込みエラー・メッセージ・コードのいずれかと一致するメッセージは、実行時に、oracle.jbo.CSMessageBundleメッセージ・バンドルのデフォルト・メッセージのかわりに使用されます。

17.7.3 カスタマイズ・エラー・メッセージをネストされた例外として表示する方法

ADFビジネス・コンポーネントのエラー・メッセージをカスタマイズする場合、ネストされたエラー・メッセージの表示もカスタマイズする必要があります。そのためには、カスタム・エラー・ハンドラ・クラスを作成して登録する必要があります。

ビジネス・メソッドでエラーがスローされると、ADFモデル・データ・バインディング・レイヤーはエラーを遮断して、登録されたカスタム・エラー・ハンドラ・クラスを呼び出します。一般に、エラー・ハンドラ・クラスは例外を読取り可能になるように書式設定します。このプロセスで、デフォルト・エラー・ハンドラDCErrorHandlerImplは通常、最上位のJboExceptionをスキップします。このオブジェクトは他のビジネス例外のラッパーでビジネス上重要でないためです。

最上位の例外をスキップすることが、ADFビジネス・コンポーネント・エラーの場合の望ましい動作ですが、デフォルトの動作では、SQLExceptionを置換するために設定されたカスタム・メッセージがスキップされます。この状況を回避するために、ネストされた例外の各項目を表示する間、カスタム・エラー・ハンドラ・クラスはDCErrorHandlerImpl::skipException(Exception ex)をオーバーライドして、該当する例外を最終リストのユーザーに表示するかどうかを決定します。

始める前に:

アプリケーション・モジュールの知識があると役立ちます。詳細は、「ビジネス・コンポーネントのエラー・メッセージのカスタマイズ」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビジネス・コンポーネントの拡張の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「基になっているADFビジネス・コンポーネントのエラー・メッセージをカスタマイズする方法」の説明に従って、リソース・バンドルのエラー・メッセージを作成します。

プロジェクトのSQLExceptionsのカスタム・メッセージを指定するには:

1. ADFモデル・データ・バインディング・レイヤーで提供されるデフォルト・エラー・ハンドラDCErrorHandlerImplインタフェースを拡張する、エラー・ハンドラ・クラスを作成します。

2. エラー・ハンドラ・クラスで、DCErrorHandlerImpl::skipException(Exception ex)メソッドのデフォルト・エラー・ハンドラ動作を次の例に示すようにオーバーライドします。

データベース・レベルのエラー・メッセージに対して戻されるものなど、ネストされた例外の各項目を表示するには、このメソッドのオーバーライドが必須です。固有の例外タイプをチェックするロジックを実装する必要があります。また、ビジネス・シナリオに基づいて、それをリストに表示するかどうかを決定する必要があります。

3. その後、「エラー処理のカスタマイズ」の説明に従って、プロジェクトのDataBindings.cpxファイルにカスタム・エラー・ハンドラを登録できます。

次の例は、ユーザーに表示されるエラー最終リストへのSQLIntegrityConstraintViolationExceptionの表示をスキップするエラー・ハンドラのカスタム実装を示しています。一意の制約違反や外部キー制約違反などのエラーで生成される、他のデータベース・レベルのエラー・メッセージをスキップすることもできます。

package view;

import java.sql.SQLIntegrityConstraintViolationException;

import oracle.adf.model.BindingContext;
import oracle.adf.model.RegionBinding;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCErrorHandlerImpl;

import oracle.adf.model.binding.DCErrorMessage;

import oracle.jbo.DMLConstraintException;
import oracle.jbo.JboException;

public class CustomErrorHandler extends DCErrorHandlerImpl {

public CustomErrorHandler() {
super();
}

/**
* If an exception is a RowValException or a TxnValException
* and they have nested exceptions, then do not display
* it.
*/
@Override
protected boolean skipException(Exception ex) {

if (ex instanceof DMLConstraintException) {
return false;
} else if (ex instanceof SQLIntegrityConstraintViolationException) {
return true;
}
return super.skipException(ex);
}
)

17.7.4 データベース制約違反のエラー・メッセージのカスタマイズ方法

データベースに制約を設定している場合、制約の違反が発生したときに、Fusion Webアプリケーションでカスタム・エラー・メッセージをエンド・ユーザーに対して提供する場合があります。たとえば、次の例に示す次のDDL文を使用して、アプリケーションのS_ORD表にS_ORD_ORDER_FILLED_CKという制約を追加するものとします。

alter table s_ord add (
constraint S_ORD_ORDER_FILLED_CK
check (ORDER_FILLED IN ('Y', 'N'))
);

アプリケーションでカスタム・エラー・メッセージを定義するには、制約名をメッセージ・キーとして、カスタム・メッセージ・バンドルにメッセージを追加します。次の例は、前の例で定義したデータベース制約名と一致するキーS_ORD_ORDER_FILLED_CKを持つメッセージを定義した場合のCustomMessageBundle.javaクラスを示しています。

package oracle.summit.model.custommessages;

import java.util.ListResourceBundle;

public class CustomMessageBundle extends ListResourceBundle {
private static final Object[][] sMessageStrings
= new String[][] {
{"27014","You must provide a value for {2}"},
{"S_ORD_ORDER_FILLED_CK", "The order filled value must be Y or N"}
};

protected Object[][] getContents() {
return sMessageStrings;
}
}

17.7.5 カスタム制約エラー処理ルーチンの実装方法

カスタム・メッセージをデータベース制約違反に割り当てるデフォルト機能が要件を満たさない場合は、独自のカスタム制約エラー処理ルーチンを実装できます。そのためには、ADFビジネス・コンポーネント・トランザクション・クラスに対するカスタム・フレームワーク拡張クラスを作成し、実行時にそれを使用するようアプリケーション・モジュールを構成する必要があります。

17.7.5.1 カスタム・データベース・トランザクション・フレームワーク拡張クラスの作成

ADFビジネス・コンポーネント・トランザクション用のカスタム・フレームワーク拡張クラスを記述するには、次の例で示すCustomDBTransactionImplのようなクラスを作成します。この例では、スローされるDMLConstraintExceptionエラーに対するカスタム処理を実行するため、トランザクション・オブジェクトのpostChanges()メソッドをオーバーライドして、super.postChanges()の呼び出しをtry/catchブロックでラップしています。この簡単な例で実行しているカスタム処理は、ex.setExceptions(null)を呼び出して、DMLConstraintExceptionが保持している可能性のあるネストされた詳細な例外をクリアすることのみです。かわりに、アプリケーションで必要な他の種類のカスタム例外処理を実行できます。たとえば、カスタム例外がJboExceptionを直接または間接に拡張している場合は、カスタム例外をスローできます。

package oracle.summit.model.custommessages;

import oracle.jbo.DMLConstraintException;
import oracle.jbo.server.DBTransactionImpl2;
import oracle.jbo.server.TransactionEvent;

public class CustomDBTransactionImpl  extends DBTransactionImpl2 {
public void postChanges(TransactionEvent te) {
try {
super.postChanges(te);
}
/*
* Catch the DML constraint exception
* and perform custom error handling here
*/
catch (DMLConstraintException ex) {
ex.setExceptions(null);
throw ex;
}
}
}

17.7.5.2 カスタム・データベース・トランザクション・クラスを使用するためのアプリケーション・モジュールの構成

アプリケーション・モジュールで実行時にカスタム・データベース・トランザクション・クラスを使用するには、次の手順を実行する必要があります。

1. カスタマイズしたトランザクション・クラスのインスタンスを返すようにcreate()メソッドをオーバーライドするDatabaseTransactionFactoryクラスのカスタム実装を提供します。

2. TransactionFactoryプロパティの値に、このカスタム・トランザクション・ファクトリ・クラスの完全修飾名を構成します。

次の例は、これを行うカスタム・データベース・トランザクション・ファクトリ・クラスを示しています。フレームワークがデータベース・トランザクション・ファクトリでcreate()メソッドを呼び出すと、このクラスはCustomDBTransactionImplクラスの新しいインスタンスを返します。

package oracle.summit.model.custommessages;

import oracle.jbo.server.DBTransactionImpl2;
import oracle.jbo.server.DatabaseTransactionFactory;

public class CustomDatabaseTransactionFactory
extends DatabaseTransactionFactory {
public CustomDatabaseTransactionFactory() {
}
/**
* Return an instance of our custom CustomDBTransactionImpl class
* instead of the default implementation.
*
* @return instance of custom CustomDBTransactionImpl implementation.
*/
public DBTransactionImpl2 create() {
return new CustomDBTransactionImpl();
}
}

これを実行するには、アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタの「プロパティ」タブを使用して、TransactionFactoryプロパティに値oracle.summit.model.custommessages.CustomDatabaseTransactionFactoryを割り当てます。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。アプリケーション・モジュール構成の概要エディタで「プロパティ」タブを選択し、「プロパティの追加」をクリックして「プロパティの追加」ダイアログから次のプロパティを選択し、「OK」をクリックします。

- TransactionFactory

次に、「プロパティ」リストで、TransactionFactoryプロパティの値を入力します。

- TransactionFactory = oracle.summit.model.custommessages.CustomDatabaseTransactionFactory

この構成を使用してアプリケーションを実行すると、カスタム・トランザクション・クラスが使用されます。

17.8 継承を使用する拡張コンポーネントの作成

新しいビジネス・コンポーネントを作成するたびに、必要に応じて、既存のものを拡張してオリジナルのカスタマイズ・バージョンを作成できます。図17-9に示すように、ProductViewExビュー・オブジェクトでは、ProductViewビュー・オブジェクトを拡張してbv_ProductNameという名前の名前付きバインド変数が追加され、このバインド変数を参照するようにWHERE句がカスタマイズされています。

図17-9 別のコンポーネントを拡張できるADFビジネス・コンポーネント

図ではビュー・オブジェクトの例が示されていますが、このコンポーネント継承機能はすべての種類のコンポーネントで使用できます。あるコンポーネントが別のコンポーネントを拡張する場合、拡張されたコンポーネントは親からすべてのメタデータと動作を継承します。拡張されたコンポーネントでは、メタデータとJavaコードの両方を使用して、新しい機能を追加したり、親コンポーネントの既存機能をカスタマイズしたりできます。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのoracle.summit.model.extendパッケージを参照します。

17.8.1 別のコンポーネントを拡張するコンポーネントの作成方法

拡張コンポーネントを作成するには、作成するコンポーネントの種類に対する「新規ギャラリ」のコンポーネント・ウィザードを使用します。たとえば、拡張ビュー・オブジェクトを作成するには、「ビュー・オブジェクトの作成」ウィザードを使用します。ウィザードの「名前」ページで、新しいコンポーネントの名前とパッケージを指定することに加えて、拡張するコンポーネントの完全修飾名を「拡張」フィールドで指定します。リストからコンポーネント名を選択するには、「拡張」フィールドの隣の「参照」ボタンを使用します。その後は、ウィザードの残りのパネルを使用して、通常の方法で拡張コンポーネントの作成を続けます。

17.8.2 コンポーネントを作成後に拡張する方法

拡張コンポーネントを定義した後で、拡張コンポーネントが継承している親コンポーネントを変更できます。コンポーネントの概要エディタをこの目的に使用できます。

作成後に親コンポーネントを変更するには:

1. 「アプリケーション」ウィンドウで、コンポーネントをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックし、「拡張対象」フィールドの横にある「オブジェクト拡張対象をリファクタします。」ボタンをクリックします。

3. 「親の選択」ダイアログで、パッケージ・リストから拡張する目的のコンポーネントを選択して、「OK」をクリックします。

どの親からも継承しないように拡張コンポーネントを変更するには、「親の選択」ダイアログの「なし」チェック・ボックスを選択します。これは、この目的のためのコンポーネント削除および再作成と同じ結果になります。

17.8.3 別のコンポーネントを拡張するコンポーネントの作成時の処理

ADFビジネス・コンポーネント・データ・モデル・プロジェクトで作成するビジネス・コンポーネントは、XMLドキュメントとオプションのJavaクラスで構成されます。別のコンポーネントを拡張するコンポーネントを作成すると、JDeveloperは、拡張されたコンポーネントのXMLドキュメントと生成されるJavaコードの両方に、このコンポーネント継承を反映します。

17.8.3.1 親コンポーネントから継承された拡張コンポーネントの属性

拡張コンポーネントを作成すると、拡張コンポーネントは親コンポーネントから属性および属性プロパティを継承します。継承される属性は拡張コンポーネントに定義されておらず、親コンポーネントから渡されるだけであるため、この接続が維持されます。したがって、拡張コンポーネントの作成後に親コンポーネントの属性を変更した場合、拡張コンポーネントの属性はその変更を反映します。

たとえば、ProductViewビュー・オブジェクトを拡張するProductViewEx拡張ビュー・オブジェクトを作成するとします。次に、ProductView親ビュー・オブジェクトでShortDesc属性の「表示」UIヒントを「非表示」に設定することに決めます。この操作を行うと、ShortDesc属性がProductViewEx拡張ビュー・オブジェクトでも非表示になります。

ただし、拡張オブジェクトで属性をオーバーライドした場合、オーバーライドされた属性は拡張オブジェクトに再定義されるため、この接続は切断されます。これにより、親オブジェクトまたはその親オブジェクトから導出された他のオブジェクトに影響を与えずに、拡張オブジェクトに変更を加えることができます。オーバーライドは選択した属性にのみ適用され、他の継承された属性は影響を受けないことに注意してください。

たとえば、ProductViewビュー・オブジェクトと2つの拡張ビュー・オブジェクトProductViewEx1およびProductViewEx2があるとします。ProductView親ビュー・オブジェクトでShortDesc属性の「表示」UIヒントを「非表示」に設定した後、ProductViewEx1拡張ビュー・オブジェクトでこれを「表示」に設定することに決めます。ProductViewEx1でShortDescをオーバーライドし、「表示」UIヒントを「表示」に設定すると、変更はProductViewEx1拡張ビュー・オブジェクトにのみ反映され、ProductViewEx2拡張ビュー・オブジェクトまたはProductView親ビュー・オブジェクトには反映されません。

17.8.3.2 拡張コンポーネントのXMLディスクリプタに追加される属性

JDeveloperは、新しいコンポーネントのXMLドキュメントのルート・コンポーネント要素にExtends属性を追加することで、親コンポーネントの名前を記録します。追加された新しい宣言機能、または親コンポーネントの定義のオーバーライドされた部分は、拡張コンポーネントのXMLドキュメントに記述されます。これに対し、親コンポーネントから純粋に継承されたメタデータは、拡張コンポーネントでは繰り返し記述されません。

次の例は、ProductViewExビュー・オブジェクトのProductViewEx.xml XMLドキュメントを示しています。ViewObject要素のExtends属性、拡張されたビュー・オブジェクトで追加されたバインド変数に関連するVariable要素、およびtheProductNameバインド変数を参照するように変更されたWHERE句のWhere属性のオーバーライドされた値に注意してください。

<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="ProductViewEx"
InheritPersonalization="true"
BindingStyle="OracleName"
CustomQuery="false"
ComponentClass="oracle.summit.model.extend.ProductViewExImpl"
RowClass="oracle.summit.model.extend.ProductViewExRowImpl"
RowInterface="oracle.summit.model.extend.common.ProductViewExRow"
ClientRowProxyName="oracle.summit.model.extend.client.ProductViewExRowClient"
ComponentInterface="oracle.summit.model.extend.common.ProductViewEx"
ClientProxyName="oracle.summit.model.extend.client.ProductViewExClient"
Extends="oracle.summit.model.extend.ProductView"
Where="UPPER(PRODUCT_NAME) LIKE UPPER(:theProductName)||'%'"
...
<Variable
Name="bv_ProductName"
Kind="where"
Type="java.lang.String"/>
...
</ViewObject>

17.8.3.3 拡張コンポーネントに生成されたJavaクラス

拡張コンポーネントでカスタムJavaコードを有効にすると、親コンポーネントの各Javaクラスを拡張するためのJavaクラスが自動的に生成されます。これにより、拡張コンポーネントでは、必要に応じて、親コンポーネントのプログラム的な動作のすべての面をオーバーライドできます。親コンポーネントが、独自のカスタムJavaクラスを持たないXMLのみのコンポーネントである場合は、拡張コンポーネントのJavaクラスは、親が実行時に使用するベースJavaクラスを拡張します。これは、oracle.jbo.serverパッケージのデフォルトのADFビジネス・コンポーネント・フレームワーク・クラス、または親コンポーネントの「拡張」ダイアログで指定されている場合は独自のフレームワーク拡張クラスなどになります。

さらに、拡張コンポーネントがアプリケーション・モジュールまたはビュー・オブジェクトで、クライアント・インタフェースを有効にしてある場合は、拡張コンポーネントのクライアント・インタフェースが自動的に生成され、親コンポーネントの各クライアント・インタフェースが拡張されます。親コンポーネントのクライアント・インタフェースが存在しない場合は、拡張コンポーネントのクライアント・インタフェースは、oracle.jboパッケージの適切なベースADFビジネス・コンポーネント・インタフェースを直接拡張します。

17.8.4 コンポーネントの拡張に関する必知事項

17.8.4.1 拡張コンポーネントの親のクラスとインタフェース

拡張コンポーネントは親のカスタマイズ・バージョンであるため、親コンポーネントのJavaクラスまたはクライアント・インタフェースで動作するように作成したコードは、親コンポーネントまたはそのカスタマイズ・バージョンで問題なく動作します。

たとえば、次のようなカスタムJavaクラスとクライアント・インタフェースを含むベースProductViewビュー・オブジェクトがあるものとします。

- クラスProductViewImpl

- 行クラスProductViewRowImpl

- クライアント・インタフェースProductView

- 行クライアント・インタフェースProductViewRow

ProductViewを拡張するProductViewExビュー・オブジェクトを作成した場合、ベース・コンポーネントのクラスとインタフェースを使用して、ProductViewとProductViewExの両方を操作できます。

次の例は、ProductView、ProductViewRow、ProductViewExおよびProductViewExRowの各クライアント・インタフェースで動作するテスト用のクライアント・プログラムです。この例については、次のことに注意してください。

1. 親のProductViewインタフェースを、それを拡張するProductViewExビュー・オブジェクトを処理するために使用できます。

2. 別の方法として、ProductViewExビュー・オブジェクトのインスタンスを、独自のさらに限定的なProductViewExクライアント・インタフェースにキャストすることもできます。

3. キャストしてProductViewExRowインタフェースに固有のメソッドを呼び出す前に、本当に行ProductViewRowがより限定的なProductViewExRowのインスタンスであるかどうかをテストできます。

package oracle.summit.model.extend;

import oracle.jbo.ApplicationModule;
import oracle.jbo.AttributeDef;
import oracle.jbo.Row;
import oracle.jbo.StructureDef;
import oracle.jbo.ValidationException;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;

import oracle.summit.model.extend.common.ProductView;
import oracle.summit.model.extend.common.ProductViewEx;
import oracle.summit.model.extend.common.ProductViewExRow;
import oracle.summit.model.extend.common.ProductViewRow;

public class TestClient {
public static void main(String[] args) {
String        amDef = "oracle.summit.model.extend.AppModule";
String        config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
ProductView products = (ProductView)am.findViewObject("ProductView1");
products.executeQuery();
ProductViewRow product = (ProductViewRow)products.first();
printAllAttributes(products,product);
testSomethingOnProductsRow(product);
products = (ProductView)am.findViewObject("ProductViewEx1");
ProductViewEx productsByName = (ProductViewEx)products;
productsByName.setbv_ProductName("bunny");
productsByName.executeQuery();
product = (ProductViewRow)productsByName.first();
printAllAttributes(productsByName,product);
testSomethingOnProductsRow(product);
am.getTransaction().rollback();
Configuration.releaseRootApplicationModule(am,true);
}
private static void testSomethingOnProductsRow(ProductViewRow product) {
try {
if (product instanceof ProductViewExRow) {
ProductViewExRow productByName = (ProductViewExRow)product;
productByName.someExtraFeature("Test");
}
product.setName("Q");
System.out.println("Setting the Name attribute to 'Q' succeeded.");
}
catch (ValidationException v) {
System.out.println(v.getLocalizedMessage());
}
}
private static void printAllAttributes(ViewObject vo, Row r) {
String viewObjName = vo.getName();
System.out.println("Printing attribute for a row in VO '"+
viewObjName+"'");
StructureDef def = r.getStructureDef();
StringBuilder sb = new StringBuilder();
int numAttrs = def.getAttributeCount();
AttributeDef[] attrDefs = def.getAttributeDefs();
for (int z = 0; z < numAttrs; z++) {
Object value = r.getAttribute(z);
sb.append(z > 0 ? "  " : "")
.append(attrDefs[z].getName())
.append("=")
.append(value == null ? "<null>" : value)
.append(z < numAttrs - 1 ? "\n" : "");
}
System.out.println(sb.toString());
}
}

テスト・クライアントを実行すると、次のような結果が生成されます。

Printing attribute for a row in VO 'ProductView1'
Id=10011
Name=Bunny Boot
ShortDesc=Beginners ski boot
LongtextId=518
ImageId=1001
SuggestedWhlslPrice=150
WhlslUnits=<null>
SomeValue=I am from the Product Impl Class
Setting the Name attribute to 'Q' succeeded.

注意:

この例では、ProductViewはProductエンティティ・オブジェクトに基づくエンティティ・ベースのビュー・オブジェクトです。Productエンティティ・オブジェクトには、一時的属性SomeValueが含まれ、I am the Product classという文字列を返します。この一時的属性が含まれる理由の詳細は、「提供されるアプリケーションでの拡張コンポーネントの置換え」の例を参照してください。

17.8.4.2 拡張コンポーネントに生成されたクラス

拡張コンポーネントを作成するとき、拡張コンポーネントのウィザードの「Java」ページにある「クラスの拡張」ボタンは無効になります。また、アプリケーション・モジュール・エディタの「Java」ページで、「Javaオプションの編集」ボタンをクリックすると、「Java」ダイアログの「クラスの拡張」ボタンは無効として表示されます。これは、JDeveloperが親コンポーネントの適切なクラスを自動的に拡張するため、別のクラスをユーザーが選択できるようにしても意味がないためです。

17.8.4.3 ビジネス・コンポーネントのタイプ

エンティティ・オブジェクト

拡張エンティティ・オブジェクトを作成するときは、新しい属性、新しいアソシエーション、新しいバリデータ、および新しいカスタム・コードを導入できます。既存の属性の特定の宣言的部分、および親コンポーネントのクラスのメソッドをオーバーライドできます。拡張エンティティ・オブジェクトから、ベース・クラスが拡張エンティティ・オブジェクトから定義する属性を削除することはできません。

ビュー・オブジェクト

拡張ビュー・オブジェクトを作成するときは、新しい属性、新しいビュー・リンク、新しいバインド変数および新しいカスタム・コードを導入できます。既存の属性の特定の宣言的部分、および親コンポーネントのクラスのメソッドをオーバーライドできます。拡張ビュー・オブジェクトから、ベース・クラスが定義する属性を削除することはできません。

アプリケーション・モジュール

拡張アプリケーション・モジュールを作成するときは、新しいビュー・オブジェクト・インスタンスまたは新しいネストされたアプリケーション・モジュール・インスタンス、および新しいカスタム・コードを導入できます。拡張ビュー・オブジェクトから、親のコンポーネント・クラスのメソッドをオーバーライドすることもできます。

17.8.4.4 拡張コンポーネントの新しい属性

拡張エンティティ・オブジェクトまたはビュー・オブジェクトで新しい属性を追加する場合、属性索引番号は親コンポーネントを規準にして計算されます。たとえば、「拡張コンポーネントの親のクラスとインタフェース」で示されているProductViewビュー・オブジェクトについて考えます。カスタム・ビュー行クラスを有効にする場合、ProductViewRowImpl.javaクラスで定義される次のような属性索引定数が含まれる場合があります。

public class ProductViewRowImpl extends SummitViewRowImpl
implements ProductViewRow {

/**
* AttributesEnum: generated enum for identifying attributes and accessors.
* Do not modify.
*/
public enum AttributesEnum {...}

public static final int ID = AttributesEnum.Id.index();
public static final int NAME = AttributesEnum.Name.index();
public static final int SHORTDESC = AttributesEnum.ShortDesc.index();
public static final int LONGTEXTID = AttributesEnum.LongtextId.index();
public static final int IMAGEID = AttributesEnum.ImageId.index();
public static final int SUGGESTEDWHLSLPRICE =
AttributesEnum.SuggestedWhlslPrice.index();
public static final int WHLSLUNITS = AttributesEnum.WhlslUnits.index();
public static final int SOMEVALUE = AttributesEnum.SomeValue.index();
//etc.
}

ProductViewExのような拡張ビュー・オブジェクトを作成するとき、そのビュー・オブジェクトでSomeExtraAttrのような属性を追加し、カスタム・ビュー行クラスを有効にした場合、その属性定数は、親コンポーネントの属性定数の最大値を規準にして計算されます。

public class ProductViewExRowImpl extends ProductViewRowImpl
implements ProductViewExRow {

public static final int MAXUSAGECONST = 1;

public enum AttributesEnum {
SomeExtraAttr {
public Object get(ProductViewExRowImpl obj) {
return obj.getSomeExtraAttr();
}

public void put(ProductViewExRowImpl obj, Object value) {
obj.setAttributeInternal(index(), value);
}
}

private static AttributesEnum[] vals = null;
private static int firstIndex =
ViewDefImpl.getMaxAttrConst("oracle.summit.model.extend.ProductView");

public abstract Object get(ProductViewExRowImpl object);

public abstract void put(ProductViewExRowImpl object, Object value);

public int index() {
return AttributesEnum.firstIndex() + ordinal();
}

public static int firstIndex() {
return firstIndex;
}

public static int count() {
return AttributesEnum.firstIndex() +
AttributesEnum.staticValues().length;
}

public static AttributesEnum[] staticValues() {
if (vals == null) {
vals = AttributesEnum.values();
}
return vals;
}
}
public static final int SOMEEXTRAATTR = AttributesEnum.SomeExtraAttr.index();
...
}

17.9 提供されるアプリケーションでの拡張コンポーネントの置換え

ソリューションの各クライアントがオンサイトでカスタマイズする必要のあるパッケージ化されたアプリケーションを配布する場合のために、ADFビジネス・コンポーネントでは、この作業を簡単にする便利な機能が提供されています。

注意:

この項の例では、SummitADF_Examplesアプリケーション・ワークスペースのExtendedProjectプロジェクトを参照します。

通常、オンサイトでのアプリケーションのカスタマイズは、配布されたアプリケーションのソース・コードを直接変更することで行います。この方法の短所が明らかになるのは、元のアプリケーションのパッチや新機能リリースをクライアントに提供するときです。基になるアプリケーションのソース・コードに適用されていたカスタマイズは、パッチまたは更新を行った後のアプリケーションに、わざわざ適用しなおす必要があります。この方法では、アプリケーションのカスタマイズやメンテナンスに費用がかかるだけでなく、以前のカスタマイズを新しいリリースに適用しなおすときの人為的エラーにより不具合が発生する可能性があります。

ADFビジネス・コンポーネントが提供する優れたコンポーネント・ベースの方法を使用してアプリケーションをカスタマイズすると、基になっているアプリケーションのソース・コードを変更する必要はなく、ソース・コードにアクセスする必要さえありません。提供されたアプリケーションのカスタマイズは、次の方法で行います。

1. 基になるアプリケーションのコンポーネントのパッケージを、新しいプロジェクトにインポートします。

2. アプリケーションのカスタマイズを適用する新しいコンポーネントを作成し、必要に応じて基のアプリケーションの適切な親コンポーネントを拡張します。

3. グローバルなコンポーネント置換のリストを定義し、カスタマイズしたコンポーネントの名前を設定して、基になるアプリケーションの適切な親コンポーネントを置き換えます。

ユーザーが定義されたグローバル・コンポーネント置換リストを使用し、配布されたアプリケーションを実行すると、配布されたアプリケーションは、コードを変更することなく、カスタマイズされたアプリケーション・コンポーネントを使用します。元のアプリケーションのパッチまたは更新バージョンが提供されると、次にアプリケーションを再起動するときにコンポーネントのカスタマイズが更新バージョンに適用されるので、カスタマイズを適用しなおす必要はありません。

17.9.1 拡張コンポーネントの置換方法

グローバルなコンポーネント置換を定義するには、基になるアプリケーションからインポートしたコンポーネントに基づいて拡張コンポーネントを作成したプロジェクトの、「プロジェクト・プロパティ」ダイアログを使用します。

注意:

基になるアプリケーションのコンポーネントのうち、基のコンポーネントを直接または間接に継承する拡張コンポーネントがあるもののみを置換できます。

拡張コンポーネントを置換するには:

1. 「アプリケーション」ウィンドウで、拡張コンポーネントを追加するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「ADFビジネス・コンポーネント」→「置換」を選択し、「置換」リストでベース・アプリケーションのコンポーネントを選択します。

3. 「置換する対象」リストで、置き換えるカスタマイズした拡張コンポーネントを選択します。

4. 「追加」をクリックします。

たとえば、ベース・ビュー・オブジェクトProductsを拡張するパッケージでビュー・オブジェクトCustomizedProductが作成されているとします。レガシーProductsビュー・オブジェクトのCustomizedProductsビュー・オブジェクトを置換するには、これらビュー・オブジェクトを図17-10のように選択して、コンポーネント置換を定義する必要があります。

図17-10 ビジネス・コンポーネントの置換の定義

17.9.2 置換時の処理

ExtendedProjectという名前のプロジェクトでグローバル・コンポーネント置換リストを定義すると、置換リストは、ソース・パスのルート・ディレクトリにあるExtendedProject.jpxに保存されます。

次の例に示すように、このファイルには、置換されるコンポーネントごとに1つずつ、Substitute要素が含まれます。

<JboProject
Name="ExtendedProject"
SeparateXMLFiles="true"
PackageName="oracle.summit.model.extended" >
<Containee
Name="custompackage"
FullName="oracle.summit.model.custompackage"
ObjectType="JboPackage" >
</Containee>
<Containee
Name="extended"
FullName="oracle.summit.model.extended"
ObjectType="JboPackage" >
</Containee>
<AppContainee
Name="Model"
FullName="oracle.summit.model.Model"
ObjectType="JboProject">
<Substitutes>
<Substitute
OldName="oracle.summit.model.extended.ProductEx"
NewName="oracle.summit.model.custompackage.CustomProduct" />
</Substitutes>
</JboProject>

17.9.3 基のアプリケーションで置換コンポーネントを有効化する方法

置換されたコンポーネントを元のアプリケーションが使用するよう指定するには、Javaシステム・プロパティFactory-Substitution-Listを定義し、その値を、置換リストが格納されている*.jpxファイルを持つプロジェクトの名前に設定します。値には、*.jprまたは*.jpx拡張子を除いたプロジェクト名のみを設定します。

たとえば、「拡張コンポーネントの親のクラスとインタフェース」で説明されている、Productエンティティ・オブジェクトとProductViewビュー・オブジェクトをカスタマイズする簡単な例について考えます。カスタマイズのため、次のようにしてExtendedProjectという名前の新しいオブジェクトを作成するものとします。

- ベース・コンポーネントを含むJARファイルに対するライブラリを定義します。

- ProductおよびProductViewを含むパッケージをインポートします。

- CustomizeProductおよびCustomizeProductViewという個別のパッケージ名で、新しい拡張コンポーネントを作成します。

- 拡張コンポーネントを使用するためのコンポーネント置換リストを定義します。

拡張コンポーネントを作成するときは次のようにします。

- ProductViewExビュー・オブジェクトにSomeExtraAttributeという名前の新しいビュー属性を追加します。

- 新しい検証ルールをCustomizedProductエンティティ・オブジェクトに追加し、Qという製品名は使用できないようにします。

- CustomizedProduct.javaクラスのgetChecksum()メソッドをオーバーライドし、I am the CustomizedProduct Classを返すようにします。

Factory-Substitution-List Javaシステム・プロパティを、値がExtendsAndSubstitutesに設定されるよう定義し、「拡張コンポーネントの親のクラスとインタフェース」で説明するものとまったく同じテスト用のクライアント・クラスを実行すると、サンプルの出力は、置換されたコンポーネントの使用を反映して変化します。

第III部 ADFモデル・レイヤーの使用

この部では、開発者がFusion WebアプリケーションのADFモデル・レイヤーで実行できるタスクについて説明します。

第III部は、次の章で構成されています。

- Fusion WebアプリケーションでのADFモデルの使用

- ADFモデル・レイヤーでの検証の使用

- プレースホルダ・データ・コントロールによるページの設計

- ADF RESTデータ・コントロールを使用したRESTful Webサービスの使用方法

- ADF RESTフレームワークを使用したRESTful Webサービスの使用方法

18 Fusion WebアプリケーションでのADFモデルの使用

この章では、Fusion WebアプリケーションでADFデータ・コントロールを使用して、ADFビジネス・コンポーネントでモデル化されたデータからデータバインドされたページを作成するために使用するJDeveloperツールについて説明します。特に、ADFアプリケーション・モジュールのデータ・モデルとADFビジネス・コンポーネント・クライアント・インタフェース・メソッドが、設計時にドラッグ・アンド・ドロップによるデータ・バインディング用にどのように表示されるかについて説明します。また、実行時にADFデータ・コントロールを使用してADFモデル・データバインディング・レイヤーによりそれらにアクセスする方法についても説明します。

この章の内容は次のとおりです。

- Fusion WebアプリケーションでのADFモデルの使用

- 追加機能

- ADFデータ・コントロールを使用したアプリケーション・モジュールの公開

- データ・コントロール・パネルの使用

- DataBindings.cpxファイルの使用

- ADFバインディング・フィルタの構成

- ページ定義ファイルの処理

- ADFデータ・バインディングのEL式の作成

- 単純なUIの最初の開発の使用

18.1 Fusion WebアプリケーションでのADFモデルの使用

ADFモデルによって、ユーザー・インタフェース・テクノロジとビジネス・サービス実装の分離を可能にする概念(データ・コントロールと宣言的ADFバインディング)が実装されます。

ADFモデルは、アプリケーションのデータ・モデル、ビジュアル・インタフェースおよびアプリケーション・フローがすべて明確に区別される、MVC (Model-View-Controller)デザイン・パターンに基づいて構築されます。図18-1に示すように、ADFモデルは、通常アプリケーションのモデル・レイヤーとして機能するビジネス・サービス上に抽象レイヤーを提供します。MVCアーキテクチャ内でのADFモデルの位置の詳細は、『Oracle Application Development Frameworkの理解』のアプリケーションのモデル・レイヤーの抽象化に関する項を参照してください。

図18-1 ADFアーキテクチャ内のADFモデル

18.1.1 ADFデータ・コントロールについて

ADFデータ・コントロールでは、関連するプロパティ、メソッド、タイプの情報を含め、サービスの操作とデータ・コレクションを表す標準のメタデータ・インタフェースを使用してビジネス・サービスの実装技術を抽象化します。ADFビジネス・コンポーネントを使用するアプリケーションでは、アプリケーション・モジュール作成時にデータ・コントロールが自動的に作成され、データ・コントロールにはアプリケーション・モジュールの全機能が含まれます。開発者は、JDeveloperの「データ・コントロール」パネルに表示されたデータ・コントロールの表現を使用して、アプリケーション・モジュールに自動的にバインドされるUIコンポーネントを作成できます。実行時に、ADFモデル・レイヤーによって、適切なXMLファイルからデータ・コントロールおよびバインディングを記述した情報が読み取られ、ユーザー・インタフェースとビジネス・サービスの双方向の結合が実装されます。

ADFビジネス・コンポーネント・アプリケーション・モジュールを作成して、そのアプリケーション・モジュールのデータ・モデルに対してビュー・オブジェクトを追加すると、データ・コントロールが自動的に作成されます。

EJBセッションBean、プレーンJavaオブジェクトおよびWebサービスなど、異なるタイプのビジネス・サービスに基づいてデータ・コントロールを作成することもできます。これらの種類のデータ・コントロールの作業の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』を参照してください。

注意:

ADF Modelレイヤーを使用してビジネス・サービスへのアクセスを実行すると、ビューとビジネス・サービスは同期を維持します。たとえば、データ・コントロール参照をアプリケーション・モジュール・インスタンスにクラス・キャストして、メソッドを直接コールすることにより、アプリケーション・モジュール上でメソッドをコールできますが、モデル・レイヤーがバイパスされ、変更が行われた場合でもモデル・レイヤーでは認識されなくなります。

18.1.2 JSFデータ・バインディングについて

ADFの宣言的なバインディングは、JSFデータ・バインディングに基づいています。JSFでは、表示または修正(あるいはその両方)する情報にバインディングするために、単純な式言語(EL)を使用します(詳細は、http://www.oracle.com/technetwork/java/unifiedel-139263.htmlを参照してください)。たとえば、特定のユーザー名を参照する#{userInfoBean.principalName}、ユーザー名がSKINGかどうかを評価する#{userInfoBean.principalName eq 'SKING'}などの式があります。汎用の式評価機能により、実行時にそれぞれString、boolean値が戻されるため、コードを必要とせずに、個々のオブジェクトとそのプロパティに自動的にアクセスできます。

特定のJSF UIコンポーネントの値は、実行時にそのvalue属性によって決定されます。コンポーネントにはその値として静的テキストを割り当てることができますが、通常、value属性には、表示データを決定するために実行時インフラストラクチャにより評価されるEL式のバインディングが含まれます。たとえば、現在ログイン中のユーザーの名前を表示するoutputTextコンポーネントには、value属性に#{userInfoBean.principalName}という式を設定できます。EL式を使用してコンポーネントの任意の属性に値を割り当てることができるため、データ駆動型の動的なユーザー・インタフェースを簡単に作成できます。たとえば、UIコンポーネントのrendered属性に#{userInfoBean.prinicpalName !=null}などのブール値の式を使用すると、ユーザーがログインしていないときにコンポーネントを非表示にできます。userInfoBeanの現在のインスタンスにプリンシパル名がない場合、rendered属性はfalseと評価され、コンポーネントはページに表示されなくなります。

18.1.3 ADFデータ・バインディングについて

ADFデータ・バインディングは、ADFデータ・コントロールに宣言的にバインドできるようにすることにより、JSFデータ・バインディングを拡張します。通常のJSFアプリケーションでは、userInfoBeanオブジェクトのようなオブジェクトはマネージドBeanとして作成します。JSFランタイムでは、EL式でBeanを最初に参照した際に、Beanのオンデマンドのインスタンス化が管理されます。ただし、ADFモデルを使用するアプリケーションでは、UIコンポーネントの属性はマネージドBeanのプロパティまたはメソッドにバインディングされるのではなく、汎用データバインディング機能の実行にXML構成ファイルを使用するADFモデルに自動的にバインディングされます。

ADFの宣言的なバインディングによって、データ・コントロール内のデータ・コレクションからのデータ・アクセスの詳細と、その操作の実行が抽象化されます。宣言的なバインディング・オブジェクトには、次の3つの基本的な種類があります。

- 実行可能バインディング: 実行可能バインディングには、イテレータ・バインディングなどが含まれ、データ・コレクションのスクロール処理とページング、および概要情報から詳細情報へのドリルダウンを可能にするユーザー・インタフェースを容易に作成できます。また、実行可能バインディングには、ページ内で一連のページの検索およびネストを可能にするバインディングや、操作を即時実行するためのバインディングも含まれます。

- 値バインディング: データを表示するUIコンポーネントで使用します。値のバインディングは、単純なテキスト・フィールドで使用する最も基本的なものから、リスト、表、ツリーでのUIコントロールのニーズをサポートするような、より高度なリスト、ツリーのバインディングまで、様々な種類があります。

- アクション・バインディング: ハイパーリンクやボタンなどのUIコンポーネントで使用され、コードを記述することなく、データ・コレクションやデータ・コントロールの組込み操作またはカスタム操作を実行します。

ページのUIコンポーネントをサポートするバインディングのグループは、ページ定義ファイルというページ固有のXMLファイルに記述されます。ADFモデル・レイヤーでは実行時にこのファイルが使用され、ページのバインディングがインスタンス化されます。これらのバインディングは、バインディング・コンテナと呼ばれるリクエスト・スコープ・マップに保持され、EL式#{bindings}を使用して各ページ・リクエスト中にアクセスできます。この式により、現在のページのバインディング・コンテナが常に評価されます。

ヒント:

現在のバインディング・コンテナは、プログラム的なアクセス用のAdfContextからも入手できます。

「データ・コントロール」パネルから項目をドラッグし、それを特定のUIコンポーネントとしてページ上にドロップすることで、データバインドされたユーザー・インタフェースを設計できます。データ・コントロールを使用してUIコンポーネントを作成すると、そのコンポーネントを選択したデータ・コントロールにバインドするために必要な、様々なコードおよびオブジェクトがJDeveloperによって自動的に作成されます。

18.2 ADFモデル・レイヤーの追加機能

ADFモデル・レイヤーを構成または使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。また、モデル・レイヤーの構成によって可能になることについても、確認しておくことをお薦めします。次に、関連する他の機能へのリンクを示します。

- ADFモデルとデータ・バインディングは、ビジネス・レイヤーに依存します。ほとんどの場合、操作の対象となるのは、ビュー・オブジェクトの表示です。詳細は、「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。「ビュー・オブジェクトのパフォーマンス・チューニング」で説明されている高度な機能についても理解しておくことをお薦めします。

- ADFモデル・レイヤーを使用して、ビュー・ページを作成できます。この章でビュー・レイヤーのデータ・バインディングの仕組みに関する基本情報を確認した後、「データバインドされたWebユーザー・インタフェースの作成」で、データ・バインディングを使用して特定のビュー機能を作成する場合の詳細を参照してください。

- ADFモデルとページ・ライフサイクルの連携の詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。

- モデル・レイヤーに影響を与える構成パラメータの詳細なリストは、「DataBindings.cpx」および「pageNamePageDef.xml」を参照してください。

- バインディング・プロパティの詳細なリストは、「Oracle ADFバインディング・プロパティ」を参照してください。

18.3 ADFデータ・コントロールを使用したアプリケーション・モジュールの公開

アプリケーション・モジュールを作成すると、アプリケーション・モジュールのデータ・モデルに追加したオブジェクトに対してデータ・コントロールが作成されます。

注意:

その他の種類のビジネス・サービスに対してもデータ・コントロールを作成できます。詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』を参照してください。

ここで重要なことは、データ・コレクション、組込み操作およびサービス・メソッドに対してバインディング・オブジェクトが求めるインタフェースを、アプリケーション・モジュール・コンポーネントが直接実装することです。最適化されたこのような相互作用により、バインディングが次のように直接、データ・モデル内のアプリケーション・モジュール・インスタンスに作用します。

- 任意のビュー・オブジェクト・インスタンスのデフォルト行セットのデフォルト行セット・イテレータに直接バインドするイテレータ・バインディング。行セットのイテレータにより、現在のオブジェクトおよび現在のレンジ情報が管理されます。

ヒント:

イテレータ・バインディングを使用して、作成した名前付きのセカンダリ行セットにバインドすることもできます。セカンダリ行セット・イテレータにバインドするには、RSINameを使用する必要があります。デフォルト行セットとセカンダリ行セットの違いと、それらの作成方法の詳細は、「複数の行セットと行セット・イテレータの使用」を参照してください。

- 次のいずれかに直接バインドするアクション・バインディング

- データ・コントロールのクライアント・インタフェース上のカスタム・メソッド

- アプリケーション・モジュールの組込み操作およびビュー・オブジェクト

図18-2に、UIコンポーネントをアプリケーション・モジュール・データ・コントロール・オブジェクトと結び付けるイテレータおよびアクション・バインディングの例を示します。

図18-2 バインディングによるデータ・コントロールへのUIコンポーネントの関連付け

18.3.1 「データ・コントロール」パネルでのアプリケーション・モジュールのデータ・コントロールの表示

「データ・コントロール」パネルで、アイコンをパネルからページのビジュアル・エディタにドラッグ・アンド・ドロップして、データバインドされたUIコンポーネントを作成します。図18-3は、Oracle ADFのSummitサンプル・アプリケーションのデータ・コントロールを表示する「データ・コントロール」パネルを示しています。

図18-3 JDeveloperの「データ・コントロール」パネル

「データ・コントロール」パネルには、アプリケーションのビジネス・サービスに対して作成されたすべてのデータ・コントロールがリストされます。また、UIコンポーネントへのバインドに使用できるコレクション(データ・オブジェクトの行セット)、メソッドおよび組込み操作がすべて公開されます。

注意:

それらを公開するようにJDeveloperを構成している場合は、ビュー・リンク・アクセッサの戻り値も表示されます。詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。ビュー・アクセッサ・メソッドの表示手順は、次のとおりです。

1. JDeveloperのメイン・メニューから、「ファイル」→「プリファレンス」を選択します。

2. 「データ・コントロール」パネルのノードを選択します。

3. 「基礎なるアクセッサ・ノードの表示」を選択して、チェック・ボックスをアクティブにします。

ビジネス・サービスを定義するためにADFビジネス・コンポーネントを使用するアプリケーションでは、「データ・コントロール」パネル上の各データ・コントロールは特定のアプリケーション・モジュールを表し、そのアプリケーションのデータ・モデルでビュー・オブジェクト・インスタンスを公開します。データ・コントロール内のオブジェクトの階層は、アプリケーション・モジュール・データ・モデル用に追加されているビュー・オブジェクト間のビュー・リンクによって定義されます。ビュー・オブジェクトおよびビュー・リンクの作成の詳細は、「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。データ・モデルへのビュー・リンクの追加の詳細は、「データ・モデルでアクティブなマスター/ディテール調整を有効化する方法」を参照してください。

ヒント:

関連付けられたデータ・コントロール・オブジェクトを右クリックして、「定義の編集」を選択すると、ビュー・オブジェクトの概要エディタを開くことができます。

たとえば、BackOfficeAppModuleDataControlは、企業の従業員が使用できるSummit ADFサンプル・アプリケーションのビジネス・サービス・レイヤーの一部を実装する、BackOfficeAppModuleアプリケーション・モジュールを表します。アプリケーション・モジュールのデータ・モデルには、複数のマスター/ディテール階層など、多数のビュー・オブジェクト・インスタンスが含まれています。Summit ADFサンプル・アプリケーションのビュー・レイヤーはJSFページで構成され、このページのUIコンポーネントは、BackOfficeAppModuleのデータ・モデル内のビュー・オブジェクト・インスタンスのデータと、そのクライアント・インタフェース上の組込み操作およびサービス・メソッドにバインドされています。

18.3.1.1 「データ・コントロール」パネルでのデータ・モデルおよびサービス・メソッドの表示

各ビュー・オブジェクト・インスタンスは、ビュー・オブジェクト・インスタンス名と対応する名前が付いたデータ・コレクションとして表示されます。図18-4は、BackOfficeAppModuleのデータ・モデル内のビュー・オブジェクト・インスタンスが「データ・コントロール」パネルでどのように表示されるかを示しています。「データ・コントロール」パネルは、マスター・データ・コレクションの下にネストされたディテール・データ・コレクションを表示することで、アプリケーション・モジュールのデータ・モデル内のマスター/ディテール階層を示します。

図18-4「データ・コントロール」パネルでのデータ・モデルの表示

「データ・コントロール」パネルは、アプリケーション・モジュールのクライアント・インタフェース上の任意のカスタム・メソッドも、メソッド名と対応する名前が付いたデータ・コントロール・カスタム操作として表示します。メソッドが引数を受け入れると、その引数は、操作ノード内にネストされた操作パラメータとして「パラメータ」ノードに表示されます。

18.3.1.2 「データ・コントロール」パネルでのトランザクション制御操作の表示

アプリケーション・モジュールのデータ・コントロールでは、図18-5に示すように、CommitおよびRollbackという名前の2つのデータ・コントロールの組込み操作を公開します。これらの操作は、実行時にデータ・バインディング・レイヤーによって起動されると、現在のアプリケーション・モジュール・インスタンスに関連付けられているTransactionオブジェクトのcommit()メソッドおよびrollback()メソッドに委譲します。

注意:

多数のビュー・オブジェクト・インスタンスおよびカスタム・メソッドがあるアプリケーション・モジュールでは、データ・コントロールの直接の子ノードである「操作」ノードを見つけるには、「データ・コントロール」パネル表示のスクロールが必要な場合があります。このノードに、その組込み操作が含まれています。

図18-5 「データ・コントロール」パネルでのトランザクション制御操作の表示

18.3.1.3 「データ・コントロール」パネルでのビュー・オブジェクトの表示

ビュー・オブジェクト属性は、作成したカスタム・メソッドと同様、対応するデータ・コレクションの直接の子ノードとして表示されます。図18-6は、アプリケーション・モジュールのデータ・モデル内の各ビュー・オブジェクト・インスタンスが「データ・コントロール」パネルでどのように表示されるかを示しています。いずれかのカスタム・メソッドをビュー・オブジェクトのクライアント・インタフェースに表示することを選択している場合、そのメソッドは、同じレベルのビュー・オブジェクト属性のすぐ下にカスタム・メソッドとして表示されます。メソッドが引数を受け入れると、その引数は、ネストされた「パラメータ」ノードに操作パラメータとして表示されます。

デフォルトでは、ビュー・オブジェクトで問合せ可能な各属性に対して暗黙的なビュー基準が作成されます。それらは、図18-6に示すように、「名前付き基準」ノードの下に「すべての問合せ可能な属性」ノードとして表示されます。ビュー・オブジェクトに対して作成された名前付きビュー基準は「名前付き基準」ノードの下に表示されます。問合せで使用される結合と基準項目、ネストされた基準(該当する場合)が子として表示されます。これらのアイテムを使用して、「ADFによるデータバインドされた検索フォームの作成」で説明するような、クイック検索フォームを作成します。

図18-6「データ・コントロール」パネルでのビュー・オブジェクトの表示

図18-6に示すように、データ・コレクションの下の「操作」ノードには、そのコレクションで使用可能な組込み操作がすべて表示されます。操作で1つ以上のパラメータを受け入れると、そのパラメータは、ネストされた「パラメータ」ノードに表示されます。実行時に、これらのデータ・コレクション操作の1つがデータ・バインディング・レイヤーによって名前別に起動されると、アプリケーション・モジュールのデータ・コントロールは、組込み機能を処理するViewObjectインタフェース上の適切なメソッドにそのコールを委譲します。組込み操作は、現在の行に影響を与える操作、データ・コレクションをリフレッシュする操作、および他の全操作の3つのカテゴリに分類されます。

現在の行に影響を与える操作:

- Create: 現在の行になる新規行を作成するが、その行の挿入なし。

- CreateInsert: 現在の行となる新規行を作成し、新規の空白行をデータソースに挿入。

- Create with Parameters: パラメータ値を使用して新しい行を作成。渡したパラメータによって、次の作成時の値を指定できます。

- 多相ビュー・オブジェクトの多相化識別子

- 多相ビュー・オブジェクトの作成に必要な、構成する側の親の外部キー属性

- 構成される側の子ビュー・オブジェクト行(親行のコンテキストで作成されない場合)

多相ビュー・オブジェクトの詳細は、「多相ビュー・オブジェクトの定義」を参照してください。

- Delete: 現在の行を削除。

- First: 現在の行を行セット内の最初の行に設定。

- Last: 現在の行を行セット内の最後の行に設定。

- Next: 行を行セット内の次の行に設定。

- Next Set: 1つ後の行のセットに移動します。

- Previous: 現在の行を行セット内の前の行に設定。

- Previous Set: 1つ前の行セットに移動。

- setCurrentRowWithKey: パラメータとして渡された行キーのシリアライズされた文字列表現を使用して行の検索を試行。検出されると、その行が現在の行になります。

- setCurrentRowWithKeyValue: パラメータとして渡された主キーの属性値を使用して行の検索を試行。検出されると、その行が現在の行になります。
setCurrentRowWithKeyおよびsetCurrentRowWithKeyValueの使用方法の詳細は、「表での現在行の設定に関する必知事項」を参照してください。

データ・コレクションをリフレッシュする操作:

- Execute: ビュー・オブジェクトの問合せを実行または再実行してデータ・コレクションをリフレッシュ。バインド・パラメータがある場合、その値は現在の値のままになります。

- ExecuteWithParams: パラメータとして渡された名前付きのバインド変数に新しい値を割り当てた後で、ビュー・オブジェクトの問合せを実行または再実行することにより、データ・コレクションをリフレッシュ。

注意:

executeWithParams操作は、設計時に1つ以上の名前付きバインド変数が定義されているビュー・オブジェクトの場合のみ表示されます。

他の全操作:

- removeRowWithKey: パラメータとして渡された行キーのシリアライズされた文字列表現を使用して行の検索を試行。検出されると、その行が削除されます。

- Find: データ・コレクションの検索モードのオンとオフの切替え。

18.3.1.4 「データ・コントロール」パネルでのネストされたアプリケーション・モジュールの表示

他のアプリケーション・モジュールのネストされたインスタンスを組み込んで複合アプリケーション・モジュールを作成すると、「データ・コントロール」パネルではこのコンポーネント・アセンブリがツリー階層で表示されます。たとえば、Summit ADFサンプル・アプリケーションにはSummitAppModuleアプリケーション・モジュールが含まれ、これにはBackOfficeAppModuleおよびCustomerSelfServiceAppModuleアプリケーション・モジュールのネストされたインスタンスが含まれます。ネストされたインスタンスはそれぞれ、BackOfficeAMおよびCustomerSelfServiceAMと呼ばれます。図18-7に示すように、3つのアプリケーション・モジュールすべてに対してトップレベルのデータ・コントロールがあり、SummitAppModuleDataControlデータ・コントロールには、BackOfficeAMおよびCustomerSelfServiceAMインスタンス用のサブノードがあります。

図18-7 「データ・コントロール」パネルでのネストされたアプリケーション・モジュールの表示

目的の用途に対応するデータ・コントロールからドラッグ・アンド・ドロップ・データ・バインディングを実行するよう注意する必要があります。パネル内のトップレベルの BackOfficeAppModuleDataControlデータ・コントロール・ノードからデータ・コレクションをドロップすると、実行時にページ上で、BackOfficeAppModuleコンポーネント・プールから取得したBackOfficeAppModuleアプリケーション・モジュールのインスタンスが使用されます。SummitAppModuleDataControlのネストされたBackOfficeAMのインスタンスのデータ・コレクションをドロップすると、実行時にページ上でSummitAppModuleコンポーネント・プールから取得したSummitAppModuleアプリケーション・モジュールのインスタンスが使用されます。各タイプのアプリケーション・モジュールのデータ・コントロールでは異なるトランザクションおよびデータベース接続が使用されるため、ネストされたアプリケーション・モジュールと最上位のデータ・コントロールの両方から不適切にデータ・コレクションを組み合せると、実行時に予期せぬ動作が発生します。

18.3.1.5 「データ・コントロール」パネルでの行検索の表示

デフォルトで、ビュー・オブジェクトに定義した行検索は「データ・コントロール」パネルに表示されます。実行時に、名前付き基準内の行検索が検索パネルとして表示され、名前付き基準内の属性のみを表示します。演算子は表示されません。アプリケーションによって「データ・コントロール」パネルでコレクションとして公開されるビュー・オブジェクトの行検索マップ属性は、行検索の参照操作に使用できます。図18-8に、「データ・コントロール」パネル内の名前付き基準の下にある行検索を示します。

図18-8 「データ・コントロール」パネル内の行検索

アプリケーションでビュー・オブジェクト・インスタンスの行検索がプログラムにより呼び出された場合、またはエンド・ユーザーが行検索にマップされた属性の値をWebサービス・ペイロードで指定した場合は、行検索では、ビュー基準のバインド変数に入力した値に一致する行が特定されます。行検索では、一致する行の特定時に行セットの変更を行いません。

18.3.2 「データ・コントロール」パネルの表示方法

「データ・コントロール」パネルは、JDeveloperの最上部左側にある「アプリケーション」ウィンドウにあります。コンテンツを表示するには、パネル・ヘッダーをクリックしてパネルを展開します。パネル・ヘッダーが表示されていない場合、「アプリケーション」ウィンドウが表示されない場合があります。

「アプリケーション」ウィンドウと「データ・コントロール」パネルを開くには:

1. メイン・メニューで、「ウィンドウ」→「アプリケーション」の順に選択します。

2. 「データ・コントロール」アコーディオン・パネルを開くには、図18-9に示す「データ・コントロール」ヘッダーの展開アイコンをクリックします。

図18-9 「アプリケーション」ウィンドウの「データ・コントロール」パネル

18.3.3 「データ・コントロール」パネルのリフレッシュ方法

アプリケーション・モジュールまたは基礎となるサービスが変更されたら必ず、変更を表示するためにデータ・コントロールを手動でリフレッシュする必要があります。

「データ・コントロール」パネルをリフレッシュするには:

- 「データ・コントロール」パネルのヘッダーにある「リフレッシュ」アイコンをクリックします(図18-10を参照)。

図18-10 「データ・コントロール」パネル

「リフレッシュ」をクリックすると、使用可能なすべてのデータ・コントロールが「データ・コントロール」パネルで検索され、データ・モデルに対して加えられた構造的な変更が反映されます。

18.3.4 別のプロジェクトで使用するデータ・コントロールのパッケージ化

別のプロジェクトで使用できるよう、データ・コントロールをパッケージ化できます。たとえば、ある開発グループがサービスおよびデータ・コントロールを作成している間に、別の開発グループがUIを作成する場合があります。最初のグループはサービスおよびデータ・コントロールを作成し、Oracle ADFライブラリとしてパッケージ化し、2番目のグループへ送信します。次に、2番目のグループは「リソース」ウィンドウを使用してそのプロジェクトにデータ・コントロールを追加できます。詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

18.4 データ・コントロール・パネルの使用

「データ・コントロール」パネルから項目をドラッグし、それを特定のUIコンポーネントとしてページ上にドロップすることで、データバインドされたユーザー・インタフェースを設計できます。データ・コントロールを使用してUIコンポーネントを作成すると、そのコンポーネントを選択したデータ・コントロールにバインドするために必要な、様々なコードおよびオブジェクトがJDeveloperによって自動的に作成されます。

「データ・コントロール」パネルでは、各データ・コントロール・オブジェクトが特定のアイコンで表されます。表18-1は、各アイコンが表すもの、「データ・コントロール」パネルの階層内で表示される場所、およびそのアイコンを使用して作成できるコンポーネントを示しています。

表18-1 「データ・コントロール」パネルのアイコンおよびオブジェクト階層

アイコン

名前

説明

作成する対象

データ・コントロール

データ・コントロールを表します。データ・コントロール自体を使用してUIコンポーネントを作成することはできませんが、その下に表示される子オブジェクトは、いずれも使用できます。ビジネス・サービスの定義方法によっては、複数のデータ・コントロールが存在することがあります。

通常、各アプリケーション・モジュールに対するデータ・コントロールは1つです。ただし、他のタイプのビジネス・サービス(Webサービスなど)に対して作成された追加のデータ・コントロールがある場合があります。

その他のビジネス・サービスのデータ・コントロールの作成の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』を参照してください。

他のオブジェクトのコンテナとして機能し、コンポーネント作成には使用されません。

コレクション

名前付きデータ・コレクションを表します。データ・コレクションとは、データ・モデル内のデータ・オブジェクト・セット(行セットとも呼ばれる)です。データ・コレクション内の各オブジェクトは、データ・モデル内の特定の構造化データ項目(行とも呼ばれる)を表します。このガイド全体を通して、データ・コレクションおよびコレクションという用語は、区別なく使用されます。

アプリケーション・モジュールにおいて、データ・コレクションは、ビュー・オブジェクト・インスタンスに含まれているデフォルトの行セットです。コレクションの名前は、ビュー・オブジェクト・インスタンス名と一致します。

ビュー・リンクによって、2つのビュー・オブジェクト間にマスター/ディテール関係が作成されます。アプリケーション・モジュール・データ・モデルにディテール・ビュー・オブジェクト(ビュー・リンクからの結果)のインスタンスを明示的に追加する場合、そのディテール・ビュー・オブジェクトに含まれるコレクションは、マスター・ビュー・オブジェクトに含まれるコレクションの子として表示されます。データ・モデルへのディテール・ビュー・オブジェクトの追加の詳細は、「データ・モデルでアクティブなマスター/ディテール調整を有効化する方法」を参照してください。

コレクションの下の子は、コレクションの属性、ビュー・リンクによって関連付けられる他のコレクション、コレクションから値を戻すカスタム・メソッド、またはコレクションに対して実行できる組込み操作などです。

ビュー・リンク・アクセッサの戻り値を表示するようにJDeveloperを構成している場合は、それらも表示されます。

フォーム、表、グラフ、ツリー、レンジ・ナビゲーションの各コンポーネント、およびマスター/ディテール・コンポーネント。

データ・コントロールのコレクションを使用したフォーム作成の詳細は、「データバインドされた基本的なページの作成」を参照してください。

コレクションを使用した表作成の詳細は、「ADFによるデータバインドされた表の作成」を参照してください。

UIコンポーネントを作成するためのマスター/ディテール関係の使用の詳細は、「マスター/ディテール・データの表示」を参照してください。

グラフ、チャートおよびその他の視覚的なUIコンポーネントの作成の詳細は、「データバインドされたチャート・コンポーネントおよびゲージ・コンポーネントの作成」を参照してください。

属性

オブジェクト内の個別のデータ要素(行の属性など)を表します。属性は、自分の属するコレクションまたはメソッド戻りの下に、子として表示されます。

アプリケーション・モジュール・データ・コントロールの場合、対応するビュー・オブジェクトに含まれる属性のみが、コレクション下に表示されます。ビュー・オブジェクトが1つ以上のエンティティ・オブジェクトを結合する場合、ビュー・オブジェクトのコレクションには、すべての基礎となるエンティティ・オブジェクトから選択された属性が含まれます。

ラベル、テキスト・フィールド、日付、値リスト、および選択リストの各コンポーネント。

属性を使用してページ上にフィールドを作成する方法の詳細は、「データ・コントロール属性を使用したテキスト・フィールドの作成」を参照してください。

リスト作成の詳細は、「データバインドされた選択リストおよびシャトルの作成」を参照してください。

構造化属性

Javaプリミティブ・タイプ(属性として示される)または任意のタイプのコレクションのいずれでもない、戻りオブジェクトを示します。構造化属性の例としてドメインがあります。これはアプリケーションのメンテナンスを簡素化するために開発者によって作成されたデータ型です。

ドメインの詳細は、「ドメインを使用したカスタム検証済データ型の作成」を参照してください。

ラベル、テキスト・フィールド、日付、値リスト、および選択リストの各コンポーネント。

メソッド

データ・コントロールの操作またはその公開された構造のいずれかを表し、パラメータの受入れや、ビジネス・ロジックの実行を行ったり、オプションで単一の値、構造またはコレクションを戻すことができます。

アプリケーション・モジュール・データ・コントロールでは、カスタム・メソッドがアプリケーション・モジュール自体の中で定義され、通常は、何も戻さないか、単一のスカラー値を戻します。カスタム・メソッドの作成の詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

コマンド・コンポーネント

パラメータを受け入れるメソッドの場合: コマンド・コンポーネントおよびパラメータ付きフォーム。

メソッド戻り

カスタム・メソッドによって戻されたオブジェクトを表します。戻されたオブジェクトは、単一の値またはコレクションです。

アプリケーション・モジュールで定義されたカスタム・メソッドから戻されるのは通常、単一のスカラー値です。データへの最新の変更の表示はデータ・モデルのビュー・オブジェクトによって処理されるため、アプリケーション・モジュール・メソッドでビュー・レイヤーにデータのセットを戻す必要はありません(詳細は、「実行時のビュー・オブジェクトとエンティティ・オブジェクトの連携処理」を参照)。ただし、非アプリケーション・モジュール・データ・コントロールのカスタム・メソッド(CSVファイルのデータ・コントロールなど)は、ビュー・レイヤーにコレクションを戻すことができます。

メソッド戻りは、これを戻すメソッドの下に、子として表示されます。メソッド戻りの下に子として表示されるオブジェクトは、コレクションの属性、親コレクションに関連するアクションを実行する他のメソッド、または親コレクションで実行できる操作などです。

コレクションおよび属性と同じコンポーネント。

単一値のメソッド戻り値がドロップされると、メソッドはフレームワークにより自動的に起動されなくなります。メソッドを起動するために、対応するメソッドをボタンとしてドロップできます。フォームがタスク・フローの一部の場合、メソッドを起動するためのメソッド・アクティビティを作成できます。実行可能ファイルの詳細は、「ページ定義ファイルで定義されるExecutablesバインディング・オブジェクト」を参照してください。

操作

親オブジェクトに対してアクションを実行する、組込みデータ・コントロール操作を表します。データ・コントロール操作は、コレクションまたはメソッド戻り値の下の「操作」 ノードと、ルート・データ・コントロール・ノードの下にもあります。特定のコレクションまたはメソッド戻りの子である操作は、それらのオブジェクトにのみ作用し、データ・コントロール・ノードの下の操作は、そのデータ・コントロール内のすべてのオブジェクトに作用します。

1つ以上のパラメータが操作に必要な場合、それらのパラメータは操作の下の「パラメータ」ノードにリストされます。

ボタン、リンクおよびメニューなどのUIコマンド・コンポーネント。

詳細は、「データ・コントロール操作を使用したコマンド・コンポーネントの作成」および「既存レコードを編集するフォームの作成」を参照してください。

パラメータ

メソッドまたはその下に表示される操作によって宣言されたパラメータ値を表します。パラメータは、メソッドまたは操作の下の「パラメータ」ノード内に表示されます。

ラベル、テキストおよび選択リストの各コンポーネント。

名前付き基準

ユーザー検索フォームを作成できる問合せを表します。

「すべての問合せ可能な属性」基準が各アクセッサ・コレクションについて自動的に生成されます。この問合せを使用して、コレクション内の任意の問合せ可能な属性に基づき、ユーザーが問合せを実行できる検索フォームを作成できます。

カスタム・ビュー基準を作成し、「データ・コントロール」パネルに追加できます。「名前付きビュー基準の処理」を参照してください。

検索フォームの作成の詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

18.4.1 「データ・コントロール」パネルの使用方法

JDeveloperは、ドロップするデータ・コントロール項目に対してそれぞれ選択できるUIコンポーネントの事前定義済セットを備えています。

始める前に:

「データ・コントロール」パネルの各種オブジェクトに関する知識があると役立つ場合があります。詳細は、「データ・コントロール・パネルの使用」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

「データ・コントロール」パネルを使用してUIコンポーネントを作成するには:

1. 「データ・コントロール」パネルで項目を選択し、ページのビジュアル・エディタにその項目をドラッグします。パネルの各項目の定義は、表18-1を参照してください。

操作またはメソッドをタスク・フローのメソッド・アクティビティにドロップする必要がある場合は、タスク・フロー・ダイアグラム内のアクティビティにドラッグ・アンド・ドロップできます。

ヒント:

図18-11に示すように、「データ・コントロール」ヘッダー内の「フィルタ」アイコンを使用して、特定の項目を検索できます。

図18-11 「データ・コントロール」パネルでのフィルタ処理

2. ポップアップ・メニューから、UIコンポーネントを選択します。

「データ・コントロール」パネルから項目をドラッグしてページにドロップすると、ドロップした項目に使用できるすべてのデフォルトUIコンポーネントのポップアップ・メニューが表示されます。表示されるコンポーネントは、プロジェクト内のライブラリに基づきます。

図18-12は、「データ・コントロール」パネルのデータ・コレクションがページにドロップされる際に表示されるポップアップ・メニューを示しています。

図18-12 「データ・コントロール」パネルのポップアップ・メニュー

ポップアップ・メニューから選択したコンポーネントに応じて、そのコンポーネントの外観を定義するためのダイアログが自動的に表示されます。たとえば、ポップアップ・メニューから「表/リスト・ビュー」→「ADF表」を選択すると、「表の作成」ダイアログが表示されます。このダイアログを使用して、表の列に表示する属性、列ラベル、各列に使用するUIコンポーネントのタイプおよび組み込む機能(行選択や列のソートなど)を定義できます。データバインドされた各種UIコンポーネントの作成の詳細は、「データバインドされたWebユーザー・インタフェースの作成」の各章を参照してください。

デフォルトで選択されたUIコンポーネントはまず、対応するビジネス・オブジェクト上で設定されているUIコントロール・ヒントで決定されます。コントロール・ヒントが設定されていない場合、JDeveloperでは標準のフォームおよび表の入力コンポーネントと読取り専用のフォームおよび表の出力コンポーネントが使用されます。リストのコンポーネントは、データ・コントロール・オブジェクトをドロップするときに選択するリストの型に基づいて決定されます。

コンポーネントを選択すると、JDeveloperではビジュアル・エディタのページにそのUIコンポーネントが挿入されます。たとえば、「データ・コントロール」パネルからコレクションをドラッグして、ポップアップ・メニューから「表/リスト・ビュー」→「ADF表」を選択した場合は、図18-13のように、ビジュアル・エディタに読取り専用の表が表示されます。

図18-13 データバインドUIコンポーネント: ADF読取り専用表

デフォルトでは、「データ・コントロール」パネルでADF Facesコンポーネントを使用したときに作成されるUIコンポーネントは、ADFデータ・コントロール内の属性にバインドされ、1つ以上の組込み機能が装備されます。これらの機能は次のとおりです。

- データバインド・ラベル

- ツールチップ

- 書式設定

- 基本的なナビゲーション・ボタン

- 検証(検証規則が特定の属性にアタッチされている場合。)詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

デフォルトのコンポーネントは、そのまま使用しても十分機能します。ただし、特定のニーズに合せて変更することができます。各コンポーネントおよびその各種機能の詳細は、「データバインドされたWebユーザー・インタフェースの作成」を参照してください。

ヒント:

ページで使用するADFデータバインド・コンポーネントのタイプを変更する場合は、ビジュアル・エディタまたは構造ウィンドウを使用してそのコンポーネントを削除し、「データ・コントロール」パネルから新しいコンポーネントをドラッグ・アンド・ドロップする方法が最も簡単です。ビジュアル・エディタまたは「構造」ウィンドウを使用してデータ・バインド・コンポーネントをページから削除する場合、それに関連するバインディング・オブジェクトがページ定義ファイル内で他のコンポーネントから参照されていなければ、それらのバインディング・オブジェクトもJDeveloperによって自動的に削除されます。ソース・エディタを使用している場合は、バインディング・オブジェクトの自動削除は行われません。

18.4.2 「データ・コントロール」パネルの使用時の処理

Oracle ADF WebアプリケーションはJSFフレームワークを使用して作成されますが、ADFデータバインドUIコンポーネントを含むページのレンダリングおよび処理を行うために、いくつかの追加アプリケーション・オブジェクト定義が必要になります。「データ・コントロール」パネルを使用しない場合、これらの様々なファイルを手動で構成する必要があります。一方、「データ・コントロール」パネルを使用した場合は、必要なすべての手順がJDeveloperによって行われます。

- DataBindings.cpxファイルがプロジェクトのデフォルト・パッケージに作成されます(このファイルが存在しない場合のみ)。また、そのページ用にエントリが追加されます。
DataBindings.cpxファイルは、アプリケーションのバインディング・コンテキストを定義します。バインディング・コンテキストはコンテナ・オブジェクトの1つで、使用可能なデータ・コントロールおよびデータ・バインディング・オブジェクトのリストを含みます。詳細は、「実行時に行われる処理: バインディング・コンテキストの動作方法」を参照してください。各DataBindings.cpxファイルによって、個々のページがページ定義ファイルに含まれるバインディング定義にマップされ、これらのページが使用するデータ・コントロールが登録されます。詳細は、「DataBindings.cpxファイルの使用」を参照してください。

- META-INFディレクトリにadfm.xmlファイルが作成されます。このファイルにより、DataBindings.cpxファイルのレジストリが作成され、バインディング・コンテキストを作成できるように、実行時にアプリケーションで特定できます。

- web.xmlファイルにADFバインディング・フィルタが登録されます。
このADFバインディング・フィルタによって、バインディング・コンテキストへのアクセスに必要なHTTPリクエストが事前処理されます。バインディング・フィルタの構成の詳細は、「ADFバインディング・フィルタの構成」を参照してください。

- 必要に応じて、次のようなライブラリをビュー・オブジェクトに追加します。

- ADF Facesデータバインディング・ランタイム

- Oracle XML Parserバージョン2

- JDeveloperランタイム

- ADFモデル・ランタイム

- BC4Jランタイム

- Oracle JDBC

- Connection Manager

- BC4J Oracleドメイン

- パッケージ定義ファイルがページ定義サブパッケージに追加されます(ページに対してファイルが存在しない場合)。デフォルトのサブパッケージは、adfmsrcディレクトリにあるview.pageDefsです。

ヒント:

「プロジェクト・プロパティ」ダイアログ(プロジェクト・ノードをダブルクリックするとアクセスできる)のADFモデル設定ページで、パッケージ構成(名前と場所など)を設定できます。

ページ定義ファイル(pageNamePageDef.xml)は、アプリケーションのビュー・レイヤーにある各ページのADFバインディング・コンテナを定義します。バインディング・コンテナでは、ページのすべてのADFバインディング・オブジェクトへのランタイム・アクセスが行われます。ページ定義ファイルを使用して、特定のUIコンポーネントに対するバインディング・オブジェクト定義を定義および編集する方法は、後の章で説明します。ページ定義ファイルの詳細は、「ページ定義ファイルの処理」を参照してください。

- ページ定義ファイルが構成されます。この処理では、ページによって参照されるバインディング・オブジェクトの定義も追加されます。

- ADF FacesコンポーネントがJSFページに追加されます。
これらの事前作成済のコンポーネントには、ページ定義ファイルのバインディング・オブジェクトを参照するADFデータ・バインディング式言語(EL)式が含まれます。詳細は、「ADFデータ・バインディングのEL式の作成」を参照してください。

- すべてのライブラリ、ファイル、およびADF Facesコンポーネントが必要とする構成要素が追加されます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の付録「ADF Facesの構成」を参照してください。

18.4.3 実行時に行われる処理: バインディング・コンテキストの動作方法

ページにADFバインディングが含まれている場合、実行時には、クライアントまたはコントローラから起動されたビジネス・サービスとのやり取りが、バインディング・コンテキストと呼ばれるシングル・オブジェクトを介して、アプリケーションによって管理されます。バインディング・コンテキストは、アプリケーション内のすべてのデータ・コントロールおよびページ定義のランタイム・マップ(名前付きdataでEL式#{data}を使用してアクセス可能)です。

図18-14に示すように、ADFライフサイクルでは、アプリケーション・モジュールDataBindings.cpxおよびページ定義ファイルから、Oracle ADFバインディング・コンテキストが作成されます。設計時に使用可能なデータ・コントロールは、すべてのDataControls.dcxファイルとワークスペース内のすべてのアプリケーション・モジュールの集合体によって定義されますが、実行時にアプリケーションで使用可能なデータ・コントロールは、DataBindings.cpxファイルで定義されます。DataBindings.cpxファイルは、アプリケーションのページで使用されているデータ・コントロールをリストに表示し、ページ定義ファイルに定義したバインディング・オブジェクトが格納されているバインディング・コンテナをWebページのURLにマップします。ページ定義ファイルは、アプリケーション・ページで使用するバインディング・オブジェクトを定義します。各ページにページ定義ファイルが1つあります。

バインディング・コンテキストには、これらのオブジェクトの現在の実際のインスタンスは含まれていません。かわりに、マップには必要に応じてデータ・コントロールまたはバインディング・コンテナ・オブジェクトになる参照が含まれます。たとえば、オブジェクト(ページ定義など)がアプリケーションから解放されるか、タスク・フローが終了するか、リクエストの終了時にバンディング・コンテナまたはデータ・コントロールが解放されると、データ・コントロールおよびバンディング・コンテナは参照オブジェクトに戻ります。ADFライフサイクルの詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。

図18-14 実行時のADFファイル・バインディングの使用状況

注意:

アプリケーション・モジュール・データ・コントロールは、アプリケーション・モジュール・プーリングも活用します。アプリケーション・モジュールのデータ・コントロールは、リクエスト開始時に使用可能なアプリケーション・モジュール・インスタンスを自動的に取得するアプリケーション・モジュール・プールのシン・アダプタです。現在のリクエスト中に、アプリケーション・モジュールのデータ・コントロールにより、現在のユーザー・セッションのかわりに、アプリケーション・モジュール・インスタンスへの参照が保持されます。リクエスト終了時に、インスタンスは、データ・コントロールによって解放され、プールに戻されます。詳細は、「実行時に行われる処理: アプリケーションでアプリケーション・モジュール・プーリングと状態管理が使用される場合」を参照してください。

18.5 DataBindings.cpxファイルの使用

DataBindings.cpxファイルでは、アプリケーション全体のバインディング・コンテキストが定義されます。実行時にはこのメタデータから、Oracle ADFバインディング・オブジェクトが作成されます。たとえばリージョンなどのコンポーネントがプロジェクトの外で作成され、インポートされた場合は、アプリケーションに複数のDataBindings.cpxファイルが存在することがあります。これらのファイルは個々のページをページ定義ファイルにマップし、どのデータ・コントロールをアプリケーションで使用するかを宣言します。実行時には、DataBindings.cpxファイルにリストされたデータ・コントロールのみが、現在のアプリケーションで使用可能になります。

18.5.1 JDeveloperによるDataBindings.cpxファイルの作成方法

初めて「データ・コントロール」パネルを使用して、ページにコンポーネントを追加したり、アクティビティに操作を追加する際には、JDeveloperによって、ビュー・プロジェクトのデフォルト・パッケージ内に、DataBindings.cpxファイルが自動的に作成されます。このファイルは、プロジェクトのadfmsrcディレクトリにあります。DataBindings.cpxファイルが作成されると、最初のページまたはタスク・フロー・アクティビティ用のエントリが自動的に追加されます。その後、「データ・コントロール」パネルを使用するたびに、そのページまたはアクティビティ用のエントリがまだない場合は、エントリがDataBindings.cpxに追加されます。

ヒント:

JDeveloperではリファクタをサポートしています。つまり、DataBindings.cpxファイルで参照されている多くのオブジェクトを安全に移動したり名前を変更することが可能になり、参照が更新されます。詳細は、「Fusion Webアプリケーションのリファクタ」を参照してください。

18.5.2 DataBindings.cpxファイルの作成時の処理

JDeveloperによりDataBindings.cpxファイルが作成されると、そのファイルを概要エディタで開くことができます。図18-15は、概要エディタで表示される、Summit ADFサンプル・アプリケーションからのDataBindings.cpxファイルを示しています。

図18-15 概要エディタでのDataBindings.cpxファイル

次の例は、Summit ADFサンプル・アプリケーションの.cpxファイルのコンテンツを示しています。

<?xml version="1.0" encoding="UTF-8" ?>
<Application xmlns="http://xmlns.oracle.com/adfm/application"
version="11.1.1.56.60" id="DataBindings" SeparateXMLFiles="false"
Package="oracle.summit.view" ClientType="Generic">
<definitionFactories>
<factory nameSpace="http://xmlns.oracle.com/adf/controller/binding"
className="oracle.adf.controller.internal.binding.
TaskFlowBindingDefFactoryImpl"/>
<dtfactory className="oracle.adf.controller.internal.dtrt.binding.
BindingDTObjectFactory"/>
<factory nameSpace="http://xmlns.oracle.com/adfm/dvt"
className="oracle.adfinternal.view.faces.dvt.model.binding.
FacesBindingFactory"/>
</definitionFactories>
<pageMap>
<page path="/index.jsf" usageId="oracle_summit_view_indexPageDef"/>
<page path="/Customers.jsff" usageId="oracle_summit_view_CustomersPageDef"/>
<page path="/orders/Orders.jsff"
usageId="oracle_summit_view_OrdersPageDef"/>
<page path="/carousel/InventoryControl.jsff" usageId="oracle_summit_view_
InventoryControlTestPageDef"/>
</pageMap>
<pageDefinitionUsages>
<page id="oracle_summit_view_CustomersPageDef"
path="oracle.summit.view.pageDefs.CustomersPageDef"/>
<page id="oracle_summit_view_indexPageDef"
path="oracle.summit.view.pageDefs.indexPageDef"/>
<page id="oracle_summit_view_OrdersPageDef"
path="oracle.summit.view.pageDefs.OrdersPageDef"/>
<page id="oracle_summit_view_InventoryControlTestPageDef"
path="oracle.summit.view.pageDefs.InventoryControlPageDef"/>
</pageDefinitionUsages>
<dataControlUsages>
<BC4JDataControl id="BackOfficeAppModuleDataControl"
Package="oracle.summit.model.services"
FactoryClass="oracle.adf.model.bc4j.DataControlFactoryImpl"
SupportsTransactions="true" SupportsFindMode="true"
SupportsRangesize="true" SupportsResetState="true"
SupportsSortCollection="true"
Configuration="BackOfficeAppModuleLocal"
syncMode="Immediate"
xmlns="http://xmlns.oracle.com/adfm/datacontrol"/>
</dataControlUsages>
</Application>

エディタの「ページ・マッピング」セクションにより、IDを使用して各JSFページまたはタスク・フロー・アクティビティが対応するページ定義ファイルにマップされます。「ページ定義の使用方法」セクションにより、ページ定義IDはアプリケーション内のページ定義ファイルの絶対パスにマップされます。「データ・コントロールの使用方法」セクションは、ページ定義ファイル内で定義済のバインディング・オブジェクトによって使用されるデータ・コントロールを識別します。これらのマッピングにより、ページの起動時にバインディング・コンテナを初期化できます。

概要エディタで、現在のID名をダブルクリックし、インラインで編集することで、ページ定義ファイルまたはデータ・コントロールのID名を変更できます。そうすると、アプリケーションのすべての参照が更新されます。ただし、JDeveloperで更新されるのはID名のみであり、ファイル名は更新されません。データ・コントロール名を予約語に変更しないようにしてください。詳細は、「既存のアプリケーション・モジュールの編集方法」を参照してください。

「構造」ウィンドウで要素をクリックし、「プロパティ」ウィンドウを使用してプロパティ値を変更することもできます。DataBindings.cpxファイルの要素および属性の詳細は、「DataBindings.cpx」を参照してください。

18.6 ADFバインディング・フィルタの構成

ADFバインディング・フィルタはサーブレット・フィルタの1つで、oracle.adf.model.servlet.ADFBindingFilterクラスのインスタンスです。ADF Webアプリケーションは、ADFバインディング・フィルタを使用して、バインディング・コンテキストへのアクセスが必要なすべてのHTTPリクエストを前処理します。これを行うには、ADFバインディング・フィルタがアプリケーションに存在するすべてのDataBindings.cpxファイルを認識している必要があります。

18.6.1 ADFバインディング・フィルタの構成方法

「データ・コントロール」パネルを使用して、初めてデータバインド・コンポーネントをページに追加する際には、JDeveloperによって、アプリケーションのweb.xmlファイル内にフィルタが自動的に構成されます。

18.6.2 ADFバインディング・フィルタを構成した場合の処理

バインディング・フィルタを構成するために、JDeveloperによって、次の要素がweb.xmlファイルに追加されます。

- ADFバインディング・フィルタ・クラス: javax.servlet.Filterインタフェースを実装するバインディング・フィルタ・オブジェクトの名前を指定します。
次の例に示すように、ADFバインディング・フィルタはweb.xmlファイルで定義されます。filter-name要素は値adfBindingsを含む必要があり、filter-class要素はバインディング・フィルタ・クラスの完全修飾名oracle.adf.model.servlet.ADFBindingFilterを含む必要があります。

<filter>
<filter-name>adfBindings</filter-name>
<filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class>
</filter>

- フィルタ・マッピング:フィルタをWebアプリケーション内の静的リソースまたはサーブレットにリンクします。
実行時にマップ済リソースが要求されると、フィルタが起動します。フィルタ・マッピングは、web.xmlファイルで次の例のように定義されます。filter-name要素は値adfBindingsを含む必要があります。

<filter-mapping>
<filter-name>adfBindings</filter-name>
<servlet-name>Faces Servlet</servlet-name>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

ヒント:

web.xmlファイルで複数のフィルタが定義されている場合は、それらのフィルタを必ず実行順に記載してください。実行時には、web.xmlファイルでの表示順にフィルタが実行されます。

adfBindingsフィルタは、Trinidadフィルタの後、初期化するADFコンテキストに依存するすべてのフィルタの前に表示されます。

18.6.3 実行時に行われる処理: ADFバインディング・フィルタの動作方法

ADFバインディング・フィルタは、実行時に次の機能を実行します。

- フィルタを初期化する際に、web.xmlファイルでフィルタ・パラメータとして指定されている名前で、文字コードをオーバーライドします。フィルタinit-param要素のパラメータ名は、encodingです。

- Fusion Webアプリケーションの実行コンテキストであり、セキュリティ・コンテキスト、リクエストとレスポンスのオブジェクトを含む環境クラスなどのADFのコンテキスト情報が含まれるADFContextオブジェクトをインスタンス化します。

- ユーザーのHTTPセッションのバインディング・コンテキストを初期化します。バインディング・コンテキストを初期化するには、まず現在のプロジェクトのadfmsrcディレクトリにあるDataBindings.cpxファイルの定義に従ってバインディングをロードします。アプリケーションに別のプロジェクトからインポートされたDataBindings.cpxファイルが含まれている場合、これらのファイルはアプリケーションのクラス・パスにあります。さらにフィルタにより、アプリケーションのクラス・パスで見つかった補助.cpxファイルがロードされます。

- 同じブラウザ(フレームセットなど)から送信されるHTTPリクエストをシリアライズし、マルチスレッドの問題を回避します。

- リクエストが送信されることをデータ・コントロール・インスタンスに通知し、リクエストごとに必要な設定が行われるようにします。

- レスポンスがクライアントに送信された後でデータ・コントロール・インスタンスに通知し、リクエストごとに必要なクリーンアップが行われるようにします。

18.7 ページ定義ファイルの処理

ページ定義ファイルは、実行時にUIコンポーネントにデータを移入するバインディング・オブジェクトを定義します。ADFバインディングを持つすべてのページには、対応するページ定義ファイルが必要です。このファイルには、そのページで使用するバインディング・オブジェクトの定義が含まれています。ページ定義ファイルによって、すべてのADFバインディングに設計時アクセスが提供されます。実行時には、ページ定義ファイルによって定義されたバインディング・オブジェクトが、ページ定義ファイルの実行時インスタンスであるバインディング・コンテナ内でインスタンス化されます。

注意:

同じページに複数のウィンドウが開いていると、ADFコントローラによって各ウィンドウに独自のDataControlFrameが割り当てられます。これにより、各ウィンドウが独自のバインディング・コンテナを持つようになります。

18.7.1 ページ定義ファイルの作成方法

「データ・コントロール」パネルを初めて使用してページにコンポーネントを追加する際には、JDeveloperによって、そのページのページ定義ファイルが自動的に作成され、コンポーネントが参照する各バインディング・オブジェクトの定義が自動的に追加されます。それ以降、ページにデータバインド・コンポーネントを追加するたびに、JDeveloperによって、必要なバインディング・オブジェクト定義がページ定義ファイルに自動的に追加されます。

デフォルトでは、ページ定義ファイルは、ビュー・プロジェクトのApplication Sourcesノードにあるview.PageDefsパッケージに含まれています。対応するJSFページがデフォルト(public_html)以外のディレクトリ、またはデフォルトのサブディレクトリに保存されると、ページ定義も同じ名前のペッケージに保存されます。たとえば、JSFファイルをpublic_html\myDirectoryディレクトリ日本すると、ページ定義がmyDirectoryパッケージに保存されます。ページ定義ファイルの場所は、「プロジェクト・プロパティ」ダイアログのADF Model設定ページを使用して変更できます。

JDeveloperによるページ定義ファイルの命名には、次の規則が使用されます。

pageNamePageDef.xml

pageNameは、JSFページまたはフラグメントの名前です。つまり、JSFページの名前がindex.jsfの場合は、デフォルトのページ定義ファイル名はindexPageDef.xmlになります。ページをサブディレクトリに組み入れる場合、JDeveloperでは、次の規則を使用してディレクトリ名をページ定義ファイル名の接頭辞にします。

directoryName_pageNamePageDef.xml

ヒント:

タスク・フローのページ定義は、同じ命名規則に従います。

ページ定義ファイルを開くには、ビジュアル・エディタでページまたはアクティビティを右クリックし、「ページ定義に移動」を選択するか、JSFページの場合は、エディタの「バインディング」タブをクリックして、「ページ定義ファイル」リンクをクリックします。

ヒント:

JDeveloperでは、「データ・コントロール」パネルを使用してコンポーネントを作成する場合にはJSFページのページ定義、項目をアクティビティにドロップする場合にはタスク・フローのページ定義が自動的に作成されますが、関連付けられたJSFページやタスク・フロー・アクティビティを削除してもページ定義は削除されません。(ADFデスクトップ統合の機能を使用する場合など、バインディングが必要になる場合でも、JSFページを使用せずに残すことができます。)ページ定義が不要になった場合、ページ定義とそのページ定義への参照はすべて手動で削除する必要があります。ただし、対応するページまたはアクティビティがコールされないかぎり、ページ定義を使用してバインディング・コンテキストが作成されることはありません。したがって、必ずしもアプリケーションから未使用のページ定義ファイルを削除する必要があるわけではありません。

18.7.2 ページ定義ファイルの作成時の処理

JDeveloperでページ定義ファイルが作成されると、概要エディタに表示されます。図18-16は、Summit ADFサンプル・アプリケーションのOrders.jsffページに対して作成された概要エディタのページ定義ファイルを示しています。

図18-16 概要エディタでのページ定義ファイル

概要エディタには次のタブが含まれており、これらを使用してバインディング、コンテキスト・イベント、ページのパラメータを表示および構成できます。

- バインディングと実行可能ファイル: 概要エディタのページ定義の「バインディングと実行可能ファイル」タブでは、Bindings、Executablesおよび関連付けられたData Controlsの3つの異なるタイプのオブジェクトが表示されます。(BindingsとExecutablesは、選択しないかぎりデータ・コントロールには表示されません。)たとえば、図18-16では、LastName属性のバインディングはOrdersForCustomerIteratorイテレータを使用して値を取得していることがわかります。イテレータは、BackOfficeAppModuleDataControlデータ・コントロールのOrdersForCustomerコレクションにアクセスしています。詳細は、「ページ定義ファイルで定義されるExecutablesバインディング・オブジェクト」を参照してください。
デフォルトでは、モデル・バインディング・オブジェクトは、そのオブジェクトを作成するために使用されたデータ・コントロール・オブジェクトの名前が付けられます。データ・コントロール・オブジェクトが1ページ内で何度も使用される場合、JDeveloperではデフォルトのバインディング・オブジェクト名に数字を追加して、それぞれが一意になるようにします。「ADFデータ・バインディングのEL式の作成」は、ADFデータ・バインディングEL式によるバインディング・オブジェクト名の参照方法について説明しています。

表18-2は、概要エディタで表示される各バインディング・オブジェクトのアイコンを示しています(エディタの「パラメータ」セクションでパラメータ・オブジェクトが表示されますが、これらもバインディング・オブジェクトとみなされます)。

表18-2 バインディング・オブジェクト・アイコン

バインディング・オブジェクト型

アイコン

説明

パラメータ

パラメータ・バインディング・オブジェクトを表します。

バインディング

属性値のバインディング・オブジェクトを表します。

リスト値のバインディング・オブジェクトを表します。

ツリー値のバインディング・オブジェクトを表します。

メソッドのアクション・バインディング・オブジェクトを表します。

バインディング/実行可能ファイル

アクション・バインディング・オブジェクトを表します。

実行可能ファイル

イテレータ・バインディング・オブジェクトを表します。

タスク・フローのExecutablesバインディング・オブジェクトを表します。

名前付き基準オブジェクトがページに追加される際に使用される、検索リージョン・バインディング・オブジェクトを表します。

- コンテキスト・イベント: アプリケーション内のアーティファクトが登録可能なコンテキスト・イベントを作成できます。たとえば、コンテキスト・イベントを顧客登録ページに使用して、適切な情報トピックを表示できます。ページ内の一方のリージョンには顧客登録タスク・フローを含め、他方には情報トピックのタスク・フローが含めることができます。コンテキスト・イベントが顧客登録リージョンから情報トピック・リージョンに渡され、情報トピック・タスク・フローに正しい情報トピックを表示します。設計時はイベント名、プロシージャ・リージョン、消費者ハンドラ、その他の情報が、ページ定義ファイルのイベント・マップ・セクションに保存されます。詳細は、「コンテキスト・イベントの使用方法」を参照してください。

- パラメータ: パラメータ・バインディング・オブジェクトは、リクエストの開始時にページが評価するパラメータを宣言します。ADFライフサイクルの詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。そのようなパラメータは、「タスク・フローのパラメータの使用」で説明されているように、タスク・フローから渡すこともできます。
静的値または静的値を割り当てるEL式を使用して、ページ定義ファイルのパラメータ値を定義できます。次の例は、EL式を使用して値を割り当てるパラメータ・バインディング・オブジェクトを示しています。

<parameters>
<parameter name="productId" value="${payLoad}"/>
</parameters>

ヒント:

パラメータ値のEL式では、ドル記号($)が使用されます。これは、これらの式を積極的に解決し、ページのレンダリング時に結果を即座に戻すようにする必要があるためです。JSFアプリケーションのほとんどのEL式ではハッシュ記号(#)が使用され、モデルの準備ができてから値がアクセスされるように式の評価が遅延されます。

概要エディタの項目(または「構造」ウィンドウの関連付けられたノード)をクリックすると、「プロパティ」ウィンドウを使用してその項目の属性値を表示および編集したり、「ソース」タブをクリックしてXMLソースを直接編集できます。次の例は、図18-16に示すページ定義ファイルから抜粋したXMLコードを示しています。

<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="11.1.1.59.23" id="OrdersPageDef"
Package="oracle.summit.view.pageDefs">
<parameters/>
<executables>
<variableIterator id="variables"/>
<iterator Binds="OrdersForCustomer" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="OrdersForCustomerIterator" ChangeEventPolicy="ppr"/>
<iterator Binds="ItemsForOrder" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="ItemsForOrderIterator" ChangeEventPolicy="ppr"/>
<iterator Binds="InventoryForOrderItem" RangeSize="-1"
DataControl="BackOfficeAppModuleDataControl"
id="InventoryForOrderItemIterator" ChangeEventPolicy="ppr"/>
</executables>
<bindings>
<attributeValues IterBinding="OrdersForCustomerIterator" id="Id">
<AttrNames>
<Item Value="Id"/>
</AttrNames>
</attributeValues>
.
.
.
<list IterBinding="OrdersForCustomerIterator" StaticList="false"
Uses="LOV_OrderFilled" id="OrderFilled" DTSupportsMRU="false"/>
<attributeValues IterBinding="OrdersForCustomerIterator" id="LastName">
<AttrNames>
<Item Value="LastName"/>
</AttrNames>
</attributeValues>
<attributeValues IterBinding="OrdersForCustomerIterator" id="Name">
<AttrNames>
<Item Value="Name"/>
</AttrNames>
</attributeValues>
<tree IterBinding="ItemsForOrderIterator" id="ItemsForOrder">
<nodeDefinition DefName="oracle.summit.model.views.ItemVO"
Name="ItemsForOrder0">
<AttrNames>
<Item Value="ProductId"/>
<Item Value="Name"/>
<Item Value="Price"/>
<Item Value="Quantity"/>
<Item Value="ItemTotal"/>
</AttrNames>
</nodeDefinition>
</tree>
.
.
.
</bindings>
</pageDefinition>

ページ定義ファイルを使用して、特定のUIコンポーネントに対するバインディングを定義および編集する方法は、後の章で説明します。ページ定義ファイルで使用できるすべての要素および属性の説明は、「pageNamePageDef.xml」を参照してください。

18.7.2.1 ページ定義ファイルで定義されるコントロール・バインディング・オブジェクト

UIコンポーネントをデータ・コントロールのオブジェクトにバインドする場合に使用するバインディング・オブジェクトは3種類あります。

- 値: イテレータ・バインディングを参照してUIコンポーネントにデータを表示します。データ・コントロールからデータを表示するページ上の個別UIコンポーネントは、それぞれ値バインディング・オブジェクトにバインドされます。値バインディング・オブジェクトの種類は、次のとおりです。

- 属性値: テキスト・フィールドをオブジェクト(属性バインディング・オブジェクトとも呼ばれます)内の特定の属性にバインドする

- リスト: データ・コレクション内でリスト・アイテムを属性のすべての値にバインドします。

- ツリー: 表全体をデータ・コレクションにバインドし、ツリーのルート・ノードをデータ・コレクションにバインドすることもできます。

- ボタン(boolean): チェック・ボックスを属性のブール値にバインドします。

- グラフ: グラフを直接ソース・データにバインドします。

- メソッド・アクション: ボタンやリンクなどのコマンド・コンポーネントをデータ・コントロール上のカスタム・メソッドにバインドします。メソッド・アクション・バインディング・オブジェクトは、メソッドの起動方法およびメソッドが取得するパラメータ(該当する場合)の詳細をカプセル化します。

- アクション: ボタンやリンクなどのコマンド・コンポーネントを組込みデータ・コントロール操作(CommitやRollbackなど)または組込みコレクションレベル操作(Create、Delete、Next、Previousなど)にバインドします。

次の例は、サンプルのbindings要素の抜粋を示しています。特に、要素は表のツリー・バインディング、テキスト・フィールドのいくつかの属性バインディング、CreateInsert組込み操作のアクション・バインディング、およびselectOneChoiceコンポーネントのリスト・バインディングを定義します。

<bindings>
.
.
.
<tree IterBinding="ItemsForOrderIterator" id="ItemsForOrder">
<nodeDefinition DefName="oracle.summit.model.views.ItemVO"
Name="ItemsForOrder0">
<AttrNames>
<Item Value="ProductId"/>
<Item Value="Name"/>
<Item Value="Price"/>
<Item Value="Quantity"/>
<Item Value="ItemTotal"/>
</AttrNames>
</nodeDefinition>
</tree>
<attributeValues IterBinding="ItemsForOrderIterator" id="ShortDesc">
<AttrNames>
<Item Value="ShortDesc"/>
</AttrNames>
</attributeValues>
<attributeValues IterBinding="ItemsForOrderIterator" id="ImageNameFromDB"
ChangeEventPolicy="ppr">
<AttrNames>
<Item Value="ImageNameFromDB"/>
</AttrNames>
</attributeValues>
.
.
.
<action IterBinding="ItemsForOrderIterator" id="CreateInsert"
RequiresUpdateModel="true" Action="createInsertRow"/>
<list IterBinding="OrdersForCustomerIterator" StaticList="false"
Uses="LOV_PaymentTypeId" id="PaymentType" DTSupportsMRU="true"/>
</bindings>

例では、tree要素はItemsForOrder表のバインディングを定義します。AttrNames要素は、値が表示される列を定義するために使用されます。IterBinding属性は、表に表示されるデータを管理するイテレータ・バインディングを参照します。詳細は、「ページ定義ファイルで定義されるExecutablesバインディング・オブジェクト」および「表のイテレータと値バインディング」を参照してください。

attributeValues要素は、ページ上のテキスト・フィールドに対して値バインディングを定義します。例では、ShortDesc属性バインディングによりShortDescの値が表示され、この値がAttrNames要素に定義されます。IterBinding属性は、テキスト・フィールドに表示されるデータを管理するイテレータ・バインディングを参照します。詳細は、「テキスト・フィールドの作成時の処理」を参照してください。

action要素で定義されたバインディング・オブジェクトは、ItemsForOrderコレクションにある組込みCreateInsert操作を起動するために必要な情報をカプセル化します。RequiresUpdateModel属性のtrueの値は、操作を実行する前にモデル・レイヤーを更新する必要があることを指定します。詳細は、「操作を使用したコマンド・コンポーネント作成時の処理」を参照してください。

この操作により、コンテキスト・イベントが発生した場合、イベント定義も表示されます。イベントを使用するバインディングがページに含まれている場合、イベント・マッピングが表示されます。詳細は、「コンテキスト・イベントの使用方法」を参照してください。

PaymentType要素により、LOV_PaymentTypeId LOVを使用して支払いタイプ・コードのリストを表示するために使用される、リスト・バインディングが定義されます。ビュー・オブジェクトのLOVを使用したリスト作成の詳細は、「データバインドされた選択リストおよびシャトルの作成」を参照してください。

18.7.2.2 ページ定義ファイルで定義されるExecutablesバインディング・オブジェクト

Executablesバインディング・オブジェクトには次の種類があります。

- イテレータ: ビュー・オブジェクト・コレクション全体で反復処理するイテレータにバインドします。ページで使用されるコレクションごとに1つのイテレータ・バインディングがあります。ページ上のすべての値バインディングはイテレータ・バインディングを参照して、実行時にデータを伴って移入されたコンポーネント値を含む必要があります。
コレクションまたはコレクションの属性をページ上にドロップすると、イテレータ・バインディングが自動的に実行可能ファイルとして追加されます。イテレータ・バインディング・オブジェクトは、基礎となるADFのRowSetIteratorオブジェクトにバインドされます。このオブジェクトは現在のオブジェクトと現在の範囲情報を管理します。イテレータ・バインディングは、そのページで使用されている他のバインディング・オブジェクトに、現在のオブジェクトと範囲状態を公開します。

デフォルトでは、イテレータ・バインディングは、送信されたデータ変更を、そのデータがコミットされてデータソースに戻されるまでキャッシュするように構成されます。データ変更が送信されると、イテレータに関連付けられたバインディングを持つページ上のすべてのコンポーネントがリフレッシュされ、変更されたデータが表示されます。詳細は、「部分ページ・レンダリングおよびイテレータ・バインディングに関する必知事項」を参照してください。

イテレータの範囲は、そのページに表示する現在のオブジェクト・セットを表します。現在の範囲内の最大オブジェクト数は、イテレータのrangeSize属性で定義されています。たとえば、データ・コントロール内のコレクションに製品が含まれており、イテレータ範囲が25の場合は、コレクション内の最初の25の製品がページ上に表示されます。ユーザーがスクロール・ダウンすると、次の25製品が表示されます。ユーザーがスクロール・アップすると、前の25製品が表示されます。ビュー・オブジェクトで範囲ページ移動を使用している場合は、イテレータ・バインディングで範囲セットを一度に戻すように設定できます。詳細は、「大きい結果セットを効率的にスクロールするための範囲ページ移動の使用方法」を参照してください。

注意:

ページが2ページあり、それぞれイテレータ・バインディングが同じビュー・オブジェクトのイテレータにバインドされている(たとえば、異なる2ページに同じコレクションをドロップした)場合、両方のページのイテレータ・バインディングでrangeSize属性を同じにする必要があります。この属性が同じでないと、レンジ・サイズが小さい方のページによりイテレータが再実行され、他のページに予期しない結果が生じる可能性があります。

- メソッド・イテレータ:データ・コントロールでカスタム・メソッドによって戻されるコレクション全体で反復処理するイテレータにバインドします。
メソッド・イテレータ・バインディングは、常にメソッド・アクション・バインディング・オブジェクトに関連しています。メソッド・アクション・バインディングは、メソッドの起動方法およびメソッドが取得するパラメータ(該当する場合)の詳細をカプセル化します。メソッド・アクション・バインディング自体がメソッド・イテレータにバインドされ、データが提供されます。

データ・コントロールのカスタム・メソッドから、メソッド戻りコレクションまたはメソッド戻りコレクションの属性をページ上にドロップする場合のみ、メソッド・イテレータのExecutablesバインディング・オブジェクトが表示されます。アプリケーション・モジュール・データ・コントロールのみを使用する場合、イテレータ・バインディング・オブジェクトのみが表示されます。

- 変数イテレータ:バインディング・コンテナ内のすべての変数を他のバインディングに公開するイテレータにバインドします。コレクションごとにイテレータ・バインディングがありますが、1ページで使用されているすべての変数には、1つの変数イテレータ・バインディングしかありません。(変数イテレータは、バインディング・コンテナ変数を属性として持つ、単一のデータ・オブジェクトだけが含まれたコレクションを指すイテレータのようなものです。)
ページの変数は、バインディング・コンテナに対してローカルであり、バインディング・コンテナ・オブジェクトが存在する間のみ存在します。ページから収集したパラメータが要求されるデータ・コントロール・メソッドまたはデータ・コントロール操作を使用する際には、JDeveloperによって、ページ定義ファイル内のパラメータの変数が自動的に定義されます。属性バインディングは、ページ変数を参照できます。

変数イテレータには、variableおよびvariableUsageの2種類の変数のうち1つを含むことができます。variableタイプ変数は単純な値ホルダーですが、variableUsageタイプ変数は、ビュー・オブジェクトの名前付きバインド・パラメータに関連する値ホルダーです。変数をvariableUsageタイプとして定義すると、バインドされるビュー・オブジェクトの名前付きバインド変数からデフォルト値やUIコントロール・ヒントを継承できるようになります。

- ページ: テンプレートのページ定義ファイルにバインドします(テンプレートを使用している場合)。テンプレートを使用した作業の詳細は、「ページ・テンプレートの使用方法」を参照してください。

注意:

page要素を使用して別のページ定義ファイルにバインドすることもできます。ただし、実行時には、現在の受信ページ(レンダリングされたページが受信ページと異なる場合は、レンダリングされたページ)のバインディング・コンテナのみが、現在のリクエスト中にフレームワークにより自動的に作成されます。したがって、現在のページから別のページのバインド値にアクセスするには、(たとえば、バッキングBeanを使用して)現在のリクエストにそのページのバインディング・コンテナをプログラムで作成する必要があります。作成しない場合、そのページのバインド値は利用できなくなるか、現在のリクエストで有効にできません。

- 検索するリージョン: 検索が実行できるよう、名前付き基準をイテレータにバインドします。

- タスク・フロー: リージョンのタスク・フローのバインディング・コンテナをインスタンス化します。

- 複数タスク・フロー: リージョンのタスク・フローのバインディング・コンテナを、タスク・フローの配列からインスタンス化します。これは、不明な数のリージョンを含むページで役立ちます。たとえば、panelTabbedコンポーネントの各タブがリージョンで、ユーザーが実行時にタブを追加および削除できるような場合です。詳細は、「複数の不明なリージョンをレンダリングするページの構成」を参照してください。

実行時には、ExecutableバインディングはそのRefresh属性の値に基づいてリフレッシュされます。イテレータ・バインディングをリフレッシュすると、そのバインディングの基礎となるRowSetIteratorオブジェクトにバインディングを再接続します。バインディングをリフレッシュする前に、ADFランタイムにより、実行可能ファイルで指定されたRefresh属性およびRefreshCondition属性がすべて評価されます。Refresh属性は、実行可能ファイルが起動されるADFライフサイクル・フェーズを指定します。RefreshCondition属性は、実行可能ファイルが起動される条件を指定します。ブールEL式を使用して、RefreshCondition値を指定できます。RefreshCondition属性を空白のままにする場合は、trueと評価されます。

デフォルトでは、Refresh値はdeferredに設定されています。これは、バインディングが(たとえば、JSFページのEL式から)アクセスされないかぎり実行されないことを意味します。バインディングがコールされると、バインディングのパラメータ値が変更されるか、バインディング自体が変更されないかぎり再実行されません。

バインディングのリフレッシュ方法と、Refresh属性およびRefreshCondition属性の設定方法の詳細は、「JSFページ・ライフサイクルとADFページ・ライフサイクルについて」を参照してください。

次の例は、Summit ADFサンプル・アプリケーションのExecutablesバインディング・オブジェクトを示しています。

<executables>
<variableIterator id="variables"/>
<iterator Binds="OrdersForCustomer" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="OrdersForCustomerIterator" ChangeEventPolicy="ppr"/>
<iterator Binds="ItemsForOrder" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="ItemsForOrderIterator" ChangeEventPolicy="ppr"/>
<iterator Binds="InventoryForOrderItem" RangeSize="-1"
DataControl="BackOfficeAppModuleDataControl"
id="InventoryForOrderItemIterator" ChangeEventPolicy="ppr"/>
</executables>

例では、ページ上にOrdersForCustomerコレクションをADF表としてドロップすることにより、OrdersForCustomerIteratorという名前のイテレータ・バインディングが作成されました。ItemsForOrderコレクションを表としてドロップすることにより、ItemsForOrderIteratorという名前のイテレータ・バインディングが作成されました。InventoryForOrderItemコレクションをグラフとしてドロップすることにより、InventoryForOrderItemIteratorという名前のイテレータ・バインディングが作成されました。

OrdersForCustomerコレクションがItemsForOrderコレクションとマスター/ディテール関係にある場合、この2つのイテレータは自動的に同期されます。詳細は、「実行時に行われる処理: マスター/ディテール表およびフォームのADFイテレータ」を参照してください。

iterator要素のBinds属性により、イテレータが反復処理するコレクションが定義されます。RangeSize属性により、イテレータが一度にページ上に表示するオブジェクトの数が定義されます。RangeSizeの値が-1の場合、イテレータはコレクション内のすべてのオブジェクトを表示します。

ヒント:

通常、イテレータ・バインディングのデフォルト・レンジ・サイズは25です。ただし、イテレータ・バインディングが「リスト・バインディングの編集」ダイアログから作成される場合、そのレンジ・サイズは-1にデフォルト設定されるため、最初の25個のみでなく、すべての選択肢がリストに表示されます。

パフォーマンスに関するヒント

イテレータがADFビジネス・コンポーネント・レイヤーのビュー・オブジェクトからデータ・オブジェクトをフェッチするために必要なラウンドトリップの回数を減らすには、rangeSize属性を-1に設定します。これにより、ユーザーがオブジェクト間を移動するときに、サーバーへ何度もラウンドトリップせず、1回のラウンドトリップでオブジェクトがフェッチされます。

18.8 ADFデータ・バインディングのEL式の作成

データ・モデルからのデータを表示するため、WebページのUIコンポーネントは、JSF式言語(EL)式を使用してバインディング・オブジェクトにバインドされます。EL式は、バインディング・コンテナ内の特定のバインディング・オブジェクトを参照します。実行時に、JSFランタイムはEL式を評価し、ページ表示の際にコンポーネントにデータを移入するバインディング・オブジェクトから値を取得します。ユーザーがUIコンポーネントでデータを更新する場合、JSFランタイムは同じEL式に基づいて、対応するバインディング・オブジェクトに値を戻します。

ヒント:

マネージドBean内でEL式を使用する必要が生じる場合があります。マネージドBean内でのEL式の使用の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のEL式の作成に関する項を参照してください。

18.8.1 ADFデータ・バインディングEL式の作成方法

「データ・コントロール」パネルを使用してコンポーネントを作成すると、ADFデータ・バインディング式が自動的に作成されます。この式は、バインディング・オブジェクトのデータを表示するか、バインディング・オブジェクトのプロパティを参照する、すべてのコンポーネント属性に追加されます。事前作成済のそれぞれの式は、ページ定義ファイルで定義された、適切なバインディング・オブジェクトを参照します。これらのバインディング式は編集可能ですが、ADFバインディング式の基本構文に従っていれば、独自に作成することもできます。ADFデータ・バインディング式は、バインディング・オブジェクトからのデータを移入する任意のコンポーネント属性に追加できます。

JSFページの一般的なADFデータ・バインディングEL式は、次の構文を使用して、バインディング・コンテナ内のタイプの異なるバインディング・オブジェクトを参照します。

#{bindings.BindingObject.propertyName}

説明:

- bindingsは、式によって参照されているバインディング・オブジェクトが現在のページのバインディング・コンテナにあることを識別する変数です。すべてのADFデータ・バインディングEL式は、bindings変数で始まる必要があります。

- BindingObjectは、ページ定義ファイルで定義される、バインディング・オブジェクトのID、または属性については名前です。バインディングobjectIDまたは名前は、そのページ定義ファイル内で一意なものです。EL式は、パラメータ・バインディング、実行可能バインディングまたは値バインディングなど、ページ定義ファイル内のどのバインディング・オブジェクトでも参照できます。

- propertyNameは、各データバインドUIコンポーネントのデフォルトの表示方法を決定し、実行時のバインディング・オブジェクトのプロパティを設定する変数です。各タイプのバインディング・オブジェクトに対して、異なるバインディング・プロパティがあります。バインディング・プロパティの詳細は、「ADFバインディング・プロパティに関する必知事項」を参照してください。

たとえば、JSFページに表示される次の式を例にしてみます。

#{bindings.ProductName.inputValue}

bindings変数は、現在のページのバインディング・コンテナでバインドされた値を参照します。参照されているバインディング・オブジェクトはProductNameであり、これは属性バインディング・オブジェクトです。バインディング・プロパティはinputValueで、最初のProductName属性の値を戻します。

ヒント:

ページ定義ファイルのバインディング式ではドル記号($)またはハッシュ記号(#)の接頭辞を使用できますが、JSFページのEL式で使用できるのは、ハッシュ記号(#)の接頭辞のみです。

前述のように、「データ・コントロール」パネルを使用してUIコンポーネントを作成する場合、これらの式が組み込まれます。ただし、必要に応じて手動で式を作成することもできます。JDeveloperの式ビルダーは、UIコンポーネントがバインドされるその他の有効なオブジェクトに加え、ページ定義ファイルに定義されたバインディング・オブジェクトのリストを提供することにより、EL式の構築を支援するダイアログです。また、ADFバインディング・オブジェクトの階層リストやADFバインディング・オブジェクトの最も一般的に使用されるプロパティが提供されるため、ADFデータバインド式の作成や編集に特に便利です。バインディング・プロパティの詳細は、「ADFバインディング・プロパティに関する必知事項」を参照してください。

18.8.1.1 「プロパティ」ウィンドウから式ビルダーを開く手順

ビジュアル・エディタで項目を選択し、「プロパティ」ウィンドウを使用して特定の属性についてEL式を作成できます。

「プロパティ」ウィンドウから式ビルダーを開くには:

1. 「構造」ウィンドウまたはビジュアル・エディタでUIコンポーネントを選択します。

2. 図18-17に示すように、「プロパティ」ウィンドウで、プロパティ上にマウス・カーソルを移動し、プロパティの右側に表示されるアイコンをクリックします。

図18-17 「プロパティ」メニューのアイコン

3. ポップアップ・メニューで、図18-18に示すように「式ビルダー」(または「メソッド式ビルダー」)を選択します。

図18-18 「プロパティ」メニュー

18.8.1.2 式ビルダーの使用

式ビルダーを開いたら、これを使用してEL式を作成できます。

始める前に:

ADFモデル・レイヤーを使用する際に、EL式の作成方法に関する知識があると役立つ場合があります。詳細は、「ADFデータ・バインディングのEL式の作成」を参照してください。

式ビルダーの使用手順:

1. 「「プロパティ」ウィンドウから式ビルダーを開く手順」で示すように、「式ビルダー」ダイアログを開きます。

2. 式ビルダーの次の機能を使用して、ADFバインディング式を編集または作成します。

- 変数ツリーを使用して、バインディング式に含める項目を選択します。ツリーには階層形式のバインディング・オブジェクトが含まれます。ツリーの各アイコンは、式で使用できる様々なタイプのバインディング・オブジェクトを表します(各アイコンの説明は、表18-3を参照してください)。
ツリーを絞り込むには、ドロップダウン・フィルタを使用するか、検索フィールドに検索基準を入力します。ツリー内の項目をダブルクリックし、「式」ボックスに移動します。

- 演算子ボタンを使用して、式に論理演算子または算術演算子を追加します。

ヒント:

また、「式」ボックスに直接式を入力することもできます。

表18-3 式ビルダーの「ADFバインディング」ノードの下にあるアイコン

アイコン

説明

現在のページのバインディング・コンテナを参照する、bindingsコンテナ変数を示します。bindingsノードを開くと、現在のページのすべてのバインディング・オブジェクトが公開されます。

バインディング・コンテキスト全体を参照する、dataバインディング変数を示します(アプリケーション内の.cpxファイルから作成)。dataノードを開くと、アプリケーション内のページ定義ファイルが公開されます。

アクション・バインディング・オブジェクトを表します。このアイコンを使用するノードを開くと、有効なアクション・バインディング・プロパティのリストが公開されます。

イテレータ・バインディング・オブジェクトを表します。このアイコンを使用するノードを開くと、有効なイテレータ・バインディング・プロパティのリストが公開されます。

属性バインディング・オブジェクトを表します。このアイコンを使用するノードを開くと、有効な属性バインディング・プロパティのリストが公開されます。

リスト・バインディング・オブジェクトを表します。このアイコンを使用するノードを開くと、有効なリスト・バインディング・プロパティのリストが公開されます。

表バインディング・オブジェクトまたはツリー・バインディング・オブジェクトを表します。このアイコンを使用するノードを開くと、有効な表バインディング・プロパティおよびツリー・バインディング・プロパティのリストが公開されます。

ADFバインディング・オブジェクト・プロパティを表します。ADFプロパティの詳細は、「ADFバインディング・プロパティに関する必知事項」を参照してください。

パラメータ・バインディング・オブジェクトを表します。

Beanクラスを表します。

メソッドを表します。

18.8.2 ADFバインディング・プロパティに関する必知事項

式ビルダーを使用してデータバインドされたコンポーネントを作成すると、EL式によって、特定のADFバインディング・プロパティが参照される場合があります。実行時には、これらのバインディング・プロパティによって、データバインドUIコンポーネントのデフォルトの表示方法や、イテレータ・バインディング固有のパラメータなどが定義されます。ADFバインディング・プロパティは、Oracle APIによって定義されます。各バインディング・タイプで使用できるプロパティの完全なリストは、「Oracle ADFバインディング・プロパティ」を参照してください。

特定のプロパティに割り当てられる値は、ページ定義ファイルで定義されます。たとえば、イテレータ・バインディングには、イテレータが一度に表示する行数を指定する、RangeSizeというプロパティがあります。RangeSizeに割り当てられた値は、次の例に示すようにページ定義ファイルで指定されます。

<iterator Binds="ItemsForOrder" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="ItemsForOrderIterator" ChangeEventPolicy="ppr"/>

18.9 単純なUIの最初の開発の使用

「データ・コントロール」パネルを使用すると、バインドされたコンポーネントを1回のドラッグ・アンド・ドロップ・アクションで設計および作成できますが、基本的なUIコンポーネントを先に作成して後からバインディングを追加した方がよい場合があります。たとえば、ページで宣言的なコンポーネントが使用されている場合、まず宣言的なコンポーネントをドロップしてから正しいADFコントロールにバインドする必要があります。宣言的なコンポーネントは、他のADF Facesコンポーネントで構成された再利用可能な複合UIコンポーネントです。プロジェクトにインポートされた宣言的なコンポーネントは、標準のADF Facesコンポーネントと同様に、「コンポーネント」からページにドロップできます。宣言的なコンポーネント全体ではADFデータ・バインディングは使用できませんが、宣言的なコンポーネントが一旦ページにドロップされると、宣言的なコンポーネントを構成する個々のコンポーネントのADFデータ・バインディングを使用できます。宣言的なコンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の宣言コンポーネントの使用に関する項を参照してください。

注意:

最終的にページのUIコンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールを使用します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

Webページの設計時に、ADFバインディングは特定のADF Facesタグまたはそれに相当するJSF HTMLタグにしか追加できないことに留意してください。表18-4に、後からADFバインディングを追加できるADF FacesおよびJSFのタグを示します。

ヒント:

JSFの参照実装UIコンポーネント・タグをADFバインディングとともに使用できるようにするには、プロジェクト・プロパティの「ADFビュー設定」で「JSFデータ・バインディングにJSF HTMLウィジェットを含む」オプションを選択する必要があります。しかし、ADF Facesタグを特にADFバインディングとともに使用すると、JSFの参照実装タグを使用するときより優れた機能を発揮します。

表18-4 ADFバインディングに使用できるタグ

ADFバインディングで使用されるADF Facesタグ

相当するJSF HTMLタグ

テキスト・フィールド

af:inputText

h:inputText

af:outputText

h:outputText

af:outputLabel

h:outputLabel

af:inputDate

該当なし

表

af:table

h:dataTable

アクション

af:button

h:commandButton

af:link

h:commandLink

af:commandMenuItem

該当なし

選択リスト

af:inputListOfValues

該当なし

af:selectOneChoice

h:selectOneMenu

af:selectOneListbox

h:selectOneListbox

af:selecOneRadio

h:selectOneRadio

af:selectBooleanCheckbox

h:selectBooleanCheckbox

問合せ

af:query

該当なし

af:quickQuery

該当なし

ツリー

af:tree

該当なし

af:treeTable

該当なし

バインディングをUIコンポーネントに追加する前に、次のガイドラインを実行します。

- 「JSF JSPの作成」ウィザードでJSFページを作成する場合は、「マネージドBean」タブの「マネージドBeanでUIコンポーネントを自動公開しない」オプションを選択します。
このオプションにより、偶発的なプログラム操作に応じてページ内のすべてのUIコンポーネントを対応するバッキングBeanのプロパティに自動的に関連付ける、JDeveloperの自動バインディング機能が無効になります。自動バインディング機能を使用すると、後で、ADFバインディングを追加した後にマネージドBeanのバインディングを削除する必要があります。マネージドBeanのUIコンポーネント・プロパティのバインディングがADFバインディングに影響を及ぼすことはありませんが、JSFコードに存在するとわかりにくくなります。マネージドBeanの詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

- ADF Facesのタグ・ライブラリを追加します。
ADFバインディングをJSFコンポーネントに追加できますが、ADF Facesコンポーネントの方が、特にADFバインディングと組み合せる場合には優れた機能を発揮します。

18.9.1 ADFモデル・データ・バインディングの既存のUIコンポーネントへの適用方法

「構造」ウィンドウを使用して、ADFモデル・バンディングをコンポーネントに適用します。

始める前に:

UI優先開発に関する知識が役立つ場合があります。詳細は、「単純なUIの最初の開発の使用」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成し、ページに任意のコンポーネントを追加します。

ADFモデル・データ・バインディングを適用するには:

1. ビジュアル・エディタの「設計」ページで、ADFバインディングを追加するUIコンポーネントを選択します。

コンポーネントは、表18-4に示すタグのいずれかである必要があります。コンポーネントをビジュアル・エディタで選択すると、図18-19に示すように、「構造」ウィンドウのそのコンポーネント・タグが同時に選択されます。

図18-19 JDeveloperの「構造」ウィンドウ

2. 「構造」ウィンドウで、UIコンポーネントを右クリックし、ポップアップ・メニューで「ADFコントロールにバインド」を選択します。

注意:

「ADFコントロールにバインド」メニュー・オプションが表示されるには、プロジェクトにすでにデータ・コントロールが含まれている必要があります。データ・コントロールが含まれていない場合は、「プレースホルダ・データ・コントロールによるページの設計」で説明しているように、プレースホルダ・データ・コントロールを使用する必要があります。

3. 「ADFコントロールにバインド」ダイアログで、UIコンポーネントをバインドするデータ・コントロールを選択します。選択されたUIコンポーネントと互換性がないコントロールを選択すると、JDeveloperにより通知されます。

18.9.2 ADFモデル・データ・バインディングのUIコンポーネントへの適用時の処理

「データ・コントロール」パネルを使用する場合、「「データ・コントロール」パネルの使用時の処理」で説明しているように、必要なADFオブジェクトはすべて自動的に作成されます。

19 ADFモデル・レイヤーでの検証の使用

この章では、Oracle ADFアプリケーションのADFモデル・レイヤー内で検証ルールを使用する方法について説明します。

この章の構成は、次のとおりです。

- ADFモデル・レイヤー検証について

- ADFモデル・レイヤーでの検証規則の定義

- エラー処理のカスタマイズ

19.1 ADFモデル・レイヤー検証について

Modelレイヤーでは、ADFモデル検証規則を特定のページのバインディングの属性として設定できます。ユーザーがフィールド内のデータを編集または入力してフォームを送信したときに、設定した規則および条件に対してバインドされたデータが検証されます。検証に失敗すると、アプリケーションでエラー・メッセージが表示されます。

エンティティ・オブジェクトのビジネス・ドメイン・レイヤーに検証規則をすでに設定している場合は、ADFモデル検証を追加する必要はありません。ADFビジネス・コンポーネント・ベースのFusion Webアプリケーションでは、アプリケーション・モジュールのデータ・コントロール以外のデータ・コントロールを使用しないかぎり、ADFモデル検証を使用する必要はありません。

19.1.1 ADFモデル・レイヤー検証のユースケースと例

アプリケーションでADFビジネス・コンポーネントに基づかないデータ・コントロールを使用している場合は、ADFモデル・レイヤー検証を使用してユーザーが入力したデータの品質を確保できます。

ベスト・プラクティス

可能な場合はビジネス・レイヤー検証を使用します。ただし、次の例に示すような場合には、モデル・レイヤー検証の使用が必要になる場合があります。

- ビジネス・レイヤーが宣言的検証をサポートしていない場合。

- 負荷の高いラウンドトリップ(Webサービスとのバインドなど)が開始される前に検証を実行する場合。

- パラメータを使用して作成されたフォームを検証する必要がある場合(executeWithParams操作を使用する場合など)。

また、サーバーとのラウンドトリップの前に検証を実行する場合、クライアント側の検証を使用することもできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の検証の追加に関する項を参照してください。

アプリケーションで、ビジネス・レイヤー検証に加えてモデル・レイヤー検証の使用も保証されている場合は、ADFビジネス・コンポーネント・オブジェクトで利用できる宣言的検証機能の多くをモデル・レイヤーでも利用できます。

19.1.2 ADFモデル・レイヤー検証の追加機能

モデル・レイヤー認証を使用する前に、他のADF検証機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- ADFビジネス・コンポーネント・アプリケーション・モジュールのデータ・コントロールを使用する場合、モデル・レイヤー検証を使用する必要はありません。可能であれば、すべての検証規則を、ビジネス・レイヤー内の再使用と管理が容易で一元管理されたエンティティ・オブジェクトに定義することを検討してください。詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。

- ページ・レベルで利用できる宣言的検証機能の多くは、Beanレベルでも利用できます(その場合はデータ・コントロール構造ファイルで実装します)。データ・コントロール構造ファイルの検証規則は、データ・コントロールが使用されるすべての場合に適用されるため、非常に役立ちます。データ・コントロール構造ファイルでの検証ルールの実装の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』の「データ・コントロールへのビジネス・ロジックの追加」を参照してください。

19.2 ADFモデル・レイヤーでの検証規則の定義

バインディングの属性に対するADFモデル検証は、ページ定義ファイルで構成できます。モデル・レイヤーの検証規則は、特定のページのバインディング属性に対して、その対象を含むフォームの送信時に実行されます。

オプションで、skipValidationプロパティをtrueに設定すると、ADFモデル検証をバイパスできます。skipValidationをskipDataControlsに設定して、トランザクションを検証せずに、バインド・オブジェクトを検証できます。たとえば、データ入力を受け付けるポップアップ・ウィンドウを開く表アクションがあるときに、表でコミットする前にビュー・レイヤーでこれらの入力を検証できるようにする場合は、skipValidationをskipDataControlsに設定します。skipValidationプロパティは、「構造」ウィンドウでページ定義ファイルのルート・ノードを選択した後に、「プロパティ」ウィンドウに表示されます。

19.2.1 ADFモデル・レイヤー検証の追加方法

ADFモデル検証をページ定義ファイルに設定します。検証規則を定義し、規則に違反した場合に表示するエラー・メッセージを設定します。

表19-1に、バインディングの属性に対して構成できるADFモデル検証規則を示します。

表19-1 ADFモデル検証規則

バリデータ・ルール名

説明

比較

属性の値とリテラル値を比較する。

リスト

値が値リスト内にあるかどうかを検証する

範囲

値が値範囲内にあるかどうかを検証する。

長さ

値の文字またはバイト・サイズをサイズおよびオペランド(greater than or equal toなど)に対して検証する。

正規表現

Java正規表現構文を使用してデータを検証する。

必須

属性にその値が存在するかどうかを検証する。

始める前に:

モデル・レイヤーでの検証規則の使用に関する知識があると役立つ場合があります。詳細は、「ADFモデル・レイヤーでの検証規則の定義」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFモデル・レイヤー検証の追加機能」を参照してください。

次のタスクを完了する必要があります。

- ページにコンポーネントを作成します。このコンポーネントにはバインディング属性が必要です。

ADFモデル検証規則を作成するには:

1. 「アプリケーション」ウィンドウで、ルールを作成するバインディングを含むページ定義をダブルクリックします。

2. 「構造」ウィンドウで、属性、リストまたは表バインディングを選択します。

3. 「プロパティ」ウィンドウで、「詳細」ドロップダウン・メニューをクリックし、「検証ルールの編集」を選択します。

4. 「検証ルール・エディタ」ダイアログで、バインディング・ノードを開き、属性名を選択して、「新規」をクリックします。

5. 「検証ルールの追加」ダイアログで、検証規則を選択し、必要に応じて規則を構成します。

6. 「失敗処理」タブをクリックして、ルールに違反した場合に表示するメッセージを構成します。

19.2.2 実行時に行われる処理: Model検証規則

ユーザーがデータを送信すると、送信された値がNULL以外の値か、少なくとも1つの文字からなる文字列値であった場合、コンポーネントに設定されているすべてのバリデータが1つずつコールされます。コンポーネントのf:validatorタグはバインディングのvalidatorプロパティにバインドされるため、モデルに設定されている検証ルーチンがアクセスされて実行されます。

続いて、プロセスは次のコンポーネントに進みます。すべての検証が正常に完了すると、モデル値更新フェーズが開始され、ローカル値を使用してモデルが更新されます。いずれかの検証が失敗すると、現在のページがエラー・メッセージとともに再表示されます。

19.2.3 デフォルトのエラー処理に関する必知事項

例外が発生すると、デフォルトの動作ではADF Facesのエラー・ダイアログにリーフレベル・エラーのみ表示されます。ADFコントローラのデフォルトのエラー処理メカニズムは、ページ・バインディング・コンテナから例外のリストを取得し、各エラーの表示方法を決定します。例外がJboExceptionでない場合、Facesエラー・メッセージが例外メッセージとともに表示されます。

例外がJboExceptionの場合、エラー処理メカニズムはネストされた例外に再帰的にドリル・ダウンし、一意の例外ごとに単一のFacesエラー・メッセージを表示します。ただし、例外にJboWarning.HIDE_DETAIL_EXCEPTIONS_HINTがある場合、エラー処理メカニズムはネストされた例外にドリル・ダウンしません。

また、エラー処理メカニズムは、各例外のバインディング・エラーのリストを取得し、エラーをレポートしたバインディングに関連付けられているコンポーネントに対するFacesエラー・メッセージを表示します。

19.3 エラー処理のカスタマイズ

デフォルトのDCErrorHandlerImplクラスを拡張するカスタム・エラー・ハンドラを使用して、エラーをレポートできます。カスタム例外ハンドラ・クラスを登録するためにコードを記述する必要はありません。かわりに、「構造」ウィンドウでDataBindings.cpxファイルのルート・ノードを選択した後、「プロパティ」ウィンドウを使用してErrorHandlerClassプロパティを、使用するエラー・ハンドラの完全修飾名に設定します。

カスタム・エラー・ハンドラには、次のオーバーライド可能なメソッドを含めることができます。

- reportException(): 発生した例外をレポートするためにコールされます。レポートされた例外を分析するようにオーバーライドできます。

- getDisplayMessage(): 発生したエラーごとにJSFにレポートされるメッセージを戻します。カスタム・エラー・ハンドラで特定の例外をクライアントにレポートする必要がない場合は、nullを戻します。

- getDetailedDisplayMessage(): 発生したエラーごとにJSFにレポートされるメッセージの詳細部分を、StringオブジェクトまたはHTMLとして戻します。カスタム・エラー・ハンドラで特定の例外をクライアントにレポートする必要がない場合は、nullを戻します。

- skipException(): ユーザー向けに表示される最終的なエラー・リストに、ネストされた例外から各アイテムを表示するかどうかに応じたブール値を戻します。このメソッド・オーバーライドにより、特定の例外タイプをチェックし、ビジネス・シナリオに基づいて、このタイプをリストに表示するかどうかを判断するロジックを実装できます。

次の例は、DCErrorHandlerImplクラスを拡張するカスタム・エラー・ハンドラを示し、ユーザーに対して表示されるリストに出現すべきでない例外をスキップするために必要なskipException()メソッドに対するオーバーライドを示しています。

package view.controller.fwkext;

import java.sql.SQLIntegrityConstraintViolationException;

import java.util.ArrayList;
import java.util.List;

import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCErrorHandlerImpl;

import oracle.jbo.CSMessageBundle;
import oracle.jbo.DMLConstraintException;
import oracle.jbo.JboException;

public class CustomErrorHandler extends DCErrorHandlerImpl {

List<ExceptionMapper> exceptionMapperList = new ArrayList<ExceptionMapper>();

public CustomErrorHandler() {
super();
exceptionMapperList.add(new DisableJboExceptionCodesMapper());
}

public void reportException(DCBindingContainer bc, Exception ex) {
for (ExceptionMapper mapper : exceptionMapperList) {
if (mapper.canMapException(ex)) {
ex = mapper.mapException(ex);
}
}
super.reportException(bc, ex);
}

/**
* If an exception is a RowValException or a TxnValException and they
* have nested exceptions, then do not display it. This example shows
* an implementation that skips the SQLIntegrityConstraintViolationException
* from displaying in the error final list displayed to the user.
*/
@Override
protected boolean skipException(Exception ex) {

if (ex instanceof DMLConstraintException) {
return false;
} else if (ex instanceof SQLIntegrityConstraintViolationException) {
return true;
}
return super.skipException(ex);
}

}

エラー・ハンドラ・クラスには、カスタム・クラスの名前と一致するデフォルトのコンストラクタが必要です。たとえば、カスタム・ハンドラ・クラスMyErrorHandlerを作成した場合、例外エラー・ハンドラは、次の例に示すようにデフォルトのコンストラクタを起動します。この規則に従うと、クラス名のみで動的な起動が可能になります。

ErrorHandlerClass="viewcontroller.MyErrorHandler"
public MyErrorHandler()
{
super();
}

19.3.1 メッセージの詳細部分のカスタマイズ方法

メッセージの詳細部分をカスタマイズし、使用する予定のある場合は、このメッセージを取得し、処理するために、カスタム・エラー・ハンドラを作成し、getDetailedDisplayMessageメソッドを実装することができます。最終的なメッセージは、ビュー・レイヤーに渡され、他のメッセージと統合されます。

メッセージの詳細部分をカスタマイズするには:

1. デフォルトのDCErrorHandlerImplクラスを拡張するカスタム・エラー・ハンドラを作成します。

2. このクラスで、DCErrorMessageオブジェクトを戻すgetDetailedDisplayMessageメソッドをオーバーライドします。

次の例は、カスタム・エラー・ハンドラ・クラスでのgetDetailedDisplayMessageメソッドの実装を示しています。

public final class MyErrorMessageHandler extends DCErrorHandlerImpl {
public MyErrorMessageHandler (){
super();
}
public DCErrorMessage getDetailedDisplayMessage(BindingContext ctx,
RegionBinding ctr,
Exception ex) {
...
return new MyDCErrorMesssage(ctr, ex);
}
}

3. DCErrorMessageインタフェースを実装するカスタム・クラスを作成します。このクラスはgetHTMLTextメソッドおよびgetTextメソッドを実装する必要があります。

getHTMLTextメソッドに、実際の処理を実行するためのコードを追加しますが、インタフェースの要件を満たすには、getTextの実装も必要です。

4. getHTMLTextの実装では、エラー・メッセージを作成、処理するためのコードを追加します。

getDetailedDisplayMessageのgetHTMLTextは、エラー・メッセージの最終版をHTMLフラグメントとして戻す必要があります。このフラグメントは、ページのHTMLコードに挿入されます。このため、getDetailedDisplayMessageによりメッセージが戻される前に、テキスト・メッセージに対して、必要な前処理をすべて実行しておく必要があります。たとえば、ローカライズしたメッセージの取得や、メッセージの順番を右から左に変更するなどの処理が必要である場合は、メッセージが戻される前に行います。

次の例は、このインタフェースの実装を示しています。

public final class MyDCErrorMesssage implements DCErrorMessage {
RegionBinding m_regionBinding;
Exception m_ex;
public MyDCErrorMesssage(RegionBinding ctr, Exception ex) {
super();
this.m_regionBinding = ctr;
this.m_ex = ex;
}
public String getText() {
...
return "Message String";
}
public String getHTMLText() {
...
/* Add code to process the message, including localization */
/* and right-to-left directional requirements. */
/* Return the message as the finalized HTML fragment.*/
return "<html><b>error</b> message details</html>";
}
}

HTMLタグを使用してメッセージを書式化するには、例に示すように、メッセージを<html></html>タグで囲む必要があります。エラー・メッセージでは次のHTMLタグのみを使用できます。

- <span>

- <b>

- <a>

- <i>

- <em>

- <br>

- <hr>

- <li>

- <ol>

- <ul>

- <p>

- <tt>

- <big>

- <small>

- <pre>

19.3.2 カスタム・エラー・ハンドラから情報メッセージを表示する方法

エラー・ハンドラを使用すると、ADFモデル・レイヤーのカスタム検証を使用してアプリケーションの警告に対して情報メッセージを表示できます。モデル・レイヤー検証を使用するアプリケーションでは、すべてのエラーと警告について、アプリケーションCPXレベルでカスタム・エラー・ハンドラを使用する必要があります。

始める前に:

モデル・レイヤーでのカスタム検証の動作に関する知識があると役立つ場合があります。詳細は、「エラー処理のカスタマイズ」を参照してください。

また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFモデル・レイヤー検証の追加機能」を参照してください。

JDeveloperを起動し、カスタム・エラー・ハンドラを追加するアプリケーションを開く必要もあります。

情報メッセージを表示する手順

1. データ・モデル・プロジェクトで、JboWarningを拡張するクラスを作成します。次に例を示します。

public class InformationalMessage extends JboWarning
{
public static final String INFO_PROPERTY = "$InformationalMessage$INFO";
public InformationalMessage(String message)
{
super(message, "", new Object[]{INFO_PROPERTY});
}
}

2. アプリケーション・モジュール実装クラスで、メソッドを追加し、クライアント・メソッドとして公開します。次に例を示します。

public void addInformationMessageTest()
{
addWarning
(new InformationalMessage("Testing. This is an information message"));
}

3. 「エラー処理のカスタマイズ」で説明するように、ビュー・コントローラ・プロジェクトで、カスタム・エラー・ハンドラ・クラスを作成します。

4. 作成したカスタム・エラー・ハンドラをデータ・バインディング・ファイル(DataBindings.cpx)に追加します。次に例を示します。

<Application xmlns="http://xmlns.oracle.com/adfm/application"
id="DataBindings" SeparateXMLFiles="false"
Package="my.view" ClientType="Generic"
ErrorHandlerClass="my.view.CustomErrorHandler">
<pageMap>
<page path="/Test.jspx" usageId="my_view_TestPageDef"/>
</pageMap>

5. メソッドをテストするには、クライアント・アプリケーション・モジュール・メソッドを.jspxページにコマンド・ボタンとしてドロップして、情報メッセージを呼び出すことができます。

.jspxファイルを実行し、ボタンを押すと、情報メッセージが表示されます。

19.3.3 複数スレッドを処理するエラー・ハンドラの記述方法

Oracle ADFでは、作成されるBindingContextオブジェクトごとにカスタム・エラー・ハンドラのインスタンスを1つ作成します。Oracle ADFでは、同じ論理エンド・ユーザー・セッションからの同時Webリクエストをシリアライズするため、通常、複数スレッドは同じエラー・ハンドラを同時に使用しません。ただし、スレッドセーフのカスタム・エラー・ハンドラを保証するには、JboExceptionでsetProperty() APIを使用します。このメソッドは、表示用に例外がJSF FacesMessageオブジェクトに変換されるときに、後で必要になる可能性があるヒントをすべて例外オブジェクト自体に格納します。

20 プレースホルダ・データ・コントロールによるページの設計

この章では、Oracle ADFアプリケーションでプレースホルダ・データ・コントロールを作成および使用する方法について説明します。ここでは、プレースホルダ・データ型の作成方法を、マスター/ディテール関係も含めて示します。また、サンプル・データの作成方法とインポート方法についても説明します。

この章の内容は次のとおりです。

- プレースホルダ・データ・コントロールについて

- プレースホルダ・データ・コントロールの作成

- プレースホルダ・データ型の作成

- プレースホルダ・データ・コントロールの使用

20.1 プレースホルダ・データ・コントロールについて

アプリケーション開発は通常、技術的実装とユーザー・インタフェース設計という2つの異なるプロセスに分けられます。一般的に、これらのプロセスは非常に異なるスキル・セットを持つ別々のチームによって実行されます。この2つのチームは、データ優先アプローチまたはUI優先アプローチ、もしくはこの2つを多少重複させた形で協業することができます。どちらのアプローチでも、通常、両チームは繰り返し協力して作業し、毎回アプリケーションを改良していきます。

データ優先アプローチでは、モデルまたはデータ・コントロールが最初に作成されます。設計者は次に、データ・コントロールをページにUIコンポーネントとしてドラッグ・アンド・ドロップして、レイアウトおよびページ・フローを作成します。モデル・データは、コンポーネントに自動的にバインドされます。このアプローチでは、設計者が作業を進める前に、データ・モデルが存在する必要があります。

UI優先アプローチでは、設計者は「コンポーネント」ウィンドウのコンポーネントを使用してレイアウトを作成します。データ・コントロールが使用可能になると、UIコンポーネントがそれらのコントロールにバインドされます。このアプローチでは、開発を評価するには、レイアウトおよびページ・フローの大半が確認可能である必要があります。ただし、データ・コントロールが使用可能になってコンポーネントにバインドされるまで、アプリケーションではその設計の意図を十分に伝えていない場合があります。たとえば、マスター/ディテール関係があるアプリケーションは、その関係を動的に駆動する実際のデータがある場合に、最も適切に確認されます。

プレースホルダ・データ・コントロールは、簡単に作成できる、十分な機能を備えた代理のデータ・コントロールで、設計開発プロセスの効率的な迅速化を可能にします。UI設計者は、プレースホルダ・データ・コントロールを使用することで、実際のデータ・コントロールを使用可能にする必要なく、ページ・レイアウトおよびページ・フローを作成できます。これらのプレースホルダ・コントロールにサンプル・データをロードすると、アプリケーションの実行を現実的にシミュレートして設計を評価できます。実際のデータ・コントロールが準備できた段階で、UIコンポーネントを簡単にリバインドしてアプリケーションを完成できます。

プレースホルダ・データ・コントロールの作成は完全に宣言的なプロセスであり、コーディングは不要です。基礎となるモデル、データソース・テクノロジ、実際のデータベース・スキーマ、実際の本番データ・コントロールにおける複雑な関係などに関する深い知識は必要ありません。プレースホルダ・データ・コントロールには、既存のデータソースやデータベース接続が不要です。複数の属性を使用して複数のデータ型を定義できます。また、データ型の間にネストされたマスター/ディテール階層を定義できます。プレースホルダ・データ・コントロールには、「Execute」、「Next」および「Create」などの同じ組込み操作があります。暗黙的に作成された名前付き基準アイテムを使用すると、ビュー・オブジェクトおよびビュー基準が使用できる場合と同様に、検索フォームを作成できます。

20.1.1 プレースホルダ・データ・コントロールのユースケースと例

複雑なアプリケーションの多くでは、UIの設計によってモデルやデータソースの開発が実質的に促進される場合があります。このUI優先のシナリオでは、プレースホルダ・データ・コントロールとサンプル・データを用意することが、アプリケーションの動作を適切にモデル化するために不可欠です。状況によっては、本番データ・コントロールを使用できる場合でも、UI設計者がその柔軟性と使用しやすさからプレースホルダ・データ・コントロールを使用することを選択する場合があります。

プレースホルダ・データ・コントロールは、様々な状況で使用できます。設計の確認および開発に使用する以外に、利便性の調査や概念の証明要件のための実際的なランタイム・モックアップの開発にも使用可能です。また、データ・モデルがまだ用意できていない段階でのデモの作成にも使用できます。

20.1.2 プレースホルダ・データ・コントロールの追加機能

プレースホルダ・データ・コントロールを使用する前に、いくつかのデータ・アクセス機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- プレースホルダ・データ・コントロールを使用した初期設計が終わり、最終的なデータ・コントロールが用意できたら、そのコンポーネントをリバインドできます。コンポーネントのリバインドの詳細は、「データバインドされた基本的なページの作成」および「ADFによるデータバインドされた表の作成」を参照してください。

- プレースホルダ・データ型の属性は、値リスト(LOV)に構成できます。LOVの詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

- 標準データ・コントロールにおけるマスター/ディテール・データ・コレクションと同様に、プレースホルダ・データ型の間にマスター/ディテール関係を作成できます。マスター/ディテール・フォームおよび表の詳細は、「マスター/ディテール・データの表示」を参照してください。

- マスター/ディテール階層でプレースホルダ・データ型を定義すると、その関係を定義するビュー・リンクがJDeveloperによって作成されます。ビュー・リンクの詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。

- プレースホルダ・データ・コントロールを使用して、検索フォームを開発できます。問合せ検索フォームの詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

- プレースホルダ・データ・コントロールをADFライブラリJARとして再利用可能なコンポーネントにパッケージ化する場合があります。再利用可能なコンポーネントおよびADFライブラリの詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

20.2 プレースホルダ・データ・コントロールの作成

プレースホルダ・データ・コントロールは、「新規ギャラリ」を使用してプロジェクトに追加します。作成後のプレースホルダ・データ・コントロールは、「データ・コントロール」パネルにノードとして表示されます。このアイコンは、標準データ・コントロールのアイコンとは異なります。プレースホルダ・データ・コントロールには、「操作」ノードのかわりに「ビルトイン操作」ノードがあります。「ビルトイン操作」ノードにはCommitおよびRollback操作が含まれますが、データの実際のデータソースがないため、コミットまたはロールバックは実行されません。

データ・コントロールを最初に作成したときには、データ型が関連付けられていません。データ型は、「プレースホルダ・データ型の作成」の項の説明に従って、手動で作成する必要があります。

20.2.1 プレースホルダ・データ・コントロールの作成方法

プレースホルダ・データ・コントロールは、JDeveloperではプロジェクト・レベルで定義されます。プレースホルダ・データ・コントロールを作成する前に、プロジェクトが作成済である必要があります。

始める前に:

プレースホルダ・データ・コントロールを作成する場合のオプションに関する知識があると役立つ場合があります。詳細は、「プレースホルダ・データ・コントロールの作成」を参照してください。

また、プレースホルダ・データ・コントロールの使用後に追加できる機能についても理解しておくと役立ちます。詳細は、「プレースホルダ・データ・コントロールの追加機能」を参照してください。

プレースホルダ・データ・コントロールを作成するには:

1. 「アプリケーション」ウィンドウで、プレースホルダ・データ・コントロールを追加するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「Business Tier」を展開し、「Data Controls」を選択した後、「プレースホルダ・データ・コントロール」を選択して「OK」をクリックします。

3. 「プレースホルダ・データ・コントロール」ダイアログ(図20-1を参照)で、次の情報を入力します。

- 名前: プレースホルダ・データ・コントロールの名前

- パッケージ: プレースホルダ・データ・コントロールの参照に使用されるパッケージ名

- 説明: プレースホルダ・データ・コントロールの説明(オプション)

図20-1 新規の「プレースホルダ・データ・コントロール」ダイアログ

4. 「OK」をクリックします。

20.2.2 プレースホルダ・データ・コントロールの作成時の処理

プレースホルダ・データ・コントロールを作成するとき、データ・コントロールの保存先に選択したパッケージは、「アプリケーション」ウィンドウのプロジェクト・ノードに表示されます。データ・コントロールXMLファイルPlaceholderDataControl.xmlがこのパッケージの下に表示されます。ここで、PlaceholderDataControlはプレースホルダ・データ・コントロールの名前です。次の例は、サンプル・ファイルPlaceholder01.xmlを示しています。これは、Placeholder01データ・コントロールが作成されたときに作成されたファイルです。

<?xml version='1.0' encoding='windows-1252' ?>
<AppModule
xmlns="http://xmlns.oracle.com/placeholder"
Name="Placeholder01" >
</AppModule>

DataControls.dcxファイルが未定義の場合、このファイルもJDeveloperにより作成され、次の例に示すように、プレースホルダ・データ・コントロールのエントリが追加されます。

<?xml version="1.0" encoding="UTF-8" ?>
<DataControlConfigs xmlns="http://xmlns.oracle.com/adfm/configuration"
version="12.1.2" id="DataControls"
Package="model">
<PlaceholderDataControl SupportsTransactions="true" SupportsFindMode="true"
SupportsResetState="true" SupportsRangesize="true"
SupportsSortCollection="true"
FactoryClass=
"oracle.adf.model.placeholder.DataControlFactoryImpl"
id="Placeholder01"
xmlns="http://xmlns.oracle.com/adfm/datacontrol"
Definition="model.prototype.Placeholder01"
Package="model.prototype"/>
</DataControlConfigs>

「データ・コントロール」パネルには、このプレースホルダ・データ・コントロールが他のデータ・コントロールとともにルート・ツリーに表示されます。データ型が未定義のプレースホルダ・データ・コントロールには、図20-2に示すように、CommitおよびRollbackの組込み操作のみが表示されます。

図20-2 「アプリケーション」ウィンドウと「データ・コントロール」パネル

20.3 プレースホルダ・データ型の作成

標準データ・コントロールは、そのデータ・コレクションおよび属性をモデルまたはビジネス・サービス・レイヤーにある基礎となるデータソースから取得します。たとえば、アプリケーション・モジュールのデータ・コントロールは、そのデータ・コレクションをビュー・オブジェクトおよび関連データベース表から取得します。

プレースホルダ・データ・コントロールには、データ・コレクションのかわりに、プレースホルダ・データ型があります。プレースホルダ・データ・タイプは、データ・コレクションに似ています。これをページにドロップすると、フォーム、表およびツリーなどの複雑なコンポーネントを作成できます。また、入力テキスト、出力テキスト、選択肢などの個々のコンポーネントとしてページにドロップできる属性セットも備えています。属性の中には、LOVとして定義できるものもあります。

プレースホルダ・データ・コントロールを初めて作成したとき、このコントロールにはデータ・タイプは1つもありません。これは、プレースホルダ・データ・コントロールが基礎となるデータベース表を参照していないからです。1つ以上のプレースホルダ・データ・タイプを宣言的に作成する必要があります。データ・タイプそれぞれについて、属性名、タイプ、デフォルトUIコンポーネントなどのオプションを指定します。アプリケーション・モジュールの複数のデータ・コレクションと同様、データ・コントロールについても複数のデータ・タイプを作成できます。

作成されたプレースホルダ・データ・タイプはその後、そのプレースホルダ・データ・コントロールの子ノードとして表示されます。また、ビルトイン操作ノードと、標準の操作セットも持っています。これは、標準データ・コントロールにあるビュー・オブジェクトの名前付きビュー基準に類似した「すべての問合せ可能な属性」項目を含む「名前付き基準」ノードを持ちます。「すべての問合せ可能な属性」項目をドラッグし、ページにドロップして、問合せやクイック問合せ検索フォームを作成できます。標準データ・コントロールでは、ビュー・オブジェクトに複数のビュー基準を作成できます。プレースホルダ・データ・タイプには実際のビュー・オブジェクトはないため、使用できる「すべての問合せ可能な属性」項目は1つのみです。問合せ検索フォームの詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

標準データ・コントロールにおけるマスター/ディテール・データ・コレクションと同様に、プレースホルダ・データ型の間にマスター/ディテール関係を作成できます。マスター/ディテール・データ型をページにドロップすると、マスター/ディテール・フォームおよび表を作成できます。マスター/ディテール・フォームおよび表の詳細は、「マスター/ディテール・データの表示」を参照してください。

JDeveloperでは、同じプロジェクトの他のプレースホルダ・データ・コントロールに作成したプレースホルダ・データ型を再利用できます。データ型の作成時に、既存のデータ型を他のプレースホルダ・データ・コントロールからロードするオプションを選択できます。「インポート元: 既存のデータ型」オプションを選択すると、インポートするデータ型の属性が既存の属性のリストに追加されます。

属性の追加時には、インポートするデータ型に関連付けられているサンプル・データをインポートするオプションも選択できます。

注意:

アプリケーションを実行するまでサンプル・データは必要ありませんが、設計時に一貫性を持ってコンポーネントをレンダリングするには、サンプル・データを追加する必要があります。

20.3.1 プレースホルダ・データ型の作成方法

プレースホルダ・データ・コントロールの作成後は、データ型の作成に進むことができます。データ型の名前を定義し、その各属性を定義します。属性ごとに、タイプ、フォーマット、デフォルトのUIコンポーネントおよびLOVにするかどうかを定義します。

プレースホルダ・データ型の作成プロセスを簡略化するため、String、Boolean、DateおよびNumberの4つの最も一般的なタイプのリストから選択できます。プレースホルダの属性にはタイプが指定されているため、列ラベルを作成でき、UIのコントロールのヒントを設計に含めることができます。

カンマ区切り値(CSV)形式のサンプル・データ・ファイルがある場合は、サンプル・データ・ファイルのインポート機能を使用して、すべての属性の作成とサンプル・データのロードを実行できます。属性を作成する必要はありません。JDeveloperはそれらの属性をCSVファイルの形式から作成します。ファイルにはオプションで最初の行として列見出しのリストを含めることができます。属性のタイプはStringにデフォルトで設定されます。必要に応じて、各属性を別のタイプに手動でリセットできます。サンプル・データのインポート手順は、「属性とサンプル・データをプレースホルダ・データ型にインポートする方法」を参照してください。

始める前に:

プレースホルダ・データ型を作成する場合のオプションに関する知識があると役立つ場合があります。詳細は、「プレースホルダ・データ型の作成」を参照してください。

また、プレースホルダ・データ・コントロールの使用後に追加できる機能についても理解しておくと役立ちます。詳細は、「プレースホルダ・データ・コントロールの追加機能」を参照してください。

また、「プレースホルダ・データ・コントロールの作成方法」の説明に従って、まずプレースホルダ・データ・コントロールを作成する必要があります。

プレースホルダ・データ型を作成するには:

1. 「アプリケーション」ウィンドウで、プレースホルダ・データ型を追加するプレースホルダ・データ・コントロールをダブルクリックします。

2. 概要エディタの「データ型」セクションで、プレースホルダ・データ・コントロールを選択し、「新規プレースホルダ・データ型」アイコンをクリックします。

注意:

または、「データ・コントロール」パネルのプレースホルダ・データ・コントロールを右クリックして「新規プレースホルダ・データ型」を選択しても、「プレースホルダ・データ型の作成」ダイアログを開くことができます。

図20-3に、「プレースホルダ・データ型の作成」ダイアログを示します。

図20-3 「プレースホルダ・データ型の作成」ダイアログ

3. 「プレースホルダ・データ型の作成」ダイアログで、プレースホルダ・データ型のファイル名とパッケージを入力します。

4. 属性およびデータをインポートする既存のプレースホルダ・データ型または.csvファイルがある場合、「インポート元」を選択し、「.CSVファイル」または「既存のデータ型」を選択して、インポートのオプションを指定します。
.csvファイルからインポートするには:

a. 「ファイル名」フィールドで、インポート元にするファイルを指定し、「参照」アイコンをクリックしてファイルに移動して選択します。

b. 「キャラクタ・セット」ドロップダウン・リストから、ファイルで使用するキャラクタ・セットを選択します。

c. ファイルに列名を含むヘッダー行がある場合、「インポートするファイルの1行目に属性名を含めます。」を選択します。

既存のプレースホルダ・データ型からインポートするには:

a. ツリーを開き、既存のプレースホルダ・データ型を見つけて選択します。

b. 既存のデータ型にインポートするデータが含まれる場合、「サンプル・データもインポートします。」を選択します。

5. 「OK」をクリックします。
プレースホルダ・データ型が作成され、概要エディタで開きます。

6. 概要エディタで、「属性」ナビゲーション・タブをクリックし、プレースホルダ・データ型の属性を表示、追加および編集します。

7. 「データ」ナビゲーション・タブをクリックして、プレースホルダ・データ型のサンプル・データを表示、追加および編集します。
実行時用、および一貫性設計時用のサンプル・データが必要です。

20.3.2 属性とサンプル・データをプレースホルダ・データ型に追加する方法

プレースホルダ・データ・コントロールを使用するアプリケーションを実行する場合は、実行時に表示されるサンプル・データを追加する必要があります。サンプル・データは、手動で、またはデータを別のプレースホルダ・データ型あるいはCSVファイルからインポートすることで、プレースホルダ・データ型の属性に追加できます。サンプル・データは実行時にのみ必須ですが、設計時に一貫性を持ってコンポーネントをレンダリングするためには、サンプル・データを追加する必要があります。

プレースホルダ・データ型の作成時に属性をインポートしなかった場合、概要エディタの「属性」ページを使用して属性を追加できます。また、概要エディタの「データ」ページを使用して、実行時に表示されるサンプル・データを追加できます。「属性」ページと「データ」ページの両方に「インポート」ボタンがあり、これをクリックすると「プレースホルダ・データ型のインポート」ダイアログが開き、このダイアログから属性とサンプル・データをインポートできます。

サンプル・データをプレースホルダ・データ型を追加する前に、プレースホルダ・データ・コントロールおよびプレースホルダ・データ型を作成しておく必要があります。データを手動で入力する場合は、そのデータを用意しておく必要があります。データをCSVファイルからロードする場合は、ファイルの場所を把握しておく必要があります。別のプレースホルダ・データ型をインポートする場合は、もう一方のデータ型も作成している必要があります。

20.3.2.1 プレースホルダ・データ型への属性の手動による追加

概要エディタの「属性」ページを使用すると、プレースホルダ・データ型に属性を追加して構成できます。

始める前に:

プレースホルダ・データ型を作成する場合のオプションに関する知識があると役立つ場合があります。詳細は、「プレースホルダ・データ型の作成」を参照してください。

また、プレースホルダ・データ・コントロールの使用後に追加できる機能についても理解しておくと役立ちます。詳細は、「プレースホルダ・データ・コントロールの追加機能」を参照してください。

また、「プレースホルダ・データ・コントロールの作成方法」の説明に従って、まずプレースホルダ・データ・コントロールを作成し、「プレースホルダ・データ型の作成方法」に従って、プレースホルダ・データ型を作成する必要があります。

プレースホルダ・データ型を手動で追加するには:

1. 「アプリケーション」ウィンドウで、属性を追加するプレースホルダ・データ型をダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、「追加」アイコンをクリックします。

4. 「ビュー属性の追加」ダイアログで、属性の名前を入力し、「OK」をクリックします。

5. 属性を追加したら、属性を選択し、属性リストの横のフィールドを使用して選択した属性を構成します。

- 名前: 属性の名前を入力します。

- データ型: 属性の型をドロップダウン・リストから選択します。サポートされるタイプは、String、Boolean、Date、およびNumberです。

- デフォルト・コンポーネント: 属性のデフォルトのコンポーネントをドロップダウン・リストから選択します。LOVの場合は、「値リストを使用したコンボ・ボックス」を選択します。次に、「編集」アイコンをクリックして、LOVを構成します。詳細は、「プレースホルダ・データ型の属性を値リストに構成する方法」を参照してください。

- デフォルト値: 属性の初期値を入力します。

- ラベル: 属性のラベルを入力します。このラベルは、コンポーネントが表示されるときに使用されます。

- ツールチップ: 属性のツールチップとして表示されるテキストを入力します。

- フォーマットの種類: このフィールドは、タイプがDateまたはNumberの場合にのみ使用できます。フォーマットの種類をドロップダウン・リストから選択します。

- フォーマット: このフィールドは、このフォーマットの種類に対してフォーマット・マスクが定義されている場合のみ有効になります。

- 表示幅: この属性を表示するコントロールで使用する文字幅を入力します。

- 検索可能: 属性を検索可能にする場合にこのチェック・ボックスを選択します。

別の属性を追加するには、「追加」アイコンをクリックします。

20.3.2.2 サンプルデータを手動で追加

「プレースホルダ・データ型の編集」ダイアログの「サンプル・データ」ページを使用すると、プレースホルダ・データ・コントロールのサンプル・データを手動で入力できます。

始める前に:

プレースホルダ・データ型を作成する場合のオプションに関する知識があると役立つ場合があります。詳細は、「プレースホルダ・データ型の作成」を参照してください。

また、プレースホルダ・データ・コントロールの使用後に追加できる機能についても理解しておくと役立ちます。詳細は、「プレースホルダ・データ・コントロールの追加機能」を参照してください。

プレースホルダ・データ型にサンプル・データを追加する前に、次のタスクを実行する必要があります。

- 「プレースホルダ・データ型の作成方法」の説明に従って、プレースホルダ・データ型を作成します。

- サンプル・データを準備しておきます。

サンプル・データをプレースホルダ・データ型に手動で追加するには:

1. 「データ・コントロール」パネルで、サンプル・データを追加するプレースホルダ・データ型を右クリックし、「開く」を選択します。

2. 概要エディタで、「データ」ナビゲーション・タブをクリックします。

3. 「データ」ページで、「追加」アイコンをクリックして、データ表に行を追加し、各属性の値を入力します。十分なサンプル・データを入力するまで、必要に応じて繰り返します。

20.3.2.3 属性とサンプル・データをプレースホルダ・データ型にインポートする方法

属性とサンプル・データをプレースホルダ・データ型に手動で入力するかわりに、それらを1回の操作でインポートできます。概要エディタの「属性」ページを使用すると、既存のプレースホルダ・データ型または.csvファイルから属性をインポートできます。

.csv (カンマ区切りの値)ファイルは、カンマで区切られた、属性値の行を含むプレーン・テキスト・ファイルです。.csvファイルには、オプションで各属性の名前を定義するヘッダー行を含めることができます。

プレースホルダ・データ型の概要エディタで、「属性」ページと「データ」ページの両方に「インポート」ボタンがあり、これをクリックすると「プレースホルダ・データ型のインポート」ダイアログが開き、このダイアログから属性とサンプル・データをインポートできます。

始める前に:

プレースホルダ・データ型を作成する場合のオプションに関する知識があると役立つ場合があります。詳細は、「プレースホルダ・データ型の作成」を参照してください。

また、プレースホルダ・データ・コントロールの使用後に追加できる機能についても理解しておくと役立ちます。詳細は、「プレースホルダ・データ・コントロールの追加機能」を参照してください。

また、「プレースホルダ・データ・コントロールの作成方法」の説明に従って、まずプレースホルダ・データ・コントロールを作成し、「プレースホルダ・データ型の作成方法」に従って、プレースホルダ・データ型を作成する必要があります。

プレースホルダ・データ型に属性をインポートするには:

1. 「アプリケーション」ウィンドウで、属性を追加するプレースホルダ・データ型をダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 属性とともにサンプル・データをインポートする場合は、プレースホルダ・データ型の既存の属性を削除する必要があります。
既存の属性を削除しないと、JDeveloperでは最初から定義された属性の数のデータ列のみがインポートされます。たとえば、CSVファイルで、データ型に2つの属性が定義されており、サンプル・データに4つの列が存在する場合、JDeveloperはデータの最初の2つの列のみをインポートします。

4. 「属性」ページで、「インポート」をクリックします。

5. 「プレースホルダ・データ型のインポート」ダイアログで、属性のインポート元を指定します。
.csvファイルを使用するには:

a. 「.CSVファイルからインポート」を選択します。

b. 「ファイル名」フィールドで、ファイルのフルパスと名前を指定し、「参照」アイコンをクリックしてファイルに移動して選択します。

c. 「キャラクタ・セット」ドロップダウン・リストから、指定された.csvファイルで示されるキャラクタ・セットを選択します。

d. .csvファイルに属性名を含むヘッダー行がある場合、「インポートするファイルの1行目に属性名を含めます。」を選択します。

既存のプレースホルダ・データ型を使用するには:

a. 「既存のプレースホルダ・データ型からインポート」を選択します。

b. 表示される利用できるプレースホルダ・データ・コントロールを開いて、それらに含まれるプレースホルダ・データ型を表示し、コピーするデータ型を選択します。

図20-4 「プレースホルダ・データ型のインポート」ダイアログ

6. 「サンプル・データもインポートします。」チェック・ボックスを選択して、ファイルまたは既存のプレースホルダ・データ型からサンプル・データをロードします。

7. プレースホルダ・データ型にすでに定義されている属性に対して、追加するか上書きするかを指定します。

- 「追加」を選択すると、プレースホルダ・データ型の現在の属性リストにインポートした属性が追加されます。

- 「上書き」を選択すると、現在の属性がインポートした属性で置き換えられます。

8. 「OK」をクリックします。

9. 属性をインポートしたら、オプションで「属性」ページに移動して属性を再構成できます。

20.3.2.4 サンプル・データの追加時の処理

プレースホルダ・サンプル・データは、手動で追加またはインポートされたかにかかわらず、メッセージ・バンドル・ファイルに格納されています。次の例は、5つの属性の2つの行を持つメッセージ・バンドルのサンプルを示しています。

model.prototype.SupplierLocationsDataType.SL_0_0=101
model.prototype.SupplierLocationsDataType.SL_0_1=so
model.prototype.SupplierLocationsDataType.SL_0_2=Houston
model.prototype.SupplierLocationsDataType.SL_0_3=TX
model.prototype.SupplierLocationsDataType.SL_0_4=USA
model.prototype.SupplierLocationsDataType.SL_1_0=101
model.prototype.SupplierLocationsDataType.SL_1_1=dw
model.prototype.SupplierLocationsDataType.SL_1_2=Atlanta
model.prototype.SupplierLocationsDataType.SL_1_3=GA
model.prototype.SupplierLocationsDataType.SL_1_4=USA

20.3.3 プレースホルダ・データ型の作成時の処理

プレースホルダ・データ型を作成すると、JDeveloperによってPlaceholderDataType.xmlファイルが作成されます(PlaceholderDataTypeは、指定したプレースホルダ・データ型の名前です)。

PlaceholderDataType.xmlファイルは、ビュー・オブジェクトのXMLファイルと同じ形式になります。これには、ビュー・オブジェクトの名前と、プレースホルダに定義した各属性の名前と値が含まれます。

次の例は、Supplierデータ型のPlaceholderDataType.xmlを示しています。Supplier_IdとSupplier_Nameの2つの属性が宣言的に定義されています。

<?xml version='1.0' encoding='windows-1252' ?>
<ViewObject
xmlns="http://xmlns.oracle.com/placeholder"
Name="SuppliersDataType"
InheritPersonalization="merge"
BindingStyle="OracleName"
CustomQuery="true">
<ViewAttribute
Name="Supplier_Id"
Type="oracle.jbo.domain.Number"/>
<ViewAttribute
Name="Supplier_Name"
Type="java.lang.String"/>
</ViewObject>

データ型は、データ・コレクションと類似しており、ビュー・オブジェクトに基づいているため、各データ型には対応するPlaceholderDataType.xmlファイルがあります。

また、JDeveloperによって各プレースホルダ・データ型のエントリがPlaceholderDataControl.xmlファイルに追加されます。たとえば、Suppliersデータ型が作成されると、次の例に示すように、データ・コントロールXMLファイルにSuppliersデータ型の新しいViewUsageエントリが含まれます。

<?xml version="1.0" encoding="windows-1252" ?>
<AppModule
xmlns="http://xmlns.oracle.com/placeholder"
Name="Placeholder01"
InheritPersonalization="merge">
<ViewUsage
Name="SuppliersDataType"
ViewObjectName="model.prototype.SuppliersDataType"/>
</AppModule>

「データ・コントロール」パネルで、プレースホルダ・データ・コントロールの下にプレースホルダ・データ型のノードが表示されます。このノードを展開すると、各属性、「ビルトイン操作」ノードおよび「名前付き基準」ノードが存在することがわかります。

図20-5に、「データ・コントロール」パネルに表示されるプレースホルダ・データ・コントロールを示します。

図20-5 「データ・コントロール」パネルに表示されるプレースホルダ・データ・コントロール

20.3.4 プレースホルダ・データ型の属性を値リストに構成する方法

プレースホルダ・データ型の属性は、値リスト(LOV)に構成できます。LOV形式の属性は、ドロップダウン・リストまたはリスト選択ダイアログを表示するUIコンポーネントにバインドされます。LOVの詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

プレースホルダ・データ型の属性の構成時に、その属性をLOVに構成するダイアログを表示するオプションを選択できます。

データソースが1つしかない場合、作成できるのは固定LOVのみです。動的LOVを作成するには、ソースで複数のプレースホルダ・データ型を使用できる必要があります。

20.3.4.1 固定LOVにする属性の構成

作業を始める前に、固定LOVにする属性、および固定リストに入れる値を決定する必要があります。

始める前に:

プレースホルダ・データ型を作成する場合のオプションに関する知識があると役立つ場合があります。詳細は、「プレースホルダ・データ型の作成」を参照してください。

また、プレースホルダ・データ・コントロールの使用後に追加できる機能についても理解しておくと役立ちます。詳細は、「プレースホルダ・データ・コントロールの追加機能」を参照してください。

また、プレースホルダ・データ・コントロールに対してすでにプレースホルダ・データ型を作成している必要があります。

属性を固定LOVに構成するには:

1. 「データ・コントロール」パネルで、プレースホルダ・データ型を右クリックし、「開く」を選択します。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、LOVとして構成する属性を選択します。

4. 「デフォルト・コンポーネント」プルダウン・リストの横にある「LOVバインディングの編集」アイコンをクリックします。

「値リストの設定」ダイアログ(図20-6を参照)が表示されます。

図20-6 固定LOVの「値リストの設定」ダイアログ

5. ダイアログで、「固定リスト」を選択します。

6. 「追加」アイコンをクリックして、値リストにエントリを追加します。

7. 各エントリに対し、ラベルおよび値を入力します。

ユーザーがアイテムを値リストから選択すると、対応する値エントリが入力フィールドに入力されます。

8. ドロップダウン・リストに表示する最近使用したアイテムの最大数を選択します。

9. 「"選択なし"アイテム」ドロップダウン・リストから、「選択なし」アイテムの表示方法のオプションを選択します。

たとえば、「空のアイテム(リストの最初)」を選択すると、「選択なし」アイテムはリストの最初に空白として表示されます。

10. 「OK」をクリックします。

20.3.4.2 動的LOVにする属性の構成

プレースホルダ・データ型をソースとして使用すると、属性を動的なLOVとして構成できます。

始める前に:

プレースホルダ・データ型を作成する場合のオプションに関する知識があると役立つ場合があります。詳細は、「プレースホルダ・データ型の作成」を参照してください。

また、プレースホルダ・データ・コントロールの使用後に追加できる機能についても理解しておくと役立ちます。詳細は、「プレースホルダ・データ・コントロールの追加機能」を参照してください。

また、動的LOVのソースの役割を果たすプレースホルダ・データ型をもう1つ作成しておく必要があります。

属性を動的LOVに構成するには:

1. 「データ・コントロール」パネルで、プレースホルダ・データ型を右クリックし、「開く」を選択します。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、LOVとして構成する属性を選択します。

4. 「デフォルト・コンポーネント」プルダウン・リストの横にある「LOVバインディングの編集」アイコンをクリックします。

「値リストの設定」ダイアログ(図20-7を参照)が表示されます。

図20-7 動的LOVの「値リストの設定」ダイアログ

5. 「値リストの構成」ダイアログで、「動的リスト」を選択します。

6. リスト・データ型およびそのソース属性を選択します。これを選択可能にするには、ソースにプレースホルダ・データ型が必要です。

7. リストの属性を選択します。

8. 目的の表示属性を「使用可能」リストから「選択済」リストに移動します。

9. ドロップダウン・リストに表示する最近使用したアイテムの最大数を選択します。

10. 「"選択なし"アイテム」ドロップダウン・リストから、「選択なし」アイテムの表示方法のオプションを選択します。たとえば、「空のアイテム(リストの最初)」を選択すると、「選択なし」アイテムはリストの最初に空白として表示されます。

11. 「OK」をクリックします。

20.3.5 マスター/ディテール・データ型の作成方法

表の間にマスター/ディテール階層を作成するのと同様に、データ型の間にマスター/ディテール関係を作成します。標準データ・コントロールでは、ビュー・リンクを使用して、マスター・オブジェクトおよびディテール・オブジェクトになるソース・ビュー・オブジェクトおよびターゲット・ビュー・オブジェクトを定義できます。マスター/ディテール関係の詳細は、「マスター/ディテール・データの表示」を参照してください。

まず、マスター・データ型とその属性を作成します。次に、ディテール・データ型をマスター・データ型の子として作成します。ディテール・データ型への関係を定義するソース属性をマスター・データ型に定義します。

始める前に:

プレースホルダ・データ型を作成する場合のオプションに関する知識があると役立つ場合があります。詳細は、「プレースホルダ・データ型の作成」を参照してください。

また、プレースホルダ・データ・コントロールの使用後に追加できる機能についても理解しておくと役立ちます。詳細は、「プレースホルダ・データ・コントロールの追加機能」を参照してください。

プレースホルダ・マスター/ディテール階層を作成する前に、次のタスクを実行する必要があります。

- マスター・データ型のデータ構造とディテール・データ型のデータ構造を決定します。

- ディテール・データ型のソースとなるマスターの属性を決定します。

- 「プレースホルダ・データ型の作成方法」の説明に従って、マスターとするプレースホルダ・データ型を作成します。

マスター/ディテール階層データ型を作成するには:

1. 「データ・コントロール」パネルで、マスター・プレースホルダ・データ型を右クリックし、「新規子プレースホルダ・データ型」を選択します。
図20-8に、ディテール・データ型の属性を入力する「プレースホルダ・データ型の作成」ダイアログを示します。

図20-8 「子プレースホルダ・データ型の作成」ダイアログ

2. 「プレースホルダ・データ型の作成」ダイアログで、ディテール・データ型の名前とパッケージを入力します。

3. 「親に対する結合属性」ドロップダウン・リストで、新しいディテール・データ型に結合するために使用する属性をマスター・データ型から選択します。

4. 属性およびデータをインポートする既存のプレースホルダ・データ型または.csvファイルがある場合、「インポート元」を選択し、「.CSVファイル」または「既存のデータ型」を選択して、インポートのオプションを指定します。
.csvファイルからインポートするには:

a. 「ファイル名」フィールドで、インポート元にするファイルを指定し、「参照」アイコンをクリックしてファイルに移動して選択します。

b. 「キャラクタ・セット」ドロップダウン・リストから、ファイルで使用するキャラクタ・セットを選択します。

c. ファイルに列名を含むヘッダー行がある場合、「インポートするファイルの1行目に属性名を含めます。」を選択します。

既存のプレースホルダ・データ型からインポートするには:

a. ツリーを開き、既存のプレースホルダ・データ型を見つけて選択します。

b. 既存のデータ型にインポートするデータが含まれる場合、「サンプル・データもインポートします。」を選択します。

5. 「OK」をクリックします。

図20-9に示すように、「データ・コントロール」パネルにディテール・データ型がマスター・データ型の子として表示されます。属性をインポートしていない場合は、「属性とサンプル・データをプレースホルダ・データ型に追加する方法」の説明に従って、ここで属性を追加できます。

図20-9 プレースホルダ・データ・コントロールのマスター/ディテール階層

20.3.6 マスター/ディテール・データ型の作成時の処理

マスター/ディテール関係は、ビュー・オブジェクトおよびビュー・リンクを使用して、標準のマスター/ディテール関係と同様に実装されます。プレースホルダ・データ型をマスター/ディテール階層に定義すると、その関係を定義するビュー・リンクのメタデータ・エントリを含むDTLink.xmlファイルがJDeveloperによって作成されます。ビュー・リンクの詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。たとえば、キーSupplier_Idに関連付けられているマスター・データ型SuppliersDataTypeとディテール・データ型SupplierLocationsDataType間の関係では、次の例に示すように、JDeveloperによって、その関係を定義するDTLink.xmlファイルがビュー・リンク・ファイルの形式で作成されます。

<?xml version="1.0" encoding="windows-1252" ?>
<ViewLink
xmlns="http://xmlns.oracle.com/placeholder"
Name="DTLink"
InheritPersonalization="merge">
<ViewLinkDefEnd
Name="SuppliersDataType"
Cardinality="1"
Source="true"
Owner="model.prototype.SuppliersDataType">
<AttrArray Name="Attributes">
<Item Value="model.prototype.SuppliersDataType.Supplier_Id"/>
</AttrArray>
</ViewLinkDefEnd>
<ViewLinkDefEnd
Name="SupplierLocationsDataType"
Cardinality="-1"
Owner="model.prototype.SupplierLocationsDataType">
<AttrArray Name="Attributes">
<Item Value="model.prototype.SupplierLocationsDataType.Supplier_Id"/>
</AttrArray>
</ViewLinkDefEnd>
</ViewLink>

20.4 プレースホルダ・データ・コントロールの使用

プレースホルダ・データ・コントロールは、標準データ・コントロールと同様に使用します。データ型をページにドラッグし、ポップアップ・メニューを使用してデータ型をフォーム、表、ツリー、グラフなどのコンポーネントとしてドロップできます。個々の属性は、テキスト、値リスト、単一選択などのコンポーネントとしてページにドロップできます。「Create」「Execute」、および「Next」などのすべての組込み操作は、ボタン、コマンド・リンクおよびメニュー・アイテムとしてドロップすることで、使用可能になります。

プレースホルダ・データ・コントロールは、次に示すように、いくつかの方法で利用できます。

- プレースホルダ・データ・コントロールを使用してページを作成し、実際のデータ・コントロールに後でリバインドできます。

- コンポーネントを使用してページを作成し、プレースホルダ・データ・コントロールにバインドし、実際のデータ・コントロールに後でリバインドできます。

- 「コンポーネント」パレットやプレースホルダ・データ・コントロールのいくつかのコンポーネントを組み合せて使用してページを作成し、実際のデータ・コントロールに後でバインドまたはリバインドできます。

20.4.1 プレースホルダ・データ・コントロールの制限

プレースホルダ・データ・コントロールは、アプリケーション開発における様々な状況で使用できます。ほとんどのUI設計評価では、プレースホルダ・データ・コントロールは実際のデータ・コントロールの完全な代替となる必要があります。

次の制限に注意してください。

- データ型は基礎となるデータソースに関連付けられていないため、コミット操作およびロールバック操作では実際のトランザクションの実行やキャッシュの更新は行われません。

- プレースホルダ・データ・コントロールは、宣言的にのみ作成できます。実際のアプリケーション・モジュールやデータ・コントロールの場合とは異なり、カスタム・メソッドを作成できません。

- プレースホルダ・データ・コントロールは、カスタム・データ、データをフェッチするためのフィルタリングまたはカスタム・コードが必要な場合は使用できません。プレースホルダ・データ・コントロールでは、これらの操作が無効化されます。

20.4.2 レイアウトの作成

プレースホルダ・データ・コントロール、使用できる実際のデータ・コントロールおよび「コンポーネント」ウィンドウのコンポーネントを使用して、ドラッグ・アンド・ドロップ機能によってページを作成します。実際のデータを必要とするページまたはアプリケーションを実行する場合は、プレースホルダ・データ型のサンプル・データを入力します。サンプル・データの量が多い場合は、データ・ソースからCSVファイルを作成してデータ型にロードできます。また、CSVサンプル・データ・ファイルの作成には、スプレッドシートまたは他のツールを使用できる場合もあります。

20.4.3 検索フォームの作成

標準データ・コントロールでは、ビュー・オブジェクトにビュー基準を作成して問合せを変更できます。これらのビュー基準は、問合せおよびクイック問合せ検索フォームのドラッグ・アンド・ドロップによる作成にも使用されます。名前付きビュー基準アイテムは、データ・コレクションの「名前付き基準」ノードの下に表示されます。問合せ検索フォームおよびクイック問合せ検索フォームの詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

プレースホルダ・データ・コントロールにも、各データ型のノードの下に「名前付き基準」ノードがあります。自動的に作成されたAll Queriable Attributesアイテムはこのノードの下に表示され、このアイテムを使用してページにドラッグ・アンド・ドロップすると問合せ検索フォームまたはクイック問合せ検索フォームを作成できます。

20.4.4 コンポーネントのバインド

データ・コントロールを使用してページを作成するかわりに、たとえば、データの形態が不明な場合は、まず「コンポーネント」ウィンドウを使用してページをレイアウトし、後でプレースホルダ・データ・コントロールのデータ型、属性または操作にバインドできます。

20.4.5 コンポーネントのリバインド

最終的なデータ・コントロールが用意できた後は、単にコンポーネントをリバインドできます。「構造」ウィンドウでコンポーネントを選択し、ポップアップ・メニューを使用して関連するリバインド・ダイアログを開くことができます。また、データ・コントロール・アイテムをUIコンポーネントにドラッグ・アンド・ドロップしてリバインド・エディタを開始することも可能です。コンポーネントの元のバインド先がプレースホルダ・データ・コントロールか標準データ・コントロールかに関係なく、リバインド手順は同じです。

コンポーネントのリバインドの詳細は、「データバインドされた基本的なページの作成」および「ADFによるデータバインドされた表の作成」を参照してください。

20.4.6 ADFライブラリJARへのプレースホルダ・データ・コントロールのパッケージ化

プレースホルダ・データ・コントロールの便利な機能として、開発者と設計者の間での並行開発および作業分割を可能にする機能があります。プレースホルダ・データ・コントロールをADFライブラリJARとして再利用可能なコンポーネントにパッケージ化すると、この機能をさらに有効利用できます。ADFライブラリは、ADFコンポーネントのすべての必要なアーティファクトがパッケージ化されたJARです。再利用可能なコンポーネントおよびADFライブラリの詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。プレースホルダ・データ・コントロールのライブラリを作成し、同じUIプロジェクトで作業している複数の設計者に配布できます。また、軽量であるため、UI設計の初期段階では、使用可能な実際のデータ・コントロールのかわりに使用することもできます。

21 ADF RESTデータ・コントロールを使用したRESTful Webサービスの使用方法

この章では、ADFビジネス・コンポーネント・アプリケーション・モジュールに基づくRESTful Webサービスのデータ・コントロールを作成する方法について説明します。

この章の内容は次のとおりです。

- アプリケーション・モジュールに基づくRESTful Webサービスのデータ・コントロールについて

- RESTデータ・コントロールを使用した、ビジネス・コンポーネントのRESTリソースとしての使用

- RESTデータ・コントロールの使用方法

- アプリケーション・モジュールによって公開されたRESTデータ・コントロールの構成

21.1 アプリケーション・モジュールに基づくRESTful Webサービスのデータ・コントロールについて

ADFビジネス・コンポーネントは、RESTful Webサービスを公開するように構成できます。これにより、アプリケーション内の他の部分や、完全に異なるアプリケーションによって公開されるサービスを使用するアプリケーションを開発できます。このため、このサービスを使用する場合は、基礎となるビジネス・コンポーネントをアプリケーションとともにパッケージ化する必要はありません。

ADFビジネス・コンポーネントに基づくRESTful Webサービスの使用を簡略化するために、JDeveloperを使用して、これらのサービスへの接続を作成した後、それらの接続によって含められたリソースに基づいてデータ・コントロールを生成できます。その後、「データ・コントロール」パネルを使用して、RESTリソースやメソッドを表すUIコンポーネントを作成することによって、RESTful Webサービスに対するクライアントを構築できます。Webサービスを解析するためのコードを記述したり、サービスを実装するクライアントWebアプリケーションを作成したりする必要はありません。

アプリケーション・モジュールによって公開されるWebサービスはRESTの原則に基づくものの、データ・コントロールを使用してサービスを使用するとき、サービスと対話する方法は、アプリケーション・モジュールと直接対話する場合と非常に似ています。ページのデータ操作の基礎となる実装はRESTメソッドに基づきますが、アプリケーション・モジュール・データ・コントロールに基づいてデータバインドUIコンポーネントを作成するときと同じタイプのデータ・コントロール・オブジェクトやビルトイン操作を使用して、ページを構築できます。

RESTful Webサービスはリクエスト間でステートレスであるものの、アプリケーション・モジュールによって公開されたRESTful Webサービスに基づくデータ・コントロールを使用して作成されたアプリケーションの動作は、ステートフルになります。ただし、アプリケーションの状態に関する情報は、サーバー上ではなく、交換されるメッセージ内に含まれるため、アプリケーションはステートレスになります。HTTPメソッドに関連するユーザーのCRUDアクション(GET、PATCH、PUT、POSTおよびDELETE)は、ユーザーがCommitまたはRollback操作を起動するまでキャッシュされ、その起動の時点でキャッシュがクリアされ(て、データがデータソースにコミットされるか、または変更が破棄され)ます。

注意:

この章は、ADFビジネス・コンポーネントを使用して開発された機能を公開するRESTful Webサービスに基づくデータ・コントロールに関連します。また、ADFビジネス・コンポーネントに基づかない、SOAPベースのWebサービスや、RESTful Webサービスに基づくデータ・コントロールを作成することもできます。詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のADFモデル・レイヤーを使用したWebサービスの公開に関する項を参照してください。

21.1.1 REST Webサービス・データ・コントロールのユースケースと例

ADFビジネス・コンポーネントによって公開されたRESTful Webサービスを使用するデータ・コントロールを作成できます。その後、そのデータ・コントロールを使用して、Webページ上に、サービスの機能にアクセスするためのデータバインドUIコンポーネントを作成します。

通常、そのようなWebサービスは、機能を自分で開発する必要なく、アプリケーションで機能を実現するための方法として使用します。また、アプリケーション内に直接、基本アプリケーション・モジュールをパッケージ化する必要はありません。使用するこれらのRESTful Webサービスは、パートナ、サービス・プロバイダまたは別の開発チームが公開する場合や、クラウドベースのサービスの一部になっている場合があります。

21.1.2 REST Webサービス・データ・コントロールの追加機能

ADFビジネス・コンポーネントに基づくRESTful Webサービスを使用する前に、他のデータ・アクセス機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- ADFデータ・コントロールやデータ・バインディングの動作方法の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

- 「データ・コントロール」パネルからアイテムをドラッグして、ページ上にUIコンポーネントとしてドロップすることによってデータバインドされたユーザー・インタフェースを設計する方法の詳細は、「データバインドされた基本的なページの作成」を参照してください。

- ADFビジネス・コンポーネントに基づくRESTful Webサービスの公開の詳細は、「アプリケーション・モジュールによるRESTful Webサービスの作成」を参照してください。

21.2 RESTデータ・コントロールを使用した、ビジネス・コンポーネントのRESTリソースとしての使用

RESTデータ・コントロールを使用すると、指定されたURI (ADFビジネス・コンポーネントによって公開されたRESTful Webサービスを実行することによって定義)からのデータ・ストリームにアクセスして使用できます。ADFビジネス・コンポーネントに基づくRESTful Webサービスを使用する接続は2通りの方法で作成できます。

1. アプリケーション・モジュールによって公開されたRESTful WebサービスのdescribeリソースへのIDE接続を作成し、この接続に基づくデータ・コントロールを作成します。

2. Webサービス・データ・コントロール・ウィザードを使用して、REST接続とデータ・コントロールを一緒に作成します。

21.2.1 REST接続の作成方法

ADFビジネス・コンポーネント・アプリケーション・モジュールに基づくRESTful WebサービスのdescribeリソースへのIDE接続を作成するために、「REST接続の作成」ダイアログを使用します。このウィザードには、「新規ギャラリ」または「リソース」ウィンドウを経由してアクセスできます。このウィザードを使用して作成するすべての接続は、「リソース」ウィンドウに追加され、すべてのアプリケーション・ワークスペースで、データ・コントロールを作成するために使用できます。

始める前に:

RESTデータ・コントロールの一般的な知識があると役立ちます。詳細は、「RESTデータ・コントロールを使用した、ビジネス・コンポーネントのRESTリソースとしての使用」を参照してください。

また、他のRESTful Webサービス機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「REST Webサービス・データ・コントロールの追加機能」を参照してください。

- データ・コントロールからアクセスするRESTful Webサービスへのアクセス権が必要です。REST接続を作成するためにdescribe機能を使用するには、RESTful WebサービスがADFビジネス・コンポーネント・アプリケーション・モジュールに基づいている必要があります。

REST接続を作成する手順は次のとおりです。

1. メイン・メニューから「ファイル」→「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で「一般」を開き、「REST接続」、「URL接続」の順に選択して、「OK」をクリックします。

3. 「REST接続の作成」ダイアログで、接続の名前を入力します。

4. 「IDE接続」ラジオ・ボタンを選択します。

5. 「URLエンドポイント」フィールドで、RESTリソースのdescribeオブジェクトのURIを入力します。

注意:

このURIは、ホスト、ポート、リソース・パスおよびdescribeリソースで構成されます。通常、リソース・パスは、Webサービス・プロジェクトのコンテキスト・ルートと、RESTプロジェクトのweb.xmlファイルのサーブレット・マッピングで指定されたURLパターンで構成されます。バージョン名とリソース名は含めますが、URLパラメータは含めません。

たとえば、次のような内容を入力できます。

http://service.example.com:7101/WebServiceProjectContextRoot/rest/VersionName/ResourceName/describe

6. 「認証タイプ」ドロップダウン・リストから認証レベルを選択します。

デフォルトの認証タイプは「なし」で、認証は無効になります。セキュリティが必要な場合は、「ダイジェスト」を使用します。この方法では、パスワードはユーザー・パスワードのMD5ダイジェストとしてネットワーク上を送信され、ネットワーク・トラフィックを傍受しても判別できません。「基本」認証は、主にネットワーク上でのサービス・アクセスに高度なセキュリティを必要としない場合にのみ役立ちます。

7. ダイジェスト認証または基本認証を選択した場合は、Webサイトへのアクセスに必要なユーザー名とパスワードを指定します。

8. 名前とエンドポイントを入力したら、「接続のテスト」をクリックして、REST接続が有効であることを検証します。

9. 「OK」をクリックします。

21.2.1.1 REST接続の作成時の処理

REST接続はJDeveloperでIDE接続として作成し、IDEで作成する任意のアプリケーションで使用できます。図21-1に示すように、「リソース」ウィンドウの「IDE接続」パネルで、IDE接続を表示できます。

図21-1 「リソース」ウィンドウに示されたREST接続

21.2.1.2 ADF RESTリソースからデータ・コントロールを作成する方法

「リソース」ウィンドウから、REST接続の下にリストされているリソースを「データ・コントロール」パネルにドラッグすることによって、RESTデータ・コントロールを作成できます。他のタイプのRESTful Webサービスに基づいてRESTデータ・コントロールを作成する場合と異なり、データ・コントロールが個別のリソースをどのように公開するかを複雑なウィザードで構成する必要はありません。

始める前に:

RESTデータ・コントロールの一般的な知識があると役立ちます。詳細は、「RESTデータ・コントロールを使用した、ビジネス・コンポーネントのRESTリソースとしての使用」を参照してください。

また、他のRESTful Webサービス機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「REST Webサービス・データ・コントロールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- アプリケーション・ワークスペースを作成し、プロジェクトをそのワークスペース内で作成します。プロジェクトの編成方法に応じて、既存のアプリケーション・ワークスペースとプロジェクトを使用することも、新規に作成することもできます。アプリケーション・ワークスペースの追加の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のアプリケーションとプロジェクトの作成に関する項を参照してください。

- 「REST接続の作成方法」の説明に従い、Create a REST接続を作成します。

RESTデータ・コントロールを作成する手順は次のとおりです。

1. メイン・メニューで、「ウィンドウ」→「リソース」を選択します。

2. 「アプリケーション」ウィンドウで、データ・コントロールの作成先とするプロジェクトのノードを選択します。

3. 「リソース」ウィンドウで、「IDE接続」を展開し、REST接続を展開します。

4. 図21-2に示すように、データ・コントロールの基になるリソースを選択して、「データ・コントロール」パネルにドラッグします。

図21-2 RESTful Webサービス接続から選択されたリソース

5. 図21-3に示すように、「リソースの追加の確認」ダイアログで、データ・コントロールの生成先とするプロジェクトを選択し、「追加」をクリックします。

図21-3 「リソースの追加の確認」ダイアログ

6. データ・コントロールに含める各リソースに対して、ステップ4と5を繰り返します。

21.2.2 Webサービス・データ・コントロール・ウィザードを使用したADFデータ・コントロールの作成方法

Webサービス・データ・コントロール・ウィザードを使用して、REST接続とデータ・コントロールを一緒に作成できます。作成したREST接続はADFビジネス・コンポーネントに基づくRESTful Webサービスを使用します。この方法でデータ・コントロールを作成する場合、手動構成は不要です。必要なメタデータはRESTサービスのdescribeエンドポイントで提供されるためです。

始める前に:

ADFアプリケーションでのWebサービス・データ・コントロールの使用方法に関する知識があると、役立つ場合があります。詳細は、「ADFアプリケーションのWebサービス・データ・コントロールについて」を参照してください。

ADFビジネス・コンポーネント・サービスに基づくRESTful Webサービスについて理解しておくと役立つ場合があります。詳細は、「アプリケーション・モジュールによるRESTful Webサービスの作成」を参照してください。

また、他のWebサービス機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFアプリケーションのWebサービス・データ・コントロールの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールによるRESTful Webサービスの作成」の説明に従って、ADF RESTリソースを作成し、RESTful Webサービスとしてデプロイします。

データ・コントロール・ウィザードを使用してREST接続とRESTful Webサービスのデータ・コントロールを作成する手順:

1. 「アプリケーション」ウィンドウで、Webサービス・データ・コントロールを作成する先のプロジェクトを右クリックして、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で「すべてのアイテム」を選択し、スクロール・ダウンして「Webサービス・データ・コントロール(SOAP/REST)」 (データ・コントロール)を選択し、「OK」をクリックします。

3. 「Webサービス・データ・コントロールの作成」ウィザードの「データソース」ページで、データ・コントロールの名前を指定して「REST」ラジオ・ボタンを選択します。
記述ベースのADFデータ・コントロール、または手動で記述された機能を持つ汎用データ・コントロールのいずれかを作成できます。

4. 「記述ベースのADFデータ・コントロール」を選択します。

5. 「新規REST接続の作成」アイコンをクリックして、「REST接続の作成」ダイアログを開きます。

6. 接続の名前と記述URIを入力します。これはADFビジネス・コンポーネントに基づくRESTful Webサービスです。URLにはリソースまたはパラメータを含めないでください。
このURIは、ホスト、ポート、リソース・パスおよびdescribeリソースで構成されます。通常、リソース・パスは、Webサービス・プロジェクトのコンテキスト・ルートと、RESTプロジェクトのweb.xmlファイルのサーブレット・マッピングで指定されたURLパターンで構成されます。バージョン名とリソース名は含めますが、URLパラメータは含めません。たとえば、次のような内容を入力できます。

http://service.example.com:7101/WebServiceProjectContextRoot/rest/VersionName/ResourceName/describe

7. 「認証タイプ」ドロップダウン・リストから認証レベルを選択します。デフォルトの認証タイプは「なし」で、認証は無効になります。セキュリティが必要な場合は、「ダイジェスト」を使用します。この方法では、パスワードはユーザー・パスワードのMD5ダイジェストとしてネットワーク上を送信され、ネットワーク・トラフィックを傍受しても判別できません。「基本」認証は、主にネットワーク上でのサービス・アクセスに高度なセキュリティを必要としない場合にのみ役立ちます。

注意:

「REST接続の作成」ダイアログで、「接続のテスト」をクリックして、URIに接続できることを確認できます。ただし、URIのサーバーがベースURIに対するリクエストを受け入れないように構成されている場合、テストは失敗します。失敗しても関係なく、「OK」をクリックして接続を作成できます。このようなベースURIを使用していて、サービスに接続できることを確認する必要がある場合は、URLに一時的にリソースを追加して、接続をテストしてから、「OK」をクリックする前にリソースを削除できます。

8. 「次へ」をクリックします。

9. 「OWSMポリシー」ページで、必要に応じてWebサービス・クライアントのポリシーをオプションで設定し、「次へ」をクリックします。

10. 指定したWebサービス接続に基づいて、「リソースの選択」ページにリソースのリストが表示されます。すべてのリソースを選択してデータ・コントロールに追加するか(デフォルト)、またはリソースをいくつか選択してデータ・コントロールに追加できます。

11. 「次へ」をクリックし、次に「終了」をクリックします。

21.2.3 REST接続に基づいてデータ・コントロールを作成する場合の処理

REST接続によって含められたリソースに基づいてデータ・コントロールを作成すると、JDeveloperによってデータ・コントロール定義ファイル(DataControls.dcx)が作成され、ファイルが概要エディタで開かれ、データ・コントロールの階層が「データ・コントロール」パネルに表示されます。

DataControls.dcx概要エディタには、各リソースのコレクション・ノードが移入されます。「データ・コントロール」パネルには、それらのコレクションの属性や操作のサブノードに加え、それらの同じコレクション・ノードが表示されます。

たとえば、図21-4に示されたデータ・コントロールには、RESTful Webサービスによって公開されるリソースに対応する、DepartmentsViewというコレクション・オブジェクトがあります。そのサブノードには、そのコレクションおよびネストされたコレクションの属性が含まれ、これらを使用して、値リスト(LOV)コンポーネントを作成できます。また、これにより、標準的なRESTメソッドにマップされる、データ・コントロール・メソッドと組込みデータ・コントロール操作の組合せも公開されます。

図21-4 RESTデータ・コントロールが表示された「データ・コントロール」パネル

複合データ型のパラメータをとる操作の場合は、構造化属性ノードも表示されます。

「データ・コントロール」パネルに表示されるオブジェクトの詳細は、「RESTデータ・コントロールの使用方法」を参照してください。

21.3 RESTデータ・コントロールの使用方法

他の種類のデータ・コントロールと同様に、「データ・コントロール」パネルから項目をドラッグし、それを特定のUIコンポーネントとしてページ上にドロップすることで、データバインドされたユーザー・インタフェースを設計できます。「データ・コントロール」パネルの一般的な使用方法の詳細は、「「データ・コントロール」パネルの使用方法」を参照してください。

「データ・コントロール」パネルでは、各データ・コントロール・オブジェクトがアイコンで表されます。表21-1は、各アイコンが表すもの、「データ・コントロール」パネルの階層内で表示される場所、およびそのアイコンを使用して作成できるコンポーネントを示しています。

注意:

また、ADFビジネス・コンポーネントに基づかない、REST Webサービスに基づくデータ・コントロールを作成することもできます。ただし、そのようなデータ・コントロールでは、公開されるメソッドおよびリソースが多少違います。たとえば、ADFビジネス・コンポーネントに基づかないRESTデータ・コントロールについては、コミット操作およびロールバック操作は公開されません。ビジネス・コンポーネントに基づかないRESTデータ・コントロールの作成および使用の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のADFモデル・レイヤーを使用したWebサービスの使用に関する項を参照してください。

表21-1 RESTデータ・コントロールの「データ・コントロール」パネルのアイコンおよびオブジェクト階層

アイコン

名前

説明

作成する対象

データ・コントロール

データ・コントロールを表します。データ・コントロール自体を使用してUIコンポーネントを作成することはできませんが、そのデータ・コントロールの下に表示される子オブジェクトは使用できます。複数のデータ・コントロールが存在する可能性もあります。これらはそれぞれ、データ関数の論理グループを表しています。

他のオブジェクトのコンテナとして機能します。なし。

メソッド

Webサービスの一部として公開されているカスタム非HTTPメソッドを表します。

注意:
HTTPペイロード・メソッドを指定すると、Webサービス・データ・コントロールによってスキーマが生成され、指定された操作(GET、POST、PUTまたはDELETE)がデータ・コントロール・パネルに表示されます。これらのペイロード操作はメソッドとして表現されます。メソッドが引数をとる場合、その引数は、メソッドのノード内にネストされたパラメータとして「パラメータ」ノードに表示されます。

注意:
ページの設計中に、これらのペイロード操作メソッドはコマンド・ボタンまたはリンクとしてフォーム上で使用できます。フォームに操作をドロップすると、それらの操作は、入力としてすでにドロップされている対応する入力パラメータを受け取ります。その後、フォームをこのボタンにバインドできます。

コマンド・コンポーネント。

パラメータを受け入れるメソッドの場合: コマンド・コンポーネントおよびパラメータ付きフォーム。

詳細は、「ビュー・レイヤーで各機能を起動するコマンド・コンポーネントの使用」を参照してください。

メソッド戻り

Webサービス・メソッドによって戻されたオブジェクトを表します。戻されたオブジェクトは、単一の値またはコレクションです。

メソッド戻りは、これを戻すメソッドの下に、子として表示されます。メソッドの戻りオブジェクトの下の子として表示されるオブジェクトは、該当コレクションの属性、親コレクションに関連するアクションを実行する他のメソッド、および親コレクション上で実行可能な操作です。

単一値のメソッド戻り値がドロップされると、メソッドはフレームワークにより自動的に起動されなくなります。メソッドを起動するために、対応するメソッドをボタンとしてドロップする必要があります。また、タスク・フローを使用している場合は、メソッド・アクティビティを作成できます。実行可能ファイルの詳細は、「ページ定義ファイルで定義されるExecutablesバインディング・オブジェクト」を参照してください。

コレクションと属性、および問合せフォームの場合と同じコンポーネント。

問合せフォームの詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

コレクション

URLサービスの操作から返されるデータ・コントロールを表現します。コレクションは、メソッド戻りオブジェクト、他のコレクション、または構造化属性の下の子として表示されます。コレクションの下の子は、属性、他のコレクション、カスタム・メソッド、コレクションに対して実行できる組込み操作などです。

フォーム、表、グラフ、ツリー、レンジ・ナビゲーションの各コンポーネント、およびマスター/ディテール・コンポーネント。

詳細は、「データバインドされた基本的なページの作成」、「ADFによるデータバインドされた表の作成」、「マスター/ディテール・データの表示」および「データバインドされたチャート・コンポーネントおよびゲージ・コンポーネントの作成」を参照してください。

構造化属性

複合型でありコレクションではない、返されたオブジェクトを表します。たとえば、構造化属性は、現在のサービス・リクエストに割り当てられた単一のユーザーを表現します。

注意:
HTTPペイロード・メソッドを指定すると、指定された操作(GET、POST、PUTまたはDELETE)のスキーマがデータ・コントロールによって生成され、各操作の入力パラメータが別々にデータ・コントロール・パネルに表示されます。ページの設計中に、これらの操作の入力パラメータを使用し、編集可能な形式でページ上にドロップできます。

ラベル、テキスト・フィールド、日付、値リスト、および選択リストの各コンポーネント。

詳細は、「データ・コントロール属性を使用したテキスト・フィールドの作成」および「データバインドされた選択リストおよびシャトルの作成」を参照してください。

属性

オブジェクト内の個別のデータ要素(行の属性など)を表します。属性は、自分の属するコレクションまたはメソッド戻りの下に、子として表示されます。

ラベル、テキスト・フィールドおよび選択リストの各コンポーネント。

詳細は、「データ・コントロール属性を使用したテキスト・フィールドの作成」を参照してください。

操作

親オブジェクトに対してアクションを実行する、組込みデータ・コントロール操作を表します。データ・コントロール操作は、コレクションまたはメソッド戻り値の下の「操作」ノードと、データ・コントロールのルート・ノードの下にもあります。

First、Last、Next、およびPreviousのナビゲーション操作がサポートされます。問合せをリフレッシュするために、Executeがサポートされます。

ビジネス・コンポーネントに基づくRESTデータ・コントロールはトランザクションであるため、ユーザーが実行するすべてのデータ操作はまとめてバッチ処理され、ユーザーがコミット操作を発行するまで、データソースにコミットされません。同様に、コミットされていない任意の変更を取り消すために、ユーザーはロールバック操作を使用できます。

ボタン、リンクおよびメニューなどのUIコマンド・コンポーネント。

詳細は、「データ・コントロール操作を使用したコマンド・コンポーネントの作成」および「入力フォームの作成」を参照してください。

パラメータ

その上に表示されているメソッドによって宣言されたパラメータ値を表します。パラメータは、メソッドまたは操作の下のノードに表示されます。

ラベル、テキストおよび選択リストの各コンポーネント。

注意:

REST接続に基づくサービスについて「データ・コントロール」パネルを使用するには、そのサービスが実行され、かつその接続を介してアクセスできることが必要です。それ以外の場合は、「データ・コントロール」パネルでサービスの構造を表示し、それらの要素に基づいてUIコンポーネントを作成できるようにするために必要な情報がありません。

21.4 アプリケーション・モジュールによって公開されたRESTデータ・コントロールの構成

ADFビジネス・コンポーネントのアプリケーション・モジュールによって公開されるRESTful Webサービスに基づくRESTデータ・コントロールを作成した後、宣言的メタデータを使用して、そのデータ・コントロールから作成されたUIコンポーネントのデフォルトの外観や動作の一部を構成できます。この方法で、次のものを構成できます。

- 属性のデフォルト値

- ラベルのUIヒント、ツールチップ、数値書式など

- 値リスト(LOV)オブジェクト

- 検証ルール

このメタデータを設定するメカニズムは、エンティティ・オブジェクトやビュー・オブジェクトを構成する場合に提供されるものと同様です。

21.4.1 RESTデータ・コントロールの構成方法

データ・コントロールを構成可能にするには、DataControls.dcxファイルの概要エディタを使用し、データ・コントロールに含まれるオブジェクトに対応するデータ・コントロール構造ファイルを作成します。個別のデータ・コントロール構造ファイルを編集できるようになります。

始める前に:

データ・コントロール構成の一般的な知識があると役立ちます。詳細は、「アプリケーション・モジュールによって公開されたRESTデータ・コントロールの構成」を参照してください。

次のタスクを完了する必要があります。

- 「ADF RESTリソースからデータ・コントロールを作成する方法」の説明に従い、RESTデータ・コントロールを作成します。

RESTデータ・コントロールを構成する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、DataControls.dcxをダブルクリックします。

2. 概要エディタで、構成するオブジェクトを選択し、「編集」アイコンをクリックしてデータ・コントロール構造ファイルを生成します(図21-5を参照)。

図21-5 DataControls.dcxファイルの概要エディタ

注意:
RESTデータ・コントロールを編集するには、それがREST接続に基づいている必要があります。前のバージョンのJDeveloperで、URL接続からRESTデータ・コントロールを作成していた場合、アプリケーションを移行したときに、接続はREST接続に変換されています。

3. データ・コントロール構造ファイルの概要エディタで、必要な変更を加えます。

21.4.2 データ・コントロール編集時の処理

データ・コントロールを編集すると、JDeveloperにより、影響を受けたコレクションのメタデータが含まれているデータ・コントロール構造ファイルが作成され、図21-6に示されているように、そのファイルが概要エディタで開かれます。このファイルには、そのリソース固有のデータ・コントロールの構成データ(データ・オブジェクトに対して指定したUIヒントやバリデータなど)が格納されます。

図21-6 データ・コントロール構造ファイルの概要エディタ

注意:

アプリケーション・モジュールによって公開されたサービスに基づくRESTデータ・コントロールでは、それらのアプリケーション・モジュールの開発者がベース・エンティティ・オブジェクトやビュー・オブジェクトに設定した、一部のUIヒントも継承します。RESTデータ・コントロールにUIヒントを設定した場合、エンティティ・オブジェクトまたはビュー・オブジェクト・レベルで、競合するすべてのものに対してその定義が優先されます。

UIヒント、検証ルールおよびLOVの詳細は、次の項を参照してください。

- ビュー・オブジェクトのUIヒントの定義

- 組込みの宣言的な検証規則の使用

- ビュー・オブジェクト属性の値リスト(LOV)での作業

21.4.3 RESTデータ・コントロールの主キーに関する必知事項

一意のRESTリソースは、データ属性ではなく特定のリソースURIによって識別されるため、アプリケーション・モジュールによって公開されるサービスに基づくRESTデータ・コントロールのキーは、生成されたcanonicalという属性によって表現されます。図21-6に示されているように、データ・コントロール構造ファイルの概要エディタの「属性」ページで、キー・アイコンによってこのことが示されます。

setCurrentRowWithKey操作およびsetCurrentRowWithKeyValue操作を使用する場合は、このことに注意することが重要です。これらの操作では、現在の行として設定する対象を識別するパラメータ(rowKey)が必要となります。このため、アプリケーション・モジュール・データ・コントロールを構成する場合のようにエンティティ・オブジェクトの主キーを使用するのではなく、生成されたcanonical属性を使用します。

22 ADF RESTフレームワークを使用したRESTful Webサービスの使用方法

この章では、サポートされているHTTPメソッド、HTTPヘッダー、リクエストURLパラメータ、メディア・タイプおよびその他のADF RESTランタイムの概念と、RESTful Webサービスによって公開されているリソースに対するREST APIコールのためにサポートされているユースケースについて説明します。この章で説明している情報は、Webサービス・クライアントがREST APIを介して使用するRESTful Webサービスを作成する必要がある、ADFビジネス・コンポーネント開発者に役立ちます。

この章の内容は次のとおりです。

- ADF RESTフレームワークについて

- ADFビジネス・コンポーネントのリソースの理解

- ADF RESTリソースの記述の取得

- リソース・バージョンの取得

- ADF RESTリソースの取得

- リソース・アイテムの作成

- リソース・アイテムの更新

- リソース・アイテムの削除

- データ整合性のチェック

- 添付ファイルの使用

- 高度な操作

- ADF RESTフレームワーク・リファレンス

22.1 ADF RESTフレームワークについて

ADF RESTフレームワークは、Fusion Webアプリケーション開発者がRESTアーキテクチャ・スタイルに基づくWeb APIを公開できるようにするADFモデル・フレームワークです。フレームワーク自体はWeb APIを構成しませんが、ADFビジネス・コンポーネントのビジネス・オブジェクトに基づくリソースやRESTful Webサービスの作成およびそれらとの対話をサポートしています。RESTfulである結果、REST APIが使用され、このAPIにより、クライアント・アプリケーション開発者は公開されたビジネス・オブジェクトと対話できます。

Fusion Webアプリケーションにおいては、RESTful Webサービスによって操作されるADF RESTリソースは、ADFビジネス・コンポーネント・モデル・プロジェクトのデータ・モデルで公開されるビュー・オブジェクト・インスタンスが基礎となっています。ADFモデル・プロジェクトで作業するADFビジネス・コンポーネント開発者は、基礎となるビュー・オブジェクトから公開する属性のセット、使用可能にするアクション(標準CRUD操作、およびビュー・オブジェクト・インタフェースまたはビュー行インタフェースのいずれかで定義されているカスタム・メソッドの両方)、および結果として生成されたリソースを保存するビュー・リンク関係を決定できます。

ADFビジネス・コンポーネント開発者による設計時の選択内容は、RESTリソース定義XMLファイルで取得されます。Webサービス・クライアント開発者は、ADF RESTランタイム・フレームワークでサポートされているREST APIを介してこれらのリソース定義と対話できます。これにより、使用するサービス・クライアントはCRUD操作を起動して、RESTリソースおよびADFビジネス・オブジェクトと対話できます。データは、親子関係はそのままで、リソースの基礎となるビュー・オブジェクト・インスタンスによって形成されます。

22.1.1 ADF RESTリソースのユースケースと例

ADFモデル・プロジェクトで作業するADFビジネス・コンポーネント開発者は、ADF RESTリソースを公開し、Fusion Webアプリケーションに提供できます。

クライアントとサーバーによるリソース情報の交換をサポートするADF RESTフレームワークの固有のランタイム機能には、次のものがあります。

- RESTリソースとの対話は、リソース、アクション実行、およびアクション実行の結果に対して、個別のJSONベース・メディア・タイプ構造によってサポートされています。

- GET、POST、PATCH、DELETEなどの標準HTTPリクエスト・メソッドを使用してRESTリクエストと対話します。

- クライアントでの制限によりRESTリソースとの対話に標準HTTPメソッドを使用できない場合は、POSTリクエスト・メソッドを使用するX-HTTP-Method-Overrideヘッダーを使用してHTTPメソッドを実行します。

- RESTリソース・アイテム(特定の従業員など)やリソース・コレクション(すべての従業員のコレクションなど)の特定は、ADFビジネス・コンポーネント・モデル・プロジェクトで定義されているリソース名に基づくREST準拠のURIパス名によってサポートされます。

- RESTリソースの記述(リソース・コレクション属性および使用可能なアクションなど)の取得は、特定のメディア・タイプとdescribeアクションでサポートされています。

- 正規RESTリソースへのリンクは、更新可能エンティティのスーパーセットを持つリソースが定義されている場合にサポートされます。正規のリンクでは、基礎となるビュー・オブジェクトの代替リンクがサポートされます。

- RESTリソースのフィルタ処理は、クライアントが特定のリソースにアクセスするために指定されたURIの問合せ文字列パラメータによりサポートされています。

- 圧縮および解凍を有効化するために、エンコーディング形式がRESTリソースでサポートされています。

- RESTリソースにより公開されるBLOB属性とCLOB属性のコンテンツのストリーミングは、ADF RESTフレームワークでサポートされています。

- RESTful Webサービス起動時のデータ整合性チェックの実行は、ADF RESTフレームワークでサポートされています。この機能では、データベースのバージョン履歴を使用して、クライアントがリソース自体の更新に応じてHTTPペイロードを管理できるようにします。

- ユーザーに対するRESTリソースへのアクセスの認可は、ADFセキュリティ権限の付与によって有効化されます。

ランタイム機能の可用性に影響を与えるADF RESTフレームワークの固有のデザインタイム機能には、次のものがあります。

- URLリソース・パスのLOVアクセッサ・リンクを公開するために、リソースの基礎となるビュー・オブジェクトで値リスト(LOV)属性を定義します。

- URLリソース・パスの行検索キー値を使用してリソースを検索するために、行検索を定義します。

- HTTPメソッドでリクエスト・ペイロードを使用して起動可能なカスタム・アクションを公開するために、ビュー・クライアント・インタフェースまたはビュー行クライアント・インタフェースでクライアント・メソッドを定義します。

- URLリソース・パスの正規のリンクを公開するために、更新可能属性のスーパーセットを使用してアプリケーション・データ・モデルのビュー・インスタンスを定義します。

- サーバーのリソースにアクセスするリクエストを行う場合にデータ整合性チェックを有効化するために、リソースの基礎となるエンティティ・オブジェクトで更新識別子属性を構成します。

- リソースで公開されているリンクを使用するコンテンツ・ストリーミングをサポートするために、リソースの基礎となるビュー・オブジェクトのBLOB属性またはCLOB属性でカスタム・コンテンツ・タイプを構成します。

- リソースへのアクセスを許可する前にユーザーを認証するために、セキュリティを構成します。

22.1.2 RESTful Webサービスの追加機能

RESTful Webサービスを使用する前に、関連するOracle ADF機能を理解しておくと役立つ場合があります。次に、関連するサポート機能へのリンクを示します。

- ADFビジネス・コンポーネント、およびADFビジネス・コンポーネント・モデル・プロジェクトの作成の詳細は、「ADFビジネス・コンポーネントのスタート・ガイド」を参照してください。

- ADFビジネス・コンポーネント・プロジェクトでのRESTful Webサービスの作成(LOVリンク、行検索、カスタム・メソッド、正規リソース、更新識別子、LOB属性のカスタム・コンテンツ・タイプ、セキュリティの有効化を含む)の詳細は、「アプリケーション・モジュールによるRESTful Webサービスの作成」を参照してください。

- ADF RESTデータ・コントロールを使用したユーザー・インタフェースの設計の詳細は、「ADF RESTデータ・コントロールを使用したRESTful Webサービスの使用方法」を参照してください。

22.1.3 この章のリソース・サンプルについて

この章では、ADF RESTリソースとの対話およびADF RESTリソースの操作の一般的なユースケースについて説明します。すべてのサンプルは、Oracle HRスキーマのDEPARTMENTS表、EMPLOYEES表、JOBHISTORY表およびJOBS表に基づきます。図22-1は、ADFビジネス・コンポーネント・モデル・プロジェクトのこれらの表から生成されるビュー・オブジェクトを示しています。

図22-1 RESTサンプル・プロジェクト - ADFビジネス・コンポーネントのビュー・インスタンス

22.1.3.1 サンプル・プロジェクト・ファイルとデータ・モデル

図22-2に示すように、モデル・プロジェクトおよびそのプロジェクトで定義されたビジネス・コンポーネントには、ADF RESTリソース定義ファイルが含まれます。JDeveloperでは、JDeveloperでのリソースの実行とテストを有効化するためにRESTWebServiceプロジェクトも生成されます。

図22-2 RESTサンプル・アプリケーション - ADFビジネス・コンポーネント

図22-3に示すように、Departmentsリソースは、DepartmentsViewビュー・オブジェクトが基礎となっており、子リソースEmployeesが有効化されています。

図22-3 RESTサンプル・プロジェクト - アプリケーション・モジュールのデータ・モデル

22.1.3.2 サンプル・プロジェクト・リソースとリソース・バージョン識別子

図22-4に示すように、アプリケーションでは3つのバージョン・リリース名を定義します。各ADF RESTリソースは、これらのバージョン識別子のいずれかに割り当てられ、実行時にバージョン・リリース名でアクセスされます。たとえば、複数バージョンのEmployeesリソースが作成された場合、1つのバージョンではサポートされる操作セットが限定されており、もう一方のバージョンではより完全な操作セットが提供されます。

バージョン識別子の順序によりバージョンの順序が決まり、最新バージョンがリストの最上位に表示されることに注意してください。RESTサンプルでは、複数バージョンのEmployeesリソースが存在する場合、リリース名11.2が最新バージョンとして識別されます。

図22-4 RESTサンプル・プロジェクト - リソース・バージョン

図22-3に示すように、アプリケーション・モジュールは、作成されたリソースを、それらに割り当てられたバージョン・リリース名で編成します。Employeesリソースは、最初にバージョン11.0で作成され、それ以降のバージョン11.1および11.2では新しい必須属性を追加して改訂されます。11.1で追加されたJobsリソースでは、LOV有効属性を含むEmployeesリソースに対する作成操作がサポートされています。

図22-5 RESTサンプル・プロジェクト - アプリケーション・モジュール・リソース名

図22-6に示すように、DepartmentsリソースはDepartmentsViewビュー・オブジェクトが基礎となっており、子リソースEmployeesとJobHistoryが有効化されています。

子リソースEmployeesの名前はビュー・リンク定義のリンク先ビュー・インスタンス名から導出されることに注意してください。このサンプルでは、リンク先ビュー・インスタンスの名前がEmployeesView1からEmployeesに変更されています。これにより、デフォルト名EmployeesView1ではなく名前EmployeesをURLリソース・パスで使用して子リソースにアクセスできます。

図22-6 RESTサンプル・プロジェクト - Departmentsリソース

図22-7に示すように、バージョン11.0のEmployeesルート・リソースは、EmployeesViewビュー・オブジェクトが基礎となっています。Employeesはルート・リソースとして作成されているため、子リソース・アクセッサを持ちません。

図22-7 RESTサンプル・プロジェクト - Employeesリソース・バージョン11.0

図22-8に示すように、EmployeesViewビュー・オブジェクトには、バージョン11.0のEmployeesルート・リソースで定義された複数のリソースがあります。HREmployeesリソースとBenefitsEmployeesリソースは、一意のビュー・オブジェクト形成定義が基礎となっており、これらの各リソースによりEmployeesリソースが正規リソースとして定義されます。

図22-8 RESTサンプル・プロジェクト - 正規Employeeリソース・バージョン11.0

図22-9に示すように、バージョン11.1のEmployeesルート・リソースでは、LOVが有効なEmployeesView属性JobIdのJobsリソースを使用したリソース・アイテムの作成を有効にするCreate操作などの機能が追加されています。実行時に、Jobsリソースは、行のコンテキストを必要とせずに、LOV有効属性JobIdの値を指定します。このバージョンでは、Employeesリソース・コレクションでのサブタイプの使用も有効化されています(JobId属性がサブタイプ・リソースの識別子として機能します)。実行時に、Employeesリソースは、ジョブIDがSA_REP (販売責任者)の従業員のコミッション属性を表示します。

図22-9 RESTサンプル・プロジェクト - Employeesリソース・バージョン11.1

図22-10に示すように、バージョン11.2のEmployeesルート・リソースは、EmpByEmailFinder行検索を追加して、従業員を電子メール・アドレスで検索できるようにしています。

図22-10 RESTサンプル・プロジェクト - Employeesリソース・バージョン11.2

22.1.3.3 エンティティ・オブジェクトとビュー・オブジェクトのカスタマイズ

**INTERNAL XREF ERROR**に示すように、EmployeesViewビュー・オブジェクトでは、LOV有効属性JobIdを定義します。LOVアクセッサ・リソースは、役職別のジョブ・リストを返し、対応するジョブIDの選択肢として示します。

JDeveloperでは、リソース定義で意図的にLOVアクセッサを公開しないことに注意してください。実行時に、ADF RESTランタイムは、リソース・アイテムのLOV有効属性の子としてLOVアクセッサ・リソースを自動的にネストします。

また、図22-11に、LOV有効属性が定義された新しいリソース・アイテムの作成のサポートを示します。EmployeesViewは、(v2:Jobsとして識別される)特定のバージョンのLOVアクセッサ・リソースを、LOV有効属性JobIdに関連付けます。実行時に、Employeesリソースの記述により、LOVリソースへのリンクが公開されます。リソース・アイテムを作成するPOSTリクエストにLOVリソースの支援が含まれることがあります。この場合、ビュー・オブジェクトLOV定義に依存することによりLOV有効属性に適切な値が返されます。

図22-11 RESTサンプル・プロジェクト - Employees LOV有効属性

図22-12に示すように、EmployeesViewビュー・オブジェクトは、EmpByEmailFinder行検索を定義します。行検索では、従業員IDではなく従業員の電子メール・アドレス(Email属性)を使用して従業員を取得します。

行検索は、デフォルトですべてのバージョンのリソースで公開されることに注意してください。ただし、行検索キー属性が特定のリソース定義で定義されている場合は、その検索名をURLリソース・パスで使用する必要があります。行検索キーがリソース定義で明示的に定義されるまでは、URLリソース・パスでキー属性(このサンプルではEmployeeId)が必要となります。

図22-12 RESTサンプル・プロジェクト - Employees行検索

図22-13に示すように、EmployeesViewビュー・オブジェクトでは、Picture属性でカスタム・コンテンツ・タイプimage/pngを定義します。このコンテンツ・タイプにより、属性のデフォルトのapplication/octet-streamコンテンツ・タイプ定義が置換され、イメージ・コンテンツのストリーミング時に期待される受入れタイプになります。

図22-13 RESTサンプル・プロジェクト - Employees BLOBコンテンツ・タイプ

図22-14に示すように、EmployeesViewビュー・オブジェクトでは、Employeesリソースで使用するカスタム・サービス・メソッドmultiplySalaryを定義します。このメソッドはビュー行インタフェースで定義されているため、リソース・コレクション(すべての従業員)ではなくリソース・アイテム(特定の従業員)のレベルでカスタム・アクションとして公開されます。ビュー・オブジェクト・クライアント・インタフェースで定義されているメソッドのみが、リソース・コレクションに対して機能します。

図22-14 RESTサンプル・プロジェクト - Employeesビュー行インタフェース・カスタム・メソッド

図22-15に示すように、Departmentsエンティティ・オブジェクトでは、データ整合性チェックを有効化する更新識別子属性RelStateを定義します。属性のエディタでは、更新識別子を構成するために「更新識別子」フィールドと「履歴列」 - 「バージョン番号」フィールドが有効になっています。

図22-15 RESTサンプル・プロジェクト - Departments更新識別子属性

22.2 ADFビジネス・コンポーネントのリソースの理解

サービス開発者がADFビジネス・コンポーネント・モデル・プロジェクトで作成するADF RESTリソースは、プロジェクト・アプリケーション・モジュールで定義されたビュー・オブジェクト・インスタンスに基づきます。次に例を示します。

- Departmentsリソースは、DepartmentsVOビュー・インスタンス、およびEmployeesVOビュー・インスタンスへのアクセッサに基づきます。

- Employeesリソースは、EmployeesVOビュー・インスタンスに基づきます。

実行時に、RESTful Webサービスのアクションが起動されると、サービスにより返されるペイロードには1つ以上のリソース・コレクションが含まれ、基礎となるビュー・オブジェクトにより問合せが行われる行セット、およびビュー・オブジェクト行の個々の属性で構成されます。リソース・コレクションでは、マスター/ディテール調整ビュー・インスタンスの関係が維持されます。

表22-1に示すように、リソース・コレクションは、ビュー・オブジェクト・インスタンスのRESTful Webサービス・ペイロード表現です。リソース・アイテムは、ペイロード・アイテム・オブジェクトの行および属性で、ビュー・オブジェクト行に対応します。

注意:

ADFリソース・コレクションおよび含まれているアイテムの形式は、特定のADF RESTメディア・タイプによりJSONエンコード・エンティティとして定義されます。詳細は、「ADF RESTメディア・タイプ」を参照してください。

表22-1 JSONオブジェクトおよびADFビジネス・コンポーネント表現

JSONオブジェクト

ADFビジネス・コンポーネント

resource collection

1つ以上の行で構成されるビュー・オブジェクト・インスタンス。Departments、Employeesは、DepartmentsVOビュー・インスタンスとEmployeesVOビュー・インスタンスに基づくリソース・コレクションの例です。

resource item

ビュー・オブジェクト行。特定の部門10または従業員1012は、Departmentsリソース・コレクションとEmployeesリソース・コレクションのリソース・アイテムの例です。

22.3 ADF RESTリソースの記述の取得

RESTful Webサービスの記述により、ADF RESTful Webサービスで許可されている形状とアクションを識別できます。RESTリソース定義で定義されている属性、アクションおよびリンクを含むJSONオブジェクトを返します。

ADF RESTフレームワークでは、サービス・エンドポイントに関して次の記述のユースケースをサポートしています。

- 使用可能なすべてのリソース(リソース・カタログ)を記述します。

- 単一のリソース・コレクションを記述します。

- 単一のリソース・アイテムを記述します。

- 親子関係でのネストされたリソースを記述します。

記述を取得するには、/describeをリソースURLに追加して、HTTP GETを起動します。

注意:

GETリクエストを実行してリソースの記述を取得する場合、クライアントが特定バージョンのコンテキストにあることも必要となります。サービス・エンドポイントのバージョン・リリース名の取得方法の詳細は、「リソース・バージョンの取得」を参照してください。

たとえば、次のURLは、識別されたアプリケーションのバージョン11.0のEmployeesリソースに関する記述を返します。

http://host:port/context-root/rest/11.0/Employees/describe

アプリケーションの特定バージョンのすべてのリソースの記述を取得するには、/describeをバージョンURLに追加します。

たとえば、次のURLは、識別されたアプリケーションのバージョン11.0のすべてのリソースに関する記述を返します。

http://host:port/context-root/rest/11.0/describe

22.3.1 使用可能なすべてのリソースの記述

ADF RESTランタイムでは、GETメソッドを使用した、アプリケーション・エンド・ポイントの使用可能なすべてのリソースの記述をサポートしています。

リソース・カタログ内の使用可能なすべてのリソースを調査する手順は次のとおりです。

1. リソース・カタログの記述を実行し、その記述内でリソースの名前を検索します。children属性により、ネストされたリソースを識別します。

2. これらのリソース・オブジェクトを調査して、各リソースの形状を理解します。

- attributesでは、使用可能なリソース・コレクション属性のリストを指定します。

- collectionでは、コレクションの形状を指定し、finder (行検索の場合)、links、および使用可能なactions (メディア・タイプを含む)を指定します。

- itemでは、コレクションのインスタンスの形状を指定し、item自体ではlinksと使用可能なactionsを指定します。

- childrenでは、ネストされたリソースを指定します(children自体にはattributesオブジェクト、collectionオブジェクトおよびitemオブジェクトが含まれます)。

たとえば、Departmentsリソースと子Employeesリソースを含むサービスの記述は、次のオブジェクトを返します。

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
...
} ],
"collection" : {
...
} ],
"finders" : [ {
} ]
"links" : [ {
} ]
"actions" : [ {
} ]
},
"item" : {
"links" : [ {
} ]
"actions" : [ {
} ]
},
"children" : {
"Departments"
...
} ],
...
"links" : [ {
} ]
}
}

次のサンプルは、リソース・カタログ内のバージョン11.0のすべてのリソースを記述します。URLバージョン・パラメータ11.0は、アプリケーション固有のバージョン識別子に置き換えられる場合があることに注意してください。リソース・バージョンの指定の詳細は、「リソース・バージョンの取得」を参照してください。

リクエスト

- URL
http://server/demo/rest/11.0/describe

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.description+json

- ペイロード

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10,
"controlType" : "choice",
"maxLength" : "10",
"lov" : {
"childRef" : "JobsLOV",
"attributeMap" : [ {
"source" : "JobTitle",
"target" : "JobId"
} ],
"displayAttributes" : [ "JobTitle" ]
}
}, {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 4
}, {
"name" : "Salary",
"type" : "number",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 8,
"scale" : 2
}, {
"name" : "Picture",
"type" : "attachment",
"updatable" : true,
"mandatory" : false,
"queryable" : false,
"actions" : [ {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "image/png" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "get",
"method" : "GET",
"responseType" : [ "image/png" ]
} ]
} ],
"collection" : {
"rangeSize" : 24,
"finders" : [ {
"name" : "EmpByEmailFinder",
"title" : "EmployeesByEmailVC",
"attributes" : [ {
"name" : "Email",
"type" : "string",
"updatable" : true,
"required" : "Optional",
"queryable" : false
} ]
}, {
"name" : "PrimaryKey",
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourcecollection+json" ]
}, {
"name" : "create",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
} ]
},
"item" : {
"links" : [ {
"rel" : "lov",
"href" : "http://server/demo/rest/11.0/Employees/{id}/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
}, {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/{id}",
"name" : "self",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/{id}",
"name" : "canonical",
"kind" : "item"
}, {
"rel" : "enclosure",
"href" : "http://server/demo/rest/11.0/Employees/enclosure/Picture",
"name" : "Picture",
"kind" : "other"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "multiplySalary",
"parameters" : [ {
"name" : "multiplicand",
"type" : "number",
"mandatory" : false
} ],
"resultType" : "number",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.action+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.actionresult+json" ]
} ]
},
"children" : {
"JobsLOV" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "JobId",
"type" : "string",
"updatable" : false,
"mandatory" : true,
"queryable" : true,
"precision" : 10
}, {
"name" : "JobTitle",
"type" : "string",
"updatable" : false,
"mandatory" : true,
"queryable" : true,
"precision" : 35
}, {
"name" : "MinSalary",
"type" : "integer",
"updatable" : false,
"mandatory" : false,
"queryable" : true,
"precision" : 6
}, {
"name" : "MaxSalary",
"type" : "integer",
"updatable" : false,
"mandatory" : false,
"queryable" : true,
"precision" : 6
} ],
"collection" : {
"rangeSize" : 0,
"finders" : [ {
"name" : "PrimaryKey",
"attributes" : [ {
"name" : "JobId",
"type" : "string",
"updatable" : false,
"mandatory" : true,
"queryable" : true,
"precision" : 10
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/{id}/child/JobsLOV",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourcecollection+json" ]
}, {
"name" : "create",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
} ]
},
"item" : {
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/{id}/child/JobsLOV/{id}",
"name" : "self",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Employees/{id}",
"name" : "parent",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/{id}/child/JobsLOV/{id}",
"name" : "canonical",
"kind" : "item"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "update",
"method" : "PATCH",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
} ]
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/{id}/child/JobsLOV/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/{id}/child/JobsLOV/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/describe",
"name" : "canonical",
"kind" : "describe"
} ]
},
"Departments" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 4
}, {
"name" : "DepartmentName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 30
}, {
"name" : "RelState",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true
} ],
"collection" : {
"rangeSize" : 24,
"finders" : [ {
"name" : "PrimaryKey",
"attributes" : [ {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 4
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourcecollection+json" ]
}, {
"name" : "create",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "testImpl",
"parameters" : [ {
"name" : "testid",
"type" : "string",
"mandatory" : false
} ],
"resultType" : "string",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.action+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.actionresult+json" ]
} ]
},
"item" : {
"links" : [ {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees",
"name" : "Employees",
"kind" : "collection",
"cardinality" : {
"value" : "1 to *",
"sourceAttributes" : "DepartmentId",
"destinationAttributes" : "DepartmentId"
}
}, {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/{id}",
"name" : "self",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/{id}",
"name" : "canonical",
"kind" : "item"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "update",
"method" : "PATCH",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
} ]
},
"children" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10,
"controlType" : "choice",
"maxLength" : "10",
"lov" : {
"childRef" : "JobsLOV",
"attributeMap" : [ {
"source" : "JobTitle",
"target" : "JobId"
} ],
"displayAttributes" : [ "JobTitle" ]
}
}, {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 4
}, {
"name" : "Salary",
"type" : "number",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 8,
"scale" : 2
}, {
"name" : "Picture",
"type" : "attachment",
"updatable" : true,
"mandatory" : false,
"queryable" : false,
"actions" : [ {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "image/png" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "get",
"method" : "GET",
"responseType" : [ "image/png" ]
} ]
} ],
"collection" : {
"rangeSize" : 0,
"finders" : [ {
"name" : "EmpByEmailFinder",
"title" : "EmployeesByEmailVC",
"attributes" : [ {
"name" : "Email",
"type" : "string",
"updatable" : true,
"required" : "Optional",
"queryable" : false
} ]
}, {
"name" : "PrimaryKey",
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourcecollection+json" ]
}, {
"name" : "create",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
} ]
},
"item" : {
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/{id}",
"name" : "self",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/{id}",
"name" : "parent",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/{id}",
"name" : "canonical",
"kind" : "item"
}, {
"rel" : "enclosure",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/{id}/enclosure/Picture",
"name" : "Picture",
"kind" : "other"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "update",
"method" : "PATCH",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "multiplySalary",
"parameters" : [ {
"name" : "multiplicand",
"type" : "number",
"mandatory" : false
} ],
"resultType" : "number",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.action+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.actionresult+json" ]
} ]
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
}
}

22.3.2 リソース・コレクションの記述

ADF RESTランタイムでは、GETメソッドを使用したリソース・コレクションの記述をサポートしています。

リソース・コレクションを調査する手順は次のとおりです。

1. リソース・コレクションの記述を実行し、その記述内でリソースの名前を検索します。

2. これらのリソース・オブジェクトを調査して、各リソースの形状を理解します。

- attributesでは、使用可能なリソース・コレクション属性のリストを指定します。

- collectionでは、コレクションの形状を指定し、finder (行検索の場合)、links、および使用可能なactions (メディア・タイプを含む)を指定します。

- itemでは、コレクションのインスタンスの形状を指定し、item自体ではlinksと使用可能なactionsを指定します。

- childrenでは、ネストされたリソースを指定します(children自体にはattributesオブジェクト、collectionオブジェクトおよびitemオブジェクトが含まれます)。

たとえば、Departmentsリソースの記述は、次のオブジェクトを返します。

{
"Resources" : {
"Departments" : {
"discrColumnType" : false,
"attributes" : [ {
...
} ],
"collection" : {
...
} ],
"finders" : [ {
} ]
"links" : [ {
} ]
"actions" : [ {
} ]
},
"item" : {
"links" : [ {
} ]
"actions" : [ {
} ]
},
"children" : {
"Employees"
...
} ],
...
"links" : [ {
} ]
}
}

次のサンプルは、バージョン11.0のDepartmentsリソースを記述します。

リクエスト

- URL
http://server/demo/rest/11.0/Departments/describe

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.description+json

- ペイロード

{
"Resources" : {
"Departments" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 4
}, {
"name" : "DepartmentName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 30
}, {
"name" : "RelState",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true
} ],
"collection" : {
"rangeSize" : 25,
"finders" : [ {
"name" : "PrimaryKey",
"attributes" : [ {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 4
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourcecollection+json" ]
}, {
"name" : "create",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "testImpl",
"parameters" : [ {
"name" : "testid",
"type" : "string",
"mandatory" : false
} ],
"resultType" : "string",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.action+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.actionresult+json" ]
} ]
},
"item" : {
"links" : [ {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees",
"name" : "Employees",
"kind" : "collection",
"cardinality" : {
"value" : "1 to *",
"sourceAttributes" : "DepartmentId",
"destinationAttributes" : "DepartmentId"
}
}, {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/{id}",
"name" : "self",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/{id}",
"name" : "canonical",
"kind" : "item"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "update",
"method" : "PATCH",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
} ]
},
"children" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10,
"controlType" : "choice",
"maxLength" : "10",
"lov" : {
"childRef" : "JobsLOV",
"attributeMap" : [ {
"source" : "JobTitle",
"target" : "JobId"
} ],
"displayAttributes" : [ "JobTitle" ]
}
}, {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 4
}, {
"name" : "Salary",
"type" : "number",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 8,
"scale" : 2
}, {
"name" : "Picture",
"type" : "attachment",
"updatable" : true,
"mandatory" : false,
"queryable" : false,
"actions" : [ {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "image/png" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "get",
"method" : "GET",
"responseType" : [ "image/png" ]
} ]
} ],
"collection" : {
"rangeSize" : 0,
"finders" : [ {
"name" : "EmpByEmailFinder",
"title" : "EmployeesByEmailVC",
"attributes" : [ {
"name" : "Email",
"type" : "string",
"updatable" : true,
"required" : "Optional",
"queryable" : false
} ]
}, {
"name" : "PrimaryKey",
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourcecollection+json" ]
}, {
"name" : "create",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
} ]
},
"item" : {
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/{id}",
"name" : "self",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/{id}",
"name" : "parent",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/{id}",
"name" : "canonical",
"kind" : "item"
}, {
"rel" : "enclosure",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/{id}/enclosure/Picture",
"name" : "Picture",
"kind" : "other"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "update",
"method" : "PATCH",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "multiplySalary",
"parameters" : [ {
"name" : "multiplicand",
"type" : "number",
"mandatory" : false
} ],
"resultType" : "number",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.action+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.actionresult+json" ]
} ]
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
}
}

22.3.3 リソース・アイテムの記述

ADF RESTランタイムでは、GETメソッドを使用したリソース・アイテムの記述をサポートしています。

リソース・アイテムの記述は、通常、コレクションの記述と同じ情報を提供することに注意してください。ただし、多相コレクションの場合、リソース・アイテムの記述には、リソース・コレクションの記述よりも多くの情報が含まれます。たとえば、(車両リソースに自動車アイテムと航空機アイテムが含まれる)多相コレクション車両について考えてみます。車両の記述は、すべての車両の一般的な形状を返し、自動車リソース・アイテムの記述はそのオブジェクト固有の形状を返します。

リソース・アイテムを調査する手順は次のとおりです。

1. リソース・アイテムの記述を実行し、その記述内でリソースの名前を検索します。children属性により、ネストされたリソースを識別します。

2. リソース・アイテムの記述を調査して、その形状を理解します。

- attributesでは、使用可能なリソース・コレクション属性のリストを指定します。

- itemでは、アイテム(定義された子コレクションなど)へのlinks、および使用可能なactionsを指定します。

- linksでは、記述のリンクを指定します。

たとえば、Departmentsリソース・アイテムの記述は、次のオブジェクトを返します。

{
"Resources" : {
"Departments" : {
"discrColumnType" : false,
"attributes" : [ {
...
} ],
"item" : {
"links" : [ {
} ]
"actions" : [ {
} ]
},
"links" : [ {
} ]
}
}

次のサンプルは、バージョン11.0のDepartmentsリソース・コレクションのインスタンスを記述します。

注意: リクエストした記述上のリソース・アイテムのすべての子が再帰的に含まれるようにするには、記述URLに問合せパラメータ?includeChildren=trueを指定します。

リクエスト

- URL
http://server/demo/rest/11.0/Departments/10/describe

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.description+json

- ペイロード

{
"Resources" : {
"Departments" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 4
}, {
"name" : "DepartmentName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 30
}, {
"name" : "RelState",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true
} ],
"item" : {
"links" : [ {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection",
"cardinality" : {
"value" : "1 to *",
"sourceAttributes" : "DepartmentId",
"destinationAttributes" : "DepartmentId"
}
}, {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "self",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "canonical",
"kind" : "item"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "update",
"method" : "PATCH",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
} ]
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
}
}

22.3.4 ネストされたリソースの記述

ADF RESTランタイムでは、GETメソッドを使用した、ADF RESTのネストされたリソースの記述をサポートしています。

リソース・カタログ内のネストされたリソースを調査する手順は次のとおりです。

1. ネストされたリソースの記述を実行し、その記述内でリソースの名前を検索します。children属性により、ネストされたリソースを識別します。

2. これらのリソース・オブジェクトを調査して、各リソースの形状を理解します。

- attributesでは、使用可能なリソース・コレクション属性のリストを指定します。

- collectionでは、コレクションの形状を指定し、finder (行検索の場合)、links、および使用可能なactions (メディア・タイプを含む)を指定します。

- itemでは、コレクションのインスタンスの形状を指定し、item自体ではlinksと使用可能なactionsを指定します。

- childrenでは、ネストされたリソースを指定します(children自体にはattributesオブジェクト、collectionオブジェクトおよびitemオブジェクトが含まれます)。

たとえば、ネストされたリソースDepartmentsとリソースEmployeesの記述は、次のオブジェクトを返します。

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
...
} ],
"collection" : {
...
} ],
"finders" : [ {
} ]
"links" : [ {
} ]
"actions" : [ {
} ]
},
"item" : {
"links" : [ {
} ]
"actions" : [ {
} ]
},
"children" : {
"Departments"
...
} ],
...
"links" : [ {
} ]
}
}

次のサンプル(URL1)は、Departmentのコンテキストで見つけることができるバージョン11.0のEmployeesリソースを記述します。2番目のサンプル(URL2)は、ネストされた同じリソースEmployeesのアイテムを記述します(ネストされたリソース・アイテムは従業員のIDにより識別されます)。

注意: リクエストした記述上のリソース・アイテムのすべての子が再帰的に含まれるようにするには、記述URLに問合せパラメータ?includeChildren=trueを指定します。

リクエスト

- URL 1
http://server/demo/rest/11.0/Departments/10/child/Employees/describe

- URL 2
http://server/demo/rest/11.0/Departments/10/child/Employees/200/describe

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.description+json

- ペイロード 1

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10,
"controlType" : "choice",
"maxLength" : "10",
"lov" : {
"childRef" : "JobsLOV",
"attributeMap" : [ {
"source" : "JobTitle",
"target" : "JobId"
} ],
"displayAttributes" : [ "JobTitle" ]
}
}, {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 4
}, {
"name" : "Salary",
"type" : "number",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 8,
"scale" : 2
}, {
"name" : "Picture",
"type" : "attachment",
"updatable" : true,
"mandatory" : false,
"queryable" : false,
"actions" : [ {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "image/png" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "get",
"method" : "GET",
"responseType" : [ "image/png" ]
} ]
} ],
"collection" : {
"rangeSize" : 25,
"finders" : [ {
"name" : "EmpByEmailFinder",
"title" : "EmployeesByEmailVC",
"attributes" : [ {
"name" : "Email",
"type" : "string",
"updatable" : true,
"required" : "Optional",
"queryable" : false
} ]
}, {
"name" : "PrimaryKey",
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourcecollection+json" ]
}, {
"name" : "create",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
} ]
},
"item" : {
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/{id}",
"name" : "self",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "parent",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/{id}",
"name" : "canonical",
"kind" : "item"
}, {
"rel" : "enclosure",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/enclosure/Picture",
"name" : "Picture",
"kind" : "other"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "update",
"method" : "PATCH",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "multiplySalary",
"parameters" : [ {
"name" : "multiplicand",
"type" : "number",
"mandatory" : false
} ],
"resultType" : "number",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.action+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.actionresult+json" ]
} ]
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
}
}

- ペイロード 2

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10,
"controlType" : "choice",
"maxLength" : "10",
"lov" : {
"childRef" : "JobsLOV",
"attributeMap" : [ {
"source" : "JobTitle",
"target" : "JobId"
} ],
"displayAttributes" : [ "JobTitle" ]
}
}, {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 4
}, {
"name" : "Salary",
"type" : "number",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 8,
"scale" : 2
}, {
"name" : "Picture",
"type" : "attachment",
"updatable" : true,
"mandatory" : false,
"queryable" : false,
"actions" : [ {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "image/png" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "get",
"method" : "GET",
"responseType" : [ "image/png" ]
} ]
} ],
"item" : {
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/200",
"name" : "self",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "parent",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/200",
"name" : "canonical",
"kind" : "item"
}, {
"rel" : "enclosure",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/200/enclosure/Picture",
"name" : "Picture",
"kind" : "other"
} ],
"actions" : [ {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "update",
"method" : "PATCH",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "application/vnd.oracle.adf.resourceitem+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.resourceitem+json" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "multiplySalary",
"parameters" : [ {
"name" : "multiplicand",
"type" : "number",
"mandatory" : false
} ],
"resultType" : "number",
"method" : "POST",
"requestType" : [ "application/vnd.oracle.adf.action+json" ],
"responseType" : [ "application/json", "application/vnd.oracle.adf.actionresult+json" ]
} ]
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/200/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees/200/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
}
}

22.3.5 ADF RESTの記述内のlinksオブジェクト構造の理解

linksは、値が常にURLリンクとなるJSONオブジェクトであり、リンク名はそのリンクのrelに応じて定義されます。linksオブジェクトは、各リソース・コレクション、リソース・アイテムおよびリソース自体に対して生成されます。

リソースの記述内のURLリンクは、そのURLのすべての部分を決定する十分な情報がない場合、テンプレート・プレースホルダ値({id})を使用して生成されることに注意してください。たとえば、次の子リンクは、特定のDepartmentリソースの値のプレースホルダを含むURLを提供します。

"item" : {
"links" : [ {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/{id}/child/Employees",
"name" : "Employees",
"kind" : "collection",
"cardinality" : {
"value" : "1 to *",
"sourceAttributes" : "DepartmentId",
"destinationAttributes" : "DepartmentId"
}

22.3.5.1 rel属性の値

rel属性は、現在のリソースとリンクが指すリソースとの間のリンク関係のタイプを定義します。関係は、表22-2に示すいずれかの値で指定できます。

表22-2 ADF RESTリソースの記述でのリンク関係

リンク関係

説明

self

常にリソース用に生成されます。hrefは、リソース自体またはリソースの記述を指します。linksオブジェクトでは、リンク名は、このrelのselfとなります。

canonical

常に生成されます。hrefは、正規リソースまたは正規リソースの記述を指します。正規リソースが定義されていない場合、selfが持っているのと同じhrefを持ちます。linksオブジェクトでは、リンク名は、このrelのcanonicalとなります。

parent

常にネストされたリソース用に生成されます。hrefは、親リソースのselfリンクを指します。linksオブジェクトでは、リンク名は、このrelのparentとなります。

child

リソースにネストされた子が存在する場合に生成されます。hrefは、ネストされたコレクションを指します。linksオブジェクトでは、リンク名は、このrelの<accessor_name>となります。

lov

リソース・アイテムでLOV(値リスト)有効属性用に生成されます。2つのタイプのhrefがあります。1.) リソース・アイテムのlinksオブジェクト上では、hrefはLOV子リソース(リソース・アイテムのchildRefプロパティで指定される名前)を示し、2.) リソース記述上のlinksオブジェクトでは、hrefはLOVリソース(リソース・アイテムのlovResourcePathプロパティで指定される名前)を示します。

最初のタイプはLOVビュー・アクセッサおよびリソース・アイテムの基礎となるLOV有効属性によって、モデル・プロジェクト内で定義されます。2つ目のタイプはLOVアクセッサ上のLOVリソースによってモデル・プロジェクト内で定義され、リソースがリソース・アイテムの基礎となるLOV有効属性に関連付けられます。

enclosure

BLOB属性とCLOB属性用にデフォルトで生成されます。この関係では、サポートされているペイロード・タイプで表すことができないリソースを指すリンクを示します。この関係の例として、JSONで表すことができないイメージがあります。

external

フレームワーク・ドメインの外部に存在するリソース用に生成されます。

current

複数のリソース・バージョン識別子が存在する場合にリソース・バージョンの記述内に生成されます。hrefは、adf-config.xmlバージョン識別子で定義されている、最新のバージョン識別子を指します。

predecessor-version

複数のリソース・バージョン識別子が存在する場合にリソース・バージョンの記述内に生成されます。hrefは、adf-config.xmlバージョン識別子で定義されている、前のバージョン識別子を指します。

successor-version

複数のリソース・バージョン識別子が存在する場合にリソース・バージョンの記述内に生成されます。hrefは、adf-config.xmlバージョン識別子で定義されている、2番目に最新のバージョン識別子を指します。

describe

リソース・バージョンの記述内に生成されます。hrefは、同じバージョンのすべてのリソースのリソース・カタログの記述を指します。

22.3.5.2 href属性の値

href属性は、リンクされたリソースまたはリンクの記述へのURLを定義します。

22.3.5.3 cardinality属性の値

cardinality属性は、ソース・リソースと宛先リソースとの間のカーディナリティを定義するオプションの属性です。この属性は、rel属性値がchildで、リソース・タイプがvnd.oracle.adf.description+jsonである場合にのみ使用可能です。このカーディナリティ属性には次の属性があります。

- value: カーディナリティの値。例: "1 to *"

- sourceAttributes: 宛先リソースへのリンクに使用される、ソース・リソース内の属性。

- destinationAttributes: ソース・リソースへのリンクに使用される、宛先リソース内の属性。

22.4 リソース・バージョンの取得

JDeveloperでは、ADF RESTリソース開発者は、バージョン識別子を作成し、これらの識別子を自分が作成したリソースに関連付けます。バージョン識別子を使用することで、RESTリソース開発者は既存のリソース定義の更新を管理できます。前のバージョンと後方互換性のない変更を使用してリソースを更新する必要がある場合、リソース開発者は新しいバージョンのリソースを作成し、そのリソースに一意のバージョン識別子を割り当てることができます。

ADF RESTランタイムでは、アプリケーションで定義されているバージョンの取得(使用可能なすべてのバージョン、最新のバージョンのみ、または特定のバージョンのみの取得など)をサポートしています。

また、RESTリソース開発者は、バージョン識別子を作成または更新するときにライフサイクル・ステータス(active、desupported、deprecated)を割り当てることができます。deprecatedのタグが付けられたリソースは、有効なリソースとして処理され、そのステータスはランタイムに影響を与えません。これに対し、ライフサイクル・ステータスdesupportedのタグが付いているリソースは、サービス・クライアントからアクセスできなくなり、サポートされないバージョンに対するリクエストは、次のエラー・メッセージを返します。

JBO-29151: The requested version 'x' has been desupported.

サービス・クライアントが、リクエストされたバージョンに存在しないリソースをリクエストすると、ADF RESTランタイムによって、ステータスがactiveまたはdeprecatedになっている前のバージョンにフォールバックされます。このため、Departmentsリソースのバージョン11.0および11.1が存在し、11.2が存在しない場合は、バージョン11.2へのリクエストに対して、次に最新のリソースであるバージョン11.1が返されます。

22.4.1 使用可能なすべてのバージョン・リリース名の取得

ADF RESTランタイムでは、GETメソッドを使用した、サービス・エンドポイントに定義されているバージョン・リリース名の取得をサポートしています。

バージョン・リリース名を調査する手順は次のとおりです。

1. サービス・エンドポイントの記述を実行し、その記述内で使用可能なバージョン・リリース名を検索します。

2. 次の要素を調査して、リリース名バージョン識別子の順序を理解します。

- versionは、adf-config.xmlファイルで定義されているバージョン識別子のリリース名を指定します。

- isLatestプロパティは、バージョンが最新のバージョン識別子であることを指定します。

- predecessor-versionは、前のバージョン識別子へのリンクを指定します。

- successor-versionは、2番目に最新のバージョン識別子へのリンクを指定します。

- currentは、最新のバージョン識別子へのリンクを指定します。

たとえば、2つのリリース名バージョン識別子を持つサービス・エンドポイントの記述は、次のオブジェクトを返します。

{
"items" : [
{
"version" : "version_identifier_latest",
"isLatest" : true,
"links" : [
{
"rel" : "self",
...

},
{
"rel" : "canonical",
...

},
{
"rel" : "predecessor-version",
...

},
{
"rel" : "describe",
...

}
]
},
{
"version" : "version_identifier_previous",
"links" : [
{
"rel" : "self",
...
},
{
"rel" : "canonical",
...
},
{
"rel" : "successor-version",
...
},
{
"rel" : "describe",
...
}
]
}
],
"links" : [
...
{
"rel" : "current",
...
}
]
}

次のサンプルは、demoアプリケーションのリソース・カタログで定義されている、使用可能なすべてのリリース名バージョン識別子を取得します。このサンプルでは、3つのバージョン識別子が11.0、11.1および11.2で、11.2が現在の(最新の)バージョンです。タイプpredecessor-versionとsuccessor-versionのリンクは、各バージョンの位置をバージョンのリストにおけるそれぞれの相対位置で指定することに注意してください。

リクエスト

- URL
http://server/demo/rest

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.description+json

- ペイロード

{
"items" : [
{
"version" : "11.2",
"isLatest" : true,
"links" : [
{
"rel" : "self",
"href" : "http://server/demo/rest/11.2",
"name" : "self",
"kind" : "item"
},
{
"rel" : "canonical",
"href" : "http://server/demo/rest/11.2",
"name" : "canonical",
"kind" : "item"
},
{
"rel" : "predecessor-version",
"href" : "http://server/demo/rest/11.1",
"name" : "predecessor-version",
"kind" : "item"
},
{
"rel" : "describe",
"href" : "http://server/demo/rest/11.2/describe",
"name" : "describe",
"kind" : "describe"
}
]
},
{
"version" : "11.1",
"links" : [
{
"rel" : "self",
"href" : "http://server/demo/rest/11.1",
"name" : "self",
"kind" : "item"
},
{
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1",
"name" : "canonical",
"kind" : "item"
},
{
"rel" : "predecessor-version",
"href" : "http://server/demo/rest/11.0",
"name" : "predecessor-version",
"kind" : "item"
},
{
"rel" : "successor-version",
"href" : "http://server/demo/rest/11.2",
"name" : "successor-version",
"kind" : "item"
},
{
"rel" : "describe",
"href" : "http://server/demo/rest/11.1/describe",
"name" : "describe",
"kind" : "describe"
}
]
},
{
"version" : "11.0",
"links" : [
{
"rel" : "self",
"href" : "http://server/demo/rest/11.0",
"name" : "self",
"kind" : "item"
},
{
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0",
"name" : "canonical",
"kind" : "item"
},
{
"rel" : "successor-version",
"href" : "http://server/demo/rest/11.1",
"name" : "successor-version",
"kind" : "item"
},
{
"rel" : "describe",
"href" : "http://server/demo/rest/11.0/describe",
"name" : "describe",
"kind" : "describe"
}
]
}
],
"links" : [
{
"rel" : "self",
"href" : "http://server/demo/rest",
"name" : "self",
"kind" : "collection"
},
{
"rel" : "canonical",
"href" : "http://server/demo/rest",
"name" : "canonical",
"kind" : "collection"
},
{
"rel" : "current",
"href" : "http://server/demo/rest/11.2",
"name" : "current",
"kind" : "item"
}
]
}

22.4.2 特定バージョンのリソースの取得

ADF RESTランタイムでは、GETメソッドを使用した、特定バージョンのリソースの取得をサポートしています。特定のリソース・バージョンとは、設計時にリソースに関連付けられたバージョンです。リリース・バージョン識別子は、adf-config.xmlの概要エディタの「リリース・バージョン」ページで定義されています。

次のサンプルは、2つのバージョンのDepartmentsリソースを記述します。最初のリソースの記述(リクエスト1)はバージョン11.0を返し、2番目の記述(リクエスト2)はバージョン11.1を返します。11.1のリソースの記述は、追加の必須属性HireDateとPhoneNumberがリソースで定義されていることを示しています。

リクエスト・バージョン1

- URL 1
http://server/demo/rest/11.0/Departments

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.describe+json

- ペイロード 1

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10,
"controlType" : "choice",
"maxLength" : "10",
}, {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 4
}, {
"name" : "Salary",
"type" : "number",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 8,
"scale" : 2
}, {
"name" : "Picture",
"type" : "attachment",
"updatable" : true,
"mandatory" : false,
"queryable" : false,
"actions" : [ {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "image/png" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "get",
"method" : "GET",
"responseType" : [ "image/png" ]
} ]
} ],
"collection" : {
...
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
...
} ]
},
"item" : {
"links" : [ {
...
} ],
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
}
}

リクエスト・バージョン2

- URL 2
http://server/demo/rest/11.1/Departments

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.describe+json

- ペイロード 2

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"title" : "Employees All Attributes",
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10
}, {
"name" : "DepartmentId",
"type" : "integer",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 4
}, {
"name" : "Salary",
"type" : "number",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 8,
"scale" : 2
}, {
"name" : "Picture",
"type" : "attachment",
"updatable" : true,
"mandatory" : false,
"queryable" : false,
"actions" : [ {
"name" : "replace",
"method" : "PUT",
"requestType" : [ "image/png" ]
}, {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "get",
"method" : "GET",
"responseType" : [ "image/png" ]
} ]
}, {
"name" : "HireDate",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true
}, {
"name" : "PhoneNumber",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
} ],
"collection" : {
...
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees",
"name" : "self",
"kind" : "collection"
} ],
"actions" : [ {
...
} ]
},
"item" : {
"links" : [ {
...
} ]
},
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/describe",
"name" : "self",
"kind" : "describe"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/describe",
"name" : "canonical",
"kind" : "describe"
} ]
}
}
}

22.5 ADF RESTリソースの取得

ADF RESTランタイムでは、次のGETメソッドのユースケースをサポートしています。

- リソース・コレクションのフェッチ。

- ページ・リソース・コレクションのフェッチ。

- 主キー・ファインダ・パラメータを使用したリソース・ペイロードのフィルタ処理。

- 問合せパラメータを使用したリソース・ペイロードのフィルタ処理。

- リソース・アイテムのフェッチ。

- ネストされた子リソースのフェッチ。

- ソートされたリソース・コレクションのフェッチ。

22.5.1 リソース・コレクションのフェッチ

ADF RESTランタイムでは、GETメソッドを使用したリソース・コレクションのフェッチをサポートしています。

次のサンプルは、バージョン11.0のDepartmentsリソース・コレクションおよび5つのアイテムをフェッチします。

リクエスト

- URL
http://server/sample/rest/11.0/Departments

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourcecollection+json

- ペイロード

{
"items" : [ {
"DepartmentId" : 10,
"DepartmentName" : "Administration",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 20,
"DepartmentName" : "Marketing",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/20/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 30,
"DepartmentName" : "Purchasing",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/30",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/30",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/30/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 40,
"DepartmentName" : "Human Resources",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/40",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/40",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/40/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 50,
"DepartmentName" : "Shipping",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
} ],
"count" : 5,
"hasMore" : true,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
} ]
}

22.5.2 リソース・コレクションのページング

ADF RESTランタイムでは、GETメソッドを使用した、行セット・ページ区切りによるリソース・コレクションの取得をサポートしています。GETメソッドを使用したリソース・コレクションのページングは、次のURI問合せパラメータを使用して実行されます。

- limitは、リソース・コレクション内で返されるリソースの数を制限します。limitがリソース数より大きい場合、フレームワークは使用可能なすべてのリソースを返します。値は、返されるリソースの最大数です。

- offsetは、ゼロを基準とする索引(0が最初の位置)をコレクションに定義します。索引により、リソース・コレクションの開始位置が識別されます。offsetがリソース数より大きい場合、リソースは返されません。

(Departmentsリソース・コレクションに5つのアイテムがある)次のサンプルは、最初のリクエスト(URL1)が2つのアイテム(索引0と1)を取得し、offsetが省略されているため、レスポンスの開始位置は最初のアイテムになります。別のリソース・アイテム・セットを表示するために、2番目のリクエスト(URL2)では、3番目のアイテムに対応するように2のoffsetが使用され、2つのアイテム(索引2と3)のみを追加で取得するために2のlimitを使用して作成されており、最後のリクエスト(URL3)では、5つのリソース・コレクション・アイテムの最後のアイテム(索引4)を返すために4のoffsetが使用されています。

新しいリソース・アイテム・セットが取得されるたびに、レスポンスのhasMore属性は追加のアイテムがコレクションから返される可能性があるかどうかを示します。この例では、コレクションに含まれるアイテムは5つのみであるため、URL3のレスポンスではhasMoreがfalseに設定され、アイテムの最後のセットが取得済であることを示します。

limitパラメータがページングURLで省略された場合、ADF RESTランタイムでは、limitが(リソースのイテレータ・バインディング定義でデフォルトのRangeSize値として決められている) 25であると想定されることに注意してください。この場合、最大25のアイテムが各リクエストで返されます。このため、コレクションをページングする場合は、常にlimit問合せパラメータを含めて、必要な数のリソース・アイテムのみが返されるようにし、それ以上返されないようにするのがベスト・プラクティスです。

リクエスト

- URL 1
http://server/demo/rest/11.0/Departments?limit=2

- URL 2
http://server/demo/rest/11.0/Departments?offset=2&limit=2

- URL 3
http://server/demo/rest/11.0/Departments?offset=4&limit=2

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourcecollection+json

- ペイロード 1

{
"items" : [ {
"DepartmentId" : 10,
"DepartmentName" : "Administration",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 20,
"DepartmentName" : "Marketing",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/20/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
} ],
"count" : 2,
"hasMore" : true,
"limit" : 2,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
} ]
}

- ペイロード 2

{
"items" : [ {
"DepartmentId" : 30,
"DepartmentName" : "Purchasing",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/30",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/30",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/30/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 40,
"DepartmentName" : "Human Resources",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/40",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/40",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/40/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
} ],
"count" : 2,
"hasMore" : true,
"limit" : 2,
"offset" : 2,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
} ]
}

- ペイロード 3

{
"items" : [ {
"DepartmentId" : 50,
"DepartmentName" : "Shipping",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
} ],
"count" : 1
"hasMore" : false,
"limit" : 25
"offset" : 4,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
} ]
}

22.5.3 主キー値によるリソース・コレクションのフィルタ処理

ADF RESTランタイムでは、GETメソッドおよび(リソースの1つ以上の主キー属性で定義されるファインダを含む)固定URLを使用したリソース・コレクションのフェッチをサポートしています。リソースの基礎となる各ビュー・オブジェクトは、少なくとも1つの主キー属性を定義します。ADF RESTランタイムでは、ファインダ問合せ文字列の主キー値を渡してコレクションをフィルタ処理することをサポートしています。

主キー(PK)によるフィルタ処理は、1つ以上の主キー値を指定するファインダ問合せ文字列を使用して実行されます。主キー問合せ文字列パラメータを含むファインダの形式は、次のとおりです。

finder=PrimaryKey;<PKattr1>=<PKvalue1>,<PKattr2>=<PKvalue2>,...

たとえば、リソース・コレクションEmployeesは、主キー属性EmployeeIdを定義します。特定の従業員の主キー検索を使用してコレクションをフィルタ処理するには、検索問合せ文字列を、次の例で示すように指定します。

finder=PrimaryKey;EmployeeId=101

リソースが、複数の部分からなる主キーによって定義される場合、検索は主キー値の対応する数を渡してコレクションをフィルタ処理できます。たとえば、リソース・コレクションInventoryには、主キー属性としてProductIdおよびWarehouseIdがあります。特定のインベントリ・アイテムの主キー検索を使用してコレクションをフィルタ処理するには、検索問合せ文字列に両方の主キー値を、次の例で示すように指定します。

finder=PrimaryKey;ProductId=8568,WarehouseId=45

リソース・コレクションの記述は、ファインダおよび主キー属性を説明します。主キー・ファインダを使用する手順は次のとおりです。

1. リソースの記述を実行し、コレクション要素内のfinders属性を検索します。name属性は、ファインダをPrimaryKeyとして識別します。また、attributesの下の主キー属性の名前も検索します。

2. 問合せパラメータfinderを指定してGETを実行し、ファインダ名PrimaryKeyを使用して主キー属性を渡します。

たとえば、Employeesリソースの記述は次を返します。

"collection" : {
"rangeSize" : 24,
"finders" : [ {
"name" : "PrimaryKey",
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : false
"precision" : 4,
} ]

次のサンプルは、(EmployeeId属性値101が渡される)ファインダPrimaryKeyで指定されたEmployeesコレクションをフェッチします。

注意: 主キーではない属性でコレクションをフィルタ処理するには、「行検索によるリソース・コレクションのフィルタ処理」を参照してください。

リクエスト

- URL
http://server/demo/rest/11.1/Employees?finder=PrimaryKey;EmployeeId=101

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"items" : [ {
"EmployeeId" : 101,
"FirstName" : "Neena",
"LastName" : "Smith",
"Email" : "NSMITH",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 2000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/101",
"name" : "Employees",
"kind" : "item"
} ]
} ],
"count" : 1,
"hasMore" : false,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.5.4 問合せパラメータによるリソース・コレクションのフィルタ処理

ADF RESTランタイムでは、GETメソッドを使用した、問合せパラメータによるリソース・コレクションのフェッチをサポートしています。リソース・コレクションは、次の式を使用して問い合わせることができます。

サポートされる演算子:

- より大きい: >

- より小さい: <

- 以上: >=

- 以下: <=

- 論理積: AND

- 論理和: OR

- 等価: =

- 相似: LIKE

特殊文字:

- リテラルの定義: "および'

- エスケープ: \

- ワイルドカード: *

次のサンプルは、30未満のDepartmentId値が割り当てられた部門をフェッチします。

リクエスト

- URL
http://server/demo/rest/11.0/Departments?q=DepartmentId<30

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourcecollection+json

- ペイロード

{
"items" : [ {
"DepartmentId" : 10,
"DepartmentName" : "Administration",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 20,
"DepartmentName" : "Marketing",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/20/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
} ],
"count" : 2,
"hasMore" : false,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
} ]
}

22.5.5 リソース・アイテムのフェッチ

ADF RESTランタイムでは、GETメソッドを使用したリソース・コレクションのアイテムのフェッチをサポートしています。

次のサンプルは、バージョン11.0のDepartmentsリソース・コレクションのインスタンスのすべてのフィールドをフェッチします。

リクエスト

- URL
http://server/demo/rest/11.0/Departments/50

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"DepartmentId" : 50,
"DepartmentName" : "Shipping",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.5.6 ネストされた子リソースのフェッチ

ADF RESTランタイムでは、GETメソッドを使用した、ネストされたリソースの取得をサポートしています。

次のサンプルは、バージョン11.0のEmployeesリソースをDepartmentsリソースの子として返します。最初のリクエスト・サンプル(URL 1)は、従業員120で識別される単一の子リソース・アイテムを取得します。URLパラメータchildは、リクエストされたリソースEmployeesの関係を識別します。

2番目のリクエスト(URL 2)では、問合せパラメータexpandを使用して、Departmentsリソース・コレクション50でネストされているすべてのEmployeesリソース・アイテムが確実に返されるようにしています。

3番目のリクエスト(URL 3)はアクセッサ・ドット表記法の使用(例: Employees.JobHistory)を示しています。問合せパラメータexpandも併用しているため、Departmentsリソース・コレクション80で、ネストされているすべてのJobHistoryリソースがEmployeesリソース・アイテムとともに返されます。

ネストされたリソースの識別に使用される名前は、リソースがADFビジネス・コンポーネント・モデル・プロジェクトで作成される場合、設計時に決定されることに注意してください。モデル・プロジェクトで作成されるネストされたリソースのデフォルト名は、ネストされたリソースのビュー・リンク・アクセッサ定義の宛先ビュー・インスタンスです(ビュー・リンクDeptToEmpFkLinkのEmployeesView1など)。このため、ADF RESTリソース開発者にとって、リソース名をURLパラメータとしてより適切な名前に変更することがベスト・プラクティスです。この例では、リソース名は、親リソース名Departmentsの命名規則に従ってEmployeesに変更されています。

リクエスト

- URL 1
http://server/demo/rest/11.0/Departments/50/child/Employees/120

- URL 2
http://server/demo/rest/11.0/Departments/50?expand=Employees

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード 1

{
"EmployeeId" : 120,
"FirstName" : "Matthew",
"LastName" : "Weiss",
"Email" : "MWEISS",
"JobId" : "ST_MAN",
"DepartmentId" : 50,
"Salary" : 8000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees/120",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees/120",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
} ]
}

- ペイロード 2

{
"DepartmentId" : 50,
"DepartmentName" : "Shipping",
"Employees" : [ {
"EmployeeId" : 120,
"FirstName" : "Matthew",
"LastName" : "Weiss",
"Email" : "MWEISS",
"JobId" : "ST_MAN",
"DepartmentId" : 50,
"Salary" : 8000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees/120",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees/120",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
} ]
}, {
"EmployeeId" : 121,
"FirstName" : "Adam",
"LastName" : "Fripp",
"Email" : "AFRIPP",
"JobId" : "ST_MAN",
"DepartmentId" : 50,
"Salary" : 8200,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees/121",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees/121",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
} ]
}, {
...
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
} ]
}

- URL 3
http://server/demo/rest/11.0/Departments/80?expand=Employees.JobHistory&onlyData=true

- ペイロード 3

{
"DepartmentId" : 80,
"DepartmentName" : "Sales",
"RelState" : null,
"Employees" : [
...
{
"EmployeeId" : 176,
"FirstName" : "Jonathon",
"LastName" : "Taylor",
"Email" : "JTAYLOR",
"JobId" : "SA_REP",
"DepartmentId" : 80,
"Salary" : 8600,
"CommissionPct" : 0.2,
"JobHistory" : [
{
"EmployeeId" : 176,
"StartDate" : "2011-03-24",
"EndDate" : "2012-12-31",
"JobId" : "SA_REP",
"DepartmentId" : 80
},
{
"EmployeeId" : 176,
"StartDate" : "2013-01-01",
"EndDate" : "2015-03-31",
"JobId" : "SA_MAN",
"DepartmentId" : 80
}
]
},
...
]
}

22.5.7 リソース・コレクションのソート

ADF RESTランタイムでは、GETメソッドを使用した、フェッチ済リソース・コレクションのソートをサポートしています。

リソース・コレクションのソートは、orderBy問合せ文字列パラメータを1つ以上の属性名と組み合せて使用して実行されます。次のオプションのソート順序フラグを各属性に関連付けることができます。

- ascは昇順でソートします。(デフォルト)

- descは降順でソートします。

orderBy問合せ文字列パラメータの形式は次のとおりです。

<orderBy_attribute1_name>:<(asc/desc)>, <orderBy_attribute2_name>:<(asc/desc)>

例: attribute1:asc,attribute2

次のサンプル(URL1)は、DepartmentName属性でソートされたDepartmentsコレクションをフェッチします。2番目のサンプル(URL2)は、salary属性でソートされた子Employeesコレクションをフェッチします。いずれのリクエスト・サンプルにもソート順序フラグが指定されていないため、レスポンスは昇順になります。

リクエスト

- URL 1
http://server/demo/rest/11.0/Departments?orderBy=DepartmentName

- URL 2
http://server/demo/rest/11.0/Departments/50/child/Employees?orderBy=Salary

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード 1

{
"items" : [ {
"DepartmentId" : 10,
"DepartmentName" : "Administration",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 40,
"DepartmentName" : "Human Resources",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/40",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/40",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/40/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 20,
"DepartmentName" : "Marketing",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/20/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 30,
"DepartmentName" : "Purchasing",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/30",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/30",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/30/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
"DepartmentId" : 50,
"DepartmentName" : "Shipping",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/50",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/50/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
} ],
"count" : 5,
"hasMore" : false,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
} ]
}

- ペイロード 2

{
"items" : [ {
"EmployeeId" : 132,
"FirstName" : "TJ",
"LastName" : "Olson",
"Email" : "TJOLSON",
"JobId" : "ST_CLERK",
"DepartmentId" : 50,
"Salary" : 2100,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/132",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/132",
"name" : "Employees",
"kind" : "item"
} ]
}, {
"EmployeeId" : 136,
"FirstName" : "Hazel",
"LastName" : "Philtanker",
"Email" : "HPHILTAN",
"JobId" : "ST_CLERK",
"DepartmentId" : 50,
"Salary" : 3100,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/136",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/136",
"name" : "Employees",
"kind" : "item"
} ]
} ],
"count" : 2,
"hasMore" : false,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.6 リソース・アイテムの作成

ADF RESTランライムでは、次の作成ユースケースをサポートしています。

- コレクションでのリソース・アイテムの作成。

- 子リソース・アイテムの作成。

22.6.1 コレクションでのリソース・アイテムの作成

ADF RESTランタイムでは、POSTメソッドを使用した、既存のリソース・コレクションでのリソース・アイテムの作成をサポートしています。

POSTメソッドでリクエストを行う前に、リソース・アイテムがLOV有効属性で定義されているかどうかを確認します。LOV有効属性が存在し、その属性が必須として定義されている場合は、まずリソース・コレクション上のLOVリソースにアクセスして、エンド・ユーザーに選択リストが表示されるようにする必要があります。LOVリソースのアクセス方法の詳細は、「リソース・アイテム作成時のLOV有効属性値の取得」を参照してください。

次のサンプルは、単一のアイテムを含む新しいDepartmentsリソース・コレクションを作成します。

リクエスト

- URL
http://server/demo/rest/11.0/Departments

- HTTPメソッド
POST

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"DepartmentId" : 15,
"DepartmentName" : "NewDept"
}

レスポンス

- HTTPコード
201

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- 場所
http://server/demo/rest/Departments/15

- ペイロード

{
"DepartmentId" : 15,
"DepartmentName" : "NewDept",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/15",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/15",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/15/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.6.2 子リソース・アイテムの作成

ADF RESTランタイムでは、POSTメソッドを使用した、1つのラウンドトリップでのADF REST子リソース・アイテムの作成をサポートしています。作成は、親と子が両方とも存在しない場合にのみ成功します。

次のサンプルは、ネストされたリソース・アイテムを作成します。最初のリクエスト・サンプル(URL1)は、既存のDepartmentsリソース内に従業員999で識別される子リソース・アイテムを作成します。2番目のリクエスト(URL2)は、親リソースと子リソースを作成します。

リクエスト

- URL 1
http://server/demo/rest/11.0/Departments/15/child/Employees

- URL 2
http://server/demo/rest/11.0/Departments

- HTTPメソッド
POST

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード 1

{
"EmployeeId": 999,
"FirstName": "New",
"LastName": "Guy",
"Email": "NGUY",
"JobId": "SA_REP",
"DepartmentId": 15,
"Salary": 9999
}

- ペイロード 2

{
"DepartmentId": 17,
"DepartmentName": "NewerDept",
"Employees": [
{
"EmployeeId": 99999,
"FirstName": "Newer",
"LastName": "Guy",
"Email": "NRGUY",
"JobId": "SA_MAN",
"DepartmentId": 17,
"Salary": 10001
}
]
}

レスポンス

- HTTPコード
201

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- 場所
http://server/demo/rest/11.0/Departments/15/child/Employees/999

- ペイロード 1

{
"EmployeeId" : 999,
"FirstName" : "New",
"LastName" : "Guy",
"Email" : "NGUY",
"JobId" : "SA_REP",
"DepartmentId" : 15,
"Salary" : 9999,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/15/child/Employees/999",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/15/child/Employees/999",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/15",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.0/Departments/15/child/Employees/999/lov/JobsView1",
"name" : "JobsView1",
"kind" : "collection"
} ]
}

- 場所
http://server/demo/rest/11.0/Departments/17/child/Employees/99999

- ペイロード 2

{
"DepartmentId" : 17,
"DepartmentName" : "NewerDept",
"Employees" : [ {
"EmployeeId" : 99999,
"FirstName" : "Newer",
"LastName" : "Guy",
"Email" : "NRGUY",
"JobId" : "SA_MAN",
"DepartmentId" : 17,
"Salary" : 10001,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/17/child/Employees/99999",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/17/child/Employees/99999",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "parent",
"href" : "http://server/demo/rest/11.0/Departments/17",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.0/Departments/17/child/Employees/99999/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
} ],
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/17",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/17",
"name" : "Departments",
"kind" : "item"
} ]
}

22.7 リソース・アイテムの更新

ADF RESTランタイムでは、PATCHメソッドを使用したリソース・アイテムの更新をサポートしています。更新は、行がすでに存在している場合にのみ成功します。

次のサンプルは、(DepartmentNameがリクエスト・ペイロードで変更された) Departmentsアイテム15を更新します。

リクエスト

- URL
http://server/demo/rest/11.0/Departments/15

- HTTPメソッド
PATCH

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"DepartmentId" : 15,
"DepartmentName" : "UpdatedDeptName"
}

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"DepartmentId" : 15,
"DepartmentName" : "UpdatedDeptName",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/15",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/15",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/15/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.8 リソース・アイテムの削除

ADF RESTランタイムでは、DELETEメソッドを使用したリソース・アイテムの削除をサポートしています。フレームワークでは、リソース・コレクションの削除は現在サポートされていません。

次のサンプル(URL1)は、Employeesリソース・コレクションの従業員ID 99999をDepartmentsリソース・アイテム17の子として削除します。2番目のリクエストURLは、Departmentsリソース・アイテム17を削除します。

リクエスト

- URL 1
http://server/demo/rest/11.0/Departments/17/child/Employees/99999

- URL 2
http://server/demo/rest/11.0/Departments/17

- HTTPメソッド
DELETE

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
204

- コンテンツ・タイプ
なし

- ペイロード
なし

22.9 データ整合性のチェック

ADF RESTランタイムでは、リクエストされたリソースでデータ整合性チェックが有効な場合、レスポンス・ヘッダーへのエンティティ・タグ(ETag)の生成をサポートしています。データ整合性チェックは、リソースの基礎となるエンティティ・オブジェクトで更新識別子属性を構成する必要があるADFビジネス・コンポーネント開発者によって有効化されます。

リソースの基礎となるエンティティ・オブジェクトでエンティティ更新識別子が構成されている場合、ADF RESTランタイムは、サーバー側の各リソースの状態を示す一意の値を割り当てます。実行時に、サーバー側リソースの基礎となっている行が変更されると、Oracle ADFは新しい状態値をETagに割り当てます。次のヘッダーは、Departmentsリソース・アイテムを取得するリクエストで返されるETagを示しています。

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Location:
Content-Length: 1069
Content-Type: application/json
ETag: "ACED00057372037200136261636C6520136261636C65237200136261636C652"
Content-Encoding:
Link: <http://server/demo/rest/11.0/Departments/10>;rel="self";kind="item";name="Departments"

注意:

ETagおよびデータ整合性チェックは、RESTリソースで自動的に有効化されないことに注意してください。ETag値の生成をサポートするために、ADFビジネス・コンポーネント開発者は、チェックされるリソースの基礎となるエンティティ・オブジェクトで更新識別子有効属性を構成する必要があります。エンティティ・オブジェクトでの更新識別子属性の構成の詳細は、「同時更新によるデータの消失を防ぐ方法」を参照してください。

サービス・クライアントは、各リソース・アイテムのレスポンス・ヘッダーで返されたETag値を使用して、事前条件ヘッダー(If-Match/If-None-Match)を含む後続のリクエストを実行できます。指定されたETagおよび事前条件に基づいて、サーバーは現在のリソース状態を評価し、指定されたETagと照合します。事前条件が満たされている場合はリクエストされた操作が実行され、満たされていない場合は412エラーが返されます。エラー・ペイロードにはサーバー側の現在のリソースが含まれ、ヘッダーでは現在のETag値も反映されます。

ETag値のテストをサポートするために、ADF RESTフレームワークでは、次の事前条件ヘッダー・フィールドが提供されています。これらの事前条件フィールドを使用すると、フレームワークは、指定されたETag値を、前にリクエストされたアイテムのETag値と比較します。

- クライアントが(前のリソース・アイテム・レスポンスから取得して)提供している状態が、サーバーの現在の状態に一致することを検証します。

If-Match: "<ETag value from resource item response>"

- クライアントが(前のリソース・アイテム・レスポンスから取得して)提供している状態が、サーバーの現在の状態に一致しないことを検証します。

If-None-Match: "<ETag value from resource item response>"

次に、データ整合性をチェックする場合の一般的なユースケースを示します。

- リソース・アイテムが、更新前のサーバー側リソース状態に一致することを確認します。

- リクエストされたいずれのアイテムも前にリクエストされたアイテムに一致しない場合、サーバー側リソース状態を使用してリソース・アイテムを取得します

これらのユースケースにGETメソッドとPATCHメソッドが関連する場合は、事前条件ヘッダーとETag値を使用して、HTTPメソッド操作がリソースの現在の状態に適用されることを確認できます。

リソース・コレクションを取得すると、追加のカスタム・プロパティchangeIndicatorが、データ整合性が有効なリソースのレスポンス・ペイロードに出現します。このプロパティには、リクエストされたコレクション内の各リソース・アイテムの現在のETag値が含まれます。次のサンプルは、Departmentsリソース・コレクションのlinksセクション内のchangeIndicatorプロパティを示しています。リソース・コレクション・ペイロードにETag値が存在すると、サーバー・クライアントは個別のリソース・アイテムからETagを取得するためのリクエストの数を減らすことができるため、サーバー・クライアントにとって便利です。

レスポンス内にRelState属性が存在することにも注意してください。これは、ADFビジネス・コンポーネント開発者がデータ整合性チェックをサポートするためにエンティティ・オブジェクトで構成した更新識別子属性の名前です。この属性の値は、状態が更新された回数を反映します。

{
"items" : [ {
"DepartmentId" : 10,
"DepartmentName" : "Administration",
"RelState" : 1,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item",
"properties" : {
"changeIndicator" : "ACED0005737200136A6176612E7574696C2E41727261794C69737
47881D21D99C7619D03000149000473697A65787000000001770400000001737200186F721
636C652E6A626F2E646F6D61696E2E4E7564A362286F0200015B0004646174617400025B45
27870757200025B42ACF317F8060854E00200007870"
}
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item",
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item",
"properties" : {
"changeIndicator" : "ACED0005737200136A6176612E7574696C2E149000473697A6578
70000000017704000000017372001B6F7261636C652E6A626F2E646F60000C78"
}
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection",
} ]
}, {
"DepartmentId" : 20,
"DepartmentName" : "Marketing",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item",
"properties" : {
"changeIndicator" : "ACED0005737200136A6176612E7574696C2E41727261794C6973747881D21D99C7619D03000149000473697A65787000000001770400000001737200186F7261636C652E6A626F2E646F6D61696E2E4E756D626572A5B1371914E0BFDA0200014900096D48617368436F6465787200116F7261636C652E73716C2E4E554D424552E90466EE632BE1D5020000787200106F7261636C652E73716C2E446174756D4078F514A362286F0200015B0004646174617400025B427870757200025B42ACF317F8060854E0020000787000000002C10A0000000078"
}
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/20",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/20/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}, {
...
} ]
} ],
"count" : 5,
"hasMore" : true,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
} ]
}

22.9.1 ADF RESTリソース・アイテムの更新時のデータ整合性のチェック

ADF RESTランタイムでは、更新識別子属性が有効になっているADFビジネス・コンポーネント・エンティティ・オブジェクトが基礎となっているリソース・アイテムを、PATCHメソッドを使用して更新する際のデータ整合性チェックをサポートしています。

ETagヘッダーおよび条件付きヘッダー・フィールドを使用してデータ整合性をチェックする手順は次のとおりです。

1. 次に示すように、リソース・アイテムのGETリクエストのヘッダーからETag値を取得します。

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Location:
Content-Length: 861
Content-Type: application/json
ETag: "responseETag123"
Content-Encoding:
Link: <http://server/demo/rest/11.0/Departments/10>;rel="self";kind="item";name="Departments"
Set-Cookie: JSESSIONID=jXvsJ1GpdkFJV5Jh0yk7D72vPZ42t8tLYDg74NRKFQzXdnsjG9vv!1113104013; path=/; HttpOnly
X-ORACLE-DMS-ECID: 51f1ff4535af720c:-7e156247:148ec9eeb3b:-8000-00000000000001ad
X-Powered-By: Servlet/2.5 JSP/2.1

{
"DepartmentId" : 10,
"DepartmentName" : "Administration",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item",
"properties" : {
"changeIndicator" : "responseETag123"
}
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

2. リソース・アイテムのPATCHリクエストを実行し、次の条件付きヘッダー・フィールドを指定してデータ整合性をチェックします。

- If-Match: "<ETag value from resource item response>" (リクエストされたリソース・アイテムの状態が、前のリソース・アイテム・レスポンスの最新状態であることを検証します)。

次のサンプルは、If-Match事前条件テストが満たされた場合、Departments 10リソース・アイテムのDepartmentNameフィールドを更新します。最初のリクエスト(リクエスト1)で、ETag値responseETag123は、サーバー側の現在のDepartments 10リソース・アイテムのETagと同一であり、リソース・アイテムの状態がサーバー側と一致していることを示します。この結果、DepartmentNameに対する更新が許可されます。

ただし、後続のリクエスト(リクエスト2)では、If-Match事前条件で指定されたETagは変更されておらず、サーバー側のDepartments 10リソース・アイテムの新しいETag値と一致しなくなります。古いETag値が2番目のリクエストで使用された結果として、更新は(事前条件テストに失敗したことを示す) HTTPコード412で失敗し、現在のETag値responseETag567がレスポンス・ヘッダーで返されます。

リクエスト1

- URL 1
http://server/demo/rest/11.0/Departments/10

- HTTPメソッド
PATCH

- 事前条件1
If-Match: "responseETag123"

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード 1

{
"DepartmentName" : "FirstAttempt_NewDepartmentName"
}

レスポンス1

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ETag
responseETag567

- ペイロード 1

{
"DepartmentId" : 10,
"DepartmentName" : "FirstAttempt_NewDepartmentName",
"RelState" : null,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item",
"properties" : {
"changeIndicator" : "responseETag567"
}
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

リクエスト2

- URL 2
http://server/demo/rest/11.0/Departments/10

- HTTPメソッド
PATCH

- 事前条件2
If-Match: "staleETag789"

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード 2

{
"DepartmentName" : "SecondAttempt_NewDepartmentName"
}

レスポンス2

- HTTPコード
412 (事前条件が失敗しました)

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ETag
responseETag567

- ペイロード 2

{
"DepartmentId" : 10,
"DepartmentName" : "FirstAttempt_NewDepartmentName",
"RelState" : null,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item",
"properties" : {
"changeIndicator" : "responseETag567"
}
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.9.2 ADF RESTリソース・アイテムの取得時のデータ整合性のチェック

ADF RESTランタイムでは、更新識別子属性が有効なADFビジネス・コンポーネント・エンティティ・オブジェクトが基礎となっているリソース・アイテムを、GETメソッドを使用して取得する際のデータ整合性チェックをサポートしています。

ETagヘッダーおよび条件付きヘッダー・フィールドを使用してデータ整合性をチェックする手順は次のとおりです。

1. 次に示すように、リソース・アイテムのGETリクエストのヘッダーからETag値を取得します。

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Location:
Content-Length: 861
Content-Type: application/json
ETag: "responseETag123"
Content-Encoding:
Link: <http://server/demo/rest/11.0/Departments/10>;rel="self";kind="item";name="Departments"
Set-Cookie: JSESSIONID=jXvsJ1GpdkFJV5Jh0yk7D72vPZ42t8tLYDg74NRKFQzXdnsjG9vv!1113104013; path=/; HttpOnly
X-ORACLE-DMS-ECID: 51f1ff4535af720c:-7e156247:148ec9eeb3b:-8000-00000000000001ad
X-Powered-By: Servlet/2.5 JSP/2.1

{
"DepartmentId" : 10,
"DepartmentName" : "Administration",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item",
"properties" : {
"changeIndicator" : "ACED0005737200136A6176612E7574696C2E4"
}
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

2. リソース・アイテムのGETリクエストを実行し、次の条件付きヘッダー・フィールドを指定してデータ整合性をチェックします。

- If-None-Match: "<ETag value from resource item response>" (前にリクエストされたいずれのリソース・アイテムの状態も、リソース・アイテム・リクエストの最新状態でないことを検証します)。

次のサンプルは、If-None-Match事前条件が満たされた場合、Departments 10リソース・アイテムを取得します。最初のリクエスト(リクエスト1)で、ETag値responseETag123は、サーバー側の前にリクエストされたDepartments 10リソース・アイテムのETagと一致し、リソース・アイテムの状態がサーバー側と一貫性があることを示します。結果として、事前条件は失敗し、新しいDepartments 10リソース・アイテムを返す必要はありません。リクエストは、サーバーの状態が変更されていないことを示すHTTPコード304を返します。

ただし、後続のリクエスト(リクエスト2)では、If-None-Match事前条件で指定されたETag unmatchedETagXYZはサーバーに存在しません。結果として、事前条件が成功し、Departments 10リソース・アイテムが取得されます。リクエストは、条件が変更されたことを示すHTTPコード200を返し、現在の(変更されていない) ETag値responseETag123がレスポンス・ヘッダーで返されます。

リクエスト1

- URL 1
http://server/demo/rest/11.0/Departments/10

- HTTPメソッド
GET

- 事前条件1
If-None-Match: "responseETag123"

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス1

- HTTPコード
304 (状態は変更されていません)

- コンテンツ・タイプ
なし

- ペイロード 1
なし

リクエスト2

- URL 2
http://server/demo/rest/11.0/Departments/10

- HTTPメソッド
GET

- 事前条件2
If-None-Match: "unmatchedETagXYZ"

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス2

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ETag
responseETag123

- ペイロード 2

{
"DepartmentId" : 10,
"DepartmentName" : "Administration",
"RelState" : null,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item",
"properties" : {
"changeIndicator" : "responseETag123"
}
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Departments/10",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.0/Departments/10/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.10 添付ファイルの使用

ADF RESTランタイムでは、BLOB属性またはCLOB属性のコンテンツ・ストリーミングをサポートしています。

LOB属性は、次の方法で処理されます。

- ペイロード自体には含まれていないカスタム・コンテンツとしてリンクされます。
これは、BLOB属性とCLOB属性のデフォルト設定であり、サポートされているペイロード・タイプ(image/pngなど)で表すことができないリソースを指すenclosureリンク・タイプを使用してレスポンス・ペイロードで指定されます。

- Base64文字列形式にエンコードされ、リクエスト・ペイロード自体に含められます。

現在、高度な機能(チャンク・エンコードのサポートなど)は、ADF RESTランタイムでサポートされていません。エンタープライズ・アーキテクチャで作業している開発者は、特殊なコンテンツ管理システム(Oracle WebCenter Contentなど)の使用を調査する場合があります。

attributeセクションでLOB属性を示すかわりに、レスポンス・ペイロードにはコンテンツへのenclosureリンクが常に含まれます。Employeesリソース・アイテムの次の記述では、application/octet-streamのデフォルトのrequestTypeを使用してBLOB属性Pictureを定義します。リソース・アイテムのenclosureリンクがitemsセクションに表示されます。actionsセクションでは、コンテンツの操作に使用できる操作を識別します。

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
...
}, {
"name" : "Picture",
"type" : "attachment",
"updatable" : true,
"mandatory" : false,
"queryable" : false,
"actions" : [ {
"name" : "delete",
"method" : "DELETE"
}, {
"name" : "get",
"method" : "GET",
"responseType" : [ "application/octet-stream" ]
} ]
} ],
"item" : {
"links" : [ {
...
}, {
"rel" : "enclosure",
"href" : "http://server/demo/rest/11.0/Employees/101/enclosure/Picture",
"name" : "Picture",
"kind" : "other"
} ],
"actions" : [ {
} ]
},
"links" : [ {
...
} ]
}
}

リソース・アイテムの属性コンテンツ・タイプは、ADF RESTリソース開発者がcontentTypeプロパティをLOBタイプ属性のカスタム・プロパティとして構成することで割り当てることができます。たとえば、PNGイメージ・ファイルを使用する場合、コンテンツ・タイプを前もって割り当てることができます。

- カスタム・プロパティ: contentType

- 値: image/png

一部のユースケースでは、この属性自体がなんらかの外部コンテンツへのリンクとなります。属性がこの方法で構成されている場合、リソース・アイテム・ペイロードに表示されるだけでなく、外部コンテンツを指すリンクも作成されます。リソースの説明では、GETアクションのみを外部リンクに使用できます。属性値に含まれるURLを変更するには、リソース・アイテムでの更新のリクエストを実行します。

ADF RESTリソース開発者は、次の属性を追加して、リンクを生成するように属性を構成できます。

- 名前: inputHandler

- 値: oracle.adf.internal.model.rest.core.binding.inputHandler.LinkInputHandler

22.10.1 リソース・アイテムのエンクロージャ・リンクを使用した添付ファイルのストリーミング

ADF RESTランタイムでは、リソース・アイテムのペイロードに含めることができないストリーミング・コンテンツを、そのコンテンツへのリンクを使用することでサポートしています。リンクされたコンテンツに対してサポートされているメソッドはGETとDELETEです。リソース・アイテムを(POSTメソッドを使用して)作成すると同時にLOBコンテンツを作成する場合、コンテンツをbase64としてエンコードする必要があることに注意してください。base64を使用してコンテンツを埋め込む方法のサンプルは、「Base64を使用したLOBコンテンツの置換」を参照してください。

リンクからコンテンツをストリーミングする手順は次のとおりです。

1. リソース・アイテムを取得し、目的の属性のenclosureリンクを検索します。itemセクションで、使用可能な属性のリンクを定義します。
または、リソースの説明を実行して、リソース・アイテムで生成されたエンクロージャ・リンクを識別できます。一般に、リソースの説明には、GETリソース・ペイロードでは返されないその他の有用な情報(image/pngなどの予期されるレスポンス・タイプなど)、およびサポートされる属性のアクションが含まれています。

2. LOBコンテンツへのリンクを使用して、HTTP操作(GETまたはDELETE)を実行します。

Employees 101の次のリソース・アイテムは、linksセクション内のPicture属性のenclosureリンクを示します。

{
"EmployeeId" : 101,
"FirstName" : "Neena",
"LastName" : "Smith",
"Email" : "NSMITH",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 2000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.0/Employees/101/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
}, {
"rel" : "enclosure",
"href" : "http://server/demo/rest/11.0/Employees/101/enclosure/Picture",
"name" : "Picture",
"kind" : "other"
} ]
}

たとえば、次のサンプルは、従業員101に関連付けられているPNGイメージをストリーミングします。

様々なメディア・タイプをサポートするために、リクエスト・タイプはデフォルトでapplication/octet-streamになることに注意してください。ADF RESTリソース開発者がカスタム・プロパティcontentTypeを定義している場合は、指定されたリクエスト・タイプがリソース・アイテムの説明に表示されます。

リクエスト

- URL
http://server/demo/rest/11.0/Employees/101/enclosure/Picture

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
image/png

- ペイロード
ストリーミングされたコンテンツ

22.10.2 Base64を使用したLOBコンテンツの置換

ADF RESTランタイムでは、コンテンツがbase64文字列形式で表されている場合、JSONペイロードを使用してLOBコンテンツを作成および更新できます。

たとえば、次のサンプルは、従業員101のPNGイメージを置換します。このユースケースでは、Picture属性はbase64でエンコードされた文字列としてリクエスト・ペイロード内に表される必要があります。リソース・アイテム101はすでに存在し、Picture属性のみが操作されるため、他の属性を指定する必要はありません。

レスポンス・ペイロードには、Picture属性へのenclosureリンクが含まれることに注意してください。

リクエスト

- URL
http://server/demo/rest/11.0/Employees/101

- HTTPメソッド
PATCH

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"Picture" : "/9j/4AAQSkZJRgABAAEAYABgAAD//..."
}

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"EmployeeId" : 101,
"FirstName" : "Neena",
"LastName" : "Smith",
"Email" : "NSMITH",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 2000,
"links" : [ {
"rel" : "lov",
"href" : "http://server/demo/rest/11.0/Employees/101/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
}, {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.0/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "enclosure",
"href" : "http://server/demo/rest/11.0/Employees/101/enclosure/Picture",
"name" : "Picture",
"kind" : "other"
} ]
}

22.11 LOVの使用

ADF RESTランタイムでは、LOV有効属性の次のユース・ケースがサポートされます。

- 既存のリソース・アイテムのコンテキストでLOV属性値を取得します。
ユーザーに既存のリソース・アイテムの更新を許可する場合で、そのリソース・アイテムでLOV有効属性が定義されている場合は、このユース・ケースを参照してください。

- 既存のリソース・アイテムのコンテキストが存在しない場合に、LOV属性値を取得します。
リソース・アイテムを作成する必要がある場合で、そのリソース・アイテムでLOV有効属性が定義される場合は、このユース・ケースを参照してください。

22.11.1 既存のリソース・アイテムのLOV有効属性値の取得

ADF RESTランタイムでは、GETメソッドを使用した、既存のリソース・アイテムでのLOV有効属性値の取得をサポートしています。

LOV有効属性の既存のリソース・アイテムはLOV子リソースをネストし、この子リソースは、含まれるリソース・アイテムのコンテキストに基づいて適切な値リストを取得するために使用できます。

新しいリソース・アイテムを作成し、LOV値を取得する必要がある場合は、リソース・コレクション内にネストされていないLOVリソースにアクセスします。ネストされていないLOVリソースのアクセス方法の詳細は、「リソース・アイテム作成時のLOV有効属性値の取得」を参照してください。

既存のリソース・アイテムでLOV有効属性を使用する手順は次のとおりです。

1. リソースの記述を実行し、LOVに関する次の詳細を検索します。
リソース属性のlov記述でchildRefプロパティを検索し、LOVの選択肢を含む子リソース・コレクションを識別します。

lov記述には、リソース・アイテムからLOV子リソース・コレクションへのビュー・オブジェクト属性マッピングが含まれます。この属性マッピングには、LOV値が選択された場合に値がリソース・アイテムからコピーされる、子リソースからの1つ以上のソース属性が含まれます。LOVの選択では、LOVを表示する属性以外にリソース・アイテム内の追加の値が導出される場合があります。そのような場合、属性マッピングではderived = trueとしてそれを識別します。最後に、lov記述は、結果がユーザー・インタフェースにバインドされている場合、子リソース・コレクションのどの属性をエンド・ユーザーへの表示に使用できるかを識別します。

2. 次に、リソース・アイテムのlinks要素を検索し、lovがrelで、対応するLOV子リソース(リソース・アイテムchildRefプロパティで指定されている)を識別するhrefを検索します。
ヒント: リソースの記述は、リソース・コレクションから特定のリソース・アイテム名を指定して完了するテンプレートとしてLOV子リソースを表示します。GETを実行してリソース・コレクションを取得し、特定のリソース・アイテムに対応するLOV子リソースの作業リンクを検索できます。

3. LOVリンクを使用してGETを実行し、オプションで、追加のフィルタ処理を使用してLOV結果を絞り込むか、ペイロードから不要な属性を除外します。lov記述内にリストされている表示属性を常にフェッチする必要があります。表示属性は、エンド・ユーザーが職位のリストなどの認識できる値リストからLOV値を選択できるようにする属性値です。LOV定義により、LOVの選択が適用された場合に正しいソース属性がリソース・アイテムの更新に使用されるようになります。

たとえば、Employeesリソース・コレクションの記述は、次を返します。

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10,
"controlType" : "choice",
"maxLength" : "10",
"lov" : {
"childRef" : "JobsLOV",
"attributeMap" : [ {
"source" : "JobId",
"target" : "JobId"
} ],
"displayAttributes" : [ "JobTitle" ]
}
...

"item" : {
"links" : [ {
"rel" : "lov",
"href" :
"http://server/demo/rest/11.0/Employees/{id}/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
}, {
...

次のサンプルは、JobsLOVリソース・コレクションからLOV表示属性JobTitleの値をフェッチします。問合せパラメータonlyDataとfieldsにより、表現がフィルタ処理され、レスポンス・ペイロードにデータのみが含まれるようになります(ここで、PresidentとAdministration Assistantは表示属性JobTitleの値の例です)。

リクエスト

- URL
http://server/demo/rest/11.0/Employees/101/lov/JobsLOV?onlyData=true&fields=JobTitle

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourcecollection+json

- ペイロード

{
"items" : [ {
"JobTitle" : "President"
}, {
"JobTitle" : "Administration Assistant"
}, {
"JobTitle" : "Finance Manager"
}, {
"JobTitle" : "Accountant"
}, {
"JobTitle" : "Accounting Manager"
}, {
"JobTitle" : "Public Accountant"
} ],
"count" : 6,
"hasMore" : false,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Employees/101/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
}

22.11.2 リソース・アイテム作成時のLOV有効属性値の取得

ADF RESTランタイムでは、リソース・コレクションに存在しない新しいリソース・アイテムを作成する際の、GETメソッドを使用したLOV有効属性値の取得をサポートしています。

すでに存在するリソース・アイテムの場合は、リソース・アイテム・リンクを使用して、そのアイテムに定義されているLOV子リソースにアクセスします。LOV子リソースへのアクセスの詳細は、「既存のリソース・アイテムのLOV有効属性値の取得」を参照してください。

リソース・アイテムの作成時にLOV有効属性を使用する手順は次のとおりです。

1. リソースの記述を実行し、LOVに関する次の詳細を検索します。
属性のlov記述でlovResourcePathプロパティを検索し、LOVの選択肢を含むLOVリソースを識別します。

lov記述には、リソース・アイテムからLOVリソース・コレクションへの属性マッピングが含まれます。この属性マッピングには、LOV値が選択された場合に値がリソース・アイテムからコピーされる、LOVリソースからの1つ以上のソース属性が含まれます。LOVの選択では、LOVを表示する属性以外にリソース・アイテム内の追加の値が導出される場合があります。そのような場合、属性マッピングではderived = trueとしてそれを識別します。最後に、lov記述は、結果がユーザー・インタフェースにバインドされている場合、LOVリソース・コレクションのどの属性をエンド・ユーザーへの表示に使用できるかを識別します。

2. 次に、リソース・コレクション記述links要素を検索し、relがlovで、hrefがそのLOVリソース(lovResourcePathプロパティで指定されている)を識別するリンクを検索します。
lovResourcePathは1つ以上のLOVリソースが指定される配列です。配列では、依存LOV有効属性(カスケードLOVとも呼ばれる)のユース・ケースがサポートされます。たとえば、配列"lovResourcePath" : [ "Countries", "States" ]はCountriesとStatesというLOVリソースを指定し、州(States)を表示するLOVリストは国(Countries)のLOVの選択に依存するといったものです。依存LOV属性に表示させる値を取得するには、次のように親LOVリソース・コレクションからの子リンクを使用します。

a. LOVリソース・リンクを使用してGETを実行します(rel: lov、name: Countries)。

b. エンド・ユーザーがLOVリソース・コレクションからリソース・アイテムを選択します(たとえば、United States)。

c. 選択されたリソース・アイテム内の子リンクを使用してGETを実行します(rel: child、name: States)。これにより、親LOVリソース(国)に基づく値(州)のリストを持つリソース・コレクションを取得できます。

3. LOVリソース・リンクを使用してGETを実行し、オプションで、追加のフィルタ処理を使用してLOV結果を絞り込むか、ペイロードから不要な属性を除外します。lov記述内にリストされている表示属性を常にフェッチする必要があります。表示属性は、エンド・ユーザーが職位のリストなどの認識できる値リストからLOV値を選択できるようにする属性値です。

4. LOVリソースからキャッシュしたLOV属性値があれば、クライアント・ユーザー・インタフェースでLOV表示属性を表示して、そこでエンド・ユーザーからの値の入力を受け付け新しいリソース・アイテムを作成することも可能です。目的の値を入力するときには、LOV有効属性に対して表示されたLOVから値を選択し、「送信」をクリックします。これによりクライアントは作成リクエストを実行できます。ADFビジネス・コンポーネント・ビュー・オブジェクト属性のLOV定義により、LOVの選択が適用された場合に正しいソース属性がリソース・アイテムの更新に使用されるようになります。新しいリソース・アイテムを作成するペイロードのPOSTリクエストの送信方法の詳細は、「コレクションでのリソース・アイテムの作成」を参照してください。

たとえば、Employeesリソース・コレクションの記述は、次を返します。

{
"Resources" : {
"Employees" : {
"discrColumnType" : false,
"attributes" : [ {
"name" : "EmployeeId",
"type" : "integer",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 6
}, {
"name" : "FirstName",
"type" : "string",
"updatable" : true,
"mandatory" : false,
"queryable" : true,
"precision" : 20
}, {
"name" : "LastName",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "Email",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 25
}, {
"name" : "JobId",
"type" : "string",
"updatable" : true,
"mandatory" : true,
"queryable" : true,
"precision" : 10,
"controlType" : "choice",
"maxLength" : "10",
"lov" : {
"childRef" : "JobsLOV",
"attributeMap" : [ {
"source" : "JobId",
"target" : "JobId"
} ],
"displayAttributes" : [ "JobTitle" ],
"lovResourcePath" : [ "Jobs" ]
}
...
},
"links" : [ {
...
"rel" : "lov",
"href" : "http://server/demo/rest/11.0/Jobs",
"name" : "Jobs",
"kind" : "collection"
}, {
...

次のサンプルは、Jobsリソース・コレクションからLOV表示属性JobTitleの値をフェッチします。問合せパラメータonlyDataとfieldsにより、表現がフィルタ処理され、レスポンス・ペイロードにデータのみが含まれるようになります(ここで、PresidentとAdministration Assistantは表示属性JobTitleの値の例です)。

リクエスト

- URL
http://server/demo/rest/11.0/Jobs?onlyData=true&fields=JobTitle

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourcecollection+json

- ペイロード

{
"items" : [ {
"JobTitle" : "President"
}, {
"JobTitle" : "Administration Assistant"
}, {
"JobTitle" : "Finance Manager"
}, {
"JobTitle" : "Accountant"
}, {
"JobTitle" : "Accounting Manager"
}, {
"JobTitle" : "Public Accountant"
} ],
"count" : 6,
"hasMore" : false,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Jobs",
"name" : "Jobs",
"kind" : "collection"
} ]
}

22.12 高度な操作

ADF RESTランタイムでは、次の高度なユースケースをサポートしています。

- 既存のリソース・アイテムのコンテキストでLOV属性値を取得します。

- 属性を制限するフィルタ処理を使用する部分取得によりリソースを問い合わせます。

- 行検索を使用してリソース・コレクションをフェッチします。

- リソース・アイテムまたはリソース・コレクションのデータのみを返します。

- リソース・コレクション内のリソース・アイテムの推定カウントを返します。

- ビュー・オブジェクト・クライアント・インタフェースで定義されたカスタム・アクションを実行します。

- HTTPメソッドをオーバーライドして、更新を実行します

- バッチ・リクエストを実行します。

22.12.1 属性のフィルタ処理による問合せ(部分取得)

ADF RESTランタイムでは、GETメソッドを使用した、リソース・コレクションからのフィールド・サブセットの取得をサポートしています。

次のサンプルは、DepartmentsコレクションとEmployeesコレクションのインスタンスの属性値をフェッチします。問合せパラメータfieldsにより、レスポンス・ペイロードには指定された属性のみが含まれるようになります。GETリクエストは、属性値を指定しないURL内のいずれのリソース値も返さない場合があることに注意してください。

最初のリクエスト(URL 1)は、Employeesコレクションのインスタンスの値をフェッチします。問合せパラメータfieldsにより、レスポンス・パラメータには指定した属性(FirstName、LastNameおよびEmail)のみが含まれるようになります。

2番目のリクエスト(URL 2)は、DepartmentsコレクションのインスタンスのDepartmentId値、および各部門の従業員のFirstName値をフェッチします。問合せパラメータonlyDataは、レスポンスをフィルタ処理して、子リンクを非表示にします。

3番目のリクエスト(URL 3)は、DepartmentsコレクションのインスタンスのDepartmentId値、および各部門の従業員のFirstName値および各従業員のJobId履歴をフェッチします。問合せパラメータonlyDataは、レスポンスを再度フィルタ処理して、子リンクを非表示にします。

注意:

ADF RESTリソースのバッキング・ビュー・オブジェクトで実行されるSQL SELECT文は、実行時に、ビュー・オブジェクトがどのように作成されるかに基づきます。宣言SQLモードを有効にしてADF Business Componentsデベロッパで作成するビュー・オブジェクトのみが、問合せパラメータfieldsにより命名された属性のリストのみを使用して作成した最適化されたSQL SELECT文をサポートします。非宣言ビュー・オブジェクトで実行されるSELECT文は、ビュー・オブジェクト定義のすべての属性を含みます。実行時の最適化を実現するには、ADF Business Componentsデベロッパで、宣言SQLモードのみを使用してADF RESTリソースに対するビュー・オブジェクトを作成することをお薦めします。

リクエスト1

- URL 1
http://server/demo/rest/11.1/Employees/101?fields=FirstName,LastName,Email

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス1

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード 1

{
"FirstName" : "Neena",
"LastName" : "Smith",
"Email" : "NSMITH",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.1/Employees/101/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
}

リクエスト2

- URL 2
http://server/demo/rest/11.1/Departments?fields=DepartmentId;Employees:FirstName&onlyData=true

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス2

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourcecollection+json

- ペイロード 2

{
"items" : [

{
"DepartmentId" : 10,
"Employees" : [
{
"FirstName" : "Jennifer"
}
]
},
{
"DepartmentId" : 20,
"Employees" : [
{
"FirstName" : "Michael"
},
{
"FirstName" : "Pat"
}
]
},
{
"DepartmentId" : 30,
"Employees" : [
{
"FirstName" : "Den"
},
{
"FirstName" : "Alexander"
},
{
"FirstName" : "Shelli"
},
{
"FirstName" : "Sigal"
},
{
"FirstName" : "Guy"
},
{
"FirstName" : "Karen"
}
]
},
{
"DepartmentId" : 40,
"Employees" : [
{
"FirstName" : "Susan"
}
]
},
...
],
"count" : 25,
"hasMore" : true,
"limit" : 25,
"offset" : 0,
"links" : [
{
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
}
]

リクエスト3

- URL 3
http://server/demo/rest/11.1/Departments?fields=DepartmentId;Employees:FirstName;Employees.JobHistory:JobId&onlyData=true

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス3

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourcecollection+json

- ペイロード 3

{
"items" : [

{
"DepartmentId" : 10,
"Employees" : [
{
"FirstName" : "Jennifer",
"JobHistory" : [
{
"JobId" : "AD_ASST"
},
{
"JobId" : "AC_ACCOUNT"
}
]
}
]
},
{
"DepartmentId" : 20,
"Employees" : [
{
"FirstName" : "Michael",
"JobHistory" : [
{
"JobId" : "MK_REP"
}
]
},
{
"FirstName" : "Pat",
"JobHistory" : [
{
"JobId" : "AD_ASST"
},
{
"JobId" : "AC_ACCOUNT"
}
]
}
]
},
{
"DepartmentId" : 30,
"Employees" : [
{
"FirstName" : "Den",
"JobHistory" : [
{
"JobId" : "ST_CLERK"
}
]
},
{
"FirstName" : "Alexander",
"JobHistory" : [
{
"JobId" : "AD_ASST"
},
{
"JobId" : "AC_ACCOUNT"
}
]
},
{
"FirstName" : "Shelli",
"JobHistory" : [
{
"JobId" : "AD_ASST"
},
{
"JobId" : "AC_ACCOUNT"
}
]

]
...
],
"count" : 25,
"hasMore" : false,
"limit" : 25,
"offset" : 0,
"links" : [
{
"rel" : "self",
"href" : "http://server/demo/rest/11.0/Departments",
"name" : "Departments",
"kind" : "collection"
}
]
}

22.12.2 行検索によるリソース・コレクションのフィルタ処理

ADF RESTランタイムでは、GETメソッドを使用してリソース・コレクションをフェッチする行検索の適用をサポートしています。ADF RESTリソース開発者は、行検索と呼ばれるシード済フィルタを定義します。ADF RESTランタイムでは、これらのフィルタにパラメータを渡すこと、およびシード済フィルタを使用してコレクションを減らす(つまりフィルタ処理する)ことをサポートしています。

行検索によるフィルタ処理は、1つ以上の行検索パラメータ値を指定するファインダ問合せ文字列を使用して実行されます。行検索問合せ文字列パラメータが含まれるファインダの形式は次のとおりです。

finder=<rowfinderName>;<attr1>=<value1>,<attr2>=<value2>,...

例: finder=DeptByName;Dname=ACCOUNTING

リソース・コレクションの記述は、行検索の形状を説明します。行検索を使用する手順は次のとおりです。

1. リソースの記述を実行し、コレクション要素内のfinders属性を検索します。name属性は、行検索定義名を識別します。また、attributesの下の行検索パラメータの名前も検索します。

2. 問合せパラメータfinderを含むGETを実行し、行検索名およびパラメータを渡します。

たとえば、Departmentsリソースの記述は次を返します。

"collection" : {
"rangeSize" : 25,
"finders" : [ {
"name" : "EmpByEmailFinder",
"title" : "EmployeesByEmailVC",
"attributes" : [ {
"name" : "Email",
"type" : "string",
"updatable" : true,
"required" : "Optional",
"queryable" : false
} ]

次のサンプルは、Email属性値NSMITHが渡される行検索EmpByEmailFinderで指定されたDepartmentsコレクションをフェッチします。

リクエスト

- URL
http://server/demo/rest/11.1/Employees?finder=EmpByNameFinder;Email=NSMITH

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"items" : [ {
"EmployeeId" : 101,
"FirstName" : "Neena",
"LastName" : "Smith",
"Email" : "NSMITH",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 2000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.1/Employees/101/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
} ],
"count" : 1,
"hasMore" : false,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.12.3 ペイロードのリソース・データのみを返す

ADF RESTランタイムでは、リソース・コレクションまたはリソース・アイテムのGETメソッドを使用した、リソース・アイテムのデータのみの取得をサポートしています。

次のサンプルは、Employeesコレクション属性の値をフェッチします。問合せパラメータonlyDataにより、表現がフィルタ処理され、レスポンス・ペイロードにデータのみが含まれ、リンクが含まれないようになります。

リクエスト

- URL
http://server/demo/rest/11.1/Employees?onlyData=true

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"items" : [ {
"EmployeeId" : 101,
"FirstName" : "Neena",
"LastName" : "Smith",
"Email" : "NSMITH",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 2000
}, {
"EmployeeId" : 102,
"FirstName" : "Lex",
"LastName" : "De Haan",
"Email" : "LDEHAAN",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 3000
}, {
"EmployeeId" : 103,
"FirstName" : "Alexander",
"LastName" : "Hunold",
"Email" : "AHUNOLD",
"JobId" : "IT_PROG",
"DepartmentId" : 60,
"Salary" : 4000
}, {
"EmployeeId" : 104,
"FirstName" : "Bruce",
"LastName" : "Ernst",
"Email" : "BERNST",
"JobId" : "IT_PROG",
"DepartmentId" : 60,
"Salary" : 5000
}, {
"EmployeeId" : 105,
"FirstName" : "David",
"LastName" : "Austin",
"Email" : "DAUSTIN",
"JobId" : "IT_PROG",
"DepartmentId" : 60,
"Salary" : 6000
} ],
"count" : 5,
"hasMore" : true,
"limit" : 25,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.12.4 リソース・アイテムの推定カウントを返す

ADF RESTランタイムでは、GETメソッドを使用した、リソース・コレクション内のリソース・アイテムの推定数の取得をサポートしています。

次のサンプルは、Employeesコレクションに関して推定合計結果5を返します。問合せパラメータtotalResultsにより、totalResults属性のみがレスポンス・ペイロードに含まれるようになります。

リクエスト

- URL
http://server/demo/rest/11.1/Employees?totalResults=true&limit=2

- HTTPメソッド
GET

- コンテンツ・タイプ
なし

- ペイロード
なし

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"items" : [ {
"EmployeeId" : 101,
"FirstName" : "Neena",
"LastName" : "Smith",
"Email" : "NSMITH",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 2000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/NSMITH",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/NSMITH",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.1/Employees/NSMITH/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
}, {
"EmployeeId" : 102,
"FirstName" : "Lex",
"LastName" : "De Haan",
"Email" : "LDEHAAN",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 3000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/LDEHAAN",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/LDEHAAN",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.1/Employees/LDEHAAN/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
} ],
"totalResults" : 5,
"count" : 2,
"hasMore" : true,
"limit" : 2,
"offset" : 0,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.12.5 カスタム・アクションの実行

ADF RESTランライムでは、POSTメソッドを使用した、リソースの基礎となるビュー・オブジェクトのクライアント・インタフェースで定義された1つ以上のカスタム・アクションの実行をサポートしています。

次のサンプルは、Employeesコレクションのインスタンスでカスタム・アクションmultiplySalaryを実行します。この場合、カスタム・アクションは基礎となるビュー・オブジェクトのビュー行クライアント・インタフェースで定義されており、このため、行レベル・インスタンスでのアクションの実行が可能になります。

リクエスト

- URL
http://server/demo/rest/11.1/Employees/101

- HTTPメソッド
POST

- コンテンツ・タイプ
application/vnd.oracle.adf.action+json

- ペイロード

{
"name": "multiplySalary",
"parameters": [
{
"multiplicand": "2"
}
]
}

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.actionresult+json

- ペイロード

{
"result" : 4000.0
}

22.12.6 HTTPメソッドのオーバーライドおよび更新の実行

HTTPサーバーまたはクライアントによっては、HTTP仕様の一部のメソッドの公開をサポートしていない場合があります。ADF RESTランタイムでは、一般的なPOSTメソッドを使用して、他のメソッドの操作を実行できます。

次のサンプルは、POSTメソッドを使用して、PATCHメソッドのオーバーライドによりDepartmentsリソース・アイテムを更新します。

リクエスト

- URL
http://server/demo/rest/11.1/Departments/15

- HTTPメソッド
POST

- X-HTTP-Method-Override
PATCH

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"DepartmentName": "UpdatedDept",
}

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.resourceitem+json

- ペイロード

{
"DepartmentId" : 15,
"DepartmentName" : "UpdatedDept",
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Departments/15",
"name" : "Departments",
"kind" : "item"
}
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Departments/15",
"name" : "Departments",
"kind" : "item"
}, {
"rel" : "child",
"href" : "http://server/demo/rest/11.1/Departments/15/child/Employees",
"name" : "Employees",
"kind" : "collection"
} ]
}

22.12.7 バッチ・リクエストの実行

ADF RESTランタイムでは、バッチ・リクエストを使用した、単一ラウンドトリップでの複数操作の実行をサポートしています。データは、リクエストの最後にコミットされます。ただし、バッチ・リクエスト内の1つのリクエスト部分が失敗した場合は、すべての変更がロールバックされ、エラー・レスポンスが返されます。

次のサンプルは、3つの部分の操作を実行する、成功したバッチ操作を示しています。

リクエスト

- URL
http://server/demo/rest

- HTTPメソッド
POST

- コンテンツ・タイプ
application/vnd.oracle.adf.batch+json

- ペイロード

{
"parts": [
{
"id": "part1",
"path": "/11.1/Employees/101",
"operation": "update",
"payload": {
"Salary": 10000
}
},
{
"id": "part2",
"path": "/11.1/Employees/102",
"operation": "update",
"payload": {
"Salary": 10000
}
},
{
"id": "part3",
"path": "/11.1/Employees/103",
"operation": "update",
"payload": {
"Salary": 10000
}
}
]
}

レスポンス

- HTTPコード
200

- コンテンツ・タイプ
application/vnd.oracle.adf.batch+json

- ペイロード

{"parts": {
{
"id" : "part1",
"path" : "/11.1/Employees/101",
"operation" : "update",
"payload" : {
"EmployeeId" : 101,
"FirstName" : "Neena",
"LastName" : "Smith",
"Email" : "NSMITH",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 10000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/101",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.1/Employees/101/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
}
}, {
"id" : "part2",
"path" : "/11.1/Employees/102",
"operation" : "update",
"payload" : {
"EmployeeId" : 102,
"FirstName" : "Lex",
"LastName" : "De Haan",
"Email" : "LDEHAAN",
"JobId" : "AD_VP",
"DepartmentId" : 90,
"Salary" : 10000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/102",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/102",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.1/Employees/102/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
}
}, {
"id" : "part3",
"path" : "/11.1/Employees/103",
"operation" : "update",
"payload" : {
"EmployeeId" : 103,
"FirstName" : "Alexander",
"LastName" : "Hunold",
"Email" : "AHUNOLD",
"JobId" : "IT_PROG",
"DepartmentId" : 60,
"Salary" : 10000,
"links" : [ {
"rel" : "self",
"href" : "http://server/demo/rest/11.1/Employees/103",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "canonical",
"href" : "http://server/demo/rest/11.1/Employees/103",
"name" : "Employees",
"kind" : "item"
}, {
"rel" : "lov",
"href" : "http://server/demo/rest/11.1/Employees/103/lov/JobsLOV",
"name" : "JobsLOV",
"kind" : "collection"
} ]
}
} ]
}

22.13 ADF RESTフレームワーク・リファレンス

ADF RESTフレームワークでは、HTTPメソッド、HTTPヘッダー、リクエストURLパラメータ、メディア・タイプおよびその他の概念をサポートして、リソースに対するREST APIコールの作成を可能にしています。

22.13.1 ADF RESTペイロード圧縮のサポート

サーバーとクライアント間で交換されるHTTPペイロードをエンコードできます。この機能は、クライアントがサービス・リクエストでAccept-Encoding: gzipヘッダーまたはContent-Encodingヘッダーを指定した場合に有効になります。

リソースのエンコーディング・サポートを無効化するには、カスタム・プロパティadf.rest.enablecompressionをfalseに設定します。JDeveloperでは、このプロパティはFusion WebアプリケーションのADF構成ファイル(adf-config.xml)で設定されています。

表22-3は、ADF RESTフレームワークでサポートされているコンテンツ・エンコーディング・トークンを示しています。

表22-3 サポートされているコンテンツ・エンコーディング・トークン

コンテンツ・エンコーディング

説明

identity

ペイロードを圧縮しません。動作は、エンコーディングが省略されている場合と同じです。

x-gzipおよびgzip

RFC 1952 [25]で説明されているように、ファイル圧縮プログラムgzip (GNU zip)で生成される形式を使用してペイロードを圧縮します。この形式は、32ビットCRCを使用するLempel-Zivコーディング(LZ77)です。

deflate

FRC 1950 [31]で定義されているzlib形式と、RFC 1951 [29]で説明されているdeflate圧縮メカニズムを組み合せて使用して、ペイロードを圧縮します。

22.13.2 ADF RESTメディア・タイプ

MIMEタイプまたはコンテンツ・タイプとも呼ばれるメディア・タイプは、クライアントとサーバー間で交換されるペイロードの使用可能なリソース構造を定義します。すべてのADF RESTメディア・タイプはJSONに基づいています。クライアント・アプリケーションでアクセスされるリソースは、applicationタイプとjsonサブタイプに分類されます。

REST APIを起動するサービス・クライアントは、表22-4にリストされているいずれかのメディア・タイプを使用してRESTful Webサービスと対話します。これらのタイプでは、リソースの基礎となるビュー・オブジェクト定義によってメディア・タイプが変わらないことが定義されています。acceptヘッダーの値は、起動のコンテキストに応じて変わることに注意してください。ADF RESTフレームワーク・メディア・タイプのJSONトークン構造へのリンクを次の表に示します。

注意:

サポートされているメディア・タイプを指定するかわりに、サービス・クライアント・リクエストのacceptヘッダーは、サポートされるすべてのメディア・タイプのスーパーセットがレスポンスで受け入れられる場合にapplication/jsonを指定できます。

表22-4 ADF RESTフレームワークでサポートされるメディア・タイプ

メディア・タイプ

起動コンテキスト

説明

application/vnd.oracle.adf.resourcecollection+json

GETメソッド

POSTメソッド

ADF RESTランタイムで返されるすべてのリソース・コレクションの形式を表します。

すべての属性がフレームワークにより自動的に生成されます。items属性のコンテンツのみがリソース定義に基づいています。

例については、「リソース・コレクションの記述」を参照してください。

application/vnd.oracle.adf.resourceitem+json

GETメソッド

POSTメソッド

DELETEメソッド

PATCHメソッド

ADF RESTランタイムで返されるすべてのリソース・アイテムの形式を表します。

属性linksのみがフレームワークにより自動的に生成されます。その他のすべて属性は、リソース定義に基づいています。

例については、「リソース・アイテムの記述」を参照してください。

application/vnd.oracle.adf.action+json

POSTメソッド

カスタム・アクション実行およびそれらのパラメータを記述します。

公開されたカスタム・アクションは、ビュー・オブジェクト・インタフェースまたはビュー行インタフェースのメソッドが基礎となっています。

例については、「カスタム・アクションの実行」を参照してください。

application/vnd.oracle.adf.actionresult+json

POSTメソッド

アクションの実行結果を記述します。

例については、「カスタム・アクションの実行」を参照してください。

application/vnd.oracle.adf.description+json

GETメソッド

リソースおよびその要素を記述します。

例については、「使用可能なすべてのリソースの記述」を参照してください。

application/vnd.oracle.adf.batch+json

POSTメソッド

実行される一連の操作を記述します(操作は部分のセットで構成され、各部分はリクエストを表します)。バッチ・リクエストは、単一のトランザクションで実行されます。

例については、「バッチ・リクエストの実行」を参照してください。

application/vnd.oracle.adf.version+json

GETメソッド

すべてのバージョンのリソースを取得するリクエストの結果を記述します。

例については、「使用可能なすべてのバージョン・リリース名の取得」を参照してください。

22.13.3 ADF RESTデータ型

ADF RESTデータ型は、ADF RESTフレームワークによってADF RESTリソース・アイテムとそれらの基礎となるADFビジネス・コンポーネント・エンティティ・オブジェクト属性との間でマップされます。実行時に、フレームワークは、フェッチされたADF RESTリソース・アイテムのデータ型を記述属性typeとして公開します。

表22-5は、ADF RESTリソースのビュー・オブジェクトの基礎となるエンティティ・オブジェクト属性でサポートされているADFビジネス・コンポーネント・データ型と、ADF RESTフレームワークが定義するADF RESTデータ型との間の関係を示しています。一般に、フレームワークではリソース・アイテムの基礎となる属性のSQLタイプに基づいてADF RESTリソース・アイテムのデータ型を定義しますが、次の2つの例外があります。

- 基礎となる属性がブール型マップとして定義されている場合、ADF RESTタイプは常にブールになります。

- 基礎となる属性のJavaタイプがblobまたはclobである場合、ADF RESTタイプは添付ファイルになります。

表22-5 ADF RESTフレームワークでサポートされるデータ型

ADFの基礎となる属性

ADF RESTデータ型

属性が次のいずれかの型マップで構成される場合:

oracle.jbo.valuemaps.Boolean10PropertySet

oracle.jbo.valuemaps.BooleanTFPropertySet

oracle.jbo.valuemaps.BooleanYNPropertySet

boolean

Javaクラス: oracle.jbo.domain.ClobDomainまたは

oracle.jbo.domain.BlobDomain

将来のリリースではSQLタイプがJavaクラスのかわりに使用されることに注意してください。

attachment

SQLタイプ: Char

string

SQLタイプ: Number

integer

桁数が指定されていないため、将来のリリースでこのADF RESTタイプはnumberに変更されることに注意してください。

SQLタイプ: Number (precision = *、scale > 0)

number

SQLタイプ: Number (precision < 10、scale = 0)

integer

SQLタイプ: Number (precision >= 10、scale = 0)

integer

整数が9桁を超えることはないため、将来のリリースでこのADF RESTタイプはnumberに変更されることに注意してください。

SQLタイプ: DateおよびDateTime

dateおよびdatetime

22.13.4 ADF REST HTTPコード

ADF RESTフレームワークでは、次の表にリストされているHTTPコードをサポートしています。返される特定のコードは、Webサービスで起動されたHTTPメソッドによって異なります。

表22-6 ADF RESTフレームワークでサポートされているHTTPコード

HTTPコード

説明

200 OK

リクエストが正常に実行され、レスポンスにコンテンツが含まれます。

201 Created

リソースが正常に作成されました。レスポンスには作成されたリソースが含まれます。

204 No Content

リクエストが正常に実行され、レスポンスにはコンテンツが含まれません。

304 Not Modified

指定されたETagに応じて、リソースは変更されませんでした。

400 Bad Request

構文の形式が正しくないため、サーバーがリクエストを理解できませんでした。

401 Unauthorized

リクエストのリソースがセキュリティによって保護されており、認証がまだ提供されていないため、サーバーはリクエストの処理を拒否しています。

404 Not Found

リクエストされたリソースが見つかりませんでした。

406 Not Acceptable

リクエストによって識別されたリソースは、リクエストで送信されたAcceptヘッダーによって受入れ不可となったコンテンツ特性を含むレスポンス・エンティティを生成することのみが可能です。

412 Precondition failed

サーバー側のリソース状態は指定されたETagと一致しません。

415 Unsupported Media Type

リクエストされたメソッドに対するリクエストのエンティティが、リクエストされたリソースではサポートされていない形式であるため、サーバーはリクエストの処理を拒否しています。

500 Internal Server Error

サーバーに予期しない状況が発生し、リクエストを遂行できなくなりました。

22.13.5 ADF REST HTTPヘッダー・サポート

ADF RESTフレームワークでは、次の表にリストされているHTTPヘッダーをサポートしています。

表22-7 ADF RESTフレームワークでサポートされているHTTPヘッダー

HTTPヘッダー名

説明

Content-Type

リクエスト/レスポンス・ペイロードのコンテンツ・タイプを指定するために使用します。ADF RESTランタイムでは、「ADF RESTメディア・タイプ」で説明しているように、メディア・タイプを解釈(リクエスト/レスポンス)できます。

Content-Encoding

リクエスト/レスポンス・ペイロードのコンテンツ・エンコーディングを指定するために使用します。ADF RESTランタイムでは、「ADF RESTペイロード圧縮のサポート」で説明しているように、エンコーディングを使用する圧縮リクエストを解析できます。

Accept

レスポンス・ペイロードの予期されたコンテンツ・タイプを指定するために使用します。ADF RESTランタイムでは、「ADF RESTメディア・タイプ」で説明しているように、メディア・タイプを解釈(リクエスト/レスポンス)できます。

Accept-Encoding

許容されるエンコード・レスポンスのリストを指定するために使用します。ADF RESTフレームワークは、「ADF RESTペイロード圧縮のサポート」で説明しているエンコーディングを使用してレスポンスを生成できます。

Location

新たに作成されたリソースのURIを識別するために使用します。ADF RESTフレームワークには、新しいリソースを作成するPOSTのレスポンスにLocationヘッダーが含まれています。例については、「コレクションでのリソース・アイテムの作成」を参照してください。

ETag

リクエスト内のリソースの状態を、サーバー上のリソースの状態と比較するために使用します。ADF RESTフレームワークでは、更新識別子属性を使用するように構成されたADFビジネス・コンポーネント・エンティティ・オブジェクトが基礎となるリソースのETagの生成をサポートしています。詳細は、「データ整合性のチェック」を参照してください。

If-Match

リクエスト内のリソースの状態が、サーバー上のリソースの最新状態であるかどうかを識別するために使用します。このヘッダーは、条件付きリクエストを実行するためにサポートされています。詳細は、「データ整合性のチェック」を参照してください。

If-None-Match

リクエスト内のリソースの状態が、サーバーでの現在の状態に一致しないかどうかを識別するために使用します。このヘッダーは、条件付きリクエストを実行するためにサポートされています。詳細は、「データ整合性のチェック」を参照してください。

X-HTTP-Method-Override

サーバーでサポートされていないアクションを実行するために使用します。これは、(HTTP仕様で定義されていない)カスタム・ヘッダーであり、HTTPメソッドの名前がその値として含まれます。この値(有効な場合)は、使用されるHTTPメソッドの定義に使用されます。このヘッダーはPOSTリクエストでのみ考慮されます。詳細は、「HTTPメソッドのオーバーライドおよび更新の実行」を参照してください。

Cache-Control

フレームワーク・ペイロードをキャッシュ/保存する中間プロキシを回避する場合に使用します。このヘッダーはすべてのHTTPレスポンスに構成されます。有効な値はno-cache、no-storeおよびmust-revalidateです。

web.xmlファイルでinit-paramと指定することで、アプリケーション全体に設定することもできます。init-paramに設定した値はデフォルトを上書きします。

より細かく制御する場合は、値をリソース・ツリーで設定すると、それに応じてヘッダーが設定されます。リソース・ツリーで設定する場合、現時点でCache-Controlに設定できるのは“max-age: ..”のみです。次のリソース定義ファイルのサンプルは値の設定方法を示しています。

<pageDefinition ...>
<parameters/>
<executables/>
<bindings>
<tree ....>
<ServiceConfiguration>
<CacheControl>
<MaxAge>30</MaxAge>
</CacheControl>
</ServiceConfiguration>
<nodeDefinition ../>
</tree>
</bindings>
</pageDefinition>

<MaxAge>内に指定された整数値は、Cache-Control文字列の作成に使用されます(例: "max-age: 30")。操作に関与するリソースが対象のリソース・ツリーに属している場合、この値がレスポンスのCache-Controlヘッダーに設定されます。

このリソース定義値はデフォルト設定およびweb.xmlファイルのinit-param値の設定を上書きするので注意してください。また、リソース定義上でCache-Control値を構成した場合、この値はリソースごとに記述の中に含められます。この情報を使用して、クライアント側でキャッシュ・メカニズムをさらにカスタマイズできます。これは特にバッチ・リクエストを行うときに便利です。

22.13.6 ADF REST HTTPメソッドおよびペイロードのサポート

ADF RESTフレームワークでは、次のHTTPメソッドでの操作をサポートしています。

- GET

- POST

- PATCH

- DELETE

22.13.6.1 GETメソッドの操作

ADF RESTフレームワークでは、GETメソッドを使用した、次に示すURIを含む次の操作をサポートしています。

- リソース・コレクション、リソース・アイテム、またはリソース・コレクションやリソース・アイテムが省略されている場合はリソース・カタログを記述します。

http://server/demo/rest/{version}/[{resourceCollectionPath}|{resourceItemPath}]/describe

- 問合せ文字列パラメータを含む、または含まないリソース・コレクション表現を取得します。

http://server/demo/rest/{version}/{resourceCollectionPath}[?{queryStringParam}[&{queryStringParam}]]

- 問合せ文字列パラメータを含む、または含まないリソース・アイテム表現を取得します。

http://server/demo/rest/{version}/{resourceItemPath}[?{queryStringParam}[&{queryStringParam}]]

- 特定のバージョンのリソース・コレクション、最新のリソース・バージョン、またはバージョン識別子やリソース・コレクションが省略されている場合は使用可能なすべてのリソースを取得します。

http://server/demo/rest/[{version}|latest/{resourceCollectionPath}]

リクエスト・パラメータ

- GETメソッドでは、リソース表現の問合せ、フィルタ処理、ページングおよびソートを実行する問合せ文字列パラメータをサポートしています。サポートされているパラメータを次の表に示します。GETメソッドのすべてのURIパラメータは、表内の他の任意のパラメータと組み合せることができますが、expandパラメータとfieldパラメータには例外が記載されています。問合せ文字列パラメータはリソース・メディア・タイプでのみ使用できることに注意してください。たとえば、リソースの記述時には使用できません。

表22-8 サポートされているリソース・メディア・タイプのGETメソッド問合せ文字列パラメータ

GET URIパラメータ

リソース・タイプ(アイテム/コレクション)

値

説明

q

リソース・コレクションのみ

セミコロンで区切られた1つ以上の式。

形式: <exp1>;<exp2>

例: ?q=Deptno>=10 and <= 30;Loc!=NY

問合せのサポートが強化されたため、問合せパラメータでSQLに似たビュー基準フィルタ式形式を使用し、リソースからどの行を取得するかを指定できます。フィルタは単一式のような簡素なものから、複数の式を組み合せた複雑なものまで使用でき、複雑なフィルタの場合はandとorの結合とグループ分けのためのカッコを使用します。

たとえば、次の式は結合を使用し、3つのフィールドを使用してしてリソースの問合せを実行しています。

(AssignedTo_Id is null) or ( (Priority <= 2) and (RecordName like 'TT-99%'))

指定された式を使用して、リソース・コレクションの問合せが実行されます。

サポートされる演算子:

- より大きい: >

- より小さい: <

- 以上: >=

- 以下: <=

- 論理積: AND

- 論理和: OR

- 等価: =

- 相似: LIKE

特殊文字:

- リテラルの定義: "または' (一重引用符または二重引用符)

- エスケープ: \

- ワイルドカード: *

例については、「問合せパラメータによるリソース・コレクションのフィルタ処理」を参照してください。

finder

リソース・コレクションのみ

ファインダおよびそのパラメータに関する情報を含む式。

形式: <finder>;<param1>=<val1>,<param2>=<value2>

例: ?finder=DeptByName;Dname=ACCOUNTING

指定されたファインダ/パラメータを使用して、リソース・コレクションの問合せが実行されます。使用可能なファインダのリストが記述で提供されます。

タイプがchar、dateまたはnumberに属していないパラメータを含むファインダは除去されます。

例については、「行検索によるリソース・コレクションのフィルタ処理」を参照してください。

fields

両方

リソース・アイテム属性の単純なカンマ区切りリスト。

形式: <attr1>,<attr2>

例: ?Dname,DLoc

子リソースに対して使用できます。

形式: <accessor>:<att1>,<att2>

例: ?fields=Employees:FirstName,LastName

アクセッサ・ドット表記法を使用するネストされたリソースに対して使用できます。

形式: <accessor1>.<accessor2>:<Attr1>,<Attr2>

例: ?fields=Employees.JobHistory:JobId

ネストされたリソース内の両方のリソースに対して。

形式: <accessor1>:<Attr1>,<Attr2>;<accessor1>.<accessor2>:<Attr1>,<Attr2>

例: ?fields=Employees:FirstName;Employees.JobHistory:JobId

このパラメータは、リソース・アイテム属性をフィルタ処理します。指定した属性のみが返されます。

アクセッサ・ドット表記法(Employees.JobHistory)を使用してネストされたリソースを問い合せる場合、両方のリソースで属性を指定できます。アクセッサ・ドット表記のリソースで属性が指定されていない場合、リソース・アイテムの属性は返されません。

このパラメータはexpandパラメータと結合できないことに注意してください。両方のパラメータが指定された場合は、fieldsのみが考慮されます。

例については、「属性のフィルタ処理による問合せ(部分取得)」を参照してください。

onlyData

両方

ブール

デフォルト: false

この表現は、データのみを含める(たとえば、linksオブジェクトを含めない)ためにフィルタ処理されます。

例については、「ペイロードのリソース・データのみを返す」を参照してください。

totalResults

リソース・コレクションのみ

ブール

デフォルト: false

totalResults=trueの場合、リソース・コレクション表現には推定の行カウントが含まれます。

例については、「リソース・アイテムの推定カウントを返す」を参照してください。

expand

両方

すべての子を表示します。形式: all

アクセッサのカンマ区切りリストを使用して、複数の子リソースを表示します。

形式: <accessor1>,<accessor2>

例: ?expand=Employees,Localizations

アクセッサ・ドット表記を使用してネストされたリソースを表示します。

形式: <accessor1>.<accessor2>

例: ?expand=Employees.JobHistory

このパラメータが指定されている場合は、(リンクではなく)指定された子がリソース・ペイロードに含まれます。

expandはfieldsパラメータと結合できないことに注意してください。両方のパラメータが指定された場合は、fieldsのみが考慮されます。

アクセッサ・ドット表記法(Employees.JobHistory)を使用してネストされたリソースを問い合せる場合、欠落している子は暗黙的に処理されます。たとえば、?expand=Employees.JobHistoryは?expand=Employees,Employees.JobHistory (EmployeesとJobHistoryを展開する)と同等です。

例については、「ネストされた子リソースのフェッチ」を参照してください。

limit

リソース・コレクションのみ

整数

デフォルト: ADF RESTリソース定義ファイルのイテレータ・バインディングRangeSizeプロパティ。

このパラメータは、リソース・コレクション内に返されるリソース数を制限します。この制限がリソースの合計結果を超える場合、フレームワークは使用可能なリソースを返します。

例については、「リソース・コレクションのページング」を参照してください。

offset

リソース・コレクションのみ

整数

デフォルト: 0 (最初の位置)

リソース・コレクションの開始位置の定義に使用されます。offsetがリソース数より大きい場合、リソースは返されません。

例については、「リソース・コレクションのページング」を参照してください。

dependency

両方

依存属性のセット。

形式: <attr1>=<val1>,<attr2>=<value2>

例: dependency=ProductId=2

依存性は、レスポンス生成の前に設定され、レスポンス生成の後にロールバックされる属性です。一般に、LOV有効属性のカスケードに適用されるため、属性変更の影響をプレビューするために使用されます。依存属性は、該当するリソース・アイテムで常に設定されます。

子リソース・コレクションがリクエストされた場合、dependencyパラメータが設定されていると、リソース・コレクション・ペイロードが生成される前に、属性は親リソースで設定されます。

orderBy

両方

昇順または降順を指定するソート・フラグが含まれるorder-by属性のカンマ区切りリスト。

形式: <orderBy_attr1_name>[:<(asc/desc)>]、<orderBy_attr2_name>[:<(asc/desc)>]

例: ?DName:asc,DLoc

デフォルト: リソースの基礎となるビュー・オブジェクト問合せで定義されているORDERBY属性が適用されます。

リソース・コレクションをその属性に基づいて順序付けします。asc/descが指定されていない(または無効な値が指定されている)場合、ascがデフォルトとして使用されます。

例については、「リソース・コレクションのソート」を参照してください。

links

両方

<rel_name>のカンマ区切りのリストです。<rel_name>はリンクの関係タイプを表す文字列です。

例: self,canonical

links問合せパラメータを使用してリソース・アイテムまたはリソース・コレクションがリクエストされた場合、カンマ区切りパラメータ値の値に一致する関係タイプ("rel")を持つリンクのみが、レスポンスに表示されます。

onlyDataの値がtrueの場合、ペイロードにlinksセクションが表示されないため、linksパラメータはonlyDataと組み合せることはできません。

include

リソース・カタログ記述

<visibility_type>のカンマ区切りリスト。<visibility_type>はall、unlisted、publicのいずれかです。

1つ以上の可視性タイプを指定したinclude問合せパラメータを使用してリソース・カタログ記述がリクエストされた場合、カンマ区切りパラメータ値の値に一致するVisibilityプロパティを持つリソースのみが、レスポンスに表示されます。

リソース定義の<ServiceConfiguration>タグ内でVisibilityプロパティを設定すると、カタログ記述で最上位のリソースを非表示にすることができます。次のリソース定義ファイルのサンプルは、このプロパティの設定方法を示しています。

<pageDefinition ...>
<parameters/>
<executables/>
<bindings>
<tree ....>
<ServiceConfiguration Visibility="unlisted"/>
<nodeDefinition ../>
</tree>
</bindings>
</pageDefinition>

includeChildren

リソース・アイテム記述

ブール

デフォルト: false

例: ?includeChildren=true

?includeChildren=trueを指定してリソース・アイテム記述がリクエストされた場合、すべての子が再帰的に記述に含まれます。

例については、「リソース・アイテムの記述」および「ネストされたリソースの記述」を参照してください。

サポートされているメディア・タイプ

- リクエスト

- なし

- レスポンス

- application/vnd.oracle.adf.resourcecollection+json: リソース・コレクションを取得する場合。

- application/vnd.oracle.adf.resourceitem+json: リソース・アイテムを取得する場合。

- application/vnd.oracle.adf.description+json: リソースを記述する場合。

- application/vnd.oracle.adf.version+json: 使用可能なすべてのリソース・バージョンを取得する場合。

ユースケースのサンプル

- ADF RESTリソースの記述の取得

- 属性のフィルタ処理による問合せ(部分取得)

- 問合せパラメータによるリソース・コレクションのフィルタ処理

- 行検索によるリソース・コレクションのフィルタ処理

- ADF RESTリソース・アイテムの取得時のデータ整合性のチェック

- 使用可能なすべてのバージョン・リリース名の取得

- 特定バージョンのリソースの取得

- リソース・アイテムのエンクロージャ・リンクを使用した添付ファイルのストリーミング

- 既存のリソース・アイテムのLOV有効属性値の取得

- 属性のフィルタ処理による問合せ(部分取得)

- 行検索によるリソース・コレクションのフィルタ処理

- ペイロードのリソース・データのみを返す

- リソース・アイテムの推定カウントを返す

22.13.6.2 POSTメソッドの操作

ADF RESTフレームワークでは、POSTメソッドを使用した、次に示すURIを含む次の操作をサポートしています。

- 新しいリソースを作成します。

http://server/demo/rest/{version}/{resourceCollectionPath}

- リソース・コレクションまたはリソース・アイテムに対するアクションを実行します。

http://server/demo/rest/{version}/{resourceCollectionPath}|{resourceItemPath}

- バッチ・リクエストを実行します。

http://server/demo/rest/{version}/{resourceCollectionPath}

リクエスト・パラメータ

- なし

サポートされているメディア・タイプ

- リクエスト

- application/vnd.oracle.adf.resourceitem+json: リソースを作成する場合、またはHTTPメソッドをオーバーライドして更新を実行する場合。

- application/vnd.oracle.adf.action+json: アクションを実行する場合。

- application/vnd.oracle.adf.batch+json: バッチ・リクエストを実行する場合。

- レスポンス

- application/vnd.oracle.adf.resourceitem+json: アクションを実行する場合、またはリソースを作成する場合。

- application/vnd.oracle.adf.actionresult+json: オブジェクトを返すアクションを実行する場合。

- application/vnd.oracle.adf.batch+json: バッチ・リクエストを実行する場合。

ユースケースのサンプル

- コレクションでのリソース・アイテムの作成

- 子リソース・アイテムの作成

- リソース・アイテムのエンクロージャ・リンクを使用した添付ファイルのストリーミング

- カスタム・アクションの実行

- HTTPメソッドのオーバーライドおよび更新の実行

- バッチ・リクエストの実行

22.13.6.3 PATCHメソッドの操作

ADF RESTフレームワークでは、PATCHメソッドを使用した、次に示すURIを含む次の操作をサポートしています。

- リソース・アイテムの更新。

http://server/demo/rest/{version}/{resourceItemPath}

リクエスト・パラメータ

- なし

サポートされているメディア・タイプ

- リクエスト

- application/vnd.oracle.adf.resourceitem+json: 更新されるリソース・アイテム。

- レスポンス

- application/vnd.oracle.adf.resourceitem+json: 更新されたリソース・アイテム。

ユースケースのサンプル

- リソース・アイテムの更新

- ADF RESTリソース・アイテムの更新時のデータ整合性のチェック

- Base64を使用したLOBコンテンツの置換

- HTTPメソッドのオーバーライドおよび更新の実行

22.13.6.4 DELETEメソッド

ADF RESTフレームワークでは、DELETEメソッドを使用した、次に示すURIを含む次の操作をサポートしています。

- リソース・アイテムを削除します。

http://server/demo/rest/{version}/{resourceItemPath}

リクエスト・パラメータ

- なし

サポートされているメディア・タイプ

- リクエスト

- なし

- レスポンス

- なし

ユースケースのサンプル

- リソース・アイテムの削除

第IV部 ADFタスク・フローの作成

ここでは、Fusion WebアプリケーションでADFタスク・フローを作成するときに開発者が実行できるタスクについて説明します。ADFタスク・フローでは、Fusion Webアプリケーションの制御フローを定義するためのモジュール・アプローチが提供されます。

第4部の章の内容は次のとおりです。

- ADFタスク・フローのスタート・ガイド

- タスク・フロー・アクティビティの使用

- タスク・フローのパラメータの使用

- リージョンとしてのタスク・フローの使用

- 複雑なタスク・フローの作成

- アプリケーションでのダイアログの使用

23 ADFタスク・フローの概説

この章では、Fusion Webアプリケーション内で作成可能なADFタスク・フローの使用開始について説明します。ADFタスク・フローの作成方法に加えて、アクティビティ、制御フロー・ルール、メモリー・スコープ、およびバインド・タスク・フローとバインドなしタスク・フローなどのADFタスク・フローの主要な機能について説明します。また、終了したタスク・フローをリファクタ、テストおよび実行する方法についても説明します。

この章の内容は次のとおりです。

- ADFタスク・フローについて

- タスク・フローの作成

- タスク・フローへのアクティビティの追加

- タスク・フローへの制御フロー・ルールの追加

- タスク・フローのテスト

- 新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ

23.1 ADFタスク・フローについて

ADFタスク・フローでは、Fusion Webアプリケーションの制御フローを定義するためのモジュール・アプローチが提供されます。アプリケーションを1つの大きなJSFページフローとして表すかわりに、再利用可能なタスクフローの集合として分類することができます。各タスクフローにはアプリケーションのナビゲーショナル・グラフの一部が含まれます。タスクフロー内のノードはアクティビティです。アクティビティ・ノードでは、ページの表示、アプリケーション・ロジックの実行または別のタスク・フローのコールなど、シンプルな論理的操作が表示されます。アクティビティ間のトランザクションは制御フロー・ケースと呼ばれます。

図23-1には、CreateとConfirmと呼ばれる2つのビュー・アクティビティが示されています。これらのビュー・アクティビティは、JSFページ・フロー内部のページ・ノードに類似しています。

図23-1 ADFタスク・フロー

ADFタスク・フローには次の2つの種類があります。

- バインドなしタスク・フロー: ユーザーがタスクを完了できるように対話する一連のアクティビティ、制御フロー・ルールおよびマネージドBeanです。バインドなしタスク・フローは、バインド・タスク・フローに含まれていない、アプリケーション内のすべてのアクティビティおよび制御フローで構成されています。

- バインド・タスク・フロー: タスク・フローの特殊な形式であり、バインドなしタスク・フローとは異なり、単一エントリ・ポイント(ブラウザからの直接の要求が可能なビュー・アクティビティ)と0以上の終了ポイントがあります。プライベート制御フロー・ルール、アクティビティおよびマネージドBeanの独自のセットが含まれています。バインド・タスク・フローでは、再利用、パラメータ、トランザクション管理および再開が可能なほか、JSFページにあるADFリージョン内へのレンダリングも可能です。
バインドなしタスク・フローまたはバインド・タスク・フローに追加可能なアクティビティ・タイプの詳細は、「タスク・フロー・アクティビティの使用」を参照してください。

デフォルトでは、JDeveloperはバインド・タスク・フローのソース・ファイルに対して次のファイル名を使用します。

task-flow-definitionN.xml

ここでNは新しいバインド・タスク・フローを作成するたびに増分する番号です。バインド・タスク・フローのファイル名を選択できます。たとえば、バインド・タスク・フローの目的が顧客によるショッピング・アプリケーションのチェックアウトを可能にすることであれば、checkout-task-flow.xmlを使用できます。

ソース・ファイルには、バインド・タスク・フローのメタデータが含まれています。次のメタデータを使用して、複数のバインド・タスク・フローを同一ソース・ファイル内に追加できます。

<task-flow-definition id="TaskFlowID1">
...
</task-flow-definition>
<task-flow-definition id="TaskFlowID2">
...
</task-flow-definition>

ただし、JDeveloperのビジュアル・エディタではファイルごとに1つのバインド・タスク・フローが表示されるため、2つ以上のバインド・タスク・フローを同一ソース・ファイル内に追加しなければ、バインド・タスク・フローの変更が容易になります。

通常のアプリケーションでは、バインドなしタスク・フローと1つまたは複数のバインド・タスク・フローが組み合されています。たとえば、Fusion Webアプリケーション・テンプレートを使用してアプリケーションを作成する場合、JDeveloperでは、空のバインドなしタスク・フロー(ソース・ファイル名はadfc-config.xml)がデフォルトで作成されます。実行時、Fusion Webアプリケーションでは、バインドなしタスク・フローに追加したアクティビティからバインド・タスク・フローをコールできます。

図23-2に示すように、アプリケーションで実行する最初のアクティビティは、多くの場合、バインドなしタスク・フロー内のビュー・アクティビティです。ビュー・アクティビティは、アプリケーションの一部として表示するJSFページを表します。図23-2に示すアクティビティは、Homeビュー・アクティビティで始まり、バインド・タスク・フローをコールします。calltoLogin_taskFlowアクティビティは、ユーザーのアプリケーションへのログインを可能にするバインド・タスク・フローをコールします。

図23-2 バインド・タスク・フローをコールするバインドなしタスク・フロー

また、バインドなしフロー内にすべてのアプリケーション・アクティビティが含まれているアプリケーションを設計できます。これは、JSFアプリケーションを模倣していますが、バインド・タスク・フローの機能の利点が活用されていません。タスク・フロー機能を十分に活用するには、バインド・タスク・フローを使用します。

表23-1では、JSFページ・フローが提供する制御フローと比較して、ADFタスク・フローが提供する制御フローがもたらす利点について説明します。シナリオによっては、JSFページ・フローの使用が必要な場合もあります。たとえば、「ADFページ・ライフサイクルのカスタマイズ」の説明のように、フェーズ・リスナーを使用するには、JSFページ・フローのfaces-config.xml構成ファイルを使用する必要があります。一般には、アプリケーションでJSFページ・フローとADFタスク・フローを併用することをお薦めしません。

表23-1 ADFタスク・フローの利点

JSFページ・フロー

ADFタスク・フロー

アプリケーション全体を単一のページ・ナビゲーション・ファイルに配置する必要があります(faces-config.xml)。1つのプロジェクト内でfaces-config.xmlのコピーを複数持つことはできますが、アプリケーションはこれらのファイルを実行時にロードします。

アプリケーションは、相互にコールする一連のモジュール型のフローに分割できます。

JSFページ・フロー内のすべてのノードは、JSFページである必要があります。他のタイプのオブジェクトは、JSFページ・フロー内には存在しません。

ビュー、メソッド・コールおよび他のタスク・フローへのコールなどのタスク・フロー・ダイアグラム・ノードに追加できます。

ナビゲーションはページ間のみです。

ナビゲーションは複数のページや、ルーターを含む他のアクティビティにも及びます。詳細は、「ルーター・アクティビティの使用方法」を参照してください。

アプリケーション・フラグメントを再利用できません。

ADFタスク・フローは、同一、または完全に別のアプリケーション内で再利用可能です。

アプリケーションをタスク・フローに分割した後で、一般機能を備えたタスク・フローを再利用できます。

詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

セッション・スコープを除き、複数のリクエスト間では共有メモリー・スコープがありません。

タスク・フロー内のアクティビティ間でのデータ渡しを可能にする共有メモリー・スコープ(ページ・フロー・スコープなど)があります。ページ・フロー・スコープは、バインド・タスク・フローの各インスタンスに対する一意の記憶域を定義します。

23.1.1 バインドなしタスク・フローについて

Fusion Webアプリケーションには常にADFバインドなしタスク・フローが組み込まれており、アプリケーションへのエントリ・ポイントが含まれています。エントリ・ポイントは、ブラウザからの直接の要求が可能なビュー・アクティビティです。Fusion Webアプリケーションには、1つのバインドなしタスク・フローのみが含まれます。デフォルトでは、バインドなしタスク・フローのソース・ファイルはadfc-config.xmlファイルです。バインドなしタスク・フローに対して追加ソース・ファイルを作成できますが、アプリケーションでは、実行中のすべてのソース・ファイルがadfc-config.xmlファイルにまとめられます。図23-3は、アプリケーションからのバインドなしタスク・フローのダイアグラムを示しています。このタスク・フローにはいくつかのビュー・アクティビティが含まれており、いずれもアプリケーションへのエントリ・ポイントになっています。

図23-3 バインドなしタスク・フロー

次の場合には、バインド・タスク・フローではなく、バインドなしタスク・フローを使用します。

- ビュー・アクティビティのブックマークなど、バインド・タスク・フローでは提供されないADFコントローラ機能を利用する場合。詳細は、「ビュー・アクティビティのブックマーク」を参照してください。

- タスク・フローが別のタスク・フローによってコールされない場合。

- アプリケーションに複数のエントリ・ポイントがある場合。図23-3では、バインドなしタスク・フロー上にビュー・アクティビティ・アイコンで表されるどのページからでも、タスク・フローを開始できます。

バインドなしタスク・フローではパラメータを宣言的に指定できません。さらにここでは、デフォルト・アクティビティ、つまりバインドなしタスク・フローで最初に実行するよう設計されたアクティビティも含まれません。これは、バインドなしタスク・フローには単一エントリ・ポイントがないためです。これらのいずれかを実行するには、バインド・タスク・フローが必要です。

完全に宣言的なADFコントローラ・トランザクションおよび再開サポートの利点を活用するには、バインドなしタスク・フローではなくバインド・タスク・フローを使用します。

23.1.2 バインド・タスク・フローについて

ADFバインド・タスク・フローを使用して、アプリケーションの再利用可能な部分をカプセル化します。バインド・タスク・フローは、次のようなJavaメソッドに類似しています。

- 単一エントリ・ポイントがある。

- 入力パラメータを受け入れることができる。

- 戻り値を生成できる。

- アクティビティおよび制御フロー・ルールの独自のコレクションがある。

- 独自のメモリー・スコープおよびマネージドBeanの存続期間(ページ・フロー・スコープ・インスタンス)がある。
メモリー・スコープの詳細は、「タスク・フローのメモリー・スコープに関する必知事項」を参照してください。

- 独立したデータ・コントロール・フレームがあるのかどうかを判別できます。
データ・コントロール・フレームへのアクセスの詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

- アクティビティを例外処理アクティビティとして定義できます。
バインド・タスク・フローの例外処理の詳細は、「タスク・フローの例外処理」を参照してください。

図23-3のcreateOrderアクティビティはバインド・タスク・フローのコールです。バインドなしタスク・フローは、バインド・タスク・フローをコールできますが、別のタスク・フローからコールできません。バインド・タスク・フローからは別のバインド・タスク・フローをコールでき、さらにそのバインド・タスク・フローからも次々にコールできます。コールに深さ制限はありません。

図23-4は、バインド・タスク・フローを示しています。

図23-4は、バインド・タスク・フローを示しています。

バインド・タスク・フローを作成する理由は次のとおりです。

- バインド・タスク・フローでは、常にバインド・タスク・フローの開始直後に実行する必要のある単一エントリ・ポイントとなる、デフォルト・アクティビティを指定します。
図23-4では、これはreconcileOrdersとラベル付けされたメソッド・コール・アクティビティです。メソッド・コール・アクティビティはデフォルトのアクティビティであるため、常にバインド・タスク・フローがorderビュー・アクティビティにより参照されるページをレンダリングする前に起動されます。

- 再利用可能です。たとえば、注文を管理またはチェックアウトするプロセスを必要とする他のアプリケーションに組み込むことができます。バインド・タスク・フローは、同じアプリケーション内でも再利用できます。

- バインド・タスク・フロー内で使用するマネージドBeanは、ページ・フロー・スコープで指定できるため、残りのアプリケーションからは分離されます。これらのマネージドBean(およびページ・フロー・スコープ)は、タスク・フローが完了した際に自動的に解放されます。

表23-2に、バインド・タスク・フローの要約を示します。

表23-2 バインド・タスク・フローの機能

機能

説明

明確に定義された境界

バインド・タスク・フローは、プライベート制御フロー・ルール、アクティビティおよびマネージドBeanの独自のセットで構成されます。コール元は、バインド・タスク・フロー境界内におけるページ名、メソッド・コール、子バインド・タスク・フロー、マネージドBean、制御フロー・ルールの内部知識を必要としません。入力パラメータをバインド・タスク・フローに渡すことが可能なほか、バインド・タスク・フローの終了時に戻り値を返すことが可能です。データ・コントロールはタスク・フロー間で共有できます。

単一エントリ・ポイント

バインド・タスク・フローには、タスク・フロー内の他のすべてのアクティビティの前に実行されるデフォルト・アクティビティである、単一のエントリ・ポイントがあります。詳細は、「バインド・タスク・フローのデフォルト・アクティビティに関する必知事項」を参照してください。

ページ・フロー・メモリー・スコープ

バインド・タスク・フロー内のアクティビティ間でデータを受け渡すためのメモリー・スコープとしてページ・フロー・スコープを指定できます。ページ・フロー・スコープは、バインド・タスク・フローの各インスタンスに対する一意の記憶域を定義します。その存続期間はバインド・タスク・フローであり、requestスコープより長く、sessionスコープより短くなっています。詳細は、「タスク・フローのメモリー・スコープに関する必知事項」を参照してください。

アドレス可能

バインド・タスク・フローにアクセスするには、バインド・タスク・フローのXMLソース・ファイルに記述されている一意の識別子とXMLソース・ファイルのファイル名を指定します。詳細は、「タスク・フロー・コール・アクティビティ追加時の処理」を参照してください。

再利用

アクティビティ・グループ全体を単一のエンティティ、つまりバインド・タスク・フローとして識別し、そのバインド・タスク・フローをADFリージョン内の別のアプリケーションで再利用できます。

また、既存のバインド・タスク・フローは、コールするのみで再利用できます。たとえば、あるタスク・フローは、タスク・フロー・コール・アクティビティまたはURLを使用して別のバインド・タスク・フローをコールできます。

さらに、タスク・フロー・テンプレートを使用して、様々なバインド・タスク・フローで再利用するための共通の動作を取得できます。詳細は、「タスク・フロー・テンプレートの作成」を参照してください。

パラメータおよび戻り値

コール元は、バインド・タスク・フローに入力パラメータを渡し、戻り値を取得します。詳細は、「バインド・タスク・フローへのパラメータ渡し」を参照してください。

また、バインド・タスク・フロー間でデータ・コントロールを共有できます。詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

トランザクション管理

バインド・タスク・フローは、作業のトランザクション単位を示すことができます。タスク・フローの開始時に、新規のトランザクションを作成するか、既存のものを結合するか、または既存のトランザクションの一部ではないかどうかを決定するオプションをバウンド側のタスク・フローに宣言的に指定できます。詳細は、「タスク・フローのトランザクションの管理」を参照してください。

再開

再開できるかどうかを決定するオプションを、バインド側のタスク・フローで指定できます。詳細は、「バインド・タスク・フローの再開」を参照してください。

メタデータのオンデマンド・ロード

バインド・タスク・フロー・メタデータは、バインド・タスク・フローの開始時にオンデマンドでロードされます。

セキュリティ

バインド・タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

表23-3にリストされている前提条件および制約を理解すると、ADFタスク・フロー、アクティビティおよび関連するADF Controller機能を正しく使用する上で役立ちます。

表23-3 ADFコントローラ機能の前提条件および制約

Feature Area

前提条件/制約

説明

ADFコントローラ・オブジェクトおよびダイアグラムのUI

JSFビュー・レイヤー

ADFコントローラはJSF環境で動作します。OracleのWebベースのFusion Webアプリケーション戦略は、唯一のビュー・レイヤー・テクノロジとしてJSFに焦点を当てています。

ADFコントローラ・オブジェクトおよびダイアグラムのUI

Oracle ADF Faces依存

ADFコントローラの拡張機能はOracle ADF Faces上に実装されています。この機能はADF Facesライブラリに依存しますが、これらのライブラリが存在する場合はJSF実装に対して実行できます。

ADFコントローラ・オブジェクトおよびダイアグラムのUI

カプセル化されたナビゲーションおよび状態管理

ADFコントローラでは、ナビゲーションと(ある程度までの)状態管理もカプセル化します。JSFおよびサーブレットAPIは、現在もアプリケーション、セッションおよびリクエストのレベルでの基本の状態管理に利用できます。

ADFコントローラ・オブジェクトおよびダイアグラムのUI

モデル・レイヤー

ADFモデル・レイヤーは、アプリケーションのモデル・レイヤーの実装に使用されます。

ADFコントローラ・オブジェクトおよびダイアグラムのUI

MDSへの依存

ADFコントローラ・メタデータはMDSに保存されます。ただし、MDSは現在faces-config.xmlをロードできません。

MDSが提供しているカスタマイズ機能が必要な場合は、ADFタスク・フローを占有使用してマネージドBeanと制御フロー・ルールの定義を行う必要があります。

ADFコントローラ・オブジェクトおよびダイアグラムのUI

StrutsまたはModel 1からの移行パスのサポートなし

StrutsまたはModel 1からADF Controllerへの移行はサポートされていません。

しかし、JSFページ・フローで選択したページに基づいて、新規のバインド・タスク・フローを作成できます。詳細は、「JSFページからのタスク・フローの作成方法」を参照してください。

バインド・タスク・フロー

ページ・フロー・スコープ状態として公開

ADFコントローラは、ページ・フロー・スコープの状態の実装を管理します。フレームワークによって提供される自動管理機能(「戻る」ボタンのサポート、状態のクリーンアップ機能など)は、ページ・フロー・スコープのデータを想定しています。アプリケーションでそのページのすべてに対してこのような機能を完全実装するために、必要に応じてネストされたバインド・タスク・フローを使用して、アプリケーション全体をADFバインド・タスク・フローとして公開します。アプリケーションには、ページ・フロー・スコープ内にバージョニングを必要とする状態が格納されます。

バインド・タスク・フロー

トランザクション境界

開発者は、ADFバインド・タスク・フローを使用してトランザクション境界を管理します。

ページ・フロー・スコープ

ADFライフサイクル内のアクセスの可用性

ADFコントローラでアクセス準備ができる前のADFライフサイクルの初期段階では、アプリケーションによるページ・フロー・スコープへのアクセスは試行できません。

ページ・フロー・スコープは、ビューのリストア・フェーズでBefore ListenerおよびAfter Listenerが実行されるまでは、アクセス可能になるとは保証されていません。ADFコントローラは、ビューのリストア・フェーズでBefore ListenerおよびAfter Listenerを使用して、サーバー側の状態をリクエストと同期化させます。ここでは、ブラウザの「戻る」ボタン検出やブックマーク参照解除などが処理されます。

ナビゲーション

ナビゲーション

ADFコントローラの使用時、faces-config.xmlのナビゲーション・ルールではなく、ADFコントローラの制御フロー・ルールを使用してすべてのアプリケーションのナビゲーションを行います。

ADFコントローラはADFコントローラ・メタデータ内に一致する制御フロー・ケースがない場合にナビゲーション処理を委譲しますが、ADF以外コントローラ以外のNavigationHandlerでナビゲーションを行う場合は、すべてのADFコントローラ機能は保証されません。

23.1.3 制御フローについて

タスク・フローは、アクティビティ、およびアクティビティ間の遷移を定義する制御フロー・ケースで構成されます。図23-5は、制御フロー・ルール、つまりラベル付けしたtoView2を示しています。ここでは、ViewActivity1およびViewActivity2のビュー・アクティビティ間の遷移が定義されています。図23-5のタスク・フローが実行されると、ViewActivity1ビュー・アクティビティがViewActivity2ビュー・アクティビティの前に表示されます。

図23-5 アクティビティおよび制御フロー・ケースのあるタスク・フロー

また、図23-5のタスク・フローにはメソッド・コール・アクティビティ(methodCall1)が含まれており、ViewActivity2ビュー・アクティビティの後およびtaskflowCall1タスク・フロー・コール・アクティビティの前に呼び出されます。タスク・フローでは、ページのレンダリング前後のメソッド・コール・アクティビティなどのアクティビティを呼び出します。特定のページの外部でメソッド・コール・アクティビティを呼び出すことによって再利用を促進できます。これは、そのメソッドを必要としない他のコンテキスト(別のタスク・フローなど)でページを再利用できるからです。制御フロー・ルールの詳細は、「タスク・フローへの制御フロー・ルールの追加」を参照してください。

ワイルドカード制御フロー・ルールは制御フローのfrom-activity-idを表し、これには、後方ワイルドカード(foo*)または単一ワイルドカード文字(*)が含まれます。タスク・フロー内の任意のアクティビティからワイルドカード制御フロー・ルールに制御を渡す場合は、単一ワイルドカード文字を使用します。あるいは、ワイルドカード制御フロー・ルールに制御を渡すアクティビティを制限する場合は、後方ワイルドカードを使用します。

図23-6では、ワイルドカード制御フロー・ルールに単一ワイルドカード文字が含まれており、タスク・フロー内のどのアクティビティからでもタスク・フロー・ダイアグラムで接続先となっているアクティビティに制御を渡せることを示しています。

図23-6 単一ワイルドカードのあるワイルドカード制御フロー・ルール

図23-7の後方ワイルドカードは、activity-idがsummitという文字で始まる有効なソース・アクティビティからloginPageビューに制御フローを渡せることを示しています。

図23-7 後方ワイルドカードのあるワイルドカード制御フロー・ルール

ワイルドカード制御フロー・ルールの詳細は、「ワイルドカード制御フロー・ルールの追加方法」を参照してください。

23.1.4 ADFタスク・フローのユース・ケースと例

図23-8は、Summitサンプル・アプリケーションのADFタスク・フローの画面を示しています。画面のエンド・ユーザーは、顧客のリストを表示するタスク・フローを起動します。画面に公開されるコントロールを使用して、エンド・ユーザーは注文の作成または編集を可能にするタスク・フローを起動することもできます。

図23-8 データを作成または編集するタスク・フロー

また、タスク・フローを使用して、エンド・ユーザーに公開するアクセス・ポイントの数を減らすことによって、Fusion Webアプリケーションのセキュリティを確保できます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つのバインドなしタスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローの「URL起動」プロパティをurl-invoke-disallowedに設定することで、アプリケーションのアクセス・ポイントは1つのみ(バインドなしタスク・フローのページ)となります。「URL起動」プロパティの詳細は、「URLを使用したバインド・タスク・フローのコール方法」を参照してください。Fusion Webアプリケーションのセキュリティ保護の詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

23.1.5 ADFタスク・フローの追加機能

ADFタスク・フローを構成または使用する前に、他のOracle ADF機能を理解しておくことは有効だと思われます。さらに、タスク・フローの構成で可能な機能について読むことが必要な場合もあります。次に、関連する他の機能へのリンクを示します。

- タスク・フローはマネージドBeanを起動します。タスク・フローで使用するマネージドBeanの定義、サポートしているメモリー・スコープ、その他の関連する情報の詳細は、「タスク・フロー用のメモリー・スコープに関する必知事項」および「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

- タスク・フローは再利用が可能です。アプリケーションの機能の再利用の詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

- タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

- カスタム・コードを記述することでタスク・フローで実行される機能を拡張できます。たとえば、タスク・フロー・アクティビティでの例外発生時にタスク・フローが制御を渡すカスタム例外ハンドラを記述できます。詳細は、「例外ハンドラとしてカスタム・コードを指定する方法」を参照してください。
次の例のように、内部としてマークされていないパッケージをインポートしないようにカスタム・コードを記述していることを確認します。

import oracle.adfinternal.controller.*;

カスタム・コードの記述に使用できるAPIの詳細は、次のドキュメントを参照してください。

- Oracle ADF ControllerのJava APIリファレンス

- Oracle ADF FacesのJava APIリファレンス

23.2 タスク・フローの作成

タスク・フローはタスク・フロー自体と、複数のアクティビティ、そしてそれらのアクティビティ間の制御フロー・ルールで構成されています。ほとんどの場合は、アクティビティの多くがフロー内の異なるページを示すビュー・アクティビティです。たとえば、ページのレンダリング前などに一部のメソッドや操作をコールする必要がある場合は、メソッド・コール・アクティビティをそのアクティビティから次の適切なアクティビティまでの制御フロー・ケースとともに使用します。別なタスク・フローをコールする場合は、タスク・フロー・コール・アクティビティを使用します。フローになんらかのブランチ化が必要な場合は、ルーター・アクティビティを使用します。バインド・タスク・フローの最後で、リターン・アクティビティを使用してフローを終了し、そのバインド・タスク・フローをコールしたフローに制御を戻します。

各アクティビティ用のメタデータと設定可能な追加構成を含む、タスク・フローの各アクティビティの詳細および手順は、「タスク・フローへのアクティビティの追加」を参照してください。

23.2.1 タスク・フローの作成方法

バインド・タスク・フローとバインドなしタスク・フローを作成するプロセスは類似しています。主な相違は、「タスク・フローの作成」ダイアログの「バインド・タスク・フローとして作成」チェック・ボックスを選択してバインド・タスク・フローを作成する点です。

注意:

プロジェクトの作成時は、バインドなしタスク・フローを必ずしも作成する必要はありません。「プロジェクト・プロパティ」ダイアログの「機能」ページで、「ADFページ・フロー」を指定している場合は、プロジェクト内で新しいadfc-config.xmlファイルが自動的に作成されます。adfc-config.xmlソース・ファイルは、バインドなしタスク・フローの主要なファイルです。

始める前に:

タスク・フローの構成内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローの作成」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

タスク・フローを作成する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、タスク・フローを作成するプロジェクトを右クリックし、「新規」→「ADFタスク・フロー」の順に選択します。

2. 「タスク・フローの作成」ダイアログでは、デフォルトで「バインド・タスク・フローとして作成」チェック・ボックスが選択されています。アプリケーションのバインドなしタスク・フローに組み込まれるソース・ファイルを作成するには、チェック・ボックスの選択を解除します。
チェック・ボックスの選択を解除すると、「ファイル名」フィールドのデフォルト値が自動的に変更されます。この値は、作成するタスク・フローのXMLソース・ファイルに名前を付けるために使用されます。XMLソース・ファイルには、タスク・フローのアクティビティおよび制御フロー・ルールを記述するメタデータが含まれます。

ヒント:

バインドなしタスク・フローのデフォルト名は、adfc-config.xmlです。バインド・タスク・フローのデフォルトのソース・ファイル名は、「タスク・フローID」フィールドに指定された値と一致します。

1つのプロジェクトには複数のタスク・フローを含めることができるので、ソース・ファイルに一意の名前を付けるために、「ファイル名」フィールドのデフォルト値に数字が追加されます(task-flow-definition3.xmlなど)。

3. 「タスク・フローの作成」ダイアログでは、「ページ・フラグメントを使用して作成」チェック・ボックスがデフォルトで選択されます。
タスク・フローに追加するビュー・アクティビティが必要な場合はこのチェック・ボックスを選択解除して、メインのブラウザ・ウィンドウにレンダリングするJSFページをルート・ページとして参照します。タスク・フローに追加するビュー・アクティビティが必要な場合は、「ページ・フラグメントを使用して作成」チェック・ボックスを選択したままにして、実行時にADFリージョンでタスク・フローが表示するページ・フラグメント・ファイル(.jsff)を参照します。このような区別はビュー・アクティビティから起動するダイアログには適用されず、「ページ・フラグメントを使用して作成」を選択した場合、ビュー・アクティビティを定義して、JSFページまたはページ・フラグメント・ファイルのどちらも参照できます。

4. 「OK」をクリックします。
タスク・フローを表すダイアグラムがエディタに表示されます。

ヒント:

タスク・フロー・ダイアグラム全体のサムネイルは、ダイアグラムをクリックし、メイン・メニューで「ウィンドウ」→「サムネイル」を選択すると表示できます。

タスク・フローの作成後、ダイアグラム、概要およびソース・エディタを使用して更新できます。タスク・フローの更新には、「構造」ウィンドウも使用できます。

ヒント:

タスク・フローの作成には、既存のタスク・フローの内容を新規のタスク・フローにリファクタするなど、別の方法もあります。詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。

5. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、アクティビティをドラッグして、ダイアグラムへドロップします。
通常は、ビュー・アクティビティから開始します。すべての種類のアクティビティを追加する手順の詳細は、「タスク・フローにアクティビティを追加する方法」を参照してください。

- ダイアグラム上にビュー・アクティビティをドラッグする場合は、そのアクティビティをダブルクリックすると、タスク・フローで起動するように構成されているJSFページまたはページ・フラグメントのウィザードを表示できます。このウィザードを使用してページまたはページ・フラグメントの特性を定義します。詳細は、「ビュー・アクティビティの使用方法」を参照してください。

注意:

「アプリケーション」ウィンドウからタスク・フローのダイアグラム上にページをドラッグ・アンド・ドロップして、タスク・フローにビュー・アクティビティを追加することもできます。

- ルーター・アクティビティをダイアグラム上にドラッグすると、「プロパティ」ウィンドウを使用して式を作成し、その式の評価によりどの制御フロー・ルールに従うかを決定できます。詳細は、「ルーター・アクティビティの使用方法」を参照してください。

- コール・アクティビティをダイアグラム上にドラッグすると、「プロパティ」ウィンドウを使用して、コールするメソッドを構成できます。詳細は、「メソッド・コール・アクティビティの使用」を参照してください。

- ダイアグラム上にタスク・フロー・アクティビティをドラッグすると、アクティビティをダブルクリックして、新しいバインド・タスク・フローの設定を定義できる「バインド・タスク・フローの作成」ウィザードを表示できます。詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。

- バインド・タスク・フローを作成しており、タスク・フロー・リターン・アクティビティをダイアグラム上にドラッグすると、「プロパティ」ウィンドウを使用して、アクティビティを構成できます。詳細は、「タスク・フロー・リターン・アクティビティの使用」を参照してください。

6. アクティビティ間の制御フロー・ケースを作成します(詳細および詳細な手順は、「タスク・フローに制御フロー・ルールを追加する方法」を参照)。

a. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「制御フロー」グループから、「制御フロー・ケース」を選択します。

b. ダイアグラムで、ビューなどのソース・アクティビティをクリックし、次にターゲット・アクティビティをクリックします。たとえば図23-14では、制御フローに2つのアクティビティがリンクされています。ソースとターゲットの両方(view1およびview2)のアクティビティがリンクされています。

c. 「プロパティ」ウィンドウで、「一般」セクションを開き、「アクション(自)」属性(結果がメソッドによって決定する場合)または「結果(自)」属性(結果をStringとして設定可能な場合)を使用して結果値を選択します。

7. バインド・タスク・フローを作成する場合、いずれかのアクティビティをデフォルトに指定できます。それにより、バインド・タスク・フローの実行中は常にこの特定のアクティビティを最初に実行できます。デフォルトでは、JDeveloperはタスク・フローに追加した最初のアクティビティをデフォルトにします。別なアクティビティに変更する場合は、ダイアグラム内で該当するアクティビティを右クリックし、「アクティビティのマーク」→「デフォルト・アクティビティ」の順に選択します。詳細は、「バインド・タスク・フローのデフォルト・アクティビティに関する必知事項」を参照してください。

23.2.2 タスク・フロー作成時の処理

新規のバインドなしタスク・フローまたはバインド・タスク・フローを作成するたびに、新しいXMLソース・ファイルが作成されます。デフォルトでは、バインドなしタスク・フローのXMLソース・ファイルはadfc-config.xmlと呼ばれます。

次の例に示すように、すべてのADFコントローラXMLソース・ファイルでは、最上位の要素として<adfc-config>が最初に出現します。バインド・タスク・フロー、アクティビティおよび制御フロー・ルールは、<adfc-config>要素の内部に定義されます。バインド・タスク・フローは、ソース・ファイル内で<task-flow-definition>メタデータ要素によって識別されます。

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2" id="__1">
<task-flow-definition id="task-flow-definition">
<use-page-fragments/>
</task-flow-definition>
</adfc-config>

バインド・タスク・フローは、識別子とドキュメント名の一意な組合せで構成されたタスク・フロー参照によって識別されます。例23-1は、タスク・フロー・コール・アクティビティ内のタスク・フロー参照の例を示しています。

注意:

JDeveloperを使用してバインド・タスク・フローを作成する場合は、各ドキュメントに1つのID (1つのバインド・タスク・フローを示す)のみを指定します。

バインド・タスク・フローを作成する場合は、識別子とドキュメント名の両方を割り当てます。例23-1に示すように、識別子は、「タスク・フローID」フィールドの値です。ドキュメント名は、「ファイル名」フィールドの値です。

例23-1 タスク・フロー参照

<adfc-config xmlns="http://xmlns.oracle.com/adf/Controller" version="1.2">
<task-flow-definition id="task-flow-definition">
<use-page-fragments/>
...
<task-flow-call id="taskFlowCall">
<task-flow-reference>
<document>/WEB-INF/target-task-flow-definition.xml</document>
<id>my-task-flow</id>
</task-flow-reference>
</task-flow-call>
...
</task-flow-definition>
</adfc-config>

23.2.3 バインド・タスク・フローのデフォルト・アクティビティに関する必知事項

デフォルト・アクティビティは、バインド・タスク・フローで実行される最初のアクティビティです。たとえば、タスク・フロー・コール・アクティビティからバインド・タスク・フローに制御が渡される場合は、デフォルト・アクティビティは常に最初に実行されます。

バインドなしタスク・フローにはデフォルト・アクティビティはありません。

図23-9に示すように、緑の円はタスク・フロー・ダイアグラムのデフォルト・アクティビティを示します。

図23-9 バインド・タスク・フローのデフォルト・アクティビティ

新しいバインド・タスク・フロー・ダイアグラムに最初に追加するアクティビティはデフォルト・アクティビティとして自動的に識別されます。タスク・フロー・ダイアグラム内の任意のアクティビティを右クリックし、「アクティビティのマーク」→「デフォルト・アクティビティ」の順に選択することもできます。このデフォルトはすべてのアクティビティ・タイプで指定可能で、バインド・タスク・フローの制御フロー内でどの位置にも配置できます。デフォルト・アクティビティを検索するには、タスク・フロー・ダイアグラム上の任意の場所で右クリックし、「デフォルト・アクティビティに移動」を選択します。

バインド・タスク・フローで使用できるデフォルト・アクティビティは1つのみです。デフォルトとして2つ目のアクティビティをマークすると、最初のマークが自動的に解除されます。アクティビティのマークを手動で解除するには、タスク・フロー上の任意のアクティビティを右クリックし、「アクティビティのマーク解除」→「デフォルト・アクティビティ」を選択します。

トレインの途中で、デフォルト・アクティビティとしてトレイン・ストップを指定しないでください。詳細は、「バインド・タスク・フローでのトレイン・コンポーネントの使用」を参照してください。

例23-2に、バインド・タスク・フローのSurveyPrompt というデフォルト・アクティビティのメタデータの例を示します。

例23-2 バインド・タスク・フローのデフォルト・アクティビティ・メタデータ

<task-flow-definition id="survey">
<default-activity>SurveryPrompt</default-activity>
<view id="SurveryPrompt">
<page>/SurveryPrompt.jsff</page>
</view>
<use-page-fragments/>
</task-flow-definition>

23.2.4 タスク・フローのメモリー・スコープに関する必知事項

Fusion Webアプリケーション内の各タスク・フローでは、状態を管理するためにpageFlowスコープを定義しています。pageFlowスコープはタスク・フローの開始時に始まり、タスク・フローの終了時に終わります。pageFlowスコープで定義する一意の記憶域は、タスク・フローのアクティビティ間でのデータの受渡しに使用するアプリケーション内でタスク・フローのインスタンスごとに定義されます。あるタスク・フローが別なタスク・フローをコールする際、呼出し側のタスク・フローは呼出される側のpageFlowスコープにアクセスします。したがって、たとえば、タスク・フローのビュー・アクティビティが参照するページ上のUIコンポーネントでは、たとえこのタスク・フローがUIコンポーネントと同じページに組み込まれたADFリージョンであっても、別のタスク・フローのpageFlowスコープにアクセスできません。

タスク・フローで複数のマネージドBeanを定義できます。図23-10は、バインド・タスク・フロー(customers-task-flow-definition.xml)が、スコープがbackingBeanであるマネージドBeanを参照する、Summit ADFタスク・フロー・サンプル・アプリケーションの例です。マネージドBeanに割り当てられたスコープを特定できます。

図23-10 タスク・フローに登録されたマネージドBean

表23-4は、マネージドBeanに使用可能なスコープを示しています。また、タスク・フローで定義したマネージドBeanの各スコープの使用に適したタイミングも説明しています。この表はスコープを存続期間順に示しています。たとえば、アプリケーション・スコープは、リクエスト・スコープよりも存続期間が長くなっています。オブジェクト・スコープの存続期間の詳細は、「オブジェクト・スコープ・ライフサイクルについて」を参照してください。

表23-4 ADFマネージドBeanのメモリー・スコープ

有効範囲

説明

アプリケーション

アプリケーション・スコープはアプリケーション終了時まで続行します。このスコープのマネージドBeanに保存する値は、そのアプリケーションを使用する各セッションと各リクエストで使用できます。

タスク・フローに使用すると、タスク・フローが終了しても存続してしまうので、避けてください。

セッション

セッション・スコープはユーザーがアプリケーション内のページに最初にアクセスしたときに始まり、非アクティブ状態になった場合、またはアプリケーションによるセッション認証が失敗した場合に、ユーザー・セッションがタイムアウトしたときに終了します。

このスコープは、セッション全体に関連する情報(ユーザー情報やコンテキスト情報など)にのみ使用します。タスク・フロー間で値を渡すためにセッション・スコープを使用しないでください。タスク・フロー間での値のやり取りには、パラメータを使用します。パラメータを使用すると、タスク・フローは、コール元あるいはコール先となる他のタスク・フローと明確に結ばれます。セッション・スコープの使用を避けるもう1つの理由は、タスク・フローが終了しても存続する可能性がある点です。最後に、同じセッション内でエンド・ユーザーが複数のブラウザ・ウィンドウを開いた場合は、ブラウザ・ウィンドウ間でセッション・スコープの値が共有されます。これらのブラウザ・ウィンドウ間では競合が発生する可能性もあります。

pageFlow

タスク・フロー内のアクティビティ全体でマネージドBeanにアクセスできるようにしたい場合は、このスコープを選択します。pageFlowがあるマネージドBeanは、それにアクセスするタスク・フローのページと同じ状態にあります。pageFlowがあるマネージドBeanは、タスク・フローの存続期間中に存在します。

ビュー

このスコープは、現在のビュー・アクティビティ内でのみ必要とされ、ビュー・アクティビティ間をまたがっていないマネージドBeanオブジェクトに使用します。

このスコープの存続期間は、ビュー・ポートの現在のviewIdの変更開始から終了までです。ビューを指定すると、このアプリケーションは、ユーザーがそのページと対話し続けるかぎり、ページで使用するマネージドBeanオブジェクトを維持します。これらのオブジェクトは、ユーザーがページを終了すると自動的に解放されます。

JSFとOracle ADFにはこのスコープが実装されています。Fusion Webアプリケーションでは、1つのEL式にビュー・スコープを使用すると、Oracle ADF実装に解決されます。

リクエスト

リクエスト・スコープは、現在のリクエストより長期間、マネージドBeanが存続する必要がない場合に使用します。

backingBean

バッキングBeanは、JSFページ上のUIコンポーネントのアクセッサとイベント処理コードを保存するマネージドBeanの記述規則です。リクエストが終了するまで存続するもので、状態の維持には使用しないでください。

タスク・フローが同じJSFページの複数のADFリージョンに表示される可能性がある場合に、ADFリージョンの各インスタンスを分離するために使用します。

複数のタスク・フローの存在するシナリオでは、各マネージドBeanに一意の名前を割り当てる命名規則を使用することを検討してください。このアプローチを使用すると、異なるタスク・フローから同じ名前を持つ2つのマネージドBeanをbackingBeanスコープに入れてしまうことを防げます。

タスク・フローでマネージドBeanを定義すると、JDeveloperではタスク・フローのソース・ファイル内にある次のようなエントリが生成されます。

<managed-bean id="__15">
<managed-bean-name id="__16">egBackingBean</managed-bean-name>
<managed-bean-class id="__13">oracle....egBackingBean</managed-bean-class>
<managed-bean-scope id="__14">backingBean</managed-bean-scope>
</managed-bean>

<managed-bean-scope>要素には、マネージドBeanのスコープの値(例ではbackingBean)が含まれています。

UIコンポーネントをマネージドBeanにバインドすると、JDeveloperはマネージドBeanの参照用に生成するEL式のスコープ名にScopeを付加します。たとえば、マネージドBeanを参照する表コンポーネントのバインド属性には次のEL式があります。

<af:table id="cartTab"
...
binding="#{backingBeanScope.egBackingBean.table}"
...
</af:table>

UIコンポーネントのバインド属性で参照するマネージドBeanのスコープを、backingBeanまたはリクエスト・スコープに限定します。UIコンポーネントのインスタンスはシリアライズできません。backingBeanとリクエスト以外のスコープのオブジェクトは、シリアライズ可能と考えられています。そのため、backingBeanまたはリクエスト以外のスコープのマネージドBeanに、UIコンポーネントをバインドしてはなりません。JDeveloperでは、UIコンポーネントのバインディング属性およびリージョン・フラグメントが、backingBeanスコープを使用するようにデフォルト設定されています。

注意:

Oracle ADF固有のカスタム・スコープ(pageFlow、backingBean、ビュー・スコープなど)にアクセスするEL式を記述する場合、アクセスするスコープを明示的に指定するEL式を記述します。たとえばpageFlowスコープにアクセスするEL式は次のように記述します。

#{pageFlowScope.inpTxtBB.uiComponent}

23.2.5 タスク・フローのソース・ファイルに関する必知事項

単一のアプリケーションで、複数のバインドなしタスク・フローXMLソース・ファイルと複数のバインド・タスク・フローXMLソース・ファイルを持つことができます。バインドなしタスク・フローの生成のために組み合せたファイル・セットは、アプリケーションのADFコントローラ・ブートストラップ構成ファイルと呼ばれています。バインドなしタスク・フローは、1つ以上のADFコントローラ・ブートストラップ構成ファイルを組み合せて、実行時にアセンブルされます。バインド・タスク・フロー内に含まれないブートストラップ構成ファイルのすべてのアクティビティは、バインドなしタスク・フロー内にあるとみなされます。

1つのアプリケーション内のソース・ファイル名は、異なる名前である必要があります。図23-11の例には、2つのバインドなしタスク・フロー(adfc-config、adfc-config1)と、1つのバインド・タスク・フロー(task-flow-definition)があります。

図23-11 バインドなしタスク・フローXMLソース・ファイルのあるアプリケーション

23.3 タスク・フローへのアクティビティの追加

タスク・フローの作成後、タスク・フローにアクティビティを追加し、アクティビティ間の制御フローを構成します。「コンポーネント」ウィンドウに、使用可能なアクティビティおよび制御フローが表示されます。「コンポーネント」ウィンドウからタスク・フロー・ダイアグラムに、アクティビティおよび制御フローをドラッグ・アンド・ドロップします。次にアクティビティ間の制御フローを構成し、タスク・フローが必要なタスクを実行できるようにします。

23.3.1 タスク・フローにアクティビティを追加する方法

タスク・フローを作成すると、タスク・フロー・ダイアグラムと「コンポーネント」が自動的に表示されます。タスク・フロー・ダイアグラムはビジュアル・エディタであり、そこでタスク・フローのアクティビティおよび制御フローを追加できます。「コンポーネント」からそれらをドラッグして、ダイアグラムに追加できます。

始める前に:

タスク・フローに追加可能なアクティビティを理解しておくと役に立つ場合があります。詳細は、「タスク・フローへのアクティビティの追加」を参照してください。

また、他のOracle ADF機能を使用してタスク・フローに追加可能な機能について理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

タスク・フローにアクティビティを追加するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、アクティビティを追加するタスク・フローをダブルクリックします。

たとえば、図23-12はタスク・フロー・ソース・ファイル(task-flow-definition.xml)をダブルクリックすると自動的に表示されるエディタおよび「コンポーネント」ウィンドウを示します。

図23-12 タスク・フロー・ダイアグラム

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、アクティビティをドラッグして、ダイアグラムへドロップします。

- ダイアグラム上にビュー・アクティビティをドラッグする場合は、そのアクティビティをダブルクリックすると、JSFページまたはページ・フラグメントの作成用ウィザードを表示できます。詳細は、「ビュー・アクティビティの使用方法」を参照してください。

- ダイアグラム上にタスク・フロー・アクティビティをドラッグすると、アクティビティをダブルクリックして、新しいバインド・タスク・フローの設定を定義できる「バインド・タスク・フローの作成」ウィザードを表示できます。詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。

ヒント:

タスク・フロー・ダイアグラムに各アクティビティをドラッグすると、アクティビティに関する追加情報を提供するオプションのステータス・アイコンとツールチップを表示できます。たとえば、タスク・フロー・ダイアグラムにビュー・アクティビティをドラッグすると、それをJSFページに関連付けるまで警告アイコンが表示されることがあります。

アイコンをオンにするには、タスク・フロー・ダイアグラムの上部にある「表示」を選択し、続いて「ステータス」と次のいずれかを選択します。

- エラー: タスク・フロー・メタデータの実行を妨げる問題がある場合に表示されます。たとえば、メタデータ内のビュー・アクティビティには<bookmark>または<redirect>要素を組み込めますが、両方を組み込むことはできません。

- 警告: タスク・フローの実行を妨げない問題がタスク・フロー・メタデータにある場合に表示されます。

- 不完全: アクティビティが不完全な場合に表示されます。たとえば、物理ページの関連付けが行われていないビュー・アクティビティ、またはタスク・フロー参照の関連付けがないタスク・フロー・コールは、ともに不完全なアクティビティとみなされます。その結果発生するタスク・フロー・メタデータは、実行が妨げられることがあります。

2次アイコンの上にマウスをドラッグすると、アイコンの意味を説明するツールチップを表示できます。

23.3.2 タスク・フローへのアクティビティ追加時の処理

図23-13に示すように、「コンポーネント」ウィンドウには、コンポーネントとダイアグラムの注釈用の別個のセクションがあります。「コンポーネント」セクションの内容は、作成対象がバインド・タスク・フローであるか、バインドなしタスク・フローであるかに応じて少し異なります。たとえば、バインド・タスク・フローを作成するときは、「コンポーネント」セクションに追加のタスク・フロー・リターン・アクティビティがあります。

図23-13には、バインドなしタスク・フローに追加可能なアクティビティが表示されています。

図23-13 バインドなしタスク・フローのアクティビティ

23.4 タスク・フローへの制御フロー・ルールの追加

ADFコントローラ制御フロー・ルールでは、タスク・フローで、あるアクティビティから次のアクティビティに制御を渡す方法が定義されています。制御フロー・ルールには、1つまたは複数の制御フロー・ケースを含めることができます。制御フロー・ケースでは、制御フローを渡すアクティビティが特定されます。また、制御ケースでは、オプションで、条件付きナビゲーション(<if>要素を使用)、または制御フローの発生元から取得したアクション値に基づく制限ナビゲーション(from-action要素を使用)を構成できます。

ADF Controller制御フロー・ルールは、JSFナビゲーション・ルールに基づきますが、その他の情報を取得します。JSFナビゲーションは常にページ間のものですが、制御フロー・ルールはアクティビティ間の遷移を示します。たとえば、制御フロー・ルールは、ビュー・アクティビティとそれ以降のメソッド・コール・アクティビティ間の遷移を示します。または、そのページ(ビュー・アクティビティ)から別のタスク・フローに制御を渡すように指定できます。

次のタスク・フロー・アクティビティは、制御フロー・ルールのソースになることはありません。

- セーブポイント・リストア

- タスク・フロー・リターン

- URLビュー

制御フロー・ルールの基本構造は、JSFナビゲーション・ルールを模倣したものです。表23-5には、JSFナビゲーション・ルールからADFコントローラ制御フロー・ルールへのメタデータのマップ方法が示されています。

表23-5 JSFナビゲーション・ルールからADFコントローラ制御フロー・ルールへのマッピング

JSFナビゲーション・ルール

ADFコントローラ制御フロー・ルール

ナビゲーション・ルール

制御フロー・ルール

ビューID(自)

アクティビティID(自)

ナビゲーション・ケース

制御フロー・ケース

アクション(自)

アクション(自)

結果(自)

結果(自)

条件

条件

ビューID(至)

アクティビティID(至)

ADFタスク・フローの使用時、faces-config.xmlファイルのJSFナビゲーション・ルールを使用するかわりに、ADFコントローラ制御フロー・ルールを使用してすべてのアプリケーション・ナビゲーションを実行します。ADFコントローラは、メタデータ内に一致する制御フロー・ケースが見つからない場合はナビゲーション処理を委譲します。ただし、ADF以外のコントローラのナビゲーション・ハンドラによってナビゲーションが実行された場合は、すべてのADFコントローラ機能の正常動作が保証されるとは限りません。ADFコントローラによる制御フロー・ルールの評価方法の詳細は、「実行時に行われる処理: タスク・フローで制御フロー・ルールを評価する方法」を参照してください。

アクティビティ間の基本的な制御フロー作成の開始ポイントとして、タスク・フロー・ダイアグラムを使用します。その後、タスク・フロー・ダイアグラムの「構造」ウィンドウ、「プロパティ」ウィンドウまたは概要エディタで制御フロー・プロパティを編集できます。

ヒント:

アクティビティを既存の制御フローにドラッグ・アンド・ドロップできます。これによって既存の制御フローが、アクティビティを中心として2つに分割されます。

23.4.1 タスク・フローに制御フロー・ルールを追加する方法

制御フロー・ルールを作成するには、「コンポーネント」ウィンドウの「ADFタスク・フロー」ページから「制御フロー・ケース」をソース・タスク・フロー・アクティビティおよびターゲット・タスク・フロー・アクティビティにドラッグ・アンド・ドロップします。

始める前に:

タスク・フロー・ルールの内容を理解しておくと有効な場合があります。詳細は、「タスク・フローへの制御フロー・ルールの追加」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

制御フロー・ルールをタスク・フローに追加するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、制御フロー・ルールを追加するタスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「制御フロー」グループから、「制御フロー・ケース」を選択します。

3. ダイアグラム上で、ソースとなるタスク・フロー・アクティビティをクリックしてから、ターゲットとなるタスク・フロー・アクティビティをクリックします。

多くの場合、ソースおよびターゲットとなるタスク・フロー・アクティビティはビュー・アクティビティです。図23-14では、2つのそのようなタスク・フロー・アクティビティ(view1およびview2)は、制御フロー・ケースにリンクされています。

図23-14 制御フロー・ケース

ダイアグラムに制御フロー・ケースが追加されます。JDeveloperによってタスク・フロー・アクティビティ間に追加された各行は制御フロー・ケースを表します。矢印は、制御フロー・ケースの方向を示します。「結果(自)」要素には、UIコンポーネントのaction属性で指定された値に一致する可能性がある値が含まれています。

4. From Outcomeの値を変更するには、ダイアグラム内の制御フローの横にあるテキストを選択し、デフォルトのワイルドカード文字(*)を上書きします。

便利な規則は、制御フロー・ルールをtoDestinationの形式または制御フロー・ルールの目的を表すその他の形式でキャストすることです。たとえば、図23-14に示す制御フローを定義するには、ワイルドカードをtoView2で上書きします。

5. 「アクティビティID(自)」(ソース・アクティビティを識別する)または「アクティビティID(至)」(ターゲット・アクティビティを識別する)の値を変更するには、ダイアグラム内で矢印の端のいずれかをドラッグして、新規のアクティビティまで移動します。

ヒント:

タスク・フロー・ダイアグラムの制御フローを選択すると、「プロパティ」ウィンドウや「構造」ウィンドウでそのプロパティを変更することもできます。「構造」ウィンドウは、制御ルールとケースの間の関連の表示に役立ちます。

また、タスク・フロー・ダイアグラムの概要エディタの「制御フロー」をクリックしてケースを追加することもできます(図23-15を参照)。ケースを追加するには、ルールの「アクティビティ(自)」(ソース・アクティビティ)および「アクティビティ(至)」(ターゲット・アクティビティ)がタスク・フローに追加されていることを確認します。

図23-15 タスク・フローの概要エディタの制御フロー

6. オプションとして、「プロパティ」ウィンドウでは、「動作」セクションを開いて、値がtrueになる必要がある、「If」フィールド内のEL式を記述した後に、「アクティビティID(至)」によって識別されたアクティビティに制御を渡すことができます。

23.4.2 ワイルドカード制御フロー・ルールの追加方法

バインドなしまたはバインド・タスク・フローにワイルドカード制御フロー・ルールを追加できます。追加の手順は、タスク・フロー・ダイアグラムへのアクティビティの追加の手順とほぼ同じです。

始める前に:

使用可能な制御フロー・ルールのオプションを理解しておくと有効な場合があります。詳細は、「タスク・フローへの制御フロー・ルールの追加」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

ワイルドカード制御フロー・ルールを追加するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、ワイルドカード制御フロー・ルールを追加するタスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「制御フロー」グループから、「ワイルドカード制御フロー・ルール」をドラッグして、ダイアグラムへドロップします。

3. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「制御フロー」グループから、「制御フロー・ケース」を選択します。

4. タスク・フロー・ダイアグラムで、制御フロー・ケースをワイルドカード制御フロー・ルールからターゲット・アクティビティにドラッグします。

ターゲットはどのアクティビティ・タイプでもかまいません。

5. デフォルトでは、ワイルドカード制御フロー・ルールの後のラベルは*です。これは、「アクティビティID(自)」要素の値です。この値を変更するには、ダイアグラムでワイルドカード制御フロー・ルールを選択します。ワイルドカード制御フロー・ルールの「プロパティ」ウィンドウで、 「アクティビティID(自)」フィールドに新しい値を入力します。便利な規則は、ワイルドカード制御フロー・ルールをその目的を表す形式でキャストすることです。たとえば、project*と入力します。新しいラベルでは、ワイルドカードは後続の文字である必要があります。

ヒント:

タスク・フロー・ダイアグラムの概要エディタにある「アクティビティID(自)」の値も変更できます。

6. オプションとして、「プロパティ」ウィンドウでは、「動作」セクションを開いて、値がtrueになる必要がある、「If」フィールド内のEL式を記述した後に、「アクティビティID(至)」によって識別されたアクティビティに制御を渡すことができます。

23.4.3 制御フロー・ルールの作成時の処理

タスク・フローのソース・ファイルのルールを定義する要素を理解すると、タスク・フロー・ダイアグラム、タスク・フローの概要エディタまたは「構造」ウィンドウで制御フロー・ルールを直接作成する際、あるいは制御フロー・ルールをXMLソース・ファイルに直接追加する際に役に立ちます。例23-3に、タスク・フロー・ソース・ファイルの制御フロー・ルール要素の一般的な構文を示します。

制御フロー・ルールは、次のメタデータで構成されます。

- control-flow-rule: 制御フロー・ケース要素の必須ラッパー要素。

- from-activity-id: 制御フロー・ルールの発生元となるアクティビティの識別子(sourceなど)。
from-activity-idの後方ワイルドカード(*)文字がサポートされています。ルールは、ワイルドカードのパターンに一致するすべてのアクティビティに適用されます。たとえば、login*は、リテラルloginで始まるすべての論理アクティビティID名と一致します。メタデータに(後方ワイルドカードではなく)単一のワイルドカード文字を指定すると、ダイアグラムで、制御フローが自動的にワイルドカード制御フロー・ルール・アクティビティに変換されます。詳細は、「ワイルドカード制御フロー・ルールの追加方法」を参照してください。

- control-flow-case: 制御フロー・ルールの各ケースの必須ラッパー要素。それぞれのケースで、同じソース・アクティビティに対して異なる制御フローを定義します。制御フロー・ルールには、少なくとも1つの制御フロー・ケースが必要です。

- from-action: 指定されたアクション・メソッドからの結果のみにルールの適用を制限する任意の要素。アクション・メソッドは、ELバインディング式(#{backing_bean.cancelButton_action}など)として指定されます。
例23-3では、outcomeがactionmethodから返された場合にのみ制御がdestinationActivityに渡されます。

from-actionの値は、ビュー・アクティビティから発生する制御フローのみに適用され、その他のアクティビティ・タイプからのものには適用されません。from-actionでは、ワイルドカードはサポートされていません。

- from-outcome: 特定の元のアクティビティ結果に基づき、続いて起こる制御フロー・ケースを識別する要素。考えられるすべての元のアクティビティの結果は、制御フロー・ケースと適合する必要があります。
from-action要素とfrom-outcome要素の両方を空のままにすると、ケースはアクティビティに対して定義されたその他の制御フロー・ケースでは識別されないすべての結果に適用されるため、アクティビティのデフォルト・ケースが作成されます。from-outcomeでは、ワイルドカードはサポートされていません。

- to-activity-id: 制御フロー・ケースが実行される場合にナビゲーションのルーティング先となるアクティビティの完全な識別子が含まれる必須要素。各制御フロー・ケースは、異なるto-activity-idを指定できます。

- if: EL式の値を受け取るオプション要素です。実行時にEL式の値がtrueの場合は、to-activity-id要素によって識別されたアクティビティに制御フローを渡します。

例23-3 ソース・ファイルの制御フロー・ルールの構文

<control-flow-rule>
<from-activity-id>from-view-activity</from-activity-id>
<control-flow-case>
<from-action>actionmethod</from-action>
<from-outcome>outcome</from-outcome>
<to-activity-id>destinationActivity</to-activity-id>
<if>#{myBean.someCondition}</if>
</control-flow-case>
<control-flow-case>
....
</control_flow-case>
</control-flow-rule>

23.4.4 実行時に行われる処理: タスク・フローで制御フロー・ルールを評価する方法

実行時、タスク・フローは、最も具体的な一致から最も具体的でない一致まで制御フロー・ルールを評価して、アクティビティ間の次の遷移を決定します。評価は次の優先度に基づきますが、これはJSFナビゲーション・ルールと類似しています。

1. from-activity-id、from-action、from-outcome

2. from-activity-id、from-outcome

3. from-activity-id

ADFコントローラは、最初にfrom-activity-id、from-action、from-outcomeの3つの要素すべての一致を検索します。一致がない場合は、from-activity-idおよびfrom-outcome要素のみの一致を検索します。最後に、from-activity-id要素のみの一致を検索します。

ADFコントローラのメタデータ内でリクエストと一致する制御フロー・ルールを検出できない場合は、標準JSFナビゲーション・ハンドラによる一致の検出が許可されます。

バインドなしタスク・フローには、複数のADFコントローラXMLソース・ファイルを含めることができます。複数のADFコントローラXMLソース・ファイルに制御フロー・ルールを定義できるため、似たようなルールが異なるファイルに定義される場合もあります。2つ以上のケースに同じfrom-activity-id、from-actionまたはfrom-outcomeの値が存在するといった競合がある場合は、(adfc-config.xml、ブートストラップまたはバインド・タスク・フローのソース・ファイルで記述される順序で)最後のケースが使用されます。異なるソース・ファイルに定義されたルール間で競合がある場合は、最後にロードされるソース・ファイルのルールが使用されます。

また、ADFコントローラには、次の複数の制限を使用して次のインタフェースを実装します。

javax.faces.application.ConfigurableNavigationHandler

制限は次のとおりです。

- getNavigationCases()によって返されたMapオブジェクトは変更できません。制御フロー・ルールを実行時に変更するには、必ずMDSフレームワークを実装したカスタマイズ機能で実行される必要があります。詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。

- JSFアプリケーション起動フェーズ後は、performNavigation()メソッドを起動してはいけません。これは、ADFレンダリング準備フェーズとJSFレスポンス・レンダリング・フェーズとの間でビューIDが変更されていないことを確認するためです。ページ・リクエストのライフサイクルでのJSFフェーズとADFフェーズの統合方法の詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。

- タスク・フロー・ビュー・アクティビティのブックマークおよびリダイレクトのプロパティに対するメタデータの値には、getNavigationCases()によって返されるナビゲーション・ケース・オブジェクトに対応する情報が移入されます。

23.5 タスク・フローのテスト

タスク・フローを実行してデバッグするプロシージャは、タスク・フローがバインドかバインドなしか、ページまたはページ・フラグメントのどちらを含んでいるか、入力パラメータを受け入れるかどうかに応じて異なります。

JDeveloperおよびOracle ADFには、作成したタスク・フローのテストに役立つ多くの機能があります。その1つとして、タスク・フロー・アクティビティにADF宣言ブレークポイントを設定する機能があります。詳細は、「タスク・フロー・アクティビティ・ブレークポイントの設定方法および使用方法」を参照してください。また、統合WebLogic Serverで現在実行されているアプリケーションのタスク・フローのメタデータを変更することもできます。タスク・フローに対する変更をアプリケーションにデプロイする作業は、アプリケーションを停止し、統合WebLogic Serverに再デプロイしなくても実行できます(ホット・リロードとも呼ばれます)。これを行うには、変更されたタスク・フロー上で作成用のコマンドを起動します(タスク・フローを右クリックし、「メイク」を選択します)。これにより、変更されたタスク・フローが統合WebLogic Serverで実行中のアプリケーションにデプロイされます。ホット・リロードの詳細は、「統合WebLogic ServerのOracle ADFのメタデータのリロード」を参照してください。

アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

23.5.1 ページを含むバインド・タスク・フローの実行方法

ページであるビュー・アクティビティを含むバインド・タスク・フローを実行またはデバッグできます。

ページ・フラグメントであるビュー・アクティビティを含むバインド・タスク・フローの実行方法の詳細は、「ページ・フラグメントを使用するバインド・タスク・フローの実行方法」を参照してください。

始める前に:

タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

ページを使用するバインド・タスク・フローを実行またはデバッグするには:

- タスク・フロー・ダイアグラムで、タスク・フローを右クリックし、「実行」または「デバッグ」を選択します。

- ブラウザにURLを入力してタスク・フローを直接実行することもできます。次に例を示します。
http://somecompany.com/internalApp/MyApp/faces/adf.task-flow?adf.tfId=displayHelp&adf.tfDoc=%2FWEB-INF%2Fdisplayhelp.xml&topic=createPurchaseOrder

詳細は、「URLを使用したバインド・タスク・フローのコールに関する必知事項」を参照してください。

- 「アプリケーション」ウィンドウで、WEB-INFノードを開き、バインド・タスク・フローを右クリックして、「実行」または「デバッグ」を選択します。

23.5.2 ページ・フラグメントを使用するバインド・タスク・フローの実行方法

ページ・フラグメントを使用するバインド・タスク・フローは、ADFリージョン内でのみ実行することを目的としています。ページ・フラグメントは、別のJSFページのコンテンツとしてレンダリングされるJSFドキュメントです。詳細は、「ページ・フラグメントおよびADFリージョンについて」を参照してください。

始める前に:

タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. バインド・タスク・フローにバインドされたリージョンのあるJSFページを作成します。ページ・フラグメントを含むバインド・タスク・フローをページ上にドロップすると、JDeveloperではJSFページに使用するリージョンが自動作成されます。リージョン作成の詳細は、「ADFリージョンの作成」を参照してください。

2. ページを参照するプロジェクトのバインドなしタスク・フローにビュー・アクティビティを作成します。詳細は、「タスク・フローにアクティビティを追加する方法」を参照してください。

ページ・フラグメントを使用するバインド・タスク・フローを実行またはデバッグするには:

- 「アプリケーション」ウィンドウまたはタスク・フロー・ダイアグラムでビュー・アクティビティを右クリックし、「実行」を選択します。

23.5.3 パラメータのあるバインド・タスク・フローの実行方法

パラメータのあるバインド・タスク・フローを実行する前に、ページを含むバインド・タスク・フローを実行する必要があります。詳細は、「ページ・フラグメントを使用するバインド・タスク・フローの実行方法」を参照してください。

入力パラメータが定義されたバインド・タスク・フローを実行またはデバッグしようとすると、図23-16に示すように、「実行構成の設定」ダイアログが表示されます。このダイアログで、バインド・タスク・フローに渡す値を入力し、「OK」をクリックします。バインド・タスク・フローに入力パラメータを定義する方法の詳細は、「タスク・フローのパラメータの使用」を参照してください。

図23-16 「実行構成の設定」ダイアログ

始める前に:

タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

入力パラメータ定義を含むバインド・タスク・フローを実行またはデバッグするには:

1. バインド・タスク・フローのダイアグラムで、タスク・フローを右クリックし、「実行」または「デバッグ」を選択します。

2. 「実行構成の設定」ダイアログの「入力パラメータ」リストで、タスク・フローに入力パラメータとして渡す値を入力します。値を指定しない場合は、バインド・タスク・フローのコール時、入力パラメータは使用されません。

図23-16に示すように、リストのそれぞれの必須入力パラメータはアスタリスク付きで表示されます。パラメータ値はリテラル文字列として指定する必要があります。EL式は指定できません。

3. 「OK」をクリックします。

23.5.4 タスク・フローのテスト時にJSFページを実行する方法

JSFページは、「アプリケーション」ウィンドウでページを右クリックし、「実行」を選択して実行できます。ただし、ボタンやリンクなどのナビゲーションUIコンポーネントがページに含まれている場合は、ナビゲーションが機能する保証はありません。

始める前に:

タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. バインド・タスク・フローまたはバインドなしタスク・フローを作成します。
詳細は、「タスク・フローの作成方法」を参照してください。

2. タスク・フローにビュー・アクティビティを追加します。
詳細は、「タスク・フローにアクティビティを追加する方法」を参照してください。

ナビゲーションを完全に機能させてJSFページを実行するには:

1. 「アプリケーション」ウィンドウで、実行するJSFページをドラッグして、タスク・フロー・ダイアグラムのビュー・アクティビティ上にドロップします。

これにより、JSFページがビュー・アクティビティと関連付けられます。

2. ダイアグラムでビュー・アクティビティを右クリックし、「実行」を選択します。

23.5.5 バインドなしタスク・フローの実行方法

バインドなしタスク・フローを実行またはデバッグするには、バインドなしタスク・フローの起動に使用する特定のビュー・アクティビティを選択します。

始める前に:

タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

バインドなしタスク・フローでビュー・アクティビティを実行するには:

- タスク・フロー・ダイアグラムで、ビュー・アクティビティを右クリックし、「実行」または「デバッグ」を選択します。
選択したビュー・アクティビティからバインドなしタスク・フローが実行されます。

- 単一のビュー・アクティビティ以外を選択している(あるいは何も選択していない)場合、「実行構成の設定」ダイアログで1つ選択するように求められます。

23.5.6 プロジェクトの実行構成を設定する方法

実行構成には、タスク・フローで実行する最初のアクティビティなど、プロジェクトの実行方法を決定する設定が含まれます。1つのプロジェクトに対して1つ以上の実行構成を定義できます。実行構成内では、デフォルトの実行ターゲットとしてADFコントローラのソース・ファイルを指定できます。プロジェクトを実行すると、ソース・ファイルが最初に実行されます。

始める前に:

タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

デフォルトのタスク・フロー実行ターゲットを定義するには:

1. 「アプリケーション」ウィンドウで、デフォルトのタスク・フロー実行ターゲットを定義するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「実行/デバッグ」を選択し、「実行構成」リストで「新規」をクリックします。

3. 「実行構成の作成」ダイアログで、新規の実行構成の名前を入力します。

4. 既存の構成に基づいて新規の構成を作成する場合は、「設定のコピー元」ドロップダウン・リストで構成を選択します。

5. 「OK」をクリックして、「実行構成の作成」ダイアログを終了します。

6. 「実行構成」リストで、「編集」を選択します。

7. 「実行構成の編集」ダイアログの「デフォルトの実行ターゲット」フィールドで、プロジェクトの実行時に最初に実行する必要があるタスク・フローのソース・ファイルを指定します。

タスク・フローを選択すると、(バインドなしタスク・フロー用の)ビュー・アクティビティまたは(バインド・タスク・フロー用の)入力パラメータを設定できます。

8. 「実行構成の編集」ダイアログの左側のパネルで、「ADFタスク・フロー」をクリックします。

9. 右側のパネルにある「タスク・フロー」ドロップダウン・リストで、実行ターゲットを含むタスク・フローを選択します。

10. バインドなしタスク・フローを実行している場合、図23-17に示すように、「実行構成の編集」ダイアログに「ビュー・アクティビティ」ドロップダウン・リストが表示され、ここからアプリケーションで最初に実行するビュー・アクティビティを選択します。

図23-17 「実行構成の編集」ダイアログ

11. 「OK」をクリックします。

次にプロジェクトを実行する際、保存された実行構成が「実行」→「アクティブな実行構成を選択」メニューで使用できるようになります。

入力パラメータを受け付ける用に設定されたバインド・タスク・フローを実行している場合は、バインド・タスク・フロー用に定義されたすべての入力パラメータの値を指定するセクションがダイアログに表示されます。詳細は、「パラメータのあるバインド・タスク・フローの実行方法」を参照してください。

23.5.7 実行時に行われる処理: タスク・フローのテスト

タスク・フローのテスト時に確認される動作は、様々な要素によって異なる場合があります。たとえば、入力パラメータが定義されたバインド・タスク・フローを実行またはデバッグしようとすると、「実行構成の設定」ダイアログが表示されます。また、JDeveloperの本インストールでアプリケーションを初めてテストしようとする場合は、統合WebLogic Serverで新しいドメインを開始できるように、「デフォルト・ドメインの作成」ダイアログが表示されます。

23.6 新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ

既存のアクティビティ、JSFページ・フローおよびJSFページを、新規のADFコントローラ・コンポーネント(バインド・タスク・フローおよびタスク・フロー・テンプレートなど)に変換できます。

23.6.1 既存のタスク・フローからバインド・タスク・フローを抽出する方法

新規のバインド・タスク・フローは、既存のバインドまたはバインドなしタスク・フローで選択したアクティビティに基づいて作成できます。

始める前に:

タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

既存のタスク・フローからバインド・タスク・フローを抽出するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、新規バインド・タスク・フローへの抽出が必要なアクティビティを含む、バインドなしタスク・フローまたはバインド・タスク・フローをダブルクリックします。

2. タスク・フロー・ダイアグラムで1つ以上のアクティビティを選択します。

ヒント:

ダイアグラムで複数のアクティビティを選択するには、マウスの左ボタンをクリックしたまま、アクティビティの上にカーソルをドラッグします。

[Ctrl]キーを押しながらそれぞれのアクティビティを選択することもできます。

3. 選択したものを右クリックして、「タスク・フローの抽出」を選択します。

4. 「バインド・タスク・フローの抽出」ダイアログで、新規バインド・タスク・フローのファイル名を入力し、それを格納するディレクトリの名前を入力します。

バインド・タスク・フローの作成の詳細は、「タスク・フローの作成」を参照してください。

23.6.2 既存のタスク・フローからのバインド・タスク・フローの抽出時に行われる処理

タスク・フロー・ダイアグラムに抽出する新規のバインド・タスク・フローが表示されます。表23-6は、JDeveloperにより自動設定される、新規のバインド・タスク・フローのプロパティについて説明しています。

表23-6 新規バインド・タスク・フローで更新されるプロパティ

プロパティ

値

タスク・フロー定義ID

「バインド・タスク・フローの抽出」ダイアログの「ファイル名」フィールドに入力した値です。

デフォルト・アクティビティ

すべての受信制御フロー・ケースのターゲットとして指定。複数のターゲットが存在する場合、エラーのフラグが立てられ、操作全体がロールバックされます。

制御フロー・ルール

選択されたソース・アクティビティのある制御フロー・ケースは、新規のバインド・タスクに組み込まれます。ソース・アクティビティは、制御フローの発生元のアクティビティです。新規のバインド・タスク・フローには、次のタイプの制御フロー・ケースがあります。

- 制御フロー・ケースのソース・アクティビティとターゲット・アクティビティの両方が、新規タスク・フローの作成のために選択されています。

- ソース・アクティビティのみが新規タスク・フローの作成のために選択されています。ターゲットは、それぞれの結果に応じて追加された、対応する新規タスク・フロー・リターン・アクティビティに変更されます。

元のタスク・フロー(新規タスク・フローの基礎として選択したアクティビティを含むタスク・フロー)で次のような変更が自動的に実行されます。

- 新規タスク・フロー・コール・アクティビティが、元のタスク・フローに追加されます。タスク・フロー・コール・アクティビティは、新規のバインド・タスク・フローをコールします。

- 選択されたアクティビティが元のタスク・フローから削除されます。

- 選択したアクティビティに関連付けられた既存の制御フロー・ケースが、元のタスク・フローから削除されます。これは新規の制御フロー・ケースに置き換えられます。

- 古いアクティビティに対する受信制御フロー・ケースは、新規タスク・フロー・コール・アクティビティにリダイレクトされます。

- 古いアクティビティからの送信制御フロー・ケースは、新規タスク・フロー・コール・アクティビティからリダイレクトされます。

23.6.3 JSFページからのタスク・フローの作成方法

JSFページ・フローで選択したページに基づいて、新規のバインド・タスク・フローを作成できます。JDeveloperでは、フローの一部であるJSFページ(つまり、JSFナビゲーション・ケースによってリンクされたページ)が新規タスク・フローのビュー・アクティビティに変換されます。

始める前に:

タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

ページ・フローで選択したJSFページから新規のタスク・フローを作成するには:

1. 「アプリケーション」ウィンドウで、新規バインド・タスク・フローで使用するページを含むページ・フローをダブルクリックします。

2. タスク・フロー・ダイアグラムで1つ以上のJSFページを選択します。

ヒント:

ダイアグラムで複数の要素を選択するには、マウスの左ボタンをクリックしたまま、要素の上にカーソルをドラッグします。

[Ctrl]キーを押しながらそれぞれの要素を選択することもできます。

3. 選択したものを右クリックして、「ADFタスク・フローの生成」を選択します。

「タスク・フローの作成」ダイアログが表示され、新規のバインドなしタスク・フローまたはバインド・タスク・フローを作成できます。

4. 「タスク・フローの作成」ダイアログで、タスク・フローのファイル名とディレクトリを入力します。バインドなしタスク・フローを作成する場合は、「バインド・タスクとして作成」チェック・ボックスの選択を解除します。

詳細は、「タスク・フローの作成」を参照してください。

5. 「OK」をクリックします。

23.6.4 バインド・タスク・フローの変換方法

既存のバインド・タスク・フローをバインドなしタスク・フローに変換したり、そこに含まれるビューがページまたはページ・フラグメントのいずれかを変更できます。表23-7に、それぞれの変換結果を示します。

表23-7 バインド・タスク・フローの変換

変換

結果

バインド・タスク・フローからバインドなしタスク・フローへの変換

パラメータ定義やトランザクションなど、バインドなしタスク・フローに対して無効なすべてのメタデータが失われます。

JSFページを使用するためのバインド・タスク・フローの変換

タスク・フロー内の任意のビュー・アクティビティに関連付けられたページ・フラグメントをJSFページに変換します。「ページ・フラグメントを保持」チェックボックスを選択している場合、古いページ・フラグメントは保存されます。新規のJSFページ名は、デフォルトで古いページ・フラグメント名になります。

ページ・フラグメントを使用するためのバインド・タスク・フローの変換

バインド・タスク・フロー内のビュー・アクティビティに関連付けられたすべてのページをページ・フラグメントに変換します。「ページを保持」チェックボックスを選択している場合、古いページは保存されます。新規のページ・フラグメント名は、デフォルトで古いページ名になります。

始める前に:

タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。

バインド・タスク・フローを変換するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、変換が必要なバインド・タスク・フローをダブルクリックします。

2. タスク・フロー・ダイアグラムで、アクティビティまたは制御フロー以外の任意の場所を右クリックします。

3. 次の適切なメニュー・オプションを選択します。

- バインドなしタスク・フローへの変換

- ページ・フラグメントを含むタスク・フローへの変換

- ページを含むタスク・フローへの変換

24 タスク・フロー・アクティビティの使用

この章では、Fusion Webアプリケーションで作成するADFタスク・フローでアクティビティを使用する方法について説明します。この章には、「コンポーネント」ウィンドウに表示される各タスク・フロー・アクティビティ・タイプの詳細な説明とともに、各タスク・フロー・アクティビティ・タイプに構成するプロパティの説明が含まれます。

この章の内容は次のとおりです。

- タスク・フロー・アクティビティについて

- ビュー・アクティビティの使用方法

- URLビュー・アクティビティの使用

- ルーター・アクティビティの使用方法

- メソッド・コール・アクティビティの使用

- タスク・フロー・コール・アクティビティの使用

- タスク・フロー・リターン・アクティビティの使用

- ページ定義ファイルのあるタスク・フロー・アクティビティの使用

24.1 タスク・フロー・アクティビティについて

アクティビティとは、タスク・フローの実行時に行われる作業を意味しています。これは、タスク・フローのダイアグラム・エディタにノードとして表示されます。ほとんどのアクティビティはバインド・タスク・フローとバインドなしタスク・フローの両方に追加できますが、アクティビティ・タイプによってはバインド・タスク・フローにのみ追加できるものもあります。

図24-1は、ADFタスク・フローのSummitサンプル・アプリケーションから、emp-reg-task-flow-definition.xmlバインド・タスク・フローを示しています。このタスク・フローには次のアクティビティが含まれます。

1. CreateInsertアクションを起動するメソッド・コール・アクティビティ

2. エンド・ユーザーが作成される従業員についての一般情報を入力できるページ・フラグメントをレンダリングするビュー・アクティビティ

3. エンド・ユーザーが正常に新規の従業員を作成した場合に確認メッセージを表示するページ・フラグメントをレンダリングするビュー・アクティビティ

図24-1 タスク・フロー・アクティビティがあるバインド・タスク・フロー

タスク・フローは、アクティビティ、およびアクティビティ間の遷移を定義する制御フロー・ケースで構成されます。表24-1は、「コンポーネント」ウィンドウからドラッグ・アンド・ドロップすることで、タスク・フローに追加可能なアクティビティ・タイプと制御フローについて説明しています。

表24-1 タスク・フロー・アクティビティと制御フロー

アイコン

コンポーネント名

説明

メソッド・コール

メソッド(通常はマネージドBean上のメソッド)を起動します。メソッド・コール・アクティビティは、制御フロー・ルールに基づいてアプリケーション・ロジックを起動するために、アプリケーションの制御フロー内のどこにでも配置できます。詳細は、「メソッド・コール・アクティビティの使用」を参照してください。

親アクション

バインド・タスク・フローで親ビュー・アクティビティに渡される結果を生成できるようにします。通常、親ビュー・アクティビティのナビゲーションのトリガーを必要とするADFリージョンで実行するバインド・タスク・フローに使用されます。詳細は、「ADFリージョンのタスク・フロー外への移動」を参照してください。

ルーター

EL式を評価して、式の値に基づいて結果を返します。たとえば、クレジット・チェック・タスクフローでのルーターは前のメソッド・コールからの戻り値を評価し、様々なケースに基づいて成功、失敗または再試行の結果を生成します。その後、このような結果を使用して、タスク・フローの他のアクティビティに制御をルーティングします。詳細は、「ルーター・アクティビティの使用方法」を参照してください。

セーブポイント・リストア

後で使用するための保存の機能をサポートするアプリケーションで、アプリケーションの状態やデータなど、以前の永続保存ポイントをリストアします。セーブポイントでは、特定のインスタンスでFusion Webアプリケーションのスナップショットが取得されます。セーブポイント・リストア機能を使用すると、セーブポイントが最初に作成されたときに取得された状態までアプリケーションをリストアできます。詳細は、「タスク・フローでのセーブポイントの使用」を参照してください。

タスク・フロー・コール

バインドなしタスク・フローまたは別のバインド・タスク・フローからバインド・タスク・フローをコールします。詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。

タスク・フロー・リターン

バインド・タスク・フローが完了し、コール元に制御が戻されるタイミングを指定します。(バインド・タスク・フローでのみ利用可能)。詳細は、「タスク・フロー・リターン・アクティビティの使用」を参照してください。

URLビュー

ADFリージョンのコンテキスト内からでも、ルート・ビュー・ポート(ブラウザ・ページなど)をURLにアドレス可能なリソースにリダイレクトします。詳細は、「URLビュー・アクティビティの使用」を参照してください。

ビュー

JSFページまたはページ・フラグメントが表示されます。複数のビュー・アクティビティが同じページまたは同じページ・フラグメントを示すことができます。詳細は、「ビュー・アクティビティの使用方法」を参照してください。ページとページ・フラグメントの詳細は、「Webページの作成」を参照してください。

制御フロー・ケース

アプリケーション内で、あるアクティビティから次のアクティビティに制御を渡す方法を指定します。詳細は、「制御フローについて」を参照してください。

ワイルドカード制御フロー・ルール

IDがワイルドカード式と一致するアクティビティからの制御フロー・ケースを表します。たとえば、foo*などの後方ワイルドカードのある制御ケースfrom-activity-idを表すことができます。詳細は、「ワイルドカード制御フロー・ルールの追加方法」を参照してください。

表24-2に、タスク・フローに追加できる注釈(メモおよび添付ファイル)を示します。

表24-2 タスク・フロー・ダイアグラムの注釈

アイコン

アイコン名

説明

ノート

タスク・フロー・ダイアグラムに注釈を追加します。ダイアグラムでテキストを追加または編集するノートを選択します。

ノートの添付

ダイアグラムで既存のノートをアクティビティまたは制御フロー・ケースに添付します。

24.1.1 タスク・フロー・アクティビティのユース・ケースと例

図24-2には、Summit ADFタスク・フロー・サンプル・アプリケーションにある顧客タスク・フローのダイアグラムが示されています。このタスク・フローでは、タスク完了のためにバインド・タスク・フローが支援する多数のアクティビティが使用されています。Summit ADFサンプル・アプリケーションの詳細は、「ADFサンプル・アプリケーションの概要」を参照してください。

図24-2 Summit ADFタスク・フロー・サンプル・アプリケーション内の顧客タスク・フロー

24.1.2 タスク・フロー・アクティビティの追加機能

タスク・フロー・アクティビティを構成または使用する前に、他のOracle ADF機能を理解しておくことは有効だと思われます。さらに、構成後のタスク・フローで実行できる機能について読むことが必要な場合もあります。次に、関連する他の機能へのリンクを示します。

- タスク・フローはマネージドBeanを起動します。マネージドBeanの詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

- バインド・タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

- バインド・タスク・フローは、ADFライブラリJARにパッケージ化できます。詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。

- タスク・フロー・アクティビティは、ページ定義ファイルとの関連付けができます。ページ定義ファイルの詳細は、「ページ定義ファイルの処理」を参照してください。

24.2 ビュー・アクティビティの使用方法

タスク・フロー・アクティビティの主要なタイプの1つにビュー・アクティビティがあります。ビュー・アクティビティは、JSFページまたはページ・フラグメントに表示されます。ページ・フラグメントは、別のJSFページのコンテンツとしてレンダリングされるJSFドキュメントです。「ADFリージョンの作成」の説明のとおり、ページ・フラグメントは通常、リージョンとしてJSFページに追加可能なバインド・タスク・フローで使用されます。

図24-3には、Summit ADFタスク・フロー・サンプル・アプリケーションにあるindexビュー・アクティビティが示されています。

図24-3 ビュー・アクティビティ

ヒント:

ビュー・アクティビティの左上にある+アイコンをクリックして、参照したページまたはページ・フラグメントのサムネイル・プレビューを表示します。

タスク・フローのソース・ファイルにあるXMLメタデータでは、ビュー・アクティビティが物理JSFページまたはページ・フラグメントと関連付けられています。id属性ではビュー・アクティビティが識別されます。<page>要素では、ページまたはページ・フラグメントのファイル名が識別されます。次の例は、図24-3のビュー・アクティビティに対応するメタデータを示しています。

<view id="index">
<page>/index.jsf</page>
</view>

ビュー・アクティビティのIDとページ名は同じである必要はありません。

タスク・フローにビュー・アクティビティを追加する手順は、タスク・フロー・ダイアグラムへのどのアクティビティの追加手順とも同じです。詳細は、「タスク・フローにアクティビティを追加する方法」を参照してください。ビュー・アクティビティの追加後、それをダブルクリックしてウィザードを表示し、新しいページまたはページ・フラグメントを作成できます。ウィザードでは、作成したJSFページまたはページ・フラグメントで次の2つのドキュメント・タイプのうち1つを選択できます。

- Facelet
このドキュメント・タイプでのページのファイル拡張子は、ページ・フラグメントの.jsfおよび.jsffになります。

- JSP XML
このドキュメント・タイプでのページのファイル拡張子は、ページ・フラグメントの.jspxおよび.jsffになります。

タスク・フローではドキュメント・タイプを1つのみ使用します。たとえば、あるタスク・フローのビュー・アクティビティではFaceletsドキュメント・タイプを使用せず、別のタスク・フローのビュー・アクティビティではJSP XMLドキュメント・タイプを使用しません。ドキュメント・タイプの詳細は、「JSFによるユーザー・インタフェースの実装」を参照してください。

また、ウィザードを使用して、作成したページまたはページ・フラグメントのページ・レイアウトを選択します。ページ・レイアウトの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のクイック・スタート・レイアウトの使用に関する項を参照してください。さらに、マネージドBeanのページまたはページ・フラグメントでUIコンポーネントを自動的に公開するかどうかを指定できます。詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

ウィザードの完了後、JDeveloperでは、完成したページまたはページ・フラグメントがビュー・アクティビティと自動的に関連付けられます。ウィザードを使用しなくても、「アプリケーション」ウィンドウから既存のページまたはページ・フラグメントをドラッグし、既存のビュー・アクティビティ上にドロップすることで、ページまたはページ・フラグメントとビュー・アクティビティとの関連付けを実行できます。ビュー・アクティビティがない場合は、ページまたはページ・フラグメントをダイアグラム上のどこか他の場所にドラッグします。ページまたはページ・フラグメントをドロップすると、JDeveloperでは、ページまたはページ・フラグメントに関連付けられた新規のビュー・アクティビティが自動作成されます。作成時には、ページまたはページ・フラグメントの名前に基づいて、そのビュー・アクティビティのデフォルトのidが自動的に生成されます(例: index)。

24.2.1 ビュー・アクティビティ間の制御の受渡し

タスク・フローのビュー・アクティビティは、実行中に相互に制御を受け渡すように構成できます。たとえば、あるビュー・アクティビティ(ビュー・アクティビティA)から次のビュー・アクティビティ(ビュー・アクティビティB)に制御を渡すには、ビュー・アクティビティAと関連付けられたページ上にコマンド・コンポーネント(ボタンまたはリンク)を構成できます。コマンド・コンポーネントのAction属性を、起動が必要なタスク・フロー・アクティビティ(前述の例のビュー・アクティビティB)に相当する制御フロー・ケースのfrom-outcomeに設定します。実行時に、エンド・ユーザーは、コマンド・コンポーネントを起動することで制御フロー・ケースを初期化します。UIコンポーネントのAction属性の定数値または動的値のいずれかを使用して、あるビュー・アクティビティから別なアクティビティに移動できます。

図24-4に示すとおり、コンポーネントのAction属性の定数値はアクション結果で、同じ制御フロー・ケースを常にトリガーします。エンド・ユーザーがコンポーネントをクリックすると、その制御フロー・ケースに指定されているアクティビティが実行されます。代替の制御フローはありません。

図24-4 「属性の編集」ダイアログ

コンポーネントのAction属性の動的値はマネージドBeanまたはメソッドにバインドされます。メソッド・バインディングにより返される値によって、次に起動する制御フロー・ケースが決定されます。たとえば、メソッドはページ上でユーザー入力を検証し、入力が有効な場合はある値を返し、入力が無効な場合は別の値を返します。これらの異なるアクション値はそれぞれ別個のナビゲーション・ケースをトリガーするため、アプリケーションが移動可能なターゲット・ページは2つのいずれかになります。

また、ターゲット・ビュー・アクティビティに制御を渡す前に、値が必ずtrueになるEL式を記述できます。タスク・フローにある制御フロー・ケースの<if>子要素の値としてEL式を記述します。詳細は、「タスク・フローに制御フロー・ルールを追加する方法」を参照してください。

24.2.1.1 ビュー・アクティビティ間で制御を渡す方法

コマンド・コンポーネントのaction属性の値として、制御フロー・ケースのfrom-outcome属性の値を指定することで、ビュー・アクティビティに制御を渡します。

始める前に:

ビュー・アクティビティ間での制御の受渡しを構成する際に、利用可能なオプションを理解しておくと有効な場合があります。詳細は、「ビュー・アクティビティ間の制御の受渡し」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

次のタスクを完了する必要があります。

- エンド・ユーザーが実行時にコマンド・コンポーネントを起動した後に制御を受け取るターゲット・ビュー・アクティビティの作成

- エンド・ユーザーが実行時に起動したコマンド・コンポーネントをホストするJSFページの作成

ビュー・アクティビティに制御を渡すには:

1. 「アプリケーション」ウィンドウで、JSFページをダブルクリックします。

2. エディタ・ウィンドウで、次のオプションのいずれかを使用して、JSFページにUIコンポーネントを追加します。

- 「コンポーネント」ウィンドウの「ADF Faces」ページで、「一般コントロール」パネルからナビゲーションUIコンポーネント(ボタンやリンクなど)をドラッグして、ページ上にドロップします。

- 「データ・コントロール」パネルから、操作またはメソッドをJSFページにドラッグ・アンド・ドロップし、ポップアップ・メニューから「ADFボタン」または「ADFリンク」を選択します。

3. 「プロパティ」ウィンドウで、「共通」セクションを開き、「アクション」プロパティ・フィールドの上にカーソルを置いたときに表示されるアイコンから起動するドロップダウン・メニューで、「編集」を選択します。

4. 「プロパティの編集: アクション」ダイアログで、「アクション結果」を選択して、関連付けられたドロップダウン・リストから値を選択します。

リストには、ページに関連付けられているビュー・アクティビティに定義済の制御フロー・ケースが含まれています。

ヒント

UIコンポーネントのaction属性は、ナビゲーション・ケースをハードコードするリテラル文字列、または、引数なしでStringを戻すメソッドをポイントするメソッド・バインディング式のいずれかにバインドできます。その他のタイプのEL式にはバインドできません。

24.2.1.2 ビュー・アクティビティ間での制御の受渡し時の処理

次の例は、バインド・タスク・フローまたはバインドなしタスク・フローのXMLソース・ファイルに定義された制御フロー・ケースを示しています。

<control-flow-rule>
<from-activity-id>Start</from-activity-id>
<control-flow-case>
<from-outcome>toOffices</from-outcome>
<to-activity-id>WesternOffices</to-activity-id>
</control-flow-case>
</control-flow-rule>

例24-1に示すように、Startビュー・アクティビティに関連付けられているJSFページ上のボタンで、action属性としてtoOfficesが指定されます。ユーザーがボタンをクリックすると、制御フロー・メタデータでto-activity-idとして指定されたWesternOfficesアクティビティに制御フローが渡されます。

例24-1 ビュー・アクティビティで定義された静的ナビゲーション・ボタン

<af:button text="Go" id="b1" action="toOffices">

24.2.2 ビュー・アクティビティのブックマーク

バインドなしタスク・フロー内のビュー・アクティビティにのみ、ブックマークを使用できます。

ビュー・アクティビティに関連付けられたページにエンド・ユーザーがブックマークを付けると、そのビューのブラウザのアドレス・フィールドに表示されているURLがブックマークとして保存されます。ほとんどの場合、このURLはビューに関連付けられているページの再表示に使用できません。たとえば、URLには状態の情報が含まれることがあり、それを使用してページを再表示することはできません。

ブックマークのURLには、ページ上の動的コンテンツを再現するための情報が含まれている必要があります。たとえば、エンド・ユーザーが顧客の連絡先情報を表示するページにブックマークを付ける場合、ブックマークのURLには、ページに加えてその顧客を識別する情報も必要です。これにより、ユーザーがブックマークを使用してそのページに戻ったときに、同じ顧客の連絡先情報を表示できるようになります。

ブラウザに表示されているページのURLをブックマークとして使用できることを確認するには、そのページに関連付けられているビュー・アクティビティがブックマーク可能であることを識別します。

実行時に、バインドなしタスク・フロー内のビュー・アクティビティがブックマーク可能として指定されているかどうかをisViewBookmarkable()メソッドを使用して識別できます。メソッドはビュー・ポート・コンテキストとは離れて配置されています。

ビュー・アクティビティをブックマーク可能として指定すると、オプションで1つ以上のURLパラメータを指定できます。url-parameterの値はEL式です。EL式は、ブックマーク可能なURLが生成されたときにURLに含めるパラメータの取得元を指定します。また、ブックマーク可能なURLが参照解除されたときにURLから値を格納します。ブックマーク可能なビュー・アクティビティのURLを介してパラメータが渡されたときに変換および検証を実行するメソッドは、converterオプションで識別されます。

さらに、送信されたURLパラメータ値でアプリケーション・モデルが更新された後、およびビュー・アクティビティをレンダリングする前に起動されるメソッドをオプションで指定することもできます。このメソッドを使用して、URLパラメータのキー値に基づいて追加情報を取得できます。

次の例は、ブックマークを付けたビュー・アクティビティのURL構文を示しています。

<server root>/<app_context>/faces/<view activity id>?<param name>=<param value>&...

ブックマークを付けたビュー・アクティビティのURL構文は、次のとおりです。

- <server root>: サイト・レベルまたは管理者レベルでカスタマイズして指定します(例: http://mycompany.com/internalApp)。

- <app context>: Webアプリケーションのコンテキスト・ルートです(例: myapp)。コンテキスト・ルートはWebアプリケーションのベース・パスです。たとえば、<app_context>は、サーバー上のWEB-INFノードの物理的な場所にマップされます。

- faces: Facesサーブレット・マッピングです。facesの値は、faces-config.xml構成ファイルを含むノードを指します。

- <view activity id>: ブックマークを付けたビュー・アクティビティの識別子です(例: edit-customers.)。

- <param name>: ブックマークを付けたビュー・アクティビティのURLパラメータの名前です(例: customer-id)。

- <param value>: EL式から導出されたパラメータ値です(例: #{pageFlowScope.employee.id})。EL式の値は、文字列として表すことができる必要があります。

例24-2は、バインドなしタスク・フロー内のブックマーク可能なビュー・アクティビティ用のサンプルURLを示しています。

例24-2 ブックマーク可能なビュー・アクティビティのサンプルURL

http://mycompany.com/internalApp/MyApp/faces/edit-customers?customer-id=1234&...

24.2.2.1 ブックマーク可能なビュー・アクティビティの作成方法

ブックマーク可能なビュー・アクティビティを作成するには、ビュー・アクティビティをブックマーク可能として指定し、ブックマークにURLパラメータを指定して、ブックマークが参照解除された後に実行されるメソッドを指定します。

始める前に:

ブックマーク可能なビュー・アクティビティの作成に必要な構文を理解しておくと役に立つ場合があります。詳細は、「ビュー・アクティビティのブックマーク」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

ビュー・アクティビティをブックマーク可能として指定するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、ビュー・アクティビティをブックマーク可能として指定するバインドなしタスク・フローをダブルクリックします。

2. バインドなしタスク・フローのダイアグラムで、ブックマーク可能として指定するビュー・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「ブックマーク」セクションを開き、「ブックマーク」ドロップダウン・リストでtrueを選択します。

4. 「メソッド」フィールドにEL式を入力して、ADF Controllerがアプリケーション・モデルを対応するブックマークURLパラメータ値で更新した後に起動するメソッドを指定します。

5. ブックマークを付けたビュー・アクティビティのURLに含めるオプションのURLパラメータを追加するには、「追加」をクリックして、「ブックマークURLパラメータ」リストにURLパラメータを入力します。

- 名前: URLパラメータの名前

- value: 評価時にパラメータ値を指定する、設定可能なEL式(例: #{pageFlowScope.employeeID})。この値は文字列として表すことができる必要があります。
「value」プロパティは、ブックマーク可能なURLが生成されたときにURLに含めるパラメータの取得元です。また、ブックマーク可能なURLが参照解除されたときにパラメータはここに格納されます。EL式からNULLが戻されると、そのパラメータはブックマークを付けたビュー・アクティビティのURLから削除されます。例24-2は、ブックマーク・パラメータをビュー・アクティビティURLに追加するために、名前と値を使用する方法を示しています。

- コンバータ: (オプション)ブックマークのURLパラメータ値(#{pageFlowScope.employee.idConverter}など)の値バインディングを入力できます。
EL式が参照するオブジェクトは、oracle.adf.controller.URLParameterConverterを実装する必要があります。

URLパラメータ・コンバータのgetAsObject()メソッドは、入力パラメータに単一文字列の値を取り、適切な型のオブジェクトを戻します。ADFコントローラでURLパラメータに対してコンバータ・メソッドが起動され、続いてパラメータ値がアプリケーションのモデル・オブジェクトに適用されます。同様に、URLパラメータ・コンバータのgetAsString()メソッドは、入力パラメータにオブジェクトを取り、URLで使用される文字列表現を戻します。

JSFアプリケーションでは、送信ページのUIコンポーネントに指定されているコンバータおよびバリデータでデータ値が変換および検証されます。ブックマーク可能URLを使用するFusion Webアプリケーションには、変換および検証を処理する送信ページがありません。そのため、各URLパラメータに使用するコンバータを指定するオプションが用意されています。

24.2.2.2 ブックマーク可能としてのビューの指定時の処理

ビュー・アクティビティをブックマーク可能として指定すると、次の例に示すように、ビュー・アクティビティのメタデータにbookmark要素が追加されます。bookmark要素には、URLパラメータと、ブックマークが参照解除された後に実行されるメソッドを指定するメタデータをオプションで含めることができます。

<view id="employee-view">
<page>/folderA/folderB/display-employee-info.jsf</page>
<bookmark>
<url-parameter>
<name>employee-id</name>
<value>#{pageFlowScope.employee.id}</value>
<converter>#{pageFlowScope.employee.validateId}</converter>
</url-parameter>
<method>#{pageFlowScope.employee.queryData}</method>
</bookmark>
</view>

24.2.3 ビュー・アクティビティへのHTTPリダイレクトの指定

ビュー・アクティビティを構成することで、顧客の要求に応じて実行時にURLへリダイレクトできるようにします。これによって、ADFコントローラでは、ビュー・アクティビティに新規のブラウザ用URLを作成できます。ビュー・アクティビティの元のURLは使用されなくなります。「ビュー・アクティビティのブックマーク」の説明のとおり、ビュー・アクティビティをすでにブックマーク可能にしている場合は、ビュー・アクティビティのHTTPリダイレクトを構成できません。

24.2.3.1 ビュー・アクティビティにHTTPリダイレクトを指定する方法

ビュー・アクティビティのredirectプロパティをtrueに設定します。

始める前に:

ビュー・アクティビティのredirectプロパティをtrueに設定した場合の影響について理解しておくと役に立つ場合があります。詳細は、「ビュー・アクティビティへのHTTPリダイレクトの指定」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

ビュー・アクティビティにHTTPリダイレクトを指定するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、タスク・フローをダブルクリックします。

2. タスク・フロー・ダイアグラムで、ビュー・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「一般」セクションを開き、「リダイレクト」ドロップダウン・リストでtrueを選択します。

24.2.3.2 ビュー・アクティビティへのHTTPリダイレクト指定時の処理

ADFコントローラは、ビュー・アクティビティの要求に応じて、HTTPリダイレクトを発行します。リダイレクトされたリクエストによって、ビュー・アクティビティ用に新しいブラウザのURLが作成されます。ビューの元のURLは使用できなくなります。

指定すると、クライアントのGETリクエストに応じて、HTTPリダイレクトが発行されます。クライアントのGETでは、ADFコントローラおよびADFモデルでページに新しいバインディング・コンテキストが設定されるまで、#{bindings} ELスコープは無効です。したがって、HTTPリダイレクトを指定したビュー・アクティビティには、次のようなEL式の使用はできません。

#{bindings.foo}

注意:

http://www.mycompany.org/x.htmlでhttp://www.mycompany.org/y.htmlの内容をかわりに表示する場合、次のようなリフレッシュ方法は使用しないでください。

<META HTTP-EQUIV=REFRESH CONTENT="1; URL=http://www.example.org/bar">

この方法は「戻る」ボタンの動作に悪影響を及ぼすことがあります。エンド・ユーザーがブラウザの「戻る」ボタンをクリックすると再度リフレッシュが行われ、予想どおり元のページに戻るのではなく次のページに進みます。

この場合は、かわりにHTTPリダイレクトを使用してください。

24.2.4 ビュー・アクティビティのURL別名の指定

Fusion WebアプリケーションがレンダリングするURLには、現在のコンテキストに基づいて実行時に生成される形式があります。

- ビュー・アクティビティがバインド・タスク・フローにある場合、アプリケーションは次の形式でURLをレンダリングします。

http://www.example.com/web-app-context-root/faces/task-flow-id/view-activity-ID

- ビュー・アクティビティがバインドなしタスク・フローにある場合、アプリケーションは次の形式でURLをレンダリングします。

http://www.example.com/web-app-context-root/faces/view-activity-ID

エンド・ユーザーに対してよりわかりやすい名前のURLが表示されるように、ビュー・アクティビティのURL別名を指定できます。デフォルトで生成される値のかわりに、指定したURL別名値がレンダリングされます。たとえば、果物に関するデータを管理するタスク・フローで、リンゴおよびオレンジに関する情報を表示および編集するビュー・アクティビティを設定できます。このシナリオでは、エンド・ユーザーがリンゴおよびオレンジのビュー・アクティビティ・ページにナビゲートすると、Fusion Webアプリケーションによって次のようなURL別名がレンダリングされます。

http://www.example.com/web-app-context-root/faces/fruit/apples
http://www.example.com/web-app-context-root/faces/fruit/oranges

URL別名に様々なレベルを指定して、エンド・ユーザーが階層を意識するようにできます。つまり、ビュー・アクティビティのURL別名では次の両方の値が有効です。

/food/fruit/pineapple
/drink/juice/pineapple

ただし、指定するURL別名は、ビュー・アクティビティが含まれているタスク・フロー内で一意である必要があります。

レンダリングするビュー・アクティビティのURL別名を指定する対象はJSFページであり、JSFページ・フラグメントではありません。この後者のタイプのドキュメントがブラウザに直接レンダリングされることはありません。

24.2.4.1 ビュー・アクティビティにURL別名を指定する方法

ビュー・アクティビティの「View-ID」プロパティ(<view-id>)の値を記述して、ビュー・アクティビティのURL別名を指定します。

始める前に:

ビュー・アクティビティのURL別名を指定するときにどのようなオプションを使用できるかについて理解しておくと、役立つ場合があります。詳細は、「ビュー・アクティビティのURL別名の指定」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 実行時にJSFページをレンダリングするビュー・アクティビティを作成します

- 実行時にエンド・ユーザーが表示するJSFページを作成します

ビュー・アクティビティのURL別名を指定する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、URL別名を指定するビュー・アクティビティを含むタスク・フローをダブルクリックします。

2. タスク・フローのダイアグラムで、URL別名を指定するビュー・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「一般」セクションを開き、「View-ID」フィールドにURL別名値を入力します。

たとえば、次の形式で値を入力します。

/food/fruit/citrus/lemons

24.2.4.2 ビュー・アクティビティへのURL別名指定時の処理

次の例に示すように、JDeveloperにより、「View-ID」フィールドに指定した値がビュー・アクティビティのメタデータに追加されます。

<view id="view1">
<page>/view1.jsf</page>
<view-id>/food/fruit/citrus/lemons</view-id>
</view>

24.3 URLビュー・アクティビティの使用

URLビュー・アクティビティを使用すると、ADFリージョンのコンテキスト内からでも、ルート・ビュー・ポート(ブラウザ・ページなど)をURLにアドレス可能なリソースにリダイレクトできます。URLアドレス可能なリソースには次が含まれます。

- バインド・タスク・フロー

- バインドなしタスク・フロー内のビュー・アクティビティ

- 現在のWebアプリケーションの外にあるアドレス(たとえばhttp://www.oracle.com)

リソースを表示するには、実行時に評価してリソースへのURLを生成するEL式を指定します。さらに、評価時にパラメータおよびパラメータ値としてURLに追加されるEL式を指定することもできます。

URLビュー・アクティビティでは、実行元のビュー・ポート(ルート・ビュー・ポートまたはADFリージョン)には関係なく、クライアントがリダイレクトされます。ビュー・アクティビティの<redirect>要素は、そのビュー・アクティビティがルート・ビュー・ポート内にある場合のみ使用されることを除けば、同様の方法で実行されます。<redirect>要素は、ADFリージョンのコンテキスト内では無視されます。詳細は、「ビュー・アクティビティへのHTTPリダイレクトの指定」を参照してください。

<redirect>要素ではなくURLビュー・アクティビティを使用した同じアプリケーション内の他の場所へのリダイレクトは、タスク・フロー・スタックがクリーンアップされるため、「戻る」ボタンでの移動と同様に処理されます。Webアプリケーション外部へのリダイレクトは、アプリケーション外部のサイトのURLを参照解除する場合のように処理されます。

24.3.1 タスク・フローへのURLビュー・アクティビティの追加方法

URLビュー・アクティビティをバインドまたはバインドなしタスク・フローに追加できます。

始める前に:

URLビューをタスク・フローの機能に追加した場合の影響について理解しておくと役に立つ場合があります。詳細は、「URLビュー・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

タスク・フローへのURLビュー・アクティビティの追加手順:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、URLビュー・アクティビティを追加するタスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、URLビュー をドラッグして、ダイアグラムへドロップします。

3. 「プロパティ」ウィンドウで「一般」セクションを開き、「アクティビティID」フィールドにURLビュー・アクティビティを識別するIDを入力します。

4. 「URL」フィールドには、実行時にURLを返すELを入力します。必要に応じて式ビルダーを使用するには、プロパティ・フィールドの上にカーソルを置いたときに表示されるアイコンをクリックします。

たとえば、図24-5は、アプリケーションのmyorders-task-flow.xmlバインド・タスク・フロー内で、EL式(#{myOrdersBean.registerNav})を使用して実行時にURLを取得するURLアクティビティ(register)を示しています。

図24-5 URLビュー・アクティビティ

5. 「URLパラメータ」セクションを開いて、URLに含めるURLパラメータをオプションで追加します。

- 名前: パラメータの名前。

- 値: 評価時にパラメータ値を生成するEL式。

- 「コンバータ」: 評価時に、ブックマーク可能なビュー・アクティビティのURLを介してパラメータが渡されたときに変換および検証を実行するメソッドを指定する、設定可能なEL式。詳細は、「ビュー・アクティビティのブックマーク」を参照してください。

24.3.2 タスク・フローへのURLビュー・アクティビティ追加時の処理

タスク・フローのソース・ファイルのURLビュー・アクティビティに、次の例のようなエントリが生成されます。

<url-view id="register">
<url>#{myOrdersBean.registerNav}</url>
</url-view>

24.3.3 URLビュー・アクティビティに関する必知事項

JSFポートレット内では、タスク・フローのURLビュー・アクティビティを使用できます。タスク・フローのURLビュー・アクティビティを構成し、JSFポートレット内で使用する場合は、次のオプションのいずれかを使用してURLを作成します。

- oracle.adf.controllerパッケージのControllerContextクラスから次のメソッドのいずれかを起動します。

- getLocalViewActivityURL()

- getGlobalViewActivityURL()

ADFPortletContainerExternalContextクラスからredirect()メソッドを起動する前に、getLocalViewActivityURL()メソッドまたはgetGlobalViewActivityURL()メソッドからの応答でADFPortletContainerExternalContextクラスからencodeActionURL()メソッドを起動してはいけません。getLocalViewActivityURL()メソッドおよびgetGlobalViewActivityURL()メソッドの両方で、必要なURLのエンコーディングが実行されます。

- 完全修飾された絶対URLを提供します。

- コンテキスト・パスの相対URLを提供します。

- 現在のビューに相対するURLを提供します。

JSFポートレットにあるタスク・フローのURLビュー・アクティビティは次のように動作します。

- リダイレクトURLがJSFポートレット・アプリケーション内の場所を参照し、値がtrueのx_DirectLinkと呼ばれるqueryStringパラメータを含まない場合は、これを含むページ内のポートレットがURLビュー・アクティビティで指定されたURLに移動します。

- それ以外の場合、クライアントはURLビュー・アクティビティで指定されたURLにリダイレクトされます。

タスク・フローのURLビュー・アクティビティの使用の詳細は、「URLビュー・アクティビティの使用」を参照してください。

URLの取得に使用できるメソッドの詳細は、Oracle ADF ControllerのJava APIリファレンスを参照してください。

24.4 ルーター・アクティビティの使用方法

EL式の実行時の評価に基づいて、ルーター・アクティビティを使用し、制御をアクティビティにルーティングします。図24-6は、そこから異なるアクティビティにつながる別の制御フローに分岐可能な、Summit ADFタスク・フロー・サンプル・アプリケーションからのcustomer-task-flow-definition.xmlタスク・フロー内のルーター・アクティビティ(isCustomerLogin)を示しています。

図24-6 代替制御フロー・ケースのルーター

各制御フローは、異なるルーター・ケースに対応できます。各ルーター・ケースでは、次の要素を使用して、制御が次にルーティングされるアクティビティを選択します。

- expression: 実行時の値がtrueまたはfalseになるEL式
ルーター・アクティビティは、trueを返すEL式に対応する結果を返します。

- outcome: EL式の値がtrueの場合にルーター・アクティビティから返される値(customerLoginなど)
制御フロー・ケース上でルーター・ケースのoutcomeがfrom-outcomeと一致する場合は、制御フロー・ケースがポイントするアクティビティに制御が渡されます。ルーター・アクティビティのケースの値がtrueでない場合、またはルーター・アクティビティのケースが指定されていない場合は、ルーターの「デフォルト結果」フィールドで指定されているoutcomeが使用されます。

たとえば、図24-6は、ユーザーがログインしており、特定のアプリケーション・ロールを持っているかどうかを特定するEL式の評価に基づいて制御フローを渡すルーター・アクティビティを示しています。Trueの場合,SetCurrentRowWithKeyValueメソッド・コール・アクティビティに制御が渡されます。そうでない場合、Customersビュー・アクティビティに制御が渡されます。

注意:

EL式にルーティング条件を表示できる場合は、ルーター・アクティビティを使用します。

ルーター・アクティビティを使用すると、それを含むタスク・フローの設計時により多くのことができます。ルーター・アクティビティでは、タスク・フローの条件に関するより多くの情報を表示できます。これにより、タスク・フローのダイアグラムを閲覧するユーザーにとってより読みやすく、有効な情報になります。

また、ルーター・アクティビティを使用すると、後でアプリケーションを変更しやすくなります。たとえば、ルーティング条件を後で変更または追加できます。

24.4.1 ルーター・アクティビティを使用した制御フローの構成方法

「コンポーネント」ウィンドウからタスク・フローのダイアグラムまでルーター・アクティビティをドラッグすることによって制御フローを定義します。ルーター・アクティビティの「アクティビティID」および「デフォルト結果」を構成し、ルーター・ケースをルーター・アクティビティに追加します。

始める前に:

機能に影響を及ぼす可能性のあるルーター・アクティビティのプロパティを理解しておくと役に立つ場合があります。詳細は、「ルーター・アクティビティの使用方法」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

ルーター・アクティビティを使用して制御フローを構成するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、ルーター・アクティビティを使用して制御フローを構成するタスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、ルーター・アクティビティをドラッグして、ダイアグラムへドロップします。

3. 「プロパティ」ウィンドウで、「一般」セクションを開き、次の値を入力します。

- アクティビティID: タスク・フローのソース・ファイルにあるルーター・アクティビティを識別する値を記述します。

- デフォルト結果: どの制御フロー・ケースの値もtrueでない場合、または制御フロー・ケースが指定されていない場合に、ルーター・アクティビティが制御を渡すアクティビティを指定します。

4. 「ケース」セクションの「追加」アイコンをクリックし、追加したルーター・ケースごとに値を指定します。

- 式: 実行時の値がtrueまたはfalseになるEL式。
たとえば、ビュー・アクティビティの入力テキスト・フィールドにある値を参照するには、次のようなEL式を記述します。

#{pageFlowScope.value=='view2'}

EL式がtrueを返す場合は、ルーター・アクティビティによって「結果」フィールドで指定した結果が呼び出されます。

- 結果: 「式」によって指定されたEL式がtrueを返す場合にルーター・アクティビティが呼び出す結果。
タスク・フロー・ダイアグラムの結果ごとに制御フロー・ケースまたはワイルドカード制御フロー・ルールを作成します。たとえば、制御フロー・ケースの結果ごとに、対応するfrom-outcomeがあることを確認します。

24.4.2 ルーター・アクティビティを使用した制御フロー構成時の処理

JDeveloperでは、ルーター・アクティビティのプロパティに指定した値に基づいて、タスク・フローのソース・ファイルに値を記述します。例24-3は、ルーター・アクティビティから異なるアクティビティにつながる別の制御フローに分岐する、Summit ADFタスク・フロー・サンプル・アプリケーションからのcustomer-task-flow-definition.xmlタスク・フローに表示される値を示しています。

実行時に、ルーター・アクティビティでは、EL式がtrueを返す場合にoutcomeによって指定される制御フロー・ケースに制御を渡します。

例24-3 Summit ADFタスク・フロー・サンプル・アプリケーションのルーター・アクティビティ

<router id="isCustomerLogin">
<case id="__4">
<expression>#{securityContext.userInRole['Application Customer Role']}</expression>
<outcome>customerLogin</outcome>
</case>
<default-outcome>notCustomerLogin</default-outcome>
</router>
...
<control-flow-case id="__7">
<from-outcome>customerLogin</from-outcome>
<to-activity-id>SetCurrentRowWithKeyValue</to-activity-id>
</control-flow-case>

24.5 メソッド・コール・アクティビティの使用

メソッド・コール・アクティビティを使用して、アプリケーションの制御フロー内のどこからでもアプリケーション・ロジックを起動する、カスタム・メソッドまたは組込みメソッドをコールします。ページ表示前の初期化、ページ終了後のクリーンアップ、例外処理などのタスクを実行するメソッドを指定できます。

図24-7は、Summit ADFタスク・フロー・サンプル・アプリケーションのcustomers-task-flow-definition.xmlを示しています。ここでは、SetCurrentRowWithKeyValueメソッド・コール・アクティビティがBackOfficeAppModuleDataControlデータ・コントロールからsetCurrentRowWithKeyValues操作を起動します。

図24-7 セット行へのメソッド・コール・アクティビティ

制御フロー・ケースを指定してメソッドの終了後に制御を渡すメソッドに対して結果を設定できます。結果には次のいずれかを指定できます。

- fixed-outcome: 正常完了時に、メソッドから常に戻される単一の結果(例: success)。メソッドが正常に完了しないと結果は戻されません。メソッド・タイプがvoidの場合、to-stringではなくfixed-outcomeを指定する必要があります。

- to-string: trueとして指定されると、メソッドによって戻されたJavaオブジェクトに対してtoString()メソッドがコールされ、それに基づく結果が得られます。たとえば、toString()からeditBasicInfoが戻された場合、ナビゲーションはeditBasicInfoという名前の制御フロー・ケースに移動します。

次の例は、図24-7のメソッド・コール・アクティビティのメタデータを示しています。ここで、fixed-outcome要素は返される結果としてsetCurrentRowWithKeyを指定します。

<method-call id="SetCurrentRowWithKeyValue">
<method>#{bindings.setCurrentRowWithKeyValue.execute}</method>
<outcome>
<fixed-outcome>setCurrentRowWithKey</fixed-outcome>
</outcome>

制御フローの詳細は、「制御フローについて」を参照してください。

24.5.1 メソッド・コール・アクティビティの追加方法

「コンポーネント」ウィンドウからタスク・フローのダイアグラムまでメソッド・コール・アクティビティをドラッグします。メソッド・コール・アクティビティは、「データ・コントロール」パネルからタスク・フロー・ダイアグラム内のメソッド・コール・アクティビティにデータ・コントロール操作を直接ドロップして、既存のメソッドに関連付けることができます。

たとえば、Summit ADFタスク・フロー・サンプル・アプリケーションで、setCurrentRowWithKeyまたはsetCurrentRowWithKeyValues操作を「データ・コントロール」パネルのBackOfficeAppModuleDataControlデータ・コントロールからダイアグラムにドラッグして、表内で現在の行を表示または選択するメソッド・コール・アクティビティを作成できます。

注意:

データ・コントロール・メソッドのパラメータは、ADFコントローラのメタデータ内ではなく、対応するページのページ定義に定義されます。

メソッドおよび操作はタスク・フロー・ダイアグラムにも直接ドラッグできます。ダイアグラム上にドロップすると、新しいメソッド・コール・アクティビティが自動的に作成されます。メソッドにEL式およびその他のオプションを指定できます。

ヒント:

メソッド・コール・アクティビティが起動するメソッドを識別するには、タスク・フロー・ダイアグラム内で任意のアクティビティを右クリックし、「メソッドに移動」を選択します。JDeveloperはメソッド・コール・アクティビティが起動するメソッドに移動します。

始める前に:

メソッド・コール・アクティビティのプロパティがタスク・フローの機能に与える影響について理解しておくと有効な場合があります。詳細は、「メソッド・コール・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

次のタスクを完了する必要があります。

- バインド・タスク・フローまたはバインドなしタスク・フローを作成します。詳細は、「タスク・フローの作成」を参照してください。

タスク・フローへのメソッド・コール・アクティビティの追加手順:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、メソッド・コール・アクティビティを追加するタスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、メソッド・コール・アクティビティをドラッグして、ダイアグラムへドロップします。
メソッド・コール・アクティビティには、オプションでデフォルトのアクティビティIDであるmethodCallnとメソッドのEL式がまだ指定されていないことを示す警告アイコンが表示されます。

警告アイコンの有効化の詳細は、「タスク・フローにアクティビティを追加する方法」を参照してください。

3. 「プロパティ」ウィンドウで「一般」セクションを開き、デフォルトの値を変更する場合は「アクティビティID」フィールドにアクティビティIDを入力します。
新規の値を入力すると、ダイアグラムのメソッド・コール・アクティビティの下に新しい値が表示されます。

4. 「メソッド」フィールドには、コールするメソッドを識別するEL式を入力します。
たとえば、ELバインディング式を次のように入力します。

#{bindings.setCurrentRowWithKeyValue.execute}

注意:

EL式のbindings変数は、現在のバインディング・コンテナからADFモデル・バインディングを参照します。バインディング変数を指定するには、バインディング・コンテナ定義またはページ定義を指定する必要があります。詳細は、「ページ定義ファイルでの作業」を参照してください。

また、図24-8に示される式ビルダーを使用してメソッドのEL式を作成することもできます。

a. 「メソッド」プロパティ・フィールド上にカーソルを置いたときに表示されるアイコンをクリックして表示されるポップアップ・メニューから、「メソッド式ビルダー」を選択します。

b. 「式ビルダー」ダイアログで、起動するメソッドにナビゲートして選択します。
「式ビルダー」ダイアログは図24-8のようになります。たとえば、図24-8で、式ビルダーの上部に表示されるEL式は、Summit ADFタスク・フロー・サンプル・アプリケーションのemp-reg-task-flow-definition.xmlタスク・フロー内のメソッド・コール・アクティビティから、CreateInsertアクション・バインディングを参照します。

図24-8 「式ビルダー」ダイアログ内のメソッド用EL式

c. 「OK」をクリックします。

ヒント:

メソッド・コール・アクティビティでマネージドBeanメソッドを起動する場合は、ダイアログでメソッド・コール・アクティビティをダブルクリックします。これによってダイアログが呼び出され、そこで起動するマネージドBeanメソッドを指定できます。

5. 「プロパティ」ウィンドウで、「一般」セクションを開き、Outcomeグループ内で次のいずれかを指定します。

- 固定結果: 正常完了時に、メソッドから常に戻される単一の結果(例: success)。メソッドが正常に完了しないと結果は戻されません。メソッド・タイプが無効の場合は、to-stringの値ではなく、「固定結果」の値を指定する必要があります。

- tostring(): 「True」を選択すると、メソッドから戻されたJavaオブジェクトに対してtoString()メソッドがコールされ、それに基づく結果が得られます。

24.5.2 メソッド・パラメータおよび戻り値の指定方法

メソッドのパラメータや戻り値を指定することができます。図24-9は、calculateSalesTaxというメソッドに唯一定義されているパラメータを示しています。「値」フィールドには、実行時に値がパラメータ値になるEL式が含まれています。

図24-9 メソッド・コールにおけるメソッド・パラメータ

メソッド・コール・アクティビティを既存のメソッドに関連付けることによってパラメータをまだ作成していない場合は、パラメータを追加します。

始める前に:

メソッド・コール・アクティビティのプロパティがタスク・フローの機能に与える影響について理解しておくと有効な場合があります。詳細は、「メソッド・コール・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「メソッド・コール・アクティビティの追加方法」の説明に従って、メソッド・コール・アクティビティをタスク・フロー・ダイアグラムに追加します。

メソッド・パラメータを追加するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、メソッド・パラメータを追加するメソッド・コール・アクティビティを含むタスク・フローをダブルクリックします。

2. タスク・フロー・ダイアグラムで、メソッド・コール・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「パラメータ」 セクションを開き、「追加」をクリックして追加するパラメータの次の値を設定します。

- クラス: パラメータのクラスを入力します(例: java.lang.Double)。

- 値: パラメータの値を取得するEL式を入力します。次に例を示します。
#{pageFlowScope.shoppingCart.totalPurchasePrice}

4. 「戻り値」フィールドに、メソッドの戻り値を格納する場所を識別するEL式を入力します(例: #{pageFlowScope.Return})。

5. 前述の各手順を繰り返してさらにパラメータを追加します。

24.5.3 メソッド・コール・アクティビティ追加時の処理

メソッドのパラメータや戻り値の指定後、XMLソース・ファイルが更新されます。例24-4は、Summit ADFタスク・フロー・サンプル・アプリケーションのcustomers-task-flow-definition.xmlタスク・フロー内のSetCurrentRowWithKeyValueメソッド・コール・アクティビティを示しています。

例24-4 Summit ADFサンプル・アプリケーションのメソッド・コール・アクティビティ

<method-call id="SetCurrentRowWithKeyValue">
<method>#{bindings.setCurrentRowWithKeyValue.execute}</method>
<outcome>
<fixed-outcome>setCurrentRowWithKey</fixed-outcome>
</outcome>
</method-call>

24.6 タスク・フロー・コール・アクティビティの使用

タスク・フロー・コール・アクティビティを使用すると、バインドなしタスク・フローまたはバインド・タスク・フローのいずれかからバインド・タスク・フローをコールできます。タスク・フロー・コール・アクティビティによって、同じアプリケーション内または別のアプリケーション内にあるバインド・タスク・フローをコールできます。

コールされたバインド・タスク・フローでは、デフォルト・アクティビティが最初に実行されます。バインド・タスク・フロー・コールの数に制限はありません。たとえば、コール先のバインド・タスク・フローから別のバインド・タスク・フローをコールでき、さらにそのバインド・タスク・フローからも次々にコールできるため、各タスク・フローがタスク間を結び付けるタスク・フロー・チェーンを作成できます。

バインド・タスク・フローにパラメータを渡すには、タスク・フロー・コール・アクティビティに入力パラメータの値を指定する必要があります。これらの値は、コール先のバインド・タスク・フローの入力パラメータ定義と一致している必要があります。詳細は、「タスク・フロー・コール・アクティビティへの入力パラメータの指定方法」を参照してください。

また、次の点にも注意してください。

- タスク・フロー・コール・アクティビティの「入力パラメータ」の値は、コール元のタスク・フロー内で値が取得される場所を指定します。

- コール先のタスク・フローの「入力パラメータの定義」の値は、値が渡されたときにコール先のバインド・タスク・フローで値が格納される場所を指定します。

ヒント:

バインド・タスク・フローがタスク・フロー・コール・アクティビティに関連付けられると、バインド・タスク・フローで定義されている入力パラメータ定義に基づいて、入力パラメータが自動的にタスク・フロー・コール・アクティビティに挿入されます。したがって、アプリケーション開発者が実行する必要があるのは、タスク・フロー・コール・アクティビティの入力パラメータへの値の割当てのみです。

デフォルトでは、すべてのオブジェクトは参照渡しされます。プリミティブ型(int、long、booleanなど)は常に値で渡されます。

バインド・タスク・フローからコール元に戻り値が渡される方法は、入力パラメータが渡される方法と類似しています。詳細は、「バインド・タスク・フローの戻り値の構成」を参照してください。

タスク・フロー・コール・アクティビティを使用するには:

1. タスク・フロー・コール・アクティビティを使用してバインド・タスク・フローをコールします。

2. パラメータをバインド・タスク・フローに渡す場合は、タスク・フロー・コール・アクティビティに入力パラメータを指定します。

3. URLを使用して別のWebアプリケーション内のバインド・タスク・フローをコールします。

4. タスク・フロー・コール・アクティビティにbefore listenerおよびafter listenerを指定します。

24.6.1 タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール方法

コール側のバインドまたはバインド・タスク・フローまたはバインドなしタスク・フローにタスク・フロー・コール・アクティビティを追加し、バインド・タスク・フローをコールします。

始める前に:

タスク・フロー・コール・アクティビティとタスク・フローとの対話方法を理解しておくと役に立つ場合があります。詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

タスク・フロー・コール・アクティビティを使用してバインド・タスク・フローをコールするには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、バインド・タスク・フローをコールするためにタスク・フロー・コール・アクティビティを追加するタスク・フロー(コール元タスク・フロー)をダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、「タスク・フロー・コール」アクティビティをドラッグして、ダイアグラムへドロップします。

3. 次のオプションのいずれかを選択して、コール先タスク・フローを識別します。

- タスク・フロー・ダイアグラムで、タスク・フロー・コール・アクティビティをダブルクリックします。
「バインド・タスク・フローの作成」ダイアログが表示され、そこで新規バインド・タスク・フロー作成のオプションを指定できます。

- 「アプリケーション」ウィンドウから既存のバインド・タスク・フローをドラッグし、タスク・フロー・コール・アクティビティにドロップします。

ヒント

バインド・タスク・フローをページまたはページ・フラグメントにドロップできます。バインド・タスク・フローがページで(ページ・フラグメントではなく)構成される場合、表示される「ボタンとしてのタスク・フロー・コール」または「リンクとしてのタスク・フロー・コール」メニュー・オプションを選択して、タスク・フローをドロップするページ上にボタンまたはリンク・コンポーネントを追加します。エンド・ユーザーは、ボタンまたはリンクをクリックしてタスク・フローをコールできます。ページがタスク・フローの既存のビュー・アクティビティに関連付けられている場合、このようにするとタスク・フロー・コール・アクティビティが同様に自動的に作成されます。

たとえ両方のアプリケーションが「アプリケーション」ウィンドウ内に表示されているとしても、「アプリケーション」ウィンドウで、あるアプリケーションから別のアプリケーション内のタスク・フロー・ダイアグラムにバインド・タスク・フローをドロップすることはできません。さらに、あるプロジェクトのバインド・タスク・フローを、別なプロジェクトのタスク・フロー・ダイアグラムにドロップすることはできません。

そのかわり、バインド・タスク・フローをADFライブラリにパッケージ化して、現在のアプリケーションまたはプロジェクトで再利用できます。その後、ライブラリのインポート時に作成される「リソース」ウィンドウまたは「コンポーネント」ウィンドウ・ページから、バインド・タスク・フローをドラッグできます。詳細は、「「リソース」ウィンドウの使用」を参照してください。

- 起動するバインド・タスク・フローの名前がわかっている場合は、次の手順を実行します。

a. タスク・フロー・ダイアグラムで、タスク・フロー・コール・アクティビティを選択します。

b. 「プロパティ」ウィンドウで、「一般」セクションを開き、「タスク・フロー参照」ドロップダウン・リストで「静的」を選択します。

c. 「ドキュメント」フィールドに、コールするバインド・タスク・フローのソース・ファイル名を入力します。たとえば、called-task-flow-definition.xmlと入力します。

d. 「ID」フィールドには、たとえばtargetTaskFlowなど、コール先のバインド・タスク・フローのXMLソース・ファイルに含まれているバインド・タスク・フローIDを入力します。

- 起動するバインド・タスク・フローの名前がわからない場合、実行時のエンド・ユーザーによって異なる場合は、次の手順を実行します。

a. タスク・フロー・ダイアグラムで、タスク・フロー・コール・アクティビティを選択します。

b. 「プロパティ」ウィンドウで、「一般」セクションを開き、「タスク・フロー参照」ドロップダウン・リストで「動的」を選択します。

c. 「動的タスク・フロー参照」プロパティ・フィールド上にカーソルを置いたときに表示されるアイコンをクリックして表示されるポップアップ・メニューから、「式ビルダー」を選択します。

d. 実行時に起動するバインド・タスク・フローのIDを識別するEL式を記述します。

図24-10には、Summit ADFタスク・フロー・サンプル・アプリケーションにあるcustomers-task-flowタスク・フローが示されています。このタスク・フローには、同じ名前のタスク・フローを起動するタスク・フロー・コール・アクティビティ(create-edit-orders-task-flow-definition)が含まれています。

図24-10 バインド・タスク・フローを起動するタスク・フロー・コール・アクティビティ

24.6.2 タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール時の処理

JDeveloperはバインド・タスク・フローをコールするタスク・フローのソース・ファイルに、メタデータ・エントリを生成します。例24-5は、Summit ADFタスク・フロー・サンプル・アプリケーションの図24-10に対応するメタデータを示しています。実行時に、タスク・フロー・コール・アクティビティはorders-select-many-itemsタスク・フローを起動します。

例24-5 Summit ADFサンプル・アプリケーションのタスク・フロー・コール・アクティビティ

<task-flow-call id="orders-select-many-items">
<task-flow-reference>
<document>/WEB-INF/flows/orders/orders-select-many-items.xml</document>
<id>orders-select-many-items</id>
</task-flow-reference>
<run-as-dialog>
<display-type>
<inline-popup/>
</display-type>
</run-as-dialog>
</task-flow-call>

24.6.3 タスク・フロー・コール・アクティビティへの入力パラメータの指定方法

タスク・フロー・コール・アクティビティとそのコール先のバインド・タスク・フローの間でパラメータをマップするには、まずコール先のバインド・タスク・フローの入力パラメータ定義を指定する方法をお薦めします。その後、「アプリケーション」ウィンドウからバインド・タスク・フローをドラッグし、タスク・フロー・コール・アクティビティにドロップできます。タスク・フロー・コール・アクティビティの入力パラメータは、バインド・タスク・フローの入力パラメータ定義に基づいて自動的に作成されます。詳細は、「バインド・タスク・フローへのパラメータ渡し」を参照してください。

当然ながら、最初にタスク・フロー・コール・アクティビティに入力パラメータを指定することも可能です。最初に定義した場合にも、コール先のバインド・タスク・フローの入力パラメータ定義がタスク・フロー・コール・アクティビティに関連付けられた時点で、その入力パラメータ定義に基づいて自動的に置換されます。

コール先のバインド・タスク・フローをまだ作成していない場合にも、タスク・フロー・コール・アクティビティに入力パラメータを指定する方法は便利です。この時点で指定することで、バインド・タスク・フローのコール時にタスク・フロー・コール・アクティビティが最終的にマップされる予定の入力パラメータを特定できます。

始める前に:

タスク・フロー・コール・アクティビティとタスク・フローとの対話方法を理解しておくと役に立つ場合があります。詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

入力パラメータをタスク・フロー・コール・アクティビティに指定するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、タスク・フロー・コール・アクティビティを含むタスク・フローをダブルクリックします。

2. ダイアグラムで、タスク・フロー・コール・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「パラメータ」セクションを開き、「追加」アイコンをクリックして、「入力パラメータ」リストで次のように新しい入力パラメータを指定します。

- 名前: 入力パラメータを識別する名前を入力します。

- 値: パラメータ値を識別するEL式を入力します。EL式は、コール元タスク・フロー内の値が取得される場所を特定します。たとえば、次のようにEL式を入力します。
#{pageFlowScope.callingTaskflowParm}

デフォルトでは、すべてのオブジェクトは参照渡しされます。プリミティブ型(int、long、booleanなど)は常に値で渡されます。

必要に応じて式ビルダーを使用するには、値フィールドをクリックして表示されるドロップダウン・リストを使用します。

4. 入力パラメータを指定すると、対応する入力パラメータ定義をコール先のバインド・タスク・フローに指定できます。詳細は、「バインド・タスク・フローへのパラメータ渡し」を参照してください。

24.6.4 URLを使用したバインド・タスク・フローのコール方法

URLを使用して、別のWebアプリケーションにあるページ・フラグメント(.jsff)を使用しないバインド・タスク・フローをコールできます。タスク・フロー・コール・アクティビティを使用して、起動するバインド・タスク・フローをコールします。タスク・フロー・コール・アクティビティのremote-app-urlプロパティ(評価されるとURLを返す)のEL式を記述します。

remote-app-urlプロパティの値を記述するだけでなく、コールするバインド・タスク・フローを識別するタスク・フロー参照・プロパティの値も指定します。タスク・フロー参照およびremote-app-urlプロパティが実行時に組み合せられて、リモートWebアプリケーションで、コール先のバインド・タスク・フローのURLが生成されます。

リモートWebアプリケーションでは、コールするバインド・タスク・フローの「可視性」プロパティを設定し、コール側のタスク・フローでタスク・フロー・コール・アクティビティから生成されたURLを受信すると、起動するようにしておく必要もあります。

JSFポートレットは同じWebアプリケーションからすべてのコンテンツを提供する点に注意してください。したがって、JSFポートレットでWebアプリケーションを使用する場合は、WebアプリケーションがURLを使用してタスク・フローを起動するような設定は行わないでください。

注意:

JDeveloperの「アプリケーション」ウィンドウで、URLを使用してコールするバインド・タスク・フローを右クリックし、「実行」を選択した場合は、バインド・タスク・フローは、実行時にURLを使用してコールされたかのように実行されます。このため、バインド・タスク・フローをJDeveloperでのテストの一部として実行する場合でも、その可視性プロパティを確実に設定しておくようにします。

始める前に:

タスク・フロー・コール・アクティビティとタスク・フローとの対話方法を理解しておくと役に立つ場合があります。詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

URLを使用してバインド・タスク・フローをコールする手順:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、リモートWebアプリケーション内でバインド・タスク・フローを起動するために構成するタスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、「タスク・フロー・コール」アクティビティをドラッグして、タスク・フローのダイアグラムへドロップします。

3. 「プロパティ」ウィンドウで、「一般」セクションを開き、バインド・タスク・フローを起動する値を指定します。

詳細は、「タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール方法」を参照してください。

4. 「リモート・アプリケーションのURL」プロパティについては、「式ビルダー」を使用して、評価時にリモートWebアプリケーションのURL作成に必要な部分を含む文字列を返すEL式を記述します。プロパティ・フィールド上にカーソルを置いたときに表示されるアイコンをクリックして表示されるポップアップ・メニューから、「式ビルダー」を選択して、式ビルダーを起動します。

たとえば次のサンプルEL式は、URLの作成に必要な部分を含む文字列を返すマネージドBeanを起動します。

#{myOrdersBean.createOrder}

5. 起動するリモートWebアプリケーション内のバインド・タスク・フローを開きます。

注意:

指定するバインド・タスク・フローは、ページ・フラグメント (.jsff)を使用できません。

6. 「構造」ウィンドウで、バインド・タスク・フロー(task-flow-definition- タスク・フローID)のノードを右クリックし、「プロパティに移動」を選択します。

7. 「プロパティ」ウィンドウで、「一般」セクションを開き、次の値を選択します。

- URL起動: URLによるバインド・タスク・フローの起動を許可する場合は、ドロップダウン・リストからurl-invoke-allowedを選択します。URLによるバインド・タスク・フローの起動を許可しない場合は、url-invoke-disallowedを選択します。この値を選択しておくと、URLがバインド・タスク・フローを起動しようとすると、HTTP 403のステータス・コードが返されます。デフォルト値(calculated)では、バインド・タスク・フローがイニシャライザを指定しておらず、ビュー・アクティビティがデフォルト・アクティビティである場合に、URLによるバインド・タスク・フローの起動を許可します。バインド・タスク・フローがこの条件を満たしていない場合は、HTTP 403のステータス・コードが返されます。url-invoke-allowedまたはurl-invoke-disallowedを選択すると、デフォルト動作がオーバーライドされます。

- ライブラリ内部: ADFライブラリJAR内にパッケージ化するときに、バインド・タスク・フローを内部にする場合は、「true」を選択します。デフォルト値は「false」です。
ADFライブラリJAR内でのバインド・タスク・フローのパッケージの詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。

8. バインド・タスク・フローを保存して閉じます。

24.6.5 URLによるバインド・タスク・フロー起動構成時の処理

JDeveloperはリモートWebアプリケーション内でバインド・タスク・フローに対するタスク・フロー・コール・アクティビティを起動するタスク・フローのソース・ファイルに、メタデータ・エントリを生成します。次の例は、タスク・フロー・コール・アクティビティのエントリを示しています。

<task-flow-call id="createOrder">
<task-flow-reference>
<document id="__6">myorders-task-flow.xml</document>
<id id="__5">myorders-task-flow</id>
</task-flow-reference>
<remote-app-url id="__7">#{myOrdersBean.createOrder}</remote-app-url>
</task-flow-call>

前述の例のcreateOrderメソッドは、バインド・タスク・フローの起動に必要なURL構文とともに文字列を返します。返される文字列に必要な部分の説明とURLの例を含むURL構文の詳細は、「URLを使用したバインド・タスク・フローのコールに関する必知事項」を参照してください。

JDeveloperはバインド・タスク・フローのソース・ファイル構成時にも、そこにエントリを生成し、URLでコールできるようにします。次の例は、URLによるバインド・タスク・フローの起動を許可するメタデータ・エントリ例を示しています。

<task-flow-definition id="task-flow-definition3">
<visibility id="__2">
<url-invoke-allowed/>
<library-internal/>
</visibility>
</task-flow-definition>

24.6.6 URLを使用したバインド・タスク・フローのコールに関する必知事項

ローカル・アプリケーションのデプロイメント記述子にコンテキスト・パラメータを追加することで、リモートWebアプリケーションとの対話管理が容易になります。

リモートWebアプリケーションのコンテキスト・パラメータ

URLを使用して別なFusion Webアプリケーション(リモート・アプリケーション)内のバインド・タスク・フローを起動する場合は、Fusion Webアプリケーション(ローカル・アプリケーション)のデプロイメント記述子(web.xml)へのコンテキスト・パラメータの追加をお薦めします。コンテキスト・パラメータ値をリモート・アプリケーションのURLに設定します。ローカル・アプリケーションでEL式を記述する際は、次の例のようにコンテキスト・パラメータ名を使用します。ここでremoteAppUrlはコンテキスト・パラメータ名です。

#{initParam.remoteAppUrl}

リモート・アプリケーションのURLが変更した場合は、コンテキスト・パラメータを更新して、変更後のURLを参照させます。

パラメータ・コンバータのオブジェクト型

パラメータ・コンバータを指定している場合は、そのコンバータを使用して、URLで使用されている文字列表現とタスク・フロー・パラメータ値の間で変換が行えます。パラメータ・コンバータは以下の型のオブジェクトを評価するEL式です。

oracle.adf.controller.UrlParameterConverter

パラメータ・コンバータを指定しない場合は、デフォルト・コンバータがパラメータにcross-site-scripting (XSS)攻撃がないことを確認します。アプリケーション内で使用されているパラメータに特殊文字が含まれていることがわかっている場合は、UrlParameterConverterを独自に実装し、タスク・フロー・パラメータ値の変換に使用する必要があります。

バインド・タスク・フローを起動するURL構文

一般的には、マネージドBeanメソッドを参照し、URLの必要な部分を取得するEL式を記述します。または、次の例のようにURLを直接返すEL式を記述することもできます。

http://somecompany.com/internalApp/MyApp/faces/adf.task-flow?adf.tfId=displayHelp&
adf.tfDoc=%2FWEB-INF%2Fdisplayhelp.xml&topic=createPurchaseOrder

例24-6では、バインド・タスク・フローを起動するURL構文部分を説明します。

次のリストで、例24-6のURL構文の各部分を説明します。

- <server root>: サイトまたは管理者レベルでカスタマイズして提供されます。次に例を示します。
http://mycompany.com/internalApp

<server root>の値は、バインド・タスク・フローをデプロイするアプリケーション・サーバーによって異なります。バインド・タスク・フローのURLは、JSFサーブレットのURLパス内のリソースです。

- <app context>: Webアプリケーションのコンテキスト・ルートです(例: MyApp)。コンテキスト・ルートはWebアプリケーションのベース・パスです。

- faces: Facesサーブレット・マッピングです。

- adf.task-flow: リモートWebアプリケーションのADFコントローラを識別する予約キーワードです。

- adf.tfId: コールするタスク・フローのIDを提供するURLパラメータ。

- <task flow ID>: コール先のバインド・タスク・フローの識別子(例: displayHelpなど)。これは、ローカルでコールするときに使用するタスク・フローIDと同じIDです。この識別子はタスク・フロー・コール・アクティビティのインスタンスIDとは異なることに注意してください。このパラメータ値は文字列で表される必要があります。

- adf.tfDoc: コールするバインド・タスク・フローのIDが含まれたドキュメント名を提供するURLパラメータ。

- <document name>: コール先のバインド・タスク・フローのIDを含むドキュメントの名前(例: %2FWEB-INF%2FtoUppercase%2FdisplayHelp.xml)。バインド・タスク・フローのURLを自分で作成する場合、適切なエンコーディングを設定します。

- <named parameter>: (オプション)コール先のバインド・タスク・フローの入力パラメータ定義の名前(例: topic)。必要な入力パラメータ定義をすべて指定する必要があります。

- <named parameter value>: (オプション)入力パラメータの値です。

注意:

アンダースコア(_)で始まるURLパラメータ名は、内部用に限定されているため、使用しないでください。ADFコントローラによって生成されたURLにこれらの名前が表示されても、使用または依存しないでください。

例24-6 名前付きパラメータを使用してバインド・タスク・フローをコールするURL構文

<server root>/<app_context>/faces/adf.task-flow?adf.tfid=<task flow definition ID>&adf.tfDoc=<document name>&<named parameter>=<named parameter value>

24.6.7 タスク・フロー・コール・アクティビティにbefore listenerおよびafter listenerを指定する方法

タスク・フロー・コール・アクティビティのbefore listenerとafter listenerを使用して、バインド・タスク・フローの開始と終了を識別します。タスク・フロー・コール・アクティビティにリスナーを指定すると、コール先のバインド・タスク・フローの特定の使用方法に対してそのリスナーが実行されます。

たとえば、バインド・タスク・フローの開始時または終了時にコールされるメソッドのEL式として次のようにリスナーを指定します。

<before-listener>#{global.showState}</before-listener}>

このメソッドにパラメータは指定できません。

- Before listener: バインド・タスク・フローの開始前にコールされるJavaメソッドのEL式。コール元で、バインド・タスク・フローの開始時を把握する必要がある場合に使用されます。

- After listener: バインド・タスク・フローから戻った後にコールされるJavaメソッドのEL式。コール元で、バインド・タスク・フローを終了してコール元に制御フローが戻ったときを認識する必要がある場合に使用されます。

複数のbefore listenerまたはafter listenerを指定した場合、バインドなしタスク・フローまたはバインド・タスク・フローのソース・ドキュメントにおける記述順でコールされます。タスク・フロー・コール・アクティビティは、before listenerとafter listenerを1つずつしか保持できません。

タスク・フロー・コールのafter listenerをコールするには、制御フロー・ルールを使用してバインド・タスク・フローから制御フローが戻される必要があります。エンド・ユーザーが、ブラウザの「戻る」ボタンまたは他のURLを使用してバインド・タスク・フローから離れた場合、タスク・フロー・コールのafter listenerはコールされません。バインド・タスク・フローのファイナライザを使用して、取得しているリソースをすべて解放し、エンド・ユーザーがブラウザの「戻る」ボタンをクリックして離れたバインド・タスク・フローのクリーンアップを実行する必要があります。

始める前に:

タスク・フロー・コール・アクティビティとタスク・フローとの対話方法を理解しておくと役に立つ場合があります。詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

タスク・フロー・コール・アクティビティにbefore listenerまたはafter listenerを指定するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、コール元タスク・フローをダブルクリックします。

2. コール元のバインド・タスク・フローのダイアグラムで、タスク・フロー・コール・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「リスナー」セクションを開き、「リスナーの前」プロパティまたは「リスナーの後」プロパティのどちらかの式ビルダーを開きます。式ビルダーを開くには、プロパティ・フィールド上にカーソルを置いたときに表示されるアイコンをクリックして起動されるポップアップ・メニューから、「メソッド式ビルダー」を選択します。

式ビルダーを使用して、そのリスナーのメソッドを含むJavaクラスにナビゲートします。たとえば、次のようなEL式を作成できます。

#{pageFlowscope.managedBean.methodListener}

4. 「OK」をクリックします。

24.6.8 タスク・フロー・コール・アクティビティ追加時の処理

タスク・フロー・コール・アクティビティをタスク・フロー・ダイアグラムに追加した後、「タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール方法」で説明したいずれかの方法で、コール先のバインド・タスク・フローへの参照を指定する必要があります。たとえば、既存のバインド・タスク・フローをタスク・フロー・コール・アクティビティにドロップすると、JDeveloperではタスク・フロー参照が自動的に生成されます。タスク・フロー参照は、コール先のバインド・タスク・フローを起動するために使用されます。

タスク・フロー参照が静的の場合は、各タスク・フロー参照は次から構成されます。

- ドキュメント: コール先のバインド・タスク・フローのIDを記述したXMLソース・ファイルの名前。ドキュメントを指定しない場合、adfc-config.xmlであると判断されます。
このドキュメントは物理XMLファイルで、MDSを介してアクセスできなければなりません。

- ID: コール先のバインド・タスク・フローのXMLソース・ファイルに記述されているバインド・タスク・フローのIDです。たとえば、コール先のタスク・フローにはtargetFlowというidがある場合があります。同じXMLソース・ファイルには複数のバインド・タスク・フローを含めることができ、各タスク・フローが一意のIDで識別されます。

注意:

JDeveloperを使用してバインド・タスク・フローを作成した場合、バインド・タスク・フローは各ドキュメントに1つのみです。

次の例は、タスク・フロー・コール・アクティビティ内の静的なタスク・フロー参照の例を示しています。バインド・タスク・フローを起動するには、そのフローのIDと、IDが記述されているファイルの名前(<document>)を把握している必要があります。

<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2" id="__1">
...
<task-flow-definition id="task-flow-definition">
<default-activity>view1</default-activity>
<task-flow-call id="taskFlowCall">
<task-flow-reference>
<document>/WEB-INF/called-task-flow-definition.xml</document>
<id>called-task-flow-definition</id>
</task-flow-reference>
</task-flow-call>
</task-flow-definition>
...
</adfc-config>

次の例は、タスク・フロー・コール・アクティビティ内の動的タスク・フロー参照用にJDeveloperが生成するメタデータを示しています。

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2"
id="__1">
<task-flow-definition id="bounded_tf">
<default-activity id="__2">taskFlowCall1</default-activity>
<task-flow-call id="taskFlowCall1">
<dynamic-task-flow-reference id="__3">#{EL_Expression_Retrieve_
TaskflowID}</dynamic-task-flow-reference>
</task-flow-call>
</task-flow-definition>
</adfc-config>

24.6.9 実行時に行われる処理: タスク・フロー・コール・アクティビティがタスク・フローを起動する方法

ADFコントローラでは、タスク・フロー・コール・アクティビティを使用してバインド・タスク・フローがコールされたときに次の手順が実行されます。

1. ユーザーにバインド・タスク・フローをコールする権限があることを確認します。

2. 指定した場合、タスク・フロー・コール・アクティビティのbefore listener (1つ以上)を起動します(「タスク・フロー・コール・アクティビティにbefore listenerおよびafter listenerを指定する方法」を参照)。

3. バインド・タスク・フローの入力パラメータ値を評価します。

4. コール先のバインド・タスク・フローをスタックに格納して、そのページ・フロー・スコープを初期化します。

5. コール先のバインド・タスク・フローのコンテキストに入力パラメータ値を設定します。

6. バインド・タスク・フローのイニシャライザ・メソッドを指定している場合は、そのメソッドを起動します。

7. バインド・タスク・フローのデフォルト・アクティビティを実行します。

24.7 タスク・フロー・リターン・アクティビティの使用

タスク・フロー・リターン・アクティビティは、アプリケーションの制御フロー内で、バインド・タスク・フローが完了してコール元に制御フローが戻される場所を識別します。タスク・フロー・リターン・アクティビティは、バインド・タスク・フロー内でのみ使用できます。

タスク・フロー・リターン・アクティビティ・アイコンを囲むグレーの円は、そのアクティビティがバインド・タスク・フローの終了ポイントであることを示します。各バインド・タスク・フローには、ゼロから複数のタスク・フロー・リターン・アクティビティを指定できます。図24-11は、commitおよびrollbackという名前のタスク・フロー・リターン・アクティビティを含む、Summit ADFタスク・フロー・サンプル・アプリケーション内のorders-select-many-items.xmlバインド・タスク・フローを示しています。

各タスク・フロー・リターン・アクティビティには、コール元のタスク・フローに戻されるoutcomeを指定します。たとえば、図24-11には、Summit ADFタスク・フロー・サンプル・アプリケーションにあるタスク・フロー・リターン・アクティビティが示されています。このタスク・フロー・リターン・アクティビティの「結果」の「名前」プロパティの値は、commitです。

図24-11 複数のタスク・フロー・リターン・アクティビティ

起動するタスク・フローに戻されるoutcomeは、エンド・ユーザー・アクションによって異なります。起動元のタスク・フローによって次のアクションを決定するように、起動元のタスク・フローの制御フロー・ケースを構成できます。制御フロー・ケースの「結果(自)」プロパティをタスク・フロー・リターン・アクティビティのoutcomeからの戻り値に設定し、結果に基づくアクションを起動します。これにより、コール先タスク・フローからの戻り値に基づいて制御フローが決まります。

「セーブポイントのリストア」プロパティの値を設定して、バインド・タスク・フローの終了時に、タスク・フロー・リターン・アクティビティを使用して、バインド・タスク・フロー内で行われたモデル変更を保存または破棄するように指定します。trueに設定すると、Fusion Webアプリケーションが最初にバインド・タスク・フローを開始した際に作成された、ADFモデルのセーブポイントまでトランザクションをロールバックします。デフォルト値はfalseです。このプロパティ値は、タスク・フロー・リターン・アクティビティがあるバインド・タスク・フローの開始時に新しいトランザクションが開始されない場合にのみ指定できます。詳細は、「バインド・タスク・フローでトランザクションを有効化する方法」を参照してください。

24.7.1 タスク・フロー・リターン・アクティビティをバインド・タスク・フローに追加する方法

「コンポーネント」ウィンドウからタスク・フロー・リターン・アクティビティをドラッグして、バインド・タスク・フローのダイアグラムにドロップします。

始める前に:

タスク・フロー・リターン・アクティビティとタスク・フローとの対話方法を理解しておくと役に立つ場合があります。詳細は、「タスク・フロー・リターン・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

タスク・フロー・リターン・アクティビティをバインド・タスク・フローに追加するには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、タスク・フロー・リターン・アクティビティを追加するバインド・タスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、「タスク・フロー・リターン」をドラッグして、ダイアグラムへドロップします。

3. 「プロパティ」ウィンドウで、「一般」セクションを開き、「名前」フィールドに結果を入力します。

タスク・フロー・リターン・アクティビティは、現在のバインド・タスク・フローが存在する場合に、この結果をコール元タスク・フローに返します。タスク・フロー・リターン・アクティビティごとに1つのみ結果を指定できます。コール元のタスク・フローには、戻された時点の制御フローを処理する制御フロー・ルールを定義する必要があります。詳細は、「タスク・フローに制御フロー・ルールを追加する方法」を参照してください。

4. 「動作」セクションを開き、「再入力」ドロップダウン・リストで、次のオプションのいずれかを選択します。

- <default> (結果に依存しません): 再開は結果に依存しません。

- reentry-allowed: バインド・タスク・フロー内の任意のビュー・アクティビティについて再開が許可されます。

- reentry-not-allowed: バインド・タスク・フローの再開は許可されません。
バインド・タスク・フローにreentry-not-allowedを指定しても、エンド・ユーザーはブラウザの「戻る」ボタンをクリックするとバインド・タスク・フロー内のページに戻れます。ただし、ユーザーがそのページでボタンのクリックなどなんらかの操作を行うと、バインド・タスク・フローを不正に再開したことを示す例外(InvalidTaskFlowReentryなど)がスローされます。実際の再開の条件は再開したページの送信時に識別されます。

バインド・タスク・フローの再開の詳細は、「バインド・タスク・フローの再開」を参照してください。

この選択により、エンド・ユーザーがブラウザの「戻る」ボタンをクリックして、バインド・タスク・フローを再度開始したときのデフォルトの動作を定義します。この選択は、タスク・フロー・リターン・アクティビティがあるバインド・タスク・フローにreentry-outcome-dependentが設定されている場合にのみ適用されます。詳細は、「バインド・タスク・フローの再開」を参照してください。

5. 「トランザクションの終了」ドロップダウン・リストから、次のいずれかのオプションを選択します。

- commit: 選択すると、既存のトランザクションをデータベースにコミットします。

- rollback: 選択したトランザクションをコール先のタスク・フローの以前のエントリまでロールバックします。これを指定すると、新しいトランザクションはバインド・タスク・フローに入って開始された当初の状態までロールバックされるため、トランザクションを取り消すのと同じ効果があります。
commitとrollbackのいずれも指定しないと、トランザクションはコール元のバインド・タスク・フローによって閉じられるまで開いたままになります。

6. In the R「セーブポイントのリストア」ドロップダウン・リストで、次のいずれかの条件に一致した場合に、trueを選択します。

- タスク・フロー・リターン・アクティビティがあるバインド・タスク・フロー上で、「常に新規トランザクションを開始」(new-transaction)が選択されていない場合があります。

- バインド・タスク・フロー内で行われたADFモデル変更を、フロー終了時にタスク・フロー・コール・アクティビティを使用して破棄する必要がある場合。トランザクションは、バインド・タスク・フローの開始時に作成されているセーブポイントまでロールバックされます。

詳細は、「バインド・タスク・フローでトランザクションを有効化する方法」を参照してください。

24.7.2 バインド・タスク・フローへのタスク・フロー・リターン・アクティビティ追加時の処理

JDeveloperは、「プロパティ」ウィンドウでタスク・フロー・リターン・アクティビティに構成した変更に対して、バインド・タスク・フローのソース・ファイルにメタデータ・エントリを生成します。次の例は、Summit ADFタスク・フロー・サンプル・アプリケーションのorders-select-many-items.xmlタスク・フローに出現するエントリを示しています。

<task-flow-return id="commit">
<outcome>
<name>commit</name>
<commit/>
</outcome>
</task-flow-return>
<task-flow-return id="rollback">
<outcome>
<name>rollback</name>
<rollback/>
</outcome>
</task-flow-return>

24.8 ページ定義ファイルのあるタスク・フロー・アクティビティの使用

ページ定義ファイルは、実行時にデータを移入するバインディング・オブジェクトを定義します。通常、Fusion Webアプリケーションで、ページのUIコンポーネントとデータ・コントロールをバインドするために使用されます。いくつかのタスク・フロー・アクティビティでも、ページ定義を使用してデータ・コントロールへのバインドが可能です。それらは次のとおりです。

- メソッド・コール
「データ・コントロール」パネルからタスク・フローにデータ・コントロール操作をドラッグ・アンド・ドロップして、メソッド・コール・アクティビティを作成するか、既存のメソッド・コール・アクティビティにドロップできます。いずれの場合も、メソッド・コール・アクティビティが、データ・コントロール操作にバインドされます。

- ルーター
ルーター・アクティビティにページ定義ファイルを関連付けることで、バインド・コンテナが作成されます。このバインド・コンテナは実行時にルーター・アクティビティ・ケースのEL式を評価し、ルーター・アクティビティが正しいバインド値を参照していることを確認します。各ルーター・アクティビティ・ケースは、EL式の評価結果がtrueかどうかを、outcomeに戻すように指定します。そのため、ページ定義ファイルには、trueまたはfalseの評価結果となるデータ・コントロール操作だけを追加します。

- タスク・フロー・コール
タスク・フロー・コール・アクティビティにページ定義ファイルを関連付けることで、バインド・コンテナが作成されます。実行時にタスク・フロー・コール・アクティビティから入力パラメータが渡されると、バインド・コンテナが起動します。バインド・コンテナはタスク・コール元のタスク・フローからコール先のタスク・フローに入力パラメータが渡される際に、フロー・コール・アクティビティがバインド値を参照する場合は、正しい値を参照していることを確認します。

- ビュー
ビュー・アクティビティをページ定義ファイルに直接関連付けることはできません。かわりに、ビュー・アクティビティが参照するページを関連付けます。

タスク・フローのダイアグラマ内で、上記のタスク・フロー・アクティビティ(ビュー・アクティビティを除く)のいずれかを右クリックすると、JDeveloperがコンテキスト・メニューにオプションを表示します(「ページ定義の作成」) 。ページ定義ファイルが作成されていない場合は、このオプションを使用して作成できます。ページ定義ファイルがある場合は、JDeveloperはページ定義ファイルに移動するためのすべてのタスク・フロー・アクティビティのコンテキスト・メニュー・オプション(「ページ定義に移動」)を表示します。ページ定義ファイルに関連付けられたメソッド・コール・アクティビティを右クリックして、JDeveloperでコンテキスト・メニュー・オプション(「バインディングの編集」)を表示することもできます。

ページ定義ファイルに関連付けられたタスク・フロー・アクティビティでは、タスク・フロー・アクティビティ・アイコンの右下にアイコンが表示されます。図24-12は、各タスク・フロー・アクティビティの例を示しています。

図24-12 ページ定義ファイルに関連付けられたタスク・フロー・アクティビティ

24.8.1 タスク・フロー・アクティビティにページ定義ファイルを関連付ける方法

JDeveloperにはタスク・フロー・アクティビティからアクセスできるコンテキスト・メニュー・オプションがあります。このコンテキスト・メニュー・オプションを使用して、タスク・フロー・アクティビティをページ定義ファイルに関連付けます。

始める前に:

タスク・フロー・アクティビティによるページ定義ファイルの使用方法を理解しておくと役に立つ場合があります。詳細は、「ページ定義ファイルのあるタスク・フロー・アクティビティの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「タスク・フロー・アクティビティの追加機能」を参照してください。

タスク・フロー・アクティビティにページ定義ファイルを関連付けるには:

1. 「アプリケーション」ウィンドウで、WEB-INFノードを開き、ページ定義ファイルを関連付けるタスク・フロー・アクティビティを含むタスク・フローをダブルクリックします。

2. ダイアグラムで、ページ定義ファイルを作成するタスク・フロー・アクティビティを右クリックし、「ページ定義の作成」を選択します。

3. 作成されたページ定義ファイルに、タスク・フロー・アクティビティの実行時に参照させたいバインドを追加します。

ページ定義ファイルの詳細は、「ページ定義ファイルの処理」を参照してください。

24.8.2 タスク・フロー・アクティビティへのページ定義ファイルの関連付け時の処理

設計時に、JDeveloperはタスク・フロー・アクティビティのページ定義ファイルを生成します。ページ定義ファイルのファイル名は、元のタスク・フローおよびタスク・フロー・アクティビティまたは起動するデータ・コントロール操作から構成されます。たとえば、taskflowName_taskflowName_methodCall1PageDef.xmlまたはtaskflowName_taskflowName_CreateInsertPageDef.xmlのような名前が付けられます。

JDeveloperは作成されたページ定義ファイル内で、タスク・フロー・アクティビティからバインドへのEL式も生成します。次の例は、CreateInsertアクション・バインドを参照するメソッド・コール・アクティビティを示しています。

<method-call id="CreateInsert">
<method>#{bindings.CreateInsert.execute}</method>
<outcome>
<fixed-outcome>CreateInsert</fixed-outcome>
</outcome>
</method-call>

実行時にバインド・コンテナは、タスク・フロー・アクティビティのEL式が正しい値を参照していることを確認します。

25 タスク・フローのパラメータの使用

この章では、Fusion Webアプリケーションで作成するビュー・アクティビティおよびADFバインド・タスク・フローでパラメータを構成する方法について説明します。これらの機能を使用することで、タスク・フローのデータを操作したり、1つまたは複数のトランザクションにまたがるタスク・フロー間でデータを共有したり、1つのタスク・フローから別のタスク・フローに戻される戻り値を構成したりできます。

この章の内容は次のとおりです。

- タスク・フローのパラメータの使用について

- ビュー・アクティビティへのパラメータ渡し

- バインド・タスク・フローへのパラメータ渡し

- バインド・タスク・フローの戻り値の構成

25.1 タスク・フローのパラメータの使用について

入力パラメータを受け取り、パラメータ値を戻すタスク・フローの機能によって、タスク・フローのデータを操作できるほか、タスク・フロー間でデータを共有できます。これらの機能を使用して、Fusion Webアプリケーションでのタスク・フローの再利用を最適化できます。

ビュー・アクティビティ入力ページ・パラメータは別名として使用できます。別名を使用すると、バインド・タスク・フロー入力パラメータをページ・パラメータにマップできるようになります。ビュー・アクティビティ入力ページ・パラメータは、コール元のタスク・フローで使用可能なマネージドBeanおよび情報をページ自体のマネージドBeanにマップします。ビュー・アクティビティから値を渡すには、値をpageFlowスコープまたはマネージドBeanに格納します。タスク・フローでのビュー・アクティビティの使用方法の詳細は、「ビュー・アクティビティの使用」を参照してください。

たとえば、ページではページ・パラメータとして#{pageFlowScope.empNo}を指定し、バインド・タスク・フローでは入力パラメータ定義の値として#{pageFlowScope.employeeID}を指定できます。

ビュー・アクティビティ入力ページ・パラメータのfrom-valueは#{pageFlowScope.employeeID}になり、to-valueは#{pageFlowScope.empNo}になると考えられます。これにより、ページ定義とバインド・タスク・フローの両方が再利用できるのは、それぞれで使用するコンテキストごとにパラメータを再定義する必要がないからです。

タスク・フロー内に含まれている他の値は、バインド・タスク・フローの入力パラメータ定義値のみでなく、入力ページ・パラメータにもマップできます。

25.1.1 タスク・フロー・パラメータのユース・ケースと例

図25-1は、pageFlowスコープ内のユーザーについての情報を保持する入力パラメータ定義を定義するタスク・フローを示しています。

図25-1 入力パラメータを定義するタスク・フロー

25.1.2 パラメータを使用したタスク・フローの追加の機能

パラメータを使用してタスク・フローを構成または使用する前に、他のOracle ADFの機能を理解しておくと役に立つ場合があります。さらに、構成後のタスク・フローで実行できる機能について読むことが必要な場合もあります。次に、関連する他の機能へのリンクを示します。

- データ・コントロールはタスク・フロー間で共有できます。データ・コントロールの共有の詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

- タスク・フローは、タスク・フローに登録されたマネージドBeanにアクセスできます。マネージドBeanとタスク・フローの詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

- バインド・タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

25.2 ビュー・アクティビティへのパラメータ渡し

図25-2は、入力ページ・パラメータ・マッピングの構成方法を示しています。pageFlowScope値またはマネージドBeanの値として、Employeeアクティビティにパラメータを渡すことができます。EL式またはリテラル式を使用して、Employeeアクティビティにパラメータを渡すことができます。Employeeアクティビティは、Targetアクティビティに渡す値をto-value要素に指定することによって、Targetアクティビティに値を渡すことができます。

図25-2 2つのアクティビティのあるタスク・フロー

25.2.1 ビュー・アクティビティにパラメータを渡す方法

パラメータを渡すビュー・アクティビティに1つまたは複数の入力ページ・パラメータを追加します。

始める前に:

ビュー・アクティビティの入力ページ・パラメータを定義する前に、利用可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、「ビュー・アクティビティへのパラメータ渡し」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「パラメータを使用したタスク・フローの追加の機能」を参照してください。

ビュー・アクティビティの入力ページ・パラメータを定義するには:

1. 「アプリケーション」ウィンドウで、パラメータを渡すビュー・アクティビティを含むタスク・フローのソース・ファイルをダブルクリックします。

2. 「プロパティ」ウィンドウで、タスク・フローのダイアグラムにあるビュー・アクティビティを選択して、「ページ・パラメータ」カテゴリを開きます。

3. 「入力ページ・パラメータ」リストで、「追加」アイコンをクリックし、次のように値を入力します。

- 値(自): EL式の評価時に、入力ページ・パラメータの値を受け取るビュー・アクティビティの場所を指定するEL式を記述します。たとえば、次のようなEL式を記述します。
#{pageFlowScope.EmployeeID}

「バインド・タスク・フローに入力パラメータを渡す方法」の説明に従って、タスク・フローに定義した入力パラメータの値に対応する「値(自)」に対してEL式を記述する場合は、タスク・フローに入力された値を受け取るビュー・アクティビティを構成できます。

- 値(至): EL式の評価時に、ビュー・アクティビティと関連付けられたページが入力ページ・パラメータの値を取得できる場所を指定するEL式を記述します。たとえば、次のようなEL式を記述します。
#{pageFlowScope.EmployeeNo}

25.2.2 ビュー・アクティビティにパラメータを渡すときの処理

次の例の説明のとおり、JDeveloperでは設計時にタスク・フローのソース・ファイルに対するエントリが記述されます。

<view id="reducedAccess">
<page>/secured/Information.jsf</page>
<input-page-parameter>
<from-value>#{res['infoUsage.reducedAccess.messageHeader']}</from-value>
<to-value>#{pageFlowScope.infoPageHeaderText}</to-value>
</input-page-parameter>
<input-page-parameter>
<from-value>#{res['infoUsage.reducedAccess.messageHeader']}</from-value>
<to-value>#{pageFlowScope.infoPageMsg}</to-value>
</input-page-parameter>
<input-page-parameter>
<from-value>info</from-value>
<to-value>#{pageFlowScope.infoPageType}</to-value>
</input-page-parameter>
</view>

実行時に、ビュー・アクティビティでは、<from-value>要素で指定した場所から入力パラメータの値が取得されます。ビュー・アクティビティによって、パラメータの値は、<to-value>要素で指定した場所にある関連付けられたページで利用可能になります。

25.2.3 パラメータ値の指定に関する必知事項

タスク・フロー・コール・アクティビティを使用してバインド・タスク・フローをコールするか、あるいはADFリージョンまたはADF動的リージョンでバインド・タスク・フローをレンダリングする場合は、標準EL式を使用してパラメータ値を指定できます。たとえば、次のEL式の構文を使用してパラメータを指定できます。

- #{bindings.bindingId.inputValue}

- #{CustomerBean.zipCode}

次の例は、ADFリージョンでレンダリングするタスク・フロー・バインディングのメタデータを示しています。

<taskFlow id="Department1" taskFlowId="/WEB-INF/Department.xml#Department"
xmlns="http://xmlns.oracle.com/adf/Controller/binding">
<parameters>
<parameter id="DepartmentId" value="#{bindings.DepartmentId.inputValue}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
</parameters>
</taskFlow>

inputValueをEL式に追加することで、実際のバインディング・オブジェクトではなく、バインディングの値をパラメータに確実に割り当てられます。

25.3 バインド・タスク・フローへのパラメータ渡し

コール先のバインド・タスク・フローは、コール元のタスク・フローまたはタスク・フロー・バインディングから入力パラメータを受け取ることができます。バインド・タスク・フローに入力パラメータを渡すには、次のうちの1つまたは複数を指定します。

- コール元のタスク・フローにあるタスク・フロー・コール・アクティビティの入力パラメータ
入力パラメータによって、パラメータ値を格納するコール元のタスク・フローの場所が指定されます。

- コール先のバインド・タスク・フローの入力パラメータ定義
入力パラメータ定義によって、実行時にコール先のバインド・タスク・フローがパラメータ値を取得できる場所が指定されます。

コール元のタスク・フローにあるタスク・フロー・コール・アクティビティで定義する入力パラメータおよびコール先のバインド・タスク・フローの入力パラメータ定義と同じ名前を指定します。これを行うことで、コール先のバインド・タスク・フローに入力パラメータ値をマップできます。

入力パラメータの値を参照するEL式を指定しない場合は、valueのEL式のデフォルト値を実行時に次のように設定します。

#{pageFlowScope.parmName}

ここで、parmNameは、入力パラメータ名に入力した値です。

コール先のバインド・タスク・フローの入力パラメータ定義では、必要に応じて入力パラメータを指定できます。入力パラメータが実行時または設計時に値を受け取らない場合、タスク・フローは、そのタスク・フローを含むFusion Webアプリケーションのログ・ファイル内に警告を生成します。必要に応じて指定しない入力パラメータは、タスク・フロー・コール・アクティビティの作成時に無視できます。

タスク・フロー・コール・アクティビティを使用してタスク・フローをコールする場合は、ADFリージョンのタスク・フローをコールしないかぎり、タスク・フロー・コール・アクティビティの入力パラメータを参照渡しまたは値渡しにできます。ADFリージョンでタスク・フローがレンダリングする場合は、タスク・フロー・コール・アクティビティは入力パラメータを参照渡しします。デフォルトでは、プリミティブ・タイプ(int、long、booleanなど)が値渡し(pass-by-value)されます。

「値渡し」チェックボックスは、プリミティブではなくオブジェクトにのみ適用され、参照渡しのデフォルト設定をオーバーライドするために使用されます。ただし、これらの2つを併用すると、パラメータが相互に参照する場合に予期しない動作につながる可能性があります。タスク・フロー・コール・アクティビティの入力パラメータAが値渡しで、タスク・フロー・コール・アクティビティの入力パラメータBが参照渡しの場合、BにAへの参照が含まれていると、AとBで2つの異なるインスタンスが生じる可能性があります。

「バインド・タスク・フローに入力パラメータを渡す方法」では、タスク・フロー・コール・アクティビティを使用して、コール元のタスク・フローからコール先のバインド・タスク・フローに入力パラメータを渡す方法が説明されています。コール元のタスク・フローのどのアクティビティからもパラメータ値を渡せますが、「バインド・タスク・フローに入力パラメータを渡す方法」で渡したパラメータには、コール元のタスク・フローにあるページの入力テキスト・フィールドの値が含まれています。

タスク・フロー・コール・アクティビティではなくURLを使用してバインド・タスク・フローをコールする場合は、URL自体にパラメータと値を渡します。詳細は、「URLを使用したバインド・タスク・フローのコール方法」を参照してください。

タスク・フロー間でパラメータとしてデータ・コントロールを明示的に受け渡すかわりに、コール先のバインド・タスク・フローのdata-control-scopeオプションを指定することで単にそれらを共有できます。詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

また、コール先のタスク・フローは、終了時にコール元のタスク・フローに値を戻すことができます。バインド・タスク・フローからの戻り値の詳細は、「バインド・タスク・フローの戻り値の構成」を参照してください。

25.3.1 バインド・タスク・フローに入力パラメータを渡す方法

コール元のタスク・フローとコール先のタスク・フローの値を定義します。

始める前に:

- バインド・タスク・フローを構成して入力パラメータを取得する前に、利用可能な構成オプションを理解しておくと有効な場合があります。詳細は、「バインド・タスク・フローへのパラメータ渡し」を参照してください。

- また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「パラメータを使用したタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

- コール元およびコール先のタスク・フローを作成します。
コール元のタスク・フローは、バインドまたはバインドなしにできます。コール先のタスク・フローはバインドにする必要があります。タスク・フローの作成の詳細は、「タスク・フローの作成」を参照してください。

- タスク・フロー・コール・アクティビティをコール元のタスク・フローに追加します。
図25-3には、ビュー・アクティビティがタスク・フロー・コール・アクティビティに制御を渡す例が示されています。

図25-3 コール元のタスク・フロー

入力パラメータをバインド・タスク・フローに渡すには:

1. 「アプリケーション」ウィンドウで、入力コンポーネント含むJSFページをダブルクリックします。このコンポーネントでは、実行時にパラメータとしてバインド・タスク・フローに渡される値をエンド・ユーザーが入力します。

コール元のタスク・フローにあるビュー・アクティビティによって、開いたJSFページを参照する必要があります。

2. エンド・ユーザーが実行時に値を入力したJSFページで入力テキスト・コンポーネントを選択します。

3. 「プロパティ」ウィンドウで、「共通」セクションを開いて、「値」フィールドに入力テキスト・コンポーネントの値を入力します。

EL式として、たとえば#{pageFlowScope.inputValue}などの値を指定できます。

4. 「アプリケーション」ウィンドウで、コール先のタスク・フローをダブルクリックします。

5. エディタ・ウィンドウで、「概要」タブをクリックします。

6. 概要エディタで、「パラメータ」ナビゲーション・タブをクリックし、「追加」アイコンをクリックして、「入力パラメータの定義」セクションにある新しいエントリを定義します。

7. 「名前」フィールドで、inputParm1などのパラメータ名を入力します。

8. 「値」フィールドで、パラメータ値を格納および参照するEL式、たとえば#{pageFlowScope.inputValue}を入力します。

9. 「アプリケーション」ウィンドウで、コール先のバインド・タスク・フローを起動するタスク・フロー・コール・アクティビティを含むコール元タスク・フローをダブルクリックします。

10. 「アプリケーション」ウィンドウで、コール元のタスク・フローのダイアグラムにあるタスク・フロー・コール・アクティビティの最上部に、コール先のバインド・タスク・フローをドラッグ・アンド・ドロップします。

ダイアグラムでタスク・フロー・コール・アクティビティの最上部にバインド・タスク・フローをドロップすると、バインド・タスク・フローを参照するタスク・フローが自動的に作成されます。図25-4に示すように、タスク・フロー参照にはバインド・タスク・フローのIDとドキュメント名が含まれます。バインド・タスク・フローのID (id)は、バインド・タスク・フローの<task-flow-definition>要素の属性です。ドキュメント名は、IDを含むタスク・フローのソース・ファイルを指します。

図25-4 タスク・フローの参照

11. タスク・フロー・コール・アクティビティの「プロパティ」ウィンドウで、「パラメータ」セクションを開いて、「入力パラメータ」セクションを表示します。

12. 入力パラメータを識別するnameを入力します。

入力パラメータを定義済のタスク・フロー・コール・アクティビティの上にバインド・タスク・フローをドロップしたため、名前はすでに指定されています。同じ入力パラメータ名を維持する必要があります。

13. パラメータの「value」に、#{pageFlowScope.parm1}などを入力します。

タスク・フロー・コール・アクティビティの入力パラメータの値によって、コール元のタスク・フローがパラメータ値を格納する場所が指定されます。

コール先のタスク・フローの入力パラメータ定義の値は、値が渡された後にコール先のバインド・タスク・フローの内で使用するために値が取得される場所を指定します。

14. 実行時、コール先のタスク・フローは入力パラメータを使用できます。コール先のタスク・フローの入力パラメータ定義でvalueとしてpageFlowScopeを指定したため、コール先のバインド・タスク・フローのどこでもパラメータ値を使用できます。たとえば、コール先のバインド・タスク・フローのビュー・アクティビティにパラメータ値を渡すことができます。詳細は、「ビュー・アクティビティ間での制御の受渡し時の処理」を参照してください。

25.3.2 バインド・タスク・フローに入力パラメータを渡すときの処理

JDeveloperでは、選択した値に基づいて、コール元のタスク・フローとコール先のタスク・フローのソース・ファイルに対しエントリを記述します。例25-1は、バインド・タスク・フローで指定された入力パラメータ定義を示しています。

例25-2は、例25-1で示したバインド・タスク・フローをコールするタスク・フロー・コール・アクティビティの入力パラメータ・メタデータを示しています。実行時に、タスク・フロー・コール・アクティビティはバインド・タスク・フローをコールして、そのvalue要素で指定された値を渡します。

例25-1 入力パラメータ定義

<task-flow-definition id="sourceTaskflow">
...
<input-parameter-definition>
<name>inputParameter1</name>
<value>#{pageFlowScope.parmValue1}</value>
<class>java.lang.String</class>
</input-parameter-definition>
...
</task-flow-definition>

例25-2 タスク・フロー・コール・アクティビティの入力パラメータ

<task-flow-call id="taskFlowCall1">
...
<input-parameter>
<name>inputParameter1</name>
<value>#{pageFlowScope.newCustomer}</value>
<pass-by-value/>
</input-parameter>
...
</task-flow-call>

25.4 バインド・タスク・フローの戻り値の構成

バインド・タスク・フローでは、パラメータ値をコール元のタスク・フローに返すように構成できます。「タスク・フロー・リターン・アクティビティの使用」の説明のとおり、バインド・タスク・フローがタスク・フロー・リターン・アクティビティを起動した場合は、バインド・タスク・フローが返す値は、コール元に返す結果を補うものとなります。値を返すには、次のものを構成する必要があります。

- コール先のバインド・タスク・フローでの戻り値の定義
戻り値の定義では、コール先のバインド・タスク・フローから戻す値を格納する場所が指定されます。

- コール元のタスク・フローにあるタスク・フロー・コール・アクティビティの戻り値(これにより、コール元のタスク・フローでは、戻された値を検出できる場所が識別されます)

コール元のタスク・フローにあるタスク・フロー・コール・アクティビティのすべての戻り値を識別しないことによって、コール元のタスク・フローでは、コール先のタスク・フローから返された戻り値の定義を無視するように構成できます。

タスク・フロー・コール・アクティビティは値を参照で戻します。これは、コール元のタスク・フローに戻す値のコピーを作成する必要がなくなるからです。

25.4.1 バインド・タスク・フローからの戻り値の構成方法

コール先のタスク・フローにある戻り値の定義を構成し、実行時に戻り値を取得するコール元のタスク・フローのタスク・フロー・コール・アクティビティにパラメータを追加します。

始める前に:

コール元のタスク・フローとコール先のタスク・フローとの間の対話について理解しておくと役に立つ場合があります。詳細は、「バインド・タスク・フローの戻り値の構成」を参照してください。

また、他のタスク・フローの機能やパラメータを使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「パラメータを使用したタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

- バインド・タスク・フローまたはバインドなしタスク・フローを(コール元のタスク・フローに対して)作成し、バインド・タスク・フローを(コール先のタスク・フローに対して)作成します。詳細は、「タスク・フローの作成」を参照してください。

コール先のバインド・タスク・フローの戻り値を構成するには:

1. 「アプリケーション」ウィンドウで、コール先のタスク・フローをダブルクリックします。

2. エディタ・ウィンドウで、「概要」タブをクリックします。

3. 概要エディタで、「パラメータ」ナビゲーション・タブをクリックします。

4. 「パラメータ」ページで、「戻り値の定義」セクションの「追加」アイコンをクリックし、次の値を追加して戻り値を定義します。

- 名前: 戻り値を識別するために名前を入力します。たとえば、returnValue1などです。

- クラス: 戻り値のデータ・タイプを定義するJavaクラスを入力します。デフォルト値はjava.lang.Stringです。

- 「値」: 戻り値を読み取る場所を示すEL式を入力します。たとえば、次のようにEL式を入力します。
#{pageFlowScope.ReturnValueDefinition}

5. 「アプリケーション」ウィンドウで、コール元のタスク・フローをダブルクリックします。

6. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、タスク・コール・アクティビティをドラッグして、ダイアグラムへドロップします。

7. タスク・フロー・アクティビティの「プロパティ」ウィンドウで、「パラメータ」セクションを開いて、「戻り値」エントリの隣にある「追加」アイコンをクリックし、戻り値を定義する次の値を追加します。

- 名前: 戻り値を識別するために名前を入力します。たとえば、returnValue1などです。
手順4で戻り値の定義を定義した場合は、入力する値と「名前」フィールドに入力した値は一致する必要があります。

- 「値」: 戻り値を格納する場所を示すEL式を入力します。たとえば、次のようにEL式を入力します。
#{pageFlowScope.ReturnValueDefinition}

手順4で戻り値の定義を定義した場合は、入力する値と「値」フィールドに入力した値は一致する必要があります。

25.4.2 バインド・タスク・フローからの戻り値を構成したときの動作

設計時にJDeveloperでは、構成したタスク・フローのソース・ファイルに対してエントリを記述します。次の例は、コール元のタスク・フローのソース・ファイルに対してJDeveloperで記述したエントリを示しています。

<task-flow-call id="taskFlowCall1">
<return-value id="__3">
<name id="__4">returnValue1</name>
<value id="__2">#{pageFlowScope.ReturnValueDefinition}</value>
</return-value>
</task-flow-call>

次の例は、コール先のタスク・フローのソース・ファイルに対してJDeveloperで記述したエントリを示しています。

<return-value-definition id="__2">
<name id="__3">returnValue1</name>
<value>#{pageFlowScope.ReturnValueDefinition}/</value>
<class>java.lang.String</class>
</return-value-definition>

実行時に、コール先のタスク・フローが値を返します。この構成の場合は、コール元のタスク・フローにあるタスク・フロー・コール・アクティビティがその値を取得します。

26 リージョンとしてのタスク・フローの使用

この章では、Fusion Webアプリケーションで、ADFリージョンを使用してページまたはページ・フラグメントにADFタスク・フローをレンダリングする方法を説明します。パラメータの指定、ADFリージョンのリフレッシュまたは起動方法、親ページへの移動、動的ADFリージョンの作成などの主要機能についても説明します。

この章の内容は次のとおりです。

- ADFリージョンでのタスク・フローの使用について

- ADFリージョンの作成

- ADFリージョンのパラメータの指定

- パラメータ・マップを使用したADFリージョンのパラメータの指定

- ADFリージョンのリフレッシュの構成

- ADFリージョンのアクティブ化の構成

- ADFリージョンのタスク・フロー外への移動

- ADFリージョンのトランザクション管理の構成

- ADF動的リージョンの作成

- ADF動的リージョンへのタスク・フローの追加

- 複数の不明なリージョンをレンダリングするページの構成

- 未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理

- Fusion Webアプリケーションでのリモート・リージョンの作成

26.1 ADFリージョンでのタスク・フローの使用について

ADFリージョンを使用して、JSFページまたはページ・フラグメント(.jsff)にバインド・タスク・フローを実行できます。バインド・タスク・フローをADFリージョンとして実行する主な理由として、再利用があります。特定のアプリケーション機能をバインド・タスク・フローおよびADFリージョンに分離することで、アプリケーション全体で再利用できます。バインド・タスク・フロー内のアプリケーション機能を抽出、構成およびパッケージ化すると、ADFリージョンを使用して他のページに追加できます。ADFリージョンは、必要に応じてどこでも再利用できます(つまり、親ページに依存しません)。さらに、親ページの表示をADFリージョンから分離することも可能で、メニュー、ボタンおよびナビゲーション領域はADFリージョンの表示内容に影響されません。バインド・タスク・フローを変更すると、変更内容はそのタスク・フローを使用するすべてのADFリージョンに適用されます。

ADFリージョンは次で構成されます。

- リージョンをレンダリングするページまたはページ・フラグメントに表示されるaf:regionタグ

- 次のパッケージのRegionModelを実装するインスタンス・オブジェクト
oracle.adf.view.rich.model

RegionModelの詳細は、Oracle ADF FacesのJava APIリファレンスを参照してください

- 次のいずれかを実行します。

- ADFリージョンで使用するバインド・タスク・フローを識別する、ページ定義内のタスク・フロー・バインディング(taskFlow)

- ADFリージョンで使用するバインド・タスク・フローのリストを識別する、ページ定義内の複数タスク・フロー・バインディング(multiTaskFlow)

初めてレンダリングされるときのADFリージョンのコンテンツは、バインド・タスク・フロー内の最初のビュー・アクティビティのものです。バインド・タスク・フローで使用するビュー・アクティビティは、ページではなくページ・フラグメントに関連付ける必要があります。

タスク・フロー・バインディングの入力パラメータまたはコンテキスト・イベントを使用して、ADFリージョンに値を渡すことができます。また、タスク・フロー・バインディングのparametersMapプロパティを構成すると、そのタスク・フロー・バインディングによってバインド・タスク・フローからADFリージョンへ渡される入力パラメータを指定できます。

ADFリージョンを構成して、リージョンのアクティブ化やリフレッシュのタイミングを指定できます。また、ADFリージョンおよびバインド・タスク・フローを構成することで、バインド・タスク・フロー内でナビゲーション・コントロールを停止させ、ADFリージョンを含むページに渡すこともできます。さらに、リージョンにレンダリングされるバインド・タスク・フローをタスク・フロー・バインディングが実行時に決定する動的リージョン(ADF動的リージョン)を作成し、動的リージョン・リンクを構成すると、実行時にADF動的リージョンにレンダリングされるバインド・タスク・フローをエンド・ユーザーが変更できるようになります。

図26-1は、ADFリージョンをホストするページのページ定義ファイルにあるタスク・フロー・バインディングを使用して、ADFリージョンによるバインド・タスク・フローの参照方法を示しています。

図26-1 バインド・タスク・フローを参照するADFリージョン

26.1.1 ページ・フラグメントおよびADFリージョンについて

ページ・フラグメントとは、別のJSFページのコンテンツとしてレンダリングするJSFドキュメント(ファイル拡張子は.jsff)です。ページ・フラグメントに複数のルート・コンポーネントを使用することはできません。ページ・フラグメントの表示パフォーマンスを最適化するために、複数のルート・コンポーネントを1つのルート・コンポーネントにラップすると役立ちます。また、ページ・フラグメントに1つのビジュアル・ルート・コンポーネントおよび(起動するまでエンド・ユーザーに表示されない)popupコンポーネントのみが含まれる場合も、これらのコンポーネントを1つのルート・コンポーネントにラップすることを検討してください。たとえば、bottomHeight属性を0ピクセルに設定して、popupコンポーネントをpanelStretchLayoutコンポーネントの一番下のファセットに配置します。

ページ・フラグメントに複数のルート・コンポーネントがある場合は、次の例に示すとおり、Fusion Webアプリケーションによって実行時にメッセージが記録されます(ここで、r1はページ・フラグメントをレンダリングするADFリージョンを識別します)。

<RegionRenderer> <encodeAll> The region component with id: r1 has detected a page
fragment with multiple root components. Fragments with more than one root
component may not display correctly in a region and may have a negative impact
on performance. It is recommended that you restructure the page fragment to have
a single root component.

ルート・コンポーネント要素を1つのみにすることとは別に、ページ・フラグメントには次のいずれのタグも含めることはできません。

- <af:document>

- <f:view>

- <f:form>

- <html>

- <head>

- <body>

これらのタグはドキュメント内で1回のみ使用可能で、JSFページでのネストはサポートされません。たとえば、ページに実装されたページ・フラグメントに<html>タグを含められないのは、JSFページにすでに存在するからです。

次の例は、単純なページ・フラグメントを示しています。JSFページとは異なり、<f:view>タグや<f:form>タグは含まれていません。

<?xml version='1.0' encoding='UTF-8'?>
<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
<af:button text="button 1" id="b1"/>
</ui:composition>

別のJSFページに含めるページ・フラグメントは、リージョン(af:regionタグ)内でネストする必要があります。JSFページにリージョンとして追加されるバインド・タスク・フローはページをコールできないため、ページ・フラグメントをコールする必要があります。

26.1.2 ビュー・ポートおよびADFリージョンについて

ビュー・ポートは、他のビュー・ポートに関係なく移動できる表示領域です。ブラウザ・ウィンドウとADFリージョンはいずれもビュー・ポートの例です。ルート・ビュー・ポートには、ブラウザ・ウィンドウのメイン・ページが表示されます。ルート・ビュー・ポートには、子ビュー・ポート(ページ上のリージョンなど)を含めることができますが、親ビュー・ポートはありません。

oracle.adf.controllerパッケージのViewPortContextインタフェースを実装するJavaクラスを使用すると、ビュー・ポートの詳細が表示されます。詳細は、Oracle ADF ControllerのJava APIリファレンスを参照してください。

26.1.3 タスク・フローおよびADFリージョンのユースケースと例

図26-2に、ADFタスク・フローのSummitサンプル・アプリケーションのedit-customer-task-flow-definition.xmlタスク・フローからの「一般情報」ページ・フラグメント(GeneralInfo.jsff)を示しています。このタスク・フローはADFリージョンでレンダリングし、認証されたユーザーが提供されたコントロールを使用して移動および編集可能な一連のページ・フラグメントで顧客に関する情報を表示します。このタイプのリージョンの作成の詳細は、「ADFリージョンの作成」を参照してください。

図26-2 Summit ADFタスク・フロー・サンプル・アプリケーションのADFリージョン

図26-2には、Welcomeとラベル付けされたshowDetailItemコンポーネントがレンダリングするADF動的リージョンで様々なタスク・フローを起動する(Register as EmployeeおよびRegister as Customerとラベル付けされた)リンクも示されています。このタイプのリージョンの作成の詳細は、「ADF動的リージョンの作成」を参照してください。

図26-3に、JDeveloperにおけるedit-customer-task-flow-definition.xmlタスク・フローを示します。エンド・ユーザーに顧客に関する情報を表示する3つのビュー・アクティビティが含まれます。

図26-3 ADFタスク・フローのADF Summitアプリケーションの顧客タスク・フローの編集

26.1.4 ADFリージョンにレンダリングされるタスク・フローの追加の機能

ADFリージョンにレンダリングされるタスク・フローが他のタスク・フローおよびADF機能とどのように対話するかを理解しておくと役立ちます。次に、関連する他の機能へのリンクを示します。

- ADFリージョンに表示されるバインド・タスク・フローおよび関連付けられているページ定義に対して、セキュリティを設定できます。ユーザーが表示する権限がないADFリージョンを含むページをエンド・ユーザーが表示すると、ADFリージョンのコンテンツは表示されません。認証メカニズムはトリガーされません。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

- タスク・フローはマネージドBeanを起動します。マネージドBeanの詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

- コンテキスト・イベントを使用して、バインド・タスク・フローと情報を交換できます。詳細は、「コンテキスト・イベントの使用方法」を参照してください。

26.2 ADFリージョンの作成

ADFリージョンを作成するには、ADFリージョンをレンダリングするページに対するビュー・アクティビティまたはタスク・フロー・コール・アクティビティが少なくとも1つ含まれているバインド・タスク・フローをドラッグ・アンド・ドロップします。これにより、作成されるADFリージョンには、実行時に表示されるコンテンツが必ず含まれます。

バインド・タスク・フローのビュー・アクティビティは、ページ・フラグメント(.jsff)に関連付ける必要があります。ページ・フラグメントではなくページに関連付けられたバインド・タスク・フローをドラッグ・アンド・ドロップしようとした場合、ADFリージョンを作成するためのポップアップ・メニューは表示されません。ページを使用するバインド・タスク・フローを、ページ・フラグメントを使用するものに変換できます。詳細は、「バインド・タスク・フローの変換方法」を参照してください。

ADFリージョンの作成用に表示されるポップアップ・メニューには、非動的リージョンおよび動的リージョンを作成するためのオプションが表示されます。動的リージョン(ADF動的リージョン)では、レンダリングされるバインド・タスク・フローは実行時に決まります。ADF動的リージョンの作成の詳細は、「ADF動的リージョンの作成」を参照してください。非動的リージョン(ADFリージョン)に表示されるバインド・タスク・フローは、設計時に決定します。

26.2.1 ADFリージョンの作成方法

「アプリケーション」ウィンドウからADFリージョンをレンダリングするページにバインド・タスク・フローをドラッグします。

始める前に:

ADFリージョンで使用するバインド・タスク・フローの要件を理解しておくと役に立つ場合があります。詳細は、「ADFリージョンの作成」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

- ページ・フラグメントに関連付けられている1つ以上のビュー・アクティビティ、またはビュー・アクティビティを伴うタスク・フローに対する1つのタスク・フロー・コール・アクティビティを持つ、バインド・タスク・フローを作成します。
詳細は、「タスク・フローの作成」を参照してください。

- ADFリージョンをホストするJSFページを作成します。
詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項を参照してください。

ADFリージョンを作成するには:

1. 「アプリケーション」ウィンドウで、ADFリージョンを検索するJSFページをダブルクリックします。

2. 「アプリケーション」ウィンドウで、JSFページにバインド・タスク・フローをドラッグ・アンド・ドロップして、ポップアップ・メニューから「作成」→「リージョン」を選択します。

3. 「タスク・フロー・バインディングの編集」ダイアログが表示される場合は、「OK」をクリックします。

「バインド・タスク・フローに入力パラメータを渡す方法」の説明のとおり、「タスク・フロー・バインディングの編集」ダイアログは、JSFページ上にドロップするバインド・タスク・フローで入力パラメータが定義されている場合に表示されます。

ADFリージョンのパラメータの指定の詳細は、「ADFリージョンのパラメータの指定」を参照してください。

図26-4 ADFリージョンの「タスク・フロー・バインディングの編集」ダイアログ

4. 「構造」ウィンドウで、追加したADFリージョンのノード(af:region)を右クリックし、「プロパティに移動」を選択します。

5. ADFリージョンの「プロパティ」ウィンドウのデフォルト値が自動的に移入される次のプロパティを、必要に応じて確認または変更します。

- ID: ADFリージョンを参照するためにJSFページで使用されるID(たとえば、r1)。

- 値: ADFリージョン・モデルへのEL参照(たとえば、#{bindings.region1.regionModel})。これはリージョンの動作を記述するリージョン・モデルです。

- レンダリング: true(デフォルト値)の場合、JSFページのレンダリング時にADFリージョンがレンダリングされます。

6. JSFページに関連付けられているビュー・アクティビティとADFリージョンの間でパラメータをマップする方法の詳細は、「ADFリージョンのパラメータの指定」を参照してください。

26.2.2 ADFリージョン作成時の処理

ADFリージョンを作成するためにバインド・タスク・フローをJSFページにドロップすると、ページにaf:regionタグが追加されます。af:regionタグは、RegionModelを実装するオブジェクトを参照します。次の例は、Summit ADFタスク・フロー・サンプル・アプリケーションのCustomers.jsffページ・フラグメントに表示されるaf:regionタグを示しています。

<af:region value="#{bindings.editcustomertaskflowdefinition1.regionModel}"
id="r2"/>

さらに、ADFリージョンをホストするページのページ定義ファイルに、タスク・フロー・バインディングが追加されます。次の例は、JDeveloperによって追加されるメタデータのサンプルを示しています。このタスク・フロー・バインディングにより、ADFリージョンとバインド・タスク・フローの間のブリッジが提供されます。これにより、ADFリージョンの特定のインスタンスが、関連付けられているバインド・タスク・フローにバインドされ、そのバインド・タスク・フローに固有のあらゆる情報が保持されます。taskFlowId属性により、バインド・タスク・フローのソース・ファイルのディレクトリ・パスおよび名前が指定されます。

<taskFlow id="editcustomertaskflowdefinition1"
taskFlowId="/WEB-INF/flows/edit-customer-task-flow-definition.xml#edit
-customer-task-flow-definition"
activation="deferred"
xmlns="http://xmlns.oracle.com/adf/controller/binding"/>

バインド・タスク・フローをJSFページにドロップした際、すべてのデータバインディングは保持されます。実行時、ADFリージョンを含むJSFページに対するリクエストは、最初はJSFページに対するその他のリクエストと同様に処理されます。JSFページ定義が実行されると、JSFページにデータがロードされます。親JSFページのコンポーネント・ツリーで<af:region>タグが検出されると、表示するコンテンツの最初のページ・フラグメントを特定するために、それが実行されます。コンテンツの最初のページ・フラグメントが特定されると、ページ・フラグメントから親JSFページのコンポーネント・ツリーへ、適切なUIコンポーネントが追加されます。

タスク・フロー・バインディングにより、そのタスク・フロー用に、現在のビュー・アクティビティを取得するための次のインタフェースを実装するオブジェクトが作成されます。

oracle.adf.controller.ViewPortContext

タスク・フロー・バインディングのtaskFlowId属性を使用して、次のいずれかに評価されるEL式を参照することもできます。

- java.lang.String

- oracle.adf.controller.TaskFlowId

この機能は、ADF動的リージョンを作成する場合に使用します。詳細は、「ADF動的リージョンの作成」を参照してください。

26.3 ADFリージョンのパラメータの指定

ADFリージョンによって参照されるタスク・フロー・バインディングに追加することで、バインド・タスク・フロー用に定義した入力パラメータをADFリージョンで使用可能にすることができます。メモリー・スコープ、マネージドBeanまたはADFバインディング・レイヤーで使用可能な入力パラメータを参照するには、EL式を使用します。

入力パラメータの指定は、ADFリージョンに情報を提供する方法の1つです。別の方法として、コンテキスト・イベントの使用があります。ADFリージョンに提供する情報の種類によって、情報提供の方法が決まります。たとえば、次を選択します。

- 入力パラメータ: 必要な情報がタスク・フローの最初にあり、この情報の値を変更するとタスク・フローの再開が必要になる場合に使用します。
たとえば、従業員の表を含むページがあるとします。このページのADFリージョンには、選択した従業員を福利厚生プログラムに登録するためのタスク・フローが含まれています。従業員の選択を変更すると、新たに選択した従業員について最初から福利厚生の登録タスク・フローを再開する必要があります。このユースケースでは、タスク・フローの入力パラメータを使用することが正しい判断です。

入力パラメータは、参照渡しでも値渡しでもかまいません。参照渡しの場合、選択した従業員の情報(姓など)に関するメイン・ページでの更新は、タスク・フローを再開しなくてもADFリージョンで実行されるタスク・フローに自動的に反映されます。

- コンテキスト・イベント: タスク・フローが開始されるまでは交換する情報を特定できず、情報を変更してもタスク・フローの再開が必要ない場合に使用します。たとえば、Summit ADFタスク・フロー・サンプル・アプリケーションの「Inventory Control」タブでは、あるリージョンの製品在庫に適したチャートを、別のリージョンでユーザーが選択する製品に応じて表示するために、コンテキスト・イベントを使用します。詳細は、「コンテキスト・イベントの使用方法」を参照してください。

ADFリージョンの作成およびタスク・フロー・バインディングの追加の詳細は、「ADFリージョンの作成」を参照してください。バインド・タスク・フローに入力パラメータを定義する方法の詳細は、「バインド・タスク・フローへのパラメータ渡し」を参照してください。

26.3.1 ADFリージョンにパラメータを指定する方法

メモリー・スコープ、マネージドBeanまたはADFバインディング・レイヤーで使用可能なパラメータをADFリージョンの入力として指定するには、EL式を使用します。

始める前に:

ADFリージョンのパラメータの指定に関する要件を理解しておくと役に立つ場合があります。詳細は、「ADFリージョンのパラメータの指定」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

ADFリージョンの入力パラメータを指定するには:

1. 「アプリケーション」ウィンドウで、ADFリージョンを保持するJSFページを右クリックし、「ページ定義に移動」を選択します。

2. 概要エディタの「バインディングと実行可能ファイル」ナビゲーション・タブをクリックし、パラメータを指定するタスク・フロー・バインディングを選択して、「編集」アイコンをクリックします。

3. 「タスク・フロー・バインディングの編集」ダイアログで、ADFリージョンを指定する各入力パラメータの値を取得するEL式を記述します。必須として定義したパラメータに対して、EL式を記述する必要があります。たとえば、次のようなEL式を記述します。

#{pageFlowScope.inputParameter1}

図26-5に、「バインド・タスク・フローへのパラメータ渡し」の説明のとおり、「入力パラメータ」セクションにバインド・タスクに対して定義された複数の入力パラメータをリストする「タスク・フロー・バインディングの編集」ダイアログを示します。

注意:

「タスク・フロー・バインディングの編集」ダイアログの「入力パラメータ・マップ」フィールドを使用して、マネージドBeanで指定された入力パラメータのリストを参照するEL式を記述できます。この機能の実装の詳細は、「パラメータ・マップを使用したADFリージョンのパラメータの指定」を参照してください。

図26-5 「タスク・フロー・バインディングの編集」ダイアログ

4. 「OK」をクリックします。

26.3.2 ADFリージョンのパラメータ指定時の処理

次の例のように、JSFページのページ定義に、taskFlow要素の子要素であるエントリが書き込まれます。

<taskFlow id="tflow_tf11"
taskFlowId="/WEB-INF/tflow_tf1.xml#tflow_tf1"
activation="deferred"
xmlns="http://xmlns.oracle.com/adf/controller/binding">
<parameters>
<parameter id="inputParameter1"
value="#{pageFlowScope.inputParameter1}"/>
<parameter id="inputParameter2"
value="#{pageFlowScope.inputParameter2}"/>
</parameters>
</taskFlow>

実行時に、EL式の値attributeで指定された値がADFリージョンに渡されます。

26.4 パラメータ・マップを使用したADFリージョンのパラメータの指定

「ADFリージョンのパラメータの指定」で説明している、タスク・フロー・バインディングにすべての入力パラメータを表示する方法に加えて(もしくはその代替方法として)、タスク・フロー・バインディングのparametersMapプロパティを使用してマネージドBean上のパラメータ・マップ・オブジェクトを指定できます。参照するパラメータ・マップ・オブジェクトは、次のインタフェースを実装するタイプであることが必要です。

java.util.Map

参照するパラメータ・マップ・オブジェクトにより、ADFリージョンに入力する値にマップされるキーが指定されます。この方法を使用すると、そのページのページ定義内でタスク・フロー・バインディング(taskFlow)要素または複数タスク・フロー・バインディング(multiTaskFlow)の下に表示されるparameter子要素の数が減ります。また、この方法ではADFリージョンに渡される入力パラメータをより柔軟に指定できます。特に、ここでは、ADF動的リージョンの各種タスク・フロー・バインディング間で、入力パラメータの個数としてADF動的リージョンにパラメータを渡す方法が異なる可能性が規定されています。詳細は、「ADF動的リージョンの作成」を参照してください。

ADFリージョンまたはADF動的リージョンのタスク・フロー・バインディングを構成して、パラメータ・マップを参照できます。また、複数タスク・フロー・バインディングを構成して、パラメータ・マップを参照できます。バインド・タスク・フローに対して定義する入力パラメータの名前と、パラメータ・マップ・オブジェクトで定義するキー名を、必ず一致させてください。

<parameter>要素および<parametersMap>要素にある同じid属性を使用してパラメータを指定する場合は、<parametersMap>要素が常に優先されます。これは、「ADF動的リージョンの作成」で説明するように、ADF動的リージョンを作成すると、<parametersMap>要素でパラメータの静的値をオーバーライドすることが必要となる可能性があるためです。

26.4.1 ADFリージョンの入力パラメータを指定するためのパラメータ・マップの作成方法

ADFリージョンに渡すキーと値のペアを定義するパラメータ・マップ・オブジェクトを参照するために、タスク・フロー・バインディングのparametersMapプロパティを構成します。

始める前に:

ADFリージョンへ入力パラメータを渡す際に使用できる構成オプションについて理解しておくと役に立つ場合があります。詳細は、「パラメータ・マップを使用したADFリージョンのパラメータの指定」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

- マネージドBeanを作成するか、java.util.Mapインタフェースを実装するオブジェクトが戻されるように既存のマネージドBeanを編集します。ADFリージョンに渡す値とともにキーと値のペアがオブジェクトによって戻されるように、マネージドBeanを構成します。マネージドBeanの詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

ADFリージョンの入力パラメータを指定するためのパラメータ・マップを作成するには:

1. 「アプリケーション」ウィンドウで、ADFリージョンを保持するJSFページを右クリックし、「ページ定義に移動」を選択します。

2. 概要エディタの「バインディングと実行可能ファイル」ナビゲーション・タブをクリックし、パラメータ・マップを指定するタスク・フロー・バインディングまたは複数のタスク・フロー・バインディングを選択して、「編集」アイコンをクリックします。

選択したタスク・フロー・バインディングのタイプにより、表示されるダイアログが決定されます。

3. 「タスク・フロー・バインディングの編集」ダイアログまたは「複数タスク・フロー・バインディングの編集」ダイアログで、「入力パラメータ・マップ」ドロップダウン・メニューから「式ビルダー」を選択します。

4. パラメータ・マップを参照するEL式を記述または作成します。たとえば、次のようなEL式を記述します。

#{pageFlowScope.userInfoBean.parameterMap}

5. 「OK」をクリックします。

26.4.2 入力パラメータを指定するためのパラメータ・マップ作成時の処理

実行時に、タスク・フロー・バインディングまたは複数タスク・フロー・バインディングによって、そのparametersMapプロパティに指定したEL式が評価されます。ADFリージョンでレンダリングするバインド・タスク・フローに対して定義された入力パラメータの名前と一致するキーのマネージドBeanからADFリージョンに値が返されます。

例26-1は、2つの値(isLoggedInおよびprincipalName)をparameterMapという名前のパラメータ・マップに書き込む、マネージドBeanのコード・スニペットを示しています。

図26-6は、例26-1に示したパラメータ・マップ・オブジェクト(parameterMap)を指定して、「式ビルダー」ダイアログを閉じた後の「タスク・フロー・バインディングの編集」ダイアログを示しています。「タスク・フロー・バインディングの編集」ダイアログの「入力パラメータ」フィールドには、このADFリージョン(checkout-flow)に関連付けらているバインド・タスク・フロー用に定義された入力パラメータが表示されています。タスク・フロー・バインディングにより、例26-1に示したマネージドBeanから、これらのパラメータの値が取得されます。

図26-6 タスク・フロー・バインディング上のパラメータ・マップを参照するEL式

次の例は、ADFリージョンをレンダリングするページのページ定義ファイルにあるタスク・フロー・バインディングで表示されるメタデータを示しています。タスク・フロー・バインディングのメタデータは、バインド・タスク・フロー(taskFlowId属性)およびマネージドBean (parametersMap)の両方を参照します。

<taskFlow id="checkoutflow1"
taskFlowId="/WEB-INF/checkout-flow.xml#checkout-flow"
activation="deferred"
xmlns="http://xmlns.oracle.com/adf/controller/binding"
parametersMap="#{pageFlowScope.userInfoBean.parameterMap}"/>

<parameterMap>要素は、ページ定義に指定します。

注意:

Refresh="ifNeeded"を指定した場合、パラメータは<parameterMap>要素内でサポートされません。リージョンのリフレッシュが必要かどうかを判断する唯一の条件は、RefreshConditionの評価によって戻されるブール値です。詳細は、「ADFリージョンのリフレッシュの構成に関する必知事項」を参照してください。

例26-1 パラメータ・マップを定義するマネージドBean

import java.util.HashMap;
import java.util.Map;

public class UserInfoBean {
private Map<String, Object> parameterMap = new HashMap<String, Object>();

public Map getParameterMap() {

parameterMap.put("isLoggedIn", getSecurity().isAuthenticated());
parameterMap.put("principalName", getSecurity().getPrincipalName());
return parameterMap;
}
}

26.5 ADFリージョンのリフレッシュの構成

ADFリージョンをリフレッシュするタイミングとタスク・フローを起動するかどうかを構成できます。ADFリージョンによってタスク・フローを起動できるのは、ADFリージョンがアクティブな状態のときのみです。非アクティブ状態のADFリージョンでは、タスク・フローを起動できず、参照先タスク・フローのIDのNULL値が親ページに戻されます。

26.5.1 ADFリージョンのリフレッシュの構成方法

ADFリージョンを非アクティブからアクティブの状態へ切り替えるタイミングを決定し、ADFリージョンをリフレッシュするタイミングを決定するには、ADFリージョンに関連付けられているタスク・フローのタスク・フロー・バインディングの値を設定します。

始める前に:

ADFリージョンで使用するバインド・タスク・フローの要件を理解しておくと役に立つ場合があります。詳細は、「ADFリージョンのリフレッシュの構成」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

ADFリージョンのリフレッシュを構成するには:

1. 「アプリケーション」ウィンドウで、ADFリージョンが含まれているページを選択し、右クリックして「ページ定義に移動」を選択します。

2. ページ定義ファイルで、図26-7に示すように、「実行可能ファイル」セクションのタスク・フロー・バインディングまたは複数タスク・フロー・バインディングを選択します。

図26-7 タスク・フロー・バインディング

3. ADFリージョンをリフレッシュする適切なオプションを選択します。

- タスク・フロー・バインディング・パラメータの値が変更されると、リフレッシュされます。
「プロパティ」ウィンドウで「リフレッシュ」ドロップダウン・リストから「ifNeeded」を選択します。

RefreshConditionプロパティの値を設定する場合は 「ifNeeded」を選択しないでください。RefreshConditionプロパティは、Refreshプロパティに「ifNeeded」を選択する場合は評価されません。

- 指定する条件がtrueを戻す場合にリフレッシュされます。
「プロパティ」ウィンドウで、RefreshConditionフィールドにブール値を返すEL式を記述します。EL式がtrueを返した場合は、ADFリージョンがリフレッシュされます。

4. 「プロパティ」ウィンドウで、次のリストの説明に従って、「アクティブ化」ドロップダウン・リストから値を選択します。

- conditional: タスク・フロー・バインディングのactiveプロパティの値として設定されたEL式によってtrueが戻された場合に、ADFリージョンがアクティブ化されます。

- deferred: アプリケーションのビュー・レイヤーでFacelets XHTMLページを使用し、Facelets XHTMLページによってviewIDが初めてリクエストされたときにADFリージョンをアクティブ化する場合は、このオプションを選択します。アプリケーションのビュー・レイヤーでJSPテクノロジが使用されている場合にこのオプションを選択すると、immediate(ADFリージョンがただちにアクティブになる)を選択した場合と同じ結果になりますが、これは、ADFリージョンの親コンポーネントがpopupまたはpanelTabbedコンポーネントでそのchildCreation属性がdeferredに設定されている場合を除きます。後者のシナリオが発生した場合は、親コンポーネント(popupまたはpanelTabbed)によって動作が決まります。
アプリケーションでFacelets XHTMLページが使用される場合は、このオプションを使用します。ADF FacesでのFaceletsの使用の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ADF FacesとJDeveloperのスタート・ガイド」を参照してください。

- immediate: ADFリージョンがただちにアクティブになります。これはデフォルト値です。

ドロップダウン・リストで選択した値により、ADFリージョンが非アクティブからアクティブの状態に切り替わるタイミングが決まります。ADFリージョンがタスク・フローを起動するには、アクティブ状態であることが必要です。

5. activationプロパティの値として「conditional」を選択した場合は、activeプロパティの実行時にブール値を戻すEL式を記述します。EL式によってtrueが戻されると、ADFリージョンはタスク・フローを起動します。

26.5.2 ADFリージョンのリフレッシュの構成に関する必知事項

ADFリージョンが最初にリフレッシュされるのは、リージョンが配置されている親JSFページが最初に表示されるときです。最初のリフレッシュでは、ADFリージョンのタスク・フロー・バインディングのパラメータ値がすべて親ページから渡されます。パラメータ値は、ADFリージョン内で初期ページ・フラグメントを表示するために使用されます。バインド・タスク・フローがページの初回作成時に使用できない入力パラメータ値に依存している場合は、NullPointerExceptionオブジェクトなどを使用して、入力パラメータ値がNULLのときにタスク・フローが正しく動作することを確認します。もしくは(または追加的に)、タスク・フロー・バインディングのactiveプロパティを構成して、入力パラメータが使用可能になるまでタスク・フローがアクティブ化されないようにしてください。

ADFリージョンのタスク・フロー・バインディングは、次のタスク・フロー・バインディング属性のいずれかに基づいて再度リフレッシュできます。

- taskFlowId
この属性により、バインド・タスク・フローのソース・ファイルのディレクトリ・パスおよび名前が指定されます。この属性値が変更されるとADFリージョンはリフレッシュされます。

- Refresh属性とRefreshCondition属性の両方が未指定(デフォルト)
タスク・フロー・バインディング属性のRefreshまたはRefreshConditionのどちらも指定していない場合は、タスク・フロー・バインディングのactiveプロパティの値を構成しないかぎり、ADFリージョンのリフレッシュは親ページの初回表示時に1回のみ行われます。

- RefreshCondition="#{EL.expression}"
RefreshConditionプロパティがtrueと評価される場合、ADFリージョンは1回のみリフレッシュされます。RefreshConditionはブール値で評価される必要があります。RefreshConditionの評価時にEL式でbindings変数が使用されていると、ADFリージョン内に表示されるページ・フラグメントではなく、親ページのバインディング・コンテナが参照されます。

RefreshConditionは、バインディング・パラメータの値の変更とは無関係です。タスク・フロー・バインディングのパラメータに変更がなければ、ADFリージョン内では何も変化しません。

- Refresh="ifNeeded"
タスク・フロー・バインディングのパラメータ値が変更されると、ADFリージョンはリフレッシュされます。ADFリージョンのタスク・フロー・バインディングにパラメータがない場合、Refresh="ifNeeded"はRefresh属性を指定していないのと同じことになります。

動的パラメータ・マップを使用してタスク・フロー・バインディングにパラメータを渡す場合、Refresh="ifNeeded"はサポートされません。その場合、RefreshCondition="#{EL.Expression}"を使用する必要があります。

パラメータ・マップを使用したパラメータ値の指定の詳細は、「パラメータ・マップを使用したADFリージョンのパラメータの指定」を参照してください。

Refresh="ifNeeded"プロパティはRefreshConditionよりも優先され、Refresh="ifNeeded"を設定する場合は、RefreshConditionは評価されません。

RefreshConditionの評価時にEL式でバインディング変数が使用されていると、ADFリージョン内に表示されるページ・フラグメントではなく、親ページのバインディング・コンテナが参照されます。ADFページ・ライフサイクルのPrepareRenderフェーズ中に式は評価されます。詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。

次の例は、ADFリージョンが追加されているページのページ定義にあるタスク・フロー・バインディングのサンプルを示しています。

<taskFlow id="Department1" taskFlowId="/WEB-INF/Department#Department"
xmlns="http://xmlns.oracle.com/adf/controller/binding">
<parameters>
<parameter id="DepartmentId" value="#{bindings.DepartmentId.inputValue}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
</parameters>
</taskFlow>

ADFリージョン内のデータ・コントロールをリフレッシュするために、ADFリージョンをリフレッシュする必要はありません。ADFのライフサイクルにおいて、更新対象のイテレータを通知するリフレッシュ・イベントは、ADFリージョンの現在のページのバインディング・コンテナに伝播されます。

26.6 ADFリージョンのアクティブ化の構成

ADFリージョンをアクティブ化するタイミングを構成できます。これは、ADFリージョンに含まれるタスク・フローをアクティブ化するタイミングの決定に影響を及ぼします。ADFリージョンのアクティブ化を構成することで、Fusion Webアプリケーションのページのパフォーマンスを最適化できます。たとえば、5つのADFリージョンを含むページが5つのタスク・フローを参照するとします。Fusion Webアプリケーション・ページのロード時にこれらの5つのタスク・フローが同時に実行されないようにするには、activationプロパティを構成してタスク・フロー実行のタイミングを指定します。

26.6.1 ADFリージョンのアクティブ化の構成方法

ADFリージョンに関連付けられているタスク・フロー・バインディングのactivationプロパティを構成して、ADFリージョンをアクティブ化するタイミングを指定します。

始める前に:

ADFリージョンのアクティブ化に関する構成オプションを理解しておくと役に立つ場合があります。詳細は、「ADFリージョンのアクティブ化の構成」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

ADFリージョンのアクティブ化を構成するには:

1. 「アプリケーション」ウィンドウで、ADFリージョンが含まれているページを選択し、右クリックして「ページ定義に移動」を選択します。

2. ページ定義ファイルで、図26-8に示すように、「実行可能ファイル」セクションのタスク・フロー・バインディングまたは複数タスク・フロー・バインディングを選択します。

図26-8 アクティブ化用に構成するADFリージョンのタスク・フロー・バインディング

3. 「プロパティ」ウィンドウで、次のリストの説明に従って、「アクティブ化」ドロップダウン・リストから値を選択します。

- conditional: タスク・フロー・バインディングのactiveプロパティの値として設定されたEL式によってtrueが戻された場合に、ADFリージョンがアクティブ化されます。

- deferred: アプリケーションのビュー・レイヤーでFacelets XHTMLページを使用し、Facelets XHTMLページによってviewIDが初めてリクエストされたときにADFリージョンをアクティブ化する場合は、このオプションを選択します。アプリケーションのビュー・レイヤーでJSPテクノロジが使用されている場合にこのオプションを選択すると、immediate(ADFリージョンがただちにアクティブになる)を選択した場合と同じ結果になります。
アプリケーションでFacelets XHTMLページが使用される場合は、このオプションを使用します。ADF FacesでのFaceletsの使用の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ADF FacesとJDeveloperのスタート・ガイド」を参照してください。

- immediate: ADFリージョンがただちにアクティブになります。これはデフォルト値です。

ドロップダウン・リストで選択した値により、ADFリージョンが非アクティブからアクティブの状態に切り替わるタイミングが決まります。ADFリージョンがタスク・フローを起動するには、アクティブ状態であることが必要です。

4. 「アクティブ化」ドロップダウン・リストの値としてconditionalを選択した場合は、activeプロパティの実行時にブール値を戻すEL式を記述します。EL式によってtrueが戻されると、ADFリージョンはタスク・フローを起動します。EL式によってfalseが戻された場合、ADFリージョンはADFリージョン内でアクティブだったタスク・フローを非アクティブ化します。

26.6.2 ADFリージョンのアクティブ化構成時の処理

ADFリージョンの実行時の動作は、activationプロパティ用に設定したオプションによって異なります。

図26-9は、ページにADFリージョン(タブ#1、タブ#2、タブ#3)がロードされるとADFリージョン内のすべてのタスク・フローが実行される、デフォルトの動作を示しています。

図26-9 ADFリージョンのデフォルトのアクティブ化

図26-10は、activationプロパティがdeferredに設定されており、アプリケーションでFaceletsが使用される場合の例を示しています。タブ#1およびタブ#2のリージョンがアクティブ状態にあるのは、エンド・ユーザーがこれらのリージョンに移動したためです。タブ#3のリージョンは非アクティブです。

図26-10 ADFリージョンの遅延アクティブ化

図26-11は、activationプロパティがconditionalに設定されており、activeプロパティが実行時にboolean値を戻すEL式に設定されている場合の例を示しています。タブ#1のリージョンがアクティブ状態にあるのは、activeプロパティ用に指定されたEL式によってtrueが戻されるためです。タブ#2およびタブ#3のリージョンが非アクティブ状態にあるのは、activeプロパティ用に指定されたEL式によってfalseが戻されるためです。

リージョンによってタスク・フローが非アクティブ化される(activeプロパティによって戻される値がtrueからfalseに変わる)と、次のイベントが発生します。

- アクティブなトランザクションを含むタスク・フローによって、そのトランザクションがロールバックされます。
タスク・フローのトランザクション・オプションの詳細は、「タスク・フローのトランザクションの管理」を参照してください。

- data-control-scopeの値がisolatedに設定されているデータ・コントロール・フレームがタスク・フローに含まれている場合は、そのデータ・コントロール・フレームおよびデータ・コントロール・フレーム内のすべてのデータ・コントロールが解放されます。
データ・コントロールの詳細は、「タスク・フロー間のデータ・コントロールの共有」および「データ・コントロールの共有およびトランザクションの管理に関する必知事項」を参照してください。

- ADF Controllerにより、リージョンのビュー・ポート・データ構造(pageFlowスコープおよびビュー・スコープを含む)が解放されます。
ビュー・ポートの詳細は、「ビュー・ポートおよびADFリージョンについて」を参照してください。メモリー・スコープの詳細は、「タスク・フローのメモリー・スコープに関する必知事項」を参照してください。

図26-11 ADFリージョンの条件付きアクティブ化

26.7 ADFリージョンのタスク・フロー外への移動

ADFリージョンで実行されるバインド・タスク・フローでは、その親ビュー・アクティビティのナビゲーションのトリガー、またはそのアプリケーションのルート・ページへの移動が必要な場合があります。そのどちらかのユースケースを実装する場合に構成するプロパティ(parent-outcomeおよびroot-outcome)は、親アクション・アクティビティによって公開されます。

たとえば、従業員情報、および従業員の登録ボタンを含むADFリージョンを表示するページがある場合は、parent-outcomeの値を指定できます。登録ページが完了してADFリージョンに戻ると、従業員情報ページは次の従業員でリフレッシュされます。

注意:

ADFリージョンから移動した場合、リージョンの状態は維持されません。

26.7.1 ADFリージョンのタスク・フロー外へのナビゲーションをトリガーする方法

ADFリージョンで実行されるバインド・タスクに親アクション・アクティビティを追加して、親のビュー・アクティビティへ移動するように構成します。

始める前に:

ADFリージョンのアクティブ化に関する構成オプションを理解しておくと役に立つ場合があります。詳細は、「ADFリージョンのアクティブ化の構成」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

ADFリージョンのタスク・フロー外へのナビゲーションをトリガーするには:

1. 「アプリケーション」ウィンドウで、ADFリージョンで実行されるバインド・タスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルから、「アクティビティ」グループにある「親アクション」をバインド・タスク・フローのダイアグラムにドラッグ・アンド・ドロップします。

3. バインド・タスク・フローのダイアグラムで、親アクション・アクティビティを選択します。

4. 「プロパティ」ウィンドウで、適切なオプションを選択します。

- 親結果: 親アクション・アクティビティが親ビュー・アクティビティへ移動するように、リテラル値を入力するか結果を戻すEL式を記述します。生成された結果は、ADFリージョンのバインド・タスク・フローではなく、親ビュー・アクティビティのタスク・フローに移動するために使用されます。
親ビュー・アクティビティのタスク・フローには、parent-outcomeに対して指定した値を受け入れる制御フロー・ケースまたはワイルドカード制御フロー・ルールを含める必要があります。

- ルート結果: 親アクション・アクティビティがアプリケーションのルート・ページへ移動するように、リテラル値を入力するか結果を戻すEL式を記述します。
たとえば、ADFリージョンからアプリケーションのホーム・ページに移動するには、図26-12の説明のように、「ルート結果」の値を指定します。

図26-12 ホーム・ページへの移動

注意:

「親結果」および「ルート結果」は相互に排他的です。

5. (オプション) 親アクション・アクティビティがparent-outcomeまたはroot-outcomeを適切なキューに追加した後のADFリージョン内のコントロール・フローの結果を指定するリテラル値を、「結果」フィールドに入力します。

outcome要素の指定が役立つのは、親アクション・アクティビティによって送られるparent-outcomeまたはroot-outcomeの結果として親ビュー・アクティビティまたはルート・ページが移動しない場合です。さらに、ADFリージョンにそのまま同じビューが表示されないようにする場合です。outcomeの値を指定しない場合、ADFリージョンのviewIdは変更されません。

26.7.2 タスク・フロー外へのナビゲーション構成時の処理

実行時に、親アクション・アクティビティ用に設定したプロパティ値に基づいて、バインド・タスク・フローのソース・ファイルにエントリが書き込まれます。次の例は、親アクション・アクティビティの「親結果」および「結果」プロパティのリテラル値を記述すると生成されるサンプル・エントリを示しています。

<parent-action id="parentAction1">
<parent-outcome>parent_outcome</parent-outcome>
<outcome id="__2">outcome</outcome>
</parent-action>

次の例は、親アクション・アクティビティの「ルート結果」および「結果」プロパティのリテラル値を記述すると生成されるサンプル・エントリを示しています。

<parent-action id="parentAction1">
<root-outcome>root_outcome</root-outcome>
<outcome id="__2">outcome</outcome>
</parent-action>

実行時、親アクション・アクティビティ用に構成したプロパティに応じて、バインド・タスク・フローは親ビュー・アクティビティまたはFusion Webアプリケーションのルート・ページへ移動します。

26.7.3 ページによるADFリージョンの機能の特定方法に関する必知事項

ページに含まれるADFリージョンの1つで現在使用できる機能の特定をページで行うことが必要な場合もあります。たとえば、queueActionEventInRegion()メソッドを使用して、現在の状態に基づいてページがADFリージョン内のコントロール・フローを初期化する必要がある場合です。親ページはリージョン機能を使用して、そのページの1つのリージョンについて、現在の状態に基づいて現在の結果を識別します。親ページに対して、リージョン内に結果の可能性があるかどうかが示されます。

次のシナリオに、アプリケーションでの一般的なリージョン機能の使用方法を示します。

1. ページ内のADFリージョンに、関連付けられているページ・フラグメントが表示されます。

2. ユーザーが、ADFリージョン内でボタンを選択したり、他のアクションを実行します。

3. 親ページにより、ADFリージョンの結果(リージョン機能)が識別されます。

4. ADFリージョンの機能に基づいて、親ページのボタンが更新されます。

ADFリージョンの機能を決定するEL式の構文は次のとおりです。

#{bindings.[regionId].regionModel.capabilities['outcome']}

regionIdはページ上のADFリージョン・コンポーネントのIDで、outcomeはADFリージョン内で検証される、可能性がある結果です。

リージョン機能では、EL式を介して、指定されたADFリージョンのregionModelを使用できることが求められます。EL式では、現在のバインディング・コンテナ以外のバインディング・コンテナにあるバインディングには、アクセスしないでください。リージョン機能は、使用できない場合があります。ADFリージョンがネストされており、現在のバインディング・コンテナ内でregionModelに到達できない場合などです。これは、ネストされたリージョンのネストされたバインディング・コンテナがまだ存在しないか、すでに解放されている可能性があるためです。

26.8 ADFリージョンのトランザクション管理の構成

「タスク・フローのトランザクションの管理」で説明するように、ADFコントローラ・レイヤーで、バインド・タスク・フローは、必要に応じて基礎となるADFモデル・レイヤーにトランザクションの独自の抽象化の実装を提供します。「タスク・フロー間のデータ・コントロールの共有」で説明するように、そのdata-control-scopeプロパティの値を設定することによって、タスク・フローがそのデータ・コントロールをコール元のタスク・フローと共有するか分離するかを選択できます。「データ・コントロールの共有およびトランザクションの管理に関する必知事項」で説明するように、タスク・フローによって新規トランザクションが作成されるかどうかは、transactionプロパティおよびdata-control-scopeプロパティに対して選択した値に応じて異なります。

たとえば、タスク・フローのデータ・コントロールをコール元タスク・フローと共有する場合、タスク・フローのtransactionオプションを「常に新規トランザクションを開始」 (new-transaction)または「可能であれば既存のトランザクションを使用」 (requires-transaction)に構成すると、ADFコントローラ・レイヤー・レベルで新規トランザクションが作成されます。requires-transactionオプションでは、トランザクションが存在していない場合にのみ新しいトランザクションが作成されます。作成されたトランザクションは、タスク・フローをレンダリングするADFリージョンと同じ存続期間を持ちます。これにより、タスク・フローがADFリージョンでレンダリングされる場合に意図しない動作を引き起こす場合があります。たとえば、ADFリージョンがリフレッシュされる場合は、ADFリージョンにレンダリングされるタスク・フローが再度開始され、次のイベントが発生します。

- ADFリージョンで使用する現在のビュー・ポートを破棄します。

注意:

セーブポイントでは、ルート・ビュー・ポートが機能する必要があります。ビュー・ポートの詳細は、「ビュー・ポートおよびADFリージョンについて」を参照してください。セーブポイントの詳細は、「タスク・フローでのセーブポイントの使用」を参照してください。

- タスク・フローで使用するデータ・コントロールを解放します。
これにより、ADFリージョンにレンダリングされるタスク・フローのデータ・コントロールが共有されるため、コール元のタスク・フローの親ページで行われた変更が失われる可能性があります。

- タスク・フローのタスク・フロー・リターン・アクティビティの「トランザクションの終了」プロパティがこれらのアクションのいずれかを指定する場合は、コミットまたはロールバックを実行します。詳細は、「タスク・フロー・リターン・アクティビティの使用」を参照してください。

ADFリージョンのリフレッシュによるタスク・フローのトランザクションの不注意による終了を回避する方法は多数あります。これらのすべてのオプションにより、ADFリージョンにレンダリングされるタスク・フローのトランザクションの存続期間とADFリージョンの存続期間の関連付けが解除されます。これらのオプションにより、リージョンの親ページがトランザクションを所有し、リージョンにレンダリングされる前にトランザクションが開始されることが確認されます。アプリケーションに最も適したオプションを選択します。

- ADFリージョンにレンダリングするタスク・フローのトランザクション・オプションを「常に既存のトランザクションを使用」(requires-existing-transaction)に設定します。これにより、トランザクションが存在しない場合に例外がスローされ、ADFリージョンがトランザクションを所有できなくなります。

- トランザクションの存続期間が親ページの存続期間に関連付けられるように、コール元のタスク・フローのトランザクション・オプションを「常に新規トランザクションを開始」(new-transaction)に設定します。

- リージョンを含む親ページに移動するアクションでDataControlFrameインタフェースのbeginTransaction()メソッドを起動します。

- ADFリージョンの親ページに移動する前に、リクエスト・スコープを使用してマネージドBeanからDataControlFrameインタフェースのbeginTransaction()メソッドを起動するメソッド・コール・アクティビティを構成します。
次のコードにより、トランザクションが開始されます。

public void beginTransaction()
{
BindingContext context = BindingContext.getCurrent();

String dcFrameName = context.getCurrentDataControlFrame();
DataControlFrame dcFrame = context.findDataControlFrame(dcFrameName);
dcFrame.beginTransaction(new TransactionProperties());
}

タスク・フローのデータ・コントロールをコール元のタスク・フローと共有する場合は、タスク・フローのタスク・フロー・リターン・アクティビティによって公開されるrollbackまたはcommitオプションを使用して、ADFモデル・レイヤーのDataControlFrameインタフェースによって公開されるメソッドをプログラム的に使用するのではなく、変更をコミットまたはロールバックします。DataControlFrameインタフェースによって公開されるメソッドを使用することにより、トランザクションは終了し、ADFリージョンにレンダリングされるタスク・フローによって新しいトランザクションを作成できます。

26.9 ADF動的リージョンの作成

ADF動的リージョンは、実行時に、タスク・フロー・バインディングによってtaskFlowId属性の値が動的に決定されるADFリージョンです。これにより、Fusion Webアプリケーションは、タスク・フロー・バインディングのtaskFlowId属性の評価結果に基づいて、ADF動的リージョン内で実行するタスク・フローを決定できます。

図26-13は、エンド・ユーザーがクリックするリンク・コンポーネントに応答して、index.jsfページの「Welcome」というラベルのshowDetailItemコンポーネントに異なる登録タスク・フローがレンダリングされる、Summit ADFタスク・フロー・サンプル・アプリケーションの実行時の例を示しています。たとえば、エンド・ユーザーが「Register as Employee」をクリックした場合は、アプリケーションでADF動的リージョンにemp-reg-task-flow-definition.xmlタスク・フローがレンダリングされます。エンド・ユーザーが「Register as a customer」をクリックした場合は、アプリケーションでADF動的リージョンにedit-customer-task-flow-definition.xmlタスク・フローがレンダリングされます。

実行時、ADF動的リージョンは、レンダリング準備ライフサイクル・フェーズでレンダリングされるタスク・フローを切り替えます。前のタスク・フローのコンポーネントがライフサイクル・フェーズにスムーズに追加されるように、JSFのアプリケーションの起動ライフサイクル・フェーズまではregionModelから移動しないでください。したがって、コンテキスト・イベントに応答して動的リージョン内のタスク・フローを移動しないことをお薦めします。ライフサイクル・フェーズの詳細は、「Fusionページ・ライフサイクルの理解」を参照し、コンテキスト・イベントの詳細は、「コンテキスト・イベントの使用方法」を参照してください。

図26-13 Summit ADFタスク・フロー・サンプル・アプリケーションのADF動的リージョン

ADF動的リージョンを作成するには、ADF動的リージョンをレンダリングするページへ、バインド・タスク・フローをドラッグ・アンド・ドロップします。バインド・タスク・フローのビュー・アクティビティは、ページ・フラグメント(.jsff)に関連付ける必要があります。

ページ・フラグメントではなくページに関連付けられたバインド・タスク・フローをドラッグ・アンド・ドロップしようとした場合、ADF動的リージョンを作成するためのポップアップ・メニューは表示されません。ページを使用するバインド・タスク・フローを、ページ・フラグメントを使用するものに変換できます。詳細は、「バインド・タスク・フローの変換方法」を参照してください。

「ADF動的リージョンへのタスク・フローの追加」で説明するように、ADF動的リージョンの作成後は、ADF動的リージョン・リンクを作成して動的リージョンにバインド・タスク・フローを追加できます。

26.9.1 ADF動的リージョンの作成方法

ADF動的リージョンをレンダリングするページへ、バインド・タスク・フローをドラッグ・アンド・ドロップします。

始める前に:

ADF動的リージョンを作成する際に使用できる構成オプションについて理解しておくと役に立つ場合があります。詳細は、「ADF動的リージョンの作成」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる他の機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

ADF動的リージョンを作成するには:

1. 「アプリケーション」ウィンドウで、ADF動的リージョンを作成するJSFページをダブルクリックします。

2. 「アプリケーション」ウィンドウで、JSFページに最初のバインド・タスク・フローをドラッグ・アンド・ドロップして、ポップアップ・メニューから「作成」→「動的リージョン」を選択します。

3. 「動的リージョンのマネージドBeanの選択」ダイアログで、適切なオプションを選択します。

- 既存のマネージドBeanにバインド・タスク・フローのIDを格納するには、「マネージドBean」ドロップダウン・リストから既存のマネージドBeanを選択します。
マネージドBeanからADF動的リージョンのタスク・フロー・バインディングへ、バインド・タスク・フローのID値が渡されます。選択するマネージドBeanが別のADF動的リージョンで使用されていないことを確認します。

- ページにマネージドBeanがない場合は、「マネージドBean」ドロップダウン・リストの横にある「追加」アイコンをクリックして、新たに作成します。次の手順で、表示されるダイアログに値を入力します。

a. Bean名: 新しいマネージドBeanの名前を入力します。たとえば、DynamicRegionBeanと入力します。

b. クラス名: 新しいマネージドBeanクラスの名前を入力します。

c. パッケージ: マネージドBeanを含むパッケージの名前を入力するか、参照して特定します。

d. 拡張対象: マネージドBeanで拡張するJavaクラスの名前を入力します。デフォルト値はjava.lang.Objectです。

e. スコープ: このフィールドは読取り専用であり、値はbackingBeanに設定されています。マネージドBeanのメモリー・スコープの詳細は、「タスク・フローのメモリー・スコープに関する必知事項」を参照してください。

f. 「OK」をクリックして、マネージドBeanを構成するダイアログを閉じます。

4. 「タスク・フロー・バインディングの編集」ダイアログで適切なオプションを選択します。

- ADF動的リージョンの入力パラメータまたは入力パラメータ・マップを指定しない場合は、「OK」をクリックします。

- ADF動的リージョンの入力パラメータを指定します。
詳細は、「ADFリージョンのパラメータの指定」を参照してください。

図26-14は、マネージドBeanの構成後に表示される「タスク・フロー・バインディングの編集」ダイアログを示しています。

注意:

「タスク・フロー・バインディングの編集」ダイアログの「入力パラメータ・マップ」フィールドを使用して、マネージドBeanで指定された入力パラメータのリストを参照するEL式を記述できます。この機能の実装の詳細は、「パラメータ・マップを使用したADFリージョンのパラメータの指定」を参照してください。

図26-14 ADF動的リージョンの「タスク・フロー・バインディングの編集」ダイアログ

5. 「OK」をクリックします。

26.9.2 ADF動的リージョン作成時の処理

ADF動的リージョンを作成するためにバインド・タスク・フローをJSFページにドロップすると、ページにaf:regionタグが追加されます。af:regionタグにはタスク・フロー・バインディングへの参照が含まれています。次の例は、Summit ADFタスク・フロー・サンプル・アプリケーションのindex.jsfページにADF動的リージョンをレンダリングするaf:regionタグを示しています。

<af:region value="#{bindings.dynamicRegion1.regionModel}" id="r4"
rendered="#{WelcomePageBean.isRegistration}"/>

さらに、ADF動的リージョンをホストするページのページ定義ファイルに、タスク・フロー・バインディングが追加されます。次の例は、JDeveloperによって追加されるメタデータのサンプルを示しています。このタスク・フロー・バインディングにより、ADF動的リージョンとバインド・タスク・フローの間のブリッジが提供されます。ADF動的リージョンがバインド・タスク・フローにバインドされ、そのバインド・タスク・フローに固有のあらゆる情報が保持されます。

<taskFlow id="dynamicRegion1"
taskFlowId="${WelcomePageBean.dynamicTaskFlowId}"
activation="deferred"
xmlns="http://xmlns.oracle.com/adf/controller/binding"/>

タスク・フロー・バインディング・メタデータのtaskFlowId属性により、ADF動的リージョンに関連付けられるバインド・タスク・フローを実行時に決定するマネージドBeanが指定されます。JDeveloperにより、このマネージドBeanが作成されるか、このデータを格納するために既存のマネージドBeanが変更されます。次の例は、JDeveloperによってマネージドBeanに書き込まれるコードの抜粋を示しています。

import oracle.adf.controller.TaskFlowId;
...
private String taskFlowId = "/directoryPath/toTaskFlow";
...
public TaskFlowId getDynamicTaskFlowId() {
return TaskFlowId.parse(taskFlowId);
}
...

実行時には、ADF動的リージョン内に表示されるバインド・タスク・フローのID (taskFlowId)が、マネージドBeanに格納されます。マネージドBeanは、様々なバインド・タスク・フローをADF動的リージョンのタスク・フロー・バインディングに切り替えます。

ADF動的リージョンが再初期化される場合、Fusion WebアプリケーションではADF動的リージョンに関連付けられているタスク・フロー・バインディングを再初期化する必要があります。その際、ADF動的リージョンに渡す新しい入力パラメータや入力パラメータ値があるかどうかが評価されます。

26.10 ADF動的リージョンへのタスク・フローの追加

ADF動的リージョン・リンクは、ADF動的リージョン内でバインド・タスク・フローを別のバインド・タスク・フローに切り替えます。エンド・ユーザーは、コマンド・コンポーネント(ボタンやリンク)をクリックして、ADF動的リージョンを新しいバインド・タスク・フローで更新します。

たとえば、ADF動的リージョンのバインド・タスク・フローにより、従業員に関する一般情報(IDや写真など)が表示されるとします。エンド・ユーザーが「詳細」というコマンド・コンポーネントをクリックすると、その従業員の詳細情報を含む別のバインド・タスク・フローの表で、ADF動的リージョンが更新されます。エンド・ユーザーのアクション(リンクのクリック)により、ADF動的リージョンのマネージドBean上のメソッドが起動します。新しいバインド・タスク・フローの値がメソッドに渡され、ADF動的リージョンは新しいバインド・タスク・フローでリフレッシュされます。その後、新しいバインド・タスク・フローがADF動的リージョン内に表示されます。

デフォルトでは、ADF動的リージョン・リンクは、バインド・タスク・フローを別のものに切り替えますが、再び元のバインド・タスク・フローに切り替えることはできません。元のバインド・タスク・フローに戻すには、クリック時に現在のタスク・フローを元のタスク・フローに切り替える2つ目のADF動的リージョン・リンクをページに追加します。

すでに1つ以上のADF動的リージョンがページにあり、同じページに新しいバインド・タスク・フローをADF動的リージョンとして追加する場合は、ADF動的リージョン・リンクを追加できます。図26-15のように、ページにバインド・タスク・フローをドロップして、ADF動的リージョン・リンクの作成を選択すると、現在ページ上にある動的リージョンがすべてメニューに表示されます。

ドキュメント内の既存の動的リージョンにオプションとして追加するバインド・タスクをドラッグ・アンド・ドロップするとメニューが表示され、そこから「動的リージョン・リンク」を選択すると、ドキュメントに含まれる現在の動的リージョンのリストが図26-15のように表示されます。

図26-15 「動的リージョン・リンク」メニュー

このメニューを使用して、バインド・タスク・フローの内容を表示するADF動的リージョンを選択します。

ヒント:

動的リージョン・リンクの値は他のUIコンポーネント内で使用できます。たとえば、リスト内の各項目が別のバインド・タスク・フローにリンクしている選択リストを作成できます。リンクされているバインド・タスク・フローはすべて同じ動的リージョンに表示されます。リンクにより、表示するバインド・タスク・フローを切り替えるために作成したマネージドBeanの背後で、クラス内のメソッドが実行されます。

26.10.1 ADF動的リージョン・リンクの作成方法

ADF動的リージョンがすでに含まれているページにバインド・タスク・フローをドラッグ・アンド・ドロップし、表示されるポップ・アップ・メニューで「動的リージョン・リンク」を選択して、リンクを作成できるADF動的リージョンのリストを表示します。

始める前に:

ADF動的リージョン・リンクを作成する前に必要な構成ついて理解しておくと役に立つ場合があります。詳細は、「ADF動的リージョンへのタスク・フローの追加」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

- ADF動的リージョン・リンクを作成するJSFページに最低1つのADF動的リージョンを追加します。JSFページへのADF動的リージョンの追加の詳細は、「ADF動的リージョンの作成」を参照してください。

ADF動的リージョン・リンクを作成するには:

1. 「アプリケーション」ウィンドウで、ADF動的リージョン・リンクを作成するJSFページをダブルクリックします。

2. 「アプリケーション」ウィンドウで、JSFページにバインド・タスク・フローをドラッグ・アンド・ドロップして、ポップアップ・メニューから「動的リージョン・リンク」を選択します。

注意:

バインド・タスク・フローのビュー・アクティビティは、ページ・フラグメントに関連付ける必要があります。ページを使用するバインド・タスク・フローを、ページ・フラグメントを使用するものに変換できます。詳細は、「バインド・タスク・フローの変換方法」を参照してください。

3. ページにすでに追加されているADF動的リージョンのリストが表示されるポップアップ・メニューで、バインド・タスク・フローの内容を表示するADF動的リージョンの名前を選択します。

4. 「OK」をクリックします。

26.10.2 ADF動的リージョン作成時の処理

次の例に示すように、ページへのリンクが追加されます。また、ADF動的リージョンのマネージドBeanが更新され、対応するタスク・フロー・バインディングが新しいパラメータで更新されます。

<af:link text="region2" action="#{RegionBean.region2}"
id="dynamicRegionLink1"/>

26.11 複数の不明なリージョンをレンダリングするページの構成

実行時にページにレンダリングされたリージョンの個数がわからない場合は、設計時にページを構成できます。たとえば、panelTabbedコンポーネントを使用してリージョンをタブに追加するかタブから削除することが必要な場合があります。追加または削除を行うタブでは、それぞれにバインド・タスク・フローを参照するリージョンがレンダリングされます。

この機能を実装するには、JSFページ定義ファイルのmultiTaskFlow要素を構成して、次のタイプのマネージドBeanに含まれるタスク・フローのリストを参照します。

oracle.adf.controller.binding.TaskFlowBindingAttributes

次の例は、2つのタスク・フローを含むリストを返すMultiBeanと呼ばれるマネージドBeanクラスのコードを示しています。

package view;

import java.util.ArrayList;
import java.util.List;

import oracle.adf.controller.TaskFlowId;
import oracle.adf.controller.binding.TaskFlowBindingAttributes;

public class MultiBean {
private List<TaskFlowBindingAttributes> mTaskFlowBindingAttrs = new
ArrayList<TaskFlowBindingAttributes>(5);

public MultiBean() {
TaskFlowBindingAttributes tfAttr = new TaskFlowBindingAttributes();
tfAttr.setId("region1");
tfAttr.setTaskFlowId(new TaskFlowId("/WEB-INF/r1.xml", "r1"));
mTaskFlowBindingAttrs.add(tfAttr);

tfAttr = new TaskFlowBindingAttributes();
tfAttr.setId("region2");
tfAttr.setTaskFlowId(new TaskFlowId("/WEB-INF/r2.xml", "r2"));
mTaskFlowBindingAttrs.add(tfAttr);

}

public List<TaskFlowBindingAttributes> getTaskFlowList() {
return mTaskFlowBindingAttrs;
}
}

TaskFlowBindingAttributesクラスの詳細は、Oracle ADF ControllerのJava APIリファレンスを参照してください。

実行時に、multiTaskFlowバインディングでは、公開するコマンド・コンポーネントを使用して、エンド・ユーザーがページに追加またはページから削除できる1つまたは複数のタスク・フローのリストが参照されます。図26-16は、このユース・ケースを作成した各種パート間の関係を示しています。

注意:

バインド・タスク・フローでレンダリングされるページ・フラグメントではFaceletsドキュメント・タイプを使用する必要があります。

図26-16 複数タスク・フロー・バインディングから導出されたADFリージョン

26.11.1 複数の不明なリージョンをレンダリングするページの構成方法

JSFページ定義ファイルのmultiTaskFlow要素を構成して、バインド・タスク・フローのリストを参照します。TaskFlowBindingAttributesタイプの要素を追加または削除することで、実行時にこのリストを変更できます。

始める前に:

複数の不明なADFリージョンをレンダリングするページの構成時に利用可能な構成オプションついて理解しておくと役に立つ場合があります。詳細は、「複数の不明なリージョンをレンダリングするページの構成」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる他の機能についても理解しておくと役立ちます。詳細は、「タスク・フローおよびADFリージョンのユースケースと例」を参照してください。

次のタスクを完了する必要があります。

- TaskFlowBindingAttributesタイプのリストを返すpageFlowスコープでマネージドBeanを作成します。マネージドBeanの作成方法の詳細は、「マネージドBeanを使用した情報の格納方法」を参照してください。

複数の不明なリージョンをレンダリングするページを構成するには:

1. 「アプリケーション」ウィンドウで、実行時にADFリージョンを追加または削除するJSFページを右クリックし、「ページ定義に移動」を選択します。

2. 確認ダイアログが表示されたら、「はい」をクリックします。

3. 概要エディタで、「バインディングと実行可能ファイル」タブをクリックし、「実行可能ファイル」セクションで「追加」アイコンをクリックします。

4. 「アイテムの挿入」ダイアログで、ドロップダウン・メニューから「ADFタスク・フロー・バインディング」を選択して、作成するアイテムとして「multiTaskFlow」を選択し、「OK」をクリックします。

5. 「multiTaskFlowの挿入」ダイアログで、次の値を入力します。

- ID *: 複数タスク・フロー・バインディングの一意のIDを入力します。

- taskFlowList *: 実行時にTaskFlowBindingAttributesのリストを返すEL式を入力します。たとえば、次のようにEL式を入力します。
#{pageFlowScope.multiBean.taskFlowList}

6. 「アプリケーション」ウィンドウで、エンド・ユーザーがADFリージョンを実行時に追加または削除するJSFページをダブルクリックします。

7. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「操作」パネルから「各」を、「各」コンポーネントの包含が必要な「構造」ウィンドウのコンポーネント上にドロップします。

8. 「各」コンポーネントの「プロパティ」ウィンドウで、次のフィールドに値を入力します。

- アイテム: 複数タスク・フロー・バインディングの実行時オブジェクトからタスク・フロー・バインディングのリストを返すメソッドを参照するEL式を入力します。
たとえば、次のようにEL式を入力します。

#{bindings.multiRegion1.taskFlowBindingList}

- Var: タスク・フロー・バインディングのリストを識別する値を入力します。

9. 「各」コンポーネントを含むJSFページで、次の例に示すように、EL式を使用して「リージョン」コンポーネントのリージョン・モデルを参照する「各」コンポーネント内にある「リージョン」コンポーネントを挿入します。

<af:forEach var="tf" items="#{bindings.multiRegion1.taskFlowBindingList}">
<af:panelBox text="#{tf.name}" id="pb1">
<f:facet name="toolbar"/>
<af:region value="#{tf.regionModel}" id="r1"/>
</af:panelBox>
</af:forEach>

26.11.2 複数の不明なリージョンをレンダリングするページの構成時の処理

複数タスク・フロー・バインディングのJSFページ定義ファイルに、次の例で示されたものと類似するメタデータが含められます。

<multiTaskFlow id="multiRegion1"
taskFlowList="${pageFlowScope.multiBean.taskFlowList}" activation="deferred"
xmlns="http://xmlns.oracle.com/adf/controller/binding"/>

複数タスク・フロー・バインディングのメタデータのtaskFlowList属性ではマネージドBeanが指定されます。マネージドBeanでは、実行時にページに追加可能なタスク・フローを記載するオブジェクトのリストが格納されています。

26.11.3 複数の不明なリージョンをレンダリングするページの構成に関する必知事項

- JSFページにレンダリングできるリモート・リージョンの数に制限はありませんが、この機能は慎重に使用する必要があります。タブが使用されていない単純なページの場合、リージョンをページにまとめ、リージョンの設計やそれが実行するビュー・オブジェクト問合せによってリージョンの最大数が決定されるようにできます。または、タブを使用する複雑なページの場合、パフォーマンスを最大化するためにリージョンの使用を制限します。複雑なタブ付きページの場合、ADFでは、リージョンがロードされた後は、タスク・フロー・トランザクションを非アクティブ化しません。タブを切り替える場合は、パフォーマンスを最大化するために進行中のトランザクションを停止する必要があります。タスク・フローとリージョン間の対話の詳細は、「ADFリージョンのトランザクション管理の構成」を参照してください。

- 各タスク・フロー・バインディングは、TaskFlowBindingAttributesによって公開されたメソッドを使用して動作をオーバーライドしないかぎり、複数タスク・フロー・バインディングに定義された属性を継承します。

- 「パラメータ・マップを使用したADFリージョンのパラメータの指定」の説明のとおり、各タスク・フロー・バインディングは、複数タスク・フロー・バインディングで定義されたパラメータとともに、parametersMapプロパティを使用して定義されたパラメータも継承します。

26.12 未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理

バインド・タスク・フローは、アクセスするセキュリティ権限のないユーザーによって起動される場合、ADFリージョンでレンダリングされません。リージョンは、これが発生する場合、リクエストされたタスク・フローのかわりに空白エリアをレンダリングします。起動しようとしたタスク・フローが表示されない理由に関してフィードバックを提供されないため、これによりユーザーが困惑する場合があります。ユーザーの操作性を向上させるために、ユーザーが必要とされるセキュリティ権限がないバインド・タスクにアクセスしようとする場合は、レンダリングする別のバインド・タスク・フローを指定できます。たとえば、ユーザーに必要なセキュリティ権限がないことを伝えるページを表示する別のバインド・タスク・フローを構成できます。より複雑なアプローチにより、システム管理者から必要な権限を要求するためのプロセスを通して、ユーザーが段階的に行うことができるバインド・タスク・フローをレンダリングできます。

セキュリティ権限のないバインド・タスク・フローにアクセスできない場合に、ユーザーが確実に表示できるように別のバインド・タスク・フローのセキュリティ・レベルを構成します。場合によっては、このことに伴い、「ADFリソースを公開する方法」の説明に従って、別のバインド・タスク・フローを公開することが必要になります。バインド・タスク・フローを含むFusion Webアプリケーションのセキュリティ保護の詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

26.12.1 未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理方法

セキュリティ権限がないためバインド・タスク・フローにアクセスできない場合にユーザーに表示する内容で、別のバインド・タスク・フローを構成します。Fusion Webアプリケーションのadf-config.xmlファイルで「未許可リージョン・タスクフロー」プロパティの値として別のバインド・タスク・フローを指定します。

始める前に:

タスク・フローにセキュリティ権限がないユーザーにメッセージを表示する必要がある場合について理解しておくと役立ちます。詳細は、「未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

1. セキュリティ権限がないためバインド・タスク・フローにアクセスできない場合に、ユーザーに表示する別のバインド・タスク・フローを作成します。
バインド・タスク・フローの作成の詳細は、「タスク・フローの作成」を参照してください。

2. ユーザーがアクセスできるようにこのタスク・フローを構成します。
詳細は、「ADFリソースを公開する方法」を参照してください。

タスク・フローにセキュリティ権限がないユーザーにメッセージを表示するには:

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開き、「adf-config.xml」ファイルをダブルクリックします。

2. 概要エディタで、「コントローラ」ナビゲーション・タブをクリックします。

3. 「コントローラ」ページの「未許可リージョン・タスクフロー」フィールドで、起動するバインド・タスク・フローの名前を入力するか、「参照」をクリックして選択します。

26.12.2 未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理

次の例に示すように、JDeveloperでは、adf-config.xmlファイルの<unauthorized-region-taskflow>要素の値として選択したバインド・タスク・フローの名前を記述します。

<?xml version="1.0" encoding="windows-1252" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:config="http://xmlns.oracle.com/bc4j/configuration"
xmlns:adf="http://xmlns.oracle.com/adf/config/properties">
...
<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
<unauthorized-region-taskflow>/WEB-INF/task-flow-definition.xml
</unauthorized-region-taskflow>
</adf-controller-config>
...
</adf-config>

実行時に、Fusion Webアプリケーションでは、ユーザーがセキュリティ権限のないバインド・タスク・フローを起動しようとすると、この別のバインド・タスク・フローをレンダリングします。

26.13 Fusion Webアプリケーションでのリモート・リージョンの作成

リモート・リージョンを作成するには、Fusion Webアプリケーション(コンシューマ)のページで、別のFusion Webアプリケーション(プロデューサ)からタスク・フローを起動します。リモート・リージョンを作成すると、同じ機能を実装する複数のタスク・フローを開発することなく、独自のデータ・コントロール・フレームを持っているタスク・フローで大まかな機能を再利用できます。ADF FacesコンポーネントをレンダリングしているJSFページでJSF portletを実装する場合と比較して、パフォーマンス、対話、実装の容易さの点でも有利です。実行時に、コンシューマ・アプリケーションは、プロデューサ・アプリケーションからリモート起動可能タスク・フローを起動およびレンダリングします。リモート起動可能タスク・フローは、複数のアプリケーションで使用される場合があります。

リモート起動されるように構成したプロデューサ・アプリケーションからのタスク・フローは、ページ・フラグメントをレンダリングする、バインド・タスク・フローである必要があります。また、data-control-scopeプロパティの値がisolatedであり、remote-invocableプロパティを含んでいる必要もあります。data-control-scopeプロパティの値がisolatedである場合に使用できるトランザクション・オプションはすべて、リモート起動されるように構成したプロデューサ・アプリケーションからのタスク・フローに対して構成できます。プロデューサ・アプリケーションでリモート起動可能タスク・フローのために選択されるオプションがトランザクションの動作を決定するため、プロデューサおよびコンシューマ・アプリケーションはトランザクションを共有しません。タスク・フローのトランザクション・オプションの詳細は、「タスク・フローのトランザクションの管理」を参照してください。

注意:

ここで説明する(リモート・リージョンを作成して、別のFusion WebアプリケーションからJSFページ・フラグメント(.jsff)を表示するバインド・タスク・フローをレンダリングする方法の説明)機能は、「URLを使用したバインド・タスク・フローのコール方法」で説明する機能とは異なります。後の項では、Fusion WebアプリケーションのJSFページで、別のFusion WebアプリケーションからJSFページをレンダリングするバインド・タスク・フローを起動する方法を説明します。

プロデューサおよびコンシューマ・アプリケーションは、同じバージョンのOracle ADF上で実行される必要があります。つまり、Oracle ADFのあるバージョンで実行されているプロデューサ・アプリケーションからリモート起動可能タスク・フローを起動して、Oracle ADFの別のバージョンで実行されているコンシューマ・アプリケーションのリモート・リージョンでレンダリングすることはできません。このタイプの実装を試行すると、プロデューサ・アプリケーションを起動しようとするユーザーに対して、コンシューマ・アプリケーションにより次のメッセージが表示されます。

Remote region error: Version of the richclient on the producer at "[producer URL]" is incompatible with this consumer.
Consumer version: [Consumer Version] Producer version: [Producer Version]

リモート起動されるように構成したプロデューサ・アプリケーションからのタスク・フローでは、次のことはできません。

- アクティブ・データ・サービスを使用するADF Facesコンポーネントをレンダリングすること
アクティブ・データ・サービスの詳細は、「アクティブ・データ・サービスの使用」を参照してください。

- リモート起動可能タスク・フローを作成する別のアプリケーションから、リモート起動可能タスク・フローを起動すること。つまり、コンシューマ・アプリケーションを構成して、別のプロデューサ・アプリケーションからリモート起動可能タスク・フローを起動するプロデューサ・アプリケーションから、リモート起動可能タスク・フローを起動するようにすることはできません。リモート・リージョンは、別のリモート・リージョンの内部にネストできません。

- 外部ダイアログを起動すること。次を参照してください。

- モーダル・ダイアログ内でのバインド・タスク・フローの実行これらの外部モーダル・ダイアログ内で実行するバインド・タスク・フローは、ページ・フラグメントではなく、ページを参照する必要があります。

- バインド・タスク・フローのかわりとしてのADF Facesダイアログ・フレームワークの使用

- 「タスク・フローでのセーブポイントの使用」の説明に従って、セーブポイントを使用します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ドラッグ・アンド・ドロップ機能の追加」の説明に従って、ドラッグ・アンド・ドロップ機能を実装します。

- iFrameを介して起動すること。リモート・リージョンの作成には、Oracle ADF機能のみ使用します。

- その入力パラメータが参照渡しで、コール元から認識可能と想定すること。リモート・リージョン実装では、すべてのパラメータ値のコピーが、リモート起動可能タスク・フロー(値渡し)のプロデューサに送信されます。通常、このプロデューサはコンシューマ・アプリケーションとは異なるWebアプリケーションに存在するためです。

さらに、リモート起動可能タスク・フローに関連付けられた次のオブジェクトはすべて、シリアライズ可能である必要があります。

- タスク・フローに対して定義された、入力パラメータと戻りパラメータの値

- タスク・フローが送出する例外

- コンテキスト・イベントが渡すあらゆるペイロード・データ

図26-17は、コンシューマ・アプリケーションが、プロデューサ・アプリケーションからリモート起動可能タスク・フローを起動するリモート・リージョンをレンダリングする、サンプル・シナリオを例示しています。

図26-17 リモート・リージョンをレンダリングするアプリケーション

ここまでで説明した機能を実装するには、次のタスクが完了している必要があります。

- タスク・フローを作成するアプリケーションで:

- アプリケーションの「リモート・リージョンのプロデューサ・サポートの有効化」プロパティの構成

- リモート・リージョンでレンダリングするタスク・フロー上での、「リモート起動可能」プロパティの設定

- コンシューマ・アプリケーションで、コンシューマにイベントをブロードキャストする、アプリケーションで公開するコンテキスト・イベントに対して次のプロパティを構成します。

- dispatchModeをremoteに設定します

- シリアライズ可能オブジェクトを参照するcustomPayloadのEL式を記述します

- オブジェクトのカスタム・ペイロードのタイプ指定します

これらのプロパティを構成すると、コンテキスト・イベントを公開するページ定義に、次のようなコンテキスト・イベントのエントリが含められます。コンテキスト・イベントの詳細は、「コンテキスト・イベントの使用方法」を参照してください。

<event name="valueChangeEvent" dispatchMode="remote"
customPayload="<EL to a serializable object>" customPayloadType=<type of the custom payload> />

イベントをリモート・コンシューマに公開する方法の詳細は、「コンテキスト・イベントの公開方法」を参照してください。

- プロデューサ・アプリケーションからコンシューマ・アプリケーションのエンド・ユーザーに対してセッション・タイムアウト警告が表示されないように、セッション・タイムアウトをコンシューマ・アプリケーションのセッション・タイムアウトより大きな値に設定することを検討すること。セッション・タイムアウトの構成の詳細は、「Fusion WebアプリケーションでのHttpSessionの管理」を参照してください。

- プロデューサ・アプリケーションからのタスク・フローを使用するアプリケーションで:

- アプリケーションの「リモート・リージョンのコンシューマ・サポートの有効化」プロパティの構成

- リモート・リージョンをレンダリングするJSFページへの、リモート起動可能タスク・フローの追加

ヒント:

JSFページにレンダリングできるリモート・リージョンの数に制限はありませんが、この機能は慎重に使用する必要があります。タブが使用されていない単純なページの場合、リージョンをページにまとめ、リージョンの設計やそれが実行するビュー・オブジェクト問合せによってリージョンの最大数が決定されるようにできます。または、タブを使用する複雑なページの場合、パフォーマンスを最大化するためにリージョンの使用を制限します。複雑なタブ付きページの場合、ADFでは、リージョンがロードされた後は、タスク・フロー・トランザクションを非アクティブ化しません。タブを切り替える場合は、パフォーマンスを最大化するために進行中のトランザクションを停止する必要があります。タスク・フローとリージョン間の対話の詳細は、「ADFリージョンのトランザクション管理の構成」を参照してください。

Oracle ADF用のSummitスタンドアロン・サンプル・アプリケーションのTaskFlowProducerプロジェクトには、コンシューマ・アプリケーションで使用できるリモート起動可能タスク・フローが含まれています。TaskFlowProducerプロジェクトのRemoteViewer.jsfページを実行して、リモート起動可能タスク・フローを含むサンプル・アプリケーションをデプロイします。このサンプル・アプリケーションをデプロイすると、「リモート・リージョンをレンダリングするようにアプリケーションを構成する方法」で説明するように、リモート起動可能タスク・フローを使用できます。

Oracle ADF用Summitスタンドアロン・サンプル・アプリケーションの詳細は、「SummitADF_Examplesワークスペースからのスタンドアロン・サンプルの実行」を参照してください。

26.13.1 リモート・リージョンで使用するタスク・フローを作成するようにアプリケーションを構成する方法

タスク・フローを作成するアプリケーションで、プロジェクトを構成します。また、各タスク・フローは、リモート起動可能になり、コール元のタスク・フローとデータ・コントロール・フレームを共有しないように、リモート・リージョンでレンダリングするプロジェクト内で構成します。

始める前に:

リモート・リージョンで使用するタスク・フローを作成するようにアプリケーションを構成する場合は、その前に必要な構成について理解しておくと役立ちます。詳細は、「Fusion Webアプリケーションでのリモート・リージョンの作成」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

リモート・リージョン用のタスク・フローを作成するアプリケーションを構成する手順:

1. 「アプリケーション」ウィンドウで、リモート起動可能タスク・フローを作成するように構成するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「ADFタスク・フロー」ノードをクリックして、「リモート・リージョンのプロデューサ・サポートの有効化」チェック・ボックスを選択します。

3. 実行時に、コンシューマ・アプリケーションのユーザーが、プロデューサ・アプリケーション内のサーブレット(rtfquery)に対して、ユーザー資格証明を提示せずにリモート起動可能タスク・フローのリストを問い合せることを許可する場合、「未認証のリモート・リージョン問合せサーブレット・リクエストを許可する」を選択します。JDeveloper(設計時)でコンシューマ・アプリケーションを開発する際に、プロデューサ・アプリケーションから使用できるリモート起動可能タスク・フローのリストを表示する場合は、このチェック・ボックスも選択します。

rtfqueryにリクエストを送信するユーザーに対して認証を要求するプロデューサ・アプリケーションのweb.xmlファイルにセキュリティ制約を追加する場合は、このチェック・ボックスを選択しないままにしておきます。このオプションがデフォルトです。詳細は、「リモート・リージョンの保護に関する必知事項」を参照してください。

4. 「アプリケーション」ウィンドウで、リモート起動するタスク・フローをダブルクリックします。

5. 概要エディタで、「一般」ナビゲーション・タブをクリックし、「可視性」セクションを開きます。

6. 「リモート起動可能」チェック・ボックスを選択します。

7. 「動作」ナビゲーション・タブをクリックして、「トランザクション」セクションを展開し、「タスク・フローのコールとデータ・コントロールを共有」ドロップダウン・リストから「独立」を選択します。

データ・コントロールの共有の詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

8. リモート起動可能にする各タスク・フローについて、ステップ4から7を繰り返して、リモート・リージョンでレンダリングできるようにします。

26.13.2 リモート・リージョンで使用するタスク・フロー作成時の処理

アプリケーションを構成して、リモート起動可能タスク・フローを作成するようにする場合、JDeveloperは次のファイルを作成/変更します。

- アプリケーションのweb.xmlファイル

- アプリケーションのポリシー・ストア(jazn-data.xmlファイル)

- リモート起動できるように構成するタスク・フローのソース・ファイル

次の例に示すように、JDeveloperはプロデューサ・アプリケーションのjazn-data.xmlファイルにあるADFセキュリティ・ポリシーを定義します。そのファイルがプロデューサ・アプリケーションの中に存在しない場合、JDeveloperにより作成されます。このADFセキュリティ・ポリシーは、リモート起動可能タスク・フローのコンテナの働きをするブートストラップ・ページへのアクセス権を付与する権限付与を指定します。権限付与を指定することによって、ブートストラップ・ページに表示する個々のリモート起動可能タスク・フローに対してアクセス・ポリシーを定義する必要があります。詳細は、「ADFバインド・タスク・フローのポリシーを定義する方法」を参照してください。ADFセキュリティの詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

...
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl</class>
<name>anonymous-role</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>oracle.adfinternal.view.rich.bootstrap.remoteRegionBootstrapPageDef</name>
<actions>view</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
...

JDeveloperはまた、次の例に示すように、remote-invocableプロパティをtrueに設定し、data-control-scopeプロパティをisolatedに設定する際に、リモート起動できるように構成するタスク・フローのソース・ファイルに、次のプロパティを挿入します。data-control-scopeプロパティをisolated手段に設定することは、実行時にタスク・フローが独自のデータ・コントロール・フレームを持つことを意味します。データ・コントロールとタスク・フローの詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

...
<data-control-scope>
<isolated/>
</data-control-scope>
...
<visibility>
<remote-invocable/>
</visibility>
...

JDeveloperがアプリケーションのweb.xmlファイルに追加または構成するエントリには、次のものが含まれます。

- remoteApplication、ServletADFFilter、ADFLibraryFilterおよびadfBindingsと言う名前のフィルタ(および関連付けられたフィルタ・マッピング)

- Faces Servlet、adflibResourcesおよびrtfqueryServletという名前のサーブレット(および関連付けられたサーブレット・マッピング)

例26-2は、リモート・リージョンのタスク・フローを作成するように構成されるプロデューサ・アプリケーションの、これらのエントリを示しています。例26-2に示したエントリの他、JDeveloperは、リモート起動可能タスク・フローを作成するようにアプリケーションを構成する際に、<security-constraint>および<login-config>要素を生成します。これらの要素は、例26-2に示されていません。これらの要素に指定された値の詳細は、「リモート・リージョンの保護に関する必知事項」を参照してください。

注意:

web.xmlファイルで、remoteApplicationフィルタが次の位置に現れることを確認します。

- この後者のフィルタが構成される場合、JpsFilterフィルタの直後。
JpsFilterフィルタの詳細は、「ADF認証に関する必知事項」を参照してください。

- ADFLibraryFilterフィルタの前(例26-2参照)。

例26-2 リモート起動可能タスク・フローを作成するアプリケーションのweb.xmlファイルのエントリ

<filter>
<filter-name>remoteApplication</filter-name>
<filter-class>oracle.adfinternal.view.rich.remote.RemoteApplicationFilter</filter-class>
</filter>
...
<filter>
<filter-name>ADFLibraryFilter</filter-name>
<filter-class>oracle.adf.library.webapp.LibraryFilter</filter-class>
</filter>
...
<filter-mapping>
<filter-name>remoteApplication</filter-name>
<url-pattern>/rr/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
...
<filter-mapping>
<filter-name>ADFLibraryFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
...
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
...
<!-- The remote region query servlet. -->
<servlet>
<servlet-name>rtfqueryServlet</servlet-name>
<servlet-class>oracle.adfinternal.controller.rtfquery.RemoteTaskFlowQueryServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
...
<!-- The servlet name here should be the same as the Faces Servlet. -->
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/rr/*</url-pattern>
</servlet-mapping>
...
<servlet-mapping>
<servlet-name>rtfqueryServlet</servlet-name>
<url-pattern>/rtfquery</url-pattern>
</servlet-mapping>

26.13.3 リモート・リージョンの保護に関する必知事項

デフォルトで、JDeveloperは、リモート・リージョンにリモート起動可能タスク・フローを作成するようにアプリケーションを構成する際に、次の例に示す<security-constraint>要素を追加します。このセキュリティ制約は、リモート・リージョン問合せサーブレット(rtfquery)へのアクセスを、<role-name>要素により指定されたロールを持つユーザーに制限します。

<security-constraint>
<web-resource-collection>
<web-resource-name>rtfquery</web-resource-name>
<url-pattern>/rtfquery</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>valid-users</role-name>
</auth-constraint>
</security-constraint>

リモート起動可能タスク・フローを作成するようにアプリケーションを構成する場合、「未認証のリモート・リージョン問合せサーブレット・リクエストを許可する」チェック・ボックスを選択することによって、web.xmlファイルからこの制約を削除できます。このチェックボックスにアクセスする方法の詳細は、「リモート・リージョンで使用するタスク・フローを作成するようにアプリケーションを構成する方法」を参照してください。

JDeveloperはまた、リモート起動可能タスク・フローを作成するようにアプリケーションを構成する際に、次の例に示された認証メカニズムを生成します。この認証メカニズムは、保護されたADFリソース(たとえば、タスク・フロー)へのアクセスが許可されるかどうかを決定します。プロデューサ・アプリケーションが保護されたリソースへのアクセスをリクエストするクライアントを認証できるように、ここに値CLIENT-CERTが存在する必要があります。クライアントが保護されていないリソースへのアクセスをリクエストする場合、プロデューサ・アプリケーションはこの設定を無視します。

<login-config>
<auth-method>CLIENT-CERT,FORM</auth-method>
<realm-name>Identity Assertion</realm-name>
</login-config>

セキュリティ制約(デフォルト動作)を定義するプロデューサ・アプリケーションで、関連付けられた認証メカニズムの<auth-method>要素の値は、最低でもCLIENT-CERTを含む必要があります。リモート起動可能タスク・フローを作成するようにアプリケーションを構成した後、他の変更をweb.xmlファイルに加えた場合(たとえば、ADF Securityの構成)、リモート起動可能タスク・フローが認証されたユーザーにアクセスできるようにするために必要な値を上書きすることがあります。セキュリティ制約と認証メカニズムのために指定される値を検証して、有効であることを確認してください。

セキュリティの詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

26.13.4 リモート・リージョンをレンダリングするようにアプリケーションを構成する方法

リモート・リージョンをレンダリングするFusion Webアプリケーションで、プロデューサ・アプリケーションからリモート起動可能タスク・フローを使用できるようにプロジェクトを構成します。プロデューサ・アプリケーションへの接続を作成します。

この接続を作成すると、接続を定義した任意の場所(「リソース」ウィンドウまたは「アプリケーション・リソース」パネル)からリモート起動可能タスク・フローをドラッグし、JSFページ、またはコンシューマ・アプリケーションのページの、リモート・リージョンが実行時にレンダリングするページ・フラグメントにドロップできます。リモート起動可能タスク・フローが接続に表示されるためには、起動するリモート起動可能タスク・フローのプロデューサ・アプリケーションが実行中である必要があります。

始める前に:

リモート・リージョンをレンダリングするようにアプリケーションを構成する場合は、その前に必要な構成について理解しておくと役立ちます。詳細は、「Fusion Webアプリケーションでのリモート・リージョンの作成」を参照してください。

他のタスク・フロー機能およびADFリージョン機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、「ADFリージョンにレンダリングされるタスク・フローの追加の機能」を参照してください。

リモート・リージョンをレンダリングするようにアプリケーションを構成する手順:

1. 「アプリケーション」ウィンドウで、リモート・リージョンをレンダリングするように構成するプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「ADFタスク・フロー」ノードをクリックして、「リモート・リージョンのコンシューマ・サポートの有効化」チェック・ボックスを選択します。

3. 「リソース」ウィンドウで、「新規」をクリックし、「接続の作成」、「リモート・リージョン・プロデューサ」の順に選択します。

4. 接続をアプリケーション内でのみ利用可能にする場合は、「リモート・リージョン接続の作成」ダイアログで、「アプリケーション・リソース」を選択します。「リソース」ウィンドウを使用する他のアプリケーションにも接続を使用できるようにする場合は、「リソース」ウィンドウを選択します。

5. 「名前」フィールドに、アプリケーションが使用して、リモート起動可能タスク・フローのプロデューサ・アプリケーションへの接続を識別する名前を入力します。

6. 「クエリーURL」セクションの「URLエンドポイント」フィールドに、リモート起動可能タスク・フローを作成するFusion WebアプリケーションのURLエンドポイントを入力します。通常、このURLは、次のような形式になります。

http://<host>:port/<context root>/rtfquery

ここで、rtfqueryは、プロデューサ・アプリケーション内のリモート起動可能タスク・フローのリストを提供するサーブレットです。

7. 「接続テスト」をクリックすると、URLエンドポイントが有効であることを検証できます。

8. 「起動URL」セクションの「URLエンドポイント」フィールドに、リモート起動可能タスク・フローを作成するFusion WebアプリケーションのURLエンドポイントを入力します。通常、このURLは、次のような形式になります。

http://<host>:port/<context root>/rr

ここで、rrは、リモート起動可能タスク・フローを作成するFusion Webアプリケーションのweb.xmlファイルのremoteApplicationフィルタに指定されたurl-patternです。

9. コンシューマ・アプリケーションがリモート起動可能タスク・フローにアクセスするために、プロデューサ・アプリケーションがユーザー資格証明を要求することがわかっている場合、「常にユーザー・アイデンティティを送信」チェック・ボックスを選択します。これは、コンシューマ・アプリケーションが初期接続時にプロデューサ・アプリケーションに送信する識別トークンを生成します。

プロデューサ・アプリケーションがユーザー資格証明を要求するかどうかわからない場合は、「常にユーザー・アイデンティティを送信」チェック・ボックスを選択しないままにしておきます。詳細は、「実行時の処理: アプリケーションによるリモート・リージョンのレンダリング方法」を参照してください。

10. 「接続テスト」をクリックしてURLエンドポイントが有効であることを検証し、「OK」をクリックします。

11. 「リモート・リージョン・プロデューサ」ノードを展開して、Fusion Webアプリケーションが起動するリモート起動可能タスク・フローをドラッグし、JSFページ、または実行時にリモート・リージョンでレンダリングするページ・フラグメントにドロップします。

12. 表示されるポップアップ・メニューで、ページに作成するリージョンのタイプを選択します(「リージョン」または「動的リージョン」)。

「動的リージョン」を選択した場合、実行時にADF動的リージョンでレンダリングするバインド・タスク・フローを決定するマネージドBeanを選択または作成する必要があります。詳細は、「ADF動的リージョンの作成」を参照してください。

13. 「タスク・フロー・バインディングの編集」ダイアログで、「リモート接続」ドロップダウン・リストから、ステップ5で定義したリモート起動可能タスク・フローを作成するFusion Webアプリケーションへの接続を選択します。

通常は、これはデフォルトで選択されています。

14. 「OK」をクリックします。

26.13.5 リモート・リージョンをレンダリングするようにアプリケーションを構成する場合の処理

次の例に示すように、リモート起動可能タスク・フローを使用するプロジェクトでリモート・リージョンのコンシューマ・サポートを有効化すると、JDeveloperはアプリケーションのweb.xmlファイルにコンテキスト・パラメータを追加します。

<context-param>
<param-name>oracle.adf.view.rich.remote.AUTH_PROVIDER</param-name>
<param-value>oracle.adf.view.rich.remote.security.ADFAuthorizationProvider</param-value>
</context-param>

このコンテキスト・パラメータは、ADF Securityで作業するために構成されるデフォルトの認可プロバイダを指定します。次のインタフェースを実装するオブジェクトを作成することによって、他の認可プロバイダを追加できます。

oracle.adf.view.rich.remote.AuthorizationProvider

アプリケーションでJSFページまたはページ・フラグメントにリモート起動可能タスク・フローをドラッグ・アンド・ドロップする場合、JDeveloperは、JSFページと、JSFページのページ定義ファイルへのバインド・タスク・フローに、af:regionタグを追加します。これらの追加は、「アプリケーション」ウィンドウから同じアプリケーションのJSFページにタスク・フローをドラッグ・アンド・ドロップするときに生成されるものと類似しています。1つの相違点は、例26-3に示すように、JSFページにリモート起動可能タスク・フローをドラッグ・アンド・ドロップする場合、JSFページのページ定義ファイルに追加されるタスク・フロー・バインディングに、プロデューサ・アプリケーションの接続名を参照するremoteConnectionName属性が含まれるということです。

タスク・フロー・バインディングのremoteConnectionName属性は、プロデューサ・アプリケーションに接続の名前を実行時に戻すEL式を参照することもできます。これは、たとえば、プロデューサ・アプリケーションの名前が変更され、そのイベントに応じてADFリージョンをリフレッシュする場合に便利です。詳細は、「ADFリージョンのリフレッシュの構成」を参照してください。

ADFリージョンまたはADF動的リージョンを作成する場合にJDeveloperが生成するエントリの詳細は、「ADFリージョン作成時の処理」および「ADF動的リージョン作成時の処理」を参照してください。

例26-3 タスク・フロー・バインディングの作成用にページ定義に追加されるメタデータ

<taskFlow id="dynamicRegion2"
taskFlowId="${viewScope.ParentActionRegion.dynamicTaskFlowId}"
activation="deferred" remoteConnectionName="RemoteAppProducingTFs"
xmlns="http://xmlns.oracle.com/adf/controller/binding"/>

26.13.6 実行時の処理: アプリケーションによるリモート・リージョンのレンダリング方法

リモート起動可能タスク・フローを作成し、リモート・リージョンをレンダリングするように構成したアプリケーションの初期ランタイム動作は、プロデューサ・アプリケーションに構成されたセキュリティ関連オプションに依存します。

- その前のコンシューマ・アプリケーションからのユーザー証明書が、rtfqueryサーブレットにアクセスして、リモート起動可能タスク・フローのリストを取得するのを許可する必要があります。
このシナリオでは、プロデューサ・アプリケーションは、初期リクエストにエラー・コードで応答します。それに応じて、コンシューマ・アプリケーションは、プロデューサ・アプリケーションに送信する暗号化された識別トークンをレンダリングします。プロデューサ・アプリケーションは、この識別トークンを使用してコンシューマ・アプリケーションを認証し、成功した場合コンシューマ・アプリケーションのリクエストをサービスします。

プロデューサ・アプリケーションがユーザー資格証明を必要とすることが前もってわかっている場合、「常にユーザー・アイデンティティを送信」チェックボックスを選択することによって、コンシューマ・アプリケーションに、初期接続で暗号化された識別トークンを送信させることができます(「リモート・リージョンをレンダリングするようにアプリケーションを構成する方法」を参照)。これは、接続プロセスを最適化します。

- それは、未認証リクエストをrtfqueryサーブレットに対して許可します。
コンシューマ・アプリケーションは、プロデューサ・アプリケーションがリモート起動されるように構成するrtfqueryサーブレットから、リモート起動可能タスク・フローのリストを取得します。

プロデューサ・アプリケーションからリモート起動可能タスク・フローにアクセスした後、コンシューマ・アプリケーションは、この目的に構成されたADFリージョン(リモート・リージョン)のタスク・フローからのコンテンツをレンダリングします。このコンテンツの表示は、コンシューマ・アプリケーションのADFスキンのstyleプロパティによって定義されます。このADFスキンのstyleプロパティは、プロデューサ・アプリケーションのADFスキンで定義されているstyleプロパティと一致する必要があります。詳細は、「ADFスキンとリモート・リージョンに関する必知事項」を参照してください。

コンシューマ・アプリケーションが、プロデューサ・アプリケーションとの間で確立したセッションを無効にすると、プロデューサ・アプリケーションは、コンシューマ・アプリケーションがセッションを無効にした時点で進行中だったあらゆるトランザクションをロールバックします。コンシューマ・アプリケーションがセッションを無効にする原因になる可能性があるイベントの例には、次のようなものがあります。

- コンシューマ・アプリケーションでセッション・タイムアウトに指定された時間に達した

- エンド・ユーザーがコンシューマ・アプリケーションをログアウトした

- エンド・ユーザーがブラウザの「戻る」ボタンをクリックした

- リモート・リージョンをレンダリングしない異なるページへのナビゲーション

26.13.7 カスタム・エラー・メッセージをリモート・リージョンに追加する方法

リモート・リージョンの実装でエラーが発生すると、コンシューマ・アプリケーションに様々なエラー・メッセージが表示されます。たとえば、図26-18に示したものに類似したメッセージが表示される場合があります。

図26-18 リモート・リージョンのエラー・メッセージ

次の例は、図26-18で表示されたメッセージに対応するログ・メッセージを示しています。

...
<oracle.adf.view> <RegionRenderer> <_logError> <RR_HTTP_ERROR>
...
...
<oracle.adf.view> <RegionRenderer> <_logError> <Jan 29, 2014 12:50:51 PM oracle.adfinternal.view.faces.renderkit.rich.RegionRenderer _logError
ALL: Remote Region error #2: An uncaught exception was thrown on the producer at "http://127.0.0.1:7101/prod/rr/" while trying to run an ADF Taskflow.
>
oracle.adf.controller.ControllerException: ADFC-14032: A required remote task flow input parameter value was not specified. Requested remote taskFlowId
'/WEB-INF/task-flow-definition.xml#task-flow-definition'; requested from 'localhost.localdomain'.
at oracle.adf.controller.internal.binding.TaskFlowRegionModelRemoteProducer.createRegionViewPortContext(TaskFlowRegionModelRemoteProducer.java:173)
at oracle.adf.controller.internal.binding.TaskFlowRegionModelViewPort.getViewPort(TaskFlowRegionModelViewPort.java:649)
...

多くのシナリオでは、リモート・リージョンの実装の問題を診断して解決するのに、図26-18のメッセージとログ・ファイル・エントリで十分です。他のシナリオでは、エンド・ユーザーに通信して追加の情報を提示する場合があります。図26-19は、現在、追加情報(エラー・タイプやプロデューサ・アプリケーションの場所など)を表示している図26-18のコンシューマ・アプリケーション・ページの、修正バージョンを示しています。図26-19のように、追加情報を表示するようにコンシューマ・アプリケーションを構成するには、コンシューマ・アプリケーションのweb.xmlファイルにコンテキスト・パラメータを追加して、次のパッケージのRemoteRegionErrorListenerを拡張する同じアプリケーションにJavaクラスを作成する必要があります。

oracle.adf.view.rich.model

図26-19 リモート・リージョンのカスタム・エラー・メッセージ

リモート・リージョンにカスタム・エラー・メッセージを追加する手順:

1. コンシューマ・アプリケーションのユーザー・インタフェース・プロジェクトで、oracle.adf.view.rich.model.RemoteRegionErrorListenerクラスを拡張するJavaクラスを作成します。

次の例は、リモート・リージョンでエラーをリッスンして、エラー・メッセージの詳細を示す文字列を戻すJavaクラスを示しています。

package example;

import oracle.adf.view.rich.model.RemoteRegionErrorEvent;
import oracle.adf.view.rich.model.RemoteRegionErrorListener;
import oracle.adf.view.rich.model.RemoteRegionHttpErrorEvent;

public class MyRemoteRegionErrorListener extends RemoteRegionErrorListener {

@Override
public String getAdditionalUserInformation(RemoteRegionErrorEvent event) {

RemoteRegionErrorEvent.Type type = event.getErrorType();
StringBuilder sb =
new StringBuilder().append("Received a(n) ").append(type);

if (RemoteRegionErrorEvent.Type.HTTP_ERROR.equals(type)) {
sb.append(" number ").append(((RemoteRegionHttpErrorEvent)event).getHttpErrorCode());
}

sb.append(" from ").append(event.getProducerURL());

String viewId = event.getViewID();
if (null != viewId) {
sb.append(" for viewId ").append(viewId);
}

return sb.toString();
}
}

2. 「アプリケーション」ウィンドウのユーザー・インタフェース・プロジェクトで、「Webコンテンツ」→「WEB-INF」ノードを開き、web.xmlをダブルクリックします。

3. web.xmlファイルの概要エディタで、「アプリケーション」ナビゲーション・タブをクリックし、「コンテキスト初期化パラメータ」セクションで「作成」アイコンをクリックして、次のように、ステップ1で作成したJavaクラスを参照するパラメータを追加します。

名前: コンテキスト・パラメータoracle.adf.view.rich.REMOTE_REGION_ERROR_LISTENERを入力します。

値 :ステップ1で作成したJavaクラスへのパスを入力します。たとえば、手順1のクラスを参照するには、example.MyRemoteRegionErrorListenerと入力します。

26.13.8 ADFスキンとリモート・リージョンに関する必知事項

コンシューマとプロデューサ・アプリケーションのADFスキンのstyleプロパティが一致しないと、リモート・リージョンはレンダリングできません。ADFスキンが一致しない場合、リモート・リージョンはそのコンテンツをレンダリングしません。ADFスキンが一致すると、リモート・リージョンは、コンシューマ・アプリケーションのADFスキンをレンダリングおよび使用して、表示を決定します。

コンシューマおよびプロデューサ・アプリケーションのADFスキンの間に不一致が発生した場合、1つまたは両方のADFスキンを修正して、不一致が発生しないようにする必要があります。不一致の発生箇所で、コンシューマ・アプリケーションのクライアントは、次のようなメッセージを表示します。

コンテンツを取得できません。詳細は、サーバー・ログの"リモート・リージョン・エラー#1"を参照してください。

サーバー・ログは、コンシューマ・アプリケーションのアプリケーション・サーバーのログ・ファイルに表示されるメッセージを参照します。これらのログ・メッセージは、ADFスキンの間の不一致を識別するため、またはADFスキンの問題を診断するために使用できる情報を提供している場合があります。次のリストは、ログ・メッセージを生成するコンシューマ・アプリケーションに帰着する問題の説明です。

- ADF_FACES-30209は、ADFスキンの間の不一致を識別します。これは、プロデューサ・アプリケーションはコンシューマ・アプリケーションが使用するスキンを検出できますが、ADFスキンが同じではないことを意味しています。次のようなメッセージが表示されます。
リモート・リージョン・エラー#1: "http://myproducer.com/rr"のプロデューサには、このコンシューマに一致するスキンがありません。コンシューマのスキン情報: {...}、プロデューサのスキン情報: {...}

提供されるADFスキン情報には、ADFスキンのチェックサムが含まれており、各ADFスキンによって使用される、スキン化拡張機能(チェックサムなど)と機能のすべてがリストされます。コンシューマおよびプロデューサ・アプリケーションは、同じADFスキンおよび拡張機能を持つ必要があります。このデータを使用すると、2つのアプリケーションの間に相違があるかどうかを識別する助けになる場合があります。

- ADF_FACES-30210は、コンシューマ・アプリケーションが使用するADFスキンがプロデューサ・アプリケーションに含まれていないことを示します。次のようなメッセージが表示されます。
リモート・リージョン・エラー#1: "http://myproducer.com/rr"のプロデューサには次のスキンがありません: simple

- プロデューサ・アプリケーションに、スキン・ファクトリがありません。これは、プロデューサ・アプリケーションが正しく構成されておらず、次のパッケージから、SkinFactoryを拡張するインスタンス・オブジェクトを検出できないことを意味します。
org.apache.myfaces.trinidad.skin

次のようなメッセージが表示されます。

リモート・リージョン・エラー#1: "http://yourproducer.com/rr"のプロデューサには、使用できるスキン・ファクトリがありません

コンシューマ・アプリケーションは、VERBOSE設定を使用してスキン・デバッグ情報を記録します。プロデューサ・アプリケーションのweb.xmlファイルに次のコンテキスト・パラメータを追加して、プロデューサ・アプリケーションからのログ出力レベルを決定します。

oracle.adf.view.rich.remote.PRODUCER_STYLESHEET_DEBUG_LEVEL

記録されたメッセージをプログラムで解析しやすいように、プロデューサ・アプリケーションは、すべてのスキン・デバッグ情報をJSON形式で出力します。

コンテキスト・パラメータに適切な値を設定します。

- TERSE
ログ出力には、プロデューサ・アプリケーションのADFスキンと、それが拡張するすべてのスキンに関する、スキンID、ファミリ、バージョン、レンダー・キットおよびドキュメントID(チェックサム)が含まれます。ドキュメントIDは、どのスキンが不一致を引き起こすかを診断する助けになりますが、個々のスタイル・シートがある場所に関する情報は提供しません。これは、アプリケーションのweb.xmlファイルでコンテキスト・パラメータを指定していない場合に、プロデューサ・アプリケーションが使用する値です。

- NORMAL
ログ出力には、TERSE設定に記載されたデータの他に、ADFスキンのCSSソース・ファイルの場所、スキンの機能のリスト、すべてのスキン追加に対応するドキュメントの場所とドキュメントIDが含まれるようになりました。ほとんどの場合、どのスタイル・シートがファイル・システム上の実ファイルへの完全なパス情報を示さずに不一致を引き起こしている可能性があるかは、NORMAL設定で十分に診断できます。CSSファイルへのパスは、常に現在のclasspathに対して相対的であり、ファイル・システム上のどこにファイルがあるか、または、どのJARに含まれているかに関する情報を含みません。

- VERBOSE
ログ出力には、TERSE設定に記載されたデータの他に、ファイル・システム上での実ファイルの場所が含まれ、ADFスキンに対応するCSSソース・ファイルを含むJARファイルが識別されるようになりました。この設定は、ADFスキンの不一致が正確にどこで発生しているかを、コンシューマ・アプリケーションに対して示します。ただし、それを使用すると、コンシューマ・アプリケーションのログにプロデューサ情報が表示される危険があるため、プロデューサ・アプリケーションへのアクセスが保護されている場合のみ使用してください。

ADFスキンの概要は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

27 複雑なタスク・フローの作成

この章では、Fusion Webアプリケーションで作成するADFタスク・フローの拡張機能を使用する方法を説明します。これらには、タスク・フローのトランザクション・オプションの定義、前回終了したユーザーのタスク・フローの再開オプションの構成、例外の処理、タスク・フローのセーブポイントの構成、trainなどのADF Facesコンポーネントの使用およびタスク・フロー・テンプレートからのタスク・フローの作成を行う機能が含まれます。

この章の内容は次のとおりです。

- 複雑なタスク・フローの作成について

- タスク・フロー間のデータ・コントロールの共有

- タスク・フローのトランザクションの管理

- バインド・タスク・フローの再開

- タスク・フローでの例外の処理

- セーブポイントを使用するためのアプリケーションの構成

- タスク・フローでのセーブポイントの使用

- アプリケーションでのアクティブなルート・ビュー・ポート数の最小化

- バインド・タスク・フローでのトレイン・コンポーネントの使用

- タスク・フロー・テンプレートの作成

- タスク・フローを使用したページ階層の作成

- 診断フレームワークへのインシデントのレポート

27.1 複雑なタスク・フローの作成について

作成したタスク・フローにアクティビティを追加して、そのアクティビティ間に制御フローを構成した場合は、次のリストで説明する機能の一部を追加することで、タスク・フローの機能を拡張できます。

- 基礎となるデータ・コントロールの機能に加えて、追加のトランザクション管理機能を含むようにバインド・タスク・フローを構成すると、タスク・フローのアクティビティにグループとして関連付けられているデータ・コントロールをFusion Webアプリケーションでコミットまたはロールバックできます。

- バインド・タスク・フローにオプションの再開を構成すると、ユーザーがブラウザの「戻る」ボタンをクリックした場合のレスポンスを決定できます。

- タスク・フローには、あらかじめ例外を処理できる機能が数多くあります。さらに、タスク・フローによってスローされる例外を処理するカスタム・コードを記述できます。

- また、タスク・フローを構成すると、セーブポイントを使用して特定のインスタンスでFusion Webアプリケーションの状態を把握できます。これにより、たとえばユーザーがタスクを完了せずにそのページから移動した場合に、アプリケーションの状態を保存できます。

- トレイン・コンポーネントは、ナビゲーション・アイテムをレンダリングするADF Facesコンポーネントで、マルチステップ・プロセスを使用してユーザーをガイドします。バインド・タスク・フローを構成することで、これらのナビゲーション・アイテムをタスク・フローのビュー・アクティビティ用にデフォルトでレンダリングできます。

- タスク・フロー・テンプレートは、共通の要素を共有するタスク・フロー作成の開始ポイントとして機能できます。

- アプリケーションのデフォルトのバインドなしタスク・フロー(およびアプリケーションの追加のタスク・フロー)が参照するビュー・アクティビティからページ階層を作成します。

- バインド・タスク・フローの入力時および終了時にイニシャライザとファイナライザを起動します。イニシャライザは、バインド・タスク・フローの入力時に起動されるカスタム・コードです。ファイナライザは、タスク・フロー・リターン・アクティビティを使用したタスク・フローの終了時、または例外の発生によって起動されるカスタム・コードです。ファイナライザはマネージドBeanのメソッドです。一般的なファイナライザのタスクには、バインド・タスク・フローで取得したすべてのリソースの解放、およびタスク・フローを終了する前のクリーンアップの実行などがあります。
イニシャライザとファイナライザは両方とも、次の例のように、マネージドBeanのメソッドにEL式として指定します。

#{pageFlowScope.modelBean.releaseResources}

バインド・タスク・フローの開始時にイニシャライザのコードを実行するには2つの方法があり、ブラウザの「戻る」ボタンでそのタスク・フローを再開できるかどうかによって次のように異なります。

- 「戻る」ボタンでの再開が想定されない場合: バインド・タスク・フロー内で(最初に実行する)デフォルト・アクティビティとしてメソッド・コール・アクティビティを指定します。そのメソッド・コール・アクティビティにより、イニシャライザのコードを含むカスタム・メソッドがコールされます。詳細は、「メソッド・コール・アクティビティの使用」および「ブラウザの「戻る」ボタンおよびレコード間の移動に関する必知事項」を参照してください。

- 「戻る」ボタンでの再開が可能な場合: バインド・タスク・フローのメタデータのオプションで、イニシャライザ・メソッドを指定します。詳細は、「タスク・フローの作成」を参照してください。ユーザーがブラウザの「戻る」ボタンでタスク・フローを再開する可能性がある場合、この方法を使用してください。このような場合には、バインド・タスク・フローに指定したデフォルト・アクティビティがコールされずに、イニシャライザ・メソッドで指定されたメソッドがコールされることがあります。

27.1.1 複雑なタスク・フローのユース・ケースと例

図27-1は、「複雑なタスク・フローの作成について」で説明されている多数のユースケースを実装するタスク・フローの「構造」ウィンドウを示しています。たとえば、ここではエラー処理用のエラー・ページが指定され、ナビゲーション・アイテムのレンダリングにADF Facesのtrainコンポーネントが使用されるほか、トランザクション管理の一部としてタスク・フローによる変更がコミットまたはロールバックされる2つのタスク・フロー・リターン・アクティビティが指定されます。

図27-1 「構造」ウィンドウのタスク・フロー

27.1.2 複雑なタスク・フローの追加の機能

タスク・フローを構成または使用する前に、他のOracle ADF機能を理解しておくと役に立つ場合があります。また、タスク・フローで実行できる機能について読むことが必要な場合もあります。次に、関連する他の機能へのリンクを示します。

- タスク・フローの実行時に発生したエラーを管理する例外ハンドラを指定できます。エラー処理の詳細は、「エラー処理のカスタマイズ」を参照してください。

- タスク・フローのセーブポイントでは、アプリケーション状態を保存できます。アプリケーション状態管理の詳細は、「Fusion Webアプリケーションでの状態管理の使用」を参照してください。

- バインド・タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

- 次を実行するには、タスク・フローとともにBusiness Process Execution Language (BPEL)を使用できます。

- バインドなしタスク・フローまたはバインド・タスク・フローからBPELプロセスを起動して、関数を実行したり、サービスを使用すること

- Webインタフェースとのユーザーの対話をモデル化するために、BPELプロセスからバインド・タスク・フローをコールすること

BPELプロセスと対話するマネージドBeanメソッドまたはWebサービスを起動するには、タスク・フロー・メソッド・コール・アクティビティを使用できます。タスク・フロー・メソッド・コール・アクティビティの詳細は、「メソッド・コール・アクティビティの使用」を参照してください。

- タスク・フローを開くカスタム・コードを記述できます。たとえば、「例外ハンドラとしてカスタム・コードを指定する方法」で説明するように、タスク・フローによって例外がスローされたときに起動するカスタム・コードを記述できます。カスタム・コードの記述に使用できるAPIの詳細は、次のドキュメントを参照してください。

- Oracle ADF ControllerのJava APIリファレンス

- Oracle ADF FacesのJava APIリファレンス

27.2 タスク・フロー間のデータ・コントロールの共有

タスク・フローが別のタスク・フローをコールすると、タスク・フローがデータ・コントロールのインスタンスを共有するか、同じデータ・コントロールの2つの個別のインスタンスを作成し、タスク・フローが独立した状態を維持できるようにします。タスク・フローがデータ・コントロールを共有するか、独立したデータ・コントロールを保存するために使用する内部オブジェクトは、データ・コントロール・フレームと呼ばれます。

コミットまたはロールバック時にタスク・フロー・トランザクション管理オプションを使用するタスク・フローでは、どのデータ・コントロールに対してトランザクション操作を実行するかを判断するためにデータ・コントロール・フレームが使用されます。data-control-scopeの値がisolatedに設定されている場合、アプリケーションのバインドなしタスク・フローおよびすべてのバインド・タスク・フローに対応するデータ・コントロール・フレームが実行時に作成されます。タスク・フローのdata-control-scopeの値にsharedが指定されている場合は、コール先のタスク・フローでは独自のデータ・コントロール・フレームは作成されず、コール元のデータ・コントロール・フレームが使用されます。これにより、データ・コントロール・フレームに添付されたデータ・コントロール・インスタンスをコール先のタスク・フローと共有できるようになります。または、コール先のタスク・フローでdata-control-scopeの値にisolatedが指定されている場合は、新しいデータ・コントロール・フレームが作成され、バウンド・タスク・フローで使用されるすべてのデータ・コントロールの新しいインスタンスが、新規に作成されたデータ・コントロール・フレームに添付されます。

コール元のタスク・フローとコール先のタスク・フローの間でデータ・コントロールを共有するかどうかを指定するには、コール先のバインド・タスク・フローでsharedまたはisolatedのいずれかのdata-control-scopeの値を設定する必要があります。デフォルト値はsharedです。

コール元のバインド・タスク・フローとコール先のバインド・タスク・フローの両方でdata-control-scopeがsharedに設定されている場合は、使用されるデータ・コントロール・フレームはコール元のタスク・フロー用のデータ・コントロール・フレームになります。

図27-2では、バインド・タスク・フローBTF1、BTF2およびBTF3は、これらのバインド・タスク・フローのすべてでdata-control-scopeの値がsharedに設定されているため、アプリケーションのバインドなしタスク・フロー(UTF1)に対して作成されたデータ・コントロール・フレームを使用します。これとは対照的に、バインド・タスク・フローBTF4は、data-control-scopeの値がisolatedに設定されているため、異なるデータ・コントロール・フレームを使用します。後者のバインド・タスク・フローはdata-control-scopeの値がsharedに設定されているため、コールするバインド・タスク・フロー(BTF5)とこのデータ・コントロール・フレームを共有します。

図27-2 データ・コントロール・フレームの共有および独立

コール先のタスク・フローのdata-control-scope要素に設定した値によって、コール元のタスク・フローとコール先のタスク・フローがフロー・データ・コントロールを共有するかどうかが決定されます。タスク・フローがページまたはページ・フラグメントのどちらでレンダリングされるかなど、その他の要因によってこの動作が変化することはありません。

27.2.1 タスク・フロー間のデータ・コントロールの共有方法

コール先のタスク・フローのdata-control-scope要素の値を指定することで、タスク・フロー間でデータ・コントロールを共有できます。

始める前に:

タスク・フロー間でのデータ・コントロールの共有方法を決定するプロパティについて理解しておくと役に立つ場合があります。詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

タスク・フロー間でデータ・コントロールを共有するには:

1. 「アプリケーション」ウィンドウで、コール先のタスク・フローをダブルクリックします。

2. 「プロパティ」ウィンドウで「動作」セクションを開き、「タスク・フローのコールとデータ・コントロールを共有」リストから「共有」を選択します。

注意:

「タスク・フローのコールとデータ・コントロールを共有」リストから「共有」を選択した後で、タスク・フローのトランザクション・オプションを構成する必要がある場合があります。詳細は、「データ・コントロールの共有およびトランザクションの管理に関する必知事項」を参照してください。

27.2.2 タスク・フロー間でのデータ・コントロールの共有時の処理

次の例に示すように、「タスク・フローのコールとデータ・コントロールを共有」リストから「共有」を選択すると、JDeveloperではコール先のタスク・フローのソース・ファイルにあるエントリが記述されます。

<task-flow-definition id="task-flow-definition">
...
<data-control-scope id="__1">
<shared/>
</data-control-scope>
...
</task-flow-definition>

27.2.3 実行時に行われる処理: タスク・フローでデータ・コントロールを共有する方法

エンド・ユーザーは、別のブラウザ・ウィンドウまたはブラウザ・タブで同じアプリケーションを複数回開くことがあります。エンド・ユーザーがこの操作を行うと、それぞれのウィンドウまたはタブには独自のビュー・ポートが与えられ、各ウィンドウまたはタブは、同じHTTPセッション内の他のすべてのウィンドウやタブから分離されます。その結果、ウィンドウやタブでデータ・コントロール(つまり、状態)が共有されなくなります。それらのウィンドウまたはタブでは、分離されたデータ・コントロール・スコープで実行されているかのように、新しいデータ・コントロール・フレームで処理が開始されます。このルールの例外は、エンド・ユーザーがセカンダリ・ブラウザ・ウィンドウでモーダル・ダイアログを開いた場合です。この場合、プライマリ・ブラウザ・ウィンドウとセカンダリ・ブラウザ・ウィンドウでサーバー側の状態が同じになり、データ・コントロールも共有されます。モーダル・ダイアログの使用の詳細は、「モーダル・ダイアログ内でのバインド・タスク・フローの実行」を参照してください。ビュー・ポートの詳細は、「ビュー・ポートおよびADFリージョンについて」を参照してください。

データ・コントロールは必要になるまでインスタンス化されません。data-control-scopeにshared(デフォルト)が指定され、Dというデータ・コントロールを参照する子タスク・フローを親タスク・フローで呼び出すと、次の2つのいずれかの処理が行われます。

1. Dというデータ・コントロールが親タスク・フローのデータ・コントロール・フレームにすでに存在する場合は、子タスク・フローのDへの参照はスコープ内に存在するDというデータ・コントロールへのものとして解決されます。

2. Dというデータ・コントロールが親タスク・フローのデータ・コントロール・フレームに存在しない場合は、Oracle ADFによってDという最初のデータ・コントロールがインスタンス化されます。このデータ・コントロールは、Oracle ADFがDataBindings.cpxファイルをトップダウン検索する際に特定されます。

ほとんどのアプリケーションでは、データ・コントロールが一意の名前で定義されているため、上のルールが適用される可能性はあまりありません。しかし、アプリケーションのタスク・フローがADFライブラリJARのタスク・フローをコールする場合、そのアプリケーションとADFライブラリJARのタスク・フローで同じ名前のデータ・コントロールが参照されていることがあります。

親タスク・フローで子タスク・フローを呼び出した際に、親タスク・フローのADFライブラリJARに基づくデータ・コントロールDがすでにインスタンス化されている場合は、子タスク・フローではそのデータ・コントロールが使用されます。まだインスタンス化されていない場合は、DataBindings.cpxファイルのトップダウン検索中に見つかったこのデータ・コントロール名の最初の参照を使用して、親タスク・フローのデータ・コントロールDがインスタンス化されます。具体的に言うと、このようなタスク・フロー呼出しのシナリオでは、子タスク・フローのデータ・コントロールDはインスタンス化されません。

別のシナリオとして、JSFページのタスク・フローが、JSFページ内の特定のリージョンにレンダリングされるタスク・フローをコールする状況を考慮できます。JSFページのコール元タスク・フローがページのリージョン・レンダラの前にデータ・コントロールDをインスタンス化する場合は、コール元タスク・フローのデータ・コントロールDが使用されます。ただし、リージョンがJSFページ内の最初のデータバインドされたコンポーネントである場合は、コール先のタスク・フローのデータ・コントロールDがインスタンス化されて使用されます。

データ・コントロールの詳細は、「ADFデータ・コントロールを使用したアプリケーション・モジュールの公開」を参照してください。DataBindings.cpxファイルの詳細は、「DataBindings.cpxファイルの使用」を参照してください。

27.3 タスク・フローのトランザクションの管理

データベースに関連するシステムのコンテキストで、トランザクションとは、1つのグループとしてコミットまたはロールバックできる永続的な作業項目の集まりです。ADFビジネス・コンポーネントなどのテクノロジを使用したADFは、トランザクションが提供するすべての利点を提供します。ただし、トランザクションのサポートは、ADFモデル・レイヤーに留まりません。ADFコントローラ・レイヤーで、バインド・タスク・フローは、必要に応じて基礎となるADFモデル・レイヤーに独自の抽象化の実装を提供します。この実装により、タスク・フローからトランザクションを制御し、トランザクションの境界を宣言的に管理することもできます。

コール先のバインド・タスク・フローで構成可能なトランザクションのオプションは、次の2つのカテゴリにグループ分けできます。

- 「コントローラ・トランザクションなし」オプションを選択して、コール元のデータバインドされたタスク・フローがトランザクション操作(トランザクションの開始、コミットまたはロールバック)を実行しないようにします。

- 次のいずれかのADFタスク・フロー・トランザクション管理オプションを使用します。

- 常に新規トランザクションを開始: トランザクションが進行中かどうかに関係なく、バインド・タスク・フローの開始時に新しいトランザクションが開始されます。この新しいトランザクションは、バインド・タスク・フローを終了した時点で完了します。

- 常に既存のトランザクションを使用: バインド・タスク・フローは、コール時にすでに進行中の既存のトランザクションに追加されます。

- 可能であれば既存のトランザクションを使用: バインド・タスク・フローは、コール時に既存のトランザクションがある場合はそれに追加されますが、既存のトランザクションがない場合はそのバインド・タスク・フローの開始時に新しいトランザクションが開始されます。

コール先のバインド・タスク・フローで(選択したtransactionオプションに基づいて)新しいADFタスク・フロー・トランザクションを開始する場合は、タスク・フローがそのコール元に戻ったときにトランザクションをコミットまたはロールバックするかどうかを指定できます。コミットおよびロールバック・オプションは、コール元のタスク・フローに制御を戻すタスク・フロー・リターン・アクティビティで設定されます。トランザクションを開始する同じタスク・フローでも、トランザクションを解決できる必要があります。

コール先のバインド・タスク・フローには、結果としてコール先のバインド・タスク・フローでトランザクションをコミットまたはロールバックする2つ異なるのタスク・フロー・リターン・アクティビティを指定できます。それぞれのタスク・フロー・リターン・アクティビティから、同じコール元タスク・フローに制御が戻されます。ただし、一方のタスク・フロー・リターン・アクティビティはコミット・オプションを指定し、他方はロールバック・オプションを指定する点が異なります。例27-3に、Summit ADFタスク・フロー・サンプル・アプリケーションからのorders-select-many-items.xmlタスク・フローを示します。トランザクションの処理が正常に終了した場合は、コミット・タスク・フロー・リターン・アクティビティに制御フローが渡され、トランザクションをコミットするオプションが指定されます。トランザクションが完了前に取り消された場合、ロールバック・タスク・フロー・アクティビティによりトランザクションをロールバックするオプションが指定されます。

図27-3 コール先バインド・タスク・フローにおけるタスク・フロー・リターン・アクティビティ

コール先のバインド・タスク・フローの終了時に、コール先のバインド・タスク・フロー内でエンド・ユーザーが行った変更を破棄する場合は、タスク・フロー・リターン・アクティビティでrestore-save-pointオプションを使用します。ADF Controllerによって、バインド・タスク・フローの開始時に作成された、前のADFモデルのセーブポイントまでロールバックされます。restore-save-pointオプションの適用は、既存のトランザクションを結合してバインド・タスク・フローを開始した場合(また、requires-existing-transactionまたはrequires-transactionのいずれかのオプションが指定された場合)、および開始時にセーブポイントを作成した場合にのみ行われます。

ADFタスク・フロー・トランザクション管理機能を使用して、現在のタスク・フローのデータ・コントロール・フレームに関連付けられているデータ・コントロールをコミットまたはロールバックする場合は、「トランザクションの終了」プロパティをcommitまたはrollbackに設定してタスク・フロー・リターン・アクティビティを使用するか、関連付けられているデータ・コントロール・フレームをプログラムによってコミットする必要があります。または、「コントローラ・トランザクションなし」設定を使用する場合や、1つのデータ・コントロールのみをコミットまたはロールバックする場合は、関連付けられたコミットまたはロールバック操作を「データ・コントロール」パネルで使用するか、関連付けられたコミットまたはロールバックのバインディングをプログラムによって実行します。

ADFタスク・フローのSummitサンプル・アプリケーションで、多数のタスク・フローによりトランザクションが作成されます。たとえば、orders-select-many-items.xmlタスク・フローでは、ADFタスク・フロー・トランザクション管理の「可能であれば既存のトランザクションを使用」オプションが使用されます。このタスク・フローにより、エンド・ユーザーが注文に複数のアイテムを追加したり、エンド・ユーザーが図27-4で示すshowshuttle.jsfページを操作したりする場合にこの変更をコミットまたはロールバックできます。

図27-4 タスク・フローのトランザクション

27.3.1 バインド・タスク・フローでトランザクションを有効化する方法

別のタスク・フローによってコールされるバインド・タスク・フローのトランザクション・オプションを定義します。コール先バインド・タスク・フローで、バインド・タスク・フローをコールするタスク・フローに制御を戻すタスク・フロー・リターン・アクティビティを追加します。

始める前に:

トランザクションの概要とその構成方法を理解しておくと役に立つ場合があります。詳細は、「タスク・フローのトランザクションの管理」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

バインド・タスク・フローをトランザクションとして実行可能にするには:

1. 「アプリケーション」ウィンドウで、コール先のバインド・タスク・フローをダブルクリックします。

2. エディタ・ウィンドウで、「概要」タブをクリックします。

3. 概要エディタで、「動作」ナビゲーション・タブをクリックします。

4. 「動作」ページで、「トランザクション」セクションを開き、ドロップダウン・リストから次のいずれかを選択します。

- コントローラ・トランザクションなし: コール元のデータバインドされたタスク・フローはトランザクション操作(トランザクションの開始、コミットまたはロールバック)を実行しません。

- 常に既存のトランザクションを使用: バインド・タスク・フローは、コール時にすでに進行中の既存のトランザクションに追加されます。

- 可能であれば既存のトランザクションを使用: バインド・タスク・フローは、コール時に既存のトランザクションがある場合はそれに追加されますが、既存のトランザクションがない場合はそのバインド・タスク・フローの開始時に新しいトランザクションが開始されます。

- 常に新規トランザクションを開始: トランザクションが進行中かどうかに関係なく、バインド・タスク・フローの開始時に新しいトランザクションが開始されます。この新しいトランザクションは、バインド・タスク・フローを終了した時点で完了します。

注意:

トランザクション・オプションを選択した後は、これらのオプション間で相互作用があるかどうかを判断するために、そのバインド・タスク・フローの「タスク・フローのコールとデータ・コントロールを共有」オプション(data-control-scope)の構成も必要になる場合があります。詳細は、「データ・コントロールの共有およびトランザクションの管理に関する必知事項」を参照してください。

5. 手順4で「常に新規トランザクションを開始」を選択した場合は、必要に応じて、「タスク・フローのコールとデータ・コントロールを共有」チェック・ボックス(data-control-scope)から「独立」を選択して、データ・コントロールがコール元のタスク・フローと共有されないようにします。

デフォルトの動作では、データ・コントロールが共有されます。詳細は、「データ・コントロールの共有およびトランザクションの管理に関する必知事項」を参照してください。

6. 手順4で次のいずれかのオプションを選択した場合は、必要に応じて、「タスク・フロー・エントリでのセーブ・ポイントなし」チェック・ボックスを選択して、タスク・フローの開始時にADFモデルのセーブポイントが作成されないようにします。

- 常に既存のトランザクションを使用

- 可能であれば既存のトランザクションを使用

ADFモデルのセーブポイントとは、ADFモデルの状態を保存したスナップショットのことです。「タスク・フロー・エントリでのセーブ・ポイントなし」チェック・ボックスを選択すると、セーブポイントに関連付けられたオーバーヘッドはトランザクション用に作成されません。

7. コール先のバインド・タスク・フロー内のタスク・フロー・リターン・アクティビティを選択します。

8. 「プロパティ」ウィンドウで、「動作」セクションを開きます。

9. コール先のバインド・タスク・フローで新しいトランザクションの作成がサポートされている場合(バインド・タスク・フローで「可能であれば既存のトランザクションを使用」または「常に新規トランザクションを開始」オプションが指定されている場合)、「トランザクションの終了」ドロップダウン・リストから次のいずれかを選択します。

- commit: 選択すると、既存のトランザクションをデータベースにコミットします。

- ロールバック: タスク・フローの開始時に新しいトランザクションを初期状態までロールバックする場合に選択します。これには、トランザクションの取消しと同じ効果があります。

10. コール先のバインド・タスク・フロー内でユーザーが行った変更をタスク・フロー終了時に破棄する場合は、「セーブポイントのリストア」ドロップダウン・リストで「true」を選択します。タスク・フローの開始時に作成されたセーブポイントがリストアされます。

27.3.2 「Transaction」オプション指定時の処理

例27-1は、コール先のバインド・タスク・フローのトランザクション・オプションのメタデータを示しています。この<new-transaction>要素は、コール先のバインド・タスク・フローの起動時に新しいトランザクションが常に開始されることを示しています。<new-transaction>要素は、「トランザクション」セクションで「常に新規トランザクションを開始」の値を選択する場合に生成されます。

例27-1は、コール先のタスク・フローのタスク・フロー・リターン・アクティビティ上にあるトランザクション・オプションのメタデータも示しています。<commit/>要素は、既存のトランザクションをデータベースにコミットします。<outcome>要素は、バインド・タスク・フローの終了時にコール元に戻される結果を、リテラルで指定します(例: success)。コール元のADFタスク・フローは、この結果に基づいて制御フロー・ルールを定義できます。戻された時点の制御フローの定義の詳細は、「タスク・フロー・リターン・アクティビティの使用」を参照してください。

例27-1 コール先のバインド・タスク・フローのメタデータ

<task-flow-definition id="trans-taskflow-definition">
<default-activity>taskFlowReturn1</default-activity>
<transaction>
<new-transaction/>
</transaction>
<task-flow-return id="taskFlowReturn1">
<outcome>
<name>success</name>
<commit/>
</outcome>
</task-flow-return>
</task-flow-definition>

27.3.3 データ・コントロールの共有およびトランザクションの管理に関する必知事項

複数のトランザクション間ではデータ・コントロールを同時に共有できません。タスク・フローがトランザクションの管理を行う場合は、data-control-scopeオプションに選択する値が、バインド・タスク・フローのtransactionオプション設定に影響を与えることがあります。表27-1で、これらのオプションの対話について説明します。

ADFモデル・レイヤーでは、フレーム内のデータ・コントロールが追加されるトランザクションを管理するためのDataControlFrameインタフェースが公開されます。DataControlFrameインタフェースによって、次のようなメソッドが公開されます。

- beginTransaction()

- commit()

- rollback()

同様に、ADF Controllerを使用すると、トランザクションの境界を定めること、タスク・フローの開始時にトランザクションを開始すること、およびタスク・フローの終了時にトランザクションをコミットまたはロールバックすることがタスク・フローで可能になります。そのために、ADFモデル・レイヤーのDataControlFrameインタフェースで公開されるメソッドが起動されます。

ADFコントローラでは、表27-1にリストするトランザクション・オプションがサポートされます。これらのトランザクション・オプションの動作は、タスク・フローの概要エディタで「タスク・フローのコールとデータ・コントロールを共有」リスト(XML要素: <data-control-scope>)から「共有」または「独立」が選択されているかどうかで異なります。

表27-1 トランザクション設定の動作

トランザクション設定

共有データ・コントロール・スコープ

独立データ・コントロール・スコープ

コントローラ・トランザクションなし

DataControlFrameは、トランザクション操作(トランザクションの開始、コミットまたはロールバック)を実行するデータバインドされたタスク・フローなしで共有されます。データ・コントロール・フレームの既存のトランザクション状態は残り、同じデータ・コントロール・フレームを共有する他のバインドされたタスク・フローによって変更されることがあります。

開いているトランザクションなしで新しいDataControlFrameが作成されます。

常に新規トランザクションを開始

XML要素: <new-transaction/>

まだトランザクションを開いていない場合は新しいトランザクションを開始し、すでに開いている場合は例外をスローします。

常に新しいトランザクションを開始します。

常に既存のトランザクションを使用

XML要素: <requires-existing-transaction/>

まだトランザクションを開いていない場合は、例外がスローされます。

無効です。チェックボックスは選択できません。

可能であれば既存のトランザクションを使用

XML要素: <requires-transaction/>

まだトランザクションを開いていない場合は、新しいトランザクションを開始します。

常に新しいトランザクションを開始します。

次のいくつかの例は、表27-1で説明されているデータ・コントロール・スコープとトランザクション・プロパティに対して様々な値の組合せを構成する際に、バインド・タスク・フローがどのように相互作用するかを示しています。

- 2つのバインド・タスク・フロー・トランザクションを完全に分離して、別々にコミットまたはロールバックできるようにします。詳細は、「完全に切り離されたトランザクションの作成」を参照してください。

- 2つのバインド・タスク・フローで、接続リソースを保存するトランザクションが共有されていること、およびコール先のバインド・タスク・フローをコール元のバインド・タスク・フロー・トランザクションに結合できないときにはそのトランザクションを停止することを保証します。詳細は、「コール先のバインド・タスクと既存のトランザクションとの結合の保証」を参照してください。

- コール元のバインド・タスク・フロー・トランザクションが存在する場合はそのトランザクションに結合し、存在しない場合は独自のトランザクションを作成するバインド・タスク・フローをコールします。詳細は、「可能であれば既存のトランザクションを使用」を参照してください。

上のリストは、すべての可能な構成オプションではなく一般的なユースケースを示しています。

27.3.3.1 完全に切り離されたトランザクションの作成

図27-5は、個別のトランザクションを作成するために構成される複数のタスク・フローを示しています。図27-5の2つのバインド・タスク・フローは組み合されていますが、それらのトランザクションは完全に切り離されています。この実装は、コール・センター・エージェントが顧客の注文を受けてから、注文詳細をアプリケーションに入力する状況で適切です。注文プロセスの終わりに差し掛かったある時点で、顧客は自分の伝えた配達先住所が間違っていたことに気付きます。コール・センター・エージェントを助けるために、注文詳細(注文番号、数量など)のトランザクションとは別のトランザクションで配達先住所の更新とコミットを行うアプリケーションを設計しました。顧客が配達先住所の修正を希望するこのシナリオでは、別のトランザクションで注文詳細が管理されているため、コール・センター・エージェントは、配達先住所を修正するために注文詳細への変更をロールバックする必要はありません。

図27-5では、バインドなしタスク・フローがバインド・タスク・フロー#1をコールします。バインド・タスク・フロー#1は次のように構成されているため、データ・コントロール・フレーム#1が作成されます。

- 値isolatedを持つdata-control-scope

- 常に新規トランザクションを開始

バインド・タスク・フロー#1では、2つの異なるビュー・オブジェクトの属性がデータ・コントロール・フィールドとして公開されます(viewObject1.XおよびviewObject2.Y)。XおよびYの初期値は、10および20にそれぞれ設定されています。エンド・ユーザーは、バインド・タスク・フロー#1へのアクセス中にXを10から30へ更新し、Yは変更せずに残します。これにより、トランザクションは変更済、つまり、ダーティとしてマークされます。これは、コミットまたはロールバックが必要なトランザクションへの変更が存在することを意味します。

バインド・タスク・フロー#1は、バインド・タスク・フロー#2をコールします。バインド・タスク・フロー#2は次のように構成されているため、データ・コントロール・フレーム#2が作成されます。

- 値isolatedを持つdata-control-scope

- 常に新規トランザクションを開始

データ・コントロール・フレーム#1のトランザクションがまだコミットされていないこと、およびデータ・コントロール・フレーム#2には別個のデータベース接続と別個のタスク・フロー・トランザクションが存在することに注意してください。その結果、バインド・タスク・フロー#2にあるデータ・コントロール・フィールドXおよびYの初期値は、10および20になります。エンド・ユーザーは、バインド・タスク・フロー#2へのアクセス中にYを40に更新し、Xは変更せずに残します。これにより、バインド・タスク・フロー#2のトランザクションがダーティとしてマークされます。次に、バインド・タスク・フロー#2は、Yへの変更をデータベースにコミットするタスク・フロー・リターン・アクティビティをコールし、バインド・タスク・フロー#1に制御を戻します。バインド・タスク・フロー#2ではXの値が変更されなかったため、このデータ・コントロール・フィールドへの変更は発生しません。

バインド・タスク・フロー#1には別個のデータ・コントロール・フレーム(データ・コントロール・フレーム#1)と別個のトランザクションが存在するため、バインド・タスク・フロー#1にあるデータ・コントロール・フィールドXおよびYの値は、30および20のまま残ります(バインド・タスク・フロー#1がバインド・タスク・フロー#2をコールしたときの値)。ここで、バインド・タスク・フロー#1は、タスク・フロー・リターン・アクティビティ(コミットに設定)をコールし、Xの値をデータベースに保存します。バインド・タスク#1のトランザクションではYの値が変更されなかったため、Yの値は変更されません。

バインドなしタスク・フローに戻った後で、XおよびYの値をデータベースからリフレッシュすると、更新された値30および40が返されます。

図27-5 完全に切り離されたトランザクション

27.3.3.2 コール先のバインド・タスクと既存のトランザクションとの結合の保証

図27-6は、2つのバインド・タスク・フローを示しています。この構成では、コール元である1つ目のバインド・タスク・フローのトランザクションに2つ目のバインド・タスク・フローが結合されることが保証されます。このような実装が適切なシナリオの例としては、アプリケーションにおける請求書と個別の請求書明細の作成があげられます。請求書明細を作成するときには、その請求書明細を含む親請求書を作成しないと意味をなしません。請求書と請求書明細の作成用に2つの別個のタスク・フローを構築する場合、請求書明細タスク・フローでは、別個のトランザクションを作成するかわりに、コール元のタスク・フロー(この場合、請求書タスク・フロー)のトランザクションに結合することを明確に規定する必要があります。

図27-6は、バインド・タスク・フロー(バインド・タスク・フロー#1)をコールするバインドなしタスク・フローを構成することで、前述のユースケースにどのように対処できるかを示しています。バインドなしタスク・フローには、独自のデータ・コントロール・フレーム(データ・コントロール・フレーム#1)があります。バインド・タスク・フロー#1では、トランザクションが開始されます。また、次のように構成されているため、データ・コントロール・フレーム(データ・コントロール・フレーム#0)も存在します。

- 値isolatedを持つdata-control-scope

- 常に新規トランザクションを開始

バインド・タスク・フロー#1では、2つの異なるビュー・オブジェクトの属性がデータ・コントロール・フィールドとして公開されます(viewObject1.XおよびviewObject2.Y)。XおよびYの初期値は、10および20にそれぞれ設定されています。エンド・ユーザーは、バインド・タスク・フロー#1へのアクセス中にXを10から30へ更新し、Yは変更せずに残します。これにより、データ・コントロール・フレーム#1に関連付けられているタスク・フロー・トランザクションAが変更済、つまり、ダーティとしてマークされます。これは、コミットまたはロールバックが必要なトランザクションへの変更が存在することを意味します。

バインド・タスク・フロー#1は、バインド・タスク・フロー#2をコールします。バインド・タスク・フロー#2は、次のように構成されます。

- 値sharedを持つdata-control-scope

- 常に既存のトランザクションを使用

このように構成されているため、新しいデータ・コントロール・フレームは作成されません。バインド・タスク・フロー#2では、バインド・タスク・フロー#1と同じデータ・コントロール・フレーム(データ・コントロール・フレーム#1)が使用されます。バインド・タスク・フロー#1のXに適用された変更は、バインド・タスク・フロー#2に反映されます。バインド・タスク・フロー#2のYに加えた更新は、バインド・タスク・フロー#2で、コミットを指定するタスク・フロー・リターン・アクティビティが実行されて制御が戻った後で、バインド・タスク・フロー#1に反映されます。このYへの更新がバインド・タスク・フロー#1に反映されるのは、バインド・タスク・フロー#2のタスク・フロー・リターン・アクティビティでコミット・オプションが指定されているからではなく、共有データ・コントロール・スコープが指定されていることによります。

タスク・フロー・リターン・アクティビティのコミット・オプションとロールバック・オプションは、トランザクションを開始するバインド・タスク・フローでのみ有効であることに注意してください。バインド・タスク・フロー#1のタスク・フロー・リターン・アクティビティでコミットすると、データベースでは変更が確定されてもバインド・タスク・フロー#2では確定されないのはこの理由によります。

図27-6 結合されたトランザクションの保証

27.3.3.3 可能であれば既存のトランザクションを使用

「コール先のバインド・タスクと既存のトランザクションとの結合の保証」では、2つ目のバインド・タスク・フローをコールするバインド・タスク・フローを構成してから、コール元のバインド・タスク・フロー・トランザクションへのコール先のバインド・タスク・フローの結合を保証する方法について説明しました。コール元のバインド・タスク・フローの構成を次の設定に変更する際に、

- 値isolatedを持つdata-control-scope

- コントローラ・トランザクションなし

コール先のバインド・タスク・フローを変更せずに残すと、バインド・タスク・フローの実行が停止され、次のエラー・メッセージが実行時に表示されます。

ADFC-00006: Existing transaction is required when calling task flow ''{0}''

上のシナリオは、コール先のバインド・タスク・フローを次のように構成する利点を示すものです。

- 値sharedを持つdata-control-scope

- 可能であれば既存のトランザクションを使用

この後者の構成は、コール元のバインド・タスク・フローでトランザクションが作成されていない場合、コール先のバインド・タスク・フローでトランザクションが作成されることを意味します。

コール先のバインド・タスクでの独自のトランザクション作成を保証する、別の構成オプションは次のとおりです。

- 値isolatedを持つdata-control-scope

- 可能であれば既存のトランザクションを使用

これにより、コール元のバインド・タスク・フローで構成したトランザクション・オプションに関係なく、コール先のバインド・タスク・フローで独自のトランザクションが作成されます。その効果は、コール先のバインド・タスク・フローで「常に新規トランザクションを開始」の使用を設定した場合と同じです。

27.3.4 ADFビジネス・コンポーネントのデータベース接続とタスク・フローのトランザクション・オプションに関する必知事項

ADFコントローラでは、ADFビジネス・コンポーネント・アプリケーション・モジュールのデータベース接続がアプリケーション内で共有されます。このアプリケーションには、複数のルート・アプリケーション・モジュール(アプリケーション・モジュールごとにデータベース接続が存在する)が存在し、タスク・フローのトランザクション・オプションを組み合せることで接続が共有されます。つまり、アプリケーションの連鎖したタスク・フロー・セット(値sharedのdata-control-scopeを持つ)を、次のトランザクション・オプションと組み合せて構成します。

- 常に新規トランザクションを開始

- 常に既存のトランザクションを使用

- 可能であれば既存のトランザクションを使用

この実装により、各ユーザーが作成するデータベース接続の数を減らせるため、アプリケーションのスケーラビリティが向上します。これは、ADFライブラリJARを通じてアプリケーションにタスク・フローやルート・アプリケーション・モジュールを追加する場合は特に有効です。

連鎖したタスク・フロー・セットとは、アプリケーション内に2つ以上のタスク・フローからなる連鎖が含まれるように、特定のタスク・フローで他のタスク・フローをコールすることです。たとえば、図27-2では、バインドなしタスク・フローUTF1がバインド・タスク・フローBTF1をコールし、そのタスク・フローがバインド・タスク・フローBTF2をコールします。

注意:

ルート・アプリケーション・モジュールでデータベース接続を共有しない場合は、値isolatedのdata-control-scopeが、アプリケーションの連鎖したタスク・フローで使用されるように構成してください。

ただし、同じデータ・モデル・プロジェクト内の個々のルート・アプリケーション・モジュールが異なるデータ・ソースに接続するときは、別の動作を構成する場合があります。たとえば、2つの異なるデータベース・システムからのデータを表示する場合や、同じデータベース内の2つの異なるスキーマへの接続が必要な場合があります。

この最後のシナリオ(ルート・アプリケーション・モジュールが独自のデータベース接続を保持する)を実装するには、アプリケーションのタスク・フローで、transactionプロパティの値を「コントローラ・トランザクションなし」(デフォルト値)に設定します。これにより、各ルート・アプリケーション・モジュールで、分離された独自のデータベース接続が管理され、ADFコントローラでADFビジネス・コンポーネントのトランザクション動作が管理されなくなります。

27.4 バインド・タスク・フローの再開

エンド・ユーザーが「戻る」ボタンをクリックして、終了後のバインド・タスク・フローに戻るケースを処理するには、バインド・タスク・フローにtask-flow-reentryオプションを指定できます。このオプションでは、バインド・タスク・フロー内のページを再開できるかどうかを指定します。

再開時には、バインド・タスク・フローの各入力パラメータが、バインド・タスク・フローの最初の開始時のアプリケーションの状態ではなく、現在のアプリケーションの状態によって評価されます。

27.4.1 再開動作の設定方法

task-flow-reentryオプションを指定することで、バインド・タスク・フロー上の再開動作を設定できます。

始める前に:

バインド・タスク・フローでの再開オプションの構成内容を理解しておくと役に立つ場合があります。詳細は、「バインド・タスク・フローの再開」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

再開動作を設定するには:

1. 「アプリケーション」ウィンドウで、バインド・タスク・フローをダブルクリックします。

2. エディタ・ウィンドウで、「概要」タブをクリックします。

3. 概要エディタで、「動作」ナビゲーション・タブをクリックします。

4. 「動作」ページで、「タスク・フローの再入力」ドロップダウン・リストから次のいずれかを選択します。

- reentry-allowed: バインド・タスク・フロー内の任意のビュー・アクティビティについて再開が許可されます。

- reentry-not-allowed: バインド・タスク・フローの再開は許可されません。バインド・タスク・フローにreentry-not-allowedを指定しても、エンド・ユーザーはブラウザの「戻る」ボタンをクリックするとバインド・タスク・フロー内のページに戻れます。ただし、ユーザーがそのページでボタンのクリックなどなんらかの操作を行うと、バインド・タスク・フローを不正に再開したことを示す例外(InvalidTaskFlowReentryなど)がスローされます。実際の再開の条件は再開したページの送信時に識別されます。
例外の表示と制御フローのルーティングを処理する例外ハンドラを設定して、コール先のバインド・タスク・フローのデフォルト・アクティビティに移動するようにできます。バインド・タスク・フローが別のバインド・タスク・フローからコールされたものでない場合は、通常のWebエラーがポストされ、web.xmlファイルでの指定に従って処理されます。

- reentry-outcome-dependent: ブラウザの「戻る」ボタンを使用したバインド・タスク・フローの再開は、同じバインド・タスク・フローの前回終了時にタスク・フロー・リターン・アクティビティを介して受け取った結果に基づいて行われます。指定する場合、コール先のバインド・タスク・フローのタスク・フロー・リターン・アクティビティにもreentry-allowedまたはreentry-not-allowedのいずれかを指定し、結果に基づいた再開動作を定義する必要があります。
このオプションを選択した場合、ユーザーは自身が初めにタスク・フローを終了した方法にのみ基づいて、そのタスク・フローに「戻る」ボタンで移動できます。たとえば、ショッピング・カートを表すタスク・フローの再開は、ユーザーが注文を取り消してそのフローを終了した場合には可能ですが、ユーザーが注文を完了してフローを終了した場合には不可能です。

27.4.2 結果依存オプションの設定方法

「再開動作の設定方法」で説明したように、reentry-outcome-dependentオプションを指定したバインド・タスク・フローに対して、結果依存のオプションを設定できます。

始める前に:

バインド・タスク・フローでの再開オプションの構成内容を理解しておくと役に立つ場合があります。詳細は、「バインド・タスク・フローの再開」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

結果依存オプションを設定するには:

1. 「アプリケーション」ウィンドウで、バインド・タスク・フローをダブルクリックします。

2. バインド・タスク・フローのタスク・フロー・ダイアグラムで、タスク・フロー・リターン・アクティビティを選択します。

タスク・フロー・リターン・アクティビティの追加の詳細は、「タスク・フロー・リターン・アクティビティの使用」を参照してください。

3. 「プロパティ」ウィンドウで「一般」セクションを開き、「名前」フィールドにsuccessまたはfailureなどのリテラルの名前を入力します。

4. 「動作」セクションを開き、「再入力」ドロップダウン・リストから次のオプションのいずれかを選択します。

- reentry-allowed: バインド・タスク・フロー内の任意のビュー・アクティビティについて再開が許可されます。

- reentry-not-allowed: バインド・タスク・フローの再開は許可されません。バインド・タスク・フローにreentry-not-allowedを指定しても、エンド・ユーザーはブラウザの「戻る」ボタンをクリックするとバインド・タスク・フロー内のページに戻れます。ただし、ユーザーがそのページでボタンのクリックなどなんらかの操作を行うと、バインド・タスク・フローを不正に再開したことを示す例外(InvalidTaskFlowReentryなど)がスローされます。実際の再開の条件は再開したページの送信時に識別されます。
例外の表示と制御フローのルーティングを処理する例外ハンドラを設定して、コール先のバインド・タスク・フローのデフォルト・アクティビティに移動するようにできます。バインド・タスク・フローが別のバインド・タスク・フローからコールされたものでない場合は、通常のWebエラーがポストされ、web.xmlファイルでの指定に従って処理されます。

27.4.3 再入力のバインド・タスク・フロー構成時の処理

JDeveloperによって、再入力用に指定する構成オプションでタスク・フローのメタデータが更新されます。次の例は、特定の結果に基づき再入力を許可するように構成されたタスク・フローを示しています。

<task-flow-definition id="task-flow-definition1">
<default-activity>view1</default-activity>
<task-flow-reentry>
<reentry-outcome-dependent/>
</task-flow-reentry>
<view id="view1">
<page>/page1.jsf</page>
</view>
<task-flow-return id="taskFlowReturn1">
<outcome>
<name>taskFlowReturn1</name>
<reentry-allowed/>
</outcome>
</task-flow-return>
</task-flow-definition>

実行時に、再入力を許可するように構成されるタスク・フローに次のイベントが発生します。

- ユーザーがコンポーネントを起動すると、タスク・フローが再入力され、またそれにより、HTTP POSTまたはGETメソッドが起動されます。

- pageFlowスコープでのタスク・フローのマネージドBean値は、タスク・フローの終了時の値にリストアされません。

- 「タスク・フローのパラメータの使用」に示すように、再入力されたタスク・フローで入力パラメータが定義されている場合、タスク・フローの再入力時に、それらの値は親タスク・フローの現在の状態を使用して再作成されます。

27.5 タスク・フローでの例外の処理

タスク・フローの実行時には、なんらかの例外処理を必要とする、次のような例外が発生する場合があります。

- メソッド・コール・アクティビティからスローされる例外。

- タスク・フローのイニシャライザまたはファイナライザとして記述したカスタム・メソッドからスローされる例外。

- アクティビティの実行権限がないユーザー。

アクティビティからスローされる例外や、ADF Controllerのその他のタイプのエラーから生じる例外を処理するために、バインド・タスク・フローまたはバインドなしタスク・フローの1つのアクティビティを、例外ハンドラとして指定できます。

タスク・フローが例外をスローすると、制御フローは指定された例外処理アクティビティに渡されます。たとえば、例外処理アクティビティは、エラー・メッセージを表示するビュー・アクティビティである場合があります。また、例外のタイプを評価するEL式に基づいてメソッドに制御フローを渡すルーター・アクティビティである場合もあります。次に例を示します。

#{controllerContext.currentViewPort.exceptionData.class.name == 'oracle.adf.controller.ControllerException'}

制御フローが例外処理アクティビティに渡された後、その例外処理アクティビティからのフローには、標準の制御フロー・ルールが使用されます。たとえば、例外処理アクティビティとしてルーター・アクティビティを指定するとします。実行時、例外に反応して、タスク・フローから例外処理アクティビティ(この場合はルーター・アクティビティ)に制御が渡されます。例外ハンドラとしてルーター・アクティビティを指定した上で、処理の対象となる例外のタイプに基づいてルーターが起動するタスク・フロー制御ケースを定義できます。これにより、例外発生時にエンド・ユーザーのアプリケーション・セッションを適切に管理できます。詳細は、「制御フローについて」を参照してください。

オプションで、バインド・タスク・フローおよびバインドなしタスク・フローの両方に対する例外ハンドラを指定できます。各タスク・フローは、例外ハンドラを1つのみ保持できます。ただし、別のタスク・フローからコールされるタスク・フローは、コール元の例外ハンドラ以外に別の例外ハンドラを1つ保持できます。さらに、ページ上のリージョンは、ページを含むタスク・フローとは別の例外ハンドラを保持できます。例外ハンドラのアクティビティとしては、ビュー・アクティビティやルーター・アクティビティなど、サポートされる任意のアクティビティ・タイプを使用できます。

バインド・タスク・フローに指定されている例外ハンドラのアクティビティがない場合、コール元のタスク・フローがあり、そこに例外ハンドラのアクティビティがあれば、コール元バインド・タスク・フローの例外ハンドラのアクティビティに制御が渡されます。例外は、例外ハンドラのアクティビティまたは最上位のバインドなしタスク・フローに到達するまで、タスク・フローのスタックに伝播されます。例外ハンドラが見つからない場合、例外はWebコンテナに伝播されます。

バインド・タスク・フローに例外ハンドラ・アクティビティが指定されている場合は、その例外ハンドラ・アクティビティによって例外が処理された後も、アプリケーションが有効なままになるようにしてください。その方法の1つは、例外ハンドラ・アクティビティの後、同じタスク・フローのビュー・アクティビティにリダイレクトすることです。

また、ADFモデルなどの他のモジュールには例外処理機能が実装されています。一部では、アプリケーションでの例外の処理方法を決定できるケースもあります。たとえば、データバインド・メソッド・アクティビティは、ページ定義とEL式を次の形式で有するメソッド・アクティビティです。

#{bindings.somebindingname.execute}

ここで、somebindingnameは、ページ定義で設定されたメソッド・バインディングです。

どのタイプのバインディングが例外をスローしても、reportException()メソッドをコールし、バインディング・コンテナに例外を格納するADFモデルによって取得されます。その後、ページのレンダリング時に、ページにエラーが表示されます。

メソッド・アクティビティがメソッド・バインディングを起動すると、例外により発生したエラーを表示するページがなくなるのは、2つのページ間の移動時に例外が発生するからです。アプリケーションにエラーを認識させるには、Oracle ADFに例外を再スローさせて、例外ハンドラ・アクティビティがあればそこに移動するADFコントローラの例外ハンドラ・メカニズムによってその例外を取得します。

「エラー処理のカスタマイズ」の説明のとおり、特に、reportException()メソッドなど、メソッドのオーバーライドを決定した場合に注意が必要なのは、このケースではADFコントローラとADFモデルの例外ハンドラの両方がコールされるからです。

27.5.1 例外ハンドラとしてアクティビティを指定する方法

ADFリージョンとして実行するバインド・タスク・フローに対して、例外ハンドラ・アクティビティを指定できます。バインド・タスク・フローで発生した例外がタスク・フローの例外ハンドラで処理されない場合、その例外は親ページのタスク・フローのスタックには伝播されません。かわりに、その例外は未処理の例外となります。

始める前に:

タスク・フローで構成可能な例外処理オプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローでの例外の処理」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

タスク・フローの例外ハンドラとしてアクティビティを指定するには:

1. 「アプリケーション」ウィンドウで、あるアクティビティを例外ハンドラとして指定するタスク・フローをダブルクリックします。

2. タスク・フロー・ダイアグラム内のアクティビティを右クリックして、「アクティビティのマーク」→「例外ハンドラ」の順に選択します。

タスク・フロー内のアクティビティ上に、例外ハンドラであることを示す赤い感嘆符が表示されます。図27-7に例を示します。

図27-7 例外ハンドラとして指定されたアクティビティの例

3. アクティビティのマークを外すには、タスク・フロー・ダイアグラム内のアクティビティを右クリックして、「アクティビティのマーク解除」→「例外ハンドラ」の順に選択します。

指定された例外ハンドラがすでに存在するタスク・フロー内で、アクティビティを例外ハンドラとしてマークすると、古いハンドラのマークは解除されます。

27.5.2 例外ハンドラとしてアクティビティを指定した場合の処理

あるアクティビティをタスク・フローの例外処理アクティビティとして指定すると、例27-2に示すように、アクティビティのIDを指定する<exception-handler>要素を使用してタスク・フローのメタデータが更新されます。

例27-2 <exception-handler>要素

<exception-handler>activityID</exception-handler>

27.5.3 例外ハンドラとしてカスタム・コードを指定する方法

起動するアクティビティとしてタスク・フロー・アクティビティを指定するかわりに、タスク・フローによる例外のスロー時に起動するカスタム・コードを記述できます。これには次の処理が必要です。

- 次のパッケージのクラスExceptionHandlerを拡張するJavaクラスを記述します。
oracle.adf.view.rich.context.ExceptionHandler

- Fusion Webアプリケーションの.adf\META-INFディレクトリ内のサービスとして記述するJavaクラスを登録します。

次の例は、タスク・フローによってスローされる例外が特定のタイプのエラー・メッセージ(ADF_FACES-30108)に対応するかどうかをチェックするカスタム・コードを示しています。対応する場合は、カスタム・コードによって、タスク・フローがfaces/SessionExpired.jsfページにリダイレクトされます。

package oracle.summit.frmwkext;

import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseId;
import oracle.adf.view.rich.context.ExceptionHandler;

public class CustomExceptionHandler extends ExceptionHandler {

public CustomExceptionHandler() {
super();
}

public void handleException(FacesContext facesContext, Throwable throwable,
PhaseId phaseId) throws Throwable {

String error_message;
error_message = throwable.getMessage();

if (error_message != null &&
error_message.indexOf("ADF_FACES-30108") > -1) {
ExternalContext ectx = facesContext.getExternalContext();
ectx.redirect("faces/SessionExpired.jsf");
}

else {
//Code to execute if the if condition is not met
throw Throwable
}
}
}

カスタム・コードの記述に使用できるAPIの詳細は、次のドキュメントを参照してください。

- Oracle ADF ControllerのJava APIリファレンス

- Oracle ADF FacesのJava APIリファレンス

始める前に:

タスク・フローで構成可能な例外処理オプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローでの例外の処理」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

例外ハンドラとしてカスタム・コードを指定するには:

1. アプリケーションの.adf\META-INFディレクトリで、servicesと呼ばれるディレクトリを作成して、次のディレクトリ・パスを取得します。

application_root\.adf\META-INF\services

ここで、application_rootは、アプリケーションのルート・ディレクトリを参照します。

2. servicesフォルダ内に、oracle.adf.view.rich.context.ExceptionHandlerという名前のテキスト・ファイルを作成します。

3. oracle.adf.view.rich.context.ExceptionHandlerという名前のテキスト・ファイルで例外を処理するには、記述したカスタム・コードのパッケージ名およびクラス名を記述します。

たとえば、次のようなコードを記述します。

oracle.summit.frmwkext.CustomExceptionHandler

4. テキスト・ファイルを保存して閉じます。

27.5.4 例外ハンドラとしてカスタム・コードを指定した場合の処理

実行時にタスク・フローが例外をスローすると、制御は指定されたカスタム・コードに渡されます。

27.5.5 トランザクション中の例外の処理に関する必知事項

トランザクションとして実行可能なバインド・タスク・フローの例外処理アクティビティを指定します。トランザクションとして実行されるバインド・タスク・フローで、タスク・フロー・リターン・アクティビティの「トランザクションの終了」プロパティの値をcommitに設定した場合は、Fusion Webアプリケーションによってトランザクションのコミットが試行されます。Fusion Webアプリケーションによるトランザクションのコミット試行時に例外が発生した場合、例外処理アクティビティは制御を受け取り、エンド・ユーザーに例外を修正する機会を提供します。例外処理アクティビティ(たとえば、ビュー・アクティビティ)を使用して、例外の修正方法およびトランザクションの再コミット方法に関する情報を含む警告メッセージを、エンド・ユーザーに対して表示できます。トランザクションとしてバインド・タスク・フローを有効化する方法、および「トランザクションの終了」プロパティの値としてcommitを設定する方法の詳細は、「バインド・タスク・フローでトランザクションを有効化する方法」を参照してください。

27.5.6 検証エラーの処理に関する必知事項

JSFページの検証エラーの場合、検証エラー・メッセージのページ上の特定のコンポーネントまたはページ全体への添付を標準JSFに依存できます。コンポーネント・レベルのバリデータでは、通常、特定のUIコンポーネントにインラインでエラー・メッセージが添付されます。例外ハンドラのアクティビティに制御を渡す必要はありません。

また、使用するアプリケーションでは、検証ロジックをJSFライフサイクルのモデル更新検証フェーズで実行されるデータ・コントロールに定義する必要があります。このようにすると、最終的なコミットの試行まで待たずに、サーバーへの送信時にデータ・エラーが検出されます。

モデル更新検証フェーズで行われる検証は、通常、モデルの更新後にモデルを検証することを目的としているため、UIコンポーネントに直接アクセスすることはありません。このような検証の多くは、依存するフィールドが同期しているかどうかのチェックなどです。その場合、エラー・メッセージは通常、このロジックがアクセスするページ全体に添付されます。

モデル更新検証フェーズで検出されたエラーをJSFページに添付して、FacesContext.renderResponse()をコールする必要があります。これによって、このフェーズの後に現在の(送信)ページがレンダリングされ、添付されたエラー・メッセージが表示されます。例外ハンドラのアクティビティに制御を渡す必要はありません。

詳細は、「プログラムによる検証とビジネス・ルールの実装」を参照してください。

27.6 セーブポイントを使用するためのアプリケーションの構成

「タスク・フローでのセーブポイントの使用」の説明に従ってタスク・フローにセーブポイントを追加し、関連する機能を構成するには、Fusion Webアプリケーションでセーブポイントを使用できることを確認しておく必要があります。これを行うには、adf-config.xmlファイルの<savepoint-datasource>要素の値を定義して、セーブポイントのデータベース表を含むデータソースのJNDI名を指定します。また、「セーブポイントのデータベース表に関する必知事項」の説明に従ってSQLスクリプト(adfc_create_save_point_table.sql)を実行し、セーブポイントを格納するデータベース表を作成する必要があります。Fusion Webアプリケーションでセーブポイントの使用を開始した後は、別のSQLスクリプト(adfc_cleanup_save_point_table.sql)を使用して、期限切れのセーブポイントを削除できます。

27.6.1 セーブポイントを使用するためのFusion Webアプリケーションの構成方法

アプリケーションのadf-config.xmlファイルの<savepoint-datasource>要素の値を定義して、セーブポイントのデータベース表を含むデータソースのJNDI名を指定します。オプションとして、セーブポイントの有効期限も指定できます。

始める前に:

タスク・フローで構成可能なセーブポイント・オプションの内容を理解しておくと役に立つ場合があります。詳細は、「セーブポイントを使用するためのアプリケーションの構成」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

セーブポイントを使用可能にするようにFusion Webアプリケーションを構成する手順は次のとおりです。

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開いて、「adf-config.xml」をダブルクリックします。

2. 概要エディタで、「コントローラ」ナビゲーション・タブをクリックし、「セーブポイント」セクションを開いて、セーブポイントのデータベース表を含むデータソースのJNDI名を指定する「データソース」プロパティの値を記述します。

たとえば、次のように記述します。

java:comp/env/jdbc/Connection1DS

Connection1はJDeveloper接続名です。

3. オプションとして、「存続時間」プロパティの値を秒単位で記述して、セーブポイントがタスク・フローで作成されてからセーブポイント・マネージャによって削除されるまでの時間を指定します。デフォルト値は86400秒です。

詳細は、「セーブポイントの存続時間に関する必知事項」を参照してください。

4. adf-config.xmlファイルを保存します。

27.6.2 セーブポイントを使用するためにFusion Webアプリケーションを構成した場合の処理

セーブポイントのデータベース表が含まれているデータソースのJNDI名を指定する次の例のようなエントリが、adf-config.xmlファイル内に生成されます。

<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
...
<savepoint-datasource>
java:comp/env/jdbc/Connection1DS
</savepoint-datasource>
<savepoint-expiration>
86399
</savepoint-expiration>
</adf-controller-config>

adf-config.xmlファイルの詳細は、「adf-config.xml」を参照してください。

27.6.3 セーブポイントのデータベース表に関する必知事項

ORADFCSAVPTという名前のデータベース表にセーブポイントが格納されます。このデータベース表が存在しない場合、使用するFusion Webアプリケーションにデータベース表の作成に必要な権限があれば、セーブポイントの初回作成時に作成されます。Fusion Webアプリケーションに必要な権限がない場合は、必要な権限を持つユーザーまたは管理者がSQLスクリプトを使用して、ORADFCSAVPTデータベース表を作成および管理できます。それらのSQLスクリプトは次のとおりです。

- adfc_cleanup_save_point_table.sql
ORADFCSAVPTデータベース表内の各セーブポイントには、有効期限があります。このスクリプトを使用して、有効期限が切れたセーブポイントを削除します。

- adfc_create_save_point_table.sql
このスクリプトを使用して、セーブポイントを格納するORADFCSAVPTデータベース表を作成します。

これらのSQLスクリプトは、JDeveloperインストールの次のディレクトリにあります。

jdev_install\oracle_common\common\sql

27.7 タスク・フローでのセーブポイントの使用

セーブポイントと呼ばれる機能を作成して、特定のインスタンスでFusion Webアプリケーションの状態を取得するタスク・フローを構成できます。これにより、たとえばユーザーがページを完了せずにそのページから移動する場合などに、アプリケーションの状態を保存できるようになります。アプリケーションの状態は、後でリストアできます。

表27-2に、セーブポイントでキャプチャされる情報を示します。

表27-2 保存されるアプリケーションの状態に関する情報

保存される状態情報

説明

ユーザー・インタフェースの状態

現在のページのUIの状態。選択中のタブ、選択中のチェック・ボックス、選択中の表の行、表の列のソート順など。

この状態は、エンド・ユーザーがセーブポイントのリストアでブラウザの「戻る」ボタンを選択できない場合を想定しています。

マネージドBean

セッション・スコープやページ・フロー・スコープなど、使用可能な複数のメモリー・スコープに保存される状態の情報。マネージドBeanを保存するには、シリアライズ可能であることが必要です。シリアライズ可能でないページ・フロー・スコープBeanがある場合にセーブポイントを作成しようとすると、実行時例外が発生します。

リクエスト・スコープは、存続期間が単一のHTTPリクエストであり、その存続期間をリクエスト間のアプリケーション状態の格納には使用できないため、サポートされません。

アプリケーション・スコープのマネージドBeanは、フェイルオーバーのシナリオでは受動化されないため、セーブポイントによって保存およびリストアされません。したがって、アプリケーションでは必要なアプリケーション・スコープの状態を常にすべて使用可能にしておく必要があります。

同じ名前を使用するマネージドBeanはアプリケーション内に複数実装できないため、リストア時にセッション・スコープ内の既存のマネージドBeanの名前が競合することはありません。

ナビゲーションの状態

実行時に、あるタスク・フローが別のタスク・フローをコールするとADFコントローラで保持されるタスク・フロー・コール・スタック。

タスク・フロー・コール・スタックでは、アプリケーション内のエンド・ユーザーの位置、およびそこに至るまでのナビゲーション・パスが追跡されます。また、エンド・ユーザーが開始した永続データ・トランザクションの開始点も識別されます。

ADFモデルの状態

Fusion Webアプリケーションでは、永続データ・モデルやビジネス・ロジックのサービス・プロバイダがADFモデルで表されます。ADFモデルには、現在のバインド・タスク・フローの開始以降に行われたデータ・モデルの更新がすべて保持されます。保存された状態の存続期間に対する制限はモデル・レイヤーにより決定します。詳細は、「Fusion Webアプリケーションでの状態管理の使用」を参照してください。

createSavePointメソッドを起動するメソッド・コール・アクティビティをバインド・タスク・フローに追加して、セーブポイントを作成します。後でセーブポイント・リストア・アクティビティを使用して、作成したセーブポイントに関連付けられたアプリケーションの状態とデータをリストアします。

同一ブラウザ・ウィンドウ内の同一セッションで実行されるタスク・フロー・インスタンスにおいて、ユーザーが後で使用するための保存を繰り返し実行する場合、同じセーブポイントを使用できます。タスク・フローのページごとのナビゲーションに従って、ユーザーが後で使用するための保存を実行すると、既存のセーブポイントが新しいセーブポイントで上書きされます。セーブポイントのリストアの詳細は、「セーブポイントのリストア方法」を参照してください。

式ビルダーのADF ControllerオブジェクトのcurrentViewPortノードによって公開される、createSavePointメソッドを指定できます。または、カスタム・メソッドで指定する属性の値を使用してセーブポイントを更新する、次の例のようなカスタム・メソッドを記述できます。

package viewController;

import java.io.Serializable;

import oracle.adf.controller.ControllerContext;
import oracle.adf.controller.savepoint.SavePointManager;

public class SaveForLater implements Serializable {
public SaveForLater() {
super();
}

public String saveTaskFlow() {
ControllerContext cc = ControllerContext.getInstance();
if (cc != null) {
SavePointManager mgr = cc.getSavePointManager();
if (mgr != null) {
String id = mgr.createSavePoint();
System.out.println("Save point is being set " + id);
...

SavePointListenerインタフェースは、セーブポイント・イベントの発生時にクライアントに通知するメソッドを公開します。SavePointListenerインタフェースは次のパッケージに含まれています。

oracle.adf.controller.savepoint

注意:

バインド・タスク・フロー内で作成されたすべてのセーブポイントは、バインド・タスク・フローの終了時に削除されます。

27.7.1 タスク・フローへのセーブポイントの追加方法

メソッド・コール・アクティビティをタスク・フロー・ダイアグラムにドラッグ・アンド・ドロップして、createSavePointメソッドまたは(作成した場合は)カスタム・メソッドを起動するように構成します。

始める前に:

タスク・フローで構成可能なセーブポイント・オプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローでのセーブポイントの使用」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

- Fusion Webアプリケーションで、jbo.locking.modeプロパティの値をデフォルト値optimisticのままにしていることを確認します。これは、Fusion Webアプリケーションでセーブポイントを使用する場合に必要です。値pessimisticを使用すると、古いセッションはタイムアウトするまでロックされます。ペシミスティック・モードでは、アプリケーションを実行してデータを変更し、データベースに変更をコミットしなかった場合、セーブポイントを作成して後でリストアしようとするとエラーが発生する可能性があります。jbo.locking.modeプロパティの詳細は、「Fusion Webアプリケーションがオプティミスティック・ロックを使用していることを確認する方法」を参照してください。

タスク・フローへのセーブポイントを追加するには:

1. 「アプリケーション」ウィンドウで、セーブポイントを追加するバインド・タスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルから、「アクティビティ」グループにある「メソッド・コール」をダイアグラムにドラッグ・アンド・ドロップします。

3. 「プロパティ」ウィンドウで、「一般」ノードを開き、「メソッド」フィールドでEL式を記述して、メソッド・コール・アクティビティで起動するセーブポイント・メソッドを指定します。必要に応じて、「プロパティ」フィールドにカーソルを移動すると表示されるアイコンから起動するドロップダウン・メニューで、「メソッド式ビルダー」を選択します。

式ビルダーのADF ControllerオブジェクトのcurrentViewPortノードによって公開されるcreateSavePointメソッドを指定する場合、生成されるEL式は次のようになります。

#{controllerContext.currentViewPort.createSavePoint}

4. 制御フローを使用して、メソッド・コール・アクティビティをバインド・タスク・フロー内の他のアクティビティに接続します。

詳細は、「タスク・フローに制御フロー・ルールを追加する方法」を参照してください。

5. オプションとして、Fusion Webアプリケーションのadf-config.xmlファイルでセーブポイント・オプションを構成して、そのアプリケーションに対して暗黙的なセーブポイントを作成できるかどうかなどを指定できます。

詳細は、「暗黙的なセーブポイントを有効化する方法」を参照してください。

27.7.2 タスク・フローにセーブポイントを追加した場合の処理

createSavePointメソッドを起動するためのメソッド・コール・アクティビティを構成すると、タスク・フローのソース・ファイルに次の例のようなエントリが生成されます。

<method-call id="methodCall1">
<method id="__3">#{controllerContext.currentViewPort.createSavePoint}</method>
</method-call>

27.7.3 セーブポイントのリストア方法

セーブポイント・リストア・アクティビティを使用すると、アプリケーション用に以前に保持されたセーブポイントをリストアできます。セーブポイント・リストア・アクティビティでは、最初にcreateSavePointメソッドを起動して作成されたセーブポイントを使用して、リストアするセーブポイントが識別されます。

現在保持されているセーブポイントのリストは、createSavePointで取得できます。ただし、リストア対象のセーブポイントは自動的に判別されません。ユーザーがリストからセーブポイントを選択するか、アプリケーション開発者がプログラムでセーブポイントを選択する必要があります。その後、セーブポイントのIDが、リストアを実行するセーブ・ポイント・リストア・アクティビティに渡されます。

始める前に:

タスク・フローで構成可能なセーブポイント・オプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローでのセーブポイントの使用」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

セーブポイント・リストア・アクティビティをバインド・タスク・フローまたはバインドなしタスク・フローに追加するには:

1. 「アプリケーション」ウィンドウで、セーブポイント・リストア・アクティビティを追加するタスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルから、「アクティビティ」グループにある「セーブポイントのリストア」をダイアグラムにドラッグ・アンド・ドロップします。

3. 「プロパティ」ウィンドウで「一般」セクションを開き、評価されるとcreateSavePointメソッドの起動時に最初に作成されたセーブポイントを取得する「セーブポイントID」フィールドのEL式を記述します。

式ビルダーを使用してADF ControllerオブジェクトのgetSavePointメソッドを指定する場合は、次のようなEL式が生成されます。

#{SessionScope.myBean.savepointID}

27.7.4 セーブポイントのリストア時の処理

セーブポイントIDを取得するセーブポイント・リストア・アクティビティを追加すると、タスク・フローのソース・ファイルに次の例のようなエントリが生成されます。

<save-point-restore id="savePointRestore1">
<save-point-id id="__4">#{sessionScope.myBean.savepointID}</save-point-id>
</save-point-restore>

27.7.5 セーブポイント・リストア・ファイナライザの使用方法

セーブポイント・リストア・アクティビティの使用時には、アプリケーション状態のリストアの一部として、アプリケーション固有のロジックを起動することが必要な場合があります。ファイナライザ・メソッドを指定する、バインド・タスク・フローの「セーブポイントのリストア・ファイナライザ」プロパティのEL式を記述できます。バインド・タスク・フローの状態がリストアされた後、指定したメソッドがタスク・フローによって起動されます。リストアを続行する前に、アプリケーションの状態が正しいことを確認するために必要なロジックが実行されます。

始める前に:

タスク・フローで構成可能なセーブポイント・オプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローでのセーブポイントの使用」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

セーブポイント・リストア・ファイナライザを使用するには:

1. 「アプリケーション」ウィンドウで、セーブポイント・リストア・ファイナライザを使用するバインド・タスク・フローをダブルクリックします。

2. 「構造」ウィンドウでバインド・タスク・フローのノード(task-flow-definition)を右クリックし、「プロパティに移動」を選択します。

3. 「プロパティ」ウィンドウで、「一般」セクションを開き、「セーブポイント・リストア・ファイナライザ」プロパティ・フィールドにカーソルを移動すると表示されアイコンから起動するドロップダウン・リストで「式ビルダー」を選択します。

4. 起動するファイナライザ・メソッドを指定するEL式を記述します。

27.7.6 タスク・フローによるセーブポイント・リストア・ファイナライザ起動時の処理

「セーブポイント・リストア・ファイナライザ」プロパティのEL式を記述すると、タスク・フローのソース・ファイルに次の例のようなエントリが生成されます。

<task-flow-definition id="task-flow-definition1">
<save-point-restore-finalizer id="__2">#{sessionScope.MyBean.invokeFinalizer}
</save-point-restore-finalizer>
</task-flow-definition>

27.7.7 暗黙的なセーブポイントを有効化する方法

タスク・フローのセーブポイントは、黙示的または明示的に分類できます。明示的セーブポイントをバインド・タスク・フローまたはバインドなしタスク・フローで作成するには、エンド・ユーザーのアクションが必要です。たとえば、エンド・ユーザーがボタンをクリックするとメソッド・コール・アクティビティが起動し、結果としてセーブポイントが作成されます。

暗黙的な保存は、バインド・タスク・フローからのみ実行できます。元のタスク・フローでセーブポイントが作成された時のあらゆるものが含まれます。これは、次の理由でデータが自動的に保存される場合に実行されます。

- エンド・ユーザーが非アクティブ状態であったことによりセッションがタイムアウトした場合

- エンド・ユーザーがデータを保存せずにログアウトした場合

- エンド・ユーザーが唯一のブラウザ・ウィンドウを閉じて、アプリケーションをログアウトした場合

- エンド・ユーザーがデータを保存せずに制御フロー・ルール(たとえば、外部URLに移動するためのlinkコンポーネント)を使用して現在のアプリケーションから移動した場合

暗黙的セーブポイントを有効化するには、使用するFusion Webアプリケーションのadf-config.xmlファイルに要素を追加して、そのバインド・タスク・フローを重要として指定する必要があります。

使用するアプリケーションのadf-config.xmlファイル、および暗黙的セーブポイントを作成するバインド・タスク・フローを構成します。暗黙的セーブポイントを有効化すると、Fusion Webアプリケーションで(有効化しない場合には行われない)追加の処理を行う必要があるため、パフォーマンス上のコストがかかります。そのため、アプリケーションで暗黙的セーブポイントを明示的に有効化し、適用されるタスク・フローを指定する必要があります。

始める前に:

タスク・フローで構成可能なセーブポイント・オプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローでのセーブポイントの使用」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

暗黙的セーブポイントを有効化するには:

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開いて、「adf-config.xml」をダブルクリックします。

2. 概要エディタの「コントローラ」ナビゲーション・タブをクリックして、「セーブポイント」セクションを開き、「暗黙的セーブポイントの有効化」チェック・ボックスを選択します。

adf-config.xmlファイル内に次のエントリが生成されます。

<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
...
<enable-implicit-savepoints>true</enable-implicit-savepoints>
</adf-controller-config>

adf-config.xmlファイルの詳細は、「adfc-config.xml」を参照してください。

3. 「アプリケーション」ウィンドウで、バインド・タスク・フローをダブルクリックします。

4. エディタ・ウィンドウで、「概要」タブをクリックします。

5. 概要エディタで「動作」ナビゲーション・タブをクリックし、「クリティカル」チェック・ボックスを選択します。

27.7.8 暗黙的セーブポイントの有効化に関する必知事項

暗黙的セーブポイントの作成時に複数のウィンドウが開いている場合は、それぞれのブラウザ・ウィンドウに対して異なるセーブポイントが作成されます。これには、ブラウザ・ウィンドウのルート・ビュー・ポート以降のあらゆるものが含まれます。ADF Controllerオブジェクトの下にあるsavePointManagerノードを使用すると、暗黙的セーブポイントのリストを取得するメソッド・コール・アクティビティのメソッド・プロパティに対するEL式を記述できます。生成されるEL式は、次のようになります。

ControllerContext.savePointManager.listSavePointIds

暗黙的なセーブポイントは、現在のルート・ビュー・ポートの下のビュー・ポートに対するページ・フロー・スタックに重要なタスク・フローが存在する場合にのみ生成されます。次のようなADF Controllerリソースに対するリクエストでは、暗黙的なセーブポイントは生成されません。

- タスク・フロー・コール・アクティビティ

- タスク・フロー・リターン・アクティビティ

- セーブポイント・リストア・アクティビティ

- ダイアログ

スタックの最下位のタスク・フローが完了したときか、新しい暗黙的なセーブポイントが生成されたときのいずれか早い方で、暗黙的なセーブポイントは削除されます。

27.7.9 セーブポイントの存続時間に関する必知事項

adf-config.xmlファイルで定義されるアプリケーション・レベルのプロパティ(savepoint-expiration)は、セーブポイントがタスク・フローで作成されてからセーブポイント・マネージャによって削除されるまでの時間(存続時間)を決定します。デフォルト値は86400秒(24時間)です。

個々のセーブポイントの存続時間を変更するには、次のパッケージに含まれるSavePointMangerのインスタンスに対してsetSavePointTimeToLiveメソッドをコールします。

oracle.adf.controller.savepoint

SavePointManagerのインスタンスは、次のようにして取得できます。

SavePointManager mgr = ControllerContext.getInstance().getSavePointManager();

次の例は、setSavePointTimeToLiveメソッドの構文を示しています。

public void setSavePointTimeToLive(long timeInSeconds) {
}

setSavePointTimeToLiveメソッドの引数(timeInSeconds)に対してゼロ以下の値を指定した場合は、デフォルト値(86400)が使用されます。

SavePointMangerは、セーブポイントの管理に役立つメソッドを定義します。たとえば、セーブポイントの取得および削除を実行できるgetSavePointおよびremoveSavePointメソッドを定義します。removeSavePointメソッドは、セーブポイントが期限切れになると自動的にコールされるものではありません。ORADFCSAVPTデータベース表からセーブポイント(期限切れのセーブポイントを含む)を削除するには、明示的にremoveSavePointメソッドをコールする必要があります。代替方法として、Oracle ADFには期限切れのセーブポイントを削除するSQLスクリプト(adfc_cleanup_save_point_table.sql)が用意されています。詳細は、「セーブポイントのデータベース表に関する必知事項」を参照してください。

セーブポイントを作成するためのメソッドをコールするのと同時に、setSavePointTimeToLiveメソッドをコールすることを検討してください。SavePointMangerの詳細は、Oracle ADF ControllerのJava APIリファレンスを参照してください。

27.8 アプリケーションでのアクティブなルート・ビュー・ポート数の最小化

アプリケーションのadf-config.xmlファイルで「最大ルート・ビュー・ポート」プロパティ(<max-root-view-ports>)の値を指定することで、アプリケーションのアクティブなルート・ビュー・ポート数を最小化できます。これにより、アプリケーションのメモリー・フットプリントが制限され、サービス拒否攻撃を防ぐのに役立つことがあります。

デフォルト値は20です。最低許容値は5です。偶発的な誤使用を防ぐために、アプリケーションは5未満の値を無視し、値5を適用します。

この機能を無効にし、アプリケーションで無制限のアクティブ・ルート・ビュー・ポート数を許容するには、-1の値を指定します。

27.8.1 アクティブ・ルート・ビュー・ポート数を最小化する方法

アプリケーションのadf-config.xmlファイルで<max-root-view-ports>プロパティの値を指定します。

始める前に:

構成可能な<max-root-view-ports>オプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローでのセーブポイントの使用」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

アクティブ・ルート・ビュー・ポート数を最小化する手順:

1. Fusion WebアプリケーションをJDeveloperで開き、「アプリケーション」ウィンドウの「アプリケーション・リソース」ペインを開きます。

2. 「ディスクリプタ」および「ADF META-INF」を展開します。

3. adf-config.xmlを右クリックし、ポップアップ・メニューから「開く」を選択します。

4. 概要エディタの「コントローラ」ページで、「最大ルート・ビュー・ポート」プロパティの値を書き込んで、アプリケーションのアクティブ・ルート・ビュー・ポートの最大数を指定します。

5. adf-config.xmlファイルを保存します。

27.8.2 アクティブ・ルート・ビュー・ポート数を最小化した場合の処理

アプリケーションのアクティブ・ルート・ビュー・ポートの最大数を指定する次の例のようなエントリが、adf-config.xmlファイル内に生成されます。

<?xml version="1.0" encoding="UTF-8" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:config="http://xmlns.oracle.com/bc4j/configuration"
xmlns:adf="http://xmlns.oracle.com/adf/config/properties">
...
<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
<max-root-view-ports>
19
</max-root-view-ports>
</adf-controller-config>
</adf-config>

実行時に、指定したルート・ビュー・ポート制限に達すると、新しいルート・ビュー・ポートの作成リクエストは、まず最も長い間使用されていないルート・ビュー・ポートを自動的に失効させます。その後、失効したルート・ビュー・ポートを使用しようとすると、ViewExpiredExceptionが発生します。

27.9 バインド・タスク・フローでのトレイン・コンポーネントの使用

タスク・フローをトレインとして作成できます。これにより、マルチステップ・プロセスを使用してエンド・ユーザーを移動するユーザー・インタフェースを作成できます。ADF Facesには、エンド・ユーザーに表示されるタスク・フロー・ビュー・アクティビティのトレイン機能をレンダリングするユーザー・インタフェース・コンポーネントが実装されています。これらのコンポーネントは、trainコンポーネントおよびtrainButtonBarコンポーネントです。図27-8に、Summit ADFタスク・フロー・サンプル・アプリケーションからのedit-customer-task-flow-definition.xmlタスク・フローの実行時ビューを示します。このタスク・フローは、trainおよびtrainButtonBarコンポーネントを使用して、顧客のデータを編集するタスクからエンド・ユーザーを移動します。

図27-8 タスク・フローでのトレイン・コンポーネントおよびトレイン・ボタン・バー・コンポーネント

図27-8のtrainコンポーネントでは、3つのトレイン・ストップがレンダリングされます。各ストップは、edit-customer-task-flow-definition.xmlタスク・フローのページ・フラグメントに対応しており、ここではエンド・ユーザーが情報の入力と確認を行い、顧客データを編集するタスクを完了できます。図27-8は、エンド・ユーザーが郵便用アドレスを入力するアドレス・トレイン・ストップを示しています。他のストップは次のようになります。

- 一般情報

- コメント

図27-8で示したトレイン・ボタン・バー・コンポーネントはオプションで、トレイン・ストップ間を移動する追加のコントロールが実装されています。このコンポーネントをトレイン・コンポーネントと併用すると、トレイン・ストップ間を複数の方法で移動できます。

JDeveloperによって提供されるダイアログ上で「トレインの作成」チェック・ボックスを選択し、バインド・タスク・フローまたはタスク・フロー・テンプレートを作成した場合は、バインド・タスク・フローおよびタスク・フロー・テンプレートではこれらのトレイン・コンポーネントを利用できます。バインド・タスク・フローまたはタスク・フロー・テンプレートでは1つのトレインのみをレンダリングできます。複数のトレインの使用が必要な場合は、各トレインで別にバインド・タスク・フローまたはタスク・フロー・テンプレートを作成します。

図27-9は、図27-8でトレイン・ストップとして実行時にレンダリングするビュー・アクティビティを表示可能なタスク・フローの設計時ビューからの抜粋を示しています。

ビュー・アクティビティを接続する点線は、ビュー・アクティビティがトレイン・ストップとしてレンダリングされる場合、エンド・ユーザーがビュー間を移動する順序を示します。

図27-9 トレインとしてレンダリングするように構成されるタスク・フロー

図27-10で示したように、トレイン・ストップとして構成されたビュー・アクティビティまたはタスク・フロー・コール・アクティビティを右クリックすると、JDeveloperではアクティビティの場所を変更するコンテキスト・メニューのオプションが表示されます。

図27-10 トレイン・ストップを編集するコンテキスト・メニュー

複数のアクティビティを1つのトレイン・ストップとしてグループ化するか、または子トレイン・ストップをコールする場合は、タスク・フロー・コール・アクティビティをトレイン・ストップとして構成します。たとえば、ルーターやメソッド・コール・アクティビティなどの他のタスク・フロー・アクティビティを、対応するビュー・アクティビティとともにトレイン・ストップの一部とみなす場合があります。初期化のため、メソッド・コール・アクティビティをビュー・アクティビティの前に配置する場合もあります。このようにグループ化することで、トレイン・ストップにアクセスするたびに一連のアクティビティがセットとして実行されるように指定できます。詳細は、「トレイン・ストップ間で実行するタスク・フロー・アクティビティのグループ化」を参照してください。

ルーター・アクティビティや制御フロー・ケースによるブランチ化は、トレインを含むタスク・フロー・ダイアグラムでも、そのトレインからコールされる子バインド・タスク・フローでもサポートされます。

27.9.1 タスク・フローのトレインとしての作成

「バインド・タスク・フローでのトレイン・コンポーネントの使用」で説明されているタイプの機能を実装する場合は、その前に、トレイン・コンポーネントを使用するようにバインド・タスク・フローを構成する必要があります。トレイン・コンポーネントを使用するようにバインド・タスク・フローを構成するには、次のリストに示すメソッドのいずれかを使用します。

- 新しいバインド・タスク・フローまたはタスク・フロー・テンプレートを作成する場合に表示されるダイアログで、「トレインの作成」チェックボックスを選択します。
詳細は、「タスク・フローの作成」または「タスク・フロー・テンプレートの作成」を参照してください。

- ダイアグラムで既存のバインド・タスク・フローを右クリックして、「トレイン」→「トレインの作成」の順に選択します。

- 概要エディタで既存のバインド・タスク・フローを開き、「動作」ナビゲーション・タブをクリックして、「トレイン」チェック・ボックスを選択します。

バインド・タスク・フローを構成し、トレイン・コンポーネントを使用している場合は、トレインでレンダリングが必要なタスク・フロー・アクティビティをバインド・タスク・フローのダイアグラムにドラッグ・アンド・ドロップします。

27.9.1.1 バインド・タスク・フローでのトレインの作成方法

トレインでレンダリングが必要なタスク・フロー・アクティビティをバインド・タスク・フローのダイアグラムにドラッグ・アンド・ドロップします。

始める前に:

トレインで構成可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、「タスク・フローのトレインとしての作成」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

- 「バインド・タスク・フローでのトレイン・コンポーネントの使用」の説明に従って、バインド・タスク・フローでトレイン・コンポーネントを使用するように構成します。

バインド・タスク・フローでトレインを作成するには:

1. 「アプリケーション」ウィンドウで、トレイン・ストップをレンダリングするバインド・タスク・フローまたはタスク・フロー・テンプレートをダブルクリックします。

2. トレインで追加が必要なビュー・アクティビティまたはJSFページをそれぞれバインド・タスク・フローのダイアグラムにドラッグします。

- JSFページをドラッグすると、ビュー・アクティビティがダイアグラムに自動的に追加されます。「アプリケーション」ウィンドウから、含めるJSFページをバインド・タスク・フローのダイアグラムにドラッグします。

- ダイアグラムにビュー・アクティビティをドラッグする場合は、そのアクティビティをダブルクリックすると、新しいJSFページを作成するダイアグラムを起動できます。「コンポーネント」ウィンドウの「ADFタスク・フロー」ページでビュー・アクティビティをドラッグするには、「コンポーネント」パネルから、「アクティビティ」グループにある「ビュー」をダイアグラムにドラッグ・アンド・ドロップします。

後で、トレイン・ストップの順序をレンダリングできます。詳細は、「トレインでのトレイン・ストップの順次動作の無効化」を参照してください。

3. バインド・タスク・フローのダイアグラムで、トレイン・ストップとして定義が必要な各ビュー・アクティビティをダブルクリックします。

ビュー・アクティビティがJSFページとまだ関連付けられていない場合は、新規のJSFページを作成するダイアログが表示されます。このダイアログを使用して新しいJSFページを作成します。

ビュー・アクティビティがJSFページとすでに関連付けられている場合は、JSFページが開きます。

4. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「一般コントロール」パネルから、「位置」グループにある「トレイン」コンポーネントおよび必要に応じて「トレイン・ボタン・バー」コンポーネントをドラッグして、JSFページにドロップします。

タスク・フロー・ビュー・アクティビティで表示が必要な「トレイン」コンポーネントおよび「トレイン・ボタン・バー」コンポーネントはそれぞれ手動で追加する必要があります。ページ・テンプレートの使用を検討します。詳細は、「ページ・テンプレートの使用方法」を参照してください。

27.9.1.2 トレインとしてのタスク・フローの作成時の処理

「タスク・フローのトレインとしての作成」で説明したメソッドのいずれかを使用して、JDeveloperでは、トレインとして有効化するバインド・タスク・フローまたはタスク・フロー・テンプレートのソース・ファイルに<train/>要素を記述します。

JDeveloperでは、trainコンポーネントおよびtrainButtonBarコンポーネントを追加するJSFページにエントリを記述します。次の例は、Summit ADFタスク・フロー・サンプル・アプリケーションのGeneralInfo.jsffページ・フラグメントにあるコード・スニペットを示しています。どちらのタイプのトレイン・コンポーネントもトレイン・モデル・オブジェクト(trainModel)のインスタンスにバインドされます。

<af:train value="#{controllerContext.currentViewPort.taskFlowContext.trainModel}"
id="t1"/>
...
<af:trainButtonBar value="#{controllerContext.currentViewPort.taskFlowContext.trainModel}"
id="tbb1"/>

図27-9に示すとおり、バインド・タスク・フローに追加し、トレイン・ストップとして定義する各ビュー・アクティビティ間には点線が表示されます。点線は、トレイン・ストップをバインド・タスク・フローが移動する順序を示します。JDeveloperでは、バインド・タスク・フローにビュー・アクティビティを追加する順番にシーケンスを定義します。このシーケンスは変更できます。詳細は、「トレインでのトレイン・ストップの順次動作の無効化」を参照してください。トレイン・ストップを省略することもできます。詳細は、「トレイン・ストップを省略するトレインの構成」を参照してください。

27.9.2 トレイン・ストップの子バインド・タスク・フローの起動

「トレイン・ストップ間で実行するタスク・フロー・アクティビティのグループ化」で説明する、タスク・フロー・アクティビティを1つのトレイン・ストップにグループ化する方法の代替としては、現在のバインド・タスク・フローから起動するトレインとして別のバインド・タスク・フローを作成する方法があります。このバインド・タスク・フローは、子バインド・タスク・フローと呼ばれます。親バインド・タスク・フローをタスク・フロー・コール・アクティビティを使用して起動するように構成します。この機能を実装するには、次を実行します。

- 子バインド・タスク・フローをトレインとして作成します。

- 親バインド・タスク・フロー上のトレイン・ストップから子バインド・タスク・フローに渡って存在する、エンド・ユーザーのアクセスが必要なタスク・フロー・アクティビティを追加します。

- 子バインド・タスク・フローを起動する親バインド・タスク・フローのトレイン・ストップとしてアクティビティをコールするタスク・フローを指定します。

- 子バインド・タスク・フローによる実行の終了時に、親バインド・タスク・フローに制御を戻す子バインド・タスク・フローにタスク・フロー・リターン・アクティビティを追加します。

エンド・ユーザーが初めてトレイン・ストップを訪問するのか、または後で戻るのかとは無関係に、子バインド・タスク・フローのタスク・フロー・アクティビティはまとめて実行されます。子バインド・タスク・フローの非ビュー・タスク・フロー・アクティビティは通常、子バインド・タスク・フローのフロー制御にあるビュー・アクティビティより優先されます。別のバインド・タスク・フローの子であるバインド・タスク・フローから子バインド・タスク・フローを起動できます。

27.9.2.1 トレイン・ストップから子バインド・タスク・フローを起動する方法

トレインとして作成したバインド・タスク・フローにタスク・フロー・アクティビティを追加し、そのアクティビティを起動する親バインド・タスク・フロー上にタスク・フロー・コール・アクティビティを構成します。

始める前に:

トレインから起動する子バインド・タスク・フローに構成可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、「トレイン・ストップの子バインド・タスク・フローの起動」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが役に立つ場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

- バインド・タスク・フローをトレインとして作成します。これは、親タスク・フローのタスク・フロー・コール・アクティビティから起動される子バインド・タスク・フローです。それに必要なタスク・フロー・アクティビティを追加します。詳細は、「タスク・フローのトレインとしての作成」を参照してください。

トレイン・ストップから子バインド・タスク・フローを起動するには:

1. 「アプリケーション」ウィンドウで、トレインとして構成された子バインド・タスク・フローであるバインド・タスク・フローをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルから、「アクティビティ」グループにある「タスク・フロー・リターン」をダイアグラムにドラッグ・アンド・ドロップします。

3. 子バインド・タスク・フローによる実行の終了時に、タスク・フロー・リターン・アクティビティが親タスク・フローに制御を戻すように構成します。

詳細は、「タスク・フロー・リターン・アクティビティの使用」を参照してください。

4. 「アプリケーション」ウィンドウで、子バインド・タスク・フローを起動する親バウンド・タスク・フローをダブルクリックします。

詳細は、「タスク・フローのトレインとしての作成」を参照してください。

5. 「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「ADFタスク・フロー」パネルから、「アクティビティ」グループにある「タスク・フロー・コール」をダイアグラムにドラッグ・アンド・ドロップします。

6. 手順1から3で構成した子バインド・タスク・フローを起動するようにタスク・フロー・コール・アクティビティを構成します。

詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。

27.9.3 トレイン・ストップ間で実行するタスク・フロー・アクティビティのグループ化

単一のトレイン・ストップを形成するタスク・フロー・アクティビティをまとめてグループ化できます。たとえば、実行時に「アドレス」としてレンダリングされるトレイン・ストップでは、次のタスク・フロー・アクティビティがまとめてグループ化されます。

- defineAddressビュー・アクティビティ

- createAddressメソッド・コール・アクティビティ

- addressDetailsビュー・アクティビティ

実行中の「アドレス」トレイン・ストップにユーザーがアクセスするたびに、タスク・フローでは、前述でリストしたタスク・フロー・アクティビティにアクセスできます。defineAddressesビュー・アクティビティでは、トレイン・ストップおよび関連付けられたdefineAddresses.jsffページ・フラグメントが動的にレンダリングされます。次に、defineAddresses.jsffページ・フラグメントでは、createAddressメソッド・コール・アクティビティを起動するボタンが公開されます。メソッド・コール・アクティビティでは、「アドレス」ページのユーザー入力が検証され、addressDetailsビュー・アクティビティに制御を(任意に)渡す結果が定義されます。addressDetailsビュー・アクティビティでは、実行時にエンド・ユーザーが追加アドレスの入力を選択できる「アドレス」情報ページがレンダリングされます。

図27-11 1つのトレイン・ストップにグループ化されるタスク・フロー・アクティビティ

トレインでは、最初の非ビュー・アクティビティから次のビュー・アクティビティに渡るすべてのタスク・フロー・アクティビティがトレインの一部であるとみなされます。ビューおよびタスク・フロー・コール・アクティビティを除いた、トレイン・ストップのすべてのタスク・フロー・アクティビティが、トレイン・ストップとして定義したビューまたはタスク・フロー・コール・アクティビティの後に続くことを確認します。

また、トレイン・ストップ間で実行するタスク・フロー・アクティビティをグループ化できます。図27-12は、制御フローがpage2に渡される前に、メソッド・コール・アクティビティ(doSomethingBeforePage2)の起動が可能な構成を示しています。ワイルドカード制御フロー・ルールのcallMethodBeforePage2では、メソッド・コール・アクティビティのdoSomethingBeforePage2に制御が渡されます。このメソッド・コール・アクティビティでは、トレインの次のトレイン・ストップ(page2)に制御を渡す固定結果(continue)が定義されます。

図27-12 トレイン・ストップ間のメソッド・コール・アクティビティ

27.9.4 トレインでのトレイン・ストップの順次動作の無効化

デフォルトでは、トレイン・ストップは順次ストップです。つまり、エンド・ユーザーがトレイン・ストップを選択できるのは、トレインで前のトレイン・ストップにアクセスした場合のみです。図27-13は、登録タスク・フローがレンダリングするトレイン・コンポーネントを示しています。エンド・ユーザーは、最初に「アドレス」トレイン・ストップにアクセスするまで、「支払」オプションおよび「確認」トレイン・ストップにアクセスできません。このトレインのすべてのトレイン・ストップは順次ストップです。

図27-13 タスク・フローの順次トレイン・ストップ

トレイン・ストップをレンダリングするビュー・アクティビティを構成して非順次ストップにすることで、このデフォルトの動作を変更(トレイン・ストップを非順次ストップに)できます。

27.9.4.1 トレインの順次動作の無効化方法

タスク・フロー・ビュー・アクティビティで、実行時に値がfalseになるsequentialプロパティの値を記述します。

始める前に:

トレインで構成可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、「バインド・タスク・フローでのトレイン・コンポーネントの使用」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

トレイン・ストップの順次動作を無効化するには:

1. 「アプリケーション」ウィンドウで、トレイン・ストップをレンダリングするビュー・アクティビティを含むバインド・タスク・フローをダブルクリックします。

2. バインド・タスク・フローのダイアグラムで、ビュー・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「トレイン・ストップ」を開いて、「順次」フィールドの値を記述し、トレイン・ストップが順次または非順次のいずれであるかを決定します。

falseを記述するか、または実行時にfalseに解決されるEL式を記述して、トレイン・ストップを非順次にします。たとえば、次のようなEL式を記述します。

#{myTrainModel.isSequential}

27.9.4.2 トレイン・ストップの順次動作の無効化時の処理

次の例に示すとおり、JDeveloperでは、バインド・タスク・フローのソース・ファイルに対してエントリを記述します。

<view id="paymentOptionDetails">
<page>/account/paymentOptionDetails.jsff</page>
<train-stop id="__1">
<sequential>#{myTrainModel.isSequential}</sequential>
</train-stop>
</view>

図27-14は、sequentialに指定した値がfalseに評価されるときに対応するランタイム・ビューを示しています。ここで、エンド・ユーザーは、支払オプション・トレイン・ストップをクリックして、支払オプションに直接移動できます。

図27-14 非順次トレイン・ストップを持つトレイン

27.9.5 トレイン・ストップのラベルの変更

トレイン・ストップを構成して定義したラベルを表示できます。定義したラベルは、EL式を使用して参照可能な静的値またはリソース・バンドル内の値などになることがあります。ローカライズされた文字列の使用の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ページの国際化およびローカライズ」を参照してください。

27.9.5.1 トレイン・ストップのラベルの変更方法

ビュー・アクティビティの「表示名」プロパティの値を構成することで、トレイン・ストップのラベルを変更できます。

始める前に:

トレインで構成可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、「バインド・タスク・フローでのトレイン・コンポーネントの使用」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

トレイン・ストップのラベルを変更するには:

1. 「アプリケーション」ウィンドウで、トレイン・ストップをレンダリングするビュー・アクティビティを含むバインド・タスク・フローをダブルクリックします。

2. バインド・タスク・フローのダイアグラムで、ビュー・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「説明」セクションを開いて、「表示名」の値を記述し、トレイン・ストップが実行時にレンダリングするラベルを指定します。

リテラル値を記述するか、またはリソース・バンドルの値を参照するEL式を記述して、実行中にレンダリングします。

27.9.5.2 トレイン・ストップのラベル変更時の処理

Summit ADFタスク・フロー・サンプル・アプリケーションのedit-customer-task-flow-definition.xmlバインド・タスク・フローから、次の例で示すように、JDeveloperでは、バインド・タスク・フローのソース・ファイルに対してエントリを記述します。

<view id="GeneralInfo"> <page>/customers/GeneralInfo.jsff</page>
<train-stop>
<display-name>General Information</display-name>
<sequential>false</sequential>
</train-stop></view>

実行時に、Fusion Webアプリケーションでは、トレイン・ストップのラベルとしてdisplay-nameプロパティに指定した値が表示されます。

27.9.6 トレイン・ストップを省略するトレインの構成

トレインを構成して、個々のトレイン・ストップを省略できるようにします。実行時に、Fusion Webアプリケーションでは、省略するように構成したトレイン・ストップが無効化されます。エンド・ユーザーは、トレイン内で次のトレイン・ストップにのみ移動できます。

最初のトレイン・ストップ以外のトレイン・ストップでトレインを実行する必要がある場合は、この機能を実装します。たとえば、トレイン・ストップ3を最初に実行する場合は、トレイン・ストップの1と2を省略するように構成します。「バインド・タスク・フローのデフォルト・アクティビティに関する必知事項」の説明のとおり、デフォルト・アクティビティとしてトレイン・ストップと関連付けられたビュー・アクティビティを定義するよりも、このアプローチを使用します。

27.9.6.1 トレイン・ストップを省略するトレインの構成方法

実行時に値がtrueに評価される、ビュー・アクティビティのskipプロパティの値を記述します。

始める前に:

トレインで構成可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、「バインド・タスク・フローでのトレイン・コンポーネントの使用」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

トレイン・ストップを省略するトレインを構成するには:

1. 「アプリケーション」ウィンドウで、トレイン・ストップをレンダリングするビュー・アクティビティを含むバインド・タスク・フローをダブルクリックします。

2. バインド・タスク・フローのダイアグラムで、ビュー・アクティビティを選択します。

3. 「プロパティ」ウィンドウで、「トレイン・ストップ」を開いて、「スキップ」フィールドの値を記述し、トレインがトレイン・ストップに移動するか、またはトレイン・ストップを省略するかのいずれかを決定します。

実行時にtrueを記述するか、またはtrueに解決されるEL式を記述して、トレインにトレイン・ストップを省略させます。たとえば、次のようなEL式を記述します。

#{myTrainModel.shouldSkip}

27.9.6.2 トレイン・ストップを省略するトレインの構成時の処理

次の例に示すとおり、JDeveloperでは、バインド・タスク・フローのソース・ファイルに対してエントリを記述します。

<view id="defineAddresses">
<display-name>Address</display-name>
<page>/account/defineAddresses.jsff</page>
<train-stop>
<display-name>Address</display-name>
<skip>#{myTrainModel.shouldSkip}</skip>
</train-stop>
</view>

図27-15は、skipに指定した値がtrueに評価されるときに対応する実行時ビューを示しています。トレインが順次ストップであれば、エンド・ユーザーは、トレイン内の次のトレイン・ストップ(「Payment」オプション)に移動する必要があります。

図27-15 トレイン・ストップの省略が構成されたトレイン

27.10 タスク・フロー・テンプレートの作成

新しいバインド・タスク・フローの作成時に、タスク・フロー・テンプレートをユーザー自身または他のアプリケーションの開発者のために作成し、出発点として使用できます。バインドなしタスク・フローは、タスク・フロー・テンプレートを使用して作成できません。タスク・フロー・テンプレートから作成したバインド・タスク・フローには、タスク・フロー・テンプレートと同じタスク・フロー・アクティビティ、制御フロー、入力パラメータおよびマネージドBeanがセットで定義されています。たとえば、図27-16に、タスク・フロー・テンプレートから作成されたバインド・タスク・フローを示します。view1およびview2ビュー・アクティビティ、さらにこのバインド・タスク・フローのgoToView2制御フローがタスク・フロー・テンプレートで定義されている一方で、startおよびview3ビュー・アクティビティがバインド・タスク・フロー自体で定義されています。

図27-16 タスク・フロー・テンプレートで定義されるアクティビティを表示するバインド・タスク・フロー

タスク・フロー・テンプレートのユース・ケースの例では、バインド・タスク・フローの例外ハンドラとしてタスク・フロー・アクティビティを定義しています。タスク・フロー・アクティビティは、例外の発生時にエンド・ユーザーに表示するページに関連付けられたビュー・アクティビティになる場合があります。このビュー・アクティビティは、各バインド・タスク・フローではなく、タスク・フロー・テンプレートで定義し、新しいバインド・タスク・フローの作成時にはそのタスク・フロー・テンプレートを選択します。例外処理の詳細は、「タスク・フローでの例外の処理」を参照してください。

新しいタスク・フロー・テンプレートを、既存のタスク・フロー・テンプレートに基づいて作成できます。また、既存のバインド・タスク・フローをリファクタして新しいタスク・フロー・テンプレートを作成することも可能です。詳細は、「バインド・タスク・フローの変換方法」を参照してください。

タスク・フロー・テンプレートに基づいてバインド・タスク・フローまたは別のタスク・フロー・テンプレートを作成する場合は、タスク・フロー・テンプレートに対して行う後続の変更がバインド・タスク・フローおよびテンプレートに自動的に伝播されるように指定できます。これを行うには、使用するダイアログで「テンプレートの変更時にタスク・フローを更新」チェック・ボックスを選択し、バインド・タスク・フローまたはテンプレートを作成します。タスク・フロー・テンプレートに対して行う後続の変更(新しいビュー・アクティビティの追加など)はバインド・タスク・フローに伝播されます。子バインド・タスク・フローまたはタスク・フロー・テンプレートの親タスク・フロー・テンプレートは、子の開発中のどの段階でも変更、更新、関連付けの解除が可能です。

子側の作成時に「テンプレートの変更時にタスク・フローを更新」チェック・ボックスを選択した場合は、実行時に、子バインド・タスク・フローまたは子タスク・フロー・テンプレートの内容が親タスク・フロー・テンプレートの内容と結合されます。子タスク・フローまたは子タスク・フロー・テンプレートの作成時に「テンプレートの変更時にタスク・フローを更新」チェック・ボックスを選択した場合でも、競合の発生時には、子タスク・フローおよび子タスク・フロー・テンプレートによって親タスク・フロー・テンプレートがオーバーライドされます。たとえば、「バインド・タスク・フローでのトレイン・コンポーネントの使用」の説明に従って、トレインとして使用する親タスク・フロー・テンプレートを作成し、このタスク・フロー・テンプレートに基づいてバインド・タスク・フローを作成します。その後、親タスク・フロー・テンプレート上のトレイン・コンポーネントを無効にします。親タスク・フロー・テンプレートをオーバーライドした子タスク・フローがトレインとして引き続き実行されます。

表27-3は、親タスク・フロー・テンプレートと子タスク・フローおよび子タスク・フロー・テンプレートの間の競合をADFコントローラによって解決する方法の詳細を説明しています。

表27-3 親テンプレートと子タスク・フロー間の競合の解決

バインド・タスク・フローのメタデータ

組合せアルゴリズム

デフォルト・アクティビティ

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

トランザクション

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートを(すべての下位要素を含む)メタデータのブロック全体としてオーバーライドします。

タスク・フローの再開

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートを(すべての下位要素を含む)メタデータのブロック全体としてオーバーライドします。

制御フロー・ルール

組合せアルゴリズムは、制御フロー・ルールのレベルではなく、制御フロー・ケースのレベルで発生します。制御フロー・ケースは次のカテゴリに分類されます。

- アクションおよび指定された結果からの場合

- 指定されたアクションからのみの場合

- 指定された結果からのみの場合

- アクションおよび指定された結果からではない場合

これらの各カテゴリは付加的にマージされます。子バインド・タスク・フローまたはテンプレートが親タスク・フロー・テンプレートをオーバーライドして、4つの各カテゴリ内で完全に一致するようにします。

入力パラメータの定義

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、入力パラメータ定義の名前が同一になるようにします。

戻り値の定義

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、戻り値の定義の名前が同一になるようにします。

アクティビティ

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、アクティビティのIDが同一になるようにします。

マネージドBean

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、マネージドBeanの名前が同一になるようにします。

イニシャライザ

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

ファイナライザ

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

クリティカル

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

ページ・フラグメントの使用

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

例外ハンドラ

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

セキュリティ - 権限

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

権限のマップは付加的なものです。子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、権限マップ操作が同一になるようにします。

セキュリティ - 転送保証

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

トレイン

子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

設計時および実行時の両方の検証で、結果として作成される親/子の拡張階層に同一のタスク・フロー・テンプレートのサイクルが含まれないことを検証してください。

27.10.1 タスク・フロー・テンプレートの作成方法

「新規ギャラリ」から「ADFタスク・フロー・テンプレート」を選択して、タスク・フロー・テンプレートを作成します。

始める前に:

構成可能なタスク・フロー・テンプレートのオプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フロー・テンプレートの作成」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

タスク・フロー・テンプレートを作成するには:

1. 「アプリケーション」ウィンドウで、タスク・フロー・テンプレートを作成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「Web層」を開いて、「JSF/Facelets」→「ADFタスク・フロー・テンプレート」を選択し、「OK」をクリックします。

3. 「ADFタスク・フロー・テンプレートの作成」ダイアログで、適切なオプションを選択します。

- ファイル名: JDeveloperにより提示されるデフォルト値を受け入れるか、新しいファイル名を入力します。この値は、作成するタスク・フロー・テンプレートのXMLソース・ファイルに名前を付けるために使用されます。ソース・ファイルには、タスク・フロー・テンプレートにあるアクティビティおよび制御フロー・ルールが含まれます。XMLソース・ファイルのデフォルト名はtask-flow-template.xmlです。

- ページ・フラグメントを使用して作成: テンプレートに基づくバインド・タスク・フローをADFリージョンとして使用する場合は、このチェック・ボックスを選択した(デフォルト)のままにします。タスク・フロー・テンプレートに基づくタスク・フローに、JSFページ・フラグメントではなくJSFページを追加する場合は、このチェック・ボックスを選択解除します。

4. 「OK」をクリックします。

27.10.2 タスク・フロー・テンプレートの作成時の処理

次の例に示すように、JDeveloperで新しいタスク・フロー・テンプレートを作成するたびに、XMLファイルが作成されます。「ADFタスク・フロー・テンプレートの作成」ダイアログの「ディレクトリ」フィールドで指定した場所の「アプリケーション」ウィンドウでXMLファイルを検索できます(.../WEB-INFなど)。

タスク・フロー・テンプレートのXMLソース・ファイルの内容は、バインド・タスク・フローの内容に類似しています。<task-flow-template>タグが含まれているという点のみが異なります。

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2" id="__1">
<task-flow-template id="task-flow-template">
<default-activity>view1</default-activity>
<view id="view1">view1.jsff</view>
</task-flow-template>
</adfc-config>

27.10.3 タスク・フロー・テンプレートに関する必知事項

バインディングを含むタスク・フロー・テンプレートを使用する場合、そのタスク・フロー・テンプレートを基盤とするタスク・フローのコンポーネントIDを変更する必要があります。これにより、IDが一意であることを確認します。テンプレートから生成されるタスク・フローでは、テンプレートと同じIDが継承されます。そのため、実行時に例外が発生します。詳細は、「ADFページ・テンプレートでのADFデータ・バインディングの使用方法」を参照してください。

Fusion WebアプリケーションにADFセキュリティが構成されている場合は、タスク・フロー・テンプレートおよびそのテンプレートを使用するタスク・フローの両方に権限を付与する必要があります。通常、タスク・フロー・テンプレート上の権限はアプリケーション・ロールのanonymous-roleに付与されるため、実際に重要な権限はタスク・フロー上に付与されますが、必ずそのようになるとは限りません。ADFセキュリティの詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

27.11 タスク・フローを使用したページ階層の作成

ページ階層の作成は、エンド・ユーザーがアプリケーション内をより簡単に移動できるようにFusion WebアプリケーションのJSFページを構成する方法として便利です。エンド・ユーザーは、リンクのパスに移動してページの情報にアクセスします。図27-17に、サンプルのページ階層を示します。

図27-17 ページ階層

エンド・ユーザーがこの階層内を移動するには、各ページのリンクをクリックして、階層の別のレベルまでドリルダウンまたはドリルアップします。たとえば、Fusion Appのホームページの「Human Resources」をクリックすると、図27-17の「Human Resources」ページの階層が表示されます。「Benefits」タブのリンクをクリックすると、図27-18のページ階層が表示されます。

図27-18 「Benefits」ページ

ユーザーがBenefitsページのリンクをクリックすると、Medical、Dental、Visionのような他のページを表示できます。各ページのブレッドクラムに、階層における現在のページの位置が示されます。ユーザーがブレッドクラム内の各ノードをクリックすると、階層の他のページに移動できます。太字で表示されるタブのラベルが、ブレッドクラムに示されている現在のページのパスと一致します。

生成するすべてのページ階層には、バインド・タスク・フローのビュー・アクティビティによって参照されるページも含めることができます。図27-19は、バインド・タスク・フローによって参照されるビュー・アクティビティをレンダリングするページ階層の実行時ビューを示しています。

図27-19 バインド・タスク・フローを含む実行時のメニュー階層

ADF ControllerをXMLMenuModel実装とともに使用して、前述のページ階層を作成できます。これを行うと、JDeveloperによって次のものが生成されます。

- エンド・ユーザーがメニュー項目を選択すると表示されるビューまたはページを決定する制御フロー・メタデータ

- XMLMenuModelメタデータ・ファイル

- デフォルトのナビゲーション・ウィジェット(「前へ」ボタン、「次へ」ボタンなど)

- ブレッドクラム

- マネージドBeanの構成

ADF Controllerを使用しない場合は、XMLMenuModel実装を使用してページ階層を作成できます。ページ階層を構築するこのメソッドの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のメニュー・モデルを使用したページ階層の作成に関する項を参照してください。

27.11.1 ページ階層の作成方法

バインドなしタスク・フローを作成するか、既存のものを開きます。バインドなしタスク・フローに、ビュー・アクティビティまたはバインド・タスク・フローを追加します。バインドなしタスク・フローに追加したそれぞれのビュー・アクティビティまたはバインド・タスク・フローには、指定されたページ階層に表示されるページへの参照が含まれます。JDeveloperの「ADFメニュー・モデルの作成」ダイアログを使用して、XMLMenuModelメタデータ・ファイルを生成します。生成したXMLMenuModelメタデータ・ファイルの項目ノードを構成し、目的のページ階層を作成します。サブメニューを親メニューに接続して階層を完成させます。

図27-20は、ビュー・アクティビティで構成されるページ階層の例を示しています。

- 最上位のメニュー(Home Page)は、ルートの親ページです。これには、Human Resourcesサブメニューへリンクする1つのタブが含まれています。
JDeveloperでは、Home Pageページは項目ノードとして、またHuman Resourcesページは共有ノードとして表示されます。

- Human Resourcesには4つのタブがあり、それぞれがPayroll、Time、LaborおよびBenefitsの各ページへリンクします。
このメニューの中で、Human Resourcesは、子項目ノード(Payroll、Time、Labor)およびBenefitsサブメニューを参照する共有ノード(Benefits)を参照する、グループ・ノードです。

- Benefitsは、子項目ノード(Medical、DentalおよびVision)のページを参照するグループ・ノードです。

図27-20 メニュー階層

注意:

1つのメニュー・モデル内にメニュー階層全体を作成することも可能です。ただし、メニュー階層を複数のサブメニューに分割した方が、管理は容易になります。また、メニュー階層をより小さなサブメニュー・モデルに分割することで、各開発組織が個別にその担当メニューを開発できるようになります。その後、各個別メニューを共有ノードで組み合せ、完全なメニュー階層を作成できます。

図27-21は、図27-19に示したページ階層をレンダリングするバインドなしタスク・フローおよびバインド・タスク・フローに対応する、JDeveloperの設計時ビューを示しています。バインドなしタスク・フロー(adfc-config.xml)には、図27-21の下部に表示されているバインド・タスク・フロー(task-flow-definition.xml)を起動する、ビュー・アクティビティ(view1)およびタスク・フロー・コール・アクティビティ(task-flow-definition)が含まれています。

図27-21 バインド・タスク・フローを含む設計時のメニュー階層

27.11.1.1 XMLMenuModelメタデータ・ファイルの作成方法

最終的なページ階層に表示するメニュー(バインドなしタスク・フロー)およびノード(ページ)を定義したら、JDeveloperの「ADFメニュー・モデルの作成」ダイアログを使用して、XMLMenuModelメタデータ・ファイルを生成します。

始める前に:

構成可能なページ階層のオプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローを使用したページ階層の作成」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

次のタスクを完了する必要があります。

1. 最終的なページ階層の各メニューに対して、バインドなしタスク・フローを作成します。
たとえば、図27-20のページ階層を実現するには、2つのバインドなしタスク・フロー(Human ResourcesメニューおよびBenefitsメニュー)を作成します。

バインドなしタスク・フローの作成の詳細は、「タスク・フローの作成方法」を参照してください。

ヒント:

作成したバインドなしタスク・フローのファイル名に接頭辞adfc-を付けて、そのファイルがバインド・タスク・フローではなくバインドなしタスク・フローのソースであることを簡単に識別できるようにします。

2. 各バインドなしタスク・フローに、ページを参照するビュー・アクティビティを追加します。ビュー・アクティビティによって参照されるページは、メニュー内のメニュー・ノードに対応します。
たとえば、Benefitsメニューには1つのグループ・ノード(benefits)および3つの項目ノード(medical、dentalおよびvision)が含まれているため、Benefitsメニューのバインドなしタスク・フローには、図27-22のように4つのビュー・アクティビティを追加する必要があります。

図27-22 タスク・フローのビュー・アクティビティ

共有ノードを使用して他のメニューが含まれているメニューについては、ビュー・アクティビティを追加しないでください。たとえば、図27-20のHuman Resourcesメニューには、共有ノードを使用してBenefitsメニューを参照するBenefitsというタブがあります。Benefitsメニューのバインド・タスク・フローにはBenefitsのビュー・アクティビティがすでに含まれているため、Human Resourcesメニューのバインド・タスク・フローにビュー・アクティビティを追加する必要はありません。

ビュー・アクティビティの詳細は、「ビュー・アクティビティの使用」を参照してください。

注意:

バインド・タスク・フローによって参照されるページがページ階層に含まれる場合は、そのバインド・タスク・フローをコールするバインドなしタスク・フローにタスク・フロー・コール・アクティビティを追加します。

XMLMenuModelメタデータ・ファイルを作成するには:

1. 「アプリケーション」ウィンドウで、作成したそれぞれのバインドなしタスク・フローのファイルを右クリックして、「ADFメニュー・モデルの作成」を選択します。

2. 「ADFメニュー・モデルの作成」ダイアログで、XMLMenuModelメタデータ・ファイルのファイル名および保存先ディレクトリを入力します。

3. 「OK」をクリックします。

27.11.1.2 グループ・ノードおよび子ノードの階層でのサブメニューの作成方法

作成したXMLMenuModelメタデータ・ファイルを開き、グループ・ノードにする項目ノードをグループ・ノードに変換します。その後、グループ・ノードが1つ以上の項目ノードの親となる階層を作成します。

始める前に:

構成可能なページ階層のオプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローを使用したページ階層の作成」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

グループ・ノードおよび項目ノードの階層でサブメニューを作成するには:

1. 「アプリケーション」ウィンドウで、XMLMenuModelメタデータ・ファイルをダブルクリックします。

「構造」ウィンドウに、バインドなしタスク・フローの各ビュー・アクティビティに対して1つの項目ノードが表示されます。デフォルトでは、定義されている階層はありません。

2. 「構造」ウィンドウで、これらの項目ノードをドラッグ・アンド・ドロップして、グループ・ノードに変換する項目ノードの子ノードにします。

グループ・ノードに変換する各項目ノードには、少なくとも1つの子項目ノードが必要です。たとえば、図27-20のメニュー階層を作成するには、Benefitsの項目ノードをグループ・ノードに変換し、Medical、DentalおよびVisionの項目ノードをドラッグ・アンド・ドロップしてBenefit項目ノードの子ノードにします。

3. 「構造」ウィンドウで親項目ノードを右クリックし、「groupNodeへの変換」を選択します。

4. 「groupNodeのプロパティ」ダイアログの「ID」フィールドで、新しい識別子を入力するか、デフォルト値を受け入れます。

識別子は、すべてのXMLMenuModelメタデータ・ファイルのすべてのノードで一意であることが必要です。ノードを識別する値を指定することをお薦めします。たとえば、Benefitsノードをグループ・ノードに変更する場合、デフォルトIDであるitemNode_benefitsをgroupNode_benefitsに更新できます。

5. 「idref」フィールドに、メニュー内のいずれかの他ノードのIDを入力します(例: itemNode_Medical)。

入力する値は、グループ・ノードまたは項目ノードである、子項目ノードのIDでもかまいません。

6. labelフィールドに値を入力するか既存のデフォルト値を変更して、実行時に表示する値を指定します。

たとえば、label_benefitsをBenefitsなどに変更できます。

7. フィールドの残りのデフォルト値を受け入れて、「終了」をクリックします。

「変換の確認」ダイアログに、groupNode要素のaction属性およびfocusViewID属性を削除するかどうかを確認するメッセージが表示されます。グループ・ノードではこれらの属性は使用されないため、常に「OK」をクリックします。

8. 「OK」をクリックします

27.11.1.3 メニュー階層を別のメニュー階層に添付する方法

共有ノード要素を使用して、2つのメニューを1つにリンクできます。たとえば、図27-20のメニュー階層に示した「Human Resources」メニューには、4つのサブメニュー(「Payroll」、「Time」、「Labor」および「Benefits」)が含まれています。Benefitsサブメニューは、それ自体がサブメニュー・エントリを持つメニューです。Human ResourcesメニューのXMLMenuModelメタデータ・ファイルで、Benefitsサブメニューの項目ノードを共有ノードに変換します。「Benefits」メニューのXMLMenuModelメタデータ・ファイルを参照する、新しく作成した共有ノードの属性(ref)のEL式を記述します。

始める前に:

構成可能なページ階層のオプションの内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローを使用したページ階層の作成」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、「複雑なタスク・フローの追加の機能」を参照してください。

共有ノードを使用してメニュー階層を別の階層に添付するには:

1. 「アプリケーション」ウィンドウで、他のメニューを参照するメニューのXMLMenuModelメタデータ・ファイルをダブルクリックします。

2. 「構造」ウィンドウで、ノードを選択して右クリックし、sharedNode要素を挿入する、適切なメニュー・オプションを選択します。

3. 「sharedNodeの挿入」ダイアログの「参照」フィールドで、もう1つのメニューのXMLMenuModelメタデータ・ファイルを参照するためのEL式を入力します。

4. 「OK」をクリックします。

注意:

ページ階層に複数のバインドなしタスク・フローがある場合は、追加したそれぞれのバインドなしタスク・フローのファイル名が、<metadata-resources>要素の値としてadfc_config.xmlファイルに含まれていることを確認してください。詳細は、「ページ階層の作成時の処理」を参照してください。

27.11.2 ページ階層の作成時の処理

ページ階層を作成すると、様々なファイルで変更が発生します。

adfc-config.xmlの変更内容

新しいバインドなしタスク・フローを作成すると、その新規作成バインドなしタスク・フローのソース・ファイルにadfc-config.xmlファイルの参照が自動的に追加されます。次の例のadfc-unbounded_tflow.xmlは、新しく作成されたバインドなしタスク・フローのソース・ファイルの名前です。

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2"
id="__1">
<metadata-resource id="__2">
/WEB-INF/adfc-unbounded_tflow.xml
</metadata-resource>
</adfc-config>

adfc-config.xmlの詳細は、「adfc-config.xml」を参照してください。

実行時、Fusion Webアプリケーションを最初に起動したとき、adfc-config.xmlファイルがロードされます。adfc-config.xmlファイルには次が含まれる可能性があります。

- バインドなしタスク・フローのADFナビゲーション・メタデータ

- バインドなしタスク・フローのADFアクティビティ・メタデータ

- ADFアクティビティによって使用されるマネージドBean

XMLMenuModelメタデータ・ファイル

JDeveloperでは、次の例に示すように、バインドなしタスク・フローに追加した各ビュー・アクティビティのノードを使用して、XMLMenuModelメタデータ・ファイルが生成されます。

<?xml version="1.0" encoding="windows-1252" ?>
<menu xmlns="http://myfaces.apache.org/trinidad/menu">
<groupNode id="groupNode_benenfits" label="Benefits" idref="itemNode_medical">
<itemNode id="itemNode_medical" label="label_medical"
action="adfMenu_medical" focusViewId="/medical"/>
<itemNode id="itemNode_dental" label="label_dental" action="adfMenu_dental"
focusViewId="/dental"/>
<itemNode id="itemNode_vision" label="label_vision" action="adfMenu_vision"
focusViewId="/vision"/>
</groupNode>
</menu>

バインドなしタスク・フローのダイアグラム

バインドなしタスク・フローのファイルは、ページ階層の移動に使用される制御フロー・ルールおよびマネージドBeanを使用して、JDeveloperによって更新されます。図27-23は、図27-22のバインドなしタスク・フローに対応する更新後のバインドなしタスク・フローをダイアグラマで示しています。

図27-23 更新されたバインドなしタスク・フロー

27.12 Oracle Fusion Middleware診断フレームワークへのインシデントのレポート

診断フレームワークは、Fusion Webアプリケーションで発生するインシデントに関する情報を収集および管理します。ADFコントローラでは、このフレームワークにインシデントをレポートできます。この情報を使用して、問題を解決するか、解決のためにOracleサポートに送信できます。インシデントの発生時にADFコントローラが診断フレームワークにレポートする情報の例は、次のとおりです。

- バージョン情報

- ページ・フロー・スタック・エントリなど、ビュー・ポート階層に関する情報

- ADFバインディング・コンテナの階層

- バインドなしタスク・フローに寄与するファイルのリストなどのメタデータ情報

さらに、ADFコントローラの実行時内の最新イベントに関する情報を診断フレームワークに送信することもできます。これらのイベントの例には、権限チェック、リージョンのリフレッシュ、アクティビティ間のナビゲーション、Oracle Metadata Services (MDS)フレームワークからのメタデータの取得などがあります。この情報(ADFコントローラの実行時内のイベント)の後半のカテゴリの送信には、QuickTrace、メモリーへのきめ細かいロギングを有効にするためにOracle Fusion Middlewareが提供するメカニズムを有効にする必要があります。QuickTraceの詳細(ADFコントローラが診断フレームワークに送信する最新イベントの履歴(数)を指定する方法を含む)は、『Oracle Fusion Middlewareの管理』のQuickTraceの構成および使用に関する項を参照してください。診断フレームワークの使用の詳細は、『Oracle Fusion Middlewareの管理』の「問題の診断」を参照してください。

28 アプリケーションでのダイアログの使用

この章では、Fusion Webアプリケーションでのダイアログの作成方法について説明します。この章では、ADF Controllerおよびタスク・フローを使用したダイアログの作成方法、およびその代替方法であるADF Facesダイアログ・フレームワークの使用方法を説明します。

この章の内容は次のとおりです。

- アプリケーションでのダイアログの使用について

- モーダル・ダイアログ内でのバインド・タスク・フローの実行

- バインド・タスク・フローのかわりとしてのADF Facesダイアログ・フレームワークの使用

28.1 アプリケーションでのダイアログの使用について

エンド・ユーザーの現在のページを表示するブラウザ・ウィンドウ外のセカンダリ・ブラウザ・ウィンドウにエンド・ユーザーへの情報を表示する場合は、ダイアログを使用します。たとえば、プライマリ・ブラウザ・ウィンドウ内のタスクに関するヘルプ情報をエンド・ユーザーに対して表示する場合や、エンド・ユーザーが値のリストから値を選択できるようにする場合です。このヘルプ情報の例は、モードレス・ダイアログが適しているユースケースです。モードレス・ダイアログを使用すると、エンド・ユーザーはプライマリ・ウィンドウとダイアログの両方で同時に作業できます。エンド・ユーザーによる値の選択が必要なユースケースの場合、モーダル・ダイアログがより適切です。モーダル・ダイアログを使用した場合、ダイアログで要求されたアクション(例: 値の選択)を実行しないかぎり、エンド・ユーザーはそのダイアログを起動したページにアクセスできません。

エンド・ユーザーに対してモードレス・ダイアログを構成する場合は、ADF Facesダイアログ・フレームワークを使用します。エンド・ユーザーに対してモーダル・ダイアログを構成する予定の場合は、1つ以上のダイアログを起動するために、ADF Controllerのバインド・タスク・フローを構成します。JSFページまたはページ・フラグメント・ファイル(.jsff)のいずれかを参照するビュー・アクティビティを定義して、ダイアログを起動できます。

28.1.1 アプリケーションのユース・ケースと例でのダイアログの使用

「モーダル・ダイアログでのバインド・タスク・フローの実行」では、モーダル・ダイアログでバインド・タスク・フローを実行し、エンド・ユーザーから入力を取得できる方法と、取得した入力を使用してバインド・タスクをコールしたビュー・アクティビティに戻ることができる方法を説明しています。アプリケーションでADFコントローラ・タスク・フローが使用されないか、モードレス・ダイアログの使用が必要な場合、「バインド・タスク・フローのかわりとしてのADF Facesダイアログ・フレームワークの使用」で、ADF Facesダイアログ・フレームワークを使用してダイアログに1つ以上のページをレンダリングできる方法が説明されています。

28.1.2 アプリケーションでダイアログを使用するための追加機能

アプリケーションでダイアログを構成または使用する前に、他のOracle ADF機能を理解しておくことが有効な場合があります。また、構成するダイアログで実行可能な機能について読むことが必要な場合もあります。次に、関連する他の機能へのリンクを示します。

- アプリケーションでADFコントローラのタスク・フローを使用する場合は、タスク・フローが提供する機能についてさらに理解しておくと役に立つ場合があります。詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。

- ADF Facesコンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

- また、Oracle ADFが提供するAPIを使用してダイアログのカスタム・コードを記述できます。カスタム・コードを記述する際は、次の例のように、内部としてマークされているパッケージをインポートしないようにしてください。
import oracle.adfinternal.controller.*;

カスタム・コードの記述に使用できるAPIの詳細は、次のドキュメントを参照してください。

- Oracle ADF ControllerのJava APIリファレンス

- Oracle ADF FacesのJava APIリファレンス

28.2 モーダル・ダイアログ内でのバインド・タスク・フローの実行

モーダル・ダイアログ内で実行するバインド・タスク・フローを構成し、エンド・ユーザーの入力を取得し、取得した入力とともに、バインド・タスク・フローをコールしたビュー・アクティビティに戻ることができます。構成するバインド・タスク・フローでは、ページ・フラグメントではなく、ページが参照される必要があります。

図28-1に、ADFタスク・フローのSummitサンプル・アプリケーションから必要とされる構成の例を示します。create-edit-orders-task-flow-definitionのタスク・フローには、ビュー・アクティビティ(Orders)が含まれ、エンド・ユーザーは、モーダル・ダイアログをレンダリングするorders-select-many-items.xmlタスク・フローをそのビュー・アクティビティから起動します。詳細は、「モーダル・ダイアログ内でのバインド・タスク・フローの実行方法」を参照してください。

エンド・ユーザーがダイアログを閉じると、制御およびすべての修正値は、create-edit-orders-task-flow-definitionのコール元タスク・フローにある起動ページに戻ります。詳細は、「モーダル・ダイアログから値を戻す方法」を参照してください。

さらに、モーダル・ダイアログが制御を戻した場合は、アプリケーションを構成して、起動ページの一部をリフレッシュできます。詳細は、「モーダル・ダイアログが戻った場合のページのリフレッシュ方法」を参照してください。

図28-1 Summit ADFサンプル・アプリケーションでモーダル・ダイアログを起動するためのタスク・フロー・アクティビティ

28.2.1 モーダル・ダイアログ内でのバインド・タスク・フローの実行方法

既存のタスク・フローにビュー・アクティビティとタスク・フロー・コール・アクティビティを追加します。ビュー・アクティビティにより、エンド・ユーザーがアクションを起動できるページが起動され、その結果、モーダル・ダイアログに表示されるバインド・タスク・フローが起動します。

始める前に:

構成する属性がモーダル・ダイアログ内のバインド・タスク・フローの機能に与える影響について理解しておくと役に立つ場合があります。詳細は、「モーダル・ダイアログ内でのバインド・タスク・フローの実行」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーションでダイアログを使用するための追加機能」を参照してください。

バインド・タスク・フローをモーダル・ダイアログ・ボックス内で実行するには:

1. 「アプリケーション」ウィンドウで、既存のタスク・フローをダブルクリックします。

2. タスク・フローのダイアグラムで、ビュー・アクティビティをダブルクリックし、関連付けられているページを開きます。

3. バインド・タスク・フローをモーダル・ダイアログ・ボックスとして起動するために、実行時にエンド・ユーザーがクリックするコマンド・コンポーネント(buttonコンポーネントなど)を選択します。

4. 「プロパティ」ウィンドウで「共通」セクションを開き、「アクション」フィールドでバインド・タスク・フローを起動する制御フロー・ケースを入力します。

たとえば、図28-1のselectmultipleitemsなどです。

5. 「UseWindow」ドロップダウン・リストから、ポップアップ・ダイアログ内でバインド・タスク・フローを起動するために、「true」を選択します。

6. 既存のタスク・フローのダイアグラムで、タスク・フロー・コール・アクティビティを選択します。

7. 「プロパティ」ウィンドウで「動作」セクションを開き、ダイアログとしてバインド・タスク・フローを実行するために、「「別名実行」ダイアログ」ドロップダウン・リストから「true」を選択します。

タスク・フロー・アクティビティがコールするバインド・タスク・フローはダイアログとして動作できます。このバインド・タスク・フローは、手順3から5で構成したコマンド・コンポーネントによって起動できるほか、「モーダル・ダイアログから値を戻す方法」の説明に従って、コマンド・コンポーネントをレンダリングするビュー・アクティビティに値を戻すことができます。モーダル・ダイアログでバインド・タスク・フローが実行されるようにするには、これらの他の変更を加える必要があることに注意してください。run-as-dialog属性のtrueへの設定では不十分です。

8. 外部ブラウザ・ウィンドウにダイアログをレンダリングする場合は「表示タイプ」ドロップダウン・リストから「external-window」(デフォルト値)、同じブラウザ・ウィンドウにダイアログをレンダリングする場合は「inline-popup」を選択します。

28.2.2 モーダル・ダイアログから値を戻す方法

モーダル・ダイアログにレンダリングされるバインド・タスク・フローを構成して、エンド・ユーザーがモーダル・ダイアログを閉じたときに、バインド・タスク・フローを起動したビュー・アクティビティに値を戻すことができます。戻された値は、たとえば、ビュー・アクティビティに関連付けられているページ上の入力コンポーネントに表示できます。

入力パラメータを宣言し、値を戻すには、タスク・フロー・コール・アクティビティによってコールされるバインド・タスク・フローを構成する必要があります。詳細は、「バインド・タスク・フローへのパラメータ渡し」を参照してください。

コマンド・コンポーネント(例: buttonコンポーネント)のreturnListener属性の値として、1つの引数を持つメソッド(戻りイベント)に対するメソッド・バインディングを指定します。returnListener属性により、ビュー・アクティビティに関連付けられているページ上の入力コンポーネントで、この値が設定されます。入力コンポーネントのバッキングBeanを指定し、入力コンポーネントのpartialTrigger属性をコマンド・コンポーネントのIDに設定します。

さらに、次を指定する必要があります。

- コール先バインド・タスク・フローに戻り値の定義を指定し、 コール先バインド・タスク・フローの終了時に戻り値を取得する場所を示します。

- 既存のタスク・フローのタスク・フロー・アクティビティに戻り値を指定し、 既存のタスク・フローが戻り値を検出できる場所を示します。
詳細は、「バインド・タスク・フローの戻り値の構成」を参照してください。

バッキングBean、入力コンポーネントおよびコマンド・コンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「入力コンポーネントの使用およびフォームの定義」を参照してください。

始める前に:

構成する属性がモーダル・ダイアログ内のバインド・タスク・フローの機能に与える影響を理解しておくと役に立つ場合があります。詳細は、「モーダル・ダイアログ内でのバインド・タスク・フローの実行」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーションでダイアログを使用するための追加機能」を参照してください。

次のタスクを完了する必要があります。

- モーダル・ダイアログで実行するためにバインド・タスク・フローを構成します。詳細は、「モーダル・ダイアログ内でのバインド・タスク・フローの実行方法」を参照してください。

戻り値を指定するには:

1. 「アプリケーション」ウィンドウで、モーダル・ダイアログでレンダリングするために、タスク・フロー・コール・アクティビティを含むタスク・フローをダブルクリックします。

2. ダイアグラム・エディタで、タスク・フロー・コール・アクティビティを選択します。

3. 「プロパティ」ウィンドウで「動作」セクションを開き、「「別名実行」ダイアログ」ドロップダウン・リストから「true」を選択します。

4. 「ダイアログ戻り値」フィールドで、ターゲット・バインド・タスク・フローに指定した戻り値の定義の名前を入力します。

バインド・タスク・フローの戻り値の定義を指定する方法の詳細は、「バインド・タスク・フローの戻り値の構成」を参照してください。

5. 「アプリケーション」ウィンドウで、モーダル・ダイアログを起動するページをダブルクリックします。

6. 設計エディタで入力コンポーネントを選択し、「プロパティ」ウィンドウで「動作」セクションを開いて、「PartialTriggers」フィールドのEL式を指定します。

指定したEL式によりコマンド・コンポーネントが識別され、そのコマンド・コンポーネントの戻り値が受け入れられて、バッキングBeanが指定されます。たとえば、次のような構文を使用してEL式を入力します。

#{pageFlowScope.backingBean.gotoModalDialog}

gotoModalDialogは、コマンド・コンポーネントを識別します。

7. 設計エディタでコマンド・コンポーネントを選択し、「プロパティ」ウィンドウで「動作」セクションを開いて、「ReturnListener」フィールドの値としてページのバッキングBeanの戻りリスナー・メソッドを参照するEL式を入力します。

指定した戻りリスナー・メソッドにより、エンド・ユーザーがモーダル・ダイアログを閉じたときに生成される戻りイベントが処理されます。Summit ADFタスク・フロー・サンプル・アプリケーションで、Orders.jsffページ・フラグメントのコマンド・コンポーネントは次のEL式を指定します。

#{viewScope.OrdersBackingBean.onShuttleTaskFlowReturn}

28.2.3 モーダル・ダイアログが戻った場合のページのリフレッシュ方法

エンド・ユーザーがモーダル・ダイアログを起動するページを構成すると、エンド・ユーザーがそのモーダル・ダイアログを終了した後にリフレッシュできます。モーダル・ダイアログが値を戻すか、エンド・ユーザーがモーダル・ダイアログの制御を使用してページ内の既存のデータを編集する場合は、この動作の構成が必要な場合があります。

この機能を実装するには、モーダル・ダイアログを起動するコマンド・コンポーネントを構成して、戻りイベントをリスニングします。戻りイベントを取得すると、ページ上で部分ページ・レンダリング・イベントを実行するバッキングBeanメソッドが起動されます。次の例は、モーダル・ダイアログを起動し、戻りイベントをリスニングするbuttonコンポーネントを示しています。

<af:button text="Edit"
id="b1" binding="#{backingBeanScope.backing_launch_page.b1}"
action="edit" useWindow="true"
returnListener="#{backingBeanScope.backing_launch_page.backFromPopup}"/>

buttonコンポーネントのreturnListener属性では、モーダル・ダイアログの起動により発生する戻りイベントがリスニングされます。戻りイベントを取得すると、次の例のようにバッキングBeanメソッドが起動されます。

public void backFromPopup(ReturnEvent returnEvent) {
AdfFacesContext adfFacesContext;
adfFacesContext = AdfFacesContext.getCurrentInstance();
adfFacesContext.addPartialTarget(this.getF1());
}

バッキングBeanメソッド(backFromPopup)では、戻りイベントが引数として取得され、例では、ページ内のフォーム上で部分ページ・レンダリング・イベントが起動されます。

始める前に:

タスク・フロー内のビュー・アクティビティと関連付けられたページから起動するモーダル・ダイアログの他のオプションの構成方法を理解しておくと役に立つ場合があります。詳細は、「モーダル・ダイアログ内でのバインド・タスク・フローの実行」を参照してください。

また、他のタスク・フローの機能およびダイアログ・フレームワークの機能を使用して追加可能な別の機能を理解しておくと役に立つ場合があります。詳細は、「アプリケーションのユースケースと例でのダイアログの使用」を参照してください。

モーダル・ダイアログが戻った後にページをリフレッシュするには:

1. 「アプリケーション」ウィンドウで、モーダル・ダイアログでレンダリングするバインド・タスク・フローを起動するタスク・フローをダブルクリックします。

2. ダイアグラムで、エンド・ユーザーがコマンド・コンポーネントを起動しモーダル・ダイアログを開始するページを参照するビュー・アクティビティをダブルクリックします。

3. 設計エディタで、コマンド・コンポーネントを選択します。

4. 「プロパティ」ウィンドウで「動作」セクションを開き、「セカンダリ・ウィンドウ」ラベルの下にある「ReturnListener」フィールドで、JDeveloperによる生成が必要なバッキングBeanメソッドの名前を指定するプロパティ・フィールドにカーソルを移動すると表示されるアイコンから「編集」を選択します。

5. 「編集プロパティ: ReturnListener」ダイアログで、「マネージドBean」フィールドの横にある「新規」をクリックします。

6. 「マネージドBeanの作成」ダイアログで、Beanおよびクラスに名前を付け、Beanのスコープを設定し、「OK」をクリックします。

7. 「編集プロパティ: ReturnListener」ダイアログで、「メソッド」フィールドの横にある「新規」をクリックします。

8. 「メソッドの作成」ダイアログで、メソッドに名前を付け、「OK」をクリックします。

9. 「編集プロパティ: ReturnListener」ダイアログで、「OK」をクリックします。

10. 「アプリケーション」ウィンドウで、「アプリケーション・ソース」を開いた後に、手順3から9で作成したバッキングBeanクラスとメソッドを含むパッケージを開きます。

11. メソッド本体を記述して、ページ上で部分ページ・レンダリング・イベントを起動します。

28.2.4 タスク・フローを使用するアプリケーションのダイアログに関する必知事項

Fusion Webアプリケーションがモードレス・ダイアログ(タスク・フロー以外の非モーダル・ダイアログ)をレンダリングし、タスク・フローなどのADFコントローラの機能も使用する場合は、faces-config.xmlファイルではなく、アプリケーションのadfc-config.xmlファイルの制御フロー・ルールにdialog:syntaxを指定します。「バインド・タスク・フローのかわりとしてのADF Facesダイアログ・フレームワークの使用」で説明するように、使用するFusion WebアプリケーションでADFコントローラ機能を使用しない場合は、faces-config.xmlファイル内のナビゲーション・ルールにdialog:syntaxを指定します。

次の例は、adfc-config.xmlファイルで指定できる内容を示しています。この例ではJSPページを参照していますが、ビュー・アクティビティを定義してJSFページまたはページ・フラグメント・ファイルのどちらでも起動できます。

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2" id="__1">
<view id="view1"
<page>/view1.jsf</page>
</view>
<view id="dialog">
<page>/dialog/untitled1.jsf</page>
</view>
<control-flow-rule>
<from-activity-id>test</from-activity-id>
<control-flow-case>
<from-outcome>dialog:test</from-outcome
<to-activity-id>dialog</to-activity-id>
</control-flow-case>
</adfc-config>

28.3 バインド・タスク・フローのかわりとしてのADF Facesダイアログ・フレームワークの使用

ADF Facesダイアログ・フレームワークを使用すると、ADF Controllerおよびタスク・フローを使用しないアプリケーションで、モーダル・ダイアログおよびモードレス・ダイアログを作成できます。このダイアログ・フレームワークでは、1つまたは一連のページを現在のページとして同じウィンドウ内に(同じビューIDで)表示するのではなく、新しいブラウザ・ウィンドウに表示できます。状況によっては、一連のインライン・ダイアログ(親ページの一部でありながら独自のフローを持つ一方で、別個のビューIDを使用しないダイアログ)の使用が検討される可能性もあります。これは、ポップアップをサポートしないアプリケーション(クライアント・デバイス上で稼働するアプリケーションや「アクティブ・データ・サービスの使用」で説明するアクティブ・データ・サービスを使用するアプリケーションなど)では重要です。通常、JavaScriptを使用してダイアログを開き、プロセスを管理する必要があります。ダイアログ・フレームワークを使用するADF Facesでは、JavaScriptを使用せずに簡単にダイアログやプロセスを管理したり、新しいブラウザ・ウィンドウを開くことができます。

注意:

使用するアプリケーションでADF ControllerとともにFusionテクノロジ・スタックを使用する場合は、タスク・フローを使用して別個のウィンドウ(つまり複数のダイアログ・プロセス)で起動するダイアログを作成する必要があります。詳細は、「モーダル・ダイアログ内でのバインド・タスク・フローの実行」を参照してください。

受注を確認しようとするユーザーにログインを要求する単純なアプリケーションについて考えてみます。図28-2は、5つのページ(login.jspx、orders.jspx、new_account.jspx、account_details.jspxおよびerror.jspx)で構成されるアプリケーションのページ・フローを示しています。

図28-2 外部ダイアログのサンプル・アプリケーションのページ・フロー

既存のユーザーが正常にログインすると、アプリケーションにより「Orders」ページが表示され、ユーザーの注文が(存在していれば)表示されます。ユーザーが正常にログインできなかった場合は、図28-3のように、別個のポップアップ・ダイアログ・ウィンドウに「エラー」ページが表示されます。

図28-3 「エラー」ポップアップ・ページ

「Error」ページには「Cancel」ボタンがあります。ユーザーが「取消」をクリックすると、ポップアップ・ダイアログが閉じ、アプリケーションは図28-4に示す「ログイン・ページ」および元のフローに戻ります。

図28-4 ログイン・ページ

新規ユーザーが「ログイン・ページ」で新規ユーザー・リンクをクリックすると、新しいウィンドウのポップアップ・ダイアログに新規アカウント・ページが表示されます(図28-5を参照)。

図28-5 別個のウィンドウの新規アカウント・ページ

ファースト・ネームやラスト・ネームなどの情報を入力した後、ユーザーが「Details」ボタンをクリックすると、同じポップアップ・ダイアログ内に「Account Details」ページが表示されます(図28-6)。ユーザーは「Account Details」ページでその他の情報を入力し、新しいログイン・アカウントのパスワードを確認入力します。「Account Details」ページには、2つのボタン(「Cancel」および「Done」)があります。

図28-6 ポップアップ・ダイアログ内の「Account Details」ページ

この新規ユーザーが新規ログイン・アカウントの作成手順に進まずに「取消」をクリックした場合は、ポップアップ・ダイアログが閉じてアプリケーションは「ログイン・ページ」に戻ります。新規ユーザーが「終了」をクリックした場合は、ポップアップ・ダイアログが閉じ、アプリケーションはユーザー名」フィールドにユーザーの名が移入された「ログイン・ページ」(図28-7を参照)に戻ります。この段階で、新規ユーザーは新しいパスワードを入力し、正常にログインできるようになります。

図28-7 「ユーザー名」フィールドに名前が移入された「ログイン・ページ」

注意:

ダイアログ・フレームワークを使用して、一度に複数のダイアログを開くことや、ベース・ページと存続期間が異なるダイアログを起動することはしないでください。

アプリケーションでのダイアログ・ページ・フローのサポートを容易にするために、ADF Facesにはアクション・コンポーネントのダイアログ機能(commandMenuItemおよびbuttonなど)が組み込まれています。アクション・コンポーネントからの新しいフローでページを開くかどうかをADF Facesに認識させるには、次の条件を満たす必要があります。

- dialog:で始まる結果を持つJSFナビゲーション・ルールが存在していること

- コマンド・コンポーネントのアクション結果がdialog:で始まっていること

- コマンド・コンポーネントのuseWindow属性がtrueであること

注意:

useWindow属性がfalseの場合、またはインラインでない別個のウィンドウとしてポップアップを構成する際にクライアント・デバイスでポップアップがサポートされていない場合、ADF Facesでは自動的に、ポップアップ・ウィンドウを使用せずに現在のウィンドウ内にページが表示されます(このアクションを実現するためにコードを変更する必要はありません)。

ダイアログに表示されるページは通常のJSFページですが、この章では外部ダイアログの実装方法を説明する目的で、ポップアップ・ダイアログに表示されるページをダイアログ・ページおよびダイアログを起動するページを元のページと呼びます。ダイアログ・プロセスは、元のページによって(1つまたは一連のダイアログ・ページを含む)ダイアログが起動すると開始され、ユーザーがダイアログを閉じて元のページに戻ると終了します。

アプリケーションでダイアログ・ページ・フローを作成するには:

1. ダイアログを開くためのJSFナビゲーション・ルールを定義します。

2. ダイアログの起動元のJSFページを作成します。

3. ダイアログ・ページを作成し、ダイアログ値を返します。

4. 値をダイアログに渡します(オプション)。

5. 戻り値を処理します。

これらの操作は、任意の順序で実行できます。

28.3.1 ダイアログを開くためのJSFナビゲーション・ルールの定義方法

ダイアログ・フローのナビゲーションを管理するには、特殊なdialog:結果を持つ標準的なJSFナビゲーション・ルールを定義します。

ダイアログを開くためのゲーション・ルールを定義するには:

1. 「アプリケーション」ウィンドウで、「WEB-INF」ノードを開いて、「adfc-config.xml」をダブルクリックします。

2. ダイアグラム・エディタで、元のページおよびダイアログ・ページのページ・フローを作成します。

詳細は、「タスク・フローに制御フロー・ルールを追加する方法」を参照してください。

3. ダイアログ・ページのナビゲーション・ルールを作成する場合、結果がdialog:で始まる必要があります。たとえば、図28-2のログイン・サンプル・アプリケーションの場合、「ログイン・ページ」から新規アカウント・ダイアログ・ページに渡される結果は、dialog:newAccountです。

実行時に、それぞれのダイアログ・ナビゲーション・ルールによって、指定したページが元のページ内に表示されるだけです。しかし、dialog:アクション結果を持つコマンド・コンポーネントを使用し、useWindow属性をtrueに設定した場合は、ADF Facesによりダイアログ内にページが開かれます。

28.3.2 ダイアログを開くJSFページの作成方法

元のページで、ダイアログを起動するコマンド・コンポーネントを使用する必要があります。コマンド・コンポーネントのアクション値は、起動されるダイアログに対する結果であることが必要です。

始める前に:

構成する属性がADF Facesダイアログ・フレームワークの機能に与える影響を理解しておくと役に立つ場合があります。詳細は、「アプリケーションでのダイアログの使用について」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーションでダイアログを使用するための追加機能」を参照してください。

次のタスクを完了する必要があります。

- ダイアログを開くJSFページも作成する必要があります。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のビュー・ページの作成に関する項を参照してください。

ダイアログを開くJSFページを作成するには:

1. 「アプリケーション」ウィンドウで、JSFページをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「一般コントロール」パネルからコマンド・コンポーネント(ボタンなど)をJSFページ上にドラッグ・アンド・ドロップします。

コマンド・コンポーネントをページに追加する方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のナビゲーションのボタンとリンクの使用に関する項を参照してください。

コマンド・コンポーネントに属性を設定する場合の注意点は、次のとおりです。

- Action: 「ダイアログを開くためのJSFナビゲーション・ルールの定義方法」で作成したように、ダイアログにナビゲートする結果にaction属性を設定します。

ヒント:

actionの値は、静的文字列またはマネージドBean上のメソッドの戻り値にすることができます。

たとえば、「ログイン・ページ」のコマンド・コンポーネントのaction属性は、戻される結果に基づいて注文ページまたは「エラー」ダイアログ・ページのどちらにナビゲートするかを決定するメソッドにバインドされます。メソッドがdialog:errorを戻した場合は、「エラー」ダイアログが開きます。メソッドがsuccessを戻した場合、ユーザーは「Orders」ページに移動します。

- ActionListener: action属性の設定の代替として、actionListener属性を構成して、次のクラスのインスタンスからlaunchDialogメソッドを起動します。
oracle.adf.view.rich.context.AdfFacesContext

launchDialogメソッドおよびAdfFacesContextクラスの詳細は、Oracle ADF FacesのJava APIリファレンスを参照してください。

- UseWindow: ダイアログを開くためにtrueに設定します。

ヒント:

falseに設定した場合、ADF Facesは、現在のページのすべての状態を保存した後、現在のウィンドウ内にダイアログ・ページを表示します。この機能を円滑に実行するためにコードを記述する必要はありません。

- WindowHeightおよびWindowWidth: ダイアログ・ウィンドウの目的のサイズを設定します。これらの値により、ダイアログのポップアップ・コンポーネントのcontentWidthおよびcontentHeight属性が設定されます。

ヒント:

ユーザーは実行時にこれらの属性の値を変更できますが、アプリケーションが変更の永続性を使用するように構成されていないかぎり、ユーザーがページを終了した時点で、それらの値は保持されなくなります。変更の永続性の有効化および使用の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「JSFページでのユーザー・カスタマイズの許可」を参照してください。

- PartialSubmit: trueに設定します。こうすることで、ポップアップ・ダイアログが表示されたときに元のページがリロードされることがありません(このため、一瞬表示されることもありません)。

- WindowEmbedStyle: 元のページに属するポップアップでダイアログを開く場合はinlineDocumentに設定します。ダイアログを別個のブラウザで開く場合は、windowに設定します。

- WindowModalityType: ダイアログをモーダルにする場合は、applicationModalに設定します。モーダル・ダイアログの場合、ダイアログを閉じるまで、ユーザーは元のページに戻れません。ユーザーが元のページとダイアログの間を行き来できるようにする場合は、modelessに設定します。

コマンド・コンポーネントはダイアログを開くとき、LaunchEventイベントを配信します。LaunchEventイベントは、ポップアップ・ダイアログを開くコンポーネントと、ダイアログ・プロセスの開始時に表示するコンポーネント・ツリーのルートに関する情報を格納しています。LaunchEventは、パラメータのマップをダイアログに渡すこともできます。詳細は、「ダイアログに値を渡す方法」を参照してください。

28.3.3 ダイアログ・ページを作成してダイアログ値を戻す方法

ダイアログ・ページは他のJSFページとほとんど同じですが、1つのみ例外があります。ダイアログ・ページでは、ダイアログ・プロセスが終了したとき(つまり、ユーザーがダイアログまたは一連のダイアログを閉じたとき)にADF Facesに通知する方法を指定する必要があります。

たとえば、新規アカウント・ページとアカウントの詳細ページは、同じダイアログ・プロセスに属しています。ダイアログ・プロセスには必要な数だけページを含めることができ、ダイアログ・プロセスが終了したことをフレームワークに通知するのは1回のみでかまいません。

これは、ダイアログを閉じるためのコマンド・コンポーネントに対する子としてreturnActionListenerタグを使用して、宣言的に行います。ただし、戻り値または他のアクション・イベント処理を提供する必要がある場合は、コマンド・コンポーネントのactionListener属性をAdfFacesContext.returnFromDialog()メソッドをコールするメソッドにバインドできます。このメソッドにより、パラメータのjava.lang.Objectまたはjava.util.Mapの形式で戻り値を返すことができます。値の戻し先を把握しておく必要はありません(ADF Facesで自動的に処理されます)。

実行時、AdfFacesContext.returnFromDialog()メソッドは、ユーザーがダイアログを閉じるとADF Facesに通知します。このメソッドは、ダイアログ・ページがポップアップ・ダイアログに表示されているかメイン・ウィンドウに表示されているかに関係なく、コールできます。ポップアップ・ダイアログが使用されている場合、ADF Facesにより自動的にそのポップアップ・ダイアログが閉じられます。

始める前に:

構成する属性がADF Facesダイアログ・フレームワークの機能に与える影響を理解しておくと役に立つ場合があります。詳細は、「アプリケーションでのダイアログの使用について」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーションでダイアログを使用するための追加機能」を参照してください。

ダイアログ・ウィンドウを閉じて任意で値を戻すには:

1. 「アプリケーション」ウィンドウで、ダイアログ・ページをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「一般コントロール」パネルからコマンド・コンポーネント(ボタンなど)をダイアログ・ページ上にドラッグ・アンド・ドロップします。

コマンド・コンポーネントをページに追加する方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のナビゲーションのボタンとリンクの使用に関する項を参照してください。

3. コマンド・コンポーネントを使用してウィンドウを閉じる場合は、「プロパティ」ウィンドウで「動作」セクションを開き、「即時」ドロップダウン・リストから「true」を選択します。

4. コマンド・コンポーネントを使用してダイアログ・プロセス内の別のページに移動する場合は、標準ナビゲーションのようにコマンド・コンポーネントを構成します。これを実行するには、「プロパティ」ウィンドウで「共通」セクションを開き、「UseWindow」ドロップダウン・リストから「false」を選択します。これにより、前のページの状態を保持しながら、同じダイアログ・ウィンドウに次のページが表示されます。

5. ダイアログ・プロセスを終了してダイアログを閉じる必要があるが、値を戻す必要はない場合は、「コンポーネント」ウィンドウの「操作」パネルで、「リスナー」グループの「アクション・リスナーを返す」をドラッグし、これを子としてコマンド・コンポーネントにドロップします。

returnActionListenerタグにより、AdfFacesContextオブジェクト上のreturnFromDialogメソッドがコールされます(バッキングBeanコードは不要です)。

このaf:returnActionListenerタグでは属性は使用されません。af:buttonコンポーネントのimmediate属性はtrueに設定されており、これによって、ユーザーが必須フィールドの「パスワード」および「パスワードの確認」に値を入力せずに「取消」をクリックした場合は、アプリケーションの起動フェーズではなく、リクエスト値の適用フェーズでデフォルトのJSF ActionListenerが実行されるため、入力の検証はバイパスされます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ADF FacesでのJSFライフサイクルの使用」を参照してください。

6. ダイアログ・プロセスを終了して値を戻す必要がある場合は、actionイベントを処理し、AdfFacesContextの現在のインスタンスのreturnFromDialogメソッドを使用して必要な値を戻す、マネージドBean上のメソッドを作成します。

注意:

AdfFacesContext.returnFromDialog()メソッドはnullを返します。バッキングBean内で「Cancel」アクション・イベントを処理するのに必要な値はこれだけです。

たとえば、ユーザーが「Account Details」ページの「Done」をクリックした場合、プロセスは終了し、ユーザーの入力値が返されます。次の例は、「終了」ボタンがバインドされているイベント・ハンドラ・メソッドのコードを示しています。このメソッドは顧客情報を取得し、その後、不正なパスワードに対するFacesメッセージを作成するか、新しい顧客オブジェクトに値を設定してそのオブジェクトを戻します。

public void done(ActionEvent e)
{
AdfFacesContext afContext = AdfFacesContext.getCurrentInstance();
String firstname = afContext.getPageFlowScope().get("firstname").toString();
String lastname = afContext.getPageFlowScope().get("lastname").toString();
String street = afContext.getPageFlowScope().get("street").toString();
String zipCode = afContext.getPageFlowScope().get("zipCode").toString();
String country = afContext.getPageFlowScope().get("country").toString();
String password = afContext.getPageFlowScope().get("password").toString();
String confirmPassword =
afContext.getPageFlowScope().get("confirmPassword").toString();
if (!password.equals(confirmPassword))
{
FacesMessage fm = new FacesMessage();
fm.setSummary("Confirm Password");
fm.setDetail("You've entered an incorrect password. Please verify that you've
entered a correct password!");
FacesContext.getCurrentInstance().addMessage(null, fm);
}
else
{
//Get the return value
Customer cst = new Customer();
cst.setFirstName(firstname);
cst.setLastName(lastname);
cst.setStreet(street);
cst.setPostalCode(zipCode);
cst.setCountry(country);
cst.setPassword(password);
// And return it
afContext.getCurrentInstance().returnFromDialog(cst, null);
}
}

28.3.4 実行時に行われる処理: ダイアログからの戻りイベントの呼出し方法

ダイアログが閉じると、ADF Facesは戻りイベント(ReturnEvent)を生成します。AdfFacesContext.returnFromDialog()メソッドは、戻り値を戻りイベントのプロパティとして送信します。この戻りイベントは、ダイアログを開いたコマンド・コンポーネント(たとえば、「ログイン」ページの「新規ユーザー」リンク)に登録されている戻りリスナー(ReturnListener)に配信されます。戻り値を処理する方法は、「戻り値の処理方法」を参照してください。

28.3.5 ダイアログに値を渡す方法

ダイアログに値を渡すには、LaunchEventのハンドラ・メソッドにバインドされているLaunchListenerリスナーを使用します。getDialogParameters()メソッドを使用すると、キーと値のペアを使用してパラメータをMapに追加できます。

始める前に:

構成する属性がADF Facesダイアログ・フレームワークの機能に与える影響を理解しておくと役に立つ場合があります。詳細は、「アプリケーションでのダイアログの使用について」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーションでダイアログを使用するための追加機能」を参照してください。

ダイアログに値を渡すには:

1. 「アプリケーション」ウィンドウで、ダイアログ・ページに移動するために使用されるコマンド・コンポーネントを含むJSFページをダブルクリックします。

2. 設計エディタで、ダイアログ・ページに移動するために使用されるコマンド・コンポーネントを選択します。

3. 「プロパティ」ウィンドウで、「動作」セクションを開きます。

4. 「LaunchListener」プロパティ・フィールドにカーソルを置いたときに表示されるアイコンから、「編集」を選択します。

5. 「編集プロパティ: LaunchListener」ダイアログで、「マネージドBean」フィールドの横の「新規」をクリックします。

6. 「マネージドBeanの作成」ダイアログで、Beanおよびクラスに名前を付け、Beanのスコープを設定し、「OK」をクリックします。

7. 「編集プロパティ: LaunchListener」ダイアログで、「メソッド」の横の「新規」をクリックします。

8. 「メソッドの作成」ダイアログで、メソッドに名前を付けて「OK」をクリックし、「OK」をクリックして編集プロパティ: LaunchListenerダイアログを閉じます。

9. 「アプリケーション」ウィンドウで、「アプリケーション・ソース」を開いた後に、手順3から8で作成したバッキングBeanクラスとメソッドを含むパッケージを開きます。

10. ソース・エディタで、getDialogParametersメソッドを使用してダイアログからパラメータを取得するLaunchEventに対して、ハンドラ・メソッドを記述します。

たとえば、サンプル・アプリケーションでは、新規ユーザーが「ログイン・ページ」の「ユーザー名」フィールドに名前を入力して、新規ユーザー・リンクをクリックできます。ポップアップ・ダイアログ内に「New Account」ダイアログ・ページが表示されると、「First Name」入力フィールドには、「Login」ページで入力された名前が自動的に移入されます。これを実現するには、次の例のように、getDialogParametersメソッドを使用してダイアログに「ユーザー名」フィールドの値を入力するハンドラを作成します。

public void handleLaunch(LaunchEvent event)
{
//Pass the current value of the field into the dialog
Object usr = username;
event.getDialogParameters().put("firstname", getUsername());
}
// Use by inputText value binding
private String username;
public String getUsername()
{
return username;
}
public void setUsername(String username)
{
this.username = username;
}

11. 「アプリケーション」ウィンドウで、ダイアログ・ページをダブルクリックします。

12. ダイアログ・ページで、pageFlowScopeオブジェクトを使用して#{pageFlowScope.someKey}という形式の特殊なEL式を介してキーと値を取得します(次の例を参照)。

<af:inputText label="First name" value="#{pageFlowScope.firstname}"/>

28.3.6 実行時の処理: LaunchEventの処理方法

ADF Facesでは、プロセスは常に、ダイアログが起動されたページのpageFlowScope内に存在するすべての値のコピーを取得します。getDialogParameters()メソッドがパラメータをMapに追加すると、これらのパラメータもpageFlowScope内で使用可能になり、ダイアログ・プロセス内のすべてのページは、EL式を介してpageFlowScopeオブジェクトを参照することによりpageFlowScopeから値を取得できます。

注意:

sessionScopeとは異なり、pageFlowScopeの値を表示できるのは、現在のページ・フローまたはプロセス内のみです。ユーザーが新しいウィンドウを開いて移動を開始した場合、一連のウィンドウには独自のプロセスが設定され、各ウィンドウに格納されている値の独立性は維持されます。ブラウザの「戻る」ボタンをクリックすると、pageFlowScopeは元の状態に自動的にリセットされます。プロセスから戻ると、pageFlowScopeはプロセスの開始前の状態に戻ります。プロセスの外へ値を渡すには、AdfFacesContext.returnFromDialog()、sessionScopeまたはapplicationScopeを使用します。

28.3.7 戻り値の処理方法

ダイアログが閉じたときに戻り値を処理するには、ダイアログを起動したコマンド・コンポーネントで戻りリスナーを定義します。たとえば、サンプル・アプリケーションでは、新規ユーザーが情報を入力した場合、その情報をダイアログ・プロセスの完了時に処理する必要があります。

始める前に:

構成する属性がADF Facesダイアログ・フレームワークの機能に与える影響を理解しておくと役に立つ場合があります。詳細は、「アプリケーションでのダイアログの使用について」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アプリケーションでダイアログを使用するための追加機能」を参照してください。

戻り値を処理するには:

1. 「アプリケーション」ウィンドウで、ダイアログ・ページに移動するために使用されるコマンド・コンポーネントを含むJSFページをダブルクリックします。

2. 設計エディタで、ダイアログ・ページに移動するために使用されるコマンド・コンポーネントを選択します。

3. 「プロパティ」ウィンドウで、「動作」セクションを開きます。

4. 「ReturnListener」プロパティ・フィールドにカーソルを置いたときに表示されるアイコンから、「編集」を選択します。

5. 「編集プロパティ: ReturnListener」ダイアログで、「マネージドBean」フィールドの横にある「新規」をクリックします。

6. 「マネージドBeanの作成」ダイアログで、Beanおよびクラスに名前を付け、Beanのスコープを設定し、「OK」をクリックします。

7. 「編集プロパティ: ReturnListener」ダイアログで、「メソッド」フィールドの横にある「新規」をクリックします。

8. 「メソッドの作成」ダイアログで、メソッドに名前を付けて「OK」をクリックし、「OK」をクリックして編集プロパティ: LaunchListenerダイアログを閉じます。

9. 「アプリケーション」ウィンドウで、「アプリケーション・ソース」を開いた後に、手順3から8で作成したバッキングBeanクラスとメソッドを含むパッケージを開きます。

10. ソース・エディタで、returnEvent用のハンドラ・メソッドを記述します。getReturnValue()メソッドを使用して戻り値を取得します。戻り値は自動的にReturnEventのプロパティとして追加されるためです。

次の例は、戻り値を処理する戻りリスナー・メソッドのコードを示しています。

public void handleReturn(ReturnEvent event)
{
if (event.getReturnValue() != null)
{
Customer cst;
String name;
String psw;
cst = (Customer)event.getReturnValue();
name = cst.getFirstName();
psw = cst.getPassword();
CustomerList.getCustomers().add(cst);
inputText1.setSubmittedValue(null);
inputText1.setValue(name);
inputText2.setSubmittedValue(null);
inputText2.setValue(psw);
}
}

28.3.8 実行時に行われる処理: 起動元コンポーネントのReturnEventの処理方法

サンプル・アプリケーションの実行時には、linkコンポーネントに登録されているReturnListenerにADF FacesがReturnEventを配信すると、handleReturn()メソッドがコールされ、それに応じて戻り値が処理されます。新規ユーザーは顧客リストに追加され、そのユーザーの利便性のために、「ログイン・ページ」で前に送信された値はすべて消去され、入力フィールドに新しい情報が移入されます。

第V部 データバインドされたWebユーザー・インタフェースの作成

ここでは、ADF Facesコンポーネントを使用して、Fusion Webアプリケーションのユーザー・インタフェースを設計する方法について説明します。

第V部の章の内容は次のとおりです。

- Webインタフェースのスタート・ガイド

- Fusionページ・ライフサイクルの理解

- データバインドされた基本的なページの作成

- ADFによるデータバインドされた表の作成

- ビュー・レイヤーで各機能を起動するコマンド・コンポーネントの使用

- マスター/ディテール・データの表示

- データバインドされた選択リストおよびシャトルの作成

- ADFによるデータバインドされた検索フォームの作成

- データバインドされたカレンダおよびカルーセル・コンポーネントの作成

- データバインドされたチャート・コンポーネント、統計図表コンポーネントおよびゲージ・コンポーネントの作成

- データバインドされたNBoxコンポーネントの作成

- データバインドされたピボット・テーブルおよびピボット・フィルタ・バー・コンポーネントの作成

- データバインドされた地理マップ・コンポーネントおよびテーマ・マップ・コンポーネントの作成

- データバインドされたガント・チャート・コンポーネントおよび時系列コンポーネントの作成

- データバインドされた階層ビューア、ツリーマップおよびサンバースト・コンポーネントの作成

- データバインドされたダイアグラム・コンポーネントの作成

- データバインドされたタグ・クラウド・コンポーネントの作成

- コンテキスト・イベントの使用方法

29 Webインタフェースの概説

この章では、Fusion WebアプリケーションでADF Facesコンポーネントを使用してデータバインドされたUIコンポーネントを作成するために、ADFデータ・コントロールの操作を開始する方法について説明します。ページ・テンプレートおよびページ・フラグメントを使用したページの作成方法を説明します。マネージドBeanを使用してページのロジックを格納する方法についても説明します。

この章の内容は次のとおりです。

- ADF Facesを使用したWebアプリケーション開発について

- ページ・テンプレートの使用方法

- Webページの作成

- Fusion WebアプリケーションでのマネージドBeanの使用

29.1 ADF Facesを使用したWebアプリケーション開発について

Webインタフェースを開始するための必知事項のほとんどは、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』で説明されています。ただし、JSFマネージドBeanのかわりにADFモデル・レイヤーを使用してデータバインディングを行うと、宣言的にコンポーネントをビジネス・サービスにバインドする機能など、追加の機能を使用できます。ADFモデルが提供する内容の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

この章では、Facesのマニュアルに詳細が含まれているWebインタフェース開発プロセスの概要を提供するとともに、ADFモデル・データ・バインディングを使用した場合に使用できる追加の機能に関する情報を提供します。

「Oracle ADFを使用したFusion Webアプリケーションの構築の概要」で説明した開発プロセスに従い、ADF Facesを使用してWebアプリケーションを開発し、データ・バインディングにADFモデルを使用するには、次の手順が必要です。

- ページのADF Facesテンプレートの作成(オプション)

- ページ内で使用するリージョンへの個別のページおよびページ・フラグメントの作成

- 必要なマネージドBeanの作成

また、Fusion Webアプリケーションのライフサイクルは、標準のJSFアプリケーションまたはADF Facesアプリケーションのライフサイクルとは異なります。ライフサイクルの仕組みの詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。

マネージドBeanは、ページやタスク・フローに柔軟にUIレベル・コードを追加するためのJavaクラスです。これらを、フロント・エンド・データ操作やイベント処理などの機能に使用できます。

ADF Facesページ・テンプレートは、Webページを構築するための構造、整合性および再利用性を提供します。ページ・テンプレートを1つ作成して複数のページに適用することで、一貫性のあるルック・アンド・フィールを実現できます。ページを作成するたびに同じ要素を配置する必要がなくなるため、時間と労力を節約できます。

29.1.1 ページ・テンプレートおよびマネージドBeanのユースケースと例

create-edit-orders-task-flow-definitionでは、ShuttleBeanを使用して、先行リストからの使用可能な製品を後続リストの選択した製品に移動するシャトル・コンポーネントをサポートするコードを示します。マネージドBeanには、使用可能製品リストおよび選択済製品リストにデータを移入するために必要なコードが含まれます。図29-1は、create-edit-orders-task-flow-definitionで使用されるマネージドBeanを示しています。

図29-1 create-edit-orders-task-flow-definitionのマネージドBean

29.1.2 ページ・テンプレートおよびマネージドBeanの追加機能

ADFモデル・レイヤーを構成または使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。また、モデル・レイヤーの構成によって可能になることについても、確認しておくことをお薦めします。次に、関連する他の機能へのリンクを示します。

- ページ・テンプレートの使用の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」および『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のページ・テンプレートの作成方法に関する項を参照してください。

- 標準JSFアプリケーションでのマネージドBeanの詳細は、Oracle Technology Network WebサイトのJava EEチュートリアル(http://www.oracle.com/technetwork/java/javaee/overview/index.html)を参照してください。マネージドBeanおよびスコープ値の詳細は、「オブジェクト・スコープ・ライフサイクルについて」を参照してください。

29.2 ページ・テンプレートの使用方法

アプリケーション・フローを設計すると同時に、ページのデザインの検討も開始できます。アプリケーション全体の整合性を保持するには、ADFページ・テンプレートを使用します。これらのページ・テンプレートは、Webページを作成する開発者に構造および整合性を提供します。ページ・テンプレートには通常、使用時に変更できない静的領域、および開発者が作成するページに固有のコンテンツを配置できる動的領域があります。

たとえば、ページ・テンプレートには、ブランド表示およびナビゲーションのための上部領域、著作権情報を表示する下部領域、およびページのメイン・コンテンツ用の中央領域が提供されます。このテンプレートを使用するページ開発者は、ブランド表示および著作権情報について何もする必要はありません。メイン・コンテンツ領域のみを開発します。

ADF Facesコンポーネントを使用してページ・テンプレートを作成し、さらにテンプレート定義に属性を追加できます。これらの属性は、ページ・テンプレートを使用するときにページ開発者が提供する必要がある特定の情報のプレースホルダとなります。たとえば、ようこそメッセージに属性を追加している場合、およびページ開発者がこのページ・テンプレートを使用する際に、ページごとに異なるようこそメッセージを追加できます。

また、ページ・テンプレートにファセット参照を追加することもできます。この参照は、ページ上のコンテンツのプレースホルダとして機能します。図29-2に、ページ・テンプレートで使用可能なファセットのレンディションを示します。

図29-2 ページ・テンプレートのファセット

このページ・テンプレートでは、ファセット参照は4つの異なるpanelSplitterコンポーネント内で使用されています。このページ・テンプレートを使用してホームページを作成すると、ナビゲーション・リンクはHeaderファセット内に配置され、ナビゲーション・ツリーや検索パネルを含むアコーディオン・パネルはStartファセット内に配置されます。カートの合計はEndファセットに配置され、ページの主要部分はCenterファセットに配置されます。著作権情報はBottomファセットに配置されます。

データバインドされたコンポーネントをページ・テンプレートに追加することを選択した場合、関連するページ定義ファイルおよびADFモデル・レイヤー・データ・バインディングをサポートする他のメタデータ・ファイルが作成されます。「Fusion WebアプリケーションでのADFモデルの使用」で説明しているように、各コンポーネントは標準JSFページと同様にバインドされます。また、ページ・テンプレートのモデル・パラメータも作成できます。それらのパラメータの値は、実行時にコール元のページから設定できます。

たとえば、ページ・テンプレートを使用している各ページに製品の一覧を表示する場合、ProductVOコレクションのName属性をリストとしてドラッグ・アンド・ドロップできます。また、現在選択されている製品IDをページに表示する場合は、その製品のIDに評価されるモデル・パラメータをページ・テンプレートに対して作成できます。

注意:

ページ・テンプレートは本来プロジェクト・アーティファクトです。プロジェクトとアプリケーションの間で再利用できますが、完全な自己完結型ではなく、ADFデータバインディング、メッセージ・バンドルのString、イメージ、およびマネージドBeanなどの外部リソースに対して常に依存します。

ページ・テンプレートにデータバインドされたコンポーネントが含まれない場合は、EL式を使用してコール元のページから動的に参照できます。つまり、使用するページ・テンプレートを実行時に決めることができます。たとえば、ユーザーの選択に基づいてtemplateAまたはtemplateBを使用できます。ページにページ・テンプレートを追加すると、af:pageTemplateタグがページに追加されます。このaf:pageTemplateタグには、そのページで使用されるページ・テンプレートを指定するviewId属性が含まれます。次の例に示すように、EL式を使用して、ページ・テンプレートIdを戻すマネージドBeanメソッドにviewIdを設定できます。

<af:pageTemplate
id="pt1"
viewId="#{myBean.templateViewId}"

ページ・テンプレートにデータバインドされたコンポーネントが含まれる場合、EL式でviewIdを設定するのみでは不十分です。データバインドされたコンポーネントにはバインディング・コンテナへのアクセスが必要なため、ページ・テンプレートおよび関連付けられているバインディング・コンテナを指定する必要があります。

データバインドされているページ・テンプレートでは、pageTemplateModelを使用して、ページ・テンプレートIdおよび関連付けられているバインディング・コンテナの両方を管理します。JSFページでは、viewId属性を使用するかわりに、value属性をpageTemplateModelに設定します。また、コール元ページのページ定義ファイルのページ実行可能セクションを変更し、ページ・テンプレートIdを処理するメソッドを使用してマネージドBeanを作成する必要があります。詳細な手順は、「データバインドされたページ・テンプレートをページに動的に追加する方法」を参照してください。

29.2.1 ADFページ・テンプレートでのADFデータ・バインディングの使用方法

ADFビジネス・コンポーネントおよびADFモデル・レイヤー・データ・バインディングを使用するアプリケーションで使用するページ・テンプレートの作成方法は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のページ・テンプレートの使用方法に関する項に記載されているように、標準のADF Facesページ・テンプレートの作成方法と同様です。テンプレートを作成すると、「データ・コントロール」パネルから項目をドラッグ・アンド・ドロップできます。このパネルから項目をドラッグ・アンド・ドロップすると、ページ定義ファイルが自動的に追加されます。

ページ・テンプレートの作成ウィザードを使用しても、テンプレートで使用するためのモデル・パラメータを作成できます。

始める前に:

基本的なページ・テンプレートの作成で使用可能な各オプションを理解しておくと役立ちます。詳細は、「ページ・テンプレートの使用方法」を参照してください。

また、ページ・テンプレートで使用可能な追加機能についても理解しておくと役立ちます。詳細は、「ページ・テンプレートおよびマネージドBeanの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のページ・テンプレートの作成方法に関する項の説明に従って、ADFビジネス・コンポーネントおよびADFモデル・レイヤー・データ・バインディングを使用するページ・テンプレートを作成します。ただし、ダイアログを完成させないでください。

モデル・パラメータをテンプレートに追加するには:

1. ページ・テンプレートの作成ウィザードの「データ・バインディング」ページで、「ページ定義ファイルの作成」を選択します。

注意:

パラメータを追加する場合は、このチェック・ボックスのみを選択します。「データ・コントロール」パネルから項目をドラッグ・アンド・ドロップすると、ページ定義ファイルが自動的に追加されます。

2. 「追加」アイコンをクリックします。

3. パラメータに、次のように入力します。

- ID: パラメータの名前を入力します。

- 値: 値に、解決可能な値またはEL式を入力します。必要に応じて、「式ビルダーの起動」(...)ボタンをクリックして「式ビルダー」を開きます。式ビルダーを使用して式を作成できます。EL式およびEL式ビルダーの詳細は、「ADFデータ・バインディングのEL式の作成」を参照してください。

- オプション: パラメータ値の指定方法を決定するオプションを選択します。

- オプション: コール元によって特にパラメータが設定されていない場合のみ、バインディング定義の値が使用されます。これはデフォルトです。

- 最終: このパラメータに使用する値にアクセスするための式が、バインディング定義に含まれています。

- 必須: コール元がパラメータ値を設定する必要があります。

- 読取り専用: パラメータ値が読取り専用であり、上書きしない場合に選択します。

4. 必要に応じてさらにパラメータを作成します。「順序」ボタンを使用し、評価する順序にパラメータを整列させます。

これで、この部の残りの章で説明しているように、標準JSFページと同様、「データ・コントロール」パネルを使用してデータバインドされたUIコンポーネントをページに追加できるようになりました。

注意:

テンプレートにメソッド・イテレータにバインドされたメソッド・アクションが含まれる場合、イテレータのrefresh属性の値をDefault以外の値に変更できません。Default以外の値に設定すると、メソッドは実行されません。

29.2.2 ページ・テンプレートにADFモデル・レイヤー・バインディングを使用するときに行われる処理

ADFのデータバインドされたコンポーネントをテンプレートに追加したり、テンプレートにモデル・パラメータを作成すると、そのテンプレートのページ定義ファイルが作成され、そのファイルにモデル・パラメータが追加されます。

注意:

この項では、静的に割り当てられるページ・テンプレートの処理について説明します。動的テンプレートの詳細は、「データバインドされたページ・テンプレートをページに動的に追加する方法」を参照してください。

次の例は、productIdモデル・パラメータを作成したテンプレートのページ定義ファイルを示しています。

<parameters>
<parameter id="productID" readonly="true"
value="#{bindings.productId.inputValue}"/>
</parameters>
<executables/>
<bindings/>

パラメータ・バインディング・オブジェクトにより、リクエスト開始時にページによって評価されるパラメータが宣言されます。バインディング・オブジェクトおよびADFライフサイクルの詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。ただし、テンプレート自体は実行されることはないため、テンプレートを使用するページ(コール元ページ)は、テンプレート用に作成されたバインディング・オブジェクト(「データ・コントロール」パネルからテンプレートにオブジェクトをドラッグ・アンド・ドロップして作成した、パラメータまたはその他のタイプのバインディング・オブジェクトを含む)にアクセスする必要があります。

テンプレートのバインディング・オブジェクトにアクセスするには、コール元のページのページ定義ファイルで、テンプレートのページ定義ファイルが示すバインディング・コンテナをインスタンス化する必要があります。その結果、テンプレートのページ定義への参照は、次の例に示すようにコール元のページのページ定義ファイルに実行可能ファイルとして挿入されます。

<executables>
<page path="oracle.summt.view.pageDefs.MyTemplatePageDef"
id="pageTemplateBinding"/>
</executables>

この例のコール元ページは、MyTemplateテンプレートを使用して作成されています。MyTemplateテンプレートのページ定義ファイルはコール元ページの実行可能ファイルとして表示されるため、 コール元ページのバインディング・コンテナがインスタンス化されると、続いてMyTemplatePageDefのバインディング・コンテナがインスタンス化され、これによってパラメータ値またはその他のデータバインドされた値へのアクセスが可能になります。

この参照にはID(この例ではpageTemplateBinding)があるため、コール元のページはテンプレートから値にアクセス可能なコンポーネントを保持できます。テンプレートからJSFページを作成する場合、テンプレート内のコードを繰り返す必要はなく、かわりにコール元のページにaf:pageTemplateタグを使用できます。このタグは、テンプレートJSFページへのパスを含みます。

また、テンプレートにADFデータ・バインディングが含まれている場合、そのタグの値は次の例に示すように、テンプレートのページ定義へのコール元のページの参照に設定されたIDとなります。

<af:pageTemplate viewId="/MyTemplate.jspx"
value="#{bindings.pageTemplateBinding}".../>

29.2.3 データバインドされたページ・テンプレートをページに動的に追加する方法

ページ・テンプレートを選択するEL式を使用することで、データバインドされたコンポーネントを含まないページ・テンプレートを動的に追加できます。手順の詳細は、「ページ・テンプレートの使用方法」を参照してください。

また、データバインドされたコンポーネントを含むページ・テンプレートを静的に追加できます。手順の詳細は、「ADFページ・テンプレートでのADFデータ・バインディングの使用方法」を参照してください。

この項では、データバインドされたコンポーネントを含むページ・テンプレートをページに動的に追加する方法を説明します。詳細は、「ページ・テンプレートの使用方法」を参照してください。

ページ・テンプレートおよびそのバインディング・コンテナを動的に管理するには、pageTemplateModelを使用します。ページ定義ファイル内でEL式を使用して、ページ・テンプレートIdを設定します。ページ・テンプレートIdを戻すためのマネージドBeanメソッドを作成します。

始める前に:

基本的なページ・テンプレートの作成で使用可能な各オプションを理解しておくと役立ちます。詳細は、「ページ・テンプレートの使用方法」を参照してください。

また、ページ・テンプレートで使用可能な追加機能についても理解しておくと役立ちます。詳細は、「ページ・テンプレートおよびマネージドBeanの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「ADFページ・テンプレートでのADFデータ・バインディングの使用方法」の説明に従って、ADFビジネス・コンポーネントおよびADFモデル・レイヤー・データ・バインディングを使用するページ・テンプレートを作成します。

データバインドされたページ・テンプレートをページに動的に追加するには:

1. JSFページ・ソース・エディタで、viewId属性を削除してvalue属性をpageTemplateModelに変更します。明示的にpageTemplateModelを作成する必要はありません。対応するページ定義ファイルのページ実行可能バインディングのpageTemplateModelを使用できます。たとえば、pageTemplate1というページ実行可能バインディングでは、af:pageTemplateタグの下に次の行を追加します。

value="#{bindings.pageTemplate1.templateModel}"/>

2. ページ定義ファイルの<executable>セクションで、<page>セクションに対して次の変更を行います。

- path属性を削除します。これは今後必要ありません。データバインドされたコンポーネントのバインディング・コンテナへのアクセスは、pageTemplateModelで管理されます。

- id属性をページ実行可能バインディングに変更します。この例ではpageTemplate1です。

- Refresh属性を追加してifNeededに設定します。

- viewId属性を追加して、現在のページ・テンプレートIdを戻すマネージドBeanメソッドを使用するEL式に設定します。

たとえば、pageTemplate1のページ実行可能バインディングでは、id属性もpageTemplate1になります。

<executables>
<page id="pageTemplate1"
viewId="#{myBean.templateViewId}"
Refresh="ifNeeded"/>
...
</executables>

3. 現在のページ・テンプレートIdを戻すメソッドを使用してpageFlowScopeマネージドBeanを作成します。

マネージドBeanのコードは、次の例に含まれるもののようになります。この例の場合、gettemplateViewId()は、ユーザーのページ・テンプレートの選択を取得してページ・テンプレートIdを戻します。setMDTemplateViewId()は、ページ・テンプレートをMDPageTemplateに設定し、setPopupTemplateViewId()は、ページ・テンプレートをPopupPageTemplateに設定します。

public class myClass {
final private String MDPageTemplate = "/MDPageTemplate.jspx";
final private String PopupPageTemplate = "/PopupPageTemplate.jspx";
private String templateViewId;

public myClass() {
super();
templateViewId = MDPageTemplate;
}
public String gettemplateViewId() {
return templateViewId;
}
public void setMDTemplateViewId(ActionEvent ae) {
templateViewId = MDPageTemplate;
}
public void setPopupTemplateViewId(ActionEvent ae) {
templateViewId = PopupPageTemplate;
}
}

29.2.4 実行時に行われる処理: ページでのテンプレートの使用方法

ADFデータ・バインディングを含むテンプレートを使用してページが作成される場合(テンプレートがないページなど)は、ページの作成にページ定義ファイルが使用されます。ライフサイクル中に、ページ・テンプレートのバインディング・コンテナも作成され、ページとテンプレートの両方に対するUIコンポーネントおよびバインディングが処理されます。

具体的には、次のような処理が行われます。

1. 「Fusionページ・ライフサイクルの理解」で説明しているように、コール元のページは標準JSF/ADFライフサイクルに準拠します。ページがビューのリストア・フェーズを開始すると、コール元のページのURLはバインディング・コンテキストに送信され、対応するページ定義ファイルが検索されます。

2. 内容の初期化フェーズ中に、コール元のページのバインディング・コンテナはページ定義ファイルに基づいて作成されます。

3. モデル準備フェーズ中に、実行可能なページ・テンプレートがリフレッシュされます。この時点で、テンプレートのバインディング・コンテナはテンプレートのページ定義ファイルに基づいて作成され、バインディング・コンテキストに追加されます。

4. ライフサイクルは、処理対象のページとテンプレートの両方のUIコンポーネントおよびバインディングとともに継続します。

29.3 Webページの作成

タスク・フローのビュー・アクティビティをダブルクリックするか、新規ギャラリを使用して、ページを作成できます。ページの作成時(またはビュー・アクティビティをタスク・フロー上にドロップする際)には、JSF JSPまたはJSF JSPフラグメントのどちらとしてページを作成するかを選択できます。JSFフラグメントは、プロジェクト内に再利用可能なページ・コンテンツを作成するための簡単な方法を提供するもので、タスク・フローをページ上のリージョンとして使用する場合に使用します。JSFページ・フラグメントを変更すると、そのページ・フラグメントを使用するJSFページが自動的に更新されます。

注意:

JDeveloperはFaceletsを使用するアプリケーションでのXHTMLファイルの使用をサポートしていますが、faces-config.xmlおよびadfc-config.xmlダイアグラマはXHTMLをサポートしていません。これらのファイルにナビゲーションを追加するには、「ソース」タブをクリックしてコードを手動で編集する必要があります。

ページへのコンテンツの追加を開始する場合、通常はJDeveloperの「コンポーネント」ウィンドウと「データ・コントロール」パネルを使用します。「コンポーネント」ウィンドウには、ページを宣言的に設計するために必要なすべてのADF Facesコンポーネントが含まれます。基本的なレイアウト・コンポーネントをページに配置すると、「データ・コントロール」パネルから項目をドラッグ・アンド・ドロップし、ADF ModelのデータバインドされたUIコンポーネントを作成できます。このマニュアルの後の章では、ADFモデル・データバインディングを使用して作成できる異なるタイプのデータバインドされたコンポーネントとページの詳細を説明します。

29.3.1 Webページの作成方法

「JSFページの作成」ダイアログを使用して、Webページを作成します。

始める前に:

ページの作成時には様々なオプションに関する知識が役立つ場合があります。詳細は、「Webページの作成」を参照してください。

Webページを作成するには:

1. 「アプリケーション」ウィンドウで、ページを保存するノード(ディレクトリ)を右クリックし、「新規」→「ページ」を選択します。

2. 「JSFページの作成」ダイアログに従って操作を進めます。ヘルプを参照するには、ダイアログで「ヘルプ」をクリックします。

ページの作成時の使用可能なテンプレートおよび処理の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のビュー・ページの作成に関する項を参照してください。

29.3.2 空白Webページの作成に関する必知事項

新規の空白Webページを作成する場合は、作業しているプロジェクトのタイプおよびプロジェクトでインポートされているタグ・ライブラリによって、生成されるコードが異なる場合があります。たとえば、「カスタム・プロジェクト」テンプレートから作成したプロジェクトで作業している場合、および「JSFページの作成」ダイアログで「空白ページの作成」オプションを選択した場合、ADF Fusion Webアプリケーション・ワークスペースのUIプロジェクトの同様な状況下と同様に生成されたコードには、ADF Facesタグが含まれない場合があります。

ADF Facesタグを含む事前定義済レイアウトなしでページを作成する場合、「JSFページの作成」ダイアログの「クイック・スタート・レイアウトのコピー」オプションを選択し、単純なレイアウトを選択するほうが容易な場合があります。このオプションを選択すると、プロジェクト内にADF Facesタグ・ライブラリのインポートがトリガーされます。また、プロジェクトに作成する後のページは、「空白ページの作成」オプションを選択して作成された場合でも、ADF Facesタグを使用します。

29.3.3 Webページのセキュリティ保護に関する必知事項

Webページを作成する場合は、セキュリティを適用する方法について計画を立てる必要があります。

ADFセキュリティ・フレームワーク内でWebページを保護するには、ページのページ定義ファイルを実際にセキュリティ保護します。ページがバインド・タスク・フロー内にある場合、バインド・タスク・フローが保護されます(そのバインド・タスク・フローに適用されるセキュリティ・ポリシーは、そのタスク・フロー内のページのすべてに適用されます)。ページがバインド・タスク・フロー内である場合、ユーザーはそのページに直接アクセスできるので、ページ定義ファイルにセキュリティ・ポリシーを適用しないでください。

Webページの保護の詳細は、「ADFセキュリティ・ポリシーの定義」を参照してください。

29.4 Fusion WebアプリケーションでのマネージドBeanの使用

マネージドBeanは、様々な構成ファイルを使用してアプリケーションに登録するJavaクラスです。JSFアプリケーションが起動すると、これらの構成ファイルが解析され、その中にリストされているBeanが使用可能になります。EL式内でマネージドBeanを参照できるため、Beanのプロパティおよびメソッドにアクセスできます。マネージドBeanが初めて参照されたときに、それがまだ存在しなていなかった場合は、常に、マネージドBean作成機能がそのBeanでデフォルトのコンストラクタ・メソッドをコールし、Beanがインスタンス化されます。また、プロパティが宣言されると、宣言されたデフォルトの値が移入されます。

多くの場合、マネージドBeanは、フロント・エンドで処理することが最適なイベントやデータ操作を処理します。標準JSFアプリケーションでのマネージドBeanの使用方法の詳細は、Oracle Technology Network WebサイトのJava EEチュートリアル(http://www.oracle.com/technetwork/java/javaee/overview/index.html)を参照してください。

ベスト・プラクティス

マネージドBeanを使用して格納するのは、UIレンダリングに関連するロジックのみです。すべてのアプリケーション・データおよび処理データは、アプリケーションのビジネス・レイヤーのロジックによって処理される必要があります。JavaクラスではなくPL/SQLを使用してデータ関連のロジックをデータベースに格納するのと同様に、Fusion Webアプリケーションにおける経験則では、ビジネス関連のロジックを中間層に格納します。このようにすると、このロジックをビジネス・サービス・メソッドとして公開でき、ADFモデル・レイヤーでアクセスできるようになり、データ・バインディングに使用できます。

ADFデータ・バインディングおよびADFタスク・フローを使用するアプリケーションでは、マネージドBeanは標準JSFアプリケーションで使用されるものとは異なる構成ファイルに登録されています。標準JSFアプリケーションでは、マネージドBeanはfaces-config.xml構成ファイルに登録されます。Fusion Webアプリケーションでは、マネージドBeanはfaces-config.xmlファイル、adfc-config.xmlファイルまたはタスク・フロー定義ファイルに登録できます。マネージドBeanの登録にどの構成ファイルを使用するかは、そのBeanにアクセスする必要があるものは何か、実行時にカスタマイズする必要があるか、Beanのスコープは何か、アプリケーション内のすべてのBeanをどの順序でインスタンス化する必要があるかによって異なります。表29-1に、各タイプの構成ファイルへのBeanの登録がBeanにどのような影響を与えるかを示します。

注意:

Fusion Webアプリケーションは、ADFタスク・フローによって提供される機能を利用します。タスク・フロー定義内でアクセスされたマネージドBeanは、faces-config.xmlファイル内ではなく、そのタスク・フローの定義ファイル内に登録する必要があります。

表29-1 マネージドBeanの構成配置の影響

マネージドBeanの配置

影響

adfc-config.xml

- マネージドBeanは任意のスコープにできます。ただし、ページ・フラグメントまたは宣言コンポーネントのバッキングBeanはBackingBeanスコープを使用する必要があります。スコープの詳細は、「オブジェクト・スコープ・ライフサイクルについて」を参照してください。

- バインドなしタスク・フロー内で実行した場合、adfc-config.xmlファイルの前にfaces-config.xmlでマネージドBeanの定義を確認します。

- 参照の優先順位はスコープごとに実行されます。リクエスト・スコープのマネージドBeanは、セッション・スコープのマネージドBeanより優先されます。このため、adfc-config.xmlファイル内のfooという名前のリクエスト・スコープのマネージドBeanは、現在のタスク・フロー定義ファイルのfooという名前のセッション・スコープのマネージドBeanより優先されます。

- すでにインスタンス化されたBeanは、インスタンス化される新しいインスタンスより優先されます。このため、fooという名前の既存のセッション・スコープのマネージドBeanは、現在のタスク・フロー定義ファイルで定義されたfooという名前のリクエスト・スコープBeanより常に優先されます。

タスク・フロー定義ファイル

- マネージドBeanは任意のスコープにできます。ただし、タスク・フロー定義内でアクセスされるpageFlowスコープまたはviewスコープのマネージドBeanは、タスク・フロー定義ファイル内で定義する必要があります。タスク・フロー内のページ・フラグメントのバッキングBeanは、BackingBeanスコープを使用する必要があります。

- タスク・フロー定義ファイル内のマネージドBean定義は、同じタスク・フロー内で実行されているアクティビティからのみ参照できます。

- バインド・タスク・フロー内で実行した場合、現在実行中のタスク・フロー定義の前にfaces-config.xmlでマネージドBeanの定義を確認します。どちらの場所でも一致するものがない場合、adfc-config.xmlおよび他のブートストラップ構成ファイルを参照します。ただし、他のadfc-config.xmlおよびブートストラップ構成ファイルの参照は、セッション・スコープまたはアプリケーション・スコープのマネージドBeanでのみ発生します。

- 参照の優先順位はスコープごとに実行されます。リクエスト・スコープのマネージドBeanは、セッション・スコープのマネージドBeanより優先されます。このため、adfc-config.xmlファイル内のfooという名前のリクエスト・スコープのマネージドBeanは、現在のタスク・フロー定義ファイルのfooという名前のセッション・スコープのマネージドBeanより優先されます。

- すでにインスタンス化されたBeanは、インスタンス化される新しいインスタンスより優先されます。このため、fooという名前の既存のセッション・スコープのマネージドBeanは、現在のタスク・フロー定義ファイルで登録されたfooという名前のリクエスト・スコープBeanより常に優先されます。

- カスタマイズ可能です。

faces-config.xml

- マネージドBeanは、pageFlowスコープまたはviewスコープ以外の任意のスコープにできます。

- マネージドBeanを検索する場合、常に最初にfaces-config.xmlファイルが参照されます。他の構成ファイルは、一致しない場合のみ検索されます。このため、faces-config.xmlファイルに登録されたBeanは、すべての名前の競合解消で常に優先されます。

- カスタマイズはできません。

Fusion Webアプリケーションの一般的な規則として、複数のページまたはタスク・フローで使用できるBean、または主要なバインドなしタスク・フロー(adfc-config)内のページで使用されるBeanは、adfc-config.xml構成ファイルに登録する必要があります。特定のタスク・フローでのみ使用されるマネージドBeanは、そのタスク・フローの定義ファイルで登録する必要があります。faces-config.xmlファイルには、Beanは登録されません。

注意:

JDeveloperのダイアログからマネージドBeanを作成した場合、adfc-config.xmlファイルが存在すれば、このファイルにBeanが登録されます。

たとえば、Oracle ADFのSummitサンプル・アプリケーションでは、ShuttleBeanはそのページのシャトル・コンポーネントの選択内容を処理するために、showshuttleページによって使用されるマネージドBeanです。create-edit-orders-task-flow-definitionタスク・フロー内で単独で使用されるため、create-edit-orders-task-flow-definition定義ファイルに登録されます。

タスク・フロー(デフォルトのadfc-configフローまたはバインド・タスク・フロー)内で使用するマネージドBeanを作成できます。マネージドBeanおよびJSFページのバッキングBeanとしてのマネージドBeanの使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のマネージドBeanの作成と使用に関する項を参照してください。

29.4.1 マネージドBeanを使用した情報の格納方法

タスク・フロー定義のエディタを使用すると、マネージドBeanを作成し、同時にJSFアプリケーションに登録できます。

始める前に:

マネージドBeanの作成で使用可能な各オプションを理解しておくと役立ちます。詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

また、マネージドBeanに使用可能な追加機能についても理解しておくと役立ちます。詳細は、「ページ・テンプレートおよびマネージドBeanの追加機能」を参照してください。

次のタスクを完了する必要があります。

- マネージドBeanを関連付けるための構成ファイルを作成します(存在しない場合)。これには、faces-config.xml、adfc-config.xmlまたはバインド・タスク・フロー定義ファイルを使用できます。

adfc-config.xmlまたはタスク・フローのマネージドBeanを作成するには:

1. 「アプリケーション」ウィンドウで、adfc-config.xmlファイルまたはその他のタスク・フロー定義ファイルをダブルクリックします。

2. 概要エディタで、「マネージドBean」ナビゲーション・タブをクリックします。図29-3はadfc-config.xmlファイルのエディタを示しています。

図29-3 adfc-config.xmlファイルのマネージドBean

3. 「マネージドBean」ページで、「マネージドBean」表に行を追加するには、「追加」アイコンをクリックします。

4. フィールドに次のように入力します。

- 名前: Beanの名前。

- クラス: Beanに対応するクラスがすでに作成されている場合、managed-bean-classフィールドの参照(...)ボタンを使用してクラスを検索し、選択します。クラスが存在しない場合、使用する名前を入力します。同様に、すべてのパッケージ名が含まれていることを確認してください。その後、ドロップダウン・メニューを使用して「クラスの生成」を選択すると、Javaファイルが自動的に作成されます。

- スコープ: このBeanのスコープ。様々なオブジェクト・スコープの詳細は、「オブジェクト・スコープ・ライフサイクルについて」を参照してください。

注意:

マネージドBeanの登録または値の格納に使用するスコープを決める際には、次に留意してください。

- 常に、できるかぎり狭いスコープを使用すること。

- 使用するマネージドBeanが、コンポーネント・インスタンスを受け入れて戻すことでコンポーネント・バインディングに関与する場合(つまり、ページ上のUIコンポーネントがbinding属性を使用してBean上のコンポーネント・プロパティにバインドされる場合)、そのマネージドBeanをBackingBeanスコープに格納する必要があります。これらのスコープのいずれかに格納できない(たとえば、高可用性のためにsessionScopeに格納する必要がある)場合は、コンポーネント・バインディングを使用するかわりにComponentReference APIを使用する必要があります。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のコンポーネント・バインディングおよびマネージドBeanに関する必知事項に関する項を参照してください

- sessionScopeスコープは、ユーザー情報やコンテキスト情報などのセッション全体に関係する情報にのみ使用します。あるページから別のページへの値の受渡しには、sessionScopeスコープは使用しないようにします。

- スコープをnoneに設定することもできます。厳密にはスコープではありませんが、noneは、そのBeanが特定のスコープ内に存在するのではなく、参照されるたびにインスタンス化されることを意味します。別のBeanによって参照される場合は、Beanのスコープをnoneに設定する必要があります。

5. Beanに必要なプロパティをオプションで追加できます。「Managed Bean」表でBeanを選択し、「管理プロパティ」表の「追加」アイコンをクリックします。プロパティ名を入力します(他のフィールドはオプションです)。

注意:

このエディタを使用して管理プロパティを宣言することはできますが、対応するコードはJavaクラスで生成されません。このコードを追加するために、適切なタイプのプライベート・メンバー・フィールドを作成し、ソース・エディタのポップアップ・メニューの「アクセッサの生成」メニュー項目を使用して、これらのBeanプロパティに対応するgetterメソッドおよびsetterメソッドを生成する必要があります。

29.4.2 マネージドBeanの作成時に行われる処理

構成エディタを使用してマネージドBeanを作成し、Javaファイルの生成を選択すると、JDeveloperによって、指定された名前のスタブ・クラスおよびデフォルトのコンストラクタが作成されます。次の例に、ビュー・パッケージに格納されたMyBeanクラスに追加されるコードを示します。

package view;

public class MyBean {
public MyBean() {
}
}

この時点で、タスク・フローまたはページによって要求されるロジックを追加する必要があります。その後、マネージドBeanに対して指定されたmanaged-bean-name値を参照するEL式を使用して、そのロジックを参照できます。たとえば、BeanのmyInfoプロパティにアクセスする場合のEL式は、次のようになります。

#{my_bean.myInfo}

また、JDeveloperによってmanaged-bean要素が適切なタスク定義ファイルに追加されます。次は、MyBeanクラスに対して作成されたmanaged-bean要素を示しています。

<managed-bean>
<managed-bean-name>my_bean</managed-bean-name>
<managed-bean-class>view.MyBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

29.4.3 サーバー/クラスタ環境でのマネージドBeanメモリー・スコープの設定方法

通常、クラスタ環境で実行されるアプリケーションでは、アプリケーションの状態がクラスタ内の他のサーバーで使用できるように、各リクエストの最後にその状態がシリアライズされ、別のサーバーまたはデータ・ストアにコピーされます。

注意:

ADF Facesコンポーネントはシリアライズ可能でないため、マネージドBeanによってADF Facesコンポーネントのsetおよびgetメソッドがコールされる場合は、マネージドBeanをシリアライズできません。別の方法でADF Facesコンポーネントにアクセスする必要があります。

クラスタ環境で実行するようにアプリケーションを設計している場合は、次の点が必要です。

- 存続期間が1つのリクエストより長いマネージドBeanは、すべてシリアライズ可能にします(つまり、java.io.Serializableインタフェースを実装します)。具体的には、セッション・スコープ、ページ・フロー・スコープおよびビュー・スコープに格納されているBeanは、シリアライズ可能である必要があります。

ヒント:

ページ・フロー・スコープおよびビュー・スコープに格納されているオブジェクトでの失敗を識別するには、writeObject()を使用します。このメソッドにより、シリアライズに失敗したオブジェクトおよびスコープに関する例外の追加情報が提供されます。追加情報は、リージョンのページ・フロー・スコープおよびオブジェクトのキーなどの可能性があります。

- ADFスコープ(ビュー・スコープおよびページ・フロー・スコープ)に格納されるマネージドBeanへの変更がフレームワークで認識されるようにします。

ビュー・スコープとページ・フロー・スコープのいずれかで、マネージドBean内の値が変更された場合には、アプリケーションがフレームワークに通知して、Beanの新しい値がレプリケートされるようにする必要があります。

この例では、ビュー・スコープ内のオブジェクトの属性が変更されます。

Map<String, Object> viewScope =
AdfFacesContext.getCurrentInstance().getViewScope();
MyObject obj = (MyObject)viewScope.get("myObjectName");
Obj.setFoo("newValue");

コードを追加しないかぎり、この変更はフレームワークに通知されないため、新しい値をクラスタ内でレプリケートする必要があることも認識されません。ADFスコープ内のオブジェクトが変更されたためにレプリケーションが必要であることをフレームワークに通知するには、次の例に示すように、markScopeDirty()メソッドを使用します。markScopeDirty()メソッドは、viewScopeおよびpageFlowScopeのみをパラメータとして受け入れます。

ControllerContext ctx = ControllerContext.getInstance();
ctx.markScopeDirty(viewScope);

このコードは、ADFスコープのいずれかにある既存のオブジェクトを変更するリクエストに対して必要になります。スコープ自体がスコープのput()、remove()またはclear()メソッドによって変更された場合は、フレームワークに通知する必要はありません。

アプリケーションをクラスタ環境にデプロイしない場合、ADFメモリー・スコープに対する変更を追跡する必要はなく、デフォルトでこの機能は無効になっています。サーバー・クラスタ内において、ADF ControllerでADFメモリー・スコープに対する変更を追跡し、ページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、adf-config.xmlファイルの<adf-scope-ha-support>パラメータをtrueに設定します。スコープのレプリケーションでは小さいパフォーマンス・オーバーヘッドが生じるため、サーバー/クラスタ環境でアプリケーションを実行する場合にかぎり、この機能を有効にしてください。

次は、adf-config.xmlファイルでtrueに設定されたadf-scope-ha-supportを示しています。

<?xml version="1.0" encoding="US-ASCII" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:adfc="http://xmlns.oracle.com/adf/controller/config">
<adfc:adf-controller-config>
...
<adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support>
...
</adfc:adf-controller-config>
...
</adf-config>

30 Fusionページ・ライフサイクルの理解

この章では、ADFページ・ライフサイクルとそのフェーズ、Fusion Webアプリケーション内でのライフサイクルの最適な使用方法について説明します。

この章の内容は次のとおりです。

- Fusionページ・ライフサイクルについて

- JSFページ・ライフサイクルとADFページ・ライフサイクルについて

- オブジェクト・スコープ・ライフサイクルについて

- ADFページ・ライフサイクルのカスタマイズ

30.1 Fusionページ・ライフサイクルについて

JSFページが送信され、新しいページがリクエストされると、JSFページ・リクエスト・ライフサイクルが起動されます。このライフサイクルでは、ページの値の送信、現在のページのコンポーネントの検証、コンポーネントのナビゲーションと結果ページへの表示および状態の保存とリストアが処理されます。JSFライフサイクル・フェーズでは、UIコンポーネント・ツリーを使用してコンポーネントの表示を管理します。このツリーはJSFページのランタイム表現で、ページ内の各UIコンポーネント・タグがツリーのUIコンポーネント・インスタンスに対応します。

FacesServletオブジェクトで、JSFアプリケーションのページ・リクエスト・ライフサイクルが管理されます。FacesServletオブジェクトで、リクエスト処理に必要な情報を含み、ライフサイクルを実行するオブジェクトを起動するFacesContextと呼ばれるオブジェクトが作成されます。

JSFライフサイクルのほかに、ADF FacesおよびADFページ・ライフサイクルも実行されます。ただし、ADF FacesライフサイクルではJSFライフサイクルが拡張され、クライアント側の値のライフサイクル、1つのページに複数のフォームを使用する弊害(ユーザーの編集内容の消失など)なしに独立して送信可能なセクションをページに作成できるサブフォーム・コンポーネント、追加スコープなどの追加機能を提供します。アプリケーションのライフサイクルで実行できる機能を含む、JSFライフサイクルとADF Facesライフサイクル両方の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ADF FacesでのJSFライフサイクルの使用」を参照してください。

ADFページ・ライフサイクルは、データ・モデルの準備と更新、モデル・レイヤーでのデータの検証、ビジネス・レイヤーでのメソッドの実行を処理します。ADFページ・ライフサイクルでは、バインディング・コンテナを使用して、現在のページ・リクエスト時にページによる簡単なデータ参照を可能にします。

組み合せたJSFページ・ライフサイクルとADFページ・ライフサイクルは、アプリケーション・サーバーにHTTPリクエストが届いたときに始まってページがクライアントに戻されるまで続く、より大規模なイベント・シーケンスに含まれる1つのシーケンスにすぎません。このイベント・シーケンス全体をWebページ・ライフサイクルと呼びます。このライフサイクルは、MVCアーキテクチャで定義されているようにモデル、ビュー、コントローラのレイヤーを通して処理をたどっていきます。ページ・ライフサイクルは厳格に定義されたイベント・セットではなく、一般的なユースケースで使用されるイベント・セットです。図30-1に、JSFとOracle ADFを併用した場合のWebページ・リクエストのライフサイクルのシーケンス図を示します。

図30-1 JSFおよびOracle ADFを使用したWebページ・リクエストのライフサイクル

JSFおよびOracle ADFを使用したWebページ・リクエストの処理の基本的なフローは、次のようになります。

1. http://yourserver/yourapp/faces/some.jspに対するWebリクエストが、クライアントからアプリケーション・サーバーに到着します。

2. ADFBindingFilterオブジェクトが、HTTPセッション内でADFバインディング・コンテキストを検索し、それがまだ存在しない場合はその初期化を初めて実行します。ADFBindingFilterの機能には、バインディング・コンテキスト・メタデータ・ファイルの名前の検索、各データ・コントロールの検索と構築などがあります。

3. ADFBindingFilterオブジェクトが、該当するリクエストに関与する各データ・コントロールに対してbeginRequest()メソッドを起動します。このメソッドにより、データ・コントロールは各リクエストの開始時に通知を受けるため、必要な設定を実行できるようになります。

4. JSF Lifecycleオブジェクト(各リクエストの標準的な処理フェーズの調整を行う)が、ライフサイクルの各フェーズでADFPhaseListenerクラスに通知し、JSFライフサイクルとADFモデル・データ・バインディング・レイヤーを調整するためのカスタムな処理が実行できるようにします。JSFページ・ライフサイクルとADFページ・ライフサイクルのフェーズの詳細は、「JSFページ・ライフサイクルとADFページ・ライフサイクルについて」を参照してください。

注意:

FacesServletクラス(javax.faces.webapp内)は、JSFアプリケーションのweb.xmlファイル内で構成され、各リクエストを処理するためのJSF Lifecycleクラス(javax.faces.lifecycle内)を最初に作成します。ただし、FacesServletクラスは、該当する処理をすべて実行するLifecycleクラスであるため、図に示していません。

5. ADFPhaseListenerオブジェクトが、各リクエストを処理するためのADF PageLifecycleオブジェクトを作成し、該当するフェーズ前後のメソッドをADF PageLifecycleクラス内の対応メソッドに委譲します。ページのバインディング・コンテナは、ユーザーのセッション中、以前に使用されていない場合は作成されます。

6. アプリケーション・モジュール・データ・コントロールが、リクエスト時に初めて参照されると、アプリケーション・モジュール・プールからアプリケーション・モジュールのインスタンスを取得します。

7. JSF Lifecycleオブジェクトが、レンダリング対象のページにコントロールを移動します。

8. 該当するページ上の一連のUIコンポーネントが、該当ページのバインディング・コンテナ内の値バインディングおよびイテレータ・バインディングにアクセスし、フォーマット設定された出力をレンダリングしてブラウザに表示します。

9. ADFBindingFilterオブジェクトが、該当するリクエストに関与する各データ・コントロールに対してendRequest()メソッドを起動します。このメソッドにより、データ・コントロールは各リクエストの終了時に通知を受けるため、必要なリソースのクリーンアップを実行できるようになります。

10. アプリケーション・モジュール・データ・コントロールがendRequestの通知を使用して、アプリケーション・モジュール・プールにアプリケーション・モジュールのインスタンスを解放して戻します。

11. 得られたページが、ユーザーのブラウザに表示されます。

ADFページ・ライフサイクルには、対応するJSFフェーズの実行前後にADFページ・ライフサイクル・リスナーに通知するためのみに定義されたフェーズも含まれています(これらのフェーズは実装されていません)。これらのフェーズにより、カスタム・リスナーを作成してJSFページ・ライフサイクルとADFページ・ライフサイクルの両方のフェーズに登録できるため、必要に応じてグローバルに、またはページ・レベルでADFページ・ライフサイクルをカスタマイズできるようになります。

30.2 JSFページ・ライフサイクルとADFページ・ライフサイクルについて

図30-2に、JSFページ・ライフサイクルとADFページ・ライフサイクルを組み合せた概要を示します。

図30-2 JSFページ・ライフサイクルとADFページ・ライフサイクル

たとえば、テキストが表示された入力テキスト・コンポーネントおよびボタンからなるページがあるとします。このページが初めてレンダリングされるとき、ビューのリストア・フェーズ中にコンポーネント・ツリーが構築され、コンポーネントのレンダリング中、ライフサイクルはレスポンスのレンダリング・フェーズまで進みますユーザーがボタンをクリックすると、完全なライフサイクルが起動されます。リクエスト値の適用フェーズおよび検証処理フェーズ中、コンポーネント・ツリーが再構築され、入力テキスト・コンポーネントではすべての新規値が抽出されます。エラーが発生した場合は(検証によるエラーなど)、ライフサイクルはレスポンスのレンダリング・フェーズにまで進みます。それ以外の場合は、モデルの更新フェーズ中にモデルが新規値によって更新され、アプリケーションの起動フェーズ中、ボタンに関連付けられたすべてのアプリケーション処理(ナビゲーションなど)が実行されます。

図30-3は、JSF、ADF Faces、ADFモデル・フェーズがページ・リクエストのライフサイクルの中で統合されるしくみの詳細を示しています。

図30-3 Fusion Webアプリケーションでのページ・リクエストのライフサイクル

ADFモデルを使用するJSFアプリケーションでは、ページ・ライフサイクルのフェーズは次のようになります。

- ビューのリストア: リクエストされたページのURLがbindingContextオブジェクトに渡され、URLと一致するページ定義が検索されます。リクエストされたページのコンポーネント・ツリーが、新しく作成されるかリストアされます。送信されたページ上のすべてのコンポーネント・タグ、イベント・ハンドラ、コンバータおよびバリデータは、FacesContextインスタンスにアクセスできます。コンポーネント・ツリーが空の場合(つまり、送信されたページからのデータがない)は、ページ・ライフサイクルは直接レスポンスのレンダリング・フェーズに進みます。
リクエスト状態とサーバー側の状態の間で不一致が検出された場合、エラーがスローされ、ページ・ライフサイクルはレスポンスのレンダリング・フェーズに進みます。

- JSFのビューのリストア: ビューのリストア・フェーズに対して、フェーズ前後のイベントを提供します。リスナーを作成してこのフェーズの前または後のイベントに登録すると、リスナーをビューのリストア・フェーズに登録したときのように、アプリケーションが動作します。ADFモデル・ページ・ライフサイクルのコンテキストの初期化フェーズでは、after(JSF Restore View)イベントをリスニングして実行します。ADF Controllerは、このフェーズの前後のイベントのリスナーを使用して、サーバー側の状態をリクエストと同期させます。たとえば、ブラウザの「戻る」ボタンの検出およびブックマーク参照などは、このフェーズで処理されます。前後のリスナーの実行後、ページ・フロー・スコープが使用可能になします。

- コンテキストの初期化: リクエストされたページのページ定義ファイルの実行時表現であるbindingContainerオブジェクトが、ページ定義ファイルを使用して作成されます。ADFページ・ライフサイクルの全フェーズで情報を保持するためのLifecycleContextクラスがインスタンス化され、関連付けられているリクエスト、バインディング・コンテナおよびライフサイクルの値で初期化されます。

- モデルの準備: ADFページ・ライフサイクルは、BindingContainer.refresh(PREPARE_MODEL)メソッドをコールすることにより、モデルの準備フェーズを開始します。モデルの準備フェーズでは、BindingContainerページ・パラメータが準備された後、評価されます。タスク・フローにパラメータが存在する場合、パラメータはフローに渡されます。
次に、RefreshプロパティがprepareModelに設定された実行可能ファイルが、ページ定義ファイルの<executables>セクション内のエントリの順序と、それらのRefreshConditionプロパティ(存在する場合)の評価に基づいてリフレッシュされます。実行可能ファイルがイテレータ・バインディング・リフレッシュに到達すると、対応するデータ・コントロールが実行され、それによってサービス・オブジェクト内の1つ以上のコレクションが実行されます。イテレータ・バインディングがリフレッシュに失敗すると、JBO例外がスローされ、データを表示できなくなります。RefreshConditionプロパティの詳細は、「pageNamePageDef.xml」を参照してください。

受信リクエストにPOSTデータまたは問合せパラメータが含まれていない場合、ライフサイクルはレスポンスのレンダリング・フェーズに進みます。

ページがテンプレートを使用して作成されており、そのテンプレートにADFモデルを使用したバインディングが含まれている場合、テンプレートのページ定義ファイルを使用してテンプレートのバインディング・コンテナが作成されます。コンテナがバインディング・コンテキストに追加されます。

taskFlow実行可能バインディングが存在する(ページにリージョンが含まれているなど)場合、taskFlowバインディングによりADFコントローラのViewPortContextオブジェクトがタスク・フローに作成された後、フローにあるページのネストされたバインディング・コンテナが実行されます。

- リクエスト値の適用: ツリー内の各コンポーネントにより、リクエスト・パラメータから(そのデコード・メソッドを使用して)新しい値が抽出され、ローカルに格納されます。関連付けられているほとんどのイベントは、後の処理のためにキューされます。コンポーネントのimmediate属性がtrueに設定されている場合は、コンポーネントに関連付けられている検証、変換およびイベントがこのフェーズで処理され、ライフサイクルは検証処理フェーズ、モデル値の更新フェーズ、アプリケーションの起動フェーズをスキップします。さらに、関連イテレータが起動されます。ADF Facesの検証と変換の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「入力の検証および変換」を参照してください。

- JSFのリクエスト値の適用: リクエスト値の適用フェーズに対して、フェーズ前後のイベントを提供します。リスナーを作成してこのフェーズの前または後のイベントに登録すると、リスナーをリクエスト値の適用フェーズに登録したときのように、アプリケーションが動作します。

- 検証処理: クライアントでコンポーネントのローカルの値が変換され、検証されます。エラーが発生した場合は、ライフサイクルがレスポンスのレンダリング・フェーズに進みます。このフェーズの最後に、コンポーネントの新しい値が設定され、検証または変換のエラー・メッセージおよびイベントがFacesContextでキューされて、すべての値変更イベントが配信されます。例外もバインディング・コンテナにより捕捉されてキャッシュされます。

- JSFの検証処理: 検証処理フェーズに対して、フェーズ前後のイベントを提供します。リスナーを作成してこのフェーズの前または後のイベントに登録すると、リスナーを検証処理フェーズに登録したときのように、アプリケーションが動作します。

- モデル値の更新: コンポーネントの検証済のローカル値がモデルに移され、ローカル・コピーが破棄されます。更新可能なコンポーネント(inputTextコンポーネントなど)については、リフレッシュ条件がデフォルト(deferred)に設定され、リフレッシュ条件(該当する場合)がtrueに評価されている場合、対応するイテレータがリフレッシュされます。
JSFページのバッキングBeanを使用してUIコンポーネントを管理する場合、バッキングBeanプロパティにバインドされているUI属性もこのフェーズでリフレッシュされます。

- JSFのモデル値の更新: モデル値の更新フェーズに対して、フェーズ前後のイベントを提供します。リスナーを作成してこのフェーズの前または後のイベントに登録すると、リスナーをモデル値の更新フェーズに登録したときのように、アプリケーションが動作します。

- モデル更新の検証: モデルに設定された検証ルーチンと比較して、更新されたモデルが検証されます。例外がバインディング・コンテナにより捕捉されてキャッシュされます。

- アプリケーションの起動: コマンド・コンポーネントまたはイベントのアクション・バインディングが起動されます。

- JSFのアプリケーションの起動: アプリケーションの起動フェーズに対して、フェーズ前後のイベントを提供します。リスナーを作成してこのフェーズの前または後のイベントに登録すると、リスナーをアプリケーションの起動フェーズに登録したときのように、アプリケーションが動作します。

- メタデータのコミット: 実行時メタデータへの変更がコミットされます。 このフェーズでは、メタデータ・サービス(MDS)を使用して、実行時にアプリケーションに対して行われるあらゆる変更が格納されます。MDSを使用した実行時の変更の保持の詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。

- 内容の初期化(アプリケーションの起動ライフサイクルでナビゲーションが発生した場合のみ): 実行されるbeforeJSFRenderResponseイベントをリスニングします。次のページのページ定義ファイルが初期化されます。

- モデルの準備(アプリケーションの起動ライフサイクルでナビゲーションが発生した場合のみ): 次のページの定義に含まれるすべてのページ・パラメータが設定されます。

- レンダリングの準備: バインディング・コンテナがリフレッシュされ、リクエスト値の適用フェーズまたは検証フェーズで発生したすべての変更が反映されます。読取り専用コンポーネント(outputTextコンポーネントなど)に対応するイテレータがリフレッシュされます。必要な場合は、すべての動的リージョンが切り替わります。afterJSFRenderResponseイベントのように、登録されたすべてのリスナーにprepareRenderイベントが送信されます。

注意:

選択する有効フェーズとして、JDeveloperではprepareRenderではなくrenderModelが表示されます。これは、バインディング・コンテナでコールされるrefresh(RENDER_MODEL)メソッドを表します。

- レスポンスのレンダリング: Java EE Webコンテナがページ内のタグを横断するにつれて、ツリー内のコンポーネントがレンダリングされます。後続のリクエストおよびビューのリストア・フェーズ用に、状態の情報が保存されます。
ページと関連データの両方を表示するのに必要な待機時間を短くするため、特定のADF Facesコンポートネント(tableコンポーネントなど)では、最初のリクエストにデータ・ストリーミングを使用します。ページにこれらのコンポーネントが1つ以上含まれる場合、ページは通常のライフサイクルをたどります。しかし、そのリクエスト時にデータをフェッチするかわりに、特別な別のリクエストが実行されます。ページは単にレンダリングされるだけなので、データ・ストリーミングを使用するコンポーネントに対してレスポンスのレンダリング・フェーズのみが実行され、対応するデータがフェッチされ、表示されます。ユーザーのアクション(表でのスクロールなど)によって次のデータのフェッチが発生する場合は、別のリクエストが実行されます。表、ツリー、ツリー表などのコレクションベースのコンポーネントおよびデータ視覚化のコンポーネントはすべて、データ・ストリーミングを使用します。

- JSFのレスポンスのレンダリング: レスポンスのレンダリング・フェーズに対して、フェーズ前後のイベントを提供します。リスナーを作成してこのフェーズの前または後のイベントに登録すると、リスナーをレスポンスのレンダリング・フェーズに登録したときのように、アプリケーションが動作します。

30.2.1 部分ページ・レンダリングおよびイテレータ・バインディングに関する必知事項

ADF Facesには、ページ上の特定のコンポーネント(通常は値が変更されたコンポーネント)にのみページ・リクエスト・ライフサイクル(変換と検証を含む)を実行する場合に使用できる、最適化されたライフサイクルが用意されています。

最適化されたライフサイクルを使用する方法の1つは、一方のコンポーネントのイベントが、もう一方のコンポーネント(ターゲット)のトリガーとして機能するように、依存性を手動で設定する方法です。トリガー・コンポーネントでイベントが発生すると、ターゲット・コンポーネントと、トリガーおよびターゲットの両方の子コンポーネントでライフサイクルが実行され、これらのコンポーネントのみがレンダリングされます。これは、部分ページ・レンダリング(PPR)とみなされます。

次の例は、トリガーの役割を果たすラジオ・ボタンと、ターゲットとなる出力テキストを保持するpanelGroupLayoutコンポーネントを示しています(outputTextコンポーネントは常時レンダリングされるわけではないため、panelGroupLayoutコンポーネントをターゲットとする必要があります)。

<af:form>
<af:inputText label="Required Field" required="true"/>
<af:selectBooleanRadio id="show" autoSubmit="true" text="Show"
value="#{validate.show}"/>
<af:selectBooleanRadio id="hide" autoSubmit="true" text="Hide"
value="#{validate.hide}"/>
<af:panelGroupLayout partialTriggers="show hide" id="panel">
<af:outputText value="You can see me!" rendered="#{validate.show}"/>
</af:panelGroupLayout>
</af:form>

ラジオ・ボタンのautoSubmit属性がtrueに設定されているため、選択されると、SelectionEventが起動されます。panelGroupLayoutコンポーネントが両方のラジオ・コンポーネントのターゲットとして設定されているため、このイベントが起動されると、selectOneRadio(トリガー)、panelGroupLayoutコンポーネント(トリガーのターゲット)とその子コンポーネント(outputTextコンポーネント)のみ、ライフサイクルの処理が行われます。outputTextコンポーネントは表示ラジオ・ボタンの選択時にのみレンダリングされるよう構成されているため、ユーザーは、ラジオ・ボタンの上の必須入力フィールドにテキストを入力しなくても、ラジオ・ボタンを選択して出力テキストを表示できます。

部分トリガーとターゲットをコード内で手動で設定するかわりに、ADF Facesフレームワークには自動PPRが用意されています。自動PPRは、イベントに対応するイベント・ルート・コンポーネントが存在する場合、またはコンポーネント自体がイベント・ルートである場合に実行されます。イベント・ルート・コンポーネントにより、PPRの境界が決定されます。たとえば、attributeChangeEventはイベントを起動させるinputTextコンポーネントを、そのイベント・ルートであるとみなします。したがって、前述の例では、inputTextコンポーネントの値が変更されると、これがPPRの最初の境界であるため、inputTextコンポーネントとそのすべての子コンポーネント上のみでライフサイクルが実行されます。

イベント・ルートのほか、Fusion Webアプリケーションではデフォルトで、同一のイテレータ・バインディングに関連付けられたすべてのUIコンポーネントに対しても自動PPRが実行されます。関連付けられたすべてのコンポーネントは、そのいずれかで値変更イベントが発生するたびに、すべてリフレッシュされます。この機能は、イテレータのchangeEventPolicy属性をpprに設定することで制御します。デフォルトでは、これはグローバルに設定されています。

たとえば、「データ・コントロール」パネルを使用して多数のinputTextコンポーネントを作成するとします(フォームを作成する場合など)。これらのinputTextコンポーネントのいずれかでattributeChangeEventが発生すると、他のinputTextコンポーネントも同一のイテレータに関連付けられているため、これらすべてのinputTextコンポーネントがリフレッシュされます。

もう1つの例として、panelSplitterコンポーネントを含むページがあるとします。スプリッタの左側は新規顧客を作成するためのフォーム(Customerコレクションを使用してフォームをドロップして作成)であり、スプリッタの右側にはフォームの用法の説明文が表示されています。フォームを構成する各inputTextコンポーネントのバインディングは、すべてCustomerイテレータに関連付けられているため、フォームが送信され、いずれかのinputTextコンポーネントの値が変更されるたびに、Customerに関連付けられているinputTextコンポーネントのみがライフサイクル処理されます。スプリッタ右側の説明文を含め、ページの残りの部分はリフレッシュされません。

注意:

自動PPRを実行するには、イベントおよびイベント・ルート・コンポーネントが『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のイベントおよび部分ページ・レンダリングに関する項の表5-1にリストされている必要があります。リストされていない場合は、同ガイドの、部分トリガーの使用に関する項を参照して、PPRを手動で設定する必要があります。

たとえば、同一のデータ・コントロール・コレクションに基づきフォームと表を作成するとします。フォームにはデータ行の詳細が表示され、表にはコレクション内のすべての行が表示されます。フォーム内で現在表示されている行は、表内でも選択された状態で表示されます。フォームの「次へ」ボタンがクリックされたときに、新たな行が選択された状態に表を更新させる必要があります。選択イベントは自動PPRによってサポートされないため、表とフォームは同一のイテレータを使用しているにもかかわらず、表はリフレッシュされません。ターゲットの表に対するPPRのトリガーとして、「次へ」および「前へ」ボタンを設定する必要があります。

注意:

構成済イテレータに関連付けられたページ定義ファイル内でコントロール・バインディングが定義されているUIコンポーネントのみが、リフレッシュされます。

マネージドBeanからイテレータに直接アクセスし、このBeanを介してイテレータの値をUIコンポーネントに公開する場合は、これらのUIコンポーネントに対して自動PPRは実行されません。この場合は、PPRを手動で構成する必要があります。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の部分トリガーの使用に関する項を参照してください。

デフォルトでは、すべての新規アプリケーションではグローバルPPRが使用されます。設定する必要はありません。ただし、ページに対するページ定義ファイル内で、この設定をオーバーライドできます。

始める前に:

部分ページ・レンダリングに関する知識が役立つ場合があります。詳細は、「部分ページ・レンダリングおよびイテレータ・バインディングに関する必知事項」を参照してください。

PPRを使用するようにイテレータ・バインディングを設定するには:

1. 特定のイテレータ・バインディングに対し、PPRを使用するように、または使用しないように設定するには、関連付けられたページ定義ファイルを開き、イテレータを選択して、「プロパティ」ウィンドウ内でChangeEventPolicyを設定します。

2. すべてのイテレータ・バインディングがPPRを使用するように設定するには:

a. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開き、「adf-config.xml」をダブルクリックします。

b. 概要エディタで「モデル」ナビゲーション・タブをクリックし、「デフォルトの変更イベント・ポリシーはPPRです」を選択します。

ADF FacesフレームワークでのPPRの使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

30.2.2 タスク・フローとライフサイクルに関する必知事項

タスク・フローは、(ページに関連付けられている)親バインディング・コンテナのリフレッシュ時に初めてリフレッシュされます。これはモデルの準備フェーズで発生します。後続のリクエストでは、レンダリングの準備フェーズにおいて、refreshおよびrefreshCondition属性とそのパラメータ値に基づいてタスク・フローがリフレッシュされます。

注意:

子ページ・フラグメントのページ定義は、引き続き子ページ・フラグメントのバインディングのリフレッシュを処理します。

ヒント:

最初は公開されないリージョン(ポップアップ・ダイアログなど)がページ上にある場合、リージョンが表示されなくても、親ページのレンダリング時にパラメータは使用可能である必要があります。リージョンにパラメータが必要であるにもかかわらず、これらのパラメータ値を親ページのレンダリング時に使用できない場合は、動的リージョンを使用する必要があります。パラメータがNULLの場合、リージョンのパラメータの準備が完了してリージョンを表示できるようになるまで、空のタスク・フローを使用できます。空のタスク・フローに切り替えるには、動的リージョンのtaskFlowId属性を空の文字列に設定します。

EL式をrefreshCondition属性の値として設定した場合、ライフサイクルのレンダリングの準備フェーズ中に評価されます。式がtrueに評価されると、タスク・フローは再度リフレッシュされます。refreshConditionがfalseに評価されると、refreshConditionが指定されていない場合と動作は同じです。

注意:

EL式でbindings変数が使用されていると、リージョン内に表示されるページ・フラグメントではなく、親ページのバインディング・コンテナが参照されます。

タスク・フロー実行可能ファイルのrefreshプロパティの有効な値は次のとおりです。

- default: 親ページが最初に表示されるときに、リージョンは1回のみリフレッシュされます。

- ifNeeded: taskFlowバインディングのパラメータ値に変更があった場合のみ、リージョンがリフレッシュされます。taskFlowバインディングにパラメータがない場合、ifNeededはデフォルトと同じです。ifNeededを使用した場合、refreshCondition属性は考慮されません。

注意:

refresh属性をifNeededに設定した場合は、refreshCondition属性のいずれの値よりも優先されます。また、動的パラメータMapを使用してtaskFlowバインディングにパラメータを渡す場合、ifNeededはサポートされません。その場合は、refreshCondition="#{EL.Expression}"を使用します。

taskFlowバインディングによる唯一の処理はそのパラメータのリフレッシュであり、Refreshをalwaysに設定する意味はありません。taskFlowバインディングのパラメータが変更されないかぎり、ADFリージョンをリフレッシュする理由はありません。

子ページ・フラグメントのページ定義は、引き続き子ページ・フラグメントのバインディングのリフレッシュを処理します。

30.3 オブジェクト・スコープ・ライフサイクルについて

実行時には、バインディング・コンテナおよびマネージドBeanなどのADFオブジェクトはインスタンス化されています。これらのオブジェクトにはそれぞれ、そのスコープ属性により設定された存続期間が定義されています。RequestContext APIからjava.util.Mapとしてスコープにアクセスできます。たとえば、リクエスト・スコープのfooというオブジェクトにアクセスするには、式#{requestScope.foo}を使用します。

オブジェクト・スコープは、プログラミング言語のグローバル変数およびローカル変数のスコープに相当します。スコープが広いほど、オブジェクトの可用性が高くなります。オブジェクトの存続期間中、これらのオブジェクトによってあるインタフェースが公開され、情報が保持され、あるいは変数およびパラメータが他のオブジェクトに渡されます。たとえば、セッション・スコープで定義されたマネージドBeanは、ページ・リクエストが複数存在する場合に使用できます。ただし、リクエスト・スコープで定義されたマネージドBeanは、1つのページ・リクエストが継続する間のみ使用できます。

Fusion Webアプリケーションには次の6種類のスコープがあります。

- アプリケーション・スコープ: オブジェクトは、アプリケーションが継続する間使用できます。

- セッション・スコープ: オブジェクトは、セッションが継続する間使用できます。

注意:

セッション・スコープにはウィンドウの一意性はなく、セッション内のすべてのウィンドウは、同じセッション・スコープ・インスタンスを共有します。複数のウィンドウが同じオブジェクトにアクセスできることが不適切な場合(たとえば、ウィンドウ間でマネージドBeanが競合しないようにする場合)は、ページ・フロー・スコープやビュー・スコープなどのウィンドウ固有のスコープを使用する必要があります。

- ページ・フロー・スコープ: このオブジェクトは、タスク・フローの継続期間中、利用できます。その名のとおり、ページ・フロー・スコープは、タスク・フロー(バインドまたはバインドなし)のインスタンスに固有です。したがって、(タスク・フローによって作成された)2つ以上のリージョンを含むページがある場合、ページ・フロー・スコープの別のインスタンスが各リージョンに対して存在します。また、ユーザーが別のブラウザ・タブでリージョンを含むページを開く場合、ページ・フロー・スコープの別のインスタンスが各ブラウザ・タブに対してインスタンス化されます。

注意:

これは標準JSFスコープではないため、Beanを参照するためのスコープをEL式に明示的に含める必要があります。たとえば、pageFlowScopeスコープからMyBeanマネージドBeanを参照するには、#{pageFlowScope.MyBean}という式になります。

- リクエスト・スコープ: オブジェクトは、HTTPリクエストが作成された時点からレスポンスがクライアントに戻されるまで使用できます。

- バッキングBeanスコープ: ページ・フラグメントおよび宣言コンポーネントのみのマネージドBeanに使用されます。このオブジェクトは、HTTPリクエストが発生してからレスポンスがクライアントに返送されるまでの間、利用できます。1つのページに複数のページ・フラグメントまたは宣言コンポーネントが含まれる場合があり、競合を避けるには別々のスコープ・インスタンスに値を保持する必要があるため、フラグメントおよび宣言コンポーネントにはこのスコープが必要です。したがって、すべてのページ・フラグメントまたは宣言コンポーネントのマネージドBeanで、バッキングBeanスコープを使用する必要があります。

注意:

これは標準JSFスコープではないため、Beanを参照するためのスコープをEL式に明示的に含める必要があります。たとえば、バッキングBeanスコープからMyBeanマネージドBeanを参照する場合の式は、#{backingBeanScope.MyBean}になります。

- ビュー・スコープ: このオブジェクトは、現在のビュー・アクティビティのビューIDが変更されるまで利用できます。このスコープは、所定のページの値を保持するために使用できます。ただし、1つのページから次のページに必要な値を格納するために使用できるリクエスト・スコープとは異なり、ビュー・スコープに格納されたものはビューIDの変更とともに失われます。

注意:

JSFおよびADF Facesはいずれも、ビュー・スコープを実装しています。ADF Facesのビュー・スコープのみが、ページのリダイレクトおよびリフレッシュの後も維持されます。Fusion Webアプリケーションでは、式でviewScopeを使用すると、ADF Facesビュー・スコープに解決されます。

このビュー・スコープは標準JSFスコープではないため、Beanを参照するためのスコープをEL式に明示的に含める必要があります。たとえば、ビュー・スコープからMyBeanマネージドBeanを参照する場合の式は、#{viewScope.MyBean}になります。

注意:

スコープを定義する必要があるオブジェクト(マネージドBeanなど)を作成する場合、スコープをnoneに設定できます。これは、このオブジェクトが特定のスコープ内には存在しないが参照されるたびにインスタンス化されることを意味します。

デフォルトでは、バインディング・コンテナおよびそれに含まれるバインディング・オブジェクトは、セッション・スコープで定義されます。ただし、値バインディングおよびイテレータ・バインディングによって参照される値はリクエスト間で定義されず、スケーラビリティ上の理由により、セッション・スコープに残りません。このため、バインディング・オブジェクトが参照する値は、そのバインディング・コンテナがADFライフサイクルによって準備されているリクエストの間のみ有効です。セッション・スコープには、バインディング・コンテナおよびバインディング・オブジェクト自体のみ残されます。

図30-4に、各タイプのスコープが有効な期間を示します。

図30-4 スコープとページ・フローの関係

マネージドBeanをどのスコープに登録するかを決定するときは常に、できるかぎり狭いスコープを使用するようにします。セッション・スコープは、セッション全体に関連する情報(ユーザー情報やコンテキスト情報など)にのみ使用します。タスク・フロー間で値を渡すためにセッション・スコープを使用しないでください。ページ・フラグメントまたは宣言コンポーネントのマネージドBeanを作成するときは、バッキングBeanスコープを使用する必要があります。

マネージドBeanは、adfc-config.xmlまたは特定のタスク・フローの構成ファイルに登録できます。FusionアプリケーションでのマネージドBeanの使用の詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

注意:

Fusion Webアプリケーションでは、faces-config.xmlでマネージドBeanを登録しないでください。

30.3.1 オブジェクト・スコープとタスク・フローに関する必知事項

タスク・フロー内の変数にどのスコープを使用するかを決定するときは、アプリケーション・スコープまたはセッション・スコープ以外のスコープ・オプションを使用する必要があります。これら2つのスコープは、タスク・フローの存続期間を超えてオブジェクトをメモリーに保存するため、タスク・フローのカプセル化および再利用で障害が発生します。さらに、アプリケーション・スコープおよびセッション・スコープでは、オブジェクトがメモリーに必要以上に長い時間保持されるため、不要なオーバーヘッドが発生します。

タスク・フロー内のアクティビティ間でデータ値を渡す必要がある場合は、ページ・フロー・スコープを使用する必要があります。現在のビュー・アクティビティ内でのみ必要とされ、ビュー・アクティビティ間にまたがっていない変数の場合、ビュー・スコープを使用する必要があります。現在のリクエストより長い期間スコープが存続する必要がない場合には、リクエスト・スコープを使用する必要があります。これは、UIコンポーネント情報の格納に使用する唯一のスコープです。最後に、タスク・フローが同じページの2つのリージョン・コンポーネントまたは宣言コンポーネントに表示される可能性があり、リージョン・インスタンスを分離する場合、タスク・フロー内のマネージドBeanには、バッキングBeanスコープを使用する必要があります。

30.4 ADFページ・ライフサイクルのカスタマイズ

ADFライフサイクルには明確に定義されたフェーズが含まれており、このフェーズによって対応するJSFフェーズの実行前後にADFライフサイクル・リスナーに通知が行われます。このライフサイクルは、必要なコードを起動するカスタム・フェーズ・リスナーを作成した後、これらのフェーズのいずれかで実行されるようにライフサイクルに登録することによってカスタマイズできます。

注意:

1つのアプリケーションでは、複数のフェーズ・リスナー・インスタンスを保持できません。デフォルトでは、最初のADFPhaseListenerインスタンスがMETA-INF/faces-config.xml構成ファイルに登録されます。たとえば、ADFPhaseListenerのカスタマイズされたサブクラスを登録すると、2つ目のインスタンスが作成されます。この場合、直近に登録されたインスタンスのみが使用されます。

警告メッセージ「ADFc: ADFページ・ライフサイクル実装を''新しいリスナーのクラス名''と置換しています。」により、インスタンスがより新しいものに置き換えられたことが通知されます。

30.4.1 カスタム・フェーズ・リスナーの作成方法

カスタム・フェーズ・リスナーを作成するには、PagePhaseListenerインタフェースを実装するリスナー・クラスを作成する必要があります。次に、コードの実行が必要なフェーズの前または後にコードを実行するメソッドを追加します。

次の例は、カスタム・フェーズ・リスナーを作成するために変更できるテンプレートを示しています。JDeveloperでクラスを作成する方法の詳細は、「カスタム・クラスの生成方法」を参照してください。

public class MyPagePhaseListener implements PagePhaseListener
{
public void afterPhase(PagePhaseEvent event)
{
System.out.println("In afterPhase " + event.getPhaseId());
}

public void beforePhase(PagePhaseEvent event)
{
System.out.println("In beforePhase " + event.getPhaseId());
}
}

カスタム・リスナー・クラスを作成したら、クラスを起動する必要があるフェーズに登録する必要があります。アプリケーション全体で使用できるようにグローバルに登録するか、1つのページに対してのみ登録することができます。

30.4.2 リスナーをグローバルに登録する方法

ADFライフサイクルをグローバルにカスタマイズするには、adf-settings.xml構成ファイルを編集してカスタム・フェーズ・リスナーを登録します。adf-settings.xmlファイルは、ADFコントローラなど複数のADFコンポーネントにより共有され、構成情報を格納します。

adf-settings.xmlにリスナーを登録するには:

1. 「アプリケーション」ウィンドウで、「META-INF」ノードの下にある「adf-settings.xml」ファイルをダブルクリックします。

2. エディタ・ウィンドウで「ソース」タブをクリックします。

3. ソース・エディタで、 <adfc-controller-config xmlns= "http://xmlns.oracle.com/adf/controller/config">まで下にスクロールします。

このエントリが存在しない場合は、これをファイルに追加します。

4. イタリックで示されている残りの要素を入力します。

<?xml version="1.0" encoding="US-ASCII" ?> <adf-config xmlns="http://xmlns.oracle.com/adf/config">
.
.
.
<adfc-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
<lifecycle>
<phase-listener>
<listener-id>MyPagePhaseListener</listener-id>
<class>mypackage.MyPagePhaseListener</class>
</phase-listener>
</lifecycle>
</adfc-controller-config>
.
.
.
</adf-config>

5. 次の要素の値を入力します。

- <listener-id>: リスナーの一意の識別子(完全修飾クラス名を使用可能)

- <class>: リスナーのクラス名

30.4.3 リスナーの順序に関する必知事項

adf-settings.xmlでは複数のフェーズ・リスナーを指定できるほか、これらの相対的なコール順序も任意で指定できます。このファイルに新しいリスナーを登録する際には、次の2つのパラメータを使用して、リスナー・リストでの配置を指定します。

- beforeIdSet: そのリスナーが、beforeIdSetで指定されているリスナーよりも先にコールされます。

- afterIdSet: そのリスナーが、afterIdSetで指定されているリスナーよりも後にコールされます。

次の例は、アプリケーション用に複数のリスナーが登録された構成ファイルの例を示しています。

<lifecycle>
<phase-listener>
<listener-id>MyPhaseListener</listener-id>
<class>view.myPhaseListener</class>
<after-id-set>
<listener-id>ListenerA</listener-id>
<listener-id>ListenerC</listener-id>
</after-id-set>
<before-id-set>
<listener-id>ListenerB</listener-id>
<listener-id>ListenerM</listener-id>
<listener-id>ListenerY</listener-id>
</before-id-set>
</phase-listener>
</lifecycle>

例では、MyPhaseListenerは登録されたリスナーであり、リスナーAおよびCの後かつ、リスナーB、MおよびYより先に実行されます。リスナーBの後にMyPhaseListenerを実行するには、リスナーBの<listener-id>要素を<after-id-set>要素の下に移動します。

30.4.4 単一ページのライフサイクル・リスナーの登録方法

単一ページのライフサイクルをカスタマイズするには、ページ定義ファイルでControllerClass属性を設定します。このリスナーが有効なのは、ページ定義によって記述された特定ページのライフサイクルに対してのみです。ページ定義ファイルとFusion Webアプリケーションにおけるその役割の詳細は、「ページ定義ファイルの処理」を参照してください。

標準JSFページまたはページ・フラグメントのどちらに対するものかに応じて、異なるコントローラ・クラスを指定します。

単一ページまたはページ・フラグメント用にADFライフサイクルをカスタマイズするには:

1. 「アプリケーション」ウィンドウで、ページまたはページ・フラグメントを右クリックし、「ページ定義に移動」を選択します。

2. 「構造」ウィンドウで、ページ定義ノードを選択します。

3. 「プロパティ」ウィンドウで、「ControllerClass」フィールドにカーソルを置いたときに表示されるアイコンをクリックして、「編集」を選択します。

4. 「階層」タブをクリックし、ページまたはページ・フラグメントの目的のコントローラ・クラスに移動します。各種ページに使用するコントローラ・クラスを次に示します。

- 標準JSFページの場合 - oracle.adf.controller.v2.lifecycle.PageController を指定
afterPhase/beforePhaseイベントを受信する必要がある場合は、oracle.adf.controller.v2.lifecycle.PagePhaseListenerを指定します。

- ページ・フラグメント - 次を指定します。 oracle.adf.model.RegionController

ヒント:

完全修飾クラス名としてページ定義のControllerClass属性の値を指定するか、ControllerClassフィールドに、クラスに直接解決されるEL式を入力できます。

ControllerClass属性の値にEL式を使用すると、#{YourExpression}が有効なクラスではないことを示す警告が「構造」ウィンドウに表示される場合があります。この警告は無視しても問題ありません。

31 データバインドされた基本的なページの作成

この章では、ADFデータ・コントロールおよびADF Facesコンポーネントを使用して、ADFビジネス・コンポーネントからデータがモデル化されたFusion Webアプリケーションでデータバインドされたフォームを作成する方法について説明します。テキスト・フィールドを個々の属性から作成する方法、新規レコードを編集および作成するためにコレクションからフォーム全体を生成する方法および動的フォームを作成する方法について説明します。

この章の内容は次のとおりです。

- データバインドされた基本的なページの作成について

- データ・コントロール属性を使用したテキスト・フィールドの作成

- データ・コントロールのコレクションを使用した基本的なフォームの作成

- データ・コントロール操作を使用したコマンド・コンポーネントの作成

- レンジ・ナビゲーションのフォームへの組入れ

- 既存レコードを編集するフォームの作成

- フォームを作成するためのパラメータの使用

- 入力フォームの作成

- 動的コンポーネントを使用したフォームの作成

- フォーム上のUIコンポーネントおよびバインディングの変更

31.1 データバインドされた基本的なページの作成について

ビジネス・サービス用に作成されたデータ・コントロールを使用して情報の表示および収集を実行するための、UIページを作成できます。たとえば、「データ・コントロール」パネルを使用して、項目の属性をドラッグし、出力テキストまたはラベル付き入力テキスト・フィールドとして、値を表示できます。関連データの表示および更新に必要なすべてのJSFタグとバインディング・コードがJDeveloperによって作成されます。「データ・コントロール」パネルおよび宣言的なバインディング機能の詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

個々の属性をドロップできる他、オブジェクトのすべての属性をフォーム、表または単一列リスト・ビューとして一度にドロップできます。この章には、値を表示するフォーム、ユーザーが値を編集できるフォームおよび値を収集するフォーム(入力フォーム)に関する情報が含まれます。表およびリスト・ビューの作成の詳細は、「ADFによるデータバインドされた表の作成」を参照してください。

UIコンポーネントをドロップすると、コレクション内のレコード間を移動できるようにしたり、ユーザーがデータを操作(レコードのコミット、削除、作成など)できるようにする組込み操作をコマンドUIコンポーネントとしてドロップできます。たとえば、フォームに表示されたデータ・オブジェクトをユーザーが削除できるようにするためのボタンを作成できます。また、必要に応じてデフォルトのコンポーネントを変更することもできます。

31.1.1 ADFによるデータバインドされたフォームのユースケースと例

行データを収集または表示する必要がある場合、フォームを使用します。たとえば、図31-1に示すように、Oracle ADFのSummitサンプル・アプリケーションには、ユーザーが顧客に関する情報を更新できるパネルが含まれています。このフォームは「データ・コントロール」パネルからCustomersコレクションをドラッグ・アンド・ドロップし、表示するフィールドを選択して作成されました。

図31-1 Summit ADFサンプル・アプリケーションの顧客一般情報フォーム

フォームを作成する場合、図31-2に示すように、ユーザーがレコード間を素早く移動できるように、ナビゲーションの追加を選択することもできます。

図31-2 フォーム内のレコード間の移動

フォームに表示される行への処理を実行するコマンド・ボタンを追加することもできます。たとえば、レコードの値を変更して、これらの変更を編集フォームに保存できます。または、ユーザーに新規レコードの作成を許可する入力フォームを作成できます。図31-3は、ユーザーが新規注文を作成可能な入力フォームを示しています。

図31-3 入力フォーム

注意:

フォーム内に表示する属性が実行時にしか使用できない場合は、動的フォームを作成できます。詳細は、「動的コンポーネントを使用したフォームの作成」を参照してください。

31.1.2 データバインド・ページの追加機能

データバインドされたページを実装する前に他のOracle ADF機能を理解することが役立つ場合があります。有用なその他の機能へのリンクは、次のとおりです。

- ADFビュー・オブジェクト: フォーム内でのコンポーネントの表示方法および機能のほとんどは、対応するビュー・オブジェクトによって制御されます。詳細は、「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。

- ADFアプリケーション・モジュール: ページにデータバインドされたコンポーネントをドラッグする「データ・コントロール」パネルに、アプリケーション・モジュールに追加したビュー・オブジェクトの表示が移入されます。詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

- アダプタベースのデータ・コントロール: EJBコンポーネントやWebサービスなど他のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』で説明されるこれらのビジネス・サービス用データ・コントロールを作成できます。

- ADFモデルとデータ・バインディング: ADF Webアプリケーション内でフォームを作成する場合は、ADFモデルおよびデータ・バインディングを使用します。詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

- ADF Faces: ADF Faces UIコンポーネントも使用します。ADF Facesを使用した開発の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

- 高度なUIコントロール: 基本的なフォームには、入出力コンポーネントを使用します。また、リスト、表、ツリー、検索フォーム、LOVコンポーネント、グラフ、ゲージ、ツリーマップなどの高度なコンポーネントを使用することもできます。詳細は、「データバインドされたWebユーザー・インタフェースの作成」の残りの各章を参照してください。

- タスク・フロー: トランザクションに携わるフォームの場合は(入力フォームなど)、フォームのレンダリングの前または後に、ADFタスク・フローを使用して特定の操作を起動する必要があります。詳細は、「ADFタスク・フローの作成」を参照してください。

- ページ・ライフサイクル: ページ・ライフサイクルでのフォームの処理の詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。

- 検証: 特定のフィールドがデータ・ストアに送信される前に、このフィールドを検証する必要がある場合もあります。詳細は、「検証とビジネス・ルールの宣言的な定義」および「ADFモデル・レイヤーでの検証の使用」を参照してください。

- アクティブ・データ: アプリケーションでアクティブ・データを使用する場合は、データ・ソースのデータが変更されるたびに、UIコンポーネント内のデータを自動的に更新できます。詳細は、「アクティブ・データ・サービスの使用」を参照してください。

31.2 データ・コントロール属性を使用したテキスト・フィールドの作成

JDeveloperでは、テキスト・フィールドを宣言的に作成可能な、JSFページ用の完全なWYSIWYG開発環境が用意されているため、ページのほとんどの内容をコードを見ずに設計できます。「データ・コントロール」パネルから項目をドラッグ・アンド・ドロップすると、属性バインディングを使用してADF FacesテキストUIコンポーネントはデータ・コントロールの属性に宣言的にバインドされます。

31.2.1 テキスト・フィールドの作成方法

属性を表示または更新できる個々のテキスト・フィールドを作成するには、「データ・コントロール」パネルからコレクションの属性をドラッグ・アンド・ドロップします。ADFビジネス・コンポーネントの場合、「データ・コントロール」パネルに、少なくとも1つのアプリケーション・モジュールで定義したデータ・モデルの要素が移入されます。

始める前に:

データ・コントロールを使用したテキスト・フィールドの作成に関する一般的な知識があると役立ちます。詳細は、「データ・コントロール属性を使用したテキスト・フィールドの作成」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

データバインド・テキスト・フィールドを作成するには:

1. 「データ・コントロール」パネルから、コレクションの属性を選択します。属性およびその他のオブジェクトを表す「データ・コントロール」パネルのアイコンの詳細は、「「データ・コントロール」パネルの使用」を参照してください。

たとえば、図31-4は、Summit ADFサンプル・アプリケーションのBackOfficeAppModuleDataControlデータ・コントロールの Customersコレクション下のLastName属性を示しています。これは、顧客の姓を表示、更新または挿入するためにドロップする属性です。

図31-4 コレクションに関連付けられた属性の「データ・コントロール」パネルでの表示

2. ページに属性をドラッグし、図31-5に示すように、ポップアップ・メニューから、属性値を表示または収集するUIコンポーネントのタイプを選択します。

図31-5 属性をページにドロップする際のポップアップ・メニュー

各属性について、次の選択肢があります。

- テキスト:

- ラベル付ADF入力テキスト: label属性が移入されADF Faces inputTextコンポーネントが作成されます。また、クライアント側検証を追加するために使用可能なネストされたvalidatorコンポーネントが作成されます。

ヒント:

inputTextコンポーネントの様々な属性の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「入力コンポーネントの使用およびフォームの定義」を参照してください。

- ADF入力テキスト: ラベルなしADF Faces inputTextコンポーネントが作成されます。また、クライアント側検証に対して使用可能なネストされたvalidatorコンポーネントが生成されます。

- ラベル付ADF出力テキスト: ADF Faces outputTextコンポーネントを保持するpanelLabelAndMessageコンポーネントを作成します。panelLabelAndMessageコンポーネントのlabel属性が移入されます。

- ADF出力テキスト: ADF Faces outputTextコンポーネントを作成します。

- ラベル付ADF出力フォーマット済: 「ラベル付ADF出力テキスト」と同様ですが、outputTextコンポーネントのかわりにoutputFormattedコンポーネントを使用します。outputFormattedコンポーネントでは、制限された分量のHTML書式設定を追加できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の出力テキストおよび書式設定された出力テキストの表示に関する項を参照してください。

- ADF出力フォーマット済: 「ラベル付ADF出力フォーマット済」と同様ですが、ラベルはありません。

- ADFラベル: ADF Faces outputLabelコンポーネント。

- 値リスト: ADF LOVリストを作成します。ビジネス・コンポーネントのこのリストの動作の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。アダプタベースのデータ・コントロールのこのリストの動作の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』の値オブジェクトのリストの作成に関する項を参照してください。JSFページでのリストの使用の詳細は、「選択リストの作成」を参照してください。

- 単一選択: 単一選択リストを作成します。JSFページでのリストの作成の詳細は、「選択リストの作成」を参照してください。

注意:

これらの選択は、デフォルトではユーザーが選択します。ただし、属性で使用可能なコンポーネントのリストは、関連するエンティティまたはビュー・オブジェクトのコントロール・ヒントとして構成できます。詳細は、「エンティティ・オブジェクトの属性のコントロール・ヒントの定義」および「ビュー・オブジェクトのUIヒントの定義」を参照してください。アダプタベースのデータ・コントロールのコントロール・ヒントを追加する方法の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』の属性のUIヒントを設定する方法に関する項を参照してください。

この章の目的にあわせて、ここではテキスト・コンポーネントのみ(リストは除く)について説明します。

31.2.2 テキスト・フィールドの作成時の処理

JSFページに属性をドラッグしてUIコンポーネントとしてドロップすると、そのページのページ定義ファイル(すでに存在する場合を除く)などが作成されます。属性をページにドラッグしたときに行われる処理の完全な説明は、「「データ・コントロール」パネルの使用時の処理」を参照してください。イテレータと属性のバインディングが作成され、ページ定義ファイルに追加されます。また、UIコンポーネントに必要なJSPXまたはJSFページ・コードがJSFページに追加されます。

31.2.2.1 ページ定義ファイルに作成されるイテレータ・バインディング

「データ・コントロール」パネルからコレクションの一部である項目をドロップして(またはコレクション全体をフォームまたは表としてドロップして)ページ上にUIコンポーネントを作成するたびに、イテレータ・バインディングが自動的に作成されます(すでに存在する場合を除く)。イテレータ・バインディングは、データ・コレクションのイテレータを参照し、この機能によりそのデータ・オブジェクトを反復処理します。また、コレクション内のデータ・オブジェクトの現在行および状態を管理します。イテレータ・バインディングは実際にはデータにアクセスしません。かわりに、データにアクセスできるオブジェクトを単純に公開し、コレクション内の現在のデータ・オブジェクトを指定します。その後、現在のオブジェクトのデータを戻したり、オブジェクトのデータに対してアクションを実行するために、他のバインディングがこのイテレータ・バインディングを参照します。イテレータ・バインディングはイテレータではないことに注意してください。これはイテレータへのバインディングです。ADFビジネス・コンポーネントの場合、実際のイテレータは、アプリケーション・モジュールのデータ・モデル内のビュー・オブジェクト・インスタンスのデフォルト行セットに対するデフォルト行セット・イテレータです。

たとえば、CustomersコレクションのLastName属性をドロップした場合、Customersコレクションのイテレータ・バインディングが作成されます。

ヒント:

各コレクションに対して1つのイテレータ・バインディングが作成されます。つまり、同じコレクションから2つの属性をドロップした場合(もしくは同じコレクションを2回ドロップした場合)は、同じバインディングが使用されます。この動作の1つの利点は、コンポーネントの現状が同期された状態で維持されることです。たとえば、ページに同じコレクションからドロップされた表とフォームがある場合、フォームには、表で選択された行のレコードが表示されます。コンポーネントごとに動作の異なるバインディングが必要な場合、手動で個別のイテレータ・バインディングを作成する必要があります。

イテレータ・バインディングのrangeSize属性は、イテレータ・バインディングへのアクセスが行われるたびにデータ・コントロールからフェッチされるデータ行数を決定します。この属性により、行セット全体の中でいくつかの絶対開始位置に対して1-n行の相対セットが置かれます。属性またはコレクションをページ上にドラッグしてイテレータ・バインディングを作成する場合、属性は最初に25に設定されます。この属性の使用の詳細は、「定義されるイテレータのRangeSize属性」を参照してください。次の例は、Customersコレクションから属性をドロップすると作成されるイテレータ・バインディングを示しています。

<executables>
<iterator Binds="Customers" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="Customers"/>
</executables>

イテレータ・バインディング要素の属性の詳細は、「Oracle ADFバインディング・プロパティ」を参照してください。

このメタデータにより、ADFバインディング・コンテナは属性値にアクセスできます。実行可能ファイルであるイテレータ・バインディングは、デフォルトでページのロード時に起動されるため、これによってイテレータがCustomersコレクションにアクセスし、反復処理を実行できます。これは、イテレータによって、コレクション内のすべてのCustomersオブジェクトの管理(現在のCustomersオブジェクトまたはCustomersオブジェクト・レンジの判別など)が行われることを意味します。

31.2.2.2 ページ定義ファイルに作成される値バインディング

「データ・コントロール」パネルから属性をドロップすると、UIコンポーネントを属性の値にバインドするための属性バインディングが作成されます。このタイプのバインディングは、コレクション内の現在行のシングル・オブジェクトに対する属性の値を提示します。値バインディングは、属性値の表示と収集の両方に使用できます。

たとえば、Customersコレクションの下にあるLastName属性を「ラベル付ADF出力テキスト」ウィジェットとしてページにドロップすると、JDeveloperによって、LastName属性の属性バインディングが作成されます。これにより、バインディングが現在のレコードの属性値にアクセスできるようになります。次の例は、Customersコレクションから属性をドロップすると作成される、LastNameに対する属性バインディングを示しています。この属性値は、CustomersIteratorという名前のイテレータを参照します。

<bindings>
...
<attributeValues IterBinding="CustomersIterator"
id=""LastName
<AttrNames>
<Item Value="LastName">
</AttrNames>
</attributeValues>
</bindings>

属性バインディング要素のプロパティの詳細は、「Oracle ADFバインディング・プロパティ」を参照してください。

31.2.2.3 JSFページに作成されるコンポーネント・タグ

「データ・コントロール」パネルから属性をドロップしてテキスト・フィールドを作成すると、対応するタグがJSFページに記述され、ドロップしたウィジェットに関連付けられているUIコンポーネントが作成されます。

たとえば、LastName属性を「ラベル付出力テキスト」ウィジェットとしてドロップすると、JDeveloperによってpanelLabelAndMessageコンポーネントとoutputTextコンポーネントのタグが挿入されます。また、panelLabelAndMessageコンポーネントのlabel属性を、LastNameのバインディングのために作成されたヒントのlabelプロパティにバインドするEL式が作成されます。この式は、ビュー・オブジェクトに設定されたラベル・ヒントを評価します(ヒントの詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照)。また、現在の行のLastName属性の値に評価される、outputTextコンポーネントのvalue属性をLastNameバインディングのinputValueプロパティにバインドする、別の式が作成されます。両方のコンポーネントに対してIDも自動的に生成されます。

ヒント:

JDeveloperでは、すべてのADF FacesコンポーネントのIDが自動的に生成されます。これらの値を必要に応じてオーバーライドできます。

次の例は、LastName属性を「ラベル付出力テキスト」ウィジェットとしてドロップしたときにJSFページで生成されるコードを示しています。

<af:panelLabelAndMessage label="#{bindings.LastName.hints.label}" id="plam1">
<af:outputText value="#{bindings.LastName.inputValue}" id="ot1"/>
</af:panelLabelAndMessage>

かわりにLastName属性を「ラベル付入力テキスト」ウィジェットとしてドロップすると、JDeveloperによってinputTextコンポーネントが作成されます。次の例に示すように、値はLastNameバインディングのinputValueプロパティにバインドされます。さらに、次のプロパティも設定されます。

- label: オブジェクトのlabel UIヒントにバインドされます。

- required: オブジェクトのmandatoryプロパティにバインドされます。

- columns: オブジェクトのdisplayWidth UIヒントにバインドされます。テキスト・ボックスの幅を決定します。

- maximumLength: オブジェクトのprecisionプロパティにバインドされます。フィールドに入力できる1行当たりの最大文字数を決定します。

- shortDesc: tooltip UIヒントにバインドされます。

また、JDeveloperはinputTextコンポーネント内にvalidatorタグをネストします。このタグを使用してクライアント側の検証規則を作成し、モデルまたはビジネス・サービス・レイヤーに存在する検証規則を補足できます。

<af:inputText value="#{bindings.LastName.inputValue}"
label="#{bindings.LastName.hints.label}"
required="#{bindings.LastName.hints.mandatory}"
columns="#{bindings.LastName.hints.displayWidth}"
maximumLength="#{bindings.LastName.hints.precision}">
shortDesc="#{bindings.LastName.hints.tooltip}" id="it1">
<f:validator binding="#{bindings.LastName.validator}"/>
</af:inputText>

validatorおよびconverterタグの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「入力の検証および変換」を参照してください。

これらの値は必要に応じて変更できます。たとえば、ビュー・オブジェクトのmandatoryコントロール・ヒントはデフォルトでfalseに設定されており、これは、コンポーネントのrequired属性もfalseと評価されることを意味します。コンポーネントのrequired属性をtrueに設定すると、この値をオーバーライドできます。属性のすべてのインスタンスを必須にする場合は、ビュー・オブジェクト内のコントロール・ヒントを変更して、すべてのインスタンスを必須にすることができます。これらのプロパティの詳細は、「Oracle ADFバインディング・プロパティ」を参照してください。エンティティ・オブジェクト・レベルでこれらのプロパティを変更する方法の詳細は、「属性プロパティの設定」を参照してください。ビュー・オブジェクト・レベルでこれらのプロパティを変更する方法の詳細は、「ビュー・オブジェクトの編集方法」を参照してください。

31.3 データ・コントロールのコレクションを使用した基本的なフォームの作成

コレクションの各属性を個別にドロップしてフォームを作成するかわりに、コレクションの複数の属性からフォームを作成するコレクション・ノードをドロップできます。

たとえば、Customersコレクションをドラッグ・アンド・ドロップすることによって、Summit ADFサンプル・アプリケーションの顧客に関する基本的な情報を表示するページを作成できます。

また、コレクションからデータを表示するだけでなく、多くの機能を提供するフォームの作成もできます。ユーザーによるデータ更新が可能なフォームの作成の詳細は、「既存レコードを編集するフォームの作成」を参照してください。ユーザーによるコレクションに対する新規オブジェクト作成が可能なフォームの作成の詳細は、「入力フォームの作成」を参照してください。また、検索フォームも作成できます。詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

31.3.1 データ・コントロール・コレクションを使用したフォームの作成方法

データ・コントロールを使用してフォームを作成する場合、UIコンポーネントをデータ・コントロールの対応するオブジェクトの属性にバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

始める前に:

基本的なデータバインド・フォームについて理解しておくと役立ちます。詳細は、「データ・コントロールのコレクションを使用した基本的なフォームの作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

基本的なフォームを作成するには:

1. 「データ・コントロール」パネルから、表示するデータを表すコレクションを選択します。図31-6に、BackOfficeAppModuleDataControlデータ・コントロールのCustomersコレクションを示します。

図31-6 「データ・コントロール」パネルでのCustomerVOオブジェクト

2. コレクションをページにドラッグし、ポップアップ・メニューから「ADFフォーム」を選択します。

図31-7 コレクションをページにドロップする際のポップアップ・メニュー

3. 「フォームの作成」ダイアログで、フォームを構成します。

- 属性がフォームに表示できないようにすることができます。

- 「読取り専用フォーム」チェック・ボックスを選択しない場合、ADF inputTextコンポーネントがほとんどの属性に対して使用されます。inputTextコンポーネントごとにlabel属性が移入されます。デフォルトで、ラベルは、関連付けられているバインディング・オブジェクトのlabelプロパティにバインディングからその値を取得します。
日付である属性ではInputDateコンポーネントが使用されます。

属性にコントロール・タイプのコントロール・ヒントが作成されている場合、または属性がリストとして構成されている場合、ヒントにより設定されたコンポーネントが使用されます。

InputTextコンポーネントには、属性のクライアント側検証を設定するためのvalidatorタグが含まれます。属性が数値または日付の場合、converterも含まれます。

ヒント:

inputTextコンポーネントの様々な属性の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「入力コンポーネントの使用およびフォームの定義」を参照してください。

- 「読取り専用フォーム」チェック・ボックスを選択する場合、読取り専用outputTextコンポーネントが使用されます。このフォームはデータの表示を目的としているため、validatorタグは追加されません(コンバータは含まれます)。タイプDateの属性は、読取り専用フォームではoutputTextコンポーネントを使用します。すべてのコンポーネントは、label属性を含むpanelLabelAndMessageコンポーネント内に配置され、panelFormLayoutコンポーネントに格納されます。これにより、実行時にラベルがoutputTextコンポーネントと適切に位置合せされるようになります。

- ユーザーがコレクション内の全データ・オブジェクト間を移動できるようにする、ナビゲーション・コントロールを含めることもできます。詳細は、「レンジ・ナビゲーションのフォームへの組入れ」を参照してください。

- HTMLフォームを送信する「送信」ボタンが含まれ、フォームのデータをJSF/ADFページ・ライフサイクルの一部としてバインディングに適用することもできます。このダイアログの使用方法に関する追加のヘルプを表示するには、「ヘルプ」をクリックします。

4. ユーザーがデータを更新できるようにするためのフォームを作成する場合は、ここで、レコードを更新するために変更をコミットする操作をドラッグ・アンド・ドロップする必要があります。詳細は、「既存レコードを編集するフォームの作成」を参照してください。

注意:

「フォームの作成」ダイアログで実行時に生成されるフィールドを選択する場合、表示する属性は、ビジネス・サービスの構成に基づいて実行時に決定されます。詳細は、「動的コンポーネントを使用したフォームの作成」を参照してください。

31.3.2 データ・コントロール・コレクションを使用したフォームの作成時の処理

「データ・コントロール」パネルからオブジェクトをフォームとしてドロップすることは、単一の属性をドロップするのと同じ効果があります。ただし、複数の属性バインディングおよび関連するUIコンポーネントが作成され、すべてのUIコンポーネントがpanelFormLayoutコンポーネント内に配置される点が異なります。UIコンポーネントの属性(valueなど)は、その属性のバインディング・オブジェクト(inputValueなど)のプロパティ、または対応するビジネス・オブジェクトで設定されるコントロール・ヒントの値にバインドされます。次の例は、CustomersコレクションをデフォルトADFフォームとしてドロップした場合にJSFページで生成されるコードの一部を示しています。

注意:

関連するビューまたはエンティティ・オブジェクトで属性が非表示としてマークされている場合、対応するUIは作成されません。

<af:panelFormLayout id="pfl1">
<af:inputText value="#{bindings.Id.inputValue}"
label="#{bindings.Id.hints.label}"
required="#{bindings.Id.hints.mandatory}"
columns="#{bindings.Id.hints.displayWidth}"
maximumLength="#{bindings.Id.hints.precision}"
shortDesc="#{bindings.Id.hints.tooltip}" id="it1">
<f:validator binding="#{bindings.Id.validator}"/>
<af:convertNumber groupingUsed="false" pattern="#{bindings.Id.format}"/>
</af:inputText>
<af:inputText value="#{bindings.Name.inputValue}"
label="#{bindings.Name.hints.label}"
required="#{bindings.Name.hints.mandatory}"
columns="#{bindings.Name.hints.displayWidth}"
maximumLength="#{bindings.Name.hints.precision}"
shortDesc="#{bindings.Name.hints.tooltip}" id="it2">
<f:validator binding="#{bindings.Name.validator}"/>
</af:inputText>
<af:inputText value="#{bindings.Phone.inputValue}"
label="#{bindings.Phone.hints.label}"
required="#{bindings.Phone.hints.mandatory}"
columns="#{bindings.Phone.hints.displayWidth}"
maximumLength="#{bindings.Phone.hints.precision}"
shortDesc="#{bindings.Phone.hints.tooltip}" id="it3">
<f:validator binding="#{bindings.Phone.validator}"/>
</af:inputText>
. . .
</af:panelFormLayout>

「データ・コントロール」パネルからアイテムをドロップするときに生成されるコードの詳細は、「テキスト・フィールドの作成時の処理」を参照してください。

定義済の値リスト(LOV)を含むオブジェクトを使用して入力フォームを作成する場合、inputTextコンポーネントのかわりにselectOneChoiceコンポーネントが作成されます。たとえば、CustomerVOビュー・オブジェクトには、CountryIdおよびCreditRatingId属性の定義済LOVが含まれます。Customersデータ・コントロール・オブジェクトをADFフォームとしてドロップすると、(空の入力テキスト・フィールドのかわりに)すべての値を表示するドロップダウン・リストが各LOVに対して作成されます。このリストの動作の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。アダプタベースのデータ・コントロールのこのリストの動作の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』の値オブジェクトのリストの作成に関する項を参照してください。JSFページでのリストの使用の詳細は、「選択リストの作成」を参照してください。

注意:

オブジェクトに構造化属性(Javaのプリミティブ・タイプまたはコレクションのいずれでもない属性)が含まれる場合、その属性はダイアログには表示されず、また、フォームに対応するコンポーネントもありません。これらのフィールドは手動で作成する必要があります。

31.4 データ・コントロール操作を使用したコマンド・コンポーネントの作成

「データ・コントロール」パネルには、データ・オブジェクトの表示を提供するほか、フォームで使用するための標準操作を表すノードもあります。これらの組込み操作により、レコード間の移動やデータベースへの変更のコミットなど、通常のフォーム機能を宣言的に処理できます。大半の操作はデータ・コントロール内の個々のデータ・コレクションに対応しています。コミットおよびロールバック操作はデータ・コントロール全体に対して使用できます。「データ・コントロール」パネルからページに操作をドラッグする場合、ボタンやリンクなど、作成するコマンド・コンポーネントの種類を選択するよう求められます。

図31-8は、Summit ADFサンプル・アプリケーションのCountriesコレクションで使用可能な操作を示しています。

図31-8 データ・コントロール・コレクションの操作

この項では、組込みデータ・コントロール操作からコマンド・コンポーネントを作成する方法を示します。データバインドされたページでコマンド・コンポーネントを使用可能な他の方法の詳細は、「ビュー・レイヤーで各機能を起動するコマンド・コンポーネントの使用」を参照してください。

31.4.1 操作からコマンド・コンポーネントを作成する方法

データ・コントロール操作に基づいてコマンド・コンポーネントを作成するには、「データ・コントロール」パネルからページに操作をドラッグ・アンド・ドロップします。

始める前に:

コマンド・コンポーネントを作成するためにデータ・コントロール操作を使用することを理解しておくと役立ちます。詳細は、「データ・コントロール操作を使用したコマンド・コンポーネントの作成」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

操作からコマンド・コンポーネントを作成するには:

1. 「データ・コントロール」パネルから、操作をページにドラッグします。

2. 次に表示されるポップアップ・メニューから「ADFボタン」または「ADFリンク」を選択します。

31.4.2 操作を使用したコマンド・コンポーネント作成時の処理

操作をドロップしてコマンド・コンポーネントを作成する場合、JDeveloperによって次の処理が行われます。

- 関連付けられている操作について、ページ定義ファイルでアクション・バインディングが定義されます。

- コレクションに部分ページ・レンダリングを使用するように、イテレータ・バインディングが構成されます。

- コマンド・コンポーネント用のコードがJSFページに挿入されます。

31.4.2.1 操作に対して作成されるアクション・バインディング

アクション・バインディングは、ビジネス・ロジックを実行します。たとえば、アクション・バインディング・オブジェクト上で操作を起動できます。これらの操作は、イテレータまたはデータ・コントロール自体で機能します。

アクション・バインディングがNextまたはPreviousなどのイテレータレベル・アクションにバインドされている場合、操作のアクション・バインディングには、値バインディングと同様にイテレータ・バインディングへの参照が含まれます。これらのタイプのアクションはイテレータによって実行されます。イテレータは現在のオブジェクトを判別するため、ナビゲーション・ボタンがクリックされたときに表示するオブジェクトが正しく判別されます。イテレータ・レベルではないアクションへのアクション・バインディング(たとえば、アプリケーション・モジュールのカスタム・メソッドやコミット操作やロールバック操作の場合)には、この参照は含まれません。

アクション・バインディングはRequiresUpdateModelプロパティを使用して、アクションを実行する前にモデルを更新する必要があるかどうかを判別します。ナビゲーション操作の場合、デフォルトではこのプロパティはtrueに設定されています。つまり、ビュー・レイヤーでのすべての変更は、ナビゲーションを実行する前にモデルに移動する必要があります。

次の例は、ナビゲーション操作のアクション・バインディングを示しています。

<action IterBinding="CustomersIterator" id="First"
RequiresUpdateModel="true" Action="first"/>
<action IterBinding="CustomersIterator" id="Previous"
RequiresUpdateModel="true" Action="previous"/>
<action IterBinding="CustomersIterator" id="Next"
RequiresUpdateModel="true" Action="next"/>
<action IterBinding="CustomersIterator" id="Last"
RequiresUpdateModel="true" Action="last"/>

31.4.2.2 定義されるイテレータのRangeSize属性

イテレータ・バインディングにはrangeSize属性が含まれ、バインディングではこの属性を使用して、反復ごとにページで使用できるようにするデータ・オブジェクト数が決定されます。この属性は、データソース内のオブジェクト数がきわめて多い場合に役立ちます。イテレータ・バインディングは、すべてのオブジェクトではなく、1つのセット番号のみを戻すため、他のバインディングでアクセスできるようになります。イテレータはレンジの最後に到達すると、次のセットにアクセスします。次の例は、Customersイテレータのデフォルトのレンジ・サイズを示しています。

<iterator Binds="Customers" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="CustomersIterator"
ChangeEventPolicy="ppr"/>

注意:

このrangeSize属性は、表コンポーネントのrows属性とは異なります。詳細については、表32-1を参照してください。

イテレータ・バインディングが最初に生成されるときに、RangeSize属性は25に設定されます。つまり、ユーザーは、データソースにアクセスせずに、前後に移動しながら25個のオブジェクトを表示できます。イテレータは、現在のオブジェクトを追跡します。ユーザーが新しいレンジが要求されるボタンをクリックすると(たとえば、オブジェクト番号25で「次へ」ボタンをクリックすると)、バインディング・オブジェクトによってイテレータに対して関連するメソッドが実行され、イテレータによって別の25個のレコードのセットが取得されます。その後、取得されたセットがバインディングによって使用されます。この設定は、必要に応じて変更できます。完全なレコード・セットを戻すには、-1に設定します。RangeSize属性が指定されない場合、完全なレコード・セットが戻されます。

31.4.2.3 操作へバインドするために作成されるEL式

データ・コントロール操作を使用してコマンド・コンポーネントを作成すると、JDeveloperにより、コマンド・コンポーネントのactionListener属性を、指定された操作のアクション・バインディングのexecuteプロパティにバインドするEL式が作成されます。

実行時、アクション・バインディングは、コアのJUCtrlActionBinding実装クラスを拡張するFacesCtrlActionBindingクラスのインスタンスです。FacesCtrlActionBindingクラスにより、次のメソッドが追加されます。

- public void execute(ActionEvent event): actionListenerプロパティで参照されるメソッドです(例: #{bindings.First.execute})。
ユーザーがボタンをクリックすると、この式によって、イテレータに対してバインディングの操作が起動されます。たとえば、Firstコマンド・ボタンのactionListener属性は、Firstアクション・バインディングのexecuteメソッドにバインドされます。

- public String outcome(): Actionプロパティで参照できます(例: #{bindings.Next.outcome})。
移動先となる次のページを決定するJSFナビゲーションの結果として、メソッド・アクション・バインディングの結果(Stringに変換後)に使用できます。

注意:

アクション・バインディングでoutcomeメソッドを使用すると、ビューおよびコントローラのレイヤーとモデル・レイヤーとの分離が壊れるため、ほとんど使用されません。

操作の各アクション・バインディングには、enabledブール型プロパティが含まれます。このプロパティは、操作を起動しない場合には、Oracle ADFによってfalseに設定されます。デフォルトでは、JDeveloperがこの値にUIコンポーネントのdisabled属性をバインドして、コンポーネントを有効化するかどうかを指定します。たとえば、「先頭へ」ボタンのUIコンポーネントのdisabled属性の値は、次のとおりです。

#{!bindings.First.enabled}

この式は、バインディングが有効でない場合、常にtrueに評価されます。つまり、操作を起動しない場合に、ボタンが無効になります。この例では、最初のレコードが表示されている場合はいつでも、フレームワークがバインディングのenabledプロパティをfalseに設定するため、「先頭へ」ボタンが自動的に無効になります。これは、enabledがFalseの場合は、常にdisabled属性がtrueに設定されるためです。enabledプロパティの詳細は、「Oracle ADFバインディング・プロパティ」を参照してください。

次の例は、CreateおよびDelete操作をページ上のボタンとしてドロップした後に生成されるコードを示しています。

<af:button actionListener="#{bindings.Create.execute}" text="Create"
disabled="#{!bindings.Create.enabled}" id="b5"/>
<af:button actionListener="#{bindings.Delete.execute}" text="Delete"
disabled="#{!bindings.Delete.enabled}" id="b6"/>

31.4.3 実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法

ユーザーがコマンド・コンポーネントをクリックすると、フォームが送信され、続いてアクション・イベントが起動します。アクション・イベントは、ユーザー・インタフェースのみに影響する場合(たとえば、異なるフィールド・プロンプトを表示させる、ロケールを変更するためのリンク)と、なんらかのロジック処理を伴う場合(たとえば、次のレコードに移動するためのボタン)があります。次に、そのイベント・オブジェクトは、イテレータから現在のデータ・オブジェクトの情報を取得し、それをアクション・バインディングのメソッドに渡し、そのactionListener属性からコマンド・コンポーネントにバインドされます。

注意:

アクション・リスナーは、コマンド・コンポーネントによってアクション・イベントが起動されたときに通知を受けるよう登録されているクラスです。アクション・リスナーには、コマンド・コンポーネントによって渡されるアクション・イベント・オブジェクトを処理する、アクション・リスナー・メソッドが含まれます。

たとえば、ユーザーがADF Delete操作から作成された「削除」ボタンをクリックすると、アクション・イベントが起動されます。このイベント・オブジェクトは、イテレータから取得した現在のデータ・オブジェクトの現在行位置情報を格納します。コンポーネントのactionListener属性がDeleteアクション・バインディングのexecuteメソッドにバインドされているため、イベントが起動されるとDelete操作が起動します。このメソッドは、イベント・オブジェクトで渡された現在行位置情報を使用して、削除するデータ・オブジェクトを判別します。

通常、actionListenerプロパティの値はEL式の形式です。たとえば、actionListener属性の値が{bindings.Delete.execute}の場合、Deleteアクション・バインディングのexecute()メソッドがコールされます。

31.4.4 宣言メソッドのオーバーライドに関する必知事項

操作またはメソッドをコマンド・ボタンとしてドロップすると、JDeveloperによって操作またはメソッドのexecuteメソッドにそのボタンがバインドされます。ただし、既存のロジックの前または後に、ロジックの追加が必要になる場合もあります。JDeveloperを使用すると、バインディング・コンテナにアクセスするマネージドBeanでメソッドおよびプロパティを新規作成することにより、宣言的操作にロジックを追加できます。デフォルトでは、この生成されたコードによって、操作またはメソッドが実行されます。その後、このコードの前か後にロジックを追加できます。元の操作またはメソッドのexecuteプロパティではなく、この新規メソッドにコマンド・コンポーネントが自動的にバインドされます。その後、ユーザーがボタンをクリックすると、新規メソッドが実行されます。詳細は、「宣言メソッドの上書き」を参照してください。

31.5 レンジ・ナビゲーションのフォームへの組入れ

ADFフォームを作成する際、ナビゲーション・コントロールの組込みを選択すると、データ・コントロールの既存のナビゲーション・ロジックにバインドされているADF Facesコマンド・コンポーネントが組み込まれます。この組込みロジックによって、ユーザーは、コレクション内のすべてのデータ・オブジェクトを移動できるようになります。図31-9の例は、Countriesコレクションをドラッグし、ナビゲーションを使用するADFフォームとしてドロップした場合に作成されるフォームを示しています。

図31-9 フォーム内のナビゲーション

表31-1に、データ・コントロールで提供される組込みナビゲーション操作と、操作にバインドされたイベントの実行または操作の起動の結果を示します。アクション・イベントの詳細は、「実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法」を参照してください。

表31-1 組込みナビゲーション操作

操作

関連イテレータ・バインディングによる起動時の処理

First

現在のポインタを結果セットの最初に移動します。

Last

現在のポインタを結果セットの最後に移動します。

前

現在のポインタを結果セットの前のオブジェクトに移動します。このオブジェクトが現在のレンジの外にある場合は、レンジ・サイズと同じオブジェクト数だけレンジが戻るようにスクロールされます。

次

現在のポインタを結果セットの次のオブジェクトに移動します。このオブジェクトが現在のレンジの外にある場合は、レンジ・サイズと同じオブジェクト数だけレンジが進むようにスクロールされます。

Previous Set

レンジ・サイズ属性と同じオブジェクト数だけ、レンジを戻すように移動します。

Next Set

レンジ・サイズ属性と同じオブジェクト数だけ、レンジを進めるように移動します。

31.5.1 フォームへのナビゲーション・コントロールの手動の挿入方法

デフォルトでは、「データ・コントロール」パネルを使用してフォームを作成する際にナビゲーションの組込みを選択すると、「先頭へ」、「最後へ」、「前へ」および「次へ」の各ボタンが作成され、ユーザーがコレクション内を移動できるようになります。

また、既存のフォームにナビゲーション・ボタンを手動で追加できます。

始める前に:

ナビゲーション・コントロールについて理解しておくと役立ちます。詳細は、「レンジ・ナビゲーションのフォームへの組入れ」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

ナビゲーション・ボタンを手動で追加するには:

1. 操作の実行対象となるオブジェクトのコレクションに関連付けられている操作を「データ・コントロール」パネルから選択し、JSFページ上にドラッグします。

たとえば、国のコレクション全体を移動できるようにする場合は、Countriesコレクションに関連付けられている「次へ」操作をドラッグします。図31-8に、Countriesコレクションに関連付けられている操作を示します。

2. 次に表示されるポップアップ・メニューから「ADFボタン」または「ADFリンク」を選択します。

ヒント:

「先頭へ」、「最後へ」、「前へ」および「次へ」のすべてのボタンを一度にドロップすることもできます。一度にドロップするには、対応するコレクションをドラッグし、ポップアップ・メニューから「移動」→「ADFナビゲーション・ボタン」を選択します。

31.5.2 手動でナビゲーション・ボタンを追加する場合の処理

「データ・コントロール」パネルからナビゲーション操作をドロップする場合、JDeveloperによって次の処理が行われます。

- 関連付けられている操作について、ページ定義ファイルでアクション・バインディングが定義されます。

- コレクションに部分ページ・レンダリングを使用するように、イテレータ・バインディングが構成されます。

- コマンド・コンポーネント用のコードがJSFページに挿入されます。

- ボタンをクリックすると部分ページ・リクエストが起動されるように、JSFページにコンポーネントのpartialSubmit属性を挿入し、それをtrueに設定します。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の部分トリガーの使用に関する項を参照してください。

コマンド・コンポーネントに対して生成されたコードの詳細は、「操作を使用したコマンド・コンポーネント作成時の処理」を参照してください。

次の例は、ナビゲーション操作ボタンに対してJSFページで生成されたコードを示しています。

<f:facet name="footer">
<af:panelGroupLayout>
<af:button actionListener="#{bindings.First.execute}"
text="First"
disabled="#{!bindings.First.enabled}"
partialSubmit="true" id="cb1"/>
<af:button actionListener="#{bindings.Previous.execute}"
text="Previous"
disabled="#{!bindings.Previous.enabled}"
partialSubmit="true" id="cb2"/>
<af:button actionListener="#{bindings.Next.execute}"
text="Next"
disabled="#{!bindings.Next.enabled}"
partialSubmit="true" id="cb3"/>
<af:button actionListener="#{bindings.Last.execute}"
text="Last"
disabled="#{!bindings.Last.enabled}"
partialSubmit="true" id="cb4"/>
</af:panelGroupLayoutr>
</f:facet>

31.5.3 実行時に行われる処理: ナビゲーション・コントロール

ユーザーがナビゲーション・コントロール・ボタンをクリックすると、アクション・イベントが起動します。次に、そのイベント・オブジェクトは、イテレータから現在のデータ・オブジェクトの情報を取得し、それを操作のメソッドに渡し、そのactionListener属性からボタンにバインドされます。

詳細は、「実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法」を参照してください。

また、ユーザーがナビゲーション・ボタンをクリックすると、ボタンのアクション・バインディングと同じイテレータに関連付けられたコンポーネントのみがライフサイクルを通して処理されます。詳細は、「部分ページ・レンダリングおよびイテレータ・バインディングに関する必知事項」を参照してください。

31.5.4 ブラウザの「戻る」ボタンおよびレコード間の移動に関する必知事項

フォームに表示されるレコード間でのナビゲートには、ナビゲーション・ボタンを使用する必要があり、ブラウザの「戻る」または「進む」ボタンは使用できません。ナビゲーション・フォームでは自動的にPPRが使用されるため、ライフサイクルを通過するのはページの一部のみです(つまり、ユーザーがナビゲーション・ボタンをクリックすると、データを表示するコンポーネントがリフレッシュされて新しいデータが表示されますが、ユーザーは実際には同じページにとどまっています)。したがって、ブラウザの「戻る」ボタンをクリックすると、そのフォームに表示された前のレコードではなく、そのフォームを使用したページの前にレンダリングされたページに戻ります。

たとえば、現在の注文をすべて表示するためのリンクを含むページが表示されているとします。このリンクをクリックすると、フォームを使用したページに移動し、最初の注文であるOrder #101が表示されます。次に「次へ」をクリックすると、Order #102が表示されます。再び「次へ」をクリックすると、Order #103が表示されます。ブラウザの「戻る」ボタンをクリックした場合、Order #102は表示されません。かわりに、現在のすべての注文を表示するためのリンクを含むページに戻ります。

31.5.5 CacheResultsプロパティに関する必知事項

「データ・コントロール」パネルを使用してナビゲーション可能なフォームを作成する場合、関連するイテレータのCacheResultsプロパティはtrueに設定されます。これにより、現在行情報などのイテレータの状態はリクエスト間でキャッシュされ、現在のオブジェクトを判別できるようになります。このプロパティがfalseに設定されている場合、ナビゲーションは動作しません。

31.6 既存レコードを編集するフォームの作成

ユーザーが現在のデータを編集し、その変更をデータ・ソースにコミットするためのフォームを作成できます。フォームを作成するには、コレクションまたはデータ・コントロール自身に関連付けられたデータ・レコードを変更するための操作を使用して、コマンド・ボタンを作成します。たとえば、Delete操作を使用して、ユーザーが現在のレンジからレコードを削除できるボタンを作成できます。

ADFビジネス・コンポーネントまたは明示的コミット・モデルを持つEJBセッションBeanに基づいたデータ・コントロールの場合、重要なのは、これらの操作がADFキャッシュのオブジェクトに対してのみ実行されるという点です。ルート・データ・コントロール上でCommit操作を使用して、任意の変更をデータソースに実際にコミットする必要があります。データ・コントロールのRollback操作を使用して、キャッシュされたオブジェクトに対する任意の変更をロールバックします。ページが、バインド・タスク・フロー内のトランザクションの一部である場合、通常、タスク・フロー・リターン・アクティビティのトランザクションを解決するためにこの操作を使用します。詳細は、「タスク・フローのトランザクションの管理」を参照してください。

31.6.1 編集フォームの作成方法

編集フォームを作成するには、コレクションをフォームとしてページにドロップし、適切な操作をコマンド・コンポーネントとしてドロップします。

始める前に:

編集フォームの作成について理解しておくと役立ちます。詳細は、「既存レコードを編集するフォームの作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

編集フォームの作成方法:

1. 「データ・コントロール」パネルから、フォームを作成するコレクションをドラッグし、ポップアップ・メニューから「ADFフォーム」を選択します。

これにより、inputTextコンポーネントを使用し、フィールドのデータを編集可能なフォームが作成されます。

2. 「フォームの作成」ダイアログで、追加するフィールドとボタンをフォームに設定し、「OK」をクリックします。

3. 必要に応じて、「データ・コントロール」パネルから、フォームに追加するコレクションに関連付けられている追加操作を選択し、ポップアップ・メニューから「ADFボタン」または「ADFリンク」を選択します。

たとえば、国を削除できるようにする場合は、Countriesコレクションに関連付けられているDelete操作を選択します。図31-10に、Countriesコレクションに関連付けられている操作を示します。

図31-10 コレクションに関連付けられている操作

4. 変更内容を保存するかキャンセルする場合はページに操作を追加します。

ページが、バインド・タスク・フロー内のトランザクションの一部でない場合、ユーザーが変更をコミットまたはロールバックできるようにするためのボタンを作成する必要があります。「データ・コントロール」パネルから、ルートレベル・データ・コントロールに関連付けられたCommit操作とRollback操作をドラッグし、コマンド・ボタンまたはコマンド・リンクのいずれかとしてドロップします。図31-11に、BackOfficeAppModuleDataControlデータ・コントロールのコミット操作とロールバック操作を示します。

図31-11 データ・コントロールのCommit操作とRollback操作

ページが、バインド・タスク・フロー内のトランザクションの一部である場合、タスク・フロー・リターン・アクティビティを作成する際のトランザクションを解決する値としてCommitまたはRollbackを入力します。詳細は、「タスク・フローのトランザクションの管理」を参照してください。

ADFビジネス・コンポーネント以外のビジネス・サービスに基づいたデータ・コントロールにフォームを作成する場合は、CommitおよびRollback操作を使用できない場合があります。詳細は、「ステートレス・ビジネス・サービスのデータ・コントロールに関する必知事項」を参照してください。

5. 必要に応じて、各編集可能なフィールドのautoSubmitプロパティをtrueに変更します。

これを行うことにより、フィールドを変更してボタンをクリックするなど、別のイベント・シーケンスによってCommitおよびRollback操作が有効になっていない場合に、フィールドからタブアウトし、これらを有効にしたときに、ユーザーの変更をページに送信できるようになります。

フィールドを選択し、「プロパティ」ウィンドウの「動作」セクションにスクロールして、フィールドのautoSubmitプロパティにアクセスできます。

ヒント:

編集フォームを作成する同じページにフォームと同じコレクションから作成された表がある場合にも、表およびフォームは同じイテレータ・バインディングを使用し、これにより、表で行を選択することによってユーザーがフォームで編集するレコードを選択できるようになります。データバインドされた表を作成する方法の詳細は、「基本表の作成」を参照してください。

31.6.2 フォームの作成時の処理

ページにコレクションをドロップする場合の処理の詳細は、「データ・コントロール・コレクションを使用したフォームの作成時の処理」を参照してください。

コマンド・ボタンとして任意のデータ・コントロール操作をドロップすると、ナビゲーション操作をドロップするときと同様のコードが生成されます。詳細は、「操作を使用したコマンド・コンポーネント作成時の処理」を参照してください。

イテレータとは異なり、Commit操作とRollback操作はアプリケーション・モジュール(データ・コントロール自身)でメソッドを実行するため、これらの操作のアクション・バインディングがイテレータへの参照を必要としないことが、唯一の相違点です。RollbackアクションのRequiresUpdateModelプロパティはfalseに設定されています。これは、すべての変更は破棄する必要があるので、操作の実行前にモデルは更新されないためです。次の例は、これらの操作に対するページ定義ファイルに生成されたアクション・バインディングを示しています。

<action id="Commit" RequiresUpdateModel="true" Action="commitTransaction"
DataControl="BackOfficeAppModuleDataControl"/>
<action id="Rollback" RequiresUpdateModel="false"
Action="rollbackTransaction"
DataControl="BackOfficeAppModuleDataControl"/>

表31-2に、データ・コントロールおよびデータ・コントロール・オブジェクトで提供されるナビゲーション以外の組込み操作と、操作の起動または操作にバインドされたイベントの実行の結果を示します。アクション・イベントの詳細は、「実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法」を参照してください。

表31-2 追加の組込み操作

操作

関連イテレータ・バインディングによる起動時の処理

CreateInsert

現在の行の直前に行を作成し、行セットに新しいレコードを挿入して、現在行ポインタを新しい行に移動します。レンジは移動しないため、レンジの最後の行が結果的にレンジから除外される可能性があります。CreateInsert操作を使用したオブジェクトの作成の詳細は、「入力フォームの作成」を参照してください。

注意: CreateInsertはADFビジネス・コンポーネント・アプリケーション・モジュールに基づいたデータ・コントロールでのみ使用可能です。

Create

現在の行の直前に行を作成し、現在行ポインタを新しい行に移動します。レンジは移動しないため、レンジの最後の行が結果的にレンジから除外される可能性があります。

アプリケーション・モジュールおよびほとんどの他のビジネス・サービスに基づいたデータ・コントロールの場合、ユーザーが実際にデータを作成することなく移動した場合の空白行を避けるため、行セットにレコードは挿入されません。新しい行は、ユーザーがデータを送信すると作成されます。詳細は、「CreateおよびCreateInsertに関する必知事項」を参照してください。ただし、JPAベースのデータ・コントロールの場合、Create操作がデータを行セットに挿入するため、データを永続化するように構成できます。詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールの組込み操作に関する項を参照してください。

CreateWith Parameters

CreateInsert操作と同じ(新規レコードが行セットに挿入されます)。ただし、オブジェクトの作成に名前付きパラメータが使用されます。

注意: Create With ParametersはADFビジネス・コンポーネント・アプリケーション・モジュールに基づいたデータ・コントロールでのみ使用可能です。

Delete

現在の行をキャッシュから削除し、現在行ポインタを結果セットの次の行に移動します。レンジは移動しないため、レンジの最後に行が追加される可能性があります。最後の行が削除された場合、現在行ポインタはその前の行に移動します。コレクション内の行がなくなると、有効な属性がdisabledに設定されます。

RemoveRowWithKey

入力フィールドによって指定された値から変換されたStringとして行キーを使用し、バインドされたデータ・コレクションのデータ・オブジェクトを削除します。

SetCurrentRowWithKey

行キーを、入力フィールドで指定された値から変換されたStringとして設定します。行キーは、バインドされたデータ・コレクション内のデータ・オブジェクトの現状設定に使用されます。使用例は、「表での現在行の設定に関する必知事項」を参照してください。

SetCurrentRowWithKeyValue

キーの値を使用して、イテレータの現在のオブジェクトを設定します。詳細は、「表での現在行の設定に関する必知事項」を参照してください。

ExecuteWithParams

パラメータとして渡された名前付きのバインド変数に新しい値を割り当てた後で、ビュー・オブジェクトの問合せを(再)実行することにより、データ・コレクションをリフレッシュします。この操作は、CreateInsert操作を使用して入力フォームを作成するのと同じ方法で使用します。詳細は、「入力フォームの作成」を参照してください。

この操作は、設計時に1つ以上の名前付きバインド変数が定義されているビュー・オブジェクトの場合のみ表示されます。詳細は、「バインド変数の使用」を参照してください。

EJBおよびBeanデータ・コントロールの場合、この操作はパラメータ使用の問合せに基づくデータ・コントロール・コレクション・オブジェクトでのみ使用可能です。

Commit

現在キャッシュ内にあるすべての項目をデータベースにコミットします。

Rollback

キャッシュをクリアして、トランザクションおよびイテレータを初期状態に戻します。ActionListenerメソッドをリセットします。

ExecuteおよびFind

これらの操作は、検索フォームでのみ使用されます。詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

31.6.3 ステートレス・ビジネス・サービスのデータ・コントロールに関する必知事項

ADFビジネス・コンポーネント・サービスに基づいてユーザー・インタフェースを作成する場合は、ユーザーが行うどのデータ変更もユーザーがコマンド・コンポーネントを使用してCommit操作を行うまで基本のデータベースに伝搬されません。

ステートレスEJBセッションBeanまたはRESTful Webサービスなど、ステートレス・ビジネス・サービスのデータ・コントロールに基づくユーザー・インタフェースの場合、CommitおよびRollback操作が使用できません。そのような場合は、基本のデータベースとの対話を処理するカスタム・メソッドを使用できます。EJBデータ・コントロールの場合、セッションBeanのpersistEntityおよびmergeEntityメソッドは、「データ・コントロール」パネルを使用して公開され、それらからコマンド・コンポーネントを作成できます。詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のEJBセッションBeanのコミット・モデルに関する項を参照してください。

31.7 フォームを作成するためのパラメータの使用

Oracle ADFでは、表示されるレコードが入力パラメータによって決定されるフォームを作成できる方法がいくつかあります。これらのメカニズムは次のとおりです。

- データ・コントロールのExecuteWithParams操作またはパラメータをとるカスタム・メソッドに基づいてADFパラメータ・フォームを作成します。

- パラメータをタスク・フローからフォームに渡します。

- コマンド・コンポーネント内でsetPropertyListenerタグをネストして、パラメータにアクセスし、必要なロジックを起動するためにマネージドBean内にアプリケーション・ロジックを提供します。

この項では、ExecuteWithParams操作に基づいたADFパラメータ・フォームの作成について説明します。パラメータをタスク・フローからフォームに渡す方法の詳細は、「タスク・フローのパラメータの使用」および「ADFリージョンのパラメータの指定」を参照してください。setPropertyListenerタグの使用方法の詳細は、「コマンド・コンポーネントを使用したパラメータ値の設定」を参照してください。

ExecuteWithParams操作は、バインド変数を含むビュー・オブジェクトに基づくものやパラメータとともに名前付き問合せを含むJPAベースのBeanに基づくものなど、パラメータを含むデータ・コントロール・オブジェクトに対してのみ使用可能です。たとえば、Summit ADFサンプル・アプリケーションには、バインド変数TitleIdBindを含む、EmpVOビュー・オブジェクトに基づくSalesPeopleと呼ばれるビュー・オブジェクト・インスタンスが含まれます。そのため、図31-12に示すように、SalesPeopleオブジェクトには、TitleIdBindパラメータのサブノードとともにExecuteWithParams操作が含まれます。

図31-12 「データ・コントロール」パネルのExecuteWithParams操作

ビュー・オブジェクト・バインド変数およびJPAパラメータ付き問合せを使用すると、実行時にビュー・オブジェクトまたはビュー基準に属性値を組み込むことができます。ExecuteWithParams操作により、パラメータとして渡された名前付きのバインド変数に新しい値を割り当てた後で、ビュー・オブジェクトの問合せを(再)実行することにより、データ・コレクションがリフレッシュされます。ビュー・オブジェクトのバインド変数の詳細は、「バインド変数の使用」を参照してください。JPA問合せの名前付きパラメータの詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のEJBデータ・コントロールの前提条件と考慮事項に関する項を参照してください。

31.7.1 パラメータを使用するフォームの作成方法

パラメータを使用するフォームを作成するには、ADFパラメータ・フォームとしてページにコレクションのExecuteWithParams操作をドロップし、ADFフォームとしてコレクション自体をドロップします。

始める前に:

パラメータ・フォームの作成について理解しておくと役立ちます。詳細は、「フォームを作成するためのパラメータの使用」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「ビュー・オブジェクト定義にWHERE句のバインド変数を追加する方法」に従ってビュー基準の定義にバインド変数を追加します。
JPAベースのデータ・コントロールの場合、名前付きパラメータを指定するセッションBeanまたはサービス・ファサードに名前付き問合せを作成できます。詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のEJBデータ・コントロールの前提条件と考慮事項に関する項を参照してください。

- 「Webページの作成」の説明に従って、JSFページを作成します。

ExecuteWithParams操作に基づいたパラメータ・フォームを作成するには:

1. 「データ・コントロール」パネルから、フォームを作成するコレクションのExecuteWithParams操作をドラッグし、ポップアップ・メニューから「ADFパラメータ・フォーム」を選択します。

2. 「フォームの作成」ダイアログで、ユーザーが問い合せることができるパラメータを選択し、「OK」をクリックします。

3. 「データ・コントロール」パネルから、対応するコレクションをドラッグし、ユーザー入力に基づいて問合せ結果を表示したい表またはフォームのタイプとしてそれをドロップします。

注意:

選択リストをパラメータ・フォームに宣言的に組み込むこともできます。選択リストを作成するには、フォームにExecuteWithParams操作の子であるパラメータ・ノードをドラッグします。次にExecuteWithParams操作をドラッグして、それをボタンとしてドロップします。

31.7.2 パラメータ・フォームの作成時の処理

ExecuteWithParams操作をパラメータ・フォームとしてドロップすると、JDeveloperによって次の処理が行われます。

- 属性バインディングにバインドされているinputTextコンポーネントおよびExecuteWithParams操作にバインドされているbuttonコンポーネントを使用して、JSFページにフォームのコードが挿入されます。

- ページ定義ファイルに次のものを定義します。

- 変数にアクセスするために使用する属性の変数イテレータ(他のフォームに対して使用されるコレクションのイテレータとは異なります)。

- データ値を保持するための各パラメータに対するvariableUsage変数。これらの変数は、バインドされるビュー・オブジェクトの名前付きバインド変数からデフォルト値やUIコントロール・ヒントを継承します。変数はローカルであり、単一リクエスト中にのみ存続します。同じフォームに後続のポストバック間で運ばれるが、ユーザーが他のいくつかのページに移動する場合は無視されます(再度初期化されます)。

- 各パラメータのNamedData要素を含む操作のアクション・バインディング。各NamedData要素は、対応する変数にバインドされます。これらのバインディングにより、操作は、実行時にパラメータに対する値にアクセスできます。

- 関連付けられた属性の属性バインディング。

次の例は、ページ上にSalesPeopleコレクションのExecuteWithParams操作をドロップすることによって作成されるページ定義ファイル内の実行可能ファイルおよびバインディングを示しています。

<executables>
<variableIterator id="variables">
<variableUsage DataControl="BackOfficeAppModuleDataControl"
Binds="SalesPeople.variablesMap.TitleIdBind"
Name="ExecuteWithParams_TitleIdBind" IsQueriable="false"/>
</variableIterator>
<iterator Binds="SalesPeople" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="SalesPeopleIterator"/>
</executables>
<bindings>
<action IterBinding="SalesPeopleIterator" id="ExecuteWithParams"
RequiresUpdateModel="true"
Action="executeWithParams">
<NamedData NDName="TitleIdBind" NDType="java.lang.Integer"
NDValue="${bindings.ExecuteWithParams_TitleIdBind}"/>
</action>
<attributeValues IterBinding="variables" id="TitleIdBind">
<AttrNames>
<Item Value="ExecuteWithParams_TitleIdBind"/>
</AttrNames>
</attributeValues>
</bindings>

パラメータ・フォームの結果を表示するために使用されるコレクションをドロップすると、「データ・コントロール・コレクションを使用したフォームの作成時の処理」で説明しているように、基本フォーム用のコードが生成されます。また、表を使用して結果を表示した場合は、表のpartialTriggersプロパティがパラメータ・フォームのコマンド・ボタンに設定されます。

31.7.3 実行時に行われる処理: パラメータの移入方法

ページがレンダリングされる場合、フレームワークにより、ページが最初にレンダリングされるか、例外リストに任意のアイテムがあるかどうかがチェックされます。両方がfalseの場合、フレームワークにより、ExecuteWithParamsアクション・バインディングが実行されます。このアクション・バインディングでは問合せが実行され、必須パラメータの値として名前付きデータ要素の値が取得されます。

31.8 入力フォームの作成

ユーザーが新規レコードの情報を入力し、そのレコードをデータ・ソースにコミットするためのフォームを作成できます。基本的な入力フォームの作成は、入力フォームにCreateInsert操作も含まれるということを除いて、編集フォームの作成と同じであり、ユーザーがフォームを使用して移入できる行セットに空白行が挿入されます。

「データ・コントロール」パネルからページにコレクションおよび適切な操作をドラッグ・アンド・ドロップすることにより、単純な入力フォームを作成できます。ただし、ユーザー・ワークフローを制御し、他のフォームの処理ロジックを挿入するために、他の手法を選択する必要がある場合があります。このような手法は次のとおりです。

- ADFタスク・フローのパラメータを使用して、新しいレコードの指定された属性を事前移入する値を渡します。詳細は、「ビュー・アクティビティへのパラメータ渡し」を参照してください。

- 「タスク・フロー・リターン・アクティビティの使用」の説明に従って、タスク・フロー・リターン・アクティビティを使用して、UIにトランザクション境界を設定します。

- 「バインド・タスク・フローへのパラメータ渡し」の説明に従って、タスク・フロー・メソッド・コールで操作を埋め込みます。

- 「宣言メソッドのオーバーライド」の説明に従って、マネージドBeanを使用して、いくつかの操作を実行します。

- 「リージョンとしてのタスク・フローの使用」の説明に従って、フォームをタスク・フローのリージョンに組み入れます。

- 「バインド・タスク・フローでのトレイン・コンポーネントの使用」の説明に従ってフォームをマルチステップ・フローに組み入れます。

- 「モーダル・ダイアログ内でのバインド・タスク・フローの実行」の説明に従って、ダイアログ内にフォームを配置します。

- 「タスク・フローのトランザクションの管理」の説明に従って、セーブポイントを使用します。

次のセクションでは、基本的な入力フォームの作成方法について説明し、またいくつかのバリアントに関する情報を提供します。

31.8.1 入力フォームの作成方法

基本的な入力フォームの作成には、編集フォームの作成および新規レコードを作成するためのコマンド・コンポーネントの追加が含まれます。

始める前に:

入力フォームについて理解しておくと役立ちます。詳細は、「入力フォームの作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「編集フォームの作成方法」の説明に従って、編集フォームを作成します。

入力フォームの作成方法:

1. 「データ・コントロール」パネルで、フォームがベースとするコレクション・オブジェクトのノードを開きます。

2. コレクションの「操作」ノードを開き、CreateInsert操作を編集フォームにドラッグします。

注意:

CreateInsert操作はADFビジネス・コンポーネント・アプリケーション・モジュールに基づいたデータ・コントロールでのみ使用可能です。データ・コントロールが別のビジネス・サービスに基づく場合は、かわりにCreate操作を使用します。2つの間の相違の詳細は、表31-2を参照してください。

31.8.1.1 バインド・タスク・フローを使用した入力フォームの作成

入力フォームのワークフローを提供するタスク・フローを使用できます。コマンド・コンポーネントを使用して新規オブジェクトを作成するのではなく、タスク・フロー内でメソッド・コール・アクティビティを使用するか、マネージドBeanのメソッドを使用します。コマンド・コンポーネントを使用して変更をコミットするのではなく、タスク・フロー・リターン・アクティビティを使用します。

たとえば、タスク・フローのメソッド・コール・アクティビティを使用して、データ・コントロール・オブジェクトのCreateInsert操作をコールして、ユーザーがデータを入力可能なフォームを表示するビュー・アクティビティにコントロールを渡すことができます。

バインド・タスク・フロー内で入力フォームを作成するには:

1. 「タスク・フローの作成」の説明に従って、バインド・タスク・フローを作成します。

2. 「プロパティ」ウィンドウの「トランザクション」プロパティを「常に新規トランザクションを開始」に設定します。

詳細は、「タスク・フローのトランザクションの管理」を参照してください。

3. バインド・タスク・フローで、メソッド・コール・アクティビティを追加します。

詳細は、「メソッド・コール・アクティビティの使用」を参照してください。

4. 「データ・コントロール」パネルから、フォームを作成しているコレクションに関連付けられているCreateInsert操作をドラッグし、それをメソッド・アクティビティにドロップします。

5. メソッド・コール・アクティビティを選択したままにして、「プロパティ」ウィンドウで、fixed-outcomeプロパティの文字列を入力します。CreateInsert操作をメソッド・コール・アクティビティにドロップした後で、この値はCreateInsertに設定されますが、さらに具体的なものに変更できます。

6. タスク・フローの概要エディタで、入力フォームのページを表すビュー・アクティビティを追加します。ビュー・アクティビティの追加の詳細は、「タスク・フローへのアクティビティの追加」を参照してください。

7. 制御フロー・ケースをメソッド・アクティビティからビュー・アクティビティに追加します。

8. 設計エディタでコントロール・フロー・ケースを選択した状態にして、「プロパティ」ウィンドウで、制御フロー・ケースのfrom-outcomeプロパティが手順5で設定したメソッド・アクティビティのfixed-outcomeプロパティの値と同じであることを確認します。

9. 設計エディタでビュー・アクティビティのページを開き、「データ・コントロール」パネルから、新しいレコードの作成にフォームを使用するコレクションをドラッグし、ポップアップ・メニューから「ADFフォーム」を選択します。

10. タスク・フローに、リターン・アクティビティを追加します。このリターン・アクティビティでは、データ・コントロールに対してcommit操作を実行する必要があります。これらの手順については、「タスク・フロー・リターン・アクティビティの使用」を参照してください。

31.8.1.2 タスク・フロー内でリターン・アクティビティのかわりにコマンド・ボタンを使用する方法

通常、Commit操作をコールするには、リターン・アクティビティを使用する必要があります。ただし、タスク・フローに複数のデータ・コントロールによって管理されるデータが含まれる場合や、フローの終了前にデータをコミットする必要がある場合など、Commit操作にコマンド・コンポーネントを使用する必要がある場合があります。

フォーム内に「コミット」ボタンを持つ入力フォームを作成するには:

1. 「バインド・タスク・フローを使用した入力フォームの作成」の説明に従って、入力フォームを作成します。

2. 「データ・コントロール」パネルで、入力フォームに関連付けられたコレクションを含むデータ・コントロールのCommit操作をドラッグし、コマンド・ボタンとしてドロップします。

3. 構造ウィンドウで、commit操作のコマンド・ボタンを選択します。

4. 「プロパティ」ウィンドウで、メソッド・アクティビティに戻る結果文字列にactionを設定します。同じoutcome値を使用して、ページからアクティビティに戻る制御フロー・ケースを追加する必要があります。

5. コマンド・ボタンのdisabledプロパティをfalseに設定します。

デフォルトでは、ボタンのdisabled属性がバインディングのenabledプロパティにバインドされ、その結果、enabledプロパティがfalseに設定された場合にボタンが無効になります。このバインディングでは、enabledプロパティは更新がポストされるまでfalseです。変更がポストされるには、その前にユーザーが新しいオブジェクトを作成する必要があるため、入力フォームの目的上、ボタンは常に有効にする必要があります。

31.8.1.3 単一トランザクションでの複数エントリを許可する入力フォームの作成

データベースにコミットする前に、ユーザーが複数のエントリを作成できるようにする場合、次のようにします。

単一トランザクションでの複数エントリを許可する入力フォームを有効にするには:

1. 「バインド・タスク・フローを使用した入力フォームの作成」の説明に従って、入力フォームを作成します

2. タスク・フローで、ビュー・アクティビティからメソッド・アクティビティに戻る別の制御フロー・ケースを追加し、from-outcomeメソッドの値を入力します。たとえば、createAnotherと入力します。

3. 「コンポーネント」ウィンドウからコマンド・コンポーネントをページにドラッグ・アンド・ドロップし、action属性を、先ほど作成したfrom-outcomeに設定します。これによって、タスク・フローはメソッド・アクティビティに戻り、CreateInsert操作を再起動します。

31.8.2 入力フォームの作成時の処理

ADFフォームを使用して入力フォームを作成すると、JDeveloperによって次の処理が行われます。

- メソッド・アクティビティのページ定義でコレクションのイテレータ・バインディングおよびCreateInsert操作のアクション・バインディングが作成されます。CreateInsert操作は、行を行セットに作成し、データ・ソースに入力されたデータを移入します。その他のフォームに関しては、ページのページ定義で、コレクションのイテレータ・バインディングと、コレクション内のオブジェクトの各属性について属性バインディングが作成されます。Commit操作およびRollback操作を使用してコマンド・ボタンまたはリンクを作成した場合、JDeveloperではこれらの操作のアクション・バインディングも作成されます。

- ADF Faces inputTextコンポーネントおよび操作の場合はbuttonコンポーネントを使用して、JSFページにフォームのコードが挿入されます。

31.8.3 実行時に行われる処理: メソッド・アクティビティからのCreateInsertアクション

CreateInsertボタンをクリックする(またはその操作に対応するメソッドをコールする)と、CreateInsertアクション・バインディングが起動され、CreateInsertRow操作が実行されてコレクション用に空白の新規インスタンスが作成されます。

注意:

CreateInsert操作をコールするタスク・フロー・メソッド・アクティビティを使用する場合、メソッド・アクティビティからビュー・アクティビティへのルーティング中、メソッド・アクティビティのバインディング・コンテナは必須属性の検証をスキップするため、空白のインスタンスがページ上のフォームに表示できます。

31.8.4 順序番号の表示に関する必知事項

ページが表示される前にCreateアクションが実行されるため、順序を使用して主キーを移入する場合は、空である他のフィールドとは異なり、次の順序番号が入力テキスト・フィールドに表示されます。順序番号が表示されるのは、関連するエンティティ・クラスに、Eagerフェッチを使用して主キー属性の番号の順序を生成するメソッドが含まれるためです。Eagerフェッチにより、行が作成される際に値が移入されます。そのため、順序を使用すると想定どおりに入力フォームが動作します。

ただし、かわりに属性のタイプをDBSequence(データベース・トリガーを使用して順序を生成する)に構成した場合、オブジェクトがデータベースにコミットされるまで番号は移入されません。この場合は、プレースホルダとして負の数が表示されます。この状態を回避するには、入力テキスト・フィールドのRendered属性に次のEL式を使用できます。

#{bindings.EmployeeId.inputValue.value > 0}

この式では、値がゼロより大きい場合のみコンポーネントが表示されますが、これはコミット前には発生しません。同様に、Rendered属性を単純にfalseに設定することもできます。ただし、その場合は主キーの入力テキスト・フィールドのコンポーネントがページに表示されることはありません。

31.8.5 ステートレス・サービスにバックアップされた入力フォームに関する必知事項

入力フォームのベースとなるデータ・コントロールがステートレス・ビジネス・サービスのデータ・コントロールである場合、データ・ソースに変更を保存するために使用する組込みCommit操作はありません。

かわりに、カスタム・メソッドを使用して、データベースに保存する必要があります。詳細は、「ステートレス・ビジネス・サービスのデータ・コントロールに関する必知事項」を参照してください。

31.9 動的コンポーネントを使用したフォームの作成

ページ内で直接各コンポーネントにタグを提供する静的データバインド・フォームを作成するかわりに、動的コンポーネントを使用して、バインディング・メタデータおよびバインド・コンテンツを表示するために使用されるコンポーネントが実行時に決定されるフォームを作成できます。

この項では、データバインドされた動的フォームの作成について説明します。動的コンポーネントを使用して、データバインドされた表を作成することもできます。詳細は、「動的コンポーネントを使用した表の作成」を参照してください。

動的フォーム・コンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の実行時のコンポーネントの決定に関する項を参照してください。

31.9.1 動的コンポーネントについて

ADF Facesでは、バインディング・メタデータおよびバインド・コンテンツを表示するために使用されるタグが実行時に決定される、モデルドリブン・フォームおよび表の作成に使用可能なdynamicComponentタグが提供されます。

バインディングのこの動的作成では、次の機能が提供されます。

- 表示されるフィールドおよびこれらのフィールドを表示するために使用されるADF Facesをデータ・モデルによって決定するページを作成できます。追加列や変更されたUIヒントなどのデータ・モデルへの変更は、ページを再設計する必要なしに、ページに反映されます。ビュー・オブジェクトのUIヒントの詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

- 多相ビュー・オブジェクトに基づいてページを作成できます。これらのビュー・オブジェクトでは、指定されたレコードに対して使用可能なフィールドがレコードのベース・エンティティ・オブジェクトによって異なる場合があります。表示するフィールドは実行時に決定されるため、特定のレコードに適用されない可能性のあるページにこれらのフィールドを含めたり、指定されたレコードに対して表示されるフィールドを調整するためにビュー・レイヤーでコーディングを行う必要はありません。複数の行タイプを処理するビジネス・コンポーネントの構築の詳細は、「多相ビュー・オブジェクトの定義」を参照してください。

コントロールをページにドロップする際に「フォームの作成」または「表の作成」ダイアログで情報を構成するのではなく、ビュー・オブジェクトのUIヒントを使用して表示情報を設定します。その結果、データの表示方法を変更する場合に、ビュー・オブジェクトで表示方法を変更するだけで、そのビュー・オブジェクトにバインドされているすべての動的コンポーネントの表示はそれに従って変更されます。

図31-13は、CustomerVOビュー・オブジェクトで属性に対するUIヒントを設定し、動的フォームとしてCustomersデータ・コントロール・コレクションをドロップすることにより設計された実行時の動的フォームを示しています。設定されたUIヒントにはLABELおよびDISPLAYHINTがあります(後者は、動的フォームに指定された属性を含めないようにHideに設定できます)。

図31-13 ビュー・オブジェクトに設定されたヒントに基づいた動的フォームの表示

次のADF Facesコンポーネントは、設計時にaf:dynamicComponentを使用する場合に、実行時にレンダリングできます。

- af:inputText

- af:inputDate

- af:inputListOfValues

- af:selectOneChoice

- af:selectManyChoice

- af:selectOneListbox

- af:selectManyListbox

- af:selectOneRadio

- af:selectBooleanRadio

- af:selectBooleanCheckbox

- af:selectManyCheckbox

31.9.2 動的フォームの作成方法

動的フォームを作成するには、コレクションをADFフォームとして「データ・コントロール」パネルからドロップして、フィールドが動的に生成されるように指定します。

始める前に:

動的フォームについて理解しておくと役立ちます。詳細は、「動的コンポーネントを使用したフォームの作成」を参照してください。

様々な属性を含むレコードの表示に動的フォームを利用する場合は、最初にその機能を含むデータ・オブジェクトが必要です。この機能を含むビュー・オブジェクトの作成の詳細は、「多相ビュー・オブジェクトの定義」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

動的フォームを作成するには:

1. 動的フォームを作成しているコレクションに対応するビュー・オブジェクトまたはデータ・コントロール構造にUIヒントを設定します。

UIヒントにより、属性、ラベル、ツールチップ、フィールドを自動的に送信する必要があるかどうかなどを表示するために使用するUIコンポーネントのタイプなどが決定されます。UIヒントの作成手順は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

2. 必要に応じて、各ビュー・オブジェクト属性のCategoryヒントに対して、カテゴリを指定するか、「新規カテゴリ」アイコンをクリックして、新規カテゴリを作成します。

同じカテゴリを持つ属性は、そのビュー・オブジェクトに基づいて作成する動的フォームでまとめることができます。

3. 必要に応じて、手順2で作成したカテゴリに対して、カテゴリのラベルおよびツールチップ用にUIヒントを設定します。これらはビュー・オブジェクトの概要エディタの「UIカテゴリ」タブで設定できます。

4. 「データ・コントロール」パネルから、ビュー・オブジェクトを表すコレクションを選択します。

5. コレクションをページにドラッグし、ポップアップ・メニューから「ADFフォーム」を選択します。

6. 「フォームの作成」ダイアログで、「実行時に生成されるフィールド」チェック・ボックスを選択します。

7. 手順2で属性のカテゴリを指定した場合は、これらのカテゴリに従ってフォームで属性をグループ化するために「フィールド・グループを含める」チェック・ボックスを選択します。

31.9.3 動的フォームの作成時に発生する処理

コレクションをページに動的フォームとしてドロップする場合、次の処理が発生します。

- ページ定義はvariableIteratorバインディング、イテレータへのiteratorバインディングおよびtree値バインディングで移入されます。

- JSFページは1つ以上のiteratorおよびdynamicComponentタグで移入されます。また、「フィールド・グループを含める」オプションが選択されている場合は、switcherおよびgroupタグが追加されます。

31.9.3.1 動的フォームに対して作成されるバインディング

動的フォームのページ定義ファイルには次の実行可能ファイルおよびバインディングが含まれます。

- variableIterator: バインディング・コンテナに対して宣言された変数を格納する内部イテレータ。

- iterator: コレクションに対するイテレータ・バインディング。イテレータ・バインディングの詳細は、「ページ定義ファイルに作成されるイテレータ・バインディング」を参照してください。

- tree: コレクションの属性に対する値バインディング。設計時に各属性に対する個々の値バインディングがある標準フォームとは異なり、動的フォームは、実行時に公開される属性値を含むように単一ツリー値バインディングを使用します。
また、ツリー値バインディングは、データバインドされた表(標準および動的の両方)にも使用されます。詳細は、「表のイテレータと値バインディング」を参照してください。

次の例は、Customersコレクションに基づく動的フォーム・コンポーネントを含むページのバインディングを示しています。

<executables>
<variableIterator id="variables"/>
<iterator Binds="SummitAppModuleDataControl.dataProvider.BackOfficeAM.Customers"
DataControl="SummitAppModuleDataControl" RangeSize="25" id="CustomersIterator"/>
</executables>
<bindings>
<tree IterBinding="CustomersIterator" id="Customers">
<nodeDefinition DefName="oracle.summit.model.views.CustomerVO" Name="Customers0"/>
</tree>
</bindings>

31.9.3.2 グループ化しないで動的フォームに対して作成されるタグ

JSFページで、JDeveloperによってiteratorタグが挿入され、その内部で、dynamicComponentタグがネストされます。iteratorタグは、実行時にコレクションによって公開される属性のすべてをループし、dynamicComponentタグを使用してページ上の各属性に対する適切なコンポーネントをレンダリングします。

次の例は、動的フォームとしてCustomersデータ・コントロール・オブジェクトをドロップした(「フィールド・グループを含める」オプションは選択していない)場合に生成されるコードを示しています。

<af:panelFormLayout id="pfl1">
<af:iterator id="i1" value="#{bindings.Customers.attributesModel.attributes}"
var="attr">
<af:dynamicComponent id="d2" attributeModel="#{attr}"/>
value="#{bindings[attr.containerName][attr.name].inputValue}"/>
</af:iterator>
</af:panelFormLayout>

iteratorタグのvalue属性では、コレクションのツリー・バインディングのattributesModel.attributesプロパティに評価するEL式を使用します。attributesModelプロパティは、コンポーネント・タイプ、ラベル、ツールチップ、レンダリングされる実際のコンポーネントの他のプロパティなど、データ・オブジェクトの属性およびそのメタデータを取得するために使用されます。attributesModelのattributesプロパティは、表示可能属性およびそのメタデータのフラット(非階層的)リストが提供されていることを示します。

dynamicComponentタグのattributeModel属性は、EL式#{attr}にバインドされ、イテレータのvar属性で定義される変数を参照し、データ・コントロール・コレクションおよびその対応するメタデータの現在の属性へのポインタとして機能します。dynamicComponentのvalue属性のEL式は、変数attrも参照します。

31.9.3.3 グループ化して動的フォームに対して作成されるタグ

「フォームの作成」ダイアログの「フィールド・グループを含める」を選択している場合、生成されたJSFページには、「グループ化しないで動的フォームに対して作成されるタグ」で説明するタグ以外に、switcherタグとgroupタグが含まれます。

switcherタグには、iteratorタグ内で直接ネストされます。switcherタグ内には、GROUPおよびATTRIBUTEという名前のネストされたfacetタグがあります。GROUPファセットにはgroupタグが含まれ、その内部に、グループ名とiteratorタグを表示するoutputTextタグがあり、それにはdynamicComponentタグが含まれます。ATTRIBUTEファセットにはdynamicComponentタグのみが含まれます。

高レベルのiteratorが反復する各属性の場合、切替え機能により、グループまたは列をレンダリングするかどうかが動的に決定されます。グループをレンダリングする場合、グループ内のイテレータはそのグループ内の属性のコンポーネントをレンダリングするために使用されます。

次の例は、Customersコレクションに基づいた動的フォームを作成し、フィールド・グループを含むように選択した場合に生成されるコードを示しています。

<af:panelFormLayout id="pfl1">
<af:iterator id="i1"
value="#{bindings.Customers.attributesModel.hierarchicalAttributes}"
var="attr">
<af:switcher id="sw1" facetName="#{attr.descriptorType}"
defaultFacet="ATTRIBUTE">
<f:facet name="GROUP">
<af:group title="#{attr.label}" id="g1">
<af:outputText value="#{attr.name}" id="ot1"/>
<af:iterator id="gi1" value="#{attr.descriptors}"
var="nestedAttr">
<af:dynamicComponent id="gd1"
attributeModel="#{nestedAttr}"/>
</af:iterator>
</af:group>
</f:facet>
<f:facet name="ATTRIBUTE">
<af:dynamicComponent id="ad1" attributeModel="#{attr}"/>
</f:facet>
</af:switcher>
</af:iterator>
</af:panelFormLayout>

iteratorタグのvalue属性では、コレクションのツリー・バインディングのattributesModel.hierarchicalAttributesプロパティに評価されるEL式を使用します。attributesModelプロパティは、コンポーネント・タイプ、ラベル、ツールチップ、レンダリングされる実際のコンポーネントの他のプロパティなど、データ・オブジェクトの属性およびそのメタデータを取得するために使用されます。hierarchicalAttributesプロパティは、UIヒントの属性に対して設定されたカテゴリを含む、表示可能属性およびそのメタデータの階層リストが提供されることを示します。

dynamicComponentタグのattributeModel属性は、EL式#{attr}に設定され、イテレータのvar属性で定義される変数を参照し、データ・コントロール・コレクションおよびその対応するメタデータの現在の属性(またはカテゴリ)へのポインタとして機能します。

31.9.4 実行時に行われる処理: 属性値の動的な決定方法

動的コンポーネントを含むページがレンダリングされると、設計時に「データ・コントロール」パネルから項目をドロップしたときと同様に、バインディングが作成されます。ただし、バインディングは実行時に作成されます。

実行時に、iteratorは、属性のセットを反復処理し、各属性のdynamicComponentをインスタンス化します。動的コンポーネントは、そのattributeModelプロパティを使用して、ラベルやコントロール・タイプなど、現在の属性に関するイテレータからの情報を取得します。次に各dynamicComponentは属性に対して戻されるメタデータに基づいてコンポーネントをレンダリングします。

属性のDISPLAYHINT UIヒントがHideに設定される場合、属性のコンポーネントはレンダリングされません。

動的フォームが多相ビュー・オブジェクトに基づくデータ・コントロール・オブジェクトから作成される場合、レンダリングされるコンポーネントは、現在選択されているレコードの行タイプによって異なります。

31.9.5 コンバータおよびバリデータの動的コンポーネントへの適用方法

デフォルトで、標準のADF Facesコンバータおよびバリデータは、動的コンポーネントを使用している場合に実行時に生成されるコンポーネントに適用されます。たとえば、converterDateTimeコンバータは、TimeStampタイプの属性に基づくコンポーネントに適用されます。

特定の検証または変換をコンポーネントに追加する必要がある場合は、ADF Facesバリデータおよびコンバータ・タグを動的コンポーネントのソースに追加することでこれを行い、タグのdisabled属性を使用してバリデータおよびコンバータが適用される属性を決定できます。

始める前に:

動的フォームについて理解しておくと役立ちます。詳細は、「動的コンポーネントを使用したフォームの作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「動的フォームの作成方法」の説明に従って動的フォームを作成するか、または「動的表の作成方法」の説明に従って動的表を作成します。

ADF Facesバリデータまたはコンバータを動的フォームに手動で挿入するには:

1. ソース・エディタで動的コンポーネントを含むページを開きます。

2. <af:dynamicComponent>タグ内に、使用するバリデータ・コンポーネントとコンバータ・コンポーネントを挿入します。

3. 各バリデータおよびコンバータ・タグ内で、disabled属性を挿入し、適用するものを除いてすべての属性のタグを無効にするEL式にそれをバインドします。

たとえば、次の式では、Hiredate属性に対してのみバリデータを有効にします。

#{attr.name == 'Hiredate' ? false : true}

次の例は、2つのバリデータおよび2つのコンバータが適用されている動的コンポーネントを示しています。

<af:panelFormLayout id="pfl1">
<af:iterator id="i1" value="#{bindings.EmpVO1.attributesModel.attributes}"
var="attr">
<af:dynamicComponent
value="#{bindings[attr.containerName][attr.name].inputValue}"
attributeModel="#{attr}" id="dc1"/>
<af:convertDateTime disabled="#{attr.name == 'Hiredate' ? false : true}"
pattern="yyyy/MM/dd"/>
<af:convertNumber disabled="#{attr.name == 'Sal' ? false : true}"
pattern="#,###,###" />
<af:validateLength disabled="#{attr.name == 'Job' ? false : true}"
maximum="10" hintMaximum="maxmum length is 10"/>
<af:validateLongRange disabled="#{attr.name == 'Sal' ? false : true}"
minimum="1000"/>
</af:dynamicComponent>
</af:iterator>
</af:panelFormLayout>

31.9.6 動的コンポーネントと静的コンポーネントの混在に関する必知事項

動的フォームを作成する場合は、基本的に、動的にレンダリングされるコンポーネントのブロックを作成します。そのコンポーネント・ブロックの前後に静的コンポーネントを配置できますが、そのブロック内に静的コンポーネントを分散させることはできません。

次の例は、可能な静的コンポーネントと動的コンポーネントの混在の粒度を示しています。3つのgroupタグから構成されます。その最初と3番目には静的コンテンツが含まれ、その2番目にはネストされたdynamicComponentタグとともにiteratorタグが含まれます。

<af:group title="static before dynamic" id="g1">
<af:separator id="sp2"/>
<af:inputText value="#{bindings.Empno.inputValue}" label="Static Empno"
required="#{bindings.Empno.hints.mandatory}"
columns="#{bindings.Empno.hints.displayWidth}"
maximumLength="#{bindings.Empno.hints.precision}"
shortDesc="#{bindings.Empno.hints.tooltip}" id="it1">
<f:validator binding="#{bindings.Empno.validator}"/>
<af:convertNumber groupingUsed="false"
pattern="#{bindings.Empno.format}"/>
</af:inputText>
</af:group>
<af:group title="dynamic part" id="g2">
<af:separator id="sp3"/>
<af:panelFormLayout id="pfl1">
<af:iterator id="i1" value="#{bindings.EmpVO1.attributesModel.attributes}"
var="attr">
<af:dynamicComponent
value="#{bindings[attr.containerName][attr.name].inputValue}"
id="dc1" attributeModel="#{attr}"/>
</af:iterator>
</af:panelFormLayout>
</af:group>
<af:group title="static after dynamic" id="g3">
<af:separator id="sp4"/>
<af:inputText value="#{bindings.Ename.inputValue}" label="Static Ename"
required="#{bindings.Ename.hints.mandatory}"
columns="#{bindings.Ename.hints.displayWidth}"
maximumLength="#{bindings.Ename.hints.precision}"
shortDesc="#{bindings.Ename.hints.tooltip}" id="it2">
<f:validator binding="#{bindings.Ename.validator}"/>
</af:inputText>
</af:group>
<af:button text="Back" id="cbb1" action="back"/>

31.9.7 動的コンポーネント動作をプログラム的に設定する方法

動的コンポーネントがレンダリングされる方法を決定する必要があるカスタム処理がある場合は、マネージドBeanでこれを行い、動的コンポーネントのattributeModelプロパティを適切なBeanメソッドにバインドできます。

始める前に:

動的フォームについて理解しておくと役立ちます。詳細は、「動的コンポーネントを使用したフォームの作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「動的フォームの作成方法」の説明に従って動的フォームを作成するか、または「動的表の作成方法」の説明に従って動的表を作成します。

動的コンポーネントの動作をプログラム的に設定するには:

1. 動的コンポーネントを含むUIプロジェクトで、oracle.adf.view.rich.model.BaseAttributeDescriptorクラスを拡張するJavaクラスを作成します。

次の例は、Sal属性のラベルにカスタム・スタイルを適用するメソッドを追加するサンプル・クラスを示しています。

public class CustomizedDescriptor extends BaseAttributeDescriptor
{
public CustomizedDescriptor(BaseAttributeDescriptor base)
{
_base = base;
}

public Object getLabelStyle()
{
if (getName().equals("Sal"))
return "color:red; font-weight:bold";
else
return null;
}

2. ページのマネージドBeanを作成します。詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

3. マネージドBeanで、手順1で作成したカスタム・ディスクリプタのインスタンスを戻すメソッドを作成します。次の例は、このようなメソッドを示しています。

public CustomizedDescriptor getCustomizedAttributes(String attrName)
{
// create value expression for "#{attrName}" and evaluate it to get object
// of "attr"
BaseAttributeDescriptor attrMetadata = null;
Class klass = null;

try
{
klass = ClassLoaderUtils.loadClass("oracle.adf.view.rich.model.BaseAttributeDescriptor");
}
catch (ClassNotFoundException e)
{
throw new RuntimeException("Can not find class oracle.adf.view.rich.model.BaseAttributeDescriptor");
}

FacesContext facesContext = FacesContext.getCurrentInstance();
ELContext elContext = facesContext.getELContext();
ValueExpression valueExpression = createValueExpression(attrName, klass);

if (valueExpression != null)
attrMetadata = (BaseAttributeDescriptor)valueExpression.getValue(elContext);

return new CustomizedDescriptor(attrMetadata);
}

4. 動的コンポーネントを含むページのソース・エディタで、動的コンポーネントのattributeModelプロパティをカスタマイズされた属性ディスクリプタを戻すマネージドBeanメソッドにバインドします。

次の例は、attributeModel属性がattributeCustomBeanマネージドBeanのgetCustomizedAttributesメソッドを参照するEL式に設定されるdynamicComponentタグを示しています。

<af:panelFormLayout id="pfl1">
<af:iterator id="i1" value="#{bindings.EmpVO1.attributesModel.attributes}"
var="attr">
<af:dynamicComponent value="#{bindings[attr.containerName][attr.name].inputValue}" attributeModel="#{attributeCustomBean.getCustomizedAttributes('attr')}" />
</af:iterator>
</af:panelFormLayout>

31.9.8 動的コンポーネントをプログラム的にアクセスする方法

ユーザー・アクションに基づいて変更を行うために、動的コンポーネント・インスタンスにプログラム的にアクセスする必要がある場合は、マネージドBeanを使用して行うことができます。

始める前に:

動的フォームについて理解しておくと役立ちます。詳細は、「動的コンポーネントを使用したフォームの作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「動的フォームの作成方法」の説明に従って動的フォームを作成するか、または「動的表の作成方法」の説明に従って動的表を作成します。

動的コンポーネントのバインディング・インスタンスにプログラム的に設定するには:

1. 動的コンポーネントを識別するマネージドBeanメソッドを作成して、RichDynamicComponentにコンポーネントをキャストし、変更を適用します。

詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

2. 動的コンポーネントを含むページでは、コマンド・コンポーネントをページに追加して、そのactionListenerプロパティをマネージドBeanメソッドにパインドします。

次の例は、動的コンポーネントのラベル・スタイルを変更するマネージドBeanメソッドを示しています。

public void changeLabelColor (ActionEvent event)
{
UIComponent component = event.getComponent().getParent();
component = component.findComponent("pfl1");

while(component != null)
{
if(component.getId().equals("it1"))
{
RichDynamicComponent rdc = (RichDynamicComponent)component;
rdc.setLabelStyle("color:red");
break;
}
else
component = component.getChildren().get(0);
}
}

31.9.9 動的コンポーネントのバインディング・インスタンスにプログラム的にアクセスする方法

動的コンポーネントの実行時バインディング・インスタンスにプログラム的にアクセスする必要がある場合は、マネージドBeanを使用してこれを行うことができます。

始める前に:

動的フォームについて理解しておくと役立ちます。詳細は、「動的コンポーネントを使用したフォームの作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「動的フォームの作成方法」の説明に従って動的フォームを作成するか、または「動的表の作成方法」の説明に従って動的表を作成します。

動的コンポーネントのバインディング・インスタンスにプログラム的にアクセスするには:

1. FacesContextを使用してバインディング・コンテナにアクセスするマネージドBeanメソッドを作成して、AttributesModelを取得し、必要なビジネス・ロジックを適用します。

詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

2. 動的コンポーネントを含むページでは、コマンド・コンポーネントをページに追加して、そのactionListenerプロパティをマネージドBeanメソッドにパインドします。

次の例は、現在行のDeptNoの値を9999に設定するマネージドBeanメソッドを示しています。

public void setValueThroughBinding(ActionEvent event)
{
// get binding container
FacesContext facesContext = FacesContext.getCurrentInstance();
ELContext elContext = facesContext.getELContext();
ValueExpression valueExpression = createValueExpression("bindings",
DCBindingContainer.class);
DCBindingContainer binding = (DCBindingContainer)
valueExpression.getValue(elContext);

// get AttributesModel and attribute metadata list
valueExpression = createValueExpression("bindings.EmpVO1.attributesModel",
AttributesModel.class);
AttributesModel attributesModel = (AttributesModel)
valueExpression.getValue(elContext);
List<BaseAttributeDescriptor> attrList = attributesModel.getAttributes();

// get AttributeMetadata for "Empno"
BaseAttributeDescriptor deptNoAttributeBase = null;
FacesAttributeDescriptor deptNoAttribute = null;
for (BaseAttributeDescriptor attrDescriptor: attrList)
{
if ("Comm".equals(attrDescriptor.getName()))
{
deptNoAttributeBase = attrDescriptor;
break;
}
}

deptNoAttribute = (FacesAttributeDescriptor)deptNoAttributeBase;
if (deptNoAttribute == null || deptNoAttribute.getContainerName() == null)
{
System.out.println("AttributesModel of Empno or its model name");
System.out.println("can not be found.");
return;
}

// get Deptno attribute value binding, set input value
JUFormBinding fb = (JUFormBinding) binding.findExecutableBinding((String)
deptNoAttribute.getContainerName());
JUCtrlValueBinding valueBinding = (JUCtrlValueBinding)
fb.getControlBinding(deptNoAttribute.getName());
valueBinding.setInputValue(Integer.valueOf(9999));

System.out.println("Found JUCtrlValueBinding " + deptNoAttribute.getName()");
System.out.println("set its value to 9999.");
}

31.10 フォーム上のUIコンポーネントおよびバインディングの変更

「データ・コントロール」パネルを使用してフォーム(動的フォームを除く)を作成すると、属性の削除、表示順序の変更、データの表示に使用するコンポーネントの変更、およびコンポーネントのバインド先の属性の変更を実行できます。

注意:

次の手順では、動的フォームの表示方法は変更できません。表示情報は、ビュー・オブジェクトまたはエンティティ・オブジェクトで変更する必要があります。

31.10.1 UIコンポーネントおよびバインディングの変更方法

「データ・コントロール」パネルからドロップしたデフォルト・コンポーネントについて、一部の内容を変更できます。「構造」ウィンドウを使用して、コンポーネントの表示順序の変更、新規コンポーネントの追加や既存のコンポーネントの変更、またはコンポーネントの削除を行えます。「プロパティ」ウィンドウを使用すると、バインディングの変更や削除またはコンポーネントに対して表示されるラベルの変更が行えます。

始める前に:

生成された後の、UIコンポーネントでの作業について理解しておくと役立ちます。詳細は、「フォーム上のUIコンポーネントおよびバインディングの変更」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド・ページの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

デフォルト・コンポーネントおよびバインディングを変更するには:

1. 構造ウィンドウを使用して、次の処理を行います。

- UIコンポーネントをツリー内で上下にドラッグして、順序を変更します。黒線の矢印は、UIコンポーネントの配置先を示します。

- UIコンポーネントの追加。「構造」ウィンドウで既存のUIコンポーネントを右クリックし、新規コンポーネントの配置場所として、選択したコンポーネントの前、後ろ、内部のいずれかを選択します。その後、リストからUIコンポーネントを選択します。

- UIコンポーネントのバインド。「構造」ウィンドウで既存のUIコンポーネントを右クリックし、「ADFコントロールにバインド」を選択します。その後、コンポーネントをバインドするオブジェクトを選択できます。

- UIコンポーネントの再バインド。「構造」ウィンドウで既存のUIコンポーネントを右クリックし、「別のADFコントロールに再バインド」を選択します。その後、コンポーネントをバインドする新しいコントロール・オブジェクトを選択できます。

- UIコンポーネントの削除。コンポーネントを右クリックして、「削除」を選択します。コンポーネントを保持するが、バインディングを削除する場合は、「プロパティ」ウィンドウを使用する必要があります。手順2の2番目の箇条書きを参照してください。

2. 「構造」ウィンドウで選択されたUIコンポーネントを使用して、「プロパティ」ウィンドウで次の操作を実行できます。

- UIコンポーネントのADF以外のバインディングの追加。「値」フィールドにEL式を入力するか、ドロップダウン・メニューを使用して「編集」を選択します。

- UIコンポーネントのバインディングの削除。EL式を削除します。

- UIコンポーネントのラベルの変更。デフォルトでは、ラベルはバインディングのヒントのlabelプロパティにバインドされます。このプロパティにより、エンティティ・オブジェクト属性またはビュー・オブジェクト属性に対して定義したラベルのUIコントロール・ヒントをページで使用できるようになります。UIヒントを使用すると、値の一度の変更で、ラベルを表示するすべてのページに同じ値を表示できます。
現在のページのラベルのみを変更できます。その場合は、label属性を選択します。ラベル値を別のもの(たとえば、プロパティ・ファイルやリソース・ファイルのキー)にバインドするために、テキストまたはEL式を入力します。

たとえば、製品名の表示に使用するinputTextコンポーネントでは、Label属性に対して次のようなコードが含まれます。

#{bindings.ProductName.hints.label}

この式を変更して、プロパティ・ファイルのキーにバインドすることもできます。次に例を示します。

#{properties['productName']}

この例のpropertiesは、プロパティ・ファイルのロードに使用する、JSFページで定義された変数です。

31.10.2 属性およびバインディングを変更した場合の処理

UIコンポーネントを移動または変更して属性の表示方法を変更すると、JSFページの対応するコードが変更されます。バインディング・エディタを使用してバインディングを追加または変更すると、JDeveloperによって、JSFページにコードが追加され、ページ定義ファイルに適切な要素が追加されます。

32 ADFによるデータバインドされた表の作成

この章では、ADFデータ・コントロールおよび編集可能な表、入力表、動的表を含むADF Facesコンポーネントを使用して、ADFビジネス・コンポーネントからモデル化されたデータを使用して表を作成する方法について説明します。

この章の内容は次のとおりです。

- ADFによるデータバインドされた表の作成について

- 基本表の作成

- 編集可能な表の作成

- 入力表の作成

- コレクションのリスト・ビューの作成

- 動的コンポーネントを使用した表の作成

- 表に表示される属性の変更

32.1 ADFによるデータバインドされた表の作成について

フォームとは異なり、表を使用すると、コレクションのデータ・オブジェクトを一度に複数表示できます。

単にデータを表示する表を作成することも、データの編集または作成が可能な表を作成することもできます。コレクションを表としてドロップすると、選択した行に対してなんらかのロジックを実行するアクションにバインドされたコマンド・ボタンを追加できます。また、必要に応じてデフォルトのコンポーネントを変更することもできます。

単純な表と同様に、各オブジェクトの属性の表示にグリッドを使用するリストにオブジェクトのコレクションを表示することもできます。

32.1.1 ADFによるデータバインドされた表のユースケースと例

図32-1は、Oracle ADFのSummitサンプル・アプリケーションの「Inventory Control」タブのProducts表を示しています。この表を使用して在庫にある製品のすべてを表示し、ユーザーが隣接したグラフでその在庫ステータスを表示する製品を選択できます。

図32-1 読取り専用表

図32-1に示すような、単に情報を表示するのみの表を作成できますが、図32-2に示すように、ユーザーに情報の編集を許可して新しいレコードを作成することもできます。

図32-2 表の編集

32.1.2 データバインド表の追加機能

表およびツリー・コンポーネントを実装する前に、他のADF Faces機能を理解することが役立つ場合があります。また、ページにツリーまたは表コンポーネントを追加した後で、検証やアクセシビリティなどの機能を追加することが必要になる場合があります。表およびツリー・コンポーネントで使用できる他の機能へのリンクを次に示します。

- ADFビュー・オブジェクト: 表内でのコンポーネントの表示方法および機能のほとんどは、対応するビュー・オブジェクトによって制御されます。詳細は、「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。

- ADFアプリケーション・モジュール: ページにデータバインドされたコンポーネントをドラッグする「データ・コントロール」パネルに、アプリケーション・モジュールに追加したビュー・オブジェクトの表示が移入されます。詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

- アダプタベースのデータ・コントロール: EJBコンポーネントやWebサービスなど他のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』の説明に従って、ビジネス・サービス用データ・コントロールを作成できます。

- ADFモデルとデータ・バインディング: ADF Webアプリケーション内でデータバインドされた表を作成する場合は、ADFモデルおよびデータ・バインディングを使用します。詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

- ADF Faces: ADF Facesを使用した開発の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

- コマンド・ボタン: データ・セットに対して様々な機能を起動するためのコマンド・ボタンやリンクを追加できます。この章で説明したもの以外の高度な機能については、「ビュー・レイヤーで各機能を起動するコマンド・コンポーネントの使用」を参照してください。

- フィルタ処理された表: フィルタリングを可能にする表を作成できます。これにより、実質的に表内のデータに対し、例による問合せ検索を実行できます。詳細は、「スタンドアロンのフィルタ処理された検索表を名前付きビュー基準から作成」を参照してください。

- タスク・フロー: トランザクションに携わる表の場合は(入力表など)、表のレンダリングの前または後に、ADFタスク・フローを使用して特定の操作を起動する必要があります。詳細は、「ADFタスク・フローの作成」を参照してください。

- 検証: 特定のフィールドがデータ・ストアに送信される前に、このフィールドを検証する必要がある場合もあります。詳細は、「検証とビジネス・ルールの宣言的な定義」および「ADFモデル・レイヤーでの検証の使用」を参照してください。

- アクティブ・データ: アプリケーションでアクティブ・データを使用する場合は、データ・ソースのデータが変更されるたびに、表およびツリーのデータを自動的に更新できます。詳細は、「アクティブ・データ・サービスの使用」を参照してください。

注意:

アクティブ・データを使用し、アプリケーションでADFビジネス・コンポーネントを使用する場合は、表が次の条件に適合する必要があります。

- アクセッサが依然として、似たようなアクセッサにアクセスしているとしても、バインディングが同種のデータ(つまり、ルールは1つのみ)を表していること。

- バインディング・ルールに含まれる属性は1つであること。

- 表でフィルタを使用しないこと。

- ツリー・コンポーネントのnodeStampファセットに、単一のoutputTextタグが含まれ、他のタグが含まれていないこと。

32.2 基本表の作成

フォームを構成する個々のUIコンポーネントをコレクション上の個々の属性にバインドするフォームとは異なり、表では、ADF Facesのtableコンポーネントをコレクション全体にバインドするか、コレクションから一度にnデータ・オブジェクトのレンジにバインドします。その結果、列にデータを表示するために使用される個々のコンポーネントが属性にバインドされます。イテレータ・バインディングによって各オブジェクトの適切なデータが表示され、tableコンポーネントによって各オブジェクトが1行で表示されます。JDeveloperを使用すると、宣言的にこの処理を実行できるため、コードを記述する必要がありません。

32.2.1 基本表の作成方法

データ・コントロールを使用して表を作成するには、tableコンポーネントをコレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

始める前に:

ADF Facesによるデータバインドされた表について理解しておくと役立ちます。詳細は、「基本表の作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド表の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

データ・バインドされた表を作成するには:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、顧客のすべてを表示するSummit ADFサンプル・アプリケーションの単一表を作成するには、Customersコレクションを選択します。

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「表/リスト・ビュー」→「ADF表」を選択します。

3. 「表の作成」ダイアログには、コレクション内の各属性が表示されます。また、これらの属性が表の列としてどのように動作し、表示されるかを定義できます。

ダイアログを使用すると、次の操作ができます。

- 表を読取り専用にします。

- 「単一行」または「複数行」ラジオ・ボタンを選択することにより、ADFモデル・レイヤーでの選択の処理が可能になります。これらのオプションのいずれかを選択すると、イテレータ・バインディングがイテレータにアクセスして、選択された1つ以上の行を判別します。表での選択を実行しない場合以外は、これらのオプションのいずれかを選択してください。

- 「ソートの有効化」チェック・ボックスの選択による、ADFモデル・レイヤーでの列のソート処理。このオプションを選択すると、イテレータ・バインディングがイテレータにアクセスし、order-by問合せを実行して順序を決定します。列のソートを実行しない場合以外は、このオプションを選択してください。

- 「フィルタの有効化」チェック・ボックスの選択による、入力した基準を使用した、表の列のフィルタリングの実行。このオプションを選択すると、各列の上にあるテキスト・フィールドに基準を入力できます。その後で、この基準を使用してコレクションへのQuery-by-Example (QBE)検索を作成すると、問合せによって戻された結果のみが表に表示されます。詳細は、「スタンドアロンのフィルタ処理された検索表を名前付きビュー基準から作成」を参照してください。

注意:

JPAベースのデータ・コントロールの場合、データ・コントロールのネストされたコレクションから作成される表でフィルタリングは機能しません。ページにこのようなコレクションをドロップする場合、実行時エラーを回避するために、このチェック・ボックスを未選択のままにする必要があります。JPAベースのデータ・コントロールの詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のEJBデータ・コントロールに関する項を参照してください。

- 目的の属性(ダイアログでは行として表示)の選択およびグループ化ボタンのクリックによる、親列の下の選択した属性の列のグループ化。図32-3に、表の作成後にグループ化された5つの列がビジュアル・エディタでどのように表示されるかを示します。

図32-3 ADF Faces表のグループ化された列

- 列の表示ラベルを変更できます。デフォルトでは、ラベルは表バインディング上の属性に定義されたすべてのコントロール・ヒントのlabelsプロパティにバインドされます。このバインディングにより、ビュー・オブジェクトのラベル・テキストの値を1回変更することで、そのラベルが表示されるすべてのページに、その変更を同様に表示できます。
このデフォルトを使用するかわりにテキストまたはEL式を入力し、ラベル値のバインド先をリソース・ファイルのキーなど、別のものにすることができます。

- 列の値バインディングの変更。異なる属性にバインドされるように列を変更できます。単に列を並べ替える場合は、順序ボタンを使用してください。列の属性バインディングを変更すると、列のラベルも変更されます。

- 属性の表示に使用されるUIコンポーネントの変更。UIコンポーネントは、コレクションをページにドロップしたときに選択した表と、対応する属性のタイプ(たとえば、日付である属性にはinputDateコンポーネントを使用)、および対応するビュー・オブジェクトにおいてデフォルト・コンポーネントがコントロール・ヒントとして設定されているかどうかに基づいて設定されます。ドロップダウン・リストを使用して別のコンポーネントに変更できます。

ヒント:

表の属性の1つが主キーでもある場合、ユーザーが値を変更できないUIコンポーネントを選択します。

ヒント:

ドロップダウン・メニューに表示されないコンポーネントを使用する場合は、このダイアログを使用してoutputTextコンポーネントを選択した後、手動で他のタグをページに追加します。

- 順序ボタンを使用した列の順序の変更。

- 「追加」アイコンを使用した列の追加。追加できる列の数に制限はありません。最初にアイコンをクリックすると、JDeveloperではダイアログの下部に新規列の行が追加され、そこにバインドされたコレクションの最初の属性の値が移入されます。後続の新規列には順序内の次の属性の値が移入され、その後も同様に続きます。

- 「削除」アイコンを使用した列の削除。

- 「実行時に列を動的に生成」チェック・ボックスを選択して、表を動的にします。動的表の詳細は、「動的コンポーネントを使用した表の作成」を参照してください。

4. 表をページにドロップした後は、「プロパティ」ウィンドウを使用して、表の他の表示プロパティを設定できます。たとえば、表の幅を特定のパーセンテージまたはサイズに設定します。表示プロパティの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「表、ツリー、およびその他のコレクションベースのコンポーネントの使用」を参照してください。

ヒント:

表の幅を100%に設定すると、表には境界が含まれないため、表の実際の幅はさらに大きくなります。コンテナの幅の100%に表を設定するには、「プロパティ」ウィンドウの「スタイル」セクションを開き、「ボックス」タブを選択してBorder Width属性を0(ゼロ)ピクセルに設定します。

5. デフォルトでは、ユーザーがスクロールを停止して、表の行をスクロールするスクローラの位置が確定されるまで待機する遅延スクロール動作が表で実行されます。表イテレータ・バインディングで表示する「プロパティ」ウィンドウを使用して、スムーズ・スクロール動作を構成できます。詳細は、「表のスクロール動作と行数に関する必知事項」を参照してください。

6. ユーザーが表の情報を編集し、変更を保存できるようにするには、変更を発行して保存する方法を指定する必要があります。詳細は、「編集可能な表の作成」を参照してください。ユーザーによるデータ入力が可能な表の作成手順は、「入力表の作成」を参照してください。

32.2.2 表の作成時の処理

「データ・コントロール」パネルから表をドロップすると、テキスト・フィールドまたはフォームをドロップするのと同じ効果があります。要約すると、JDeveloperによって行われる処理は次のとおりです。

- 表のバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

詳細は、「テキスト・フィールドの作成時の処理」を参照してください。

32.2.2.1 表のイテレータと値バインディング

「データ・コントロール」パネルから表をドロップすると、treeの値バインディングが作成されます。ツリーはノードの階層で構成され、各サブノードは上位レベルのノードから分岐します。表の場合、フラット化された階層であり、各属性(列)は表のサブノードになります。フォームで使用される属性バインディングと同様で、treeの値バインディングによってイテレータ・バインディングが参照されると同時に、イテレータ・バインディングによってデータ・コレクションのイテレータが参照されるため、コレクションのデータ・オブジェクト全体の反復が円滑に行われます。属性ごとに異なるバインディングが作成されるのではなく、表ノードへのツリー・バインディングのみが作成されます。ツリー・バインディングでは、表の各行で表示または参照に使用する各属性の子要素が、nodeDefinition要素のAttrNames要素に含まれています。

ツリーの値バインディングは、FacesCtrlHierBindingクラスのインスタンスです。このクラスは、コアのJUCtrlHierBindingクラスを拡張して、次の2つのJSF固有のプロパティを追加します。

- collectionModel: JSFおよびADF Facesで表などのコレクション値コンポーネントに使用するjavax.faces.model.DataModelオブジェクトを拡張するオブジェクトによってラップされたデータを戻します。

- treeModel: collectionModelを拡張し、実質的に階層構造であるデータを戻します。詳細は、「マスター/ディテール・データの表示」を参照してください。

次の例は、ADFタスク・フローのProductVO1コレクションのSummitサンプル・アプリケーションをドロップすると作成される表の値バインディングを示しています。

<bindings>
<tree IterBinding="ProductVO1Iterator" id="ProductVO1">
<nodeDefinition
DefName="oracle.summit.model.views.ProductVO"
Name="ProductVO10">
<AttrNames>
<Item Value="Id"/>
<Item Value="Name"/>
<Item Value="ShortDesc"/>
<Item Value="LongtextId"/>
<Item Value="ImageId"/>
<Item Value="SuggestedWhlslPrice"/>
<Item Value="WhlslUnits"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

データにアクセスする必要があるのは表のみであるため、(列または個々のセル内のテキスト・コンポーネントではなく)モデルにバインドする必要があるのは表コンポーネントのみです。表のツリー・バインディングは表の個々の構造化属性にドリルダウンするので、表の列は表コンポーネントからその情報を導出できます。

32.2.2.2 ADF Faces表のJSFページのコード

「データ・コントロール」パネルを使用してJSFページに表をドロップすると、表バインディングで指定された各属性に対するADF Facesのcolumnコンポーネントが含まれたADF FacesのtableコンポーネントがJDeveloperによって挿入されます。各列には、属性の値にバインドされた別のコンポーネント(inputTextコンポーネントやoutputTextコンポーネントなど)が含まれます。各列の見出しは、属性のコントロール・ヒントのlabelsプロパティにバインドされます。

ヒント:

関連するビューまたはエンティティ・オブジェクトで属性が非表示としてマークされている場合、対応するUIは作成されません。

次の例は、ProductsVO1コレクションを読取り専用表としてドロップして作成した表から抜粋したコードを示しています。

<af:table value="#{bindings.ProductVO1.collectionModel}" var="row"
rows="#{bindings.ProductVO1.rangeSize}"
emptyText="#{bindings.ProductVO1.viewable ? 'No data to display.' : 'Access Denied.'}"
fetchSize="#{bindings.ProductVO1.rangeSize}" rowBandingInterval="0"
selectedRowKeys="#{bindings.ProductVO1.collectionModel.selectedRow}"
selectionListener="#{bindings.ProductVO1.collectionModel.makeCurrent}"
rowSelection="single" id="t1">
<af:column headerText="#{bindings.ProductVO1.hints.Id.label}" id="c1">
<af:outputText value="#{row.Id}"
shortDesc="#{bindings.ProductVO1.hints.Id.tooltip}"
id="ot1">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.ProductVO1.hints.Id.format}"/>
</af:outputText>
</af:column>
<af:column headerText="#{bindings.ProductVO1.hints.Name.label}" id="c2">
<af:outputText value="#{row.Name}"
shortDesc="#{bindings.ProductVO1.hints.Name.tooltip}"
id="ot2"/>
</af:column>
<af:column headerText="#{bindings.ProductVO1.hints.ShortDesc.label}" id="c3">
<af:outputText value="#{row.ShortDesc}"
shortDesc="#{bindings.ProductVO1.hints.ShortDesc.tooltip}"
id="ot3"/>
</af:column>
.
.
.
</af:table>

ツリー・バインディングは、イテレータ・バインディングによって公開されたデータ全体を反復します。表の値は、collectionModelオブジェクトにアクセスするcollectionModelプロパティにバインドされています。表は、イテレータ・バインディングからの結果セットをcollectionModelオブジェクト内にラップします。collectionModelにより、コレクションの各アイテムは、var属性を使用して表コンポーネント内で使用できるようになります。

例では、表がProductVO1イテレータ・バインディングの現在レンジの行全体を反復します。イテレータ・バインディングは、現在行の追跡を続行する行セット・イテレータにバインドします。表のvar属性をrowに設定すると、次のaf:outputTextタグの値に示すように、各列はrow変数を使用して、表タグに示される現在行の現在データ・オブジェクトにアクセスします。

<af:outputText value="#{row.Id}"/>

ADF表をドロップし、それを読取り専用表として指定しない場合は、次の例に示すように、出力コンポーネントではなく、入力コンポーネントが生成されます。入力コンポーネントの値は、行変数にバインドされるのではなく、bindingsプロパティを使用してバインディング・コンテナの特定の行に暗黙的にバインドされます。さらに、入力コンポーネントごとにバリデータ・コンポーネントが追加されます。bindingsプロパティを使用すると、発生した例外を該当するバインド・オブジェクトにリンクできます。コントローラは、バインディング・コンテナ内のすべての例外を反復処理し、FacesMessageオブジェクトの作成時にクライアントIDを取得するためのバインディング・オブジェクトを取得します。この取得により、特定のセルのエラーを表に表示できるようになります。この方法は、リストなどの選択コンポーネントを含め、すべての入力コンポーネントに使用されます。

<af:table value="#{bindings.ProductVO1.collectionModel}" var="row"
rows="#{bindings.ProductVO1.rangeSize}"
emptyText="#{bindings.ProductVO1.viewable ? 'No data to display.' :
'Access Denied.'}"
fetchSize="#{bindings.ProductVO1.rangeSize}" rowBandingInterval="0"
id="t1">
<af:column headerText="#{bindings.ProductVO1.hints.Id.label}" id="c1">
<af:inputText value="#{row.bindings.Id.inputValue}"
label="#{bindings.ProductVO1.hints.Id.label}"
required="#{bindings.ProductVO1.hints.Id.mandatory}"
columns="#{bindings.ProductVO1.hints.Id.displayWidth}"
maximumLength="#{bindings.ProductVO1.hints.Id.precision}"
shortDesc="#{bindings.ProductVO1.hints.Id.tooltip}"
id="it1">
<f:validator binding="#{row.bindings.Id.validator}"/>
<af:convertNumber groupingUsed="false"
pattern="#{bindings.ProductVO1.hints.Id.format}"/>
</af:inputText>
</af:column>

ADF Facesのバリデータとコンバータの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「入力の検証および変換」を参照してください。

表32-1に、「データ・コントロール」パネルを使用して作成されたADF Faces表に対して、デフォルトで定義された他の属性を示します。

表32-1 ADF Faces表の属性と移入される値

属性

説明

デフォルト値

rows

一度に表示する行数を決定します。

デフォルトで、関連付けられたイテレータ・バインディングのrangeSizeプロパティに評価されるEL式。これにより、データ・コントロールから一度にフェッチされるデータの行数が決定されます。表は戻される行数以上を表示できないため、rows属性の値は、対応するイテレータのrangeSize値以下にする必要があります。

first

レンジの最初の行の索引(ベース0)。

関連付けられたイテレータ・バインディングのrangeStartプロパティに評価されるEL式。

emptyText

戻す行がない場合に表示するテキスト。

イテレータの表示可能なプロパティに評価されるEL式。表が表示可能で、戻すオブジェクトがない場合、「表示するデータがありません」と表示されます。表が表示できない場合(表に対して認可の制限が設定されている場合など)は、「アクセスが拒否されました」と表示されます。

fetchSize

データソースからフェッチされたデータの行数。

デフォルトで、関連付けられたイテレータ・バインディングのrangeSizeプロパティに評価されるEL式。rangeSizeプロパティの詳細は、「定義されるイテレータのRangeSize属性」を参照してください。この属性は、rows属性より大きな値に設定できます。

表でのスクロール動作を向上させるため、表のイテレータ・バインディングが200超の項目で構成されるデータ・セットを管理すると想定され、ビュー・オブジェクトが範囲ページングを使用するように構成されている場合、イテレータは1つの範囲のみではなく範囲のセットを実際には戻します。ビュー・オブジェクトの範囲ページングの使用方法の詳細は、「大きい結果セットを効率的にスクロールするための範囲ページ移動の使用方法」を参照してください。JPAベースのデータ・コントロールの範囲ページングの詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のEJBデータ・コントロールでのデータのページ分割されたフェッチに関する項を参照してください。

selectedRowKeys

表の選択の状態。

デフォルトでコレクション・モデルの選択された行に評価されるEL式。

selectionListener

選択したイベントをリスニングするメソッドへの参照。

デフォルトでコレクション・モデルのmakeCurrentメソッドに評価されるEL式。

rowSelection

行が選択可能かどうかを決定します。

一度に1行のみ選択するにはsingleに設定します。複数の行の選択を許可するには、multipleに設定します。

列属性

sortProperty

列をソートする対象となるプロパティを決定します。

列の対応する属性バインディング値に設定します。

sortable

ソートできる列かどうかを決定します。

falseに設定します。trueに設定すると、イテレータ・バインディングがイテレータにアクセスし、順序を決定します。

headerText

列の上部に表示されるテキストを決定します。

デフォルトで、対応する属性に設定されたラベルのコントロール・ヒントに評価されるEL式。

32.2.3 表での現在行の設定に関する必知事項

アプリケーションで表を使用し、ADFモデル・レイヤーで行選択を管理できるようにする場合、現在行はイテレータによって決定されます。ユーザーがADF Faces表で行を選択すると、表の行が影付きになり、選択された行がコンポーネントによりイテレータに通知されます。そのためには、次の例に示すように、表のselectedRowKeys属性をコレクション・モデルの選択した行にバインドします。

<af:table value="#{bindings.ProductVO1.collectionModel}" var="row"
.
.
.
selectedRowKeys="#{bindings.ProductVO1.collectionModel.selectedRow}"
selectionListener="#{bindings.ProductVO1.collectionModel.makeCurrent}"
rowSelection="single">

このバインディングは、表の選択したキーをコレクション・モデルの選択した行にバインドします。selectionListener属性は、コレクション・モデルのmakeCurrentプロパティにバインドされます。このバインディングは、コレクションの選択した行をイテレータの現在行に設定します。

注意:

カスタム選択リスナーを作成した場合、コレクション・モデル(#{binding.Products.collectionModel.makeCurrent}など)のmakeCurrentプロパティへのメソッド・バインディングを作成し、任意のカスタム・ロジックの前にこのメソッド・バインディングをカスタム選択リスナーで起動する必要があります。

表は選択を自動的に処理できますが、オブジェクトの現在行をイテレータにプログラムで設定する必要がある場合があります。

getKey()メソッドをどのビュー行でコールしても、行を識別する1つ以上のキー属性をカプセル化するKeyオブジェクトを取得できます。findByKey()メソッドを使用して行セットのビュー行を検索するためにKeyオブジェクトを使用することもできます。実行時に、setCurrentRowWithKeyまたはsetCurrentRowWithKeyValueのいずれかの組込み操作がデータ・バインディング・レイヤーによって名前で起動されると、findByKey()メソッドを使用して、パラメータとして渡された値に基づいて行が検索された後、検索された行が現在の行として設定されます。

setCurrentRowWithKey操作およびsetCurrentRowWithKeyValue操作ではいずれもrowKeyという名前のパラメータが予想されますが、実行時にそのrowKeyパラメータに予想される値はそれぞれで異なります。

setCurrentRowWithKey操作

setCurrentRowWithKeyでは、rowKeyパラメータ値に、ビュー行キーのシリアライズされた文字列表現が想定されています。これは、次のような16進エンコード文字列です。

000200000002C20200000002C102000000010000010A5AB7DAD9

キーのシリアライズされた文字列表現により、ブラウザのURL文字列またはフォーム・パラメータで単一値として渡すことができる方法で、ビュー行のキーを構成する可能性のあるすべてのキー属性がエンコードされます。実行時に、有効なシリアライズされた文字列キーではないパラメータ値を不注意に渡すと、oracle.jbo.InvalidParamExceptionまたはjava.io.EOFExceptionなどの例外を結果として受信する場合があります。Webページでは、ADFコントロール・バインディングのrowKeyStrプロパティ(#{bindings.SomeAttrName.rowKeyStr}など)またはADF Faces表の行変数(#{row.rowKeyStr}など)を参照すると、行のシリアライズされた文字列キーの値にアクセスできます。

setCurrentRowWithKeyValue操作

setCurrentRowWithKeyValue操作では、rowKeyパラメータ値がビュー行のキーを表すリテラル値であると想定しています。たとえば、製品番号201を検索する場合、この値は単に201になります。

注意:

アプリケーション・モジュール・クラスにカスタム・コードを記述し、クライアントから渡されたシリアライズされた文字列キーに基づいて行を検索する必要がある場合は、oracle.jbo.clientパッケージにあるJboUtilクラスのgetRowFromKey()メソッドを次のように使用できます。

static public Row getRowFromKey(RowSetIterator rsi, String sKey)

第1パラメータは、行を検索するビュー・オブジェクト・インスタンスです。第2パラメータは、キーのシリアライズされた文字列書式です。

32.2.4 プログラムを使用した行データの取得に関する必知事項

CollectionModelでは行キー・パラメータを取るgetRowDataメソッドのバージョンがサポートされているため、現在の位置を変更することなく行データを取得できます。

たとえば、このコードを置き換えることができます。

CollectionModelInstance.setRowKey(RowKeyInstance);
JUCtrlHierNodeBinding rowData = (JUCtrlHierNodeBinding)
CollectionModelInstance.getRowData();

次のコードで置き換えることができます。

JUCtrlHierNodeBinding rowData = (JUCtrlHierNodeBinding)
CollectionModelInstance.getRowData(RowKeyInstance);

これは、setRowKeyメソッドの使用を回避できるため、ビュー・オブジェクトで範囲ページ移動を使用する際には特に役立ちます。(setRowKeyを使用する場合、そのメソッドで指定する行が現在の行範囲内にあることを確認するため、カスタム・コードを提供する必要がある場合もあります。)

32.2.5 表のスクロール動作と行数に関する必知事項

表コンポーネントをページに追加するとき、表のサイズ設定で、表示行数は、基礎となるビュー・オブジェクトで設定されたフェッチ・サイズよりも小さくするため、合計行数の一部分のみとなります。実行時、合計行数が表の行数よりも非常に多い場合、ユーザーが結果セットをスクロールするとき、ユーザーがスクロールを停止して、スクローラの最終位置が確定されるまで、対応する行のレンダリングを待機することが通常は適切です。このデフォルトの動作は、スクローラの位置が確定されるまで表の行が変更されないため、遅延スクロールと呼ばれます。これに対し、結果セット全体をスクロールするために必要となるフェッチの回数(基礎となるビュー・オブジェクトのフェッチ・サイズの倍数が行数に達する最小の回数が必要です)が少ない場合、スクローラの位置の変化に対応する表の行が表示される、スムーズ・スクロールが適切です。

表のイテレータ・バインディングのRowCountThreshold属性を使用して、必要な表スクロール動作を構成できます。デフォルトの属性値(0)では、表が最初にレンダリングされるときに推定行数が取得され、大規模な結果セットの遅延スクロールがサポートされます。この場合、最初にスクローラのサイズが決定され、ユーザーが結果セットをスクロールしても変更されません。

スムーズ・スクロールをサポートするには、表コンポーネントのイテレータ・バインディングのRowCountThreshold属性を0未満の値(-1など)に設定します。これにより、小さい結果セットのスムーズ・スクロールが実行され、最後の行セットがフェッチされるまで推定行数の取得が遅延されます。この場合、スクローラのサイズおよび位置は、表によってフェッチされる行数によって決定されるため、ユーザーが結果セットをスクロールするのに伴ってスクローラが小さくなります。

または、スムーズ・スクロールを開始するしきい値を構成する場合は、RowCountThreshold属性を0より大きい値に設定できます。表がレンダリングされるときに推定行カウントが実行され、行数が指定した値よりも小さい場合は、フレームワークによりデフォルトの動作(スクローラの位置が確定されるまで行のスクロールを遅延する)が実行されます。推定行数がしきい値を超えると、表でスムーズ・スクロール動作が実行されます。

32.3 編集可能な表の作成

ユーザーが表内の情報を編集し、その変更をデータ・ソースにコミットできるようにする表を作成できます。組込みデータ制御操作を使用して、データを変更するためのコマンド・ボタンを作成し、このボタンを表のツールバーに配置できます。たとえば、Delete操作を使用して、ユーザーが現在のレンジからレコードを削除できるボタンを作成します。

重要なのは、コレクション固有の操作がADFキャッシュのオブジェクトに対してのみ実行されるという点です。ルート・データ・コントロール上でCommit操作を使用して、任意の変更をデータソースに実際にコミットする必要があります。データ・コントロールのRollback操作を使用して、キャッシュされたオブジェクトに対する任意の変更をロールバックします。ページが、バインド・タスク・フロー内のトランザクションの一部である場合、通常、タスク・フロー・リターン・アクティビティのトランザクションを解決するためにこの操作を使用します。詳細は、「タスク・フローのトランザクションの管理」を参照してください。

注意:

WebサービスやステートレスEJBセッションBeanに基づくデータ・コントロールなど、CommitおよびRollback操作が使用できないデータ・コントロールの場合、データ・ソースにデータを保存するカスタム・メソッドを提供する必要があります。JPA-ベースのデータ・コントロールの場合、mergeEntityまたはpersistEntityメソッドを使用して変更を保存できますが、これらのメソッドは単一行でのみ動作します。JPAベースのデータ・コントロールの使用の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のEJBセッションBeanのコミット・モデルに関する項を参照してください。

編集可能なコンポーネントを使用してデータを表示することにした場合、ただちにすべての行を変更可能として表示する表か、ユーザーが行内をダブルクリックするまですべての行を読取り専用として表示する表という選択肢があります。図32-4は、すべての行に編集可能フィールドがある表を示しています。ページは、ページに追加されたコンポーネント(inputTextおよびinputDateコンポーネントなど)を使用してレンダリングされます。

図32-4 編集可能フィールドがある表

図32-5は、同じ表ですが、データを編集または入力するにはユーザーが行をダブルクリック(または行がすでに選択されている場合はシングルクリック)する必要があるように構成されています。図32-4と同じ入力コンポーネントを使用してページは作成されていますが、outputTextコンポーネントを使用して選択されていない行のデータが表示されることに注意してください。これらのコンポーネントを実際にレンダリングしている行は、編集のために選択された行のみです。

図32-5 行の編集のためにクリックする表

ADF Facesの表コンポーネントによる編集の処理方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の表、ツリーおよびツリー表のデータの編集に関する項を参照してください。

32.3.1 編集可能な表の作成方法

編集可能な表を作成するには、基本表の作成に類似した手順に従い、続いて操作にバインドされたコマンド・ボタンを追加します。ただし、表にツールバーを含めるには、表の作成に使用されたコレクションのアイテムとツールバーを関連付けるADF Facesコンポーネントを追加する必要があります。

始める前に:

編集可能なデータバインド表について理解しておくと役立ちます。詳細は、「編集可能な表の作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド表の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

編集可能な表を作成するには:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、システム内の製品を編集できる簡単な表をSummit ADFタスク・フロー・サンプル・アプリケーションで作成するには、ProductVO1コレクションを選択します。

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「表/リスト・ビュー」→「ADF表」を選択します。

これにより、入力コンポーネントを使用して編集可能な表が作成されます。

3. 次に表示される「表の作成」ダイアログを使用して、属性がどのように動作し、表の列としてどのように表示されるかを決定します。ユーザーが編集する行を選択できるようにするには、必ず「単一行」または「複数行」ラジオ・ボタンを選択してください。

このダイアログを使用して表を構成する方法の詳細は、「基本表の作成方法」を参照してください。

4. 「構造」ウィンドウで表を選択し、「プロパティ」ウィンドウの「動作」セクションを開いて、「EditingMode」属性を設定します。全行を編集可能にする場合は、editAllを選択します。ユーザーに1行をクリックさせてその行を編集可能にする場合は、clickToEditを選択します。

5. 「構造」ウィンドウで、表コンポーネントを右クリックし、「囲む」を選択します。

6. 「囲む」ダイアログでは、ドロップダウン・リストで「ADF Faces」が選択されていることを確認し、「パネル・コレクション」コンポーネントを選択して「OK」をクリックします。

panelCollectionコンポーネントのツールバー・ファセットによりツールバーが保持され、そのツールバーによりデータの更新に使用されるコマンド・コンポーネントが保持されます。

7. 「構造」ウィンドウで、panelCollectionの「f:facet - toolbar」ファセット・ノードを右クリックし、「f:facet - toolbarの中に挿入」→「ツールバー」を選択します。

これにより、ユーザーが表の表示方法を変更できるデフォルトのメニューと、表全体の連結を解除する「連結解除」リンクをすでに含むツールバーが作成され、ブラウザ・ウィンドウの大部分を占めるように表示されます。panelCollectionコンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の表メニュー、ツールバーおよびステータス・バーの表示に関する項を参照してください。

8. 「データ・コントロール」パネルから操作の実行対象となるオブジェクトのコレクションに関連付けられている操作を選択し、「構造」ウィンドウのtoolbarコンポーネントにドラッグして、ポップアップ・メニューから「作成」→「ADFボタン」を選択します。これにより、データバインドされたコマンド・コンポーネントがツールバー内に配置されます。

たとえば、製品レコードを削除できるようにする場合は、ProductVO1コレクションに関連付けられているDelete操作をドラッグします。図32-6に、ProductVO1コレクションに関連付けられている操作を示します。

図32-6 コレクションに関連付けられている操作

9. 変更をキャッシュに送信するボタンが必要な場合は、「構造」ウィンドウで「af:toolbar」コンポーネントを右クリックし、「ツールバーの中に挿入」→「ボタン」の順に選択します。

注意:

表内の入力コンポーネントに対してautoSubmitプロパティをtrueに設定するなど、変更をキャッシュに送信する他の手段を使用できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の部分トリガーの使用に関する項を参照してください。

10. ページが、バインド・タスク・フロー内のトランザクションの一部でない場合、ユーザーが変更をコミットまたはロールバックできるようにするためのボタンを作成する必要があります。「データ・コントロール」パネルから、ルートレベル・データ・コントロールに関連付けられたCommit操作とRollback操作をドラッグし、ボタンまたはリンクのいずれかとしてツールバーにドロップします。

図32-7に、BackOfficeAppModuleDataControlデータ・コントロールのコミット操作とロール・バック操作を示します。

図32-7 データ・コントロールのCommit操作とRollback操作

ページが、バインド・タスク・フロー内のトランザクションの一部である場合、タスク・フロー・リターン・アクティビティを作成する際のトランザクションを解決する値としてCommitまたはRollbackを入力します。詳細は、「タスク・フローのトランザクションの管理」を参照してください。

ヒント:

データ・ストアに新規レコードを挿入できる表を作成するには、「入力表の作成」を参照してください。

32.3.2 編集可能な表の作成時の処理

編集可能な表の作成は、レコードの編集に使用するフォームの作成と類似しています。「データ・コントロール」パネルからドロップした操作に対してアクション・バインディングが作成されます。詳細は、「操作を使用したコマンド・コンポーネント作成時の処理」を参照してください。

32.4 入力表の作成

ユーザーが表に新しく空白行を挿入し、各列に値を追加することのできる表を作成できます(対応するエンティティ・オブジェクトまたはビュー・オブジェクトに設定されたデフォルト値は自動的に移入されます)。

32.4.1 入力表の作成方法

入力表を作成する際に、現在の行セット内の他の行のコンテキストにある新しい空白行をユーザーに表示する必要があります。この挿入を許可するには、CreateInsert操作を使用します。Create操作とは異なり、CreateInsert操作は、実際にはキャッシュのみではなく行セット内に新しい行を作成します。また、ユーザー・アクションに対応するよう表を構成する必要があります。ページ全体をリフレッシュするのではなく、他のコンポーネントとの対話に基づいて1つのコンポーネントをリフレッシュするようにADF Facesコンポーネントを設定できます。これは、部分ページ・レンダリングと呼ばれます。

注意:

CreateInsert操作は、WebサービスやJavaクラスに基づく操作など、アダプタベースのデータ・コントロールには利用できません。ただし、JPAベースのデータ・コントロールの場合、Create操作により、新規行がアプリケーション・モジュールに基づくデータ・コントロール用のCreateInsertなどの行セットに追加されます。詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールの組込み操作に関する項を参照してください。

始める前に:

ADF Facesの入力表について理解しておくと役立ちます。詳細は、「入力表の作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド表の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「編集可能な表の作成」の説明に従い、編集可能な表を作成します。

- 表がバインド・タスク・フローの一部でない場合は、Commit操作とRollback操作にバインドされたボタンを含めます。

入力表を作成するには:

1. 「データ・コントロール」パネルから、ドロップされたコレクションに関連付けられたCreateInsert操作をドラッグし、ツールバー・ボタンとしてツールバーにドロップします。CreateNewRowなどのわかりやすいものにIDを変更できます。これによって、部分トリガーとして選択する際に識別しやすくなります。

注意:

コレクションが別のコレクションの子である場合は(たとえば、Summit ADFサンプル・アプリケーションでは、OrdersForCustomerコレクションはCustomersコレクションの子)であり、CreateInsert操作を使用するかわりに、Create with Parameters操作を使用する必要があります。これは、子コレクションに対して作成するレコードが親コレクションに関連付けられるようにするためです。

2. 「構造」ウィンドウで、表コンポーネントを選択します。「プロパティ」ウィンドウで、「動作」セクションを開きます。

3. 「プロパティ」ウィンドウで、PartialTriggers属性上にマウスを置いて、「編集」を選択します。

4. 「プロパティの編集」ダイアログで、panelCollectionコンポーネントのツールバー・ファセットを開き、CreateInsert コマンド・コンポーネントを含むツールバーを開きます。そのコンポーネントを選択し、「選択済」パネルに移動します。「OK」をクリックします。これにより、表のリフレッシュがトリガーされるコンポーネントが設定されました。

32.4.2 入力表の作成時の処理

CreateInsert操作を使用して入力表を作成すると、JDeveloperによって次の処理が行われます。

- コレクションのイテレータ・バインディング、CreateInsert操作のアクション・バインディング、および表の属性バインディングの作成。CreateInsert操作は、行セットに新しい行を作成します。Commit操作およびRollback操作を使用してコマンド・ボタンまたはリンクを作成した場合、JDeveloperではこれらの操作のアクション・バインディングも作成されます。

- ADF Faces tableコンポーネント、columnコンポーネント、inputTextコンポーネントおよび操作の場合はbuttonコンポーネントを使用した、JSFページへのコードの挿入。

次の例は、ProductVO1コレクションから作成された入力表のページ定義ファイルを示しています(属性の中には、コレクションをドロップしたときに、「表の作成」ダイアログで削除されたものがあります)。

<executables>
<iterator Binds="ProductVO1" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl" id="ProductVO1Iterator"/>
</executables>
<tree IterBinding="ProductVO1Iterator" id="ProductVO1">
<nodeDefinition
DefName="oracle.summit.model.views.ProductVO"
Name="ProductVO10">
<AttrNames>
<Item Value="Id"/>
<Item Value="Name"/>
<Item Value="ShortDesc"/>
<Item Value="LongtextId"/>
<Item Value="ImageId"/>
<Item Value="SuggestedWhlslPrice"/>
<Item Value="WhlslUnits"/>
</AttrNames>
</nodeDefinition>
</tree>
<action IterBinding="ProductVOIterator" id="CreateInsert"
RequiresUpdateModel="true" Action="createInsertRow"/>
<action id="Commit" RequiresUpdateModel="true" Action="commitTransaction"
DataControl="BackOfficeAppModuleDataControl"/>
<action id="Rollback" RequiresUpdateModel="false"
Action="rollbackTransaction"
DataControl="BackOfficeAppModuleDataControl"/>
</bindings>

次の例は、表をリフレッシュするためのトリガーとしてCreateInsertコマンド・ツールバー・ボタンを使用して、部分ページ・レンダリングを提供する、JSFページに追加されたコードを示しています。

<af:form>
<af:panelCollection id="pc1">
<f:facet name="menus"/>
<f:facet name="toolbar">
<af:toolbar id="tb1">
<af:button actionListener="#{bindings.CreateInsert.execute}"
text="CreateInsert"
disabled="#{!bindings.CreateInsert.enabled}"
id="CreateInsert"/>
<af:button actionListener="#{bindings.Commit.execute}"
text="Commit"
disabled="false" id="b2"/>
<af:button actionListener="#{bindings.Rollback.execute}"
text="Rollback"
disabled="#{!bindings.Rollback.enabled}"
immediate="true" id="b3">
<af:resetActionListener/>
</af:button>
</af:toolbar>
</f:facet>
<f:facet name="statusbar"/>
<af:table value="#{bindings.ProductVO1.collectionModel}" var="row"
rows="#{bindings.ProductVO1.rangeSize}"
emptyText="#{bindings.ProductVO1.viewable ? \'No data to display.\' :
\'Access Denied.\'}"
fetchSize="#{bindings.ProductVO1.rangeSize}"
rowSelection="single" partialTriggers="CreateInsert" id="t1">
<af:column sortProperty="Id" sortable="false"
headerText="#{bindings.ProductVO1.hints.Id.label}"
id="c1">
<af:inputText value="#{row.ProductId}" simple="true"
required="#{bindings.ProductVO1.hints.Id.mandatory}"
columns="#{bindings.ProductVO1.hints.Id.displayWidth}"
maximuumLength="#{bindings.ProductVO1.hints.Id.precision}"
id="it1"/>
</af:column>
.
.
.
</af:table>
</af:panelCollection>
</af:form>

32.4.3 実行時に行われる処理: CreateInsertおよび部分ページ更新の動作方法

CreateInsert操作にバインドされたボタンを起動すると、アクションが実行され、ページがレンダリングされることによりコレクションの新しいインスタンスが作成および挿入されます。ボタンは、表をリフレッシュするトリガーとして構成されているため、表の最上部に新しい空白行を表示して再描画されます。Commitアクションにバインドされたボタンをユーザーがクリックすると、行セット内に作成された新しい行がデータベースに挿入されます。部分ページ・リフレッシュの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

32.4.4 行の作成および列のソートに関する必知事項

表の列のソートが可能で、新規行を挿入する前にユーザーが列をソートした場合、新規行はソートされません。新規行を含めて列をソートするには、目的のソートとは逆の列ソートを行ってから再ソートする必要があります。これは、表で列がすでにソートされていると見なされるためで、最初から希望のソート順をクリックしても列には何の効果もあらわれません。

たとえば、ユーザーが列を昇順でソートし、その後行を新たに追加するとします。最初、その行は最上部に表示されます。もう一度昇順で列をソートするために最初から昇順をクリックすると、列がすでに昇順であると見なされ、表は再ソートされません。ユーザーは、降順でソートした後に昇順でソートする必要があります。

行を挿入すると、データが特定の列で特定の順に自動的にソートされるようにする場合、プログラムでコミット後にSortEventをキューに入れ、ソートを実行するハンドラを実装します。

ビュー・オブジェクト属性がカスタム・ドメイン・データ・タイプによって定義されている列でソートを許可する場合、表のソート・ボタン・クリック・イベントに対してcompareTo()メソッドを実装する必要があります。

public int compareTo(Object theObject)

現在のオブジェクトがtheObjectより小さい場合は0以下の値に対して0を戻します。また現在のオブジェクトがそれより大きい場合は、0より大きい値を戻します。属性のオブジェクト比較は文字列比較のように動作します。

32.4.5 CreateおよびCreateInsertに関する必知事項

CreateまたはCreateInsert操作を使用して新規行を宣言的に作成すると、次のコード行が実行されます。

// create a new row for the view object
Row newRow = yourViewObject.createRow();
// mark the row as being "initialized", but not yet new
newRow.setNewRowState(Row.STATUS_INITIALIZED);

ただし、CreateInsert操作を使用している場合は、行を行セットに挿入する追加のコード行も実行されます。

// insert the new row into the view object's default rowset
yourViewObject.insertRow(newRow);

行をエンティティ・ベースのビュー・オブジェクトに作成すると、現在のアプリケーション・モジュールに関連付けられているTransactionオブジェクトによって、その処理が即時に記録されます。ビュー行の後に作成された新規エンティティ行は、Transactionの保留中の変更リストにすでに含まれています。作成された新規行は、初期化済状態であるとしてマーク付けされると、Transactionの保留中の変更リストから削除され、エンド・ユーザーによるデータ値の入力がまだ行われていない空白行とみなされます。初期化済という用語が適切である理由は、基礎となるエンティティ・オブジェクトによって定義されたすべてのデフォルト値を使用して初期化された新規行がエンド・ユーザーに表示されるためです。初期化済の行のどの属性にもユーザーがデータを入力していない場合は、その行が存在していないかのように処理されます。トランザクションのコミット時には、その行がTransactionの保留中の変更リストに含まれていないため、INSERT文はその行に対して試行されません。

初期化済の行に1つ以上の属性が設定されると同時に、初期化済の状態から新規状態(Row.STATUS_NEW)に自動的に遷移します。この時点で、基礎となるエンティティ行はTransactionの保留中の変更リストに登録され、トランザクションの次回コミット時に新規行が永続的に保存されます。

注意:

多数の初期化済の行を作成してもその行にデータを移入しない手順をエンド・ユーザーが実行した場合、低速メモリー・リークが発生することがあります。ただし、新規状態に遷移しない初期化済の行で使用されるメモリーは、Java仮想マシンのガベージ・コレクタによって最終的に解放されます。

32.4.6 JPAベースのデータ・コントロールでの複数行の保存に関する必知事項

EJBデータ・コントロールおよびJPAベースのBeanデータ・コントロールには、使用可能な組込みCreateInsert操作がありません。ただし、データ・コントロールのEagerPersistプロパティをtrueに設定して、これらのデータ・コントロールのCreate操作とCreateInsertの動作を置き換えることができます。このプロパティは、コンテナ管理トランザクションおよび明示的コミット・モデルを使用するステートフル・セッションBeanに基づくデータ・コントロールに対してデフォルトでtrueに設定されます。詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のEJBセッションBeanのコミット・モデルに関する項を参照してください

32.5 コレクションのリスト・ビューの作成

リストにオブジェクトのコレクションを表示する必要がある場合は、listViewコンポーネントを使用できます。各オブジェクトの属性は、グループまたは単一行および単一列内のグリッドに表示されます。図32-8に、listViewコンポーネントを使用して表示される製品のコレクションを示します。

図32-8 リストの単一列に表示されるコレクション

このlistViewでは、子listItemコンポーネントにはpanelGridLayoutコンポーネントが含まれ、このコンポーネントには、データおよびユーザーがアイテムを削除できるようにするボタン・コンポーネントを表示するoutputFormattedコンポーネントが含まれます。listViewコンポーネントは、value属性を使用して、表がコレクションにバインドされるのと同じ方法でコレクションにバインドされます。listItemコンポーネントはlistViewコンポーネントの直接の子であり、列コンポーネントが表のデータ・コンポーネントを保持するのと同じ方法で、データを表示するコンポーネントのコンテナになります。

コレクションに別のコレクションとのマスター/ディテール関係がある場合、listViewコンポーネントのグループ化機能を使用して親コレクションの下で子コレクションをグループ化できます。詳細は、「リスト・ビューを使用したマスター/ディテール・オブジェクトの表示」を参照してください。

listViewおよびlistItemコンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のリストへのコレクションの表示に関する項を参照してください。(図32-8に示すように) panelGridLayoutコンポーネントを使用してリストのグリッドにアイテムをグループ化する方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のグリッドでのコンテンツの配置に関する項を参照してください。panelGroupLayoutコンポーネントを使用して、グリッド・レイアウトが不要な場合にコンポーネントをグループ化することもできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の関連アイテムのグループ化に関する項を参照してください。

32.5.1 データバインドされたリスト・ビューの作成方法

「リスト・ビューの作成」ウィザードを使用して、リストを作成します。ウィザードでは、panelGroupLayoutまたはpanelGridLayoutコンポーネントを選択して、リスト・アイテムのコンポーネントを配置できます。マスター/ディテール関係の子のリストを作成している場合は、ウィザードを使用してリストのヘッダーを構成することもできます。

始める前に:

ADF Facesのリスト・ビューについて理解しておくと役立つことがあります。詳細は、「コレクションのリスト・ビューの作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド表の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

リスト・ビューを作成する手順:

1. 「データ・コントロール」パネルから、コレクションをページにドラッグし、「表/リスト・ビュー」→「ADFリスト・ビュー」を選択します。親コレクションからヘッダー付きリストを作成する場合は、子であるコレクションを別のコレクションにドラッグします。

2. 「リスト・ビューの作成」ウィザードを使用してレイアウト・コンポーネントを選択し、データの表示を整理したり、表示する属性およびコンポーネントを選択できます。グループを作成している場合は、ウィザードの最初のページで親コレクションを使用してヘッダーを含めるを選択します。

ウィザードの使用の詳細は、[F1]キーを押すか、「ヘルプ」をクリックします。

3. 「プロパティ」ウィンドウを使用して、レイアウト・コンポーネントをさらに構成します。

panelGridLayoutコンポーネントの使用の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のグリッドでのコンテンツの配置に関する項を参照してください。panelGroupLayoutコンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の関連アイテムのグループ化に関する項を参照してください。

32.5.2 データバインド・リスト・ビューの作成時の処理

ウィザードを使用してlistViewコンポーネントを作成する場合、JDeveloperでは、listView、listItemおよびレイアウト・コンポーネントが作成および構成されます。バインディングは、表の場合と同じです。listViewコンポーネントは、「データ・コントロール」パネルから削除されたコレクションにバインドされています。このコンポーネントのvar属性の値は、表の場合と同じ方法で、データにアクセスするためにoutputFormattedコンポーネントによって使用されます。コレクションのページ定義コードとJSPコードの詳細は、「表の作成時の処理」を参照してください。

次の例は、図32-8に示した単純な表のページ・コードを示しています。

<af:listView value="#{bindings.SProductView1.collectionModel}" var="item"
emptyText="#{bindings.SProductView1.viewable ? 'No data to display.'
: 'Access Denied.'}"
fetchSize="#{bindings.SProductView1.rangeSize}" id="lv1">
<af:listItem id="li1">
<af:panelGridLayout id="pgl2" dimensionsFrom="parent">
<af:gridRow marginTop="5px" height="15px" id="gr2">
<af:gridCell marginStart="5px" width="50%" id="gc2">
<af:panelLabelAndMessage label="Product:" id="plam1"
inlineStyle="font-weight:bold;">
<af:outputFormatted
value="#{item.bindings.Name.inputValue}" id="of1"/>
</af:panelLabelAndMessage>
</af:gridCell>
<af:gridCell marginStart="5px" width="50%" marginEnd="5px"
id="gc3"/>
</af:gridRow>
<af:gridRow marginTop="5px" height="15px" id="gr3">
<af:gridCell marginStart="5px" width="50%" id="gc4">
<af:panelLabelAndMessage label="ID:" id="plam2">
<af:outputFormatted value="#{item.bindings.Id.inputValue}"
id="of2">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.SProductView1.hints.Id.format}"/>
</af:outputFormatted>
</af:panelLabelAndMessage>
</af:gridCell>
<af:gridCell marginStart="5px" width="50%" marginEnd="5px"
id="gc5">
<af:button actionListener="#{bindings.Delete.execute}"
text="Delete Product"
disabled="#{!bindings.Delete.enabled}" id="b1"/>
</af:gridCell>
</af:gridRow>
<af:gridRow marginTop="5px" height="15px" marginBottom="5px" id="gr4">
<af:gridCell marginStart="5px" width="50%" id="gc6">
<af:panelLabelAndMessage label="Suggested Wholesale:"
id="plam3">
<af:outputFormatted
value="#{item.bindings.SuggestedWhlslPrice.inputValue}"
id="of3">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.SProductView1.hints.SuggestedWhlslPrice.format}"/>
</af:outputFormatted>
</af:panelLabelAndMessage>
</af:gridCell>
<af:gridCell marginStart="5px" width="50%" marginEnd="5px"
id="gc7"/>
</af:gridRow>
</af:panelGridLayout>
</af:listItem>
</af:listView>

32.6 動的コンポーネントを使用した表の作成

ページ内で直接各コンポーネントに対してタグを提供する静的データバインド・フォームを作成するのではなく、動的コンポーネントを使用して、バインディング・メタデータ、列およびバインド・コンテンツを表示するために使用されるコンポーネントが実行時に決定される表を作成します。

図32-9は、CustomerVOビュー・オブジェクトで属性に対するUIヒントを設定し、動的表としてCustomersデータ・コントロール・コレクションをドロップすることによって作成された実行時の動的表を示しています。設定されたUIヒントにはLABELおよびDISPLAYHINTがあります(後者は、動的フォームに指定された属性を含めないようにHideに設定できます)。

図32-9 カテゴリ・ヒントに基づいた列グループを含む動的表

動的コンポーネントの詳細は、「動的コンポーネントについて」を参照してください。

32.6.1 動的表の作成方法

動的表を作成するには、コレクションをADF表として「データ・コントロール」パネルからドロップして、フィールドが動的に生成されることを指定します。

始める前に:

動的コンポーネント機能および動的データバインド表について理解しておくと役立ちます。詳細は、「動的コンポーネントについて」および「動的コンポーネントを使用した表の作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド表の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

動的表を作成するには:

1. 動的フォームを作成しているコレクションに対応するビュー・オブジェクトまたはデータ・コントロール構造にUIヒントを設定します。

UIヒントにより、属性、ラベル、ツールチップ、フィールドを自動的に送信する必要があるかどうかなどを表示するために使用するUIコンポーネントのタイプなどが決定されます。UIヒントの作成手順は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。

2. 必要に応じて、各ビュー・オブジェクト属性のCategoryヒントに対して、カテゴリを指定するか、「新規カテゴリ」アイコンをクリックして、新規カテゴリを作成します。

同じカテゴリを持つ属性は、そのビュー・オブジェクトに基づいて作成する動的表でまとめることができます。

3. 必要に応じて、手順2で作成したカテゴリに対して、カテゴリのラベルおよびツールチップ用にUIヒントを設定します。これらはビュー・オブジェクトの概要エディタの「UIカテゴリ」タブで設定できます。

4. 「データ・コントロール」パネルから、ビュー・オブジェクトを表すコレクションを選択します。

5. コレクションをページにドラッグし、ポップアップ・メニューから「表/リスト・ビュー」→「ADF表」を選択します。

6. 「表の作成」ダイアログで、「実行時に列を動的に生成」チェック・ボックスを選択します。

7. 手順2で属性のカテゴリを指定した場合は、これらのカテゴリに従って表の列をグループ化するためにチェック・ボックスにフォームの列の表示を編成するため、「列グループを含める」チェック・ボックスを選択します。

32.6.2 動的コンポーネント使用時の処理

コレクションをページに動的フォームとしてドロップする場合、次の処理が発生します。

- ページ定義はvariableIteratorバインディング、イテレータへのiteratorバインディングおよびtree値バインディングで移入されます。詳細は、「動的フォームに対して作成されるバインディング」を参照してください。

- JSFページにはtableタグおよび1つ以上のiterator、columnおよびdynamicComponentタグが移入されます。また、「列グループを含める」オプションが選択されている場合は、switcherおよびgroupタグが追加されます。

32.6.2.1 グループ化しないで動的表に対して作成されるタグ

JSFページで、JDeveloperはtableタグを挿入し、その内部で、コレクションの属性を反復処理するiteratorタグをネストします。そのiteratorタグ内で、dynamicComponentタグを含むcolumnタグがネストされます。また、dynamicComponentに、実行時に決定される各列に対して適切なコンポーネントが表示されます。

次の例は、動的表としてCountriesデータ・コントロール・オブジェクトをドロップした(ただし、「列グループを含める」オプションを選択していない)場合に生成されるコードを示しています。

<af:table value="#{bindings.Countries.collectionModel}" var="row"
rows="#{bindings.Countries.rangeSize}"
emptyText="#{bindings.Countries.viewable ? 'No data to display.' :
'Access Denied.'}"
rowBandingInterval="0" fetchSize="#{bindings.Countries.rangeSize}"
id="t1">
<af:iterator id="i1"
value="#{bindings.Countries.attributesModel.attributes}"
var="column">
<af:column headerText="#{column.label}" id="c1">
<af:dynamicComponent id="d2" attributeModel="#{column}"
value="#{row.bindings[column.name].inputValue}"/>
</af:column>
</af:iterator>
</af:table>

iteratorタグのvalue属性では、コレクションのツリー・バインディングのattributesModel.attributesプロパティに評価するEL式を使用します。attributesModelプロパティは、コンポーネント・タイプ、ラベル、ツールチップ、レンダリングされる実際のコンポーネントの他のプロパティなど、データ・オブジェクトの属性およびそのメタデータを取得するために使用されます。attributesModelのattributesプロパティは、表示可能属性およびそのメタデータのフラット(非階層的)リストが提供されていることを示します。

dynamicComponentタグのattributeModel属性は、EL式#{column}にバインドされ、イテレータのvar属性で定義される変数を参照し、データ・コントロール・コレクションおよびその対応するメタデータの現在の属性へのポインタとして機能します。dynamicComponentのvalue属性のEL式は、変数columnも参照します。

32.6.2.2 グループ化して動的表に対して作成されるタグ

「表の作成」ダイアログの「列グループを含める」チェックボックスを選択している場合は、生成されたJSFページに、「グループ化しないで動的表に対して作成されるタグ」で説明されているタグに加え、switcherとgroupタグが含まれます。

switcherタグは、columnタグ内で直接ネストされます。switcherタグ内には、GROUPおよびATTRIBUTEという名前のネストされたfacetタグがあります。GROUPファセットにはgroupタグが含まれ、その内部に、グループ名とiteratorタグを表示するoutputTextタグがあり、それにはdynamicComponentタグを含むcolumnタグが含まれます。ATTRIBUTEファセットにはdynamicComponentタグのみが含まれます。

高レベルのiteratorが反復する各属性の場合、切替え機能により、グループまたは列をレンダリングするかどうかが動的に決定されます。グループをレンダリングする場合、グループ内のイテレータはそのグループ内の列をレンダリングするために使用されます。

次の例は、Countriesコレクションに基づいた動的フォームを作成し、列グループを含めるように選択した場合に生成されるコードを示しています。

<af:table value="#{bindings.Countries.collectionModel}" var="row"
rows="#{bindings.Countries.rangeSize}"
emptyText="#{bindings.Countries.viewable ? 'No data to display.' : 'Access Denied.'}"
rowBandingInterval="0" fetchSize="#{bindings.Countries.rangeSize}"
id="t1">
<af:iterator id="i1"
value="#{bindings.Countries.attributesModel.hierarchicalAttributes}"
var="column">
<af:column headerText="#{column.label}" id="c1">
<af:switcher id="sw1" facetName="#{column.descriptorType}"
defaultFacet="ATTRIBUTE">
<f:facet name="GROUP">
<af:iterator id="gi1" value="#{column.descriptors}"
var="nestedCol">
<af:column headerText="#{nestedCol.label}" id="c2">
<af:dynamicComponent id="gd1"
attributeModel="#{nestedCol}"
value="#{row.bindings[nestedCol.name].inputValue}"/>
</af:column>
</af:iterator>
</f:facet>
<f:facet name="ATTRIBUTE">
<af:dynamicComponent id="ad1" attributeModel="#{column}"
value="#{row.bindings[column.name].inputValue}"/>
</f:facet>
</af:switcher>
</af:column>
</af:iterator>
</af:table>

iteratorタグのvalue属性では、コレクションのツリー・バインディングのattributesModel.hierarchicalAttributesプロパティに評価されるEL式を使用します。attributesModelプロパティは、コンポーネント・タイプ、ラベル、ツールチップ、レンダリングされる実際のコンポーネントの他のプロパティなど、データ・オブジェクトの属性およびそのメタデータを取得するために使用されます。hierarchicalAttributesプロパティは、UIヒントの属性に対して設定されたカテゴリを含む、表示可能属性およびそのメタデータの階層リストが提供されることを示します。

dynamicComponentタグのattributeModel属性は、EL式#{column}に設定され、イテレータのvar属性で定義される変数を参照し、データ・コントロール・コレクションおよびその対応するメタデータの現在の列(またはカテゴリ)へのポインタとして機能します。

32.6.3 実行時に行われる処理: 属性値の動的な決定方法

動的コンポーネントを含むページがレンダリングされると、設計時に「データ・コントロール」パネルから項目をドロップしたときと同様に、バインディングが作成されます。ただし、バインディングは実行時に作成されます。詳細は、「実行時に行われる処理: 属性値の動的な決定方法」を参照してください。

32.6.4 detailStampファセットを使用した動的表の作成方法

また、マスター・コンテンツを表示し、ユーザーが指定されたレコードのディテールを表示できるdetailStampファセットを含む動的表を作成できます。ディテール・コンテンツは、マスター・ビュー・オブジェクトでの動的コンポーネントのビュー・リンク・アクセッサへのバインディングから取得されます。図32-10に、このようなディテール・ファセットを含む動的表の一部を示します。表のdetailStampファセットの使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の表への非表示機能の追加に関する項を参照してください。

図32-10 detailStampファセットが表示された動的表

始める前に:

動的表について理解しておくと役立ちます。詳細は、「動的コンポーネントを使用した表の作成」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド表の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法」の説明に従って、必要なマスター/ディテール階層を確立するビュー・オブジェクトとビュー・リンクのインスタンスを含むアプリケーション・モジュールを作成します。

- 「動的表の作成方法」の説明に従って動的表を作成します。

detailStampファセットを使用して動的表を作成するには:

1. JSFページのソース・エディタで、動的表のtableタグ内にfacetタグを挿入します。

2. facetタグ内に、panelFormLayoutタグを挿入します。

3. panelFormLayoutタグ内に、iteratorタグを挿入します。

4. イテレータのvalue属性をデータ・オブジェクトのattributesModel.getLinkedViewAttributes(LinkedViewName)プロパティにバインドします。ここで、LinkedViewNameは、ディテール・コンテンツにアクセスするビュー・リンク・アクセッサの名前です。

5. iteratorタグ内に、dynamicComponentタグを挿入します。

6. dynamicComponentタグのattributeModel属性をiteratorタグのvar属性の値にバインドします。

7. dynamicComponentタグのvalue属性を、選択した行のディテール・データを戻す式にバインドします。

次の例は、ビュー・リンク・アクセッサを使用して取得されたデータを表示するためにdetailStampファセットを使用する動的表のJSFページ・コードを示しています。

<af:table value="#{bindings.EmpVO3.collectionModel}" var="row" id="t1" ...>
<f:facet name="detailStamp">
<af:panelForm id="pgl1" layout="vertical">
<af:iterator id="iter3" var="detail"
value="#{bindings.EmpVO3.attributesModel.getLinkedViewAttributes('DeptView')}">
<af:dynamicComponent value="#{row['DeptView'].bindings[detail.name].inputValue}"/> attributeModel="#{detail}" id="dc1"/>
</af:iterator>
</af:panelForm>
</f:facet>
<af:iterator id="itr1" var="column"
value="#{bindings.EmpVO3.attributesModel.attributes}">
<af:column headerText="#{column.label}" id="dcc1">
<af:dynamicComponent value="#{row.bindings[column.name].inputValue}" attributeModel="#{column}" id="dc1"/>
</af:column>
</af:iterator>
</af:table>

32.7 表に表示される属性の変更

「データ・コントロール」パネルを使用して表を作成したら、属性の削除、表示順序の変更、表示に使用されるコンポーネントの変更、コンポーネントの属性バインディングの変更ができます。新しい属性を追加したり、表を新規のデータ・コントロールに再バインドすることもできます。

32.7.1 表示される属性の変更方法

「データ・コントロール」パネルを使用して作成された表は、次のような変更ができます。

- 行のラベルに対するバインディングの変更

- 属性にバインドされているUIコンポーネントの変更

- 属性を表す列の追加または削除

- 表内の列の並替え

- 選択とソート処理の有効化

始める前に:

データバインド表の変更について理解しておくと役立ちます。詳細は、「表に表示される属性の変更」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド表の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「基本表の作成」の説明に従い、データバインドされた表を作成します。

表の属性を変更するには:

1. 「構造」ウィンドウで、表コンポーネントを選択します。

2. 「プロパティ」ウィンドウで「列」セクションを開き、列として表示される属性を変更、追加または削除します。列内でデータ表示に使用されるUIコンポーネントを変更することもできます。

3. 「プロパティ」ウィンドウの他のセクションを開き、フィルタリングやソートなど、表の表示や動作を変更します。

32.7.2 表のバインディングの変更方法

バインディングを変更するかわりに、表がバインドされているオブジェクトを完全に変更することができます。

始める前に:

データバインド表の変更について理解しておくと役立ちます。詳細は、「表に表示される属性の変更」を参照してください。

また、その他のADF機能について理解しておくと役立ちます。詳細は、「データバインド表の追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「基本表の作成」の説明に従い、データバインドされた表を作成します。

表をリバインドするには:

1. 「構造」ウィンドウで表を右クリックし、「別のADFコントロールに再バインド」を選択します。

2. 「ADFコントロールにバインド」ダイアログで、表のバインド先とする新しいコレクションを選択します。

表のバインディングを変更すると、すべての列のバインディングも変更されます。「表示される属性の変更方法」の手順に従って、これらのバインディングを変更できます。

ヒント:

既存の表の最上部に異なるビュー・オブジェクトをドラッグして表を再バインドすることもできます。

32.7.3 バインディングまたは表示される属性の変更時に発生する処理

UIコンポーネントを移動または変更して単に属性の表示方法を変更すると、JSFページの対応するコードが変更されます。バインディング・エディタを使用してバインディングを追加または変更すると、JDeveloperによって、JSFページにコードが追加され、ページ定義ファイルに適切な要素が追加されます。

33 ビュー・レイヤーで各機能を起動するコマンド・コンポーネントの使用

この章では、Fusion Webアプリケーションで、ADF Facesコマンド・コンポーネントとADFモデル・データ・バインディングを使用して、ADFビジネス・コンポーネントでカスタム・メソッドを起動する方法について説明します。具体的には、メソッドにパラメータを渡す方法、「データ・コントロール」パネルからメソッドをドラッグ・アンド・ドロップするときに作成される宣言メソッドをオーバーライドする方法など、ADF Facesコンポーネントを使用してADFビジネス・コンポーネント・クライアント・インタフェース・メソッドを起動する方法について説明します。

この章の内容は次のとおりです。

- コマンド・コンポーネントについて

- メソッドを実行するためのコマンド・コンポーネントの作成

- コマンド・コンポーネントを使用したパラメータ値の設定

- 宣言メソッドのオーバーライド

33.1 コマンド・コンポーネントについて

基本的なページを作成してナビゲーション機能を追加すると、ページ間でパラメータを渡したり、宣言アクションをオーバーライドする機能を提供するなどの、より複雑な機能を追加できます。Oracle ADFには、このような複雑な機能を実際のコードをほとんど使用せずに追加できる機能が数多く用意されています。

この章で説明する実装メソッドのいくつかは、ページレベルの設計のためのものです。タスク・フローを使用することにより、同じ機能の多くを実行できます。詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。

33.1.1 コマンド・コンポーネントのユースケースと例

コマンド・コンポーネントを使用すると、パラメータの引渡し、宣言アクションのオーバーライド、なんらかのロジックの実行といったアクションを実行できます。「データ・コントロール」パネルでコマンド・コンポーネントをカスタム・メソッドにバインドできます。たとえば、deleteOrderItem()というカスタム・メソッドがある場合、ボタンを作成してこのメソッドにバインドすると、ユーザーがこのボタンを押したときに注文項目を削除できます。

コマンド・コンポーネント内でsetPropertyListenerタグを使用して、イベント発生時に値を割り当てることもできます。たとえば、検索を開始して、マネージドBeanに保存されたパラメータ値に基づき、別のページ上に検索結果を表示するボタンを作成できます。setPropertyListenerプロパティを使用して、値をチェックするメソッドにこのパラメータ値を渡すことができます。

コマンド・コンポーネントにバインドされた宣言メソッドにコードを追加できます。たとえば、宣言的なCommitボタンを作成した後、マネージドBeanにコードを追加してから、追加処理用にCommit操作をオーバーライドできます。

33.1.2 コマンド・コンポーネントの追加機能

コマンド・コンポーネントの処理を開始する前に、その他のOracle ADF機能を理解しておくと役に立ちます。次に、関連する他の機能へのリンクを示します。

- コマンド・コンポーネントとしてページに追加可能なカスタム・メソッドの作成の詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」および「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

- 操作によるコマンド・コンポーネントの作成の詳細は、「操作を使用したコマンド・コンポーネント作成時の処理」を参照してください。

- メソッド内でEL式を使用する場合は、「操作へバインドするために作成されるEL式」を参照してください。

- コマンド・ボタンのactionListener属性の詳細は、「実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法」を参照してください。

- ADFバインディングの詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

- タスク・フローを使用している場合、タスク・フローのパラメータ渡しメカニズムを使用できます。詳細は、「タスク・フローのパラメータの使用」を参照してください。

- タスク・フローのコール・メソッドの使用を検討している場合は、「メソッド・コール・アクティビティの使用」を参照してください。

- マネージドBeanを使用する場合は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

33.2 メソッドを実行するためのコマンド・コンポーネントの作成

アプリケーションにカスタム・メソッドが含まれている場合、これらのメソッドは「データ・コントロール」パネルに表示されます。これらのメソッドは、コマンド・ボタンとしてドラッグ・アンド・ドロップできます。ユーザーがボタンをクリックすると、メソッドが実行されます。

カスタム・メソッドの作成の詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」および「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

注意:

タスク・フローを使用している場合、タスク・フロー定義からメソッドを直接コールできます。詳細は、「メソッド・コール・アクティビティの使用」を参照してください。

たとえば、Oracle ADFのSummitサンプル・アプリケーションのItemsForOrderビュー・オブジェクトには、deleteOrderItem()メソッドが含まれています。このメソッドは、ショッピング・カート内の項目を更新します。ユーザーがこのメソッドを実行できるようにするには、図33-1のように、「データ・コントロール」パネルからdeleteOrderItem()メソッドをドラッグします。

図33-1 「データ・コントロール」パネルに表示されたメソッド

要求されるビジネス・ロジックを実行するために、多くのメソッドでは、そのパラメータ(1つ以上)に対する値を必要とします。つまり、メソッドにバインドされたボタンを作成する際に、EL式を作成して、パラメータの値の取得元を指定する必要があります。たとえば、populateInventoryForProduct(String productId)メソッドを使用する場合は、メソッド・アクション・バインディングを構成して製品IDを取得し、メソッドがそのIDを使用して製品のインベントリを表示できるようにする必要があります。

33.2.1 カスタム・メソッドにバインドされたコマンド・コンポーネントの作成方法

「データ・コントロール」パネルからフォームにカスタム・メソッドをドラッグすることにより、カスタム・メソッドにバインドされたコマンド・コンポーネントを作成します。

始める前に:

カスタム・メソッドについて理解しておくと役立ちます。詳細は、「メソッドを実行するためのコマンド・コンポーネントの作成」を参照してください。

また、他のコマンド・コンポーネントを使用して追加できる機能について理解しておくと役立ちます。詳細は、「コマンド・コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトおよびカスタム・メソッドのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

カスタム・メソッドにバインドされたコマンド・コンポーネントを作成するには:

1. 「データ・コントロール」パネルから、メソッドをページにドラッグします。

ヒント:

表またはフォームに含まれるデータを使用するメソッドのボタンをドロップする場合は、その表またはフォームの中にボタンをドロップする必要があります。

2. ポップアップ・メニューから「作成」>→「メソッド」>→「ADFボタン」を選択します。

メソッドがパラメータを取る場合は、「アクション・バインディングの編集」ダイアログが開きます。「アクション・バインディングの編集」ダイアログで、各パラメータの値を入力するか、「パラメータ」の「値」列で「EL式ビルダーの表示」メニュー選択をクリックし、EL式ビルダーを起動します。

33.2.2 メソッドを使用したコマンド・コンポーネント作成時の処理

メソッドをコマンド・ボタンとしてドロップすると、JDeveloperによって次の処理が行われます。

- メソッドのメソッド・アクション・バインディングが定義されます。

- メソッドがパラメータを取得する場合は、パラメータ値を保持するNamedData要素が作成されます。

- ADF Facesコマンド・コンポーネント用のコードがJSFページに挿入されます。

- actionListenerを使用して、ボタンにメソッドをバインドします。

- メソッド・コールからの戻り値を使用します。

33.2.2.1 アクション・バインディング

JDeveloperはメソッドにアクション・バインディングを追加します。アクション・バインディングはRequiresUpdateModelプロパティを使用して、アクションを実行する前にモデルを更新する必要があるかどうかを判別します。コマンド操作の場合、デフォルトではこのプロパティはtrueに設定されています。つまり、ビュー・レイヤーでのすべての変更は、操作を実行する前にモデルに移動する必要があります。

33.2.2.2 メソッドのパラメータ

パラメータを取得するメソッドをJSFページにドロップすると、メソッド・アクション・バインディングが作成されます。このバインディングにより、ユーザーがコマンド・コンポーネントをクリックしたときにメソッドが実行されるようになります。メソッドが実行するパラメータを要求する場合は、JDeveloperによって、各パラメータのNamedData要素も作成されます。これらの要素は、メソッドのパラメータを表します。

たとえば、ADFタスク・フローのSummitサンプル・アプリケーションのpopulateInventoryForProduct(String)メソッド・アクション・バインディングには、StringパラメータのNamedData要素が含まれます。この要素は、アクション・バインディングの作成時に指定した値にバインドされます。次の例は、populateInventoryForProduct(String)メソッドをドロップし、Stringパラメータ(productId)を適切な変数にバインドしたときに作成されるメソッド・アクション・バインディングを示しています。

<methodAction id="populateInventoryForProduct" RequiresUpdateModel="true"
Action="invokeMethod"
MethodName="populateInventoryForProduct" IsViewObjectMethod="true"
DataControl="BackOfficeAppModuleDataControl"
InstanceName="data.BackOfficeAppModuleDataControl.InventoryVO1">
<NamedData NDName="productId" NDType="java.lang.String"/>
</methodAction>

33.2.2.3 ADF Facesコンポーネント・コード

JDeveloperはADF Facesコンポーネント用のコードをJSFページに追加します。このコードは、「EL式を使用したメソッドへのバインド」で説明しているように、その他のコマンド・ボタンのコードに似ています。ただし、ボタンは、組込み操作用のアクション・バインディングのexecuteメソッドではなく、ドロップしたメソッド用のメソッド・アクション・バインディングのexecuteメソッドにバインドされます。

33.2.2.4 EL式を使用したメソッドへのバインド

操作を使用してコマンド・ボタンを作成するときと同様に、メソッドを使用してコマンド・ボタンを作成すると、actionListener属性を使用して、ボタンがメソッドに自動的にバインドされます。ボタンは、EL式を使用して、指定されたメソッドのアクション・バインディングのexecuteプロパティにバインドされます。このEL式により、アプリケーション・モジュールに対してバインディングのメソッドが起動します。コマンド・ボタンのactionListener属性の詳細は、「実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法」を参照してください。

ヒント:

アクション・バインディングのexecuteメソッドにボタンをバインドするかわりに、executeメソッドをオーバーライドするバッキングBean内のメソッドにボタンをバインドできます。そうすることで、元のメソッドの実行前か実行後に、ロジックを追加できるようになります。詳細は、「宣言メソッドの上書き」を参照してください。

ナビゲーション操作のように、ボタンのdisabledプロパティは、EL式を使用してボタンを表示するかどうかを決定します。次の例は、コマンド・ボタンのpopulateInventoryForProduct(String)メソッドへのバインドに使用されるEL式を示しています。

<af:button actionListener="#{bindings.populateInventoryForProduct.execute}"
text="populateInventoryForProduct"
disabled="#{!bindings.populateInventoryForProduct.enabled}"
id="b1"/>

ヒント:

コマンド・ボタン・コンポーネントをページにドロップすると、以前にドロップされた同種のコンポーネントの数に基づいて自動的にIDが付けられます。たとえば、最初の2つのボタンのb1およびb2がドロップされます。このIDをより説明的なものに変更する場合は、ページ内のすべてのEL式でこのIDへの参照を手動で更新する必要があります。

33.2.2.5 メソッド・コールからの戻り値の使用

メソッド・コールからの戻り値を使用することもできます。次の例は、文字列値を戻すカスタム・メソッドを示しています。

/**
* Custom method.
*/
public String getHelloString() {
return ("Hello World");
}

次の例は、コマンド・ボタンおよびoutputTextコンポーネントのJSFページのコードを示しています。

<af:button actionListener="#{bindings.getHelloString.execute}"
text="getHelloString"
disabled="#{!bindings.getHelloString.enabled}"
id="helloButtonId"/>
<af:outputText value="#{bindings.return.inputValue}"
id="helloOutputId"/>

ユーザーがコマンド・ボタンをクリックすると、カスタム・メソッドがコールされます。このメソッドは、outputTextコンポーネントの値として表示される文字列「Hello World」を戻します。

33.2.3 実行時に行われる処理: コマンド・ボタンのメソッド・バインディング

ユーザーがボタンをクリックすると、メソッド・バインディングによって、関連付けられているメソッドが起動し、NamedData要素にバインドされている値がパラメータとして渡されます。たとえば、ユーザーがopulateInventoryForProduct(String productId)メソッドにバインドされるボタンをクリックすると、メソッドはproductIdパラメータの値を取得し、その製品の在庫を表示します。

33.3 コマンド・コンポーネントを使用したパラメータ値の設定

1つのページでのアクションに対して、アプリケーション機能を判別するためのパラメータを設定する必要が生じる場合があります。たとえば、あるページから別のページの結果表へ移動する検索ボタンを作成できます。ただし、結果表が表示されるのはパラメータ値がfalseの場合のみです。

ページ間でこのパラメータを渡す場合やパラメータ値のチェックに使用するメソッドを含める場合には、マネージドBeanを使用できます。検索ページのレンダリング時にマネージドBeanがインスタンス化され、このBeanのメソッドによってこのパラメータがチェックされます。このパラメータがnullの場合(ページが初めてレンダリングされる場合)は、値がtrueに設定されます。

カスタム・メソッドの作成の詳細は、「サービス・メソッドによるアプリケーション・モジュールのカスタマイズ」および「UIクライアントへのカスタム・サービス・メソッドの公開」を参照してください。

注意:

タスク・フローを使用している場合、タスク・フローのパラメータ渡しメカニズムを使用できます。詳細は、「タスク・フローのパラメータの使用」を参照してください。

typeプロパティがactionに設定されたsetPropertyListenerコンポーネント(この検索を実行したコマンド・ボタンにネストされている)を使用してこのフラグがfalseに設定されるため、検索の実行後に結果表が表示されるようになります。マネージドBeanの使用の詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

33.3.1 コマンド・コンポーネント内でのsetPropertyListenerを使用したパラメータの設定方法

setPropertyListenerコンポーネントを使用して、その他のオブジェクトの値を設定できます。このコンポーネントは、コマンド・コンポーネントの子である必要があります。

始める前に:

setPropertyListenerおよびマネージドBeanを使用して値を設定する方法について理解しておくと役立ちます。詳細は、「コマンド・コンポーネントを使用したパラメータ値の設定」を参照してください。

また、他のコマンド・コンポーネントを使用して追加できる機能について理解しておくと役立ちます。詳細は、「コマンド・コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトおよびカスタム・メソッドのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

setPropertyListenerコンポーネントを使用するには:

1. 「アプリケーション」ウィンドウで、リスナーを追加するコマンド・コンポーネントを含むWebページをダブルクリックします。

2. ページの設計エディタで、コマンド・コンポーネントを右クリックして、「内部に挿入」ボタン→「ADF Faces」を選択します。

3. ADF Facesアイテムの挿入ダイアログで「プロパティ・リスナーの設定」を選択し、「OK」をクリックします。

4. 「プロパティ・リスナーの設定の挿入」ダイアログの「選択元」フィールドにパラメータ値を入力します。

フィールドの右にカーソルを移動し、表示されるアイコンをクリックして、「式ビルダー」を選択すると、このフィールドの式ビルダーを表示できます。

5. 「先」フィールドにパラメータのターゲットを入力します。

フィールドの右にカーソルを移動し、表示されるアイコンをクリックして、「式ビルダー」を選択すると、このフィールドの式ビルダーを表示できます。

ヒント:

作成されるページのページ定義ファイルに直接パラメータ値を設定するかわりに、マネージドBeanまたはスコープにパラメータ値を格納することを考慮してください。次のページに直接設定すると、それ以降、ナビゲーションを簡単に変更できなくなります。詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。また、バインディング・コンテナ内のデータは、そのコンテナが準備されたリクエストでのみ有効です。データを設定してから次のページがレンダリングされるまでの間に、データが変更される場合があります。

6. 「タイプ」ドロップダウン・メニューから「アクション」を選択します。

7. 「OK」をクリックします。

33.3.2 setPropertyListenerを使用したパラメータ設定時の処理

setPropertyListenerコンポーネントを使用すると、次のページに移動する前にコマンド・コンポーネントによって値が設定されます。渡す必要がある値のソースまたは実際の値をfrom属性に設定すると、コンポーネントからその値へのアクセスが可能になります。to属性をターゲットに設定すると、コマンド・コンポーネントによってターゲットに値が設定されるようになります。次の例は、false値を取得し、その値をsearchResultsマネージドBeanのinitialSearchフラグの値として設定するコマンド・コンポーネントのJSFページのコードを示しています。

<af:button actionListener="#{bindings.Execute.execute}"
text=Search>
<af:setPropertyListener from="#{false}"
to="#{searchResults.initialSearch}"/>
type="action"/>
</af:button>

33.3.3 実行時に行われる処理: コマンド・コンポーネントに対するsetPropertyListener

ユーザーがコマンド・コンポーネントをクリックすると、移動する前に、setPropertyListenerコンポーネントによってパラメータ値が設定されます。「setPropertyListenerを使用したパラメータ設定時の処理」の例に示すように、setPropertyListenerはfalse値を取得し、その値をsearchResultsマネージドBeanのinitialSearch属性の値として設定しています。これで、レンダリングするかどうかを決定するためにこの値を認識する必要があるコンポーネントは、EL式#{searchResults.initialSearch}を使用してアクセスできます。

33.4 宣言メソッドのオーバーライド

操作またはメソッドをコマンド・ボタンとしてドロップすると、操作またはメソッドのexecuteメソッドに、そのボタンが自動的にバインドされます。ただし、既存のロジックの前または後に、ロジックの追加が必要になる場合もあります。

注意:

タスク・フローを使用している場合、タスク・フローからカスタム・メソッドをコールできます。詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。

JDeveloperを使用すると、バインディング・コンテナにアクセスするマネージドBeanでメソッドおよびプロパティを新規作成することにより、宣言的操作にロジックを追加できます。デフォルトでは、この生成されたコードによって、操作またはメソッドが実行されます。その後、このコードの前か後にロジックを追加できます。元の操作またはメソッドのexecuteプロパティではなく、この新規メソッドにコマンド・コンポーネントが自動的にバインドされます。その後、ユーザーがボタンをクリックすると、新規メソッドが実行されます。

たとえば、Summit ADFタスク・フロー・サンプル・アプリケーションのCustomers.jsffフラグメントでは、「新規」アイコンをクリックして、新規注文を作成できます。ただし、宣言的CreateInsert操作には、追加処理が必要です。ボタンをクリックすると、注文の詳細を示す新規タブが表示される必要があります。この処理を提供するために、CustomersBackingBeanのマネージドBeanのcreateNewOrderメソッドにロジックが追加されます。

宣言メソッドをオーバーライドするには、マネージドBeanにコマンド・コンポーネントがバインドされる新規メソッドを保持させる必要があります。ページにバッキングBeanが関連付けられている場合は、JDeveloperによって、バインディング・オブジェクトへのアクセスに必要なコードがバッキングBeanに追加されます。ページにバッキングBeanが関連付けられていない場合は、作成を促す指示が表示されます。

33.4.1 宣言メソッドのオーバーライド方法

コマンド・コンポーネントを追加して、マネージドBeanを使用してその宣言メソッドをオーバーライドできます。

始める前に:

宣言メソッドのオーバーライド方法について理解しておくと役立ちます。詳細は、「宣言メソッドの上書き」を参照してください。

また、他のコマンド・コンポーネントを使用して追加できる機能について理解しておくと役立ちます。詳細は、「コマンド・コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトおよびカスタム・メソッドのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

注意:

現在、コマンド・コンポーネントのAction属性の値としてEL式が設定されている場合は、JDeveloperによってEL式が上書きされないため、宣言メソッドをオーバーライドできません。次の手順を行う前に、この値を削除する必要があります。

宣言メソッドのオーバーライドの手順:

1. オーバーライドする操作またはメソッドをJSFページ上にドラッグし、UIコマンド・コンポーネントとしてドロップします。

コンポーネントが作成され、ActionListener属性を使用してADFモデル・レイヤーの関連するバインディング・オブジェクトにバインドされます。

「データ・コントロール」パネルでメソッドを使用したコマンド・コンポーネントの作成の詳細は、「メソッドを実行するためのコマンド・コンポーネントの作成」を参照してください。

操作によるコマンド・コンポーネントの作成の詳細は、「操作を使用したコマンド・コンポーネント作成時の処理」を参照してください。

2. JSFページでコンポーネントをダブルクリックします。

3. 「バインド・アクション・プロパティ」ダイアログで、次のいずれかの方法で、バッキングBeanとコンポーネントのバインド先とするメソッドを指定します。

- ページで自動バインディングが有効になっている場合(「JSFページの作成」ウィザードの「マネージドBean」タブにある「新規マネージドBeanでのUIコンポーネントの自動公開」を選択)、バッキングBeanがすでに選択されています。

- 新規メソッドを作成するには、「メソッド」フィールドにメソッドの名前を入力します。このフィールドには、最初にデフォルト名が表示されています。
または

- 既存のメソッドを使用するには、「メソッド」フィールドのドロップダウン・リストからメソッドを選択します。

- 「生成にADFバインディングを使用」を選択します。

- そのページで自動バインディングが使用されていない場合は、既存のバッキングBeanから選択するか、新規作成できます。

- 「新規」をクリックして、新しいバッキングBeanを作成します。「マネージドBeanの作成」ダイアログで、Beanおよびクラスに名前を付け、Beanのスコープを設定します。
または

- 既存のバッキングBeanおよびメソッドをドロップダウン・リストから選択します。

図33-2に、メソッド・バインディングに対して指定されるマネージドBeanのメソッドを使用した「バインドActionプロパティ」ダイアログを示します。

図33-2 「バインドActionプロパティ」ダイアログ

注意:

コマンド・コンポーネントにActionListener属性の値が存在する場合は常に、ボタンのバインド先はバインディングのexecuteプロパティであるとみなされます。そのバインディングを削除した場合は、ADFバインディング・コードを生成することを選択できなくなります。その場合は、コマンド・コンポーネントをダブルクリックする前に、コードを手動で挿入するか、ActionListenerのダミー値を設定する必要があります。

4. バッキングBeanおよびメソッドを識別したら、「バインドActionプロパティ」ダイアログで「OK」をクリックします。

ソース・エディタでマネージドBeanが開きます。次の例は、Summit ADFタスク・フロー・サンプル・アプリケーションのBeanに挿入されるコードを示しています。この例では、コマンド・ボタンがCreateInsert操作にバインドされています。

public void createNewOrder() {
BindingContainer bindings = getBindings();
OperationBinding operationBinding =
bindings.getOperationBinding("CreateInsert");
Object result = operationBinding.execute();
if (!operationBinding.getErrors().isEmpty()) {
return null;
}
}

5. これで、次の例に太字のコードで示すように、バインディング・オブジェクトにアクセスする前または後に、ロジックを追加できます。

public void createNewOrder() {
//This method is called when creating a new order
//to create the record and switch the tab
getSdi3().setDisclosed(false);
getSdi4().setDisclosed(true);
BindingContainer bindings = getBindings();
OperationBinding operationBinding =
bindings.getOperationBinding("CreateInsert");
operationBinding.execute();
AdfFacesContext adfFacesContext = AdfFacesContext.getCurrentInstance();
adfFacesContext.addPartialTarget(getSdi4());
}

処理ロジックに加えて条件付きロジックを記述し、複数の結果の中から1つを戻すこともできます。たとえば、処理中にエラーが発生した場合にはnullを、処理が正常終了した場合は別の結果値を戻すことができます。nullの戻り値により、ナビゲーション・ハンドラはナビゲーション・ケースを評価せずに、そのまま現在ページを再表示します。

ヒント:

特定のナビゲーション・ケースをトリガーするには、メソッドによって戻される結果値が、ナビゲーション・ルールの結果値と(大/小文字も含めて)完全に一致する必要があります。

この時点で、コマンド・ボタンは、ActionListener属性ではなく、Action属性を使用して新しいメソッドにバインドされています。Action属性の値(結果文字列など)がすでに存在していた場合は、その値が新規メソッドの戻りとして追加されます。値が存在していなかった場合は、戻りがnullのままになります。

33.4.2 宣言メソッドのオーバーライド時の処理

宣言メソッドをオーバーライドすると、JDeveloperにより、管理プロパティがバッキングBeanに追加され、この管理プロパティに値#{bindings}(バインディング・コンテナへの参照)が設定されます。また、強く型付けされたBeanプロパティがBindingContainer型のクラスに追加され、JSFランタイムにより、値として管理プロパティ式#{bindings}が設定されます。また、JDeveloperはUIコマンド・アクション・メソッドにロジックを追加します。このロジックには、現在のバインディング・コンテナへのアクセスに使用されている、強く型付けされたgetBindings()メソッドが含まれます。

このコードは、次の操作を実行します。

- バインディング・コンテナにアクセスします。

- 関連付けられているメソッドのバインディングを検索し、実行します。

- ナビゲーションに使用できるメソッドの戻り値を追加します。デフォルトでは、戻り値はnullです。ボタンのAction属性に結果文字列がすでに存在する場合は、その属性が戻り値として使用されます。このコードは、必要に応じて変更できます。

ActionListener属性ではなく、Action属性を使用して新しいメソッドにUIコマンド・コンポーネントがリバインドされます。次の例は、CreateInsert操作が宣言的にページに追加される場合のコードを示しています。

<af:button actionListener="#{bindings.CreateInsert.execute}"
text="CreateInsert"
disabled="#{!bindings.CreateInsert.enabled}"/>

次の例は、ページのバッキングBeanのメソッドをオーバーライドした後のボタン・タブのコードを示しています。ここでは、action属性は、バッキングBeanのメソッドにバインドされています。

<af:button text="New"
action="#{backingBeanScope.CustomersBackingBean.createNewOrder}"/>

ヒント:

オーバーライド後のメソッドを使用するボタンをクリックすると、次のエラーが表示されます。

SEVERE: マネージドBean main_beanを作成できませんでした。参照されるオブジェクトのスコープ: '#{bindings}'が、参照するオブジェクトより小さいです。

これは、オーバーライド後のメソッドを含むマネージドBeanのスコープが、requestより大きい(つまり、sessionまたはapplicationである)ためです。メソッドで参照されるバインディング・コンテナ内のデータのスコープがrequestであるため、このマネージドBeanのスコープは同じか、より小さいスコープに設定する必要があります。

34 マスター/ディテール・データの表示

この章では、ADFデータ・コントロールおよびADF Facesコンポーネントを使用して、ADFビジネス・コンポーネントからデータがモデル化されたマスター/ディテール・オブジェクトを作成する方法について説明します。事前作成済のマスター/ディテール・ウィジェット、表、ツリーおよびツリー表を使用してマスター/ディテール・データを表示する方法と、選択イベントの操作方法について説明します。

この章の内容は次のとおりです。

- マスター/ディテール・データの表示について

- マスター/ディテール表、フォームおよびツリーの前提条件

- 表およびフォームを使用したマスター/ディテール・オブジェクトの表示

- ツリーを使用したマスター/ディテール・オブジェクトの表示

- ツリー表を使用したマスター/ディテール・オブジェクトの表示

- リスト・ビューを使用したマスター/ディテール・オブジェクトの表示

- ツリーおよびツリー表での選択イベントについて

選択リストを使用して、関連するマスター・コレクションまたはディテール・コレクションからのキー値をコレクションに移入する方法の詳細は、「データバインドされた選択リストおよびシャトルの作成」を参照してください。

34.1 マスター/ディテール・データの表示について

データを階層形式で表現する必要がある場合が多くあります。マスター/ディテール関係では、ユーザーがマスター・データ・オブジェクト内でアイテムの選択を変更すると、これに合せ、ディテール・データ・オブジェクト内で表示されていたデータ・セットも変更されます。たとえば、マスター・オブジェクト内でテレビのカテゴリを選択すると、ディテール・オブジェクトにはすべてのテレビ・モデルが表示されます。

ADF Faces UIコンポーネントと組み合せてADFモデルを使用すると、複数のオブジェクトでマスター/ディテール関係が定義されている場合には、これらのオブジェクトから同時にデータを表示するマスター/ディテール・ページを宣言的に作成できます。ADFイテレータ・バインディングは、選択されたマスター・データ・オブジェクトに対して表示されるディテール・データ・オブジェクトの同期化を自動的に管理します。

ADFビジネス・コンポーネントにおけるマスター/ディテール関係は、ビュー・リンクが2つのビュー・オブジェクト・インスタンスを関連付けるように作成される場合に確立されます。「ビュー・オブジェクトについて」で説明しているように、ビュー・リンクは2つのビュー・オブジェクト間の関係を表します。通常は基礎となるデータ表間の外部キー関係に基づきますが、そうである必要はありません。ビュー・リンクは、1つのビュー・オブジェクト・インスタンス(マスター・オブジェクト)の行を別のビュー・オブジェクト・インスタンス(ディテール・オブジェクト)の1つ以上の行に関連付けます。

34.1.1 マスター/ディテールの表、フォームおよびツリーのユースケースと例

オブジェクトがマスター/ディテール関係にある場合は、両方のオブジェクトのデータを同時に表示するページを宣言的に作成できます。たとえば、図34-1に示すページでは、ページ上部のフォームには顧客の入力を表示し、ページ下部には顧客注文の表を示しています。このような表示ができるのは、オブジェクトがマスター/ディテール関係にあるためです。この例では、Customersビュー・オブジェクトがマスター・オブジェクトで、OrdersForCustomerがディテール・オブジェクトです。ADFイテレータは、選択されたマスター・データ・オブジェクトに対して表示されるディテール・データ・オブジェクトの同期化を自動的に管理します。イテレータ・バインディングにより、データ・コレクションのスクロール処理やページング、または概要情報から詳細情報へのドリルダウンを可能にするユーザー・インタフェースを簡単に作成できます。

図34-1 マスター・フォームとディテール表

マスター/ディテール・オブジェクトは、フォーム、表、ツリーおよびツリー表に表示します。これらのオブジェクトは同じページまたは別々のページに表示できます。たとえば、マスター・オブジェクトをあるページの表に表示し、ディテール・オブジェクトを別のページの読取り専用フォームに表示できます。

マスター・オブジェクトは多数のディテール・オブジェクトを保持でき、各ディテール・オブジェクトも自身のディテール・オブジェクトを多くのレベル(深さ)にわたって保持できます。この階層内のディテール・オブジェクトの1つを「アプリケーション」ウィンドウからマスター/ディテール・フォームとしてページにドロップすると、直接の親マスター・オブジェクトのみがページに表示されます。最上位の親オブジェクトまで、階層全体が表示されるわけではありません。

ディテール・オブジェクトをツリーまたはツリー表オブジェクトとして表示すると、深さのレベルが複数ある階層全体を、最上位のマスター・オブジェクトから始まり、各ノードのディテール子オブジェクトを横断して表示できます。

図34-1は、ディテール表を伴うマスター・フォームの例を示します。ユーザーがコマンド・ボタンを使用して顧客間を移動する場合、顧客が行った注文が表にリストされます。

図34-2は、2レベルのノードからなるツリーを示します。ツリーを使用して、階層情報を表示できます。この例では、ツリーを使用して、国別にグループ化された顧客が表示されています。ユーザーは各ノードを開いて、ツリーのブランチを下位に横断し、リーフ・レベルのアイテムにアクセスできます。

図34-2 複数レベルのツリー

図34-3は、国別だが、ツリーではなくツリー表を使用した、グループ化された同じ顧客を示しています。ツリー表では、階層ノード・レベルのツリーだけでなく、各ノードに対する列情報も表示できます。また、要素を開いたり閉じるだけでなく、サブツリーに焦点を当てることもできます。

図34-3 ツリー表

34.1.2 マスター/ディテール表、フォームおよびツリーの追加機能

ADFモデル・レイヤーを構成または使用する前に、他のOracle ADF機能を理解しておくと役立つ場合があります。また、モデル・レイヤーの構成によって可能になることについても、確認しておくことをお薦めします。次に、関連する他の機能へのリンクを示します。

- ADFビュー・オブジェクトおよびビュー・リンク: フォーム内でのコンポーネントの表示方法および機能のほとんどは、対応するビュー・オブジェクトによって制御されます。ビュー・オブジェクトの作成方法およびビュー・リンクでのデータ・モデルのマスター/ディテール階層の確立の詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。

- ADFアプリケーション・モジュール: ページにデータバインドされたコンポーネントをドラッグする「データ・コントロール」パネルに、アプリケーション・モジュールに追加したビュー・オブジェクトの表示が移入されます。詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

- アダプタベースのデータ・コントロール: EJBコンポーネントやWebサービスなど他のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』の説明に従って、ビジネス・サービス用データ・コントロールを作成できます。

- ADFモデルとデータ・バインディング: ADF Webアプリケーション内でフォームを作成する場合は、ADFモデルおよびデータ・バインディングを使用します。詳細は、「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。

- ADF Faces: ADF Faces UIコンポーネントも使用します。ADF Facesを使用した開発の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

- ADFフォームおよび表: デフォルトのフォームまたは表を変更する場合は、「データ・コントロールのコレクションを使用した基本的なフォームの作成」または「基本表の作成」を参照してください。

- タスク・フロー: トランザクションに携わるフォームの場合は、フォームのレンダリングの前または後に、ADFタスク・フローを使用して特定の操作を起動する必要がある場合があります。詳細は、「ADFタスク・フローの作成」を参照してください。

- イベント処理: クライアント側イベントを処理するためにリスナー・メソッドを記述することが必要な場合があります。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「イベントの処理」を参照してください。

- マネージドBean: イベントの処理および他のフロントエンド処理にマネージドBeanの作成が必要な場合があります。マネージドBeanの作成および使用の詳細は、「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。

34.2 マスター/ディテール表、フォームおよびツリーの前提条件

マスター/ディテール表、フォーム、ツリーおよびツリー表を使用するには、データ・モデル内でマスター/ディテール関係を確立する必要があります。マスター/ディテール関係は、「データ・コントロール」パネルに反映され、そこからマスター/ディテール・データを表示するページを宣言的に作成するオブジェクトをドラッグ・アンド・ドロップできます。

ADFビジネス・コンポーネント・アプリケーションでのマスター/ディテール関係は、2つのビュー・オブジェクト間のビュー・リンクを作成することによって示します。次に、マスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトの両インスタンスをアプリケーション・モジュールのデータ・モデルに追加します。詳細は、「データ・モデルでアクティブなマスター/ディテール調整を有効化する方法」を参照してください。

注意:

WebサービスやEJBセッションBeanなど、他のビジネス・サービスに基づいたデータ・コントロールの場合、マスター/ディテール関係は通常、Webサービスの定義ファイルまたはJPAベースのBeanのJoinColumnアノテーションなど、これらのサービス内の標準メカニズムから推定されます。

たとえば、図34-4に示すように、Oracle ADFのSummitサンプル・アプリケーションにはCustomerId属性に基づくCustomerVOビュー・オブジェクトからOrdVOビュー・オブジェクトへのビュー・リンクがあり、どちらもアプリケーション・モジュールのデータ・モデルに含まれています。マスター・ビュー・オブジェクト・インスタンスの現在の行を変更すると、ディテール・ビュー・オブジェクト・インスタンスの行セットがリフレッシュされて現在のマスターの詳細が含まれるようになります。

図34-4 CustomerVOおよびOrdVOの両ビュー・オブジェクト間のビュー・リンク

注意:

Summit ADFサンプル・アプリケーションのCustomerVOビュー・オブジェクトとOrdVOビュー・オブジェクトの間のビュー・リンクは、一方向の関係です。ビュー・リンクが双方向で、マスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトの両セットがアプリケーション・モジュールのデータ・モデルに追加された場合、「データ・コントロール」パネルには、OrdersForCustomerコレクションもCustomersコレクションと同じノード・レベルで表示され、OrdersForCustomerコレクションのディテール・インスタンスもCustomersコレクションの子として表示されます。

34.2.1 「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別方法

マスター/ディテール・オブジェクトは「データ・コントロール」パネルの階層を調べることで識別できます。

始める前に:

マスター/ディテールの関係の基本を理解しておくと役立つ場合があります。詳細は、「マスター/ディテール表、フォームおよびツリーの前提条件」を参照してください。

また、マスター/ディテール表およびフォームに使用可能な追加機能についても理解しておくと役立ちます。詳細は、「マスター/ディテール表、フォームおよびツリーの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 必要なマスター/ディテール階層を確立するビュー・オブジェクトとビュー・リンクのインスタンスを含むアプリケーション・モジュールを作成します(「アプリケーション・モジュールの作成と変更」を参照)。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

マスター/ディテール・オブジェクトを識別するには:

- 「アプリケーション」ウィンドウで、「データ・コントロール」パネルを開いて、コレクション・ノードを開き、これらのコレクションのコレクション子ノード検索します。

コレクション・ノードの子コレクション・ノードは、親ノードとのマスター/ディテール関係のディテール部分を表しています。親コレクションは、複数の子コレクションとのマスター/ディテール関係の一部にできます。また、コレクションは複数のレイヤーでネストできます。これは、コレクションを1つのマスター/ディテール関係のディテール部分とし、別のマスター/ディテール関係のマスター部分にできることを意味しています。

図34-5は、Summit ADFサンプル・アプリケーションの「データ・コントロール」パネルに表示された2つのマスター/ディテール関連コレクションを示しています。CustomersコレクションはCustomerVOビュー・オブジェクトのインスタンスで、Customerコレクションの子として表示されているOrdersForCustomerコレクションはOrdVOビュー・オブジェクトのインスタンスです。

ノート

「データ・コントロール」パネルに表示されるマスター/ディテール階層には、関係のカーディナリティ(1対多、1対1、多対多)は反映されません。階層には、別のコレクション(ディテール)から1つ以上のオブジェクトを取得するために使用されているコレクション(マスター)が簡潔に示されます。

図34-5 「データ・コントロール」パネルでのマスター/ディテール・オブジェクト

「データ・コントロール」パネル上のマスター/ディテール階層には、図34-4に示す、アプリケーション・モジュールのデータ・モデルに定義されている階層が反映されます。「データ・コントロール」パネルに表示されるアイコンの詳細は、「「データ・コントロール」パネルの使用方法」を参照してください。

34.3 表およびフォームを使用したマスター/ディテール・オブジェクトの表示

フォームと表コンポーネントを使用してページにマスター/ディテール機能を作成できます。作成するには、個々のフォームおよび表コンポーネントを作成するか、マスター/ディテール・コンポーネント両方を含む事前作成済ウィジェットを使用します。

事前作成済のウィジェットにより、「データ・コントロール」パネルを使用して単一の宣言的アクションで、読取り専用マスター/ディテール・ブラウザ・ページを作成できます。そのために必要な操作は、ディテール・コレクションをページにドロップして、使用するウィジェットのタイプを選択することのみです。生成されたコンポーネントには、エンド・ユーザーがコレクション内のデータ・オブジェクトをスクロールできるレンジ・ナビゲーションが含まれます。テキスト・フィールドまたは列をページから削除すると、不要な属性を削除できます。

図34-6に示す事前作成済のマスター/ディテール・ウィジェットの例では、ページ上部のフォームに一般的な注文情報が表示され、ページ下部の表に注文詳細が表示されています。ユーザーが「次へ」ボタンをクリックし、ページ上部のマスター・データのレコードをスクロールすると、ページが自動的に更新され、現在表示されているマスター・レコードのディテール・データが表示されます。

図34-6 「データ・コントロール」パネルの事前作成済のマスター/ディテール・ウィジェット

JDeveloperで提供される事前作成済マスター/ディテールUIコンポーネントでは必要な機能を発揮できない場合があります。たとえば、マスター/ディテールUIコンポーネントを使用するかわりに、コンポーネントを編集可能にしたり、コンポーネントをプログラム的にバインドすることが必要な場合があります。このような場合には、フォームと表を別々に作成することにより、マスター/ディテール・ページを作成できます。コンポーネントがコレクションおよびネストされたコレクションから作成される場合は、ネストされたコレクションのイテレータ・バインディングはマスターおよびディテール・コンポーネント間の調整を自動的に管理します。詳細は、「個別のコンポーネントからマスター/ディテール・フォームを作成する方法」および「個別のページにマスター/ディテール・コンポーネントを表示する方法」を参照してください。

注意:

また、マスター表のdetailStampファセットを使用して、選択した行のディテールを表示することもできます。動的コンポーネントを使用してこれを行う方法の詳細は、「detailStampファセットを使用した動的表の作成方法」を参照してください。

34.3.1 マスター/ディテール・ウィジェットを使用して表およびフォームにマスター/ディテール・オブジェクトを表示する方法

「データ・コントロール」パネルで事前作成済のマスター/ディテール・フォームおよび表を使用すると、単一の宣言的アクションで、マスター・ウィジェットとディテール・ウィジェットの両方を1つのページ上に作成できます。これらの事前作成済マスター/ディテール・ウィジェットは読取り専用です。マスター・データとディテール・データを個別のページに表示する方法の詳細は、「個別のコンポーネントからマスター/ディテール・フォームを作成する方法」を参照してください。マスター・データとディテール・データを個別のページに表示する方法の詳細は、「個別のページにマスター/ディテール・コンポーネントを表示する方法」を参照してください。

始める前に:

マスター/ディテール表およびフォームの作成で使用可能な各オプションを理解しておくと役立ちます。詳細は、「表およびフォームを使用したマスター/ディテール・オブジェクトの表示」を参照してください。

また、マスター/ディテール表およびフォームに使用可能な追加機能についても理解しておくと役立ちます。詳細は、「マスター/ディテール表、フォームおよびツリーの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 必要なマスター/ディテール階層を確立するビュー・オブジェクトとビュー・リンクのインスタンスを含むアプリケーション・モジュールを作成します(「アプリケーション・モジュールの作成と変更」を参照)。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

事前作成済のADFマスター/ディテール・フォームおよび表を使用したマスター/ディテール・ページを作成するには:

1. 「「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別方法」の説明に従って、「データ・コントロール」パネルでディテール・オブジェクトを特定します。

2. ディテール・オブジェクトをJSFページにドラッグ・アンド・ドロップします。

3. ポップアップ・メニューの「マスター/ディテール」サブメニューから、次のコンポーネントのいずれかを選択します。

- ADFマスター表、ディテール・フォーム: 読取り専用表にマスター・オブジェクトが表示され、表の下にある読取り専用フォームにディテール・オブジェクトが表示されます。
マスター表で特定のデータ・オブジェクトを選択すると、その下にあるフォーム内に、関連する最初のディテール・データ・オブジェクトが表示されます。後続の各ディテール・データ・オブジェクトをスクロールするには、フォーム・ナビゲーションを使用する必要があります。

- ADFマスター・フォーム、ディテール表: マスター・オブジェクトが読取り専用フォームに表示され、ディテール・オブジェクトがフォームの下にある読取り専用表に表示されます。
フォームに特定のマスター・データ・オブジェクトを表示すると、その下にある表に、関連するディテール・データ・オブジェクトが表示されます。

- ADFマスター・フォーム、ディテール・フォーム: マスター・オブジェクトとディテール・オブジェクトが別々の読取り専用フォームに表示されます。
上のフォームに特定のマスター・データ・オブジェクトを表示すると、その下にあるフォームに、関連する最初のディテール・オブジェクトが表示されます。後続の各ディテール・データ・オブジェクトをスクロールするには、フォーム・ナビゲーションを使用する必要があります。

- ADFマスター表、ディテール表: マスター・オブジェクトとディテール・オブジェクトが別々の読取り専用表に表示されます。
上の表で特定のマスター・データ・オブジェクトを選択すると、その下にある表に、関連する最初のディテール・データ・オブジェクトのセットが表示されます。

デフォルトのフォームまたは表を変更する場合は、「フォーム上のUIコンポーネントおよびバインディングの変更」および「表に表示される属性の変更」を参照してください。

34.3.2 個別のコンポーネントからマスター/ディテール・フォームを作成する方法

事前作成済のマスター/ディテール・ウィジェットを使用してマスター/ディテール・フォームを作成するかわりに、マスター/ディテール関係を持つデータ・コントロール・オブジェクトから表およびフォーム・コンポーネントを別々に作成して、マスター/ディテール調整を提供するディテール・オブジェクトのイテレータ・バインディングを利用できます。別々のコンポーネントからマスター/ディテール・フォームを作成することにより、コンポーネントとそのバインディングの生成方法により柔軟性がもたらされます。

始める前に:

マスター/ディテール表およびフォームの作成で使用可能な各オプションを理解しておくと役立ちます。詳細は、「表およびフォームを使用したマスター/ディテール・オブジェクトの表示」を参照してください。

また、マスター/ディテール表およびフォームに使用可能な追加機能についても理解しておくと役立ちます。詳細は、「マスター/ディテール表、フォームおよびツリーの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法」の説明に従って、必要なマスター/ディテール階層を確立するビュー・オブジェクトとビュー・リンクのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

個々のコンポーネントを使用してマスター/ディテール・フォームを作成するには:

1. ディテール・ウィジェットは、「データ・コントロール」パネルから子コレクションをドラッグして、それを表またはフォームとしてJSFページまたはディテール・ビュー・アクティビティに対応するフラグメント上にドロップして作成します。詳細は、「「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別方法」を参照してください。

個々のコンポーネントの作成方法の詳細は、「データ・コントロールのコレクションを使用した基本的なフォームの作成」および「基本表の作成」を参照してください。

2. マスター・ウィジェットは、手順1でコレクションの親であるコレクションをドラッグして、それを表またはフォームとしてJSFページまたはマスター・ビュー・アクティビティに対応するフラグメント上にドロップして作成します。

34.3.3 マスター/ディテール表およびフォームの作成時の処理

「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップすると、JSFページへのコードの追加やページ定義ファイルに対応するエントリの追加など、様々な処理が自動的に行われます。「データ・コントロール」パネルの使用時に実行される処理と作成される内容の詳細は、「「データ・コントロール」パネルの使用時の処理」を参照してください。

34.3.3.1 マスター/ディテールJSFページで生成されるコード

事前作成済のマスター/ディテール・ウィジェット用に生成されたJSFコードは、「データ・コントロール」パネルを使用して読取り専用のフォームまたは表を作成したときに生成されるJSFコードとほぼ同じです。独自のマスター/ディテール・ウィジェットを作成する場合、事前作成済のマスター/ディテール表およびフォームに自動的に組み込まれるものと同様のコンポーネントを組み込むことを検討してください。

事前作成済のマスター/ディテール・ウィジェットの表およびフォームには、マスター・フォームまたは表にデータを移入するデータ・コントロールの名前を保持するpanelHeaderタグが含まれます。このラベルは、リソース・バンドルにバインドする文字列またはEL式を使用して、必要に応じて変更できます。

コレクション内に複数のデータ・オブジェクトがある場合、事前作成済のマスター/ディテール・ウィジェットのフォームには、レンジ・ナビゲーション用としてFirst、Previous、NextおよびLastという4つのbuttonタグがあります。これらのレンジ・ナビゲーション・ボタンを使用して、コレクション内のオブジェクトをスクロールできます。各ボタンのactionListener属性は、ナビゲーションを実行するデータ・コントロール操作にバインドされています。ボタンをクリックすると、actionListenerバインディングで使用されるexecuteプロパティによって、操作が起動します。(フォームに単一のオブジェクトが表示されている場合、レンジ・ナビゲーション・コンポーネントは表示されません。)レンジ・ナビゲーションの詳細は、「レンジ・ナビゲーションのフォームへの組入れ」を参照してください。

ヒント:

ページに「ADFマスター表、ディテール・フォーム」ウィジェットまたは「ADFマスター表、ディテール表」ウィジェットをドロップすると、ディテール・コンポーネントの親タグ(panelHeaderタグやtableタグなど)のpartialTriggers属性はマスター・コンポーネントのidに自動的に設定されます(部分トリガーの詳細は、「入力表の作成方法」を参照)。実行時に、ユーザーがマスター・コンポーネントで選択を行うと、partialTriggers属性によりディテール・コンポーネントのみが再度レンダリングされます。これは、部分ページ・レンダリングと呼ばれます。部分ページ・レンダリングが使用されるのは、ディテール・コンポーネントのみ新しいデータを表示するために再度レンダリングする必要があるためです。ユーザーがファセット内で選択のみを行う場合、表を再度レンダリングする必要はありません。

34.3.3.2 マスター/ディテール・ページ定義ファイルで定義されるバインディング・オブジェクト

次の例は、マスター/ディテール・ページ用に作成されたページ定義ファイルを示しています。このページは、Customersオブジェクトの下位のディテール・オブジェクトであるOrdersFromCustomerコレクションを、「ADFマスター・フォーム、ディテール表」としてページにドロップして作成したものです。

このexecutables要素では2つのイテレータが定義されており、1つはマスター・オブジェクトに対するもの、もう1つはディテール・オブジェクトに対するものです。実行時には、ディテール・ビュー・オブジェクト・インスタンスのデータ・モデルおよび行セット・イテレータにより、現在の行が変更されたときに、ディテール・ビュー・オブジェクトの行セットが現在のマスター行の正しい行セットになるようにリフレッシュされます。詳細は、「実行時に行われる処理: マスター/ディテール表およびフォームのADFイテレータ」を参照してください。

bindings要素は、フォームおよび表の値バインディングを定義します。フォーム内のテキスト・フィールドに値を移入する属性バインディングは、attributeValues要素内で定義されます。attributeValues要素のid属性には各データ属性の名前が含まれ、IterBinding属性はイテレータ・バインディングを参照し、マスター・オブジェクトのデータをテキスト・フィールドに表示します。

フォーム内のレンジ・ナビゲーション・ボタンは、action要素で定義されたアクション・バインディングにバインドされます。属性バインディングの場合と同様に、アクション・バインディングのIterBinding属性は、マスター・オブジェクトのイテレータ・バインディングを参照します。

ディテール・データを表示する表は、table要素で定義される表バインディング・オブジェクトにバインドされます。IterBinding属性は、ディテール・オブジェクトのイテレータ・バインディングを参照します。

ページ定義ファイルの要素および属性の詳細は、「pageNamePageDef.xml」を参照してください。

<executables>
<variableIterator id="variables"/>
<iterator Binds="Customers" RangeSize="25" DataControl="BackOfficeAppModuleDataControl" id="CustomersIterator"
ChangeEventPolicy="ppr"/>
<iterator Binds="OrdersForCustomer" RangeSize="25" DataControl="BackOfficeAppModuleDataControl"
id="OrdersForCustomerIterator" ChangeEventPolicy="ppr"/>
</executables>
<bindings>
<action IterBinding="CustomersIterator" id="First" RequiresUpdateModel="true" Action="first"/>
<action IterBinding="CustomersIterator" id="Previous" RequiresUpdateModel="true" Action="previous"/>
<action IterBinding="CustomersIterator" id="Next" RequiresUpdateModel="true" Action="next"/>
<action IterBinding="CustomersIterator" id="Last" RequiresUpdateModel="true" Action="last"/>
<attributeValues IterBinding="CustomersIterator" id="Id">
<AttrNames>
<Item Value="Id"/>
</AttrNames>
</attributeValues>
<attributeValues IterBinding="CustomersIterator" id="Name">
<AttrNames>
<Item Value="Name"/>
</AttrNames>
</attributeValues>
<attributeValues IterBinding="CustomersIterator" id="Phone">
<AttrNames>
<Item Value="Phone"/>
</AttrNames>
</attributeValues>
. . .
<tree IterBinding="OrdersForCustomerIterator" id="OrdersForCustomer">
<nodeDefinition DefName="oracle.summit.model.views.OrdVO"
Name="OrdersForCustomer0">
<AttrNames>
<Item Value="Id"/>
<Item Value="CustomerId"/>
<Item Value="DateOrdered"/>
...
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

注意:

EJBセッションBeanなど、ビジネス・サービスの他のタイプに基づくデータ・コントロールの場合、イテレータ・バインディングの処理にiterator要素のかわりにaccessorIterator要素が使用されます。

34.3.4 実行時に行われる処理: マスター/ディテール表およびフォームのADFイテレータ

実行時に、ADFイテレータは、マスター表オブジェクトのどの行をマスター/ディテール・フォームに表示するかを決定します。フォームが最初に表示されるときは、マスター表オブジェクトの1行目がフォームのマスター・セクションに強調表示されます。マスター行に関連付けられているディテール表の行は、フォームのディテール・セクションに表示されます。

「マスター/ディテール・ページ定義ファイルで定義されるバインディング・オブジェクト」で説明しているように、ADFイテレータは基礎となるrowsetIteratorオブジェクトに関連付けられています。これらのイテレータは、ページに現在表示されているデータ・オブジェクト(つまり行)がどれかを管理します。実行時には、行セット・イテレータがマスター・コンポーネントとディテール・コンポーネントに表示されるデータを管理します。

マスターおよびディテールの行セット・イテレータは、どちらも行セット・ナビゲーション・イベント(ユーザーによるレンジ・ナビゲーション・ボタンのクリックなど)をリスニングし、適切な行をUIに表示します。デフォルトのマスター/ディテール・コンポーネントの場合は、行セット・ナビゲーション・イベントは、フォーム上のコマンド・ボタン(「先頭へ」、「前へ」、「次へ」、「最後へ」)になります。

ディテール・コレクションの行セット・イテレータは、 ディテール・データとマスター・データの同期化を管理します。マスター・ビュー・オブジェクトからディテール・ビュー・オブジェクトへの基礎となるビュー・リンクにより、ディテール行セット・イテレータは、マスター・コレクションとディテール・コレクションの両方で行ナビゲーション・イベントをリスニングします。マスター・コレクションで行セット・ナビゲーション・イベントが発生すると、ディテール行セット・イテレータが自動的に実行され、現在のマスター行に関連するディテール行が戻されます。

34.3.5 個別のページにマスター/ディテール・コンポーネントを表示する方法

デフォルトのマスター/ディテール・コンポーネントでは、 マスター/ディテール・データは単一のページに表示されます。ただし、「データ・コントロール」パネルでマスター・オブジェクトとディテール・オブジェクトを使用して、バインディング・イテレータにマスター・オブジェクトとディテール・オブジェクトの同期化を管理させたまま、コレクションを別々のページ(または同じページの別のフラグメント)に表示できます。

始める前に:

マスター/ディテール表およびフォームの作成で使用可能な各オプションを理解しておくと役立ちます。詳細は、「表およびフォームを使用したマスター/ディテール・オブジェクトの表示」を参照してください。

また、マスター/ディテール表およびフォームに使用可能な追加機能についても理解しておくと役立ちます。詳細は、「マスター/ディテール表、フォームおよびツリーの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法」の説明に従って、必要なマスター/ディテール階層を確立するビュー・オブジェクトとビュー・リンクのインスタンスを含むアプリケーション・モジュールを作成します。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

マスター・オブジェクトとディテール・オブジェクトを個別のページに作成するには:

1. 「タスク・フローの作成方法」に従って、ADFタスク・フローを作成します。

ページ・フラグメントを使用して、マスター/ディテール・コンポーネントを保持する予定がある場合は、この手順の「ページ・フラグメントを使用して作成」チェック・ボックスを選択します。

2. 「タスク・フローにアクティビティを追加する方法」の説明に従い、タスク・フローに2つのビュー・アクティビティ(マスター・ビュー用に1つ、ディテール・ビュー用に1つ)を追加します。

3. タスク・フロー定義ファイルで、マスター・ビューからディテール・ビューに制御フロー・ケースを追加し、ディテール・ビューからマスター・ビューに戻る制御フロー・ケースを追加します。詳細は、「タスク・フローに制御フロー・ルールを追加する方法」を参照してください。

4. マスター/ディテール・コンポーネントを保持する場合は2つのJSFページまたは2つのJSFフラグメントを作成します。

ビュー・アクティビティのページまたはフラグメントは、タスク・フローの概要エディタのビュー・アクティビティをクリックして作成できます。

ビュー・アクティビティにマップするページまたはフラグメントがすでにある場合は、タスク・フローの概要エディタでビュー・アクティビティを選択し、「プロパティ」ウィンドウに移動して、PageプロパティでJSFページまたはフラグメントを指定して、これを行うことができます。

5. ディテール・コンポーネントは、「データ・コントロール」パネルから子コレクションをドラッグして、それを表またはフォームとしてJSFページまたはディテール・ビュー・アクティビティに対応するフラグメント上にドロップして作成します。詳細は、「「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別方法」を参照してください。

フォームと表の作成方法の詳細は、「データ・コントロールのコレクションを使用した基本的なフォームの作成」および「基本表の作成」を参照してください。

6. マスター・コンポーネントは、手順5でコレクションの親であるコレクションをドラッグして、それを表またはフォームとしてJSFページまたはマスター・ビュー・アクティビティに対応するフラグメント上にドロップして作成します。

7. コマンド・ボタンまたはリンクを各ページに追加します。

8. 各ボタンのaction属性で、他のページに移動するために使用される制御フロー・ケースを指定します。この値は対応する制御フロー・ケースのfrom-outcomeプロパティから取得できます。

たとえば、Summit ADFサンプル・アプリケーションのCustomers.jsffフラグメントには、OrdersFromCustomerコレクションから作成される表が含まれます。その表は、顧客注文のディテール・ビューとItemsFromOrderコレクションから作成される注文品目表のマスター・ビューの両方として機能し、 Orders.jsffにあります(「Order」タブに表示されます)。図34-7は、顧客のディテール・ビューとして注文表を示し、図34-8は、その表で選択される注文とその注文のディテールを示しています。OrdersFromCustomerコレクションは、Customers.jsffおよびOrders.jsffフラグメントの両方で使用されますが、マスター/ディテール調整を保持するために両方の場所で使用される必要はありません。ItemsFromOrderのイテレータ・バインディングでは、ページ・フラグメントでさえも、マスター/ディテール調整が維持されます。

図34-7 1ページ・フラグメントでのマスター・ビュー

図34-8 1 個別のページ・フラグメントでのディテール・ビュー

34.4 ツリーを使用したマスター/ディテール・オブジェクトの表示

表およびフォーム以外に、階層ツリーにもマスター/ディテール・データを表示できます。ADF Facesのtreeコンポーネントは階層データの表示に使用します。マスター・オブジェクトのバインディングによって移入される複数のルート・ノードが表示されます。ツリー内の各ルート・ノードは、ディテール・オブジェクトのバインディングによって移入されるブランチを持つことが可能で、その数に制限はありません。ツリーには複数のレベルのノードがあり、各ノードは親ノードのディテール・オブジェクトを示します。ツリー内の各ノードは、階層でのノードのレベルを示します。

treeコンポーネントには、ツリー・ノードを開閉するメカニズムが含まれていますが、フォーカス機能はありません。フォーカス機能を使用する必要がある場合は、ADF FacesのtreeTableコンポーネントの使用を検討してください(詳細は、「ツリー表を使用したマスター/ディテール・オブジェクトの表示」を参照)。デフォルトでは、ツリーの各ノードのアイコンはフォルダですが、独自のアイコンを階層内の各レベルのノードに使用できます。

図34-9に、Summit ADFサンプル・アプリケーションのCustomers.jsffフラグメントにあるツリーの例を示します。このツリーには、ルートおよびブランチの2つのノード・レベルが表示されます。ルート・ノードには、国が表示されます。ブランチ・ノードには、顧客が表示されます。

図34-9 データバインドされたADF Facesツリー

34.4.1 ツリーでのマスター/ディテール・オブジェクトの表示方法

ツリーはノードの階層で構成され、各サブノードは上位レベルのノードから分岐します。データバインドされたADF Facesのtreeコンポーネントの各ノード・レベルは、異なるデータ・コレクションによって移入されます。JDeveloperでは、「ツリー・バインディングの編集」ダイアログを使用してデータバインド・ツリーを定義します。このダイアログで、ツリー内の各ノード・レベルにデータを移入するためのルールを定義できます。階層内の各ノード・レベルに対して1つのルールが必要です。それぞれのルールは、次のノード・レベル・プロパティを定義します。

- ノード・レベルを移入するデータ・コレクション。

- そのノード・レベルで表示される、データ・コレクションからの属性。

図34-9で示すように、Summit ADFサンプル・アプリケーションで顧客ツリーの作成を有効にするには、ビュー・オブジェクトCountryVOを最初に作成して、国のリストを戻します。もう1つのビュー・オブジェクトCustomerVOも作成して、顧客を戻します。また、マスター/ディテール関係を確立するために、CountryVOからCustomerVOにビュー・リンクが作成されます。

この場合、CustomerVOがビュー・オブジェクトOrdVOへのビュー・リンクを持ち、OrdVOがItemVOへのビュー・リンクを持つため、第3レベルと第4レベルのノードも追加できます。

ツリーのブランチが再帰的な場合、自己参照型のビュー・リンクを伴う単一のビュー・オブジェクトをデータ・モデル・プロジェクトで定義する必要があります。たとえば、EmployeesViewで定義されたコレクションで、各ブランチのルート・ノードがManagerId属性で指定され、同じブランチの子ノードがManagerIdに関連する従業員(直属の部下とも呼ぶ)になります。自己参照型のビュー・リンクによって名前が付けられるリンク元とリンク先の両方のビュー・オブジェクトは、どちらもEmployeesViewとして定義されますが、わかりやすくするためにリンク先の名前がDirectReportsに変更されます。自己参照型のビュー・リンクの作成の詳細は、「エンティティ・ベースのビュー・オブジェクトに対する再帰的マスター/ディテール階層の作成方法」を参照してください。

注意:

ビジネス・サービスがADFビジネス・コンポーネントに基づいている場合、マスター・ビュー・オブジェトのビュー・リンク・アクセッサ属性にプログラム的にアクセスし、現在のノード・レベルのブランチとして表示するディテール・オブジェクトを戻すことができます。ビュー・リンク・アクセッサの詳細は、「ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法」を参照してください。

始める前に:

マスター/ディテール表およびフォームの作成で使用可能な各オプションを理解しておくと役立ちます。詳細は、「ツリーを使用したマスター/ディテール・オブジェクトの表示」を参照してください。

また、マスター/ディテール表およびフォームに使用可能な追加機能についても理解しておくと役立ちます。詳細は、「マスター/ディテール表、フォームおよびツリーの追加機能」を参照してください。

次のタスクを完了する必要があります。

- データ・モデル・プロジェクトのマスター/ディテール・ビュー・オブジェクトおよびビュー・リンクを作成し、ツリー・コンポーネントの行セット・アクセスのパフォーマンスを最適化して、マスター・ビュー・オブジェクト(および必要に応じてディテール・ビュー・オブジェクト)をアプリケーション・モジュールに追加します。最適化フラグ「行セットの保存」の設定の詳細は、「マスター/ディテール・データを表示するためのビュー・リンク・アクセッサのアクセスの最適化」を参照してください。マスター/ディテール階層を作成して、これをアプリケーション・モジュールに追加する方法の詳細は、「ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法」を参照してください。
または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

ツリーでのマスター/ディテール・オブジェクトの表示方法:

1. 「データ・コントロール」パネルからマスター・オブジェクトをドラッグし、ページ上にドロップします。これは、ツリーのルート・レベルを表すマスター・データである必要があります。

2. ポップアップ・メニューから、「ツリー」→「ADFツリー」を選択します。

図34-10に示す「ツリー・バインディングの編集」ダイアログが表示されます。バインディング・エディタを使用し、ツリーに表示する各レベルのルールを定義します。

最初にダイアログが表示されたら、ドラッグしたコレクションが「ルート・データソース」ドロップダウン・リストに表示され、対応するビュー・オブジェクトが「ツリー・レベル・ルール」リストに表示されます。これは、マスター・データ・コレクションを表します。

ヒント:

「ルート・データ・ソース」リストに使用するデータ・コレクションが見つからない場合、「追加」ボタンをクリックします。「データ・ソースの追加」ダイアログで、データ・コントロールとイテレータ名を選択して新しいデータ・ソースを作成します。次に「ルールの追加」アイコンをクリックして、「ルールの追加」を選択し、マスター・ルールを追加します。

図34-10 「ツリー・バインディングの編集」ダイアログ

3. 「ルールの追加」アイコンをクリックして、「ツリー・レベル・ルール」リストに追加するディテール・コレクションを選択します。

図34-11に示すように、マスター・データソースの下にディテール・データソースが表示されます。

図34-11 マスター/ディテール・ツリー・レベル・ルール

再帰的なマスター/ディテール階層を持つツリーを作成する場合は、データソースとセルフ・アクセッサを指定したルールを定義するだけで済みます。再帰的なツリーには、単一のコレクションに基づいてルート・ノードが表示されるとともに、そのコレクションからデータを再帰的にフェッチするセルフ・アクセッサの属性から、子ノードが表示されます。再帰的なツリーは、ツリーのブランチを定義するためのルールが1つしか必要ないため、通常のマスター/ディテール・ツリーとは異なります。再帰的なデータソースは、図34-12に示すように、データソースの後にセルフ・アクセッサ名をカッコで囲んで指定した形で表示されます。

ツリーに追加する追加ノード(または階層のさらに上位レベル)に対してこの手順を繰り返します。

図34-12 再帰的なツリー・レベル・ルール

4. 「ツリー・レベル・ルール」リストでルールのいずれかを選択します。

5. ダイアログの下部で、「属性の表示」リストに属性を移動することによって、ノードの表示に使用する属性を設定します。

6. 残りの各ルールに手順4から5を繰り返します。

7. 「OK」をクリックします。

34.4.2 ADFデータバインド・ツリーの作成時の処理

「データ・コントロール」パネルからドラッグ・アンド・ドロップを行うと、JDeveloperによって様々な処理が自動的に行われます。「データ・コントロール」パネルの使用時に実行される処理と作成される内容の詳細は、「「データ・コントロール」パネルの使用方法」を参照してください。

「データ・コントロール」パネルを使用して「データ・コントロール」ページ定義ファイルにバインディング・オブジェクトが追加され、JSFページにtreeタグも追加されます。作成されたUIコンポーネントは、そのままで十分機能するため、変更する必要はありません。

34.4.2.1 JSFページで生成されるコード

次の例は、「データ・コントロール」パネルを使用してツリーを作成したときにJSFページで生成されるコードを示しています。このサンプル・ツリーには、国と顧客の2レベルのノードが表示されます。ルート・ノードを移入するために、Countriesコレクションが使用されています。

<af:tree value="#{bindings.Countries.treeModel}"
var="node"
selectionListener="#{bindings.Countries.treeModel.makeCurrent}"
rowSelection="single" id="t1"
<f:facet name="nodeStamp">
<af:outputText value="#{node}" id="ot1"/>
</f:facet>
</af:tree>

デフォルトで、フォームの中にaf:treeタグが作成されます。treeタグのvalue属性には、treeコンポーネントをページ定義ファイルのCountriesツリー・バインディング・オブジェクトにバインドするEL式が含まれます。バインディング式のtreeModelプロパティは、基礎となるデータ・モデルに基づいてtree階層の表示方法を定義する、ADFクラスを参照します。var属性は、現在のノードへのアクセスを提供します。

f:facetタグに含まれるnodeStampファセットは、各ノードのデータを表示するために使用されます。treeでは、ノードごとにコンポーネントを持つかわりに、ADF Facesの表コンポーネントに対して行がレンダリングされるのと同様の方法で、nodeStampファセットが繰返しレンダリングされます。

ADF Facesのtreeコンポーネントは、oracle.adf.view.faces.model.PathSetクラスのインスタンスを使用して、開いた状態のノードを表示します。このインスタンスは、コンポーネントのtreeState属性として格納されます。このインスタンスを使用して、階層での要素の開閉状態をプログラム的に管理できます。PathSetインスタンスに含まれるすべての要素は、開いた状態とみなされます。その他のすべての要素は閉じた状態です。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のプログラムを使用したノードの開閉に関する必知事項に関する項を参照してください。

34.4.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

次の例は、Summit ADFサンプル・アプリケーションのCountries ADFデータバインド・ツリーに関するページ定義ファイルで定義されるバインディング・オブジェクトを示しています。

<executables>
...
<iterator Binds="Countries" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="CountriesIterator"/>
</executables>
<bindings>
...
<tree IterBinding="CountriesIterator" id="Countries">
<nodeDefinition DefName="oracle.summit.model.views.CountryVO"
Name="Countries0">
<AttrNames>
<Item Value="Country"/>
</AttrNames>
<Accessors>
<Item Value="CustomerVO"/>
</Accessors>
</nodeDefinition>
<nodeDefinition DefName="oracle.summit.model.views.CustomerVO"
Name="Countries1"
TargetIterator="${bindings.CustomersIterator}">
<AttrNames>
<Item Value="Id"/>
<Item Value="Name"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

ページ定義ファイルには、ツリー・バインディング・エディタで定義された規則情報が含まれます。executables要素では、2つのノード・レベルがツリーに表示されても、1つのイテレータ・バインディング・オブジェクトしか要求されません。このイテレータは、ツリーのルート・ノードを移入するマスター・コレクションを反復処理します。このノードで指定したアクセッサは、各ブランチ・ノードのディテール・データを戻します。

tree要素は、ツリーに表示されるすべての属性の値バインディングです。tree要素のIterBinding属性は、ツリーにデータを移入するイテレータ・バインディングを参照します。tree要素内のAttrNames要素は、マスター・コレクション内のすべての属性のバインディング・オブジェクトを定義します。ただし、ツリーに表示するように選択する属性は、nodeDefinition要素内のAttrNames要素で定義されます。

nodeDefinition要素は、ツリーのノードにデータを移入するためのルールを定義します。ノードごとに1つのnodeDefinition要素があり、各要素には次の属性およびサブ要素が含まれます。

- DefName: ノードの移入に使用されるデータ・コレクションの完全修飾名が含まれる属性

- id: ノードの名前を定義する属性。

- AttrNames: 実行時にノードに表示される属性を定義するサブ要素。

- Accessors: ツリーの次のブランチを戻すアクセッサ属性を定義するサブ要素。

ページ定義ファイルでのnodeDefintion要素の順序によって、ツリーでのノードの順序またはレベルが決まります。最初のnodeDefinition要素は、ルート・ノードを定義します。後続の各nodeDefinition要素は、先行するノードのサブノードを定義します。

ページ定義ファイルの要素および属性の詳細は、「pageNamePageDef.xml」を参照してください。

34.4.3 実行時に行われる処理: ADFデータバインド・ツリーの表示方法

treeコンポーネントは、org.apache.myfaces.trinidad.model.TreeModelを使用してデータにアクセスします。このクラスは、ADF Facesのtableコンポーネントがデータへのアクセスに使用するCollectionModelを拡張します。TreeModelクラスの詳細は、ADF Faces Javadocを参照してください。

treeを含むページが表示されると、ツリーのイテレータ・バインディングによって、ルート・ノードにデータが移入されます。ユーザーがノードを開いてブランチを表示したり、閉じて非表示にすると、DisclosureEventイベントが送信されます。このイベントのisExpandedメソッドは、ユーザーによるノードの操作(開いているか、閉じているか)を判断します。DisclosureEventイベントには、リスナーが関連付けられています。

treeのDisclosureListener属性は、ページ定義ファイルで定義済のノード・ルールで指定されたアクセッサ属性にバインドされます。このアクセッサ属性は、DisclosureEventイベントに応じて起動します。つまり、ユーザーがノードを開くたびに、アクセッサ属性によってブランチ・ノードにデータが移入されます。

34.4.4 ページの他の部分をツリーの選択と同期する方法

ディテール・ビューをマスター・ビューと同期させるほか、ページの他の部分をツリーの選択と同期させることができます。各ノード定義(ルール)に対して、オプションのTargetIteratorプロパティを指定して、それを現在のバインディング・コンテナのイテレータ・バインディングのEL式に設定できます。その式は、ユーザーがツリーで行を選択すると、実行時に評価されます。イテレータ・バインディングのビュー行キーの属性は、ツリー用にnodeDefinitionタイプの行が取得されるイテレータのビュー行キーと(順序、数およびデータ型が)一致します。実行時に、ツリー・コントロールはselectionChangedイベントを受け取ると、ツリーのレベルごとにキーのリストを渡します。これらのキーは選択されたノードを一意に識別します。

注意:

ページ定義エディタでノード・バインディングを開くことで、ページのnodeDefinition要素を表示できます。これらは、ツリー・バインディング・ダイアログで構成できる同じツリー・バインディング・ルールです。

ツリー・バインディングは、ツリーの最上位から始まります。Currently Selected Tree Node Keysリストにキーが存在するツリー・レベルごとに、そのnodeDefinitionについて構成されているTargetIteratorプロパティがある場合、ツリー・バインディングは選択されたターゲット・イテレータに対してsetCurrentRowWithKey()操作を実行します。Currently Selected Tree Node Keysリストの適切なレベルからキーを使用します。

たとえば、Summit ADFサンプル・アプリケーションには、第1ノードで顧客を表示し、第2ノードで顧客を表示するツリーが含まれています。ユーザーがツリーで顧客を選択すると、図34-13で示すように、顧客情報を表示するフォームがページの「Summit Customer Management」パネルに表示されます。この機能は、Countriesデータ・コントロール・オブジェクト、Customersオブジェクトから作成されるフォームおよびOrdersFromCustomerオブジェクトから作成されるディテール表(「データ・コントロール」パネルのCustomersの下にネストされます)から作成されたツリーで構成されます。

図34-13 ツリーの選択と同期されるフォーム

始める前に:

ツリーの作成で使用可能な各オプションを理解しておくと役立ちます。詳細は、「ツリーを使用したマスター/ディテール・オブジェクトの表示」を参照してください。

また、マスター/ディテール表およびフォームに使用可能な追加機能についても理解しておくと役立ちます。詳細は、「マスター/ディテール表、フォームおよびツリーの追加機能」を参照してください。

次のタスクを完了する必要があります。

- データ・モデル・プロジェクトのマスター/ディテール・ビュー・オブジェクトおよびビュー・リンクを作成し、ツリー・コンポーネントの行セット・アクセスのパフォーマンスを最適化して、マスター・ビュー・オブジェクト(および必要に応じてディテール・ビュー・オブジェクト)をアプリケーション・モジュールに追加します。最適化フラグ「行セットの保存」の設定の詳細は、「マスター/ディテール・データを表示するためのビュー・リンク・アクセッサのアクセスの最適化」を参照してください。マスター/ディテール階層を作成して、これをアプリケーション・モジュールに追加する方法の詳細は、「ビュー・オブジェクトのみに基づくマスター/ディテール階層の作成方法」を参照してください。
または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

ページの他の部分をツリーの選択と同期するには:

1. 「データ・コントロール」パネルから、レコードがツリーのユーザー選択に基づいて表示されるディテール・コレクションをドラッグして、フォームまたは別のデータバインドされたコンポーネントとしてそれをドロップします。

2. 「データ・コントロール」パネルから、ドロップした親ディテール・コレクションをドラッグして、「作成」→「ツリー」→「ADFツリー」(または「ADFツリー表」)の順に選択します。

3. 「ツリー・バインディングの編集」ダイアログで、「ツリーでのマスター/ディテール・オブジェクトの表示方法」で説明するように、ツリー階層のレベルのすべてに対してツリー・バインディング・ルールを構成し、ダイアログを開いたままにします。

4. 手順1で使用される同じコレクションに対応するディテール・ツリーレベル・ルールを選択します。

5. 「ターゲット・データソース」ノードを開いて、「ELピッカー」ボタンをクリックします。

6. 「変数」ダイアログで、「ADFバインディング」、「バインディング」の順に開き、手順1で作成したコンポーネントのイテレータ・バインディングを選択します。

「式」テキスト・エリアに式が表示されます。式は${bindings.CustomersIterator}のようになります。この式は、ユーザーがディテール・ノードをクリックするときに、ターゲット・イテレータを設定するために使用されます。

7. 「OK」をクリックして「変数」ダイアログを終了し、「OK」をクリックして「ツリー・バインディングの編集」ダイアログを終了します。

34.5 ツリー表を使用したマスター/ディテール・オブジェクトの表示

ADF FacesのtreeTableコンポーネントを使用すると、マスター/ディテール・コレクションの階層を表に表示できます。treeコンポーネントのかわりにtreeTableコンポーネントを使用することの利点は、treeTableコンポーネントがツリー内の特定のノードにフォーカスして表示するメカニズムを使用できることです。

たとえば、各ルート・ノードが個々の国を表す国および顧客のノード・レベルを表示するツリー表を作成できます。各ルート・ノードが分岐して、その国の顧客が表示されます。ツリーの場合と同様、このようなツリー表を作成するには、階層内のコレクション間でマスター/ディテール関係を持つ必要があります。

データバインドされたADF FacesのtreeTableには、一度に1つのルート・ノードしか表示されませんが、様々なルート・ノードをスクロールするためのナビゲーションが用意されています。各ルート・ノードには、任意の数のブランチ・ノードを表示できます。各ノードは表の個別の行として表示され、各行の左端の列にはフォーカス・メカニズムが付属します。

「プロパティ」ウィンドウで、次のtreeTableコンポーネント・プロパティを編集できます。

- レンジ・ナビゲーション: ユーザーは、「前へ」および「次へ」のナビゲーション・ボタンをクリックして、ルート・ノードをスクロールできます。

- リスト・ナビゲーション: 「前へ」ボタンと「次へ」ボタンの間にあるリスト・ナビゲーションにより、ユーザーは、選択リストを使用してデータ・コレクション内の特定のルート・ノードに移動できます。

- ノードを開閉するためのメカニズム: ユーザーは、それぞれのノードを個別に開閉するか、「すべて開く」または「すべて閉じる」のコマンド・リンクを使用できます。デフォルトでは、個々のノードを開閉するためのアイコンは、プラス記号またはマイナス記号が表示された矢印です。カスタム・アイコンを選択して使用することもできます。

- フォーカス・メカニズム: ユーザーがノードの横(左端の列)のフォーカス・アイコンをクリックすると、ページが再表示され、ノードとそのブランチのみが表示されます。親ノードに戻るためのナビゲーション・リンクも表示されます。

34.5.1 ツリー表でのマスター/ディテール・オブジェクトの表示方法

ADF Facesデータ・バインド・ツリー表の作成手順は、ADF Facesデータ・バインド・ツリーの作成手順とほぼ同じですが、データ・コレクションをドロップする際に、ADFツリーとしてではなくADFツリー表としてドロップします。詳細は、「ツリーでのマスター/ディテール・オブジェクトの表示方法」を参照してください。

34.5.2 データバインド・ツリー表の作成時の処理

「データ・コントロール」パネルからドラッグ・アンド・ドロップを行うと、JDeveloperによって様々な処理が自動的に行われます。「データ・コントロール」パネルの使用時に実行される処理と作成される内容の詳細は、「「データ・コントロール」パネルの使用方法」を参照してください。

「データ・コントロール」パネルを使用してデータバインド・ツリー表を作成すると、JDeveloperによって、ページ定義ファイルにバインディング・オブジェクトが追加され、JSFページにtreeTableタグが追加されます。作成されたUIコンポーネントは、そのままで十分機能するため、変更する必要はありません。

34.5.2.1 JSFページで生成されるコード

次の例は、「データ・コントロール」パネルを使用してツリー表を作成したときにJSFページで生成されるコードを示しています。このサンプル・ツリーには、国と顧客の2レベルのノードが表示されます。

デフォルトでは、フォームの中にtreeTableタグが作成されます。treeTableタグのvalue属性には、treeコンポーネントを、データ移入を行うバインディング・オブジェクトにバインドするEL式が含まれます。treeModelプロパティは、基礎となるデータ・モデルに基づいてツリー階層の表示方法を定義する、ADFクラスを参照します。var属性は、現在のノードへのアクセスを提供します。

<af:treeTable value="#{bindings.Countries.treeModel}" var="node"
selectionListener="#{bindings.Countries.treeModel.makeCurrent}"
rowSelection="single"
id="tt1">
<f:facet name="nodeStamp">
<af:column id="c1">
<af:outputText value="#{node}" id="ot1"/>
</af:column>
</f:facet>
<f:facet name="pathStamp">
<af:outputText value="#{node}" id="ot2"/>
</f:facet>
</af:treeTable>

各ノードのデータの表示には、nodeStampファセットが使用されます。ノードごとにコンポーネントを持つかわりに、ツリーでは、ADF Faces tableコンポーネントに対して行がレンダリングされるのと同様の方法で、nodeStampファセットが繰返しレンダリングされます。pathStampファセットは、ユーザーがディテール・ノードにフォーカスした後で親ノードに戻れるように、表の上に列およびパスのリンクをレンダリングします。

34.5.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

ツリー表に対してページ定義ファイルで作成されるバインディング・オブジェクトは、ツリーに対して作成されるものとまったく同じです。詳細は、「ページ定義ファイルで定義されるバインディング・オブジェクト」を参照してください。

34.5.3 実行時に行われる処理: ツリー表のイベント

treeコンポーネントは、oracle.adf.view.faces.model.TreeModelを使用してデータにアクセスします。このクラスは、ADF Facesのtableコンポーネントがデータへのアクセスに使用するCollectionModelを拡張します。TreeModelクラスの詳細は、ADF Faces Javadocを参照してください。

ツリー表を含むページが表示されると、treeTableコンポーネントのイテレータ・バインディングは、ルート・ノードに値を移入し、行ナビゲーション・イベント(ユーザーによる「次へ」ボタンまたは「前へ」ボタンのクリック、もしくはレンジ・ナビゲータからの行の選択)をリスニングします。ユーザーが行ナビゲーション・イベントを開始すると、イテレータによって適切な行が表示されます。

ユーザーがコンポーネントのフォーカス・アイコンをクリックして表示のフォーカスを変更すると、treeTableコンポーネントによってフォーカス・イベント(FocusEvent)が生成されます。フォーカス変更後のノードが現在のノードになった後で、イベントが配信されます。その後、treeTableコンポーネントによってfocusPathプロパティが適切に変更されます。ツリー上のFocusListener属性は、マネージドBeanのメソッドにバインドできます。これにより、このメソッドはフォーカス・イベントに応じて起動されます。

ユーザーがノードを開閉するたびに、公開イベント(DisclosureEvent)が送信されます。この公開イベントのisExpandedメソッドは、ユーザーの操作に基づいてノードを開くか閉じるかを判断します。公開イベントには、リスナーDisclosureListenerが関連付けられます。ツリー表上のDisclosureListener属性は、ページ定義ファイルで定義済のノード規則で指定されたアクセッサ属性にバインドされます。このアクセッサ属性は、公開イベント(ユーザーがノードを開くなど)に応じて起動し、そのノードを移入するコレクションを戻します。

treeTableコンポーネントには、「すべて開く」リンクおよび「すべて閉じる」リンクも表示されます。ユーザーがどちらかのリンクをクリックすると、treeTableによってDisclosureAllEventイベントが送信されます。このイベントのisExpandAllメソッドは、ユーザーの操作に基づいてすべてのノードを開くか閉じるかを判断します。その後、現在フォーカスしているルート・ノードの子ノードが、開くか閉じます。大規模なツリーの場合は、「すべて開く」コマンドを使用しても、直下の子より下にあるノードは開きません。ADF FacesのtreeTableコンポーネントでは、oracle.adf.view.faces.model.PathSetクラスのインスタンスを使用して、開いたノードが判別されます。このインスタンスは、コンポーネントのtreeState属性として格納されます。このインスタンスを使用して、階層でのノードの開閉状態をプログラム的に管理できます。PathSetインスタンスに含まれるすべてのノードは、開いているとみなされます。その他のすべてのノードは閉じた状態になります。このクラスでは、addAll()やremoveAll()のような操作もサポートされます。

ADF FacesのtreeTableコンポーネントの詳細は、ADF Faces Javadocのoracle.adf.view.faces.component.core.data.CoreTreeTableクラスを参照してください。

34.6 リスト・ビューを使用したマスター/ディテール・オブジェクトの表示

ADF FacesのlistViewコンポーネントを使用すると、マスター/ディテール・コレクションの階層を単純なツリー表に表示できます。各オブジェクトの属性は、グループまたは単一行および単一列内のグリッドに表示されます。

たとえば、図34-14に示すように、注文を表示して、それらを顧客別にグループ化するlistViewを作成できます。

図34-14 listViewコンポーネントがあるマスター/ディテール

データバインドされたリスト・ビューの使用の詳細は、「コレクションのリスト・ビューの作成」を参照してください。

34.6.1 リスト・ビューでのマスター/ディテール・オブジェクトの表示方法

「リスト・ビューの作成」ウィザードを使用して、リストを作成します。ウィザードでは、panelGroupLayoutまたはpanelGridLayoutコンポーネントを選択して、リスト・アイテムのコンポーネントを配置できます。

始める前に:

マスター/ディテール・リスト・ビューの作成で使用可能な各オプションを理解しておくと役立つことがあります。詳細は、「リスト・ビューを使用したマスター/ディテール・オブジェクトの表示」を参照してください。

また、マスター/ディテール表およびフォームに使用可能な追加機能についても理解しておくと役立ちます。詳細は、「マスター/ディテール表、フォームおよびツリーの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 必要なマスター/ディテール階層を確立するビュー・オブジェクトとビュー・リンクのインスタンスを含むアプリケーション・モジュールを作成します(「アプリケーション・モジュールの作成と変更」を参照)。または、別のタイプのビジネス・サービスを使用している場合は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のデータ・コントロールを使用したビジネス・サービスの公開に関する項の説明に従って、そのビジネス・サービスのデータ・コントロールを作成します。

- 「Webページの作成」の説明に従って、JSFページを作成します。

リスト・ビューを作成する手順:

1. 「「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別方法」の説明に従って、「データ・コントロール」パネルでディテール・オブジェクトを特定します。

2. 「データ・コントロール」パネルから、詳細コレクションをページにドラッグし、「表/リスト・ビュー」→「ADFリスト・ビュー」を選択します。

3. 「リスト・ビューの作成」ウィザードの最初のページで、レイアウト・コンポーネントを選択し、親コレクションを使用してヘッダーを含めるを選択します。

4. ウィザードの最初のページで「パネル・グリッド・レイアウト」オプションを選択した場合は、ウィザードの次の2ページを使用して、グリッド・セルのサイズと配置を整理します。

これらのウィザード・ページの使用の詳細は、[F1]キーを押すか、「ヘルプ」をクリックします。

5. 「リスト・アイテム・データ」ページで、バインディングを設定し、対応するコンポーネントでfor eachを使用するように設定することにより、詳細データについて表示するフィールドを決定します。

6. 同じページで、「グループ・ヘッダー・データ」タブをクリックし、マスター・データのバインディングとコンポーネントを設定します。

7. 「終了」をクリックします。

8. 「プロパティ」ウィンドウを使用して、レイアウト・コンポーネントをさらに構成します。

panelGridLayoutコンポーネントの使用の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のグリッドでのコンテンツの配置に関する項を参照してください。panelGroupLayoutコンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の関連アイテムのグループ化に関する項を参照してください。

34.6.2 マスター/ディテール・リスト・ビューの作成時の処理

ウィザードを使用してグループ・ヘッダー付きのlistViewコンポーネントを作成する場合、JDeveloperでは、listView、listItemおよびレイアウト・コンポーネントが作成および構成されます。listViewには、詳細アイテムのlistItemと、グループ・ヘッダー・スタンプのfacetが含まれます。グループ・ヘッダー・スタンプには、マスター・アイテムのlistItemが含まれます。

バインディングは、表の場合と同じです。listViewコンポーネントは、「データ・コントロール」パネルから削除されたコレクションの親にバインドされています。このコンポーネントのvar属性の値は、表の場合と同じ方法で、データにアクセスするためにoutputFormattedコンポーネントによって使用されます。コレクションのページ定義コードとJSPコードの詳細は、「表の作成時の処理」を参照してください。

次の例は、図34-14に示した単純な表のページ・コードを示しています。

<af:form id="f1">
<af:panelGridLayout id="pgl1">
<af:gridRow height="100%" id="gr1">
<af:gridCell width="100%" halign="stretch" valign="stretch" id="gc1">
<!-- Content -->
<af:listView value="#{bindings.Customers.treeModel}" var="item"
emptyText="#{bindings.Customers.viewable ? 'No data to
display.' : 'Access Denied.'}"
fetchSize="#{bindings.Customers.rangeSize}" id="lv1">
<af:listItem id="li1">
<af:panelGroupLayout layout="horizontal" id="pgl2">
<f:facet name="separator">
<af:spacer width="10" id="s1"/>
</f:facet>
<af:outputFormatted
value="#{item.bindings.DateOrdered.inputValue}" id="of1">
<af:convertDateTime
pattern="#{bindings.Customers.hints.DateOrdered.format}"/>
</af:outputFormatted>
<af:outputFormatted value="#{item.bindings.Total.inputValue}"
id="of2">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.Customers.hints.Total.format}"/>
</af:outputFormatted>
</af:panelGroupLayout>
</af:listItem>
<f:facet name="groupHeaderStamp">
<af:listItem id="li2" inlineStyle="font-size:medium;">
<af:panelGroupLayout layout="horizontal" id="pgl3">
<f:facet name="separator">
<af:spacer width="10" id="s2"/>
</f:facet>
<af:outputFormatted value="#{item.bindings.Name.inputValue}"
id="of3"/>
</af:panelGroupLayout>
</af:listItem>
</f:facet>
</af:listView>
</af:gridCell>
</af:gridRow>
</af:panelGridLayout>
</af:form>

34.7 ツリーおよびツリー表での選択イベントについて

アプリケーションでなんらかの処理を行うために、ツリーまたはツリー表で選択されているノードを判別する必要が生じることがあります。たとえば、アプリケーションで、ユーザーによって選択される製品カテゴリ・ノードに一致する製品を決定するための処理が必要になる場合があります。

ユーザーがツリーのノード(または表の行)を選択するたびに、コンポーネントは選択イベントを起動します。selectionEventイベントは、選択解除された行と選択された行をレポートします。現在の選択内容、つまり選択済の行は、RowKeySetオブジェクトによって管理され、このオブジェクトは、行の関連キーをキー・セットに追加、またはキーセットから削除することで、現在選択されているすべてのノードを追跡します。ユーザーが新しいノードを選択したときに、ツリーまたは表が単一選択用に構成されている場合、それまで選択されていたキーは破棄され、新たに選択されたキーが追加されます。ツリーまたは表が複数選択用に構成されている場合は、新たに選択されたキーがセットに追加されます。それまで選択されていたキーを破棄するかどうかは、ノードの選択方法によって決まります。たとえば、ユーザーが[Ctrl]キーを押した場合、新たに選択されたノードは現在のセットに追加されます。

選択イベントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の表の選択された行でのアクションの実行に関する必知事項に関する項を参照してください。

注意:

選択したノードおよびページ上の他のUIコンポーネント間の行の現在位置を同期させる必要がある場合、各ノード定義に対してTargetIteratorプロパティを使用して宣言的に実行できます。詳細は、「ページの他の部分をツリーの選択と同期する方法」を参照してください。

ツリーまたは表内で選択項目を変更すると、ページ内のリージョン間の通信を実行するコンテキスト・イベントもトリガーされます。詳細は、「コンテキスト・イベントの使用方法」を参照してください。

35 データバインドされた選択リストおよびシャトルの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータから、リスト・コンポーネントとシャトル・コンポーネントを作成する方法について説明します。これらのコンポーネントの作成には、ADFデータ・バインディングとADF Facesコンポーネントを使用します。ここでは、問合せを使用して値リスト(LOV)コンポーネントを作成し、選択リストにデータを移入する方法を説明します。また、モデルドリブン・リスト、固定値リストまたは動的に生成されたリストを使用して、標準選択コンポーネントを作成する方法を説明します。さらに、ユーザーがコレクション内のオブジェクトのリストを介して操作できるようにするために、ナビゲーション・リストのバインディングを追加する方法も説明します。また、シャトル・コンポーネントを使用して、ユーザーが2つのリストの間ですばやくアイテムを移動できるようにする方法も説明します。

この章の内容は次のとおりです。

- 選択リストおよびシャトルについて

- 値リスト(LOV)のコンポーネントの作成

- 選択リストの作成

- ナビゲーション・リスト・バインディングを持つリストの作成

- データバインド・シャトルの作成

35.1 選択リストおよびシャトルについて

選択リスト・コンポーネントにより、入力値として使用される選択項目のリストが表示されます。この選択リストは、モデルドリブンのリスト、固定リストから取得されるリスト、または実行時に動的に作成されるリストのいずれかです。選択リストのコンポーネントは、リスト、ラジオ・ボタン、チェック・ボックスおよびリスト・ボックスとしてレンダリングできます。一部の選択タイプは、単一選択(1つ選択)または複数選択(2つ以上選択)のどちらにも設定できます。

選択リストおよびシャトルは、標準的なJSFリスト・コンポーネントと同様に機能します。ただし、ADF Facesのリスト・コンポーネントには追加の機能(ラベルとメッセージの表示、自動フォーム送信、部分ページ・レンダリングのサポートなど)が備わっています。リストを提示することにより、ユーザーには使用可能な選択項目が容易にわかるため、すぐに選択を実行できます。また、リストから選択することにより、起こり得る入力エラーを防ぐこともできます。

値リスト(LOV)コンポーネントはUIコンポーネントで、これによりユーザーは問合せにより生成されたリストから値を選択して入力できます。LOVは、通常、検索機能を備えたモーダル・ポップアップ・ダイアログ内に表示されます。たとえば、af:inputListOfValuesおよびaf:inputComboboxListOfValuesコンポーネントは、LOVモーダル・ダイアログ内の検索フィールドや複数の表の列に基づいた問合せなど、選択リストでは使用できない追加機能を提供します。詳細は、「ポップアップ値リストの作成方法」および『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

値リスト・コンポーネントでは、問合せコンポーネントを使用してポップアップ検索パネルと結果表を作成することにより、より複雑な検索および入力機能を実現しています。この問合せコンポーネントには、追加機能として、自動提案、スマート・リスト・フィルタリングおよびカスタム・ファセットなどの機能も備わっています。

ユーザーがナビゲーション・リストから項目を選択すると、リストにバインドされた対応するコンポーネントでも、選択に応じて値が変更されます。たとえば、ユーザーがショッピング・リストから商品を選択すると、商品リストにバインドされている表が更新され、選択した商品の詳細が表示されます。

ユーザーはシャトルを使用して、利用可能なリストにある利用可能なアイテムと、選択されたリストにある選択されたアイテムを簡単に確認し、これらのアイテムを2つのリスト間ですばやくやりとりすることができます。

シャトルは、利用可能なリストからアイテムを選択すると同時に、選択したアイテムを確認する視覚的な方法を提供します。ADF Facesに用意されているselectManyShuttleコンポーネントとselectOrderShuttleコンポーネントを使用すると、選択したリストの並替えを実行できます。どちらのコンポーネントも、マネージドBeanにコードを追加してリストに移入することによって実装できます。

35.1.1 選択リストとシャトルのユースケースと例

リストが比較的小さく、単一値選択を入力に使用する状況では、selectOneChoiceなどの選択リスト・コンポーネントを使用できます。たとえば、製品の色をリストから選択したり、使用するクレジット・カードの種類を選択する場合にselectOneChoiceを使用できます。

より大きなリストと、さらに複雑なフィルタリング機能を使用する場合は、af:inputListOfValuesまたはaf:inputComboboxListOfValuesコンポーネントを使用します。これらのコンポーネントでは、問合せコンポーネントを使用してトランザクション検索を実行することにより、リストに移入します。たとえば、af:inputComboboxListOfValuesを使用して、アドレス入力ページの国名リストから選択できます。

ユーザーがアイテム・リストをアセンブルし、アイテムの選択および選択解除をできるようにするには、selectShuttleコンポーネントを使用します。アイテム数が多いものの表示できないほどではない場合に、シャトル・コンポーネントを使用します。ユーザーは、選択内容を確認したり、最終選択に落ち着くまでアイテムの選択と解除を繰り返すことができます。たとえば、特定の自動車に選択できるオプションについての使用可能リストがあると、ユーザーは希望するオプションを選択済リストに移動できるようになります。

35.1.2 選択リストとシャトルの追加機能

ADFモデル・レイヤーを構成または使用する前に、他のADF機能を理解しておくと役立つ場合があります。また、モデル・レイヤーの構成によって可能になることについても、確認しておくことをお薦めします。次に、関連する他の機能へのリンクを示します。

- 検索フォームとaf:queryコンポーネントとともにLOVコンポーネントを使用する方法の詳細は、「値リスト(LOV)入力フィールド」を参照してください。

- LOVは、独立したデータ・コントロールを使用するタスク・フローで使用できます。共有のデータ・コントロールおよび独立したデータ・コントロールの詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

- LOVは、名前付きビュー基準に関連付けられています。ビュー基準の設定の詳細は、「名前付きビュー基準を宣言的に作成する方法」を参照してください。

- LOVコンポーネントはaf:queryコンポーネントを使用して選択リストに移入します。af:queryコンポーネントの詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

35.2 値リスト(LOV)のコンポーネントの作成

値リスト(LOV)コンポーネントは、問合せにより生成されたリストからユーザーが値を選択して入力できる、入力コンポーネントです。ADF Facesには、af:inputListOfValuesおよびaf:inputComboboxListOfValuesコンポーネントが用意されています。フル機能のLOVコンポーネントを作成する場合は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」で説明するように、ビュー・オブジェクトにLOVを定義する必要があります。

検索フォームの一部に依存LOVを使用する場合は、必ず、af:queryコンポーネントとともに使用してください。検索フォームでのLOVコンポーネントの使用の詳細は、「値リスト(LOV)入力フィールド」を参照してください。

図35-1に示すように、af:inputListOfValuesコンポーネントには、検索基準フィールドの横に検索アイコンがあります。

図35-1 inputListOfValuesとして定義された検索基準入力フィールド

図35-2のState属性で示すように、af:inputComboboxListOfValuesコンポーネントではフィールドの横にドロップダウン・アイコンが表示されます。

図35-2 inputComboboxListOfValuesとして定義された検索基準入力フィールド

af:inputComboboxListOfValuesの場合、ドロップダウン・アイコンをクリックすると、図35-3に示すように、LOVドロップダウン・リストと「詳細」または「検索」リンクが表示されます。「検索」リンクは、LOV検索および選択ポップアップ・ダイアログに検索を絞込むための検索パネルが含まれている場合に表示されます。「詳細」リンクは、ポップアップ・ダイアログに値リストの表のみが含まれている場合、またはスマート・リストが使用されている場合に表示されます。

図35-3 inputComboboxListOfValuesの「検索」リンクがあるLOVドロップダウン・リスト

ユーザーは、ドロップダウン・リスト内の任意の項目を選択し、入力フィールドに移入できます。このドロップダウン・リストには、フィルタされた値リスト、および必要に応じて、最後に使用されたアイテムのリストが含まれます。このドロップダウン・リストに含まれる各属性の幅は、ビュー・オブジェクト定義で、その属性に対するDisplayWidth UIヒントを使用して設定します。ドロップダウン・リストの幅は、このリストに含まれる属性すべての幅の合計になります。

ユーザーは、フィールドに値を入力することもできます。ユーザーが入力したデータのデータ型とnputComboboxListOfValuesに定義されているデータ型が異なる場合は、変換エラーがスローされます。たとえば、NUMBERデータ型のinputComboboxListOfValuesに、ユーザーが英数文字列を入力すると、変換エラーが発生します。

「検索および選択」ダイアログでは、searchContentファセットを使用して、レンダリングされるカスタム・コンテンツを作成できます。入力テキスト、tablesおよびtreesなどのコンポーネントを追加して、カスタム・コンテンツを表示できます。returnPopupDataValue属性を定義し、returnPopupListenerを実装する必要があります。カスタム・ポップアップにオートコンプリート機能を追加する場合は、launchPopupEvent.setLaunchPopup(false)をLaunchPopupListener()コードに追加してポップアップを無効にできます。ただし、「検索」リンクをクリックすると、それでもなお「検索および選択」ダイアログが起動します。カスタム・コンテンツの追加方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「値リスト・コンポーネント」を参照してください。

resultsTableファセットは、「検索および選択」ダイアログの結果表が空のときに、カスタム・メッセージを表示するために使用します。

このコンポーネントのreadOnly属性がtrueに設定されている場合、入力フィールドはレンダリングされず、値の変更はできません。デフォルトでは、readOnly属性はfalseに設定されています。これにより、editMode属性も有効化され、ユーザーはリストから値の選択のみを許可されているか(editModeにselectを設定)、入力フィールドに値を入力することもできるのか(editModeにinputを設定)が決定されます。

また、ユーザーが値の一部を入力したときに、選択可能な推奨項目のリストを表示するように、LOVコンポーネントを設定することもできます。たとえば、ユーザーがCAと入力したときに、CAと部分的に一致する推奨リストが、推奨項目リストとして表示されます。ユーザーはこのリストから、入力フィールドに入力する項目を選択できます。一致するものがない場合は、「結果が見つかりません。」メッセージが表示されます。「コンポーネント」ウィンドウからLOVにaf:autoSuggestBehaviorタグを追加してから、ADFモデルで実装したsuggestedItemsメソッドにselectedItem属性を設定します。

自動提案動作は、リクエスト値の適用フェーズ中に行われることに注意してください。immediateプロパティがtrueに設定されていると、これと同じフェーズで検証が実行されます。検証エラーが発生すると、提案リストは表示されなくなります。自動提案動作を追加する場合は、immediateにtrueを設定しないでください。

LOV属性が一意でなく、同じ値のエントリが複数ある場合、自動提案ではリストの値が1つのみ表示されます。自動提案選択リストにすべての重複値を表示するには、一意の外部キーを持つ属性をLOV属性として選択する必要があります。inputListOfValuesまたはinputComboboxListOfValuesコンポーネントの内部にf:converter bindingタグを追加することで、より読みやすい属性をLOV定義の表示属性として選択できます。表示属性値は、入力フィールドおよび自動提案リストに表示されます。

f:converter binding = "#{bindings.LOV_ATTR.converter}"

たとえば、研究部門に部門番号の異なる複数のエントリがあり、DeptName属性をLOVとして定義した場合、自動提案リストには研究の部門エントリが1つのみ表示されます。かわりに、Deptnoは一意の外部キーであるため、DeptnoをLOV属性として定義できます。自動提案には、研究部門のすべてのエントリがリストされます。ただし、LOV表示を読みやすくするには、次の例に示すように、DeptNameを表示属性として定義し、f:converter bindingタグを使用して、レンダリングされる選択フィールドにDeptNameをDeptnoのかわりに表示します。

<af:inputComboboxListOfValues id="deptnoId"
popupTitle="Search and Select:
#{bindings.Deptno.hints.label}"
value="#{bindings.Deptno.inputValue}"
label="#{bindings.Deptno.hints.label}"
model="#{bindings.Deptno.listOfValuesModel}"
required="#{bindings.Deptno.hints.mandatory}"
columns="#{bindings.Deptno.hints.displayWidth}"
shortDesc="#{bindings.Deptno.hints.tooltip}">
<f:validator binding="#{bindings.Deptno.validator}"/>
<f:converter binding="#{bindings.Deptno.converter}"/>
<af:autoSuggestBehavior suggestItems="#{bindings.Deptno.suggestItems}"/>
</af:inputComboboxListOfValues>

LOVではユーザーに対して部門名が表示されますが、モデルと対話する場合は一意の部門番号が使用されます。

ユーザーが「検索」または「詳細」リンク(または、af:inputListOfValuesでは「検索」アイコン)をクリックすると、LOVの「検索および選択」ダイアログにすべての値のリストが表形式で表示されます。図35-4は、「詳細」リンクから起動されたLOV検索および選択ダイアログです。

図35-4 LOV検索および選択ダイアログ

ユーザーがLOVに部分文字列を入力して、「検索」をクリックするかタブ・アウトすると、その部分文字列が検索フィールドに表示された状態で「検索および選択」ダイアログが開き、一致する値の結果リストが表に表示されます。ユーザーは、このリストからLOV値にするエントリを選択できます。

LOV検索および選択ダイアログは、ユーザーが新しい行を追加できるようにするための作成機能を持っています。LOV検索および選択ダイアログを使用して新しいレコードを作成している場合、LOVの「自動的に問合せ」コントロールのヒントがfalseに設定されていると、新しい行は空白行として表に現れますので注意してください。行のコンテンツは、「検索」ボタンを使用して問合せを実行したときに表示されます。次の例は、リンクを使用して作成機能を起動するコード・サンプルを示しています。

<f:facet name="customActions">
<af:link id="createLink" text="Create..."
partialSubmit="true">
<af:showPopupBehavior popupId="createSLPopup"
alignId="createLink"/>
</af:link>
</f:facet>

LOVが独立したデータ・コントロールを使用するタスク・フローの一部で、ユーザーが新しいレコードの追加に作成機能を使用した場合、新たに追加されたレコードは親ページには表示されません。これは、検索リージョンも独立したデータ・コントロール・スコープを使用しているため、基礎となるビュー・オブジェクトの更新が表示されないからです。共有のデータ・コントロールおよび独立したデータ・コントロールの詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。

プログラム的にLOVをリフレッシュし、ビュー・オブジェクトの更新を表示するには、次の例に類似するコードとともに、returnListenerをCreateリンクに追加します。

public void refreshLOV() {
BindingContainer bindings = this.getBindings();
oracle.jbo.uicli.binding.JUCtrlListBinding lovBinding =
(oracle.jbo.uicli.binding.JUCtrlListBinding)
bindings.get("Description1");
JUIteratorBinding lovIter = lovBinding.getIteratorBinding();
RowSet rs = lovIter.getRowSetIterator().getRowSet();
rs.executeQuery();

//Add LOV as the partialTrigger

AdfFacesContext.getCurrentInstance().addPartialTarget(this.getPlatformDesc());

LOVは、ビュー・アクセッサ経由でデータ・ソースと関連付けられます。LOVに関連付けられているビュー・アクセッサには、1つ以上のビュー・クライテリアを適用できます。ビュー・アクセッサは、LOVデータ・ソースに永久フィルタを提供します。この永久フィルタのほかにもフィルタを適用できる可能性があります。

LOVダイアログには、ユーザーが値リストの検索に使用する基準を入力するための問合せパネルが含まれる場合も、また結果表が含まれる場合もあります。LOVをビュー・オブジェクトに定義するときに、UIヒントを使用して、リージョンを表示するかどうか、値リストを移入するための検索としてビュー基準を使用するかどうか、またどのLOVコンポーネントを使用するかを指定できます。図35-5に、「値リストの作成」ダイアログとそのオプションの一部を示します。この例では、検索リージョンは、問合せに使用したAll Queryable Attributes名前付きビュー基準とaf:inputComboboxListOfValuesにより、コンポーネントとして使用可能になります。af:inputComboboxListOfValuesの便利なオプションには、「コンボ・ボックスに表示」オプションもあります。これは、ドロップダウン・リストと「検索および選択」ダイアログに表示される多数の属性を選択できるようにするものです。LOV UIヒントの詳細は、「ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法」を参照してください。

af:inputListOfValuesおよびaf:inputComboboxListOfValuesの両方について、ユーザーが入力検索フィールドに部分一致を入力し、[Tab]または[Enter]キーを押した場合、LOVは自動的にLOV検索および選択ダイアログを起動し、ユーザーが入力した部分一致の値を表す項目を1つ使って自動生成されたビュー基準の適用後に問合せを実行します。一致するものがある場合、LOV検索および選択ダイアログには部分一致基準を満たすエントリがすべて表示されます。入力された部分一致条件を満たすエントリがない場合、ダイアログにはすべてのエントリが表示されます。

デフォルトでは、af:inputComboboxListOfValuesコンポーネントでオートコンプリート機能を使用した検索では、大/小文字を区別します。検索で大/小文字を区別しない場合は、そのLOV属性に関連付けたビュー基準を作成します。「ビュー基準の作成」ダイアログで、該当のビュー基準の「大/小文字を区別しない」チェック・ボックスの選択を解除してから、LOV定義にそのビュー基準を適用します。ビュー基準の設定の詳細は、「名前付きビュー基準を宣言的に作成する方法」を参照してください。

図35-5 「値リスト」ダイアログの「UIヒント」タブ

また、ユーザーが値の一部を入力したときに、選択可能な推奨項目のリストを表示するように、LOVコンポーネントを設定することもできます。たとえば、ユーザーがCaと入力すると、部分的にCAと一致する推奨リストが、推奨項目リストとして表示されます。ユーザーはこのリストから、入力フィールドに入力する項目を選択できます。この自動提案動作機能を追加するには、「コンポーネント」ウィンドウからLOVにaf:autoSuggestBehaviorタグを組み込み、ADFモデルに実装されたsuggestedItemsメソッドにselectedItem属性を設定します。

LOVがaf:inputComboboxListOfValuesである場合は、追加のビュー基準を適用して、ドロップダウン・リストの値をさらにフィルタ処理し、スマート・リストを作成できます。「コンボ・ボックスのフィルタ基準」UIヒントが適用されていない場合、ドロップダウン・リストは、ビュー・アクセッサに適用されたビュー基準によりフィルタされます。ただし、このスマート・リスト・フィルタはドロップダウン・リストにのみ適用されます。このリスト全体は、引き続き、検証、およびLOV検索および選択ポップアップ・ダイアログからの検索に用いられます。スマート・リストを有効化すると、LOVの「検索および選択」ダイアログには、「検索」リンクのかわりに「詳細」リンクが表示されるようになります。

LOVで自動提案動作とスマート・リスト・フィルタの両方が有効化されている場合、自動提案では、スマート・リストから検索を開始します。ユーザーがクリックせずに2秒間待機した場合、自動提案では、完全リストの検索も実行して結果を追加します。また、返される推奨項目の数を指定するには、maxSuggestedItems属性を設定します(-1を指定すると、全リストが返されます)。maxSuggestedItems > 0の場合、「詳細」リンクがレンダリングされます。ユーザーがこのリンクをクリックすると、LOV検索および選択ダイアログが表示されます。次の例は、自動提案動作とスマート・リストの両方を備えたLOVのコードを示しています。

af:autoSuggestBehavior
suggestItems="#{bindings.CountryName.suggestItems}"
smartList="#{bindings.CountryName.smartList}"/>
maxSuggestedItems="5"

ビュー・オブジェクトで、1つの属性に1つ以上のLOVを定義できます。1つの属性に複数のLOVを定義した場合、LOVごとに、独自の名前、ビュー・アクセッサ、データ・マッピング、バリデータ、およびUIヒントが設定されます(ただし、デフォルトのリスト・タイプ・ヒントは例外で、属性に対して一度だけ定義されます)。実行時に使用するLOVを切り替えるには、LOV切替え機能が使用されます。LOV切替え機能は、タイプがStringの既存の属性を基礎にすることもできますし、LOV間での切替えのためにのみ、新たなString属性として作成することもできます。LOV切替え機能は、実行時に使用されるLOV名を返します。たとえば、price属性に対して3種類のLOVを作成し、LOV切替え機能としてCountryName属性を指定できます。実行時には、CountryNameの値により、price属性が切り替えられ、その国の価格と通貨を反映したLOVが使用されるようになります。

ある属性がLOVとして定義されている場合、そのビュー基準で「複数の値の選択をサポート」コントロールのヒントを設定し、ユーザーが検索基準フィールドで複数選択できるようにすることができます。LOV属性で複数選択が有効になっているときに、Equal toまたはNot equal to演算子を選択した場合、selectManyChoiceコンポーネントが問合せパネルにレンダリングされます。ユーザーは検索基準として複数の項目を選択できます。

LOVの値が別のLOVの値に依存している場合、この2つのLOVはカスケードLOVと呼ばれます。たとえば、City LOVの値リストは、CountryName LOVで選択された値に応じて変化します。LOVが名前付きバインド変数として定義されている、または検証が有効化されている場合、名前付きバインド変数でNull値が使用できるかどうかなどの条件に応じて、LOV問合せの動作が変わる可能性があります。バインド変数がNullの場合、LOV問合せに空リストが返されるようにすることもできます。ビュー基準のNull値の無視および検証オプションを使用して、LOV問合せの動作を定義できます。

ビュー・オブジェクトにバインド変数を持つLOVがある場合、ビュー・オブジェクトのバインド変数のコントロールのヒントを非表示に設定する必要があります。設定しなかった場合、このバインド変数はLOV検索および選択ポップアップ・ダイアログに表示されます。ビュー・オブジェクトの概要エディタにある「問合せ」タブで、バインド変数をダブルクリックし、「コントロール・ヒント」タブをクリックして、「ヒントの表示」ドロップダウン・リストから「非表示」を選択します。

注意:

値リストは、有効な値のみを返すように設計されています。そのため、データ・ソース・ビュー・オブジェクトの属性に対して定義された検証規則は適用されなくなります。返される値リストには有効な値のみが含まれていることを確認してください。詳細は、「値リストおよび属性検証規則に関する必知事項」を参照してください。

ベスト・プラクティス

「検索モード」イテレータを使用して手動で作成した検索では、LOVとして有効化された属性を検索基準として使用してはいけません。この方法で検索フォームを作成すると、SQL例外、java.sql.SQLException: Attempt to set a parameter name that does not occur in the SQLが発生します。検索フォームを作成するには、「問合せ」コンポーネントおよび「クイック問合せ」コンポーネントを使用するのが一番です。詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。

ビュー・オブジェクトのキー属性が数値である場合に名前属性のLOVリストを表示するには、LOVが有効な属性にサプリメンタル属性をマッピングする必要があります。たとえば、支払いオプションのID値のかわりに、名前別にクレジット・カードのリストを表示するには、名前参照属性にLOVを作成し、主キー属性をLOVのサプリメンタル属性として定義します。LOVが有効な参照属性の作成の詳細は、「LOVを定義して参照属性を表示する方法」を参照してください。

注意:

af:inputListOfValuesおよびaf:inputComboboxListOfValuesは、「検索および選択」ダイアログから返される値リストが有効であることを想定しています。ADFビジネス・コンポーネントの検証エラーは表示されません。

様々な使用法のシナリオと、その他のビュー基準オプションの詳細は、「名前付きビュー基準を宣言的に作成する方法」および「ビュー基準のバインド変数に関する必知事項」を参照してください。

35.2.1 LOVの作成方法

LOVの作成には、af:inputListOfValuesコンポーネントまたはaf:inputComboboxListOfValuesコンポーネントを使用できます。これらのコンポーネントに自動提案動作を追加して、ユーザーの入力から、一致する可能性のある項目のリストを表示できます。

始める前に:

LOVの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「値リスト(LOV)のコンポーネントの作成」を参照してください。

LOVと併用可能な機能についても理解しておくと役立ちます。詳細は、「選択リストとシャトルの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「ビュー・オブジェクト属性の値リスト(LOV)での作業」で説明されている手順に従って、ビュー・オブジェクトでLOVになる属性を定義します。

LOVを作成するには:

1. 「アプリケーション」ウィンドウで、このコンポーネントを表示するWebページをダブルクリックします。

2. 「データ・コントロール」パネルから、属性をJSFページにドラッグ・アンド・ドロップし、「作成」→「値リスト」→「ADF LOV入力」または「作成」→「値リスト」→「ADF LOV選択肢リスト」を選択します。

3. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「操作」パネルから「自動提案動作」をドラッグして、LOVコンポーネントに子としてドロップします。

4. プロパティ・インスペクタで、「自動提案動作」の値を入力します。

- SuggestItems: suggestItemsメソッドに解決されるEL式。

- SmartList: smartListメソッドに解決されるEL式。

- MaxSuggestedItems: 自動提案リストに表示される項目数。完全なリストを表示するには、-1を入力します。

5. LOVに異なる表示属性を設定する場合は、f:converter bindingタグをコンポーネントに追加します。たとえば、LOVで営業担当者IDのかわりに営業担当者名を表示し、このタグをコンポーネント: f:converter binding="#{bindings.SalesRepId.converter}"に追加でき、SalesRepNameを表示属性として定義できます。

6. 自動提案動作を追加する場合は、そのコンポーネントのimmediateプロパティをtrueに設定しないでください。

次の例は、自動提案動作とスマート・リスト機能を持つinputListOfValuesコンポーネントを示しています。

<af:inputListOfValues id="salesRepIdId"      popupTitle="Search and Select: #{bindings.SalesRepId.hints.label}"      value="#{bindings.SalesRepId.inputValue}"      label="#{bindings.SalesRepId.hints.label}"      model="#{bindings.SalesRepId.listOfValuesModel}"      required="#{bindings.SalesRepId.hints.mandatory}"      columns="#{bindings.SalesRepId.hints.displayWidth}"      shortDesc="#{bindings.SalesRepId.hints.tooltip}">
<f:validator binding="#{bindings.SalesRepId.validator}">
<f:converter binding="#{bindings.SalesRepId.converter}">
<af:autoSuggestBehavior suggestItems="#{bindings.SalesRepId.suggestedItems}"
smartList="#{bindings.SalesRepId.smartList}"
maxSuggestedItems="5"/>
</af:inputListOfValues>

35.2.2 LOVの作成時の処理

「データ・コントロール」パネルから属性をドラッグ・アンド・ドロップすると、JDeveloperによって様々な処理が自動的に行われます。「データ・コントロール」パネルの使用時に実行される処理と作成される内容の詳細は、「テキスト・フィールドの作成時の処理」を参照してください。

LOVとして定義された属性を「データ・コントロール」パネルからドラッグし、inputListOfValuesまたはinputComboboxListOfValuesコンポーネントとしてJSFページにドロップすると、JDeveloperにより、次の例に類似したコードがこのページに追加されます。CustomerVOビュー・オブジェクトのState属性は、LOVとして定義されていて、そのデフォルト・コンポーネントはinputComboboxListOfValuesになるように設定されています。このコンポーネントは、ビュー・オブジェクトで宣言的に定義されたコントロールのヒントからプロパティを取得します。自動提案動作を組み込む場合は、「コンポーネント」ウィンドウから手動でタグを追加する必要があります。

<af:inputComboboxListOfValues id="stateId"
popupTitle="Search and Select: #{bindings.State.hints.label}"
value="#{bindings.State.inputValue}"
label="#{bindings.State.hints.label}"
model="#{bindings.State.listOfValuesModel}"
required="#{bindings.State.hints.mandatory}"
columns="#{bindings.State.hints.displayWidth}"
shortDesc="#{bindings.State.hints.tooltip}">
<f:validator binding="#{bindings.State.validator}"/>
</af:inputComboboxListOfValues>

ページ定義ファイルに、次の例に示すようなコードが、JDeveloperによって追加されます。ページ定義のバインディング・セクションでは、LOVがState属性用であることと、LOVの名前がLOV_Stateであることを指定します。JDeveloperは、イテレータ・バインディング・オブジェクトの定義をexecutables要素に、値リストのバインディング・オブジェクトをbindings要素に追加します。

<executables>
<variableIterator id="variables"/>
<iterator Binds="Customers" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="CustomersIterator"/>
</executables>
<bindings>
<listOfValues StaticList="false" IterBinding="CustomersIterator"
Uses="LOV_State" id="State"/>
</bindings>

ページ定義ファイルおよびADFデータ・バインディング式の詳細は、「ページ定義ファイルの処理」および「ADFデータ・バインディングのEL式の作成」を参照してください。

35.2.3 リスト・バリデータとLOVに関する必知事項

ビュー・オブジェクトの属性を値リストの属性として定義する場合は、リスト検証規則が同一のリストに基づいているかぎり、基礎となるエンティティ・オブジェクトで相当するリスト検証規則を定義できます。ビュー・オブジェクトの値リストとしてすでに定義されている属性のエンティティ・オブジェクトには、その他のタイプの検証規則を定義しないでください。これにより、予期せぬ動作が発生し、検証エラーになる可能性があります。検証ルールの定義の詳細は、図11-3および「組込みの宣言的な検証規則の使用」を参照してください。

35.2.4 InputComboboxListOfValuesおよびNULL値に関する必知事項

ビュー・オブジェクト・リストのデータソースを使用してinputComboboxListOfValuesコンポーネントを作成し、かつ、そのリストを実行時に変更できるために、リスト・アイテムが削除される可能性がある場合は、NULL値をサポートするために、LOV属性に対してカスタム・プロパティdisplayModeを定義する必要があります。デフォルトでは、使用できる表示値がない場合、inputComboboxListOfValuesコンポーネントには、LOV属性によって定義されているリスト属性の値が表示されます。削除された表示属性値が対応する属性リスト値に置き換えられないようにするには、LOV表示属性の名前を値とするカスタム・プロパティdisplayModeを定義します。たとえば、図35-6は、LOV表示属性のNameを値としてカスタム・プロパティを定義する、LOV属性DeptIdを示しています。実行時に、使用可能な部門のリストから1つの部門名を削除した場合は、削除した名前を入力すると、カスタム・プロパティにより一致なしが返されます。

図35-6 カスタム・プロパティdisplayModeが定義されたビュー・オブジェクトのLOV属性

35.3 選択リストの作成

ADF Faces Coreには、リストから単一値および複数値を選択するコンポーネントが含まれています。たとえば、selectOneChoiceを使用するとドロップダウン・リストから項目を1つ選択でき、selectManyChoiceを使用するとチェック・ボックスのリストから項目を複数選択できます。表35-1に、選択リストの説明を示します。

表35-1 ADF Facesの単一選択および複数選択リスト・コンポーネント

ADF Facesコンポーネント

説明

使用例

SelectOneChoice

項目のリストから単一値を選択します。

SelectOneRadio

ラジオ・ボタンのセットから単一値を選択します。

SelectOneListbox

スクロール可能な項目のリストから単一値を選択します。

SelectManyChoice

スクロール可能なチェック・ボックスのリストから複数値を選択します。リストの最上位に、選択した項目の名前が表示されます。

SelectManyCheckbox

チェック・ボックスのグループから複数値を選択します。

SelectManyListbox

スクロール可能なチェック・ボックスのリストから複数値を選択します。

SelectOneChoice ADF Facesコンポーネントを使用して、選択リストを作成できます。作成の手順は、SelectOneRadioやSelectOneListboxのような他の単一値選択リストを作成する場合でも同様です。

データバインドされた選択リストは、データ・コントロール・コレクションまたは静的リストの値を表示し、ユーザーの選択に基づいて別のコレクションの属性またはメソッド・パラメータを更新します。リストにバインディングを追加する場合は、リストで選択された値によって移入されるデータ・コントロールの属性を使用します。

注意:

デフォルトでは、ADFモデル・リストのバインディングは、インデックスをコンポーネントに渡します。valuePassThru=trueを設定する場合は、対応するページ定義ファイルのリスト・バインディング・エントリでMode属性をObjectに設定する必要があります。Mode=Objectの場合は、リスト・バインディングはインデックスのかわりにオブジェクトをコンポーネントに渡します。詳細は、「固定選択リストの作成時の処理」を参照してください。

選択リストを作成するには、「リスト・バインディングの編集」ダイアログでベース・データソースとリスト・データソースを選択します。

- ベース・データソース: コントロールにバインドし、ユーザーの選択に応じて更新される属性を含むデータ・コレクションを選択します。

- リスト・データソース: 表示する属性を含むデータ・コレクションを選択します。

データ・コレクションは、ビュー・オブジェクトに基づいています。ビュー・オブジェクトの作成の詳細は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。

「リスト・バインディングの編集」ダイアログでは、次の3種類の選択リストを作成できます。

- モデルドリブン・リスト: リストの選択は、データ・コレクションにバインドされた値リストに基づいています。この種類の選択リストは、「モデルドリブン・リストの作成方法」で説明しているように、他の2種類に比べ大きな利点があります。

- 静的リスト: リストの選択は、エディタに1つずつ値を入力して手動で作成した固定リストに基づいています。詳細は、「固定値を含む選択リストの作成方法」を参照してください。

- 動的リスト: リストの選択は、1つ以上のデータバインドされた属性値に基づいて動的に生成されます。詳細は、「動的に生成される値を含む選択リストの作成方法」を参照してください。

35.3.1 モデルドリブン・リストの作成方法

モデルドリブン・リストは、ビュー・データ・オブジェクトにバインドされた値リストに基づいています。通常、値リストはフォームで使用され、エンド・ユーザーは属性値を手動で入力する必要がなく、ドロップダウン・リストから選択できます。ユーザーが値を選択したフォームを送信すると、ADFモデル・レイヤーのADFデータ・バインディングにより、データバインドされたフィールドに対応するビュー・オブジェクト属性の値が更新されます。

注意:

モデルドリブン・リストを作成するには、データ・コントロール・パレットからJSFページにコレクションをドラッグし、ポップアップ・メニューでADFフォームのいずれか1つを選択してデフォルトを受け入れるのも1つの方法です。この利点は、基礎となるビュー・オブジェクト属性でLOVが定義されている場合、フォーム全体のすべてのLOVが自動的に構成される点です。詳細は、「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」を参照してください。

選択リスト作成の基準として値リストを使用することもできます。値リストに基づいてモデルドリブン・リストを作成する利点は次のとおりです。

- 再利用: 値リストはビュー・データ・コレクションにバインドされています。データ・コレクションに基づいて作成した選択リストはすべて、同じ値リストを使用できます。ADFビジネス・コンポーネントを持つデータ・モデル・プロジェクトの個々の属性にLOVを定義するため、LOV使用をカスタマイズすると、ユーザー・インタフェース内のビジネス・コンポーネントが使用されている場所で変更を参照できます。

- 翻訳: 値リストの値は、翻訳に使用されるリソース・バンドルに含めることができます。

始める前に:

選択リスト・コンポーネントの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「選択リストの作成」を参照してください。

選択リストと併用可能な機能についても理解しておくと役立ちます。詳細は、「選択リストとシャトルの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. ビュー・オブジェクトを作成します。

2. オブジェクトにビュー・アクセッサを作成します。

3. 選択リスト用のベース・データソースの属性にバインドされた値リストを作成する必要があります。たとえば、Addressesビュー・データ・オブジェクトのCountryId属性にバインドされた値リストを作成できます。
詳細は、「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」を参照してください。

モデルドリブン選択リストを作成するには:

1. 「データ・コントロール」パネルから、JSFページに属性をドラッグ・アンド・ドロップして、ポップアップ・メニューから「作成」→「単一選択」→「ADF選択肢を1つ選択」を選択します。

2. 「リスト・バインディングの編集」ダイアログで、「モデルドリブン・リスト」ラジオ・ボタンをクリックします。

3. 「ベース・データソース属性」ドロップダウン・リストから、値リストに表示する属性を選択します。

「ベース・データソース」は、「データ・コントロール」パネルからドラッグしたコレクションになります。このコレクションがドロップダウン・リストに表示されていない場合は、「追加」ボタンをクリックして必要なコレクションを選択します。

4. 「サーバー・リスト・バインディング名」ドロップダウン・リストから、ベース属性用に作成した値リスト定義の名前を選択します。

値リスト定義が作成されている属性を選択しているときには、その定義がドロップダウン・リストに表示されます。たとえば、State属性用の値リスト定義として、LOV_Stateを定義しておくと、「サーバー・リスト・バインディング名」ドロップダウン・リストにはLOV_Stateが表示されます。

5. 「OK」をクリックします。

35.3.2 モデルドリブン選択リストの作成時の処理

「データ・コントロール」パネルから属性をドラッグ・アンド・ドロップすると、JDeveloperによって様々な処理が自動的に行われます。「データ・コントロール」パネルの使用時に実行される処理と作成される内容の詳細は、「テキスト・フィールドの作成時の処理」を参照してください。

次の例は、モデルドリブンSelectOneChoiceコンポーネントを追加した後のページのソース・コードを示しています。

<af:selectOneChoice value="#{bindings.State.inputValue}"
label="#{bindings.State.label}"
required="#{bindings.State.hints.mandatory}"
shortDesc="#{bindings.State.hints.tooltip}"
id="soc1">
<f:selectItems value="#{bindings.State.items}" id="si1"/>
</af:selectOneChoice>

選択項目のリストを提供するためのf:selectItemsタグは、バインディング・コンテナ内のStateリスト・バインディング・オブジェクトのitemsプロパティにバインドされます。ADFデータ・バインディング式の構成の詳細は、「ADFバインディング・フィルタの構成」を参照してください。

ページ定義ファイルでは、bindings要素内にリスト・バインディング・オブジェクト定義が追加されます(次の例を参照)。

<executables>
<variableIterator id="variables"/>
<iterator Binds="Customers" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="CustomersIterator"/>
</executables>
<bindings>
<list IterBinding="CustomersIterator"
StaticList="false" Uses="LOV_State"
id="State" DTSupportsMRU="true"
SelectItemValueMode="ListObject"/>
</bindings>

list要素で、id属性は、リスト・バインディング・オブジェクトの名前を指定します。IterBinding属性は、現在の行が、バインディング・コンテナの各変数を表す属性の行である、変数イテレータを参照します。変数イテレータは、他のデータ・コレクションの場合と同じ方法で変数値をバインディングに公開します。

ページ定義ファイルおよびADFデータ・バインディング式の詳細は、「ページ定義ファイルの処理」および「ADFデータ・バインディングのEL式の作成」を参照してください。

35.3.3 固定値を含む選択リストの作成方法

他のデータソースから値を取得するのではなく、ユーザーが独自にコーディングした選択肢を含む選択リストを作成できます。別のデータソースで動的に生成された値を選択リストに移入する方法の詳細は、「動的に生成される値を含む選択リストの作成方法」を参照してください。

図35-7 固定の値リストにバインドされた選択リスト

始める前に:

選択リスト・コンポーネントの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「選択リストの作成」を参照してください。

選択リストと併用可能な機能についても理解しておくと役立ちます。詳細は、「選択リストとシャトルの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 固定リストとしてコンポーネントに組み込む値リストを準備します。

固定の値リストにバインドされたリストを作成するには:

1. 「データ・コントロール」パネルから、JSFページに属性をドラッグ・アンド・ドロップして、ポップアップ・メニューから「作成」→「単一選択」→「ADF選択肢を1つ選択」を選択します。

2. 「リスト・バインディングの編集」ダイアログで、「固定リスト」ラジオ・ボタンをクリックします。

3. 「ベース・データソース属性」ドロップダウン・リストから、値リストに表示する属性を選択します。

「ベース・データソース」は、「データ・コントロール」パネルからドラッグしたコレクションになります。このコレクションがドロップダウン・リストに表示されていない場合は、「追加」ボタンをクリックして必要なコレクションを選択します。

4. 「一連の値」ボックスで、リストに表示するそれぞれの値を入力します。[Enter]キーを押して値を設定してから、次の値を入力します。たとえば、使用する属性がCountryの場合は、国コードのIndia、JapanおよびRussiaを追加します。

値を入力する順序は、実行時にSelectOneRadioコントロールにリスト項目が表示される順序です。

SelectOneRadioコンポーネントではnull値がサポートされています。このため、ユーザーが項目を選択しない場合、その項目のラベルがブランクとして表示され、コンポーネントの値がデフォルトで空の文字列に設定されます。ブランクまたは空の文字列を使用せずに、null値を表す文字列を指定できます。デフォルトでは、リストの先頭に新しい文字列が表示されます。

5. 「OK」をクリックします。

35.3.4 固定選択リストの作成時の処理

固定選択リストを追加すると、JSFページにソース・コードが追加され、ページ定義ファイルにリスト・バインディング・オブジェクトとイテレータ・バインディング・オブジェクトが追加されます。

次の例は、固定SelectOneChoiceコンポーネントを追加した後のページのソース・コードを示しています。

<af:selectOneChoice value="#{bindings.CountryIdStatic.inputValue}"
label="#{bindings.CountryIdStatic.label}">
<f:selectItems value="#{bindings.CountryIdStatic.items}"/>
</af:selectOneChoice>

選択項目のリストを提供するためのf:selectItemsタグは、バインディング・コンテナ内のCountryIdリスト・バインディング・オブジェクトのitemsプロパティにバインドされています。ADFデータ・バインディング式の詳細は、「ADFデータ・バインディングのEL式の作成」を参照してください。

JDeveloperにより、ページ定義ファイルのexecutables要素内にイテレータ・バインディング・オブジェクトの定義が、bindings要素内にリスト・バインディング・オブジェクトの定義が追加されます(次の例を参照)。

<executables>
<iterator Binds="Addresses1" RangeSize="10"
DataControl="BackOfficeAppModuleDataControl"
id="Addresses1Iterator"/>
</executables>
<bindings>
<list IterBinding="Addresses1Iterator" id="CountryIdStatic" ListOperMode="0"
StaticList="true">
<AttrNames>
<Item Value="CountryIdStatic"/>
</AttrNames>
<ValueList>
<Item Value="India"/>
<Item Value="Japan"/>
<Item Value="Russia"/>
</ValueList>
</list>
</bindings>

ページ定義ファイルの詳細は、「ページ定義ファイルの処理」を参照してください。

35.3.5 動的に生成される値を含む選択リストの作成方法

実行時に、選択リスト・コンポーネントに動的に値を移入できます。

ヒント:

もう1つ、静的なビュー・オブジェクトまたは共有アプリケーション・モジュール内にデータベース・ビュー・オブジェクトを作成する方法もあります。次に、モデルドリブンLOVを使用して、リストを作成します。これにより、キャッシュと翻訳が可能になります。

始める前に:

選択リスト・コンポーネントの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「選択リストの作成」を参照してください。

選択リストと併用可能な機能についても理解しておくと役立ちます。詳細は、「選択リストとシャトルの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 動的値リストを提供するリスト・データソースに対するデータソースの定義

2. ユーザーの選択に基づいて更新されるベース・データソースに対するデータソースの定義

動的に生成される値を含むバインドされた選択リストを作成するには:

1. 「データ・コントロール」パネルから、JSFページに属性をドラッグ・アンド・ドロップして、ポップアップ・メニューから「作成」→「単一選択」→「ADF選択肢を1つ選択」を選択します。

2. 「リスト・バインディングの編集」ダイアログで、「動的リスト」ラジオ・ボタンをクリックします。

3. ドロップダウン・リストから「ベース・データソース」を選択するか、「追加」をクリックします。

4. 「データソースの追加」ダイアログから、更新する属性が含まれるデータ・コレクションを選択して、「OK」をクリックします。

5. ドロップダウン・リストから「リスト・データソース」を選択するか、「追加」をクリックします。

6. 「データソースの追加」ダイアログから、表示する属性が含まれるデータ・コレクションを選択して、「OK」をクリックします。

注意:

リスト・コレクションとベース・コレクションはマスター/ディテール関係になっている必要はありませんが、リスト・コレクション内の属性のタイプはベース・コレクション属性と同じである必要があります。

7. 「データ・マッピング」セクションでは、デフォルト・マッピングをそのまま受け入れることも、「データ値」リストと「リスト属性」リストから別の属性アイテムを選択してマッピングを更新することもできます。

「データ値」コントロールには、選択リストでユーザーがアイテムを選択すると更新される、データ・コレクションの属性が含まれます。「リスト属性」コントロールには、選択リストに値を移入する属性が含まれます。

2番目のマッピングを追加するには、「追加」をクリックします。

8. 「リスト・アイテム」セクションでは、次のように値を選択します。

- 表示属性: 表示する属性を選択します。

- ""選択なし""アイテム: NULL値の選択肢をリストに表示するかどうかと、NULL値の表示方法を指定します。

- MRU: 最近使用したアイテムのリストを表示する場合に選択します。MRUリストに表示するアイテムの数と、使用するセパレータを指定します。

9. 「OK」をクリックします。

35.3.6 動的選択リストの作成時の処理

動的選択リストをページに追加すると、JSFページにソース・コードが追加され、ページ定義ファイルにリスト・バインディング・オブジェクトとイテレータ・バインディング・オブジェクトが追加されます。

次の例は、動的SelectOneChoiceコンポーネントを追加した後のページのソース・コードを示しています。

<af:selectOneChoice value="#{bindings.SalesRepId.inputValue}"
label="#{bindings.SalesRepId.label}"
required="#{bindings.SalesRepId.hints.mandatory}"
shortDesc="#{bindings.SalesRepId.hints.tooltip}" id="soc2">
<f:selectItems value="#{bindings.SalesRepId.items}" id="si4"/>
<f:validator binding="#{bindings.SalesRepId.validator}"/>
</af:selectOneChoice>

選択用のアイテム・リストを提供するf:selectItemsタグは、バインディング・コンテナ内のSalesRepIdリスト・バインディング・オブジェクトのitemsプロパティにバインドされています。ADFデータ・バインディング式の詳細は、「ADFデータ・バインディングのEL式の作成」を参照してください。

JDeveloperにより、ページ定義ファイルのexecutables要素内にイテレータ・バインディング・オブジェクトの定義が、bindings要素内にリスト・バインディング・オブジェクトの定義が追加されます(次の例を参照)。

<executables>
<variableIterator id="variables"/>
<iterator Binds="SummitAppModuleDataControl.dataProvider.
BackOfficeAM.Customers"
DataControl="SummitAppModuleDataControl" RangeSize="25"
id="CustomersIterator"/>
<iterator Binds="Countries" RangeSize="10"
DataControl="BackOfficeAppModuleDataControl"
id="CountriesIterator"/>
<iterator Binds="Customers" RangeSize="-1"
DataControl="BackOfficeAppModuleDataControl"
id="CustomersIterator1"/>
</executables>
<bindings>
<list IterBinding="CountriesIterator" StaticList="false" id="SalesRepId"
DTSupportsMRU="true" SelectItemValueMode="ListObject"
ListIter="CustomersIterator1">
<AttrNames>
<Item Value="Id"/>
</AttrNames>
<ListAttrNames>
<Item Value="Id"/>
</ListAttrNames>
<ListDisplayAttrNames>
<Item Value="Id"/>
</ListDisplayAttrNames>
</list>
</bindings>

デフォルトでは、JDeveloperはCustomersイテレータ・バインディング用のiterator要素に対するRangeSize属性に値-1を設定するため、このイテレータで有効な製品の選択用に完全なリストを提供できるようになります。list要素で、id属性は、リスト・バインディング・オブジェクトの名前を指定します。IterBinding属性は、Countriesコレクションを反復処理するイテレータを参照します。ListIter属性は、Customersコレクションを反復処理するイテレータを参照します。AttrNames要素は、ベース・イテレータにより戻されるベース・データソース属性を指定します。ListAttrNames要素は、ベース・データソース属性にマッピングされるリスト・データソース属性を定義します。ListDisplayAttrNames要素は、実行時にユーザーに表示される値をリストに移入するリスト・データソース属性を指定します。

ページ定義ファイルの詳細は、「ページ定義ファイルの処理」を参照してください。

35.3.7 選択リストの値に関する必知事項

リスト・バインディングを作成すると、リストの値へのアクセスが必要な場合があります。ビジュアル・エディタまたはプロパティ・インスペクタのいずれかで、コンポーネントのvaluePassThru属性をtrueに設定できます。次の例は、selectOneChoiceコンポーネントのコードを示しています。

<af:selectOneChoice value="#{bindings.Language.inputValue}"
label="#{bindings.Language.label}"
required="#{bindings.Language.hints.mandatory}"
shortDesc="#{bindings.Language.hints.tooltip}"
valueChangeListener="#{myBean.valueChanged}"
id="soc1" valuePassThru="true">
<f:selectItems value="#{bindings.Language.items}" id="si1"/>
</af:selectOneChoice>

valuePassThru属性がtrue、対応するページ定義ファイルのMode属性がObjectに設定されている場合のみ、valueChangeListenerに渡される値のタイプをObject(実際の値)にできます。デフォルトでは、ModeはIndexに設定されます。次の例は、ページ定義ファイルのMode属性を示しています。

<list IterBinding="AvailableLanguagesView1Iterator" id="Language"
DTSupportsMRU="true" StaticList="false"
ListIter="CountryCodesView1Iterator"
Mode="Object"/>

35.4 ナビゲーション・リスト・バインディングを持つリストの作成

ナビゲーション・リスト・バインディングを使用して、ユーザーがコレクション内のオブジェクトを移動できるようにします。ユーザーがナビゲーション・リスト・コンポーネントを使用して現在のオブジェクト選択を変更すると、属性を介して同じコレクションにバインドされている他のコンポーネントも、新しく選択したオブジェクトから表示されます。また、現在の行を変更するコレクションがデータ・モデルのマスター/ディテール関係のマスター・ビュー・オブジェクト・インスタンスである場合、ディテール・ビュー・オブジェクト・インスタンスの行セットが自動的に更新され、新規の現在のマスター行に適したデータが表示されます。

35.4.1 ナビゲーション・リスト・バインディングを持つリストの作成方法

始める前に:

ナビゲーション・リストの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「ナビゲーション・リスト・バインディングを持つリストの作成」を参照してください。

ナビゲーション・リストと併用可能な機能についても理解しておくと役立ちます。詳細は、「選択リストとシャトルの追加機能」を参照してください。

ナビゲーション・リスト・バインディングを使用するリストの作成方法:

1. 「データ・コントロール」パネルから、マスター・コレクションをページにドラッグ・アンド・ドロップし、「作成」→「ナビゲーション」→「ADFナビゲーション・リスト」を選択します。

ユーザーは、マスター・コレクションから選択します。

2. 「リスト・バインディングの編集」ダイアログの「ベース・データソース」ドロップダウン・リストからコレクションを選択します。このコレクションのメンバーがリストの作成に使用されます。

これは、「データ・コントロール」パネルからドラッグしたコレクションです。このコレクションがドロップダウン・リストに表示されていない場合は、「追加」ボタンをクリックして必要なコレクションを選択します。

3. 「属性の表示」ドロップダウン・リストから、リストに表示される属性を選択します。すべての属性を含む選択肢を指定し、「複数の選択」を選んで、選択ダイアログを開くことができます。

4. 「複数の表示属性の選択」ダイアログで、表示する属性を「使用可能な属性」リストから「表示する属性」リストに移します。「OK」をクリックして、ダイアログを閉じます。

5. 「OK」をクリックします。

6. 「データ・コントロール」パネルから、詳細コレクションをドラッグして、ページの「詳細」セクションの内側に出力コンポーネントとしてドロップします。

この出力コンポーネントは、データの表示に使用する任意のコンポーネントになります。たとえば、表を使用する場合は、「作成」→「表」→「ADF表」を選択します。

「詳細」セクションは、手順1でナビゲーション・リストを作成したときに、JDeveloperによって追加されたaf:panelHeaderコンポーネントです。

35.4.2 ナビゲーション・リスト・バインディングの作成時の処理

ナビゲーション・リストをページに追加すると、JSFページにソース・コードが追加され、ページ定義ファイルにリスト・バインディング・オブジェクトとイテレータ・バインディング・オブジェクトが追加されます。

JDeveloperは、このページにf:selectItemsタグを含むselectOneChoiceコンポーネントを追加します。selectOneChoiceコンポーネントを使用すると、ユーザーは、ソースのデータ・コレクションで選択した属性に基づいた値リストから選択できるようになります。JDeveloperは、af:panelHeaderコンポーネントも追加します。このコンポーネントには、選択内容に基づいたデータを表示するためのコンポーネントを含めます。この例では、データの表示用に表コンポーネントを追加しています。af:panelHeaderコンポーネントのpartialtriggersは、selectOneChoiceコンポーネントのidに設定されているため、選択内容が変更されると、新しいデータが表示されるようになります。次の例は、ナビゲーション・リストを追加した後のページのソース・コードを示しています。

<af:selectOneChoice id="nl1" autoSubmit="true"
value="#{bindings.Customers.inputValue}"
label="#{bindings.Customers.label}">
<f:selectItems value="#{bindings.Customers.items}" id="si1"/>
</af:selectOneChoice>
<af:panelHeader text="Details" partialTriggers="nl1" id="ph1">
<af:table value="#{bindings.OrdersForCustomer.collectionModel}" var="row"
rows="#{bindings.OrdersForCustomer.rangeSize}"
emptyText="#{bindings.OrdersForCustomer.viewable ?
'No data to display.' : 'Access Denied.'}"
fetchSize="#{bindings.OrdersForCustomer.rangeSize}" rowBandingInterval="0"
id="t1">
<af:column headerText="#{bindings.OrdersForCustomer.hints.Id.label}" id="c1">
<af:inputText value="#{row.bindings.Id.inputValue}"
...

ページ定義ファイルのexecutables要素内には、JDeveloperによってイテレータ・バインディング・オブジェクトの定義が追加されます。次の例は、ページ定義ファイル内のイテレータ・バインディングとナビゲーション・リスト・バインディングを示しています。

<executables>
<variableIterator id="variables"/>
<iterator Binds="Customers" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl" id="CustomersIterator"/>
<iterator Binds="OrdersForCustomer" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="OrdersForCustomerIterator"/>
</executables>
<bindings>
<navigationlist IterBinding="CustomersIterator" ListOperMode="navigation"
ListIter="CustomersIterator"
id="Customers" DTSupportsMRU="false">
<AttrNames>
<Item Value="Name"/>
</AttrNames>
</navigationlist>
<tree IterBinding="OrdersForCustomerIterator" id="OrdersForCustomer">
<nodeDefinition DefName="oracle.summit.model.views.OrdVO"
Name="OrdersForCustomer0">
<AttrNames>
<Item Value="Id"/>
<Item Value="CustomerId"/>
<Item Value="DateOrdered"/>
<Item Value="LastName"/>
<Item Value="Name"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

35.5 データバインド・シャトルの作成

selectManyShuttleおよびselectOrderShuttleコンポーネントは、2つのリスト・ボックスと、ユーザーが先行(選択可能)リスト・ボックスから複数の項目を選択して項目を後続(選択済)リスト・ボックスに移動または往復させる(またはその逆を行う)ことのできるボタンをレンダリングします。項目をダブルクリックして、別のリスト・ボックスに移動することもできます。図35-8に、レンダリングされたselectManyShuttleコンポーネントの例を示します。このコンポーネントは、Summit ADFサンプル・アプリケーションに実装されています。リスト・ボックスの上に表示されるヘッダーには任意のテキストを指定できます。

図35-8 SelectManyShuttleコンポーネント

selectManyShuttleとselectOrderShuttleで違う点は、selectOrderShuttleコンポーネントでは、ユーザーは横の上下矢印を使用して後続リスト・ボックス内の項目を並替えできることのみです。

Summit ADFサンプル・アプリケーションでは、selectManyShuttleコンポーネントを使用することで、ユーザーが注文する製品を「All available products」リスト・ボックスから選択して「Selected Products」リスト・ボックスに移動できるようにしています。左側の先行リスト・ボックスには、入手可能なすべての製品が表示されます。右側の後続リスト・ボックスには、顧客が選択した製品が表示されます。

他のADF Faces選択リスト・コンポーネントと同様に、selectManyShuttleコンポーネントとselectOrderShuttleコンポーネントは、f:selectItemsタグを使用して、先行リストに表示して選択できるアイテムのリストを提供できます。

f:selectItemsタグをバインドする前に、シャトルを必要とするページによって使用される汎用クラスを作成します。使用可能なすべての選択肢のリスト(先行リスト、または使用可能な製品カテゴリ)、および選択された選択肢のリスト(後続リスト、または割り当てられた製品カテゴリ)で使用すべきビュー・オブジェクト・インスタンス名を記述するプロパティのgetterメソッドおよびsetterメソッドをこのクラスで宣言し、インクルードします。Summit ADFサンプル・アプリケーションでは、f:selectItemsはバインディング・コンテナを使用して、入手可能な製品のリストを取得します。例35-1に示すShuttleBeanクラスは、showshuttle.jsfページのシャトル・コンポーネントの移入と選択の状態を管理するために作成します。

getSelectedProducts()メソッドは、シャトルの後続リスト内のアイテムを定義するListを返します。getSelectedProducts()から返される値は、先行リスト内の値のサブセットです。先行リストに存在している値でも、getSelectedProducts()に存在していない値は、無視されます(また、エラーがサーバー・ログに記録されます)。ShuttleBeanクラスでは、ADFUtilsクラス内のユーティリティ・メソッドを必要に応じてコールできます。また、このクラスは基本beanのいくつかのプロパティの値を使用しますので注意してください。

例35-2に、シャトル・コンポーネントを操作するためにorder-select-many-item.xmlタスク・フロー内で構成されるマネージドBeanおよび管理プロパティを示します。

例35-1 ShuttleBeanクラス

public class ShuttleBean {

private List<oracle.jbo.domain.Number> _selectedProducts =
new ArrayList<oracle.jbo.domain.Number>();

public ShuttleBean()
{
}

public void setSelectedProducts(List<oracle.jbo.domain.Number>
_allocatedRoles) {
this._selectedProducts = _allocatedRoles;
}

public List<oracle.jbo.domain.Number> getSelectedProducts() {
return _selectedProducts;
}

public void onAddMultipleProducts(ActionEvent actionEvent) {
DCBindingContainer dcBindings =
(DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry();
OperationBinding createMethod =
dcBindings.getOperationBinding("CreateInsert");
if ( createMethod != null && _selectedProducts.size() > 0 ) {
DCIteratorBinding iterator =
dcBindings.findIteratorBinding("ItemsForOrderIterator");
for ( oracle.jbo.domain.Number productId : _selectedProducts )
{
createMethod.execute();
iterator.getCurrentRow().setAttribute("ProductId", productId );
}
}
}
}

例35-2 order-select-many-itemsタスク・フロー内のシャトル・コンポーネント用のマネージドBean

<managed-bean id="__3">
<managed-bean-name>ShuttleBean</managed-bean-name>
<managed-bean-class>oracle.summit.backing.ShuttleBean</managed-bean-class>
<managed-bean-scope>backingBean</managed-bean-scope>
</managed-bean>
<view id="showshuttle">
<page>/orders/showshuttle.jsf</page>

35.5.1 データバインドされたシャトルの作成方法

始める前に:

シャトルの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「データバインド・シャトルの作成」を参照してください。

選択リストと併用可能な機能についても理解しておくと役立ちます。詳細は、「選択リストとシャトルの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. ページ定義ファイルに関連するイテレータ・バインディングを作成します。例35-3を参考にしてください。
Summit ADFサンプル・アプリケーションでは、ItemsForOrderIteratorによるProductIdのリスト・バインディングがshowshuttlePageDef.xmlファイルに追加されることで、先行リストに移入する製品のリストを提供します。

2. ShuttleBeanクラスと同様のクラスを作成して、必要に応じて値を処理するメソッドを用意します。例35-1を参考にしてください。

3. 必要なマネージドBeanと管理プロパティをタスク・フロー定義で構成します。バインドなしタスク・フローの場合はadfc-config.xmlファイルを構成します。例35-2を参考にしてください。

シャトル・コンポーネントを作成するには:

1. 「アプリケーション」ウィンドウで、コンポーネントを表示するWebページをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「テキストおよび選択」パネルからSelectManyShuttleまたはSelectOrderShuttleをドラッグしてページにドロップします。

図35-9に示すように、シャトルの挿入ウィザードが表示されます。

図35-9 「SelectManyShuttleの挿入」ウィザード

3. 「リストにバインド(アイテムを選択)」を選択し、「バインド」をクリックします。

4. 「式ビルダー」で、ツリー構造を開いて、先行リストの値を移入する式を作成し、「OK」をクリックします。

Summit ADFサンプル・アプリケーションで、「ADFバインディング」→bindings→ProductId→itemsを選択し、式#{bindings.ProductId.items}を作成して、「終了」をクリックします。これにより、selectManyShuttleコンポーネントのf:selectedItemタグをデータ・コレクションにバインドします。このタグにより、製品のリストをシャトルの先行リストに移入します。

getAllProducts()などのメソッドを使用して先行リストの値を取得する場合は、このメソッドをマネージドBean内に作成する必要があります。その後、式ビルダーで、このメソッドにバインドします。

5. 「次へ」をクリックします。

6. 「共通プロパティ」ページで、「値」フィールドの横にある「バインド」をクリックします。

7. 「式ビルダー」で、ツリーを開いて、後続リストの値を移入する式を作成し、「OK」をクリックします。

Summit ADFサンプル・アプリケーションで、「ADFマネージドBean」→BackingBeanScope→ShuttleBean→selectedProductsを選択し、式#{backingBeanScope.ShuttleBean.selectedProducts}を作成してから、「終了」をクリックします。これにより、value属性をselectedProducts()メソッドにバインドします。このメソッドで、シャトルの後続リストに値を移入します。

8. 選択された値を処理するために、別のコントロールを追加することもできます。

Summit ADFサンプル・アプリケーションでは、「Done」というラベルの付いたaf:buttonコンポーネントがページに追加されます。このコンポーネントは、ShuttleBeanに定義されているonAddMultipleProductsメソッドをコールすることで、選択された製品を処理します。

35.5.2 データバインドされたシャトルの作成時の処理

showshuttle.jsfのすべてのバインディングは、showshuttlePageDef.xmlファイル内で定義されます。例35-3に、showshuttle.jsfページ用のページ定義ファイルの一部を示します。

例35-4に、「SelectManyShuttleの挿入」ダイアログを完了した後のselectManyShuttleコンポーネントのコードを示します。

例35-3 showshuttleページ用のページ定義ファイル

<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="12.1.2.61.86" id="showshuttlePageDef" Package="orders">
<parameters/>
<executables>
<variableIterator id="variables"/>
<iterator Binds="ItemsForOrder" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl"
id="ItemsForOrderIterator"/>
</executables>
<bindings>
<list IterBinding="ItemsForOrderIterator" StaticList="false"
Uses="LOV_ProductId" id="ProductId"
DTSupportsMRU="true" SelectItemValueMode="ListObject"/>
<action IterBinding="ItemsForOrderIterator" id="CreateInsert"
RequiresUpdateModel="true" Action="createInsertRow">
</action>
</bindings>
</pageDefinition>

例35-4 showshuttle.jsffファイル内のSelectManyShuttleコンポーネント

<af:selectManyShuttle id="sms1"
value="#{backingBeanScope.ShuttleBean.selectedProducts}"
leadingHeader="All available products" trailingHeader="Selected products">
<f:selectItems value="#{bindings.ProductId.items}" id="si1"/>
</af:selectManyShuttle>

36 ADFによるデータバインドされた検索フォームの作成

この章では、複数の属性に対する複合検索を実行するために、ADFビジネス・コンポーネントを基にモデル化されたデータから検索フォームを作成する方法について説明します。このフォームの作成には、ADFデータ・バインディングとADF Facesコンポーネントを使用します。また、単一属性の検索を実行するための検索フォームの作成方法についても説明します。複雑な問合せ検索フォームについては、問合せ検索フォーム・モードの設定方法、結果表、保存済みの検索リスト、およびパーソナライズについて説明します。単一属性検索フォームについては、フォーム・レイアウトの構成方法を説明します。また、名前付きバインド変数およびQuery-by-Example (QBE)フィルタ処理された表の検索の使用についての情報も含まれます。

この章の内容は次のとおりです。

- 検索フォームの作成について

- 問合せ検索フォームの作成

- 検索フォーム・プロパティの設定

- クイック問合せ検索フォームの作成

- スタンドアロンのフィルタ処理された検索表を名前付きビュー基準から作成

36.1 検索フォームの作成について

開発者は、オブジェクトの既知の属性に基づいてユーザーが検索基準を入力フィールドに入力することのできる検索フォームを作成できます。検索基準は入力テキスト・フィールドに入力するか、ポップアップ・リスト・ピッカーまたはドロップダウン・リスト・ボックスの値リストから選択できます。入力した基準は実行する問合せに組み込まれます。問合せの実行時に、名前付きバインド変数を使用して属性値を指定できます。問合せの結果は、表、フォームまたは別のUIコンポーネントとして表示できます。

Oracle ADFは、問合せおよびクイック問合せの2つのタイプの検索フォームをサポートしています。問合せ検索フォームは完全な機能を備えた検索フォームです。クイック問合せ検索フォームは、検索基準が1つしかない簡略化されたフォームです。それぞれの検索フォームはフィルタ処理された表と組み合せて結果を表示できるため、検索機能を追加できます。スタンドアロンのフィルタ処理された表も作成でき、問合せ検索パネルまたはクイック問合せ検索パネルを使用せずに検索を実行できます。

検索フォームは、ビュー・オブジェクトで定義したビュー基準またはJDeveloperで定義した暗黙的ビュー基準に基づいています。検索フォームは、再利用およびパーソナライズが可能なリージョン・ベースのコンポーネントです。また、問合せの実行に必要な多くのアクションおよびイテレータ管理操作をカプセル化および自動化します。イテレータの変更および新しいイテレータの作成を行わずに、同一ページに複数の検索フォームを作成できます。

フィルタ処理された表は、それぞれの検索可能列の上に追加のQuery-by-Example (QBE)検索基準フィールドを持つ表です。表のフィルタ処理オプションが有効になっている場合、各列にQBEスタイルの検索基準を入力し問合せ結果をフィルタ処理できます。表の詳細は、「ADFによるデータバインドされた表の作成」を参照してください。

個別の問合せコンポーネントおよび表コンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」および「表、ツリー、およびその他のコレクションベースのコンポーネントの使用」を参照してください。

36.1.1 暗黙的ビュー基準と名前付きビュー基準

データ・コントロールの作成時に、すべてのデータ・コレクションには「すべての問合せ可能な属性」基準を含む「名前付き基準」ノードが自動的に含まれます。これは、データ・コレクションの検索可能なすべての属性または列を含むデフォルトのビュー基準です。このビュー基準は編集または変更できません。暗黙的ビュー基準は、問合せ検索フォームまたはクイック問合せ検索フォームの作成時に宣言的に作成した(または、名前付き)ビュー基準と同様に使用できます。名前付きビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。

そのビュー・オブジェクトまたはコレクションに対して名前付きビュー基準を追加する場合、新しいビュー基準は「名前付き基準」ノードに追加されます。

注意:

問合せ検索フォームには、ビュー基準がネストしている式を扱う場合の制約事項がいくつかあり、一部の種類のネストした式では動作しない可能性があります。検索フォームでサポートされるネストされた式の詳細は、「ネストされたビュー基準の式に関する必知事項」を参照してください。

「データ・コントロール」パネルでは、データ・コレクションの「名前付き基準」ノードに、名前付きビュー基準が定義されているかどうかに関係なく、必ず暗黙的ビュー基準が含まれます。暗黙的ビュー基準は常に、すべてのデータ・コレクションで使用できます。

36.1.2 値リスト(LOV)入力フィールド

値リスト(LOV)コンポーネントは、問合せにより生成されたリストからユーザーが値を選択して入力できる、入力コンポーネントです。ADF Facesには、af:inputListOfValuesおよびaf:inputComboboxListOfValuesコンポーネントが用意されています。検索フォームの一部に依存LOVを使用する場合は、必ず、af:queryコンポーネントとともに使用してください。LOVコンポーネントの詳細は、「値リスト(LOV)のコンポーネントの作成」を参照してください。

ある属性がLOVとして定義されている場合、そのビュー基準で「複数の値の選択をサポート」コントロールのヒントを設定し、ユーザーが検索基準フィールドで複数選択できるようにすることができます。LOV属性で複数選択が有効になっているときに、Equal toまたはNot equal to演算子を選択した場合、selectManyChoiceコンポーネントが問合せパネルにレンダリングされます。ユーザーは検索基準として複数の項目を選択できます。

LOVが問合せコンポーネントに含まれているときに、「複数の値の選択をサポート」ヒントが設定されておらず、Equal toまたはNot equal to演算子が選択されている場合、この問合せコンポーネントは、ビュー・オブジェクト内の対応する属性に対する「デフォルトのリスト・タイプ」コントロール・ヒントに従って検索基準コンポーネントをレンダリングします。

クイック問合せコンポーネントでは、複数選択はサポートされていません。これは常に、「デフォルトのリスト・タイプ」コントロール・ヒントで指定されたコンポーネントをレンダリングします。表36-1に、コントロール・ヒントの選択肢とデフォルトのリスト・コンポーネントを示します。

表36-1 問合せおよびクイック問合せの検索基準フィールド入力コンポーネント

デフォルトのリスト・タイプのコントロール・ヒント

コンポーネント

値リストのある入力テキスト

af:inputListOfValues

値リストを持つコンボ・ボックス

af:inputComboboxListOfValues

選択リスト、コンボ・ボックス、リスト・ボックス、ラジオ・グループ

af:selectOneChoice

ビュー基準オプションの詳細は、「名前付きビュー基準を宣言的に作成する方法」および「ビュー基準のバインド変数に関する必知事項」を参照してください。

36.1.3 検索フォームのユースケースと例

検索フォームは、モデルドリブンのaf:queryおよびaf:quickQueryコンポーネントに基づいています。これらの基礎となるコンポーネントはモデルドリブンであるため、検索フォームはモデルの変更を反映するよう自動的に変更されます。ビュー・レイヤーは変更する必要がありません。たとえば、ビュー・オブジェクトまたはエンティティ・オブジェクトの属性に値リスト(LOV)を定義すると、LOVは検索フォームにLOVコンポーネントとして自動的に表示されます。あるいは、ビュー基準を変更してWHERE句用に新しい属性を挿入すると、このビュー基準を使用する検索パネルは、その属性用の検索フィールドを追加してその変更を自動的に反映します。

図36-1に、クイック問合せコンポーネントを示します。

図36-1 クイック問合せ

製品名、価格帯および可用性などの基準を組み合せたより複雑な検索には、問合せコンポーネントが使用されます。図36-2に示すように、様々なモードで問合せコンポーネントを作成し、ユーザーに各種機能を提供できます。ユーザーは、「フィールドの追加」ボタンを使用して、独自の基準を作成できます。今後の使用を目的として作成した検索を保存できます。

図36-2 問合せコンポーネント

簡易検索では、図36-3に示すように、フィルタ処理された表を使用して例示問合せ(QBE)検索を実行できます。

図36-3 フィルタ処理された表の検索

36.1.4 検索フォームの追加機能

ADFモデル・レイヤーを構成または使用する前に、他のADF機能を理解しておくと役立つ場合があります。また、モデル・レイヤーの構成によって可能になることについても、確認しておくことをお薦めします。次に、関連する他の機能へのリンクを示します。

- 問合せコンポーネントとクイック問合せコンポーネントはどちらも、ビュー・オブジェクトに定義されたビュー基準に基づいています。ビュー基準を使用して初期の検索フィールドと検索基準を設定します。コントロール・ヒントを使用して問合せコンポーネントをさらに定義します。名前付きビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。

- フィルタ処理された表には検索機能も備わっているので、簡易検索機能と見なす必要があります。表の詳細は、「ADFによるデータバインドされた表の作成」を参照してください。

- 値リスト・コンポーネントでは、LOV選択リストを作成する際に、検索パネルで問合せコンポーネントを使用します。LOVコンポーネントの詳細は、「値リスト(LOV)のコンポーネントの作成」を参照してください。

- アプリケーションがメタデータ・ストレージ(MDS)と組み合せて設定されている場合は、保存済の検索をトランザクション全体で維持し、検索をパーソナライズできます。MDSの使用方法の詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。

36.2 問合せ検索フォームの作成

問合せ検索フォームは、複雑なトランザクション検索を行うための標準フォームです。それぞれに組込み演算子のドロップダウン・リストを保持する複数の検索基準フィールドがある複雑な検索フォームを作成できます。また、カスタム演算子を追加してリストをカスタマイズすることもできます。問合せ検索フォームでは、値リスト、AND結合とOR結合、および将来使用するための検索の保存がサポートされています。

問合せは、問合せ操作で使用するビュー・オブジェクトに関連付けられています。特に、問合せコンポーネントは、ビュー・オブジェクトに定義されたビュー基準を図示したものです。ビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。ビュー基準で定義されたビュー基準アイテムは、問合せコンポーネントの検索パネルの検索基準のソースとなります。ビュー基準エディタの「表示されたモード」オプションにより、表示される検索基準を制御します。

検索基準は、属性の論理的なグループを指定するために、グループ化できます。たとえば、アドレスの属性を1つにグループ化できます。

問合せ検索フォームには基本モードと詳細モードがあります。ユーザーは「基本」ボタンまたは「詳細」ボタンを使用して、2つのモードを切り替えることができます。設計時にフォーム・プロパティを宣言的に指定(デフォルトの状態を設定するなど)して、基本または詳細のいずれかにすることができます。図36-4に、3つの検索基準を含む詳細モードの問合せ検索フォームを示します。

図36-4 詳細モードの問合せ検索フォーム

詳細モードの問合せフォームに含まれる機能は次のとおりです。

- ドロップダウン・リストからの検索基準演算子の選択

- カスタム演算子の追加と標準演算子の削除

- WHERE句の結合におけるANDまたはOR(すべてに一致またはいずれかに一致)の選択

- 実行時の検索基準フィールドの動的な追加および削除

- 将来使用するための検索の保存

- 保存済の検索のパーソナライズ

通常、問合せ検索フォームはいずれかのモードで、関連付けられた結果表またはツリー表とともに使用します。Oracle ADFのSummitサンプル・アプリケーションでは、問合せパネルと結果表が図36-5のように表示されます。

図36-5 問合せ検索の結果表

基本モードには、ユーザーによる動的な検索基準フィールドの追加以外の詳細モードのすべての機能が含まれます。図36-6に、3つの検索基準フィールドを含む基本モードの問合せ検索フォームを示します。詳細モードで検索基準フィールドの追加に使用される、「保存」ボタンの隣のドロップダウン・リストがないことに注意してください。

図36-6 3つの検索基準フィールドを含む基本モードの問合せフォーム

どちらのモードでも、Greater ThanおよびEqual Toなどの演算子をドロップダウン・リストから選択して各検索基準フィールドを変更できます。また、「すべてに一致」または「いずれかに一致」ラジオ・ボタンを使用して検索パネル全体を変更できます。検索フォームでは、ほとんどすべての状況下で部分ページ・レンダリングもサポートされています。たとえば、「Between」演算子を選択した場合、別の入力フィールドが表示され、範囲の上限を選択できるようになります。

「すべてに一致」を選択すると、問合せのWHERE句の検索基準において暗黙的にAND結合が使用されます。「いずれかに一致」を選択すると、問合せのWHERE句において暗黙的にOR結合が使用されます。これは、図36-4に示した検索基準で「すべてに一致」が選択された場合の簡略化されたWHERE句です(ビュー基準の実際のWHERE句は異なります)。

WHERE (Id < 4) AND (InStock > 20) AND (Name="Shoes")

これは、図36-4に示した検索基準で「いずれかに一致」が選択された場合の簡略化されたWHERE句です。

WHERE (Id < 4) OR (InStock > 20) OR (Name="Shoes")

問合せのビュー基準の基準アイテム間でAND結合およびOR結合が混在している場合、コンポーネントが最初にレンダリングされるときには「すべてに一致」および「いずれかに一致」のいずれも選択されません。しかし、「すべてに一致」または「いずれかに一致」を選択して、ビュー基準に初期状態として定義された結合をオーバーライドできます。

詳細モードの問合せフォームでは、より複雑な問合せを実行するために、ユーザーは問合せパネルに検索基準フィールドを動的に追加できます。ユーザーが作成した検索基準フィールドは削除できますが、ユーザーは既存のフィールドを削除できません。「フィールドの追加」ドロップダウン・リストを使用すると、1つの検索基準フィールドまたはグループに含まれるすべてのフィールドを追加できます。

図36-7に、問合せ検索フォームと、「フィールドの追加」ドロップダウン・リストを選択して、検索フォームに基準フィールドを追加する方法を示します。

図36-7 実行時の検索基準フィールドの動的な追加

図36-8に、新しいユーザー追加の検索基準がある問合せ検索フォームを示します。その右側には削除アイコンがあります。削除アイコンをクリックすると条件を削除できます。

図36-8 削除アイコンがあるユーザー追加の検索基準

図36-9に示すように、「並替え」ボタンを使用して、「検索フィールドの並替え」ダイアログを開き、検索パネルの検索フィールドを並べ替えることができます。

図36-9 「検索フィールドの並替え」ダイアログ

「すべてに一致」または「いずれかに一致」が選択されている場合に、ユーザーが検索基準の2つ目のインスタンスを動的に追加すると、「すべてに一致」と「いずれかに一致」はともに選択解除されます。ユーザーは、「検索」ボタンをクリックする前に、「すべてに一致」または「いずれかに一致」を再度選択する必要があります。

問合せ検索フォームに基本モードおよび詳細モードの両方を使用する場合、各検索基準フィールドは、基本モードのみでの表示、詳細モードのみでの表示、両方での表示のいずれかに定義できます。ユーザーがあるモードから別のモードに切り替えると、そのモードに定義された検索基準フィールドのみが表示されます。たとえば、基本モード用にA、B、Cの3つの検索フィールドを、詳細モード用にA、B、Dの3つの検索フィールドを問合せに定義したとします。問合せ検索フォームが基本モードの場合、検索基準フィールドA、B、Cが表示されます。問合せ検索フォームが詳細モードの場合、検索基準フィールドA、B、Dが表示されます。その検索フィールドに入力されたすべての検索データは、フォームがそのモードに戻ったときも保持されています。基本モードにおいてユーザーが検索フィールドCに35と入力し、詳細モードに切り替えた後に再度基本モードに戻ると、フィールドCには値35が入力された状態で再表示されます。

基本または詳細モードを使用するとともに、検索フォームをどの程度表示するかを決定することもできます。デフォルト設定では、フォーム全体が表示されます。圧縮モードまたはシンプル・モードで表示するように、問合せコンポーネントを構成することもできます。圧縮モードでは、ヘッダーや境界線がなく、「保存済の検索」ドロップダウン・リストは開く/閉じるアイコンの横に移動しています。また、「基本」ボタンがフォームの下部に移動され、「検索」ラベルが省略されています。図36-10に、圧縮モードに設定された問合せ検索フォームを示します。

図36-10 コンパクト・モードのqueryコンポーネント

シンプル・モードでは、ヘッダーおよびフッターがなく、通常その領域に表示されるボタンもないコンポーネントが表示されます。図36-11に、単純モードに設定された同じ問合せ検索フォームを示します。

図36-11 簡易モードのqueryコンポーネント

ビュー基準が複数定義されている場合、各ビュー基準は「保存済の検索」ドロップダウン・リストから選択できます。これら保存済の検索は設計時に作成され、システム検索と呼ばれます。たとえば、ビュー・オブジェクトに2つのビュー基準を定義している場合は、図36-12に示すように、問合せ検索フォームで「保存済の検索」ドロップダウン・リストから両方のビュー基準が選択できるようになります。

注意:

問合せパネルの開閉アイコンをクリックしてパネルを開閉しても、適用されたビュー基準はリセットされないことに注意してください。適用されているビュー基準をリセットするには、「リセット」ボタンをクリックします。

図36-12 問合せフォームの「保存済の検索」ドロップダウン・リスト

ビュー・オブジェクトに明示的に定義されたビュー基準が存在しない場合、デフォルトの暗黙的ビュー基準を使用できます。

ユーザーは、検索の状態を将来使用するために、実行時に保存済の検索を作成することもできます。図36-13に示すように、「保存」ボタンをクリックして「検索の保存」ダイアログを開き、入力された検索基準値、基本モードまたは詳細モードの状態、結果の表またはコンポーネントのレイアウトを保存できます。保存済の検索は、「保存済の検索」ドロップダウン・リストにアルファベット順で表示されます。ユーザーが作成した保存済の検索はセッション内で保持されます。保存済の検索を、セッションを超えて使用できるようにするには、保存済の検索を格納するための永続データ・ストアを構成する必要があります。Oracle ADFでは、アクセス制御の対象となるデータソース(MDSなど)を使用できます。MDSの使用方法の詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。

保存済の検索を実行する際には、結果コンポーネントのレイアウトも保存するかどうかを指定できます。保存済の検索を作成し、結果コンポーネントのレイアウトを保存するには、MDSが構成されている必要があります。問合せコンポーネントのsaveResultsLayout属性をalwaysに設定すると、結果コンポーネントのレイアウトが保存されます。saveResultsLayoutをneverに設定すると、レイアウトは保存されません。

<context-param>
<description>Saving results layout</description>
<param-name>oracle.adf.view.rich.query.SAVE_RESULTS_LAYOUT</param-name>
<param-value>true</param-value>
</context-param>

saveResultsLayoutが定義されていない場合は、レイアウトの保存には、web.xmlファイルのアプリケーションレベルのプロパティoracle.adf.view.rich.query.SAVE_RESULTS_LAYOUTがデフォルトで使用されます。oracle.adf.view.rich.query.SAVE_RESULTS_LAYOUTのデフォルト値はtrueです。

ユーザーが保存済の検索のレイアウトに変更を加え、保存せずに続行すると、保存するようにユーザーを促す警告メッセージが表示されます。保存しないと変更は失われます。また、ユーザーが検索フィールドを追加または削除した後、保存せずに続行した場合も、警告メッセージが表示されます。

表36-2に、saveResultsLayoutとSAVE_RESULTS_LAYOUTの値およびそれらの結果実行される処理を示します。レイアウトを保存するには、MDSが構成されている必要があります。

表36-2 結果コンポーネントのレイアウト保存属性

web.xmlSAVE_RESULT_LAYOUT

問合せコンポーネントsaveResultsLayout

結果として生じるアクション

true

常時

レイアウトが保存される

true

なし

保存されない

true

未定義

レイアウトが保存される

false

常時

レイアウトが保存される

false

なし

保存されない

false

未定義

保存されない

図36-13に、保存済の検索の名前の入力フィールドと、「デフォルトとして設定」および「自動的に実行」のチェックボックス選択がある「保存済の検索の作成」ダイアログを示します。

図36-13 実行時の「保存済の検索」ダイアログ・ウィンドウ

表36-1に、保存済の検索、その作成方式および可用性のシナリオを作成者別に示します。

表36-3 設計時および実行時の保存済の検索

作成者

設計時にビュー基準として作成

実行時に「保存」ボタンを使用して作成

開発者

開発者による保存済の検索(システム検索)は、アプリケーション開発時に作成され、通常はソフトウェア・リリースの一部に含まれます。これらの検索は、設計時にビュー基準として作成されます。通常、アプリケーションのすべてのユーザーが利用可能であり、「保存済の検索」ドロップダウン・リストの下部に表示されます。

管理者

管理者による保存済の検索は、デプロイ前にサイト管理者が作成します。これらの検索は、サイトを一般のエンド・ユーザーが利用可能になる前に作成されます。管理者は、設計時に適切なロールでログインしてJDeveloperを使用し、保存済の検索(またはビュー基準)を作成できます。これらの保存済の検索(またはビュー基準)は、「保存済の検索」ドロップダウン・リストの下部に表示されます。

エンド・ユーザー

エンド・ユーザーによる保存済の検索は、実行時に問合せフォームの「保存」ボタンを使用して作成します。これらの検索は、作成したユーザーのみが利用可能です。エンド・ユーザーの保存済の検索は、「保存済の検索」ドロップダウン・リストの最上部に表示されます。

プロパティ・インスペクタに記載されているとおりにrunQueryAutomaticallyプロパティを使用して、保存済の検索により問合せが自動的に実行されるかどうかを指定できます。このプロパティをallSavedSearchesに設定すると、すべてのシステムおよびユーザー作成の保存済の検索が、問合せコンポーネントが最初にロードされたとき、保存済の検索に変更が加えられたとき、またはリセット・ボタンが押されたときに自動的に実行されます。runQueryAutomaticallyプロパティをsearchDependentに設定すると、設計時にその特定の問合せを自動的に実行するかどうかを指定できます。searchDependentがデフォルト値です。

runQueryAutomaticallyプロパティがsearchDependentに設定されたユーザー作成の新しい保存済の検索については、図36-13に示すように、「保存済の検索の作成」ダイアログは「自動的に実行」オプションがデフォルトで設定された状態で表示されます。runQueryAutomaticallyプロパティがallSavedSearchesに設定されたユーザー作成の新しい保存済の検索については、「保存済の検索の作成」ダイアログには「自動的に実行」オプションは表示されず、暗黙的に設定されます。

図36-14に示すように、エンド・ユーザーは「保存済の検索」ドロップダウン・リストの「パーソナライズ」機能を使用して「保存済の検索のパーソナライズ」ダイアログを表示し、保存済の検索を管理できます。

エンド・ユーザーは、「パーソナライズ」機能を使用して次の操作を実行できます。

- 保存済検索の更新。
ユーザーは、検索基準の追加や削除、演算子の更新、値の更新、論理積の修正、および既存の保存済検索名を使用した検索基準の保存(既存の保存済検索をオーバーライドする)を実行できます。

- 保存済検索の削除(現在アクティブな保存済検索を含む)
ユーザーは、デフォルトの保存済検索を削除できます。この場合、次のUSERレベルの保存済検索がデフォルトになります。

- 既存の保存済検索の複製

- 保存済の検索のデフォルトとしての設定

- 保存済の検索の自動実行の設定

- 「保存済の検索」ドロップダウン・リストでの保存済の検索の表示または非表示の設定

図36-14 「保存済の検索のパーソナライズ」ダイアログ

注意:

ビュー基準アイテムの値をプログラム的に変更している場合は、ViewCriteria.saveState()メソッドを呼び出して、searchRegionバインディングにより、ビュー基準アイテムの値が設計時に指定された値にリセットされないようにする必要があります。

問合せ検索フォームは、名前付きビュー基準項目を「データ・コントロール」パネルからページにドロップして作成します。ドロップするものとして、検索パネルのみ、検索パネルと結果表、検索パネルとツリー表のいずれかを選択できます。

検索パネルを表とともにドロップすることにした場合、ダイアログでフィルタ処理オプションを選択し、表をフィルタ処理された表にすることができます。

通常は、問合せ検索パネルとともに結果表またはツリー表をドロップします。JDeveloperでは、結果表またはツリー表が自動的に作成され、問合せパネルと関連付けられます。

問合せパネルのみをドロップし、結果コンポーネントが必要な場合、または結果を表示するコンポーネントがすでに存在する場合、問合せパネルのResultsComponentIdと結果コンポーネントのIdを一致させる必要があります。

注意:

名前付きビュー基準をページにドロップすると、そのビュー基準は最初の検索フォームのベースとなります。そのデータ・コレクションに定義された他のすべてのビュー基準も「保存済の検索」ドロップダウン・リストに表示されます。その後、ユーザーは、任意のビュー基準検索フォームとエンド・ユーザーが作成した任意の保存済の検索を選択できます。

36.2.1 結果表またはツリー表付きの問合せ検索フォームの作成方法

検索フォームを作成するには、ビュー基準を「データ・コントロール」パネルからページにドラッグ・アンド・ドロップします。結果表付きとするか、問合せパネルのみとするかを選択できます。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「問合せ検索フォームの作成」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. ビュー・オブジェクトを作成します。ビュー・オブジェクトの詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」および「結合問合せ結果での複数表の使用」を参照してください。

2. ビュー基準に基づいて検索フォームを作成する場合は、ビュー基準を作成します。コレクションに問合せ可能なすべての属性を含む暗黙的ビュー基準を使用することもできます。ビュー基準の詳細は、「名前付きビュー基準の処理」を参照してください。

3. 検索フォームのデフォルトのプロパティを設定します。検索フォームのデフォルト状態の設定の詳細は、「ビュー基準に検索フォーム・プロパティを設定する方法」を参照してください。ビュー基準の作成方法の詳細は、「名前付きビュー基準の処理」を参照してください。

結果表またはツリー表付きの問合せ検索フォームを作成するには:

1. 「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。

2. 名前付きビュー基準項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

3. 図36-15に示すように、ポップアップ・メニューから、「作成」→「問合せ」→「表付きADF問合せパネル」または「作成」→「問合せ」→「ツリー表付きADF問合せパネル」を選択します。

図36-15 「データ・コントロール」パネルの「問合せ」ポップアップ・メニュー

4. 「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。フィルタ処理オプションを選択した場合、表はフィルタ処理された表になります。

フォームの作成後、一部のプロパティの設定やカスタム機能の追加が可能です。これを行う方法の詳細は、「検索フォーム・プロパティの設定」を参照してください。

36.2.2 問合せ検索フォームを作成した後で結果コンポーネントを追加する方法

検索フォームを作成するには、ビュー基準を「データ・コントロール」パネルからページにドラッグ・アンド・ドロップします。結果表付きとするか、問合せパネルのみとするかを選択できます。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「問合せ検索フォームの作成」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. ビュー・オブジェクトを作成します。

2. ビュー基準に基づいて検索フォームを作成する場合は、ビュー基準を作成します。コレクションに問合せ可能なすべての属性を含む暗黙的ビュー基準を使用することもできます。

3. 検索フォームのデフォルトのプロパティを設定します。検索フォームのデフォルト状態の設定の詳細は、「ビュー基準に検索フォーム・プロパティを設定する方法」を参照してください。ビュー基準の作成方法の詳細は、「名前付きビュー基準の処理」を参照してください。

問合せ検索フォームを作成し、別のステップで結果コンポーネントを追加するには:

1. 「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。

2. 名前付きビュー基準項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

3. 図36-15に示すように、ポップアップ・メニューから、「作成」→「問合せ」→「ADF問合せパネル」を選択します。

4. まだ結果コンポーネントがない場合、ビュー基準に関連付けられているデータ・コレクションをコンポーネントとしてドロップします。

5. 表の「プロパティ」ウィンドウで、「ID」フィールドの値をコピーします。

6. 問合せパネルの「プロパティ」ウィンドウで、問合せのResultsComponentIdフィールドに、表のIDの値を貼り付けます。

検索フォームの作成後、一部のプロパティの設定やカスタム機能の追加が可能です。詳細は、「検索フォーム・プロパティの設定」を参照してください。

36.2.3 保存済の検索をMDSに保存する方法

保存済の検索をMDSに保存するには、adf-config.xmlファイルに/persdefネームスペースを定義する必要があります。また、metadatapathの指定など、通常のMDS構成を行うことも必要です。次の例は、/persdefネームスペースを定義したadf-config.xmlファイルを示しています。

<persistence-config>
<metadata-namespaces>
<namespace path="/persdef" metadata-store-usage="mdsstore"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="mdsstore" deploy-target="true"
default-cust-store="true">
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>

追加した保存済の検索をユーザーが次にログインしたときに使用できるようにするには、cust-configをMDS構成の一部として定義する必要があります。cust-configおよびMDSの設定の詳細は、「カスタマイズ・クラスの作成方法」を参照してください。

結果コンポーネントのレイアウトも保存する場合は、アプリケーションにADF PageFlow RuntimeライブラリとADF Controller Runtimeライブラリをインストールしておく必要があります。プロジェクトのテクノロジ・スコープにADFページ・フローが含まれるように設定するか、ADF Page Flowアプリケーションのアプリケーション・テンプレートを使用して、これらのライブラリを自動的にインクルードします。

36.2.4 検索フォームの名前付きバインド変数に関する必知事項

検索フォームで使用されるビュー基準でリテラル・オペランドを指定するかわりに、名前付きバインド変数を指定できます。名前付きバインド変数は、実行時に値が変化するパラメータのような動作をします。SQL文を変更する必要はありません。この変数をビュー基準で使用するには、まず、ビュー・オブジェクトで定義する必要があります。

ビュー基準でリテラル・オペランドを指定したときに、この値を空白のままにしておくと、SQLプレビューには表示されません。実行時に検索フォームとしてビュー基準を適用すると、その属性は空の入力検索フィールドとしてレンダリングされます。このリテラル・オペランドに対する値を指定した場合、SQLプレビューにより、このオペランドに対応したSQL句が生成されます。実行時に検索フォームとしてビュー基準が適用されたとき、ビュー基準で指定した値が入力検索フィールドに表示されたとしても、SQL文は自動的に適用されません。ユーザーが「検索」をクリックするまで(または、auto-executeがtrueに設定されるまで)、このSQL文は適用されません。

ビュー基準で定義された問合せで名前付きバインド変数が使用された場合、SQLプレビューには、バインド変数とともにWHERE句が表示されます。実行時に検索フォームとしてビュー基準が適用された場合、バインド変数名ではなく、属性名に基づいて、バインド変数がプロンプトおよび入力検索フィールドとともにレンダリングされます。名前付きバインド変数の入力フィールドは、NULL値、デフォルト値、別のページから受け取った値など以前の処理でロードされた値のいずれかの状態となります。ユーザーは他の検索基準と同様に、名前付きバインド変数の値を入力できます。検索を実行すると、名前付きバインド変数の値は、SQL問合せ文で定義したように他の基準で評価されます。

注意:

リテラル値での検索フォームのSQLインジェクションの可能性を回避するために、adf-config.xmlファイルのuseBindVarsForViewCriteriaLiteralsプロパティをtrueに設定して、すべての入力検索フィールドでバインド変数を強制的に使用できます。デフォルト値はtrue。trueに設定されている場合、アプリケーションの入力検索フィールドは、問合せコンポーネントの関連ビュー基準に基づいてリテラル・オペランドによって定義されたデフォルト値を表示します。

adf-config.xmlファイルの詳細は、「adf-config.xml」を参照してください。

概要エディタを使用して、このプロパティを編集することもできます。adf-config.xmlの概要エディタで、「モデル」タブをクリックするか、「ViewCriteriaリテラルにバインド変数を使用」チェックボックスを選択または選択解除します。

バインド変数が同じビュー基準で複数回使用されている場合、バインド変数は出現するたびに、1つの入力フィールドとしてレンダリングされます。すべての入力フィールドの背後にはバインド変数が1つしかありませんから、すべてのフィールドの値が同期されます。たとえば、同じバインド変数を3回使用するビュー基準を指定した場合、3つの入力フィールドがレンダリングされます。ユーザーが1つの入力フィールドに値を入力すると、その他2つの入力フィールドにも同じ値が入ります。このようにバインド変数を使用すると、ユーザーは同じ値を何回も入力する必要がなくなります。

バインド変数は、ベース行からLOV検索フォームの検索に値を渡すためにも使用できます。

また、たとえば、顧客IDを別のページに渡して、さらに詳細な処理をする場合など、あるページから別のページにパラメータ値を渡すときにもバインド変数を使用できます。さらに、SQL文の構成によっては、名前付きバインド変数を使用すると、新しい文を準備する必要が少なくなる、つまりデータベースを再解析する必要がなくなるため、問合せの速度が向上する可能性があります。名前付きバインド変数の作成および使用の詳細は、「バインド変数の使用」を参照してください。

たとえば、listCustomerAddressesビュー基準のWHERE句は、AssociatedOwnerIdがparamCustomerId名前付きバインド変数の値と同じであるかどうかを確認します。このビュー基準は、AddressesLookupVOビュー・オブジェクト内にあります。図36-16に、「ビュー基準の編集」で定義したlistCustomerAddressesビュー基準を示します。

図36-16 名前付きバインド変数のあるビュー基準

名前付きバインド変数のあるビュー基準の問合せ検索フォームは、inputTextコンポーネントを使用してその変数の検索フィールド付きでレンダリングされます。図36-17は、inputTextコンポーネントとして表示されているAssociatedOwnerId検索フィールドを示しています。

図36-17 名前付きバインド変数がある問合せ検索フォーム

36.2.5 デフォルトの検索バインディング動作に関する必知事項

検索バインディングは、実行時、検索フォームに対してモデルドリブンの動作を提供します。検索バインディングは、特定のイテレータ、およびそのイテレータのビュー基準に関連付けられていて、その実行時デフォルトはそれぞれ、検索バインディングの「バインド」プロパティと「基準」プロパティで指定されます。検索バインディングの動作は、「自動的に問合せ」コントロールのヒントによって異なります。名前付きビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。

タスク・フローで初めて検索フォームがレンダリングされたときの検索バインディングの実行時の動作(初期のAutoQuery-or-ClearRowSet動作)は次のようになります。

- 「自動的に問合せ」がtrueに設定されている場合: タスク・フローで検索バインディングが初期化されたときに、検索バインディングにより、自動的にイテレータが実行されます。ユーザーには、ビュー基準に基づいた検索結果が提示されます。

- 「自動的に問合せ」がfalseに設定されている場合: 検索バインディングにより、イテレータに関係する行セットがクリアされます。ユーザーには空の検索結果コンポーネントが提示されます。ユーザーはここから検索基準を入力し、「検索」ボタンをクリックして、検索を実行できます。

「自動的に問合せ」コントロールのヒントは、名前付きビュー基準に対してのみ、宣言的に使用できます。「すべての問合せ可能な属性」ビュー基準に対して、このビュー基準のAPIインタフェースでsetProperty()メソッドを使用し、実行時にヒントを構成することができます。また、このメソッドを使用して、名前付きビュー基準にヒントを設定することもできます。このメソッドで、ViewCriteriaHints.CRITERIA_AUTO_EXECUTEプロパティをtrueに設定します。

ユーザーが「保存済の検索」ドロップダウン・リストから別のビュー基準を選択して、検索フォームを変更した場合の実行時の動作は次のようになります。

- 「自動的に問合せ」がtrueに設定されている場合: 検索バインディングにより、新しいビュー基準の適用後、自動的にイテレータが実行されます。ユーザーには、新たに選択された保存済の検索結果が提示されます。

- 「自動的に問合せ」がfalseに設定されている場合: 検索バインディングにより、新しいビュー基準のみが適用され、既存の検索結果はすべてそのまま残されます。ユーザーには、以前の検索結果が提示されます。

自動的に、またはユーザーが「検索」ボタンをクリックしたことにより、検索バインディングが問合せを実行した場合、検索バインディングのqueryPerformedプロパティはtrueに評価されます。検索フォームで「リセット」ボタンをクリックすると、ビュー基準がリセットされ、queryPerformedプロパティがfalseに設定されます。

ユーザーが検索バインディングのデフォルト動作をカスタマイズできるようにするために、TrackQueryPerformedおよびInitialQueryOverriddenという2つのプロパティが用意されています。TrackQueryPerformedプロパティとInitialQueryOverriddenプロパティは、「プロパティ」ウィンドウで設定できます。

検索バインディングのTrackQueryPerformedプロパティは、検索バインディングが実行時のqueryPerformedプロパティをページ・フロー・レベル、個々のページ・レベル、ページ・フラグメント・レベルのいずれで管理するかを制御します。TrackQueryPerformedに有効な値はpageFlowとpageで、デフォルトはpageFlowです。検索バインディングは次のように動作します。

- TrackQueryPerformedがpageFlowに設定されている場合、queryPerformedはページ・フロー1回につき一度初期化され、ページ・フロー・レベルで追跡されます。ユーザーは検索フォーム・ページ以外の場所に移動し、ページ・フローの有効期限が切れる前にこのページに戻りますが、queryPerformedフラグの値は変わりません。

- TrackQueryPerformedがpageに設定されている場合、queryPerformedはユーザーがこのページ、またはページ・フラグメントに移動するたびに初期化されます。これは、そのページに初めてナビゲートされたとき、およびページ・フロー内の別のページから返されたときに発生します。

検索バインディングのTrackQueryPerformedがpageFlowに設定されている場合、最初のAutoQuery-or-ClearRowSet動作は、ページ・フロー中に一度、実行されます。対照的に、TrackQueryPerformedがpageに設定されている場合、最初のAutoQuery-or-ClearRowSet動作はユーザーがページまたはページ・フラグメントにアクセスするたびに実行されます。

検索バインディングのInitialQueryOverriddenプロパティは、ページ・フローで検索バインディングが初めて使用されたときに、最初のAutoQuery-or-ClearRowSet動作を抑制すべきかどうかを制御します。InitialQueryOverriddenがtrueの場合、true、false、ブール値のEL式を含む、すべての有効な値が抑制されます。デフォルト値はfalseです。

InitialQueryOverriddenプロパティをtrueに設定した場合、問合せを実行するためのカスタム・アプリケーション・ロジックを記述しなければなりません。通常、この問合せは、コードがなんらかのビュー基準を適用、バインド変数を設定、またはプログラムで問合せの設定を実行した後で行う必要があります。カスタム・コードが、InitialQueryOverriddenがtrueに設定されているときに期待されているとおりの問合せを実行できなかった場合、「自動的に問合せ」がfalseに設定されていない限り、フレームワークは、イテレータ・バインディング参照のあるユーザー・セッション中に初めて暗黙的な問合せを実行します。これは「自動的に問合せ」がfalseに設定されていない場合、イテレータ・バインディングのデフォルトexecuteQueryIfNeeded動作が有効になり、問合せが実行されるために起こります。

InitialQueryOverriddenがtrue、またはブール値のtrueに評価されるとき、ページ・フローで初めて検索バインディングが使用されると、最初のAutoQuery-or-ClearRowSet動作は抑制されます。TrackQueryPerformedがpageFlowに設定されている場合、この検索バインディングについて発生する最初のAutoQuery-or-ClearRowsSet動作のみ抑制されます。

対照的に、検索バインディングのTrackQueryPerformedプロパティがpageに設定されている場合、最初のAutoQuery-or-ClearRowSet動作のみが抑制されます。その後、ユーザーが同じページ(またはページ・フラグメント)に戻ったため発生した最初のAutoQuery-or-ClearRowSet動作は、InitialQueryOverriddenプロパティによる影響を受けません。

検索バインディングによる、最初のAutoQuery-or-ClearRowSet動作の実行を回避する必要がある場合は、TrackQueryPerformedをpageFlowに設定したまま、InitialQueryOverriddenをtrueに設定します。

検索バインディングのqueryPerformedプロパティの参照に、イテレータのRefreshConditionプロパティを使用してはいけません。これにより、検索バインディングの問合せが実行される前に、このイテレータの行セットに誤って新しい行が作成されるのを防ぐことができます。

36.2.6 依存基準に関する必知事項

ある検索基準が別の基準の値に依存しているという状況があります。たとえば、あるバグ・データベースに、ComponentおよびSubomponent検索基準を持つ検索フォームがあり、これらの検索基準は両方ともLOVとして定義されているとします。ユーザーがComponent検索基準から値を選択したときに、Subomponentをフィルタし、ユーザーの選択肢となる適切な検索リストを移入できるように、この値はモデルに送信されなければなりません。

依存関係を持つ検索基準を使用している場合、ルートと依存基準の基礎となるビュー属性のAuto Submitコントロールのヒントをtrueに設定する必要があります。カスタム・リスナーを作成し、部分的送信をトリガーしてモデルを更新し、問合せコンポーネントがルート基準の値の変更を検知したときに、検索パネルをリフレッシュします。標準のQueryOperationListenerはこのイベント・タイプに対応できないため、カスタム・リスナーを作成する必要があります。QueryOperationListenerインタフェースを使用して、カスタムQueryOperationListenerクラスを作成することができます。その後、このクラスをマネージドBeanに実装するか、またはJSFページに直接設定して登録します。

36.2.7 問合せフォーム作成時の処理

問合せ検索フォームをページにドロップすると、ページにaf:queryタグが作成されます。表付き問合せまたはツリー表付き問合せをドロップした場合、af:queryタグの後にaf:tableタグまたはaf:treeTableタグが続きます。

af:queryタグの下には問合せのプロパティを定義する複数の属性があります。これには次のものがあります。

- 問合せを一意に識別するid属性。

- 問合せ結果が表示されるコンポーネントを識別するresultsComponentId属性。通常、これは問合せとともにページにドロップされた表またはツリー表です。この値は、別の結果コンポーネントのidに変更できます。詳細は、「問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。

ページ定義ファイルのexecutablesセクションに、iteratorおよびsearchRegionエントリが作成されます。次の例は、ページ定義ファイルのサンプル・コードを示しています。このコードは、BackOfficeAppModuleDataControlのCustomersコレクションから、CustomerViewCriteriaをページにドロップしたときに作成されます。

ページ定義ファイルのexecutableセクションでは、プロパティが次のように設定されます。

- イテレータbindsプロパティはデータ・コレクション名に設定します。この例では、この値にCustomersを設定します。

- イテレータidプロパティはデータ・コレクション・イテレータに設定します。この例では、この値にCustomersIteratorを設定します。

- そのデータ・コレクションについて、複数のビュー基準が定義されている場合、searchRegion Criteriaプロパティは、ドロップされたビュー基準の名前に設定されます。この例では、この値にCustomerViewCriteriaを設定します。定義されているビュー基準が1つのみの場合、Criteriaプロパティはありません。

- searchRegionのBindsプロパティは、iterator idプロパティと同じ値に設定されます。この例では、この値にCustomersIteratorを設定します。

- searchRegionのidプロパティには、ビュー基準とQueryを連結した名前が設定されます。この例では、この値にCustomerViewCriteriaを設定します。

問合せを表またはツリーとともにページにドロップした場合は、ページ定義ファイルのbindingsセクションにtree要素が追加され、Iterbindingプロパティが検索イテレータに設定されます。この例では、この値にCustomersIteratorを設定します。これは、executableセクションで定義されたイテレータと同じものでなければなりません。

<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel" version="12.1.2.66.41" id="searchPageDef"
Package="oracle.summit.view.pageDefs">
<parameters/>
<executables>
<variableIterator id="variables"/>
<iterator Binds="Customers" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl" id="CustomersIterator"/>
<searchRegion Criteria="CustomerViewCriteria"
Customizer="oracle.jbo.uicli.binding.JUSearchBindingCustomizer"
Binds="CustomersIterator" id="CustomerViewCriteriaQuery"/>
</executables>
<bindings>
<tree IterBinding="CustomersIterator" id="Customers">
<nodeDefinition DefName="oracle.summit.model.views.CustomerVO"
Name="Customers0">
<AttrNames>
<Item Value="Id"/>
<Item Value="Name"/>
<Item Value="City"/>
<Item Value="State"/>
<Item Value="CountryId"/>
<Item Value="LastName"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>
</pageDefinition>

36.2.8 実行時に行われる処理: 検索フォーム

実行時には、検索フォームはページ上の検索パネルとして表示されます。検索パネルは、対応するビュー基準が作成されたときのモードのコントロール・ヒントに応じて、基本モードまたは詳細モードのいずれかで表示されます。「保存済の検索」ドロップダウン・リストには、有効(「リストに表示」コントロール・ヒントが有効)なビュー基準がすべて含まれます。「すべてに一致」または「いずれかに一致」結合ラジオ・ボタンが有効化されることがあります。

検索基準フィールドは、ビュー基準に定義された検索基準ごとにレンダリングされます。ビュー・オブジェクトの「デフォルトのリスト・タイプ」コントロール・ヒントがLOVまたは選択リスト・コンポーネントとして宣言されている場合、検索基準フィールド・コンポーネントは表36-1に示すようになります。

ユーザーが検索基準を入力して「検索」をクリックすると、ビュー基準に対する問合せが実行され、関連付けられた表、ツリー表またはコンポーネントに結果が表示されます。

36.3 検索フォーム・プロパティの設定

問合せ検索フォームは、ビュー・オブジェクトで定義されたビュー基準に基づいています。ビュー基準の作成時には、検索フォーム・プロパティの一部も指定します。後で名前付き基準をページにドロップして問合せコンポーネントを作成する場合、その他の検索フォーム・プロパティも指定できます。

ビュー・オブジェクトに対して設定可能な検索フォームのプロパティには、問合せパネルでの関連フィールドと依存フィールドのグループ化も含まれています。ビュー・オブジェクトでのヒント設定の詳細は、「UIカテゴリ・ヒントを定義する方法」を参照してください。

ビュー基準の作成時に設定可能な検索フォーム・プロパティは、次のとおりです。

- 基本モードまたは詳細モードのデフォルトのモード

- ページのロード時の自動問合せ実行

- 検索基準フィールドのレンダリング

- LOVとして定義された属性の複数選択を有効化

問合せコンポーネントがJSFページに追加された後に設定可能な検索フォーム・プロパティは、次のとおりです。

- 結果表または結果コンポーネントのid

- 「基本」ボタンまたは「詳細」ボタンの表示または非表示

- モード・ボタンの位置

- デフォルト、シンプルまたは圧縮の表示モード

ビュー・オブジェクトの作成時に設定可能な検索フォーム属性プロパティは、次のとおりです。

- timestamp属性に対するtimezoneコントロール・ヒント

36.3.1 ビュー基準に検索フォーム・プロパティを設定する方法

ビュー基準の作成時に、複数のプロパティの初期状態を宣言的に設定できます。図36-18に、デフォルト・オプションの設定に使用する「ビュー基準の編集」ダイアログを示します。ビュー基準の詳細は、「名前付きビュー基準の処理」を参照してください。

図36-18 「ビュー基準の作成」ダイアログ

問合せ検索フォームのデフォルト・モードとして「基本」または「詳細」のいずれかを選択する必要があります。デフォルトは「基本」です。

また、個々の検索基準フィールドが使用できるのは、基本モードのみ、詳細モードのみ、両方のモードのいずれか、あるいは表示しないかを宣言する必要があります。検索基準フィールドが「基本」モードのみで宣言されている場合、ユーザーが「詳細」モードに切り替えた場合は表示されず、逆も同様です。フィールドが両方のモードに対して宣言されている場合、両方のモードで表示されます。検索基準フィールドのレンダリングのデフォルトは、すべてのモードです。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「検索フォーム・プロパティの設定」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「名前付きビュー基準の処理」の説明に従い、問合せ検索フォームのビュー基準を作成します。

デフォルト・モードと検索基準フィールドの表示オプションを設定するには:

1. 「アプリケーション」ウィンドウで、問合せ検索フォーム用に作成したビュー基準を含むビュー・オブジェクトをダブルクリックします。

2. ビュー・オブジェクトの概要エディタで、「ビュー基準」ナビゲーション・タブをクリックします。

3. 「ビュー基準」ページで、リストからビュー基準を選択して、「編集」をクリックします。

4. 「ビュー基準の編集」ダイアログで、基準定義ページの「UIヒント」タブをクリックします。

5. 「表示されたモード」ドロップダウン・リストで、「すべて」、「基本」、「詳細」または「なし」を選択します。

6. 「ビュー基準の編集」ダイアログで、基準UIヒントタブをクリックします。

7. 「検索リージョン・モード」ドロップダウン・リストから、「基本」または「詳細」を選択します。

8. 「基準アイテムUIのヒント」セクションで、設定する基準アイテムを選択します。

9. 「演算子の表示」ドロップダウン・リストで常に表示、基本モード、表示しない、詳細モードまたは表示しないを選択して、このビュー基準に対応する問合せコンポーネントにより表示される演算子を、ユーザーが変更できるかどうかを指定します。

ユーザーが詳細モードから基本モードに問合せコンポーネントのモードを変更したときに、問合せコンポーネントにより表示される演算子は、「演算子の表示」の設定方法によって異なります。問合せコンポーネントは、ユーザーが演算子の表示を常に表示に設定して両方のモードで演算子の完全なリストを表示できるようにした場合にのみ、2つのモード間でユーザーの選択を保持します。ただし、「演算子の表示」を詳細モードに設定して詳細モードでのみ完全な演算子リストを表示する場合は、ユーザーが選択を行い、基本モードに切り替えた後に演算子はビュー基準で定義したデフォルトに戻るため、ユーザーの選択が変更されたように見えます。ユーザーが定義した演算子だけを使用してビュー基準を実行する場合は、表示しないを選択します(この場合、演算子の完全なリストは基本モードでも詳細モードでも表示されません)。

10. 「OK」をクリックします。

36.3.2 問合せコンポーネントに検索フォーム・プロパティを設定する方法

問合せ検索フォームをページにドロップした後に、「プロパティ」ウィンドウで他のフォーム・プロパティを編集できます(図36-19を参照)。次のような共通プロパティを設定できます。

- 「基本」または「詳細」モード・ボタンの有効化または無効化

- 問合せ検索フォームのIDの設定

- 結果表などの結果コンポーネントのIDの設定

- デフォルト、シンプルまたは圧縮の表示モードの選択

- criterionFeaturesの設定。すべての文字列ベースの検索基準で大/小文字を区別するにはmatchCaseDisplayedに、すべての基準を表示するにはrequiredDisplayedに設定します。

図36-19 「問合せ」コンポーネントの「プロパティ」ウィンドウ

一般的なオプションの1つに、「基本」または「詳細」ボタンの表示または非表示があります。その他のいくつかのプロパティの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の問合せコンポーネントの追加方法に関する項を参照してください

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「検索フォーム・プロパティの設定」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

問合せフォームで「基本」または「詳細」ボタンを有効化または非表示にするには:

1. 「構造」ウィンドウで「af:query」をダブルクリックします。

2. 「プロパティ」ウィンドウで、「外観」タブをクリックします。

3. 「基本」または「詳細」モード・ボタンを有効化するには、ModeChangeVisibleフィールドで「True」を選択します。「基本」または「詳細」モード・ボタンを非表示するには、ModeChangeVisibleフィールドで「False」を選択します。

36.3.3 Timestamp属性に対するTimezoneコントロール・ヒントの設定方法

問合せにDate属性が含まれる場合、その属性が定義されているビュー・オブジェクトまたはエンティティ・オブジェクトのコントロール・ヒントを使用してそのtimezoneを設定できます。たとえば、従業員のHiredateに対して、従業員が勤める支社に応じた適切なtimezoneを設定できます。

始める前に:

「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。

コントロール・ヒントを使用してビュー・オブジェクトのtimestamp属性をカスタマイズするには:

1. 「アプリケーション」ウィンドウで、ビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、コントロール・ヒントを使用してカスタマイズするDate属性を選択します。

3. 「UIヒント」タブをクリックして、「タイムゾーン」プロパティを開きます。

4. 「タイムゾーン」ドロップダウン・リストから、タイムゾーンを選択します。

タイムゾーン値は、協定世界時(UTC)からの差分(+/-)の時間として一覧表示されます。

36.3.4 カスタム演算子の作成方法

ビュー・オブジェクトXMLファイルにコードを追加すると、各ビュー基準項目にカスタム演算子を作成できます。たとえば、日付属性を処理するmore than a year(現在の日から365日後)という演算子を新規に作成できます。

ビュー・オブジェクトの属性に応じたカスタム演算子を追加するには、その属性用のコードをビュー・オブジェクトのXMLファイルに追加します。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「検索フォーム・プロパティの設定」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

カスタム演算子を追加するには:

1. 「アプリケーション」ウィンドウで、カスタム演算子を追加するビュー基準のビュー・オブジェクトを選択します。

2. 概要エディタで、「ソース」タブをクリックします。

3. XMLエディタで、ビュー基準属性のコードを特定し、ViewCriteriaItemグループの最後の項目の後にCompOperコード文を追加します。例36-1は、ビュー基準のコードを示しています。CompOperコード文を太字で表示しています。

CompOperプロパティは次のとおりです。

- Name: 操作のidを指定します。

- ToDo: このカスタム演算子を追加するには1に設定します。演算子を削除するには-1に設定します。

- OperDescStrCode: 手順4で説明しているように、説明の文字列にマップするために、メッセージ・バンドルで使用したidを指定します。

- Oper: SQL文でこの操作を示すために、プログラム的に使用される値に設定します。例36-1では、Operが>Yに設定されています(1年より長いことを示します)。

- MinCardinality: 入力範囲がある場合、範囲の最小値を設定します。たとえば、範囲が月である場合、この値を1に設定する必要があります。範囲がない場合、0に設定します。

- MaxCardinality: 入力範囲がある場合、範囲の最大値を設定します。たとえば、範囲が月である場合、この値を12に設定する必要があります。範囲がない場合、0に設定します。

- TransientExpression: カスタム演算を実行するための式を設定します。例36-1では、この式は![CDATA[return " > SYSDATE -365"]]です。これは文字列" > SYSDATE -365"を戻します。

4. ビュー・オブジェクトのメッセージ・バンドル・ファイルを開き、手順3でビュー・オブジェクトXMLに定義したOperDescStrCode識別子を使用してカスタム演算子のエントリを追加します。

例36-2は、例36-1に示したLastUpdateDateカスタム演算子のメッセージ・バンドル・コードを示しています。

例36-1 ビュー・オブジェクトXMLへのカスタム演算子コードの追加

<ViewCriteriaRow
Name="vcrow50"
UpperColumns="1">
<ViewCriteriaItem
Name="LastUpdateDate"
ViewAttribute="LastUpdateDate"
Operator="="
Conjunction="AND"
Required="Optional">
<CompOper
Name="LastUpdateDate"
ToDo="1"
OperDescStrCode="LastUpdateDate_custOp_grt_year"
Oper=">Y"
MinCardinality="0"
MaxCardinality="0" >
<TransientExpression><![CDATA[ return " < SYSDATE - 365"
]]></TransientExpression>
</CompOper>
</ViewCriteriaItem>

例36-2 メッセージ・バンドルへのLastUpdateDateのカスタム演算子のエントリの追加

public class AvailLangImplMsgBundle extends JboResourceBundle {
static final Object[][] sMessageStrings =
{
{ "LastUpdateDate_custOp_grt_year", "more than a year old"
},

36.3.5 標準演算子の削除方法

ビュー基準アイテムから、標準演算子を削除できます。たとえば、標準演算子であるbeforeをリストから削除できます。

標準演算子のリストは、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。

ビュー・オブジェクトの属性に応じた標準演算子を削除するには、その属性用のコードをビュー・オブジェクトのXMLファイルに追加します。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「検索フォーム・プロパティの設定」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

標準演算子を削除するには:

1. 「アプリケーション」ウィンドウで、標準演算子を削除するビュー基準のビュー・オブジェクトを選択します。

注意:

標準演算子の削除を試みる前に、ビュー基準アイテムのデフォルト演算子を削除してないかどうかを確認してください。

2. 概要エディタで、「ソース」タブをクリックします。

3. XMLエディタで、ビュー基準属性のコードを特定し、ViewCriteriaItemグループの最後の項目の後にCompOperコード文を追加します。

次の例では、CompOperコード文を太字で表示しています。この例のコードは、BEFORE演算子をLastUpdateDate属性の演算子のリストから削除します。

<ViewCriteriaRow
Name="vcrow50"
UpperColumns="1">
<ViewCriteriaItem
Name="LastUpdateDate"
ViewAttribute="LastUpdateDate"
Operator="="
Conjunction="AND"
Required="Optional">
<CompOper
Name="LastUpdateDate"
ToDo="-1"
Oper="BEFORE"
</CompOper>
</ViewCriteriaItem>

CompOperプロパティは次のとおりです。

- Name: 操作のidを指定します。

- ToDo: 演算子を削除するには-1に設定します。演算子を追加するには1に設定します。
ToDoを2に設定しないでください。すべての演算子が削除されます。

- Oper: リストから削除する標準演算子に設定します。

36.3.6 均一な演算子フィールド幅の設定方法

検索パネルのすべての演算子ドロップダウン・フィールドに対して均一の幅が必要な場合、次のスキニング・プロパティを設定できます。

af|query {
-tr-operator-size: constant;

}

演算子フィールドの幅を均一にすると、すべての検索フィールドの演算子および検索ボックスが垂直方向に整列され、外観が整理されます。

スキンの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

36.4 クイック問合せ検索フォームの作成

クイック問合せ検索フォームは、単一検索で十分な場合、またはフル問合せ検索を行うための起点とする場合に使用します。問合せ検索フォームおよびクイック問合せ検索フォームはどちらもADF Facesコンポーネントです。クイック問合せ検索フォームには、関連するデータ・コレクションから利用可能な検索可能属性のドロップダウン・リストとともに検索基準フィールドが1つ含まれます。通常は、関連するビュー・オブジェクトのすべての属性が検索可能属性となります。「属性の編集」ダイアログの「コントロール・ヒント」ページで、属性の「ヒントの表示」プロパティを「非表示」に設定して、属性を除外できます。ユーザーは、選択された属性または表示されるすべての属性に対して検索を実行できます。検索基準フィールド・タイプは対応する属性タイプに自動的に一致します。フォームに組み込まれた「詳細」リンクを使用すると、開発者はクイック問合せ検索フォームから詳細モードの問合せ検索フォームへの切替えを制御するマネージドBeanを作成できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。

図36-20に示すように、フォームが水平方向レイアウトとなるように構成できます。

図36-20 水平方向レイアウトのクイック問合せ検索フォーム

図36-21に示すように、垂直方向レイアウトも選択できます。

図36-21 垂直方向レイアウトのクイック問合せ検索フォーム

クイック問合せ検索フォームを使用すると、ユーザーによるコレクションの単一属性の検索が可能になります。クイック問合せ検索フォームのレイアウトは、水平または垂直に設定できます。クイック問合せ検索フォームは小さい領域のみを使用するため、ページの様々な領域に配置できます。ユーザーによるクイック問合せ検索からフル問合せ検索への切替えを可能にするマネージドBeanを作成できます。クイック問合せからマネージドBeanを使用した問合せに切り替える方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。

「結果表またはツリー表付きのクイック問合せ検索フォームの作成方法」で説明しているように、結果表またはツリー付きのクイック問合せパネルをドロップした場合、結果表が自動的に作成されます。「クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」で説明しているように、クイック問合せパネルのみをドロップした後に結果表または結果コンポーネントが必要な場合、または結果を表示するコンポーネントがすでに存在する場合、クイック問合せのIdと結果コンポーネントのpartialTrigger値を一致させる必要があります。

注意:

クイック問合せ検索は、基礎となるビュー・オブジェクトで定義されたすべての検索可能な属性のドロップダウン・リストを作成します。それらの属性の一部のみを表示する場合は、除外する属性の「表示」コントロール・ヒントを「非表示」に設定できます。ビュー・オブジェクトのコントロール・ヒントの設定の詳細は、「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。

36.4.1 結果表またはツリー表付きのクイック問合せ検索フォームの作成方法

検索可能な属性の完全セットを使用してクイック問合せ検索を作成すると同時に、表またはツリー表を結果コンポーネントとして追加できます。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「クイック問合せ検索フォームの作成」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 検索フォームのベースとなるビュー・オブジェクトを作成します。

結果表付きのクイック問合せ検索フォームを作成するには:

1. 「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。

2. All Queriable Attributes項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

3. 図36-22に示すように、ポップアップ・メニューから、「作成」→「クイック問合せ」→「表付きADFクイック問合せ」 または「作成」→「クイック問合せ」→「ツリー表付きADFクイック問合せ」を選択します。

4. 「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。フィルタ処理オプションを選択した場合、表はフィルタ処理された表になります。

5. 「OK」をクリックします。

図36-22 「データ・コントロール・パネル」パネルの「クイック問合せ」ポップアップ・メニュー

36.4.2 クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法

検索可能な属性の完全セットを使用してクイック問合せ検索を作成した後で、表またはツリー表を結果コンポーネントとして追加できます。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「クイック問合せ検索フォームの作成」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 検索フォームのベースとなるビュー・オブジェクトを作成します。

クイック問合せ検索フォームを作成し、別のステップで結果コンポーネントを追加するには:

1. 「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。

2. All Queriable Attributes項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

3. ポップアップ・メニューから、「作成」→「クイック問合せ」→「ADFクイック問合せパネル」を選択します。

4. まだ結果コンポーネントがない場合、ビュー基準に関連付けられているデータ・コレクションをコンポーネントとしてドロップします。

5. クイック問合せパネルの「プロパティ」ウィンドウで、「ID」フィールドの値をコピーします。

6. 結果コンポーネント(表など)の「プロパティ」ウィンドウで、「PartialTriggers」フィールドに値を貼り付けるか、値を入力します。

36.4.3 クイック問合せのレイアウト書式を設定する方法

デフォルトのレイアウト書式は垂直方向です。レイアウト・オプションは、「プロパティ」ウィンドウで変更できます。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「クイック問合せ検索フォームの作成」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

レイアウトを設定するには:

1. 「構造」ウィンドウで「af:quickQuery」をダブルクリックします。

2. 「プロパティ」ウィンドウの「共通」ページで、ドロップダウン・リストから「レイアウト」フィールドを選択して、「デフォルト」、「水平」、「垂直」のいずれかを指定します。

36.4.4 クイック問合せ検索フォームの作成時の処理

クイック問合せ検索フォームをページにドロップすると、JDeveloperはaf:quickQueryタグを作成します。クイック問合せと表またはツリー表をドロップした場合、af:tableタグまたはaf:treeTableタグも追加されます。

af:quickQueryタグの下にはクイック問合せのプロパティを定義する複数の属性およびファセットがあります。タグの一部は次のとおりです。

- クイック問合せを一意に識別するid属性。この値は結果表または結果コンポーネントのpartialTriggers値に一致するように設定する必要があります。クイック問合せと表またはツリー表をドロップすると、JDeveloperはこれらの値を自動的に割り当てます。別の結果コンポーネントに変更する方法は、「クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。

- クイック問合せのレイアウトをデフォルト、水平または垂直に指定するlayout属性。

- 「詳細」リンク(クイック問合せから問合せにモードを変更)の表示に使用するコンポーネントを指定するendファセット。この機能の作成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。

36.4.5 実行時に行われる処理: クイック問合せ

実行時に、クイック問合せ検索フォームには、単一の検索基準フィールドが選択可能な検索基準アイテムのドロップダウン・リストとともに表示されます。検索可能な基準アイテムが1つしかない場合、ドロップダウン・リスト・ボックスはレンダリングされません。表36-4に示すように、選択した検索基準タイプと互換性のある入力コンポーネントが表示されます。たとえば、検索基準タイプがDATEの場合、inputDateがレンダリングされます。

表36-4 クイック問合せ検索基準フィールド・コンポーネント

属性タイプ

レンダリングされるコンポーネント

DATE

af:inputDate

VARCHAR

af:inputText

NUMBER

af:inputNumberSpinBox

ビュー・オブジェクトの「デフォルトのリスト・タイプ」コントロール・ヒントがLOVまたは選択リスト・コンポーネントとして宣言されている場合、検索基準フィールド・コンポーネントは「値リスト(LOV)入力フィールド」の表36-1に示すようになります。

また、「検索」ボタンが入力フィールドの右側にレンダリングされます。endファセットを指定すると、endファセットのコンポーネントはすべて表示されます。デフォルトでは、endファセットには「詳細」リンクが含まれます。

36.5 スタンドアロンのフィルタ処理された検索表を名前付きビュー基準から作成

フィルタ処理された表はスタンドアロンとして作成することも、問合せ検索フォームまたはクイック問合せ検索フォームの結果表として作成することもできます。フィルタ処理された表の検索はQuery-by-Exampleに基づいており、QBEテキストまたは日付入力フィールド書式を使用します。検索基準の変更では>および<=などの文字を入力できるようにするため、入力バリデータは無効になっています。たとえば、数値列の検索基準として、>1500と入力できます。ワイルドカード文字もサポートされます。列がQBEをサポートしていない場合、検索基準入力フィールドはその列に対してレンダリングを行いません。レンダリングされる入力フィールドは属性のデータ型により決まります。たとえば、日付列には日付ピッカー・コンポーネントがレンダリングされ、値リストとして定義されている属性に対する列には対応する値リスト・コンポーネントがレンダリングされます。

フィルタ処理された表の検索基準入力値は、問合せのWHERE句を作成するためにAND演算子とともに使用されます。フィルタ処理された表が問合せ検索パネルまたはクイック問合せ検索パネルと関連付けられている場合、複合検索基準値も組み合せてWHERE句を作成します。

注意:

フィルタ処理された表を問合せコンポーネントとともに検索フォームで使用し、検索リージョンで既存の名前付き基準を使用している場合、問合せの結果はすべてのビュー基準行によって繰り返しフィルタ処理されます。たとえば、あるフィルタ処理済の表にPersonIdとDeptIdの2つのビュー基準行があるとします。最初のビュー基準行にはPersonId > 1が含まれています。ユーザーがフィルタ・フィールドに「> 100」と入力すると、2つ目のビュー基準行DeptIdを使用して、入力値の受け入れと、その後の結果のフィルタ処理が行われます。この処理は、最終的な問合せ結果に達するまですべてのビュー基準行に対して繰り返されます。

図36-23に、フィルタ処理された表を示します。ユーザーが、Idフィールドに>10などのQBE検索基準を入力すると、問合せの結果は、問合せ検索基準とフィルタ処理された表の検索基準のAND結合となります。

図36-23 フィルタ処理された表

表36-5に、検索値を変更するために使用可能なQBE検索演算子を示します。

表36-5 Query-by-Example検索基準演算子

演算子

説明

>

次より大きい

<

次より小さい

>=

以上

<=

以下

AND

および

OR

または

=

次と等しい

<>

次を含まない

!=

次を含まない

複雑な検索では問合せ検索フォームを使用しますが、フィルタ処理された表を使用して単純なQBE検索を実行することもできます。関連付けられた検索パネルのないスタンドアロンのADFのフィルタ処理された表を作成し、QBE形式の検索基準入力フィールドを使用して検索を実行できます。フィルタ処理された表の詳細は、「フィルタ処理された表と例示問合せ検索の作成方法」を参照してください。

af:tableコンポーネントのaf:columnのfilterFeature属性を使用すると、フィルタ処理可能な各列のQBE検索基準において、大文字と小文字を区別するかどうかを設定できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の表でのフィルタ処理の有効化に関する項を参照してください。

36.5.1 フィルタ処理された表と例示問合せ検索の作成方法

表の作成時に、フィルタ処理オプションが有効な場合にそのオプションを選択すると、ほとんどすべての表をフィルタ処理された表にできます。スタンドアロンのフィルタ処理された表を作成するには、次の3つの方法があります。

- 「コンポーネント」ウィンドウからページに表をドロップして、その表をデータ・コレクションにバインドしてから、フィルタ処理オプションを設定できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。

- データ・コレクションをページにドラッグ・アンド・ドロップしてフィルタ処理オプションを設定すると、フィルタ処理された表を作成できます。詳細は、「基本表の作成方法」を参照してください。

- 名前付き基準をページにドロップし、フィルタ処理された表または読取り専用のフィルタ処理された表を作成することもできます。暗黙的に作成された名前付き基準のAll Queriable Attributes、または宣言的に作成された名前付きビュー基準のどちらも使用できます。作成されるフィルタ処理された表には、検索可能属性のそれぞれに対応する列があり、各列の上に入力検索フィールドがあります。

始める前に:

問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「スタンドアロンのフィルタ処理された検索表を名前付きビュー基準から作成」を参照してください。

問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。

名前付きビュー基準を使用してフィルタ処理された表を作成するには:

1. 「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。

2. 名前付きビュー基準項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

3. ポップアップ・メニューから、「作成」→「ADFフィルタリング済表」を選択します。

4. 「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。

表はクイック問合せの作成時に自動的に作成されるため、図36-24に示すように、フィルタ処理オプションは自動的に有効になり、ユーザーは選択できません。

図36-24 フィルタ処理された表の「表の列の編集」ダイアログ

37 データバインドされたカレンダおよびカルーセル・コンポーネントの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータから、カレンダ・コンポーネントとカルーセル・コンポーネントを作成する方法について説明します。これらのコンポーネントの作成には、ADFデータ・コントロールとADF Facesコンポーネントを使用します。

この章の内容は次のとおりです。

- データバインドされたADF Facesカレンダおよびカルーセル・コンポーネントについて

- ADF Faces Calendarコンポーネントの使用方法

- ADF Faces Carouselコンポーネントの使用方法

37.1 データバインドされたADF Facesカレンダおよびカルーセル・コンポーネントについて

ADF Faces CalendarおよびADF Faces Carouselは、アプリケーションにカレンダ機能を組み込んだり、回転するイメージを表示する場合に使用できる複雑なコンポーネントです。ADF Faces Calendarはアクティビティを日、週、月単位で表示したり、特定のプロバイダのリスト・ビューに表示します。カレンダは、ビューの一部のみを表示するように構成できます。Calendarには、ユーザーが表示を(日、週、月またはリスト間で)変更、前または次の日、週、月に移動、および本日に戻ることのできる組込み機能のあるツールバーが含まれます。ツールバーはカスタマイズ可能で、表示するボタンやテキストの選択に加え、ボタンやその他のコンポーネントの追加もできます。

ADF Facesのカルーセルは、環状に回転するイメージを表示します。ユーザーはスライダを使用するか、イメージをクリックすることで、そのイメージを選択できます。これは、水平方向または垂直方向に構成できます。カルーセルとともに他のコンポーネントを使用できます。ツールバーやメニュー・バーを追加して、ユーザーが現在のオブジェクトに対してアクションを実行できるようにするボタンやメニュー項目をそれらに追加できます。

37.1.1 データバインドされたADF Facesカレンダおよびカルーセル・コンポーネントのユースケースと例

ADF Faces Calendarは、カレンダ機能をアプリケーションに追加する場合に使用できます。日付、時刻、件名、場所および所有者などの、カレンダによって提供されるコンテンツを表す関連データがデータ・ストアに含まれている必要があります。使い慣れたエンティティ・オブジェクトとビュー・オブジェクトのパターンを使用してデータをモデリングし、さらに「データ・コントロール」パネルからドラッグ・アンド・ドロップしてカレンダを作成できます。

Carouselコンポーネントを使用すると、一連のイメージからイメージを1つ表示できます。ユーザーは、そのイメージを表示する前後に各イメージの部分ビューを確認したり、イメージを順にスクロールできます。それには、スライダやナビゲーション・ボタンを使用します。カルーセルは、高度な視覚化表現を必要とするオブジェクトの表示に役立ちます。たとえば、カタログに写真コレクションや商品を表示する際に使用できます。

37.1.2 データバインドされたADF Facesカレンダおよびカルーセル・コンポーネントの追加機能

ADF Facesカレンダおよびカルーセル・コンポーネントを構成または使用する前に、その他のOracle ADF機能について理解しておいてください。また、カレンダおよびカルーセル・コンポーネントで実行できる内容について読むことが必要な場合があります。次に、関連する他の機能へのリンクを示します。

- 個人ユーザー用にカレンダをカスタマイズし、そのユーザーがカレンダにアクセスすると、選択した構成でカレンダが表示されるようにできます。詳細は、「実行時でのユーザー・カスタマイズの許可」を参照してください。

- カレンダはエンティティ・オブジェクトに基づいています。エンティティ・オブジェクトの作成の詳細は、「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」を参照してください。

- 部分ページ・レンダリングとpartialTriggers属性の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

- Carouselコンポーネントは、ツリー・バインディングを使用してデータを反復します。ツリー・バインディングの詳細は、「表のイテレータと値バインディング」を参照してください。

37.2 ADF Faces Calendarコンポーネントの使用方法

ADF Facesには、カレンダ・コンポーネントが含まれています。このコンポーネントは、日単位、週単位、月単位でアクティビティを表示します。図37-1に、いくつかのサンプル・アクティビティがある週表示モードのADF Faces Calendarを示します。

図37-1 ADF Faces Calendar

このコンポーネントには、次の機能も含まれています。

- 月単位、週単位、日単位、およびリスト・ビューを切り替えるためのツールバー。

ヒント:

これらのツールバー・ボタンを使用すると、Calendarの属性値が変わります。この値が保持されるように構成し、特定のユーザーがカレンダにアクセスしたときには必ずその値で表示されるようにできます。詳細は、「実行時でのユーザー・カスタマイズの許可」を参照してください。

- 週のはじめの曜日および1日の開始時刻の設定。たとえば、カレンダの1週間は日曜日に、1日は8:00 amから始まるように設定できます。

- スキニング・キーを使用した構成可能なスタイル。

さらに、その他のADF Facesコンポーネントやリッチ・クライアント・フレームワークを使用して、次の機能を実装することもできます。

- ポップアップ機能。サポートされているファセットに配置されたコンポーネント。特定のイベントに応答し、ユーザーがアクティビティやカレンダに従って行動できるようにします。たとえば、ユーザーがCalendar内のアクティビティをクリックすると、CalendarActivityEventが起動され、ActivityDetailファセットにあるポップアップ・コンポーネントがすべて表示されます。図37-2に示すように、ユーザーがアクティビティを表示および編集できるフォームを含んでいるダイアログ・コンポーネントを使用することもできます。

図37-2 ActivityDetailファセットの「編集」ダイアログ

- ドラッグ・アンド・ドロップ機能: calendarDropTargetタグを追加して、ユーザーがアクティビティをカレンダの別の場所にドラッグできるようにすることができます。その後、アクティビティで実際に時刻が変更され、データ・ストアに保持されるように機能を実装します。

- ツールバーのカスタマイズ: デフォルトでは、ツールバーにはユーザーがビューを切り替えるためのボタンとともに、「前へ」、「次へ」ボタンや現在の日付に戻るためのボタンが含まれます。また、このツールバーには現在の日付範囲(日表示の場合は日付)が表示されます。ユーザーが選択したボタンを含むファセットを追加して、ツールバーをカスタマイズすることができます。

- スキニング: カレンダはスキニング・キーを使用して、使用する色やアイコンなどを決定できます。スキンを拡張して、カレンダの外観を変更できます。

組込み機能の構成方法や、追加機能の実装方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「カレンダ・コンポーネントの使用方法」を参照してください。

ADF Faces CalendarコンポーネントはCalendarModelクラスにバインドする必要があります。このクラスは、ユーザーがADFビジネス・コンポーネントを使用して、カレンダ・データを管理するときに、このユーザーのために作成することができます。たとえば、日付、時刻、件名、場所、所有者など、アクティビティの詳細を表すデータがデータ・ストアに入っているとします。このデータを表すエンティティ・オブジェクトを作成してから、このデータを表示するためのビュー・オブジェクトを作成した場合、関連するコレクションを「データ・コントロール」パネルからドラッグ・アンド・ドロップして、カレンダを作成できます。JDeveloperはモデルを宣言的に作成して、このモデルにビューをバインドし、カレンダを起動したときに正しいデータが表示されるようにします。ただし、モデルを作成するためには、ADFビジネス・コンポーネントを持つデータ・モデル・プロジェクトのエンティティ・オブジェクトおよび同じプロジェクト内のビュー・オブジェクトに、有効日指定の属性が必要です。また、ビュー・オブジェクトには、指定された日付範囲に対する正しいアクティビティを返すように問合せを修正するための変数も必要です。

37.2.1 ADF Faces Calendarの作成方法

JSFページでカレンダを作成する前に、まず、カレンダの属性を表す具体的な属性を持つエンティティ・オブジェクトを作成する必要があります。その後、このエンティティ・オブジェクトからビュー・オブジェクトを作成し、表示する日付範囲と現在のタイムゾーンを表す名前付きバインド変数を使用して、問合せを編集してください。これにより、この問合せから、カレンダの指定されたビューに表示すべきアクティビティのみが返されるようになります。

たとえば、あるアクティビティを表すデータベース表があるとします。これには、タイトル列、開始時刻、終了時刻、所有者を表すプロバイダ・オブジェクトへの参照が含まれています。この表に基づいて、(次の手順で説明するとおり、要件を満たすことを保証しながら)エンティティ・オブジェクトとビュー・オブジェクトを作成します。その後、ビュー・オブジェクトに、カレンダに現在表示されている開始時刻と終了時刻を表す名前付きバインド変数、カレンダで現在使用されているタイムゾーンを追加します。これにより、問合せはその時間範囲内に収まるアクティビティのみを返すようになります。

カレンダ・コンポーネントは、JSFページに追加した後で構成と機能の追加が可能になります。

始める前に:

カレンダの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「ADF Faces Calendarコンポーネントの使用方法」を参照してください。

ADF Faces Calendarを作成するには:

1. データ・ソースに基づいて、エンティティ・オブジェクトを作成します。このエンティティ・オブジェクトには、表37-1に示す属性が含まれていなければなりません。これらの属性は、必ずしも、この表に示す名前を使用する必要はありません。どのような名前でもつけられます。ただし、記載されているタイプのいずれかでなければなりません。後述の手順で、これらの属性を、CalendarModelの属性にマップします。

表37-1 カレンダに必須の属性

属性

有効なタイプ

説明

開始時間

java.util.Date、java.sql.Date、oracle.jbo.domain.Date、oracle.jbo.domain.TimeStamp

アクティビティの開始時刻

終了時間

java.util.Date、java.sql.Date、oracle.jbo.domain.Date、oracle.jbo.domain.TimeStamp

アクティビティの開始時刻

ID

String

一意のID

プロバイダID

String

アクティビティの所有者を表すプロバイダ・オブジェクトのID

タイトル

String

アクティビティの簡単な説明

このエンティティ・オブジェクトには、表37-2に示す既知の属性を含めることができます(必須ではありません)。

表37-2 カレンダに必要に応じて指定できる属性

属性

タイプ

説明

繰返し

StringまたはCalendarActivity.Recurring

アクティビティの繰返しステータス。有効な値はSINGLE(繰り返さない)、RECURRING(繰り返す)、またはCHANGED(このアクティビティは繰返しアクティビティの一部だが、修正されていて、親アクティビティとは異なる)です。

アラーム

StringまたはCalendarActivity.Reminder

アクティビティに関連付けられたアラームがあるかどうか。有効な値はONまたはOFFです。

時間タイプ

StringまたはCalendarActivity.TimeType

アクティビティに関連付けられている時間のタイプ。有効値はALLDAYおよびTIMEです。値ALLDAYを持つアクティビティには、時間は関連付けられていません。これらは1日中続くとみなされます。値TIMEを持つアクティビティは具体的な継続時間を持ちます。

場所

String

アクティビティの場所。

タグ

String値のSet、またはセミコロンで区切ったString値のリスト。

アクティビティのキーワード

エンティティ・オブジェクトは、CalendarModelが認識していない属性を含むこともできます。これらの属性は、後述の手順でカスタム・プロパティとしてモデルに追加できます。

エンティティ・オブジェクトの作成の詳細は、「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」を参照してください。

2. 関連するビュー・オブジェクトを作成します。概要エディタの「問合せ」ページで、次に対する名前付きバインド変数を作成します。

- タイムゾーンを表す文字列

- カレンダに表示されている現在の日付範囲の開始日を表す日付

- カレンダに表示されている現在の日付範囲の終了日を表す日付

ヒント:

ADF Facesカレンダの日付は「半分空いている」状態です。つまり、カレンダは、開始時刻ちょうどまたはそれ以降に始まり、終了時刻前に(ちょうどではない)アクティビティすべてを戻します。

名前付きバインド変数の作成の詳細は、「バインド変数の使用」を参照してください。

3. アクティビティのプロバイダ(所有者)を表すエンティティ・オブジェクトを作成します。このエンティティ・オブジェクトには、表37-3に示す属性が含まれていなければなりません。これらの属性は、必ずしも、この表に示す名前を使用する必要はありません。どのような名前でもつけられます。ただし、記載されているタイプでなければなりません。後述の手順で、これらの属性を、CalendarProviderの属性にマップします。

表37-3 CalendarProviderクラスの属性

属性

タイプ

説明

Id

String

一意のID。

表示名

String

カレンダに表示できるプロバイダ名。

4. このプロバイダのビュー・オブジェクトを作成します。

5. 新しいビュー・オブジェクトがアプリケーション・モジュールの一部であることを確認し、必要に応じて、「データ・コントロール」パネルをリフレッシュします。

6. 「Webページの作成」の手順に従って、JSFページを作成します。

7. 「データ・コントロール」パネルから、ステップ2で作成したアクティビティに対応するビュー・オブジェクトを表すコレクションをドラッグし、カレンダとしてドロップします。

ヒント:

「カレンダ」オプションは、ビュー・オブジェクトに必須属性(表37-1を参照)とバインド変数(手順2を参照)が含まれている場合にのみ、コンテキスト・メニューに表示されます。

8. 「カレンダ・バインディング」ダイアログで、CalendarModelおよびCalendarProviderクラスにバインド変数と属性をマップします。詳細は、「ヘルプ」をクリックするか、[F1]を押してください。

9. デフォルトでは、カレンダは読取り専用で、そのときにデータ・ストアに入っているアクティビティのみが返されます。『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「カレンダ・コンポーネントの使用方法」の説明に従い、カレンダを構成し、追加機能を実装することが必要になります。

たとえば、新しいアクティビティを作成できるようにするには、カレンダを作成したときに使用したものと同じデータ・コントロールのコレクションを使用して、ダイアログに入力フォーム作成します(ダイアログの作成手順は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のダイアログの作成方法に関する項を参照)。入力フォームの作成の詳細は、「入力フォームの作成」を参照してください。

37.2.2 カレンダの作成時に行われる処理

コレクションをカレンダとしてドロップすると、JDeveloperにより次の処理が行われます。

- アクティビティ・コレクションへのイテレータ・バインディングを1つと、プロバイダ・コレクションへのイテレータ・バインディングを1つ定義します。

- アクティビティ・コレクションでexecuteWithParams操作へのアクション・バインディングを定義します。表示するアクティビティを返す問合せの実行のために呼び出されるのはこの操作です。この操作には日付範囲とタイムゾーンを決定するためのパラメータが必要であるため、(ビュー・オブジェクトで名前付きバインド変数として作成された)パラメータそれぞれについて、NamedData要素も作成されます。NamedData要素の詳細は、「メソッドのパラメータ」を参照してください。

注意:

カレンダ・ページ定義ファイルのNDTypeとしてjava.sql.Dateを指定すると、ランタイム・エラーが発生します。かわりに次のサポートされたデータ型の1つを使用してください。

- oracle.jbo.domain.Timestamp

- oracle.jbo.domain.Date

- java.sql.Timestamp

- java.util.Date

- カレンダ・バインディングを定義します。このバインディングは、ウィザードで定義したとおり、コレクションの行を表すnode要素を含み、データ・コントロール属性をカレンダ・アクティビティの属性にマップします。valueはデータ・コントロール属性、typeはカレンダ属性です。カスタム定義属性では、typeはcustom、valueはデータ・コントロール属性になります。各行(ノード)はrowKeyで表されます。これはアクティビティIDです。
また、利用可能なプロバイダのソースとマッピングを決定するproviderDefinition要素もあります。このマッピングにより、カレンダ・モデルはプロバイダの状態(有効または無効)に基づいてアクティビティをフィルタできるようになります。

ヒント:

カスタム属性にアクセスするには、value要素で定義された属性名で渡されるCalendarActivity.getCustomAttributes()メソッドを使用します。

次の例は、カレンダのページ定義コードを示しています。

<executables>
<iterator Binds="ActivityView1" RangeSize="-1"
DataControl="AppModuleDataControl" id="ActivityView1Iterator"/>
<iterator Binds="EmployeesView1" RangeSize="25"
DataControl="AppModuleDataControl" id="EmployeesView1Iterator"/>
</executables>
<bindings>
<action IterBinding="ActivityView1Iterator" id="ExecuteWithParams"
RequiresUpdateModel="true" Action="executeWithParams">
<NamedData NDName="startTime"
NDValue="#{bindings.ActivityView1.startDate}"
NDType="oracle.jbo.domain.Date"/>
<NamedData NDName="endTime" NDValue="#{bindings.ActivityView1.endDate}"
NDType="oracle.jbo.domain.Date"/>
<NamedData NDName="timeZone"
NDValue="#{bindings.ActivityView1.timeZoneId}"
NDType="java.lang.String"/>
</action>
<calendar IterBinding="ActivityView1Iterator" id="ActivityView1"
xmlns="http://xmlns.oracle.com/adf/faces/binding"
ActionBindingName="ExecuteWithParams">
<nodeDefinition DefName="model.ActivityView">
<AttrNames>
<Item Type="id" Value="Id"/>
<Item Type="providerId" Value="ProviderId"/>
<Item Type="title" Value="Title"/>
<Item Type="startTime" Value="StartTime"/>
<Item Type="endTime" Value="EndTime"/>
</AttrNames>
</nodeDefinition>
<providerDefinition IterBindingName="EmployeesView1Iterator">
<AttrNames>
<Item Type="id" Value="EmployeeId"/>
<Item Type="displayName" Value="FirstName"/>
</AttrNames>
</providerDefinition>
</calendar>
</bindings>

次の例に示すとおり、JDeveloperはCalendarModelクラスにカレンダ値をバインドするコードをJSFページに挿入します。

<af:form>
<af:calendar value="#{bindings.ActivityView1.calendarModel}"/>
</af:form>

CalendarModelクラスは、カレンダ・バインディングへのアクセスにCalendarActivityDefinitionクラスを使用します。

37.2.3 実行時に行われる処理: カレンダ・バインディングの動作方法

カレンダにアクセスすると、executeWithParams操作が、カレンダ・コンポーネントのviewおよびactiveDay属性により決定されるstartDateおよびendDateパラメータ値を使って呼び出されます。たとえば、view属性がmonthに設定されていて、activeDayが現在の日付(例: May 5, 2013)に設定されている場合、startDateはMay 1, 2013になり、endDateの値はMay 31, 2013になります。デフォルトでは、タイムゾーン値はtrinidad-config.xmlファイルのtime-zone設定から取得されます(詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のtrinidad-config.xml内の構成に関する項を参照)。したがって、問合せは、この日付範囲内に収まるアクティビティのみを返すように制限されます。

カレンダ・コンポーネントはCalendarModelにバインドされているため、問合せがデータを返すとき、CalendarModelはCalendarActivityDefinitionクラスを使用して、カレンダ・バインディング・クラスにアクセスし、このバインディングが提供するマッピングを使用して、データ・ソースからカレンダに値をマップします。

37.3 ADF Faces Carouselコンポーネントの使用方法

図37-3に示すように、イメージを回転カルーセルに表示できます。正面にある画像を変更するには、下部のスライダを使用するか、または別の画像を正面にドラッグします。

図37-3 Carouselコンポーネント

表示されるイメージごとに子carouselItemコンポーネントを組み込み、これらのコンポーネントを個々のイメージにバインドするかわりに、carouselコンポーネントを完成コレクションにバインドし、ツリーがデータの各行をスタンプ処理するのと同じ方法で、各アイテムの値をスタンプ処理して、1つのcarouselItemコンポーネントを繰り返しレンダリングします。各項目にスタンプが設定されると、現在の項目のデータが、carouselコンポーネントvar属性を使用するEL式を使用して特定可能なプロパティにコピーされます。カルーセルのレンダリングが完了したら、このプロパティは削除されるか前の値に戻ります。カルーセルはnodeStampファセットを持っています。このファセットは、各アイテムに関するテキストと簡単な説明の表示に使用されるcarouselItemコンポーネントのホルダーで、各アイテムについて表示されるイメージの親コンポーネントでもあります。カルーセル・コンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のカルーセルでイメージを表示する方法に関する項を参照してください。

37.3.1 データバインドされたCarouselコンポーネントの作成方法

Fusion Webアプリケーションでカルーセル・コンポーネントを使用する場合は、このコンポーネントの作成に「データ・コントロール」パネルを使用します。また、カルーセルのスピン・イベントの処理にはマネージドBeanを使用します。その他のロジックについては、アイテムの表示が必要になる可能性があります。

始める前に:

カルーセルの作成時に選択可能なオプションについて理解しておいてください。詳細は、「ADF Faces Carouselコンポーネントの使用方法」を参照してください。

また、カルーセルと併用できる機能について理解しておくとよいでしょう。詳細は、「データバインドされたADF Facesカレンダおよびカルーセル・コンポーネントの追加機能」を参照してください。

JDeveloperで、次の手順を実行します。

1. カルーセルに表示されるコレクションに対するビュー・オブジェクトを作成します。たとえば、図37-3に示すようなカルーセルを作成する場合は、Inventoryビュー・オブジェクトを使用します。

2. マネージドBeanを作成して、そのマネージドBeanに、カルーセルの回転を処理するメソッドを保持します。次の例は、アイテムをカルーセルに表示するために使用できるハンドラ・メソッドを示しています。

public void handleCarouselSpin(CarouselSpinEvent event)
{
// This method is invoked when there is a spin event on the carousel in
// InventoryControl.jsff. The purpose is to get the newly selected item in the
// carousel and update the iterator current row with the value

// get the bindingContainer
DCBindingContainer dcBindings = (DCBindingContainer)
BindingContext.getCurrent().getCurrentBindingsEntry();
// get the NewItemKey from the event object. The first entry in the list is the
// currently selected item
List itemKeyList = (List) event.getNewItemKey();
// create a Key ojbect instance and set it to the first key in the list
Key currentItemKey = (Key) itemKeyList.get(0);
// get the iteratorBinding
DCIteratorBinding inventoryIterator =
dcBindings.findIteratorBinding("InventoryIterator");
// set the iterator
inventoryIterator.setCurrentRowWithKey(currentItemKey.toStringFormat(true));
}

データバインドされたCarouselコンポーネントを作成するには:

1. 「データ・コントロール」パネルから、ビュー・オブジェクトで使用されるコレクションをページにドラッグし、ポップアップ・メニューから「カルーセル」を選択します。

2. 「プロパティ」ウィンドウの「動作」セクションで、前提条件として作成したハンドラ・メソッドにCarouselSpinListenerをバインドします。

3. 構造ウィンドウで、carouselコンポーネントとnodeStampファセットを展開し、carouselItemコンポーネントを選択します。

4. CarouselItemコンポーネントのtext属性を、ビュー・オブジェクトの関連プロパティにバインドします。このバインドには、カルーセルのvar属性に設定されている変数値(デフォルトではitem)を使用します。たとえば、ビュー・オブジェクトのName属性を使用する場合、carouselItemのtext属性の値は、#{item.Name}になります。

それ以外のプロパティをtext属性にバインドすることで、別の情報を表示することもできます。たとえば、インベントリ・カルーセルでは、NameプロパティとAmountInStockプロパティの両方をtext属性にバインドします。

5. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「一般コントロール」パネルから「イメージ」をドラッグし、それを子としてcarouselItemにドロップします。

「イメージの挿入」ダイアログに、画像ソースへのパスを入力します。必ず、カルーセルでこのアイテムを表している変数を使用してください。たとえば、この製品の画像ファイルへのパスは通常、次のようになります。

/images/products/#{item.Filename}

shortDesc属性をテキストにバインドします。このテキストは、マウス・ポインタをイメージ上に移動したときに表示されます。次に例を示します。

#{item.Name}

carouselコンポーネントとcarouselItemコンポーネントのその他の属性を設定する方法は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のカルーセルの作成方法に関する項を参照してください。

6. カルーセル内のアイテムに関する追加情報を提供する場合は、同じビュー・オブジェクトをドラッグして、たとえば表としてページにドロップします。この表内のコンポーネントに、カルーセルの回転後に表示される現行のアイテムの情報が再表示されるようにするには、フォームを含んでいるコンポーネントのpartialTrigger属性をカルーセル・コンポーネントのIDに設定する必要があります。

たとえば、各アイテムの情報を表示する表があるとします(図37-3を参照)。このtableコンポーネントのpartialTrigger属性は、カルーセル・コンポーネントのIDであるc1に設定されます。これにより、carouselItemでCarouselSpinEventを起動するたびに、tableがリフレッシュされ、カルーセルで現行になったアイテムの情報を表示する行が表内の現行の行になります。

さらに、カルーセルとカルーセル・アイテムのpartialTrigger属性を、表のIDであるt1に設定します。これにより、表で選択イベントが発生するたびに、カルーセルがリフレッシュされ、表内で現行になったアイテムがカルーセルでの現行アイテムになります。

部分ページ・レンダリングとpartialTriggers属性の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

次の例は、図37-3に示すカルーセルのページ・コードを示しています。

<f:facet name="first">
<af:carousel currentItemKey="#{bindings.Inventory.treeModel.rootCurrencyRowKey}"
value="#{bindings.Inventory.treeModel}" var="item" id="c1"
carouselSpinListener="#{InventoryControl.handleCarouselSpin}"
partialTriggers="::t1">
<f:facet name="nodeStamp">
<af:carouselItem id="ci1" text="#{item.Name} #{item.AmountInStock}"
partialTriggers="::t1">
<af:image source="/images/products/#{item.Filename}"
shortDesc="#{item.Name}" id="i1"/>
</af:carouselItem>
</f:facet>
</af:carousel>
</f:facet>
<f:facet name="second">
<af:table value="#{bindings.Inventory.collectionModel}" var="row"
rows="#{bindings.Inventory.rangeSize}"
emptyText="#{bindings.Inventory.viewable ? 'No data to display.' :
'Access Denied.'}"
fetchSize="#{bindings.Inventory.rangeSize}" rowBandingInterval="0"
selectedRowKeys="#{bindings.Inventory.collectionModel.selectedRow}"
selectionListener="#{bindings.Inventory.collectionModel.makeCurrent}"
rowSelection="single" id="t1"
columnStretching="last" partialTriggers="::c1">

37.3.2 カルーセルの作成時に行われる処理

「データ・コントロール」パネルからコレクションをカルーセルとしてドロップすると、ツリーの値バインディングが作成されます。ツリーはノードの階層で構成され、各サブノードは上位レベルのノードから分岐します。

ツリー・バインディングは、イテレータ・バインディングによって公開されたデータ全体を反復します。このカルーセルは、イテレータ・バインディングからの結果セットを、collectionModelの拡張であるtreeModelオブジェクト内にラップします。collectionModelにより、コレクションの各アイテムは、var属性を使用してカルーセル・コンポーネント内で使用できるようになります。ツリー・バインディングの詳細は、「表のイテレータと値バインディング」を参照してください。

次の例に示すように、JDeveloperはcarouselコンポーネントとその子carouselItemコンポーネントの両方をページに追加します。

<af:carousel
currentItemKey="#{bindings.Products.treeModel.rootCurrencyRowKey}"
value="#{bindings.Products.treeModel}" var="item"
id="c1"
carouselSpinListener="#{InventoryControl.handleCarouselSpin}">
<f:facet name="nodeStamp">
<af:carouselItem id="ci1" text="#{item.Name}"/>
</f:facet>
</af:carousel>

カルーセルの値は、関連するコレクションのtreeModelにバインドされています。また、カルーセルのcurrentItemKey属性は、バインディング・オブジェクトのrootCurrencyRowKeyにバインドされています。この例では、カルーセルがProductsイテレータ・バインディングのアイテムを反復します。イテレータ・バインディングは、現在の製品を追跡するrowKeySetにバインドします。デフォルトでは、カルーセルのcurrentItemKey属性は、バインディング・オブジェクトのrootCurrencyRowKeyにバインドされています。このため、カルーセルの正面に表示されている製品が、ルートおよびカレント・アイテムになります。carouselItemコンポーネントは、item変数を使用して、カルーセル・タグに表示されているカレント・アイテムのカレント・データ・オブジェクトにアクセスします。

38 データバインドされたチャート・コンポーネント、統計図表コンポーネントおよびゲージ・コンポーネントの作成

この章では、Fusion WebアプリケーションでADFデータ・コントロールおよびADF Facesコンポーネントを使用して、ADFビジネス・コンポーネントでモデル化されたデータからチャート、統計図表、またはゲージを作成する方法を説明します。具体的には、ビジネス・データを視覚的に表すADFデータ視覚化ツール(DVT)の面チャート、棒グラフ、バブル・チャート、ファンネル・チャート、横棒グラフ、折れ線グラフ、円グラフ、極チャート、レーダー・チャート、散布図、スパーク・チャート、統計図表と、ダイアル、LED、評価およびステータス・メーターの各ゲージの使用方法について説明します。ここでは、ADFデータ・コントロールを使用して、これらのコンポーネントをデータ優先開発で作成する方法について説明します。

簡単なUI優先開発を使用してページを設計する場合は、チャートやゲージをページに追加してから、データ・バインディングを構成してください。チャートおよびゲージ・コンポーネントのデータ要件、タグ構造、および外観と動作のカスタマイズ・オプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントの使用方法、統計図表コンポーネントの使用方法およびゲージ・コンポーネントの使用方法を参照してください。

この章の内容は次のとおりです。

- ADFデータ視覚化チャート、統計図表およびゲージ・コンポーネントについて

- データバインドされたチャートの作成

- データバインドされたゲージの作成

- データバインドされた統計図表の作成

38.1 ADFデータ視覚化チャート、統計図表およびゲージ・コンポーネントについて

ADFデータ視覚化コンポーネントは、ビジネス・データを視覚的に表示、分析するための幅広いグラフィック機能と表機能を提供します。コンポーネントをレンダリングできるようにするには、これらのコンポーネントをそれぞれ、データにバインドする必要があります。コンポーネントの外観は表示されるデータによって変わるからです。

チャート・コンポーネントとゲージ・コンポーネントの両方により、データがレンダリングされます。ただし、チャートでは、複数の軸上の複数のデータ・ポイントを様々な方法で評価できます。豊富な種類のチャートにより、あるグループの結果を別のグループの結果と比較することが容易になります。一方、ゲージでは、単一のデータ・ポイントを重視し、そのポイントを最小、最大およびしきい値インジケータと比較して問題を識別します。

統計図表は、絶対数や母集団の中の部分集合を表現するときに使用する汎用性の高いコンポーネントです。フロー・レイアウトで配置されることから、データ・ポイントを様々な方法で見栄えよく表現できます。

接頭辞dvt:は、各データ視覚化コンポーネント名の先頭に付いて、そのコンポーネントがADFデータ視覚化ツール(DVT)のタグ・ライブラリに属することを示します。

38.1.1 データ視覚化コンポーネントのユースケースと例

データ視覚化のユースケースと例の詳細は、次を参照してください。

- チャート・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントのユースケースと例に関する項。

- ゲージ・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のゲージ・コンポーネントのユースケースと例に関する項。

- 統計図表コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の統計図表コンポーネントのユースケースと例に関する項。

38.1.2 エンド・ユーザー機能およびプレゼンテーション機能

魅力的な外観を備えたデータ視覚化コンポーネントを使用すると、エンド・ユーザーは複雑なビジネス・データを理解して分析できるようになります。このコンポーネントは機能が豊富で、そのまますぐに使用できる対話型のサポートも用意されています。エンド・ユーザーの詳細な説明と各コンポーネントのプレゼンテーション機能の詳細は、次を参照してください。

- チャート・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャートのエンド・ユーザー機能とプレゼンテーション機能に関する項。

- ゲージ・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のゲージ・コンポーネントのエンド・ユーザー機能とプレゼンテーション機能に関する項。

- 統計図表コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の統計図表のエンド・ユーザー機能とプレゼンテーション機能に関する項。

38.1.3 データ視覚化コンポーネントの追加機能

データ視覚化コンポーネントをデータ・バインドする前に、その他のOracle ADF機能について理解しておいてください。また、いったんデータ視覚化コンポーネントをページに追加すると、検証やアクセシビリティなどの機能を追加する必要があることに気付く場合があります。データ視覚化コンポーネントで使用されるその他の機能へのリンクは、次のとおりです。

- 部分ページ・レンダリング: データ視覚化コンポーネントをリフレッシュして、ページの別のコンポーネントで実行されたアクションに基づく新しいデータを表示できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

- パーソナライズ: ユーザーは実行時にデータ視覚化コンポーネントの表示を変更できますが、ユーザーがカスタマイズできるようにアプリケーションを構成していないかぎり、ユーザーがページを終了するとそれらの値は保持されません。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「JSFページでのユーザー・カスタマイズの許可」を参照してください。

- アクセシビリティ: データ視覚化コンポーネントをアクセス可能にできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「アクセス可能なADF Facesページの開発」を参照してください。

- スキンおよびスタイル: アプリケーションに適用するADFスキンを使用するか、スタイル関連のプロパティ(styleClassまたはinlineStyle)を使用してCSSスタイル・プロパティを直接適用することで、データ視覚化コンポーネントの外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

- プレースホルダ・データ・コントロール: 最終的にページのデータ視覚化コンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールの使用を検討します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

38.2 データバインドされたチャートの作成

チャートはデータ・コレクションに基づいています。データバインドされたチャートを作成するには、「データ・コントロール」パネルから「JSF」ページにコレクションをドラッグ・アンド・ドロップして、チャートにデータ・コレクション属性をバインドします。

チャートには、データの系列とグループが表示されます。系列とグループは、データのグリッドの行と列にたとえることができます。通常、グリッドの行はチャートの系列として表示され、グリッドの列はグループとして表示されます。

大半のチャートでは、系列は同じ色のマーカーのセットとして表示されます。通常、チャートの凡例に、各系列の識別子と対応する色が表示されます。たとえば、棒グラフで黄色の棒が靴の売上げを示し、緑色の棒がブーツの売上げを示す、などです。

グループの表示は、チャート・タイプによって異なります。たとえば、積上げ棒グラフでは、各積層がグループです。グループは年などの期間を表す場合もあります。グループが地域などの地理上の場所を表す場合もあります。

チャート・タイプのデータ要件に応じて、1つのグループに複数のデータ値が必要な場合があります。たとえば、散布図では、データ・マーカーごとに2つの値が必要です。1つ目の値はX軸上のマーカーの位置を決め、2つ目の値はY軸上のマーカーの位置を決めます。チャート・データ要件の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネント・データ要件に関する項を参照してください。

データ・コレクション内の属性には、データ値またはデータ値のカテゴリを指定できます。データ値は、棒の高さなどのマーカーまたは散布図のポイントで示される数字です。データ値のカテゴリは、軸のラベルとして示されるメンバーになるか、ツールチップの追加プロパティとして表示されます。バインディング内で属性が担うロール(データ値またはID)は、データ型およびマップされる場所(棒やX軸など)の両方によって決まります。

「データ・コントロール」パネルから挿入されたデータ・コレクションを使用してチャートを作成する場合は、コンポーネント・ギャラリを使用すると、多数のチャート・カテゴリ、チャート・タイプおよびレイアウト・オプションから選択できます。チャート・カテゴリは、1つ以上の異なるタイプのチャートを1つのグループにまとめたものです。たとえば、「面」カテゴリには次のタイプのチャートが含まれます。

- 領域

- 分割二重Y面

- 積上げ面

- 分割二重Y積上げ面

- 範囲面

チャートの作成時に表示されるコンポーネント・ギャラリを見てまわり、使用可能なチャート・カテゴリ、タイプおよびそれぞれの説明を確認してください。図38-1に、「データ・コントロール」パネルを使用しているときにADFチャート用に表示される、「コンポーネント・ギャラリ」を示します。

図38-1 チャートのコンポーネント・ギャラリ

表38-1に、チャートのコンポーネント・ギャラリに表示されるカテゴリを示します。各カテゴリには、1つ以上のチャート・タイプが関連付けられています。

表38-1 コンポーネント・ギャラリのADFチャート・カテゴリ

イメージ

カテゴリ

説明

領域

データが塗りつぶされた面として表されるチャートを作成します。面チャートを使用して、過去12か月の売上げなど、ある期間の傾向を示します。面チャートでは、1つの軸上に最低2グループのデータが必要です。通常、この軸には期間(月など)のラベルが付けられます。

棒

データが一連の垂直な棒として表されるチャートを作成します。製品またはカテゴリ間で値を比較するため、または期間別に分類された集計データを表示するために使用します。

棒(横)

Y軸に沿って棒を横向きに表示するチャートを作成します。方向を示して傾向の表示や値の比較を可能にするために使用します。

バブル

データが丸いデータ・マーカー(バブル)の場所と大きさによって表されるチャートを作成します。3タイプの値の相関を示すために使用します(特に、多数のデータ・アイテムがあり、全般的な関係を確認する場合)。たとえば、バブル・チャートを使用して、従業員の給与(X軸)、経験年数(Y軸)と生産性(バブルのサイズ)をプロットします。このようなチャートでは、生産性を給与および経験と比較して調べることができます。

組合せ

異なるタイプのデータ・マーカー(棒、線または面)を使用して、異なる種類のデータ・アイテムを表示するチャートを作成します。棒と線、棒と面、線と面またはこの3つすべてを比較するために使用します。

ファンネル

プロセス内の手順に関連するデータを表すチャートを作成します。実際値とターゲット値を比較したり、一連の手順内の値を比較したりするために使用します。たとえば、ファンネル・チャートを使用して、ファンネルの異なるセクションが販売周期の異なる段階を表すプロセスを表示します。

線

データが線、一連のデータ・ポイントまたは線で結ばれた複数のデータ・ポイントとして表されるチャートを作成します。折れ線グラフには、グループ内のメンバーごとに最低2つのポイントを表すデータが必要です。たとえば、月単位の折れ線グラフでは、少なくとも2つの月のデータが必要です。通常、特定の色の線がデータの各系列(アメリカ、ヨーロッパ、アジアなど)に関連付けられます。複数のアイテムを同じ期間で比較するために使用します。

円

データ・アイテムのセットを合計に対する比率として表すチャートを作成します。データ・アイテムが円のセクションとして表示され、円が切り分けられたパイのように見えます。それぞれの商品群から得られる収益など、各区分と全体との関係を示すために使用します。

散布図

データがデータ・マーカーの場所によって表されるチャートを作成します。人気商品の売上とコストなど、2つの異なる種類のデータ値の相関を示すために使用します。散布図は、多数の項目間の全体的な関連性を示す場合に特に有用です。

スパーク

表の列に、またはテキストともにインラインでトレンドまたはバリエーションを表したシンプルな要約チャートを作成します。

株価

株価の高値、安値、始値および終値を示すデータでチャートを作成します。また、株価の出来高を必要に応じて表示します。

また、「コンポーネント」ウィンドウからチャート・コンポーネントをドラッグして、チャートを作成することもできます。この方法では、コンポーネントをデータにバインドする前に、チャートのユーザー・インタフェースを設計できます。「チャートの作成」ダイアログが表示され、チャート・タイプ、説明および簡単なレイアウト・オプションが表示されます。UI優先開発を使用したチャートの作成方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントの使用に関する項を参照してください。

38.2.1 データ・コントロールを使用して面チャート、棒グラフ、複合チャート、横棒グラフまたは折れ線グラフを作成する方法

面チャート、棒グラフ、横棒グラフおよび折れ線グラフでは、1つ以上の系列があるデータのグループが少なくとも2つ必要です。グループは、面チャート、棒グラフおよび折れ線グラフの場合はチャートのX軸に沿って表示され、横棒グラフの場合はチャートのY軸に沿って表示されます。系列は、チャートに面、棒または折れ線として表示されます。

図38-2に、Summit ADFサンプル・アプリケーションの2つの棒グラフを示します。左側の棒グラフは、顧客の注文履歴と注文の平均を示すように構成されており、右側の棒グラフは各注文の出荷日を示します。これらの例では、棒グラフは注文日と出荷日を表すグループで構成され、系列は注文の合計と出荷日の平均です。注文の平均は、Order Historyチャートに赤い参照線として表示されます。

図38-2 Summit ADFサンプル・アプリケーションの棒グラフ

チャートの作成後のチャートへの参照線の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャートへの参照オブジェクトの追加に関する項を参照してください。

始める前に:

データバインドされたデータ視覚化チャートについて理解しておいてください。詳細は、「データバインドされたチャートの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
たとえば、Summit ADFのShipping Time棒グラフは、OrdersForCustomerデータ・コレクションに基づいています。図38-3に、「データ・コントロール」パネル内のOrdersForCustomerコレクションを示します。

図38-3 注文出荷期間のデータ・コレクション

OrdersForCustomerデータ・コントロールは、OrdVOビュー・オブジェクトに基づいています。図38-4に、OrdEO、EmpEOおよびCustomerEOエンティティ・オブジェクトからの属性を含むOrdVOビュー・オブジェクトを示します。OrdEO、EmpEOおよびCustomerEOエンティティ・オブジェクトは、SummitスキーマのSOrd、SEmpおよびSCustomer表から導出されます。

図38-4 Summit ADFサンプル・アプリケーションOrdVOビュー・オブジェクト

OrdVOオブジェクトには、Summit ADFのShipping Time棒グラフの棒で表されるTimeToShip一時属性も含まれます。TimeToShip属性の値は、calculateTimeToShip()メソッドのコールによって取得されます(adf.object.calculateTimeToShip(DateOrdered, DateShipped))。calculateTimeToShip()メソッドは、注文の出荷に要した日数を判断し、OrdVORowImpl.javaに追加されます。OrdVORowImpl.javaには、OrdVOビュー・オブジェクトの実装メソッドが含まれます。

次の例は、Summit ADFサンプル・アプリケーションのcalculateTimeToShip()メソッドを示しています。メソッドは、日数をoracle.jbo.domain.Numberとして返します。これはチャートのvalue属性に必要な型です。

public oracle.jbo.domain.Number calculateTimeToShip(Date ordered, Date shipped) {
if (null != shipped) {
long days = (shipped.getTime() - ordered.getTime()) / (1000 * 60 * 60 * 24);
return new Number(days);
} else
return new Number(0);
}

ビュー・オブジェクトへの一時属性の追加の詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされた面チャート、棒グラフ、複合チャート、横棒グラフまたは折れ線グラフを作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、各注文に対する出荷期間を表示する棒グラフを、Summit ADFサンプル・アプリケーションの「Orders Dashboard」ページに作成する場合は、OrdersForCustomerコレクションを選択します。

2. コレクションをJSFページにドラッグして、ポップアップ・メニューから「チャート」を選択します。

3. 「コンポーネント・ギャラリ」で、チャート・カテゴリとチャート・タイプを選択して、「OK」をクリックします。

「コンポーネント・ギャラリ」に表示されるチャート・カテゴリおよびチャート・タイプの詳細は、表38-1を参照してください。

ダイアログの名前と表示される入力フィールドのラベルは、選択したチャートのカテゴリ、タイプおよびデータ・コレクションに応じて変化します。たとえば、チャート・カテゴリとして「棒」を選択し、チャート・タイプとして「棒」を選択すると、表示されるダイアログの名前は「棒グラフの作成」になり、入力フィールドのラベルは「棒」と「X軸」になります。

4. ダイアログで次のようにして、データを表示するチャートを構成します。

- 実行時に属性の値をどこに表示するかに応じて、「使用可能」リストから入力フィールドに属性をドラッグします。
たとえば、X軸に沿って注文日を表示するように、Summit ADFサンプル・アプリケーションの棒グラフを構成する場合は、「使用可能」リストからDateOrdered属性をドラッグして、「棒グラフの作成」ダイアログの「X軸」フィールドにドロップします。出荷の時間を棒グラフとして表示するようにチャートを構成するには、「使用可能」リストからTimeToShip属性をドラッグして、「棒グラフの作成」ダイアログの「棒」フィールドにドロップします。

二重Y軸を含むチャート・タイプを選択した場合、追加する2番目の面、棒または折れ線は、2番目のY軸にレンダリングされます。また、chartSeriesStyleコンポーネントは、2番目のY軸に表される系列のチャートに追加され、chartSeriesStyleコンポーネントのassignedToY2属性がtrueに設定されます。

複合チャートを選択した場合、「データ・ポイント」入力フィールドに追加する各属性は、面チャート、棒グラフまたは折れ線グラフとしてレンダリングされます。デフォルトでは、最初の属性は棒グラフとしてレンダリングされ、2番目の属性は折れ線グラフとしてレンダリングされ、3番目の属性は面チャートとしてレンダリングされます。チャート・タイプを変更するには、chartSeriesStyleコンポーネントを複合チャートのseriesStampファセットに追加します。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャートの系列のカスタマイズ方法に関する項を参照してください。

- 「属性ラベル」表で、デフォルト値を受け入れるか、「ラベル」フィールドのドロップダウン・リストから値を選択して、実行時に表示されるラベルを指定します。
基になるデータ型に応じて、「ラベル」フィールドで選択可能な項目が決まります。この選択に応じて、属性のラベルをチャートにレンダリングする方法が決まります。詳細は、「属性ラベルの使用に関する必知事項」を参照してください。

図38-5に示す「棒グラフの作成」ダイアログは、OrdersForCustomerデータ・コレクションのDateOrdered属性とTimeToShip属性のデータを使用して、Summit ADFサンプル・アプリケーションのShipping Time棒グラフを生成します。

図38-5 Summit ADFのShipping Timeチャートの「棒グラフの作成」ダイアログ

5. 「OK」をクリックします。

データ・バインディング・ダイアログに必要事項を入力した後で、「プロパティ」ウィンドウを使用してチャート属性の設定を指定できます。また、チャート・タグに関連付けられた子タグを使用してチャートをさらにカスタマイズできます。たとえば、凡例の表示は、Summit ADFサンプル・アプリケーションのShipping Timeチャートに対してオフになっています。チャート・コンポーネントの構成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントの使用に関する項を参照してください。

38.2.2 「データ・コントロール」パネルによるチャート作成時の処理

チャートを「データ・コントロール」パネルからドロップすると、次の処理が行われます。

- チャートのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

JDeveloperが生成するデータ・バインディングXMLは、作成する特定のチャート・タイプの物理モデルを表します。次の例は、ページ定義ファイルにJDeveloperが生成したバインディングを示しています。この例では、OrdersForCustomerデータ・コレクションのDateOrdered属性とTimeToShip属性のデータを使用して縦棒グラフが作成されています。

<tree IterBinding="OrdersForCustomerIterator" id="OrdersForCustomer5"
ChangeEventPolicy="ppr">
<nodeDefinition DefName="oracle.summit.model.views.OrdVO"
Name="OrdersForCustomer5">
<AttrNames>
<Item Value="TimeToShip"/>
<Item Value="DateOrdered"/>
</AttrNames>
</nodeDefinition>
</tree>

チャートでは、例に示す標準のツリー・バインディングが使用されます。ノード定義は、データ・コントロール(OrdersForCustomer5)の名前とインスタンス、およびデータ・コントロールのベースになっているビュー・オブジェクト(OrdVO)を示します。表示される各属性がAttrNames定義にリストされます。二重Y軸に対して構成されるチャートの場合、AttrNames定義には、2番目のY軸に表示される系列の追加アイテムが含まれます。

次の例は、OrdersForCustomerデータ・コレクションをJSFページにドラッグしたときに縦棒グラフ用に生成され、X軸にDateOrderedを、棒にTimeToShipを指定するコードを示しています。

<dvt:barChart id="barChart2" var="row"
value="#{bindings.OrdersForCustomer5.collectionModel}">  <dvt:chartLegend id="cl2"/>
<f:facet name="dataStamp">
<dvt:chartDataItem id="di2" value="#{row.TimeToShip}"
group="#{row.DateOrdered}"
series="#{bindings.OrdersForCustomer5.hints.TimeToShip.label}"/>
</f:facet>
</dvt:barChart>

38.2.3 データバインドされたファンネル・チャートの作成方法

ファンネル・チャートは、プロセス内の手順を表すために使用されます。「データ・コントロール」パネルを使用して、ファンネル・チャートを作成できます。

ファンネル・チャートでは、2つ以上、最大で3つの値が必要になります。値は、各ステージのデータの実際値とターゲット値、およびステージ値を表します。

図38-6に、サンプル・ファンネル・チャートを示します。このファンネルは、オンライン・ストアの販売へのコンバージョンのプロセスにおける、様々なステージを示しています。各ファンネル・セクションは、プロセス内の特定のステージに到達した顧客の数と、そのステージで目標とする顧客の数を示しています。ユーザーが各セクションの上に移動すると、ツールチップに、そのステージの実際値およびターゲット値の数量が示されます。

図38-6 サンプル・ファンネル・チャート

始める前に:

データバインドされたデータ視覚化チャートについて理解しておいてください。詳細は、「データバインドされたチャートの作成」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたファンネル・チャートを作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、前に示したファンネル・チャートは、SalesConversionFunnelコレクションを使用して作成されています。図38-7に、「データ・コントロール」パネル内のSalesConversionFunnelコレクションを示します。

図38-7 SalesConversionFunnelコレクションのデータ・コレクション

2. コレクションをJSFページにドラッグして、ポップアップ・メニューから「チャート」を選択します。

3. 「コンポーネント・ギャラリ」で、ファンネル・チャート・カテゴリとチャート・タイプを選択してから、「OK」をクリックします。

たとえば、垂直ファンネル・チャートを作成するには、「ファンネル」チャート・カテゴリと「ファンネル」チャート・タイプを選択します。

4. ダイアログで次のようにして、データを表示するチャートを構成します。

- 「実際値」と「ターゲット値」フィールドのドロップダウン・メニューから、データの系列を表す属性を選択します。
たとえば、サンプルのファンネル・チャートを構成するには、「実際値」フィールドのドロップダウン・メニューからNumOfVisitors属性を選択し、「ターゲット値」フィールドのドロップダウン・メニューからTargetVisitors属性を選択します。

- 「ファンネル・セクション」フィールドのドロップダウン・メニューから、データのグループを表す属性を選択します。
たとえば、サンプルのファンネル・チャートを構成するには、「ファンネル・セクション」フィールドのドロップダウン・メニューからStage属性を選択します。

図38-8に、SalesConversionFunnelコレクションのNumberOfVisitors、TargetVisitors、Stageの各属性を使用してファンネル・チャートを生成する「ファンネル・チャートの作成」ダイアログを示します。

図38-8 SalesConversionFunnelの「ファンネル・チャートの作成」

5. 「OK」をクリックします。

次の例は、JSFページにSalesConversionFunnelデータ・コレクションをドラッグし、「実際値」属性にNumOfVisitors、「ターゲット値」属性にTargetVisitors、「ファンネル・セクション」にStageを指定したときにファンネル・チャート用に生成されるコードを示しています。

<dvt:funnelChart id="funnelChart1" var="row"
value="#{bindings.SalesConversionFunnel.collectionModel}">
<dvt:funnelDataItem id="di1" value="#{row.NumberOfVisitors}"
targetValue="#{row.TargetVisitors}"
label="#{row.Stage}"/>
</dvt:funnelChart>

データ・バインディング・ダイアログに必要事項を入力した後で、プロパティ・インスペクタを使用してチャート属性の設定を指定できます。また、チャート・タグに関連付けられた子タグを使用してチャートをさらにカスタマイズできます。チャート・コンポーネントの構成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントの使用に関する項を参照してください。

38.2.4 データバインドされた円グラフの作成方法

円グラフには1つのデータ・グループが表示され、個別の系列を各区分で表します。このチャート・タイプには、複数の行(区分ごとに1つの行)を持つ1つの列が必要になります。「データ・コントロール」パネルを使用して、円グラフを作成できます。

図38-9に、Summit ADFサンプル・アプリケーションの円グラフを示します。このグラフは、各蓄積場所おける受注品目の在庫を、その品目の合計在庫の割合として表示します。ユーザーが各区分の上にマウス・ポインタを移動すると、その場所での実際の数量を示すツールチップが表示されます。この例のデータ列は、受注品目の合計在庫を表し、それぞれの区分は各備蓄場所でのインベントリ・レベルを表しています。

図38-9 各備蓄場所でのインベントリ・レベルを示す円グラフ

始める前に:

データバインドされたデータ視覚化チャートについて理解しておいてください。詳細は、「データバインドされたチャートの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされた円グラフを作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、Summit ADFサンプル・アプリケーションの「Summit Customer Management」ページに、各備蓄場所でのインベントリ・レベルを表示する円グラフを作成する場合は、「BackOfficeAppModuleDataControl」→「Customers」→「OrdersForCustomer」→「ItemsForOrder」→「InventoryForOrderItem」コレクションの順に選択します。図38-10に、「データ・コントロール」パネルのInventoryForOrderItemコレクションを示します。

図38-10 InventoryForOrderItemコレクションのデータ・コレクション

2. コレクションをJSFページにドラッグして、ポップアップ・メニューから「チャート」を選択します。

3. 「コンポーネント・ギャラリ」で、「円」チャート・カテゴリとチャート・タイプを選択してから、「OK」をクリックします。

たとえば、図38-9の円グラフを作成する場合は、「円」チャート・カテゴリと「円」チャート・タイプを選択します。

4. 「円グラフの作成」ダイアログで次の操作を実行し、データを表示する円グラフを構成します。

- 「円」フィールドのドロップダウン・メニューから、データの列に表示する属性を選択します。
たとえば、インベントリ・レベルを表示するようにSummit ADFサンプル・アプリケーションの円グラフを構成する場合は、「円」フィールドのドロップダウン・メニューからAmountInStock属性を選択します。

- 実行時に属性の値をどこに表示するかに応じて、「使用可能」リストから「区分」フィールドに属性をドラッグします。
たとえば、受注品目の各備蓄場所におけるインベントリ・レベルを表示するように、Summit ADFサンプル・アプリケーションの円グラフを構成する場合は、「円グラフの作成」ダイアログで、「使用可能」リストからCity属性をドラッグして「区分」フィールドにドロップします。

- 「属性ラベル」表で、デフォルト値を受け入れるか、「ラベル」フィールドのドロップダウン・リストから値を選択して、実行時に表示されるラベルを指定します。
基になるデータ型に応じて、「ラベル」フィールドで選択可能な項目が決まります。この選択に応じて、属性のラベルをチャートにレンダリングする方法が決まります。詳細は、「属性ラベルの使用に関する必知事項」を参照してください。

図38-11に示す「円グラフの作成」ダイアログでは、InventoryForOrderItemコレクションのAmountInStock属性とCity属性を使用して円グラフを生成します。

図38-11 InventoryForOrderItemの「円グラフの作成」

5. 「OK」をクリックします。

次の例は、InventoryForOrderItemデータ・コレクションをJSFページにドラッグしたときに円グラフ用に生成され、「円」値にAmountInStockを、「区分」値にCityを指定するコードを示しています。

<dvt:pieChart id="pieChart1" var="row"
value="#{bindings.InventoryForOrderItem1.collectionModel}">
<dvt:chartLegend/>
<dvt:pieDataItem id="di1" value="#{row.AmountInStock}" label="#{row.City}"/>
</dvt:pieChart>

データ・バインディング・ダイアログに必要事項を入力した後で、「プロパティ」ウィンドウを使用してチャート属性の設定を指定できます。また、チャート・タグに関連付けられた子タグを使用してチャートをさらにカスタマイズできます。たとえば、円の1つの区分が他の区分から分離されるように、切り離された円の区分を構成できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントの使用に関する項を参照してください。

38.2.5 データ・コントロールを使用したデータバインドされたスパーク・チャートの作成

スパーク・チャートは、表の列に、またはテキストともにインラインでトレンドまたはバリエーションを表したシンプルな要約チャートです。スパーク・チャートを作成するには、「データ・コントロール・パネル」からデータ・コントロールを挿入します。

図38-12に、「データ・コントロール」パネルからページ上にスパーク・チャートをドラッグしたときに表示される「コンポーネント・ギャラリ」を示します。

図38-12 スパーク・チャートの作成のコンポーネント・ギャラリ

バインディング・ダイアログで、選択したスパーク・チャート・タイプで表示する値を指定するように求められます。折れ線スパーク・チャート、棒スパーク・チャートおよび面スパーク・チャートには、変動する株価などの単一系列のデータ値が必要です。フローティング棒スパーク・チャートには、データ値の系列がフローティング・オフセットに1つ、棒の値のために1つの、合計2つ必要です。たとえば、フローティング積上げ棒スパーク・チャートの作成ダイアログでは、次のように指定します。

- 「棒の高さ」: 棒の値に使用するデータ値を選択するには、これを使用します。

- 「棒のフロート」: フロート・オフセット、つまり軸とフローティング棒との間の距離に使用するデータ値を選択するには、これを使用します。

図38-13に、設定済のフローティング積上げ棒スパーク・チャートの作成ダイアログを示します。

図38-13 「スパークチャート・バインディング」ダイアログ

簡単なUI優先開発のシナリオでは、「コンポーネント」ウィンドウを使用してスパーク・チャートを挿入してから、そのチャートをデータにバインドします。スパーク・チャートへのデータの提供の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のスパーク・チャートへのデータの追加方法に関する項を参照してください。

38.2.6 データバインドされたバブル・チャートと散布図の作成方法

バブル・チャートと散布図は、データ・マーカーの位置でデータを表します。バブル・チャートは、マーカーのサイズを使用してデータの追加の側面も表します。

散布図には、マーカーごとに少なくとも2つのデータ値が必要です。バブル・チャートには、マーカー・サイズごとに追加のデータ値が必要です。各データ・マーカーは次の値を表します。

- マーカーのX軸上の位置を決めるX値。

- マーカーのY軸上の位置を決めるY値。

- バブル・チャートのマーカーのサイズを決めるZ値

複数のデータ・グループの場合、データは、散布図の場合には2の倍数、バブル・チャートの場合には3の倍数である必要があります。

図38-14に、Summit組織の販売員の給与とコミッションを表示する散布図とバブル・チャートを示します。この例では、X値はコミッションによって決まり、Y値は給与によって決まります。バブル・チャートは、Z値に販売員の売上合計を使用するように構成されています。この例では、Mageeは給与とコミッションが最低ですが、売上合計が最高の販売員です。

図38-14 データバインドされた散布図およびバブル・チャートの例

始める前に:

データバインドされたデータ視覚化チャートについて理解しておいてください。詳細は、「データバインドされたチャートの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
たとえば、図38-14のバブル・チャートと散布図は、Summit ADF DVTサンプル・アプリケーションのSEmpエンティティに基づく最上位レベル・ビュー・オブジェクトを使用しています。この例では、Summit ADF従業員データベースに含まれるすべての販売責任者をビュー・オブジェクトで取得するために、TITLE_IDが2である従業員レコードをすべて取得しています。図38-15に、SalesRepViewObjビュー・オブジェクトを示します。

図38-15 Summit DVTサンプル・アプリケーションのSalesRepViewObjビュー・オブジェクト

図38-16に、SalesRepViewObj3データ・コントロールを示します。

図38-16 Summit DVTサンプル・アプリケーションのSalesRepViewObj3データ・コントロール

TotalSales属性は、SOrdViewビュー・オブジェクトのTotal属性から販売員の売上合計を計算する一時属性です(SOrdView.sum ('Total'))。ビュー・オブジェクトへの一時属性の詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたバブル・チャートまたは散布図を作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、図38-14のバブル・チャートまたは散布図を作成するには、SalesRepViewObj3コレクションを選択します。

2. コレクションをJSFページにドラッグして、ポップアップ・メニューから「チャート」を選択します。

3. 「コンポーネント・ギャラリ」で、バブル・チャートまたは散布図のカテゴリとチャート・タイプを選択してから、「OK」をクリックします。

4. 「バブル・チャートの作成」または「散布図の作成」ダイアログで、次の操作を実行してバブル・チャートまたは散布図の軸値を構成します。

- 「X軸データ・ポイント」フィールドで、ドロップダウン・リストを使用して、X軸データ・ポイントに使用するデータ・コレクション内の属性を指定します。
たとえば、X軸にコミッションの割合を表示するようにバブル・チャートまたは散布図を構成するには、ドロップダウン・リストから「CommissionPct」を選択します。

- 「Y軸データ・ポイント」フィールドで、ドロップダウン・リストを使用して、Y軸データ・ポイントに使用するデータ・コレクション内の属性を指定します。

- バブル・チャートの場合、Z軸データ・ポイント・フィールドで、ドロップダウン・リストを使用して、Z軸データ・ポイントに使用するデータ・コレクション内の属性を指定します。

5. 散布図を構成している場合は、ダイアログの「マーカー」セクションで次の操作を行って、散布図の色、形状およびツールチップを構成します。

- 色/形状の組合せにシステムで生成された値を使用するには、「自動」を選択します。色と形状の決定に個別の属性を使用するには「手動」を選択します。
「手動」を選択した場合は、「マーカーの色」および「マーカーの形状」のドロップダウン・リストで属性を選択します。

たとえば、図38-14に表示されている散布図の「マーカーの色」と「マーカーの形状」にLastNameとFirstNameを使用することを選択できます。散布図がレンダリングされるときに、凡例には図38-17に示すように色と形状の両方のエントリが含まれます。散布図のツールチップには、マーカー属性と形状属性の両方に関連付けられた値が表示されます。

図38-17 色と形状が手動で構成された散布図

- 「マーカー・タイプ」フィールドのドロップダウン・リストで、散布図の凡例に表示される値を決定する、データ・コレクション内の1つ以上の属性を指定します。散布図の凡例では、各属性が固有の色/形状の組合せで表現されます。「使用可能」リストから属性をドラッグ・アンド・ドロップするか、「追加」ドロップダウン・リストから選択できます。
入力フィールドで属性を指定した後、任意の属性を右クリックして、「右に移動」、「左に移動」、「削除」、「テキストとして処理」などのアクションに対応するポップアップ・メニューを表示できます。

- 「マーカー・ツールチップ」フィールドのドロップダウン・リストから、散布図のツールチップに使用する属性を選択します。

6. バブル・チャートを構成している場合は、ダイアログの「マーカー」セクションで次の操作を行って、バブルの色およびツールチップを構成します。

- 色にシステムで生成された値を使用するには、「自動」を選択します。色と形状の決定に個別の属性を使用するには「手動」を選択します。
「手動」を選択した場合は、「マーカーの色」および「マーカーの形状」のドロップダウン・リストで属性を選択します。

- バブルの色フィールドのドロップダウン・リストで「自動」を選択した場合は、バブル・チャートの凡例に表示される値を決定する、データ・コレクション内の1つ以上の属性を指定します。バブル・チャートの凡例では、各属性が固有の色で表現されます。「使用可能」リストから属性をドラッグ・アンド・ドロップするか、「追加」ドロップダウン・リストから選択できます。
入力フィールドで属性を指定した後、任意の属性を右クリックして、「右に移動」、「左に移動」、「削除」、「テキストとして処理」などのアクションに対応するポップアップ・メニューを表示できます。

- 「バブル・ツールチップ」フィールドのドロップダウン・リストから、バブル・チャートのツールチップに使用する属性を選択します。
デフォルトでは、バブル・チャートのツールチップには、バブル・チャートの凡例に関連付けられている1つまたは複数の属性が表示されます。たとえば、図38-14のバブル・チャートのツールチップは、Groupの販売員の姓を表示しています。ツールチップのGroupアイテムに使用する、コレクション内の別の属性を選択できます。

7. 「属性ラベル」表で、デフォルト値を受け入れるか、「ラベル」フィールドのドロップダウン・リストから値を選択して、実行時に表示されるラベルを指定します。

基になるデータ型に応じて、「ラベル」フィールドで選択可能な項目が決まります。この選択に応じて、属性のラベルをチャートにレンダリングする方法が決まります。詳細は、「属性ラベルの使用に関する必知事項」を参照してください。

8. 「OK」をクリックします。

図38-18に、SalesRepViewObj3データ・コレクションのCommissionPct、SalaryおよびTotal Sales属性のデータを使用してバブル・チャートを生成する「バブル・チャートの作成」ダイアログを示します。

図38-18 「バブル・チャートの作成」ダイアログ

「散布図の作成」ダイアログのエントリも同様ですが、バブル・サイズの選択は不要です。図38-19に、SalesRepViewObj3データ・コレクションのCommissionPctおよびSalary属性のデータを使用して散布図を生成する「散布図の作成」ダイアログを示します。

図38-19 「散布図の作成」ダイアログ

次の例は、SalesRepViewObj3データ・コレクションをJSFページにドラッグしたときにバブル・チャートと散布図用に生成され、「X軸データ・ポイント」にCommissionPct、「Y軸データ・ポイント」にSalary、バブル・チャートのZ軸データ・ポイントにTotalSalesを指定するコードを示しています。

<dvt:scatterChart id="scatterChart1" var="row"
value="#{bindings.SalesRepViewObj3.collectionModel}">
<dvt:chartLegend rendered="true" id="cl1">
<dvt:legendSection source="ag1" id="ls1"/>
</dvt:chartLegend>
<f:facet name="dataStamp">
<dvt:chartDataItem id="di1" group="#{row.LastName}" x="#{row.CommissionPct}"
y="#{row.Salary}">
<dvt:attributeGroups id="ag1" value="#{row.LastName}" type="color shape"/>
</dvt:chartDataItem>
</f:facet>
</dvt:scatterChart>
...
<dvt:bubbleChart id="bubbleChart1" var="row"
value="#{bindings.SalesRepViewObj3.collectionModel}">
<dvt:chartLegend rendered="true" id="cl1">
<dvt:legendSection source="ag1" id="ls1"/>
</dvt:chartLegend>
<f:facet name="dataStamp">
<dvt:chartDataItem id="di1" group="#{row.LastName}" x="#{row.CommissionPct}"
y="#{row.Salary}" z="#{row.TotalSales}">
<dvt:attributeGroups id="ag1" value="#{row.LastName}" type="color"/>
</dvt:chartDataItem>
</f:facet>
</dvt:bubbleChart>

マーカーおよび形状にデータ・コレクションの属性を使用して散布図を手動で構成することを選択した場合、JDeveloperは追加のdvt:legendSectionおよびdvt:attributeGroupsタグをJSFページに追加します。次の例は、変更されたエントリが太字でハイライトされた改訂コードを示しています。

<dvt:scatterChart id="scatterChart1" var="row"
value="#{bindings.SalesRepViewObj3.collectionModel}">
<dvt:chartLegend rendered="true" id="cl1">
<dvt:legendSection source="ag1" id="ls1"/>
<dvt:legendSection source="ag2" id="ls2"/>
</dvt:chartLegend>
<f:facet name="dataStamp">
<dvt:chartDataItem id="di1" group="#{row.LastName} #{row.FirstName}"
x="#{row.CommissionPct}"
y="#{row.Salary}">
<dvt:attributeGroups id="ag1" value="#{row.LastName}" type="color"/>
<dvt:attributeGroups id="ag2" value="#{row.FirstName}" type="shape"/>
</dvt:chartDataItem>
</f:facet>
</dvt:scatterChart>

データ・バインディング・ダイアログに必要事項を入力した後で、「プロパティ」ウィンドウを使用してチャート属性の設定を指定できます。また、チャート・タグに関連付けられた子タグを使用してチャートをさらにカスタマイズできます。たとえば、チャートの凡例を表示する場所を指定できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントの使用に関する項を参照してください。

38.2.7 データバインドされた極チャートおよびレーダー・チャートを作成する方法

極チャートおよびレーダー・チャートは、折れ線グラフ、棒グラフ、面チャート、バブル・チャートおよび散布図のバリエーションです。「データ・コントロール」パネルを使用して、極チャートまたはレーダー・チャートを作成できます。

極チャートおよびレーダー・チャートの要件は、使用するチャートのタイプによって異なります。レーダー折れ線チャート、レーダー面チャートおよび極棒グラフでは、1つ以上の系列を持つ2つ以上データのグループが必要となります。極散布図では位置を示すために2つ以上のデータ値が必要となり、極バブル・チャートでは3つの値、つまり、位置用の2つとバブル・サイズ用の1つが必要となります。

図38-20に示すサンプルの極線グラフは、製品のIDおよび名前に対応する、様々な製品の使用可能なインベントリ・レベルを示すように構成されています。

図38-20 サンプルの極棒グラフ

始める前に:

データバインドされたデータ視覚化チャートについて理解しておいてください。詳細は、「データバインドされたチャートの作成」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
たとえば、サンプルの極棒グラフはInventoryデータ・コレクションに基づいています。図38-21に、「データ・コントロール」パネルでのInventoryコレクションを示します。

図38-21 Inventoryのデータ・コレクション

Inventoryデータ・コレクションは、InventoryVOビュー・オブジェクトに基づいています。図38-22に、InventoryVOビュー・オブジェクトを示します。

図38-22 Summitサンプル・アプリケーションのInventoryVOビュー・オブジェクト

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSF JSPページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたレーダー・チャートまたは極チャートを作成する手順は次のとおりです。

1. 「データ・コントロール」パネルから、コレクションを選択します。

2. コレクションをJSFページにドラッグして、ポップアップ・メニューから「チャート」を選択します。

3. 「コンポーネント・ギャラリ」で、「レーダー/極」チャート・カテゴリおよびチャート・タイプを選択し、「OK」をクリックします。

たとえば、レーダー折れ線チャートを作成するには、「レーダー/極」チャート・カテゴリおよび「レーダー」チャート・タイプを選択します。

4. 極線チャート、面チャートまたは棒グラフを構成する場合は、次の手順を実行します。

- 実行時に属性の値がどのように表示されるようにするかに応じて、「使用可能」リストから入力フィールドに属性をドラッグします。
たとえば、インベントリ・レベルが表示されるようにサンプル・アプリケーションの極棒グラフを構成するには、AmountInStock属性を「使用可能」リストから「棒グラフの作成」ダイアログの「棒」フィールドにドラッグします。製品IDおよび名前が表示されるようにチャートを構成するには、ProductId属性およびName属性を「使用可能」リストから「棒グラフの作成」ダイアログの「X軸」フィールドにドラッグします。

5. 「OK」をクリックします。

図38-23に、Inventoryデータ・コレクションのAmountInStock、ProductIdおよびName属性のデータを使用して極線グラフを生成するレーダー・チャートの作成ダイアログを示します。

図38-23 レーダー・チャートの作成ダイアログ

次の例は、Inventoryデータ・コレクションをJSFページにドラッグし、「Y軸データ・ポイント」のAmountInStockおよび「Y軸データ・ポイント」のProductIdとName名前を指定すると、バブル・チャートおよび散布図用に生成されるコードを示しています。レーダー・チャートおよび極チャートは個別にタグを持つのではなく、coordinateSystem属性がpolarに設定された基本的なチャートであることに注意してください。

<dvt:lineChart coordinateSystem="polar" polarGridShape="polygon" id="lineChart1" var="row" value="#{bindings.Inventory.collectionModel}">
<f:facet name="dataStamp">
<dvt:chartDataItem id="di1"      series="#{bindings.Inventory.hints.AmountInStock.label}" value="#{row.AmountInStock}" group="#{row.ProductId} #{row.Name}"/>
</f:facet>
</dvt:lineChart>

データ・バインディング・ダイアログに必要事項を入力した後で、プロパティ・インスペクタを使用してチャート属性の設定を指定できます。また、チャート・タグに関連付けられた子タグを使用してチャートをさらにカスタマイズできます。チャート・コンポーネントの構成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントの使用に関する項を参照してください。

38.2.8 データバインドされた株価チャートの作成方法

株価チャートは、高値、安値、始値、終値など、株式の期間マイルストン値の追跡に使用されます。「データ・コントロール」パネルを使用して、株価チャートを作成できます。

選択したチャート・タイプによって、最小で4個、最大で7個の値が株価チャートに必要になります。図38-24に、株式と始値、終値、高値、安値、期間、出来高を表示するように構成されたサンプル株価チャートを示します。ユーザーが各株式の上に移動すると、ツールチップに、その株式のすべての値の数量が示されます。

図38-24 サンプル株価チャート

始める前に:

データバインドされたデータ視覚化チャートについて理解しておいてください。詳細は、「データバインドされたチャートの作成」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされた株価チャートを作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、前に示した株価チャートは、StockView1コレクションを使用して作成されています。図38-25に、「データ・コントロール」パネルでのStockView1コレクションを示します。

図38-25 StockView1コレクションのデータ・コントロール

2. コレクションをJSFページにドラッグして、ポップアップ・メニューから「チャート」を選択します

3. 「コンポーネント・ギャラリ」で、株価チャート・カテゴリとチャート・タイプを選択してから、「OK」をクリックします。
たとえば、サンプルで構成されたチャートを作成するには、株価チャート・カテゴリと、「出来高と始値 - 高値 - 安値 - 終値のローソク足」チャート・タイプを選択します。

4. ダイアログで次のようにして、データを表示するチャートを構成します。

- 「株価」フィールドのドロップダウン・メニューから、株式の銘柄名を示す属性を選択します。「テキスト・リソースの選択」オプションを使用してテキスト値を入力するか、または式ビルダーを使用してJSF式を入力することもできます。

- 選択した株価チャートのタイプに応じたラベルが表示されます。各ラベルのドロップダウン・メニューから属性を1つずつ選択します。
たとえば、前述の例のチャートを構成するには、「始値」、「高値」、「安値」、「終値」、「出来高」、「時間」の各ラベルで、Open、High、Low、Close、Volume、MarketDate属性をそれぞれ選択します。

図38-26に、前述のサンプルで構成された株価チャートのチャートの作成ダイアログを示します。

図38-26 StockView1コレクションのチャートの作成ダイアログ

5. 「OK」をクリックします。

次の例は、前述のサンプルの株価チャートの作成に際し、株価データ・コレクションをJSFページにドラッグして値を指定したときに生成されたコードを示しています。

<dvt:stockChart id="stockChart1" var="row" value="#{bindings.StockView1.collectionModel}">
<dvt:chartY2Axis id="cya1"/>
<dvt:stockDataItem id="di1" volume="#{row.Volumn}" high="#{row.High}" low="#{row.Low}" series="Stock"
close="#{row.Close}" open="#{row.Open}" group="#{row.MarketDate}"/>
</dvt:stockChart>

データ・バインディング・ダイアログに必要事項を入力した後で、プロパティ・インスペクタを使用してチャート属性の設定を指定できます。また、チャート・タグに関連付けられた子タグを使用してチャートをさらにカスタマイズできます。チャート・コンポーネントの構成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のチャート・コンポーネントの使用に関する項を参照してください。

38.2.9 属性ラベルの使用に関する必知事項

「チャートの作成」ダイアログで属性のラベルを構成するときに、「ラベル」フィールドで選択できる項目は基になるデータ型によって決まります。この選択に応じて、属性のラベルをチャートにレンダリングする方法が決まります。

属性がデータ値を表している場合、「ラベル」フィールドの選択肢は次のようになります。

- 「属性名の使用」: 基になるViewObjectに含まれる該当の属性のUIHintsから取得したラベルを使用して値を文字列としてレンダリングする場合に選択します。これはデフォルト選択です。

- 「ラベルなし」: ラベルをレンダリングしない場合は、これを選択します。メトリックが1つで、結果として表示されたチャートを説明する独自の説明テキストをページに表示する場合に、この選択肢は役に立ちます。

- 「テキスト・リソースの選択」: 「テキスト・リソースの選択」ダイアログを開いて、ラベルに使用するテキスト・リソースを選択または追加するには、これを選択します。テキスト・リソースは、アプリケーション・リソース・バンドルからの翻訳可能な文字列です。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

- 「式ビルダー」: 「式ビルダー」ダイアログを開いて、実行時に該当のラベルについて実行する式を作成するには、これを選択します。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

属性がデータ値のカテゴリを表す場合は、次の選択肢があります。

- 「属性値の使用」: カテゴリ・ラベルとして属性値をレンダリングする場合に選択します。これはデフォルト選択です。

- ドロップダウン・リストで、ラベルの代替の属性を選択します。たとえば、従業員IDのかわりに従業員名をラベルに使用します。

38.3 データバインドされたゲージの作成

ゲージは、売上合計、在庫レベル、温度、速度などの単一のデータ値をプロットします。しきい値を使用すると、ゲージでは、色を使用して許容範囲または非許容範囲などの状態情報を表示できます。

たとえば、ゲージ値軸では、赤、黄、緑の色の範囲を示して、低、中、高の状態を表す場合があります。データバインドされた1つのゲージ・コンポーネントは、使用するデータ・コレクション内の行数に応じて、単一のゲージまたはゲージの列を作成できます。データ・コレクションでは、各行に単一のゲージの値が含まれます。

ゲージ用のコンポーネント・ギャラリを使用すると、4つのゲージ・カテゴリから選択できます。

表38-2 コンポーネント・ギャラリのADFゲージ・カテゴリ

イメージ

カテゴリ

説明

ダイアル

円形の軸にプロットされたメトリック値を表示します。ゲージの背景属性によって、ゲージの背景が矩形、円形、半円形のいずれで表示されるかが決まります。インジケータは、軸上のダイアル・ゲージのメトリック値を指します。

LED

キー・パフォーマンス・インディケータ(KPI)などの指標を図示します。LEDゲージには、ステータスを示すために色を使用する円形または矩形、カラー・インジケータに加えて上、左、右または下を指す三角形または矢印など、数種の形状を使用できます。

評価

メトリック値の入力を表示し、オプションで受け入れます。このゲージは、通常、映画の星評価など、製品やサービスの評価を示すために使用されます。

ステータス・メーター

水平または円形の軸にメトリック値を表示します。内側の矩形は、外側の矩形に表示された範囲に対する現在の測定値のレベルを示します。オプションで、ステータス・メーターは、メトリック値が事前定義されたしきい値内のどこに含まれるかを色で示します。

各カテゴリには、1つ以上のゲージ・タイプが含まれます。単一ゲージの作成時に表示されるコンポーネント・ギャラリを詳しく調べて、使用可能なすべてのゲージ、カテゴリ・タイプおよびそれぞれの説明を確認してください。図38-27に、ADFゲージ用に表示されるコンポーネント・ギャラリを示します。

図38-27 ADFゲージのコンポーネント・ギャラリ

データ・バインディングのプロセスは、作成するゲージのタイプに関係なく、基本的に同じです。必要なものは、メトリック値(つまり、ゲージで示す指標)のみです。ただし、データ・コレクション内の行に最大、最小、しきい値などの範囲情報が含まれている場合は、その値をゲージにバインドして動的な設定を示すことができます。ゲージの上部または下部ラベルで使用する情報がデータ・コレクション内に含まれている場合も、その値をゲージにバインドできます。

データ・バインディングの完了後に、ゲージをカスタマイズする方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のゲージ・コンポーネントの使用に関する項を参照してください。

38.3.1 データバインドされたダイアル・ゲージの作成方法

ADFゲージ・コンポーネントを使用して、円形、ドーム型または矩形の背景にダイアル・ゲージを作成できます。ゲージのインジケータでは、メトリックの現在の値を指定します。

図38-28に示す単一のダイアル・ゲージは、Summit ADF DVTサンプル・アプリケーションの在庫品目についてのAmountInStockデータからゲージを作成した場合に表示されます。AmountInStockメトリックの値(0.650K)は、ゲージの中心のラベルに表示されます。

図38-28 在庫ダイアル・ゲージで示される数量

データ・コントロールを使用してダイアル・ゲージを作成する場合は、ゲージ・コンポーネントをデータ・コレクションの属性にバインドします。JDeveloperを使用すると、「データ・コントロール」パネルから属性をドラッグ・アンド・ドロップすることで、この処理を宣言的に実行できます。属性をドラッグ・アンド・ドロップした後で、ダイアル・ゲージの作成ダイアログを使用してゲージを構成します。

図38-29に示す「ダイヤル・ゲージの作成」ダイアログは、図38-28に示した在庫数量ダイアル・ゲージ用に構成されていて、図38-27に示したゲージ・タイプを使用しています。

図38-29 在庫数量ダイアル・ゲージの「ダイアル・ゲージの作成」ダイアログ

始める前に:

データバインドされたデータ視覚化ゲージについて理解しておいてください。詳細は、「データバインドされたゲージの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたダイアル・ゲージを作成するには:

1. 「データ・コントロール」パネルから、コレクションの属性を選択します。

たとえば、Summit ADF DVTサンプル・アプリケーションに、在庫品目のインベントリ・レベルについて表示するダイアル・ゲージを作成する場合は、ProductInventoryView1コレクションのAmountInStock属性を選択します。図38-30は、AmountInStock属性を選択している「データ・コントロール」パネルのProductInventoryView1コレクションを示しています。

図38-30 在庫品目の在庫数量を含むデータ・コレクション

2. JSFページに属性をドラッグして、ポップアップ・メニューから「ゲージ」を選択します。

3. 「コンポーネント・ギャラリ」で、ゲージのカテゴリとタイプを選択し、「OK」をクリックします。

4. 「ダイアル・ゲージの作成」ダイアログで、次の操作を実行します。

- 「メトリック」フィールドで、データ・コレクション内の列がゲージで図示する実際の値を保持していることを確認します。このダイアログで必須なのは、この値のみです。

- 「最小」フィールドで、ゲージ範囲の最小値がデータ・コレクションに格納されている場合は、ドロップダウン・リストから、この値が含まれている列を選択します。または、範囲の最小数を指定します。値を指定しない場合、最小値はデフォルトで0になります。

- 「最大」フィールドで、ゲージ範囲の最大値がデータ・コレクションに格納されている場合は、この値が含まれている列を選択します。または、最大値を指定します。値を指定しない場合、最大値はデフォルトで100になります。

- 「背景」フィールドで、ドロップダウン・リストから背景を選択します。
使用可能な形状には、alta、light、antiqueまたはdarkシェーディングの付いた円形、ドーム型および矩形が含まれます。デフォルトでは、ゲージの背景は、現在のスキンのプライマリ設計を返すautoに設定されます。

- 「インジケータ」フィールドで、ドロップダウン・リストからインジケータ・スタイルを選択します。
使用可能なインジケータには、alta、antique、darkおよびlightが含まれます。デフォルトでは、インジケータは、ゲージの背景に一致するインジケータを選択するautoに設定されます。

- 「メトリック・ラベルの表示」チェック・ボックスで、「メトリック・ラベルの表示」チェック・ボックスを選択して、ゲージのメトリック・ラベルを表示します。メトリック・ラベルには、ゲージの実際のメトリック値が含まれます。たとえば、特定のアイテムの在庫数量が63の場合、メトリック・ラベルには63と表示されます。

5. 「OK」をクリックします。

「プロパティ」ウィンドウでは、ゲージのバインディングの完了後に、ゲージ・タグおよびその子タグの追加属性の値を設定して、コンポーネントをカスタマイズできます。たとえば、スケーリングなしで在庫数量を表示するように在庫数量ゲージを構成する場合は、メトリックのscaling属性とティック・ラベルをnoneに設定します。

また、既存のゲージ・バインディングを確認して調整するには、そのゲージ・コンポーネントの「プロパティ」ウィンドウで「編集」アイコンをクリックします。

データ・バインディングの完了後に、ゲージをカスタマイズする方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のゲージ・コンポーネントの使用に関する項を参照してください。

38.3.2 データ・コントロールからのダイアル・ゲージの作成時の処理

ゲージを「データ・コントロール」パネルからドロップすると、次の処理が行われます。

- ゲージのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

次の例は、倉庫内にある製品のインベントリ・レベルを表示するダイアル・ゲージ用にJDeveloperが生成したバインディングを示しています。このコード例では、ゲージ・メトリックがProductInventoryView1データ・コレクション内のAmountInStock属性から動的に値を受け取ることを示しています。

<bindings>
<attributeValues IterBinding="ProductInventoryView1Iterator" id="AmountInStock">
<AttrNames>
<Item Value="AmountInStock"/>
</AttrNames>
</attributeValues>
</bindings>

次の例は、ダイアル・ゲージに対してJDeveloperによりJSFページに生成されたコードを示しています。

<dvt:dialGauge id="dialGauge1" indicator="needleAlta" minimum="0"
maximum="2600" background="domeAlta"
value="#{bindings.AmountInStock.inputValue}">
<dvt:gaugeMetricLabel rendered="true" id="gml1"/>
</dvt:dialGauge>

38.3.3 データバインドされた評価ゲージの作成方法

評価ゲージは、メトリック値の入力を表示し、オプションで受け入れます。このゲージは、通常、映画の星評価など、製品やサービスの評価を示すために使用されます。

図38-31に、Summit ADFサンプル・アプリケーションの顧客の信用格付けを示すために使用されている評価ゲージの例を示します。この例では、顧客の信用格付けが低く、星が1つ割り当てられています。その他の評価には、普通の信用を示す星2つ、高い信用を示す星3つ、非常に高い信用を示す星4つがあります。

図38-31 Summit ADFサンプル・アプリケーションの評価ゲージ

データ・コントロールを使用して評価ゲージを作成する場合は、評価ゲージをデータ・コレクションの属性にバインドします。JDeveloperを使用すると、「データ・コントロール」パネルから属性をドラッグ・アンド・ドロップすることで、この処理を宣言的に実行できます。属性をドラッグ・アンド・ドロップした後で、「評価ゲージの作成」ダイアログを使用してゲージを構成します。

図38-32に、図38-31の評価ゲージに対して完成した「評価ゲージの作成」ダイアログを示します。この例では、評価ゲージは4つの信用格付けを表すために最大値の4に設定されています。

図38-32 Summitの信用格付けゲージの「評価ゲージの作成」ダイアログ

始める前に:

データバインドされたデータ視覚化ゲージについて理解しておいてください。詳細は、「データバインドされたゲージの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされた評価ゲージを作成する手順:

1. 「データ・コントロール」パネルから、コレクションの属性を選択します。

たとえば、Summit ADFサンプル・アプリケーションの評価ゲージを作成して、顧客の信用格付けを表示するには、CustomerコレクションでCreditRatingId属性を選択します。図38-30は、CreditRatingId属性を選択している「データ・コントロール」パネルのCustomerコレクションを示しています。

図38-33 在庫品目の在庫数量を含むデータ・コレクション

2. JSFページに属性をドラッグして、ポップアップ・メニューから「ゲージ」を選択します。

3. 「コンポーネント・ギャラリ」で、ゲージのカテゴリとタイプを選択し、「OK」をクリックします。

4. 「評価ゲージの作成」ダイアログで、次の操作を実行します。

- 「評価値」フィールドで、データ・コレクション内の列がゲージで図示する実際の値を保持していることを確認します。このダイアログで必須なのは、この値のみです。

- 「最小」フィールドで、ゲージ範囲の最小値がデータ・コレクションに格納されている場合は、ドロップダウン・リストから、この値が含まれている列を選択します。または、範囲の最小数を指定します。値を指定しない場合、最小値はデフォルトで0になります。

- 「最大」フィールドで、ゲージ範囲の最大値がデータ・コレクションに格納されている場合は、この値が含まれている列を選択します。または、最大値を指定します。値を指定しない場合、最大値はデフォルトで5になります。

- 「図形」フィールドで、ドロップダウン・リストから背景を選択します。
使用可能な形状には、円形、ひし形、矩形および星型が含まれます。

5. 「OK」をクリックします。

「プロパティ」ウィンドウでは、ゲージのバインディングの完了後に、ゲージ・タグおよびその子タグの追加属性の値を設定して、コンポーネントをカスタマイズできます。たとえば、顧客の信用格付けを更新できるように評価ゲージを構成するには、評価ゲージのreadOnly属性をfalseに設定します。

Summit ADFの例では、評価ゲージの値は作成時にCreditRatingIdに設定されました。ただし、CreditRatingIdは実際には1から4の範囲で、1が最高評価です。格付けを評価ゲージの星に変換するには、ゲージの作成後に「コード・エディタ」でソース・コードを編集し、評価ゲージの値を#{5 - bindings.CreditRatingId.inputValue}で置換します。

次の例は、Summit ADF評価ゲージのJSFページのコードを示しています。

<dvt:ratingGauge id="ratingGauge1" minimum="0" maximum="4"
value="#{5 - bindings.CreditRatingId.inputValue}" shape="star"/>

また、既存のゲージ・バインディングを確認して調整するには、そのゲージ・コンポーネントの「プロパティ」ウィンドウで「編集」アイコンをクリックします。

データ・バインディングの完了後に、ゲージをカスタマイズする方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のゲージ・コンポーネントの使用に関する項を参照してください。

38.3.4 データバインドされたADF表へのゲージの組込み

データバインドされたADF表に、データバインドされたゲージを追加するには、表を編集または作成しているときに、列コンテンツを指定する際にgaugeコンポーネントを選択します。

図38-34に、表の一部を示します。この表は、倉庫内のすべての製品をADF DVTサンプル・アプリケーションに表示します。この例では、AmountInStock列に、各製品の在庫数量と、値が許容範囲内にあるかどうかを示すLEDゲージが組み込まれています。

図38-34 ADFのLEDゲージの表

38.3.4.1 データバインドされたADF表にゲージを組み込む方法

データバインドされたADF表にゲージを追加するには、「データ・コントロール」パネルからJSFページに、ゲージ・メトリックを含むデータ・コレクションをドラッグして、作成するゲージのタイプを指定します。

始める前に:

データバインドされたデータ視覚化ゲージについて理解しておいてください。詳細は、「データバインドされたゲージの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたADF表にゲージを組み込むには:

1. 「データ・コントロール」パネルから、ADF表に使用するコレクションを選択します。

たとえば、Summit ADF DVTサンプル・アプリケーションに、倉庫内の製品ごとのインベントリ・レベルを表示する表を作成する場合は、ProductInventoryView1コレクションを選択します。図38-35に、「データ・コントロール」パネル内のProductInventoryView1コレクションを示します。

図38-35 ProductInventoryView1データ・コレクション

2. JSFページにコレクションをドラッグし、ポップアップ・メニューから「表」→「ADF表」を選択します。

3. 「表の列の編集」ダイアログで、ゲージ・メトリックを表す列を選択します。

たとえば、ゲージ・メトリックとして使用する列にAmountInStock列を選択します。

4. 「使用するコンポーネント」メニューから、作成するゲージのタイプを選択します。

たとえば、「ゲージ・ステータス・メーター」を選択すると、表にステータス・メーターが追加されます。

5. 表の構成を完了します。

ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

図38-36は、図38-34に示した表の必要事項を入力したダイアログです。このダイアログでは、AmountInStock列で「LEDゲージ」が選択されています。

図38-36 LEDゲージを示す「表の作成」ダイアログ

6. 「OK」をクリックして、JSFページに表を追加します。

「プロパティ」ウィンドウでは、表のバインディング完了後に、ゲージ・タグおよびその子タグの追加属性の値を設定してコンポーネントをカスタマイズできます。たとえば、図38-34のLEDゲージは、しきい値を使用して在庫レベルが許容範囲内かどうかを示すように構成されています。ゲージしきい値の構成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のゲージしきい値の構成方法に関する項を参照してください。

既存の表バインディングを確認して調整するには、表コンポーネントの「プロパティ」ウィンドウで「編集」アイコンをクリックします。

データバインドされたADF表の作成方法および構成方法の詳細は、「ADFによるデータバインドされた表の作成」を参照してください。ゲージ・コンポーネントの使用とカスタマイズの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のゲージ・コンポーネントの使用に関する項を参照してください。

38.3.4.2 ADF表へのゲージの組込み時の処理

データバインドされたADF表にゲージを組み込むと、ゲージのメトリック属性がページ定義ファイルに追加され、JSFページのUIコンポーネントが更新されます。

次の例は、図38-34で示したADF表のバインディングを示しています。

<bindings>
<tree IterBinding="ProductInventoryView1Iterator" id="ProductInventoryView1">
<nodeDefinition DefName="model.ProductInventoryView"
Name="ProductInventoryView10">
<AttrNames>
<Item Value="ProductId"/>
<Item Value="Name"/>
<Item Value="ShortDesc"/>
<Item Value="AmountInStock"/>
<Item Value="ReorderPoint"/>
<Item Value="MaxInStock"/>
<Item Value="WarehouseId"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

次の例は、ADF表のJSFページに追加されたコードを示しています。gauge要素は、太字で強調してあります。簡潔にするために、表の最初の3列のみを表示しています。

<af:table value="#{bindings.ProductInventoryView1.collectionModel}" var="row"
rows="#{bindings.ProductInventoryView1.rangeSize}"
emptyText="#{bindings.ProductInventoryView1.viewable ?
'No data to display.' : 'Access Denied.'}"
rowBandingInterval="0"
fetchSize="#{bindings.ProductInventoryView1.rangeSize}" id="t1"
summary="Table Showing Product Inventory">
<af:column headerText="#{bindings.ProductInventoryView1.hints.ProductId.label}"
id="c1" width="100"
rowHeader="true">
<af:outputText value="#{row.ProductId}"
shortDesc="#{bindings.ProductInventoryView1.hints.ProductId.tooltip}"
id="ot1">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.ProductInventoryView1.hints.ProductId.format}"/>
</af:outputText>
</af:column>
<af:column headerText="#{bindings.ProductInventoryView1.hints.Name.label}"
id="c2" width="100">
<af:outputText value="#{row.Name}"
shortDesc="#{bindings.ProductInventoryView1.hints.Name.tooltip}" id="ot2"/>
</af:column>
<af:column headerText="#{bindings.ProductInventoryView1.hints.ShortDesc.label}"
id="c3" width="100">
<af:outputText value="#{row.ShortDesc}"
shortDesc="#{bindings.ProductInventoryView1.hints.ShortDesc.tooltip}" id="ot3"/>
</af:column>
<af:column headerText="#{bindings.ProductInventoryView1.hints.AmountInStock.label}"
id="c4" width="72" align="center">
<dvt:ledGauge id="ledGauge1" value="#{row.bindings.AmountInStock.inputValue}"
shortDesc="#{bindings.ProductInventoryView1.hints.AmountInStock.tooltip}"
maximum="3000">
<dvt:gaugeMetricLabel rendered="true" scaling="none" id="gml1"/>
<dvt:gaugeThreshold id="gt1" maximum="#{row.bindings.ReorderPoint.inputValue}"
color="#d62800"/>
<dvt:gaugeThreshold id="gt2" maximum="#{row.bindings.MaxInStock.inputValue}"
color="#63a500"/>
<dvt:gaugeThreshold id="gt3" color="#e7e700"/>
</dvt:ledGauge>
</af:column>

... remaining columns omitted
</af:table>

38.4 データバインドされた統計図表の作成

ADF DVT統計図表コンポーネントは、絶対数や母集団の中の部分集合の相対的なサイズをアイコンを使用して視覚化するときに使用します。統計図表は、従来の表やリストよりも魅力的かつ効果的に数値情報を表現とするとして、インフォグラフィックで広く使用されています。

図38-37は、母集団の中の2つの部分集合を表現した基本的な統計図表を示しています。このデータには2行の情報が含まれており、各行が名前、カウント、色の情報を持っています。

図38-37 サンプル統計図表

統計図表のエンド・ユーザー機能とプレゼンテーション機能、ユースケース、タグ構造、統計図表への特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の統計図表コンポーネントの使用方法を参照してください。

38.4.1 データバインドされた統計図表の作成方法

統計図表は絶対数や母集団の中の部分集合の相対的なサイズを視覚化するために使用されます。「データ・コントロール」パネルを使用して、統計図表を作成できます。

始める前に:

データバインドされた統計図表について理解しておいてください。詳細は、「データバインドされた統計図表の作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされた統計図表を作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、図38-37に示されたデータ・コレクションを使用するには、PictoChartDataコレクションを選択します。図38-38に、「データ・コントロール」パネル内のコレクションを示します。

図38-38 サンプル統計図表のデータ・コントロール

2. コレクションをJSFページにドラッグして、メニューから「統計図表」を選択します。

3. 「統計図表の作成」ダイアログで、次の操作を実行します。

- 「名前」フィールドで、表示するツールチップの値を指定します。
たとえば、サンプルの統計図表を構成するには、Name属性を選択します。

- オプションで「カウント」フィールドに、図形または画像の描画回数を数値で指定します。データ・アイテムまたはテキスト・リソースを指定するか、またはドロップダウン・リストから式ビルダーを使用できます。値を指定しなかった場合、デフォルト値1が使用されます。
たとえば、サンプルの統計図表を構成するには、Count属性を選択します。

図38-39に、値が入力された「統計図表の作成」ダイアログを示します。

図38-39 「統計図表の作成」ダイアログ

4. 「OK」をクリックします。

統計図表のバインディングの完了後、「プロパティ」ウィンドウを使用して統計図表タグおよびその子タグの追加属性に値を設定し、コンポーネントをカスタマイズできます。統計図表コンポーネントの構成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の統計図表コンポーネントの使用に関する項を参照してください。

38.4.2 データ・コントロールからの統計図表の作成時の処理

データ・コントロールから統計図表を作成するには、「データ・コントロール」パネルからコントロールをドラッグし、JSFページ上の対応するコンテナ上にドロップします。

統計図表を「データ・コントロール」パネルからドロップすると、次の処理が行われます。

- 統計図表のバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

次の例は、サンプルの統計図表に対してJDeveloperが生成したバインディングを示しています。

<tree IterBinding="PictoChartDataIterator" id="PictoChartData" ChangeEventPolicy="ppr">
<nodeDefinition DefName="view.prototype.PictoChartData" Name="PictoChartData">
<AttrNames>
<Item Value="Name"/>
<Item Value="Count"/>
</AttrNames>
</nodeDefinition>
</tree>

次の例は、統計図表に対してJDeveloperによりJSFページに生成されたコードを示しています。

<dvt:pictoChart id="pictoChart1" var="row" value="#{bindings.PictoChartData.collectionModel}">
<dvt:pictoChartItem name="#{row.Name}" count="#{row.Count}" id="pci1"/>
</dvt:pictoChart>

統計図表の作成後、統計図表の編集ダイアログでバインディングを変更したり、ルールを追加したりできます。このダイアログを開くには、統計図表コンポーネントで「プロパティ」ウィンドウの「編集」アイコンをクリックします。また、ビジュアル・エディタで統計図表のコードを直接編集するか、「プロパティ」ウィンドウで値を設定して、属性をカスタマイズすることもできます。たとえば、「プロパティ」ウィンドウまたはコード・エディタで母集団の中の部分集合に色を設定したり、データ・アイテムの図形を設定したりできます。次の例で強調表示した部分が、関連するコードです。

<dvt:pictoChartItem name="#{row.Name}" count="#{row.Count}" color="#{row.Color}"
shape="human" id="pci1"/>

39 データバインドされたNBoxコンポーネントの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータから、NBoxコンポーネントを作成する方法について説明します。このピボット・テーブルの作成には、Fusion WebアプリケーションのADFデータ・コントロールとADF Facesコンポーネントを使用します。具体的には、ADFデータ視覚化コンポーネントのnBoxを使用して、ビジネス・データを視覚的に表現する方法について説明します。ここでは、ADFデータ・コントロールを使用して、データ優先開発でNBoxを作成する方法について説明します。

簡単なUI優先開発を使用してページを設計する場合は、NBoxをページに追加してから、データ・バインディングを構成してください。nBoxコンポーネントのデータ要件、タグ構造および外観と動作のカスタマイズ・オプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のNBoxコンポーネントの使用方法に関する項を参照してください。

この章の内容は次のとおりです。

- ADFデータ視覚化NBoxコンポーネントについて

- データバインドされたNBoxコンポーネントの作成

39.1 ADFデータ視覚化NBoxコンポーネントについて

ADFデータ視覚化コンポーネントは、ビジネス・データを視覚的に表示、分析するための幅広いグラフィック機能と表機能を提供します。コンポーネントをレンダリングできるようにするには、これらのコンポーネントをそれぞれ、データにバインドする必要があります。コンポーネントの外観は表示されるデータによって変わるからです。

ADFのnBoxコンポーネントは、行と列で視覚的に表される2次元のグリッドに沿ってデータを視覚化および比較するために使用できる対話型コンポーネンを生成します。nBoxコンポーネントは、データを表すノード、およびそのノードが配置されるセルが含まれるグリッドの2つの部分から構成されます。ノードの数がセルに割り当てられた領域よりも大きい場合、NBoxでは、ユーザーがクリックして追加のノードにアクセスできるインジケータが表示されます。

たとえば、従業員のポテンシャルとパフォーマンスのデータの比較にnBoxコンポーネントを使用できます(行は従業員のポテンシャルを表し、列は従業員のパフォーマンスを表しています)。従業員を表すノードは、適切なセル内にスタンプされています。

図39-1 従業員のポテンシャルとパフォーマンスを比較するNBoxコンポーネント

接頭辞dvt:は、各データ視覚化コンポーネント名の先頭に付いて、そのコンポーネントがADFデータ視覚化ツール(DVT)のタグ・ライブラリに属することを示します。

39.1.1 エンド・ユーザー機能およびプレゼンテーション機能

魅力的な外観を備えたデータ視覚化コンポーネントを使用すると、エンド・ユーザーは複雑なビジネス・データを理解して分析できるようになります。このコンポーネントは機能が豊富で、そのまますぐに使用できる対話型のサポートも用意されています。NBoxコンポーネントのエンド・ユーザー機能とプレゼンテーション機能の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のエンド・ユーザー機能とプレゼンテーション機能に関する項を参照してください。

39.1.2 データ視覚化コンポーネントのユースケースと例

各データ視覚化のユースケースと例の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のNBoxのユースケースと例に関する項を参照してください。

39.1.3 データ視覚化コンポーネントの追加機能

データ視覚化コンポーネントをデータ・バインドする前に、その他のOracle ADF機能について理解しておいてください。また、いったんデータ視覚化コンポーネントをページに追加すると、検証やアクセシビリティなどの機能を追加する必要があることに気付く場合があります。データ視覚化コンポーネントで使用されるその他の機能へのリンクは、次のとおりです。

- 部分ページ・レンダリング: データ視覚化コンポーネントをリフレッシュして、ページの別のコンポーネントで実行されたアクションに基づく新しいデータを表示できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の部分ページ・コンテンツの再レンダリングに関する項を参照してください。

- パーソナライズ: ユーザーは実行時にデータ視覚化コンポーネントの表示を変更できますが、ユーザーがカスタマイズできるようにアプリケーションを構成していないかぎり、ユーザーがページを終了するとそれらの値は保持されません。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページでのユーザー・カスタマイズの許可に関する項を参照してください。

- アクセシビリティ: データ視覚化コンポーネントをアクセス可能にできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のアクセス可能なADF Facesページの開発に関する項を参照してください。

- スキンおよびスタイル: アプリケーションに適用するADFスキンを使用するか、スタイル関連のプロパティ(styleClassまたはinlineStyle)を使用してCSSスタイル・プロパティを直接適用することで、データ視覚化コンポーネントの外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のスタイルおよびスキンを使用した外観のカスタマイズに関する項を参照してください。

- プレースホルダ・データ・コントロール: 最終的にページのデータ視覚化コンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールの使用を検討します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

39.2 データバインドされたNBoxコンポーネントの作成

ADFのNBoxコンポーネントでは、データがグリッド・レイアウトで表示され、2次元で表したり、データの大きさを表すように使用する行および列の数を構成可能です。ノードは実際のデータを表し、そのノードの値が、各セルに設定された範囲または大きさのいずれに相当するかに応じて、グリッドのセルの内部にスタンプされます。

図39-2は、3つの行と4つの列からなるグリッドが表示されるように構成したNBoxの例を示しています。各行は、Low、MediumまたはHighというラベルの付いた人口データ範囲を表しています。各列は、Lower、Lo-Mid、Hi-MidまたはUpperというラベルの付いた収入データ範囲を表しています。ノードは州を表しており、州の人口と収入レベルの値に基づいてセルに挿入されます。また、NBoxの例では、オプション属性グループを使用して、Divisionの値によって各ノードを色分けし、Regionの値によってノードのアイコン・マーカーの図形を変えています。

図39-2 米国の州、収入および人口を示すNBox

NBoxの作成ウィザードでは、NBoxを作成してデータにバインドするための宣言的サポートが提供されます。ウィザードページでは、次の操作を行うことができます。

- 次を含む、NBoxの初期レイアウトを指定します。

- 行および列の数(必須)

- NBoxの各行および列の値(必須)

- NBoxの行および列のタイトル

- NBoxの各行および列のラベル

- 次を含む、NBoxのノードを構成します。

- ノードの行と列の配置を決定するためにデータ・コレクションから使用する属性(必須)

- プライマリ・ノードおよびセカンダリ・ノードのラベル

- 指定した属性に応じて色別または図形別にノードを分けるための属性グループ

- ノードのアイコンまたはインジケータに使用するイメージ

NBoxウィザードの完了後、NBoxがページに追加されたら、「プロパティ」ウィンドウを使用してNBoxをさらにカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のNBoxコンポーネントの使用方法に関する項を参照してください。

39.2.1 ADFデータ・コントロールを使用したNBoxコンポーネントの作成方法

データ・コントロールを使用してDVT NBoxを作成するには、dvt:nBoxコンポーネントをコレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

ヒント:

また、「コンポーネント」ウィンドウからNBoxをドラッグして、NBoxを作成することもできます。この方法では、コンポーネントをデータにバインドする前に、NBoxのユーザー・インタフェースを設計できます。

始める前に:

データバインドされたNBoxについて理解しておくと役立ちます。詳細は、「ADFデータ視覚化NBoxコンポーネントについて」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、NBoxのデータ・モデルで必要な、ビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
図39-3は、図39-2に示されているNBoxのデータ・コントロールを示しています。この例では、CensusView1にNBoxのデータ・コレクションが含まれています。NBoxのノードは、州の名前で識別された長方形の枠として視覚的に表されます。各ノードは、ノードのPopulation2006Level属性およびIncome2005Class属性の値に応じて、NBoxのセルの1つに挿入されます。

図39-3 米国の収入と人口を示すNBoxのデータ・コントロール

Population2006Level属性とIncome2005Class属性は一時属性として定義され、その値はデータ・コレクション内のPopulation2006属性とIncome2005属性から導出されます。この例では、行が範囲として定義され、最も低い範囲がNBoxの一番下の行に表示されます。たとえば、Population2006の値が1,000,000以下のノードは、lowのPopulation2006Levelに割り当てられます。また、列も範囲として定義され、最も低い範囲が、左から右へ記述するロケールでは一番左の列に表示され、右から左へ記述するロケールでは一番右の列に表示されます。

package model

import oracle.jbo.script.annotation.TransientValueExpression;

@TransientValueExpression(attributeName="Population2006Level")
def Population2006Level_ExpressionScript_Expression()
{
Population2006 <= 1000000 ? 'low' : (Population2006 <= 5000000 ? 'medium' : 'high')
}

@TransientValueExpression(attributeName="Income2005Class")
def Income2005Class_ExpressionScript_Expression()
{
Income2005 <= 40000.0 ? 'lower' : (Income2005 <= 45000.0 ? 'lo-mid' : (Income2005 <= 50000.0 ? 'hi-mid' : 'upper'))
}

ビュー・オブジェクトへの一時属性の詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたNBoxを作成するには、次の手順を実行します。

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、この項に示したデータ・コントロールを使用するには、CensusView1を選択します。

2. コレクションをJSFページにドラッグし、メニューから「NBox」を選択します。

3. NBoxグリッドを構成するための「NBoxの作成」ダイアログで、NBox内の行数と列数を表す数値を入力します。

たとえば、3つの行と4つの列を持つNBoxを作成する場合は、「行」に3、「列」に4を入力します。

4. オプションで、NBoxの行および列のタイトルに表示するテキスト・ラベルを入力します。リソース・バンドル内のテキスト・リソースをテキスト・ラベルと関連付ける場合は、「テキスト・リソースの選択」を選択して、その目的で使用可能なダイアログを開きます。オブジェクトに格納されているデータにアクセスする場合や、EL式を使用してメソッドを参照および呼び出す場合は、「式ビルダー」を選択して「式ビルダー」ダイアログを開きます。動的サンプルNBoxに行タイトルが表示されます。

5. NBox内のセルごとに、行と列の値を入力します。

たとえば、この項に示したデータ・コントロールを使用するには、Row1に行の値としてlowを入力し、Column 1の値としてlowerを入力します。

オプションで、各セル内にテキスト・ラベルを表示するには、「テキスト・リソースの選択」を選択して、ラベルにテキスト・リソースを関連付けます。オブジェクトに格納されているデータにアクセスする場合や、EL式を使用してメソッドを参照および呼び出す場合は、「式ビルダー」を選択して「式ビルダー」ダイアログを開きます。

「次の行」または「次の列」をクリックすると、NBox内の次の行または列に移動できます。あるいは、NBox動的サンプル内の目的のセルをクリックすると、そのセルの行フィールドと列フィールドを表示できます。値の入力が完了したら、「次へ」をクリックして次のダイアログに移動します。

図39-4は、この項に示したNBoxの設定済のダイアログを示しています。

図39-4 米国の人口と収入を示すNBoxのNBoxダイアログの作成

6. ノード構成用の「NBoxの作成」ダイアログの「行」フィールドと「列」フィールドで、行と列の値を含むデータ・コレクションから属性を選択します。オブジェクトに格納されているデータにアクセスする場合や、EL式を使用してメソッドを参照および呼び出す場合は、「式ビルダー」を選択して「式ビルダー」ダイアログを開きます。

たとえば、この項に示した一時属性を使用するには、Population2006LevelおよびIncome2005Classを選択します。

7. オプションで、ノード内にテキスト・ラベルを表示する場合は、「ラベル」および「第2ラベル」ドロップダウン・メニューから、テキスト・ラベルに使用する属性を選択します。ラベルにテキスト・リソースを使用するには、「テキスト・リソースの選択」を選択して、ラベルにテキスト・リソースを関連付けます。オブジェクトに格納されているデータにアクセスする場合や、EL式を使用してメソッドを参照および呼び出す場合は、「式ビルダー」を選択して「式ビルダー」ダイアログを開きます。

8. オプションで、NBoxノードのアイコンまたはインジケータを構成する場合は、「NBoxの作成」ダイアログで「アイコン」または「インジケータ」をクリックして、次の値を入力します。

- 図形: クリックしてドロップダウンを使用し、アイコンまたはインジケータに使用する図形を選択します。有効な値は、circle、human、diamond、square、triangleDown、triangleUpおよびplusです。

注意:

アイコンまたはインジケータの図形を明示的に指定すると、NBox内の各ノードに同じ図形が使用されます。なんらかのメジャーに従って図形を変える場合は、かわりに属性グループを構成します。

- イメージ: クリックしてドロップダウンを使用し、アイコンまたはインジケータに使用するイメージを選択します。

9. オプションで、NBoxのノード、アイコンまたはインジケータの属性グループを構成する場合は、「ノード」、「アイコン」または「インジケータ」タブの「グループ化ルール」で「新規作成」をクリックします。NBoxのノード、アイコンまたはインジケータの表示を色、図形またはパターンに基づいて変えるには、属性グループを使用します。属性グループは、凡例を表示する場合にも必要です。

属性グループを構成するには、次の値を入力します。

- 値でグループ化: ドロップダウン・リストから、属性グループをグループ化するためのデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。
この項のサンプル・アプリケーションは、Divisionによってノードを、Regionによってアイコンをグループ分けするための属性グループを定義しています。たとえば、CensusView1コレクションの「値でグループ化」として「Division」を選択すると、NBoxのノードに表示される色は色に応じて変わります。

- 「ノード」、「アイコン」または「インジケータ」: ドロップダウン・リストから、表示のためのグループ分けに使用するオプションを選択します。
NBoxノードの場合、ノードを色でグループ分けするには「色」を選択し、属性グループを色で区別し、色をインジケータとして表示するには「インジケータの色」を選択します。属性グループを色とインジケータ色の両方で区別するには、「複数の属性の選択」を選択し、「色」と「インジケータの色」の両方を選択します。「OK」をクリックします。

NBoxのアイコンおよびインジケータの場合、「色」、「図形」または「パターン」を選択して、アイコンまたはインジケータを色、図形またはパターンでグループ分けします。属性グループを複数の属性で区別するには、「複数の属性の選択」を選択し、ダイアログから「色」、「図形」または「パターン」を選択します。「OK」をクリックします。

- 凡例ラベル: ドロップダウン・リストから、NBoxの凡例に表示するデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。

- セクション・ラベル: ラベルにテキスト・リソースを使用するには、「テキスト・リソースの選択」を選択して、ラベルにテキスト・リソースを関連付けます。オブジェクトに格納されているデータにアクセスする場合や、EL式を使用してメソッドを参照および呼び出す場合は、「式ビルダー」を選択して「式ビルダー」ダイアログを開きます。

注意:

セクション・ラベルは、凡例のサブセクションの凡例内容を記したもので、凡例領域にレンダリングされます。たとえば、図39-2では、DivisionとRegionがセクション・ラベルです。

図39-5は、ノードを構成するための設定済の「NBoxの作成」ダイアログを示しています。

図39-5 ノード構成のための「NBoxの作成」ダイアログ

- オプションで、「値固有のルール」をクリックして属性グループ・ダイアログを拡張し、一致ルールまたは例外ルールを指定します。一致ルールは、単純なtrueまたはfalse条件に対して色またはパターンを指定するか、特定の値に一致させたい場合に使用します。グループ化値が特定の条件を満たしたときの色またはパターンを指定する場合は、例外ルールを使用します。
一致ルールを指定するには、「一致ルール」セクションで「新規」をクリックして、次の値を入力します。

- グループ値: 一致に対するカテゴリ値を入力します。カテゴリを表す文字列を入力するか、trueまたはfalseに設定できます。この値をtrueまたはfalseに設定する場合、「値でグループ化」フィールドには、次の例に示すように、trueまたはfalseに評価されるEL式(#{row.AmountInStock gt row.ReorderPoint}など)を指定する必要があります。

- プロパティ: ドロップダウン・リストから、ノードを色で区別する場合は「色」を、ノードのインジケータ領域の背景を色で区別する場合は「インジケータの色」を選択します。

- プロパティ値: ドロップダウン・リストから、ノードの値が「グループ値」に一致する場合に表示する色またはパターンを選択します。色については、提供されているいずれかの色を選択するか、「カスタム・カラー」を選択して「カスタム・カラーの選択」ダイアログでカスタム・カラーを指定できます。パターンについては、提供されているいずれかの値を選択する必要があります。

例外ルールを指定するには、「例外ルール」セクションで「新規」をクリックして、次の値を入力します。

- 条件: trueまたはfalseに評価されるJSF EL式を入力します。「条件」フィールドに式を直接入力するか、「式ビルダー」を選択してJSF EL式を入力できます。

- プロパティ: ドロップダウン・リストから、ノードを色で区別する場合は「色」を選択します。ノードのインジケータ領域をインジケータの色で区別する場合は、「インジケータの色」を選択します。

- プロパティ値: ドロップダウン・リストから、ノードの値が「条件」フィールドで指定した条件に一致する場合に表示する色またはパターンを選択します。色については、提供されているいずれかの色を選択するか、「カスタム・カラー」を選択して「カスタム・カラーの選択」ダイアログでカスタム・カラーを指定できます。パターンについては、提供されているいずれかの値を選択する必要があります。

- 凡例ラベル: 凡例ラベルにテキスト・リソースを使用するには、ドロップダウン・リストから「テキスト・リソースの選択」を選択します。このフィールドにテキストを入力するか、「式ビルダー」を選択してJSF EL式を入力することもできます。

10. ノード構成が完了したら、「終了」をクリックしてダイアログを終了し、NBoxをページに追加します。

「NBoxの作成」ダイアログに必要事項を入力した後で、「プロパティ」ウィンドウを使用してNBox属性の設定を指定することも、NBoxタグに関連付けられた子タグを使用してNBoxをさらにカスタマイズすることもできます。NBoxのエンド・ユーザー機能とプレゼンテーション機能、ユースケース、タグ構造および特殊機能の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のNBoxコンポーネントの使用方法に関する項を参照してください。

39.2.2 データバインドされたNBoxを作成すると行われる処理

NBoxを「データ・コントロール」パネルからドロップすると、次の処理が行われます。

- JSFページのページ定義ファイル(pageNamePageDef.xml)内にNBoxのバインディングが作成されます

- dvt:nBoxコンポーネントのJSFページに必要なタグが追加されます。

39.2.2.1 NBoxコンポーネントのバインディング

次のコード・サンプルは、JDeveloperで図39-3のデータ・コレクションを使用してdvt:nBoxコンポーネントに生成されたバインディングを示しています。

<executables>
<variableIterator id="variables"/>
<iterator Binds="CensusView1" RangeSize="-1" DataControl="AppModuleDataControl"
id="CensusView1Iterator"/>
</executables>
<bindings>
<tree IterBinding="CensusView1Iterator" id="CensusView1">
<nodeDefinition DefName="model.CensusView" Name="CensusView10">
<AttrNames>
<Item Value="Population2006Level"/>
<Item Value="Income2005Class"/>
<Item Value="State"/>
<Item Value="Division"/>
<Item Value="Region"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

NBoxのノードにデータを移入するためのルールは、ノード定義として定義されます。各ノード定義は、ビュー・オブジェクト1つと「NBoxの作成」ダイアログで指定された属性を参照しています。pageNamePageDef.xmlファイルの詳細は、「pageNamePageDef.xml」を参照してください。

39.2.2.2 NBoxバインディングの編集

作成中に「NBoxの作成」ダイアログで指定していない属性は、バインディングに含められません。データ・コレクションの別の属性を参照する必要がある場合は、バインディングに手動で追加する必要があります。たとえば、この項のサンプルでは、ユーザーがノードにカーソルを置いたときに州の収入と人口を示すツールチップを表示しています。

図39-6 NBoxのツールチップ

ツールチップが適切に評価されるためには、Population2006 and Income2005属性をNBoxのバインディング定義に追加する必要があります。バインディングを追加するには、「構造」ウィンドウでdvt:nBoxコンポーネントを右クリックし、「バインディングに移動」を選択します。「バインディング」セクションで「編集」を選択して、Population2006属性とIncome 2005属性を追加します。

図39-7は、表示属性にPopulation2006およびIncome2005が追加された設定済の「ツリー・バインディングの編集」を示しています。

図39-7 NBoxサンプルの「ツリー・バインディングの編集」ダイアログ

「OK」をクリックすると、バインディングが追加した属性で更新されます。次のコード・サンプルは、CensusView10ノード定義の改訂済バインディングを示しています。

<nodeDefinition DefName="model.CensusView" Name="CensusView10">
<AttrNames>
<Item Value="Population2006Level"/>
<Item Value="Income2005Class"/>
<Item Value="State"/>
<Item Value="Division"/>
<Item Value="Region"/>
<Item Value="Population2006"/>
<Item Value="Income2005"/>
</AttrNames>
</nodeDefinition>

39.2.2.3 NBoxコンポーネントのJSFページのコード

次の例は、NBoxのJSFページで生成されたコードを示しています。

<dvt:nBox id="nb1" var="ent" rowsTitle="#{viewcontrollerBundle.POPULATION}"
value="#{bindings.CensusView1.collectionModel}"
columnsTitle="#{viewcontrollerBundle.INCOME}">
<f:facet name="rows">
<af:group id="g1">
<dvt:nBoxRow label="#{viewcontrollerBundle.LOW}" id="nbr1" value="low"/>
<dvt:nBoxRow label="#{viewcontrollerBundle.MEDIUM}" id="nbr2" value="medium"/>
<dvt:nBoxRow label="#{viewcontrollerBundle.HIGH}" id="nbr3" value="high"/>
</af:group>
</f:facet>
<f:facet name="columns">
<af:group id="g2">
<dvt:nBoxColumn label="#{viewcontrollerBundle.LOWER}" id="nbc1" value="lower"/>
<dvt:nBoxColumn label="#{viewcontrollerBundle.LO_MID}" id="nbc2" value="lo-mid"/>
<dvt:nBoxColumn label="#{viewcontrollerBundle.HI_MID}" id="nbc3" value="hi-mid"/>
<dvt:nBoxColumn label="#{viewcontrollerBundle.UPPER}" id="nbc4" value="upper"/>
</af:group>
</f:facet>
<dvt:nBoxNode column="#{ent.Income2005Class}" row="#{ent.Population2006Level}"
label="#{ent.State}" id="nbn1">
<dvt:attributeGroups value="#{ent.Division}" type="color"
label="#{ent.Division}"
sectionLabel="#{viewcontrollerBundle.DIVISION}" id="ag1"/>
<f:facet name="icon">
<dvt:marker id="m1">
<dvt:attributeGroups value="#{ent.Region}" type="shape"
label="#{ent.Region}"
sectionLabel="#{viewcontrollerBundle.REGION}"
id="ag2"/>
</dvt:marker>
</f:facet>
</dvt:nBoxNode>
</dvt:nBox>

39.2.2.4 NBoxのプロパティとレイアウトの変更

NBoxを作成した後は、「NBoxの作成」ダイアログを使用して、コンポーネントのレイアウトを変更したり、ラベルなどの要素を追加したりできます。このダイアログを開くには、nBoxコンポーネントの「プロパティ」ウィンドウで、「編集」アイコンをクリックします。また、ビジュアル・エディタでNboxのコードを直接編集するか、「プロパティ」ウィンドウで値を設定して、レイアウトをカスタマイズすることもできます。

たとえば、図39-6に示したツールチップをNBoxに追加するには、「プロパティ」ウィンドウまたはコード・エディタで、NBoxノードのshortDesc属性の値を入力できます。

<dvt:nBoxNode column="#{ent.Income2005Class}" row="#{ent.Population2006Level}"
label="#{ent.State}" id="nbn1"
shortDesc="Population: #{ent.Population2006}&lt;br/>Income: #{ent.Income2005}">
... contents omitted
</dvt:nBoxNode>

NBoxのカスタマイズの詳細および例は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のNBoxコンポーネントの使用方法に関する項を参照してください。

40 データバインドされたピボット・テーブルおよびピボット・フィルタ・バー・コンポーネントの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータから、ピボット・テーブルを作成する方法について説明します。このピボット・テーブルの作成には、Fusion WebアプリケーションのADFデータ・コントロールとADF Facesコンポーネントを使用します。具体的には、ADFデータ視覚化コンポーネントのpivotTableおよびpivotFilterBarを使用して、ビジネス・データを視覚的に表現するピボット・テーブルの作成方法について説明します。ここでは、ADFデータ・コントロールを使用して、ピボット・テーブルをデータ優先開発で作成する方法について説明します。

簡単なUI優先開発を使用してページを設計する場合は、ピボット・テーブルをページに追加してから、データ・バインディングを構成してください。このコンポーネントのデータ要件、タグ構造および外観と動作のカスタマイズ・オプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ピボット・テーブル・コンポーネントの使用方法」を参照してください。

この章の内容は次のとおりです。

- ADFデータ視覚化ピボット・テーブル・コンポーネントおよびピボット・フィルタ・バー・コンポーネントについて

- データバインドされたピボット・テーブルの作成

40.1 ADFデータ視覚化ピボット・テーブル・コンポーネントおよびピボット・フィルタ・バー・コンポーネントについて

ADFデータ視覚化コンポーネントは、ビジネス・データを視覚的に表示、分析するための幅広いグラフィック機能と表機能を提供します。コンポーネントをレンダリングできるようにするには、これらのコンポーネントをそれぞれ、データにバインドする必要があります。コンポーネントの外観は表示されるデータによって変わるからです。

ピボット・テーブル・コンポーネントでは、複数レイヤーのデータ・ラベルをグリッドの行エッジまたは列エッジでサポートするグリッドが生成されます。オプションのピボット・フィルタ・バーは使用可能なピボット・テーブル・データをフィルタリングするページ・エッジを表します。このコンポーネントには、グリッド・データの小計および合計を自動的に生成するオプションもあります。ピボット・テーブルを使用すると、データ・レイヤーをあるエッジから別のエッジに切り替えてデータの表示を変更できます。たとえば、あるピボット・テーブルには、最初、行エッジに複数地域にわたる商品売上合計、列エッジに年別の明細が表示されていたとします。実行時に地域と年を切り替えると、複数年にわたる商品売上合計の地域別明細が表示されます。実行時に、エンド・ユーザーは内部列ラベルに表示されるボタンをクリックして、昇順または降順で行をソートできます。

接頭辞dvt:は、各データ視覚化コンポーネント名の先頭に付いて、そのコンポーネントがADFデータ視覚化ツール(DVT)のタグ・ライブラリに属することを示します。

40.1.1 データ視覚化コンポーネントのユースケースと例

データ視覚化ごとのユースケースと例の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のピボット・テーブルおよびピボット・フィルタ・バー・コンポーネントのユースケースと例に関する項を参照してください。

40.1.2 エンド・ユーザー機能およびプレゼンテーション機能

魅力的な外観を備えたデータ視覚化コンポーネントを使用すると、エンド・ユーザーは複雑なビジネス・データを理解して分析できるようになります。このコンポーネントは機能が豊富で、そのまますぐに使用できる対話型のサポートも用意されています。各コンポーネントのエンド・ユーザー機能およびプレゼンテーション機能の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のピボット・テーブル・コンポーネントのエンド・ユーザー機能とプレゼンテーション機能に関する項を参照してください。

40.1.3 データ視覚化コンポーネントの追加機能

データ視覚化コンポーネントをデータ・バインドする前に、その他のOracle ADF機能について理解しておいてください。また、いったんデータ視覚化コンポーネントをページに追加すると、検証やアクセシビリティなどの機能を追加する必要があることに気付く場合があります。データ視覚化コンポーネントで使用されるその他の機能へのリンクは、次のとおりです。

- 部分ページ・レンダリング: データ視覚化コンポーネントをリフレッシュして、ページの別のコンポーネントで実行されたアクションに基づく新しいデータを表示できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

- パーソナライズ: ユーザーは実行時にデータ視覚化コンポーネントの表示を変更できますが、ユーザーがカスタマイズできるようにアプリケーションを構成していないかぎり、ユーザーがページを終了するとそれらの値は保持されません。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「JSFページでのユーザー・カスタマイズの許可」を参照してください。

- アクセシビリティ: データ視覚化コンポーネントは、デフォルトでアクセス可能です。アプリケーションの各ページは、スクリーン・リーダーでのアクセスが可能になるように作成できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「アクセス可能なADF Facesページの開発」を参照してください。

- スキンおよびスタイル: アプリケーションに適用するADFスキンを使用するか、スタイル関連のプロパティ(styleClassまたはinlineStyle)を使用してCSSスタイル・プロパティを直接適用することで、データ視覚化コンポーネントの外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

- プレースホルダ・データ・コントロール: 最終的にページのデータ視覚化コンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールの使用を検討します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

40.2 データバインドされたピボット・テーブルの作成

ADFピボット・テーブルは、グリッド・レイアウトでデータを表示します。このレイアウトでは、階層型のネストされた行ヘッダー・セルと列ヘッダー・セルのレイヤー数に制限はありません。ピボット・テーブルでは、使用可能なピボット・テーブル・データをフィルタするページ・エッジを表すオプションのピボット・フィルタ・バーをサポートしています。ピボット・テーブルの構造は次のとおりです。

- 列エッジ: 1つ以上の情報レイヤーを持つピボット・テーブル上の横軸。

- 行エッジ: 1つ以上の情報レイヤーを持つピボット・テーブルの横側の縦軸。

- ページ・エッジ: ピボット・テーブルで、データの表示をフィルタするために、0個以上の情報レイヤーを持つオプションのピボット・フィルタ・バー。

- データ本体: ピボット・テーブルのセルに表示される1つ以上の指標(つまり、データ値)。

図40-1に、製品在庫のピボット・テーブルを示します。このピボット・テーブルは、データ本体に在庫数量と再発注点についてのデータ値を表示し、列エッジには倉庫ID、行エッジには製品カテゴリと製品データのレイヤーを表示しています。ピボット・フィルタ・バーは、世界の地域と地域フィルタをページ・エッジに表示します。

図40-1 製品在庫のピボット・テーブル

「ピボット・テーブルの作成」ウィザードでは、ピボット・テーブルのデータ・バインディングおよび構成のための宣言をサポートしています。ウィザードページでは、次の操作を行うことができます。

- ピボット・テーブルの初期レイアウトの指定

- ピボット・フィルタ・バーの関連付けと構成

- データ・レイヤーに対する代替ラベルの指定

- ドリルの挿入またはフィルタの設定

- データ値の集計の定義

- カテゴリおよびデータ・ソートの構成

ウィザードの先頭ページでピボット・テーブルのレイアウトを行うと、2ページめ以降で対応するエントリが初期化されます。ウィザードのページを進めるに従って、「戻る」ボタンおよび「次へ」ボタンを使用して、ピボット・テーブルを調整できます。ウィザード・ページの後半では、「終了」をクリックして、構成オプションをスキップすることもできます。

データ・バインディング完了後に、ピボット・テーブルをカスタマイズする方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ピボット・テーブル・コンポーネントの使用方法」を参照してください。

40.2.1 ADFデータ・コントロールを使用したピボット・テーブルの作成方法

データ・コントロールを使用してピボット・テーブルを作成するには、ピボット・テーブル・コンポーネントをコレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

ヒント:

また、「コンポーネント」ウィンドウからピボット・テーブル・コンポーネントをドラッグして、ピボット・テーブルを作成することもできます。この方法では、コンポーネントをデータにバインドする前に、ピボット・テーブルのユーザー・インタフェースを設計できます。

始める前に:

データバインドされたピボット・テーブルおよびピボット・フィルタ・バーについて理解しておいてください。詳細は、「データバインドされたピボット・テーブルの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従い、ピボット・テーブルのデータ・モデルで必要になる、ビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。
たとえば、図40-1に示す製品在庫のピボット・テーブルのデータソースは、ADF DVTコンポーネントについてのSummitサンプル・アプリケーション用に作成したビュー・オブジェクトから取得しています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたピボット・テーブルを作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。
たとえば、世界中の各倉庫の製品インベントリ・レベルを表示する、ピボット・テーブルとピボット・フィルタ・バーを作成する場合は、「データ・コントロール」パネルからWorldProductInventory1コレクションを選択します(図40-2を参照)。

図40-2 製品インベントリ・レベルのデータ・コレクション

2. JSFページにデータ・コレクションをドラッグして、ポップアップ・メニューから 「表/リスト・ビュー」→「ADFピボット・テーブル」を選択します。

3. 「ピボット・テーブルの作成」ウィザードの「表示属性の選択」ページで、次のようにして、ピボット・テーブルの初期レイアウトを指定します。

a. ピボット・フィルタ・バーとピボット・テーブルを関連付ける場合は、「ピボット・フィルタ・バーの作成」を選択します。必要に応じて、「使用可能な属性」リストからページ・エッジに属性をドラッグして、フィルタの初期ディスプレイを設定します。設定しなかった場合、空のピボット・フィルタ・バーが作成されます。

注意:

ウィザードの完了後にピボット・フィルタ・バーを追加するには、「構造」ウィンドウの「pivotTable」ノードを右クリックして、「ピボット・テーブルの前に挿入」→「ADFデータ視覚化」→「ピボット・フィルタ・バー」を選択します。

ピボット・フィルタ・バーを削除する場合は、「pivotFilterBar」ノードを右クリックして、「削除」を選択します。

b. 初期レイアウトでは、属性を「使用可能な属性」リストからピボット・テーブルのレイアウトにドラッグし、ピボット・テーブルの列、行、ページ・エッジおよびデータ本体の属性を選択します。
ピボット・テーブル・レイアウトでは、「データ・ラベル」は、セル内のデータ(データ値)を識別するピボット・テーブルのレイヤーを表し、行エッジ、列エッジまたはページ・エッジのヘッダー・ラベルとしても表示されます。ピボット・テーブルのデータ本体にドラッグした属性のラベルは、「データ・ラベル」レイヤーに表示されます。

データ・ラベルは、列エッジ、行エッジまたはページ・エッジ上の任意の場所にドラッグできます。また、属性を同じエッジ上の別の場所や、別のエッジ上にドラッグすることも可能です。

レイアウトで属性を配置または移動するためにドラッグ操作を使用するかわりに、属性を右クリックするか、[Shift]を押しながら[F10]を押して、ポップアップ・メニュー・オプションを表示することもできます。図40-3に、RegName属性のポップアップ・メニュー・オプションを示します。

図40-3 属性のポップアップ・メニューの表示

注意:

属性の間に存在しうるドリル・パスは、行エッジ、列エッジ、およびページ・エッジに複数の属性をレイアウトするときに定義されます。このようなドリル・パスは、実行時にピボット・テーブルのドリルをサポートするために後で有効化できます。

c. 「入力済属性」のデフォルトの選択から「名前-値ペア」に変更してデータ・ポイントをコレクションに格納する方法を構成する場合は、「データ形状の変更」ボタンをクリックします。次のオプションを提示するダイアログが表示されます。

- 入力済属性
コレクション内の各種データ・ポイントは、別々の属性によって表されます。このオプションは、ピボット・テーブル内のデータ・ポイントの種類が1つのみの場合も有効です。

たとえば、推定値と実際値に対するデータ・ポイントがある場合は、推定値の属性と実際値の属性が異なる場合にのみ、「入力済属性」を選択します。

- 名前-値ペア
次の2つの属性によって表されるデータ・ポイントが2種類以上あることを示します。データ・ポイントの種類を指定するName属性とデータ値を指定するValue属性です。

たとえば、Name属性に、推定値を表すValue属性の値としてESTがある場合や、実際値を表すValue属性の値としてACTがName属性にある場合があります。

たとえば、製品在庫のピボット・テーブル(図40-1を参照)の初期レイアウトを指定する場合、ページ・エッジにはRegName属性とCountry属性をドラッグし、行エッジにはCategory属性とProdName属性、データ本体(データのラベル)にはAmountinStock属性とReorderPoint属性、列エッジにはWarehouseIDをドラッグして、「ピボット・フィルタ・バーの作成」を選択します(図40-4を参照)。

図40-4 「ピボット・テーブルの作成」ウィザードの「表示属性の選択」ページ

4. ウィザードの「表示属性の選択」ページにレイアウトされた属性に対して代替の値またはラベルを指定する場合は、「次へ」をクリックしてから、「属性プロパティの指定」ページを使用して、次の手順を実行します。

a. デフォルトでは、ピボット・テーブル内のセルは編集できません。af:outputTextコンポーネントは、自動的に各データ・セルにスタンプされます。データ・セルの編集が可能なピボット・テーブルを作成する場合は、「読取り専用ピボット・テーブル」の選択を解除して、「コンポーネント」列の各データ・セル属性のaf:inputTextコンポーネント・オプションを使用できるようにします。その後で、af:inputTextコンポーネントを選択することで、0個以上のデータ値を編集可能として指定できるようになり、タグとそのタグに対応するf:validatorタグがピボット・テーブルのデータ・セルにスタンプされます。詳細は、「編集可能なデータ・セルの構成に関する必知事項」を参照してください。

b. 「データ値」エリアでデータ値の代替ラベルを指定するには、実行時にその属性のヘッダー・セルにスタンプされているデフォルトの「データ属性名の使用」テキスト・ラベルを変更します。テキストを直接入力する、ピボット・テーブルでデータ値を1つ使用する場合のように「ラベルなし」を選択してヘッダー・セルを抑制する、リソース・バンドルからテキスト・リソースを指定する、またはEL式ビルダーを使用して実行時にラベル・テキストを評価することが可能です。

c. 「カテゴリ」エリアで属性カテゴリの代替ラベルを指定するには、「属性の表示名」列で、実行時にその属性のヘッダー・セルにスタンプされているデフォルトの「属性の表示名」テキスト・ラベルを変更します。テキストを直接入力できますし、リソース・バンドルからテキスト・リソースを指定したり、EL式ビルダーを使用して実行時にラベル・テキストを評価できます。ラベルは、実行時、ピボット・ハンドルに表示されます。
また、「属性の表示名」列で別の属性を選択して、属性カテゴリに代替値を指定することもできます。たとえば、データ・コレクション内のRegionId属性を使用してピボット・テーブルをレイアウトできますが、実行時にはピボット・テーブル・ヘッダーにRegionName属性の値を表示して情報を読みやすくすることが必要になる場合があります。

テキスト・リソースを設定すると、ユーザーのブラウザの言語設定と一致する言語を、JSFページやアプリケーションに表示できるようになります。「データ値」のラベルと「カテゴリ」属性の表示名フィールドに「テキスト・リソースの選択」オプションを選択して、翻訳可能なテキスト・リソースを設定します。

注意:

「プロジェクト・プロパティ」→「リソース・バンドル」ページを「バンドルの自動同期化」に構成した場合は、かわりのラベル文字列を入力できます。これにより、設計時のコードから翻訳可能なテキスト・リソースが作成されます。

たとえば、図40-1の製品在庫のピボット・テーブルで、ラベルと表示名にテキスト・リソースを使用するように設定する場合は、図40-5に示すように、ウィザードの「属性プロパティの指定」ページに必要事項を入力します。

図40-5 「ピボット・テーブルの作成」ウィザードの「属性プロパティの指定」ページ

5. 実行時に、ピボット・テーブルでドリル操作を公開する必要がある場合は、「次へ」をクリックしてから、「ピボット・テーブルの作成」ウィザードの「ドリルの構成」ページを使用して、次のいずれかのオプションを有効にします。

- 「ドリルの挿入」を選択すると、兄弟および集計データを保持しながら、詳細なデータを折りたたまれたビューまたは展開されたビューに表示できます。実行時、ドリル・アイコンは親属性の表示ラベル内に表示されます。
展開されたビューで、親属性の総計を子属性の前または後のどちらに表示するかを指定するには、「親行の挿入」を使用します。

ドリルの挿入を有効にするには、次の手順の実行も必要です。

- 有効化するドリル・パスを選択します。ドリル・パスは、ウィザードの「表示属性の選択」ページにある属性レイアウトに基づいて設定されます。

- ウィザードの「集計の構成」ページで集計を設定します。

たとえば、図40-6のピボット・テーブルは、ドリルの挿入を使用して、Yearデータ・レイヤーのビューを展開しています。各年の売上の集計値(2007年52,500ドル、2006年544,150ドル)および売上個数(2007年410個、2006年507個)は、製品の上にある行に表示されます。

図40-6 ドリルの挿入が有効になっているピボット・テーブル

- 「ドリルのフィルタ」を選択すると、兄弟および集計データを保持せずに、詳細なデータを折りたたまれたビューまたは展開されたビューに表示できます。実行時、ドリル・アイコンは親属性の表示ラベル内で有効化されます。
ドリルのフィルタはデータ・レイヤー属性の詳細にビューの焦点を当てます。たとえば、図40-7のピボット・テーブルは、ドリルのフィルタ機能を使用して、Year (2007)データ・レイヤーのビューを展開し、総売上高(52,500)および売上げ個数(410)を表示する一方、それ以外の年のデータとすべての年の総計の両方をフィルタアウトして表示から除外しています。

図40-7 ドリルのフィルタが有効化されているピボット・テーブル

「ドリルのフィルタ」を有効化するには、有効化するドリル・パスを選択する必要があります。ドリル・パスは、ウィザードの「表示属性の選択」ページにある属性レイアウトに基づいて設定されます。

たとえば、図40-1の製品在庫ピボット・テーブルでドリルの挿入を使用できるようにするには、図40-8に示すように、ウィザードの「ドリルの構成」ページに必要事項を入力します。

図40-8 「ピボット・テーブルの作成」ウィザードの「ドリルの構成」ページ

6. ピボット・テーブルのデータの合計と小計を集計する方法を定義するには、「次へ」をクリックして、「ピボット・テーブルの作成」ウィザードの「集計の構成」の一方のページまたは両方のページを使用します。
デフォルトでは、ピボット・テーブルに表示されている属性によってデータ・コレクションの各行が一意に識別されない場合、重複行のデータを集計してピボット・テーブルの単一のセルに折りたたむことができます。また、特定のデータ項目では、デフォルトの集計タイプを無視することもできます。

- ピボット・テーブルでのデータの集計方法を指定するには、「データ集計」ページで次の手順を実行します。

- 重複行を処理するためのデフォルト集計方法を変更する場合は、「デフォルトの関数」ドロップダウン・リストを使用して、値を指定します。有効な値は、Sum、Average、Count、Maximum、Minimum、Standard Deviation、MedianおよびVarianceです。

- 特定のデータ値について、デフォルトの集計タイプを無視する場合は、「追加」アイコンをクリックして、使用可能な属性のために1行挿入します。次に、各属性の「関数」列で、集計に使用する数学演算を選択します。使用可能なオプションは、Sum、Average、Count、Maximum、Minimum、Standard Deviation、MedianおよびVarianceです。この属性は、ピボット・テーブルに複数のデータ値(SalesやUnitsなど)がバインドされている場合のみ有効です。

たとえば、売上のピボット・テーブル(図40-1を参照)にあるUnitsデータ値のデフォルト集計タイプをオーバーライドするには、図40-9に示すように、「追加」アイコンを使用してUnits属性を追加し、「データ集計」ページの「関数」列でAverageを選択します。

図40-9 「ピボット・テーブルの作成」ウィザードの「データ集計」ページ

- また、ピボット・テーブルの列エッジ、行エッジまたはページ・エッジに追加された属性カテゴリについて、合計と小計を定義することもできます。「カテゴリの合計」ページで、「追加」アイコンを使用して、各属性を挿入するか、「すべての集計」を選択して、使用可能な属性をすべて追加してから、次の手順を実行します。

- 「属性」列で、合計する属性を選択します。

- 「関数」列で、集計に使用する数学演算を選択します。使用可能なオプションは、Sum、Average、Count、Maximum、Minimum、Standard Deviation、MedianおよびVarianceです。

- 「属性」列で参照しているアイテムを基準として、集計結果を表示する位置を示す値を「合計の挿入」列で選択します。有効な値はBefore、AfterまたはReplaceです。

- 「合計ラベル」列に、集計のラベルとして使用するテキストを入力します。テキストを直接入力できますし、リソース・バンドルからテキスト・リソースを指定したり、EL式ビルダーを使用して実行時にラベル・テキストを評価できます。

注意:

読取り専用の「ドリル挿入の合計」表には、ピボット・テーブルでドリルの挿入を有効にした結果として、自動的に定義されたカテゴリ合計が表示されます。

たとえば、売上のピボット・テーブル(図40-1を参照)でGeographyデータ・レイヤーとYearデータ・レイヤーの合計を定義するには、「関数」列でSum、「合計の挿入」列でAfterを選択し、図40-10に示すように、「カテゴリの合計」ページの属性それぞれについて、「合計ラベル」列にテキスト(「Total Geography」と「Total Year」)を入力します。

実行時に結果として得られたピボット・テーブルで特定の年の値を展開すると、直前のウィザードページのドリルの挿入オプションで指定したレイアウトと設定に基づいて子値から計算された合計が自動的に保存されます。

図40-10 「ピボット・テーブルの作成」ウィザードの「カテゴリの合計」ページ

7. ピボット・テーブルのソート機能を構成するには、「次へ」をクリックしてから、「ピボット・テーブルの作成」ウィザードの「ソートの構成」の一方のページまたは両方のページ使用します。
デフォルトでは、ピボット・テーブルのデータは、最初は外部行データ・レイヤーの値に基づいてソートされます。任意の行エッジ、列エッジまたはページ・エッジのデータ・レイヤーにソート順序を指定することができます。このようなソートをカテゴリ・ソートと呼びます。実行時に、データ・レイヤーを異なるエッジにピボットした場合、指定されたカテゴリのソート順序が使用されます。

ウィザードの「表示属性の選択」ページでデータ本文にマップされた属性を並べることはできますが、データ・ラベル(データ値)のカテゴリ・ソートは指定できません。たとえば、図40-4はSalesおよびUnitsのデータ値を使ったピボット・テーブルのレイヤーを示しています。これらのメジャーのカテゴリ・ソートは指定できませんが、図40-1のように、実行時にピボット・テーブルのデータ本文に表示される値の順序は指定できます。

また、ピボット・テーブルをレンダリングするときに、データ本文でのデータ値の初期ソート順序を指定することもできます。これはデータ・ソートと呼ばれます。

- カテゴリごとにソートを設定するには、「カテゴリ・ソート」ページの「追加」アイコンを使用して、設定の対象となる各行エッジ、列エッジまたはページ・エッジの属性を追加し、その後、次の手順を実行します。

- 「ソート属性」列で、ピボット・テーブル・ヘッダーの実際値に基づいてアルファベット順でソートすることを指定するにはデフォルトのUse Attribute Valueをそのまま使用します。ソート順序をカスタマイズするには、ドロップダウン・リストからかわりのソート順序属性を指定します。たとえば、基礎となる問合せに、収益性別製品ランキングのランク計算が含まれている場合、ProductRank別に降順で製品が表示されるように指定できます。

- 「初期ソート順序」列で、初期ソート方向を選択します。有効な値はASCENDINGまたはDESCENDINGです。

たとえば、図40-11に示すウィザードの「カテゴリ・ソート」ページでは、Categoryデータ・レイヤーが列エッジに昇順に表示されるように構成しています。

図40-11 「ピボット・テーブルの作成」ウィザードの「カテゴリ・ソート」ページ

実行時に表示されるピボット・テーブルは図40-12のとおりです。

図40-12 カテゴリ・ソートの例

- データのソートを構成するには、「データ・ソート」ページで、次の手順を実行します。

- ピボット・テーブルがレンダリングされたときのデータの初期ソート順序を指定するには、「列でソート」を選択します。

- 「初期ソート順序」ドロップダウン・リストで、初期ソート方向を選択します。有効な値はASCENDINGおよびDESCENDINGです。

- 「シーケンスNull」ドロップダウン・リストで、NULL値をソートの先頭に表示する場合はFirst、NULL値をソートの最後に表示する場合はLastを指定します。

- 「初期ソート列」表で、「レイヤー属性」列に表示される各データ・レイヤーの「値」列にデータ値を指定します。

たとえば、図40-13は、Units/World/Canoesデータ値に基づいて、年ごとにグループ化されたChannelデータ・レイヤーをソートするように構成された「データ・ソート」ページを示しています。

図40-13 「ピボット・テーブルの作成」ウィザードの「データ・ソート」ページ

実行時、ピボット・テーブルは最初に図40-14のようにレンダリングされます。

図40-14 データ・ソートの例

8. 「終了」をクリックして、データバインドされたピボット・テーブルの作成を完了します。
ピボット・テーブルを作成するウィザードの完了後に、JDeveloperのツールを使用すると、ピボット・テーブルのルック・アンド・フィールをカスタマイズできます。たとえば、ヘッダー・セルのデフォルト・サイズに収まらないラベルのワード・ラップを構成したり、図40-1のピボット・テーブルのデータ・セット用にスクロール・バーのかわりのページ・コントロールを追加したりできます。

9. ピボット・テーブルをカスタマイズするには、次のタスクを実行します。

a. 「構造」ウィンドウで「dvt:pivotTable」ノードを右クリックし、「プロパティに移動」を選択します。

b. 「プロパティ」ウィンドウで、「共通」セクションを開き、ScrollPolicyプロパティをpageに設定することで、デフォルトのスクロール・バーのかわりとしてのページ・コントロールを構成します。

c. 「構造」ウィンドウで「dvt:headerCell」ノードを右クリックし、「プロパティに移動」を選択します。

d. 「プロパティ」ウィンドウで、「動作」セクションを開き、WhiteSpace属性をnormalに設定することで、ピボット・テーブルの各ヘッダーにワード・ラップを構成します。

データ・バインディング完了後に、ピボット・テーブルをカスタマイズする方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ピボット・テーブル・コンポーネントの使用方法」を参照してください。

40.2.2 「データ・コントロール」パネルによるピボット・テーブルの作成時の処理

ピボット・テーブルを「データ・コントロール」パネルからドロップすると、次の処理が行われます。

- ピボット・テーブルのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

「データ・コントロール」パネルからピボット・テーブルを作成すると、ページ定義ファイルがバインディングを使って更新されます。次の例は、地域内の商品売上と売上個数を年別に表示するピボット・テーブルに対して生成された行セット・バインディングを示しています。ピボット・テーブルのデータ・マップには次の要素が含まれます。

- <columns>: 各列項目を適切な順番で定義します

- <rows>: 各行項目を適切な順番で定義します

- <pages>: ピボット・フィルタ・バーに組入れられる項目を定義します

- <aggregatedItems>: 項目の合計と小計を定義します

- <hierarchies>: 2つの項目間で考えられるドリル・パスを定義します

- <sorts>: ピボット・テーブル・データのカテゴリ・ソートと初期ソート順序を定義します

重複する行のデフォルト・データ集計方法は、<data>要素で指定します。重複の集計の詳細は、「ピボット・テーブルの属性の集計に関する必知事項」を参照してください。

ソート操作の詳細は、「ピボット・テーブルへの初期ソートの指定に関する必知事項」を参照してください。

<pivotTable IterBinding="WorldProductInventory1Iterator"
id="WorldProductInventory1"
xmlns="http://xmlns.oracle.com/adfm/dvt" ChangeEventPolicy="ppr">
<pivotTableDataMap convert="false">
<columns>
<data aggregateDuplicates="true" defaultAggregateType="SUM">
<item label="${adfBundle['view.ViewControllerBundle'].AMOUNT_IN_STOCK}"
value="AmountInStock"/>
<item label="${adfBundle['view.ViewControllerBundle'].REORDER_POINT}"
value="ReorderPoint"/>
</data>
<item value="WarehouseId"
itemLabel="${adfBundle['view.ViewControllerBundle'].WAREHOUSE_ID}"/>
</columns>
<rows>
<item value="Category"
itemLabel="${adfBundle['view.ViewControllerBundle'].CATEGORY}"/>
</rows>
<pages>
<item value="RegName"
itemLabel="${adfBundle['view.ViewControllerBundle'].REGION}"/>
<item value="Country"
itemLabel="${adfBundle['view.ViewControllerBundle'].COUNTRY}"/>
</pages>
<aggregatedItems>
<item aggregateLocation="AFTER" aggregateType="AVERAGE" value="Category"
aggregateLabel="${adfBundle['view.ViewControllerBundle'].AVERAGE}"/>
</aggregatedItems>
<drills type="INSERT"/>
<hierarchies>
<item value="Category" location="BEFORE">
<child value="ProdName"
itemLabel="${adfBundle['view.ViewControllerBundle'].PRODUCT}"/>
</item>
</hierarchies>
<sorts>
<categorySort item="Category" direction="ASCENDING"/>
</sorts>
</pivotTableDataMap>
</pivotTable>

「データ・コントロール」パネルを使ってピボット・テーブルを作成すると、必要なコードがページに追加されます。次の例は、売上のピボット・テーブルと関連するピボット・フィルタ・バーに対してJSFページで生成されるコードを示しています。

<dvt:pivotFilterBar id="pfb1"
value="#{bindings.WorldProductInventory1.pivotFilterBarModel}"
modelName="pt1Model"/>
<dvt:pivotTable id="pt1"
value="#{bindings.WorldProductInventory1.pivotTableModel}"
modelName="pt1Model"
var="cellData" varStatus="cellStatus"
summary="#{viewcontrollerBundle.WorldProductInventoryPivotTable}"
scrollPolicy="page">
<dvt:headerCell whiteSpace="normal">
<af:switcher facetName="#{cellData.layerName}" defaultFacet="Default" id="s1">
<f:facet name="DataLayer">
<af:outputText value="#{cellData.label}" id="ot1"/>
</f:facet>
<f:facet name="WarehouseId">
<af:outputText value="#{cellData.dataValue}" id="ot2">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.WorldProductInventory1.
hints.WarehouseId.format}"/>
</af:outputText>
</f:facet>
<f:facet name="Category">
<af:outputText value="#{cellData.dataValue}" id="ot3"/>
</f:facet>
<f:facet name="ProdName">
<af:outputText value="#{cellData.dataValue}" id="ot4"/>
</f:facet>
<f:facet name="RegName">
<af:outputText value="#{cellData.dataValue}" id="ot5"/>
</f:facet>
<f:facet name="Country">
<af:outputText value="#{cellData.dataValue}" id="ot6"/>
</f:facet>
<f:facet name="Default">
<af:outputText value="#{cellData.dataValue}" id="ot7"/>
</f:facet>
</af:switcher>
</dvt:headerCell>
<dvt:dataCell>
<af:switcher facetName="#{cellStatus.members.DataLayer.value}"
defaultFacet="Default" id="s2">
<f:facet name="AmountInStock">
<af:outputText value="#{cellData.dataValue}" id="ot8">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.WorldProductInventory1.
hints.AmountInStock.format}"/>
</af:outputText>
</f:facet>
<f:facet name="ReorderPoint">
<af:outputText value="#{cellData.dataValue}" id="ot9">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.WorldProductInventory1.
hints.ReorderPoint.format}"/>
</af:outputText>
</f:facet>
<f:facet name="Default">
<af:outputText value="#{cellData.dataValue}" id="ot10"/>
</f:facet>
</af:switcher>
</dvt:dataCell>
</dvt:pivotTable

40.2.3 ピボット・テーブルの属性の集計に関する必知事項

ピボット・テーブルに表示するために選択した属性によってデータ・コレクションの各行が一意に識別されない場合、重複行のデータを集計してピボット・テーブルの単一のセルに折りたたむことができます。

たとえば、図40-15に示すデータ・コレクションの行に店舗IDも含まれていた場合、商品、販路および地理の特定の組合せにおける全店舗のデータ行をピボット・テーブルの単一のセルに折りたたむ必要があります。

図40-15 売上のピボット・テーブル

ピボット・テーブルには、重複するデータ行の計算の制御に使用できる次のオプションのデータ・バインディング属性があります。

- aggregateDuplicates: <data>要素のブール型プロパティ。重複行でデータ値を集計するために、バインディング実行時に特殊処理を有効化するかどうかを決定します。この属性が指定されていない場合、falseであると判断されます。

- defaultAggregateType: 重複を処理するためのデフォルト集計方法を指定する<data>要素の文字列プロパティ。有効な値は、SUM、AVERAGE、COUNT、MIN、MAX、STDDEV、MEDIANおよびVARIANCEです。aggregateDuplicatesがtrueで、defaultAggregateTypeが指定されていない場合、SUMであると判断されます。

- aggregateType: <item>要素の文字列プロパティ。特定のデータ項目のデフォルト集計タイプをオーバーライドすることができます。この属性は、ピボット・テーブルに複数のデータ値(SalesやUnitsなど)がバインドされている場合のみ有効です。

40.2.3.1 重複するデータ行のデフォルトの集計

デフォルトでは、ピボット・テーブルはSUM演算を使用してデータ・コレクション内で重複するデータ行のデータ値を集計し、ピボット・テーブルの単一のセル値を生成します。つまり、aggregateDuplicates属性はtrueに設定され、defaultAggregateTypeはSUMであると判断されます。

次の例に示す<data>要素は、このようなデフォルトの集計の例です。

<pivotTable IterBinding="ptExampleDataIterator" id="ptExampleData"
xmlns="http://xmlns.oracle.com/adfm/dvt"
ChangeEventPolicy="ppr">
<pivotTableDataMap>
<columns>
<item value="Geography" itemLabel="Location"/>
<data aggregateDuplicates="true" defaultAggregateType="SUM">
<item value="Sales"/>
<item value="Units" aggregateType="AVERAGE"/>
</data>
</columns>
<rows>
<item value="Year"/>
</rows>
<pages>
<item value="Channel"/>
</pages>
<aggregatedItems>
<item aggregateLocation="AFTER" aggregateType="SUM" value="Geography"
aggregateLabel="Total Geography"/>
<item aggregateLocation="AFTER" aggregateType="SUM" value="Year"
aggregateLabel="Total Across Years"/>
</aggregatedItems>
<drills type="INSERT"/>
<hierarchies>
<item value="Year" location="BEFORE">
<child value="Product" label="Product"/>
</item>
</hierarchies>
<sorts>
<categorySort item="Channel" direction="DESCENDING"/>
<categorySort item="Year" direction="ASCENDING"/>
<qdrSliceSort direction="DESCENDING" edge="rows" grouped="true"
nullsFirst="true">
<item name="Geography" value="World"/>
</qdrSliceSort>
</sorts>
</pivotTableDataMap>
</pivotTable>

40.2.3.2 重複行のカスタム集計

ピボット・テーブルで別の数学演算を使用して重複行のデータ値を集計する場合は、defaultAggregateTypeを目的の演算に設定します。

次の例は、defaultAggregateTypeがSUMに設定されているデータ要素を示しています。この演算は、商品、販路および州の一意の組合せごとに全店舗の売上合計を表示する場合に適しています。

<pivotTable IterBinding="SalesPivotTable1Iterator" id="SalesPivotTable11"
xmlns="http://xmlns.oracle.com/adfm/dvt">
<pivotTableDataMap>
<columns>
<data aggregateDuplicates="true" defaultAggregateType="SUM">
<item value="Sales"/>
</data>
<item value="Geography"/>
</columns>
<rows>
<item value="Channel"/>
<item value="Product"/>
</rows>
<aggregatedItems>
<item aggregateLocation="After" aggregateType="AVERAGE"
value="Product" aggregateLabel="Average"/>
</aggregatedItems>
</pivotTableDataMap>
</pivotTable>

売上や店舗の平均規模(平方フィート単位)など複数のデータ値がピボット・テーブルにあり、重複行の売上データ値を合計する一方、平方フィートのデータ値を平均化する場合は、次のようにします。

- <data>要素で、defaultAggregateTypeをSUMに設定します。

- 平方フィート属性の<item>要素で、aggregateTypeをAVERAGEに設定します。

次の例は、PivotTableDataMap要素でラップされた<columns>要素を示しています。<data>要素には、集計のデフォルトの属性が指定されています。これらは、特殊なカスタムaggregateType属性が指定されていないデータ・アイテムすべてに適用されます。

<columns>
<data aggregateDuplicates="true" defaultAggregateType="SUM">
<item value="Sales" label="Total Sales"/>
<item value="StoreSqFeet" label="Avg Sq Feet" aggregateType="AVERAGE"/>
</data>
<item value="State"/>
</columns>

40.2.4 ピボット・テーブルへの初期ソートの指定に関する必知事項

デフォルトでは、ピボット・テーブルのデータは、最初は外部行データ・レイヤーの値に基づいてソートされます。任意の行アイテム、列アイテムまたはページ・アイテムのデータ・レイヤーにソート順序を指定することができます。このようなソートをカテゴリ・ソートと呼びます。実行時に、データ・レイヤーを異なるエッジにピボットした場合、指定されたカテゴリのソート順序が使用されます。sorts要素内にcategorySort要素を挿入し、表40-1に示すように属性の値を設定します。

表40-1 categorySort要素の属性値

属性

説明

item

カテゴリ・ソートを設定する列アイテム、行アイテムまたはページ・アイテムを指定します。この属性の値は必須です。

direction

初期のソート方向を指定します。有効な値はASCENDINGおよびDESCENDINGです。この属性の値は必須です。

また、ピボット・テーブルをレンダリングするときに、データ本文でのデータ値の初期ソート順序を指定することもできます。これはデータ・ソートと呼ばれます。デフォルトの動作は、ページ定義ファイルでピボット・テーブル・バインディングのpivotTableDataMap要素内にsorts要素を挿入すると変更できます。sorts要素内にqdrSliceSort要素を挿入し、表40-2に示すように属性の値を設定します。

表40-2 qdrSliceSort要素の属性値

属性

説明

direction

初期のソート方向を指定します。有効な値はASCENDINGおよびDESCENDINGです。この属性の値は必須です。

edge

columnsまたはrowsを指定し、データをソートするエッジを決定します。この属性の値は必須です。

grouped

親のスライスをソートする場合はtrue、エッジ全体にわたってソートする場合はfalseを指定します。この属性の値は任意です。デフォルト値はfalseです。

nullsFirst

NULL値をソートの先頭に表示する場合はtrue、NULL値をソートの最後に表示する場合はfalseを指定します。デフォルト値はfalseです。この属性の値は任意です。

1つ以上のitemタグをqdrSliceSortタグに挿入します。itemタグは、ソート対象の値が取得されるのとは逆のエッジ上にスライスを指定します。たとえば、ソート行がデータに基づいている場合は、各レイヤーのitemタグを列エッジで指定する必要があります。表40-3に示すように属性の値を設定します。

表40-3 itemタグの属性値

属性

説明

name

ソート対象のレイヤーの名前を指定します。通常、これは行セットの列名です。行セットのデータ列(Sales、Costsなど)を含むレイヤーを識別する場合はDataLayerを指定します。

value

指定したレイヤーの値を目的のスライスに指定します。

40.2.5 編集可能なデータ・セルの構成に関する必知事項

デフォルトでは、ピボット・テーブル内のセルは編集できません。ADFデータ・コントロールを使用してピボット・テーブルを作成すると、各データ・セルにaf:outputTextコンポーネントが自動的にスタンプされます。また、ピボット・テーブルの作成ウィザードを使用して、データ・セルを編集可能として構成することもできます。このように構成するには、af:inputTextコンポーネントとタグ、およびそれに対応するf:validatorタグが、データ・セルにスタンプされるように指定します(次の例を参照)。

<dvt:dataCell>
<af:switcher facetName="#{cellStatus.members.DataLayer.value}"
defaultFacet="Default" id="s2">
<f:facet name="AmountInStock">
<af:inputText value="#{cellData.dataValue}"
label="#{bindings.WorldProductInventory1.hints.
AmountInStock.label}"
required="#{bindings.WorldProductInventory1.hints.
AmountInStock.mandatory}"
columns="#{bindings.WorldProductInventory1.hints.
AmountInStock.displayWidth}"
maximumLength="#{bindings.WorldProductInventory1.hints.
AmountInStock.precision}"
shortDesc="#{bindings.WorldProductInventory1.hints.
AmountInStock.tooltip}"
id="it1">
<f:validator binding="#{cellData.bindings.AmountInStock.validator}"/>
</af:inputText>
</f:facet>
<f:facet name="ReorderPoint">
<af:outputText value="#{cellData.dataValue}" id="ot8">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.WorldProductInventory1.hints.
ReorderPoint.format}"/>
</af:outputText>
</f:facet>
<f:facet name="Default">
<af:outputText value="#{cellData.dataValue}" id="ot10"/>
</f:facet>
</af:switcher>
</dvt:dataCell>

<dvt:dataCell>
<af:switcher facetName="#{cellStatus.members.DataLayer.value}"
defaultFacet="Default" id="s2">
<f:facet name="Sal">
<af:inputText value="#{cellData.dataValue}" id="ot5"
label="#{bindings.EmpView1.hints.Sal.label}"
required="#{bindings.EmpView1.hints.Sal.mandatory}"
columns="#{bindings.EmpView1.hints.Sal.displayWidth}"
maximumLength="#{bindings.EmpView1.hints.Sal.precision}"
shortDesc="#{bindings.EmpView1.hints.Sal.tooltip}">
<f:validator binding="#{cellData.bindings.Sal.validator}"/>
</af:inputText>
</f:facet>
<f:facet name="Default">
<af:inputText value="#{cellData.dataValue}" id="ot6"/>
</f:facet>
</af:switcher>
</dvt:dataCell>

また、dataCellコンポーネントの子としてEditableValueHolderインタフェースまたはActionSourceインタフェースを実装するコンポーネント(af:selectBooleanCheckboxやaf:inputComboboxListofValuesなど、ほとんどのコンポーネント)を使用するようにピボット・テーブルのデータ・セルを構成することもできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のヘッダーおよびデータ・セルのスタンプの構成方法に関する項を参照してください。

41 データバインドされた地理マップ・コンポーネントおよびテーマ・マップ・コンポーネントの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータから地理マップまたはテーマ・マップを作成する方法について説明します。これらのマップの作成には、Fusion WebアプリケーションのADFデータ・コントロールとADF Facesコンポーネントを使用します。具体的には、ADFデータ視覚化コンポーネントのmapおよびthematicMapを使用して、ビジネス・データを視覚的に表現する地理マップまたはテーマ・マップを作成する方法について説明します。ここでは、ADFデータ・コントロールを使用して、これらのコンポーネントをデータ優先開発で作成する方法について説明します。

簡単なUI優先開発を使用してページを設計する場合は、地理マップまたはテーマ・マップをページに追加してから、データ・バインディングを構成してください。マップ・コンポーネントのデータ要件、タグ構造および外観と動作のカスタマイズ・オプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「マップ・コンポーネントの使用方法」を参照してください。

この章の内容は次のとおりです。

- ADFデータ視覚化マップ・コンポーネントについて

- データバインドされた地理マップの作成

- データバインドされたテーマ・マップの作成

41.1 ADFデータ視覚化マップ・コンポーネントについて

ADFデータ視覚化コンポーネントは、ビジネス・データを視覚的に表示、分析するための幅広いグラフィック機能と表機能を提供します。コンポーネントをレンダリングできるようにするには、これらのコンポーネントをそれぞれ、データにバインドする必要があります。コンポーネントの外観は表示されるデータによって変わるからです。

地理マップ・コンポーネントはビジネス・データを空間的に表現し、1つのマップ上に複数層(テーマとも呼ばれる)の情報を重ね合せられるようにします。たとえば、アメリカ合衆国のマップでは、色の明度を変えて各州における商品の人気を示すカラー・テーマ、商品カテゴリ内での売上を示す円グラフ・テーマ、各倉庫の正確な場所を識別する点テーマなどを使用できます。この3つの全テーマをアメリカ合衆国の地図に重ね合せると、特定の地域で商品の人気度に応じた十分な在庫があるかどうかを簡単に評価できます。地理マップでは、Oracle MapViewerサービスへの接続が必要です。また、オプションで地理的および政治的な詳細情報を表示するためのジオコーダ・サービスにも接続できます。

テーマ・マップ・コンポーネントでは、ビジネス・データをスタイル設定されたエリア内にパターンまたは関連付けられたマーカーとして表し、Oracle MapViewerサービスへの接続は必要ありません。テーマ・マップでは、地理マップでの地理的な詳細なしで、データに焦点を合せます。テーマ・マップは、米国、世界をはじめ、世界の大陸や地域(EMEAやAPACなど)などのあらかじめ作成されたベース・マップとともにパッケージ化されています。それぞれのベース・マップには、いくつかのリージョンのセットと、都市の固定セットが1つ含まれます。リージョンまたは都市の1つのセットはレイヤーと呼ばれます。各レイヤーは、データ・コレクションにバインドし、データを色やパターンの塗りつぶし、またはデータ・マーカー、あるいはその両方で表すためにスタイルを設定できます。実行時には、テーマ・マップでドリルが有効になっていないかぎり、一度に表示できるのは1つのマップ・レイヤーとその関連するデータのみです。

接頭辞dvt:は、各データ視覚化コンポーネント名の先頭に付いて、そのコンポーネントがADFデータ視覚化ツール(DVT)のタグ・ライブラリに属することを示します。

41.1.1 ユースケースと例

各データ視覚化のユースケースと例の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のマップ・コンポーネントのユースケースおよび例に関する項を参照してください。

41.1.2 エンド・ユーザー機能およびプレゼンテーション機能

魅力的な外観を備えたデータ視覚化コンポーネントを使用すると、エンド・ユーザーは複雑なビジネス・データを理解して分析できるようになります。このコンポーネントは機能が豊富で、そのまますぐに使用できる対話型のサポートも用意されています。各コンポーネントのエンド・ユーザー機能とプレゼンテーション機能の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のマップのエンド・ユーザー機能およびプレゼンテーション機能に関する項を参照してください。

41.1.3 データ視覚化コンポーネントの追加機能

データ視覚化コンポーネントをデータ・バインドする前に、その他のOracle ADF機能について理解しておいてください。また、いったんデータ視覚化コンポーネントをページに追加すると、検証やアクセシビリティなどの機能を追加する必要があることに気付く場合があります。データ視覚化コンポーネントで使用されるその他の機能へのリンクは、次のとおりです。

- 部分ページ・レンダリング: データ視覚化コンポーネントをリフレッシュして、ページの別のコンポーネントで実行されたアクションに基づく新しいデータを表示できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

- パーソナライズ: ユーザーは実行時にデータ視覚化コンポーネントの表示を変更できますが、ユーザーがカスタマイズできるようにアプリケーションを構成していないかぎり、ユーザーがページを終了するとそれらの値は保持されません。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「JSFページでのユーザー・カスタマイズの許可」を参照してください。

- アクセシビリティ: データ視覚化コンポーネントは、デフォルトでアクセス可能です。アプリケーションの各ページは、スクリーン・リーダーでのアクセスが可能になるように構成できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「アクセス可能なADF Facesページの開発」を参照してください。

- スキンおよびスタイル: アプリケーションに適用するADFスキンを使用するか、スタイル関連のプロパティ(styleClassまたはinlineStyle)を使用してCSSスタイル・プロパティを直接適用することで、データ視覚化コンポーネントの外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

- プレースホルダ・データ・コントロール: 最終的にページのデータ視覚化コンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールの使用を検討します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

41.2 データバインドされた地理マップの作成

地理マップは、Oracle Spatialの機能をOracle ADF内で提供するADFデータ視覚化コンポーネントです。このコンポーネントでは、ユーザーはビジネス・データを地理マップ上に表し、1つのマップ上に複数層の情報(テーマと呼ばれる)を重ね合せることができます。これらのレイヤーは、棒グラフ、円グラフ、カラー、点および事前定義済テーマといった任意のテーマとして表すことができます。

図41-1は、アメリカ合衆国内のある地域のベース・マップとともに次のテーマを使用した地理マップ・コンポーネントを示しています。

- カラー・テーマ: このテーマでは、選択した商品について、商品の人気に基づいて州を色付けします。色の範囲は緑(その商品の人気が最高であることを表す)から赤(その商品の人気が最低であることを表す)までです。

- 円グラフ・テーマ: このテーマでは、各州で人気のある商品カテゴリを示す円グラフをその州に表示します。この例の円グラフでは、Media、OfficeおよびElectronicsという3つの商品カテゴリを円グラフの区分として示しています。

- 点テーマ: このテーマでは、倉庫を点として識別します。各点に対し、選択した商品のその倉庫での在庫レベルを示すアイコンが表示されます。表示されるアイコンは、在庫レベルが低、中、高といった各在庫範囲で異なります。

図41-1 色テーマ、円グラフ・テーマおよび点テーマを使用した地理マップ

地理マップ・コンポーネントは、複数のデータ・セットを表示するために、複数のマップを1ページ上に配置する必要がないという点が、他のADFデータ視覚化コンポーネントとは異なります。このコンポーネントは、複数のグラフを1ページ上に配置できるグラフなどのコンポーネントとは対照的です。かわりに、複数のデータセットの空間的な相互関係を示すか、特定の点に対して別々のテーマでレイヤー化された異なる属性を表示します。

地理マップ・コンポーネント自体はデータにバインドされません。しかし、各マップのテーマは独自のデータバインディングを持っています。

ベース・マップは、開発者が作成したテーマをADF地図コンポーネントでレイヤー化する背景となります。

Oracle Spatialでは、管理者は1つ以上のテーマで構成されるベース・マップを作成します。管理者は、ベース・マップのテーマの可視性を制御します。ベース・マップを拡大および縮小すると、ベース・マップの様々なテーマが表示/非表示になります。ADF地図コンポーネントのレベルでは、管理者がベース・マップに作成したテーマの表示を、開発者がズーム係数を使用して制御することはできません。

複数のテーマをADF地図にオーバーレイする際は、そのテーマに関連するコンポーネントのmaxZoomおよびminZoomプロパティを設定することでテーマの可視性を制御できます。実行時には、「マップ」ツールバーの表示メニューまたはページに作成した他のADFコンポーネントを使用してカスタム・テーマを表示/非表示にすることもできます。

データ・バインディング完了後に、地理マップをカスタマイズする方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「マップ・コンポーネントの使用方法」を参照してください。

41.2.1 地理ベース・マップの構成方法

地理マップを作成する場合は、最初にマップを構成してから、データ・コレクションに点、円グラフや棒グラフまたはマップの色テーマをバインドします。JDeveloperでは、作成するテーマに対して「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を行うことができます。

始める前に:

データバインドされた地理マップについて理解しておいてください。詳細は、「データバインドされた地理マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従い、ピボット・テーブルのデータ・モデルで必要になる、ビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。
たとえば、図41-1に示す製品在庫のピボット・テーブルのデータソースは、ADF DVTコンポーネントについてのSummitサンプル・アプリケーション用に作成したビュー・オブジェクトから取得しています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

地理ベース・マップを構成するには:

1. 「データ・コントロール」パネルから、コレクションを選択します。
たとえば、世界中の各倉庫の製品インベントリ・レベルを表示する地理マップを作成する場合は、「データ・コントロール」パネルからWorldProductInventory1コレクションを選択します(図41-2を参照)。

図41-2 製品インベントリ・レベルのデータ・コレクション

2. JSFページにデータ・コレクションをドラッグし、ポップアップ・メニューから「地理マップ」→「マップおよび点のテーマ」、「マップおよび円グラフのテーマ」、「マップおよび色のテーマ」または「マップおよび棒グラフのテーマ」を選択します。

3. ページ上のマップを構成していない場合は、次に表示される「地理マップの作成」ダイアログで「新規」アイコンをクリックし、「地理マップ構成の作成」ダイアログを表示して、次の手順を実行します。

a. 「ID」フィールドに、マップ構成の一意のIDを入力します。たとえば、mapConfig1です。

b. 「MapViewer URL」フィールドに、Oracle MapViewerサービスのURLを入力します。
ドロップダウン・リストを使用して既存の接続を選択するか、「追加」アイコンをクリックして新しい接続を構成します。「URL接続の作成」ダイアログで、URLエンドポイントのアドレスにhttp://elocation.oracle.com/mapviewerを使用し、「接続のテスト」をクリックして接続を確認します。図41-3に、必要事項を入力した「URL接続の作成」ダイアログを示します。

図41-3 マップ・ビューアのURL接続の作成

c. 「ジオコーダURL」フィールドで、マップ作成用に住所を緯度と経度の座標に変換するGeocoder WebサービスのURLを入力します。

注意:

ジオコーダのURLは、住所の経度および緯度情報をまだ持っていない場合のみ必要です。

ドロップダウン・リストを使用して既存の接続を選択するか、「追加」アイコンをクリックして新しい接続を構成します。「URL接続の作成」ダイアログで、URLエンドポイントのアドレスにhttp://elocation.oracle.com/geocoder/gcserverを使用し、「接続のテスト」をクリックして接続を確認します。図41-4に、必要事項を入力した「URL接続の作成」ダイアログを示します。

図41-4 ジオコーダURL接続の作成

d. 「OK」をクリックします。図41-5に、必要事項を入力した「地理マップ構成の作成」ダイアログを示します。

図41-5 「地理マップ構成の作成」ダイアログ

4. 「OK」をクリックします。

5. 「地理マップの作成」ダイアログで地理マップ・コンポーネントのベース・マップを選択し、次の手順を実行して、地理マップに使用するその他の設定を指定します。

a. データ・ソース・リストで、ベース・マップの選択元となるマップのコレクションを選択します。

b. 「基準となるマップ」リストから、地理マップ・コンポーネントの背景となるマップを選択します。

c. 「開始X」フィールドと「開始Y」フィールドの値を指定するには、マップのイメージをクリックしてマップを「プレビュー」ウィンドウ内の中央に配置します。
左上角のマップ・ナビゲータの矢印を使用すると、マップを適切な方向に移動できます。

d. オプションで、「プレビュー」ウィンドウのスライド矢印を使用して、地図のズーム係数を調整します。

e. 「OK」をクリックします。図41-5に、必要事項を入力した「地理マップの作成」ダイアログを示します。

図41-6 「地理マップの作成」ダイアログ

6. 「テーマの作成」ダイアログを使用して、次に示すようにマップ・テーマをデータ・バインドします。

- 点テーマを作成して、ベース・マップ上のデータを表現します。詳細は、「点テーマを使用して地図を作成する方法」を参照してください。

- 色テーマを作成して、ベース・マップ上のデータを表現します。詳細は、「色テーマを使用して地理マップを作成する方法」を参照してください。

- 円グラフ・テーマまたは棒グラフ・テーマを作成して、ベース・マップ上のデータを表します。詳細は、「円グラフまたは棒グラフのテーマを使用した地理マップの作成方法」を参照してください。

41.2.2 点テーマを使用して地図を作成する方法

点テーマを使用して地理マップを作成すると、緯度と経度または住所で識別されるマップ内の特定の場所を表示できるようになります。たとえば、点テーマで倉庫の場所をマップに示します。表示される点のスタイルをカスタマイズすると、倉庫のセットに含まれる倉庫内の製品数(高、適正、低)に応じた個別のイメージを使用して、それぞれの製品数を区別できるようになります。

点テーマを使用した地理マップを作成する場合は、最初にベース・マップを構成してから、そのマップの点テーマをデータ・コレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。また、点テーマをレイヤー化して、それとは別のテーマ用に構成およびバインドされているベース・マップに重ねることもできます。

たとえば、図41-7に示す地理マップには、米国内の倉庫の場所と、それらの倉庫の製品数レベルを表す点テーマが設定されています。

図41-7 点テーマを使用した地理マップ

始める前に:

データバインドされた地理マップについて理解しておいてください。詳細は、「データバインドされた地理マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従い、点テーマを使用した地理マップのデータ・モデルで必要になる、ビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。
たとえば、図41-7に示す地理マップの点テーマのデータソースは、Summit ADF DVTサンプル・アプリケーション用に作成したビュー・オブジェクトから取得しています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされた点テーマを使用して地図を作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。

図41-8は、「データ・コントロール」パネルで選択可能なSWarehouseView1コレクションを示しています。このコレクションにより、製品数のレベルを表すようにスタイル設定された各倉庫の場所が特定できるイメージを表示する点テーマを使用した地理マップを作成できます。

図41-8 倉庫の場所と製品数のデータ・コレクション

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「地理マップ」→「マップおよび点のテーマ」を選択します。

3. ページ上のマップをまだ構成していない場合は、「地理マップの作成」ダイアログの入力を完了してください。詳細は、「地理ベース・マップの構成方法」を参照してください。それ以外の場合は、以下のいずれかを実行します。

- ドロップダウン・リストから、使用するマップ構成を選択します

- 「OK」クリックして、使用可能なマップ構成をそのまま使用します

- 「新規」をクリックして、新しいベース・マップを構成します

- 「編集」をクリックして、使用可能なマップ構成に変更を加えます

4. ベース・マップに点テーマをレイヤー表示するときに、それとは別のテーマ用にベース・マップが構成およびバインドされている場合は、「作成」ダイアログで「点テーマ」を選択します。

5. 「点マップ・テーマの作成」ダイアログの「テーマID」フィールドに、点マップ・テーマの一意のIDを入力します。

6. 「位置」セクションで、点の位置を「住所」で指定するか、x座標とy座標(経度と緯度)のペアで指定するかを選択します。

選択する位置によって、「位置」セクションに表示されるコントロールが決まります。

ヒント:

地図上にデータを表現するには、「住所」コントロールを使用するよりも、xおよびy座標を使用するほうが効率的です。これは、「住所」コントロールはジオコーダでxおよびy座標に変換する必要があるからです。データ・コレクションの行が100行を超える場合は、パフォーマンスを向上するために、xおよびy座標を使用してください。

7. xとyの点の位置に対し、次のアイテムを表すデータ・コレクションから属性を選択します。

- X(経度):マップ上の点の水平位置。

- Y(緯度):マップ上の点の垂直位置。

- ラベル:「情報」ウィンドウの上部に表示される点のラベル。点をクリックすると表示されます。

8. 「点データ」セクションで、点、そのラベルおよび点のスタイル(オプション)に関連するデータを指定する次の情報を入力します。

- 「データ」フィールドで、点に関連付けられているデータ行(ProductCountなど)を選択します。

- 「ラベル」フィールドに、点をクリックすると、「情報」ウィンドウでデータ値の前に表示されるテキストを入力します。ラベルに使用するテキスト・リソースを入力できます。テキスト・リソースは、リソース・バンドルからの翻訳可能な文字列または実行時に実行されるEL式のいずれかにできます。ドロップダウン・リストを使用して、「テキスト・リソースの選択」または「式ビルダー」ダイアログを選択します。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

- オプションで、「カテゴリ」フィールドで、点の適切なスタイルの検索に使用するデータ列を選択します。「カテゴリ」で値を選択すると、その値はこの点テーマのバインディングに格納された後、この点テーマ用に作成するmapPointStyleItemタグのitemValue属性と照合されます。

注意:

点のスタイルの検索にカテゴリとして使用する列がデータにない場合、mapPointStyleItemタグを使用して、「データ」フィールドで選択した列の値と一致するデータの範囲(高、適正、低など)に関連するスタイルを定義することもできます。詳細は、「点テーマの点スタイル・アイテムの作成方法」を参照してください。

9. マスター/ディテール関係を有効にする場合は、「行選択の有効化」を選択します。これは、地理マップのデータ・コレクションが、ページ上の別のUIコンポーネントに表示されるディテール・ビューとのマスター/ディテール関係においてマスターである場合に便利です。このオプションを選択すると、selectionListenter属性とclickListener属性の両方が有効になります。

10. 「OK」をクリックします。

図41-9に、点テーマを使用した地理マップ用に入力が完了した「点マップ・テーマの作成」ダイアログを示します。この地理マップは、各倉庫の場所と製品数のレベルをイメージで表現します。

図41-9 倉庫内の製品数についての「点マップ・テーマの作成」ダイアログ

マップの点テーマの作成後に、マップに表示される点のスタイルをさらにカスタマイズすると、より詳細な情報を表現できるようになります。たとえば、図41-7のマップの点テーマでは、各倉庫の製品数についてのレベル(高、適正、低)を表現するために個別のイメージを使用しています。それぞれの点スタイルに、mapPointStyleItemタグを使用します。詳細は、「点テーマの点スタイル・アイテムの作成方法」を参照してください。

41.2.3 点テーマの点スタイル・アイテムの作成方法

特定のマップ点テーマで使用する点スタイル・アイテムを作成するために使用できる様々なオプションがあります。それらは次のとおりです。

- すべてのデータ・ポイントに対する単一イメージ

- データ・ポイント・カテゴリごとに異なるイメージ

- データ値の低、中および高範囲を表すイメージ

マップ点テーマのデータ・バインディングを作成すると、そのマップ・テーマのすべての点に対して使用される単一の組込みイメージを選択できるようになります。この選択には、「プロパティ」ウィンドウで、mapPointThemeタグのbuiltInImage属性を使用します。この属性のデフォルト値は、オレンジ色の球です。

あるいは、「点マップ・テーマの作成」ダイアログの「カテゴリ」に値を指定した場合は、一連の点スタイル・アイテムを作成して各カテゴリのデータ・ポイントを表す別のイメージを決定する必要もあります。その場合、点スタイル・アイテムのタグで最小/最大値を使用しないでください。かわりに、点スタイル・アイテムのタグのitemValue属性に、「カテゴリ」に指定したデータ列のエントリと一致する値を設定します。

地理マップの点テーマでは、「カテゴリ」に値を指定しない場合でも、mapPointThemeタグのmapPointStyleItem子タグを使用して値の範囲(低、中、高など)とその範囲を表すイメージを指定できます。この指定をすると、各点は、その点のデータ値が含まれる範囲を識別するイメージによって表されます。

始める前に:

データバインドされた地理マップについて理解しておいてください。詳細は、「データバインドされた地理マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従い、点テーマを使用した地理マップのデータ・モデルで必要になる、ビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。
たとえば、図41-7に示す地理マップの点テーマのデータソースは、Summit ADF DVTサンプル・アプリケーション用に作成したビュー・オブジェクトから取得しています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

- 点テーマを使用した地理マップをページに追加します。詳細は、「点テーマを使用して地図を作成する方法」を参照してください。

点スタイルのアイテムをマップの点テーマに追加して、データ値の範囲を表現するには:

1. 「構造」ウィンドウで、dvt:mapPointThemeタグを右クリックし、点テーマの中に挿入→「点スタイルのアイテム」を選択します。

2. 「点スタイルのアイテム」の「プロパティ」ウィンドウで、表41-1に示すように値を設定します。

表41-1 点スタイル・アイテムのプロパティ

プロパティ

設定値

Id

点スタイル・アイテムの一意のIDを指定します。

MinValue

定義するデータ範囲の最小値を指定します。

MaxValue

定義するデータ範囲の最大値を指定します。

ShortLabel

ユーザーが点アイテムの上にカーソルを置いたときに表示されるテキストを指定します。たとえば、低い在庫レベルの点アイテムを定義する場合は、このプロパティの値としてLow Inventoryと入力します。

ImageURL

イメージ・ファイルへのURLを指定するか、ドロップダウン・リストから選択します。実行時に、指定したイメージはマップ上に表示され、MinValueおよびMaxValueプロパティによって指定されたデータ範囲を表します。

あるいは、「その他」セクションに表示されるBuiltInImageドロップダウン・リストによって参照される様々な事前定義済イメージの1つを選択できます。

HoverImageURL

イメージ・ファイルへのURLを指定するか、ドロップダウン・リストから選択します。実行時に、指定したイメージは、ユーザーが点アイテムの上にカーソルを置くと表示されます。

SelectedImageURL

イメージ・ファイルへのURLを指定するか、ドロップダウン・リストから選択します。実行時に、指定したイメージは、ユーザーが点アイテムを選択すると表示されます。

3. 手順1と手順2でデータ値の低範囲についてデータ値の範囲を定義した場合は、手順1と手順2を繰り返して、データ値の中範囲および高範囲を適切な値で定義します。

注意:

mapPointStyleItem子タグを使用して点のスタイルをカスタマイズする方法は、カスタム点イメージを指定できる宣言的な方法です。コールバックを使用してカスタム・イメージだけでなくカスタムHTMLを指定する方法の詳細は、「マップ点テーマへのカスタム点スタイル・アイテムの追加に関する必知事項」を参照してください。

41.2.4 点テーマを使用した地図の作成時の処理

点テーマを使用した地理マップを「データ・コントロール」パネルから作成すると、次の処理が行われます。

- 点テーマのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- 地理マップ・コンポーネントに必要なタグをJSFページに追加します。

- 地理マップ・タグ内の必要な点テーマの子タグをJSFページに追加します。

次の例は、点テーマを使用する地理マップ用に生成された行セット・バインディングを示しています。

<bindings>
<mapTheme xmlns="http://xmlns.oracle.com/adfm/dvt"></mapTheme>
<mapTheme IterBinding="WorldProductInventory1Iterator"
id="WorldProductInventory1"
xmlns="http://xmlns.oracle.com/adfm/dvt">
<mapThemeDataMap convert="false" mapThemeType="point">
<data>
<item value="AmountInStock"
label="${adfBundle['view.ViewControllerBundle'].AMOUNT_IN_
STOCK}"/>
</data>
<item type="us_form_2" street="Address" city="City" state="State"
zipCode="ZipCode" label="WarehouseId"/>
</mapThemeDataMap>
</mapTheme>
<mapTheme IterBinding="SWarehouseView1Iterator" id="SWarehouseView1"
xmlns="http://xmlns.oracle.com/adfm/dvt">
<mapThemeDataMap convert="false" mapThemeType="point">
<data>
<item value="ProductCount"
label="${adfBundle['view.ViewControllerBundle'].PRODUCT_COUNT}"/>
</data>
<item type="lat_long" longitude="Longitude" latitude="Latitude"
label="ProductCount"/>
</mapThemeDataMap>
</mapTheme>
</bindings>

次の例は、地理マップおよびその点テーマに対してJSFページで生成されるXMLコードを示しています。

<dvt:map id="map" startingX="-104.15" mapServerConfigId="mapConfig1"
baseMapName="ELOCATION.WORLD_MAP" mapZoom="3"
inlineStyle="width:600px; height:375px;" startingY="42.09">
<dvt:mapPointTheme id="mapPointTheme"
value="#{bindings.SWarehouseView1.geoMapModel}">
<dvt:mapPointStyleItem maxValue="5.0"
shortLabel="#{viewcontrollerBundle.PRODUCT_COUNT_LOW}"
imageURL="/images/error.png" minValue="0.0"/>
<dvt:mapPointStyleItem minValue="6.0" maxValue="7.0"
shortLabel="#{viewcontrollerBundle.PRODUCT_COUNT_OK}"
imageURL="/images/checkmark.png"/>
<dvt:mapPointStyleItem minValue="8.0"
shortLabel="#{viewcontrollerBundle.PRODUCT_COUNT_HIGH}"
imageURL="/images/warning.png"/>
</dvt:mapPointTheme>
</dvt:map>
<dvt:mapToolbar mapId="map" id="mt1"/>

41.2.5 マップ点テーマへのカスタム点スタイル・アイテムの追加に関する必知事項

マップの点にカスタムHTMLとカスタム・イメージを指定する場合は、mapPointThemeタグのcustomPointCallback属性を使用して、このカスタマイズを実行できます。

注意:

マップ点テーマのcustomPointCallback属性を設定すると、マップはdvt:mapPointStyleItem子タグをすべて無視します。コールバックによってこれらのタグはオーバーライドされるためです。

コールバックを使用してマップ点のスタイルをカスタマイズする手順:

1. 目的の点のカスタマイズを実行するメソッドをJavaで記述します。

2. このメソッドをマップのマネージドBeanに格納します。

マネージドBeanの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のマネージドBeanの作成と使用に関する項を参照してください。

3. マップの点テーマをデータ・バインディングした後で、「プロパティ」ウィンドウを使用して、マネージドBeanのメソッドへの参照を、dvt:mapPointThemeタグのcustomPointCallback属性に指定します。

たとえば、マネージドBeanの名前がMapSampleBean、メソッドの名前がsetCustomPointStyleの場合、その参照は#{mapSampleBean.CustomPointStyle}となります。

41.2.6 色テーマを使用して地理マップを作成する方法

色テーマを使用して地理マップを作成すると、マップの領域を色分け表示できるようになります。たとえば、色テーマを使用すると、州ごとのインベントリ・レベルを色の範囲で表現する形式で倉庫のある州を識別できます。

色テーマを使用した地理マップを作成する場合は、最初にベース・マップを構成してから、そのマップの色テーマをデータ・コレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。また、色テーマをレイヤー化すると、それとは別のテーマ用に構成およびバインドされているベース・マップに重ねることもできます。

たとえば、図41-10に示す地理マップには、各州のインベントリ・レベルを表現する形式で倉庫のある州を識別する色テーマが設定されています。

図41-10 色テーマを使用した地理マップ

始める前に:

データバインドされた地理マップについて理解しておいてください。詳細は、「データバインドされた地理マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従い、色テーマを使用した地理マップのデータ・モデルで必要になる、ビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。
たとえば、図41-10に示す色テーマを使用した地理マップのデータ・ソースは、Summit ADF DVTサンプル・アプリケーション用に作成したビュー・オブジェクトから取得しています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされた色テーマを使用して地理マップを作成するには:

1. 「データ・コントロール」パネルから、コレクションを選択します。
図41-11に示す「データ・コントロール」パネルでは、地域(この例では、米国の州)の製品インベントリ・レベルを色で表すマップの色テーマを作成するために、WorldProductInventory1コレクションを選択しています。

図41-11 製品インベントリ・レベルのデータ・コレクション

2. すでに地理マップ・コンポーネントを含んでいるJSFページにコレクションをドラッグし、ポップアップ・メニューから「地理マップ」→「マップおよび色のテーマ」を選択します。

3. ページ上のマップをまだ構成していない場合は、「地理マップの作成」ダイアログの入力を完了してください。詳細は、「地理ベース・マップの構成方法」を参照してください。それ以外の場合は、以下のいずれかを実行します。

- ドロップダウン・リストから、使用するマップ構成を選択します

- 「OK」クリックして、使用可能なマップ構成をそのまま使用します

- 「新規」をクリックして、新しいベース・マップを構成します

- 「編集」をクリックして、使用可能なマップ構成に変更を加えます

4. ベース・マップに色テーマをレイヤー表示するときに、それとは別のテーマ用にベース・マップが構成およびバインドされている場合は、「作成」ダイアログで「色テーマ」を選択します。

5. 「色マップ・テーマの作成」ダイアログの「テーマID」フィールドで、「ID」フィールドのマップ・テーマに一意の識別子を入力します。

6. ベース・マップ・テーマ・セクションで、地理マップで使用するベース・マップのカラー・テーマを次のように指定します。

a. 「名前」フィールドで、ベース・マップ・テーマの名前を選択します。

b. 「位置」では、選択したベース・マップ・テーマ内の位置の列に対応するデータ・コレクション内の位置の列を選択します。

c. オプションで、「サンプル・テーマ・データの表示」をクリックし、「サンプル・テーマ・データ」ダイアログを表示します。このダイアログでは、実際のデータの先頭のいくつかの行を確認できるため、適切な位置列を指定できます。
たとえば、アメリカ合衆国のマップの州で構成される地域のデータを確認するには、図41-12で示すように、MAP_STATES_NAMEを選択できます。

注意:

Oracle Spatialの管理者はサンプル・データの表示を無効にできます。このボタンが使用できない場合は、管理者に連絡して指示を求めてください。

図41-12 地域または州のサンプル・テーマ・データ

7. 「外観」セクションで、カラー・テーマの外観を次のように指定します。

a. 「データ・バケット数」に、この地理マップのデータのグループ数を入力します。各グループは、色別にコード化されます。この数の指定後は、最小値と最大値に色を指定できます。他の値の色は、RGBアルゴリズムを使用して自動的に選択されます。

b. 「最小値の色」で、最小値の色を選択します。

c. 「最大値の色」で、最大値の色を選択します。

注意:

データ・バケットごとに正確な色を指定する場合は、「マップ・カラー・テーマでの色のカスタマイズに関する必知事項」を参照してください。

8. 「データ」セクションで、コレクション内のデータに関する次の情報を指定します。

a. 「位置」では、ベース・マップ・テーマから選択した位置列の値に対応するデータ・コレクション内の列を選択します。

b. 「ロケーション・ラベル」では、位置列の値に関連付けられているラベルを含むデータ・コレクション内の列を選択します。これらのラベルは、色をクリックしたときまたは色の上にカーソルを置いたときに表示される「情報」ウィンドウに表示されます。

c. 「データ・ラベル」には、色をクリックしたときまたは色の上にカーソルを置いたときに表示される「情報」ウィンドウおよびツールチップでのデータの説明に使用されるラベルを入力します。たとえば、「情報」ウィンドウでは、データ値の前にProduct Popularityなどのラベルを表示できます。データ・ラベルに使用するテキスト・リソースを入力することもできます。テキスト・リソースは、リソース・バンドルからの翻訳可能な文字列または動的ラベル用に実行時に実行されるEL式のいずれかにできます。ドロップダウン・リストを使用して、「テキスト・リソースの選択」または「式ビルダー」ダイアログを選択します。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

9. 「行選択の有効化」は、マスター/ディテール関係を有効にする場合にのみ使用します。これは、マップ・テーマのデータ・コレクションが、ページ上の別のUIコンポーネントに表示されるディテール・ビューとのマスター/ディテール関係においてマスターである場合に便利です。

図41-13に、商品の人気を州別のカラー・テーマで示す「カラー・マップ・テーマの作成」ダイアログを示します。

図41-13 商品の人気を州別に示す「カラー・マップ・テーマの作成」ダイアログ

41.2.7 地図へのカラー・テーマの追加時の処理

カラー・テーマを「データ・コントロール」パネルから既存の地図にドロップすると、次の処理が行われます。

- カラー・テーマのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- 地理マップ・タグ内の必要なカラー・テーマの子タグをJSFページに追加します。

次の例は、地理マップの色テーマに生成された行セット・バインディングを示しています。

<bindings>
<mapTheme IterBinding="WorldProductInventory1Iterator"
id="WorldProductInventory1"
xmlns="http://xmlns.oracle.com/adfm/dvt">
<mapThemeDataMap convert="false" mapThemeType="color">
<item type="location" value="State" label="State"/>
<data>
<item value="AmountInStock"
label="${adfBundle['view.ViewControllerBundle'].STOCK_LEVELS}"/>
</data>
</mapThemeDataMap>
</mapTheme>
</bindings>

次の例は、アメリカ合衆国のマップ上の各州における商品の人気を表す色テーマに対してJSFページで生成されるXMLコードを示しています。

<dvt:map id="map" startingX="-102.39" mapServerConfigId="mapConfig1"
baseMapName="ELOCATION_MERCATOR.WORLD_MAP"
mapZoom="3" inlineStyle="width:600px; height:375px;" startingY="40.27"
summary="Geographic map with color theme">
<dvt:mapColorTheme id="mapColorTheme" themeName="MAP_STATES_ABBRV"
value="#{bindings.WorldProductInventory1.geoMapModel}"
bucketCount="5" minColor="#ff0000"
maxColor="#00ff00" locationColumn="STATE_ABRV"/>
</dvt:map>

41.2.8 マップ・カラー・テーマでの色のカスタマイズに関する必知事項

マップ・カラー・テーマのデータ・バインディング時には、データ・バケットに対する最小値の色および最大値の色のみを指定できます。最小値から最大値までのバケットの色は、マップがアルゴリズムを使用して決定します。しかし、データ・バインディングを完了すると、各データ・バケットに使用する正確な色を指定できるようになります。

dvt:mapColorThemeタグの「プロパティ」ウィンドウで、colorList属性を使用すると、各バケットの色を指定できます。色の配列をこの属性にバインドするか、セミコロンのセパレータを使用して色の文字列を指定できます。

たとえば、この属性の値を#ff0000;#00ff00;#0000ffに設定した場合、最初のバケットは赤、2番目のバケットは緑、3番目のバケットは青となります。

41.2.9 円グラフまたは棒グラフのテーマを使用した地理マップの作成方法

円グラフ・テーマまたは棒グラフ・テーマを使用して地理マップを作成すると、緯度と経度または住所で識別されるマップ内の特定の場所を表示できるようになります。たとえば、点テーマで倉庫の場所をマップに示します。表示される点のスタイルをカスタマイズすると、倉庫のセットに含まれる倉庫内の製品数(高、適正、低)に応じた個別のイメージを使用して、それぞれの製品数を区別できるようになります。

円グラフまたは棒グラフのテーマを使用した地理マップを作成する場合は、最初にベース・マップを構成してから、そのマップの円グラフまたは棒グラフのテーマをデータ・コレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。また、円グラフまたは棒グラフのテーマをレイヤー化すると、それとは別のテーマ用に構成およびバインドされているベース・マップに重ねることもできます。

たとえば、図41-14に示す地理マップには、米国内の倉庫の場所と、それらの倉庫の製品数レベルを表す点テーマが設定されています。

図41-14 円グラフ・テーマを使用した地理マップ

たとえば、図41-14に示す地理マップには、米国内の倉庫の場所と、それらの倉庫の製品数レベルを表す点テーマが設定されています。

図41-15 棒グラフ・テーマを使用した地理マップ

始める前に:

データバインドされた地理マップについて理解しておいてください。詳細は、「データバインドされた地理マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従い、円グラフまたは棒グラフのテーマを使用した地理マップのデータ・モデルで必要になる、ビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。
たとえば、図41-14に示す円グラフ・テーマと図41-15に示す棒グラフ・テーマのデータソースは、Summit ADF DVTサンプル・アプリケーション用に作成したビュー・オブジェクトから取得しています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされた円グラフまたは棒グラフのテーマを使用した地理マップを作成するには:

1. 「データ・コントロール」パネルから、コレクションを選択します。
図41-16に、WorldProductInventory1を選択し、ある州で人気のある製品カテゴリを表すために、既存の地図マップ・コンポーネントに円グラフまたは棒グラフの棒テーマを作成する例を示します。

図41-16 製品別インベントリ・レベルのデータ・コレクション

2. JSFページにコレクションをドラッグし、ポップアップ・メニューから「地理マップ」→「マップおよび円グラフのテーマ」または「マップおよび棒グラフのテーマ」を選択します。

3. ページ上のマップをまだ構成していない場合は、「地理マップの作成」ダイアログの入力を完了してください。詳細は、「地理ベース・マップの構成方法」を参照してください。それ以外の場合は、以下のいずれかを実行します。

- ドロップダウン・リストから、使用するマップ構成を選択します

- 「OK」クリックして、使用可能なマップ構成をそのまま使用します

- 「新規」をクリックして、新しいベース・マップを構成します

- 「編集」をクリックして、使用可能なマップ構成に変更を加えます

4. ベース・マップに円グラフ・テーマをレイヤー表示するときに、それとは別のテーマ用にベース・マップが構成およびバインドされている場合は、「作成」ダイアログで「円グラフ・テーマ」を選択します。

5. 円グラフ・テーマの作成ダイアログで、次の手順を実行して、作業対象にする新しいテーマとベース・マップのテーマの要素を識別します。

a. 「テーマID」で、作成する円グラフ・テーマの一意のIDを入力します。

b. ベース・マップ・テーマ・セクションで、ベース・マップの名前と、円グラフを配置する地域を選択します。

6. 「外観」セクションで、「データ」の下で次のようにします。

a. 「位置」では、選択したベース・マップ・テーマ内の位置の列に対応するデータ・コレクション内の位置の列を選択します。
必要に応じて、適切な位置の列を識別できるように、「サンプル・テーマ・データの表示」をクリックして実際のデータの最初の数行を確認します。

b. 「ロケーション・ラベル」では、データ・コレクション内の位置のラベルを含むデータ・コレクション内の列を選択します。

c. 「円グラフの区分の属性」のグリッド(円グラフの場合)、または「系列の属性」のグリッド(棒グラフの場合)で、作成中の円グラフまたは棒グラフで表す値を含む各属性を入力します。

d. 各円グラフの区分の属性またはシリーズ属性の横に、その属性のデータ値のラベルとして使用するテキストを入力します。テキストを直接入力したり、データ値を1つ使用する場合のようにNo Labelを選択してラベルを抑制したり、リソース・バンドルからテキスト・リソースを指定したりできます。またはEL式ビルダーを使用して実行時にラベル・テキストを評価することもできます。

7. 「行選択の有効化」は、関連するコンポーネントで行を選択可能にする場合にのみ選択します。このコンポーネントは、作成中の地図に関連するデータ・コレクションにリンクされているコンポーネントがページに含まれる場合に使用します。

8. 「OK」をクリックします。

図41-17に、製品別インベントリ・レベル用に必要事項を入力した「円グラフ・マップ・テーマの作成」ダイアログを示します。

図41-17 製品別インベントリ・レベルの「円グラフ・マップ・テーマの作成」

図41-17に、製品別インベントリ・レベル用に必要事項を入力した「棒グラフ・マップ・テーマの作成」ダイアログを示します。

図41-18 製品別インベントリ・レベルの「棒グラフ・マップ・テーマの作成」

41.2.10 地理マップへの円グラフ・テーマまたは棒グラフ・テーマの追加時の処理

円グラフ・テーマを「データ・コントロール」パネルから既存の地図にドロップすると、次の処理が行われます。

- 円グラフ・テーマのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- マップXML内で必要な円グラフ・テーマのコードをJSFページに追加します。

次の例は、地理マップの円グラフ・テーマに生成された行セット・バインディングを示しています。

<mapTheme IterBinding="PopularCategoriesByState1Iterator"
id="PopularCategoriesByState1"
xmlns="http://xmlns.oracle.com/adfm/dvt">
<mapThemeDataMap mapThemeType="pieChart">
<item type="location" value="StateProvince" label="StateProvince"/>
<data>
<item value="AudioVideo"
label="${adfBundle['view.ViewControllerBundle'].AUDIO_VIDEO}"/>
<item value="CellPhones"
label="${adfBundle['view.ViewControllerBundle'].CELL_PHONES}"/>
<item value="Games"
label="${adfBundle['view.ViewControllerBundle'].GAMES}"/>
</data>
</mapThemeDataMap>
</mapTheme>

次の例は、地理マップの円グラフ・テーマに対してJSFページで生成されるXMLコードを示しています。

<dvt:mapPieGraphTheme id="mapPieGraphTheme1"
themeName="MAP_STATES_NAME"
shortLabel="#{viewcontrollerBundle.POPULAR_CATEGORIES}"
pieRadius="10"
styleName="comet"
value="#{bindings.PopularCategoriesByState1.geoMapModel}"
locationColumn="POLYGON_ID"/>
</dvt:mapPieGraphTheme>

41.3 データバインドされたテーマ・マップの作成

テーマ・マップでは、ビジネス・データをスタイル設定されたエリア内にパターンまたは関連付けられたマーカーとして表し、リモートのOracle MapViewerサービスへの接続は必要ありません。テーマ・マップでは、地理マップでの地理的な詳細なしで、データに焦点を合せます。

テーマ・マップは、米国、世界をはじめ、世界の大陸や地域(EMEAやAPACなど)などのあらかじめ作成されたベース・マップとともにパッケージ化されています。それぞれのベース・マップには、いくつかのリージョンのセットと、都市の固定セットが1つ含まれます。リージョンまたは都市の1つのセットはレイヤーと呼ばれます。各レイヤーは、データ・コレクションにバインドし、データを色やパターンの塗りつぶし、またはデータ・マーカー、あるいはその両方で表すためにスタイルを設定できます。実行時には、テーマ・マップでドリルが有効になっていないかぎり、一度に表示できるのは1つのマップ・レイヤーとその関連するデータのみです。

テーマ・マップに表示されるデータは、データ・コレクションに基づいています。ADFデータ・コントロールを使用すると、JDeveloperではデータ・バインディングが宣言的なタスクとなります。「データ・コントロール」パネルからJSFページにコレクションをドラッグ・アンド・ドロップし、「コンポーネント・ギャラリ」を使用してデータを表示するベース・マップとマップ・レイヤーを選択します。レイヤー・ブラウザおよびバインディング・ダイアログを使用して、テーマ・マップでデータ・コレクション属性をデータ・レイヤーにバインドできます。

マップ・レイヤーをデータ・コレクションのデータ行に関連付けるには、スタンプを使用します。スタンプを使用すれば、データ・モデル内の各データ行をスタイル(色またはパターンなど)、マーカー(円形または四角形など)、またはイメージにより識別できます。スタンプを使用すると、テーマ・マップではエリア、マーカーまたはイメージごとに子コンポーネントが作成されません。むしろ、コンポーネントのコンテンツは、データ・コレクションの行など、データ属性ごとに1回、繰り返しレンダリングされるか、スタンプされます。

図41-19に、USAベース・マップを使用したテーマ・マップを示します。このSummit ADF DVTサンプル・アプリケーションのマップでは、州マップ・レイヤーを使用して、顧客の場所と倉庫の場所を表示し、倉庫のある州については製品インベントリ・レベルを表示しています。この例は、「データ・コントロール」パネルおよびテーマ・マップのバインディング・ダイアログを使用したときの、テーマ・マップのデフォルト機能を示しています。このデフォルト機能には、データにバインドされた凡例と、スタイル設定された点およびエリアに関連付けられるラベルなどがあります。

図41-19 顧客の場所と倉庫の場所を表示するテーマ・マップ

テーマ・マップのエンド・ユーザー機能とプレゼンテーション機能、ユースケース、タグ構造、テーマ・マップへの特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のテーマ・マップ・コンポーネントの使用方法に関する項を参照してください。

41.3.1 ADFデータ・コントロールを使用してテーマ・マップを作成する方法

thematicMapコンポーネントは、モデルを使用して、基になるリストのデータにアクセスします。固有のモデル・クラスはoracle.adf.view.rich.model.CollectionModelです。java.util.List、java.util.Arrayおよびjavax.faces.model.DataModelなど、その他のモデル・インスタンスも使用できます。データ・レイヤーではインスタンスがCollectionModelに自動的に変換されます。

始める前に:

データバインドされたテーマ・マップについて理解しておいてください。詳細は、「データバインドされたテーマ・マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

「データ・コントロール」パネルを使用してテーマ・マップを作成する手順は次のとおりです。

1. 「データ・コントロール」パネルから、データ・コレクションを選択します。

図41-20に、倉庫の場所と製品インベントリ・レベルのデータ・コレクションを示します。

図41-20 倉庫の場所と在庫のデータ・コレクション

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「テーマ・マップ」を選択します。

3. 「コンポーネント・ギャラリ」で、データ表示のために構成するベース・マップに関連付けられたマップ・レイヤーを選択します。この例では、米国のベース・マップで州のマップ・レイヤーが選択されています。図41-21に、米国の州のマップ・レイヤーが選択されているコンポーネント・ギャラリを示します。

図41-21 テーマ・マップのコンポーネント・ギャラリ

デフォルトでは、選択したマップ・レイヤーに面データ・レイヤーや点データ・レイヤーを追加するための「データ・レイヤーの作成」ダイアログが開きます。図41-19に示したテーマ・マップでは、倉庫の製品レベルごとに米国の州をスタイル化するように、面データ・レイヤーが構成されています。

4. 「データ・レイヤーの作成」ダイアログで、次のように入力します。

- 「レイヤーID」: 定義するデータ・レイヤーの一意の名前を入力します。デフォルトでは、一意の連番のID、つまりdl1、dl2などになります。

- 「面」: このオプションを選択して、面データ・レイヤーをマップ・レイヤーに追加します。

- 「エリア・レイヤー」: データ・レイヤーを追加するマップ・レイヤーを参照します。この例では、「USA(州)」マップ・レイヤーを参照します。

- 「位置」: データ・レイヤー内のエリアに対応するデータの位置を決定する、データ・モデル内の列を表す属性を選択します。位置は、データが表示されるベース・マップのリージョンのIDです。詳細は、「基準となるマップの位置IDについて」を参照してください。

- 「マスター/ディテールの現在行の設定」: マスター/ディテール関係を有効化する場合に選択します。これは、テーマ・マップのデータ・コレクションが、ページ上の別のUIコンポーネントに表示されるディテール・ビューとのマスター/ディテール関係においてマスターである場合に便利です。詳細は、「マスター/ディテール関係の構成について」を参照してください。

図41-22に、設定済の「データ・レイヤーの作成」ダイアログを示します。

図41-22 面データ・レイヤーの作成ダイアログ

areaDataLayerコンポーネントを表す面データ・レイヤーおよびareaコンポーネントを表すエリアが、レイヤー・ブラウザ階層に追加されます。図41-23に、面データ・レイヤーおよびエリアをマップ・レイヤーに追加した後で展開したレイヤー・ブラウザを示します。

図41-23 テーマ・マップ・レイヤー・ブラウザ

5. レイヤー・ブラウザで、面データ・レイヤーを開き、スタイル設定するエリアを選択し、「編集」アイコンをクリックします。

注意:

テーマ・マップ・レイヤー内のすべてのエリアについてデフォルトのスタンプを使用してエリアを構成することも、子attributeGroupsタグを使用して、データ・セット内のカテゴリ・グループに基づいてスタイル属性タイプを自動的に生成することもできます。areaタグとattributeGroupsタグの両方で、同じスタイル属性が設定されている場合は、attributeGroupsスタイル・タイプが優先されます。詳細は、「データを表示するためのエリア、マーカーおよびイメージのスタイル設定」を参照してください。

6. 「エリアの構成」ダイアログの「属性グループ」ページで、次のように入力します。

- 「グループ化ルール」: この表を使用して、データ・コレクション内のデータのカテゴリ・グループのスタイルを指定します。「追加」アイコンを使用して、カテゴリ・グループのルールを構成する表に行を追加し、「削除」アイコンを使用して選択した行を表から削除します。各グループ化ルールはattributeGroupsコンポーネントとして表され、一意の連番ID (ag1、ag2など)が割り当てられます。
表に追加された行ごとに、次のように入力します。

- 「値でグループ化」: データ値のグループ化に使用するデータ・セットの列を表す属性を入力するか、ドロップダウン・リストを使用して選択します。たとえば、ProductCountは州ごとの倉庫内製品インベントリ・レベルを表します。

注意:

選択した属性は、カテゴリ化できる離散値で構成される必要があります。たとえば、40から45までの数値範囲は自動的にはグループ化されません。

- 「エリア・プロパティ」: 該当のエリアのスタイル設定に使用するプロパティをドロップダウン・リストを使用して選択します。エリアは、色、パターン、不透明度またはこれら有効値の任意の組合せを使用してスタイル設定できます。ダイアログのドロップダウン・リストから「複数の属性の選択」を選択し、値の組合せを指定します。
各プロパティに生成されるデフォルトのスタイル値は、ADFスキンのCSSスタイル・プロパティを使用して定義されます。各attributeGroupsタイプには、スキンで定義されたデフォルトのランプがあり、索引ベースのプロパティを目的の値に設定することによりカスタマイズできます。詳細は、「属性グループのデフォルトのスタイル値について」を参照してください。

- 「凡例ラベル」: テキストを入力するか、テーマ・マップの凡例のカテゴリ・グループに使用するテキストを表す属性をドロップダウン・リストを使用して選択します。ドロップダウン・リストから「式ビルダー」を選択し、EL式を作成して凡例テキストを指定することもできます。詳細は、「データバインドされた凡例の作成」を参照してください。

- 「値固有のルール」: クリックして、データ・セットのカテゴリ・グループに1つ以上のデータ値の詳細を指定する際に使用する「一致ルール」表および「例外ルール」表を開きます。たとえば、一致ルールを使用して、製品インベントリ・レベルの低い倉庫があるすべての州には、事前定義済の色範囲ではなく、#DD1E2Fの色でスタイルを設定します。

注意:

これらの表で指定された一致ルールや例外ルールは、「グループ化ルール」表で定義された設定に優先します。

- 「一致ルール」: このオプションを使用して、データ・コレクション内のデータ・グループの1つ以上のデータ値に一致するスタイル・ルールを指定します。「追加」アイコンを使用して、カテゴリ・グループの一致ルールを構成する表に行を追加し、「削除」アイコンを使用して選択した行を表から削除します。各一致ルールはattributeMatchRuleコンポーネントとして表され、一意の連番ID (amr1、amr2など)が割り当てられます。プロパティとプロパティ値は、子f:attributeタグで定義されます。次に例を示します。

<dvt:attributeMatchRule id="amrl" group="Mountain Dew">
<f:attribute name="color" value="#ffff00"/>
</dvt:attributeMatchRule>

表に追加された行ごとに、次のように入力します。

- 「グループ値」: この一致ルールの実行をトリガーする「値でグループ化」属性の値を入力します。この例では、倉庫内製品インベントリ・レベルのデータ・コレクションの属性には、low、medおよびhighの値が含まれます。

- 「プロパティ」: 該当のデータ値のスタイル設定に使用するプロパティをドロップダウン・リストを使用して選択します。エリアは、色、パターンまたは不透明度の値を使用してスタイル設定できます。ここで選択したプロパティは、「グループ化ルール」属性の「エリア・プロパティ」に表示されるプロパティ・タイプのいずれかに一致する必要があります。

- 「プロパティ値」: 入力するかドロップダウン・リストを使用して、値をプロパティに割り当てます。一致オーバーライドにより指定された値が、グループ化ルールによって返された事前作成のランプ内にもある場合、その値はオーバーライドでのみ使用され、事前作成のランプではスキップされます。
色の有効な値は、RGB16進数色です。

パターンの有効値として、12個の事前作成されたパターン(smallChecker、largeDiamond、smallDiagonalRight、largeCrosshatchなど)から選択することもできます。塗りつぶし色が指定されている場合は、パターンはその色、背景色はデフォルトの白で表示されます。

不透明度の有効な値範囲は、0.0(透明)から1.0(不透明)です。

- 「例外ルール」: データ・セット内のカテゴリ・グループのスタイル・ルールについて1つ以上の例外を指定します。「追加」アイコンを使用して、例外ルールを構成する表に行追加し、「削除」アイコンを使用して任意の行を表から削除します。各例外ルールはattributeExceptionRuleコンポーネントとして表され、一意の連番ID (aer1、aer2など)が割り当てられます。プロパティとプロパティ値は、子f:attributeタグで定義されます。
表に追加された行ごとに、次のように入力します。

- 「条件」: EL式を入力するか、ドロップダウン・リストを使用して「式ビルダー」ダイアログを開き、EL式を作成します。この式は、特定の条件を満たす場合にスタイル・プロパティ値を別の値に置き換えます。次に例を示します。

#{row.Sales gt 100000}

- 「プロパティ」: 該当のデータ値のスタイル設定に使用するプロパティをドロップダウン・リストを使用して選択します。エリアは、色、パターンまたは不透明度の値を使用してスタイル設定できます。ここで選択したプロパティは、「グループ化ルール」属性の「エリア・プロパティ」に表示されるプロパティ・タイプのいずれかに一致する必要があります。

- 「プロパティ値」: 入力するかドロップダウン・リストを使用して、値をプロパティに割り当てます。一致オーバーライドにより指定された値が、グループ化ルールによって返された事前作成のランプ内にもある場合、その値はオーバーライドでのみ使用され、事前作成のランプではスキップされます。
色の有効な値は、RGB16進数色です。

パターンの有効値として、12個の事前作成されたパターン(smallChecker、largeDiamond、smallDiagonalRight、largeCrosshatchなど)から選択することもできます。塗りつぶし色が指定されている場合は、パターンはその色、背景色はデフォルトの白で表示されます。

不透明度の有効な値範囲は、0.0(透明)から1.0(不透明)です。

- 「凡例ラベル」: 凡例ラベルに使用するテキスト・リソースを入力します。テキスト・リソースは、リソース・バンドルからの翻訳可能な文字列または実行時に実行されるEL式のいずれかにできます。ドロップダウン・リストを使用して、「テキスト・リソースの選択」または「式ビルダー」ダイアログを選択します。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

注意:

テキスト・リソース・オプションは、固定エリアでのみ使用可能です。行数が変動するエリアでは、EL式を使用して行数変動キーを取得し、リソース・バンドルでテキスト・リソースを検索します。たとえば、次のようになります。

#{viewController.ResourceBundle[row.label]}

- 「メッセージ」: エリアの構成に関連付けられたアラートを必要に応じて確認したり消去します。

図41-24に、設定済の「エリアの構成」ダイアログを示します。メッセージ・ペインの警告は、ダイアログの「デフォルト・スタンプ」ページで指定されているデフォルトのエリアの色が、「グループ化ルール」で指定された色や、「属性グループ」ページで指定された値固有のオーバーライドで上書きされることをユーザーにアラートします。

図41-24 「エリアの構成」ダイアログの「属性グループ」ページ

7. レイヤー・ブラウザを使用して、倉庫の場所を表すグローバル・ポイント・データ・レイヤーを追加します。このレイヤーの作成には、テーマ・マップを作成したときに使用したものと同じデータ・コレクションを使用します。手順の詳細は、「テーマ・マップにデータ・レイヤーを追加する方法」を参照してください。

8. レイヤー・ブラウザを使用して、顧客の住所を表すグローバル・ポイント・データ・レイヤーを追加します。このレイヤーの作成には、テーマ・マップを作成したときに使用したものとは別のデータ・コレクションを使用します。手順の詳細は、「テーマ・マップにデータ・レイヤーを追加する方法」を参照してください。図41-25に、顧客の場所のデータ・コレクションを示します。

図41-25 顧客の住所のデータ・コレクション

9. レイヤー・ブラウザを使用して、グローバル・ポイント・データ・レイヤーで顧客の場所を表すためのマーカーを追加して、スタイルを設定します。手順の詳細は、「データを表示するためのエリア、マーカーおよびイメージのスタイル設定」を参照してください。

図41-26では、図41-20に示したテーマ・マップのレイヤー・ブラウザを開いています。

図41-26 テーマ・マップ・レイヤー・ブラウザ

10. データ・バインドされた凡例とラベル追加して、スタイル設定した点と面に関連付けるように構成します。手順の詳細は、「データバインドされた凡例の作成」を参照してください。

41.3.2 データ・コントロールを使用したテーマ・マップ作成時の処理

ADFデータ・コントロールを使用してテーマ・マップを作成すると、JDeveloperにより、次が実行されます。

- JSFページのページ定義ファイルでテーマ・マップのバインディングが定義されます。

- DVTテーマ・マップ・コンポーネント用のコードがJSFページに挿入されます。

次の例は、図41-19に例示したテーマ・マップの場合の、JSFページのページ定義ファイルに定義されたバインディングを示しています。

<bindings>
<tree IterBinding="WorldProductInventory1Iterator" id="WorldProductInventory1">
<nodeDefinition DefName="model.WorldProductInventory" Name="WorldProductInventory10">
<AttrNames>
<Item Value="Address"/>
<Item Value="AmountInStock"/>
<Item Value="Category"/>
<Item Value="CategoryId"/>
<Item Value="City"/>
<Item Value="Country"/>
<Item Value="CountryCode"/>
<Item Value="CountryId"/>
<Item Value="Id"/>
<Item Value="Id1"/>
<Item Value="Id2"/>
<Item Value="Id3"/>
<Item Value="Id4"/>
<Item Value="Latitude"/>
<Item Value="Longitude"/>
<Item Value="ProdName"/>
<Item Value="ProductId"/>
<Item Value="RegName"/>
<Item Value="RegionId"/>
<Item Value="ReorderPoint"/>
<Item Value="State"/>
<Item Value="WarehouseId"/>
<Item Value="ZipCode"/>
</AttrNames>
</nodeDefinition>
</tree>
<tree IterBinding="SCustomerView1Iterator" id="SCustomerView1">
<nodeDefinition DefName="model.SCustomerView" Name="SCustomerView10">
<AttrNames>
<Item Value="Address"/>
<Item Value="City"/>
<Item Value="CountryId"/>
<Item Value="Id"/>
<Item Value="Name"/>
<Item Value="State"/>
<Item Value="ZipCode"/>
</AttrNames>
</nodeDefinition>
</tree>
<tree IterBinding="SWarehouseView1Iterator" id="SWarehouseView1">
<nodeDefinition DefName="model.SWarehouseView" Name="SWarehouseView10">
<AttrNames>
<Item Value="Address"/>
<Item Value="City"/>
<Item Value="CountryId"/>
<Item Value="Id"/>
<Item Value="Latitude"/>
<Item Value="Longitude"/>
<Item Value="ManagerId"/>
<Item Value="Phone"/>
<Item Value="ProductCount"/>
<Item Value="State"/>
<Item Value="ZipCode"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

次の例は、図41-19に例示したテーマ・マップのJSFページに挿入されるコードを示しています。

<dvt:thematicMap id="tm1" basemap="usa" animationOnDisplay="alphaFade"
summary="#{viewcontrollerBundle.THEMATIC_MAP_DISPLAYING_
WAREHOUSE_PRODUCT_INVENTORY_LEVELS}">
<dvt:areaLayer layer="states" id="al1">
<dvt:areaDataLayer id="dal1"
value="#{bindings.SWarehouseView1.collectionModel}"
var="row">
<dvt:areaLocation name="#{row.State}" id="al2">
<dvt:area id="a1" shortDesc="#{row.ProductCount} units">
<dvt:attributeGroups id="ag1" type="color"
value="#{row.ProductCount le 5 ? 'low' :
(row.ProductCount le 8 ? 'med' : 'high')}"
label="#{row.ProductCount le 5 ? 'Low Product
Counts' : (row.ProductCount le 8 ? 'Good
Product Counts' : 'Surplus Product
Counts')}">
<dvt:attributeMatchRule id="amr1" group="low">
<f:attribute name="color" value="#DD1E2F"/>
</dvt:attributeMatchRule>
<dvt:attributeMatchRule id="amr2" group="med">
<f:attribute name="color" value="#EBB035"/>
</dvt:attributeMatchRule>
<dvt:attributeMatchRule id="amr3" group="high">
<f:attribute name="color" value="#218559"/>
</dvt:attributeMatchRule>
</dvt:attributeGroups>
</dvt:area>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
<dvt:pointDataLayer id="dpl1"
value="#{bindings.SCustomerView1.collectionModel}"
var="row">
<dvt:pointLocation type="pointName" pointName="#{row.State}_
#{fn:toUpperCase(fn:replace(row.City, ' ', '_'))}"
id="pl1">
<dvt:marker id="m2" fillColor="#00000" opacity="1.0" shape="human"
scaleX="4.0" scaleY="4.0"
shortDesc="#{row.Name}">
<f:attribute name="legendLabel" value="Customer Location"/>
</dvt:marker>
</dvt:pointLocation>
</dvt:pointDataLayer>
<dvt:pointDataLayer id="dpl2"
value="#{bindings.SWarehouseView1.collectionModel}"
var="row">
<dvt:pointLocation type="pointXY" pointX="#{row.Longitude}"
pointY="#{row.Latitude}" id="pl2">
<af:image id="img1" source="/images/normalHouse.gif"
shortDesc="#{row.Address}, #{row.City} #{row.ZipCode}">
<f:attribute name="legendLabel" value="Warehouse Location"/>
</af:image>
</dvt:pointLocation>
</dvt:pointDataLayer>
<dvt:legend id="l1">
<dvt:showLegendGroup id="slg1" label="Customer and Warehouse Locations">
<dvt:legendSection source="dpl1:m2" id="ls2"/>
<dvt:legendSection source="dpl2:img1" id="ls1"/>
</dvt:showLegendGroup>
<dvt:showLegendGroup id="slg2" label="Warehouse Product Levels">
<dvt:legendSection source="al1:dal1:ag1" id="ls3"/>
</dvt:showLegendGroup>
</dvt:legend>
</dvt:thematicMap>

データ・バインドされたテーマ・マップの作成を完了すると、ベース・マップの地理階層で使用可能なリージョンを表す別のマップ・レイヤーを追加したり、テーマ・マップの作成に使用したものと同じデータ・コレクションを使用して面データ・レイヤーや点データ・レイヤーを関連付けできます。レイヤー・ブラウザでは、マップ・レイヤー、面データ・レイヤーと点データ・レイヤー、スタイル設定されたエリアとマーカーの論理的構造を表します。レイヤー・ブラウザを使用して次を実行します。

- ベース・マップの地理階層のその他のマップ・レイヤーをテーマ・マップに追加します。

- 下位レベルのリージョンを使用して、カスタム・レイヤーにリージョンを集約することにより、ベース・マップの地理階層でカスタム・マップ・レイヤーを定義します。詳細は、「カスタム・マップ・レイヤーの定義方法」を参照してください。

- (グローバルまたはマップ・レイヤー固有の)面データ・レイヤーや点のデータ・レイヤーを追加、編集または削除します。詳細は、「テーマ・マップにデータ・レイヤーを追加する方法」を参照してください。

- スタイル設定したエリアやマーカーを追加、編集または削除します。詳細は、「データを表示するためのエリア、マーカーおよびイメージのスタイル設定」を参照してください。

データ・コントロールを使用してテーマ・マップを作成すると、デフォルトのマップ・ラベルや凡例の表示をカスタマイズし、相互作用力やアニメーション効果を追加できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

41.3.3 テーマ・マップにデータ・レイヤーを追加する方法

データ・レイヤーを使用して、マップ・レイヤーをデータ・コレクションに関連付けます。スタンプを使用すれば、データ・モデル内の各データ行をスタイル(色またはパターンなど)、マーカー(円形または四角形など)、またはイメージにより識別できます。実行時にマップ・レイヤーが表示される場合は、データはスタイル設定されたエリア、マーカーまたはイメージとして表示されます。

41.3.3.1 マップ・レイヤーに面データ・レイヤーを追加する方法

マップ・レイヤーは、1つの面データ・レイヤーあるいは1つ以上の点データ・レイヤーを使用して、データを表示できます。面データ・レイヤーは、エリア、マーカーまたはイメージを使用してスタイル設定できます。点データ・レイヤーは、マーカーまたはイメージを使用してスタイル設定できます。

始める前に:

データバインドされたテーマ・マップについて理解しておいてください。詳細は、「データバインドされたテーマ・マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

- 「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」の説明に従い、データバインドされたテーマ・マップをJSFページに作成します。

面データ・レイヤーをマップ・レイヤーに追加する手順は次のとおりです。

1. ビジュアル・エディタでテーマ・マップを選択します。

2. レイヤー・ブラウザで、データ・コレクションの行をバインドするマップ・レイヤーを選択します。ビジュアル・エディタでレイヤー・ブラウザが表示されない場合は、マップの内部で右クリックして「レイヤー・ブラウザを開く」を選択します。

3. 「追加」アイコンのドロップダウン・リストから、「データ・レイヤーの追加」を選択します。

4. 「データ・レイヤーの作成」ダイアログで、次のように入力します。

- 「レイヤーID」: 定義するデータ・レイヤーの一意の名前を入力します。デフォルトでは、一意の連番のID、つまりdl1、dl2などになります。

- 「データを今すぐバインド」: このオプションを選択して「参照」をクリックし、「ピッカー」ダイアログ→データ・コントロールの定義ページを表示します。データ・レイヤーへのデータのバインドに使用するADFデータ・コントロールで、データ・コレクションを選択します。

注意:

または、「式ビルダー」ページを使用して、面データ・レイヤーと各エリアのデータ・バインドに使用しているADFマネージドBeanを選択します。残りの各フィールドに「式ビルダー」ダイアログを使用することもできます。

- 「面」: このオプションを選択して、面データ・レイヤーをマップ・レイヤーに追加します。

- 「エリア・レイヤー」: データ・レイヤーを追加するマップ・レイヤーを参照します。

- 「位置」: データ・レイヤーのエリアに対応するデータ位置を決定する、データ・モデルの列を表す属性を選択します。位置は、データが表示されるベース・マップのリージョンのIDです。詳細は、「基準となるマップの位置IDについて」を参照してください。

- 「マスター/ディテールの現在行の設定」: マスター/ディテール関係を有効化する場合に選択します。これは、テーマ・マップのデータ・コレクションが、ページ上の別のUIコンポーネントに表示されるディテール・ビューとのマスター/ディテール関係においてマスターである場合に便利です。詳細は、「マスター/ディテール関係の構成について」を参照してください。

図41-27に、設定済の面データ・レイヤーの作成ダイアログを示します。

図41-27 面データ・レイヤーの作成ダイアログ

デフォルトでは、areaDataLayerコンポーネントを表す面データ・レイヤーおよびareaコンポーネントを表すエリアが、レイヤー・ブラウザ階層に追加されます。次の例は、面データ・レイヤーをマップ・レイヤーに追加する際にJSFページに追加されるコードを示しています。

<dvt:thematicMap id="tm1" basemap="usa">
<dvt:areaLayer layer="counties" id="al1">
<dvt:areaDataLayer id="dl2"
value="#{bindings.TmapStatesView11.collectionModel}"
var="row">
<dvt:areaLocation name="#{row.Name}" id="al2">
<dvt:area id="a1"/>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
...
</dvt:thematicMap>

面データ・レイヤーをテーマ・マップに追加したら、エリア、マーカーまたはイメージを使用してデータをスタイル設定します。詳細は、「データを表示するためのエリア、マーカーおよびイメージのスタイル設定」を参照してください。

41.3.3.2 マップ・レイヤーに点データ・レイヤーを追加する方法

マップ・レイヤーは、1つの面データ・レイヤーあるいは1つ以上の点データ・レイヤーを使用して、データを表示できます。面データ・レイヤーは、エリア、マーカーまたはイメージを使用してスタイル設定できます。点データ・レイヤーは、マーカーまたはイメージを使用してスタイル設定できます。

点データ・レイヤーが、特定のマップ・レイヤーの子としてではなくthematicMapの直接の子としてベース・マップに関連付けられている場合は、データは常時表示され、グローバル・ポイント・レイヤーと呼ばれます。

始める前に:

データバインドされたテーマ・マップについて理解しておいてください。詳細は、「データバインドされたテーマ・マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

- 「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」の説明に従い、データバインドされたテーマ・マップをJSFページに作成します。

点データ・レイヤーをマップ・レイヤーに追加する手順は次のとおりです。

1. ビジュアル・エディタでテーマ・マップを選択します。

2. レイヤー・ブラウザで、データ・レイヤーをバインドするマップ・レイヤーを選択します。ビジュアル・エディタでレイヤー・ブラウザが表示されない場合は、マップの内部で右クリックして「レイヤー・ブラウザを開く」を選択します。

3. 「追加」アイコンのドロップダウン・リストから、「データ・レイヤーの追加」を選択します。

注意:

テーマ・マップに常時表示されるグローバル・ポイント・レイヤーを作成する場合は、「グローバル・ポイント・レイヤーの作成」を選択します。

4. 「データ・レイヤーの作成」ダイアログで、次のように入力します。

- 「レイヤーID」: 定義するデータ・レイヤーの一意のIDを入力します。デフォルトでは、一意の連番のID、つまりdl1、dl2などになります。

- 「データを今すぐバインド」: このオプションを選択して「参照」をクリックし、「ピッカー」ダイアログ→データ・コントロールの定義ページを表示します。データ・レイヤーへのデータのバインドに使用するADFデータ・コントロールで、データ・コレクションを選択します。

注意:

または、「式ビルダー」ページを使用して、点データ・レイヤーと各マーカーのデータ・バインドに使用するADFマネージドBeanを選択します。残りの各フィールドに「式ビルダー」ダイアログを使用することもできます。

- 「点」: このオプションを選択して、点データ・レイヤーをマップ・レイヤーに追加します。

- 「エリア・レイヤー」: ドロップダウン・リストを使用してデータ・レイヤーを関連付けるマップ・レイヤーを選択します。「すべて」を選択すると、点データ・レイヤーがグローバル・ポイント・レイヤーとして構成され、常時表示されるようになります。使用可能なマップ・レイヤーを選択した場合は、点データ・レイヤーはそのマップ・レイヤーが表示された場合のみ表示されます。

- 「データ・タイプ」: 次のいずれかを選択します。

- 「市区町村」: ベース・マップの名前付きポイントにマッピングされる、データ・コレクション内の名前付きポイント(市区町村など)を表すpointNameデータ型を使用するには、これを選択します。

- 「座標」: pointXとpointYを組み合せてポイントの位置を定義する、データ・コレクション内の列を表すpointXYデータ型を使用するには、これを選択します。

- 「位置」: 市区町村データ型が指定されている場合にのみ使用可能です。ドロップダウン・リストを使用して、データ・レイヤーのポイントに対応するデータの位置を決定する、データ・モデルの列を表す属性を選択します。位置は、データが表示されるベース・マップのポイントのIDです。詳細は、「基準となるマップの位置IDについて」を参照してください。

- 「経度」: 座標データ型が指定されている場合に使用可能です。ドロップダウン・リストを使用して、経度、つまりマーカーのpointXを表すデータ・コレクションの属性を選択します。

- 「緯度」: 座標データ型が指定されている場合に使用可能です。ドロップダウン・リストを使用して、緯度、つまりマーカーのpointYを表すデータ・コレクションの属性を選択します。

- 「マスター/ディテールの現在行の設定」: マスター/ディテール関係を有効化する場合に選択します。これは、テーマ・マップのデータ・コレクションが、ページ上の別のUIコンポーネントに表示されるディテール・ビューとのマスター/ディテール関係においてマスターである場合に便利です。詳細は、「マスター/ディテール関係の構成について」を参照してください。

図41-28に、データ型がpointNameの、設定済の点データ・レイヤーの作成ダイアログを示します。

図41-28 点データ・レイヤーの作成ダイアログ

デフォルトでは、pointDataLayerコンポーネントを表す点・データ・レイヤーおよびmarkerコンポーネントを表すマーカーが、レイヤー・ブラウザ階層に追加されます。次の例は、点データ・レイヤーをマップ・レイヤーに追加する際にJSFページに追加されるコードを示しています。

<dvt:thematicMap id="tm1" basemap="usa">
<dvt:areaLayer layer="states" id="al1">
<dvt:pointDataLayer id="dl1"
value="#{bindings.TmapCitiesView11.collectionModel}"
var="row">
<dvt:pointLocation type="pointName" pointName="#{row.City}" id="pl1">
<dvt:marker id="m2"/>
</dvt:pointLocation>
</dvt:pointDataLayer>
</dvt:areaLayer>
...
</dvt:thematicMap>

次の例は、グローバル・ポイント・データ・レイヤーをテーマ・マップに追加する際にJSFページに追加されるコードを示しています。

<dvt:thematicMap>
<areaLayer layer="states" id="al1"/>
<dvt:pointDataLayer id="dl2"
value="#{bindings.TmapCitiesView12.collectionModel}"
var="row">
<dvt:pointLocation type="pointXY" pointX="#{row.Longitude}"
pointY="#{row.Latitude}" id="pl2">
<dvt:marker id="m3"/>
</dvt:pointLocation>
</dvt:pointDataLayer>
...
</dvt:thematicMap>

点データ・レイヤーをテーマ・マップに追加したら、エリア、マーカーまたはイメージを使用してデータをスタイル設定します。詳細は、「データを表示するためのエリア、マーカーおよびイメージのスタイル設定」を参照してください。

41.3.4 データを表示するためのエリア、マーカーおよびイメージのスタイル設定

面データ・レイヤーを使用してマップ・レイヤーをデータ・コレクションに関連付けます。スタンプを使用すれば、データ・モデル内の各データ行をスタイル(色またはパターンなど)、マーカー(円形または四角形など)、またはイメージにより識別できます。

点データ・レイヤーを使用してマップ上のポイントのセットをデータ・コレクションに関連付けます。データ・ポイントは、マップ・レイヤー内の名前付きポイント(米国マップ内の都市など)、または経度と緯度により、指定できます。スタンプを使用すれば、データ・モデル内の各データ行をマーカー(円形や四角形など)またはイメージにより識別できます。

41.3.4.1 エリアをスタイル設定してデータを表示する方法

テーマ・マップareaLayer内のすべてのエリアについてデフォルトのスタンプを使用してエリアを構成することも、子attributeGroupsタグを使用して、データ・セット内のカテゴリ・グループに基づいてスタイル属性タイプを自動的に生成することもできます。areaタグとattributeGroupsタグの両方で、同じスタイル属性が設定されている場合は、attributeGroupsスタイル・タイプが優先されます。

デフォルトでは、面データ・レイヤーを追加すると、構成可能なエリアがレイヤー・ブラウザに追加されます。レイヤー・ブラウザを使用して、追加のエリアやマーカーを面データ・レイヤーに追加したり、マーカーを点データ・レイヤーに追加できます。レイヤー・ブラウザは、マップ・レイヤー、面データ・レイヤーと点データ・レイヤー、テーマ・マップに構成されたエリアやマーカーの論理的構造を反映します。

たとえば、倉庫のある州を赤色で表示するように(図41-29を参照)、usaベース・マップのstatesレイヤーに含まれる州を属性グループでスタイル設定できます。

図41-29 エリア・スタンプが構成されたテーマ・マップ

始める前に:

データバインドされたテーマ・マップについて理解しておいてください。詳細は、「データバインドされたテーマ・マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

- 「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」の説明に従い、データバインドされたテーマ・マップをJSFページに作成します。

デフォルトのスタンプを使用してエリアをスタイル設定する手順は次のとおりです。

1. レイヤー・ブラウザで、構成しているマップ・レイヤー内部のエリア位置にあるエリアを選択します。

2. 「編集」アイコンをクリックします。

3. 「エリアの構成」ダイアログの「デフォルト・スタンプ」ページで、次のように入力します。

- 「位置」: デフォルトでは、データ・レイヤーのエリアに対応するデータの位置を決定する、データ・モデルの列を表す属性です。位置は、データが表示されるベース・マップのリージョンのIDです。この読取り専用フィールドには、スタンプされたエリアをベース・マップのリージョンにマップするEL式が表示されます。詳細は、「基準となるマップの位置IDについて」を参照してください。

- 「色」: (オプション)ドロップダウン・リストからエリアの塗りつぶし色を選択します。有効な値は、RGB16進数です。ドロップダウン・リストから「カスタム・カラー」を選択し、「カラー・ピッカー」ダイアログを開きます。

- 「パターン」: (オプション)ドロップダウン・リストから12個の事前作成されたパターンのいずれかを選択し、エリアをスタイル設定します。たとえば、smallChecker、largeDiamond、smallDiagonalRight、largeCrosshatchなどがあります。塗りつぶし色が指定されている場合は、パターンはその色、背景色はデフォルトの白で表示されます。

- 「不透明度」: (オプション)エリアの塗りつぶし色の不透明度を指定します。有効値の範囲は、0.0(透明)から1.0(不透明)です。

- 「凡例に含める」: 検索アイコンを使用して「テキスト・リソースの選択」ダイアログを開き、凡例テキストに使用するアプリケーション・テキスト・リソースを選択または作成します。テキスト・リソースは、リソース・バンドルからの翻訳可能な文字列または実行時に実行されるEL式のいずれかにできます。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

注意:

テキスト・リソース・オプションは、固定エリアでのみ使用可能です。行数が変動するエリアでは、EL式を使用して行数変動キーを取得し、リソース・バンドルでテキスト・リソースを検索します。たとえば、次のようになります。

#{viewController.ResourceBundle[row.label]}

- 「メッセージ」: エリアの構成に関連付けられたアラートを必要に応じて確認したり消去します。

図41-30に、「エリアの構成」ダイアログの「デフォルト・スタンプ」ページを示します。

図41-30 「エリアの構成」ダイアログの「デフォルト・スタンプ」ページ

次の例は、構成したエリアのJSFページに挿入されるコードを示しています。

<dvt:thematicMap id="tm1" basemap="usa">
<dvt:areaLayer layer="states" id="al1">
<dvt:areaDataLayer id="dl1"
value="#{bindings.TmapStatesView1.collectionModel}"
var="row">
<dvt:areaLocation name="#{row.Name}" id="al2">
<dvt:area id="a1" fillColor="#ff0000">
<f:attribute name="legendLabel"
value="#{Bundle.US_STATES}"/>
</dvt:area>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
</dvt:thematicMap>

データ・コレクション内のデータのカテゴリ・グループを使用してエリアをスタイル設定する場合は、「エリアの構成」ダイアログの「属性グループ」ページを使用します。サンプル・コードを含めた「属性グループ」ページの使用方法の詳細は、「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」に記載のユースケースを参照してください。

41.3.4.2 デフォルト・スタンプを使用してデータを表示するためにマーカーをスタイル設定する方法

テーマ・マップ・レイヤー内のすべてのマーカーについてデフォルトのスタンプを使用してマーカーを構成することも、子attributeGroupsタグを使用して、データ・セット内のカテゴリ・グループに基づいてスタイル属性タイプを自動的に生成することもできます。markerタグとattributeGroupsタグの両方で、同じスタイル属性が設定されている場合は、attributeGroupsスタイル・タイプが優先されます。

デフォルトでは、点データ・レイヤーを追加すると、構成可能なマーカー要素がレイヤー・ブラウザに追加されます。レイヤー・ブラウザを使用して、追加のエリアやマーカーを面データ・レイヤーに追加したり、マーカーを点データ・レイヤーに追加できます。レイヤー・ブラウザは、マップ・レイヤー、面データ・レイヤーと点データ・レイヤー、テーマ・マップに構成されたエリアやマーカーの論理的構造を反映します。

たとえば、図41-31に示すように、デフォルトのスタンプを使用すると、米国のベース・マップの州レイヤーに事前定義されているすべての市区町村を、赤丸を付けることにより識別できます。この例では、マーカーは点データ・レイヤー上でスタイル設定されています。面データ・レイヤー上でのマーカーのスタイル設定も同様です。

図41-31 デフォルト・スタンプで構成したマーカーを含むテーマ・マップ

始める前に:

データバインドされたテーマ・マップについて理解しておいてください。詳細は、「データバインドされたテーマ・マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

- 「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」の説明に従い、データバインドされたテーマ・マップをJSFページに作成します。

デフォルトのスタンプを使用してマーカーをスタイル設定する手順は次のとおりです。

1. レイヤー・ブラウザで、構成しているマップ・レイヤー内部のポイント位置にあるマーカーを選択します。

2. 「編集」アイコンをクリックします。

3. 「マーカーの構成」ダイアログの「デフォルト・スタンプ」ページで、次のように入力します。

- 「位置」: デフォルトでは、データ・レイヤーのマーカーに対応するデータの位置を決定する、データ・モデルの列を表す属性です。位置は、データが表示されるベース・マップのポイントのIDです。この読取り専用フィールドには、スタンプされたマーカーをベース・マップのポイントにマップするEL式が表示されます。詳細は、「基準となるマップの位置IDについて」を参照してください。

- 「色」: (オプション)ドロップダウン・リストからマーカーの塗りつぶし色を選択します。有効な値は、RGB16進数です。ドロップダウン・リストから「カスタム・カラー」を選択し、「カラー・ピッカー」ダイアログを開きます。

- 「パターン」: (オプション)ドロップダウン・リストから12個の事前作成されたパターンのいずれかを選択し、マーカーをスタイル設定します。たとえば、smallChecker、largeDiamond、smallDiagonalRight、largeCrosshatchなどがあります。塗りつぶし色が指定されている場合は、パターンはその色、背景色はデフォルトの白で表示されます。

- 「不透明度」: (オプション)マーカーの塗りつぶし色の不透明度を指定します。有効値の範囲は、0.0(透明)から1.0(不透明)です。

- 「図形」: (オプション)マーカーの形状を選択します。有効な値は、円(デフォルト)、四角、正符号、ひし形、上向き三角形、下向き三角形および人型です。
オプションで、「カスタム形状」フィールドを使用して、マーカーに使用するためにScalable Vector Graphics (SVG)ファイルに対してshapePath値を指定します。パスを入力するか、「検索」アイコンを使用して「SVGファイルの選択」ダイアログを開き、ファイルの場所にナビゲートします。このオプションは、「図形」フィールドでデフォルトの図形が選択されている場合にのみ使用できます。

形状は、CSSスタイル・プロパティを使用して指定することもできます。事前定義のマーカーの形状は上書きでき、カスタム・マーカー用のSVGファイルのパスは、shapePath属性を使用せずに定義できます。詳細は、「マーカーのスタイル設定について」を参照してください。

- 「サイズ」: (オプション)マーカーをデフォルトのサイズから拡大縮小するためのパーセンテージを、「スケールX」(水平方向)および「スケールY」(垂直方向)に入力します。パーセンテージが浮動小数に変換されます。たとえば、マーカーの幅を2倍にするには、「スケールX」を200に設定します。すると、タグに2.0と書き込まれます。また、高さを半分にするには、「スケールY」を50に設定します。すると、タグに0.5と書き込まれます。

- 「凡例に含める」: 凡例ラベルに使用するテキスト・リソースを入力します。テキスト・リソースは、リソース・バンドルからの翻訳可能な文字列または実行時に実行されるEL式のいずれかにできます。ドロップダウン・リストを使用して、「テキスト・リソースの選択」または「式ビルダー」ダイアログを選択します。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

注意:

テキスト・リソース・オプションは、固定エリアでのみ使用可能です。行数が変動するエリアでは、EL式を使用して行数変動キーを取得し、リソース・バンドルでテキスト・リソースを検索します。たとえば、次のようになります。

#{viewController.ResourceBundle[row.label]}

- 「メッセージ」: マーカーの構成に関連付けられたメッセージを確認したり消去します。

図41-32に、「マーカーの構成」ダイアログの「デフォルト・スタンプ」ページを示します。

図41-32 「マーカーの構成」ダイアログの「デフォルト・スタンプ」ページ

次の例は、構成したマーカーのJSFページに挿入されるコードを示しています。

<dvt:thematicMap id="tm1" basemap="usa">
<dvt:areaLayer layer="states" id="al1">
<dvt:pointDataLayer id="dl2"
value="#{bindings.TmapCitiesView1.collectionModel}"
var="row">
<<dvt:pointLocation type="pointName" pointName="#{row.City}" id="pl1">
<dvt:marker id="m2" fillColor="#ff0000">
<f:attribute name="legendLabel"
value="#{Bundle.US_CITIES}"/>
</dvt:marker>
</dvt:pointLocation>
</dvt:pointDataLayer>
</dvt:areaLayer>
</dvt:thematicMap>

41.3.4.3 カテゴリ・グループを使用してデータを表示するためにマーカーをスタイル設定する方法

テーマ・マップ・レイヤー内のすべてのマーカーについてデフォルトのスタンプを使用してマーカーを構成することも、子attributeGroupsタグを使用して、データ・セット内のカテゴリ・グループに基づいてスタイル属性タイプを自動的に生成することもできます。markerタグとattributeGroupsタグの両方で、同じスタイル属性が設定されている場合は、attributeGroupsスタイル・タイプが優先されます。

データ・コレクション内のデータのカテゴリ・グループを使用してマーカーをスタイル設定する場合は、「マーカーの構成」ダイアログの「属性グループ」ページを使用します。マーカーは、点データ・レイヤーまたは面データ・レイヤーに対して構成できます。

始める前に:

データバインドされたテーマ・マップについて理解しておいてください。詳細は、「データバインドされたテーマ・マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

- 「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」の説明に従い、データバインドされたテーマ・マップをJSFページに作成します。

データのカテゴリ・グループを使用してマーカーをスタイル設定する手順は次のとおりです。

1. レイヤー・ブラウザで、構成しているマップ・レイヤー内部のマーカー位置にあるマーカーを選択します。

2. 「編集」アイコンをクリックします。

3. 「マーカーの構成」ダイアログの「属性グループ」ページで、次のように入力します。

- 「グループ化ルール」: この表を使用して、データ・コレクション内のデータのカテゴリ・グループのスタイルを指定します。「追加」アイコンを使用して、カテゴリ・グループのルールを構成する表に行を追加し、「削除」アイコンを使用して選択した行を表から削除します。各グループ化ルールはattributeGroupsコンポーネントとして表され、一意の連番ID (ag1、ag2など)が割り当てられます。
表に追加された行ごとに、次のように入力します。

- 「値でグループ化」: データ値のグループ化に使用するデータ・セットの列を表す属性を入力するか、ドロップダウン・リストを使用して選択します。

注意:

選択した属性は、カテゴリ化できる離散値で構成される必要があります。たとえば、40から45までの数値範囲は自動的にはグループ化されません。

- 「マーカー・プロパティ」: 該当のマーカーのスタイル設定に使用するプロパティをドロップダウン・リストを使用して選択します。マーカーは、色、パターン、不透明度、スケールX、スケールYまたはこれら有効値の任意の組合せを使用してスタイル設定できます。ダイアログのドロップダウン・リストから「複数の属性の選択」を選択し、値の組合せを指定します。
各プロパティに生成されるデフォルトのスタイル値は、ADFスキンのCSSスタイル・プロパティを使用して定義されます。各attributeGroupsタイプには、スキンで定義されたデフォルトのランプがあり、索引ベースのプロパティを目的の値に設定することによりカスタマイズできます。詳細は、「属性グループのデフォルトのスタイル値について」を参照してください。

- 「凡例ラベル」: テキストを入力するか、テーマ・マップの凡例のカテゴリ・グループに使用するテキストを表す属性をドロップダウン・リストを使用して選択します。ドロップダウン・リストから「式ビルダー」を選択し、EL式を作成して凡例テキストを指定することもできます。詳細は、「データバインドされた凡例の作成」を参照してください。

- 値固有のルール: クリックして、データ・セットのカテゴリ・グループに1つ以上のデータ値の詳細を指定する際に使用する「一致ルール」表および「例外ルール」表を開きます。

注意:

これらの表で指定された一致ルールや例外ルールは、「グループ化ルール」表で定義された設定に優先します。

- 「一致ルール」: このオプションを使用して、データ・コレクション内のデータ・グループの1つ以上のデータ値に一致するスタイル・ルールを指定します。「追加」アイコンを使用して、カテゴリ・グループの一致ルールを構成する表に行を追加し、「削除」アイコンを使用して選択した行を表から削除します。各一致ルールはattributeMatchRuleコンポーネントとして表され、一意の連番ID (amr1、amr2など)が割り当てられます。プロパティとプロパティ値は、子f:attributeタグで定義されます。次に例を示します。

<dvt:attributeMatchRule id="amrl" group="Mountain Dew">
<f:attribute name="color" value="#ffff00"/>
</dvt:attributeMatchRule>

表に追加された行ごとに、次のように入力します。

- 「グループ値」: この一致ルールの実行をトリガーする「値でグループ化」属性の値を入力します。

- 「プロパティ」: 該当のデータ値のスタイル設定に使用するプロパティをドロップダウン・リストを使用して選択します。マーカーは、色、パターン、不透明度、スケールX、スケールYまたはこれら有効値の任意の組合せを使用してスタイル設定できます。ここで選択したプロパティは、「グループ化ルール」属性の「マーカー・プロパティ」に表示されるプロパティ・タイプのいずれかに一致する必要があります。

- 「プロパティ値」: 入力するかドロップダウン・リストを使用して、値をプロパティに割り当てます。一致オーバーライドにより指定された値が、グループ化ルールによって返された事前作成のランプ内にもある場合、その値はオーバーライドでのみ使用され、事前作成のランプではスキップされます。
色の有効な値は、RGB16進数色です。

パターンの有効値として、12個の事前作成されたパターン(smallChecker、largeDiamond、smallDiagonalRight、largeCrosshatchなど)から選択することもできます。塗りつぶし色が指定されている場合は、パターンはその色、背景色はデフォルトの白で表示されます。

不透明度の有効な値範囲は、0.0(透明)から1.0(不透明)です。

スケールXおよびスケールYの有効値はパーセンテージで、これはその後浮動小数に変換されます。

- 「例外ルール」: データ・セットのカテゴリ・グループのスタイル・ルールについて1つ以上の例外を指定します。「追加」アイコンを使用して、例外ルールを構成する表に行追加し、「削除」アイコンを使用して任意の行を表から削除します。各例外ルールはattributeExceptionRuleコンポーネントとして表され、一意の連番ID (aer1、aer2など)が割り当てられます。プロパティとプロパティ値は、子f:attributeタグで定義されます。次に例を示します。

<dvt:attributeExceptionRule id="aer1" condition="#{row.name=='TX'}"
label="Texas">
<f:attribute name="color" value="#ff00ff"/>
</dvt:attributeExceptionRule>

表に追加された行ごとに、次のように入力します。

- 「条件」: EL式を入力するか、ドロップダウン・リストを使用して「式ビルダー」ダイアログを開き、EL式を作成します。この式は、特定の条件を満たす場合にスタイル・プロパティ値を別の値に置き換えます。次に例を示します。

#{row.Sales gt 100000}

- 「プロパティ」: 該当のデータ値のスタイル設定に使用するプロパティをドロップダウン・リストを使用して選択します。マーカーは、色、パターン、不透明度、スケールXまたはスケールYを使用してスタイル設定できます。ここで選択したプロパティは、「グループ化ルール」属性の「マーカー・プロパティ」に表示されるプロパティ・タイプのいずれかに一致する必要があります。

- 「プロパティ値」: 入力するかドロップダウン・リストを使用して、値をプロパティに割り当てます。一致オーバーライドにより指定された値が、グループ化ルールによって返された事前作成のランプ内にもある場合、その値はオーバーライドでのみ使用され、事前作成のランプではスキップされます。
色の有効な値は、RGB16進数色です。

パターンの有効値として、12個の事前作成されたパターン(smallChecker、largeDiamond、smallDiagonalRight、largeCrosshatchなど)から選択することもできます。塗りつぶし色が指定されている場合は、パターンはその色、背景色はデフォルトの白で表示されます。

不透明度の有効な値範囲は、0.0(透明)から1.0(不透明)です。

スケールXおよびスケールYの有効値はパーセンテージで、これはその後浮動小数に変換されます。

- 「凡例ラベル」: 凡例ラベルに使用するテキスト・リソースを入力します。テキスト・リソースは、リソース・バンドルからの翻訳可能な文字列または実行時に実行されるEL式のいずれかにできます。ドロップダウン・リストを使用して、「テキスト・リソースの選択」または「式ビルダー」ダイアログを選択します。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

注意:

テキスト・リソース・オプションは、固定エリアでのみ使用可能です。行数が変動するエリアでは、EL式を使用して行数変動キーを取得し、リソース・バンドルでテキスト・リソースを検索します。たとえば、次のようになります。

#{viewController.ResourceBundle[row.label]}

- 「メッセージ」: マーカーの構成に関連付けられたアラートを必要に応じて確認したり消去します。

たとえば、図41-33に示すように、面データ・レイヤーでマーカーを使用してデータのカテゴリ・グループを色で表示できます。

図41-33 色別のマーカー属性グループ

次の例は、色別のマーカー属性グループのサンプル・コードを示しています。

<dvt:thematicMap basemap="usa" id="tm1"
<dvt:areaLayer layer="states" id="al1" labelDisplay="off">
<dvt:areaDataLayer id="dl1" var="row" value="#{stateData.colorModel}">
<dvt:areaLocation id="al2" name="#{row.name}">
<dvt:marker id="m1"
scaleX="3.0"
scaleY="3.0"
shape="circle">
<dvt:attributeGroups id="ag1" type="color" value="#{row.category}"
label="#{row.category}"/>
</dvt:marker>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
<dvt:legend id="l1">
<f:facet name="separator"/>
<dvt:legendSection id="ls1" label="Category" source="ag1"/>
</dvt:legend>
</dvt:thematicMap>

マーカーに色、形状などの複数の属性を指定してデータのカテゴリ・グループを表示することもできます。また、特定の条件を満たした場合にグループ化ルールに例外を表示できます。図41-34に、色と形状を使用してカテゴリ・グループを表示したテーマ・マップ(例外のTexas州を含む)を示します。

図41-34 例外ルールが設定された複数のマーカー属性グループ

次の例は、例外ルールが設定された複数のマーカー属性グループのサンプル・コードを示しています。

<dvt:thematicMap basemap="usa" id="tm2"
<dvt:areaLayer layer="states" id="al1" labelDisplay="off">
<dvt:areaDataLayer id="dl1" var="row" value="#{stateData.colorModel}">
<dvt:areaLocation id="al2" name="#{row.name}">
<dvt:marker id="m1"
scaleX="3.0"
scaleY="3.0"
shape="circle">
<dvt:attributeGroups id="ag1" type="shape color" value="#{row.category}"
label="#{row.category}">
<dvt:attributeExceptionRule id="aer1" condition="#{row.name=='TX'}"
label="Texas">
<f:attribute name="color" value="#ff00ff"/>
</dvt:exceptionRule>
</dvt:attributeGroups>
</dvt:marker>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
<dvt:legend id="l1">
<f:facet name="separator"/>
<dvt:legendSection id="ls1" label="Category" source="ag1"/>
</dvt:legend>
</dvt:thematicMap>

41.3.4.4 マーカーのスタイル設定について

テーマ・マップでは、事前定義された7つの形状セット(circle、squareなど)をサポートしており、これらはmarkerコンポーネントのshape属性を使用して指定できます。カスタム・マーカーの場合、shapePath属性を使用してSVGファイルのパスを指定すると、事前定義の形状のかわりに表示されます。

スケーラブル・ベクター・グラフィック(SVG)が、テーマ・マップのマーカーのカスタム形状作成のためのファイル形式としてサポートされています。

カスタム形状によってサポートされていないSVG機能には次のものがあります。

- SVGファイル内のイメージ・タグ。SVGのベクター形状を使用して、すべてを宣言する必要があります。

- パターンによる塗りつぶし

- ストロークのグラデーション

マーカーの形状は、ADFスキン内のCSSスタイル・プロパティを使用して指定することもできます。テーマ・マップ・スタイルのプロパティを使用すれば、事前定義のマーカーの形状は上書きでき、カスタム・マーカーのSVGファイルのパスは、shapePath属性を使用せずに定義できます。スタイル・プロパティを使用する場合、事前定義とカスタムの両方の形状の定義にmarkerコンポーネントのshape属性が使用されます。

その形状の汎用またはコンポーネント固有のスタイル・プロパティがADFスキンで指定されている場合、事前定義の形状は上書きされます。たとえば、テーマ・マップ・コンポーネントのスタイル・プロパティで次のようにnewCircle.svgファイルを指定することにより、事前定義のcircle形状を上書きできます。

af|dvt-thematicMap::shape-circle{
-tr-path: url(/resources/path/newCircle.svg);
}

JSFページでは、markerコンポーネントのshape属性は次のように設定されます。

<dvt:marker id="m1" shape="circle"/>

markerコンポーネントのshape属性でカスタム形状を指定するには、形状スタイル・プロパティ名でcustomの接頭辞を使用する必要があります。たとえば、カスタム形状がcustomNameという名前の場合、ADFスキン・ファイルで汎用の.AFDVTShapeCustomName:aliasスタイル・プロパティか、次のようにSVGファイルを指す-tr-pathプロパティを指定したテーマ・マップ固有のaf|dvt-thematicMap::shape-customNameのいずれかを定義する必要があります。

af|dvt-thematicMap::shape-customName{
-tr-path: url(/resource/path/newCShape.svg);
}

JSFページでは、マーカー・コンポーネントの形状属性は次のように設定されます。

<dvt:marker id="m1" shape="customName"/>

ADFスキンおよびスタイル・プロパティの使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

41.3.4.5 属性グループのデフォルトのスタイル値について

attributeGroupsコンポーネントは、データ・コレクション内のデータのカテゴリ・グループに基づいて色または形状などのスタイル・プロパティ値を生成するために使用します。データ・モデルでグループ化の基準となる列を表す属性に基づき、attributeGroupsコンポーネントにより、データ内の一意の値またはグループごとにスタイル値を生成できます。

値を生成するスタイル・プロパティのタイプは、attributeGroupsコンポーネントのtype属性で指定します。areaコンポーネントに対してサポートされているタイプは、color、patternおよびopacityです。markerコンポーネントに対してサポートされているタイプは、color、shape、pattern、opacity、scaleXおよびscaleYです。これらのタイプは、一意のデータ値ごとに複数のスタイル・プロパティを生成するために、スペース区切りのリストにまとめることができます。

生成されるデフォルトのスタイル値は、ADFスキンのCSSスタイル・プロパティを使用して定義されます。各attributeGroupsタイプには、ADFスキンで定義されたデフォルトのランプがあり、索引ベースのセレクタを目的の値に設定することによりカスタマイズできます。次の例は、CSSスタイル・プロパティを使用するサンプル・コードを示しています。そのコードでは、CSSスタイル・プロパティを使用して属性グループを指定します。

af|dvt-attributeGroups::shape1{
-tr-shape: square;
}
af|dvt-attributeGroups::shape2{
-tr-shape: square;
}
...
af|dvt-attributeGroups::color1{
-tr-fill-color: #003366;
}

属性グループ・タイプごとのデフォルトのランプを表41-2に示します。

表41-2 テーマ・マップ属性グループのデフォルトのランプ

タイプ

デフォルトのランプ

color

j#003366 (青)、#CC3300 (赤)、#666699 (ラベンダー)、#0006666 (エメラルド)、#FF9900 (橙黄)、#993366 (紫)、#99CC33 (黄緑色)、#624390 (青紫)、#669933 (緑)、#FFCC33 (黄)、#006699 (青緑色)、#EBEA79 (淡黄色)

shape

square、circle、diamond、plus、triangleDown、triangleUpおよびhuman

pattern

smallDiagonalLeft、smallDiagonalRight、smallTriangle、smallChecker、smallChecker、smallCrosshatch、smallDiamond、largeDiagonalLeft、largeDiagonalRight、largeTriangle、largeChecker、largeCrosshatch、largeDiamond

opacity

0.25、0.50、0.75、1.0

scaleXおよびscaleY

1.0、2.0、3.0、4.0、5.0

ADFスキンおよびスタイル・プロパティの使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

41.3.4.6 イメージを使用したデータの表示方法

組込みまたはカスタム形状を使用してテーマ・マップにデータをスタイル設定するかわりに、イメージを使用してデータを表現できます。イメージは、面データ・レイヤーまたは点データ・レイヤーのどちらかに関連付けることができます。

たとえば、図41-35に示すように、面データ・レイヤーで家屋のイメージを使用して、米国ベース・マップの州マップ・レイヤー上で主要な不動産の位置を識別できます。

図41-35 イメージでデータをスタイル設定したテーマ・マップ

始める前に:

データバインドされたテーマ・マップについて理解しておいてください。詳細は、「データバインドされたテーマ・マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

- 「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」の説明に従い、データバインドされたテーマ・マップをJSFページに作成します。

イメージを使用してデータを表示する手順は次のとおりです。

1. レイヤー・ブラウザで、イメージを構成してデータを表示する面データ・レイヤーまたは点データ・レイヤーを選択します。

2. 「構造」ウィンドウで、面または点データ・レイヤーの子であるareaLocationまたはpointLocationコンポーネントを右クリックし、「dvt:areaLocationの中に挿入」または「dvt:pointLocationの中に挿入」→「イメージ」を選択します。

3. 「イメージの挿入」ダイアログで、次のように入力します。

- 「ソース」: イメージ・ソースの場所を指定するURIを入力します。ドロップダウン・メニューを使用して「編集」を選択し、「プロパティの編集: ソース」ダイアログまたは式ビルダーを開き、イメージ・ソースの場所を指定できます。

- 「短い説明」: スクリーン・リーダーのユーザー用のaltテキストとして使用される、イメージの短い説明を入力します。

次の例は、イメージを使用して図41-35に示したテーマ・マップのデータを表示するコード・サンプルを示しています。

<dvt:thematicMap id="thematicMap" imageFormat="flash" basemap="usa"
summary="Thematic map showing the important real estate markets">
<dvt:legend label="Legend">
<dvt:legendSection source="areaLayer:dataLayer:img1"/>
</dvt:legend>
<dvt:areaLayer id="areaLayer" layer="states">
<dvt:areaDataLayer id="dataLayer" contentDelivery="immediate"
value="#{tmapBean.colorModel}"
var="row"varStatus="rowStatus">
<dvt:areaLocation id="dataLoc" name="#{row.name}">
<af:image id="img1" source="/resources/images/geoMap/mansion.gif"
rendered="#{row.category == 'category1'}"
shortDesc="House image">
<f:attribute name="legendLabel" value="Prime location"/>
</af:image>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
</dvt:thematicMap>

41.3.4.7 マーカー・イメージ・ソースを使用してデータを表示する方法

イメージ・ファイルを使用してデータを表示するようにマーカーを構成できます。個別のイメージを指定して、テーマ・マップ上でユーザーの選択とホバーの状態を表示できます。dvt:markerコンポーネントを使用している場合は、イメージの回転もサポートされます。たとえば、図41-36のテーマ・マップは、航空機のフライトの位置と航路を表し、航路に沿って移動するときにイメージを回転します。

図41-36 テーマ・マップ・フライト・トラッカ

始める前に:

データバインドされたテーマ・マップについて理解しておいてください。詳細は、「データバインドされたテーマ・マップの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

- 「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」の説明に従い、データバインドされたテーマ・マップをJSFページに作成します。

マーカー・イメージ・ソースを使用してデータを表示する手順:

1. レイヤー・ブラウザで、イメージを構成してデータを表示する面データ・レイヤーまたは点データ・レイヤーを選択します。

2. 「構造」ウィンドウで、面または点データ・レイヤーの子であるareaLocationまたはpointLocationコンポーネントを右クリックし、「エリアの場所の中に挿入または「点の位置の中に挿入」→「マーカー」を選択します。

3. 「構造」ウィンドウで「dvt:marker」コンポーネントを右クリックし、「プロパティに移動」を選択します。

4. 「プロパティ」ウィンドウで、「外観」セクションを開いて次の属性を設定します。

- 「ソース」: イメージ・ソースの場所を指定するURIを入力します。ドロップダウン・メニューを使用して「編集」を選択し、「プロパティの編集: ソース」ダイアログまたは式ビルダーを開き、イメージ・リソースの場所を指定できます。

- SourceHover: オプションで、カーソルが置かれているイメージ・リソースの場所を指定するURIを入力します。

- SourceHoverSelected: オプションで、カーソルが置かれている選択されたイメージ・リソースの場所を指定するURIを入力します。

- SourceSelected: オプションで、選択されているイメージ・リソースの場所を指定するURIを入力します。

- 「短い説明」: スクリーン・リーダーのユーザー用のaltテキストとして使用される、イメージの短い説明を入力します。

5. オプションで、「その他」セクションを展開し、「回転」属性を使用してイメージの中心の時計回りでのマーカーの回転を指定します。

次の例は、図41-36のテーマ・マップ・フライト・トラッカのコード・サンプルを示しています。

<dvt:thematicMap id="thematicMap" basemap="world" animationOnDisplay="none"
tooltipDisplay="auto"
summary="flight tracker demo">
<dvt:areaLayer id="al1" layer="countries">
<dvt:pointDataLayer id="pdl1" contentDelivery="immediate"
value="#{flightTrackerBean.flights}"
selectionListener="#{flightTrackerBean.processSelection}"
var="row"
varStatus="rowStatus"
selectionMode="multiple" partialTriggers="::::sbcb1"
selectedRowKeys="#{flightTrackerBean.selectedKeys}">
<dvt:pointLocation id="pl1" type="pointXY" pointX="#{row.currentLongLat.x}"
pointY="#{row.currentLongLat.y}">
<dvt:marker id="m1" labelPosition="bottom" scaleX="3" scaleY="3"
rotation="#{row.rotation}"
shortDesc="OracleAir#{row.flightNumber}"#{row.flightNumber}"
sourceHover="/resources/images/thematicMap/planeHover.png"
source="/resources/images/thematicMap/plane.png"
sourceSelected="/resources/images/thematicMap/planeSel.png"
sourceHoverSelected="/resources/images/thematicMap/
planeHoverSel.png"
labelDisplay="#{flightTrackerBean.showFlightNo ? 'on' : 'off'}"
value="Flight #{row.flightNumber}"/>
</dvt:pointLocation>
</dvt:pointDataLayer>
</dvt:areaLayer>
</dvt:thematicMap>

41.3.5 基準となるマップの位置IDについて

テーマ・マップ・コンポーネント用に用意されている基準となる各マップには、一連のリージョンを表す事前に作成された複数のマップ・レイヤーがあります。たとえば、基準となるworldマップには、continents用のマップ・レイヤーとcountries用の別のレイヤーが含まれています。下位レベルのマップ・レイヤーのリージョンは、集約されて地理的階層内の次のレベルを構成します。マップ・レイヤーは、areaLayerコンポーネントのlayer属性で指定されます。

データ・コレクションをテーマ・マップにバインドする際、データが表示される基準となるマップからリージョンのマップ位置IDを使用してエリアまたはポイント・データの位置を指定する列を、データ・モデルに指定する必要があります。エリアの位置はareaLocationコンポーネントのname属性で指定され、ポイントの位置は、type属性がpointNameに設定されている場合、pointLocationコンポーネントのpointName属性で指定されます。

米国の基準となるマップでは、位置IDは次のネーミング・ルールによって決まります。

- countryレイヤー: USA

- statesレイヤー: 2文字の郵便用の略号を使用します。たとえば、Massachusettsの位置IDはMAで、Texasの位置IDはTXです。

- countiesレイヤー: statesレイヤー位置IDの後に、アンダースコア、郡の名前を続けます。すべて大文字にし、英字以外の文字はアンダースコアに置き換えます。たとえば、MassachusettsのMiddlesex郡の位置IDはMA_MIDDLESEXで、TexasのRed River郡の位置IDはTX_RED_RIVERです。

- citiesレイヤー: statesレイヤー位置IDの後に、アンダースコア、都市名を続けます。すべて大文字にし、英字以外の文字はアンダースコアに置き換えます。たとえば、MassachusettsのBostonの位置IDはMA_BOSTONで、TexasのSan Antonio位置IDはTX_SAN_ANTONIOです。

他の基準となるマップでは、位置IDは次のネーミング・ルールによって決まります。

- continentsレイヤー: world、africa、asia、australia、europe、northAmericaおよびsouthAmericaの基準となるマップでは、AF(アフリカ)、AS(アジア)、AU(オーストラリア)、EU(ヨーロッパ)、NA(北米)およびSA(南米)となります。

- worldRegionsレイヤー: worldRegions、apac、emea、latinAmericaおよびusaAndCanadaの基準となるマップでは、APAC(アジア太平洋)、EMEA(ヨーロッパおよび中近東)、LAT(中南米)、NA(米国およびカナダ)となります。

- countriesレイヤー: ISO 3166-1 alpha-3国名コードを使用します。たとえば、カナダの位置IDはCANで、中国の位置IDはCHNです。

- citiesレイヤー: 3文字のcountries位置IDの後に、アンダースコア、都市名を続けます。すべて大文字にし、英字以外の文字はアンダースコアに置き換えます。たとえば、カナダのTorontoの位置IDはCAN_TORONTO、米国のLos Angelesの位置IDはUSA_LOS_ANGELESです。

事前作成されたマップ・レイヤーごとに、すべてのテーマ・マップの基準となるマップの位置IDを記載したカンマ区切りの値(CSV)ファイルをダウンロードできます。これらのリンクは、areaLocationコンポーネントのname属性のタグ・ドキュメントで検索します。データ視覚化コンポーネントのタグ・ドキュメントにアクセスするには、構造ウィンドウで該当のコンポーネントを選択し、「プロパティ」でヘルプ・ボタンをクリックします。

41.3.6 マスター/ディテール関係の構成について

テーマ・マップを構成し、表などの、ページ上の別のUIコンポーネントにその関連するデータを表示できます。この構成では、テーマ・マップのデータ・コレクションが、別のUIコンポーネントに表示されるディテール・ビューとのマスター/ディテール関係でのマスターとなります。図41-37に、州ごとの失業率を表示するテーマ・マップを示します。ユーザーは、1つ以上の州を選択してデータのディテール・ビューを表に表示できます。

図41-37 テーマ・マップのマスター/ディテール表のビュー

このマスター/ディテール処理を宣言的に実現するには、次の要件を満たす必要があります。

- 次のように、同じデータ・コレクションを使用して両方のビューにデータを提供する必要があります。

- テーマ・マップareaDataLayerまたはpointDataLayerをデータ・コレクションにバインドします。その属性は、テーマ・マップ・レイヤーでエリアまたはマーカーによってスタイル設定されるデータを表します。

- その他のADFコンポーネント(表など)を同じデータ・コレクションにバインドします。

- 「データ・レイヤーの作成」ダイアログで現在の行をマスター/ディテールに設定を選択し、テーマ・マップareaLayerコンポーネントのselectionListener属性に値を自動的に設定し、すでにテーマ・マップ・バインディングの一部であるprocessSelectionメソッドを使用します。
たとえば、テーマ・マップの面データ・レイヤー・コンポーネントのvalue属性がvalue="#{stateData.employmentData}"である場合は、selectionListener属性は次のように設定されます。

selectionListener="#{stateData.employmentData.processSelection}".

- areaDataLayerまたはpointDataLayerコンポーネントのselectionMode属性が、テーマ・マップの要件に応じてsingleまたはmultipleに設定されていることを確認します。

41.3.7 カスタム・マップ・レイヤーの定義方法

カスタム・マップ・レイヤーを固有のリージョン・データから定義し、テーマ・マップの自然の地理階層に挿入できます。カスタム・レイヤーは、事前定義のマップ・レイヤーを開き、下位レベルのリージョンを集約することで作成され、カスタム・レイヤー内に新規のリージョンが形成されます。定義したカスタム・マップ・レイヤーは、他のマップ・レイヤーと同じように使用されます。

たとえば、図41-38に示すように、米国リージョンのカスタム・マップ・レイヤーに米国北東部、中西部、西部および南部という地理的なリージョンを定義できます。この図では、米国リージョンのカスタム・レイヤーは米国のベース・マップの州レイヤーから拡張されています。レイヤー内の新しいエリアは、州レイヤーの州から集約されます。米国南部リージョンのラベルには、そのリージョンにある州が一覧で表示されます。米国中西部のリージョンは、下位レベルの郡リージョンの売上げカテゴリを表示するまでドリルダウンされています。ドリルの詳細は、「テーマ・マップでドリルを構成する方法」を参照してください。

図41-38 米国リージョンのカスタム・マップ・レイヤー

customAreaLayerコンポーネントは、モデルを使用して、基になるリストのデータにアクセスします。固有のモデル・クラスはoracle.adf.view.rich.model.CollectionModelです。java.util.List、java.util.Arrayおよびjavax.faces.model.DataModelなど、その他のモデル・インスタンスも使用できます。customAreaLayerは、インスタンスをCollectionModelに自動的に変換します。

始める前に:

テーマ・マップの属性やテーマ・マップの子タグが機能にどのような影響を与えるかについて理解しておくと役立ちます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のテーマ・マップの構成に関する項を参照してください。

拡張対象の事前定義のベース・マップで集約したエリアを定義するADFデータ・コントロールまたはADFマネージドBeanは、すでに用意されています。

ページにすでにテーマ・マップが存在している必要があります。ない場合は、この章の指示に従ってテーマ・マップを作成します。詳細は、「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」を参照してください。

カスタム・マップ・レイヤーを追加および構成する手順は次のとおりです。

1. ビジュアル・エディタでテーマ・マップを選択します。

2. レイヤー・ブラウザの「追加」アイコンのドロップダウン・リストでカスタム・レイヤーの追加を選択しします。ビジュアル・エディタでレイヤー・ブラウザが表示されない場合は、マップ内で右クリックして「レイヤー・ブラウザを開く」を選択します。

3. 「カスタム・レイヤーの作成」ダイアログで、次のように入力します。

- 「データを今すぐバインド」: このオプションを選択して「参照」をクリックし、「ピッカー」ダイアログ→データ・コントロールの定義ページを表示します。カスタム・レイヤーやエリアのデータバインドに使用するADFデータ・コントロールで、データ・コレクションを選択します。

注意:

または、「式ビルダー」ページを使用して、カスタム・レイヤーと各エリアのデータ・バインドに使用するADFマネージドBeanを選択します。残りの各フィールドに「式ビルダー」ダイアログを使用することもできます。

- 「レイヤーID」: customAreaLayerコンポーネントの一意のIDを入力します。たとえば、米国を集約リージョン(北西部、中西部、西部、南部)に分割する場合は、対応するID (NE、MW、WおよびS)を使用してこれらのリージョンを定義できます。

- 「拡張」: 検索アイコンを使用して、カスタム・レイヤーにエリアを集約する際に使用できる組込みマップ・レイヤーを表示します。カスタム・レイヤーによって拡張されるマップ・レイヤーを選択します。

- 「エリア・リスト」: ドロップダウン・リストを使用して、カスタム・マップ・レイヤーでのエリアの集約に使用する下位レベルのマップ・リージョンのリストを表すデータ・コレクション属性を選択します。値のカンマ区切りリストでは、「拡張」属性に定義されているマップ・レイヤーのリージョンを集約します。

- 「エリアID」: ドロップダウン・リストを使用して、カスタム・マップ・レイヤーでのエリアの集約に使用する下位レベルのマップ・リージョンの一意のIDを表すデータ・コレクション属性を選択します。デフォルトでは、一意のID (ca1、ca2など)は、customAreaコンポーネントで使用されます。

- 「エリア・ラベル」: ドロップダウン・リストを使用して、カスタム・マップ・レイヤーでのエリアの集約に使用する下位レベルのマップ・リージョンの名前を表すデータ・コレクション属性を選択します。実行時に、集約したリージョンのカンマ区切りリストがラベルに表示されます。

図41-39に、設定済の「カスタム・レイヤーの作成」ダイアログを示します。

図41-39 「カスタム・レイヤーの作成」ダイアログ

図41-40に、カスタム・レイヤー定義後のレイヤー・ブラウザを示します。レイヤー構造では、カスタム・レイヤーcal1は、マップ・レイヤーal1で参照されます。ここで、面データ・レイヤーまたは点データ・レイヤーを追加してデータを表示します。詳細は、「テーマ・マップにデータ・レイヤーを追加する方法」を参照してください。

図41-40 レイヤー・ブラウザでのカスタム・マップ・レイヤー

次の例は、JSFページに挿入されるコードを示しています

<dvt:thematicMap>
...
<dvt:areaLayer layer="states" id="al1"/>
<dvt:areaLayer layer="cal1" id="al3"/>
<dvt:customAreaLayer id="cal1"
value="#{bindings.TmapStatesView.collectionModel}"
var="row"
extendsLayer="states">
<dvt:customArea areaId="#{row.RowID}" areaList="#{row.RowID}"
label="#{row.RowID}" id="ca1"/>
</dvt:customAreaLayer>
...
</dvt:thematicMap>

カスタム・レイヤーを構成してマップ・レイヤー階層に追加すると、他のマップ・レイヤーと同様の方法でそのマップ・レイヤーを使用できるようになります。たとえば、図41-38に示すようにテーマ・マップを作成するには、次を実行する必要があります。

- テーマ・マップでドリルをサポートするように構成します。詳細は、「テーマ・マップでドリルを構成する方法」を参照してください。

注意:

テーマ・マップでドリルが有効な場合は、カスタム・レイヤーとカスタム・レイヤーの集約に使用するマップ・レイヤー間のドリルが可能です。その際、どちらのレイヤーもデータ表示を構成する必要はありません。

- 郡データ・ビューに面データ・レイヤーを追加し、構成します。詳細は、「テーマ・マップにデータ・レイヤーを追加する方法」を参照してください。

- エリア・コンポーネントを追加してスタイル設定し、各マップ・レイヤーの関連するデータを表示します。詳細は、「データを表示するためのエリア、マーカーおよびイメージのスタイル設定」を参照してください。

- テーマ・マップの凡例を構成します。詳細は、「データバインドされた凡例の作成」を参照してください。

次の例は、テーマ・マップでカスタム・レイヤーを使用するためのサンプル・コードを示しています。

<dvt:thematicMap id="thematicMap" imageFormat="flash" basemap="usa" drilling="on"
maintainDrill="true"
controlPanelBehavior="initExpanded" summary="US Custom Regions">
<dvt:customAreaLayer id="crl1" value="#{tmapRegions.collectionModel}" var="row"
varStatus="rowStatus"
extendsLayer="states">
<dvt:customArea areaId="#{row.name}" label="#{row.name}"
areaList="#{row.regions}" id="ca1"/>
</dvt:customAreaLayer>
<dvt:areaLayer id="custom" layer="crl1">
<dvt:areaDataLayer contentDelivery="immediate"
value="#{tmapRegions.collectionModel}"
selectionMode="single"
var="row" varStatus="rowStatus" id="adl1">
<dvt:areaLocation name="#{row.name}" id="al1">
<dvt:area fillColor="#{row.color}" shortDesc="#{row.regions}"
id="a1" value="#{row.name}"/>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
<dvt:areaLayer id="areaLayerS" layer="states"
<dvt:areaDataLayer id="dataLayerS" selectionMode="multiple"
contentDelivery="immediate"
value="#{tmapStates.collectionModel}" var="row"
varStatus="rowStatus">
<dvt:areaLocation id="areaLocS" name="#{row.name}">
<dvt:area id="area1S" fillColor="#{row.color}"></dvt:area>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
<dvt:areaLayer id="areaLayer" layer="counties">
<dvt:areaDataLayer id="dataLayer" selectionMode="single"
contentDelivery="immediate"
value="#{tmapCounty.collectionModel}" var="row"
varStatus="rowStatus">
<dvt:areaLocation id="areaLoc" name="#{row.name}">
<dvt:area id="area1" fillColor="#{row.color}"
value="#{row.category}"></dvt:area>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
<dvt:legend label="Sales Regions" id="l1">
<dvt:legendSection source="custom:adl1:a1" id="ls1"/>
<dvt:legendSection label="Counties" source="areaLayer:dataLayer:areaLoc"
id="ls3"/>
</dvt:legend>
</dvt:thematicMap>

41.3.8 テーマ・マップでドリルを構成する方法

各種マップ・レイヤーの関連するデータ・ビューを備えたテーマ・マップは、上位と下位のデータ・ビュー間でドリルを実行するように構成できます。たとえば、図41-38に示すように、テーマ・マップでは、米国の州別の売上げカテゴリのデータを郡別にドリルダウンして表示できます。州や郡を選択した場合は、ポップアップ・メニューの選択やコントロール・パネルの設定により、ドリルアップやドリルダウンが開始されます。

テーマ・マップ・エリアのドリルを宣言的に実現するには、次の要件を満たす必要があります。

- ドリル階層の各マップ・レイヤー(areaLayer)について、その子であるareaDataLayerを該当するマップ・レイヤーの関連データを定義するデータ・コントロールにバインドする必要があります。

- マップ・レイヤー・ドリル階層の各areaDataLayerのselectionMode属性は、singleまたはmultipleに設定されている必要があります。

- 下位レベルのマップ・レイヤー・ドリル階層のareaを構成し、上位レベルのマップ・レイヤーのareaコンポーネントと同じデフォルトのスタンプやカテゴリ属性のスタイルを使用してデータを表示する必要があります。

- thematicMapコンポーネントのdrilling属性はonに設定する必要があります。

注意:

テーマ・マップでドリルが有効な場合は、カスタム・レイヤーとカスタム・レイヤーの集約に使用するマップ・レイヤー間のドリルが可能です。

始める前に:

テーマ・マップの属性やテーマ・マップの子タグが機能にどのような影響を与えるかについて理解しておくと役立ちます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のテーマ・マップの構成に関する項を参照してください。

ページにすでにテーマ・マップが存在している必要があります。ない場合は、この章の指示に従ってテーマ・マップを作成します。詳細は、「ADFデータ・コントロールを使用してテーマ・マップを作成する方法」を参照してください。

ドリル階層の各データ・レイヤーのデータ・モデルを定義するデータ・コントロールはすでに用意されています。

テーマ・マップ・エリアを構成してドリルを可能にする手順は次のとおりです。

1. 構造ウィンドウで、dvt:thematicMapコンポーネントを選択します。

2. 「プロパティ」ウィンドウで、「動作」セクションを開きます。このセクションを使用して、次の属性を設定します。

- Drilling: テーマ・マップ・レイヤー間でデータ・ビューのドリルを有効にするために使用します。ドロップダウン・リストから「オン」を選択して、ドリルを有効にします。デフォルト値は「オフ」です。

- MaintainDrill: (オプション)新しいエリアをドリルするときに、以前にドリルしたエリアのドリル状態を維持するために、オプションのtrue値を指定するために使用します。デフォルト値は「false」です。

- DrillBehavior: (オプション)ドリル対象のエリアでオプションのzoomToFit効果を指定するために使用します。デフォルト値は指定なしです。

3. レイヤー・ブラウザで、希望のドリル階層にある各「エリア・レイヤー」コンポーネントを選択し、次を実行します。

- 「追加」アイコンをクリックし、「データ・レイヤーの追加」を選択して「データ・レイヤーの作成」ダイアログを開きます。ダイアログを設定して面データ・レイヤーを追加し、このデータ・レイヤーを該当のマップ・レイヤーのデータ・コントロールにバインドします。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

注意:

面データ・レイヤーがすでに存在する場合は、「編集」アイコンをクリックしてデータ・コントロールへのバインディングを確定します。

- 「プロパティ」ウィンドウで、「動作」セクションを展開し、SelectionMode属性をsingleまたはmultipleに設定します。

4. レイヤー・ブラウザで、希望のドリル階層にある各「面データ・レイヤー」コンポーネントを選択し、次を実行します。

- 「追加」アイコンをクリックし、「エリアの追加」を選択して「エリアの構成」ダイアログを開きます。ダイアログを設定してデフォルトのスタンプを定義するか、属性グループを使用して該当のマップ・レイヤーのエリアをスタイル設定します。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

注意:

エリアがすでに存在する場合は、「編集」アイコンをクリックしてエリアのスタイル設定を確定します。

図41-40に、売上げカテゴリのデータを表示するようにスタイル設定されたエリアを持つ米国の州と郡のマップ・レイヤーに対し、ドリルを有効化したサンプル・コードを示します。

<dvt:thematicMap id="thematicMap"
basemap="usa"
drilling="on"
maintainDrill="true"
drillBehavior="zoomToFit"
animationOnDisplay="none"
<dvt:areaLayer id="al1" layer="states">
<dvt:areaDataLayer id="adl1"
selectionMode="single"
contentDeliver="immediate"
value="#{row.state}"
var="row"
var="rowStatus">
<dvt:areaLocation id="areaLocS" name="#{row.stname}">
<dvt:area id="a1" fillColor="#{row.state}"/>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
<dvt:areaLayer id="al2" layer="counties">
<dvt:areaDataLayer id="adl2"
selectionMode="single"
contentDelivery="immediate"
value="#{row.county}"
var="row"
varStatus="rowStatus">
<dvt:areaLocation id="areaLocC" name="#{row.coname}">
<dvt:area id="a2" fillColor="#{row.county}"/>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
...
</dvt:thematicMap>

41.3.9 データバインドされた凡例の作成

凡例には、シンボルとラベルのペア表記による、テーマ・マップのスタイル設定されたデータに関する説明表が付いています。テーマ・マップの凡例コンポーネント(legend)では、色、形状、カスタム形状、塗りつぶしパターン、不透明度、イメージおよびサイズのシンボルをサポートしています。1つ以上の子凡例アイテム・コンポーネント(legendSection)のソースは、テーマ・マップに表示するデータをスタイル設定するためにスタンプされる、テーマ・マップのarea、marker、attributeGroupsまたはaf:imageコンポーネントです。凡例セクションの構造では、コンテンツの順序付けと外観に対する制御をサポートしています。showLegendSectionコンポーネントを使用して、凡例アイテムを公開可能なセクションにまとめることができます。図41-41に、マップのエリアおよびマーカーの公開可能なセクションを設定した凡例を示します。

図41-41 公開可能なセクションとマーカーを設定した凡例

attributeGroupsコンポーネントからの凡例アイテムにより、エリアまたはマーカーの属性タイプを異なるセクションに自動的に分割できます。セパレータ・ファセットを指定して、凡例セクション間にセパレータを描画できます。図41-42に、色、形状、塗りつぶしパターン、不透明度およびサイズに関する属性グループを使用し、各セクション間にセパレータを描画した凡例を示します。

図41-42 属性グループを使用した凡例

凡例は、Flash(デフォルト)およびPNGイメージ形式のどちらでも表示できます。どちらの形式も、右から左に表示するロケールをサポートしています。PNG形式にレンダリングすると、たとえば、テーマ・マップを印刷する場合に凡例の公開可能なセクションはサポートされず、凡例アイテムが公開として表示されます。

「データ・コントロール」パネルとテーマ・マップ・バインディング・ダイアログを使用してテーマ・マップを作成すると、凡例のデータ・バインディングが作成されます。テーマ・マップのすべてのエリアについて、1つのエリアまたはマーカーをデフォルトのスタンプとして構成した場合は、静的テキスト・リソースを凡例の固定エリアまたはマーカーに割り当てることができます。

行数が変動するデータを表示するデフォルトのスタンプに対し、EL式を使用して凡例テキストおよびマネージドBean(オプション)を割り当て、行数変動キーを取得してリソース・バンドルでテキスト・リソースを検索できます。次の例は、エリアとマーカーのスタンプの凡例エントリを生成するコード・サンプルを示しています。このコードは、行数が変動するエリアおよびテキスト・リソースが割り当てられた固定マーカーの公開可能なセクションを示しています。

<dvt:thematicMap id="tm1" basemap="usa" ...>
<dvt:legend label=“Legend“>
<dvt:showLegendGroupLabel label="Voting Majority">
<dvt:legendSection id="ls1" source="al1:adl1:areaStamp“/>
</dvt:showLegendGroupLabel>
<dvt:legendSection id="ls2" source="al1:adl1:fixedMarker">
</dvt:legend>
<dvt:areaLayer id="al1" layer="states">
<dvt:areaDataLayer id="adl1"...>
<dvt:areaLocation id="aloc1" ,,,>
<dvt:area id="areaStamp">
fillColor="#{row.value > 50 ? tmapLegendBean,color1 :
tmapLegendBean.color2}"
<f:attribute name="legendLabel" value="#{row.value > 50 ?
'Candidate 2' : 'Candidate 1'}" />
<dvt:marker id=“fixedMarker“ shape=“human" fillColor=“"#FF9900"
scaleX="3" scaleY="3">
<f:attribute name="legendLabel“
value="#{Bundle.Office_Locations}"/>
</dvt:marker>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:area>
</dvt:thematicMap>

エリアまたはマーカーを構成し、属性グループを使用してデータ・コレクション内のデータのカテゴリ・グループのスタイルを指定する場合は、EL式を使用して凡例テキストおよびマネージドBean(オプション)を割り当て、行数変動キーを取得してリソース・バンドルでテキスト・リソースを検索できます。

属性グループに一致ルールを指定した場合は、凡例テキストはgroup属性で指定されます。例外ルールを指定する場合は、アプリケーション・リソース・バンドルからのテキスト・リソースを指定できます。次の例は、一致ルールと例外ルールの両方が組み込まれ、凡例セクション間にセパレータを指定した属性グループを使用する凡例のサンプル・コードを示しています。

<dvt:thematicMap id="tm1" basemap="usa" ...>
<dvt:legend id="l1" label="Legend">
<f:facet name="separator"
<af:separator/>
<dvt:legendSection id="ls1" source="al1:adl1:attributeGroupColor" />
<dvt:legendSection id="ls2" source="al1:adl1:attributeGroupShape" />
<dvt:legendSection id="ls3" source="al1:adl1:attributeGroupPattern" />
<dvt:legendSection id="ls4" source="al1:adl1:attributeGroupOpacity" />>
</dvt:legend>
<dvt:areaLayer id="al1" layer="states">
<dvt:areaDataLayer id="adl1" value=" " var=" " ...>
<dvt:areaLocation id="dataLoc" name="#{row.name}">
<dvt:marker id="m1"... >
<dvt:attributeGroups id="attributeGroupColor" type="color"
label="#{row.category1}" value="#{row.category1}" />
<dvt:attributeMatchRule id="amrl" group="Mountain Dew">
<f:attribute name="color" value="#ffff00"/>
</dvt:attributeMatchRule>
<dvt:attributeGroups id="attributeGroupShape" type="shape"
label="#{row.category2}" value="#{row.category2}" />
<dvt:attributeExceptionRule id="aer1" condition="#{row.name=='TX'}"
label="#{viewcontroller.Texas}">
<f:attribute name="shape" value="human"/>
</dvt:exceptionRule>
<dvt:attributeGroups id="attributeGroupShape" type="pattern"
label="#{row.category3}" ... />
<dvt:attributeGroups id="attributeGroupShape" type="opacity"
label="#{row.category4}" ... />
</dvt:marker>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
</dvt:thematicMap>

テーマ・マップの凡例エリアまたはマーカーを、他のマップ・レイヤーと同様の方法でカスタム・リージョンで構成します。カスタム・マップ・レイヤーの凡例のサンプル・コードを示します。

<dvt:thematicMap>
<dvt:legend>
<dvt:legendSection label=“Sales Regions" source="customAreaStamp"/>
</dvt:legend>
...
<dvt:customAreaLayer id="crl1“>
...
</dvt:customAreaLayer>
<dvt:areaLayer layer="crl1">
<dvt:areaDataLayer var="row">
<dvt:areaLocation name="#{row.name}" id="al1">
<dvt:area id=“customAreaStamp" fillColor="#{row.color}“>
<f:attribute name="legendLabel“ value=“#{row.name}"/>
</dvt:area>
</dvt:areaLocation>
</dvt:areaDataLayer>
</dvt:areaLayer>
</dvt:thematicMap

ADFスキンを使用して、テーマ・マップの凡例の外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください

42 データバインドされたガント・チャート・コンポーネントおよび時系列コンポーネントの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータからガント・チャートおよび時系列を作成する方法について説明します。これらの作成には、Fusion WebアプリケーションのADFデータ・コントロールとADF Facesコンポーネントを使用します。具体的には、ADFデータ視覚化コンポーネントのprojectGantt、resourceUtilizationGantt、schedulingGanttおよびtimelineを使用して、ビジネス・データを視覚的に表現するガント・チャートと時系列を作成する方法について説明します。ここでは、ADFデータ・コントロールを使用して、これらのコンポーネントをデータ優先開発で作成する方法について説明します。

簡単なUI優先開発を使用してページを設計する場合は、ガント・チャートや時系列をページに追加してから、データ・バインディングを構成してください。ガント・チャートおよび時系列コンポーネントのデータ要件、タグ構造、および外観と動作をカスタマイズするためのオプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ガント・チャート・コンポーネントの使用方法」と「時系列コンポーネントの使用」を参照してください。

この章の内容は次のとおりです。

- ADFデータ視覚化コンポーネントについて

- データバインドされたガント・チャートの作成

- データバインドされた時系列の作成

42.1 ADFデータ視覚化コンポーネントについて

ADFデータ視覚化コンポーネントは、ビジネス・データを視覚的に表示、分析するための幅広いグラフィック機能と表機能を提供します。コンポーネントの外観は表示するデータに応じて決まるため、コンポーネントをレンダリングするには、各コンポーネントをデータにバインドしておく必要があります。

ADFガント・チャートには、3種類のコンポーネントがあります。プロジェクト・ガント・チャートはプロジェクト管理に使用し、スケジュール・ガント・チャートはリソースのスケジュールに使用し、リソース使用率ガント・チャートはリソースのメトリックを表示するために使用します。すべてのガント・チャートは、2つのリージョンを表示します。これらのリージョンは、1つの分割線で結合されています。リスト・リージョンには、タスクまたはリソースのリストが表示され、チャート・リージョンには、経時的なグラフでタスク進行状況、リソース使用率またはリソース進行状況が表示されます。

対話型のデータ視覚化ツールであるADF時系列を使用すると、ユーザーはイベントを時間順に表示して、定義された時間範囲内で時間を進めたり戻したりできます。各イベントは時系列アイテムとして表され、単純なADFコンポーネントを使用してテキストやイメージなどの情報を表示したり、リンクなどのアクションを提供したりします。2つの時系列を構成して2系列のイベントを表示し、関連する情報を並べて比較することもできます。

接頭辞dvt:は、各データ視覚化コンポーネント名の先頭に付いて、そのコンポーネントがADFデータ視覚化ツール(DVT)のタグ・ライブラリに属することを示します。

42.1.1 データ視覚化コンポーネントのユースケースと例

データ視覚化コンポーネントのユースケースと例の詳細は、次を参照してください。

- ガント・チャート・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のガント・チャート・コンポーネントのユースケースおよび例に関する項。

- 時系列コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の時系列のユースケースと例に関する項。

42.1.2 エンド・ユーザー機能およびプレゼンテーション機能

魅力的な外観を備えたデータ視覚化コンポーネントを使用すると、エンド・ユーザーは複雑なビジネス・データを理解して分析できるようになります。このコンポーネントは機能が豊富で、そのまますぐに使用できる対話型のサポートも用意されています。エンド・ユーザーの詳細な説明と各コンポーネントのプレゼンテーション機能の詳細は、次を参照してください。

- ガント・チャート・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のエンド・ユーザー機能およびプレゼンテーション機能に関する項。

- 時系列コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のエンド・ユーザー機能およびプレゼンテーション機能に関する項。

42.1.3 データ視覚化コンポーネントの追加機能

データ視覚化コンポーネントをデータ・バインドする前に、その他のOracle ADF機能について理解しておいてください。また、いったんデータ視覚化コンポーネントをページに追加すると、検証やアクセシビリティなどの機能を追加する必要があることに気付く場合があります。データ視覚化コンポーネントで使用されるその他の機能へのリンクは、次のとおりです。

- 部分ページ・レンダリング: データ視覚化コンポーネントをリフレッシュして、ページの別のコンポーネントで実行されたアクションに基づく新しいデータを表示できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

- パーソナライズ: ユーザーは実行時にデータ視覚化コンポーネントの表示を変更できますが、ユーザーがカスタマイズできるようにアプリケーションを構成していないかぎり、ユーザーがページを終了するとそれらの値は保持されません。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「JSFページでのユーザー・カスタマイズの許可」を参照してください。

- アクセシビリティ: データ視覚化コンポーネントは、デフォルトでアクセス可能です。アプリケーションの各ページは、スクリーン・リーダーでのアクセスが可能になるように作成できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「アクセス可能なADF Facesページの開発」を参照してください。

- スキンおよびスタイル: アプリケーションに適用するADFスキンを使用するか、スタイル関連のプロパティ(styleClassまたはinlineStyle)を使用してCSSスタイル・プロパティを直接適用することで、データ視覚化コンポーネントの外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

- プレースホルダ・データ・コントロール: 最終的にページのデータ視覚化コンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールの使用を検討します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

42.2 データバインドされたガント・チャートの作成

ガント・チャートは、横軸上に表示される棒グラフの1種です。このグラフは、プロジェクトの計画および追跡において、開始と終了が明確な時間枠内でタスクまたはリソースを示すために使用されます。

ガント・チャートを作成する場合は、次のタイプから選択できます。

- プロジェクト
プロジェクト・ガント・チャートは、タスクを垂直に示し、各タスクの期間を水平な時間軸上に棒として示します。

- リソース使用率
リソース使用率ガント・チャートは、リソースの割当てが超過なのか未満なのかを図示します。リソースを縦に示し、横方向の時間軸にその割当てとキャパシティ(オプション)を示します。

- スケジューリング
このガント・チャートは手動のスケジュール表をベースにし、リソースを縦に表示し、対応するアクティビティを横方向の時間軸に表示します。リソースの例には、人、機械、部屋などがあります。

42.2.1 データバインドされたプロジェクト・ガント・チャートの作成方法

プロジェクト・ガント・チャートでは、タスクの値を指定する必要があります。オプションで、分割タスク、サブタスク、再帰タスクおよびタスク間の依存性の値も指定できます(データ・コレクションにこの追加情報に対するアクセッサがある場合)。

プロジェクト・ガント・チャートは、全体的な開始時間および終了時間と、主および副時間軸の値に対するデフォルト値を使用して表示されます。プロジェクト・ガント・チャートでは、主時間軸はデフォルトで週に設定され、副時間軸は日に設定されます。

図42-1は、各タスクが入力される1つの注文となっているプロジェクト・ガント・チャートを示しています。分割線の左側のリスト・リージョンには、注文の担当者の名前を示す列と、注文日および出荷日を示す列が表示されます。分割線の右側のグラフ・リージョンでは、各注文の注文日から出荷日までの水平な棒がガント・チャートで表示されています。

図42-1 出荷された注文のプロジェクト・ガント・チャート

データ・コントロールを使用してプロジェクト・ガント・チャートを作成するには、プロジェクト・ガント・チャート・コンポーネントをデータ・コレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

ヒント:

また、「コンポーネント」ウィンドウからプロジェクト・ガント・チャート・コンポーネントをドラッグし、「プロジェクト・ガントの作成」ダイアログの入力を完了することで、プロジェクト・ガント・チャートを作成することもできます。この方法では、コンポーネントをデータにバインドする前に、ガント・チャートのユーザー・インタフェースを設計できます。

始める前に:

データバインドされたガント・チャートについて理解しておいてください。詳細は、「データバインドされたガント・チャートの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
たとえば、図42-1のプロジェクト・ガント・チャートのデータソースは、ADF DVTコンポーネントについてのSummitサンプル・アプリケーションに含まれる、出荷日と配達日を含む出荷注文を表すビュー・オブジェクトから取得しています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

「データ・コントロール」パネルを使用して、プロジェクト・ガント・チャートを作成するには:

1. 「データ・コントロール」パネルから、データ・コレクションを選択します。行セット・コレクションを選択するか(タスクのフラット・リストを生成)、基本的なツリー・コレクションを選択します(タスクの階層リストを生成)。

図42-2は、「データ・コントロール」パネルでOrderEmployee1コレクションを選択して、注文の出荷の進行状況を表示するプロジェクト・ガント・チャートを作成する例を示しています。

図42-2 注文の出荷のデータ・コレクション

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「ガント」→「プロジェクト」を選択します。

3. 「プロジェクト・ガントの作成」ダイアログの「タスク」ページで、次の属性に対応するデータ・コレクション内の列を選択します。

- タスクID: ガント・チャート内のタスクを表す一意のID。

- 開始時間: タスクの開始時刻。

- 終了時間: タスクの終了時刻。

- タスク・タイプ: ガント・チャートにタスク・バーをレンダリングするときに、そのタスク・バーの外観を指定するために使用するタイプ。タイプをデータ・コレクション内の列にバインドしない場合、すべてのタスクはデフォルトでNormalになります。タスクのタイプには次のものがあります。

- Normal: 基本のタスク・タイプ。プレーンな横棒で、タスクの開始時刻、終了時刻および期間を示します。

- Summary: タスク(通常は、サブタスク)のグループの開始時刻と終了時刻を示します。サマリー・タスクは移動や伸長できません。ただし、いずれかのサブタスクの日付が変更された場合は、アプリケーションでサマリー・タスクの時間を再計算する必要があります。

- Milestone: ガント・チャート内の特定の日付を示します。マイルストン・タスクに関連付けられる日付は1つのみです。マイルストン・タスクは伸長できませんが、移動できます。

4. 「詳細の表示」をクリックして、指定したタスク・タイプごとに、次の属性に対応するデータ・コレクション内の追加の列を選択します。

- 「実際の開始」および「実際の終了」: これらの属性を指定すると、1つの棒グラフではなく2つの棒グラフが描画されます。1つの棒グラフはベース開始日およびベース終了日を示し、もう1つの棒グラフは実際の開始日および終了日を示します。これは標準タスク・タイプおよびマイルストン・タスク・タイプに適用されます。

- %完了: これを指定すると、棒の内側にタスクの完了割合を示す追加の棒が描画されます。

- 完了: 割合のかわりに、日付を指定できるようになります。これを指定すると、棒の内側に、属性が参照する日付に基づいた完了割合を示す追加の棒が描画されます。

- クリティカル: 棒を赤色に変更して、その棒が重要であることを示します。これは標準タスク・タイプ、サマリー・タスク・タイプおよびマイルストン・タスク・タイプに適用されます。

- 編集可能: タスクの開始日、終了日または期間がチャート・リージョン内でサポートされるかどうかを指定するブール値。

- コンテナ: ノード定義がコンテナであるかどうかを指定するブール値。

5. データ・コレクションにサブタスクに対するアクセッサが含まれている場合は、「サブタスク」ページを使用して、ドロップダウン・リストから「サブタスク・アクセサ」を選択し、次の属性に対応するデータ・コレクション内の列を選択します。

- サブタスクID: データ・コレクション内のサブタスクのリストに対する一意のID。

- 開始時間: サブタスクの開始時刻。

- 終了時間: サブタスクの終了時刻。

- サブタスク・タイプ: ガント・チャートにサブタスク・バーをレンダリングするときに、そのタスク・バーの外観を指定するために使用するタイプ。タイプをデータ・コレクション内の列にバインドしない場合、すべてのタスクはデフォルトでNormalになります。タスクのタイプには次のものがあります。

- Normal: 基本のタスク・タイプ。プレーンな横棒で、タスクの開始時刻、終了時刻および期間を示します。

- Summary: タスク(通常は、サブタスク)のグループの開始時刻と終了時刻を示します。サマリー・タスクは移動や伸長できません。ただし、いずれかのサブタスクの日付が変更された場合は、アプリケーションでサマリー・タスクの時間を再計算する必要があります。

- Milestone: ガント・チャート内の特定の日付を示します。マイルストン・タスクに関連付けられる日付は1つのみです。マイルストン・タスクは伸長できませんが、移動できます。

サブタスクをバインドしないと、ガント・チャートはタスクの階層ビューをレンダリングできません。サブタスクをバインドすると、ガント・チャートの階層ビューでタスクからサブタスクに向けてドリルダウンできるようになります。

6. データ・コレクションに依存タスクに対するアクセッサが含まれている場合は、「依存タスク」ページを使用して、ドロップダウン・リストから「依存タスク・アクセッサ」を選択し、次の属性に対応するデータ・コレクション内の列を選択します。

- 依存性のタイプ: 依存性のタイプを指定します。有効な値は、start-start、start-finish、finish-finish、finish-start、start-before、start-together、finish-afterおよびfinish-togetherです。

- 元タスクID: 依存関係内で最初のタスクを指定します。

- 先タスクID: 依存関係内で最後のタスクを指定します。

7. データ・コレクションに分割タスクに対するアクセッサが含まれている場合は、「分割タスク」ページを使用して、ドロップダウン・リストから「分割タスク・アクセッサ」を選択し、次の属性に対応するデータ・コレクション内の列を選択します。

- 分割タスクID: 2つの横棒(通常は、線でリンクされる)に分割されたタスクの一意のID。棒の間の時間は、移動時間または停止時間によるアイドル時間を表します。

- 開始時間: 分割タスクの開始時刻。

- 終了時間: 分割タスクの終了時刻。

8. データ・コレクションに再帰タスクに対するアクセッサが含まれている場合は、「再帰タスク」ページを使用して、ドロップダウン・リストから「再帰タスク・アクセッサ」を選択してから、次の属性に対応するデータ・コレクション内の列を選択します。

- 再帰タスクID: ガント・チャートで繰り返されるタスクの一意のID。タスクの各インスタンスには、固有の開始日と終了日が含まれます。個々の再帰タスクにはオプションでサブタイプを含めることができます。個々の再帰タスクのその他すべてのプロパティには、そのタスクが一部となっているタスクのプロパティが使用されます。ただし、個々の再帰タスクにサブタイプがある場合は、このサブタイプがタスク・タイプをオーバーライドします。

- タイプ: 再帰タスクのタイプを指定します。

- 開始時間: 再帰タスクの開始時刻。

- 終了時間: 再帰タスクの終了時刻。

9. 「外観」ページで、タスク・バーの「ラベル」に対応する属性と、タスク・バーに関連付けるアイコンを3個まで指定します。

10. 「表の列」セクションで、ガント・チャートのリスト・リージョン内に各行を表示する列を選択します。「新規」アイコンを使用すると、新しい行を追加できます。行を削除するには、「削除」アイコンを使用します。また、矢印アイコンを使用すると、ガント・チャート・リストに表示する列の行の順序を並べ替えできます。

注意:

「表の列」セクションで指定する最初の行により、リスト・リージョンのnodestamp列を指定します。サブタスク・アクセッサを指定すると、この行は、階層関係の開閉可能な親として使用されます。

各行で、次を指定します。

- ラベルの表示: ガント・チャート・リストの列のヘッダーの値を選択します。<default>を選択すると、ヘッダーのテキストはデータ・バインディングから自動的に取得されます。

- 値バインディング: ガント・チャート・リストの列に使用するデータ・コレクション内の列を選択します。選択できる値は、タスク・グループの場合と同じです。

- 使用するコンポーネント: ガント・チャート・リストのセルに表示するコンポーネントのタイプを選択します。ADF入力コンポーネントを使用すると、セルが編集可能になるように指定できます。デフォルトは、ADF出力テキスト・コンポーネントです。

11. 「OK」をクリックします。

図42-3に、注文の出荷のデータ・コレクションから、図42-1のプロジェクト・ガント・チャートを作成する際に使用されるダイアログを示します。

図42-3 出荷された注文を示す「プロジェクト・ガントの作成」ダイアログ

12. 「構造」ウィンドウでdvt:projectGanttコンポーネントを右クリックし、「プロパティに移動」を選択します。

13. 「プロパティ」ウィンドウで、「共通」セクションを開き、StartTime属性とEndTime属性の日付(yyyy-mm-dd)を指定します。これらの属性は、ガント・チャート・データの期間の開始日と終了日を表します。

指定した日付に応じて、実行時にプロジェクト・ガント・チャートに表示される初期ビューが決定されます。

14. ガント・チャートに凡例を含めるには、「構造」ウィンドウでプロジェクト・ガント・チャート・ノードを右クリックし、プロジェクト・ガントの中に挿入→「凡例」を選択します。

凡例には、それぞれの記号に関する情報と、各タスク・タイプを表すカラー・コード化された棒が示されます。また、ガント・チャート内で選択されているタスクに関する詳細情報も示されます。

プロジェクト・ガント・チャートの作成後に、「プロパティ」ウィンドウを使用して、追加の属性に値を設定します。ガント・チャートのユースケース、エンド・ユーザー機能とプレゼンテーション機能、タグ構造、ガント・チャートへの特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ガント・チャート・コンポーネントの使用方法」を参照してください。

42.2.2 データ・コントロールからのプロジェクト・ガント・チャートの作成時の処理

プロジェクト・ガント・チャートを作成するために、「データ・コントロール」パネルからビュー・オブジェクトをドラッグ・アンド・ドロップすると、次の処理が行われます。

- ガント・チャートのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

次の例は、出荷された注文を表示する図42-1のプロジェクト・ガント・チャート用に生成された行セット・バインディングを示しています。このコード例は、タスクID、開始日および終了日についての属性を持つタスク用に定義したノードを示しています。また、定義された属性のないサブタスク、依存タスク、分割タスクおよび再帰タスク用に定義されたノードもあります。

<bindings>
<gantt IterBinding="OrderEmployee1Iterator" id="OrderEmployee1"
xmlns="http://xmlns.oracle.com/adfm/dvt">    <ganttDataMap>      <nodeDefinition DefName="model.OrderEmployee" type="Tasks">        <AttrNames>
<Item Value="TaskId" type="taskId"/>
<Item Value="StartDate" type="startTime"/>
<Item Value="EndDate" type="endTime"/>
<Item Value="TaskType" type="taskType"/>
</AttrNames>
</nodeDefinition>
<nodeDefinition type="subTasks">
<AttrNames/>
</nodeDefinition>
<nodeDefinition type="Dependents">
<AttrNames/>
</nodeDefinition>
<nodeDefinition type="SplitTasks">
<AttrNames/>
</nodeDefinition>
<nodeDefinition type="RecurringTasks">
<AttrNames/>
</nodeDefinition>
</ganttDataMap>
</gantt>
</bindings>

次の例は、プロジェクト・ガント・チャートに対してJSFページで生成されるコードを示しています。このタグ・コードには、プロジェクト・ガント・チャートの全体的な開始および終了時間に対する設定が含まれています。また、主軸(週)および副軸(日)に対するデフォルトの時間軸の設定も示されています。さらに、ガント・チャートのリスト・リージョンに表示される各列に対する指定もリストされています。

<dvt:projectGantt id="gantt1" value="#{bindings.OrderEmployee1.projectGanttModel}"
dataChangeListener="#{bindings.OrderEmployee1.projectGanttModel
.processDataChanged}"
var="row"
startTime="2012-03-31" endTime="2012-06-30">
<f:facet name="major">
<dvt:timeAxis scale="weeks" id="ta1"/>
</f:facet>
<f:facet name="minor">
<dvt:timeAxis scale="days" id="ta2"/>
</f:facet>
<f:facet name="nodeStamp">
<af:column
sortProperty="#{bindings.OrderEmployee1.hints.FirstName.name}"
sortable="false"
headerText="#{bindings.OrderEmployee1.hints.FirstName.label}"
id="c1">
<af:outputText value="#{row.FirstName}" id="ot1"/>
</af:column>
</f:facet>
<af:column sortProperty="LastName" sortable="false"
headerText="#{bindings.OrderEmployee1.hints.LastName.label}">
<af:outputText value="#{row.LastName}"/>
</af:column>
<af:column sortProperty="OrderDate" sortable="false"
headerText="#{bindings.OrderEmployee1.hints.OrderDate.label}">
<af:outputText value="#{row.OrderDate}">
<af:convertDateTime
pattern="#{bindings.OrderEmployee1.hints.OrderDate.format}"/>
</af:outputText>
</af:column>
<af:column sortProperty="ShippedDate" sortable="false"
headerText="#{bindings.OrderEmployee1.hints.ShippedDate.label}">
<af:outputText value="#{row.ShippedDate}">
<af:convertDateTime
pattern="#{bindings.OrderEmployee1.hints.ShippedDate.format}"/>
</af:outputText>
</af:column>
<af:column sortProperty="TaskType" sortable="false"
headerText="#{bindings.OrderEmployee1.hints.TaskType.label}">
<af:outputText value="#{row.TaskType}"/>
</af:column>
</projectGantt>

42.2.3 データバインドされたリソース使用率ガント・チャートの作成方法

リソース使用率ガント・チャートでは、リソースのID、時間のID、リソース使用率の開始および終了時間を指定する必要があります。オプションで、サブリソースのデータ値を指定できます。

リソース使用率ガント・チャートは、主および副時間軸の値に対するデフォルト値を使用して表示されます。リソース使用率ガント・チャートでは、主時間軸はデフォルトで週に設定され、副時間軸は日に設定されます。

図42-4は、各リソースと、リソースの使用中に表示できる関連付けられたカレンダを示すリソース使用率ガント・チャートを示しています。

図42-4 リソース使用率ガント・チャート

データ・コントロールを使用してリソース使用率ガント・チャートを作成するには、リソース使用率コンポーネントをデータ・コレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグしてJSFページにドロップし、宣言的にこの処理を実行できます。

ヒント:

また、「コンポーネント」ウィンドウからリソース使用率ガント・チャート・コンポーネントをドラッグし、「リソース使用率ガントの作成」ダイアログの入力を完了することで、リソース使用率ガント・チャートを作成することもできます。この方法では、コンポーネントをデータにバインドする前に、ガント・チャートのユーザー・インタフェースを設計できます。

始める前に:

データバインドされたガント・チャートについて理解しておいてください。詳細は、「データバインドされたガント・チャートの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
たとえば、図42-4に示すガント・チャートのデータ・ソースは、Summit ADF DVTサンプル・アプリケーションのビュー・オブジェクトから取得しています。販売担当者を表すSalesRepViewObj1ビュー・オブジェクトを使用します。このオブジェクトには、注文日と出荷日についてのタイム・バケット・アクセッサと属性を含むSOrdView2ビュー・オブジェクトへのビュー・リンクが含まれています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

「データ・コントロール」パネルを使用して、リソース使用率ガント・チャートを作成するには:

1. 「データ・コントロール」パネルから、データ・コレクションを選択します。ガント・チャートでは、行セット・コレクションまたは基本的なツリー・コレクションを選択できます。

図42-5に、「データ・コントロール」パネルでSalesRepViewObj1コレクションを選択して、リソースの使用率を表示するリソース使用率ガント・チャートを作成する例を示します。

図42-5 リソース使用率ガント・チャートのデータ・コレクション

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「ガント」→「リソース使用率」を選択します。

3. 「リソース使用率ガントの作成」ダイアログで、次の属性に対応するデータ・コレクション内の列を選択します。

- リソースID: リソースの一意のID。たとえば、ビュー・オブジェクト内で販売責任者を表すIdです。

- コンテナ: ブール値。ノード定義がコンテナかどうかを指定します。

4. 「時間バケット」ページでは、リソースに割り当てられた時間バケットを含む「バケット・アクセッサ」ドロップダウン・リストから値を選択し、時間の単位に対応する「バケット日」ドロップダウン・リストから値を選択します。

たとえば、SOrdView2ビュー・オブジェクトには、販売責任者に関連付けられた注文ごとに、受注日と出荷日を表す属性が含まれています。図42-6に、バケット・アクセッサに使用するビュー・オブジェクトを示します。

図42-6 リソース使用率ガント・チャートのバケット・アクセッサ

5. 「バケット・メトリック」リストで、時間バケット内のバーとして表示される属性を指定します。「新規」アイコンを使用して新しい行を追加し、「削除」アイコンを使用して行を削除します。また、矢印アイコンを使用して、ガント・チャート・リージョンに表示する列の行の順序を並べ替えます。

「バケット・メトリック」リストで指定した属性はバーの高さの計算に使用されるため、個々の属性は数値タイプでなければなりません。

6. 「表の列」セクションで、ガント・チャートのリスト・リージョン内に各行を表示する列を選択します。「新規」アイコンを使用すると、新しい行を追加できます。行を削除するには、「削除」アイコンを使用します。また、矢印アイコンを使用すると、ガント・チャート・リストに表示する列の行の順序を並べ替えできます。

注意:

「表の列」セクションで指定する最初の行により、リスト・リージョンのnodestamp列を指定します。サブリソース・アクセッサを指定すると、この行は、階層関係の開閉可能な親を表示します。

各行で、次を指定します。

- ラベルの表示: ガント・チャート・リストの列のヘッダーの値を選択します。<default>を選択すると、ヘッダーのテキストはデータ・バインディングから自動的に取得されます。

- 値バインディング: ガント・チャート・リストの列に使用するデータ・コレクション内の列を選択します。選択できる値は、タスク・グループの場合と同じです。

- 使用するコンポーネント: ガント・チャート・リストのセルに表示するコンポーネントのタイプを選択します。ADF入力コンポーネントを使用すると、セルが編集可能になるように指定できます。デフォルトは、ADF出力テキスト・コンポーネントです。

7. データ・コレクション内にサブリソースに対するアクセッサが含まれている場合は、「サブリソース」ページを使用して、ドロップダウン・リストから「サブリソース・アクセッサ」を選択し、「リソースID」ドロップダウン・リストからサブリソースの一意のIDを選択します。

8. 「外観」ページで、タスク・バーの「ラベル」に対応する属性を指定します。

9. 「OK」をクリックします。

図42-7に、プロジェクトで使用可能なリソースのデータ・コレクションからリソース使用率ガント・チャートを作成するために使用するダイアログを示します。

図42-7 リソース使用率ガント・チャートの作成ダイアログ

10. 「構造」ウィンドウでdvt:resourceUtilizationGanttコンポーネントを右クリックし、「プロパティに移動」を選択します。

11. 「プロパティ」ウィンドウで、「共通」セクションを開き、StartTime属性とEndTime属性の日付(yyyy-mm-dd)を指定します。これらの属性は、ガント・チャート・データの期間の開始日と終了日を表します。

指定した日付に応じて、実行時にリソース使用率ガント・チャートに表示される初期ビューが決定されます。

12. ガント・チャートに凡例を含めるには、「構造」ウィンドウでリソース使用率ガント・チャート・ノードを右クリックし、リソース使用率ガントの中に挿入→「凡例」を選択します。

凡例には、それぞれの記号に関する情報と、各タスクを表すカラー・コード化された棒が示されます。また、ガント・チャート内で選択されているタスクに関する詳細情報も示されます。

リソース使用率ガント・チャートの作成後に、「プロパティ」ウィンドウを使用して、追加の属性に値を設定します。ガント・チャートのユースケース、エンド・ユーザー機能とプレゼンテーション機能、タグ構造、ガント・チャートへの特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ガント・チャート・コンポーネントの使用方法」を参照してください。

42.2.4 リソース使用率ガント・チャート作成時の処理

リソース使用率ガント・チャートを作成するために、「データ・コントロール」パネルからJSFページにビュー・オブジェクトをドラッグ・アンド・ドロップすると、次の処理が行われます。

- リソース使用率ガント・チャートのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

次の例は、図42-7に示すリソース使用率ガント・チャートに生成された行セット・バインディングを示しています。

<bindings>
<gantt IterBinding="SalesRepViewObj1Iterator" id="SalesRepViewObj1"
xmlns="http://xmlns.oracle.com/adfm/dvt">
<ganttDataMap>
<nodeDefinition DefName="model.SalesRepViewObj" type="Resources">
<AttrNames>
<Item Value="Id" type="resourceId"/>
</AttrNames>
<Accessors>
<Item Value="SOrdView" type="timeBuckets"/>
</Accessors>
</nodeDefinition>
<nodeDefinition type="TimeBuckets" DefName="model.SOrdView">
<AttrNames>
<Item Value="DateOrderedDay" type="time"/>
<Item type="metric" Value="Total"/>
</AttrNames>
</nodeDefinition>
<nodeDefinition type="Subresources">
<AttrNames/>
</nodeDefinition>
</ganttDataMap>
</gantt>
</bindings>

次の例は、リソース使用率ガント・チャートに対してJSFページで生成されるコードを示しています。このタグ・コードには、リソース使用率ガント・チャートの全体的な開始および終了時間に対する設定が含まれています。これらの設定は手動で編集する必要があります。また、主時間軸(週)および副時間軸(日)に対する時間軸の設定も示されています。さらに、リソース使用率ガント・チャートのリスト・リージョンに表示される各列に対する指定もリストされています。

<dvt:resourceUtilizationGantt id="gantt1"
value="#{bindings.SalesRepViewObj1.resourceUtilizationGanttModel}"
var="row" metrics="#{bindings.SalesRepViewObj1.metrics}"
taskbarFormatManager="#{bindings.SalesRepViewObj1.
resourceUtilizationGanttTaskbarFormatManager}"
startTime="2012-05-09" endTime="2013-05-15"
summary="#{viewcontrollerBundle.RESOURCE_UTILIZATION_GANTT_CHART}">
<f:facet name="major">
<dvt:timeAxis scale="weeks" id="ta1"/>
</f:facet>
<f:facet name="minor">
<dvt:timeAxis scale="days" id="ta2"/>
</f:facet>
<f:facet name="nodeStamp">
<af:column sortProperty="#{bindings.SalesRepViewObj1.hints.FirstName.name}"
sortable="false"
headerText="#{bindings.SalesRepViewObj1.hints.FirstName.label}"
id="c1">
<af:outputText value="#{row.FirstName}"
shortDesc="#{bindings.SalesRepViewObj1.hints.FirstName.tooltip}"
id="ot1"/>
</af:column>
</f:facet>
<af:column sortProperty="#{bindings.SalesRepViewObj1.hints.LastName.name}"
sortable="false"
headerText="#{bindings.SalesRepViewObj1.hints.LastName.label}"
id="c2">
<af:outputText value="#{row.LastName}"
shortDesc="#{bindings.SalesRepViewObj1.hints.LastName.tooltip}"
id="ot2"/>
</af:column>
<af:column sortProperty="#{bindings.SalesRepViewObj1.hints.Email.name}"
sortable="false"
headerText="#{bindings.SalesRepViewObj1.hints.Email.label}"
id="c3">
<af:outputText value="#{row.Email}"
shortDesc="#{bindings.SalesRepViewObj1.hints.Email.tooltip}"
id="ot3"/>
</af:column>
</dvt:resourceUtilizationGantt>

42.2.5 データバインドされたスケジュール・ガント・チャートの作成方法

スケジュール・ガント・チャートでは、リソースのID、タスクのID、タスクの開始および終了時間を指定する必要があります。オプションで、サブリソース、再帰タスク、分割タスクおよびタスク間の依存性のデータ値を指定できます。

スケジュール・ガント・チャートは、全体的な開始および終了時間と、主および副時間軸の値に対するデフォルト値を使用して表示されます。スケジュール・ガント・チャートでは、主時間軸はデフォルトで週に設定され、副時間軸は日に設定されます。

図42-8は、各リソースと、そのリソースが担当するすべての注文をリストするスケジュール・ガント・チャートを示しています。プロジェクト・ガント・チャートでは各タスクが個別の線上にリストされますが、スケジュール・ガント・チャートでは特定のリソースのすべてのタスクが同じ線上に表示されます。

図42-8 注文の出荷のスケジュール・ガント・チャート

データ・コントロールを使用してスケジュール・ガント・チャートを作成するには、schedulingGanttタグをデータ・コレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

始める前に:

データバインドされたガント・チャートについて理解しておいてください。詳細は、「データバインドされたガント・チャートの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
たとえば、図42-8に示すガント・チャートのデータ・ソースは、Summit ADF DVTサンプル・アプリケーションのビュー・オブジェクトから取得しています。販売担当者を表すSalesRepViewObj1ビュー・オブジェクトを使用します。このオブジェクトには、注文日と出荷日についてのタスク・アクセッサと属性を含むSOrdView2ビュー・オブジェクトへのビュー・リンクが含まれています。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

「データ・コントロール」パネルを使用して、スケジュール・ガント・チャートを作成するには:

1. 「データ・コントロール」パネルから、データ・コレクションを選択します。ガント・チャートでは、行セット・コレクションまたは基本的なツリー・コレクションを選択できます。

図42-9に、SalesRepViewObj1データ・コレクションを選択して、スケジュール・ガント・チャートを作成する例を示します。このチャートには、各販売担当者が管理を担当する注文が表示されます。

図42-9 スケジュール・ガント・チャートのデータ・コレクション

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「ガント」→「スケジューリング」を選択します。

3. 「スケジュール・ガントの作成」ダイアログで、次の属性に対応するデータ・コレクション内の列を選択します。

- リソースID: スケジュール・ガント・チャートでリソースを表す一意のID。

- 作業開始時間: スケジュール・ガント・チャートの作業開始日。

- 作業終了時間: スケジュール・ガント・チャートの作業終了日。

- 作業曜日: 作業曜日のリストを指定します。

- コンテナ: ブール値。ノード定義がコンテナかどうかを指定します。

4. 「タスク」ページで、ドロップダウン・リストから「タスク・アクセッサ」を選択して、次の属性に対応するデータ・コレクション内の列を選択します。

- タスクID: ガント・チャート内のリソースに関連付けられたタスクの一意のID。

- タスク・タイプ: ガント・チャートにタスク・バーをレンダリングするときに、そのタスク・バーの外観を指定するために使用するタイプ。タイプをデータ・コレクション内の列にバインドしない場合、すべてのタスクはデフォルトでScheduledになります。

- 開始時間: タスクの開始時刻。

- 終了時間: タスクの終了時刻。

- 起動時間: タスクを開始するまでにかかる時間。

- シャットダウン時間: タスクが完了してから終了するまでの時間。

たとえば、SOrdView2ビュー・オブジェクトには、販売責任者に関連付けられた注文ごとに、受注日と出荷日を表す属性が含まれています。図42-10に、タスク・アクセッサに使用するビュー・オブジェクトを示します。

図42-10 スケジュール・ガント・チャートのタスク・アクセッサ

5. データ・コレクションに依存タスクに対するアクセッサが含まれている場合は、「依存タスク」ページを使用して、「依存タスク・アクセッサ」を選択し、次の属性に対応するデータ・コレクション内の列を選択します。

- 依存性のタイプ: 依存性のタイプを指定します。有効な値は、start-start、start-finish、finish-finish、finish-start、start-before、start-together、finish-afterおよびfinish-togetherです。

- 元タスクID: 依存関係内で最初のタスクを指定します。

- 先タスクID: 依存関係内で最後のタスクを指定します。

各依存タスクは、それらのタスクの終了時刻と開始時刻を関連付けることでリンクします。

6. データ・コレクションに分割タスクに対するアクセッサが含まれている場合は、「分割タスク」ページを使用して、「分割タスク・アクセッサ」を選択し、次の属性に対応するデータ・コレクション内の列を選択します。

- 分割タスクID: 2つの横棒(通常は、線でリンクされる)に分割されたタスクの一意のID。棒の間の時間は、移動時間または停止時間によるアイドル時間を表します。

- 開始時間: 分割タスクの開始時刻。

- 終了時間: 分割タスクの終了時刻。

7. データ・コレクションに再帰タスクに対するアクセッサが含まれている場合は、「再帰タスク」ページを使用して、ドロップダウン・リストから「再帰タスク・アクセッサ」を選択し、次の属性に対応するデータ・コレクション内の列を選択します。

- 再帰タスクID: ガント・チャートで繰り返されるタスクの一意のID。タスクの各インスタンスには、固有の開始日と終了日が含まれます。個々の再帰タスクにはオプションでサブタイプを含めることができます。個々の再帰タスクのその他すべてのプロパティには、そのタスクが一部となっているタスクのプロパティが使用されます。ただし、個々の再帰タスクにサブタイプがある場合は、このサブタイプがタスク・タイプをオーバーライドします。

- タイプ: 再帰タスクのタイプを指定します。

- 開始時間: 再帰タスクの開始時刻。

- 終了時間: 再帰タスクの終了時刻。

8. データ・コレクション内にサブリソースに対するアクセッサが含まれている場合は、「サブリソース」ページを使用して、ドロップダウン・リストから「サブリソース・アクセッサ」を選択し、サブリソースIDに対応するデータ・コレクション内の列を選択します。このIDは、データ・コレクション内のサブリソースのリストの一意のIDです。

サブリソースをバインドしていないと、ガント・チャートでリソースの階層ビューをレンダリングできなくなります。サブリソースをバインドすると、ガント・チャートの階層ビューで、リソースからサブリソースに向けたドリル操作が可能になります。

9. 「外観」ページで、タスク・バーの「ラベル」に対応する属性と、タスク・バーに関連付けるアイコンを3個まで指定します。

10. 「表の列」セクションでは、分割線の左側のガント・チャートのリスト・リージョンに表示される列を指定します。表示するそれぞれの列に対して、1行の情報を指定します。新規行を追加するには、「新規」アイコンを使用します。ガント・チャート・リストで列を表示する順序のとおりに行を配置するには、矢印アイコンを使用します。各行について、次のアイテムを指定します。

- ラベルの表示: ガント・チャート・リストの列のヘッダーの値を選択します。<default>を選択すると、ヘッダーのテキストはデータ・バインディングから自動的に取得されます。

- 値バインディング: ガント・チャート・リストの列に使用するデータ・コレクション内の列を選択します。選択できる値は、タスク・グループの場合と同じです。

- 使用するコンポーネント: ガント・チャート・リストのセルに表示するコンポーネントのタイプを選択します。デフォルトは、「ADF出力テキスト」コンポーネントです。

11. 「OK」をクリックします。

図42-11に、注文の出荷を担当する販売担当者のデータ・コレクションからスケジュール・ガント・チャートを作成する際に使用されるダイアログを示します。

図42-11 「スケジュール・ガントの作成」ダイアログ

12. 「構造」ウィンドウでdvt:schedulingGanttコンポーネントを右クリックし、「プロパティに移動」を選択します。

13. 「プロパティ」ウィンドウで、「共通」セクションを開き、StartTime属性とEndTime属性の日付(yyyy-mm-dd)を指定します。これらの属性は、ガント・チャート・データの期間の開始日と終了日を表します。

指定した日付により、実行時にスケジュール・ガント・チャートに表示される初期ビューが決定されます。

14. ガント・チャートに凡例を含めるには、「構造」ウィンドウでスケジュール・ガント・チャート・ノードを右クリックし、スケジュール・ガントの中に挿入→「凡例」を選択します。

凡例には、それぞれの記号に関する情報と、各タスクを表すカラー・コード化された棒が示されます。また、ガント・チャート内で選択されているタスクに関する詳細情報も示されます。

42.2.6 スケジュール・ガント・チャート作成時の処理

スケジュール・ガント・チャートを「データ・コントロール」パネルからドロップすると、次の処理が行われます。

- ガント・チャートのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

次の例は、リソースおよび出荷された注文を表示するスケジュール・ガント・チャートに生成された行セット・バインディングを示しています。

<bindings>
<gantt IterBinding="SalesRepViewObj1Iterator" id="SalesRepViewObj1"
xmlns="http://xmlns.oracle.com/adfm/dvt">
<ganttDataMap>
<nodeDefinition DefName="model.SalesRepViewObj" type="Resources">
<AttrNames>
<Item Value="Id" type="resourceId"/>
</AttrNames>
<Accessors>
<Item Value="SOrdView" type="tasks"/>
</Accessors>
</nodeDefinition>
<nodeDefinition type="Tasks" DefName="model.SOrdView">
<AttrNames>
<Item Value="Id" type="taskId"/>
<Item Value="DateOrdered" type="startTime"/>
<Item Value="DateShipped" type="endTime"/>
</AttrNames>
</nodeDefinition>
<nodeDefinition type="Dependents">
<AttrNames/>
</nodeDefinition>
<nodeDefinition type="SplitTasks">
<AttrNames/>
</nodeDefinition>
<nodeDefinition type="RecurringTasks">
<AttrNames/>
</nodeDefinition>
<nodeDefinition type="Subresources">
<AttrNames/>
</nodeDefinition>
</ganttDataMap>
</gantt>
</bindings>

次の例は、スケジュール・ガント・チャートに対してJSFページで生成されるコードを示しています。このタグ・コードには、スケジュール・ガント・チャートの全体的な開始および終了時間に対する設定が含まれています。また、主時間軸(週)および副時間軸(日)に対する時間軸の設定も示されています。さらに、ガント・チャートのリスト・リージョンに表示される各列に対する指定もリストされています。

<dvt:schedulingGantt id="gantt1"
value="#{bindings.SalesRepViewObj1.schedulingGanttModel}"
dataChangeListener="#{bindings.SalesRepViewObj1.
schedulingGanttModel.processDataChanged}"
var="row" startTime="2012-04-15" endTime="2013-05-15"
summary="#{viewcontrollerBundle.SCHEDULING_GANTT_CHART}">
<f:facet name="major">
<dvt:timeAxis scale="weeks" id="ta1"/>
</f:facet>
<f:facet name="minor">
<dvt:timeAxis scale="days" id="ta2"/>
</f:facet>
<f:facet name="nodeStamp">
<af:column sortProperty="#{bindings.SalesRepViewObj1.hints.FirstName.name}"
sortable="false"
headerText="#{bindings.SalesRepViewObj1.hints.FirstName.label}"
id="c1">
<af:outputText value="#{row.FirstName}"
shortDesc="#{bindings.SalesRepViewObj1.hints.
FirstName.tooltip}"
id="ot1"/>
</af:column>
</f:facet>
<af:column sortProperty="#{bindings.SalesRepViewObj1.hints.LastName.name}"
sortable="false"
headerText="#{bindings.SalesRepViewObj1.hints.LastName.label}"
id="c2">
<af:outputText value="#{row.LastName}"
shortDesc="#{bindings.SalesRepViewObj1.hints.LastName.tooltip}"
id="ot2"/>
</af:column>
<af:column sortProperty="#{bindings.SalesRepViewObj1.hints.Email.name}"
sortable="false"
headerText="#{bindings.SalesRepViewObj1.hints.Email.label}" id="c3">
<af:outputText value="#{row.Email}"
shortDesc="#{bindings.SalesRepViewObj1.hints.Email.tooltip}"
id="ot3"/>
</af:column>
</dvt:schedulingGantt>

42.2.7 データ変更イベントの処理に関する必知事項

ADFデータ・コントロールを使用して、プロジェクト・ガント・チャートおよびスケジュール・ガント・チャートにデータをバインドすると、次に示すような行の属性の更新が必要になるデータ変更イベントに対応するデータ変更リスナーが、自動的に提供されます。

- DURATION_CHANGE: タスクの終了時刻(タスク・バーのサイズ変更)

- PROGRESS_CHANGE: タスクの進行状況(進行状況バーのサイズ変更)

- TIME_CHANGE: タスクの開始時刻および終了時刻(タスク・バーの移動)

設計時に、次の例に示すように、データ変更リスナーで、プロジェクト・ガントおよびスケジュール・ガントのバインディング用に、組込みのprocessDataChangeメソッドを提供します。

<dvt:projectGantt id="gantt1"
dataChangeListener="#{bindings.GanttProjectView1.
projectGanttModel.processDataChanged}"
value="#{bindings.GanttProjectView1.projectGanttModel}"
...
</dvt:projectGantt>

次に示すような、行の挿入または削除が必要になるデータ変更イベントは、サポートされていません。

- TASK_SPLITTED: タスクの分割

- TASK_MERGED: 別のタスクとのタスクのマージ

- LINK: 2つのタスクの相互リンク

- UNLINK: 相互リンクされた2つのタスクのリンク解除

- COPY: 1つ以上のタスクまたはリソースのコピー

- CREATE: 新しいタスクの作成

- CREATE_RESOURCE: 新しいリソースの作成

- CUT: 1つ以上のタスクまたはリソースのカット

- PASTE: タスクまたはリソースの貼り付け

- UPDATE: タスクの更新

- UPDATE_RESOURCE: リソースの更新

- TASKS_PROPERTIES_UPDATE: タスク・プロパティ・ダイアログのイベント

- INDENT: タスクまたはイベントのインデント

- OUTDENT: タスクまたはリソースのアウトデント

- DELETE: 1つ以上のタスクまたはリソースの削除

デフォルトの実装がないイベントをアプリケーションが処理できるように構成するには、バッキングBeanのメソッドを指定して、組込みのprocessDataChangeメソッドに委譲します。たとえば、次のコードの最初のブロックには、次のクラス・コードに示すバッキングBeanを使用してTASK_PROPERTIES_UPDATEイベントを処理するためにhandleDataChangeメソッドを使用するように構成されたdataChangeListenerが表示されています。

<dvt:projectGantt id="gantt1"
dataChangeListener="#{backingBeanScope.backing_
projectGantt.handleDataChange}"
value="#{bindings.GanttProjectView1.projectGanttModel}"
...
</dvt:projectGantt>

public void handleDataChange(DataChangeEvent evt)
{
// handle events not supported by built-in "processDataChange" method
int _type = evt.getActionType();
if (_type == DataChangeEvent.TASK_PROPERTIES_UPDATE)
{
// handle event.
}
else  // delegate to built-in "processDataChange" method.
{
Application app = facesContext.getApplication();
String expression =
"#{bindings.GanttProjectView1.projectGanttModel.processDataChanged}";
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext elContext = facesContext.getELContext();
MethodExpression methodExp = elFactory.createMethodExpression(elContext,
expression, null, new Class[] {DataChangeEvent.class});
methodExp.invoke(elContext, new Object[] {evt});
}
}

注意:

プロジェクトおよびスケジュールのガント・チャートについては、ADFデータ・コントロールのdataChangeListenerのデフォルト実装では、データベースへの変更のコミットまたはロールバックを実行しません。これらの操作を処理するように、アプリケーションを構成する必要があります。

42.3 データバインドされた時系列の作成

時系列は、ユーザーが日付ベースのイベントを時間順に表示し、定義された時間範囲内を簡単に前後に移動することを可能にする対話型のデータ視覚化ツールです。二重時系列を使用して、イベントの対照比較を行うことができます。たとえば、時系列を使用して従業員の入社日を表示したり、二重時系列を使用して2人の従業員の複数の人事管理イベントを比較したりすることができます。

時系列は、時間軸に沿った時系列アイテムとしてのイベントの表示、時系列に表示可能な期間に対応する移動可能な概要ウィンドウ、および時系列の時間増分全体を示した概要時間軸で構成されます。表示可能な時間範囲は、水平方向のズーム制御を使用して変更できます。イベントに対応する各時系列アイテムは、関連する情報やアクションを表示し、時間軸内のイベント日付に結び付けられます。時系列アイテムは、概要パネルにマーカーで表されます。時系列コンポーネントでは、イベントの系列が2つまでサポートされます。

図42-12に、Summit ADF DVTサンプル・アプリケーションで従業員の雇用日を時間順に表示した時系列の例を示します。この例では、各イベントを表す時系列アイテムに、イメージとラベル付きテキストを使用して従業員に関する情報を表示しています。選択が構成されている場合は、時系列アイテム、引出線、および概要パネルのイベント・マーカーが強調表示されます。

図42-12 従業員の雇用日の時系列

図42-13に、2人の従業員の複数の人事管理イベントを比較する二重時系列を示します。時間軸は2つのイベント系列の間に配置され、概要パネルは時系列の一番下に表示されています。

図42-13 2人の従業員のイベントを示す二重時系列

時系列項目の内容、マーカーの表示および時間軸は構成可能です。時系列のユースケース、エンド・ユーザー機能とプレゼンテーション機能、タグ構造、時系列への特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「時系列コンポーネントの使用」を参照してください。

42.3.1 ADFデータ・コントロールを使用した時系列の作成方法

時系列に表示されるデータは、データ・コレクションに基づいています。timelineコンポーネントは、モデルを使用して、基になるリストのデータにアクセスします。固有のモデル・クラスはoracle.adf.view.rich.model.CollectionModelです。java.util.List、java.util.Arrayおよびjavax.faces.model.DataModelなど、その他のモデル・インスタンスも使用できます。データ・レイヤーではインスタンスがCollectionModelに自動的に変換されます。

時系列イベントに関する情報をデータ・コレクションのデータ行に関連付けるには、スタンプを使用します。スタンプを使用すれば、データ・モデル内の各データ行をイベントに対して表示できます。スタンプを使用する場合、時系列のすべての項目に対して子コンポーネントが作成されるわけではありません。むしろ、コンポーネントのコンテンツは、データ属性ごとに1回、繰り返しレンダリング(スタンプ)されます。

Oracle ADFのデータ・コントロールを使用すると、JDeveloperでは宣言的なタスクとなります。「データ・コントロール」パネルから、1つ(または2つ)のイベント系列を生成するデータ・コレクションをドラッグして、JSFページにドロップします。

始める前に:

時系列について理解しておくと役立ちます。詳細は、「データバインドされた時系列の作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
たとえば、図42-12に示す時系列のデータ・ソースは、Summit ADF DVTサンプル・アプリケーションのビュー・オブジェクトから取得しています。SEmp表を使用して、各従業員と雇用日を表すビュー・オブジェクトを作成します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

「データ・コントロール」パネルを使用して時系列を作成するには:

1. 「データ・コントロール」パネルから、コレクションを選択します。
図42-14に、「データ・コントロール」パネルでSEmpView1コレクションを選択して、従業員の雇用日を表示する時系列を作成する例を示します。

図42-14 従業員の雇用日についての時系列用データ・コレクション

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「時系列」を選択します。

3. 「時系列の作成」ウィザードの「時系列の系列データの構成」ページで次の値を設定することにより、1つ以上(二重時系列の場合は2つ)の時系列に対する時系列データ・モデルを構成します。

a. 系列値: ドロップダウン・リストを使用して、時系列で使用するデータ・コレクションを選択します。デフォルトでは、「データ・コントロール」パネルから挿入したデータ・コレクションが表示されます。該当する日付ベースの属性を1つ以上含むアプリケーション・モジュールからのコレクションのリストが、選択用に自動的に表示されます。

b. アイテム・データ値: ドロップダウン・リストを使用して、時系列内にスタンプされる時系列項目に対して使用する日付ベースの属性を選択します。「系列値」で参照されるコレクション内の該当するすべての属性が選択用に自動的に表示されます。

c. グループ: オプションで、ドロップダウン・リストを使用して、項目日付値が同一の場合に時系列項目をグループ化するために使用する属性を選択します。すべてのデータ・コレクション属性が選択用に自動的に表示されます。
「式ビルダー」を選択してEL式を作成することにより、実行時に属性のグループ化を指定することもできます。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

4. データ・モデルとして構成した時系列の系列ごとに、系列を選択し、時系列項目の表示属性に対して次の値を設定します。

a. イメージ: オプションで、時系列項目にスタンプするイメージ・ファイルへの相対パスを入力するか、「検索」アイコンを使用して「イメージ・ファイルの選択」ダイアログを開き、イメージ・ソースに移動します。
「式ビルダー」を選択して、実行時に評価されてイメージ・ファイルの場所を特定するEL式を構成することもできます。

注意:

時系列項目内のイメージのサイズを変更する必要がある場合は、ソース・コードで、または「プロパティ」ウィンドウで宣言的に、af:imageコンポーネントのInlineStyle属性を指定します。たとえば、Summit ADF DVTサンプルでは、inlineStyle="width:85px;height:100px;"と指定します。

b. コンポーネント: ドロップダウン・リストから、時系列項目内に属性テキストを表示するために使用するADF Facesコンポーネントを選択します。書式設定されていないテキストを表示するoutputTextまたはテキストを表示して限られた範囲の書式設定オプションを設定できるoutputFormattedを選択できます。「ラベル」値を使用して、いずれかの出力テキスト・オプションにラベルを関連付けることも選択できます。

c. 値: ドロップダウン・リストから、時系列項目内に表示する属性値を選択します。選択した時系列の系列に対するデータ・コレクション内のすべての属性が自動的に表示されます。

d. ラベル: 表示属性に対する「コンポーネント」値でラベル付きのADF Facesコンポーネントを指定した場合は、このオプションを使用できます。デフォルトの「属性名の使用」テキストを使用するか、リソース・バンドルからのテキスト・リソースを指定するか、EL式ビルダーを使用して実行時にラベル・テキストを評価できます。ラベルは、実行時に時系列項目に表示されます。

たとえば、図42-12のSummit ADF DVTサンプルの場合、時系列の系列と表示属性を指定するには、図42-15に示すように、時系列の作成ウィザードの「時系列の系列データの構成」ページに必要事項を入力します。

図42-15 「時系列の作成」ウィザードの「時系列の系列データの構成」ページ

5. 「次へ」をクリックして、ウィザードの次のページに進むか、「取消」をクリックして時系列の作成を終了します。

6. 「時系列の作成」ウィザードの「イベント・マーカーの構成」ページで、データ・モデルとして構成した時系列の系列ごとに、系列を選択し、イベント・マーカーに対する次のオプションの値を設定します。

a. 「色」: イベント・マーカーの塗りつぶし色を指定します。ドロップダウン・リストを使用して使用可能な色を選択するか、アイコンをクリックしてカラー・ピッカー・ダイアログを表示できます。デフォルトでは、どの色も指定されません。

b. 不透明度: マーカーの塗りつぶし色の不透明度を指定します。有効な値の範囲は、0パーセント(透明)から100パーセント(不透明)です。

c. 標準図形: 選択した各時系列の系列値に対する概要マーカーの形状を指定します。ドロップダウン・リストから、7つの事前作成図形の内の1つを選択して、概要マーカーの形状を指定します。有効な値は、circle(デフォルト)、diamond、human、plus、square、triangleDownおよびtriangleUpです。

d. スケールX/スケールY: 概要マーカーをデフォルト・サイズから変更するための水平(scaleX)および垂直(scaleY)スケール係数を入力します。有効な値は、数値のパーセンテージです。マーカーが大きすぎる場合は、JDeveloperにより、時系列の概要領域に合せて自動的にマーカーのサイズが変更されます。

たとえば、図42-12のSummit ADF DVTサンプルの場合、時系列の概要系列マーカーを指定するには、図42-16に示すように、時系列の作成ウィザードの「イベント・マーカーの構成」ページに必要事項を入力します。

図42-16 「時系列の作成」ウィザードの「イベント・マーカーの構成」ページ

7. 「戻る」をクリックしてウィザードの前のページに戻るか、「次へ」をクリックしてウィザードの次のページへ進みます。または、「取消」をクリックして時系列の作成を終了します。

8. 「時系列の作成」ウィザードの「時間範囲とタイム・スケールの構成」ページで次の値を設定することにより、時間軸と概要軸を構成します。

a. 開始時間: yyyy-mm-ddフォーマットを使用して、時系列の時間範囲に使用する開始日を入力します。時系列に表示するデータ・コレクション内に含めるイベントの開始日を選択します。ドロップダウン・リストから「現在の日付」を選択できます。カレンダ・アイコンをクリックして日付ピッカー・ダイアログを表示することもできます。デフォルト値は、現在の日付から3か月前に設定されます。

b. 終了時間: yyyy-mm-ddフォーマットを使用して、時系列の時間範囲に使用する終了日を入力します。時系列に表示するデータ・コレクション内に含めるイベントの終了日を選択します。ドロップダウン・リストから「現在の日付」を選択できます。カレンダ・アイコンをクリックして日付ピッカー・ダイアログを表示することもできます。デフォルト値は、デフォルトの「開始時間」値から12か月後に設定されます。

c. 軸スケール: ドロップダウン・リストを使用して、時系列の時間軸で使用するタイム・スケールを選択します。時間軸は、時系列に対する現在の時間増分を示します。
「概要スケール」よりも小さなタイム・スケールを使用する必要があります。たとえば、概要スケールがmonthsに設定されている場合に、軸スケールをyearsに設定することはできません。カスタム軸スケールを指定することもできます。

有効値は、twoyears、years、halfyears、quarters(デフォルト)、twomonths、months、twoweeks、weeks、days、sixhours、threehours、hours、halfhoursおよびquarterhoursです。カスタム軸スケールを指定することもできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の時系列へのカスタム・タイム・スケールの追加方法に関する項を参照してください。

d. 概要スケール: ドロップダウン・リストを使用して、時系列の概要軸で使用するタイム・スケールを選択します。概要軸は、時系列に含まれる合計時間増分を示します。
有効値は、twoyears、years(デフォルト)、halfyears、quarters、twomonths、months、twoweeks、weeks、days、sixhours、threehours、hours、halfhoursおよびquarterhoursです。カスタム軸スケールを指定することもできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の時系列へのカスタム・タイム・スケールの追加方法に関する項を参照してください。

たとえば、図42-12のSummit DVT ADFサンプルの場合、時系列の軸と概要時間範囲を指定するには、図42-17に示すように、時系列の作成ウィザードの「時間範囲とタイム・スケールの構成」ページに必要事項を入力します。

図42-17 「時系列の作成」ウィザードの「時間範囲とタイム・スケールの構成」ページ

9. 「戻る」をクリックしてウィザードの前のページに戻るか、「終了」をクリックしてデータ・バインディングの定義を完了するか、「取消」をクリックして時系列の作成を終了します。

42.3.2 データ・コントロールを使用した時系列作成時の処理

ADFデータ・コントロールを使用して時系列を作成すると、JDeveloperにより、次が実行されます。

- 時系列に対するバインディングがJSFページのページ定義ファイルに定義されます。

- DVT時系列コンポーネント用のコードがJSFページに挿入されます。

次の例は、図42-12のSummit ADF DVTサンプルの時系列に対するJSFページのページ定義ファイルで定義されているバインディングを示しています。

<bindings>
<tree IterBinding="SEmpView1Iterator" id="SEmpView1" ChangeEventPolicy="ppr">
<nodeDefinition DefName="model.SEmpView" Name="SEmpView1">
<AttrNames>
<Item Value="DeptId"/>
<Item Value="FirstName"/>
<Item Value="Id"/>
<Item Value="LastName"/>
<Item Value="StartDate"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

次の例は、図42-12に例示された時系列に対して、JSFページに挿入されるコードを示しています。

<dvt:timeline id="tl1" startTime="2010-01-01" endTime="2012-12-31"
itemSelection="multiple">
<dvt:timelineSeries id="ts1" var="evt"
value="#{bindings.SEmpView1.collectionModel}">
<dvt:timelineItem value="#{evt.StartDate}" id="ti1" group="#{evt.DeptId}">
<af:panelGroupLayout id="pg1" layout="horizontal">
<af:image id="img1" source="images/#{evt.Id}.png"
inlineStyle="width:85px;height:100px;"/>
<af:spacer width="3" id="s1"/>
<af:panelGroupLayout id="pg2" layout="vertical">
<af:panelLabelAndMessage id="plam1"
label="#{viewcontrollerBundle.EMPLOYEE_ID}">
<af:outputText id="ot1" value="#{evt.Id}" noWrap="true">
<af:convertNumber groupingUsed="false" pattern=
"#{bindings.SEmpView1.hints.Id.format}"/>
</af:outputText>
</af:panelLabelAndMessage>
<af:panelLabelAndMessage id="plam2"
label="#{viewcontrollerBundle.FIRST_NAME}">
<af:outputText id="ot2" value="#{evt.FirstName}" noWrap="true"/>
</af:panelLabelAndMessage>
<af:panelLabelAndMessage id="plam3"
label="#{viewcontrollerBundle.LAST_NAME}">
<af:outputText id="ot3" value="#{evt.LastName}" noWrap="true"/>
</af:panelLabelAndMessage>
<af:panelLabelAndMessage id="plam4"
label="#{viewcontrollerBundle.DEPARTMENT_ID}">
<af:outputText id="ot4" value="#{evt.DeptId}" noWrap="true">
<af:convertNumber groupingUsed="false" pattern=
"#{bindings.SEmpView1.hints.DeptId.format}"/>
</af:outputText>
</af:panelLabelAndMessage>
</af:panelGroupLayout>
</af:panelGroupLayout>
<f:facet name="overviewItem">
<dvt:marker id="m1" fillColor="#ff0000"/>
</f:facet>
</dvt:timelineItem>
</dvt:timelineSeries>
<dvt:timeAxis id="ta1" scale="months"/>
<dvt:timelineOverview id="ov1">
<dvt:timeAxis id="ta2" scale="halfyears"/>
</dvt:timelineOverview>
</dvt:timeline>

42.3.3 データ・コントロールを使用した二重時系列の作成に関する必知事項

「データ・コントロール」パネルを使用して二重時系列を作成する際には、2つの時系列の系列に対して同じまたは異なるデータ・コレクションを構成できます。またそれぞれに対して、時系列項目の表示属性および概要マーカーを指定できます。「時系列の作成」ウィザードに、該当する日付ベースの属性を1つ以上含むアプリケーション・モジュールからのデータ・コレクションのリストが、選択用に自動的に表示されます。

次の例は、図42-13の二重時系列に対するサンプル・コードを示しています。

<dvt:timeline id="tl1" startTime="2000-01-01" endTime="2011-12-31"
inlineStyle="width:1024px;height:500px" itemSelection="single"
currentTime="2010-04-01">
<dvt:timelineSeries id="ts1" var="evt" value="#{timeline.firstModel}"
contentDelivery="lazy">
<dvt:timelineItem id="ti1" value="#{evt.date}" group="#{evt.group}">
<af:panelGroupLayout id="pg1" layout="horizontal">
<af:image id="img1" inlineStyle="width:30px;height:30px"
source="/resources/images/timeline/#{evt.type}.png"/>
<af:spacer width="3"/>
<af:panelGroupLayout id="pg2" layout="vertical">
<af:outputText id="ot1" inlineStyle="color:#084B8A"
value="#{evt.description}" noWrap="true"/>
<af:outputText id="ot2" value="#{evt.date}"
inlineStyle="color:#6e6e6e" noWrap="true">
<af:convertDateTime dateStyle="medium"/>
</af:outputText>
</af:panelGroupLayout>
</af:panelGroupLayout>
<f:facet name="overviewItem">
<dvt:marker id="m1" shape="circle" fillColor="#ff0000"/>
</f:facet>
</dvt:timelineItem>
</dvt:timelineSeries>
<dvt:timelineSeries id="ts2" var="evt" value="#{timeline.secondModel}"
contentDelivery="lazy">
<dvt:timelineItem id="ti2" value="#{evt.date}">
<af:panelGroupLayout id="pg2" layout="horizontal">
<af:image id="img2" inlineStyle="width:30px;height:30px"
source="/resources/images/timeline/#{evt.type}.png"/>
<af:spacer width="3"/>
<af:panelGroupLayout id="pg3" layout="vertical">
<af:outputText id="ot3" inlineStyle="color:#084B8A"
value="#{evt.description}" noWrap="true"/>
<af:outputText id="ot4" value="#{evt.date}"
inlineStyle="color:#6e6e6e" noWrap="true">
<af:convertDateTime dateStyle="medium"/>
</af:outputText>
</af:panelGroupLayout>
</af:panelGroupLayout>
<f:facet name="overviewItem">
<dvt:marker id="m2" shape="circle" fillColor="#0000ff"/>
</f:facet>
</dvt:timelineItem>
</dvt:timelineSeries>
<dvt:timeAxis id="ta1" scale="quarters"/>
<dvt:timelineOverview id="ov1">
<dvt:timeAxis id="ta2" scale="years"/>
</dvt:timelineOverview>
</dvt:timeline>

このコンポーネントのデータ要件、タグ構造および外観と動作のカスタマイズ・オプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「時系列コンポーネントの使用」を参照してください。

43 データバインドされた階層ビューア、ツリーマップおよびサンバースト・コンポーネントの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータから、階層ビューア、ツリーマップまたはサンバーストを作成する方法について説明します。これらの作成には、Fusion WebアプリケーションのADFデータ・コントロールとADF Facesコンポーネントを使用します。具体的には、ADFデータ視覚化コンポーネントのhierarchyViewer、treemapおよびsunburstを使用して、ビジネス・データを視覚的に表現する階層ビューア、ツリーマップおよびサンバーストを作成する方法について説明します。ここでは、ADFデータ・コントロールを使用して、これらのコンポーネントをデータ優先開発で作成する方法について説明します。

簡単なUI優先開発を使用してページを設計する場合は、階層ビューア、ツリーマップまたはサンバーストをページに追加してから、データ・バインディングを構成してください。階層ビューア、ツリーマップおよびサンバースト・コンポーネントのデータ要件、タグ構造および外観と動作のカスタマイズ・オプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「階層ビューア・コンポーネントの使用方法」と「ツリーマップおよびサンバースト・コンポーネントの使用方法」を参照してください。

この章の内容は次のとおりです。

- ADFデータ視覚化コンポーネントについて

- データバインドされた階層ビューアの作成

- データバインドされたツリーマップおよびサンバーストの作成

43.1 ADFデータ視覚化コンポーネントについて

ADFデータ視覚化コンポーネントは、ビジネス・データを視覚的に表示、分析するための幅広いグラフィック機能と表機能を提供します。コンポーネントをレンダリングできるようにするには、これらのコンポーネントをそれぞれ、データにバインドする必要があります。コンポーネントの外観は表示されるデータによって変わるからです。

ADF階層ビューア・コンポーネントは、リンクされた形状のセットとして階層データを表示した対話型グラフィックを生成します。形状とリンクはデータの要素と関係に対応します。たとえば、階層ビューア・コンポーネントを、従業員データに基づく組織図の生成に使用することができます。実行時、エンド・ユーザーはグラフィックをパンおよびズームし、このグラフィックが表示している管理階層を展開、選択、およびナビゲートすることができます。

ツリーマップとサンバーストを使用して、定量的な階層データをサイズと色で視覚的に表現し、2つの次元にまたがり表示します。ツリーマップおよびサンバーストでは、nodeと呼ばれる形を使用して、階層内のデータを表します。たとえば、ツリーマップまたはサンバーストを使用して地域の四半期ごとの売上げを表示し、売上げ傾向を特定する場合は、ノードのサイズで各地域の売上げ高を示し、ノードの色でその地域の売上げが四半期で増えたか減ったかを示すことができます。ノードの外観とコンテンツは、階層の各レベルで構成可能です。

接頭辞dvt:は、各データ視覚化コンポーネント名の先頭に付いて、そのコンポーネントがADFデータ視覚化ツール(DVT)のタグ・ライブラリに属することを示します。

43.1.1 エンド・ユーザー機能およびプレゼンテーション機能

魅力的な外観を備えたデータ視覚化コンポーネントを使用すると、エンド・ユーザーは複雑なビジネス・データを理解して分析できるようになります。このコンポーネントは機能が豊富で、そのまますぐに使用できる対話型のサポートも用意されています。エンド・ユーザーの詳細な説明と各コンポーネントのプレゼンテーション機能の詳細は、次を参照してください。

- 階層ビューア・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のエンド・ユーザー機能とプレゼンテーション機能に関する項。

- ツリーマップおよびサンバースト・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のツリーマップおよびサンバーストのエンド・ユーザー機能とプレゼンテーション機能に関する項。

43.1.2 データ視覚化コンポーネントのユースケースと例

データ視覚化コンポーネントのユースケースと例の詳細は、次を参照してください。

- 階層ビューア・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の階層ビューアのユースケースと例に関する項。

- ツリーマップおよびサンバースト・コンポーネント: 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のツリーマップおよびサンバーストのユースケースと例に関する項。

43.1.3 データ視覚化コンポーネントの追加機能

データ視覚化コンポーネントをデータ・バインドする前に、その他のOracle ADF機能について理解しておいてください。また、いったんデータ視覚化コンポーネントをページに追加すると、検証やアクセシビリティなどの機能を追加する必要があることに気付く場合があります。データ視覚化コンポーネントで使用されるその他の機能へのリンクは、次のとおりです。

- 部分ページ・レンダリング: データ視覚化コンポーネントをリフレッシュして、ページの別のコンポーネントで実行されたアクションに基づく新しいデータを表示できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

- パーソナライズ: ユーザーは実行時にデータ視覚化コンポーネントの表示を変更できますが、ユーザーがカスタマイズできるようにアプリケーションを構成していないかぎり、ユーザーがページを終了するとそれらの値は保持されません。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「JSFページでのユーザー・カスタマイズの許可」を参照してください。

- アクセシビリティ: データ視覚化コンポーネントをアクセス可能にできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「アクセス可能なADF Facesページの開発」を参照してください。

- スキンおよびスタイル: アプリケーションに適用するADFスキンを使用するか、スタイル関連のプロパティ(styleClassまたはinlineStyle)を使用してCSSスタイル・プロパティを直接適用することで、データ視覚化コンポーネントの外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

- プレースホルダ・データ・コントロール: 最終的にページのデータ視覚化コンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールの使用を検討します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

43.2 データバインドされた階層ビューアの作成

階層ビューアは、データ内に親子関係の存在するデータを視覚的に表現するADFデータ視覚化コンポーネントです。組織図、ネットワーク・ダイアグラム、ソーシャル・ネットワークや類似の視覚的表現を表示する場合には、このコンポーネントが有益です。

階層ビューアでは、ノードと呼ばれる形状を使用して、階層内のデータを参照します。ノードの形状とコンテンツは、ノードの視覚的レイアウトと同様に構成可能です。ノードは、1つのパネル・カード内に複数のビューを表示できます。

図43-1に、組織図をレンダリングする階層ビューア・コンポーネントの実行時ビューを示します。

図43-1 組織図をレンダリングする階層ビューア・コンポーネント

作成する階層ビューア・コンポーネント(dvt:hierarchyViewer)はそれぞれ次の要素を持つことができます。

- 1つ以上のノード要素(dvt:node)

- 1つ以上のリンク要素(dvt:link)

階層ビューア・コンポーネントとともに、必要に応じて、カード要素(dvt:panelCard)を使用することもできます。パネル・カードは、アニメーションを使用して、ノード要素で参照される複数のコンテンツ・セットを動的に切り替える方法を提供します。たとえば、コンテンツを水平方向にスライドさせたり、ノードをめくったりできます。

階層ビューアのエンド・ユーザー機能とプレゼンテーション機能、ユースケース、タグ構造、階層ビューアへの特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「階層ビューア・コンポーネントの使用方法」を参照してください。

43.2.1 ADFデータ・コントロールを使用して階層ビューアを作成する方法

階層ビューアは、1つ以上のディテール・コレクションと1つのマスター・データ・コレクションとの間にマスター/ディテール関係が存在するデータ・コレクションに基づいています。Oracle ADFのデータ・コントロールを使用すると、JDeveloperでは宣言的なタスクとなります。「データ・コントロール」パネルから、1つ以上のルート・ノードを生成するデータ・コレクションをドラッグして、JSFページにドロップします。

始める前に:

データバインドされた階層ビューアについて理解しておいてください。詳細は、「データバインドされた階層ビューアの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従い、階層ビューアのデータ・モデルで必要になる、ビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。
たとえば、図43-1に示す階層ビューアのデータソースは、ADF DVTコンポーネントについてのSummitサンプル・アプリケーションで従業員を表す1つの表から取得しています。Summit ADF DVTサンプルアプリケーションで、SEmp表を使用して管理者と従業員との間の階層関係を設定し、最上位レベルの従業員を階層のルートとして設定するには、次の手順を実行します。

1. SEmp表に基づくエンティティ・オブジェクトを作成します。
図43-2は、SEmp表に基づいたSEmpエンティティ・オブジェクトです。この表内の各行には、従業員のIDと従業員の管理者IDの両方が含まれています。エンティティ・オブジェクトの作成についての説明が必要な場合は、「エンティティ・オブジェクトおよびアソシエーションの作成」を参照してください。

図43-2 Summit ADF DVTサンプル・アプリケーションのSEmpエンティティ・オブジェクト

2. SEmp.IdとSEmp.ManagerIDのアソシエーションを作成し、従業員と管理者との間の関係を確立します。
図43-3に、Summit ADF DVTサンプル・アプリケーションのSEmpManagerIdFkAssocアソシエーションを示します。この例では、SEmpエンティティ・オブジェクトの作成時に、アソシエーションが自動的に作成されます。アソシエーションの詳細は、「エンティティ・オブジェクトおよびアソシエーションの作成」を参照してください。

図43-3 Summit ADF DVTサンプル・アプリケーションでの管理者と従業員との間のアソシエーション

3. 管理者と従業員との間の階層を確立するには、SEmpManagerIdFkAssocアソシエーションに基づいて、管理者と従業員との間にビュー・リンクを作成します。
図43-4に、Summit ADF DVTサンプル・アプリケーションのSEmpManagerIDFKLinkビュー・リンクを示します。ビュー・リンクを使用して、マスター/ディテール関係を確立する方法の詳細は、「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」を参照してください。

図43-4 Summit ADF DVTサンプル・アプリケーションでの管理者と従業員との間のビュー・リンク

4. SEmpManagerIDFKLinkを使用するには、管理者を従業員に結び付ける新しいビュー・オブジェクトを作成します(図43-5を参照)。

図43-5 Summit ADF DVTサンプル・アプリケーションの管理者/従業員ビュー・オブジェクト

5. データ・コレクションからルート値を取得するビュー・オブジェクトを作成します。
たとえば、Summit ADF DVTサンプル・アプリケーションでは、Carmen Velasquezは、従業員IDが1の最上位レベルの管理者です。Summit ADF DVTサンプル・アプリケーションに基づいたビュー・オブジェクトを作成する場合は、IDが1の従業員を取得するビュー・オブジェクトを作成します。

図43-6に、Summit ADF DVTサンプル・アプリケーションのRootEmployeeViewObjectを示します。問合せで、IDが1の従業員を取得して、その従業員をrootEmpnoバインド変数に格納します。ビュー・オブジェクトおよびバインド変数の使用の詳細は、「バインド変数の使用」を参照してください。

図43-6 階層ビューアのRootEmployeeViewObjectサンプル

6. ルートの従業員と下位レベルの管理者および従業員との間の階層を確立するには、RootEmployeeViewObjと、手順4で作成した管理者/従業員ビュー・オブジェクトとの間にビュー・リンクを追加します。

図43-7 Summit ADF DVTサンプル・アプリケーションのRootEmployeesViewLink

7. 「データ・コントロール」パネルで「リフレッシュ」アイコンをクリックして、データ・コントロールを更新します。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

「データ・コントロール」パネルを使用して階層ビューアを作成する手順は次のとおりです。

1. 「データ・コントロール」パネルから、コレクションを選択します。
図43-8に、「データ・コントロール」パネルでRootEmployeeViewObj2コレクションを選択して、従業員データを組織図で表す階層ビューアを作成する例を示します。

図43-8 組織図の従業員のデータ・コレクション

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「階層ビューア」を選択します。

3. 「コンポーネント・ギャラリ」で、作成する階層ビューアのレイアウトを選択します。図43-9に、上から下の垂直方向レイアウトが選択されたコンポーネント・ギャラリを示します。

図43-9 階層ビューアのコンポーネント・ギャラリ

4. 「階層ビューアの作成」ダイアログで、次のように入力します。

- 「階層」: 実行時のダイアグラムにノードとして含めるコレクションを選択します。デフォルトでは、ルート・コレクションが選択されます。階層内の上位オブジェクトまたは下位オブジェクトを構成することもできます。

- 「ノード」: 「階層」リストで選択したコレクションごとに、利用可能なズーム・レベルを1つ以上使用して、タイトル・エリアで属性を、各パネル・カードでタイトルと属性を構成します。デフォルトでは、ズーム・レベルが100%のノードは次のアルゴリズムに準拠します。

- データ・コレクションの最初の3つの属性をタイトル・エリアに割り当てます。

- 次の2つの属性を最初のパネル・カードに割り当てます。

- 次の2つの属性を2つ目のパネル・カードに割り当てます。

パネル・カードのタイトルまたはノードの属性を選択して、次に示す1つ以上の要素を構成します。

- テキスト: パネル・カードのタイトルに使用できます。タイトル・エリア要素には使用できません。階層のパネル・カード・タイトルにテキストを入力するか、ドロップダウン・リストから「テキスト・リソースの選択」を選択して、該当のタイトルに使用するテキスト・リソースを選択または追加します。テキスト・リソースは、アプリケーション・リソース・バンドルからの翻訳可能な文字列です。ヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

- パネル・カード・データ・ソース: パネル・カードに使用できます。データ・ソースは、パネル・カードの属性に使用されるデータ・コレクションを意味します。デフォルトでは、現在の階層レベルに関連付けられたコレクションが、属性の選択に使用されます。
図43-10は、Summit ADFスキーマに基づいたデータ・コレクションを使用した階層ビューアの「階層ビューアの作成」ダイアログを示しています。この例では、「パネル・カード・データ・ソース」は、デフォルトのSEmpViewコレクションです。

図43-10 デフォルトのパネル・カード・データ・ソースで構成した階層ビューア

パネル・カード属性に対する代替の子アクセッサを使用するには、ドロップダウン・リストから代替の子アクセッサを選択します(図43-11を参照)。詳細は、「データバインドされたパネル・カード用に代替ビュー・オブジェクトを構成する方法」を参照してください。

図43-11 代替のパネル・カード・データ・ソースを示す「階層ビューアの作成」ダイアログ

- 「コンポーネント」: 属性に使用可能です。ノードにデータを表示するために使用するコンポーネントのタイプを選択します。有効な値は、「ラベル付ADF出力テキスト」、「ADF出力テキスト」、「ラベル付ADF出力フォーマット済」およびADF出力フォーマット済テキストです。これらのコンポーネントの使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「出力コンポーネントの使用方法」を参照してください。

- 「属性」: 属性要素とイメージ要素に使用可能です。ドロップダウン・リストから、階層ビューアのノードに表示する値を表すデータ・コレクションの属性を選択します。

- ラベル: 「コンポーネント」フィールドのドロップダウン・リストから「ラベル付出力テキスト」またはラベル付ADF出力フォーマット済テキスト・コンポーネントを選択した場合に、属性に使用できます。デフォルトの「属性名の使用」を使用すると、基礎となるViewObjectのその属性にUIHintsのラベルを使用して値を文字列としてレンダリングできます。属性のドロップダウン・メニューから「ラベルなし」を選択して、属性にラベルをレンダリングしないことを選択したり、「テキスト・リソースの選択」を選択して「テキスト・リソースの選択」ダイアログを開き、ラベルに使用するテキスト・リソースを選択または追加できます。テキスト・リソースは、アプリケーション・リソース・バンドルからの翻訳可能な文字列です。

「新規」アイコンをクリックし、ノードの選択に応じて、新しいパネル・カード、属性またはイメージをノードに追加します。既存の要素を選択したら、矢印アイコン(上へ、下へ、一番上、一番下)を使用して要素を並べ替えるか、「削除」アイコンを使用して選択した要素を削除します。

ズーム・レベルが75%、50%および25%のページを使用して、各ページ・レベルでの階層の展開表示を指定します。「ズーム・レベルの追加」を選択して、ページ・レベルのズーム・レベルを有効にします。デフォルトでは、ノード属性とパネル・カードをノードに割り当てるアルゴリズムは、100%のズーム・レベルの場合と同様です。

注意:

階層ビューア・コンポーネントは4種類のズーム・レベルを定義します。これらのズーム・レベルを変更したり、新しいズーム・レベルを作成したりすることはできません。デフォルトのズーム・レベルは100%です。

- 「サンプル」: 階層ビューア・ノードのサンプル・アウトラインの構成不能な表示です。タイトル・エリアなどのエリアや属性は、ノード・エリアで選択されている場合にはサンプルで強調表示されます。

5. 「OK」をクリックします。

図43-12は、RootEmployeeViewObj2という名前のデータ・コレクションのデータを使用して階層ビューアのルート・レベルについて完成した「階層ビューアの作成」ダイアログを示しています。

図43-12 「階層ビューアの作成」ダイアログ

「階層ビューアの作成」ダイアログに必要事項を入力した後で、「プロパティ」ウィンドウを使用して階層ビューア属性の設定を指定できます。また、階層ビューア・タグに関連付けられた子タグを使用して、さらに階層ビューアをカスタマイズすることもできます。階層ビューアのエンド・ユーザー機能とプレゼンテーション機能、ユースケース、タグ構造、階層ビューアへの特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「階層ビューア・コンポーネントの使用方法」を参照してください。

階層ビューアをビジュアル・エディタで編集する場合は、その表示は実行時の表示と機能とほぼ同じになります。「構造」ウィンドウの属性を並べ替えたり、属性を「データ・コントロール」パネルから「構造」ウィンドウにドラッグ・アンド・ドロップして新しい属性をバインドできます。

43.2.2 データバインドされた階層ビューアの作成時の処理

階層ビューアを「データ・コントロール」パネルから作成すると、次の処理が行われます。

- JSFページのページ定義ファイルで階層ビューアのバインディングを作成

- 階層ビューア・コンポーネントのJSFページに必要なタグを追加

次の例は、階層ビューア・コンポーネントについてJDeveloperにより生成されたバインディングを表示します。マスター/ディテール・ツリーのノードにデータを移入するためのルールは、ノード定義として定義されます。次の例では、2つのノード定義が生成されます。これらのノード定義はそれぞれ、ビュー・オブジェクト1つとそれに関連する属性を参照しています。また、このコード例はアクセッサ(SEmpView)も参照しています。

<parameters/>
<executables>
<variableIterator id="variables"/>
<iterator Binds="RootEmployeeViewObj2" RangeSize="25"
DataControl="AppModuleDataControl"
id="RootEmployeeViewObj2Iterator"/>
</executables>
<bindings>
<tree IterBinding="RootEmployeeViewObj2Iterator" id="RootEmployeeViewObj2">
<nodeDefinition DefName="model.RootEmployeeViewObj"
Name="RootEmployeeViewObj20">
<AttrNames>
<Item Value="ManagerId"/>
<Item Value="TitleId"/>
<Item Value="Userid"/>
<Item Value="Comments"/>
<Item Value="DeptId"/>
<Item Value="StartDate"/>
<Item Value="Email"/>
<Item Value="Salary"/>
<Item Value="FirstName"/>
<Item Value="Id"/>
<Item Value="CommissionPct"/>
<Item Value="LastName"/>
</AttrNames>
<Accessors>
<Item Value="SEmpView">
<Properties>
<CustomProperties>
<Property Name="hierarchyType" Value="children"/>
</CustomProperties>
</Properties>
</Item>
</Accessors>
</nodeDefinition>
<nodeDefinition DefName="model.SEmpView" Name="RootEmployeeViewObj21">
<AttrNames>
<Item Value="ManagerId"/>
<Item Value="TitleId"/>
<Item Value="Userid"/>
<Item Value="Comments"/>
<Item Value="DeptId"/>
<Item Value="StartDate"/>
<Item Value="Email"/>
<Item Value="Salary"/>
<Item Value="FirstName"/>
<Item Value="Id"/>
<Item Value="CommissionPct"/>
<Item Value="LastName"/>
</AttrNames>
<Accessors>
<Item Value="SEmpView">
<Properties>
<CustomProperties>
<Property Name="hierarchyType" Value="children"/>
</CustomProperties>
</Properties>
</Item>
</Accessors>
</nodeDefinition>
</tree>
</bindings>

次の例は、上の例のページ定義ファイルに関連付けられているJSFページに生成されるコードを示しています。簡潔にするために、zoom75、zoom50およびzoom25という名前のファセット要素の詳細と、パネル・カードのshowDetailItemコンポーネントの詳細は省略しています。また、階層ビューアの2番目のノードに関する詳細も省略しています。

この例は、RootEmployeeViewObj2ツリー・バインディングを参照する階層ビューア・コンポーネントを示しています。これには、ノード(dvt:node)コンポーネントが含まれ、このコンポーネントにはパネル・カード・コンポーネント(dvt:panelCard)が含まれます。このパネル・カード・コンポーネントは、ノードにより参照されたコンテンツの表示を変更するときに使用されるエフェクトとして、slide_horzを定義しています。

階層ビューアを作成すると、図43-12に示す「階層の作成」ダイアログを使用して、コンポーネントのレイアウトを変更したり、パネル・カードなどのコンポーネントをさらに追加できます。このダイアログを開くには、hierarchyViewerコンポーネントの「プロパティ」ウィンドウで、「編集」アイコンをクリックします。また、ビジュアル・エディタで階層ビューア・コンポーネントのコードを直接編集するか、「プロパティ」ウィンドウで値を設定して、レイアウトをカスタマイズすることもできます。「コンポーネント」ウィンドウを使用すると、パネル・カードなどの別のコンポーネントを追加できます。

<dvt:hierarchyViewer id="hv1" var="node"
value="#{bindings.RootEmployeeViewObj2.treeModel}"
selectionListener="#{bindings.RootEmployeeViewObj2.treeModel.makeCurrent}"
detailWindow="none" layout="hier_vert_top"
levelFetchSize="#{bindings.RootEmployeeViewObj2.rangeSize}"
styleClass="AFStretchWidth" summary="Hierarchy Viewer Demo">
<dvt:link linkType="orthogonalRounded" id="l1"/>
<dvt:node type="model.RootEmployeeViewObj" width="233" height="233" id="n1">
<f:facet name="zoom100">
<af:panelGroupLayout styleClass="AFStretchWidth AFHVNodeStretchHeight
AFHVNodePadding"
layout="vertical" id="pgl1">
<af:panelGroupLayout layout="horizontal" id="pgl2">
<af:panelGroupLayout id="pgl7">
<af:image source="/images/#{node.Id}.png" shortDesc="Employee Image"
id="i1" styleClass="AFHVNodeImageSize"/>
</af:panelGroupLayout>
<af:panelGroupLayout layout="vertical" id="pgl3">
<af:outputText value="#{node.LastName}"
shortDesc="#{bindings.RootEmployeeViewObj2.hints.LastName.tooltip}"
styleClass="AFHVNodeTitleTextStyle" id="ot1"/>
<af:outputText value="#{node.FirstName}"
shortDesc="#{bindings.RootEmployeeViewObj2.hints.FirstName.tooltip}"
styleClass="AFHVNodeSubtitleTextStyle" id="ot2"/>
<af:panelLabelAndMessage
label="#{bindings.RootEmployeeViewObj2.hints.Id.label}"
styleClass="AFHVNodeLabelStyle" id="plam1">
<af:outputText value="#{node.Id}"
shortDesc="#{bindings.RootEmployeeViewObj2.hints.Id.tooltip}"
styleClass="AFHVNodeTextStyle" id="ot3">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.RootEmployeeViewObj2.hints.Id.format}"/>
</af:outputText>
</af:panelLabelAndMessage>
</af:panelGroupLayout>
</af:panelGroupLayout>
<af:spacer height="5" id="s1"/>
<dvt:panelCard effect="slide_horz" styleClass="AFHVNodePadding" id="pc1">
<af:showDetailItem text="Contact Details" id="sdi1">
<af:spacer height="2" id="s2"/>
<af:panelFormLayout styleClass="AFStretchWidth AFHVNodeStretchHeight
AFHVNodePadding"
id="pfl1">
<af:panelLabelAndMessage
label="#{bindings.RootEmployeeViewObj2.hints.Email.label}"
styleClass="AFHVPanelCardLabelStyle" id="plam2">
<af:outputText value="#{node.Email}"
shortDesc="#{bindings.RootEmployeeViewObj2.hints.Email.tooltip}"
styleClass="AFHVPanelCardTextStyle" id="ot4"/>
</af:panelLabelAndMessage>
<af:panelLabelAndMessage
label="#{bindings.RootEmployeeViewObj2.hints.Userid.label}"
styleClass="AFHVPanelCardLabelStyle" id="plam3">
<af:outputText value="#{node.Userid}"
shortDesc="#{bindings.RootEmployeeViewObj2.hints.Userid.tooltip}"
styleClass="AFHVPanelCardTextStyle" id="ot5"/>
</af:panelLabelAndMessage>
</af:panelFormLayout>
</af:showDetailItem>
... remaining showDetailItem panel card details omitted
</dvt:panelCard>
</af:panelGroupLayout>
</f:facet>
... remaining zoom levels omitted
</dvt:node>
<dvt:node type="model.SEmpView" width="233" height="233" id="n2">
... second node details are similar to first node and are omitted
</dvt:node>
</dvt:hierarchyViewer>

43.2.3 データバインドされたパネル・カード用に代替ビュー・オブジェクトを構成する方法

データバインドされた階層ビューアを作成または編集するときには、パネル・カードのデータ・ソースとして、代替ビュー・オブジェクトを指定できます。たとえば、販売責任者と注文との間のマスター/ディテール関係を含むデータ・コレクションがあるときに、注文を発注した顧客の詳細を表示するパネル・カードが必要になることがあります。

図43-13に、階層ビューアの実行時ビューの一部を示します。この階層ビューアは、Summit ADFスキーマを使用して、販売責任者に対する注文と注文の詳細を表示するように構成されています。この例では、Customer Detailsパネル・カードに対して代替ビュー・オブジェクトを使用するように、階層ビューアを構成しています。

図43-13 代替ビュー・オブジェクトを使用して構成した階層ビューアのパネル・カード

代替ビュー・オブジェクトは、親コレクションの子にする必要があります。この親子関係を確立するには、親コレクションと子コレクションとの間にビュー・リンクを作成します。

始める前に:

データバインドされた階層ビューアについて理解しておいてください。詳細は、「データバインドされた階層ビューアの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

「アプリケーション・モジュールの作成と変更」の説明に従い、アプリケーションに必要なエンティティとビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。

階層ビューア用のデータ・モデルを作成します。たとえば、図43-13の階層ビューアでは、Summit ADF DVTサンプル・アプリケーションのSEmpエンティティに基づく、最上位レベルのビュー・オブジェクトを使用しています。この例では、Summit ADF従業員データベースに含まれるすべての販売責任者をビュー・オブジェクトで取得するために、TITLE_IDが2である従業員レコードをすべて取得しています。図43-14に、SalesRepViewObjビュー・オブジェクトを示します。

図43-14 Summit ADFスキーマを使用した販売責任者ビュー・オブジェクト

ビュー・オブジェクトの作成の詳細は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。

Summitの販売責任者と注文との間のマスター/ディテール関係は、SalesRepViewObjとOrdersViewObjとの間のビュー・リンクで確立されます。図43-15は、ビュー・オブジェクト間の関係を示しています。

図43-15 Summitの販売責任者と注文との間のビュー・リンク

ビュー・リンクを使用して、マスター/ディテール関係を確立する方法の詳細は、「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」を参照してください。

データバインドされたパネル・カード用に代替ビュー・オブジェクトを構成するには:

1. パネル・カードの代替データ・ソースにするビュー・オブジェクトを作成します(まだ作成していない場合)。
たとえば、図43-13の階層ビューアでは、Summit ADF DVTサンプル・アプリケーションのSCustomerエンティティ・オブジェクトに基づいたビュー・オブジェクトを使用しています。

2. 親コレクションと代替ビュー・オブジェクトとの間にビュー・リンクを作成します。
図43-16に、Summit ADF DVTサンプル・アプリケーションでの販売責任者と顧客との間のビュー・リンクを示します。ビュー・リンクの作成についての説明が必要な場合は、「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」を参照してください。

図43-16 Summit ADF DVTサンプル・アプリケーションでの販売責任者と顧客との間のビュー・リンク

3. 必要に応じて、親コレクションと代替の子コレクションとの間の階層を確立するためのビュー・リンクを作成します。
たとえば、Summit ADF DVTサンプル・アプリケーションで、注文と顧客との階層を確立するには、SOrdViewコレクションとSCustomerViewコレクションとの間にビュー・リンクを作成します。図43-17に、ビュー・リンクの例を示します。

図43-17 Summit ADF DVTでの注文と顧客との間のビュー・リンク

43.2.3.1 階層ビューアのパネル・カードに代替ビュー・オブジェクトを使用する場合の処理

パネル・カード・データソースに代替ビュー・オブジェクトを使用するように階層ビューアを構成すると、JDeveloperにより、階層ビューアと代替ソースのバインディングがJSFページのページ定義ファイルに追加されます。

次の例は、図43-13に表示される階層ビューアのサンプル・バインディングを示します。代替ソースのエントリは強調表示されています。代替データ・ソースは、階層ビューアのノード定義の1つとして定義されている点に注目してください。

<bindings>
<tree IterBinding="SalesRepViewObj2Iterator" id="SalesRepViewObj2">
<nodeDefinition DefName="model.SalesRepViewObj" Name="SalesRepViewObj20">
<AttrNames>
<Item Value="ManagerId"/>
<Item Value="TitleId"/>
<Item Value="Userid"/>
<Item Value="Comments"/>
<Item Value="DeptId"/>
<Item Value="StartDate"/>
<Item Value="Email"/>
<Item Value="Salary"/>
<Item Value="FirstName"/>
<Item Value="Id"/>
<Item Value="CommissionPct"/>
<Item Value="LastName"/>
</AttrNames>
<Accessors>
<Item Value="SOrdView">
<Properties>
<CustomProperties>
<Property Name="hierarchyType" Value="children"/>
</CustomProperties>
</Properties>
</Item>
</Accessors>
</nodeDefinition>
<nodeDefinition DefName="model.SOrdView" Name="SalesRepViewObj21">
<AttrNames>
<Item Value="DateShipped"/>
<Item Value="DateOrdered"/>
<Item Value="Id"/>
<Item Value="Total"/>
</AttrNames>
<Accessors>
<Item Value="SItemView">
<Properties>
<CustomProperties>
<Property Name="hierarchyType" Value="children"/>
</CustomProperties>
</Properties>
</Item>
<Item Value="SCustomerView"/>
</Accessors>
</nodeDefinition>
<nodeDefinition DefName="model.SCustomerView" Name="SalesRepViewObj22">
<AttrNames>
<Item Value="Name"/>
<Item Value="Phone"/>
<Item Value="City"/>
</AttrNames>
</nodeDefinition>
<nodeDefinition DefName="model.SItemView" Name="SalesRepViewObj23">
<AttrNames>
<Item Value="QuantityShipped"/>
<Item Value="ItemId"/>
<Item Value="Quantity"/>
<Item Value="Price"/>
<Item Value="OrdId"/>
<Item Value="ProductId"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

43.2.4 階層ビューアでのデータバインドされた検索の作成方法

階層ビューアの検索機能は、階層ビューア・データ・モデルの基本であるデータ・コレクションの検索可能属性または列に基づいています。Oracle ADFのデータ・コントロールで定義されている問合せ結果コレクションを使用して、JDeveloperではこれが宣言的タスクになります。ExecuteWithParams操作をドラッグして、このページの既存の階層ビューア・コンポーネントにドロップします。

図43-18に、従業員を姓で検索するように構成された、Summit ADF DVTの従業員階層ビューアを示します。この例では、「検索」パネルに従業員の姓を入力することも、%または_を使用してパターン一致を指定することもできます。

図43-18 階層ビューアと検索パネル

始める前に:

データバインドされた階層ビューアについて理解しておいてください。詳細は、「データバインドされた階層ビューアの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

1. 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。

2. 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

3. 「ADFデータ・コントロールを使用して階層ビューアを作成する方法」の説明に従い、データバインドされた階層ビューア・コンポーネントを作成します。

4. 階層ビューアのルート・ノードを取得する問合せを検証します。
たとえば、図43-6では、Id列でルート・ノードを取得して、ルート・ノードをrootEmpnoバインド変数に格納しています。

5. 検索を実行するビュー・オブジェクトを作成します。
たとえば、図43-19はEmployeesSearchResultsビュー・オブジェクトを示しています。このオブジェクトは、任意の値と一致させるためのデフォルト値の%と、パターン一致を有効にする比較値のlikeを使用して、データ・コレクションのLastName列に基づいた検索を実行します。

図43-19 EmployeeSearchResultsビュー・オブジェクト

ビュー・オブジェクトの作成の詳細は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。

階層ビューアでデータバインドされた検索を作成する手順:

1. 「データ・コントロール」パネルから、問合せ結果に対応するコレクションを選択し、「操作」ノードを展開してExecuteWithParams操作を表示します。
図43-20では、Summit ADF DVTサンプル・アプリケーションのEmployeeSearchResults1操作ノードが開かれています。

図43-20 階層ビューア検索のExecuteWithParams操作の例

2. ExecuteWithParams操作をドラッグして、ビジュアル・エディタの階層ビューア、または「構造」ウィンドウのコンポーネント上にドロップします。

3. 「階層ビューア検索の作成」ダイアログで、「追加」アイコンを使用して「検索結果」パネルに表示する結果リストを指定し、それぞれの結果に対して次の指定を行います。

a. ラベルの表示: 階層内のノードのヘッダー値を選択します。<default>を選択すると、ヘッダーのテキストはデータ・バインディングから自動的に取得されます。

b. 値バインディング: 階層ビューアのツリーにあるノードに使用するデータ・コレクション内の列を選択します。

c. 使用するコンポーネント: ノードに表示するコンポーネントのタイプを選択します。デフォルトは、ADF出力テキスト・コンポーネントです。

既存のフィールドの選択後、矢印アイコン(Up、Down、Top、Bottom)を使用して、結果を並べ替えるか、または「削除」アイコンを使用して、結果を削除します。

4. 「操作」ドロップダウン・リストで、検索結果が選択されたときに使用する階層ルート・データ・コレクションを選択します。有効な値には、次のものがあります。

- removeRowWithKey: 入力フィールドによって指定された値から変換されたStringとして行キーを使用し、バインドされたデータ・コレクションのデータ・オブジェクトを削除します。

- setCurrentRowWithKey: 入力フィールドで指定された値から変換したStringとして行キーを設定します。行キーは、バインドされたデータ・コレクション内のデータ・オブジェクトの現状設定に使用されます。

- setCurrentRowWithKeyValue: キーの値を使用して、イテレータの現在のオブジェクトを設定します。

- ExecuteWithParams: パラメータとして渡される名前付きバインド変数に値を設定します。

5. 「パラメータ・マッピング」表で、「結果属性」列のドロップダウン・リストを使用して、「階層パラメータ」列に表示されるパラメータにマップする結果コレクション属性を選択します。

図43-21は、EmployeesSearchResults1という名前のデータ・コレクションのデータを使用して階層ビューアを作成したときに表示される「階層ビューア検索の作成」ダイアログです。

図43-21 「階層ビューア検索の作成」ダイアログ

次の例は、「OK」をクリックすることで、階層ビューア・コンポーネントの子としてdvt:searchが追加された後のJSFページのコードを示しています。

<dvt:search value="#{bindings.searchName.inputValue}"
actionListener="#{bindings.ExecuteWithParams.execute}" id="s19">
<f:facet name="end">
<af:link text="Advanced" styleClass="AFHVAdvancedSearchLinkStyle" id="l1"/>
</f:facet>
<dvt:searchResults id="sr1"
value="#{bindings.EmployeeSearchResults.collectionModel}"
emptyText="#{bindings.EmployeeSearchResults.viewable ?
'No data to display.' : 'Access Denied.'}"
fetchSize="#{bindings.EmployeeSearchResults.rangeSize}"
resultListener="#{bindings.ExecuteWithParams1.execute}"
var="resultRow">
<af:setPropertyListener type="action" from="#{resultRow.Id}"
to="#{bindings.rootEmpno.inputValue}"/>
<f:facet name="content">
<af:panelGroupLayout layout="horizontal" id="pgl27">
<af:panelLabelAndMessage
label="#{bindings.ExecuteWithParams.hints.LastName.label}"
id="plam29">
<af:outputText value="#{resultRow.LastName}"
shortDesc="#{bindings.ExecuteWithParams.hints.LastName.tooltip}"
id="ot45"/>
</af:panelLabelAndMessage>
<af:panelLabelAndMessage
label="#{bindings.ExecuteWithParams.hints.FirstName.label}"
id="plam30">
<af:outputText value="#{resultRow.FirstName}"
shortDesc="#{bindings.ExecuteWithParams.hints.FirstName.tooltip}"
id="ot46">
<af:convertNumber groupingUsed="false"
pattern="#{bindings.ExecuteWithParams.hints.FirstName.format}"/>
</af:outputText>
</af:panelLabelAndMessage>
</af:panelGroupLayout>
</f:facet>
</dvt:searchResults>
</dvt:search>

実行時に、検索結果は、1つの表にLastNameとFirstNameで表示されます。図43-22は、ユーザーがC%と入力して、姓がCで始まるすべての従業員を検索した場合の検索結果パネルを示しています。

図43-22 階層ビューアの検索結果パネル

ユーザーは、検索結果のいずれかを選択して、その結果に関連する階層ビューアのノードと子ノード(存在する場合)を表示できます。図43-23は、ユーザーが検索結果のリストからCatchpoleを選択した場合に示される階層ビューアのノードです。

図43-23 検索後に選択したノードを示す階層ビューア

43.3 データバインドされたツリーマップおよびサンバーストの作成

ツリーマップおよびサンバーストは、サイズと色で視覚的に表された、2つの次元にまたがる定量的階層データを表示するADFデータ視覚化コンポーネントです。たとえば、ツリーマップまたはサンバーストを使用して地域の四半期ごとの売上げを表示し、売上げ傾向を特定する場合は、ノードのサイズで各地域の売上げ高を示し、ノードの色でその地域の売上げが四半期で増えたか減ったかを示すことができます。

ツリーマップおよびサンバーストでは、nodeと呼ばれる形を使用して、階層内のデータを表します。ツリーマップはノードをネストした矩形のセットとして表示します。ツリーのブランチごとに1つの矩形が割り当てられ、そこにサブブランチを表すより小さな矩形が並べられます。

図43-24に、各倉庫での製品在庫を表示するSummit ADF DVTサンプル・アプリケーションのツリーマップを示します。この例では、ノードのサイズが各製品の在庫量を表し、ノードの色が在庫ステータスを表しています。

図43-24 製品の在庫状況とインベントリ・レベルを示すツリーマップ

サンバーストは、ノードを矩形レイアウトではなく、放射状に表示し、階層のトップを中心に、深いレベルになると中心から離れて表示します。図43-25に、地域と国ごとの注文数を示すために色を使用して地域および国ごとの売上を示すように構成されたサンバーストを示します。

図43-25 製品の在庫状況とインベントリ・レベルを示すサンバースト

ノードの形状とコンテンツは、ノードの視覚的レイアウトと同様に構成可能です。ツリーマップおよびサンバーストのエンド・ユーザー機能とプレゼンテーション機能、ユースケース、タグ構造、特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ツリーマップおよびサンバースト・コンポーネントの使用方法」を参照してください。

43.3.1 ADFデータ・コントロールを使用したツリーマップおよびサンバーストの作成方法

ツリーマップおよびサンバーストは、1つ以上のディテール・コレクションと1つのマスター・データ・コレクションとの間にマスター/ディテール関係が存在するデータ・コレクションに基づいています。ツリーマップおよびサンバーストでは、JDeveloperで次の属性も設定されている必要があります。

- value:ノードのサイズ

- fillColor:ノードの色

- label:ノードのテキスト識別子

valueおよびlabel属性の値は、ツリーマップあるいはサンバーストのデータ・モデルに保存する必要があり、UI-first開発を使用の場合は、クラスまたはマネージドBeanに保存する必要があります。fillColor値は、データ・モデル、クラスおよびマネージドBeanで指定するか、「プロパティ」ウィンドウで宣言的に指定できます。

ツリーマップあるいはサンバーストの構成を正常に行うには、データが次のルールに従うことを確認してください。

- 各子ノードは、親ノードを1つのみ持つことができます。

- レベルをスキップすることはできません。

Oracle ADFのデータ・コントロールを使用すると、JDeveloperではツリーマップとサンバーストの作成は宣言的なタスクとなります。「データ・コントロール」パネルから、1つ以上のノードを生成するデータ・コレクションをドラッグして、JSFページにドロップします。

始める前に:

データバインドされたツリーマップとサンバーストについて理解しておいてください。詳細は、「データバインドされたツリーマップおよびサンバーストの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、データ・モデルで必要なビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
マスター/ディテール関係の操作の詳細は、「マスター/ディテール・データの表示」を参照してください。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

「データ・コントロール」パネルを使用してツリーマップまたはサンバーストを作成するには:

1. 「データ・コントロール」パネルから、コレクションを選択します。

図43-26に、図43-24のツリーマップおよび図43-25のサンバーストに対するデータ・コレクションを示します。

図43-26 ツリーマップおよびサンバーストに対するサンプル・データ・コレクション

Summit ADF DVTサンプルの場合、アプリケーションは、SCountriesView2コレクションとSWarehouseView2コレクションの間のビュー・リンクを使用して、SRegionView1とSWarehouseView2のデータ・コレクションとの間の階層を確立します。図43-27に、ビュー・リンクの例を示します。

図43-27 国と倉庫との間のビュー・リンクの例

表43-1は、図43-24のツリーマップの作成に使用するデータ・コレクションと、サイズ値、ラベル値および色の値を示しています。

表43-1 ツリーマップ・インベントリの例に対するサンプル値

コレクション

サイズ値

ラベル値

色値

SRegionView1

CountryCount

Name

CountryCount

SCountriesView2

WarehouseCount

Country

WarehouseCount

SWarehouseView2

ProductCount

City

ProductCount

ProductInventoryView2

AmountInStock

Name

在庫レベルにより異なる

CountryCount、WarehouseCountおよびProductCount属性は、データ・コレクション内の国、倉庫および製品の数をカウントする一時属性です。たとえば、地域内の国の数は、地域のRegionIdと一致するSCountriesView子コレクションの一意のId値の数をカウントすることで計算されます。

SCountriesView.count('Id')

表43-2は、図43-25のサンバーストの作成に使用するデータ・コレクションと、サイズ値、ラベル値および色の値を示しています。

表43-2 サンバーストの売上の例に対するサンプル値

コレクション

サイズ値

ラベル値

色値

SRegionView1

TotalSales

Name

TotalOrders

SCountriesView2

TotalSales

Country

TotalOrders

TotalSalesおよびTotalOrders属性は、データ・コレクション内の各地域と国の合計売上高および注文数を計算する一時属性です。たとえば、地域の売上合計は、SCountriesViewコレクション内のTotalSalesを合計することで計算されます。

SCountriesView.sum ('TotalSales')

ビュー・オブジェクトへの一時属性の詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから「ツリーマップ」または「サンバースト」を選択します。

3. ツリーマップの作成または「サンバーストの作成」ダイアログの「階層」セクションで、実行時のツリーマップまたはサンバーストにノードとして含めるコレクションを選択します。デフォルトでは、ルート・コレクションが選択されます。

4. 「階層」リストで選択するコレクションごとに、次に対する値を入力します。

- 値: ドロップダウン・リストから、サンバーストのサイズ値を表すデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。「式ビルダー」ダイアログに関するヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。
たとえば、図43-26のデータ・コレクションを使用してツリーマップまたはサンバーストを作成するには、最初のノードに対するサイズ値を表すように、SRegionView1の値として「CountryCount」を選択します。

- ラベル: ドロップダウン・リストから、サンバースト・ノードのラベルとして表示するラベルを表すデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。
たとえば、SRegionView1ノード・ラベルに対して「Name」を選択します。

- オプションで、ビュー・エリア・セクションで「新規」をクリックして、ノードに対する属性グループを構成します。ノードの表示を色またはパターンに基づいて変えるには、属性グループを使用します。ツリーマップまたはサンバーストの作成後にノードのfillColorまたはfillPatternプロパティを使用して、ノードの塗りつぶしの色またはパターンを指定することもできます。
色を変えるように属性グループを構成したり、ノードに対してfillColor属性を指定したりしない場合は、ノードは黒で表示されます。デフォルトでは、ノードはパターンなしで表示されます。

ツリーマップとサンバーストの例では、階層のレベルごとに属性グループを構成しています。

属性グループを構成するには、次の値を入力します。

- 値でグループ化: ドロップダウン・リストから、属性グループをグループ化するためのデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。
ツリーマップの例で使用されている色は、階層のレベルごとの数のメトリックに基づきます。たとえば、SRegionView1コレクションの「値でグループ化」としてCountryCountを選択すると、「リージョン」ノードに表示される色数は、特定のリージョン内の国の数に応じて変化します。

サンバーストの例で使用されている色は、階層のレベルごとの数の注文数に基づきます。たとえば、SRegionView1コレクションの「値でグループ化」としてTotalOrdersを選択すると、「リージョン」ノードに表示される色数は、特定のリージョン内の注文の数に応じて変化します。

- エリア: ドロップダウン・リストから、属性グループを色で区別する場合は「色」を、属性グループをパターンで区別する場合は「パターン」を選択します。属性グループを色とパターンの両方で区別するには、「複数の属性の選択」を選択し、「色」と「パターン」の両方を選択します。「OK」をクリックします。
ツリーマップとサンバーストの例では、階層のレベルごとに色を使用しています。

- 凡例ラベル: ドロップダウン・リストから、ツリーマップの凡例に表示するデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。
ツリーマップとサンバーストの例では、この値は空のままになっています。

図43-28は、Summit ADF DVTサンプル・アプリケーションの最初のノード用に必要事項を入力したツリーマップの作成ダイアログです。

図43-28 リージョン・ノードに対する「ツリーマップの作成」ダイアログ

図43-29は、Summit ADF DVTサンプル・アプリケーションの最初のノード用に必要事項を入力した「サンバーストの作成」ダイアログです。

図43-29 リージョン・ノードに対する「サンバーストの作成」ダイアログ

- オプションで、「値固有のルール」をクリックして属性グループ・ダイアログを拡張し、一致ルールまたは例外ルールを指定します。一致ルールは、単純なtrueまたはfalse条件に対して色またはパターンを指定するか、特定の値に一致させたい場合に使用します。例外ルールは、ノードのグループ化値が特定の条件を満たす場合に色またはパターンを指定するときに使用します。
一致ルールを指定するには、「一致ルール」セクションで「新規」をクリックして、次の値を入力します。

- グループ値: 一致に対するカテゴリ値を入力します。カテゴリを表す文字列を入力するか、trueまたはfalseに設定できます。この値をtrueまたはfalseに設定する場合、「値でグループ化」フィールドには、次の例に示すように、trueまたはfalseに評価されるEL式(#{row.AmountInStock gt row.ReorderPoint}など)を指定する必要があります。

- プロパティ: ドロップダウン・リストから、ノードを色で区別する場合は「色」を、ノードをパターンで区別する場合は「パターン」を選択します。

- プロパティ値: ドロップダウン・リストから、ノードの値が「グループ値」に一致する場合に表示する色またはパターンを選択します。色については、提供されているいずれかの色を選択するか、「カスタム・カラー」を選択して「カスタム・カラーの選択」ダイアログでカスタム・カラーを指定できます。パターンについては、提供されているいずれかの値を選択する必要があります。

図43-30に、階層の一番下のレベルに対する一致ルールを使用するデータ・コレクションの「ツリーマップの作成」ダイアログを示します。

図43-30 属性グループに対する一致ルールを示すツリーマップ

この例では、ツリーマップ・ノードは、インベントリ・レベルが許容可能であれば緑(RGB 16進#008000)で表示され、インベントリ・レベルが製品の再発注レベル以下であれば赤(RGB 16進#ff0000)で表示されます。属性グループの「ラベル」フィールドには、凡例表示に対する詳細が含まれます。この場合、フィールドには項目の在庫数に基づいて凡例ラベルを決定する式(#{(row.AmountInStock gt row.ReorderPoint) ? 'Stock Level OK': 'Reorder Time'})が含まれます。

図43-31は、実行時のツリーマップを示します。

図43-31 実行時に一致ルールを示すツリーマップ

例外ルールを指定するには、「例外ルール」セクションで「新規」をクリックして、次の値を入力します。

- 条件: trueまたはfalseに評価されるJSF EL式を入力します。「条件」フィールドに式を直接入力するか、「式ビルダー」を選択してJSF EL式を入力できます。
Summit ADF DVTサンプル・アプリケーションでは、最下位レベルの階層に対して3つの例外ルールが定義されています。製品のインベントリ・レベルが再発注レベルを明らかに上回っている場合は、図43-24のツリーマップ・ノードと図43-25のサンバースト・ノードは緑で表示されます。ツリーマップとサンバースト・ノードは、インベントリ・レベルが再発注点に近い場合は黄色で、インベントリ・レベルが再発注点に達したか非常に近い場合は赤で表示されます。

図43-32に、最下位レベルの階層に対する例外ルールを使用する、Summit ADF DVTサンプル・データ・コレクションの「ツリーマップの作成」ダイアログを示します。

図43-32 例外ルールを示すツリーマップの作成ダイアログ

注意:

この例では、条件はデータ・コレクションのReorderPoint属性を参照しています。この属性を使用するには、ツリーマップの作成後にツリーマップのバインディングに手動で追加する必要があります。詳細は、「データバインドされたツリーマップまたはサンバーストの作成時の処理」を参照してください。

- プロパティ: ドロップダウン・リストから、ノードを色で区別する場合は「色」を選択します。ノードをパターンで区別する場合は「パターン」を選択します。

- プロパティ値: ドロップダウン・リストから、ノードの値が「条件」フィールドで指定した条件に一致する場合に表示する色またはパターンを選択します。色については、提供されているいずれかの色を選択するか、「カスタム・カラー」を選択して「カスタム・カラーの選択」ダイアログでカスタム・カラーを指定できます。パターンについては、提供されているいずれかの値を選択する必要があります。

- 凡例ラベル: 凡例ラベルにテキスト・リソースを使用するには、ドロップダウン・リストから「テキスト・リソースの選択」を選択します。このフィールドにテキストを入力するか、「式ビルダー」を選択してJSF EL式を入力することもできます。

5. 「OK」をクリックします。

43.3.2 データバインドされたツリーマップまたはサンバーストの作成時の処理

ツリーマップまたはサンバーストを「データ・コントロール」パネルから作成すると、次の処理が行われます。

- サンバーストまたはツリーマップに対するバインディングがJSFページのページ定義ファイルに作成されます。

- treemapまたはsunburstコンポーネントに必要なタグがJSFページに追加されます。

次の例に、図43-26のデータ・コレクションを使用してtreemapコンポーネントに対してJDeveloperが生成したバインディングを示します。

<executables>
<variableIterator id="variables"/>
<iterator Binds="SRegionView1" RangeSize="-1"
DataControl="AppModuleDataControl" id="SRegionView1Iterator"/>
</executables>
<bindings>
<tree IterBinding="SRegionView1Iterator" id="SRegionView1">
<nodeDefinition DefName="model.SRegionView" Name="SRegionView10">
<AttrNames>
<Item Value="CountryCount"/>
<Item Value="Name"/>
</AttrNames>
<Accessors>
<Item Value="SCountriesView"/>
</Accessors>
</nodeDefinition>
<nodeDefinition DefName="model.SCountriesView" Name="SRegionView11">
<AttrNames>
<Item Value="WarehouseCount"/>
<Item Value="Country"/>
</AttrNames>
<Accessors>
<Item Value="SWarehouseView"/>
</Accessors>
</nodeDefinition>
<nodeDefinition DefName="model.SWarehouseView" Name="SRegionView12">
<AttrNames>
<Item Value="ProductCount"/>
<Item Value="City"/>
</AttrNames>
<Accessors>
<Item Value="ProductInventoryView"/>
</Accessors>
</nodeDefinition>
<nodeDefinition DefName="model.ProductInventoryView" Name="SRegionView13">
<AttrNames>
<Item Value="Name"/>
<Item Value="AmountInStock"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

ツリーマップまたはサンバーストのノードにデータを移入するためのルールは、ノード定義で定義されています。この例は、階層の各レベルに対して1つずつ、合計で4つのノード定義が生成されたことを示しています。これらのノード定義はそれぞれ、ビュー・オブジェクト1つと「ツリーマップの作成」または「サンバーストの作成」ダイアログで指定された属性を参照します。階層の次のレベルが存在する場合は、各ノード定義では次のレベルに対するアクセッサも参照しています。

作成時に「値」、「名前」または「値でグループ化」フィールドで指定されていない属性は、バインディングに含まれません。データ・コレクションの別の属性を参照する必要がある場合は、バインディングに手動で追加する必要があります。たとえば、Summit ADF DVTサンプルでは、属性例外ルールは特定の製品の在庫量(AmountInStock)と再発注点(ReorderPoint)の差異に基づいて色を計算します。EL式を正しく評価するには、ReorderPoint属性をツリーマップまたはサンバーストのバインディング定義に追加する必要があります。

バインディングを追加するには、「構造」ウィンドウでdvt:treemapまたはdvt:sunburstコンポーネントを右クリックし、「バインディングに移動」を選択します。「バインディング」セクションで「編集」を選択し、ReorderPoint属性を追加します。図43-33に、ReorderPointが表示属性に追加された、Summit ADF DVTツリーマップについて完成した「ツリー・バインディングの編集」ダイアログを示します。

図43-33 「ツリー・バインディングの編集」ダイアログ

「OK」をクリックすると、バインディングが追加した属性で更新されます。次の例に、SRegionView13ノード定義の改訂したバインディングを示します。

<nodeDefinition DefName="model.ProductInventoryView" Name="SRegionView13">
<AttrNames>
<Item Value="Name"/>
<Item Value="AmountInStock"/>
<Item Value="ReorderPoint"/>
</AttrNames>
</nodeDefinition>

ツリーマップまたはサンバーストの作成後は、「ツリーマップの作成」ダイアログまたは「サンバーストの作成」ダイアログを使用して、各ノードの値、ラベルおよび属性グループを変更できます。このダイアログを開くには、treemapまたはsunburstコンポーネントに対する「プロパティ」ウィンドウの「編集」アイコンを使用します。また、値はコードで直接カスタマイズすることも、「プロパティ」ウィンドウで値を設定してカスタマイズすることもできます。

43.3.3 実行時に行われる処理: データバインドされたサンバーストまたはツリーマップの初期表示

デフォルトでは、サンバーストまたはツリーマップでは階層の最初の2つのレベルのみが表示され、サンバーストまたはツリーマップでlegendSource属性を構成するまでは凡例は表示されません。図43-34に、図43-26のデータ・コレクションを使用してツリーマップを作成した場合に実行時に表示されるツリーマップを示します。

図43-34 構成前のデータバインドされたツリーマップの例

「ツリーマップの作成」ダイアログまたは「サンバーストの作成」ダイアログに必要事項を入力した後で、「プロパティ」ウィンドウを使用して、ツリーマップまたはサンバーストのレベル表示と、legendSource属性を構成できます。その他のツリーマップまたはサンバースト属性に対する設定を指定し、サンバーストおよびツリーマップ・タグに関連付けられた子タグを使用してさらにサンバーストおよびツリーマップをカスタマイズすることもできます。

次の例に、図43-24のツリーマップに対するJSFページ・コード上のコードを示します。この例では、データバインドされたツリーマップは、階層内のすべてのレベル、凡例、ユーザーがノード上にマウスを移動した場合にはツールチップ、およびアクセシビリティのサマリーを表示するように構成されています。追加構成に関連するコードは太字フォントでハイライト表示されています。

<dvt:treemap id="t1" value="#{bindings.SRegionView1.treeModel}"
var="row" displayLevelsChildren="3"
legendSource="ag1" summary="Sample Treemap">
<af:switcher facetName="#{row.hierTypeBinding.name}" id="s1">
<f:facet name="SRegionView11">
<dvt:treemapNode value="#{row.WarehouseCount}" label="#{row.Country}"
id="tn1">
<dvt:attributeGroups id="ag2" value="#{row.WarehouseCount}" type="color"/>
</dvt:treemapNode>
</f:facet>
<f:facet name="SRegionView10">
<dvt:treemapNode value="#{row.CountryCount}" label="#{row.Name}" id="tn2">
<dvt:attributeGroups id="ag3" value="#{row.CountryCount}" type="color"/>
</dvt:treemapNode>
</f:facet>
<f:facet name="SRegionView13">
<dvt:treemapNode value="#{row.AmountInStock}" label="#{row.Name}" id="tn3"
shortDesc="Amount in Stock:
#{row.AmountInStock}&lt;br/>Reorder Point:
#{row.ReorderPoint}">
<dvt:attributeGroups value="#{row.AmountInStock}" type="color" id="ag1">
<dvt:attributeExceptionRule id="aer1"
condition="#{(row.AmountInStock -
row.ReorderPoint) gt 50}"
label="Stock OK">
<f:attribute name="color" value="#008800"/>
</dvt:attributeExceptionRule>
<dvt:attributeExceptionRule id="aer2"
condition="#{((row.AmountInStock - row.ReorderPoint) le 50) and
((row.AmountInStock - row.ReorderPoint) gt 25)}"
label="Stock Level Getting Low">
<f:attribute name="color" value="#FFFF33"/>
</dvt:attributeExceptionRule>
<dvt:attributeExceptionRule id="aer3"
condition="#{(row.AmountInStock - row.ReorderPoint) le 25}"
label="Reorder Time">
<f:attribute name="color" value="#880000"/>
</dvt:attributeExceptionRule>
</dvt:attributeGroups>
</dvt:treemapNode>
</f:facet>
<f:facet name="SRegionView12">
<dvt:treemapNode value="#{row.ProductCount}" label="#{row.City}" id="tn4">
<dvt:attributeGroups id="ag4" value="#{row.ProductCount}" type="color"/>
</dvt:treemapNode>
</f:facet>
</af:switcher>
</dvt:treemap>

次の例に、図43-25のサンバーストに対するJSFページ・コード上のコードを示します。この例では、データバインドされたサンバーストには、サマリーおよびユーザーがノード上にマウス・ポインタを移動した場合に表示するツールチップが構成されています。

<dvt:sunburst id="t1" value="#{bindings.SRegionView1.collectionModel}"
var="row" summary="Sunburst Demo">
<af:switcher facetName="#{row.hierTypeBinding.name}" id="s1">
<f:facet name="SRegionView10">
<dvt:sunburstNode value="#{row.TotalSales}" label="#{row.Name}" id="sn1"
shortDesc="Sales: #{row.TotalSales}&lt;br/>Orders: #{row.TotalOrders}">
<dvt:attributeGroups value="#{row.TotalOrders}" type="color" id="ag2"/>
</dvt:sunburstNode>
</f:facet>
<f:facet name="SRegionView11">
<dvt:sunburstNode value="#{row.TotalSales}" label="#{row.Country}" id="sn2"
shortDesc="Sales: #{row.TotalSales}&lt;br/>Orders: #{row.TotalOrders}">
<dvt:attributeGroups value="#{row.TotalOrders}" type="color" id="ag1"/>
</dvt:sunburstNode>
</f:facet>
</af:switcher>
</dvt:sunburst>

サンバーストまたはツリーマップのレベル表示、legendSource属性、ツールチップ、追加の属性または子タグの構成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ツリーマップおよびサンバースト・コンポーネントの使用方法」を参照してください。

44 データバインドされたダイアグラム・コンポーネントの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータから、ダイアグラムを作成する方法について説明します。このダイアグラムの作成には、Fusion WebアプリケーションのADFデータ・コントロールとADF Facesコンポーネントを使用します。具体的には、ADFデータ視覚化diagramコンポーネントを使用して、ビジネス・データを視覚的に表現するダイアグラムの作成方法について説明します。ここでは、ADFデータ・コントロールを使用して、これらのコンポーネントをデータ優先開発で作成する方法について説明します。

簡単なUI優先開発を使用してページを設計する場合は、ダイアグラムをページに追加してから、データ・バインディングを構成してください。ダイアグラム・コンポーネントのデータ要件、タグ構造および外観と動作のカスタマイズ・オプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のマップ・コンポーネントの使用方法に関する項を参照してください。

この章の内容は次のとおりです。

- ADFデータ視覚化ダイアグラム・コンポーネントについて

- データバインドされたダイアグラム・コンポーネントの作成

44.1 ADFデータ視覚化ダイアグラム・コンポーネントについて

ADFデータ視覚化コンポーネントは、ビジネス・データを視覚的に表示、分析するための幅広いグラフィック機能と表機能を提供します。コンポーネントをレンダリングできるようにするには、これらのコンポーネントをそれぞれ、データにバインドする必要があります。コンポーネントの外観は表示されるデータによって変わるからです。

ADF diagramコンポーネントは、(データを表すノードおよびノード間の関係を表すリンクと呼ばれる)図形を使用して、情報のモデル化、表現および視覚化に使用できる対話型コンポーネントを生成します。データ・オブジェクト、およびそれらの間の関係をハイライトする場合は、ダイアグラムを使用します。

図44-1は、ダイアグラム・コンポーネントの4つのランタイム・イメージ(サンキー・フロー・ダイアグラム、データベース表設計、従業員組織図およびスケジュール・ダイアグラム)を示しています。これらの例では、プロセス、データベース・オブジェクト、従業員およびスケジュールされたストップがノードになっています。これらのリンクは、サンキー・フロー・ダイアグラムの各プロセス、組織図における従業員およびスケジュール・ダイアグラムのストップの順序の間の関係を示しています。

図44-1 ダイアグラム・コンポーネントの例

接頭辞dvt:は、各データ視覚化コンポーネント名の先頭に付いて、そのコンポーネントがADFデータ視覚化ツール(DVT)のタグ・ライブラリに属することを示します。

44.1.1 エンド・ユーザー機能およびプレゼンテーション機能

魅力的な外観を備えたデータ視覚化コンポーネントを使用すると、エンド・ユーザーは複雑なビジネス・データを理解して分析できるようになります。このコンポーネントは機能が豊富で、そのまますぐに使用できる対話型のサポートも用意されています。DVTダイアグラム・コンポーネントのエンド・ユーザー機能とプレゼンテーション機能の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のエンド・ユーザー機能およびプレゼンテーション機能に関する項を参照してください

44.1.2 データ視覚化コンポーネントのユースケースと例

ダイアグラム・コンポーネントのユースケースと例の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のダイアグラムのユースケースと例に関する項を参照してください。

44.1.3 データ視覚化コンポーネントの追加機能

データ視覚化コンポーネントをデータ・バインドする前に、その他のOracle ADF機能について理解しておいてください。また、いったんデータ視覚化コンポーネントをページに追加すると、検証やアクセシビリティなどの機能を追加する必要があることに気付く場合があります。データ視覚化コンポーネントで使用されるその他の機能へのリンクは、次のとおりです。

- 部分ページ・レンダリング: データ視覚化コンポーネントをリフレッシュして、ページの別のコンポーネントで実行されたアクションに基づく新しいデータを表示できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の部分ページ・コンテンツの再レンダリングに関する項を参照してください。

- パーソナライズ: ユーザーは実行時にデータ視覚化コンポーネントの表示を変更できますが、ユーザーがカスタマイズできるようにアプリケーションを構成していないかぎり、ユーザーがページを終了するとそれらの値は保持されません。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページでのユーザー・カスタマイズの許可に関する項を参照してください。

- アクセシビリティ: データ視覚化コンポーネントをアクセス可能にできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のアクセス可能なADF Facesページの開発に関する項を参照してください。

- スキンおよびスタイル: アプリケーションに適用するADFスキンを使用するか、スタイル関連のプロパティ(styleClassまたはinlineStyle)を使用してCSSスタイル・プロパティを直接適用することで、データ視覚化コンポーネントの外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のスタイルおよびスキンを使用した外観のカスタマイズに関する項を参照してください。

- プレースホルダ・データ・コントロール: 最終的にページのデータ視覚化コンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールの使用を検討します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

44.2 データバインドされたダイアグラム・コンポーネントの作成

データバインドされたダイアグラムでは、データを表すノード・オブジェクトのコレクションが必要であり、オプションでノード間の関係を表すリンク・オブジェクトのコレクション(オプション)を含めます。Listインタフェース(java.util.ArrayListオブジェクトなど)やコレクション・モデル(org.apache.myfaces.trinidad.model.CollectionModelなど)を実装するオブジェクトを使用できます。

また、データバインドされたダイアグラムでは、機能としてアプリケーションに追加するJavaScriptメソッド内でクライアント・レイアウト構成が定義されている必要もあります。クライアント・レイアウトにより、ページ上のノードおよびリンクの配置方法を指定します。ダイアグラム・コンポーネントには、必要に応じて使用および変更できるデフォルト・レイアウトが含まれています。デフォルトのforceDirectedLayoutでは、すべてのリンクがほぼ同じ長さとなり、可能なかぎり交差リンクが少なくなるようにダイアグラム・ノードが配置されます。

注意:

また、アプリケーション機能として追加するJavaScriptオブジェクト内で独自のクライアント・レイアウト構成を設定することもできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のダイアグラム・レイアウト・フレームワークの使用に関する項を参照してください。

ダイアグラムの作成ウィザードでは、ダイアグラムを作成してデータにバインドするための宣言的サポートが提供されます。ウィザードの5つのページで、次の操作を実行できます。

1. ダイアグラムのクライアント・レイアウトを構成します。
デフォルトのクライアントforceDirectedLayout機能を選択することも、独自のレイアウトを指定することもできますが、レイアウトを選択しなくてもかまいません。

2. 次を含む、ノードおよびリンクのデータを指定します。

- ノードおよびリンクのデータに使用するコレクション

- ノードの一意の識別子(id)を指定する属性

- 親ノードにより含められた子ノードを識別するコンテナIDを含むノード・コレクション内の属性(オプション)

- リンクの開始ノードIDと終了ノードIDを指定するリンク・コレクション内の属性

3. オプションで、ノードのラベルおよびマーカーの表示特性を構成します。
ダイアグラムのノードは、dvt:markerコンポーネントを使用して、ノードの表示特性の多く(色、パターン、図形、境界線のスタイル、色を含む)を構成します。

4. オプションで、指定した属性に従ってノードを色、図形、パターン、不透明度、スケールXまたはスケールYでグループ分けするための属性グループを構成します。

5. オプションで、リンクのラベル、スタイル、色、幅、開始コネクタおよび終了コネクタの表示特性を構成します。

図44-2は、デフォルト・クライアント・レイアウトを使用するように構成されたダイアグラムを示しています。この例では、ダイアグラムは、属性グループを使用してノードのNodeGroup属性とNodeType属性の値によりノードをグループ分けするように構成されています。

図44-2 属性グループを使用するダイアグラムの例

ダイアグラムの作成ウィザードの完了後、ダイアグラムがページに追加されたら、「プロパティ」ウィンドウを使用してダイアグラムをさらにカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のダイアグラム・コンポーネントの使用に関する項を参照してください。

注意:

ADFデータ視覚化ツール(DVT)コンポーネント・コレクションには、組織図やタイム・ラインなどをモデル化するために使用できる他のコンポーネントが含まれています。

たとえば、DVT階層ビューア・コンポーネントを使用して、従業員データにバインドされた組織図を表示することもできます。階層ビューアもノードおよびリンクを使用してデータを表示しますが、コンポーネントはノードのデータ・コレクション内の値に基づいてリンクを自動的に作成するため、リンクに個別のデータ・コレクションを提供する必要はありません。

他のDVTコンポーネントおよび一般的なユースケースの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のデータ視覚化コンポーネントの概要に関する項を参照してください。

44.2.1 ADFデータ・コントロールを使用したダイアグラムの作成方法

データ・コントロールを使用してDVTダイアグラムを作成するには、dvt:diagramコンポーネントを、ノード・データを含むコレクションと、ノード間の関係を表すリンクを含むコレクションにバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

ヒント:

また、「コンポーネント」ウィンドウからダイアグラムをドラッグして、ダイアグラムを作成することもできます。

始める前に:

データバインドされたダイアグラムについて理解しておくと役立ちます。詳細は、「ADFデータ視覚化ダイアグラム・コンポーネントについて」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従って、ダイアグラムのデータ・モデルで必要な、ビュー・オブジェクトのインスタンスを含むアプリケーション・モジュールを作成します。
図44-3は、図44-2に示されているダイアグラムのデータ・コントロールを示しています。この例では、NodesView1にダイアグラム・ノードのデータ・コレクションが含まれ、LinksView1にダイアグラム・リンクのデータ・コレクションが含まれています。

図44-3 ダイアグラム・ノードとダイアグラム・リンクのデータ・コレクションの例

LinksView1データ・コレクション内のStartnode属性とEndnode属性には、NodesView1データ・コレクション内のNodeid属性への参照が含まれています。図44-4は、オブジェクト・ビューアでのリンク・コレクションのデータの一部を示しています。

図44-4 ダイアグラム・サンプル・リンク・データ

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたダイアグラムを作成するには、次の手順を実行します。

1. 「データ・コントロール」パネルから、ダイアグラムに使用するノードを表すデータ・コレクションを選択します。

たとえば、この項に示されたデータ・コレクションを使用するには、「NodesView1」を選択します。

2. コレクションをJSFページにドラッグし、メニューから「ダイアグラム」を選択します。

3. 「NBoxの作成 - クライアント・レイアウトの構成」ダイアログで、クライアント・レイアウトを選択します。

デフォルト・クライアント・レイアウトを選択することも、独自のレイアウトを指定することもできますが、レイアウトを選択しなくてもかまいません。デフォルト・レイアウトを選択するには、図44-5に示す「デフォルト・クライアント・レイアウト」をクリックします。

図44-5 デフォルト・クライアント・レイアウトが選択された「クライアント・レイアウトの構成」ダイアログ

別のレイアウトを指定するには、「クライアント・レイアウトの選択」をクリックし、「機能」および「メソッド」ドロップダウン・メニューから、使用する機能およびメソッドを選択します。レイアウトを選択すると、レイアウトのオプション属性がダイアログに表示され、属性に目的の値を入力できます。

図44-6は、カスタム・サークル・レイアウト用の設定済の「NBoxの作成 - クライアント・レイアウトの構成」ダイアログを示しています。この例では、選択されている機能名はDemoCircleLayoutであり、選択されているメソッドはcircleLayoutです。オプションのレイアウト属性には、anchor、center、curvedLinks、radialLabels、radiusおよびsortAttrがあります。

図44-6 カスタム・レイアウトが選択された「クライアント・レイアウトの構成」ダイアログ

選択したメソッドのコード・ソースを参照するには、「検索」をクリックして、ソース・コードを含むポップアップを表示します。図44-7は、DemoCircleLayout.circleLayoutメソッドが表示されたポップアップを示しています。

図44-7 メソッドのソース・コードのポップアップが表示された「クライアント・レイアウトの構成」ダイアログ

4. 「ダイアグラムの作成 - ノードおよびリンク・データの指定」ダイアログで、データ・ソースおよびリンクの接続を指定するために次の値を入力します。

- コレクション: ノード・コレクションに正しいデータ・コレクションが表示されていることを確認します。
データ・コレクションを変更するには、「データソースの追加」をクリックし、リストから別のデータ・コレクションを選択します。

- ノードID: 値を入力するか、ダイアグラム内のノードの一意の識別子を表すノードのデータ・コレクションの属性を選択します。
または、値を返すEL式を入力するか、ドロップダウン・メニューから「式ビルダー」を選択して「式ビルダー」ダイアログを開くこともできます。「式ビルダー」ダイアログに関するヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

- コンテナID: 入力するか、ドロップダウン・リストを使用して、ダイアグラム内の子ノードの親ノードを表すノードのデータ・コレクションの属性を選択します。
または、値を返すEL式を入力するか、ドロップダウン・メニューから「式ビルダー」を選択して「式ビルダー」ダイアログを開くこともできます。

- コレクション(リンク): リンクを表すデータ・コレクションを入力するか、「データソースの追加」をクリックして、リストから別のデータ・コレクションを選択します。

- 開始ノードID: 入力するか、ドロップダウン・リストを使用して、ダイアグラム内のソース・ノードを表すリンクのデータ・コレクションの属性を選択します。
または、値を返すEL式を入力するか、ドロップダウン・メニューから「式ビルダー」を選択して「式ビルダー」ダイアログを開くこともできます。

- 終了ノードID: 入力するか、ドロップダウン・リストを使用して、ダイアグラム内のターゲット・ノードを表すリンクのデータ・コレクションの属性を選択します。
または、値を返すEL式を入力するか、ドロップダウン・メニューから「式ビルダー」を選択して「式ビルダー」ダイアログを開くこともできます。

図44-8は、NodesView1およびLinksView1データ・コレクションを使用するダイアグラムに対する設定済ダイアログを示しています。この例では、「ノードID」の値がNodeidで、リンクの「開始ノードID」および「終了ノードID」の値がLinksView1データ・コレクション内のStartnodeおよびEndnode属性に設定されています。この例では、親コンテナに子はなく、「コンテナID」フィールドは使用されていません。

図44-8 「ノードおよびリンク・データの指定」ダイアログの例

5. 「ダイアグラムの作成 - ダイアグラム・ノードの構成」ダイアログで、オプションで次の値を入力して、ノードのラベルおよびマーカーの表示特性を構成します。

- ノード・ラベル: ドロップダウン・リストから、ノードのラベルに使用するデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。
オプションで、ラベルの幅、高さおよび不透明度の値を入力できます。ダイアログのヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。

ヒント:

ダイアグラムに適した値がわからない場合は、ダイアグラムを作成してから、作成後に値を変更できます。

- 色: ドロップダウン・リストで、提供された色からノードの色を選択するか、「カスタム色」を選択して「カラー・ピッカー」ダイアログに入力します。デフォルトのノード色は「ブラック」です。

- パターン: ドロップダウン・リストからノード・パターンを選択します。パターンの有効な値には、12の選択肢の事前組込みパターン(大小の格子模様、ダイヤ、三角形など)があります。ノード色を指定した場合、選択した色でパターンが表示されます。デフォルトのノード・パターンは「なし」です。

- 図形: ドロップダウン・リストから、ノードに使用する図形を選択します。有効な値は、circle、human、diamond、square、triangleDown、triangleUpおよびplusです。デフォルトのノードの図形は「円」です。

注意:

ノードの図形、色またはパターンを明示的に指定すると、ダイアグラム内の各ノードに同じ値が使用されます。なんらかのメジャーに従って色、パターンまたは図形を変える場合は、かわりにダイアグラムの作成・ウィザードの次のページで属性グループを構成します。

- ソース: カスタム・ノード図形を使用する場合は、ノード・イメージに使用するSVGファイルの相対パスを入力するか、「検索」アイコンを使用して「SVGファイルの選択」ダイアログを開き、イメージ・ソースに移動します。

- 境界線のスタイル: ドロップダウン・リストから、ダイアグラム内のすべてのノードの境界線のスタイルを選択します。有効な値は、「実線」、「破線」および「ドット」です。デフォルトのスタイルは実線です。

- 枠線の色: ドロップダウン・リストから、ダイアグラム内のすべてのノードの境界線の色を選択するか、「カスタム色」を選択して「カラー・ピッカー」ダイアログに入力します。デフォルトの境界線の色は「ブラック」です。
図44-9は、設定済の「ダイアグラムの作成 - ダイアグラム・ノードの構成」ダイアログを示しています。この例では、ノード・ラベルは相対的な幅20および相対的な高さ30で構成されています。ノードの図形は、水色の小さいクロスハッチ・パターンを持つ、頂点が上部にある三角形です。

図44-9 「ダイアグラム・ノードの構成」ダイアログの例

図44-10は、作成後の3つのダイアグラム・ノードの実行時ビューを示しています。

図44-10 オプションの表示属性を使用するダイアグラム・ノード

6. (オプション)「ダイアグラムの作成 - 属性グループの構成」で、ダイアグラム・ノードの1つ以上の属性グループを構成するには、「グループ化ルール」セクションで「新規」をクリックし、次の値を入力します。

- 値でグループ化: ドロップダウン・リストから、属性グループをグループ化するためのデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。

- プロパティ: ドロップダウン・リストから、表示のためのグループ分けに使用するプロパティを選択します。使用可能なオプションは、「色」、「不透明度」、「パターン」、「スケールX」、「スケールY」および「図形」です。
属性グループを複数のプロパティで区別するには、「複数の属性の選択」を選択します。「複数の属性の選択」で、目的のプロパティを選択し、「OK」をクリックします。

- 凡例ラベル: ドロップダウン・リストから、ダイアグラムの凡例に表示するデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。

- セクション・ラベル: ラベルにテキスト・リソースを使用するには、「テキスト・リソースの選択」を選択して、ラベルにテキスト・リソースを関連付けます。オブジェクトに格納されているデータにアクセスする場合や、EL式を使用してメソッドを参照および呼び出す場合は、「式ビルダー」を選択して「式ビルダー」ダイアログを開きます。

注意:

セクション・ラベルは、凡例のサブセクションの凡例内容を記したもので、凡例領域にレンダリングされます。たとえば、図44-2では、GroupとTypeがセクション・ラベルです。

- オプションで、「値固有のルール」をクリックして属性グループ・ダイアログを拡張し、一致ルールまたは例外ルールを指定します。一致ルールは、単純なtrueまたはfalse条件に対して色またはパターンを指定するか、特定の値に一致させたい場合に使用します。グループ化値が特定の条件を満たしたときの色またはパターンを指定する場合は、例外ルールを使用します。
一致ルールを指定するには、「一致ルール」セクションで「新規」をクリックして、次の値を入力します。

- グループ値: 一致に対するカテゴリ値を入力します。カテゴリを表す文字列を入力するか、trueまたはfalseに設定できます。この値をtrueまたはfalseに設定する場合、「値でグループ化」フィールドには、次の例に示すように、trueまたはfalseに評価されるEL式(#{row.AmountInStock gt row.ReorderPoint}など)を指定する必要があります。

- プロパティ: ドロップダウン・リストから、表示のためのグループ分けに使用するプロパティを選択します。使用可能なオプションは、「色」、「不透明度」、「パターン」、「スケールX」、「スケールY」および「図形」です。

- プロパティ値: ドロップダウン・リストから、ノードの値が「グループ値」に一致する場合に表示する色またはパターンを選択します。色については、提供されているいずれかの色を選択するか、「カスタム・カラー」を選択して「カスタム・カラーの選択」ダイアログでカスタム・カラーを指定できます。パターンについては、提供されているいずれかの値を選択する必要があります。

例外ルールを指定するには、「例外ルール」セクションで「新規」をクリックして、次の値を入力します。

- 条件: trueまたはfalseに評価されるJSF EL式を入力します。「条件」フィールドに式を直接入力するか、「式ビルダー」を選択してJSF EL式を入力できます。

- プロパティ: ドロップダウン・リストから、表示のためのグループ分けに使用するプロパティを選択します。使用可能なオプションは、「色」、「不透明度」、「パターン」、「スケールX」、「スケールY」および「図形」です。

- プロパティ値: ドロップダウン・リストから、ノードの値が「条件」フィールドで指定した条件に一致する場合に表示する色またはパターンを選択します。色については、提供されているいずれかの色を選択するか、「カスタム・カラー」を選択して「カスタム・カラーの選択」ダイアログでカスタム・カラーを指定できます。パターンについては、提供されているいずれかの値を選択する必要があります。

- 凡例ラベル: 凡例ラベルにテキスト・リソースを使用するには、ドロップダウン・リストから「テキスト・リソースの選択」を選択します。このフィールドにテキストを入力するか、「式ビルダー」を選択してJSF EL式を入力することもできます。

図44-11は、図44-2のダイアグラムに対する設定済の「ダイアグラムの作成 - 属性グループの構成」ダイアログを示しています。この例では、ダイアグラムは2つの属性グループに対して構成されています。1つ目の属性グループではNodeGroup属性の値に基づいてノードの色を区別し、2つ目の属性グループはNodeType属性の値に基づいてノードの図形を区別しています。凡例には、両方のグループのセクション・ラベルが表示されます。

図44-11 「属性グループの構成」ダイアログの例

7. 「ダイアグラムの作成 - ダイアグラム・リンクの構成」ダイアログで、次の値を入力して、リンク・ラベル、スタイルおよびコネクタの表示特性を構成します。

- リンク・スタイル: ドロップダウン・リストから、ダイアグラム内のすべてのノードの境界線のスタイルを選択します。有効な値は、「実線」、「破線」、「ドット」および「1点鎖線」です。デフォルトのスタイルは実線です。

- リンク幅: リンクの幅をピクセル単位で入力します。デフォルト値は1です。

- リンク色: ドロップダウン・リストで、提供された色からリンクの色を選択するか、「カスタム色」を選択して「カラー・ピッカー」ダイアログに入力します。デフォルトのリンク色は「ブラック」です。

- コネクタの開始: リンクの開始コネクタの値を入力します。有効な値は、「なし」、「arrowOpen」、「arrow」、「arrowConcave」、「circle」、「rectangle」および「rectangleRounded」です。デフォルト値はnoneです。

- コネクタの終了: リンクの終了コネクタの値を入力します。有効な値は、「なし」、「arrowOpen」、「arrow」、「arrowConcave」、「circle」、「rectangle」および「rectangleRounded」です。デフォルト値はnoneです。

- ラベル: ドロップダウン・リストから、リンクのラベルに使用するデータ・コレクションの属性を選択します。提供されているいずれかの属性を選択するか、「式ビルダー」を選択してJSF EL式を入力できます。

図44-12は、設定済の「ダイアグラムの作成 - ダイアグラム・リンクの構成」ダイアログを示しています。この例では、リンクはラベルおよびデフォルトの幅とスタイルで構成されています。リンクの色はマルーンであり、コネクタの開始部に円、コネクタの終了部に矢印が表示されます。

図44-12 「ダイアグラム・リンクの構成」ダイアログの例

図44-13は、作成後の3つのダイアグラム・ノードの実行時ビューを示しています。

図44-13 オプションの表示属性を使用するダイアグラム・リンク

8. ダイアグラムの作成ウィザードを完了したら、「終了」をクリックしてウィザードを終了し、ダイアグラムをページに追加します。

44.2.2 データバインドされたダイアグラムを作成すると行われる処理

ダイアグラムを「データ・コントロール」パネルからドロップすると、次の処理が行われます。

- JSFページのページ定義ファイル(pageNamePageDef.xml)内にダイアグラムのバインディングが作成されます。

- dvt:diagramコンポーネントのJSFページに必要なタグが追加されます。

- 作成中にデフォルト・クライアント・レイアウトを選択した場合は、そのレイアウトがADF Faces実行時環境に登録されます。

44.2.2.1 ダイアグラム・コンポーネントのバインディング

次のコード・サンプルは、JDeveloperで図44-3のデータ・コレクションを使用してdvt:diagramコンポーネントに生成されたバインディングを示しています。

<executables>
<variableIterator id="variables"/>
<iterator Binds="NodesView1" RangeSize="-1" DataControl="AppModuleDataControl" id="NodesView1Iterator"/>
<iterator Binds="LinksView1" RangeSize="-1" DataControl="AppModuleDataControl" id="LinksView1Iterator"/>
</executables>
<bindings>
<tree IterBinding="NodesView1Iterator" id="NodesView1">
<nodeDefinition DefName="model.NodesView" Name="NodesView10">
<AttrNames>
<Item Value="NodeGroup"/>
<Item Value="NodeType"/>
<Item Value="Nodeid"/>
</AttrNames>
</nodeDefinition>
</tree>
<tree IterBinding="LinksView1Iterator" id="LinksView1">
<nodeDefinition DefName="model.LinksView" Name="LinksView10">
<AttrNames>
<Item Value="Endnode"/>
<Item Value="Startnode"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

ダイアグラムにデータを移入するためのルールは、ノード定義として定義されます。各ノード定義はノードを参照し、「ダイアグラムの作成」ダイアログで指定されたビュー・オブジェクトと属性をリンクします。pageNamePageDef.xmlファイルの詳細は、「pageNamePageDef.xml」を参照してください。

44.2.2.2 ダイアグラム・コンポーネントのJSFページのコード

次の例は、図44-2に示されたダイアグラムに対してJSFページで生成されたコードを示しています。

<dvt:diagram id="dg1" layout="DiagramSampleDiagramLayout">
<dvt:diagramNodes var="node" id="dnodes1"
value="#{bindings.NodesView1.collectionModel}">
<dvt:diagramNode label="#{node.Nodeid}" id="dn1" nodeId="#{node.Nodeid}">
<f:facet name="zoom100">
<dvt:marker width="20" id="m1" height="30">
<dvt:attributeGroups id="ag1" label="#{node.NodeGroup}" type="color"
value="#{node.NodeGroup}"/>
<dvt:attributeGroups id="ag2" label="#{node.NodeType}" type="shape"
value="#{node.NodeType}"/>
</dvt:marker>
</f:facet>
</dvt:diagramNode>
</dvt:diagramNodes>
<dvt:diagramLinks var="link" value="#{bindings.LinksView1.collectionModel}"
id="dl1">
<dvt:diagramLink startNode="#{link.Startnode}" id="dl2"
endNode="#{link.Endnode}"/>
</dvt:diagramLinks>
<dvt:clientLayout method="DiagramSampleDiagramLayout.forceDirectedLayout"
featureName="DiagramSampleDiagramLayout"
name="DiagramSampleDiagramLayout">
<f:attribute name="optimalLinkLength" value="75"/>
</dvt:clientLayout>
<dvt:legend id="l1">
<dvt:legendSection label="#{viewcontrollerBundle.GROUP}" source="dnodes1:ag1"
id="ls1"/>
<dvt:legendSection label="#{viewcontrollerBundle.TYPE}" source="dnodes1:ag2"
id="ls2"/>
</dvt:legend>
</dvt:diagram>

44.2.2.3 デフォルト・クライアント・レイアウトのファイルおよび場所

デフォルト・クライアント・レイアウトを使用してダイアグラムを作成すると、JDeveloperによってADFランタイム環境に力指向レイアウトがJavaScript (JS)機能として登録されます。作成プロセスで、次の命名規則で自動的にJSファイルがViewController/src/js/layoutディレクトリに追加されます。

ApplicationNameDiagramLayout.js

たとえば、アプリケーションがDiagramSampleという名前ならば、JSファイルはDiagramSampleDiagramLayout.jsという名前になります。ファイルの内容にはforceDirectedLayoutメソッドが含まれており、ファイルはJDeveloperで開くことができます。また、「プロパティ」ウィンドウで「コンポーネント定義の編集」をクリックして、「ダイアグラムの編集 - クライアント・レイアウトの構成」ダイアログを表示し、「検索」をクリックしてメソッド・ポップアップを表示することもできます。

また、JDeveloperによって、adf-js-features.xmlファイル(まだ存在しない場合)が作成され、機能名としてApplicationNameDiagramLayout、機能クラスとしてJSファイルのパスが追加されます。次の例は、DiagramSampleという名前のアプリケーションのadf-js-features.xmlファイルを示しています。

<?xml version="1.0" encoding="UTF-8" ?>
<features xmlns="http://xmlns.oracle.com/adf/faces/feature">
<feature>
<feature-name>DiagramSampleDiagramLayout</feature-name>
<feature-class>js/layout/DiagramSampleDiagramLayout.js</feature-class>
</feature>
</features>

44.2.2.4 ダイアグラムのプロパティとレイアウトの変更

ダイアグラムを作成した後は、「ダイアグラムの編集」ダイアログを使用して、別のクライアント・レイアウトを指定したり、ラベルなどの要素を追加したりできます。このダイアログを開くには、dvt:diagramコンポーネントの「プロパティ」ウィンドウで「編集」アイコンを使用します。また、ダイアグラムのプロパティは、ビジュアル・エディタで直接カスタマイズすることも、「プロパティ」ウィンドウで値を設定することによってカスタマイズすることもできます。

たとえば、図44-2に示したツールチップをダイアグラムに追加するには、「プロパティ」ウィンドウまたはコード・エディタで、ダイアグラム・ノードのshortDesc属性の値を入力できます。

<dvt:diagramNode label="#{node.Nodeid}" id="dn1" nodeId="#{node.Nodeid}"
shortDesc="Group: #{node.NodeGroup} Type: #{node.NodeType}">
<f:facet name="zoom100">
... contents omitted
</f:facet>
</dvt:diagramNode>

詳細およびダイアグラムのカスタマイズの例は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のダイアグラム・コンポーネントの使用に関する項を参照してください。

45 データバインドされたタグ・クラウド・コンポーネントの作成

この章では、ADFビジネス・コンポーネントでモデル化されたデータから、タグ・クラウドを作成する方法について説明します。このタグ・クラウドの作成には、Fusion WebアプリケーションのADFデータ・コントロールとADF Facesコンポーネントを使用します。具体的には、ADFデータ視覚化tagCloudコンポーネントを使用して、ビジネス・データを視覚的に表現するタグ・クラウドの作成方法について説明します。ここでは、ADFデータ・コントロールを使用して、これらのコンポーネントをデータ優先開発で作成する方法について説明します。

簡単なUI優先開発を使用してページを設計する場合は、タグ・クラウドをページに追加してから、データ・バインディングを構成してください。タグ・クラウド・コンポーネントのデータ要件、タグ構造および外観と動作のカスタマイズ・オプションの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のタグ・クラウド・コンポーネントの使用方法に関する項を参照してください。

この章の内容は次のとおりです。

- ADFデータ視覚化タグ・クラウド・コンポーネントについて

- データバインドされたタグ・クラウド・コンポーネントの作成

45.1 ADFデータ視覚化タグ・クラウド・コンポーネントについて

ADFデータ視覚化コンポーネントは、ビジネス・データを視覚的に表示、分析するための幅広いグラフィック機能と表機能を提供します。コンポーネントをレンダリングできるようにするには、これらのコンポーネントをそれぞれ、データにバインドする必要があります。コンポーネントの外観は表示されるデータによって変わるからです。

タグ・クラウドはテキスト・データの視覚表現で、通常、自由形式のテキストやWebサイトのタグ・メタデータを視覚化するときに使用されます。各タグの重要度と頻度がフォント・サイズや色で表現されます。視覚化には、セット内で突出する用語をすばやく把握できるという利便性があります。

接頭辞dvt:は、各データ視覚化コンポーネント名の先頭に付いて、そのコンポーネントがADFデータ視覚化ツール(DVT)のタグ・ライブラリに属することを示します。

45.1.1 データ視覚化コンポーネントのユースケースと例

タグ・クラウド・コンポーネントのユース・ケースと例の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のタグ・クラウドのユース・ケースと例に関する項を参照してください。

45.1.2 エンド・ユーザー機能およびプレゼンテーション機能

魅力的な外観を備えたデータ視覚化コンポーネントを使用すると、エンド・ユーザーは複雑なビジネス・データを理解して分析できるようになります。このコンポーネントは機能が豊富で、そのまますぐに使用できる対話型のサポートも用意されています。

DVTタグ・クラウド・コンポーネントのエンド・ユーザー機能とプレゼンテーション機能の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のタグ・クラウドのエンド・ユーザー機能およびプレゼンテーション機能に関する項を参照してください。

45.1.3 データ視覚化コンポーネントの追加機能

データ視覚化コンポーネントをデータ・バインドする前に、その他のOracle ADF機能について理解しておいてください。また、いったんデータ視覚化コンポーネントをページに追加すると、検証やアクセシビリティなどの機能を追加する必要があることに気付く場合があります。データ視覚化コンポーネントで使用されるその他の機能へのリンクは、次のとおりです。

- 部分ページ・レンダリング: データ視覚化コンポーネントをリフレッシュして、ページの別のコンポーネントで実行されたアクションに基づく新しいデータを表示できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」を参照してください。

- パーソナライズ: ユーザーは実行時にデータ視覚化コンポーネントの表示を変更できますが、ユーザーがカスタマイズできるようにアプリケーションを構成していないかぎり、ユーザーがページを終了するとそれらの値は保持されません。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「JSFページでのユーザー・カスタマイズの許可」を参照してください。

- アクセシビリティ: データ視覚化コンポーネントは、デフォルトでアクセス可能です。アプリケーションの各ページは、スクリーン・リーダーでのアクセスが可能になるように作成できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「アクセス可能なADF Facesページの開発」を参照してください。

- スキンおよびスタイル: アプリケーションに適用するADFスキンを使用するか、スタイル関連のプロパティ(styleClassまたはinlineStyle)を使用してCSSスタイル・プロパティを直接適用することで、データ視覚化コンポーネントの外観をカスタマイズできます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

- プレースホルダ・データ・コントロール: 最終的にページのデータ視覚化コンポーネントでADFデータ・バインディングが使用されることがわかっていても、データ・コントロールの準備ができる前にページを開発する必要がある場合、手動でコンポーネントをバインドするのではなく、プレースホルダ・データ・コントロールの使用を検討します。プレースホルダ・データ・コントロールを使用すると、開発済データ・コントロールを使用した場合と同じ宣言的な開発が行われます。詳細は、「プレースホルダ・データ・コントロールによるページの設計」を参照してください。

45.2 データバインドされたタグ・クラウド・コンポーネントの作成

ADFタグ・クラウド・コンポーネントは長方形のコンテナや自由形式のクラウドの中にタグ・データを表示します。タグは実際のデータを表現しており、その重みに応じてクラウド・レイアウトの中に配置されます。より重い、またはより重要なタグが中央に配置されます。

図45-1に、米国のすべての州を表示するように構成されたタグ・クラウドを示します。人口が500万未満の州は青いタグ、500万以上の国は赤のタグで表示されています。このタグ・クラウドでは、密度の高いタグが中央にレンダリングされています。

図45-1 米国の人口の多い州と少ない州を示すタグ・クラウド・コンポーネント

タグ・クラウドのエンド・ユーザー機能とプレゼンテーション機能、ユースケース、タグ構造、タグ・クラウドへの特殊機能の追加の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のタグ・クラウド・コンポーネントの使用方法を参照してください。

45.2.1 データバインドされたタグ・クラウドの作成方法

タグ・クラウドはタグ情報やWebサイト・メタデータを自由フロー形式で表示するときに使用します。「データ・コントロール」パネルを使用して、タグ・クラウドを作成できます。

始める前に:

データバインドされたタグ・クラウドについて理解しておいてください。詳細は、「データバインドされたタグ・クラウド・コンポーネントの作成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「データ視覚化コンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールの作成と変更」の説明に従い、タグ・クラウドのデータ・モデルで必要になる、ビュー・オブジェクトのインスタンスが含まれているアプリケーション・モジュールを作成します。
図45-2は、図45-1に示されているタグ・クラウドのデータ・コントロールを示しています。この例では、CensusView1にタグ・クラウドのデータ・コレクションが含まれています。タグは自由形式テキストとして視覚的に表現されます。各タグのサイズと配置はタグのPopulation2006属性の値に基づいて決定されます。

図45-2 米国の人口の多い州と少ない州を示すタグ・クラウドのデータ・コントロール

Population2006属性の値がタグ・クラウドの一致ルールと照合されます。値が500万を超える場合はタグが赤色でレンダリングされ、それ以外のタグは青色でレンダリングされます。

- 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のJSFページの作成方法に関する項の説明に従い、JSFページを作成します。

データバインドされたタグ・クラウドを作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。

たとえば、この項に示したデータ・コントロールを使用するには、CensusView1を選択します。

2. コレクションをJSFページにドラッグし、メニューから「タグ・クラウド」を選択します。

3. 「タグ・クラウドの作成」ダイアログで、次を実行してタグ・クラウドを構成します。

- 「テキスト値」フィールドのドロップダウン・メニューから、レンダリングするタグ・クラウドに表示するテキストを示す属性を選択します。
たとえば、サンプルのタグ・クラウドを構成するには、State属性を選択します。

- タグ・サイズを構成するには、「相対サイズ」フィールドのドロップダウン・メニューから属性を選択します。
たとえば、サンプルのタグ・クラウドを構成するには、Population2006属性を選択します。

- タグの色を構成するには、「グループ化ルール」の下でルールを作成し、適切な値固有のルールを作成します。一致ルールは、単純なtrueまたはfalse条件に対して色を指定するか、特定の値に一致させたい場合に使用します。例外ルールは、ノードのグループ化値が特定の条件を満たす場合に色を指定するときに使用します。
たとえば、サンプルのタグ・クラウドを構成するには、新しいグループ化ルールを作成します。「値でグループ化」と「凡例ラベル」の下に、#{ent.Population2006 gt 5000000}と入力します。

次に、新しい一致ルールを2つ作成します。最初のルールでは、「グループ値」にtrue、「プロパティ値」に#ed6647を入力します。2つ目のルールでは、「グループ値」にfalse、「プロパティ値」に#267db3を入力します。

図45-3に、CensusView1データ・コントロールを使用してサンプル・タグ・クラウドを生成する「タグ・クラウドの作成」ダイアログを示します。

図45-3 CensusView1の「タグ・クラウドの作成」ダイアログ

4. 「OK」をクリックします。

データ・バインディング・ダイアログに必要事項を入力した後で、プロパティ・インスペクタを使用してタグ・クラウド属性の設定を指定できます。また、dvt:tagCloudに関連付けられた子タグを使用してタグ・クラウドをさらにカスタマイズできます。タグ・クラウド・コンポーネントの構成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のタグ・クラウド・コンポーネントの使用に関する項を参照してください。

45.2.2 データバインドされたタグ・クラウドの作成時の処理

タグ・クラウドを「データ・コントロール」パネルからドロップすると、次の処理が行われます。

- タグ・クラウドのバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

JDeveloperが生成するデータ・バインディングXMLは、作成するタグ・クラウドの物理モデルを表します。次の例は、ページ定義ファイルにJDeveloperが生成したバインディングを示しています。この例では、CensusView1データ・コレクションのState属性とPopulation2006属性のデータを使用してタグ・クラウドが作成されています。

<tree IterBinding="CensusView1Iterator" id="CensusView1">
<nodeDefinition DefName="view.CensusView" Name="CensusView10">
<AttrNames>
<Item Value="State"/>
<Item Value="Population2006"/>
</AttrNames>
</nodeDefinition>
</tree>

次の例は、タグ・クラウドのJSFページで生成されたコードを示しています。

<dvt:tagCloud id="tc1" var="ent" value="#{bindings.CensusView1.collectionModel}" layout="cloud">
<dvt:tagCloudItem label="#{ent.State}" id="tci1" value="#{ent.Population2006}">
<dvt:attributeGroups value="#{ent.Population2006 gt 5000000}" type="color"
label="#{ent.Population2006}"    id="ag1">
<dvt:attributeMatchRule group="true" id="amr1">
<f:attribute name="color" value="#ed6647"/>
</dvt:attributeMatchRule>
<dvt:attributeMatchRule group="false" id="amr2">
<f:attribute name="color" value="#267db3"/>
</dvt:attributeMatchRule>
</dvt:attributeGroups>
</dvt:tagCloudItem>
</dvt:tagCloud>

タグ・クラウドの作成後、「タグ・クラウドの編集」ダイアログでバインディングを変更したり、ルールを追加したりできます。このダイアログを開くには、タグ・クラウド・コンポーネントの「プロパティ」ウィンドウで、「編集」アイコンをクリックします。また、ビジュアル・エディタでタグ・クラウドのコードを直接編集するか、「プロパティ」ウィンドウで値を設定して、属性をカスタマイズすることもできます。

46 コンテキスト・イベントの使用方法

この章では、Fusion Webアプリケーション内のADF Facesリージョン間の通信を円滑化する、コンテキスト・イベントの作成方法、公開方法およびサブスクライブ方法について説明します。ここでは、イベントを宣言的に作成する方法と、マネージドBeanおよびJavaScriptをプログラム的に使用する方法について説明します。

この章の内容は次のとおりです。

- コンテキスト・イベントの作成について

- コンテキスト・イベントの宣言的な作成

- コンテキスト・イベントの手動作成

- マネージドBeanを使用したコンテキスト・イベントの作成

- プレーンJavaオブジェクト(POJO)を使用したコンテキスト・イベントの作成

- JavaScriptを使用したコンテキスト・イベントの作成

- イベント・マップの手動作成

- カスタム・ディスパッチャの登録

46.1 コンテキスト・イベントの作成について

コンテキスト・イベント・フレームワークは、ページ内のリージョン間の通信を可能にします。このフレームワークにより、ページ上の様々なリージョンによって生成および使用される各イベントを、ページ上でマップできます。JDeveloperを使用して、ページ定義ファイルによって宣言的にイベントを公開できます。同様に、ページ定義ファイルから、これらのイベントを宣言的にサブスクライブできます。パラメータをイベントとともに渡し、イベントに応答するハンドラを実装します。コンテキスト・イベントを作成するその他の方法には、マネージドBeanの使用、JavaScriptの使用などがあります。コンテキスト・イベントでは、リージョンがパラメータを受け取るために、リージョンをリフレッシュする必要はありません。

コンテキスト・イベントは、ADFビジネス・コンポーネントが発生させるビジネス・イベントや、UIコンポーネントが発生させるイベントとは異なります。これらのタイプのイベントの説明は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。ただし、コンテキスト・イベントは、UIイベントと関連付けて使用できます。この場合、UIイベントにより起動されるアクション・リスナーが、メソッド・アクション・バインディングを起動し、これによりイベントを生成できます。

ページまたはページ内のリージョンは、ページの他の場所からの情報または異なるリージョンからの情報を必要とすることがよくあります。情報を取得するためにパラメータを渡すことは可能ですが、それはパラメータが既知であり、EL式でページにアクセスできる入力である場合のみ意味を持ちます。また、パラメータ値が変化した場合にタスク・フローを再起動する必要があるときに、パラメータは便利です。

ただし、複数のページ・フラグメントを持つタスク・フローがあり、ページ・フラグメントには、フロー内のあるページへの入力として使用できる様々な興味深い値が含まれているとします。パラメータを使用して値を渡す場合、タスク・フローはすべてのフラグメントの興味深い各値を結合するための出力パラメータを公開する必要があります。そのかわり、必要な情報を含む各フラグメントに対し、ページを送信すると発生するコンテキスト・イベントを定義できます。これにより、情報を必要とするページやフラグメントは様々なイベントをサブスクライブし、このイベントを介して情報を受け取ることができます。

ADFタスク・フローについてのSummitサンプル・アプリケーションでは、選択した兵品の在庫を表示するために、コンテキスト・イベントがメイン・ページの「Inventory Control」タブで使用されています。ユーザーが「Inventory Control」タブを選択すると、2つのリージョンが並んで表示されます。一方のリージョンには、showProducts.jsffページ・フラグメントが収容されます。このページ・フラグメントには、製品在庫の表が含まれています。もう一方のリージョンには、showInventory.jsffページ・フラグメントが収容されます。このページ・フラグメントには、各倉庫の製品在庫割合示すDVTチャートが含まれています。図46-1に、製品リージョンと在庫リージョンを表示する「Inventory Control」タブを示します。

図46-1 「Inventory Control」タブ

製品リージョンには、showProducts.jsffページ・フラグメントを利用するshow-products-task-flowタスク・フローが含まれています。在庫リージョンには、showInventory.jsffページ・フラグメントを利用するproduct-inventory-task-flowタスク・フローが含まれています。

メイン・ページのindex.jsffは、両方のリージョンの親ページになります。これらのリージョンは、af:panelTabbedレイアウト・コンポーネントの子に配置されています。

コンテキスト・イベントは、製品リージョンから在庫リージョンに渡されるため、選択した製品のDVTチャートがshowInventory-task-flowで表示できるようになります。「プロパティ」ウィンドウを使用してプロデューサ・コンポーネントのイベントを作成すると、プロデューサのページ定義ファイルにイベントが登録されます。Summit ADFサンプル・アプリケーションでは、次のように、productSelectedイベントがshowProductsPageDef.xmlファイルに登録されます。

<tree IterBinding="ProductVO1Iterator" id="ProductVO1">
<nodeDefinition DefName="oracle.summit.model.views.ProductVO"
Name="ProductVO10">
<AttrNames>
<Item Value="Id"/>
<Item Value="Name"/>
<Item Value="ShortDesc"/>
<Item Value="LongtextId"/>
<Item Value="ImageId"/>
<Item Value="SuggestedWhlslPrice"/>
<Item Value="WhlslUnits"/>
</AttrNames>
<events xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="productSelected" eventType="Currency Change Event"
customPayLoad="#{bindings.Id.inputValue}"/>
</events>
</nodeDefinition>
</tree>

ページ定義ファイルの概要エディタを使用してイベントにサブスクライブすると、プロデューサとコンシューマとの間でイベントをマップするeventMapが作成されます。

Summit ADFサンプル・アプリケーションでは、次のように、eventMapはコンシューマのページ定義ファイルに作成されます。

<eventMap xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="productSelected">
<producer region="*">
<consumer handler="populateInventoryForProduct" region="">
<parameters>
<parameter name="productId" value="${payLoad}"/>
</parameters>
</consumer>
</producer>
</event>
</eventMap>

実行時に、ユーザーが、show-products-task-flow-definitionとshowProducts.jsffページ・フラグメントに移動すると、在庫のある製品の表が表示されます。ユーザーがリストから製品を選択すると、通貨変更イベントが起動されます。その結果として、productSelectedコンテキスト・イベントがブロードキャストされます。この例では、選択した製品のproductIdを含むpayLoadパラメータが、イベントとともに渡されます。

その後、このイベントは、product-inventoryタスク・フローとそのハンドラのpopulateInventoryForProduct()メソッドで使用されます。このメソッドでは、payLoadパラメータを使用して、どの製品の在庫情報をDVTコンポーネントに表示するかを決定します。

このイベント・ハンドラのコードを作成する必要があります。Summit ADFサンプル・アプリケーションの場合は、在庫データがInventoryVOビュー・オブジェクトに含まれているため、次のように、InventoryVOImpl.javaファイルにpopulateInventoryForProduct()ハンドラを追加します。

public void populateInventoryForProduct( String productId ) {
applyViewCriteria(getViewCriteria("InventoryVOCriteria"));
setinputProductId( productId );
executeQuery();
}

/**
* Returns the variable value for Variable.
* @return variable value for Variable
*/
public String getinputProductId() {
return (String)ensureVariableManager().getVariableValue("inputProductId");
}

/**
* Sets <code>value</code> for variable Variable.
* @param value value to bind as Variable
*/
public void setinputProductId(String value) {
ensureVariableManager().setVariableValue("inputProductId", value);
}

イベントは、イベントを発生させるページまたはリージョン(作成者)のページ定義ファイルで構成されます。イベントに基づいた処理を実行するコンシューマをプロデューサと関連付けるには、コンシューマ側のページまたは親ページのページ定義ファイルにイベント・マップを作成します。(親ページは両方のリージョンを含むページです)。使用ページが動的リージョン内にある場合、イベント・マップを使用ページのページ定義ファイル内に配置し、プロデューサの属性リージョンを"*"に設定する必要があります。属性リージョンを"*"に設定するのは、設計時、フレームワークはプロデューサへの相対パスを決定できないためです。

コンテキスト・イベントは、アクション・バインディング、メソッド・アクション・バインディング、値属性バインディング、またはレンジ・バインディング(表、ツリー、またはリスト・バインディング)に対して発生させることができます。また、条件付きでイベントを発生させ、EL式を使用して条件付きでイベントを処理することもできます。

アクション・バインディングとメソッド・アクション・バインディングの場合、アクションまたはメソッドの実行時にイベントは発生します。payLoadには、メソッドの戻り値が含まれます。また、ボタンのクリックやメニューからの選択などのADF Facesイベントからコンテキスト・イベントを発生させることもできます。イベントを定義するeventBindingがページ定義内に作成されます。

値属性バインディングの場合、イベントはバインディング・コンテナによってトリガーされ、属性が正常に設定された後に発生します。payLoadはDCBindingContainerValueChangeEventのインスタンスであり、新規の値、古い値、プロデューサ・イテレータ、バインディング・コンテナおよびソースへのアクセスを提供します。カスタム・データ・オブジェクトをポイントするようにpayLoadプロパティを変更すると、payLoad参照はかわりにオブジェクトを返します。次の例は、入力コンポーネントと関連付けられている属性値バインディング内部の値の変更イベントを示しています。このページでユーザーがLAST_NAMEの値を変更すると、イベントvalueChangeEventがディスパッチされます。

<attributeValues IterBinding="DeptView1Iterator" id="Dname"
xmlns="http://xmlns.oracle.com/adfm/jcuimodel">
<events xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="valueChangeEvent"/>
</events>
<AttrNames xmlns="http://xmlns.oracle.com/adfm/uimodel">
<Item Value="LAST_NAME"/>
</AttrNames>
</attributeValues>
</bindings>
<eventMap xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="valueChangeEvent">
<producer region="LAST_NAME">
<consumer region="" handler="consumeEvent"/>
</producer>
</event>
</eventMap>

範囲バインディング(ツリー、表、リスト)の場合、イベントは現行の変更が正常に行われた後に発生します。payLoadはDCBindingContainerValueChangeEventのインスタンスであり、新規の値、古い値、プロデューサ・イテレータ、バインディング・コンテナおよびソースへのアクセスを提供します。前述のeventMapの例は、範囲バインディングに関連付けられた通貨変更イベントのイベント・マップを示しています。

値属性バインディングおよび範囲バインディングのコンテキスト・イベントは、ナビゲーションの変化によってトリガーすることもできます。たとえば、ツリー表バインディングの内部にイベントを作成した場合、ユーザーがページでこのツリーの別ノードを選択したときに、このイベントがディスパッチされます。

「プロパティ」ウィンドウの「動作」セクションの下にある「コンテキスト・イベント」セクションを使用すると、コンテキスト・イベントを作成および公開できます。図46-2に示すように、「コンテキスト・イベント」パネルは、ページから適切なコンポーネントまたはリージョンを選択した場合にのみ表示されます。

図46-2 「プロパティ」ウィンドウの「コンテキスト・イベント」パネル

コンテキスト・イベントのサブスクライブには、ページ定義ファイルの「コンテキスト・イベント」タブの「サブスクライバ」セクションにある概要エディタを使用します(図46-3を参照)

図46-3 ページ定義の「コンテキスト・イベント」タブ

コンシューミング・リージョンのページ定義のeventMap内で、refresh="false"をコンシューマ要素に追加して、コンテキスト・イベントの使用時に自動リージョン・リフレッシュをオフにすることができます。refreshをfalseに設定すると、イベント・コンシューミング・リージョンのリフレッシュを担当する場合に役に立ちます。refresh属性のデフォルトはtrueです。加えて、コンシューミング・リージョンのページ定義のeventMapの内部にあるコンシューマ要素に存在するhandleCondition属性のELバインディングを使用して、コンテキスト・イベントの特定のインスタンスでサブスクライバ・リージョンをオフにすることもできます。次のページ定義ファイル・ソースおよび「プロパティ」画面は、コンシューミング・リージョンのページ定義のmethodActionバインディングおよびeventMapを示し、ここでは、regionおよびhandleCondition属性を追加することで、コンシューミング・リージョンのコンテキスト・イベント・レスポンスが制御されています。

図46-4 コンシューマEventMap内のコンシューマ要素の属性

46.1.1 コンテキスト・イベントのユースケースと例

リージョンと親ページ間の通信パターンには、親対リージョン、リージョン対親、リージョン対リージョンの3種類があります。コンテキスト・イベント・フレームワークは、これら3つのシナリオすべてに対応する、非常に強力な通信実装です。コンテキスト・イベントでは、リージョンが入力パラメータを使用するために、リージョンをリフレッシュする必要はありません。

ADFリージョン間で通信を行うには、コンテキスト・イベントを使用する必要があります。ADFタスク・フロー・パラメータを使用してリージョン間の通信もできますが、この場合、リージョン間に直接的な依存性が生じてしまう可能性があります。静的なリージョンに対しては、ADFタスク・フロー・パラメータの使用が適切な場合もありますが、コンテキスト・イベントを使用すると、リージョン間の独立した通信を実装できます。

たとえば、従業員情報を入力するためのフォームを保持するリージョンがページに含まれるとします。ユーザーが従業員IDを更新し、送信ボタンを押すと、値変更コンテキスト・イベントが発生し、従業員ID値がpayLoadとして渡されます。同じページ上の別のリージョンがこのイベントをサブスクライブして使用することで、コンテキスト・イベントとともに渡されたpayLoadの情報に基づき、選択された従業員に対する部署情報を表示できます。

46.1.2 コンテキスト・イベントのその他の機能

コンテキスト・イベントの処理を開始する前に、その他のADF機能について理解しておいてください。次に、関連する他の機能へのリンクを示します。

- ADFタスク・フロー・パラメータを使用して、ADFリージョン間で通信を行うこともできます。タスク・フローとリージョンの使用の詳細は、「リージョンとしてのタスク・フローの使用」を参照してください。

46.2 コンテキスト・イベントの宣言的な作成

コンテキスト・イベントを作成するには、まず、メソッド・アクション、アクション、値属性、またはリスト・バインディングに基づいて、プロデューサにイベントを作成し、公開します。コンシューマで、このイベントをサブスクライブし、これを処理するためのハンドラを作成します。

通常、タスク・フローおよびビュー・アクティビティを含むリージョンを持つ親ページを作成します。リージョンの1つには、もう1つのリージョンのコンシューマ・イベント・ハンドラのために公開されるコンテキスト・イベントを作成します。タスク・フローとリージョンの使用の詳細は、「リージョンとしてのタスク・フローの使用」を参照してください。

注意:

コードから(マネージドBeanの内部などから)アクション・コンテキスト・イベントを公開することもできます。EventDispatcherのインスタンスを戻すgetBindingContainer().getEventDispatcherを使用します。EventDispatcherには、コンテキスト・イベントをプログラミングによって発生させるために使用できるパブリックAPIがあります。

46.2.1 コンテキスト・イベントの公開方法

「プロパティ」ウィンドウを使用して、コンテキスト・イベントを生成するページにコンテキスト・イベントを作成します。つまり、プロデューサのページが、コンテキスト・イベントを生成するページになります。イベントはローカルまたはリモート・コンシューマに向けて公開できます。デフォルトで、すべてのイベントはローカル・コンシューマに公開されます。たとえば、あるページのボタンをクリックすると、別のコンポーネントで利用されるコンテキスト・イベントがトリガーされるとします。このボタンを含むページが、プロデューサのページになります。

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「コンテキスト・イベントの宣言的な作成」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

次のタスクを完了する必要があります。

- コンテクスト・イベントを発生させるために使用するコンポーネントのタイプを決定します。メソッド・アクション・バインディングの使用を計画している場合は、ページにドロップするメソッドをあらかじめ作成しておく必要があります。

コンテキスト・イベントを作成するには:

1. コンテキスト・イベントを公開するページで、「データ・コントロール」パネルからコンポーネントをドラッグし、そのページにドロップします。
このコンポーネントで、イベントをトリガーすることになります。これには、メソッド・アクション、アクション、値属性またはリストのバインディング・イベントが必要です。

2. 「プロパティ」ウィンドウで、「動作」セクションを開きます。

3. 「イベントの発行」セクションで「追加」アイコンをクリックします。

4. コンテキスト・イベントの公開ダイアログで:

a. 「新規イベントの作成」を選択します。

b. イベントの名前を入力します。

c. 表、ツリーまたはツリー表のコンポーネントを使用している場合は、「ノード」フィールドが表示されます。このフィールドには、変更イベントの発生時にイベントを公開するノードを入力します。

d. ペイロード・データをコンシューマに渡す場合は、「次からカスタム値を渡す」を選択します。

e. payloadデータを渡す場合は、ドロップダウン・リストからデータ型を選択します。通常、このパラメータは、{$payLoad}になります。
たとえば、プロデューサ・ページからコンシューマ・ページに属性値を渡す場合は、「ページ・データ」を選択して、ツリー構造から目的の属性を選択します。

f. 「呼出し条件」タブにEL式を入力して、条件付きでイベントを発生させることができます。
たとえば、式${bindings.LAST_NAME.inputValue == 'KING'}を入力すると、顧客の姓が「KING」である場合のみ、イベントが発生します。

g. 「OK」をクリックします。
イベントはこのページに作成されますが、コンポーネント・バインディングと関連付けるまで公開できません。

図46-5 コンテキスト・イベントの公開

5. デフォルトで、すべてのイベントはローカル・リージョンにディスパッチされます。イベントをリモート・リージョンにディスパッチする手順:

a. イベントを生成するページのページ定義ファイルの「ソース」ビューで、イベントを選択して「プロパティ」ウィンドウでそのイベントのプロパティを表示します。

b. dispatchMode属性をremoteに設定します。

c. customPayLoad属性に、シリアライズ可能オブジェクトを参照するEL式を記述します。

d. customPayLoadType属性で、オブジェクトのカスタム・ペイロードのタイプを指定します。

46.2.2 コンテキスト・イベントをサブスクライブおよび使用する方法

コンテキスト・イベントにサブスクライブするには、ページ定義ファイルの概要エディタを使用します。概要エディタには、現在のリージョンと、その子のリージョンが表示されます。コンテキスト・イベントにサブスクライブできるリージョンのみが表示されます。

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「コンテキスト・イベントの宣言的な作成」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

次のタスクを完了する必要があります。

- 「コンテキスト・イベントの公開方法」の説明に従い、ページ定義ファイル内にコンテキスト・イベントを作成します。

イベントをサブスクライブし、使用するには:

1. イベントとそのペイロード・データを処理するハンドラを作成します。
Summit ADFサンプル・アプリケーションでは、InventoryVOImpl.javaファイルにコードを追加することで、InventoryVOビュー・オブジェクトにPopulateInventoryForProductハンドラ・メソッドを作成します。

このメソッドは、BackOfficeAppModuleDataControlアプリケーション・モジュール内にあります。

2. コンシューマ側のページには、イベントに応答するコンポーネントを追加します。
Summit ADFサンプル・アプリケーションでは、DVTコンポーネントをページに追加することで、各倉庫内の在庫を表示します。

このDVTコンポーネントは、PopulateInventoryForProductメソッドからデータを取得します。

3. 「アプリケーション」ウィンドウで、イベント・マップを含めるページ定義ファイルをダブルクリックします。
Summit ADFサンプル・アプリケーションでは、showInventoryPageDef.xmlページ定義ファイルにイベント・マップを含めます。

4. 概要エディタの「バインディングと実行可能ファイル」タブをクリックし、「バインディング」セクションの「追加」アイコンをクリックします。

5. 「項目の挿入」ダイアログで、methodActionを選択し、「OK」をクリックします。

6. 「アクション・バインディングの作成」ダイアログで:

a. ハンドラを作成したデータ・コレクションを開きます。

b. ハンドラを選択します。

c. 「OK」をクリックします。

7. 概要エディタの「コンテキスト・イベント」タブで「サブスクライバ」をクリックし、「イベント・サブスクライバ」セクションの「追加」アイコンをクリックします。

8. 「コンテキスト・イベントのサブスクライブ」ダイアログで:

a. イベント名を入力するか、「検索」アイコンをクリックして、「コンテキスト・イベントの選択」ダイアログを開きます。
「コンテキスト・イベントの選択」ダイアログが開かれている場合は、イベントをツリー構造から選択して「OK」をクリックします。

b. 「パブリッシャ」ドロップダウン・リストから目的のプロデューサ、または「<任意>」を選択します。1つのコンテキスト・イベントに対して複数のプロデューサが存在することがあります。
<Any>を選択すると、コンシューマは、選択したイベントを生成するあらゆるプロデューサをサブスクライブできます。ページ定義ファイルで、producer属性にはワイルドカード"*"が設定されます。プロデューサが動的リージョン内にある場合、サブスクライバがどのプロデューサからでも使用できるように、このフィールドを<Any>に設定する必要があります。

c. 「範囲」フィールドの隣にある「ハンドラ」アイコンをクリックします。

d. 「ハンドラの選択」ダイアログで、ツリー構造から目的のイベント・ハンドラを選択し、「OK」をクリックします。

e. このハンドラにパラメータが必要な場合は、「パラメータ」タブを選択し、「追加」をクリックしてから、パラメータとして名前/値ペアを入力します。

f. 条件付きでイベントを処理する場合、「ハンドル」タブを選択し、ハンドラがイベントを処理する条件を決定するEL式を入力します。

g. 「OK」をクリックします。

図46-6 コンテキスト・イベントのサブスクライブ

注意:

「構造」ウィンドウでページ定義を右クリックし、「イベント・マップの編集」を選択し、イベント・マップを編集することができます。ページ定義ファイルまたは「プロパティ」ウィンドウで、イベントの属性を編集することもできます。

46.2.3 コンテキスト・イベントの作成時の処理

作成者のイベントを作成すると、JDeveloperはページ定義ファイルにevents要素を追加します。各イベント名が子として追加されます。次のプロデューサのイベント定義の例は、通貨変更イベントとしてプロデューサのページ定義ファイル内に定義されたproductSelectedイベントを示しています。

<tree IterBinding="ProductVO1Iterator" id="ProductVO1">
<nodeDefinition DefName="oracle.summit.model.views.ProductVO"
Name="ProductVO10">
<AttrNames>
<Item Value="Id"/>
<Item Value="Name"/>
<Item Value="ShortDesc"/>
<Item Value="LongtextId"/>
<Item Value="ImageId"/>
<Item Value="SuggestedWhlslPrice"/>
<Item Value="WhlslUnits"/>
</AttrNames>
<events xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="productSelected" eventType="Currency Change Event"
customPayLoad="#{bindings.Id.inputValue}"/>
</events>
</nodeDefinition>
</tree>

コンシューマのページ定義ファイルには、イベントに応答するメソッド・アクション・バインディングが作成されます。次のメソッド・アクションの定義の例は、showInventoryPageDefページ定義ファイル内に定義されたメソッド・アクション・バインディングを示しています。

<methodAction id="populateInventoryForProduct" RequiresUpdateModel="true"
Action="invokeMethod"
MethodName="populateInventoryForProduct"
IsViewObjectMethod="true"
DataControl="BackOfficeAppModuleDataControl"
InstanceName="data.BackOfficeAppModuleDataControl.InventoryVO1">
<NamedData NDName="productId" NDType="java.lang.String"/>
</methodAction>

通貨の変更が発生すると、そのイベントは、イベントのコンシューマにブロードキャストされます。メソッド・アクションの定義は、コンシューマ側のページ定義ファイルで定義されます。

イベント・マップを構成すると、JDeveloperは対応するページ定義ファイルにイベント・マップのエントリを作成します。次の例は、showproductstaskflowdefinition1リージョンからproductinventorytaskflowdefinition1リージョンにproductSelectedイベントをマップする、showInventoryPageDefページ定義ファイルのイベント・マップを示しています。また、showInventoryPageDefページ定義ファイルで定義されているpopulateInventoryForProductハンドラ・メソッド・バインディングもマップしています。このハンドラは、payLoad情報(productIDが含まれる)を処理してDVTコンポーネントに渡すため、このコンポーネントは、その製品の倉庫内在庫を問合せできるようになります。

<eventMap xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="productSelected">
<producer region="*">
<consumer handler="populateInventoryForProduct" region="">
<parameters>
<parameter name="productId" value="${payLoad}"/>
</parameters>
</consumer>
</producer>
</event>
</eventMap>

dispatchModeの値をremoteに設定すると、ページ定義ファイル内でJDeveloperがevent要素に属性dispatchModeを追加します。CustomPayLoadTypeは渡されるペイロードのタイプです。getCustomPayLoad()が文字列を返す場合は文字列です。次の例はイベント要素を示しています。このイベント要素には、remoteに設定されたdispatchMode属性と、リモート・コンシューマに渡すカスタム・ペイロードを指定する属性が含まれています。

<methodAction id="eventProducer" RequiresUpdateModel="true" Action="invokeMethod" MethodName="eventProducer"
IsViewObjectMethod="false" DataControl="Class1"
InstanceName="bindings.eventProducer.dataControl.dataProvider"
ReturnName="data.Class1.methodResults.eventProducer_eventProducer_dataControl_dataProvider_eventProducer_result">
<events xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="teste" eventType="Action Event" dispatchMode="remote" customPayloadType="java.lang.String"
customPayLoad="#{testBean.customPayLoad}"/>
</events>
</methodAction>

46.2.4 コンテキスト・イベント・ディスパッチの制御方法

アプリケーション・レベル、またはページ・レベルで、子リージョンへのコンテキスト・イベントのディスパッチを制御できます。

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「コンテキスト・イベントの宣言的な作成」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

イベントのディスパッチを無効化するには:

1. アプリケーション・レベルでイベントのディスパッチを無効化するには、次の例に示すように、adf-config.xmlファイルのdynamicEventSubscriptionsプロパティをfalseに設定します。

プロデューサがワイルドカードであるイベント・マップを持つリージョンへのイベントのディスパッチを無効化できます。

<?xml version="1.0" encoding="windows-1252" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:cef="http://xmlns.oracle.com/adfm/contextualEvent">
<cef:DynamicRegionEventsConfig dynamicEventSubscriptions="false">
</cef:DynamicRegionEventsConfig>
</adf-config>

2. 個々のページ・レベルでイベントのディスパッチを無効化するには、次の例に示すように、関連付けられたページ定義ファイル内でdynamicEventSubscriptionsプロパティをfalseに設定します。

コンテキスト・イベントがこのページや、その子のいずれにも渡されることはありません。

<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="11.1.1.52.8" id="viewBPageDef" Package="view.pageDefs"
DynamicEventSubscriptions="false">

46.2.5 実行時に行われる処理: コンテキスト・イベント

イベント・プロデューサとコンシューマの両方が同じページ定義ファイルに定義されている場合、対応するページの呼び出しおよびバインディング・コンテナの作成後、次の場合にイベントが発生します。

- 対応するメソッドまたはアクション・バインディングが実行される

- 値バインディングが正常に設定される

- レンジ・バインディングの現行性が正常に設定される

メソッド・バインディングの場合、メソッド実行の結果がイベントのペイロードを形成し、イベントがキューイングされます。JSFライフサイクルのアプリケーションの起動フェーズで、キューイングされたすべてのイベントがディスパッチされます。バインディング・コンテナに関連付けられたイベント・ディスパッチャは、そのイベントに関連するコンシューマをイベント・マップで確認し、イベントをコンシューマに渡します(イベント・マップは同じページ定義ファイルの一部であるため、バインディング・コンテナにも含まれます)。

プロデューサとコンシューマが異なるリージョンに存在する場合、イベントは最初に同じコンテナ内の任意のコンシューマにディスパッチされ、次にイベント伝播が親バインディング・コンテナに委任されます。この処理は、親または最上位のバインディング・コンテナに達するまで続きます。最上位バインディング・コンテナに達した後、プロデューサがワイルドカード(*)に設定されているページでリージョンを保持する子バインディング・コンテナに、イベントが再度ディスパッチされます。

46.3 コンテキスト・イベントの手動作成

コンテキスト・イベントの作成では、最初に作成者にイベントを作成します。続いてイベントのコンシューマを定義し、プロデューサとコンシューマをマッピングします。

46.3.1 コンテキスト・イベントの手動作成方法

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「コンテキスト・イベントの手動作成」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

次のタスクを完了する必要があります。

- メソッド・バインディング、アクション・バインディング、値属性バインディングまたはリスト・バインディングを持つコンテキスト・イベントをプロデューサ・ページ上に作成します。

コンテキスト・イベントを作成するには:

1. 「アプリケーション」ウィンドウで、イベントのプロデューサ用のバインディングを含むページ定義ファイルをダブルクリックします。
作成者には、イベントの発行に使用される関連付けられたバインディングが必要です。たとえば、メソッドまたは操作が作成者になる場合、イベントは関連アクション・バインディングまたはメソッド・アクション・バインディングに含まれます。

2. 「構造」ウィンドウで、プロデューサのバインディングを右クリックし、「バインディング名の中に挿入」→「event」または「バインディング名の中に挿入」→「コンテキスト・イベント」→「event」を選択します。

3. 「構造」ウィンドウで、たった今作成されたevents要素を右クリックし、「eventsの内部に挿入」→「event」を選択します。

4. 「eventの挿入」ダイアログで、「名前」フィールドにイベント名を入力し、「終了」をクリックします。
これで、イベントが作成されます。デフォルトでは、関連するメソッドまたは操作の戻り値はすべて、イベントのペイロードとして取得され、ELでアクセス可能な変数${data.payLoad}に格納されます。次に、イベントをコンシューマにマッピングし、コンシューマに渡す必要があるペイロードを構成する必要があります。

5. 「アプリケーション」ウィンドウで、コンシューマ用のバインディングを含むページ定義ファイルをダブルクリックします。
このページが表すバインディング・コンテナは、含まれるバインディング・コンテナすべてを含む現在のスコープ(タスク・フロー・リージョンなど)からイベントへのアクセスを提供します。リージョンまたは他のネストされたコンテナがイベントを認識する必要がある場合、イベント・マップは使用リージョン内のページのページ定義に存在する必要があります。

6. 「構造」ウィンドウで、ページ定義を表す最上位のノードを右クリックし、「イベント・マップの編集」を選択します。

注意:

プロデューサ・イベントが埋込み動的リージョン内のページから発生する場合、イベント・マップ・エディタを使用してイベント・マップを編集できないことがあります。イベント・マップを手動で作成するには、ページ定義ファイルを編集するか、「コンテキスト・イベントの手動作成」で説明している「内部に挿入」の手順を使用します。

7. イベント・マップ・エディタで、「追加」アイコンをクリックして、イベント・エントリを追加します。

8. 「新規EventMapエントリの追加」ダイアログ・ボックスで、次の操作を行います。

a. 作成者ドロップダウン・メニューを使用して作成者を選択します。

b. 「イベント名」ドロップダウン・メニューを使用してイベントを選択します。

c. 使用者ドロップダウン・メニューを使用して使用者を選択します。これは、イベントを使用する実際のメソッドになります。

d. 使用するメソッドまたは操作にパラメータが必要な場合は、「追加」アイコンをクリックします。
「パラメータ名」フィールドに、メソッドに必要なパラメータの名前を入力します。「パラメータ値」フィールドに値を入力します。これがイベントからのペイロードの場合は、${data.payLoad}式を使用すると、この値にアクセスできます。ペイロードに複数のパラメータが含まれ、それらすべてを必要とする場合以外は、省略記号ボタンを使用して「式ビルダー」ダイアログを開きます。このダイアログを使用して、「ペイロード」ノードの下の特定のパラメータを選択できます。

また、「パラメータ」省略記号ボタンをクリックして、選択ダイアログを開くこともできます。

e. 「OK」をクリックします。

9. イベント・マップ・エディタで、「OK」をクリックします。

46.4 マネージドBeanを使用したコンテキスト・イベントの作成

マネージドBeanの内部など、コードからアクション・コンテキスト・イベントを公開することができます。

46.4.1 マネージドBeanを使用したコンテキスト・イベントの作成方法

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「マネージドBeanを使用したコンテキスト・イベントの作成」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

マネージドBeanを使用してコンテキスト・イベントを作成するには:

1. コンテキスト・イベントを生成するマネージドBeanのメソッドを作成します。

次の例は、ボタンが押されたときにアクションを実行するマネージドBeanのコードを示しています。myActionPerformedメソッドが呼び出されると、payLoadとして"myString"を含むコンテキスト・イベントを生成するためのメソッドをコールします。

BindingContainer bc BindingContext.getCurrent().getCurrentBindingsEntry();
JUCtrlActionBinding actionBnd =
(JUCtrlActionBinding)bc.getControlBinding("eventProducer");
...
((DCBindingContainer)bc).getEventDispatcher().queueEvent(actionBnd.
getEventProducer(),"myString");

2. プロデューサ・コンポーネントをマネージドBeanのメソッドにバインドします。

次の例は、アクション・バインディングを起動するコマンド・ボタンに関連付けられた、プロデューサのコードを示しています。このコードでのコンシューマは文字列を表示するoutputTextコンポーネントです。これらは両方とも同じページにあります。

<af:form id="f1">
<af:button value="eventProducerButton1" id="cb1"
action="#{MyBean.myActionPerformed}"/>
<af:panelLabelAndMessage label="#{bindings.return.hints.label}"id="plam1">
<af:outputText value="#{bindings.return.inputValue}" id="ot1"/>
</af:panelLabelAndMessage>
</af:form>

46.4.2 マネージドBeanを使用したコンテキスト・イベントの作成時の処理

次に示すとおり、このページ定義ファイルには、プロデューサのメソッド・アクション・バインディング、コンシューマおよびイベント・マップが含まれます。

<executables>
<variableIterator id="variables">
<variable Type="java.lang.String" Name="eventConsumer_return"
IsQueriable="false" IsUpdateable="0"
DefaultValue="${bindings.eventConsumer.result}"/>
</variableIterator>
</executables>
<bindings>
<methodAction id="eventProducer"
InstanceName="AppModuleDataControl.dataProvider"
DataControl="AppModuleDataControl" RequiresUpdateModel="true"
Action="invokeMethod" MethodName="eventProducer"
IsViewObjectMethod="false"
ReturnName="AppModuleDataControl.methodResults.eventProducer_
AppModuleDataControl_dataProvider_eventProducer_result">
<events xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="myEvent"/>
</events>
</methodAction>
<methodAction id="eventConsumer" RequiresUpdateModel="true"
Action="invokeMethod" MethodName="eventConsumer"
IsViewObjectMethod="false" DataControl="AppModuleDataControl"
InstanceName="AppModuleDataControl.dataProvider"
ReturnName="AppModuleDataControl.methodResults.eventConsumer_
AppModuleDataControl_dataProvider_eventConsumer_result">
<NamedData NDName="str" NDValue="test" NDType="java.lang.String"/>
</methodAction>
<attributeValues IterBinding="variables" id="return">
<AttrNames>
<Item Value="eventConsumer_return"/>
</AttrNames>
</attributeValues>
</bindings>
<eventMap xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="myEvent">
<producer region="eventProducer">
<consumer region="" handler="eventConsumer">
<parameters>
<parameter name="test" value="${data.payLoad}"/>
</parameters>
</consumer>
</producer>
</event>
</eventMap>

46.4.3 マネージドBeanを使用したコンテキスト・イベントの動的作成および操作の方法

プログラム的なコンテキスト・イベント定義を作成し、イベント・プロデューサを登録して、コンテキスト・イベントをトリガーすることができます。これは、イベントが使用されるコンテキストに基づいて異なるイベントをトリガーするタスク・フローを作成する場合に、役に立ちます(たとえば、タスクをホストするクライアントが変更される場合など)。

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「マネージドBeanを使用したコンテキスト・イベントの作成」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

マネージドBeanを使用してコンテキスト・イベントを作成および操作するには、次の手順を実行します。

1. コンテキスト・イベントを生成するマネージドBeanのメソッドを作成します。

次の例は、EventDispatcher APIを実行して、ボタンが押された場合にアクションを実行するマネージドbeanコードを示します。

DCBindingContainer bc = (DCBindingContainer) BindingContext.getCurrent().getCurrentBindingsEntry();
bc.getEventDispatcher().queueEvent(new CustomEventProducer(), someCustomEventPayLoad);
bc.getEventDispatcher().processContextualEvents();

この前述のサンプルで使用されるCustomEventProducerは、コンテキスト・イベントJDemoEventを定義します。

import oracle.adf.model.events.EventProducer;

public class CustomEventProducer implements EventProducer {
public CustomEventProducer() {
super();
}
public String getId() {
return "JDemoEvent";
}

public ArrayList getEventDefinitionsList() {
ArrayList eventDefList = new ArrayList();

EventDefinitionImpl demoEvent = new EventDefinitionImpl();
demoEvent.setEventName("JDemoEvent");
eventDefList.add(demoEvent);
return eventDefList;
}

}

2. プロデューサ・コンポーネントをマネージドBeanのメソッドにバインドします。

次のサンプルは、前述のマネージドbean上で、アクション・リスナー・メソッドproduceDynamicContextualEvent()を起動するアクション・ボタンに関連付けられたプロデューサ・ページ・ソースを示します。

<af:panelGroupLayout id="pgl1">
<af:button text="Produce Contextual Event" id="b5"
actionListener="#{viewScope.EventProducer.produceDynamicContextualEvent}"/>
</af:panelGroupLayout>

3. コンシューマ・コンポーネントを、コンテキスト・イベントのイベント・ハンドラ・メソッドにバインドします。(これはデータ制御に依存したバインディングの実行に対する代替の方法です。)

次のサンプルは、コンシューマ・ページ・ソースを、イベント・ハンドラ・メソッドsetOutputTextDeptName()により設定される文字列を表示するoutputTextコンポーネントとして示します。

<af:panelGroupLayout id="pgl1">
<af:outputText value="Got the following via Contextual Event :" id="ot1"/>
<af:outputText value="#{backingBeanScope.EventHandler.deptName}" id="ot2"
binding="#{backingBeanScope.EventHandler.outputTextDeptName}" clientComponent="true"/>
</af:panelGroupLayout>

データ制御を使用せずにコンテキスト・イベントとしてマネージドbeanを作成する場合、methodActionバインディングを手動で作成することができます。これにより、コンテキスト・イベントとして、UIコンポーネントをリフレッシュするまたはマネージドbeanを起動する場合に、タスクを単純化することができます。次のサンプルは、コンシューミング・リージョンのページ定義で作成するようなmethodActionバインディングおよびeventMapを示します。

<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel" id="consumerPageDef" Package="view.pageDefs">
...
<bindings>
<methodAction DataControl="AppModuleDataControl" id="EventHandlerMethod" InstanceName="${backingBeanScope.EventHandler}"
MethodName="handleEvent">
<NamedData NDName="eventPayLoad" NDType="java.lang.Object"/>
</methodAction>
</bindings>
<eventMap xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="JDemoEvent">
<producer region="*">
<consumer region="" handler="EventHandlerMethod">
<parameters>
<parameter name="eventPayLoad" value="#{data.payLoad}"/>
</parameters>
</consumer>
</producer>
</event>
</eventMap>
</pageDefinition>

46.5 プレーンJavaオブジェクト(POJO)を使用したコンテキスト・イベントの作成

リージョンに埋め込まれているバインドされたタスク・フローには、コンテキスト・イベントの潜在的なコンシューマとして公開する必要のある複数のビューがある場合があります。各ビューのプレーンJavaオブジェクト(POJO)、データ・コントロールおよびイベント・ハンドラを作成するかわりに、単一のPOJOと単一のデータ・コントロールを作成して、タスク・フロー内のすべてのビューのイベントを処理できます。

このアプローチでは、イベント・レシーバ・メソッドは、handleEventメソッドを呼び出して処理のためにpayLoadを渡すために、マネージドBean参照を使用してコンテキスト・イベント・リクエストをディスパッチします。バッキングBeanスコープで定義されたマネージドbeanには、Beanが依存ユーザー・インタフェースをリフレッシュできるようにするJSFコンポーネント参照がある場合があります。

このアプローチが機能するためには、次の条件が満たされている必要があります。

- イベント・レシーバ・メソッドは、メッセージを処理するメソッドの引数としてpayLoadを渡す必要があります。

- イベント・レシーバ・メソッドには、サブスクライバ・リージョン・タスク・フローに関連付けられているマネージドBeanにオブジェクト参照を渡すために使用される第2引数が必要です。

- 参照として渡されるマネージドBeanには、イベント・メッセージを入力引数として受け入れる一般に既知のパブリック・メソッドが含まれている必要があります。このメソッドはイベントを処理します。

46.5.1 タスク・フローに対して汎用コールバック・メッセージ・ハンドラを構成する方法

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「プレーンJavaオブジェクト(POJO)を使用したコンテキスト・イベントの作成」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

汎用イベント・レシーバおよびマネージドBeanイベント・ハンドラを作成する手順:

1. POJOデータ・コントロールを作成します。
POJOデータ・コントローラが「データ・コントロール」パネルに表示されます。

データ・コントロールの詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』のBeanデータ・コントロールの作成と構成に関する項を参照してください。

2. 2つの引数を定義するイベント・ハンドラ・メソッドで、イベント・レシーバ・クラス(POJOデータ・コントロールで公開)を作成します。
最初の引数は、コンテキスト・イベントで提供されるpayLoad用です。2番目の引数は、コンテキスト・イベント・ハンドラ・インタフェースを実装しているマネージドBeanへのコールバック・ハンドラ参照です。

3. ContextualEventHandlerインタフェースを実装するバッキングBeanスコープでマネージドBeanを作成します。
ContextualEventHandlerインタフェースの実装には、handleEvent()など、マネージドBeanに制御を渡すために汎用コンテキスト・イベント・レシーバによってコールされるコールバック・メソッドの定義が含まれます。

4. イベントを受信するタスク・フロー内のビューのページ定義ファイルにメソッド・バインディングを作成します。

a. 「アプリケーション」ウィンドウで、イベント・マップを含めるページ定義ファイルをダブルクリックします。

b. 概要エディタの「バインディングと実行可能ファイル」タブをクリックし、「バインディング」セクションの「追加」アイコンをクリックします。

c. 「アイテムの挿入」ダイアログで、「一般バインディング」カテゴリのmethodActionを選択し、イベント・レシーバ・メソッドを公開するPOJOデータ・コントロールを選択します。

d. EL式ビルダーを使用して、ContextualEventHandler引数に対して作成されたマネージドBeanを参照します。payLoad引数はコンテキスト・イベント・マッパーによって提供されるため、空白のままにします。

5. メソッド・バインディングが宣言された同じページ定義ファイルに定義することで、コンテキスト・イベントをサブスクライブします。
コンテキスト・イベントのサブスクライブの一般的な手順は、「コンテキスト・イベントをサブスクライブおよび使用する方法」の手順7から手順8に従います。

これは、ビューのコンテキストで処理されるコンテキスト・イベント・ペイロードをイベントへの応答として変更するために、構成されたマネージドBeanに対してメソッドを呼び出す汎用的で再利用可能なコンテキスト・イベント・ハンドラの実装です。

46.6 JavaScriptを使用したコンテキスト・イベントの作成

マネージドBeanからアクセスできるアクションとメソッド・バインディングはすべて、JavaScriptから呼び出すことができます。ADF Facesは、af:serverListener操作コンポーネントを提供します。これは、クライアント側JavaScriptからマネージドBeanメソッドを呼び出すために使用できます。参照されたマネージドBeanメソッドを使用してこのコンポーネントを呼び出すには、BindingContextオブジェクトを使用して、現在のBindingContainerを調べ、OperationBindingまたはJUEventBindingバインディングにアクセスします。また、af:serverListenerコンポーネントを使用して、ブラウザ・クライアントからマネージドBeanメソッドにメッセージpayloadを送信することもできます。

46.7 イベント・マップの手動作成

ほとんどの状況では、「コンテキスト・イベントの手動作成」で説明しているように、イベント・マップ・エディタを使用してイベント・マップを作成できます。しかし、プロデューサ・イベントが埋込み動的リージョン内のページから発生する場合などの状況では、設計時にイベント・マップ・エディタではイベント・マップの作成に必要な情報を取得できません。

46.7.1 イベント・マップの手動による作成方法

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「イベント・マップの手動作成」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

イベント・マップを手動で作成するには:

1. 「アプリケーション」ウィンドウで、コンシューマ用のバインディングを含むページ定義ファイルをダブルクリックします。

2. 「構造」ウィンドウで、ページ定義を表す最上位のノードを右クリックし、「pagedef名の中に挿入」→「eventMap」を選択します。

3. 「構造」ウィンドウで、「eventMap」ノードを選択して右クリックし、「eventMapの中に挿入」→「event」を選択します。

4. 「eventの挿入」ダイアログで、イベント名を入力して「OK」をクリックします。
手順3から4を繰り返して、さらにイベントを追加します。

5. 「event」ノードを選択して右クリックし、「eventの中に挿入」→「プロデューサ」を選択します。

6. 「プロデューサの挿入」ダイアログで、このイベントを生成するバインディングの名前を入力して、「OK」をクリックします。
イベント・プロデューサを持つリージョンの名前を入力することもできます。この場合、このタグの下に指定されたコンシューマはすべて、このイベントを使用できます。また、"*"を入力して、このタグの下のコンシューマすべてが使用できることを示すこともできます。

7. 「プロデューサ」ノードを選択して右クリックし、「プロデューサの中に挿入」→「コンシューマ」を選択します。

8. 「コンシューマの挿入」ダイアログで、このイベントを使用するハンドラの名前を入力して、「OK」をクリックします。
手順7から8を繰り返して、さらにコンシューマを追加します。

9. 渡すパラメータがある場合は、パラメータ名および値を追加します。

a. 「コンシューマ」ノードを選択して右クリックし、「コンシューマの中に挿入」→「パラメータ」を選択します。

b. 「パラメータ」ノードを選択して右クリックし、「パラメータの中に挿入」→「パラメータ」を選択します。

c. 「パラメータの挿入」ダイアログで、パラメータ名およびパラメータ値を入力して、「OK」をクリックします。値はEL式でもかまいません。
さらにパラメータを追加するには、この手順を繰り返します。

46.8 カスタム・ディスパッチャの登録

デフォルトでは、コンテキスト・イベント・フレームワークはEventDispatcherImplを使用して、リージョンを横断するイベントをディスパッチします。デフォルトのイベント・ディスパッチャをオーバーライドするカスタム動作を提供して、カスタム・イベント・ディスパッチャを作成することができます。デフォルトのディスパッチャをオーバーライドするには、作成したカスタム・イベント・ディスパッチャをDatabindings.cpxファイルに登録する必要があります。

46.8.1 カスタム・ディスパッチャの登録方法

始める前に:

コンテキスト・イベントの作成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「カスタム・ディスパッチャの登録」を参照してください。

また、コンテキスト・イベントで使用可能な各機能についても理解しておくと役立ちます。詳細は、「コンテキスト・イベントのその他の機能」を参照してください。

カスタム・イベント・ディスパッチャを登録するには:

1. EventDispatcherクラスに基づいて、カスタム・イベント・ディスパッチャのJavaクラスを作成します。

2. 次の形式の完全修飾名を使って、カスタム・イベント・ディスパッチャをDatabindings.cpxファイルに登録します。

EventDispatcher="package_name.CustomEventDispatcher_name"

次の例は、パッケージNewPackageに作成されたNewCustomEventDispatcherというカスタム・イベント・ディスパッチャのコードを示しています。

<Application xmlns="http://xmlns.oracle.com/adfm/application"
version="11.1.1.51.60" id="DataBindings" SeparateXMLFiles="false"
Package="project3" ClientType="Generic"
EventDispatcher="NewPackage.NewCustomEventDispatcher">

3. プロデューサのページ定義にイベントを作成します。詳細は、「コンテキスト・イベントの宣言的な作成」または「コンテキスト・イベントの手動作成」を参照してください。

4. コンシューマが動的リージョンにある場合は、コンシューマ・リージョンにイベント・マップを作成します。コンシューマが動的リージョンにはない場合でも、プロデューサ・リージョンとコンシューマ・リージョンの両方が入っている親ページにイベント・マップを指定できます。詳細は、「イベント・マップの手動作成」を参照してください。

第VI部 アプリケーションの完成

この部では、Fusion Webアプリケーションを保護、調整、テストおよびデプロイするために開発者が実行できるタスクについて説明します。

第VI部は、次の章で構成されます。

- Fusion WebアプリケーションでのADFセキュリティの有効化

- ADFコンポーネントのテストとデバッグ

- Fusion Webアプリケーションのリファクタ

- アプリケーション・コンポーネントの再利用

- MDSによるアプリケーションのカスタマイズ

- 実行時のユーザー・カスタマイズの許可

- アクティブ・データ・サービスの使用

- Fusion Webアプリケーションの高可用性の構成

- Fusion Webアプリケーションのデプロイ

- Fusion Webアプリケーションでの状態管理の使用

- アプリケーション・モジュール・プールのチューニング

47 Fusion WebアプリケーションでのADFセキュリティの有効化

この章では、Fusion WebアプリケーションでADFセキュリティを有効化して、Oracle ADFリソースのリソース権限を定義し、それらのリソースに関連するWebページをユーザーが表示できるかどうかを制限する方法を説明します。

この章の内容は次のとおりです。

- ADFセキュリティについて

- ADFセキュリティ・プロセスの概要

- ADFセキュリティの有効化

- アプリケーション・ロールの作成

- ADFセキュリティ・ポリシーの定義

- テスト・ユーザーの作成

- ログイン・ページの作成

- JDeveloperにおけるセキュリティのテスト

- セキュア・アプリケーションのデプロイの準備

- ADFセキュリティの無効化

- 高度なトピックとベスト・プラクティス

47.1 ADFセキュリティについて

ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。ADFセキュリティはOracle Platform Security Services (OPSS)アーキテクチャの上に構築されます。このアーキテクチャはそれ自体がOracle WebLogic Serverと密接に統合されています。それ以外にも、ユーザー・ログインおよびリソースの保護を処理できるセキュリティ対応モデルはありますが、ADFバインド・タスク・フロー、ADFバインディングを使用するトップレベルのWebページ(バインド・タスク・フローに含まれないページ)、および最も低いレベルの粒度でADFエンティティ・オブジェクトとその属性によって定義されたデータ列に対して宣言型で許可ベースの保護を実現するのに、ADFセキュリティは非常に適しています。このドキュメントでは、ADFセキュリティ・フレームワークが保護するこれらの個々のリソースを、ADFセキュリティ対応リソースと呼びます。

「ADFセキュリティの有効化」の説明に従い、ADFセキュリティの構成ウィザードを実行して、Fusion WebアプリケーションのADFセキュリティを有効にします。このウィザードにより、Fusion Webアプリケーション全体のADFセキュリティを構成するため、ADFセキュリティ対応リソースに関連するWebページはデフォルトで保護されます。つまり、ADFセキュリティを有効化すると、アプリケーションがロックダウンされるので、そのページはデフォルトでセキュアであるとみなされます。

ADFセキュリティを有効にしたら、ユーザーにアクセス権を付与する必要があります。これによってユーザーは、Fusion WebアプリケーションのWebページを表示できるようになります。ユーザーに付与するアクセス権は、ページのADFセキュリティ対応リソース用に指定するセキュリティ・ポリシーとして知られています。タスク・フローの入力やWebページの表示を行うユーザー権限を制御するのは、最終的にはADFリソースにおけるセキュリティ・ポリシーになります。

ADF SecurityはJava Authentication and Authorization Service (JAAS)に基づいているので、セキュリティ・ポリシーによりプリンシパル(ユーザーまたはアプリケーション・ロール)、ADFリソースおよび権限(リソースのADF権限クラスで定義される操作)が識別されます。たとえば、ADFタスク・フローのSummitサンプル・アプリケーションでは、customer-task-flowのタスク・フローにより含まれるWebページを保護し、ログイン済ユーザー(認証済ユーザー)にのみアクセス権を付与します。実行時、ADFセキュリティ・フレームワークではタスク・フローのセキュリティ・ポリシーに対して認可チェックを実行して、ユーザーに表示操作を完了する権限があるかどうかを識別します。この場合、ユーザーがチェックアウト・プロセスを完了しようとする場合は、セキュリティ・ポリシーでは表示の権限をユーザーに付与する必要があります。

ユーザーとADFリソースに対してセキュリティ・ポリシーを定義するタスクを簡略化するために、ADFセキュリティではADFバインド・タスク・フローとそこに含まれるWebページに対して1つのセキュリティ・ポリシーを定義できる包含階層を定義します。つまり、バインド・タスク・フロー・レベルでセキュリティ・ポリシーを定義すると、フローのエントリ・ポイントが保護されます。次に、そのフロー内のすべてのページが、定義されたポリシーによって保護されます。また、個々のユーザーにアクセス権を付与するかわりに、ユーザーをアプリケーション・ロールにグループ化し、そのロールにview権限を付与します。

特に、Fusion Webアプリケーションで次のADFセキュリティ対応リソースのためのセキュリティ・ポリシーを定義して、ユーザーがWebページにアクセスできるようにします。

- ADFバインド・タスク・フローはタスク・フローのエントリ・ポイントを保護します。エントリ・ポイントが、そのフローに含まれるページへのユーザーのアクセスを制御します。
たとえば、新規顧客に登録プロセスを説明する一連のWebページがあるとすると、バインド・タスク・フローによって、そのプロセスのページ・ナビゲーションが制御されます。バインド・タスク・フローの詳細は、「バインド・タスク・フローについて」を参照してください。

ADFバインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、認可チェックは行われません。バインドなしタスク・フローの構成ページを保護する必要がある場合は、ページに関連するページ定義ファイルの権限を定義します。

- Webページに関連付けられているADFページ定義ファイルは、バインド・タスク・フローに含まれません
たとえば、Webページに売上数上位の製品の要約が表示されることがありますが、これには、そのページに関連付けられたADFページ定義ファイルのADFバインディングによって調整されたデータが使用されます。ページ定義とADFバインディングの詳細は、「ページ定義ファイルの処理」を参照してください。

- ADFエンティティ・オブジェクトとエンティティ・オブジェクトの属性(データ行を参照し、ユーザー・インタフェースに表示するコレクションの定義に使用されます)
たとえば、WebページにADF Facesの表コンポーネントが表示されることがあります。これには、ADFバインディングがエンティティ・オブジェクトの属性にデータ・ソースとしてマップする列が表示されます。エンティティ・オブジェクトの場合、ADFセキュリティを有効化してもエンティティ・オブジェクト行は自動的に保護されません。エンティティ・オブジェクトまたはその属性を明示的に保護するセキュリティ・ポリシーを定義しないかぎり、ユーザーが引続きデータにアクセスできます。エンティティ・オブジェクトの詳細は、「エンティティ・オブジェクトについて」を参照してください。

JDeveloperツールではセキュリティの反復開発がサポートされるため、ADFリソースに作成するセキュリティ・ポリシーの作成、テストおよび編集が容易になります。JDeveloperでのテスト・ユーザーの作成に進み、統合WebLogic Serverでアプリケーションを実行して、保護されたリソースにエンド・ユーザーがどのようにアクセスするかをシミュレートできます。この章では、ユーザー・アイデンティティとログイン資格証明のリポジトリ(アイデンティティ・ストアと呼ばれる)を構成する方法を説明します。

注意:

この章で説明するアイデンティティ・ストアはすべて、統合WebLogic Serverでの実行を目的として作成するテスト・ユーザー・アイデンティティに関係しています。「セキュア・アプリケーションのデプロイの準備」で説明するように、Oracle WebLogic Serverにデプロイするとき、通常はこのようなユーザーをステージング環境に移行することはありません。

ADFセキュリティを有効化したが、テスト・ユーザーにアクセス権を付与するセキュリティ・ポリシーをまだ定義していないという状況を避けるため、「ADFセキュリティの構成」ウィザードでは、一時的なview権限を既存のすべてのADFリソースに付与できます(view権限が各ADFリソースのセキュリティ・ポリシーに追加されます)。ウィザードのこのオプションでは、自動付与を行わずに、各リソースの作成時にADFリソースのセキュリティ・ポリシーを定義する選択肢と、view権限を自動付与してから、セキュリティ・ポリシーを定義してその権限を1つずつ置き換える選択肢があります。セキュリティの反復開発の選択肢については、「ADFセキュリティ・プロセスの概要」で説明します。

ヒント:

ADFセキュリティを有効化し、ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義する前に、ADF認可チェックの規則を理解する必要があります。この規則を理解すると、計画しているセキュリティの実装に役立ちます。これらの規則の詳細は、「ADFセキュリティのユースケースと例」を参照してください。

47.1.1 ADFセキュリティとJavaセキュリティの統合

Fusion Webアプリケーション・リソースを保護するADFセキュリティ・モデルは、Java EEセキュリティ・モデルで使用されているセキュリティ制約のURLマッピングに基づくものではありません。実際の処理でも、セキュリティ制約はJavaServer Faces (JSF) Webアプリケーションの保護には適していません。ページ・ナビゲーションが特定のページURLでサポートされないためです。たとえば、ユーザーがタスク・フローの次のページにナビゲートしても、そのフロー内ではURLは変化しません。新しいページが表示されるときに、URLベースのセキュリティ制約をトリガーする手段がありません。

かわりに、ADFセキュリティはJava Authentication and Authorization Service (JAAS)セキュリティ・モデルを実装しています。JAASは既存のJavaセキュリティ・モデル上に構築され、すべてのJAAS実装(JAASサービスのOracle Platform Security Services (OPSS)実装も含む)と統合されるため、JAASモデルはポリシー・ベースです。URLセキュリティ制約を利用するアプリケーションがセキュリティ非対応となるのは、セキュリティを管理するためにJava EEコンテナに依存するためです。これに対して、Fusion Webアプリケーションは、ユーザー定義ポリシーに基づいてリソースへのアクセスを認可するために、ADFセキュリティ・フレームワークへの明示的なコールを必要とします。つまり、ADFセキュリティを有効化して、ADFリソースのアクセス・ポリシーを定義したときに、アプリケーションがセキュリティ対応になります。

ADFセキュリティによりJAAS認可モデルの実装が簡略化されます。この実装では、ADFリソースに対するセキュリティ・ポリシーを宣言して公開し、それらのリソースに対する認可チェックを実行時に行うことで、セキュリティ対応アプリケーションの作成に必要な作業を最小限に抑えます。

JDeveloperのポリシー・ストアはファイルベースで、ADFリソースのセキュリティ・ポリシーを定義する権限と呼ばれるエントリのリストを含みます。権限エントリには、保護対象のリソースに操作(たとえば、ADFバインド・タスク・フローに関連付けられたWebページへのアクセス)を実行するためにユーザーに付与されるすべての権限が含まれます。権限はポリシー・ストアでアプリケーション・ロール・プリンシパルに対して付与されます。

ADFセキュリティによってJAASモデルが拡張されます。ADFセキュリティ・フレームワーク権限クラスで指定されるアクションを使用して権限を定義できるようになります。このようなクラスはADFリソースに固有であり、リソースでサポートされる操作にアクションをマッピングします。Fusion Webアプリケーションのポリシー・ストアに含まれる権限では、次の項目が指定されます。

- リソースの権限クラスによって定義されるアクションと、アプリケーションのADFリソース・インスタンスを関連付ける、1つ以上の権限(現在、バインド・タスク・フローとページ定義リソースでサポートされるのはviewアクションのみです)

- 権限の付与先として、アプリケーションによって定義されるアプリケーション・ロール(同じアクセス権を付与するメンバー・ユーザーまたはエンタープライズ・ロール(オプション)を移入します)

エンティティ・オブジェクトの場合、権限クラスはエンティティ・オブジェクトのread、removeCurrentRowおよびupdate操作に対応するread、deleteおよびupdateアクションを定義します。

ADF権限クラスとサポートされるアクションの詳細は、「ADFセキュリティ権限の付与」を参照してください。

47.1.2 ADFセキュリティのユースケースと例

ADFセキュリティを使用すると、Webアプリケーションを現実のビジネス・セキュリティ要件に適応させやすくなります。アプリケーション・リソースへのパスを保護するのではなく、JAASによってADFリソースに対する表示操作を保護するためです。JAASベースのADFセキュリティでは次の機能が提供されます。

- ADFリソース(バインド・タスク・フローなど)の宣言セキュリティのサポート
Java EEセキュリティはURLベースまたはページベースであるため、カスタム・コードなしではナビゲーションを制御できません。ADFセキュリティでは、ユーザーがタスク・フローを開始できるかどうかを制御できます。つまり、タスク・フローに対する1つのセキュリティ・ポリシーによって、複数のWebページへのアクセスを制御できます。また、宣言セキュリティではアクセス・パスではなくADFリソースを保護できるため、アプリケーションの別の場所でADFリソースを再利用するときも、保護された状態が維持されます。

- 権限の継承を可能にするアプリケーション・ロールを使用した権限割当ての簡略化
Java EEセキュリティ制約で使用されるJava EEセキュリティ・ロールが平面的であるのに対し、JAAS権限を付与するアプリケーション・ロールはネストすることができ、Oracle WebLogic Serverドメインが定義するエンタープライズ・ロールにマップすることもできます。

- セキュリティ・コンテキストで、ADFリソースにアクセスするためにEL式で使用するユーティリティ・メソッド
ADFセキュリティのEL式ユーティリティ・メソッドを使用すると、ユーザーが既知の操作を実行できるかどうかを判定することができます。たとえば、ユーザーが特定のタスク・フローを表示できるかどうかを判定することができます。

また、JDeveloperを使用すると、統合WebLogic Serverでセキュリティをテストするためのテスト・ユーザーとパスワードをすぐに作成できます。Oracle WebLogic Serverにデプロイする準備ができたら、アプリケーション固有の認可ポリシーをサーバーに移行できます。管理者はアプリケーションがLDAPユーザー・リポジトリを使用するように構成できます。

表47-1に、ADFセキュリティの有効化がアプリケーションや様々なADFセキュリティ対応リソースに及ぼす影響をまとめています。ADFセキュリティを最も効果的に使用する方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。

表47-1 ADFセキュリティ対応リソースのサマリー

ADFリソース

ADFによるセキュリティの施行方法

アクセス権の付与方法

すべてのユーザー・インタフェース・プロジェクトのバインド・タスク・フロー

デフォルトで保護されます。ユーザーがバインド・タスク・フローを開始するために権限が必要です。

タスク・フローの権限を定義します。

バインド・タスク・フローのWebページに関連付けられている個々のページ定義ファイルの権限は、定義しないでください。

すべてのユーザー・インタフェース・プロジェクトのページ定義ファイル

デフォルトで保護されます。ページ定義に関連付けられたページをユーザーが表示するために権限が必要です。

Webページがバインド・タスク・フローに含まれる場合は、このタスク・フローに対する権限を定義します。

Webページがバインド・タスク・フローに含まれない場合、またはWebページがバインドなしタスク・フローに含まれる場合は、ページ定義のみの権限を定義します。

バインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、権限を定義できないことに注意してください。

データ・モデル・プロジェクトのエンティティ・オブジェクト

デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。

データ・コレクション全体レベルでアクセスを制御する必要がある場合のみ、データを保護するためにエンティティ・オブジェクトの権限を定義します。保護対象のエンティティ・オブジェクトを参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。

エンティティレベルのセキュリティは注意して使用してください。または、エンティティ属性レベルでのセキュリティの定義を検討します。

データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。

データ・モデル・プロジェクトのエンティティ・オブジェクトの属性

デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。

データ・コレクションの列レベルでアクセスを制御する必要がある場合は、データを保護するためにエンティティ・オブジェクト属性の権限を定義します。保護対象のエンティティ属性を参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。

データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。

47.1.3 ADFセキュリティの追加機能

ADFセキュリティの処理を開始する前に、その他のOracle ADF機能を理解しておくと役に立ちます。次に、関連する他の機能へのリンクを示します。

- Oracle Platform Security Servicesのセキュリティ機能の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

47.2 ADFセキュリティ・プロセスの概要

Fusion WebアプリケーションのADFリソースを保護するときはJDeveloperを使用します。ADFセキュリティでは、アプリケーションのバインド・タスク・フロー、およびバインドなしタスク・フローに含まれるすべてのWebページが保護されます。この保護を有効にするには、「ADFセキュリティの構成」ウィザードを実行し、その後、ADFセキュリティ・ポリシーを定義して各リソースのユーザー・アクセス権を定義します。

アプリケーションのユーザー・インタフェースを作成するときは、「ADFセキュリティの構成」ウィザードをいつでも実行できます。選択肢は次のとおりです。

- UIプロジェクトのWebページの作成と、関連するADFリソースのセキュリティ・ポリシーの定義を繰り返しながら行います。

- UIプロジェクトのすべてのWebページの作成を完了してから、関連するADFリソースのセキュリティ・ポリシーを定義します。

注意:

Fusion Webアプリケーションの保護に進む前に、「ADFセキュリティのユースケースと例」で説明されているADFセキュリティ・モデルについてよく理解する必要があります。

設計とテストの反復プロセスは、様々な設計時ツールでサポートされています。

新しいバインド・タスク・フローまたはADFページ定義ファイルをユーザー・インタフェース・プロジェクトで作成するたびに、新しいADFリソースがjazn-data.xmlファイルの概要エディタに表示されます。このエディタは、セキュリティ・ポリシーの概要エディタとも呼ばれます。概要エディタを使用し、アプリケーション全体に関してWebページに関連付けられたADFリソースのセキュリティ・ポリシーを定義します。また、概要エディタを使用してADFリソースをソートすると、セキュリティ・ポリシーがまだ定義されていないADFリソースを簡単に見つけることができます。

ADFアイデンティティ・ストアの少数のテスト・ユーザーをプロビジョニングするには、別のエディタを使用します。JDeveloperに作成するアイデンティティ・ストアを使用して、ユーザー資格証明(ユーザーIDとパスワード)を定義できます。エディタには、作成するユーザーと、ユーザーを割り当てるアプリケーション・ロールの関係も表示され、ADFセキュリティ・ポリシーで定義されるアクセス権を付与することができます。

JDeveloperは設計時に、ポリシー・ストアとアイデンティティ・ストアのすべての変更内容をアプリケーション全体で1つのファイルに保存します。開発環境では、これはjazn-data.xmlファイルです。エディタを使用してjazn-data.xmlファイルを構成すると、統合WebLogic Serverでアプリケーションを実行でき、ポリシー・ストアの内容がドメインレベルのストア(system-jazn-data.xmlファイル)に追加されます。また、テスト・ユーザーは、統合WebLogic Serverがアイデンティティ・ストアとして使用する埋込みLDAPサーバーに移行されます。ドメインレベルのストアを使用すると、作成したテスト・ユーザーとしてログオンしてセキュリティ実装をテストできます。

セキュリティに関するすべての設計時ツールは、図47-1に示すように、メイン・メニューの「アプリケーション」→「保護」メニューを使用してアクセスします。

図47-1 ADFセキュリティの設計時ツールの利用

設計フェーズ

ADFセキュリティを有効化し、JDeveloperで実行するアプリケーションに対するポリシー・ストアを設定するには:

1. 「ADFセキュリティの構成」ウィザードを実行することにより、動的認証を許可し、認可を実施するためにADFセキュリティを有効化します。
ウィザードの実行時に動的認証のみを有効にすることを選択した場合は、残りの設計フェーズのステップはスキップします。このウィザードを使用して、Oracle WebLogic Serverでセキュリティ・フレームワークとOPSSを統合するファイルを構成します。

2. ADFセキュリティ対応リソースを作成します。構成Webページ(またはリージョン)を含むバインド・タスク・フロー、またはADFバインディングを使用して設計される最上位Webページ(またはリージョン)などです。
注意: 「ADFセキュリティの構成」ウィザードを実行すると、ADFセキュリティ対応リソースに関連付けられるすべてのWebページが保護されます。つまり、アプリケーションを実行してセキュリティをテストする前に、Webページをアクセス可能にするためにセキュリティ・ポリシーを定義する必要があります。

3. ADFセキュリティ対応リソースと、作成した1つ以上のアプリケーション・ロールを関連付けます。
作成するアプリケーション・ロールはアプリケーションに固有であり、これを使用すると、同じレベルのアクセス権を一連のユーザー(またはメンバー・ユーザー)に付与することができます。テスト・フェーズではユーザーをいくつか作成し、作成したアプリケーション・ロールのメンバーとして追加します。

4. ADFセキュリティ対応リソースおよび関連する各アプリケーション・ロールにview権限を付与します。
こうすることでアプリケーション・ロールのメンバー・ユーザーにアクセス権が与えられます。権限がないとユーザーはADFセキュリティ対応リソースにアクセスできません。テスト・フェーズでは、いくつかのユーザーを作成してアプリケーション・ロールに追加します。

テスト・フェーズ

統合WebLogic Serverを使用してアイデンティティ・ストアをプロビジョニングし、セキュリティをテストするには:

1. ユーザーをいくつか作成します。また、必要に応じてエンタープライズ・ロールを作成します。
定義したユーザーIDとパスワードを使用してアプリケーションにログインします。エンタープライズ・ロールは、ユーザーをグループ化して、そのグループにアプリケーション・ロールを関連付けるための論理ロールです。エンタープライズ・ロールはテストのためには必要ありません。詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。

2. 作成したユーザーおよびエンタープライズ・ロール(オプション)を1つ以上のアプリケーション・ロールに関連付けます。
メンバー・ユーザー複数のアプリケーション・ロールのアクセス権を付与する必要がある場合は、1メンバー・ユーザーを複数のアプリケーション・ロールに含めることができます。

3. デフォルトのログイン・ページをカスタム・ログイン・ページで置き換えます(オプション)。
「ADFセキュリティの構成」ウィザードで生成されるデフォルトのログイン・ページは、ADF Facesコンポーネントを利用できません。これは、ADFセキュリティ・ポリシーのテスト用としてのみ便宜的に提供されています。カスタム・ログイン・ページは、ADF Facesコンポーネントを使用するように設計できます。

4. JDeveloperでアプリケーションを実行し、任意のADFセキュリティ対応リソースにアクセスします。
最初にADFセキュリティ対応リソースにアクセスしようとするとき、セキュリティ・フレームワークによってログインを求められます。

5. ログインし、予定どおりにページとそのリソースにアクセスできることを確認します。
ログインすると、セキュリティ・フレームワークによって、リソースにアクセスするためのユーザーの権限がチェックされます。たとえば、予期していない401未認可ユーザーのエラーを受け取った場合は、「ADFセキュリティの操作のベスト・プラクティス」に従って権限を作成したことを確認します。

ステージングの準備

ステージング環境または本番環境でOracle WebLogic Serverにデプロイするためにセキュア・アプリケーションを準備するには:

1. すべてのADFセキュリティ対応リソースについてtest-allロールのすべての権限を削除し、定義した権限で置き換えます。
ADFリソースはデフォルトで保護されるため、アプリケーションをテストする開発者にview権限が付与されるのは、セキュリティ・ポリシーが定義された後です。「ADFセキュリティの構成」ウィザードでは、test-allロールに対して、すべてのADFリソースへのアクセスを可能にする権限を生成するオプションがあります。企業のセキュリティを危険にさらさないために、test-allロールに対するすべての一時権限は、自ら定義した明示的な権限でいずれ置き換える必要があります。

2. 作成したすべてのユーザー・アイデンティティを削除します。
JDeveloperはアイデンティティ・ストアのプロビジョニング・ツールとして使用しないでください。また、テスト目的で作成したユーザー・アイデンティティをアプリケーションとともにデプロイしないように注意してください。ユーザー・アイデンティティをアプリケーションとともにデプロイすると、悪質なユーザーが予想外のアクセス手段を獲得してしまう恐れがあります。かわりに、ドメインレベルのアイデンティティ管理システムによって提供されるツールを使用して、ユーザー・アイデンティティを構成する作業を、システム管理者が担当します。

3. ポリシー・ストアに表示されるアプリケーション・ロールが、最終的に管理者がドメインレベルのグループにマッピングするロールであることを確認します。

4. ADF Facesリソース・ファイルを保護するセキュリティ制約を定義するかどうかを決定します。
リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)とは、アプリケーションの個々のページをサポートするためにFusion Webアプリケーションがロードするファイルです。これらのファイルはADFセキュリティによって保護されませんが、アプリケーションにアクセスしようとするすべてのユーザーを認証する必要がある場合は、それらのファイルのJava EEアクセス・パスを保護できます。

5. 完成したポリシー・ストアと資格証明ストアをターゲット・サーバーに移行します。
アプリケーションがOracle WebLogic環境のサーバーにデプロイされると、アプリケーションのポリシーと資格証明は自動的にドメイン・ポリシー・ストアに移行されます。これらのストアの自動的な移行は、ターゲット・サーバーの構成によって制御されます。JDeveloper外部でデプロイメントを実行するためにOracle Enterprise Managerを使用する場合、移行構成設定はこのツールで指定できます。jazn-data.xmlセキュリティ・ポリシーおよびcwallet.sso資格証明の移行の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」を参照してください。

47.3 ADFセキュリティの有効化

ADFセキュリティをOPSSに統合するための構成プロセスを単純にするため、JDeveloperでは「ADFセキュリティの構成」ウィザードが用意されています。このウィザードは、ADFセキュリティを使用してFusion Webアプリケーションを保護する開始ポイントとなります。このウィザードはアプリケーションレベルのツールなので、実行すると、アプリケーションに含まれるすべてのユーザー・インタフェース・プロジェクトでADFセキュリティが有効になります。

注意:

「ADFセキュリティの構成」ウィザードにより、アプリケーションのすべてのユーザー・インタフェース・プロジェクトに対してADFセキュリティが有効になります。このウィザードを実行した後で、バインド・タスク・フローに含まれる任意のWebページや、ADFページ定義に関連付けられたすべてのWebページを表示するための権限をユーザーに許可する必要があります。したがって、ウィザードを実行した後では、セキュリティ・ポリシーを定義してユーザーにview権限を付与するまで、アプリケーションは基本的にロックダウンされます。このプロセスの概要は、「ADFセキュリティ・プロセスの概要」を参照してください。

47.3.1 ADFセキュリティを有効化する方法

「ADFセキュリティの構成」ウィザードでは、認証と認可を個別に有効化することを選択できます。選択肢は次のとおりです。

- ユーザー認証のみを有効化します。
ADFセキュリティでは認証にJava EEコンテナ管理のセキュリティを利用しますが、認証のみを有効化すると、ユーザーのログインとログアウトにはADF認証サーブレットを使用し、Webページの保護にはコンテナ管理のセキュリティ制約を定義することになります。

- ユーザー認証を有効化し、認可も有効化します。
認可を有効化することは、ADFリソースに対してセキュリティ・ポリシーを作成することで、Fusion Webアプリケーションに対するアクセスの制御を意図することを意味します。

ADFセキュリティ・フレームワークではこれら2つの方法がサポートされるため、Java EEセキュリティを実装した上で、ADF認証サーブレットを使用したログインとログアウトに対応することができます。ADF認証サーブレットを有効化する利点は、ユーザーがアプリケーションに最初にアクセスするとき、サーブレットが自動的にユーザーにログインを求めることです。ADF認証サーブレットでも、認証が正常に終了すると、定義された開始ページにユーザーがリダイレクトされ、リクエストURLでターゲット・ページを渡す必要はありません。また、ユーザーがアプリケーションからログアウトする際にページ・リダイレクトを管理することもできます。ADFセキュリティで提供されるこのようなリダイレクト機能は、コンテナ管理セキュリティだけを使用する場合にはありません。

「実行時に行われる処理: ADFセキュリティによる認証の処理」で説明されているように、ADFセキュリティでは認証は実行されませんが、Java EEコンテナを利用して構成済のログイン・メカニズムが起動されます。

ベスト・プラクティス

Java EEセキュリティ制約では、タスク・フローと連動してタスク・フローの現在のページを保護することはできません。このため、ADFタスク・フローを含むようにアプリケーションが設計されている場合、コンテナ管理セキュリティは効果的なソリューションではありません。ADFタスク・フローを使用する場合は、「ADFセキュリティの構成」ウィザードで「ADF認証および認可」オプションを選択します。このオプションを選択すると、セキュリティ・ポリシーを定義してアプリケーションのタスク・フローを保護できます。

ADFセキュリティはWebコンテナに認証を委任するため、「ADFセキュリティの構成」ウィザードを実行すると、ウィザードによってWebコンテナで使用する認証方式の構成を求められます。認証で最も一般的に使用されるタイプは、HTTP Basic認証とフォームベース認証です。Basic認証では、ユーザーがユーザー名とパスワードを入力できるようにブラウザのログイン・ダイアログが使用されます。Basic認証の場合、ユーザーからの資格証明がブラウザによりキャッシュされるため、ログアウトできないことに注意してください。Basic認証は、カスタム・ログイン・ページを作成しないでアプリケーションをテストする場合に便利です。フォーム認証では、アプリケーションの開発者がカスタムのログインUIを指定することができます。フォームベース認証を選択すると、ウィザードを使用して単純なログイン・ページを生成することもできます。デフォルトのログイン・ページは、統合WebLogic Serverでアプリケーションをテストするときに役立ちます。

注意:

生成されるログイン・ページは単純なJSPファイルまたはHTMLファイルであるため、ADF Facesコンポーネントを使用して変更することはできません。ADF Facesコンポーネントを使用するカスタム・ログイン・ページでデフォルトのログイン・ページを置き換える方法の詳細は、「ログイン・ページの作成」を参照してください。

始める前に:

「ADFセキュリティの構成」ウィザードの知識があると役立ちます。詳細は、「ADFセキュリティの有効化」を参照してください。

アプリケーションに対してADFセキュリティを有効化するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「ADFセキュリティの構成」を選択します。

2. 「ADFセキュリティ」ページではデフォルトで「ADF認証および認可」オプションが選択されています。「次へ」をクリックします。

デフォルト・オプションが選択された状態でウィザードを実行すると、アプリケーションはADFセキュリティ対応リソースの認可を施行します。ADFリソースの認可の施行とは、アプリケーションのWebページにアクセスできるようにするために、それらのリソースに対するセキュリティ・ポリシーを定義することを意味します。定義を行うまでは、ADFバインド・タスク・フローに依存するすべてのページとADFページ定義は保護された状態になります。

ADFセキュリティを構成するためのウィザードの他の2つのオプションは、ADFセキュリティを有効化する場合は使用しないでください。これらのオプションを使用すると、一時的にADFセキュリティを無効化して、「ADFセキュリティの無効化」で説明するようにセキュリティ保護なしでアプリケーションを実行できます。

具体的には図47-2に示すように、ウィザードの最初のページには3つのオプションがあり、デフォルトのオプションとして「ADF認証および認可」が有効になっています。

- 「ADF認証および認可」(デフォルト)では、ADF認証サーブレットが有効化され、ユーザーがログインおよびログアウトする際に構成済のWebページにリダイレクトできます。このオプションを使用すると、ADF認可を有効化して、ADFリソースについて定義したセキュリティ・ポリシーに対する認可チェックを施行することもできます。このオプションを選択した場合は、アプリケーション・ロールを定義し、明示的な権限をそのロールに割り当てて、ADFセキュリティ対応リソースへのアクセスを管理します。

- 「ADF認証」を選択すると、アプリケーションのページが最初にアクセスされたときに、ADF認証サーブレットがユーザーのログインを要求します。また、Java EEアプリケーション・ルート「/」をJava EEセキュリティ制約(ユーザー認証をトリガーする)にマップすることで、ページ・リダイレクトがサポートされます。ウィザードによりADF認可が無効になるため、ADFリソースに対するセキュリティ・ポリシーが存在するかどうかに関係なく、認可チェックは実行されません。一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。

- 「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効化され、ADF Securityはポリシー権限を確認できなくなりますが、既存のポリシー・ストアは変更されません。この場合、標準的なJava EEセキュリティを使用して、ユーザーに対して、ログインし、認証を受け、URLセキュリティ制約に対してアクセス権をテストすることことを求めることができます。ウィザードをこのオプションで実行すると、ADFリソースに対するきめ細かいセキュリティが無効になることに注意してください。

図47-2 セキュリティ対応リソースを有効化するための「ADFセキュリティの構成」ウィザードの使用

3. 「認証タイプ」ページで、ユーザーがログイン情報を送信したときにアプリケーションで使用する認証タイプを選択します。「次へ」をクリックします。

ADF認証サーブレットがBasic認証で作動せず、ログアウトしたユーザーがリソースにアクセスできるという問題が明らかになっています。Basic認証のかわりにフォームベース認証を使用してください。この問題の詳細は、「Fusion Webアプリケーション・ログアウトおよびブラウザ・キャッシュに関する必知事項」を参照してください。

「フォームベース認証」を選択した場合は、「デフォルト・ページの生成」を選択して、ウィザードでデフォルトのログイン・ページおよびエラー・ページを生成できます。デフォルトでは、図47-3に示すように、ウィザードによって、ユーザー・インタフェース・プロジェクトのトップ・レベルに、ログイン・ページとエラー・ページが生成されます。場所を変更する場合は、ユーザー・インタフェース・プロジェクトを基準としたフルパスを指定します。

図47-3 単純なログイン・ページを生成するための「ADFセキュリティの構成」ウィザードの使用

4. 「自動ポリシー付与」ページでは、デフォルトで選択されている「自動付与なし」オプションをそのままにしておきます。「次へ」をクリックします。

「自動付与なし」を選択すると、アプリケーション固有の明示的な権限を定義する必要があります。test-allアプリケーション・ロールを使用すると、ADF認可により施行される制限アクセスなしで、アプリケーション・リソースを実行してテストできるので便利です。ただし、このようにすると、アプリケーションの一部のリソースが保護されない状態になるリスクが高まります。

または、ウィザードを使用してtest-allアプリケーション・ロールに権限を付与できます。test-allロールへの権限付与を有効化すると、アプリケーションのアクセス・ポリシーを調整する用意ができるまで、ADFリソースに対する明示的な権限の定義を延期することができます。自動付与の有効化を決めた場合は、test-allロールの権限をアプリケーションの明示的な権限で置き換えるまで、アプリケーション開発をあまり進めずに、アプリケーションの内容が確定してしまわないようにしてください。明示的な権限により、ユーザーがこれらのリソースにアクセスするために必要な権限(たとえばページのview)が確立されます。test-allロールの詳細は、「組込みtest-allアプリケーション・ロールを使用する方法」を参照してください。

5. 「認証されたようこそページ」で、ログイン後にユーザーを特定のWebページに移動させる場合またはセッション・タイムアウトによりセッションが失われた後にデフォルトの宛先ページを定義する場合に「認証の成功時にリダイレクト」を選択します。「次へ」をクリックします。

「認証の成功時にリダイレクト」オプションを未選択のままにし、アプリケーションでAuthenticationService APIを使用して明示的にログイン・リダイレクトを処理しない場合、ユーザーはデフォルトでログインを開始したページに戻されます。ただし、ユーザーが[Ctrl]を押しながら[N]を押すか[Ctrl]を押しながら[T]を押して新しいブラウザ・ウィンドウまたはタブを開くと、ようこそページの定義がアプリケーションのweb.xmlファイルにない場合は、403エラーまたは404エラーを受け取ります。このオプションを使用して、ようこそページを指定すると、その定義がアプリケーションのweb.xmlファイルに追加されます。

指定するWebページにADF Facesコンポーネントが含まれる場合、/faces/のコンテキストでページを定義する必要があることに注意してください。たとえば、adffaces_welcome.jspxのパスは、「ようこそページ」フィールドに、/faces/adffaces_welcome.jspxと表示されます。

他のリダイレクト・オプションの指定の詳細は、「認証後にユーザーをリダイレクトする方法」を参照してください。

6. サマリー・ページで選択内容を確認し、「終了」をクリックします。

47.3.2 ADFセキュリティを有効にしたときの処理

「ADFセキュリティ」ページでデフォルトの「ADF認証および認可」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、次のようになります。

- ADF認証が有効化されます。ユーザーにログインを求め、ページ・リダイレクトを行います。

- ADF認可チェックが有効化され、認可ユーザーのみがADFリソースにアクセスできます。

ウィザードによりセキュリティ関連の構成ファイルがすべて更新され、デフォルトでADFリソースがセキュリティ保護されます。表47-2に、ADFセキュリティの設定ウィザードにより更新されるファイルを示します。

表47-2 ADF認証および認可で更新されるファイル

ファイル

ファイルの場所

ウィザードの構成

web.xml

ユーザー・インタフェース・プロジェクトに相対する/public_html/WEB-INFディレクトリ

JDeveloperでは、ユーザー・インタフェース・プロジェクト内の「Webコンテンツ」→WEB-INFノードの下

- Oracle JpsFilterフィルタを定義して、OPSSポリシー・プロバイダを設定します。フィルタで定義される設定により、サーブレットが特殊な権限を持つことが示されます。JpsFilterをweb.xmlファイルの最初のフィルタ定義にすることが重要です。

- Oracle adfAuthenticationサーブレット定義を追加します。これは、ユーザーがADFリソースに最初にアクセスするときにログインを求めます。ADFセキュリティ自体は認証を実行しませんが、Java EEコンテナ管理のセキュリティをこの目的で利用します。

- ウィザードで「ADF認証および認可」オプションを選択すると、web.xmlによって、ユーザー認証を動的にトリガーするセキュリティ制約にadfAuthenticationサーブレットがマッピングされます。

- ウィザードで「ADF認証」オプションを選択すると、web.xmlによって、ユーザー認証を動的にトリガーするallPagesセキュリティ制約に、Java EEアプリケーション・ルート「/」がマッピングされます。

- ユーザー・ログインを処理するためのログイン構成の認証方式を設定します。

- ウィザードで「認証の成功時にリダイレクト」オプションを選択すると、web.xmlによってsuccess_urlサーブレット初期化属性(init-param要素)が定義され、これにより、ログインが成功した場合に使用するリダイレクト宛先がホワイトリスト登録され、1. AuthenticationService APIを使用してログイン・リダイレクトを処理しないアプリケーションのための1つの固定されたフォールバックと、2.　セッション・タイムアウトによりセッションが失われた場合のデフォルトの宛先ページが指定されます。

- valid-usersロールなど、動的認証を有効化するセキュリティ制約をトリガーするために使用される必須セキュリティ・ロールを定義します。

adf-config.xml

Webアプリケーション・ワークスペースに相対する/.adf/META-INFディレクトリ

JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→ADF META-INFノードの下

- JAASセキュリティ・コンテキストを定義します。

- 認可チェックのためにADFセキュリティ・ポリシーを使用できるようにします(<JaasSecurityContext>要素のauthorizationEnforceパラメータがtrueに設定されます)。

- Java SEアプリケーションでログイン・ダイアログのトリガーを有効にします(<JaasSecurityContext>要素のauthenticationRequireパラメータをtrueに設定します)。このパラメータは、Fusion Webアプリケーションでは使用されません。Fusion Webアプリケーションでは、認証を有効にする際にweb.xmlファイルの設定が使用されます。

jps-config.xml

Webアプリケーション・ワークスペースに相対する/src/META-INFディレクトリ

JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノードの下

- OPSSセキュリティ・サービスは、特にJDeveloperの設計時に有効にします。
Oracle ADFモデル・テスターを使用してデータ・モデル・プロジェクトをテストする場合、またはセキュリティ検証のユニット・テストを実行する場合は、ワークスペース固有のこのファイルが存在している必要があります。このファイルは、デプロイ済のFusion Webアプリケーションでは使用されません。たとえば、統合WebLogic Serverにデプロイする場合は、DefaultDomain/config/fmwconfig/jps-config.xmlファイルによってOPSSセキュリティ・サービスが有効化されます。

weblogic.xml

Webアプリケーション・ワークスペースに相対する/public_html/WEB-INFディレクトリ

JDeveloperでは、ユーザー・インタフェース・プロジェクト内の「Webコンテンツ」→WEB-INFノードの下

- valid-usersセキュリティ・ロールをusersという暗黙のグループにマッピングします。Oracle WebLogic Serverにより、すべての認証済ユーザーがusersグループのメンバーとして構成されます。

jazn-data.xml

Webアプリケーション・ワークスペースに相対する/src/META-INFディレクトリ

JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノードの下

- 統合WebLogic Serverで使用するために構成するXMLアイデンティティ・ストアのデフォルトのjazn.comレルム名を設定します。
このファイルは、ADFセキュリティ対応のアプリケーションのユーザー・アイデンティティ、ユーザー・グループおよびセキュリティ・ポリシーを格納するために使用します。このファイルはデプロイ時に使用され、Oracle ADFモデル・テスターの実行時にセキュリティのサポートを有効にします。ただし、統合WebLogic Serverなどにアプリケーションをデプロイする場合、DefaultDomain/config/fmwconfig/system-jazn-data.xmlファイルで構成されているポリシー・ストアにセキュリティ・ポリシーが移行されます。

認証はWebコンテナに委任されるため、ウィザードはweb.xmlファイルのみを更新し、ADF認証サーブレットが動的に認証をトリガーできるようにします。次の例に示すように、ADF認証サーブレットのサーブレット・マッピングが定義され、2つのJava EEセキュリティ制約allPagesおよびadfAuthenticationがweb.xmlファイルに追加されます。

<servlet>
<servlet-name>adfAuthentication</servlet-name>
<servlet-class>
oracle.adf.share.security.authentication.AuthenticationServlet
</servlet-class>
<init-param>
<param-name>success_url</param-name>
<param-value>faces/welcome</param-value>
</init-param>
<init-param>
<param-name>end_url</param-name>
<param-value>faces/welcome</param-value>
</init-param>
<init-param>
<param-name>disable_url_param</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
...
<servlet-mapping>
<servlet-name>adfAuthentication</servlet-name>
<url-pattern>/adfAuthentication</url-pattern>
</servlet-mapping>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>allPages</web-resource-name>
<url-pattern>/</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>valid-users</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>adfAuthentication</web-resource-name>
<url-pattern>/adfAuthentication</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>valid-users</role-name>
</auth-constraint>
</security-constraint>

例で示されているinit-param要素によって定義されるサーブレット初期化属性は、ログインおよびログアウトが成功した場合のリダイレクトを制御します(それぞれsuccess_urlおよびend_url)。これらのinit-param要素により、ログイン時およびログアウト時のリダイレクト・ターゲットがアプリケーションによって指定されない場合のデフォルトまたはフォールバック宛先が指定されます。この場合、未検証のリダイレクトの発生を防ぐ固定宛先ホワイトリストがADF認証サーブレットに定義されます。サーブレット初期化属性disable_url_paramを必要に応じてweb.xmlのサーブレットのinit-paramリストに追加して、success_urlおよびend_urlがブラウザURLで渡されないようにすることで、ブラウザURL上のこれらのパラメータを利用する悪意のあるリダイレクト攻撃をある程度防止できます。このリダイレクト保護は、特にアプリケーションがAuthenticationService APIを使用してログインおよびログアウト・リダイレクトをサポートする場合に適切に機能し、リダイレクトURLパラメータはユーザーが変更できないセッション属性として格納されます。

サーブレットのinit-param要素disable_url_paramによる保護は、選択する必要があり、デフォルトでは無効になっています。リダイレクト・パラメータをブラウザURLリクエストで渡すレガシー・アプローチを使用する既存のアプリケーションでは、disable_url_param属性を有効にしないでください。新しいアプリケーションでは、例に示すように選択(disable_url_paramをtrueに設定)して、success_urlおよびend_urlがブラウザURLで使用されないようにすることをお薦めします。

allPages制約は「/」URLにマッピングされるため、Java EEアプリケーション・ルートを保護します。このマッピングにより、ADFセキュリティがアクセスされる前でも、Oracle WebLogic Serverコンテナがユーザー認証を動的にトリガーできるようになります。ユーザーがアプリケーションに最初にアクセスするときに、コンテナがユーザーにユーザー名とパスワードを求めるように強制します。その後、ユーザーがADFセキュリティで保護されたページにアクセスするときは、ユーザーを認証したりADF認証サーブレットにリダイレクトしたりする必要はありません。

注意:

ログインを明示的にトリガーするログイン・リンクまたはログイン・ボタンを用意する場合は、allPages制約をweb.xmlファイルから削除できます。ログアウトを実行するリンクまたはボタンも用意します。ログインとログアウトを実行するカスタム・コンポーネントの作成方法の詳細は、「ログイン・ページの作成」を参照してください。動的認証を許可するために制約を保持する場合は、Java EEアプリケーション・ルートの下位項目すべてがこの制約の対象になるため、「カスタム・ログイン・ページのリソースを明示的な認証時にアクセス可能にする方法」で説明するように、サポートするリソースが実行時にログイン・ページに表示されないことがあります。

アプリケーションのすべてのユーザーがログインできる必要があるため、adfAuthenticationリソースに定義されるセキュリティ制約を使用すると、すべてのユーザーがこのWebリソースにアクセスできるようになります。このように、制約に関連付けられるセキュリティ・ロールはすべてのユーザーを含む必要があります。このタスクを簡略化するため、Java EE valid-usersロールが定義されています。weblogic.xmlファイルでは、このロールが、Oracle WebLogic Serverによって定義された暗黙のusersグループにマッピングされます。「valid-usersロールに関する必知事項」で説明するように、Oracle WebLogic Serverは、正しく認証されたすべてのユーザーをusersグループのメンバーとして構成するため、このマッピングにより、すべてのユーザーがこのロールを持つことが保証されます。

注意:

adfAuthenticationリソース制約は、ADF認証サーブレットに対して1つの標準URLパターンの定義を提供します。このADF認証サーブレットのURLパターンを参照する明示的なログイン・リンクまたはログアウト・リンクをWebページに表示できます。この明示的なログイン・シナリオは、「ADFセキュリティの構成」ウィザードで単純なログイン・フォームを生成し、ADF認証を利用してユーザーにログインを求めるかわりに使用できます。明示的なログイン・シナリオの処理の詳細は、「ログイン・ページの作成」を参照してください。

認可を有効化するため、ウィザードはadf-config.xmlファイルを更新し、次の例に示すように<JaasSecurityContext>要素のauthorizationEnforceパラメータをtrueに設定します。

<JaasSecurityContext
initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory"
jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
authorizationEnforce="true"
authenticationRequire="true"/>

認可が有効化されると、ユーザーがコンテナによって認証された後で、ADFセキュリティ・コンテキストがHttpServletRequestからユーザー・プリンシパルを取得します。ユーザーはユーザー名とパスワードを送信し、そのデータがユーザー情報が格納されているアイデンティティ・ストアのデータと比較されます。一致するデータが見つかると、要求の発信元(ユーザー)が認証されます。その後、ユーザー・プリンシパルはADFセキュリティ・コンテキストに格納され、認可権を判別するために他のセキュリティ関連情報(ユーザーが所属するグループなど)を取得する際にアクセスできます。ADFセキュリティ・コンテキストのアクセス方法の詳細は、「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。

47.3.3 デフォルトのフォームベース・ログイン・ページ生成時の処理

ウィザードで生成されるログイン・ページおよびエラー・ページは単純なHTMLページです。ユーザー・インタフェース・プロジェクトの最上位フォルダに追加されます。生成されるログイン・ページでは、ユーザーのログイン・リクエストを標準のj_security_checkアクションによって送信するHTMLフォームが定義されます。このアクションとフォームベース認証(ウィザードで提供されるコンテナ認証のデフォルト・オプション)を使用すると、Webコンテナでユーザーに対して様々なWebアプリケーション・リソースを認証できるようになります。

ウィザードはweb.xmlファイルを更新し、次の例に示すように、フォームベース認証を指定してページの場所を指定します。

<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>

認証されていないユーザーが保護対象のリソースにアクセスしようとすると、ウィザードで生成されたログイン・ページがサーバー側からのリダイレクトによってアプリケーションに表示されます。ログイン・ページへのリダイレクトは、ADFセキュリティ対応のリソースを含むページにユーザーが移動した場合にのみ発生するため、これは暗黙的な認証と呼ばれます。

Webアプリケーションにはパブリック・ページの概念もあり、明示的な認証と暗黙的な認証に対応します。つまり、ユーザーは保護されたコンテンツに移動する前にログイン・リンクをクリックすることによってアプリケーションにログインできるということです。ログイン・リンクの作成および使用の詳細は、「ログイン・ページの作成」を参照してください。

47.3.4 「ADFセキュリティの構成」ウィザードに関する必知事項

最初に「ADFセキュリティの構成」ウィザードを実行して認証と認可を有効にすると、アプリケーション・レベルでADFリソースが保護されます。さらに、ユーザー・インタフェース・プロジェクトについて特定のプロジェクトレベル設定(認証のタイプや認証のようこそページなど)を選択します。ウィザードによって、選択するプロジェクトのweb.xmlファイルにWebアプリケーション設定が追加されます。アプリケーションに複数のユーザー・インタフェース・プロジェクトとweb.xmlファイルが含まれる場合は、ウィザードに戻り、選択する別のユーザー・インタフェース・プロジェクトのweb.xmlファイルでこれらの設定を構成します。

47.3.5 ADF認証に関する必知事項

Java EEコンテナ管理の認証を使用するログイン用のFusion Webアプリケーションとログアウト用のADF認証は、特別な要件なしでOracle Single Sign-On (Oracle SSO)と統合されます。ADF認証サーブレットは、ログアウトの詳細を処理し、ユーザー・セッションを無効にします。ただし、アプリケーションがServlet 3.0によって提供されるログインおよびログアウトのメソッドを使用している場合、Oracle SSOはサポートされません。さらに、Servlet 3.0のログインおよびログアウトは、Java EE 6以降を完全にサポートするアプリケーション・サーバーのみと互換性があります。

ADFセキュリティ対応リソースに依存するページが最初にアクセスされたときにユーザーがまだログインしていない場合は、アプリケーション・サーバーによってセッションが作成され、ADFセキュリティの構成ウィザードの実行時にweb.xmlに構成されたJpsFilterによってanonymousユーザー・プリンシパルとanonymous-roleロール・プリンシパルを含むサブジェクトが作成されます。このロール・プリンシパルを使用すると、無名ユーザー・セッションでは、認証されていないユーザーがどのADFセキュリティ対応リソース(ADFバインド・タスク・フローまたはページ定義など)にも関連付けられていないパブリックWebページにアクセスできます。ログイン時に、WebLogic Serverは既存の無名ユーザー・セッションを無効にせず、セキュリティ上の理由により、認証されたユーザー・セッションの新しいセッションIDのみを作成します。

WebLogic Serverによって強制される認証済ユーザー・セッション動作により、ユーザーは無名ユーザー・セッション・データを新しいIDを持つ認証済ユーザー・セッションにクローニングすることで、前にアクセスしたパブリック・ページを引き続き表示できます。この動作は、WebLogic Server上でのHTTPセッションの作成方法とは異なりますが、無名ユーザー・セッション・データを認証ユーザー・セッションに渡すときにセキュリティ・リスクが伴いません。

注意:
Fusion Webアプリケーションでは、セッションBeanが初期化されるのはセッションの確立時のみです。セッションがanonymousとして作成された場合、WebLogic Serverによって新しいセッションが作成される場合でも、セッションBeanはユーザーのログイン時に再初期化されません。これは、パブリック・ページからセキュリティ保護されたページに移動する場合です。ただし、ユーザーがセキュリティ保護されたページでアプリケーションに入る場合は、ユーザー・ログイン時にセッションBeanが初期化されます。
そのため、Fusion Webアプリケーションでは、現在のユーザー・データを認証済セッションから取得するためにセッション・スコープのマネージドBeanを使用しないでください。アプリケーションで現在のユーザーを取得する正しい方法は、ADFセキュリティ・コンテキストから取得することです。ADFセキュリティ・コンテキストを扱うAPIの詳細は、「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。

ADFセキュリティ対応リソースに関連付けられているページの場合は、無名ユーザーがページにアクセスできるようにするには、view権限をanonymous-roleに明示的に付与する必要があります。無名ユーザーへの権限付与の詳細は、「ADFリソースを公開する方法」を参照してください。

47.3.6 組込みtest-allロールに関する必知事項

「ADFセキュリティの構成」ウィザードを使用して、アプリケーションのすべてのADFセキュリティ対応リソースのview権限を付与するために、組込みtest-allアプリケーション・ロールへの自動付与を有効にすることができます。権限(自動view権限またはユーザー定義の明示的な権限)が付与されないと、ADFセキュリティの認可チェックの施行により、アプリケーションの実行とリソースへのアクセスを行えなくなります。test-allアプリケーション・ロール機能を有効にしてウィザードを実行し、その後、自動view権限を明示的な権限で段階的に置き換えることができます。test-allアプリケーション・ロールの権限が設定された状態ではアプリケーションをデプロイしないでください。この機能のためにすべてのADFリソースが公開されるためです。ウィザードで組込みtest-allアプリケーション・ロールの有効化を選択する場合は、アプリケーションをデプロイする前に「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」を参照してください。

47.3.7 valid-usersロールに関する必知事項

valid-usersロールは、ADFセキュリティによって定義されたJava EEセキュリティ・ロールです。このロールにより、web.xmlファイルで定義されたadfAuthenticationサーブレットWebリソースにすべてのユーザーがアクセスできることが保証されます。ADFセキュリティの構成ウィザードはweblogic.xmlファイルを更新し、次の例に示すように、このADFセキュリティ・ロールをusersプリンシパルにマッピングします。Oracle WebLogic Serverは、正常に認証されたすべてのユーザーをusersグループのメンバーとして構成するため、このマッピングによりすべてのユーザーがこのロールを持ちます。

<security-role-assignment>
<role-name>valid-users</role-name>
<principal-name>users</principal-name>
</security-role-assignment>

usersプリンシパルは、実行時に、OPSSによって、正常に認証されたサブジェクトに自動的に追加されます。セキュリティの観点から、valid-usersロールがADF認証をサポートするのは、セキュリティ制約だけを使用してWebリソースへのアクセスを制御する必要がある場合のみです。このマッピングの最終的な結果はJava EEセキュリティに全面的に依存します。JAAS権限は関係ありません。

47.4 アプリケーション・ロールの作成

アプリケーション・ロールを作成して、アプリケーションのポリシー要件を表し、同じview権限を持つユーザーのグループを定義します。アプリケーション・ポリシー・ストアに作成するアプリケーション・ロールは、お使いのアプリケーション固有のものです。たとえば、ワークフローのコンテキストでは、Application Customer RoleやApplication Employee Roleなどのアプリケーション・ロールが、Summit ADFサンプル・アプリケーションのSummitADF_TaskFlowsワークスペースで定義されていることがあります。

実行時には、ユーザーがメンバーとして定義されているアプリケーション・ロールにより、ユーザーにアクセス権が付与されます。このように、セキュリティ・ポリシーを定義する前に、権限の付与先にするアプリケーション・ロールをポリシー・ストアに含める必要があります。それは、ユーザーが定義するアプリケーション・ロール(Application Customer Roleなど)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-roleまたはanonymous-role)のいずれかでもかまいません。JDeveloperで提供される組込みアプリケーション・ロールを使用すると、「ADFリソースを公開する方法」で説明するようにADFリソースを公開できます。

アプリケーション・ロールを作成した後は、次の手順を実行します。

- 「ADFセキュリティ・ポリシーの定義」の説明に従って、権限をアプリケーション・ロールに付与します。

- 「テスト・ユーザーの作成」の説明に従って、テスト・ユーザーを各アプリケーション・ロールに関連付けます。

ベスト・プラクティス

ADFセキュリティ・フレームワークは、アプリケーション・ロールまたは個々のユーザーに付与された権限に基づいて、ロールベースのアクセス制御メカニズムを施行します。セキュリティのテストのみを行う必要があり、ユーザー・グループを作成する必要がなくても、アプリケーション・ロール(少なくとも1ユーザー・メンバーを含む)を作成しなければなりません。後でADFリソースのセキュリティ・ポリシーを定義するとき、アプリケーション・ポリシー・ストアの概要エディタを使用して、権限に対してアプリケーション・ロールを選択できます。

47.4.1 アプリケーション・ロールを作成する方法

JDeveloperでは、アプリケーション・ロールをjazn-data.xmlファイルのポリシー・ストアに格納できます。これは、「アプリケーション・リソース」パネルのDescriptors/META-INFノードに表示されます。

注意:

アプリケーション・ロールを作成するときは、新しいアプリケーション・ロールをアイデンティティ・ストアではなくポリシー・ストアに追加してください。アイデンティティ・ストアに追加するロールによって、エンタープライズ・セキュリティ・ロールが定義されます。また、このロールは、アイデンティティ・ストア内のユーザーをグループ化するときに役立ちます。エンタープライズ・ロールの詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。

jazn-data.xmlファイルのポリシー・ストアにアプリケーション・ロールを作成するには、jazn-data.xmlファイルの概要エディタの「アプリケーション・ロール」ページを使用します。このエディタを使用すると、アイデンティティ・ストアのメンバーと、作成するアプリケーション・ロールの関係を表示できます。

始める前に:

アプリケーション・ロールについて理解しておくと役立ちます。詳細は、「アプリケーション・ロールの作成」を参照してください。

アプリケーション・ロールを作成するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。

2. jazn-data.xml概要エディタの「アプリケーション・ロール」ページで、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。

JDeveloperによってjazn-data.xmlファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。

3. 「ロール」リストで「新規」アイコンをクリックします。

4. 「名前」フィールドにロール名を入力します。他のいずれかのフィールドをクリックすると、アプリケーション・ロールがポリシー・ストアに追加されます。

5. テスト・ユーザーをアイデンティティ・ストアにすでに設定している場合は、「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」の説明に従ってユーザーとロールをマッピングできます。

47.4.2 アプリケーション・ロール作成時の処理

アプリケーション・ロールをポリシー・ストアに追加すると、アプリケーション・ワークスペースを基準とするsrc/META-INFディレクトリにあるjazn-data.xmlファイルがJDeveloperによって更新されます。アプリケーション・ロールは、次の例に示すように<policy-store>内の<app-role>要素に定義されます。ポリシー・ストアの<application>要素にアプリケーションが指定されるため、作成するすべてのアプリケーション・ロールは、実行時にそのアプリケーションに対してのみ有効になります。他のWebアプリケーションは、独自のアプリケーション・ロールのセットを含むポリシー・ストアを定義できます。

<policy-store>
<applications>
<application>
<name>SummitADFTaskFlows</name>
<app-roles>
<app-role>
<name>Application Employee Role</name>
<display-name>Application Employee Role</display-name>
<class>oracle.security.jps.service.policystore.
ApplicationRole</class>
</app-role>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
</applictions>
</policy-store>

47.4.3 エンタープライズ・ロールとアプリケーション・ロールに関する必知事項

エンタープライズ・ロールは、ドメインのアイデンティティ・ストア(アプリケーションのアイデンティティ・ストアではなく)で管理されるロールです。ドメインにデプロイされているすべてのアプリケーションが使用できるため、エンタープライズ・ロールは外部ロールとも呼ばれます。

アプリケーション・ロールはFusion Webアプリケーションで使用されるロールです。これはアプリケーション固有であり、アプリケーション・ポリシーで定義するものなので、Java EEコンテナで認識できるとはかぎりません。アプリケーション・ロールは、アプリケーションに定義されたユーザーとロールのみを含むという意味でスコープ指定されています。アプリケーション・ロールはエンタープライズ・ロールにマッピングする必要があります。

jazn-data.xmlファイルの概要エディタを使用して、アイデンティティ・ストアに追加するユーザーをグループ分けするためのエンタープライズ・ロールを作成します。この仕組みを使用すると、「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」で説明するように、定義したアプリケーション・ロールにすべてのユーザー・グループを割り当てて、ADFセキュリティ・ポリシーで定義されたアクセス権を付与できます。

ただし、統合WebLogic Serverでは、JDeveloper内でアプリケーションを実行するためにエンタープライズ・ロールを作成する必要はありません。アプリケーションをテストするためには、少数のテスト・ユーザーを作成して、アプリケーションに直接割り当てるだけで十分な場合があります。アプリケーションをJDeveloperで実行すると、ユーザーと定義済エンタープライズ・ロールが、デフォルトのセキュリティ・プロバイダ(統合WebLogic Serverの埋込みLDAP)に作成されます。

通常、ステージングのためにアプリケーションをデプロイするときは、ポリシー・ストアのみをターゲット・サーバーに移行します。「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、アイデンティティ・ストア(テスト・ユーザーとエンタープライズ・ロールを含む)が移行されないように、JDeveloperデプロイメント・オプションを構成できます。

セキュア・アプリケーションをデプロイすると、Oracle Fusion Middlewareはアプリケーションのポリシー・ストアをドメインレベル・ポリシー・ストアのポリシーとマージします。このタスクを完了するために、Oracle WebLogic Serverの管理者は、最終的にポリシー・ストアのアプリケーション・ロールを既存のドメインレベル・エンタープライズ・ロールにマッピングします。ドメイン・レベルでのこのようにアプリケーション・ロールをマッピングすると、定義したADFセキュリティ・ポリシーに従ってエンタープライズ・ユーザーがアプリケーション・リソースにアクセスできるようになります。また、管理者がドメインレベルでアプリケーション・ロール・マッピングを行うことにより、本番環境のアイデンティティ・ストアの知識がなくても、アプリケーションのADFセキュリティ・ポリシーを開発できるようになります。

47.5 ADFセキュリティ・ポリシーの定義

認可で利用されるポリシー・ストアは、実行時にアクセスされ、指定したオブジェクトに対する事前定義済のアクション(viewなど)を実行するための権限を含みます。当初、「ADFセキュリティの構成」ウィンドウを実行した後では、ポリシー・ストアでは権限が定義されていません。また、デフォルトのウィザード・オプション「ADF認証および認可」では認可チェックが有効になるため、ADFセキュリティ対応リソースに依存するアプリケーションのWebページにユーザーはアクセスできません。ユーザーのアクセスを許可するリソースに明示的な権限を定義するには、JDeveloperを使用する必要があります。

ベスト・プラクティス

デフォルト・オプション「ADF認証および認可」を選択して「ADFセキュリティの構成」ウィザードを実行すると、アプリケーションのWebページがロックダウンされます。指定するページのみのアクセスをユーザーに許可するように明示的な権限を定義するため、このときにFusion Webアプリケーションに最大限の保護を実現できます。このようなガイドラインの詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。

セキュリティ・ポリシーを定義するには、アプリケーションのポリシー・ストアに、権限を付与するアプリケーション・ロールが含まれる必要があります。それは、ユーザーが定義するアプリケーション・ロール(Application Customer Roleなど)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-roleまたはanonymous-role)のいずれかでもかまいません。アプリケーション・ロールは、同じロールの各メンバーが同じアクセス権を持つようにユーザーを分類する目的で使用できます。このため、セキュリティ・ポリシーにより、アプリケーション・ロールには、(個別のユーザーでなく)権限のプリンシパルの名前が付けられます。アプリケーション・ロールの定義の詳細は、「アプリケーション・ロールの作成」を参照してください。

ユーザー・インタフェース・プロジェクトの場合、セキュリティ・ポリシーに対応する概要エディタを使用して、ADFタスク・フローとADFページ定義などのADFリソースをセキュリティ保護します。jazn-data.xmlファイルのエディタを開きます。これには、jazn-data.xmlファイル(「アプリケーション・リソース」パネル)をダブルクリックするか、メイン・メニューの「アプリケーション」メニューから「保護」→「リソース権限」を選択します。

jazn-data.xmlファイルを開くと、テスト・ユーザー、エンタープライズ・ロールおよびアプリケーション・ロールを作成するために別のエディタ・ページが概要エディタに表示されることに注意してください。

データ・モデル・プロジェクトの場合、エンティティ・オブジェクトまたはその属性のセキュリティを保護するのに、セキュリティ・ポリシーの概要エディタは使用しません。かわりに、これらのオブジェクトにメタデータを直接設定して、データバインドUIコンポーネントがデータを表示するかどうかを管理します。行レベル・セキュリティの権限付与の詳細は、「データのポリシーを定義する方法」を参照してください。

47.5.1 ADFリソースを公開する方法

個別のアクセス権限にかかわらず、一部のWebページをすべてのユーザーが表示できるようにするのは、一般的な要件です。たとえば、ホームページは、サイトにアクセスするすべてのユーザーに対して表示する必要がありますが、企業サイトは認証によって身元が確認されたユーザーのみに表示する必要があります。

どちらの場合も、ページを表示する権限がユーザーの特定の権限によって定義されているわけではないので、ページはパブリックであると考えられます。両者の違いは、ユーザーが匿名であるか、それとも既知のアイデンティティであるかです。

ADFセキュリティ・モデルでは、アクセス権限をanonymous-roleプリンシパルに付与することで、セキュリティの欠如とコンテンツの公開アクセスを区別します。匿名ロールは、既知のユーザーと無名ユーザーの両方を含みます。したがって、anonymous-roleに付与される権限を使用すると、認証されていないユーザー(たとえばゲスト・ユーザー)によるリソースへのアクセスを許可できます。認証済ユーザーのみにアクセスを許可するには、authenticated-roleプリンシパルにポリシーを定義する必要があります。

注意:

アプリケーション内の他のページへのリンクを含むパブリック・ホームページの作成方法の詳細は、「パブリックなようこそページの作成方法」を参照してください。

始める前に:

ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、「ADFセキュリティ・ポリシーの定義」を参照してください。

次のタスクを完了する必要があります。

1. 「タスク・フローの作成」の説明に従って、バインド・タスク・フローを作成します。

2. 「ページ定義ファイルの処理」の説明に従って、ADFページ定義ファイルを含むWebページを作成します。

3. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

4. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

ADFセキュリティ対応リソースに対する公開アクセス権を付与するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから次のいずれかのリソースを選択します。

- 「タスク・フロー」(バインド・タスク・フローを公開する場合)。アプリケーションによって、タスク・フローそのものに定義した権限の下でWebページが表示されます。つまり、バインド・タスク・フローのすべての構成Webページが公開されます。

- 「Webページ」(個別のWebページを公開する場合)。通常、これらのページはバインドなしタスク・フローに定義された、アプリケーションのトップレベル・ページ(ホームページなど)です。

3. 「リソース」列で、アクセス権を付与するADFリソースを選択します。

選択するリソースは、リソース名の横の最初の列にロック・アイコンが表示されている必要があります。ロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。たとえば、図47-4ではADFリソースcustomer-registration-task-flow (バインド・タスク・フロー)は権限が定義されていないため、ロック・アイコンが表示されています。

ヒント:

概要エディタの先頭列のヘッダーにあるキー切替えアイコンをクリックして、すでに権限が定義されたリソースの非表示と表示を切り替え、権限のないリソースのみを表示します。キー・アイコンは、リソースに権限が定義されており、十分なアクセス権を持つユーザーがアクセスできることを示します。

図47-4 概要エディタでのADFセキュリティ対応リソースの選択

4. 「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。

5. 「アプリケーション・ロールの選択」ダイアログで、次の組込みアプリケーション・ロールから1つを選択します。

- anonymous-roleは、サイトにアクセスするすべてのユーザーがリソースにアクセスできることを意味します。このロールへの権限付与が必要となるのは、ユーザーがログインしなくても、ADFセキュリティ対応リソースに関連するWebページにアクセスできるようにする場合です。たとえば、顧客の登録を管理するタスク・フローについてanonymous-roleに権限を付与します。

- authenticated-roleは、認証されたユーザー(サイトにアクセスしてログインしたユーザー)のみがリソースにアクセスできることを意味します。たとえば、従業員登録のタスク・フローについてauthenticated-roleに権限を付与します。

6. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。

7. 概要エディタの「リソース権限」ページの「アクション」列では、viewアクションが選択されたままにしておきます。

デフォルトでは、図47-5のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。

customize、grantまたはpersonalizeの各アクションは、Oracle WebCenter Portal: Frameworkアプリケーションまたはカスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できる)でのページ定義セキュリティのために実装されています。

図47-5 概要エディタでのanonymous-roleへの権限付与

47.5.2 ADFリソースの公開時の処理

セキュリティ・ポリシーを定義すると、セキュリティ・ポリシーの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INFノードにあるjazn-data.xmlファイルが更新されます。

概要エディタは、ファイルの<policy-store>セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロール(この場合は匿名ロール)です。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。

次の例は、顧客登録タスク・フローを公開するjazn-data.xmlファイルのセキュリティ・ポリシーを示しています。anonymous-roleに対する権限には、バインド・タスク・フローcustomer-registration-task-flowの1つのview権限が含まれます。この権限により、すべてのユーザーが顧客登録タスク・フローを開始して顧客登録プロセスを完了できます。匿名ロールに権限を追加することもでき、匿名ロール権限の<permissions>セクションに表示されます。

<policy-store>
...
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.internal.core.
principals.JpsAnonymousRoleImpl</class>
<name>anonymous-role</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.controller.security.TaskFlowPermission</class>
<name>/WEB-INF/customer-registration-task-flow.xml#
customer-registration-task-flow</name>
<actions>view</actions>
</permission>
...
</permissions>
...
</grant>
...
</jazn-policy>
</policy-store>

47.5.3 実行時に行われる処理: 組込みロールの使用方法

anonymous-roleおよびauthenticated-roleという名前は、Oracle Platform Security Services (OPSS)によって定義される特別なロールです。

「ADFセキュリティの構成」ウィザードを実行すると、匿名ロールのサポートを有効にするJpsFilter定義がweb.xmlファイルに構成されます。匿名ロールを有効にすると、無名ユーザー(ログインしていないユーザー)によるサイトのブラウズがADFセキュリティによってサポートされます。反対に、認証ロールは宣言されず、デフォルトで常に識別されます。ADFセキュリティでは両方のロールがサポートされます。

エンド・ユーザーがADFセキュリティ対応リソースに最初にアクセスするとき、システムによってサブジェクトが作成され、匿名ロール・プリンシパルがそのサブジェクトに移入されます。アクセス対象のADFセキュリティ対応リソースのview権限が匿名ロールに付与されているかぎり、ユーザーのアクセスが許可されます。匿名ロールがADFリソースの権限受領者でない場合、ユーザーはログインするように求められます。ログインすると認証ロールがサブジェクトに追加されます。また、ウィザードによってJpsFilter定義がweb.xmlファイルに追加されます。remove.anonymous.roleはfalseに設定され、ユーザーがログインした後でも匿名ロール・プリンシパルが使用可能になります。認証ロール・プリンシパルを使用すると、認証ロールに対して明示的に権限が付与されたリソースにユーザーがアクセスできます。

47.5.4 ADFバインド・タスク・フローのポリシーを定義する方法

セキュリティ・ポリシーの概要エディタの「リソース権限」ページで権限を作成することで、ADFバインド・タスク・フローのアクセス・ポリシーを定義します。作成する権限は、jazn-data.xmlファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はバインド・タスク・フロー定義名)を定義します。

ベスト・プラクティス

バインド・タスク・フローの個々のWebページに対しては権限を作成しないでください。ユーザーがバインド・タスク・フローにアクセスする場合、すべてのページのセキュリティはタスク・フローに付与する権限により管理されます。また、含まれている(ページ定義が関連付けられている) Webページにはデフォルトでアクセスできないため、ADFセキュリティではユーザーによるタスク・フローのページへの直接アクセスが禁止されます。これにより、タスク・フローの明確なセキュリティ・モデルがサポートされ、すべてのユーザーに単一エントリ・ポイントを強制します。セキュリティ・ポリシーの実装方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。

表47-3で説明するように、概要エディタで「タスク・フロー」ヘッダーの切替えボタンをクリックすると、タスク・フローをソートできます。

表47-3 バインド・タスク・フローのリソース権限切替えボタン

ボタン

切替えアクション

説明

権限のないバインド・タスク・フローの表示または非表示

権限が定義されていないバインド・タスク・フローを表します。タスク・フローがコールするWebページにはすべてのユーザーがアクセスできません。

権限付きのバインド・タスク・フローの表示または非表示

1つ以上の権限が定義されたバインド・タスク・フローを表します。タスク・フローがコールするWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。

概要エディタに表示される、利用できるアクションのリストは、タスク・フロー権限クラス(oracle.adf.controller.security.TaskFlowPermission)によって定義されます。権限クラスは、これらのアクションを、タスク・フローがサポートする操作にマップします。表47-4に、JDeveloperによって表示される、ADFバインド・タスク・フローに対するアクションを示します。

Fusion Webアプリケーションで現在サポートされているのはviewアクションのみです。customize、grantまたはpersonalizeアクションを選択しないでください。これらはタスク・フロー・セキュリティで将来使用するために用意されています。

表47-4 ADFバインド・タスク・フローのセキュリティ保護されたアクション

許可できるアクション

ユーザー・インタフェースへの影響

view

Fusion Webアプリケーションのバインド・タスク・フローの読取りと実行を行うユーザーを制御します。

これは、タスク・フローがサポートする唯一の動作です。

customize

将来の使用のために予約されています。このアクションは実行時にチェックされません。

grant

将来の使用のために予約されています。このアクションは実行時にチェックされません。

personalize

将来の使用のために予約されています。このアクションは実行時にチェックされません。

タスク・フロー・セキュリティ・ポリシーの権限を定義するには、jazn-data.xmlファイルの概要エディタの「リソース権限」ページを使用します。

始める前に:

ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、「ADFセキュリティ・ポリシーの定義」を参照してください。

次のタスクを完了する必要があります。

1. 「タスク・フローの作成」の説明に従って、バインド・タスク・フローを作成します。

ベスト・プラクティス

同じアプリケーションの別のUIプロジェクトのバインド・タスク・フローを作成している場合、一意のタスク・フロー定義名を割り当てることをお薦めします。これが必要になるのは、権限のタスク・フロー定義名がjazn-data.xmlポリシー・ストアにパスでスコープ指定されているためです(たとえば、/WEB-INF/mytaskflow-definition.xml#mytaskflow-definition)。したがって、権限のプロジェクトレベル・スコープを設定するには、一意の定義名でバインド・タスク・フローを作成するしかありません。

2. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

3. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

ADFバインド・タスク・フローで権限を定義するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択します。

概要エディタに、アプリケーションで定義されるすべてのタスク・フローが表示されます。タスク・フローは、ユーザー・インタフェース・プロジェクトの「Webコンテンツ/ページ・フロー」ノードに表示されるタスク・フロー定義ファイル(.xml)で定義されます。

3. 「リソース」列で、アクセス権を付与するタスク・フローを選択します。

最初にバインド・タスク・フローに権限付与を行うとき、最初の列のタスク・フロー名の横に「権限のないリソースを表示します。」アイコン(ロックを表すアイコン)が表示されます。概要エディタに表示されるロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。

ヒント:

「リソース」列のヘッダーの「権限付きリソースを表示します。」アイコン(キーを表すアイコン)をクリックすると、すでに権限が定義されているすべてのタスク・フローが非表示になります。こうすることで、図47-6のように権限のないタスク・フローのみが表示されます。さらに、タスク・フロー名の一部を検索フィールドに入力すると、文字が一致する名前のタスク・フローのみを表示できます。

図47-6 概要エディタでの権限付きタスク・フローの非表示

4. 「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。

5. 「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。

「アプリケーション・ロールの選択」ダイアログには、jazn-data.xmlファイルのアプリケーション・ロールが表示されます。「実行時に行われる処理: 組込みロールの使用方法」で説明するように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。

アプリケーション固有のアプリケーション・ロールが表示されていない場合は、「アプリケーション・ロールの作成」の説明に従ってロールを作成します。

6. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。

7. 概要エディタの「リソース権限」ページの「アクション」列では、viewアクションが選択されたままにしておきます。

デフォルトでは、図47-7のように概要エディタにviewアクションが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。customize、grantまたはpersonalizeアクションを選択しないでください。これらは将来の使用のために用意されているものです。実行時にADFセキュリティでチェックされることはありません。

TaskFlowPermissionクラスによってタスク・フロー(タスク・フローの操作にマッピングされる特定のアクション)が定義されます。表47-4を参照してください。

図47-7 概要エディタでのバインド・タスク・フロー定義のアプリケーション・ロールへの権限付与

8. この手順を必要なだけ繰り返して、追加の権限を作成します。

同一のタスク・フロー定義に、異なるアプリケーション・ロールに対する複数の権限がある場合があります。「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xmlファイルのポリシー・ストア定義に含まれます。

47.5.5 ページ定義を参照するWebページのポリシーを定義する方法

セキュリティ・ポリシーの概要エディタの「リソース権限」ページで権限を作成することで、ADFページ定義のアクセス・ポリシーを定義します。作成する権限は、jazn-data.xmlファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はページ定義名)を定義します。

ベスト・プラクティス

個々のWebページの権限を作成するのは、そのページがバインド・タスク・フローの構成ページでない場合のみです。ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。セキュリティ・ポリシーの実装方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。

表47-5で説明するように、概要エディタで「リソース」ヘッダーの切替えボタンをクリックするとWebページ定義リソースをソートできます。

表47-5 Webページ定義のリソース権限切替えボタン

ボタン

切替えアクション

説明

権限のないトップレベル・ページの表示または非表示

バインドなしタスク・フローに含まれるWebページに対して定義された権限がないページ定義を表します。このWebページにはどのユーザーもアクセスできません。

権限付きのトップレベル・ページの表示または非表示

バインドなしタスク・フローに含まれるWebページに対して定義された1つ以上の権限があるページ定義を表します。このWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。

バインド・タスク・フローに含まれるページの表示または非表示

バインド・タスク・フローにも含まれるWebページに関連付けられたページ定義を表します。このようなWebページ定義には権限を付与しないでください。かわりに、バインド・タスク・フローのセキュリティ・ポリシーを定義します。

保護できないページ(ページ定義なし)の表示または非表示

バインドなしタスク・フローに含まれる、ページ定義が定義されていないWebページを表します。(バインド・タスク・フローに含まれる同様のページは、バインド・タスク・フローの権限によって保護されます。)Webページは、ADFセキュリティ対応リソースにより保護されていないため、すべてのユーザーによりアクセス可能です。「ADFバインドなしのページのポリシー定義に関する必知事項」で説明するように、必要に応じて、空のページ定義ファイルを追加することでページを保護できます。

概要エディタに表示される、利用できるアクションのリストは、リージョン権限クラス(oracle.adf.share.security.authorization.RegionPermission)によって定義されます。権限クラスは、これらのアクションを、WebページのADFページ定義がサポートする操作にマップします。表47-6に、JDeveloperによって表示される、ADFページ定義に対するアクションを示します。

Fusion Webアプリケーションで現在サポートされているのはviewアクションのみです。

customize、grantまたはpersonalizeアクションを選択しないでください。これらは、WebCenter Portal: Frameworkアプリケーションでのページ定義セキュリティのためだけに実装されています。

表47-6 ADFページ定義のセキュアなアクション

許可できるアクション

ユーザー・インタフェースへの影響

view

ページを表示できるユーザーを制御します。

これは、ページ定義がサポートする唯一の動作です。

他のすべての操作はOracle WebCenter Portal: Frameworkをサポートしています。

customize

カスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できるアプリケーション)またはWebCenter Portalアプリケーションのページに含まれるWebCenter Portalカスタマイズ可能コンポーネント(カスタマイズ可能パネルまたは「詳細フレームの表示」)に対して暗黙の変更(最小化/復元、削除または移動)を実行できるユーザーを制御します。詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

grant

すべてのWebCenter Portal固有のアクションを組み合せて指定した権限を付与します。他のすべてのアクションの権限付与と同じです。他のユーザーに権限を付与できるユーザーや、Oracle WebCenter PortalのComposerを使用してページのセキュリティ設定を変更できるユーザーも制御します。詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

personalize

カスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できるアプリケーション)またはWebCenter Portalアプリケーションのページに含まれるWebCenter Portalカスタマイズ可能コンポーネント(カスタマイズ可能パネルまたは「詳細フレームの表示」)に対して暗黙の変更(最小化/復元、削除または移動)を実行できるユーザーを制御します。詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

ページ定義セキュリティ・ポリシーの権限を定義するには、セキュリティ・ポリシーの概要エディタの「リソース権限」ページを使用します。

始める前に:

ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、「ADFセキュリティ・ポリシーの定義」を参照してください。

次のタスクを完了する必要があります。

1. 「ページ定義ファイルの処理」の説明に従って、ADFページ定義ファイルを含むトップレベルWebページを作成します。

ベスト・プラクティス

同じアプリケーションの別のUIプロジェクトのトップレベルWebページを作成している場合、一意のページ・ファイル名を割り当てることをお薦めします。これが必要になるのは、権限のページ定義がjazn-data.xmlポリシー・ストアにパッケージでスコープ指定されているためです(たとえば、view.pageDefs.mytoppagePageDef)。したがって、権限のプロジェクトレベル・スコープを設定するには、一意のファイル名でトップレベル・ページを作成するしかありません。

2. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

3. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

ADFページ定義に権限を定義するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択します。

概要エディタの「リソース権限」ページには、ADFページ定義が関連付けられているページも含め、すべてのWebページが表示されます。ADFバインディングを使用するあらゆるWebページや、空のページ定義を作成しておいたあらゆるWebページも含まれます。ページ定義は、ユーザー・インタフェース・プロジェクトの「アプリケーション・ソース」ノードに表示されるPageDef.xmlファイルで定義されます。

3. 「リソース」列で、アクセス権を付与するページ定義を選択します。

最初にページ定義に権限付与を行うとき、最初の列のページ定義名の横に「権限のないリソースを表示します。」アイコン(ロック・アイコン)が表示されます。エディタに表示されるロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。たとえば、図47-8のページ定義account_updateUserInfoには権限が付与されていないためロック・アイコンが表示されます。図47-8の他のページ定義には「バインド・タスク・フローに含まれるページ」アイコンが表示されます。これらはトップレベル・ページではなく、含まれているバインド・タスク・フローによって保護されるためです。

「バインド・タスク・フローに含まれるページ」アイコンが表示されている個々のWebページ定義には権限を作成しないでください。関連付けられたWebページのセキュリティ・ポリシーは、バインド・タスク・フローによって保護されます。たとえば、図47-8のaccount_addressDetails.jsffリージョンに関連付けられているページ定義は、それが含まれているバインド・タスク・フローによって保護されます。

ヒント:

ページ定義名の一部を検索フィールドに入力すると、文字が一致する名前のページ定義のみを表示できます。たとえば、generalという語を検索すると、図47-8に示すように名前がgeneralという語で開始するページ定義のみが表示されます。

図47-8 概要エディタでの名前によるページ定義の検索

ヒント:

権限付きリソースのアイコン(キー・アイコン)をクリックすると、すでに権限があるすべてのページ定義を非表示にできます。「リソース」列のヘッダーの「バインド・タスク・フローに含まれるページを表示」切替えボタンがオフになっており、バインド・タスク・フローに含まれるページ定義がすべて非表示になっていることを確認します(デフォルトでは、これらのページが非表示になるように設定されています)。この場合、図47-9に示すように、権限がないトップレベル・ページ(および保護できないページ)が表示されます。

図47-9 概要エディタでの権限付きWebページの非表示

4. 「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。

5. 「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。

「アプリケーション・ロールの選択」ダイアログには、jazn-data.xmlファイルのアプリケーション・ロールが表示されます。「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。

アプリケーション固有のアプリケーション・ロールが表示されていない場合は、「アプリケーション・ロールの作成」の説明に従ってロールを作成します。

6. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。

7. 概要エディタの「リソース権限」ページの「アクション」列では、viewアクションが選択されたままにしておきます。

デフォルトでは、図47-10のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。

customize、grantまたはpersonalizeの各アクションは、WebCenter Portal: Frameworkアプリケーションまたはカスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できる)で使用するために実装されています。

RegionPermissionクラスによってページ定義(ページの操作にマッピングされる特定のアクション)が定義されます。表47-6を参照してください。

図47-10 概要エディタでのADFページ定義に関するアプリケーション・ロールへの権限付与

8. この手順を必要なだけ繰り返して、追加の権限を作成します。

同一のページ定義に、異なるアプリケーション・ロールに対する複数の権限がある場合があります。「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xmlファイルのポリシー・ストア定義に含まれます。

47.5.6 ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法

アプリケーションによって定義されたADFメソッドは、コマンド・コンポーネントとしてユーザー・インタフェース内にドロップできます。デフォルトでは、メソッドのコマンド・コンポーネントが表示されたページにアクセス可能なユーザーには、このメソッドを実行する権限も与えられます。メソッド操作に対するアクセスを制限する追加のセキュリティを作成するには、リソース権限を作成し、ユーザー・インタフェース・レベルで権限をテストする必要があります。ADFセキュリティでは、ADFメソッドに対する認可チェックは行われません。アプリケーションでの認可チェックを独自に有効化する必要があります。ADFメソッドに対してユーザーに付与したリソース権限に基づき、ユーザー・インタフェースでコマンド・コンポーネントが有効化または無効化されます。

コマンド・コンポーネントとしてページに表示されるメソッドへのユーザー・アクセスを制御するには、次の手順を実行します。

1. カスタム・リソース・タイプおよびリソースに対してリソース権限を作成します。

2. ユーザー・インタフェースで権限付与を施行します。

47.5.6.1 ADFメソッドへのアクセスを制御するリソース権限の作成

リソース・タイプを作成するとマッチャ・クラスoracle.security.jps.ResourcePermissionに設定されます。これにより、アプリケーションのADFセキュリティで保護されていない部分に対して権限を付与できるようになります。たとえば、顧客への商品の出荷をユーザーが取り消すためのボタンをページに表示できます。ただし、特定のアプリケーション・ロールのメンバーのみが出荷を取り消すことができます。このルールを適用するには、実行時に宣言的にチェック可能なリソース権限をユーザー・インタフェースに作成し、ボタンを有効または無効にします。

保護対象のユーザー・インタフェース・コンポーネントに権限を作成するには、セキュリティ・ポリシーの概要エディタを使用します。

始める前に:

ADFセキュリティによるADFメソッドの処理方法について理解しておくと役立ちます。詳細は、「ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

1. 「メソッドを実行するためのコマンド・コンポーネントの作成」の説明に従い、保護対象のメソッドを実行するコマンド・コンポーネントを作成します。

2. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

3. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

カスタム・リソース・タイプに対するリソース権限を付与するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストの横の「新規リソース・タイプ」ボタンをクリックします。

3. 「リソース・タイプの作成」ダイアログで、リソース・タイプの名前、JDeveloperでリソース権限を付与する際に表示される表示名、および説明を入力します。

保護が必要なユーザー・インタフェース・リソースに適したリソース・タイプと表示名を入力します。たとえば、商品の出荷を取り消すためのメソッド・ボタンを保護する場合は、リソース・タイプにCancelShipment、表示名にCancel Shipmentなどと入力します。

4. 「アクション」リストの横の「アクションの追加」ボタンをクリックして、保護するアクションの名前を入力します。「OK」をクリックします。

アクション名には、カスタム・リソース・タイプに関連付ける任意の名前を指定できます。たとえば、メソッドを起動するボタンを保護する場合は、アクション名にinvokeなどと入力します。個別のアプリケーション・ロールに対してリソース権限のインスタンスを付与できるようにする必要がある場合は、複数のアクションをリストに追加できます。

5. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで「リソース」列で、「リソースの追加」アイコンをクリックします。

カスタム・リソース・タイプへの権限付与を最初に行うときには、定義済のリソースはありません。ポリシーに対してカスタム・リソースを作成する必要があります。このリソースは実行時にユーザー・インタフェースでユーザー権限をチェックする際に使用されます。

6. 「リソースの作成」ダイアログで、リソースの名前、JDeveloperでリソース権限を付与する際に表示される表示名を入力し、「OK」をクリックします。

保護対象のユーザー・インタフェース・リソースを表すリソース名と表示名を入力します。たとえば、商品の出荷を取り消すためのメソッド・ボタンを保護する場合は、リソース名にCancelShipmentButton、表示名にCancel Shipment Buttonなどと入力します。

7. 「ロールに付与済」列で「権限受領者の追加」アイコンをクリックし、「アプリケーション・ロールの追加」を選択します。

8. 「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。

「アプリケーション・ロールの選択」ダイアログには、jazn-data.xmlファイルのアプリケーション・ロールが表示されます。「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。

アプリケーション固有のアプリケーション・ロールが表示されていない場合は、「アプリケーション・ロールの作成」の説明に従ってロールを作成します。

9. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。

10. 概要エディタの「リソース権限」ページの「アクション」列で必要なアクションを選択します。

デフォルトでは、選択されていないカスタム・リソース・タイプのすべてのアクションが概要エディタに表示されます。使用可能なアクションはリソース・タイプによって定義されます。

11. この手順を必要なだけ繰り返して、追加の権限を作成します。

同一のADFメソッド・リソースに、異なるアプリケーション・ロールに対する複数の権限が定義される場合があります。「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xmlファイルのポリシー・ストア定義に含まれます。

47.5.6.2 ユーザー・インタフェースによるリソース権限の施行

事前に定義されているカスタム・リソース・タイプに対してユーザーのアクセス権をチェックするEL式を定義するには、UIコンポーネントの表示プロパティで開いた「式ビルダー」ダイアログを使用します。アプリケーションを実行すると、EL式によるリソース権限評価の結果に基づき、コンポーネントが有効化または無効化されます。

たとえば、次の例に示すように、af:button#cb1ボタンのdisabled属性に対してuserGrantedPermission式を定義できます。この場合、ユーザーが権限を持っているかどうかが式によってテストされ、その結果ボタンが有効化されるか、ユーザーが権限を所有していない場合はボタンが無効化されます。この式はボタンのrendered属性に対して定義されているのではないため、ページには常にこのボタンが表示されます。

<af:button actionListener="#{bindings.myMethodName.execute}"
text="myMethodName"
disabled="#{!securityContext.userGrantedPermission
['resourceName=CancelShipmentButton,resourceType=CancelShipment,
action=invoke']}
id="cb1"/>

始める前に:

ADFメソッド認可チェックの制限について理解しておくと役立ちます。詳細は、「ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

- 「ADFメソッドへのアクセスを制御するリソース権限の作成」の説明に従って、カスタム・リソース・タイプに対するリソース権限を作成します。

式を使用してリソース権限をチェックするには:

1. 「アプリケーション」ウィンドウで、ADFメソッドにバインドされたコマンド・コンポーネントを含むページをダブルクリックします。

2. ページのビジュアル・エディタで、ADFメソッドの実行に使用されるコマンド・コンポーネントを選択します。

3. 「プロパティ」ウィンドウで、「無効」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。

4. 「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedPermissionを選択します。次に、「式」フィールドに、権限を定義する連結文字列を入力します。

権限文字列は、resourceName=aResourceName;resourceType=aResourceType;action=actionNameのようにセミコロンで連結した文字列として入力します。たとえば、ページ内でメソッドの起動に使用されるコマンド・ボタンを有効または無効にするには、前述の例に示したような式を入力します。

例では、ユーザーに定義されているアプリケーション・ロールに対して、CancelShipmentというリソース・タイプの権限がリソース・ポリシー権限で起動されるかどうかは式によって決定されます。実行時に式をテストする際に、リソース・ポリシーがアプリケーション・ポリシー・ストアに存在している必要があります。

5. 「OK」をクリックします。

47.5.7 セキュリティ・ポリシーの定義時の処理

セキュリティ・ポリシーを定義すると、セキュリティ・ポリシーの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INFノードにあるjazn-data.xmlファイルが更新されます。

概要エディタは、ファイルの<policy-store>セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロールです。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。

次の例は、従業員登録のタスク・フローとそのタスク・フローにアクセスするために使用するトップレベルWebページに対して、認証されていないユーザーにアクセス権を付与するjazn-data.xmlファイルのセキュリティ・ポリシーを示しています。anonymous-roleアプリケーション・ロールに対する権限には、バインド・タスク・フローemp-reg-task-flowのview権限と、indexPageDefページ定義を含むWebページのview権限が含まれます。この権限によって、認証されていないユーザーは従業員登録タスク・フローに入り、ようこそページを表示できるようになります。

Webページに関しては、ようこそページ(index.jsf)に対して作成されたindexPageDefページ定義に権限が定義されていることに注意してください。また、これはバインド・タスク・フローによってまだ保護されていないトップレベルWebページであることにも注意してください。

<policy-store>
...
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<name>anonymous-role</name>
<class>oracle.security.jps.internal.core.principals.
JpsAnonymousRoleImpl</class>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.controller.security.TaskFlowPermission</class>
<name>/WEB-INF/flows/emp-reg-task-flow-definition.xml#
#emp-reg-task-flow-definition</name>
<actions>view</actions>
</permission>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>oracle.summit.view.pageDefs.indexPageDef</name>
<actions>view</actions>
</permission>
...
</permissions>
</grant>
...
</jazn-policy>
</policy-store>

47.5.8 実行時に行われる処理: ADFセキュリティ・ポリシーの実施方法

ADFリソースに作成する権限は、標準のJAAS権限です。アプリケーションでADFセキュリティを有効化すると、Oracle WebLogic Server上で実行されているOracle Platform Security Service (OPSS)は、この権限を使用して認可を実行します。認可モードでは、ADFセキュリティは、JAAS権限で実装され、ページへのアクセス権のセキュリティ・チェックを実行する、きめ細かい認可を使用します。ADFセキュリティ施行ロジックは、JAASサブジェクトによって表現されるユーザーが、リソースにアクセスする正しい権限を持っているかどうかを確認します。

サブジェクトには、ユーザーのプリンシパル(ログオン前は無名、ログオン後はユーザー名を含むユーザー・プリンシパル)とロール・プリンシパルのリスト(authenticated-role、ポリシー・ストアやアイデンティティ・ストアから取得されるいくつかのロールなど)が含まれます。プリンシパルは、ポリシー・ストアに定義されているアプリケーション・ロールのすべてのユーザーのメンバーシップを表すために作成されます。また、各アプリケーション・ロールには複数の権限を関連付けておくことができます。これらは、jazn-data.xmlファイルの概要エディタで作成されるADFセキュリティ・ポリシーです。

注意:

ADFセキュリティ・ポリシーはアプリケーションごとにスコープ指定されます。このスコープで2つのアプリケーションは、意図しない結果を生じることなく、同じ権限ターゲットを参照します。ポリシー・ストア情報のアプリケーション・スコープを設定するためにアプリケーション・リソースを指定する必要はありません。

統合WebLogic Serverを使用してアプリケーションを実行する前に、テスト・ユーザーを含むアイデンティティ・ストアをプロビジョニングし、構成するアプリケーション・ロールにそれらのユーザーを追加する必要があります。「テスト・ユーザーの作成」で説明するように、アプリケーション・ロールでは、ユーザーまたはユーザー・グループ(エンタープライズ・ロール)に固有のメンバーを定義できます。

その後、実行時に、現在のユーザーがアクセスしようとしているページのview権限を持っているかどうかが、ページのコンテキストによって決まります。

- ページがバインド・タスク・フローのアクティビティである場合は、タスク・フロー・コントローラによって権限が決まります。

- ページが、ページ定義ファイルが関連付けられたトップレベル・ページである場合は、ADFモデル・レイヤーによって権限が決まります。

次に、Oracle Platform Security Servicesにより、ページにアクセスするために必要な権限を持つロールがサブジェクトに含まれるかどうかが確認されます。ユーザーが認可されると、タスク・フローが開始します。

バインド・タスク・フローとトップレベル・ページ(バインドなしタスク・フローで定義)の場合、ユーザーが認可されないと、ADFコントローラによって例外がスローされ、タスク・フロー構成で指定された例外ハンドラに制御が渡されます。他のエラー・ページの指定の詳細は、「認証後にユーザーをリダイレクトする方法」を参照してください。

47.5.9 ADFバインドなしのページのポリシー定義に関する必知事項

「ADFセキュリティの構成」ウィザードのデフォルト・オプション「ADF認証および認可」では、認可チェックが有効になり、Webページが保護されます(WebページがADFセキュリティ対応リソースに関連付けられている場合)。したがって、ウィザードを実行した後で、次の両方の条件が存在するとWebページは保護されません。

- ページにデータバインドADF Facesコンポーネントが表示されず、ページにADFページ定義が存在していない場合。

- ページがデータバインドADFタスク・フローの構成ページでない場合。(ユーザーがバインド・タスク・フローのプロセスとしてアクセスするすべてのページは、タスク・フローの権限でチェックされます。)

「データ・コントロール」パネルを使用してWebページを設計し、データバインドされたADF Facesコンポーネントを作成するときには常に、JDeveloperによってADFページ定義ファイルが生成されます。ただし、WebページがADFバインディングを使用しない場合でも空のページ定義ファイルを作成できます。これには、ユーザー・インタフェース・プロジェクトのWebページを右クリックして、「ページ定義に移動」を選択します。このページ定義ファイルは空にしておくことができます。このページは、データバインドADF FacesコンポーネントをサポートするためにADFバインディングと連携する必要がないためです。

WebページとADFページ定義ファイル(空かどうかに関係なく)をいったん関連付けると、関連付けられたWebページにユーザーがアクセスするときに認可チェックが施行されます。他のADFページ定義と同様にページのセキュリティ・ポリシーを定義できます。空のADFページ定義に対する権限付与の詳細は、「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。

始める前に:

個々のページの定義ファイルのセキュリティについて理解しておくと役立ちます。詳細は、「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。

JDeveloperがページ定義ファイルを生成する通常の方法について理解しておくことも役立ちます。詳細は、「ページ定義ファイルでの作業」を参照してください。

セキュリティ・ポリシーを定義するために空のページ定義を作成するには:

1. 「アプリケーション」ウィンドウで、保護するWebページを探し、ノードを右クリックして「ページ定義に移動」を選択します。

2. 確認ダイアログで「はい」をクリックすると、ページの新しいページ定義が作成されます。
ページ定義はpageDefsパッケージに追加されます。

47.5.10 正規表現を使用したリソース・グループのポリシーの定義方法

一度に複数のリソースに適用する権限を定義する場合は、java.util.regex.Patternクラスによって定義されるパターンを作成して、実行時に評価される正規表現を生成します。たとえば、権限を一連のリソースに対応させるには、権限の名前に対して.* (任意の文字0個以上を表す)という表現を入力できます。ADFセキュリティでは、他のセキュリティ・オブジェクト(プリンシパル名など)については正規表現を使用できません。

この機能を使用すると、次の例に示すように、同じ権限を持つバインド・タスク・フローをグループ化してWEB-INFの専用のサブフォルダに含め、そのフォルダ全体に権限を定義できます。この場合、ピリオド(任意の文字を表す)の後にアスタリスク修飾子(0回以上を表す)を付けた正規表現を使用します。

...
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>anonymous-role</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.controller.security.TaskFlowPermission</class>
<name>/WEB-INF/.*</name>
<actions>view</actions>
</permission>
</permissions>
</grant>

jazn-data.xmlファイルの概要エディタのユーザー・インタフェースでは、正規表現の使用がサポートされていないため、直接ファイルを編集する必要があります。system-jazn-data.xmlファイルのポリシー・ストアを直接編集しないでください。そのかわりに、正規表現を使用してjazn-data.xmlファイルに権限を追加します。アプリケーションを実行またはデプロイすると、これらの権限がポリシー・ストアにマージされます。

より複雑な正規表現を使用すると、ポリシーにビジネス・ルールを定義して、非常に限定的な権限のセットを作成できます。たとえば、すべてのページ定義にview権限を付与すると同時に、正規表現で除外セットを定義して特定のページ定義を除くことができます。次の例は、customで始まるページ定義名を除いたすべてのページに関してanonymous-roleにview権限を付与する方法を示しています。

<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>anonymous-role</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>[^(custom)].*</name>
<actions>view</actions>
</permission>
</permissions>
</grant>

表47-7は、ポリシー定義で使用できる正規表現の基本的なメタ文字の一部を示しています。

表47-7 メタ文字の説明

メタ文字

説明

[abc]

a、bまたはc(リストに含まれる)

[^abc]

a、bまたはc以外の文字(否定)

[a-zA-Z]

aからzまたはAからZ、包含的(範囲)

[a-d[m-p]]

aからd、またはmからp~= [a-dm-p](和集合)

[a-z&&[def]]

d、eまたはf(積集合)

[a-z&&[^bc]]

aからzのうち、bおよびcを除く、つまり[ad-z](減算)

[a-z&&[^m-p]]

aからzのうち、mからpを除く

.*

任意の個数の任意の文字(この表現ではピリオドとアスタリスクを一緒に使用することに注意)

47.5.11 データのポリシーを定義する方法

データ・モデル・オブジェクトのADFエンティティ・オブジェクトはセキュリティ対応です。つまり、開発者が付与することのできるリソース固有の権限が事前定義されています。さらに、エンティティ・オブジェクトの個々の属性だけを保護することもできます。

セキュリティ保護の対象とするエンティティ・オブジェクトでは、UIコンポーネントがADFバインディングによってセキュアなエンティティ・オブジェクトのアクセス先データにバインドされている場合に、そのUIコンポーネントをレンダリングしているWebページに表示されるデータの、ユーザーによる更新が制限されます。さらに、エンティティ・オブジェクトをセキュリティ保護する際、そのエンティティ・オブジェクトに依存するデータ・モデル・プロジェクト内のビュー・オブジェクトも事実上保護します。そのため、セキュリティ保護するエンティティ・オブジェクトは、このビュー・オブジェクトにバインドされたUIコンポーネントに適用される、さらに広範なアクセス・ポリシーを定義します。

ADFエンティティ・オブジェクトを使用して行データを保護するには:

1. 保護するエンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について、特定のアクションの権限マップを定義します。

2. ポリシー・ストアに追加したアプリケーション・ロールに権限を付与します。

47.5.11.1 ADFエンティティ・オブジェクトに対する権限マップの定義

データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクトによって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。

概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission)によって定義されます。権限クラスは、エンティティ・オブジェクトでサポートされる操作をアクションにマップします。表47-8は、エンティティ・オブジェクトの、セキュア化できる操作を示しています。

表47-8 ADFエンティティ・オブジェクトのセキュア化可能な操作

セキュアな操作

想定されるマップされたアクション

対応する実装

read

read

WHERE句フラグメントで制限された、数行の結果セットを表示します。

update

update

バインドされたコレクションの属性を更新します。

removeCurrentRow

delete

バインドされたコレクションの1つの行を削除します。

注意:

read操作やupdate操作とは異なり、deleteアクションにマップされるセキュア化可能な操作は、一意識別子removeCurrentRowで定義されます。Fusion Webアプリケーションの認可チェックはアクション名ではなく操作名に依存するため、delete権限名ではなくremoveCurrentRow操作名をテストする必要があります。エンティティ権限をテストできるようにするエンティティ行APIおよびEL式の詳細は、「エンティティ・オブジェクト操作の認可チェックの実行方法」を参照してください。

エンティティ・オブジェクトがアクセスするすべての行レベル・データを保護するには、エンティティ・オブジェクト用の概要エディタを使用します。

始める前に:

エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」の説明に従って、データ・モデル・プロジェクトにエンティティ・オブジェクトを作成します。

エンティティ・オブジェクトに対する操作をセキュア化する手順:

1. 「アプリケーション」ウィンドウで、保護するエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

3. 「一般」ページで「セキュリティ」セクションを開き、エンティティ・オブジェクトについて保護する操作を選択します。

「セキュリティ」セクションに、EntityPermissionクラスで定義されている、保護できる操作が表示されます。このクラスがエンティティ・オブジェクトのマッピングを行います。表47-8に示すように、特定のアクションがエンティティ・オブジェクトの操作にマッピングされます。

たとえば、read権限を有効化するには、図47-11に示すように選択します。権限が、エンティティ・オブジェクトのXML定義に表示されます。

図47-11 ADFエンティティ・オブジェクトのread操作に対する権限を有効化

47.5.11.2 ADFエンティティ・オブジェクト属性に対する権限マップの定義

データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクト属性によって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。

概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission)によって定義されます。権限クラスは、エンティティ・オブジェクト属性でサポートされる操作をアクションにマップします。表47-9は、エンティティ・オブジェクト属性の、保護可能な操作を示しています。

表47-9 ADFエンティティ・オブジェクト属性のセキュア化可能な操作

セキュアな操作

想定されるマップされたアクション

対応する実装

update

update

バインドされたコレクションの特定の属性を更新します。

エンティティ・オブジェクトがアクセスするデータの個々の列を保護するには、エンティティ・オブジェクト用の概要エディタの「属性」ページを使用します。

始める前に:

エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

- 「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」の説明に従って、データ・モデル・プロジェクトにエンティティ・オブジェクトを作成します。

エンティティ・オブジェクト属性に対する操作をセキュア化する手順:

1. 「アプリケーション」ウィンドウで、保護する属性を定義するエンティティ・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 属性ページで保護する属性を選択し、「セキュリティ」タブをクリックして、update操作を選択します。

「セキュリティ」タブに、EntityAttributePermissionクラスで定義されるセキュア化可能な操作が表示されます。このクラスがエンティティ・オブジェクトのマッピングを行います。表47-9に示すように、特定のアクションがエンティティ・オブジェクトの操作にマッピングされます。

たとえば、update権限を有効化するには、図47-12に示すように選択します。権限マップが、エンティティ・オブジェクトのXML定義に表示されます。

図47-12 ADFエンティティ・オブジェクトのupdate操作に対して権限を有効化

47.5.11.3 ADFエンティティ・オブジェクトおよびエンティティ属性に対する権限の付与

権限ターゲットが構成されても、エンティティ・オブジェクトの権限ターゲットに対してポリシー権限が明示的に定義されるまで、エンティティ・オブジェクトあるいはその属性から導出されるデータは、セキュリティ保護されないままです。

既存のエンティティ・オブジェクトまたはエンティティ属性の権限ターゲットに対するアクセス・ポリシーを定義するには、セキュリティ・ポリシーの概要エディタを使用します。

始める前に:

エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

1. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

2. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

3. 「ADFエンティティ・オブジェクトに対する権限マップの定義」の説明に従って、エンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について権限ターゲットを定義します。

エンティティ・オブジェクトまたはエンティティ属性のアクセス・ポリシーを定義するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「ADFエンティティ・オブジェクト」または「ADFエンティティ・オブジェクト属性」を選択します。

概要エディタの「リソース権限」ページに、これまでに権限ターゲットを定義したすべてのエンティティ・オブジェクト(またはエンティティ属性)が表示されます。

3. 「リソース」列で、アクセス権を付与するADFエンティティ・オブジェクトまたはエンティティ属性を選択します。

初めてADFエンティティ・オブジェクトまたはエンティティ属性に権限付与を行うとき、図47-13に示すように、先頭列のメソッド名の隣には「権限のないリソース」アイコン(ロック・アイコン)が表示されています。エディタに表示されるロック・アイコンは、リソースにセキュリティ・ポリシーが定義されていないためにロックされている(権限を定義するまでユーザーがアクセスできない)ことを示します。

図47-13 概要エディタでの権限のないエンティティ・オブジェクト

4. 「ロールに付与済」列で「権限受領者の追加」アイコンをクリックし、「アプリケーション・ロールの追加」を選択します。

5. 「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。

「アプリケーション・ロールの選択」ダイアログには、jazn-data.xmlファイルのアプリケーション・ロールが表示されます。「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。

アプリケーション固有のアプリケーション・ロールが表示されていない場合は、「アプリケーション・ロールの作成」の説明に従ってロールを作成します。

6. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。

7. 概要エディタの「リソース権限」ページの「アクション」列で、特定のアプリケーション・ロールに付与するアクションを選択します。

エンティティ・オブジェクトに対し、概要エディタではデフォルトでreadアクションが選択されています。表47-8に示すように、対応する権限ターゲットをすでに構成している場合は、updateアクションおよびdeleteアクションを選択できます。

エンティティ・オブジェクト属性に関しては、表47-9に示す権限ターゲットに対し、概要エディタではデフォルトでupdateアクションが選択されています。エンティティ・オブジェクト属性に対してサポートされる他のアクションはありません。

図47-14は、エンティティ・オブジェクトのアプリケーション・ロールApplication Employee Roleに付与されるdelete、read、update権限を示しています。

図47-14 概要エディタでADFエンティティ・オブジェクト権限をアプリケーション・ロールに付与

8. この手順を必要なだけ繰り返して、追加の権限を作成します。

同一のADFエンティティ・オブジェクトまたはエンティティ属性に、異なるアプリケーション・ロールに対する複数の権限が定義される場合があります。「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xmlファイルのポリシー・ストア定義に含まれます。

47.5.12 リソース権限を資格付与として集約する方法

リソース権限を作成することで、セキュア化できる個々のOracle ADFアーティファクトに対するエンド・ユーザーのアクセス権を定義します。しかし、管理とメンテナンスを容易にするため、リソース権限を資格付与として定義することもできます。こうすると、セキュア化可能な複数のアプリケーション・アーティファクトが1つの名前付きセキュリティ・グループとして集約され、これを1つの文によってアプリケーション・ロールに付与できます。たとえば、ADFビジネス・コンポーネント・エンティティ・オブジェクトによってアプリケーション内で公開されるデータへのアクセスを認可しようとする場合、複数のエンティティ・オブジェクトに対して同一のセキュリティ・ポリシーが必要になる可能性があります。各エンティティ・オブジェクトに対してアクセス権限を個別に付与するのではなく、これらの権限を1つの資格としてグループ化し、一括して付与できます。

セキュリティ・ポリシーの概要エディタの「資格付与」ページで、資格付与を作成します。作成する権限は、jazn-data.xmlファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、選択したリソース・インスタンスとアクションとのペアで構成される1つの資格(XML定義では<permission-set>として識別されます)を定義します。この資格は付与可能なエンティティであり、アプリケーション・ロールに付与できます。

セキュリティ・ポリシーの概要エディタには、リソース・タイプのリストが表示されます。選択したリソース・タイプにより、アプリケーション・ワークスペースのプロジェクト内で定義されたリソース・インスタンスがフィルタ処理されます。また、選択したリソース・タイプにより、概要エディタに表示される使用可能なアクションのリストが決定されます。たとえば、リソース・タイプタスク・フロー権限を選択した場合、概要エディタには、選択したユーザー・インタフェース・プロジェクト内のすべてのタスク・フローが表示されます。また、viewアクションも表示され、これを使用可能なADFバインド・タスク・フロー・リソースに関連付けることができます。

表47-10は、JDeveloperで表示されるリソース・タイプのリストと、各タイプに対して関連付けられるリソースおよびサポートされるアクションを示します。

表47-10 セキュア化できるOracle ADFアーティファクトのリソース・タイプ

リソース・タイプ

サポートされるリソースおよびアクション

タスク・フロー

選択したユーザー・インタフェース・プロジェクト内のADFバインド・タスク・フローに対してviewアクションを定義します。

Webページ

選択したユーザー・インタフェース・プロジェクト内のADFページ定義ファイルに基づくリージョンおよびWebページに対してviewアクションを定義します。

ADFエンティティ・オブジェクト

選択したデータ・モデル・オブジェクト内のエンティティ・オブジェクトに対してread、updateおよびdeleteアクションを定義します。

ADFエンティティ・オブジェクト属性

選択したデータ・モデル・オブジェクト内の特定のエンティティ・オブジェクトのエンティティ・オブジェクト属性に対してupdateアクションを定義します。

セキュア化できるOracle ADFアーティファクトに対して資格付与を定義するには、セキュリティ・ポリシーの概要エディタの「資格付与」ページを使用します。

始める前に:

エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「リソース権限を資格付与として集約する方法」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

Oracle ADFアーティファクトに対して資格付与を定義するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「資格付与」を選択します。

2. セキュリティ・ポリシー概要エディタの「資格付与」ページで、「資格」セクションの「資格の追加」アイコンをクリックします。

概要エディタに、アプリケーションで定義されるすべてのリソースが表示されます。

3. 「資格付与」ページで、「リソース」タブをクリックして「メンバー・リソースの追加」アイコンをクリックし、メンバー・リソースを資格に追加します。

4. 「リソースの選択」ダイアログで、「リソース・タイプ」ドロップダウン・リストからリソースを選択して、「ソース・プロジェクト」セクションで必要なプロジェクトを選択します。

ダイアログに、アプリケーション・ワークスペース内のすべてのプロジェクトが表示されます。

5. 「使用可能なリソース」セクションで、リソースを選択して「追加」アイコンをクリックします。

ダイアログに、選択したプロジェクトによって定義されたすべてのリソースが表示されます。

6. 「アクション」リストで、選択したリソースに対する目的のアクションを選択します。

図47-15に示す概要エディタでは、タスク・フローに対してViewアクションが選択され、資格に追加されています。

図47-15 バインド・タスク・フローを資格内のリソースとして追加

7. 必要なその他のリソースをリストに追加します。

8. 「資格付与」ページで、「付与」タブをクリックして、「ロール付与の追加」アイコンをクリックし、アプリケーション・ロールに資格を付与します。

9. 「アプリケーション・ロールの選択」ダイアログで、1つ以上のカスタム・アプリケーション・ロールを選択します。

ダイアログに、jazn-data.xmlファイル内のすべてのアプリケーション・ロールが表示されます。事前定義されたアプリケーション・ロール(Oracle Fusionアプリケーションの用語では職務ロールとも呼びます)に権限を追加しないでください。JDeveloperで自分で作成したカスタム・アプリケーション・ロール、またはこの目的でITセキュリティ・マネージャによって作成されたカスタム・アプリケーション・ロールのみを選択してください。

10. 「OK」をクリックします。

11. これらの手順を繰り返して他のリソースを追加し、同一カスタム・アプリケーション・ロールの同一資格に対して、これらのリソースの権限を作成します。

47.5.13 資格作成後の処理

JDeveloperのセキュリティ・ポリシー・エディタを使用して資格を作成すると、JDeveloperはjazn-data.xmlファイル内で、アプリケーション・ポリシー・ストアのソースを修正します。ファイルのポリシー・ストア・セクションには、<resource-type>定義(選択したリソース・タイプに対してサポートされるアクションを識別)、<resource>定義(アプリケーションから選択してリソース・タイプにマッピングしたリソース・インスタンスを識別)、<permission-set>定義(1つの資格として付与されるリソースおよびアクションを定義)、および<grant>定義が含まれ、1つ以上の資格(XML内で権限セットとして定義)が目的のアプリケーション・ロール(権限受領者)に付与されます。

次の例に示すように、Oracle Fusionアプリケーションにおける資格ベースのセキュリティ・ポリシーは、<jazn-policies>要素内で定義され、単一のアプリケーション・ロールに付与される1つ以上の資格によって構成されます。

<?xml version="1.0" ?>
<jazn-data>
<policy-store>
<applications>
<application>
<name>MyApp</name>

<app-roles>
<app-role>
<name>AppRole</name>
<display-name>AppRole display name</display-name>
<description>AppRole description</description>
<guid>F5494E409CFB11DEBFEBC11296284F58</guid>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
</app-role>
</app-roles>

<role-categories>
<role-category>
<name>MyAppRoleCategory</name>
<display-name>MyAppRoleCategory display name</display-name>
<description>MyAppRoleCategory description</description>
</role-category>
</role-categories>

<!-- resource-specific OPSS permission class definition -->
<resource-types>
<resource-type>
<name>APredefinedResourceType</name>
<display-name>APredefinedResourceType display name</display-name>
<description>APredefinedResourceType description</description>
<provider-name>APredefinedResourceType provider</provider-name>
<matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>write,read</actions>
</resource-type>
</resource-types>

<resources>
<resource>
<name>MyResource</name>
<display-name>MyResource display name</display-name>
<description>MyResource description</description>
<type-name-ref>APredefinedResourceType</type-name-ref>
</resource>
</resources>

<!-- entitlement definition -->
<permission-sets>
<permission-set>
<name>MyEntitlement</name>
<display-name>MyEntitlement display name</display-name>
<description>MyEntitlement description</description>
<member-resources>
<member-resource>
<type-name-ref>APredefinedResourceType</type-name-ref>
<resource-name>MyResource</resource-name>
<actions>write</actions>
</member-resource>
</member-resources>
</permission-set>
</permission-sets>

<!-- Oracle function security policies -->
<jazn-policy>
<!-- function security policy is a grantee and permission set -->
<grant>
<!-- application role is the recipient of the privileges -->
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole
</class>
<name>AppRole</name>
<guid>F5494E409CFB11DEBFEBC11296284F58</guid>
</principal>
</principals>
</grantee>

<!-- entitlement granted to an application role -->
<permission-set-refs>
<permission-set-ref>
<name>MyEntitlement</name>
</permission-set-ref>
</permission-set-refs>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
</jazn-data>

47.6 テスト・ユーザーの作成

JDeveloperで提供されるエディタを使用して、アイデンティティ・ストアとポリシー・ストアの両方を作成できます。アプリケーション固有のjazn-data.xmlファイルに両方のリポジトリを作成します。ファイルのアイデンティティ・ストア・セクション用のエディタでは、有効なユーザーIDと割り当てられたパスワードのリストを入力できます。同じエディタを使用して、アプリケーション・ロールを作成し、アプリケーション・ロールのメンバーとしてテスト・ユーザーまたはエンタープライズ・ロールを割り当てることができます。定義されると、この情報はjazn-data.xmlファイルのポリシー・ストア・セクションに表示されます。

47.6.1 JDeveloperでテスト・ユーザーを作成する方法

アプリケーションのアイデンティティ・ストアに一時的なユーザーのセットを生成して、本番環境での実際のユーザーの体験をシミュレートします。統合WebLogic Serverでアプリケーションを実行すると、任意のテスト・ユーザーとしてログインでき、アプリケーションのセキュアADFリソースを表示するアクセス権を与えられます。

アイデンティティ・ストアを使用すると、エンタープライズ・ロールにユーザーをグループ分けすることができます。通常は、JDeveloperのデプロイメント・オプションを構成して、アイデンティティ・ストアをステージング環境に移行しないようにするため、jazn-data.xmlファイルに作成するエンタープライズ・ロールは便宜上のものです。エンタープライズ・ロールの使用方法の詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。

注意:

アイデンティティ・ストアのスタンドアロン・サーバーへのデプロイを選択する場合、Oracle WebLogic Serverに対してすでに構成されているローカル・アイデンティティ・ストアにユーザーとエンタープライズ・ロールを作成しないでください。たとえば、ユーザーweblogicとエンタープライズ・ロールAdministratorsを含むアイデンティティ・ストアをデプロイする場合は、ターゲット・サーバーのデフォルト管理構成を上書きします。Oracle WebLogic Serverによってデフォルトでインストールされるグローバル・ロールの完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・ロール」を参照してください。

ユーザーがリソースを表示できるようにするには、そうしたロールのメンバーであるユーザーではなく、アプリケーション・ロールに対して権限を付与します。したがって、アイデンティティ・ストアにテスト・ユーザーを生成した後で、各ユーザーまたはエンタープライズ・ロール・グループをアプリケーション・ロールに関連付ける必要があります。この関連付けにより、ADFセキュリティ・ポリシーによって定義されたアクセス権がユーザーに付与されます。アクセス権のユーザーへの付与の詳細は、「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」を参照してください。

始める前に:

アイデンティティ・ストアについて理解しておくと役立ちます。詳細は、「テスト・ユーザーの作成」を参照してください。

テスト・ユーザーおよびグループを作成するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「ユーザー」を選択します。

2. セキュリティ・ポリシーの概要エディタの「ユーザー」ページで、「レルム」ドロップダウン・リストからアプリケーションのレルムを選択して、次の手順を実行します。
JDeveloperでは、レルムjazn.comがデフォルトで使用されます。

a. 「ユーザー」リストで「新規ユーザー」アイコンをクリックします。

b. 「名前」フィールドにユーザー名を入力します。
Oracle WebLogic Serverに対してすでに構成されているユーザー名を選択しないでください(たとえば、webcenterは入力しないでください)。Oracle WebLogic Serverによりインストールされているユーザー名のリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・ロール」を参照してください。

c. 「パスワード」フィールドにユーザーのパスワードを入力します。他の任意のフィールドをクリックすると、パスワードがアイデンティティ・ストアに追加されます。
パスワードは8文字以上で指定し、特殊文字(!、%、^、&、$など)を少なくとも1つ含める必要があります。

3. 必要に応じて、セキュリティ・ポリシーの概要エディタで、「エンタープライズ・ロール」ナビゲーション・タブをクリックし、アプリケーションのレルムを「レルム」ドロップダウン・リストから選択して、次の手順を実行します。
ユーザーをグループ分けしてアプリケーション・ロールに追加する場合のみ、エンタープライズ・ロールを作成します。統合WebLogic Serverを使用してアプリケーションを実行するためのテスト・ユーザーを作成する目的であれば、エンタープライズ・ロール・グループを作成する必要はありません。

a. 「エンタープライズ・ロール」リストで「新規ロール」アイコンをクリックします。

b. 「名前」フィールドにエンタープライズ・ロール名を入力します。他のいずれかのフィールドをクリックすると、ロールがアイデンティティ・ストアに追加されます。
エンタープライズ・ロール・グループを作成する場合、Oracle WebLogic Serverに対してすでに構成されているロール名を選択しないでください(たとえば、Administratorsは入力しないでください)。Oracle WebLogic Serverによってインストールされるデフォルト・グループ名の完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・ロール」を参照してください。

47.6.2 テスト・ユーザー作成時の処理

ユーザー・アイデンティティとエンタープライズ・ロール・グループを含むアイデンティティ・ストアをプロビジョニングすると、Webアプリケーション・ワークスペースを基準とした/src/META-INFノードにあるjazn-data.xmlファイルがJDeveloperによって更新されます。

ダイアログによって、アイデンティティ・ストアに対応するファイルの<jazn-realm>セクションにユーザー情報が書き込まれます。各ユーザー・アイデンティティには、ユーザー名とユーザー・ログイン・パスワードが含まれます。各エンタープライズ・ロールには1つ以上のメンバー・ユーザーが含まれます。

次の例は、2つのユーザーと2つのエンタープライズ・ロールを含むjazn-data.xmlファイルのアイデンティティ・ストアを示しています。ユーザーcmageeはEnterprise Employee Groupエンタープライズ・ロールのメンバーで、ユーザー214はEnterprise Customer Groupエンタープライズ・ロールのメンバーです。

<jazn-data>
<jazn-realm default="jazn.com">
<realm>
<name>jazn.com</name>
<users>
<user>
<name>cmagee</name>
<display-name>Colin Magee</display-name>
<description>Sales Rep</description>
<credentials>{903}5AUHlE+qvDxxAhxIMoXJ/WLhMF0ynue7</credentials>
</user>
<user>
<name>214</name>
<display-name>Ojibway Retail</display-name>
<description>Customer</description>
<credentials>{903}rijN2KQCBSeBQ/JNZlv8GwwUiGWk5IQa</credentials>
</user>
...
</users>
<roles>
<role>
<name>Enterprise Employee Group</name>
<members>
<member>
<type>user</type>
<name>cmagee</name>
</member>
</members>
</role>
<role>
<name>Enterprise Customer Group</name>
<members>
<member>
<type>user</type>
<name>214</name>
</member>
...
</members>
</role>
...
</roles>
</realm>
...
</jazn-realm>
</jazn-data>

47.6.3 テスト・ユーザーとアプリケーション・ロールを関連付ける方法

ADFセキュリティ・フレームワークは、アプリケーション・ロールに付与された権限を使用するロールベースのアクセス制御メカニズムを施行するため、アプリケーション固有の一連のロールをポリシー・ストアに定義します。たとえば、ワークフローのコンテキストでは、顧客、製品担当、監督者、管理者などのロールを想定できます。

アプリケーション・ロールを作成したら、アイデンティティ・ストアに作成したユーザーに1つ以上のロールを関連付けることができます。アプリケーション・ロールのメンバーであるユーザーには、実行時にアプリケーション・ロールのアクセス権が付与されます。複数のリソース権限を特定のユーザーに付与する場合は、1ユーザーを複数のアプリケーション・ロールに割り当てることができます。

たとえば、認証された1ユーザーがスーパーバイザ・ロールと従業員ロールに所属し、別の1ユーザーは従業員ロールのみに所属する場合があります。顧客レコードのブラウズと編集を許可するバインド・タスク・フローのセキュリティ・ポリシーでは、スーパーバイザ・ロールにview権限が与えられますが、従業員ロールにはブラウズ・ページのview権限に制限されます。このように、アプリケーション・ロールへの権限付与により複数レベルのアクセスに対応します。認証されたユーザーが、ターゲットADFリソースのview権限を持つアプリケーション・ロールのメンバーでない場合は、ユーザーが認証されていないというメッセージがセキュリティ・フレームワークによって返されます。

始める前に:

アイデンティティ・ストアについて理解しておくと役立ちます。詳細は、「テスト・ユーザーの作成」を参照してください。

次のタスクを完了する必要があります。

1. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

2. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

3. 「ADFセキュリティ・ポリシーの定義」の説明に従って、ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義します。

4. 「JDeveloperでテスト・ユーザーを作成する方法」の説明に従って、テスト・ユーザーを作成し、必要に応じてエンタープライズ・ロール・グループを作成します。

ユーザーをアプリケーション・ロールに関連付けるには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。

2. セキュリティ・ポリシーの概要エディタの「アプリケーション・ロール」ページで、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。
JDeveloperによってjazn-data.xmlファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。

3. 「ロール」リストで既存のアプリケーション・ロールを選択し、必要に応じて次のタスクを実行します。

a. 「マッピング」セクションで、「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「ユーザーの追加」を選択します。次に、「ユーザーの選択」ダイアログで、前に作成したユーザーをリストから選択して「OK」をクリックします。

b. アイデンティティ・ストアにエンタープライズ・ロールを定義している場合、必要であれば、「マッピング」セクションで「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「エンタープライズ・ロールの追加」を選択します。次に、「エンタープライズ・ロールの選択」ダイアログで、前に作成したエンタープライズ・ロールをリストから選択して「OK」をクリックします。

47.6.4 アプリケーション・ロール構成時の処理

ユーザーにアプリケーション・ロールを関連付けると、Webアプリケーション・ワークスペースを基準とした/src/META-INFノードにあるjazn-data.xmlファイルがJDeveloperによって更新されます。

ダイアログによって、ファイルの<policy-store>セクションにユーザー情報が書き込まれます。各アプリケーション・ロールには1つ以上のメンバー・ユーザーまたはエンタープライズ・ロールが含まれます。

次の例は、Enterprise Employee GroupとEnterprise Manager Groupという2つのメンバーが含まれている、Application Employee Roleアプリケーション・ロールを持つjazn-data.xmlファイル内のポリシー・ストアを示しています。

<policy-store>
<applications>
<application>
<name>SummitADF</name>
<app-roles>
<app-role>
<name>Application Employee Role</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<display-name>Application Employee Role</display-name>
<members>
<member>
<class>oracle.security.jps.internal.core.principals.
JpsXmlEnterpriseRoleImpl</class>
<name>Enterprise Employee Group</name>
</member>
<member>
<class>oracle.security.jps.internal.core.principals.
JpsXmlEnterpriseRoleImpl</class>
<name>Enterprise Manager Group</name>
</member>
...
</members>
</app-role>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
</applictions>
</policy-store>

47.7 ログイン・ページの作成

ADFセキュリティでは、暗黙的認証および明示的認証を使用できます。

- 暗黙的な認証のシナリオでは、未認証のユーザーがアクセスしようとするWebページが、anonymous-roleに権限付与されていないADFセキュリティ対応リソースに関連付けられている場合、認証が動的にトリガーされます。ユーザーが正常にログインすると、認証されたユーザーが、リクエストしたページのADFセキュリティ対応リソースに対するviewアクセス権を付与されているかどうかを検証するために別のチェックが実行されます。

- 明示的な認証のシナリオでは、ログイン・リンクが表示された公開ページがアプリケーションに用意され、このリンクをクリックすると、そのユーザーのログインにおいて認証チャレンジがトリガー実行されます。ログイン・リンクには、認証が成功した後に表示するいくつかの他のターゲット・ページ(認証済ユーザーがアクセス権を持っている場合)を指定できます。

「ADF認証に関する必知事項」で説明したように、暗黙的および明示的な認証のシナリオは、ADFセキュリティの構成ウィザードを実行するとデフォルトで処理されます。ただし、デフォルトの生成済ログイン・ページをカスタマイズ(または独自のページを指定)してADF Facesコンポーネントを使用する場合は、コンテナ管理デプロイメント・ディスクリプタ(web.xmlファイル)を構成する必要があります。

ユーザー認証を明示的に処理するには:

1. ログイン・リンク・コンポーネントを作成し、アプリケーションのパブリック・ホームページに追加します。

2. Servlet 3.0固有のAPIを使用して、ユーザーによるログインの試行を処理するマネージドBeanを作成します。

3. ADF Facesコンポーネントを使用して、JSFログイン・ページを作成します。

4. ログイン・ページのリソースがアクセス可能であることを確認します。

暗黙的な認証と明示的な認証の詳細は、「実行時に行われる処理: ADFセキュリティによる認証の処理」を参照してください。

47.7.1 明示的な認証用にログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法

アプリケーションのどのページにも追加できる標準的なログイン・リンク・コンポーネントを作成して、ユーザーの認証または以降のログオフができます。このコンポーネントは、ユーザーの認証状態を追跡し、適切なログインまたはログアウトのURLおよびアイコンを戻します。このログイン・リンク・コンポーネントは、ユーザーの認証後、ユーザーを特定のページにリダイレクトします。したがって、このログイン・リンク・コンポーネントを使用すると、一貫性のある単一のオブジェクトを得られます。

認証されていないユーザーに対しては、ログイン・リンク・コンポーネントは図47-16のように表示されます。

図47-16 ユーザーがログインする前のコンポーネント

その後、ユーザーがログイン・リンクをクリックして、適切な資格証明を持つユーザーとしてログインすると、コンポーネントは図47-17のようになります。

図47-17 ユーザーがログインした後のコンポーネント

始める前に:

ADF認証について理解しておくと役立ちます。詳細は、「ログイン・ページの作成」を参照してください。

次のタスクを完了する必要があります。

- ログインおよびログアウトのイメージ・ファイル(GIF、JPG、PNGなどのファイル)を、プロジェクトのpublic_htmlディレクトリにコピーします。

注意:

アプリケーションでスキンを使用する場合は、使用されるイメージは適切なスキン・イメージを参照している必要があります。スキンの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」を参照してください。

ログイン・リンク・コンポーネントを作成してページに追加するには:

1. 「アプリケーション」ウィンドウで、コンポーネントを表示するWebページをダブルクリックします。

2. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「共通コンポーネント」パネルからリンクをドラッグして、このページにドロップします。

3. 「構造」ウィンドウで「af:link」を右クリックし、「プロパティに移動」を選択します。

4. 「プロパティ」ウィンドウで、「リンク」コンポーネントのラベルを指定して、「テキスト」フィールドに条件式言語(EL)式を入力します。

たとえば、次のようなEL式を入力して、リンク・テキストを条件付きでレンダリングできます。

#{securityContext.authenticated ? &quot;Click to log out&quot; :
&quot;Click to log in&quot;}

現在のユーザーが認証されると、securityContext Beanのauthenticatedプロパティがtrueに評価され、ログアウト・オプションがレンダリングされます。それ以外の場合はログイン・オプションのリンクがレンダリングされます。

5. 「プロパティ」ウィンドウで、「リンク」コンポーネントのURLを指定して、「宛先」フィールドにEL式を入力します。

たとえば、次のEL式はユーザーが認証済かどうかに応じて、ユーザーを転送するURLを条件付きでレンダリングします。

#{securityContext.authenticated ? \"Logout\" : \"Login\"}" id="gl2" destination="#{securityContext.authenticated ?
\"/adfAuthentication?logout=true\" : \"/adfAuthentication?login=true\"}

ユーザーがリンクをクリックすると、ADF認証サーブレットのinit-paramのsuccess_urlおよびend_url設定によって宛先が決定されます。これらの設定では、ログイン後のページ・ナビゲーションに制御フロー・ルールが適用されるように、Webページ名ではなくビュー・アクティビティ名を指定する必要があります。現在のユーザーが認証されると、securityContext Beanのauthenticatedプロパティがtrueに評価され、success_urlで定義されているページに転送されます。ユーザーが認証されない場合、ログイン・ページに転送する必要はありません。ADF認証サーブレットでトリガーされるログインは、コンテナ管理セキュリティ構成によって処理されるためです。ログアウトは、セッションを無効にするADF認証サーブレットによって処理されることに注意してください。

6. 「リンク」コンポーネントのリンク・コンポーネント・イメージを指定するには、「プロパティ」ウィンドウで、「アイコン」フィールドにEL式を入力します。

たとえば、次のEL式は条件に応じて、ユーザーが認証されない場合にリンク・コンポーネント・イメージをロックのGIFとしてレンダリングします。それ以外の場合は、キーのGIFでイメージをレンダリングします。

#{securityContext.authenticated ? '/images/lock.gif' : '/images/key.gif'}

図47-18に、ログイン・リンク・コンポーネントをグローバル・メニュー・ファセットに追加するとどのように表示されるかを示します。

図47-18 ページのログイン・リンク・コンポーネント

47.7.2 明示的な認証用のログイン・ページを作成する方法

「ADFセキュリティの構成」ウィザードを実行して生成されるデフォルトのログイン・フォームは、JDeveloperでアプリケーションをテストする際に利用できるように提供されます。デフォルトのフォームでは、アプリケーションのユーザー・インタフェースに合せて、ADF Facesコンポーネントを使用してページをカスタマイズすることはできません。図47-19に示すように、カスタマイズ可能なコンポーネントを組み込めるADF Facesベースのログイン・ページによって、デフォルトのフォームを置き換えることができます。

図47-19 ログイン・ページ

ただし、ADF Facesコンポーネントを含むログイン・ページの設計が要件でない場合は、単純なJSPまたはHTMLのログイン・ページを使用することもできます。ADFセキュリティの構成ウィザードの実行時に単純なログイン・ページを生成する方法の詳細は、「ADFセキュリティを有効化する方法」を参照してください。

47.7.2.1 バッキングBeanのログイン・コードの作成

ADF Facesページとしてログイン・ページを作成する前に、ログインの試行を処理するマネージドBeanを作成する必要があります。このログインBeanの例では、Servlet 3.0固有のAPIを使用し、プログラムによって認証が処理されます。ログインBeanは、doLogin()メソッドによって、ログイン・リンクから開始されたログイン・アクションを処理します。ログインが成功すると、このメソッドはサーブレットAPIを起動してランディング・ページにリダイレクトします。このBeanをadfc-config.xmlファイルに追加し、requestスコープで登録します。

注意:

この項で説明するこのバッキングBeanの例では、Oracle Single Sign-On (Oracle SSO)による認証は行われません。このバッキングBeanは、Servlet 3.0によって提供されるログインおよびログアウト・メソッドを使用して認証を処理しています。Servlet 3.0は、Java EE 6以降をサポートするアプリケーション・サーバー上のプログラムによるログインを汎用的にサポートしています。

始める前に:

ログイン・ページの知識があると役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。

次のタスクを完了する必要があります。

- 「ADFセキュリティの構成」ウィザードを実行し、ADF認証と認可を有効化します。

ログインのためのバッキングBeanを作成して登録する手順:

1. 「アプリケーション」ウィンドウで、バッキングBeanを作成するプロジェクトを右クリックし、「新規」、「ギャラリから」の順にクリックします。

2. 「新規ギャラリ」で「一般」を開き、「Java」、「クラス」を選択して「OK」をクリックします。

3. 「Javaクラスの作成」ダイアログで、ログイン・ページのバッキングBeanクラス・ファイルの名前を入力し、デフォルトのオプション「スーパークラスからのコンストラクタ」と「抽象メソッドの実装」を無効にして、「OK」をクリックします。

たとえば、LoginPageName.javaのように、ログイン・ページ名に基づいてバッキングBeanの名前を付けると便利です。

4. 「アプリケーション」ウィンドウで、「アプリケーション・ソース」を開き、新しいLoginPageName.javaバッキングBeanをダブルクリックします。

5. ソース・エディタで、LoginPageName.javaファイルの宣言セクションに次のコードを追加して2つのprivateフィールドを作成します。

private String _username;
private String _password;

6. 両方のフィールドのパブリック・アクセッサを生成または作成します。

ソース・エディタを右クリックして、「アクセッサの生成」を選択すると、次のパブリック・アクセッサがファイルに追加されます。

public void setUsername(String _username) {
this._username = _username;
}

public String getUsername() {
return _username;
}

public void setPassword(String _password) {
this._password = _password;
}

public String getPassword() {
return _password;
}

7. 以下のクラスをインポートします。

javax.faces.application.FacesMessage
javax.faces.context.ExternalContext
javax.faces.context.FacesContext

javax.servlet.ServletException
javax.servlet.http.HttpServletRequest
javax.servlet.http.HttpSession

8. doLogin()メソッドをこのJavaクラスに追加して、ユーザーのログイン試行を処理します。

1 public String doLogin() {
2   FacesContext ctx = FacesContext.getCurrentInstance();

3   if (_username == null || _password == null) {
4      showError("Invalid credentials",
5                  "An incorrect username or password was specified.", null);
6   } else {
7       ExternalContext ectx = ctx.getExternalContext();
8       HttpServletRequest request = (HttpServletRequest)
9                                    ctx.getExternalContext().getRequest();
10      try {
11          request.login(_username, _password); // Servlet 3.0 login
12          _username = null;
13          _password = null;
14          HttpSession session = request.getSession();
15          session.setAttribute("success_url", "/faces" +
16                                             ctx.getViewRoot().getViewId());
17          redirect(ectx.getRequestContextPath() + "/adfAuthentication");
18      } catch (ServletException fle) {
19          showError("ServletException", "Login failed.
20             Please verify the username and password and try again.", null);
21      }
22  }
23  return null;
24 }

doLogin()メソッドは、次のタスクを実行します。

行2および行6-9は、ExternalContextからのHTTPリクエストをカプセル化するオブジェクトを取得します。

行3-5は、資格証明が指定されていない場合のエラーを処理します。showError()メソッドは、ログイン・プロセスに関する多様な問題を処理するために実装するメソッドです。

行11-13は、Servlet 3.0 API login()メソッドを使用して、リクエストを発行するユーザーのログインを試行します。このプログラムによるログイン例は、Servlet APIに依存しており、Oracle Single Sign-On (Oracle SSO)はサポートされていません。

行14-16は、HTTPセッションを作成し、ADF認証サーブレット・パラメータsuccess_urlをセッションの属性として設定します。セッションにsuccess_urlを設定すると、宛先ページURLが悪意のアルリダイレクトの影響を受けるリクエスト・パラメーターとして渡されないことが保証されます。この例では、宛先ページはFacesコンテキストから取得された現在のページです。

注意: ADFセキュリティ・ウィザードを実行し、このウィザードを使用してログイン・フォームを作成した場合は、ログイン成功時にログイン・ページに戻るのではなく、セッションを保護されているターゲット・ページにリダイレクトする必要があります。この場合、15行目と16行目のsession.setAttributeで属性としてsuccess_urlおよび宛先ページのフル・パス(たとえば、/faces/protectedPage)を取得します。

行17はメソッドredirect()をコールします。このメソッドは、ADF認証サーブレットが行15で設定されているHTTPセッションから取得するURLにユーザーを転送するためにこの項で後から実装します。

行18-21はServletExceptionを処理します。これは、ログインにかかわる多様な問題によってスローされます。たとえば、資格証明が正しくない場合、ロックされたアカウントにログインを試行した場合、または期限切れパスワードを使用した場合に例外が生成されます。showError()メソッドは、ログイン・プロセスに関する多様な問題を処理するために実装するメソッドです。

行23はnullを返して、ADFコントローラが制御フロー・ケースを試行しないようにします。

9. メソッドredirect()およびshowError()のスタブを作成します。

10. アクションを含むredirect()メソッドを追加します。

1  private void redirect(String forwardUrl) {
2    FacesContext ctx = FacesContext.getCurrentInstance();
3    ExternalContext ectx = ctx.getExternalContext();
4    try {
5      ectx.redirect(forwardUrl);
6    } catch (IOException ie) {
7        showError("IOException", "An error occurred during redirecting.
8                        Please consult logs for more information.", ie);
9    }
10 }

redirect()メソッドは、次のタスクを実行します。

行2はADF Faces ctxを取得します。これはレスポンスを特定のURIに転送します。

行3-5はctxを使用して現在のHTTPレスポンスをURLにリダイレクトします。

行6 - 8はIOExceptionを処理します。これがスローされるのは、リクエストを読み取ることができないとき、またはレスポンスを書き込むことができないときです。

11. showError()メソッドを実装します。

private void showError(String errType, String message, Exception e){
FacesMessage msg =
new FacesMessage(FacesMessage.SEVERITY_ERROR, errType, message);
FacesContext.getCurrentInstance().addMessage("d2:it35", msg);
if (e != null) {
e.printStackTrace();
}
}

このshowError()メソッドは、サマリー・エラー・メッセージをFacesContextに追加し、例外のフル・スタック・トレースをコンソールに出力します。

12. 必要に応じて、タスク・フローのメソッド・コール・アクティビティからプログラムによるログアウトをトリガーする場合は、logoff()メソッドのスタブを作成し、次のように実装します。

public String logoff() {
FacesContext ctx = FacesContext.getCurrentInstance();
ExternalContext ectx = ctx.getExternalContext();
HttpServletRequest httpRequest = (HttpServletRequest) ectx.getRequest();
try {
httpRequest.logout(); // Servlet 3.0 logout
HttpSession session = httpRequest.getSession(false);
if (session != null) {
session.invalidate();
}
String logoutUrl = ectx.getRequestContextPath() + "/faces" +
ctx.getViewRoot().getViewId();
redirect(logoutUrl);
} catch (ServletException e) {
showError("ServletException", "An error occurred during logout.
Please consult logs for more information.", e);
}
return null;
}

このlogoff()メソッドは、Servlet 3.0 APIのlogout()メソッドを使用してログオフ・アクションを処理します。

13. Javaファイルを保存します。

14. 「アプリケーション」ウィンドウで、WEB-INFを開き、adfc-config.xmlをダブルクリックします。

15. エディタ・ウィンドウで、「概要」タブをクリックします。

16. 概要エディタで、「マネージドBean」ナビゲーション・タブをクリックします。

17. 「マネージドBean」ページの「マネージドBean」セクションで、「追加」アイコンをクリックして、Bean名と完全修飾クラス名を入力し、スコープrequestを選択します。

たとえば、クラス名は図47-20のoracle.summit.bean.LoginBeanのようになります。

図47-20 adfc-config.xmlファイルに登録されたログインBean

18. すべてを保存します。

47.7.2.2 明示的な認証用のADF Facesベースのログイン・ページの作成

ADF Facesレイアウト・コンポーネントおよびADF Facesユーザー・インタフェース・コンポーネントを利用する単純なログイン・ページには、2つの入力フィールドと1つのボタンが含まれます。これらのUIコンポーネントのプロパティを、ログイン・ページのマネージドBeanに定義したログイン・ハンドラ・メソッドにバインドする必要があります。

この手順で作成できるページでは暗黙的な認証はサポートされないことに注意してください。暗黙的な認証を実装する場合には、コンテナ管理の認証をサポートする、デフォルトのウィザードにより生成されたログイン・フォームをカスタマイズできます。Java EEコンテナでは、ユーザーにより送信されたj_usernameおよびj_password入力を処理するためにj_security_checkメカニズムに依存するフォームを使用します。ここで説明する明示的な認証シナリオでは、Java EEコンテナ管理の認証は使用しません。

始める前に:

明示的認証について理解しておくと役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。

次のタスクを完了する必要があります。

- 「バッキングBeanのログイン・コードの作成」の説明に従って、ユーザーのログイン試行を処理するマネージドBeanを作成します。

明示的な認証用のADF Facesベースのログイン・ページを作成するには:

1. 「アプリケーション」ウィンドウで、ログイン・ページを作成するプロジェクトを右クリックし、「新規」、「新規ギャラリ」の順にクリックします。

2. 「新規ギャラリ」で「Web層」を開き、「JSF」、「ページ」の順に選択し、「OK」をクリックします。

3. 「JSFページの作成」ダイアログで、「JSP XML」を選択します。

4. 「ファイル名」フィールドで、ログイン・ページの名前を指定します。たとえば、LoginPage.jspxを入力します。
他のオプションは選択しません。また、マネージドBeanでUIコンポーネントを公開するオプションは選択しないでください。ログイン・ページのために作成したマネージドBeanにコンポーネントを手動でバインドします。

5. 「OK」をクリックします。

6. ページを保存します。

7. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「レイアウト」パネルから「パネル・ボックス」をドラッグし、「構造」ウィンドウの「af:form」ノードの下にドロップします。

8. 「プロパティ」ウィンドウで、「テキスト」、「水平」、「幅」、「高さ」フィールドに値を入力します。
たとえば、基本的なログイン・ページを作成するには、次のように入力します。

「テキスト」にLogin Informationを設定します。

「アイコン」に/images/key_ena.pngを設定します。

「幅」および「高さ」に300および200ピクセルを設定します。

9. 「コンポーネント」ウィンドウから「パネル・フォーム・レイアウト」をドラッグして、「構造」ウィンドウの「af:panelBox」ノードの下にドロップします(図47-21)。

図47-21 パネル・フォーム・レイアウトのログイン・ページ構造

10. 「共通コンポーネント」ウィンドウから、ユーザー名フィールド用に「入力テキスト」をドラッグして「パネル・フォーム・レイアウト」ノードにドロップし、パスワード・フィールド用にもう1つの「入力テキスト」をドラッグ・アンド・ドロップします。

11. 入力フィールドの「プロパティ」ウィンドウで、「ラベル」フィールドにUsernameとPasswordを入力し、「動作」セクションを開き、両方のフィールドの「必須」ドロップダウン・リストから「true」を選択します。

12. 「プロパティ」ウィンドウで、パスワード・フィールド用に、「外観」セクションを開き、「機密」ドロップダウン・リストから「true」を選択します。

13. 2つの入力フィールドの値を処理するために、各フィールドで次の手順を実行します。

a. 「構造」ウィンドウで、入力フィールドの1つを選択し(たとえば「af:inputText - Username」ノードを選択)、「プロパティ」ウィンドウで「値」フィールドの横にある「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。

b. 「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、Beanのハンドラ・メソッドに対応する式の値を選択します。
たとえば、「構造」ウィンドウでusername入力フィールドを選択した場合は、図47-22のように「式ビルダー」ダイアログでusernameを選択します。

図47-22 「式ビルダー」ダイアログでのusernameの選択

c. 「OK」をクリックします。
「プロパティ」ウィンドウに表示される式により、ログイン・ページのために作成したマネージドBeanにフィールドがバインドされます。たとえば、username入力フィールドの場合、式は#{loginPageBean.username}のようになります(図47-23)。

図47-23 「プロパティ」ウィンドウでのusernameの値

14. 「コンポーネント」ウィンドウで、「レイアウト」パネルから「パネル枠線レイアウト」をドラッグして、af:panelBoxノードのfooterノードの内側にドロップします(図47-24)。

図47-24 ログイン・ページ構造とパネル枠線レイアウト

15. JSP/HTMLビジュアル・エディタで、ラベルが「端」、「上」および「下」のパネル枠線レイアウト・ファセットを削除します。「開始」ファセットのみを残します。

16. 「構造」ウィンドウで、「パネル枠線レイアウト」ファセットを開いて、「開始」ノードを選択し、「コンポーネント」ウィンドウから「ボタン」をドラッグ・アンド・ドロップします。

17. 「プロパティ」ウィンドウで、ボタン・コンポーネントの「テキスト」フィールドにLoginを入力します。

18. ログイン・ボタンのアクションを処理するには、次の手順を実行します。

a. 「構造」ウィンドウで「開始」ノードにある「af:button」を選択し、「プロパティ」ウィンドウで「アクション」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。

b. 「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、ログイン・メソッドに対応する式の値を選択します。
たとえば、ログインBeanにdoLogin()という名前のメソッドを作成した場合は、「式ビルダー」ダイアログでdoLoginを選択します。

c. 「OK」をクリックします。
「プロパティ」ウィンドウに表示される式により、ログイン・ページのために作成したマネージドBeanにボタンがバインドされます。たとえば、ログイン・ボタンの場合、式は#{loginPageBean.doLogin}のようになります(図47-25)。

図47-25 「プロパティ」ウィンドウでのログインのアクション

19. ページを保存します。

47.7.2.3 ログイン・ページのパブリック化の確認

アプリケーションはADFセキュリティによって保護されるため、デフォルトでは、バインド・タスク・フローに定義されたすべてのWebページ、およびADFページ定義によって定義されたすべてのWebページにはアクセスできません。すべてのユーザーがログオンできるようにする必要があるため、ログイン・ページは公開する必要があります。このため、ログイン・ページにはデータバインド・コンポーネントを追加しないでください。ログイン・ページでデータバインド・コンポーネントが使用されないかぎり、このページにはデフォルトでアクセスできます。

コンテナがページ(この場合は認証ページ)へのアクセスを許可する前に、定義済の認証ポイントに常にリダイレクトすることを保証するには、これ以上の手順は必要ありません。

47.7.3 カスタム・ログイン・ページのリソースを明示的な認証時にアクセス可能にする方法

「ADFセキュリティの構成」ウィザードを実行して、「ADF認証」オプションを選択したとき(ADF認可を有効にしない)、アプリケーションがカスタム・ログイン・ページまたはカスタム・エラー・ページを使用していると、場合によってはADFセキュリティでweb.xmlファイルに追加されたデフォルトのJava EEセキュリティ制約を編集する必要があります。次の例に示すように、allPagesセキュリティ制約に定義されるデフォルトのURLパターン(/*)は、Java EEアプリケーション・ルートの下位項目すべてに対応し、ログイン・ページに使用される各リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)もこれに含まれます。

<security-constraint>
<web-resource-collection>
<web-resource-name>allPages</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>valid-users</role-name>
</auth-constraint>
</security-constraint>

作成するページがリソース(イメージ、CSSファイルまたはJavaScriptライブラリなど)を使用する場合、web.xmlファイルのデフォルトのallPagesセキュリティ制約により、そのようなリソースが実行時にロードされなくなります。アプリケーションでそれらのリソースを表示するためには、リソースを独自のフォルダに保存し、そのリソース・フォルダがURLパターンに含まれないようにallPagesセキュリティ制約を編集する必要があります。

「ADFセキュリティの構成」ウィザードを実行して、「ADF認証および認可」オプション(デフォルト)を選択した場合は、このようなリソースの問題が生じないことに注意してください。特に、この場合にデフォルトで生成される制約がADF認証サーブレットに対応し、制約(/adfAuthentication)によってすべてのリソース・ファイルが除外されます。

47.7.4 パブリックなようこそページの作成方法

Webアプリケーションは通常は保護されているため、認証されていないユーザーのための開始地点すなわちホームページが必要になります。このようなパブリックなようこそページを作成するには、アプリケーション内の他のページへのリンクを含み、アプリケーションの開始地点として機能するADF Facesページを作成します。ただし、認証されていないユーザーに対してはパブリック・ページへのリンクしかレンダリングできません。反対に、セキュア・ページへのリンクをレンダリングするのは、ユーザーがログインし、ターゲット・ページを表示する適切な権限を持っている場合のみです。

ベスト・プラクティス

ユーザーが[Ctrl]を押しながら[N]を押すか[Ctrl]を押しながら[T]を押して、新しいブラウザ・ウィンドウまたはタブを開いたとき、アプリケーションのweb.xmlファイルにようこそページが定義されていないと、ブラウザに403エラーまたは404エラーが表示されます。このエラーを防ぐためには、ようこそページの定義をアプリケーションのweb.xmlファイルに指定する必要があります。この定義は、「ADFセキュリティの構成」ウィザードを実行して作成できます。このウィザードの実行方法の詳細は、「ADFセキュリティを有効化する方法」を参照してください。

47.7.4.1 ようこそページのパブリック化の確認

標準のADF Facesページを作成すると、ページはデフォルトでパブリックになり、認証されていないユーザーがアクセスできます。ただし、ようこそページをADFリソースに関連付けた場合(「データ・コントロール」パネルを使用してデータバインドADF Facesコンポーネントをようこそページにドラッグ・アンド・ドロップするなど)、ADFセキュリティによってデフォルトでページが保護されます。セキュリティ・ポリシーの概要エディタを使用して、提供されているanonymous-roleにADFリソースのview権限を付与すると、任意のADFリソースを公開できます。anonymous-roleの詳細は、「ADFリソースの公開時の処理」を参照してください。

47.7.4.2 ログイン・リンクおよびログアウト・リンクの追加

ログイン・リンクやログアウト・リンクをパブリックのようこそページに追加して、ログインやアプリケーション使用中のログアウトをユーザーが明示的に行えるようにします。Java EEコンテナ管理セキュリティでは、保護されているリソースにアクセスする際に認証の概念がサポートされますが、ログアウトした後も保護されたアプリケーションにとどまる標準の方法はありません。ただし、一般的なWebアプリケーションの場合、ページがパブリックであれば、ユーザーは同じページにとどまります。あるいは、ページが保護されている場合はようこそページが再び表示されます。各ページにログイン・リンクとログアウト・リンクを追加すると、ユーザーがアプリケーション内の任意の場所でログイン・セッションを終了できます(ようこそページに戻る)。また、ようこそページにこれらのリンクがあると、ユーザーがアプリケーションを開始するときに明示的に認証されます。

たとえば、3つのコンポーネント(出力テキスト領域、イメージ、ログイン/ログアウト・リンク)を含むADF Facesパネル・グループを作成できます。適切なログイン・リンクまたはログアウト・リンクをレンダリングするために、ユーザーの認証ステータスを評価するEL式を使用できます。特に、securityContext.authenticatedを使用すると、次の例に示すようにADFセキュリティ・コンテキストにアクセスできます。この式はtrueまたはfalseとして評価され、この例では、結果によって、表示するログイン・イメージまたはログアウト・イメージとリンクが決まります。次の例に示すように、リンクはセキュリティBeanのlogonおよびlogoffメソッドをトリガーします。

<af:panelGroupLayout inlineStyle="width:100%; height:15px;" id="ptpgl3">
<af:spacer width="7" height="10" id="pts2"/>
<af:outputText value="Welcome #{securityContext.userName}!"
inlineStyle="font-weight:bold; width:100px" id="ptot2"
rendered="#{securityContext.authenticated}"/>
<af:image source="#{securityContext.authenticated ? '/images/lock.gif' : '/images/key.gif'}"
id="pti2" inlineStyle="width:16px; height:16px;" shortDesc="switchable icon"/>
<af:link text="Logon" id="l1" action="#{securityBean.logon}"
rendered="#{!securityContext.authenticated}"/>
<af:link text="Logoff" id="l2" action="#{securityBean.logoff}"
rendered="#{securityContext.authenticated}"/>
<f:facet name="separator">
<af:spacer width="5" height="10" id="pts1"/>
</f:facet>
</af:panelGroupLayout>

logonおよびlogoffメソッドを実装するセキュリティBeanでは、ADF AuthenticationService APIを使用してアプリケーションを悪意のあるリダイレクトから保護できます。これにより、web.xmlファイルにsuccess_urlおよびend_urlパラメータをnullとしてホワイトリスト登録してADF認証サーブレットを起動する場合と同じレベルの保護が実現されますが、これはタスク・フローによるナビゲーションの処理に代わるベスト・プラクティスとみなされます。リダイレクトの詳細は、「認証後にユーザーをリダイレクトする方法」を参照してください。

ページ内にリンクを直接レンダリングするかわりに、「明示的な認証用にログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法」で説明するように、ログイン・リンクとログアウト・リンクを含むログイン・リンク・コンポーネントを作成して、ページ・テンプレートに追加できます。

47.7.4.3 セキュアなページへのリンクの非表示化

セキュリティ保護されたページに無名ユーザーがアクセスできないように、ようこそページ上のセキュリティ保護されたページをポイントするナビゲーション・コンポーネントを、次の2つの基準に基づいてビューから非表示にする必要があります。

- ユーザーが既知のユーザー・アイデンティティで認証されているか

- 指定されたユーザー・アイデンティティがターゲットの表示権限を持っているか

これらの条件の一方が満たされない場合、パブリック・ページ上でセキュリティ保護されたリソースをポイントするすべてのナビゲーション・コンポーネントは、そのrendered属性をfalseに設定して、無名ユーザーに対して非表示にする必要があります。ようこそページでこのような規則を施行するには、「ADFセキュリティでの式言語(EL)の使用」を参照してください。

47.7.5 認証後にユーザーをリダイレクトする方法

暗黙的な認証を実装することを選択した場合は、ユーザーが保護されたWebページにアクセスしてログインした後、ADF認証サーブレットは、ログイン・リクエストが発行された最初のページにユーザーをリダイレクトします。ADFセキュリティ認証が有効な場合、ADFは、ADF認証のsuccess_urlパラメータとして元のページをセッション・マップで自動的に渡します。通常、これは必要な動作です。

また、暗黙の認証を実装することを選択した場合、web.xmlファイル内でsuccess_urlパラメータをinit-param要素として指定することにより、Fusion Webアプリケーションを悪意のあるリダイレクトから保護できます。ただし、ADF認証サーブレットによって元のページがsuccess_urlパラメータとして自動的に渡され、web.xmlの設定よりも優先されるため、web.xmlのinit-param設定が有効になるのは、ユーザーがadfAuthentication URLをブラウザに明示的に入力する場合のみです。

一方、明示的な認証を実装し、ページに明示的なログイン・リンクを表示することを選択した場合、ADFセキュリティ・フレームワークは元のページを判別できません。この場合、ログイン・リンクは、認証後、目的のページへのリダイレクトがADF認証サーブレットによって確実に行われるように、次の例に示すように、Webページのビュー・アクティビティ名をサーブレットのsuccess_urlパラメータとして渡します。

<af:link text="Login" destination="/adfAuthentication?success_url=/faces/viewactivityname"/>

ベスト・プラクティス

明示的な認証で、Fusion WebアプリケーションがADF認証リダイレクトをADFコントローラのナビゲーション・イベントとして処理するようにするには、リダイレクト・ターゲットをビュー・アクティビティ名で指定します。リダイレクト・ターゲットとしてビュー・アクティビティを指定しない場合、特にaf:buttonコンポーネントなどのコマンド・コンポーネントは、ログイン後に必ず元のページに戻ることになります。リダイレクト・ターゲットを表すADF認証サーブレットのパラメータsuccess_urlおよびend_urlとしてビュー・アクティビティ名を渡すことで、アプリケーションではすべての場合において、制御フロー・ルールを使用してナビゲーションが処理されるようになります。

明示的な認証では、タスク・フロー・ビュー・アクティビティ名でsuccess_urlを定義するベスト・プラクティスに従うと、ユーザーがブラウザに入力を試みるadfAuthentication URLをADF認証サーブレットが無視するようにすることで、Fusion Webアプリケーションが悪意のアルリダイレクトから保護されます。または、タスク・フロー・アクティビティが不便な場合は、アプリケーションでAuthenticationService APIを使用して、リダイレクトを安全な方法で処理するログインおよびログアウト・メソッドを実装できます。セキュリティBeanでAPIを使用する方法の詳細は、「異なるホスト・サーバーへのリダイレクトに関する必知事項」を参照してください。

ユーザーが認証されたが、Webページの表示を認可されない場合は、ADF認証サーブレットをアプリケーションのエラー・ページにリダイレクトできます。タスク・フローを使用しない設計のアプリケーションを作成した場合を除いて、Fusion Webアプリケーションのエラー処理は、ADFコントローラの例外ハンドラで制御されます。たとえば、ADFページ定義で保護された、トップレベルのようこそページと1つのブラウズ・ページを含むバインドなしタスク・フローを定義した場合、次の例に示すようにアプリケーションのエラー・ページ(adfc-config.xmlファイルに指定されたauthorizationErrorPage.jspx)が表示されます。

<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
<exception-handler>authorizationErrorPage</exception-handler>
<view id="welcomePage">
<page>/welcomePage.jspx</page>
</view>
<view id="browse">
<page>/browse.jspx</page>
</view>
<view id="authorizationErrorPage">
<page>/authorizationErrorPage.jspx</page>
</view>
<control-flow-rule>
<from-activity-id>welcomePage</from-activity-id>
<control-flow-case>
<from-outcome>goToSecuredPage</from-outcome>
<to-activity-id>browse</to-activity-id>
</control-flow-case>
</control-flow-rule>
</adfc-config>

ADFコントローラ例外ハンドラのビュー・アクティビティとしてエラー・ページを指定する方法の詳細は、「タスク・フローでの例外の処理」を参照してください。

ユーザーが認証されず、認可の失敗が発生した場合は、フレームワークがADF認証サーブレットにリダイレクトし、ADF認証サーブレットがログインを求めるJava EE制約をトリガーします。この場合、コンテナ管理セキュリティは、web.xmlファイルの<login-config>要素に指定されているログイン・ページとエラー・ページを利用します。

タスク・フローを使用せずにFusion Webアプリケーションを作成する場合、次の例に示すようにADFバインディング・フィルタのための<init-param>設定をweb.xmlに指定できます。アプリケーションにタスク・フローがないこのケースでは、ページ認可チェックがADFバインディング・フィルタによって処理され、unauthorizedErrorPageパラメータがADFバインディング・リクエスト・ハンドラに渡されます。

注意:

unauthorizedErrorPageパラメータの機能は、ADFコントローラが使用できない以前のリリースとの互換性のために用意されています。Fusion Webアプリケーションでは、ユーザーをエラー・ページにリダイレクトする必要があるときは、前述の例のようにタスク・フロー例外ハンドラを使用してエラー・ページを指定します。

<filter>
<filter-name>adfBindings</filter-name>
<filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class>
<init-param>
<param-name>unauthorizedErrorPage</param-name>
<param-value>faces/authorizationErrorPage.jspx</param-value>
</init-param>
</filter>

47.7.6 暗黙的な認証用のカスタム・ログイン・ページをトリガーする方法

ユーザーが保護対象のリソースにアクセスできるように(直接URLアクセスまたはADFセキュリティの保護対象リソースへの移動により)暗黙的な認証を実装することを選択すると、ADFセキュリティ認証サーブレットがJava EEコンテナを開始し、web.xmlファイルで構成されているログイン・フォームを表示します。暗黙的な認証では、ADF Facesコンポーネントを使用するようにデフォルトのウィザードにより生成されたログイン・フォームをカスタマイズしている場合は、ADF Facesサーブレットを参照するようにサーブレット・マッピングに対するURLパターンを変更する必要があります。

「ADFセキュリティの構成」ウィザードの「認証タイプ」ページでこのように設定できます。あるいは、web.xmlファイルで直接行うことができます。すでに「ADFセキュリティの構成」ウィザードを実行している場合は、次の手順に従って、説明したようにweb.xmlファイルが更新されていることを確認できます。

明示的な認証を実装することを選択し、ユーザーが保護対象のリソースにアクセスするためにログインできるようにパブリック・ページを作成した場合は、作成するログイン・フォームはADFセキュリティによりトリガーされません。明示的な認証シナリオでは、web.xmlファイルを構成する必要はありません。

注意:

「明示的な認証用のADF Facesベースのログイン・ページの作成」で説明しているとおりに、アプリケーションで明示的な認証をプログラム的に実装する際にログイン・ページ・アプリケーション・パスでweb.xmlファイルを構成すると、予期しない結果が発生し、ログインが失敗することがあります。web.xmlファイルは、暗黙的な認証を実装しており、デフォルトのウィザードにより生成されたログイン・フォームのようにj_security_checkアクションに依存するフォームを作成した場合にのみ変更してください。

始める前に:

ログイン・ページの知識があると役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。

暗黙的な認証用のADF Facesログイン・ページを参照するには:

1. 「アプリケーション」ウィンドウで、WEB-INFを開き、web.xmlをダブルクリックします。

2. web.xmlファイルの概要エディタで、「セキュリティ」ナビゲーション・タブをクリックします。

3. 「セキュリティ」ページで「ログイン認証」セクションを開き、ADF Facesサーブレットへの参照を含むようにログイン・ページを設定します。こうすることで、ログイン・ページがADF Facesライフサイクル/faces/ADFlogin.jspxページの一部になります。

ファイル・ブラウザを使用してページを追加すると、web.xmlファイルに入力されるパスに/facesが指定されません。ADF Facesサーブレットのサーブレット・マッピング・パスを参照するようにパスのエントリを変更します。たとえば、マッピングで指定されるURLパターンが/faces/*の場合、パスを/faces/yourpage.jspxとする必要があります(図47-26)。

図47-26 ログイン構成でのFacesサーブレットに対する参照の追加

47.7.7 リダイレクト宛先ページを確実に使用可能にする方法

ADF認証サーブレットはユーザーにログインを求めるときに、success_urlで定義されているリダイレクト宛先をセッション・マップに配置します。ただし、ユーザーが認証される前にセッションがタイムアウトした場合、セッション・マップはsuccess_urlの値を失い、アプリケーションは宛先ページに移動できなくなります。

ログイン・リダイレクト宛先をアプリケーションが確実に常に使用できるようにするには、success_urlパラメータをタスク・フローのナビゲーション結果ルールとして定義するか、ADFセキュリティの構成ウィザードを実行するときにweb.xmlファイルに追加される、ホワイトリスト登録された1つのページとして静的に定義します。

web.xmlファイルはデプロイメント前に定義する必要があるため、Fusion Webアプリケーションでは、接続参照値の定義を伴うリダイレクトURLのsuccess_urlパラメータを構成する別の動的なアプローチがサポートされています。これらの値は、connections.xmlファイルで直接構成することもできます。

connections.xmlファイルをADF認証サーブレットのリダイレクト宛先の永続ストアとして使用する手順は次のとおりです。

1. 次の例に示すように、web.xmlファイルで、oracle.adf.share.security.authentication.connectionsという名前のinit-paramをADF認証サーブレットの定義に追加し、adf/META-INFフォルダにあるconnections.xmlファイルに出現する接続参照名としてparam_valueを指定します。

<servlet>
<servlet-name>adfAuthentication</servlet-name>
<servlet-class>
oracle.adf.share.security.authentication.AuthenticationServlet
</servlet-class>
<init-param>
<param-name>
oracle.adf.share.security.authentication.connections
</param-name>
<param-value>my_connection_name</param-value>
</init-param>
...
</servlet>

2. 次の例に示すように、connections.xmlファイルで、success_urlを定義し、必要に応じてend_urlを名前付き接続参照内で定義します。

<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="my_connection_name"
className=
"oracle.adf.share.security.authentication.AuthenticationConnection"
xmlns="">
<Factory className=
"oracle.adf.share.security.authentication.AuthenticationConnection"/>
<RefAddresses>
<StringRefAddr addrType="success_url">
<Contents>
http://localhost:port/context_root/faces/welcomePage</Contents>
</StringRefAddr>
<!-- end_url for logout -->
<StringRefAddr addrType="end_url">
<Contents>
http://localhost:port/context_root/faces/publicPage</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>
</References>

アプリケーションを現在のリクエスト・ホスト、ポートおよびコンテキスト・ルートにリダイレクトする場合は、宛先URLでホスト名、ポート番号およびコンテキスト・ルートを省略できます。この場合、URLは/faces/pagenameとして指定され、/facesはADF Facesのコンテキストでページをロードし、ADF Facesコンポーネントを使用するように設計されたページをサポートします。

実行時にリダイレクトURLがセッション・マップ上にない場合、ADF認証サーブレットはoracle.adf.share.security.authentication.connectionsという名前のinit-paramから接続名を取得してconnections.xmlファイルから接続を参照します。名前付きの接続がない場合、またはsuccess_url (ログイン)やend_url (ログアウト)がconnections.xmlにない場合は、success_urlまたはend_urlがweb.xmlに定義されていないかどうかADF認証サーブレットによってチェックされます。

47.7.8 異なるホスト・サーバーへのリダイレクトに関する必知事項

ログアウト時に、Fusion Webアプリケーションの開始サーバーとは異なる任意のWebページまたはホスト・サーバーにユーザーをリダイレクトすることが必要な場合があります。このシナリオでは、宛先ページのURLがリクエスト時にアプリケーションによって配置されないようにすることで、アプリケーションを悪意のあるリダイレクトから保護する必要があり、かわりにセッション・マップを使用します。これを実現するために、次の例に示すように、サーブレットのinit-param要素disable_url_paramをtrueに設定してweb.xmlファイルのADF認証サーブレット定義に追加することで、ADFリダイレクト・パラメータがブラウザURLで渡されないようにすることをお薦めします。

<servlet>
<servlet-name>adfAuthentication</servlet-name>
<servlet-class>
oracle.adf.share.security.authentication.AuthenticationServlet
</servlet-class>
<init-param>
<param-name>success_url</param-name>
<param-value>faces/welcome</param-value>
</init-param>
<init-param>
<param-name>end_url</param-name>
<param-value>faces/welcome</param-value>
</init-param>
<init-param>
<param-name>disable_url_param</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
...

セッション・マップでリダイレクト・パラメータを渡すこと(そうしなければブラウザURLリクエストでパラメータが公開される)をADFによって強制される前に構築されたレガシー・アプリケーションでは、disable_url_paramをtrueに設定せず、かわりにターゲットの宛先をセッション・マップに配置することで、ADFインタフェースoracle.adf.share.security.AuthenticationServiceを使用してADF固有のログインおよびログアウト・メソッドを処理するセキュリティBeanを実装することを検討してください。

次の例は、AuthenticationServiceインタフェースのlogout()メソッドの使用方法を示しています。このメソッドは、渡されたURLをセッション・マップに内部的に挿入し、ユーザーによってURLに明示的に設定される可能性のあるend_urlパラメータを無視します。同様にlogin()メソッドはセッション・マップにログインURLの宛先を配置します。異なるサーバー上のWebページにリダイレクトするためにログアウトが必要な場合、メソッド実装では、目的のWebページのURLを渡し、悪意のあるリダイレクトから引き続き保護できます。

import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import oracle.adf.share.security.AuthenticationService;
import oracle.adf.share.security.authentication.AuthenticationServiceUtil;

public class SecurityBean {
public SecurityBean() {
super();
}

public boolean isAuthenticated() {
ExternalContext ectx =
FacesContext.getCurrentInstance().getExternalContext();
return ectx.getUserPrincipal() != null;
}

public void logon() {
if (!isAuthenticated())
{
FacesContext ctx = FacesContext.getCurrentInstance();
AuthenticationServiceUtil.getAuthenticationService().login("/faces" +
ctx.getViewRoot().getViewId(), null, null);
}
}

public void logoff() {
if (isAuthenticated())
{
AuthenticationServiceUtil.getAuthenticationService().
logout("/faces/index", null);
}
}
}

プログラムによるアプローチの代替では、null値のsuccess_urlおよびend_urlパラメータを持つ明示的なリンクでADF認証サーブレットを呼び出すことで、セッション・マップへの宛先URLの配置を処理します。この場合、ADF認証サーブレットは、web.xmlファイル(またはconnections.xmlファイル)からリダイレクト値を取得しようとし、ユーザーがURLに入力しようとする値を無視します。このアプローチでは、success_urlおよびend_urlパラメータにinit-param要素を指定することで、web.xmlにADF認証サーブレット定義を構成する必要があります。その結果、これはログインおよびログアウト・リダイレクトに単一の宛先があるホワイトリストを生成する宣言的なアプローチになります。

47.7.9 Fusion Webアプリケーション・ログアウトおよびブラウザ・キャッシュに関する必知事項

Fusion Webアプリケーションのweb.xmlファイルの指定に基づいてBasic認証が有効な場合、ブラウザは認証資格証明をキャッシュします。これは、ADF認証サーブレットによるログアウト・リダイレクトの実行後に、Basic認証によってユーザーを再認証する場合の既知の問題です。このシナリオでは、ログアウト・セッションを完了し、ユーザーによるリソースへのアクセスを防ぐために、ブラウザを終了し、新しいブラウザ・セッションを再開する必要があります。

ADFアプリケーションがログアウトを完了し、ユーザーがログアウト後にリソースにアクセスできないようにするには、基本認証ではなくフォームベースの認証を使用します。「ADFセキュリティを有効化する方法」で説明するように、ADFセキュリティの構成ウィザードを実行してフォームベース認証を選択できます。

47.7.10 IBM WebSphere Application Serverに関する必知事項

アプリケーションをIBM WebSphereアプリケーション・サーバーにデプロイし、同じマシンを使用してWebSphere管理コンソールにログインすると、アプリケーションにログインしたユーザーの名前ではなく管理コンソールにログインしたユーザーの名前がアプリケーションによって表示されます。通常は、認証されたユーザーをテストする式(#{securityContext.authenticated ? securityContext.userName : ""}など)によって、アプリケーションにログインしたユーザーの名前が表示される必要があります。ただし、Mozilla Firefoxでアプリケーションが実行されているときは、管理ユーザーの名前がIBM WebSphereアプリケーション・サーバーに表示されます。セッションIDが同一マシンのすべてのブラウザで共有されるためです。この動作は、Oracle WebLogic Serverで実行するときや、アプリケーションをMicrosoft Internet Explorerで実行するときには発生しません。

47.7.11 Internet Explorerでのエラー・ページの表示に関する必知事項

ADFセキュリティを有効化してカスタム・エラー・ページを表示する場合、ページ表示のリクエストに応じてアプリケーションがHTTPエラーを生成すると、エラー・ページが表示されます。ただし、特定のバージョンのInternet Explorerでは、ブラウザに、カスタム・エラー・ページか、Internet Explorerに組み込まれているエラー・メッセージのどちらかが表示されます。Internet Explorerにエラー・メッセージのみが表示される場合は、「インターネット オプション」ダイアログの「詳細設定」で、エラー・メッセージ番号を表示するオプションを無効にできます。Internet Explorer 10では、このオプションはデフォルトで有効になっています。「ADFセキュリティの構成」ウィザードで有効化したカスタム・エラー・メッセージを表示するには、「HTTPエラーメッセージを簡易表示する」を無効にする必要があります。

Internet Explorer 10でカスタム・エラー・メッセージを表示するには:

1. Internet Explorerのツールバーで、「ツール」ボタンをクリックします。

2. 「インターネット オプション」ダイアログで、「詳細設定」タブをクリックします。

3. 「詳細設定」タブで、スクロールして「HTTPエラーメッセージを簡易表示する」を探します。

4. このオプションをクリックして無効化し、「OK」をクリックします。

47.8 JDeveloperにおけるセキュリティのテスト

統合WebLogic Serverにより、アプリケーションを直接JDeveloper内部で実行して、アプリケーションで定義するアプリケーション・ポリシー、ユーザーおよび資格証明などのセキュリティ・オブジェクトを移行するかどうかを決定できます。デフォルトでは、アプリケーションを実行するたびにすべてのセキュリティ・オブジェクトが統合WebLogic Serverに移行されます。

47.8.1 セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法

JDeveloperはデフォルトで、アプリケーションを実行するたびにアプリケーション・リポジトリから統合WebLogic Serverにセキュリティ・オブジェクトをデプロイするよう構成されています。この動作は、「アプリケーション・プロパティ」ダイアログでのセキュリティ・デプロイメント・オプションの選択により、次のように変更できます。

- ドメインレベル・ポリシーをアプリケーションのjazn-data.xmlファイル内のポリシーにより上書きするかどうかを決定します。

- システム資格証明をアプリケーションのcwallet.ssoファイルにより上書きするかどうかを決定します。
cwallet.ssoファイル(JDeveloperの「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノード)には、安全に保持されるオブジェクトとして資格証明が格納されます。この資格証明はアイデンティティと照合するために認証プロバイダに渡されます。このファイルは暗号化されているため、JDeveloper内では参照も編集もできません。設計時に各種コンポーネントでcwallet.ssoファイルを使用し、そのファイル内に必要な資格証明を作成します。

- jazn-data.xmlファイルのアイデンティティ・ストアの一部をドメインレベル・アイデンティティ・ストアに移行するかどうかを決定します。

デプロイ設定を変更しない場合、アプリケーションを実行するたびに、JDeveloperはドメイン・レベルのセキュリティ・ポリシーおよびシステム資格証明を上書きします。また、テスト目的で作成した新しいユーザー・アイデンティティを移行し、統合WebLogic Serverがそのアイデンティティ・ストアで使用する埋込みLDAPサーバー内の既存のユーザー・パスワードを更新します。しかし、統合WebLogic Server内の既存のセキュリティ・オブジェクトを更新せずにアプリケーションを実行する場合には、このオプションを選択できます。

始める前に:

統合WebLogic Serverについて理解しておくと役立ちます。詳細は、「JDeveloperにおけるセキュリティのテスト」を参照してください。

セキュリティ・デプロイメントを構成し、JDeveloperでアプリケーションを実行するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「セキュリティ・デプロイメントの構成」を選択します。

2. 「アプリケーション・プロパティ」ダイアログの「デプロイメント」ページの「セキュリティ・デプロイメント・オプション」セクションで、統合WebLogic Serverにデプロイするセキュリティ・オブジェクトを選択します。

デフォルトでは、アプリケーションを実行するたびに、JDeveloperによって、ドメイン・レベルのアプリケーション・ポリシーとシステム資格証明がアプリケーションのアプリケーション・ポリシーとシステム資格証明で上書きされます。これらリポジトリのいずれかを上書きしない場合は、「アプリケーション・ポリシー」または「資格証明」を選択解除します。選択解除した場合、JDeveloperでは新しいポリシーまたは資格証明のみがドメインレベル・ストアにマージされます。

デフォルトでは、アプリケーションを実行するたびに、テスト目的で作成する新規ユーザーのアイデンティティがJDeveloperによって移行され、統合WebLogic Serverでアイデンティティ・ストア用に使用される埋込みLDAPサーバーにある既存のユーザー・パスワードが更新されます。「ユーザーとグループ」を選択解除して、アプリケーションのアイデンティティ・ストアの移行を無効にできます。

3. 「OK」をクリックします。

4. 「アプリケーション」ウィンドウで、保護されたWebページが含まれるユーザー・インタフェース・プロジェクトを右クリックし、「実行」を選択します。

ユーザー・インタフェース・プロジェクトで「実行」を選択すると、JDeveloperでは、プロジェクトについて構成済のデフォルト実行ターゲットを使用してアプリケーションが実行されます。たとえば、実行ターゲットとしてタスク・フロー・アクティビティを構成して、アプリケーションを起動できます。デフォルトの実行ターゲットを構成するには、「タスク・フローのテスト」を参照してください。

アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

47.8.2 セキュリティ・デプロイメント・オプション構成時の処理

統合WebLogic Serverを使用してアプリケーションを実行するとき、JDeveloperは、「アプリケーション・プロパティ」ダイアログに指定したセキュリティ・デプロイメント構成設定に基づいて、セキュリティ・ポリシーと資格証明をドメイン・レベルに移行します。デプロイメント・プロセスで、JDeveloperは、次の例に示すように、「アプリケーション・プロパティ」の設定に基づいてデプロイメント・アーカイブ・ファイルに追加するweblogic-application.xmlファイルを更新します。これらの設定はアプリケーション・ソース・ディレクトリのweblogic-application.xmlファイルには追加されないため、表示されないことに注意してください。

<application-param>
<param-name>jps.credstore.migration</param-name>
<param-value>OVERWRITE</param-value>
</application-param>
<application-param>
<param-name>jps.policystore.migration</param-name>
<param-value>OVERWRITE</param-value>
</application-param>

OVERWRITE値を指定すると、アプリケーションのセキュリティ・ポリシーと資格証明を変更して、開発モードで実行しているOracle WebLogic Server、または統合WebLogic Server(デフォルトで開発モードで実行するように設定されている)にどちらも再デプロイすることができます。

注意:

いずれ本番環境にデプロイする際には、weblogic-application.xmlファイルの移行設定は無視されます。既存のポリシーと資格証明を上書きできるため、これはセキュリティの脆弱性とみなされます。本番環境へのデプロイの詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。

また、次の例に示すように、JDeveloperはweblogic-application.xmlファイルをOPSSライフサイクル・リスナーでも更新します。アプリケーションが実行する前に移行プロセスを開始するために、ライフサイクル・リスナーはポリシーと資格証明について移行設定を確認し、ドメイン・レベルでセキュリティ・オブジェクトを上書きします。

<listener>
<listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</listener-class>
</listener>
<listener>
<listener-class>
oracle.security.jps.wls.listeners.JpsAppVersionLifecycleListener
</listener-class>
</listener>

移行プロセスで、JDeveloperはOracle Platform Security Services (OPSS)アプリケーション・ロール・メンバー・クラスを統合WebLogic Serverメンバー・クラスにマッピングし、ユーザーをWebLogic Serverアイデンティティ・ストアusersに移行し、ロールをWebLogic Serverアイデンティティ・ストア・グループに移行します。Oracle WebLogic Serverでは、usersはOPSSのauthenticated-roleと同等の暗黙のグループです。

アイデンティティ・ストアの移行は、weblogic-application.xmlファイルのアプリケーション・ライフサイクル・リスナー設定では制御されません。かわりに、統合WebLogic Serverで実行するとき、またはJDeveloperからデプロイするときは、Oracle WebLogic Mbeanによってアイデンティティの移行が処理されます。ユーザーがすでに存在している場合、Mbeanはユーザー定義全体を移行しません。ユーザーのパスワードだけを更新します。

47.8.3 組込みtest-allアプリケーション・ロールを使用する方法

「ADFセキュリティの構成」ウィザードを実行すると、jazn-data.xmlファイルのポリシー・ストアにtest-allアプリケーション・ロールを追加するオプションを有効にできます。このオプションを有効にするときは、アプリケーションのアプリケーション・ロールへの権限付与のスコープも指定します。

- JDeveloperでtest-allアプリケーション・ロールにview権限を付与し、ウィザードの実行時にユーザー・インタフェース・プロジェクトに表示されるADFタスク・フローとWebページすべてにこのポリシーを適用するには、「既存のオブジェクトのみに付与」を選択します。

- JDeveloperでtest-allアプリケーション・ロールにview権限を付与し、開発者がユーザー・インタフェース・プロジェクトで作成した既存のADFタスク・フローとWebページ、および今後ユーザー・インタフェース・プロジェクトで作成するすべてのADFタスク・フローとWebページにこのポリシーを適用するには、「すべてのオブジェクトに付与」を選択します。「すべてのオブジェクトに付与」オプションを選択してウィザードを初めて実行した後は、ウィザードによりオプション「新規オブジェクトに付与」が表示されます。

ウィザードの実行後、jazn-data.xmlファイルにtest-allロールが表示され、セキュリティ・ポリシーの概要エディタにこのロールが表示されます。test-allロールにテスト・ユーザーを移入する必要はありません。ウィザードによって、組込みアプリケーション・ロールanonymous-roleがtest-allロールに割り当てられるためです。この場合、すべてのユーザーは自動的にanonymous-roleプリンシパルを保持し、アプリケーションへのアクセスを許可されます。

注意:

アプリケーションをデプロイする前に、「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」の説明に従って、ポリシー・ストアからすべてのtest-allロールを削除する必要があります。これにより、未認可のユーザーはアプリケーションのWebページにアクセスできなくなります。

いつでもウィザードを再実行して、自動付与を無効にすることができます。いったん無効になると、新たに作成するADFタスク・フローとWebページはtest-allロールを利用しないため、「ADFセキュリティ・ポリシーの定義」で説明するように明示的な付与を定義する必要があります。

47.8.4 実行時に行われる処理: ADFセキュリティによる認証の処理

統合WebLogic Serverを使用してJDeveloperでアプリケーションをテストするとき、アイデンティティ・ストアが、Oracle Internet Directoryに格納されている情報と一緒に埋込みLDAPサーバーに移行されます。

図47-27に、ユーザーがあらかじめログインせずに、ADFバインド・タスク・フローまたはADFバインディングを含むWebページ(mypage.jspxなど)にアクセスを試行するときの認証プロセスを示します。ユーザーがパブリック・ページのログイン・リンクをクリックしてログインを開始するのではないため、認証は暗黙的に開始されます。セキュリティ保護されたページの場合、無名ユーザーに対して権限付与は行われません。

図47-27 ADFセキュリティの暗黙的認証

図47-27の暗黙的な認証プロセスでは、リソースがanonymous-roleに対する権限を持たず、ユーザーがまだ認証されていず、認証メソッドがフォームベース認証であると想定しています。この場合、処理は次のようになります。

1. バインド・タスクフローまたはWebページ(ADFバインディングを含む)がリクエストされると、ADFバインディング・サーブレット・フィルタがADF認証サーブレットにリクエストをリダイレクトし(図のステップ1)、ログインをトリガーした論理操作を格納します。

2. ADF認証サーブレットにはJava EEセキュリティ制約が設定されているため、Java EEコンテナによって構成済のログイン・メカニズムが起動されます(図のステップ2)。コンテナのログイン構成に基づいて、ユーザーは次のように認証を求められます。

a. フォームベース認証の場合は、適切なログイン・フォームが表示されます(図のステップ2a)。

b. ユーザーは、表示されるログイン・フォームに自分の資格証明を入力します(図のステップ2b)。

c. ユーザーは、コンテナのj_security_check()メソッドにフォームをポストします(図のステップ2c)。

d. Java EEコンテナは、構成済のプラガブル認証モジュールを使用してユーザーを認証します(図のステップ2d)。

3. 認証が成功すると、コンテナは認証チャレンジを開始したサーブレット(この場合はADF認証サーブレット)にユーザーをリダイレクトします(図のステップ3)。

4. ADF認証サーブレットに戻ると、最初にリクエストされたリソースにリダイレクトされます(図のステップ4)。
「実行時に行われる処理: ADFセキュリティによる認可の処理」で説明するように、リソースが表示されるかどうかは、ユーザーのアクセス権と、ADFセキュリティのための認可が施行されているかどうかに依存します。

図47-28は、パブリック・ページの「ログイン」リンクから開始するプロセスで、ユーザーが認証される場合の明示的認証処理を示しています。

図47-28 ADFセキュリティの明示的認証

明示的認証のシナリオでは、(anonymousユーザー・プリンシパルとanonymous-roleプリンシパルのみを持つ)認証されていないユーザーが、パブリック・ページの「ログイン」リンクをクリックします(図のステップ1)。「ログイン」リンクは、web.xmlファイルのJava EEセキュリティ制約を介してセキュリティ保護されているADF認証サーブレットへのダイレクト・リクエストです。

このシナリオでは、現在のページがパラメータとしてADF認証サーブレットに渡されます。暗黙的認証のケースと同じく、セキュリティ制約によってユーザーがログイン・ページにリダイレクトされます(図のステップ2)。暗黙的認証ケースのステップa - ステップdで説明したようにコンテナがユーザーを認証すると、リクエストがADF認証サーブレットに戻されます(図のステップ3)。その後、サーブレットによってユーザーがパブリック・ページに戻されますが、その時点では新しいユーザーおよびロール・プリンシパルが配置されています。

47.8.5 実行時に行われる処理: ADFセキュリティによる認可の処理

ADF認可が有効になってるとき、ADFバインド・タスク・フローとタスク・フロー外部のWebページ(ADFページ定義がある)はデフォルトで保護されます。ユーザーがこれらのWebページにアクセスしようとすると、ADFセキュリティが、ポリシー・ストアでそのユーザーがアクセス権を付与されているかどうか、確認して判定します。ユーザーがまだ認証されていず、anonymous-roleに対してページが許可されていない場合、ログイン・ページまたはフォームが表示されます。認証されたユーザーでも権限がない場合は、セキュリティ・エラーが表示されます。ポリシー・ストアに適切な権限を構成していない場合、ページは保護された状態に維持され、したがって認証されたユーザーも利用できません。

図47-29は、認可プロセスを示しています。

図47-29 ADFセキュリティの認可

このユーザーは、ポリシー・ストアに定義されたアプリケーション・ロールstaffのメンバーです。ユーザーがまだログインしていないため、セキュリティ・コンテキストにはサブジェクト(ユーザーを表すコンテナ・オブジェクト)がありません。そのかわりに、Oracle Platform Security Servicesにより、ADFセキュリティに対して、anonymousユーザー・プリンシパル(ユーザーの一意の定義)とanonymous-roleプリンシパルを持つサブジェクトが提供されます。

anonymous-roleプリンシパルを使用すると、通常、ユーザーはADFリソースで定義されないページのみ(public.jspページなど)にアクセスできます。これに対して、ADFタスク・フローで定義されたページまたはADFページ定義ファイルを使用するタスク・フロー外部のページはすべてデフォルトで保護され、ユーザーはアクセスできません。このセキュリティ・ポリシーの例外は、ポリシー・ストアでADFリソースに対するanonymous-roleアクセスを付与する場合です。この場合、ユーザーはADFリソースによって定義されたページにすぐにアクセスすることはできません。

(ADFページ定義などで指定されている)mypage.jspxなど、ADFリソースによって定義されたWebページにユーザーがアクセスしようとすると、ADFセキュリティ施行ロジックがそのリクエストを遮断し、また、すべてのADFリソースがデフォルトでセキュリティ保護されているため、ユーザーは自動的に認証を要求されます(anonymous-roleがADFリソースへのアクセスを付与されていないと想定)。

認証が正常に終了すると、ユーザーは特定のサブジェクトを取得します。ここでセキュリティ施行ロジックがポリシー・ストアをチェックして、mypage.jspxの表示を許可されるロールと、ユーザーがそのロールのメンバーかどうかを判別します。mypage.jspxのこの例ではview権限がスタッフ・ロールに付与されています。ユーザーはそのロールのメンバーであるため、mypage.jspxにナビゲートできます。

同様の方法で、ADFリソースにより定義されている別のページsecpage.jspにユーザーがアクセスしようとすると、ユーザーはこのページで必要なview権限を持たないため、アクセスが拒否されます。

ユーザーおよびロールは、リソース・プロバイダのアイデンティティ・ストアですでに定義されているものです。アプリケーション・ロールは、jazn-data.xmlのポリシー・ストアで定義されています。

47.9 セキュア・アプリケーションのデプロイの準備

統合WebLogic Serverを使用したJDeveloperでのテストの後は、アプリケーションをスタンドアロン・サーバーにデプロイすることができます。最初は、ターゲットのサーバーはステージング環境です。本番環境にデプロイする前に、このサーバーのアイデンティティ・ストアを使用して開発のテストを続行できます。つまり、通常は作成したテスト・ユーザーを統合WebLogic Serverで実行するために移行しません。資格証明(cwallet.ssoファイル内)とセキュリティ・ポリシー(jazn-data.xmlファイル内)をスタンドアロンOracle WebLogic Serverに移行するために実行するステップは、ターゲット・サーバーで構成されているモードと、デプロイにJDeveloperまたはJDeveloper外部ツールのどちらを使用するかによって異なります。

注意:

JDeveloperからデプロイメント環境へのデプロイの詳細は、「Fusion Webアプリケーションのデプロイ」を参照してください。

ターゲット・サーバーが開発モードで構成されているときは、JDeveloperから直接デプロイできます。この場合、JDeveloperが、デプロイメント・プロセスの一環としてポリシー・ストア、システム資格証明およびアイデンティティ・ストア(ユーザーおよびグループ)の移行を自動的に処理します。アプリケーション・セキュリティ・デプロイメント・プロパティでは、デプロイメント・プロセスがドメインレベルのポリシー・ストアとシステム資格証明を上書きできるようにデフォルトで構成されています。さらに、アイデンティティ・ストア・デプロイメント・プロパティは、テスト・ユーザーを含むアイデンティティ・ストアを移行するようにデフォルトで構成されています。「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、このデフォルトのデプロイメント動作を「アプリケーション・プロパティ」ダイアログで変更できます。

注意:

開発モードで実行するOracle WebLogic Serverへのシステム資格証明の移行が実行されるのは、ターゲット・サーバーが資格証明の上書きを許可するように構成されている場合だけです。システム資格証明の上書きをサポートするためにOracle WebLogic Serverを構成する方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」を参照してください。

ターゲット・サーバーが本番モードで構成されているとき、通常は、JDeveloper外部でOracle Enterprise Managerなどのツールを使用して移行タスクを処理します。JDeveloper外部のツールを使用してポリシー・ストアを本番環境のドメインレベルに移行する方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」を参照してください。本番モードで実行するOracle WebLogic Serverでは、どのような状況でもシステム資格証明の上書きはサポートされないことに注意してください。

「ADFセキュリティの構成」ウィザードで自動付与機能を有効にした場合は、アプリケーションをデプロイする前にtest-allアプリケーション・ロールを削除することをお薦めします。test-allロールによってすべてのADFリソースが公開されるため、このロールが存在していると、アプリケーションのリソースが保護されない状態になるリスクが高まります。したがって、アプリケーションレベルのポリシー・ストアを移行する前にこのロールを削除する必要があります。

さらに、アプリケーションのOracle WebLogic Serverへのデプロイを準備するとき、jazn-data.xmlファイルに作成したテスト・アイデンティティを削除することもお薦めします。こうしておくと、セキュリティ・ポリシーをテストするために作成したユーザーが、ドメインレベルのアイデンティティ・ストアに移行されません。

ベスト・プラクティス

アプリケーションをスタンドアロン環境にデプロイする場合は、すでにOracle WebLogic Serverに対して構成しているローカル・アイデンティティ・ストアのユーザーおよびエンタープライズ・ロールを移行してはいけません。たとえば、ユーザーweblogicとエンタープライズ・ロールAdministratorsを含むアイデンティティ・ストアをデプロイする場合は、ターゲット・サーバーのデフォルト管理構成を上書きします。競合の可能性をすべて排除するには、「アプリケーション・アイデンティティ・ストアからテスト・ユーザーを削除する方法」で説明するように、アイデンティティ・ストアの移行を無効にすることができます。

47.9.1 アプリケーション・ポリシー・ストアからtest-allロールを削除する方法

セキュリティ・ポリシーの概要エディタには、ADFセキュリティの組込みtest-allロールに対するview権限を持つすべてのリソースを表示する機能があります。概要エディタのこの機能を使用して、test-allロールの権限を削除し、アプリケーションで定義するロールの権限で置き換えることができます。

または、jazn-data.xmlファイルの概要エディタを使用してtest-allロールを削除できます。エディタの「アプリケーション・ロール」ページでtest-allロールを選択して、「アプリケーション・ロールの削除」ボタンをクリックします。ただし、この方法でtest-allロールを削除しても、削除するロールのかわりの権限を作成する必要があります。概要エディタではこれらのタスク両方を一緒に行うことができるため、次の手順で使用方法を説明します。

始める前に:

Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。

test-allアプリケーション・ロールを削除し、カスタム・アプリケーション・ロールで置き換えるには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択し、「test-allのみが付与されたタスク・フローを示します」チェック・ボックスを選択して、この組込みロールに対する権限を含むタスク・フローのリストを表示します。

test-allロールに対する権限が存在しない場合、概要エディタの「リソース」リストには何も表示されません。test-allロールが定義されるのは、「ADFセキュリティの構成」ウィザードで有効にした場合のみです。有効になっている場合、test-allの権限を含むそれらのタスク・フローが図47-30のように表示されます。

図47-30 概要エディタでのtest-all権限付きタスク・フローの表示

3. 「リソース」列でリストの最初のタスク・フローを選択します。

4. 「付与先」列でtest-allを選択し、「権限受領者の削除」アイコンをクリックします。

5. 「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。その後、「アプリケーション・ロールの選択」ダイアログを使用して必要なロールを追加します。

6. これらのステップを繰り返し、残りのすべてのタスク・フローでtest-allロールを削除して、独自のアプリケーション・ロールで置き換えます。

7. 概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択し、手順を繰り返して、すべてのWebページとそのADFページ定義についてtest-allロールを削除します。

8. 「test-allのみが付与されたタスク・フローを示します」/「test-allのみが付与されたWebページを示します」チェックボックスが選択された状態で、概要エディタにtest-all権限付きのリソースが表示されていないことを確認します。

47.9.2 アプリケーション・アイデンティティ・ストアからテスト・ユーザーを削除する方法

デプロイ先のスタンドアロンOracle WebLogic Serverでは、構成済の独自のアイデンティティ・ストアが用意されます。JDeveloperで作成したテスト・ユーザーとエンタープライズ・ロール・グループをドメイン・レベルに移行しないようにするには、jazn-data.xmlファイルからテスト・ユーザー・レルムを削除する必要があります。

または、JDeveloperからデプロイする場合は、「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、「アプリケーション・プロパティ」ダイアログで「ユーザーとグループ」オプションを選択解除して、ユーザーとグループの移行を無効にすることができます。

始める前に:

Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。

アイデンティティ・ストアからテスト・ユーザーとエンタープライズ・ロール・グループを削除するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「ユーザー」を選択します。

2. jazn-data.xmlファイルのエディタ・ウィンドウで「ソース」タブをクリックします。

3. jazn-data.xmlファイルのソースで<jazn-realm>要素の横の「-」アイコンをクリックすると、図47-31のように要素全体が折りたたまれます。

図47-31 XMLエディタでの<jazn-realm>要素の選択

4. この要素が選択された状態で[Delete]を押し、ファイルを保存します。

47.9.3 URL制約を使用してリソース・ファイルをセキュリティ保護する方法

リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)とは、アプリケーションの個々のページをサポートするためにFusion Webアプリケーションがロードするファイルです。これらのファイルは、ADFセキュリティによって保護されません。アプリケーションのWebページをセキュリティ保護する場合、これらのファイルをセキュリティ保護することは必須ではありませんが、アプリケーションを十分にセキュリティ強化するために、リソース・ファイルを保護したほうが好ましい場合もあります。JavaScriptファイルはブラウザにダウンロードされるため、このときに読取り可能となることに注意してください。

リソース・ファイルを提供するため、ADF Facesフレームワークではorg.apache.myfaces.trinidad.webapp.ResourceServletを使用し、これによってリソース・ローダーに処理が委譲されます。Fusion Webアプリケーションのweb.xmlファイルには、リソース・サーブレットとURLパターンを対応付けるサーブレット・マッピングが含まれます。JDeveloperは、デフォルトで/adf/*(MyFaces Trinidad Coreの場合)および/afr/*(ADF Facesの場合)パターンを使用します。

リソース・サーブレットはADFセキュリティによって保護されないため、リソース・サーブレット用のJava EEアクセス・パスを、セキュリティ制約を使用して保護できます。リソース・ファイルに対する独自のセキュリティをweb.xmlファイル内に実装するには、/adflib/*、/adf/*および/afr/*パスに対するセキュリティ制約を定義して、これらに特定のセキュリティ・ロールを割り当てます。このセキュリティ制約により、すべてのユーザーは、Fusion Webアプリケーションの最初のページにアクセスする前に認証を受けることになります。

次の例は、セキュリティ・ロールresource_roleと、このロールにマッピングされたURLパターンによる制約を示しています。セキュリティ・ロールを定義した後は、ターゲット・サーバーの管理者によってこのロールをOracle WebLogic Serverエンタープライズ・ロール(ユーザー・グループ)にマッピングしてもらうか、または同名のエンタープライズ・ロールを作成してもらう(この場合はマッピングは不要)必要があります。

<security-role>
<description>Java EE role to map to an enterprise role. All users who will
be allowed to run Fusion web app must be members of that role.     </description>
<role-name>resource_role</role-name>
</security-role>

<security-constraint>
<web-resource-collection>
<web-resource-name>resources</web-resource-name>
<url-pattern>/adflib/*</url-pattern>
<url-pattern>/adf/*</url-pattern>
<url-pattern>/afr/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>resource_role</role-name>
</auth-constraint>
</security-constraint>

47.10 ADFセキュリティの無効化

アプリケーション・ポリシー・ストアに対する認可チェックを一時的に実行せずにアプリケーションを実行する必要がある場合、JDeveloperではADFセキュリティを無効にできます。こうすると、既存のセキュリティ・ポリシーで提供される保護なしで、アプリケーションを実行し、すべてのリソースにアクセスできます。

47.10.1 ADFセキュリティを無効化する方法

アプリケーションのレベルでADFセキュリティを無効にするには、ウィザードを実行して次のオプションの1つを選択します。

- 「ADF認証」を選択すると、ADF認可が無効になりますが、ADF認証サーブレットは有効なままです。たとえば、一時的に無効化されたセキュリティ・ポリシーに対して認可チェックを施行してアプリケーションをJDeveloperで実行する必要があるとします。このオプションでは、Java EEアプリケーション・ルート「/」を、ユーザー認証をトリガーするallPagesJava EEセキュリティ制約にマップすることで、ユーザーがアプリケーションのページに最初にアクセスしたときにログインを要求します。認可チェックが施行されないため、ADFリソースはセキュリティ対応になりません。したがって、一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。

- 「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効になり、ADFリソースの認可チェックも無効になります。この場合、ユーザー認証とADFリソースのセキュリティがない状態でアプリケーションを実行できます。

どちらのオプションもADFセキュリティを再有効化する目的でいつでも選択できます。このウィザードでは特に、アプリケーション開発者がADFリソースに対して定義したセキュリティ・ポリシーを含む、アプリケーションのポリシー・ストアは変更されません。このため、いつでもウィザードに戻り、「ADF認証および認可」オプションを選択し、アプリケーションの既存のポリシー・ストアやアイデンティティ・ストアに対してADFセキュリティを再有効化できます。

始める前に:

ADFセキュリティの無効化について理解しておくと役立ちます。詳細は、「ADFセキュリティの無効化」を参照してください。

ADF認可チェックを無効にするには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「ADFセキュリティの構成」を選択します。

2. 「ADFセキュリティ」ページで「ADF認証」オプションまたはADFセキュリティ構成の無効化オプションを選択します。「次へ」をクリックします。

これらのオプションのいずれかを設定してウィザードを実行すると、ユーザー・インタフェース・プロジェクトのADFリソースはセキュリティ対応でなくなります。

3. 「終了」をクリックします。

47.10.2 ADFセキュリティを無効にしたときの処理

「ADFセキュリティ構成の削除」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、web.xmlファイルとadf-config.xmlファイルからADF固有のメタデータ(表47-2)が削除されます。

同様に、「ADF認証」オプションを選択してウィザードを実行し、認可チェックのみを無効にすると、次の更新が実行されます。

- web.xmlファイルでADF固有のメタデータは変更されず、allPagesセキュリティ制約が追加されます。
allPagesセキュリティ制約が存在する場合、ユーザーはアプリケーションに最初にアクセスしたときに認証を行うことになります。

- 次の例に示すようにadf-config.xmlファイルの<JaasSecurityContext>要素のauthorizationEnforceパラメータがfalseに設定されます。

<JaasSecurityContext
initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory"
jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
authorizationEnforce="false"
authenticationRequire="true"/>

adf-config.xmlファイルは、ワークスペースの/.adf/META_INFフォルダにあります。JDeveloperでは、このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで「ディスクリプタ」→「ADF META-INF」ノードを開くと見つかります。JDeveloperの外部でエディタを使用してadf-config.xmlファイルを表示する場合、ウィザードによって適用されたファイル内の変更を確認するにはワークスペースを保存する必要があります。

47.11 高度なトピックとベスト・プラクティス

ADFセキュリティの有効化プロセスを完了した後、ユーザー・インタフェースにおいてADFセキュリティと連動するようにアプリケーションをカスタマイズすることができます。たとえば、式言語(EL)を使用し、一連のUIコンポーネントのためだけに定義したカスタム権限の評価に基づいて、UIコンポーネントをWebページにレンダリングできます。さらに、マネージドBean内にメソッドを定義して、アプリケーションの情報(ユーザー名やロール・メンバーシップなど)を公開できます。

47.11.1 ADFセキュリティでの式言語(EL)の使用

式言語(EL)を使用するとUIのポリシーを直接評価できますが、Javaを使用するとマネージドBean内でポリシーを評価できます。ADFセキュリティでは、セキュリティ・コンテキストでADFリソースにアクセスするように、EL式で使用できる便利なメソッドがいくつか実装されています。たとえば、EL式とADFセキュリティ・コンテキストAPIのメソッドを使用して、ユーザーが特定のタスク・フローにアクセスできるかどうかを判定できます。優れたセキュリティは、ユーザーがアクセス権を持たないリソースや機能をアプリケーションが非表示にすることを求めます。この理由から、ユーザーが特定のタスク・フローへのアクセスを許可されない場合、そのユーザーの権限を評価して、そのタスク・フローを開始するナビゲーション・コンポーネントをレンダリングするかどうかを判別します。

注意:

ポリシーを評価できるのは、現在のリクエストのみです。この理由から、リクエスト・スコープ外でポリシーを評価すると、予期しない結果が発生することがあるため、ポリシー評価がどこで行われるかを理解することが重要です。

47.11.1.1 ELを使用したポリシーの評価方法

UIコンポーネント内でELを使用すると、コンポーネントの属性値を動的に定義できるようになるため、実行時にUIコンポーネントを変更できます。リソースを保護する場合、対象となるUIコンポーネント属性はrendered属性です。これを使用して、ユーザーの権限に基づいてコンポーネントの表示と非表示を切り替えることができます。デフォルトでは、rendered属性はtrueに設定されています。権限に応じてこの値を動的に変更することで、UIコンポーネントの表示と非表示を設定できます。たとえば、ユーザーが適切な権限を持っている場合は、UIコンポーネントが表示されるようにrendered属性をtrueに設定する必要があります。権限を持たない場合は、属性をfalseに設定して、UIコンポーネントを非表示にする必要があります。

ELを使用してポリシーを評価するには、securityContext ELネームスペースでADFセキュリティのメソッドを使用する必要があります。これらのメソッドを使用して、特定のユーザーまたはADFリソースに関してADFセキュリティ・コンテキストの情報にアクセスできます。

表47-11に、ユーザーが関連する権限を持つかどうかを判別するために必要なEL式を示します。ユーザーが適切な権限を持っている場合、EL式はtrueに評価されます。そうでない場合はfalseを返します。

表47-11 ADFリソースに対するview権限を判定するEL式

式

式のアクション

#{securityContext.taskflowViewable['MyTaskFlow']}

次に例を示します。

#{securityContext.taskflowViewable
['/WEB-INF/audit-expense-report.xml#audit-expense-report']}

MyTaskFlowは、アクセス対象のタスク・フローのWEB-INFノード修飾名です。ユーザーがアクセス権を持つ場合はtrueを戻します。ユーザーが十分なアクセス権を持たない場合はfalseを戻します。

#{securityContext.regionViewable['MyPagePageDef']}

MyPagePageDefは、アクセス対象のWebページに関連付けられているページ定義ファイルの修飾名です。ユーザーがアクセス権を持つ場合はtrueを戻します。ユーザーが十分なアクセス権を持たない場合はfalseを戻します。

注意:

「valid-usersロールに関する必知事項」で説明したように、ページ権限の場合、マネージドBean内部の遅延バインディングELを使用することにより、ページ定義の値を動的に指定できます。

表47-12には、ADFセキュリティ・コンテキストから、ADFリソースに関連しない一般的な情報を取得するためのEL式を示します。たとえば、ユーザーの名前をユーザー・インタフェースに表示する場合は、現在のユーザー名にアクセスできます。また、現在のユーザーが特定のロールのメンバーかどうか、特定の権限を付与されているかどうかもチェックできます。アプリケーションはこの結果を使用してメニューの非表示と表示を動的に切り替えることができます。

表47-12 ADFセキュリティ・コンテキストでのユーザー情報を判定するEL式

式

式のアクション

#{securityContext.userName}

認証されたユーザーのユーザー名を戻します。

#{securityContext.authenticated}

ユーザーがログインしている場合はtrueを戻します。ユーザーがログインしていない場合はfalseを戻します。これが役立つのは、ログイン/ログアウトの動的リンクのレンダリング、またはユーザーが認証されたときの「ようこそ、username」メッセージのレンダリングです。この式を使用する例は、「ログイン・リンクおよびログアウト・リンクの追加」を参照してください。

#{securityContext.userInRole['roleList']}

roleListはロール名のカンマ区切りリストです。ユーザーが少なくとも1つのロールに含まれる場合はtrueを戻します。ユーザーがどのロールにも含まれない場合または現在認証されていない場合は、falseを戻します。

#{securityContext.userInAllRoles['roleList']}

roleListはロール名のカンマ区切りリストです。ユーザーがすべてのロールに含まれる場合はtrueを戻します。ユーザーがすべてのロールには含まれていない場合または現在認証されていない場合は、falseを戻します。

#{securityContext.userGrantedPermission['permission']}

permissionは、permissionClass=<class>;target=<artifact_name>;action=<action>のようなセミコロンで連結した要素を含む文字列です。ユーザーがアクセス権を持つ場合はtrueを戻します。ユーザーが十分なアクセス権を持たない場合はfalseを戻します。

表47-11に示された便利なメソッドtaskflowViewableおよびregionViewableにも同じ機能があります。

#{securityContext.userGrantedResource['resource']}

resourceは、resourceName=<name>;resourceType=<type>;action=<action>のようなセミコロンで連結した要素を含む文字列です。ユーザーがアクセス権を持つ場合はtrueを戻します。ユーザーが十分なアクセス権を持たない場合はfalseを戻します。

この式を使用すると、タスク・フローに含まれないリソース(「ADF Faces」パネルやメニュー項目など)の表示プロパティの権限をテストできます。最初に、保護するUIコンポーネントのカスタム・リソース・タイプを作成します。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。

始める前に:

ELの用法について理解しておくと役立ちます。詳細は、「ADFセキュリティでの式言語(EL)の使用」を参照してください。

ナビゲーション・コンポーネントのレンダリングを、ターゲット・タスク・フローまたはページ定義に対してユーザーに付与された権限に関連付ける手順:

1. 「アプリケーション」ウィンドウで、条件付きでレンダリングするナビゲーション・コンポーネントを含むページをダブルクリックします。

2. ページのビジュアル・エディタで、セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。

3. 「プロパティ」ウィンドウで、「レンダリング済」フィールドの横に表示されている「プロパティ・メニュー」ドロップダウン・メニューから、「式ビルダー」を選択します(図47-32)。

図47-32 データへのRenderedプロパティのバインディング

4. 「式ビルダー」で「ADFバインディング」の「securityContext」ノードを開いて適切なEL値を選択します。次に、「式」フィールドに、アクセスしようとしているADFリソースの修飾名を入力します。

たとえば、図47-33に示すようにアプリケーションで表示するタスク・フローへのアクセスを制限するには、次のような式を作成します。

#{securityContext.taskflowViewable
['/WEB-INF/audit-expense-report.xml#audit-expense-report']}

この例では、式によって、ターゲット・タスク・フローaudit-expense-reportを表示するためのユーザーのアクセス権が判別されます。ユーザーにアクセス権がある場合、式はtrueとして評価され、rendered属性は値trueを受け取ります。

図47-33 「式ビルダー」ダイアログでのELの定義

ヒント:

「式ビルダー」ダイアログの「説明」を開くと、選択したセキュリティELメソッドに関する追加情報を参照できます。

5. 「OK」をクリックします。

アプリケーションを実行すると、ユーザーがターゲット・ページを表示できるかどうかに基づいて、コンポーネントがレンダリングされるか、非表示になります。

47.11.1.2 「式ビルダー」ダイアログの使用時の処理

「式ビルダー」を使用してrendered属性の式を定義すると、開いている.jspxファイルのコンポーネント定義がJDeveloperによって更新されます。次の例に示すように、コンポーネントのrendered属性に、trueまたはfalseに評価される式が追加されます。この例ではコンポーネントはナビゲーション・リンクであり、リンク・テキストCheckoutは別の式で定義されます。このナビゲーション・リンクを含むページによってこのコンポーネントがレンダリングされるのは、チェックアウト・タスク・フローにアクセスするための十分なアクセス権がユーザーにある場合のみです。

<af:commandNavigationItem
text="#{res['global.nav.checkout']}"
action="globalCheckout"
id="cni3"
rendered="#{securityContext.taskflowViewable
['/WEB-INF/checkout-task-flow.xml#checkout-task-flow']}"
/>

47.11.1.3 ELの遅延評価に関する必知事項

セキュリティ権限を評価できるスコープは、リクエストに設定されています。リクエストよりも上位レベルまでスコープ設定されたマネージドBean (マネージドBeanが基礎となっているグローバル・メニューなど)からターゲット・ページにアクセスするための権限を評価する場合は、遅延EL評価(遅延バインディング)を実装する必要があります。Beanの管理プロパティとしてターゲット・ページを渡すことで、マネージドBeanが必要なバインディング情報を取得できるようになった後でEL式が評価されるようになります。ELは、ページが実行されるとすぐに評価されるため、マネージドBeanを基礎としたUIコンポーネントのプロパティ内に直接EL式を配置すると、有効範囲外エラーが発生します。

次の例は、ユーザーが特定のターゲット・ページを表示できるかどうかに基づいてtrueまたはfalseを返すマネージドBeanのプロパティ(authorized)を示しています。この場合、_targetPageDef変数は、ターゲット・ページの名前が含まれる管理プロパティです。UI内で、EL式はauthorizedプロパティを参照します。

public boolean isAuthorized()
{
if (_targetPageDef != null) {
FacesContext fctx = FacesContext.getCurrentInstance();
ADFContext adfCtx = ADFContext.getCurrent();
SecurityContext secCtx = adfCtx.getSecurityContext();
boolean hasPermission = secCtx.hasPermission(new RegionPermission
(_targetPageDef, RegionPermission.VIEW_ACTION));
if (hasPermission) {
return hasPermission;
}
else {
fctx.addMessage(null, new FacesMessage (
FacesMessage.SEVERITY_WARN, "Access Permission not defined! " , null));
return false;
}
}

47.11.2 OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法

表47-12に示したADFセキュリティのELネームスペースでのセキュリティ式によって、ページにUIコンポーネントを表示する前にユーザー権限、認証およびロール・メンバーシップ・ステータスを確認できます。タスク・フロー・セキュリティやWebページ・セキュリティの一部ではないアプリケーションの機能部分を保護するために、UIコンポーネントをきめ細かく保護する必要がある場合は、EL値userGrantedResourceと、カスタム・リソース・タイプ用に定義したリソース権限を使用します。たとえば、ユーザーがメニュー項目用に作成したリソース権限によって、アプリケーションはCancel Shipment(出荷取消し)のメニュー項目を有効化または無効化して、顧客注文更新の実行者を制限します。

カスタム・リソース・タイプのリソース権限は、ResourcePermissionクラスに依存しています。このクラスはOracle Platform Security Services (OPSS)によって提供され、アプリケーションとともにパッケージ化されています。

セキュリティ・ポリシーの概要エディタを使用して、カスタム・リソース・タイプのセキュリティ・ポリシーを作成します。またWebページでは、セキュリティ式を使用して、リソース権限によって投影されるUIコンポーネントへのユーザーのアクセス権限を評価します。

ベスト・プラクティス

カスタム・リソース・タイプとResourcePermissionマッチャ・クラスを組み合せることで、ADFセキュリティを開き、権限内で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。Webページへのアクセスを管理するために、カスタム・リソース・タイプを作成する必要はありません。このレベルのアクセスは、セキュリティ・ポリシーの概要エディタで操作できる、ADFセキュリティのデフォルトのview権限によって実現されます。

カスタム・リソース・タイプのリソース・ポリシーを許可するには:

1. 保護するUIコンポーネントのカスタム・リソース・タイプを作成します。

2. カスタム・リソースに対してリソース権限を作成します。

3. UIコンポーネントのレンダリングを、ロールに付与されるリソース権限に関連付けます。

47.11.2.1 カスタム・リソース・タイプの作成

「リソース・タイプの作成」ダイアログを使用して、保護するUIコンポーネントのリソース・タイプを作成します。JDeveloperが、リソース・タイプの定義とOPSS権限クラスoracle.security.jps.ResourcePermissionを一致させます。このクラスを使用して、タスク・フロー・セキュリティまたはWebページ・セキュリティによって保護されないアプリケーションの機能部分に権限を付与できるカスタム・アクションを指定できます。たとえば、メニューのUIコンポーネントを使用してユーザーがアクセスするアプリケーションの機密部分を保護するために、リソース・タイプを作成することがあります。

「リソース・タイプの作成」ダイアログでは、保護するリソースのタイプ(たとえば、MenuProtectionという名前はメニューのUIコンポーネントを識別する)、セキュリティ・ポリシー・ストアに表示される表示名(例: Menu Protection)、リソース権限でのリソース・タイプの使用方法の説明(例: Resource permission to grant menu item permissions)を識別できます。このダイアログでは、権限を付与するために使用する1つ以上のカスタム・アクション名を入力することもできます。たとえば、保護されたメニュー項目へのアクセス権を付与するセキュリティ・ポリシーで使用するために、processというアクション名を入力できます。

始める前に:

ADF権限クラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。

カスタム・リソース・タイプを作成する手順:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「新規リソース・タイプ」をクリックします。

3. 「リソース・タイプの作成」ダイアログで、名前と、UIコンポーネントを説明する表示名を入力します。

たとえば、メニュー項目を保護するには、名前にはMenuProtection、表示名にはMenu Protectionと入力します。

4. 「アクション」リストで「追加」をクリックし、権限を付与するアクションの名前を入力して、「OK」をクリックします。

たとえば、メニュー項目を保護する場合、processと入力することで、メニュー選択を処理する権限が付与されることを示します。特定のアクションの権限を個々のユーザーまたはロールに付与する場合は、複数のアクション名を入力できます。図47-34のように概要エディタにカスタム権限が表示されます。

図47-34 カスタム・リソース・タイプの作成

47.11.2.2 カスタム・リソース・タイプに対するリソース権限の作成

jazn-data.xmlファイルの概要エディタを使用して、カスタム・リソースのADFセキュリティ・ポリシーを作成します。完成したソースは、次の例に示すように、ポリシー・ストアで定義される権限と類似した内容となります。

<grant>
<grantee>
<principals>
<principal>
<name>AccountManagersadmin</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.ResourcePermission</class>
<name>resourceType=MenuProtection,resourceName=CancelShipment</name>
<actions>process</actions>
</permission>
</permissions>
</grant>

ターゲット名<permission>は、カスタム・リソース・タイプと、リソースを割り当てた名前を識別します。たとえば、ユーザーがアカウント内のメニュー選択から出荷を取り消すことができるリソース名は、CancelShipmentという名前になります。

アクションは、カスタム・リソース・タイプによって定義されています。たとえば、メニュー保護では、リソース・タイプによって、メニュー選択を処理する権限を付与するための単一アクションprocessが定義されます。

始める前に:

ResourcePermissionクラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。

次のタスクを完了する必要があります。

- 「カスタム・リソース・タイプの作成」の説明に従って、カスタム・リソース・タイプを作成します。

カスタム・リソース・タイプに対してリソース権限を作成する手順:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。

2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストからカスタム・リソースを選択します。

3. 「リソース」列で、「リソースの追加」アイコンをクリックします。

4. 「リソースの作成」ダイアログで、セキュリティ・ポリシーが特に保護するリソースの名前、表示名、説明を入力して、「OK」をクリックします。

5. 概要エディタの「リソース権限」ページにおいて、「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。

6. 「アクション」列で、カスタム・リソース・タイプに対して定義したアクションを選択します。

図47-35のように、概要エディタにリソース権限が表示されます。

図47-35 概要エディタでのカスタム・リソースに対する権限の作成

47.11.2.3 UIコンポーネントのレンダリングとリソース権限との関連付け

UIコンポーネントの表示プロパティに対する「式ビルダー」ダイアログを使用して、コンポーネントのレンダリングを制御するEL式を定義します。たとえば、認可ユーザーが出荷を取り消すことができるアプリケーションでメニュー項目を保護するために、アプリケーションは、af:commandMenuItemによって定義されたメニュー項目のdisabledプロパティに対して、userGrantedResource式を指定します。次の例に示すように、ユーザーにリソース・タイプに対する権限が付与されているか、その結果メニュー項目が表示されるかどうかが式によってテストされ、ユーザーにリソースに対する権限が付与されていない場合は、メニュー項目が無効化されます。

#{!securityContext.userGrantedResource
['resourceName=CancelShipment;resourceType=MenuProtection;action=process']}

図47-36は、「式ビルダー」ダイアログに式がどのように表示されるかを示します。

図47-36 「式ビルダー」ダイアログでのELの定義

始める前に:

ResourcePermissionクラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。

次のタスクを完了する必要があります。

1. 「カスタム・リソース・タイプの作成」の説明に従って、カスタム・リソース・タイプを作成します。

2. 「カスタム・リソース・タイプに対するリソース権限の作成」の説明に従って、カスタム権限を使用してADFセキュリティ・ポリシーを作成します。

UIコンポーネントのレンダリングとユーザーに付与されるリソース権限を関連付ける手順:

1. 「アプリケーション」ウィンドウで、条件付きでレンダリングするUIコンポーネントを含むページをダブルクリックします。

2. ページのビジュアル・エディタで、セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。

3. 「プロパティ」ウィンドウで、「レンダリング済」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。

4. 「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedResourceを選択します。次に、「式」フィールドに、権限を定義する連結文字列を入力します。

権限文字列は、resourceName=theResourceInstanceName;resourceType=customResourceTypeName;action=actionNameのようにセミコロンで連結した文字列として入力します。たとえば、認可ユーザーが出荷を取り消すことができるアプリケーションでメニュー項目を保護するために、次の例と同じような式を入力でき、userGrantedResourceのリソース・タイプは、カスタム・リソース権限で使用されるリソース・タイプを識別します。

#{!securityContext.userGrantedResource
['resourceName=CancelShipment;resourceType=MenuProtection;action=process']}

この例では、アプリケーション・ポリシー・ストアに追加したMenuProtectionという名前のカスタム・リソース・タイプに基づいて、権限が式によって評価されます。

5. 「OK」をクリックします。

47.11.3 エンティティ・オブジェクト操作の認可チェックの実行方法

Fusion Webアプリケーションで、エンティティ・オブジェクトの操作をセキュリティで保護する際にデータ・コレクションのセキュリティを有効にできます。ユーザーには、行セット全体のデータを表示、更新または削除するのに十分な権限が必要です。

oracle.jbo.ViewCriteriaRow APIでは、エンティティ行のレベルで標準操作(read、update、removeCurrentRow)の認可チェックを実行できます。次の例は、エンティティ行に対して認可チェックAPI、getSecurityHints()およびallowsOperation()を使用して、ユーザーにデータを削除する権限があるかどうかをテストする方法を示しています。

if(row.getSecurityHints().allowsOperation("removeCurrentRow").hasPermission())
// code for the data
else
// display error message

allowsOperation()メソッドは、保護するアクションの名前ではなく保護された操作名を入力として必要とします。エンティティ行の削除の操作名はremoveCurrentRow (deleteがアクション名)です。

Fusion WebアプリケーションのJSFページにデータ・バインドされたコンポーネントの基礎となるエンティティ・オブジェクトの認可チェックを実行する場合は、EL式を使用できます。たとえば、次のEL式は、指定された操作を実行する権限がユーザーに付与されている場合にtrueを返します。式で使用されている<operationName>は、エンティティ・オブジェクトに対して有効にしたread、updateまたはremoveCurrentRow操作である必要があります。

#{row.hints.allows.<operationName>}

認可チェック式は、行コレクションのコンテキストで評価されます。行コレクションのコンテキストの外部でエンティティ権限をチェックする場合は、表47-12に示すようにuserGrantedResourceメソッドを使用する必要があります。

47.11.4 ADFセキュリティ・コンテキストからの情報の取得

Fusion Webアプリケーション内にセキュリティを実装することは、定義上、ADFセキュリティ・フレームワークのセキュリティ・インフラストラクチャを実装することです。このため、フレームワークのセキュリティ・コンテキストを使用して、アプリケーションのポリシーやセキュリティ全体を定義するときに必要となる情報にアクセスできます。

47.11.4.1 セキュリティが有効かどうかの判定方法

ADFセキュリティの施行は、アプリケーションと無関係にコンテナ・レベルでオン/オフを切り替えることができるため、認可チェックを行う前に、ADFセキュリティが有効化されているかどうかを判断する必要があります。このためには、次の例に示すように、ADFセキュリティ・コンテキストのisAuthorizationEnabled()メソッドをコールします。

if (ADFContext.getCurrent().getSecurityContext().isAuthorizationEnabled()){
//Authorization checks are performed here.
}

47.11.4.2 ユーザーが認証済かどうかの判定方法

Fusion Webアプリケーション内のユーザー・プリンシパルがnullになることはない(つまり、認証されていないユーザーの場合はanonymousで、認証されたユーザーの場合は実際のユーザー名になる)ため、ユーザー・プリンシパルがnullかどうかを確認するだけで、そのユーザーがログオンしているかどうかを判断することはできません。このため、anonymousユーザー・プリンシパルがユーザーが認証されていないことを表すことを考慮に入れるメソッドを使用する必要があります。このためには、次の例に示すように、ADFセキュリティ・コンテキストのisAuthenticated()メソッドをコールします。

// ============ User's Authenticated Status =============
private boolean _authenticated;
public boolean isAuthenticated() {
_authenticated = ADFContext.getCurrent().getSecurityContext().isAuthenticated();
return _authenticated;
}

47.11.4.3 現在のユーザー名の判別方法

Fusion Webアプリケーションでは、セキュアでありながらすべてのユーザーに使用可能なパブリック・ページの概念をサポートしています。さらに、Webページ上のコンポーネント(ポートレットなど)では、現在のユーザー・アイデンティティの情報を必要とします。このため、Fusion Webアプリケーションのユーザー名は決してnullになることはありません。認証されていないユーザーがページにアクセスすると、ユーザー名anonymousがページ・コンポーネントに渡されます。

現在のユーザー名を判別するには、次の例に示すように、ADFセキュリティ・コンテキストのgetUserName()メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymousを返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。

// ============ Current User's Name/PrincipalName =============
public String getCurrentUser() {
_currentUser = ADFContext.getCurrent().getSecurityContext().getUserName();
return _currentUser;
}

Facesベースのアプリケーションでユーザー名を判別するための従来のメソッド(FacesContext.getCurrentInstance().getExternalContext().getRemoteUser())では、認証されていないユーザーに対してnullが戻されるため、そのメソッドを使用する場合は、パブリック・ユーザーのケースを処理する追加のロジックを使用する必要があります。

47.11.4.4 Java EEセキュリティ・ロールのメンバーシップの判別方法

Fusion WebアプリケーションはJavaServer Facesベースのアプリケーションなので、次の例に示すように、Faces外部コンテキストのisUserInRole(roleName)メソッドを使用すると、ユーザーに特定のロールが割り当てられているかどうかを判別できます。ADFセキュリティはJAASポリシーに基づくため、ロール・メンバーシップに基づくADFセキュリティ対応リソースに関連付けられたページを保護するためにJava EEセキュリティ・ロールを使用する必要はありません。ただし、ADFセキュリティ対応リソースに関連付けられていないページについては、メソッドを使用してロールをチェックできます。

この例では、便利なメソッド(checkIsUserInRole)が定義されています。マネージドBean内でこのメソッドを使用すると、名前付きロールのメンバーシップを属性として公開し、その後EL内で使用できます。

public boolean checkIsUserInRole(String roleName){
return
(FacesContext.getCurrentInstance().getExternalContext().isUserInRole(roleName));
}

public boolean isCustomer() {
return (checkIsUserInRole("Application Customer Role"));
}

47.11.4.5 Javaを使用して権限を判別する方法

Java内からセキュリティ・ポリシーを評価するには、ADFセキュリティ・コンテキストのhasPermissionメソッドを使用できます。このメソッドは、(リソースとアクションの組合せにより定義された)権限オブジェクトを取り、ユーザーに対応する権限があればtrueを返します。

次の例では、ページ名と必要なアクションを渡し、ユーザーの権限に基づいてtrueまたはfalseを返すことのできる、便利な関数が定義されています。この便利な関数がページ権限を確認するため、RegionPermissionクラスを使用して、hasPermissionメソッドに渡される権限オブジェクトを定義しています。

private boolean TestPermission (String PageName, String Action)  {
Permission p = new RegionPermission("view.pageDefs." + PageName + "PageDef",
Action);
if (p != null) {
return ADFContext.getCurrent().getSecurityContext().hasPermission(p);
}
else {
return (true);
}

バッキングBean内からターゲット・ページのユーザー権限を判別することはできないので、今度はこの便利なメソッドを使用して、Facesナビゲーション・アクションの結果を動的に変更できます。次の例では、1つのコマンド・ボタンがユーザーの権限に応じて異なるターゲット・ページを指していることがわかります。コマンド・ボタンのバッキングBeanは、最も高いレベルで保護されているページ(管理者ページ)から最も低いレベルで保護されているページ(パブリックのようこそページ)までview権限を確認することにより、適切なアクションを適用して、ユーザーに対して権限レベルに応じたページを表示します。適切なアクションを戻すバッキングBeanは、次の例に定義されている便利なメソッドを使用しています。

//Button Definition
<af:button text="Goto Your Group Home page"
binding="#{backing_content.commandButton1}"
id="commandButton1"
action="#{backing_content.getSecureNavigationAction}"/>

//Backing Bean Code
public String getSecureNavigationAction() {
String ActionName;
if (TestPermission("ManagerPage", "view"))
ActionName = "goToManagerPage";
else if (TestPermission("EmployeePage", "view"))
ActionName = "goToEmployeePage";
else
ActionName = "goToWelcomePage";
return (ActionName);
}

47.11.5 ADFセキュリティの操作のベスト・プラクティス

次に示すベスト・プラクティスは、ADFセキュリティ・フレームワークによるセキュリティ施行のための規則をまとめたものです。これらのベスト・プラクティスを理解することで、アプリケーションを保護して、意図したWebページにユーザーのアクセスを許可することができます。

アプリケーションを構築するときは最初からADFセキュリティを有効にしてください。

セキュリティを有効化すると、アプリケーションが実質的にロックダウンされます。また、作成する固有のADFセキュリティ対応リソースに対して明示的な権限付与を行う必要が生じます。アプリケーションを構築する際に、これらのリソースについて認識して、権限付与を行うことにより、反復しながらセキュリティをテストできます。こうして、必要な結果を実現するようにアプリケーションを構成できます。

バインド・タスク・フローの権限を定義してください。

バインド・タスク・フローを実行するプロセスでユーザーがアクセスするページは、ページごとの個別の権限チェックは行われず、タスク・フローの権限において実行されます。つまり、タスク・フローに追加するページには、ページ定義レベルでの独自のセキュリティは定義されていません。ユーザーがフローをリクエストする場合、アクセス・レベルに応じて、タスク・フローのすべてのページの表示を許可されるか、まったく許可されないかのどちらかになります。

バインド・タスク・フローの個々のページには権限を定義しないでください。

タスク・フローはユーザーによるページへの直接アクセスを妨げないことを理解することが重要です。公開されているディレクトリにあるすべてのWebページは、URLを使用してブラウザからアクセスできます。バインド・タスク・フローによって参照されるページに直接アクセスできないようにするため、関連するページ定義ファイルについて存在するすべての権限を削除します。バインド・タスク・フローのコンテキスト内でページに追加のセキュリティが必要な場合は、それらのページをサブタスク・フローに含めて、このネストされたタスク・フローに対する権限の定義を追加します。

エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすため、タスク・フローを使用してください。

タスク・フローを使用すると、エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすことができます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つのバインドなしタスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローの「URL起動」プロパティをurl-invoke-disallowedに設定することで、アプリケーションのアクセス・ポイントは1つのみ(バインドなしタスク・フローのページ)となります。「URL起動」プロパティの詳細は、「URLを使用したバインド・タスク・フローのコール方法」を参照してください。

未認可のユーザーに対する代替タスク・フローを指定してください。

エンド・ユーザーが、必要な権限を持たないリージョンでバインド・タスク・フローを起動しようとすると、リクエストしたタスク・フローではなく、空白にレンダリングされたリージョンが表示されます。リージョンが空白のままだと、リクエストしたタスク・フローが表示されない理由についてのフィードバックが提供されないため、エンド・ユーザーが当惑する可能性があります。このシナリオの発生時には、認可が必要でない代替タスク・フローを構成することを検討してください。代替タスク・フローの構成の詳細は、「未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理」を参照してください。

バインド・タスク・フロー外部の個々のページには権限を定義してください。

ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。ページ定義ファイルとそれがセキュリティ保護するWebページの間には1対1の関係があります。

ADFバインディングを使用しないページを保護する場合は、そのページに対して空のページ定義バインディング・ファイルを作成できます。

ユーザーのアクセス権に基づいてUIコンポーネントをレンダリングするにはカスタム権限を定義してください。

カスタムADF権限クラスを使用すると、ADFセキュリティを拡張して、権限で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。

UIコンポーネントによって表示される行レベル・データに対するユーザーのアクセス権を管理するには、エンティティ・オブジェクト属性権限を定義してください。

エンティティ・オブジェクトおよびエンティティ・オブジェクト属性は両方とも権限クラスを定義します。これを使用して、エンティティ・オブジェクトがデータ・ソースに対して開始する読取り、更新および削除操作の権限を定義できます。これらのデータ・モデル・プロジェクト・コンポーネントの場合、ADFセキュリティ認可を選択するために、アプリケーション・ロールに明示的に権限を付与する必要があります。ただし、エンティティ・オブジェクトの認可を有効にすると、そのエンティティ・オブジェクトによって定義されたすべてのデータ行は権限付与によって保護されます。このレベルの粒度では、表コンポーネントがWebページにレンダリングされるとき、ユーザーのアクセス権に応じて、すべてのデータが表示されるかデータがまったく表示されないかのどちらかになります。コレクション全体を保護するかわりに、データの個々の列を保護することができます。このレベルの粒度は、エンティティ・オブジェクトの個々の属性に設定する権限によってサポートされます。エンティティ・オブジェクトが保護されるとき、ユーザーが見ることができるのは表コンポーネントに表示されるデータの一部のみです。

view権限しかないユーザーに行レベルの作成/挿入操作を公開しないようにするには、タスク・フローまたはページレベルの権限付与を使用してください。

特定のユーザーだけが表の新しい行を更新できるページのアクセスを制御する適切な方法としては、タスク・フローまたはページレベルの権限付与を使用します。ただし、代替手段として、特定の操作に対応する表ボタンを保護することができます。これには、EL式を指定して、ボタンを表示するためのユーザーのアクセス権をテストします。カスタム権限が定義され、userGrantedPermission式がボタンのRenderedプロパティに設定されているとき、十分な権限を持つユーザーのみにボタンが表示されます。これが役立つのは、ユーザー・インタフェースに表示されるページに制限がなく、行レベルデータのview権限のみがエンティティ・オブジェクトに定義されている場合です。この場合、ユーザーが表示すると、エンティティ・オブジェクトに関連付けられた編集可能な表の「Delete」ボタンは無効な状態で表示されます。ただし、入力表の場合は、ユーザーにupdate権限がなくても、ユーザー・インタフェースによってCreateInsert操作のボタンが無効になることはありません。

JDeveloperを、ユーザー・アイデンティティのプロビジョニング・ツールとして使用しないでください。

JDeveloperはアイデンティティ・ストアのプロビジョニング・ツールとして使用しないでください。また、テスト目的で作成したユーザー・アイデンティティをアプリケーションとともにデプロイしないように注意してください。ユーザー・アイデンティティをアプリケーションとともにデプロイすると、悪質なユーザーが予想外のアクセス手段を獲得してしまう恐れがあります。かわりに、ドメインレベルのアイデンティティ管理システムによって提供されるツールを使用して、ユーザー・アイデンティティを構成する作業を、常にシステム管理者が担当します。アプリケーションをデプロイする前に、作成したすべてのユーザーおよびグループをjazn-data.xmlファイルから削除する必要があります。

ユーザーがファイル名を使用してWebページにアクセスできないようにしてください。

Fusion Webアプリケーションをデプロイするときは、ADFコントローラの構成ファイルに定義されたビュー・アクティビティからユーザーがWebページにアクセスできるように常に許可する必要があります。ユーザーがJSPXファイルの物理名(ファイル名AllDepartments.jspxなど)を使用して直接アクセスすることは許可しないでください。

ビュー・アクティビティの名前がAllDepartmentsとすると、このページをコールするには次の2つの方法があります。

1. localhost:7101/myapp/faces/AllDepartments

2. localhost:7101/myapp/faces/AllDepartments.jspx

違いは、1のコールがADFコントローラ・タスク・フローのコンテキストにあることです。つまり、ページのナビゲーションが作動し、ページで参照されるすべてのマネージドBeanが適切にインスタンス化されます。2のコールでもページが表示されますが、完全に作動しないことがあります。これはセキュリティの侵害とみなされる可能性があるためです。

JSPXファイルへの直接アクセスを防ぐには、JSPXファイルを/public_html/WEB-INFディレクトリに移動して、直接ファイル・アクセスを行えないようにします。ドキュメントにアクセスするには、ユーザーはビュー・アクティビティ名をコールする必要があります。

この方法では、ADFセキュリティで保護されていないドキュメントは保護できないことに注意してください。物理ファイルそのものへのアクセスのみがロックダウンされます。

したがって、次のセキュリティ・ガイドラインが引続き適用されます。

1. adfc-config.xmlファイルに定義されたビュー・アクティビティに関連付けられたすべてのJSPXドキュメントに、ADFセキュリティ権限を適用します。

2. ユーザー・インタフェース・プロジェクトのすべてのJSPXドキュメントを/public_html/WEB-INFディレクトリに移動して、ファイルへの直接アクセスを防ぎます。

3. adfc-config.xmlのページを最小限に制限し、他のすべてのページをバインド・タスク・フローに含めます。

4. バインド・タスク・フローに直接URLアクセスでアクセスできないようにします(新しいタスク・フローのデフォルト構成設定)。

5. バインド・タスク・フローにADFセキュリティ権限を適用します。

48 ADFコンポーネントのテストとデバッグ

この章では、Oracle ADFを使用するアプリケーションのロギングおよびテストを行うツールについて説明します。ADF宣言デバッガを使用してブレークポイントを設定するデバッグ手順も示します。最後に、ADFビジネス・コンポーネント・ベースのビジネス・サービスに対する回帰テストを記述し、実行する方法について説明します。

この章の内容は次のとおりです。

- ADFのデバッグについて

- 単純なOracle ADFコンパイル・エラーの修正

- 単純なOracle ADFランタイム・エラーの修正

- 統合WebLogic ServerのOracle ADFのメタデータのリロード

- ADFコントローラのメタデータの検証

- ADFロガーの使用

- テストとデバッグのためのOracle ADFモデル・テスターの使用

- ADF宣言デバッガの使用

- ADF宣言ブレークポイントの設定

- JavaコードとGroovyスクリプトのブレークポイントの設定

- JUnitを使用した回帰テスト

48.1 ADFのデバッグについて

WebアプリケーションとOracle Application Development Framework (Oracle ADF)との対話のデバッグは、他のデバッグ・タスクと同様に、特定の要因を切り分けするプロセスです。ただし、Webアプリケーションの場合は一般に、このプロセスでJavaソース・コードのコンパイルが行われません。このため、Webページにはコンパイル用のJavaソース・コードは含まれません。実際には、アプリケーションを実行して使用してみるまで、問題が存在しているかわからないことがあります。たとえば、次のような障害は実行時に初めて現れます。

- ページが見つからないというサーブレット・エラー

- ページは見つかるが、コンポーネントがデータなしで表示される

- メソッド・コールまたは組込み操作(「Next」や「Previous」など)の実行後、ページにデータが表示されない

- ページは表示されるが、メソッド・コールまたは組込み操作をまったく実行できない

- ページは表示されるが、予期しない検証エラーが発生する

データを表示できない、またはメソッド・コールを実行できない場合、WebページのコンポーネントとADFモデル・レイヤーの間の対話に原因があります。ADFライフサイクル処理中にランタイム・エラーが観測されると、モデルの準備、値の更新、アクションの起動、データのレンダリングという一連の処理の完了が失敗します。

幸い、WebアプリケーションとOracle ADFの対話における失敗は、アプリケーションにより定義された宣言情報か、ページのADFバインディング・コンテナのランタイム・オブジェクトにアクセスするEL式の中にある、修正が容易な単純なエラーが原因であることがほとんどです。

データバインド済Fusion Webアプリケーションでランタイム・エラーが観測された場合は、その原因として考えられる宣言情報とEL式を調べる必要があります。宣言ファイルの編集の詳細は、「単純なOracle ADFコンパイル・エラーの修正」および「単純なOracle ADFランタイム・エラーの修正」を参照してください。

最も役に立つ診断用ツールのうちの1つが、ADFロガーです。JDeveloperでは、このロギング・メカニズムを使用して実行時トレース・メッセージを取得します。ADFロギングが有効になっている場合、JDeveloperにより、メッセージ・ログ・ウィンドウ内にアプリケーション・トレースが表示されます。このトレースには、アプリケーション・エラーの原因をすぐに特定できるランタイム・メッセージが含まれます。詳細なトレース・メッセージが表示されるようにADFロガーを構成するには、「ADFロガーの使用」を参照してください。

サポート契約を締結しているOracle ADFのお客様については、Oracle Worldwide SupportにOracle ADFソース・コードをリクエストできます。これにより、ADFビジネス・コンポーネント・フレームワーク・コードを非常に簡単にデバッグできます。Oracle ADFソース・コードを使用するためのJDeveloperの構成方法の詳細は、「デバッガでのADFソース・コードの使用」を参照してください。

エラーを簡単に特定できない場合は、JDeveloperでADF宣言デバッガを使用してブレークポイントを設定することができます。ブレークポイントに達すると、アプリケーションの実行が一時停止され、ADFバインディング・コンテナの作業対象データを調べて、予測されるデータと比較することができます。ブレークポイントのタイプによっては、ステップ機能を使用して、1つのブレークポイントから別のブレークポイントに移動することができます。デバッガの詳細は、「ADF宣言デバッガの使用」を参照してください。

JDeveloperでは、回帰テスト・ケースを生成するウィザードにより、Fusion WebアプリケーションのためのJUnitとの統合が提供されます。アプリケーションのテスト・スイートの記述方法の詳細は、「JUnitを使用した回帰テスト」を参照してください。

48.2 単純なOracle ADFコンパイル・エラーの修正

JDeveloperで、Webページを作成し、ADFデータ・コントロールを使用してADFバインディング定義を作成するとき、編集するOracle ADF宣言ファイルは、Oracle ADFにより定義されたXMLスキーマに準拠している必要があります。XML構文エラーが発生すると、JDeveloper XMLコンパイラによって即時に「構造」ウィンドウ内にエラーが表示されます。

設計時に多少の構文チェックが行われますが、JDeveloperコンパイラには現在、EL式を解決できないという制限があります。Webページ内のEL式は、Web環境における様々なランタイム・オブジェクト(WebページのADFバインディング・コンテナなど)と直接対話します。現在、EL式内のエラーは実行時にしか観測できません。このため、オブジェクト・アクセス式に入力エラーが1つ存在していても、コンパイラによって検出されず、実行時にバインディング・コンテナと対話できないこと、またページにデータが表示されないことでエラーが明らかになります。ラインタイム・エラーのデバッグの詳細は、「単純なOracle ADFランタイム・エラーの修正」を参照してください。

ヒント:

式ビルダーは、オブジェクト、マネージドBeanおよびプロパティのリストを提供することでEL式の作成を支援するダイアログです。また、ADFバインディング・オブジェクトの階層リストやその有効なプロパティが提供され、選択できるため、ADFデータバインド式の作成や編集に特に便利です。入力エラーを未然に防ぐために、式ビルダーを使用してください。詳細は、「ADFデータ・バインディングのEL式の作成」を参照してください。

次の例は、ページ定義ファイルに含まれている単純なコンパイル・エラーを2つ示しています。falseとなるところがfalsに、ChangeEventPolicy="ppr"/>となるところがChangeEventPolicy="ppr"/ (つまり、属性に山閉じカッコがない)となっています。

<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
Package="oracle.summit.view.pageDefs"
SkipValidation="fals">
<parameters/>
<executables>
<iterator Binds="InventoryForOrderItem" RangeSize="-1" DataControl="BackOfficeAppModuleDataControl" id="InventoryForOrderItemIterator"
ChangeEventPolicy="ppr"/
...
</pageDefinition>

コンパイル時には、図48-1に示すように、「構造」ウィンドウにページ内のXMLエラーが表示されます。

図48-1 「構造」ウィンドウに表示されたXMLエラー

コンパイラ-「ログ」ウィンドウには、図48-2に示すように、ページ内のコンパイル・エラーも表示されます。

図48-2 「コンパイラ」ウィンドウに表示されたXMLコンパイル・エラー

スキーマ検証エラーを確認し、修正するには:

1. メイン・メニューで「表示」→「構造」を選択して「構造」ウィンドウを開くか、「表示」→「ログ」を選択して「ログ」ウィンドウを開きます。

2. どちらかのウィンドウで、エラー・メッセージをダブルクリックします。

3. XMLエディタで、強調表示された行を特定します。
エラーのある行が強調表示されます。

4. エラーを修正します。
エラーを修正すると、それに対応するエラー・メッセージは自動的に「構造」ウィンドウから削除されます。

5. 必要であれば、プロジェクトを再コンパイルします。「実行」→「メイク」を選択し、コンパイラでエラー・メッセージがまだ生成されるかどうかをチェックします。

48.3 単純なOracle ADFランタイム・エラーの修正

ADFモデル・レイヤーの障害はJDeveloperコンパイラでは検出できません。1つには、ページのデータ表示とメソッド実行の動作が宣言ADFページ定義ファイルに依存するためです。ADFモデル・レイヤーはこのような宣言ファイルを実行時に使用して、ADFバインディング・コンテナのオブジェクトを作成します。

スキーマ検証だけでなく、Webページを定期的に実行およびテストして、次のいずれの条件も存在していないことを確認すると効果的です。

- データ・モデル・プロジェクトとユーザー・インタフェース・プロジェクトの間のプロジェクト依存関係が無効である。
デフォルトでは、データ・モデル・プロジェクト内のデータ・コントロールにアクセスするWebページを作成すると、プロジェクト間の依存関係が有効になります。しかし、アプリケーションを実行しようとしたときに依存関係が無効化されて再び有効化されないと、実行時に次の内部サーブレット・エラーが生成されます。

oracle.jbo.NoDefException: JBO-25002: 型nullの定義model.DataControls.dcxが見つかりません。

このエラーを修正するには、ユーザー・インタフェース・プロジェクトをダブルクリックし、ダイアログで「依存性」ノードを選択します。パネル内にModelProjectName.jprオプションが表示されていることを確認してください。

- ページ定義ファイルの名前が変更されたのに、DataBindings.cpxファイルが依然として元のページ定義ファイル名を参照している。
JDeveloperではIDE内でのこれらのファイルの名前変更は許可されていませんが、JDeveloperの外部でページ定義ファイルの名前が変更された場合、DataBindings.cpxファイル内の参照が更新されていないと、実行時に次の内部サーブレット・エラーが生成されます。

oracle.jbo.NoDefException: JBO-25002: 型フォーム・バインディング定義の定義oracle.<path>.pageDefs.<pagedefinitionName>が見つかりません。

このエラーを修正するには、DataBindings.cpxファイルを開き、ソース・エディタを使用して<pageMap>要素と<pageDefinitionUsages>要素にあるページ定義ファイル名を編集します。

- Webページ・ファイル(.jspまたは.jspx)の名前が変更されたが、DataBindings.cpxファイルが依然として同じWebページの元のファイル名を参照している。
ページ・コントローラでは、ページのURLを使用して、Webページ用のADFバインディング・コンテナの作成に使用する適切なページ定義を決定します。URLからのページの名前がDataBindings.cpxファイルの<pageMap>要素と一致しない場合、実行時に次の内部サーブレット・エラーが生成されます。

javax.faces.el.PropertyNotFoundException: プロパティ<propertyname>のテスト中にエラーが発生しました。

このエラーを修正するには、DataBindings.cpxファイルを開き、ソース・エディタを使用して<pageMap>要素にあるWebページ・ファイル名を編集します。

- WebページのEL式でバインディングの名前が変更されたが、ページ定義ファイルが依然として元のバインディング・オブジェクト名を参照している。
Webページに期待どおりの情報が表示されない可能性があります。このエラーを修正するには、ページ定義ファイル内のバインディング名と、表示されていないページ部分に対応するEL式とを比較します。不一致は値バインディングで発生する可能性が最も高く、その結果として、コンポーネントがデータなしで表示されます。イテレータ・バインディング名で不一致が発生した場合、エラーはさらに軽微になり、不一致の原因を特定するためにさらに詳細なデバッグが必要になることがあります。

- ページ定義ファイル内のバインディングの名前変更または削除が行われたが、EL式が依然として元のバインディング・オブジェクト名を参照している。
デフォルトのエラー処理メカニズムによりADFバインディング・コンテナからのランタイム・エラーが捕捉されるため、このタイプのエラーは非常に簡単に検出できます。たとえば、ページ定義ファイル内の、findUsersByNameIterという名前のイテレータ・バインディング名が変更されたが、ページが依然として元の名前を参照している場合、Webページに次のエラーが表示されます。

JBO-25005: 型イテレータ・バインディング定義のオブジェクト名<iterator>が無効です。

このエラーを修正するには、Webページで名前をクリックして「ページ定義に移動」を選択し、EL式内に使用する適切なバインディング名を見つけます。

- 式ピッカー・ダイアログを使用せずに手動でEL式を記述し、無効なオブジェクト名またはプロパティ名が入力されている。
このエラーは見つけにくいことがあります。エラーが含まれているEL式によって、サーブレットのエラー・メッセージが表示されることと、表示されないことがあります。たとえば、ランタイム結果を持たないバインディング・プロパティ(ラベル名の表示など)においてエラーが発生した場合、ページは正常に機能しますが、ラベルは表示されません。しかし、メソッドを実行するバインディングにおいてエラーが発生した場合は、内部サーブレット・エラーjavax.faces.el.MethodNotFoundException: methodnameが表示されます。また、メソッド式にプロパティ名を間違って入力した場合は、サーブレット・エラーjavax.faces.el.PropertyNotFoundException: propertynameが表示されます。

このような一般的なエラーのリストを調べても、ランタイム・エラーの特定と解決ができない場合は、原因を特定するためにJDeveloper内部のデバッグを開始できます。Oracle ADFアプリケーションの場合は、問題を特定するためにADF宣言ブレークポイントの設定を開始します。ADF宣言デバッガを使用してADF宣言ブレークポイントを設定する方法は、「ADF宣言デバッガの使用」および「ADF宣言ブレークポイントの設定」で説明されています。このプロセスでは、アプリケーションで処理を続行する際にアプリケーションの実行を一時停止してデータを調べます。また、「JavaコードとGroovyスクリプトのブレークポイントの設定」で説明するように、ADF宣言デバッガを使用してJavaコード・ブレークポイントを設定することもできます。

48.4 統合WebLogic ServerのOracle ADFのメタデータのリロード

JDeveloperによるOracle ADFのメタデータのホット・リロードのサポートは、実行中のアプリケーションを終了し、プロジェクトのXML定義ファイルを編集して再デプロイし、統合WebLogic Serverでアプリケーションを再実行して最新の変更を表示する手順の代替手段です。

統合WebLogic Serverにデプロイしたアプリケーションは、Fusion Webアプリケーション・プロジェクトに対して行う変更を自動的に適用しません。ただし、データ・モデル・プロジェクトとユーザー・インタフェース・プロジェクトからいつでもメタデータをリロードして、実行中のアプリケーションをアプリケーションのXML定義ファイルに対して行った変更と同期をとることができます。

デプロイしたFusion Webアプリケーションに変更が反映されるようにメタデータをリロードするには、プロジェクトを再コンパイルし、Webブラウザをリフレッシュする必要があります。

JDeveloperが統合WebLogic Serverにホット・リロードするメタデータには次のものがあります。

- データ・モデル・プロジェクトでは、ビジネス・コンポーネントの定義ファイルに対する変更。

- ユーザー・インタフェース・プロジェクトでは、ページ定義ファイルのバインディング定義に対する変更およびタスク・フロー定義ファイルのタスク・フローに対する変更。

このサポートによって、インクリメンタル変更の実行およびそのテストが可能になります。

48.5 ADFコントローラのメタデータの検証

ADFコントローラがメタデータを取得すると、基本的な検証が実行されます。デフォルト・アクティビティがないタスク・フローなど、最も重大なエラーでは例外が解析されます。

adf-config.xmlのenable-grammar-validation設定を使用すると、アプリケーションのデプロイ前にADFコントローラのメタデータの文法を検証できるようになります。enable-grammar-validationをtrueに設定すると、ADFコントローラのメタデータはADFコントローラのXSDに対して検証されます。たとえば、ビュー・アクティビティIDのスラッシュ(/)など、ADFコントローラのメタデータの無効な文字は、例外としてフラグを立てられます。

デフォルトでは、enable-grammar-validationはfalseに設定されています。パフォーマンス上の理由から、アプリケーションの開発時またはトラブルシューティング時にのみ、trueに設定してください。

48.6 ADFロガーの使用

Webページまたはその対応するページ定義ファイル内でエラーが簡単に見つからない場合、JDeveloperのデバッグ・ツールを使用して、アプリケーションの障害の発生箇所を調べることができます。

Oracle Diagnostic Logging Configurationでは、エディタを使用してlogging.xml構成ファイルを編集することでロギング・セッションを構成できます。ロギング構成は、いつでも(アプリケーションがJDeveloperで実行していても)設定できます。

JDeveloperの多くのファイルとは異なり、logging.xmlファイルを直接開くことはできません。かわりに、これらの場所でメニュー・コマンドを使用して、Oracle Diagnostic Logging Configurationのエディタを開きます。

- 「アプリケーション・サーバー」ウィンドウでアクティブ・サーバー・インスタンスを右クリックします。

- アプリケーションをデバッグ・モードで起動した後、ログ・ウィンドウのデバッガ・プロセス・パネルに表示される「アクション」ドロップダウン・メニューをクリックします。

Oracle Diagnostic Logging Configurationのエディタを使用して、必要なロギング・レベルを設定し、表示されるメッセージのレベルと数を制御します。永続ロガーと一時ロガー両方のロギング・レベルを設定し、各ロガーのハンドラを宣言できます。

JDeveloperは、Oracle Fusion Middlewareのコンポーネントで使用されるOracle Diagnostic Logging (ODL)形式で診断ログ・ファイルを作成します。ログ・ファイルの名前とログ・ファイルの内容の形式は、Oracle標準に準拠します。デフォルトでは、診断メッセージはテキスト形式です。ODL形式の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

エディタでは、デフォルトのODL形式のかわりに、Javaロガーを構成してJava診断メッセージを表示できます。

ログを作成した後で、Oracle Diagnostic Log Analyzerでログ・メッセージを表示してフィルタ処理できます。このツールを使用すると、様々なログ・レベルでのフィルタ設定、メッセージの時間枠の定義、およびメッセージ・テキストの検索を行うことができます。

続いてADF宣言デバッガを使用して、ブレークポイントを設定し、アプリケーションを調べることができます。詳細は、「ADF宣言ブレークポイントの設定」および「JavaコードとGroovyスクリプトのブレークポイントの設定」を参照してください。

48.6.1 ADFロギング・レベルを設定する方法

Oracle Diagnostic Logging Configurationのエディタを使用して、logging.xml構成ファイルに指定されるロギング・レベルを構成できます。このファイルを構成できるのは、アプリケーションを統合WebLogic Serverで実行する前と実行しているときです。サーバーを再起動しなくても変更内容が適用されます。

統合WebLogic Serverが実行しているとき、永続ロガーと一時ロガーの両方を定義できます。統合WebLogic Serverが実行していないときは、永続ロガーしか定義できません。一時ロガーはセッションの間のみ存続し、logging.xml構成ファイルには入力されません。サーバーが実行していない場合は、次の実行時に更新が有効になるように、構成の変更内容を明示的にlogging.xmlファイルに保存する必要があります。

Oracle Diagnostic Logging Configurationのエディタは、「アプリケーション・サーバー」ウィンドウまたは「ログ」ウィンドウ(図48-3)から利用できます。

図48-3 「ログ」ウィンドウとツールバー

ただし、サーバーが実行しているときに「ログ」ウィンドウのメニューからエディタにアクセスすると、一時ロガーを追加する機能がエディタに含まれます。

図48-4にサーバーが実行しているときのOracle Diagnostic Logging Configurationを示します。

図48-4 Oracle Diagnostic Logging Configurationのエディタ

JDeveloperのメニュー・コマンドを使用するだけでlogging.xml構成ファイルを開いて、Oracle Diagnostic Logging Configurationのエディタを起動できます。ただし、構成ファイルの場所に関する次の情報が便利であることがわかります。

注意:

ログ・ハンドラ定義を宣言して追加するには、「ソース」タブをクリックして、定義をXMLエディタに入力します。

WindowsプラットフォームのJDeveloperで統合WebLogic Serverを使用している場合、logging.xml構成ファイルは次のような場所にあります。

C:\Users\username\AppData\Roaming\JDeveloper\<your_JDev_system_folder>\DefaultDomain\config\fmwconfig\servers\DefaultServer

統合WebLogic Serverのログ・ファイルは次のような場所にあります。

C:\Users\username\AppData\Roaming\JDeveloper\<your_JDev_system_folder>\DefaultDomain\servers\DefaultServer\logs

スタンドアロンWebLogic Serverインスタンスのログ・ファイルは次のような場所にあります。

$domain_home/servers/<your_servername>/logs

ロギング・レベルは、テスト実行の前には「アプリケーション・サーバー」で、アプリケーションの実行中には「ログ」ウィンドウの実行パネル・ツールバーで、またはデバッグ・セッション中には「ログ」ウィンドウのメニューで構成できます。

ログ・レベルを構成するには:

1. メイン・メニューで、「ウィンドウ」、「アプリケーション・サーバー」を選択します。

2. 「アプリケーション・サーバー」ウィンドウで「アプリケーション・サーバー」を開き、「IntegratedWebLogicServer」を右クリックして、「"IntegratedWebLogicServer"に対するOracle Diagnostic Loggingの構成」を選択します。
または、アプリケーションの開始後に、「ログ」ウィンドウの実行中: IntegratedWebLogicServerパネルで、「アクション」→「Oracle Diagnostic Loggingの構成」を選択します。「実行中のログ」ウィンドウは、アプリケーションの実行中のみ表示されます。

または、アプリケーションのデバッグ中に、「ログ」ウィンドウのデバッグ・プロセス・パネルで、「アクション」→「Oracle Diagnostic Loggingの構成」を選択します。デバッグ・プロセス・パネルは、アプリケーションをデバッグ・モードで起動した後のみ、「ログ」ウィンドウに表示されます。

3. Oracle Diagnostics Logging Configurationのエディタで、表示するロガー・タイプについて「ODLログ・レベル」または「Javaログ・レベル」を選択します。

4. 永続ロガーのみを表示する場合は、「一時ロガーの非表示」を選択します。

5. ロガーを追加するには次のようにします。

a. サーバーが実行している場合は、「追加」アイコンのドロップダウン・メニューをクリックして、「永続ロガーの追加」または「一時ロガーの追加」を選択します。サーバーが実行していない場合は、「追加」をクリックして永続ロガーを追加します。一時ロガーは追加できません。

b. ロガーの追加ダイアログでロガーの名前を入力します。

c. ロギング・レベルを選択します。

d. 「OK」をクリックします。

6. 新たに作成したロガーを含むすべてのロガーについて、ハンドラを指定できます。これには、使用可能なハンドラのリストから選択して、「ハンドラ宣言」セクションの「追加」アイコンをクリックします。
または、「親ハンドラの使用」を選択して、親のハンドラをロガーに割り当てます。デフォルトではロガーは親のハンドラを使用します。

注意:

ログ・ハンドラ定義を宣言して追加するには、「ソース」タブをクリックして、定義をXMLエディタに入力します。

48.6.2 Oracle ADFデバッグ構成の作成方法

Oracle ADFでは、デバッグ・セッションの実行時にロギング機能を提供するために、JavaロギングAPI (java.util.logging.Logger)を使用します。Javaロギングは、Javaプラットフォーム(http://docs.oracle.com/javase/7/docs/api/java/util/logging/package-summary.html)から入手できる標準APIです。

ADFイベント・メッセージの完全な階層ツリーをロギングするには、1つのパッケージに対してCONFIGよりも制限が厳しくないJavaログ・レベル(またはNotification:16よりも制限が厳しくないODLログ・レベル)を構成する必要があります。

- oracle.adfdiagnosticsでは、ADFモデル・データバインディング・レイヤー、ADFコントローラ・ソース・コード、ADFビジネス・コンポーネント、ADFデスクトップ統合、およびOracle ADF内部クラスのソース・コードで生成されるイベントがロギングされます。

図48-5に、最も詳細なOracle ADFログ・メッセージを有効にするように構成された特別なロガーを表示します。oracle.adfdiagnosticsパッケージはCONFIGに設定され、それよりも制限の厳しい(高い)ログ・レベルには設定されません(ここでは、SEVERE、WARNINGおよびINFOはCONFIGよりも高いJavaログ・レベルで、FINE、FINERおよびFINESTはCONFIGよりも低いレベルです)。oracle.adfdiagnosticsパッケージのロガーを有効化すると、ロガーはADFイベントの完全な階層を記録します。

図48-5 Oracle ADFデバッグのロガーの構成

後方互換性を保つため、Javaシステム・プロパティjbo.debugoutputによる値consoleまたはADFLoggerの設定がサポートされています(この設定を行うと、logging.xmlファイルを介して標準の方法で制御できる標準ロガー実装に診断がルーティングされます)。JDeveloper内部でのアプリケーションの実行中、このシステム・プロパティを設定する最も簡単な方法は、プロジェクト・プロパティを編集し、「実行/デバッグ」ページで実行構成を選択して、「編集」をクリックすることです。次に、文字列-Djbo.debugoutput=consoleを「Javaオプション」フィールドに追加します。

ADFモデルのデバッグ構成を作成するには:

1. メイン・メニューで、「ウィンドウ」、「アプリケーション・サーバー」を選択します。

2. 「アプリケーション・サーバー」ウィンドウで「アプリケーション・サーバー」を開き、IntegratedWebLogicServerを右クリックして、「Oracle Diagnostic Loggingの構成」を選択します。
または、アプリケーションの開始後に、「ログ」ウィンドウの実行中: IntegratedWebLogicServerパネルで、「アクション」→「Oracle Diagnostic Loggingの構成」を選択します。「実行中のログ」ウィンドウは、アプリケーションの実行中のみ表示されます。

または、アプリケーションのデバッグ中に、「ログ」ウィンドウのデバッグ・プロセス・パネルで、「アクション」→「Oracle Diagnostic Loggingの構成」を選択します。デバッグ・プロセス・パネルは、アプリケーションをデバッグ・モードで起動した後のみ、「ログ」ウィンドウに表示されます。

3. Oracle Diagnostics Logging Configurationのエディタで、表示するロガー・タイプについて「ODLログ・レベル」または「Javaログ・レベル」を選択します。

4. 「oracle」ノードを開き、CONFIGよりも制限が厳しくないログ・レベル(Javaログの場合)、またはNotificationよりも制限が厳しくないログ・レベル(ODLログの場合)を、次のパッケージに対して選択します。

- oracle.adfdiagnosticsでは、ADFモデル・データバインディング・レイヤー、ADFコントローラ・ソース・コード、ADFビジネス・コンポーネントおよびOracle ADF内部クラスのソース・コードで生成されるイベントがロギングされます。
このパッケージのロガーを有効化すると、ロガーはADFイベントの完全な階層を記録します。

5. その他の必要なOracle ADFロガーに対しては、Javaログ・レベル「FINEST」を選択します。

ADFビューJavascriptロギング構成を作成するには:

1. 「アプリケーション」ウィンドウで、アプリケーションまたはプロジェクトの「web.xml」ファイルをダブルクリックします。

2. ソース・エディタで、次の要素をファイルに追加します。

<context-param>
<param-name>
oracle.adf.view.rich.LOGGER_LEVEL
</param-name>
<param-value>
FINE
</param-value>
</context-param>

48.6.3 Oracle ADF以外のロガーの診断ロギングを有効化する方法

Oracle ADF以外のロガーの場合、実際のデバッガを使用する前に、FINE、FINERまたはFINESTにJavaログ・レベルを設定した状態でアプリケーションを実行することで、フレームワークの診断ロギングが可能になります。デバッグ診断メッセージは、問題発生時の処理を確認する際に役立ちます。デバッグ診断メッセージを有効にするには、Oracle Diagnostics Logging Configurationのエディタを使用して、Javaログ・レベルを最も詳細に設定して必要なロガーを構成します。サポートされているロガーの診断ロギングが構成済の場合、JDeveloperは、デバッグ診断メッセージをJDeveloperの「ログ」ウィンドウに表示します。

現時点で、Oracle ADFは、Javaログ・レベルをFINE、FINERまたはFINESTに設定した状態のロギングはサポートしていません。Oracle ADFロガーの詳細は、「Oracle ADFデバッグ構成の作成方法」を参照してください。

48.6.4 ログ・アナライザを使用してログ・メッセージを表示する方法

Oracle Diagnostic Log Analyzerを使用してログ・ファイルのログ・エントリを表示できます。ログ・アナライザでは、ログ・レベル、エントリ・タイプ、ログの時刻、エントリの内容によってエントリをフィルタ処理できます(1つ以上の検索基準を使用)。見やすくするために、メッセージの並替えや、列の表示と非表示の切替えを行うこともできます。

図48-6に、Javaログ・レベルの表示に設定されているOracle Diagnostic Log Analyzerを示します。

図48-6 Oracle Diagnostic Log AnalyzerでのJavaログ・メッセージの表示

他のテスト実行で作成されたログ・ファイルに対してもログ・アナライザを使用できます。たとえば、他のアプリケーションについて別の開発者から送信されたログを分析できます。

48.6.4.1 ログ・アナライザでの診断メッセージの表示

ロギング・レベルは、テスト実行の前に「アプリケーション・サーバー」ウィンドウで、またはデバッグ・セッション中に「ログ」ウィンドウのツールバーで構成できます。指定するレベルによって、ログ・メッセージのタイプと量が決まります。

ADFイベントの場合、ODLログについては「通知」レベルで、Javaログに関しては「情報」レベルで、すべてのメッセージが生成されます。「インシデント・エラー」/「重度」レベルや「エラー」/「警告」レベルでは、生成されるADFメッセージの数は少なくなります。

表示するメッセージのログ・レベルを選択した後で、「ログ・メッセージ別」ページの「検索」パネルを使用して、ログ・ファイルのメッセージをフィルタ処理して表示します。

注意:

ADF固有のメッセージを検索するために指定できる検索基準の詳細は、「ADFイベントに基づく診断メッセージのソート」を参照してください。

ログ・アナライザを開始するには、テスト実行の前は「ツール」メニューを使用し、デバッグ・セッション中は「ログ」ウィンドウのツールバーを使用します。

始める前に:

ロギングの知識があると役立ちます。詳細は、「ADFロガーの使用」を参照してください。

次のタスクを完了する必要があります。

1. 「ADFロギング・レベルを設定する方法」の説明に従い、ロギング・レベルを設定します。

2. 「Oracle ADF以外のロガーの診断ロギングを有効化する方法」の説明に従い、ロギングを有効にします。

3. テスト実行または別のソースからログ・ファイルを作成します。

ログ・アナライザを開始するには:

1. メイン・メニューで、「ツール」→「Oracle Diagnostic Log Analyzer」を選択します。

あるいは、「ログ」ウィンドウの「アクション」メニューで、「ログの分析」を選択して、「コンソールのカレント」または「選択項目を開く」(サーバー・ログ・ディレクトリのログ・ファイルを参照する)のいずれかを選択します。

2. Oracle Diagnostic Log Analyzerのエディタで「ログ・メッセージ別」をクリックします。

3. 「ログ・メッセージ別」ページで、「ログ」フィールドにログ・ファイルのパスと名前を入力するか、「ログ・ファイルの参照」をクリックしてログ・ファイルに移動します。

ヒント:

「ログ・ファイルの選択」ダイアログを使用して、JDeveloperで生成されたログ・ファイルを含むディレクトリにナビゲートできます。「ログ」テキスト・フィールドの横の「ログ・ファイルの参照」アイコンをクリックし、スクロール・リストの「サーバー・ログ」アイコンをクリックします。ログ・ファイルのリストから、一度に分析する複数のログ・ファイルを選択できます。

4. ドロップダウン・リストで「ODLログ・レベル」または「Javaログ・レベル」を選択します。

5. 表示するログ・エントリのタイプごとに対応するチェックボックスを選択します。少なくとも1つのタイプを選択する必要があります。

選択できるODLログ・レベルのタイプは次のとおりです。

- インシデント・エラー

- エラー

- 警告

- NOTIFICATION: ADFイベント・メッセージに対応

- トレース

- 不明。

選択できるJavaログ・レベルのタイプは次のとおりです。

- 重度

- 警告

- 情報

- CONFIG: ADFイベント・メッセージに対応

- 普通

- 詳細

- 最も詳細

- 不明

6. 表示するエントリの期間を指定します。一番新しい期間または範囲を選択できます。

7. 結果をフィルタ処理するには、「検索」パネルを使用してログでテキスト・パターンを問い合せます。検索基準を追加するには、「追加」をクリックしてください。サポートされる検索基準は次のとおりです。

- エンタープライズ名: エンタープライズ名ごとにログをフィルタ処理します。

- 詳細: メソッドが起動されたスタックの文からテキストをフィルタ処理します。

- エンタープライズID: エンタープライズのIDごとにログをフィルタ処理します。

- メッセージ: ロギングされたメッセージのテキストをフィルタ処理します。

- ADFメッセージ・データ: ADFイベントの実行中にロギングされた、ADFライフサイクル・フェーズ名、ビュー・オブジェクト名、ビュー・オブジェクト問合せ文、データ・コントロール名、バインディング・コンテナ名およびイテレータ・バインディング名に関連するデータのログをフィルタ処理します。

- ソース・メソッド: メッセージがロギングされるメソッドごとにログをフィルタ処理します。たとえば、メソッドexecuteについてフィルタ処理すると、ビュー・オブジェクトの問合せ実行またはADFライフサイクル・フェーズ実行でロギングされたすべてのメッセージを表示できます。

- アプリケーション: メッセージがロギングされるアプリケーション名ごとにログをフィルタ処理します。これが役立つのは、アプリケーションがコンポジット・アプリケーション内で実行しているときに、特定のアプリケーションのメッセージを表示する場合です。

- ソース・クラス: メッセージがロギングされるメソッドの完全修飾クラス名ごとにログをフィルタ処理します。表示されるメッセージ数を増やすには、パッケージ名の一部を入力します。たとえば、パッケージ名の一部oracle.adfや完全なパッケージ名oracle.jboを入力すると、Oracle ADFに関連するすべてのクラスについてフィルタ処理できます。

- モジュール: メッセージがロギングされるクラスの完全修飾パッケージ名ごとにログをフィルタ処理します。これはソース・クラスと同じパッケージです。

- メッセージID: ロギングされたメッセージのIDごとにログをフィルタ処理します。IDが同じメッセージが多数あります。たとえば、メッセージID ADFC-52008には、4つのINFOメッセージと1つのWarningメッセージがあります。ログ・アナライザの「結果」パネルで「IDでグループ化」を選択すると、共通のIDでメッセージをグループ化できます。

8. フィルタを開始して、ログ・メッセージを表示するには、「検索」をクリックします。

9. メッセージID順に結果を並べるには、「IDでグループ化」チェックボックスを選択します。

10. 期間別またはリクエスト別にメッセージをグループ化するには、「関連付け」列で「時間による関連付け」または「リクエストによる関連付け」を選択します。

関連付けオプションを選択すると、ログ・アナライザによって「結果メッセージ」パネル内のメッセージが、選択した基準(時間、HTTPリクエストまたはエンタープライズ名)によってグループ化されます。

11. 「関連付け」列で、メッセージがその一部となっているADFリクエスト(存在する場合)を開くには、「ADFリクエストによる関連付け」を選択します。

「ADFリクエストによる関連付け」を選択すると、ログ・アナライザの「ADFリクエスト別」ページには関連するリクエストが表示されます。

12. 「結果」セクションで列の表示と非表示を切り替えるには、列ヘッダーの右側のドロップダウン・リストをクリックし、表示される列のリストを選択して、列の表示状態を変更します。

48.6.4.2 ADFリクエストを分析するためのログ・アナライザの使用

OracleではOracle ADFソース・コードを使用して、ADFライフサイクル・フェーズの実行中にログ・メッセージを生成するため、ログ・アナライザを使用すると、実行中のアプリケーションでのアクティブな(または以前の)ページ・リクエストの詳細を調査できます。特に、ログ・アナライザの「ADFリクエスト別」ページでは、実行順に整理された階層リストでADFイベント・メッセージを表示できます。また、各イベントのグラフィック表示も提供されます。アプリケーションを実行して、ADFロギングが構成されたログ・アナライザを開始したとき、実行時間が通常よりも長い場合は、このページを使用すると、アプリケーションのコンポーネントがパフォーマンス・ボトルネックに関与しているかどうかをすぐに判断できます。

注意:

「ログ・メッセージ別」ページとは異なり、ログ・アナライザの「ADFリクエスト別」ページにはADFイベント・メッセージが階層で表示されます。この2つのページの違いは、「ADFリクエスト別」ページでは、ページまたはリージョンが送信されたときに作成されたADFページ・リクエストのみに焦点を当てていることです。ADFページ・ライフサイクルの詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。

「ADFリクエスト別」ページに検索基準を入力すると、ログ・ファイルの特定のリクエストを1つ以上表示できます。次のいずれかの検索基準を組み合せて、ログ・ファイルをフィルタ処理できます。

- 表示するリクエストの数

- ログに記録されたリクエストのタイムスタンプ

- ログインしているユーザー名、エンタープライズ名、リクエスト・ヘッダー(ページまたはリージョン名に基づく検索の指定用)、メッセージ、ソース・クラス、モジュール、サーバー、詳細、エンタープライズID、ADFメッセージ・データ、コンポジット・アプリケーション内のアプリケーション名、ソース・メソッド、メッセージIDまたはECID (すべてのトップレベル・タスクに関連付けられたグローバルに一意のID。そのトップレベル・タスクによって起動されるサブタスクは、同じECIDを共有する実行コンテキストによって機能します)。

リクエストの完了後、ログ・アナライザでは単一の表にADFリクエストのサマリーが表示されます。図48-7に、ADF Webリクエストを一覧したサマリー表を示します。

図48-7 Oracle Diagnostic Log AnalyzerでのADF Webリクエストのサマリーの表示

サマリー表に表示されたADFリクエストごとに、リクエスト・リンクをクリックして、リクエスト・イベント階層に関する詳細を表示できます。図48-8に示す「ADFリクエスト」パネルには、JSFライフサイクルのビューのリストア・フェーズおよびレスポンス・レンダリング・フェーズが表示されています(期間はミリ秒単位)。リクエスト・イベント階層のルート・ノード(ADF Webリクエスト)の棒グラフは合計実行時間を示します。

図48-8 Oracle Diagnostic Log AnalyzerでのADF Webリクエスト・イベント階層の表示

注意:

リクエスト時間の割合の棒グラフの2色(黒とグレー)は、リクエストの実行時間のうち、ADFソース・コードのADFイベント・メッセージの生成に使用された部分(黒で表示)と、使用されなかったADFソース・コードの部分(ADFイベント・メッセージを生成できない、グレーで表示)に基づく時間を示します。また、リクエストの個々のフェーズを合計しても合計のリクエスト時間と等しくならないことに注意してください。これは、ライフサイクルの有効なフェーズのみがログ・アナライザに表示されるためです。

リクエストをさらに詳しく調べるには、ADFライフサイクル・ノードのツリーを展開して、アプリケーションのどこでパフォーマンス・ボトルネックが発生したかを調査します。リクエスト・メッセージ・パネルでドリルダウンしてADFイベント・ノードを選択すると、各ADFイベントに関連付けられたコンポーネントの詳細が表示されます。たとえば、JSFフェーズRENDER_RESPONSEノードを開くと、そのフェーズで生成されたすべてのADFイベントが表示されます。図48-9に、開かれたJSFフェーズRENDER_RESPONSEノードを示します。リクエスト期間を表す長い棒グラフが表示されたLOVリストの取得ノードと「問合せの実行」ノードがあります。「問合せの実行」ノードが選択されており、ビュー・オブジェクト名や問合せ文を含む詳細なADFデータが「ADFメッセージ・データ詳細」パネルの下部に表示されます。棒グラフが示す実行時間が長いADFイベントをドリルダウンして選択することで、たとえば、データ・モデル・プロジェクト内のビュー・オブジェクト名を取得できます。パフォーマンスを改善するためにはこれをチューニングする必要があります。

図48-9 Oracle Diagnostic Log AnalyzerでのADFイベント・メッセージとADFデータの表示

始める前に:

ロギングの知識があると役立ちます。詳細は、「ADFロガーの使用」を参照してください。

次のタスクを完了する必要があります。

1. 「ADFロギング・レベルを設定する方法」の説明に従い、ロギング・レベルを設定します。
ADFイベント・メッセージの完全な階層ツリーをロギングするには、1つのパッケージに対してNOTIFICATION:16よりも制限が厳しくないODLログ・レベル、またはCONFIGよりも制限が厳しくないJavaログ・レベルを構成する必要があります。

- oracle.adfdiagnosticsでは、ADFモデル・データ・バインディング・レイヤー、ADFコントローラ・ソース・コード、ADFビジネス・コンポーネント、およびOracle ADF内部クラスのソース・コードで生成されるイベントがロギングされます。

ヒント:

Oracle Diagnostics Logging Configurationのエディタによって表示されるルート・ログ出力のデフォルト・ログ・レベルでは、ADFイベント・メッセージのロギングが保証されます。

2. 「Oracle ADF以外のロガーの診断ロギングを有効化する方法」の説明に従い、ロギングを有効にします。

3. テスト実行または別のソースからログ・ファイルを作成します。

ログ・アナライザでADFリクエスト・メッセージを表示するには:

1. メイン・メニューで、「ツール」→「Oracle Diagnostic Log Analyzer」を選択します。

あるいは、「ログ」ウィンドウの「アクション」メニューで、「ログの分析」を選択して、「コンソールのカレント」または「選択項目を開く」(サーバー・ログ・ディレクトリのログ・ファイルを参照する)のいずれかを選択します。

2. Oracle Diagnostic Log Analyzerのエディタで「ADFリクエスト別」タブをクリックします。

3. 「ADFリクエスト別」ページで、表示する最新リクエストの数を指定します。

デフォルトでは一番新しいリクエスト1つしか表示されません。

4. 表示するエントリの期間を指定します。一番新しい期間または範囲を選択できます。

5. 表示するリクエストをフィルタ処理するには、検索フィールドを使用してログでテキスト・パターンを問い合せます。検索フィールドを追加するには、「行の追加」アイコンをクリックしてください。

6. フィルタを開始して、一致するADFリクエストを表示するには、「検索」をクリックします。

7. 「ADFリクエスト」パネルで、目的のリクエスト・リンクをクリックしてイベント階層を表示し、時間(ミリ秒)の棒グラフが示す実行時間が長いADFイベントを探します。

8. 必要なADFイベントを選択し、ADFイベントに関連するADFコンポーネントの詳細を「ADFメッセージ・データ詳細」パネルで確認します。

9. アプリケーションのコンポーネントを調べて、最適化が可能かどうかを判別します。

48.6.4.3 ADFイベントに基づく診断メッセージのソート

Oracleでは、ADFライフサイクル・フェーズの実行中、およびADFモデルのデータバインディング・レイヤー、ADFコントローラ・ソースおよびADFビジネス・コンポーネント・ソースで実行される操作中に、Oracle ADFソース・コードを使用してログ・メッセージが生成されます。ログ・アナライザではこれらのメッセージをまとめてADFイベントと呼びます。ログ・アナライザを使用して、実行中のアプリケーションのADFイベントを調査することができます。ログ・アナライザの「ログ・メッセージ別」ページでは、ADFイベント・メッセージが実行時刻で整理されたフラット・リストで表示されます。「ADFリクエスト別」ページに切り替えて、実行順の階層リストでADFイベントを表示することもできます。

ADFイベント・メッセージには、アプリケーションのどのADFコンポーネントでイベントが生成されたかを特定するための情報が含まれます。たとえば、ADFイベント・メッセージのログを検索して、ページでのデータ表示、問合せの実行またはアクションの開始に関連するコンポーネントを識別できます。

- イテレータ・バインディングの実行: ページでのデータ表示を管理するために実行されたイテレータの名前を表示します。これは、問合せの更新が遅い場合の診断に役立ちます。

- 問合せの実行: 実行された問合せに関連するビュー・オブジェクトの名前を表示します。これが役立つのは、問合せ文、バインド・パラメータおよびビュー・オブジェクト名を表示する場合です。

- メソッド・バインディングの実行: バインド・データ・ソースに対して実行されたJavaメソッドの名前を表示します。これは、メソッドの実行が遅い場合の診断に役立ちます。

ログ・アナライザにADFイベント・メッセージを表示した後で、ロギングされた他のメッセージとの関係に基づいてイベントを整理することができます。次のように表示する項目に応じて「関連付け」列でオプションを選択できます。

- ADFイベントまでのすべてのメッセージ(「時間による関連付け」)

- ADFイベントと同じWebリクエストのすべてのメッセージ(「リクエストによる関連付け」)

- 同じWebリクエストのADFイベント・メッセージのみ(「ADFリクエストによる関連付け」)

ヒント:

「ADFリクエストによる関連付け」オプションには、ADFイベント・メッセージの詳細なADFデータが表示されます。たとえば、このビューは、「問合せの実行」メッセージに関連する問合せ文を表示する場合に使用します。

図48-10に、ADFイベント・メッセージ「アプリケーション・モジュールの作成」に関するログ・アナライザの検索結果を示します。「結果」パネルに検索基準を満たすすべてのメッセージが表示され、下部のパネルにはコンポーネントの詳細情報が表示されます。

図48-10 Oracle Diagnostic Log AnalyzerでのADFイベント・メッセージの表示

「結果」パネルの「関連付け」列で「ADFリクエストによる関連付け」を選択すると、ログ・アナライザは「ADFリクエスト別」ページの表示に切り替わり、ADFイベント・メッセージが実行の依存関係を表す階層で表示されます。ログ・アナライザの「ADFリクエスト別」ページは、パフォーマンスの問題の診断に適しています。「ADFリクエスト別」ページの詳細は、「ADFリクエストを分析するためのログ・アナライザの使用」を参照してください。「ログ・メッセージ別」ページの経過時間は、「結果」パネルから表示または非表示にできる情報です。

始める前に:

ロギングの知識があると役立ちます。詳細は、「ADFロガーの使用」を参照してください。

次のタスクを完了する必要があります。

1. 「ADFロギング・レベルを設定する方法」の説明に従い、ロギング・レベルを設定します。
ADFイベント・メッセージをロギングするには、次のパッケージについてNOTIFICATION:16よりも制限の厳しいODLログ・レベルまたはCONFIGよりも制限の厳しいJavaログ・レベルを構成しないでください。

- oracle.adfdiagnosticsでは、ADFモデル・データ・バインディング・レイヤー、ADFコントローラ・ソース・コード、ADFビジネス・コンポーネント、およびOracle ADF内部クラスのソース・コードで生成されるイベントがロギングされます。

ヒント:

Oracle Diagnostics Logging Configurationのエディタによって表示されるルート・ログ出力のデフォルト・ログ・レベルでは、ADFイベント・メッセージのロギングが保証されます。

2. 「Oracle ADF以外のロガーの診断ロギングを有効化する方法」の説明に従い、ロギングを有効にします。

3. テスト実行または別のソースからログ・ファイルを作成します。

ADFイベントに関連付けられたメッセージを表示するには:

1. メイン・メニューで、「ツール」→「Oracle Diagnostic Log Analyzer」を選択します。

あるいは、「ログ」ウィンドウの「アクション」メニューで、「ログの分析」を選択して、「コンソールのカレント」または「選択項目を開く」(サーバー・ログ・ディレクトリのログ・ファイルを参照する)のいずれかを選択します。

2. Oracle Diagnostic Log Analyzerのエディタで「ログ・メッセージ別」タブをクリックします。

3. 「ログ・メッセージ別」ページで、必要なロガー・タイプ、ログ・レベルおよびログ時間を選択します。

ADFイベント・メッセージのログを検索するには、最低でもログ・レベル「通知」(ODLログ・レベル)または「情報」(Javaログ・レベル)を選択する必要があります。

4. 検索のドロップダウンで、検索基準として「メッセージ」と「次を含む」を選択し、次のいずれかのADFイベント・メッセージを入力して、「検索」をクリックします。

- Executing iterator binding - これは、問合せの更新が遅い場合の診断に役立ちます。

- Executing method binding - これは、メソッドの実行が遅い場合の診断に役立ちます。

- Execute query - これが役立つのは、問合せ文、バインド・パラメータおよびビュー・オブジェクト名を表示する場合です。

さらに次に示すADFイベント・メッセージについてログをフィルタ処理することもできます。

- Refreshing binding container

- データソースへのイテレータ・バインディングのアタッチ

- 階層ノードへの行の変換

- Estimated row count

- Get LOV list

- Filter LOV list

- Validate Entity

- Lock Entity's Parent

- Lock Entity

- エンティティの変更のポスティング前

- エンティティの変更のポスティング

- Posting in batches

- エンティティの変更のコミット前

- エンティティの変更のコミット後

- エンティティの変更のロールバック前

- エンティティの変更のロールバック後

- イベントを通知するエンティティ

- Entity notification name

- Removing Entity

- Updating audit columns

- 有効日付変更の適用

- Entity DML

- エンティティでのすべての属性の読取り

- Create Application Module

- ネスト・アプリケーション・モジュールの作成

- Passivating Application Module

- Activating Application Module

- Establish database connection

- Commit transaction

- Rollback transaction

- Validate transaction

- Validate value

ADFイベントの情報について「結果」パネルのデータ部分で確認します。

5. ADFイベントを階層表示するには、必要なADFイベント・メッセージが「結果」パネルで選択された状態で、「関連付け」列で、必要なイベント行のアイコンをクリックして、ドロップダウン・メニューから「ADFリクエストによる関連付け」を選択します。

Oracle Diagnostic Log Analyzerのエディタに、選択したADFイベントの「ADFリクエスト別」ページが表示されます。ADFイベントのその他のADFデータについて「結果」パネルの下部で確認します。たとえば、「結果」パネルの「ADFデータ」領域で「問合せの実行」メッセージに関連する問合せ文を確認できます。

48.6.5 ADFロガーおよびログ・レベルに関する必知事項

デフォルトでは、すべてのOracleロガーのレベルがWARNINGに設定されます。Oracle ADFパッケージで、詳細なロギング診断を行う場合には、level="FINE"に設定します。

ADFビュー・レイヤー・パッケージoracle.adf.view.facesおよびoracle.adfinternal.view.facesの場合は、次の要素を編集します。

<logger name="oracle.adf" level="FINE"/>
<logger name="oracle.adfinternal" level="FINE"/>

ADFモデル・レイヤー・パッケージの場合は、次の要素を編集します。

<logger name="oracle.adf" level="FINE"/>
<logger name="oracle.jbo" level="FINE"/>

ADFコントローラ・レイヤー・パッケージの場合は、次の要素を編集します。

<logger name="oracle.adf.controller" level="FINE"/>
<logger name="oracle.adfinternal.controller" level="FINE"/>

あるいは、デバッグ・セッションを開始する際に選択できるデバッグ構成をJDeveloper内に作成することもできます。

次の例は、ログ・メッセージの粒度を変更できるlogging.xmlファイルの一部を示しています。例の中で、oracle.adf.facesのログが、より多くのメッセージを表示するためにFINEに変更されていることに注意してください。

</logging_configuration>
...
<loggers>
<logger name="oracle.adf" level="INFO"/>
<logger name="oracle.adf.faces" level="FINE"/>
<logger name="oracle.adf.controller" level="INFO"/>
<logger name="oracle.bc4j" level="INFO"/>
<logger name="oracle.adf.portal" level="INFO"/>
<logger name="oracle.vcr" level="INFO"/>
<logger name="oracle.portlet" level="INFO"/>
<logger name="oracle.adfinternal" level="INFO"/>
<logger name="oracle.adfdt" level="INFO"/>
<logger name="oracle.adfdtinternal" level="INFO"/>
</loggers>
</logging_configuration>

Javaロギング・システムの各種レベルの最新情報は、http://www.oracle.com/technetwork/java/index.htmlを参照してください。通常、Javaロギング・システムでは次のログ・レベルがサポートされます。

- SEVERE (最も制限された最高のログ・レベル)

- 警告

- 情報

- CONFIG (Oracle ADFに対してサポートされる最高のログ・レベル)

- 普通

- 詳細

- FINEST (最も制限の少ない最低のログ・レベル)

48.6.6 ADFロギングおよびログ出力に関する必知事項

デフォルトでは、ロガーは階層的なので、別のロガーの子であるロガーは、その親のログ・レベルを継承するため、予想外に大きなログ出力を生成することがあります。このため、Oracle Diagnostic Logging Configurationのエディタでロガーを有効化する場合、親ロガーのログ・レベルと子ロガーのログ・レベルを別々に設定することをお薦めします。これは、メモリー・リークなどの条件を診断するのに便利な設定FINE、FINER、FINESTを使用する場合、詳細なログ・メッセージが有用なので、特に重要です。

たとえば、メモリー・リークをデバッグする場合、oracle.adf.share.ADFContextロガーをFINESTに設定することが考えられます。この設定は、子oracle.adf.share.ADFContext.allocationLoggerロガーを自動的に起動させるため、ログ出力ファイルに、割当てバッファ超過条件が生じることがあります。このため、メモリー・リークを修正するために必要なメッセージを有効にする解決策は、親レベルをFINESTにする一方で、子ロガーをINFOに下げることです。

<logger name="oracle.adf.share.ADFContext" level="FINE"/>
<logger name="oracle.adf.share.ADFContext.allocationLogger" level="INFO"/>

48.6.7 ADFロギングとOracle WebLogic Serverに関する必知事項

Fusion WebアプリケーションをOracle WebLogic Serverにデプロイした後で、アプリケーションによって実行される処理は、そのアプリケーションが実行している管理対象サーバーの次のファイルに直接ロギングされます。

DOMAIN_HOME/servers/server_name/logs/server_name-diagnostic.log

別の管理対象サーバーのログ・ファイルも、Oracle WebLogic Server管理コンソールで使用できます。ログを表示するには、Oracle WebLogic Server管理コンソールhttp://<admin_server_host>:<port>/consoleにアクセスして、「診断」→「ログ・ファイル」をクリックします。

このログの粒度とロギング・プロパティは、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用して変更できます。Fusion Middleware Controlは、ファームのモニターおよび管理に使用できる、Webブラウザベースのグラフィカル・ユーザー・インタフェースです。

Fusion Webアプリケーションが高可用性環境にデプロイされたとき、レベルをFINEに設定すると、高可用性に関する警告診断メッセージを受け取ることがあります。

Fusion Middleware Controlを使用して管理対象サーバーとOracle ADFのログ設定を変更する方法の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

48.7 テストとデバッグのためのOracle ADFモデル・テスターの使用

Oracle ADFモデル・テスター(またはテスターとも呼ばれます)は、ADFビジネス・コンポーネント・データ・モデル・プロジェクトのビジネス・オブジェクトを操作するときにJDeveloperから起動するJavaアプリケーションです。Oracle ADFモデル・テスターはJDeveloper外部で実行し、データ・モデル・プロジェクトのテストと調査のための総合的なUIを提供します。このテスターを実行すると、ADFアプリケーション・モジュールのビュー・インスタンスの調査、ビュー・リンクの階層構造のナビゲート、アプリケーション・モジュールのクライアント・インタフェース、ビュー・オブジェクト・インタフェースおよびビュー行インタフェースからのカスタム・メソッドの実行ができます。テスターをADF宣言デバッガと一緒に使用して、これらのインタフェースのカスタム・メソッドにブレークポイントを設定することもできます。

さらに、テスターではユーザー・インタフェースの多くの機能がシミュレートされます。アプリケーション・モジュールの構成ファイル(bc4j.xcfg)で指定されたデータベースのビジネス・オブジェクトの内容を表示、挿入および更新できます。特に、ビュー・インスタンスのマスター・ディテール関係、ビュー・インスタンスとその属性、ビュー・インスタンスの問合せ結果セット、ビュー基準を使用する検索フォーム、属性値に対して定義される検証規則、LOV(値リスト)定義属性のドロップダウン・リストなど、データ・モデル設計の様々な要素を確認できます。テスターと対話してビジネス・オブジェクトをテストする方法の詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。Oracle ADFモデル・テスターでのテストの詳細は、このマニュアルの「ビジネス・サービスの構築」の部内の章の、各ビジネス・オブジェクト固有の項にも記載されています。

48.7.1 デバッグ・モードでの実行方法およびOracle ADFモデル・テスターでのテスト方法

多くの場合、クライアント・インタフェース実装クラスのサービス・メソッドでカスタム・コードを分析およびデバッグできると便利です。Oracle ADFモデル・テスターを使用すると、ユーザー・インタフェースでアプリケーションを実行せずに、これらができます。デバッグ・プロセスを補完するテスト・ツールとしてOracle ADFモデル・テスターを使用できます。

注意:

デバッグ・モードで実行するOracle ADFモデル・テスターはJDeveloper IDE Javaオプションを継承しません。特定の実行/デバッグJavaオプションがテスターで使用されるようにするには、データ・モデル・プロジェクトに対する実行構成を編集する必要があります。デフォルトの実行構成は、「プロジェクト・プロパティ」ダイアログの「実行/デバッグ」ページで変更できます。

始める前に:

実行時テスト・ツールの使用方法に関する知識が役立つ場合があります。詳細は、「テストとデバッグのためのOracle ADFモデル・テスターの使用」を参照してください。

次のタスクを完了する必要があります。

1. 『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「Javaプロジェクトの実行およびデバッグ」の説明に従って、使用したい実行構成に対する適切なJavaオプションを設定します。

2. 「ADF宣言ブレークポイントの設定」の説明に従い、クライアント・インタフェースのカスタム・メソッドにブレークポイントを設定します。

Oracle ADFモデル・テスターを起動してデバッグ・モードにするには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを右クリックして「デバッグ」を選択します。

2. Oracle ADFモデル・テスターで、「Oracle ADFモデル・テスターを使用したカスタム・サービス・メソッドのテスト方法」の説明に従って、必要なクライアント・インタフェースのメソッド・テスト・パネルを開きます。

3. メソッド・パネルでドロップダウン・リストから必要なメソッドを選択し、メソッドのパラメータとして渡す値を入力して、「実行」をクリックします。

JDeveloperに戻り、ADF宣言デバッガを使用してコードをステップ実行します。メソッドの実行が完了すると、メソッド・パネルに戻り値(ある場合)とテスト結果が表示されます。Oracle ADFモデル・テスターに表示される結果は、メソッドが正常に実行されたかどうかを示します。

48.7.2 Oracle ADFモデル・テスターを実行して特定のアプリケーション・モジュール構成を使用してテストする方法

「アプリケーション」ウィンドウでアプリケーション・モジュールを右クリックし、「実行」または「デバッグ」を選択すると、JDeveloperがアプリケーション・モジュールに定義されるデフォルト構成を使用してOracle ADFモデル・テスターを実行します。ビジネス・コンポーネントを別のアプリケーション・モジュール構成(異なるデータソースおよび独自のランタイム・パラメータのセットを指定できる)でテストする場合は、bc4j.xcfgファイルの概要エディタで行うことができます。このファイルは「アプリケーション」ウィンドウには表示されず、アプリケーション・モジュールの概要エディタの「構成」ページからのみアクセスできます。

特定のアプリケーション・モジュール構成を使用してOracle ADFモデル・テスターを実行するには:

1. 「アプリケーション」ウィンドウで、テストするアプリケーション・モジュールをダブルクリックします。

2. 概要エディタで「構成」ナビゲーション・タブをクリックして、「bc4j.xcfg」構成ファイル・リンクをクリックします。

3. 概要エディタで、「構成」リストから構成を選択します。

4. 選択した構成を右クリックして、「実行」または「デバッグ」を選択し、Oracle ADFモデル・テスターを起動します。

48.7.3 デバッグ・モードでOracle ADFモデル・テスター実行時の処理

Oracle ADFモデル・テスターは他のJavaプログラムと同じように動作します。具体的には、JDeveloper IDEに対して指定されたJavaオプションは継承しません。テスターはデータ・モデル・プロジェクトに対して指定された実行構成およびその構成内に設定されたJavaオプションをかわりに使用します。

JDeveloperではOracle ADFモデル・テスターを2つのモード(デバッグ・モードまたは非デバッグ・モード)で実行できます。テスターをデバッグ・モードで実行すると、ADF宣言デバッガと連動して、クライアント・インタフェースのカスタムJavaコードおよびGroovyスクリプトに挿入したブレークポイントを使用してカスタム・メソッドを実行します。たとえば、クライアント・インタフェースでメソッドにブレークポイントを設定し、そのメソッドをテスターでデバッグ・モードで実行すると、コードをステップ実行できます。その後、テスターによって成功または失敗の結果が返されます。非デバッグ・モードでは、テスターは、メソッドが正常に実行されたかどうかを示す結果をすぐに返します。また、テスターは、デバッグ・モードでも非デバッグ・モードでも、アプリケーション・モジュールに対して実行時に作成されたシステム・カタログの実行時アーティファクトを表示できます。

48.7.4 Oracle ADFモデル・テスターで実行時アーティファクトを確認する方法

Oracle ADFモデル・テスターを実行するが、ADF宣言デバッガを使用する必要がない場合は、実行時アーティファクトの情報をアプリケーション・モジュールのシステム・カタログから表示できます。システム・カタログによってビジネス・オブジェクト・メタデータとその他の情報が表示されます。これはビジネス・オブジェクトを比較する必要があるときに役立ちます。

デバッグせずにOracle ADFモデル・テスターを起動するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールを右クリックして、「実行」を選択します。

2. Oracle ADFモデル・テスターで、「作成」→SysCat AMの作成を選択します。

3. データ・モデル・ツリーで「SysCatAMDefs」を展開し、「ViewDefs」を右クリックして、「表の表示」を選択します。

4. データ・ビューアで縦方向にスクロールし、必要なビュー・インスタンスを「SCName」(システム・カタログ名)フィールドで確認します。

テスターでシステム・カタログを公開すると、デバッガを実行せずに、ランタイム・オブジェクト固有のメタデータおよびその他の情報にアクセスできます。たとえば、ビュー・インスタンスにカスタムJava実装クラスがあるかどうかをチェックできます。

48.7.5 アプリケーションの変更内容でOracle ADFモデル・テスターをリフレッシュする方法

Oracle ADFモデル・テスターは、非常に対話型のツールです。テスターを実行しているときに、データ・モデル・プロジェクトの変更が必要であるとわかると、JDeveloperに戻って必要なアプリケーション・モジュール・インスタンスを編集し、変更内容を表示するようにOracle ADFモデル・テスターのデータ・モデルをリフレッシュできます。このように、変更内容を確認するためにテスターを再実行する必要はありません。

Oracle ADFモデル・テスターにアプリケーション・メタデータを再ロードするには:

1. データ・モデル・プロジェクトでビジネス・オブジェクトを編集し、変更内容をJDeveloperに保存します。

2. データ・モデル・プロジェクトを再コンパイルします。

たとえば、「アプリケーション」ウィンドウでデータ・モデル・プロジェクトを右クリックし、「メイク」を選択して再コンパイル・ステップを完了します。

メタデータに対して行う変更とプロジェクトのコンパイルに関連性はありませんが、メタデータをクラス・パスにコピーし、Oracle ADFモデル・テスターでリロードできるようにするには、コンパイル手順を実行する必要があります。

3. Oracle ADFモデル・テスターのツールバーで、アプリケーション・メタデータの再ロードをクリックします。

また、Oracle ADFモデル・テスターの「ファイル」メニューから、「アプリケーションのリロード」を選択してもかまいません。

48.8 ADF宣言デバッガの使用

ADF宣言デバッガで提供される宣言ブレークポイントは、カスタムJavaコードおよびGroovyスクリプトの標準ブレークポイントと同様に、ADFオブジェクト・レベル(タスク・フロー、ページ定義実行可能ファイル、メソッドとアクションのバインディング、ADFライフサイクル・フェーズなど)に設定できます。ADF宣言ブレークポイントにより、ADFアプリケーションをデバッグするために概要レベルのオブジェクト・ビューが提供されます。たとえば、図48-11のようにタスク・フロー・アクティビティの前にブレークすると、タスク・フローに渡されるパラメータを確認できます。Javaブレークポイントだけを使用して同じ機能を実行するには、ブレークポイントを設定するクラスまたはメソッドを認識する必要があります。ADFアプリケーションではADF宣言ブレークポイントを使用することをお薦めします。

図48-11 タスク・フロー・アクティビティでのADF宣言ブレークポイント

ADF宣言デバッガも、標準のJavaコード・ブレークポイントをサポートします。どのADFアプリケーションにもJavaコード・ブレークポイントを設定できます。ADF宣言ブレークポイントが必要な場所でブレークしないとき、場合によってはJavaコード・ブレークポイントを使用できます。

ADF宣言デバッガはJavaデバッガ上に構築されているので、機能と動作はJavaデバッガと同様です。ただ、Javaのクラスやメソッドを知らなくても、ビジュアル・エディタでADF宣言ブレークポイントを設定することができます。

ADF宣言デバッガでは、変数やスタック・データの調査など標準デバッグ機能が提供されます。アプリケーションが任意のブレークポイント(ADF宣言ブレークポイントまたはJavaコード・ブレークポイント)で一時停止するときに、様々なウィンドウを使用してアプリケーションのステータスを調べることができます。「ブレークポイント」ウィンドウで、ブレークが発生した箇所を確認することができます。「スタック」ウィンドウを使用して、現在のスレッドのコール・スタックを確認することができます。「スタック」ウィンドウで行を選択すると、「データ」ウィンドウ、「監視」ウィンドウおよびすべての「インスペクタ」ウィンドウが更新され、関連データが表示されます。「データ」ウィンドウを使用すると、アプリケーションの引数、ローカル変数および静的フィールドを表示できます。

「ADF構造」ウィンドウには、プロジェクトの実行時構造が表示されます。「ADFデータ」ウィンドウでは、「ADF構造」ウィンドウの選択内容に基づいて、表示する情報が自動的に変更されます。たとえば、タスク・フロー・ノードが選択されている場合は、図48-12に示すように、ADFデータ・ウィンドウにはタスク・フローに関連したデバッグ情報が表示されます。

図48-12 タスク・フロー選択時の「ADF構造」ウィンドウとADFデータ・ウィンドウ

デバッグ・セッションでは、必要に応じてADF宣言ブレークポイントと標準のJavaおよびGroovyブレークポイントを混用することができます。ステップ機能を使用すると、あるJavaコード・ブレークポイントから別のJavaコード・ブレークポイントにアプリケーションを進めることができますが、ADF宣言ブレークポイントのステップ機能には、より多くの制約と制限事項があります。ADF宣言ブレークポイントでのステップ機能の使用の詳細は、表48-3を参照してください。

ADF宣言ブレークポイントの使用方法の詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

クラスとメソッドでのJavaブレークポイントの使用方法の詳細は、「JavaコードとGroovyスクリプトのブレークポイントの設定」を参照してください。

JSFアプリケーション(Fusion Webアプリケーションを含む)で、ブレークポイントでブレークしたとき、ELエバリュエータを使用してEL式の値を調べることができます。ELエバリュエータには、評価する正しい式の選択を支援するブラウズ機能があります。詳細は、「EL式エバリュエータの使用」を参照してください。

ADF宣言ブレークポイントと標準のJavaおよびGroovyブレークポイントのどちらを使用するかをあらかじめ決めておかなくても、Oracle ADFソース・コードに対してADF宣言デバッガを使用できます。Oracle ADFソース・コードはデバッグ・ライブラリで入手できます。ソース・コードのロード方法の詳細は、「デバッガでのADFソース・コードの使用」を参照してください。

48.8.1 デバッガでのADFソース・コードの使用

有効なOracle ADFサポートがある場合、Oracle Worldwide Supportでサービス・リクエストをオープンし、Oracle ADFの完全なソース・コードを取得できます。Oracle ADFのソース・コードは、特定のバージョンのものをリクエストできます。ソース・コードのZIPファイルを復号化するためのダウンロードおよびパスワード情報が与えられます。詳細は、Oracle Worldwide Supportに問い合せてください。

アプリケーションのデバッグ・セッションにOracle ADFソース・コードへのアクセスを追加すると、次のことが可能になります。

- ソース・エディタ内でJDeveloper Quick Javadoc機能にアクセスできます。ソース・コードがない場合は、標準のJavadocのみの使用となります。

- Javaコード・ブレークポイントは、ブレークポイントに到達したときに実行されているOracleソース・コードを表示するためにも使用できます。ブレークするソース・コード行の余白をクリックすることで、ブレークポイントをより簡単に設定することもできます。ソース・コードがない場合、Oracleコード内にブレークポイントを設定するには、クラス、メソッド、または行番号を調べる必要があります。

- ソース・コード内に設定されたJavaコード・ブレークポイントの場合は、デバッガですべてのローカル変数およびメンバー・フィールドの値を表示できます。

ADFソース・コードのZIPファイルは、出荷の際にはコンテンツ保護のために暗号化された外部ZIP内に置かれます。外部ZIPファイルの名前は、サービス・リクエスト番号のバリアントであることがあります。

外部ZIPアーカイブ・ファイルの受信またはダウンロード後は、供給されるパスワードを使用して解凍し、実際のソース・コードのZIPファイルにアクセスします。ADFソース・コードのZIPファイル名は、Oracle ADFバージョン番号およびビルド番号のバリアントである必要があります。たとえば、Oracle ADFのソースZIPファイルは、adf_vvvv_nnnn_source.zipのような形式であり、ここでvvvvはバージョン番号、nnnnはビルド番号を示しています。

Oracle ADFソース・コードのZIPファイルにアクセスし、次にそのコンテンツを作業ディレクトリに解凍します。

48.8.2 ADFソース・ユーザー・ライブラリの設定方法

ソース・ユーザー・ライブラリの名前を作成し、それをソースZIPファイルに関連付けます。

ADFソースZIPファイルをユーザー・ライブラリに追加するには:

1. メイン・メニューで、「ツール」、「ライブラリの管理」を選択します。

2. 「ライブラリの管理」ダイアログの「ライブラリ」タブを選択した状態で、「新規」をクリックします。

3. 「ライブラリの作成」ウィンドウで、ライブラリのタイプを識別する、ソース用のライブラリ名を入力します。

4. ツリー構造の「ソースパス」ノードを選択します。「エントリの追加」をクリックします。

注意:

クラス・パスの値は入力しないでください。ソース・パスの値のみ指定する必要があります。

5. 「パス・エントリの選択」ウィンドウで、ファイルが解凍されたディレクトリを参照し、ソースZIPファイルを選択します。「選択」をクリックします。

6. 「ライブラリの作成」ウィンドウで、ソース・パスのエントリにソースZIPファイルの正しいパスが入力されていることを確認し、「デフォルトでデプロイ済」の選択を解除します。「OK」をクリックします。

7. 「OK」をクリックします。

48.8.3 ADFソース・ライブラリのプロジェクトへの追加方法

使用可能なユーザー・ライブラリのリストへソース・ライブラリを追加した後、デバッグするプロジェクトにソース・ライブラリを追加します。

ADFソースZIPファイルをプロジェクトに追加するには:

1. 「アプリケーション」ウィンドウで、ADFライブラリを追加するプロジェクトをダブルクリックするか、プロジェクトを右クリックして「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」を選択します。

3. 「ライブラリの追加」をクリックします。

4. 「ライブラリの追加」ダイアログの「ユーザー」ノードで、追加するソース・ライブラリを選択して「OK」をクリックします。

ソース・ライブラリが「プロジェクト・プロパティ」ダイアログの「クラスパス・エントリ」セクションに表示されます。

5. 「OK」をクリックします。

48.8.4 EL式エバリュエータの使用

アプリケーションがブレークポイントで一時停止したら、EL式エバリュエータを使用して、評価するEL式を入力します。評価するEL式は、現在のコンテキストの範囲内で任意に入力することができます。EL式が現在のコンテキストの範囲に収まらない場合、値はnullと評価されます。

ELエバリュエータは、後続のデバッグ手順で停止されるときでなく、ブレークポイントで停止されるときにのみEL評価が発生する点で、「監視」ウィンドウと異なります。

ELエバリュエータは、あらゆるJSFアプリケーションのデバッグで利用できます。

注意:

EL式を評価するときは、アプリケーションのデータ、つまりアプリケーションの動作を間接的に変更しないように注意してください。たとえば、#{foo.bar}を評価する場合、対応するgetBar()メソッドによってアプリケーション・データが変更されます。

始める前に:

ADF宣言デバッガに関する知識が役立つ場合があります。詳細は、「ADF宣言デバッガの使用」を参照してください。

次のタスクを完了する必要があります。

- 「ADF宣言ブレークポイントの設定」の説明に従い、アプリケーションで必要なブレークポイントを設定します。アプリケーションは、JSFアプリケーションである必要があります。ADFアプリケーションである必要はありません。

ELエバリュエータを使用するには:

1. 次のいずれかの方法で、デバッグ・プロセスを開始します。

- メイン・メニューで、「実行」→「<project_name>のデバッグ」を選択します。

- 「アプリケーション」ウィンドウで、プロジェクト、adfc-config.xml、タスク・フローまたはページを右クリックし、「デバッグ」を選択します。

- タスク・フロー・ダイアグラマで、アクティビティを右クリックして、「デバッグ」を選択します。ページ・フラグメントを使用しないタスク・フローのみを実行できます。

2. ブレークポイントに到達すると、ELエバリュエータは、デバッガ・ウィンドウ領域にタブとして表示されます。「ELエバリュエータ」タブをクリックして前面に移動します。表示されない場合は、メイン・メニューで「ウィンドウ」を選択して、「デバッガ」→「ELエバリュエータ」を選択します。

注意:

「ブレークポイント」ウィンドウを確認するか、オブジェクトのブレークポイントの隣に「実行ポイント」アイコン(赤い右矢印)が表示されていることを確認することによって、アプリケーションが実際にブレークポイントをヒットしていることを確認してください。ブレークポイントの設定箇所によっては、アプリケーションが実際にはページ上でのユーザー入力を待機しているのに、停止しているように見えることがあります。

3. 「式」入力フィールドにEL式を入力します。

フィールドをクリックして#{またはピリオドを入力すると、図48-13に示すように、入力支援機能によって選択可能な式項目のリストが表示されます。自動的に補完されるため入力が簡単です。セミコロンで区切ることによって、複数のEL式を同時に評価することができます。

図48-13 ELエバリュエータの入力支援機能の使用

4. EL式の入力を完了したら、「式の評価」をクリックすると、式が評価されます。図48-14を参照してください。

図48-14 EL式の評価

48.8.5 スタック・トレース情報を表示およびエクスポートする方法

通常、問題を判断できず、自分で解決できない場合には、他の人に支援を求めます。OTN JDeveloper Discussion Forumに質問を投稿する場合、またはMetalinkでサービス・リクエストをオープンする場合、支援しようとしている他のユーザーが問題の発生箇所を正確に理解するためには、スタック・トレース情報を投稿内容に含めることが非常に重要です。

JDeveloperの「スタック」ウィンドウを使用すると、この情報を伝えるときに役立ちます。デバッガが一時停止したときは常に、「スタック」ウィンドウで、現在行までのメソッド・コールのスタックとしてプログラム・フローを確認できます。「プリファレンス」ダイアログを使用して、「スタック」ウィンドウのプリファレンスを設定し、デフォルトで組み込まれているクラスやメソッドの名前のように、行番号情報を組み込むことができます。最後に、「スタック」ウィンドウのポップアップ・メニュー・オプション「エクスポート」を使用すると、現在のスタック情報を外部テキスト・ファイルに保存できます。その後、問題の診断を支援してくれる人にファイルの内容を投稿または送信できます。

始める前に:

ADF宣言デバッガに関する知識が役立つ場合があります。詳細は、「ADF宣言デバッガの使用」を参照してください。

次のタスクを完了する必要があります。

- 「ADF宣言ブレークポイントの設定」の説明に従い、アプリケーションで必要なブレークポイントを設定します。アプリケーションは、JSFアプリケーションである必要があります。ADFアプリケーションである必要はありません。

スタック情報をテキスト・ファイルに保存するには:

1. 次のいずれかの方法で、デバッグ・プロセスを開始します。

- メイン・メニューで、「実行」→「<project_name>のデバッグ」を選択します。

- 「アプリケーション」ウィンドウで、プロジェクト、adfc-config.xml、タスク・フローまたはページを右クリックし、「デバッグ」を選択します。

- タスク・フロー・ダイアグラマで、アクティビティを右クリックして、「デバッグ」を選択します。ページ・フラグメントを使用しないタスク・フローのみを実行できます。

2. ブレークポイントに到達してデバッガが一時停止すると、「スタック」ウィンドウが、デバッガ・ウィンドウ領域側にウィンドウとして表示されます。「スタック」タブをクリックして、前面に表示します。「スタック」ウィンドウが表示されない場合は、メイン・メニューで「ウィンドウ」を選択して、「デバッガ」→「スタック」を選択します。

3. たとえばエクスポート・ファイルに行番号情報を組み込むなど、「スタック」ウィンドウのプリファレンスを変更する場合は「スタック」ウィンドウの背景を右クリックして、「プリファレンス」を選択します(図48-15)。

図48-15 「スタック」ウィンドウのポップアップ・メニュー

4. 「スタック」ウィンドウの背景を右クリックして「エクスポート」を選択します。

5. スタックのエクスポート・ダイアログで、ファイルに名前を付けて、ファイルの保存場所を選択します。「OK」をクリックします。

48.9 ADF宣言ブレークポイントの設定

ADFタスク・フロー・アクティビティ、ページ定義実行可能ファイル、メソッド、アクションおよび値のバインディング、ADFライフサイクル・フェーズ、コンテキスト・イベント上でブレークポイントを宣言的に設定するには、JDeveloperでADF宣言デバッガ機能を使用します。メソッド名とクラス名などのADFコードのすべての内部構造体を知らなくても、最高抽象レベルでオブジェクトにブレークポイントを設定することができます。

タスク・フロー・ダイアグラマでタスク・フロー・アクティビティにブレークポイントを追加できます。あるいは、「ブレークポイント」ウィンドウでADFタスク・フロー・アクティビティ・ブレークポイントの作成ダイアログを起動できます。タスク・フロー・ダイアグラマでタスク・フロー・アクティビティを選択し、ポップアップ・メニューを使用してそのアクティビティのブレークポイントの有効/無効を切り替えるか、[F5]キーを押します。アプリケーションがブレークポイントで停止すると、「ADF構造」ウィンドウに、オブジェクトの実行時構造がツリー構造で表示されます。「ADFデータ」ウィンドウには、「ADF構造」ウィンドウで選択されたオブジェクトのデータのリストが表示されます。

たとえば、Browse Ordersタスク・フローのタスク・フロー・コール・アクティビティにブレークポイントを設定すると、図48-16に示すように、コール・アクティビティに赤い点のアイコンが表示されます。

図48-16 タスク・フロー・アクティビティでのADF宣言ブレークポイント

ブレークポイントに到達すると、図48-17に示すように、アプリケーションが一時停止され、アイコンが変化します。

図48-17 ADF宣言ブレークポイントで一時停止したアプリケーション

同様に、ページ定義ファイルでBeforeブレークポイントとAfterブレークポイントを設定することができます。項目の横の左余白または右余白をクリックするかまたはポップアップ・メニューから選択して、サポートされる値バインディング(サポートされる値バインディングのリストについては表48-1を参照)および実行可能ファイルに対してブレークポイントを設定します。左余白をクリックするとBeforeページ定義ブレークポイントが追加され、右余白をクリックするとAfterページ定義ブレークポイントが追加されます。この場合も、図48-18に示すように、ブレークポイントを示す赤い点アイコンが設定されます。

図48-18 ページ定義ファイルのADFバインディングのADF宣言ブレークポイント

ページ定義ファイルでも、図48-19に示すように、ページまたはページ内のリージョンによって実行時に発生するコンテキスト・イベントにブレークポイントを設定できます。

図48-19 ページ定義ファイルのコンテキスト・イベントのADF宣言ブレークポイント

すべてのADFライフサイクル・フェーズにもBeforeブレークポイントとAfterブレークポイントを設定できます。図48-20に示すようにブレークポイント・ウィンドウでADFライフサイクル・フェーズ・ブレークポイントの作成ダイアログを起動できます。

図48-20 ブレークポイント・ウィンドウの「ブレークポイントの追加」アイコンのドロップダウン・メニュー

ADFライフサイクル・フェーズ・ブレークポイントの作成ダイアログでは、様々なライフサイクル・ブレークポイントのオプションを選択できます(図48-21)。

図48-21 ADFライフサイクル・フェーズ・ブレークポイントの作成ダイアログ

または、「ADF構造」ウィンドウの「ADFライフサイクル・ブレークポイント」ダイアログまたはタスク・フロー・ダイアグラマを使用して、ADFライフサイクル・フェーズ・ブレークポイントを設定します。ADFライフサイクル・フェーズの詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。

ADF宣言デバッガを使用する場合、ADF宣言ブレークポイントとJavaコード・ブレークポイントの両方を定義することができます。デバッグ・シナリオによっては、宣言ブレークポイントのみを設定すればアプリケーションをデバッグできることもあります。あるいは、宣言的でないJavaコードで追加のブレークポイントを追加する必要が生じることもあります。Javaコード・ブレークポイントの詳細は、「クラスおよびメソッド上にJavaブレークポイントを設定する方法」を参照してください。表48-1に、使用可能なADF宣言デバッガ・ブレークポイントの場所をリストします。

表48-1 ADF宣言デバッガ・ブレークポイント

ADF面

ブレークポイント型

挿入場所

JDeveloperポップアップ・メニュー・コマンド

説明

ADFライフサイクル・フェーズ

ADFライフサイクル・フェーズの前

ADFライフサイクル・フェーズの後にブレーク

「ADF構造」ウィンドウの「ADFライフサイクル・ブレークポイント」ツールバー・ボタン

タスク・フロー・ダイアグラマ

「ブレークポイント」ウィンドウの「追加」ボタン

BeforeブレークポイントはADFライフサイクル・フェーズの前にデバッグを一時停止します。

AfterブレークポイントはADFライフサイクル・フェーズの後でデバッグを一時停止します。

ADFライフサイクルのJSFレスポンス・レンダリング・フェーズとレンダリング準備フェーズのBeforeブレークポイントとAfterブレークポイントは、次の順序で実行されます。

- jsfRenderResponseの前。

- prepareRenderの前。(prepareRenderフェーズが実行します)。

- prepareRenderの後。(jsfRenderResponseフェーズが実行します)。

- jsfRenderResponseの後。

ADFページ定義 - バインディングおよび実行可能ファイル

実行可能ファイルの前/後にブレーク:

- イテレータ

- リージョンのインスタンス化

ページ定義の概要エディタの「バインディングと実行可能ファイル」タブ、「実行可能ファイル」セクション

「ブレークポイント」ウィンドウの「追加」ボタン

「ブレークポイントの設定」または[F5]

ブレークポイントの無効化

実行可能ファイルがリフレッシュする前または後にデバッグを一時停止します。タスク・フロー・バインディングの場合、1ライフサイクルにつき2回あり、最初はprepareModel(初期リージョン作成)、2回目はprepareRender(動的リージョンにより、対応するリージョンのタスク・フローIDが入れ替えられる)。

アクション・バインディングの前/後にブレーク:

- methodAction

- ビルトイン操作

ページ定義の概要エディタの「バインディングと実行可能ファイル」タブ、「バインディング」セクション

「ブレークポイント」ウィンドウの「追加」ボタン

「ブレークポイントの設定」または[F5]

ブレークポイントの無効化

バインディングが実行される前または後にデバッグを一時停止します。

属性値バインディングの前/後にブレーク

ページ定義の概要エディタの「バインディングと実行可能ファイル」タブ、「バインディング」セクション

「ブレークポイント」ウィンドウの「追加」ボタン

「ブレークポイントの設定」または[F5]

ブレークポイントの無効化

属性のsetInputValue() ADFソース・コード・メソッドが実行される前または後にデバッグを一時停止します。新しい値は、setInputValue()へのパラメータとなる。

表バインディングの前/後にブレーク

ページ定義の概要エディタの「バインディングと実行可能ファイル」タブ、「バインディング」セクション

「ブレークポイント」ウィンドウの「追加」ボタン

「ブレークポイントの設定」または[F5]

ブレークポイントの無効化

ADF階層バインディングのupdateValuesFromRows()ソース・コード・メソッドが実行される前または後にデバッグを一時停止します。新しい値は、updateValuesFromRows()へのパラメータとなる。

ツリー・バインディングの前/後にブレーク

ページ定義の概要エディタの「バインディングと実行可能ファイル」タブ、「バインディング」セクション

「ブレークポイント」ウィンドウの「追加」ボタン

「ブレークポイントの設定」または[F5]

ブレークポイントの無効化

次の2つのケースのいずれかで一時停止します。

1. ツリーでノードの選択を実行している場合、ADF階層バインディングのupdateValuesFromRows()ソース・コード・メソッドが実行される前または後にデバッグを一時停止します。新しい値は、updateValuesFromRows()へのパラメータとなる。

2. ツリーを開いている場合、ADFツリー・コレクション・モデルのmodifyExpanded()ソース・コード・メソッドが実行される前または後にデバッグを一時停止します。

ADFページ定義 - コンテキスト・イベント

コンテキスト・イベントの前/後にブレーク

ページ定義の概要エディタの「コンテキスト・イベント」タブ、「イベント」セクション

「ブレークポイント」ウィンドウの「追加」ボタン

「ブレークポイントの設定」または[F5]

ブレークポイントの無効化

イベントがディスパッチされる前またはイベントの後に、イベントのサブスクライバによってイベントが使用される直前にデバッグを一時停止します。

ADFタスク・フロー

アクティビティの前にブレーク

タスク・フロー・ダイアグラマ

「ブレークポイント」ウィンドウの「追加」ボタン

「ブレークポイントの設定」または[F5]

ブレークポイントの無効化

JSFアプリケーション起動フェーズ内でアクティビティが実行する前にデバッグを一時停止します。宣言ブレークポイントが定義されているアクティビティは未実行です。例外はビュー・アクティビティです。ビュー・アクティビティが実行された後で、新しいページがレンダリングする前に、JSFレスポンス・レンダリング・フェーズ内で一時停止します。このポイントで一時停止することにより、「ADF構造」ウィンドウと「ADFデータ」ウィンドウを使用してビュー・アクティビティ値を検査できます。

ADF宣言デバッガは、ADF宣言ブレークポイントのステータスの設定、切り替えおよび表示のために、標準デバッガのアイコンと表記法を使用します。

設定されたADF宣言ブレークポイントは、図48-22、図48-23、図48-24および図48-25に示すように、タスク・フロー・アクティビティ、ページ定義のブレークポイント余白、「ADFライフサイクル・ブレークポイント」ウィンドウに、赤い点のアイコンとして表示されます。

図48-22 タスク・フロー・アクティビティ上で有効化されたADF宣言ブレークポイント

図48-23 ページ定義実行可能ファイルで有効化されたADF宣言ブレークポイント

図48-24 ページ定義ファイルのコンテキスト・イベントの有効化されたADF宣言ブレークポイント

図48-25 ADFライフサイクル・ブレークポイント・ウィンドウで有効化されたADFライフサイクル・フェーズ・ブレークポイント

ADFタスク・フローまたはページ定義の宣言ブレークポイントを無効にすると、図48-26に示すように、赤いアイコンがグレーのアイコンになります。

図48-26 無効化されたADF宣言ブレークポイント

アクティブなADFタスク・フロー宣言ブレークポイントでは、図48-27に示すように、赤いアイコンに緑のチェックマークが付きます。

図48-27 アクティブなADF宣言ブレークポイント

アプリケーションがADF宣言ブレークポイントで一時停止すると、図48-28に示すように、実行ポイントのアイコンが表示されます。

図48-28 タスク・フローの実行ポイントで一時停止したアプリケーション

アプリケーションがADFライフサイクル宣言ブレークポイントで一時停止すると、図48-29に示すように、「ADFライフサイクル・ブレークポイント」ウィンドウのライフサイクル・フェーズの横に実行ポイントのアイコンが表示されます。現在のADFライフサイクル・フェーズの名前は「ADF構造」ウィンドウにも表示されます。

図48-29 ADFライフサイクル・フェーズの実行ポイントで一時停止したアプリケーション

ブレークポイント・ウィンドウには、ADF宣言ブレークポイントを含むすべてのブレークポイントが表示されます(図48-30)。

図48-30 ブレークポイント・ウィンドウでのADF宣言ブレークポイントとJavaコード・ブレークポイントの表示

ブレークポイント・ウィンドウのツールバーには、図48-30に示すようにブレークポイントの追加、編集、削除、有効化、無効化のためのボタンが含まれます。「ブレークポイントの追加」アイコン・ドロップダウン・メニューには、ADFコンテキスト・イベント・ブレークポイント、ADFライフサイクル・フェーズ・ブレークポイント、ADFページ定義ブレークポイント(ADFバインディングおよび実行可能ファイル用)、ADFタスク・フロー・アクティビティ・ブレークポイントおよび標準Javaコード・ブレークポイントの作成および管理を行う機能があります。

「ブレークポイント」ウィンドウを使用して、対応するソース・ファイル内のADF宣言ブレークポイントの場所を表示できます。

- コンテキスト・イベント・ブレークポイントをダブルクリックし、対応するページ定義ファイルの概要エディタを開きます。次に「コンテキスト・イベント」タブをクリックして、ブレークポイントの場所を表示できます。

- ADFライフサイクル・フェーズ・ブレークポイントをダブルクリックし、すべてのADFライフサイクル実行ポイントを表示する「ADFライフサイクル・ブレークポイント」ウィンドウを開きます。

- タスク・フロー・アクティビティ・ブレークポイントをダブルクリックし、対応するタスク・フローのタスク・フロー・ダイアグラマを開きます。

- ADFバインディング・ブレークポイントをダブルクリックし、対応するページ定義ファイルの概要エディタを開きます。

デバッガがブレークポイントを処理する方法を管理するために、「ブレークポイント」ウィンドウに表示される個々のブレークポイントの「ADFブレークポイントの編集」を開くことができます。または、複数のADF宣言ブレークポイントを選択し、共通フィールドの動作をカスタマイズできます。

表48-2に、「ブレークポイント」ウィンドウの「説明」列や「タイプ」列に表示されるADF宣言ブレークポイントを示します。

表48-2 「ブレークポイント」ウィンドウでのADF宣言ブレークポイントの表示

宣言ブレークポイントの型

「説明」列

「タイプ」列

コンテキスト・イベントの前/後

ページ定義@イベント名の前

ページ定義@イベント名の後

コンテキスト・イベント・ブレークポイント

ADFライフサイクル・フェーズの前

adfライフサイクル・フェーズの前

ADFライフサイクル・フェーズ・ブレークポイント

ADFライフサイクル・フェーズの後

adfライフサイクル・フェーズの後

ADFライフサイクル・フェーズ・ブレークポイント

ページ定義実行可能ファイルの前/後:

- イテレータ

page definition@executable idの前

ページ定義@実行可能ファイルidの後

ページ定義実行可能ファイル・ブレークポイントの前

ページ定義アクション・バインディングの前/後:

- methodAction

- ビルトイン操作

page definition@binding idの前

ページ定義@バインディングidの後

ページ定義バインディング・ブレークポイントの前

ページ定義属性値バインディングの前/後

page definition@binding idの前

ページ定義@バインディングidの後

ページ定義バインディング・ブレークポイントの前

ページ定義表バインディングの前/後

page definition@binding idの前

ページ定義@バインディングidの後

ページ定義バインディング・ブレークポイントの前

ページ定義ツリー・バインディングの前/後

page definition@binding idの前

ページ定義@バインディングidの後

ページ定義バインディング・ブレークポイントの前

ADFタスク・フロー・アクティビティの前

task flow document#task flow id@activity idの前

タスク・フロー・アクティビティ・ブレークポイント

表48-3に、ADF宣言ブレークポイントとともに使用できるステップ・コマンドをリストします。

表48-3 ADF宣言デバッガのステップ・コマンド

ADFデバッガのステップ・コマンド

説明

実行ポイントの検索

宣言ブレークポイントで、開いておりアクティブな現在の実行ポイントを対応するエディタに表示できるようにする。

ステップ実行([F8])

タスク・フロー・アクティビティ宣言ブレークポイントで、タスク・フロー内でアクティビティからアクティビティにステップできるようにする。ユーザーとの対話処理が必要とされる場合(ページが表示される場合など)、これを受け取ると(ボタンが選択された場合など)処理を再開し、次のタスク・フロー・アクティビティの前で一時停止する。

ページ定義実行可能ファイルのブレークポイントに対応します。アプリケーションが、次のページ定義実行可能ファイル・ブレークポイントにステップします。

ADFライフサイクル・フェーズ宣言ブレークポイントが、ADFライフサイクル・フェーズの次のBeforeまたはAfterの位置にステップできるようにします。

トレース実行([F7])

タスク・フロー・コール・アクティビティ上で定義されているタスク・フロー・アクティビティ宣言ブレークポイントでのみ使用できます。タスク・フロー・アクティビティ宣言ブレークポイントは、アクティビティの実行直前でアプリケーションを一時停止します。トレース実行機能では、コールされたタスク・フローのデフォルト・アクティビティを実行する直前でデバッグを一時停止できます。このアクションは、コールされたタスク・フローのデフォルトのアクティビティ上に、タスク・フロー・アクティビティ宣言ブレークポイントを配置することと同じである。

ステップ・アウト([Shift]+[F7])

タスク・フロー・アクティビティ宣言ブレークポイントで、現在コールされているタスク・フローからステップ・アウトして、コール元(存在する場合)へ戻すことができるようにする。ユーザーとの対話処理が必要とされる場合(ページが表示される場合など)、ユーザーとの対話処理を受け取ると(ボタンが選択された場合など)処理を再開し、コール元タスク・フロー内の、次のユーザーとの対話処理またはアクティビティの前で一時停止する。

ステップ続行([Shift]+[F8])

宣言ブレークポイントではサポートされない。

メソッドの最後まで実行

宣言ブレークポイントではサポートされない。

カーソルまで実行

宣言ブレークポイントではサポートされない。

フレームに戻る

Javaコード用であるため、宣言ブレークポイントでは使用できません。前の実行ポイントに戻ることはできません。

48.9.1 タスク・フロー・アクティビティ・ブレークポイントの設定方法および使用方法

タスク・フローチャートの作成後は、タスク・フロー・アクティビティ上にADF宣言ブレークポイントを設定することができます。

始める前に:

ADF宣言ブレークポイントについて理解しておくと役立ちます。詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

タスク・フロー・アクティビティ上にブレークポイントを設定するには:

1. タスク・フロー・ダイアグラマでタスク・フローを開くか、「ブレークポイント」ウィンドウで「追加」アイコンをクリックし、「ADFタスク・フロー・アクティビティ・ブレークポイント」を選択します。
「ブレークポイント」ウィンドウが表示されていない場合は、メイン・メニューで、「ウィンドウ」→「ブレークポイント」を選択します。

2. タスク・フロー・アクティビティ・ブレークポイントを設定します。

- タスク・フロー・ダイアグラマを使用する場合は、右クリックしてポップアップ・メニューから「ブレークポイントの設定」を選択するか、[F5]を押します。
タスク・フロー・アクティビティ上にブレークポイント・アイコンが表示されます。

- 「ブレークポイント」ウィンドウでADFタスク・フロー・アクティビティ・ブレークポイントの作成ダイアログを起動した場合は、「参照」をクリックしてタスク・フロー定義を選択し、「タスク・フロー」ドロップダウン・リストからタスク・フローを選択し、「アクティビティ」ドロップダウン・リストからタスク・フロー・アクティビティを選択し、「OK」をクリックします。

3. 必要に応じて、次のようにデバッガを管理するためのブレークポイントの設定を構成します。

a. メイン・メニューで、「ウィンドウ」→「ブレークポイント」を選択します。

b. 「ブレークポイント」ウィンドウで、構成するタスク・フロー・アクティビティ・ブレークポイントを選択し、「編集」アイコンをクリックします。

c. ADFタスク・フロー・アクティビティ・ブレークポイントの編集ダイアログで「条件」タブをクリックし、ブレークポイントに適用する条件を指定します。条件が有効な場合のみブレークポイントが発生します。

d. 「アクション」タブをクリックし、ブレークポイントが発生したときにデバッガで行うアクションを指定して、「OK」をクリックします。
たとえば、ブレークポイントの通常の処理では、デバッグ中のプログラムを停止しますが、プログラムを停止せずにビープ音を鳴らし、ログ・ウィンドウにログ情報を記録することもできます。

4. 次のいずれかの方法で、デバッグ・プロセスを開始します。

- メイン・メニューで、「実行」→「<project_name>のデバッグ」を選択します。

- 「アプリケーション」ウィンドウで、プロジェクト、adfc-config.xml、タスク・フローまたはページを右クリックし、「デバッグ」を選択します。

- タスク・フロー・ダイアグラマで、アクティビティを右クリックして、「デバッグ」を選択します。ページ・フラグメントを使用しないタスク・フローのみを実行できます。

5. アプリケーションがブレークポイントで一時停止されると、タスク・フロー・アクティビティ上のブレークポイント・アイコンの隣に「実行ポイント」アイコン(赤い右矢印)が表示されます。各種デバッガ・ウィンドウを使用して、アプリケーションを調査できます。

注意:

「ブレークポイント」ウィンドウを確認するか、ブレークポイントの隣に「実行ポイント」アイコン(赤い右矢印)が表示されていることを確認することによって、アプリケーションが実際にブレークポイントをヒットしていることを確認してください。ブレークポイントの設定箇所によっては、アプリケーションが実際にはページ上でのユーザー入力を待機しているのに、停止しているように見えることがあります。

タスク・フロー・アクティビティ宣言ブレークポイントは、タスク・フロー・アクティビティの実行直前でアプリケーションを一時停止します(ビュー・アクティビティを除く)。

6. デフォルトでは、「ADF構造」ウィンドウと「ADFデータ」ウィンドウ、およびいくつかのデバッガ・ウィンドウが表示されます。「ADF構造」ウィンドウでは実行時構造、「ADFデータ」ウィンドウではそれに対応するデータを調べることができます。「「ADF構造」ウィンドウの使用方法」および「ADFデータ・ウィンドウの使用方法」を参照してください。

7. 「ADF構造」ウィンドウでノードを選択し、「ADFデータ」ウィンドウに関連情報を表示します。
タスク・フロー・アクティビティ宣言ブレークポイントは、タスク・フロー・アクティビティの実行直前でアプリケーションを一時停止します。「トレース実行」(F7)機能を使用すると、コールされたタスク・フローのデフォルト・アクティビティを実行する直前に、アプリケーションを一時停止できます。

8. 必要に応じて、表48-3で説明したステップ機能を使用して、アプリケーションのデバッグを継続します。主要なステップ機能は、「トレース実行」(F7)です。
アプリケーションが一時停止しているときに、既存のブレークポイントを削除または無効化し、新しいブレークポイントを設定できます。

48.9.2 ページ定義実行可能ファイル・ブレークポイントの設定方法および使用方法

ページ定義に実行可能ファイルがある場合は、その実行可能ファイルの前または後でアプリケーションを一時停止するブレークポイントを設定できます。たとえば、イテレータがリフレッシュされるときにアプリケーションを一時停止するブレークポイントを設定できます。

注意:

ビュー・オブジェクト問合せが実行された後でアプリケーションを一時停止するAfterイテレータ・ブレークポイントを設定している場合、アプリケーションがこのブレークポイントで複数回一時停止することに注意してください。また、問合せが実行されなかったときにも、このブレークポイントでアプリケーションが一時停止する可能性があります。問合せが実行されたかどうかを把握する必要がある場合は、関連するADFビジネス・コンポーネントを「ADF構造」ウィンドウで選択して、「ADFデータ」ウィンドウで対応するデータを確認します。これらのウィンドウの使用方法の詳細は、「「ADF構造」ウィンドウの使用方法」および「ADFデータ・ウィンドウの使用方法」を参照してください。

ビュー・オブジェクト問合せ実行でのJavaコード・ブレークポイントの使用方法の詳細は、「Oracle ADFブレークポイントに関する必知事項」を参照してください。

始める前に:

ADF宣言ブレークポイントについて理解しておくと役立ちます。詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

ページ定義ファイルの実行可能ファイル上にブレークポイントを設定するには:

1. 「アプリケーション」ウィンドウで、ブレークポイントを設定する実行可能ファイルを含むページ定義ファイルをダブルクリックします。

2. 概要エディタの「バインディングと実行可能ファイル」タブをクリックし、「実行可能ファイル」リストで実行可能ファイルを選択し、項目の左側にあるブレークポイント余白をクリックします。
項目の隣にある余白にブレークポイント・アイコンが表示されます。

3. 必要に応じて、次のようにデバッガを管理するためのブレークポイントの設定を構成します。

a. メイン・メニューで、「ウィンドウ」→「ブレークポイント」を選択します。

b. 「ブレークポイント」ウィンドウで、構成する実行可能ファイル・ブレークポイントを選択し、「編集」アイコンをクリックします。

c. ADFページ定義バインディング・ブレークポイントの編集ダイアログで「条件」タブをクリックし、ブレークポイントに適用する条件を指定します。条件が有効な場合のみブレークポイントが発生します。

d. 「アクション」タブをクリックし、ブレークポイントが発生したときにデバッガで行うアクションを指定して、「OK」をクリックします。
たとえば、ブレークポイントの通常の処理では、デバッグ中のプログラムを停止しますが、プログラムを停止せずにビープ音を鳴らし、ログ・ウィンドウにログ情報を記録することもできます。

4. 次のいずれかの方法で、デバッグ・プロセスを開始します。

- メイン・メニューで、「実行」→「<project_name>のデバッグ」を選択します。

- 「アプリケーション」ウィンドウで、プロジェクト、adfc-config.xml、タスク・フローまたはページを右クリックし、「デバッグ」を選択します。

- タスク・フロー・ダイアグラマで、アクティビティを右クリックして、「デバッグ」を選択します。ページ・フラグメントを使用しないタスク・フローのみを実行できます。

5. アプリケーションがブレークポイントで一時停止されると、実行可能項目のブレークポイント・アイコンの隣にある余白に、「実行ポイント」アイコン(赤い右矢印)が表示されます。各種デバッガ・ウィンドウを使用して、アプリケーションを調査することができます。
Executablesバインディングがリフレッシュされると、アプリケーションが一時停止します。taskFlow実行可能ファイルの場合、prepareModelおよびprepareRenderライフサイクルで一時停止が発生します。

注意:

「ブレークポイント」ウィンドウを確認するか、ブレークポイントの隣の「実行ポイント」アイコン(赤い右矢印)を確認することによって、アプリケーションが実際にブレークポイントをヒットしていることを確認してください。ブレークポイントの設定箇所によっては、アプリケーションが実際にはページ上でのユーザー入力を待機しているのに、停止しているように見えることがあります。

6. デフォルトでは、「ADF構造」ウィンドウと「ADFデータ」ウィンドウ、およびいくつかのデバッガ・ウィンドウが表示されます。「ADF構造」ウィンドウでは実行時構造、「ADFデータ」ウィンドウではそれに対応するデータを調べることができます。「「ADF構造」ウィンドウの使用方法」および「ADFデータ・ウィンドウの使用方法」を参照してください。

7. 「ADF構造」ウィンドウでノードを選択すると、「ADFデータ」ウィンドウに関連情報が表示されます。

8. アプリケーションが一時停止しているときに、既存のブレークポイントを削除または無効化し、新しいブレークポイントを設定できます。

48.9.3 ページ定義アクション・バインディング・ブレークポイントの設定方法および使用方法

ページ定義ファイルで、アクション・バインディング上およびmethodActionバインディング上にブレークポイントを設定することができます。バインディングが実行されると、アプリケーションが一時停止します。

始める前に:

ADF宣言ブレークポイントについて理解しておくと役立ちます。詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

ページ定義ファイルのアクション・バインディング上にブレークポイントを設定するには:

1. 「アプリケーション」ウィンドウで、ブレークポイントを設定するバインディングを含むページ定義ファイルをダブルクリックします。

2. 概要エディタの「バインディングと実行可能ファイル」タブをクリックし、「バインディング」リストでmethodActionバインディングまたは組込み操作項目を選択し、項目の左側にあるブレークポイント余白をクリックします。
項目の隣にブレークポイント・アイコンが表示されます。

3. 必要に応じて、次のようにデバッガを管理するためのブレークポイントの設定を構成します。

a. メイン・メニューで、「ウィンドウ」→「ブレークポイント」を選択します。

b. 「ブレークポイント」ウィンドウで、構成するアクション・バインディング・ブレークポイントを選択し、「編集」アイコンをクリックします。

c. ADFページ定義バインディング・ブレークポイントの編集ダイアログで「条件」タブをクリックし、ブレークポイントに適用する条件を指定します。条件が有効な場合のみブレークポイントが発生します。

d. 「アクション」タブをクリックし、ブレークポイントが発生したときにデバッガで行うアクションを指定して、「OK」をクリックします。
たとえば、ブレークポイントの通常の処理では、デバッグ中のプログラムを停止しますが、プログラムを停止せずにビープ音を鳴らし、ログ・ウィンドウにログ情報を記録することもできます。

4. 次のいずれかの方法で、デバッグ・プロセスを開始します。

- メイン・メニューで、「実行」→「<project_name>のデバッグ」を選択します。

- 「アプリケーション」ウィンドウで、プロジェクト、adfc-config.xml、タスク・フローまたはページを右クリックし、「デバッグ」を選択します。

- タスク・フロー・ダイアグラマで、アクティビティを右クリックして、「デバッグ」を選択します。ページ・フラグメントを使用しないタスク・フローのみを実行できます。

5. アプリケーションがブレークポイントで一時停止されると、アクション・バインディング項目上のブレークポイント・アイコンの隣に「実行ポイント」アイコン(赤い右矢印)が表示されます。各種デバッガ・ウィンドウを使用して、アプリケーションを調査することができます。
バインディングが実行されると、アプリケーションが一時停止します。

注意:

「ブレークポイント」ウィンドウを確認するか、ブレークポイントの隣に「実行ポイント」アイコン(赤い右矢印)が表示されていることを確認することによって、アプリケーションが実際にブレークポイントをヒットしていることを確認してください。ブレークポイントの設定箇所によっては、アプリケーションが実際にはページ上でのユーザー入力を待機しているのに、停止しているように見えることがあります。

6. デフォルトでは、「ADF構造」ウィンドウと「ADFデータ」ウィンドウ、およびいくつかのデバッガ・ウィンドウが表示されます。「ADF構造」ウィンドウでは実行時構造、「ADFデータ」ウィンドウではそれに対応するデータを調べることができます。「「ADF構造」ウィンドウの使用方法」および「ADFデータ・ウィンドウの使用方法」を参照してください。

7. 「ADF構造」ウィンドウでノードを選択すると、「ADFデータ」ウィンドウに関連情報が表示されます。

8. アプリケーションが一時停止しているときに、既存のブレークポイントを削除または無効化し、新しいブレークポイントを設定できます。

48.9.4 ページ定義値バインディング・ブレークポイントの設定方法および使用方法

ページ定義に次のいずれかの値バインディングがある場合、アプリケーションを一時停止するブレークポイントを設定できます。

- 属性値バインディング

- ツリー値のバインディング

- 表の値のバインディング

始める前に:

ADF宣言ブレークポイントについて理解しておくと役立ちます。詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

ページ定義ファイルの値バインディング上にブレークポイントを設定するには:

1. 「アプリケーション」ウィンドウで、ブレークポイントを設定するバインディングを含むページ定義ファイルをダブルクリックします。

2. 概要エディタの「バインディングと実行可能ファイル」タブをクリックし、「バインディング」リストで属性、ツリーまたは表のバインディングを選択し、項目の左側にあるブレークポイント余白をクリックします。値バインディングの隣にブレークポイント・アイコンが表示されます。

3. 必要に応じて、次のようにデバッガを管理するためのブレークポイントの設定を構成します。

a. メイン・メニューで、「ウィンドウ」→「ブレークポイント」を選択します。

b. 「ブレークポイント」ウィンドウで、構成するバインディング・ブレークポイントを選択し、「編集」アイコンをクリックします。

c. ADFページ定義バインディング・ブレークポイントの編集ダイアログで「条件」タブをクリックし、ブレークポイントに適用する条件を指定します。条件が有効な場合のみブレークポイントが発生します。

d. 「アクション」タブをクリックし、ブレークポイントが発生したときにデバッガで行うアクションを指定して、「OK」をクリックします。
たとえば、ブレークポイントの通常の処理では、デバッグ中のプログラムを停止しますが、プログラムを停止せずにビープ音を鳴らし、ログ・ウィンドウにログ情報を記録することもできます。

4. 次のいずれかの方法で、デバッグ・プロセスを開始します。

- メイン・メニューで、「実行」→「<project_name>のデバッグ」を選択します。

- 「アプリケーション」ウィンドウで、プロジェクト、adfc-config.xml、タスク・フローまたはページを右クリックし、「デバッグ」を選択します。

- タスク・フロー・ダイアグラマで、アクティビティを右クリックして、「デバッグ」を選択します。ページ・フラグメントを使用しないタスク・フローのみを実行できます。

5. アプリケーションがブレークポイントで一時停止されると、属性値バインディング上のブレークポイント・アイコンの隣に「実行ポイント」アイコン(赤い右矢印)が表示されます。各種デバッガ・ウィンドウを使用して、アプリケーションを調査することができます。
表48-1に示すように、ADFソース・コード実行の適切なメソッドの前でアプリケーションが一時停止します。新しい値は、このメソッドに入るパラメータになります。

注意:

「ブレークポイント」ウィンドウを確認するか、ブレークポイントの隣に「実行ポイント」アイコン(赤い右矢印)が表示されていることを確認することによって、アプリケーションが実際にブレークポイントをヒットしていることを確認してください。ブレークポイントの設定箇所によっては、アプリケーションが実際にはページ上でのユーザー入力を待機しているのに、停止しているように見えることがあります。

6. デフォルトでは、「ADF構造」ウィンドウと「ADFデータ」ウィンドウ、およびいくつかのデバッガ・ウィンドウが表示されます。「ADF構造」ウィンドウでは実行時構造、「ADFデータ」ウィンドウではそれに対応するデータを調べることができます。「「ADF構造」ウィンドウの使用方法」および「ADFデータ・ウィンドウの使用方法」を参照してください。

7. 「ADF構造」ウィンドウでノードを選択すると、「ADFデータ」ウィンドウに関連情報が表示されます。

8. 必要に応じて、表48-3で説明したステップ機能を使用して、アプリケーションのデバッグを継続します。主要なステップ機能は、ステップ実行(F8)です。
アプリケーションが一時停止しているときに、既存のブレークポイントを削除または無効化し、新しいブレークポイントを設定できます。

48.9.5 ページ定義コンテキスト・イベント・ブレークポイントの設定方法および使用方法

ページ定義がコンテキスト・イベントを定義している場合、コンテキスト・イベント上にブレークポイントを設定し、アプリケーションを一時停止できます。

始める前に:

ADF宣言ブレークポイントについて理解しておくと役立ちます。詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

ページ定義ファイルのコンテキスト・イベント上にブレークポイントを設定するには:

1. 「アプリケーション」ウィンドウで、ブレークポイントを設定するバインディングを含むページ定義ファイルをダブルクリックします。

2. 概要エディタの「コンテキスト・イベント」タブをクリックし、「イベント」リストからコンテキスト・イベントを選択し、項目の左側にあるブレークポイント余白をクリックします。コンテキスト・イベントの隣にブレークポイント・アイコンが表示されます。

3. 必要に応じて、次のようにデバッガを管理するためのブレークポイントの設定を構成します。

a. メイン・メニューで、「ウィンドウ」→「ブレークポイント」を選択します。

b. 「ブレークポイント」ウィンドウで、構成するコンテキスト・イベント・ブレークポイントを選択し、「編集」アイコンをクリックします。

c. ADFコンテキスト・イベント・ブレークポイントの編集ダイアログで「条件」タブをクリックし、ブレークポイントに適用する条件を指定します。条件が有効な場合のみブレークポイントが発生します。

d. 「アクション」タブをクリックし、ブレークポイントが発生したときにデバッガで行うアクションを指定して、「OK」をクリックします。
たとえば、ブレークポイントの通常の処理では、デバッグ中のプログラムを停止しますが、プログラムを停止せずにビープ音を鳴らし、ログ・ウィンドウにログ情報を記録することもできます。

4. 次のいずれかの方法で、デバッグ・プロセスを開始します。

- メイン・メニューで、「実行」→「<project_name>のデバッグ」を選択します。

- 「アプリケーション」ウィンドウで、プロジェクト、adfc-config.xml、タスク・フローまたはページを右クリックし、「デバッグ」を選択します。

- タスク・フロー・ダイアグラマで、アクティビティを右クリックして、「デバッグ」を選択します。ページ・フラグメントを使用しないタスク・フローのみを実行できます。

5. アプリケーションがブレークポイントで一時停止されると、コンテキスト・イベント上のブレークポイント・アイコンの隣に「実行ポイント」アイコン(赤い右矢印)が表示されます。各種デバッガ・ウィンドウを使用して、アプリケーションを調査することができます。
コンテキスト・イベントが発生する前にアプリケーションが一時停止します。

注意:

「ブレークポイント」ウィンドウを確認するか、ブレークポイントの隣に「実行ポイント」アイコン(赤い右矢印)が表示されていることを確認することによって、アプリケーションが実際にブレークポイントをヒットしていることを確認してください。ブレークポイントの設定箇所によっては、アプリケーションが実際にはページ上でのユーザー入力を待機しているのに、停止しているように見えることがあります。

6. デフォルトでは、「ADF構造」ウィンドウと「ADFデータ」ウィンドウ、およびいくつかのデバッガ・ウィンドウが表示されます。「ADF構造」ウィンドウでは実行時構造、「ADFデータ」ウィンドウではそれに対応するデータを調べることができます。「「ADF構造」ウィンドウの使用方法」および「ADFデータ・ウィンドウの使用方法」を参照してください。

7. 「ADF構造」ウィンドウでノードを選択すると、「ADFデータ」ウィンドウに関連情報が表示されます。

8. 必要に応じて、表48-3で説明したステップ機能を使用して、アプリケーションのデバッグを継続します。主要なステップ機能は、ステップ実行(F8)です。
アプリケーションが一時停止しているときに、既存のブレークポイントを削除または無効化し、新しいブレークポイントを設定できます。

48.9.6 ADFライフサイクル・フェーズ・ブレークポイントの設定方法および使用方法

ADFライフサイクル・フェーズのBeforeブレークポイントとAfterブレークポイントを任意のADFライフサイクル・フェーズに設定できます。各フェーズに、Beforeのみ、Afterのみ、または両方を設定できます。必要な数のフェーズにブレークポイントを設定できます。

「ブレークポイント」ウィンドウのメニューからADFライフサイクル・フェーズ・ブレークポイントの作成ダイアログを使用し、ブレークポイントを作成して、オプションをカスタマイズできます。または、「ADFライフサイクル・ブレークポイント」ウィンドウを使用してデフォルト・オプションのブレークポイントを作成できます。ライフサイクル・ブレークポイントを設定した後で、「ブレークポイント」ウィンドウから開始できるADFライフサイクル・フェーズ・ブレークポイントの編集ダイアログを使用してオプションを編集できます。

ADFライフサイクル・ブレークポイントは次に示す任意のADFライフサイクル・フェーズに設定できます。

- JSFのビューのリストア

- コンテンツの初期化

- モデルの準備

- JSFのリクエスト値の適用

- JSFの検証処理

- JSFのモデル値の更新

- モデル更新の検証

- JSFのアプリケーションの起動

- メタデータのコミット

- レンダリング準備

- JSFのレスポンス・レンダリング

始める前に:

ADF宣言ブレークポイントについて理解しておくと役立ちます。詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

「ブレークポイント」ウィンドウでADFライフサイクル・フェーズ・ブレークポイントを設定または管理するには:

1. メイン・メニューで、「ウィンドウ」→「ブレークポイント」を選択します。

2. 「ブレークポイント」ウィンドウで、「追加」→「ADFライフサイクル・フェーズ・ブレークポイント」を選択します。

3. ADFライフサイクル・フェーズ・ブレークポイントの作成ダイアログの「定義」タブで、次の手順を実行します。

- ブレークポイントを設定するADFライフサイクル・フェーズを選択します。

- 「フェーズの前」または「フェーズの後」のブレークポイントを選択します。

4. 「条件」タブで必要なオプションを選択し、「OK」をクリックします。

5. 「アクション」タブで必要なオプションを選択し、「OK」をクリックします。

ブレークポイント・アイコンを使用してADFライフサイクル・フェーズ・ブレークポイントを設定するには:

1. 「アプリケーション」ウィンドウで、任意のタスク・フローの構成ファイルをダブルクリックし、概要エディタで「ダイアグラム」タブをクリックします。

2. タスク・フロー・ダイアグラマのツールバーまたは「ADF構造」ウィンドウのタイトル・バーで、ADFライフサイクル・ブレークポイントのアイコン(図48-31)をクリックします

図48-31 ADFライフサイクル・ブレークポイントのアイコン

3. 「ADFライフサイクル・ブレークポイント」ウィンドウで、ADFライフサイクル・フェーズの左余白をクリックしてBeforeブレークポイントを設定し、右余白をクリックしてAfterブレークポイントを設定します。図48-32に示すように、ブレークポイントを示す赤い点アイコンが設定されます。このブレークポイントはデフォルトのブレークポイント・オプションで設定されます。ブレークポイントを削除するには赤い点アイコンをクリックします。

図48-32 ADFライフサイクル・ブレークポイント・ウィンドウでのブレークポイントの設定

4. ブレークポイント・オプションを編集する場合は、「ブレークポイント」ウィンドウでブレークポイントを選択し、「編集」アイコンをクリックします。

ADFライフサイクル・フェーズ・ブレークポイントを使用してアプリケーションをデバッグするには:

1. 次のいずれかの方法で、デバッグ・プロセスを開始します。

- メイン・メニューで、「実行」→「<project_name>のデバッグ」を選択します。

- 「アプリケーション」ウィンドウで、プロジェクト、adfc-config.xml、タスク・フローまたはページを右クリックし、「デバッグ」を選択します。

- タスク・フロー・ダイアグラマで、アクティビティを右クリックして、「デバッグ」を選択します。ページ・フラグメントを使用しないタスク・フローのみを実行できます。

2. アプリケーションがADFライフサイクル・フェーズ・ブレークポイントで一時停止すると、図48-33に示すように、「ADFライフサイクル・ブレークポイント」ウィンドウで、実行ポイントのアイコン(赤い右矢印)がブレークポイント・アイコンの横に表示され、ADFライフサイクル・フェーズが太字になります。各種デバッガ・ウィンドウを使用して、アプリケーションを調査することができます。

図48-33 ADFライフサイクル・ブレークポイント・ウィンドウでの実行ポイントの表示

注意:

「ブレークポイント」ウィンドウでブレークポイントの到達を確認するか、ブレークポイントの隣に「実行ポイント」アイコン(赤い右矢印)が表示されていることを確認することによって、アプリケーションが実際にブレークポイントをヒットしていることを確認してください。ブレークポイントの設定箇所によっては、アプリケーションが実際にはページ上でのユーザー入力を待機しているのに、停止しているように見えることがあります。

3. デフォルトでは、「ADF構造」ウィンドウと「ADFデータ」ウィンドウ、およびいくつかのデバッガ・ウィンドウが表示されます。「ADF構造」ウィンドウでは実行時構造、「ADFデータ」ウィンドウではそれに対応するデータを調べることができます。現在のADFライフサイクル・フェーズは「ADF構造」ウィンドウの一番上に表示されます。詳細は、「「ADF構造」ウィンドウの使用方法」および「ADFデータ・ウィンドウの使用方法」を参照してください。

4. 「ADF構造」ウィンドウでノードを選択すると、「ADFデータ」ウィンドウに関連情報が表示されます。

5. 必要に応じて、表48-3で説明したステップ機能を使用して、アプリケーションのデバッグを継続します。主要なステップ機能は、ステップ実行(F8)です。

アプリケーションが一時停止しているときに、既存のブレークポイントを削除または無効化し、新しいブレークポイントを設定できます。

48.9.7 「ADF構造」ウィンドウの使用方法

アプリケーションがブレークポイントで停止すると、「ADF構造」ウィンドウに、アプリケーション内でのADFランタイム・オブジェクトやその相互関係がツリー構造として表示されます。特に、メイン・ブラウザ・ウィンドウまたは含まれているリージョンやポートレットを表現する、ビュー・ポートの階層が表示されます。「ADF構造」ウィンドウで各種の項目を選択すると、対応する「ADFデータ」ウィンドウに表示される関連情報が変化します。「ADFデータ」ウィンドウの詳細は、「ADFデータ・ウィンドウの使用方法」を参照してください。

次のどちらかがtrueのとき、デバッグ・セッションでは、デフォルトで「ADF構造」ウィンドウと「ADFデータ」ウィンドウが表示されます。

- デバッグしているプロジェクトに、WEB-INF/adfc-config.xmlファイルが含まれる。

- デバッグしているプロジェクトに、ADF Facesタグ・ライブラリが含まれる。

「ADF構造」ウィンドウを開くには、メイン・メニューから「ウィンドウ」→「デバッガ」→「ADF構造」を選択します。「ADF構造」ウィンドウでADFライフサイクル・ブレークポイントのアイコンを使用して、「ADFライフサイクル・ブレークポイント」ウィンドウを開きます。

ブレークポイントに到達すると、図48-34に示すように、「ADF構造」ウィンドウにADFライフサイクル・フェーズとランタイム・オブジェクトのツリー構造が表示されます。

図48-34 「ADF構造」ウィンドウでのランタイム・オブジェクトの表示

「ADF構造」ウィンドウで項目を選択すると、その項目に関連付けられているデータと値が「ADFデータ」ウィンドウに表示されます。図48-35に、「ADF構造」ウィンドウで選択されたタスク・フローと、ADFデータ・ウィンドウに表示された関連情報を示します。

図48-35 「ADF構造」ウィンドウの選択内容とADFデータ・ウィンドウのデータ

階層のルートは、兄弟ノードである「スコープ」と「ADFコンテキスト」です。処理が停止した現在のビュー・ポートは、太字で表示されます。ツリー内のデフォルトの選択内容は前のブレークポイントから保持されるため、ブレークポイント間での変化を監視することができます。ADF宣言ブレークポイントが定義されているADFオブジェクトは、対応するJDeveloperエディタ(タスク・フロー・ダイアグラマ、またはページ定義ファイルの概要エディタ)で開かれます。

「ADF構造」ツリーは、変更されたオブジェクト状態を反映するため、アプリケーションがブレークするたびに、また後続のステップでも再ビルドされます。全体のツリー階層が表示されますが、選択したり、さらに調査したりできるのは、現在のビュー・ポートとその親ビュー・ポートの範囲内の項目のみです。現在のコンテキストにない、ツリー階層の他のすべての項目は、淡色表示され、無効にされます。また、この階層を使用して、アプリケーションの範囲内でのランタイム・オブジェクト間の関係を特定することもできますが、現在のコンテキスト(およびその親のビュー・ポート)に限定されます。

表48-4に、「ADF構造」ウィンドウの階層ツリーに表示できる、各種の項目を示します。

表48-4 「ADF構造」ウィンドウの項目

「ADF構造」ツリーの項目

説明

スコープ

ADF構造階層の一番上で兄弟ノードの「ADFコンテキスト」よりも上に表示されます。ADF構造階層には「スコープ」ノードは1つしかありません。「スコープ」ノードを展開すると、子スコープ・ノード(viewScopeやpageFlowScopeなど)のリストが表示されます。子スコープ・ノードを選択すると、「ADFデータ」ウィンドウにそのスコープの変数と値が表示されます。

ADFコンテキスト

ADF構造階層のルート・ノードとして、兄弟ノードの「スコープ」の下に表示されます。ADF構造階層内にはADFコンテキストは1つのみ存在する。

ビュー・ポート

ビュー・ポートは、ADF Controllerの概念。このため、デバッグしているアプリケーションがADF Controllerを利用するときだけ、ADF構造階層の範囲内でビュー・ポートが表示される。

ビュー・ポートは、次のいずれかを表現可能。

- ブラウザ: メイン・ブラウザ・ビュー・ポート(ルート・ビュー・ポート)は、ルートの「ADFコンテキスト」の子として表示されます。ランタイムのデバッグ・セッション中に複数のブラウザ・ウィンドウが開いている場合、複数のブラウザ・ビュー・ポートが階層内に示されます。各ブラウザ・ビュー・ポートのラベルにはブラウザというテキストが表示されます。ビュー・ポートにはビュー・ポートIDを示すツールチップも用意されており、ビュー・ポート: 999999のように表示されます。

- リージョン: リージョン・ビュー・ポートは、ページまたはページ・フラグメントの子として表示される。これらは子ビュー・ポートとも呼ばれます。各リージョン・ビュー・ポートのラベルには、テキスト「リージョン」が表示される。リージョンにはビュー・ポートIDを示すツールチップも用意されており、「子ビュー・ポート: 999999」のように表示されます。

ADFタスク・フロー

各ビュー・ポートに対応するページ・フロー・スタックは、ADFタスク・フローの階層として表示されます。スタックに対応してコールされる最初のADFタスク・フローは、対応するビュー・ポートの直接の子である。各ADFタスク・フローのラベルは、対応するADFタスク・フロー表示名(存在する場合)、またはそのタスク・フローIDを反映する。リージョン・ビュー・ポートには、内包されたバインドなしタスク・フローのためのページ・フロー・スタック階層内の項目は表示されません。タスク・フローにも、ADFタスク・フロー・パスを表示するツールチップと、エディタ・ワークスペース内の、対応するADFタスク・フローを開くポップアップ・メニュー項目が用意されている。

アプリケーションがADF Controllerを利用しない場合(またはページがADFタスク・フローのコンテキストの外部で実行される場合)、ADFタスク・フローは階層内に表示されない。

ページ

ブラウザ・ビュー・ポート内で現在表示されているページ(ビュー)を表します。関連付けられたバインディング・コンテナ(ある場合)と一緒に子として示されます。デバッグしているアプリケーションがADFコントローラを利用する場合、ページは各ブラウザ・ビュー・ポートの子です。各ページのラベルは、対応するランタイム・ビューIDを反映する。ページにも、ページ・パスを表示するツールチップと、エディタ・ワークスペース内の、対応するページを開くポップアップ・メニュー項目が用意されている。アプリケーションでビジュアル・ユーザー・インタフェースが実装されていない場合、ページは階層内に表示されない。

ページ・フラグメント

リージョン・ビュー・ポート内で現在表示されているページ・フラグメントを表す。関連付けられたバインディング・コンテナ(ある場合)と一緒に子として示されます。デバッグしているアプリケーションがADF Controllerを利用する場合、ページ・フラグメントは各リージョン・ビュー・ポートの子である。各ページ・フラグメント・ノードのラベルは、対応するランタイム・ビューIDを反映する。ページ・フラグメントにも、ソース・ファイル・ページ定義パスを表示するツールチップと、エディタ・ワークスペース内の、対応するページ・フラグメントを開くポップアップ・メニュー項目が用意されています。

バインディング・コンテナ

対応するページまたはページ・フラグメントのバインディング・コンテナを表す。各バインディング・コンテナのラベルは、対応するファイル名(ページ定義ファイル)から拡張子を除いたものを反映する。バインディング・コンテナ・ノードにも、ページ・フラグメント・パスを表示するツールチップが用意されています。タスク・フロー・アクティビティ・バインディング(たとえば、メソッド・コール・アクティビティ・バインディング)を表すために使用される場合は、バインディング・コンテナも現在のタスク・フローの下に表示される。

アプリケーションでADFモデルが利用されない場合、バインディング・コンテナは表示されない。

アプリケーション・データ

対応するビュー・ポート(または、ADFコントローラが使用されない場合はバインディング・コンテナ)のデータ・コントロール・フレーム内でインスタンス化されたアプリケーション・データ・オブジェクト(ADFビジネス・コンポーネント・オブジェクトまたはADFビジネス・コンポーネント・ビジネス・サービス・オブジェクトなど)を表します。現在、アプリケーション・データ・ノードを表示するために、アプリケーション・データ・オブジェクトをインスタンス化する必要はありません。

48.9.8 ADFデータ・ウィンドウの使用方法

アプリケーションがADF宣言ブレークポイントで一時停止されるとき、「ADFデータ」ウィンドウには、「ADF構造」ウィンドウ内での選択内容に基づく関連データが表示されます。「ADFデータ」ウィンドウを開くには、メイン・メニューから「ウィンドウ」→「デバッガ」→「ADFデータ」を選択します。「ADF構造」ウィンドウでの選択内容に基づく「ADFデータ」ウィンドウの内容を、表48-5に示します。

表48-5 「ADF構造」ウィンドウの選択内容に対応するADFデータ・ウィンドウの内容

「ADF構造」ウィンドウ

ADFデータの内容

スコープ

現在のコンテキストに基づくメモリー・スコープ値が表示されます。pageFlowScopeもADFタスク・フローの内容に表示されます。選択されたADFタスク・フロー(現在のコンテキストとはかぎらない)に固有のpageFlowScope値です。viewScopeもビュー・ポートの内容に表示されます。選択されたビュー・ポート(現在のコンテキストとはかぎらない)に固有のviewScope値です。

ADFコンテキスト

ADFコンテキストの変数と値の階層が表示されます。#(data.adfContext) EL式をELエバリュエータで評価して、ADFコンテキストの変数と値を検査することができます。

ビュー・ポート

viewScopeの内容などの、ビュー・ポート詳細が表示されます。

ページ・フロー・スタック・エントリ

現在のトランザクション・ステータスやADFモデル・セーブポイント・ステータスなど、選択されているページ・フロー・スタック・エントリの情報が表示されます。

ページ/ページ・フラグメント

ページまたはページ・フラグメントがレンダリングされた場合は、選択されたページまたはページ・フラグメントに対応する、ページまたはページ・フラグメントUIコンポーネント・ツリー階層が表示される。

バインディング・コンテナ

パラメータ、バインディング、実行可能ファイルなど、バインディング・コンテナの実行時値が表示されます。

アプリケーション・データ

現在のバインディング・コンテキストでインスタンス化されたアプリケーション・データ・オブジェクト(たとえばADFビジネス・コンポーネント・オブジェクト)が表示されます。ビジネス・サービス・レイヤーがADFビジネス・コンポーネント・オブジェクト(たとえばEJB)以外のテクノロジで実装されている場合、アプリケーション・データ・オブジェクトはより一般的な形式で表示されます。

「ADF構造」ウィンドウの「スコープ」ノードを展開すると、子スコープ・ノードのリストが表示されます。「ADF構造」ウィンドウで子スコープ・ノードを選択すると、「ADFデータ」ウィンドウに、選択したメモリー・スコープの現在のコンテキスト値が表示されます(図48-36)。

図48-36 「ADF構造」ウィンドウで選択された子スコープ

「スコープ」ノードそのものを選択した場合は、メモリー・スコープすべてのリストが「ADFデータ」ウィンドウにも表示されます。このリストも検査のために展開できます。図48-37では、「ADF構造」ウィンドウで「スコープ」ノードが選択され、ADFデータ・ウィンドウではviewScope子ノードが選択されて値が表示されています。requestScope、viewScope、pageFlowScope、applicationScopeおよびsessionScopeに対応する各ノードを展開して値を検査できます。pageFlowScopeも、ADFタスク・フローの内容に表示され、「ADF構造」ウィンドウで現在選択されているADFタスク・フロー固有の値を反映します。viewScopeも、ビュー・ポートの内容に表示され、「ADF構造」ウィンドウで現在選択されている特定のビュー・ポートの値を反映します。

図48-37 「ADF構造」ウィンドウで選択された「スコープ」ノード

図48-38のように「ADF構造」ウィンドウで「ADFコンテキスト」が選択されると、ADFコンテキスト変数の現在の値がADFデータ・ウィンドウに表示されます。#(data.adfContext) EL式をELエバリュエータで評価して、ADFコンテキストの変数と値を検査することもできます。詳細は、「EL式エバリュエータの使用」を参照してください。

図48-38 「ADFコンテキスト」が選択されたADFデータ・ウィンドウ

ADF構造階層内でビュー・ポートを選択すると、図48-39に示すように、そのビュー・ポートの現在のビュー・ポート詳細がADFデータ・ウィンドウに表示されます。各ビュー・ポートで表示される値の概要を、表48-6に示します。

図48-39 ビュー・ポートが選択されたADFデータ・ウィンドウ

表48-6 ビュー・ポートに対応するADFデータ・ウィンドウの内容

ビュー・ポート

説明

ビュー・ポートID

表示されます

クライアントID

表示されます

初期タスク・フローID

ビュー・ポート・ページ・フロー・スタック上の初期ADFタスク。バインドなしタスク・フローの場合は表示されません。対応するタスク・フロー定義をエディタ・ワークスペースで開くためのリンクとして表示される。

現在のタスク・フローID

バインド・タスク・フローでは表示され、バインドなしタスク・フローでは表示されません。ビュー・ポートのページ・フロー・スタック上の現在のADFタスク。対応するタスク・フロー定義をエディタ・ワークスペースで開くためのリンクとして表示される。

ビュー・アクティビティID

現在のADFタスク・フロー・ビュー・アクティビティID。現在のADFタスク・フロー・アクティビティがビュー・アクティビティである場合のみ適用される。

発行済アクティビティID

現在のリクエストを発行しているADFタスク・フロー・アクティビティ。

最終アクティビティID

現在のリクエストを受け取っているADFタスク・フロー・アクティビティ。

未処理のブックマーク・リダイレクト

(ブール)

例外

(存在する場合)

ビュー・メモリー・スコープ

選択したビュー・ポートのビュー・メモリー・スコープ変数と値。

「ADF構造」ウィンドウでは、ページ・フロー・スタック階層内の各ADFタスク・フローを選択できます。「ADF構造」ウィンドウでADFタスク・フローを選択すると、現在のタスク・フロー情報がADFデータ・ウィンドウに表示されます(図48-40)。選択したADFタスク・フローで使用されるタスク・フロー・テンプレートを判別するには、ADFタスク・フロー・ソース・ファイルに手動でナビゲートします。これは、Javaソース・ファイルで同様の機能を処理する方法と似ています。選択されたADFタスク・フローの現在の情報を表48-7に示します。

図48-40 タスク・フローが選択されたADFデータ・ウィンドウ

表48-7 タスク・フローに対応するADFデータ・ウィンドウの内容

タスク・フロー

説明

ADFタスク・フローの参照

ADFタスク・フローの参照

タスク・フロー・コール・アクティビティID

コール元タスク・フローのタスク・フロー・アクティビティID。各ビュー・ポート・タスク・フローの「コール」ウィンドウ内の最初のADFタスク・フローではnullとなる。

ビュー・アクティビティIDのコール中

ADFタスク・フロー(存在する場合)によって表示されている現在の表示アクティビティのコール元表示アクティビティ。

ビュー到達済

(ブール)

トレイン・モデル

現在のADFタスク・フロー・アクティビティがビュー・アクティビティである場合のみ適用される。

トランザクション開始済

(ブール)ADFタスク・フローのトランザクション状態の現行ステータスを特定する。たとえば、ADFタスク・フローが、新しいトランザクションを開始したかどうか。

トランザクション共有

(ブール)ADFタスク・フローのトランザクション状態の現行ステータスを特定する。たとえば、ADFタスク・フローが、既存のトランザクションに結合されたかどうか。

セーブポイント

ADFタスク・フローのADFモデル・セーブポイント作成状態の現行ステータスを特定します。たとえば、モデル・セーブポイントが、ADFタスク・フロー・エントリ上に作成されたか。

リモート・タスク・フロー・コール済

(ブール)

リモート・タスク・フロー・リターンURL

ADFタスク・フローをリモートからコールする場合にのみ適用される。リモートからコールされたタスク・フローが完了したときに戻すURLを特定する。

データ・コントロール・フレーム作成済

(ブール)

データ・コントロール・フレーム

ADFタスク・フローに関連付けられたデータ・コントロール・フレームの名前。

ページ・フロー・メモリー・スコープ

展開できるノードとして表示されます。「ADF構造」ウィンドウで選択されたタスク・フローのページ・フロー・メモリー・スコープの値を検査できます。

ページ・フロー・メモリー・スコープは、「ADF構造」ウィンドウの「スコープ」ノードにも表示されます。ただし、「スコープ」ノードのページ・フロー・メモリー・スコープは、常にアプリケーションの現在のコンテキストに対応し、選択されているタスク・フローには対応していません。

ADF構造階層でページまたはページ・フラグメント・ノードを選択すると、図48-41に示すように、対応するUIコンポーネント・ツリーがADFデータ・ウィンドウに表示されます。ページまたはページ・フラグメントがページ・テンプレートに基づいている場合、ページ・テンプレートに由来する内容をファセット参照項目の外部に組み込むことができます。これには、「ADFデータ」ウィンドウの一番上で「ページ・テンプレート・コンテンツを含める」チェックボックスを選択します。ページ・テンプレートの内容が組み込まれない場合、ページまたはページ・フラグメントのUIコンポーネント・ツリーはソース・ファイルのツリーと似た構造になります。

図48-41 ページが選択されたADFデータ・ウィンドウ

ADF構造階層でバインディング・コンテナを選択すると、表48-8に示すノードの選択肢がADFデータ・ウィンドウに表示されます。

表48-8 バインディング・コンテナに対応するADFデータ・ウィンドウの内容

バインディング・コンテナ

説明

ページ定義リンク

対応するページ定義ソース・ファイルに移動して、エディタ・ワークスペースで開く。

データ・コントロール

バインディング・コンテナのデータ・コントロールが表示されます。

ADFビジネス・コンポーネント・オブジェクトよって実装されたデータ・コントロールと非ADFビジネス・コンポーネント・オブジェクトによって実装されたデータ・コントロールの表示は少し異なります。ADFビジネス・コンポーネント・ベースのデータ・コントロールの表示は、行コレクションを使用する実際のビジネス・サービス実装と似ています。非ADFビジネス・コンポーネント・ベースのデータ・コントロールは、通常、RAWメンバー変数として表示されます。これはADF宣言デバッガの「データ」ウィンドウに表示される項目と似ています。「ADFデータ」ウィンドウには、メンバー変数や配列など、キャッシュされた情報しか表示されません。標準デバッガ機能を使用して、各項目をカスタマイズすることもできます。

各ADFビジネス・コンポーネント・データ・コントロールについて次の情報が表示されます。

- 行コレクション

- 各行コレクションの問合せ文字列

- 各行コレクションに対する変数での置換を含む問合せ文字列

- アプリケーション・データ行

- 現在行のインジケータ

- 更新識別子

- 現在の値と元の値(同じリクエスト内で変更される場合)

パラメータ

すべてのバインディング・コンテナ・パラメータの現在の値。

実行可能ファイル

実行可能ファイルが表示され、現在行のインジケータと、現在と元の値(同じリクエスト内で変更された場合)が示されます。これには次のタイプの実行可能ファイルが含まれます。

- イテレータ - 対応する属性バインディングがRefreshプロパティおよびRefreshConditionプロパティと一緒に表示されます。

- タスク・フロー - タスク・フロー・バインディングに割り当てられたタスク・フローIDの現在の値、および関連するすべてのパラメータ値。タスク・フローIDは、対応するタスク・フロー定義ソース・ファイルをエディタ・ワークスペースで開くためのリンクとして表示される。リンク・テキストは、<task flow source document>#<task flow id>のように構成されます。

- 検索リージョン - イテレータと似ていますが、基準と置換情報を含む基準も表示されます。

バインディング

値、表、ツリーおよびメソッドのバインディングが表示されます。各バインディングには次の情報が含まれます。

- 関連付けられた実行可能ファイル

- 更新識別子

- 現在の値と元の値(同じリクエスト内で変更される場合)

ページ・テンプレートのバインディング・コンテナ

対応するページまたはページ・フラグメントがページ・テンプレートを利用していた場合、ページ・テンプレートのバインディング・コンテナは、ページまたはページ・フラグメント・バインディング・コンテナの内容の子として表示されます。

非ADFビジネス・コンポーネント・オブジェクトに基づくアプリケーションのバインディング・コンテナを選択すると、「ADFデータ」ウィンドウにバインディング・コンテナの内容が表示されます(図48-1)。

図48-42 バインディング・コンテナ(非Business Components)が選択された「ADFデータ」ウィンドウ

ADFビジネス・コンポーネント・オブジェクトに基づくアプリケーションのバインディング・コンテナを選択すると、「ADFデータ」ウィンドウに標準の行コレクション・アイコンが表示されます(図48-2)。

図48-43 バインディング・コンテナ(ビジネス・コンポーネント)が選択されたADFデータ・ウィンドウ

ADFデータ・ウィンドウの「パラメータ」ノードを展開すると、図48-44のように情報が表示されます。

図48-44 「パラメータ」が選択されたADFデータ・ウィンドウ

ADFデータ・ウィンドウの「実行可能ファイル」ノードを展開すると、図48-45のように情報が表示されます。

図48-45 「実行可能ファイル」が選択されたADFデータ・ウィンドウ

値が変更された場合、変更された項目は左側に青い点が付いてマークされ、以前の値がカッコ内に表示されます。たとえば、OrderTotalの値が7895.81から7670.11に変更されたとします。「ADFデータ」ウィンドウでは、OrderTotalと親のOrdersView1Iteratorの横に青い点が表示され、「値」列に現在の値と前の値が表示されます(図48-46)。

図48-46 値の変更が青い点で示されるADFデータ・ウィンドウ

メソッドのバインディング情報はADFデータ・ウィンドウで図48-47のように表示されます。

図48-47 メソッドのバインディングが選択されたADFデータ・ウィンドウ

「ADF構造」ウィンドウで「アプリケーション・データ」ノードを選択すると、対応するビュー・ポート(または、ADFコントローラが使用されない場合はバインディング・コンテキスト)の現在のデータ・コントロール・フレーム内でインスタンス化されたアプリケーション・オブジェクト(ADFビジネス・コンポーネント・オブジェクトなど)が、ADFデータ・ウィンドウに表示されます。

ADFビジネス・コンポーネント・オブジェクトで実装されたビジネス・サービスによって、図48-48のようにアプリケーション・データの内容が表示されます。これは表48-9で説明します。

図48-48 ADFビジネス・コンポーネント・ビジネス・サービスのアプリケーション・データ

表48-9 アプリケーション・データに対応するADFデータ・ウィンドウの内容

バインディング・コンテナ

説明

アプリケーション・モジュール

対応するビュー・ポートのデータ・コントロール・フレームのアプリケーション・モジュールが、アプリケーション・データ階層にルート・ノードとして表示されます。アプリケーション・モジュールの設計時のアイコンによってノードが示されます。アプリケーション・モジュール・ノードでは次の情報が提供されます。

- アプリケーション・モジュール・リンク - 対応するアプリケーション・モジュールのソース・ファイルをエディタ・ワークスペースで開くためのリンク。

- トランザクション - アプリケーション・モジュールの現在のトランザクション・ステータス(該当する場合)

- ビュー・オブジェクト

- エンティティ・オブジェクト

ビュー・オブジェクト

対応するビュー・ポートのデータ・コントロール・フレーム内でインスタンス化されたビュー・オブジェクトが、対応するアプリケーション・モジュール・ルート・ノードの下に下位ノードとして表示されます。設計時のアイコンによって示されます。子ビュー・オブジェクトは、親ビュー・オブジェクトの下位階層に表示されます。名前付き行セットはビュー・オブジェクトと同様に表示されます。ビュー・オブジェクトの名前付きイテレータは子ビュー・オブジェクトと同様に表示されます。各ビュー・オブジェクト・ノードでは次の情報が提供されます。

- ビュー・オブジェクト・リンク - 対応するビュー・オブジェクトのソース・ファイルをエディタ・ワークスペースで開くためのリンク。

- 問合せ - 最後に実行されたビュー・オブジェクトのSQL文。値の置換を含まないバインド変数が表示されます。

- 置換を含む問合せ - 最後に実行されたビュー・オブジェクトのSQL文。値の置換を含むバインド変数が表示されます。

- バインド変数 - 最後に実行されたビュー・オブジェクトのSQL文のバインド変数とその値

- ビュー・オブジェクト行 - 表示される各行は、連結されたキー値で示されます。現在行は特別なアイコンで示されます。

- 属性 - 各行に含まれる属性では、含まれるエンティティ・オブジェクトと一緒に現在の値が表示されます。一時属性も表示されます。

- 変更 - 同じリクエストで行われた変更は、属性、行およびビュー・オブジェクトのノード・ラベルの左側の青い点で示されます。変更前と変更後の値が両方とも表示されます。

エンティティ・オブジェクト

対応するビュー・ポートのデータ・コントロール・フレーム内でインスタンス化されたエンティティ・オブジェクトが、アプリケーション・モジュール・ルート・ノードの下に下位ノードとして表示されます。設計時のアイコンによって示されます。各エンティティ・オブジェクト・ノードでは次の情報が提供されます。

- エンティティ・オブジェクト・リンク - 対応するエンティティ・オブジェクトのソース・ファイルをエディタ・ワークスペースで開くためのリンク。

- エンティティ・オブジェクト行 - 表示される各行は、連結されたキー値で示されます。行の現在のエンティティ状態とポスト状態(たとえばSTATUS_MODIFIED)も表示されます。

- 属性 - 各行に含まれる属性については現在の値が表示されます。

- 変更 - 同じリクエストで行われた変更は、属性、行およびエンティティ・オブジェクトのノード・ラベルの左側の青い点で示されます。変更前と変更後の値が両方とも表示されます。

非ADFビジネス・コンポーネント・オブジェクトによって実装されたビジネス・サービスでは、アプリケーション・データの内容がRAWメンバー変数を使用して表示されます。この形式は、図48-42に示す、バインディング・コンテナに関する非ADFビジネス・コンポーネントの内容の表示と似ています

48.9.9 ADF宣言ブレークポイント設定時の処理

ADF宣言ブレークポイントを設定すると、ADFソースJavaコード内の対応する適切なクラス、メソッドまたは他の構造体に、JDeveloperによってブレークポイントが追加されます。コードにブレークポイントが設定されると、アプリケーションがブレークポイントに到達したときに、標準Javaデバッガ・メカニズムによって実行が一時停止されます。ブレークポイントに到達すると、「ブレークポイント」ウィンドウにおいて赤い点のアイコンで示されます。到達した宣言ブレークポイントのタイプに応じて、タスク・フロー・アクティビティ、ページ定義ブレークポイント余白、または「ADFライフサイクル・ブレークポイント」ウィンドウでも、赤い点のアイコンとして示されます。

タスク・フロー・アクティビティ・ブレークポイントの場合、JSFアプリケーション起動フェーズ内で、ブレークポイントが設定されたアクティビティの前にアプリケーションがデバッガによって一時停止されます。つまり、ブレークポイントが設定されているアクティビティは実行されません。

ただし、タスク・フロー・ビュー・アクティビティの場合、アプリケーションは、ビュー・アクティビティが実行された後で、新しいページがレンダリングする前に、JSFレスポンス・レンダリング・フェーズ内で一時停止します。

ページ定義の実行可能ファイルのBeforeブレークポイントの場合、実行可能ファイルがリフレッシュされるとアプリケーションがデバッガによって一時停止されます。ページ定義のアクション・バインディングのBeforeブレークポイントの場合、バインディングが実行されるとアプリケーションがデバッガによって一時停止されます。ページ定義の属性値バインディングのBeforeブレークポイントの場合、ADFソース・コードの属性のsetInputValue()メソッドが実行される前に、アプリケーションがデバッガによって一時停止されます。

ライフサイクルのBeforeブレークポイントの場合、アプリケーションが次のライフサイクル・フェーズに入る前にデバッガによって一時停止されます。ライフサイクルのAfterブレークポイントの場合は、ライフサイクル・フェーズの後で次のフェーズの前にアプリケーションがデバッガによって一時停止されます。

48.10 JavaコードとGroovyスクリプトのブレークポイントの設定

標準的なJavaコード・デバッガと同様に、ADF宣言デバッガを使用してJavaのクラスおよびメソッド上にブレークポイントを設定することができます。Javaコード・ブレークポイントとGroovyスニペット・ブレークポイントは、ADF宣言ブレークポイントと組み合せて使用できます。大部分のADFアプリケーションでは、ADF宣言ブレークポイントから、アプリケーションのトラブルシューティングに十分なデバッグ情報を得ることができます。ADF宣言ブレークポイントの使用の詳細は、「ADF宣言ブレークポイントの設定」を参照してください。ただし、詳細な調査のために、個別のクラスまたはメソッド上にブレークポイントを設定する必要があることがあります。あるいは、非ADFアプリケーションをデバッグする場合に、Javaコード・ブレークポイントを使用できます。

JDeveloperでは、ブレークするクラスを見つけるためのクラス・ロケータ機能が提供されます。Oracle ADFソース・コードを取得できる場合、様々なADFクラスおよびメソッドにアクセスして、デバッグの効率を上げることができます。ADFソース・コードの取得の詳細は、「デバッガでのADFソース・コードの使用」を参照してください。ADFソースを取得すると、「シンボリック・デバッグでデバッグ・ライブラリを使用する方法」で説明するように、ADFソースのデバッグ・ライブラリ・バージョンを使用してデバッグの効率を上げることができます。

48.10.1 Groovyスクリプトのブレークポイントの設定方法

Groovyスクリプトを使用して検証ルールまたは属性のデフォルト値を定義する場合は、これらのGroovyスニペットにブレークポイントを設定できます。

始める前に:

ADF宣言ブレークポイントでなくコード・ブレークポイントを使用する場合について理解しておくと役立ちます。詳細は、「JavaコードとGroovyスクリプトのブレークポイントの設定」を参照してください。

Groovyスニペット・ブレークポイントを設定してアプリケーションをデバッグする手順:

1. 「アプリケーション」ウィンドウで、ブレークポイントを設定するGroovyスクリプトを含むエンティティ・オブジェクトまたはビュー・オブジェクトを展開して、オブジェクトの.bcsファイルをダブルクリックします。

2. ソース・エディタで、該当する行の横の余白をクリックしてブレークポイントを設定し、デバッガを実行します。

3. アプリケーションがブレークポイントで停止したら、「データ」ウィンドウを使用して、現在のコンテキストのローカル変数および引数を調べることができます。

48.10.2 クラスおよびメソッド上にJavaブレークポイントを設定する方法

クラスおよびメソッド上にJavaブレークポイントを設定できます。ADFソース・コードがある場合、ソースにもJavaブレークポイントを設定することができます。ADFアプリケーションをデバッグしている場合、Javaコード・ブレークポイントでなくADF宣言ブレークポイントを使用することができないか確認することをお薦めします。詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

始める前に:

ADF宣言ブレークポイントでなくJavaコード・ブレークポイントを使用する場合について理解しておくと役立ちます。詳細は、「JavaコードとGroovyスクリプトのブレークポイントの設定」を参照してください。

次のタスクを完了する必要があります。

- ブレークポイントの使用を試みる前に、アプリケーションを実行し、欠落しているデータや不完全なデータ、無視されるアクションとメソッド、正しく実行されていないアクションとメソッド、あるいはその他の予期しない結果があるか調べることをお薦めします。問題がなければ、ADFログを有効にしてOracle ADFメッセージを「ログ」ウィンドウに送信するデバッグ構成を作成します。詳細は、「Oracle ADFデバッグ構成の作成方法」を参照してください。

Javaブレークポイントを設定してアプリケーションをデバッグするには:

1. メイン・メニューで「ナビゲート」→「Javaタイプに移動」を選択し(または[Ctrl]を押しながら[-]を押し)、ダイアログを使用して、処理が失敗しているエントリ・ポイントを表すOracle ADFクラスを見つけます。

注意:

JDeveloperにより、「アプリケーション」ウィンドウで現在フォーカスのあるユーザー・インタフェース・プロジェクトからのクラスが特定されます。ワークスペースに複数のユーザー・インタフェース・プロジェクトが含まれている場合は、デバッグの対象となるプロジェクトに現在フォーカスがあることを確認してください。

2. ソース・エディタでクラス・ファイルを開き、メソッドの文をトレース実行できるOracle ADFメソッド・コールを見つけます。

3. 目的のメソッドにブレークポイントを設定し、デバッガを実行します。

4. アプリケーションがブレークポイントで停止したら、「データ」ウィンドウを使用して、現在のコンテキストのローカル変数および引数を調べます。

ヒント:

データ、監視または「スマート・データ」ウィンドウで「ソースへ移動」ポップアップ・メニュー・コマンドを使用している場合、「戻る」ボタンを使用することにより実行ポイントに戻ることができます。「ナビゲート」メニューを使用して「戻る」ボタンにアクセスすることもできます。

アプリケーションを一時停止するブレークポイントをキー・ポイント上に設定した後は、「データ」ウィンドウにデータを表示できます。WebページとADFモデル・レイヤーの対話を効率的にデバッグするには、次のことを理解する必要があります。

- ADFページのライフサイクルと、起動されるメソッド・コール

- アプリケーションの処理過程でADFモデル・レイヤーに含まれる必要のあるローカル変数および引数

Oracle ADFの処理を理解しておくことは、ブレークポイントを選択的に設定し、アプリケーションによりロードされたデータを調べ、エラーの要因を特定するための手がかりとなります。

注意:

JSF Webページでは、ページのコンポーネントとデータの間の対話を管理するためにバッキングBeanを使用している場合もあります。他のJavaクラス・ファイルと同様に、ブレークポイントを設定してバッキングBeanをデバッグします。

48.10.3 ソース・エディタの使用を最適化する方法

ADFソース・ライブラリをプロジェクトに追加すると、ソース・エディタで使用可能になる有用なQuick JavaDoc機能([Ctrl]+[D])([Ctrl]+[D])にアクセスできるようになります。図48-49に、findSessionCookie()などのメソッドのためのQuick Javadoc機能を示します。

図48-49 ソース・エディタでのADF API上のQuick JavaDocの使用

48.10.4 ADFソース・コードを使用してブレークポイントを設定およびデバッグする方法

ADFソース・コードをロードした後、Javaコードと同じ方法で、現在のプロジェクトに対するOracle ADFコードをデバッグできます。つまり、[Ctrl]+[-]キーを押してOracle ADFで任意のクラス名を入力すると、JDeveloperによってそのソース・ファイルが自動的に開かれるため、必要に応じてブレークポイントを設定できます。

48.10.5 シンボリック・デバッグでデバッグ・ライブラリを使用する方法

Oracle ADFソース・コードをデバッグする際、デフォルトでは現在実行中のメソッドのパラメータまたはメンバー変数の記号情報は表示されません。

たとえば、ADFソース・コード・デバッグ・ライブラリのないデバッグ・セッションでは、図48-50に示すように、「_slot」など認識できない名前があることがあります。

図48-50 デバッグ・ライブラリがないとわかりにくいローカル記号

これらの名前はわかりにくいため、デバッグが困難になります。開発環境でデバッグする場合、ソースとともに提供されるADF JARファイルのデバッグ・バージョンを使用することにより、デバッグを容易にできます。

注意:

通常、提供されたデバッグ・ライブラリは、JDeveloperに同梱されている最適化されたJARファイルに比べ、実行時パフォーマンスがわずかに劣るため、テスト環境または本番環境では使用しないでください。

デバッグ・ライブラリJARは、デバッグ情報を追加してコンパイルされたバージョンのOracle ADF JARファイルです。デフォルトの最適化されたJARファイルでなく、これらのデバッグ用JARを使用すると、デバッガにすべての情報が表示されます。たとえば、図48-51に示すように、変数evidの名前が、デバッガで確認できるようになります。

図48-51 デバッガに表示されるシンボル情報

始める前に:

ADF宣言ブレークポイントでなくJavaコード・ブレークポイントを使用する場合について理解しておくと役立ちます。詳細は、「JavaコードとGroovyスクリプトのブレークポイントの設定」を参照してください。

次のタスクを完了する必要があります。

- 標準ライブラリJARを置き換える前に、JDeveloperが実行中でないことを確認します。実行中の場合、先に進む前に製品を終了します。

標準ライブラリJARをデバッグ・ライブラリJARに置き換えるには:

1. JDeveloperを終了した状態で、JDeveloperインストール先の./BC4J/libディレクトリで、既存の最適化されたJARファイルすべてのbackupサブディレクトリを作成します。たとえば、jdev11をJDeveloperのホーム・ディレクトリとすると、次のようになります。

C:\jdev11\BC4J\lib> mkdir backup
C:\jdev11\BC4J\lib> copy *.jar backup

2. デバッグ時にデバッグ記号を使用する各ADFライブラリに対して、C:\jdev11\BC4J\libディレクトリで対応する既存のライブラリに、一致するライブラリの_g.jarバージョンをコピーします。

これは、手順2で最適化されたJARファイルのバックアップをbackupディレクトリに作成してあるため安全です。

通常、デバッグ・ライブラリはデバッグ情報なしでコンパイルされたライブラリよりも実行速度が劣るため、この診断メッセージは実行タイミングでデバッグ・ライブラリを使用しないように注意を促すものです。

**************************************************************************
*** WARNING: Oracle BC4J debug build executing - do not use for timing ***
**************************************************************************

3. 最適化されたライブラリに戻すには、該当するJARファイルを./BC4J/lib/backupディレクトリから./BC4J/libディレクトリにコピーして戻します。

48.10.6 Javaコード・ブレークポイントの設定に関する必知事項

最初に、様々なJavaコード・ブレークポイントとそれを作成する場所を理解する必要があります。

デバッガの「ブレークポイント」ウィンドウを表示するには、メイン・メニューで「ウィンドウ」→「ブレークポイント」を選択するか、[Ctrl]、[Shift]、[R]を同時に押します。

「ブレークポイント」ウィンドウで、ポップアップ・メニューから「ブレークポイントの作成」を選択することで、新規のJavaコード・ブレークポイントを作成できます。表48-10に示すように、「ブレークポイント型」ドロップダウン・リストでは、作成するブレークポイントの種類をコントロールします。

注意:

「ブレークポイントの作成」ダイアログを使用して、ADFライフサイクル・フェーズ宣言ブレークポイントを作成することもできます。ADF宣言ブレークポイントの作成の詳細は、「ADFライフサイクル・フェーズ・ブレークポイントの設定方法および使用方法」を参照してください。

表48-10 様々な型のJavaブレークポイント

ブレークポイント型

ブレークポイントが発生する条件

用途

例外

このクラス(またはサブクラス)の例外がスローされる場合。

例外ブレークポイントは、例外がどこで発生するかわからないが、例外の種類(たとえば、java.lang.NullPointerException、java.lang.ArrayIndexOutOfBoundsException、oracle.jbo.JboException)はわかっているときに便利です。チェック・ボックス・オプションを使用することで、このクラスの例外を捕捉した場合にブレークするか、捕捉しなかった場合にブレークするかを制御できます。「参照」ボタンは、例外の完全修飾されたクラス名を検索するのに役立ちます。「例外クラス」コンボ・ボックスでは、最近使用した例外ブレークポイント・クラスが記憶されています。これはブレークポイント・ウィンドウでブレークポイントを作成する場合の、デフォルトのブレークポイント型であることに注意してください。

ソース

特定のパッケージで特定クラスの特定ソース行を実行する場合。

「ブレークポイントの作成」ダイアログでソース・ブレークポイントを作成することはほとんどありません。「ナビゲート」→「Javaタイプに移動」メニュー([Ctrl]を押しながら[-]を押す)を使用した後、必要な行番号までスクロールしてから(または「ナビゲート」→「指定行に移動」([Ctrl]を押しながら[G]を押す))、ブレークする行の左のブレークポイント余白をクリックする方法が簡単なためです。これは、新規のソース・ブレークポイントの作成と同じですが、パッケージ、クラスおよび行番号を手入力する必要がありません。

メソッド

指定されたクラスのメソッドが起動する場合。

メソッド・ブレークポイントは、問題のデバッグ中にコール・スタックで表示される、特定のメソッドにブレークポイントを設定するのに便利です。ソース・ブレークポイントを設定できるソースがそのクラスにある場合でも、この種のブレークポイントでは、クラスに対するソースがない場合もデバッガで停止します。

クラス

指定されたクラスのメソッドのいずれかが起動する場合。

クラス・ブレークポイントは、問題に関連するクラスのみが判明している場合に使用できますが、停止のための厳密なメソッドではありません。この種のブレークポイントはソースを必要としません。「参照」ボタンにより、ブレークするクラスの完全修飾名を迅速に検索できます。

ウォッチポイント

指定されたフィールドがアクセスまたは変更される場合。

監視ポイント・ブレークポイントは、クラス内部のコードが複数の異なる場所からメンバー・フィールドを直接変更する場合の問題の検出に使用できます。任意のフィールドが変更される際にデバッガを一時停止できます。クラスのソースのメンバー・フィールドを指し示し、ポップアップ・メニューから「監視ポイントの設定」メニュー項目を使用すると、このタイプのブレークポイントを作成できます。

48.10.7 コントロール向上のためのブレークポイントの編集方法

Javaコード・ブレークポイントの作成後は、ブレークポイントを右クリックして、ポップアップ・メニューから「編集」を選択すると、「ブレークポイント」ウィンドウでブレークポイントを編集できます。

注意:

「ブレークポイントの編集」ダイアログを使用して、ADF宣言ブレークポイントを編集することができます。ただし、他の一部の情報、たとえば「定義」タブの情報などは編集できません。「ブレークポイント」ウィンドウで、ポップアップ・メニューから「編集」を選択することで、「ブレークポイントの編集」ダイアログを起動することができます。ADF宣言ブレークポイントの作成の詳細は、「ADF宣言ブレークポイントの設定」を参照してください。

ブレークポイントの編集で使用できる機能は次のとおりです。

- このブレークポイントをグループ化する、論理ブレークポイント・グループ名を、同じグループ名の他のグループに関連付けます。ブレークポイント・グループは、1つの操作でブレークポイントのセット全体を簡単に有効化または無効化できます。

- ブレークポイントをヒットしたときに、デバッガ・アクションをブレークポイントに関連付けます。デフォルト・アクションでは、アプリケーションの状態を調査できるようにデバッガを停止しますが、警告音の追加、ログ・ファイルへの情報の書込み、ブレークポイントのグループの有効化または無効化も可能です。

- 条件が合う場合にのみデバッガを停止するよう、条件式をブレークポイントに関連付けます。次のように、ほとんどすべてのブール式が可能です。

- expr ==value

- expr.equals("value")

- expr instanceof.fully.qualified.ClassName

注意:

デバッガの「監視」ウィンドウを使用して、まず式を評価してその式が有効であるか確認します。

48.10.8 クラス・メンバーのビューのフィルタリング方法

デバッガを使用して、あらゆるクラスに対して、デバッガ・ウィンドウに表示されるメンバーをフィルタすることができます。デバッガの「データ」ウィンドウで任意のアイテムを選択し、ポップアップ・メニューから「プリファレンス」を選択すると、デバッガに表示されるメンバーと表示されないメンバー(場合によっては重要)をカスタマイズできるダイアログが表示されます。クラス・タイプを基準にフィルタすることで、デバッガの「データ」ウィンドウで必要になるスクロールの量を減らすことができます。これは特に、クラスのメンバーの少数のみに関連する場合に役立ちます。

48.10.9 Oracle ADFブレークポイントに関する必知事項

Oracle ADFソース・コードをロードした場合、表48-11にリストされているブレークポイントを使用してアプリケーションをデバッグできます。

これらのブレークポイントをヒットした際に「スタック」ウィンドウを参照してソースを確認することで、現状をよりよく把握することができます。

表48-11 よく使用されるADFブレークポイント

ブレークポイント

ブレークポイント型

用途

oracle.jbo.JboException

例外

このブレークポイントは、すべてのADFビジネス・コンポーネントの実行時例外のベース・クラス上にブレークポイントを設定するために便利です。

oracle.jbo.DMLException

例外

これは、トリガーまたは制約違反によって発生する例外が原因で失敗したDML操作など、データベースから生じる例外のベース・クラスです。

doIt()

メソッド

同じデバッグ機能を、ページ定義アクション・バインディング上にADF宣言ブレークポイントを設定することによって実行することもできます。「ページ定義アクション・バインディング・ブレークポイントの設定方法および使用方法」を参照してください。

このJavaブレークポイントの方を使用する場合、JUCtrlActionBindingクラス(oracle.jbo.uicli.bindingパッケージ)にあります。

これは、任意のADFアクション・バインディングの起動時に実行されるメソッドです。関連する場合、ロジックに踏み込んでパラメータを確認できます。

oracle.jbo.server.ViewObjectImpl.executeQueryForCollection

メソッド

これはビュー・オブジェクトがSQL問合せを実行する際にコールされるメソッドです。

oracle.jbo.server.ViewRowImpl.setAttributeInternal

メソッド

これは任意のビュー行属性が設定される際にコールされるメソッドです。

oracle.jbo.server.EntityImpl.setAttributeInternal

メソッド

同じデバッグ機能を、ページ定義属性値バインディング上にADF宣言ブレークポイントを設定することによって実行することもできます。「ページ定義値バインディング・ブレークポイントの設定方法および使用方法」を参照してください。

これは任意のエンティティ・オブジェクト属性が設定される際にコールされるメソッドです。

48.11 ビジネス・コンポーネント内のGroovy式のデバッグ

JDeveloperではGroovyスクリプト/式をデバッグできます。デバッガを起動するには、applicationmodule.xmlファイルを右クリックしてOracle ADF Model Testerを開始するか、またはJavaプログラムを実行するメイン・メソッドを含むJavaファイルを右クリックします。

.bcsファイルにはGroovy式/スクリプトが含まれています。.bcsファイルはエンティティ・オブジェクトまたはビュー・オブジェクトと関連付けられています。Groovy式がデバッグされると、例外があった場合、.bcsファイルの例外が発生した行で停止し、エラーを表示します。例外がない場合、デバッガはGroovy式の実行に進み、必要な計算データ(データ/スマート・データ/監視などのウィンドウにあります)を表示します。Javaソース・コード・ファイルでブレークポイントを設定するのと同じように、.bcsファイルにもブレークポイントを設定できます。デバッガが実行され、この.bcsファイルのブレークポイントが見つかると、デバッガはこのブレークポイントで実行を中断します。

.bcsファイル内のGroovyスクリプトをデバッグする手順は、Javaファイルのデバッグ手順と同じです。デバッガが.bcsファイルに入ったときに、様々なステップ操作(トレース実行、ステップ実行、ステップ・アウト)を使用して、デバッガによるGroovyスクリプトの実行を制御できます。ブレークポイントやステップ操作により実行が行で一時停止しているときなど、デバッガが.bcsファイルに入っているときに、デバッガのログ・ウィンドウを使用して実行データを表示できます。

48.11.1 Groovy式をデバッグする方法

JDeveloperではGroovy式をデバッグできます。Groovy式をデバッグするには、applicationmodule.xmlファイルを右クリックして「デバッグ」を選択し、Oracle ADF Model Testerを開始するか、またはJavaプログラムを実行するメイン・メソッドを含むJavaファイルを右クリックします。

Groovy式のデバッグを開始するには、次の2つの手順のいずれかを実行します。

1. モジュール(applicationmodule.xmlファイル)を右クリックして「デバッグ」を選択し、Oracle ADFモデル・テスターを起動します。

2. メイン・メソッドが含まれているJavaファイルを右クリックし、コンテキスト・メニューから「デバッグ」を選択してJavaプログラムの実行を開始します。または、Javaファイルをダブルクリックして開き、Javaファイル内を右クリックしてポップ・アップ・メニューから「デバッグ」を選択します。

48.11.2 Groovyのデバッグを制御する方法

.bcsファイルにブレークポイントを設定し、ステップ操作(トレース実行、ステップ実行、ステップ・アウト)を使用して、デバッガの実行を制御できます。

Groovyのデバッグを制御する方法:

1. .bcsファイルをダブルクリックして開きます。
図48-52は.bcsファイルに設定されたブレークポイントを示しています。デバッガがGroovyスクリプトを実行し、この.bcsファイルのブレークポイントが見つかると、デバッガはこのブレークポイントで実行を中断します。トレース実行、ステップ実行、カーソルまで実行を使用して、Groovyデバッグを制御することもできます。

ブレークポイントの詳細は、ブレークポイントの管理に関する項を参照してください。

図48-52 .bcsファイルに設定されたブレークポイント

2. .bcsファイル内のブレークポイントでデバッガが一時停止したときに、「デバッグ」メニューやツールバー・アイコン、対応するキーボード操作を使用して、ステップ操作を使用できます。トレース実行、ステップ実行、ステップ・アウトという操作があります。
ステップ操作の詳細は、メソッドにステップ・インする方法に関する項を参照してください。
アプリケーションではカーソル位置でのデバッガ実行もできます。詳細はカーソル位置での実行方法に関する項を参照してください。

実行中のデバッガを一時停止できます。その後プログラムの状態を精査し、デバッガの実行を再開します。デバッガの実行を中断し、再開する方法の詳細は、デバッガの中断と再開方法に関する項を参照してください。

デバッガ・セッションは任意の位置で終了できます。デバッガ・セッションを終了する方法の詳細は、デバッガ・セッションの終了方法に関する項を参照してください。

48.11.3 Groovy式のデバッグ時の処理

アプリケーションは.bcsファイルのGroovyスクリプトをデバッグします。ブレークポイントでデバッガの実行を中断する必要がある場合は、.bcsファイルにそうしたブレークポイントを設定します。デバッガがブレークポイントで中断したらその都度、またはステップ操作を実行したときは、データ/監視/スマート・データなどのウィンドウで情報を精査します。

デバッガがGroovyスクリプトを実行し、「データ」/「監視」/「スマート・データ」などのウィンドウに情報を表示します。図48-53では、ブレークポイントが行27に設定されていて、デバッガがこの行で停止しています。これが現在の実行行(赤色の矢印で表示)です。現在の実行行はメソッドmodifyEname()へのコールを示しています。このメソッドはEmpエンティティのEname属性を変更します。

図48-53 JavaファイルのGroovy式を参照する行に設定されたブレークポイント

Ename属性にはバリデータが定義されています。バリデータはGroovyスクリプト/式を使用して定義されています。このGroovyスクリプトは(他のユース・ケースに定義されている他のGroovyスクリプトとともに).bcsファイルにあります。そのため、行27のこのメソッドをトレース実行すると、アプリケーションがこの.bcsファイルにアクセスし、バリデータを実行します。図48-54は.bcsファイルの行23の事前設定されたブレークポイントの位置でデバッガが停止しているところを示しており、バリデータも実行されています。

図48-54 デバッガがJavaファイルから.bcsファイルに移動し、.bcsファイルのブレークポイントで停止

この時点でデバッグを再開するか、デバッグを終了するか、またはステップ操作を使用します。詳細は「Groovyのデバッグを制御する方法」を参照してください。

48.12 JUnitを使用した回帰テスト

ビジネス・サービスのテストは、アプリケーション開発プロセスの重要な部分です。アプリケーション・モジュールで提供される機能を実行する一連のJUnit回帰テストを作成することで、新機能、バグ修正またはリファクタ実行のためにアプリケーションが不安定にならないことを確認できます。JDeveloperにはJUnit回帰テストの作成に対する統合サポートがあり、アプリケーションのテストを簡単に実行できます。JUnitテストの実行に関する統合サポートでは、チームの開発者であれば、マウスを1回クリックするだけでテスト・スイートを実行できます。すべてのチーム・メンバーがシステムの自らの変更箇所を確認するためにテストを実行する機会が増加します。また、Apache Antビルド・スクリプトを作成および実行するためにJDeveloperの統合サポートを使用すると、テストの実行を自動ビルド・プロセスに簡単に組み込むこともできます。アプリケーション・モジュールのJUnitテストの作成、実行、およびAntビルド・スクリプトへの統合を行うことができます。

JDeveloperでは、JUnitテスト・ケース、テスト・フィクスチャ、およびテスト・スイートを生成できます。テスト・ケースを作成し、単一または複数のJavaクラスを含む個別のJavaファイルをテストすることができます。JUnitテスト・ケースによって再利用されるJUnitテスト・フィクスチャを作成できます。これらのすべてのテスト・ケースは、JUnitテスト・スイートにグループ化し、ユニットとして一括して実行できます。

アプリケーション・モジュールがプロジェクトにあるときは、JUnit BC4Jテスト・スイート・ウィザードを使用してテスト・スイートを作成することもできます。ウィザードでは、アプリケーション・モジュールの各ビュー・オブジェクトについてテスト・スイート、テスト・フィクスチャおよびテスト・ケースが生成されます。

回帰テストを含む個別のプロジェクトを作成するか、テスト・ファイルを既存のプロジェクトに統合することもできます。ADFビジネス・コンポーネント・テストを作成している場合は、テスト用に別のプロジェクトを作成する必要があります。

テスト用のプロジェクトを別個に作成することには、次の利点があります。

- JUnitに依存せずにベース・プロジェクトを編集できる

- テスト・クラスを除外せずに、ベース・プロジェクトをデプロイメント用にパッケージ化できる

JUnitテストのために別個のプロジェクトを作成する場合、テスト対象パッケージの構造と同一のディレクトリ構造を作成することをお薦めします。テスト・クラスに名前を付ける場合、テストされているパッケージを簡単に特定できる命名規則を使用することをお薦めします。たとえば、myClass.javaをテストする場合、テスト・クラスにmyClassTest.javaという名前を付けます。

プロジェクトを別々にすることにも多くの利点がありますが、場合によっては、テストをプロジェクトに含める方が簡単です。

プロジェクトについて「テストの作成」ウィザードを使用すると、JUnitテスト・ケース、テスト・フィクスチャ、またはテスト・スイートを作成できます。ただし、これらのテストがデプロイメントに含まれないようにする場合は、テストを外部に切り離して独自のプロジェクトにすることもできます。

ヒント:

テスト作成のウィザードが表示されない場合は、続行する前にJDeveloperの「ヘルプ」→「更新の確認」機能を使用して、JUnit統合拡張機能をインストールします。

各テスト・ケース・クラスには、テスト・ケースによって必要とされるリソースの初期化を可能にし、その後それらをクリーン・アップするためにJUnitによって起動される、setUp()およびtearDown()メソッドが含まれます。これらのテスト・ケース・メソッドは、対応するsetUp()およびtearDown()メソッドを起動して、各テスト・ケース実行のテスト・フィクスチャを準備およびクリーン・アップします。テスト・ケース内のテストの1つがアプリケーション・モジュールへのアクセスを必要とする場合は常に、テスト・フィクスチャのgetApplicationModule()メソッドを使用します。このメソッドは、テスト・ケースの最後で、setUp()への最初のコールからtearDown()への最後のコールまでの間に、テスト・フィクスチャ・クラスのメンバー・フィールドに保存された、同じアプリケーション・モジュールのインスタンスを戻します。

JDeveloperはJUnit 4をサポートしているため、明示的にメソッドsetUp()およびtearDown()に名前を付けなくても注釈を使用できます。これらの注釈、@Beforeおよび@Afterを使用すると、必要に応じて、複数のsetupおよびteardownメソッド(たとえば、継承したメソッドなど)を使用できます。

生成されたExampleModuleConnectFixtureは、アプリケーションの取得および解放の詳細をカプセル化する、JUnitテスト・フィクスチャです。これには、アプリケーション・モジュールのインスタンスを作成するためにConfigurationクラスのcreateRootApplicationModule()メソッドを使用する、setUp()メソッドが含まれます。tearDown()メソッドは一致するreleaseRootApplicationModule()メソッドをコールして、アプリケーション・モジュールのインスタンスを解放します。

自身のテスト・メソッドでは、oracle.jboパッケージで使用可能な任意のプログラムのAPIを使用して、アプリケーション・モジュールおよびそのデータ・モデル内のビュー・オブジェクト・インスタンスを扱うことができます。また、ApplicationModuleインタフェースをカスタム・インタフェースにキャストして、テストがそのジョブの一部としてカスタム・サービス・メソッドを起動するようにします。それぞれのテスト中に、JUnitフレームワークによって提供されている1つ以上のassertXxx()メソッドをコールして、特定の式の予測結果がどのようになる必要があるかをアサートします。テスト・スイートを実行する際、任意のテスト・ケースの任意のテストに失敗したアサーションが含まれる場合、「JUnitテスト・ランナー」ウィンドウに失敗したテストが赤の失敗アイコンとともに表示されます。

JUnitテスト生成ウィザードによってデータ・モデルの各ビュー・オブジェクト・インスタンスに対してスケルトン・テスト・ケース・クラスが生成され、それぞれのクラスにはtestAccess()という名前の1つのテスト・メソッドが含まれます。このメソッドには、ビュー・オブジェクト・インスタンスが存在することをテストするassertNotNull()メソッドへのコールが含まれます。

// In ViewInstanceNameTest.java test case class
public void testSomeMeaningfulName() {
// test assertions here
}

生成されたテスト・ケースそれぞれに、そのテスト・ケース実行の一部としてJUnitフレームワークが実行する1つ以上のテスト・メソッドを含めることができます。接頭辞testで始まる名前を持つクラスでpublic voidメソッドを作成するか、注釈@Testを使用するだけで、テストをテスト・ケースに追加できます。

48.12.1 JUnit拡張機能を取得する方法

JUnitを利用可能にし、メニュー・システムに表示されるようにするには、JDeveloperに拡張機能としてロードする必要があります。

始める前に:

JUnitを使用した回帰テストによるテスト・ケースの作成に関する知識が役立つ場合があります。詳細は、「JUnitを使用した回帰テスト」を参照してください。

JUnit拡張機能をロードするには:

1. メイン・メニューで、「ヘルプ」→「更新の確認」を選択します。

2. 「更新の確認」ダイアログの「ソース」ページで、「更新センターの検索」と「Oracleの公式拡張機能と更新」を選択し、「次へ」をクリックします。

JUnit zipファイルがある場合、またはJUnitの選択が「可能な更新」リストに表示されない場合は、「ローカル・ファイルからインストール」を選択してJUnit zipファイルをロードします。

3. 「更新」ページで、図48-55に示すように、「JUnit統合」を選択し、「次へ」をクリックします。

図48-55 JUnit拡張機能を追加するための「更新の確認」ウィザード

4. 「ライセンス契約」ページで、「同意する」、「終了」の順にクリックします。

48.12.2 JUnitテスト・ケースの作成方法

JUnitテスト・ケースを作成する前に、テストされるプロジェクトの作成を完了している必要があります。

始める前に:

JUnitを使用した回帰テストによるテスト・ケースの作成に関する知識が役立つ場合があります。詳細は、「JUnitを使用した回帰テスト」を参照してください。

JUnitテスト・ケースを作成するには:

1. 「アプリケーション」ウィンドウで、テスト・ケースを作成するプロジェクトを右クリックし、「新規」、「ギャラリから」の順にクリックします。

2. 「新規ギャラリ」で、「一般」を開き、「ユニット・テスト」、続いて「テスト・ケース」を選択し、「OK」をクリックします。

3. 「テスト・ケースの作成」ダイアログの「テストするクラスの選択」ページで、「テスト中のクラス」に入力するか、「参照」をクリックします。

4. 「クラス・ブラウザ」ダイアログで、テストするクラスを確認します。または、「クラス名を一致」フィールドに最初の文字を入力します。「一致するクラス」リストは識別しやすいようにフィルタ処理されます。

たとえば、Summitと入力すると、図48-56に示すように、リストが4つの項目にまでフィルタされます。

図48-56 テスト対象のクラス・ファイルを選択するためのクラス・ブラウザ

クラスを選択し、「OK」をクリックして、ダイアログを閉じます。「次へ」をクリックします。

5. テストする個別のメソッドを選択し、「次へ」をクリックします。

たとえば、図48-57では、チェックされた4つのメソッドがテストされます。

図48-57 テスト対象のメソッドを選択するための「テスト・ケースの作成」ダイアログ

6. 「テスト・ケース・クラスの設定」ダイアログで、テスト・ケース、パッケージ、その拡張対象のクラスの名前を入力し、JUnitでスタブが作成される組込み機能のリストを選択します。「次へ」をクリックします。

たとえば、図48-58では、JUnitが、Oracle ADFのSummitサンプル・アプリケーションのoracle.summit.baseパッケージにあるSummitViewObjectImplTestテスト・ケースのsetUp()メソッドに対するスタブを作成します。

図48-58 テスト対象のクラスを設定するための「テスト・ケースの作成」ダイアログ

7. 「テスト・フィクスチャの選択」ページで、テスト・ケースに追加するテスト・フィクスチャを選択するか、「参照」をクリックします。

8. テスト・ケースに追加するテスト・フィクスチャがすべてリスト中で選択されていることを確認し、「終了」をクリックします。

48.12.3 JUnitテスト・フィクスチャの作成方法

クラスまたはメソッドに対して複数のテストが必要な場合、JUnitテスト・フィクスチャを作成することをお薦めします。JUnitテキスト・フィクスチャを使用すると、テストを初期化するために必要なテスト・コードの重複作成を防止することができます。

始める前に:

JUnitを使用した回帰テストによるテスト・ケースの作成に関する知識が役立つ場合があります。詳細は、「JUnitを使用した回帰テスト」を参照してください。

JUnitテスト・フィクスチャを作成するには:

1. 「アプリケーション」ウィンドウで、テスト・フィクスチャを作成するプロジェクトを右クリックし、「新規」、「ギャラリから」の順にクリックします。

2. 「新規ギャラリ」で、「一般」を開き、「ユニット・テスト」、続いて「テスト・フィクスチャ」を選択し、「OK」をクリックします。

3. 「テスト・フィクスチャの作成」ダイアログで、テスト・フィクスチャの名前、パッケージ、およびその拡張対象のクラスを入力します。

4. 「OK」をクリックします。

48.12.4 JUnitテスト・スイートの作成方法

JUnitテスト・スイートを作成する前に、テスト・スイートに追加できるJUnitテスト・ケースの作成を完了しておくことをお薦めします。

始める前に:

JUnitを使用した回帰テストによるテスト・ケースの作成に関する知識が役立つ場合があります。詳細は、「JUnitを使用した回帰テスト」を参照してください。

JUnitテスト・スイートを作成するには:

1. 「アプリケーション」ウィンドウで、テスト・スイートを作成するプロジェクトを右クリックし、「新規」、「ギャラリから」の順にクリックします。

2. 「新規ギャラリ」で、「一般」を開き、「ユニット・テスト」、続いて「テスト・スイート」を選択し、「OK」をクリックします。

3. 「テスト・スイートの作成」ダイアログの「テスト・スイート・クラスの設定」ページで、テスト・スイート、パッケージ、およびその拡張対象のクラスの名前を入力します。「次へ」をクリックします。

たとえば、図48-59では、java.lang.Objectクラスを拡張するAllTestsテスト・スイートが作成されます。

図48-59 「テスト・スイートの作成」ウィザード

4. 「テスト・スイートの作成」ダイアログの「テスト・ケースの選択」ページで、テスト・スイートに組み込むすべてのテスト・ケースが選択されていることを確認します。作成したテストケースは、リストに移入されます。組み込まないテスト・ケースがあれば、その選択を解除します。「終了」をクリックします。

48.12.5 ビジネス・コンポーネント・テスト・スイートの作成方法

作成されるテキスト・フィクスチャは、接続数を減らすシングルトン・クラスです。各テスト・ケースで接続または切断する場合は、JUnit 4の注釈、@Beforeおよび@Afterを使用してテスト・ケースをカスタマイズします。

JUnit BC4Jテスト・スイート・ウィザードでは、アプリケーション・モジュールの各ビュー・オブジェクトに対してテストが生成されます。アプリケーション・モジュールがメソッドをエクスポートしていない場合、ウィザードによって、アプリケーション・モジュールそのもののテストも生成されます。生成されるビュー・オブジェクト・クラスの形式はview_objectVOTest.javaです。パッケージにはpackage.view.viewobjectVOという形式で配置されます。このときpackageはアプリケーション・モジュール・パッケージです。生成されるアプリケーション・モジュール・テストの形式はapplication_moduleAMTest.javaです。パッケージにはpackage.applicationModuleという形式で配置されます。生成されるテスト・フィクスチャ・クラスの形式はapplicationmoduleAMFixture.javaです。アプリケーション・モジュール・テストと同じパッケージに配置されます。

生成されるすべてのテスト・スイート・クラスの形式はAllapplicationmoduleTest.javaです。アプリケーション・モジュールのパッケージ名と同じ名前でパッケージに配置されます。

各アプリケーション・モジュールまたはビュー・オブジェクト・テストについてテスト・ケースのXMLファイルも生成されます。このXMLファイルには、アプリケーション・モジュールまたはビュー・オブジェクト・テスト・ケースで定義されているテスト・メソッドが含まれます。重複が多くなりすぎる可能性があるため、ベース・クラス(ある場合)のテスト・メソッドは含まれません。

たとえば、パッケージStoreAPack内に、ビュー・オブジェクトEmployees1View1およびEmployees1View2を含むStoreAAppModuleという名前のアプリケーション・モジュールのテスト・スイートを作成したら、図48-20に示すように、「アプリケーション」ウィンドウにはテスト階層が表示されます。

図48-60 ビジネス・コンポーネントのテスト・スイートが表示された「アプリケーション」ウィンドウ

始める前に:

JUnitを使用した回帰テストによるテスト・ケースの作成に関する知識が役立つ場合があります。詳細は、「JUnitを使用した回帰テスト」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールによるビジネス・サービスの実装」の説明に従って、データ・モデル・プロジェクト内にアプリケーション・モジュールを作成します。

ビジネス・コンポーネント・テスト・スイートを作成するには:

1. メイン・メニューで、「ファイル」→「新規」→「ギャラリから」を選択します。

ビジネス・コンポーネント・テスト用に別のプロジェクトを作成します。

2. 「新規ギャラリ」で、「一般」を開き、「プロジェクト」、続いて「Javaアプリケーション・プロジェクト」を選択し、「OK」をクリックします。

3. Javaプロジェクトの作成ウィザードの「プロジェクト名」ページで、テスト・プロジェクトの名前とディレクトリ・パスを入力し、「次へ」をクリックします。

4. プロジェクトのJava設定ページで、パッケージ名、プロジェクトのJavaソース・コードのディレクトリ、および出力クラス・ファイルが配置される出力ディレクトリを入力し、「終了」をクリックします。

5. 「アプリケーション」ウィンドウで、テストするアプリケーション・モジュールをダブルクリックします。

6. 概要エディタで、「Java」ナビゲーション・タブをクリックします。

7. 概要エディタの「Java」ページで、「Javaクラス」セクションの「編集」アイコンをクリックします。

8. 「Javaオプションの選択」ダイアログで「アプリケーション・モジュール・クラスの生成」を選択して、「OK」をクリックします。

9. 概要エディタの「Java」ページで、「クラス・インタフェース」セクションの「編集」アイコンをクリックします。

10. 「クライアント・インタフェースの編集」ダイアログで、テストするメソッドを「選択済」ペインに移動して、「OK」をクリックします。

11. 「アプリケーション」ウィンドウで、作成したテスト・プロジェクトを右クリックし、「新規」→「ギャラリから」をクリックします。

12. 「新規ギャラリ」で、「一般」を展開し、「ユニット・テスト」、「ビジネス・コンポーネントのテスト・スイート」の順に選択して、「OK」をクリックします。

13. JUnit BC4Jテスト・スイート・ウィザードの「テストの構成」ページで次の値を選択し、「次へ」をクリックします。

- ビジネス・コンポーネント・プロジェクト: テストするアプリケーション・モジュールを含むプロジェクトを選択します。

- アプリケーション・モジュール: テストするアプリケーション・モジュールを選択します。

- 構成: ローカル・アプリケーション・モジュールまたは共有アプリケーション・モジュールを選択します。

- 「ベース・クラスのテスト」→「アプリケーション・モジュール拡張」: 様々なベース・クラスを指定できます。生成されるテスト・ケース・クラスはそのベース・クラスから拡張されます。このとき、ベース・クラスのすべてのpublic抽象メソッドの本体は単純なデフォルトの実装になります。

- 「ベース・クラスのテスト」→「ビュー・オブジェクト拡張」: ビュー・オブジェクトが拡張するクラスを指定できます。生成されるテスト・ケース・クラスはそのベース・クラスから拡張されます。このとき、ベース・クラスのすべてのpublic抽象メソッドの本体は単純なデフォルトの実装になります。

14. 「サマリー」ページで選択内容を確認して、「終了」をクリックします。

48.12.6 Business Componentsテスト・フィクスチャの作成方法

ビジネス・コンポーネントのテスト・スイートを作成すると、ビジネス・コンポーネントのテスト・フィクスチャも一緒に作成されます。また、ビジネス・コンポーネントのテスト・フィクスチャを個別に作成することもできます。

生成されるテスト・フィクスチャ・クラスの形式はapplicationmoduleAMFixture.javaです。形式がpackage.applicationModuleのパッケージに収められます。このとき、packageはアプリケーション・モジュール・パッケージです。

始める前に:

JUnitを使用した回帰テストによるテスト・ケースの作成に関する知識が役立つ場合があります。詳細は、「JUnitを使用した回帰テスト」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・モジュールによるビジネス・サービスの実装」の説明に従って、データ・モデル・プロジェクト内にアプリケーション・モジュールを作成します。

ビジネス・コンポーネント・テスト・フィクスチャを作成するには:

1. メイン・メニューで、「ファイル」→「新規」→「ギャラリから」を選択します。

ビジネス・コンポーネント・テスト用に別のプロジェクトを作成します。

2. 「新規ギャラリ」で、「一般」を開き、「プロジェクト」、続いて「Javaアプリケーション・プロジェクト」を選択し、「OK」をクリックします。

3. Javaプロジェクトの作成ダイアログの「プロジェクト名」ページで、テスト・プロジェクトの名前とディレクトリ・パスを入力し、「次へ」をクリックします。

4. プロジェクトのJava設定ページで、パッケージ名、ソース・ディレクトリおよび出力ディレクトリを入力し、「終了」をクリックします。

5. 「アプリケーション」ウィンドウで、テストするアプリケーション・モジュールをダブルクリックします。

6. 概要エディタで「Java」ナビゲーション・タブをクリックし、「Javaクラス」セクションの「編集」アイコンをクリックします。

7. 「Javaオプションの選択」ダイアログで「アプリケーション・モジュール・クラスの生成」を選択して、「OK」をクリックします。

8. 概要エディタの「Java」ページで、「クラス・インタフェース」セクションの「編集」アイコンをクリックします。

9. 「クライアント・インタフェースの編集」ダイアログで、テストするメソッドを「選択済」ペインに移動して、「OK」をクリックします。

10. 「アプリケーション」ウィンドウで、作成したテスト・プロジェクトを右クリックし、「新規」→「ギャラリから」をクリックします。

11. 「新規ギャラリ」で、「一般」を展開し、「ユニット・テスト」、「ビジネス・コンポーネントのテスト・フィクスチャ」の順に選択して、「OK」をクリックします。

12. JUnit BC4Jテスト・フィクスチャ・ウィザードの「テストの構成」ページで次の値を選択し、「次へ」をクリックします。

- ビジネス・コンポーネント・プロジェクト: テストするアプリケーション・モジュールを含むプロジェクトを選択します。

- アプリケーション・モジュール: テストするアプリケーション・モジュールを選択します。

- 構成: ローカル・アプリケーション・モジュールまたは共有アプリケーション・モジュールを選択します。

13. 「サマリー」ページでテスト・フィクスチャ・クラスを確認して、「終了」をクリックします。

48.12.7 Antビルド・スクリプトの一部としてのJUnitテスト・スイートの実行方法

Apache Antは、JDeveloperによる設計時サポートが提供されている、一般的なクロス・プラットフォーム・ビルド・ユーティリティです。Antの組込みjunitおよびjunitreportタスクを使用することにより、JUnitテストの自動実行とテスト出力レポート生成を組み込むことができます。次の例は、Ant build.xmlファイルのtestsと呼ばれるタスクを示しています。これは、testsターゲットを実行する前にAntが確実に実行しているbuildおよびbuildTestsターゲットに依存します。

<target name="testCustomizations" depends="compileExtensionClasses">
<junit printsummary="yes" haltonfailure="yes">
<classpath refid="customization.classpath">
<pathelement location="${customization.build.dir}"/>
</classpath>
<formatter type="plain"/>
<test name="oracle.customization.tests.AllTests"/>
</junit>
</target>

junitタグには、実行するテスト・スイート・クラスを識別するネストされたtestタグが含まれ、結果をレポートするディレクトリが指定されます。junitreportタグにより、Javadocの形式に類似するHTMLページのコレクションにテスト結果を書式設定できるようになります。

AntからJUnitテストの実行を試行するには、「アプリケーション」ウィンドウでbuild.xmlファイルを選択し、ポップアップ・メニューから「Antターゲットの実行」→「テスト」を選択します。

49 Fusion Webアプリケーションのリファクタ

この章では、ソース・ファイル、構成ファイル、オブジェクト、属性およびFusion Webアプリケーションの要素の名前変更、移動および削除に関する注意事項を説明します。ほとんどの場合、JDeveloperでリファクタを完全に実行できます。ただし、リファクタする前に、いくつかの手動ステップを完了する必要があることがあります。

この章の内容は次のとおりです。

- Fusion Webアプリケーションのリファクタについて

- ファイルの名前の変更

- JSFページの移動

- pagedef.xmlバインディング・オブジェクトのリファクタ

- ADFビジネス・コンポーネントのリファクタ

- ADFビジネス・コンポーネント・オブジェクト属性のリファクタ

- 名前付き要素のリファクタ

- ADFタスク・フローのリファクタ

- DataBindings.cpxファイルのリファクタ

- リファクタの制限

- ADFビジネス・コンポーネント・プロジェクト構成ファイル (.jpx)の移動

49.1 Fusion Webアプリケーションのリファクタについて

JDeveloperには、アプリケーションが使用する属性の名前と場所、名前付き要素、ファイル、ADFビジネス・コンポーネント・オブジェクトを変更できるようにするリファクタ・オプションが用意されています。これらのリファクタ・オプションは、行った変更と、その変更に依存するアプリケーションの他の部分とを同期させます。たとえば、「名前の変更」オプションを使用して、ビュー・オブジェクトなどのADFビジネス・コンポーネント・オブジェクトの名前を変更すると、他のXMLソース・ファイル内にそのオブジェクトへの参照があれば、その参照の名前も変更されます。

Fusion Webアプリケーションでは、JDeveloperのリファクタ・アクション(移動、名前変更および削除)を使用して、オブジェクトの名前と場所を変更できます。これらのアクションは、「リファクタ」のメイン・メニューと、「アプリケーション」ウィンドウのオブジェクト・タイプごとのポップアップ・メニューから使用できます。移動、名前変更および削除操作は、ほとんどの(すべてではない)オブジェクトおよびファイル・タイプに使用できます。「アプリケーション」ウィンドウでオブジェクトまたはファイルが選択される場合、適用されるリファクタ操作は「リファクタ」メニューで有効にされます。

また、JDeveloperでリファクタできる対象には制限があります。場合によっては、プロジェクト構成ファイルの移動など、従うことのできる手動手順があります。詳細は、「リファクタの制限」を参照してください。

49.1.1 リファクタのユースケースと例

開発中、必要に応じてアプリケーションのニーズを満たすように、エンティティ・オブジェクトなどのオブジェクトを作成します。その後、不要になったオブジェクトを削除したり、命名規則に合うようにオブジェクトの名前を変更したり、一連のオブジェクトを別のパッケージに移動してその場所をまとめたりする必要が生じる場合があります。JDeveloperを使用して、これらのオブジェクトをリファクタして更新し、また、他のオブジェクトでのこれらのオブジェクトへの参照も更新して、アプリケーション全体の整合性を維持できます。

49.1.2 リファクタの追加機能

JDeveloperで使用できるその他のリファクタ機能を理解しておくと役立ちます。次に、関連する他の機能へのリンクを示します。

- JDeveloper機能を使用したJavaコードのリファクタの詳細は、『Oracle JDeveloperによるアプリケーションの開発』のJavaプロジェクトのリファクタに関する項を参照してください。

49.2 ファイルの名前の変更

次のメソッドを使用して、構成ファイルなどのファイルの名前を変更できます。

- 「アプリケーション」ウィンドウで、ファイルを選択し、メイン・メニューから「ファイル」→「名前の変更」を選択します。

- 「アプリケーション」ウィンドウで、ファイルを右クリックして、「リファクタ」→「名前の変更」を選択します。

- ソース・エディタで、クラス名を選択し、右クリックして「名前の変更」を選択します。

ディレクトリ間でファイルを移動するには、「移動」メニュー項目を使用します。

ファイルの名前を変更したり移動したりすると、そのファイルへの参照もすべて更新されます。たとえば、ページ定義ファイルの名前を変更すると、DataBindings.cpxファイル内のエントリもそれに応じて更新されます。

ADFビジネス・コンポーネント・オブジェクトに関連付けられたXMLファイルやJavaファイルの名前を、そのオブジェクトと無関係に変更することはできません。これらのファイルは同期を維持する必要があるからです。詳細は、「ADFビジネス・コンポーネントのリファクタ」を参照してください。

49.3 JSFページの移動

他のリファクタ操作に加えて、JSFページのパッケージを変更できます。「アプリケーション」ウィンドウで、JSFページを右クリックして「リファクタ」→「移動」を選択し、ページを別のパッケージに移動します。JSFページを別のパッケージに移動すると、次のものが更新されます。

- ページとそのパッケージを参照するfaces-config.xmlファイル

- ページに関連付けられるビューを含むADFタスク・フロー

- ページへのDataBindings.cpxマッピング

49.4 pagedef.xmlバインディング・オブジェクトのリファクタ

リファクタできるpagedef.xmlバインディング・オブジェクトには、バインディングと実行可能ファイルが含まれます。詳細は、「ページ定義ファイルでの作業」を参照してください。

始める前に:

リファクタに使用できるオプションに関する知識が役立つ場合があります。詳細は、「Fusion Webアプリケーションのリファクタについて」を参照してください。

JDeveloperで、リファクタするオブジェクトを含むアプリケーションを開きます。

pagedef.xmlバインディング・オブジェクトをリファクタするには:

1. 「アプリケーション」ウィンドウで、ADFフォームまたは選択リストなどのバインド・オブジェクトを追加したページ・ノードを選択します。

2. ページ・ノードを右クリックして、「ページ定義に移動」を選択します。

ページにページ定義が存在しない場合は、「ページ定義の作成」ダイアログが表示されます。「OK」をクリックすると、そのページのページ定義が作成されます。

3. 概要エディタで、「バインディングと実行可能ファイル」タブをクリックします。

図49-1に示すように、ページで定義されているリスト・バインディングやイテレータ・バインディングなどのデータ・バインディングが、「バインディングと実行可能ファイル」の下に表示されます。

図49-1 「ページ・データ・バインディング定義」概要タブ

4. 「構造」ウィンドウで、データ・バインディングまたは実行可能ファイルを右クリックして「リファクタ」を選択し、「名前の変更」や「削除」などのリファクタ・オプションを選択します。

5. バインディング、実行可能ファイルおよびデータ・コントロールの間の使用方法を表示するには、バインディングや実行可能ファイルを右クリックして、「使用方法の検索」を選択します。

49.5 ADFビジネス・コンポーネントのリファクタ

ADFビジネス・コンポーネントには、ビュー・オブジェクト、エンティティ・オブジェクトなどのオブジェクトが含まれます。表49-1で、ADFビジネス・コンポーネントのリファクタのサポートについて説明します。

表49-1 「ADFビジネス・コンポーネントのリファクタ」

アクション

結果

移動

オブジェクトを異なるパッケージまたはディレクトリへ移動し、すべての参照を更新する。

削除

JDeveloperでオブジェクト上のすべての依存性が表示され、強制削除が許可される。この時点ではアプリケーションが機能しないことがある。ブレーク中の参照を解決しなければならないことがある。

名前の変更

ADFビジネス・コンポーネント・オブジェクトは、XMLファイルによって定義される。このXMLファイルのファイル名はオブジェクト名と同一である。たとえば、Persons1Viewという名前のビュー・オブジェクトのためのXMLファイルの名前は、Persons1View.xmlである。名前を変更すると、Name属性が変更され、XMLファイルの名前が変更され、すべての参照が更新される。

たとえば、あるエンティティの名前(Customer)は、XMLファイルに属性(name=Customer)として格納されます。このXMLファイルの名前はエンティティ名と同一(Customer.xml)である。

使用方法の検索

JDeveloperによってオブジェクトのすべての依存性が表示される。

注意:

抽象レイヤーを越えてリファクタすることはありません。たとえば、Deptエンティティ・オブジェクトに基づいてビュー・オブジェクトが作成された場合、デフォルトでDeptViewという名前になります。Deptエンティティ・オブジェクトの名前を変更すると、DeptViewのエンティティの慣用名は更新されますが、ビュー・オブジェクトの名前は変更されません。

始める前に:

リファクタに使用できるオプションに関する知識が役立つ場合があります。詳細は、「Fusion Webアプリケーションのリファクタについて」を参照してください。

JDeveloperで、リファクタするオブジェクトを含むアプリケーションを開きます。

ADFビジネス・コンポーネント・オブジェクトをリファクタするには:

1. 「アプリケーション」ウィンドウで、プロジェクトを開き、「アプリケーション・ソース」ノードを開き、次にリファクタするオブジェクトを含むパッケージを開きます。

2. オブジェクトを右クリックして、「リファクタ」およびリファクタ・オプションを選択します。

- オブジェクトの名前を変更するには、「名前の変更」を選択します。
「名前の変更」ダイアログにオブジェクトの現在の名前が表示されます。新しいオブジェクト名を入力し、「OK」をクリックしてリファクタを続行するか、「取消」をクリックして取り消します。

オプションで、「プレビュー」を選択して「OK」をクリックし、「ログ」ウィンドウに使用方法を表示できます。ここからリファクタを続行したり、取り消すことができます。「ログ」ウィンドウで使用方法をクリックすると、使用方法を含むファイルがソース・エディタで開き、含まれている行が強調表示されます。

- オブジェクトの場所を変更するには、「移動」を選択します。
「移動」ダイアログにオブジェクトの現在の場所が表示されます。新しいパッケージ名を入力するか、「参照」をクリックしてそのパッケージに移動します。「OK」をクリックしてリファクタを続行するか、「取消」をクリックして取り消します。

- オブジェクトを削除するには、「削除」を選択します。
「削除の確認」ダイアログに、オブジェクトの名前と使用方法の検索が表示されます。「使用方法の表示」をクリックして、オブジェクトの使用場所を表示します。「はい」をクリックしてリファクタを続行するか、「いいえ」をクリックして取り消します。「プレビュー」をクリックして、「ログ」ウィンドウに結果を表示します。ここからリファクタを続行したり、取り消すことができます。「ログ」ウィンドウで使用方法をクリックすると、使用方法を含むファイルがソース・エディタで開き、含まれている行が強調表示されます。

デフォルトでは、JDeveloperが現在のアプリケーション内でオブジェクトの使用方法を検索します。検索の範囲を変更するには、「次で使用方法の検索中」ドロップダウン・リストから選択するか、「ワーキング・セットの管理」アイコンをクリックします。

49.6 ADFビジネス・コンポーネント・オブジェクト属性のリファクタ

表49-1で、ADFビジネス・コンポーネントのエンティティ・オブジェクトおよびビュー・オブジェクトの属性のリファクタのサポートについて説明します。

表49-2 属性のリファクタ

アクション

結果

移動

サポートされない。

削除

JDeveloperで属性上のすべての依存性が表示され、強制削除が許可される。この時点ではアプリケーションが機能しないことがある。ブレーク中の参照を解決しなければならないことがある。

名前の変更

属性は、エンティティ・オブジェクトやビュー・オブジェクト内で表現されるデータ要素を共有する(詳細は「エンティティ・オブジェクトについて」を参照)。属性の名前を変更すると、属性への参照が更新される。名前を変更すると、Name属性が変更され、すべての参照が更新される。ここには、アプリケーション・モジュールの生成されたサービスで使用されるビュー属性のサービス実装の更新も含まれる。

属性の名前を変更しても、それが表すデータは変更されず、基礎となる表の列名も変更されない。

使用方法の検索

JDeveloperによって属性のすべての依存性が表示される。

始める前に:

リファクタに使用できるオプションに関する知識が役立つ場合があります。詳細は、「Fusion Webアプリケーションのリファクタについて」を参照してください。

JDeveloperで、リファクタする属性を含むアプリケーションを開きます。

属性をリファクタする手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、リファクタする属性を含むエンティティ・オブジェクトまたはビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「名前」列で、属性を右クリックしてリファクタのオプションを選択します。

- 属性の名前を変更するには、「名前の変更」を選択します。
「名前の変更」ダイアログに属性の現在の名前が表示されます。新しい属性名を入力し、「OK」をクリックしてリファクタを続行するか、「取消」をクリックして取り消します。

オプションで、「プレビュー」を選択して「OK」をクリックし、「ログ」ウィンドウに使用方法を表示できます。ここからリファクタを続行したり、取り消すことができます。

- 属性の使用場所を表示するには、「使用方法の検索」を選択します。
ログ・ウィンドウに、属性の使用方法が表示されます。「ログ」ウィンドウで使用方法をクリックすると、使用方法を含むファイルがソース・エディタで開き、含まれている行が強調表示されます。

- 属性を削除するには、「削除」を選択します。
「削除の確認」ダイアログで、「使用方法の表示」をクリックして属性の使用場所を表示します。「はい」をクリックしてリファクタを続行するか、「いいえ」をクリックして取り消します。「プレビュー」をクリックして、「ログ」ウィンドウに結果を表示します。ここからリファクタを続行したり、取り消すことができます。

- 属性のタイプを変更するには、「タイプの変更」を選択します。
「タイプの変更」ダイアログで、「タイプ」ドロップダウン・リストから新しいタイプを選択するか、「参照」をクリックしてタイプを見つけます。「OK」をクリックしてリファクタを続行するか、「取消」をクリックして取り消します。

オプションで、「プレビュー」を選択して「OK」をクリックし、「ログ」ウィンドウに使用方法を表示できます。ここからリファクタを続行したり、取り消すことができます。

49.7 名前付き要素のリファクタ

名前付き要素は、Name属性によって参照できるXMLスキーマの任意の要素です。名前付き要素は、オブジェクトや属性ではありません。表49-3で、XMLスキーマの名前付き要素のリファクタのサポートについて説明します。

表49-3 名前付き要素のリファクタ

アクション

結果

移動

サポートされない。

削除

サポートされない。

名前の変更

名前付き要素の定義に関する1つの例外は、設計時の要素Attrです。これにはName属性が含まれています。Attrは名前/値ペアであり、コード・エディタでアクセスできません。名前は変更しないでください。

使用方法の検索

JDeveloperによって名前付き要素のすべての依存性が表示されます。

始める前に:

リファクタに使用できるオプションに関する知識が役立つ場合があります。詳細は、「Fusion Webアプリケーションのリファクタについて」を参照してください。

JDeveloperで、リファクタする名前付き要素を含むアプリケーションを開きます。

名前付き要素をリファクタするには:

1. 「アプリケーション」ウィンドウで、リファクタする名前付き要素を含むエンティティ・オブジェクトまたはビュー・オブジェクトをダブルクリックします。

2. エディタ・ウィンドウで、「ソース」タブをクリックして、検索またはスクロールして名前付き要素を見つけます。

名前付き要素は、ソース・コードでName="<element>"などのように示されます。

<Key Name="PersonsAffContactChk">

名前付き要素は、オブジェクトや属性ではありません。

3. リファクタする名前付き要素を右クリックして、「リファクタ」およびリファクタ・オプションを選択します。

- 要素の名前を変更するには、「名前の変更」を選択します。
「名前の変更」ダイアログに要素の現在の名前が表示されます。新しい要素名を入力し、「OK」をクリックしてリファクタを続行するか、「取消」をクリックして取り消します。

オプションで、「プレビュー」を選択して「OK」をクリックし、「ログ」ウィンドウに使用方法を表示できます。ここからリファクタを続行したり、取り消すことができます。

- 要素を削除するには、「削除」を選択します。
「削除の確認」ダイアログで、「使用方法の表示」をクリックして要素の使用場所を表示します。「はい」をクリックしてリファクタを続行するか、「いいえ」をクリックして取り消します。「プレビュー」をクリックして、「ログ」ウィンドウに結果を表示します。ここからリファクタを続行したり、取り消すことができます。

49.8 ADFタスク・フローのリファクタ

詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。

49.9 DataBindings.cpxファイルのリファクタ

DataBindings.cpxファイルは、アプリケーション全体のOracle ADFバインディング・コンテキストを定義し、Oracle ADFバインディング・オブジェクトが実行時に作成される元となるメタデータを提供します(詳細は「DataBindings.cpxの構文」を参照)。このファイルは、すべての.cpx、.dcx、.jpxおよび.xcfgファイルを短時間で検索するために使用されるレジストリで、それ自身もメタデータのレジストリです。

DataBindings.cpxファイルの名前を新しい名前に変更して、たとえばDataBindingsNew.cpxにすると、adfm.xmlファイルにその変更が追加されます。

次の例は、DataBindings.cpxがDataBindingsNew.cpxにリファクタされた後のadfm.xmlファイルの内容を示しています。

<?xml version="1.0" encoding="UTF-8" ?>
<MetadataDirectory xmlns="http://xmlns.oracle.com/adfm/metainf" version="11.1.1.0.0">
<DataBindingRegistry path="adf/sample/view/DataBindingsNew.cpx"/>
</MetadataDirectory>

さらに、アプリケーションが正しいバインディング・ファイルにアクセスできるように、ID値が次の例と同じようなIDに変更されます。

<Application xmlns="http://xmlns.oracle.com/adfm/application"
version="11.1.1.49.28" id="DataBindingsNew" SeparateXMLFiles="false"
Package="adf.sample.view" ClientType="Generic">

49.10 リファクタの制限

表49-4に、JDeveloperのリファクタのサポートに関する制限を示します。

表49-4 リファクタの制限

領域

制限

データベース

ADFビジネス・コンポーネント・オブジェクトで使用されるデータベース・アーティファクトの名前を変更した場合、オブジェクトを更新する必要がある。このタイプのリファクタは、現在サポートされていない。

サービス・インタフェース

サービス・インタフェースによって、2つの異なるソフトウェアの間の規定が定義されます。たとえば、ADFビジネス・コンポーネントのサービス・インタフェースは、ビュー・レイヤーとモデル・レイヤーへのビジネス・コンポーネントの公開に対応します。サービス・インタフェースの名前を変更すると競合が発生する可能性があります。アプリケーションを開発する際は、サービス・インタフェースを削除してからオブジェクトをリファクタし、その後でサービス・インタフェースを再生成することを検討してください。また、サービス・インタフェースで定義される検索操作が、バインド変数を指定するビュー基準に基づいている場合は、基礎となるビュー基準のバインド変数の数または順序を変更すると、サービス・インタフェースを再生成する必要があります。

詳細は、「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。

Javaリテラル参照

ADFビジネス・コンポーネントによって生成されるJavaコードは、XMLメタデータへのリテラル参照を持つ。このリテラル参照は、リファクタ操作の際に更新される。生成された(型保証の)メソッドも更新される。リファクタの削除操作はローカルJava変数に対しても使用できる。

ただし、アプリケーション・コードが直接メタデータを参照する場合は、この参照は更新されない。

ドメイン

ドメインの名前の変更や移動が必要な場合は、新しいドメインを作成してから、既存ドメインの使用方法のタイプを変更します。たとえば、ドメイン名をEmployeeIDからEmployeeNumberに変更するとします。このとき、エンティティEmpにはタイプがEmployeeIDの属性Empnoがあるとします。新しいドメインEmployeeNumberを作成した後で、エンティティの属性ページに移動し、Empnoを右クリックして「タイプの変更」を選択します。こうすると、EmpnoがEmployeeIDからEmployeeNumberに切り替わります。

セキュリティ

ポリシー・ストアのセキュリティ・ポリシーは、エンティティ・オブジェクト、属性、ページまたはタスク・フローの名前を参照することがあります。このポリシー定義は、オブジェクト自体のリファクタに対応して更新されません。

リソース・バンドル

エンティティ・オブジェクト定義は、作成した1つ以上の任意のリソース・バンドル・ファイル(.properties)を参照できます。このファイルを使用してエンティティ・オブジェクトの属性のラベルを定義できます。ただし、作成した.propertiesファイルの名前を変更すると、JDeveloperによってエンティティ・オブジェクト定義が更新されず、新しいファイル名が反映されません。作成するリソース・バンドル・ファイルのかわりに、データ・モデル・プロジェクトのために1つのデフォルト・リソース・バンドル・ファイルを生成するようにプロジェクト設定を指定できます。この場合、JDeveloperではこの生成されたファイルの名前を変更することはできません。ただし、プロジェクト・レベルのデフォルト・リソース・バンドル・ファイルを変更しようとすると、JDeveloperによって変更について警告されます。データ・モデル・プロジェクトでは、デフォルト・リソース・バンドル・ファイルにまだリンクされていないすべてのオブジェクトについて、新しいADFビジネス・コンポーネント・プロジェクトレベル設定が尊重されます。元のデフォルト・ファイルにすでにリンクされている既存のすべてのビジネス・コンポーネントでは、元のファイルが引続き使用されます。

.jpxプロジェクト構成ファイル

ADFビジネス・コンポーネント・プロジェクト構成ファイル(.jpx)の名前の変更はサポートされません。

JDeveloperの前のバージョンでは、ADFビジネス・コンポーネント・プロジェクト構成.jpxファイルは、プロジェクトのsrcディレクトリのルート・パッケージのみに作成され、プロジェクトと同じベース名が付けられました。ADFビジネス・コンポーネント・オブジェクト(エンティティ・オブジェクト、ビュー・オブジェクト、アプリケーション・モジュール)は、/Model.jpxを除き、すべてモデル・パッケージ(たとえば/model/AppModule.xml)に作成されます。このため、クラス・パスで使用するためにこれらをADF JARファイルにパッケージ化しようとする際に再利用に関して問題が発生することがあります。複数のプロジェクトの名前がModelであるため、名前の競合が発生する可能性があります。

49.11 ADFビジネス・コンポーネント・プロジェクト構成ファイル (.jpx)の移動

ADFビジネス・コンポーネント・プロジェクト構成ファイル(.jpx)のリファクタはサポートされていませんが、この名前または場所を変更して、プロジェクトの内容をADFライブラリとして共有する際の競合を回避する必要がある場合があります。.jpxファイルには、JDeveloperが設計時に使用して、ユーザーによるADFビジネス・コンポーネントを使用したデータ・モデル・プロジェクトの作成を可能にするための構成情報が含まれます。このファイルをリファクタする必要がある場合は、手動で実行してください。

始める前に:

リファクタに使用できるオプションに関する知識が役立つ場合があります。詳細は、「Fusion Webアプリケーションのリファクタについて」を参照してください。

ADFビジネス・コンポーネント・プロジェクト構成ファイル (.jpx)を手動で移動するには:

1. .jpxファイルを新しいソース・ツリーの場所に移動します。

たとえば、Model.jpxファイルをsrc/Model.jpxからsrc/newpackage/name/here/Model.jpxに移動できます。

2. .jpxファイルの内容を変更します。ルート要素JboProjectのPackageName属性は、正しい値を持つ必要があります。

たとえば、PackageName="newpackage.name.here"と指定できます。

3. .jpxファイルで参照されている要素を含むすべてのcommon/bc4j.xcfgファイルで、jbo.project属性を変更して、新しいパッケージ名を含むようにします。

次に例を示します。

<AppModuleConfig name="ScottDeptAMLocal" ApplicationName="newpackage.name.here.ScottDeptAM" DeployPlatform="LOCAL" JDBCName="scottdb" jbo.project="newpackage.name.here.Model">

4. JDeveloperプロジェクト・ファイル(.jprファイル)の内容を変更します。

- 新しい.jpxパッケージの場所を設定します。後からプロジェクト・プロパティでデフォルト・パッケージを変更する場合、.jpxファイルが原因となって再びNotFoundエラーが発生します。
次に例を示します。

<value n="defaultPackage" v="newpackage.name.here"/>

- .jpxファイルの古い場所への参照を含むownerMapで、いずれかのownerURL要素を修正します。
次に例を示します。

<url n="ownerURL" path="src/newpackage/name/here/Model.jpx"/>

50 アプリケーション・コンポーネントの再利用

この章では、特定のOracle ADFコンポーネントをADFライブラリにパッケージ化してFusion Webアプリケーションで再利用する方法について説明します。再利用可能なADFコンポーネントは、アプリケーション・モジュール、ビジネス・コンポーネント(エンティティ・オブジェクト、ビュー・オブジェクト、アソシエーション)、データ・コントロール、タスク・フロー、ページ・テンプレートおよび宣言的なコンポーネントです。

この章の内容は次のとおりです。

- 再利用可能なコンポーネントについて

- ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化

- プロジェクトへのADFライブラリ・コンポーネントの追加

- プロジェクトからのADFライブラリJARの削除

50.1 再利用可能なコンポーネントについて

アプリケーション開発の過程では、特定のコンポーネントは複数回使用されることが一般的です。通常、再利用が単一の同じアプリケーション内と複数の異なるアプリケーション間のどちらで行われるかに関係なく、これらの再利用可能なコンポーネントを複数の開発者間、異なるチーム間、さらには組織内の異なる部署間で共有できるライブラリにパッケージ化すると便利です。

Javaのオブジェクト指向プログラミングでは、クラスおよびオブジェクトの再利用は非常に一般的な手順です。Model-View-Controller (MVC)アーキテクチャの導入により、アプリケーションをモデル、ビューおよびコントローラという別々のレイヤーへとさらにモジュール化できます。データ(モデル・レイヤーとビジネス・サービス・レイヤー)をプレゼンテーション(ビュー・レイヤーとコントローラ・レイヤー)から分離することで、いずれかのレイヤーを変更しても、他のレイヤーの整合性は影響を受けなくなります。ビジネス・ロジックを変更するときに、UIの変更やWebページまたはフロント・エンドの再設計は必要なく、ドメイン・ロジックの再コーディングは不要です。

Oracle ADFおよびJDeveloperでは、MVCデザイン・パターンをサポートしています。アプリケーションをJDeveloperで作成するときは、データ・モデル・プロジェクトとユーザー・インタフェース・プロジェクトを自動的に設定する多数のアプリケーション・テンプレートを選択できます。各MVCレイヤーは相互に分離されるため、開発を複数のプロジェクトで並行して、ある程度の独立性を保ちながら進めることができます。

ADFライブラリは、高レベルなコンポーネントを作成、デプロイおよび再利用する便利で実用的な方法を提供することで、設計のこのモジュール性をさらに拡張します。アプリケーションを最初に設計するときは、コンポーネントの再利用性を念頭に置いて設計してください。再利用可能なコンポーネントを作成すると、そのコンポーネントをJARファイルにパッケージ化し、再利用可能なコンポーネントのリポジトリに追加できます。コンポーネントが必要な場合は、リポジトリでそのコンポーネントを検索し、検索したコンポーネントを自分のプロジェクトまたはアプリケーションに追加できます。

たとえば、あるドメイン用のアプリケーション・モジュールを作成し、それをパッケージ化して複数の異なるアプリケーションでデータ・モデル・プロジェクトとして使用できます。または、複数のコンポーネントを使用するアプリケーションを作成する場合、ページ・テンプレート・コンポーネントをADFライブラリJARのリポジトリからロードすることで、ルック・アンド・フィールが共通のページを作成できます。この後で、複数のタスク・フロー・コンポーネントをライブラリから取り出してつなぎ合せ、ページ・フローを編成できます。

ADFライブラリJARにはADFコンポーネントが含まれます。他のJARは含まれませんし、含めることはできません。JDeveloperライブラリ、Java EEライブラリまたはOracle WebLogic共有ライブラリと混同しないでください。

表50-1に、ADFでサポートされている再利用可能なコンポーネントを示します。

表50-1 Oracle ADFの再利用可能なコンポーネント

再利用可能なコンポーネント

説明

データ・コントロール

任意のデータ・コントロールをADFライブラリJARにパッケージ化できます。Oracle ADFでサポートされているデータ・コントロールとしては、アプリケーション・モジュール、Enterprise JavaBeans、Webサービス、URLサービス、JavaBeans、およびプレースホルダ・データ・コントロールなどがあります。

アプリケーション・モジュール

ADFビジネス・コンポーネントを使用してアプリケーション・モジュールを生成すると、関連するアプリケーション・モジュールのデータ・コントロールも生成されます。アプリケーション・モジュールのデータ・コントロールをパッケージ化するときは、そのアプリケーション・モジュールに関連付けられているADFビジネス・コンポーネントもパッケージ化します。関連するエンティティ・オブジェクト、ビュー・オブジェクトおよびアソシエーションは、ADFライブラリJARの一部になり、再利用が可能になります。

ビジネス・コンポーネント

ビジネス・コンポーネントは、ADFビジネス・コンポーネント・データ・モデル・プロジェクトで使用されるエンティティ・オブジェクト、ビュー・オブジェクトおよびアソシエーションです。ビジネス・コンポーネントは、ビジネス・コンポーネントのみで、またはアプリケーション・モジュールとともにパッケージ化できます。

タスク・フローおよびtaskflowテンプレート

タスク・フローは、ADFライブラリJARにパッケージ化して再利用できます。

ページ・フラグメントを使用するバインド・タスク・フローをドロップすると、JDeveloperがページにリージョンを追加し、ドロップされたタスク・フローにバインドします。

ページを使用して作成されたADFバインド・タスク・フローは、ページにドロップできます。このドロップにより、バインド・タスク・フローをコールするリンクが作成されます。タスク・フロー・コール・アクティビティと制御フローは、ページを参照するビュー・アクティビティを含むタスク・フローに自動的に追加されます。ページを参照するビュー・アクティビティを含むタスク・フローが複数ある場合、タスク・フロー・コール・アクティビティと制御フローを自動的に追加するタスク・フローの選択を求めるプロンプトが表示されます。

ADFタスク・フロー・テンプレートがタスク・フローと同じプロジェクトに作成された場合、そのADFタスク・フロー・テンプレートはADFライブラリJARに組み込まれ、再利用が可能になります。

ページ・テンプレート

ページ・テンプレートとそのアーティファクトは、ADFライブラリJARにパッケージ化できます。テンプレートでイメージ・ファイルを使用し、そのファイルがプロジェクト内のディレクトリに含まれている場合、再利用中にそのファイルもテンプレートで使用できます。

宣言的なコンポーネント

宣言的なコンポーネントを作成し、パッケージ化して再利用できます。コンポーネントに関連付けられているタグ・ライブラリは、使用側プロジェクトに組み込まれロードされます。

複数のコンポーネントを使用する場合は、複数の異なる再利用可能なコンポーネントを含むプロジェクトをパッケージ化することもできます。たとえば、アプリケーション・モジュールとバインド・タスク・フローの両方を含むプロジェクトを作成できます。このADFライブラリJARファイルを使用するときは、アプリケーションでアプリケーション・モジュールとタスク・フローの両方を使用できます。複数のコンポーネントを1つのJARファイルにパッケージ化したり、単一コンポーネントをJARファイルにパッケージ化できます。Oracle ADFおよびJDeveloperには、ユーザーおよびユーザーの組織に最も適した再利用可能なコンポーネントを作成するためのオプションと柔軟性が備わっています。

再利用可能なコンポーネントを作成するときは、JDeveloperを使用して、コンポーネントを含むプロジェクトをADFライブラリJARファイルにパッケージ化してデプロイします。このコンポーネントを使用するときは、そのJARを使用側プロジェクトに追加します。設計時に、JARは使用側プロジェクトのクラス・パスに追加され、再利用が可能になります。実行時には、再利用されたコンポーネントは参照によってJARファイルから実行されます。JARを手動で追加する手順の詳細は、「ADFライブラリJARをプロジェクトに手動で追加する方法」を参照してください。JDeveloperのリソース・カタログを使用してJARを追加する手順の詳細は、「「リソース」ウィンドウを使用してプロジェクトにADFライブラリJARを追加する方法」を参照してください。

再利用可能なコンポーネントの作成に進む前に、再利用可能なコンポーネントの作成に関するガイドラインを確認してください。

50.1.1 再利用可能なコンポーネントの作成

再利用可能なコンポーネントの作成および使用は、ソフトウェア・プロジェクトの初期の設計およびアーキテクチャ段階に含める必要があります。開発者および開発チームは、どのコンポーネントが再利用の候補となるかを、現在のアプリケーションのみでなく、将来のアプリケーションや他の部署で開発中のアプリケーションに対しても検討する必要があります。

開発者および開発者のチームは、ライブラリJARの格納に必要なリポジトリのタイプ、格納場所および格納したJARへのアクセス方法を決定する必要があります。また、組織のニーズに適した構造にライブラリJARを編成およびグループ化する方法も検討します。さらに、標準化された命名規則を作成し、ADFライブラリJARの作成者と使用者の両方がコンポーネントの機能を簡単に識別できるようにすることも検討する必要があります。

ヒント:

個人およびチームで開発を行っている間に、再利用の候補となる可能性のあるモジュールが見つかった場合は、JDeveloperの包括的なリファクタ機能を使用して、名前の競合を防ぎ、再利用可能なコンポーネントの命名規則に従うことができます。

50.1.1.1 ネーミング規則

再利用可能なコンポーネントの作成時は、アプリケーション、プロジェクト、アプリケーション・モジュール、タスク・フロー、接続または他のファイルやコンポーネントに対し、一意で関連性のある名前を作成してください。Application、Project、ViewController、AppModule、task-flow-defintion.xml、ConnectionなどのJDeveloperウィザードのデフォルト名は使用しないでください。アプリケーション内の他のプロジェクト、コンポーネントまたは接続との名前の競合を避けるため、一意の名前を設定することをお薦めします。名前の競合は、使用側アプリケーションで作成されたコンポーネントや、他のJARファイルからロードされたコンポーネントによって発生する場合があります。表50-2に、名前の変更が必要な場合のあるオブジェクトを示します。

表50-2 再利用可能なコンポーネントの一意で関連性のある名前の例

タイプ

JDeveloperのデフォルト

使用例

アプリケーション

アプリケーション

SummitADF

プロジェクト

Model

ViewController

プロジェクト

BackOfficService

OrderTrackingUI

パッケージ

様々な可能性があります。詳細は、「パッケージのネーミングに関する考慮事項」を参照してください。

oracle.summit

アプリケーション・モジュール

AppModule

SummitAppModuleDataControl

接続

Connection1

summit_adf

タスク・フロー

task-flow-defintion.xml

customer-task-flow-definition.xml

ページ・テンプレート

templateDef.jspx

SummitTemplate.jspx

宣言的なコンポーネント

componentDef

componentDef.jspx

SummitsuperwidgetDef

SummitsuperwidgetDef.jspx

ADFライブラリJARファイル

adflib<文字列または3桁の乱数>N

詳細は、「ADFライブラリJARデプロイメント・プロファイルのネーミング・プロセス」を参照してください。

SummitADF_Model_adflibSummitADF1

50.1.1.1.1 パッケージのネーミングに関する考慮事項

一部のコンポーネントでは、名前の明示的な設定が不可能で、プロジェクトのデフォルトのパッケージ名が使用されることに注意してください。この状況では、パッケージ名の競合を避けるよう特に注意する必要があります。パッケージ名はアプリケーションの作成ウィザードで設定できますが、この名前は後で「プロジェクト・プロパティ」ダイアログで確認してください。パッケージ名を設定しない場合は、プロジェクト名のバリアントにデフォルトで設定されます(通常は先頭の文字が小文字になります)。たとえば、Project1という名前のプロジェクトのデフォルトのパッケージ名はproject1になります。プロジェクトの作成に進む前に、パッケージ名を一意の名前に手動で変更してください。

注意:

パッケージの基本的なネーミング要件は、ADFメタデータ・レジストリ(.dcx、.cpxなど)がプロジェクトのパッケージ名に基づいて生成されることです。実行時に組み合されるプロジェクト間でのメタデータのネーミングの競合を回避してください。

再利用可能なコンポーネントのWebリソース・ファイル(JSP、HTMLおよびタスク・フローなど)を作成するときは、それぞれ独自の相対ディレクトリに作成してください。この方法により、JARを別のアプリケーションにデプロイする際に、再利用可能なコンポーネントのファイルと使用側アプリケーションのファイルの間で競合が発生する可能性が低くなります。

注意:

初期化パラメータをweb.xmlファイルに追加して、ADFライブラリのすべての静的Webアプリケーション・リソースに対する失効期限設定364日をオーバーライドできます。詳細は、「web.xml」を参照してください。

50.1.1.1.2 接続のネーミングに関する考慮事項

一般に、あるアプリケーション内の複数のモジュールは同じデータソースに接続されます。そのアプリケーション全体の接続に対してネームスペースは1つしかないため、同じデータソースへの接続名を標準化して混乱を回避することをお薦めします。このためには、他の開発者、コンポーネントの作成者およびコンポーネントの使用者との調整が必要です。たとえば、customersとsuppliersの両方で同じデータベースへの接続がある場合、この接続の名前は、合意により決定した名前(orders_dbなど)に標準化してください。

ADFライブラリJAR(接続を含む)は、接続要件が異なる複数のアプリケーションで使用される場合があります。ADFライブラリJARの作成者は、実際に標準化された接続名ではなくても、少なくとも接続ソースを表す接続名を選択する必要があります。接続とともに作成されたJARの使用者は、コンポーネントをアプリケーションに追加する際、接続要件を満たす必要があることに注意してください。

たとえば、あるデータベース接続に対してエンドポイントのホスト名を選択することは、通常は不適切です。最も適した名前は、スキーマ全体を表す名前です。使用できる接続名の例としては、oracle-appsdbやoracle-customersdbなどがあります。多数の再利用可能なコンポーネントで同じ論理接続に対して異なる名前を使用すると、コンポーネントの使用者は重複した情報を使用してそれぞれの要件を満たすことが必要になります。つまり、複数の異なる接続名が実際にはすべて同じインスタンスを参照していても、それぞれの名前に対して個別に接続詳細を指定する必要があります。

50.1.1.1.3 EJBプロジェクトを含むアプリケーションのネーミングに関する考慮事項

アプリケーションにEJBプロジェクトとデータバインディング付きWebアプリケーション・プロジェクトの両方がある場合、EJBコンポーネント名が他のWebアプリケーション・プロジェクト・コンポーネント名と競合していないことを確認する必要があります。EJBプロジェクト・コンポーネントは、グローバル・スコープを持っている場合があります。これは、プロジェクトがアプリケーションのすべてのWebプロジェクトのグローバル・クラスパスに自動的に追加されるためです。Webアプリケーション・プロジェクトが、自らのプロジェクトではなく、EJBプロジェクト内の同じ名前のコンポーネントに誤ってアクセスすることがあります。

たとえば、EJBプロジェクトとWebベースのプロジェクトにtest1.jspxページがある場合、Webベースのプロジェクトを実行したときに、EJBプロジェクトのtest1.jspxページを実行しようとする場合があります。

実行時に、JDeveloperでは、同じアプリケーション内にデータ・バインディングを伴うEJBプロジェクトおよびWebアプリケーション・プロジェクトがあるかどうかを検出します。両方のタイプがアプリケーション内に存在する場合は、プロジェクトを実行してサーバーが起動すると、「ログ」ウィンドウに警告メッセージが表示されます。

50.1.1.2 ADFライブラリJARデプロイメント・プロファイルのネーミング・プロセス

プロジェクトをパッケージ化する前に、JARファイルの名前とパスを使用してデプロイメント・プロファイルを作成する必要があります。自分および自分の開発チームの命名規則に従い、コンポーネントの機能を表す名前を選択してください。使用側プロジェクトには、別の開発者が作成したソフトウェアの他のJARファイルも含まれている場合があることに注意してください。

たとえば、コンポーネントがセルフ・サービス支払い用のタスク・フローの場合、mycompany.hcm.pay.selfservice.taskflows.jarという名前を付けることができます。他の例としては、oracle.apps.hcm.pay.model.jarやmycompany.hcm.pay.model.overrides.jarなどがあります。

デプロイメント・プロファイルを作成するとき、JDeveloperは、次の形式でデフォルトの名前を表示します。

adflibidentifierN

ここで、identifierは最大3桁の乱数で、Nは1で始まりプロファイルの繰り返しごとに1ずつ増加していきます。

たとえば、プロファイルのデフォルト名がadflib7491(乱数が749、接尾辞が1)になる場合があります。別のプロファイルのデフォルト名がadflib51(乱数が5接尾辞が1)になる場合があります。

このデフォルト名を指定の名前に変更できます。

50.1.1.3 関連プロジェクトの保持

再利用可能なコンポーネントを作成するときは、そのコンポーネントに関連のないプロジェクトは排除する必要があります。たとえば、再利用可能なアプリケーション・モジュールを作成する場合に、データ・モデル・プロジェクトは必要だが、ユーザー・インタフェース・プロジェクトは不要であるとします。この状況で、データ・モデルとユーザー・インタフェース・プロジェクトの両方のプロジェクトを含むアプリケーションを作成した場合は、ユーザー・インタフェース・プロジェクトを削除できます。当然ながら、デフォルト名のModelは、BackOfficeServiceなど、より関連性のある名前に変更してください。同様に、データがバインドされていない再利用可能なタスク・フローを作成している場合は、データ・モデル・プロジェクトをアプリケーションから削除できます。

50.1.1.4 関連機能の選択

使用側プロジェクトのテクノロジ・スコープが既知の場合は、互換性のあるテクノロジを使用してコンポーネントを設計します。たとえば、使用側アプリケーションで標準JSF Facesのみを使用する場合は、ADF Facesを使用して作成された宣言的なコンポーネントとは互換性がない場合があります。

この機能は、「アプリケーションの作成」ウィザードを使用し、「アプリケーション・テンプレート」から選択してアプリケーションを作成する際に定義できます。

テクノロジは、プロジェクトの作成後に、「プロジェクト・プロパティ」ダイアログ内の「機能」ページを使用して定義することができます。

50.1.1.5 パスおよびフォルダの選択

ファイル・システムを使用してADFライブラリJARを格納している場合は、リポジトリとして機能できるファイル・システムの場所を選択する必要があります。JARのグループは、共通のディレクトリ・フォルダ(C:\ADF\jdev\DevTeamADFRepositoryなど)に格納すると便利です。自分のチームまたは組織でADFライブラリJARを共有する計画がある場合は、ネットワークでアクセスできるリポジトリ・フォルダ、ディレクトリまたはサービスの設定を検討してください。「リソース」ウィンドウを使用すると、複数のリポジトリ・ソースに接続して複数の接続を確立できます。「リソース」ウィンドウを使用したADFライブラリJARへのアクセスの詳細は、「「リソース」ウィンドウの使用」を参照してください。

50.1.1.6 再利用可能なコンポーネント内への接続の組込み

ADFライブラリJARにパッケージ化しているプロジェクトに接続が含まれる場合、その情報はJARに組み込まれ、使用側プロジェクトで使用可能になる場合があります。Oracle ADFでは、接続を接続名と接続詳細またはエンドポイント定義という2つの部分として定義する接続アーキテクチャを使用します。JDeveloperでは、JARの作成者は、接続名のみをパッケージ化するか、接続名に加えて接続詳細も含めるかをオプションで選択できます。

接続がプロジェクトに含まれている場合、パッケージ化されたADFライブラリJARにはjar-connections.xmlファイルとjar-adf-config.xmlが含まれます。それらはMETA-INFディレクトリに追加されます。jar-connections.xmlファイルには、接続名およびその他の関連接続情報が含まれます。jar-adf-config.xmlには、接続のために使用された資格証明に関する情報が格納されます。接続の資格証明も指定した場合は、資格証明ストアへのjar-credential-jazn-data.xmlの組込みも行われます。ADFライブラリJARデプロイメント・プロファイルを作成すると、ADFライブラリJARにパッケージ化するために個々の接続または接続タイプを選択できます。「コンポーネントをADFライブラリJARにパッケージ化する方法」の説明に従って、ADFライブラリ・デプロイメント・プロファイル・プロパティの作成ダイアログまたはADFライブラリ・デプロイメント・プロファイル・プロパティの編集ダイアログの「接続」ページで接続を選択します。

ADFライブラリJARをプロジェクトに追加する間に、JDeveloperではアプリケーションの接続とJARの接続との間に競合がないかをチェックします。この後、プロジェクトへのJARの追加を続行するかどうかを決定するダイアログが提示されます。ADFライブラリJARに定義されている接続は、次の状況に応じて、使用側プロジェクトに追加される場合があります。

- JARに定義されている接続が完全に構成されていて、使用側プロジェクトとの接続名の競合がない場合は、新しい接続が追加されます。

- JARに定義されている接続が部分的に構成されている場合は、新しい接続が使用側プロジェクトに追加されますが、この接続は使用前に構成する必要があります。ユーザーが接続情報を入力できる接続ダイアログが表示される場合があります。この部分的に構成された接続には、不完全であることを示すアイコンが表示される場合があります。

- JARに定義されている接続の名前がアプリケーションの接続と同じ場合は、プロジェクトに追加されません。アプリケーションの既存の接続が使用されます。

- JARに定義されている接続の名前がアプリケーションの接続と同じでも、型が異なる場合、JARの接続はプロジェクトに追加されません。たとえば、アプリケーションでJARのデータベース接続とURL接続の名前が同じ場合、データベース接続はアプリケーションに追加されません。

接続を含むプロジェクトにADFライブラリを追加する方法の詳細は、「「リソース」ウィンドウを使用してプロジェクトにADFライブラリJARを追加する方法」を参照してください。

注意:

ADFライブラリをプロジェクトに追加するプロセスで、ログ・ウィンドウに、JARで定義された各接続に関する1つのメッセージが表示されます。このメッセージは、プロジェクトでマージ・アクションが実行されていることを示します。

50.1.2 再利用可能なADFコンポーネントのユースケースと例

プロジェクトをADFライブラリJARにパッケージ化すると、同じまたは異なるアプリケーションでコンポーネントを複数回再利用できます。異なる開発チームは、プロジェクトを作成して使用し、再利用可能モジュールのライブラリを作成できます。ADFライブラリJARでは、M-V-Cデザイン・パターンをサポートしています。ADFライブラリを作成し、「リソース」ウィンドウからのドラッグ・アンド・ドロップによってそれらにアクセスできます。

たとえば、アプリケーション・モジュールをADFライブラリJARにパッケージ化し、これを別のチームが使用するパブリック・フォルダに配置できます。別の実装チームは、そのJARにアクセスし、アプリケーションを作成できます。独自のアプリケーション・モジュールを作成するかわりに、このアプリケーション・モジュールを使用して、別のページを作成して使用できます。モデルに変更がある場合、元の開発者は、アプリケーション・モジュールを再パッケージ化し、ADFライブラリJARを再公開できます。別の実装チームは、更新されたADFライブラリを使用して、アプリケーションを更新できます。

50.1.3 再利用可能なADFコンポーネントの追加機能

再利用可能なADFコンポーネントを使用する前に、他のADF機能を理解することが役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- ビジネス・コンポーネントをパッケージ化して再利用できます。アプリケーション・モジュールの詳細は、「ADFビジネス・コンポーネントのスタート・ガイド」を参照してください。

- アプリケーション・モジュールをパッケージ化して再利用できます。アプリケーション・モジュールの詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。

- タスク・フローをパッケージ化して再利用できます。タスク・フローの詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。

- ページ・テンプレートをパッケージ化して再利用できます。タスク・フローの詳細は、「Webインタフェースのスタート・ガイド」を参照してください。

- ページ・テンプレートをパッケージ化して再利用できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の宣言的なコンポーネントの使用に関する項を参照してください。

50.1.4 再利用可能なADFコンポーネントの共通機能

ADFライブラリJARをパッケージ化または使用するとき、プロジェクトに関連付けられている拡張機能ライブラリも含めたり使用します。ADFライブラリを使用する場合は、「リソース」ウィンドウを使用できます。

50.1.4.1 拡張機能ライブラリの使用方法

ADFプロジェクトには、通常、実行する必要がある拡張機能ライブラリのリストが含まれます。これらのライブラリは、プロジェクトのクラス・パスでロードされます。「プロジェクト・プロパティ」ダイアログの「ライブラリとクラスパス」ノードを選択すると、プロジェクトの依存ライブラリが表示されます。表示されるライブラリは、JSPランタイム、ADFページ・フロー・ランタイム、Connection Manager、Oracle JDBCなどです。

プロジェクトがADFライブラリJARにパッケージ化される場合、拡張機能ライブラリもともにパッケージ化されます。ADFライブラリJARが別のプロジェクトによって使用されているとき、その間で拡張機能ライブラリの競合が発生した場合、JDeveloperにより自動的に解決されます。使用プロセスの際、JDeveloperは、使用側プロジェクトがADFライブラリJARの拡張機能ライブラリをすでにクラス・パスに持ち、持っていないライブラリのみをロードしているかをチェックします。たとえば、JSPランタイムがすでに使用側プロジェクト内に存在する場合、ADFライブラリJARにも含まれていれば、重ねてロードされません。使用側プロジェクトの拡張機能ライブラリは、自身のライブラリとADFライブラリJAR内のライブラリを合せたものです。

ADFライブラリにパッケージ化するプロジェクトに依存プロジェクトがある場合、依存プロジェクトの拡張機能ライブラリをJARに直接含めることができます。あるいは、依存プロジェクトにデプロイメント・プロファイルがある場合は、依存プロジェクトのJARをADFライブラリに追加できます。デプロイメント・プロセスの設定方法の詳細は、「コンポーネントをADFライブラリJARにパッケージ化する方法」を参照してください。

たとえば、プロジェクトViewがADFライブラリadflibView1.jarにパッケージ化され、Modelプロジェクトに依存性があるとします。プロジェクトViewに対して、Modelプロジェクトは依存プロジェクトであり、デプロイメント・プロファイル・オプション(adflibmodel1)が選択されています(図50-1)。

図50-1 デプロイメント・プロファイル・オプションのある「依存性の編集」ダイアログ

デプロイメント・プロファイルを選択すると、依存プロジェクトのJARファイルがADFライブラリJARに追加されます。その結果、依存プロジェクトの拡張機能ライブラリが、すべての使用側プロジェクトで利用可能になります。図50-2で、パッケージ化されるADFライブラリadflibView1.jarには、依存するadflibModel.jarが含まれ、「ライブラリ依存性」ノードの下にリストされます。

図50-2 adflibView1.jarおよびadflibModel.jar拡張機能ライブラリが表示されている「リソース」ウィンドウ

別の方法として、依存プロジェクトのアーティファクトと拡張機能ライブラリを、ADFライブラリJARに直接含めることができます。

たとえば、プロジェクトViewはADFライブラリadflibView2.jarにもパッケージ化できます。これもModelプロジェクトに依存性があります。ただし、この2つ目のデプロイメント・プロファイルでは、Modelプロジェクトは、図50-3に示すように「ビルド出力」オプションが選択された依存プロジェクトです(デプロイメント・プロファイル(adflibmodel1)の選択とは異なります)。

図50-3 adflibview2.jarをビルドするために使用される「依存性の編集」ダイアログ

「ビルド出力」を選択すると、依存プロジェクトのクラスと拡張機能ライブラリが、ADFライブラリJARに直接追加されます。図50-4に、ADFライブラリadflibView2.jarを示します。これには、Modelプロジェクトのアーティファクトと拡張機能ライブラリが含まれます。「ライブラリ依存性」ノードadflibView2.jarの下にある拡張機能ライブラリは、図50-2のadflibView1.jarとadflibModel.jarの下にある拡張機能ライブラリを合せたものと同じです。

図50-4 adflibView2.jar拡張機能ライブラリが表示されている「リソース」ウィンドウ

依存プロジェクトをどのようにパッケージ化するかは、ADFライブラリの想定される使用に応じて異なります。依存プロジェクトがそれ自身で再利用可能なコンポーネントであるか、ADFライブラリJARにパッケージ化される複数のプロジェクトの依存プロジェクトである場合は、依存プロジェクトをJARとして含む方法に利点があります。例では、依存プロジェクトModelは、複数のビュー・プロジェクトの依存プロジェクトになる可能性があります。一方、依存プロジェクトをビルド出力としてパッケージ化する方法は、簡単明瞭で、JARが重複する心配もありません。

注意:

JDeveloper拡張機能ライブラリに含まれるADFライブラリJARを作成している場合、追加のマニフェスト、JDevLibrary: extension_library_nameエントリをJARに組み込む必要があります。「リソース」ウィンドウの「プロジェクトに追加」を使用して、JDevLibraryマニフェスト・エントリを含むADFライブラリJARを追加すると、ADFライブラリJARそのものではなく、このJARを含むJDeveloper拡張機能ライブラリが追加されます。

50.1.4.2 「リソース」ウィンドウの使用

ADFライブラリJARは、他のOracleライブラリ・コンポーネントと同様に、パッケージ化、デプロイ、検出および使用が可能です。ADFライブラリJARの作成は、プロジェクトのすべてのアーティファクト(および追加の制御ファイル)をJARにパッケージ化する処理です。再利用可能なコンポーネントのADFライブラリJARからの使用は、そのADFライブラリJARをプロジェクトのライブラリ・セットにロードする処理です。

ただし、ADFライブラリJARコンポーネントを管理および使用する最も簡単な方法は、JDeveloperの「リソース」ウィンドウを使用することです。「リソース」ウィンドウを使用すると、再利用可能なコンポーネントの使用を希望している開発者は、使用可能なコンポーネントを簡単に検索および検出でき、自分のプロジェクトに追加できます。「リソース」ウィンドウの検索および参照機能を使用すると、複数のデータ管理システムを対象にコンポーネントを特定できます。リソース・カタログでは、複数の接続を提供し、異なるソースへのアクセスを可能にします。また、複数の接続およびADFライブラリJARコンポーネント・タイプを表示する構造ツリー・ビューもあります。図50-5は、いくつかのファイルシステム接続が表示された「リソース」ウィンドウを示しています。

「リソース」ウィンドウのツリー構造には、各JARがサブカテゴリとして表示されます。再利用可能なコンポーネントのタイプごとに別々のノードが作成されます。たとえば、アプリケーション・モジュールは「データ・コントロール」ノードの下にあり、タスク・フローは「ADFタスク・フロー」ノードの下にあります。

ADFライブラリJARのツリー構造では、接続情報が「ライブラリ接続」ノードに、作成しているプロジェクトの拡張機能ライブラリが「ライブラリ依存性」ノードにリストされます。

図50-5 ADFライブラリ構造が表示されている「リソース」ウィンドウ

50.2 ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化

1つ以上の特定のコンポーネントを再利用できると判断した後は、アプリケーションおよびプロジェクトを作成してそのコンポーネントを開発します。アプリケーション、プロジェクト、パッケージおよびその他のオブジェクトやファイルの名前を設定するには、「再利用可能なコンポーネントの作成」のガイドラインに従ってください。各プロジェクトは、1つのADFライブラリJARに対応します。複数のプロジェクトを作成し、それぞれのプロジェクトでコンポーネントを再利用する場合は、各プロジェクトに対してADFライブラリJARの作成が必要な場合があります。また、複数のコンポーネントを1つのプロジェクトにまとめて、単一のADFライブラリJARを作成できる場合もあります。たとえば、アプリケーション・モジュール、ビジネス・コンポーネント(エンティティ・オブジェクト、ビュー・オブジェクト、アソシエーション)、タスク・フローおよびページ・テンプレートすべてを1つのプロジェクトに作成して、1つのADFライブラリJARを作成することができます。

ADFライブラリJARの作成プロセスには、プロジェクトのコンパイル、コンポーネントの検証、リソース・サービス・ファイル、制御ファイルおよびadflibREADME.txt,の作成、関連するプロジェクト・ファイルのJARへの追加などが含まれます。ADFライブラリJARの詳細は、「ADFライブラリJARへのプロジェクトのパッケージ化時の処理」を参照してください。

コンポーネント自体が別のADFライブラリ・コンポーネントを使用するコンポーネントをパッケージ化する場合、最終的な使用側プロジェクトには両方のADFライブラリJARを追加する必要があります。たとえば、別のADFライブラリJARのデータ・コントロールからドロップされた表を含む再利用可能なタスク・フローを作成したとします。このタスク・フローをADFライブラリJARから使用側プロジェクトに追加する場合、そのプロジェクトにはデータ・コントロールのADFライブラリJARも必要です。

依存JAR(サードパーティのJARなど)を含むコンポーネントをパッケージ化する場合は、2つの方法があります。

- 使用側の環境でJARの配置が制御される場合、ADFライブラリJARおよび依存JARをJDeveloper拡張機能ライブラリに配置できます。JDeveloper拡張機能ライブラリを使用する利点は、個々の依存JARを参照する必要がないために、使用側プロジェクトが複雑にならないことです。

- JDeveloper拡張機能ライブラリを使用できない場合は、依存JARをADFライブラリJARと同じ場所に配置し、各依存JAR用のマニフェスト・クラスパス・エントリを含めることができます。

50.2.1 コンポーネントをADFライブラリJARにパッケージ化する方法

再利用可能なコンポーネントをパッケージ化するには、まず、アーカイブ・タイプ、JARファイルの名前およびJARを作成するディレクトリのパスを指定するデプロイメント・プロファイルを作成します。次に、このデプロイメント・プロファイルを使用してプロジェクトをデプロイします。

始める前に:

ADFコンポーネントをパッケージ化するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。

ADFコンポーネントをパッケージ化する際に使用できる機能を理解することも役立つ場合があります。詳細は、「再利用可能なADFコンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- プロジェクトを作成して、パッケージ化する必要がある依存プロジェクトとJARがあるかどうかを判別します。詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。

プロジェクトをADFライブラリJARにパッケージ化およびデプロイするには:

1. 「アプリケーション」ウィンドウで、再利用を可能にするコンポーネントを含むプロジェクトをダブルクリックします。

2. 「プロジェクト・プロパティ」ダイアログで、「デプロイメント」を選択し、続いて「新規」をクリックします。

3. 「デプロイメント・プロファイルの作成」ダイアログで、「プロファイル・タイプ」として「ADFライブラリのJARファイル」を選択し、「デプロイメント・プロファイル名」に名前を入力するかまたはデフォルト名を受け入れ、「OK」をクリックします。

図50-6 「デプロイメント・プロファイルの作成」ダイアログ(デフォルト名の場合)

4. 「プロジェクト・プロパティ」ダイアログで、デプロイメント・プロファイルを選択し、「編集」をクリックします。

5. 「ADFライブラリJARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「ライブラリ依存性」ノードを選択します。図50-7を参照してください。

図50-7 「ADFライブラリJARデプロイメント・プロファイルのプロパティ」ダイアログ

「ライブラリ依存性」ペインに、パッケージ化されるプロジェクトの、依存プロジェクトのリストが表示されます。依存プロジェクトのビルド出力を、パッケージ化するプロジェクトのライブラリに直接追加することも、選択されたデプロイメント・プロファイル・アーカイブをクラス・パスに追加することもできます。

a. 依存プロジェクトを追加するには、編集アイコンをクリックして「依存性の編集」ダイアログを表示します。図50-8を参照してください。
「ビルド出力」を選択すると、依存プロジェクトの拡張機能ライブラリが、ADFライブラリJARに直接追加されます。デプロイメント・プロファイルを選択すると、依存プロジェクトのJARファイル(独自の拡張機能ライブラリを含む)が、ADFライブラリJARに追加されます。ライブラリ依存性の詳細は、「拡張機能ライブラリの使用方法」を参照してください。

この例では、Modelプロジェクトは、ビルド出力としてのみ、依存性として設定できます。ただし、ViewControllerプロジェクトは、ビルド出力としてでも、デプロイメント・プロファイル(SummitADF_ViewController_webapp)としてでも依存性として設定できます。

図50-8 ADFライブラリ・デプロイメントの「依存性の編集」ダイアログ

b. 各依存プロジェクトで、プロジェクトの「ビルド出力」ノードを選択するか、依存プロファイルを選択して、「OK」をクリックします。

6. 「ADFライブラリJARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「接続」ノードを選択します。図50-9を参照してください。
次のいずれかを選択できます。

- 接続詳細(セキュア・コンテンツは除外): プロジェクトに接続が含まれる場合に、接続名だけでなく使用できる接続詳細も含む場合は、このチェック・ボックスを選択します。接続詳細には、ホスト名、ポート番号、SID、ドライバ・タイプ、ユーザー名などが含まれます。詳細は、「再利用可能なコンポーネント内への接続の組込み」を参照してください。

- 接続名のみ: 接続詳細を含まず、接続名のみを追加する場合は、このチェック・ボックスを選択します。

注意:

使用可能な接続のオプションはJDeveloperロールによって異なります。「接続詳細(セキュア・コンテンツは除外)」および「接続名のみ」は、Studio開発者のロールで選択できます。JDeveloperが別のロールに設定されている場合は、他のオプションとデフォルトになります。

「アプリケーション接続」ツリー構造で、組み込む接続レベルに対応するチェック・ボックスを選択します。

図50-9 「ADFライブラリJARデプロイメント・プロファイルのプロパティの編集」ダイアログの「接続」ページ

7. 「JARオプション」ノードで、図50-10に示すように、ADFライブラリJARファイルの格納先として、デフォルトのディレクトリ・パスを検証するか、新しいパスを入力します。
ADFライブラリJARをJDeveloper拡張機能ライブラリに組み込む場合は、JDevLibrary: extension_library_nameエントリを含むテキスト・ファイルを作成し、そのファイルをプロジェクト・ルート・ディレクトリに配置します。「追加」をクリックすると、このファイルがManifest.mfファイルにマージされます。

マニフェスト・テキスト・ファイルを作成するときは、JDevLibraryエントリを列1から開始して、コロンの後には空白を1つ入力してください。また、ファイルの最後の1行は空白行にする必要があります。

図50-10 「ADFライブラリJARデプロイメント・プロファイルのプロパティ」ダイアログの「JARオプション」

8. 「ADF検証」ノードを選択します。
次のいずれかを選択できます。

- エラーの無視: 検証が失敗してもJARファイルを作成します。このオプションがデフォルトです。

- 処理の停止: 検証が失敗した場合は処理を停止します。

図50-11 「ADFライブラリJARデプロイメント・プロファイルのプロパティ」ダイアログの「ADF検証」

9. デプロイメント・プロファイルの設定を完了するには、「OK」をクリックします。

10. 「アプリケーション」ウィンドウで、プロジェクトを右クリックし、「デプロイ」→「deployment」を選択します。「deployment」はデプロイメント・プロファイルの名前です。

11. 「デプロイ」ダイアログの「デプロイメント・アクション」ページで、「次」をクリックしてから、「終了」をクリックします。
JDeveloperによって、ステップ7で指定したディレクトリにADFライブラリJARが作成されます。ディレクトリをチェックして、JARが作成されたかどうかを確認できます。

50.2.2 ADFライブラリJARへのプロジェクトのパッケージ化時の処理

ライブラリJARをデプロイすると、JDeveloperによって必要なすべてのアーティファクトがパッケージ化され、適切な制御ファイルが追加され、JARファイルが生成されてデプロイメント・プロファイルで指定されたディレクトリに配置されます。デプロイ中は、コンパイル・メッセージが「ログ」ウィンドウに表示されます。

プロジェクトをADFライブラリJARにデプロイするとき、JDeveloperは次の処理を実行します。

- HTMLルート・ディレクトリのアーティファクトをJARにパッケージ化します。JARが使用側プロジェクトに追加されると、JDeveloperによってそれがクラス・パスに追加され、再利用可能なコンポーネントのpublic_htmlリソースが使用可能になります。

- adfm.xmlファイルをJARに追加します。ワークスペースに複数のMETA-INF/adfm.xmlファイルがある場合、デプロイ中のプロジェクトのadfm.xmlファイルのみが追加されます。このファイルはJDeveloperによって変更され、依存プロジェクトのadfm.xmlファイルの関連する内容が組み込まれます。

- サービス・リソース・ファイルoracle.adf.common.services.ResourceService.svaをJARのMETA-INFディレクトリに追加します。このファイルを追加することで、ADFライブラリJARファイルが標準のJARファイルから区別されます。このファイルにより、JARのサービス方針が定義され、「リソース」ウィンドウでJARの内容を正しく検出および表示できるようになります。

- Manifest.mfファイルをJARに追加します。Manifest.mfファイルは、JARファイル間の依存性を指定し、JARファイルの内容をコピーして組み込むか参照するかを決定するために使用されます。JDeveloperにより、デフォルトのマニフェスト・ファイルが作成されます。次に例を示します。

Manifest-Version: 1.0

- 接続が必要で、接続アーキテクチャを使用するコンポーネントに対しては、jar-connections.xmlファイルがJARに追加されます。使用側アプリケーションで、クラス・パスで定義され、実行時にアクセスできる構成ファイル内の接続情報が、マージされることがある点に注意してください。同じ接続がクラス・パスで複数回指定された場合、メイン・アプリケーションの接続が優先されます。

異なるタイプの再利用可能なコンポーネントでは、異なるアーティファクト・ファイルおよびエントリがサービス・リソース・ファイルに含まれます。

50.2.2.1 JARにパッケージ化されるアプリケーション・モジュール・ファイル

アプリケーション・モジュールの場合、JDeveloperは、これらの制御ファイルをJAR (oracle.adf.common.services.ResourceService.sva、Manifest.mf、adfm.xmlおよびビジネス・コンポーネント.jpxファイル)に追加します。アプリケーション・モジュールのサービス・リソース・ファイルには、そのアプリケーション・モジュールのデータ・コントロールのエントリに加えて、アプリケーション・モジュールに関連付けられているビジネス・コンポーネントのエントリも含まれます。

接続アーキテクチャを使用し、データ・ソースに関する接続情報を含むコンポーネントの場合は、jar-connections.xmlファイルが存在する場合があります。

50.2.2.2 JARにパッケージ化されるデータ・コントロール・ファイル

プレースホルダ・データ・コントロールなどのデータ・コントロールに対しては、oracle.adf.common.services.ResourceService.sva、Manifest.mfおよびDataControl.dcxという3つの制御ファイルがJDeveloperによってJARに組み込まれます。データ・コントロールが使用されるのは、データソースがADFビジネス・コンポーネントに基づいていないため、アプリケーション・モジュールのJARファイルの場合と異なり、ビジネス・コンポーネントがJARファイルに含まれていない場合です。標準のデータ・コントロールのサービス・リソース・ファイルには、データ・コントロールのエントリが含まれます。

JARには、データ・コントロールのタイプを示すDatacontrol.dcxファイルもプロジェクトから組み込まれます。

50.2.2.3 JARにパッケージ化されるタスク・フロー・ファイル

タスク・フローに対しては、oracle.adf.common.services.ResourceService.sva、Manifest.mfおよびtask-flow-registry.xmlという3つの制御ファイルがJDeveloperによってJARに組み込まれます。タスク・フローのサービス・リソース・ファイルには、1つまたは複数のタスク・フローがJARに含まれることを示すエントリが含まれます。

50.2.2.4 JARにパッケージ化されるページ・テンプレート・ファイル

ページ・テンプレートに対しては、oracle.adf.common.services.ResourceService.svaおよびManifest.mfという2つの制御ファイルがJDeveloperによってJARに組み込まれます。

50.2.2.5 JARにパッケージ化される宣言コンポーネント・ファイル

宣言的なコンポーネントに対しては、oracle.adf.common.services.ResourceService.svaおよびManifest.mfという2つの制御ファイルがJDeveloperによってJARに組み込まれます。

50.2.3 JARファイルの配置方法とアクセス方法

他のプロジェクトで再利用できるJARファイル(サードパーティJARファイルなど)がある場合、JDeveloperを使用して、JARファイルをアクセス可能な場所に配置し、それらのファイルを指定するライブラリ・ファイル(.library)を作成できます。使用側はJDeveloperを使用して、この場所にナビゲートし、JARをプロジェクトに追加できます。

ADFライブラリJARにはADFコンポーネントが含まれます。他のJARは含まれません(含めることはできません)。

始める前に:

ADFコンポーネントをパッケージ化するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。

ADFコンポーネントをパッケージ化する際に使用できる機能を理解することも役立つ場合があります。詳細は、「再利用可能なADFコンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- JARファイルの生成側と使用側両方にとってアクセス可能な場所にJARファイルを配置します。たとえば、他の共有ファイルを配置しているネットワーク・ドライブ上のディレクトリに配置します。詳細は、「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。

JDeveloper LIbrary JARを配置してアクセスするには:

1. メイン・メニューから「ツール」→「ライブラリの管理」を選択します。

2. 「ライブラリの管理」ダイアログで「ディレクトリ」をクリックします。

3. 「ディレクトリのロード」ダイアログで、二次的なJARファイルを配置するディレクトリを選択します。

4. 「ライブラリの管理」ダイアログで「新規」をクリックします。

5. 「ライブラリの作成」ダイアログで、ライブラリ名を入力して「エントリの追加」をクリックします。
ライブラリ・ファイル(.library拡張子)が作成されます。ライブラリ・ファイルはソース・コントロール・システムに配置する必要があります。

6. 「パス・エントリの選択」ダイアログで、追加するJARを選択して「OK」をクリックします。

7. 「ライブラリの作成」ダイアログで、「デフォルトでデプロイ済」オプションがJARに正しく設定されていることを確認して「OK」をクリックし、さらに「OK」をクリックします。

8. 使用するプロジェクトで次の手順を実行します。

a. メイン・メニューから「ツール」→「ライブラリの管理」を選択します。

b. 「ライブラリの管理」ダイアログで「ディレクトリ」をクリックします。

c. 「ディレクトリのロード」ダイアログで、二次的なJARファイルを配置するディレクトリを選択して「選択」をクリックします。この手順のステップ3で指定したのと同じ場所を選択する必要があります。

d. プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

e. プロジェクト・プロパティ・ウィンドウで、「ライブラリとクラスパス」を選択し、「ライブラリの追加」をクリックします。

f. 「ライブラリの追加」ダイアログで「OK」をクリックし、もう一度「OK」をクリックします。

50.3 プロジェクトへのADFライブラリ・コンポーネントの追加

ADFライブラリJARは、作成後、そのJARを使用する開発者に配布する必要があります。ADFライブラリJARを配布する手順には、検索、参照および検出するネットワーク・ファイル・システムへのJARの配置が含まれる場合があります。これらのJARにアクセスして取得する場合に、他の形式のデータ・ストアまたはサービスが使用されることがあります。ADFライブラリJARは単なるバイナリ・ファイルなので、ftpや電子メールなどを使用して、他のファイルと同様に配布できます。

ADFライブラリJARへのアクセスが可能になった後は、JDeveloperを使用してJARにアクセスし、自分の使用側プロジェクトに追加できます。JDeveloperの「リソース」ウィンドウを使用すると、最も簡単で効率的です。JDeveloperを使用してJARをクラス・パスに入力することで、JARをプロジェクトに手動で追加することも可能です。

プロジェクトがADFライブラリJARにパッケージ化されると、そのプロジェクトがデプロイメントと実行時に必要とする依存JARのリストが取得されます。このリストは、プロジェクトの依存プロファイルと、「デフォルトでデプロイ済」が選択されたプロジェクトの「ライブラリとクラスパス」の情報に基づいています。ADFライブラリJARが使用側プロジェクトに追加されるとき、この依存JARのリストは、ADFライブラリ依存性と呼ばれるライブラリに配置されます。これは、使用側プロジェクト内のロックされたライブラリです。内容は、JDeveloperの「データ・コントロール」パネル、「コンポーネント」ウィンドウまたは他の場所では表示されません。このライブラリは、プロジェクトでの様々なADFライブラリJARの追加や削除に応じて管理および更新されます。依存性が変更された場合は(たとえば、生成側プロジェクトの再ビルドなど)、JDeveloperのメニュー・コマンドを使用して使用側プロジェクトの依存性をリフレッシュできます。

追加した再利用可能なコンポーネントの使用方法は、コンポーネントのタイプによって異なります。

50.3.1 「リソース」ウィンドウを使用してプロジェクトにADFライブラリJARを追加する方法

「リソース」ウィンドウを使用して、ADFライブラリJARの検索、検出およびプロジェクトへの追加を実行できます。

始める前に:

ADFコンポーネントをパッケージ化するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「プロジェクトへのADFライブラリ・コンポーネントの追加」を参照してください。

ADFコンポーネントをパッケージ化する際に使用できる機能を理解することも役立つ場合があります。詳細は、「再利用可能なADFコンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- リポジトリ・フォルダにADFライブラリJARを作成します。このリポジトリに「リソース」ウィンドウがまだ接続していない場合は、このフォルダの場所を認識している必要があります。詳細は、「プロジェクトへのADFライブラリ・コンポーネントの追加」を参照してください。

「リソース」ウィンドウを使用してプロジェクトにコンポーネントを追加するには:

1. メイン・メニューで、「ウィンドウ」→「リソース」を選択します。

2. 「リソース」ウィンドウで、「新規」アイコンをクリックして、「IDE接続」→「ファイルシステム」を選択します。

3. 「ファイルシステム接続の作成」ダイアログで、JARが含まれるフォルダの名前とパスを入力します。

ファイル・パスのガイドラインは、「パスおよびフォルダの選択」を参照してください。

4. 「OK」をクリックします。

新しいADFライブラリJARが「リソース」ウィンドウの接続名の下に表示されます。

5. JAR構造ツリーの各項目を調査するには、ツールチップを使用します。ツールチップには、選択されている項目のソースなどの、関連情報が表示されます。

図50-12では、「リソース」ウィンドウに、ビジネス・コンポーネントのパッケージ情報を示すツールチップ・メッセージが表示されています。

図50-12 「リソース」ウィンドウに表示される、接続に関するツールチップ・メッセージ

6. ADFライブラリJARまたはその項目のいずれかをプロジェクトに追加するには、項目を右クリックして「プロジェクトに追加」を選択します。表示される確認ダイアログで「ライブラリの追加」をクリックします(図50-13)

図50-13 「ADFライブラリ追加の確認」ダイアログ

そのライブラリJARを前に追加したことがある場合、「ADFライブラリのリフレッシュの確認」ダイアログが表示され、ライブラリをリフレッシュする確認を求めてきます。

7. ADFライブラリJARに依存性の変更がある場合は、新しい変更内容でプロジェクトをリフレッシュできます。「アプリケーション」ウィンドウで、プロジェクトを右クリックして「project.jprのADFライブラリ依存性のリフレッシュ」を選択します。

アプリケーション・モジュールおよびデータ・コントロールの場合は、オプションで、アプリケーション・モジュールまたはデータ・コントロールを「リソース」ウィンドウから「データ・コントロール」パネルにドラッグ・アンド・ドロップできます。

注意:

JDeveloperは、使用側プロジェクトにまだ含まれていないすべてのADF Library JAR拡張機能ライブラリをロードします。使用側プロジェクトに含まれていない場合、ADFライブラリの依存JARの拡張機能ライブラリも、チェックおよびロードされます。詳細は、「拡張機能ライブラリの使用方法」を参照してください

50.3.2 ADFライブラリJARをプロジェクトに手動で追加する方法

ADFライブラリJARは、他のライブラリJARファイルと同じ方法で追加できます。

始める前に:

ADFコンポーネントをパッケージ化するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「プロジェクトへのADFライブラリ・コンポーネントの追加」を参照してください。

ADFコンポーネントをパッケージ化する際に使用できる機能を理解することも役立つ場合があります。詳細は、「再利用可能なADFコンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- ADFライブラリJARを作成します。詳細は、「プロジェクトへのADFライブラリ・コンポーネントの追加」を参照してください。

コンポーネントをプロジェクトに手動で追加するには:

1. 「アプリケーション」ウィンドウで、コンポーネントを追加するプロジェクトをダブルクリックします。

2. 「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」ノードを選択し、「ライブラリの追加」をクリックします。

3. 「ライブラリの追加」ダイアログで、「新規」をクリックします。

4. 「ライブラリの作成」ダイアログの「場所」ドロップダウン・リストで「プロジェクト」を選択し、ADFライブラリの名前を入力します。適切な名前は「ADF Library」です。「デフォルトでデプロイ済」を選択し、「エントリの追加」をクリックします。

5. 「パス・エントリの選択」ダイアログで、ADFライブラリJARファイルを入力または参照し、「開く」をクリックします。

6. 「ライブラリの作成」ダイアログが再表示され、「クラスパス」ノードの下にJARファイルのパスが表示されます。「OK」をクリックします。

7. 「ライブラリの追加」ダイアログが再表示され、「プロジェクト」ノードの下にADFライブラリのエントリが表示されます。「OK」をクリックします。

図50-14 「ライブラリの追加」ダイアログ

8. JARファイルがライブラリのリストに追加された状態で、「プロジェクト・プロパティ」ダイアログが再表示されます。「OK」をクリックします。

50.3.3 プロジェクトへのADFライブラリJARの追加時の処理

「リソース」ウィンドウを使用して、またはJARを手動で追加することで、ADFライブラリJARをプロジェクトに追加すると、ADFライブラリの定義がプロジェクトに作成されます。ADFライブラリJARファイルは、プロジェクトのクラス・パスに追加されます。プロジェクトでは、JAR内のコンポーネントのアクセスおよび使用を参照によって行います。

デフォルトでは、「ライブラリの作成」ダイアログの、ADFライブラリの「デフォルトでデプロイ済」オプションはtrueに設定されています。このオプションが設定されている場合、アプリケーションまたはモジュールがWARファイルにさらにアーカイブまたは組み込まれると、ADFライブラリJARの内容が、そのアーカイブまたはWARファイルにコピーされます。「デフォルトでデプロイ済」オプションが設定されていない場合は、ADFライブラリのJARを他の方法(共有ライブラリへのデプロイなど)でロードする必要があります。

図50-15に、ADFライブラリが追加される前の、使用側プロジェクトの空の「データ・コントロール」パネルを示します。

図50-15 使用側プロジェクトの「データ・コントロール」パネル

図50-16に、使用側プロジェクトに追加されるadflibview1 ADFライブラリを示します。

図50-16 プロジェクトへのADFライブラリJARの追加

図50-17に、使用側プロジェクトの「データ・コントロール」パネルに追加されたADFライブラリの、いくつかのデータ・コントロールを示します。

図50-17 使用側プロジェクトの「データ・コントロール」パネルへのアプリケーション・モジュールの追加

ADFライブラリJARの追加後に、JDeveloperの一部のウィンドウが変更される場合があります。変更内容は、追加したコンポーネントのタイプによって異なります。表50-3に、JDeveloperのいくつかのウィンドウでの影響を示します。

表50-3 ADFライブラリ追加後のJDeveloperウィンドウ

追加したコンポーネント

「データ・コントロール」パネル

作成ウィザード

「コンポーネント」ウィンドウ

データ・コントロール

データ・コントロールが表示されます。

アプリケーション・モジュール

アプリケーション・モジュールが表示されます。

ビジネス・コンポーネント

ビュー・オブジェクトの作成ウィザードでエンティティ・オブジェクトが使用可能になります。JARのビュー・オブジェクトも使用可能になります。

タスク・フロー

「コンポーネント」ウィンドウにタスク・フローが表示されます。

ページ・テンプレート

JSFの作成ウィザードでページ・テンプレートが使用可能になります。

宣言的なコンポーネント

「コンポーネント」ウィンドウにタグ・ライブラリが表示されます。宣言的なコンポーネントがリストに表示されます。

50.3.4 ADFライブラリのコンポーネントの使用に関する必知事項

ADFライブラリJARをプロジェクトに追加する手順は標準化されており、コンポーネントがJDeveloperに表示される場所と、それを再利用できる方法は、コンポーネントのタイプによって決まります。

50.3.4.1 データ・コントロールの使用方法

プロジェクトにデータ・コントロールを追加すると、「データ・コントロール」パネルにデータ・コントロールが表示されます。「リソース」ウィンドウを使用している場合は、オプションで、データ・コントロールの項目を「リソース」ウィンドウから「データ・コントロール」パネルにドラッグ・アンド・ドロップした後で、「データ・コントロール」パネルからページにドラッグ・アンド・ドロップできます。

50.3.4.2 アプリケーション・モジュールの使用方法

プロジェクトにアプリケーション・モジュールを追加すると、「データ・コントロール」パネルにアプリケーション・モジュールが表示されます。「リソース」ウィンドウを使用している場合は、オプションで、アプリケーション・モジュール項目を「リソース」ウィンドウから「データ・コントロール」パネルにドラッグ・アンド・ドロップした後で、「データ・コントロール」パネルからページにドラッグ・アンド・ドロップできます。

アプリケーション・モジュールは、ビジネス・コンポーネントに関連付けられます。再利用可能なアプリケーション・モジュールがパッケージ化されている場合、JARにはそのアプリケーション・モジュールの作成に使用されたビジネス・コンポーネントが含まれます。このコンポーネントは再利用可能です。

50.3.4.3 ビジネス・コンポーネントの使用方法

ビジネス・コンポーネントも、パッケージ化および再利用が可能です。エンティティ・オブジェクト、ビュー・オブジェクトおよびアソシエーションを一緒にパッケージ化して、使用側プロジェクトに追加できます。デフォルトでは、アプリケーション・モジュールをパッケージ化するとJARにビジネス・コンポーネントが組み込まれますが、ビジネス・コンポーネントは、関連するアプリケーション・モジュールがなくても、ビジネス・コンポーネント自体で再利用できます。

ビジネス・コンポーネントの再利用方法としては、ADFライブラリJARのエンティティ・オブジェクトを使用して新しいビュー・オブジェクトを作成することがあります。ウィザードを使用してビュー・オブジェクトを追加すると、ビュー・オブジェクトの生成をサポートするために、エンティティ・オブジェクトがウィザードで使用可能になります。ビュー・オブジェクトを作成する手順は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。ビュー・オブジェクトの作成に使用するエンティティ・オブジェクトを選択する画面が表示されると、図50-18に示すように、ADFライブラリのエンティティ・オブジェクトがシャトル・ウィンドウで選択可能になります。

図50-18 ADFライブラリのエンティティ・オブジェクトを使用したビュー・オブジェクトの作成

ADFライブラリJARを追加する前に使用側プロジェクトで「ビジネス・コンポーネント用にプロジェクトを初期化」オプションを選択しておいた場合(「プロジェクト・プロパティ」ダイアログの「ビジネス・コンポーネント」ページ)、JAR内のビジネス・コンポーネントは、プロジェクトに対して自動的に利用可能になります。

先にADFライブラリJARを追加してから「ビジネス・コンポーネント用にプロジェクトを初期化」を選択すると、JDeveloperにより、ビジネス・コンポーネントが自動的にロードされます。

50.3.4.4 タスク・フローの使用方法

コンポーネントをJSFページに追加するときには、プロジェクトに追加されたタスク・フローが「コンポーネント」ウィンドウに表示されます。「リソース」ウィンドウを使用している場合は、図50-19に示すように、タスク・フローを「リソース」ウィンドウから別のタスク・フローまたはページに直接ドラッグ・アンド・ドロップすることもできます。

図50-19 「リソース」ウィンドウを使用したタスク・フローのドラッグ・アンド・ドロップ

タスク・フローの作成の詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。

50.3.4.5 ページ・テンプレートの使用方法

プロジェクトに追加したページ・テンプレートは、「アプリケーション」ウィンドウでは公開されません。イメージ・ファイルなどの個々のサポート・ファイルには、直接アクセスすることはできません。ただし、テンプレートではそのサポート・ファイルへのアクセスをJAR内に保持しており、テンプレートはプロジェクト内で完全に再利用可能です。適用後のテンプレートは、そのテンプレートにロードされているすべてのイメージを保持します。

ページ・テンプレートは、ウィザードを使用して新しいJSFページを作成するときに公開され、アクセス可能になります。ページ・テンプレートを使用するオプションがウィザードで表示されると、ADFライブラリ・テンプレートがドロップダウン・リストに表示されます。たとえば、SummitTemplateというページ・テンプレートがADFライブラリからロードされている場合、ウィザードを使用してJSFページを作成するときに、SummitTemplateがウィザードに表示されます(図50-20を参照)。ページ・テンプレートを使用してJSFページを作成する方法の詳細は、「ページ・テンプレートの使用方法」および『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

図50-20 ADFライブラリからのページ・テンプレートの使用

50.3.4.6 宣言コンポーネントの使用方法

宣言的なコンポーネントをプロジェクトに追加すると、そのコンポーネントを含むJSPタグ・ライブラリがプロジェクトに追加されます。このタグ・ライブラリが「コンポーネント」ウィンドウに表示され、宣言的なコンポーネントの選択が可能になります。宣言コンポーネントの作成および使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

50.3.5 ADFライブラリのコンポーネントの区別に関する必知事項

アプリケーション開発中に作成したコンポーネントとADFライブラリからインポートしたコンポーネントが混在する場合は、JDeveloperのツールチップ機能を使用して区別できます。

カーソルをアプリケーション・モジュールまたはデータ・コントロールの上に移動すると、ソースのフルパスが表示されます。パスにADFライブラリJARファイルが含まれている場合、そのコンポーネントのソースはADFライブラリです。

注意:

データ・コントロール・パネルの項目のツールチップは、このセッションでノードを開いたことがあるかどうかによって変わります。最も完全なツールチップを表示していることを確認するには、項目を開く必要があります。

50.3.6 実行時に行われる処理: プロジェクトへのADFライブラリの追加方法

プロジェクトおよびクラス・パスに追加されたADFライブラリJARは、他のライブラリ・ファイルと同様に動作します。実行中に、ADFライブラリJAR内のコンポーネントを使用するコンポーネントは、そのオブジェクトを参照します。このプロセスは透過的であり、プロジェクト用に開発されたコンポーネントとADFライブラリJAR内のコンポーネントを区別する必要はありません。図50-21に、プロジェクトに対して定義されたADFライブラリとJARへのパスを示します。

図50-21 クラス・パスにADFライブラリが表示されている「ライブラリ定義の編集」ダイアログ

注意:

ADFライブラリJARを作成すると、コンポーネントの作成に使用したあらゆるJavaソースをJARで使用できなくなります。使用者がデバッグなどの目的でソースにアクセスできるようにする場合、これらを別々に配信する必要があります(通常ZIPファイルで配信)。使用者は、自分のプロジェクトのADFライブラリ「ライブラリとクラスパス」エントリの「ソースパス」エントリの関連コンポーネント・ソースとしてそのZIPファイルを指定できます。

50.4 プロジェクトからのADFライブラリJARの削除

「リソース」ウィンドウを使用してADFライブラリJARをプロジェクトから削除したり、「プロジェクト・プロパティ」ダイアログを使用してJARを手動で削除できます。プロジェクト内のコンポーネントに、ADFライブラリJARのコンポーネントに対する依存性がない場合のみ、ADFライブラリJARを削除できます。

JARを削除すると、プロジェクトのクラス・パスに表示されなくなり、そのすべてのコンポーネントは使用できなくなります。

50.4.1 「リソース」ウィンドウを使用してプロジェクトからADFライブラリJARを削除する方法

「リソース」ウィンドウでは、単純なコマンドを使用して、以前に追加したADFライブラリJARをプロジェクトから削除できます。

始める前に:

ADFコンポーネントをパッケージ化するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「プロジェクトからのADFライブラリJARの削除」を参照してください。

ADFコンポーネントをパッケージ化する際に使用できる機能を理解することも役立つ場合があります。詳細は、「再利用可能なADFコンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 「リソース」ウィンドウを使用してADFライブラリJARを追加します。詳細は、「プロジェクトへのADFライブラリ・コンポーネントの追加」を参照してください。

「リソース」ウィンドウを使用してプロジェクトからADFライブラリJARを削除するには:

1. メイン・メニューで、「ウィンドウ」→「リソース」を選択します。

2. 「アプリケーション」ウィンドウで、削除するADFライブラリJARを含むプロジェクトを選択します。

3. 「リソース」ウィンドウで、現在のプロジェクトから削除するADFライブラリJARを検索します。

4. そのJARを右クリックして、「アクティブなプロジェクトから削除」を選択します。

50.4.2 ADFライブラリJARをプロジェクトから手動で削除する方法

ADFライブラリJARを手動で削除するときは、的確なライブラリを削除するよう注意してください。ライブラリの中には、プロジェクトの操作に不可欠なものもあります。

始める前に:

ADFコンポーネントをパッケージ化するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「プロジェクトからのADFライブラリJARの削除」を参照してください。

ADFコンポーネントをパッケージ化する際に使用できる機能を理解することも役立つ場合があります。詳細は、「再利用可能なADFコンポーネントの追加機能」を参照してください。

次のタスクを完了する必要があります。

- 手動でADFライブラリJARを追加します。詳細は、「プロジェクトへのADFライブラリ・コンポーネントの追加」を参照してください。

ADFライブラリJARをプロジェクトから手動で削除するには:

1. 「アプリケーション」ウィンドウで、プロジェクトをダブルクリックします。

2. 「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」ノードを選択します。

3. 「クラスパス・エントリ」リストで、「ADFライブラリ」を選択し、「編集」をクリックします。

4. 「ライブラリ定義の編集」ダイアログで、削除するADFライブラリJARを「クラスパス」ノードの下から選択し、「削除」をクリックします。

5. 「OK」をクリックして削除を確認し、「OK」を再度クリックしてダイアログを閉じます。

51 MDSによるアプリケーションのカスタマイズ

この章では、Oracle Metadata Services (MDS)フレームワークによって提供されるカスタマイズ機能を使用して、顧客がカスタマイズおよびデプロイできるFusion Webアプリケーションを開発する方法について説明します。これらのアプリケーションにカスタマイズを実装する方法についても説明します。

この章の内容は次のとおりです。

- カスタマイズおよびMDSについて

- カスタマイズ可能なアプリケーションの開発

- アプリケーションのカスタマイズ

- カスタマイズしたアプリケーションをパッケージ化してデプロイする方法

- 拡張メタデータ・プロパティ

- カスタマイズ構成の実行時変更の有効化

カスタマイズしたアプリケーションのデプロイ方法の詳細は、「アプリケーションのデプロイ」を参照してください。

51.1 カスタマイズおよびMDSについて

MDSのカスタマイズ機能を使用して、次のカスタマイズ・パターンのアプリケーションを作成できます。

- シード・カスタマイズ
アプリケーションのシード・カスタマイズとは、汎用化されたアプリケーションを特定のグループ(特定の産業やサイトなど)のニーズにあわせて変更するプロセスです。シード・カスタマイズはデプロイされたアプリケーションの一部として存在し、特定のデプロイ期間中保持されます。この章では、カスタマイズ可能なアプリケーションを作成し、JDeveloperを使用してそのアプリケーションをカスタマイズする方法について説明します。

- ユーザー・カスタマイズ(変更永続性)
ユーザー・カスタマイズでは、エンド・ユーザーは実行時に個々の設定(表にどの列を表示するかなど)にあわせてアプリケーションの内容を変更できます。変更内容は、次回そのアプリケーションを開くときに記憶されます。ユーザー・カスタマイズの詳細は、「実行時のユーザー・カスタマイズの許可」を参照してください。

- 実行時のデザインタイム
Oracle WebCenter Portalの機能を使用して、実行時にカスタマイズ可能なアプリケーションを作成できます。これにより、ビジネス・アナリストや管理者はWebブラウザ・インタフェースを使用して、エンド・ユーザー向けにアプリケーションをカスタマイズできます。ランタイムのカスタマイズの詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

MDSアーキテクチャとメタデータ・リポジトリ(データベース・ベースおよびファイル・ベース)およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項を参照してください。

51.1.1 カスタマイズおよびレイヤーのユースケースおよび例

カスタマイズしたアプリケーションは、ベース・アプリケーションとカスタマイズを含む1つ以上のレイヤーで構成されます。MDSは、カスタマイズをメタデータ・リポジトリに格納し、実行時にこのカスタマイズを取得してベース・メタデータにマージし、カスタマイズ済アプリケーションを公開します。カスタマイズはベースとは別個に保存されるため、アップグレードの際にカスタマイズが保護されます。つまり、新しいパッチをベースに適用する場合でも、カスタマイズに影響を与えずに行えるということです。カスタマイズ済アプリケーションが起動されると、カスタマイズの内容がベース・アプリケーションに適用されます。

たとえば、給与フィールドを4000に制限する検証規則を持つ、一般的な給与アプリケーションがあるとします。次に、給与フィールドを3300に制限する、この検証規則のカスタマイズを作成します。実行時に、ベース・アプリケーションにカスタマイズが適用され、給与フィールドの検証規則によりフィールドは3300に制限されます。

カスタマイズ可能なアプリケーションには、複数のカスタマイズ・レイヤーを設定できます。カスタマイズ・レイヤーには、業種やサイトなどがあります。各レイヤーには複数のカスタマイズ・レイヤー値を設定できますが、通常、実行時には、各レイヤーからこのようなレイヤー値が1つだけ適用されます。たとえば、カスタマイズ可能なアプリケーションのindustryレイヤーには、healthcareやfinancialなどの業種の値を格納できます。一方、デプロイ対象のカスタマイズ済アプリケーションで一度に使用されるのは、このレイヤー値のいずれか1つのみです。

複数のカスタマイズ・レイヤーからのレイヤー値を、指定の優先順位に従ってベース・メタデータの最上位に適用できます。たとえば、カスタマイズされたアプリケーションでは、industryレイヤーのfinancialレイヤー値とsiteレイヤーのFinancial Company #1レイヤー値にカスタマイズを含めることができます。各カスタマイズ・レイヤーは、基礎となるメタデータを変更する一連の指示を含んだカスタマイズ・ドキュメントに対応します。

カスタマイズしたアプリケーションのカスタマイズ・コンテキストは、適用された一連のカスタマイズ・レイヤー値により定義されます。

図51-1に、カスタマイズしたアプリケーションにレイヤーを適用する方法を示します。

図51-1 レイヤー化されたカスタマイズの例

これをサポートするために、JDeveloperを使用してカスタマイズ・クラスを作成し、レイヤーと値を定義して、優先順位を指定します。これらのプロセスの詳細は、「カスタマイズ可能なアプリケーションの開発」を参照してください。

51.1.2 静的および動的なカスタマイズ・コンテンツ

カスタマイズは、静的なものと動的なものに分類できます。動的なカスタマイズでは、アプリケーションの実行コンテキストによって変化する値を指定できるのに対し、静的なカスタマイズでは、アプリケーションのすべての実行で有効な1つのレイヤー値のみを指定できます。アプリケーションを実行する様々なユーザーによってカスタマイズが変化する可能性がある場合、それは動的なカスタマイズです。アプリケーションを実行するすべてのユーザーでカスタマイズの値が同じである場合、それは静的なカスタマイズです。

ADFビジネス・コンポーネント・オブジェクトにカスタマイズを実装する場合、カスタマイズはアプリケーションの実行時全体にわたって変化しません。これらのオブジェクトはアプリケーションに対して1回だけロードされ、アプリケーションの継続中再利用されるためです。たとえば、サイト・レイヤーのHealthcare Company #1値で、そのサイトの給与フィールドを3300に制限するカスタマイズされた検証規則を持つことができます。これは静的なカスタマイズ・コンテンツです。

ただし、ユーザー・ロール(職責)または他のアプリケーション固有の条件に基づいて実行時にレイヤー値を決定できるカスタマイズを、コントローラ・レベルまたはビュー・レベルで実装することもできます。たとえば、組織が異なるユーザーには画面上で異なるフィールドを表示するように、アプリケーションを設計できます。これは動的なカスタマイズ・コンテンツです。

カスタマイズが静的か動的かの判断は、カスタマイズ・クラスで行われます。カスタマイズ・クラスで、getCacheHint()メソッドがALL_USERSを戻す場合、カスタマイズ・レイヤーは静的です。CacheHint値の詳細は、「カスタマイズ・クラスに関する必知事項」を参照してください。

カスタマイズ・クラスの実装方法によっては、すべてのオブジェクトが静的なカスタマイズ・レイヤーを持つことができます。ただし、ADFビジネス・コンポーネント・オブジェクトの場合、静的なカスタマイズしか使用できません。

51.1.3 カスタマイズの追加機能

カスタマイズを使用し始める前に、他の機能を理解することが役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- MDSアーキテクチャとメタデータ・リポジトリ(データベース・ベースおよびファイル・ベース)およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項を参照してください。

- ADF Faces変更永続性フレームワークを使用して、ユーザーが実行時にカスタマイズ可能なJSFページを作成できます。詳細は、「実行時のユーザー・カスタマイズの許可」を参照してください。

- Oracle WebCenter Portalの機能により、ビジネス・アナリストや管理者はWebブラウザ・インタフェースを使用して、エンド・ユーザー向けにアプリケーションをカスタマイズできます。ランタイムのカスタマイズの詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

51.2 カスタマイズ可能なアプリケーションの開発

カスタマイズ可能なアプリケーションを作成するには、ベース・アプリケーションを作成して次の手順を実行します。

カスタマイズ用にアプリケーションを準備するには:

1. 「カスタマイズ・クラスの作成方法」の説明に従って、使用するカスタマイズ・クラスを作成します。

2. 「ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションでシード・カスタマイズを有効化します。

3. 「adf-config.xmlファイルの構成方法」の説明に従って、adf-config.xmlファイルでカスタマイズ・クラスを指定します。

4. オプションで、「拡張メタデータ・プロパティを編集する方法」の説明に従って、アプリケーションでランタイム・カスタマイズを制限できます。

5. カスタマイズ用にアプリケーションを準備した後、「カスタマイズ・レイヤーの構成方法」の説明に従って、JDeveloperを使用してカスタマイズを実装できるようにJDeveloperを準備する必要があります。

51.2.1 カスタマイズ・クラスの作成方法

カスタマイズ・クラスとは、ベース定義メタデータに適用するカスタマイズを定義するためにMDSが使用するインタフェースです。各カスタマイズ・クラスでカスタマイズ・レイヤー(industryやsiteなど)を定義して、複数のレイヤー値を含めることができます。アプリケーションで使用するカスタマイズ・クラスは、アプリケーションのカスタマイズ時にJDeveloperで使用できる必要があります。また、デプロイされたアプリケーションに含める必要があります。

51.2.1.1 カスタマイズ・クラス

カスタマイズ・クラスでは、現在のコンテキストが評価されてStringの結果が戻されます。このStringの結果を使用してカスタマイズ・レイヤーが検索されます。

カスタマイズ・クラスによって、次の情報が提供されます。

- レイヤー名を表す名前。

- カスタマイズ・レイヤー値を表す値の配列通常、各レイヤーで値が1つ戻されます。複数の値が戻される場合、MDSリポジトリでこれらの値に使用可能なカスタマイズが、配列に表示された順序で適用されます。null値や、空の文字列("")を含む配列は、適用するカスタマイズ・レイヤーが存在しないことを示します。詳細は、「カスタマイズ・クラスでのgetValue()メソッドの実装」を参照してください。

- レイヤーで作成されたオブジェクトのIDPrefix。カスタマイズ・レイヤーで新しいオブジェクトを作成する場合、一意のIDが必要です。オブジェクトの自動生成IDにIDPrefixが追加されて、新たに追加されたオブジェクトのIDが作成されます。異なるカスタマイズ・レイヤーで作成されたオブジェクトに一意のIDを指定するために、各レイヤーに一意のIDPrefixを指定する必要があります。

- カスタマイズ・クラスによって定義されたレイヤーのキャッシュ・ヒント。キャッシュ・ヒントは、レイヤーが静的か動的かを定義します。getCacheHint()メソッドがALL_USERSを戻す場合、カスタマイズ・レイヤーは静的です。動的なカスタマイズの詳細は、「静的および動的なカスタマイズ・コンテンツ」を参照してください。CacheHint値の詳細は、「カスタマイズ・クラスに関する必知事項」を参照してください。

カスタマイズを使用して、特定の業種ドメインにあわせてアプリケーションを調整できます(垂直統合)。このようなドメインはそれぞれカスタマイズ・レイヤーを表しており、カスタマイズ・クラスを使用して示されます。

カスタマイズ・クラスを使用してシード・カスタマイズを実装するには:

- adf-config.xmlのcust-configセクション(mds-configの下)に、カスタマイズ・クラスへの参照を含める必要があります(「adf-config.xmlファイルの構成方法」を参照)。
カスタマイズ構成(cust-config)セクションでは、カスタマイズしたアプリケーションのカスタマイズ・クラスと優先順位が指定されます。「adf-config.xmlファイルの構成方法」を参照してください。

- カスタマイズ・クラスをアプリケーションに含め、シード・カスタマイズをサポートする必要があります。
詳細は、「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」を参照してください。実行時に、EARレベルのアプリケーション・クラス・ローダーで、該当のカスタマイズ・クラスを使用できる必要があります。

- レイヤー値が、CustomizationLayerValues.xmlファイルにリストされている必要があります。
このファイルは、jdev_install\jdevディレクトリにあります。このファイルのレイヤーの名前は、カスタマイズ・クラスと一致する必要があります。(詳細は、「カスタマイズ・レイヤーの構成方法」を参照。)JDeveloperは、このファイルを使用して、設計時にレイヤー値を取得します。

「カスタマイズ開発者」ロールでJDeveloperが起動されると、「カスタマイズ・コンテキスト」ウィンドウに使用可能なカスタマイズ・レイヤーとレイヤー値が表示されます。「カスタマイズ・コンテキスト」ウィンドウで、カスタマイズを適用するレイヤーと値を選択します。「カスタマイズ開発者」ロールでの作業の詳細は、「「カスタマイズ開発者」ロールの概要」を参照してください。カスタマイズ先として選択したレイヤーは、ヒント・レイヤーと呼ばれます。詳細は、「ヒント・レイヤーの概要」を参照してください。

次の例は、サンプルのカスタマイズ・クラスを示しています。すべてのカスタマイズ・クラスは、単一の引数なしのコンストラクタを持っている必要があります。

package mycompany;

import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
import oracle.mds.core.MetadataObject;
import oracle.mds.core.RestrictedSession;
import oracle.mds.cust.CacheHint;
import oracle.mds.cust.CustomizationClass;

public class IndustryCC extends CustomizationClass {
private static final String DEFAULT_LAYER_NAME = "industry";
private String mLayerName = DEFAULT_LAYER_NAME;

public IndustryCC() {
}
public CacheHint getCacheHint() {
return CacheHint.ALL_USERS;
}
public String getName() {
return mLayerName;
}

public String generateIDPrefix(RestrictedSession sess, MetadataObject mo) {
return "I";
}

public String[] getValue(RestrictedSession sess, MetadataObject mo) {
// This needs to return the appropriate value at runtime.
return new String[] {"financial"};
}
}

この例では、カスタマイズ・クラスの動作を定義する4つのメソッドgetCacheHint()、getName()、generateIDPrefix()およびgetValue()を示しています。

getCacheHint()の戻り値は、このカスタマイズによりメタデータ・オブジェクトの可視性が広がり、その結果メモリー内での存続期間が長くなることを、MDSに示します。また、レイヤーが静的か動的かも定義します。この例では、getCacheHint()メソッドはALL_USERSを戻すため、カスタマイズ・レイヤーは静的です。CacheHint値の詳細は、「カスタマイズ・クラスに関する必知事項」を参照してください。

getName()メソッドは、カスタマイズ・レイヤーの名前を戻します。たとえば、SiteCCカスタマイズ・クラスはsiteを戻します。この例では、getName()メソッドはindustryを戻します。

generateIDPrefix()メソッドは、IDPrefixを作成します。IDPrefixはレイヤーの名前と値を識別する、一意の省略形の文字列です。カスタマイズ・レイヤーで作成されたオブジェクトのIDの接頭辞として使用されます。デフォルト実装では(IDPrefixが指定されていない場合)、カスタマイズ値と連結されたレイヤー名が戻されます。パフォーマンス上の理由により、IDPrefixは短くする必要があります(4文字以下)。このため、デフォルト実装をオーバーライドする必要があります。関連するgetIDPrefix()メソッドは、カスタマイズ・レイヤーのIDPrefixを戻します。この例では、getIDPrefix()メソッドはI (industryの場合)を戻します。

getValue()メソッドは、カスタマイズ・クラスのカスタマイズ値(複数可)を戻します。この例では、getValue()メソッドは単一値financialを戻し、レイヤー名と組合せてカスタマイズ・コンテキストを定義します。「カスタマイズ・クラスでのgetValue()メソッドの実装」で、getValue()メソッドを使用するその他の手法について説明します。

注意:

レイヤー名に対応する有効なレイヤー値は、JDeveloperによってCustomizationLayerValues.xmlファイルから「カスタマイズ開発者」ロールで取得されます。レイヤーの優先順位は、adf-config.xmlファイルで指定されたカスタマイズ・クラスの順序によって定義されます。レイヤーの名前は、これらのファイルおよびカスタマイズ・クラスで一貫性がある必要があります。

51.2.1.2 カスタマイズ・クラスでのgetValue()メソッドの実装

getValue()メソッドを使用して、アプリケーションのコンテキストとメタデータに基づいて、カスタマイズ・クラスのレイヤー値が取得されます。たとえば、SiteCCカスタマイズ・クラスでgetValue()を呼び出すと、単一エントリheadquartersを持つ配列が戻されます。一般に、getValue()メソッドは単一値を持つ配列を戻します(「カスタマイズ・クラス」を参照)。

getValue()メソッドから複数の値を戻すこともできます(次の例を参照)。

public String[] getValue(RestrictedSession sess, MetadataObject mo) {
return new String[]{"North America", "US", "CA"}
}

複数の値が戻される場合、すべての値に適用できるカスタマイズが適用されます。カスタマイズは、配列に表示された順序で適用されます。この例では、North Americaカスタマイズがベース・アプリケーションに適用され、次にUSカスタマイズが適用され、最後にCAが適用されます。

注意:

カスタマイズ・レイヤーに複数の値を戻すことは高度な概念で、通常は必要とされません。

getValue()メソッドは、現行ユーザーの現在の実行コンテキストに基づいてレイヤー値を戻すことができます。この値は、クライアントが保持する静的またはスレッド・ローカル状態から、またはMDSセッションでメタデータ・オブジェクト名に基づいてクライアントによって設定されたプロパティから取得されます。次の例は、このタイプの実装を示しています。

public String[] getValue(RestrictedSession sess, MetadataObject mo) {
if (mo.getName().equals("/sample/abc.jspx"))
{
return new String[]{"Headquarters"};
}
else
{
return new String[]{"RemoteSite"};
}
}

この例では、getValue()メソッドはメタデータ・オブジェクトでgetName()メソッドを使用して、メタデータ・ドキュメントの名前が/sample/abc.jspxかどうかを判断します。この名前である場合、getValue()はHeadquartersを戻して、headquartersカスタマイズを適用します。この名前でない場合、RemoteSiteを戻して、リモート・サイトのカスタマイズを適用します。

注意:

getValue()メソッドをコーディングし、メタデータ・オブジェクトに基づいて値を戻すことは、高度な概念で通常は必要とされません。動的なレイヤーのカスタマイズ・コンテキストは、通常、ユーザー名や職責などアプリケーション・コンテキストのファセットよって決定されます。

開発サイクル中に有効なその他の手法として、外部プロパティ・ファイルを使用してレイヤー値を指定する手法があります。次の例は、レイヤー値を格納するプロパティ・ファイル(customization.properties)を参照しています。

public String[] getValue(RestrictedSession sess, MetadataObject mo) {
Properties properties = new Properties();
String configuredValue = null;
Class clazz = IndustryCC.class;
InputStream is = clazz.getResourceAsStream("/customization.properties");
if (is != null){
try {
properties.load(is);
String propValue = properties.getProperty(mLayerName);
if (propValue != null){
configuredValue = propValue;
}
} catch (IOException e) {
e.printStackTrace();
}
finally {
try {
is.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
return new String[] {configuredValue};
}

この手法を使用するアプリケーションがJDeveloperで実行されている場合、プロパティ・ファイルでレイヤー値を変更し、ブラウザをリフレッシュして、適用される新しいカスタマイズを確認できます。このカスタマイズ・クラスとプロパティ・ファイルの組合せによって、レイヤー値を別のファイルに保持できるため、特定のデプロイメントのためにJavaコードを修正およびリコンパイルしてレイヤー値を変更する必要はありません。customization.propertiesファイルを使用する場合は、同じクラス・ローダーからロードされるように、カスタマイズ・クラスとともにパッケージ化する必要があります。

次の例は、customization.propertiesファイルのサンプルを示しています。このプロパティ・ファイルでIndustryCCクラスがロードされる場合、レイヤー値healthcareが適用されます。

#Configured values for the default layer values
industry=healthcare
site=headquarters

51.2.1.3 カスタマイズ・クラスの作成

カスタマイズ・クラスを作成したら、別個のプロジェクトに配置します。これにより、これらをJARにデプロイし、JARをカスタマイズ可能なアプリケーションにインポートできます。このアプローチによってモジュール性が高まり、カスタマイズ・クラスを社内の複数のアプリケーションに容易に組み込み、一元的にパッチを適用できます。このアプローチの詳細は、「カスタマイズ・クラスの使用方法」を参照してください。

また、1つのアプリケーションのみで使用するカスタマイズ・クラスを作成している場合、単純にJDeveloperからアプリケーションをローカルで実行する場合またはMDS構成を使用してリモートにデプロイする場合、カスタマイズ・クラスをデータ・モデル・プロジェクトに配置できます。

アプリケーションにカスタマイズ・クラスのコピーが1つしかないことおよびEARレベルのアプリケーション・クラス・ローダーからロードできるようにJARファイルにパッケージ化されていること、を確認してください。デフォルトでは、プロジェクトの依存性を追加すると、カスタマイズ・クラスがWARプロファイルに追加されます。これは、アプリケーションをパッケージ化してデプロイした後は正しく機能しません。デプロイ用にアプリケーションをパッケージ化する方法の詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。

カスタマイズ・クラスを作成するには、次の手順を使用します。

始める前に:

カスタマイズ・クラスの機能に関する知識が役立つ場合があります。詳細は、「カスタマイズ・クラス」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ・クラスを保持するアプリケーションを開く(または作成する)必要があります。

カスタマイズ・クラスを作成するには:

1. メイン・メニューから、「ファイル」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「一般」を開き、「プロジェクト」、続いて「Javaアプリケーション・プロジェクト」を選択し、「OK」をクリックします。

3. Javaプロジェクトの作成ダイアログで、プロジェクトの適切な設定を指定して、「終了」をクリックします。

注意:

すべてのカスタマイズ・クラスを保持するには、単一のプロジェクトを使用する必要があります。

Javaプロジェクトの作成ダイアログのオプションの詳細は、オンライン・ヘルプを参照してください。

4. 「アプリケーション」ウィンドウで、プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

5. 「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」,をクリックしてから「ライブラリの追加」を選択します。

6. 「ライブラリの追加」ダイアログでMDSランタイムを選択し、「OK」をクリックし、もう一度「OK」をクリックして「プロジェクト・プロパティ」ダイアログを閉じます。

7. 「アプリケーション」ウィンドウで、プロジェクトを右クリックし、「新規」→「Javaクラス」をクリックします。

8. 「Javaクラスの作成」ダイアログで、クラスの名前と適切なパッケージを入力します。

注意:

カスタマイズ・クラスには一般に、戻すレイヤー名が付けられます。たとえば、レイヤー名industryを戻すカスタマイズ・クラスには、IndustryCCという名前が付けられます。

9. 「拡張」フィールドにoracle.mds.cust.CustomizationClassと入力します。

このクラスの詳細は、Javadocを参照してください。

10. 「抽象メソッドの実装」が選択されていることを確認して、「OK」をクリックします。

11. 生成されたファイルのコードを「カスタマイズ・クラス」で説明しているようなコードに置き換えます。

12. 変更内容を保存してプロジェクトを再ビルドします。

これでカスタマイズ・クラスが作成されます。サンプル・コードではパッケージ名mycompanyとクラス名IndustryCCが使用されています。これらを、アプリケーションにあわせて変更する必要があります。

51.2.2 カスタマイズ・クラスに関する必知事項

「カスタマイズ・クラス」で説明したように、カスタマイズ・クラスではカスタマイズ・レイヤーでのメタデータ・オブジェクトの可視性、およびその結果としてのメモリー内での存続期間を指定するCacheHintが定義されます。MDSはこの情報を使用して、カスタマイズをキャッシュするかどうか、およびどこにキャッシュするかを決定します。このカスタマイズ・クラスを使用して構築されたカスタマイズ・レイヤーは、このキャッシュ・ヒントを持ちます。

次の定数は、CacheHintでサポートされる値です。

- ALL_USERS - カスタマイズは特定のデプロイメントでグローバルに適用されます(条件付きではない)。この定数は、静的なカスタマイズ・レイヤーで使用されます。

- MULTI_USER - カスタマイズは複数のユーザーに適用されます。

- REQUEST - カスタマイズは、リクエスト期間にのみ適用されます。

- USER - カスタマイズは単一ユーザーに対して、ユーザーのアプリケーション・セッション中にアクセスされるドキュメントに適用されます。(Webアプリケーションでは、アプリケーション・セッションは通常サーブレット・セッションです。)

注意:

カスタマイズ・クラスは頻繁に実行されることが多いため(レイヤー名とレイヤー値を取得するために、アクセスされるドキュメントごとに1度)、効率性を確保するようにしてください。

51.2.3 カスタマイズ・クラスの使用方法

カスタマイズ・クラスを作成後、これらを設計時に「カスタマイズ開発者」ロールでおよび実行時にアプリケーションで使用できます。アプリケーションまたはJDeveloperで使用するには、クラスを適切にパッケージ化する必要があります。

51.2.3.1 設計時にJDeveloperでカスタマイズ・クラスを使用可能にする

カスタマイズ・クラスの作成後、JDeveloperでカスタマイズ・クラスを使用可能にして、カスタマイズの実装時に「カスタマイズ開発者」ロールで操作中に使用できるようにする必要があります。

カスタマイズ・クラスは再利用可能コンポーネントであるため、別個のプロジェクトを作成してこれにカスタマイズ・クラスを含めて、独自のJARファイルにパッケージ化できます。その後、使用するアプリケーションにJARをインポートし、カスタマイズ・クラスをJDeveloperで使用できます。別個のプロジェクトにカスタマイズ・クラスを作成する方法の詳細は、「カスタマイズ・クラスの作成」を参照してください。JARファイルにカスタマイズ・クラスをパッケージ化する方法の詳細は、「JARへのカスタマイズ・クラスの追加」を参照してください。

注意:

使用するアプリケーションのデータ・モデル・プロジェクトでカスタマイズ・クラスを作成した場合、この手順は不要です。

次の手順を使用してアプリケーションでカスタマイズ・クラスを表示できるようにしてから、「adf-config.xmlファイルの構成方法」の説明に従って、カスタマイズ・クラスをadf-config.xmlファイルのcust-configセクションに追加します。

始める前に:

カスタマイズ・クラスをパッケージ化する方法に関する知識が役立つ場合があります。詳細は、「カスタマイズ・クラス」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ・クラスの作成」の説明に従って、外部プロジェクトでカスタマイズ・クラスを作成します。

- 「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。

- Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。

外部プロジェクトからカスタマイズ・クラスを使用するには:

1. 「アプリケーション」ウィンドウで、「アプリケーション・メニュー」アイコンをクリックして、「アプリケーション・プロパティ」を選択します。

2. 「アプリケーションのプロパティ」ダイアログで、「ライブラリとクラスパス」を選択し、「JAR/ディレクトリの追加」をクリックします。

3. 「アーカイブまたはディレクトリの追加」ダイアログで、カスタマイズ・クラスを含む作成済JARファイルを選択して、「開く」をクリックします。

4. 「OK」をクリックします。

JDeveloperでプロジェクトをローカルに実行するためやカスタマイズのために、カスタマイズ・クラスを使用できます。またこれらは、アプリケーションをパッケージ化するときに、EARクラス・パスにパッケージ化されます。

51.2.3.2 実行時にアプリケーションでカスタマイズ・クラスを使用可能にする

カスタマイズしたアプリケーションをパッケージ化してデプロイする際、アプリケーションのクラス・パスで、アプリケーション・レベルでカスタマイズ・クラスを使用できる必要があります。

アプリケーションのデプロイメント・プロファイルを定義する際、カスタマイズ・クラスJARファイルをEARアセンブリに追加する必要があります。また、重複を避けるために、WARプロファイルにカスタマイズ・クラスJARファイルが含まれないようにする必要があります。詳細は、「アプリケーション・レベルのEARデプロイメント・プロファイルの作成」を参照してください。

51.2.4 ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法

すべてのカスタマイズ可能なコンポーネントと同様に、カスタマイズ可能なメタデータ・オブジェクトのXML要素はMDSによって一意に識別できる必要があるため、NULL以外の一意の識別子を指定する必要があります。このコンポーネントの識別子を使用して、カスタマイズ・レイヤー内のカスタマイズ指示の要素を参照します。IDプロパティは、ADF Faces .jspxまたは.jsffファイルの各タイプのコンポーネントの識別子です。

JSFページとJSPページでカスタマイズを可能にするには、ページの一部のデフォルト設定を受け入れずに、アプリケーションのユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効にする必要があります。これは、モデル・プロジェクトとコントローラ・プロジェクトでは不要です。

注意:

MDSでは、カスタマイズするにはこれらのページがXMLベースである必要があります。このため、.jspファイルではカスタマイズできません。かわりに.jspxファイルを使用してください。

さらに、Faceletファイルには、カスタマイズを可能にするために拡張子.jsfを付ける必要があります。MDSではこの拡張子を使用して、そのファイルをFaceletsファイルとして認識します。

始める前に:

シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。

ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効にするには:

1. 「アプリケーション」ウィンドウで、ユーザー・インタフェース・プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで「ADFビュー」を選択し、「シード・カスタマイズの有効化」チェック・ボックスを選択します(図51-2)。

3. 「OK」をクリックします。

4. プロジェクトの変更を保存します。

図51-2 「プロジェクト・プロパティ」 - 「シード・カスタマイズの有効化」

51.2.5 既存のページでシード・カスタマイズを有効化する方法

プロジェクトに前のバージョンのJDeveloperで作成されたページがある場合、これらの既存のページでもシード・カスタマイズを有効にする必要があります。これは、アプリケーションを前のバージョンのJDeveloperから移行して、移行中にIDを生成していない場合にのみ必要です。

始める前に:

シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。

既存のページでシード・カスタマイズを有効にするには:

1. 監査プロファイルを作成して、ページのすべてのXMLオブジェクトにIDトークンを実装します。

a. メイン・メニューから、「ツール」→「プリファレンス」を選択します。

b. 「プリファレンス」ダイアログで、「監査」→「プロファイル」を選択します。

c. 「プロファイル」ページで、「ルール」をクリックして、すべてのルールを選択解除します。

d. アプリケーション開発→「ADF Faces」→「コンポーネントIDルール」の順に開きます。

e. ルール「ADF Facesが存在する場合、IDをチェックします」を選択します。

f. 「デフォルト修正」ドロップダウン・リストで、「一意のIDの生成」を選択します。

g. 「名前を付けて保存」をクリックし、プロファイルに識別可能な名前(「一意のIDの生成」など)を入力して「保存」をクリックします。

h. 「OK」をクリックして「プリファレンス」ダイアログを閉じます。

2. 「アプリケーション」ウィンドウで、シード・カスタマイズを有効にするページを選択します。プロジェクトを選択して、そのプロジェクトに含まれるすべてのファイルに対して監査を実行することもできます。

3. メイン・メニューから「ビルド」→「監査」を選択します。

4. 「監査」ダイアログで、作成したプロファイルを選択してIDを生成し、「実行」をクリックします。

5. ログ・ウィンドウを使用して問題を確認し、修正を適用します。

6. 監査が完了したら、変更内容を保存します。

51.2.6 リソース・バンドルでカスタマイズを有効化する方法

カスタマイズの実装時に新しいリソース・キーを作成する予定がある場合、「アプリケーション・プロパティ」ダイアログを使用して影響を受けるリソース・バンドルを指定できます。

始める前に:

シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。

リソース・バンドルでカスタマイズを有効にするには:

1. 「アプリケーション」ウィンドウのポップアップ・メニューで、「アプリケーション・プロパティ」を選択します。

2. 「アプリケーション・プロパティ」ダイアログで、「リソース・バンドル」をクリックして、「追加」をクリックします。

3. 「リソース・バンドルの選択」ダイアログで、カスタマイズを有効化するリソース・バンドルを探して選択します。

4. 「開く」をクリックします。

5. 「アプリケーション・プロパティ」ダイアログで、「バンドル」表の「オーバーライド済」列のチェックボックスを選択します。

6. 「OK」をクリックします。

51.2.7 adf-config.xmlファイルの構成方法

アプリケーションのadf-config.xmlファイルでは、mds-configセクションで適切なcust-config要素が指定されている必要があります。クライアントはcust-config要素を使用して、順序付けされ、名前が付けられたカスタマイズ・クラスのリストを定義できます。adf-config.xmlファイルの概要エディタを使用して、カスタマイズ・クラスを追加します(図51-3を参照)。

始める前に:

カスタマイズ・クラスを作成しパッケージ化する方法に関する知識が役立つ場合があります。詳細は、「カスタマイズ・クラス」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。

- 「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。

- 「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。

- Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。

adf-config.xmlファイルでカスタマイズ・クラスを識別するには:

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開いて、「adf-config.xml」をダブルクリックします。

2. 概要エディタで「MDS構成」ナビゲーション・タブをクリックして、「追加」アイコンをクリックします。

3. 「カスタマイズ・クラスの編集」ダイアログで、作成済のカスタマイズ・クラスを検索するか、作成済のカスタマイズ・クラスに移動します。

4. 適切なクラスを選択して、「OK」をクリックします。

5. カスタマイズ・クラスをすべて追加した後、矢印アイコンを使用して適切な順序で配置できます。

図51-3は、2つのカスタマイズ・クラスが追加されたadf-config.xmlファイルの概要エディタを示しています。

図51-3 adf-config.xmlの概要エディタ

customization-class要素の順序により、カスタマイズ・レイヤーの優先順位が指定されます。たとえば、次の例に示すコードでは、IndustryCCクラスはSiteCCクラスの前に表示されています。これは、industryレイヤーでのカスタマイズがベース・アプリケーションに適用されてから、siteレイヤーでのカスタマイズが適用されることを示します。

<adf-config xmlns="http://xmlns.oracle.com/adf/config">
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config xmlns="http://xmlns.oracle.com/mds/config" version="11.1.1.000">
<cust-config>
<match path="/">
<customization-class name="com.mycompany.IndustryCC"/>
<customization-class name="com.mycompany.SiteCC"/>
</match>
</cust-config>
</mds-config>
</adf-mds-config>
</adf-config>

51.2.8 カスタマイズ可能アプリケーション作成時の処理内容

カスタマイズ可能アプリケーションを作成する際、カスタマイズしたアプリケーションの基礎として使用するために必要な部分を含むベース・アプリケーションがあります。

カスタマイズを実行するには、「アプリケーションのカスタマイズ」の説明に従って、「カスタマイズ開発者」ロールを使用してJDeveloperでアプリケーションを開く必要があります。

51.2.9 カスタマイズ可能なオブジェクトおよびアプリケーションに関する必知事項

Oracle ADFコンポーネント(コントローラ、モデル、ビジネス・コンポーネント・オブジェクトなど)をカスタマイズするには、これらに一意の識別子を指定する必要があります。ユーザー・インタフェース・プロジェクトのJSPページとJSFページを除き、JDeveloperによって生成されるADFコンポーネントは、デフォルトでは識別子とともに作成されます。JDeveloperにユーザー・インタフェース・プロジェクトのページ上のコンポーネントの識別子を生成させるには、プロジェクト・レベルで明示的に指定する必要があります(「ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法」を参照)。

アプリケーションでカスタマイズを実装する前に、カスタマイズするすべてのオブジェクトに必要な識別子が指定されていることを確認します。多くの場合、監査ルールを実行し、欠落を把握して修正することができます(「既存のページでシード・カスタマイズを有効化する方法」を参照)。

また、カスタマイズ・クラスは頻繁に実行できるため(レイヤー名とレイヤー値を取得するために、アクセスされるドキュメントごとに1度)、効率性を確保するようにしてください。

51.3 アプリケーションのカスタマイズ

「カスタマイズ開発者」ロールを使用して、カスタマイズ可能アプリケーションでカスタマイズを作成できます。

51.3.1 「カスタマイズ開発者」ロールの概要

「カスタマイズ開発者」ロールを使用して、プロジェクトのメタデータをカスタマイズします。カスタマイズ機能は、このロールでのみ使用できます。「カスタマイズ開発者」ロールでは、次の作業を実行できます。

- カスタマイズの作成および更新

- カスタマイズしたアプリケーションのヒント・レイヤーの選択および編集

- 既存のカスタマイズの削除

「カスタマイズ開発者」ロールで作業する場合、ソース・エディタは読取り専用になり、次のJDeveloperの機能が無効になります。

- ワークスペースの移行

- アプリケーションおよびIDE接続の作成、削除および変更「カスタマイズ開発者」ロールでアプリケーションを開く前に、デフォルト・ロールで接続を構成する必要があります。

「カスタマイズ開発者」ロールでアプリケーションを使用する場合、新規オブジェクトは作成できず、カスタマイズ不能オブジェクトは変更できません。ただし、次のコンテンツ・タイプはカスタマイズ可能です。

- ポータル・モジュール

- ADFモジュール(ADF Faces、ADFモデル、ADFビジネス・コンポーネント、ADF Controllerなど)

注意:

ADFビジネス・コンポーネント・オブジェクトは、「カスタマイズ・コンテキスト」ウィンドウで静的カスタマイズ・クラスが選択されている場合のみカスタマイズ可能です。それ以外の場合、ビジネス・コンポーネント・オブジェクトは読取り専用です。

「カスタマイズ開発者」ロールで作業する場合、Javaクラス、リソース・バンドル、セキュリティ・ポリシー、デプロイメント・ディスクリプタ、構成ファイルなどのカスタマイズ不能ファイルは編集できません。「カスタマイズ開発者」ロールで作業している際、カスタマイズ不能ファイルはロック・アイコンで示されます。

注意:

Faceletファイルには、カスタマイズを可能にするために拡張子.jsfを付ける必要があります。MDSではこの拡張子を使用して、そのファイルをFaceletsファイルとして認識します。

プロジェクト設定の変更や、サービス・インタフェースやビジネス・イベント定義など特定のADFビジネス・コンポーネント機能のカスタマイズも制限されます。また、カスタマイズ不能ファイルの変更が必要になる場合は、カスタマイズ可能ファイルをリファクタまたは変更できません。

51.3.2 JDeveloperでの「カスタマイズ開発者」ロールへの切替え

「カスタマイズ開発者」ロールでは、JDeveloperのカスタマイズ機能を使用できます。このロールで作業するには、JDeveloperの起動時に選択するか、JDeveloperがすでに実行されている場合は「ロールの切替え」メニューで「カスタマイズ開発者」ロールに切り替えます。

始める前に:

「カスタマイズ開発者」ロールの機能に関する知識が役立つ場合があります。詳細は、「「カスタマイズ開発者」ロールの概要」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

JDeveloperを起動する必要もあります。

JDeveloperで「カスタマイズ開発者」ロールに切り替えるには:

1. メイン・メニューで「ツール」→「ロールの切替え」→「カスタマイズ開発者」の順に選択します。

注意:

任意で「ツール」→「ロールの切替え」→「起動時にロール選択を常に要求」メニュー・アイテムを切り替え、JDeveloper起動時にロールを選択するかどうかを指定できます。この選択を解除すると、JDeveloperは、最後に閉じたときのロールで起動します。

51.3.3 ヒント・レイヤーの概要

「カスタマイズ開発者」ロールで作業する際、「カスタマイズ・コンテキスト」ウィンドウで選択したレイヤーとレイヤー値の組合せをヒント・レイヤーと呼びます。このレイヤーには、「カスタマイズ開発者」ロールで作業中に行った変更が適用されます。

注意:

「カスタマイズ開発者」ロールで作業している場合、「カスタマイズ・コンテキスト」ウィンドウが表示されない場合は、「ウィンドウ」メニューからアクセスできます。

JDeveloperのエディタに表示されるメタデータは、ベース・メタデータと(adf-config.xmlで設定された優先順位に従った)ヒント・レイヤーまでのカスタマイズ・レイヤーを組み合せたもので、各レイヤーの値は「カスタマイズ・コンテキスト」ウィンドウで指定したものです。

「カスタマイズ開発者」ロールでの作業時には、アプリケーションのカスタマイズされていない状態も確認できます。「カスタマイズ・コンテキスト」ウィンドウで「カスタマイズなしで表示」が選択されている場合、現在使用しているヒント・レイヤーはありません。したがって、表示されているのはカスタマイズされていない状態です。このビューでは、(「アプリケーション」ウィンドウの)カスタマイズ可能ファイルすべてにロック・アイコンが表示され、これらのファイルが読取り専用であることが示されます。

ヒント・レイヤーで行ったカスタマイズは、「プロパティ」ウィンドウではオレンジのアイコンで示されます。緑のアイコンは、ヒント以外のレイヤーのカスタマイズを示します。プロパティの横にオレンジのアイコンが表示されている場合、そのプロパティのドロップダウン・メニューから「カスタマイズ・アクションの削除」を選択して、そのカスタマイズを削除できます。

51.3.4 カスタマイズ・レイヤーの構成方法

アプリケーションをカスタマイズするには、JDeveloperで認識できるように、CustomizationLayerValues.xmlファイルでカスタマイズ・レイヤーとその値を指定する必要があります。

カスタマイズ可能なアプリケーションを「カスタマイズ開発者」ロールで開くと、JDeveloperによりadf-config.xmlファイルが読み取られ、使用するカスタマイズ・クラスと優先順位が判別されます。また、CustomizationLayerValues.xmlファイルも読み取られ、「カスタマイズ・コンテキスト」ウィンドウで使用可能にするレイヤー値が判別されます。CustomizationLayerValues.xmlファイルで定義されたレイヤー値がカスタマイズ・クラス(adf-config.xmlファイルにリストされている)で定義されていない場合、これらは「カスタマイズ・コンテキスト」ウィンドウに表示されません。

したがって、CustomizationLayerValues.xmlファイルにすべてのカスタマイズ・プロジェクトの包括的なレイヤー値リストを含めて、現在のアプリケーションに適したもののみを「カスタマイズ・コンテキスト」ウィンドウに表示できます。逆に、アプリケーションの包括的なカスタマイズ・クラスのリストをadf-config.xmlファイルに含めて、作業するレイヤー値のサブセットのみをCustomizationLayerValues.xmlファイルに含めることもできます。

注意:

デザインタイムには、JDeveloperはCustomizationLayerValues.xmlファイルからカスタマイズ・レイヤー値を取得します。しかし、実行時には、レイヤー値はカスタマイズ・クラスから取得されます。

CustomizationLayerValues.xmlファイルに入力するレイヤー名およびレイヤー値は、カスタマイズ・クラスで指定されたものと一致する必要があります。次の例は、サンプルのCustomizationLayerValues.xmlファイルの内容を示しています。

<cust-layers  xmlns="http://xmlns.oracle.com/mds/dt">
<cust-layer name="industry" id-prefix="i">
<cust-layer-value value="financial" display-name="Financial" id-prefix="f"/>
<cust-layer-value value="healthcare" display-name="Healthcare" id-prefix="h"/>
</cust-layer>
<cust-layer name="site" id-prefix="s">
<cust-layer-value value="headquarters" display-name="HQ" id-prefix="hq"/>
<cust-layer-value value="remoteoffices" display-name="Remote" id-prefix="rm"/>
</cust-layer>
</cust-layers>

各レイヤーとレイヤー値に、id-prefixトークンを追加できます。これにより、idの一意性を確保し、カスタマイズを正確に適用できます。カスタマイズ中に新規要素(コマンド・ボタンなど)をページに追加すると、(選択したヒント・レイヤーで決定された)レイヤーとレイヤー値のid-prefixが要素の自動生成識別子に追加され、カスタマイズ・メタデータ・ファイルで新たに追加された要素のidが作成されます。前述の例では、siteレイヤーにsというid-prefixが付けられ、headquartersレイヤー値にhqというid-prefixが付けられています。したがって、ヒント・レイヤーとしてsite/headquartersを選択して、コマンド・ボタンをページに追加すると、メタデータ・カスタマイズ・ファイルでコマンド・ボタンにshqcb1というidが設定されます。

各レイヤー値にdisplay-nameトークンを追加して、レイヤー値に人間が判読可能な名前を指定することもできます。「カスタマイズ開発者」ロールで作業する際、そのレイヤー値のdisplay-nameトークンの値が「カスタマイズ・コンテキスト」ウィンドウに表示されます。

レイヤーごとに、カスタマイズ・レイヤーに対する値セットのサイズを定義するvalue-set-sizeトークンを、オプションで設定できます。これは、たとえば、設計時にアプリケーション固有のCustomizationLayerValues.xmlファイルを使用する場合などに役立ちます。value-set-sizeを"no_values"に設定することで、設計時に実行時のみのレイヤーを除外できます。

<cust-layer name="runtime_only_layer" value-set-size="no_values"/>

カスタマイズ・レイヤー値はJDeveloper用にグローバルにまたはアプリケーション固有ファイルで定義できます。アプリケーション固有ファイルを使用する場合、このファイルはグローバル・ファイルより優先されます。JDeveloperのレイヤー値をグローバルに構成する方法の詳細は、「レイヤー値をグローバルに構成」を参照してください。アプリケーション固有のレイヤー値を構成する方法の詳細は、「Studio開発者ロールでのワークスペースレベルのレイヤー値の構成」を参照してください。

51.3.4.1 レイヤー値をグローバルに構成

JDeveloper用にCustomizationLayerValues.xmlファイルをグローバルに構成する手順は、次のとおりです。

始める前に:

レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、「カスタマイズ・レイヤーの構成方法」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。

- 「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。

JDeveloper用にデザインタイム・カスタマイズ・レイヤー値をグローバルに構成するには:

1. CustomizationLayerValues.xmlファイルを探して開きます。

このファイルは、JDeveloperインストール・ディレクトリのjdevサブディレクトリにあります(jdev_install\jdev\CustomizationLayerValues.xml)。

2. 「カスタマイズ・レイヤーの構成方法」の説明に従って、レイヤーごとにcust-layer要素を入力します。

3. 「カスタマイズ・レイヤーの構成方法」の説明に従って、レイヤー値ごとにcust-layer-value要素を入力します。

4. CustomizationLayerValues.xml ファイルを保存して閉じます。

5. グローバルなCustomizationLayerValues.xmlファイルに変更を加えた後は、JDeveloperを再起動する必要があります。

51.3.4.2 Studio開発者ロールでのワークスペースレベルのレイヤー値の構成

アプリケーションのレイヤー値を構成する場合Studio開発者ロールまたは「カスタマイズ開発者」ロールのいずれかを使用できます。アプリケーション固有のCustomizationLayerValues.xmlファイルを構成する場合、レイヤー値を作成および変更できますが、追加のカスタマイズ・レイヤーを作成できません。アプリケーション固有のレイヤー値に対して行った変更を適用するためにJDeveloperを再起動する必要はありません。

アプリケーション固有のCustomizationLayerValues.xmlファイルを作成すると、JDeveloperはこのファイルをアプリケーションレベルのディレクトリに格納します(workspace-directory\.mds\dt\customizationLayerValues\CustomizationLayerValues.xmlなど)。このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルのMDS DTノードの下にあります。

次に、Studio開発者ロールで特定アプリケーションのCustomizationLayerValues.xmlファイルを構成する手順について説明します。この手順は、「カスタマイズ開発者」ロールでも使用できます。

始める前に:

レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、「カスタマイズ・レイヤーの構成方法」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。

- 「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。

- Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。

Studio開発者ロールからワークスペース・レベルでデザインタイム・カスタマイズ・レイヤー値を構成するには:

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開いて、「adf-config.xml」をダブルクリックします。

2. 概要エディタで、「MDS構成」ナビゲーション・タブをクリックします。

3. カスタマイズ・クラスの表の下の「MDS構成」ページで、「デザインタイム・カスタマイズ・レイヤー値の構成」リンクをクリックして、ワークスペースレベルのCustomizationLayerValues.xmlファイルを開きます。

リンクをクリックすると、ソース・エディタでファイルが開きます。オーバーライド・ファイルがまだ存在しない場合、JDeveloperは、確認ダイアログを表示します。「はい」をクリックして、グローバル・ファイルのコピーを作成して開きます。

4. このファイルで、「カスタマイズ・レイヤーの構成方法」の説明に従って、必要なレイヤー値を指定します。

5. 変更を保存します。

51.3.4.3 「カスタマイズ開発者」ロールでのワークスペースレベルのレイヤー値の構成

「カスタマイズ開発者」ロールでアプリケーションのレイヤー値を構成することもできます。アプリケーション固有のCustomizationLayerValues.xmlファイルを構成する場合、レイヤー値を作成および変更できますが、追加のカスタマイズ・レイヤーを作成できません。アプリケーション固有のレイヤー値に対して行った変更を適用するためにJDeveloperを再起動する必要はありません。

アプリケーション固有のCustomizationLayerValues.xmlファイルを作成すると、JDeveloperはこのファイルをアプリケーションレベルのディレクトリに格納します(workspace-directory\.mds\dt\customizationLayerValues\CustomizationLayerValues.xmlなど)。このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルのMDS DTノードの下にあります。

次に、「カスタマイズ開発者」ロールで特定アプリケーションのCustomizationLayerValues.xmlファイルを構成する手順について説明します。

始める前に:

レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、「カスタマイズ・レイヤーの構成方法」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。

- 「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。

- 「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。

「カスタマイズ開発者」ロールからワークスペース・レベルでデザインタイム・カスタマイズ・レイヤー値を構成するには:

1. 「カスタマイズ・コンテキスト」ウィンドウで、「アプリケーション・レイヤー値の構成」リンクをクリックします。

リンクをクリックすると、ソース・エディタでCustomizationLayerValues.xmlファイルが開きます。オーバーライド・ファイルがまだ存在しない場合、JDeveloperは、確認ダイアログを表示します。「はい」をクリックして、グローバル・ファイルのコピーを作成して開きます。

2. 「カスタマイズ・レイヤーの構成方法」の説明に従って、必要なレイヤー値を指定します。

3. 変更を保存します。

「カスタマイズ開発者」ロールの間にアプリケーション固有のCustomizationLayerValues.xmlファイルに対して変更を行った後、「カスタマイズ・コンテキスト」ウィンドウで選択したヒント・レイヤーが選択解除されます。必要なヒント・レイヤーを選択できます。

51.3.5 JDeveloperでメタデータをカスタマイズする方法

ベース・アプリケーションの開発時と同じ開発手順および開発手法を使用して、メタデータをカスタマイズします。ただし、カスタマイズを実装するには、メタデータを編集する前に、「カスタマイズ開発者」ロールを使用し、ヒント・レイヤーとレイヤー値を選択してカスタマイズ・コンテキストを指定する必要があります。カスタマイズ可能にできるアプリケーションに対して、プロジェクトでカスタマイズを有効にする必要があります。詳細は、「カスタマイズ可能なアプリケーションの開発」を参照してください。

始める前に:

カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」および「アプリケーションのカスタマイズ」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。

- 「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。

- 「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。

- 「adf-config.xmlファイルの構成方法」の説明に従って、adf-config.xmlファイルを更新します。

- 「ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法」および「既存のページでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションでシード・カスタマイズを有効化します。

- 「カスタマイズ・レイヤーの構成方法」の説明に従って、アプリケーション・カスタマイズ・レイヤーを構成します。

- 「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。

JDeveloperでメタデータをカスタマイズするには:

1. 「カスタマイズ・コンテキスト」ウィンドウで、カスタマイズを実装するレイヤーと値を選択します。

図51-4に示すように、(「カスタマイズ・コンテキスト」ウィンドウの下部に表示される)「カスタマイズ・コンテキスト」が選択内容を反映して変更されます。

図51-4 site/headquartersがヒント・レイヤーとして選択された「カスタマイズ・コンテキスト」ウィンドウ

注意:

「カスタマイズ・コンテキスト」ウィンドウで選択された内容は、JDeveloperに実装するカスタマイズのコンテキストを示します。この選択内容が、アプリケーションの実行時に直接影響を及ぼすことはありません。実行時には、カスタマイズ・クラスからカスタマイズ・コンテキストが戻されます。詳細は、「カスタマイズ・クラスの作成方法」を参照してください。

2. 開発時に通常行うように、メタデータを編集します。たとえば、エンティティ・オブジェクトをダブルクリックします。その後、概要エディタを使用してオブジェクトを編集します。

カスタマイズ時には、開発時と同じ方法でメタデータを編集しますが、一定の制約が適用されます。たとえば、ボタン・ラベルなど一部の文字列プロパティは、「プロパティ」ウィンドウで直接編集できません。「テキスト・リソースの選択」ダイアログまたは式ビルダーを使用して編集する必要があります。カスタマイズ時に編集を制限する方法の詳細は、「「カスタマイズ開発者」ロールの概要」を参照してください。式ビルダーを使用する方法の詳細は、「「プロパティ」ウィンドウから式ビルダーを開く手順」を参照してください。

概要エディタを使用してカスタマイズを実装する場合でも、ベース・メタデータ・ファイルは変更しません。変更内容は、カスタマイズ・メタデータ・ファイルに別個に保存されます。

注意:

カスタマイズされていないベース・メタデータを表示するには、「カスタマイズ・コンテキスト」ウィンドウで「カスタマイズなしで表示」を選択します。

3. オプションで、(「プロパティ」ウィンドウで)プロパティのドロップダウン・メニューから「カスタマイズの削除」を選択して、既存のカスタマイズを消去できます。

注意:

「プロパティ」ウィンドウでは、ヒント・レイヤーのカスタマイズはオレンジのアイコンで示され、現在のヒント・レイヤーでカスタマイズされないプロパティは緑のアイコンで示されます。カスタマイズは、これを追加したコンテキストでのみ削除できます。つまり、「プロパティ」ウィンドウでは、オレンジのインジケータの付いたカスタマイズのみを削除できます。

4. メイン・メニューで、「ファイル」→「保存」を選択して、変更を保存します。

カスタマイズの完了後、カスタマイズしたアプリケーションを実行してテストできます。

51.3.6 アプリケーションのカスタマイズ時の処理内容

アプリケーションでカスタマイズを実装する場合、JDeveloperによりカスタマイズ用のメタデータ・ファイルとこれらを格納するサブパッケージが作成されます。

メタデータ・ファイルにはカスタマイズしたオブジェクトのカスタマイズが含まれ、これらは実行時にベース・メタデータに適用されます。新しいメタデータ・ファイルには、オブジェクトのベース・ファイルと同じ名前が付けられ、拡張子.xmlが付加されます。たとえば、browseOrders.jsffページのカスタマイズを実装する場合、カスタマイズ・メタデータ・ファイルの名前はbrowseOrders.jsff.xmlになります。また、OrderItemsエンティティ・オブジェクトにカスタマイズを実装する場合は、ベース・メタデータ・ファイルの名前はOrderItems.xmlになり、カスタマイズ・メタデータ・ファイルの名前はOrderItems.xml.xmlになります。

カスタマイズ・メタデータ・ファイルは、カスタマイズするオブジェクトと同じレベルで作成されたサブパッケージ階層に格納されます。第1レベルのパッケージ名はmdssysで、custという名前のパッケージが含まれます。custパッケージには、カスタマイズを実装した各カスタマイズ・レイヤーのパッケージが含まれます。

たとえば、エンティティ・オブジェクトを含むoracle.summit.model.entitiesというパッケージを持つベース・アプリケーションがあり、headquartersとremoteofficesの2つのレイヤー値を持つsiteという名前のカスタマイズ・レイヤーがあるとします。その後、headquartersレイヤー値でOrderItemsエンティティ・オブジェクトにカスタマイズを実装します。これらのカスタマイズを実装する場合、JDeveloperによりサブパッケージ階層oracle.summit.model.entities.mdssys.cust.site.headquartersが作成され、ここにカスタマイズ・メタデータ・ファイルが格納されます。

同様にユーザー・インタフェース・プロジェクトのページ用に、ディレクトリ構造が作成されてカスタマイズ・メタデータ・ファイルが格納されます。たとえば、ユーザー・インタフェース・プロジェクトの「Webコンテンツ」ノードのBrowseOrders.jsffページをカスタマイズする場合、JDeveloperにより「Webコンテンツ」の下にディレクトリ構造mdssys/cust/site/headquartersが作成され、ここにカスタマイズ・メタデータ・ファイルが格納されます。

51.3.7 JDeveloperでADFライブラリ・アーティファクトをカスタマイズする方法

「カスタマイズ開発者」ロールでは、JDeveloperを使用してADFライブラリのアーティファクトをカスタマイズできます。これが必要になるのは、たとえば、ある開発チームがフレームワーク・サービスの一部としてタスク・フローを作成し、これを他のチームがADFライブラリとして使用できるようにする場合です。その後、他の開発チームがいずれかのタスク・フローを使用アプリケーションで使用して、アプリケーションの要件にあわせて調整する必要が生じます。

51.3.7.1 ADFライブラリ・アーティファクトのカスタマイズ

ADFライブラリのプロジェクトへの追加は、Studio開発者ロールで実行するのと同様に「カスタマイズ開発者」ロールで実行できます。ただし、 「カスタマイズ開発者」ロールでは、ADFライブラリのコンテンツは編集可能でカスタマイズを実装できるのに対し、Studio開発者ロールでは読取り専用になります。ADFライブラリの使用の詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

始める前に:

カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」および「アプリケーションのカスタマイズ」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。

- 「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。

- 「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。

- 「adf-config.xmlファイルの構成方法」の説明に従って、adf-config.xmlファイルを更新します。

- 「ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法」および「既存のページでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションでシード・カスタマイズを有効化します。

- 「カスタマイズ・レイヤーの構成方法」の説明に従って、アプリケーション・カスタマイズ・レイヤーを構成します。

- 「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。

ADFライブラリ・アーティファクトをカスタマイズするには:

1. 「アプリケーション」ウィンドウで、「アプリケーション・ウィンドウのオプション」アイコンをクリックして、「ライブラリの表示」を選択します。

これにより「アプリケーション」ウィンドウにライブラリが表示されるので、いろいろ見てまわってアーティファクトにアクセスできます。

2. 「アプリケーション」ウィンドウのライブラリに希望するライブラリがない場合は、希望するライブラリをプロジェクトに追加します。

この手順の詳細は、「プロジェクトへのADFライブラリ・コンポーネントの追加」を参照してください。

3. プロジェクトの他のコンテンツをカスタマイズするのと同じように、アーティファクトをカスタマイズします。

たとえば、タスクフローのライブラリから使用プロジェクトの.jspxまたは.jsffページへのドラッグ・アンド・ドロップ、タスクフローのライブラリから他のライブラリのページまたはフラグメントへのドラッグ・アンド・ドロップ、ライブラリ・コンテンツまたはタスクフローのリソース・カタログからのドラッグ・アンド・ドロップ、データ・コントロールの「データ・コントロール」パネルからライブラリの.jspxまたは.jsffページへのドラッグ・アンド・ドロップ、ビジネス・コンポーネントの編集、データ・コントロールのライブラリから「データ・コントロール」パネルへのドラッグ・アンド・ドロップおよび他のパレットのページへのドロップなどを行うことができます。これらのアクションすべてが、ライブラリのカスタマイズになります。

51.3.7.2 ADFライブラリのカスタマイズの場所の指定

ADFライブラリのカスタマイズが保存される場所は、デフォルトではproject-dir\libraryCustomizationsです。ワークスペースに複数のプロジェクトが含まれる場合、この場所を各プロジェクトのワークスペースレベルの場所に変更する必要があります(workspace-dir\.mds\ADFLibraryCustomizationsなど)。

ADFライブラリのカスタマイズの場所は、「プロジェクト・プロパティ」ダイアログの「プロジェクトのソースパス」→「ADFライブラリのカスタマイズ」ページで変更できます。ADFライブラリでカスタマイズを実装後にこの場所を変更する場合は、カスタマイズ・メタデータ・ファイルを新しい場所に移動する必要があります。そのためには、ファイル・システムを使用してカスタマイズ・メタデータ(XML)ファイルを古いディレクトリから新しいディレクトリに移動します。

ワークスペースに、共通の場所に移動する必要がある既存のADFライブラリのカスタマイズを持つプロジェクトが複数存在する場合は、一度に1つのプロジェクトずつカスタマイズを新しい場所に移動します。プロジェクトごとに、「プロジェクト・プロパティ」ダイアログでADFライブラリのカスタマイズの場所を変更してから、カスタマイズ・メタデータ・ファイルを古い場所から新しい場所に移動します。複数のプロジェクトでADFライブラリ・アーティファクトにカスタマイズがある場合の競合を緩和するために、次のオプションが用意されています。

- 両方のプロジェクトで、カスタマイズが競合しているADFライブラリ・アーティファクトを開き、どちらが必要なカスタマイズかを決定します。保持するカスタマイズを残して、もう一方は削除します。

- 両方のカスタマイズが重要である場合は、最初のプロジェクトでADFライブラリ・アーティファクトを開き、前に2つめのプロジェクトで行われたカスタマイズを実装します。その後、最初のプロジェクトでカスタマイズを保存して、2つめのプロジェクトからカスタマイズを削除します。

複数のプロジェクトのADFライブラリ・カスタマイズ・メタデータ・ファイルをテキスト・エディタで開いて、そのコンテンツをマージすることはできません。これを行うと、カスタマイズ・メタデータ・ファイルが破損する可能性があります。

また、MARデプロイメント・プロファイルを作成すると、ADFライブラリのカスタマイズが保存されている場所が自動的に含められます。また、MARプロファイルの作成後にこの場所を変更する場合は、パッケージ化する前に、「MARデプロイメント・プロファイルのプロパティの編集」ダイアログの「ユーザー・メタデータ」ファイル・グループ・ページにあるコントリビュータ・リストで、対応するエントリを変更する必要があります。または、MARプロファイルを再作成して、この変更を取得することも可能です。MARデプロイメント・プロファイルの作成の詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。

51.3.8 エクスポートしたJARからのADFライブラリ・ランタイム・カスタマイズの表示方法

JDeveloperの「カスタマイズ開発者」ロールで作業している場合、エクスポートしたJARに含まれるADFライブラリ・アーティファクトに実装されたランタイム・カスタマイズを表示できます。

始める前に:

カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」および「アプリケーションのカスタマイズ」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ可能なアプリケーションの開発」の説明に従って、カスタマイズ可能なアプリケーションを作成します。

- アプリケーションをデプロイし、ランタイム・カスタマイズをこれに実装し、ランタイム・カスタマイズをJARファイルにエクスポートします。詳細は、『Oracle WebCenter Portalの管理』を参照してください。

- 「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズ可能なアプリケーションを開きます。

ランタイム・カスタマイズをJDeveloperで表示できるようにするには:

1. 「アプリケーション」ウィンドウのポップアップ・メニューで、「アプリケーション・プロパティ」を選択します。

2. 「アプリケーション・プロパティ」ダイアログで「カスタマイズ・ライブラリ」を選択します。

3. 「参照」をクリックして、エクスポートしたJARファイルの場所に移動します。

4. JARファイルを選択して「選択」をクリックします。

5. 「OK」をクリックします。

これで、JARが使用可能になり、JDeveloperはADFライブラリ・アーティファクトのカスタマイズを検索できます。ADFライブラリ・アーティファクトを含むオブジェクトを開くと、JDeveloperはこのJARファイルでカスタマイズを検索し、必要に応じて表示します。JDeveloperは特定のカスタマイズ・コンテキストで特定のアーティファクトについて表示する内容を、次のように決定します。

- アーティファクトにランタイム・カスタマイズもシード・カスタマイズも関連付けられていない場合、ADFライブラリのアーティファクトが表示されます。

- アーティファクトにランタイム・カスタマイズまたはシード・カスタマイズのいずれかのみが関連付けられている場合、カスタマイズされたアーティファクトが表示されます。

- アーティファクトにランタイム・カスタマイズとシード・カスタマイズの両方が関連付けられている場合、シード・カスタマイズが優先されて表示されます。

また、アプリケーションをJDeveloperからローカルに実行する場合は、ランタイム・カスタマイズが表示されます。ただし、ランタイム・カスタマイズはアプリケーションのデプロイメント用のパッケージには含められません。

51.3.9 ADFライブラリ・アーティファクトのカスタマイズ時の処理内容

エンタープライズ・アプリケーションを開発する際、複数のアプリケーションで再利用可能なアーティファクト(タスク・フローなど)が存在することがあります。再利用しやすいように、これらの共通アーティファクトをADFライブラリにパッケージ化して配布できます。これにより、使用アプリケーションが依存するライブラリ・リストにADFライブラリを追加できます。アプリケーションがパッケージ化されると、追加したすべてのADFライブラリのカスタマイズがMARに含められ、その後、MDSリポジトリにデプロイされます。ただし、そのADFライブラリのカスタマイズは、プロファイルの作成時にMARデプロイメント・プロファイルに追加されており、これは、プロファイルの作成後にカスタマイズを実装する際には自動更新されません。こうした後続のカスタマイズを適用するには、「MARデプロイメント・プロファイルのプロパティの編集」ダイアログの「MARオプション」ページにある「プロファイルの更新」ボタンを使用します。

注意:

ADFライブラリ・プロバイダは、ライブラリのカスタマイズを原因とする名前の競合がないことを確認する必要があります。ADFライブラリにパッケージ化されたカスタマイズと使用プロジェクトのカスタマイズとの間で名前の競合が発生した場合、ADFライブラリのカスタマイズは無視されます。

ADFライブラリのオブジェクトにカスタマイズを実装すると、デフォルトでは、カスタマイズ・メタデータはlibraryCustomizationsというプロジェクトのサブディレクトリに格納されます。また、プロジェクト・レベルでADFライブラリのカスタマイズを作成しても、これらは実行時にアプリケーションで使用できるように、パッケージ化される際に一緒にマージされます。基本的に、ADFライブラリはプロジェクト・レベルで追加されるJARであり、プロジェクト・レベルで作成されるライブラリ・カスタマイズにマップされます。ただし、プロジェクトは実行時にWebアプリケーションにマップされますが、MAR(ライブラリのカスタマイズを含む)はEARレベルにあるため、すべてのWebアプリケーションからライブラリのカスタマイズを確認できます。

したがって、ある特定のカスタマイズ・コンテキスト(カスタマイズ・レイヤーおよびレイヤー値)では、アプリケーションの1箇所でしかADFライブラリ・アーティファクトをカスタマイズできません。同一ライブラリ・コンテンツをカスタマイズ・コンテキストが同一の複数のプロジェクトでカスタマイズすると、MARパッケージで重複が発生します。パッケージ化の失敗の原因となる重複を回避するには、アプリケーションの1つのプロジェクトにのみ特定ライブラリのカスタマイズを実装します。

注意:

アプリケーション内のすべてのプロジェクトに対して、ADFライブラリのカスタマイズに同じ場所を使用することで、重複カスタマイズを防止できます。詳細は、「ADFライブラリのカスタマイズの場所の指定」を参照してください。

たとえば、使用中のADFライブラリにページ・フラグメントtext.jsffが含まれるとします。使用アプリケーションで、このライブラリ・ページを1つのプロジェクトでのみカスタマイズします。これにより、実行時にこのライブラリを使用するアプリケーションのすべてのプロジェクトで、カスタマイズが使用可能になります。

プロジェクトに同じ名前のオブジェクトがすでに含まれる場合、ADFライブラリのオブジェクトをカスタマイズすることも制限されます。重複する場合は、重複するドキュメントの1つを削除するか、削除してから差異をもう一方に手動でマージして、プロジェクトを修正する必要があります。

同様に、ADFライブラリに特定のカスタマイズ・コンテキスト(カスタマイズ・レイヤーとレイヤー値)のアーティファクトのシード・カスタマイズが含まれる場合、同じカスタマイズ・コンテキストでそのアーティファクトにカスタマイズを実装することはできません。この場合、ADFライブラリ・アーティファクトは読取り専用になります。ただし、他のカスタマイズ・コンテキストでアーティファクトにカスタマイズを実装することはできます。

たとえば、使用中のADFライブラリに、SiteレイヤーのHeadquartersレイヤー値のシード・カスタマイズが含まれるとします。「カスタマイズ・コンテキスト」ウィンドウでこれをヒント・レイヤーとして選択すると、そのADFライブラリのカスタマイズ済オブジェクトは読取り専用になります。ただし、Site/Remote Site 1をヒント・レイヤーとして選択すると、オブジェクトはカスタマイズ可能になります。

注意:

使用アプリケーションでADFライブラリのコンテンツに対するカスタマイズが実装されると、カスタマイズはローカル・プロジェクトのディレクトリには書き込まれますが、パッケージ化する際にweb-app-rootで自動的に挿入されることはありません。詳細は、「MARデプロイメント・プロファイルの作成」を参照してください。

51.3.10 実行時の処理: カスタマイズの適用方法

実行時に、アプリケーションではadf-config.xmlファイルのcust-configセクションで定義された優先順位に従って、カスタマイズ・メタデータ・ファイルがベース・アプリケーション全体に適用されます。

レイヤー値は実行時にカスタマイズ・クラスから取得され、アプリケーションが実行されているコンテキストで評価されて、そのレイヤー値に適したカスタマイズが適用されます。

51.3.11 カスタマイズしたアプリケーションに関する必知事項

アプリケーションをカスタマイズする場合、統合ソース・コントロールを使用したり、リソース文字列をカスタマイズすることがあります。これらの機能を使用する場合に、知っておくべき追加情報があります。

51.3.11.1 カスタマイズおよび統合ソース・コントロール

「カスタマイズ開発者」ロールでの作業時には、ソース・コントロール統合によってカスタマイズ・プロセスが補完されます。自動的にチェックアウトして新規ファイルをソース・コントロールに追加するようにJDeveloperが構成されている場合、ソース・コントロール・システムから使用可能なベース・ドキュメントをカスタマイズしようとすると、JDeveloperは次のように動作します。

- 該当するカスタマイズ・ファイルがまだ使用可能でない場合、ソース・コントロールで新しいカスタマイズ・ファイルが作成されてカスタマイズが書き込まれます。

- 該当するカスタマイズ・ファイルが存在する場合、チェックアウトされてカスタマイズが書き込まれます。

- 該当するカスタマイズ・ファイルが存在し、すでにチェックアウトされている場合、またはまだバージョン・コントロールにない場合、バージョン・コントロール操作なしでカスタマイズが書き込まれます。

ベース・ドキュメントは「カスタマイズ開発者」ロールでは変更されないため、ベース・ドキュメントはチェックアウトされません。

自動的にチェックアウトしたり新規ファイルをソース・コントロールに追加するようにJDeveloperが構成されていない場合、手動でカスタマイズ・ファイルを編集可能にして、新たに作成したカスタマイズ・ファイルをソース・コントロールにチェックインする必要があります。JDeveloperでのソース・コントロールの使用の詳細は、「ソース・コントロール・システムの使用」の項を参照してください。

51.3.11.2 カスタマイズしたアプリケーションでのリソース・バンドルの編集

アプリケーションをカスタマイズする過程で、コンテンツをカスタマイズして、別のリソース・バンドル・キーを使用したり、新しいリソース・キーを定義して使用できます。

「カスタマイズ開発者」ロールでカスタマイズ可能なアプリケーションを開き、「プロパティ」ウィンドウを使用してリソース・バンドル文字列の使用方法をカスタマイズできます。ドキュメントを変更して、リソース・バンドルにすでに存在する別のリソース・キーを使用したり、新しいリソースを作成できます。リソース・バンドルの詳細は、「リソース・バンドルの使用」を参照してください。

新しいリソース・キー(「カスタマイズ開発者」ロールで作成された)は、アプリケーション・レベルのオーバーライド・バンドルに(XLIFF形式で)保存され、JDeveloperにより次の例に示すようなエントリがadf-config.xmlファイルに追加されて、アプリケーション・レベルのオーバーライド・バンドルが構成されます。

また、ベース・リソース・バンドルのオーバーライドをサポートするように、adf-config.xmlファイルを構成する必要があります。次の例に示すように、bundleId要素をoverride="true"とともにタグ付けしてオーバーライド可能にする必要があります。オーバーライド可能に指定すると、そのバンドルのカスタマイズはアプリケーションのオーバーライド・バンドルに格納されます。

<adf-resourcebundle-config xmlns="http://xmlns.oracle.com/adf/resourcebundle/config">
<applicationBundleName>
path-to-resource-bundle/bundle-name
</applicationBundleName>
<bundleList>
<bundleId override="true">
package.BundleID
</bundleId>
</bundleList>
</adf-resourcebundle-config>

注意:

アプリケーションがカスタマイズ用に構成されていない場合、「カスタマイズ開発者」ロールでアプリケーションを開き、メイン・メニューから「アプリケーション」→「リソース・バンドルの編集」を選択して新しいリソース・キーを定義できます。ただし、カスタマイズ用に構成されていない場合、ドキュメントを変更して新しいリソース・キーを使用することはできません。

51.4 カスタマイズしたアプリケーションをパッケージ化してデプロイする方法

アプリケーションをカスタマイズしたら、そのアプリケーションをデプロイできます。カスタマイズしたアプリケーションをデプロイする前に、『Oracle Fusion Middlewareの管理』の説明に従って、MDSリポジトリを設定するための構成手順を実行する必要があります。

エンタープライズ・アプリケーションにはモデル・プロジェクトおよびユーザー・インタフェース・プロジェクトを含めることができ、どちらのタイプのプロジェクトにもカスタマイズしたメタデータを含めることができます。カスタマイズしたメタデータは、デプロイのためにMARにパッケージ化されます。デフォルトでは、どちらのタイプのプロジェクトのカスタマイズも1つのMARに追加されます。MARプロファイルの作成方法の詳細は、「MARデプロイメント・プロファイルの作成」を参照してください。

51.4.1 MARプロファイルの暗黙的作成

JDeveloperを使用してFusion Webアプリケーションをパッケージ化する場合、次のいずれかの条件が満たされると、デフォルト・メタデータ(カスタマイズなど)を含む自動生成MARプロファイルが作成されます。

- ユーザー・インタフェース・プロジェクトの「プロジェクト・プロパティ」ダイアログの「ADFビュー設定」ページで、「ユーザー・カスタマイズの有効化」→「MDSを使用したセッション間チェック・ボックスが選択されている。

- adf-config.xmlファイルのMDS構成セクションに、次の例に示すようにdeploy-target="true"とマークされている<metadata-store-usage>要素が含まれる。

< . . . >
<persistence-config>
<metadata-namespaces>
<namespace path="/oracle/apps" metadata-store-usage="repos1"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="repos1" deploy-target="true">
. . .
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
< . . . >

51.4.2 MARプロファイルの明示的作成

JDeveloperで作成されたカスタマイズをデプロイ時にアプリケーションで有効にするには、これらのカスタマイズを実行時にアプリケーションで使用可能にする必要があります。そのために、2つの方法を使用できます。

- MARプロファイルを使用して、カスタマイズをアプリケーションとともにパッケージ化します。
カスタマイズ・メタデータを含むMARプロファイルを作成します。デプロイしたEARファイルにMARプロファイルを含めて、実行時にカスタマイズを使用できるようにします。アプリケーションレベル・クラス・ローダーに配置されるように、カスタマイズ・クラスをEARファイルにパッケージ化する必要があります。

注意:

シード・カスタマイズしかない場合は、ランタイム・カスタマイズもサポートする場合を除き、MARプロファイルを作成してMDSリポジトリにインポートする必要はありません。シード・カスタマイズがあり、セッション間の永続性が有効でない場合、シード・カスタマイズはデフォルトでEARファイルにパッケージ化され、クラス・パスからロードされます。

- カスタマイズを、アプリケーションで使用されるランタイム・リポジトリにインポートします。
この方法は一般に、ライブラリ・メタデータへのカスタマイズを、別個にデプロイされたアプリケーションに適用する必要がある場合に使用します。この方法を使用してカスタマイズをJARファイルにパッケージ化し、Oracle WebLogic Scripting Tool (WLST)とともにimportMetadataコマンドを使用してMDSランタイム・リポジトリにインポートします。このコマンドやその他のWLSTコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』を参照してください。

アプリケーションにADFライブラリのオブジェクトのカスタマイズがある場合、MARプロファイルの作成時にカスタマイズ・メタデータが暗黙的に含められます。「プロジェクト・プロパティ」ダイアログでADFライブラリのカスタマイズの場所を変更する場合は、パッケージ化する前に、MARプロファイルを再作成する必要があります。

実行時のデザインタイム機能を使用して、実行時にオーバーライド・バンドルでリソース・キーを追加または編集する予定がある場合は、オーバーライド・バンドルをMARプロファイルの一部としてパッケージ化する必要があります。デフォルトでは、アプリケーションにシード・カスタマイズが含まれる場合、オーバーライド・バンドルは自動生成MARプロファイルの一部としてパッケージ化されます。ただし、アプリケーションにシード・カスタマイズが含まれない場合は、MARデプロイメント・プロファイルを明示的に作成してオーバーライド・バンドルをパッケージ化する必要があります。MARプロファイルが明示的に作成される場合、オーバーライド・バンドルはデフォルトでユーザー・メタデータの一部として追加されて含められます。

完了したカスタマイズ済アプリケーションをパッケージ化してデプロイする場合、 「カスタマイズ開発者」ロールではなくStudio開発者ロールで行う必要があります。MARプロファイルの作成方法の詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。

51.5 拡張メタデータ・プロパティ

拡張メタデータは、メタデータのコンテンツを説明するデータです。拡張メタデータ・ファイルには、メタデータ・ファイルについての追加情報が含まれます。この拡張情報を使用する目的の1つは、実行時にメタデータのどの部分をカスタマイズできるか(実行時のデザインタイムのカスタマイズ)および誰がカスタマイズできるか識別することです。拡張メタデータ・プロパティのこの用法の詳細は、「実行時のデザインタイムのカスタマイズを有効化する方法」を参照してください。

メタデータ・ファイル(.jspxファイルなど)をJDeveloperで開き、「プロパティ」ウィンドウを使用して拡張メタデータ・プロパティを表示および編集できます。メタデータ・ファイルを開くと、「プロパティ」ウィンドウに拡張メタデータ・プロパティが表示されます。これらのプロパティを編集して、次のいずれかのレベルでメタデータ情報を追加できます。

- ファイルレベル: 構造ウィンドウでルート要素が選択されている場合、「プロパティ」ウィンドウにこれらのプロパティが表示されます。

- 要素レベル: 構造ウィンドウで要素が選択されている場合、「プロパティ」ウィンドウにこれらのプロパティが表示されます。選択した要素は、null以外の識別子を持つ必要があります。

拡張メタデータ・プロパティは、カスタマイズをサポートし、MARにパッケージ化できるファイル・タイプ(.jsffファイルや.jspxファイルなど)に対してサポートされます。

メタデータ・ドキュメントの拡張メタデータは、関連するリソース記述フレームワーク(RDF)ファイルに格納されます。RDFは、メタデータを定義するXMLフレームワークの定義に使用されるW3C標準です。メタデータ・ドキュメントに関連付けられるRDFファイルは、「プロパティ」ウィンドウを使用して最初のプロパティ値を指定するときに作成されます。JDeveloperがStudio開発者ロールの場合にのみ、拡張メタデータ・プロパティは編集できます。「カスタマイズ開発者」ロールでは、RDFファイルは読取り専用です。

RDFファイルは、mdssysディレクトリに格納されます。たとえば、記述されるメタデータが/myapp/data/page1.jspxとしてファイル・システムに格納される場合、対応する拡張メタデータ・ドキュメントは/myapp/data/mdssys/mdx/page1.jspx.rdfとして格納されます。その後、拡張メタデータ・ドキュメントを対応するメタデータ・ベース・ファイルとともにパッケージ化して、同じデプロイメント・プロファイルに追加する必要があります。MARデプロイメント・プロファイルの作成の詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。

注意:

拡張メタデータ・ドキュメントを直接編集することはできません。「プロパティ」ウィンドウを使用してください。

51.5.1 拡張メタデータ・プロパティを編集する方法

拡張メタデータ・プロパティを使用して、メタデータ・ファイル(.jspxファイルなど)に含まれていない追加のメタデータ情報を提供できます。JDeveloperでメタデータ・ファイルを開くと、「プロパティ」ウィンドウに拡張メタデータ・プロパティが表示されます。JDeveloperをStudio開発者ロールで使用している場合は、プロパティ・インスペクタを使用してこれらのプロパティを編集できます。

たとえば、なんらかのフォームのメタデータ・ファイルを外部の顧客に配信するとします。メタデータ・ファイルとともに、作成者、題目、内容、形式、権利などファイルに関する追加情報を提供する必要があります。メタデータ・ファイルの拡張メタデータ・プロパティ・ファイルを作成することで、これらの情報を提供できます。

始める前に:

拡張メタデータの使用方法に関する知識が役立つ場合があります。詳細は、「拡張メタデータ・プロパティ」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクを完了する必要もあります。

- Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開きます。

拡張メタデータ・プロパティを編集するには:

1. 「アプリケーション」ウィンドウで、拡張メタデータ・プロパティを編集するオブジェクトを選択します。

2. 構造ウィンドウで、適切な要素(通常はルート要素)を選択します。

3. 「プロパティ」ウィンドウで、適切なノードを開き、プロパティを編集します。

「プロパティ」ウィンドウに選択したコンポーネントの値を表示するには、メイン・メニューから「ウィンドウ」→「プロパティ」を選択します。

4. 目的のプロパティの値を編集して、[Enter]を押します。

5. メイン・メニューで、「ファイル」→「保存」を選択して、変更を保存します。

メタデータ・ファイルの拡張メタデータ・プロパティを編集した場合は、アプリケーションのデプロイ時に、拡張メタデータ(またはRDF)ファイルをメタデータ・ファイルとともにパッケージ化する必要があります。

51.5.2 実行時のデザインタイムのカスタマイズを有効化する方法

拡張メタデータ・プロパティを使用して、実行時にメタデータのどの部分をカスタマイズできるか、および誰がメタデータのコンテンツをカスタマイズできるかについての情報を提供することもできます。

デフォルトでは、.jspxページに追加できるすべてのコンポーネントは、ランタイム・カスタマイズを許可するように事前構成されており、暗黙的なユーザー・カスタマイズをサポートしています(表の列順の変更など)。

作成するすべてのページおよびフラグメントもデフォルトではカスタマイズできるように構成されます。一部のWebCenter Portalコンポーネント(panelCustomizableなど)でも、タイプ定義のカスタマイズが許可されています。ユーザー・カスタマイズの詳細は、「実行時のユーザー・カスタマイズの許可」を参照してください。WebCenter Portalコンポーネントの詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

カスタマイズできるようにコンポーネントが事前構成されている場合、さらに変更を加えて実行時のデザインタイムのカスタマイズを可能にする必要はありません。このようなコンポーネントを.jspxページで使用する場合、デフォルトでカスタマイズ可能になっています。

アプリケーションの要件に応じて、次の状況でカスタマイズ・プロパティを変更する必要があります。

- カスタマイズを許可するように構成されているコンポーネントの場合、デフォルト設定をオーバーライドしてカスタマイズを禁止できます。

- カスタマイズを許可するように構成されていないコンポーネントおよびメタデータ・オブジェクト(.jspxページなど)の場合、設定をオーバーライドしてカスタマイズを許可できます。

- カスタマイズを許可するように構成されているコンポーネントの場合、オプションで、実行時にカスタマイズを実行できるユーザーを制限することができます。

カスタマイズ・プロパティを編集する場合は、アプリケーションのデプロイ時に、拡張メタデータ(RDF)ファイルをメタデータ・ファイルとともにパッケージ化する必要があります。

また、サブツリーのルートをカスタマイズ禁止にマーキングすることによって、コンポーネントのサブツリー全体のカスタマイズを制限できます。そのサブツリーの個別のコンポーネントにカスタマイズ可能のマークを付けて、その特定のコンポーネントのカスタマイズを許可できます。

51.5.2.1 「プロパティ」ウィンドウでのカスタマイズ・プロパティの編集

「プロパティ」ウィンドウのカスタマイズ・グループには、実行時にオブジェクトをカスタマイズできるかどうか、および誰がカスタマイズを実行できるかを指定する2つのプロパティがあります。任意の要素にCustomizationAllowedプロパティを設定して、カスタマイズできるかどうかを指定できます。CustomizationAllowedByプロパティは、要素をカスタマイズできるユーザーを制御します。JDeveloperを使用してシード・カスタマイズを実装する場合、これらの設定は強制されませんが、実行時にアプリケーションをカスタマイズする場合は強制されます(実行時のデザインタイムのカスタマイズ)。

たとえば、2つのパネルで構成される.jspxページがあり、パネル1のコンテンツにはランタイム・カスタマイズを許可する必要があり、パネル2のコンテンツには許可する必要がないとします。パネル1ではCustomizationAllowedにtrueを設定し、パネル2ではfalseを設定します。ページ全体でランタイム・カスタマイズを許可する必要がある場合は、.jspxページ・ルートのCustomizationAllowedにtrueを設定します。

始める前に:

拡張メタデータの使用方法に関する知識が役立つ場合があります。詳細は、「拡張メタデータ・プロパティ」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。

次のタスクも完了する必要があります。

- 「カスタマイズ可能なアプリケーションの開発」の説明に従って、カスタマイズ可能なアプリケーションを作成します。

- Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開きます。

カスタマイズ・プロパティを編集するには:

1. 「アプリケーション」ウィンドウで、カスタマイズ・プロパティを編集するオブジェクトを選択します。

2. 構造ウィンドウで、適切な要素を選択します。

3. 「プロパティ」ウィンドウで、「カスタマイズ」ノードを開いてカスタマイズ・プロパティを編集します。

「プロパティ」ウィンドウに選択したコンポーネントの値を表示するには、メイン・メニューから「ウィンドウ」→「プロパティ」を選択します。

4. プロパティの値を編集して、[Enter]を押します。

たとえば、.jspxファイルでランタイム・カスタマイズを許可する場合、ファイルを選択してCustomizationAllowedプロパティをtrueに設定します。

5. メイン・メニューで、「ファイル」→「保存」を選択して、変更を保存します。

51.5.2.2 スタンドアロン注釈ファイルを使用してタイプ・レベル・カスタマイズ・プロパティを指定する

任意でスタンドアロン注釈ファイルを使用して、カスタマイズを指定のタイプのコンポーネントに対して許可するかどうかを指定できます。このファイルを使用すると、インスタンスではなく要素型に基づいてカスタマイズ・プロパティを設定できます。特定のインスタンスに対して明示的にtrueまたはfalseを設定して、指定のタイプの設定をオーバーライドできます。次の例は、サンプルのスタンドアロン注釈ファイルの内容を示しています。

<?xml version="1.0" encoding="UTF-8"?>
<grammarMetadata xmlns="http://xmlns.oracle.com/bali/xml/metadata"
xmlns:md="http://xmlns.oracle.com/bali/xml/metadata"
xmlns:mmd="http://xmlns.oracle.com/bali/xml/metadata/model"
xmlns:mds="http://xmlns.oracle.com/mds"
namespace="http://www.oracle.com/mds/restrictCustomizations">
<elementMetadata elementName="orderDetail">
<attributeMetadata attributeName="itemTypeRef">
<mds:customizationAllowedBy>sales admin</mds:customizationAllowedBy>
</attributeMetadata>
<attributeMetadata attributeName="description">
<mds:customizationAllowed>true</mds:customizationAllowed>
<mds:customizationAllowedBy>hr</mds:customizationAllowedBy>
</attributeMetadata>
<attributeMetadata attributeName="title">
<mds:customizationAllowed>true</mds:customizationAllowed>
</attributeMetadata>
</elementMetadata>

<elementMetadata elementName="bankTransfer">
<mds:customizationAllowed>false</mds:customizationAllowed>
</elementMetadata>

<elementMetadata elementName="order">
<mds:customizationAllowed>true</mds:customizationAllowed>
<attributeMetadata attributeName="paymentRef">
<mds:customizationAllowedBy>sales</mds:customizationAllowedBy>
</attributeMetadata>
<elementMetadata elementName="itemDetail">
<attributeMetadata attributeName="itemsRef">
<mds:customizationAllowedBy>hr</mds:customizationAllowedBy>
</attributeMetadata>
</elementMetadata>
</elementMetadata>

</grammarMetadata>

スタンドアロン注釈ファイルを使用する場合、これをadf-config.xmlファイルのMDSに登録する必要があります。次の例に示すように、adf-config.xmlファイルのmdsc:type-configセクションにmdsc:standalone-definitionsセクションを作成します。

<?xml version="1.0"?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:mdsc="http://xmlns.oracle.com/mds/config">
<mdsdata>
<mdsc:mds-config version="11.1.1.000" >
<mdsc:type-config>
<mdsc:type-definitions>

<mdsc:url>jar:file:/c:/jdev/lib/oafwk.jar!/oracle/apps/schemas/oa.xsd</mdsc:url>

<mdsc:mds>/oracle/mds/TypeSeven.xml</mdsc:mds>
<mdsc:mds>/oracle/mds/TypeEight.xml</mdsc:mds>
<mdsc:file>typefile7.xsd</mdsc:file>
<mdsc:file>typefile8.xsd</mdsc:file>
</mdsc:type-definitions>
<mdsc:standalone-definitions>

<mdsc:url>jar:file:/c:/jdev/lib/oafwk.jar!/oracle/apps/schemas/oa.xsd</mdsc:url>

<mdsc:mds>/oracle/mds/standAloneSeven.xml</mdsc:mds>
<mdsc:mds>/oracle/mds/standAloneEight.xml</mdsc:mds>
<mdsc:file>standAloneFile7.xsd</mdsc:file>
<mdsc:file>standAloneFile8.xsd</mdsc:file>
</mdsc:standalone-definitions>
</mdsc:type-config>
....
</mdsc:mds-config>
</mdsdata>
</adf-config>

51.6 カスタマイズ構成の実行時変更の有効化

カスタマイズしたアプリケーションで実行時にセッションごとにカスタマイズ構成(adf-config.xmlファイルのcust-configセクション)をオーバーライドできるようして、特定のセッション(またはWebリクエスト)にカスタマイズを適用する方法をユーザーが変更できるようにすることができます。

アプリケーションがsiteレイヤーとuserレイヤーで構成されていて、siteレイヤーに実行時のデザインタイムのカスタマイズを行うシナリオを考えてみます。アプリケーションのカスタマイズ構成(adf-config.xmlファイルで定義された)を使用する場合、実装するカスタマイズはすべてuserレイヤーに適用されます。このため、特定のセッションのカスタマイズ構成を調整して、カスタマイズをsiteレイヤーに適用できる必要があります。

または、管理者がsiteレイヤーのカスタマイズのみを持つベース・メタデータ・ドキュメントを確認できる必要があるとします。このような場合、アプリケーションのadf-config.xmlファイルで元々指定されている以外の、変更済のカスタマイズ構成を指定する必要があります。

Webリクエストごとに、Oracle ADFはMDSセッションを作成します。セッション(Webリクエスト)に適用するMDSカスタマイズ構成変更に対して、新しいカスタマイズ構成の変更済MDSセッション・オプションをOracle ADFにプログラムで提供できます。これは、MDSセッションの作成時に、元のMDS構成の上に適用されます。

この機能を実装するには、sessionOptionsFactoryの次のADFインタフェースを使用します。

- oracle.adf.share.mds.SessionOptionsFactoryは、Fusion WebアプリケーションでWebリクエストの変更済MDSセッション・オプションを指定するためのインタフェースです。

SessionOptionsFactory :: oracle.mds.core.SessionOptions createSessionOptions(oracle.mds.core.SessionOptions defaultOptions)

このメソッドを実装すると、変更済MDS sessionOptionsがADFに戻されます。

- oracle.adf.share.config.ConfigUtilsは、セッション・オプション・ファクトリをADFに登録するためのパブリック・クラスです。

ConfigUtils :: public static void setSessionOptionsFactory(ADFContext context, SessionOptionsFactory factory)

これらのインタフェースの詳細は、ADF APIドキュメントを参照してください。

注意:

Oracle WebCenter Portalのコンポーザ・コンポーネントを使用している場合、ComposerSessionOptionsFactoryインタフェースを使用して、Oracle WebCenter Portalのコンポーザの変更済MDSセッション・オプションを指定できます。

ComposerSessionOptionsFactory :: public SessionOptions createSessionOptions(SessionOptions defaultOptions, String mode);

oracle.adf.view.page.editor.webapp.WebCenterComposerFilterは、ComposerSessionOptionsFactory実装を現在のスレッド・コンテキストのクラス・ローダーからロードします。詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

sessionOptionsFactoryをOracle ADFに登録して、リクエストのライフサイクルでMDSセッションが作成される前に、ADFが実装から変更済セッション・オプションを取得できるようにします。

または、フィルタ実装でsessionOptionsFactoryをOracle WebCenter Portalのコンポーザに登録できます。

次の例は、sessionOptionsFactoryの実装方法を示しています。この例では、adf-config.xmlファイルで指定されたカスタマイズ構成に関係なく、siteカスタマイズ・レイヤーのみを使用する変更済カスタマイズ構成をセッションに設定します。詳細は、oracle.mdsのJavadocを参照してください。

package mycompany;

import oracle.adf.share.mds.SessionOptionsFactory;
import oracle.mds.config.CustClassListMapping;
import oracle.mds.config.CustConfig;
import oracle.mds.config.MDSConfigurationException;
import oracle.mds.core.SessionOptions;
import oracle.mds.cust.CustClassList;
import oracle.mds.cust.CustomizationClass;

public class MySessionOptionsFactory implements SessionOptionsFactory {
public MySessionOptionsFactory() {
super();
}
/**
* Called to allow the application code to create a new SessionOptions object.
* The application code should make sure to read the values from the
* defaultOptions object as part of contruction of their new object and make
* sure they only override the intended values.
* @param defaultOptions
* @return modified MDS session options
*/
public SessionOptions createSessionOptions(SessionOptions defaultOptions) {
// create new mds Customization configuration
CustConfig custconfig = null;

// create customization class array. Just put SiteCC implementation as we
// wish to apply site customizations alone.
CustomizationClass[] custclassarray = new CustomizationClass[] {new SiteCC()};

CustClassList custclasslist = new CustClassList(custclassarray);

// specify the base metdata package namespace mapping on which site
// customizations would apply
CustClassListMapping[] mappings =
new CustClassListMapping[] {new CustClassListMapping("mycompany/package",
null, null, custclasslist)};
// create new customization configuration
try{
custconfig = new CustConfig(mappings);
}
catch (Exception ex){
//do nothing
}

// now return modified sessionOptions to ADF with new mds customization
// configuration. Only use newly created customization configuration in here.
// For rest of option, use whatever available in defaultOptions.
return new SessionOptions(defaultOptions.getIsolationLevel(),
defaultOptions.getLocale(),
custconfig,
defaultOptions.getVersionContext(),
defaultOptions.getVersionCreatorName(),
defaultOptions.getCustomizationPolicy(),
defaultOptions.getServletContextAsObject());
}
}

52 実行時のユーザー・カスタマイズの許可

この章では、ADF Faces変更永続性フレームワークを使用して、ユーザーが実行時にカスタマイズ可能なJSFページを作成する方法について説明します。

この章の内容は次のとおりです。

- ユーザー・カスタマイズについて

- Fusion Webアプリケーションの実行時ユーザー・カスタマイズの有効化

- ユーザー・カスタマイズの構成

- 個々のJSFページでのユーザー・カスタマイズの制御

- カスタム・ユーザー・カスタマイズの実装

- カスタム・コンポーネントでの暗黙的な変更永続性の作成

52.1 ユーザー・カスタマイズについて

特定のADF Facesコンポーネントには、特定のユーザーのために保存できる属性があります。たとえば、panelBoxコンポーネントのdisclosed属性の値を、現在のセッションの間、特定のユーザーのために保存できます。アプリケーションのmyOrdersページには、オーダー情報を示す4つのpanelBoxコンポーネントがあります。デフォルトでは、これらは図52-1に示すように開いています。

図52-1 デフォルトで開いているpanelBoxコンポーネント

図52-2のように、1つのボックスを折りたたむとします。

図52-2 panelBoxコンポーネントを折りたたむ場合

このアプリケーションはユーザー・カスタマイズを許可するように構成されているため、ユーザーのセッション中にユーザーがこのページに戻ると、支払情報ボックスは折りたたまれたままです。これらの変更内容をユーザーのセッションに永続させるには、プロジェクトに対してユーザー・カスタマイズを有効にするだけで済みます。

注意:

ユーザー・セッションは、ユーザーがアプリケーションにログインすると開始され、ユーザーがアプリケーションを終了すると終了します。アプリケーションの使用中、ユーザーはアプリケーションの境界を越えて(ピア・アプリケーションなどに)移動し、そこでアプリケーションを終了する場合がありますが、ユーザー・セッションはその時点で終了します。

表52-1に、ユーザー・カスタマイズを許可するようにアプリケーションを構成した後に、ADF Facesアプリケーションによって永続される属性値の変更を示します。

表52-1 暗黙的に永続する属性値

コンポーネント

属性

実行時の効果

panelBox

showDetail

showDetailHeader

showDetailItem

disclosed

ユーザーは、ヘッダーのアイコンを使用してコンテンツを表示または非表示にできます。ユーザーの直近のアクションに基づいて、詳細コンテンツが表示または非表示になります。

showDetailItem (panelAccordionコンポーネントで使用)

flex

複数のshowDetailItemコンポーネントの高さは、それぞれのflex属性の相対値によって決まります。大きいflex値が設定されているshowDetailItemコンポーネントは、小さい値が設定されているコンポーネントよりも高くなります。これらの比率を変更でき、新しい値は永続します。

showDetailItem (panelAccordionコンポーネントで使用)

inflexibleHeight

ユーザーはパネルのサイズを変更でき、そのサイズは保持されます。

panelSplitter

collapsed

ユーザーはスプリッタのいずれかの面を閉じることができます。閉じられた状態は、ユーザーによる最終の構成として保持されます。

panelSplitter

splitterPosition

パネルのスプリッタの位置が、ユーザーによって最後に移動された位置のままになります。

richTextEditor

editMode

エディタは、ユーザーが最後に選択したモード(WYSIWYGまたはソース)で表示されます。

calendar

activeDay

現在の表示でアクティブとみなされる日は、アクティブな日のままになります。

calendar

view

現在アクティビティを表示しているビュー(日、週、月またはリスト)が保持されます。

panelWindow

dialog

contentHeight

ユーザーはpanelWindowまたはdialogポップアップ・コンポーネントの高さを変更でき、変更した高さが維持されます。

panelWindow

dialog

contentWidth

ユーザーはpanelWindowまたはdialogポップアップ・コンポーネントの幅を変更でき、変更した幅が維持されます。

button

link

commandMenuItem

commandNavigationItem

windowHeight

ユーザーがpanelWindowまたはdialogコンポーネントのcontentHeight属性値を変更すると、コマンド・コンポーネントの関連するwindowHeight値も変更され、その値が維持されます。

button

link

commandMenuItem

commandNavigationItem

windowWidth

ユーザーがpanelWindowまたはdialogコンポーネントのcontentWidth属性値を変更すると、コマンド・コンポーネントの関連するwindowWidth値も変更され、その値が維持されます。

column

displayIndex

ADF Facesの列は、ユーザーが実行時に並べ替えることができます。displayIndex属性によって、列の順序が決まります。(デフォルトでは、各列の値は-1に設定され、データ・ソースと同じ順序で列が表示されます)。ユーザーが列を移動すると、新しい順序を反映するよう各列の値が変更されます。これらの新しい値は永続します。

column

frozen

ADF Facesの列は、スクロールされないように固定できます。列のfrozen属性をtrueに設定すると、その列の前のすべての列(displayIndex値に基づく)がスクロールしません。panelCollectionコンポーネントで表を使用する場合、ユーザーが列を固定できるボタンが表示されるようにその表を構成できます。

column

noWrap

列のコンテンツを折り返すかどうかを指定します。ユーザーがこの属性値を変更できるようにするコードを作成する必要があります。たとえば、ユーザーが値をtrueからfalseに切り替えることができるポップアップ・メニューを作成します。

column

selected

選択された列は、ユーザーが最後に選択した列に基づきます。

column

visible

ユーザーの直近のアクションに基づいて、列が表示または非表示になります。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。たとえば、ユーザーが値をtrueからfalseに切り替えることができるポップアップ・メニューを作成します。

column

width

列の幅が、ユーザーが最後に設定したサイズのままになります。

table

filterVisible

ADF Facesの表には、ユーザーが属性値で表の行をフィルタ処理できるコンポーネントを含めることができます。フィルタを使用するよう構成されている表では、ユーザーの直近のアクションに基づいて、フィルタは表示または非表示になります。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。たとえば、ユーザーが値をtrueからfalseに切り替えることができるボタンを作成します。

dvt:areaGraph

dvt:barGraph

dvt:bubbleGraph

dvt:comboGraph

dvt:horizontal BarGraph

dvt:lineGraph

dvt:scatterGraph

timeRangeMode

グラフの時間軸上に表示されるデータの時間範囲は、すべてのデータ視覚化グラフ・コンポーネントに指定できます。デフォルトでは、すべてのデータが表示されます。時間範囲は、最後または最初のデータ・ポイントからの相対的時間範囲、または明示的時間範囲にも設定できます。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。たとえば、グラフの時間範囲を選択するためのドロップダウン・リストを作成できます。

dvt:ganttLegend

visible

データ視覚化プロジェクトの凡例、リソース使用率およびスケジュール・ガント・チャート・コンポーネントは、情報パネル内で表示されるかされないかのいずれかです。ユーザーがこの属性値を変更できるように(汎用を表示するための非表示および表示のボタン)コードを記述することが必要になります。

dvt:hierarchyViewer

layout

データ視覚化階層ビューア・コンポーネントでは、上から下への垂直、ツリー、円、放射など、9つの階層レイアウト・オプションをサポートしています。ユーザーは、マップ・コントロール・パネルでレイアウトを変更でき、最後に選択されたレイアウトが保持されます。

dvt:map

mapZoom

このデータ視覚化地理マップ・コンポーネント属性では、マップの初期ズーム・レベルを指定します。ズーム・レベルは、ベース・マップの一部としてマップ・キャッシュ・インスタンスで定義されます。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。

dvt:map

srid

このデータ視覚化地理マップ・コンポーネント属性では、startingXおよびstartingYによって定義されるマップの中心位置や、点テーマのすべての点を含む、マップの全座標のsrid(空間参照ID)を指定します。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。

dvt:map

startingX、startingY

このデータ視覚化地理マップ・コンポーネント属性では、マップの中心位置のXおよびY座標を指定します。座標のsridはsrid属性で指定します。srid属性が指定されていない場合、その値はマップの中心位置の経度であると想定されます。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。

dvt:projectGantt

dvt:resource UtilizationGantt

dvt:schedulingGantt

splitterPosition

パネルのスプリッタの位置が、ユーザーによって最後に移動された位置のままになります。

dvt:timeAxis

scale

プロジェクト、リソース使用率およびスケジュールのガント・チャートのデータ視覚化コンポーネントでは、ガント・チャートの主時間軸および副時間軸の指定にこのファセットを使用します。タイム・スケール(twoyears、year、halfyears、quarters、twomonths、months、weeks、twoweeks、days、sixhours、threehours、hours、halfhours、quarterhours)は、ユーザーがメニュー・バーの「表示」メニューを使用することで設定でき、その選択は保持されます。このコンポーネント値には、カスタム・タイム・スケールも指定できます。

dvt:timeSelector

explicitStart、explicitEnd

データ視覚化の面、棒、コンボ、折れ線、散布およびバブルの各グラフ・コンポーネントでは、この子タグ属性を使用して、タイム・セレクタの開始および終了日付を明示的に指定します。この属性では、値バインディングのみがサポートされています。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。

52.1.1 実行時ユーザー・カスタマイズのユースケースおよび例

MDSリポジトリを使用して表52-1にリストした属性の値をセッション間で永続できるように、アプリケーションを構成できます。たとえば、アプリケーションでMDSリポジトリへの永続化が許可されている場合、図52-2に示すように支払情報ボックスを折りたたむことができ、次回アプリケーションを開いたときに折りたたまれた状態になります。

注意:

リポジトリへの永続化を有効にするには、事前に『Oracle Fusion Middlewareの管理』に説明されているすべてのMDS構成手順を実行する必要があります。

ADF Facesで使用できる自動永続性のほかに、次のタイプの変更に対する独自のカスタム・ユーザー・カスタマイズ機能を作成できます。

- 属性値の変更

- ファセットの追加または削除

- 子コンポーネントの追加または削除

- 子コンポーネントの並替え

- 子コンポーネントの別の親への移動

これらのタイプのカスタム・ユーザー・カスタマイズを作成する場合、永続性を処理するAPIを呼び出すコードを追加する必要があります(たとえば、イベント・ハンドラで)。

アプリケーションで変更永続性フレームワークを使用できるようにするには、まずアプリケーションでユーザー・カスタマイズを許可できるようにする必要があります。このプロセスには、変更内容をセッションまたはMDSリポジトリのどちらに永続させるかの決定が含まれます。

変更内容をセッションに永続させる場合、デフォルトでは、表52-1に示すすべての値がユーザーのセッションに保存されます。ただし、リポジトリに永続させる場合は、これらの属性値のうちどれをリポジトリに永続させるかを明示的に構成する必要があります。これらのすべての属性値を永続させるのではなく、コンポーネントの特定属性値の変更のみが永続されるように、またはコンポーネントの特定インスタンスのみが変更を永続させるように、変更を制限できます。

注意:

addComponentChange()メソッドを使用して、af:forEachタグまたはaf:iteratorタグの(サブツリーの)内部に含まれるコンポーネントの変更は、永続できません。この構造では表示ツリーに1つのコンポーネントの複数のコピーが表示されますが、JSPドキュメントには各コンポーネントは1回しか表示されないためです。ただし、addDocumentChange()メソッドでは、このようなコンポーネントの永続性を許可します。詳細は、「変更永続性フレームワークAPIに関する必知事項」のDocumentChangeクラスとComponentChangeクラスの説明を参照してください。

変更内容をMDSリポジトリに永続させるアプリケーションをデプロイする際には、アプリケーションのEARアセンブリにメタデータ・アーカイブ(MAR)プロファイルを作成する必要があります。詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。

52.1.2 実行時ユーザー・カスタマイズの追加機能

ユーザー・カスタマイズを使用し始める前に、他の機能を理解することが役立つ場合があります。次に、関連する他の機能へのリンクを示します。

- MDSアーキテクチャとメタデータ・リポジトリ(データベース・ベースおよびファイル・ベース)およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項を参照してください。

- MDSフレームワークを使用すると、顧客がカスタマイズしてからデプロイできる、カスタマイズ可能なアプリケーションを作成できます。詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。

- Oracle WebCenter Portalの機能により、ビジネス・アナリストや管理者はWebブラウザ・インタフェースを使用して、エンド・ユーザー向けにアプリケーションをカスタマイズできます。ランタイムのカスタマイズの詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

52.2 Fusion Webアプリケーションの実行時ユーザー・カスタマイズの有効化

アプリケーションでユーザー・カスタマイズを許可できるようにするには(一部のADF Facesコンポーネントが提供するデフォルトの変更に対して、またはユーザーが作成するカスタム機能に対して)、変更永続性フレームワークを使用するようにアプリケーションを構成し、変更内容を永続させる場所(セッションまたはMDSリポジトリ)を決定する必要があります。

注意:

変更内容をMDSリポジトリに永続させる場合は、変更永続性を使用するようにADF Facesアプリケーションを構成する前に、『Oracle Fusion Middlewareの管理』に説明されているすべてのMDS構成手順を実行する必要があります。

52.2.1 ユーザー・カスタマイズを有効にする方法

アプリケーションで変更永続性フレームワークを使用できるようにするには、web.xmlファイルとadf-config.xmlファイルを編集します。

始める前に:

実行時ユーザー・カスタマイズの機能に関する知識が役立つ場合があります。詳細は、「Fusion Webアプリケーションの実行時ユーザー・カスタマイズの有効化」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。

Studio開発者ロールを使用してJDeveloperを起動し、実行時ユーザー・カスタマイズを有効化するアプリケーションを開く(または作成する)必要があります。

ユーザー・カスタマイズを有効にするには:

1. 「アプリケーション」ウィンドウで、アプリケーション内のWebプロジェクトをダブルクリックします。

2. 「プロジェクト・プロパティ」ダイアログで、「ADFビュー」ノードを選択します。

3. 「ADFビュー」ページで「ユーザー・カスタマイズの有効化」チェックボックスを選択します。変更内容をセッションにのみ永続させる場合は、「セッションの継続時間」ラジオ・ボタンを選択します。変更内容をMDSリポジトリに永続させる場合は、「MDSを使用したセッション間」を選択します。

4. リポジトリに永続させる場合は、各コンポーネント・タグおよびリポジトリに永続させる関連する属性値を宣言する必要があります(セッションにのみ永続させる場合は、すべての値が永続されます)。

このタスクを実行する手順については、「ユーザー・カスタマイズの構成」を参照してください。構成が完了したら、これらの設定をコンポーネント・イスタンスごとにオーバーライドできます。手順については、「個々のJSFページでのユーザー・カスタマイズの制御」を参照してください。

注意:

「カスタム・ユーザー・カスタマイズの実装」の説明に従ってカスタム・ユーザー・カスタマイズ機能を作成した場合は、これらの属性値または操作も宣言する必要があります。

52.2.2 ユーザー・カスタマイズを有効化する場合の処理

変更内容をセッションにのみ保存するよう選択すると、JDeveloperによりCHANGE_PERSISTENCEコンテキスト・パラメータがweb.xmlファイルに追加され、値がsessionに設定されます。このコンテキスト・パラメータでは、永続性の処理に使用されるChangeManagerクラスが登録されます。かわりに、変更内容をMDSリポジトリに保存するよう選択すると、次の例に示すように値はoracle.adf.view.rich.change.FilteredPersistenceChangeManagerに設定されます。

<context-param>
<param-name>org.apache.myfaces.trinidad.CHANGE_PERSISTENCE</param-name>
<param-value>
oracle.adf.view.rich.change.FilteredPersistenceChangeManager
</param-value>
</context-param>

ヒント:

adf-config.xmlファイルの構成または個々のJSFページに基づいてカスタマイズを制限せずに、常に変更内容をセッションではなくMDSリポジトリに永続させる場合は、必要に応じて、この値を手動でoracle.adf.view.rich.change.MDSDocumentChangeManagerに設定できます。

リポジトリへの永続化を選択すると、JDeveloperにより次の処理も行われます。

- 次のJARがクラス・パスに追加されます(ない場合)。

- javatools-nodep.jar

- facesconfigmodel.jar

- taglib.jar

- 別のコンテキスト・パラメータをweb.xmlに追加して、MDSJSPProviderHelperクラスを登録し、MDSカスタマイズ・ドキュメントとベースJSPドキュメントのマージを処理します(次の例を参照)。

<context-param>
<param-name>oracle.adf.jsp.provider.0</param-name>
<param-value>oracle.mds.jsp.MDSJSPProviderHelper</param-value>
</context-param>

- ADF Faces Change Managerランタイム11ライブラリをプロジェクトに追加します。

- adf-config.xmlディスクリプタ・ファイルで、persistent-change-manager要素をMDSDocumentChangeManagerに設定します。これは、変更内容の永続化に使用するクラスです。次の例は、MDSリポジトリに対して永続化するための構成を示しています。

<persistent-change-manager>
<persistent-change-manager-class>
oracle.adf.view.rich.change.MDSDocumentChangeManager
</persistent-change-manager-class>
</persistent-change-manager>

- JSF JSPページをXMLドキュメントとして作成します。詳細は、「個々のJSFページでのユーザー・カスタマイズの制御」を参照してください。

また、変更内容をMDSリポジトリに保存し、Faceletをアプリケーションに含めることを選択した場合、JDeveloperによって、faceletCacheコンテキスト・パラメータがweb.xmlファイルに追加されます。このパラメータの値は、次の例に示すように、oracle.adfinternal.view.faces.facelets.rich.MDSFaceletCacheに設定されます。

<context-param>
<param-name>com.sun.faces.faceletCache</param-name>

<param-value>oracle.adfinternal.view.faces.facelets.rich.MDSFaceletCache</param-value>

</context-param>

Faceletキャッシュはアプリケーションのパフォーマンスを向上し、キャッシュ容量はサーバーのMDSで構成できます。詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

52.3 ユーザー・カスタマイズの構成

変更内容をMDSリポジトリに永続させる場合、デフォルトでセッションに永続させる属性値のうち(表52-1を参照)、リポジトリにも永続させる属性値を決定する必要があります。または、永続させない変更を構成することもできます。

ヒント:

多くの場合、構成はシステム管理者がadf-config.xmlで設定します。コンポーネントのpersistおよびdontPersist属性により、ページ作成者は必要に応じてこの設定をオーバーライドできます。

たとえば、列のwidth属性の値はリポジトリに永続させないが、列の他のデフォルト属性の変更はすべて永続させるとします。この場合、永続させる他のデフォルトの列値を明示的に設定し、またwidth属性を永続させないようにアプリケーションを明示的に構成する必要があります。

注意:

「カスタム・ユーザー・カスタマイズの実装」の説明に従ってカスタム・ユーザー・カスタマイズ機能を作成した場合は、これらの属性値または操作も明示的に宣言する必要があります。

これらの値は、adf-config.xmlファイルの概要エディタを使用して設定(または設定解除)します。図52-3に、columnコンポーネントの特定の属性値のみを永続させる概要エディタを示します。

図52-3 adf-config.xmlファイルの概要エディタ

設定後、ページ上の特定コンポーネントの永続性をオーバーライドできます。たとえば、1つの表の列に対してのみ、width属性の変更を許可しないとします。アプリケーションの他の表では、その属性の変更を永続させます。この場合、width属性の変更をグローバルに永続させるように列を構成し、その後その1つの表に対して、JSFページで直接グローバル構成をオーバーライドします。詳細は、「個々のJSFページでのユーザー・カスタマイズの制御」を参照してください。

注意:

セッションの永続性のみを有効にした場合、表52-1のすべての属性値がセッションに永続されます。これをグローバルにまたはインスタンスでオーバーライドする方法はありません。

52.3.1 変更永続性の構成方法

デフォルトでは、いずれかのタイプの変更永続性(セッションまたはリポジトリへの)を使用するようにアプリケーションを構成する際、表52-1に示すすべての属性の値が、常にユーザーのセッションに永続化されます。変更内容をリポジトリに永続させるように構成した場合は、値をそのリポジトリに永続させる属性を宣言する必要があります。永続させない値がある場合は、それらの値も構成する必要があります。

始める前に:

実行時ユーザー・カスタマイズが永続される方法に関する知識が役立つ場合があります。詳細は、「ユーザー・カスタマイズの構成」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。

Studio開発者ロールを使用してJDeveloperを起動し、実行時ユーザー・カスタマイズを有効化するアプリケーションを開く(または作成する)必要があります。

属性値のリポジトリへの永続性を宣言するには:

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開いて、「adf-config.xml」をダブルクリックします。

2. 概要エディタで「表示」ナビゲーション・タブをクリックします。

3. 「ビュー」ページの「タグ永続性」セクションの「コンポーネント」表で、変更をリポジトリに対して永続化(または非永続化)するコンポーネントを選択します。

コンポーネントが表に表示されない場合は、「追加」アイコンをクリックし、コンポーネントを選択して追加します。

注意:

adf-config.xmlファイルで指定されているフィルタ・ルールは、MDSリポジトリに対して永続化する場合にのみ適用されます(「ユーザー・カスタマイズを有効にする方法」を参照)。これらのルールは、セッション・スコープ内の永続性には適用されません。

なんらかの理由で永続性が失敗した場合、(たとえば、いずれかのフィルタ・ルールが失敗した場合またはMDSリポジトリ・エラーがある場合)、値はセッション・スコープ内にのみ保存されます。

「属性」表に、選択したコンポーネントの、値を永続できるすべての属性が表示されます。

4. 「属性」表で、値を永続化させる各属性に対して「変更の永続化」を選択します。値を永続させない場合は、選択解除します。

注意:

カスタム・ユーザー・カスタマイズを実装する場合は(「カスタム・ユーザー・カスタマイズの実装」を参照)、adf-config.xmlを手動で編集して構成を追加する必要があります。ユーザー・カスタマイズの構成方法の例は、「変更永続性の構成時の処理」を参照してください。

52.3.2 変更永続性の構成時の処理

adf-config.xmlファイルでコンポーネント・タグと永続させる属性値を選択すると、JDeveloperによってコンポーネントのタグ・ライブラリ情報と永続させる属性が入力されます。次の例は、panelBoxコンポーネントのdisclosed属性の値を永続化するエントリを示しています。

<taglib-config>
<taglib uri="http://xmlns.oracle.com/adf/faces/rich">
<tag name="panelBox">
<attribute name="disclosed">
<persist-changes>
true
</persist-changes>
</attribute>
...
</tag>
</taglib>
</taglib-config>

52.4 個々のJSFページでのユーザー・カスタマイズの制御

アプリケーションでユーザー・カスタマイズを使用できるようにしたら、ページ上の特定コンポーネントのユーザー・カスタマイズを制御できます。

デフォルトでは、このフレームワークはすべてのコンポーネント・インスタンスの変更内容を、adf-config.xmlファイルの構成に基づいて永続させます。persistおよびdontPersist属性を使用して、コンポーネント・インスタンスごとに何を永続させるかおよび何を永続させないかを明示的に設定することで、このデフォルト動作をオーバーライドできます。

注意:

persistおよびdontPersist属性を使用して指定されているフィルタ・ルールは、MDSリポジトリに対して永続化する場合にのみ適用されます(「ユーザー・カスタマイズを有効にする方法」を参照)。これらのルールは、セッション・スコープ内の永続性には適用されません。

なんらかの理由で永続性が失敗した場合、(たとえば、いずれかのフィルタ・ルールが失敗した場合またはMDSリポジトリ・エラーがある場合)、値はセッション・スコープ内にのみ保存されます。

persistおよびdontPersist属性をサポートするコンポーネントを次に示します。

- panelBox

- showDetail

- showDetailHeader

- showDetailItem

- column

- tree

- treeTable

- panelSplitter

- calendar

- dvt:projectGantt

- dvt:resourceUtilizationGantt

- dvt:schedulingGantt

- dvt:ganttLegend

- dvt:hierarchyViewer

- dvt:timeAxis

52.4.1 JSFページでのユーザー・カスタマイズの制御方法

persist属性およびdontPersist属性を使用して、コンポーネントにグローバルに設定されているすべての永続性構成をオーバーライドできます。

ヒント:

多くの場合、構成はシステム管理者がadf-config.xmlで設定します。persistおよびdontPersist属性により、ページ作成者は必要に応じてこの設定をオーバーライドできます。

始める前に:

実行時ユーザー・カスタマイズが個別ページで制限される方法に関する知識が役立つ場合があります。詳細は、「個々のJSFページでのユーザー・カスタマイズの制御」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。

Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開き、ユーザー・カスタマイズの動作を変更するページを開きます。

JSFページでユーザー・カスタマイズを実装するには:

1. 「アプリケーション」ウィンドウで、変更を永続化させるコンポーネントを含むページをダブルクリックします。

2. コンポーネントの永続可能なすべての属性を永続させる場合:

a. 「プロパティ」ウィンドウで、「拡張」セクションを開きます。

b. 「永続」フィールドのドロップダウン・リストから、「すべて使用可能」を選択します。

3. 属性を永続させない場合は、永続させないフィールドに対して手順2を繰り返します。

4. コンポーネントの複数の属性を永続できるが、それらすべては永続させない場合:

a. 「プロパティ」ウィンドウで、「永続」フィールドの右側のドロップダウン・メニューから、「編集」を選択します。

b. 「プロパティの編集」ダイアログで、永続させる属性を「選択可能」から「選択済」に移動します。

5. 属性値を永続させない場合は、永続させないフィールドに対して手順4を繰り返します。

注意:

persistおよびdontPersist属性を使用して指定されているフィルタ・ルールは、グローバルなコンポーネント・レベルの制限を設定するadf-config.xml構成より優先されます。

dontPersist属性に指定された値は、persist属性に指定された値より優先されます。たとえば、panelBoxコンポーネントでpersist属性とdontPersist属性の両方の値としてdisclosedを設定した場合、disclosed属性の値は永続されません。

またはpersist属性またはdontPersist属性の値をAll Availableに設定した場合、「編集」ダイアログを使用して選択肢として入力された値および移動は無視され、使用可能なすべての属性値が永続されるか、または永続されません。

52.4.2 実行時の処理: 変更をどのように永続させるか

変更内容をセッションに永続させるようアプリケーションを構成している場合、セッション中に行われた変更はすべてデータ構造内のセッション変数に記録されます。これは、ビューIDとコンポーネントのID属性値によって索引付けされます。後続のビューの作成またはビューのリストア・フェーズでページがリクエストされるたびに、すべての変更内容が追加されたときと同じ順序で適用されます。つまり、セッションの間に登録された変更は、同じセッションの後続のリクエストでのみ適用されます。

変更内容をMDSリポジトリに永続させるようにアプリケーションを構成している場合、ビューの背後のJSPドキュメントに対してMDSで保持するDocument Object Modelを変異させることで、セッション中に行われた変更が記録されます。ADFコントローラによって登録されたJSFフェーズ・リスナーが、適切なライフサイクル・フェーズでMDSセッションに対するコミットをトリガーすることで、変更ドキュメントがMDSストアに永続されます。ページがリクエストされるたびに、格納された変更をベース・ドキュメントにマージした後、フラット化されたドキュメントを提供するMDS JSPプロバイダから、OracleのJSPエンジンでJSPドキュメントが検索されます。MDSでは、コンポーネントのID属性の一意の値に対して変更が記録されます。

ヒント:

ページの部分送信に応えて変更が適用される場合(partialSubmit属性をtrueに設定したbuttonなど)、変更が適用されるコンポーネントをpartialTarget属性の値として設定する必要があります。

さらに、登録WebLogic ServerでJDeveloperからアプリケーションを実行する場合は、MDSによりメタデータ・カスタマイズを永続させるためのローカル・ファイルベースのリポジトリが作成されます。逆に、アプリケーションがテスト環境または本番環境にデプロイされる場合、カスタマイズは構成済のMDSリポジトリに永続されます。MDSリポジトリ構成の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。アプリケーションのデプロイの詳細は、「アプリケーションのデプロイ」を参照してください。

52.4.3 テンプレートおよび領域での変更永続性の使用に関する必知事項

変更内容がテンプレートまたはリージョンのコンポーネントに永続される際の処理方法は、変更がセッションに永続されるか、MDSリポジトリに永続されるかによって異なります。セッション永続性では、指定されたセッションのviewIdに対して変更内容が記録およびリストアされます。その結果、リージョンまたはページ・テンプレートに属するコンポーネントで変更が適用される場合、その変更は、リージョンまたはテンプレートを使用するページの範囲でのみ適用可能です。リージョンまたはテンプレートを使用するページすべてには適用されません。たとえば、pageOne.jspxとpageTwo.jspxがあり、両方にregion.jsffで定義されているリージョンが含まれ、これにはshowDetailコンポーネントが含まれるとします。pageOne.jspxがレンダリングされ、showDetailコンポーネントのdisclosed属性が変更されると、暗黙的に属性の変更が記録され、pageOne.jspxにのみ適用されます。ユーザーがpageTwo.jspxに移動すると、属性の変更は適用されません。

変更内容をMDSリポジトリに対して永続化する場合、JSPページ・パスとカスタマイズ・クラスで設定されたカスタマイズ名/値構成設定の組合せによって識別されたドキュメントのカスタマイズが、MDSにより記録されリストアされます(詳細は、「カスタマイズ・クラス」を参照)。この結果、レンダリングされた特定ページについて、MDSによりリージョンまたはテンプレート内のコンポーネントに変更が適用される際、ソース・ページと同じカスタマイズ名および値を持つ、リージョンまたはテンプレートを使用するページすべてに変更を適用できます。

前述の例で、showDetailコンポーネントがmyShowDetailのIDを使用するとします。pageOne.jspxがレンダリングされ、showDetailコンポーネントのdisclosed属性が変更されると、属性の変更はregion.jsffに記録されます(これを使用するページではなく)。この変更は、IDが同じであるかぎり、リージョンを含むページがレンダリングされるときに適用されます。

52.5 カスタム・ユーザー・カスタマイズの実装

特定のADF Facesコンポーネントに組み込まれているユーザー・カスタマイズ機能のほかに、独自のカスタム・ユーザー・カスタマイズ機能を作成できます。変更永続性フレームワークは、次のタイプのユーザー・カスタマイズをサポートします。

- 属性値の変更

- ファセットの追加または削除

- 子コンポーネントの追加または削除

- 子コンポーネントの並替え

- 子コンポーネントの別の親への移動

カスタム・ユーザー・カスタマイズを作成するには、ユーザー・カスタマイズのタイプごとにカスタマイズ・クラスを作成し、作成したクラスを使用するようにアプリケーションを構成する必要があります。アプリケーションのカスタマイズ・レイヤーも設定する必要があります。これらの手順の詳細は、「カスタマイズ可能なアプリケーションの開発」を参照してください。

これらの前提条件を満たしたら、セッションまたはMDSリポジトリへの変更の永続化を処理するADF Facesクラスでメソッドを呼び出すロジックを追加します。変更を処理するには、いずれかのADF Faces専用コンポーネント変更クラスのAPIを使用するコードを作成します。多くの場合、このコードを、永続させるコンポーネントが配置されているページに関連付けられているマネージドBean上のイベント・ハンドラ・メソッドに追加します。コンポーネントのすべてのインスタンスで同じ変更内容を永続させる場合、コンポーネントが表示されるページごとにこのコードを追加する必要があります。

カスタム・コンポーネントを作成する場合は、コードをカスタム・コンポーネント・クラスに直接追加することで、コンポーネントにユーザー・カスタマイズを実装できます。この場合、コードをそのコンポーネント・クラスにのみ追加する必要があります(コンポーネントのインスタンスごとに1回ではなく)。詳細は、「カスタム・コンポーネントでの暗黙的な変更永続性の作成」を参照してください。

52.5.1 変更永続性フレームワークAPIに関する必知事項

カスタム・ユーザー・カスタマイズを作成するために必要な作業について理解するには、変更永続性とMDSフレームワークについて十分に理解していることが必要です。変更内容をMDSリポジトリに永続させる場合、変更永続性フレームワークがMDSフレームワークと連携して機能します。カスタマイズを保存する場所および方法は、MDSリポジトリ、カスタマイズ・レイヤー、カスタマイズ・クラスの設定によって異なります。MDSフレームワークとリポジトリ、およびその使用方法の詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。

変更永続性フレームワークでは、Apache MyFaces Trinidadからの基になる変更マネージャ・クラス(org.apache.myfaces.trinidad.changeパッケージ)といくつかのADF Faces固有のクラス(oracle.adf.view.rich.changeパッケージ)を使用します。登録済のChangeManagerクラスのインスタンスには、RequestContextオブジェクトからアクセスできます。リクエストで変更が作成および追加されときに、これらを収集して永続させます。SessionChangeManagerクラスはセッション内でのみ永続性を処理するChangeManagerの実装で、MDSDocumentChangeManagerクラスはMDSリポジトリのみに永続させる実装です。FilteredPersistenceChangeManagerクラスは、登録済の永続性変更マネージャを使用してフィルタ・ルールをリポジトリに渡す変更を格納するChangeManagerの実装です。FilteredPersistenceChangeManagerが使用されている場合、リポジトリに永続されない変更はセッションに永続されます。

コンポーネントの変更を記述するために、追加のクラスが使用されます。これらのAPIを使用して、ADF Facesフレームワークで提供される暗黙的な値変更以外のコンポーネントへの変更の永続化を処理します(表52-1を参照)。ComponentChangeは、ファセットや子コンポーネントの追加または削除など、JSFコンポーネント階層で行われる固有の変更を実装するための、すべてのクラスのベース・クラスです。これらの変更は、後続のビューの作成時に、変更が追加された順序で自動的に適用されます。ComponentChangeクラスを拡張し、DocumentChangeインタフェースを実装するクラスは、変更内容を直接MDSリポジトリに永続できます。DocumentChangeインタフェースを実装しないクラスは、変更内容をセッションにのみ永続できます。

表52-2に、特定のカスタマイズを処理する専用クラスを示します。「リポジトリ」列に「可」と表示されている場合、そのクラスはDocumentChangeインタフェースを実装し、変更内容をMDSリポジトリに永続できます。

表52-2 変更永続性の処理に使用するクラス

クラス名

リポジトリ

説明

AddChildDocumentChange

AddComplexChildDocumentChange

はい

はい

ドキュメント・マークアップを使用して、子コンポーネントまたは複雑な子(dvt:)コンポーネントを追加します。この変更の適用時に、子コンポーネントまたは複雑な子コンポーネントが作成されてドキュメントに追加されます。

AddComplexChildAttributeChange

はい

複雑な子(dvt:)コンポーネント属性を追加します。

AttributeComponentChange

ComplexAttributeComponentChange

いいえ

はい

属性の値を変更します。

AttributeDocumentChange

ComplexAttributeDocumentChange

はい

はい

ファセット属性の値を変更します。

MoveChildComponentChange

はい

子をあるコンテナから別のコンテナへ移動します。

RemoveChildComponentChange

はい

子コンポーネントを削除します。

RemoveComplexChildAttributeComponentChange

RemoveComplexChildAttributeDocumentChange

はい

はい

複雑な子(dvt:)コンポーネント属性を削除します。

SetFacetChildComponentChange

いいえ

ドキュメント・マークアップを使用して子コンポーネントをファセットに追加します。この変更の適用時に、マークアップがドキュメントに追加されます。

SetFacetChildDocumentChange

はい

子コンポーネントをファセットに追加します。この変更の適用時に、子コンポーネントに対応するDOM要素がドキュメントに追加されます。ファセットが存在しない場合は作成されます。ファセットが存在する場合は、そのコンテンツがすべて削除され、新たにコンテンツが追加されます。

RemoveFacetComponentChange

はい

ファセットを削除します。

ReorderChildrenComponentChange

はい

コンポーネントの子を並べ替えます。

ChangeManagerクラスとは別に、DocumentChangeFactoryインタフェースを実装してChangeManagerクラスに登録する必要がある場合があります。DocumentChangeFactoryの実装でComponentChangeに相当するDocumentChangeを提供できる場合、ChangeManagerはこれを使用してDocumentChangeをリポジトリに永続させます。

52.5.2 カスタム・ユーザー・カスタマイズ用のコードを作成する方法

作成する明示的な変更を処理するコードを追加し、JSFページ上のコンポーネントを構成してカスタマイズを処理する必要があります。また、デフォルトのユーザー・カスタマイズと同様に、カスタムの変更をadf-config.xmlファイルに登録する必要があります。

注意:

変更内容を複数の形式で表すことができる場合、最も優先順位の高い形式で記録する必要があります。次に例を示します。

- コンポーネントの属性の変更: 属性はコンポーネント・タグで指定するか、<f:attribute>タグを使用して表すことができます。JSF JSPドキュメントでは、コンポーネント・タグで指定された属性が<f:attribute>よりも優先されます。このため、コンポーネント・タグでの属性の変更がカスタマイズに記録されます。

- 列コンポーネントの列ヘッダー・テキスト: 列のヘッダー・テキストは、headerText属性を使用して、またはヘッダー・ファセットを使用して指定できます。この場合は、ファセット・コンポーネントが優先されます。

始める前に:

カスタムの実行時ユーザー・カスタマイズの機能に関する知識が役立つ場合があります。詳細は、「カスタム・ユーザー・カスタマイズの実装」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。

Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開き、ユーザー・カスタマイズの動作を変更するページを開きます。

カスタム・ユーザー・カスタマイズを作成するには:

1. 「Fusion WebアプリケーションでのマネージドBeanの使用」の説明に従って、そのコンポーネントを含むページのマネージドBeanを作成します。

マネージドBeanおよびJSFページのバッキングBeanとしてのマネージドBeanの使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のマネージドBeanの作成と使用に関する項を参照してください。

2. 変更に使用されるコンポーネントのイベント・ハンドラ・メソッドに、コードを追加します。このコードは、変更を含むコンポーネントを取得する必要があります。その後、このコンポーネントと適切なAPIを使用して、変更内容を作成し、記録して、永続させます。

次の例は、MDSリポジトリに対して永続化する変更のための、コマンド・ボタンのアクション・イベント・ハンドラのコードを示しています。ユーザーがボタンをクリックすると、ソース・グラフィック・ファイルが変更されます。イベント・ハンドラ・メソッドはコンポーネントにアクセスして、グラフィックのソース属性を変更します。その後、addAttributeChangeプライベート・メソッドを呼び出します。このメソッドは、まずコンポーネントAPIを使用して変更内容を記録し、次にAttributeComponentChangeクラスを使用して新しいソース属性値を設定します。

public void modifyObjectImage(ActionEvent event) {
UIComponent uic = event.getComponent().findComponent("oi1");
String source = "/images/mediumAd.gif";
uic.getAttributes().put("source", source);
_addAttributeChange(uic, "source", source);
}
. . .
private static void _addAttributeChange(UIComponent uic, String attribName,
Object attribValue) {
FacesContext fc = FacesContext.getCurrentInstance();
ChangeManager cm =
RequestContext.getCurrentInstance().getChangeManager();
ComponentChange cc =
new AttributeComponentChange(attribName, attribValue);
cm.addComponentChange(fc, uic, cc);
}

注意:

変更内容を永続化する場合、コンポーネントの変更を明示的に記録する以外に(上の例でuic.getAttributes().put("source", source)を使用して行っています)、_addAttributeChange(uic, "source", source)プライベート・メソッドを使用して行ったように、コンポーネントAPIを使用して変更を直接適用する必要があります。この方法で変更を適用することで、ユーザーは同一リクエストに応じた変更を確認できます。コンポーネントで変更が記録される場合、次のリクエストまで変更は表示されません。

さらに、制限された変更永続性設定に関係なく、コンポーネントが常にリポジトリに永続されることがわかっている場合、かわりにAdfFacesContext.getCurrentInstance(). getPersistentChangeManager()メソッドを呼び出すことができます。

3. ChangeManagerクラスでは、AttributeComponentChangeからAttributeDocumentChangeへの自動変換がサポートされ、これにより、リポジトリへの永続が可能になります。ただし、別のタイプの変更を変換する必要があり、DocumentChangeクラスを実装しない専用の変更マネージャ・クラスを使用する場合は、コンポーネント変更をドキュメント変更に変換するDocumentFactoryカスタム実装を作成する必要があります。

注意:

AttributeComponentChangeからAttributeDocumentChangeへの自動変換では、コンポーネント属性は、JSPXドキュメントの関連する要素で同じ名前の属性として表されることを前提とします。

JSPXドキュメントで表すことのできる属性値のみ、AttributeDocumentChangeを使用して永続できます。つまり、サポートされるデータ型は、CharSequence、Number、BooleanおよびValueExpressionのみです。

java.io.Serializableを実装する値のみ、AttributeComponentChangeを使用して永続できます。

4. DocumentFactoryカスタム実装を作成した場合、beanで次のメソッドを使用して、適切な変更マネージャ・クラスに登録する必要があります。

public static void registerDocumentFactory(String targetClassName,
String converterClassName)

targetClassNameはComponentChangeクラスの名前で、converterClassNameはターゲットのComponentChangeをDocumentChangeに変換できるDocumentChangeFactory拡張の名前です。これらのクラスのnameのセマンティックスは、java.lang.ClassクラスのgetName()のものと同じです。

5. コンポーネント変更の作成に使用するクラスでコンポーネントのサブツリーを持つ子が追加され、変更をリポジトリに永続させる場合、変更を表すDocumentFragmentを作成する必要があります。

次の例は、AddComponentDocumentChange専用クラスを使用してDocumentChangeオブジェクトを作成し、DocumentFragmentを使用して変更を表す方法を示しています。

public void appendChildToDocument(ActionEvent event)
{
UIComponent eventSource = event.getComponent();
UIComponent uic = eventSource.findComponent("pg1");
// only allow the image to be added once
if (_findChildById(uic,"oi3") != null)
return;
FacesContext fc = FacesContext.getCurrentInstance();
DocumentFragment imageFragment = _createDocumentFragment(_IMAGE_MARK_UP);
DocumentChange change = new AddChildDocumentChange(imageFragment);
ChangeManager apm = RequestContext.getCurrentInstance().getChangeManager();
apm.addDocumentChange(fc, uic, change);
}
private static final String _IMAGE_MARK_UP =
"<af:objectImage id='oi3' height='100' width='120' " +
"source='http://www.somewhere.com/someimage.jpg' " +
"xmlns:af='http://xmlns.oracle.com/adf/faces'/>";

private static DocumentFragment _createDocumentFragment(
String markUp)
{
// prepend XML declaration
markUp = "<?xml version = '1.0' encoding = 'ISO-8859-1'?>" + markUp;
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
factory.setValidating(false);
DocumentBuilder builder;
try
{
builder = factory.newDocumentBuilder();
}
catch (ParserConfigurationException pce)
{
_LOG.log(Level.WARNING, "Unable to get XML Parser:", pce);
return null;
}
try
{
// use a version explicitly with ISO-8859-1 instead
byte[] markupBytes = markUp.getBytes();
Document newDoc = builder.parse(new ByteArrayInputStream(markupBytes));
DocumentFragment fragment = newDoc.createDocumentFragment();
// add the document's root element to the fragment
fragment.appendChild(newDoc.getDocumentElement());
return fragment;
}
catch (SAXException se)
{
_LOG.log(Level.WARNING, "Unable to parse markup:" + markUp, se);
return null;
}
catch (IOException ioe)
{
_LOG.log(Level.WARNING, "IO Problem with markup:" + markUp, ioe);
return null;
}
}

6. 「ユーザー・カスタマイズの構成」に記載されているように、ユーザー・カスタマイズをadf-config.xmlファイルに登録します。カスタムの変更がAttributeDocumentChange以外のタイプである場合は、次の例に示すように、adf-config.xmlファイルを手動で編集して、すべての変更内容をコンポーネントで許可することを示す必要があります。

<tag name="inputText">
<attribute name="label">
<persist-changes>true</persist-changes>
</attribute>
<persist-operations>ALL</persist-operations>
</tag>

52.6 カスタム・コンポーネントでの暗黙的な変更永続性の作成

カスタム・コンポーネントを作成する際、アプリケーションで変更永続性が使用可能な場合に、そのコンポーネントの特定の属性値を永続させるように指定できます。カスタム・コンポーネントでの暗黙的な変更の設定は、既存のコンポーネントでの明示的な変更永続性の設定と似ています。実際の永続化を実行するコードを追加しますが、そのコードをマネージドbeanに置くかわりに、コンポーネント・クラスで直接そのコードを処理することができます。イベントを使用してコンポーネントの属性値とサーバーが同期されている場合、ブロードキャスト・メソッドを使用して変更を永続させることができます。永続させる属性値がイベントを使用しない場合、レンダラとコンポーネント・クラスにコードを追加する必要があります。

52.6.1 イベントを使用する属性値への暗黙的な変更永続性の設定方法

属性値がイベントを使用する場合、コンポーネント・クラスにコードを追加する必要があります。

始める前に:

カスタム・コンポーネントでの永続性の実装方法に関する知識が役立つ場合があります。詳細は、「カスタム・コンポーネントでの暗黙的な変更永続性の作成」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。

Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開く必要があります。

イベントを使用する属性値に暗黙的な変更永続性を設定するには:

1. 「アプリケーション」ウィンドウで、カスタム・コンポーネント・クラスのJavaファイルをダブルクリックします。

2. ブロードキャスト・メソッドに、専用クラスを使用して新規ComponentChangeオブジェクトを作成し、ChangeManagerを呼び出して変更を追加するコードを追加します。

次の例は、UIXShowDetailクラスに追加された、disclosed属性の変更を永続化するコードを示しています。この場合、AttributeComponentChangeクラスが使用されます。

public class UIXShowDetail extends UIXComponentBase
{
...
public void broadcast(FacesEvent event) throws AbortProcessingException
{
super.broadcast(event);
...
if (event instanceof DisclosureEvent)
{
boolean isDisclosed = ((DisclosureEvent) event).isExpanded();
setDisclosed(isDisclosed);
//Record a Change for 'disclosed' attribute
AttributeComponentChange aa =
new AttributeComponentChange('disclosed', isDisclosed ? Boolean.TRUE : Boolean.FALSE);
AdfFacesContext adfContext = AdfFacesContext.getCurrentInstance();
adfContext.getChangeManager().addComponentChange(getFacesContext(), this, aa);
...
}
}
...

52.6.2 他の属性値への暗黙的な変更永続性の設定方法

属性がイベントを使用しない場合、コードをコンポーネントのレンダラ・クラスに配置する必要があります。

始める前に:

カスタム・コンポーネントでの永続性の実装方法に関する知識が役立つ場合があります。詳細は、「カスタム・コンポーネントでの暗黙的な変更永続性の作成」を参照してください。

アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。

Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開く必要があります。

他の属性値に暗黙的な変更永続性を設定するには:

1. 「アプリケーション」ウィンドウで、カスタム・コンポーネントのレンダラ・クラスのJavaファイルをダブルクリックします。

2. ClientMetadataインスタンスをとるfindTypeConstantsメソッドを使用し、addPersistedPropertyメソッドを使用して特定のプロパティを永続とマークします。次の例は、ADF Faces PanelSplitterコンポーネントで使用されるレンダラ・クラスのコードを示しています。ここでは、splitterPosition属性値が暗黙的に永続化されます。

// Code from PanelSplitterRenderer.java
protected void findTypeConstants(
FacesBean.Type type,
ClientMetadata metadata)
{
super.findTypeConstants(type, metadata);
metadata.addRequiredProperty(
_orientationKey = type.findKey("orientation"));
metadata.addRequiredProperty(
_positionedFromEndKey = type.findKey("positionedFromEnd"));
metadata.addRequiredProperty(
_disabledKey = type.findKey("disabled"));
metadata.addRequiredProperty(
_splitterPositionKey = type.findKey("splitterPosition"));
metadata.addPersistedProperty(_splitterPositionKey);
}

3. JavaScriptコンポーネント・ピア・クラスで、setProperty関数を使用して永続させる属性値を定義します。この関数は、属性名(前の手順でレンダラで定義した)、値およびtrueを使用して呼び出す必要があります。これにより、属性の値が設定されます。次の例は、スプリッタの位置を設定するpanelSplitterクラスのコードを示しています。

// Code from AdfDhtmlPanelSplitterPeer.js file where we set the
splitter position

var component = this.getComponent();
component.setProperty("splitterPosition",position, true);
// position is the value to be set

53 アクティブ・データ・サービスの使用

この章では、ADF Facesコンポーネントに対してリアルタイムの更新を行うための、ADFモデル・レイヤーとアクティブ・データ・サービス(ADS)の操作方法について説明します。

この章の内容は次のとおりです。

- アクティブ・データ・サービスについて

- アクティブ・データ・サービスの構成

- アクティブ・データ・サービスの使用に向けたコンポーネントの構成

- アクティブ・データ・プロキシの使用

- 読取り一貫性の維持に関する必知事項

- アクティブ・データとスカラー・モデルの併用

53.1 アクティブ・データ・サービスについて

Fusionテクノロジ・スタックにはアクティブ・データ・サービス(ADS)が含まれます。これは、ADF Facesコンポーネントに対してリアルタイムでデータ更新を提供するためのサーバー側のプッシュ・フレームワークです。ADF Facesコンポーネントをデータ・ソースにバインドすると、ADSでは、ブラウザ・クライアントに明示的な更新リクエストを要求することなく、ブラウザ・クライアントにデータ更新をプッシュします。たとえば、ADFデータ・コントロールの属性にバインドされた表があり、その属性値はサーバー上で定期的に変化するため、表には更新された値が表示されるようにします。サーバー上でデータが変更されたときには必ず、ADFモデル・レイヤーがコンポーネントに通知し、コンポーネントが変更後のデータを再レンダリングして、新しくなった値をハイライトするように(図53-1参照)アプリケーションとコンポーネントを構成できます。

図53-1 更新されたデータを強調表示で示す表

53.1.1 アクティブ・データ・サービスのユースケースおよび例

ADF FacesコンポーネントにバインドされているADFデータ・コントロールに関連付けられたビジネス・ロジックの結果として、バックエンドで変化するデータをレンダリングするには、自動部分ページ・レンダリング(PPR)のかわりにADSを使用します。自動PPRでは(通常、ユーザーが)サーバーに要求を送信する必要がありますが、ADSは、変更されたデータがサーバーに到着したときに、このデータをデータ・ストアからプッシュできるようにします。また、PPRとは対照的に、ADSにより、コンポーネントはコンポーネント全体ではなく、変更されたデータのみをレンダリングできるようになります。したがって、アプリケーションが、定期的に変化するデータに対応する必要がある場合にはADSが理想的です。

この機能を使用するには、ADSを使用するようにアプリケーションを構成する必要があります。アプリケーション・サービスがADSをサポートしていない場合は、サービスのプロキシを作成して、データがソースで更新されたときに、コンポーネントがこのデータを表示できるようにする必要もあります。

どのADF FacesページでもADSを使用できます。ただし、アクティブ・データを処理するように構成できるのは、次のADF FacesコンポーネントおよびADFデータ視覚化(DVT)コンポーネントのみです。

- activeImage

- activeOutputText

- chart (すべてのタイプ)

- gauge (すべてのタイプ)

- pivotTable

- tree

- treeTable

- geoMap (mapPointThemeのみ)

- sunburst

- treemap

DVTコンポーネントのADSサポートの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のアクティブ・データのサポートに関する項を参照してください。

また、コレクションベースのコンポーネント(table、tree、pivotTableなど)は、outputTextコンポーネントまたはsparkChartがアクティブ・データを表示するように構成されている場合にのみADSをサポートします。その他のコンポーネントは、コレクションベース・コンポーネントの内部でサポートされません。

53.1.2 アクティブ・データ・サービス・フレームワークの制限

ADS対応フレームワークの制限事項は次のとおりです。

- ADSは、フィルタリングが有効化されているADF Faces表コンポーネントのアクティブ・データをサポートしません。実行時に表をフィルタリングすると、アクティブ・データは表示されません。

- ADSは、デフォルトでは、ユーザーの非アクティブ状態によってタイムアウトしません。アクティブ・セッションが無期限に維持されないように、web.xml context-parameter oracle.adf.view.rich.poll.TIMEOUTを構成し、ユーザーが非アクティブになってからタイムアウトするまでのADSの実行時間を指定できます。詳細は、「アクティブ・データ・サービスのセッション・タイムアウトの構成方法」を参照してください。

- ユーザーがブラウザ・ページから移動しようとし、ブラウザによって表示された警告ダイアログで終了アクションを取り消してそのページに留まった場合、ADSは再起動しません。この制限を回避するために、ADF Facesでは、ページ終了時の確認ダイアログの表示をサポートするブラウザのbeforeunloadイベントを処理するクライアント・リスナーをサポートしています。このイベントを処理するADFドキュメントでは、ユーザーはADSによって処理が停止される前に終了を取り消すことができます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のADS対応ページからの移動に関する必知事項に関する項を参照してください。

- ADSは非リクエスト・スレッド上で実行し、コンポーネントレベルEL式の強制実行はサポートしていません。そのため、ADF Facesコンポーネント上でコンポーネント・プロパティ(アクティブ・データを使用して構成されたチャートの塗りつぶし色など)を計算するためにEL式を使用している場合、それらの式はADSによるコンポーネント値の更新時に実行されません。このようなシナリオでELを実行するには、モデル内でプロパティ値を計算し、ELを使用してそのモデルにコンポーネント・プロパティをバインドします。またはページにJavaScriptをインラインで適用し、アクティブ・データの更新が発生した後にプロパティ値の変更が適用されるようにします。後者のソリューションを使用するとADF Facesでコンポーネントを効率よくレンダリングできます。

注意:

ADF DVTコンポーネントによって追加の制限が適用される場合があります。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のアクティブ・データのサポートに関する項を参照してください。

53.1.3 アクティブ・データ・サービス・フレームワーク

ADSのフレームワークには、ソースからUIコンポーネントにアクティブ・データを送信するために提携しあう、多数のコンポーネントが含まれます。データ・イベントが発生したとき、関連するADFモデル・レイヤー・バインディングがアクティブ・データ用に構成されている場合、アクティブ・データ・モデルにより、データがイベント・マネージャに配信されます。その後、イベント・マネージャはデータを取得してプッシュ・サービスを起動し、このデータは、プッシュ・サービスによって、その構成内容(詳細は「データ・トランスポート・モード」を参照)に基づいて適切なコンポーネントに配信されます。その後、このコンポーネントはサーバーからプッシュされた新しいデータを適用します。図53-2に、ADSフレームワークを示します。

図53-2 アクティブ・データ・サービスのフレームワーク

アクティブ・データ・サービスを使用するには、データが変化したときにイベントを公開するデータ・ストアが必要です。また、このようなイベントに反応するビジネス・サービスを作成する必要もあります。デフォルトでは、ADFビジネス・コンポーネントは、データ・イベントには反応しません。アクティブ・データ・プロキシ・フレームワークでは、ADFビジネス・コンポーネントを含むあらゆるタイプのデータ・ソースとADSを提携させることができます。このフレームワークはActiveDataModelをJSFモデルと組み合せます。したがって、ActiveDataModelとJSFモデルの両方ではなく、このプロキシのみの機能をオーバーライドする必要があります。

ADSフレームワークは次のアイテムにより構成されています。

- ActiveDataModelインタフェース: アクティブ・データ・モデルを抽象化したもの。その役割は次のとおりです。

- アクティブ・データの開始と停止

- 現在のアクティブ・データのイベントIDを追跡

- モデルがアクティブ・データを必要としているかどうかをレンダラに通知

- イベント・マネージャ: ADFモデル・レイヤーと提携するサーバー側コンポーネント。次の役割があります。

- バインディング・イベントのリスニング

- アクティブ・データの取得

- アクティブ・データ・エンコーディングの管理

- エンコード済みアクティブ・データを送信するためにプッシュ・サービスを起動

- プッシュ・サービス: 配信チャネルの1つで、サーバー側のイベント・マネージャ、およびクライアント側のアクティブ・データ・マネージャと対話します。その機能は次のとおりです。

- サーバーとクライアントの間の接続を確立し維持

- サーバーからクライアントへ、この接続を経由してアクティブ・データを転送

- 望ましいパラメータの範囲内でアクティブ・データが配信されることを保証し、配信されない場合はコンポーネントの更新を強行

- アクティブ・データ・マネージャ: クライアント側コンポーネントの1つで、アクティブ・データを適切なコンポーネントに配信します。特に次の役割があります。

- チャネル経由でサーバー側からやってきたイベントを、イベント配信サービスを使用して配信

- 共有チャネルを通じて複数のブラウザ・ウィンドウに対応

- コンポーネントが変更を適宜、レンダリングできるように、リッチ・クライアント・コンポーネントにアクティブ・データ・イベントをディスパッチ

- アクティブ・データ・プロキシ: すべてのタイプのデータ・ソースがプッシュ機能を有効化できるようにするプロキシプロキシには特に次のような役割があります。

- ActiveDataModel機能の実装と委譲

- JSFモデルへの委譲

- データ・ソースからデータ変更イベントをリスニング

- データ変更イベントに基づいてアクティブ・データ・イベントを生成

53.1.4 データ・トランスポート・モード

アクティブ・データは、データ・ストリーミング(プッシュ)、または2種類のデータ・ポーリングのいずれか1つを用いて、クライアントに送信されます。データ・ストリーミングを使用する場合、リクエストは1つのみで、これは開かれたままになります。データ変更イベントが発生した場合、部分的な応答が送信され(この応答はクローズされない)、クライアントに通知が送られて、関連するコンポーネントが更新されて、新しいデータが表示されます(図53-3を参照)。

図53-3 ストリーミング・モード

データ・ポーリングでは、アプリケーションは指定された間隔でデータソースをポーリングするように構成されています(図53-4を参照)。データ変更イベントが発生したかどうかに関係なく、応答は要求ごとに送信され、閉じられます。データが変更された場合は、クライアントに通知が送られ、コンポーネントが更新されます。

図53-4 ポーリング・モード

ロング・ポーリングはストリーミングに似ています。ページがレンダリングされるとき、アクティブ・チャネルに要求が送信されます。しかし、データ変更イベントが発生するまで、応答は返されません。このイベントが発生した時点で、接続が閉じられます。接続が閉じられると同時に、新しい接続が開始されます。これにより、ほとんど常時接続されていることになります。特定のインターバルはありません。ロング・ポーリングの結果、データ変更イベントが起きたときに、その大半が受信されます。これは、接続が常時確立され、クライアントに応答を送信できる体制が整っているからです(図53-5参照)。

図53-5 ロング・ポーリング・モード

詳細は、「ADSトランスポート・モードの構成に関する必知事項」を参照してください。

ADSを使用するには、アプリケーションを構成して、データ・トランスポート方法などのパフォーマンス・オプションを決定する必要があります。また、コンポーネントがADSを使用できるように、コンポーネントのバインディングを構成する必要もあります。ADFビジネス・コンポーネントを使用している場合、アクティブ・データ・プロキシを使用し、アクティブ・データ・イベントのリスナーとしてモデル自身を登録するために、ActiveModelインタフェースを実装するようにモデルを修正する必要があります。

ヒント:

OracleのOracle Business Activity Monitoring (BAM)は、アクティブ・データ・ストアを作成する能力を提供する完成されたソリューションです。詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。

53.2 アクティブ・データ・サービスの構成

データ・トランスポート・モードを決定すると同時に、待機しきい値や再接続情報など、その他の構成を行うようにADSを構成する必要があります。

注意:

ADSを有効化したが、ADSの構成は済んでいない場合、ADSフレームワークでは表53-1に示すデフォルト値が使用されます。

53.2.1 アクティブ・データ・サービスの構成方法

JDeveloperおよび統合WebLogic ServerでADSを使ってFusion Webアプリケーションを実行するための構成は、adf-config.xmlファイルで行われます。必要な場合の作成方法を含む、adf-config.xmlファイルの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のadf-config.xmlでの構成に関する項を参照してください。

注意:

クラスタ環境内のWebアプリケーションに対して自動的なレプリケーションとフェイルオーバーをサポートするために、Oracle WebLogic Serverは、クラスタ間でHTTPセッションの状態をレプリケートするメカニズムをサポートしています。Oracle Application Development Framework (Oracle ADF)を構成して、Fusion Webアプリケーションの状態をサーバーからクラスタにリストアできます。アクティブ・データを表示するように構成されているページに対してフェイルオーバーをサポートするには、ADFビジネス・コンポーネント・アプリケーション・モジュールのフェイルオーバーを有効にし、ADF ControllerがADFメモリー・スコープへの変更を追跡できるようにする必要があります。これらのADF設定を構成すると、フェイルオーバーの発生時にADFサーバーがフェイルオーバーを検出し、アクティブ・データを表示するように構成されているすべてのページに対し、ページをリフレッシュするように要求します。その後でADSが再起動し、データがクライアントにプッシュされます。高可用性環境でFusion Webアプリケーションのフェイルオーバーを有効にする方法の詳細は、『高可用性ガイド』を参照してください。

始める前に:

ADS構成の選択項目に関する知識が役立つ場合があります。詳細は、「アクティブ・データ・サービスの構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アクティブ・データ・サービスについて」を参照してください。

アクティブ・データ・サービスを構成するには:

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF Meta-INF」ノードを開いて、adf-config.xmlをダブルクリックします。

2. 「ソース」タブをクリックして、ソース・エディタでこのファイルを開き、表53-1に示す要素1つにつき1個のエントリを作成します。

表53-1 adf-config.xmlのADS構成要素

要素

説明

デフォルト値(ミリ秒)

最小値(ミリ秒)

<transport>

データがクライアントに送信される方法。値は次のとおりです。

- streaming (デフォルト)

- polling

- long-polling

詳細は、「ADSトランスポート・モードの構成に関する必知事項」を参照してください。

<latency threshold>

待機しきい値(ミリ秒単位)。このしきい値よりもネットワーク遅延が大きいアクティブなデータ・メッセージは遅延とみなされます。

10000

1000

<keep-alive-interval>

イベントが生成されていないときに、キープアライブ・メッセージを送信する頻度(ミリ秒単位)。

10000

5000

<polling-interval>

<transport>がpollingに設定されている場合は、ポーリング要求の間隔(単位はミリ秒)。

5000

1000

<max-reconnect-attempt-time>

クライアントが接続を切断された場合に、サーバーへのプッシュ・チャンネルの再接続の試行を続ける最大期間(ミリ秒単位)。

1800000 (30分)

0

<reconnect-wait-time>

再接続の試行の間の間隔(ミリ秒単位)。

10000

1000

パフォーマンスに関するヒント

ADSを構成するときには、次の点に注意してください。

- コンポーネントが頻繁にリフレッシュされるのを回避するには、待機しきい値には1000を超える値を設定します。

- キープアライブ間隔と再接続待機時間には、ブラウザのキープアライブ・タイムアウト未満の値を設定します。

- 再接続時間の上限には、Webサーバーのセッション・タイムアウト未満の値を設定します。

次の例は、クライアントにプッシュされたコンテンツを持つサンプル構成を示しています。

<?xml version="1.0" encoding="utf-8" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:ads="http://xmlns.oracle.com/adf/activedata/config">
<ads:adf-activedata-config xmlns=
"http://xmlns.oracle.com/adf/activedata/config">
<transport>streaming</transport>
<latency-threshold>5000</latency-threshold>
<keep-alive-interval>10000</keep-alive-interval>
<max-reconnect-attempt-time>90000</max-reconnect-attempt-time>
<reconnect-wait-time>8000</reconnect-wait-time>
</ads:adf-activedata-config>
</adf-config>

3. データ・サーバーのクロックとアプリケーション・サーバーのクロックを同期します。これらが同期されていない場合、ADSはイベントが未来に発生するものと解釈する可能性があります。

53.2.2 ADSトランスポート・モードの構成に関する必知事項

ADSは3種類のトランスポート・モード(ストリーミング、ポーリング、またはロング・ポーリング)の1つを使用していコンポーネントにアクティブ・データを配信します。

ストリーミング・モードを使用するようにADSを構成すると、データにより変更イベントが発生するたびに、このデータがクライアントにプッシュされます。クライアント側では、プッシュ・チャネルの確立後、latency-threshold要素とkeep-alive-interval要素の合計時間以内にアクティビティが何も発生しなかった場合、reconnect-wait-time要素の値に基づいて、経過時間がmax-reconnect-attempt-time要素の値に到達するまで、establish-channel-requestが繰り返し送信されます。その後、接続は切断されているものとみなされます。たとえば、「アクティブ・データ・サービスの構成方法」に示された値が指定されている場合、15,000ミリ秒間にアクティビティが発生しないと、チャネルの確立要求が、8,000ミリ秒間隔で最高90,000ミリ秒間送信されます。その後、接続は切断されているものとみなされます。

サーバー側では、サーバーにより、プッシュ・チャネルが切断され、空のアクティブ・データ・メッセージがある、またはアクティブ・データ・メッセージの送信に失敗したときに、cleanup-delay-timeを使ってクリーンアップするためのタイマーが起動されます。cleanup-delay-timeは、max-reconnect-attempt-time + 30 × 1000 msの式で求められます。デフォルト値は30分です。

ポーリング・モードを使用するようにADSを構成すると、クライアント側では、polling-interval要素の値に達した後で、ポーリング要求を繰り返し送信するようにスケジュールが設定されます。max-reconnect-attempt-timeだけの時間が経過しても応答が得られない場合、接続は切断されているものとして扱われ、それ以上、要求は送信されません。ポーリング応答の受信後、応答にかかった時間がpolling-interval要素を超える場合、サービスは次の要求を即座に送信します。超えていない場合、次の要求はスケジュールどおり送信されます。

サーバー側では、ポーリング応答が返された後で、セッションが終了します。その時点で、クリーンアップをトリガーするために、cleanup-delay-timeを使ったタイマーが設定されます。このタイマーの起動前に新しい要求が到着した場合、古いタイマーはキャンセルされ、新しいタイマーが作成されます。

ロング・ポーリング・モードを使用するようにADSを構成した場合、要求はストリーミング・モードと同じように行われます。ただし、接続が切断と判断されると同時に、新しい接続が開始されます。その結果、待機時間が大幅に短縮されます。

表53-2はこれら3種類のモードを比較したものです。

表53-2 ストリーミング、ポーリングおよびロング・ポーリング・モードの比較

比較ベンチマーク

ストリーミング

ポーリング

ロング・ポーリング

待機時間

非常に良好。

サーバー側でイベントが発生した直後、クライアントに部分的な応答が送信される。別のイベントが発生した場合も、即座に部分的な応答が送信される。このアプローチには待機時間はほとんどない。

よくない(ただし、ポーリング間隔による)。

ポーリング間隔が短い(たとえば、0.5秒)場合、接続が繰り返し開かれるため、ネットワークの速度が低下する原因となる。また、クライアント側リソースおよびサーバー側リソースが大量に消費される。

よい。

ただし、応答がクローズされた直後に新しいイベントが発生したとき、新しいデータがクライアント側に現れるまでに多少の待機時間を要する。ほとんどの場合、これは問題にはならない。

HTTPプロキシ

よくない。

一部の古いサーバーでは応答が絶対にリリースされないため、クライアントとサーバーの間にプロキシが存在するとき、このプロキシが応答をバッファする可能性がある。

これはリアルタイムのデータがブラウザに流入することを妨げる、不適切な最適化である。プロキシを使用している場合は、ロング・ポーリングを使用すべきである。

よい。

よい。

ライブ接続数

よくない。

ストリームが常に有効であるため、多数の接続が同時に存在する。

よい。

接続は、実際のポーリング中のみ有効である。ただし、ポーリング・レートが高い場合、同時接続数も増えますので注意してください。

よくない。

ストリームがほとんど常に有効であるため、多数の接続が同時に存在する。

通信チャネル

HTTP GET

この結果、ビジー・カーソル、またはブラウザのスロバー・アイコンのアニメーションが表示される。

XMLHttpRequest (XHR)

HTTP GET

XMLHttpRequest (XHR)

HTTP GET

53.2.3 アクティブ・データ・サービスのセッション・タイムアウトの構成方法

デフォルトでは、ADSを使用する構成のアプリケーションはタイムアウトしません。ポーリング・モードでは、クライアントがサーバーにポーリング要求を定期的に送信します。ロング・ポーリング・モードでは、サーバーからポーリング要求が返されると、即座にクライアントが新しいポーリング要求を送信します。ストリーミング・モードでは、 サーバーがGETリクエスト・レスポンスを保持し、アクティブ・データを無期限に書き込みます。各データ・トランスポート・モードの動作のために、ユーザーがアプリケーションと対話しているかどうかにかかわらず、ADSはアプリケーション・セッションをアクティブに維持します。

ADSのためにアクティブ・セッションが無期限に維持されるこの状況を防止するために、web.xml構成ファイルには、ユーザーが非アクティブになってからタイムアウトするまでのADSの実行時間を指定するoracle.adf.view.rich.poll.TIMEOUTコンテキスト・パラメータが含まれています。キーボードまたはマウスのアクティビティがない場合、ADSクライアントはタイムアウトできるとみなされます。デフォルトのタイムアウト時間は10分です。このため、ユーザーのアクティビティが10分間ない場合(キーボードやマウスを使用しない時間)は、ADSはポーリングを停止するかサーバーとの接続を中断し、その時点から、アプリケーションは標準のサーバー側セッション・タイムアウトに入ります。たとえば、サーバー側セッション・タイムアウトが65分で、ポーリング・タイムアウト・パラメータが15分に設定されている場合、ユーザーが非アクティブな状態が80分を超えると、セッションのタイムアウト期限が切れることになります。

ADF Facesポーリング・コンポーネントのtimeout属性を使用して、特定のWebページでこのタイムアウト設定をオーバーライドできます。ポーリング・コンポーネントを使用して、サーバーにハートビートを配信して、特定のページでそれらのセッションがタイムアウトするのを防ぐことができます。oracle.adf.view.rich.poll.TIMEOUTコンテキスト・パラメータと個々のWebページの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のポーリング・イベントを使用したページの更新に関する項を参照してください。

始める前に:

ADS構成の選択項目に関する知識が役立つ場合があります。詳細は、「アクティブ・データ・サービスの構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アクティブ・データ・サービスについて」を参照してください。

セッションが非アクティブになったらタイムアウトするようにアクティブ・データ・サービスを構成するには:

1. 「アプリケーション」ウィンドウのユーザー・インタフェース・プロジェクトで、「Webコンテンツ」→「WEB-INF」ノードを開き、web.xmlをダブルクリックします。

2. web.xmlファイルの概要エディタで、「アプリケーション」ナビゲーション・タブをクリックし、「コンテキスト初期化パラメータ」セクションで「作成」アイコンをクリックして、次のようにポーリング・タイムアウト・パラメータを追加します。

名前: コンテキスト・パラメータoracle.adf.view.rich.poll.TIMEOUTを入力します。

値: アクティブ・データを使用するように構成されたすべてのページがタイムアウトしてADSが停止するまでの経過時間(ミリ秒)を入力します。ユーザーが非アクティブ状態であることによるADFのタイムアウトを無効にするには、-1を入力します。ADSのタイムアウトのデフォルト値は、600000ミリ秒(10分)です。

53.3 アクティブ・データ・サービスの使用に向けたコンポーネントの構成

ADSの使用に向けてコンポーネントを構成する方法は、アクティブ・データ・プロキシを使用する必要があるかどうかによって異なります。データが変更されたときにイベントを公開するデータ・ストアをアプリケーションが使用しているときに、ビジネス・サービスがこのようなイベントに反応する(たとえば、アプリケーションがBAMを使用している)場合、アクティブ・データ・プロキシを使用する必要はありません。

ビジネス・サービスがこれらのイベントに反応しない(たとえば、アプリケーションがADFビジネス・コンポーネントを使用している)場合は、アクティブ・データ・プロキシを使用し、別の手順に従って、コンポーネントを構成する必要があります。

注意:

ビジネス・サービスでアクティブ・データ・プロキシを使用する必要がある場合、アクティブ・データとともに使用できるのは次のコンポーネントのみです。

- table

- tree

- treeTable

- ADFデータ視覚化コンポーネント(chart、gauge、mapPointTheme、pivotTable、pivotFilterBar、sunburst、treemap)

53.3.1 アクティブ・データ・プロキシを使わずに、アクティブ・データ・サービスの使用に向けたコンポーネントを構成する方法

プロキシを使わずにADSを使用するには、対応するページ定義ファイルでバインディング要素に値を設定する必要があります。

始める前に:

ADS構成の選択項目に関する知識が役立つ場合があります。詳細は、「アクティブ・データ・サービスの使用に向けたコンポーネントの構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アクティブ・データ・サービスについて」を参照してください。

アクティブ・データ・プロキシを使わずに、アクティブ・データを表示するコンポーネントを構成するには:

1. 「データ・コントロール」パネルからコレクションをJSFページにドラッグ・アンド・ドロップし、ポップアップ・メニューから目的のコンポーネントを選択します。

2. コレクションをADFバインド・ツリーまたはツリー表としてドロップする場合は、次のことを確認する必要があります。

- アクセッサが依然として、似たようなアクセッサにアクセスしているとしても、バインディングが同種のデータ(つまり、ルールは1つのみ)を表していること。

- バインディング・ルールに含まれる属性は1つであること。

- 表でフィルタを使用しないこと。

- 「ADFツリーでのアクティブ・データの表示に関する必知事項」で説明するように、ツリー・コンポーネントのnodeStampファセットにあるのはoutputTextタグ1つのみで、それ以外のタグは含まれていないこと。

3. 「アプリケーション」ウィンドウで、ページを右クリックし、「ページ定義に移動」を選択します。

選択したページに対するページ定義ファイルのエディタが開きます。

4. 「構造」ウィンドウで、コンポーネントにバインドされた属性を表すノードを選択します。

5. 「プロパティ」ウィンドウで、「詳細」セクションを開き、ChangeEventPolicyドロップダウン・メニューから「プッシュ」を選択します。

ヒント:

サーバーの状態を示すために、statusIndicatorコンポーネントを使用できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のアイコンを使用したアプリケーション・ステータスの表示に関する項を参照してください。

53.3.2 アクティブ・データ・プロキシを使ったアクティブ・データ・サービスの使用に向けたコンポーネントを構成する方法

プロキシとADSを併用するには、コンポーネントの値と、このプロキシを使用するデコレータ・クラスをバインドする必要があります。対応するページ定義ファイルでバインディング要素に値を設定するには、「アクティブ・データ・プロキシの使用」でこのクラスの詳細を参照してください。

始める前に:

ADS構成の選択項目に関する知識が役立つ場合があります。詳細は、「アクティブ・データ・サービスの使用に向けたコンポーネントの構成」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アクティブ・データ・サービスについて」を参照してください。

アクティブ・データ・プロキシを使って、アクティブ・データを表示するコンポーネントを構成するには:

1. 「データ・コントロール」パネルからコレクションをJSFページにドラッグ・アンド・ドロップし、ポップアップ・メニューから目的のコンポーネントを選択します。

2. ADFバインド・ツリー、またはツリー表を使用している場合は、次の点を確認する必要があります。

- アクセッサが依然として、似たようなアクセッサにアクセスしているとしても、バインディングが同種のデータ(つまり、ルールは1つのみ)を表していること。

- バインディング・ルールに含まれる属性は1つであること。

- 表でフィルタを使用しないこと。

- 「ADFツリーでのアクティブ・データの表示に関する必知事項」で説明するように、ツリー・コンポーネントのnodeStampファセットにあるのはoutputTextタグ1つのみで、それ以外のタグは含まれていないこと。

3. 「アプリケーション」ウィンドウで、ページを右クリックし、「ページ定義に移動」を選択します。

選択したページに対するページ定義ファイルのエディタが開きます。

4. 「構造」ウィンドウで、コンポーネントにバインドされた属性を表すノードを選択します。

5. 「プロパティ」ウィンドウで、プロキシで使用するために作成するデコレータ・クラスにバインドされる値の属性を変更します。

詳細は、「アクティブ・データ・プロキシの使用」を参照してください。

53.3.3 ADFツリーでのアクティブ・データの表示に関する必知事項

ADF Facesツリー(または、ツリー表)コンポーネントを作成するときには、nodeStampファセットを構成します。これはツリーの各ノードのデータを表示するために使用されるコンポーネントのホルダーです。各ノードが一度ずつ、すべてのノードで繰り返しレンダリング(スタンプ設定)されます。

このスタンプ設定動作のため、ADF Facesツリー・コンポーネントで子としてサポートされるのは、特定タイプのコンポーネントのみです。ツリー・コンポーネントがアクティブ・データ・ソースにバインドされていない場合、動作を持たないコンポーネントがすべてサポートされます。ただし、ADSを使用するツリーを構成する場合、次の例に示すとおり、nodeStampファセット内ではoutputTextコンポーネントのみがサポートされます。nodeStampファセットには他のタグが含まれていてはいけません。したがって、たとえば、ADSを使用するように構成されたツリーのnodeStampファセットにpanelGroupLayoutタグを追加した場合、アクティブ・データは機能しません。

<f:facet name="nodeStamp">
<af:outputText value="#{row.str2}"/>
</f:facet>

53.3.4 実行時に行われる処理: アクティブ・データにバインドされている場合のコンポーネントのレンダリング方法

アプリケーションとADSのコンポーネントの構成後、サーバーでデータが変化すると必ず、コンポーネントに通知が送られ、変更されたデータのみを使って再レンダリングが行われます。対照的に、アクティブ・データまたは自動PPRのどちら向けにも構成されていないコンポーネントは、データ変更後に明示的にリフレッシュする必要があります。明示的なリフレッシュは、変更されていないデータを含め、クライアントに表示されているデータすべてを再フェッチします。この結果、コンポーネント全体が強制的に再レンダリングされます。さらに、コンポーネントが(アクティブ・データ・ポリシー「Push」を使用して)アクティブ・データ・ソースにバインドされている場合、このコンポーネントによる再レンダリングが行われ、新しい値がハイライトされます。

53.3.5 Google ChromeブラウザでのADSの実行に関する必知事項

Fusion WebアプリケーションがGoogle Chrome Webブラウザで実行されているときに、ユーザーが[Ctrl]+[N]キー(または[Ctrl]+[T]キー)を押して、新しいウィンドウ(またはタブ)を開き、元のウィンドウから新しいウィンドウにURLをコピーすると、元のウィンドウのアクティブ・データはストリーミングを停止します。Google Chromeのプロセス・モデルによれば、新しいブラウザ・ウィンドウは別のプロセスで作成され、両方のウィンドウは同じHTTPセッションを共有します。ただし、2つの異なるプロセスで作成されたブラウザ・ウィンドウは互いに通信できないため、クライアントとサーバーの間でADSが同期しなくなり、ADSのストリーミングが停止します。回避策として、複数のGoogle Chromeウィンドウでアクティブ・データを許可するには、元のウィンドウから新しいウィンドウにURLをコピーする前に、ユーザーは[Ctrl]キーと[Shift]キーと[N]キーを同時に押して、ブラウザ・ウィンドウを匿名モードで開きます(プライベート・ブラウジング)。[Ctrl]キーと[Shift]キーと[N]キーを同時に押すと、別のプロセスと別のHTTPセッションでウィンドウが開かれるため、ADSは2つのウィンドウを同期しようとしなくなり、ストリーミングは影響を受けません。

53.4 アクティブ・データ・プロキシの使用

ビジネス・サービスがデータ・イベントに反応しないときには、アクティブ・データ・プロキシを使用します。ADFビジネス・コンポーネントに渡されたイベントに基づいてコンポーネントを更新する必要がある場合は、アクティブ・データ・プロキシを使用する必要があります。

ヒント:

アプリケーションがビジネス・サービスにBAMを使用している場合、アクティブ・データ・プロキシを使用する必要はありません。

注意:

ビジネス・サービスでアクティブ・データ・プロキシを使用する必要がある場合、アクティブ・データとともに使用できるのは次のコンポーネントのみです。

- table

- tree

- treeTable

- ADFデータ視覚化コンポーネント(mapPointTheme、pivotTable,、pivotFilterBar、sunburst、treemap)

53.4.1 アクティブ・データ・プロキシの使用方法

次のデコレータ・クラスの1つをサブクラスするJavaクラスを作成します。

- ActiveCollectionModelDecoratorクラス

- ActiveGeoMapDataModelDecoratorクラス

これらのクラスは、アクティブ・データ機能をActiveDataModelのデフォルト実装に委譲するラッパー・クラスです。ActiveDataModelクラスは、データ変更イベントをリッスンし、イベント・マネージャと対話します。具体的には、次の処理が行われます。

- アクティブ・データおよびActiveDataModelオブジェクトを開始および停止し、データ・ソースへのリスナーの登録および登録解除を行います。

- JSFモデル・インタフェースをラップします。たとえば、ActiveCollectionModelDecoratorクラスはCollectionModelクラスをラップします。

- データ・ソースから、データ変更イベントに基づいてアクティブ・データ・イベントを生成します。

- イベント・マネージャからリスナーを管理し、アクティブ・データ・イベントをイベント・マネージャにプッシュします。

アクティブ・データ・ソースのリスナーとして自分自身を登録し、データの送信先モデルを取得するこのJavaクラスにメソッドを実装する必要があります。

注意:

アクティブ・データ・フレームワークは、ユーザー・プロファイルやセキュリティなどADF実行時コンテキストを必要とする複雑なビジネス・ロジックや変換をサポートしません。たとえば、このフレームワークはADFコンテキストのロケール依存値を変換し、ロケール固有の値を返すことはできません。

複雑なビジネス・ロジックの例として、たとえば、注文をopenステータスからpendingステータスに変更することをユーザーに許可するロジックがあるとします。この変更の結果がupdateイベントで、このイベントにより、データ・オブジェクト"Open Orders"から注文が削除されます。フレームワークでは、このイベント・タイプをビジネス・ロジックに基づいて処理することはできません。そのかわりに、ユーザーは、データ変更イベントを公開する前に、データ・ソースにこれを処理させる必要があります。

始める前に:

アクティブ・データ・プロキシに関する知識が役立つ場合があります。詳細は、「アクティブ・データ・プロキシの使用」を参照してください。

他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「アクティブ・データ・サービスについて」を参照してください。

次のタスクを完了する必要があります。

- データ・ソースから非同期的にアクティブ・データ・イベントを起動するロジックを実装します。たとえば、このロジックとしては、データベースを更新するビジネス・プロセス、またはJMSから通知を受けるJMSクライアントなどが考えられます。

アクティブ・データ・サービスを使用するには:

1. コンポーネントに適したデコレータ・クラスを拡張するJavaクラスを作成します。次の例は、表用に作成されたクラスを示しています。

package view;

import oracle.adf.view.rich.model.ActiveCollectionModelDecorator;
import oracle.adf.view.rich.activedata.ActiveDataEventUtil;
import oracle.adf.view.rich.activedata.JboActiveDataEventUtil;

/**
* This code wraps the existing collection model in the page and implements the
ActiveDataModel interface to enable ADS for the existing page.
*/
public class DeptModel
extends ActiveCollectionModelDecorator
{
}

2. モデルを戻すメソッドを実装します。次の例は、getCollectionModel()メソッドの実装を示しており、これは、式言語(EL)に依存して、内部クラスへのタイプキャストが必要になる事態を回避します。このメソッドは、バインディング・コンテナからDepartmentsView1コレクションを戻します。

public CollectionModel getCollectionModel()
{
if (_model == null)
{
FacesContext fc = FacesContext.getCurrentInstance();
Application app = fc.getApplication();
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext el = fc.getELContext();

// This is EL to avoid typecasting to an Internal class.
ValueExpression ve = elFactory.createValueExpression(el,
"#{bindings.DepartmentsView1.collectionModel}", Object.class);

// Now GET the collectionModel
_model = (CollectionModel)ve.getValue(el);
}
return _model;
}

3. ActiveDataModelクラスを独自に実装した内部クラスを作成します。デコレータはこれをアクティブ・データの開始および停止、データ・ソースへの接続および接続解除に使用します。次の例に示すとおり、このクラスは、データ読取り一貫性を維持するために、changeCount APIも使用します。詳細は、「読取り一貫性の維持に関する必知事項」を参照してください。

public class MyActiveDataModel extends BaseActiveDataModel
{
protected void startActiveData(Collection<Object> rowKeys,
int startChangeCount)
{
_listenerCount.incrementAndGet();
if (_listenerCount.get() == 1)
{
System.out.println("start up");

Runnable dataChanger = new Runnable()
{
public void run()
{
System.out.println("MyThread starting.");
try
{
Thread.sleep(2000);
System.out.println("thread running");
triggerDataChange(MyActiveDataModel.this);
}
catch (Exception exc)
{
System.out.println("MyThread exceptioned out.");
}
System.out.println("MyThread terminating.");
}
};
Thread newThrd = new Thread(dataChanger);
newThrd.start();
}
}

protected void stopActiveData(Collection<Object> rowKeys)
{
_listenerCount.decrementAndGet();
if (_listenerCount.get() == 0)
{
System.out.println("tear down");
}
}

public int getCurrentChangeCount()
{
return _currEventId.get();
}

public void bumpChangeCount()
{
_currEventId.incrementAndGet();
}

public void dataChanged(ActiveDataUpdateEvent event)
{
fireActiveDataUpdate(event);
}

private final AtomicInteger _listenerCount = new AtomicInteger(0);
private final AtomicInteger _currEventId = new AtomicInteger();
}

4. ActiveDataModelクラスを戻すメソッドを実装します(次の例を参照)。

public ActiveDataModel getActiveDataModel()
{
return _activeDataModel;
}

5. アクティブ・モデルへのデータの挿入または更新に使用できる、アプリケーション固有のイベントを作成するメソッドを作成します。

次の例に示すtriggerDataChange()メソッドは、アクティブ・モデル(MyActiveDataModelのインスタンス)を使用して、データを挿入および更新するためのActiveDataUpdateEventオブジェクトを作成します。このメソッドを実装するには、oracle.adf.view.rich.activedata.ActiveDataEventUtilおよびoracle.adf.view.rich.activedata.JboActiveDataEventUtilをインポートする必要があります。

public void triggerDataChange(MyActiveDataModel l)
throws Exception
{

// do an update on dept 1
l.bumpChangeCount();
ActiveDataUpdateEvent event =
ActiveDataEventUtil.buildActiveDataUpdateEvent(ActiveDataEntry.ChangeType.UPDATE,
l.getCurrentChangeCount(),
JboActiveDataEventUtil.convertKeyPath(new Key
(new Object[]{ new Long(1), new Integer(0) })),
null,
new String[] { "name" },
new Object[] { "Name Pushed" });

l.dataChanged(event);

try
{
Thread.sleep(2000);
}
catch (InterruptedException ie)
{
ie.printStackTrace();
}
// insert dept 99

l.bumpChangeCount();
event =
ActiveDataEventUtil.buildActiveDataUpdateEvent(ActiveDataEntry.ChangeType.INSERT_AFTER,
l.getCurrentChangeCount(),
JboActiveDataEventUtil.convertKeyPath(new Key
(new Object[]{ new Long(99), new Integer(0) })),
JboActiveDataEventUtil.convertKeyPath(null),
new String[]{ "addr1", "name" },
new Object[]{ "Addr Inserted", "Name Inserted" });

l.dataChanged(event);

try
{
Thread.sleep(2000);
}
catch (InterruptedException ie)
{
ie.printStackTrace();
}

// delete dept 10

l.bumpChangeCount();
event =
ActiveDataEventUtil.buildActiveDataUpdateEvent(ActiveDataEntry.ChangeType.REMOVE,
l.getCurrentChangeCount(),
JboActiveDataEventUtil.convertKeyPath(new Key
(new Object[]{ new Long(9), new Integer(0) })),
null, null, null);

l.dataChanged(event);

try
{
Thread.sleep(2000);
}
catch (InterruptedException ie)
{
ie.printStackTrace();
}

// refresh the entire table

l.bumpChangeCount();
event =
ActiveDataEventUtil.buildActiveDataUpdateEvent(ActiveDataEntry.ChangeType.REFRESH,
l.getCurrentChangeCount(),
null, null, null, null);

l.dataChanged(event);
}

private MyActiveDataModel _activeDataModel = new MyActiveDataModel();

private CollectionModel _model = null;

}

53.5 読取り一貫性の維持に関する必知事項

アクティブ・データを使用するということは、コンポーネントに2つのデータ・ソース(アクティブ・データ・フィードと標準データ・フェッチ)があることを意味します。このため、アプリケーションでは読取り一貫性が確保されるようにする必要があります。

たとえば、ページには表が1つ含まれ、この表ではアクティブ・データが有効化されているとします。この表は、データを更新するための配信メソッドとして、標準の表データ・フェッチとアクティブ・データ・プッシュの2種類を持っています。ここで、バック・エンド・データがfooからbarに変更され、さらにfredに変更されたとしましょう。変更のたびに、アクティブ・データ・イベントが起動されます。これらのイベントがブラウザに到着する前に表をリフレッシュした場合、表にはfredと表示されます。これは、標準のデータ・フェッチでは、必ず最新のデータが取得されるからです。しかし、アクティブ・データ・イベントに長い時間がかかることもあるため、場合によっては、リフレッシュの後で、このデータ変更イベントの結果、fooがブラウザに到着し、表が更新されて、しばらくの間、fredのかわりにfooと表示されます。したがって、読取り一貫性を維持する方法を実装する必要があります。

読取り一貫性を実現するために、ActiveDataModelは、効果的にデータにタイムスタンプを押す変更カウントの概念を採用しています。データ・フェッチとアクティブ・データ・プッシュのどちらも、このchangeCountオブジェクトを単調にカウントを増やすことで維持する必要があるため、返されたデータのchangeCountが現在のカウントより低い場合は、アクティブ・イベントにより廃棄される可能性があります。読取り一貫性を維持するActiveDataModelクラスの実装の例は、「アクティブ・データ・プロキシの使用方法」を参照してください。

53.6 アクティブ・データとスカラー・モデルの併用

コレクションベースのデータを表示するADFコンポーネントは、ADSと提携するように構成することができます。ビュー・レイヤーでは余分なセットアップは必要ありません。しかし、JSPXページで、Javaタイマーに基づき新しいカウントを表示するために、activeOutputTextコンポーネントを使用する例を考えてみましょう。この場合、モデル・レイヤーを、JavaBeanから表示されるスカラー、つまり"フラットな"データで置き換えます。

53.6.1 アクティブ・データとスカラー・モデルの併用方法

スカラー・モデルを実装するには、次の基本手順に従います(後に例を示しています)。

1. このBean(スカラー・モデル)が実際のモデルを模倣するように、ActiveModelContext APIを使用して、ADSとともにBeanを登録します。
アクティブな属性のgetterメソッドに登録コードを追加します。Beanのコンストラクタに登録コードを追加すると、ADSが失敗することがあります。

2. 次の例に示すように、データをビュー・レイヤーにプッシュするカスタム・メカニズムを実装します。

package oracle.adfdemo.view.feature.rich;

import java.util.Collection;
import java.util.Timer;
import java.util.TimerTask;
import java.util.concurrent.atomic.AtomicInteger;

import oracle.adf.view.rich.activedata.ActiveModelContext;
import oracle.adf.view.rich.activedata.BaseActiveDataModel;
import oracle.adf.view.rich.activedata.ActiveDataEventUtil;
import oracle.adf.view.rich.event.ActiveDataEntry;
import oracle.adf.view.rich.event.ActiveDataUpdateEvent;

public class CounterBean extends BaseActiveDataModel
// Example using a Java timer to create new counts
{
public CounterBean()
{
timer.schedule(new UpdateTask(), 2000, 2000);
}

public String getState()
{
// 1. Use the ActiveModelContext API to register the scalar model key path for
//    the "state" attribute.
ActiveModelContext context = ActiveModelContext.getActiveModelContext();
Object[] keyPath = new String[0];
context.addActiveModelInfo(this, keyPath, "state");

return String.valueOf(counter);
}

// Not needed. We do not need to connect to a (real) active data scource.
protected void startActiveData(Collection<Object> rowKeys, int
startChangeCount) {}

// Not needed. We do not need to connect to a (real) active data scource.

protected void stopActiveData(Collection<Object> rowKeys) {}

public int getCurrentChangeCount()
{
return counter.get();
}

protected class UpdateTask extends TimerTask
{
public void run()
{
counter.incrementAndGet();

// 2. Use ActiveDataEventUtil to create an event object to update the model.
ActiveDataUpdateEvent event =
ActiveDataEventUtil.buildActiveDataUpdateEvent(
ActiveDataEntry.ChangeType.UPDATE,
counter.get(),
new String[0],
null,
new String[] { "state" },
new Object[] { counter.get() });
fireActiveDataUpdate(event);
}
}

private static final Timer timer = new Timer();
private final AtomicInteger counter = new AtomicInteger(0);
}

Beanの作成後、これをマネージドBeanとしてfaces-config.xmlファイルに登録します(次の例のcounterBeanを参照)。

...
<managed-bean>
<managed-bean-name>counterBean</managed-bean-name>
<managed-bean-class>
oracle.adfdemo.view.feature.rich.CounterBean
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

Beanの登録が完了すると、ADSを使用して、データをビュー・レイヤーにストリーミングできるようになります。ADF Facesコンポーネントでは、プッシュされたデータを受け取るために式言語が使用されます(次の例のactiveOutputTextコンポーネントのvalue属性を参照)。

...
<f:view>
<af:document title="Active Data Visual Design Demo"
binding="#{templateBindings.documentComponent}"
smallIconSource="#{aboutBean.smallIconSource}"
largeIconSource="#{aboutBean.largeIconSource}" theme="dark"
id="d1">
<af:pageTemplate id="dmoTpl" viewId="#{templates.componentTemplate}">
<f:attribute name="tagName" value="Active Data Visual Design"/>
<f:attribute name="demoKind" value="visualDesign"/>
<f:attribute name="customEditorPresent" value="true"/>
<f:facet name="center">
<af:panelGroupLayout layout="scroll">
<af:activeOutputText
value="#{counterBean.state}"
inlineStyle=
"color:brown;
font-size:100px;
font-weight:bold;
text-align:center;"
/>
</af:panelGroupLayout>
</f:facet>
</af:pageTemplate>
</af:document>
</f:view>

54 Fusion Webアプリケーションの高可用性の構成

この章では、高可用性クラスタ・サーバー環境にデプロイするFusion Webアプリケーションの開発に関する考慮事項について説明します。

この章の内容は次のとおりです。

- Oracle ADF高可用性について

- 高可用性のためのOracle ADFの構成

- 高可用性のためのFusion Webアプリケーションのトラブルシューティング

54.1 Oracle ADF高可用性について

Fusion Webアプリケーションの高可用性は、必要な場合にアプリケーションを使用可能にする機能です。

高可用性環境では、ユーザーがサービスを失わずにアプリケーションにアクセスできます。Fusion Webアプリケーションを高可用性環境にデプロイすることで、アプリケーションの停止時間つまり使用不可の時間が最小化され、アプリケーションの稼働時間つまり使用可能な時間が最大化されます。

高可用性は、システムとコンポーネントに冗長性を持たせることによって実現されます。高可用性ソリューションは、冗長性のレベルによってアクティブ/アクティブ・ソリューションとアクティブ/パッシブ・ソリューションに分類されます。

アクティブ/アクティブ・ソリューションは、複数のアクティブなサーバーをデプロイし、スケーラビリティの向上の他、高可用性の提供に使用できます。アクティブ/アクティブ・デプロイでは、すべてのインスタンスは、同時にリクエストを処理します。単一サイトにミドルウェアをデプロイする場合は、常にアクティブ/アクティブ・ソリューションを使用することをお薦めします。アクティブ/パッシブ・ソリューションでは、リクエストを処理するアクティブ・インスタンスと、スタンバイ状態のパッシブ・インスタンスをデプロイします。

高可用性環境の詳細は、高可用性ガイドを参照してください。

54.1.1 Oracle ADFスコープとセッション状態の考慮事項

実行時には、バインディング・コンテナおよびマネージドBeanなどのADFオブジェクトはインスタンス化されています。これらの各オブジェクトには、そのスコープ属性によって設定される存続期間が定義されています。

ADFオブジェクトの存続期間の詳細は、「オブジェクト・スコープ・ライフサイクルについて」を参照してください。

54.1.2 Oracle ADFのフェイルオーバーおよび予想される動作の考慮事項

Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内で他に利用可能なメンバーがリクエストを処理できます。アプリケーションのフェイルオーバー要件およびフェイルオーバーの発生時に予想される動作について精通している必要があります。

54.1.2.1 セッションのフェイルオーバー要件

Fusion Webアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。

- アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できます。

- ステートフル・アプリケーションに対し、「高可用性のためのOracle ADFの構成」の説明に従って、状態のレプリケーションが正しく構成されています。

- Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されています。

- ハードウェア・ロード・バランサを使用する場合は、ロード・バランサが:

- 利用可能なインスタンスすべてに対してトラフィックをルーティングしています

- 利用できないインスタンスをマークするように、ヘルス・モニターで正しく構成されています

- セッションの状態の永続性をサポートするように構成されています

54.1.2.2 アプリケーションのフェイルオーバーで予想される動作

環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気が付きません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。

1. ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。

2. ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。

3. ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。

4. ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。

5. インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。

6. インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。

54.1.3 Oracle RACのADFアプリケーション・モジュールの考慮事項

冗長なデータベースやバックエンドとしてのOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、GridLinkデータ・ソースまたはマルチ・データ・ソースを使用する必要があります。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースまたはGridLinkデータ・ソースの命名規則は、非マルチ・データ・ソースまたはGridLinkデータ・ソースの命名規則と同じになります。この命名規則によって、正しいデータ・ソースが実行時に使用されるようになります。

高可用性アプリケーションのGridLinkデータソースまたはマルチ・データソースの構成の詳細は、『高可用性ガイド』の「データベースの考慮事項」を参照してください。

Fusion WebアプリケーションのmdsDSデータソースURLのデプロイメント後の変更に関連する高可用性の考慮事項の詳細は、『高可用性ガイド』の「その他のコンポーネントの高可用性の構成」を参照してください。

54.2 高可用性のためのOracle ADFの構成

クラスタ環境内のWebアプリケーションに対して自動的なレプリケーションとフェイルオーバーをサポートするために、Oracle WebLogic Serverは、クラスタ間でHTTPセッションの状態をレプリケートするメカニズムをサポートしています。Fusion Webアプリケーションの状態をクラスタ内のどのサーバーからでもリストアできるようにOracle ADFを構成できます。

54.2.1 高可用性のためのアプリケーション・モジュールの構成方法

アプリケーション・モジュールは、Fusion Webアプリケーションがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。アプリケーション・モジュールは、そのトランザクション状態を非アクティブ化する、またはスナップショットとしてデータベースに格納することをサポートしています。また、これらの保存済スナップショットのいずれかからトランザクション状態をアクティブ化する逆の操作もサポートしています。

アプリケーション・モジュール状態管理の詳細は、「Fusion Webアプリケーションの状態管理について」を参照してください。

ADFビジネス・コンポーネントのフェイルオーバーのサポートを有効にするには、jbo.dofailoverパラメータをtrueに設定し、アプリケーション・モジュールの状態が解放時に保存されるようにします。これによって、Oracle ADFは、前のチェックインで保存されたスナップショットからアプリケーション・モジュールの状態をリストアできるようになります。一方、フェイルオーバー機能がデフォルトにより無効のままになっている場合は、アプリケーションが後続のユーザー・セッションで再利用されたときと、アプリケーション・モジュール・プールが未使用のアプリケーション・モジュールを見つけられないときにのみ、アプリケーション・モジュールの状態が保存されます。

アプリケーション・モジュール構成でこのパラメータを設定するには、アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタの「プーリングおよびスケーラビリティ」タブを使用します。

高可用性のためのアプリケーション・モジュールを構成する手順は次のとおりです。

1. JDeveloperを起動してアプリケーションを開きます。

2. 「アプリケーション」ウィンドウで、データ・モデルを含むプロジェクトを展開し、アプリケーション・モジュールをダブルクリックします。

3. アプリケーション・モジュールの概要エディタで「構成」ナビゲーション・タブを選択し、高可用性を設定する構成の構成ハイパーリンクをクリックします。

4. アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタで、「データベースとスケーラビリティ」タブをクリックします。

5. 「管理された解放時にトランザクションの状態をフェイルオーバー」チェック・ボックスを選択し、変更を保存します。

54.2.2 HTTPセッション状態のレプリケートのサポートを有効にする方法

HTTPセッションの状態のレプリケートをサポートできるようにするには、Oracle WebLogic Server weblogic.xmlファイルのpersistent-store-type要素に値を割り当てる必要があります。replicated_if_clusteredの値により、有効な永続ストアのタイプがレプリケートされ、このサーバーの属するサーバーのクラスタに対して設定された値に従って、クラスタ環境のセッションが格納されるようになります。

注意:

Oracle WebCenterポータルSuiteなどのOracle ADFアプリケーションは事前に構成されており、追加構成は不要です。

高可用性を実現するためにweblogic.xmlファイルを構成する手順は次のとおりです。

1. JDeveloperを起動してアプリケーションを開きます。

2. 「アプリケーション」ウィンドウで、Webアプリケーションを含むプロジェクトを展開し、WEB-INFフォルダを展開します。

3. weblogic.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。

4. ファイル内で、persistent-store-typeの定義をsession-descriptor要素に追加します。

<weblogic-web-app>
<session-descriptor>
<persistent-store-type>
replicated_if_clustered
</persistent-store-type>
</session-descriptor>
</weblogic-web-app>

54.2.3 マネージドBeanの変更からOracle ADFが通知を受信することを確認する方法

クラスタ環境で実行するアプリケーションを設計している場合は、ADFスコープ(ビュー・スコープおよびページ・フロー・スコープ)に格納されているマネージドBeanの変更をOracle ADFが認識していることを確認する必要があります。

ビュー・スコープまたはページ・フロー・スコープのいずれかで、マネージドBean内の値が変更された場合には、アプリケーションがOracle ADFに通知して、Beanの新しい値がレプリケートできるようにする必要があります。

ADF ControllerがADFメモリー・スコープに対する変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、アプリケーションのadf-config.xmlファイル内のADF Controllerパラメータ<adf-scope-ha-support>をtrueに設定する必要があります。たとえば、アプリケーションにtrueを設定した場合、そのアプリケーションがリクエスト中にページ・フロー・スコープでBeanの追加または削除を行うと、変更がクラスタ内で自動的にレプリケートされます。

adf-config.xmlは、すべてのADFコンポーネントの中核となる構成ファイルです。このファイルには、ADF ControllerなどのADFコンポーネントの実行時の動作を構成するためのセクションが含まれています。

注意:

アプリケーションでMDSを使用しており、フェイルオーバーをサポートするOracle Databaseを使用する場合は、フェイルオーバー時におけるMDSの再試行を有効化しておくことをお薦めします。これを行うには、次のretry-connectionエントリをadf-config.xmlのMDS構成セクションに追加します。

<persistence-config>
<metadata-namespaces>...
<metadata-store-usages>...
<external-change-detection enabled="false" />
<read-only-mode enabled="true"/>
<retry-connection enabled="true"/>
</persistence-config>

高可用性を実現するためにadf-config.xmlファイルを構成する手順は次のとおりです。

1. 「アプリケーション」ウィンドウで、「アプリケーション・リソース」を展開します。

2. 「ディスクリプタ」を選択し、「ADF META-INF」ノードを選択します。

3. adf-config.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。

4. このファイルに次の行を追加します。

<adf-controller-config xmlns="http://xmlns.example.com/adf/controller/config">
<adf-scope-ha-support>true</adf-scope-ha-support>
</adf-controller-config>

adf-config.xmlファイルを使用したADFの構成の詳細は、「adfc-config.xml」を参照してください。

54.2.4 クラスタ環境でのアプリケーション・スコープのマネージドBeanの使用に関する必知事項

JSFアプリケーション・スコープBeanは、クラスタ・ノードごとにインスタンスを1つだけ持てるサーブレット・コンテキストによって戻されます。したがって、設計時に構成されたBeanそれぞれに対して、クラスタ内のノードごとにBeanの実行時インスタンスが存在することになります。ノード間は同期化されていないので、別々のノードで実行されるアプリケーションの各インスタンスが、そのBeanの別々の値を含む別々のインスタンスを持つことになります。つまり、1つのクラスタ内のすべてのノードで共有されるように更新できるアプリケーション全体の値を渡す際に、アプリケーション・スコープのマネージドBeanを使用することはできません。ただし、定数、読取り専用の値またはクラスタ内の1つのノードの状態(ノード上のユーザー数など)を反映する値を渡すために使用することはできます。

54.2.5 設計時の最適化を無効にする方法

org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONコンテキスト・パラメータは、JDeveloperでFusion Webアプリケーションの開発とテストを最適化します。高可用性環境でアプリケーションを実行するときに、このパラメータをtrueのままにすると、フェイルオーバーの発生後にエラーが発生することがあります。通常、このパラメータは開発環境のみに使用し、高可用性環境では使用しないため、この制限が操作に影響することはありません。

高可用性用にCHECK_FILE_MODIFICATIONパラメータを構成する手順:

1. 「アプリケーション」ウィンドウで、ユーザー・インタフェース・プロジェクトを展開し、WEB-INFフォルダを展開します。

2. web.xmlファイルをダブルクリックし、「アプリケーション」ナビゲーション・タブをクリックします。

3. 概要エディタで、「コンテキスト初期化パラメータ」セクションを展開し、org.apache.myfaces.trinidata.CHECK_MODIFICATIONパラメータ定義がfalseに設定されていることを確認します。

web.xmlファイル定義は次のようになります。

<web-app>
...
<context-param>
<param-name>org.apache.myfaces.trinidad.CHECK_FILE_
MODIFICATION</param-name>
<param-value>false</param-value>
</context-param>
</web-app>

54.3 高可用性のためのFusion Webアプリケーションのトラブルシューティング

この項では、設計時およびデプロイメント後にFusion Webアプリケーションの問題をトラブルシューティングする手順について説明します。

54.3.1 フェイル・オーバー・モードが有効なFusion Webアプリケーションをテストする方法

JDeveloper環境内でフェイルオーバー・サポートを使用する(jbo.dofailoverが有効な)アプリケーションを実行またはデバッグするときは、アプリケーション・サーバーを頻繁に起動および停止します。ADFのフェイルオーバー・メカニズムでは、ユーザーがサーバーを停止してアプリケーション・サーバーの障害をシミュレートしているのか、それとも初期状態のサーバー・インスタンスで何かを最初から再テストするために停止しているのかを認識する手段がありません。後者の場合は、サーバーでアプリケーションを再起動する前に、ブラウザを終了することをお薦めします。これにより、アプリケーションでフェイルオーバー・メカニズムの正しい機能に関する部分をテストするつもりがない場合に、このメカニズムが動作することによって発生する混乱を避けることができます。

54.3.2 設計時の高可用性の問題をトラブルシューティングする方法

Fusion WebアプリケーションをOracle JDeveloperで開発する場合は、この統合開発環境によって、高可用性に関する問題を検出するためのサポートが提供されます。JDeveloperが発する警告は監査フレームワークによって生成され、JDeveloperのソース・エディタに表示するようにトリガーされます。エディタに表示される警告は、高可用性アプリケーションの監査ルールに基づきます。

JDeveloperがデフォルトにより有効にする高可用性監査ルールは次のとおりです。

- 「ADF Controller構成 - ADFスコープの高可用性が有効になっていません」は、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されていないことを警告します。この監査ルールは、<adf-controller-config>要素がADFアプリケーションレベルの構成ファイル(adf-config.xml)に存在する場合にのみ適用されます。

- 「ADFページ・フロー - スコープ・マップのBeanが変更されました」は、コードがBeanでsetterメソッドを呼び出す際、続いてControllerContext.markScopeDirty()メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。

- 「ADFページ・フロー - EL Beanが変更されました」は、BeanをミューテーションするEL式をコードが評価する際、続いてControllerContext.markScopeDirty()メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。

- 「ADFページ・フロー - マネージドBeanクラスはシリアライズ不可」は、マネージドBeanのviewScope、pageFlowScopeまたはsessionScopeに、シリアライズ不可のクラスが定義されていることを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。

高可用性監査ルール設定は、JDeveloperの「設定」ダイアログを使用して変更できます。JDeveloperのツールバーで「ツール - 設定」を選択し、「監査 - プロファイル」の下にある「ADF Controller構成」または「ADFページ・フロー」を展開して、目的の監査ルールを選択します。

JDeveloperのツールバーで「ビルド - 監査」project.jprを選択して監査をトリガーすることもできます。

54.3.3 デプロイメント後の高可用性の問題をトラブルシューティングする方法

Fusion Webアプリケーションのデプロイメントに関する問題に直面した場合は、実施する2つの対応として、JRFランタイムの確認とアプリケーションのデプロイメント・ステータスの確認を行います。

54.3.3.1 JRFランタイムのインストールの確認

Fusion Webアプリケーションのデプロイメントをトラブルシューティングする最初の手順では、WebLogic Serverドメイン上にJRFランタイムがインストールされているかどうかを確認します。ADFのアプリケーションには、JRFとADFのランタイムが必要です。スタンドアロンのWebLogic Serverドメインまたはアプリケーション開発の製品に含まれているWebLogic ServerだけではADFのアプリケーションを実行できないため、JRF拡張テンプレートを使用して拡張する必要があります。

JRFテンプレートの詳細は、『ドメイン・テンプレート・リファレンス』のOracle JRFおよびADFのテンプレートに関する項を参照してください。

54.3.3.2 すべてのアプリケーションが正常にデプロイされたかどうかの確認

Fusion Webアプリケーションは、管理対象サーバーを最初に起動したときにデプロイされます。すべてのアプリケーションが正常にデプロイされたかどうかは、管理コンソールを使用して確認します。

1. 左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。

2. アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/server_name/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。

- データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。

- 適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。

54.3.4 Oracle ADFのレプリケーションおよびフェイルオーバーの問題をトラブルシューティングする方法

フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。

- ウィンドウが閉じたか、または状態がリセットされた可能性がある。

- 画面のリセットが必要になった可能性がある。

- アプリケーションがログオン画面にリダイレクトしている可能性がある。

状態のレプリケーションに関する問題の診断およびトラブルシューティングを行う手順は、次のとおりです。

1. これがレプリケーションに関する既知の問題でないことを確認します。

予想される動作については、「Oracle ADFのフェイルオーバーおよび予想される動作の考慮事項」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。

2. ロード・バランサの設定を確認します。

レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverでのハードウェア・ロード・バランサの構成の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。

3. クラスタのステータスを確認します。

クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、他に少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。

- Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。

- weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminユーティリティは、特定のクラスタ内にある全サーバーの状態を問い合せるときに使用できます。次に例を示します。

$ java weblogic.Admin -url Adminhost:7001 -username <username> -password
<password> CLUSTERSTATE -clustername Spaces_Cluster

次のようなメッセージが返されます。

There are 2 server(s) in cluster: Spaces_Cluster
The alive servers and their respective states are listed below:
Application Server---RUNNING
Managed Server---RUNNING

4. クラスタ通信を確認します。

クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。

- ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。

- マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。次に例を示します。

$ java utils.MulticastTest -H

5. Oracle WebLogic Serverアプリケーションの構成を確認します。

Oracle WebLogic Serverは、デフォルトではフェイルオーバーするように構成されていません。インメモリー・レプリケーションは、weblogic.xmlファイルに次の適切な設定が含まれている場合にのみ行われます。

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

replicatedのpersistent-store-typeも受け入れられます。この設定は、「HTTPセッション状態のレプリケートのサポートを有効にする方法」で説明されているように、JDeveloperで行うことができます。

6. Oracle ADFビジネス・コンポーネントの構成を確認します。

Oracle ADFは、デフォルトではフェイルオーバーするように構成されていません。フェイルオーバーは、ADFビジネス・コンポーネントの構成ファイル(bc4j.xcfg)に次の適切な設定が含まれている場合にのみサポートされます。

<AppModuleConfig ...
<AM-Pooling jbo.dofailover="true"/>
</AppModuleConfig>

「高可用性のためのアプリケーション・モジュールの構成方法」で説明するように、この設定は、JDeveloperで「ビジネス・コンポーネント構成の編集」ダイアログを通じて行われます。

7. Oracle WebLogic Serverの接続プール・パラメータを確認します。

weblogic-application.xmlデプロイメント・ディスクリプタの要素<connection-check-params> pool-paramsにあるパラメータinactive-connection-timeout-secondsに適切な値を設定します。

アプリケーション・モジュール状態の非アクティブ化を有効にしている場合は、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。この障害によって、例外Connection has already been closedが生成されます。この例外は、サーバー・ログに保存されます。ユーザー・インタフェースには、この例外は表示されません。

inactive-connection-timeout-secondsは、数分に設定します。多くの場合は、この設定値によって、非アクティブ接続の強制的なタイムアウトと、非アクティブ化障害を回避できます。ご使用の環境に合せて、この設定値を調整してください。

8. ADF Controllerの構成を確認します。

Oracle ADFは、デフォルトでは、ADFオブジェクトに対する変更をADFメモリー・スコープ内にレプリケートするように構成されていません。ADFオブジェクトのレプリケーションは、ADFアプリケーションレベルの構成ファイル(adf-config.xml)に次の適切な設定が含まれている場合にのみサポートされます。

<adfc:adf-controller-config>
<adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support>
</adfc:adf-controller-config>

この設定は、JDeveloperのソース・エディタを使用して行います。「高可用性のためのアプリケーション・モジュールの構成方法」を参照してください。

9. デフォルトのロガー・メッセージを確認します。

デフォルトでは、ADFのログには上位レベルのメッセージ(INFOレベル)が表示されます。デフォルトのログ出力では、さらに詳細なログ・メッセージを有効にする必要なしに、シリアライズやレプリケーションに関する問題を報告することがよくあります。

10. ADF高可用性アプリケーションのログ・メッセージを有効にします。

ADFロガーを、高可用性のランタイム・メッセージを出力するように構成します。デフォルトでは、ADFのログには上位レベルのメッセージ(INFOレベル)が表示されます。Fusion Middleware Controlでロギング・レベルをFINEに設定して、ADF Controllerの高可用性の診断を有効にします。

有効にすると、adf-config.xmlファイルにadfc:adf-scope-ha-supportが設定されていない場合に、ロガーが警告を出力するようになります。

11. デバッグを有効にします。

サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、DOMAIN_HOME/servers/SERVER_NAME/logsディレクトリに格納されています。

詳細なデバッグを行うには、DebugCluster、DebugClusterAnnouncements、DebugFailOver、DebugReplication、DebugReplicationDetailsの各フラグを有効にします。各フラグは、weblogic.Adminユーティリティを使用して次のように有効にできます。

$ java weblogic.Admin -url Adminhost:7001 -username <username> -password
<password> SET -type ServerDebug -property DebugCluster true

12. コンポーネントの状態のシリアライズ・チェックを有効にします。

サーバーのチェックを有効にして、セッション属性でシリアライズ不能な状態コンテンツが検出されないようにします。このチェックは、デフォルトでは、実行時のオーバーヘッドを軽減するために無効になっています。シリアライズ・チェックは、Javaサーバーのシステム・プロパティorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATIONによってサポートされます。

表54-1は、このプロパティで使用できるオプションを示しています。オプションを区切るには、カンマを使用します。

表54-1 CHECK_STATE_SERIALIZATIONのオプション

オプション

説明

ツリー

コンポーネント・ツリー全体がシリアライズ可能であるかどうかをチェックします。これは、最も高速なコンポーネント・チェックです。大部分のテストは、このフラグを有効にして実行してください。

コンポーネント

シリアライズ可能性について各コンポーネントを個別にチェックします。このオプションは、treeと比較するとかなり低速です。これは、通常、treeのテストでエラーが報告された後にのみ有効にします。このオプションは、問題のあるコンポーネントを絞り込みます。

プロパティ

シリアライズ可能性について各コンポーネント属性を個別にチェックします。これはcomponentよりも低速であり、treeまたはcomponentモードで障害が検出された後に問題のある特定のコンポーネント属性を絞り込みます。

セッション

シリアライズ可能とマークされているJSF Session Mapのすべての属性がシリアライズ可能であることをチェックします。

アプリケーション

シリアライズ可能とマークされているJSF Application Mapのすべての属性がシリアライズ可能であることをチェックします。

beans

該当するマップのシリアライズ可能なオブジェクトのシリアライズ可能なコンテンツがリクエスト中に変更された場合に、そのオブジェクトがダーティとマークされたことをチェックします。

すべて

すべてをチェックします。

高可用性をテストするには、まず次のシステム・プロパティを使用してアプリケーション・サーバーを起動し、セッションおよびJSFの状態がシリアライズ可能であることを確認します。

-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree

次のようにbeansオプションを追加して、該当するマップのシリアライズ可能なオブジェクトのシリアライズされたコンテンツがリクエスト中に変更された場合に、そのオブジェクトがダーティとマークされたことをチェックします。

-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree,beans

JSFの状態がシリアライズ不能であることが検出された場合は、次のシステム・プロパティを使用してアプリケーション・サーバーを再起動し、コンポーネントとプロパティのフラグを有効にしてからテストを再実行します。

-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all

これらはJavaシステム・プロパティで、アプリケーション・サーバーを起動する際にこれらを指定する必要があります。

55 Fusion Webアプリケーションのデプロイ

この章では、ターゲット・アプリケーション・サーバーにOracle ADFアプリケーションをデプロイする方法を説明します。デプロイメント・プロファイルを作成する方法、デプロイメント・ディスクリプタを作成する方法、およびADFランタイム・ライブラリをロードする方法も説明します。アプリケーションを統合WebLogic Serverで実行する手順、およびスタンドアロンOracle WebLogic Serverにデプロイする手順についても説明します。

この章の内容は次のとおりです。

- Fusion Webアプリケーションのデプロイについて

- 統合WebLogic ServerでのFusion Webアプリケーションの実行

- アプリケーションの準備

- アプリケーションのデプロイ

- デプロイメント後の構成

- アプリケーションのテストとデプロイの検証

55.1 Fusion Webアプリケーションのデプロイについて

デプロイは、アプリケーション・ファイルをアーカイブ・ファイルとしてパッケージ化し、ターゲット・アプリケーション・サーバーに転送するプロセスです。JDeveloperを使用して、Oracle ADFアプリケーションをアプリケーション・サーバー(Oracle WebLogic Serverなど)に直接デプロイしたり、間接的にアーカイブ・ファイルをデプロイメント・ターゲットにしてデプロイしてから、そのアーカイブ・ファイルをターゲット・サーバーにインストールできます。アプリケーション開発の際には、JDeveloperを使用して、統合WebLogic Serverでアプリケーションを実行することもできます。JDeveloperではサーバー・クラスタへのデプロイがサポートされていますが、JDeveloperを使用して、クラスタのメンバーである個々の管理対象サーバーにデプロイすることはできません。

図55-1に、デプロイ処理全体を説明したフロー・ダイアグラムを示します。ADFランタイムのインストールによるデプロイ用のターゲット・アプリケーション・サーバーの準備については、『Oracle ADFアプリケーションの管理』を参照してください。

図55-1 デプロイの概要フロー・ダイアグラム

注意:

通常、JDeveloperは開発やテストの目的でアプリケーションをデプロイする場合に使用します。Oracle ADFアプリケーションを本番用にデプロイする場合は、Enterprise Managerまたはスクリプトを使用して、本番レベルのアプリケーション・サーバーにデプロイできます。

後期段階のテスト環境または本番環境へのデプロイの詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

ADF Java EEアプリケーションは、標準化されたモジュール型コンポーネントに基づいており、次のアプリケーション・サーバーにデプロイできます。

- Oracle WebLogic Server
Oracle WebLogic Serverは、そうしたモジュール用のサービス一式を備えており、細かいアプリケーション動作の多くを自動的に処理するため、プログラミングは必要ありません。JDeveloperと互換性のあるOracle WebLogic Serverのバージョンについては、動作保証情報のWebサイト(http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html)を参照してください。

- IBM WebSphereアプリケーション・サーバー
互換性のあるIBM WebSphereのバージョンについては、を参照してください。

Fusion Webアプリケーションのデプロイは、標準的なJava EEアプリケーションのデプロイとは多少異なります。ADF Facesコンポーネントを含むJSFアプリケーションには、次の追加デプロイ要件があります。

- ADF Facesには、SunのJSF Reference Implementation 1.2およびMyFaces 1.0.8(またはそれ以降)が必要です。

JDeveloperを使用して、次の作業を実行できます。

- 統合WebLogic Serverでのアプリケーションの実行
統合WebLogic Serverを使用してアプリケーションを実行およびデバッグし、スタンドアロンWebLogic Serverにデプロイできます。

- スタンドアロン・アプリケーション・サーバーへの直接デプロイ
アプリケーションをスタンドアロン・アプリケーション・サーバーに直接デプロイするには、サーバーへの接続を作成し、そのサーバーの名前をデプロイメント・ターゲットとして選択します。

- アーカイブ・ファイルへのデプロイ
デプロイメント・ターゲットとしてEARファイルを選択することによって、間接的にアプリケーションをデプロイすることができます。アーカイブ・ファイルは、ターゲット・アプリケーション・サーバーに後でインストールできます。

Oracle ADFのSummitサンプル・アプリケーションに、Fusion Webアプリケーション・テクノロジ・スタックを使用してトランザクション・ベースのWebアプリケーションを作成する方法が示されています。Summitサンプル・アプリケーションは、統合WebLogic Serverを使用してJDeveloperで実行できます。Summit ADFサンプル・アプリケーションの詳細は、「ADFサンプル・アプリケーションの概要」を参照してください。

55.1.1 統合WebLogic Serverを使用したアプリケーションの開発

JDeveloperでアプリケーションを開発していて、統合WebLogic Serverでアプリケーションを実行する場合、Oracle WebLogic Serverに直接、またはアーカイブ・ファイルにデプロイするために必要なタスクを実行する必要はありません。JDeveloperには統合WebLogic Serverへのデフォルトの接続があるため、デプロイメント・プロファイルやデプロイメント・ディスクリプタは不要です。統合WebLogic Serverには、Oracle ADFアプリケーションの実行に必要なADFライブラリを含む事前構成済ドメイン、および-Djps.app.credential.overwrite.allowed=trueの設定が用意されています。JDeveloperのメイン・メニューから「実行」を選択すれば、アプリケーションを実行できます。

「ADFコンポーネントのテストとデバッグ」で説明した機能を使用して、アプリケーションをデバッグできます。

55.1.2 スタンドアロン・アプリケーション・サーバーにデプロイするためのアプリケーションの開発

通常、スタンドアロン・サーバーにデプロイするためには、統合WebLogic Serverでアプリケーションを実行してテストと開発を行います。その後、アプリケーションをスタンドアロンのOracle WebLogic Serverに開発モードでデプロイして本番環境を厳密にシミュレートし、アプリケーションのテストをさらに実施することができます。

一般にJDeveloperでは、次の作業を行って、デプロイに向けてアプリケーションまたはプロジェクトを準備します。

- ターゲット・アプリケーション・サーバーへの接続の作成

- デプロイメント・プロファイルを作成(必要な場合)

- デプロイメント・ディスクリプタを作成(必要な場合、およびターゲット・アプリケーション・サーバーに固有の場合)

- application.xmlとweb.xmlを更新してアプリケーション・サーバーとの互換性を確保(必要な場合)

- web.xmlでアプリケーションをReal User Experience Insight (RUEI)に対して有効化(希望する場合)

- アプリケーション・レベルのセキュリティ・ポリシー・データをドメインレベルのセキュリティ・ポリシー・ストアに移行

- Oracle Single Sign-On (Oracle SSO)を使用してWebアプリケーションを実行する場合は、ドメインのjps-config.xmlファイルでOracle SSOのサービスおよびプロパティを構成

アプリケーション・サーバーがすでにインストールされている必要があります。Oracle WebLogic Serverの場合は、Oracle 12c InstallerまたはOracle Fusion Middleware 12c Application Developer Installerを使用してインストールできます。他のアプリケーション・サーバーについては、対象アプリケーション・サーバーのドキュメントの説明に従ってサーバーを取得し、インストールしてください。

また、Fusion Webアプリケーションのデプロイに向けてアプリケーション・サーバーを準備する必要もあります。詳細は、『Oracle ADFアプリケーションの管理』のスタンドアロン・アプリケーション・サーバーのデプロイの準備に関する項を参照してください。

- ADFランタイムを使用して、Oracle WebLogic ServerドメインをADF互換に拡張

- WebLogicの場合は、必要に応じて、Oracle WebLogic Server資格証明ストアの上書きを設定(-Djps.app.credential.overwrite.allowed=true設定)。

- データ・ソースへの接続を必要とするアプリケーションのためのグローバルなJDBCデータ・ソースの作成

アプリケーションとアプリケーション・サーバーの準備が完了したら、次の作業を行うことができます。

- JDeveloperを使用して次を実行します。

- デプロイメント・プロファイルとアプリケーション・サーバー接続を使用して、アプリケーション・サーバーに直接デプロイします。

- デプロイメント・プロファイルを使用して、EARファイルにデプロイします。Oracle ADFアプリケーションの場合、WARファイルとMARファイルはEARファイルの一部としてのみデプロイできます。

- Enterprise Manager、スクリプト、またはアプリケーション・サーバーの管理ツールを使用して、JDeveloperで作成したEARファイルをデプロイします。詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

55.2 統合WebLogic ServerでのFusion Webアプリケーションの実行

JDeveloperは、統合WebLogic Serverとともにインストールされますが、この統合WebLogic Serverをアプリケーションのテストと開発に使用できます。開発目的では、統合WebLogic Serverで十分なことがほとんどです。アプリケーションをテストする準備が整ったら、実行ターゲットを選び、メイン・メニューから「実行」コマンドを選択します。

注意:

アプリケーションを統合WebLogic Serverで初めて実行する際、「デフォルト・ドメインの作成」ダイアログが表示され、新しいドメインの管理パスワードを定義します。

アプリケーション・ターゲットを実行すると、プロジェクトとワークスペースのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプが自動的に検出されます。次に、アプリケーションを統合WebLogic Serverにデプロイするためのメモリー内デプロイメント・プロファイルが作成されます。プロジェクトとアプリケーション・ワークスペースのファイルは、展開EARディレクトリ構造にコピーされます。このファイル構造は、アプリケーションをEARファイルにデプロイする場合のEARファイル構造を忠実に模したものです。続いて、標準のデプロイ手順に従って、展開EARファイルが統合WebLogic Serverに登録およびデプロイされます。展開EAR方式を取ることで、実際のEARファイルのパッケージ化とパッケージ化解除によって生じるパフォーマンス・オーバーヘッドが軽減されます。

要約すれば、実行ターゲットを選択して統合WebLogic Serverでアプリケーションを実行すると、JDeveloperによって次のことが行われます。

- プロジェクトとアプリケーションのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプを検出

- メモリー内にデプロイメント・プロファイルを作成

- プロジェクトとアプリケーションのファイルを、アプリケーションの展開EARファイルをシミュレートしたファイル構造を持つ作業ディレクトリにコピー

- 模擬EARを統合WebLogic Serverに登録およびデプロイするためのデプロイ・タスクを実行

- アイデンティティ、資格証明およびポリシーを自動的に移行
後で、スタンドアロンのWebLogic Serverインスタンスにアプリケーションをデプロイする予定がある場合は、このセキュリティ情報の移行が必要になります。詳細は、「ADFセキュリティを有効にしたアプリケーションのデプロイ方法」を参照してください。

注意:

統合WebLogic Serverでアプリケーションを実行する際、アプリケーションに対して作成されたデプロイメント・プロファイルは無視されます。

アプリケーションは、統合WebLogic Serverの基本ドメインで実行されます。この基本ドメインは、スタンドアロンのWebLogic Serverインスタンスの基本ドメインと同じ構成になっています。つまり、この基本ドメインは、Oracle Fusion Middleware構成ウィザードを使用して、スタンドアロンのWebLogic Serverインスタンスにデフォルト・オプションで基本ドメインを作成した場合と同一です。

JDeveloperでは、JDeveloperテクノロジ拡張に基づいて、この基本ドメインが必要なドメイン拡張テンプレートで拡張されます。たとえば、JDeveloper Studioをインストールした場合、統合WebLogic Server環境がADFランタイム・テンプレート(JRF Fusion Middlewareランタイム・ドメイン拡張テンプレート)で自動的に構成されます。

統合WebLogic Serverのデフォルト・ドメインを明示的に作成することもできます。このデフォルト・ドメインを使用して、アプリケーションを実行およびテストできます。「アプリケーション・サーバー」ウィンドウを開き、IntegratedWebLogicServerを右クリックして、「デフォルト・ドメインの作成」を選択します。

55.2.1 統合WebLogic Serverでのアプリケーションの実行方法

アプリケーションを統合WebLogic Serverで実行して、テストすることができます。ブレークポイントを設定して、ADF宣言デバッガでアプリケーションを実行することも可能です。

始める前に:

統合WebLogic Serverでアプリケーションを実行するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「統合WebLogic ServerでのFusion Webアプリケーションの実行」を参照してください。

統合WebLogic Serverでアプリケーションを実行するには:

1. 「アプリケーション」ウィンドウで、プロジェクト、バインドなしタスク・フロー、JSFページ、ファイルのいずれかを、実行ターゲットとして選択します。

2. 実行ターゲットを右クリックして、「実行」または「デバッグ」を選択します。

アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

55.2.2 統合WebLogic Serverでのメタデータを含むアプリケーションの実行方法

アプリケーションが統合WebLogic Serverで実行されている場合、MAR(メタデータ・アーカイブ)プロファイルそのものはリポジトリにデプロイされませんが、MARに含まれるメタデータ情報を反映した模擬MDSリポジトリがアプリケーション用に構成されます。このメタデータ情報はシミュレートされ、ソース・コントロール内のこの場所を基準にアプリケーションが実行されます。

アプリケーションによって作成されたカスタマイズ内容やドキュメントのうち、他のMDSリポジトリに格納するよう構成されていないものは、この模擬MDSリポジトリのディレクトリに書き込まれます。たとえば、オブジェクトをカスタマイズした場合、その内容は模擬MDSリポジトリに書き込まれます。新しいメタデータ・オブジェクトを作成するコードを実行した場合、この新しいメタデータ・オブジェクトも模擬MDSリポジトリの同じ場所に書き込まれます。このディレクトリは、デフォルトの場所(ORACLE_HOME\jdeveloper\systemXX.XX\o.mds.dt\adrs\Application\AutoGeneratedMar\mds_adrs_writedir)をそのまま使用することも、別のディレクトリに設定することも可能です。アプリケーションが複数回実行される間、このディレクトリをずっと保持するか、それとも各実行の前に削除するかも選択できます。

ワークスペースに異なるワーキング・セットがある場合、ワーキング・セットとその依存オブジェクトで定義されたプロジェクトのメタデータのみがMARに組み込まれます。「アプリケーション」ウィンドウでプロジェクトを右クリックして「プロジェクト・プロパティ」を選択し、「依存性」を選択すると、プロジェクトの依存性の表示または変更が行えます。たとえば、アプリケーションに複数のプロジェクトがあるが、workingsetAはviewcontroller2およびviewcontroller5として定義され、viewcontroller5はmodelproject1に依存しているとします。workingsetAを実行またはデバッグすると、viewcontroller2、viewcontroller5およびmodelproject1のメタデータのみがデプロイ用のMARに組み込まれます。

始める前に:

統合WebLogic Serverでメタデータを使用してアプリケーションを実行するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「統合WebLogic ServerでのFusion Webアプリケーションの実行」を参照してください。

次のタスクを完了する必要があります。

- JDeveloperによって手動または自動でMARプロファイルを作成。

MARプロファイルを統合WebLogic Serverにデプロイするには:

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックして、「アプリケーション・プロパティ」を選択します。

2. 「アプリケーションのプロパティ」ダイアログで、「実行」を展開して「MDS」を選択します。

3. 「MDSの実行」ページで、次の手順を実行します。

- 「MARプロファイル」ドロップダウン・リストからMARプロファイルを選択します。

- 模擬MDSリポジトリの場所をカスタマイズする場合は、「オーバーライド場所」にディレクトリ・パスを入力します。

- 「ディレクトリ・コンテンツ」オプションを選択します。アプリケーションが複数回実行される間、カスタマイズ内容を維持するか、それとも各実行の前にカスタマイズ内容を削除するかを選択できます。

「MARプロファイル」ドロップダウン・リストからMARプロファイルを選択します。図55-2は、MARプロファイルとして「Demometadata1」を選択したところを示しています。

図55-2 MDS実行オプションの設定

55.3 アプリケーションの準備

Fusion Webアプリケーションをスタンドアロン・アプリケーション・サーバーにデプロイする前に、JDeveloperで必須のタスクを実行し、デプロイに向けてアプリケーションを準備する必要があります。

図55-3に、アプリケーションをデプロイ用に準備する場合のプロセス・フローを示します。『Oracle ADFアプリケーションの管理』で説明されているようにアプリケーションが準備され、アプリケーション・サーバーが準備された後、「アプリケーションのデプロイ」の説明に従ってアプリケーションをデプロイできます。

図55-3 アプリケーションのデプロイ用の準備のフロー・ダイアグラム

55.3.1 ターゲット・アプリケーション・サーバーへの接続の作成方法

JDeveloperアプリケーション・サーバー接続を介して、アプリケーション・サーバーにアプリケーションをデプロイできます。

アプリケーションにMDSを使用したカスタマイズが加えられている場合は、MDSリポジトリをアプリケーション・サーバーに登録してください。

- WebLogicの場合: MDSをWebLogicドメインに登録
WebLogicでのMDSの登録の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

- WebSphereの場合: MDSをWebSphereセルに登録
WebSphereでのMDSの登録の詳細は、を参照してください。

MDSの登録の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

始める前に:

デプロイメント用のアプリケーションを準備するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- アプリケーション・サーバーのインストール。

アプリケーション・サーバーへの接続の作成方法:

1. 「アプリケーション・サーバー接続」ウィザードを起動します。

次の操作を実行できます。

- 「アプリケーション・サーバー」ウィンドウで、「アプリケーション・サーバー」を右クリックして、「新規アプリケーション・サーバー」を選択します。

- 「新規ギャラリ」で、「一般」を展開し、「接続」→「アプリケーション・サーバー接続」を選択して、「OK」をクリックします。

- 「リソース」ウィンドウで、「新規」→「IDE接続」→「アプリケーション・サーバー」を選択します。

2. 「使用方法」ページの「アプリケーション・サーバー接続の作成」ダイアログで、「スタンドアロン・サーバー」を選択し、「次へ」をクリックします。

3. 「名前とタイプ」ページで、接続名を入力します。

4. 「接続タイプ」ドロップダウン・リストで、次を選択します。

- Oracle WebLogic Serverへの接続を作成する場合は「WebLogic」

- IBM WebSphere Serverへの接続を作成する場合は「WebSphere Server 7.x」

5. 「次へ」をクリックします。

6. 「認証」ページで、アプリケーション・サーバーへのアクセスを認可された管理ユーザーのユーザー名とパスワードを入力します。

7. 「次へ」をクリックします。

8. 「構成」ページで、次のサーバー情報を入力します。

WebLogicの場合:

- Oracle WebLogicホスト名は、アプリケーション(.jar、.war、.ear)がデプロイされるTCP/IP DNSを含む、WebLogic Serverインスタンスの名前です。

- 「ポート」フィールドに、アプリケーション(.jar、.war、.ear)がデプロイされるWebLogic Serverインスタンスのポート番号を入力します。
ポートを指定しない場合、ポート番号はデフォルトの7001になります。

- 「SSLポート」フィールドに、アプリケーション(.jar、.war、.ear)がデプロイされるWebLogic ServerインスタンスのSSLポート番号を入力します。
SSLポートの指定はオプションです。デプロイメント時に確実にセキュア接続にする場合にのみ必要です。

ポートを指定しない場合、SSLポート番号はデフォルトの7002になります。

- SSLポートを使用してWebLogic Serverインスタンスに接続するために、「常にSSLを使用」を選択します。

- オプションで、管理権限のないサーバー・ノードをWebLogic Serverが名前で識別するように構成されている場合のみ、WebLogicドメインを入力します。

WebSphereの場合:

- 「ホスト名」フィールドに、Java EEアプリケーション(.jar、.war、.ear)がデプロイされる、TCP/IP DNSを含むWebSphereサーバーの名前を入力します。名前を入力しない場合は、デフォルトのlocalhostになります。

- 「SOAPコネクタのポート」フィールドに、ポート番号を入力します。このホスト名とポートが、デプロイ用にサーバーへの接続に使用されます。デフォルトのSOAP接続ポートは8879です。

- 「サーバー名」フィールドに、この接続のターゲット・アプリケーション・サーバーに割り当てられた名前を入力します。

- 「ターゲット・ノード」フィールドに、この接続のターゲット・ノード名を入力します。ノードとは、管理対象サーバーのグループです。デフォルトはmachineNode01で、この場合のmachineはノードが常駐するマシンの名前です。

- 「ターゲット・セル」フィールドに、この接続のターゲット・セルの名前を入力します。セルとは、ランタイム・コンポーネントをホストするプロセスのグループです。デフォルトはmachineNode01Cellで、この場合のmachineはノードが常駐するマシンの名前です。

- 「WS管理スクリプト・ファイルの場所」フィールドに、IBM WebSphereアプリケーション・サーバー接続のシステム・ログイン構成を定義するために使用するwsadminスクリプト・ファイルの場所を入力するか、参照して指定します。ORACLE_HOME/oracle_common/common/binディレクトリにあるwsadminファイルは、バージョンが正しくないため、使用しないでください。デフォルトの場所は、Unix/Linuxの場合はwebsphere-home/bin/wsadmin.sh、Windowsの場合はwebsphere-home/bin/wsadmin.batです。

9. 「次へ」をクリックします。

10. WebSphereを選択した場合は、「JMX」ページが表示されます。「JMX」ページで、JMXの情報を入力します(オプション)。

注意:

JMXの構成はオプションで、WebSphere Application Serverへの接続には必要ありません。JMXはSOAアプリケーションのデプロイにのみ必要です。

- 「この接続のJMXの有効化」を選択してJMXを有効にします。

- 「RMIポート」フィールドに、WebSphereのRMI接続ポートのポート番号を入力します。デフォルトは2809です。

- 「WebSphereランタイムJARの場所」フィールドに、WebSphereランタイムJARの場所を入力するか、参照して指定します。

- 「WebSphereプロパティの場所(セキュアなMBeanアクセス用)」フィールドに、セキュリティ構成および有効なMBeanのプロパティを含むファイルの場所を入力するか、参照して指定します。このフィールドはオプションです。

11. 「次へ」をクリックします。

12. SSL署名者交換ダイアログが表示される場合は、「Y」をクリックします。

13. テスト・ページで、「接続のテスト」をクリックして、接続をテストします。

JDeveloperにより、数種類の接続テストが実行されます。アプリケーションをデプロイできるためには、JSR-88テストに合格する必要があります。テストに不合格だった場合は、ウィザードの前のページに戻って、構成を修正します。

14. 「終了」をクリックします。

55.3.2 デプロイメント・プロファイルの作成方法

デプロイメント・プロファイルでは、ターゲット環境にデプロイされるアーカイブにアプリケーションがパッケージ化される方法が定義されています。デプロイメント・プロファイルには、次の役割があります。

- 作成されるアーカイブ・ファイルのフォーマットと内容を指定します。

- パッケージ対象となるソース・ファイル、デプロイメント・ディスクリプタ、およびその他の補助ファイルをリストします。

- 作成されるアーカイブ・ファイルのタイプおよび名前を記述します。

- 依存情報、プラットフォーム固有の指示、およびその他の情報を示します。

アプリケーションにデプロイするWebユーザー・インタフェース・プロジェクトそれぞれにWARデプロイメント・プロファイルが必要です。シード・カスタマイズをパッケージ化する場合や、ベース・メタデータをMDSリポジトリに保存する場合は、アプリケーション・レベルのメタデータ・アーカイブ(MAR)・デプロイメント・プロファイルも必要になります。シード・カスタマイズの詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。アプリケーションにカスタマイズ・クラスがある場合は、そのクラスを格納するJARファイルが必要であり、EARファイルの作成時にそのJARを追加する必要があります。さらに、アプリケーション・レベルのEARデプロイメント・プロファイルも必要です。WARプロファイルやMARプロファイル、カスタマイズ・クラスのJARファイルなど、その中に組み込むプロジェクトをリストから選択する必要があります。アプリケーションがデプロイされるとき、EARファイルは、デプロイメント・プロファイルで選択されたすべてのプロジェクトを組み込みます。

注意:

ADF Fusion Web Applicationテンプレートを使用してプロジェクトまたはアプリケーションを作成する場合、JDeveloperによりデフォルトのWAR、EAR、MARおよびJARデプロイメント・プロファイルが自動的に作成されます。通常、デプロイメント・プロファイルを手動で編集または作成する必要はありません。

Oracle ADFアプリケーションの場合、アプリケーションはEARファイルとしてのみデプロイできます。デプロイメント・プロファイルを作成する際に、アプリケーションの一部となるWARファイルとMARファイルをEARファイルに組み込む必要があります。

注意:

デプロイするビジネス・サービスがFusion Webアプリケーションにある場合は、ビジネス・コンポーネント・サービス・インタフェース・デプロイメント・プロファイルを作成してデプロイする必要があります。ビジネス・サービスの詳細は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。

55.3.2.1 WARデプロイメント・プロファイルの作成

アプリケーションにパッケージ化するWebベースのプロジェクトごとに、WARデプロイメント・プロファイルを作成する必要があります。通常、WARプロファイルには必要な依存データ・モデル・プロジェクトが組み込まれます。

始める前に:

WARデプロイメント・プロファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- Webベースのプロジェクトを作成します。ADF Fusion Webアプリケーション・テンプレートを使用した場合は、すでにデフォルトのWARデプロイメント・ファイルが存在します。

アプリケーションのWARデプロイメント・プロファイルを作成するには:

1. 「アプリケーション」ウィンドウで、デプロイするWebプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

各WebプロジェクトのWARプロファイルを作成します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「WARファイル」を選択して、「OK」をクリックします。

「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- WARファイル 」ダイアログで、プロジェクト・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「WARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。

- アプリケーションにカスタマイズ・クラスがある場合は、カスタマイズ・クラスを、WARからではなくEARレベルのアプリケーション・クラス・ローダーからロードする必要があります。このカスタマイズ・クラスは後でEARに追加します。
デフォルトでは、データ・モデル・プロジェクトに実装されているカスタマイズ・クラスはデータ・モデル・プロジェクトのWARクラス・パスに追加されます。したがって、WARごとにカスタマイズ・クラスを除外する必要があります。

アプリケーションの拡張プロジェクトにカスタマイズ・クラスを作成し、「アプリケーションのプロパティ」ダイアログの「ライブラリとクラスパス」ページを使用してこれらを含めた場合、これらはデフォルトでEARレベルにパッケージ化されます。WARプロファイルからこれらを削除するためにこれ以上アクションは必要ありません。

ただし、アプリケーションのデータ・モデル・プロジェクトのカスタマイズ・クラスを作成した場合、これらはWARプロファイルから削除する必要があります。各ユーザー・インタフェース・プロジェクトの「WARデプロイメント・プロファイルのプロパティの編集」ダイアログの「フィルタ」ページでカスタマイズ・クラスを選択解除します。customization.propertiesファイルを使用する場合は、それも選択解除します。

- Java EE Webコンテキストのルート設定を変更する必要がある場合もあります。これを行うには、左側のペインで、「一般」を選択します。
デフォルトでは、「プロジェクトのJava EE Webコンテキスト・ルートを使用」が選択されている場合、関連付けられている値は、Application1-Project1-context-rootのようにプロジェクト名に設定されています。ユーザーに違う名前でアプリケーションにアクセスさせる場合は、この名前を変更する必要があります。

JAZNを使用した認証でカスタムのJAAS LoginModuleを使用している場合は、コンテキスト・ルート名によって、JAAS LoginModuleの検索に使用されるアプリケーション名も定義されます。

5. 「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。

6. 「OK」を再度クリックして、プロジェクト・プロパティのダイアログを終了します。

7. デプロイするすべてのWebプロジェクトに対して、手順1から7を繰り返します。

55.3.2.2 MARデプロイメント・プロファイルの作成

MDSリポジトリに保存するシード・カスタマイズやベース・メタデータがある場合は、MARデプロイメント・プロファイルを作成する必要があります。

adf-config.xmlファイルの<mds-config>におけるMARコンテンツのネームスペース構成は、「MARデプロイメント・プロファイルのプロパティ」ダイアログでの選択内容に基づいて生成されます。

まれなことですが、1つのエンタープライズ・アプリケーション(1つのEARにパッケージ化)に複数のWebアプリケーション・プロジェクト(複数のWARにパッケージ化)が含まれている場合があります。しかし、このようなWebアプリケーションのメタデータはすべて、単一のメタデータ・アーカイブ(MAR)にパッケージ化されます。これらそれぞれの個別のWebアプリケーションから取り込まれたメタデータは、グローバル(すべてのWebアプリケーションで使用可能)である場合と、その特定のWebアプリケーションに対してローカルの場合があります。

グローバル・スコープを持つメタデータの名前の競合を防止するために、すべてのメタデータ・オブジェクトおよび要素が、アプリケーション全体の一部を形成するすべてのWebアプリケーション・プロジェクトを通して一意の名前を持つようにします。

「プロジェクト・プロパティ」ダイアログの「ADFビュー」ページで「ユーザー・カスタマイズの有効化」オプションと「MDSを使用したセッション間」オプションを選択した場合、またはadf-config.xmlファイルにデプロイメント・ターゲット・ディレクトリを明示的に指定した場合は、自動生成MARが作成されます。

始める前に:

MARデプロイメント・プロファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- MARデプロイメント・プロファイルを使用してメタデータをデプロイするために、カスタマイズ要件を考慮したMDSリポジトリを作成します。詳細は、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項を参照してください。ADF Fusion Web Applicationテンプレートを使用した場合は、すでにデフォルトのMARデプロイメント・ファイルが存在します。

MARデプロイメント・プロファイルを作成するには:

1. 「アプリケーション」ウィンドウで、MARプロファイルを作成するアプリケーションを右クリックし、「新規」→「ギャラリから」をクリックします。

カスタマイズ内容を組み込む場合は、MARプロファイルを作成します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「MARファイル」を選択して、「OK」をクリックします。

「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- MARファイル」ダイアログで、MARデプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「MARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。

図55-4に、サンプルの「ユーザー・メタデータ」ディレクトリ・ツリーを示します。

図55-4 MARデプロイメント・プロファイルの項目の選択

次の重要な点に注意してください。

- すべてのカスタマイズ内容を組み込む場合は、目的のディレクトリを含むファイル・グループを作成するだけで済みます。

- ADFモデルとADFビューのディレクトリはデフォルトで追加されます。ADFモデルとADFビューのカスタマイズ内容をMARにパッケージ化するために必要な作業はこれだけです。ADFビューの内容はHTMLルート・ディレクトリに追加され、ADFモデルとビジネス・コンポーネントの内容はユーザー・メタデータに追加されます。

- MDSリポジトリにベース・メタデータを組み込む場合は、対象となるディレクトリをダイアログで明示的に選択する必要があります。
MARに組み込むベース・ドキュメントを選択する際に、個々のパッケージも選択します。パッケージを1つ選択すると、そのパッケージの下にあるすべてのドキュメント(サブパッケージを含む)が使用されます。パッケージを選択したときに、その下の個々の項目を選択解除することはできません。

- ADFモデルとADFビュー以外のファイルを組み込む場合は、目的のディレクトリを含む「ユーザー・メタデータ」の下に新しいファイル・グループを作成し、「ディレクトリ」ページで必要なコンテンツを明示的に選択する必要があります。

- プロジェクトの依存ADFライブラリJARにシード・カスタマイズが含まれている場合、そのシード・カスタマイズはMARのパッケージ化中にMARに自動的に追加されます。MARプロファイルには表示されません。

- ADFライブラリのカスタマイズ内容が使用側プロジェクトのコンテキストで作成された場合、そのカスタマイズ内容はMARプロファイルのダイアログにデフォルトで表示されます。

5. 「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。

6. 「OK」を再度クリックして、アプリケーション・プロパティのダイアログを終了します。

55.3.2.3 アプリケーション・レベルのEARデプロイメント・プロファイルの作成

EARファイルには、アプリケーション・サーバーでアプリケーションを実行するために必要なアプリケーション・アーティファクトがすべて含まれています。ADF Fusion Webアプリケーション・テンプレートを使用した場合は、すでにデフォルトのEARデプロイメント・ファイルが存在します。EARファイルの詳細は、「EARファイルとパッケージ化に関する必知事項」を参照してください。

始める前に:

EARデプロイメント・プロファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

1. 「JARへのカスタマイズ・クラスの追加」の説明に従って、JARファイルにクラスを追加します。

2. 「WARデプロイメント・プロファイルの作成」の説明に従って、WARデプロイメント・プロファイルを作成します。

アプリケーションのEARデプロイメント・プロファイルを作成するには:

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックして、「新規」→「ギャラリから」を選択します。
アプリケーションのEARプロファイルを作成します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「EARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- EARファイル」ダイアログで、アプリケーション・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。
次の手順を必ず実行してください。

- 「アプリケーション・アセンブリ」を選択し、続いて「Java EEモジュール」リストで、デプロイメントに組み込むすべてのプロジェクト・プロファイルを選択します(WARまたはMARプロファイルを含む)。

- 「プラットフォーム」を選択し、デプロイ先となるアプリケーション・サーバーを選択した後、「ターゲット接続」ドロップダウン・リストから、ターゲット・アプリケーション接続を選択します。

注意:

JAZNを使用した認証でカスタムのJAAS LoginModuleを使用している場合は、コンテキスト・ルート名によって、JAAS LoginModuleの検索に使用されるアプリケーション名も定義されます。

5. アプリケーションにカスタマイズ・クラスがある場合は、そのクラスがEARレベルのアプリケーション・クラス・ローダーからロードされるように構成する必要があります。

注意:

アプリケーションの拡張プロジェクトにカスタマイズ・クラスを作成し、「アプリケーションのプロパティ」ダイアログの「ライブラリとクラスパス」ページを使用してこれらを含めた場合、これらはデフォルトでEARレベルにパッケージ化されるため、この手順は不要です。

a. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「アプリケーション・アセンブリ」を選択します。

b. カスタマイズ・クラスを含むJARデプロイメント・プロファイルを選択して、ダイアログの一番下にある「EARのパス」フィールドにlibを入力します。

注意:

このJARは、「JARへのカスタマイズ・クラスの追加」の説明に従って作成したものです。

カスタマイズ・クラスを含むJARファイルが、EARファイルのlibディレクトリに追加されます。

注意:

アプリケーションにカスタマイズ・クラスがある場合は、カスタマイズ・クラスがWARからロードされないようにする必要があります。デフォルトでは、データ・モデル・プロジェクトのライブラリおよびクラスパスに追加されるカスタマイズ・クラスは、WARクラス・パスにパッケージ化されます。

カスタマイズ・クラスをコンシューミング・アプリケーションのデータ・モデル・プロジェクトで作成した場合は、「WARデプロイメント・プロファイルのプロパティの編集」ダイアログの「フィルタ」ページですべてのカスタマイズ・クラスを選択解除します。

6. 再度「OK」をクリックして、「EARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。

7. 「OK」を再度クリックして、アプリケーション・プロパティのダイアログを終了します。

注意:

カスタマイズ・クラスがEARクラス・パスに正しく追加されていることを検証するには、EARプロファイルをファイル・システムにデプロイします。その後、EARを調べ、カスタマイズ・クラスJARがEARクラス・パス(EAR/libディレクトリ)で使用でき、WARクラス・パス(WEB-INF/libディレクトリおよびWEB-INF/classesディレクトリ)で使用できないことを確認します。

55.3.2.4 JARへのカスタマイズ・クラスの追加

アプリケーションにカスタマイズ・クラスがある場合は、そのカスタマイズ・クラスのみを格納するJARを作成します。このJARは、EARを作成する際にEARアセンブリに追加できます。WebプロジェクトのWARプロファイルを作成する場合は、このプロファイルにカスタマイズ・クラスのJARを組み込まないようにする必要があります。

始める前に:

カスタマイズ・クラスを追加するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- プロジェクトにカスタマイズ・クラスがあることを確認します。アプリケーションにカスタマイズ・クラスがない場合、この手順を実行する必要はありません。カスタマイズ・クラスの詳細は、「カスタマイズ・クラスの作成方法」を参照してください。

JARにカスタマイズ・クラスを追加するには:

1. 「アプリケーション」ウィンドウで、JARを作成するカスタマイズ・クラスを含むデータ・モデル・プロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」、「JARファイル」の順に選択して、「OK」をクリックします。

または、共有ライブラリを作成する場合は、プロファイル・タイプのリストから「共有ライブラリJARファイル」を選択し、「OK」をクリックします。

注意:

「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- JARファイル」ダイアログで、プロジェクト・デプロイメント・プロファイルの名前(CCArchiveなど)を入力して、「OK」をクリックします。

4. 「JARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「JARオプション」を選択します。

5. JARファイルの場所を入力します。

6. ファイル・グループ→「プロジェクトの出力」→「フィルタ」を開き、JARに含むように選択できるファイルを一覧表示します。

7. 「フィルタ」ページの「ファイル」タブで、JARファイルに追加するカスタマイズ・クラスを選択します。

customization.propertiesファイルを使用する場合は、このファイルがJARファイルと同じクラス・ローダーにあることが必要です。customization.propertiesファイルを選択して、カスタマイズ・クラスとともに同じJARにパッケージ化することができます。

8. 「OK」をクリックして、「JARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。

9. 「OK」を再度クリックして、プロジェクト・プロパティのダイアログを終了します。

10. 「アプリケーション」ウィンドウで、JARデプロイメント・プロファイルを含むプロジェクトを右クリックし、「デプロイ」→「deployment profile」→「JARファイルへ」を選択します。

注意:

デプロイメント・プロファイルからJARに初めてデプロイする場合は、ウィザードで「デプロイ」→「デプロイメント・プロファイル」を選択し、「JARにデプロイ」を選択します。

55.3.2.5 共有ライブラリとしてのカスタマイズ・クラスの配布

「アプリケーションレベルのEARデプロイメント・プロファイルの作成」で説明しているように、カスタマイズ・クラスをEARに追加する別の方法として、カスタマイズ・クラスを共有ライブラリとしてコンシューミング・アプリケーションに追加することもできます。

注意:

この手順では、Oracle Weblogic Serverにデプロイする場合の、共有ライブラリの作成および使用方法について説明します。

始める前に:

カスタマイズ・クラス用に共有ライブラリを作成および使用するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- JDeveloperをStudio開発者ロールで使用して、カスタマイズ・クラスをJARに追加します。「JARへのカスタマイズ・クラスの追加」に記載されている手順に従って、作成するアーカイブのタイプとして「共有ライブラリJARファイル」を選択していることを確認します。

カスタマイズ・クラスの共有ライブラリを作成および使用するには:

1. 「アプリケーション」ウィンドウで、カスタマイズ・クラス・プロジェクトを右クリックし、「デプロイ」→「deployment-profile」を選択します。

2. 「デプロイ」ウィザードで、「アプリケーション・サーバーへのデプロイ」を選択し、「次へ」をクリックします。

3. 適切なアプリケーション・サーバーを選択し、「終了」をクリックします。

これにより、共有ライブラリがアプリケーション・サーバーで使用できるようになります。次に、コンシューミング・アプリケーションから共有ライブラリへの参照を追加する必要があります。

4. JDeveloperのStudio開発者ロールで、カスタマイズするアプリケーションを開きます。

5. 「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、weblogic-application.xmlファイルをダブルクリックします。

6. 概要エディタで、「ライブラリ」ナビゲーション・タブをクリックします。

7. 「ライブラリ」ページで、「共有ライブラリ参照」セクションで、「追加」アイコンをクリックします。

8. 「共有ライブラリ参照」表に新たに作成された行の「ライブラリ名」フィールドに、デプロイしたカスタマイズ・クラスの共有ライブラリの名前を入力し、変更を保存します。

55.3.2.6 デプロイメント・プロファイル・プロパティの表示および変更

デプロイメント・プロファイルを作成したら、そのプロパティを表示および変更できます。

始める前に:

デプロイメント・プロファイルを表示するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

プロジェクトのデプロイメント・プロファイルを作成、編集、または削除するには:

1. 「アプリケーション」ウィンドウで、表示または編集するプロジェクトを右クリックして「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「デプロイ」をクリックします。

「デプロイメント・プロファイル」リストには、現在プロジェクトに定義されているすべてのプロファイルが表示されます。

3. 「デプロイメント・プロファイル」セクションで、デプロイメント・プロファイルを選択します。

4. 「編集」または「削除」をクリックして、デプロイメント・プロファイルを編集または削除します。

55.3.3 デプロイメント・ディスクリプタの作成および編集方法

デプロイメント・ディスクリプタは、アプリケーションのデプロイ構成を定義するサーバー構成ファイルで、必要に応じてJava EEアプリケーションとともにデプロイされます。プロジェクトに必要なデプロイメント・ディスクリプタは、プロジェクトが使用しているテクノロジとターゲット・アプリケーション・サーバーのタイプによって異なります。デプロイメント・ディスクリプタは、ソース・ファイルとして作成および編集できるXMLファイルですが、JDeveloperは、ほとんどのディスクリプタ・タイプについて、プロパティの表示と設定に使用できるダイアログまたは概要エディタを備えています。これらのファイルを宣言的に編集できない場合、その内容を編集できるようにソースエディタでXMLファイルが開きます。

標準のJava EEデプロイメント・ディスクリプタ(application.xmlおよびweb.xmlなど)に加えて、ターゲット・アプリケーション・サーバーに固有のデプロイメント・ディスクリプタも使用できます。たとえば、Oracle WebLogic Serverにデプロイする場合、weblogic.xml、weblogic-application.xmlおよびweblogic-ejb-jar.xmlを使用できます。

WebLogic Serverの場合は、アプリケーションのEARファイルに、adf.oracle.domainへの参照を含むweblogic-application.xmlファイルが組み込まれていること、そしてデプロイ作業とアンデプロイ作業の間にアプリケーション・リソースをクリーンアップするためのADFApplicationStateListenerが組み込まれていることを確認してください。次の例は、weblogic-application.xmlファイルのサンプルを示しています。

<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-application">
<listener>
<listener-class>oracle.adf.share.weblogic.listeners.
ADFApplicationStateListener</listener-class>
</listener>
<listener>
<listener-class>oracle.mds.lcm.weblogic.WLLifecycleListener</listener-class>
</listener>
<library-ref>
<library-name>adf.oracle.domain</library-name>
</library-ref>
</weblogic-application>

Webサービスをデプロイする場合は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」の説明に従って、weblogic-application.xmlファイルとweb.xmlファイルを変更する必要が生じることがあります。

アプリケーションに対してReal User Experience Insight (RUEI)によるモニタリングを行えるようにするには、「RUEIの適用とクリック履歴の有効化」の説明に従って、web.xmlファイルにパラメータを追加する必要があります。

デプロイ時には、アプリケーションとともにEARファイルにデプロイされるweblogic-application.xmlファイルに、アプリケーションのセキュリティ・プロパティが書き込まれます。詳細は、「セキュリティ・デプロイメント・オプション構成時の処理」を参照してください。

Oracle WebLogic ServerはJava EEプラットフォーム上で動作するため、application.xmlファイルとweb.xmlファイルを変更してアプリケーション・サーバーと互換性を持たせることが必要になる場合があります。

IBM WebSphereの場合は、デプロイメント・ディスクリプタが実行時に作成されますが、これを編集することはできません。一部の関連するディスクリプタを表55-1に示します。

表55-1 IBM WebSphereのデプロイメント・ディスクリプタ

WebSphere

アクション

ibm-application-bnd.xml

application.xmlでマップされたセキュリティ・ロールを参照し、これを定式名AllAuthenticatedUsersにマップします。WebLogic Serverのweblogic.xmlと似ています。JEEのセキュリティ・ロールであるvalid-usersを定式名Usersにマップします。

application.xml

標準Java EEデプロイメントの説明「valid-users」ロール(ADFセキュリティの使用時にweb.xmlに定義される)のセキュリティ・マッピングの移入にも使用されます。

<EAR_ROOT>/META-INF/manifest.mf

adf.oracle.domainなどのアプリケーション共有ライブラリを参照します。

<EAR_ROOT>/META-INF/deployment.xml

adf.oracle.domain.webappなどのWAR共有ライブラリを参照します。

55.3.3.1 デプロイメント・ディスクリプタの作成

必要なデプロイメント・ディスクリプタの多くは、自動的に作成されます。必要なデプロイメント・ディスクリプタが存在しない場合や、追加のディスクリプタを作成する必要がある場合は、JDeveloperを使用して作成できます。

始める前に:

デプロイメント・ディスクリプタを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- デプロイメント・ディスクリプタがすでに生成されているかどうかを確認します。

デプロイメント・ディスクリプタの作成方法:

1. 「アプリケーション」ウィンドウで、ディスクリプタを作成するプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」、ディスクリプタ・タイプの順に選択して、「OK」をクリックします。

目的の項目が見つからない場合は、正しいプロジェクトが選択されていることを確認してから「すべての機能」タブを選択するか、「検索」フィールドを使用してディスクリプタを検索します。項目が有効になっていない場合は、そのタイプのディスクリプタがプロジェクトにまだ存在しないことを確認します。1つのプロジェクトで使用できるディスクリプタのインスタンスは1つのみです。

「デプロイメント・ディスクリプタの作成」ウィザードが起動し、選択したデプロイメント・ディスクリプタのタイプに応じて、概要エディタまたはソース・エディタでファイルが開きます。

注意:

EARファイルの場合は、1つのアプリケーションまたはワークスペースに同じタイプの複数のデプロイメント・ディスクリプタを作成しないでください。これらのファイルはプロジェクトに割当て可能ですが、アプリケーション・ワークスペース・スコープがあります。アプリケーションの複数のプロジェクトが同じデプロイメント・ディスクリプタを使用すると、起動されたプロジェクトに属するディスクリプタが他のディスクリプタより優先されます。この制約は、application.xml、weblogic-jdbc.xml、jazn-data.xmlおよびweblogic.xmlに適用されます。

アプリケーション・レベルのディスクリプタを作成するのに最適な場所は、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」ノードです。アプリケーションは、確実に、正しいディスクリプタとともに作成されます。

プロジェクトで作成されたアプリケーション・レベル・ディスクリプタは、実行時に無視されます。実行時には、アプリケーション・リソースのディスクリプタ、またはEARレベルで生成されたディスクリプタのみが使用されます。

55.3.3.2 デプロイメント・ディスクリプタ・プロパティの表示または変更

デプロイメント・ディスクリプタを作成したら、JDeveloperの各種ダイアログを使用するか、ソース・エディタでファイルを編集することで、そのプロパティを変更できます。デプロイメント・ディスクリプタは、通常「アプリケーション・ソース」ノードにあるXMLファイル(application.xmlなど)です。

始める前に:

デプロイメント・ディスクリプタを表示するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

デプロイメント・ディスクリプタのプロパティの表示または変更方法:

1. 「アプリケーション」ウィンドウまたは「アプリケーション・リソース」パネルで、デプロイメント・ディスクリプタをダブルクリックします。

2. エディタ・ウィンドウで、「概要」タブまたは「ソース」タブを選択し、プロパティ値を設定してディスクリプタを構成します。

概要エディタが使用できない場合は、ソース・エディタでファイルが開きます。

55.3.3.3 アプリケーション・サーバー互換のapplication.xmlファイルの構成

ご使用のJava EEバージョンに準拠するようにapplication.xmlファイルを構成しなければならないことがあります。

注意:

通常、プロジェクトには互換性のあるapplication.xmlファイルがあるため、この手順を実行する必要はありません。

始める前に:

application.xmlの構成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

application.xmlファイルを構成するには:

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックして、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」→「Java EEデプロイメント・ディスクリプタ・ウィザード」を選択して、「OK」をクリックします。

3. 「Java EEデプロイメント・ディスクリプタの作成」ダイアログの「ディスクリプタの選択」ページで、「application.xml」を選択して、「次へ」をクリックします。

4. 「バージョンの選択」ページで、Java EE 5.0以上と互換性を持たせるために「5.0」を選択し、「次へ」をクリックします。

5. 「サマリー」ページで「終了」をクリックします。

6. application.xmlファイルを適切な値で編集します。

55.3.3.4 アプリケーション・サーバー互換のweb.xmlファイルの構成

ご使用のJava EEバージョンに準拠するようにweb.xmlファイルを構成しなければならないことがあります。詳細は、「web.xml」を参照してください。

注意:

通常、プロジェクトには互換性のあるweb.xmlファイルがあるため、この手順を実行する必要はありません。プロジェクトを作成すると、初期のweb.xmlファイルが自動的に作成されます。

アプリケーションでADFセキュリティが使用され、WebSphereにデプロイされる場合は、web.xmlファイルを手動で編集する必要があります。詳細は、「web.xmlファイルの編集によるWebSphereのアプリケーション・ルートの保護」を参照してください。

始める前に:

web.xmlの構成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

web.xmlファイルを構成するには:

1. 「アプリケーション」ウィンドウで、web.xmlファイルを構成するプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」→「Java EEデプロイメント・ディスクリプタ」を選択して、「OK」をクリックします。

3. 「Java EEデプロイメント・ディスクリプタの作成」ダイアログの「ディスクリプタの選択」ページで、「web.xml」を選択して、「次へ」をクリックします。

4. 「バージョンの選択」ページで、使用するバージョンを選択し、「次へ」をクリックします。

バージョン3.0はJava EE 6.0以上と互換性があり、バージョン2.5はJava EE 5.0と互換性があります。

5. 「サマリー」ページで「終了」をクリックします。

55.3.3.5 RUEIの適用とクリック履歴の有効化

Real User Experience Insight (RUEI)はWebベースのユーティリティで、ネットワークからリクエストされる、またはネットワークで生成される実際のユーザーのトラフィックに対してレポートを作成します。ネットワーク・インフラストラクチャの最も重要となるポイントで、ページやトランザクションのレスポンス時間を測定します。セッション診断情報を使用すれば、根本原因分析を実行できます。

RUEIでは、実際のユーザー体験に基づいてサーバーおよびネットワーク時間を表示し、キー・パフォーマンス・インディケータ(KPI)とサービス・レベル合意(SLA)をモニターし、定義済のターゲットに違反するインシデントが発生した場合にアラート通知をトリガーすることが可能です。ページ・コンテンツ、サイト・エラー、およびトランザクションの機能要件に関するチェックを実施できます。この情報を使用することで、業務面、技術面から運用を検証できます。RUEIで認識されるすべての項目の可用性、スループットおよびトラフィックに関して、カスタム・アラートを設定することもできます。

RUEIの詳細は、http://www.oracle.com/technetwork/documentation/realuserei-091455.htmlにあるOracle Real User Experience Insightドキュメントを参照してください。

クリック履歴は、ボタンのクリックやマウスのスクロールなどのUIコンポーネントに対するユーザー・アクションをレポートする、ADFに組み込まれた機能です。クリック履歴は、web.xmlおよびweblogic.xmlファイルを使用してWebLogicサーバーで、またアプリケーション内で有効にする必要があります。

クリック履歴の詳細およびそれをWebLogicサーバーで有効にする方法は、『Oracle ADFアプリケーションの管理』のクリック履歴に関する項を参照してください。

web.xmlファイルでRUEIおよびクリック履歴を有効にする手順:

1. 「アプリケーション」ウィンドウで、WEB-INFを開き、web.xmlをダブルクリックします。

2. 次の例に示すように、概要エディタで、context-paramタグをweb.xmlファイルに追加します。

<context-param>
<description>This parameter notifies ADF Faces that the
ExecutionContextProvider service provider is enabled.
When enabled, this will start monitoring and aggregating
user activity information for the client initiated
requests. By default this param is not set or is false.
</description>
<param-name>
oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER
</param-name>
<param-value>true</param-value>
</context-param>

クリック履歴では、web.xmlファイルへのパラメータの追加に加えて、weblogic.xmlファイルにodl.clickhistory.webappライブラリを定義する必要もあります。

weblogic.xmlファイルを使用してクリック履歴の有効化を完了する手順:

1. 「アプリケーション」ウィンドウで、WEB-INFを開き、weblogic.xmlをダブルクリックします。

2. 次の例に示すように、概要エディタで、ライブラリ・エントリをweblogic.xmlファイルに追加します。

<library-ref>
<library-name>odl.clickhistory.webapp</library-name>
</library-ref>

EndUserMonitoringServiceサービス・プロバイダが使用可能な場合、これをアプリケーションに登録することで、これを使用してパフォーマンス・メトリックとデータをロギングできます。EndUserMonitoringServiceクラスを開いて、このサービス・プロバイダを実装しておく必要があります。このクラスの詳細は、Javadocを参照してください。

ADFアプリケーション内でEndUserMonitoringServiveプロバイダを使用する場合は、コンテキスト・パラメータoracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDERを設定する必要があります。

アプリケーションでエンド・ユーザー・モニタリングを有効にするには:

1. EndUserMonitoringServiceサービス・プロバイダが実装されていることを確認します。

2. オペレーティング・システム・ツールを使用して、アプリケーションの<application_home>/src/META-INF/servicesフォルダに移動します。

servicesフォルダが存在しない場合は、これを作成します。

3. <application_home>/src/META-INF/servicesフォルダで、oracle.adf.view.rich.monitoring.EndUserMonitoringServiceという名前のファイルを作成します。

ここで、EndUserMonitoringServiceはサービス・インタフェースの名前です。

4. エディタでファイルを開き、次のエントリを追加します。<package>.MyEndUserMonitoringService

ここで、packageは、サービス・プロバイダが格納されているJavaパッケージ名で、MyEndUserMonitoringServiceは、EndUserMonitoringServiceサービス・プロバイダの名前です。

55.3.4 ADFセキュリティを有効にしたアプリケーションのデプロイ方法

統合WebLogic Serverを使用してJDeveloperでアプリケーションを開発する場合、アプリケーション・セキュリティ・デプロイメント・プロパティがデフォルトで構成されます。つまり、開発目的で再デプロイするたびに、アプリケーションとセキュリティの資格証明およびポリシーが上書きされることになります。ただし、アプリケーション・セキュリティ・デプロイメント・プロパティは、統合WebLogic ServerおよびスタンドアロンのWebLogic Serverの両方で同じです。

デフォルト動作は、「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明されているように「アプリケーション・プロパティ」ダイアログで変更できます。

55.3.4.1 Oracle Single Sign-On (SSO)を使用して実行するアプリケーション

ADFセキュリティを有効にしたWebアプリケーションを、アプリケーション・サーバーにデプロイして実行するには、ターゲット・サーバーの管理者がOracle Access Manager (OAM)セキュリティ・プロバイダのドメインレベルのjps-config.xmlファイルを構成する必要があります。この構成タスクを実行するため、JDeveloperに付属しているOracle WebLogic Scripting Tool (WLST)を使用できます。WLSTの実行方法(コマンドaddOAMSSOProvider(loginuri, logouturi, autologinuri)を使用)の詳細は、『Oracle Access Management管理者ガイド』の付録A「Oracle ADFアプリケーションとOracle Access Manager SSOの統合」にあるOracle ADFセキュリティおよびOPSS SSOフレームワークを使用したAccess ManagerとWebアプリケーションの統合に関する項を参照してください。

addOAMSSOProvider()コマンドを実行することで、ADFセキュリティ・フレームワークが確実にOAMサービス・プロバイダに従って、ObSSOCookieトークンをクリアするようになります。OAMでは、このトークンを使用して認証済ユーザーのアイデンティティが保存されるため、ログアウト中にトークンがクリアされないかぎり、ユーザーはログアウトできません。

システム管理者がターゲット・サーバーに対してコマンドを実行すると、ドメインのjps-config.xmlファイルに、ADFセキュリティ固有の次のセキュリティ・プロバイダ定義が追加されます。

<propertySet name="props.auth.uri">
<property name="login.url.FORM" value="/${app.context}/adfAuthentication"/>
<property name="logout.url" value=""/>
</propertySet>

また、SSOに必要な認証タイプはCLIENT-CERTです。デプロイ済アプリケーションのweb.xml認証構成に、<auth-method>要素を次のいずれかのCLIENT-CERTタイプとして指定する必要があります。

WebLogicでは、次の2種類の認証方式をサポートしています。

- FORMタイプの認証方式の場合、次のような要素を指定します。

<login-config>
<auth-method>CLIENT-CERT,FORM</auth-method>
<realm-name>myrealm</realm-name>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>

- BASICタイプの認証方式の場合、次のような要素を指定します。

<login-config>
<auth-method>CLIENT-CERT,BASIC</auth-method>
<realm-name>myrealm</realm-name>
</login-config>

WebSphereでは、次の1種類の認証方式をサポートしています。次のように要素を指定します。

<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>myrealm</realm-name>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>

web.xmlファイルは、Webアプリケーションをデプロイする前でも後でも構成可能です。シングル・サインオンの認証方法の設定の詳細は、『Oracle Access Management管理者ガイド』の第IV部「Access Manager SSO、ポリシーおよびテストの管理」を参照してください。

55.3.4.2 Weblogic Serverのセキュリティ構成

開発環境では、サーバーが開発モードに設定されている場合にのみ、アプリケーション・レベルの資格証明、アイデンティティおよびポリシーがスタンドアロンWebLogic Serverインスタンスへ自動的に移行されます。統合WebLogic Serverはデフォルトで開発モードに設定されています。Oracle WebLogic Serverドメインの作成時に、Oracle Fusion Middleware構成ウィザードを使用して、スタンドアロンWebLogic Serverを開発モードに設定できます。Oracle WebLogic Serverドメインの構成の詳細は、『構成ウィザードによるWebLogicドメインの作成』を参照してください。

本番モードでは、アプリケーション・レベルのセキュリティ資格証明はWebLogic Server設定に移行されません。本番環境では一般に、管理者はEnterprise ManagerまたはWLSTを使用してアプリケーション(セキュリティ要件を含む)をデプロイします。

アプリケーションをWebLogic Serverにデプロイすると、資格証明(cwallet.ssoファイルに含まれる)およびセキュリティ・ポリシー(jazn-data.xmlファイルに含まれる)は、WebLogic Serverのドメインレベルの資格情報ストアを上書きするか、これらとマージされます。上書きとマージのどちらが行われるかは、weblogic-application.xmlのオプションがOVERWRITEまたはMERGEのいずれに設定されているかによって決まります。本番モードのWebLogic Serverでは、セキュリティ・リスクを回避するため、MERGEしか使用できません。開発モードのWebLogic Serverでは、モードをOVERWRITEに設定して、ユーザー名とパスワードをテストできます。また、オプションを設定するには、setDomainEnv.cmdまたはsetDomainEnv.shを実行できます。その際、コマンド(通常はORACLE_HOME/user_projects/domains/MyDomain/binにあります)に次のオプションを追加します。

setDomainEnv.cmdの場合:

set EXTRA_JAVA_PROPERTIES=-Djps.app.credential.overwrite.allowed=true
%EXTRA_JAVA_PROPERTIES%

setDomainEnv.shの場合:

EXTRA_JAVA_PROPERTIES="-Djps.app.credential.overwrite.allowed=true
${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES

管理サーバーがすでに稼働している場合、この設定を有効にするにはサーバーを再起動する必要があります。

WebLogic Serverが本番モードかどうかをチェックするには、Oracle WebLogic Server管理コンソールを使用するか、WebLogic Serverのconfig.xmlファイルで次の行を確認します。

<production-mode-enabled>true</production-mode-enabled>

デフォルトでは、アプリケーションの資格証明、アイデンティティおよびポリシーはOVERWRITEモードに設定されます。つまり、「アプリケーションのプロパティ」ダイアログの「デプロイメント」ページで、「アプリケーション・ポリシー」、「資格証明」、「ユーザーとグループ」の各オプションがデフォルトで選択されます。ただし、アプリケーションの資格証明が移行されるのは、ターゲットとなるWebLogic Serverインスタンスが-Djps.app.credential.overwrite.allowed=trueの指定によって開発モードに設定されている場合のみです。

ポリシーの移行は開発モードでのみ実行されます。アイデンティティの移行が実行できるのは、開発または本番モードにかかわらず、JDeveloperを使用してWebLogic Serverに直接デプロイする場合のみです。

アプリケーションを本番環境にデプロイする準備ができたら、jazn-data.xmlファイルからアイデンティティを削除するか、「アプリケーションのプロパティ」ダイアログで「ユーザーとグループ」を選択解除して、アイデンティティの移行を無効にしてください。アプリケーションの資格証明は、JDeveloperの外部で、手動で移行する必要があります。

注意:

jazn-data.xmlファイルを本番環境に移行する前に、ポリシー・ストアに、重複する権限付与のためのパーミッションがないか確認します。ファイル内に重複するパーミッション(同じ名前とクラスを持つパーミッション)がある場合は、ポリシー・ストアを移行する管理者にエラーが表示され、ポリシーの移行が停止します。jazn-data.xmlファイルを手動で編集して、権限付与の定義から重複するパーミッションをすべて削除する必要があります。

アプリケーションの資格証明およびその他のjazn-dataユーザー資格証明の移行の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」を参照してください。

55.3.4.2.1 WebLogic用のJDBC URLを使用するアプリケーション

アプリケーションにJDBC URL接続を使用するコンポーネントがある場合、接続のユーザー名とパスワードもアプリケーション・レベルの資格証明およびポリシー・ストアに格納されます。デプロイされたアプリケーションがJDBC URLを使用してデータベースに接続できるようにする場合は、これらの資格証明とポリシーを移行する必要があります。すなわち、WebLogic Serverが本番モードの場合、システム管理者はこのセキュリティ情報を移行する必要があります。WebLogic Serverが開発モードの場合は、ドメインレベルの資格証明とポリシー・ストアをOVERWRITEに設定して、セキュリティ情報の移行を許可する必要があります。

55.3.4.2.2 WebLogic用のJDBCデータ・ソースを使用するアプリケーション

アプリケーションがパスワード・インダイレクション機能を持つアプリケーション・レベルのJDBCデータソースを使用して、データベース接続を行う場合、WebLogic Serverで資格証明マップを作成し、データベース接続を有効にする必要があります。詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

55.3.4.3 WebSphere Application Serverのセキュリティ構成

アプリケーションを資格証明(cwallet.ssoファイルに含まれる)を含めセキュリティ・ポリシー(jazn-data.xmlファイルに含まれる)ともにWebSphereに移行できます。WebSphereで追加のタスクを実行する必要があります。WebSphere Application Server用のアプリケーションのEARファイルには、opss-application.xmlファイルが含まれないことに注意してください。

注意:

jazn-data.xmlファイルを本番環境に移行する前に、ポリシー・ストアに、重複する権限付与のためのパーミッションがないか確認します。ファイル内に重複するパーミッション(同じ名前とクラスを持つパーミッション)がある場合は、ポリシー・ストアを移行する管理者にエラーが表示され、ポリシーの移行が停止します。jazn-data.xmlファイルを手動で編集して、権限付与の定義から重複するパーミッションをすべて削除する必要があります。

資格証明とポリシーを受け入れるためのWebSphereの設定の詳細は、を参照してください。

55.3.4.3.1 WebSphere用のJDBC URLを使用するアプリケーション

アプリケーションにJDBC URL接続を使用するコンポーネントがある場合、接続のユーザー名とパスワードもアプリケーション・レベルの資格証明およびポリシー・ストアに格納されます。デプロイされたアプリケーションがJDBC URLを使用してデータベースに接続できるようにする場合は、OPSS移行を有効にする必要があります。

55.3.4.3.2 WebSphere用のJDBCデータ・ソースを使用するアプリケーション

アプリケーションがパスワード・インダイレクション機能を持つアプリケーションレベルのJDBCデータソースを使用して、データベース接続を行う場合、WebSphereでJDBCデータソースを作成する必要があります。詳細は、IBM WebSphereのドキュメントを参照してください。

55.3.4.3.3 web.xmlファイルの編集によるWebSphereのアプリケーション・ルートの保護

WebアプリケーションのADFセキュリティを有効にすると、web.xmlファイルにJava EEセキュリティ制約のallPagesが格納され、Java EEのアプリケーション・ルートが保護されます。デフォルトでは、Oracle WebLogic Serverへのデプロイをサポートするために、JDeveloperでセキュリティ制約のURLパターンが/(バックスラッシュ)に指定されます。アプリケーションをIBM WebSphereにデプロイする場合、正しいURLパターンは/*(バックスラッシュとアスタリスク)になります。アプリケーションをWebSphereにデプロイする前に、アプリケーションのweb.xmlファイルを手動で編集し、allPagesセキュリティ制約を次のように変更します。

<security-constraint>
<web-resource-collection>
<web-resource-name>allPages</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
. . .
</security-constraint>

55.3.5 クラスタ環境でのメモリー・スコープのレプリケート方法

クラスタ環境での実行を想定したアプリケーションをデプロイする場合、存続期間が1つのリクエストより長いマネージドBeanがすべてシリアライズ可能であること、そしてOracle ADFがADFスコープ(ビュー・スコープとページ・フロー・スコープ)に格納されるマネージドBeanへの変更を認識することを確認する必要があります。

詳細は、「サーバー/クラスタ環境でのマネージドBeanメモリー・スコープの設定方法」を参照してください。

55.3.6 アプリケーションをADF MBeanに対して有効化する方法

Fusion Webアプリケーションでは、多くのXMLファイルを使用して構成情報が設定されています。これらの3つの構成ファイルには、アプリケーションとともにデプロイされ、構成ファイルと同じ役割を果すADF MBeanがあります。アプリケーションがデプロイされたら、Enterprise Manager Fusion Middleware ControlのMBeanブラウザを使用してADF MBeanにアクセスし、構成プロパティを変更することができます。

ADF MBeanを有効にするには、これをweb.xmlファイルに登録します。次の例は、接続、構成およびビジネス・コンポーネントのリスナー・エントリを含むweb.xmlファイルを示しています。

<listener>
<listener-class>
oracle.adf.mbean.share.connection.ADFConnectionLifeCycleCallBack
</listener-class>
</listener>
<listener>
<listener-class>
oracle.adf.mbean.share.config.ADFConfigLifeCycleCallBack</listener-class>
</listener>
<listener>
<listener-class>
oracle.bc4j.mbean.BC4JConfigLifeCycleCallBack</listener-class>
</listener>

また、ADF接続MBeanを使用したconnections.xmlのデプロイメント後の構成、およびADFビジネス・コンポーネントMBeanを使用したbc4j.xcfgのデプロイメント後の構成を有効にするために、書込み可能なMDSリポジトリを構成する必要があります。

データベース・ベースのMDSを使用する場合のadf-config.xmlファイルのMDS構成エントリを次の例に示します。MDSの構成の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config xmlns="http://xmlns.oracle.com/mds/config" version="11.1.1.000">
<persistence-config>
<metadata-store-usages>
<metadata-store-usage
default-cust-store="true" deploy-target="true" id="myStore">
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
</mds-config>
</adf-mds-config>

本番環境では、データベースを使用するMDSリポジトリが必要です。JDeveloper、Enterprise Manager Fusion Middleware Controlまたはスクリプトのいずれかを使用して、ファイルベースのリポジトリからデータベースのMDSリポジトリに切り替えることができます。

また、複数のアプリケーションが同じMDS構成を共有している場合は、adf-config.xmlファイルでadf:adf-properties-childプロパティを定義して、各アプリケーションに異なるカスタマイズ・レイヤーを持たせることができます。このエントリは、アプリケーションの作成時に自動的に生成されます。adf-config.xmlファイルにこのエントリがない場合は、ここに示すようなコードを使用してファイルに追加できます。

<adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties">
<adf-property name="adfAppUID" value="Application3-4434"/>
<adf-property name="partition_customizations_by_application_id"
value="true"/>
</adf:adf-properties-child>

value属性は、JDeveloperで自動的に生成するか、アプリケーションのデプロイ先となるサーバー・ファーム内で一意の識別子に設定します。この値は、adfAppUIDプロパティのvalue属性に設定できます。

adf-property nameをadfAppUidに設定した場合は、対応するvalueプロパティをアプリケーションの名前に設定する必要があります。デフォルトでは、valueプロパティはアプリケーションのパッケージ名を使用して生成されます。パッケージ名を指定していない場合、valueプロパティはワークスペース名と4桁の乱数を使用して生成されます。

ADF MBeanを使用したADFアプリケーションの構成の詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

55.3.7 Oracle WebLogic Server用のJDBCデータソースに関する必知事項

ADFアプリケーションでは、データベース接続にJDBCデータ・ソースとJDBC URLのいずれかを使用することができます。JDBCデータ・ソースを構成するには、Oracle WebLogic Server管理コンソールを使用します。データベース・アクセスの詳細は、「アプリケーション・モジュールのデータベース接続の構成」を参照してください。

注意:

Fusion Webアプリケーションは、JDBC XAドライバで定義されたデータ・ソースと互換性がありません。Oracle WebLogic Serverでデータソースを作成する場合、忘れずにFusion Webアプリケーション・データソースのJDBCドライバをOracleのドライバ(Thin XA)からOracleのドライバ(Thin)に変更してください。XAデータ・ソースはコミット時にすべてのカーソルをクローズするため、XAデータ・ソースを使用してFusion Webアプリケーションを実行すると、ランダムにJBO-27122エラーおよび文のクローズ・エラーが発生することがあります。

Fusion Webアプリケーションのデータ・モデル・プロジェクト内のアプリケーション・モジュールは、JDBC URL接続タイプ、JDBCデータソース接続タイプまたはこの2つのタイプの組合せを使用するように構成できます。デフォルトでは、Fusion Webアプリケーション・モジュールはJDBC URL接続を使用します。JDBC URLを使用するコンポーネントは、JDBC URLを使ってデータベースへの直接接続を試みて、WebLogic Serverで使用可能なJDBCデータソース(グローバルまたはアプリケーション・レベル)を無視します。アプリケーションからWebLogic ServerへのJDBC URLセキュリティ情報(ユーザー名とパスワード)の移行の詳細は、「ADFセキュリティを有効にしたアプリケーションのデプロイ方法」を参照してください。

Fusion Webアプリケーションでは、データベースへの接続にJDBCデータソースを使用できます。JDBCデータ・ソースには、グローバル、アプリケーションレベル、パスワード・インダイレクション機能を持つアプリケーションレベルの3種類があります。通常、グローバルなJDBCデータ・ソースはWebLogic Serverで設定します。データベースにアクセスする必要のあるアプリケーションは、そのJDBCデータ・ソースを使用できます。アプリケーションには、アプリケーション・レベルのJDBCデータソースを組み込むこともできます。アプリケーションをデプロイメント用にパッケージ化する際に、「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」オプションを選択すると、定義した接続ごとにconnection_name-jdbc.xmlファイルが作成されます。各接続の情報は、対応するconnection_name-jdbc.xmlファイルに書き込まれます(weblogic-application.xmlとweb.xmlのエントリも変更されます)。アプリケーションがWebLogic Serverにデプロイされると、サーバーはグローバル・データソースを検索する前に、アプリケーション・レベルのデータソース情報を検索します。

パスワード・インダイレクションをtrueに設定してアプリケーションをデプロイすると、WebLogic Serverは、connection_name-jdbc.xmlファイルを探してユーザー名情報を確認し、そのユーザー名に対応するアプリケーション・レベルの資格証明マップを特定してパスワードを入手しようとします。JDeveloperを使用してアプリケーションをWebLogic Serverに直接デプロイする場合は、資格証明マップが自動的に作成され、MBeanコールを介してサーバーに組み込まれます。

ただし、EARファイルをデプロイする場合は、JDeveloperでWebLogic ServerへのMBeanコールを行えません。Oracle WebLogic管理コンソールを使用して、資格証明マップを設定する必要があります。グローバルなJDBCデータ・ソースを設定した場合でも、資格証明マッピングを設定していなければ、WebLogic Serverは資格証明をパスワードにマップできず、接続は失敗します。

データ・ソースがOracle WebLogic Serverで作成されたら、アプリケーション・モジュールで使用できます。詳細は、『Oracle ADFアプリケーションの管理』のスタンドアロン・アプリケーション・サーバーのデプロイの準備に関する項を参照してください。

55.4 アプリケーションのデプロイ

ADFアプリケーションは、JDeveloperを使用してスタンドアロン・アプリケーション・サーバーに直接デプロイすることも、アーカイブ・ファイルを作成し、他のツールを使用してアプリケーション・サーバーにデプロイすることもできます。

注意:

Oracle ADFを使用するアプリケーションをスタンドアロン・アプリケーション・サーバーにデプロイし始める前に、ADFランタイムのインストール、およびドメインまたはセルの作成や拡張といったタスクを実行して、アプリケーション・サーバー環境を準備しておく必要があります。詳細は、『Oracle ADFアプリケーションの管理』のスタンドアロン・アプリケーション・サーバーのデプロイの準備に関する項を参照してください。

図55-5に、ターゲット・スタンドアロン・アプリケーション・サーバーへのアプリケーションのデプロイとカスタマイズのデプロイのプロセス・フローを示します。

図55-5 アプリケーションのデプロイのフロー・ダイアグラム

表55-2に、アプリケーションのデプロイおよびデプロイ・サイクル中に使用できる一般的なデプロイ方法を示します。開発環境でのデプロイから本番環境のデプロイまでの順序でデプロイ方法をリストしています。本番環境では、システム管理者がEnterprise Manager Fusion Middleware Controlまたはスクリプトを使用してアプリケーションをデプロイします。

表55-2 開発環境または本番環境でのデプロイ方法

デプロイ方法

環境

使用するとき

JDeveloperから直接実行

テストまたは開発

この方法は、アプリケーションの開発中に使用します。編集プロセスとデプロイ・プロセスを何度も繰り返す必要があるからです。

JDeveloperには統合WebLogic Serverが含まれています。この統合WebLogic Serverでアプリケーションを実行してテストできます。

JDeveloperを使用してターゲット・アプリケーション・サーバーに直接デプロイ

テストまたは開発

この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。

テスト用サーバーでは、開発用サーバーで使用できない機能(LDAPやOracle Single Sign-Onなど)をテストできます。

テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。

JDeveloperを使用してEARファイルにデプロイし、ターゲット・アプリケーション・サーバーのデプロイ用ツールを使用

テストまたは開発

この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。JDeveloperから直接デプロイするかわりに、EARファイルにデプロイしてから、他のツールを使用してアプリケーション・サーバーにデプロイすることができます。

テスト用サーバーでは、開発用サーバーで使用できない機能(LDAPやOracle Single Sign-Onなど)をテストできます。

テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。

Enterprise ManagerまたはWLSTを使用してアプリケーションをデプロイ

本番

アプリケーションがテスト環境と本番環境にある場合です。本番環境では、システム管理者がEnterprise Manager Fusion Middleware Controlを使用するか、WLSTを実行して、アプリケーションをデプロイするのが一般的です。

必要なMDSリポジトリをすべてアプリケーション・サーバーに登録する必要があります。MDSリポジトリがデータベースの場合、リポジトリはMDS固有の要件を備えたデータソースにマップされます。

アプリケーションをOracle WebLogic Serverにデプロイする前に、このデータ・ソースのターゲットをWebLogic管理サーバー、およびアプリケーションのデプロイ先となるすべての管理対象サーバーに設定する必要があります。MDSの登録の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

adf-config.xmlのMDSリポジトリ構成を必要とするEARファイルとしてパッケージ化されたアプリケーションを、アプリケーション・サーバーの管理コンソールまたはスクリプトを使用してデプロイする場合は、EARファイルをデプロイする前に、getMDSArchiveConfigコマンドを実行してMDSを構成する必要があります。MDS構成は、EARファイルにMARファイルが含まれる場合、またはアプリケーションがDT@RT (Design Time At RunTime)に対して有効化されている場合に必要です。

WLSTコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』を参照してください。

wsadminコマンドの詳細は、およびを参照してください。

注意:

IBM WebSphere Application Serverの場合、アプリケーションのデプロイ後にサーバーの起動などの追加作業を実行する必要があります。

IBM WebSphere Application Server、wsadminコマンドおよびWebSphere管理コンソールの使用の詳細は、を参照してください。

Oracle ADF固有のwsadminコマンドの詳細およびADFランタイムのIBM WebSphere Application Serverへのインストールの詳細は、Oracle ADFアプリケーションの管理を参照してください。

アプリケーションのデプロイ後に、ADF MBeanを使用してADF接続情報、ADFビジネス・コンポーネント情報またはadf-config.xmlを構成する予定の場合は、アプリケーションがMDSを使用するように構成されていること、およびweb.xmlファイルでMBeanリスナーが有効になっていることを確認してください。詳細は、「アプリケーションをADF MBeanに対して有効化する方法」を参照してください。

注意:

WebLogic Serverにデプロイするビジネス・サービスがFusion Webアプリケーションにある場合は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。

55.4.1 JDeveloperからアプリケーション・サーバーへのデプロイ方法

始める前に:

アプリケーションをデプロイするときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションのデプロイ」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーション・レベルのEARデプロイメント・プロファイルの作成」の説明に従って、EARファイルにデプロイするアプリケーション・レベルのデプロイメント・プロファイルを作成します。

注意:

JDeveloperからOracle WebLogic Serverにデプロイする場合は、Oracle WebLogic Server管理コンソールで、HTTPトンネリング・プロパティが有効になっていることを確認してください。このプロパティは、「サーバー」→ServerName→「プロトコル」の下にあります。ServerNameは、Oracle WebLogic Serverの名前です。

注意:

JDeveloperは、クラスタに属する個々の管理対象サーバーへのアプリケーションのデプロイをサポートしていません。Oracle WebLogic Server管理コンソールやその他のOracle WebLogicツールを使用してクラスタ内の1つ以上の管理対象サーバーをターゲットに設定することは可能ですが、クラスタに悪影響を及ぼす可能性があります。Oracle WebLogic Serverクラスタへのデプロイの詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

JDeveloperからターゲット・アプリケーション・サーバーへのデプロイ方法:

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックして「デプロイ」を選択し、デプロイメント・プロファイルを選択します。

2. 「デプロイ」ウィザードの「デプロイメント・アクション」ページで、「アプリケーション・サーバーへのデプロイ」を選択し、「次へ」をクリックします。

3. 「サーバーの選択」ページで、アプリケーション・サーバー接続を選択し、「次へ」をクリックします。

4. WebLogic Serverインスタンスにデプロイしている場合は、「WebLogicオプション」ページが表示されます。デプロイメント・オプションを選択し、「次へ」をクリックします。

注意:

ADFアプリケーションをデプロイしている場合は、「ドメイン内の全インスタンスへのデプロイ」オプションは使用しないでください。

5. 「終了」をクリックします。

デプロイ中は、処理ステップがデプロイメント・ログ・ウィンドウに表示されます。作成中のモジュールの内容(アーカイブまたは展開EAR)を確認するには、ログ・ウィンドウに表示されたリンクをクリックします。アーカイブ・ファイルまたは展開EARファイルが該当するエディタまたはディレクトリ・ウィンドウで開き、確認できるようになります。

EARファイル内のadf-config.xmlファイルにMDSリポジトリ構成が必要な場合は、図55-6に示す「デプロイメント構成」ダイアログが表示されるので、そこでターゲット・メタデータ・リポジトリまたは共有メタデータ・リポジトリを選択します。「リポジトリ名」ドロップダウン・リストでは、管理サーバーに登録されているメタデータ・リポジトリのリストからターゲット・メタデータ・リポジトリを選択できます。「パーティション名」ドロップダウン・リストでは、デプロイ中にアプリケーションのメタデータがインポートされるメタデータ・リポジトリ・パーティションを選択できます。MDSの構成と登録には、Oracle WebLogic Scripting Tool (WLST)およびOracle WebLogic Server管理ツールを使用できます。MDSリポジトリの管理の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

図55-6 デプロイメントのMDS構成およびカスタマイズ

注意:

Java EEアプリケーションをデプロイする場合は、「アプリケーション」ウィンドウ内でJava EEアプリケーションの隣にあるアプリケーション・メニューをクリックします。

アプリケーション・サーバー接続の作成の詳細は、「ターゲット・アプリケーション・サーバーへの接続の作成方法」を参照してください。

55.4.2 デプロイメント用のEARファイルの作成方法

デプロイメント・プロファイルを使用してアーカイブ・ファイル(EARファイル)を作成することもできます。作成したアーカイブ・ファイルは、Enterprise Manager、Oracle WebLogic Scripting Tool (WLST)、Oracle WebLogic Server管理コンソールのいずれかを使用してデプロイできます。

Fusion WebアプリケーションはEARファイル(通常はWAR、MAR、JARのコンポーネントを含む)にカプセル化されますが、部分的にEARではデプロイされないことがあります。たとえば、ADFビジネス・サービスはJARとしてデプロイできます。ビジネス・サービスの詳細は、「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。

始める前に:

デプロイするためにEARファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションのデプロイ」を参照してください。

次のタスクを完了する必要があります。

- 「アプリケーションレベルのEARデプロイメント・プロファイルの作成」の説明に従って、EARファイルにデプロイするアプリケーション・レベルのデプロイメント・プロファイルを作成します。

EARアーカイブ・ファイルを作成するには:

1. 「アプリケーション」ウィンドウで、デプロイメント・プロファイルを含むアプリケーションを右クリックし、「デプロイ」→「deployment profile」を選択します。

2. デプロイ・ウィザードの「デプロイメント・アクション」ページで、「EARにデプロイ」を選択し、「終了」をクリックします。

EARファイルがアプリケーションレベルでデプロイされ、そのEARファイルにデータ・モデル・プロジェクトのJARファイルとユーザー・インタフェース・プロジェクトのWARファイルへの依存性が存在する場合、各ファイルはデフォルトで次のディレクトリに保存されます。

- ApplicationDirectory/deploy/EARdeploymentprofile.EAR

- ApplicationDirectory/ModelProject/deploy/JARdeploymentprofile.JAR

- ApplicationDirectory/ViewControllerProject/deploy/WARdeploymentprofile.WAR

ヒント:

「表示」→「ログ」を選択し、アーカイブ・ファイルの作成時に生成されたメッセージを表示します。

55.4.3 ADFライブラリに適用された新しいカスタマイズのデプロイ方法

ADFライブラリ用に新しいカスタマイズを作成した場合は、MARプロファイルを使用して、このカスタマイズをADFライブラリを使用する任意のデプロイ済アプリケーションにデプロイできます。たとえば、ADFLibraryBを使用するapplicationAがスタンドアロン・アプリケーション・サーバーにデプロイされるとします。その後、新しいカスタマイズがADFLibraryBに追加された場合は、この更新されたカスタマイズをapplicationAにデプロイするだけで済みます。アプリケーション全体を再パッケージ化したり再デプロイする必要はありません。また、MDSリポジトリに手動でパッチを適用する必要もありません。

注意:

この手順は、ADFライブラリのカスタマイズ変更を、スタンドアロン・アプリケーション・サーバーのデプロイ済アプリケーションに適用するためのものです。カスタマイズを初めてMARにパッケージ化し、最終的にEARの一部とするための手順ではありません。MARを使用したカスタマイズの初回パッケージ化の詳細は、「MARデプロイメント・プロファイルの作成」を参照してください。

ADFライブラリのカスタマイズをデプロイするには、新しいMARプロファイルを作成し、デプロイするカスタマイズのみを格納し、JDeveloperを使用して次を実行します。

- カスタマイズをスタンドアロン・アプリケーション・サーバーのMDSリポジトリに直接デプロイします。

- カスタマイズをJARにデプロイします。次に、Fusion Middleware Controlなどのツールを使用して、JARをMDSリポジトリにインポートします。

55.4.3.1 デプロイ済アプリケーションへのカスタマイズのエクスポート

カスタマイズは、JDeveloperからスタンドアロン・アプリケーション・サーバーのデプロイ済アプリケーションのMDSリポジトリに直接エクスポートできます。

始める前に:

カスタマイズを直接アプリケーション・サーバーにエクスポートするときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションのデプロイ」を参照してください。

次のタスクを完了する必要があります。

- ADFライブラリに新しいカスタマイズを作成します。カスタマイズの詳細は、「JDeveloperでADFライブラリ・アーティファクトをカスタマイズする方法」を参照してください。

カスタマイズをアプリケーション・サーバーに直接エクスポートするには:

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックし、「デプロイ」→「metadata」を選択します。

2. 「デプロイメント・アクション」ページの「メタデータのデプロイ」ダイアログで、「デプロイ済アプリケーションへのエクスポート」を選択し、「次へ」をクリックします。

MARプロファイルが任意のアプリケーションのEARプロファイルに格納されると、「デプロイ済アプリケーションへのエクスポート」がグレー表示されて無効化されます。

3. 「アプリケーション・サーバー」ページで、アプリケーション・サーバー接続を選択し、「次へ」をクリックします。

4. WebLogic Serverの場合は、「サーバー・インスタンス」ページが表示されます。このページで、デプロイ済アプリケーションを含むサーバー・インスタンスを選択し、「次へ」をクリックします。

5. 「デプロイ済アプリケーション」ページで、カスタマイズを適用するアプリケーションを選択し、「次へ」をクリックします。

6. サンドボックスにデプロイする場合は、「サンドボックス・インスタンス」ページで、「関連するサンドボックスにデプロイ」を選択し、サンドボックス・インスタンスを選択し、「次へ」をクリックします。

7. 「サマリー」ページで、内容を確認して「終了」をクリックします。

55.4.3.2 JARへのカスタマイズのデプロイ

ADFライブラリのカスタマイズをJARにデプロイする場合は、MARプロファイルに定義されているとおりにコンテンツをパッケージ化します。

始める前に:

カスタマイズをJARとしてデプロイするときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションのデプロイ」を参照してください。

次のタスクを完了する必要があります。

- ADFライブラリに新しいカスタマイズを作成します。カスタマイズの詳細は、「JDeveloperでADFライブラリ・アーティファクトをカスタマイズする方法」を参照してください。

カスタマイズをJARとしてデプロイするには::

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックし、「デプロイ」→「metadata」を選択します。

2. 「デプロイメント・アクション」ページの「メタデータのデプロイ」ダイアログで、「MARにデプロイ」を選択します。

3. 「サマリー」ページで「終了」をクリックします。

4. Enterprise Manager Fusion Middleware Controlまたはアプリケーション・サーバーの管理ツールを使用して、JARをMDSリポジトリにインポートします。Fusion Middleware Controlの詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

55.4.4 ADFライブラリに関する必知事項

ADFライブラリは、ADFコンポーネント(ADFタスク・フロー、ページ、アプリケーション・モジュールなど)に対して登録されたJARサービスを含むJARファイルです。プロジェクトのADFコンポーネントを再利用する場合は、プロジェクトのADFライブラリ・デプロイメント・プロファイルを作成してから、そのプロファイルに基づいたADFライブラリJARを作成します。

「リソース」ウィンドウを使用するか、手動でライブラリのクラスパスに追加する方法でADFライブラリJARを追加すると、アプリケーションまたはプロジェクトでそのADFライブラリJARを使用できるようになります。「デフォルトでデプロイ済」オプションが選択されている場合、プロジェクトに追加されたADFライブラリJARは、プロジェクトのWARファイルに組み込まれます。

詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

55.4.5 EARファイルとパッケージ化に関する必知事項

Fusion WebアプリケーションをEARファイルにパッケージ化する場合、EARファイルには次のものを組み込むことができます。

- WARファイル: Webベースのビュー・コントローラ・プロジェクトはそれぞれWARファイルにパッケージ化します。

- MARファイル: アプリケーションとともにデプロイするカスタマイズ内容がある場合、カスタマイズ内容はMARにパッケージ化します。

- ADFライブラリJARファイル: アプリケーションでADFライブラリJARが使用される場合、そのJARファイルはEARにパッケージ化できます。

- その他のJARファイル: アプリケーションに必要な依存JARファイルが他にもある場合があります。それらはEARにパッケージ化できます。

55.4.6 スクリプトとAntを使用したアプリケーションのデプロイ方法

コマンドを使用してアプリケーションをデプロイし、そのコマンドをスクリプトに記述してプロセスを自動化することができます。ojdeployコマンドを使用すると、JDeveloperなしでアプリケーションをデプロイできます。Antスクリプトを使用してアプリケーションをデプロイすることもできます。JDeveloperには、Antスクリプトの作成に役立つ機能が用意されています。要件によっては、通常のスクリプトをAntスクリプトと組み合せることも可能です。

コマンド、スクリプト、Antの詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

55.4.7 ADF FacesライブラリJARをアプリケーションとともにデプロイする方法

ADFモデルを使用せずにADF Facesのみを使用するアプリケーションを開発できます。この場合、ADF Faces JARをアプリケーションとともにアプリケーション・サーバーにデプロイできます。

始める前に:

Webベースのプロジェクトを使用してアプリケーションを作成します。Fusion Web Application (ADF)テンプレートを使用した場合は、すでにデフォルトのWARデプロイメント・ファイルが存在します。

ADF Faces JARをアプリケーションの一部としてデプロイするには:

1. 「アプリケーション」ウィンドウで、デプロイするWebプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで「デプロイ」を選択してからデプロイメント・プロファイルを選択し、「編集」をクリックします。

プロジェクトにWARデプロイメント・プロファイルがない場合は、「WARデプロイメント・プロファイルの作成」の手順1から3に従って、新しいWARデプロイメント・プロファイルを作成します。

3. 「ファイル・グループ」→「WEB-INF/lib」→「コントリビュータ」を選択し、ADF Facesランタイム11を選択します。

4. 「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。

5. 「OK」を再度クリックして、プロジェクト・プロパティのダイアログを終了します。

6. この章で説明したように、JDeveloperを使用して直接、あるいはEARを作成してEnterprise Manager Fusion Middleware Control、Oracle WebLogic Server管理コンソールまたはその他の方法を使用してデプロイすることにより、アプリケーションをデプロイします。

「アプリケーション・レベルのEARデプロイメント・プロファイルの作成」で説明しているように、アプリケーション・レベルのEARにWARファイルが含まれていることを確認します。

55.4.8 JDeveloperランタイム・ライブラリに関する必知事項

アプリケーションをデプロイすると、必要なライブラリの一部がアプリケーションとともに組み込まれます。JDeveloperランタイム・ライブラリとしてすでにWebLogic Serverにロードされている共有ライブラリも必要になる場合があります。どのJDeveloperライブラリがどのWebLogic Server共有ライブラリにパッケージ化されているかを知っておくと便利です。JDeveloperランタイム・ライブラリのコンテンツの一覧は、『Oracle ADFアプリケーションの管理』を参照してください。

55.5 デプロイメント後の構成

アプリケーションをWebLogic Serverにデプロイしたら、構成タスクを実行できます。

55.5.1 アプリケーションの移行方法

Fusion WebアプリケーションをWebLogic Server間で移行する場合は、初回のデプロイの際と同じステップの一部を実行する必要があります。

一般に、アプリケーションを移行する際には、次の作業を行います。

- ターゲットとなるアプリケーション・サーバーにADFランタイムをロードします(まだインストールされていない場合)。
詳細は、『Oracle ADFアプリケーションの管理』のスタンドアロン・アプリケーション・サーバーのデプロイの準備に関する項を参照してください。

- ターゲットとなるアプリケーション・サーバーを正しいデータベース接続情報またはURL接続情報で構成します。

- セキュリティ情報をソースからターゲットに移行します。
手順は、「ADFセキュリティを有効にしたアプリケーションのデプロイ方法」を参照してください。

- Enterprise Manager、管理コンソール、スクリプトのいずれかを使用してアプリケーションをデプロイします。
詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

55.5.2 ADF MBeanを使用したアプリケーションの構成方法

ADF MBeanが有効化され、デプロイ済アプリケーションとともにパッケージ化されている場合、Enterprise ManagerのMBeanブラウザを使用してADFプロパティを構成できます。アプリケーションをMBeanに対して有効化する手順は、「アプリケーションをADF MBeanに対して有効化する方法」を参照してください。

ADF MBeanを使用したADFアプリケーションの構成方法の詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

55.5.3 結果セットを再利用するためのWebSphereの構成方法

WebSphere Application ServerにデプロイされたADFアプリケーションは、共有データベース接続を使用します。WebSphereでnon-transactional datasourceおよびDisableMultiThreadedServletConnectionMgmtプロパティを設定して、アプリケーションが結果セットをリクエスト全体で再利用できるようにする必要があります。

これらのプロパティを設定しないと、WebSphereは結果セットをリクエスト間で閉じます。

詳細は、『Oracle ADFアプリケーションの管理』のWebSphere Application Serverの構成を参照してください。

55.6 アプリケーションのテストとデプロイの検証

アプリケーションは、デプロイが完了したら、アプリケーション・サーバーからテストできます。ADFアプリケーションをテストするには、ブラウザ・ウィンドウを開き、次のURLを入力します。

- Faces以外のページの場合: http://<host>:port/<context root>/<page>

- Facesページの場合: http://<host>:port/<context root>/faces/<view_id>
<view_id>は、ADFタスク・フローにおけるビュー・アクティビティのビューIDです。

ヒント:

アプリケーションのコンテキスト・ルートは、ユーザー・インタフェース・プロジェクト設定に、デフォルトでApplicationName/ProjectName/context-rootとして設定されています。この名前を短くするには、ターゲット・アプリケーション・サーバー全体で一意の名前を指定します。ユーザー・インタフェース・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。「プロジェクト・プロパティ」ダイアログで、「Java EEアプリケーション」を選択し、コンテキスト・ルートの一意の名前を入力します。

注意:

FacesページのURLには、/facesが含まれている必要があります。これは、JDeveloperがFacesサーブレットとの関連付けのために、/facesというURLパターンを使用するようweb.xmlファイルを構成するためです。Facesサーブレットは、リクエスト単位処理を実行し、URL内の/faces部を取り除いた後、そのURLをJSPに転送します。URLに/facesを指定しないと、Facesサーブレットは関与しません(URLパターンが一致しないためです)。JSPは必要なJSFリクエスト単位処理なしで実行されます。

56 Fusion Webアプリケーションでの状態管理の使用

この章では、ADFアプリケーション・モジュールがWeb上でステートフルなアプリケーションをサポートするためのFusion Webアプリケーション状態管理機能について説明します。

この章の内容は次のとおりです。

- Fusion Webアプリケーションの状態管理について

- 受動化とアクティブ化が行われるタイミングの管理

- アプリケーション・モジュールの能動化が安全であることの確認テスト

- モデル状態が保存される場所の制御

- モデル状態のクリーンアップ

- Fusion WebアプリケーションでのHttpSessionの管理

- 受動化時のカスタム・ユーザー固有情報の管理

- 受動化時のビュー・オブジェクトの状態の管理

56.1 Fusion Webアプリケーションの状態管理について

現実世界のほとんどのビジネス・アプリケーションでは、マルチステップのユーザー・タスクをサポートする必要があります。トランザクションWebサイトは、ステップ・バイ・ステップ・スタイルのユーザー・インタフェースを使用し、論理的な順序のページを通してエンド・ユーザーをタスクの完了まで導きます。タスクが終了すると、ユーザーは全体をまとめて保存またはキャンセルできます。ただし、HTTPプロトコルは、個別でステートレスなリクエストの概念に基づいて構築されるため、ユーザー・アクションの順序を論理的でステートフルな作業ユニットにグループ化する作業はアプリケーション開発者が行うことになります。

HTTPプロトコルの制限事項のため、制約がなく、すべての列の型が文字ベースとして定義されているデータベース表のシャドウ・セットを利用する解決策が開発者によって発明されました。このような解決策の使用は、短期間に非常に複雑になります。最終的に、より汎用的で実現可能な方法でこのような問題に対処するには、なんらかの種類の汎用アプリケーション状態管理機能が必要になります。ADFビジネス・コンポーネントは、このソリューションをすぐに実装できる状態で提供します。

状態管理を利用すると、メモリー、信頼性または実装の複雑さの問題に陥ることなく、マルチステップのユースケースをサポートするWebアプリケーションを簡単に作成できます。Oracle ADFでは、アプリケーション・モジュール・プールを使用してセッション状態を実装および管理するプロセスが簡略化されています。これらのプールは、アプリケーション・モジュール・キャッシュを安全に解放する構成可能なリソース・マネージャです。デフォルトでは、ADFビジネス・コンポーネント・プロジェクトにより、アプリケーション内のアプリケーション・モジュール定義ごとに1つのアプリケーション・モジュール・プールが有効になります。

Fusion Webアプリケーションでは、次のレベルで状態管理が提供されます。

- タスク・フローに実装されたADFコントローラ・レイヤーの後で使用するための保存の機能(「タスク・フローでのセーブポイントの使用」を参照)。
「保存」は、ADFコントローラ・レイヤーでアクティブ化され、現在のUIおよびコントローラの状態のスナップショットを自動的に保存し、さらにADFモデル・レイヤーに委譲することでその状態も保存します。後で使用するための保存では、未完了のトランザクションが検証規則の強制またはデータの送信なしで保存されます。これを使用して、データおよびリージョン、ビュー・ポート、ポートレットに関する状態情報を保存できます。明示的保存(ユーザーが開始)または暗黙的保存(ユーザーによる操作なし)のどちらにも対応するセーブ・ポイントに関連付けられているアプリケーション状態とデータを後からリストアできます。エンド・ユーザーは、もともとはアプリケーションの終了時に保存されたデータと同じものを使用して、同じトランザクションの処理を再開できます。

- ADFモデル・レイヤーのアプリケーション状態管理機能は、アプリケーション・モジュールで実装されます。
アプリケーション状態管理機能によって、ADFランタイムは、各ユーザー・セッションのアプリケーション状態を自動的に管理して、スケーラビリティの高いアプリケーションをサポートします。アプリケーション・モジュールは、保留中トランザクション状態のXMLドキュメントへの受動化(格納)をサポートし、XMLドキュメントは、インメモリーまたはデータベースの単一の汎用的な表に、一意の受動化スナップショットIDをキーとして格納されます。また、これらの保存されているXMLスナップショットの1つから保留中トランザクション状態を能動化する逆の操作もサポートします。この受動化およびアクティブ化は、アプリケーション・モジュール・プールによって必要に応じて自動的に実行され、指定できる構成プロパティによって制御されます。「受動化とアクティブ化が行われるタイミングの管理」で説明しているように、この重要な機能を最大限に活用するには、背後で行われていることを理解しておく必要があります。

- アプリケーション状態管理は、サーバー・ファーム、またはフェイルオーバーを使用するクラスタ化サーバー環境に対応します。
フェイルオーバーが有効な複数アプリケーション・サーバー環境でデプロイする場合、以降のエンドユーザー・リクエストは、サーバー・ファームまたはクラスタ内の任意のサーバーで処理できます。このシナリオに対応するために、アプリケーション状態管理機能は、すべてのリクエストの最後にアプリケーション・モジュールを受動化します。フェイルオーバーが発生してユーザー・セッションが別のサーバー・ノードにリダイレクトされた場合、セッションCookieでは、データベース利用のXMLスナップショットから、保留中のアプリケーション状態を再アクティブ化でき、このとき、どのサーバーがこの要求を処理するかは関係ありません。アプリケーション・モジュールの受動化およびアクティブ化にはクラスタ・フェイルオーバーのサポートが組み込まれており、追加の構成は必要ありません。フェイルオーバーのADFサポートの詳細は、「Fusion Webアプリケーションの高可用性の構成」を参照してください。

ADFビジネス・コンポーネントのアプリケーション・モジュールを使用して、完全にステートレスなアプリケーションを実装したり、複数のブラウザ・ページが関係する作業単位をサポートしたりできます。図56-1は、これらのマルチステップ・シナリオをサポートするための状態管理機能の基本アーキテクチャを示しています。

図56-1 ADFが提供するデータベースを利用した汎用的な状態管理

ADFバインディング・コンテキストは、エンド・ユーザーごとのHttpSessionに存在する1つのオブジェクトです。このコンテキストが保持するのは、軽量アプリケーション・モジュール・データ・コントロール・オブジェクトへの参照であり、このオブジェクトは、各リクエスト時(データ・コントロールにアクセスしたとき)におけるプールからのアプリケーション・モジュール・インスタンスの取得と、各リクエストの終了時のプールへの解放を管理します。データ・コントロールは、ユーザー・セッションを識別するアプリケーション・モジュール・ハンドルへの参照を保持します。具体的には、保留中トランザクションで作成または変更されるアプリケーション・モジュール状態のシリアル化セッション・オブジェクトは、この手法を使用するHttpSessionには保存されません。これにより、ユーザーごとに必要なセッション・メモリーが最小になり、サーバーがクラスタ構成の場合のセッション・レプリケーションに関係するネットワーク・トラフィックがなくなります。

56.1.1 マルチステップ・タスクに関する必知事項

一般的な検索後に編集を行うシナリオでは、エンド・ユーザーは、更新する適切な行を検索して発見した後、作業を保存するかキャンセルするかを決定する前に、関連するマスター/ディテール情報の複数のページを開いて編集を行うことができます。エンド・ユーザーが休暇の予約をオンラインで行う別のシナリオを考えてみます。プロセスには、エンド・ユーザーによる次の詳細情報の入力が含まれる場合があります。

- 旅行に含まれる1つ以上の飛行機利用区間

- 旅行する1人以上の乗客

- 座席の選択と食事の指定

- 異なる都市での1つ以上のホテルの部屋

- 借りる自動車

ユーザーは途中で、トランザクションの完了、後で行うための予約の保存、または保存前のトランザクションの中止を決定します。

これらのシナリオには複数のWebページにまたがる論理的な作業単位が含まれることは明らかです。これまでの章では、JDeveloperのJSFページ・ナビゲーション・ダイアグラムを使用してこのようなユースケースに対するページ・フローを設計する方法を見てきましたが、それはパズルのほんの一部にすぎません。途中のビジネス・ドメイン・オブジェクト(Trip、Flight、Passenger、Seat、HotelRoom、Autoなど)に対してエンド・ユーザーが行う保留変更は、各エンド・ユーザーに対するアプリケーションの進行中状態を表します。これとともに、前のステップで行われた選択に関する他の種類の記録された情報が、アプリケーション状態の全体像を構成します。

56.1.2 ステートレスHTTPプロトコルに関する必知事項

マルチステップ・アプリケーション・シナリオを容易に想像できる場合もありますが、Webアプリケーションでの実装は、HTTP (hypertext transfer protocol)のステートレスな性質のために複雑になります。図56-2は、サイトへのエンド・ユーザーの訪問がHTTPの一連のリクエスト/レスポンスのペアで構成される様子を示しています。しかし、HTTPには、Webサーバーが異なるユーザーのリクエストを区別したり、同じユーザーがサイトとの対話中に行った異なるリクエストを区別したりするための手段がありません。サーバーは、ユーザーからのリクエストを、常にそれが最初にして唯一のものであるかのように受け取ります。

図56-2 Webアプリケーションが使用するステートレスなHTTPプロトコル

56.1.3 セッションCookieに関する必知事項

図56-3で示されているように、ステートレスなHTTPプロトコルを介した同じエンド・ユーザーからのリクエスト・シーケンスの継続を認識するために使用される手法には、cookieと呼ばれる一意の識別子が関係します。Cookieは名前と値のペアであり、サイトに対してユーザーが行う各HTTPリクエストのヘッダー情報で送信されます。ユーザーが行う最初のリクエストには、Cookieは含まれていません。サーバーは、cookieが存在しないことを利用して、ユーザーとサイトとの対話セッションの開始を検出し、そのユーザーに対するそのセッションを表す一意の識別子をブラウザに返します。実際のCookieの値は文字と数字から成る長い文字列ですが、説明を簡単にするために、一意の識別子はサイトを使用する異なるユーザーに対応するAやZなどの1文字であるものとします。

Webブラウザは、サーバーから返されるCookieを認識するための標準的な方法をサポートすることによって、次の項目を識別することが可能になっています。

- Cookieを送信したサイト

- Cookie値を保持する必要のある期間

そのユーザーがそれ以降に行う各リクエストにおいて、ブラウザは、Cookieの有効期限が切れるまで、リクエストのヘッダーとともにCookieを送信します。サーバーは、Cookieの値を使用して、異なるユーザーによって行われたリクエストを区別します。

Cookieは、最初に作成されてから週、月または年が経過してから有効期限が切れるように単一のブラウザ・セッションを超えて持続するように設定できますが、セッションCookieは、ユーザーがブラウザを閉じると有効期限が切れます。

図56-3 セッションCookieとサーバー・サイド・セッションを使用した状態の追跡

Java EEに準拠するWebサーバーが提供するHttpSessionと呼ばれる標準のサーバー・サイド機能を利用すると、Webアプリケーションで、特定のユーザーのセッションに関連するJavaオブジェクトを、属性と値の名前付きのペアとして保管できます。あるリクエストでこのセッションMapに格納されたオブジェクトは、同じセッションの以降のリクエストが処理されている間に、アプリケーションが取得できます。

<web.xml>ファイルの<session-timeout>要素によって指定される時間枠内で、ユーザーが新しいリクエストの送信を続けている間、セッションはアクティブ状態を保ちます。デフォルトのセッションの長さは、通常は30分前後で、コンテナによって異なります。

56.1.4 HttpSessionの使用に関する必知事項

HttpSession機能はほとんどのアプリケーション状態管理戦略の構成要素ですが、使用方法を誤ると、パフォーマンスと信頼性の問題につながる可能性があります。まず、アプリケーションが作成するセッション・スコープのJavaオブジェクトはJava EE Webサーバーのメモリーに保持されるため、サーバーで障害が発生すると、HTTPセッションのオブジェクトは失われます。

図56-4で示されているように、信頼性を高める1つの方法は、複数のJava EEサーバーをクラスタ構成にすることです。このようにすると、Java EEアプリケーション・サーバーはユーザーごとのHTTPセッションのオブジェクトをクラスタ内の複数のサーバーにレプリケートするため、1台のサーバーが停止しても、オブジェクトはクラスタ内の他のサーバーのメモリーに存在し、ユーザーのリクエストの処理を続行できます。クラスタは異なるサーバーで構成されるため、サーバー間でのHTTPセッション・コンテンツのレプリケーションには、HTTPセッション・オブジェクトに対して行われた変更の、ネットワークを通したブロードキャストが含まれます。

図56-4 サーバー・クラスタでのセッション・レプリケーション

HTTPセッションの乱用は、パフォーマンスに影響を与える可能性があります。

- アクティブなユーザーが増えると、サーバーで作成されるHTTPセッションが増加します。

- HTTPセッションごとに格納されるオブジェクトが増えると、必要なメモリーが増加します。ユーザーがアクティブでなくなってもメモリーが解放されない点に注意してください。これが発生するのは、セッション・タイムアウトまたは明示的なセッション無効化の場合のみです。ユーザーが常にログアウトするわけではないため、セッション無効化は常に発生するとはかぎりません。

- クラスタにおいて、各HTTPセッションで変化するオブジェクト増えると、変化したオブジェクトをクラスタの他のサーバーにレプリケートするために生成されるネットワーク・トラフィックが増加します。

最初は、セッションで保管されるオブジェクトの数を最小限に保つことで問題に対処できるように思われます。しかし、これは、各ユーザーの保留中のアプリケーション状態を一時的に格納するために代替メカニズムを利用することを意味します。ADFビジネス・コンポーネントは、このソリューションをすぐに実装できる状態で提供します。

56.2 受動化とアクティブ化が行われるタイミングの管理

受動化/アクティブ化サイクルは、アプリケーション・モジュール・プーリングに対応しており、本来は妥当な数のキャッシュをメモリーに維持することを目的として設計されましたが、高可用性のクラスタ化サーバー環境でのフェイルオーバーにも対応しています。ただし、このプロセスでは、データベースへのアプリケーション・モジュール状態の読み書きが必要であり、それ自体が費用のかかる操作になります。32ビット・プラットフォームで構成されるレガシー・システムでは、通常、今日の中間層サーバーよりも利用可能なメモリー量は少なく、アプリケーション・モジュール・インスタンスの受動化によってメモリー制限が補正されていました。

今日のシステムでは、一般的にRAMが制限事項ではなくなり、中間層サーバーのメモリー使用量を減らすことで受動化/アクティブ化から得られるメリットはわずかになっています。現在は、クラスタ化サーバー環境での障害状況に対応することが、アプリケーション・モジュール・プーリングに組み込まれた受動化/アクティブ化サイクルの最適な利用手段になっています。

次のシナリオは、アプリケーション・モジュール状態の自動的な受動化とアクティブ化が行われるタイミングを表しています。このバックグラウンドは、受動化/アクティブ化の使用を制限するためにアプリケーション・モジュール・プーリングをどのようにチューニングするかを後で理解する場合に役立ちます。

1. HTTPリクエストの開始時に、アプリケーション・モジュール・データ・コントロールは、プールからアプリケーション・モジュール・インスタンスをチェックアウトすることで、beginrequestイベントを処理します。
アプリケーション・モジュール・プールは、参照されないインスタンスを返します。参照されないアプリケーション・モジュールとは、その時点では他のユーザー・セッションに対する保留中の状態を管理していないモジュールです。

2. リクエストの終了時に、アプリケーション・モジュール・データ・コントロールは、アプリケーション・モジュール・インスタンスを管理対象状態モードでプールに戻すことで、endrequestイベントを処理します。
アプリケーション・モジュール・インスタンスは、この時点では、それを使用していたデータ・コントロールによって参照されています。また、アプリケーション・モジュール・インスタンスは、データ・コントロールによって行われ、メモリーに格納された、保留中のトランザクション状態(つまり、エンティティ・オブジェクトおよびビュー・オブジェクトのキャッシュ、行われてまだコミットされていない変更、およびカーソル状態)をまだ含んでいるオブジェクトです。この後で説明するように、インスタンスは、このデータ・コントロールに専用のものではなく、参照されているのみです。

3. 以降のリクエストでは、そのアプリケーション・モジュール・ハンドルによって識別される同じデータ・コントロールが、アプリケーション・モジュール・インスタンスを再びチェックアウトします。
プールが使用するユーザー・アフィニティによるステートレスなアルゴリズムのため、状態がまだメモリー内に存在しているまったく同じアプリケーション・モジュール・インスタンスがプールから返されます。

アプリケーション・モジュール・プーリングのデフォルト構成により、サイトに同時にアクセスするユーザー数が多いピーク使用時は、異なるユーザー・セッションでアプリケーション・モジュール・インスタンスを順番に再利用する必要があることが指示されます。この場合、アプリケーション・プールは、現在参照されているアプリケーション・モジュール・インスタンスを別のセッションによる使用のために次のようにリサイクルします。

1. ユーザーAのセッションのアプリケーション・モジュール・データ・コントロールは、リクエストの終了時に、アプリケーション・モジュール・インスタンスをアプリケーション・プールにチェックインします。このインスタンスの名前をAM1とします。

2. ユーザーZの新しいセッションのアプリケーション・モジュール・データ・コントロールは、初めてプールにアプリケーション・モジュール・インスタンスを要求しますが、使用可能な参照されていないインスタンスはありません。このとき、アプリケーション・モジュール・プールは次のようにします。

- インスタンスAM1の状態をデータベースに受動化します。

- 別のセッションが使用するための準備として、AM1の状態をリセットします。

- AM1インスタンスをユーザーZのデータ・コントロールに返します。

3. その後のリクエストで、ユーザーAのセッションのアプリケーション・モジュール・データ・コントロールが、プールにアプリケーション・モジュール・インスタンスを要求します。このとき、アプリケーション・モジュール・プールは次のようにします。

- 参照されていないインスタンスを取得します。
これは、前述の手順2と同じタスクに従って取得されたインスタンスAM1である場合も、または途中で参照されなくなった場合は別のインスタンスAM2である場合もあります。

- ユーザーAに対する適切な保留中状態をデータベースから能動化します。

- アプリケーション・モジュール・インスタンスをユーザーAのデータ・コントロールに返します。

つまり、受動化、アクティブ化およびリサイクルのプロセスにより、データ・コントロールごとに専用のアプリケーション・モジュール・インスタンスを必要とせずに、データ・コントロールによって参照される状態をリクエスト間で保持します。前述のシナリオのブラウザ・ユーザーはどちらも、複数のHTTPリクエストにわたってアプリケーション・トランザクションを継続しますが、エンド・ユーザーには、バックグラウンドで受動化と能動化が行われているかどうかはわかりません。保留中の変更が継続して表示されるだけです。エンド・ユーザーが作業の論理的な単位をコミットできる状態になるまで、保留中の変更を基礎のアプリケーション・データベースの表に保存する必要はありません。アプリケーション・モジュール・プールは、アプリケーション・モジュール・インスタンスを、その保留中状態を管理している現在のデータ・コントロールにできるかぎり結び付けておこうとします。これは、ユーザー・セッション・アフィニティの維持と呼ばれます。

最適なパフォーマンスを実現するには、デプロイしたFusion Webアプリケーションでの受動化/アクティブ化サイクルの必要性を最小限に抑えます。これを制御するにはデフォルトの構成パラメータを変更します。これらのパラメータでは、アプリケーション・モジュール・プールのサイズを指定して、プール・マネージャのリソース・クリーンアップ動作を制御し、ユーザー・リクエストの最後にアプリケーション・モジュール・インスタンスで使用されるJDBC接続の切断動作をチューニングします。アプリケーション・モジュール・プールを調整して受動化を軽減する設計時構成パラメータの詳細は、「アプリケーション・モジュール・プーリング構成パラメータに関する必知事項」を参照してください。

56.2.1 Fusion Webアプリケーションがオプティミスティック・ロックを使用していることを確認する方法

Webアプリケーションのデフォルト・モードであるオプティミスティック・ロックを使用することをお薦めします。ペシミスティック・ロックは、行レベル・ロックの形でデータベースに保留トランザクション状態を作り出すため、Webアプリケーションでは使用しないようにする必要があります。ペシミスティック・ロックを設定しても状態管理は動作しますが、ロック・モードは予想したほどのパフォーマンスになりません。裏側では、アプリケーション・モジュールがリサイクルされるたびに、JDBC接続でロールバックが発行されます。これにより、ペシミスティック・ロックが作成していたすべてのロックが解放されます。

パフォーマンスに関するヒント

常に、Webアプリケーションのデフォルト・モードであるオプティミスティック・ロックを使用します。オプティミスティック・ロックのみが、アプリケーション・モジュールの非管理解放レベル・モードと互換性があり、この場合、Webページが終了すると、アプリケーション・モジュール・インスタンスをすぐに解放することができます。これにより、多くのユーザーがアプリケーションに同時にアクセスすることが見込まれるWebアプリケーションで、最高レベルのパフォーマンスが実現されます。

構成がオプティミスティック・ロックを使用していることを確認するには、adf-config.xml概要エディタの「ビジネス・コンポーネント」ページを開き、「ロック・モード」(jbo.locking.modeプロパティに対応)がoptimisticまたはoptupdateになっていることを確認します。adf-config.xmlエディタを開くには、「アプリケーション・リソース」ウィンドウで、「ディスクリプタ」および「ADF META-INF」フォルダを展開し、ファイル・ノードをダブルクリックします。

オプティミスティック・ロック(optimistic)では、SELECT FOR UPDATE文を発行して行をロックし、更新識別子属性を比較することによって、行が別のユーザーによって変更されているかどうかを判定します。また、更新識別子が指定されていない場合は、エンティティ・オブジェクトがキャッシュにフェッチされたときに存在していた、現在のエンティティのすべての永続的な属性の値を比較します。

オプティミスティック・ロック(optupdate)では、ロックは実行されません。UPDATE文が、現在のエンティティ・オブジェクトがフェッチされた時から属性値が変わっていない場合にかぎり既存の行と一致するWHERE句を含むことによって、行が別のユーザーによって更新されたかどうかを判定します。

56.2.2 HTTPリクエストでの保留中の変更に関する必知事項

ADFの状態管理メカニズムは、受動化と能動化を利用して、アプリケーション・モジュール・インスタンスの状態を管理します。この機能の安定した実装は、すべての保留中の変更が中間層のアプリケーション・モジュール・トランザクションによって管理される場合にのみ可能です。最もスケーラブルな戦略は、保留中の変更を中間層のオブジェクトに維持し、HTTPリクエストの間で保留データベース状態が存在するような操作を実行しないようにすることです。これにより、アプリケーション・モジュール・プールが提供するパフォーマンスの最適化を最大限に利用し、アプリケーションにとって最も安定したランタイム動作を実現できます。

注意:

jbo.doconnectionpooling構成パラメータをtrueに設定する場合(一般に、データベース接続の共通プールを複数のアプリケーション・モジュール・プールで共有するため)、アプリケーション・モジュールをアプリケーション・モジュール・プールに解放すると、そのJDBC接続が解放されてデータベース接続プールに戻され、その接続でROLLBACKが発行されます。その結果、ポストされていてコミットされていなかったすべての変更が失われます。次のリクエストで、アプリケーション・モジュールが使用されると、プールからJDBC接続を受け取りますが、前回使用していたものとは異なるJDBC接続インスタンスである可能性があります。これにより、データベースにポストされ、前のリクエストの間にコミットされていなかった変更は、失われます。

jbo.doconnectionpooling構成パラメータは、アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタの「データベースとスケーラビリティ」タブで、「解放時にアプリケーション・モジュールの切断」プロパティを選択して設定します。

56.2.3 解放レベルおよびpostChanges()メソッドに関する必知事項

検証前の変更をコミットせず、トランザクションから強制的に送信するようなトランザクション・レベルのpostChanges()メソッドが存在します。このメソッドは、同一のHTTPリクエスト内でのトランザクションのコミットまたはロールバックが必ず実行される場合を除き、Webアプリケーションでの使用はお薦めしません。使用した場合、複数の異なるクライアントにより、アプリケーション・モジュールとデータベース接続の両方がプールされ、シリアルに共有されるという事態が環境内で発生する可能性があります。

なんらかの理由で、postChanges()メソッドを呼び出して、またはPL/SQLのストアド・プロシージャをコールして、特定のリクエスト内でデータベースにトランザクション状態を作成する必要があり、同じリクエストの終わりまでにコミットまたはロールバックを発行できない場合は、後のリクエストでコミットまたはロールバックするまでの間に、そのリクエストから予約レベルでアプリケーション・モジュール・インスタンスを解放する必要があります。

注意:

データベースでのトランザクション状態の作成から最後のコミットまたはロールバックの実行までを可能なかぎり短くして使用します。これは、予約レベルがアプリケーションのスケーラビリティと信頼性に悪影響を及ぼすため、予約レベルを長時間使用する必要がないようにします。

アプリケーション・モジュールを予約レベルで解放すると、予約レベルを明示的に管理レベルまたは非管理レベルに変更して戻すまで、以降のすべてのリクエストは予約レベルのままになります。したがって、コミットまたはロールバックを発行したら、責任を持って予約レベルを管理レベルに戻す必要があります。

56.3 アプリケーション・モジュールの能動化が安全であることの確認テスト

保留状態を受動化スナップショットから能動化したときにアプリケーション・モジュールが機能することを明確にテストしていない場合、システムに高い負荷がかかることによってシステムのこの面が初めてテストされたときに、本番環境で予期せず不愉快な経験をする可能性があります。

56.3.1 能動化をテストするためにアプリケーション・モジュール・プーリングを無効化する方法

全体的なテスト計画の一部として、jbo.ampool.doampooling構成パラメータをfalseに設定した状態でアプリケーション・モジュールをテストする方法を採用することをお薦めします。このように設定すると、アプリケーション・モジュール・プーリングは完全に無効になり、ページ・リクエストがあるたびに、システムは受動化スナップショットからアプリケーション・モジュールの保留状態を能動化するように強制されます。これは、カスタム・アプリケーション・コードで行われている想定のために本番環境で発生する可能性のある問題を検出する優れた方法です。

注意:

テストが終了し、アプリケーションを本番環境でデプロイする準備が整ったら、アプリケーション・モジュールのプーリングを再度有効化することが重要です。構成プロパティjbo.ampool.doampoolingをfalseに設定する構成は、本番環境のアプリケーションではサポートされていないため、アプリケーションをデプロイする前にtrueに設定する必要があります。

たとえば、受動化されていると確信している一時ビュー・オブジェクト属性がある場合、この手法を使用すると、意図したとおりに動作しているかどうかをテストできます。さらに、次のものを導入している状況を考えてみます。

- アプリケーション・モジュール、ビュー・オブジェクトまたはエンティティ・オブジェクトのプライベート・メンバー・フィールド

- Sessionユーザー・データ・ハッシュ表のカスタム・ユーザー・セッション状態

カスタム・コードでは、このカスタム状態がHTTPリクエスト間で維持されているものとされている場合があります。JDeveloper Integrated WebLogic Serverを使用して1人のユーザーでテストしている場合、または少数のユーザーでテストしている場合は、問題なく動いているように見えます。これは、ADFアプリケーション・モジュール・プールのアフィニティによるステートレスの最適化によるものです。システムの負荷が許せば、プールは後のリクエストでもユーザーに同じアプリケーション・モジュール・インスタンスを返し続けます。しかし、負荷が大きい、現実の使用においては、この最適化を実現できない場合があり、使用できる任意のアプリケーション・モジュール・インスタンスを取得して、受動化スナップショットから保留状態を再能動化することが必要になります。カスタム・コンポーネントの状態を受動化スナップショットに保存してそこからリロードするためのpassivateState()とactivateState()のオーバーライド(「受動化時のカスタム・ユーザー固有情報の管理」を参照)が正しく行われていないと、この再能動化ステップの後でカスタム状態が失われます(つまり、nullになるか、デフォルト値に戻ります)。jbo.ampool.doampoolingをfalseに設定してテストすることで、コードに存在するこの種の状況を素早く検出できます。

ビジネス・コンポーネント構成プロパティを構成する方法の詳細は、「構成プロパティの宣言的設定方法」。

56.3.2 jbo.ampool.doampooling構成パラメータに関する必知事項

jbo.ampool.doampooling構成プロパティは、アプリケーション・モジュール構成(bc4j.xcfgファイル)の概要エディタの「データベースとスケーラビリティ」タブにある「アプリケーション・モジュール・プーリングの有効化」オプションに対応しています。デフォルトでは、このチェック・ボックスは選択されていて、アプリケーション・モジュール・プーリングは有効になっています。本番環境でアプリケーションをデプロイする場合は、常にデフォルト設定のjbo.ampool.doampooling=trueにしてアプリケーションを実行します。ただし、テスト環境でアプリケーションを実行するかぎり、テストでは、このプロパティをfalseに設定することで重要な役割を果せます。このプロパティがfalseの場合、実質的にアプリケーション・プールはありません。リクエストの最後でアプリケーション・モジュール・インスタンスが解放されると、ただちに削除されます。同じユーザー・セッションによって行われる以降のリクエストでは、リクエストを処理するために新しいアプリケーション・モジュール・インスタンスを作成する必要があり、アプリケーション・モジュールの保留状態を受動化ストアから再能動化する必要があります。

ビジネス・コンポーネント・プロパティを構成する方法の詳細は、「構成プロパティの宣言的設定方法」。

56.3.3 状態管理とデータの整合性に関する必知事項

エンティティ・オブジェクトが複数のユーザーによって同時に更新され、これらのユーザーのいずれかが更新時にアプリケーション・モジュールのアフィニティを失った場合、エンティティ・オブジェクトに対して更新識別子が定義されていなければ、データを損失する可能性があります。

2人のユーザー(ユーザーAとユーザーB)が同じエンティティ・オブジェクトに同時にアクセスするシナリオについて考えてみましょう。

- 問合せの後、ユーザーBが属性の値を変更(たとえば、Dept属性の値をAccountingからResearchに変更)して、コミットします。

- その間に、ユーザーAも問合せを行い、Dept属性の値がAccountingになっている同じレコードを表示します。

- ユーザーAは問合せに使用したアプリケーション・モジュールによるアフィニティを失い、受動化が発生します。

- 次にユーザーAがDept属性の値をAccountingからSalesに変更してコミットすると、アクティブ化が発生します。

- アクティブ化が発生すると、Dept属性の新しい値がアクティブ化されますが、ブラウザはデータ変更を認識せず、問題なくコミットが実行されます。

このタイプのシナリオを防止するには、すべてのエンティティ・オブジェクトに対して更新識別子属性を定義します。詳細は、「同時更新によるデータの消失を防ぐ方法」を参照してください。

56.3.4 状態管理とサブクラス化エンティティ・オブジェクトに関する必知事項

アプリケーションがサブクラス化されたエンティティ・オブジェクトを使用する場合、新しいエンティティのキー属性を事前に移入する必要があります。キーを事前に移入しないと、受動化および能動化が失敗します。create()メソッドをオーバーライドするかまたはコミット後に実際の値をデータベースからフェッチする前に一時的に負の値をキーに割り当てるDBSequenceタイプを使用することによってキー属性を事前に移入できます。詳細は、「トリガーによってデータベース順序から割り当てられた主キー値の取得方法」を参照してください。

56.4 モデル状態が保存される場所の制御

デフォルトでは、受動化スナップショットはデータベースに保存されますが、かわりにファイル・システムを使用するよう構成できます。

受動化されたXMLスナップショットは、データベースに保存される場合、jbo.server.internal_connectionプロパティで指定されている接続を使用して、PS_TXNという名前の表のBLOB列に書き込まれます。受動化レコードが保存されるたびに、受動化レコードには、PS_TXN_SEQ順序から取得された順序番号に基づいて、一意の受動化スナップショットIDが割り当てられます。ADFバインディング・コンテキストのアプリケーション・モジュール・データ・コントロールによって保持されるアプリケーション・モジュール・ハンドルは、かわりに作成された最新の受動化スナップショットIDと、使用された前回のIDを記憶しています。

56.4.1 状態管理表が存在するスキーマの制御方法

ADFランタイムは、PS_TXN表およびPS_TXN_SEQ順序の作成に使用する必要のあるデータベース接続およびスキーマを制御するjbo.server.internal_connectionという名前の構成プロパティを認識します。この構成パラメータの値が明示的に設定されていない場合、状態管理機能は、現在のアプリケーション・データベース接続の資格証明を使用して、一時的な表を作成します。

一時的な情報を別に保持するため、状態管理機能は、データベース接続プールから別の接続インスタンスを使用しますが、データベース資格証明は現在のユーザーと同じです。フレームワークは、一時的な表を作成し、存在しない場合には順序を作成することがあるため、jbo.server.internal_connectionの値を設定しないということは、現在のデータベース・ユーザーが、CREATE TABLE、CREATE INDEXおよびCREATE SEQUENCEの各権限を持つ必要があることを意味します。これは望ましくない場合が多いため、jbo.server.internal_connectionプロパティには常に適切な値を指定し、表とスキーマが作成される状態管理スキーマに対して資格証明を提供することをお薦めします。構成のjbo.server.internal_connectionプロパティに対する有効な値は、次のとおりです。

- 次のような、完全修飾されたJDBC接続URL:
jdbc:oracle:thin:username/password@host:port:SID

- 次のような、JDBCデータ・ソース名:
java:/comp/env/jdbc/YourJavaEEDataSourceName

パフォーマンスに関するヒント

PS_TXN表を作成する際は、securefileを使用してLOBデータ(コンテンツ列)を格納し、PS_TXN表に、グローバルでパーティション化された逆キー索引としてプライマリ列索引を作成します。LOBデータを処理する場合、securefile構成は、basicfile構成よりも優れたパフォーマンスをもたらします。逆キー索引は、挿入の比率が高い場合に発生する競合を削減することにより役立ちます。

56.4.2 受動化ストアを構成する方法

受動化された情報は、複数の場所に格納できます。これを制御するには、アプリケーション・モジュール構成でオプションを構成します。選択肢は、データベースまたはローカル・ファイル・システムに格納されるファイルです。

- ファイル
ファイルにアクセスする方がデータベースにアクセスするより速いため、これは使用できる最も速い選択肢である場合があります。中間層全体が同じマシン上にインストールされているか共有ファイル・システムにアクセスでき、受動化情報にアクセスできる場合には、この選択肢が適しています。通常、この選択肢は、使用されているOracle WebLogic Serverドメインが1つである小さい中間層に適しています。つまり、Oracle WebLogic Serverインスタンスが1つで、そのすべてのコンポーネントが1台の物理マシンにインストールされているような小型の中間層には、非常にふさわしい選択です。永続スナップショット・ファイルの場所と名前は、jbo.tmpdirプロパティ(指定されている場合)によって決まります。この指定は、構成プロパティに関する通常のADFプロパティ優先順位の規則に従います。他になにも指定されていない場合、場所はuser.dirによって決まります(指定されている場合)。これはデフォルトのプロパティであり、OS固有です。

- データベース
これがデフォルトの選択です。ファイルへの受動化より少し遅くなる場合がありますが、信頼性ははるかに優れています。ファイルへの受動化でよくある問題は、リモートでインストールされているOracle WebLogic Serverインスタンスがアクセスできないことです。この場合、クラスタ環境では、1つのノードがダウンすると、他のノードは受動化された情報にアクセスできず、フェイルオーバーが機能しません。可能性のあるもう1つの問題は、リモート・ノードがファイルにアクセスできたとしても、ローカル・ノードとリモート・ノードでアクセス時間が大きく異なり、パフォーマンスが一定でなくなります。データベース・アクセスの場合、時間はすべてのノードでほぼ同じです。

設計時に選択した値を設定するには、jbo.passivationstoreプロパティにdatabaseまたはfileを設定します。値nullは、接続の種類に固有のデフォルトを使用することを示します。OracleまたはDB2の場合はデータベースによる受動化を使用し、それ以外はファイル・シリアライズを使用します。

56.4.3 実行時に行われる処理: 保存されるモデル状態とそのクリーンアップのタイミング

アプリケーション・モデルの受動化によって保存される情報は、トランザクション状態と非トランザクション状態の2つの部分に分かれます。トランザクション状態は、エンティティ・オブジェクト・データに対して行われた、データベースへの保存が意図されている更新のセットであり、エンティティ・オブジェクトに対して直接実行されるか、ビュー・オブジェクトの行を介してエンティティに実行されます。非トランザクション状態は、現在の行インデックス、WHERE句、ORDER BY句など、ビュー・オブジェクトの実行時設定で構成されます。

アプリケーション・モジュールの受動化スナップショットの一部として保存される情報には、次のものが含まれます。

トランザクション状態

- このユーザー・セッションに対するルート・アプリケーション・モジュールのエンティティ・キャッシュにおける新しいエンティティ、変更されたエンティティおよび削除されたエンティティ(変更の場合は新旧の値を含みます)。

非トランザクション状態

- アクティブ・ビュー・オブジェクトごとに次のもの(静的および動的に作成されたもの両方):

- 各行セットの現在の行インジケータ(通常は1)

- 新しい行とその位置。(新しい行は、更新された行とは別に扱われます。ビュー・オブジェクトにおけるそのインデックスも追跡されます。)

- ViewCriteriaおよびビュー基準行などの関連するすべてのパラメータ。

- 行セットが実行されたかどうかを示すフラグ

- 範囲の開始と範囲のサイズ

- アクセス・モード

- フェッチ・モードとフェッチ・サイズ

- すべてのビュー・オブジェクト・レベルのカスタム・データ

注意:

設計時に受動化のためにビュー・オブジェクト一時属性が選択されている場合、その属性を保存できます。ただし、これにより、取得される行数が多くなると、スナップショットのサイズも大きくなっていくため、この機能は慎重に使用してください。一時属性の受動化を有効にする方法の詳細は、「ビュー・オブジェクトの状態の管理方法」を参照してください。

- 動的に作成された場合、またはビュー定義から変更された場合は、SELECT、FROM、WHERE、ORDER BYの各句

注意:

ADFビジネス・コンポーネントのランタイム診断を有効にしている場合は、各XML状態スナップショットの内容も保存されます。診断を有効にする方法の詳細は、「ADFビジネス・コンポーネント・デバッグ診断を有効化する方法」を参照してください。

ユーザー固有情報やインスタント変数など、ADFビジネス・コンポーネント・オブジェクト内のその他の情報は、受動化スナップショットの一部として保存されません。このタイプの情報を保存するには、「受動化時のカスタム・ユーザー固有情報の管理」で説明した手法を使用します。

56.5 モデル状態のクリーンアップ

通常の環境では、ADF状態管理機能は、受動化スナップショット・レコードを自動的にクリーンアップします。

56.5.1 受動化で生じる一時格納表のクリーンアップ方法

JDeveloperでは、アプリケーション・モジュール状態管理表を定期的にクリーンアップするための手段として、adfbc_purge_statesnapshots.sqlスクリプトが提供されています。このファイルは、Oracle Middlewareインストール・ディレクトリのoracle_commonサブディレクトリにあります(例: ORACLE_HOME\oracle_common\common\sql)。

サーバーが開発時や障害時などに異常な方法でシャットダウンすると、永続的スナップショット・レコードが時間とともに蓄積します。SQL*Plusでスクリプトを実行すると、BC4J_CLEANUP PL/SQLパッケージが作成されます。このパッケージには、2つの関連するプロシージャがあります。

- PROCEDURE Session_State(olderThan DATE)
このプロシージャは、特定の日付より古いセッションのアプリケーション・モジュール・セッション状態記憶域をクリーンアップします。

- PROCEDURE Session_State(olderThan_minutes INTEGER)
このプロシージャは、特定の分数より古いセッションのアプリケーション・モジュール・セッション状態記憶域をクリーンアップします。

このパッケージの適切なプロシージャの呼出しをデータベース・ジョブとして発行することで、ADFの一時的永続記憶域の定期的なクリーンアップをスケジュールできます。

次の例に示すような匿名PL/SQLブロックを使用することで、bc4j_cleanup.session_state()の実行を、翌日の2:00amに開始してそれ以降毎日実行し、状態が1日(1440分)を超えているセッションをクリーンアップするようスケジュールできます。

SET SERVEROUTPUT ON
DECLARE
jobId    BINARY_INTEGER;
firstRun DATE;
BEGIN
-- Start the job tomorrow at 2am
firstRun := TO_DATE(TO_CHAR(SYSDATE+1,'DD-MON-YYYY')||' 02:00',
'DD-MON-YYYY HH24:MI');
-- Submit the job, indicating it should repeat once a day
dbms_job.submit(job       => jobId,
-- Run the ADF Purge Script for Session State
-- to cleanup sessions older than 1 day (1440 minutes)
what      => 'bc4j_cleanup.session_state(1440);',
next_date => firstRun,
-- When completed, automatically reschedule
-- for 1 day later
interval  => 'SYSDATE + 1'
);
dbms_output.put_line('Successfully submitted job. Job Id is '||jobId);
END;
.
/

56.5.2 実行時に行われる処理: 受動化レコードを更新するタイミング

セッションCookieのかわりに受動化レコードがデータベースに保存されたとき、この受動化レコードにより、新しい一意のスナップショットIDが取得されます。同じトランザクションの一部として、その同じセッションCookieによって使用されていた前のスナップショットIDを持つ受動化レコードは削除されます。これにより、サーバー障害がなければ、受動化スナップショット・レコードはアクティブなエンド・ユーザー・セッションごとに1つのみ存在します。

56.5.3 実行時に行われる処理: 受動化スナップショットを管理対象外のリリースで削除するタイミング

セッションCookieに関係する受動化スナップショット・レコードは、アプリケーション・モジュールが非管理状態レベルでプールにチェックインされると削除されます。これは次の場合に発生します。

- コードがアプリケーション・モジュール・データ・コントロールでresetState()を明示的に呼び出す場合

- たとえば明示的なログアウト機能の実装の一部などとして、コードがHttpSessionを明示的に無効化する場合

- アイドル時間に対するセッション・タイムアウトのしきい値を超え、フェイルオーバー・モードが無効(デフォルト)になっているため、HttpSessionがタイムアウトする場合

いずれの場合も、アプリケーション・モジュール・プールは、セッションCookieによって参照されていたアプリケーション・モジュールも参照されていない状態にリセットします。基礎となるデータベース表には変更が保存されていないため、保留中のセッション状態スナップショットが削除されると、その時点までにユーザー・セッションが完了した未終了作業のトレースは残りません。

56.5.4 実行時に行われる処理: フェイルオーバー・モードで保持される受動化スナップショット

フェイルオーバー・モードが有効になっていると、セッションが非アクティブなためにHttpSessionがタイムアウトした場合、ユーザーがブラウザに戻ったときに作業を再開できるよう、受動化スナップショットが維持されます。

アクションが中断された後、エンド・ユーザーがブラウザに戻ってアプリケーションの使用を続けると、なにも変化がなかったかのように作業は継続されます。セッションCookieは、リクエストを処理する前のユーザーの最新の保留中状態スナップショットで、使用可能なアプリケーション・モジュール・インスタンスを再能動化するために使用されます。これにより、ユーザーの次のリクエストが新しいHttpSessionのコンテキストで処理されても(別のアプリケーション・サーバー・インスタンスであっても)、ユーザーはこのことに気付きません。

注意:

アプリケーション・モジュールが予約レベルで解放された場合、HttpSessionはタイムアウトし、ユーザーは認証プロセスを実行する必要があり、保存されていない変更はすべて失われます。

56.6 Fusion WebアプリケーションでのHttpSessionの管理

HTTPはステートレス・プロトコルであるため、クライアントがブラウザを閉じたり週末で不在になったことの暗黙の通知を、サーバーが受け取ることはありません。このため、Java EEに準拠するサーバーは、ユーザーがリクエスを停止したときにHTTPセッションに結び付けられているリソースを解放できるよう、標準的で構成可能なセッション・タイムアウトのメカニズムを提供します。プログラムでタイムアウトを強制することもできます。

56.6.1 ユーザーの非アクティブ状態による暗黙のタイムアウトの構成方法

web.xmlファイルの<session-timeout>タグを使用して、セッションのタイムアウトのしきい値を構成できます。デフォルト値は通常は30分前後で、コンテナによって異なります。

56.6.2 明示的なHttpSessionタイムアウトのコーディング方法

セッション・タイムアウトの期限が切れる前にユーザーのセッションを終了するには、ユーザーがログアウトのボタンやリンクをクリックした際に、バッキングBeanからHttpSessionオブジェクトのinvalidate()メソッドを呼び出します。これにより、セッションがタイムアウトした場合と同じ方法でHttpSessionがクリーンアップされます。JSFとADFを使用して、セッションを無効化した後は、単に転送を行うのではなく、表示する次のページへのリダイレクトを行う必要があります。次の例は、「ログアウト」ボタンからこのタスクを実行するサンプル・コードです。

public String logoutButton_action() throws IOException{
ExternalContext ectx = FacesContext.getCurrentInstance().getExternalContext();
HttpServletResponse response = (HttpServletResponse)ectx.getResponse();
HttpSession session = (HttpSession)ectx.getSession(false);
session.invalidate();
response.sendRedirect("Welcome.jspx");
return null;
}

暗黙のタイムアウトと同様に、HTTPセッションをこの方法でクリーンアップすると、参照されていたアプリケーション・モジュールは非参照としてマークされます。

56.6.3 実行時に行われる処理: HTTPがタイムアウトしたときのアプリケーション・モジュールに対する処理

HttpSessionがタイムアウトすると、BindingContextはスコープ外となり、それとともに、アプリケーション・モジュールを参照していたすべてのデータ・コントロールは、管理状態レベルでプールに解放されます。アプリケーション・モジュール・プールは、参照されていたアプリケーション・モジュールをリセットし、インスタンスを再び参照されていない状態にします。

56.7 受動化時のカスタム・ユーザー固有情報の管理

メンバー変数の形式、またはoracle.jbo.Sessionユーザー・データ・ハッシュ表に格納されるカスタム情報の形式で、カスタム・ユーザー定義情報をアプリケーション・モジュールに追加することは、ごく一般的な方法です。ADF状態管理機能では、ApplicationModuleImplクラス内のpassivateState()メソッドおよびactivateState()メソッドをオーバーライドすることで、このカスタム情報を受動化スナップショットにも保存するためのメカニズムが提供されています。

注意:

ViewObjectImplクラスとEntityObjectImplクラスでも、似たメソッドを使用して、これらのオブジェクトのカスタム状態を受動化スナップショットに保存できます。

56.7.1 カスタム・ユーザー固有情報の受動化方法

passivateState()およびactivateState()をオーバーライドして、カスタム・アプリケーション・モジュール状態情報を受動化/能動化サイクルに確実に組み込むことができます。次に、これを行う方法を示します。

例にあるjbo.counterには、アプリケーション・モジュール状態の受動化と能動化の過程で保持するカスタム値が含まれています。各アプリケーション・モジュールにはoracle.jbo.Sessionというオブジェクトが関連付けられており、アプリケーション・モジュール固有のセッションレベル状態を格納します。セッションにはユーザー・データ・ハッシュ表があり、一時的な情報を格納できます。ユーザー固有のデータをアプリケーション・モジュールの受動化と能動化の過程で保持するには、このカスタム値をアプリケーション・モジュール状態の受動化スナップショットに保存してリストアするコードを記述する必要があります。

/**
* Overridden framework method to passivate custom XML elements
* into the pending state snapshot document
*/
public void passivateState(Document doc, Element parent) {
// 1. Retrieve the value of the value to save
int counterValue = getCounterValue();
// 2. Create an XML element to contain the value
Node node = doc.createElement(COUNTER);
// 3. Create an XML text node to represent the value
Node cNode = doc.createTextNode(Integer.toString(counterValue));
// 4. Append the text node as a child of the element
node.appendChild(cNode);
// 5. Append the element to the parent element passed in
parent.appendChild(node);
}
/**
* Overridden framework method to activate  custom XML elements
* into the pending state snapshot document
*/
public void activateState(Element elem) {
super.activateState(elem);
if (elem != null) {
// 1. Search the element for any <jbo.counter> elements
NodeList nl = elem.getElementsByTagName(COUNTER);
if (nl != null) {
// 2. If any found, loop over the nodes found
for (int i=0, length = nl.getLength(); i < length; i++) {
// 3. Get first child node of the <jbo.counter> element
Node child = nl.item(i).getFirstChild();
if (child != null) {
// 4. Set the counter value to the activated value
setCounterValue(new Integer(child.getNodeValue()).intValue()+1);
break;
}
}
}
}
}
/*
* Helper Methods
*/
private int getCounterValue() {
String counterValue = (String)getSession().getUserData().get(COUNTER);
return counterValue == null ? 0 : Integer.parseInt(counterValue);
}
private void setCounterValue(int i) {
getSession().getUserData().put(COUNTER,Integer.toString(i));
}
private static final String COUNTER = "jbo.counter";

56.7.2 カスタム情報の受動化時の処理

「カスタム・ユーザー固有情報の受動化方法」の例に示すように、activateState()をオーバーライドするときは、次の手順を実行します。

1. jbo.counter要素の要素を検索します。

2. 見つかった場合は、ノード・リストで見つかったノードをループします。

3. jbo.counter要素の最初の子ノードを取得します。
これはDOM Textノードで、その値は前述のpassivateState()メソッドが呼び出されたときに保存された、jbo.counter属性の値を表す文字列です。

4. カウンタの値に、スナップショットから能動化された値を設定します。

passivateState()がオーバーライドされると、次の手順で逆の処理を実行します。

1. 保存する値を取得します。

2. 値を収めるXML要素を作成します。

3. 値を表すためのXMLテキスト・ノードを作成します。

4. テキスト・ノードを要素の子として追加します。

5. 渡される親要素に要素を追加します。

注意:

XMLドキュメントでノードを操作するために使用するAPIは、org.w3c.domパッケージのDocument Object Model (DOM)インタフェースで提供されています。これらはJava API for XML Processing (JAXP)の一部です。詳細は、このパッケージに含まれるNode、Element、Text、Document、およびNodeListの各インタフェースのJavadocを参照してください。

56.7.3 カスタム情報の能動化に関する必知事項

ビュー・オブジェクトを能動化した後で、能動化プロセスの最後に、activateState()メソッドがコールされます。多くの場合、これは、アプリケーション・モジュール状態の能動化ロジックを配置する場所です。ただし、ADF状態管理機能がビュー・オブジェクトを能動化する前にアプリケーション・モジュールの能動化ロジックがカスタム状態情報を設定する必要がある場合(たとえば、実行時にビュー・オブジェクトがカスタム値を内部的に参照できるようにカスタム・コードを書き込む必要がある場合など)、ApplicationModuleImplクラスのprepareForActivation()メソッドは能動化プロセスの最初に起動するため、これが正しい位置となります。

56.8 受動化時のビュー・オブジェクトの状態の管理

デフォルトでは、すべてのビュー・オブジェクトが受動化可能に設定されており、これによりそれらの状態が保存されます。ただし、一時属性を持つビュー・オブジェクトは、デフォルトではそれらの属性を受動化しません。ビュー・オブジェクトの概要エディタの「チューニング」ページを使用して、ビュー・オブジェクトの受動化方法、さらにどの属性が受動化されるかを変更できます。

56.8.1 ビュー・オブジェクトの状態の管理方法

ビュー・オブジェクトごとに、宣言的に受動化可能または不可能に構成できます。ビュー・オブジェクトが受動化可能ではない場合は、ビュー・オブジェクトに関する情報はアプリケーション・モジュールの受動化スナップショットに書き込まれません。

パフォーマンスに関するヒント

UI上の値の表示に使用せず、値の計算または導出のための再入力可能メソッドでのみ使用される読取り専用ビュー・オブジェクトを受動化する必要はありません。これにより、受動化と能動化に関連するパフォーマンスのオーバーヘッドが取り除かれ、アプリケーション・モジュール・プールを維持するために必要なCPU使用率も減少します。

始める前に:

ビュー・オブジェクトの受動化に関する知識が役立つ場合があります。詳細は、「受動化時のビュー・オブジェクトの状態の管理」を参照してください。

ビュー・オブジェクトの受動化状態を設定するには:

1. 「アプリケーション」ウィンドウで、受動化の状態を設定するビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。

3. 「一般」ページで、「チューニング」セクションを開き、「状態の受動化」を選択して、ビュー・オブジェクト・データが保存されていることを確認します。

4. このとき、オプションですべての一時属性を含むを選択してすべての一時属性を受動化できますが、詳細は「一時ビュー・オブジェクトの受動化に関する必知事項」を参照してください。

56.8.2 ビュー・オブジェクトの受動化に関する必知事項

能動化メカニズムは、ビュー・オブジェクトを、最後の受動化が発生したときの状態に戻すように設計されています。それを保証するために、Oracle ADFは、最後の問合せ実行で使用されたバインド変数の値を状態スナップショットに格納します。このバインド変数は、受動化時に行セットに設定された変数に追加されるものです。受動化状態も、ユーザーが適用したWHERE句を、受動化時の行セットに関連するビュー・オブジェクトに格納します。

56.8.3 一時ビュー・オブジェクトおよび属性の状態の管理方法

一時ビュー・オブジェクト(一時属性のみを含むビュー・オブジェクト)は受動化可能に設定されていますが、ビュー・オブジェクトがデフォルトで受動化される設定になっているため、現在行およびその他の非トランザクション状態に関連する情報のみを受動化します。

パフォーマンスに関するヒント

一時ビュー・オブジェクトの属性は、デフォルトでは受動化されません。その性質上、一時ビュー・オブジェクトの属性は読取り専用として意図されていることが普通であり、簡単に再作成できます。そのため、通常は、その値をXMLスナップショットの一部として受動化しても意味がありません。これにより、受動化と能動化に関連するパフォーマンスのオーバーヘッドが取り除かれ、アプリケーション・モジュール・プールを維持するために必要なCPU使用率も減少します。

始める前に:

ビュー・オブジェクトの受動化に関する知識が役立つ場合があります。詳細は、「受動化時のビュー・オブジェクトの状態の管理」を参照してください。

また、次のタスクを実行する必要があります。

- JDeveloperでアプリケーションを開きます。

一時ビュー・オブジェクトの属性の受動化状態を個別に設定するには:

1. 「アプリケーション」ウィンドウで、受動化の状態を指定する一時属性を含むビュー・オブジェクトをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで、受動化する一時属性を選択し、「詳細」タブをクリックします。

4. 「詳細」ページで、「受動化」チェック・ボックスを選択します。

56.8.4 一時ビュー・オブジェクトの受動化に関する必知事項

トランザクション機能はエンティティ・オブジェクト・レベルで管理されることが普通であるため、一時ビュー・オブジェクト属性の受動化はリソースやパフォーマンスの点で効率が低下します。一時ビュー・オブジェクトはエンティティ・オブジェクトに基づいていないため、すべての更新は、エンティティ・キャッシュではなく、ビュー・オブジェクト行キャッシュで管理されます。したがって、一時ビュー・オブジェクトまたは一時ビュー・オブジェクト属性を受動化するには、特別なランタイム処理が必要になります。

通常、受動化では変更された値のみを保存しますが、一時ビュー・オブジェクトの受動化では行全体を保存する必要があります。行には、受動化として設定されたビュー・オブジェクト属性のみが含まれます。

注意:

ADF受動化および能動化ロジックは、エンティティ・オブジェクトがポストされていない状態であるかぎりにおいてのみ、エンティティ・オブジェクトおよびビュー・オブジェクトの一時属性の回復を行います。ユーザーが変更をデータベースに保存すると、エンティティ・オブジェクトはデータベースにポストされ、次に能動化サイクルでデータベース・クエリを使用してビュー行が回復されます。属性は一時属性のため、その値はNULLのままです。エンティティ・オブジェクトまたはビュー・オブジェクトに基づく一時属性値がフェイルオーバー後も存続するようにするには、式を使用して一時属性を定義する必要があり、その式は値を指定できるgetterメソッドをポイントする必要があります。

56.8.5 一時ビュー・オブジェクトを使用してセッションレベルのグローバル変数を格納する方法

受動化を使用すると、ビュー・オブジェクトを使用して、1つまたは複数のグローバル変数を、それぞれ別の一時属性に格納することができます。一時属性を受動化済としてマークすると、ADFビジネス・コンポーネント・フレームワークでは、高スループットとフェイルオーバーを実現するシナリオで受動化と能動化が発生しても、その一時的な値が保持されます。このため、低効率のHTTPセッション・レプリケーションでなく、状態管理メカニズムによりバックアップされるセッション・レベルのグローバル値を実装するほうが簡単です。また、必要に応じてUIのコントロールにバインドすることも簡単になります。

様々な画面の起動方法において、値を保存するには2つの基本的な方法があります。1つはコントローラ中心、もう1つはモデル中心の方法です。

コントローラ中心の方法を使用してADFコントローラ・レイヤーにこのタスクを実装すると、ページ・フロー・スコープの属性を使用した値の保存および参照が行われます。この方法は、いずれかのADFビジネス・コンポーネントの実装によってグローバル値を内部で参照する必要がない場合に適しています。ページ・フロー・スコープの詳細は、「タスク・フローのメモリー・スコープに関する必知事項」を参照してください。

モデル中心の方法では、概念的にはOracle Formsの非データベース・ブロックと等しい一時ビュー・オブジェクトが作成されます。

始める前に:

ビュー・オブジェクトの受動化に関する知識が役立つ場合があります。詳細は、「受動化時のビュー・オブジェクトの状態の管理」を参照してください。

また、次のタスクを実行する必要があります。

1. JDeveloperでアプリケーションを開きます。

2. 「エンティティ・ベースのビュー・オブジェクトの作成方法」の説明に従い、ビュー・オブジェクト・ウィザードを使用して新規ビュー・オブジェクトを作成します。

a. ウィザードのページ1で、データソース: プログラム関連のオプションを選択します。

b. ページ2では、「新規」をクリックして一時属性名およびビューオブジェクトに含まれるタイプを定義します。

c. ページ3では、各属性の「更新可能」オプションを「常時」に設定します。

d. 「終了」をクリックすると、概要エディタに新規作成されたビュー・オブジェクトが表示されます。

3. 「既存のアプリケーション・モジュールへのマスター/ディテール・ビュー・オブジェクト・インスタンスの追加」に示すとおり、一時属性があるビュー・オブジェクトのインスタンスをアプリケーション・モジュールのデータ・モデルに追加します。

モデル中心の方法を使用してセッションレベルのグローバル変数を格納するには:

1. ビュー・オブジェクトでのエントリの実行を無効にします。

a. 概要エディタの「一般」ページで、「チューニング」セクションを開きます。

b. 「データベースから取得」グループで、行なしオプションを選択します。

2. ビュー・オブジェクトのデータがロールバック操作中にクリアされないよう注意してください。これを行うには、ビュー・オブジェクトのカスタムJavaクラスを有効にして、2つのロールバック・メソッドをオーバーライドします。

a. 概要エディタで「Java」ナビゲーション・タブをクリックし、「Javaクラス」セクションの「編集」アイコンをクリックします。

b. 「Javaオプションの選択」ダイアログで「ビュー・オブジェクト・クラスの生成」を選択して、「OK」をクリックします。

c. 概要エディタで、「Javaクラス」セクションの「ビュー・オブジェクト・クラス」の隣のリンクをクリックします。

d. メイン・メニューから、「ソース」→「メソッドのオーバーライド」を選択します。

e. 「メソッドのオーバーライド」ダイアログで、オーバーライドするbeforeRollback()メソッドおよびafterRollback()メソッドを選択し、次に「OK」をクリックします。

f. beforeRollback()メソッドおよびafterRollback()メソッドの両方で、Javaコードでsuperのコールをコメント・アウトします。

3. 新規ユーザーがアプリケーション・モジュールの使用を開始した場合は、ビュー・オブジェクトに空の行を作成します。

a. 「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。

b. 「アプリケーション・モジュールのカスタム・クラスの生成方法」の説明に従って、アプリケーション・モジュールのJavaクラスを作成します(存在しない場合)。

c. 「組込みフレームワーク・メソッドのオーバーライド方法」の説明に従って、アプリケーション・モジュールのprepareSession()メソッドをオーバーライドします。

d. super.prepareSession()をコールした後、新規行を一時ビュー・オブジェクトに作成するコードを追加し、これをビュー・オブジェクトに挿入します。

これで、「データ・コントロール」パネルを使用して、読取り専用要素および更新可能UI要素を、その他のビュー・オブジェクトと同様に、グローバルなビュー・オブジェクト属性にバインドできます。

57 アプリケーション・モジュール・プールのチューニング

この章では、ADFビジネス・コンポーネントのアプリケーション・モジュール・プールの動作方式と、アプリケーション・モジュール・プールをチューニングしてアプリケーションのパフォーマンスを最適化する方法について説明します。

この章の内容は次のとおりです。

- アプリケーション・モジュール・プールについて

- プール構成パラメータの設定

- データベースの状態の初期化とプーリングに関する考慮事項

57.1 アプリケーション・モジュール・プールについて

アプリケーション・モジュール・プールは、同じタイプのアプリケーション・モジュール・ランタイム・インスタンスのコレクションです。そこにアクセスするユーザー数をプロビジョニングするために、実行時に1つ以上のアプリケーション・モジュール・インスタンスをプールからサービス・ユーザーに提供するように、Fusion Webアプリケーションを構成できます。

プール内の各アプリケーション・モジュール・インスタンスは、複数のブラウザ・クライアントで共有されます。これらのクライアントの標準的な「思考時間」(Webページを送信する間隔)により、アプリケーション・モジュール・コンポーネントの数がシステムで作業しているアクティブ・ユーザーの総数よりも効果的に小さくなるように最適化されます。たとえば、20人のユーザーがそれぞれのブラウザからWebサイトにアクセスしている場合、これらのユーザーと同数のアプリケーション・モジュール・インスタンスではなく、5個または10個のアプリケーション・モジュール・インスタンスでサービスを提供できる可能性があります。つまり、プールは使用可能なアプリケーション・モジュールの数を上回るユーザーにサービスを提供できるだけでなく、この小さなアプリケーション・モジュールのセットへのサービス提供のために中間層が必要とするメモリーが少なくて済むので、ADFアプリケーションを、制限のあるハードウェア・リソース上でさらに拡大可能になります。

設計時の構成を通して、アプリケーション・モジュールを使用すると、完全にステートレスなFusion Webアプリケーションをサポートしたり、複数のブラウザ・ページにまたがる作業ユニットをサポートしたりできます。パフォーマンスを最適化するために、あるアプリケーション・モジュールのインスタンスが「状態管理」モードでプールに返された場合、プールは該当するアプリケーション・モジュールに対するセッション参照を追跡します。このアプリケーション・モジュールのインスタンスはそのままプールに残り、使用できる状態ですが、「セッション・アフィニティ」を維持することによりパフォーマンスが向上するため、前回このインスタンスを使用していたセッションによる使用が望ましいでしょう。

そのため、プール内のアプリケーション・モジュールのインスタンスはどの時点においても、その状態を反映して、次の3つのグループに論理的に分類されます。

- プールにチェックインされて、無条件に使用可能

- プールにチェックインされて使用可能だが、アクティブ・ユーザー・セッションによるセッション・アフィニティの再利用のため参照される

- プールからチェックアウトされ、かつ使用不可能。Webコンテナ内のなんらかのスレッドにより現在(まさにその瞬間に)使用されているため

アプリケーション・モジュール・プーリングを最大限に活用するには、背後で行われていることを理解しておく必要があります。アプリケーション・モジュールのセッション状態管理の詳細は、「受動化とアクティブ化が行われるタイミングの管理」を参照してください。

アプリケーション・モジュール・プールの動作に影響を与えるために設計時に設定できる構成パラメータの詳細は、「アプリケーション・モジュール・プールの構成パラメータに関する必知事項」を参照してください。

57.1.1 アプリケーション・モジュール・プール

アプリケーション・モジュール・コンポーネントは実行時、次の2つの方法で使用できます。

- クライアントから直接アクセスされるアプリケーション・モジュールとして使用する

- 別のアプリケーション・モジュール・インスタンスの中に集約(ネスト)されている再利用可能なコンポーネントとして使用する

クライアントがこれに直接アクセスするときのアプリケーション・モジュールはルート・アプリケーション・モジュールと呼ばれます。クライアントは、クライアントが含むアプリケーション・モジュール・インスタンスの一部として、ネストされているアプリケーション・モジュールに間接的にアクセスします。同一のアプリケーション・モジュールを実行時にこれら両方の方法で使用することも可能ですが、それは一般的ではありません。重要な点は、ADFビジネス・コンポーネントが作成するのは、ルート・アプリケーション・モジュールに対するアプリケーション・モジュール・プールのみであるということです。

基本的には、各Java VMのFusion Webアプリケーションにより使用されるルート・アプリケーション・モジュール1つにつき、アプリケーション・モジュール・プールが1つ作成されます。これらのJava VMでは、そのタイプのルート・アプリケーション・モジュールがADFコントローラ・レイヤーにより使用されます。アプリケーションが必要とするアプリケーション・モジュール・プールの数に関連する詳細トピックは、「デプロイメント環境のシナリオとプーリング」を参照してください。

57.1.2 デプロイメント環境のシナリオとプーリング

アプリケーションが利用するプールの数やプールの型は、ターゲット・プラットフォームの構成によって異なります。たとえば、アプリケーション・ユーザーのWebリクエストにサービスを提供するために利用できるJava仮想マシン(JVM)が複数あるかどうかや、Oracle WebLogic Serverドメインが複数あるかどうかで変わります。このアプリケーションにおいて、実行時のJVMが1つのシナリオと複数のシナリオで、どの種類のプールがいくつ作成されるのかを理解するために、次の想定を見直してみます。

- Fusion WebアプリケーションでHRModuleおよびPayablesModuleという2つのアプリケーション・モジュールを使用する。

- ユーザー・アプリケーション内で値リストをサポートするためによく使用される一連のビュー・オブジェクトがCommonLOVModuleに含まれており、HRModuleにもPayablesModuleにもよく使用されるLOVビュー・オブジェクトにアクセスするためにCommonLOVModuleのインスタンスがネストされている。

- HRModuleおよびPayablesModuleは、appuserという名前の同一のJDeveloper接続定義を使用するように構成済である。

57.1.2.1 Oracle WebLogic Serverドメインが1つ、Oracle WebLogic Serverインスタンスが1つ、JVMが1つの場合

Oracle WebLogic Serverインスタンスが1つという構成で、このアプリケーションを単一のOracle WebLogic Serverドメインにデプロイすると、アプリケーション・ユーザーからのWebリクエストにサービスを提供する場合に利用可能なJava VMは1つのみになります。

HRModuleおよびPayablesModuleにアクセスするWebページを全ユーザーが利用するものと仮定すると、次のようになります。

- HRModuleルート・アプリケーション・モジュール用のアプリケーション・モジュール・プールは1つ

- PayablesModuleルート・アプリケーション・モジュール用のアプリケーション・モジュール・プールは1つ

Java VMが1つであるこの場合は、全部でアプリケーション・モジュール・プールが2つになります。

注意:

再利用可能なCommonLOVModuleのネストされたインスタンスに対して、アプリケーション・モジュール・プールは存在しません。CommonLOVModuleのインスタンスは、HRModuleおよびPayablesModuleのインスタンスにより、それぞれのアプリケーション・モジュール・プール内でラップされます。

57.1.2.2 Oracle WebLogic Serverドメインが複数、Oracle WebLogic Serverインスタンスが複数、JVMが複数の場合

次は、Java VMが複数関与するデプロイ環境を考えてみます。フロントエンドとしてハードウェア・ロードバランサを設け、4台の異なる物理マシンを2つのOracle WebLogic Serverドメインとして構成してあるものとします。4台のマシン上で、各Oracle WebLogic Serverインスタンスがそれぞれ1つのJVMを持ちます。アプリケーションのユーザーがアプリケーションにアクセスすると、そのリクエストはこれら2つのOracle WebLogic Serverドメインによって共有され、各ドメインの中では該当するOracle WebLogic Serverインスタンスから利用可能な2つのJVMによって共有されます。

この場合も、HRModuleおよびPayablesModuleにアクセスするWebページを全ユーザーが利用するものと仮定すると、次のようになります。

- HRModuleのアプリケーション・モジュール・プールは4つ(4つの各JVMごとに1つ)
(1つのHRModuleルート・アプリケーション・モジュール)×(2つのOracle WebLogic Serverドメイン)×(各2つのOracle WebLogic Server JVM)

- PayablesModuleのアプリケーション・モジュール・プールは4つ(4つの各JVMごとに1つ)
(1つのPayablesModuleルート・アプリケーション・モジュール)×(2つのOracle WebLogic Serverドメイン)×(各2つのOracle WebLogic Server JVM)

この場合は、全部で8つのアプリケーション・モジュール・プールが4つのJVMに存在することになります。

「アプリケーション・モジュール・プールの構成パラメータに関する必知事項」でアプリケーション・モジュール・プールの構成パラメータをいろいろと確認する場合、それらのパラメータは1つのJVM内で指定した単一のアプリケーション・モジュールの特定の1つのアプリケーション・モジュール・プールに適用されることに注意してください。

ロード・バランシングによりユーザー・リクエストはOracle ADFが実行されている複数のJVMに分散されるため、各JVMにある個々のアプリケーション・モジュール・プールは、ユーザー負荷のn分の1をサポートする必要があります。ここで、nには、ユーザー・リクエストへのサービス提供に使用できるJVMの数です。Java VMの数を念頭に置いて、アプリケーション・モジュール・プールの適切な値を設定する必要があります。基本的には、負荷テストとアプリケーション・モジュール・プーリング統計の結果をサイズに関するパラメータの基準とし、次にその合計をプール数nで割ります。この数は、アプリケーション・サーバー・ドメインとOracle WebLogic Serverインスタンスの使用状況に基づいて決定されます。たとえば、1つのプールにあるアプリケーション・モジュール数の最小値を10に設定しようと決めたが、このアプリケーションにサービスを提供しているOracle WebLogic Serverインスタンスが5つあるため最終的なプール数は5になったという場合、このパラメータは10 (1つのJVMにある指定されたアプリケーション・モジュールのみにサービスを提供)ではなく2 (10を5で割った商)に設定します。

使用可能なサイズ指定に関するパラメータの詳細は、「プールのサイズ指定に関するパラメータ」を参照してください。

57.2 プール構成パラメータの設定

アプリケーション・モジュール・プールの実行時動作は、適切な構成パラメータの設定により制御します。それらのパラメータは、アプリケーション・モジュールの構成で宣言的な設定を行ったり、Java Systemパラメータとして指定したり、または実行時にプログラムで設定したりできます。

57.2.1 構成プロパティの宣言的設定方法

個々のアプリケーション・モジュールの実行時構成プロパティを表示および設定するには、アプリケーション・モジュール構成の概要エディタの「データベースとスケーラビリティ」タブを使用します(図57-1)。

図57-1 「構成の編集」ダイアログの「データベースとスケーラビリティ」タブ

始める前に:

アプリケーション・モジュール・プーリングの知識があると役立ちます。詳細は、「プール構成パラメータの設定」を参照してください。

アプリケーション・モジュールの構成パラメータについて理解します。アプリケーション・モジュール・プールのチューニング用の構成パラメータの詳細は、「アプリケーション・モジュール・プールの構成パラメータに関する必知事項」を参照してください。

予測されるレベルの使用量に関して、Fusion Webアプリケーションのチューニングに役立つベスト・プラクティス・ガイドラインは、『パフォーマンスのチューニング・ガイド』の「Oracle Application Development Frameworkのチューニング」を参照してください。

アプリケーションでJDBC URL接続タイプ(レガシーのみ)を定義する場合、このガイドの11g リリース・バージョンを参照して、ADFデータベース接続プールの構成パラメータに関するドキュメントを取得してください。

アプリケーション・モジュールのプーリング構成を編集するには:

1. 「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。

2. 概要エディタで、「構成」ナビゲーション・タブをクリックします。

3. 「構成」ページで、編集する構成の構成ハイパーリンクをクリックします。

4. アプリケーション・モジュール構成の概要エディタで、「データベースとスケーラビリティ」タブをクリックして必要な実行時プロパティを編集し、「OK」をクリックして構成の変更内容を保存します。

57.2.2 構成プロパティを宣言的に設定した場合の処理

アプリケーション・モジュール構成の概要エディタで指定した値は、アプリケーション・モジュールのXML定義を基準とする./commonサブディレクトリ内のbc4j.xcfgというXMLファイルに保存されます。同一のJavaパッケージ内の全アプリケーション・モジュールの構成はすべて、この同じファイルに保存されます。通常は、bc4j.xcfgファイルを直接変更するのではなく、概要エディタを使用して特定のアプリケーション・モジュールの構成の設定を変更します。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。

たとえば、SummitADFアプリケーションに含まれるBackOfficeAppModuleアプリケーション・モジュールのアプリケーション・モジュール構成(./src/oracle/summit/model/services/commonディレクトリ内のbc4j.xcfgファイル)の概要エディタを見ると、BackOfficeAppModuleアプリケーション・モジュール用の2つの名前付き構成が含まれています。この場合、次の例のようにBackOfficeAppModuleLocal構成とBackOfficeAppModuleShared構成は、Oracle ADFモデル・テスターがJDBC URL接続を使用するように指定しています。JDBC接続の接続詳細は、プロジェクト・ディレクトリとの相対位置指定で./.adf/META-INFと記述されるサブディレクトリにあるconnections.xmlファイルにあります。

<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>

ここで、<AppModuleConfig>タグの子要素の属性にはjboで始まる名前が付けられています。これは、そのADFビジネス・コンポーネント・プロパティの名前と一致しています(たとえば、<AM-Pooling>タグは、プロパティjbo.ampool.maxpoolsizeに対応する属性jbo.ampool.maxpoolsizeを定義します)。また、アプリケーション・モジュール構成エディタで、あるプロパティが実行時のデフォルト値に設定されている場合、JDeveloperはこのエントリをbc4j.xcfgファイルに書き込まないことを理解しておくことも重要です。

57.2.3 構成プロパティをプログラム的に設定する方法

実行時にアプリケーションによってアプリケーション・モジュール構成プロパティを制御する必要がある場合は、ADFビジネス・コンポーネントAPIを使用してこれらのプロパティを動的に設定できます。たとえば、一般的なADFアプリケーションでは、アプリケーション・モジュールによって静的なJDBCデータソースが構成されます。しかし、アプリケーションで、ユーザーに応じて様々なデータベースからデータを表示する必要がある場合、データソース名とアプリケーション・モジュール・プールのパラメータを実行時に設定することがあります。

oracle.jbo.common.ampoolパッケージにEnvInfoProviderインタフェースを実装するJavaクラスを作成すると、構成プロパティをプログラムによって設定できます。クラス内では、次の例に示すように、getInfo()メソッドをオーバーライドしてput()をコールし、渡される環境ハッシュ表に値を格納します。

package devguide.advanced.customenv.view;
import java.util.Hashtable;
import oracle.jbo.common.ampool.EnvInfoProvider;
/**
* Custom EnvInfoProvider implementation to set
* environment properties programmatically
*/
public class CustomEnvInfoProvider implements EnvInfoProvider {
/**
* Overridden framework method to set custom values in the
* environment hashtable.
*
* @param string - ignore
* @param environment Hashtable of config parameters
* @return null - not used
*/
public Object getInfo(String string, Object environment) {
Hashtable envHashtable = (Hashtable)environment;
envHashtable.put("some.property.name","some value");
return null;
}
/* Required to implement EnvInfoProvider */
public void modifyInitialContext(Object object) {}
/* Required to implement EnvInfoProvider */
public int getNumOfRetries() {return 0;}
}

ConfigurationクラスのcreateRootApplicationModule()メソッドを使用してステートレスなクライアントまたはコマンド行クライアント用のアプリケーション・モジュールを作成する場合は、カスタムなEnvInfoProviderを第2引数(オプション)として渡すことができます。カスタムなEnvInfoProviderをADF Webベース・アプリケーションで使用するには、次の例で示すように、セッションCookieファクトリのカスタム・クラスを実装する必要があります。カスタムなセッションCookieファクトリを使用するには、構成プロパティjbo.ampool.sessioncookiefactoryclassに、セッションCookieファクトリのカスタム・クラスの完全修飾名を設定します。

package devguide.advanced.customenv.view;
import java.util.Properties;
import oracle.jbo.common.ampool.ApplicationPool;
import oracle.jbo.common.ampool.EnvInfoProvider;
import oracle.jbo.common.ampool.SessionCookie;
import oracle.jbo.http.HttpSessionCookieFactory;
/**
* Example of custom http session cookie factory
* to install a custom EnvInfoProvider implementation
* for an ADF web-based application.
*/
public class CustomHttpSessionCookieFactory
extends HttpSessionCookieFactory {
public SessionCookie createSessionCookie(String appId,
String sessionId,
ApplicationPool pool,
Properties props) {
SessionCookie cookie =
super.createSessionCookie(appId, sessionId,pool, props);
EnvInfoProvider envInfoProv = new CustomEnvInfoProvider();
cookie.setEnvInfoProvider(envInfoProv);
return cookie;
}
}

57.2.4 構成プロパティのスコープに関する必知事項

ADFビジネス・コンポーネントが使用する各ランタイム構成プロパティには、スコープが1つあります。各プロパティのスコープは、該当するプロパティ値が評価されるタイミングと、その値が単一のJava VM内で効果的に共有される(すなわち静的である)か否かを示します。ADFビジネス・コンポーネントのPropertyManagerクラスは、サポートされているすべてのプロパティから構成されるレジストリです。定義されるのは、プロパティの名前、デフォルト値およびスコープです。このクラスにはmain()メソッドが含まれているので、該当クラスをコマンド行から実行して、全構成プロパティ情報のリストを表示できます。

JDEVHOMEがJDeveloperのインストール・ディレクトリである場合、この一連の設定値のリストを表示するには、次のコマンドを実行します。

$ java -cp JDEVHOME/BC4J/lib/bc4jmt.jar oracle.jbo.common.PropertyManager

このコマンドを発行すると、ADFビジネス・コンポーネントの構成プロパティがすべてコンソールに送られます。また、構成プロパティ値を設定できる様々なレベルおよびそれらのレベルの優先度を示す便利な参考情報もリスト表示されます。

---------------------------------------------------------------
Properties loaded from following sources, in order:
1. Client environment [Provided programmatically
or declaratively in bc4j.xcfg]
2. Applet tags
3. -D flags (appear in System.properties)
4. bc4j.properties file (in current directory)
5. /oracle/jbo/BC4J.properties resource
6. /oracle/jbo/commom.jboserver.properties resource
7. /oracle/jbo/common.Diagnostic.properties resource
8. System defined default
---------------------------------------------------------------

どのプロパティも、次のいずれか1つのスコープとともにリスト表示されます。

- MetaObjectManager
このスコープのプロパティは、ADF PropertyManagerが初めて初期化される際、Java VMごとに一度初期化されます。

- SessionImpl
このスコープのプロパティは、ApplicationModule.prepareSession()が起動されるたびに一度初期化されます。

- Configuration
このスコープのプロパティは、アプリケーション・モジュール・プールが初めて作成され、該当するアプリケーション・モジュールの構成が初めて読み込まれるときに初期化されます。

- Diagnostic
このスコープのプロパティは、ADFビジネス・コンポーネントの組込み診断機能に固有なものです。

これらのどのスコープでも、一連のプロパティが初期化される際に、前述のレイヤー化された値の解決が実行されます。クライアント環境(解決順序のレベル1)でプロパティ値が指定されていれば、これらが初期化されたときには必ず、システム・パラメータ(解決順序レベル3)に指定された値よりも優先されます。

クライアント環境は、プログラムで移入できるか、ロード時にConfigurationオブジェクトによって自動的に移入される名前/値ペアのハッシュ表であり、bc4j.xcfgファイルのエントリにその名前/値ペアが含まれます。つまり、MetaObjectManagerレベルでスコープの対象となるプロパティの場合は、次の両方の処理を実行するのが、該当する一連のプロパティに対し全アプリケーション・モジュールで同じデフォルト値を確実に使用するための最も信頼性の高い方法です。

1. 該当するプロパティ値が、どのアプリケーション・モジュールのbc4j.xcfgファイルの構成名/値のペア・エントリにも表示されないようにする。

2. 実行環境内のJavaシステム・プロパティを使用してプロパティ値を設定する。

そのかわり、もし、MetaObjectManagerスコープのプロパティをbc4j.xcfgファイルに残した場合、Java VMの起動後にプールが作成される最初のアプリケーション・モジュールの構成に指定された値に対して望ましくない処理が行われます。

57.2.5 アプリケーション・モジュール・プールの構成パラメータに関する必知事項

アプリケーション・モジュール・プールの構成パラメータは、プールの動作、プールのサイズ指定およびプールのクリーンアップ動作に関連する3つの論理的カテゴリに分類されています。デフォルトでは、Fusion Webアプリケーションにより、アプリケーション・モジュール・プーリングが有効になります。

57.2.5.1 プールの動作に関するパラメータ

アプリケーション・モジュールは、アプリケーション・モジュール・プールの動作に影響を与える構成パラメータを定義し、インスタンスがアプリケーション・モジュール・プールから削除された後、アプリケーション・モジュール・インスタンスが、接続プールから取得するJDBC接続を保持するかどうかを定義します。

ADFアプリケーション・モジュール・プールがデータベース接続プールを使用する方法は、「解放時にアプリケーション・モジュールの切断」の構成パラメータjbo.doconnectionpoolingの設定によって異なります。図57-1に示すように、デフォルトでは設定は無効であり、パラメータの設定はjbo.doconnectionpooling=falseになっています。

。

注意:

jbo.doconnectionpooling=falseと設定しても、データベース接続プーリングが実行されないわけではありません。これは、アプリケーション・モジュール・プールに戻されるときのチェックインの際、アプリケーション・モジュールがそのJDBC接続から切断されないという意味です。

アプリケーション・モジュール・インスタンスをアプリケーション・モジュール・プールで作成すると、JDBC接続が取得されます。デフォルトでは、1人のユーザーのリクエスト全体にわたって、ADFは同じアプリケーション・モジュール・インスタンス(その関連するメモリーとJDBC接続および状態を含む)を試して再利用するようにセッション・アフィニティの維持を優先します。目的はこのようなユーザーのパフォーマンス速度の向上です。jbo.doconnectionpooling=falseのデフォルト設定によってこの動作が有効になり、アプリケーション・モジュール・インスタンスは、クライアントによる以降のリクエスト全体にわたって、そのJDBC PreparedStatementオブジェクトのキャッシュ化と再利用を維持できます。

ただし、Fusion Webアプリケーションにアクセスするユーザー数が増加するにつれて、JDBC接続、PREPARE文および結果セットを保持するサーバーへのメモリー要求が増します。数千のユーザーに対応するようにアプリケーション・モジュール・プールを構成する場合、各リクエスト後にJDBC接続を解放しないと、サポートされる管理対象ユーザー・セッションの一部を含め、サーバー負荷が高まる可能性があります。この状況は、Oracle Database 10g以降のOracle JDBCドライバと同様に、メモリー消費を超えてパフォーマンスを最適化するデータベース・ドライバを使用するように構成されるデプロイメント環境で特に顕著です。

JDBCドライバによってサーバー・メモリーがすぐに消費される状況を回避するには、jbo.doconnectionpooling=trueを設定してアプリケーション・モジュール・インスタンス接続のデフォルト動作をオーバーライドできます。ユーザー・セッションがアプリケーション・モジュールの使用を終える(通常は各HTTPリクエストの終了時)たびに、アプリケーション・モジュール・インスタンスが、該当するリクエストで使用していたJDBC接続との関係を断ち、その接続をJDBC接続プールに返します。該当するアプリケーション・モジュール・インスタンスは、ユーザー・セッションによって次回使用されるとき、JDBC接続プールからJDBC接続を再度取得し、該当するアプリケーション・モジュールがアプリケーション・モジュール・プールからチェックアウトされている期間(この場合も、通常は1つのHTTPリクエストの期間)、そのJDBC接続を使用します。アプリケーション・モジュール・インスタンス自体で、PreparedStatementの作成に使用されたJDBC接続オブジェクトを切断するため、この状況では、アプリケーション・モジュールがプールからチェックアウトされるたびにprepareSession()メソッドが起動され、データベース状態を初期化しなおすことができます。そのため、JDBC接続の解放をセッションに対して有効にする場合は、データベース接続の総数が少なくなるかわりに、JDBCを毎回セットアップするオーバーヘッドが少し増えます。

アプリケーション接続のために、基礎となる同一のデータベース・ユーザーを多数のアプリケーション・モジュール・プールがすべて使用する場合、違いが顕著になります。

- 50個の異なるアプリケーション・モジュール・プールがそれぞれアプリケーション・モジュール・インスタンスを内部に1つだけ持つ場合、jbo.doconnectionpooling=falseという条件では、50個のJDBCアプリケーション接続が使用されます。「最小使用可能サイズ」の構成パラメータjbo.ampool.minavailablesize=0を設定し、適切なインスタンス・アイドル・タイムアウトが経過した後にアプリケーション・モジュール・プールを0インスタンスまで減らせるようにアプリケーション・モジュール・プーリングのサイズ・パラメータを設定すると、アプリケーション・モジュールは保持していた接続をそのプールから削除されるときに元に戻します。この状況は、管理対象アプリケーション・モジュール・インスタンスの数が少ないままの場合、ピーク需要時以外、または少数の同時ユーザーをアプリケーションがサポートする必要がある場合に最適です。

- 対照的に、50個の異なるアプリケーション・モジュール・プールがそれぞれ1つのアプリケーション・モジュール・インスタンスを持ち、jbo.doconnectionpooling=trueであった場合、使用中のJDBC接続の数は、これらのアプリケーション・モジュールのうち、異なるクライアントにより同時に使用されているものの数によって変わります。アプリケーション・モジュール・インスタンスは、プール内にあってユーザー・セッションにより使用されていない場合、jbo.doconnectionpooling=trueという条件があるため、そのJDBC接続を接続プールに解放します。そのアプリケーション・モジュール・インスタンスは、別のユーザーによって再度必要とされるかアプリケーション・モジュール・プール・モニターによって最終的にクリーンアップされるまでプール内で待機している間、JDBC接続には接続されていません。この状況は、ピーク需要時または同時ユーザー数の増加が予測される場合にFusion Webアプリケーションのスケーラビリティを確保する際に最適です。

jbo.doconnectionpoolingをtrueに設定すると、「Transaction Disconnect Level」の構成パラメータjbo.txn.disconnect_levelのデフォルト設定1により、対応するJDBC接続への参照がドロップされた後でも、アプリケーション・モジュール、ビュー・オブジェクトおよび行セットをすべてメモリーに残し、有効のままにできます。この構成により、通常は解放時にアプリケーション・モジュールの受動化が実行される、この状況に関連するメモリー要件が軽減されます。かわりに、アクティブ化されるときに、このフレームワークで必要になるのは、カーソル位置の再実行と同期のみです。

あるいは、JDBC接続を保持することと、接続したままにすることのバランスをとるには、「接続しきい値」の構成パラメータjbo.ampool.connection_thresholdを構成します。このパラメータは、結合されたすべてのアプリケーション・モジュール・プール内のアプリケーション・モジュールが、アプリケーション・モジュール・プールのクリーンアップ時に保持する(解放して接続プールに戻さない)最大接続数を指定します。jbo.ampool.connection_thresholdパラメータを最大接続数(0よりも大きな値)に設定した場合、プールのクリーンアップ時にはアプリケーション・モジュールを切断するのが望ましいことを暗黙的に示したことになるため、構成パラメータjbo.doconnectionpoolingを有効にしないようにする必要があることに注意してください。jbo.ampool.connection_thresholdパラメータがアプリケーション・モジュール・プーリングにどのような影響を及ぼすかの詳細は、「アプリケーション・モジュール・プーリングの最適化に関する必知事項」を参照してください。

57.2.5.2 プールのサイズ指定に関するパラメータ

アプリケーション・モジュールでは、アプリケーション・モジュール・プールのサイズ指定に影響を与える構成パラメータを定義します。プール・モニターがそのリソース・クリーンアップ・パスのいずれかを実行する場合、アプリケーション・モジュール・インスタンスの数を、使用可能な最大および最小サイズ・パラメータで指定する範囲に送ろうとします。

プール・モニターが、未使用でアイドル状態のアプリケーション・モジュール・インスタンスを削除することで最大サイズを下回るようにプール・サイズを減らすことができない場合、タイムアウトしていないアクティブ・インスタンスを削除して、これらのアクティブ・アプリケーション・モジュールの状態を受動化します。「参照プール・サイズ」の構成パラメータjbo.recyclethresholdでは、受動化が行われるときにプール・モニターに残るアクティブ・アプリケーション・モジュールの数を決定します。デフォルトでは、プール・モニターが受動化を開始するときのしきい値は、10アプリケーション・モジュール・インスタンスです。

「最大使用可能プール・サイズ」の構成パラメータjbo.ampool.maxavailablesizeを使用して、プール・モニターによるリソースのクリーンアップ後、プール・サイズの上限範囲を指定できます。通常、同時ユーザー数に基づくデフォルトの最大使用可能サイズ25と、ユーザーがアプリケーション・モジュールのサービスにアクセスする必要がある頻度をオーバーライドします。ただし、サーバー・メモリーがアプリケーション・パフォーマンスの制限要因ではない場合、最大使用可能サイズを任意の大きな値に設定して、アクティブなユーザー・セッションに引き続き結び付けられているアプリケーション・モジュール・インスタンスの受動化とアクティブ化の影響を最小限に抑えることができます。

注意:

未使用のアプリケーション・モジュール・インスタンスを再生せず、通常のHTTPセッション・タイムアウトのアイドル時間を30分にするようにプールのクリーンアップを構成する場合、プール・サイズに十分大きな値を指定することが特に重要です。プールのクリーンアップの構成の詳細は、「プールの動作に関するパラメータ」を参照してください。

同様に、使用可能なアプリケーション・モジュール・インスタンスのベースラインを確保する場合にデフォルトの5インスタンスでは足りない場合、「最小使用可能プール・サイズ」の構成パラメータjbo.ampool.minavailablesizeを使用して、プール・サイズの下限範囲を指定できます。通常、ピーク使用時以外は、この値を同時ユーザー数と同じになるように設定してください。この値の設定が低すぎると、パフォーマンスに影響を与える可能性があるアプリケーション・モジュール・インスタンスの不要なインスタンス化が行われます。

57.2.5.3 プールのクリーンアップに関するパラメータ

アプリケーション・モジュールは、プール・モニターがそのリソース・クリーンアップ・パスのいずれかを実行するときに、リソースの再生処理に影響を与える構成パラメータを定義します。

Java VMごとに1つのアプリケーション・モジュール・プール・モニターがバックグラウンド・スレッドで実行し、プールのスキャンを起動して、デフォルトで600000ミリ秒(10分)間隔のクリーンアップを実行します。デフォルトのプール・ポーリング間隔を変更するには、「プール・ポーリング間隔」のパラメータjbo.ampool.monitorsleepintervalを構成できます。

プール・モニターは次の2つの独立した戦略を使用して、どのアプリケーション・モジュール・インスタンスをプールから削除し、使用可能な新しいリソースとして解放可能かを判断します。

1. アプリケーション・モジュール・プール・モニターは、3600000ミリ秒(1時間、デフォルト値)を超える期間使用されていなかったアプリケーション・モジュール・インスタンスをプールから削除します。これらの未使用のアプリケーション・モジュール・インスタンスは、プールに構成された最小使用可能サイズにかかわらず再生されます。アプリケーション・モジュールに対する最長有効期間をオーバーライドするには、「最長有効期間」の構成パラメータjbo.ampool.timetoliveを設定できます。ただし、ほとんどのFusion Webアプリケーションでは未使用のアプリケーション・モジュール・インスタンスを解放する必要はないため、このパラメータ値を-1に設定できます。

2. アプリケーション・モジュール・プール・モニターは、600000ミリ秒(10分、デフォルト値)を超える期間アイドル状態であったアプリケーション・モジュール・インスタンスをプールから削除します。このクリーンアップは、プール内のインスタンス数が、使用可能な最小サイズに達すると停止します。10分を超えるアイドル・ユーザー・セッションを許可する場合、「アイドル・インスタンス・タイムアウト」の構成パラメータjbo.ampool.maxinactiveageを使用して、アプリケーション・モジュール・インスタンスのアイドル・タイムアウトをオーバーライドできます。

ベスト・プラクティス

アプリケーション・モジュール・プールのクリーンアップ・パスの時間間隔を指定するときに、すべてのアプリケーション・モジュールで「プール・ポーリング間隔」の構成パラメータjbo.ampool.monitorsleepintervalの値を同じに設定します。Java VM 1つにつきアプリケーション・モニターのプール・モニターは1つしかありませんので、アプリケーション・モジュール・プール・モニターのポーリング間隔として効果的に使用される値は、アプリケーション・モジュール構成内にあり、作成される最初のアプリケーション・モジュール・プールにより読取られる値です。すべてのアプリケーション・モジュールで同じ値が使用されるように設定すると、この値が予想可能な方法で確実に設定されます。

57.2.6 アプリケーション・モジュール・プーリングの最適化に関する必知事項

JDBC接続を保持することと、接続したままにすることのバランスをとるには、「接続しきい値」の構成パラメータjbo.ampool.connection_thresholdを構成します。このパラメータは、結合されたすべてのアプリケーション・モジュール・プール内のアプリケーション・モジュールがプールの次のクリーンアップ・サイクル時に保持する(解放して接続プールに戻さない)最大接続数を指定します。

接続しきい値のパラメータjbo.ampool.connection_thresholdを有効にする場合(0よりも大きな値)、アプリケーション・モジュール接続は、チェックイン時ではなく、プールのクリーンアップ時に解放されます。クリーンアップ・モニターは、JDBC接続数の合計数が指定のしきい値を下回るまで最後に使用されたアプリケーション・モジュールを切断しようと最善の努力をします。jbo.ampool.connection_thresholdパラメータを有効にすると、アプリケーション・モジュール・プールのクリーンアップの実行タイミングが変わるため、これは、jbo.ampool.connection_threshold=trueパラメータの設定に互換性がないことを表します。

注意:

プールのクリーンアップ・サイクルでアプリケーション・モジュールを切断するためのしきい値を構成する場合、値がfalse (デフォルト)になるように必ずjbo.doconnectionpoolingを無効にしてください。接続しきい値パラメータは、設定jbo.doconnectionpooling=trueと互換性がありません。これは、この設定により、アプリケーション・モジュールのチェックイン時にJDBC接続が解放されて接続プールに戻され、かつ、この設定をjbo.txn.disconnect_levelパラメータと組み合せて使用すると、ビジネス・コンポーネントがメモリーに残るようになるためです。jbo.doconnectionpoolingパラメータの詳細は、「プールの動作に関するパラメータ」を参照してください。

たとえば、2つのアプリケーション・モジュール・プールの接続しきい値パラメータを10に設定するとします。この場合、アプリケーション・モジュール・プール1には7つのアプリケーション・モジュールがあり、プール2には8つのアプリケーション・モジュールがあるため、JDBC接続の合計は15になります。アプリケーション・モジュール・プールのクリーンアップ・モニターが実行すると、モニターは、5つの接続(15の接続リソース - 接続しきい値10)を再生するように最大限の努力をします。モニターは、各プールの接続済アプリケーション・モジュールの総数に比例してアプリケーション・モジュールを切断します。この場合、各プールのアプリケーション・モジュール接続の1/3 (5/15)が切断されます。そのため、プール1は2つの接続(7/3)を解放し、プール2は3つの接続(8/3)を解放します。この場合、プール・サイズの小数は切り上げられます。

クリーンアップ・モニターは、接続済リソースの数が指定の制限値を下回るまでアプリケーション・モジュールを切断する最大限の努力をしますが、使用可能な状態でアプリケーション・モジュールが十分にない場合、それを実行できないことに注意してください。JDBC接続が効率的に解放されるようにするために、「プール・ポーリング間隔」のパラメータjbo.ampool.monitorsleepintervalを構成してモニターのスリープ時間を短縮できます。

57.3 データベースの状態の初期化とプーリングに関する考慮事項

現在のユーザー・セッションに関連するデータベース状態を初期化するために、ストアド・プロシージャの起動が必要な場合もあります。その初期化を実行するには、アプリケーション・モジュールのprepareSession()メソッドをオーバーライドして行うのが正しい方法です。

57.3.1 ユーザー単位でのデータベース状態の設定方法

Fusion Webアプリケーションでは、ユーザーごとにデータベース状態を設定できます。通常は、データベースCONTEXTネームスペースを作成し、PL/SQLプロシージャをそれに関連付け、SYS_CONTEXT() SQL関数を使用してコンテキストから値を参照します。

たとえば、次の例に示すように、PL/SQLパッケージを使用して、現在認証されているFusion Webアプリケーション・ユーザーの名前を保持する変数をパッケージ・レベルで設定および取得できます。

create or replace package context_pkg as
procedure set_app_user_name(username varchar2);
function app_user_name return varchar2;
end context_pkg;

その後、このアプリケーションはビュー・オブジェクトのWHERE句を定義し、context_pkg.app_user_name関数を参照して、ユーザーごとに状態を問い合せることができます。

データベース状態を設定するには、「IN引数のみのストアド・プロシージャの呼出し方法」に示したものによく似たcallStoredProcedure()ヘルパー・メソッドをアプリケーション・モジュール・フレームワーク拡張クラス(AppModuleImpl.java)に定義します。その後、カスタム・アプリケーション・モジュール・クラスは、このフレームワーク拡張クラスを拡張し、次の例に示すsetCurrentUserInPLSQLPackage()ヘルパー・メソッドを定義します。このヘルパー・メソッドはcallStoredProcedure()メソッドを使用して、context_pkg.set_app_user_name()ストアド・プロシージャを呼び出し、パラメータ値として、現在認証されているユーザーの値を渡します。

// In CustomAppModuleImpl.java
public void setCurrentUserInPLSQLPackage() {
String user = getUserPrincipalName();
callStoredProcedure("context_pkg.set_app_user_name(?)",new Object[]{user});
}

このヘルパー・メソッドを使用し、カスタム・アプリケーション・モジュール・クラスは、次の例に示すように、prepareSession()メソッドをオーバーライドします。

// In CustomAppModuleImpl.java
protected void prepareSession(Session session) {
super.prepareSession(session);
getLoggedInUser().retrieveUserInfoForAuthenticatedUser();
setUserIdIntoUserDataHashtable();
setCurrentUserInPLSQLPackage();
}

付録

ここでは、Oracle ADFを使用してFusion Webアプリケーションを構築するときに開発者が認識している必要がある情報を提供します。

特に、次の付録が含まれます。

- ADF XMLファイル

- ADFバインディング・プロパティ

- ADFセキュリティ権限の付与

- ADFビジネス・コンポーネントのよく使用されるメソッド

- ADFビジネス・コンポーネントJava EEデザイン・パターン・カタログ

- 一般的なOracle Formsのトリガーに相当するADFの機能

- Oracle ADFでの一般的なOracle Formsのタスクの実行

- GlassFishへのADFアプリケーションのデプロイ

A Oracle ADF XMLファイル

この付録は、データ・モデル・プロジェクトとユーザー・インタフェース・プロジェクトで作成されるOracle ADFメタデータ・ファイルのリファレンスです。この情報は、これらのファイルに定義されたメタデータの内容を編集する場合に使用できます。

この付録の内容は次のとおりです。

- ADFメタデータ・ファイルについて

- ADFファイルの概要図

- ADFファイルの構文図

- adfm.xml

- modelProjectName.jpx

- bc4j.xcfg

- DataBindings.cpx

- pageNamePageDef.xml

- adfc-config.xml

- task-flow-definition.xml

- adf-config.xml

- adf-settings.xml

- web.xml

- logging.xml

A.1 ADFメタデータ・ファイルについて

Fusion Webアプリケーションのメタデータ・ファイルは、アプリケーションによって使用される構造化XMLファイルです。次の目的で使用されます。

- アプリケーションのOracle ADFデータ・コントロールで使用できるパラメータ、メソッドおよび戻り値を指定します。

- Oracle ADFバインディング・コンテキストのオブジェクトを作成し、それらのオブジェクトの実行時動作を定義します。

- JSFおよびADF FacesのUIコンポーネントに関する構成情報を定義します。

- Java EEアプリケーション・サーバーのアプリケーション構成情報を定義します。

ADFバインディングの場合、バインディング固有のエディタを使用して、バインディング・オブジェクトの実行時プロパティをカスタマイズできます。バインディング固有のエディタを開くには、ページ定義ファイルの「構造」ウィンドウを表示して、ポップアップ・メニューから「プロパティに移動」を選択します。

また、JDeveloperのXMLエディタでは、任意のメタデータ・ファイルの内容を参照および編集できます。これらのファイルを操作する最も簡単な方法は、「構造」ウィンドウと「プロパティ」ウィンドウを使用することです。「構造」ウィンドウで要素を選択し、「プロパティ」ウィンドウで(通常はドロップダウン・メニュー・オプションを選択して)その要素の属性値を定義します。この付録を使用して、Oracle ADF固有の要素の場合に選択できるオプションについて学習してください。

A.2 ADFファイルの概要図

Oracle ADFメタデータ・ファイル間の関係により、モデル・データ・プロジェクトとユーザー・インタフェース・プロジェクト間の依存性が定義されます。これらの依存性は、各ファイルのXML要素内のファイル参照として定義されます。

図A-1は、ADFビジネス・コンポーネント・アプリケーション・モジュールをJSF Webページに対するサービス・インタフェースとして使用しているFusion Webアプリケーションで操作する可能性のあるXMLメタデータ・ファイルの階層構造を示しています。

図A-1 Fusion WebアプリケーションにおけるOracle ADFファイル階層の概要

A.2.1 Oracle ADFデータ・コントロール・ファイル

ADFビジネス・コンポーネントを含むFusion Webアプリケーションの場合、データ・コントロール実装ファイルはアプリケーションに含まれます。データ・コントロール用の参照は、アプリケーション・モジュールおよびビュー・オブジェクトXMLコンポーネントのディスクリプタ・ファイルによって提供されます。これらのファイルはbc4j.xcfgファイルとともに、データ・コントロールに必要な情報を提供します。

1つのプロジェクトでADFビジネス・コンポーネントを使用し、別のプロジェクトでADFビジネス・コンポーネント以外のデータ・コントロールを使用するアプリケーションは、DataControls.dcxファイルと、サポート用の<sessionbeanname>.xmlファイルおよび<beanname>.xmlファイルを持つ場合があります。

A.2.2 Oracle ADFデータ・バインディング・ファイル

Fusion Webアプリケーションの標準的な次のXML構成ファイルは、ユーザー・インタフェース・プロジェクトに表示されます。

- adfm.xml: このファイルには、現在のプロジェクトで利用できるDataBindings.cpxファイルがリストされます。
詳細は、「adfm.xml」を参照してください。

- DataBindings.cpx: このファイルには、ページ・マップ、ページ定義参照およびデータ・コントロール参照が含まれます。このファイルは、(「構造」ウィンドウまたは「データ・コントロール」パネルで)UIコンポーネントのデータ・バインディングを最初に作成したときに作成されます。DataBindings.cpxファイルでは、アプリケーション全体のOracle ADFバインディング・コンテキストを定義します。バインディング・コンテキストは、アプリケーション全体にわたるバインディングおよびデータ・コントロールへのアクセスを提供します。DataBindings.cpxファイルには、各WebページのOracle ADFバインディングのメタデータを定義する<pagename>PageDef.xmlファイルへの参照も含まれます。
詳細は、「DataBindings.cpx」を参照してください。

- <pagename>PageDef.xml: ページ定義XMLファイルです。これにより、WebページのUIコンポーネントがデータまたはデータ・コントロールと関連付けられます。ユーザーが「データ・コントロール」パネルまたは「構造」ウィンドウを使用して、新しいWebページを設計するたびに、JDeveloperによりこのファイルが作成されます。これらのXMLファイルには、WebページのUIコンポーネントにデータを移入するバインディングを作成するためのメタデータが含まれます。ADFバインディングを参照するすべてのWebページに対して、バインディング定義を含む専用のページ定義ファイルが必要です。
詳細は、「pageNamePageDef.xml」を参照してください。

A.2.3 Web構成ファイル

JSFアプリケーションに必要とされる次の標準XML構成ファイルは、ユーザー・インタフェース・プロジェクトに表示されます。

- web.xml: アプリケーション構成の一部は、Java EEアプリケーション・デプロイメント・ディスクリプタのweb.xmlの内容によって決定されます。web.xmlファイルでは、サーバーが認識する必要のあるアプリケーションのすべての設定を定義します。このファイルで、ADFBindingFilterを設定してOracle ADFデータ・バインディングを構成します。追加の実行時設定には、サーブレットの実行時パラメータと初期化パラメータ、カスタム・タグ・ライブラリの場所、およびセキュリティ設定が含まれます。
ADFデータ・バインディングとJSF構成オプションの詳細は、「web.xml」を参照してください。

ADF Facesアプリケーションでは通常、web.xml以外に構成ファイルの独自のセットが使用されます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のtrinidad-config.xmlでの構成に関する項を参照してください。

- adfc-config.xml: ADFバインドなしタスク・フローの構成ファイル。構成ファイルには、バインドなしタスク・フローに格納されているアクティビティおよび制御フローに関するメタデータが含まれています。このファイルのデフォルト名はadfc-config.xmlですが、エンド・ユーザーはこの名前を変更できます。
詳細は、「adfc-config.xml」を参照してください。

- task-flow-definition.xml: ADFバインド・タスク・フローの構成ファイル。構成ファイルには、バインド・タスク・フローに格納されているアクティビティおよび制御フローに関するメタデータが含まれています。このファイルのデフォルト名はtask-flow-defintion.xmlか、エンド・ユーザーが「ADFタスク・フローの作成」ダイアログで指定した名前にできます。複数のタスク・フロー定義ファイルを同一のアプリケーションに格納できます。
詳細は、「task-flow-definition.xml」を参照してください。

A.3 ADFファイルの構文図

図A-2は、ADFアプリケーション・モジュールをADFビジネス・コンポーネントに対するサービス・インタフェースとして使用しているWebアプリケーションで操作する可能性のあるXMLメタデータ・ファイルの階層構造を示しています。実行時には、これらのファイルから作成されたオブジェクトが次の順序で対話を行います。

1. ADFのデータ・バインドされたWebページに対する最初のリクエストが発生すると、サーブレットは、web.xmlファイルに設定されているOracle ADFサーブレット・フィルタのADFBindingFilterを登録します。

2. バインディング・フィルタにより、空のバインディング・コンテキストが作成されます。

3. ページがレンダリングされるとき、バインディング・フィルタはバインディング・コンテキストにこのページについて、対応するPageDef.xmlのロードを依頼します。

4. バインディング・コンテキストは、DataBindings.cpxファイルの<pagemap>要素による参照に従って<page>ファイルをロードし、バインディング・コンテナを作成します。

5. adfm.xmlファイルはDataBindings.cpxコンテンツをロードし、<pageDefinitionUsage>要素に対する<pagemap>要素参照に基づいて適切なPageDef.xmlを見つけます。

6. バインディング・コンテナのprepareModelフェーズは、関連するすべての実行可能ファイル(その大半はデフォルトでdeferredとマークされている)を準備し、リフレッシュします。

7. イテレータ・バインディングの実行には、bc4j.xcfgファイルのADFビジネス・コンポーネントに対して指定されたデータ・コントロール・ファクトリを通じて発見されたデータ・コントロールの名前付きメソッドが参照されます。

8. バインディング・コンテナは、マップされたWebページのpagenamePageDef.xmlファイルの<bindings>セクションに定義されたバインディングも作成します。

9. #{bindings}という式を使用した式言語(EL)に基づくADFバインディングへのWebページ参照が、そのページのバインディング・コンテナにアクセスすることで解決されます。

10. ページは、バインディング・コンテナのバインディングから使用可能なデータを取得します。

図A-2 ADF BCベースのWebアプリケーションにおけるOracle ADFファイル階層および構文図

A.4 adfm.xml

adfm.xmlファイルには、実行時にデプロイされたアプリケーションに組み入れられている各設計時プロジェクトの、.cpx、.dcx、.jpxおよび.xcfgファイルのクラスパス相対パスが含まれています。adfm.xmlファイルは、動的に管理される「レジストリのレジストリ」として動作し、.cpx、.dcx、.jpxおよび.xcfgファイル(自身がメタデータのレジストリ)の迅速な検索に使用されます。

ファイル・レジストリは、ADFライブラリ・リソース・カタログのブラウズの実装や、ADFモデル・レイヤーの設計時、またマージや検索の実行中に幅広く使用されます。

開発者がページ上にバインディングを作成した場合、JDeveloperのプロジェクト・ソース・ツリーにメタデータ・ファイル(ページ定義など)が追加されます。その後adfm.xmlでそれぞれの場所を記録します。

プロジェクトが作成されると、adfm.xmlファイルはproject-root/adfmsrc/META-INF/adfm.xmlに配置されます。プロジェクト・レベルのアーカイブ・デプロイ・プロファイルでは、ファイル位置はMETA-INF/adfm.xmlとされます。

実行時、アプリケーション・クラスパスはスキャンされ、アプリケーションを構成する.cpxファイルのリストを作成します。次にアプリケーションが必要に応じて各.cpxをロードし、バインディング・コンテキストを作成します。ADFモデル・レイヤーの使用の詳細は、「「データ・コントロール」パネルの使用時の処理」を参照してください。

adfm.xmlファイルにより、次の4つのタイプのサブレジストリが現在記録されています。

- DataBindingRegistry (.cpx)

- DataControlRegistry (.dcx)

- BusinessComponentServiceRegistry (.xcfg)

- BusinessComponentProjectRegistry (.jpx)

A.5 modelProjectName.jpx

.jpxファイルにはJDeveloperが設計時に使用して、ユーザーによるADFビジネス・コンポーネントを使ったデータ・モデル・プロジェクトの作成を可能にするための構成情報が含まれます。また、共有アプリケーション・モジュールが実行時に使用される方法を定義するメタデータも含まれます。共有アプリケーション・モジュールは同じFusion Webアプリケーションのデータ・モデル・プロジェクトからアクセスできるため、JDeveloperは、ADFビジネス・コンポーネント・プロジェクト構成ファイルにある共有アプリケーション・モジュールのスコープを保持します。

このファイルは、プロジェクトのsrcディレクトリに保存されています。たとえば、Oracle ADFのSummitサンプル・アプリケーションは、Model.jpxファイルを、Modelプロジェクトの.src/oracle/summit/modelサブディレクトリに保存します。

次の例では、サンプルのデフォルト.jpxファイルを表示します。

<JboProject
xmlns="http://xmlns.oracle.com/bc4j"
Name="Model"
Version="12.1.2.66.11"
SeparateXMLFiles="true"
PackageName="oracle.summit.model">
<DesignTime>
<Attr Name="_appModuleNames2"
Value="oracle.summit.model.services.BackOfficeAppModule"/>
<Attr Name="_jprName" Value="../../../../Model.jpr"/>
<Attr Name="_appModuleNames1"
Value="oracle.summit.model.services.CustomerSelfServiceAppModule"/>
<Attr Name="_appModuleNames0"
Value="oracle.summit.model.services.SummitAppModule"/>
<Attr Name="_jbo.TypeMapEntries" Value="Java"/>
<Attr Name="_NamedConnection" Value="summit_adf"/>
</DesignTime>
<Containee
Name="assoc"
PackageName="oracle.summit.model.entities.assoc"
ObjectType="JboPackage">
<DesignTime>
<Attr Name="_AS" Value="true"/>
</DesignTime>
</Containee>
<Containee
Name="entities"
PackageName="oracle.summit.model.entities"
ObjectType="JboPackage">
<DesignTime>
<Attr Name="_EO" Value="true"/>
<Attr Name="_VO" Value="true"/>
</DesignTime>
</Containee>
<Containee
Name="services"
PackageName="oracle.summit.model.services"
ObjectType="JboPackage">
<DesignTime>
<Attr Name="_AM" Value="true"/>
</DesignTime>
</Containee>
<Containee
Name="links"
PackageName="oracle.summit.model.views.links"
ObjectType="JboPackage">
<DesignTime>
<Attr Name="_VL" Value="true"/>
</DesignTime>
</Containee>
<Containee
Name="readonly"
PackageName="oracle.summit.model.views.readonly"
ObjectType="JboPackage">
<DesignTime>
<Attr Name="_VO" Value="true"/>
</DesignTime>
</Containee>
<Containee
Name="views"
PackageName="oracle.summit.model.views"
ObjectType="JboPackage">
<DesignTime>
<Attr Name="_VO" Value="true"/>
</DesignTime>
</Containee>
</JboProject>

A.6 bc4j.xcfg

bc4j.xcfgファイルには、アプリケーション・モジュール名に関するメタデータ情報、アプリケーション・モジュールが使用するデータベース接続、およびユーザーがアプリケーション・モジュールに対して構成した実行時パラメータが含まれています。

bc4j.xcfgファイルは、アプリケーション・モジュールのXMLコンポーネント定義に対して./commonと相対位置指定されるサブディレクトリにあります。同一のJavaパッケージ内の全アプリケーション・モジュールの構成はすべて、この同じファイルに保存されます。たとえば、Summit ADFサンプル・アプリケーションのModelプロジェクトの/Model/src/oracle/summit/model/services/commonディレクトリにあるbc4j.xcfgファイルを見ると、そのアプリケーション・モジュール用の構成があることがわかります。構成の編集の詳細は、「アプリケーション・モジュールのランタイム構成の変更方法」と「プール構成パラメータの設定」を参照してください。

例A-1に、Summit ADFサンプル・アプリケーションにあるサンプルのbc4j.xcfgファイルを示します。

例A-1 サンプルbc4j.xcfgファイル

<?xml version = '1.0' encoding = 'UTF-8'?>
<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
<AppModuleConfigBag ApplicationName="oracle.summit.model.services.SummitAppModule">
<AppModuleConfig name="SummitAppModuleLocal" DeployPlatform="LOCAL" JDBCName="summit_adf" jbo.project="oracle.summit.model.Model" java.naming.factory.initial="oracle.jbo.common.
JboInitialContextFactory" ApplicationName="oracle.summit.model.services.SummitAppModule">
<Database jbo.TypeMapEntries="Java"/>
<Security AppModuleJndiName="oracle.summit.model.services.SummitAppModule"/>
</AppModuleConfig>
<AppModuleConfig name="SummitAppModuleShared" DeployPlatform="LOCAL" JDBCName="summit_adf" jbo.project="oracle.summit.model.Model" java.naming.factory.initial="oracle.jbo.common.JboInitialContextFactory"
ApplicationName="oracle.summit.model.services.SummitAppModule">
<AM-Pooling jbo.ampool.isuseexclusive="false" jbo.ampool.maxpoolsize="1"/>
<Database jbo.TypeMapEntries="Java"/>
<Security AppModuleJndiName="oracle.summit.model.services.SummitAppModule"/>
</AppModuleConfig>
</AppModuleConfigBag>
<AppModuleConfigBag ApplicationName="oracle.summit.model.services.CustomerSelfServiceAppModule">
<AppModuleConfig name="CustomerSelfServiceLocal" jbo.project="oracle.summit.model.Model" ApplicationName="oracle.summit.model.services.CustomerSelfServiceAppModule"
DeployPlatform="LOCAL" JDBCName="summit_adf">
<Database jbo.TypeMapEntries="Java"/>
<Security AppModuleJndiName="oracle.summit.model.services.CustomerSelfServiceAppModule"/>
</AppModuleConfig>
<AppModuleConfig name="CustomerSelfServiceShared" jbo.project="oracle.summit.model.Model" ApplicationName="oracle.summit.model.services.CustomerSelfServiceAppModule"
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.CustomerSelfServiceAppModule"/>
</AppModuleConfig>
</AppModuleConfigBag>
<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>

A.7 DataBindings.cpx

DataBindings.cpxファイルは、データ・コントロール使用名を、ビジュアル・エディタのWebページに初めてドロップしたときに、ユーザー・インタフェース・プロジェクト内に作成されます。DataBindings.cpxファイルでは、アプリケーション全体のOracle ADFバインディング・コンテキストが定義され、メタデータが提供されます。実行時には、このメタデータからOracle ADFバインディング・オブジェクトが作成されます。これは、ADFライブラリ・リソース・カタログのブラウズの実装により、また.cpxや.dcxの設計時および実行時のマージや検索により広く使用されます。データ・バインドUIコンポーネントをドキュメントに挿入した時点で、実行時にOracle ADFバインディング・オブジェクトにアクセスするバインディング式がページに存在するようになります。

DataBindings.cpxファイルは、ユーザー・インタフェース・プロジェクト・フォルダの/srcディレクトリにあります。ファイル・ノードをダブルクリックすると、XMLソース・エディタにバインディング・コンテキスト記述が表示されます。(バインディング・コンテキスト・パラメータを編集するには、「プロパティ」ウィンドウを使用して、「構造」ウィンドウで適切なパラメータを選択します。)

A.7.1 DataBindings.cpxの構文

DataBindings.cpxファイルの最上位レベルの要素は<Application>です。次に例を示します。

<?xml version="1.0" encoding="UTF-8" ?>
<Application xmlns="http://xmlns.oracle.com/adfm/application"
version="11.1.1.56.60" id="DataBindings" SeparateXMLFiles="false"
Package="oracle.summit.view" ClientType="Generic">

図A-3に、Oracle ADFのSummitスタンドアロン・サンプル・アプリケーションにあるDataBindings.cpxファイルの構造定義を示します。

図A-3 DataBindings.cpxファイルの構造

子要素の使用方法は、次のとおりです。

- <definitionFactories>には、実行時に個別のネームスペースに関連付けられるADFバインディング・オブジェクトを作成するためのファクトリ・クラスが登録されます。ファクトリ・クラスは、ADFバインディングのタイプ(タスク・フロー・バインディングなど)に関連付けられたネームスペースに固有です。

- <pageMap>要素: すべてのユーザー・インタフェースURLと、対応するページ定義慣用名をマップします。このマップは、実行時にURLをそのページ定義にマップするために使用されます。

- <pageDefinitionUsages>は、ページ定義慣用名(BindingContainerインスタンス名)を、対応するページ定義にマップします。id属性は、使用IDを示します。path属性は、ページ定義へのフルパスを示します。

- <dataControlUsages>は、データ・コントロール慣用名(短縮名)と、それらに対応する.dcxまたは.xcfgファイルのデータ・コントロール定義エントリへのパスのリストを宣言します。

表A-1に、DataBindings.cpxの各要素の属性を示します。

表A-1 DataBindings.cpxファイルの各要素の属性

要素の構文

属性

属性の説明

<definitionFactories> <factory/></definitionFactories>

nameSpace

URI。ページ定義慣用名における実行可能要素の位置を識別します。

className

完全修飾クラス名。ページ定義慣用名オブジェクトを作成するファクトリ・クラスの位置を識別します。

<pageMap> <page /></pageMap>

path

ディレクトリへのフルパス。ユーザー・インタフェース・ページの場所を識別します。

usageId

一意の修飾子。ADFページ定義ファイルに出現するページ定義IDを指定します。ADFバインディング・サーブレットは、受信URLリクエストを検出し、bindings変数が受信HTTPリクエストのURLに関連付けられたADFページ定義を指し示しているかどうかをチェックします。

<pageDefinitionUsages> <page/></pageDefinitionUsages>

id

一意の修飾子。ADFページ定義ファイルに出現するページ定義IDを参照します。

path

完全修飾パッケージ名。ユーザー・インタフェース・ページのADFページ定義ファイルの場所を識別します。

<dataControlUsages> <dc.../></dataControlUsages>

id

一意の修飾子。DataControls.dcxファイルの定義に従ってデータ・コントロールの使用を識別します。

path

完全修飾パッケージ名。データ・コントロールの場所を識別します。

A.7.2 DataBindings.cpxの例

例A-2に、Summit ADFサンプル・アプリケーションにあるDataBindings.cpxファイルの構造を示します。

ADF実行可能定義ファクトリ(factory要素)はclassName属性により指定され、namespaceと関連付けられます。実行時、ファクトリ・クラスは、特定のページ定義に関連付けられるADFバインディング・コンテナで使用されるバインディング・オブジェクトの作成を導く実行可能定義オブジェクトを作成します。ファクトリは2個のDataBindings.cpxファイル要素を通じて、ページ定義を見つけます。この要素の1つは設計時に割り当てられたページ定義ID (usageId属性)にページURLをマップするpageMap要素で、もう1つはプロジェクトまたはプロジェクト・クラスパスのページ定義の場所にこのIDをマップするpageDefinitionUsages要素です。

さらに、ADFビジネス・コンポーネント・データ・コントロール(BC4JDataControl要素)は、id属性によって名前を指定されます。Package属性とConfiguration属性の組合せは、指定されたパッケージの./commonサブディレクトリ内でbc4j.xcfgファイルの場所を識別するために使用されます。該当する構成には、アプリケーション・モジュール名とユーザーが構成済の全ランタイム・パラメータに関する情報が含まれています。

例A-2 サンプルDataBindings.cpxファイル

<?xml version="1.0" encoding="UTF-8" ?>
<Application xmlns="http://xmlns.oracle.com/adfm/application"
version="11.1.1.56.60" id="DataBindings" SeparateXMLFiles="false"
Package="oracle.summit.view" ClientType="Generic">
<definitionFactories>
<factory nameSpace="http://xmlns.oracle.com/adf/controller/binding"
className="oracle.adf.controller.internal.binding.TaskFlowBindingDefFactoryImpl"/>
<dtfactory className="oracle.adf.controller.internal.dtrt.binding.BindingDTObjectFactory"/>
<factory nameSpace="http://xmlns.oracle.com/adfm/dvt"
className="oracle.adfinternal.view.faces.dvt.model.binding.FacesBindingFactory"/>
</definitionFactories>
<pageMap>
<page path="/index.jsf" usageId="oracle_summit_view_indexPageDef"/>
<page path="/Customers.jsff" usageId="oracle_summit_view_CustomersPageDef"/>
<page path="/orders/Orders.jsff"
usageId="oracle_summit_view_OrdersPageDef"/>
<page path="/carousel/InventoryControl.jsff" usageId="oracle_summit_view_InventoryControlTestPageDef"/>
</pageMap>
<pageDefinitionUsages>
<page id="oracle_summit_view_CustomersPageDef"
path="oracle.summit.view.pageDefs.CustomersPageDef"/>
<page id="oracle_summit_view_indexPageDef"
path="oracle.summit.view.pageDefs.indexPageDef"/>
<page id="oracle_summit_view_OrdersPageDef"
path="oracle.summit.view.pageDefs.OrdersPageDef"/>
<page id="oracle_summit_view_InventoryControlTestPageDef"
path="oracle.summit.view.pageDefs.InventoryControlPageDef"/>
</pageDefinitionUsages>
<dataControlUsages>
<BC4JDataControl id="BackOfficeAppModuleDataControl"
Package="oracle.summit.model.services"
FactoryClass="oracle.adf.model.bc4j.DataControlFactoryImpl"
SupportsTransactions="true" SupportsFindMode="true"
SupportsRangesize="true" SupportsResetState="true"
SupportsSortCollection="true"
Configuration="BackOfficeAppModuleLocal"
syncMode="Immediate"
xmlns="http://xmlns.oracle.com/adfm/datacontrol"/>
</dataControlUsages>
</Application>

A.8 pageNamePageDef.xml

pageNamePageDef.xmlファイルは、「データ・コントロール」パネルまたは「構造」ウィンドウを使用して、データバインドされたコンポーネントをWebページに挿入するたびに作成されます。これらのXMLファイルにより、アプリケーションの各WebページのOracle ADFバインディング・コンテナが定義されます。バインディング・コンテナは、ページ内のバインディングへのアクセスを提供します。データバインドされたWebページごとに1つのXMLファイルが割り当てられます。

注意:

DataBindings.cpxファイルは、JSFページを対応するページ定義ファイルにマップします。ページ定義ファイルまたはJSFページの名前を変更した場合、JDeveloperにより、DataBindings.cpxファイルが自動的にリファクタされることはありません。DataBindings.cpxファイルでページのマッピングを手動で更新する必要があります。

PageDef.xmlファイルは、ユーザー・インタフェース・プロジェクトの/src/viewディレクトリにあります。「アプリケーション」ウィンドウでは、「アプリケーション・ソース」ノードのビュー・パッケージ内にこのファイルが表示されます。ファイル・ノードをダブルクリックすると、XMLソース・エディタにページ記述が表示されます。ページ記述パラメータを編集するには、「プロパティ」ウィンドウを使用して、「構造」ウィンドウで適切なパラメータを選択します。

詳細は、「ページ定義ファイルでの作業」を参照してください。

ページ定義の生成方法は、単一値を戻すメソッドとコレクションを戻すメソッドでは大きな違いがあります。

A.8.1 PageDef.xmlの構文

PageDef.xmlファイルのトップレベルの要素は、<pageDefinition>です。

<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="11.1.1.59.23" id="<pagename>PageDef"
Package="oracle.summit.view.pageDefs">

ここでのXMLネームスペース属性(xmlns)により、ADFバインディング・コンテナの実行時のバインド先となるURIを指定します。パッケージ名のみ編集可能であり、他のすべての属性はここに示したとおりの値に設定する必要があります。

次の例は、<pageDefinition>要素の子要素の階層を示しています。データ・コントロールを作成したビジネス・サービスごとに、独自の<AdapterDataControl>定義が割り当てられます。

<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition>
<parameters>
...
</parameters>
<executables>
...
</executables>
<bindings>
...
</bindings>
</pageDefinition>

子要素の使用方法は、次のとおりです。

- <parameters>: ELでアクセス可能なページ・レベルのパラメータを定義します。これらのパラメータは、Webページ・リクエストに固有の情報を格納しており、バインディング式を通じてアクセスできます。

- <executables>: ADFページ・ライフサイクルのprepareModelフェーズ中に実行される項目(メソッド、ビュー・オブジェクトおよびアクセッサ)のリストを定義します。実行されるメソッドは、<methodIterator>により定義されます。ライフサイクルでは、<executables>セクションにリストされた順序で実行処理が行われます。メソッドまたは操作が実行されるかどうかは、そのRefreshまたはRefreshCondition属性の値に依存します。データ・コントロールの組込み操作は、次の要素で定義されます。

- <page>: ネストされたページの定義(バインディング・コンテナ)

- <iterator>: DataControlsの名前付きコレクションの定義

- <accessorIterator>: データ・コントロール階層のアクセッサを取得するための定義

- <methodIterator>: 同じファイルのmethodActionにより定義された起動メソッドから戻されるイテレータを取得するための定義

- <variableIterator>: バインディング・コンテナに対して宣言された変数を格納する内部イテレータ

- <invokeAction>: 実行可能項目として起動されるメソッドの定義

注意:

アプリケーションで、Fusion Webアプリケーションのテクノロジ・スタックにあるADFコントローラ・モジュールを使用していない場合は、invokeActionのみを使用します。アプリケーションでADFコントローラ・モジュールを使用している場合は、「メソッド・コール・アクティビティの使用」に示すように、タスク・フローのメソッド・コール・アクティビティを使用することをお薦めします。

- <bindings>: <executables>内のエントリを参照して、バインディングが属性レベルのデータを抽出または送信するコレクションを取得します。

表A-2に、<pageDefinition>トップレベル要素の属性を示します。

表A-2 PageDef.xmlファイルの<pageDefinition>要素の属性

要素の属性" width="100%">

要素の構文

属性

属性の説明

<pageDefinition>

ControllerClass

コントローラがこのbindingContainerのPageControllerオブジェクトをリクエストしたときに作成されるクラスの完全修飾名。

EnableTokenValidation

ポストバックが発生したときに、このbindingContainerで現在位置検証を有効化します。これにより、Web層の状態が特定ページのレンダリング状態と一致することが保証されます。

FindMode

FindModeは旧リリース(10.1.2)でのみ使用します。初期準備の際に、このbindingContainerをfindModeで開始するかどうかを示します。

MsgBundleClass

完全修飾パッケージ名。任意のバインディングの翻訳文字列を含むクラスを識別します。

SkipValidation

データ検証が行われたかどうかを判断します。サポートされている値は次のとおりです。

- true: データ検証を省略します。ただし、クライアント側でのバインディング・レベルの属性検証は引き続き行われますので注意してください。たとえば、NULL以外の値や型変換エラーが検証されます。

- false: 現在のページで参照されているデータ・コントロールすべての行をすべて検証します。これはデフォルト値です。

- skipDataControls: 現在のページで変更されたイテレータ・バインディングの現在の行を検証します。

- custom: アプリケーションがoracle.binding.BindingContainerValidatorインタフェースのインスタンスを実装し、バインディング・コンテナにあるCustomValidatorというEL式エントリを通じてこれを参照している場合は、customに設定します。

たとえば、トレイン・コンポーネントなどのデータ検証を省略する必要がある場合には、この属性に値を設定しておくと便利です。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のトレイン・モデルの作成方法に関する項を参照してください

Viewable

このバインディングおよび関連コンポーネントをレンダリングするかどうかを決定するため、実行時に解決されるEL式。

表A-3に、<parameters>の子要素の属性を示します。

表A-3 PageDef.xmlファイルの<parameters>要素の属性

要素の属性" width="100%">

要素の構文

属性

属性の説明

<parameter>

evaluate

eachUse、firstUseまたはinPrepareModelのいずれかでパラメータを評価するタイミングを指定します。

id

一意の識別子。ADFバインディングにより参照できます。

option

バインディング・コンテナ内での変数の使用方法を次のように示します。

- Final: このバインディング・コンテナの慣用名がこのパラメータを渡すことができないことを示します。定義内のデフォルト値を使用する必要があります。

- Optional: 変数の値を提供する必要がないことを示します。

- Mandatory: 実行時にJavaまたはEL式を使用してパラメータ値を指定する必要があることを指定します。必須パラメータまたはバインディングに対して値を指定しないと、バインディングの検証時に例外がスローされます。

readonly

パラメータ値が変更可能であるかどうかを示します。パラメータ値の変更をアプリケーションに許可しない場合は、trueに設定します。

value

デフォルト値。EL式を使用できます。

表A-4に、PageDef.xmlの<executables>要素の属性を示します。

表A-4 PageDef.xmlファイルの<executables>要素の属性

要素の属性" title="PageDef.xmlファイルの<executables>要素の属性" width="100%">

要素の構文

属性

属性の説明

<accessorIterator>

Accessor

このバインディングによって定義されるその他のアクセッサを指定します。

Binds

イテレータのバインド先となるビューまたはアクションを指定します。

BeanClass

関連付けられたイテレータ(コレクション)のBeanのJava型を識別します。

CacheResults

trueの場合、リクエスト間でデータ・コレクションが管理されます。

ChangeEventRate

コンポーネントがこのイテレータを介してデータに関連付けられているとき、およびポーリング・イベント・モードのときの、イベントのレートを指定します。

DataControl

このイテレータ・バインディングにより参照されるコレクションを解析して、戻します。

id

一意の識別子。任意のADF値バインディングにより参照できます。

MasterBinding

マスターとして機能するデータ・コレクションをアクセッサ・イテレータのディテール・コレクションにバインドするmethodIterator(イテレータ)への参照。

ObjectType

ADFビジネス・コンポーネント専用。ブール値により、コレクションがオブジェクト型であるかどうかを指定します。

RangeSize

バインドされたコレクションからフェッチする、範囲内のデータ・オブジェクトの数を指定します。レンジは、コレクション内のデータ・オブジェクトのサブセットにアクセスする際に使用できるウィンドウを定義します。通常は、「データ・コントロール」パネルからオブジェクトをドラッグすることでコンポーネントを作成すると、レンジ・サイズは25に設定されます。セット全体を使用する場合、またはページに表示されるデータ・オブジェクトの数を制限したい場合は、RangeSizeを使用します。-1および0という値に特定の意味があることに注意してください。値-1の場合、使用可能なオブジェクトすべてがコレクションから返されます。値0の場合、コレクションがデータソースから取得を行うために収容しているのと同じ数のオブジェクトが返されます。RangeSize属性を指定しない場合、使用可能なすべてのオブジェクトが戻されます。

Refresh

どのようなときに実行可能項目を起動するかを指定します。Refresh属性はデフォルト値(deferred)から変更せず、実行可能項目をリフレッシュするかどうかを決定するにはRefreshCondition属性のEL式を使用することをお薦めします。完全を期すために、有効な属性値を次にリストします。

- always: バインディング・コンテナが準備されるたびに、実行可能項目を起動します。ページが表示されたとき、ユーザーが変更を送信したとき、またはアプリケーションがページに再ポストしたときにリフレッシュが発生します。

- deferred: リフレッシュは、別のバインディングが要求するか、この実行可能項目を参照するときに発生します。実行可能項目をリフレッシュするとパフォーマンスが低下することがあるため、レンダリングされるバインディングでdeferredが使用されている場合にのみリフレッシュが発生するように設定できます。これはADF Facesアプリケーションのデフォルト値です。

- <default>: デフォルトでは常にdeferredに設定されます。

- ifNeeded: その時点までリフレッシュが発生していないためにフレームワークが必要とする場合、実行可能項目のリフレッシュが発生します。たとえば、ページ定義の最初にディテールがリストされるようなアクセッサ階層が存在すると、マスターが2回リフレッシュされる可能性があります(ディテールに対して1回とマスターのイテレータに対して1回)。ifNeededを使用すると、リフレッシュの重複を回避できます。これは、ADF Faces以外のすべてのビュー・テクノロジに対するデフォルト値です。

- never: コントローラ・フェーズのいずれかにおいて、アプリケーション自体で実行可能項目のリフレッシュをコールします。フレームワークによる実行可能項目のリフレッシュは実行されません。

- prepareModel: ページのバインディング・コンテナが準備されるたびに、実行可能項目を起動します。

- prepareModelIfNeeded: その時点までにその実行可能項目のリフレッシュが発生していない場合、モデル準備フェーズ中に実行可能項目を起動します。ifNeededも参照してください。

- renderModel: ページがレンダリングされるたびに、実行可能項目を起動します。

- renderModelIfNeeded: 必要に応じて、ページのモデル・レンダリング・フェーズ中に実行可能項目を起動します。ifNeededも参照してください。

RefreshCondition

実行可能項目をリフレッシュするかどうかを決定するEL式。実行可能項目のRefresh属性とともに使用して、実行可能項目のリフレッシュを予想可能にします。Refresh属性は、RefreshConditionに対して設定したEL式がtrueを戻した場合に評価されます。

RefreshAfter

実行可能ファイル間の依存性の処理に使用します。たとえば、別の実行可能ファイルの後にこの実行可能ファイルがリフレッシュされるように条件を設定できます。

RowCountThreshold

ユーザーが値として指定した行数が結果セットから戻されるかどうかを決定する値を指定します。RowCountThresholdを0に設定した場合、イテレータはカウント問合せを実行して、推定される行カウントを結果セットに戻します。RowCountThresholdを0未満に設定した場合、イテレータはカウント問合せを実行しません。

ユーザーがRowCountThresholdに指定した値を最大値として、イテレータにカウント問合せを実行させる場合は、RowCountThresholdに0を超える値を設定します。推定される行カウントがRowCountThresholdを下回る場合は、推定される行カウントの行数が戻されます。推定される行カウントがRowCountThresholdを超える場合は、-1が戻されます。

Sortable

イテレータがソート可能かどうかを指定します。

<invokeAction>

アプリケーションで、Fusion Webアプリケーションのテクノロジ・スタックにあるADFコントローラ・モジュールを使用していない場合は、<invokeAction>のみを使用します。アプリケーションでADFコントローラ・モジュールを使用している場合は、「メソッド・コール・アクティビティの使用」に示すように、タスク・フローのメソッド・コール・アクティビティを使用することをお薦めします。

Binds

起動するアクションを指定します。任意のactionBindingで使用できます。また、EJBセッション・ファサード・データ・コントロールの場合、データ・コントロールにより公開されるfinderメソッドにバインドできます。EJBセッション・ファサード・データ・コントロールでサポートされる組込みのアクションは、次のとおりです。

- Execute: データ・コレクションにより定義されたバインド・アクションを実行します。

- Find: コレクションからデータ・オブジェクトを取得します。

- First: データ・コレクション・レンジ内の最初のデータ・オブジェクトに移動します。

- Last: データ・コレクション・レンジ内の最初のデータ・オブジェクトに移動します。

- Next: データ・コレクション・レンジ内の最初のデータ・オブジェクトに移動します。現在のレンジ位置がすでに最後のデータ・オブジェクト上にある場合には、アクションは実行されません。

- Previous: データ・コレクション・レンジ内の最初のデータ・オブジェクトに移動します。現在の位置がすでに最初のデータ・オブジェクト上にある場合には、アクションは実行されません。

- setCurrentRowWithKey: 入力フィールドで指定された値から変換したStringとして行キーを渡します。行キーは、バインドされたデータ・コレクション内のデータ・オブジェクトの現状設定に使用されます。キーを渡す際に、フォームのURLには行キー値は表示されません。この操作は、データ・コレクションがマルチパートの属性キーを定義する場合に使用できます。

- setCurrentRowWithKeyValue: setCurrentRowWithKeyと同様ですが、文字列化されたキーのかわりに主キー値を使用する場合に指定します。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

Refresh

<accessorIterator>のRefresh属性を参照してください。

RefreshCondition

<accessorIterator>のRefreshCondition属性を参照してください。

<iterator>および<methodIterator>

BeanClass

関連付けられたイテレータ(コレクション)のBeanのJava型を識別します。

BindingClass

この属性は、後方互換性を目的としており、このバインディング定義のランタイムを実装するクラスを示します。JDeveloperの現在のリリースでは使用されません。

Binds

<invokeAction>のBinds属性を参照してください。

CacheResults

<accessorIterator>のCacheResults属性を参照してください。

ChangeEventRate

コンポーネントがこのイテレータを介してデータに関連付けられているとき、およびポーリング・イベント・モードのときの、イベントのレートを指定します。

DataControl

このイテレータが関連付けられているbindingContext(.cpx)のDataControl使用の名前。

DefClass

ADFによる内部使用属性。

id

一意の識別子。任意のADF値バインディングにより参照できます。

ObjectType

EJBセッション・ファサード・データ・コントロールでは使用されません(ADFビジネス・コンポーネントでのみ使用されます)。

RangeSize

<accessorIterator>のRangeSize属性を参照してください。

Refresh

<accessorIterator>のRefreshを参照してください。

RefreshAfter

ページをリフレッシュした後の条件を指定します。

RefreshCondition

<accessorIterator>のRefreshCondition属性を参照してください。

RowCountThreshold

<accessorIterator>のRowCountThresholdを参照してください。

<page>および<variableIterator>

id

一意の識別子。<page>の場合、このページに含まれるネストされたページ(リージョン)を示します。<variableIterator>実行可能項目の場合、任意のADF値バインディングによりこの識別子を参照できます。

ChangeEventRate

コンポーネントがこのイテレータを介してデータに関連付けられているとき、およびポーリング・イベント・モードのときの、イベントのレートを指定します。

path

<page>実行可能項目にのみ使用されます。高度な使用例として、別のページのバインディング・コンテナを参照する完全修飾パスを指定できます。

Refresh

<accessorIterator>のRefresh属性を参照してください。

RefreshAfter

ページをリフレッシュした後の条件を指定します。

RefreshCondition

<accessorIterator>のRefreshCondition属性を参照してください。

表A-5に、PageDef.xml <bindings>要素の属性を示します。

表A-5 PageDef.xmlファイルの<bindings>要素の属性

要素の属性" width="100%">

要素の構文

属性

属性の説明

<action>

Action

完全修飾パッケージ名。データ・コントロールの作成されるクラスを識別します。EJBセッション・ファサードの場合は、セッションBeanです。

BindingClass

この属性は、後方互換性を目的としており、このバインディング定義のランタイムを実装するクラスを示します。旧バージョンのJDeveloperで使用します。

DataControl

このiteratorBindingまたはactionBindingが関連付けられているbindingContext(.cpx)のDataControl使用の名前。

Execute

自動的に構成されたActionListenerプロパティで「データ・コントロール」パネルから操作をドロップするとき、デフォルトで使用されます。結果として、バインディング・アクションの操作を実行時に実行することになります。

InstanceName

アクションのインスタンス名を指定します。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを指定します。

Outcome

メソッド・アクション・バインディングの結果(一度Stringに変換されている)をJSFナビゲーション結果名として使用する場合に使用します。

<attributeValues>

ApplyValidation

デフォルトでtrueに設定されます。trueの場合、controlBindingにより、バインディングに定義されたバリデータが実行されます。ADFビジネス・コンポーネントにおいて、ローカル・モードが使用され、対応する属性に同じバリデータがすでに定義されている場合は、falseに設定できます。

BindingClass

この属性は、後方互換性を目的としており、このバインディング定義のランタイムを実装するクラスを示します。旧バージョンのJDeveloperで使用します。

ChangeEventPolicy

ADS(アクティブ・データ・サービス)を使って実行される場合のコンポーネントのイベント戦略を指定します。次のいずれかを指定できます。

push

poll

ppr

なし

ControlClass

ADFによる内部使用属性。

CustomInputHandler

これは、指定された値バインディングに対してinputValueを処理するために使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

DefClass

ADFによる内部使用属性。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

NullValueId

リスト表示にNULL値を示すためのStringを含むbindingContainerのメッセージ・バンドルのエントリを参照します。

<button>

ApplyValidation

デフォルトでtrueに設定されます。trueの場合、controlBindingにより、バインディングに定義されたバリデータが実行されます。ADFビジネス・コンポーネントにおいて、ローカル・モードが使用され、対応する属性に同じバリデータがすでに定義されている場合は、falseに設定できます。

BindingClass

この属性は、後方互換性を目的としており、このバインディング定義のランタイムを実装するクラスを示します。旧バージョンのJDeveloperで使用します。

BoolVal

このブール・リスト・バインディングの静的値のリストにおいて、0(ゼロ)索引の値がtrueとfalseのいずれを示すかを指定します。

ControlClass

ADFによる内部使用属性。

CustomInputHandler

特定の値バインディングのinputValueを処理する際に使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

DefClass

ADFによる内部使用属性。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

ListIter

このlistBindingのソース・リストに関連付けられているiteratorBindingを参照します。

ListOperMode

このリスト・バインディングをナビゲーション用とするか、値の静的リストとするか、またはLOV型のリストとするかを指定します。

NullValueFlag

このリスト・バインディングにNULL値を含めるかどうかを指定します。含める場合は、リストの最初または最後のどちらに表示するかを指定します。

NullValueId

リスト表示にNULL値を示すためのStringを含むbindingContainerのメッセージ・バンドルのエントリを参照します。

<gantt>

ChangeEventPolicy

コンポーネントの更新ポリシーを識別します。有効な値は、none、ppr、pushです。デフォルトはpprです。

xmlns

ADFによる内部使用属性。

CustomInputHandler

特定の値バインディングのinputValueを処理する際に使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

NullValueId

リスト表示にNULL値を示すためのStringを含むbindingContainerのメッセージ・バンドルのエントリを参照します。

ganttDataMap

ADF Facesガント・チャート・コンポーネントのデータ・バインディングXMLをラップします。

<gauge>

type

ゲージ・タイプを識別します。

ledStyle

ゲージのLEDスタイルを識別します。

ChangeEventPolicy

コンポーネントの更新ポリシーを識別します。有効な値は、none、ppr、pushです。デフォルトはpprです。

xmlns

ADFによる内部使用属性。

CustomInputHandler

特定の値バインディングのinputValueを処理する際に使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

NullValueId

リスト表示にNULL値を示すためのStringを含むbindingContainerのメッセージ・バンドルのエントリを参照します。

gaugeDataMap

ADF Faces gaugeコンポーネントのデータ・バインディングXMLをラップします。

<graph>

type

グラフ・タイプを識別します。

ChangeEventPolicy

コンポーネントの更新ポリシーを識別します。有効な値は、none、ppr、pushです。デフォルトはpprです。

xmlns

ADFによる内部使用属性。

CustomInputHandler

特定の値バインディングのinputValueを処理する際に使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

NullValueId

リスト表示にNULL値を示すためのStringを含むbindingContainerのメッセージ・バンドルのエントリを参照します。

graphDataMap

ADF Faces graphコンポーネントのデータ・バインディングXMLをラップします。

<list>

ApplyValidation

デフォルトでtrueに設定されます。trueの場合、controlBindingにより、バインディングに定義されたバリデータが実行されます。ADFビジネス・コンポーネントにおいて、ローカル・モードが使用され、対応する属性に同じバリデータがすでに定義されている場合は、falseに設定できます。

BindingClass

この属性は、後方互換性を目的としており、このバインディング定義のランタイムを実装するクラスを示します。旧バージョンのJDeveloperで使用します。

ControlClass

ADFによる内部使用属性。

CustomInputHandler

特定の値バインディングのinputValueを処理する際に使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

DefClass

ADFによる内部使用属性。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

ListIter

このlistBindingのソース・リストに関連付けられているiteratorBindingを参照します。

ListOperMode

このリスト・バインディングをナビゲーション用とするか、値の静的リストとするか、またはLOV型のリストとするかを指定します。

Mode

この属性の値のよって、リスト・バインディングが実際の値(Object)を渡すか、索引にある値の場所(Index)を渡すかが決まります。この属性の設定の詳細は、「選択リストの値に関する必知事項」を参照してください。

MRUCount

ユーザーが最近選択したアイテムをショートカットとして提供するときに、選択リストに表示するアイテム数を指定します。たとえば、フォームにサプライヤIDの選択リストを表示して、発注書を作りやすくすることができます。この例では、ユーザーは最近表示されたサプライヤのリストから選択できますが、このリストに表示される選択肢の数は、ユーザーが入力した値によって決定されます。デフォルトは0(ゼロ)で、選択リストには属性の値がすべて表示されます。

MRUId

MRUリストのための識別子行になるStringを指定します。

NullValueFlag

このリスト・バインディングにNULL値を含めるかどうかを指定します。含める場合は、リストの最初または最後のどちらに表示するかを指定します。

NullValueId

リスト表示にNULL値を示すためのStringを含むbindingContainerのメッセージ・バンドルのエントリを参照します。

StaticList

バインドされたリスト・コンポーネントにレンダリングされる値の静的リストを定義します。

<mapTheme>

ChangeEventPolicy

コンポーネントの更新ポリシーを識別します。有効な値は、none、ppr、pushです。デフォルトはpprです。

xmlns

ADFによる内部使用属性。

CustomInputHandler

特定の値バインディングのinputValueを処理する際に使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

NullValueId

リスト表示にNULL値を示すためのStringを含むbindingContainerのメッセージ・バンドルのエントリを参照します。

mapThemeDataMap

ADFデータ視覚化地理マップ・コンポーネントに対するデータ・バインディングXMLをラップします。

<methodAction>

Action

完全修飾パッケージ名。データ・コントロールの作成されるクラスを識別します。EJBセッション・ファサードの場合は、セッションBeanです。

BindingClass

この属性は、後方互換性を目的としており、このバインディング定義のランタイムを実装するクラスを示します。旧バージョンのJDeveloperで使用します。

ClassName

起動されるメソッドが属しているクラスです。

DataControl

このiteratorBindingまたはactionBindingが関連付けられているbindingContext(.cpx)のDataControl使用の名前。

DefClass

ADFによる内部使用属性。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

InstanceName

関連付けられたメソッドが起動されるJavaオブジェクト・インスタンスへのドット区切りのELパス。

IsLocalObjectReference

instanceNameに、このbindingContainerを基準として相対的に記述されたELパスが含まれる場合は、trueに設定します。

IsViewObjectMethod

instanceNameに、関連データ・コントロールのアプリケーション・モジュールを基準として相対的に記述されたインスタンス・パスが含まれる場合は、trueに設定します。

MethodName

このmethodActionBindingで起動する必要のある特定のインスタンスまたはクラスの操作の名前を示します。

RequiresUpdateModel

このアクションの起動前に、アクションでモデルの更新を必要とするかどうかを指定します。

ReturnName

関連付けられたメソッドにより戻される結果のELパス。

<pivotTable>

ChangeEventPolicy

コンポーネントの更新ポリシーを識別します。有効な値は、none、ppr、pushです。デフォルトはpprです。

xmlns

ADFによる内部使用属性。

CustomInputHandler

特定の値バインディングのinputValueを処理する際に使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

NullValueId

リスト表示にNULL値を示すためのStringを含むbindingContainerのメッセージ・バンドルのエントリを参照します。

pivotTableDataMap

ADFデータ視覚化ピボット・テーブル・コンポーネントに対するデータ・バインディングXMLをラップします。

<table>および<tree>

ApplyValidation

デフォルトでtrueに設定されます。trueの場合、controlBindingにより、バインディングに定義されたバリデータが実行されます。ADFビジネス・コンポーネントにおいて、ローカル・モードが使用され、対応する属性に同じバリデータがすでに定義されている場合は、falseに設定できます。

BindingClass

この属性は、後方互換性を目的としており、このバインディング定義のランタイムを実装するクラスを示します。旧バージョンのJDeveloperで使用します。

CollectionModel

CollectionModelオブジェクト(ADF表コンポーネントが使用するデータ・モデル)にアクセスします。表の値は、CollectionModel属性にバインドされます。表は、イテレータ・バインディングからの結果セットをCollectionModelオブジェクト内にラップします。CollectionModel属性により、コレクションの各アイテムを、var属性を使用して表コンポーネント内で使用できるようになります。

ControlClass

テスト用の内部使用属性。

CustomInputHandler

特定の値バインディングのinputValueを処理する際に使用されるoracle.jbo.uicli.binding.JUCtrlValueHandler実装のクラス名です。

DefClass

ADFによる内部使用属性。

DiscrValue

階層タイプのバインディング(ツリー・ノードのタイプ定義)における多相化識別子の値を示します。この値により、多相ツリー・バインディングにレンダリングされるコレクションの特定行を、包含階層タイプのバインディングを使用してレンダリングするかどうかを指定します。

id

一意の識別子。任意のADFアクション・バインディングにより参照できます。

IterBinding

このバインディングが関連付けられているbindingContainerのiteratorBindingインスタンスを参照します。

TreeModel

ADFツリー・コンポーネントで使用されるデータ・モデル。TreeModelは、CollectionModelを拡張して、コンテナ行のサポートを追加します。TreeModel内の行には、他の行が含まれることがあります(再帰的に)。

A.9 adfc-config.xml

adfc-config.xmlファイルは、ADF Fusion Webアプリケーション・テンプレートを使用してアプリケーションを作成するときにデフォルトでJDeveloperが作成するADFバインドなしタスク・フローのソース・ファイルです。デフォルトでは、JDeveloperは、adfc-config.xmlファイルを次のディレクトリに格納します。

application_root\ViewController\Web Content\WEB-INF

追加のバインドなしタスク・フローを作成すると、JDeveloperは、追加のバインドなしタスク・フローのソース・ファイルに次のファイル名を提案します。

adfc-configN.xml

ここでNは新しいバインドなしタスク・フローを作成するたびに増分する番号です。または、バインドなしタスク・フローのソース・ファイルに好きなファイル名を選択します。

バインドなしタスク・フローのソース・ファイルそれぞれに、バインドなしタスク・フローに追加したアクティビティのメタデータ、制御フロー・ルール、マネージドBeanが含まれ、エンド・ユーザーは、Fusion Webアプリケーションと連動してタスクを完了できます。

adfc-config.xmlファイルの有効なメタデータ・エントリを定義するXMLスキーマ定義ファイル(XSD)はadfc-config_1_0.xsdです。adfc-config_1_0.xsdファイルは、インストールしたJDeveloperの次のディレクトリにあるadf-controller-schema.jarファイルに格納されます。

jdev_install\oracle_common\modules\oracle.adf.model_12.1.2

JDeveloperのXSDビジュアル・エディタを使用してadfc-config_1_0.xsdファイルを表示します。このエディタを使用すると、adfc-config.xmlファイルの有効なメタデータ要素および属性を識別できます。

次の例は、ビュー・アクティビティ、制御フロー・ルールなどがまだ追加されていないバインドなしタスク・フローのソース・ファイルを示しています。

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
</adfc-config>

図A-4に、ADFタスク・フローのadfc-config.xmlファイルに対するSummitサンプル・アプリケーションのダイアグラム・ビューを示します。例A-3に、図A-4で表示したバインドなしタスク・フローの対応するソース表示を示します。

バインドなしタスク・フローの詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。

図A-4 Summit ADFタスク・フロー・サンプル・アプリケーションのadfc-config.xmlファイルのダイアグラム・ビュー

例A-3 Summit ADFタスク・フロー・サンプル・アプリケーションのadfc-config.xmlファイルのソース・ビュー

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
<view id="index">
<page>/index.jsf</page>
</view>
<managed-bean id="__1">
<managed-bean-name>login</managed-bean-name>
<managed-bean-class>oracle.summit.bean.LoginBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
<managed-bean id="__2">
<managed-bean-name>WelcomePageBean</managed-bean-name>
<managed-bean-class>oracle.summit.bean.WelcomePageBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
</adfc-config>

A.10 task-flow-definition.xml

作成した最初のADFバインド・タスク・フローのソース・ファイルに対してJDeveloperが提案するデフォルトのファイル名は、task-flow-definition.xmlです。このファイルにはバインド・タスク・フローのメタデータが格納されています。これには、バインド・タスク・フローに追加する、各ビュー・アクティビティ、メソッド・コール・アクティビティ、タスク・フロー・コールなどのエントリが含まれています。

JDeveloperは、作成する後続のバインド・タスク・フローに次のファイル名を提案します。

task-flow-definitionN.xml

ここでNは新しいバインド・タスク・フローを作成するたびに増分する番号です。または、バインド・タスク・フローのソース・ファイルに好きなファイル名を選択します。デフォルトでは、JDeveloperは、task-flow-definition.xmlファイルを次のディレクトリに格納します。

application_root\ViewController\Web Content\WEB-INF

バインド・タスク・フローのソース・ファイルの有効なメタデータ・エントリを定義するXMLスキーマ定義ファイル(XSD)は、インストールしたJDeveloperの次のディレクトリにあるadf-controller-schema.jarファイルに格納されます。

jdev_install\oracle_common\modules\oracle.adf.model_12.1.2

JDeveloperのXSDビジュアル・エディタを使用して、これらのファイルを表示し、バインド・タスク・フローのソース・ファイルの有効なメタデータ要素と属性を識別します。

次の例は、「タスク・フローの作成」ダイアログを使用して新しいバインド・タスク・フローを作成するときのソース・ファイルの内容を示しています。<task-flow-definition>要素によって、このファイルがバインド・タスク・フローとして識別されます。JDeveloperは、「タスク・フローの作成」ダイアログの「バインド・タスク・フローとして作成」チェック・ボックスを選択するときに<task-flow-definition>要素を生成します。<task-flow-definition>要素のid属性(task-flow-definition)の値は、「タスク・フローの作成」ダイアログの「タスク・フローID」フィールドに入力した値に対応します。<use-page-fragments/>要素は、このバインド・タスク・フローのすべてのビュー・アクティビティをページ・フラグメントと関連付ける必要があることを示しています。JDeveloperは、「タスク・フローの作成」ダイアログの「ページ・フラグメントを使用して作成」チェック・ボックスを選択するときにこのエントリを生成します。

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
<task-flow-definition id="task-flow-definition">
<use-page-fragments/>
</task-flow-definition>
</adfc-config>

例A-4に、Summit ADFタスク・フロー・サンプル・アプリケーションのcustomers-task-flow-definition.xmlファイルを示します。図A-5の「構造」ウィンドウに示すように、アクティビティのエントリを表示できます。

バインド・タスク・フローの詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。

図A-5 customers-task-flow-definition.xmlファイルの「構造」ビュー

例A-4 customers-task-flow-definition.xmlファイルの「ソース」ビュー

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
<task-flow-definition id="customer-task-flow-definition">
<default-activity id="__1">isCustomerLogin</default-activity>
<managed-bean id="__11">
<managed-bean-name id="__9">CustomersBackingBean</managed-bean-name>
<managed-bean-class id="__10">oracle.summit.backing.CustomersBackingBean</managed-bean-class>
<managed-bean-scope id="__8">backingBean</managed-bean-scope>
</managed-bean>
<view id="Customers">
<page>/customers/Customers.jsff</page>
</view>
<method-call id="SetCurrentRowWithKeyValue">
<method>#{bindings.setCurrentRowWithKeyValue.execute}</method>
<outcome>
<fixed-outcome>setCurrentRowWithKey</fixed-outcome>
</outcome>
</method-call>
<router id="isCustomerLogin">
<case id="__4">
<expression>#{securityContext.userInRole['Application Customer Role']}</expression>
<outcome>customerLogin</outcome>
</case>
<default-outcome>notCustomerLogin</default-outcome>
</router>
<control-flow-rule id="__2">
<from-activity-id>SetCurrentRowWithKeyValue</from-activity-id>
<control-flow-case id="__3">
<from-outcome>setCurrentRowWithKey</from-outcome>
<to-activity-id>Customers</to-activity-id>
</control-flow-case>
</control-flow-rule>
<control-flow-rule id="__5">
<from-activity-id>isCustomerLogin</from-activity-id>
<control-flow-case id="__6">
<from-outcome>notCustomerLogin</from-outcome>
<to-activity-id>Customers</to-activity-id>
</control-flow-case>
<control-flow-case id="__7">
<from-outcome>customerLogin</from-outcome>
<to-activity-id>SetCurrentRowWithKeyValue</to-activity-id>
</control-flow-case>
</control-flow-rule>
<critical/>
<use-page-fragments/>
</task-flow-definition>
</adfc-config>

A.11 adf-config.xml

ADF Fusion Webアプリケーション・テンプレートを使用してアプリケーションを作成すると、JDeveloperによってadf-config.xmlファイルが生成されます。JDeveloperは、アプリケーション・レベルのディスクリプタ・ファイルを次のディレクトリに格納します。

application_root\.adf\META-INF

JDeveloperでは、このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで「ディスクリプタ」→「ADF META-INF」ノードを開くと見つかります。

adf-config.xmlファイルは、デプロイ時に定義するアプリケーション・レベルの設定を指定します。デプロイメント・プロファイルを使用して、アプリケーションのデプロイ時に使用される設定を指定することができます。Oracle Enterprise Managerを使用して、実行時に一部の設定を変更できます。

adf-config.xmlファイルの設定を変更することによって実現できるタスクの例には、次のものが含まれます。

- ADFコントローラのメタデータの有効化および無効化

- クラスタ環境にFusion Webアプリケーションをデプロイする場合のメモリー・スコープのレプリケート

- アプリケーションがEL式を使用して実行時にリソース・バンドルから文字列を取得する場合にリソース・バンドルのキャッシュを管理するプロパティの構成
構成できるプロパティを次に示します。

- initial-size
アプリケーションがキャッシュできるリソース・バンドルの個数の初期値を指定します。デフォルト値は100です。

- max-size
アプリケーションがキャッシュできるリソース・バンドルの個数の最大値を指定します。デフォルト値は100です。

- load-factor
デフォルト値は0.75です。

- expire-time
デフォルト値は43200秒(12時間)です。

これらのプロパティは、adf-config.xmlファイルで<resource-bundle-cache>要素の属性値として指定できます。例A-5は、adf-config.xmlファイルで、アプリケーションに対するこれらの値を設定する方法を示しています。

adf-config.xmlファイルでリソース・バンドルのキャッシュを設定するかわりに、Java Virtual Machine (JVM)のパラメータとして、リソース・バンドルのキャッシュ・プロパティを指定できます。プロパティをJVMのパラメータとして指定した場合、JVMが管理しているアプリケーションすべてに変更が適用されます。このため、adf-config.xmlファイルで、アプリケーションのリソース・バンドルのキャッシュ・プロパティを構成することを検討してください。JVMのパラメータとしてリソース・バンドルのキャッシュ・プロパティを指定することに決めた場合は、次のプロパティ名を使用します。

- resource-bundle-cache-initial-size

- resource-bundle-cache-max-size

- resource-bundle-cache-load-factor

- resource-bundle-cache-expire-time

実行時、Fusion Webアプリケーションは、META-INFディレクトリからadf-config.xmlファイルをロードします。このFusion Webアプリケーションにより、複数のadf-config.xmlファイルが検出された場合、ファイルのロードは停止され、警告がログに記録されます。

次のタスクは、adf-config.xmlファイルが変更されるかこのファイルの変更が要求されます。

- ADFコントローラ・レイヤー内

- タスク・フローの作成
デフォルトでは、ADFコントローラはユーザー・セッション・レベルのキャッシュを使用して、アプリケーションのバインドなしタスク・フロー・メタデータを格納します。これにより、アプリケーションのバインドなしタスク・フロー・メタデータのユーザー固有のシード・カスタマイズまたは実行時のデザイン・タイムのカスタマイズがサポートされます。adf-config.xmlのファイル概要エディタの「コントローラ」ページで「バインドなしタスク・フロー・カスタマイズの許可」チェックボックスを選択解除してこの動作を無効にし、<allow-unbounded-task-flow-customizations>要素の値をfalseに設定します。アプリケーションのバインドなしタスク・フロー・メタデータも引き続きカスタマイズできます。ただし、これらのカスタマイズはアプリケーションのすべてのユーザーによって共有されます。カスタマイズの詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。タスク・フローの詳細は、「ADFタスク・フローのスタート・ガイド」を参照してください。

- root-view-port-request-lock-timeoutプロパティに対して整数値を構成します。この値は、リクエストがルート・ビュー・ポートのロックを保持できる秒数で、この値を超えるとタイムアウトして他のリクエストがロックを取得できるようになります。デフォルト値は600秒です。ルート・ビュー・ポートの詳細は、「ビュー・ポートおよびADFリージョンについて」を参照してください。

- <max-root-view-ports>プロパティの値を指定することで、アプリケーションのアクティブなルート・ビュー・ポート数を最小化します。詳細は、「アプリケーションでのアクティブなルート・ビュー・ポート数の最小化」を参照してください。

- 収集されるイベント数を変更するか、ADFコントローラによるイベントの収集を停止します。どちらのタスクにも、アプリケーションのadf-config.xmlファイル内の<debug-history-size>要素の値の構成が関係します。詳細は、「診断フレームワークへのインシデントのレポート」を参照してください。

- 明示的なセーブ・ポイントの有効化
詳細は、「暗黙的なセーブポイントを有効化する方法」を参照してください。

- セキュリティ権限を持たないリージョンでバインド・タスク・フローを起動しようとする場合は、起動のための認可を必要としないバインド・タスク・フローを指定します。詳細は、「未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理」を参照してください。

- ADFコントローラがADFメモリー・スコープの変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープとビュー・スコープをレプリケートできるようにします。アプリケーションのadf-config.xmlファイル内のADFコントローラ・パラメータ<adf-scope-ha-support>をtrueに設定する必要があります。詳細は、「マネージドBeanの変更からOracle ADFが通知を受信することを確認する方法」を参照してください。

- ADFモデル・レイヤー内

- アプリケーションのデフォルトの動作として、自動部分ページ・レンダリングを無効にします。これを行うには、changeEventPolicy属性の値をpprのデフォルト値から変更する必要があります。
<defaults changeEventPolicy="ppr"/>

詳細は、「部分ページ・レンダリングおよびイテレータ・バインディングに関する必知事項」を参照してください。

- ユーザー・インタフェース・プロジェクト内のすべての問合せコンポーネントを、バインド変数を使用して入力検索フィールドをレンダリングするように構成します。
詳細は、「検索フォームの名前付きバインド変数に関する必知事項」を参照してください。

- コンテキスト・イベントのディスパッチの制御
詳細は、「コンテキスト・イベント・ディスパッチの制御方法」を参照してください。

- MDSでの保存済の検索の永続化
詳細は、「保存済の検索をMDSに保存する方法」を参照してください。

- ADFアプリケーション・モジュールからのRESTful Webサービスの作成、およびRESTリソースのリリース・バージョン識別子の管理
詳細は、「アプリケーション・モジュールを使用したADF RESTリソースの作成」および「ADF RESTリソースのバージョニング」を参照してください。

- 「ADFビジネス・コンポーネント」グローバル設定の構成
詳細は、「ビュー・オブジェクトの最大フェッチ・レコード数を制限するためのフェッチ・サイズの使用方法」および「データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法」を参照してください。

- Oracle ADFセキュリティの有効化と無効化
詳細は、「ADFセキュリティの有効化」および「ADFセキュリティの無効化」を参照してください。

- シード・カスタマイズの有効化
詳細は、「ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法」および「既存のページでシード・カスタマイズを有効化する方法」を参照してください。

- 変更永続性の構成
詳細は、「ユーザー・カスタマイズを有効にする方法」を参照してください。

- ユーザー・カスタマイズの有効化
詳細は、「ユーザー・カスタマイズを有効化する場合の処理」を参照してください。

例A-5に、アプリケーションのadf-config.xmlファイルのエントリ例を示します。

例A-5 サンプルadf-config.xmlファイル

<?xml version="1.0" encoding="windows-1252" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:sec="http://xmlns.oracle.com/adf/security/config">
<sec:adf-security-child xmlns="http://xmlns.oracle.com/adf/security/config">
<CredentialStoreContext credentialStoreClass=
"oracle.adf.share.security.providers.jps.CSFCredentialStore"
credentialStoreLocation="../../src/META-INF/jps-config.xml"/>
<!-- The Configure ADF Security wizard modifies JaasSecurityContext settings -->
<JaasSecurityContext initialContextFactoryClass=
"oracle.adf.share.security.JAASInitialContextFactory"
jaasProviderClass=
"oracle.adf.share.security.providers.jps.JpsSecurityContext"
authorizationEnforce="true"
authenticationRequire="true"/>
</sec:adf-security-child>
<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
<savepoint-datasource>java:comp/env/jdbc/summit_adfDS</savepoint-datasource>
<enable-implicit-savepoints>true</enable-implicit-savepoints>
<unauthorized-region-taskflow>/WEB-INF/task-flow-definition.xml</unauthorized-region-taskflow>
</adf-controller-config>
<adf-faces-config xmlns="http://xmlns.oracle.com/adf/faces/config">
<persistent-change-manager>
<persistent-change-manager-class>
oracle.adf.view.rich.change.MDSDocumentChangeManager
</persistent-change-manager-class>
</persistent-change-manager>
<taglib-config>
<taglib uri="http://xmlns.oracle.com/adf/faces/rich">
<tag name="calendar">
<attribute name="activeDay">
<persist-changes>true</persist-changes>
</attribute>
</tag>
<!-- Additional tags omitted to make this example concise -->
<tag name="table">
<attribute name="filterVisible">
<persist-changes>true</persist-changes>
</attribute>
</tag>
</taglib>
</taglib-config>
</adf-faces-config>
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config xmlns="http://xmlns.oracle.com/mds/config" version="11.1.1.000">
<cust-config>
<match path="/">
<customization-class name="oracle.adf.share.config.UserCC"/>
</match>
</cust-config>
</mds-config>
</adf-mds-config>
<adf-adfm-config xmlns="http://xmlns.oracle.com/adfm/config">
<defaults rowLimit="100"/>
<startup>
<amconfig-overrides>
<config:Database jbo.SQLBuilder="Oracle" jbo.locking.mode="optimistic"/>
</amconfig-overrides>
</startup>
</adf-adfm-config>
<!-- Properties to manage the caching of a resource bundle in your application -->
<adf-resourcebundle-config xmlns="http://xmlns.oracle.com/adf/resourcebundle/config">
<applicationBundleName>
path-to-resource-bundle/bundle-name
</applicationBundleName>
<resource-bundle-cache initial-size="20" max-size="100" expire-time="30000" load-factor=".75"/>
<bundleList>
<bundleId override="true">
package.BundleID
</bundleId>
</bundleList>
</adf-resourcebundle-config>
</adf-config>

A.12 adf-settings.xml

adf-settings.xmlファイルには、プロジェクト・レベルおよびライブラリ・レベルの設定(ADF Facesヘルプ・プロバイダ、ADFコントローラ・フェーズ・リスナーなど)が保持されます。

adf-settings.xmlの構成設定は固定で、アプリケーション・デプロイメント時またはその後に変更できません。アプリケーションに複数のadf-settings.xmlファイルがあることがあります。それらの構成の内容をマージするのはadf-settings.xmlファイル・ユーザーの役目です。

JDeveloperは、次の場合にadf-settings.xmlファイルを作成します。

- ADF Fusion Webアプリケーション・テンプレートを使用してアプリケーションを作成するとき

- ADFページ・フロー(ADFコントローラ)を既存のプロジェクトに機能として追加するとき

デフォルトでは、JDeveloperは、adf-settings.xmlファイルを次のディレクトリに格納します。

application_root\ViewController\src\META-INF

次のタスクでは、adf-settings.xmlファイルが変更されるか、またはユーザーによるこのファイルの変更が要求されます。

- フェーズ・リスナーの登録
詳細は、「リスナーをグローバルに登録する方法」を参照してください。

- ADF Facesコンポーネントのヘルプの作成
詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のコンポーネントのヘルプの表示に関する項を参照してください。

adf-settings.xmlファイルの編集方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のadf-settings.xmlでのADF Facesの構成方法に関する項を参照してください。

例A-6に、フェーズ・リスナーおよびヘルプ・プロバイダ向けに設定されたadf-setting.xmlファイルのサンプルを示します。

例A-6 サンプルadf-settings.xmlファイル

<?xml version="1.0" encoding="windows-1252" ?>
<adf-settings xmlns="http://xmlns.oracle.com/adf/config">
<adfc-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
<lifecycle>
<phase-listener>
<listener-id>SummitPhaseListener</listener-id>
<class>oracle.summit.listeners.SummitPhaseListener</class>
</phase-listener>
</lifecycle>
</adfc-controller-config>
<adf-faces-config>
<help-provider prefix="MYAPP">
<help-provider-class>oracle.summit.MyHelpProvider</help-provider-class>
<property>
<property-name>myCustomProperty</property-name>
<value>someValue</value>
</property>
</help-provider>
</adf-faces-config>
</adf-settings>

A.13 web.xml

Oracle ADFには、標準のweb.xmlデプロイメント・ディスクリプタ・ファイルに固有の構成設定があります。

JDeveloperでJSFテクノロジを使用するプロジェクトを作成すると、デフォルト設定を含む初期のweb.xmlファイルが/WEB-INFに自動的に作成されます。ファイルを編集するには、「アプリケーション」ウィンドウでweb.xmlをダブルクリックし、XMLエディタで開きます。

次の設定は、JSFおよびADF Facesを使用するすべてのアプリケーションのweb.xmlで構成する必要があります。

- ADFライブラリ・リソース・サーブレットとマッピング: アプリケーション・クラス・パスのADFライブラリJARファイルのWebアプリケーション・リソース(イメージ、スタイル・シート、JavaScriptライブラリ)として動作します。
デフォルトでは、イメージなどの静的Webアプリケーション・リソース(ADFライブラリのリソースを含む)には、364日の失効期限設定があります。この失効期間設定では、次のイベントのいずれかが発生するまで、静的Webアプリケーション・リソースの検証をクライアントがサーバーにリクエストしないことが要求されます。

- 失効期限が切れる

- ブラウザ・キャッシュに静的リソースが含まれなくなる

- ユーザーがページ・リフレッシュを実行する

クライアントがサーバーにリクエストを行い、リソースが変更しなかった場合、サーバーは、本文なしでHTTP 304応答(変更なし)を返します。

初期化パラメータをweb.xmlファイルに追加して、ADFライブラリのすべての静的Webアプリケーション・リソースに対する失効期限設定364日をオーバーライドできます。次の例に、多くの例を使用してこれらの初期化パラメータを設定する方法を示します。

<!-- Expires all static resources in 30 days -->
<init-param>
<param-name>expires</param-name>
<param-value>60*60*24*30</param-value>
</init-param>

<!-- Expires static resources with the .js file extension in 1 day -->
<init-param>
<param-name>expires.js</param-name>
<param-value>60*60*24</param-value>
</init-param>

<!-- Turns off staleness setting. Use for testing -->
<init-param>
<param-name>expires</param-name>
<param-value>OFF</param-value>
</init-param>

次の例は、デフォルトのファイル拡張子を示しています。extensionsパラメータ値を構成して必要なファイル拡張子を含めることによって、ファイル拡張子を追加できます。ファイル拡張子の前後に「.」を付ける必要があることに注意してください。次の例に、キャッシュ制御の可視性を指定する方法も示します。

<!-- Specify file extensions for a number of different file formats -->
<init-param>
<param-name>extensions</param-name>
<param-value>.png.jpg.jpeg.gif.js.css.</param-value>
</init-param>

<!-- Specify visibility for cache control, for example -->
<init-param>
<param-name>visibility</param-name>
<param-value>Public</param-value>
</init-param>

- JSFのサーブレットとマッピング: JSFを使用してユーザー・インタフェースを構築するWebアプリケーションのリクエスト処理ライフサイクルを管理するサーブレットjavax.faces.webapp.FacesServlet。

- ADF Facesのフィルタとマッピング: AdfFacesContextオブジェクトを構成してADF Facesを適切に初期化するためのサーブレット・フィルタ。このフィルタでは、ファイル・アップロードも処理されます。

JSFのサーブレットとマッピングの構成設定は、JSFプロジェクトを最初に作成したときに、自動的に初期のweb.xmlファイルに追加されます。ADF Facesのフィルタとマッピング、およびリソース・サーブレットとマッピングの構成設定は、JSFページに最初にADF Facesコンポーネントを挿入したときに自動的に挿入されます。

詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の付録「ADF Facesの構成」を参照してください。

A.14 logging.xml

ADFロガーは診断ツールの一種で、アプリケーションのデバッグ時にJDeveloperでこのツールを使用して、実行時トレース・メッセージをキャプチャできます。このツールの使用を設定するには、logging.xmlファイルを編集します。

logging.xmlファイル、およびADF Loggerの使用の詳細は、「ADF Loggerの使用」を参照してください。

B Oracle ADFバインディング・プロパティ

この付録では、Oracle ADFアプリケーションで実行時にアクセスに使用できるADFバインディングのプロパティについて説明します。

表B-1は、実行時にADFバインディング・オブジェクトの値にアクセスするためのEL式で使用できるプロパティを示しています。プロパティは、アルファベット順に並んでいます。

表B-1 Oracle ADFバインディングのELプロパティ

実行時プロパティ

説明

イテレータ

アクション

属性

ボタン

リスト

表

ツリー

actionEnabled

かわりにoperationEnabledを使用してください。

該当なし

はい

該当なし

該当なし

該当なし

該当なし

該当なし

allRowsInRange

関連付けられたコレクションから現在行のセットの配列を戻します。RowSetIteratorオブジェクトでgetAllRowsInRange()をコールします。

はい

該当なし

該当なし

該当なし

該当なし

該当なし

該当なし

attributeDef

バインディングが関連付けられている最初の属性の属性定義を戻します。

該当なし

該当なし

はい

はい

はい

該当なし

該当なし

attributeDefs

バインディングが関連付けられているすべての属性の属性定義を戻します。

該当なし

該当なし

はい

はい

はい

該当なし

該当なし

attributeValue

コントロール・バインディングがバインドされている属性の現在行の値(書式設定されておらず、適切なJava型に型付けされた値)を戻します。

該当なし

該当なし

はい

はい

はい

該当なし

該当なし

attributeValues

順序付けられた配列においてバインディングが関連付けられるすべての属性の値を返します。コントロール・バインディングがバインドされている属性すべてについて、現在行の値(書式設定されておらず、適切なJava型に型付けされた値)の配列を戻します。

該当なし

該当なし

はい

はい

はい

該当なし

該当なし

bindings

ツリー・ノード・バインディングの行の下で公開される各セルまたは属性の新しいバインディングを戻します。

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

はい

children

ツリー・ノード・バインディングの子ノードを戻します。

該当なし

該当なし

該当なし

該当なし

該当なし

該当なし

はい

currentRow

イテレータにバインドされているアクション・バインディング(組込みナビゲーション・アクションなど)の現在行を戻します。

該当なし

はい

該当なし

該当なし

該当なし

該当なし

該当なし

dataControl

イテレータの関連データ・プロバイダを戻します。

はい

該当なし

該当なし

該当なし

該当なし

該当なし

該当なし

displayData

マップ要素のリストを戻します。各マップ・エントリには、次の要素が含まれます。

- selected: 現在のエントリが選択されている場合はブール値のtrue

- index: 現在のエントリの索引値

- prompt: UIにエントリをレンダリングするために使用できる文字列値

- displayValues: リスト・バインディングのすべての表示属性に対応する表示属性値の順序付けられたリスト

該当なし

該当なし

該当なし

該当なし

はい

該当なし

該当なし

displayHint

バインディングが関連付けられている最初の属性の表示ヒントを戻します。ヒントには、属性を表示する必要があるかどうかが指定されています。詳細は、oracle.jbo.AttributeHints.displayHintを参照してください。

該当なし

該当なし

該当なし

該当なし

はい

該当なし

該当なし

displayHints

バインディングが関連付けられているすべての表示属性について、UIヒントの名前/値ペアのリストを戻します。マップには、次の要素が含まれます。

- label: 現在の属性に表示されるラベル

- tooltip: 現在の属性に表示されるツールチップ

- displayHint: 現在の属性の表示ヒント

- displayHeight: 現在の属性の高さ(行数)

- displayWidth: 現在の属性の幅(文字数)

- controlType: 現在の属性のコントロール・タイプ・ヒント

- format: 現在の属性に使用される書式

該当なし

該当なし

該当なし

はい

はい

該当なし

該当なし

enabled

operationEnabledプロパティを使用します。

該当なし

該当なし

該当なし

該当なし

該当なし

該当なし

該当なし

enabledString

アクション・バインディングの起動準備が整っていない場合、disabledを戻します。存在しない場合は、空の文字列("")を返します。

該当なし

はい

該当なし

該当なし

該当なし

該当なし

該当なし

error

値バインディングの関連属性値の更新時に、または操作バインディングによってバインドされている操作の起動時にキャッシュされた例外を戻します。

はい

はい

はい

はい

はい

はい

はい

estimatedRowCount

このイテレータ・バインディングが関連付けられているコレクションの最大行数を戻します。

はい

該当なし

該当なし

該当なし

該当なし

はい

はい

findMode

イテレータが現在検索モードで動作している場合、trueを戻します。それ以外の場合はfalseを戻します。

はい

該当なし

該当なし

該当なし

該当なし

該当なし

該当なし

fullName

Oracle ADFバインディング・コンテキスト内のバインディング・オブジェクトの完全修飾名を戻します。

はい

はい

はい

はい

はい

はい

はい

hints

バインディングに対して示されるUIヒントの値を戻します。UIヒント・キーワードのリストについてはdisplayHintsを参照してください。

はい

はい

はい

はい

はい

はい

はい

inputValue

バインディングが関連付けられている最初の属性の値を戻します。バインディングが属性に値を設定するために使用されていて、設定操作が失敗した場合、このメソッドは設定されようとしていた無効な値を戻します。

該当なし

該当なし

はい

はい

はい

はい

はい

iteratorBinding

データ・コレクションへのアクセスを提供するイテレータ・バインディングを戻します。

該当なし

はい

はい

はい

はい

はい

はい

label

バインディングの最初の属性のラベルを戻します(コントロール・ヒントで指定されている場合)。

該当なし

該当なし

はい

はい

はい

該当なし

該当なし

labels

バインディングが関連付けられているすべての属性の属性名によってキー設定されたラベルのマップを戻します(コントロール・ヒントで指定されている場合)。

該当なし

該当なし

はい

はい

はい

はい

該当なし

labelSet

バインディングが関連付けられているすべての属性について、順序付けられたラベルのセットを戻します。

該当なし

該当なし

はい

はい

はい

はい

該当なし

mandatory

バインディングが関連付けられている最初の属性が必須であるかどうかを戻します。

該当なし

該当なし

はい

はい

はい

該当なし

該当なし

name

バインディング・オブジェクトが登録されているバインディング・コンテナのコンテキスト内でのバインディング・オブジェクトの名前を戻します。このプロパティは、EL式ビルダー・ダイアログには表示されません。

はい

はい

はい

はい

はい

はい

はい

operationEnabled

アクション・バインディングの状態に応じて、trueまたはfalseを戻します。たとえば、アクション・バインディングは、ユーザーが「先頭へ」、「次へ」、「前へ」、「最後へ」などのナビゲーション・ボタンをクリックした場合に決定される現在位置に基づいて、有効化(true)または無効化(false)されます。

該当なし

はい

該当なし

該当なし

該当なし

該当なし

該当なし

rangeSet

関連付けられたイテレータ・バインディングの行のレンジに対応するマップ要素のリストを戻します。このリスト内の要素は、レンジ内の索引付けされた行に対するラッパー・オブジェクトで、バインディングがバインドされている属性にアクセスを制限します。参照オブジェクトに対して戻されるプロパティは次のとおりです。

- index: この参照が指し示している行のレンジ索引。

- key: この参照が指す行のキー。

- keyStr: この参照が指し示している行のキーのString形式。

- currencyString: 現在の索引付きの行(文字列)。現在のエントリが現在の行に属する場合には"*"を、そうでない場合には" "を戻します。このプロパティは、JSPアプリケーションで現在の行を表示する場合に便利です。

- attributeValues: 行の適用可能な属性値の配列。

また、rangeSet.dnameのように、レンジ・セットに対して名前で属性値にアクセスすることもできます(dnameがレンジ・バインディング内のバインドされた属性の場合)。

該当なし

該当なし

該当なし

該当なし

該当なし

はい

はい

rangeSize

ADFイテレータ・バインディングの行セットのレンジ・サイズを戻します。これにより、データソースからバインドされるデータ・オブジェクトの数を確認できます。

はい

該当なし

該当なし

該当なし

該当なし

はい

はい

rangeStart

レンジに含まれる最初の行のコレクションの絶対索引を戻します。oracle.jbo.RowSetIterator.getRangeStart()のjavadocを参照してください。

はい

該当なし

該当なし

該当なし

該当なし

はい

はい

result

メソッド・アクション・バインディングによりバインドおよび起動されるメソッドの結果を戻します。

該当なし

はい

該当なし

該当なし

該当なし

該当なし

該当なし

rootNodeBinding

ツリー・バインディングのルート・ノードを戻します。

該当なし

該当なし

該当なし

該当なし

該当なし

該当なし

はい

selectedValue

リストまたはボタン・バインディングで現在選択されている索引に対応する値を戻します。

該当なし

該当なし

該当なし

はい

はい

該当なし

該当なし

tooltip

バインディングが関連付けられている最初の属性のツールチップ・ヒントを戻します。

該当なし

該当なし

はい

はい

はい

該当なし

該当なし

updateable

バインディングが関連付けられている最初の属性が更新可能である場合、trueを戻します。それ以外の場合はfalseを戻します。

該当なし

該当なし

はい

はい

はい

該当なし

該当なし

C ADFセキュリティ権限の付与

この付録では、Oracle ADFのセキュリティ対応コンポーネントと、そのPermission実装クラスが定義するアクションをリストします。

表C-1にADFコンポーネント、およびADFセキュリティ・ポリシーを作成するために定義できる権限を示します。権限をポリシー・ストアに追加するには、ADFセキュリティ・ポリシーの概要エディタを使用します。権限により、完全修飾Permissionクラス名、完全修飾リソース名、リソースに対して実行できるアクション、および権限のアプリケーション・ロール・ターゲットが指定されます。ADFセキュリティによって、ポリシー・ストアのセキュリティ・ポリシーに対する認可チェックを施行できるようにすると、アプリケーション・ロールに付与される権限で定義されるような十分なアクセス権を持たないユーザーは、ADFコンポーネントでサポートされる操作にアクセスできなくなります。

Fusion WebアプリケーションにおけるADFセキュリティ・ポリシーの定義の詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

注意:

JDeveloperは、Oracle WebCenter Portal: Frameworkのアクションを含め、Fusion Webアプリケーションに付与可能なアクションを表示します。WebCenter Portal: Frameworkは、パーソナライズ可能なWebページの作成をサポートします。WebCenter Portal: Frameworkアプリケーションの保護の詳細は、Oracle JDeveloperによるWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

表C-1 ADFセキュリティ権限の付与

ADFコンポーネント

許可できるアクション

対応する実装

ADFバインド・タスク・フロー

View

Viewアクションは、バインド・タスク・フローを読込み、実行できるユーザーを制御します。バインド・タスク・フローの実行仮定でユーザーがアクセスするページのセキュリティが個別にチェックされることはありません。また、これらのページはタスク・フローの許可を受けて実行されます。

Oracle WebCenter Portal: Frameworkなしに、Fusion Webアプリケーションによりサポートされているタスク・フロー・アクションは、このリリースではこれだけです。

ADFバインド・タスク・フロー

Customize

将来の使用のために予約されています。このアクションは実行時にチェックされません。

ADFバインド・タスク・フロー

Grant

将来の使用のために予約されています。このアクションは実行時にチェックされません。

ADFバインド・タスク・フロー

Personalize

将来の使用のために予約されています。このアクションは実行時にチェックされません。

ADFページ定義

View

Viewアクションは、ページを表示できるユーザーを制御します。バインドなしタスク・フローの過程で関連するページ定義バインディング・ファイルを持つページへのアクセスが行われた場合のみ、このページに対するページレベルのセキュリティがチェックされます。ページ定義ファイルとそれがセキュリティ保護するWebページの間には1対1の関係があります。

Oracle WebCenter Portal: Frameworkなしに、Fusion Webアプリケーションによりサポートされているページ定義アクションは、このリリースではこれだけです。

ADFページ定義

Customize

customizeアクションは、カスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できるもの)のページやWebCenter Portal: Frameworkアプリケーションに含まれるWebCenter Portalのカスタマイズ可能なコンポーネント(Panel CustomizableやShow Detail Frameなど)を明示的に変更(最小化/リストア、削除、移動など)できるユーザーを制御します。

ADFページ定義

Edit

editアクションは、Oracle WebCenter PortalのComposerを呼び出すことができるユーザー、およびOracle WebCenter PortalのComposerを使用してページを変更できるユーザーを制御します。さらに、このアクションはpersonalizeアクションとcustomizeアクションを組み合せます。つまり、editアクションは、edit権限を与えられたページに含まれるWebCenter Portalのカスタマイズ可能なコンポーネント(Panel CustomizableやShow Detail Frameなど)を明示的に変更できるユーザーも定義します。

ADFページ定義

Grant

grantアクションは、Oracle WebCenter Portal: Framework固有のアクションをすべて組み合せることにより表される権限を付与します。つまり、その他のアクションすべてを付与することに相当します。他のユーザーに権限を付与できるユーザーや、Oracle WebCenter PortalのComposerを使用してページのセキュリティ設定を変更できるユーザーも制御します。

ADFページ定義

Personalize

personalizeアクションは、カスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できるもの)のページやWebCenter Portal: Frameworkアプリケーションに含まれるWebCenter Portalのカスタマイズ可能なコンポーネント(Panel CustomizableやShow Detail Frameなど)を明示的に変更(最小化/リストア、削除、移動など)できるユーザーを制御します。

ADFビジネス・コンポーネント・エンティティ・オブジェクト

read

readアクションは、バインドされたコレクションの行を表示できるユーザーを制御します。

ADFビジネス・コンポーネント・エンティティ・オブジェクト

update

updateアクションは、バインドされたコレクションの任意の属性を更新できるユーザーを制御します。

ADFビジネス・コンポーネント・エンティティ・オブジェクト

delete

deleteアクションは、バインドされたコレクションから行を削除できるユーザーを制御します。このアクションは、エンティティ・オブジェクトremoveCurrentRow操作に対応します。

エンティティ・オブジェクトのADFビジネス・コンポーネント属性

update

updateアクションは、バインドされたコレクションの特定の属性を更新できるユーザーを制御します。

D ADFビジネス・コンポーネントのよく使用されるメソッド

この付録では、Oracle ADFのADFビジネス・コンポーネント・レイヤーのインタフェースおよびクラスでよく使用されるメソッドをリストします。

この付録の内容は次のとおりです。

- フレームワーク・ベース・クラスの独自のレイヤーを作成するメソッド

- クライアント層で使用されるメソッド

- ビジネス・サービス層で使用されるメソッド

D.1 フレームワーク・ベース・クラスの独自のレイヤーを作成するメソッド

アプリケーションに固有なビジネス・コンポーネントの開発を開始する前に、この付録で解説されているADFビジネス・コンポーネント・フレームワーク実装のベース・クラスをすべて拡張するクラスから構成される層を独自に作成してください。アプリケーション・モジュール・コンポーネントのカスタムのフレームワーク・ベース・クラスの例を、次に示します。

package com.yourcompany.adfextensions;
import oracle.jbo.server.ApplicationModuleImpl;
public class CustomApplicationModuleImpl extends ApplicationModuleImpl {
/*
* We might not yet have any custom code to put here yet, but
* the first time we need to add a generic feature that all of
* our company's application modules need, we will be very happy
* that we thought ahead to leave ourselves a convenient place
* in our class hierarchy to add it so that all of the application
* modules we have created will instantly benefit by that new feature,
* behavior change, or even perhaps, bug workaround.
*/
}

ユーザーが選択したパッケージ名(com.yourcompany.adfextensionsなど)の、カスタマイズされたフレームワーク・ベース・クラスの共通セット(それぞれがoracle.jbo.server.*パッケージをインポート)は、次のクラスで構成されます。

- public class CustomEntityImpl extends EntityImpl

- public class CustomEntityDefImpl extends EntityDefImpl

- public class CustomViewObjectImpl extends ViewObjectImpl

- public class CustomViewRowImpl extends ViewRowImpl

- public class CustomApplicationModuleImpl extends ApplicationModuleImpl

- public class CustomDBTransactionImpl extends DBTransactionImpl2

- public class CustomDatabaseTransactionFactory extends DatabaseTransactionFactory

完全を期すために、次のクラスにカスタマイズされたフレームワーク・クラスを作成することもできます。

- public class CustomViewDefImpl extends ViewDefImpl

- public class CustomEntityCache extends EntityCache

- public class CustomApplicationModuleDefImpl extends ApplicationModuleDefImpl

これらのクラスでのオーバーライドは、かなりまれな要件です。

D.2 クライアント層で使用されるメソッド

この項で説明するインタフェースはすべて、クライアント層で使用するためにメソッドを公開できるように設計されています。これらのインタフェース・メソッドは、oracle.jbo.*パッケージの一部です。

この項では、ADFビジネス・コンポーネントの主要なインタフェースでコール、記述およびオーバーライドの対象としてよく使用されるメソッドのサマリーを示します。

注意:

これらのoracle.jbo.*インタフェースに対応する実装クラスは、クライアント・コードによって直接アクセスされないように、意図的に設計されています。「ビジネス・サービス層で使用されるメソッド」では、該当する実装クラスはoracle.jbo.server.*パッケージの中に存在し、クライアント層コードで使用しないようユーザーの注意を喚起するため、一般にImplという接尾辞が名前に付いていることが示されています。

D.2.1 ApplicationModuleインタフェース

アプリケーション・モジュールはビジネス・サービス・コンポーネントの1つで、その他のADFコンポーネントのトランザクション・コンテナとして機能し、これらと密接に連携して、ビジネス・アプリケーション開発者にとって重要な多数のJava EE設計パターンを実装します。それらのデザイン・パターンの実装により、クライアント・コードは、クライアントに必要なデータのみを取得してクライアントが望む方法で表示するFast Lane ReaderのSQL問合せに基づいて、更新可能な一連の値オブジェクトと簡単に連携できます。それらの値オブジェクトに行われた変更は、ビジネス・サービス層内の永続的なビジネス・ドメイン・オブジェクトと自動的に協調して、ビジネス・ルールを首尾一貫して施行し、データベースに変更を保存します。表D-1は、ApplicationModuleインタフェースを使用して、アプリケーション・モジュールで実行できる操作を説明しています。

注意:

ADFビジネス・コンポーネントによって実装されるデザイン・パターンの完全なリストは、「ADFビジネス・コンポーネントJava EEデザイン・パターン・カタログ」を参照してください。

表D-1 ApplicationModuleインタフェース

実行する処理

コールするApplicationModuleインタフェースのメソッド

割当て済インスタンス名(MyVOInstanceNameなど)を使用して既存のビュー・オブジェクト・インスタンスにアクセス

findViewObject()

既存の定義を使用して新しいビュー・オブジェクト・インスタンスを作成

createViewObject()

SQL文を使用して新しいビュー・オブジェクト・インスタンスを作成

createViewObjectFromQueryStmt()

注意:

動的問合せのSELECTリストの形を規定するために、実行時にオーバーヘッドが発生します。このメソッドは、問合せのSELECTリストが設計時に不明な場合にのみ使用してください。また、なんらかの種類のカスタムのランタイム・リポジトリに基づいて動的問合せを作成する場合は、この手順に従うことで、ランタイムの規定に関するオーバーヘッドなしで動的ビュー・オブジェクト(読取り専用および更新可能)を作成できます(「複数の更新可能エンティティによるビュー・オブジェクトの作成」を参照)。WHEREのみを動的にする必要がある場合は、ビュー・オブジェクトを設計時に作成し、ViewObject APIを使用して必要に応じてWHERE句を動的に設定します。

ネストしたアプリケーション・モジュール・インスタンスに名前でアクセス

findApplicationModule()

既存の定義を使用して、ネストした新しいアプリケーション・モジュール・インスタンスを作成

createApplicationModule()

ドット表記法の名前(MyNestedAMInstanceName.OneOfItsVONamesなど)を使用してネストしたアプリケーション・モジュール内でビュー・オブジェクト・インスタンスを検索

findViewObject()

注意:

このメソッドを使用して1つのメソッド・コールで、ネストしたアプリケーション・モジュールに属するビュー・オブジェクトのインスタンスを検索できます。これにより、まず、findApplicationModule()をコールしてネストしたアプリケーション・モジュールを検索し、その後、そのネストしたアプリケーション・モジュールでfindViewObject()をコールする必要がなくなります。

現在のトランザクション・オブジェクトにアクセス

getTransaction()

アプリケーション・モジュールによる汎用的なアクセスに加えて、JDeveloperでは、クライアントに公開することを選択したサービスレベルのカスタム・メソッドが含まれるカスタムなYourApplicationModuleNameインタフェースも生成できます。クライアント・インスタンスに表示するメソッドを選択するには、「アプリケーション・モジュールの編集」ダイアログの「クライアント・インタフェース」ページを使用します。

D.2.2 Transactionインタフェース

Transactionインタフェースでは、現在のトランザクション内で保留中の変更をクライアントが管理できるようなメソッドを公開しています。表D-2は、Transactionインタフェースを使用して、トランザクションで実行できる操作を説明しています。

表D-2 Transactionインタフェース

実行する処理

コールするTransactionインタフェースのメソッド

保留中の変更をコミット

commit()

保留中の変更のロールバック

rollback()

1回かぎりのデータベース・コマンドまたはPL/SQLブロックを実行

executeCommand()

注意:

OUTパラメータの取得が必要なメソッド、および複数回実行されるメソッド、またはバインド変数の使用が有効なメソッドでは、このコマンドを使用しないでください。その場合は、アプリケーション・モジュールでカスタム・メソッドを公開してください。

トランザクション内のすべての保留中の無効な変更を検証

validate()

デフォルトのロック・モードを変更

setLockingMode()

注意:

構成内のロック・モードは、プロパティjbo.locking.modeに、サポートされている4つの値(none、optimistic、pessimistic、optupdate)のいずれか1つを設定すると、設定できます。ロック・モードを明示的に設定していない場合、デフォルトでoptimisticになります。Fusion Webアプリケーションの場合は、optimisticモードまたはoptupdateモードを使用します。

バンドルされている例外レポート・モードを使用するかどうかを決定

setBundledExceptionMode()

注意:

ADFコントローラ・レイヤー・サポートでは、Fusion Webアプリケーションの場合、このパラメータは自動的にtrueに設定されます。

トランザクションのコミットに成功した場合にエンティティ・キャッシュを消去するかどうかを決定

setClearCacheOnCommit()

注意:

デフォルトはfalseです。

トランザクションのロールバック時にエンティティ・キャッシュを消去するかどうかを決定

setClearCacheOnRollback()

注意:

デフォルトはtrueです。

特定のエンティティ・オブジェクトのエンティティ・キャッシュを消去

clearEntityCache()

D.2.3 ViewObjectインタフェース

ビュー・オブジェクトは、データベース問合せをカプセル化し、この問合せから得られる結果の行セットを使った作業を簡略化するコンポーネントです。ビュー・オブジェクトは、SQLを使用して1つ以上の表からビジネス・データを投影、フィルタ、結合、またはソートして、ユーザーがページやパネルに表示できる形式にデータをキャストするために使用します。ビュー・リンクを使用して、複数のビュー・オブジェクトを接続し、任意の深さや複雑さの「マスター/ディテール」階層を作成できます。ビュー・オブジェクトからは、読取り専用の問合せ結果が得られます。また、設計時に1つ以上のエンティティ・オブジェクトと関連付けられている場合、ビュー・オブジェクトは完全に更新可能です。更新可能なビュー・オブジェクトは、適切なビジネス・ドメインへの自動委譲を使用して、結果コレクションでの行の挿入、変更および削除をサポートできます。

ビュー・オブジェクトの問合せ結果の行セットは1つだけというケースがユースケースの90パーセントを占めますが、このようなケースを単純化するために、ビュー・オブジェクトには必ず「デフォルト行セット」が含まれています。ビュー・オブジェクトは、すべてのメソッドをこのデフォルトRowSetに委譲することにより、RowSetインタフェースに実装します。つまり、どのビュー・オブジェクトでも、任意のRowSetメソッドを呼び出すことができます。

すべてのビュー・オブジェクトは、StructureDefインタフェースを実装し、行セット内の各行の属性の数とタイプに関する情報を提供します。したがって、どのビュー・オブジェクトでも、StructureDefメソッドを直接コールできます。

表D-3は、ViewObjectインタフェースを使用して、ビュー・オブジェクトで実行できる操作を説明しています。

表D-3 ViewObjectインタフェース

実行する処理

コールするViewObjectインタフェースのメソッド

行セット上で追加のランタイムWHERE句を設定

setWhereClause()

注意:

このWHEREは、基本ビュー・オブジェクト内で設計時に指定されたWHERE句をさらに増やします。置換ではありません。

動的なORDER BY句を設定

setOrderByClause()

Query-by-Example基準コレクションを作成

createViewCriteria()

注意:

その後、作成したViewCriteriaオブジェクト上でcreateViewCriteriaRow()メソッドを使用し、ViewCriteriaRowオブジェクトを1つまたは複数作成します。その後、add()を使用してそれらのビュー基準行をビュー基準コレクションに追加し、applyViewCriteria()メソッドを使用してその基準を適用します。

Query-by-Example基準コレクションを適用

applyViewCriteria()

問合せオプティマイザ・ヒントを設定

setQueryOptimizerHint()

ビュー・オブジェクト内のキー属性の属性定義にアクセス

getKeyAttributeDefs()

該当するビュー・オブジェクトの行セット内の行に動的属性を追加

addDynamicAttribute()

ビュー・オブジェクトによって作成された行セットをすべて消去

clearCache()

ビュー・オブジェクト・インスタンスとそのリソースを削除

remove()

ビュー・オブジェクトがデータベースからフェッチしようとする行数に上限を設定

setMaxFetchSize()

注意:

デフォルト値は-1です。この場合、データベースから取得する行数(すべて反復処理する場合)に制限はありません。デフォルトでは、それらの行は、ユーザーが反復処理を実行するのに伴って遅延フェッチされます。

ViewObjectによる汎用的なアクセスのみでなく、JDeveloperでは、ユーザーがクライアントに公開することを選択したビュー・オブジェクトレベルのカスタム・メソッドが含まれるカスタムなYourViewObjectNameインタフェースも生成できます。クライアント・インスタンスに表示するメソッドを選択するには、「ビュー・オブジェクトの編集」ダイアログの「クライアント・インタフェース」ページを使用します。

D.2.4 RowSetインタフェース

行セットは、通常はビュー・オブジェクトの問合せに実行によって作成される一連の行を含むオブジェクトです。

行セットに対して必要なイテレータは1つのみというケースがユースケースの90パーセントを占めますが、このようなケースを単純化するために、RowSetにより必ず「デフォルトの行セット・イテレータ」が集計されます。RowSetオブジェクトは、すべてのメソッドをこのデフォルトRowSetIteratorに委譲することにより、RowSetIteratorインタフェースに実装します。つまり、どのRowSetオブジェクト(または、ビュー・オブジェクト。ビュー・オブジェクトはデフォルトのRowSetに対してもRowSetを実装するため)でも、任意のRowSetIteratorメソッドを呼び出すことができます。

表D-4は、RowSetインタフェースを使用して、行セットで実行できる操作を説明しています。

表D-4 RowSetインタフェース

実行する処理

コールするRowSetインタフェースのメソッド

WHERE句のバインド変数値を設定

setWhereClauseParams()

注意:

バインド変数の序数位置はゼロ・ベースです。

データが一度しか読み取られない場合はビュー・オブジェクト行のキャッシングを回避

setForwardOnly()

強制的に行セットの問合せを実行(排他的ビュー・オブジェクト・インスタンスの場合)、または実行する可能性がある(共有ビュー・オブジェクト・インスタンスの場合)

executeQuery()

注意:

このメソッドの動作は、ビュー・オブジェクトが共有アプリケーション・モジュールに属しているかどうかによって異なります。共有モジュールのインスタンスではなく、排他的ビュー・オブジェクトに対する問合せを再度実行すると、新しい問合せコレクションが作成されます。共有ビュー・オブジェクト・インスタンスの問合せを実行する前に、結果セットがすでに存在しないかどうかを判断するためのチェックが行われます。この共有ビュー・オブジェクト・インスタンスについて、すでにキャッシュされている結果があれば、問合せを再実行するのではなく、この結果が再使用されます。共有ビュー・オブジェクト・インスタンスの結果を確実にリフレッシュする必要がある場合は、forceExecuteQueryOfSharedVO()メソッドを呼び出します。ただし、強制実行を呼び出したときに、ユーザーが共有ビュー・オブジェクト・インスタンスのコレクションを反復していた場合の動作は不確定で、例外が発生する可能性があります。

ビュー・オブジェクトの問合せ結果の行数を推定

getEstimatedRowCount()

ビュー・オブジェクト行セット内の行に対してXML文書を作成

writeXML()

受信XML文書内の全行を処理

readXML()

他の行セットによって作成された同じエンティティ・オブジェクトに基づいて、行セットが新規行を自動的に確認するかどうかを設定

setAssociationConsistent()

プログラムによる反復で使用するセカンダリ・イテレータを作成

createRowSetIterator()

注意:

後で名前を使用してセカンダリ・イテレータを検出し、使用する場合は、文字列名を引数として渡します。そうでない場合は、nullを名前として渡し、反復処理の終了時はイテレータのcloseRowSetIterator()メソッドをコールしてイテレータを閉じてください。

D.2.5 RowSetIteratorインタフェース

行セット・イテレータは、行セット内の行を反復処理するイテレータです。デフォルトでは、行の反復処理を順方向にも逆方向にも実行できます。表D-5は、RowSetIteratorインタフェースを使用して、行セットで実行できる操作を説明しています。

表D-5 RowSetIteratorインタフェース

実行する処理

コールするRowSetIteratorインタフェースのメソッド

イテレータの行セットの先頭行を取得

first()

反復処理の対象となる行がまだ存在しているかどうかをテスト

hasNext()

イテレータの行セットの次の行を取得

next()

指定したキー値を持つ行をこのイテレータの行セット内で検索

findByKey()

注意:

findByKeyに渡すKeyオブジェクトを作成するときは、操作しているビュー・オブジェクト内の行のキーを構成する属性とまったく同じデータ型を使用することが重要です。

挿入目的で移入する新しい行を作成

createRow()

注意:

該当する新しい行は、エンティティ・オブジェクトまたはビュー・オブジェクトのレベルで提供されている静的なデフォルト値を持つ属性の場合、または基礎となるエンティティ・オブジェクトのオーバーライドされたcreate()メソッドで値が移入済の場合、デフォルト値がすでに設定されています。

外部キーまたは識別子(あるいはその両方)の属性値の初期セットを使用してビュー行を作成

createAndInitRow()

注意:

このメソッドは、エンティティ・オブジェクトの一連のサブタイプから構成されるファミリの1つを返すことができるビュー・オブジェクトを使用する場合に使用します。行を作成するためのコールで正確な識別子属性値を渡すことにより、フレームワークは合致するエンティティ・オブジェクトの正しいサブタイプを下に作成することができます。

イテレータの行セットに新しい行を1行挿入

insertRow()

注意:

新しく作成した行を、常に行セットにただちに挿入するようにしてください。それにより、行を作成したものの、行セットに挿入し忘れるという間違いをなくすことができます。

イテレータの行セットの最終行を取得

last()

イテレータの行セットの直前の行を取得

previous()

現在の行ポインタを先頭行の前のスロットにリセット

reset()

反復処理の実行時にイテレータを終了

closeRowSetIterator()

指定した行を現在の行に設定

setCurrentRow()

現在の行を削除

removeCurrentRow()

現在の行を後で同一イテレータ内の別の場所に挿入するために削除

removeCurrentRowAndRetain()

現在の行を現在のコレクションから削除(ただし、トランザクションからは削除しない)

removeCurrentRowFromCollection()

範囲(ユーザーが表示できるページ)当たりの行数を設定/変更

setRangeSize()

スクロールしてnページ(先頭は1)目の行を表示

scrollToRangePage()

スクロールして、行番号nから始まる行範囲を表示

scrollRangeTo()

範囲内の行番号nを現在の行に設定

setCurrentRowAtRangeIndex()

範囲内の全行をRow配列として取得

getAllRowsInRange()

D.2.6 Rowインタフェース

Rowは、汎用的な値オブジェクトです。それに含まれる属性は、関連先ビュー・オブジェクトの名前およびJavaタイプに適しています。表D-6は、Rowインタフェースを使用して、ビュー・オブジェクト行で実行できる操作を説明しています。

表D-6 Rowインタフェース

実行する処理

コールするRowインタフェースのメソッド

名前を使用して属性の値を取得

getAttribute()

名前を使用して属性の値を設定

setAttribute()

単一行のXML文書を作成

writeXML()

行の検証を積極的に実行

validate()

XMLからの行の属性値の読取り

readXML()

行を削除

remove()

新しく作成した行への一時的としてのフラグ付け(再度更新されるまで)

setNewRowState(Row.STATUS_INITIALIZED)

行の属性構造の定義情報を取得

getStructureDef()

行のKeyオブジェクトを取得

getKey()

Rowによる汎用的なアクセスのみでなく、JDeveloperでは、型保証属性のgetterメソッドおよびsetterメソッドに加えて、ユーザーがクライアントに公開することを選択した望ましい行レベルのカスタム・メソッドも含まれるカスタムなYourViewObjectNameRowインタフェースも生成できます。クライアント・インスタンスに表示するメソッドを選択するには、「ビュー・オブジェクトの編集」ダイアログの「カスタム行インタフェース」ページを使用します。

D.2.7 StructureDefインタフェース

StructureDefは、Rowオブジェクトの構造に関する実行時メタデータにアクセスするためのインタフェースです。

また便宜上、各ビュー・オブジェクトは、StructureDefインタフェースも実装しており、一連の属性に関するメタデータへのアクセスを、問合せによって生成されるビュー行によって提供します。

表D-7は、StructureDefインタフェースを使用して、ビュー・オブジェクト行で実行できる操作を説明しています。

表D-7 StructureDefインタフェース

実行する処理

コールするStructureDefインタフェースのメソッド

ビュー・オブジェクト行内の全属性の属性定義にアクセス

getAttributeDefs()

名前を使用して属性定義を検出

findAttributeDef()

索引を使用して属性定義を取得

getAttributeDef()

1行内の属性数を取得

getAttributeCount()

D.2.8 AttributeDefインタフェース

AttributeDefインタフェースが提供する属性定義情報は、属性名、Javaタイプ、SQLタイプのような、ビュー・オブジェクト行またはエンティティ・オブジェクト・インスタンス用属性のためのものです。また、ユーザーが記述する汎用コードによってインスペクトできるカスタム属性固有のメタデータ・プロパティや、属性およびその値を適切なユーザー・インタフェースに表示する際に役立つUIヒントへのアクセスも提供されます。表D-8は、AttributeDefインタフェースを使用して、属性で実行できる操作を説明しています。

表D-8 AttributeDefインタフェース

実行する処理

コールするAttributeDefインタフェースのメソッド

属性のJavaタイプを取得

getJavaType()

属性のSQLタイプを取得

getSQLType()

注意:

int値は、JDBCクラスjava.sql.Types内の定数に対応しています。

属性の種類を特定

getAttributeKind()

注意:

簡単な属性とは、定数ATTR_PERSISTENT、ATTR_SQL_DERIVED、ATTR_TRANSIENT、ATTR_DYNAMIC、ATTR_ENTITY_DERIVEDのいずれか1つを戻す属性です。属性が、1対1または多対1のアソシエーション/ビュー・リンク・アクセッサである場合、ATTR_ASSOCIATED_ROWが返されます。属性が、1対多または多対多のアソシエーション/ビュー・リンク・アクセッサである場合は、ATTR_ASSOCIATED_ROWITERATORが返されます。

配列値属性に含まれる要素のJavaタイプを取得

getElemJavaType()

配列値属性に含まれる要素のSQLタイプを取得

getElemSQLType()

属性の名前を取得

getName()

属性の索引位置を取得

getIndex()

数値属性の精度または文字列属性の最大値を取得

getPrecision()

数値属性のスケールを取得

getScale()

属性に対応する基礎となる列名を取得

getColumnNameForQuery()

属性に固有なカスタム・プロパティ値を取得

getProperty()、getProperties()

属性のUI AttributeHintsオブジェクトを取得

getUIHelper()

属性が必須かどうかをテスト

isMandatory()

属性が問合せ可能かどうかをテスト

isQueriable()

属性が行の主キーの一部であるかどうかをテスト

isPrimaryKey()

D.2.9 AttributeHintsインタフェース

AttributeHintsインタフェースは、属性とその値を適切なユーザー・インタフェースに表示する際に使用できるUIヒント情報を公開します。表D-9は、AttributeHintsインタフェースを使用して、属性で実行できる操作を説明しています。

表D-9 AttributeHintsインタフェース

実行する処理

コールするAttributeHintsインタフェースのメソッド

属性のUIラベルを取得

getLabel()

属性のツールチップを取得します

getTooltip()

与えられたフォーマット・マスクを使用して、属性のフォーマット化された値を取得

getFormattedAttribute()

属性の表示ヒントを取得

getDisplayHint()

注意:

表示されるヒントは、DisplayまたはHideという文字列値を持ちます。

属性の優先されるコントロールのタイプを取得

getControlType()

属性で提供されるフォーマット・マスクを使用して、フォーマット化された文字列値を解析

parseFormattedAttribute()

D.3 ビジネス・サービス層で使用されるメソッド

これらのoracle.jbo.*インタフェースに対応する実装クラスは、「クライアント層で使用されるメソッド」で説明されているとおり、クライアント・コードによって直接アクセスされないように、意図的に設計されています。該当する実装クラスはoracle.jbo.server.*という別のパッケージの中に存在し、クライアント層コードで使用しないようユーザーに喚起するため、Implという接尾辞が名前に付いています。

ビジネス・サービス層の実装コードでは、クライアントから利用できるのと同じメソッドを使用できますが、次の処理も実行できます。

- oracle.jbo.*インタフェースをそのoracle.jbo.server.*パッケージ実装クラスに安全にキャストして、該当するImplクラス上のメソッドも使用する。

- super.methodName()をコールして、そのデフォルト機能の拡張または変更を実行する前または後で、基本フレームワークの実装クラスのpublicまたはprotectedメソッドをオーバーライドし、コンポーネントのサブクラス内にカスタム・コードを記述する。

この項では、ADFビジネス・コンポーネントの主要なクラスでコール、記述およびオーバーライドの対象としてよく使用されるメソッドのサマリーを示します。

D.3.1 コンポーネントでのカスタムJavaファイルの制御

個々のクラスの仕様を調べる前に、コンポーネントで使用するカスタムJavaファイルの制御方法を理解することが重要です。カスタマイズされたサブクラスがコンポーネントで不要な場合は、基本フレームワーク・クラスで実装を実行時に処理するだけですみます。

ユーザーが作成する各ビジネス・コンポーネントは、単一のXMLコンポーネント・ディスクリプタと、関連するカスタムJava実装ファイル(ゼロ個以上)から構成されます。Javaのカスタマイズをサポートする各コンポーネントでは、JDeveloper IDEのコンポーネントの概要エディタにJavaページが表示されます。様々なJavaクラスを選択、または選択解除して、コンポーネント用に作成するクラスを制御します。クラスを1つも指定しなかった場合、コンポーネントはXMLのみのコンポーネントになり、そのJava実装として基本フレームワーク・クラスのみが使用されます。そうでない場合は、現在のコンポーネントでカスタマイズする必要がある関連するJavaクラスのチェック・ボックスを選択します。JDeveloperは、フレームワーク・ベース・クラスのカスタム・サブクラスを作成します。ユーザーはこのサブクラスにコードを追加できます。

注意:

「ツール」→「設定」→「ビジネス・コンポーネント」を選択し、チェック・ボックスを選択してデフォルト値を設定すると、ADFビジネス・コンポーネントのタイプごとにデフォルトでJavaクラスを生成する必要のあるグローバルなIDE設定を設定できます。

ベスト・プラクティスの1つは、自動生成されたgetterおよびsetterメソッド以外のカスタム・コードは必要なくても、常にエンティティ・オブジェクトとビュー行クラスを生成することです。getterおよびsetterメソッドを使用すると、コンパイル時に型チェックが実行されるため、正しくない種類の値が設定されている属性に反応して、実行時にエラーが表面化するのを防止できます。

D.3.2 ApplicationModuleImplクラス

ApplicationModuleImplクラスは、アプリケーション・モジュール・コンポーネント用のベース・クラスです。アプリケーション・モジュールは、ビジネス・サービスの実装に使用するADFコンポーネントであるため、アプリケーション・モジュール・クラスはサービスレベルのアプリケーション・ロジックを記述できる場所と考えてください。アプリケーション・モジュールは、ビュー・オブジェクト・インスタンスと協調して、ビジネス・ドメイン・オブジェクトに自動的に関連付けされる更新可能な一連の値オブジェクトをサポートします。ビジネス・ドメイン・オブジェクトは、ADFエンティティ・オブジェクトとして実装されます。

D.3.2.1 ApplicationModuleImpl上でよくコールされるメソッド

表D-10は、ApplicationModuleImplクラスを使用して、アプリケーション・モジュールで実行できる操作を説明しています。

表D-10 ApplicationModuleImpl上でよくコールされるメソッド

実行する処理

コールするApplicationModuleImplクラスのメソッド

(クライアント内から実行することもできる)一般的なアプリケーション・モジュール処理をクラス内から実行

これらのメソッドのリストは、「ApplicationModuleインタフェース」を参照してください。

アプリケーション・モジュールのデータ・モデルに設計時に追加したビュー・オブジェクト・インスタンスにアクセス

getViewObjectInstanceName()

注意:

JDeveloperは、この型保証ビュー・オブジェクト・インスタンスのgetterメソッドを自動的に生成して、アプリケーション・モジュールの設計時のデータ・モデルに各ビュー・オブジェクト・インスタンスを反映します。

現在のDBTransactionオブジェクトにアクセス

getDBTransaction()

設計時にアプリケーション・モジュールに追加した、ネストしたアプリケーション・モジュール・インスタンスにアクセス

getAppModuleInstanceName()

注意:

JDeveloperは、この型保証アプリケーション・モジュール・インスタンスのgetterメソッドを自動的に生成して、現在のアプリケーション・モジュールに設計時に追加された、ネストした各アプリケーション・モジュール・インスタンスを反映します。

D.3.2.2 カスタムのApplicationModuleImplサブクラスでよく記述されるメソッド

表D-11は、カスタムApplicationModuleImplクラスを使用して、アプリケーション・モジュールで実行できる操作を説明しています。

表D-11 カスタムなApplicationModuleImplサブクラスでよく記述されるメソッド

実行する処理

記述するカスタムなApplicationModuleImplクラスのメソッド

データベース・ストアド・プロシージャを起動

someCustomMethod()

注意:

DBTransactionインタフェースの該当するメソッドを使用して、JDBC PreparedStatementを作成します。ストアド・プロシージャにOUTパラメータがある場合は、かわりにCallableStatementを作成します。

PL/SQLストアド・プロシージャへのコールのカプセル化の実例を示すサンプル・コードは、「ストアド・プロシージャとストアド・ファンクションの呼出し」を参照してください。

カスタムなビジネス・サービス・メソッドをアプリケーション・モジュール上で公開

someCustomMethod()

注意:

「アプリケーション・モジュールの編集」ダイアログの「クライアント・インタフェース」ページでメソッド名を選択し、クライアントからアクセスできるように必要に応じて公開します。

JDeveloperでは、ユーザーがクライアントに公開することを選択したサービスレベルのカスタム・メソッドが含まれるカスタムなYourApplicationModuleNameインタフェースを生成できます。クライアント・インスタンスに表示するメソッドを選択するには、「アプリケーション・モジュールの編集」ダイアログの「クライアント・インタフェース」ページを使用します。

D.3.2.3 カスタムのApplicationModuleImplサブクラスでよくオーバーライドされるメソッド

表D-12は、カスタムApplicationModuleImplインタフェースを使用して、アプリケーション・モジュールでオーバーライドできる操作を説明しています。

表D-12 カスタムなApplicationModuleImplサブクラスでよくオーバーライドされるメソッド

実行する処理

カスタムなApplicationModuleImplクラスでオーバーライドするメソッド

最初はアプリケーション・モジュールの作成時、以降はそのアプリケーション・モジュールが異なるアント・セッションによって使用されるときにカスタムな設定コードを実行

prepareSession()

注意:

これは、Oracle仮想プライベート・データベース(VPD)機能を使用することを目的として現在のユーザーのためにクライアント別コンテキスト情報を設定する際に使用するメソッドです。このメソッドは、その他の種類のPL/SQLパッケージ・グローバル変数(値はクライアントに固有で、他のストアド・プロシージャが依存している可能性がある)を設定する際にも使用できます。

このメソッドは、アプリケーション・モジュールで指定されたビュー・オブジェクト・インスタンス固有のセットアップ・コードを実行する場合にも便利です。ビュー・オブジェクト設定コードをインスタンス固有ものにするかわりに、該当するビュー・オブジェクト・コンポーネントから作成されるインスタンスごとに初期化する場合は、かわりにViewObjectImplサブクラス内のオーバーライド対象のcreate()メソッドに設定ロジックを記述します。

アプリケーション・モジュールのトランザクションが接続プールのデータベース接続と関連付けられた後に、カスタムな設定コードを実行

afterConnect()

注意:

getDBTransaction().executeCommand()を使用してALTER SESSION SET SQL TRACE TRUEを実行し、現在のアプリケーション接続のデータベースSQL Traceロギングを有効にするコード行の記述に便利な場所です。これらのログはその後、TKPROFユーティリティを使用して処理すると、実行対象のSQL文および使用対象の問合せオプティマイザ計画を調査することができます。

TKPROFユーティリティでの作業の詳細は、の「アプリケーション・トレースの実行」、SQLトレースとTKPROFの理解に関する項を参照してください。

アプリケーション・モジュールのトランザクションがそのデータベース接続をデータベース接続プールに解放する前に、カスタムな設定コードを実行

beforeDisconnect()

注意:

jbo.doconnectionpoolingをtrueに設定しておくと、アプリケーション・モジュールがアプリケーション・モジュール・プールに返されるたびに、接続がデータベース接続プールに解放されます。

カスタムなアプリケーション・モジュールの状態の状態管理XMLスナップショットへの書出し

passivateState()

カスタムなアプリケーション・モジュールの状態を状態管理XMLスナップショットから読み込んでリストア

activateState()

D.3.3 DBTransactionImpl2クラス

DBTransactionImpl2クラス(ベースのDBTransactionImplクラスを拡張し、DatabaseTransactionFactoryクラスによって作成される)は、DBTransactionインタフェースを実装するベース・クラスであり、現在のトランザクション内で保留中の作業ユニットを表します。

D.3.3.1 DBTransaction上でよくコールされるメソッド

表D-13は、DBTransactionクラスを使用して、トランザクションで実行できる操作を説明しています。

表D-13 DBTransaction上でよくコールされるメソッド

実行する処理

コールするDBTransactionクラスのメソッド

トランザクションをコミットします

commit()

トランザクションをロールバックします。

rollback()

トランザクション内のすべての保留中の無効な変更を積極的に検証

validate()

トランザクションのConnectionオブジェクトを使用してJDBC PreparedStatementを作成

createPreparedStatement()

トランザクションのConnectionオブジェクトを使用してJDBC CallableStatementを作成

createCallableStatement()

トランザクションのConnectionオブジェクトを使用してJDBC Statementを作成

createStatement()

トランザクションの警告リストに警告を追加

addWarning()

D.3.3.2 カスタムのDBTransactionImpl2サブクラスでよくオーバーライドされるメソッド

表D-14は、カスタムDBTransactionImpl2サブクラスを使用して、トランザクションで実行できる操作を説明しています。

表D-14 カスタムなDBTransactionImpl2サブクラスでよくオーバーライドされるメソッド

実行する処理

カスタムなDBTransactionImpl2クラスでオーバーライドするメソッド

トランザクション・コミット操作の前または後でカスタム・コードを実行

commit()

トランザクション・ロールバック操作の前または後でカスタム・コードを実行

rollback()

カスタムなDBTransactionImpl2サブクラスを実行時に使用するには、次の手順を実行する必要があります。

1. 次のようにcreateメソッドをオーバーライドしてカスタムなDBTransactionImpl2サブクラスのインスタンスを返すようなDatabaseTransactionFactoryのカスタムなサブクラスを作成します。

package com.yourcompany.adfextensions;
import oracle.jbo.server.DBTransactionImpl2;
import oracle.jbo.server.DatabaseTransactionFactory;
import com.yourcompany.adfextensions.CustomDBTransactionImpl;
public class CustomDatabaseTransactionFactory
extends DatabaseTransactionFactory {
/**
* Return an instance of our custom CustomDBTransactionImpl class
* instead of the default implementation.
*
* @return An instance of our custom DBTransactionImpl2 implementation.
*/
public DBTransactionImpl2 create() {
return new CustomDBTransactionImpl();
}
}

2. 構成プロパティTransactionFactoryの値にカスタムなトランザクション・ファクトリの完全修飾クラス名を設定して、カスタムなトランザクション・ファクトリ・クラスを使用するようフレームワークに指示します。他の構成プロパティの場合と同様に、構成XMLファイル内で指定しない場合は、かわりに同名のJavaシステム・パラメータとして指定することもできます。

D.3.4 EntityImplクラス

EntityImplクラスは、ビジネス・ドメイン・オブジェクトのデータ、検証規則およびビジネス動作をカプセル化するエンティティ・オブジェクトのベース・クラスです。

D.3.4.1 EntityImpl上でよくコールされるメソッド

表D-15は、EntityImplクラスを使用して、エンティティ・オブジェクトで実行できる操作を説明しています。

表D-15 EntityImpl上でよくコールされるメソッド

実行する処理

コールするEntityImplクラスのメソッド

属性の値を取得

getAttributeName()

注意:

このコード生成されたgetterメソッドは、getAttributeInternal()をコールしますが、コンパイル時に型チェックが実行されます。

属性の値を設定

setAttributeName()

注意:

このコード生成されたsetterメソッドは、setAttributeInternal()をコールしますが、コンパイル時に型チェックが実行されます。

名前を使用して属性の値を取得

getAttributeInternal()

名前を使用して属性の値を設定

setAttributeInternal()

エンティティ・オブジェクトの検証を積極的に実行

validate()

データベースのエンティティをリフレッシュ

refresh()

属性の値を移入しますが、このときこの値は変更中とはされません。そのかわり、変更通知が送信され、画面またはページ上でUIにより値がリフレッシュされます。

populateAttributeAsChanged()

エンティティのDefinitionオブジェクトにアクセス

getDefinitionObject()

エンティティのKeyオブジェクトを取得

getKey()

現在のトランザクション内でポスト済(ただし、未コミット状態)であるかどうかに関係なく、エンティティ・インスタンスの状態を判別

getEntityState()

注意:

このメソッドにより、現在のトランザクション内のエンティティ・インスタンスのステータスを示す定数(STATUS_UNMODIFIED、STATUS_INITIALIZED、STATUS_NEW、STATUS_MODIFIED、STATUS_DELETEDまたはSTATUS_DEAD)の1つが返されます。

エンティティ・インスタンスの状態を判別

getPostState()

注意:

このメソッドは通常、postChanges()メソッドを使用しプログラムでポストを実行する(ただし、エンティティの変更をデータベースにまだコミットしておらず、そのポスト状態に関してエンティティの状態を検出する必要がある)場合にのみ使用します。

データベースから読み取った特定の属性値を取得

getPostedAttribute()

エンティティ・インスタンスのデータベース行を積極的にロック

lock()

D.3.4.2 カスタムのEntityImplサブクラスでよく記述されるメソッド

表D-16は、カスタムEntityImplサブクラスを使用して、エンティティ・オブジェクトで実行できる操作を説明しています。

表D-16 カスタムなEntityImplサブクラスでよく記述されるメソッド

実行する処理

カスタムEntityImplサブクラスで記述するメソッド

属性に固有な検証を実行

public boolean validateSomething(AttrTypevalue)

注意:

エンティティ・オブジェクトの編集ダイアログの「検証」ページ内の正しい属性に対してMethodValidatorルールを追加することにより、属性バリデータ・メソッドを登録します。

エンティティ・レベルの検証を実行

public boolean validateSomething()

注意:

エンティティ・オブジェクトの編集ダイアログの「検証」パネル内のエンティティに対してMethodValidatorルールを追加することにより、エンティティレベルのバリデータ・メソッドを登録します。

一時属性の値を計算

生成されたgetAttributeName()メソッドに計算コードを追加します。

D.3.4.3 カスタムのEntityImplサブクラスでよくオーバーライドされるメソッド

表D-17は、カスタムEntityImplサブクラスを使用して、エンティティ・オブジェクトでオーバーライドできる操作を説明しています。

表D-17 カスタムなEntityImplサブクラスでよくオーバーライドされるメソッド

実行する処理

EntityImplサブクラスでオーバーライドするメソッド

新しいエンティティ・インスタンスの主キー属性値をプログラムで移入することも含めて、計算後のデフォルト属性値を設定

create()

注意:

super.create()をコールした後、適切なsetAttrName()メソッド(複数可)をコールし、該当する属性のデフォルト値を設定します。

データベースに対して変更をポストする前に属性値を変更

prepareForDML()

ユーザーのエンティティ・オブジェクトのかわりにフレームワークがデータベースに対して実行する標準のINSERT、UPDATEまたはDELETE DML操作を拡張または変更

doDML()

注意:

このメソッドは、操作フラグの値を定数DML_INSERT、DML_UPDATEまたはDML_DELETEに照らしてチェックし、どのようなDML操作が実行されているのかをテストします。

すべてのエンティティ・インスタンスがデータベースに対してポストされた後で、該当する変更がコミットされる前に、SQLベースの複雑な検証を実行

beforeCommit()

注意:

このメソッドは、トランザクションのエンティティ行ごとに起動されます。

すべてのエンティティ・インスタンスがデータベースにコミットした後、カスタム処理を実行

afterCommit()

注意:

このメソッドは、保留中の変更のトランザクション・リストのエンティティ行ごとに起動されます。

現在の子エンティティの前に、この子エンティティが依存する、新たに作成された関連する親エンティティがデータベースにポストされることを保証

postChanges()

注意:

該当する子エンティティにコンポジット・アソシエーションによって親エンティティが関連付けられている場合、変更のポストはフレームワークによって自動的に処理済です。(構成されているわけではなく)関連付けられているだけの場合は、postChanges()をオーバーライドして、新しく作成された親エンティティに、それに依存している現在の子エンティティより前にポストの実行を強制する必要があります。これを実現するために、オーバーライド対象のpostChanges()メソッドで一般的に記述するコードの例は、「ポスト順序を制御するためのpostChanges()のオーバーライド」を参照してください。

デフォルトの属性値をプログラムで定義するか、変更された行が初期化状態に再リフレッシュされる前または行が最初に作成された後に、カスタムな初期化を実行

initDefaultExpressionAttributes()

注意:

このメソッドは、初期化サイクルの終了直前に起動されます。これにより、カスタム・コードの実行に適応できるようになります。

注意:

属性レベルの検証コードは、EntityImplクラスの適切なsetAttributeNameメソッドの中に直接記述できます。ただし、表D-16でお薦めしたMethodValidatorのアプローチを使用すると、エンティティ・オブジェクトの属性に対応する概要エディタの「検証規則」ページ上に、すべての検証が効果的に配置されます。

警告:

また、validateEntity()メソッドをオーバーライドして、エンティティレベルの検証コードを記述することもできます。ただし、フレームワークにより最大限の検証エラー・セットが収集され、クライアント・ユーザー・インタフェースに報告されるというADFバンドル例外モードの長所をそのまま維持する必要がある場合は、表D-16でお薦めされているMethodValidatorアプローチを使用します。その場合は、ユーザーの検証メソッドがスローするユーザー例外をフレームワークがすべて自動的に収集するので、ユーザーはバンドルされている例外実装メカニズムを理解する必要がありません。validateEntity()メソッドをオーバーライドすると、デフォルトでは、Oracle ADFが捕捉していた例外を正確に捕捉し、バンドルする責任がユーザー独自のコードに直接移ります。これは重要なので、毎回、忘れずに手作業でコーディングします。

D.3.5 EntityDefImplクラス

EntityDefImplクラスは、単一のJava VM内で所定のタイプを持つ全エンティティ・オブジェクトに対するシングルトンの共有メタデータ・オブジェクトです。たとえば、Java VMに、EntityDefImplクラスの2つのインスタンスが含まれていて、一方に顧客のXMLデータが含まれていて、他方にオーダーが含まれている場合、それぞれのインスタンスは1つのみになります。このクラスは、エンティティ・インスタンスの構造を定義し、新規エンティティ・インスタンスを作成するメソッドおよび主キーによって既存のインスタンスを探すメソッドを提供します。

D.3.5.1 EntityDefImpl上でよくコールされるメソッド

表D-18は、EntityDefImplクラスを使用して、エンティティ・オブジェクトで実行できる操作を説明しています。

表D-18 EntityDefImpl上でよくコールされるメソッド

実行する処理

コールするEntityDefImplクラスのメソッド

指定されたタイプのエンティティ・オブジェクトを主キーにより検索

findByPrimaryKey()

注意:

findByPrimaryKey()でサブタイプ・エンティティのエンティティ・インスタンスも検索するためのヒントは、「サブタイプ・エンティティ・オブジェクトとfindByPrimaryKey()メソッド」を参照してください。

現在のDBTransactionオブジェクトにアクセス

getDBTransaction()

完全修飾名を使用してEntityDefImplオブジェクトを検索

findDefObject() (静的メソッド)

エンティティ・オブジェクトのカスタム・プロパティの値を取得

getProperty()、getProperties()

エンティティ・オブジェクトのカスタム・プロパティの値を設定

setProperty()

エンティティ・オブジェクトの新規インスタンスを作成

createInstance2()

注意:

同じカスタムなEntityDefImplサブクラス内で期待される独自のシグネチャを使用して、カスタムなcreateXXX()メソッドを公開することもできます。詳細は「カスタムのEntityDefImplクラスでよく記述されるメソッド」を参照してください。

該当するエンティティ・タイプのキャッシュ内でエンティティ・インスタンスの反復処理を実行

getAllEntityInstancesIterator()

エンティティ定義オブジェクトの配列リストにアクセスし、現在のエンティティを拡張するエンティティを取得

getExtendedDefObjects()

D.3.5.2 カスタムのEntityDefImplクラスでよく記述されるメソッド

表D-19は、カスタムEntityDefImplクラスを使用して、エンティティ・オブジェクトで実行できる操作を説明しています。

表D-19 EntityDefImpl上でよく記述されるメソッド

実行する処理

記述するカスタムなEntityDefImplクラスのメソッド

属性値または設定情報から構成される初期型保証セットを持つエンティティ・インスタンスの作成を他のクラスに許可

createXXX(Type1arg1,..., TypeNargN)

注意:

内部ではこのメソッドを使用することにより、AttributeListを実装するNameValuePairsオブジェクトのインスタンスが作成、移入され、保護されたメソッドcreateInstance()がコールされ、NameValuePairsオブジェクトが渡されます。これに対するコールを他のクラスに許可する場合、該当メソッドはpublicである必要があります。

D.3.5.3 カスタムのEntityDefImplでよくオーバーライドされるメソッド

表D-20は、EntityDefImplクラスを使用して、エンティティ・オブジェクトで実行できる操作を説明しています。

表D-20 EntityDefImpl上でよくオーバーライドされるメソッド

実行する処理

カスタムなEntityDefImplクラスでオーバーライドするメソッド

該当するシングルトン・メタオブジェクトのロード時にカスタムなメタデータの初期化を実行

createDef()

Refresh-On-Insert属性またはRefresh-on-Update属性をサポートするためにRETURNING INTO句の使用を回避

isUseReturningClause()

注意:

RETURNING INTOの使用を無効化するには、このメソッドがfalseを返すように設定します。これは、データベース・レベルでRETURNING INTOをサポートしていない、INSTEAD OFトリガーを持つビューにエンティティ・オブジェクトが基づいている場合に必要なことがあります。

該当するエンティティのために発行されたUPDATE文が、変更された列のみ更新するのか、すべての列を更新するのかを制御

isUpdateChangedColumns()

注意:

デフォルトはtrueです。

完全修飾名を使用してEntityDefImplオブジェクトを検索

findDefObject()

注意:

静的メソッド。

エンティティ・オブジェクトのカスタム・プロパティの値を設定

setProperty()

ビュー・オブジェクトによる暗黙的な方法ではなく、エンティティ・オブジェクトの新規インスタンスの作成を他のクラスに許可

createInstance()

注意:

「カスタムのEntityDefImplクラスでよく記述されるメソッド」の項の説明に従ってカスタムのcreateメソッドを記述しない場合、エンティティ・インスタンスの作成を他のクラスに許可するには、このメソッドをオーバーライドして可視性をprotectedからpublicに広げることが必要になります。

D.3.6 ViewObjectImplクラス

ViewObjectImplクラスは、ビュー・オブジェクトのベース・クラスです。

D.3.6.1 ViewObjectImpl上でよくコールされるメソッド

表D-21は、ViewObjectImplクラスを使用して、ビュー・オブジェクトで実行できる操作を説明しています。

表D-21 ViewObjectImpl上でよくコールされるメソッド

実行する処理

コールするViewObjectImplクラスのメソッド

(クライアント内から実行することもできる)一般的なビュー・オブジェクト、行セットまたは行セット・イテレータ操作をクラス内から実行。

ビュー・オブジェクト、行セットまたは行セットのイテレータ・レベルでの操作の詳細は、「ViewObjectインタフェース」、「RowSetインタフェース」および「RowSetIteratorインタフェース」を参照してください。

デフォルトの行セットを変更せずに、ビュー・インスタンスのメモリー内行セットを検索

findByViewCriteria()

データベースからすべての行をフェッチし、ビュー・オブジェクトの行セット内の行の合計数を決定

getRowCount()

注意:

このメソッドは注意して使用してください。起動する行数が多いと、パフォーマンスが低下する可能性があります。

クライアントによる起動のたびに、その後に、ビュー・オブジェクトの行セット内の行の合計数を決定

getQueryHitCount()

ビュー・オブジェクトの行セット内の行の合計数を決定

getEstimatedRowCount()

注意:

必要とされるデータベース問合せが1つのみ(行数の取得後は、行が追加および削除されて維持される)なので、これは行数の確認には適した方法です。

カウント問合せを実行するが、行数が多くてパフォーマンスに影響する場合、実行を管理するためにcap引数を使用

getCappedQueryHitCount()

名前付きバインド・パラメータを定義

defineNamedWhereClauseParam()

名前付きバインド・パラメータを削除

removeNamedWhereClauseParam()

名前を使用して、デフォルト行セット上のバインド変数値を設定

setNamedWhereClauseParam()

注意:

ビュー・オブジェクト上で名前付きのバインド変数を以前定義してある場合にのみ機能します。

デフォルト行セット上のバインド変数値を設定

setWhereClauseParams()

注意:

このメソッドは、名前付きバインド変数が未定義の場合に、Oracle PositionalまたはJDBC Positionalというバインド・スタイルを持つビュー・オブジェクトに対して使用します。

メモリー内フィルタ式の評価に基づいてビュー・オブジェクトの行セット内の行のサブセットを取得

getFilteredRows()

メモリー内フィルタ式の評価に基づいてビュー・オブジェクトの行セット内の現在の範囲内にある行のサブセットを取得

getFilteredRowsInRange()

ADF問合せコンポーネント内に表示される基準アイテムの実行時表示をオーバーライド。サブクラスがオーバーライドして、指定の基準アイテムのカスタムAttributeHints実装を返す場合があります。デフォルトではnullを返します。

getCriteriaItemAttributeHints()

該当するビュー・オブジェクトのラウンドトリップごとにデータベースからフェッチされる行の数を設定

setFetchSize()

注意:

デフォルトのフェッチ・サイズは一度に1行です。ビュー・オブジェクトで多数の行を取得しようとしている場合には、これが最適ではないことは明らかです。したがって、設計時に「ビュー・オブジェクトの編集」ダイアログにある「チューニング」ページを使用してフェッチ・サイズの設定を大きくするか、またはこのメソッドを使用して、実行時に設定する必要があります。

共有アプリケーション・モジュールのルックアップ・ビュー・オブジェクト・インスタンスでのみ、行セットの問合せを強制的に(再)実行

forceExecuteQueryOfSharedVO()

注意:

問合せを再実行すると、新しい問合せのコレクションが強制的に作成され、アプリケーション・モジュール・キャッシュの使用が妨げられます。このメソッドは、実行中ではなく、セットアップ中に共有アプリケーション・モジュールにアクセスしていることが分かっている場合のみ使用してください。通常の実行時にこのメソッドを使用した場合、このコレクションに同時にアクセスする複数のユーザーのナビゲーションを妨害するような、予想外の副作用が生じる可能性があります。新しい問合せコレクションを作成せずに、キャッシュからコレクションをリフレッシュする必要がある場合は、かわりにexecuteQuery()を呼び出します。

D.3.6.2 カスタムのViewObjectImplサブクラスでよく記述されるメソッド

表D-22は、カスタムViewObjectImplサブクラスを使用して、ビュー・オブジェクトで実行できる操作を説明しています。

表D-22 カスタムなViewObjectImplサブクラスでよく記述されるメソッド

実行する処理

カスタムなViewObjectImplサブクラスで記述するメソッド

バインド変数自体の位置詳細を公開することなくバインド変数値を設定する型保証メソッドをクライアントに提供

someMethodName(Type1arg1, ..., TypeNargN)

注意:

このメソッドは、内部でsetWhereClauseParams()メソッドをコールし、型保証メソッドの引数で提供される値を使用して、正しいバインド変数を設定します。

JDeveloperでは、ユーザーがクライアントに公開することを選択したビュー・オブジェクトのカスタム・メソッドが含まれるカスタムなYourViewObjectNameインタフェースを生成できます。クライアント・インスタンスに表示するメソッドを選択するには、「ビュー・オブジェクトの編集」の「クライアント・インタフェース」ページを使用します。

D.3.6.3 カスタムのViewObjectImplサブクラスでよくオーバーライドされるメソッド

表D-23は、カスタムViewObjectImplサブクラスを使用して、ビュー・オブジェクトで実行できる操作を説明しています。

表D-23 カスタムなViewObjectImplサブクラスでよくオーバーライドされるメソッド

実行する処理

ViewObjectImplサブクラスでオーバーライドするメソッド

ビュー・オブジェクト・インスタンスが初めて作成されるときにカスタムなビュー・オブジェクト・クラスのメンバー(行属性ではない)を初期化

create()

注意:

このメソッドは、作成されるビュー・オブジェクトの各インスタンスに適用可能な設定ロジックをアプリケーション・モジュールのコンテキスト内で実行する際に有用です。

汎用のビュー・オブジェクト設定ロジックのかわりに、アプリケーション・モジュールで指定されたビュー・オブジェクト・インスタンス固有のロジックを実行する必要がある場合は、アプリケーション・モジュールのApplicationModuleImplサブクラスのprepareSession()メソッドをオーバーライドし、findViewObject()をコールして設定が必要なプロパティを持つビュー・オブジェクト・インスタンスを検索した後で、このロジックを実行します。

カスタムなビュー・オブジェクト・インスタンスの状態の状態管理XMLスナップショットへの書出し

passivateState()

カスタムなビュー・オブジェクト・インスタンスの状態を状態管理XMLスナップショットから読み込んでリストア

activateState()

代替データソースを利用するために、ビュー・オブジェクトの問合せの実行をカスタマイズします。

executeQueryForCollection()

注意:

デフォルトのビュー・オブジェクトは、データベースからデータを読み取り、データベースの結果セットを処理するためにJDBCレイヤーを使用するタスクを自動化します。これに対し、カスタムJavaクラスで適切なメソッドをオーバーライドすることにより、「代替データソースに対するプログラムでのビュー・オブジェクトの使用」で説明されているとおり、様々な代替データソースからプログラムでデータを取得するビュー・オブジェクトを作成できます。

WHERE句およびパラメータを変更するために、executeQueryForCollection()をオーバーライドするのは正しい方法ではありません。ADFビジネス・コンポーネントは、メソッドがコールされるまでに、パラメータがすでに計算済で行フィルタが構築されているものと想定しています。毎回の実行の前に問合せを変更すると、ADFビジネス・コンポーネントは既存のキャッシュされている文ハンドルを再利用できなくなります。かわりに、問合せの実行前にバインド・パラメータを指定する場合は、ViewObjectImplのprepareRowSetForQuery()をオーバーライドできます。これは実行される行セットへのアクセスを提供するからです。

プログラムによるビュー・オブジェクトをカスタマイズして、代替データソースを使用するようにし、問合せコレクションが、問合せの実行からフェッチできる行がまだあるかどうかを判断します。

hasNextForCollection()

プログラムによるビュー・オブジェクトをカスタマイズして、代替データソースが利用されるようにし、問合せ内で使用されるバインド・パラメータの名前と値をロギングします

bindParametersForCollection()

プログラムによるビュー・オブジェクトをカスタマイズして、代替データソースが利用されるようにし、取得したデータの各行を移入します。

createRowFromResultSet()

プログラムによるビュー・オブジェクトをカスタマイズして、代替データソースが利用されるようにし、取得される行数を返します。

getQueryHitCount()

プログラムによるビュー・オブジェクトをカスタマイズして、代替データソースを使用するようにし、グローバルな行フェッチ制限で指定された上限値を超える行数を問合せが戻す可能性があるかどうかを判断します。

getCappedQueryHitCount()

プログラムによるビュー・オブジェクトをカスタマイズして、実行される行セットにアクセスし、問合せの実行前に、ビュー・オブジェクトのWHERE句を変更して、バインド・パラメータ値を指定します。これは、問合せをオーバーライドしてバインド・パラメータを設定する場合に推奨されるフック・ポイントです。このメソッドは、行セットを実行しようとするたびに、フレームワークによって起動されます。

prepareRowSetForQuery()

プログラムによるビュー・オブジェクトをカスタマイズして、代替データソースが利用されるようにし、クローズ処理中の行セットと関連付けられている可能性のあるリソースをすべて解放します。

releaseUserDataForCollection()

ViewCriteriaRowのViewCriteriaコレクションをQuery-by-ExampleのWHERE句に変換する方法を変更または拡張します

getViewCriteriaClause(boolean)

プログラムによるビュー・オブジェクトをカスタマイズして、範囲ページングを実装します。

buildRangePagingQuery()

プログラムによるビュー・オブジェクトをカスタマイズして、範囲ページングを実装し、現在の行の範囲の開始とサイズを制御するパラメータを渡して、データソースからフェッチします。

bindRangePagingParams()

D.3.7 ViewRowImplクラス

ViewRowImplクラスは、ビュー行オブジェクトのベース・クラスです。

D.3.7.1 ViewRowImpl上でよくコールされるメソッド

表D-24は、カスタムViewRowImplクラスを使用して、ビュー・オブジェクト行で実行できる操作を説明しています。

表D-24 ViewRowImpl上でよくコールされるメソッド

実行する処理

カスタムなViewRowImplクラスでコールするメソッド

(クライアント内から実行することもできる)一般的なビュー行処理をクラス内から実行

行レベルでの操作の詳細は、「行インタフェース」を参照してください。

属性の値を取得

getAttrName()

属性の値を設定

setAttrName()

該当するビュー行からの属性保存場所の委譲先である基礎となるエンティティ・インスタンスにアクセス

getEntityUsageAliasName()

注意:

エンティティ・オブジェクトの慣用名(別名)は、「ビュー・オブジェクトの編集」ダイアログの「エンティティ・オブジェクト」ページで変更できます。

D.3.7.2 カスタムのViewRowImplクラスでよく記述されるメソッド

表D-25は、カスタムViewRowImplクラスを使用して、ビュー・オブジェクト行で実行できる操作を説明しています。

表D-25 ViewRowImpl上でよく記述されるメソッド

実行する処理

記述するカスタムなViewRowImplクラスのメソッド

ビュー・オブジェクト・レベルの一時属性の値を計算

getAttrName()

注意:

メソッドのスケルトンは、JDeveloperによって自動的に生成されます。ただし、メソッド本体内のカスタムな計算ロジックは、ユーザーが記述する必要があります。

ビュー行属性の設定というカスタムな処理を実行

setAttrName()

注意:

メソッドのスケルトンは、JDeveloperによって自動的に生成されます。ただし、メソッド本体内のカスタムなロジックは、ユーザーが必要に応じて記述する必要があります。

属性の更新の可能性を条件付きの方法で判断

isAttributeUpdateable()

論理演算を現在行で公開(オプションでクライアントからコール可能)

doSomething()

注意:

これらのビュー行レベルのカスタム・メソッドは、単に反転し、現在行に関連する基礎となるエンティティ・オブジェクト上のメソッド・コールに委譲することがよくあります。

JDeveloperでは、ユーザーがクライアントに公開することを選択したビュー行のカスタム・メソッドが含まれるカスタムなYourViewObjectNameRowインタフェースを生成できます。クライアント・インスタンスに表示するメソッドを選択するには、「ビュー・オブジェクトの編集」ダイアログの「カスタム行インタフェース」ページを使用します。

D.3.7.3 カスタムのViewRowImplサブクラスでよくオーバーライドされるメソッド

表D-26は、カスタムViewRowImplサブクラスを使用して、ビュー・オブジェクト行で実行できる操作を説明しています。

表D-26 カスタムなViewRowImplサブクラスでよくオーバーライドされるメソッド

実行する処理

ViewRowImplサブクラスで記述するメソッド

属性の更新の可能性を条件付きの方法で判断

isAttributeUpdateable()

E ADFビジネス・コンポーネントJava EEデザイン・パターン・カタログ

この付録では、ADFビジネス・コンポーネントによって自動的に実装されるJavaプラットフォームEnterprise Edition (Java EE)デザイン・パターンの概要を示します。

Oracle Application Development Frameworkのビジネス・コンポーネント部品とJDeveloper用の関連する設計時拡張機能を使用すると、高性能かつ機能豊富で正確な階層構造を持つJava EEビジネス・サービスを構築するための規範的なアーキテクチャが得られます。

ADFビジネス・コンポーネント層によって自動的に実装される多数の設計パターンの概要を、表E-1に示します。おなじみのSunのJava EE Blueprintsのパターンもあれば、ADFビジネス・コンポーネントによって追加されたデザイン・パターンもあります。Java EE BluePrintsの詳細は、Oracle Technology Network WebサイトのBluePrintsのページ(http://www.oracle.com/technetwork/java/index-jsp-136701.html)を参照してください。

表E-1 ADFビジネス・コンポーネントによって実装されるJava EEデザイン・パターン

パターンの名前と説明

ADFビジネス・コンポーネントによる実装方法

モデル/ビュー/コントローラ

データおよびプレゼンテーションの役割が正しく分割され、複数のタイプのクライアント・ディスプレイで同じビジネス情報を使用できます。

ADFアプリケーション・モジュールが提供するモデル/ビュー/コントローラというアプリケーション・オブジェクトの汎用的な実装により、あらゆるアプリケーションまたはサービスに対するアプリケーション・データ・モデルの公開が簡単になり、論理的な作業ユニットの境界を宣言的に指定することが容易になります。JDeveloperではUI中心のフレームワークおよびタグ・ライブラリも提供され、これによりビュー・レイヤーおよびコントローラ・レイヤーを簡単に実装できます。

インタフェース/実装の分離

コンポーネントのAPIまたはインタフェースが、その実装クラスから正確に分離されます。

ADFビジネス・コンポーネントにより、クライアント層から(インタフェースを介して)アクセス可能な機能とそのビジネス層の実装の論理的な分離が強制されます。カスタム・インタフェースおよびクライアント・プロキシ・クラスの作成は、JDeveloperにより自動的に処理されます。

サービス・ロケータ

クライアントからより簡単に使用できるように、サービスの検索に関する技術的な詳細情報が抽象化されます。

ADFアプリケーション・モジュールの検索に使用されるシンプルな構成オブジェクトにより、背後にあるサービス・インスタンスを検索するための低レベルの詳細情報が隠蔽されます。Fusion Webアプリケーションの場合は、アプリケーション・モジュール・プール(一連のサービス・コンポーネントから構成される軽量プールであり、アプリケーションの拡張性を改善する)の実装も隠蔽されます。

制御の逆転

格納側コンポーネントは、ユーザーがコードの実行時期よりも実行内容を重視できるように、適切な時期にオーバーライド可能な特定のメソッドを起動することで、格納しているコンポーネントのライフサイクルを調整します。

ADFコンポーネントには、アプリケーションの処理過程で必要に応じてフレームワークによって起動される、オーバーライドが容易な一連のメソッドが含まれています。

依存関係インジェクション

コンポーネントの構成とコンテナへのアセンブリを保留することにより、アプリケーション・コードが簡単になり、構成の柔軟性が高くなります。

ADFビジネス・コンポーネントは、外部のXMLメタデータ定義ファイルからそのすべてのコンポーネントを構成します。実行時に、そのフレームワークにより、ビュー・オブジェクト・インスタンスのような依存オブジェクトはアプリケーション・モジュール・サービス・コンポーネントに、エンティティ・オブジェクトはビュー行に自動的に注入されるので、遅延ロードが実装されます。コンポーネントのカスタマイズされた任意のサブクラスによる該当コンポーネントの実行時ファクトリ置換がサポートされるので、オンサイトでのアプリケーションのカスタマイズが容易になります。ADFビジネス・コンポーネント機能の大半はバリデータ・サブスクリプションおよびリスナー・サブスクリプションの動的注入によって実装されますが、それにより、XMLメタデータ内の各コンポーネントで構成されている宣言的な機能に基づいて、フレームワークのやり取りが調整されます。

アクティブ・レコード

データベース表またはデータベース・ビュー内の1行をラップしてデータベース・アクセスをカプセル化し、該当するデータ上でドメイン・ロジックを追加するようなオブジェクトを提供することにより、「すべてのものからすべてのものへ」というオブジェクト・リレーショナル・マッピングの複雑性が回避されます。

継承、関連付け、コンポジットのサポートなど、最も頻繁に使用されるデータベース・マッピング機能はADFエンティティ・オブジェクトにより処理されますので、ユーザーはオブジェクト・リレーショナル・マッピングに重点を置く必要はありません。また、これらのオブジェクトは、宣言的なビジネス・ルールと1回限りのプログラム的なビジネス・ドメインの両方をカプセル化する場所も提供します。

データ・アクセス・オブジェクト

依存オブジェクトをそれぞれ個別にエンタープライズBeanとして実装するのではなく、一連の軽量の永続クラスとして実装することにより、不要なマーシャリングのオーバーヘッドを防ぎます。永続性に関する詳細が、メンテナンスが簡単な単一のクラスに分離されます。

ADFビュー・オブジェクトは、SQL文を使用してデータを読み取るためのデータ・アクセスの実装を自動化します。ADFエンティティ・オブジェクトは、軽量ビジネス・エンティティの永続的な保存を自動化します。ADFのビュー・オブジェクトとエンティティ・オブジェクトが協力して提供する高度で高性能なデータ・アクセス・オブジェクト層では、ビュー・オブジェクトを介して問合せが行われるデータを任意で完全に更新可能にすることもできます。アプリケーションを処理するコードを記述する必要はありません。

セッション・ファサード

セッションBeanを使用してエンティティBeanをラップすることにより、エンティティBeanの非効率的なクライアント・アクセスと機密性の高いビジネス情報の不注意な露見を防ぎます。

ADFアプリケーション・モジュールは、サポートされているどのデプロイ・モードでも粒度の粗いサービス・ファサード・アーキテクチャを実装するように設計されています。サービス・インタフェースとしてデプロイされると、セッション・ファサード・パターンが自動的に実装されます。

値オブジェクト

1回かぎりのトランスポート・オブジェクトを作成し、クライアント・プログラムに必要な、関連する一連の属性をグループ化することにより、ネットワークの不必要なラウンドトリップを防ぎます。

ADFビジネス・コンポーネントによって実装される汎用的なRowオブジェクトは、クライアントからアクセスする必要がある任意の数および種類の属性から構成されるメタデータ・ドリブンのコンテナです。開発者は、汎用的なRowインタフェースを使用して遅延バインドのgetAttribute("Price")コールおよびsetAttribute("Quantity")コールを実行するか、OverdueOrdersRowのような早期バインドのRowインタフェースを生成して、getPrice()やsetQuantity()のような型保証メソッド・コールを有効にすることができます。ADF Rowオブジェクトは、単純な属性の集合よりも洗練されており、実行時に見直して行内の属性の数、名前およびタイプを規定することが可能なため、高度で汎用的なソリューションを実装することができます。

ページごとのイテレータ

1つの大きな塊をページサイズの一連のチャンクに分割して表示することにより、不必要なデータの送信を防ぎます。

ADFビジネス・コンポーネントによって実装される汎用的なRowSetインタフェースは、ビュー・オブジェクトSQL問合せの実行によって生成された結果セットを管理します。このRowSetを使用して望ましいページサイズ(たとえば10行)を設定し、そのページサイズのチャンク単位で問合せ結果のページを上下に移動できます。データは遅延して取得されるため、ユーザーが実際にアクセスしたデータのみがバックエンドでデータベースから取得され、クライアント層ではページ内の一連の行がネットワークを介して1回のラウンドトリップで返されます。

優先リーダー

JDBC APIに直接アクセスすることにより、読取り専用データに対する不必要なオーバーヘッドを防ぎます。これにより、アプリケーションはクライアントの要求がほんのわずかであるときに、主キーを基準にすべての属性を検索するのではなく、表示する必要のある属性のみを取得できるようになります。一般に、RAW JDBCレベルで実行される問合せは、エンタープライズBeanで表されるビジネス情報に対して行われたが、保留になっている変更を「見ない」ため、このパターンを実装すると、パフォーマンスでのデータの一貫性が犠牲になります。

ADFビュー・オブジェクトは最適なパフォーマンスのためにデータベースから直接データを読み込みますが、データの一貫性に関する選択肢も用意されています。保留中の変更についての更新の可能性や一貫性が重要である場合は、ビュー・オブジェクトと、ビジネス・データが提示されているエンティティ・オブジェクトとの関連付けのみが必要です。一貫性は問題ではない場合、ビュー・オブジェクトは単純に問合せを実行できます。オーバーヘッドは発生しません。どちらの場合も、JDBCデータ・アクセス・コードを記述する必要はありません。XMLディスクリプタへの適切なSQL文の提供のみが必要です。

(Bean)ファクトリ

外部構成が可能な情報に基づいて、指定のインタフェースまたはスーパークラスの適切なサブクラスのインスタンス化および構成を実行時に実行できます。

すべてのADFのコンポーネントのインスタンス化は、ファクトリ・クラスを使用し、XML構成メタデータに基づいて実行されます。そのため、特殊なコンポーネントの実行時置換が可能になり、アプリケーションのカスタム化が促進されます。

エンティティ・ファサード

1つ以上のビジネス・エンティティのデータおよび動作の制限的ビューを提供します。

ADFのビュー・オブジェクトは、基礎となる1つ以上のエンティティ・オブジェクトの組合せから属性およびメソッドの任意のセットを公開し、操作対象となる単一の論理値オブジェクトをクライアントに提供できます。

Value Messenger

クライアントの値オブジェクトの属性と、双方向に表示される中間層のビジネス・エンティティ情報の同期が維持されます。

ADFビジネス・コンポーネントの値オブジェクトの実装により、クライアント側値オブジェクトとの調整が実行され、EJB層に対するバッチ属性変更のキャッシング、および中間層ビジネス・ロジックの結果として発生するバッチ属性更新の受信が実行されます。ADF Value Messengerの実装は、これを実現するためのどのような種類の非同期メッセージングも必要としないように設計されています。

続行

ステートレスなWebソリューションの拡張性を備えたステートフルなプログラミング・モデルの容易さおよび生産性を提供します。

この付加価値は、ADFビジネス・コンポーネントのアプリケーション・モジュール・プーリングと状態管理機能を組み合せたものです。アプリケーション・モジュール・プーリングにより、個々のユーザーにアプリケーション・サーバー層リソースを割り当てる必要がなくなり、ユーザーによる調整が可能で、ユーザー・アフィニティについてステートレスな最適化がサポートされます。

F 一般的なOracle Formsのトリガーに相当するADFの機能

この付録では、Oracle Formsのよく使用されるトリガーを使って実行される基本タスクをOracle ADFを使用して実行する方法の概要を示します。

この付録の内容は次のとおりです。

- 検証とデフォルト設定(ビジネス・ロジック)

- 問合せ処理

- データベース接続

- トランザクション後の処理(レコード・キャッシュ)

- エラー処理

F.1 検証とデフォルト設定(ビジネス・ロジック)

表F-1 Oracle Formsの検証およびデフォルト設定トリガーに相当するADFの機能

Formsのトリガー

相当するADFの機能

WHEN-VALIDATE-RECORD

レコード・レベルで検証コードを実行します。

エンティティ・オブジェクトのカスタムなEntityImplクラスで、validateXXXX()のようなメソッド名を持ち、boolean型を返すpublicメソッドを作成し、検証に成功するとtrue、検証に失敗するとfalseを返すようにします。その後、エンティティ・レベルで、この検証メソッドのメソッド・バリデータをエンティティ・オブジェクトに追加します。その実行時に、検証エラー・メッセージとルールを関連付けることができます。

WHEN-VALIDATE-ITEM

フィールド・レベルで検証コードを実行します。

エンティティ・オブジェクトのカスタムなEntityImplクラスで、booleanを返し、属性と同じデータ型の引数を1つ受け取る(validateXXXX()のようなメソッド名を持つ)publicメソッドを作成します。このメソッドで、検証に成功するとtrue、検証に失敗するとfalseを返すようにします。その後、適切な属性の属性レベルで、この検証メソッドのメソッド・バリデータをエンティティ・オブジェクトに追加します。その実行時に、検証エラー・メッセージとルールを関連付けることができます。

WHEN-DATABASE-RECORD

データ・ブロック内の行に挿入または更新のマークが付けられるとコードを実行します。

エンティティ・オブジェクトのaddToTransactionManager()メソッドをオーバーライドします。スーパー・メソッドをコールした後、コードを記述します。

WHEN-CREATE-RECORD

データ・ブロック内で新規レコードが作成されると、該当レコードの変更ステータスを変更することなくコードを実行し、複雑なデフォルト値を移入します。

エンティティ・オブジェクトのcreate()メソッドをオーバーライドし、スーパー・メソッドをコールした後、該当するsetAttrName()メソッドを使用して属性のデフォルト値を必要に応じて設定します。

主キー属性に順序値を即時に設定するには、SequenceImplヘルパー・クラスのインスタンスを作成し、そのgetSequenceNumber()メソッドをコールして次の順序番号を取得します。この値は、主キー属性に割り当てます。

新しいレコードが保存されるまで順序番号の割当てを待機するものの、データベース・トリガーは使用しない場合は、エンティティ・オブジェクト内のオーバーライドしたprepareForDML()メソッドの中でこの方法を使用できます。

また、独自のBEFOREINSERTFOREACHROWデータベース・トリガーを使用して順序値から主キーを割り当てるには、通常のNumber型ではなくDBSequenceという特殊なデータ型を主キー属性で使用します。

WHEN-REMOVE-RECORD

行がデータ・ブロックから削除されるとコードを実行します。

エンティティ・オブジェクトのremove()メソッドをオーバーライドし、スーパー・メソッドをコールする前またはコールした後でコードを記述します。

F.2 問合せ処理

表F-2 Oracle Formsの問合せ処理トリガーに相当するADFの機能

Formsのトリガー

相当するADFの機能

PRE-QUERY

データ・ブロック内で問合せが実行される前にロジックを実行します(通常は、「サンプル・レコード」内のQuery-By-Example基準の値を設定することが目的)。

ビュー・オブジェクト・クラスのexecuteQueryForCollection()メソッドをオーバーライドし、スーパー・メソッドをコールする前にコードを記述します。

ON-COUNT

データ・ブロックの問合せのヒット数をカウントするためのデフォルトの動作をオーバーライドします。

ビュー・オブジェクト内のgetQueryHitCount()メソッドをオーバーライドし、スーパー・メソッドをコールする以外の処理を実行します。

POST-QUERY

データ・ブロックのデータ・ソースから各行を取得した後、ロジックを実行します。

一般に、POST-QUERYスタイルの方法を使用して現在の行内の外部キー値に基づいて他の表から説明をフェッチするかわりに、ADFでは問合せ内で必要な全情報をメイン表および補助/検索値表から結合して、関与するエンティティ・オブジェクトが複数存在するビュー・オブジェクトを構築する方が効率的です。この方法では、データベースに対する1回のラウンドトリップで、必要な情報がすべて得られます。POST-QUERYのような、行がフェッチされるたびに実行されるトリガーが必要な場合は、ビュー・オブジェクト・クラス内のcreateInstanceFromResultSet()メソッドをオーバーライドします。

ON-LOCK

データ・ブロック内の現在の行でロックの取得を試行するためのデフォルトの動作をオーバーライドします。

エンティティ・オブジェクト・クラス内のlock()をオーバーライドし、スーパー・メソッドをコールする以外の処理を実行します。

F.3 データベース接続

表F-3 Oracle Formsのデータベース接続トリガーに相当するADFの機能

Formsのトリガー

相当するADFの機能

POST-LOGON

データベースにログオンした後にロジックを実行します。

カスタムなアプリケーション・モジュールのafterConnect()メソッドをオーバーライドします。アプリケーション・モジュール・インスタンスは接続されたままでも、他の論理クライアント・セッションにサービスを提供できるため、prepareSession()メソッドをオーバーライドできます。これは最初のログインの後、および最後にアクセスしたユーザーとは異なるユーザーがこのアプリケーション・モジュールにアクセスした後に起動されます。

PRE-LOGOUT

データベースからログアウトする前にロジックを実行します。

カスタムなアプリケーション・モジュール・クラスのbeforeDisconnect()メソッドをオーバーライドします。

F.4 トランザクション後の処理(レコード・キャッシュ)

表F-4 Oracle Formsのトランザクション・トリガーに相当するADFの機能

Formsのトリガー

相当するADFの機能

PRE-COMMIT

変更された行の処理がトランザクション内のすべてのデータ・ブロックで開始される前にコードを実行します。

カスタムなDBTransactionImplクラス内のcommit()メソッドをオーバーライドし、スーパー・メソッドをコールする前にコードを記述します。

注意:

カスタムのDBTransaction実装の作成と使用の概要は、「カスタム・データベース・トランザクション・フレームワーク拡張クラスの作成」を参照してください。

PRE-INSERT

後処理中にデータ・ブロック内の新しい行がデータベースに挿入される前にコードを実行します。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_INSERTに等しい場合は、スーパー・メソッドをコールする前にコードを記述します。

ON-INSERT

後処理中に新しい行がデータベースに挿入されるというデフォルト処理をオーバーライドします。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_INSERTに等しい場合は、スーパー・メソッドをコールするかわりにコードを記述します。

POST-INSERT

後処理中にデータ・ブロック内の新しい行がデータベースに挿入された後にコードを実行します。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_INSERTに等しい場合は、スーパー・メソッドをコールした後でコードを記述します。

PRE-DELETE

後処理中にデータ・ブロック内の行がデータベースから削除される前にコードを実行します。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_DELETEに等しい場合は、スーパー・メソッドをコールする前にコードを記述します。

ON-DELETE

後処理中にデータ・ブロック内の行がデータベースから削除されるというデフォルト処理をオーバーライドします。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_DELETEに等しい場合は、スーパー・メソッドをコールするかわりにコードを記述します。

POST-DELETE

後処理中にデータ・ブロック内の行がデータベースから削除された後にコードを実行します。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_DELETEに等しい場合は、スーパー・メソッドをコールした後でコードを記述します。

PRE-UPDATE

後処理中にデータ・ブロック内で変更された行がデータベース内で更新される前にコードを実行します。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_UPDATEに等しい場合は、スーパー・メソッドをコールする前にコードを記述します。

ON-UPDATE

後処理中にデータ・ブロック内で変更された行がデータベース内で更新されるというデフォルト処理をオーバーライドします。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_UPDATEに等しい場合は、スーパー・メソッドをコールするかわりにコードを記述します。

POST-UPDATE

後処理中にデータ・ブロック内で変更された行がデータベース内で更新された後にコードを実行します。

エンティティ・クラス内のdoDML()メソッドをオーバーライドします。もし、operationがDML_UPDATEに等しい場合は、スーパー・メソッドをコールした後でコードを記述します。

POST-FORMS-COMMIT

Formsが必要な行をすべてデータベースにポストしてから、データ・コミットを発行してトランザクションを終了する前にコードを実行します。

トランザクション全体を単一のコード・ブロックにする場合は、カスタムなDBTransactionImplオブジェクト内のdoCommit()メソッドをオーバーライドし、スーパー・メソッドをコールする前にコードを記述します。

トランザクション内で影響を受けるエンティティごとにコミットを実行する前に、エンティティに固有なコードを実行するには、エンティティ・オブジェクトのbeforeCommit()メソッドをオーバーライドして、そこにコードを記述します。

POST-DATABASE-COMMIT

データベース・トランザクションがコミットされた後にコードを実行します。

カスタムなDBTransactionImplクラス内のcommit()メソッドをオーバーライドし、スーパー・メソッドをコールした後でコードを記述します。

F.5 エラー処理

表F-5 Oracle Formsのエラー処理トリガーに相当するADFの機能

Formsのトリガー

相当するADFの機能

ON-ERROR

エラーを処理するためのデフォルトの動作をオーバーライドします。

ADF BindingContextにカスタムなエラー・ハンドラ(DCErrorHandler)をインストールします。

G Oracle ADFでの一般的なOracle Formsのタスクの実行

この付録では、一般的なOracle FormsのタスクがOracle ADFにどのように実装されているかについて説明します。Oracle Formsでは、一部のタスクをデータ・ブロックで実行し、その他のタスクをUIで実行します。このため、この付録はデータに関連するタスクと、UIに関連するタスクの2つの項に分けられています。

この付録の内容は次のとおりです。

- Oracle Forms開発者が理解しやすい概念

- データ関連タスクの実行

- ユーザー・インタフェース関連タスクの実行

G.1 Oracle Forms開発者が理解しやすい概念

ADFビジネス・コンポーネントは、ユーザー・インタフェースに依存しない方法で、Oracle Formsのデータ中心のすべてのラインタイム機能を実装します。表G-1に示すように、問合せとエンティティ関連で機能の役割が明確に区別され、より適切に再利用できます。

表G-1 Oracle Forms開発者向けの概念

概念

Oracle ADFへのマッピング

類似点

ヘッドレス・フォーム・モジュール

アプリケーション・モジュール

アプリケーション・モジュール・コンポーネントは、フォームのデータ部分です。アプリケーション・モジュールは、クライアント・インタフェースで処理が必要なマスター/ディテール関連の問合せに関するデータ・モデルを含む、スマート・データ・サービスです。また、これに含まれるコンポーネントで使用されるトランザクションとデータベース接続を提供します。このコンポーネントには、サービス実装においてカプセル化される、サービス・メソッドと呼ばれるフォーム・レベルのプロシージャおよびファンクションが含まれています。このプロシージャやファンクションのうち、どれをプライベートに設定し、どれをパブリックに設定するかを決定できます。

Formsレコード・マネージャ

エンティティ・オブジェクト

エンティティ・オブジェクト・コンポーネントは、前述のデータ・ブロック機能のうち、検証およびデータベース変更に関する部分を実装します。Formsの実行時には、この処理はレコード・マネージャによって実行されます。レコード・マネージャは、適切なタイミングでのブロック・レベルやアイテム・レベルでの検証トリガーの実行、およびデータベースへの変更の格納に関する調整を行うため、データ・ブロックのどの行が変更されたかを追跡します。この処理は、まさにエンティティ・オブジェクトが実行するものです。エンティティ・オブジェクトとは、基礎となるベース表によってビジネス・ドメインのエンティティを表すコンポーネントです。エンティティ・オブジェクトでは、ビジネス・オブジェクトの検証、デフォルト設定、データベース変更処理に関連するビジネス・ロジックをカプセル化するための場所を提供します。

データ・ブロック

ビュー・オブジェクト

ビュー・オブジェクト・コンポーネントは、データ・ブロック機能のうち、データの取得を実行します。各ビュー・オブジェクトではSQL問合せをカプセル化し、実行時にはそれぞれの問合せ結果セットを管理します。マスター/ディテール関連で2つ以上のビュー・オブジェクトを接続する場合、その調整は自動的に処理されます。ビュー・オブジェクトを定義する際、すべての問合せ列を、基礎となるエンティティ・オブジェクトにリンクさせることができます。この情報を取得することにより、ビュー・オブジェクトとエンティティ・オブジェクトは実行時に自動的に連携し、ユーザーのタスクで必要となるビジネス・データの形態にかかわらず、ドメインのビジネス・ロジックを実行します。

G.2 データ関連タスクの実行

Oracle Formsでは、データにのみ関連するタスクはデータ・ブロックで実行されます。Oracle ADFでは、これらのタスクは、データを保持するビジネス・コンポーネント(エンティティ・オブジェクト)と、データを問い合せるオブジェクト(ビュー・オブジェクト)で実行されます。

G.2.1 外部キーに対する検索表示値の取得方法

Oracle Formsでは多くの場合、編集可能な表に別の表への外部キー検索列があります。この表示値はわかりやすく、関連表に存在する外部キー列の値に対応しています。一般的には、このような関連表示値は、ユーザーに対して表示される必要があります。

Formsでは、非データベースのアイテムをデータ・ブロックに追加し、ブロックレベルのPOST-QUERYトリガーをデータ・ブロックに追加し、さらにそれぞれの外部キー属性にSQLのSELECT文を記述する必要があったため、これは複雑なタスクでした。また、ユーザーがデータを変更する場合は、外部キーの値をアイテム・レベルのWHEN-VALIDATE-ITEMトリガーで同期化させる必要がありました。Oracle ADFでは、この処理ははるかに簡単です。

Oracle ADFでのタスクの実装

1. 次を含むビュー・オブジェクトを作成します。

- プライマリ・エンティティ・オブジェクトの慣用名として、メインとなる編集可能なエンティティ・オブジェクト

- 基礎となる表が表示テキストを含む、1つ以上の関連エンティティに対するセカンダリ「参照」エンティティ・オブジェクトの慣用名

詳細は、「エンティティ・ベースのビュー・オブジェクトに対する結合の作成方法」を参照してください。

2. 「参照エンティティ・オブジェクトの慣用名からの追加属性の選択方法」の説明に従い、必要な属性(表示テキストが最低限必要です)をセカンダリ・エンティティ・オブジェクトの慣用名から選択します。
実行時には、メイン・エンティティのデータおよび関連する検索表示フィールドすべてのデータが単一結合でデータベースから取得されます。

ユーザーがデータを変更できる場合、追加の手順は必要ありません。ユーザーが外部キー属性の値を変更する場合は、関連付けられた表の新規の関連行について参照情報を自動的に取得します。

G.2.2 データベースからのシステム日付の取得方法

Oracle Formsでは、現在の日時を取得する場合はデータベースからsysdateを取得します。Oracle ADFでは、JavaメソッドやGroovy式を使用してシステム日付を取得するオプションもあります。

Oracle ADFでのタスクの実装

データベースからシステム日付を取得するには、次のGroovy式をエンティティ・レベルで使用します。

DBTransaction.currentDbTime

注意:

DBTransaction参照は、エンティティ・レベルのGroovy式専用です。

このGroovy式を使用してデフォルト値を属性に割り当てる場合は、「式を使用してデフォルト値を定義する方法」を参照してください。

Javaからシステム日付を取得するには、getCurrentDate()メソッドをコールします。詳細は、「現在の日時へのアクセス」を参照してください。

G.2.3 読取り一貫性のない分離モードの実装方法

Oracle Formsでは、読取り一貫性、つまりSQL文が発行されたタイミングのデータの状態を示すデータベースの機能が考慮されます。

Oracle ADFでのタスクの実装

エンティティ・ベースのビュー・オブジェクトを使用する場合は、問合せにより、保留中のトランザクションで、現在のユーザーのセッションごとに処理中の変更を参照できます。これはデフォルト動作であり、最も正確なものです。

また、現在のユーザーによる保留中の変更を考慮せず、データベースのデータのスナップショットを必要とする場合は、読取り専用ビュー・オブジェクトを使用し、問合せを再実行して、最新のコミット済データベース値を参照できます。読取り専用ビュー・オブジェクトの詳細は、「カスタムSQLモード・ビュー・オブジェクトの作成方法」を参照してください。

G.2.4 計算済フィールドの実装方法

計算済フィールドは通常、2つの値の合計を示す場合に使用されますが、2つ以上のフィールドの連結値またはメソッド・コールの結果にも使用できます。

Oracle ADFでのタスクの実装

計算属性はその値がプログラムで容易に取得できるため、データベースには保存されません。中間層で使用されるが、データベースには格納されない属性は一時属性と呼ばれます。一時属性はエンティティ・オブジェクト・レベルまたはビュー・オブジェクト・レベルで定義できます。

一時属性が、1つのエンティティ・オブジェクトをベースとしている可能性がある複数のビュー・オブジェクトで使用されている場合は、エンティティ・オブジェクト・レベルの属性を定義します。これを定義しない場合は、特定のビュー・オブジェクトに対するビュー・オブジェクト・レベルの一時属性を定義します。

一時属性をエンティティ・オブジェクト・レベルで定義するには、「エンティティ・オブジェクトへの一時属性および計算属性の追加」を参照してください。一時属性をビュー・オブジェクト・レベルで定義するには、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。

G.2.5 ミラー・アイテムの実装方法

Oracle Formsでは、ミラー・アイテムを使用して同一の値を共有する2つ以上のフィールドを表示できます。

Oracle ADFでのタスクの実装

UIとデータは分離されるため、ミラー・アイテムをOracle ADFで保持する必要はありません。同一の値を持つミラー・アイテムを作成しなくても、任意の数のページに同一のビュー・オブジェクトを表示できます。同様に、1つのフォームの複数の箇所に同一のフィールドを表示できますが、これをミラーリングする必要はありません。

G.2.6 タイプCLOBまたはBLOBのデータベース列の使用方法

標準データベース型で作業する場合、Oracle ADFでCLOBおよびBLOBタイプの使用方法を把握する必要があります。

Oracle ADFでのタスクの実装

Oracle ADFでは、組込みデータ型ClobDomainまたはBlobDomainを使用します。これらは、このような列タイプのある既存の表から、エンティティ・オブジェクトまたはビュー・オブジェクトをリバース・エンジニアリングする場合に自動的に作成されます。詳細は、「エンティティ・オブジェクト属性のデータベースおよびJavaデータ型を設定する方法」を参照してください。

G.3 ユーザー・インタフェース関連タスクの実行

Oracle ADFとOracle Formsでは、一般的なUI関連タスク(マスター/ディテール画面、値のポップアップ・リスト、ページ・レイアウトなど)の処理が大きく異なります。

G.3.1 ページのレイアウト方法

JSFのコンテナベースのアプローチとは異なり、Oracle Formsは絶対ピクセルまたはポイントベースのレイアウトに基づいています。

Oracle ADFでのタスクの実装

Oracle ADFでのページのレイアウト方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

G.3.2 キャンバスのスタック方法

Oracle Formsでは、スタック・キャンバスは通常、画面領域の表示および非表示に使用されていました。

Oracle ADFでのタスクの実装

Oracle ADFで、スタック・キャンバスに相当するのは、renderedプロパティをtrueまたはfalseに設定したパネル(レイアウト・コンテナ)です。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

G.3.3 マスター/ディテール画面の実装方法

Oracle ADFでは、マスター/ディテール関係は、ビュー・リンクを介して調整されます。ビュー・リンクは、概念的にはOracle Formsのリレーションに類似しています。

Oracle ADFでのタスクの実装

ビュー・リンクの作成方法の詳細は、「マスター/ディテール階層における複数表の使用」を参照してください。ビュー・リンクで2つのビュー・オブジェクトの関係を確立した後は、「データ・モデルでアクティブなマスター/ディテール調整を有効化する方法」を参照してください。

G.3.4 問合せ入力画面の実装方法

Oracle Formsには、問合せ入力画面の作成という一般的なタスクもありました。つまり、画面は検索モードで始まります。

Oracle ADFでのタスクの実装

Oracle ADFでは、これは検索フォームで行われます。検索フォームの作成方法の詳細は、「ADFによるデータバインドされた検索フォームの作成」を参照してください。特に、「ビュー基準に検索フォーム・プロパティを設定する方法」を参照する必要があります。

G.3.5 更新可能な複数レコード表の実装方法

Oracle Formsでは、多数のレコードを同時に編集および挿入できる表を作成できます。Oracle ADFでは、既存レコードの編集と新規レコードの作成の操作は同じではないため、JSFページを使用する場合は若干複雑になります。

Oracle ADFでのタスクの実装

Oracle ADFでは、この場合、入力表を使用します。入力表を作成するには、「入力表の作成」を参照してください。

G.3.6 ポップアップ値リストの作成方法

Oracle Formsでは、簡単に値リスト(LOV)オブジェクトを作成し、そのオブジェクトを宣言でフィールドに関連付けることができました。このLOVにより、ポップアップ・ウィンドウが表示され、次のことが可能になります。

- モーダル値の選択

- LOVダイアログの最上部での問合せ

- 複数列の表示

- LOVを起動したフィールドのコンテンツに基づく、LOVコンテンツの自動縮小

- LOV機能の起動時に、フィールドの値に一致する値が1つのみの場合のリスト値の自動選択

- LOVでキャッシュされた値に基づく、フィールド値の検証

- フィールド・コンテンツが有効でない場合のLOVの自動ポップアップ

Oracle ADFでのタスクの実装

Oracle ADFにポップアップ・リストを実装するには、LOV型となるビュー・オブジェクトの属性のいずれかを構成し、UIヒントのスタイルとして、「値リストを使用した入力テキスト」を選択します。手順の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

G.3.7 ドロップダウン・リストの値リストとしての実装方法

Oracle Formsでは、値リスト(LOV)オブジェクトを作成し、そのオブジェクトを宣言でフィールドに関連付けることができました。Oracle ADFでは、複数の利用可能な値がある検索フィールドに使用できる、検索項目のあるLOV(検索値)画面を実装できます。

Oracle ADFでのタスクの実装

Oracle ADFにドロップダウン・リストを実装するには、LOV型となるビュー・オブジェクトの属性のいずれかを構成し、UIヒントのスタイルとして、「値リストを使用した入力テキスト」を選択します。手順の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

G.3.8 別表からの値のあるドロップダウン・リストの実装方法

Oracle Formsでは、値リスト(LOV)オブジェクトを作成し、そのオブジェクトを宣言でフィールドに関連付けることができました。Oracle ADFでは、別の表にある文字列値を使って、ドロップダウン・リストを実装できます。これらの文字列値は、画面がベースとしている表への有効な入力であるIDコードとともに、フィールドに移入されます。

Oracle ADFでのタスクの実装

Oracle ADFにこのタイプのドロップダウン・リストを実装するには、LOV型となるビュー・オブジェクトの属性のいずれかを構成し、UIヒントのスタイルとして、「選択リスト」を選択します。手順の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。

G.3.9 即時ロックの実装方法

Oracle ADFでは、ユーザーが特定のレコードを変更しようとしていることが明確になった瞬間に、データベースのレコードをロックできます。

Oracle ADFでのタスクの実装

行の即時ロックは、デフォルトではなく、Webアプリケーション・シナリオでは通常使用されませんが、ADFビジネス・コンポーネントで構成できます。Webアプリケーションでは、デフォルトの構成設定jbo.locking.mode=optimisticを使用します。詳細は、「Fusion Webアプリケーションがオプティミスティック・ロックを使用していることを確認する方法」を参照してください。

G.3.10 レコードがロックされた場合のエラーのスロー方法

レコードがユーザーによってロックされた場合、レコードが更新不可になっていることをエラーのスローによって別のユーザーに通知すると便利です。

Oracle ADFでのタスクの実装

行のロック、および行がロックされている場合の例外スローは、ADFビジネス・コンポーネントの機能に組み込まれています。エラー・メッセージを処理する方法は、静的エラー・メッセージ、または現在行に関する情報を含むカスタム・メッセージのどちらが必要かによって異なります。

- 静的メッセージをスローするには、データ・モデル・プロジェクトにバンドルされているカスタム・メッセージを登録し、デフォルトのRowAlreadyLockedExceptionのエラー・メッセージをより明確でわかりやすいものに置き換えます。

- 行に関する情報を含むメッセージをスローするには、RowAlreadyLocked例外を取得するtry/catchブロックを使用して、エンティティ・オブジェクトのlock()メソッドをオーバーライドします。例外を取得したら、現在行に関するより詳細な情報を含むエラー・メッセージをスローできます。

H GlassFishへのADFアプリケーションのデプロイ

この付録では、Oracle ADFアプリケーションをGlassFishアプリケーション・サーバーにデプロイする方法について説明します。具体的には、デプロイメント・ファイルの作成方法、デプロイメント・ディスクリプタの作成方法、およびアプリケーションのデプロイ方法について説明します。

この付録の内容は次のとおりです。

- GlassFish ServerへのADFアプリケーションのデプロイについて

- 統合WebLogic ServerでのADFアプリケーションの実行

- アプリケーションの準備

- アプリケーションのデプロイ

- アプリケーションのテストとデプロイの検証

H.1 GlassFish ServerへのADFアプリケーションのデプロイについて

デプロイは、アプリケーション・ファイルをアーカイブ・ファイルとしてパッケージ化し、ターゲットのGlassFishアプリケーション・サーバーに転送するプロセスです。JDeveloperを使用すると、ADFアプリケーションをGlassFish Serverに直接デプロイするか、またはデプロイ・ターゲットとしてアーカイブ・ファイルに間接的にデプロイし、このアーカイブ・ファイルを対象のGlassFish Serverにインストールできます。アプリケーション開発の際には、JDeveloperを使用して、統合WebLogic Serverでアプリケーションを実行することもできます。

JDeveloperを使用して、次の作業を実行できます。

- 統合WebLogic Serverでのアプリケーションの実行
統合WebLogic Serverを使用してアプリケーションを実行およびデバッグし、スタンドアロンGlassFish Serverにデプロイできます。

- スタンドアロンGlassFish Serverへの直接デプロイ
アプリケーションをスタンドアロンGlassFish Serverに直接デプロイするには、サーバーへの接続を作成し、そのサーバーの名前をデプロイメント・ターゲットとして選択します。

- アーカイブ・ファイルへのデプロイ
デプロイメント・ターゲットとしてEARファイルを選択することによって、間接的にアプリケーションをデプロイすることができます。アーカイブ・ファイルは、ターゲットのGlassFish Serverに後でインストールできます。

H.1.1 統合WebLogic Serverを使用したアプリケーションの開発

JDeveloperでアプリケーションを開発していて、統合WebLogic Serverでアプリケーションを実行する場合、Oracle WebLogic Serverに直接、またはアーカイブ・ファイルにデプロイするために必要なタスクを実行する必要はありません。JDeveloperには統合WebLogic Serverへのデフォルトの接続があるため、デプロイメント・プロファイルやデプロイメント・ディスクリプタは不要です。統合WebLogic Serverには、ADFアプリケーションの実行に必要なADFライブラリを含む事前構成済ドメイン、および-Djps.app.credential.overwrite.allowed=trueの設定が用意されています。JDeveloperのメイン・メニューから「実行」を選択すれば、アプリケーションを実行できます。

「ADFコンポーネントのテストとデバッグ」で説明した機能を使用して、アプリケーションをデバッグできます。

H.1.2 スタンドアロンGlassFish Serverにデプロイするためのアプリケーションの開発

通常、スタンドアロン・サーバーにデプロイするためには、統合WebLogic Serverでアプリケーションを実行してテストと開発を行います。その後、アプリケーションをスタンドアロンGlassFish Serverにデプロイして、アプリケーションのテストをさらに実施できます。

一般にJDeveloperでは、次の作業を行って、デプロイに向けてアプリケーションまたはプロジェクトを準備します。

- ターゲットGlassFish Serverへの接続の作成

- デプロイメント・プロファイルを作成(必要な場合)

- GlassFishに固有のデプロイメント・ディスクリプタの作成

- GlassFish Serverとの互換性を確保するためのapplication.xmlおよびweb.xmlの更新(必要な場合)

GlassFish Serverをあらかじめインストールしておく必要があります。GlassFishを入手およびインストールする手順は、http://glassfish.java.net/download.htmlを参照してください。

また、ADFアプリケーションのデプロイに向けてGlassFish Server準備する必要もあります。詳細は、『Oracle ADFアプリケーションの管理』の付録「GlassFish Serverの構成」を参照してください。

- GlassFish Serverのインストール先へのADFランタイムのインストール:

- JVMキャッシュ・サイズおよびsimpleオプションの設定

- GlassFish Server上でのセキュアな管理の有効化。これにより、リモート・ログインおよびリモート接続が可能になるため、GlassFish以外のマシン上でJDeveloperを実行できるようになります。

- データ・ソースへの接続を必要とするアプリケーションのためのグローバルなJDBCデータ・ソースの作成

アプリケーションとGlassFish Serverの準備が完了したら、次の作業を行うことができます。

- JDeveloperを使用して次を実行します。

- デプロイメント・プロファイルとアプリケーション・サーバー接続を使用して、GlassFish Serverに直接デプロイします。

- デプロイメント・プロファイルを使用して、EARファイルにデプロイします。ADFアプリケーションの場合、WARファイルはEARファイルの一部としてのみデプロイできます。

- GlassFish Serverの管理ツールを使用して、JDeveloperで作成したEARファイルをデプロイします。

H.2 統合WebLogic ServerでのADFアプリケーションの実行

JDeveloperは、統合WebLogic Serverとともにインストールされますが、この統合WebLogic Serverをアプリケーションのテストと開発に使用できます。開発目的では、統合WebLogic Serverで十分なことがほとんどです。アプリケーションをテストする準備が整ったら、実行ターゲットを選び、メイン・メニューから「実行」コマンドを選択します。

注意:

アプリケーションを統合WebLogic Serverで初めて実行する際、「デフォルト・ドメインの作成」ダイアログが表示され、新しいドメインの管理パスワードを定義します。

アプリケーション・ターゲットを実行すると、プロジェクトとワークスペースのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプが自動的に検出されます。次に、アプリケーションを統合WebLogic Serverにデプロイするためのメモリー内デプロイメント・プロファイルが作成されます。プロジェクトとアプリケーション・ワークスペースのファイルは、展開EARディレクトリ構造にコピーされます。このファイル構造は、アプリケーションをEARファイルにデプロイする場合のEARファイル構造を忠実に模したものです。続いて、標準のデプロイ手順に従って、展開EARファイルが統合WebLogic Serverに登録およびデプロイされます。展開EAR方式を取ることで、実際のEARファイルのパッケージ化とパッケージ化解除によって生じるパフォーマンス・オーバーヘッドが軽減されます。

要約すれば、実行ターゲットを選択して統合WebLogic Serverでアプリケーションを実行すると、JDeveloperによって次のことが行われます。

- プロジェクトとアプリケーションのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプを検出

- メモリー内にデプロイメント・プロファイルを作成

- プロジェクトとアプリケーションのファイルを、アプリケーションの展開EARファイルをシミュレートしたファイル構造を持つ作業ディレクトリにコピー

- 模擬EARを統合WebLogic Serverに登録およびデプロイするためのデプロイ・タスクを実行

注意:

統合WebLogic Serverでアプリケーションを実行する際、アプリケーションに対して作成されたデプロイメント・プロファイルは無視されます。

アプリケーションは、統合WebLogic Serverの基本ドメインで実行されます。この基本ドメインは、スタンドアロンのWebLogic Serverインスタンスの基本ドメインと同じ構成になっています。つまり、この基本ドメインは、Oracle Fusion Middleware構成ウィザードを使用して、スタンドアロンのWebLogic Serverインスタンスにデフォルト・オプションで基本ドメインを作成した場合と同一です。

JDeveloperでは、JDeveloperテクノロジ拡張に基づいて、この基本ドメインが必要なドメイン拡張テンプレートで拡張されます。たとえば、JDeveloper Studioをインストールした場合、統合WebLogic Server環境がADFランタイム・テンプレート(JRF Fusion Middlewareランタイム・ドメイン拡張テンプレート)で自動的に構成されます。

統合WebLogic Serverのデフォルト・ドメインを明示的に作成することもできます。このデフォルト・ドメインを使用して、アプリケーションを実行およびテストできます。「アプリケーション・サーバー」ウィンドウを開き、IntegratedWebLogicServerを右クリックして、「デフォルト・ドメインの作成」を選択します。

H.2.1 統合WebLogic Serverでのアプリケーションの実行方法

アプリケーションを統合WebLogic Serverで実行して、テストすることができます。ブレークポイントを設定して、ADF宣言デバッガでアプリケーションを実行することも可能です。

始める前に:

統合WebLogic Serverでアプリケーションを実行するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「統合WebLogic ServerでのADFアプリケーションの実行」を参照してください。

統合WebLogic Serverでアプリケーションを実行するには:

1. 「アプリケーション」ウィンドウで、プロジェクト、バインドなしタスク・フロー、JSFページ、ファイルのいずれかを、実行ターゲットとして選択します。

2. 実行ターゲットを右クリックして、「実行」または「デバッグ」を選択します。

アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

H.3 アプリケーションの準備

ADFアプリケーションをスタンドアロンGlassFish Serverにデプロイする前に、JDeveloperで必須のタスクを実行し、デプロイに向けてアプリケーションを準備する必要があります。

タスクは次のとおりです。

- ターゲット・アプリケーション・サーバーへの接続の作成方法

- デプロイメント・プロファイルの作成方法

- デプロイメント・ディスクリプタの作成および編集方法

- GlassFish用JDBCデータソースの有効化方法

- 初期コンテキスト・ファクトリの変更方法

注意:

ADFセキュリティはGlassFishに対応のADF Essentialsではサポートされていません。GlassFish固有のセキュリティをADFアプリケーションで構成する必要があります。GlassFishセキュリティの構成の詳細は、http://docs.oracle.com/cd/E18930_01/html/821-2418/beabg.html#scrolltocを参照してください。

H.3.1 ターゲット・アプリケーション・サーバーへの接続の作成方法

JDeveloperアプリケーション・サーバー接続を介して、GlassFish Serverにアプリケーションをデプロイできます。

始める前に:

アプリケーション・サーバー接続を作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- GlassFish Serverをインストールします。

アプリケーション・サーバーへの接続の作成方法:

1. 「アプリケーション・サーバー接続」ウィザードを起動します。

次の操作を実行できます。

- 「アプリケーション・サーバー」ウィンドウで、「アプリケーション・サーバー」を右クリックして、「新規アプリケーション・サーバー」を選択します。

- 「新規ギャラリ」で、「一般」を展開し、「接続」→「アプリケーション・サーバー接続」を選択して、「OK」をクリックします。

- 「リソース」ウィンドウで、「新規」→「IDE接続」→「アプリケーション・サーバー」を選択します。

2. 「使用方法」ページの「アプリケーション・サーバー接続の作成」ダイアログで、「スタンドアロン・サーバー」を選択します。

3. 「名前とタイプ」ページで、接続名を入力します。

4. 「接続タイプ」ドロップダウン・リストで、次を選択します。

- GlassFish Serverへの接続を作成する場合は「GlassFish 3.1」

5. 「次へ」をクリックします。

6. 「認証」ページで、GlassFish Serverへのアクセスを認可された管理ユーザーのユーザー名とパスワードを入力します。

7. 「次へ」をクリックします。

8. 「構成」ページで、GlassFish Serverの次の情報を入力します。

- ホスト名: GlassFish Serverが稼働しているマシン名を入力します。名前を入力しない場合は、デフォルトのlocalhostになります。

- RMIポート: 必要に応じて、サーバーのRMIポート番号を変更します。デフォルトは8686です。

- HTTPポート: デフォルトでは、GlassFishはポート8080でHTTPリクエストをリスニングします。このポート番号は必要に応じて変更できます。

- 管理HTTPポート: デフォルトでは、GlassFishはポート4848を管理用として使用します。このポート番号は必要に応じて変更できます。

- セキュアな管理の有効化: GlassFishでリモート・ログインおよびリモート接続を可能にする場合に選択します。

注意:

GlassFish 3.1.2を使用し、GlassFishとは別のマシンでJDeveloperが稼働している場合は、GlassFishでセキュアな管理を有効にし、リモート・ログインできるようにする必要があります。JDeveloperとGlassFishが同一マシン上にある場合は、セキュアな管理を有効にする必要はありません。

9. 「次へ」をクリックします。

10. テスト・ページで、「接続のテスト」をクリックして、接続をテストします。

JDeveloperにより、数種類の接続テストが実行されます。アプリケーションをデプロイできるためには、JSR-88テストに合格する必要があります。テストに不合格だった場合は、ウィザードの前のページに戻って、構成を修正します。

11. 「終了」をクリックします。

H.3.2 デプロイメント・プロファイルの作成方法

デプロイメント・プロファイルでは、ターゲット環境にデプロイされるアーカイブにアプリケーションがパッケージ化される方法が定義されています。デプロイメント・プロファイルには、次の役割があります。

- 作成されるアーカイブ・ファイルのフォーマットと内容を指定します。

- パッケージ対象となるソース・ファイル、デプロイメント・ディスクリプタ、およびその他の補助ファイルをリストします。

- 作成されるアーカイブ・ファイルのタイプおよび名前を記述します。

- 依存情報、プラットフォーム固有の指示、およびその他の情報を示します。

アプリケーションにデプロイするWebユーザー・インタフェース・プロジェクトそれぞれにWARデプロイメント・プロファイルが必要です。アプリケーションレベルのEARデプロイメント・プロファイルも必要になるので、その中に組み込むプロジェクト(WARプロファイルなど)をリストから選択する必要があります。アプリケーションがデプロイされるとき、EARファイルは、デプロイメント・プロファイルで選択されたすべてのプロジェクトを組み込みます。

注意:

ADF Fusion Webアプリケーション・テンプレートを使用してプロジェクトまたはアプリケーションを作成する場合、JDeveloperによりデフォルトのWARおよびEARデプロイメント・プロファイルが自動的に作成されます。通常、デプロイメント・プロファイルを手動で編集または作成する必要はありません。

ADFアプリケーションの場合、アプリケーションはEARファイルとしてのみデプロイできます。デプロイメント・プロファイルを作成する際に、アプリケーションの一部となるWARファイルをEARファイルに組み込む必要があります。

H.3.2.1 WARデプロイメント・プロファイルの作成

アプリケーションにパッケージ化するWebベースのプロジェクトごとに、WARデプロイメント・プロファイルを作成する必要があります。通常、WARプロファイルには必要な依存データ・モデル・プロジェクトが組み込まれます。

始める前に:

WARデプロイメント・プロファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- Webベースのプロジェクトを作成します。ADF Fusion Webアプリケーション・テンプレートを使用した場合は、すでにデフォルトのWARデプロイメント・ファイルが存在します。

アプリケーションのWARデプロイメント・プロファイルを作成するには:

1. 「アプリケーション」ウィンドウで、デプロイするWebプロジェクトを右クリックし、「新規」→「ギャラリから」を選択します。

各WebプロジェクトのWARプロファイルを作成します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「WARファイル」を選択して、「OK」をクリックします。

「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- WARファイル 」ダイアログで、プロジェクト・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「WARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。次のリストの項目は、特定のアプリケーションには該当しないものもあります。

- 「WEB-INF/lib」/「コントリビュータ」パネルで、ADF Facesランタイム11、JSTL 1.2、およびADFm、ADFc、ADFvの各ライブラリがデプロイ済としてマークされていることを確認します。

- 「ファイル・グループ」→「Webファイル」→「フィルタ」→「WEB-INF」を選択し、weblogic.xmlの選択を解除します。

- 「ファイル・グループ」→Webファイル/クラス→「フィルタ」→「META-INF」を選択し、ejb-jar.xmlの選択を解除します。

- 「ファイル・グループ」→Webファイル/クラス→「フィルタ」→「パス」を選択し、serviceinterfaceの選択を解除します。

- 「ファイル・グループ」→Webファイル/クラス→「フィルタ」→「パス」を選択し、「サーバー」の選択を解除します。

- Java EE Webコンテキストのルート設定を変更する必要がある場合もあります。これを行うには、左側のペインで、「一般」を選択します。
デフォルトでは、「プロジェクトのJava EE Webコンテキスト・ルートを使用」が選択されている場合、関連付けられている値は、Application1-Project1-context-rootのようにプロジェクト名に設定されています。ユーザーに違う名前でアプリケーションにアクセスさせる場合は、この名前を変更する必要があります。

- 「プラットフォーム」で「GlassFish 3.1」を選択します。

5. 「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。

6. 「OK」を再度クリックして、プロジェクト・プロパティのダイアログを終了します。

7. デプロイするすべてのWebプロジェクトに対して、手順1から6を繰り返します。

H.3.2.2 アプリケーション・レベルのEARデプロイメント・プロファイルの作成

EARファイルには、アプリケーション・サーバーでアプリケーションを実行するために必要なアプリケーション・アーティファクトがすべて含まれています。ADF Fusion Webアプリケーション・テンプレートを使用した場合は、すでにデフォルトのEARデプロイメント・ファイルが存在します。EARファイルの詳細は、「EARファイルとパッケージ化に関する必知事項」を参照してください。

始める前に:

アプリケーションレベルのEARデプロイメント・プロファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- 「WARデプロイメント・プロファイルの作成」の説明に従って、WARデプロイメント・プロファイルを作成します。

アプリケーションのEARデプロイメント・プロファイルを作成するには:

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックして、「新規」→「ギャラリから」を選択します。

アプリケーションのEARプロファイルを作成します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「EARファイル」を選択して、「OK」をクリックします。

「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- EARファイル」ダイアログで、アプリケーション・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。

- 「ファイル・グループ」→「アプリケーション・ディスクリプタ」→「フィルタ」を選択し、weblogic-application.xmlの選択を解除します。

- 「アプリケーション・アセンブリ」を選択し、続いて「Java EEモジュール」リストで、デプロイメントに組み込むすべてのプロジェクト・プロファイルを選択します(WARプロファイルを含む)。

- 「プラットフォーム」を選択し、デプロイ先となるアプリケーション・サーバーを選択した後、「ターゲット接続」ドロップダウン・リストから、ターゲット・アプリケーション接続を選択します。GlassFishの場合は、「GlassFish 3.1」を選択します。

5. 再度「OK」をクリックして、「EARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。

6. 「OK」を再度クリックして、アプリケーション・プロパティのダイアログを終了します。

注意:

カスタマイズ・クラスがEARクラス・パスに正しく追加されていることを検証するには、EARプロファイルをファイル・システムにデプロイします。その後、EARを調べ、カスタマイズ・クラスJARがEARクラス・パス(EAR/libディレクトリ)で使用でき、WARクラス・パス(WEB-INF/libディレクトリおよびWEB-INF/classesディレクトリ)で使用できないことを確認します。

H.3.2.3 デプロイメント・プロファイル・プロパティの表示および変更

デプロイメント・プロファイルを作成したら、そのプロパティを表示および変更できます。

始める前に:

デプロイメント・プロファイル・プロパティを表示および変更するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

プロジェクトのデプロイメント・プロファイルを作成、編集、または削除するには:

1. 「アプリケーション」ウィンドウで、プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「デプロイ」をクリックします。

「デプロイメント・プロファイル」リストには、現在プロジェクトに定義されているすべてのプロファイルが表示されます。

3. リストから、デプロイメント・プロファイルを1つ選択します。

4. 「編集」または「削除」をクリックして、デプロイメント・プロファイルを編集または削除します。

H.3.3 デプロイメント・ディスクリプタの作成および編集方法

デプロイメント・ディスクリプタは、アプリケーションのデプロイ構成を定義するサーバー構成ファイルで、必要に応じてJava EEアプリケーションとともにデプロイされます。プロジェクトに必要なデプロイメント・ディスクリプタは、プロジェクトが使用しているテクノロジとターゲット・アプリケーション・サーバーのタイプによって異なります。デプロイメント・ディスクリプタは、ソース・ファイルとして作成および編集できるXMLファイルですが、JDeveloperは、ほとんどのディスクリプタ・タイプについて、プロパティの表示と設定に使用できるダイアログまたは概要エディタを備えています。これらのファイルを宣言的に編集できない場合、JDeveloperはその内容を編集するためにソースエディタでXMLファイルを開きます。

標準のJava EEデプロイメント・ディスクリプタ(application.xmlおよびweb.xmlなど)に加えて、ターゲット・アプリケーション・サーバーに固有のデプロイメント・ディスクリプタも使用できます。

H.3.3.1 デプロイメント・ディスクリプタの作成

必要なデプロイメント・ディスクリプタの多くは、自動的に作成されます。必要なデプロイメント・ディスクリプタが存在しない場合や、追加のディスクリプタを作成する必要がある場合は、JDeveloperを使用して作成できます。

始める前に:

デプロイメント・ディスクリプタを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- デプロイメント・ディスクリプタがすでに生成されているかどうかを確認します。

デプロイメント・ディスクリプタの作成方法:

1. 「アプリケーション」ウィンドウで、ユーザー・インタフェース・プロジェクトを開き、「WEB-INF」を選択して、「新規」→「ギャラリから」をクリックします。

2. 「新規ギャラリ」で「一般」を開き、「XMLドキュメント」を選択して、「OK」をクリックします。

3. XMLファイルの作成ダイアログで、ディスクリプタの名前を入力し、「OK」をクリックします。

たとえば、GlassFish固有の情報を定義するためのglassfish-web.xmlを作成できます。

4. 概要エディタでGlassFish用のエントリを追加します。

次の例は、サンプルのglassfish-web.xml記述子を示しています。

glassfish-web.xmlディスクリプタを使用して、web.xmlで定義されていない設定を追加したり、web.xmlですでに定義されている設定を変更できます。たとえば、次に示すように、res-ref-nameおよびjndi-nameというエントリをglassfish-web.xmlに追加することで、web.xmlで定義されているjdbc/Connections1DS設定をオーバーライドできます。glassfish-web.xmlの設定後は、jdbc/NewConnections1DSがjdbc/Connections1DSのかわりに使用されます。ただし、res-ref-nameセクションはオプションです。

<glassfish-web-app>
<context-root>DeptApp-ViewController-context-root</context-root>
<resource-ref>
<res-ref-name>jdbc/Connection1DS</res-ref-name>
<jndi-name>jdbc/NewConnection1DS</jndi-name>
</resource-ref>
<class-loader delegate="false"/>
<property value="true" name="useBundledJsf"/>
</glassfish-web-app>

注意:

EARファイルの場合は、1つのアプリケーションまたはワークスペースに同じタイプの複数のデプロイメント・ディスクリプタを作成しないでください。これらのファイルはプロジェクトに割当て可能ですが、アプリケーション・ワークスペース・スコープがあります。アプリケーションの複数のプロジェクトが同じデプロイメント・ディスクリプタを使用すると、起動されたプロジェクトに属するディスクリプタが他のディスクリプタより優先されます。この制限はapplication.xmlに適用されます。

アプリケーション・レベルのディスクリプタを作成するために最適な場所は、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」ノードです。アプリケーションは、確実に、正しいディスクリプタとともに作成されます。

プロジェクトで作成されたアプリケーションレベル・ディスクリプタは、実行時に無視されます。実行時には、アプリケーション・リソースのディスクリプタ、またはEARレベルで生成されたディスクリプタのみが使用されます。

H.3.3.2 デプロイメント・ディスクリプタ・プロパティの表示または変更

デプロイメント・ディスクリプタを作成したら、JDeveloperの各種ダイアログを使用するか、ソース・エディタでファイルを編集することで、そのプロパティを変更できます。デプロイメント・ディスクリプタは、通常「アプリケーション・ソース」ノードにあるXMLファイル(application.xmlなど)です。

始める前に:

デプロイメント・ディスクリプタを表示または変更するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

デプロイメント・ディスクリプタのプロパティの表示または変更方法:

1. 「アプリケーション」ウィンドウまたは「アプリケーション・リソース」パネルで、デプロイメント・ディスクリプタをダブルクリックします。

2. 概要エディタで、「概要」タブまたは「ソース」タブを選択し、プロパティ値を設定してディスクリプタを構成します。

概要エディタが使用できない場合は、ソース・エディタでファイルが開きます。

H.3.3.3 アプリケーション・サーバー互換のapplication.xmlファイルの構成

ご使用のJava EE 1.5に準拠するようにapplication.xmlファイルを構成しなければならないことがあります。

注意:

通常、プロジェクトには互換性のあるapplication.xmlファイルがあるため、この手順を実行する必要はありません。

始める前に:

application.xmlファイルを構成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

application.xmlファイルを構成するには:

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックして、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」→「Java EEデプロイメント・ディスクリプタ・ウィザード」を選択して、「OK」をクリックします。

3. 「Java EEデプロイメント・ディスクリプタの作成」ダイアログの「ディスクリプタの選択」ページで、「application.xml」を選択して、「次へ」をクリックします。

4. 「バージョンの選択」ページで、Java EE 5.0以上と互換性を持たせるために「5.0」を選択し、「次へ」をクリックします。

5. 「サマリー」ページで「終了」をクリックします。

6. application.xmlファイルを適切な値で編集します。

H.3.3.4 GlassFish Server互換のweb.xmlファイルの構成

ご使用のJava EEバージョンに準拠するようにweb.xmlファイルを構成する必要がある場合があります。

次の例は、JDBC接続の設定を含むweb.xmlファイルを示しています。設定の詳細と必要なその他の設定は、「web.xml」を参照してください。

<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/Connection1DS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

注意:

通常、プロジェクトには互換性のあるweb.xmlファイルがあるため、この手順を実行する必要はありません。プロジェクトを作成すると、初期のweb.xmlファイルが自動的に作成されます。

始める前に:

web.xmlファイルを構成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

web.xmlファイルを構成するには:

1. 「アプリケーション」ウィンドウで、プロジェクトを右クリックして、「新規」→「ギャラリから」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」→「Java EEデプロイメント・ディスクリプタ」を選択して、「OK」をクリックします。

3. 「Java EEデプロイメント・ディスクリプタの作成」ダイアログの「ディスクリプタの選択」ページで、「web.xml」を選択して、「次へ」をクリックします。

4. 「バージョンの選択」ページで、使用するバージョンを選択し、「次へ」をクリックします。

バージョン3.0はJava EE 6.0以上と互換性があり、バージョン2.5はJava EE 5.0と互換性があります。

5. 「サマリー」ページで「終了」をクリックします。

6. 概要エディタでweb.xmlファイルを開きます。

7. 「フィルタ」タブを選択し、JpsFilterを削除します。

H.3.4 GlassFish用JDBCデータソースの有効化方法

アプリケーションでADFビジネス・コンポーネントを使用する場合、アプリケーションの一部としてADFビジネス・コンポーネント用に定義されているデータ・ソースがGlassFishコンテナで定義されているデータ・ソースと一致することを確認しなければならないことがあります。

アプリケーションでJDBCデータソースを使用するようにADFアプリケーションを構成するには、アプリケーションのbc4j.xcfgファイルを編集します。

始める前に:

JDBCの構成時に使用可能な各オプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

JDBCデータソースが有効になるようにbc4j.xcfgファイルを構成するには:

1. 「アプリケーション」ウィンドウで、モデル・プロジェクトを開き、アプリケーション・モジュールをクリックします。

2. アプリケーション・モジュールの概要エディタで「構成」を選択し、bc4j.xcfgをクリックします。

3. bc4j.xcfgの概要エディタで「ソース」タブを選択します。

4. 『Oracle ADFアプリケーションの管理』の付録「GlassFish Serverの構成」で説明するように、ファイル内で定義されているCustom JDBCDataSourceエントリが、GlassFish Server用に定義されているJDBCデータソースと一致することを確認します。

たとえば、次の例は、bc4j.xcfgファイルに定義されているJDBCDataSourceプロパティを示しています。

<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
<AppModuleConfigBag ApplicationName="model.AppModule">
<AppModuleConfig name="AppModuleLocal" jbo.project="model.Model"
ApplicationName="model.AppModule" DeployPlatform="LOCAL">
<Database jbo.TypeMapEntries="OracleApps"/>
<Security AppModuleJndiName="model.AppModule"/>
<Custom ns0:JDBCDataSource="jdbc/OracleDS"
xmlns:ns0="http://xmlns.oracle.com/bc4j/configuration"/>
</AppModuleConfig>
<AppModuleConfig name="AppModuleShared" jbo.project="model.Model"
ApplicationName="model.AppModule" DeployPlatform="LOCAL">
<AM-Pooling jbo.ampool.maxpoolsize="1"
jbo.ampool.isuseexclusive="false"/>
<Database jbo.TypeMapEntries="OracleApps"/>
<Security AppModuleJndiName="model.AppModule"/>
<Custom ns0:JDBCDataSource="jdbc/OracleDS"
xmlns:ns0="http://xmlns.oracle.com/bc4j/configuration"/>
</AppModuleConfig>
</AppModuleConfigBag>
</BC4JConfig>

H.3.5 初期コンテキスト・ファクトリの変更方法

アプリケーション(EJBベースのアプリケーションなど)でJNDI参照が必要な場合は、初期コンテキスト・ファクトリのクラス名をGlassFishコンテキスト・ファクトリに変更する必要があります。

初期コンテキスト・ファクトリを変更するには:

1. 「アプリケーション」ウィンドウで、モデル・プロジェクトを開き、DataControls.dcxファイルをダブルクリックします。

2. 概要エディタで、「ソース」タブをクリックします。

3. initial-context-factory="com.sun.enterprise.naming.SerialInitContextFactory"となるように、initial-context-factoryを編集します。

H.4 アプリケーションのデプロイ

ADFアプリケーションは、JDeveloperを使用してGlassFish Serverに直接デプロイすることも、アーカイブ・ファイルを作成し、他のツールを使用してアプリケーション・サーバーにデプロイすることもできます。

注意:

Oracle ADFを使用するアプリケーションをスタンドアロン・アプリケーション・サーバーにデプロイする前に、ADFランタイム・ライブラリのインストールや構成値の設定などのタスクを実行して、GlassFish Server環境を準備する必要があります。詳細は、『Oracle ADFアプリケーションの管理』の付録「GlassFish Serverの構成」を参照してください。

表H-1に、アプリケーションのデプロイおよびデプロイ・サイクル中に使用できる一般的なデプロイ方法を示します。開発環境でのデプロイから本番環境のデプロイまでの順序でデプロイ方法をリストしています。本番環境では、システム管理者がGlassFish管理コンソールまたはスクリプトを使用してアプリケーションをデプロイします。

表H-1 開発環境または本番環境でのデプロイ方法

デプロイ方法

環境

使用するとき

JDeveloperから直接実行

テストまたは開発

この方法は、アプリケーションの開発中に使用します。編集プロセスとデプロイ・プロセスを何度も繰り返す必要があるからです。

JDeveloperには統合WebLogic Serverが含まれています。この統合WebLogic Serverでアプリケーションを実行してテストできます。

アプリケーションのテストは統合GlassFish Serverではなく統合WebLogic Serverで行います。統合WebLogic Serverでテストを行った後で、スタンドアロンGlassFish Serverにデプロイし、さらにテストを実行できます。

JDeveloperを使用してターゲットGlassFish Serverに直接デプロイ

テストまたは開発

この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。

テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。

JDeveloperを使用してEARファイルにデプロイし、ターゲットのGlassFish Serverのデプロイ用ツールを使用

テストまたは開発

この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。JDeveloperから直接デプロイするかわりに、EARファイルにデプロイしてから、他のツールを使用してアプリケーション・サーバーにデプロイすることができます。

テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。

GlassFishのasadminコマンドまたはGlassFish管理コンソールを使用

本番

アプリケーションがテスト環境と本番環境にある場合です。本番環境では、システム管理者がGlassFishのasadminコマンドまたはGlassFishの管理コンソールを使用する方法が一般的です。

H.4.1 JDeveloperからアプリケーション・サーバーへのデプロイ方法

始める前に:

JDeveloperからアプリケーション・サーバーにデプロイするときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- EARファイルにデプロイするアプリケーションレベルのデプロイメント・プロファイルを作成します。

JDeveloperからターゲット・アプリケーション・サーバーへのデプロイ方法:

1. 「アプリケーション」ウィンドウで、アプリケーションを右クリックして「デプロイ」を選択し、デプロイメント・プロファイルを選択します。

GlassFishデプロイメント・プロファイルが選択されていることを確認してください。

2. 「デプロイ」ウィザードの「デプロイメント・アクション」ページで、「アプリケーション・サーバーへのデプロイ」を選択し、「次へ」をクリックします。

3. 「サーバーの選択」ページで、アプリケーション・サーバー接続を選択し、「次へ」をクリックします。

4. 「終了」をクリックします。

デプロイ中は、処理ステップがデプロイメント・ログ・ウィンドウに表示されます。作成中のモジュールの内容(アーカイブまたは展開EAR)を確認するには、ログ・ウィンドウに表示されたリンクをクリックします。アーカイブ・ファイルまたは展開EARファイルが該当するエディタまたはディレクトリ・ウィンドウで開き、確認できるようになります。

注意:

Java EEアプリケーションをデプロイする場合は、「アプリケーション」ウィンドウ内でJava EEアプリケーションの隣にあるアプリケーション・メニューをクリックします。

アプリケーション・サーバー接続の作成の詳細は、「ターゲット・アプリケーション・サーバーへの接続の作成方法」を参照してください。

H.4.2 JDeveloperからのデプロイに関する必知事項

GlassFish用に作成したEARデプロイメント・プロファイルを使用してアプリケーションをデプロイすると、JDeveloperでは次のことが行われます。

- 必要なADFモデル、ADFコントローラおよびADFビュー・ライブラリJARがEARファイルに挿入されます。

- adf-share-glassfish.jarがWARに挿入されます。

- GlassFishアプリケーション・ライフサイクル・リスナーADFGlassFishAppLifeCycleListenerのエントリがweb.xmlファイルに挿入されます。

- 他のリスナー・エントリ(ADFConnectionLifeCycleCallBack、ADFConfigLifeCycleCallBackおよびBC4JConfigLifeCycleCallBack)がweb.xmlファイルから削除されます。

H.4.3 デプロイメント用のEARファイルの作成方法

デプロイメント・プロファイルを使用してアーカイブ・ファイル(EARファイル)を作成することもできます。後から、GlassFish管理コンソールを使用して、アーカイブ・ファイルをデプロイすることができます。

ADFアプリケーションはEARファイル(通常はWARのコンポーネントを含む)にカプセル化されますが、部分的にEARではデプロイされないことがあります。

始める前に:

デプロイするためにEARファイルを作成するときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

次のタスクを完了する必要があります。

- EARファイルにデプロイするアプリケーションレベルのデプロイメント・プロファイルを作成します。

EARアーカイブ・ファイルを作成するには:

- 「アプリケーション」ウィンドウで、デプロイメント・プロファイルを含むアプリケーションを右クリックし、「デプロイ」→「deployment profile」→「EARファイルへ」を選択します。
EARファイルがアプリケーションレベルでデプロイされ、そのEARファイルにデータ・モデル・プロジェクトのJARファイルとユーザー・インタフェース・プロジェクトのWARファイルへの依存性が存在する場合、各ファイルはデフォルトで次のディレクトリに保存されます。

- ApplicationDirectory/deploy/EARdeploymentprofile.EAR

- ApplicationDirectory/ModelProject/deploy/JARdeploymentprofile.JAR

- ApplicationDirectory/ViewControllerProject/deploy/WARdeploymentprofile.WAR

ヒント:

「表示」→「ログ」を選択し、アーカイブ・ファイルの作成時に生成されたメッセージを表示します。

H.4.4 ADFライブラリに関する必知事項

ADFライブラリは、ADFコンポーネント(ADFタスク・フロー、ページ、アプリケーション・モジュールなど)に対して登録されたJARサービスを含むJARファイルです。プロジェクトのADFコンポーネントを再利用する場合は、プロジェクトのADFライブラリ・デプロイメント・プロファイルを作成してから、そのプロファイルに基づいたADFライブラリJARを作成します。

「リソース」ウィンドウを使用するか、手動でライブラリのクラスパスに追加する方法でADFライブラリJARを追加すると、アプリケーションまたはプロジェクトでそのADFライブラリJARを使用できるようになります。「デフォルトでデプロイ済」オプションが選択されている場合、プロジェクトに追加されたADFライブラリJARは、プロジェクトのWARファイルに組み込まれます。

詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。

H.4.5 EARファイルとパッケージ化に関する必知事項

ADFアプリケーションをEARファイルにパッケージ化する場合、EARファイルには次のものを組み込むことができます。

- WARファイル: Webベースのビュー・コントローラ・プロジェクトはそれぞれWARファイルにパッケージ化します。

- ADFライブラリJARファイル: アプリケーションでADFライブラリJARが使用される場合、そのJARファイルはEARにパッケージ化できます。

- その他のJARファイル: アプリケーションに必要な依存JARファイルが他にもある場合があります。それらはEARにパッケージ化できます。

H.4.6 アプリケーション・サーバーへのasadminコマンドを使用したデプロイ方法

始める前に:

JDeveloperからアプリケーション・サーバーにデプロイするときに使用できるオプションについて理解しておくと役立ちます。詳細は、「アプリケーションの準備」を参照してください。

asadminコマンドを使用してターゲット・アプリケーション・サーバーをデプロイするには:

1. GlassFish Serverのasadminシェルを起動します。

2. deployコマンドを起動します。

たとえば、次のコマンドによってapplication1.earがGlassFish Serverにデプロイされます。

deploy \--target=server \--force /path/application1.ear

H.4.7 スクリプトとAntを使用したアプリケーションのデプロイ方法

コマンドを使用してアプリケーションをデプロイし、そのコマンドをスクリプトに記述してプロセスを自動化することができます。ojdeployコマンドを使用すると、JDeveloperなしでアプリケーションをデプロイできます。Antスクリプトを使用してアプリケーションをデプロイすることもできます。JDeveloperには、Antスクリプトの作成に役立つ機能が用意されています。要件によっては、通常のスクリプトをAntスクリプトと組み合せることも可能です。

コマンド、スクリプト、Antの詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

H.5 アプリケーションのテストとデプロイの検証

アプリケーションは、デプロイが完了したら、アプリケーション・サーバーからテストできます。ADFアプリケーションをテストするには、ブラウザ・ウィンドウを開き、次のURLを入力します。

- Faces以外のページの場合: http://<host>:port/<context root>/<page>

- Facesページの場合: http://<host>:port/<context root>/faces/<view_id>
<view_id>は、ADFタスク・フローにおけるビュー・アクティビティのビューIDです。

ヒント:

アプリケーションのコンテキスト・ルートは、ユーザー・インタフェース・プロジェクト設定に、デフォルトでApplicationName/ProjectName/context-rootとして設定されています。この名前を短くするには、ターゲット・アプリケーション・サーバー全体で一意の名前を指定します。ユーザー・インタフェース・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。「プロジェクト・プロパティ」ダイアログで、「Java EEアプリケーション」を選択し、コンテキスト・ルートの一意の名前を入力します。

注意:

FacesページのURLには、/facesが含まれている必要があります。これは、JDeveloperがFacesサーブレットとの関連付けのために、/facesというURLパターンを使用するようweb.xmlファイルを構成するためです。Facesサーブレットは、リクエスト単位処理を実行し、URL内の/faces部を取り除いた後、そのURLをJSPに転送します。URLに/facesを指定しないと、Facesサーブレットは関与しません(URLパターンが一致しないためです)。JSPは必要なJSFリクエスト単位処理なしで実行されます。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。