| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.2.0) E82918-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.2.0) E82918-03 |
|
|
前 |
次 |
この章の内容は次のとおりです。
ADFビジネス・コンポーネントのビュー・オブジェクト・インスタンスは、RESTを使用してWebサービスとして機能できます。クライアント開発者は、ADF RESTランタイムで有効になっているREST APIを介してこれらのリソースとやり取りします。
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でセキュリティをテストするには、テスト・ユーザーを作成してこれらのユーザーにリソースへのアクセス権限を付与します。次に、これらのアクセス権を付与するセキュリティ・ポリシーをアプリケーション・レベルからドメイン・レベルのセキュリティ・ポリシー・ストアに移行します。セキュリティ・ポリシー・ストアで、エンタープライズ・ユーザーにアクセス権がプロビジョニングされます。
開発チームはADF RESTリソースを公開し、Fusion Webアプリケーションに提供できます。ADF RESTアプリケーション開発者は、次のようなバージョニング機能を使用してサービス・クライアントに公開する機能を管理できます。
RESTリソースのバージョニングをサポートするために、RESTリソースをアプリケーション固有のリソース・バージョン名(または番号)で登録します。
RESTリソースに対してデフォルトのADF RESTフレームワーク・バージョンを宣言すると、サービス・クライアントでは、ADF RESTランタイム・フレームワークのバージョン2で提供される拡張問合せ機能など、新機能および拡張機能を実行時に利用できます。リクエストを処理するデフォルトのフレームワーク・バージョンを宣言することで、RESTアプリケーション開発者は準備が整えば特定のADF RESTフレームワークで導入される機能を選択できます。JDeveloperリリース12.2.1.2.0では、フレームワーク・バージョン1、2および3が存在します。
クライアントとサーバーによるリソース情報の交換をサポートするADF RESTフレームワークの固有のランタイム機能には、次のものがあります。
RESTリソースとの対話は、リソース、アクション実行、およびアクション実行の結果に対して、個別のJSONベース・メディア・タイプ構造によってサポートされています。
カスタム・ヘッダーを渡して、リクエストの処理に使用するADF RESTランタイム・フレームワークのバージョンを指定します。バージョン・ヘッダーにより、サービス・クライアントではRESTアプリケーションによって定義されたデフォルトのバージョン宣言をオーバーライドできます。JDeveloperリリース12.2.1.2.0では、フレームワーク・バージョン1、2、3が存在します。
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セキュリティ権限の付与によって有効化されます。
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サービスの使用方法」を参照してください。
ADFビジネス・コンポーネントのアプリケーション・モジュールのデータ・モデルのビュー・オブジェクト・インスタンスを使用してADF RESTリソースを作成できます。
アプリケーション・モジュールは、ビュー・オブジェクト・インスタンスおよびカスタム・メソッドとして公開される、一連の関連するビジネス機能としてビジネス・ロジックをカプセル化する、ADFビジネス・コンポーネント・フレームワーク・コンポーネントです。アプリケーション・モジュールのデータ・モデルに出現する1つ以上のビュー・オブジェクト・インスタンスをADF RESTリソースにマップできます。アプリケーション・モジュールの概要エディタを使用して、ADF RESTリソースを作成します。ADFモデル・プロジェクトに追加するRESTリソースは、RESTアーキテクチャ・スタイルに従うWebサービスとして公開される場合があります。
注意:
ADF RESTリソースとして公開する目的でビュー・オブジェクトを作成する場合、ビュー・オブジェクトの作成・ウィザードで「問合せ」ページのDeclarativeオプションを使用して、宣言SQLモード・オプションが有効なビュー・オブジェクトを作成します。設計時に宣言SQLモードで作成されたビュー・オブジェクトは、ADF RESTフレームワーク実行時最適化をサポートし、リソース・コレクションは、URL問合せパラメータfieldsで作成されたクライアント・リクエストを使用して効果的にフィルタ処理されます。
ビュー・オブジェクト・インスタンスは、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リソースを作成する手順は次のとおりです。
「アプリケーション」ウィンドウで、ADF RESTリソースを作成するビュー・インスタンスを含むアプリケーション・モジュールをダブルクリックします。
概要エディタで、「Webサービス」ナビゲーション・タブをクリックして「REST」タブをクリックし、「RESTサービスのサポートの有効化」追加アイコンをクリックします。
最初のRESTリソースを作成するとき、JDeveloperによって、ADF RESTサーブレットを登録する個別のRESTful Webサービス・プロジェクトも生成されます。
「RESTリソースの作成」ダイアログで、RESTful Webサービスで公開するルート・ビュー・インスタンスを選択します。
ダイアログに、アプリケーション・モジュールのデータ・モデルで定義されたビュー・インスタンスが表示されます。マスター/ディテール階層のルート・ビュー・インスタンスのみ選択できます。
RESTリソース・コレクションの「リソース名」を入力し、ドロップダウン・リストからリリース・バージョンを選択して「OK」をクリックします。
リソース名は、サービス・クライアントがビュー・インスタンスとの対話に使用する識別子です。たとえば、次の図に示すように、DeptView1ビュー・インスタンスに基づくコレクションに名前を付ける場合、完全なコレクション名を示すために名前にDepartmentsを入力できます。ネーミングの詳細は、「ADF RESTリソースのネーミングに関する必知事項」を参照してください。
リリース・バージョンは、JDeveloperでリソースの作成を管理するためにadf-config.xmlファイル内に作成する必要がある識別子です。「ADF RESTリソースのバージョニング」で説明するように、バージョンは、サービス・クライアントが特定のRESTリソースの操作を起動するために使用するURLの一部となります。
図16-3 ADF RESTリソースのリリース・バージョンへの割当て
RESTリソースの概要エディタで、次のいずれかのタスクを実行することによって、リソースとその構造の編集に進むことができます。
ビュー・リンク・アクセッサで定義された子リソースを追加および削除します。詳細は、「ADF RESTリソース定義の編集方法」を参照してください。
同じ基礎となるビュー・インスタンスで定義されたリソースを追加および削除します。詳細は、「同じビュー・インスタンスに基づくリソースを追加および削除する方法」を参照してください。
属性を追加および削除します。詳細は、「ADF RESTリソースの属性を非表示にしたり公開したりする方法」を参照してください。
HTTPメソッド、正規のリンク、行検索フィルタ、サブタイプ・ビューの慣用名およびカスタム・メソッドで定義された標準操作へのアクセスを変更します。詳細は、「ADF RESTリソース表現およびメソッドのカスタマイズ」を参照してください。
「ファイル」、「すべて保存」の順にクリックして、このリソースの選択を保存します。
「ADFビジネス・コンポーネント・プロジェクトのRESTリソースを作成する場合の処理」で説明するように、JDeveloperでは、概要エディタで行われる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リソース
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リソースで子リソースを公開できます。データ・モデルの各マスター/ディテール関係に対して、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リソースを作成します。
ネストされたリソースを公開する手順は次のとおりです。
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リソースを作成します。
概要エディタでリソースを追加および削除する手順は次のとおりです。
「アプリケーション」ウィンドウで、リソースを追加または削除するADF RESTリソースが定義されているリソース定義ファイルをダブルクリックします。
RESTリソースの概要エディタで、「リソース」ドロップダウンからリソースを選択し、「リソースの削除」をクリックして、ビュー・オブジェクトに対してすでに定義されているリソースを削除します。
「リソースの削除」を使用してルート・リソース定義を削除するとリソースは削除されますが、空の定義ファイルが「アプリケーション」ウィンドウに表示されます。
RESTリソースの概要エディタで、ビュー・オブジェクトに対して作成するリソースを追加するには、「リソースの追加」をクリックします。
「ビュー・オブジェクト」ダイアログの「リソースの追加」で、選択したルート・ビュー・インスタンスに対して追加するRESTリソース・コレクションの「リソース名」を入力し、「OK」をクリックします。
RESTリソースの概要エディタで、「リソース」ドロップダウンから新規リソースを選択し、そのリソース定義を編集します。
ビュー・リンク・アクセッサで定義された子リソースを追加および削除します。詳細は、「ADF RESTリソース定義の編集方法」を参照してください。
属性を追加および削除します。詳細は、「ADF RESTリソースの属性を非表示にしたり公開したりする方法」を参照してください。
HTTPメソッド、正規のリンク、行検索フィルタ、サブタイプ・ビューの慣用名およびカスタム・メソッドで定義された標準操作へのアクセスを変更します。詳細は、「ADF RESTリソース表現およびメソッドのカスタマイズ」を参照してください。
次のコード例に示すように、リソース定義のServiceConfigurationタグ内のVisibility属性を設定することで、最上位レベルのリソースをADF RESTカタログ記述から非表示にできます。
<tree..> <ServiceConfiguration Visibility="unlisted"/> ... </tree>
Visibility属性をunlistedまたはpublicに設定できます。include問合せパラメータを使用して、特定の可視性のリソースの説明を含めることができます。詳細は、「使用可能なすべてのリソースの記述」を参照してください。
ADF RESTリソースの開発中、RESTリソースの概要エディタを使用して、リソース定義ファイルでリソースの名前を変更できます。サービス・クライアントでは、必要なRESTリソース・コレクションとの対話にリソース名を使用するため、サービスを本番環境にデプロイする前に、ADF RESTリソースの名前を確定することが重要です。
デプロイ後にADF RESTリソースの名前を変更する必要がある場合は、「ADF RESTリソースのバージョニング方法」で説明するように、リソースの完全な新規バージョンを作成することで、このことを最適に処理できます。
始める前に:
ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。詳細は、「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。
また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。詳細は、「RESTful Webサービスの追加機能」を参照してください。
次のタスクを完了する必要があります。
「アプリケーション・モジュールを使用したADF RESTリソースの作成」の説明に従い、RESTリソースを作成します。
本番デプロイメントの前にリソースの名前を変更する手順は次のとおりです。
RESTリソース名は、サービス・クライアントが、公開されているリソース・コレクションを識別して対話する手段です。通常、RESTリソース名で、利用するクライアントがアクセスするビュー・オブジェクトを識別します。そのため、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リソースに適用する手順は次のとおりです。
入力する接尾辞はサービス形状定義ファイルの名前を形成します。たとえば、接尾辞ForHRはビュー・オブジェクトEmployeesViewに追加され、図16-10に示すようにサービス形状定義名EmployeesView_ForHRを形成します。
図16-10 使用可能な属性を定義するビュー・オブジェクトのサービス形状定義
図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リソースのバージョニング」を参照してください。
BLOBまたはCLOBタイプ属性を公開するリソースには、実行時にストリーミング・メディアとしてアクセスできます。デフォルトでは、ビュー・オブジェクト属性は、一般的なコンテンツ・タイプapplication/octet-streamを使用してADF RESTランタイムによって処理されます。特定のコンテンツ・タイプをサポートする場合は、LOBタイプ属性のカスタム・プロパティとして特別なプロパティcontentTypeを構成できます。たとえば、PNGイメージ・ファイルを使用する場合は、設計時に次のコンテンツ・タイプを構成できます。
カスタム・プロパティ: contentType
値: image/png
図16-12に示すように、カスタム・プロパティcontentTypeは、ビュー・オブジェクトの概要エディタでPicture属性のビュー・オブジェクト定義に追加されています。
図16-12 LOB属性に対して構成されているカスタム・コンテンツ・タイプ
値リスト(LOV)属性は、そのデータソースを別のビュー・オブジェクトに依存するビュー・オブジェクトの属性です。通常、データソース・ビュー・オブジェクトでは、LOV有効属性に対して使用可能な値の固定リストを指定します。ビュー・オブジェクトでLOV有効属性を明示的に定義すると、ADF RESTランタイムがADF RESTリソースでLOV子リソースとして自動的に公開するLOVビュー・アクセッサが、ADFビジネス・コンポーネントによって定義されます。このため、実行時にリソースでLOV有効属性が検出されると、サービス・クライアントによってLOVビュー・アクセッサが起動され、LOV有効属性のデータソースが取得されて、エンド・ユーザーに選択項目が表示される場合があります。
注意:
デフォルトでは、LOVアクセッサ・リソースはリソースで公開され、リソース概要エディタの構造ツリーには表示されません。LOV有効属性の作成の詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
JDeveloperでは、ADF RESTリソース定義を編集できます。HTTPアクションの有効化、行検索の公開、ツリーの各ノードに対する正規のリソース・リンクの有効化などが可能です。
ADF RESTリソースの概要エディタを使用して、ADF RESTリソース定義を編集します。リソース構造ツリーで選択することによって、HTTPアクションを有効にし、行検索を公開し、ツリーの各ノードに対する正規のリソース・リンクを有効にできます。
ADFモデル・プロジェクトでRESTリソースに行うカスタマイズは、最終的に、実行時にこれらのリソースと対話するサービス・クライアントの機能に影響します。このため、この項では様々なデザインタイム・カスタマイズについて説明していますが、必要なADF RESTランタイム機能をサポートするサービス・クライアントのユースケースの要件を理解することが重要です。
ADF RESTランタイムの詳細は、「ADF RESTフレームワークを使用したRESTful Webサービスの使用方法」を参照してください。
注意:
リソース属性に対して定義されたカスタム・プロパティは、記述に含まれます。ただし、名前がINTERNAL、internalまたは__ (二重のアンダースコア)で開始するカスタム・プロパティは記述から非表示になります。
ADF RESTリソース表現では、実行時のレスポンスで返される属性が、リソースの基礎となるビュー・オブジェクトによって問い合わされた属性に制限されます。そのため、設計時にビュー・オブジェクト問合せを定義する場合は、サービス・クライアントの特定のユースケースをサポートするために必要な属性のみを公開することが重要になります。ただし、サービス・クライアントが部分的なRESTリソース表現から同じデータの完全表現に移動できるようにするために、正規リソースへのリンクを構成できます。
通常、正規リソースは真のソースとみなされるため、特定のデータソースの完全表現を指定します。正規リソースの例は、managerインスタンスを記述するリソースへのリンクを持つemployeesリソースによって示すことができます。このシナリオ(マネージャ名のみが必要な一般的なユースケース)では、非正規のmanagerリソースに名前属性のみが含まれています。さらに、名前がマネージャの識別には十分でない場合は、非正規リソースがmanagerインスタンスのすべての属性(名前、ID、部門、入社日など)を公開する正規リソースにリンクする場合があります。したがって、正規リソースと非正規リソースは次のような状態で存在します。
非正規リソースと正規リソースは、同じデータソースの異なる表現を公開します。
非正規リソースはサービス・クライアントのユースケースのサポートに必要なデータソースの表現のみを公開するため、部分表現となります。
非正規リソースを定義するときには、その正規の完全表現へのリンクが含められます。
リソースの概要エディタで、リソース構造ツリーの各リソース・ノードに対して、ADFモデル・プロジェクトによって定義されている既存のRESTリソースから正規リソースを選択するか、アプリケーションのconnections.xmlファイルの既存のURL接続によって定義されている外部リソースを選択できます。
RESTリソースの概要エディタで選択できる内部正規リソースは、次の基準を満たす必要があります。
ADFモデル・プロジェクトでは、既存の部分的な表現リソースの基礎となる、同じデータソースにアクセスするビュー・オブジェクトを定義する必要があります。ビュー・オブジェクトはエンティティ・ベースまたは非エンティティ・ベースとなります。
ビュー・オブジェクトでは、非正規リソースによって問い合わされた使用可能な属性のスーパーセットを問い合わせる必要があります。
スーパーセットの表現ビュー・オブジェクトは、アプリケーション・モジュールのデータ・モデルでビュー・インスタンスとして指定する必要があります。
図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リソースで名前が付けられているビュー・オブジェクトで明示的に定義されている場合は、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リソースで公開するビュー・インスタンスで行検索を作成します。
行検索フィルタを公開する手順は次のとおりです。
実行時、行検索キーが有効化されている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リソースでの正規リソースの公開方法」を参照してください。
サブタイプ・ビュー・オブジェクトは、継承階層のベース・ビュー・オブジェクトを拡張するビュー・オブジェクトです。サブタイプ・ビュー・オブジェクトは、ベース・ビュー・オブジェクトから属性のそのリストを継承し、サブタイプに固有の独自の属性を提供します。このようなサブタイプ・ビュー・オブジェクトは多相ビュー・オブジェクトと呼ばれます。実行時、多相ビュー・オブジェクトによって、ベース・ビュー・オブジェクトの属性および定義サブタイプ・ビュー・オブジェクトの属性で構成されるサブタイプ・ビュー行が定義されます。
サブタイプ・ビュー行を問い合わせるには、サブタイプ・ビュー・オブジェクトで特定のタイプを判別する識別子属性を指定する必要があります。たとえば、識別子属性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リソースを作成します。
リソース定義でサブタイプ・ビュー行を公開する手順は次のとおりです。
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アクションを公開する手順は次のとおりです。
値リスト(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リソースを定義する手順:
「リソース名」リストのデータはモデル・プロジェクト内のADF RESTリソース定義によって移入されます。選択したRESTリソースのビュー・オブジェクト定義は、LOV属性データ・ソースを定義しているビュー・オブジェクトと同じである必要があります。たとえばEmployeesリソースを作成していて、EmployeesViewビュー・オブジェクトがLOV属性JobsIdを定義しているとします。LOVリソースの作成エディタで、図16-17のとおり、ADF RESTリソースJobsを選択し、Jobsリソースのリソース構造ツリーからルート・リソースJobsView1を選択します。
図16-17 REST作成操作のための静的LOVリソースの作成
すべてのADF RESTリソースでは、サービス・クライアントによる読取り操作がサポートされます。効率的な読取り操作(HTTP GETリクエスト)をサポートするには、ADF RESTリソースの基礎となるビュー・オブジェクト定義で、HTTPリクエスト・ペイロードでのコレクションのページングをサポートするように設定されたアクセス・モードを定義する必要があります。範囲ページングの詳細は、「ビュー・オブジェクトの範囲ページ移動を有効にする方法」を参照してください。
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リソースで公開するビュー・オブジェクトのクライアント・インタフェースまたはクライアント行インタフェースでカスタム・メソッドを作成します。
カスタム・メソッドを公開する手順は次のとおりです。
JDeveloperでは、ADF RESTリソースをバージョニングできます。これにより、ADF RESTリソースのユース・ケースまたはバッキング・ビュー・オブジェクトが変更された場合に、ADF RESTリソースの新しいバージョンを簡単に作成できます。
開発サイクル中は、リソースをバージョニングする必要なく、ADF RESTリソースに変更を加えることができます。ただし、RESTful Webサービスをデプロイした後、ADF RESTリソースにアクセスするサービス・クライアントでそれらのユースケースが満たされることは、リソース・コレクションの安定性に依存します。
時間の経過に伴い、ユースケースが変化したり、RESTリソースの基礎となるビュー・オブジェクトが変化したりすることによって、すでにデプロイされているリソースのリソース構造を変更することが必要になる場合があります。このとき、既存のADF RESTリソースに対する変更に、デプロイされているRESTサービスとの後方互換性がない場合があり、新しいバージョン識別子およびそのバージョンの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のバージョンを管理する手順は次のとおりです。
次に、すでにデプロイされているRESTful Webサービスと後方互換性がないとみなす必要があるADF RESTリソース構造への変更の例を示します。
公開されている属性の名前変更
すでに公開されている属性の削除または非表示
すでに公開されている子リソースの削除
標準操作の無効化またはカスタム・メソッドの削除
LOVビュー・アクセッサの無効化または別のビュー・オブジェクトに対するLOVの変更
特定の状況では、リソースをバージョニングしないで、ADF REST構造を変更できます。次の変更は後方互換性があるとみなされるため、すでにデプロイされているADF RESTリソースの新規バージョンを作成する必要はありません。
属性を必須として定義しない新規属性および基礎となるビュー・オブジェクトの公開
必須として定義された属性を公開する場合は、リソースをバージョニングする必要があることに注意してください。
標準操作の公開または新しいカスタム・メソッドの公開
新しい子リソースの公開
すでに公開されている属性に対するLOVビュー・アクセッサの定義
指定するバージョン識別子は、サービス・クライアントが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が返されます。
JDeveloperでは、ADF RESTリソースに対するリクエストの処理時に、サービス・クライアントで使用するデフォルトのADF RESTランタイム・フレームワークを指定できます。デフォルトのフレームワーク・バージョンを宣言すると、クライアントは適切なレベルの機能とやり取りするようになります。
Oracle JDeveloper 12cでは、リリース12.2.1.2.0から、サービス・クライアントで新しいラインタイム機能をサポートするためにADF RESTフレームワーク拡張機能が導入されます。アプリケーションでこのような拡張機能が役立つかどうかは、アプリケーションのユース・ケースによって決まります。サービス・クライアントに公開する前にフレームワーク拡張機能を評価できるように、ADF RESTフレームワークの各版はバージョン1、2、3といったバージョン番号で識別されます(バージョン1はデフォルトでアプリケーションに関連付けられます)。アプリケーションは、現在のフレームワーク・バージョン(ベース・フレームワーク・バージョン1など)のままにしておくことも、新しいバージョン(フレームワーク・バージョン2など)を選択してアプリケーションのユース・ケースを拡張することもできます。これにより、ADF RESTランタイムでは、サービス・クライアントに対して必要なレベルの機能を提供するフレームワーク・バージョンを使用してリクエストを処理するようになります。アプリケーションでリクエストを処理するフレームワーク・バージョンを指定できると、準備が整えばそれらの機能を選択できます。
新しいADF RESTランタイム・フレームワーク・バージョンが導入されると、後続フレームワークで提供されるランタイム機能を使用するようにアプリケーションの更新が必要になることがあります。これを実行するために、ADF RESTデザインタイムでは、adf-config.xmlファイルでrestFrameworkVersionプロパティを関連付けてアプリケーションのADF RESTリソースの各バージョンにデフォルトのフレームワーク・バージョンを定義できます。たとえば、リソース・バージョン11.0があり、フレームワーク・バージョン1の基本機能にデフォルトで関連付けられています。その場合、Oracle JDeveloper 12.2.1.2.0およびADF RESTフレームワーク・バージョン2以降、新しいリソース・バージョン11.1を作成してフレームワーク・バージョン2に関連付けることを選択できます。あるいは、新しいリソース・バージョンを作成するかわりに、既存のリソース・バージョンでフレームワーク・バージョン2を選択できます。個々のリソース・バージョンに関連付けるデフォルトのフレームワーク・バージョンを指定することで、アプリケーションによって適切なレベルの機能がサービス・クライアントに公開されるようになります。
注意:
JDeveloperリリース12.2.1.2.0では、ADF RESTランタイム・フレームワークのバージョン1、2および3が存在します(バージョン1はベース・バージョンであり、ADF RESTサービス・クライアントに対して複数のフレームワーク・バージョンをサポートする機能が含まれています)。フレームワークの後続バージョン(バージョン2、バージョン3など)の詳細は、「ADF RESTフレームワークのバージョニングに関する必知事項」を参照してください。
「ソース」ビューでadf-config.xmlファイルの概要エディタを使用し、ADF RESTアプリケーションのリソース・バージョンに対してデフォルトのADF RESTフレームワーク・バージョンを宣言します。サービス・クライアントがリソースをリクエストすると、ADF RESTランタイムでは、リクエストURLに指定されたリソース・バージョンに関連付けられている宣言されたフレームワーク・バージョンを使用してリクエストを処理します。
始める前に:
ADF RESTフレームワークによって、アプリケーション・モジュールがどのようにサポートされ、サービス・クライアントのデータ行アクセスやサービス操作の実行がどのように有効化されるかについて理解しておくと役立ちます。「RESTful WebサービスおよびADFビジネス・コンポーネントについて」を参照してください。
アプリケーションのADF RESTリソースについてリソースの版を管理するために作成したリリース・バージョンの役割を理解しておくと役立つ場合があります。詳細は、「ADF RESTリソースのバージョニング」を参照してください。
また、新しいリソース・バージョンを作成し、それに対してデフォルトのフレームワーク・バージョンを宣言する必要がある後方互換性のない変更がADF RESTフレームワーク・バージョンによってどのように導入されるかを理解しておくと役立つ場合があります。「ADF RESTフレームワークのバージョニングに関する必知事項」を参照してください。
さらに、サービス・クライアントによるリクエスト処理がリソース・バージョンに対して宣言されたADF RESTフレームワークによってどのように影響を受けるかを理解しておくと役立つ場合があります。「実行時に行われる処理: ADF RESTフレームワーク・バージョンの起動」を参照してください。
また、ADF RESTリソースに依存する他のOracle ADF機能を理解しておくと役立つ場合があります。「RESTful Webサービスの追加機能」を参照してください。
デフォルトのADF RESTフレームワーク・バージョンを宣言する手順は次のとおりです。
ADF RESTアプリケーションのADF RESTフレームワークのバージョニングが必要となる理由の1つは、ADF RESTランタイム・フレームワークの後続バージョンで提供される新機能を選択することです。現在、3つのフレームワーク・バージョンが提供されています。
フレームワーク・バージョン1
バージョン1と識別されるADF RESTランタイム・フレームワークは、ADF RESTの初期導入時にJDeveloperリリース12.2.1.0.0から提供されました。これは、特定のJSONペイロード形式を指定したベース・バージョンです。このリリースおよびすべての後続リリースでは、adf-config.xmlファイルでrestFrameworkVersionプロパティを使用できることで、複数のフレームワーク・バージョンをサポートする機能が組み込まれました。
バージョン1は、他のバージョンが指定されていない場合にサービス・クライアントのリクエストを処理するためにADF RESTランタイムで使用されるデフォルトのバージョンです。したがって、基本レベルの機能でサービス・クライアントをサポートする場合、アプリケーションでは、adf-config.xmlファイルでrestFrameworkVersionプロパティを使用してバージョンを宣言する必要がありません。
ベース・フレームワーク・バージョン(バージョン1)でサポートされるQuery-By-Exampleリソース問合せ構文は、ADF RESTフレームワークの後続バージョンと互換性がないことに注意してください。ADF RESTフレームワークのバージョン2から、より高度な問合せ構文がかわりに提供されます。
フレームワーク・バージョン2
バージョン2と識別されるADF RESTランタイム・フレームワークは、JDeveloperリリース12.2.1.2.0から提供されました。この新しいバージョンの目的は、ADF RESTリクエスト用の拡張問合せ式構文を導入することです。ADF RESTフレームワークのバージョン2では、q問合せパラメータ値をフレームワーク・バージョン1とは異なって解析するため、フレームワーク・バージョン1に依存するサービス・クライアントに後方互換性のない変更が導入されます。フレームワーク・バージョン2 (以降)がリソース・リクエストに指定されている場合のみ、ADF RESTランタイムではリクエストを処理するために拡張式構文の使用がサポートされます。
バージョン1では、次のように、q問合せパラメータを使用したリソース・コレクションのフィルタ処理がQuery-by-Example構文に制限されます。
GET /rest/11.0/Departments?q=Dname SA*;Loc BOSTON
これに対してバージョン2から、次のように、新しい拡張問合せ構文ではRowMatch問合せ式を使用したリソース・コレクションのフィルタ処理がサポートされます。
GET /rest/11.1/Departments?q=Dname like 'SA*' or Loc = 'BOSTON'
注意:
RowMatch式(フレームワーク・バージョン2以降で提供)とQuery-by-Example構文(バージョン1のみ)の両方をサポートするには、フレームワーク・バージョン2 (以降)をadf-config.xmlファイルでRESTリソースに定義する新しいリリース・バージョン識別子に関連付ける必要があります。たとえば、前述のURLサンプルでは、リリース・バージョン11.0の元の機能を保持しながら、バージョン11.1の新機能を公開できます。これは、アプリケーションのadf-config.xmlファイルで、リリース・バージョン11.1でrestFrameworkVersion="2"プロパティを使用して、フレームワーク・バージョン2がデフォルトとして宣言されていることを前提としています。あるいは、サービス・クライアントで現在のフレームワーク・バージョンの機能が不要になった場合に、新しいフレームワーク・バージョンを既存のリリース・バージョン識別子に関連付けることができます。したがって、新しいフレームワーク・バージョンを使用するために、リリース・バージョンを増す必要がありません。
RowMatch式で提供される拡張問合せ構文の説明は、「ADF RESTフレームワーク・バージョン2の拡張問合せ構文に関する必知事項」を参照してください。
フレームワーク・バージョン3
バージョン3と識別されるADF RESTランタイム・フレームワークは、JDeveloperリリース12.2.1.2.0から提供されました。このバージョンの目的は、後続のADF RESTリクエストでリソース・アイテムがさらに返されるかどうかを判別するためにサービス・クライアントで使用できるペイロード属性によってネストされた子リソースを取得するためのサポートを追加することです。この機能をサポートするために、フレームワーク・バージョン3でのペイロード構造では、ネストされた子リソースをアイテムの配列(バージョン1および2)でなく、リソース・コレクションとして表すようになっています。したがって、バージョン3では、フレームワーク・バージョン1またはバージョン2に依存するサービス・クライアントに後方互換性のない変更が導入されます。バージョン3を選択することにした場合、GET操作で?expandおよび?fields問合せパラメータを使用してネストされた子リソースをhasMore属性とともにリソース・コレクションとして返すことができる機能が公開されます。要するに、この変更により、フェッチするために1つ以上のリクエストを必要とするネストされた子リソースのページ区切りがサポートされます。
フレームワーク・バージョン3のサポートをアプリケーションに追加する場合は、adf-config.xmlファイルでrestFrameworkVersionプロパティを使用した既存レベルの機能の保持に、フレームワーク・バージョン2 (前述の項を参照)について説明している同じガイドラインが適用されます。
バージョン3で導入されるネストされた子リソースの新しいペイロード構造の例については、「ネストされた子リソースのフェッチ」 および「属性のフィルタ処理による問合せ(部分取得)」を参照してください。hasMore属性を使用したリソース・コレクションのページ区切りの詳細は、「リソース・コレクションのページング」を参照してください。
バージョン2と識別されるADF RESTランタイム・フレームワークは、JDeveloperリリース12.2.1.2.0から提供されました。このフレームワーク・バージョンの目的は、ADF RESTリクエスト用の拡張問合せ式構文を導入することです。このバージョンでは、q問合せパラメータ値をフレームワーク・バージョン1とは異なって解析するため、フレームワーク・バージョン1に依存するサービス・クライアントに後方互換性のない変更が導入されます。
フレームワーク・バージョン2 (以降)を選択することにした場合、ADF RESTランタイムでは拡張式構文を使用してq問合せパラメータに関するフェッチ・リクエストを処理する一方、Query-by-Example構文を使用しているリクエストは無効になり、エラーを返します。しかし、リリース・バージョンのデフォルトをフレームワーク・バージョン1に設定されたままにすることで、フレームワーク・バージョン2で提供される機能を選択しないこともできます。あるいは、adf-config.xmlファイルで既存のリリース識別子をフレームワーク・バージョン1のままにすると同時に、フレームワーク・バージョン2に関連付ける新しいリリース・バージョン識別子を作成することで、基本機能を保持することもできます。
バージョン1では、次のように、問合せパラメータを使用したリソース・コレクションのフィルタ処理が、セミコロンを使用して式を区切るQuery-by-Example構文に制限されます。
GET /rest/11.0/Departments?q=Dname SA*;Loc BOSTON
これに対してバージョン2から、次のように、新しい拡張問合せ構文ではRowMatch式を使用したリソース・コレクションのフィルタ処理がサポートされます。
GET /rest/11.1/Departments?q=Dname like 'SA*' or Loc = 'BOSTON'
このようなRowMatch式には、大/小文字を区別するリソース・アイテムの名前と、その後に演算子と(使用する演算子によって決まる)1つ以上のオペランド値が含まれます。フィルタは単一式のような簡素なものでも、andおよびor結合をグループ分けのための対となったカッコとともに使用して式を組み合せてもかまいません。
フレームワーク・バージョン2以降で提供される拡張問合せ構文の利点
RowMatch式の利点は次のとおりです。
サポートされている演算子を使用できます。
DepartmentNumber = 20
DepartmentNumber <> 20
DepartmentNumber <= 20
DepartmentNumber < 20
DepartmentNumber >= 20
DepartmentNumber >20
DepartmentNumber between 20 and 40
DepartmentNumber not between 20 and 40
DepartmentNumber in (20, 30, 40)
DepartmentName like '%S%'
DepartmentName like 'RE%'
DepartmentName not like 'RE%'
Location is null
Location is not null
複数の属性を挿入できます。
DepartmentNumber = 10 or DepartmentName like 'RESEARCH'
DepartmentNumber > 10 and DepartmentNumber < 40
DepartmentNumber < 20 or DepartmentNumber > 30
(DepartmentNumber = 10 or DepartmentNumber = 30) and (DepartmentName like 'SALES')
DepartmentNumber BETWEEN 20 and 40) and (Location like 'DAL%')
(DepartmentNumber > 0 and DepartmentNumber < 100) and (DepartmentName <> 'SALES') and (Location not like 'NEW%')
(DepartmentNumber = 10 or DepartmentNumber = 30) and (DepartmentName = 'ACCOUNTING' or DepartmentName = 'SALES')
(DepartmentNumber = 10 and DepartmentName like 'ACC%') or (DepartmentNumber = 20 and DepartmentName like 'RES%')
DepartmentName='ACCOUNTING' or (DepartmentName like 'R%' and Location like '%ALLA%')
(DepartmentName like 'R%' and Loc like '%ALLA%') or DepartmentName='ACCOUNTING'
(DepartmentName like 'R%' or Loc like '%ALLA%') or DepartmentName='ACCOUNTING'
(DepartmentNumber between 20 and 40) and DepartmentNumber is not null
ネストした子リソースの属性を挿入できます。
Deptno > 5 and Emps.Job = 'MANAGER'
Emps.Job = 'MANAGER' and Deptno > 5
Deptno > 5 and (Emps.Job = 'MANAGER')
(Emps.Job = 'MANAGER') and Deptno > 5
(Deptno > 5) and (Emps.Job = 'MANAGER')
(Deptno = 10 and Emps.Job = 'PRESIDENT') or (Deptno = 20 and Emps.Job = 'MANAGER')
Deptno > 5 and Emps.Job = 'MANAGER' and Emps.Sal >= 2500
Deptno > 5 and (Emps.Job = 'ANALYST' or Emps.Sal >= 4000)
(Deptno > 5 and Emps.Job = 'ANALYST') or Emps.Sal >= 4000
Emps.Job = 'ANALYST' or Emps.Job = 'SALESMAN'
Deptno > 5 and (Emps.Job = 'ANALYST' or Emps.Job = 'SALESMAN')
Deptno > 5 and Emps.Job = 'MANAGER' and Emps.DirectReports.Sal >= 2000
Deptno > 5 and (Emps.Job = 'MANAGER' or Emps.DirectReports.Sal >= 2000)
Deptno > 10 and (Emps.Job = 'MANAGER' and (Loc = 'NEW YORK' or Emps.Mgr=7698))
Deptno > 10 and (Emps.Job = 'MANAGER' or (Loc = 'NEW YORK' or Emps.Mgr=7698))
Deptno > 10 and (Emps.Job = 'MANAGER' or (Loc = 'NEW YORK' or Emps.Mgr=7698)) or Deptno = 40
Deptno > 10 and (Emps.Job = 'MANAGER' or (Loc = 'NEW YORK' or Emps.Mgr=7698)) or (Deptno = 40)
Deptno > 10 and (Emps.Job = 'MANAGER' or (Emps.DirectReports.Sal > 2000 and (Emps.DirectReports.Comm = 500 or Emps.DirectReports.Deptno > 10)))
Deptno > 10 and (Emps.Job = 'MANAGER' and (Emps.DirectReports.Sal >= 2000 and (Emps.DirectReports.Comm = 500 or Emps.DirectReports.Deptno > 10)))
UPPER関数を挿入できます。
UPPER(DepartmentName) = 'RESEARCH'
UPPER(DepartmentName) = UPPER('research')
UPPER(DepartmentName) like 'RES%' and UPPER(Location) like 'DAL%'
UPPER(DepartmentName) like UPPER('research')
フレームワーク・バージョン2以降で提供される拡張問合せ構文の概要
次に、RowMatch式の例をいくつか示します。
値がnullかどうかテストするには、is nullまたはis not nullキーワードを使用する必要があります。
AssignedToId is null
AssignedToId is not null
等しいことには=記号を使用し、等しくないことには!=または<>演算子を使用します。
AssignedToId = 100000000089003
Priority != 1
Priority <> 1
ActivityType != 'RS'
ActivityType <> 'RS'
関係比較には、よく使用される<、<=、>または<>の各演算子の他、betweenまたはnot betweenを使用します。
Priority <= 2
Priority < 3
Priority <> 1
Priority > 1
Priority >= 1
TotalLoggedHours >= 12.75
Priority between 2 and 4
Priority not between 2 and 4
文字列照合には、like演算子を使用でき、パーセント記号%をワイルドカードとして採用し、ワイルドカードの挿入位置に応じて"starts with"、"contains"または"ends with"形式のフィルタ処理を実現します。
RecordName like 'TT-%'
RecordName like '%-TT'
RecordName like '%-TT-%'
フィールドの値が可能値のリストに含まれているかどうかをテストするには、in演算子を使用できます。
ActivityType in ('OC','IC','RS')
andおよびor結合をグループ分けのための対となったカッコとともに使用して式を組み合せて、次のようなさらに複雑なフィルタを作成できます。
(AssignedToId is null) or ( (Priority <= 2) and (RecordName like 'TT-99%'))
(AssignedToId is not null) and ( (Priority <= 2) or (RecordName like 'TT-99%'))
between句またはin句を使用する際、andまたはor結合を使用して他の句と連結する場合は、カッコで囲む必要があります。
Oracle JDeveloperによって新しいADF RESTフレームワーク・バージョン(JDeveloperリリース12.2.1.2.0以降で提供されるフレームワーク・バージョン2など)が導入された後、サービス・クライアントで適切なレベルの機能が使用されるようにするために、新しいリソース・バージョンを作成して新しいフレームワーク・バージョンに関連付けることが必要になる場合もあります。
たとえば、次のURLではリソース・バージョン11.2を指定しています(アプリケーションのadf-config.xmlファイルにより、このリソース・バージョンはADF RESTフレームワークのバージョン2と関連付けられています)。ADF RESTフレームワーク・バージョン2ではRowMatchフィルタ式がサポートされるため、結果として、ADF RESTランタイムでは適切な機能でリクエストを処理し、SAで始まる名前(SALESなど)の部門またはLocationがBOSTONの部門をフェッチします。
http://server/demo/rest/11.2/Departments?q=DepartmentName like 'SA*' or Location = 'BOSTON'
サービス・クライアントでは、デフォルトのフレームワーク・バージョンをオーバーライドし、カスタム・ヘッダーREST-Framework-Versionに渡された指定のフレームワーク・バージョンを使用して個々のリクエストを処理することもあります。その場合、ADF RESTランタイムでは、アプリケーションのデフォルトのフレームワーク・バージョン宣言を無視します。カスタム・ヘッダーがリクエストで省略されている場合、ADF RESTランタイムでは常に、adf-config.xmlファイルで定義されているアプリケーションのデフォルトのフレームワーク・バージョンを使用します。アプリケーションでデフォルトのフレームワーク・バージョンが定義されておらず、サービス・クライアントに対するリクエストでバージョン・ヘッダーが省略されている場合、ADF RESTフレームワークのバージョン1と想定されます。フレームワーク・バージョンを使用したリクエストの処理の詳細は、「ADF RESTフレームワーク・バージョンの使用」を参照してください。
次の表では、リクエストで特定のADF RESTフレームワーク・バージョンでサポートされている(またはサポートされていない)機能を使用する際の実行時に行われる処理を対比します。特に、バージョン1でのみサポートされるQuery-by-Example構文をバージョン2 (以降)でサポートされるRowMatch式と対比したURLに注目してください。REST-Framework-Versionヘッダーの列は、リクエストのバージョン・ヘッダーが渡されるかどうかを示します。リクエストにバージョン・ヘッダーが含まれる場合、ADF RESTランタイムでは渡されたフレームワーク値でリクエストを処理し、adf-config.xmlファイルのデフォルトの宣言をオーバーライドします。
表16-3 ADF RESTフレームワーク・バージョンによって処理されたリクエストの例
| URI | REST-Framework-Versionヘッダー | 解決されたバージョン | 成功/エラーの説明 |
|---|---|---|---|
GET /rest/11.0/Departments |
1 |
成功。リソース・バージョン11.0のデフォルトのフレームワーク・バージョンを使用します。 |
|
GET /rest/11.1/Departments |
1 |
1 |
成功。リクエストされたフレームワーク・バージョンを使用します( |
GET /rest/11.0/Departments |
2 |
2 |
成功。リクエストされたフレームワーク・バージョンを使用します( |
GET /rest/11.1/Departments |
2 |
成功。リソース・バージョン11.1のデフォルトのフレームワーク・バージョンを使用します。 |
|
GET /rest/11.0/Departments?q=Dname SA*;Loc BOSTON |
1 |
成功。リソース・バージョン11.0のデフォルトのフレームワーク・バージョン(バージョン1として定義)を使用します。 フレームワーク・バージョン1ではQuery by Example構文がサポートされています。 |
|
GET /rest/11.1/Departments?q=Dname SA*;Loc BOSTON |
2 |
エラーが戻されます。リソース・バージョン11.1のデフォルトのフレームワーク・バージョン(バージョン2として定義)を使用します。 フレームワーク・バージョン2ではQuery by Example構文がサポートされていません。 |
|
GET /rest/11.0/Departments?q=Dname LIKE 'SA*' OR Loc = 'BOSTON' |
2 |
2 |
成功。リクエストされたフレームワーク・バージョンを使用します( フレームワーク・バージョン2ではRowMatch式がサポートされています。 |
GET /rest/11.0/Departments?q=Dname LIKE 'SA*' OR Loc = 'BOSTON' |
1 |
エラーが戻されます。リソース・バージョン11.1のデフォルトのフレームワーク・バージョン(バージョン1として定義)を使用します。 フレームワーク・バージョン1ではRowMatch式がサポートされていません。 |
|
GET /rest/11.1/Departments?q=Dname LIKE 'SA*' OR Loc = 'BOSTON' |
1 |
1 |
エラーが戻されます。リクエストされたフレームワーク・バージョンを使用します( フレームワーク・バージョン1ではRowMatch式がサポートされていません。 |
ADFセキュリティの構成ウィザードを使用し、ウィザードでRESTWebService.jprをWebプロジェクトとして選択してADF RESTリソース・セキュリティを管理します。
RESTリクエストでのアクションの起動に対してユーザー認証が要求されるようにする場合は、ADF RESTリソースに対してセキュリティを有効にできます。ADFセキュリティの構成ウィザードを実行し、ウィザードでWebプロジェクトとしてRESTWebService.jprを選択すると、セキュリティはすべてのFusion Webアプリケーションのように処理され、有効化されます。Webサービス・プロジェクトでADFセキュリティを有効にすることは、デプロイされているサービスにデフォルトではアクセスできず、ユーザーには特定のアクセス権限を付与するアプリケーション・ロールに対するセキュリティ権限が必要となることを意味します。
RESTful Webサービスのユーザーに付与できる権限は、次のクラスによって定義されます。
RESTリソースで定義されている標準のアクションに対する認可付与を定義するoracle.adf.share.security.authorization.RestServicePermission。
表16-4に、定義されたアプリケーション・ロールに付与できるADF REST権限クラスによって定義されているアクションをリストします。
表16-4 ADF RESTリソースのセキュリティ保護されたアクション
| 許可できるアクション | RESTリソースへの影響 |
|---|---|
|
RESTリソースのコレクションおよびインスタンスを記述できるようにします。 |
|
RESTリソースのコレクションまたはインスタンスを返すことができるようにします。 |
|
RESTリソースのコレクションまたはインスタンスを更新できるようにします。 |
|
RESTリソースのコレクションまたはインスタンスを削除する権限。 |
|
RESTリソースのコレクションまたはインスタンスを作成できるようにします。 |
|
この権限で、RESTリソースのカスタム・メソッドを起動できるようにします。このアクションは、個々のメソッドではなく、すべてのカスタム・メソッドへのアクセス権を付与することに注意してください。 |
ADF RESTリソースのアクションを起動するユーザーを認証する一般的なプロセスは、次のとおりです。
RESTリソースに対する必要な標準のアクションを有効にします。
RESTリソースに対する必要なカスタム・メソッドを有効にします。
RESTWebServiceプロジェクトで、ADFセキュリティ・ウィザードを実行します。
1つ以上のアプリケーション・ロールとテスト・ユーザーを作成してJDeveloperでセキュリティをテストします。
必要なアプリケーション・ロールに関連付けるRESTリソースに対するリソース権限を作成します。
アプリケーション・ロールとそれらのリソース権限をテスト・ユーザーにマップします。
セキュリティ・ポリシーの概要エディタを使用して、リソースで公開した操作をセキュリティ保護する権限を作成します。JDeveloperによって、リソース・タイプの定義とOPSS権限クラスoracle.adf.share.security.authorization.RestServicePermissionが照合されます(表16-4を参照)。
始める前に:
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セキュリティの有効化」で説明するように、「Webプロジェクト」ドロップダウンからデフォルトで生成されるRESTWebServiceを選択し、ADF RESTリソースを定義するADFビジネス・コンポーネント・モデル・プロジェクトのADFセキュリティを構成します。
「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」で説明するように、1つ以上のテスト・ユーザーを作成し、リソース権限を付与する目的で作成したアプリケーション・ロールにそれらをマップします。
ADF RESTリソース権限を作成する手順は次のとおりです。
図16-20のように、概要エディタにアプリケーション・ロールに対するリソース権限が表示されます。
図16-20 ADF RESTリソースに対する権限の作成
JDeveloperの統合Oracle WebLogic ServerまたはスタンドアロンOracle WebLogic Serverに、RESTful Webサービスをデプロイできます。
JDeveloperの統合WebLogic ServerまたはスタンドアロンOracle WebLogic Serverに、RESTful Webサービスをデプロイできます。
図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にデプロイする手順は次のとおりです。
統合WebLogic Serverが構成されていない場合は、JDeveloperによりデフォルト・ドメインを構成するように要求されます。
JDeveloperによってアプリケーションがデプロイされ、Webサービスが開始されます。この間、これらのプロセスからの出力が「ログ」ウィンドウの実行中: IntegratedWebLogicServerタブに表示されます。図16-22に示すように、Webサービスが開始された後、ターゲットURLがログの下部に表示されます。
図16-22 ターゲットURLが表示された「ログ」ウィンドウ
たとえば、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リクエストの実行
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リソースを作成します。
デプロイメント・プロファイルを構成する手順は次のとおりです。
RESTWebServiceプロジェクトをアプリケーションのEARデプロイメント・プロファイルの依存性として追加します。
「アプリケーション」ウィンドウで、アプリケーションを選択し、メイン・メニューから「アプリケーション」→「アプリケーション・プロパティ」を選択します。
「アプリケーション・プロパティ」ダイアログで、「デプロイメント」を選択してからアプリケーション・モジュール・デプロイメント・プロファイルを選択し、「プロファイルの編集」をクリックします。
「EARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「アプリケーション・アセンブリ」を選択してRESTWebService.jprモジュールを開き、図16-24に示すようにプロジェクトを選択して「OK」をクリックします。
図16-24 RESTWebServiceプロジェクトへのデプロイメントの依存性の追加
スタンドアロン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サービスをデプロイする手順は次のとおりです。
サービス・クライアントがサービスへのアクセスに使用する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プロジェクトでのデフォルトのコンテキスト・ルートの編集
モデル・プロジェクトでビュー・オブジェクト形成定義を定義し、アプリケーションで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"を定義する必要があります。
カスタマイズしたメタデータをパッケージ化する方法の詳細は、「カスタマイズしたアプリケーションをパッケージ化してデプロイする方法」を参照してください。
JDeveloperでは、統合WebLogic ServerにデプロイされたADF RESTリソースをテストできます。HTTPアナライザ(HTTPリクエストを作成する場合)、Webブラウザ(GETリクエスト用)またはcURLコマンドライン・ツールを使用します。
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サービスをテストする手順は次のとおりです。
構成したリソースのバージョン番号を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タイプのリクエストを作成する必要があります。
-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リクエストの実行
