はじめに
ワークフロー要件において、「ユーザマスタ未登録の入社予定者」を承認者に指定したいケースがありました。
- 現状： 社内独自の「先日付ユーザ管理テーブル」にはユーザコードが存在するが、IM標準のユーザマスタにはまだ登録されていない。
- 問題点： 標準機能のノード遷移では、IMユーザマスタに存在しないアカウントを処理者に設定できない
解決アプローチ
本記事では、標準機能の制約を回避するため、以下のステップでジョブネット（ロジックフロー）から処理者を後付けで設定する方法を解説します。
処理内容： 「IM標準ユーザマスタおよび先日付ユーザ管理テーブル」の情報を参照し、対象案件の「動的承認ノード」に対して処理者を動的にセットする。「先日付ユーザ管理テーブル」の場合は、ダミーアカウントを設定or意図的に動的承認者を未設定状態にする
※未設定とした場合、ログ上エラーは残る＆処理対象無しログも残ります。
タイミング： IMユーザマスタへ該当アカウントが登録された後のジョブネットで自動設定
実行手段： ジョブネットからロジックフローを起動。
フローイメージ
フローは以下のとおりです。設定タイミングは申請・承認時どちらでもOKです。
実装時のポイント
- 本事例ではFormaアプリの種別「ワークフロー」で作成します。ほぼ同じかと思いますが、IM-BISは読み替えてください。
- Forma標準テーブルにジョブネットで制御するうえで必要な項目（隠し項目）をセットしておく。
- 動的承認ノードはユーザをセットする前提です。
- 動的承認ノードはカスタムスクリプトを用いてセットします。やり方が不明な場合は、処理モーダルをでの手順となりますが以下を参照いただければと思います。
構築手順
Forma画面設計
設計によりますが、以下4点がForma標準テーブルにあるとジョブネットでコントロールしやすいと思います。
- 先日付社員であることがわかる管理項目（＝隠し項目）
- ジョブネットでの更新有無を把握するための管理項目（＝隠し項目）
- 最終承認が完了した把握するための管理項目（＝隠し項目）
- ワークフローのシステム案件ID（systemMatterId）（＝隠し項目）
ジョブネット構築手順
入出力定義
ジョブネットなので不要です。
対象データ抽出
画面設計の隠し項目を利用し、先日付対象者をピックアップします。複数あると思うので、レコード分を繰り返し処理させます。
ピックアップした対象者から既にIMMユーザとして登録されたユーザに絞ります。
分岐でユーザコードに対してIMユーザマスタに１件でもヒットすれば、今回の目的である該当ノードに対して「処理者」を追加します。
※SQL定義は簡易で作成してますため、実環境に合わせた形で組んでください。
処理対象者追加と後始末
必要情報であるシステム案件ID、ノード、ユーザコードを指定します。
今回はノードは定数定義してますが、画面設計次第では動的にコントロールできるかもしれません。
処理者対象者追加が完了すれば、翌日以降ピックアップされないように後始末として、既に更新したことがわかるように管理項目を更新します。
まとめ
以上で、『【intra-mart】動的承認ノードにジョブネットで処理対象者を追加する方法』をお届けしました。
比較的容易に構築できますので、同じ要件で悩まれている方は参考にしていただければ幸いです。
コメント