Oracle APEX 24.2のRESTデータ・ソースのトークンによるページネーションのサポートを確認する

Oracle APEX 24.2のRESTデータ・ソースで新たに、ページ・サイズとページ・トークンによるページネーションがサポートされました。以前に記事「東京都のオープンデータAPIを呼び出してデータを取得する」で、PL/SQLを使って東京都が提供しているオープンデータAPIを呼び出す方法を紹介していますが、APEX 24.2からはPL/SQLのコーディングは必要なく、RESTデータ・ソースの設定だけでページネーションに対応できます。

以下より、東京都のオープンデータAPIを呼び出して文化財一覧のデータを取得し、Oracle APEXでレポートなどを表示するアプリケーションを作成してみます。

作成したAPEXアプリケーションは、以下のように動作します。

今回使用するAPIは、東京都の以下のページで紹介されています。

オープンデータAPIについて

https://portal.data.metro.tokyo.lg.jp/opendata-api/

この中のCulturalPropertyを呼び出します。

以下より、アプリケーションの作成手順を紹介します。

最初に空のAPEXアプリケーションを作成します。名前はTokyo Metropolitan Government Open Data APIとします。

アプリケーションが作成されたら、共有コンポーネントのRESTデータ・ソースを開きます。

作成済みのRESTデータ・ソースが一覧されます。作成をクリックします。

RESTデータ・ソースの作成はデフォルトの最初からのまま変更せず、次へ進みます。

東京都のオープンデータAPIのエンドポイントを設定します。

RESTデータ・ソース・タイプは簡易HTTPです。名前はTokyo Cultural Propertiesとします。URLエンドポイントの指定は以下になります。

https://api.data.metro.tokyo.lg.jp/v1/CulturalProperty

次へ進みます。

リモート・サーバーの設定に移ります。リモート・サーバーが未設定の場合は- 新規作成 -となります。自動的に検出されたベースURLやサービスURLパスは、通常は変更不要です。

次へ進みます。

東京都のオープンデータAPIのページネーションの仕組みを設定します。

東京都のオープンデータAPIは、以下の形式でレスポンスを返します。

[
    [
         { 文化財1のJSONデータ },
         { 文化財2のJSONデータ },
         ....
         { 文化財NのJSONデータ }
    ],
    {
         "endCursor": "後続のAPI呼び出しの引数cursorに与える値",
         "moreResults": "MORE_RESULTS_AFTER_LIMIT",
         ...
     }
]

よって、ページネーションとして以下の設定を行います。

ページ区切りタイプとしてページ・サイズとページ・トークンを選択します。APIの仕様よりページ・サイズURLパラメータにlimit、ページ・サイズ最大に100を設定します。設定可能な仕様上の最大値は1000です。

ページ・トークンURLパラメータはcursor、次のページ・トークン・セレクタは[1].endCursorです。REST APIのレスポンスよりセレクタ$[1].endCursor（内部で指定したセレクタの先頭に$を付けます）で取り出した値が、続けて発行されるREST APIの引数cursorに割り当てられます。

東京都のオープンデータAPIの仕様では、moreResultsの値がMORE_RESULTS_AFTER_LIMITであれば追加のデータが存在し、moreResultsがNO_MORE_RESULTSであれば、データの終了となっています。

この仕様に合わせて、その他の行セレクタとして[1].moreResultsを指定し、次の値のときのその他の行に次と等しい、その他の行属性値としてmore_results_after_limitを設定します。その他の行属性値は英小文字で記述します。現在は、大文字小文字を区別せずに一致を確認するために、取り出した文字列を一律で小文字に変換しその他の行属性値に指定した値と比較しています。そのため、その他の行属性値を小文字で指定する必要があります。製品の不具合として、将来の修正対象となっています。

ページ区切りタイプがページ・サイズとページ・トークンである場合、その仕組みより順方向のページングのみが可能です。ページ番号またはフェッチ・オフセットが引数として与えられないため、中間のデータだけが欲しい場合でも、つねにデータの先頭から順番に読み出す必要があります。そのため、多数のREST APIを発行し、何度も同じデータを取得することが起こり得ます。

この点については、Oracle APEXのRESTデータ・ソースの同期化を構成して、ローカル・データベースに取得したデータを保存することで対応することにします。

次へ進みます。

認証は不要なのでオフのままにします。そのまま検出をクリックします。

東京都のオープンデータAPIが呼び出され、文化財一覧のデータが取得されます。しかし、表示は１行だけで、UpdatedやRevisionといった、文化財とは関係ないデータが表示されます。これは、東京都のオープンデータAPIが配列の2番目の要素として返している、REST APIリクエストのメタデータです。

レスポンス本文を開くと、実際に受信されたデータを確認できます。

受信したデータを確認したのち、データ・プロファイルを開き、不要な属性を削除します。

検出された属性のうち、セレクタに@typeを含む属性はOracle APEXで扱うことはありません。また、REST APIのメタデータに関する属性も不要です。

以下の名前の属性を削除します。

C_TYPE, 参照__TYPE, 名称__TYPE, UPDATED, REVISION, ENDCURSOR, EX_員数__TYPE, 管理者__TYPE, 管理者_種別コード__TYPE, MORERESULTS, 権利管理__TYPE, 設置地点__TYPE, 設置地点_住所__TYPE, 設置地点_連絡先__TYPE, 設置地点_地理座標__TYPE, 設置地点_利用可能時間__TYPE, メタデータ__TYPE, メタデータ_作成者__TYPE, EX_文化財指定日__TYPE

検出された52の属性から19の属性を削除し、結果として33個の属性を持ったRESTデータ・ソースを作成します。

RESTデータ・ソースの作成をクリックします。

RESTデータ・ソースTokyo Cultural Propertiesが作成されます。RESTソース名をクリックし、作成されたRESTデータ・ソースをさらに調整します。

データ・プロファイルの編集をクリックします。

列ID、EX_員数_数値、設置地点_地理座標_経度、設置地点_地理座標_緯度、メタデータ_作成者_IDのデータ型が数値になっています。実際には数値としては扱えないデータが含まれていることがあります。そのため、数値のままだとエラーが発生します。

エラーの発生を回避するため、これらの列のデータ型をすべてVarchar2に変更します。長さは4000とします。数値として扱う場合は、APEXのアプリケーション側でto_numberを呼び出して数値に変換します。

列IDは本来主キーとして設定できるはずなのですが、APIのレスポンスに空行が含まれているため、列IDの主キーをオンにするとエラーが発生します。そのため、主キー設定も行いません。

設定の行セレクタに[0]を設定します。REST APIのレスポンスとして受信したJSON配列の最初の要素（インデックスとしては０）がデータで、次の要素（インデックスとしては１）はレスポンスのメタデータであるため、最初の要素だけをデータとして限定します。

データ・プロファイルに以上の変更を実施し、変更の適用をクリックします。

リクエストの発行を節約するためにRESTデータ・ソースの同期化を使い、ローカル・データベースに文化財一覧の情報をキャッシュします。

RESTデータ・ソースの同期化の管理を開きます。

同期先として新規表を選択し、表名にEBAJ_TOKYO_CULTURAL_PROPERTIESを指定します。RESTデータ・ソースの同期化が完了すると、文化財の情報を表EBAJ_TOKYO_CULTURAL_PROPERTIESから参照できるようになります。

保存をクリックします。

REST同期化の設定画面が開きます。

同期化表が存在しません。とレポートされています。SQLの表示をクリックし、表EBAJ_TOKYO_CULTURAL_PROPERTIESを作成するDDLを確認します。

以下の列名が長すぎて、途中で名前が切れてしまっています。また、列名と型名が繋がっている部分もあります。

   ,"設置地点_利用可能時間_終了 VARCHAR2(4000)

   ,"設置地点_利用可能時間_開催 VARCHAR2(4000)

   ,"設置地点_利用可能時間_開始 VARCHAR2(4000)

そのため、この画面からは表を作成することができません。

SQLワークショップのSQLコマンドを開き、エラーが発生しないように修正した以下のDDLを実行します。

アプリケーション・ビルダーに戻り、RESTデータ・ソースの同期化の管理を開きます。同期化表EBAJ_TOKYO_CULTURAL_PROPERTIESが作成されているため、表のステータスとして「表"EBAJ_TOKYO_CULTURAL_PROPERTIES"は同期化の準備ができています」と表示されます。

初回の同期化では、同期タイプは追加または置換を選択します。データ・プロファイルに主キーが含まれていないため、マージはできません。次回以降は置換を選択します。

保存して実行をクリックすると、作成したRESTデータ・ソースを使って東京都の文化財一覧を読み出し、表EBAJ_TOKYO_CULTURAL_PROPERTIESに保存します。

RESTデータ・ソースの最後の同期化やログの情報より、REST同期化が成功したことを確認します。

ログから表EBAJ_TOKYO_CULTURAL_PROPERTIESに248行の文化財のデータが読み込まれたことが確認できます。RESTデータ・ソースのページネーションの設定ではlimitに100を設定しているため、3回のリクエストですべてのデータを読み取っています。

以上でRESTデータ・ソースの作成が完了し、データもローカル・データベースにキャッシュされました。

これから、アプリケーションにページを追加していきます。

最初に対話モード・レポートのページを追加します。

ページの作成をクリックします。

対話モード・レポートを選択します。

ページの名前は文化財一覧とします。データ・ソースとしてRESTソースを選択し、RESTデータ・ソースとしてTokyo Cultural Propertiesを選択します。

ページの作成をクリックします。

対話モード・レポートを含むページが作成されます。

ページ作成直後は、対話モード・レポートは同期化表を参照する設定になっていません。対話モード・レポートのリージョンを選択し、REST同期化のローカル表の使用をオンにします。

以上でページを実行します。

対話モード・レポートに東京都の文化財一覧が表示されます。東京都のオープンデータAPIを呼び出して取得されたデータがそのまま表示されているため、見にくい部分もあります。

オープンデータAPIから得られたデータを加工するビューEBAJ_TOKYO_CULTURAL_PROPS_Vを作成します。これから作成するファセット検索とマップのソースとして使用します。

作成したビューをソースとしたファセット検索のページを作成します。

ページの作成を実行し、ファセット検索を選択します。

ページの名前は文化財検索、データ・ソースの表/ビューの名前としてEBAJ_TOKYO_CULTURAL_PROPS_Vを選択します。

次へ進みます。

ファセットとして列TYPE（東京都の文化財一覧としては種別に当たるデータ）を選択したいのですが、これはJSON配列であるためタイプがclobとして認識されています。そのため、ファセットとして選択できません。

表示形式にレポートを選択し、ファセットとしては何も選択しません。ページの作成後に列TYPEをファセットとして追加します。

以上でページの作成をクリックします。

ページが作成されたら、レンダリング・ツリーのファセット上でコンテキスト・メニューを表示し、ファセットの作成を実行します。

作成したファセットの識別の名前はP3_TYPEとします。タイプはチェック・ボックス・グループです。

ラベルは本来の名前である種別、LOVのタイプは個別値を選択します。アクション・メニューのフィルタとチャートは不要なのでオフとします。ソースのデータベース列はTYPE、データ型はVARCHAR2です。複数の値のタイプにJSON配列を選択し、フィルタの結合にAND(論理積)を選択します。

ページを作成するウィザードでは列TYPEの型がClobと認識されていましたが、実際にはVARCHAR2です。また、複数の値のタイプにJSON配列を選択するにはVARCHAR2である必要があります。

検索結果のレポートに含まれる列LONおよびLATはそれぞれ経度と緯度の数値で、列TYPEはファセットとして使用しているため、レポートに表示する必要はありません。

列LON、LATおよびTYPEを選択し、タイプを非表示に変更します。

以上でファセット検索のページは完成です。ページの保存と実行を行い、動作を確認します。

最後に、地図上に文化財の位置を表示するページを作成します。

ページの作成を実行し、マップを選択します。

ページの名前は文化財の場所、データ・ソースの表/ビューの名前としてEBAJ_TOKYO_CULTURAL_PROPS_Vを選択します。

次へ進みます。

 マップ・スタイルとしてポイントを選択します。

マップ属性のジオメトリ列タイプとして２つの数値列を選択し、経度列はLON(Number)、緯度列はLAT(Number)とします。ツールチップ列にNAME(Varchar2)を選択します。

ファセット検索ページの作成はオンにします。

以上でページの作成をクリックします。

マップを含んだページが作成されます。

最初に先ほど作成した文化財検索のページと同様に、種別のファセットを作成します。

レンダリング・ツリーのファセット上でコンテキスト・メニューを表示し、ファセットの同期化を実行します。

ファセットの同期化ではなくファセットの作成を実行して作成したファセットは、なぜかマップ・リージョンと連動しませんでした。ファセットの同期化であればマップ・リージョンと連動するファセットが作成されるため、こちらの実行をお勧めします。

ビューEBAJ_TOKYO_CULTURAL_PROPS_Vに含まれるすべての列がファセットとして追加されます。ファセットP4_SEARCHとP4_TYPEを除き、その他のファセットを削除します。

 ファセットP4_TYPEは、文化財検索のファセットP3_TYPEと同じ設定にします。

マップの表示を少し調整します。レイヤー文化財の場所を選択します。

行のマッピングの主キー列としてIDを選択します。

ツールチップの拡張フォーマットをオンにし、HTML式に以下を記述します。ツールチップに文化財の名前を太字、その下に住所を表示します。

<b>&NAME.</b>
<br>
&ADDRESS.

 情報ウィンドウのタイトル列にNAME、本体列にDESCRIPTIONを指定します。

 ファセット検索が付いた文化財の場所を表示する地図のページが作成できました。

以上で、東京都が提供しているオープンデータAPIを活用したAPEXアプリケーションは完成です。

Oracle APEX 24.2のRESTデータ・ソースの新機能としてトークンによるページネーションがサポートされたため、ほぼノーコードでアプリケーションを作成することができました。

さて、Oracle Databaseに東京都が提供しているオープンデータが保存されています。

以前の記事「Oracle Databaseに接続するMCPサーバーを作成しClaudeから問い合わせる」で紹介しているClaudeのデスクトップ・アプリケーションに組み込んだMCPサーバーからオープンデータを保存しているスキーマに接続することにより、AIによる問い合わせも可能です。

 Claude 3.5 Sonnetに、作成した表EBAJ_TOKYO_CULTURAL_PROPERTIESを認識させてから、東京の名勝を一覧してもらいました。10件の名勝が一覧されました。

ファセット検索でも、東京都の文化財として登録されている名勝は10件でした。

今回の記事は以上になります。

今回作成したAPEXアプリケーションのエクスポートを以下に置きました。

https://github.com/ujnak/apexapps/blob/master/exports/rest-token-pagination-with-tokyo-opendata.zip

Oracle APEXのアプリケーション作成の参考になれば幸いです。

完

Oracle APEX 24.1のRESTデータ・ソースでサポートされたデータ型の配列を確認する

Oracle APEX 24.1のRESTデータ・ソースでは、受信したJSONレスポンスに含まれるJSON配列を文字列ではなくJSON配列として認識するようになりました。RESTデータ・ソースのデータ・プロファイルのデータ型は配列になります。

JSON配列を扱えるようになったことにより、JSONドキュメントに含まれている階層構造の情報（親子関係のある情報）を扱うことができます。

Oracle APEX 24.1のRESTデータ・ソースの拡張については、Oracle APEXのアーキテクトのCarsten CzarskiさんがOracleの公式ブログの記事で解説されています。

APEX 24.1: REST Data Sources and nested JSON responsesh

https://blogs.oracle.com/apex/post/rest-data-sources-and-nested-json-responses

APEXアプリケーションを作成し、ブログ記事に沿って新しく追加された機能を確認していきます。

元の記事では階層を含むJSONドキュメントを返すREST APIについて、すでに作成済みのURLを紹介しています。本記事ではRESTサービスから作成します。

最初にOracle Databaseのサンプル・スキーマのOrder Entryに含まれているJSONデータを、データベースに取り込みます。以前にJSONのサンプル・データをデータベースに取り込む手順は紹介していますが、もう少し簡略化した手順でデータベースに取り込んでみます。

PurchaseOrders.dmpを取り込む表としてEBAJ_PURCHASE_ORDERSを作成します。今回はデータベースとして23aiを使用しているため、JSONコレクション表として作成します。

create json collection table ebaj_purchase_orders;

表を作成したのち以下のスクリプトを実行し、GitHubにあるPurchaseOrders.dmpを表EBAJ_PURCHASE_ORDERSに取り込みます。

9999行のPurchase Orderのドキュメント（いわゆる発注書）が読み込まれます。

データの準備ができたので、この表を元にRESTサービスを作成します。

SQLワークショップのRESTfulサービスを開き、有効なオブジェクトを選択します。

AutoRESTが有効化されたオブジェクトが一覧されます。AutoRESTオブジェクトの作成をクリックします。

オブジェクト・タイプは表、オブジェクトとして先ほど作成した表EBAJ_PURCHASE_ORDERSを選択します。オブジェクト別名にpurchaseordersを設定し、完全なURLに表名が含まれないようにします。認可が必要はいいえとします。

RESTデータ・ソースを作成する際に、ここで表示されている完全なURLを指定します。この値をコピーして保存しておきます。

作成をクリックします。

表EBAJ_PURCHASE_ORDERSをREST APIを通して参照できるようになりました。

ブラウザに完全なURLを入力し、データを確認してみます。

Purchase Orderのドキュメントには、以下の階層構造があることがわかります。

1. itemsとして複数のPurchase Orderのドキュメントが含まれる。
2. POドキュメントには複数のShippingInstructionが含まれる。
3. ShippingInstructionには複数のPhoneが含まれる。
4. POドキュメントには複数のLine Item（いわゆる品目）が含まれる。

このRESTサービスを元にRESTデータ・ソースを作成します。

その前にいくつか注意点を記録しておきます。

Oracle APEX 24.1.1のRESTfulサービスの画面よりAutoREST定義を削除しようとすると、ORA-2290のエラーが発生しました。

代替となる削除方法は２通りあります。ひとつ目の方法は、プロシージャORDS.ENABLE_OBJECTを引数p_enabledにfalseを渡して呼び出し、オブジェクトに対して適用したAutoRESTを無効化します。

begin
    ords.enable_object(
        p_enabled => false
        ,p_object => 'EBAJ_PURCHASE_ORDERS'
    );
end;

もう一つの方法は、データベース・アクションのRESTよりAutoRESTを開き、オブジェクトの無効化を実行します。

また、JSONコレクション表やJSONを保存するデータ型をJSONではなく、CLOBやBLOBとしている場合は、AutoRESTではJSONドキュメントを適切な形式で返しません。

その場合は、モジュールとテンプレートを作成し、GETハンドラに以下のSELECT文を記述します。JSON型に変換できる場合は、JSONファンクションを使用します。

select json(data) data from ebaj_purchase_orders

JSON型が使えない場合はエスケープを抑止する列に別名を付け、その先頭に"{}"を付加します。

select data "{}data" from ebaj_purchase_orders -- CLOBの場合

select to_clob(data) "{}data" from ebaj_purchase_orders -- BLOBの場合

RESTサービスが作成できました。

これからAPEXアプリケーションを作成し、本題のRESTデータ・ソースを作成してJSON配列の扱いを確認します。

アプリケーションの作成を呼び出し、空のAPEXアプリケーションを作成します。名前はPurchase Ordersとします。

アプリケーションの作成をクリックします。

アプリケーションが作成されたら、共有コンポーネントを開きます。

RESTデータ・ソースを開きます。

作成済みのRESTデータ・ソースが一覧されます。作成をクリックし、Purchase OrdersのREST APIを呼び出すRESTデータ・ソースを作成します。

RESTデータ・ソースの作成は最初から行います。

次へ進みます。

RESTデータ・ソース・タイプとして簡易HTTPを選択します。名前はPurchase Ordersとします。URLエンドポイントとして、作成したREST APIの完全なURLを入力します。

次へ進みます。

新規作成またはすでに作成済みのリモート・サーバーの設定を確認します。

次へ進みます。

ページ区切りタイプとしてページ区切りなしを選択します。

次へ進みます。

認証が必要ですはオフです。

検出をクリックします。

REST APIを呼び出し取得したJSONドキュメントを解析し、属性の名前やデータからデータ型を推定します。

データ・プロファイルを開き、推定されたデータ型を確認します。

行セレクタとしてitemsが認識されています。つまり、それぞれのPOドキュメントは属性itemsに配列として含まれています。

認識されたデータ・プロファイルには、いくつかデータ型がARRAYの行が含まれます。セレクタdata.LineItemsやdata.ShippingInstructions.Phoneです。

RESTデータ・ソースの作成を実行します。

RESTデータ・ソースPurchase Ordersが作成されます。作成された内容を確認するため、Purchase Ordersを開きます。

PL/SQLコードからRESTデータ・ソースを呼び出す際に使用する静的IDを確認します。今回はpurchase_ordersとなっていました。

データ・プロファイルの編集を開きます。

データ・プロファイルDATA_LINEITEMS（セレクタ：data.LineItems）のデータ型が配列であり、それを親列としたデータ・プロファイルとしてPART_UPCCODE、PART_UNITPRICE、PART_DESCIPTION、QUANTITY、ITEMNUMBERが作成されています。

この他にデータ・プロファイルDATA_SHIPPINGINSTRUCTIONS_PHONE（セレクタ：data.ShippingInstructions.Phone）のデータ型が配列であり、それを親列としたデータ・プロファイルとしてTYPEとNUMBER_が作成されています。

この他にデータ・プロファイルLINKSのデータ型が配列として認識されています。データ・プロファイルのLINKS、REL、HREFはORDSが自動的に付与する属性であるため、共通をNoに変更し、ページ作成ウィザードによるレポート作成時に列として含まれないようにします。

この共通はOracle APEX 24.1で、データ・プロファイルに追加された属性です。

変更の適用をクリックします。

以上でRESTデータ・ソースの作成は完了です。

作成したRESTデータ・ソースPurchase Ordersをソースとした、APEXのレポートを作成します。

ページ・デザイナでホーム・ページを開き、新たにリージョンを作成します。

識別の名前はPurchase Orders、タイプは対話モード・レポートとします。ソースの位置にRESTソースを選択し、RESTソースとしてPurchase Ordersを設定します。

ソースとしてRESTソースを選択すると、リージョンの属性としてデータ・プロファイルと配列列が現れます。

以下では列LINKSは不要なので、コメント・アウトしています。

対話モード・レポートは以下のように表示されます。列DATA_LINEITEMSおよびDATA_SHIPPINGINSTRUCTIONS_PHONEともに、JSONがそのまま表示されます。

同様に対話モード・レポートを作成し、データ・プロファイルの配列列としてDATA_LINEITEMSを指定します。レポートに選択できる配列列は１つのみです。

配列列を設定すると、それを親列としたデータ・プロファイルが列として追加されます。今回の例ではPART_UPCCODE、PART_UNITPRICE、PART_DESCRIPTION、QUANTITY、ITEMNUMBERが列として追加されています。

データプロファイルのデータ型が配列となっている列はすべて列から取り除かれます。今回の例では、DATA_LINEITEMS、DATA_SHIPPINGINSTRUCTIONS_PHONE、LINKSです。

対話モード・レポートは以下のように表示されます。PONumberは一意の数値ですが、LineItemsは複数あるため、レポートには同じPONumberが複数現れます。

ローカル後処理を有効にして、LineItemの単価（PART_UNITPRICE）と数量を掛け合わせて、Purchase Orderごとの合計を計算してみます。

ローカル後処理のタイプにSQL問合せを選択し、SQL問合せに以下を記述します。

select 
    DATA_USER,
    DATA_PONUMBER,
    DATA_REFERENCE,
    DATA_COSTCENTER,
    SUM(PART_UNITPRICE * QUANTITY) as ORDER_TOTAL
  from #APEX$SOURCE_DATA#
  group by 
    DATA_USER,
    DATA_PONUMBER,
    DATA_REFERENCE,
    DATA_COSTCENTER

対話モード・レポートは以下のように表示されます。Order TotalにPuchase Orderごとの合計金額が表示されます。

新たに追加された列Order Totalは最初、非表示になっている場合があります。そのときはアクション・メニューの列を開いて、表示列に追加します。

対話グリッドもRESTデータ・ソースの配列列を扱うことができます。対話グリッド以外でも、RESTデータ・ソースが扱えるコンポーネントは概ね配列列を指定できます。

対話グリッドでは、複数の対話グリッドを使ってマスター・ディテール関係を設定できます。

最初にPurchase Orderを保持する対話グリッドを作成します。データ・プロファイルの配列列は、設定しません。

列DATA_PONUMBERを選択し、検証の必須の値をオン、ソースの主キーをオンにします。

Line Itemを表示する対話グリッドを作成します。すでに作成済みの対話グリッドPurchase Ordersをコピーし、識別の名前をLine Itemsに変更します。

列DATA_PONUMBERを選択し、マスター・ディテールのマスター列としてDATA_PONUMBERを選択します。

あとは、対話グリッドPurchase Ordersに表示されている列をコメント・アウトします。

対話グリッドを表示すると以下のように表示されます。

Oracle APEXが提供しているAPIのAPEX_EXEC.OPEN_REST_SOURCE_QUERYも、配列列に当たる引数p_array_column_nameをサポートしています。

本記事で参照しているCarsten Czarskiさんのプログに載っているコードと処理内容は同じですが、APEXアプリケーション内で動作するように改変しました。

ページのレンダリング前にプロセスを作成し、以下のコードを実行します。ページ・アイテムP5_OUTPUTに結果を出力します。

出力先となるページ・アイテムP5_OUTPUTの識別のタイプはテキスト領域とします。

外観の高さに40を設定し、高さを広げておきます。また表示が崩れないように詳細のカスタム属性で等幅フォントを使用するように設定します。

style="font-family: monospace;"

以上の設定を行いページを実行すると、以下のように表示されます。

続いて引数p_array_column_nameは指定せず、APEX_EXEC.OPEN_ARRAYとAPEX_EXEC.NEXT_ARRAY_ROWを呼び出し、JSONの階層構造を辿ります。

レンダリング前のプロセスで以下のコードを実行します。

ページを実行すると、以下のように表示されます。

今回の記事は以上になります。

今回の記事の説明で使用したAPEXアプリケーションのエクスポートを以下に置きました。

https://github.com/ujnak/apexapps/blob/master/exports/sample-rds-array-purchase-orders.zip

Oracle APEXのアプリケーション作成の参考になれば幸いです。

完