APEX承認コンポーネントの続き-少ないコストでより多くのことを行う (2022/05/31)

https://blogs.oracle.com/apex/post/apex-approvals-component-continued---do-more-with-less

投稿者：Ananya Chatterjee | Consulting Member of Technical Staff

承認管理 - クレーム、委任、解放など。

このブログでは、休暇申請アプリケーションをさらに拡張し、タスクを複数の潜在的所有者に割り当てる方法と、その潜在的所有者がタスクに対して実行可能なアクションを探ります。また、休暇が承認されると、従業員の休暇残高を更新するためのタスクアクションを強化します。

サンプル・テーブルとサンプル・データ

データセットのインストール

1.     SQL Workshop に移動し、[SQL Scripts] をクリック
2.     [作成]をクリック
3.     スクリプト・エディタに以下のコマンドをコピー・アンド・ペーストして、社員休暇テーブルを作成し、サンプル・レコードを追加
4.     [実行]をクリック
5.     [今すぐ実行]をクリック

CREATE TABLE "EMP_LEAVES" 
( "EMP_LEAVE_ID" NUMBER GENERATED BY DEFAULT ON NULL 
AS IDENTITY MINVALUE 1 MAXVALUE 9999999999999999999999999999 
INCREMENT BY 1 START WITH 8000 CACHE 20 
NOORDER NOCYCLE NOKEEP NOT NULL ENABLE, 
"EMP_NO" NUMBER NOT NULL REFERENCES EMP_1 ON DELETE CASCADE, 
"LEAVE_BALANCE" NUMBER, 
CONSTRAINT "EMP_LEAVE_PK" PRIMARY KEY ("EMP_LEAVE_ID"));

insert into EMP_LEAVES(EMP_LEAVE_ID, EMP_NO, LEAVE_BALANCE) values (1, 10, 22);
insert into EMP_LEAVES(EMP_LEAVE_ID, EMP_NO, LEAVE_BALANCE) values (2, 20, 13);
insert into EMP_LEAVES(EMP_LEAVE_ID, EMP_NO, LEAVE_BALANCE) values (3, 30, 25);
insert into EMP_LEAVES(EMP_LEAVE_ID, EMP_NO, LEAVE_BALANCE) values (4, 40, 6);
commit;

注：EMP_1テーブルを作成し、入力する手順は、入門ブログで紹介しました。以下のコマンドを実行する前に、そのテーブルが作成され、入力されていることを確認してください。

既存の Employee テーブル EMP_1 に新しい列 HR_MGR (HR Manager) を追加し、以下に示すように既存の Employee レコードを更新します。

alter table "EMP_1" add "HR_MGR" varchar2(10);
update EMP_1 set HR_MGR = 'SOPHIE'
 where EMPNO in  (10,20);
update EMP_1 set HR_MGR = 'ROBIN'
 where EMPNO in  (30,40);
commit;

注: [ワークスペース管理] の [ユーザーとグループの管理] メニューを使用して、2 人のユーザー SOPHIE と ROBIN を作成することを忘れないでください。

タスク定義の拡張

入門ブログで作成した休暇申請承認アプリケーションで、Shared Components→ Workflows and Automations→ Task Definitions と進み、Leave Request Task Definition を選択します。

次に、開いた［タスク定義の編集］画面で、［休暇申請タスク定義］の［参加者］セクションをさらに更新することができます。

[参加者]セクションの[行の追加]をクリックします。

[参加者タイプ]を[潜在的所有者]、[値タイプ]を[SQLクエリ]に設定します。Value]フィールドに、以下のSQLクエリを追加します。

select hr_mgr from emp_1 where empno=:APEX$TASK_PK

APEX$TASK_PKは、タスクが関連付けられているレコード・システムの主キーの値を保持する置換文字列です。この場合、この休暇申請タスクが提出される従業員の従業員番号が格納されます。注： Approvals Componentで使用可能な置換文字列の完全なリストについては、ドキュメントを確認してください。

[Apply Changes] をクリックして、更新された参加者を保存します。

これは何を意味するのでしょうか。

新しい参加者のエントリを追加すると、各従業員について、休暇の承認者は直属の上司または人事部長のいずれかになることを意味します。この例では、クララが休暇を申請する場合、上司のジェーンまたは人事部長のソフィーのいずれかがタスクを承認することができます。

これで、休暇申請タスクの所有者が複数になる可能性があるシナリオができました。これは、Claim、Release、Delegate など、1 人以上の潜在的所有者を持つタスクに対して実行可能な操作を示すのに役立ちます。

タスクパラメータを追加

タスクパラメータセクションに以下の新しいエントリを追加します。

注: [Task Parameters] に追加したパラメータはすべて、参加者やアクションのソース SQL クエリでバインド変数として使用でき、この例に示すようにタスク定義のサブジェクトに LEAVE_TYPE パラメータへの参照を含む置換文字列として使用することもできます。

アクションの追加

以前のブログで、タスク・イベントにアクションを定義する方法について説明しました。休暇が承認されると、休暇申請者にメールを送信するアクションを定義しました。今度は、休暇申請が承認されたときに休暇残高を調整するアクションを定義します。下図に示すように、「アクションの追加」をクリックします。タスク定義のアクション編集ページが表示されます。

以下のようにEdit Actionページに必要事項を記入して、以下のPL/SQLコードを追加し、[Create]を押してください。

update emp_leaves 
set leave_balance = leave_balance - :NO_OF_DAYS 
where emp_no=:APEX$TASK_PK;

注：NO_OF_DAYSは先にタスクパラメーターとして定義されており、このように定義されたパラメーターはすべてタスクアクションコードのバインド変数として使用することができます。

以上です。休暇申請のタスク定義への変更は完了です。変更を適用して、アプリケーションに戻ってください。

「休暇申請」ページを更新

タスクの定義が更新されたので、従業員が休暇を申請するときに提出する「休暇申請」ページを更新する必要があります。このページを送信すると、先ほど更新したタスク定義に基づいた休暇申請タスクが作成されます。

休暇申請ページを開きます。

ページデザイナーで、新規休暇申請フォームのソースを更新し、クエリ領域に以下を入力します。

select e.empno, 
       e.emp_name, 
       m.emp_name as mgr_name, 
       l.leave_balance 
  from emp_1 e, emp_1 m ,emp_leaves l
 where m.empno(+)=e.mgr
   and e.empno=l.emp_no
   and e.empno=:P3_EMPNO;

以下のページ項目が既に作成されていることがわかります。P3_LEAVE_BALANCEです。タイプをNumber Fieldに更新し、ソースをLEAVE_BALANCE列として設定します。(余分なP3_LEAVE_BALANCE_1項目も作成されています。それを削除しても構いません！)

[処理]タブに移動し、[休暇申請]プロセスをクリックします。

パラメータに「休暇残高」が追加され、プリセット値として「変更してください#」が設定されていることが確認できます。

Parameter typeをItemに更新し、値を以下のように設定します。

[保存]をクリック 

これで休暇申請ページへの変更は完了です。

管理タスクのページ

前回のブログでは、従業員の上司が休暇申請を承認または却下するための「マイ承認」ページと、従業員が休暇申請のステータスを確認するための「マイ申請」ページを作成しました。このために、2つの統一されたタスクリストを作成しました。

今度は、休暇要請タスクに定義されたビジネス管理者であるマット（ビジネス管理者の参加者タイプについては、タスク定義の参加者セクションを確認してください）が、休暇要請タスクで管理アクションを実行できるようにするページを作成することにします。

タスクの管理操作とは何ですか？

タスクのビジネス管理者として、ユーザはこれらの操作を行うことができます。

a) タスクを他の潜在的な所有者に委任する。

b) タスクの臨時の潜在的所有者を追加する。この操作はタスクインスタンスに固有のものであり、タスクインスタンスが基づいている元のタスク定義で定義された参加者を変更しないことに注意してください。

c) タスクの優先順位を更新する。

 

管理タスクページの作成

ページの作成ウィザードをクリックし、コンポーネントセクションから[Unified Task List]を選択します。ページ名を「管理タスク」とし、レポートコンテキストを「管理タスク」として選択します。

注：統一されたタスクリストページは、ページデザイナーでカスタマイズすることができます。しかし、この例では、箱から出されたものを使用します。

 

アプリケーションを実行

App Builder で［Leave Request Approvals］を選択し、［Run Application］をクリックします。 アプリケーションは別のタブで起動されます。

CLARA としてログインし、[Apply For Leave] ページに移動します。

Employee ID、Name Manager、Leave Balance の各フィールドには、あらかじめ入力されています。

下図のように、日数、休暇の種類に値を入力します。その後、[Submit Request]をクリックします。

ログアウトし、Clara のマネージャーである Jane としてログインし直します。[私の承認]ページに移動します。クララの病気休暇の申請が見つかり、タスクの状態が「未割り当て」になっていることに気がつくでしょう。

これは、Jane (Manager) と Sophie (HR Manager) の両方がこのタスクの潜在的な所有者であり、承認または拒否する前にどちらかがタスクを「クレーム」しなければならないからです。それまでは、このタスクは「未割り当て」です。

ログアウトして、Sophieとしてログインし直します。あなたは同様に彼女のために私の承認で同じタスクが表示されます。

注意: SophieまたはJaneは、統一されたタスクリストで上に表示されているボタンを使って、リクエストを承認または拒否することができます。この場合、承認または却下の前に、暗黙のうちにタスクの「請求」が行われます。

Sophieとしてログインしたまま、タスクをクリックします。そのタスクで他のアクションを実行する前に、[クレーム] ボタンをクリックする必要があります。

注：「詳細」セクションには、休暇申請タスク定義で構成されたタスクパラメータの値が表示され、タスク定義で後から追加した休暇バランスパラメータも表示されます。入門ブログで説明したように、タスクの詳細ページは、タスク定義を編集するときに作成される、すぐに使えるページです。このページはカスタマイズ可能で、System of Recordsからより多くのデータを表示したり、関連性がないと判断した場合は生成されたセクションのいくつかを削除したりすることができます。これらのカスタマイズについては、次回のブログでご紹介します。

「請求タスク」をクリックします。タスクの詳細]に[承認]および[却下]ボタンが表示されます。さらに、タスクの詳細セクションのすぐ上に[リリース]および[委任]ボタンが表示されます。

このタスクは Sophie が申請しているので、Jane としてログアウトして再ログインすると、Jane の承認ページでこのタスクは見つからなくなります。

解放と委任のボタンで何ができるかを簡単に説明します。

Release - これはClaimの逆の動作です。タスクは未割り当てに戻り、潜在的な所有者のいずれかが再び請求することができます。Sophieがこのアクション（リリース）をクリックすると、このタスクはJaneのマイ承認ページに再び表示され、状態は「未割り当て」になることがわかります。SophieとJaneのどちらかが、このタスクに権利を主張し、作業することができます。

委任 - Sophieがこのタスクを委任できる所有者候補のリストがポップアップで表示されます。この場合、Jane がもう一人の所有者候補です。そのため、リストには彼女の名前が表示されています。リリースとは異なり、Delegate はタスクを新しいオーナーにのみ割り当てます。そのため、タスクの状態は「割り当て済み」となり、委任された新所有者だけがそのタスクを処理することができます。

「委任する」をクリックします。タスクが委譲されると、Sophie の「私の承認」ページから消えます。

こうすることで、ジェーンとソフィーはお互いに仕事を任せ続けることができるのです。(その間、クララは自分の休暇が承認されるのを待っているのですから、無限に望めるわけではありません!)   

業務管理者が介在

一旦ログアウトし、Mattとしてログインし直し、「管理タスク」ページに移動します。

ビジネス管理者の Matt は、このタスクの優先順位を「緊急」に更新し、Jane または Sophie がこのタスクの作業を迅速化できるようにすることができます。

タスクをクリックして、タスクの詳細ページを開きます。「コメント」セクションにコメントを追加し、下図のように「優先度」ボタンをクリックします。

[優先順位の設定]をクリックし、[緊急]を新しい優先順位とします。

Jane としてログインし、[My Approvals] に移動します。休暇申請タスクが「緊急」と表示される。

このタスクは緊急なので、[承認] ボタンをクリックして、[自分の承認] ページから承認してください。Jane は、タスクの詳細ページを開いて、そこからタスクを承認することもできます。

クララとしてログインし直し、[マイリクエスト] ページに移動します。彼女のタスクは現在、完了状態になっています。

Clara が次に休暇を申請したとき、休暇残高には、以前に申請した 8 日間が差し引かれて表示されています。そのため、彼女の休暇残高は13 -8 = 5日と表示されます。これは、タスク定義で設定した新しいタスクアクション「残高の更新」によるものです。

前回のブログで紹介したように、クララにも休暇が承認された旨のメールが届きます。

Approvals Component Blogシリーズ第2弾はこれで終了です。

まとめ

学習したこと

1) 複数の所有者がいるタスクを承認、委任、解放する方法

2) 統一タスクリストを使用して、タスクのビジネス管理者用の管理タスクページを作成する方法

3) タスクの完了を促進するために優先順位を更新する方法

4) タスクが完了したときに、記録システムを更新するために、追加のタスクアクションを設定する方法

次回は？

次回のブログでは、このアプリケーションをさらに発展させ、次のことを学びます。

1) 複数レベル(階層)承認のユースケースを実証するために、休暇アプリケーションを使用します。

2) タスクの開始者に、承認が不要になったタスクをキャンセルするオプションを提供する方法。

ご期待ください