Flows for APEXによる経費精算アプリの作成(10) - コール・アクティビティ

 Flows for APEX 22.2より、タスクのタイプとしてコール・アクティビティを選択できるようになりました。コール・アクティビティとして別のフロー・モデルを呼び出すことができます。

経費精算のフロー・モデルの最後に呼び出されるスクリプトタスク経費の支払いをコール・アクティビティに変更し、以下のフロー・ダイアグラムを呼び出す実装を行います。

条件によって、銀行振り込みとクレジットカードのどちらかを選んで支払いを実施します。

タスク経費の支払いの処理で、上記のフロー・モデルが呼び出されるようにします。現在はスクリプトタスクとして、表TUTO_EXPENSESの列EXPE_STATUSにpaidを設定しています。

タスク銀行振込の支払いでは、列EXPE_STATUSにpaidの代わりにpaid-by-bk、タスククレジットカードによる支払いでは、列EXPE_STATUSにpaid-by-ccを設定します。

上記のように実装すると、アプリケーションは以下のように動作します。動画の最後のフロー・モニターでの表示で、別のフロー・モデルが呼び出されていることがわかります。

フロー・モデル経費精算のバージョン２がステータスdraftで存在すること、およびAPEXアプリケーションとして経費精算 - 開発中が作成されていることを前提とします。

以下より、コール・アクティビティの実装を行います。

フロー・モデル支払いプロセスの作成

Flows for APEXアプリケーションのフロー管理を実行します。

モデルの作成をクリックします。

カテゴリを社内手続き、名前を支払いプロセスとします。バージョンは０です。

作成をクリックします。

フロー・モデル支払いプロセスのバージョン０が作成されます。ステータスはdraftです。

ダイアグラム変更をクリックし、フロー・ダイアグラムの作成を始めます。

開始イベント、終了イベント、排他ゲートウェイ、タスクをフロー・ダイアグラムに配置します。以下のように名前を付けます。

開始イベント：支払いプロセスの開始

排他ゲートウェイ（分岐）：支払い方法の選択

タスク（上）：銀行振込による支払い

タスク（下）：クレジットカードによる支払い

排他ゲートウェイ（合流）：名前なし

終了イベント：支払いプロセスの完了

それぞれをシーケンスフローで接続します。

フロー・ダイアグラムの背景のどこかをクリックし、フロー・ダイアグラム自体を選択します。

実行のコール可能をはいに切り替えます。この設定変更により、このフロー・モデルが別のフロー・モデルから呼び出し可能になります。入出力変数を設定するタブが現れます。

入出力変数のタブを開きます。

変数内（入力変数がより適切な翻訳です）のプラス（＋）サインをクリックし、呼び出し元のフロー・モデルから伝搬させるプロセス変数を設定します。

変数詳細の名前としてPAYMENT_METHOD、データ型はVarchar2、説明として支払い方法を入力します。

出力変数は呼び出し元に値を返すプロセス変数の設定です。今回は使用しません。

ゲートウェイ支払い方法の選択とタスク銀行振込による支払いを繋ぐシーケンスフローを選択します。

名前は銀行振込とします。このシーケンスフローが選択される条件として、条件タイプを式、条件として以下を指定します。

:F4A$PAYMENT_METHOD = 'BANK_TRANSFER'

呼び出し元によって、プロセス変数PAYMENT_METHODに値が設定されていることを前提としています。

ゲートウェイ支払い方法の選択とタスククレジットカードによる支払いを繋ぐシーケンスフローを選択します。

名前はクレジットカードとし、条件として以下を設定します。

:F4A$PAYMENT_METHOD = 'CREDIT_CARD'

タスク銀行振込による支払いを選択し、タイプをスクリプトタスクに変更します。PL/SQLコードとして以下を記述します。

銀行振込のタスクが実行されたことを確認できるように、update文でexpe_statusにpaidを設定している部分をpaid-by-bkに変更します。

	declare
	l_business_ref flow_process_variables.prov_var_vc2%type;
	l_prcs_id flow_processes.prcs_id%type;
	begin
	-- retrieve process id
	l_prcs_id:= flow_plsql_runner_pkg.get_current_prcs_id;
	-- retrieve business ref
	l_business_ref:= flow_process_vars.get_business_ref(l_prcs_id);
	-- set expense status
	update tuto_expenses expe set expe.expe_status = 'paid'
	where expe.expe_id = to_number(l_business_ref);
	end;

view raw expense_claims_make_payment.sql hosted with ❤ by GitHub

タスククレジットカードによる支払いを選択し、同様の変更を適用します。こちらはexpe_statusにpaidを設定している部分をpaid-by-ccに変更します。

以上でフロー・モデル支払いプロセスは完成です。

フロー・モデル経費精算の変更

フロー・モデル経費精算を開き、フロー・ダイアグラムの変更を行います。

タスク経費の支払いを選択し、タイプをコール・アクティビティに変更します。

一般のコール済ダイアグラム（呼び出すダイアグラムのこと）として、先ほど作成した支払いプロセスを選択します。バージョニングは最新バージョンのまま変更しません。

入出力マッピングのタブを開きます。定義済変数のロードをクリックし、呼び出すフロー・ダイアグラムで定義した入出力変数の定義を反映させます。

変数内（入力変数）としてPAYMENT_METHODがロードされます。

変数内（入力変数）のPAYMENT_METHODを選択し、変数式の式タイプは静的、式としてBANK_TRANSFERを入力します。

プロセス変数PAYMENT_METHODにBANK_TRANSFERを設定した上で、フロー・モデル支払い方法が呼ばれるようになります。静的な設定なので必ず銀行振り込みのパスが選択されますが、コール・アクティビティの動作は確認できます。

フロー・モデル経費申請の変更は以上で完了です。

フロー・ビューワーの変更

コール・アクティビティとして呼び出されたフロー・ダイアグラムも表示されるよう、フロー・ビューワーの設定を変更します。

ページ・デザイナにてフロー・ビューワーが実装されているページ（ページ番号９）を開きます。

フロー・ビューワーのプラグインのリージョンを選択し、ソースのWHERE句を確認します。呼び出し元のフロー・ダイアグラムとコール・アクティビティとして呼び出されたフロー・ダイアグラムは異なるため、フロー・ダイアグラムの検索条件があれば削除し、プロセスIDのみを検索条件とします。

prcs_id = :P9_PRCS_ID

属性タブを開き、設定のEnable Call ActivitiesをONに変更します。

Calling Diagram Identifierなど新たなプロパティが追加されますが、デフォルトからの変更は不要です。

以上でAPEXアプリケーションの変更も完了です。

アプリケーションを実行すると、先頭のGIF動画のように動作します。

今回作成したフロー・モデルのエクスポートを以下に置きました。

https://github.com/ujnak/apexapps/blob/master/exports/20221223-0254_%E6%94%AF%E6%89%95%E3%81%84%E3%83%95%E3%82%9A%E3%83%AD%E3%82%BB%E3%82%B9_%E7%A4%BE%E5%86%85%E6%89%8B%E7%B6%9A%E3%81%8D_draft_0_20221223-0225.bpmn

https://github.com/ujnak/apexapps/blob/master/exports/20221223-0254_%E7%B5%8C%E8%B2%BB%E7%B2%BE%E7%AE%97_%E7%A4%BE%E5%86%85%E6%89%8B%E7%B6%9A%E3%81%8D_draft_2_20221223-0242.bpmn

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

https://github.com/ujnak/apexapps/blob/master/exports/expenseclaim-v3.zip

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

完

Flows for APEXによる経費精算アプリの作成(9) - 承認コンポーネント

 Flows for APEX 22.2よりユーザータスクのタイプとして、APEXページに加えてAPEXの承認 - APEX 22.1から追加された承認コンポーネント - が使えるようになりました。

以前の記事で作成している経費精算のフロー・モデルとAPEXアプリケーションを改変して、承認コンポーネントとの連携を実装してみます。

以下の記事で作成しているステータスがdraftの経費精算のフロー・モデルのバージョン２、と経費精算 - 開発中のAPEXアプリケーションがあるところから始めます。

Flows for APEXによる経費精算アプリの作成(6) - アプリケーションの更新

部門長による申請のレビューはAPEXのフォームを使って実装していましたが、その部分を承認コンポーネントとして提供されている統合タスク・リストを使うように変更します。

承認コンポーネント用のプラグインの作成

Flows for APEX自体はOracle APEX 20.1以降での動作をサポートしています。承認コンポーネントがAPEXに追加されたのは22.1からなので、Flows for APEXの本体には承認コンポーネントとの連携は含まれていません。

承認コンポーネントをFlows for APEXに連携させるプラグインを、GitHubより以下より入手します。

https://github.com/flowsforapex/apex-flowsforapex/blob/development/src/plugins/return-apex-approval-result/process_type_plugin_com_flows4apex_return_to_flows_process.sql

手元の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ページタブが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を設定しています。

部門長が経費申請を承認したときに経由するシーケンスフローを選択し、条件の式を以下に変更します。

:F4A$PAYMENT_REVIEW = 'APPROVED'

プロセス変数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のアプリケーション作成の参考になれば幸いです。

続く

Flows for APEXによる休暇申請フローの作成(5) - 進捗確認画面の組み込み

 Flows for APEXが提供しているプラグイン、Flows for APEX - Viewerを組み込んでみます。ワークフローの進捗を確認することができます。

アプリケーションに組み込まれたビューワーは、以下のように動作します。

進捗確認画面の組み込み

進捗を表示するページを作成します。ページの作成を実行します。

空白ページを選択します。

名前をFlow Status、ページ・モードとしてモーダル・ダイアログを選択します。ページ・モードとしてモーダル・ダイアログを選択しているため、ナビゲーションのブレッドクラムの使用、ナビゲーションの使用ともにOFFになります。

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

ページが作成されたら、Content Body以下にリージョンの作成を行います。

識別のタイトルをFlows Statusとし、タイプとしてFlows for APEX - Viewerを選択します。ソースの表名としてFLOW_INSTANCE_DETAILS_VWを設定し（ビューとして選択する）、WHERE句にprcs_id = :PROCESS_IDを指定します。

続いてリージョンの属性を開き、ビューワーに対する設定を行います。

設定のDiagram XMLとしてDGRM_CONTENTを選択します。Add HighlightingをONに変更します。Add HighlightingをONに変更した際に設定される値は、そのまま使用します。

以上で進捗を表示する画面が作成されました。変更を保存します。

対話モード・レポートから、このページを呼び出せるように変更するため、対話モード・レポートのページをページ・デザイナで開きます。

列SBFL_PRCS_IDを選択し、タイプをリンクに変更します。

リンクのターゲットを設定します。

ページにはFlows Statusとして作成したページのページ番号を選択し、アイテムの設定として名前にPROCESS_ID、値に#SBFL_PRCS_ID#を指定します。OKをクリックします。

以上で進捗を表示できるようになりました。アプリケーションを実行すると、記事の最初にあるGIF動画のように動作します。

以上でFlows for APEXを組み込んだ休暇申請のアプリケーションは完成です。

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

https://github.com/ujnak/apexapps/blob/master/exports/holidayreq.zip

休暇申請のフロー・モデルのエクスポートは以下に置きました。

https://github.com/ujnak/apexapps/blob/master/exports/20230815-0811_%E4%BC%91%E6%9A%87%E7%94%B3%E8%AB%8B.bpmn

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

完

Flows for APEXによる休暇申請フローの作成(4) - ワークフローの組み込み

 作成したAPEXアプリケーションにワークフローの処理を組み込みます。

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

アプリケーションへのワークフローの組み込み

アプリケーション・アイテムとしてPROCESS_ID、SUBFLOW_ID、STEP_KEYを作成します。共有コンポーネントのアプリケーション・アイテムを開きます。

登録済みのアプリケーション・アイテムの一覧画面より、作成を実行します。

名前をPROCESS_IDとし、セッション・ステート保護をチェックサムが必要 - セッション・レベルとします。アプリケーション・アイテムの作成を実行します。

続けてSUBFLOW_IDを作成します。

最後にSTEP_KEYを作成します。

アプリケーション・アイテムとしてPROCESS_ID、SUBFLOW_ID、STEP_KEYが作成されています。

Flows for APEXを使うアプリケーションに必要なプラグインをコピーします。

共有コンポーネントのプラグインを開きます。

プラグインの一覧画面より、作成を実行します。

プラグインの作成として、既存のプラグインのコピーを選択します。次へ進みます。

アプリケーションからコピーとして、NNN Flows for APEX (NNNはアプリケーションID)を選択します。ユーザー・インターフェースに含まれないプラグインなので、テーマは- テーマなし-のまま変更しません。

次へ進みます。

タイプがリージョンのプラグインFlows for APEX - Modelerだけは不要なので、コピーしますか。をいいえにします。それ以外はコピーしますか。をコピーおよびサブスクライブから変更せず、アプリケーション休暇申請にコピーします。

プラグインのコピーをクリックします。

プラグインがコピーされ、アプリケーションで利用できるようになります。

APEXアプリケーションには表HAP_REQUESTSを対象とした、対話モード・レポートとフォームのページが作成されています。こちらにFlows for APEXで定義したフローを、ワークフローとして組み込みます。

対話モード・レポートにワークフローの処理経過を表示するよう、ソースを変更します。

ページ・デザイナにてページ番号1の対話モード・レポートのページRequestsを開きます。

リージョンRequestsのソースのタイプをSQL問合せに変更し、SQL問合せとして以下のSELECT文を記述します。

select 
    h.id
    , h.emp_name
    , h.start_date
    , h.end_date
    , tibx.link_text         -- ユーザータスクへのリンク (ページ2)
    , tibx.sbfl_prcs_id      -- フロー・ステータスの表示 (ページ3)
    , tibx.sbfl_process_name -- リンク名
from hap_requests h          -- アプリケーションとして準備した表
join flow_task_inbox_vw tibx -- Flows by APEXが提供しているビュー
    on h.id = tibx.sbfl_business_ref
where tibx.sbfl_dgrm_name = '休暇申請' 
--    and tibx.sbfl_dgrm_version = 0

Flows for APEXが提供するビューFLOW_TASK_INBOX_VWと表HAP_REQUESTSを、表HAP_REQUESTSの主キーである列IDとフローのビジネス・リファレンスである列SBFL_BUSINESS_REFでジョインしています。

ページの保存と実行を行います。アプリケーションのサインイン画面が表示されます。

ワークスペースに登録されているユーザー（通常は開発者）にてサインインします。

作成をクリックします。休暇申請の作成にあたります。

このままデータを作成しても、単に表HAP_REQUESTSに行が挿入されるだけです。新規にデータを挿入すると同時に、ワークフローを開始するためのプロセスを作成します。

開発者ツール・バーよりページ２をクリックして、ページの編集を開始します。

ワークフローを開始するプロセスを作成します。

左ペインでプロセス・ビューを開きます。プロセスの節の上でコンテキスト・メニューを表示させプロセスの作成を実行します。

作成したプロセスはフォームの処理を行なうプロセス・フォームRequestの下、ダイアログを閉じるの上に配置します。

識別の名前はワークフローの開始とします。タイプとしてFlows for APEXが提供しているプロセス・プラグインであるFlows for APEX - Manage Flow Instanceを選択します。設定のActionはCreate and Start、Flow Instance Nameは休暇申請 - &P2_EMP_NAME!RAW. - &P2_START_DATE!RAW.とします。これが開始したワークフローのインスタンス名となるため、一意で認識できる文字列にします。

Select Flow usingとしてStatic Text、Static Textに休暇申請、Flow (Diagram) selection based onとしてNameを選択することにより、開始するワークフローが休暇申請であることを指定します。バージョンはデフォルトの０が選択されます。

Select Flow usingとしてStatic Text以外に、APEX item、SQL Query、Component Settingを選ぶことができます。複数のページで同じフローを操作する場合や動的にフローを切り替える場合などはStatic Text以外を選択すると良いでしょう。Flow (Diagram) selection based onとしてName & Versionを選択すると、フロー・モデルに複数のバージョンがある場合に、特定のバージョンのワークフローを開始できます。

Set Business Referenceとして、表HAP_REQUESTSの主キーとなるページ・アイテムP2_IDを指定します。ビューFLOW_TASK_INBOX_VWのSBFL_BUSINESS_REFとして表HAP_REQUESTSのIDが参照できるようになるため、この２つの列を使ってユーザーの表（今回はHAP_REQUESTS）とFlows for APEXのワークフローのインスタンスの状態を保持しているビュー（FLOW_TASK_INBOX_VW）をジョインできます。

Return Instance IDは無指定（ユーザー表の主キーをワークフローのインスタンスに保持させる - SBFL_BUSINESS_REFとして参照させるのではなく、ワークフローを一意に認識するインスタンスIDをユーザー表側に持たせる場合に使用）、Set Process Variables?はNo Process Variablesを選択します。

Process Variable（プロセス変数）はFlows for APEXによって提供される機能のひとつで、ワークフローのインスタンスに各種の値を紐づけるために使用します。Oracle APEXのアプリケーション・アイテムおよびページ・アイテムの値はAPEXのセッションに紐付き、その有効期限はセッションの終了までになります。ワークフローのインスタンスはAPEXのセッションの有効期間とは独立して、ワークフロー（のインスタンス）が終了するまで有効である必要があります。そのため、このワークフローのインスタンスに紐づけて値を維持する方法が提供されています。

表HAP_REQUESTSに新規に行が挿入される場合にのみ、ワークフローのインスタンスが作成されるようにサーバー側の条件として、ボタン押下時にCREATEを設定します。

変更を保存し、アプリケーションを実行します。

休暇申請を作成します。Is Approvedには値を入れません。ワークフローの開始時にはIs Approvedのページ・アイテムを非表示にするとよいでしょう。

Emp Name、Start Date、End Dateに適当に値を入れ、作成をクリックします。

列Link Textが表示されていない場合は、アクション・メニューから列を実行し、Link Textをレポートに表示に追加します。

休暇申請の行が表HAP_REQUESTSに挿入されると同時に、ワークフローも開始します。Link Textとして、フロー休暇申請のダイアグラムに記述したユーザータスク休暇申請の承認のAPEXページの設定値を元に生成されたリンクが表示されています。

このリンクをクリックしてページの実行ができるように、対話モード・レポートの列の定義を変更します。

ページ・デザイナにてページ番号1の対話モード・レポートのページを開きます。

列LINK_TEXTを選択し、タイプをリンクに変更します。その後に、リンクのターゲットをクリックします。

ターゲットはタイプがURL、URLとして#LINK_TEXT#を指定します。OKをクリックします。

今回は学習のためにアプリケーションを作成しているため、リンク・テキストは#LINK_TEXT#のままにします。以下のようにアイコンを設定するのもよいでしょう。

<span class="fa fa-edit" aria-hidden="true"></span>

列Link Textに表示されているリンクは、ページrequestを開くURLになっています。これは、フロー休暇申請のモデルに含まれるユーザータスク休暇申請の承認のタスク・タイプとしてAPEXページを選択し、ページIDにrequestが設定されているためです。

Link Textをクリックして、休暇申請の承認または却下を行なう画面を開きます。

Is ApprovedにYまたはNを入力し変更の適用をクリックすることにより、休暇申請の承認もしくは却下を行いますが、今はまだワークフローと連携できていません。

開発者ツール・バーよりページ・デザイナを開き、新たにプロセスを作成します。作成したプロセスでは、ページ・アイテムP2_IS_APPROVEDの値をプロセス変数IS_APPROVEDに設定します。

識別の名前はIS_APPROVEDの設定とします。タイプとしてFlows for APEXが提供しているプロセス・プラグインFlows for APEX - Manage Flows Instance Variablesを選択します。

設定のActionはSet、Flow Instance infoはIn Page Items、Process ID ItemはPROCESS_ID、Subflow ID ItemはSUBFLOW_IDです。Manage Variable(s) usingにAPEX item(s)を選択し、Process Variable(s) Name(s)としてIS_APPROVED、APEX item(s)としてP2_IS_APPROVEDを指定します。

ワークフローの承認処理の際に実行されるよう、サーバー側の条件のボタン押下時としてSAVEを選択します。

もうひとつプロセスを作成します。作成したプロセスはIS_APPROVEDの設定の下、ダイアログを閉じるの上に配置します。

ユーザータスク休暇申請の承認の完了をワークフローに伝えます。

識別の名前を休暇申請の承認完了とします。タイプとしてFlows for APEX - Manage Flow Instance Stepを選択します。設定のActionとしてComplete Step、Flow Instance InfoはIn Page items、Process ID ItemにPROCESS_ID、Subflow ID itemにSUBFLOW_ID、Step KeyにSTEP_KEYを指定します。

サーバー側の条件のボタン押下時としてSAVEを選択します。

ワークフローでの承認と却下の処理が追加されたので、ページを実行して確認します。

Is ApprovedにYを入力し、変更の適用をクリックします。

ワークフローが終了したため、対話モード・レポートから行が消えました。

このままだと処理結果が分からないため、休暇申請の一覧を表示する対話モード・レポートを追加します。

すでにある対話モード・レポートの下に新たにリージョンを作成します。

識別のタイトルを休暇申請一覧とし、タイプとして対話モード・レポートを選択します。ソースの位置はローカル・データベース、タイプはSQL問合せを選択します。

SQL問合せとして以下のSELECT文を記述します。

select 
    id
    ,emp_name
    ,start_date
    ,end_date
    ,case
    when fi.prcs_status = 'completed' and is_approved = 'Y' then
        '承認'
    when fi.prcs_status = 'completed' then
        '却下'
    else
        '処理中'
    end is_approved
    ,fi.prcs_status
from hap_requests h join flow_instances_vw fi on h.id = fi.prcs_business_ref
where fi.dgrm_name = '休暇申請'
-- and fi.dgrm_version = 0

休暇申請に変更があったときに、今回作成した対話モード・レポートも再表示されるように動的アクションを追加します。

左ペインで動的アクション・ビューを開きます。すでにあるリフレッシュのアクションを重複させ、リージョンをRequestsから、休暇申請一覧へ変更します。

識別の名前は休暇申請一覧のリフレッシュとします。

コピー元のアクションの名前はRequetsのリフレッシュとします。

ワークフローとの連携の実装は以上で完了です。

ワークフローの終了後も参照されるデータはワークフロー側で持っている値に依存しないようにします。今回の例では休暇申請自体 - 表HAP_REQUESTSの行 - や承認や却下のデータ - 列IS_APPROVEDの値です。これらの値はユーザーが作成した表に保存します。

一般にワークフローを構成する表に含まれるデータは一方的に増加し、そのままにしておくとパフォーマンスが悪化します。そのため、定期的なパージ（行の削除）は必須です。ワークフローを組み込んで作成するアプリケーションは、ワークフローのインスタンスの開始から終了までの期間に限ってFlows for APEXが提供するビューからデータを参照できると理解しておく必要があります。終了しているワークフローのインスタンスに紐づいているデータはつねに削除される可能性があります。

特にワークフローの進捗について監査といった要件がある場合は、中間の状態についてもユーザー表を用意してFlows for APEXより得られる情報とは別に記録しておく必要があります。

続く