CookBook

Formaのスクリプトから処理対象者を制御するには

投稿日:2016-04-13 更新日:

このCookBookでは、スクリプトを利用してIM-Workflowの動的ノード(動的承認、縦配置、横配置)の処理対象者を制御する方法をご紹介します。
スクリプトから動的処理対象者設定機能を利用することで制御を行います。

【注意事項】このCookBookのサンプルアプリケーション・サンプルスクリプトは、クライアントタイプ「PC」を対象としております。

完成イメージ

サンプルアプリケーションでは、Formaのアプリ実行画面で選択したユーザが動的承認ノードの処理対象者として自動で設定されます。


1. 任意のユーザを選択します。
2. 申請処理を行います。
3. 1で選択したユーザの未処理一覧に案件が展開されていることを確認します。

完成サンプル

以下の完成サンプルをダウンロードしてご活用ください。

e builder プロジェクト : im_cookbook_110547_forma_node_setting.zip
imm ファイル : im_cookbook_110547_forma_node_setting-1.0.0.imm

ローカル環境で表示させる場合は、以下のURLにアクセスしてください。
http://localhost:8080/imart/im_workflow/user/apply/apply_direct/im_cookbook_110547_1

なおベースURLである以下の部分は、環境に合わせて適宜変更してください。
http://localhost:8080/imart

レシピ

  1. 動的ノードを配置したフローを作成する
  2. 動的ノードを制御するスクリプトを作成する

1. 動的ノードを配置したフローを作成する

「動的ノード」とは?

「動的ノード」とは、フローの申請(処理開始)後に、処理対象者の追加・削除などを設定することができるノードです。以下の3種類のノードが提供されています。

  • 動的承認ノード : 申請者や承認者が指定した処理対象者が、案件の承認を行うことを示すノードです。このノードより前のノード(前ノード)の処理者は、このノードに対する編集(処理対象者の変更・ノードの削除・復活)ができます。

  • 横配置ノード : 申請者や承認者が、連続した動的承認ノードを指定した範囲内で作成することができることを示すノードです。配置するノード数の上限と下限はフロー定義で設定することができます。下限のノード数を0に設定すると、ノードを配置しない(削除する)ことができます。

  • 縦配置ノード : 申請者や承認者が、並行した動的承認ノードを指定した範囲内で示すノードです。配置するノード数の上限と下限はフロー定義で設定することができます。下限のノード数を0に設定すると、ノードを配置しない(削除する)ことができます。

動的ノードの配置(ルート定義)

動的ノードを配置したルート定義を作成します。今回は、3種類の動的ノードのうち、動的承認ノードを利用します。

  1. 「サイトマップ」- 「ワークフロー」-「マスタ定義」-「ルート定義」からルート定義一覧画面を表示し、「新規作成」のメニューを押下してください。ルート定義新規作成画面が表示されます。

route_add

  1. 「ルートID」「ルート名」を入力し、ルート定義の登録を行います。ルート定義バージョン一覧が表示されます。

  2. 「新規作成」メニューを押下し、ルート定義バージョン新規作成画面を表示してください。

route_version_add

  1. 「ルート詳細」タブを押下し、ルート詳細画面を表示してください。開始ノード・申請ノード・終了ノードが配置されています。

  2. 動的承認ノードを配置してください。

node_add

  1. 配置した動的承認ノードを押下し、ノード設定画面を表示してください。処理対象者設定の「指定なし」を選択してください。

non_target

  1. 申請ノードから動的承認ノードへ、動的承認ノードから終了ノードへ矢印を引きます。

relation_add

  1. 「基本情報」タブを押下し、バージョン期間を入力し、ルート定義バージョンを新規登録してください。
動的ノードの処理対象者を決定するノードの設定(フロー定義)

作成したルート定義を利用したフロー定義を作成してください。
コンテンツ定義については、FormaのWF連携設定により作成済みのものを利用してください。

  1. 「サイトマップ」- 「ワークフロー」-「マスタ定義」-「フロー定義」からフロー定義一覧画面を表示し、「新規作成」のメニューを押下してください。フロー定義新規作成画面が表示されます。

flow_add

  1. 「フローID」「フロー名」を入力し、フロー定義の登録を行います。フロー定義バージョン一覧が表示されます。

  2. 「新規作成」メニューを押下し、フロー定義バージョン新規作成画面を表示してください。

flow_version_add

  1. バージョン期間・コンテンツ・ルートを設定し、フロー定義バージョンを新規登録してください。コンテンツについてはFormaのWF連携設定により作成したコンテンツ定義を、ルートについては前章で作成したルート定義を設定してください。

  2. フロー定義バージョン編集画面が表示されます。「ルート詳細」タブを押下し、ルート詳細画面を表示してください。

route_detail

  1. 動的承認ノードの編集リンクを押下し、ノード設定画面を表示してください。

  2. 処理対象者設定可能ノードに対して、申請ノードを登録してください。

node_select

  1. フロー定義バージョンを更新してください。

2. 動的ノードを制御するスクリプトを作成する

「動的処理対象者設定機能」とは?

動的処理対象者設定機能は、動的ノードの処理対象者をシステム的に制御できる機能です。以下が実現可能です。

  • 処理対象者の決定 : 標準処理画面で処理対象者の設定が可能な動的ノードに対して、ビジネスロジックによって決定した処理対象者を反映する。

  • 処理対象者検索時の暗黙条件の指定:標準処理画面で処理対象者の設定が可能なノードにおいて、申請者・承認者が処理対象者を検索・設定する際の暗黙条件を指定し、検索結果の絞り込みを行う。

処理対象者の決定・処理対象者検索時の暗黙条件の指定を行うには、ユーザコンテンツ画面から標準処理画面を呼び出す際のリクエストパラメータにて指定してください。

詳細については、「IM-Workflow プログラミングガイド 8.9. 動的処理対象者設定機能」をご参照ください。

また、IM-BISで作成したフローの場合、外部連携機能を利用することでスクリプトを作成することなく、設定ベースで動的処理対象者設定機能と連携することが可能です。

詳細については、「IM-BIS for Accel Platform / 業務管理者 操作ガイド 7.18. 動的ノード(動的承認、縦配置、横配置)の処理対象者条件を設定する」をご参照ください。

処理対象者の決定

動的処理対象者設定機能のうち、処理対象者を自動で設定する場合のスクリプトの書き方をご紹介します。

標準処理画面が呼び出される際に(申請・承認ボタンが押下されるタイミング)、動的ノードの処理対象者の設定内容をパラメータ「imwNodeSetting」で送信してください。

  1. 動的承認ノードが対象の場合、設定内容は以下のようなオブジェクト構造で作成してください。

  1. 設定内容のオブジェクトはJSON文字列に変換した上でパラメータ「imwNodeSetting」に指定してください。

動的ノードで利用可能な処理対象者プラグイン

処理対象者は、IM-Workflowの処理対象者プラグイン(拡張ポイントID・プラグインID・パラメータ)形式で指定してください。

  1. 拡張ポイントID

以下のコード値を指定してください。すべての動的ノード(動的承認・縦配置・横配置ノード)で利用可能です。

  1. プラグインID・パラメータ

ここでは、よく利用されるプラグイン情報をご紹介します。
動的ノードで利用可能な全てのプラグイン情報については、以下のドキュメントをご参照ください。

「IM-Workflow 仕様書 3.9.2.2. 処理権限者プラグイン一覧 動的承認ノード、縦配置ノード、横配置ノード」

「IM-Workflow 管理者操作ガイド 処理対象者プラグイン設定ファイル一覧 動的承認・縦配置・横配置ノード」

ユーザ

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.user
パラメータ
ユーザーコード

組織

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.department
パラメータ
会社コード^組織セットコード^組織コード

ロール

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.role
パラメータ
ロールID

パブリックグループ

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.public_group
パラメータ
パブリックグループセットコード^パブリックグループコード

役職

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.post
パラメータ
会社コード^組織セットコード^役職コード

役割

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.public_group_role
パラメータ
パブリックグループセットコード^役割コード

組織+役職

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.department_and_post
パラメータ
会社コード^組織セットコード^組織コード|会社コード^組織セットコード^役職コード

パブリックグループ+役割

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.public_group_and_public_group_role
パラメータ
パブリックグループセットコード^パブリックグループコード|パブリックグループセットコード^役割コード

組織+ロール

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.department_and_role
パラメータ
会社コード^組織セットコード^組織コード|ロールID

パブリックグループ+ロール

プラグインID
jp.co.intra_mart.workflow.plugin.authority.node.dynamic.public_group_and_role
パラメータ
パブリックグループセットコード^パブリックグループコード|ロールID
(サンプルスクリプト)処理対象者の決定

画面アイテム「ユーザ選択」の入力値を元にリクエストパラメータ「imwNodeSetting」を生成し、動的承認ノードの処理対象者にセットするサンプルコードをご紹介します。

処理対象者検索時の暗黙条件の指定

動的処理対象者設定機能のうち、ユーザが選択できる処理対象者の範囲を限定する場合のスクリプトの書き方をご紹介します。

標準処理画面が呼び出される際に(申請・承認ボタンが押下されるタイミング)、申請者・処理者が処理対象者を検索する際の暗黙条件をパラメータ「imwNodeSetting」で送信してください。
暗黙条件を指定した場合は、申請者・処理者が選択できる処理対象者の指定方法はユーザ検索のみです。

  1. 動的承認ノードが対象の場合、設定内容は以下のようなオブジェクト構造で作成してください。

  1. 設定内容のオブジェクトはJSON文字列に変換した上でパラメータ「imwNodeSetting」に指定してください。

検索条件は、IM-共通マスタのユーザ検索画面(キーワード タブ)に対する暗黙条件を指定可能です。検索条件に利用できる暗黙条件の詳細については、
「IM-共通マスタ 検索画面起動引数一覧」をご参照ください。

【注意事項】暗黙条件に「組織分類」・「パブリックグループ分類」「ユーザ分類」を利用することはできません。

(サンプルスクリプト)処理対象者検索時の暗黙条件の指定

画面アイテム「所属組織選択」の入力値を元にリクエストパラメータ「imwNodeSetting」を生成し、動的承認ノードの処理対象者を検索する際の暗黙条件にセットするサンプルコードをご紹介します。

サンプルコードは、画面アイテム「ボタン(イベント)」への記述を想定しています。

-CookBook
-, ,

執筆者:


  1. intra-mart開発本部 より:

    お待たせしております。
    ご提供いただいた情報から弊社側でも再現確認を行っておりますが、ご指摘の事象を再現できておりません。
    再現確認が実施できないため、これ以上の調査継続が難しい状況です。

    大変申し訳ありませんが、事象の解決に向けて追加の調査・支援をご希望される場合は、弊社の技術コンサルティングサービスをご利用ください。
    http://www.intra-mart.jp/products/consulting/

  2. intra-mart開発本部 より:

    ご回答ありがとうございます。

    完成サンプルをダウンロードし、取込みした画面を起動

    完成版サンプルの取り込みと記述していただいている内容は、CookBookの記事に添付されているプロジェクト(im_cookbook_110547_forma_node_setting.zip)もしくはユーザモジュール(im_cookbook_110547_forma_node_setting-1.0.0.imm)から以下のファイルを取得し、インポートされたという認識でお間違いないでしょうか?

    ・ IM-FormaDesigner サンプルアプリケーション im_cookbook_110547_forma1.zip
    ・ IM-FormaDesigner サンプルアプリケーション im_cookbook_110547_forma2.zip
    ・ IM-FormaDesigner サンプルアプリケーション im_cookbook_110547_forma3.zip
    ・ IM-FormaDesigner サンプルアプリケーション im_cookbook_110547_forma4.zip
    ・ IM-Workflow サンプルフロー定義,ルート定義,コンテンツ定義 im_cookbook_110547_workflow.xml

    フロー設定のブロックが表示され、設定状況が空のものが表示される

    「(サンプルスクリプト)処理対象者の決定」が正常に実行された場合は、申請処理画面にフロー設定のブロックが表示されません。「(サンプルスクリプト)処理対象者の決定」では処理対象者をセットする動的承認ノードとしてノードID「dynamic_001」を設定しておりますが、ルート定義のノードIDは「dynamic_001」になっておりますでしょうか?

    また、ご回答の内容ですと、2014Winterも2016Summerも同じ動作をするとありますが、何か環境設定周りの編集は必要ないのでしょうか。

    環境設定に関して変更する点は、ございません。

    また、2014 Winter PATCH 001と2016 Summerで同様に動作致します。2014 WinterにIM-Workflow 2014 Winter(Iceberg) 8.0.9 PATCH 001を適用していない場合は、動的処理対象者設定機能がインストールされていないため、CookBookのサンプルコードの内容は動作致しません。

    • ohashi より:

      ■サンプル取込手順について
      【環境:2016Summer】
      1.IM-Jugglingでユーザモジュールとして「im_cookbook_110547_forma_node_setting-1.0.0.imm」を取り込んでおります。
      2.テナント環境セットアップについて「テナント環境は最新です。セットアップが必要なモジュールはありません。 」となっております。
      3.インストールされているモジュール一覧に「jp.co.intra_mart.im_cookbook_110547_forma_node_setting」が表示されております。
      4.コンテンツ定義、ルート定義、フロー定義、アプリケーション一覧に「im_cookbook_110547_1(4まで)」が取り込まれていることを確認しております。
      5.http://xxxxxxx:8080/imart/im_workflow/user/apply/apply_direct/im_cookbook_110547_1(4まで)でアプリケーションにアクセスできることを確認しております。

      正常にインポートがされていることを確認する上で、その他に確認する箇所はございますか。

      ■サンプルスクリプトにおける動的承認ノードのノードIDについて
      過去に回答しておりますが、同じノードID「dynamic_001」を設定しております。

      ■2014 Winterのパッチ適用について
      こちらも過去に回答しておりますが、
      「IM-Workflow 2014 Winter(Iceberg) 8.0.9-PATCH_001」を適用しております。

  3. intra-mart開発本部 より:

    ご連絡ありがとうございます。

    下記の流れで現在に至っております。
    1.2014Winter環境でサンプルコードを貼り付けて作成⇒動作せず
    2.2014Winterから2016Summerにバージョンを上げ、1で作成したものを動作確認⇒動作せず
    3.2016Summer環境でサンプルコードを貼り付けて作成⇒動作せず
    4.2016Summer環境で提供頂いているサンプルを取込み動作確認⇒動作せず

    動作しないと記述していただいている内容に関して、具体的な確認手順・確認内容をご教示ください。

    ①2014Winterでサンプルコードを組み込んだ場合、問題なく動作しますか
    ②2016Summerでユーザモジュールを取り込んだ場合、問題なく動作しますか

    はい。

    CookBook用に公開しております以下のサイト(2016 Summerアップデート版)と同じ動作になります。

    1. ロール「IM-Workflowユーザ」に所属しているユーザにてログインします(ueda/ueda)。
      https://dev.intra-mart.jp/imart/login?

    2. 以下のURLからIM-Workflowの申請一覧画面を表示します。
      https://dev.intra-mart.jp/imart/im_workflow/user/apply/apply_list?

    3. フロー「Forma DCNodeSetting Decision Sample」の申請/処理開始ボタンを押下します。

    4. 表示された画面にて任意のユーザを選択し、Executeボタンを押下します。

    5. 表示された標準処理画面にて申請/処理開始ボタンを押下します。

    6. 以下のURLからIM-Workflowの処理済み一覧を表示します。
      https://dev.intra-mart.jp/imart/im_workflow/user/cpl_proc/actv_proc_list?

    7. 5で申請された案件のフローリンクからフロー参照画面を表示します。

    8. Dynamic Approvalノードの処理対象者に4で選択したユーザが選択されていることが確認できます。

    • ohashi より:

      動作しないと記述していただいている内容に関して、具体的な確認手順・確認内容をご教示ください。

      複数環境で確認を行っておりますので、2点記載します。

      1つ目
      【環境:2014Winter】
      1.当記事内のレシピ通りにフロー作成、ルート作成、フロー定義等を行う
      2.Formaアプリを作成し、ボタンイベントにサンプルコードを記述
      3.作成した画面を起動しボタンを押下
      4.申請[Apply]画面が表示されるが処理対象者の設定ができていない
      (フロー設定のブロックが表示され、設定状況が空のものが表示される)

      2つ目
      【環境:2016Summer】
      1.完成サンプルをダウンロードし、取込みした画面を起動
      2.Executeボタン押下
      3.申請[Apply]画面が表示されるが処理対象者の設定ができていない
      (フロー設定のブロックが表示され、設定状況が空のものが表示される)

       ⇒ここまでで、連携部分の動作が確認できないと判断しました。
        内容に不足がございましたらご指摘ください。

      また、ご回答の内容ですと、2014Winterも2016Summerも同じ動作をするとありますが、何か環境設定周りの編集は必要ないのでしょうか。

      よろしくお願いいたします。

  4. intra-mart開発本部 より:

    こちらでもCookBookのサンプルコードにて再現確認しておりますが、ご指摘の事象を再現できておりません。事象の発生時に実施された具体的な手順を共有していただくことは可能でしょうか?

    また、以下の認識でお間違いないでしょうか?
    ・「2014 Winter(Iceberg) 8.0.9 PATCH 001」の環境にてIM-FormaDesignerアプリケーション・IM-Workflowフロー定義を作成されて、そちらにCookBookのサンプルコードを貼り付けて動作を確認されている。

    【補足】
    ・CookBookに挙げているサンプルのユーザモジュールには依存関係を設定しており、IM-FormaDesigner 2015 Winterアップデート以降のバージョンでないとIM-Jugglingプロジェクトに取り込めません。

    ・ユーザモジュール内に配置されているIM-FormaDesignerアプリケーションを2014 Winter(Iceberg) 8.0.9 PATCH 001の環境にインポートすると、エラーになります(旧バージョンで動作しない新規の設定がインポート資材に含まれているため)。

    • ohashi より:

      ご連絡ありがとうございます。

      調査を行いながら対応していたため、
      誤解を招くような書き方をしてしまい申し訳ございません。

      事象の発生時に実施された具体的な手順を共有していただくことは可能でしょうか?

      下記の流れで現在に至っております。
      1.2014Winter環境でサンプルコードを貼り付けて作成⇒動作せず
      2.2014Winterから2016Summerにバージョンを上げ、1で作成したものを動作確認⇒動作せず
      3.2016Summer環境でサンプルコードを貼り付けて作成⇒動作せず
      4.2016Summer環境で提供頂いているサンプルを取込み動作確認⇒動作せず

      補足頂きました依存関係によるエラーについては2014Winter環境においては確認しております。
      2016Summer環境では問題なく取り込めて画面の表示なども正常に行われておりますが、
      連携の部分がうまく動作しておりません。

      以下2点について確認したいのですが、ご回答いただけますでしょうか。
      ①2014Winterでサンプルコードを組み込んだ場合、問題なく動作しますか
      ②2016Summerでユーザモジュールを取り込んだ場合、問題なく動作しますか

      よろしくお願いいたします。

  5. aokit より:

    記事内で紹介されている完成サンプルをダウンロードして実施しているので、こちらで特別なことはしていません。
    ですがうまくいかないため、他に変更する箇所や環境設定の変更が必要なのかと思って質問を投げた次第です。

    なるほど。
    環境側の問題となると、以下からの制約かもしれません。

    バージョン

    公式ドキュメントによると、この記事で利用されている動的処理対象者設定機能は以下のバージョンで追加された機能のようなので、それ以前のバージョンでは動作しないようです。
    http://www.intra-mart.jp/document/library/iap/public/im_workflow/im_workflow_programming_guide/texts/customize/dynamic_operator_setting/index.html

    「PC版 IM-Workflow 2014 Winter(Iceberg) 8.0.9 PATCH 001」
    「スマートフォン版 IM-Workflow 2015 Summer(Karen) 8.0.11」

    モジュール構成

    公式ドキュメントによると、この記事で利用されている動的処理対象者設定機能はIM-Workflow 2014 Winter(Iceberg) 8.0.9 PATCH 001の時点だと、IM-BIS入り環境では動作しないようです。
    「8.2.9. IM-Workflow の「動的処理対象者設定機能」は、IM-BIS が導入されている環境で利用することはできません。」
    http://accel-archives.intra-mart.jp/2014-winter/document/bis/public/bis_release_note/texts/limitations/flow.html#common-imw-local-bis

    • ohashi より:

      ドキュメントの提示ありがとうございます。
      バージョンについては「IM-Workflow 2014 Winter(Iceberg) 8.0.9 PATCH 001」
      ですので、問題ないかと思います。

      もうひとつの

      「8.2.9. IM-Workflow の「動的処理対象者設定機能」は、IM-BIS が導入されている環境で利用することはできません。」

      について、こちらIM-BISは導入しておりません。
      そのため、提示していただいた要件は2つとも満たしているはずなのですが・・・。

      • 通りすがり より:

        そもそも、ここにで、公開されてるmodule.xmlが、

        jp.co.intra_mart.forma
        8.0.11

        ってなってますから、Formaの2015 Winterしか動かないと思います。

  6. aokit より:

    chromeの開発者ツールを使用していますが特にスクリプトエラーは確認できません。

    スクリプトエラーが出ないということから、スクリプト自体は正しく実行されてそうですね。それで期待通りに動作しないなら、スクリプトから動的処理対象者設定機能に対してバインドしている設定内容が誤ってるのではないでしょうか?

    アップしていただいたスクリプトではサンプルコードのノードID「dynamic_001」をそのまま指定されていますが、ご利用されているルート定義上の動的承認のノードIDは「dynamic_001」になっていますか?

    • ohashi より:

      ご利用されているルート定義上の動的承認のノードIDは「dynamic_001」になっていますか?

      同じノードIDを設定しております。
      記事内で紹介されている完成サンプルをダウンロードして実施しているので、こちらで特別なことはしていません。ですがうまくいかないため、他に変更する箇所や環境設定の変更が必要なのかと思って質問を投げた次第です。

  7. aokit より:

    $(“#form”).append(”);

    imwNodeSettingのinputタグをappendしている箇所がサンプルコードとは違って、空文字になっているように見えます。

    あと、サンプルの通りに動作しないとのことですが、ブラウザの開発者ツールのコンソールなどにスクリプトエラーが出力されてたりしませんか?

    • ohashi より:

      imwNodeSettingのinputタグをappendしている箇所がサンプルコードとは違って、空文字になっているように見えます。
      ご指摘の箇所、確認しました。
      コメント送信時にタグが変換されてしまっているみたいですね。
      投稿内容を見直しせずにすみません。
      確認したところ他の箇所もシングル・ダブルクォーテーションが全角に変換されていたりしますが、userCdとdisplayFlag以外はサンプル通りです。

      ↓念のため・・ご指摘の箇所を全角にして貼ってみます↓
      //ここから
       $(”#form”).append(’<input type=”hidden” name=”imwNodeSetting” value>’);
      //ここまで

      ブラウザの開発者ツールのコンソールなどにスクリプトエラーが出力されてたりしませんか?
      chromeの開発者ツールを使用していますが特にスクリプトエラーは確認できません。

  8. ohashi より:

    aokit さん
    userCdとdisplayFlagのみ変更していますが、他はサンプル通りです。

    念のため貼り付けます。

    // パラメータ
    var userCd = ‘ohashi’; //ユーザ名
    var nodeId = “dynamic_001”; // 動的承認ノードのノードID

    // リクエストパラメータ「imwNodeSetting」を作成します。
    var nodeSetting = {};
    nodeSetting.DCNodeSetting = {};
    nodeSetting.DCNodeSetting[nodeId] = {};
    nodeSetting.DCNodeSetting[nodeId].displayFlag = true; // 画面表示をしない
    nodeSetting.DCNodeSetting[nodeId].processTargetConfigs = [];
    nodeSetting.DCNodeSetting[nodeId].processTargetConfigs[0] = {};
    nodeSetting.DCNodeSetting[nodeId].processTargetConfigs[0].extensionPointId = “jp.co.intra_mart.workflow.plugin.authority.node.dynamic”;
    nodeSetting.DCNodeSetting[nodeId].processTargetConfigs[0].pluginId = “jp.co.intra_mart.workflow.plugin.authority.node.dynamic.user”;
    nodeSetting.DCNodeSetting[nodeId].processTargetConfigs[0].parameter = userCd;
    var nodeSettingJson = ImJson.toJSONString(nodeSetting);

    // リクエストパラメータ「imwNodeSetting」をフォームにセットします。
    if($(‘input[name=imwNodeSetting]’).size() === 0 ){
    $(“#form”).append(”);
    }
    $(‘input[name=imwNodeSetting]’).val(nodeSettingJson);

    // 標準処理画面を呼び出します。
    sendRegistData();

    以上です。

  9. aokit より:

    横から失礼します。
    こちらでも試してみましたが、サンプルの資材で動作しました。

    どんな風にコードを書かれてますか?

  10. ohashi より:

    コメントありがとうございます。
    ご指摘の暗黙条件の指定ではなく、
    「(サンプルスクリプト)処理対象者の決定」のコードで試してみましたが、設定がされていない状態です。

  11. ohashi より:

    こんにちは。
    記事内の完成サンプルを取込し、手順通り実行したのですが
    申請画面で処理対象者の設定がされません。
    (フロー設定のブロックが表示され、設定状況が空のまま)
    別途、定義ファイルなどの変更作業が必要でしょうか?
    よろしくお願いいたします。

    • intra-mart開発本部 より:

      本記事は、申請画面で処理対象者をコードで設定するサンプルと、
      申請画面で処理対象者を絞り込むための暗黙条件(引数)を渡すためのサンプルの両方を記載していますが、暗黙条件を指定するオブジェクト(criteriaプロパティ)を渡していないでしょうか。

comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

no image

Lombok のご紹介

この CookBook では、Lombok について紹介しています。 intra-mart 開発本部では Lombok を利用しています。 Lombok を簡単に説明すると、「アノテーションを書くだけ …

「イベント」ボタン・「一覧へ戻る」ボタンを使用し任意の遷移先を設定する

このCookBookでは、IM-FormaDesignerの画面アイテム・ボタンを使用し、任意の画面に遷移する方法について紹介しています。 設定方法は下記の2パターンです。 「イベント」ボタンを使用す …

no image

最初に表示するページを指定する方法

このCookBookでは、最初に表示するページを指定する方法について紹介しています。 BloomMakerのデザイン編集画面でコンテナページを追加すると、プレビュー画面やアプリケーション画面では1つ目 …

no image

Web サーバで Cookie に SameSite=None; Secure 属性を追加する方法

ブラウザの仕様変更により、クロスドメインアクセスにおける Cookie の扱いに変更がありました。 Google Chrome では バージョン 80 以降、SameSite 属性が宣言されていない …

no image

多要素認証(MFA)のバックアップコードを生成していないユーザに通知を送る方法

この CookBook では、多要素認証のバックアップコードを生成していないユーザに通知を送る方法について紹介しています。 多要素認証では Google Authenticator を用いて認証を行い …