PAMのサンプルを動かしてみよう

PAM(Red Hat Process Automation Manager）には、いくつかのサンプルプロジェクトがあらかじめ用意されていて、すぐにその動作を試してみることができるようになっています。
PAMをインストールする手順は、こちらの記事を参照ください。

[PAMの開発環境をローカルで作成して触ってみるための手順](https://qiita.com/Erina/items/2b80ecab78d6378417fc)

# PAMサンプルのインポート方法

Business Central（とKie Server）を起動し、Business Centralに管理者ユーザでログインしましょう。

ホーム画面で、「設計」をクリックします。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/764a9bfc-62ac-8cbd-9bb1-6509a5a4f5fa.png)

Spacesのページで、スペースを追加するか、もしくはデフォルトのMySpaceをクリックします。

「サンプルを試す」をクリックします。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/3c7ff032-bd8a-807c-6be2-8ef98c908a0b.png)

サンプル一覧が表示されます。試してみたいサンプルを選択してください。
（製品バージョンによってサンプル数に違いがあります。）
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/ae0bd87e-a847-1767-379a-8159555f2f2f.png)

PAMのサンプル以外にも、DMNのサンプル、Plannerのサンプルなど、いくつかのサンプルプロジェクトがあります。
PAMのサンプルは、以下３つです。

- IT_Orders ケースマネージメントのサンプル
- Evalutaion_Process 人事評価プロセスのサンプル（ヒューマンタスクのみ）
- Mortgage_Process 住宅ローン承認プロセスのサンプル（ヒューマンタスクとルールタスク）

ここでは、Mortgage_Processサンプルについて解説します。

# Mortgage_Process サンプルの動かし方

サンプル一覧から、Mortgage_Processを選択して、OKを押します。
サンプルプロジェクトのアセットが展開されます。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/95bd40e2-5dcb-4127-5a10-ae876014e4c1.png)

### アセット種類の説明
複数のアセットがこのサンプルには含まれています。開いてみたらどんなものかはだいたいわかると思います。

- フォーム　　サンプルプロジェクト用のUI。Business Central上で、簡単な入力フォームを表示するためのもの。
- データオブジェクト　JavaのPOJO。ここではBusiness Central上で入力して、自動生成したものを使用している。別途実装して、jarにして参照させてもよい。
- ビジネスプロセス　プロセス定義。
- ガイド付きデシジョンテーブル Business Central上で生成したデシジョンテーブル。別途Excelで実装してインポートしたり、jarにして参照させることも可能。

### プロセス定義解説
プロセス定義にコメントいれると、こんな感じです。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/701ab641-b89c-a772-5564-4ab30e9c4bed.png)

サンプルフォームもついているので、ビルドしてデプロイすると、プロセスを動かしてみることが出来ます。
が、その前に、まず、ユーザー登録が必要です。
このプロセス定義では、４つのヒューマンタスクが登場しますが、それぞれのタスクに割り振られている担当者をあらかじめ作成し、そのユーザでログインすることで、該当タスクを実行してプロセスを進行することが可能になります。

それぞれのタスクの設定を確認してみましょう。
Business Centralでプロセス定義を開き、ヒューマンタスクをクリックして、プロパティを表示させます。
プロパティ表示は、右端のペンシルマークをクリックします。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/99fb8056-cd50-6df7-5ca8-19c005833c2a.png)

たとえば、[Correct Data]タスクのアクターとグループ設定を確認してみましょう。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/a4978eb8-5d19-a0ef-c853-def1a07efd8b.png)

アクターは、設定無しですね。アクターは、タスクをアサインするユーザを特定の一人に指定する場合に使います。
グループに、brokerが設定されています。つまり、brokerグループに属する人であれば、だれでもこのタスクを担当可能ということです。

その他のヒューマンタスクも同様に設定を確認してみてください。以下の様になっているはずです。

| タスク名 | グループ |
|:-:|:-:|
| Correct Data | broker |
|Qualify  | approver  |
| Increase Down Payment  | broker  |
| Final Approval  |manager   |

ということで、broker、approver,managerのグループに属するユーザが必要ということになります。
ユーザとグループの追加をしましょう。
ここでは、Business Central上でユーザとグループを追加します。これはあくまでもサンプルアプリを動かすための設定です。

### ユーザとグループの設定
今回は以下のようにユーザを追加しましょう。

| グループ名 | ユーザ名 |
|:-:|:-:|
| broker  | John  |
| broker  | Tom  |
| approver  | Mary  |
| manager  | Chris |

Business Centralの設定画面を開き、「ユーザ」設定画面を開き、上表の通り４名を新規追加します。
Chris以外は、ロール/グループの割当て無しで、作成します。
Chrisは、既存ロールのmanagerを割当てます。

次に、グループ、brokerとapproverを追加します。managerは、もともとロールに設定されているので、設定は不要です。（同じ名前のロールおよびグループの設定は不可）
グループ追加時に、そのグループに追加するユーザも同時に設定します。（あとから追加も可能です）

また、サンプルはBusiness Central上でログインしないと使えないため、各ユーザにはBusiness Centralを使うロールを割り当てる必要があります。
既存ロールがいくつか用意されていますが、とりあえずここでは、userロールを割り当てておきましょう。
**John,Tom,Mary,Chrisに、userロールを割り当てます。**

ちなみに、ここで追加した、グループやユーザの設定は、`EAP_HOME/standalone/configutarion/application-****s.properties` に書き込まれます。

既存ロールがそれぞれどういう役割なのかについては、[製品マニュアル](https://access.redhat.com/documentation/ja-jp/red_hat_process_automation_manager/7.9/html/installing_and_configuring_red_hat_process_automation_manager/roles-users-con_planning)を参照ください。

### ビルド・デプロイ

さて、サンプルプロジェクトをビルドして、Kie Serverにデプロイしましょう。
プロジェクトのページの右上の「デプロイ」をクリックすると、ビルドが行われ、Kie Serverにデプロイされます。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/99988e9a-141d-3fea-e459-1f0132c28334.png)

Business Centralのホーム画面に戻り、「デプロイ」メニューをクリックして、Kie Serverへのデプロイ状況を確認してみましょう。
（上部メニューの「実行サーバー」をクリックでも可）
![スクリーンショッ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/a8dc7455-b1b0-55d9-e41a-a4b252888654.png)

mortgage-process_1.0.0-SNAPSHOT.jarが、kieserverにデプロイされて、使える状態になっていることが確認できます。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/b312cac3-ed60-83a1-9540-c1b868bd1ecc.png)

### サンプルプロセスを実行する

Kie Serverにデプロイされた、サンプルプロセスを動かして見ましょう。
方法としては、主に２つあります。

- プロセスの実行方法としては、SwaggerUI等から、REST APIを直接実行する。
- Business Centralでプロセスインスタンスをスタートさせる。

ここでは、Business Centralを使ってプロセスをスタートさせ、タスクを進めていく方法を説明します。


※ちなみに、SwaggerUIは、`http://SERVER:PORT/kie-server/docs`でアクセスできます。
ログインを求められたら、kie-serverロールを持つユーザでログインします。以下、画面例。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/7901c607-d3cd-f130-3afc-dd7093d0f486.png)
==========

さて、プロセスをデプロイしたら、プロセスインスタンスを生成（≒プロセスを開始）します。
Business Centralにログインします。ここでは、プロセスの開始はどのユーザでも可能になっていますので、いずれかのユーザでログインします。
上部メニューから「プロセス定義」を選択します。
デプロイしたプロセス定義が表示されているので、右の縦ドットをクリックし、「開始」をクリックします。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/f70d8265-c6c7-baec-e608-7d65dd4b8cd9.png)

すると、フォームが表示されます。これは、サンプルのプロセス用に作られたフォームです。（PAMでは、作成したプロセスをテスト的に動かすための簡易フォーム作成機能があります。）
住宅ローンの申請入力のフォームになっています。英語表記なのでわかりにくいですが、日本語にするとこんな感じになります。（フォームのラベルを編集すると変更できます）
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/0395334a-b5cb-8f0c-0ffd-1d0b5775bb51.png)

ここにデータを入力し、「送信」ボタンを押すと、プロセスが開始されます。
このあと、この入力データ内容のValidationルールが走り、エラーの場合は、Correct Dataタスクが生成されます。
（RetractValidationというルールタスクがありますが、これは不要なオブジェクトを削除しているだけのルールです。繰り返しチェックできるようにしたのでしょうが、作りとしてはかなりイケてない気がします・・・）
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/6e7f8826-98c8-7cad-bb29-6c9312ac781c.png)

まずは、Validationルールでエラーになるように入力してみます。
Validationルール定義を確認しましょう。まず、プロセス定義のValidationに紐付いているルール定義はどれかを確認します。
プロセス定義のValidationルールタスクのプロパティを開いて、ルールフローグループの箇所を確認します。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/838443fa-8810-7e61-7d16-ab691c0ed8c3.png)

はい、ここでは、ルールフローグループに、`validation[Mortgage_Process]`が指定されていますね。
[]内は、プロジェクト名です。Mortgate_Processプロジェクトの中の、validationというルールフローグループのルールがここで動くということです。
ルールフローグループは、ルール定義を開けてみないと確認できないので、Mortgate_Process内のルール定義から探してみましょう。
アセット一覧表示画面で、「デシジョン」で絞って検索すると、ルール定義だけが検索できます。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/acfa91b1-1d59-0d6a-a83e-a6f0ca53cfc9.png)
この「Validate Down Payment」がそれっぽいですね。開いて確認してみましょう。
「モデル」タブの表記はわかりにくい（主観）ので、「ソース」タブでDRLを見ましょう。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/fc0fa2f9-ceda-05a9-eb7d-df2485eed9e3.png)
`ruleflow-group "validation"`とありますね！
ルールタスクとそこで呼ばれるルールとの紐付けは、このルールフローグループ名で行われますので、覚えておきましょう。

ルールの中身は簡単ですね。
`Application( downpayment == 0 || downpayment >= app.property.saleprice )`に一致すると、エラーオブジェクトを生成するルールになっています。
つまり、頭金が0、または頭金>= 物件価格の場合は、エラーになるようです。

では、再度プロセス定義を開始して、表示されたフォームに、エラーになるように入力してみましょう。
サンプルフォームの実装は、かなりいい加減なので、数値で入れるところに文字を入れると、システムエラーになったりするので、とりあえず以下のように入れてみてください。

Down Payment： 22000
Years of amortization： 20
Name： 鈴木一郎
Annual Income： 5000
SSN：  123456789
Age of property： 5
Address of prooperty： 東京都港区
Locale： 
Sales Price： 20000

入力して、「送信」ボタンを押すと、プロセスが開始されます。
コンソールログを見てみると、Validateルールに一致して、ログが表示されているはずです。
`13:20:37,767 INFO  [stdout] (default task-52) Executed Rule: Validate Down Payment`

Business Central上では、上部メニューから「プロセスインスタンス」を選択すると、MortgageApprovalProcessのプロセスインスタンスが１つ生成されていることが確認できるはずです。
クリックして、「ログ」タブを表示すると、通過したノードが表示されているはずです。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/c9ff1d3f-a737-6a0a-428b-4e6fdba6dc9e.png)

Correct Dataヒューマンタスクが生成されているようなので、該当タスクが割り当てられている、brokerグループのユーザでBusiness Centralにログインしなおします。
brokerグループのユーザでログインしたら、「タスク受信箱」を開きます。タスク受信箱は、自分または自グループに割り当てられているタスク一覧が表示される場所です。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/5de4c200-11d3-581e-5d38-e485f2d8260d.png)

Correct Dataタスクが生成されているのが確認できました。
では、このタスクをクリックして、タスクを完了させましょう。
クリックすると、申請入力内容とエラー内容を表示するフォームが出ます。（下の図はラベルが日本語になってますが、ラベルを変えていなければ英語で表示されます）
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/459f0e0f-4fe2-ed1d-1ff2-891c957bbff0.png)

さて、ここでまず先に、ヒューマンタスク（ユーザータスク）のライフサイクルについて理解しましょう。
BPMNでは、ヒューマンタスクのステートが定義されており、PAMでもそれに則った設計をしています。
![スクリーンショット 2020-12-23 13.43.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/88d99035-2d44-e3db-af58-a10531372028.png)
http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel4people/WS-HumanTask_v1.pdf

プロセスがヒューマンタスクに到達すると、まずタスクのステータスは`Created`になり、すぐに`Ready`に更新されます。
`Ready`はまだ特定の誰かにタスクがアサインされていない状態です。
先程のCorrect Dataのフォームに「クレーム」ボタンがありましたが、クレームを押すことで、その人がそのタスクの担当になり、タスクのステートは`Reserved`に更新されます。

クレームボタンを押してみましょう。
すると、今度は「リリース」と「開始」ボタンが出てきました。まだ、画面は編集不可でグレイアウトされているはずです。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/65ce2868-8409-69fb-ad61-6e186eba6361.png)

ここで、DBを見ることができる方は、DBのTaskテーブルのレコードを見てみましょう。
クレームボタン押下により、Correct DataタスクのStatusが`Reserved`になり、actualowner_idに、ログインユーザ名がセットされているはずです。
この時点で、このタスクは、他のbrokerグループのユーザからは見えなくなります。
（ここで、「リリース」ボタンを押すと、またもとの`Ready`状態に戻り、他のbrokerグループのユーザからも見えるようになります。）
では、フォームの「開始」ボタンを押しましょう。これにより、タスクのステータスは`InProgress`になり、フォームの修正入力が可能になります。

頭金を22000→2000に減額して、今度は「完了」ボタンを押しましょう。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/1015cd1a-b3c7-90e3-aedc-f9d2e8104732.png)

これにより、Correct Dataタスクのステータスは、`Completed`に更新されました。

そして、プロセスが先に進み、MortgageCalculationルールタスクが実行され、Qualifyタスクに到達したはずです。
一旦ログアウトし、approverグループのユーザでログインしなおします。
タスク受信箱を確認しましょう。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/7f256420-4e29-21da-0fea-dac654e56429.png)
タスクのライフサイクルは先程説明した通りです。
Ready　→（クレーム）　Reserved →（開始） InProgress →（完了） Completed とボタンを押して進めてみましょう。
ここは、ローン審査を行うタスクなので、フォームの下の方にある「Is mortgage application in limit?」チェックボックスにチェック（限度額内につきOK）を入れて、「完了」を押します。

```
pam_db=# select processid,name,status,actualowner_id from public.task where processid = 'Mortgage_Process.MortgageApprovalProcess';
                processid                 |      name      |  status   | actualowner_id 
------------------------------------------+----------------+-----------+----------------
 Mortgage_Process.MortgageApprovalProcess | Correct Data   | Completed | Tom
 Mortgage_Process.MortgageApprovalProcess | Qualify        | Completed | Mary
 Mortgage_Process.MortgageApprovalProcess | Final Approval | Ready     | 
(3 rows)
```
DBデータからも、QualifyがCompletedになり、Final Approvalタスクが生成されたことがわかります。

タスクテーブルの一部のカラムは、「タスクレポート」からも見ることが出来ます。
上部メニューから「タスクレポート」を選択し、タスクレポート画面の右上の「テーブルの表示」をクリックすると、タスクテーブルの中身が表示されます。
表示例
![スクリーンショット 2020-12-23 16.47.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/76d73aa7-bd27-8476-a678-55b3f7d9419b.png)



プロセスインスタンスを確認してみましょう。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/d097b9cc-2634-2253-2e1d-4587b2e1045f.png)
通過した箇所は、グレイになっているのがわかります。
今は、Qualifyタスクで、審査OKにしたので、その下の分岐で、Increase Down Paymentタスクではなく、Final Approvalに進みました。

さて、ここで、分岐についてちょっと見てみましょう。
分岐（ゲートウェイ）は、排他、並列、包含、イベントの４種類使えます。
イベントってなんだろう？使ったことないのでわかりませんw

Xが排他で、＋が並列です。この住宅ローン審査のサンプルでは、排他ゲートウェイが３つ使われていますね。

排他は、分岐が複数ある場合に、**いずれか１つだけが選択**されます。必ず１つは条件がtrueになるように設定する必要があります。
複数の分岐がtrueになる場合は、優先順位に従って、１つだけが選択されます。
また、排他ゲートウェイに入ってくる矢印が複数ある場合は、いずれかが来たらすぐに次に進みます。

並列は、複数の分岐すべてが並列に実行されます。
また、並列ゲートウェイに入ってくる矢印が複数ある場合は、すべてが到達するまで待機してから、次に進みます。

分岐の条件は、ゲートウェイではなく、矢印側に設定します。Qualifyタスクの下の排他ゲートウェイのプロパティを見てみましょう。
（プロセス定義の詳細を確認するには、adminやdeveloperロールが必要になります。adminロールのユーザでログインしなおしてください。）

ゲートウェイは、デフォルトルートの設定が可能ですが、ここでは何も設定されていませんね。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/56a9ec25-beca-7a51-1327-ee6670e936bc.png)

Final Approvalに向かう矢印のプロパティを見ると、`return inlimit;`と条件式が入っています。
inlimitの値が返却されるということですね。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/38fbaede-b5f4-5dda-d5d7-69040fabd75b.png)
Java構文で書かれていますが、式の構文は、他にもJavascript/Drools/MVEL/FEELが選択できます。

このinlimitとはなんでしょうか？というと、これは、プロセス変数として定義されています。
プロセス変数は、プロセスインスタンス毎に保持される値です。プロセス定義を開いて、背景部分をクリックして、プロパティを開く、または、「ドキュメント」タブでも確認できます。
３つのプロセス変数が定義されていて、inlimitはBoolean型で定義されていることがわかりますね。
![スクリーンショット 2020-12-23 17.16.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/275fbcd0-5bf0-4a01-8f6c-b7ddca17c48a.png)
プロセス定義のドキュメント表示は、プロセス定義の設計書になります。（いちいちプロパティを開かなくても、すべて一覧表示されるので、まあまあ便利です）

プロセス変数は、プロセスインスタンスの作成時に初期化され、そのプロセスおよび子プロセスからアクセスが可能です。
ただし、各タスクでプロセス変数にアクセスするには、各タスクのタスク変数にマッピングする必要があります。

inlimitの値は、Qualifyタスクのフォームの、ローン審査OKを示すチェックボックスの値を渡しています。
フォーム定義を見て確認してみます。
Qualify-taskformを開き、一番下のチェックボックスの縦ドットをクリックして、「編集」を選択します。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/e99cc9bf-5776-2cbf-aaea-7816af8e4975.png)
すると、開いた画面で、「フィールドバインディング」に`inlimit`がバインドされているのがわかります。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/b9d633a6-5b5c-ea47-f16d-ead46d572c55.png)

そして次に、Qualifyタスクのプロパティで、データ割当のところを見ると、以下のようにマッピングされていることがわかります。
![スクリーンショット.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276989/a035061b-b223-cb7c-ea45-fb04aeb6bc55.png)

Qualifyタスク内で、タスク変数のinlimitに、チェックボックスの値が書き込まれ、そのタスク変数inlimitが、プロセス変数のinlimitに渡されたということになります。（名前が同じなので説明がわかりにくいかもしれません。）

### 最後に
住宅ローン申し込みのサンプルを動かす方法について、一通り説明しました。
このサンプルをいろいろ改変しながら、PAMの基本動作について学習するのもよいと思います。
修正を入れて、ビルド＆デプロイすれば、OKです。