さて、プロセスをデプロイしたら、プロセスインスタンスを生成（≒プロセスを開始）します。
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がバインドされているのがわかります。

そして次に、Qualifyタスクのプロパティで、データ割当のところを見ると、以下のようにマッピングされていることがわかります。

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

最後に

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