日日是Oracle APEX: Flows for APEXによる経費精算アプリの作成(3) - レーンとロールを使ったアクセス制御

経費精算のフロー・ダイアグラムを記述する際に、プールを４つのレーンに分割しています。４つのレーンはそれぞれ、従業員、上司、部門長、経理としています。これらをAPEXのアプリケーションのロールに対応させることにより、ワークフローに含まれるステップの可視範囲を限定します。

フロー・ダイアグラムに記述したレーンのIDはそれぞれ、EMPLOYEE(従業員)、MANAGER(上司)、VICE_PRESIDENT(部門長)、ACCOUNTANT(経理)です。

アプリケーション経費精算の共有コンポーネントのアプリケーション・アクセス制御を開き、レーンに対応するロールを作成します。

アプリケーション作成ウィザードによるアプリケーションの作成時に、機能としてアクセス制御を含めているので、コントリビュータ、リーダー、管理者の３つのロールがあらかじめ作成されています。

ロールの追加をクリックします。

従業員のレーンに対応するロールを作成します。名前は従業員、静的識別子はレーンのIDであるEMPLOYEEを指定します。ロールの作成をクリックします。

同様の手順で、名前が上司、静的識別子がMANAGERのロールの作成を行います。

名前が部門長、静的識別子がVICE_PRESIDENTのロールの作成を行います。

名前が経理、静的識別子がACCOUNTANTのロールの作成を行います。

アプリケーション・アクセス制御のロールの一覧より、４つのロールが作成されていることを確認します。

上司のロールが割り当てられているユーザーにのみ、上司によるレビューを待っている経費精算の申請が一覧されるように、レポートのSELECT文を変更します。

	select
	expe.expe_id
	,expe.expe_justification
	,expe.expe_amount
	,expe.expe_status
	,expe.expe_submitted_by
	,expe.expe_submitted_on
	,expe.expe_invoice_dd
	,expe.expe_purpose
	,tibx.link_text
	,tibx.sbfl_prcs_id
	,tibx.sbfl_step_key
	from tuto_expenses expe
	join flow_task_inbox_vw tibx on expe.expe_id = tibx.sbfl_business_ref
	-- APEXのロールとF4Aのレーンの関連付け
	join apex_appl_acl_user_roles aclr on tibx.sbfl_current_lane = aclr.role_static_id
	where tibx.sbfl_dgrm_name = :APP_NAME
	and expe.expe_status = 'submitted' -- 状態はF4Aが管理しているため、この条件は必須ではない
	and tibx.sbfl_current = 'review_expense_mgr'
	-- アサインされているロールを選択する
	and aclr.application_id = :APP_ID
	and aclr.user_name = :APP_USER

view raw expense_manager_with_lane.sql hosted with ❤ by GitHub

ページ・デザイナにてページ番号４の上司のページを開き、レポート１のソースのSQL問合せを以下に変更します。

APEXの標準ビューAPEX_APPL_ACL_USER_ROLESの列ROLE_STATIC_ID（ユーザーに割り当てられたロールの静的識別子）とFlows for APEXが提供するビューFLOW_TASK_INBOX_VWの列SBFL_CURRENT_LANE（現在のタスクが配置されているレーン）を対象としてジョインします。結果として、レーンのIDと同じロールを持つユーザーだけに、レーン内の情報が一覧されます。

上記の変更を行なった後で、アプリケーションを実行し経費精算の申請を行ってみます。従業員の画面から作成をクリックします。

経費精算の申請を作成します。入力データはなんでも良いですが、Expe Amount - 金額については、50より大きい値を入れます。上司による承認後に部門長に申請が回ります。

経費精算の申請が作成されます。ステータスをクリックして、ワークフローの進捗を確認します。

上司のレーンにある申請のレビューで、ワークフローが待機していることが確認できます。

ナビゲーション・メニューより上司をクリックし、上司の画面を表示します。承認待ちの経費精算の申請は表示されません。サインインしたユーザーにロール上司が割り当たっていないためです。

アプリケーションにサインインしたユーザーに、ロール上司を割り当てます。

ナビゲーション・メニューより管理を開き、ユーザーのアクセス制御設定を変更します。

ロール上司を割り当てるユーザーの鉛筆アイコンをクリックします。

上司にチェックを入れ、変更の適用をクリックします。

ロールの追加を確認し、画面を閉じます。

再度、上司の画面を開きます。ロール上司が割り当てられたため、今度はレビュー待ちの経費精算の申請が表示されます。

つまり、フロー・ダイアグラムに配置されているタスクやゲートウェイは、それらが配置されているレーンの情報を持っていますが、そのレーンの情報の扱いはあくまでアプリケーション側で決められます。経費精算のアプリケーションでは、レーンをロールと見做しています。

同様の手順で部門長のレポートを変更します。ページ番号７の部門長のページを開き、ソースのSQL問合せを以下に変更します。

	select
	expe.expe_id
	,expe.expe_justification
	,expe.expe_amount
	,expe.expe_status
	,expe.expe_submitted_by
	,expe.expe_submitted_on
	,expe.expe_invoice_dd
	,expe.expe_purpose
	,tibx.link_text
	,tibx.sbfl_prcs_id
	,tibx.sbfl_step_key
	from tuto_expenses expe
	join flow_task_inbox_vw tibx on expe.expe_id = tibx.sbfl_business_ref
	join apex_appl_acl_user_roles aclr on tibx.sbfl_current_lane = aclr.role_static_id
	where tibx.sbfl_dgrm_name = :APP_NAME
	and expe.expe_status = 'approved_by_mgr' -- 状態はF4Aで管理しているので、必須ではない。
	and tibx.sbfl_current = 'review_expense_vp'
	and aclr.application_id = :APP_ID
	and aclr.user_name = :APP_USER

view raw expense_vp_with_lanes.sql hosted with ❤ by GitHub

レポートのソースとなるSELECT文の変更点は、上司のレポートのソースとまったく同じです。部門長へ回された経費精算の申請は、部門長のロールをもったユーザーにのみ表示されます。

経理のレポートも変更します。ページ番号６の経理のページを開き、対話グリッドのソースのSQL問合せを以下に変更します。

	select
	expe.expe_id
	,expe.expe_purpose
	,expe.expe_amount
	,expe.expe_submitted_by
	,expe.expe_submitted_on
	,expe.expe_invoice_dd
	,expe.expe_account
	,tibx.sbfl_prcs_id
	,tibx.sbfl_id
	,tibx.sbfl_step_key
	from tuto_expenses expe
	join flow_task_inbox_vw tibx on expe.expe_id = tibx.sbfl_business_ref
	join apex_appl_acl_user_roles aclr on tibx.sbfl_current_lane = aclr.role_static_id
	where tibx.sbfl_dgrm_name = :APP_NAME
	and tibx.sbfl_current = 'prepare_payment'
	and aclr.application_id = :APP_ID
	and aclr.user_name = :APP_USER

view raw expense_accountant_with_lanes.sql hosted with ❤ by GitHub

経費精算のアプリケーションが提供するすべての機能にアクセスするには、以下のように上司、部門長、経理のロールが必要です。管理者のロールは管理画面にアクセスするために必要で、このロールがないとユーザーに上司、部門長、経理といったロールを割り当てることができなくなります。

従業員のロールは、今の所は経費精算のアプリケーションでは使用していません。ナビゲーション・メニューの従業員の画面で表示される申請は、そのユーザーが申請したすべての経費精算の申請であり、従業員のレーンに限定されません。

一覧を従業員のレーンに限定すると、タスク申請の修正で再申請待ちとなっている経費精算の申請だけが一覧の対象となります。

フロー・モデルに定義したレーンを、APEXアプリケーションとしてはロールとして扱うことにしても、それぞれのレーンごとに扱いは変わります。今回は、上司、部門長、経理についてはレーンとロールを紐づける形でデータの可視範囲を制限していますが、従業員のロールについては、そのような扱いはしていません。

フロー・ダイアグラムのレーンをAPEXアプリケーションで扱う方法についての説明は以上になります。まとめると、レーンの扱いはコードに依存する、ということになります。

ところで、ユーザーが以下のように従業員のロールだけを持っていたとします（管理者はロールの設定を変更するために必要で、経費精算の処理とは関係ありません）。

実行している経費精算のアプリケーションのナビゲーション・メニューは、以下のように表示されます。

ロールを定義しただけでは、経費精算のアプリケーションで使える機能に制限はかかりません。

ワークフローが持っている情報の制限とは別に、ユーザーに割り当てられたロールに従って、アプリケーションが提供する機能を制限します。

APEXアプリケーションでアクセス制限を実装するには、認可スキームを使用します。

共有コンポーネントの認可スキームを開きます。

すでに作成済みの認可スキームの一覧が表示されます。管理権限、リーダー権限、コントリビューション権限があります。この内、管理権限とコントリビューション権限が、ロールを元に作成されている認可スキームです（タイプがロールまたはグループ内にある）。

ロールとして従業員、上司、部門長、経理を作成しています。これらの作成済みのロールを使った認可スキームを作成します。作成をクリックします。

それほど難しい設定ではないので、認可スキームの作成には最初からを選びます。次へ進みます。

認可スキームの作成の画面が開きます。名前は従業員、スキーム・タイプとしてロールまたはグループ内にあるを選択します。タイプはアプリケーション・ロール、名前は従業員を選択します。

スキームの違反時に表示されるエラー・メッセージの指定には「従業員ではありません。」と入力します。必須項目なので、何某かのメッセージの入力が必要です。

認可スキームの検証として、ページ・ビューごとに1回を選択します。通常はセッションごとに1回で十分だと思います。今回作成しているアプリケーションは機能検証が目的です。ユーザーのロール割り当てを変更するごとにサインインをやり直し、認可スキームに反映させるのは手間なので、ページ・ビューごとに評価するようにしています。

以上を設定し、認可スキームの作成をクリックします。