Logic-Designerを用いたサーバサイド処理のローコード開発について（サンプル有）

本記事では、intra-mart Accel PlatForm(以下、IM)の基盤上で動作するアプリケーション、Logic-Designer(以下、LD)に関する技術投稿記事になります。

※Logic-Designerの詳細については、下記公式ガイドを参照願います。
[Logic-Designerとは](https://document.intra-mart.jp/library/iap/public/im_logic/im_logic_specification/texts/summary/index.html "Logic-Designerとは")


##Logic-Designerについて
LDとは、スクラッチ開発等で必要とするコーディング作業を、ローコードで実現可能とするGUIツールです。

LDでは、いくつかのサーバサイドの処理が「タスク」と呼ばれる、言いかえれば視覚的なAPI群にまとめられており、これらを線で結んで配置し、各タスクに対し「マッピング」と呼ばれる「入出力」を必要に応じて定義します。

これらをいくつかの「ロジックフロー」として定義することで、必要なタイミングで呼び出し可能となります。

##スクラッチ開発との相違点
相違点について、下記に記述します。

＜スクラッチ開発＞
・各種APIを正しく使うための知識が必要です。
・定数や変数、関数定義等を全て記述する必要があります。
・第三者が見た場合に処理を追う必要があり、視覚的にわかりづらいことでレビュー作業に時間がかかります。
・動作確認には外部モジュールやコンパイル作業が必要で、試験作業に時間がかかります。
・凡ミスによるバグ発生率が高く、修正作業に時間がかかります。
・エラー時の記述が煩雑になりやすいです。

＜LD開発＞
・各種APIを知らない場合でも、タスク毎の入出力に関する最低限の知識で製造可能です。
・定数名や変数名は汎用的なグローバル定義で使用可能です。
・線引きされたタスクを順に追うだけで、どのような処理が行われるのか視覚的に把握しやすいです。
・デバッグ機能が備わっているため、実行時のパラメータ設定のみで動作確認可能です。
・標準タスク内での内部エラーが発生することは考えにくいため、バグ発生率が比較的少ないです。
・内部エラー時のフラグ確認が容易なため、エラー発生時の挙動をハンドリングしやすいです。

##その他特徴
その他特徴ついて、下記に記述します。

・IMのワークフロー後処理や、システムノードで実行するプログラムとしての呼び出し等が可能です。
・ワークフロー操作や、IM-Forma-Designer、IM-BloomMaker等の一部データの操作が可能です。
>現時点（2021/11/30）では、IM-BloomMakerは添付ファイル操作のみ、Forma-Designerは添付ファイルや根回しメール、代理承認等を除く機能について対応しているようです。

・ロジックフローから他のロジックフロー呼び出しも可能なため、オブジェクト指向があれば複雑なフローも作成可能です。
・標準タスクに存在しないプログラムは「ユーザ定義」として作成可能です。

##（参考）実装例
例として、次のようなサーバサイドの処理の実装が必要な場合を想定します。
>画面の入力項目の条件に従い、指定ノードへ処理対象者を追加します。

これをスクラッチで開発する場合、次のような作業が必要です。

１．リクエストパラメータからuserDataIdを取得します。
２．取得したuserDataIdを用いて、必要なAPIを実行し対象テーブルから案件データを取得します。
３．取得結果から、対象データを抽出します。
４．対象データが指定の条件に一致するか判定します。
５．一致する場合、処理者を追加するノードを決定します。
６．指定ノードへ追加する処理対象者を決定します。
７．処理対象者情報を作成します。
８．処理対象者情報を用いて、必要なAPIを実行します。

ここまでの作業が、LDを使用すると次のような操作で作成することができます。

１．案件データを取得するための「案件データ取得」ユーザ定義タスクを新規作成します。
![SQL定義編集1](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/9b8b62fe-6684-c21b-a9e9-43991be21d83.png "SQL定義編集1（案件データ取得タスク）")
![SQL定義編集2](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/ba49a601-b4da-ef12-a97f-1d26c5c4090b.png "SQL定義編集2（案件データ取得タスク）")
![SQL定義編集3](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/a83d6ebd-004f-92be-4b9c-0b4c7ecb7168.png "SQL定義編集3（案件データ取得タスク）")

２．作成した１の「案件データ取得」タスク、「分岐」タスク、「処理対象者追加」タスクを配置し、添付の例のように各タスクを線で結びます。
![タスク配置](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/3d84837a-9486-5d4d-6144-af36573c33d5.png "タスク配置")

３．必要に応じて入出力設定を定義します。
![入出力設定](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/7fe6a5db-e078-4019-0b21-f4df5c71fc3c.png "入出力設定")

４．各タスクのマッピングやEL式を設定します。
![マッピング1](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/aafbbaa6-5ce9-8954-c644-f2fa21ec7f14.png "マッピング（案件データ取得タスク）")
![EL式](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/7c1bc39d-7b5e-c10d-1209-4c8d0676b7fd.png "EL式（分岐タスク）")
![マッピング2](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/a0cedf06-04ca-2b1e-56db-dfc99ae0e2da.png "マッピング（処理対象者追加タスク）")
※EL式の詳細については、下記公式ガイドを参照願います。
[EL式とは](https://document.intra-mart.jp/library/iap/public/im_logic/im_logic_specification/texts/appendix/expression_language.html "EL式とは")


##実行例
デバッグ機能を用いて、動作確認します。

###開始条件
１．キーとなるシステム案件ID、ユーザデータIDがある申請データが存在する。
２．処理追加対象者ユーザが処理対象者となっていない。

###終了条件
処理追加対象者ユーザが処理対象者となる。

開始条件１
![開始条件１](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/a6383972-9c93-3b27-a24d-676a589777b1.png "開始条件１")

開始条件２
![開始条件２](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/e71c1c05-4b65-e99a-f70a-a901d3c193cf.png "開始条件２")

追加対象ユーザ：test2

動作確認（デバッグ実行）
![デバッグ実行](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/366d2f54-3cc7-6229-0b77-a446f2fec202.png "デバッグ実行")

結果確認
![結果確認１](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/cc3e7c6d-eade-83a5-4e94-d353b28dc7cd.png "結果確認１")

終了条件
![終了条件](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517374/4071a261-609f-5fd2-2778-14a5bb0ea192.png "終了条件")
⇒test2ユーザが追加されており、終了条件を満たしていることを確認。


以上