IM-Workflowでのワークフロー開発
IM-Workflowでのプロコード開発は、独自の画面や処理をプログラミングし、APIを通じてワークフローエンジンと連携させる開発手法です。業務テンプレートの制約を受けず、要件に応じた画面レイアウトや業務ロジックを柔軟に実装できるため、複雑な業務ロジックや内外のシステムと統合したワークフローアプリケーションの開発に適しています。
ワークフロー開発の基礎で説明した3つの定義（ルート定義・コンテンツ定義・フロー定義）は自動生成されないため、管理画面で作成します。画面やプログラムをコンテンツ定義に登録し、フロー定義でルート定義と組み合わせてワークフローを完成させます。そのため、事前に3つの定義の役割と関係を把握しておく必要があります。未読の場合は、基礎を先に確認してください。
このページでは、プロコード開発の位置づけやスクリプト開発モデルの全体像を説明します。開発の具体的な流れやつまずきやすいポイントについては、後続のページを参照してください。
ワークフロー開発の流れ
IM-Workflowを使ったスクリプト開発モデルによるワークフロー開発の流れを説明します。
つまずきやすいポイント
スクリプト開発モデルで画面やユーザプログラムを実装するとき、画面種別やアクション処理の仕様によって、想定と異なる動作やエラーの原因になることがあります。
プロコード開発の位置づけ
intra-martのワークフローには3つの開発パターンがあり、画面とロジックを独自に実装してワークフローAPIで連携する手法がパターン3（独自開発＋IM-Workflow）です。
申請・承認が中心で台帳・マスタ管理が不要な場合はIM-BIS、データ管理機能と承認プロセスをセットで素早く構築したい場合はAccel Studioが適しています。一方、業務テンプレートの構成にとらわれない独自の画面・ロジックが必要な場合や、内外の複数システムを統合するような要件では、プロコードによるスクラッチ開発を選択します。
独自開発の手段には、スクリプト開発モデル、JavaEE開発モデル、URL指定などがあります。このガイドのプロコード開発では、スクリプト開発モデル（JSSP）によるスクラッチ開発を中心に解説します。
スクリプト開発モデルとJavaEE開発モデル
プロコード開発で画面や業務ロジックを独自に作成する場合、おもに「スクリプト開発モデル」と「JavaEE開発モデル」の2つの手法があります。スクリプト開発モデルではJavaScriptを、JavaEE開発モデルではJavaを使って画面や処理を実装します。
画面をコンテンツ定義に登録するときは、開発モデルに応じてパス種別と登録項目が異なります。
| 項目 | スクリプト開発モデル | JavaEE開発モデル |
|---|---|---|
| 画面のパス種別 | スクリプト開発モデル | JavaEE開発モデル |
| 実装言語 | JavaScript | Java |
| 画面の登録項目 | スクリプトパス | アプリケーションIDとサービスID |
スクリプト開発モデルでは、コンテンツ定義のパス種別に「スクリプト開発モデル」を選択し、ソースディレクトリ（既定はWEB-INF/jssp/src）からの相対パスを拡張子なしで指定します。JavaEE開発モデルでは、ルーティングに対応するアプリケーションIDとサービスIDを指定します。
- 画面呼び出し時に渡されるリクエストパラメータの取得方法も開発モデルごとに異なります。画面呼び出し時のリクエストパラメータ
- コンテンツ定義のパス種別設定と実際の実装が一致していないと、ワークフロー実行時に画面を呼び出せないため注意が必要です。画面定義（仕様書）、コンテンツ定義を登録・設定する（管理者操作ガイド）
- パス種別には「URL指定」もあり、TERASOLUNA Server Framework for Java（5.x）やIM-BloomMakerの画面を利用する場合に指定しますが、このガイドのスクラッチ開発では扱いません。
- ユーザプログラムの登録では、画面のようなパス種別ではなく、プラグイン種類としてスクリプト開発モデルまたはJavaEE開発モデルを選択します。
スクリプト開発モデルの全体像
スクリプト開発モデルによるプロコード開発では、開発者が作成するソースコードやデータベーステーブルと、IM-Workflowの管理画面で設定する各種定義を手動で紐づけてワークフローを構築します。Accel StudioやIM-BISのような定義の自動生成ウィザードはないため、それぞれの成果物の役割と配置場所を把握しておく必要があります。
成果物と配置場所、およびIM-Workflow定義への登録先の対応関係は以下のとおりです。
| 成果物 | 置く場所 | 登録先 |
|---|---|---|
| ユーザコンテンツ画面 | JSSP（WEB-INF/jssp/src） | コンテンツ定義の画面に登録する（パス種別「スクリプト開発モデル」） |
| ユーザプログラム | JSSP（WEB-INF/jssp/src） | コンテンツ定義のユーザプログラムに登録する |
| 業務テーブル／マスタ | アプリ側DB（任意、サンプルはsample_imw_t_purchase） | IM-Workflowの定義には載せない（ユーザデータIDで案件と結ぶ） |
| 案件プロパティ定義 | 管理画面の案件プロパティ定義 | コンテンツ定義やフロー定義で参照する |
| ルート定義 | 管理画面のルート定義 | フロー定義でコンテンツ定義と組み合わせる |
| フロー定義 | 管理画面のフロー定義 | ルート定義とコンテンツ定義を組み合わせ、各ノードへ画面とユーザプログラムを割り当てる |
画面（HTML/JS）やユーザプログラムは、サーバのWEB-INF/jssp/src配下に配置してコンテンツ定義へ登録します。登録した画面や処理をフロー定義の各ノードへ割り当てることで、申請一覧から画面を開いたり、申請・承認などの処理時にプログラムを呼び出したりできるようになります。コンテンツ定義へ登録していない画面やプログラムはフロー定義に組み込めないため、配置と登録のもれに注意してください。
- スクリプト開発モデルで新規に画面を実装する場合は、標準処理画面ではなくワークフロー処理モーダルを利用します。つまずきやすいポイント
- 業務テーブルなどのデータベースはアプリケーション側で任意に用意し、後述するユーザデータIDによって案件と紐づけます。画面やプログラムの実装から動作確認までの一連の手順は、ワークフロー開発の流れを参照してください。
3つのIDと案件プロパティ
独自開発の画面や業務データとIM-Workflowを連携させるには、案件を識別・管理するための「3つのID」と、案件ごとの付加情報を保持する「案件プロパティ」の役割を理解しておく必要があります。
ワークフロー上で扱われる主要なIDには、以下の3つがあります。ユーザアプリケーションとIM-Workflowの関係（プログラミングガイド）、案件とユーザコンテンツの関係（仕様書）
- システム案件ID：IM-Workflow内部で案件を一意に識別するキーです。ワークフローエンジンが自動で採番し、外部からは指定できません。APIや処理画面のコンテキストで案件を特定する用途で使われ、画面上に表示されることはありません。
- ユーザデータID：業務アプリケーション側のデータとワークフローの案件を1対1で結びつけるキーです。アプリケーション側で採番するか既存の業務IDを使い、申請または起票時にAPIやタグライブラリの引数として渡すか、省略してテナントのユーザデータID設定方式に委ねて自動生成します。システム案件IDと同様に画面には表示されず、連携用キーとして機能します。
- 案件番号：申請者や承認者が画面や帳票上で案件を識別するための業務用の番号です。ワークフロー側に保存・管理されます。標準の連番採番を利用できるほか、独自の採番ルールがある場合は申請系アクション処理の返却オブジェクト（
data）で任意の番号を設定できます。
開発時において特に注意が必要な点は、画面種別ごとのパラメータの違いです。申請一覧から開く新規申請では、案件が未開始のためシステム案件ID（imwSystemMatterId）はなく、ユーザデータIDも未確定のためimwUserDataIdもありません。処理画面や確認画面と同じ前提でこれらのパラメータを参照しようとすると、スクリプトエラーの原因になります。
一方、案件プロパティはIDではなく、案件単位でIM-Workflowに保存できるキーと値のデータです。ワークフローのAPIを通じて任意のタイミングで登録・取得できます。案件プロパティ（仕様書）
- 事前に管理画面の「案件プロパティ定義」へキーを登録しておくと、案件を一覧表示する画面（未処理一覧や案件一覧など）の表示項目、ルール定義による分岐条件の判定値、通知メッセージの置換文字列として利用できます。分岐開始処理から参照する方法は、ワークフロー開発の流れを参照してください。
- 申請画面におけるユーザデータIDの具体的な渡しかたや、独自案件番号の設定手順、案件プロパティの活用方法などは、ワークフロー開発の流れおよびつまずきやすいポイントを参照してください。