Flows for APEX 22.2よりユーザータスクのタイプとして、APEXページに加えてAPEXの承認 - APEX 22.1から追加された承認コンポーネント - が使えるようになりました。
以前の記事で作成している経費精算のフロー・モデルとAPEXアプリケーションを改変して、承認コンポーネントとの連携を実装してみます。
以下の記事で作成しているステータスがdraftの経費精算のフロー・モデルのバージョン2、と経費精算 - 開発中のAPEXアプリケーションがあるところから始めます。
Flows for APEXによる経費精算アプリの作成(6) - アプリケーションの更新部門長による申請のレビューはAPEXのフォームを使って実装していましたが、その部分を承認コンポーネントとして提供されている統合タスク・リストを使うように変更します。
承認コンポーネント用のプラグインの作成
Flows for APEX自体はOracle APEX 20.1以降での動作をサポートしています。承認コンポーネントがAPEXに追加されたのは22.1からなので、Flows for APEXの本体には承認コンポーネントとの連携は含まれていません。
承認コンポーネントをFlows for APEXに連携させるプラグインを、GitHubより以下より入手します。
手元のPCにprocess_type_plugin_com_flows4apex_return_to_flows_process.sqlというSQLファイルとして作成しておきます。
このSQLファイルをプラグインとしてインポートします。
共有コンポーネントのプラグインを開きます。
インポートをクリックします。
インポートするファイルとしてGitHubからダウンロードしたプラグインのSQLファイルを選択します。ファイル・タイプがプラグインになっていることを確認します。
次へ進みます。
名前がFlows for APEX - Return to Flows for APEXというプラグインがインストールされます。
プラグインのインストールをクリックします。
プラグインFlows for APEX - Return for Flows for APEXのインストールが完了しました。
タスク定義の作成として、以下の値を設定します。
名前:部門長による申請のレビュー
件名:経費精算申請 &PROCESS_ID. &SUBFLOW_ID. &STEP_KEY.
静的ID:REVIEW_BY_VP
優先度:3 - 中
潜在的所有者:APEXDEV
ビジネス管理者:APEXDEV
潜在的所有者として指定するのは、本来はこの申請をレビューする部門長のアカウントです。今回は実装の確認なので、開発者のアカウントを設定しています。
作成をクリックします。
タスク定義が作成されました。
タスク詳細ページを生成します。
タスク詳細ページの番号に(未使用である)10を入力し、タスクの詳細ページの作成をクリックします。
タスク定義の一覧画面に戻るので、再度、タスク定義部門長による申請のレビューを開きます。
タスク詳細ページが作成されていることを確認します。
統合タスク・リストで、タスクの承認を行ったときに実行するアクションを作成します。
アクションの追加をクリックします。
アクションの名前はF4A:申請のレビューとします。タイプにFlows for APEX - Return to Flows for APEX [プラグイン]を選択します。イベント時は完了、結果は承認済を選択します。
Parameter Name containing Process IDはデフォルトでPROCESS_IDとなっています。
作成をクリックします。
以上で、承認コンポーネントのタスク定義の作成は完了です。
統合タスク・リストのページ作成
作成したタスク定義を元に、統合タスク・リストのページを作成します。
ページの作成をクリックします。
統合タスク・リストを選択します。
作成する統合タスク・リストのページ番号は11、名前は申請のレビューとします。タスクの作成者および潜在的所有者が開発者のAPEXDEVと固定されていることより、レポート・コンテキストとして自分で開始、マイ・タスクを指定できません(自分で開始したタスクを自分で承認できない仕組みであるため)。そのため、レポート・コンテキストとして管理タスクを選択します。
ナビゲーションはデフォルトでブレッドクラムの作成、ナビゲーションの作成ともにONになっています。
ページの作成を実行します。
フロー・モデルの更新
部門長にレーンにあるユーザータスク申請のレビューのユーザー・タスク・タイプを、APEXページからAPEXの承認に変更します。
APEXページタブがAPEXの承認タブに変わります。
Application IDとして、このフロー・モデルを呼び出すAPEXアプリケーションのアプリケーションIDを指定します。ユーザー・タスク・タイプがAPEXの承認の場合、空白としてデフォルト値を選択することもアプリケーション別名を指定することもできません。必ず数値を指定します。新規に追加された機能なので、まだ、設定がこなれていないようです。
Task Definition Static IDとしてタスク定義の静的IDを指定します。今回の例ではREVIEW_BY_VPになります。
ビジネス参照は&F4A$BUSINESS_REF.(business_refをクリック)、パラメータとして静的IDがPROCESS_ID、値が&F4A$PROCESS_ID.の組みを登録します。
結果変数はPAYMENT_REVIEWとします。これはプロセス変数で、統合タスク・リスト上でタスクの承認を行った場合APPROVEDが設定されます。
開始者として、開発者のアカウントであるAPEXDEVを設定しています。
プロセス変数PAYMENT_REVIEWの値がAPPROVEDの際に、このパスが選択されます。
以上でフロー・モデルの更新は完了です。
APEXアプリケーションとフロー・モデルの両方で、部門長のユーザータスク申請のレビューに承認コンポーネントが使われるようになりました。変更したアプリケーションを実行すると、記事の先頭のGIF動画にあるように、部門長による承認を統合タスク・リストで行えることが確認できます。
今回作成したAPEXアプリケーションのエクスポートを以下に置きました。
https://github.com/ujnak/apexapps/blob/master/exports/expenseclaim-v2.zip
承認コンポーネントに置き換えたフロー・ダイアグラムのエクスポートです。
https://github.com/ujnak/apexapps/blob/master/exports/20221222-0728_%E7%B5%8C%E8%B2%BB%E7%B2%BE%E7%AE%97_draft_2_20221222-0711.bpmn
Oracle APEXのアプリケーション作成の参考になれば幸いです。