1. アプリケーション・ビルダー・ユーザーズ・ガイド
  2. アプリケーション・データの管理
  3. RESTデータ・ソースの管理
  4. Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

17.4.6 Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

Oracle Cloud SaaS ApplicationsでのAPEX RESTデータ・ソースの使用について説明します。

親トピック: RESTデータ・ソースの管理

17.4.6.1 Oracle Cloud SaaS ApplicationsのRESTデータ・ソース・サポートについて

Oracle Cloud SaaS ApplicationsのRESTデータ・ソース・サポートについて説明します。

Oracle APEXにより、Oracle Cloud Applications (SaaS) RESTサービス・エンドポイント経由でデータの問合せ、挿入、更新および削除を実行する、APEXアプリケーションの構築プロセスが簡素化されます。このサポートには、次のものを対象としたすべてのREST APIが含まれます:

  • Oracle Fusion Cloud Applicationsビジネス・オブジェクト(Fusion Applicationビジネス管理者によってカスタマイズされることもあります)
  • Oracle Visual Builderアプリケーション・ビジネス・オブジェクト
  • Oracle Application Development Framework (ADF)ビジネス・コンポーネントを使用するカスタム・アプリケーション

関連項目:

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

17.4.6.2 Oracle Cloud SaaS AppsのRESTデータ・ソースの作成

Oracle Cloud SaaSアプリケーションのRESTデータ・ソースの作成について説明します。

Oracle Cloud SaaSアプリケーションのRESTデータ・ソースを作成するには、RESTデータ・ソースの作成ウィザードを実行します。プロンプトが表示されたら、RESTデータ・ソース・タイプ「Oracle Cloud Applications (SaaS) REST Service」を選択します。このトピックでは、RESTデータ・ソースの作成ウィザードを実行する際の主な決定ポイントについて説明します。

ヒント:

ウィザードのすべてのオプションの詳細は、「ヘルプ」項目または一般的な説明を参照してください。RESTデータ・ソースの作成

RESTデータ・ソースを作成するには:

  1. 「RESTデータ・ソース」ページにナビゲートします。
    1. ワークスペースのホームページで、「アプリケーション・ビルダー」をクリックします。
    2. アプリケーションを選択します。
    3. アプリケーションのホームページで、「共有コンポーネント」をクリックします。
    4. 「データ・ソース」で、「RESTデータ・ソース」を選択します。
  2. 「RESTデータ・ソース」ページで、「作成」をクリックします。
    RESTデータ・ソースの作成ウィザードが表示されます。
  3. メソッド - 「最初から」を選択し、「次」をクリックします。
  4. 一般:
    1. RESTデータ・ソース・タイプ - 「Oracle Cloud Applications (SaaS) REST Service」を選択します。
    2. 名前 - このRESTデータ・ソースのわかりやすい名前を入力します。
    3. URLエンドポイント - RESTデータ・ソースのエンドポイントURLを入力します(http://またはhttps://で始めます)。
    4. 「次」をクリックします。
  5. リモート・サーバー - デフォルトを受け入れます。

    このステップでは、APEXが「ベースURL」と「サービスURLパス」の組合せとしてREST APIのエンドポイントURLを管理する方法を示します。「ベースURL」と「サービスURLパス」の構成の詳細は、「XX」を参照してください。

  6. 設定、ページ区切りタイプ - デフォルトを受け入れて、「次」をクリックします。
  7. 認証が必要です - 該当する場合は既存の資格証明を選択します。または、「認証タイプ」を選択して新しい資格証明を定義するための関連する詳細を入力します。
  8. 「RESTソースの手動作成」をクリックします。
    RESTデータ・ソースが作成されます。

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

17.4.6.3 Oracle Cloud SaaS AppsのRESTデータ・ソースの定義

Oracle Cloud SaaSアプリケーションのRESTデータ・ソース定義の表示について説明します。

RESTデータ・ソースは、「RESTデータ・ソースの編集」で説明するように、「RESTデータ・ソース」ページで表示できます。新しく作成したOracle Cloud SaaSアプリケーション・データ・ソースには、エンド・ポイントでサポートされるすべての操作、そのすべての属性を反映するデータ・プロファイル、および割り当てられたルート・リソース名が備わっています。定義されていれば、RESTデータ・ソースはページの作成中に任意のAPEXリージョンで使用できます。また、APEX_EXECパッケージで使用可能な適切なプロシージャおよびファンクションを使用することで、それをプログラム的に使用することもできます。

関連項目:

『Oracle APEX APIリファレンス』のAPEX_EXEC

操作

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

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

データ・プロファイル

データ・プロファイルには、APEX$RESOURCEKEYという名前の主キー列が含まれていて、各行を一意に識別するRESTサービスのリソース・キーにマップされています。これにより、基礎となるビジネス・オブジェクトに単一属性主キー、複数属性主キーがあるもの、またはリソース・キーとして代替の一意キーを定義するものを含め、すべてのRESTサービスが任意のエンドポイントに対して一貫した方法で動作することが保証されます。データ・プロファイルには、その他のすべてのビジネス・オブジェクト属性に適切に向けて定義された列もあります。Fusion Applicationビジネス・オブジェクトの一部には、数百の標準属性が含まれているものがあり、その数をさらに増やすようにカスタマイズできるものもあります。そうした属性のすべてをAPEXアプリケーションで扱う必要がない可能性は非常に高いのですが、RESTデータ・ソースの作成ウィザードでは、すべての属性に応じたデータ・プロファイル列が定義されます。次のようにすると、APEXエンジンと特定のOracle Cloud RESTデータ・ソース・アプリケーションの間で交換されるデータの量を合理化できます:

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

APEXは、それぞれのリージョンに必要なフィールド・データのみをリクエストします。単一のリクエストで操作できるRESTエンドポイント・ビジネス・オブジェクト属性の最大量に正確な上限はありませんが、実際には、単一のリージョンについて数百の属性のデータを問い合せようとすると、実行時例外が発生することがあります。実際の制限は、関連する属性名の長さと問合せに関与する属性の合計数によって異なります。

数百もの属性が含まれているFusion Applicationビジネス・オブジェクトのRESTエンドポイントの操作エクスペリエンスを裁量にするために、RESTデータ・ソースの作成ウィザードは、RESTサービスのすべてのデータ・プロファイル列を定義してから、「参照可能」とマークされた列を最大150列に制限します。RESTエンドポイントのビジネス・オブジェクトにカスタム・フィールド(名前に接尾辞"_c"が付いているもの)が含まれている場合、ウィザードは、デフォルトで選択する150の参照可能列に、該当するフィールドができるだけ多く含まれるようにすることを優先しようとします。RESTデータ・ソースの作成後は、いつでも、そのデータ・ソースを編集し、そのデータ・プロファイルを更新することで、参照可能にするデータ・プロファイル列を調整できます。

ルート・リソース名の設定

各RESTデータ・ソースには、「ルート・リソース名」設定があり、その値は、RESTデータ・ソースの作成ウィザードによって自動的に推測されますが、以前のAPEXリリースからアップグレードしたOracle Cloud SaaS Apps RESTデータ・ソースの場合は手動で設定できます。この設定では、エンドポイントのルート・リソースの大/小文字が区別される名前を特定します。

employeeのようなトップ・レベル・ビジネス・オブジェクトを定義する .../latest/employeesなどのエンドポイントを操作する場合、「ルート・リソース名」はRESTリソースの名前(たとえば、employees)と一致します。ただし、.../latest/employees/:empid/child/VacationRequestsのようなエンドポイントURLを使用して、ある従業員が所有する休暇リクエストなどの関連する子オブジェクトの集合に対してRESTサービスを定義する場合、この休暇リクエスト・データ・ソースのルート・リソース名もemployeesになります。これは、それがルートEmployeeオブジェクトが所有するデータのツリーの一部であるためです。トップレベルのRESTエンドポイントの場合、この設定値はAPEXが正しいルート・リソース名を推測できるためオプションですが、ネストされた子リソースに基づくデータ・ソースの場合、この設定は必須になります。

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

17.4.6.4 Oracle Cloud SaaS AppsのRESTデータ・ソース実行時機能

Oracle Cloud SaaS アプリケーションの実行時機能について説明します。

実行時に、RESTエンドポイントに基づくRESTデータ・ソースは、ページ区切り、データのフィルタリング、順序付けおよびバッチ損失更新保護をサポートします。合計結果数の計算の有効化と、バッチDMLの必要に応じた無効化をサポートします。

ページ区切りと合計結果数の計算

ユーザー・インタフェースの目的とREST同期の両方について、RESTデータ・ソースはエンドポイントから返された行のページングをサポートします。

エンド・ユーザーへのページ区切り表示(1-20 of 200など)の表示をサポートするには、「設定」タブに移動し、「合計結果の使用」を「はい」に設定します。この設定により、アプリケーションは、すべての結果を取得することなく結果の合計数を表示します。ページ区切りをサポートしていない特定のRESTエンドポイントを使用している場合は、それに対応するデータ・ソースの「ページ区切りの使用」を「いいえ」に構成します。

データのフィルタリング

APEXエンジンは、エンド・ユーザーがアプリケーションで実行できるほぼすべてのデータ・フィルタリング操作を、サーバー側で実行するためにRESTエンドポイントに委任します。これには、大/小文字を区別しないトークン化された行検索も含まれます。また、必要に応じて、リージョンを定義するときにサービスのフィルタ式を使用することでExternal Filterを指定できます。これは、RESTペイロードの大/小文字を区別するビジネス・オブジェクトの属性名を使用するSQLのような述語です。参考までに、属性名は各データ・プロファイル列の定義の「セレクタ」フィールドに表示されているものです。このフィルタ言語では、ANDとORの結合、カッコを使用したグループ化と演算がサポートされます。たとえば、フィルタは次のようになります:

(category like 'SALES%' or (purchaseDate between '2023-07-15' and '2023-07-31'))

大/小文字を区別しない検索は、upper()で属性名をラップすることで実行できます。たとえば:

upper(lastName) = 'STAR'

外部フィルタではバインド変数はサポートされませんが、APEXの置換パラメータ(&P3_NAME.など)はサポートされます。こうした変数は、フィルタ述語の右側として使用する必要があり、実行時に置換された値に置き換えられるときに、その値はAPEXエンジンによって自動的に一重引用符で囲まれます。たとえば、外部のwhere句は次のようになります:

upper(lastName) = &P3_NAME.

P3_NAMEページ・アイテムに値CHIPが含まれているとすると、RESTサービスは次の外部WHERE句を認識します:

upper(lastName) = 'CHIP'

データの順序付け

APEXエンジンは、エンド・ユーザーが実行できるデータの順序付けを、サーバー側で実行するためにRESTエンドポイントに委任します。また、必要に応じて、RESTデータ・ソースに基づいてリージョンを定義するときに、外部並べ替え基準句を指定できます。その構文は、1つ以上の属性名のカンマ区切りリストで、大/小文字が区別され、それぞれに昇順の場合は:asc、降順の場合は:descの接尾辞を付けます。たとえば、次の外部並替え基準の式は、部門番号の基準で昇順にソートし、採用日の基準で降順にソートします。

departmentNumber:asc,dateHired:desc

バッチの失われた更新保護

エンド・ユーザーがRESTデータ・ソースから1つ以上のデータ行を変更すると、APEXは効率的なバッチ操作として、失われた更新保護を適用します。たとえば、ユーザーが対話グリッド・リージョンで4つの新しい行を挿入し、3つの行を変更し、2つの行を削除したときに、「保存」をクリックすると、APEXエンジンは、RESTエンドポイントへの1回のラウンドトリップで9行すべてに対して失われた更新保護のチェックを実行します。

バッチDML

エンド・ユーザーがRESTデータ・ソースの1つ以上のデータ行を変更すると、APEXエンジンは、デフォルトで変更されたすべての行を単一の効率的なバッチ操作に保存します。たとえば、ユーザーが対話グリッド・リージョンで4つの新しい行を挿入し、3つの行を変更し、2つの行を削除して、「保存」をクリックするとします。前述の失われた更新保護のチェックを通過すると、APEXエンジンは1回のラウンドトリップで9行すべてをRESTエンドポイントに送信します。つまり、すべての行の変更が一単位として成功するか、それらすべてが一単位として失敗することを意味します。これにより、部分的に成功したトランザクションを元に戻すカスタムのビジネス・ロジックが不要になり、アプリケーション開発が簡略化されます。

RESTエンドポイントの操作中にバッチDMLを使用すると、そのエンドポイントが予期したとおりに動作しないことに気付いた場合は、これを「設定」タブで無効にできます。「バッチDMLの使用」を「いいえ」に設定します。RESTデータ・ソースに対してバッチDMLが無効になっている場合、それぞれの削除、挿入および更新は、RESTエンドポイントへの個別のコールを使用して実行されます。

自動的にAPEXエラーとして表示する検証エラー

エンド・ユーザーがページへの変更内容を保存すると、RESTデータ・ソースに基づくリージョンでは、自動的に検証エラーがAPEXエラーとしてレポートされます。それにより、ユーザーは、サーバー側のビジネス・オブジェクト検証ルールまたはトリガーによって発生した検証の失敗を、APEXアプリケーション自体の内部で定義されたエラー・メッセージと同じ見慣れた方法で確認できます。複数のエラー・メッセージは、それぞれAPEXエラー・メッセージの新しい行に表示されます。プログラムでエラー・メッセージを操作する場合は、エラー・メッセージ間のデリミタとして4文字の文字列"<br>"を使用して、1つのメッセージを複数の個別のエラー・メッセージに分割します。

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

17.4.6.5 例による問合せおよび親と子のユースケースのフィルタ・パラメータ

例による問合せおよび親と子のユースケースのフィルタ・パラメータを作成します。

カスケード選択リストおよび例による問合せ(QBE)のユースケースを簡単に構築するために、APEX RESTデータ・ソースでは、「行のフェッチ」データベース・アクションに関連するGET操作にフィルタ・パラメータを定義できます。これらは、ランタイム動作の3つの側面を宣言的に構成する特別に定式化されたパラメータ名を持つ「URLパターン」のパターン・パラメータです:

  • フィルタする大/小文字を区別する属性の名前。たとえば:

    SomeAttr

  • 使用がサポートされているフィルタの演算子:

    • equals ( eq )
    • 大/小文字を区別しないcontains ( contains )
    • 大/小文字を区別しないstarts-with ( startswith )

  • パラメータの値がNULLの場合に望まれる動作:

    • パラメータ値がNULLの場合はフィルタを無視する(ignoreifnull)
    • パラメータ値がNULLの場合は行を返さない(norowsifnull)
    • NULL値と一致する(matchifnull)

フィルタ・パラメータの名前は次の形式になります:

attrName_operator$behavior

カスケード・リストのユースケース

たとえば、SubcomponentsForComponentという名前のデータ・ソースについて、equals演算子を使用したフィルタをcomponentIdという名前の親属性に適用し、その値がnullの場合は行を戻さないようにする場合、定義するパラメータ名は次のようになります:

componentId_eq$norowsifnull

P3_COMPONENT_IDとP3_SUBCOMPONENT_IDのカスケード選択リストが含まれたページを作成する場合、後者はSubcomponentsForComponent RESTデータ・ソースを使用する共有コンポーネントLOVに基づいた選択リスト・ページ・アイテムにできます。このLOVでは、データ・ソースのcomponentId_eq$norowsifnullパラメータの値をページ・アイテムP3_COMPONENT_IDの値に割り当てることができます。最後に、ページ・デザイナでP3_SUBCOMPONENT_ID選択リスト・ページ・アイテムの親アイテムとしてP3_COMPONENT_IDを構成すると、カスケード・リストは期待どおりに動作します。

例による問合せページのユースケース

Peopleという名前のデータ・ソースについて、firstName属性とlastName属性に対して大/小文字を区別しないcontainsマッチングを実行し、その値がnullの場合はそれぞれのフィルタを無視する場合、定義する2つのフィルタ・パラメータ名は次のようになります:

  • firstName_contains$ignoreifnull
  • lastName_contains$ignoreifnull

例による問合せページに戻り、ページ・アイテムのP4_FIRST_NAMEとP4_LAST_NAMEを定義し、前述の2つのRESTデータ・ソース・パラメータを構成すると、それらの値をそれぞれのページ・アイテムから取得できます。検索結果リージョンの「送信するページ・アイテム」属性にP4_FIRST_NAMEとP4_LAST_NAMEが指定されていることを確認すると、動作する例による問合せページができあがります。

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

17.4.6.6 サンドボックスに対する操作

APEXアプリケーションとサンドボックスを関連付けるには、「Oracle Cloud Applications (SaaS) REST Service」ページの「コンポーネント設定」、「共有コンポーネント」でサンドボックス名を定義します。

Oracle Fusion Applicationsビジネス管理者は、SaaSアプリケーションのビジネス・オブジェクト・データ・モデルをカスタマイズするときに、サンドボックスと呼ばれる名前付きのプライベート開発領域のコンテキスト内で保留中の変更を実施します。サンドボックス内で実施された変更は、本番アプリケーションを使用するエンド・ユーザーには表示されません。Oracle APEXでは、サンドボックスでアクティブにカスタマイズしているビジネス・オブジェクトのRESTエンドポイントに対してOracle Cloud Apps RESTデータ・ソースが動作可能なアプリケーションを作成できます。

管理者は、「Oracle Cloud Applications (SaaS) REST Service」ページの「コンポーネント設定」、「共有コンポーネント」を使用して、APEXアプリケーションで適切なサンドボックス名を構成するだけです。説明は、「Oracle Cloud Applications (SaaS) REST Serviceの構成」を参照してください。サンドボックス名を定義すると、アプリケーション・ビルダーは、そのアプリケーションでRESTデータ・ソースを作成、編集および実行するときに、そのサンドボックスに存在するビジネス・オブジェクトの保留中のバージョンを反映するRESTエンドポイントを使用します。

これにより、Fusion Applicationsビジネス・オブジェクトのカスタマイズは、カスタマイズしたバージョンのビジネス・オブジェクト・データの操作が必要なAPEXアプリケーションと並行して反復的に開発できるようになります。Fusion Appsバックエンドに新しいカスタム・オブジェクトを追加する場合は、そのカスタム・オブジェクトをサンドボックスから使用するために新しいRESTデータ・ソースを定義できます。既存のオブジェクトに新しいカスタム属性を追加すると、APEXは、そうしたカスタム属性もサンドボックスで認識します。以前に特定のOracle SaaS RESTエンドポイントにAPEX RESTデータ・ソースを定義していた場合は、その間に実施した新しいカスタマイズを反映するように簡単に更新できます。たとえば、サンドボックスで属性を追加すると、次のステップを実行するだけで、APEXアプリケーションでも新しいカスタム属性を反復的に認識できます:

  1. 既存のRESTデータ・ソースを編集し、「データ・プロファイル」を編集して、再検出をクリックします。APEXにより、新しい属性が表示され、それらが含まれるようにデータ・プロファイルを拡張できるようになります。

  2. このRESTデータ・ソースを使用しているページ内の既存のリージョンを編集し、コンテキスト・メニューから「列の同期化」を選択します。これにより、当該のリージョンに新しい列が含まれます。「列の同期化」の実行時に、リージョン内の列またはページ・アイテムにコメント・アウトするマークが付いていると、それらはコメント・アウトされたままになり、新しいフィールドのみがコメントされていない列またはページ・アイテムとして必要に応じて追加されます。

サンドボックスをパブリッシュするときには、APEXアプリケーションでサンドボックス名をクリアするだけで、すぐにパブリッシュ済のRESTエンドポイントの使用が再開されます。

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

17.4.6.7 REST ServiceベースURLを構成する際のベスト・プラクティス

REST ServiceベースURLを構成する際のベスト・プラクティスについて説明します。

APEXアプリケーションを構築するときには、開発環境と本番環境を別々に使用することが一般的です。そのアプリケーションでRESTデータ・ソースを使用する場合は、通常、DEVとPRODでは異なるRESTエンドポイントURLを使用します。これにより、本番エンド・ユーザーや本番データに混乱を引き起こすことなく、開発環境でアプリケーションをテストできます。APEXリモート・サーバー機能により、Oracle Cloud SaaSアプリケーションのRESTデータ・ソースなどのRESTデータ・ソースを操作するときに、この使用パターンに簡単に対応できます。

RESTデータ・ソースを定義するときに、エンドポイントURLを指定します。APEXでは、このURL値を2つの部分からなる文字列として管理します。先頭の部分はベースURLで、特定のリモート・サーバー定義から取得されます。エンドポイントURLの末尾の部分は、サービスURLパスです。APEXでは、アプリケーションを別の環境にデプロイするときにリモート・サーバーのベースURLの値を簡単に変更できるようにしているため、この概念を理解することが重要です。リモート・サーバーのベースURLの値はターゲット・デプロイメント環境に固定されたままになるため、アプリケーションの更新済バージョンをDEVからPRODに簡単にデプロイでき、PRODのリモート・サーバーのベースURL定義はPROD用に構成したままになります。

操作が必要なRESTエンドポイントのURL、およびDEV環境とPROD環境の切替え時に、どのような変更が必要になるかを調べます。これにより、エンドポイントURLを変更可能なベースURL部分と、両方の環境で同じ静的サービスURLパスに分割する場所を決定できます。RESTデータ・ソースの作成ウィザードの実行中に、「リモート・サーバー」ステップで「リモート・サーバー」と「サービスURLパス」を調整して、アプリケーションを別のAPEXインスタンスにデプロイするときに変更が必要になるRESTサービスのエンドポイントURLの前半部分をカプセル化できるようにします。その後、サービスのエンドポイントURLの後半部分を保持するように「サービスURLパス」を調整します。これは、デプロイメント間で常に同じままになります。RESTデータ・ソースのエンドポイントURLのベースURLとサービス・パスURLの間の分割方法は、いつでも後から調整できます。

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

17.4.6.8 デフォルトの実行時ヘッダーの必要に応じたオーバーライド

新しいRESTフレームワーク・バージョンを使用するように、「RESTデータ・ソース」パラメータを定義します。

デフォルトでは、APEXはエンドポイントとの通信にRESTフレームワークのバージョン6を使用します。それより新しいRESTフレームワーク・バージョンを使用するように特定のRESTデータ・ソースを定義する必要がある場合、これはHeader型のモジュール・パラメータ(または操作パラメータ)を定義することで実現できます。ヘッダーにREST-Framework-Versionという名前を付けて、ヘッダーの値として使用する必要がある引用符なしのオーバーライドしたバージョン番号を指定します。たとえば:

REST-Framework-Version = 7

デフォルトでは、APEXはアプリケーションの「Oracle Cloud Applications (SaaS) REST Service」ページの「コンポーネント設定」、「共有コンポーネント」で構成したサンドボックス名を使用するように、RESTリクエストに切なヘッダーを構成します(その値がnullでない場合)。アプリケーション・レベルの設定がnullの場合、ヘッダーは送信されません。特定のRESTデータ・ソースのアプリケーション・レベルのサンドボックス名設定をオーバーライドする必要がある場合、これはHeader型のモジュール(または操作)パラメータを定義することで実現できます。ヘッダーにMetadata-Contextという名前を付けて、その値を次のいずれかに設定します:

  • sandbox="YourOtherSandboxName" (サンドボックスの名前がYourOtherSandboxの場合)
  • この特定のデータ・ソース(または操作)がサンドボックスを使用しないようにするシグナルとして、ヘッダー値を空白(またはnull)のままにします。

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用

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

「追加情報」属性を使用して、データ・プロファイル列の注釈を追加します。

適切に構成されたデータ型、書式マスク(日付用)およびRESTペイロード・セレクタに加えて、データ・プロファイル列の「追加情報」属性を使用すると、APEXがRESTデータ・ソース・エンドポイントと通信する方法を最適化するために使用される、次の大/小文字が区別されるタグ名のカンマ区切りリストを含めることができます:

  • RemotePK - 作成ペイロードからnullのリモート主キーを省略して、その値をサービスがデフォルト設定します。
  • CreateOnly - 更新ペイロードから列を除外します。
  • ReadOnly - DMLペイロードから列を除外します。
  • HasDefault - 作成ペイロードからNULL値列を省略して、サーバー側のデフォルトを優先します。
  • Required - 現在は強制されていませんが、知っておくと役に立ちます(将来のAPEXで強制される可能性があります)。

親トピック: Oracle Cloud SaaS ApplicationsのRESTデータ・ソースの使用