ワークフロー開発の流れ - IM-Workflow

IM-Workflowを使ったスクリプト開発モデルによるワークフロー開発の流れを説明します。

スクリプト開発モデルでは、画面作成から動作確認までを次の順で進めます。

画面・ユーザプログラムをプロコード開発する
コンテンツ定義で作成したソースコードを紐づける
ルート定義で承認ルートを作成する
フロー定義でコンテンツ定義とルート定義を紐づける
申請一覧から動作確認する

※Accel StudioやIM-BISには、画面・処理・3つの定義の作成を支援するテンプレートや画面ウィザードがありますが、IM-Workflowにはありません。

ここでは、IM-Workflowの購入申請（物品購買）サンプルを使って開発の流れを説明しています。

intra-mart管理画面上の構成

システム管理者がサンプルデータセットアップ済みの場合、intra-martメニューのWorkflow＞申請一覧＞フローにサンプルワークフローの一覧が表示されます。

直線ルート[処理モーダル] の場合、関連するフロー・ルート・コンテンツ定義は以下の図のとおりです。

フロー定義flow_modal_01、コンテンツ定義contents_modal、ルート定義route_sample_01、申請一覧。直線ルートの処理モーダルの定義対応

サンプルコードの構成

サンプルコードで、基本的な画面種別・アクション処理・案件プロパティ・分岐の対応を学習できる構成になっています。

スクリプトはWEB-INF/jssp/src配下に置きます。購入申請サンプルの相対パスはsample/im_workflow/purchase/です。
sample/im_workflow/template/は、ユーザプログラム・リスナごとのテンプレートです。新規作成時に複製利用できます。

サンプルコードのおもな構成は次のとおりです。

パス	役割
`screen_modal/`	処理モーダル／CSJS APIで実装した画面（新規実装時の推奨）
`screen/`	標準処理画面（`workflowOpenPage`タグ）で実装した画面（旧来実装の参考用）
`action/`	アクション処理、案件終了処理、分岐開始処理
`common.js`	業務テーブル`sample_imw_t_purchase`の参照・登録・更新・削除

※screen_modal/とscreen/は、画面呼び出し方法だけが違います。入力項目と、action/へ渡すユーザパラメータの役割は同じです。このページでは画面呼び出し方法を処理モーダルの前提で説明しています。

モジュールの構成

サンプルコード上の各モジュールの関係とフローは次のとおりです。申請と処理では、画面・アクション処理・データの関係とフローがそれぞれ異なります。処理画面は参照が中心です。

申請画面
処理画面

申請画面の入力をoptionalParameter.userParameterに載せてアクション処理に渡す
アクション処理が、業務テーブルと案件プロパティへ値を分けて書き込む

ActionProcess1〜ActionProcess2は、申請ノードに登録した順で実行されます。画面入力をテーブルと案件プロパティへ分ける
- ActionProcess1により、テーブルへ書き込まれる
- ActionProcess2により、案件プロパティitem_totalへ書き込まれる

imwUserDataIdをキーに、common.jsのgetPurchaseDataでテーブルを読み、品名などを処理画面に表示する
承認ボタンのイベントでimWorkflow.modal.showProcessを呼ぶ

申請と処理以外のモジュール：

RuleCondition1〜RuleCondition3は分岐開始処理で、テーブルの合計で分岐します。画面入力をテーブルと案件プロパティへ分ける
MatterEndProcessは、案件終了時に終了フラグを更新します。MatterStartProcessは空処理です。
確認と詳細は参照用の画面です。確認・詳細画面：comfirm/detail

注意

screen/は標準処理画面の旧来実装です。新規実装では、screen_modal/と同じ処理モーダルとCSJS APIを使ってください。2020 Summer以降、workflowOpenPageタグに機能追加の予定はありません。

備考

サンプルの詳細は、サンプルプログラム（プログラミングガイド）を参照してください。参照先の例は、標準処理画面（screen/）が中心であることに注意してください。

前提条件

以下を準備してから、以降の手順に進みます。

開発環境とテナントで、IM-Workflowとスクリプト開発モデルが利用できること
スクリプトをWEB-INF/jssp/src配下に配置できること
業務テーブル（サンプルならsample_imw_t_purchase）を用意できること
サンプルデータセットアップが済んでいること
案件プロパティを使う場合、案件プロパティ定義を登録できること（サンプルならitem_total）

開発ステップ

定義の登録より先に、画面とユーザプログラムを実装します。定義の登録後、申請一覧から動作を確認します。

ステップ1：画面を作成する

まずは申請と処理の画面を先に用意します。申請一覧から案件を起こし、案件一覧で案件を承認するには、この2画面が最低限必要です。そのあとに、一時保存・再申請・確認・詳細などを作成します。

優先	種別の例
1	申請、処理
2	一時保存、再申請、確認、詳細（処理詳細など）

※一時保存は途中保存、再申請は差戻し後の再投入で使います。確認と詳細は、案件の参照用です。

リクエストパラメータ（画面を開いたときのコンテキスト）の取得

スクリプト開発モデルでは、画面を開いたときのコンテキストを、ユーザコンテンツ画面のスクリプトで取得できます。

IM-Workflowは、申請一覧や案件一覧からユーザコンテンツ画面をリクエストパラメータ付きで呼び出します。画面スクリプトのinit(request)で受け取ります。

リクエストパラメータは、画面種別や案件、フローなどのIDを知るための値です。よく使うパラメータは次のとおりです。

パラメータ	役割
`imwPageType`	現在の画面種別。例：申請は`0`
`imwUserDataId`	業務データと案件を結ぶID。申請ではリクエストにないので生成する。処理などではリクエストで受け取る
`imwOriginalUserDataId`	コピー新規で申請画面を開いたときに渡される、コピー元案件のユーザデータID
`imwSystemMatterId`	システム案件ID。処理や確認の画面で受け取る。申請画面では不要
`imwFlowId`	フローID。申請一覧から開く申請では自動で付く
`imwNodeId`	処理対象のノードID
`imwAuthUserCode`	処理権限者のコード。代理時は代理元。複数時は配列
`imwApplyBaseDate`	申請基準日（`yyyy/mm/dd`）
`imwCallOriginalPagePath`	呼出元のページパス
`imwCallOriginalParams`	呼出元ページのパラメータ

画面作成の流れ

はじめてIM-Workflowで画面開発をする場合サンプルで入力と送信の流れを確認する
処理モーダルで画面を実装する

サンプルで入力と送信の流れを確認する

購入申請サンプルの処理モーダル実装はscreen_modal/にあります。画面種別とファイルの対応は次のとおりです。

画面種別	ファイル
申請（一時保存・起票・再申請を含む）	`screen_modal/apply`
処理	`screen_modal/approve`
確認	`screen_modal/confirm`
詳細	`screen_modal/detail`

申請画面：`apply`

申請一覧から申請画面を開くと、screen_modal/applyが動きます。入力からアクション処理までの流れは次のとおりです。

apply.jsのinit(request)が、リクエストパラメータを$dataへコピーする
imwPageTypeが0（申請）の場合、Identifier.get()でユーザデータIDを生成するユーザデータIDの概要
imwPageTypeが0で、コピー新規による申請（imwOriginalUserDataIdがある）の場合、setPurchaseData(imwOriginalUserDataId)でコピー元の品目を$itemに読む

コピー新規ではない場合（imwOriginalUserDataIdがない）は、テーブルを読まず、初期値を$itemに入れる

imwPageTypeが2（起票案件からの申請）の場合は何もしない。0でも2でもない場合はsetPurchaseData($data.imwUserDataId)でテーブルを読む
apply.htmlが、品名・数量・単価・コメントの入力欄を描画する
申請ボタンのハンドラで入力を検証し、通ればimWorkflow.modal.showApplyを呼び、入力値をoptionalParameter.userParameterに載せる処理モーダルで画面を実装する
モーダルで申請を確定すると、アクション処理へ渡る

備考

アクション処理への受け渡し

手順6で入力したuserParameterは、ActionProcess1とActionProcess2の両方へ渡されます。実行順はコンテンツ定義の「実行順番」で決まります。コンテンツ定義を登録・設定する（管理者操作ガイド）

合計金額の書き込み

合計のitem_totalは画面のキーではなく、アクション処理が書き込みます。テーブルと案件プロパティへの書き分けは、画面入力をテーブルと案件プロパティへ分けるを参照してください。

処理画面：`approve`

処理画面ではimwUserDataIdでテーブルを読んで品名などを表示し、承認ボタンでimWorkflow.modal.showProcessを呼びます。

処理コメントは処理モーダルが提供する標準機能であり、入力値もIM-Workflow側で保持されます。画面側に入力欄を用意したり、スクリプトから渡したりする必要はありません。なお、購入申請サンプルではinterfaceControl.processComment.displayをfalseに設定し、処理モーダル上のコメント欄を非表示にしています。
サンプルの処理画面は申請内容の確認専用であり、独自データを更新しません。そのため、showProcessの引数optionalParameterを空にします。申請画面のようなuserParameterは載せません。
アクション処理のapproveでもテーブルや案件プロパティを更新しません。詳細は画面入力をテーブルと案件プロパティへ分けるの処理ノードでの更新制御を参照してください。

確認・詳細画面：`comfirm`/`detail`

確認画面と詳細画面はどちらもimwUserDataIdでテーブルを読み、品名などを表示します。

※確認画面ではimWorkflow.modal.showConfirmを呼び、詳細画面では処理モーダルも確認モーダルも呼びません。

処理モーダルで画面を実装する

処理モーダルは、申請や承認などのワークフロー処理を行うモーダル画面です。開発モデルによらず、CSJS APIから呼び出します。

apply.htmlなどのヘッダに、セキュアトークン出力とim_workflow/js/api_base.jsのdefer付き読み込みを記述する

<imart type="head">
<meta http-equiv="X-Intramart-Secure-Token" content="<imart type="imSecureToken" mode="value" />"/>
<script src="im_workflow/js/api_base.js" defer></script>
</imart>

申請ボタンのクリックイベントなどで、imWorkflow.modal.showApplyを呼び出す

imWorkflow.modal.showApply({
  processParameter: {
    matterName: "sampleMatter"
  },
  optionalParameter: {
    userParameter: {
      item_name: $('#item_name').val(),
      item_amount: $('#item_amount').val(),
      item_price: $('#item_price').val(),
      item_comment: $('#item_comment').val()
    }
  },
  rebootModal: false
}).then(function(result) {
  if (result.isProcessDone) {
    // 申請完了後の追加処理
  }
  imWorkflow.transition.afterProcess();
});

申請一覧から開く申請では、flowIdは指定しません。
processParameter.userDataIdの指定方法は、ユーザデータIDの概要を参照してください。

画面の入力値をoptionalParameter.userParameterに設定し、アクション処理へ渡す
thenブロック内でresult.isProcessDoneがtrueの場合の処理を記述し、モーダル終了後にimWorkflow.transition.afterProcess()を実行する
処理画面ではimWorkflow.modal.showProcessを呼び出す

サンプルの処理画面はscreen_modal/approve.htmlです。詳細は処理画面：approveを参照してください。

備考

API呼び出し手順：申請モーダル（プログラミングガイド）、処理モーダル（プログラミングガイド）
メソッドの引数：クライアントサイドJavaScript APIを参照してください。

ユーザデータIDの概要

ユーザデータIDは、業務データと案件を1対1で紐づけるアプリケーション側の識別子です。開発要件に合わせて、userDataIdの指定方法と呼び出すAPIを決定します。

ケース	`userDataId` の指定	呼び出すAPI
新規申請で、アプリが決めたIDを渡す ※1	生成したIDを指定する	`showApply`
新規申請で、IDの生成をシステムにまかせる ※1	省略する	`showApply`
一時保存・再申請で、リクエストのIDを渡す	リクエストの `imwUserDataId` を指定する	`showApply`
承認などの処理 ※2	引数には含めない	`showProcess`

※1：新規申請では、次のいずれかに該当する場合に「新規申請で、アプリが決めたIDを渡す」を選択します。当てはまらない場合は「新規申請で、IDの生成をシステムにまかせる」を選択してください。
- 申請前に、アプリ側で生成したIDに紐づく業務データや添付ファイルの作成、他システム連携が必要な場合
- 申請前に、独自の別画面やバッチ処理で業務テーブルをアプリ側生成のIDで検索・連携したい場合
- 文字列20バイト以下の既存業務ID（外部ID）を、案件のユーザデータIDとしてそのまま流用したい場合
※2：承認などの処理では、showProcessのprocessParameterにuserDataIdはありません。画面は、リクエストのimwUserDataIdでテーブルから業務データを取得します。呼び出しの詳細は処理画面：approveを参照してください。

新規申請で、アプリが決めたIDを渡す

アプリケーション側で独自にIDを生成し、申請時にshowApplyの引数userDataIdへ渡す方法です。IDを生成するタイミングは任意で、案件の開始前でも問題ありません。案件とユーザコンテンツの関係

申請一覧から開く新規申請では、リクエストパラメータにimwUserDataIdが含まれません。そのため、画面種別が申請（imwPageTypeが0）のときに、ファンクション・コンテナでIdentifier.get()を呼び出します。既存の業務IDを利用する場合は、その値を設定します。

購入申請サンプルは、ID指定を省略する実装（IDの生成をシステムにまかせる形式）になっています。アプリケーションが決めたIDを渡す実装へ変更する手順は、次のとおりです。

ファンクション・コンテナ（サーバ側JavaScript）でIdentifier.get()を呼び出し、$data.imwUserDataIdに格納する

既存の業務IDを使う場合は、Identifier.get()の代わりにその値を$data.imwUserDataIdへ代入します。

HTML側で、$data.imwUserDataIdの値をJavaScript変数に展開する

サンプルのapply.htmlで、$(function(){ ... })の内側に次のスクリプトを記述します。
```
<script type="text/javascript">
$(function(){
  var userDataId = '<imart type="string" value=$data.imwUserDataId escapeXml="true" escapeJs="true" />';
});
</script>
```
備考
<imart type="string">タグはサーバ側で評価されて文字列に置換され、ブラウザにはvar userDataId = 'xxxxxxxx';のように展開されて届きます。
value=$data.imwUserDataIdのように属性値を引用符で囲まない記述は、ファンクション・コンテナ変数のバインドを示します。値はクライアント側のJavaScript文字列リテラル内へ埋め込まれます。そのため、構文エラーやXSSを防ぐ目的でescapeXmlとescapeJsの両方をtrueに指定します。 IMART type="string"
imWorkflow.modal.showApplyのprocessParameter.userDataIdに、その変数を渡す

サンプルのapply.htmlに、次のパラメータを追記します。
```
{
  processParameter: {
    userDataId: userDataId
  }
}
```

新規申請で、IDの生成をシステムにまかせる

showApplyの呼び出し時にuserDataIdを省略し、IDの生成をIM-Workflowにまかせる方法です。省略時は、設定された採番ルールに従って自動的にIDが割り当てられます。ユーザデータID設定方式

※アクション処理側では、システムから渡されるparameter.userDataIdを受け取って業務テーブルへ登録します。購入申請サンプルのアクション処理もこの方式で実装されています。

注意

サンプルのapply.jsには、imwPageType == "0"のときにIdentifier.get()を呼び出して$data.imwUserDataIdに格納する記述があります。IDの生成をシステムにまかせる場合、このID生成ロジックは不要です。

if ($data.imwPageType == "0") {
  $data.imwUserDataId = Identifier.get();
}

申請一覧から開いた申請では、HTML側でimWorkflow.modal.showApplyを呼び出します。引数にuserDataIdとflowIdは含めないでください。申請一覧で選択したフローは、IM-Workflowが自動的に適用します。

一時保存・再申請で、リクエストのIDを渡す

一時保存や再申請など、案件一覧から開く申請画面では、リクエストパラメータのimwUserDataIdをそのまま使用します。すでに採番済みのユーザデータIDを引き継ぐため、IDを再生成する必要はありません。

showApplyの引数userDataIdは省略可能です。ただし省略すると、「ユーザデータID設定方式」に従って新規IDが自動採番されます。一時保存や再申請の状態から申請を再開する場合は、保持されているユーザデータIDを明示的に指定してください。 showApply

購入申請サンプルは、userDataIdを渡さない実装になっています。一時保存や再申請のIDを引き継ぐ実装へ変更する手順は、次のとおりです。

ファンクション・コンテナ（サーバ側JavaScript）で、リクエストパラメータのimwUserDataIdを取得して$dataへ格納する（Identifier.get()は呼び出しません）
HTML側で、$data.imwUserDataIdの値をJavaScript変数に展開する

サンプルのapply.htmlで、$(function(){ ... })の内側に次のスクリプトを記述します。
```
<script type="text/javascript">
$(function(){
  var userDataId = '<imart type="string" value=$data.imwUserDataId escapeXml="true" escapeJs="true" />';
});
</script>
```
備考
<imart type="string">タグはサーバ側で評価されて文字列に置換され、ブラウザにはvar userDataId = 'xxxxxxxx';のように展開されて届きます。
value=$data.imwUserDataIdのように属性値を引用符で囲まない記述は、ファンクション・コンテナ変数のバインドを示します。値はクライアント側のJavaScript文字列リテラル内へ埋め込まれます。そのため、構文エラーやXSSを防ぐ目的でescapeXmlとescapeJsの両方をtrueに指定します。 IMART type="string"
imWorkflow.modal.showApplyのprocessParameter.userDataIdに、取得したユーザデータIDを渡す

サンプルのapply.htmlに、次のパラメータを追記します。
```
{
  processParameter: {
    userDataId: userDataId
  }
}
```

備考

showProcessの引数processParameterにuserDataIdプロパティはありません。案件一覧から遷移した場合、systemMatterIdやnodeIdなどの案件識別情報には、一覧で選択した値が自動設定されるため、引数での指定は不要です。

呼び出しの実装方法は、前述の処理画面：approveおよびshowProcessを参照してください。

ステップ2：ユーザプログラムを作成する

画面を作成したら、画面からの送信データを受け取って業務テーブルに保存したり、フローの分岐や一覧表示に使う値を設定したりするサーバ側のユーザプログラムを実装します。

IM-Workflowでは、アクションの実行、案件の開始・終了、ルートの分岐など、フローの進行イベントに応じて呼び出される各種のプログラム種別が用意されています。購入申請サンプルでは、次の種別とプログラムが実装されています。

種別	サンプルプログラム	役割の概要
アクション処理	`ActionProcess1`	画面入力値（`userParameter`）の業務テーブル登録・更新、および案件番号の採番
アクション処理	`ActionProcess2`	数量×単価を計算し、案件プロパティ`item_total`へ登録・更新
案件終了処理	`MatterEndProcess`	案件完了時に業務テーブルの終了フラグを更新
分岐開始処理	`RuleCondition1`〜`RuleCondition3`	合計金額に応じた分岐ルートの判定（遷移可否の真偽値を返却）

※購入申請サンプルには案件開始処理のMatterStartProcessも含まれていますが、executeで成功フラグを返却するのみで、テーブルや案件プロパティの更新は行いません。

ヒント

プログラムを新規作成する場合は、sample/im_workflow/template/に用意されている各種別のテンプレート（空の関数シグネチャ）を複製して実装します。

備考

プログラムの返却値は種別ごとに異なります。分岐開始処理ではルートの遷移可否を返却オブジェクトdataの真偽値（true/false）で返し、アクション処理では処理結果をresultFlagとmessage（独自採番時はdata）で返却します。
種別の一覧と起動タイミングの詳細は、ユーザプログラムの作成（プログラミングガイド）を参照してください。

画面入力をテーブルと案件プロパティへ分ける

購入申請サンプルのアクション処理（ActionProcess1およびActionProcess2）を例に、申請画面からの入力データを業務テーブルと案件プロパティへ書き分け、後続の分岐処理へ連携するデータフロー（申請・更新時）を説明します。

申請画面でimWorkflow.modal.showApplyを呼び出すと、optionalParameter.userParameterに設定された入力値が各アクション処理の第2引数userParameterとして渡されます。画面側のパラメータ設定については、申請画面：applyを参照してください。

注意

アクション処理はIM-Workflowのトランザクション内で実行されます。

プログラム内で独自のDBトランザクション制御を行うことはできません。
返却オブジェクトのresultFlagにfalseを設定した場合、後続のアクション処理は実行されません。resultFlagの指定を省略した場合は成功（true）として扱われます。したがって、コンテンツ定義でActionProcess1が先に登録されている場合、ActionProcess1が失敗したときは後続のActionProcess2も呼び出されません。

業務テーブルへの登録と採番（ActionProcess1）
案件プロパティへの登録（ActionProcess2）
分岐処理でのデータ参照先
処理ノードでの更新制御

業務テーブルへの登録と採番（ActionProcess1）

ActionProcess1は、申請画面から渡された入力パラメータを業務テーブル（sample_imw_t_purchase）へ登録・更新し、申請時に案件番号を採番して返却します。処理区分に応じて、採番の実行要否や業務テーブルへの操作（新規登録・更新・削除）が分岐します。

画面からuserParameterとして渡されるキーは、item_name、item_amount、item_price、item_commentです。合計金額item_totalは画面の入力キーに含まれないため、プログラム内でNumber(userParameter.item_amount) * Number(userParameter.item_price) + ""により算出し、業務テーブルの列へ文字列として保存します（userParameterが未設定の場合は"0"として扱います）。

注意

案件番号の採番と返却設定では、IM-Workflowの仕様に注意が必要です。返却オブジェクトのdataプロパティがnull以外の場合にのみ、案件情報側の案件番号が上書きされます。

新規採番（申請系・一時保存からの申請）：apply、applyFromTempSave、applyFromUnapplyではWorkflowNumberingManager.getNumber()を呼び出し、取得した案件番号を返却オブジェクトのdataに設定します。採番に失敗した場合はresultFlagにfalseを設定して後続処理を中断します。
既存番号の維持（再申請）：reapplyではdataにnullを設定します。返却オブジェクトのdataがnull以外の場合にのみ案件情報側の案件番号が上書きされる仕様のため、nullを設定することで既存の案件番号が維持されます。
一時保存での除外：一時保存処理（tempSaveCreate、tempSaveUpdate、tempSaveDelete）では採番せず、dataプロパティも設定しません。

案件プロパティへの登録（ActionProcess2）

ActionProcess2は、業務テーブルとは別に、合計金額item_totalをワークフローの案件プロパティへ登録・更新・削除します。申請画面で入力された全項目を業務テーブルに保存するのに対し、案件プロパティへは一覧検索や管理画面のルール定義での条件判定に必要な主要キー（合計金額）のみを抽出して登録します。

案件プロパティはワークフローエンジンが管理する共通インデックス領域です。不要な明細データまで多重に登録するとデータベース容量や処理負荷が増加するため、主要な制御データに絞り込みます。

処理種別に応じたプロパティ操作では、UserActvMatterPropertyValueのAPIを次のように使い分けます。後続の分岐判定ノード（方式A）や一覧画面で参照されるため、アクション処理の段階で登録しておく必要があります。

操作	APIメソッド	対象の処理区分	設定内容
新規登録	`createMatterProperty`	`apply`、`applyFromUnapply`、`tempSaveCreate`	算出した合計金額を`matterPropertyValue`に設定
更新	`updateMatterProperty`	`reapply`、`applyFromTempSave`、`tempSaveUpdate`	再計算した合計金額でプロパティ値を更新
削除	`deleteMatterProperty`	`tempSaveDelete`	`matterPropertyValue`に`null`を設定して削除

分岐処理でのデータ参照先

購入申請サンプルの分岐開始処理（RuleCondition1〜RuleCondition3）は、業務テーブルを参照してルート遷移を判定します。IM-Workflowにおける分岐判定には、管理画面で完結する方式と、プログラムで柔軟に実装する方式の2通りのデータ参照経路があります。

2つの方式には次の違いと使い分けがあります。

方式	設定・実装場所	参照先	特徴と使い分け
方式A（ルール定義）	管理画面（ノンプログラミング）	案件プロパティ（`item_total`）	金額帯の条件式（例：`item_total >= 10000`）をGUI上で定義します。プログラムを実装せずに設定変更できる利点があります。
方式B（分岐開始処理プログラム）	スクリプト開発モデル（プロコード）	業務テーブル（`sample_imw_t_purchase`）	`parameter.userDataId`をキーに`getPurchaseData`で該当行の値を取得し、ルート遷移可否を`result.data`（`true`で遷移、`false`で非遷移）として返却します。外部システム連携や複雑な判定に適しています。

購入申請サンプルでは、ActionProcess2で案件プロパティへitem_totalを登録しつつ、サンプルの分岐ノードには分岐開始処理プログラム（プロコード方式）を割り当てています。同一の合計金額を扱いながら、書き込み先と参照元が異なる構成になっている点に留意してください。

なお、サンプルのRuleConditionが呼び出す共通関数getPurchaseDataは、データ取得に失敗した場合はエラー画面へ遷移したうえでnullを返却し、result.resultFlagをfalseに設定します。各分岐で判定する金額帯の基準は、ステップ6：動作確認をするで確認できます。

処理ノードでの更新制御

購入申請サンプルの承認処理（approve）では、業務テーブルと案件プロパティのいずれも更新しません。承認時にデータを更新するかどうかによって、画面呼び出しとアクション処理の実装構成が異なります。

サンプルの処理画面（screen_modal/approve）は確認専用画面として実装されており、画面側から入力パラメータを送信しません（optionalParameterが空）。そのため、ActionProcess1およびActionProcess2のapprove関数では成功ステータス（resultFlag: true、空のmessage）を返却するのみで、データ更新処理は含まれていません。

承認ノードで査定金額の修正や承認コメントの保存をする場合は、処理画面のshowProcess呼び出し時にoptionalParameter.userParameterへ入力値を設定します。そして、アクション処理のapprove関数内で業務テーブルや案件プロパティの更新を実装します。

画面側の呼び出し構成については、前述の処理画面：approveを参照してください。

備考

パラメータの詳細仕様および返却値の構成については、アクション処理（プログラミングガイド）を参照してください。

ステップ3：コンテンツ定義に登録する

ステップ1で作成した画面と、ステップ2で作成したユーザプログラム（アクション処理・案件終了処理・分岐開始処理）を、コンテンツ定義に登録します。コンテンツ定義は、ワークフローで利用する画面や処理のリソースを定義するマスタです。

スクリプト開発モデルでは、画面やプログラムの配置パスを正確に設定する必要があります。パスに誤りや拡張子が含まれていると、画面の表示時やノードの処理時に実行エラーとなります。

コンテンツ定義を新規登録するコンテンツ定義を登録・設定する（管理者操作ガイド）

基本情報としてコンテンツIDやコンテンツ名を入力し、バージョン情報を設定します。

画面定義で、画面種別とパス種別を指定する

パス種別ではスクリプト開発モデルを選択し、WEB-INF/jssp/srcからの相対パスを入力します。末尾に拡張子（.jsや.html）は付けません。フローで標準として使用する画面は、初期使用を選択します。

ユーザプログラム定義で、プラグイン種別・種類・対象ノード・初期使用・実行順番を指定する

プラグイン種類ではスクリプト開発モデルを選択し、選んだプラグイン種別に対応するプログラムパスを相対指定します。
アクション処理を登録する場合は、対象ノード（サンプルのActionProcess1およびActionProcess2では「申請」）を指定します。フローで標準として実行するプログラム（サンプルのActionProcess1、ActionProcess2、および案件終了処理MatterEndProcess）は、初期使用を選択します。
分岐処理を実装した場合は、プラグイン種別「分岐処理」、プラグイン種類「スクリプト開発モデル」を選択し、プログラムパス（サンプルではRuleCondition1〜RuleCondition3）を指定します。分岐先ノードへの割り当ては、後述のステップ5で行います。
同一ノードで複数のアクション処理を実行する場合は、実行順番に昇順の数値を指定します。サンプルの申請ノードでは、テーブル登録と採番を行うActionProcess1を1、案件プロパティを登録するActionProcess2を2のように指定します。画面入力をテーブルと案件プロパティへ分ける

必要に応じて、案件プロパティ定義を登録する

ステップ2のActionProcess2のような、保存した値を一覧画面での表示やルール定義での分岐条件判定に利用する場合は、コンテンツ定義とは別に案件プロパティ定義を登録します。
intra-martメニューのサイトマップ＞ワークフロー＞ワークフロー管理者＞マスタ定義＞案件プロパティ定義を開き、キー（サンプルではitem_total）、キー名（日本語「合計金額」など）、型（「数値」）、使用種別（「一覧表示項目の項目として使用する」「ルールの条件の変数として使用する」など）を設定して登録します。案件プロパティ定義を登録・設定する（管理者操作ガイド）

購入申請サンプルで登録するおもな設定値は次のとおりです。

区分	画面種別／プラグイン種別	設定パス／設定値	役割
画面	申請画面、一時保存画面、申請（起票案件）画面、再申請画面	`sample/im_workflow/purchase/screen_modal/apply`	処理モーダル対応の申請画面（同一パスを各画面種別に登録）
画面	処理画面	`sample/im_workflow/purchase/screen_modal/approve`	処理モーダル対応の承認画面
画面	確認画面	`sample/im_workflow/purchase/screen_modal/confirm`	確認用画面
画面	処理詳細画面、参照詳細画面、確認詳細画面、過去案件詳細画面	`sample/im_workflow/purchase/screen_modal/detail`	詳細・参照画面（同一パスを各画面種別に登録）
処理	アクション処理	`sample/im_workflow/purchase/action/ActionProcess1`	申請ノードでのテーブル登録と案件番号採番
処理	アクション処理	`sample/im_workflow/purchase/action/ActionProcess2`	申請ノードでの案件プロパティ登録
処理	案件終了処理	`sample/im_workflow/purchase/action/MatterEndProcess`	案件終了時のフラグ更新
処理	分岐処理	`sample/im_workflow/purchase/action/RuleCondition1`〜`RuleCondition3`	合計金額による分岐判定（分岐使用時。金額帯ごとに3プログラムを登録）

備考

コンテンツ定義の詳細やメッセージ・メールなどの仕様については、以下のドキュメントを参照してください。

コンテンツ定義（仕様書）

ステップ4：ルート定義を登録する

ワークフローの承認経路をルート定義で設計します。「誰」が「どのような順序」で処理するかを、ノードの配置と処理対象者の設定で決定します。ルート定義はコンテンツ定義と独立しているため、画面やプログラムの実装と並行して作成できます。

ルート定義を新規作成するルート定義を登録・設定する（管理者操作ガイド）

基本情報としてルートIDやルート名を入力し、バージョン情報を設定します。

ノードを配置して承認経路を組み立てるルートの設計 - 承認経路の組み立て

開始ノードから申請ノード、承認ノード、終了ノードを配置し、各ノードを接続線で結びます。分岐ルートを作成する場合は、分岐開始ノードと分岐終了ノードのあいだに各分岐先の承認ノードを追加します。

各ノードの処理対象者を設定する

申請ノードや承認ノードに対して、処理を担当するユーザ・組織・役職などを割り当てます。

備考

ルート定義では、経路の構造と処理対象者のみを設計します。分岐ノードを配置した場合でも、分岐条件（プログラムやルール定義）の割り当ては、ステップ5のフロー定義で行います。

ステップ5：フロー定義を登録する

作成したコンテンツ定義とルート定義を、フロー定義で関連付けてひとつのワークフローとして完成させます。コンテンツ定義で初期使用として登録した画面やユーザプログラムはフローにそのまま引き継がれるため、フロー定義では基本情報・バージョン情報の登録と、分岐開始ノードへの分岐処理の割り当てを行います。

フロー定義とバージョン情報を新規登録するフロー定義を登録・設定する（管理者操作ガイド）

基本情報としてフローIDやフロー名を入力して登録したあと、バージョンを新規作成します。バージョン情報で使用するコンテンツ定義とルート定義を選択し、有効期間やバージョン有効を設定して、申請者が申請一覧から利用できる状態にします。

分岐開始ノードに分岐処理を割り当てる

分岐ルートを使用する場合は、ルート詳細で分岐開始ノードの設定を開き、分岐開始方法に「ユーザプログラムで分岐開始する」を選択します。分岐先ノードごとにコンテンツ定義に登録した分岐処理（1万円未満はRuleCondition1、1万円以上5万円未満はRuleCondition2、5万円以上はRuleCondition3）を選択します。サンプルの分岐では、ルール定義（条件式）ではなくプログラムによる分岐処理を使用します。

ステップ6：動作確認をする

フロー定義の有効化まで完了したら、一般ユーザ画面から申請・承認・完了までの一連の操作を実行し、動作を確認します。画面の表示や遷移だけでなく、業務テーブルへの登録結果、案件プロパティの値、分岐判定の結果、案件終了処理の実行が意図どおりかを検証します。

申請一覧から申請処理を実行する申請する（ユーザ操作ガイド）

intra-martメニューのWorkflow＞申請一覧を開き、作成したフローを選択します。申請画面が表示されたら、品名や数量などの必要項目を入力し、処理モーダルから申請を実行します。

承認者で案件を処理する承認、否認をする（ユーザ操作ガイド）

承認対象のユーザでログインし、未処理一覧から対象の案件を開きます。処理画面が表示されることを確認し、承認（または否認・差戻し）を実行します。

データ登録結果と案件プロパティの値を確認する

データベースおよびワークフローの案件状態を確認します。

購入申請サンプルでは、処理の進行に合わせて次の項目を確認します。

業務テーブル（sample_imw_t_purchase）に申請データが登録されていることレコードの追加/更新/削除（TableMaintenance 管理者操作ガイド）
案件一覧や案件情報画面に、採番された案件番号が表示されていることフロー情報（ユーザ操作ガイド）
案件プロパティitem_totalに数量×単価の合計金額が設定されていること
分岐ルートを使用している場合、合計金額の条件（1万円未満、1万円以上5万円未満、5万円以上）に応じた承認ノードへ案件が進むことユーザプログラム（プログラミングガイド）
案件が完了した際、案件終了処理（MatterEndProcess）によって終了フラグが更新されていること

画面が表示されない場合やプログラムが実行されない場合は、コンテンツ定義に登録した相対パス（スペルミスや不要な拡張子の有無）や、フロー定義における各ノードへの割り当て設定、サーバログのエラー内容を確認してください。

スクリプト開発モデルでのワークフロー開発​

intra-mart管理画面上の構成​

サンプルコードの構成​

モジュールの構成​

前提条件​

開発ステップ​

ステップ1：画面を作成する​

サンプルで入力と送信の流れを確認する​

申請画面：apply​

処理画面：approve​

確認・詳細画面：comfirm/detail​

処理モーダルで画面を実装する​

ユーザデータIDの概要​

新規申請で、アプリが決めたIDを渡す​

新規申請で、IDの生成をシステムにまかせる​

一時保存・再申請で、リクエストのIDを渡す​

ステップ2：ユーザプログラムを作成する​

画面入力をテーブルと案件プロパティへ分ける​

業務テーブルへの登録と採番（ActionProcess1）​

案件プロパティへの登録（ActionProcess2）​

分岐処理でのデータ参照先​

処理ノードでの更新制御​

ステップ3：コンテンツ定義に登録する​

ステップ4：ルート定義を登録する​

ステップ5：フロー定義を登録する​

ステップ6：動作確認をする​