2.1.2.1.1. ワークフロー定義例¶

ワークフローインスタンスを生成し、ワークフローを開始・進行・終了させる。

確認や承認の タスク の タスク担当ユーザ/タスク担当グループ を指定してワークフローを進行させる。

確認などを行う タスク で、確認結果がNGだった場合に申請者に差戻しを行う。

このとき、差戻し後の タスク の タスク担当ユーザ/タスク担当グループ は、 その タスク を直前に実行したユーザとなる。

確認結果がOKかどうかで進行先となるフローノードを切り替える XORゲートウェイ を利用し、 OKの場合には承認タスクへ、NGの場合は前の申請タスクにワークフローを進行させる。

一般に、既に一度実行されている タスク へワークフローを進行させる必要がある場合には、 XORゲートウェイ を利用することで要件を実現できる。 その場合の タスク担当ユーザ/タスク担当グループ には、その タスク に最後に割り当てられていたユーザが設定される。

差し戻された申請を修正し、再申請を行う。

上記の単純な差戻しフローとは異なり、初回の申請と再申請を明確に区別する。

差戻しと同様に、確認結果がOKかどうかで進行先となるフローノードを切り替える XORゲートウェイ を利用する。 ただし、NGの場合には、申請タスクではなく、再申請タスクにワークフローを進行させる。

なお、申請者は申請タスクを実施後に必ずしも再申請を行うわけではないため、 申請タスクと再申請タスクを結ぶシーケンスフローは作成しないこと。

申請者が、申請の取り消しを行う。

申請が取り消された場合には、ワークフローを完了させる。

申請の取り消しを行うことができる作業種別に対応する タスク に、 境界イベント を関連付ける。

それらの 境界イベント からは、 停止イベント に ワークフローを進行させるようにしておく。

申請の取り消しが行われた時には、上記の 境界イベント をトリガーし、ワークフローを完了する。

確認者や承認者が、申請を却下する。

申請が却下された場合には、ワークフローを完了させる。

取消 と同様に、申請の引戻しを行うことができる作業種別に対応する タスク に、 境界イベント を関連付ける。

それらの 境界イベント からは、引戻し後の タスク に ワークフローを進行させるようにしておく。

申請の引戻しが行われた時には、上記の 境界イベント を発生させし、 ワークフローを引戻し後の タスク に進行させる。

後閲の可能性があるフローに入る際には、必ずユーザを選択してからワークフローを進行させるものとし、 選択されたユーザが代理ユーザであるかどうかで、ワークフローを分岐する。

なお、要件上、確認後にユーザ選択を強制することができない場合には、フロー進行条件をアプリケーションで実装し、 直前の タスク の実行ユーザが代理ユーザであったかどうかをゲートウェイで判定することで、 下記例の確認後の「承認者選択タスク」は不要となり、確認後にユーザ選択を強制する必要はなくなる。

複数人で承認を行い、全員の承認が完了した時点でワークフローを進行させる。

一人でも差戻しなどを行った場合には、合議を中断して差戻し先にワークフローを進行させる。

合議に対応する タスク には、担当ユーザを複数人割り当てることのできる マルチインスタンス・タスク を利用する。

なお、合議に参加する人数は動的に決定できる。

審議：確認や承認などを行った後、内容に応じて別の担当者による審査を実施する。

スキップ：確認や承認などを行った後、内容に応じて別の担当者による審査はスキップする。