2017年10月4日水曜日

Nintex入門 第5回 ワークフローロジックの定義


連載第5回となる今回は、前回までに作成したユーザーインタフェースに対して、ついにワークフローロジックの定義を追加していきます。計算処理やメール送信といった処理を実行するための「アクション」と呼ばれる部品を組み合わせることによって、簡単にワークフローロジックを定義することができます。ワークフローロジックを作成した後に、UIも含めた動作確認を行ってみます。

 
1.1.     ワークフローロジックの基礎

まずは、Nintex Formsでワークフローロジックを作成し、公開するまでの基本的な手順をご紹介します。本記事では、リストアイテムの作成・更新時に呼び出されて処理をバックグラウンドで行うための「ワークフロー」のことを、画面を含めたワークフロー全体と区別するために「ワークフローロジック」と呼ぶことにします。
1.    カスタムリストを開き、リボンにある「Nintex Workflow」をクリックします。

 
 
2.    Nintex Workflow」の「ワークフローギャラリー」が表示されることを確認します。ワークフローロジックを作成した後にこの画面を開くと、下部のリストにワークフローが列挙されます。

 
 
 
3.    「新規ワークフローの作成」のすぐ下にある「CustomList01(カスタムリスト名)をクリックします。


4.    「リストワークフロー」の編集画面が開くことを確認します。既定では、開始と終了のアクションが配置されています。

 
 
 
5.    リボンにある「設定」をクリックします。



6.    「ワークフローの設定」ダイアログが表示されることを確認します。



7.    必要に応じて「名前」と「説明」を入力した後、「開始オプション」にある「アイテム作成時に開始」および「アイテム更新時に開始」にチェックをつけ、「保存」をクリックします。「アイテム変更時に開始」も有効化するのは、申請者も承認者も同一のアイテムを編集(申請者は初回のみ作成)するためです。



8.    続いて、リボンにある「保存」をクリックします。

 
 
9.    「保存」ダイアログが表示されることを確認します。



10.  必要に応じて設定を変更した後、「保存」をクリックします。

 
 
1.2.     アクション(部品)の追加

次に、前節で作成した土台に対して「アクション」という部品を追加していきます。アクションには、メールを送信したりリストアイテムを更新したりといった処理を行うものがあり、これらの組み合わせによってワークフローシステムを実現することができます。

この節ではシンプルなワークフローロジックの作例として、Nintex Workflowに用意されているアクションの1つである「タスクプロセス」アクションを使用したロジックをご紹介します。「タスクプロセス」アクションを使用すると、承認画面や送信されるメール本文をカスタマイズ出来ない代わりに、配置するアクションの数を抑えて手軽にワークフローロジックを完成させることができます。Nintex Workflowは、契約するプランによっては配置可能なアクションの上限数が少ない場合があり、ワークフローロジックを完成させるために必要なアクション数を抑えることが出来ればコスト負担も抑えることが可能です。

 

1.    アクションを配置する前に、「ワークフロー変数」を作成しておきます。ワークフローの処理結果として永続的に保存する必要がある情報はカスタムリストのアイテムとしてSharePoint上に保存しますが、ワークフローロジックの中で一時的に保存するだけで済む情報については、Nintex Workflow上に用意されている「ワークフロー変数」へ格納します。

       i.          まず、リボンにある「変数」をクリックします。

 
 
      ii.          「変数」ダイアログが表示されるので、「新規」をクリックします。

 
 
    iii.          変数の「名前」を入力し、「種類」を選択します。

「種類」列の右隣にある「開始」は、「スタートフォーム」というユーザーに値を入力させる画面上に変数を表示するか選択する項目なので、今回のようにNintex Formsと組み合わせる場合には使用しないので、チェックをつける必要はありません。



    iv.          必要な変数を追加したら「保存」をクリックします。



2.    続いて画面中央の領域に、以下の図のようにアクションを配置します。いったん全てのアクションを配置してから、個々のアクションの設定を行うと良いでしょう。図中に示した丸数字は、次のアクションの構成手順の連番と対応しています。



 
 
3.    それぞれのアクションに対して以下のように設定を行います。各アクション右上にある「▼」をクリックし、「構成」をクリックすることで設定します。

       i.          申請日を記録するために、実行された日の日付を取得して、「ReqDate」列に格納します。
 

 
      ii.          「ステータス」列の値を「申請中」にします。これは、Nintex Formsで作成するステータス欄の選択肢に含まれる文字列であればどれでも構いませんが、ワークフローロジックに入力される選択肢の中でもっとも初期段階のものであることから選択しました(申請画面上では「未申請」を既定値とするのが適切ですが、ワークフローロジックが開始される時点で「未申請」から「申請中」へと変更されているべきなので、リスト列の既定値は「申請中」とするのが適切という考え方です)
 

 
    iii.          ButtonType」列が「Application」のとき、つまり「申請」ボタンが押されたときのみ、後続の処理を実行するように「場合」(条件)を指定します。この条件文がないと、一時保存の場合にもワークフロー内の処理が最後まで実行されてしまい、余計な処理時間を発生させてしまいます。
 

 
    iv.          カスタムリストのアイテムから承認者を取得して、コレクション(配列型のワークフロー変数)に格納します。今回は最大5人の承認者に対応させるため、承認者の値をApp1からApp5まで変えた同様のアクションを合計5個配置します。


本来こうした繰り返し処理は「Forループ」を使用して格納させたいところですが、SharePoint側の制約により実行時間が延びてしまう課題があるため、順次追加しています。また、カウンタ変数とそのインクリメント処理を省略するために、追加先のインデックスを「0」に固定して逆順で追加します。

App5



      v.          App4




    vi.          App3




   vii.          App2



  viii.          App1




    ix.          承認者の人数を「AppCollectionCount」変数に格納しておきます。




      x.          For Each ループ」でループを中断するために使用するフラグ変数をFalse(いいえ)で初期化しておきます。




    xi.          For Each ループ」でループさせるコレクション、ステップごとのアイテムの格納先、インデックスの格納先、フラグ変数を指定します。「Forループ」とは異なり、「For Eachループ」であれば実行時間が大きく延びることはありません。




   xii.          ユーザーに対しては、インデックス変数の値そのもの(0はじまりの連番)ではなくインデックスに1を足した値(1はじまりの連番)を見せたいため、ループ内の先頭で計算して別の変数に格納しておきます。




  xiii.          コレクションから取得したユーザー情報を文字型にキャスト(変換)します。




  xiv.          承認者が格納されている場合のみ、後続の処理を実行させます。「いいえ」の分岐に後続のアクション「タスクプロセスを開始する」が接続されていることに注意して設定します。「はい」の場合は、ループ内の処理をスキップし、次の承認者の処理を行います。




   xv.          タスクプロセスを開始し、タスクプロセスの結果に応じて処理を変更します。「参加者」にはコレクションから取得したユーザー型の値を、「タスクタイトル」には区別しやすいような任意のメッセージを入力します。この時の承認者番号はユーザーが見るものなので、1はじまりの連番の方のワークフロー変数「AppIndexPlusOne」を指定しておきます。




  xvi.          現在の承認者(AppItemに格納されているユーザー)に承認された場合は、承認状況がわかるようにリスト列「Status」を変更します。リスト列「Status」の種類は選択肢なので、予めカスタムリスト側で入力しておいた候補以外の文字列を値に設定しようとすると空文字列が格納されてしまうことに注意が必要です。




xvii.          現在の承認者に却下された場合は、「Status」列を「却下」に変更します。




xviii.          却下された場合には即座にFor Each ループを終了させる必要があるため、フラグ変数にTrue(はい)を格納します。




  xix.          For Each ループが終了した後に「Status」列が「却下」でない場合(Status」列が「承認者N承認済」の場合)は、最後の承認者まで承認されたと見なします。




   xx.          最後の承認者まで承認された場合は、「Status」列を「完了」に変更します。




 
4.    全てのアクションに対して設定を終えた後、リボンにある「発行」をクリックします。
 

 
5.    必要に応じて設定を変更した後、「発行」をクリックします。



6.    「ワークフローを発行しました。」と表示されることを確認します。



7.    リボンにある「閉じる」ボタンをクリックして、Nintex Workflowを終了し、リスト画面に戻ります。
 

 
1.3.     動作確認

作成したワークフローロジックが正常に実行されるか確認します。

1.    新規アイテムを作成してみます。



2.    アイテムが作成されたことを確認します。



3.    作成されたアイテムの「・・・」をクリックし、「詳細」の中の「ワークフロー」をクリックします。



4.    「実行中のワークフロー」にあるワークフロー名をクリックします。



5.    「ワークフローの状態」画面が開きます。ワークフローの中に「タスクプロセスを開始する」アクションを配置した場合は、「タスク」に状態が表示されます。また、「履歴リストに記録する」アクションを配置した場合は、「ワークフローの履歴」に指定したメッセージが表示されます。



6.    承認者に自アカウントを指定した場合、ワークフローの状態を確認し終わる頃にはメールが届くので、通知からメール本文を開きます。



7.    メール本文にある承認リンクをクリックします。



8.    承認画面が開くことを確認します。



9.    「承認済み」ボタンをクリックします。



10.  リストのビューを開き、ステータスが変更されたことを確認します。



11.  承認者として現在のログインユーザーを複数追加した場合は追加した数分だけメールが送られてくるので、各メールに対して本文にあるリンクをクリックします。



12.  全ての承認者に承認された後、「Status」列が「完了」に変更されることを確認します。



13.  アイテムの「タイトル」の右側にある「…」をクリックし、「詳細」の中にある「ワークフロー」をクリックします。



14.  先程とは異なり、「実行中のワークフロー」ではなく「完了したワークフロー」の中に「Workflow of CustomList01(ワークフロー名)が表示されるので、これをクリックします。



15.  ワークフローの中で「タスクプロセスを開始する」アクションが呼ばれた数(For Each ループアクションに与えたコレクションの要素数)の分だけタスクが生成され、すべてのタスクの状態が「完了」になっていることを確認できれば完成です。



1.4.     まとめ


本記事では、Nintex製品を使用したワークフロー作成手順のうち、最も簡易な「タスクプロセス」を使用したものをご紹介しました。タスクプロセスを使用することによって、予め定義されている承認画面やメールテンプレートを使用でき、短期間でのワークフロー開発を行うことが出来ました。しかしながら、予め用意されたアクションを使用するために、カスタマイズの余地が狭いと言うことも出来ます。

次回の記事では、よりカスタマイズ性が高く実運用に適したアクションを使用した作成手順についてご紹介したいと考えております。


ブログアーカイブ

前回までのブログと今後の予定
Nintex Workflow
 第6回 Nintex ワークフローロジックの定義(応用編) 10月中旬以降予定
 
その他以下ブログを発信中です。
 
機械学習(Azure Machine Learning)の入門からビジネス活用へ