【第二回】経費申請のフローで学ぶCamundaの基本（BPMNモデリング編）
前回はCamunda ModelerのインストールとCamunda Spring Boot StarterによるCamunda環境構築を行いました。
- 【第一回】経費申請のフローで学ぶCamundaの基本（導入編）
- 【第二回】経費申請のフローで学ぶCamundaの基本（BPMNモデリング編）
- 【第三回】経費申請のフローで学ぶCamundaの基本（BPMN実行編）
- 【第四回】経費申請のフローで学ぶCamundaの基本（DMN編）
- 【第五回】経費申請のフローで学ぶCamundaの基本（CMMN編）
- 【第六回】経費申請のフローで学ぶCamundaの基本（テスト編）
- 【第七回】経費申請のフローで学ぶCamundaの基本（まとめ）
今回は、前回インストールしたCamunda Modelerを使って、「経費申請」の基本的なワークフローをBPMNでモデリングしてみましょう。
BPMNとは
BPMNとはBusiness Process Modeling Notationの略で、ビジネスプロセスをモデリングするための記法です。
ビジネスプロセスとは業務の一連の流れのことで、BPMNは、タスクの担当者や担当範囲、フローの分岐条件、システムが担当するタスクやメッセージのやりとりなどが明確かつロジカルに定義できる、定型作業としてのワークフローをモデルとして表記することを得意とします。
百聞は一見にしかずなので、経費申請のワークフローを下記のような簡単な業務要件としてモデリングしてみましょう。
- ユーザーが経費申請のフォームを入力する
- 承認者が申請を承認する
上記のような要件をBPMNで表現してみると下のようなモデルが出来上がります。
GitHubにもあげてあるのでCamunda Modelerから開いて見ることも可能です。
ぱっと見ただけでも直感的に何を表現しているかわかりやすいかと思いますが、今回はこのBPMNのモデルを作成するのに必要ないくつかのコンポーネントの説明と、Camunda Modeler上でのコンポーネントの作成方法を解説していきます。
プール
ひとかたまりのビジネスプロセスや、あるプロセスを担当する一番高次な概念（たとえば部署等）を表現するためのコンポーネントを「プール」と呼びます。プールは、Camunda Modeler上の左下にあるこちらのボタンを押すと作成することができます。
プールの詳細についてはこちらのドキュメントに詳しく記載があります。
今回は「経費申請」のためのプロセスということで、こちらのボタンから経費申請のプールを作成すると下のようになります。
プールの名前（今回は「経費申請」）は、プールを選択した際に右側に表示されるProperties PanelのName欄に入力すればOKです。
プール以外の他のBPMNコンポーネントについても、名前に関してはすべて同じProperties PanelのName欄から記入することができます。
スイムレーン
スイムレーンとは、プール内で特定のタスクの担当範囲を分割するためのコンポーネントです。詳細についてはこちらのドキュメントを参照してください。
今回の経費申請ワークフローでは、申請者、承認者、経理という担当範囲を定義しているので、経費申請プールにこのスイムレーンを作成してみましょう。
まずはプールを選択した際に右側に現れるDivide into two Lanesというボタンを押してみましょう。
下のように、プールが2つのレーンに分割されます。
次に、どちらかのレーンを選択して右のメニューのAdd Lane aboveもしくはAdd Lane belowどちらでも良いので押して見ましょう。
これでスイムレーンが3つ作成できたので、それぞれ申請者、承認者、経理としましょう。
イベント
BPMNには「イベント」という概念があり、ワークフローのスタート起点となるイベントStart Eventであったり、プロセスの途中に発生するエラーハンドリングのようなイベントIntermidiate Event、プロセスの終点となるイベントEnd Eventを表記することができます。
Camunda Modeler上では左のメニューにあるこれらの丸いコンポーネントがそれぞれStart Event、Intermidiate Event、End Eventとなります。
さらに、それぞれのイベント内にもメッセージを起点とするイベントMessage Eventや時間発火するイベントTimer Event、特定の条件で発動するイベントConditional Event、Signal Event等さまざまな種類のイベントが存在します。今回はこれらの紹介は省きますが、イベントの詳細はこちらのドキュメントを参照してみてください。
今回は起点イベントとして「経費申請フォーム送信」というStart Eventを作成してみましょう。左のメニューからStart Eventを選択して申請者レーンに配置をし、「経費申請フォーム送信」という名前をつけるだけなので直感的にいけるかとおもいます。
タスク
さて、一旦起点イベントから「経費申請フォーム」が送信されたら、今度は承認者が申請フォームを承認する必要があります。BPMNでは、このような、人やシステムが何かしらのアクションを起こす概念を「タスク」と呼びます。
タスクにもさまざまな種類があり、こちらのドキュメントで詳細を確認することができます。
「経費申請」フローで使用するタスクは、人がアクションを起こすUser Taskと、システムがアクションを起こすService Taskの2種類で、今回の例ではUser Taskは「承認」と「確認」、Service Taskは「経費記録」のタスクをこなします。それぞれ下のようなBPMNコンポーネントとなります。
ここでは承認者が承認するユーザータスクUser Taskを作成してみましょう。
先ほど作成した「経費申請フォーム送信」イベントを選択すると、タスクを追加するためのAppend Taskというメニューが表示されるので、こちらをクリックします。
タスクを配置する場所をマウスで選択できるので、承認者レーンでクリックします。
すると、下記のようなメニューが出現するので、レンチマークのChange Typeを選択し、
タスクのタイプとしてUser Taskを選択しましょう。
名前を承認とすることで、下のようなモデルが出来上がります。
これでUser Taskを作成することができました。
ゲートウェイ
ビジネスプロセス上では、さまざまな状況に応じてプロセスが分岐したり、分岐したフローが合流したりといった事象を表現をしたいことがあります。BPMNでこの分岐や合流を表現するのがゲートウェイです。
今回は、経費申請が「承認されたかどうか」という判断と分岐するためにExclusive Gatewayというコンポーネントを使います。
Exclusive Gatewayは、ある条件（例えば今回は「承認済みかどうか」）に対して一つの分岐フローだけが選択されるゲートウェイになります。
承認ユーザータスクから「承認済み」かどうかを判定し分岐するためのExlusive Gatewayを足します。
作成されたExclusive Gatewayに「承認済み？」という名前をつけ、「いいえ」の場合の分岐に「経費却下」というEnd Eventを作成しましょう。下のようにEnd EventはAppend EndEventから作成することができます。
「承認済み？」の条件が「はい」だった場合の分岐には、経理のレーンに「確認」のUser Taskを作成します。
仕上げ
ここまででプール、スイムレーン、イベント、タスク、ゲートウェイというBPMNの基本的なコンポーネントを使用して「経費申請」のワークフローのほぼ最終段階までモデリングしてきました。最後に、これまでと同様の流れで「経費記録」というService Taskと「経費受理」というEnd Eventを作成すれば今回のBPMN図は完成になります。
最初にも書きましたが今回作成したBPMNはこちらのGitHubにあげてあるので、Camunda Modelerから開くことができます。最終成果物を確かめてみたい方はこちらからどうぞ。
第二回まとめ
いかがでしたでしょうか。業務要件の定義さえしっかりされていれば、Camunda Modelerを用いたBPMNモデリングは非常に直感的かつ簡単にできることがおわかりいただけたのではないでしょうか？
今回は「経費申請」という単純なワークフローを題材に、下記のBPMNコンポーネント用いてビジネスプロセスをモデリングしてみました。
次回は、今回作成したBPMNモデルをCamundaの実行環境にデプロイし、いくつかのフォームとJava実装と連携することで、実際に動く経費申請アプリケーションを作成してみます。お楽しみに。
