2023年4月27日木曜日

APEX 23.1で追加されたセッション・ステート・コミットの注意点

 Oracle APEX 23.1より、アプリケーション定義のセキュリティのセッション管理のセクションに、セッション・ステート・コミットという属性が追加されました。

セッション・ステート・コミットには、即時またはリクエストの終わりのどちらかを設定します。

セッション・ステート・コミットが即時の場合、APEX 22.2までと同じ動作になります。そのため、APEX 23.1にアップグレードする以前から存在するアプリケーションのセッション・ステート・コミットは即時が設定されます。

Oracle APEX 23.1の環境で新規に作成したアプリケーションは、セッション・ステート・コミットはリクエストの終わりが設定されます。

セッション・ステート・コミットの設定は、セッション・ステートの操作で発生する暗黙コミットに影響を与えます。Oracle APEXの暗黙コミットについては、以下の記事で説明しています。

APEXのプロセスで発生する暗黙コミットの注意点

上記の記事で使用しているサンプル・アプリケーションを使って、セッション・ステート・コミットの効果を確認できます。
https://github.com/ujnak/apexapps/blob/master/exports/test-implicit-commit.zip

このサンプル・アプリケーションの含まれるプロセスUpdate Page Itemに、以下のコードが記述されています。
:P1_TEXT := '処理完了';
-- apex_util.set_session_state('P1_TEXT','処理完了',true);
-- apex_util.set_session_state('P1_TEXT','処理完了',false);
-- rollback;
元記事では、ページ・アイテムの3種類の操作で発生する暗黙コミットについて、動作の違いを説明しています。

セッション・ステート・コミットにリクエストの終わりが設定されていると、上記すべての操作で暗黙コミットは行われなくなります。つまり、どれも以下と同じ動作になります。

apex_util.set_session_state('P1_TEXT','処理完了',false);

セッション・ステートの操作(主にページ・アイテムであるバインド変数への代入)で暗黙コミットが行われると、その後、プロセスで例外が発生したときにトランザクションがロールバックされても、リクエストを受け付ける直前の状態には(完全には)戻りません。よって、処理のべき等性が確保されません。

Oracle APEXのページ・プロパティにページの重複送信の許可という属性があります。これはデフォルトでははい - ページの再ポストを許可するになっています。


ブラウザからのリクエストの再送が発生した場合、これまでは2重にデータが挿入されることがありました。そのような場合、いいえ - ページの再ポストを防止するへの変更が対応方法のひとつでした。

セッション・ステート・コミットの追加は、上記の対応が必要なケースを少なくするでしょう。

また、こちらが本命ですが、Oracle Database側でApplication Continuityの機能を有効にすると、Oracle REST Data ServicesとOracle Databaseの間で障害が発生した際に、失敗したリクエストが自動的に再実行されます。処理のべき等性が確保されていないと問題が発生する可能性があります。

プロセスのPL/SQLコードを記述する際に、あまり暗黙コミットを意識していることはない(プロセスで例外が発生しなければ、中間でコミットしても、最後にコミットしても結果は同じ)と思います。

Oracle DatabaseにApplication Continuity(実際にはTransparent Application Continuity)を設定する場合などで、APEX 23.1以前に作成したアプリケーションのセッション・ステート・コミットの設定を即時からリクエストの終わりに変更する場合は、アプリケーションの動作が変わる可能性があるため、気を付ける必要があります。

APEX 23.1のセッション・ステート・コミットのデフォルトがリクエストの終わりになっていますが、Oracle APEXのアプリケーション開発者は、元々リクエストの終わりにコミットされると理解している場合が多く(プロセスで例外が発生しない限り、暗黙コミットを意識する必要ことはありません)、この点についてはそれほど気にする必要はないかもしれません。

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

完

Storecove社のデジタルインボイスAPIを呼び出してみる

 Storecove社が提供しているデジタルインボイスAPIを、Oracle APEXから呼び出してみます。

Storecove社のサイトは以下です。

https://www.storecove.com/

Storecove社は、デジタル庁が推進しているPeppolのネットワークにアクセスするサービスおよびRESTful APIを提供しています。

APIの呼び出しを試すには、サンドボックス環境を取得する必要があります。サンドボックス環境は無料で取得できます。詳しくは上記のStorecove社のサイトを参照してください。

開発者アカウントを作成しログインすると、SettingsタプよりAPIキーの生成と取得ができます。


デジタルインボイスの送受信を行うには、受送信を行うLegal Entityを作成する必要があります。Legal Entityを作成する際にPeppol IDが必要であり、このIDは「法人番号」と「適格請求書発行事業者登録番号」のどちらか、「インボイス制度」における「適格請求書」を送るためには「適格請求書発行事業者登録番号」が必要になります。(Storecove社のFAQ: Peppol IDとは?を参照)

これらの情報を準備できなかったため、以下の作業のみを実施しました。

Storecove API Documentation

Storecove APIを呼び出すにあたって、APIキーの保存の仕方とパッケージAPEX_WEB_SERVICEの使い方を以下より紹介します。

デジタルインボイスの作成(StorecoveのAPIではインボイスはJSONオブジェクトとして作成します)や、送受信のAPI呼び出しは含みません。


Web資格証明の作成



StorecoveのAPIは以下の形式のAuthorizationヘッダーにより、認証を行います。(1.1.3 Make your first API callのcurlのサンプルより)

Authorization: Bearer API_KEY_HERE

この形式の認証は、認証タイプがHTTPヘッダーであるWeb資格証明として作成できます。

ワークスペース・ユーティリティのWeb資格証明を開きます。


作成するWeb資格証明に、以下の値を設定します。

名前は任意です。今回はStorecove API Keyとしました。静的識別子はAPI呼び出しの際に指定する文字列になります。今回はSTORECOVE_API_KEYとしています。

認証タイプとしてHTTPヘッダーを選択します。資格証明名はヘッダー名であるAuthorizationを指定します。資格証明シークレットとして、Bearerで始め、空白で区切り、StorecoveのSettingsのAPI Keysの画面で生成したAPIキーの値を続けて設定します。

Bearer API_KEY_HERE

URLに対して有効に、APIのベースURLである以下を設定します。

https://api.storecove.com/api/v2/


Web資格証明が作成できたので、SQLコマンドよりAPIの呼び出しを行います。


APIの呼び出し



最初のAPIとして、Discover Network Participantが呼び出されています。

https://app.storecove.com/en/docs#_receiving_documents

リクエストの本体であるJSONドキュメントはDiscoverableParticipantです。

以下のPL/SQLコードを実行します。

SQLワークショップのSQLコマンドより実行します。(記事の先頭のスクリーンショット)

応答としてDiscoveredParticipantが返されます。

今回の実行では、以下の応答が返されます。

{"code":"OK","email":false}

以上で、Oracle APEXからStorecove APIを呼び出せることが確認できました。

ドキュメントの送信(3.2.2 Sending a document)、インボイス(5.2.32 Invoice)、送信証明の取得(3.3.5 Sending Evidence)、ドキュメントの受信(3.4.2. Received Document Webhook)といったAPIも何かの機会があれば、試してみたいと思います。

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

完

対話グリッドの行の追加をコードから呼び出す

 対話グリッドの最終セルにてTabを入力すると、新規行が追加されます。


この動作は、対話グリッドの属性の編集に含まれる空の場合に行を追加をオフにすることで、抑止できます。


空の場合に行を追加をオフにすると、対話グリッドの検索結果が0行のときにデータが見つかりませんと表示されるようになります。


オンライン・ヘルプには、こちらの動作が説明されています。

最終セルでのタブ入力で行が追加される動作は、Oracle APEXのJavaScriptリファレンスに記載されています。

autoAddRecord :boolean

 

Specifies if a new record should be automatically added when the model doesn't contain any data. If supported by the derived view a new record may be added when moving beyond the last record in the view while editing. Must only be true if the model and view are editable and the model allows adding records.


https://docs.oracle.com/en/database/oracle/apex/22.2/aexjs/grid.html#autoAddRecord

タブによる行の追加は抑止するが、対話グリッドに何も表示されないときは、新規行を自動的に追加する方法を考えてみました。

対話グリッドに何も表示されないときに、ボタン行の追加を押すと以下のように動作します。


この手順を、動的アクションを使って自動的に実行されるように実装します。

JavaScriptにて対話グリッドを操作する方法は、以下の記事で紹介しています。

JavaScriptのコードを書いて対話グリッドを操作する
http://apexugj.blogspot.com/2022/08/manipulate-ig-sample.html

ボタン行の追加はrow-add-rowというアクションとして実装されています。

https://docs.oracle.com/en/database/oracle/apex/22.2/aexjs/interactiveGrid.html

このアクションは、以下のコードで実行できます。Actionインターフェースのinvokeを呼び出します。

apex.region( "[region static ID]" ).call( "getActions" ).invoke( "[action name]" );

対話グリッドに表示される行が0行の際に、row-add-rowを実行する動的アクションを作成します。

最初に対話グリッドの静的IDを設定します。

今回はempとしました。


対話グリッドに動的アクションを作成します。

識別の名前は空のときに行を追加とします。タイミングのイベントは選択の変更[対話グリッド]です。選択タイプはリージョン、リージョンとして対象となる対話グリッドを指定します。


TRUEアクションとしてJavaScriptコードの実行を選択します。設定のコードとして、以下を記述します。
if (this.data.model.getTotalRecords() == 0) {
    apex.region("emp").call("getActions").invoke("row-add-row");
}
実行の初期化時に実行はオンにします。


以上で実装は完了です。

対話グリッドの内容が0行であれば、自動的に行が追加されます。

対話グリッドの動的アクションを実装するにあたって、Marko Goričkiさんによる以下のページを参照しています。

Oracle APEX Interactive Grid Cheat Sheet

今回作成したAPEXアプリケーションのエクスポートを以下に置きました。
https://github.com/ujnak/apexapps/blob/master/exports/invoke-action-row-add-row.zip

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

完

2023年4月25日火曜日

対話グリッド、対話モード・レポートのセルの背景色を設定する

 以下の画面例のように、セルの背景色を従業員毎に設定したいのだけど、ひとつひとつハイライトを設定するのは大変なので、何か良い方法はないものか?という相談を受けました。


コードを沢山書くとハイライトを使うのと大差なくなりますし、なかなか良い方法がないのですが、結果として以下の実装が採用されました。

上記の例では、サンプル・データセットに含まれる表EMP(英語データ)を使用して、対話グリッドと対話モード・レポートを作成しています。列Manager(または列Mgr)は対話グリッドではタイプに選択リスト、対話モード・レポートではプレーン・テキスト(LOVに基づく)をタイプにすることで、従業員名を表示しています。

上記の実装について紹介します。

従業員毎の色の設定を、ページ・プロパティのJavaScriptのファンクションおよびグローバル変数の宣言に記述します。
var empColors = {
    "KING": "u-color-1-bg",
    "BLAKE": "u-color-2-bg",
    "CLARK": "u-color-3-bg",
    "JONES": "u-color-4-bg",
    "SCOTT": "u-color-5-bg",
    "FORD": "u-color-6-bg",
    "SMITH": "u-color-7-bg",
    "ALLEN": "u-color-8-bg",
    "WARD": "u-color-9-bg",
    "MARTIN": "u-color-10-bg",
    "TURNER": "u-color-11-bg",
    "ADAMS": "u-color-12-bg",
    "JAMES": "u-color-13-bg",
    "MILLER": "u-color-14-bg"
};


対話グリッドに動的アクションを作成します。

識別の名前はColor IGとします。

タイミングのイベントとして選択の変更[対話グリッド]、選択タイプはリージョン、リージョンとして対話グリッドのリージョン(以下のスクリーンショットではEmployees)を選択します。


TRUEアクションとしてJavaScriptコードの実行を選択し、設定のコードに以下を記述します。

triggeringElement(動的アクションが割り当てられた要素、つまりこの対話グリッド)に含まれるTD要素の内容が従業員名であれば、バックグラウンド色をクラス定義に追加しています。

this.triggeringElement.querySelectorAll("td").forEach(
    (e) => {
        e.classList.add(empColors[e.textContent]);
    }
);

実行の初期化時に実行をオンにします。

対話モード・レポートに作成する動的アクションでは、タイミングのイベントにリフレッシュ後を選択します。


TRUEアクションはJavaScriptコードの実行で、設定のコードは同じです。

実行の初期化時に実行はオンにします。


以上の設定を行った後、ページを実行すると記事の先頭の画像のように表示されます。

ほとんどコーディングはしていないため、以下のケースで背景色が消えることが確認できています。

対話グリッドの場合は、値を変更すると背景色が無くなります。レポートの保存を実行すると表示が回復します。


対話モード・レポートの場合は、マウスが乗った行は背景色が無くなります。


表のセルの背景色の設定方法の紹介は以上です。

CSSのhas擬似クラスを使うと表示も早く、上記の現象は回避できます。代わりに、以下のような制限があります。
  • CSSのセレクタとして、TDのテキストは使用できない。
    • td:has(span[TDのテキスト=JONES])みたいに書けない。
  • HTML式を使ってカスタム属性に従業員を割り当てる。
    • CSSのセレクタが使えるのでtd:has(span[data-ename=JONES])みたいに書ける。
    • 選択リストである列Manager/Mgrでは使えない。
    • HTML式を設定すると対話グリッドで編集できなくなる。
  • Firefoxではhasは実装されていない。
どちらで実装するかは、ケース・バイ・ケースでしょう。

今回の記事で使用したアプリケーションのエクスポートを以下に置きました。
https://github.com/ujnak/apexapps/blob/master/exports/table-cell-coloring-ig-and-ir.zip

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

完

動的アクションのイベント有効範囲を確認する

 Oracle APEXの動的アクションにイベント有効範囲という設定があります。このイベント有効範囲として、静的、動的、1回のどれかを選ぶことができます。

簡単なアプリケーションを作成し、このプロパティイベント有効範囲の使い方を確認します。


確認アプリケーションの作成


以下のページを作成し、それぞれイベント有効範囲が異なる動的アクションを作成します。

ボタン、ページ・アイテム、動的コンテンツのリージョンを作成します。


ボタンREFRESHをクリックすると、リージョンTESTをリフレッシュします。ボタンの動作のアクションとして動的アクションで定義を指定します。


動的アクションのタイミングのイベントはクリック、選択タイプはボタン、ボタンはREFRESHになります。


実行するTRUEアクションとしてリフレッシュを選択します。影響を受ける要素の選択タイプにリージョン、リージョンにTESTを指定します。


ページ・アイテムP1_STATUSを作成します。タイプはテキスト・フィールドです。このページ・アイテムは、動的アクションのイベント有効範囲の違いを確認するために使用します。

ページ番号1にイベント有効範囲が静的のケース、ページ番号2に動的のケース、ページ番号3に1回のケースを実装します。そのため、作成するページ・アイテムは、ページ番号に従ってP1_STATUS、P2_STATUS、P3_STATUSとなります。


タイプが動的コンテンツのリージョンを作成します。

ソースのCLOBを返すPL/SQLファンクション本体として、以下を記述します。


クラスdummyclassが設定されたDIV要素に対して動的アクションを作成します。この要素にマウスが乗った時にテキスト・コンテンツをページ・アイテムPn_STATUSにコピーします。

詳細の静的IDとしてtestを設定します。



イベント有効範囲が静的のケース



動的コンテンツに含まれるDIV要素に動的アクションを作成するため、動的アクション・ビューより動的アクションを作成します。

実行のイベント有効範囲として静的を選択します。

タイミングのイベントはマウス・エンター、選択タイプはjQueryセレクタ、jQueryセレクタとして#test .dummyclassを指定します。

リージョンTESTに含まれるDIV要素(classにdummyclassを含む)にマウスが乗ると、TRUEアクションが実行されます。


実行するTRUEアクションとしてJavaScriptコードの実行を選択し、設定のコードとして以下を記述します。

console.log(this.triggeringElement.textContent);
apex.items.P1_STATUS.setValue(this.triggeringElement.textContent);

初期化時に実行はオフにします。


マウスが離れたときに、ページ・アイテムをクリアする動的アクションも作成します。

タイミングのイベントにマウス・リーブを選択します。選択タイプ、jQueryセレクタは、マウス・エンターと同じ設定にします。


TRUEアクションとしてクリアを選択します。影響を受ける要素の選択タイプはアイテム、アイテムとしてP1_STATUSを選択します。

実行の初期化時に実行はオフにします。


リージョンTESTの属性にあるパフォーマンスの遅延ロードは、オフであることが必須です。


イベント有効範囲が静的の場合、動的アクションが設定されたHTML要素が更新されるとイベントが処理されなくなります。ページ全体の再ロードを伴わない更新は、一般にリージョンのリフレッシュとして実装されています。遅延ロードがオンの場合は、ページのロード後にリージョンのリフレッシュを実行するといった動作になるため、イベントが処理されなくなります。

イベント有効範囲が静的の場合は、以下のような動作になります。

ページ・ロード直後はDIV要素にマウスを乗せると動的アクションが呼び出され、ページ・アイテムP1_STATUSに文字列がコピーされます。その後、ボタンRefreshをクリックし、リージョンTESTをリフレッシュすると、動的アクションは(ページを再ロードするまで)呼び出されなくなります。



イベント有効範囲が動的のケース



実行のイベント有効範囲を動的にします。静的コンテナ(jQueryセレクタ)として#testを設定します。#testで指定されるリージョンTESTの内容は、リフレッシュを実行することにより書き換えられます。しかし、リージョンTESTの枠は変わらないため、静的コンテナとして指定できます。

タイミングのイベントはマウス・エンター、選択タイプとしてjQueryセレクタ、jQueryセレクタとして.dummyclassを指定します。


動的アクションMouse Leaveもイベントにマウス・リーブを選択する以外は、マウス・エンターと同じ設定にします。


イベント有効範囲を動的としている場合は、リージョンTESTの遅延ロードをオンにできます。


イベント有効範囲を動的にした場合の動作です。

リージョンのリフレッシュを行った後も動的アクションが呼び出されています。



イベント有効範囲が1回のケース



イベント有効範囲の1回は静的と近いですが、動的アクションが1回呼び出されると、それ以降は(ページが再ロードされるまで)呼び出されません。

実行のイベント有効範囲は1回、タイミングの選択タイプはjQueryセレクタ、jQueryセレクタとして#test .dummyclassを設定します。リージョンTESTの遅延ロードはオフにします。


イベント有効範囲を1回にした場合の動作です。

ページ・ロード直後に1回だけ動的アクションが呼び出されますが、それ以降は呼び出されなくなります。また、呼び出されない状況はリージョンのリフレッシュを行っても変わりません。


動的アクションのイベント有効範囲の説明は以上になります。

今回の確認作業で使用したアプリケーションのエクスポートを以下に置きました。
https://github.com/ujnak/apexapps/blob/master/exports/dynamic-actions-event-scope-test.zip

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

完

2023年4月21日金曜日

Oracle APEX 23.1のプッシュ通知を使ってみる

apex.oracle.comのAPEXが23.1のプレリリース版にアップグレードされました。APEX 23.1にて提供される新機能のひとつである、プッシュ通知を確認してみます。

いち早く動作を確認した方がYouTubeに動画をポストしていたので、その内容を参考にしました。

Push Notifications - Oracle APEX 23.1 New Features
https://www.youtube.com/watch?v=u_re_3cxz3U

apex.oracle.comのワークスペースを使用します。

アプリケーション作成ウィザードを起動し、新規にアプリケーションを作成します。

アプリケーション・アイコンと名前はプッシュ通知の表示に含まれます。後からでも変更できますが、通知に表示されることを意識して設定することをお勧めします。

機能に含まれるプログレッシブWebアプリケーションのインストールとプッシュ通知にチェックを入れます。

以上で、アプリケーションの作成を実行します。


アプリケーションが作成されます。機能としてプッシュ通知を含めたため、ページ番号20020として、プッシュ通知の設定を行うページが作成されています。


アプリケーションを実行します。

まだ何もアプリケーションには実装していません。

ナビゲーション・バーの一番右にユーザー名のメニューがあります。そのメニューから設定を開きます。


画面右よりドロワーが開きます。プッシュ通知をクリックすると設定画面が開きます。


このデバイスでプッシュ通知を有効にするにチェックを入れると、プッシュ通知が有効化されます。画面上に説明されていますが、通知はデバイスごとに有効にする必要があり、また、ブラウザやデバイスで通知を許可する必要があります。


設定に戻ると、プッシュ通知がオンに変わっていることが確認できます。


ホーム・ページにプッシュ通知を送信する画面を作成します。作成した画面は以下のようになります。


通知先を指定するページ・アイテムを作成します。

識別の名前はP1_PUSH_TO、タイプは選択リストとします。ラベルはPush Toとしています。LOVのタイプにSQL問合せを選択し、SQL問合せとして以下を記述します。

select user_name d, user_name r from APEX_WORKSPACE_APEX_USERS where workspace_id = :WORKSPACE_ID

ワークスペースに作成されているユーザーから、通知の宛先を選択します。


通知のタイトルを記述するページ・アイテムを作成します。

識別の名前はP1_TITLE、タイプはテキスト・フィールド、ラベルはTitleとします。


同様に通知の本文を指定するページ・アイテムを作成します。

識別の名前はP1_MESSAGE、タイプはテキスト・フィールド、ラベルはMessageとします。


プッシュ通知を実行するボタンを作成します。

識別のボタン名をNOTIFY、ラベルをNotifyとします。動作のアクションはデフォルトのページの送信です。


プロセス・ビューを開き、プッシュ通知を行うプロセスを作成します。

識別の名前をプッシュ通知とします。タイプにプッシュ通知の送信を選択します。

設定の宛先は&P1_PUSH_TO.、タイトルは&P1_TITLE.、本文は&P1_MESSAGE.とします。リンク・ターゲットに、同じアプリケーションのページ番号1を指定します。

ボタンNotifyをクリックした時に実行されるように、サーバー側の条件のボタン押下時としてNOTIFYを選択します。


アプリケーションを実行し、アプリケーションのインストールを実施します。


アプリケーションのインストールができたら、プッシュ通知の設定を再度確認します。


Push To、Title、Messageを指定して、Notifyをクリックして通知を実行します。


Apple iOSのデバイスに作成したアプリをインストールし、通知を確認してみました。PWAのプッシュ通知はiOS/iPadOS 16.4以降のSafariでサポートされます。


プッシュ通知の実装の確認は以上です。

動かないと思ったら?


通知のサブスクリプションが登録されているかどうか、ビューAPEX_APPL_PUSH_SUBSCRIPTIONSを検索して確認します。

select * from APEX_APPL_PUSH_SUBSCRIPTIONS;


Google Chromeから通知を設定した場合はSUBSCRIPTION_INTERFACEのendpointとしてfcm.googleapis.com、Appleのデバイスではweb.push.apple.comを呼び出すように設定されています。

一見してサブスクリプションが登録されているように見えても、プッシュ通知をONにしたままPWAとしてインストールしたアプリケーションを削除した場合など、無効なサブスクリプションが残っていることがあります。通知を受けるアプリケーションでプッシュ通知のオン・オフを行い、サブスクリプションが正しく登録されていることを確認します。

プッシュ通知は、APEXのインスタンスからfcm.googleapis.com、web.push.apple.comへHTTPのリクエストを発行することによって実施されています。

発行されたHTTPリクエストを確認することで、APEXからプッシュ通知が行われたかどうか確認できます。発行されたHTTPリクエストは、APEX_WEBSERVICE_LOGから確認します。

select id, url, http_method, status_code, to_char(request_date, 'RR/MM/DD HH24:MI:SS') request_date from apex_webservice_log order by request_date desc


apex.oracle.comでは、2分毎に通知を処理しているようです。そのため、プッシュ通知を実行して受信するまでに、最大で2分の遅延が発生します。

プッシュ通知の要求が成功していれば、HTTPのステータス・コードは200番台の値になります。

HTTPリクエストが成功しているにもかかわらず、プッシュ通知が受信できない場合、まずはデバイス側で通知が許可されているか確認します。

Google Chromeの場合は設定のプライバシーとセキュリティのサイトの設定に含まれる、apex.oracle.comの通知の設定を確認します。


iOSの場合は設定アプリの通知より、プッシュ通知(ホーム・ページにインストールしたアプリの名前です)を探します。



プッシュ通知の資格証明


プッシュ通知を組み込んでいるアプリケーションの、共有コンポーネントのプログレッシブWebアプリケーションのプッシュ通知のセクションは以下のようになっています。

アプリケーションにプッシュ通知を組み込む際に、Web資格証明が自動的に生成されてプッシュ通知の資格証明として設定されています。


ワークスペース・ユーティリティのWeb資格証明からも、自動的に作成されたWeb資格証明を確認できます。


このアプリケーションをエクスポートし、再度インポートした際には、この資格証明がWeb資格証明として存在しているかどうか、存在していない場合は資格証明の再生成の実施を検討する必要があります。



APIによる通知


作成したアプリケーションプッシュ通知のコピーを作ります。

タスクのこのアプリケーションをコピーを実行します。


新規アプリケーション名はプッシュ通知 - APIとします。

次へ進みます。


アプリケーションのコピーを実行します。


アプリケーションのコピーが作成されます。

ホーム・ページをページ・デザイナで開き、プロセスプッシュ通知を選択します。

識別のタイプをコードを実行に変更し、ソースのPL/SQLコードとして以下を記述します。p_application_idには、コピー元であるアプリケーションのIDを指定します。
begin
    apex_pwa.send_push_notification(
        p_application_id => [コピー元のアプリケーションID]
        ,p_user_name => :P1_PUSH_TO
        ,p_title => :P1_TITLE
        ,p_body => :P1_MESSAGE
    );
end;

以上で、APIによるプッシュ通知ができるようになりました。プロセス・タイプがプッシュ通知の送信の場合、通知の送信先は同じアプリケーションでしたが、APIの場合は異なるアプリケーションに通知できます。

APIによるプッシュ通知を送信するアプリケーションは、プログレッシブWebアプリケーションが無効でも、通知を送信できます。



Oracle APEX 23.1の新機能、プッシュ通知の紹介は以上になります。

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

完