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

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

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

ホーム画面で、「設計」をクリックします。

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

「サンプルを試す」をクリックします。

サンプル一覧が表示されます。試してみたいサンプルを選択してください。
（製品バージョンによってサンプル数に違いがあります。）

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

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

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

Mortgage_Process サンプルの動かし方

サンプル一覧から、Mortgage_Processを選択して、OKを押します。
サンプルプロジェクトのアセットが展開されます。

アセット種類の説明

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

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

プロセス定義解説

プロセス定義にコメントいれると、こんな感じです。

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

それぞれのタスクの設定を確認してみましょう。
Business Centralでプロセス定義を開き、ヒューマンタスクをクリックして、プロパティを表示させます。
プロパティ表示は、右端のペンシルマークをクリックします。

たとえば、[Correct Data]タスクのアクターとグループ設定を確認してみましょう。

アクターは、設定無しですね。アクターは、タスクをアサインするユーザを特定の一人に指定する場合に使います。
グループに、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 に書き込まれます。

既存ロールがそれぞれどういう役割なのかについては、製品マニュアルを参照ください。

ビルド・デプロイ

さて、サンプルプロジェクトをビルドして、Kie Serverにデプロイしましょう。
プロジェクトのページの右上の「デプロイ」をクリックすると、ビルドが行われ、Kie Serverにデプロイされます。

Business Centralのホーム画面に戻り、「デプロイ」メニューをクリックして、Kie Serverへのデプロイ状況を確認してみましょう。
（上部メニューの「実行サーバー」をクリックでも可）

mortgage-process_1.0.0-SNAPSHOT.jarが、kieserverにデプロイされて、使える状態になっていることが確認できます。

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

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

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

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

※ちなみに、SwaggerUIは、http://SERVER:PORT/kie-server/docsでアクセスできます。
ログインを求められたら、kie-serverロールを持つユーザでログインします。以下、画面例。

さて、プロセスをデプロイしたら、プロセスインスタンスを生成（≒プロセスを開始）します。
Business Centralにログインします。ここでは、プロセスの開始はどのユーザでも可能になっていますので、いずれかのユーザでログインします。
上部メニューから「プロセス定義」を選択します。
デプロイしたプロセス定義が表示されているので、右の縦ドットをクリックし、「開始」をクリックします。

すると、フォームが表示されます。これは、サンプルのプロセス用に作られたフォームです。（PAMでは、作成したプロセスをテスト的に動かすための簡易フォーム作成機能があります。）
住宅ローンの申請入力のフォームになっています。英語表記なのでわかりにくいですが、日本語にするとこんな感じになります。（フォームのラベルを編集すると変更できます）

ここにデータを入力し、「送信」ボタンを押すと、プロセスが開始されます。
このあと、この入力データ内容のValidationルールが走り、エラーの場合は、Correct Dataタスクが生成されます。
（RetractValidationというルールタスクがありますが、これは不要なオブジェクトを削除しているだけのルールです。繰り返しチェックできるようにしたのでしょうが、作りとしてはかなりイケてない気がします・・・）

まずは、Validationルールでエラーになるように入力してみます。
Validationルール定義を確認しましょう。まず、プロセス定義のValidationに紐付いているルール定義はどれかを確認します。
プロセス定義のValidationルールタスクのプロパティを開いて、ルールフローグループの箇所を確認します。

はい、ここでは、ルールフローグループに、validation[Mortgage_Process]が指定されていますね。
[]内は、プロジェクト名です。Mortgate_Processプロジェクトの中の、validationというルールフローグループのルールがここで動くということです。
ルールフローグループは、ルール定義を開けてみないと確認できないので、Mortgate_Process内のルール定義から探してみましょう。
アセット一覧表示画面で、「デシジョン」で絞って検索すると、ルール定義だけが検索できます。

この「Validate Down Payment」がそれっぽいですね。開いて確認してみましょう。
「モデル」タブの表記はわかりにくい（主観）ので、「ソース」タブでDRLを見ましょう。

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のプロセスインスタンスが１つ生成されていることが確認できるはずです。
クリックして、「ログ」タブを表示すると、通過したノードが表示されているはずです。

Correct Dataヒューマンタスクが生成されているようなので、該当タスクが割り当てられている、brokerグループのユーザでBusiness Centralにログインしなおします。
brokerグループのユーザでログインしたら、「タスク受信箱」を開きます。タスク受信箱は、自分または自グループに割り当てられているタスク一覧が表示される場所です。

Correct Dataタスクが生成されているのが確認できました。
では、このタスクをクリックして、タスクを完了させましょう。
クリックすると、申請入力内容とエラー内容を表示するフォームが出ます。（下の図はラベルが日本語になってますが、ラベルを変えていなければ英語で表示されます）

さて、ここでまず先に、ヒューマンタスク（ユーザータスク）のライフサイクルについて理解しましょう。
BPMNでは、ヒューマンタスクのステートが定義されており、PAMでもそれに則った設計をしています。

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel4people/WS-HumanTask_v1.pdf

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

クレームボタンを押してみましょう。
すると、今度は「リリース」と「開始」ボタンが出てきました。まだ、画面は編集不可でグレイアウトされているはずです。

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

頭金を22000→2000に減額して、今度は「完了」ボタンを押しましょう。

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

そして、プロセスが先に進み、MortgageCalculationルールタスクが実行され、Qualifyタスクに到達したはずです。
一旦ログアウトし、approverグループのユーザでログインしなおします。
タスク受信箱を確認しましょう。

タスクのライフサイクルは先程説明した通りです。
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タスクが生成されたことがわかります。

タスクテーブルの一部のカラムは、「タスクレポート」からも見ることが出来ます。
上部メニューから「タスクレポート」を選択し、タスクレポート画面の右上の「テーブルの表示」をクリックすると、タスクテーブルの中身が表示されます。
表示例

プロセスインスタンスを確認してみましょう。

通過した箇所は、グレイになっているのがわかります。
今は、Qualifyタスクで、審査OKにしたので、その下の分岐で、Increase Down Paymentタスクではなく、Final Approvalに進みました。

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

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

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

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

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

ゲートウェイは、デフォルトルートの設定が可能ですが、ここでは何も設定されていませんね。

Final Approvalに向かう矢印のプロパティを見ると、return inlimit;と条件式が入っています。
inlimitの値が返却されるということですね。

Java構文で書かれていますが、式の構文は、他にもJavascript/Drools/MVEL/FEELが選択できます。

このinlimitとはなんでしょうか？というと、これは、プロセス変数として定義されています。
プロセス変数は、プロセスインスタンス毎に保持される値です。プロセス定義を開いて、背景部分をクリックして、プロパティを開く、または、「ドキュメント」タブでも確認できます。
３つのプロセス変数が定義されていて、inlimitはBoolean型で定義されていることがわかりますね。

プロセス定義のドキュメント表示は、プロセス定義の設計書になります。（いちいちプロパティを開かなくても、すべて一覧表示されるので、まあまあ便利です）

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

inlimitの値は、Qualifyタスクのフォームの、ローン審査OKを示すチェックボックスの値を渡しています。
フォーム定義を見て確認してみます。
Qualify-taskformを開き、一番下のチェックボックスの縦ドットをクリックして、「編集」を選択します。

すると、開いた画面で、「フィールドバインディング」にinlimitがバインドされているのがわかります。