グループ階層とプリンシパルでワークフローを制御する

概要

人事異動や組織改編といったケースに対応したワークフローの運用を行うために、Wagbyが提供するグループ階層とプリンシパルを組み合わせた承認者、決裁者の制御方法を紹介します。ワークフローではスクリプトを用いて承認者や決裁者を動的に決めることができます。

このページのポイントは次の二点です。

• アカウントの所属グループにグループ階層を設定する。
• フロー参加者スクリプトでグループ階層、プリンシパルを条件に承認者、決裁者を動的に決定する。

準備

アカウント

次に示すアカウントを用意しておきます。

グループ階層

営業一課、営業二課、営業部は次のグループ階層とします。グループ階層の作成方法はこちらをお読みください。

年休申請・承認・決裁ルール

今回の例は次のルールとします。

申請者

• すべてのユーザ

承認者

• 申請者の同一グループに所属
• 「年休承認者」プリンシパルを持つ

決裁者

• 申請者より1階層上位のグループに所属
• 「年休決裁者」プリンシパルを持つ

このルールに準じたアカウント設定の例を示します。

フロー参加者にスクリプトを設定する

今回は「順次・順次・順次フロー」をベースに、スクリプトを設定した例を示します。

申請者のスクリプト

全ユーザーを申請可能とする場合は、次のように記述します。

return wman.getLogonUserOrApplicant(modelname, modelpkey, p); 

• 暗黙変数wmanを利用します。wmanは、Wagbyが標準で提供するワークフロー管理クラス(WorkflowManagerクラス)のインスタンスです。
• 暗黙変数 modelname と modelpkey はそれぞれモデルIDと、主キーの値を保持します。
• "すべてのユーザ" を申請者として表現するためにwmanが提供するgetLogonUserOrApplicantメソッドを使います。このメソッドは新規登録の場合、ログオンユーザのuseridを返します。申請済みの場合は申請者のuseridを返します。

承認者のスクリプト

return $applicant.group().findUsers(By.principal("nenkyu_authorizer")).name(); 

• 暗黙変数$applicantを利用します。この$applicantは申請者を表すUserElementクラスのインスタンスです。
• 申請者と同一のグループに所属するユーザで、年休承認者(nenkyu_authorizer)のプリンシパルを持つユーザのuseridを返すという式になっています。
  • $applicant.group()は、申請者の所属グループ(GroupElement)を取得します。
  • findUsers(By.principal("nenkyu_authorizer")).name()で、グループに属するユーザーのうち、プリンシパル“nenkyu_authorizer”を持つユーザーのIDを取得します。

決裁者のスクリプト

return $applicant.group().parent().findUsers(By.principal("nenkyu_finalist")).name(); 

• 申請者の所属グループの一階層上のグループに所属するユーザで年休決裁者(nenkyu_finalist)のプリンシパルを持つユーザの useridを返す式になっています。
  • $applicant.group().parent()は、申請者の所属グループの1階層上のグループ(GroupElement)を取得します。
  • findUsers(By.principal("nenkyu_finalist")).name()で、グループに属するユーザーのうち、プリンシパル“nenkyu_finalist”を持つユーザーのIDを取得します。

このようなスクリプトを利用することで、一つの参加者設定（式）で複数のグループに対する承認ルールを表現できます。

実行

1. 営業一課 amuro による申請

はじめに amuro が年休を申請しました。

2. 営業一課による承認

同一グループに所属する承認者 kinjo でログオンすると、承認ボタンが表示されます。

異なるグループ（営業二課）に所属する承認者 shinjo では、承認ボタンは表示されません。

kinjo が承認しました。次は決裁者になります。kinjo は決裁者スクリプトの条件を満たさないため、承認ボタンは表示されません。

3. 営業部による決裁

申請者の一つ上のグループ階層(営業部)に所属し、決裁者プリンシパルを持つ onaga でログオンすると、承認ボタンが表示されます。

決裁者 onaga による決裁後、ワークフローは完了となります。

スクリプト内で利用できる暗黙変数

ワークフローのスクリプトで利用できる暗黙変数は次の通りです。

ストアモデルの詳細 (*1)

1. 標準では、ストアモデルオブジェクトは参照連動や自動計算の処理を行っていません。これはパフォーマンスを優先しているためです。参照連動項目を解決し、計算式の値を取得する場合は、次のように EntityService を経由してください。

var entityService = p.appctx.getBean("LeaveEntityService");
var leave = entityService.findById(modelpkey);

2. ここで得られるストアモデルは参照では利用できますが、更新では利用できません。[詳細...]

UserElementの詳細

UserElementは複数または単一のユーザーを表現するクラスとなっています。このクラスが提供する API は次のとおりです。

GroupElementの詳細

上の API で説明した group() で取得できるグループは GroupElementとなっています。GroupElementは複数または単一のグループを表現するクラスです。このクラスが提供する API は次のとおりです。

$applicantの使い方

$applicantは申請者スクリプトでは利用できません。承認者および決裁者スクリプトで利用できます。

次の式は、申請者の1階層上位グループ(GroupElement)を取得します。

$applicant.group()

次の式は、申請者の所属グループのグループID(数値の配列)を取得します。

$applicant.group().jgroupid(); 

(例) 申請者がamuroの場合は1000となります。

次の式は、申請者と同じグループに属するユーザー(UserElement)を取得します。

$applicant.group().users();

次の式は、申請者と同じグループに属するユーザーのユーザーIDを取得します。

$applicant.group().users().name();

(例) 申請者がamuroの場合は”amuro|kinjo”となります。

次の式は、申請者と同じグループに属するユーザーのうち、プリンシパル“nenkyu_authorizer”を持つユーザー (UserElement)のユーザーIDを取得します。

$applicant.group().findUsers(By.principal("nenkyu_authorizer")).name();

ワークフローのスクリプトで、By.principal を使ってプリンシパルで絞り込みを行うことができます。

By.principal("プリンシパル名")
By.principal("プリンシパル名","プリンシパル名",...)

複数のプリンシパル名をコンマ区切りで指定することもできます。

(例) 申請者がamuroの場合は”yamashiro”となります。

次の式は、申請者の所属グループの1階層上のグループ(GroupElement)のグループIDを取得します。

$applicant.group().parent().jgroupid();

(例) 申請者がamuroの場合は”2000”(営業部)となります。

次の式は、申請者の所属グループの1階層上のグループに属するユーザー(UserElement)のユーザーIDを取得します。

$applicant.group().parent().users().name();

(例) 申請者がamuroの場合は “uehara|onaga” となります。

次の式は、申請者の所属グループの1階層上のグループおよび、その下位階層グループ(GroupElement)のグループIDを取得します。

$applicant.group().parent().descendants().jgroupid();

(例) 申請者がamuroの場合は1000,1001,2000(営業1課、営業2課、営業部)となります。

次の式は、申請者の所属グループの1階層上のグループおよび、その下位階層グループに属するユーザー(UserElement)を取得します。

$applicant.group().parent().descendants().users().name();

(例) 申請者がamuroの場合は “uehara|onaga|yamashiro|kinjo|amuro|shinjo|miyagi|taira” となります。

次の式は、申請者の所属グループの1階層上のグループおよび、その下位階層グループに属するユーザー(UserElement)のうち、プリンシパル"nenkyu_finalist"を持つユーザーを取得します。

$applicant.group().parent().descendants().findUsers(By.principal("nenkyu_finalist")).name(); 

(例) 申請者がamuroの場合は”taira”となります。

次の式は、申請者の所属グループの1階層上のその下位階層グループ(GroupElement)のグループIDを取得します。

$applicant.group().parent().children().jgroupid();

(例) 申請者がamuroの場合は1000,1001 ("営業1課"、"営業2課")となります。"営業部" は含まれません。

$allUsersの使い方

次の式は、全ユーザーのうちのうち、プリンシパル"nenkyu_finalist"を持つユーザIDを取得します。

$allUsers.find(By.principal("nenkyu_finalist"));

次の式は、全ユーザーのうちのうち、グループID1000に所属し、かつプリンシパル"nenkyu_finalist"を持つユーザIDを取得します。

$allUsers.find(By.jgroupId(1000), By.principal("nenkyu_finalist"));

By.principal と同様に、グループIDで絞り込むための By.jgroupid も用意されています。

By.jgroupid(グループID)
By.jgroupid(グループID,グループID,...)

コンマ区切りで複数のグループIDを指定することもできます。

次の式は、全ユーザーのうちのうち、グループIDが1000,1001,1002に所属し、かつプリンシパル"nenkyu_finalist"を持つユーザIDを取得します。

$allUsers.find(By.jgroupId(1000,1001,1002), By.principal("nenkyu_finalist"));

$rootGroupの使い方

$rootGroup は、グループ階層を設定している場合のみ利用できます。

次の式は、全グループを取得します。

$rootGroup.descendants();

次の式は、最上位グループを取得します。図18の例では"管理部"、"第二技術部"、"第一技術部" が該当します。

$rootGroup.children();

仕様・制約

• フロー参加者をスクリプトで設定する場合、スクリプトは必ず return で対象者を返すようにしてください。null (対象者が定まらない) は許容されません。(*1)
• フロー参加者をスクリプトで設定した場合、スクリプトで取得された "次の承認対象者" は、ワークフロー適用モデルの "承認対象者(jfcWorkflowAdmitUser)" 項目に保存されます。このため、申請・承認時にスクリプトで次の承認対象者が確定された後にスクリプトを変更しても、次の承認対象者は変更されません。この仕様から、例えばスクリプトを実行するたびに対象者が変わるような仕組みを実現することはできません。(*2)
• フロー参加者スクリプトのデータベースの型は、各データベースの CLOB に相当する型を用いるようにしています。スクリプトのサイズの最大長は、データベースの CLOB 型の上限値となります。例えば Oracle では NCLOB となります。詳細は、自動生成された jfcparticipant_setting.ddl をご確認ください。
• このスクリプトは、ワークフロー処理中に複数回、実行されることがあります。何回実行されるかはフロー設定により変わるため、複数回実行されても結果が変わらないようにしてください。（具体的には、N回呼び出されることを前提としたり、N回目の呼び出しのときに処理を変える、というような手順を加えないようにしてください。）
• 「フロー参加者による閲覧権限を設定する」と、フロー参加者のスクリプト設定は併用できません。フロー参加者による閲覧権限は使わないようにしてください。

その他の情報

• スクリプトでService/Daoクラス、ヘルパ、SQLを利用する場合は、あわせてこちらをお読みください。