2017年10月20日金曜日

Nintex入門 第6回 ワークフローロジックの定義(応用編)

連載第6回となる今回は、前回ご紹介したタスクプロセスを用いた作成方法では実現できない、より応用的なワークフローロジックの定義方法をご紹介します。

 
1.1.     タスクプロセスを使用しないロジック作成手順

前回の記事では「タスクプロセス」アクションを使用したワークフローの作成方法をご紹介しました。しかしながら、前回の手順で作成したワークフローロジックには以下のような課題があります。

l  承認画面や送信されるメール文面のカスタマイズ性が低い

l  ワークフロー処理が完了するまでワークフローのプロセスが実行され続けるため、処理負荷が高い

そこで今回は、メールを送信したり、ステータスを管理したりするアクションを組み合わせることによって、タスクプロセスアクションを配置した時と同様の動作を実現します。若干難易度は高くなりますが、上記のような課題を解決することが出来るため、利便性の高いワークフローが出来上がります。前回と同様に、Nintex Workflowの編集画面を開いて作業します。

 

1.    「ワークフロー変数」を作成しておきます。

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


 

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



 

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

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



 

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



 

2.    ワークフローの編集画面に戻り、アクションを配置します。すべてのアクションを配置した後に、各アクションの「構成」を行います。今回作成するワークフローの全体図を以下に示します。






3.各アクションに対して、「構成」メニューから設定を行います。以下に1の図中に示した各アクションの連番と設定内容を示します。
  

 

     申請日時を記録するために、実行日時を取得してリスト列「ReqDate」に追加します。



 

     (ii)でリスト列に格納した申請日時を文字型にキャストした後、同名のワークフロー変数に格納します。



 

     リスト列「登録者」を取得し、文字型にキャストした上でワークフロー変数「Author」に格納します。この変数が申請者のユーザー情報を持つことになります。



 

     「登録者」の「表示名」をワークフロー変数に格納します。単に「現在のアイテム」から「登録者」を選択しただけでは、(iii)と同様に登録者の「ログイン名」しか取得できないため、以下の追加手順が必要になります。

 

(ア)  テキストボックス「文字列」をクリックした後、「高度な検索」をクリックします。




 

(イ)  「次に等しい」の「リストから検索」を選択します。すると、「ソース」と「フィールド」のドロップダウンメニューが表示されるので、それぞれ「現在  のアイテム」、「登録者」を選択します。



 

(ウ)  「フィールド」の右隣にある数式アイコンをクリックします。


             (エ)  既定値の「ログイン名」から「表示名」に変更します。

             (オ)  OK」をクリックします。

 

(カ)  「挿入」をクリックします。


           (キ)  テキストボックス「文字列」に追加されたことを確認します。



 

     空文字列をワークフロー変数「AppComment」に格納します。これは承認者コメント欄のデフォルト値とします。わざわざリストアイテムの値を参照させているのは、Nintex Workflowの構成画面で空文字を指定しようとしてもエラーとなってしまい、保存できないという制約があるためです。



 

     「一時保存」ボタンが押された場合には後続処理を行う必要がないため、リストの「ButtonType」列の値を基に押されたボタンが「一時保存」かどうかを判定します。



 

     承認者ユーザーをコレクションに格納します。今回は承認者が5人いるため、「値」のみを変更した同様のアクションを5個配置する必要があります。

Forループを使用して格納させたいところですが、SharePointの制約により実行時間が延びてしまう問題があるため、前回の記事と同様に個別に追加しています。また、カウンタ変数とそのインクリメント処理を省略するために、追加先のインデックスを「0」に固定して、承認者5から承認者1へ逆順で追加しています。

 

(ア)  承認者5を追加します。


 

(イ)  承認者4を追加します。



 

(ウ)  承認者3を追加します。




 

(エ)  承認者2を追加します。



 

(オ)  承認者1を追加



 

     コレクションにある空の要素を除去します。「承認者」テキストボックスのいずれかを空欄にしたまま申請した場合に、該当する要素が削除されることになります。



 

     申請者である「アイテムの登録者」を、アクセス権限の判定に使用するための閲覧可能ユーザー一覧に追加します。



 

     For Each ループを使用して、承認者も閲覧可能ユーザー一覧に追加します。



 

     閲覧可能ユーザー一覧は文字型の変数なので、承認者ユーザー情報を文字型にキャストする必要があります。



 

     文字型にキャストしたユーザー情報が空文字でなく、かつ、閲覧可能ユーザー一覧に既に含まれていない場合のみ、⑬の追加処理を行います。



 

     文字型にキャストしたユーザー情報を、閲覧可能ユーザー一覧の既存の文字列にセミコロン区切りで連結します。



 

     閲覧可能ユーザー一覧を格納したワークフロー変数「Members」の値を、リストの「Member」列に反映させます。リスト列「Members」の種類は「ユーザーまたはグループ」を選択します。



 

     ワークフローロジック側でログインユーザーと閲覧可能ユーザー一覧を比較するためには文字列同士の演算として扱う必要があるため、「Members」列とは別の列に文字型のまま格納する必要があります。そのため、リスト列「Members」に格納したのと同じ内容を、文字型の値としてリスト列「MembersString」にも格納しておきます。リスト列「MembersString」の種類には、「一行テキスト」を指定してあります。




 

     承認者数を数えてワークフロー変数「AppCollectionCount」に格納しておきます。



 

21    承認者のログイン名を取得します。



 

22    承認者の表示名を取得します。



 

23    画面で押されたボタンに応じて実行する処理を判定するので、リスト列「ButtonType」の値を基に分岐します。4種類の値で処理内容を変更するため、アクション「条件付き分岐」ではなく、アクション「スイッチ」を使用します。



 

24    承認履歴が空文字列か判定します。



 

25    承認履歴が空文字列でない場合、現在の承認履歴の末尾にレコードを追加し、ワークフロー変数「AppHistoryAddedCurrentRow」に格納します。



 

26    承認履歴が空文字列の場合、先頭に現在の承認履歴と改行を入れる必要がないため、レコードのみをワークフロー変数「AppHistoryAddedCurrentRow」に格納します。



 

27    ワークフロー変数「AppHistoryAddedCurrentRow」で組み立てた承認履歴レコードを、リスト列「AppHistory」に反映させます。



 

28    リスト列「AppComment(承認者コメント)を空文字列で初期化しておきます。この処理がないと、次の承認者が承認画面を表示した際に前の承認者が入力したコメントが表示されてしまいます。




 

29    ステータスを「申請中」に変更します。



 

30    ワークフローコンテキスト「現在のアイテムのURL」を基に、編集画面のURLを生成し、ワークフロー変数「ItemEditUrl」に格納します。



 

31    次の承認者を取得します。ここで取得したユーザーにメールを送信して承認リンクを開いてもらうことになります。



 

32    取得したユーザー(のログイン名)を文字型にキャストし、ワークフロー変数「AppString」に格納します。



 

33    ワークフロー変数「AppString」の値を基に、承認者ユーザーのメールアドレスを取得します。


 

34    電子メールを送信するための設定を行います。



 

(カ)   「宛先」および「件名」を入力します。宛先には(29)で取得したものを使用します。



 

(キ)  下方向にスクロールして、テキストエリア「本文」をクリックしてフォーカスを当てます。



 

(ク)  「リンクを挿入」をクリックします。



 

(ケ)  URL」、「ハイパーリンクテキスト」欄が表示されるので、まず「URL」をクリックしてフォーカスを当てます。



 

(コ)  右側にある「参照の挿入」パネルで「ワークフロー変数」をクリックします。



 

(サ)  ItemEditUrl」をダブルクリックします。



 

(シ)  URL」に追加されたことを確認します。



 

(ス)  続いて、「ハイパーリンクテキスト」をクリックして、フォーカスを当てます。



 

(セ)  リンク文字列(アンカータグに囲まれる文字列)を入力します。



 

(ソ)  「挿入」をクリックします。



 

(タ)  「本文」に追加されていることを確認します。



 

(チ)  必要に応じて、前後にメッセージを追加します。



 

35    現在の承認履歴の末尾にレコードを追加し、ワークフロー変数「AppHistoryAddedCurrentRow」に格納します。



 

36    ワークフロー変数「AppHistoryAddedCurrentRow」で組み立てた承認履歴レコードを、リスト列「AppHistory」に反映させます。




 

37    リスト列「AppComment(承認者コメント)を空文字列で初期化しておきます。この処理がないと、次の承認者が承認画面を表示した際に前の承認者が入力したコメントが表示されてしまいます。



 

38    現在承認処理を実行中の承認者ユーザーを識別するためのインデックスを格納しているリスト列「CurrentAppIndex」の値をインクリメントさせます。




 

39    ワークフロー変数「CurrentAppIndex」の値をリスト列「CurrentAppIndex」に反映させます。



 

40    リスト列「Status」を承認の進捗状況に合わせて変更します。



 

41    すべての承認者に承認されたかを確認するために、承認者インデックスと承認者数を比較します。



 

42    ワークフローコンテキスト「現在のアイテムのURL」を基に、編集画面のURLを生成し、ワークフロー変数「ItemEditUrl」に格納します。





 

43    次の承認者(メールを送信して承認リンクを開いてもらう)を取得します。



 

44    取得したユーザー(のログイン名)を文字型にキャストし、ワークフロー変数「AppString」に格納します。



 

45    ワークフロー変数「AppString」の値を基に、承認者ユーザーのメールアドレスを取得します。



 

46    (34)と同様の手順で、電子メールを送信するための設定を行います。




 

47    リスト列「Status」の値を、承認の進捗状況に合わせて変更します。



 

48    ワークフローコンテキスト「現在のアイテムのURL」を基に確認画面のURLを生成し、ワークフロー変数「ItemDispUrl」に格納します。



 

49    登録者のユーザー情報を文字型にキャストし、ワークフロー変数「AppString」に格納します。



 

50    ワークフロー変数「AppString」の値を基に、登録者ユーザーのメールアドレスを取得します。




 

51    (34)と同様の手順で電子メールを送信するための設定を行う。ハイパーリンクのURLのみ「ItemEditUrl」から「ItemDispUrl」に変更する必要があります。



 

52    現在の承認履歴の末尾にレコードを追加し、ワークフロー変数「AppHistoryAddedCurrentRow」に格納します。



 

53    ワークフロー変数「AppHistoryAddedCurrentRow」で組み立てた承認履歴レコードを、リスト列「AppHistory」に反映させます。





 

54    リスト列「AppComment(承認者コメント)を空文字列で初期化しておきます。この処理がないと、次の承認者が承認画面を表示した際に、前の承認者が入力したコメントが表示されてしまいます。



 

55    リスト列「Status」の値を、承認の進捗状況に合わせて変更します。



 

56    ワークフローコンテキスト「現在のアイテムのURL」を基に、確認画面のURLを生成し、ワークフロー変数「ItemDispUrl」に格納します。




 

57    文字型にキャストした登録者(申請者)のログイン名を基に、登録者のメールアドレスを取得します。



 

58    (34)と同様の手順で電子メールを送信するための設定を行います。



 

59    現在の承認履歴の末尾にレコードを追加し、ワークフロー変数「AppHistoryAddedCurrentRow」に格納します。



 

60    ワークフロー変数「AppHistoryAddedCurrentRow」で組み立てた承認履歴レコードを、リスト列「AppHistory」に反映させます。




 

61    リスト列「AppComment(承認者コメント)を空文字列で初期化しておきます。この処理がないと、次の承認者が承認画面を表示した際に前の承認者が入力したコメントが表示されてしまいます。



 

62    リスト列「Status」の値を、承認の進捗状況に合わせて変更します。




 

63    申請者に再申請を行わせるためには編集画面を有効化しなければならないため、リスト列「ButtonType」に「TempSave」を設定します。




 

64    再申請が行われた場合に承認プロセスを最初の承認者から再実施するために、インデックスを0に戻す必要があります。



 

65    ワークフローコンテキスト「現在のアイテムのURL」を基に、編集画面のURLを生成し、ワークフロー変数「ItemEditUrl」に格納します。



 

66    文字型にキャストした登録者(申請者)のログイン名を基に、登録者のメールアドレスを取得します。




 

67    (34)と同様の手順で電子メールを送信するための設定を行います。



 

1.2.     ワークフロー発行と動作確認


作成したワークフローロジックの動作確認を行います。

 

1.    ワークフロー編集画面のリボンにある「発行」をクリックします。



 

2.    必要に応じて設定を変更した後、ダイアログ下部の「発行」をクリックします。



 

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



 

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



 

5.    ワークフローが正常に実行されるか確認するために、新規アイテムを作成します。



 

6.    SharePointのデフォルトの編集画面ではなく、連載第3回で作成したフォームが表示されることを確認します。

 
 
 
7.    適当な値を入力し、「保存」をクリックします。



 

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



 

9.    承認者に自アカウントを指定した場合にメールが届く点は、タスクプロセスアクションを使用してワークフローロジックを作成した時と同様です。しかし、メール本文の承認リンクをクリックした後に開く画面が申請画面と同一のフォームとなる点は、タスクプロセスの時と異なります。

また、承認履歴に承認者の情報が追記されていること、承認者列を基にした判定によって「申請」ボタンが非表示となるかわりに「承認」、「差戻し」、「却下」の各ボタンが表示されていることを確認します。

確認出来たら、「承認」をクリックします。



 

10.  リストのビューを開き、ステータスが変更されたことを確認します。承認者が1人の場合は「完了」、承認者が2人以上の場合は「承認者1承認済」と変更されているはずです。



 

11.  最終的にすべての承認者に承認され、「Status」列が「完了」に変更されることを確認します。

 

1.3.     まとめ


本記事では、応用的なワークフローシステムを実現するために必要な、個別のアクションを組み合わせてワークフローロジックを作成する手順についてご紹介しました。タスクプロセスを使用しないため、柔軟なワークフローロジックを組み立てることが出来ました。

機会があれば、これまでにご紹介した内容を基に、実案件を模したワークフローシステムを作成する手順についてもご紹介したいと考えております。

ブログアーカイブ

前回までのブログと今後の予定
Nintex Workflow
 
その他以下ブログを発信中です。
 
機械学習(Azure Machine Learning)の入門からビジネス活用へ