BOSS RESTデータ・ソース定義について

RESTデータ・ソースは、「RESTデータ・ソースの編集」で説明するように、「RESTデータ・ソース」ページで表示できます。新しく作成されたBOSS RESTデータ・ソースには、次のものがあります:

エンドポイントでサポートされているすべての操作に対して定義されている操作。
そのすべての属性を反映しているデータ・プロファイル。
RESTデータ・ソースの作成中に「参照の検出」設定で「はい」を選択した場合、新しいRESTデータ・ソースのデータ・プロファイルには次のものが含まれます:
- 第1レベル(1/多)対1の参照オブジェクトの、読取り専用属性。
- 該当する場合は、ページで参照オブジェクトをキー別に割り当てるか更新するために使用できる更新可能なアクセッサ外部キー属性。
割り当てられているルート・リソース名。
適切に構成されたリソース・タイプ。

定義してあれば、RESTデータ・ソースを、ページの作成中にどのAPEXリージョンででも使用できます。また、APEX_EXECパッケージで使用可能な適切なプロシージャおよびファンクションを使用することで、それをプログラム的に使用することもできます。

ヒント:

詳細は、PL/SQLでのBOSS RESTデータ・ソースを参照してください。

操作

エンドポイントがすべての操作をサポートする場合、ウィザードで作成される操作の最大セットには次のものが含まれます。

フィルタリング、順序付けおよびページ区切りをサポートする行のGET
リソース・キーによる行のGET
POST (挿入)
PATCH (更新)
DELETE

データ・プロファイル

リソース・タイプが「ビジネス・オブジェクト/ビュー」または「検索ビュー」であるRESTデータ・ソースの場合、データ・プロファイルには、BOSS RESTサービスのリソース・キーにマップされているAPEX$RESOURCEKEYという主キー列(各行を一意に識別する)が含まれています。これにより、すべてのBOSS RESTサービスがどのエンドポイントに対しても必ず一貫した方法で動作するようになります(エンドポイントの基にあるビジネス・オブジェクトに単一属性主キーがある場合や、複数属性主キーがある場合や、リソース・キーとして代替の一意キーが定義されている場合を含む)。これら2つのビジネス・オブジェクト・エンドポイント・データ・ソースには、セレクタ$context.etagによりBOSS etagにマップされているAPEX$ETAGという列も含まれます。ビジネス・オブジェクトでhistoryType='versionNumber'タイプの属性が定義されている場合、行を更新または削除するにはこの列が必要です。データ・プロファイルには、その他のすべてのビジネス・オブジェクト属性のための、適切に定義された列もあります。

データ・プロファイル列の注釈

適切に構成されたデータ型、書式マスク(日付用)およびRESTペイロード・セレクタに加えて、各データ・プロファイル列の「追加情報」フィールドには、APEXがBOSS RESTエンドポイントとやり取りする方法を最適化するために使用される、大/小文字が区別される次のタグ名1つ以上のカンマ区切りリストを含めることができます。APEXの「RESTデータ・ソースの作成」ウィザードでは、HasDefaultとSubtypeを除き(これらは必要に応じて手動で追加する必要がある)、それらほとんどを自動的に推測できます。

RemotePK - 作成ペイロードからnullのリモート主キーを省略して、その値をサービスがデフォルト設定します。
ETag - BOSSによってETag値として使用される行バージョン・インジケータとして、列を特定します。
次のいずれか、または属性が常に更新可能である場合はどれでもない:
- CreateOnly - 更新ペイロードから列を除外します。
- ReadOnly - DMLペイロードから列を除外します。
HasDefault - 作成ペイロードからNULL値列を省略して、サーバー側のデフォルトを優先します。
Required - 現在は強制されていませんが、知っておくと役に立ちます(将来のAPEXで強制される可能性があります)。
Subtype - フィールドを$fieldsリストから除外し、NULLの場合はペイロードの作成/更新から除外します。
Sortable - その列がソート可能であることを示します。
AccessorFK - その列が、参照オブジェクトを割り当てるためのアクセッサ外部キーであることを示します。

データ・プロファイルに関する考慮事項

一部のFusion Applicationsビジネス・オブジェクトには、数百もの標準属性が含まれています。参照の検出を選択した場合は、関連オブジェクトの第1レベルに追加すると、数百の属性があるデータ・プロファイルが生成される可能性があります。最初の150個はVisible = trueとしてマークされ、残りの属性はそのプロパティについてはfalseになります。データ・プロファイル列のVisibleプロパティにより、リージョンの作成時に、アプリケーション・ビルダーでそれを列リストに含めるかどうかが制御されます。そうした属性のすべてをAPEXアプリケーションで扱う必要がない可能性は非常に高いのですが、RESTデータ・ソースの作成ウィザードでは、すべての属性に応じたデータ・プロファイル列が定義されます。開発者は、次の2つの簡単な方法で、APEXエンジンと特定のBOSS RESTデータ・ソースの間で交換されるデータの量を合理化できます:

確実に不要なデータ・プロファイル列を削除できます。
データ・プロファイル列を、削除する必要なく、APEXエンジンに対して参照不可としてマークできます。
各リージョンで、リージョンの列リストから他の列を削除するか、コメント・アウトするか、サーバー側の「条件」を「なし」に設定して、必要な列のみが使用されるようにすることができます。

単一のリクエストで使用できるBOSS RESTエンドポイント・ビジネス・オブジェクト属性の最大量に正確な上限はありませんが、実際には、単一のリージョンについて数百の属性のデータを問い合せようとすると、実行時例外が発生する可能性があります。実際の制限は、関連する属性名の長さと問合せに関与する属性の合計数によって異なります。BOSS RESTデータ・ソースの作成後は、いつでも、そのデータ・ソースを編集しそのデータ・プロファイルにアクセスすることで、参照可能にするデータ・プロファイル列を調整できます。

リソース名の設定

各BOSS RESTデータ・ソースには「ルート・リソース名」設定があり、その値は、「RESTデータ・ソースの作成」ウィザードによって自動的に推測されます。この設定では、エンドポイントのルート・リソースの大/小文字が区別される名前を特定します。

トップ・レベル・ビジネス・オブジェクト(employee (従業員)など)を定義するエンドポイント(.../v1/employeesなど)の使用時は、ルート・リソース名がRESTリソースの名前(たとえば、employees)と同じになります。ただし、エンドポイントURL (.../v1/employees/:empid/vacationRequestsなど)を使用して、employee (従業員)が所有する、関連する子オブジェクトのコレクション(Vacation Requests (休暇リクエスト)など)に対してBOSS RESTサービスを定義した場合は、このVacation Requests (休暇リクエスト)データ・ソースのルート・リソース名もemployeesになります。これは、それがルートEmployeeオブジェクトが所有するデータのツリーに含まれているためです。

18.4.8.3 BOSS RESTデータ・ソース定義について