Accel Studioは、intra-martのローコード開発プラットフォームです。ワークフロー用に最適化された業務テンプレートによって、ワークフロー開発に必要なデータ・画面・ロジックなどの定義・連携がそろった状態で開始できます。データ管理機能と承認プロセスを組み合わせた業務アプリケーションの開発に適しています。
ワークフロー開発の基礎で説明した3つの定義（ルート定義・コンテンツ定義・フロー定義）は、テンプレートを選んだ時点で自動的に生成されます。テンプレートが用意したリソースに対して、業務要件に合わせた調整を加える形で開発を進めることができます。
Accel Studioの開発ステップ
ワークフロー開発の基礎では、IM-Workflowでワークフローを構築する手順を紹介しました。Accel Studioでは、次の5ステップでワークフロー開発を進めます。
ステップ1でテンプレートを選んだ時点で、ワークフローに必要なリソースが一式そろいます。ステップ2以降は、自動生成されたリソースを業務要件に合わせて調整する作業が中心です。必要に応じてステップを繰り返します。
※ステップ2・3・5については、関連ドキュメントで詳しく解説されているため、このページでは概要や補足情報のみ扱います。
テンプレート選択からアプリケーション作成までの操作の詳細については、以下のドキュメントを参照してください。
Accel Studioが自動で行うこと
Accel Studioでワークフローを開発するには、シンプルなワークフロー（imds）テンプレートを選択してアプリケーションを作成します。
このテンプレートは、ワークフロー開発に必要なリソースを自動生成し、相互に紐づける役割をもちます。「空のアプリケーション」などほかのテンプレートでは、ワークフロー開発に必要なリソースが生成されないため、利用できません。
| 自動生成されるリソース | 説明 |
|---|
| ワークフロー定義 | ルート定義・コンテンツ定義・フロー定義のセット |
| 画面コンテンツ | 申請画面・承認画面の雛形 |
| 画面URL | ワークフローアプリのルーティング設定 |
| ロジックフロー | 申請内容や状態をデータベーステーブルに登録・更新する処理 |
| エンティティ | エンティティ自体や対応するテーブル |
既存アプリケーションへワークフロー機能を追加するには
以下のいずれかの方法があります。
- 別途「シンプルなワークフロー（imds）」テンプレートでワークフロー用のアプリケーションを新規作成し、公開URLを利用したアプリケーション連携で既存アプリと連携させる
- 既存アプリケーションの管理画面メニューで、リソースを追加＞テンプレートからリソース追加をクリックし、シンプルなワークフロー（imds） テンプレートを選んでワークフローのリソースを追加する
ステップ1：テンプレートからアプリを作成
Accel Studioのワークフロー向けテンプレートからアプリケーションを新規作成します。テンプレートの選択、アプリケーション情報の入力、データ定義の登録、ワークフロー情報の入力までを一連の操作で行います。
テンプレートの選択
Accel Studioでアプリケーションの新規作成時、または業務テンプレート一覧のベーステンプレートからシンプルなワークフロー（imds） を選択します。
※選択したテンプレートは、アプリケーション作成後に変更できません。ワークフロー機能を利用する場合は、最初の操作として必ずこのテンプレートを選択してください。
設定項目
設定項目の概要を記載しています。必須の設定項目や、あとから変更可能な項目の情報を確認できます。
テンプレートの概要や設定の詳細については、以下のドキュメントを参照してください。
アプリケーション情報
アプリケーションを識別する基本情報を入力します。
| 設定項目 | 説明 | 必須 | 変更可能 |
|---|
| アプリケーションID | アプリケーションを一意に識別する文字列 | ✅ | |
| アプリケーション名 | メニューなどに表示される名称 | ✅ | ✅ |
| 説明 | アプリケーションの用途や概要 | | ✅ |
扱うデータの定義
ワークフローで扱うデータの構造を、IM-Repositoryのエンティティとして定義します。ここで定義した内容は、データベーステーブル・登録処理・申請画面のフィールドに反映されます。
この時点では入力フィールドのみに絞って設定することをおすすめします。設定した項目から入力フィールドを含む画面コンテンツが自動生成されます。
| 設定項目 | 説明 | 必須 | 変更可能 |
|---|
| エンティティ名 | データの単位を表す名称（例：「経費申請」） | ✅ | ✅ |
| エンティティに紐づくテーブル名 | データベース上の物理テーブル名 | ✅ | |
| デフォルトカテゴリの設定 | エンティティ・辞書項目が属するカテゴリ | ✅ | ✅ |
| 辞書項目 | エンティティに含まれる辞書項目（型・必須・桁数など） | ✅ | ✅ |
- 外部データベースを使用しない場合、詳細に設定するは無効のままをおすすめします。
- すでにほかのアプリケーションで利用しているIM-Repositoryのエンティティを、再利用することもできます。共通のマスタデータを扱う場合などに活用できます。
- 多言語対応が必要な場合、事前にIM-Repositoryで辞書項目を作成する必要があります。この画面では標準ロケールのみ登録できます。
- このとき、辞書項目のDatabaseのデータ型に「TIME」（時刻）「DATETIME」（日時）「BINARY」（バイナリ）を設定することや、エイリアスを使用できないことに注意してください。
明細データの利用指定
サブエンティティを使用する場合に、サブエンティティの数を設定します。
選択した数に応じて、扱う明細データの定義1～5を設定します。
ワークフロー情報の入力
| 設定項目 | 説明 | 必須 | 変更可能 |
|---|
| ルート作成方法 | ルートを新規作成するか、既存ルートをコピーして作成するかを選択 | ✅ | |
| 利用開始日 | ワークフローの利用開始日 | ✅ | ✅ |
| 処理対象者の設定 | 申請・承認操作のユーザ・ロールを指定 | | ✅ |
| IM-Workflow資材の設定 | ワークフローのリソースIDを指定。通常、手動設定は不要です。 | | |
| 添付ファイル設定 | 添付ファイルの利用有無 | | ✅ |
| 承認時の添付ファイル設定 | 承認時の添付ファイルの利用有無 | | ✅ |
その他情報の指定
ステップ2：データ定義の調整
ステップ1で登録したデータ定義は、エンティティ（IM-Repository）で追加・変更できます。具体的には、申請項目（辞書項目）の追加・変更や、既存エンティティとの関連付け（サブエンティティ設定を含む）などを行います。
調整時の注意事項
- エンティティの変更は、データベーステーブルやロジックフローに自動反映されます。一方、申請画面・承認画面には自動反映されません。画面側の調整はステップ3で行います。
- 辞書項目の作成時に、JavaScriptやIM-LogicDesignerなどのデータ型と変数名を統一して定義します。定義に不一致があると、アプリケーション作成時や後続処理でエラーの原因になります。
- 辞書項目のDatabaseのデータ型に「TIME」「DATETIME」「BINARY」を設定することや、エイリアスを使用することはできません。
- 運用中に項目を追加する場合は、既存データへの影響に注意してください。すでに登録済みのレコードがあるときは、追加項目にNULLを許可するか、デフォルト値の設定を検討してください。
ユーザデータIDは変更しない
「ユーザデータID」は、ワークフローの案件とアプリケーションデータを紐づける連携キーです。メインエンティティとサブエンティティの両方が、この項目を主キーに含みます。変更すると既存案件との紐付けが失われ、ワークフローが正常に動作しなくなります。
ステップ3：画面の作成・修正
ステップ1で登録したデータ定義の内容をもとに、申請画面・承認画面が画面コンテンツとして自動生成されます。ステップ3では、この画面コンテンツ（IM-BloomMaker）を業務要件に合わせて修正します。フィールドの追加・配置の変更、入力チェック・表示制御の調整などがおもな作業です。
なお、このステップで扱うのは画面内部の作り込みです。どの場面でどの画面を表示するか（画面の割り当て）は、ステップ4のフロー設定で扱います。
画面エレメントの追加・配置やプロパティ設定などの、画面コンテンツ編集の概要や操作手順の詳細については、以下のドキュメントを参照してください。
画面コンテンツの仕様を理解する
まずは修正を始める前に、生成された画面コンテンツの仕様を理解します。テンプレートが生成した申請・承認画面は、実体としてはひとつの画面コンテンツです。申請・処理・確認それぞれで別の画面コンテンツを作るのではなく、ひとつの画面コンテンツで利用される場面（役割）に応じて見た目と振る舞いを変える仕組みになっています。
たとえば申請画面ではフィールドを入力欄として表示し、承認画面では入力済みの内容を読み取り専用で表示して承認コメント欄を追加する、といった要件があるとします。これをひとつの画面定義に条件分岐を組み込み、場面ごとに表示・処理を切り替えることで、それぞれの画面制御を実現します。
これらの仕組みの概要については、以下のドキュメントを参照してください。マスタメンテナンステンプレートを例にしていますが、シンプルなワークフローテンプレートでも同様です。
役割ごとに画面コンテンツを分けると、項目をひとつ追加するたびに関連する画面を修正する必要が生じ、画面間で表示の食い違いが発生するリスクがあります。ひとつの画面定義に表示・制御をまとめれば、修正箇所が一元化され、項目の追加や変更があっても画面全体へ一貫して反映できます。
画面種別の判定方法
画面が「今どの役割で表示されているか」を判定するには、次の2つの要素を使います。
$input.imwPageType：IM-Workflowが画面へ遷移する際に、リクエストパラメータとして渡す画面種別の数値です。画面コンテンツは、これを入力変数として受け取ります。たとえば申請画面なら0、処理画面なら4が渡されます。$constant.PAGE_TYPE：画面種別の数値を、可読な名前で参照するための定数（マップ）です。$constant.PAGE_TYPE.APPLY（申請画面）が0を、$constant.PAGE_TYPE.PROCESS（処理画面）が4を表します。
条件分岐は、この2つを組み合わせて記述します。たとえば「申請画面のときだけ」という場合は、= $input.imwPageType == $constant.PAGE_TYPE.APPLYを該当エレメントの表示/非表示プロパティに条件式を設定します。
条件式では= $input.imwPageType == 0のように数値を直接書かず、= $input.imwPageType == $constant.PAGE_TYPE.APPLYと定数名で記述することをおすすめします。数値の直書きは、式が何を意図しているか読み取りにくく、誤りの原因になります。
画面種別の一覧
$constant.PAGE_TYPEで参照できる画面種別は、次のとおりです。
| 定数 | 数値 | 画面種別 | おもな利用シーン |
|---|
APPLY | 0 | 申請 | 新規申請の起票 |
TEMP_SAVE | 1 | 一時保存 | 一時保存中の案件の再開 |
APPLY_FROM_UNAPPLY | 2 | 起票案件からの申請 | 起票済み案件からの申請 |
RE_APPLY | 3 | 再申請 | 差戻し後の再申請 |
PROCESS | 4 | 処理 | 承認者による承認・否認・差戻し |
CONFIRM | 5 | 確認 | 確認者による確認 |
PROCESS_DETAIL | 6 | 処理詳細 | 処理済み案件の詳細参照 |
REFER_DETAIL | 7 | 参照詳細 | 参照専用の詳細表示 |
CONFIRM_DETAIL | 8 | 確認詳細 | 確認済み案件の詳細表示 |
ARCHIVE_MATTER_DETAIL | 9 | 過去案件詳細 | アーカイブ済み案件の詳細参照 |
なお、申請から確認までの操作画面には、別途スマートフォン用の画面種別が用意されています。末尾に_SPが付いた値（APPLY_SP〜CONFIRM_SP、数値は10〜15）が渡されます。参照用の詳細画面（数値6〜9）についてはスマートフォン専用の画面種別がありません。
申請画面の種別はAPPLYだけではありません。一時保存（TEMP_SAVE）、起票案件からの申請（APPLY_FROM_UNAPPLY）、および再申請（RE_APPLY）も申請系です。承認コメント欄の非表示など、申請系のすべてを対象にしたい制御では、条件式でこれらの種別をもれなく指定してください。!= $constant.PAGE_TYPE.APPLYだけでは、再申請や一時保存の画面で意図しない表示になる場合があります。
※複数の画面種別を対象にする場合は、= $input.imwPageType == $constant.PAGE_TYPE.PROCESS || $input.imwPageType == $constant.PAGE_TYPE.PROCESS_SPのように条件式を設定します。
画面種別による制御パターン
画面種別の判定は、おもに以下のような場面で使います。いずれも、画面エレメントのプロパティやアクションの実行条件に設定して制御します。
| 制御 | 内容 | 制御方法の例 |
|---|
| 表示／非表示の切り替え | 承認コメント欄を申請画面では非表示にする | 表示/非表示プロパティに条件式を設定 |
| 読み取り専用（readonly）への切り替え | 処理画面以外では入力欄を読み取り専用にする | readonlyプロパティに条件式を設定 |
| 初期値の自動設定 | 申請画面のときだけ申請日などを自動入力する | 1. 初期表示時アクションで画面変数に現在の日付を入れる
2. 自動入力したいエレメントのvalueプロパティに画面変数を割り当てる |
制御パターンの一連の操作手順については以下のドキュメントを参照してください。
ステップ4：ワークフローの編集
テンプレートが生成したワークフロー定義を業務要件に合わせて修正します。直線的な承認経路（申請者 → 承認者 → 完了）が設定されているので、分岐や追加ノードを組み立てます。
ルート編集
テンプレートが用意した初期ルートをもとに、業務に合わせて経路を組み立てます。ワークフロー定義上のルート編集ボタンから操作します。
- 既存ノード間の接続線を削除する
- 必要なノードを画面左のノードパネルから追加する
- ノードを線で接続して新しい経路を組み立てる
- 各ノードの処理対象者を設定する
配置できるノードの種類や仕様は、IM-Workflowと同等です。詳細はワークフロー開発の基礎のルート定義とルートの設計の説明を参照してください。
フロー設定
フロー全体に関わる設定をフロー設定で行います。フロー設定は、基本情報・ノード標準設定・詳細設定・参照者設定の4つのタブに分かれています。ワークフロー定義を開いた直後またはノードの背景エリアをクリックしたときに表示される、画面右のフロー設定パネルで設定できます。
基本情報
案件の詳細を参照する画面、案件の進行に合わせて実行する処理、案件に関する通知を設定できます。
画面・処理・通知のいずれも、テンプレートが生成した初期状態のままでワークフローは動作します。独自の画面に差し替えたい、ライフサイクル処理や通知を追加・変更したい、といった場合に設定します。
画面
案件の詳細を参照する画面を、利用者の役割ごとに公開URLで指定します。※PC・スマートフォン兼用
| 画面種別 | 用途 |
|---|
| 処理詳細 | 処理対象者が案件の詳細を参照する画面 |
| 確認詳細 | 確認対象者が案件の詳細を参照する画面 |
| 参照詳細 | 参照者が案件の詳細を参照する画面 |
| 過去案件詳細 | アーカイブされた過去案件の詳細を参照する画面 |
処理
案件の開始・終了・削除など、案件全体の節目で自動実行する処理（ロジックフローなど）を設定します。データの初期化や外部システム連携など、標準機能だけでは足りない処理を組み込みたい場合に使用します。
| 設定項目 | 実行されるタイミング |
|---|
| 案件開始処理 | 案件が申請され、開始されるとき |
| 案件終了処理 | 案件が終了するとき |
| 案件終了処理（トランザクションなし） | 案件終了時（案件処理とは独立した処理として実行） |
| 案件退避処理 | 完了した案件をアーカイブするとき |
| 未完了案件削除処理 | 未完了の案件を削除するとき |
| 完了案件削除処理 | 完了した案件を削除するとき |
| 過去案件削除処理 | アーカイブ済みの過去案件を削除するとき |
「トランザクション」とは、複数の処理を「すべて成功」か「すべて取り消し」のどちらかに揃える仕組みです。案件終了処理は案件処理と同じトランザクションで実行され、途中で失敗すると案件処理もともに取り消されます。一方、案件終了処理（トランザクションなし） は独立して実行されるため、案件処理の成否に影響されません。
通知
案件の節目で、関係者に送る通知を設定します。
| 設定項目 | 通知の内容 |
|---|
| 最終結果通知 | 案件の最終結果を申請者に通知 |
| 参照依頼 | 参照者に案件の参照を依頼 |
| 振替通知 | 処理者の振替が行われたことを通知 |
| 自動催促 | 処理が滞留した際に処理対象者へ催促を通知 |
| 根回し | 処理対象者より前の段階で、事前に関係者へ通知 |
リンク先は以下くらいしかない？機能利用のヒントになるドキュメントとしては厳しい印象
ノード標準設定
各ノードに適用する画面・処理・通知の標準設定ができます。ここで設定した内容が、ルート上の各ノードの初期値になります。
| セクション | 設定する内容 |
|---|
| 画面 | 申請・処理・確認などの操作で表示する画面。PC用とスマートフォン用を個別に指定できます。 |
| 処理 | 申請・承認・システム・終了など、各タイミングで実行するロジックフロー（アクション処理・ノード到達処理） |
| 通知 | 処理対象者への処理依頼、確認対象者への確認依頼の通知設定 |
ノードごとに個別の設定が必要な場合は、各ノードのノード情報設定で上書きできます。
リンク先は以下くらいしかない？機能利用のヒントになるドキュメントとしては厳しい印象
詳細設定
フロー全体に適用する機能の有効・無効や、ノードのデフォルト動作を設定できます。
| 設定項目 | 内容 |
|---|
| カレンダー設定 | 処理期限・催促期限の日数カウントに使用するカレンダー定義 |
| ファイル添付 | 案件へのファイル添付を許可するかどうか |
| 一括確認 | 複数の案件をまとめて確認する操作を許可するかどうか |
| 完了した案件の確認 | 完了後の案件に確認コメントの登録を許可するかどうか |
| 対象者を展開する日 | 処理対象者・確認対象者を展開する基準日（「申請基準日」または「システム日」） |
| ノードのデフォルト設定 | 新規ノードに適用する一括処理・自動処理・自動催促の初期値 |
「対象者を展開する日」は、ノードに到達したときに誰を処理対象者とするかを決める基準日です。組織変更や異動があり得る運用では、案件の動作に影響するため設定内容に注意してください。
リンク先は以下くらいしかない？機能利用のヒントになるドキュメントとしては厳しい印象
参照者設定
申請者・処理対象者以外で、案件を参照できるユーザやグループを登録できます。
参照者には、案件を閲覧する権限に加えて、必要に応じて操作権限（保留解除、ノードの処理・確認対象者の変更など）を付与できます。
参照者設定の変更は、すでに申請・起票済みの案件には反映されません。申請時点の設定が適用されます。
リンク先は以下くらいしかない？機能利用のヒントになるドキュメントとしては厳しい印象
ノード設定
個別ノードに関わる設定を、ノードを選択して表示される画面右のノード設定パネルで行います。フロー設定で行った標準設定をノードごとに上書きすることや、ノード固有の設定ができます。
ステップ5：認可設定
ステップ5では、アプリケーションを利用できるユーザを認可設定します。作成したワークフローアプリ画面へのアクセスを、ユーザ・組織・ロール単位で許可します。
作成直後は、テナント管理者ロールとAccel Studio管理者ロールだけに許可が設定されています。任意のユーザに利用を許可するには、ここで認可を変更します。
認可設定と処理対象者の設定について
ワークフローを利用できるようにするには、次の2つの設定が必要です。
- 認可設定（ステップ5）
アプリケーション画面へのアクセス権を、ユーザ・組織・ロール単位で許可します。
- 処理対象者の設定（ステップ1「ワークフロー情報の入力」、ステップ4「ルート編集」）
誰が申請・承認できるかを決めます。申請対象者に指定したユーザ・ロールの「申請一覧」にワークフローが表示され、申請できるようになります。
どちらか一方だけでは、対象ユーザがワークフローを利用できないことがあります。両方を設定してください。
Accel Studioでの開発における注意点
Accel Studioは複数のローコード製品を組み合わせて開発を簡略化しますが、その仕組みによる制約があります。
テンプレートが生成した定義はAccel Studioから管理する
Accel Studioで作成したアプリケーションは、Accel Studioのアプリケーション管理画面から編集してください。テンプレートが生成したワークフロー定義（ルート定義・コンテンツ定義・フロー定義）を、IM-Workflow側の管理画面から直接変更すると、Accel Studio側との整合性が失われ、正常に動作しなくなる可能性があります。
データ定義や画面についても同様で、IM-RepositoryやIM-BloomMakerの管理画面から直接変更するのではなく、Accel Studio経由で編集することをおすすめします。
IM-Workflowの管理画面には「ユーザプログラムの追加」など、Accel Studio側にはない高度な設定項目があります。これらを利用する場合は、Accel Studioが自動設定した処理との整合性に十分注意してください。
バージョン管理
Accel Studioでは、アプリケーション単位でバージョン管理をします。ワークフロー定義のバージョンも、アプリケーションのバージョンに連動します。
ルートだけ、画面だけ、といった個別のバージョン管理はできません。変更が必要な場合は、アプリケーション全体で新しいバージョンを作成してください。
Accel Studioが向かないケース
以下のような要件がある場合は、Accel Studioでの開発が適さないことがあります。ほかの開発手法の活用や組み合わせを検討しましょう。
| 要件 | 理由 | 代替手段 |
|---|
| 申請・承認フローのみで完結し、データ管理は不要 | テンプレートが生成するデータベーステーブル・データ操作処理が活かしきれない | IM-BISのほうがシンプルに構築可能 |
| テンプレートの構成にとらわれない、独自の業務ロジックを組み込みたい | テンプレートが定めるリソース構成が前提となる | IM-Workflowを直接利用した独自開発 |
