メインコンテンツまでスキップ

つまずきやすいポイントと関連ドキュメント

スクリプト開発モデルで画面やユーザプログラムを実装するとき、画面種別やアクション処理の仕様によって、想定と異なる動作やエラーの原因になることがあります。

代表的な事象と対処を示します。詳細な仕様については、各製品ドキュメントを参照してください。スマートフォン画面などの拡張機能については、参考リンクの案内に留めています。

おもな注意事項​

新規実装は処理モーダルを選ぶ​

2020 Summer（Zephirine）以降で、ワークフロー処理モーダルを利用できます。標準処理画面から画面デザインを刷新しており、開発モデルによらずCSJS APIとして動作します。

注意

workflowOpenPageタグはこれまでどおり動作しますが、今後の機能追加の予定はありません。新規実装では、ワークフロー処理モーダルを利用した画面実装を推奨します。

申請画面ではユーザデータIDが渡らない​

申請一覧から開く新規申請では、リクエストパラメータにimwUserDataIdがありません。

画面種別が申請（imwPageTypeが0）のときは、画面側でユーザデータIDを生成してshowApplyのprocessParameter.userDataIdへ渡すか、processParameter.userDataIdを省略すると、テナントのユーザデータID設定方式にしたがって生成されます。既存の業務IDをユーザデータIDにする場合は、最大20バイトに収まる値を渡します。

詳細はワークフロー開発の流れと、リクエストパラメータ（プログラミングガイド）を参照してください。

画面種別ごとにリクエストパラメータの取得可否が異なる​

一時保存・再申請・処理など、画面種別によって渡るパラメータは申請時と異なります。申請画面と同じ前提で一時保存や処理の画面を実装すると、渡されないパラメータの参照によってスクリプトエラーが発生します。

実装前に、リクエストパラメータ（プログラミングガイド）に記載されている画面種別ごとの取得可否の表を確認してください。

コンテンツ定義のパス指定は相対パス・拡張子なし​

スクリプト開発モデルのスクリプトパスは、スクリプト開発モデルプログラムのソースディレクトリからの相対パスです。既定ではWEB-INF/jssp/srcからの相対パスで、拡張子は含みません。新規の申請画面では、処理モーダル実装のパスを登録します。

実体がWEB-INF/jssp/src/sample/im_workflow/purchase/screen_modal/apply.jsと.htmlなら、指定はsample/im_workflow/purchase/screen_modal/applyです。先頭にスラッシュを付けた絶対パスや、WEB-INF/jssp/srcを含めたパス、末尾に.jsや.htmlを付けたパスを指定すると、正しく読み込まれません。

登録内容はコンテンツ定義を登録・設定する（管理者操作ガイド）を参照してください。

アクション処理内でDBトランザクション制御はできない​

アクション処理はIM-Workflowモジュールのトランザクション内で実行され、アクション処理のプログラム中ではDBトランザクション制御はできません。

トランザクションのロールバックはモジュール側でのみ実行できます。このため、ユーザプログラムの成功・失敗フラグやエラーメッセージをアクション処理の返却オブジェクトに設定するようにします。

  • 失敗時はresultFlagをfalseにします。指定しない場合は成功（true）とみなされます。
  • messageは失敗時に設定します。画面にそのエラーメッセージが表示されるようになります。

詳細はアクション処理（プログラミングガイド）を参照してください。

アクション処理の失敗で後続が実行されない​

複数のアクション処理があるとき、いずれかが失敗すると、失敗した処理よりあとに設定したアクション処理は実行されません。スクリプト開発モデルでは、返却オブジェクトのresultFlagにfalseを設定した場合に処理失敗とみなされます。

さきに業務テーブルへ登録する処理が失敗すると、案件プロパティへ登録する後続も実行されません。複数のアクション処理を設定する場合は、入力検証など失敗する可能性のある処理を先行させ、登録順序に注意します。

詳細はアクション処理（プログラミングガイド）を参照してください。

ユーザパラメータがnull／空になる処理がある​

ユーザパラメータのおもな用途は、画面上の入力情報をアクション処理へ渡すことです。画面入力を経由しない操作では、空やnullのユーザパラメータも渡ります。

nullになるのは、引戻し、差戻し後引戻し、承認／否認／差戻し（自動処理による実行時）、案件操作、一時保存（削除）です。空になるのは、承認（一括処理による実行時）です。スクリプト開発モデルでは、空の値は空のオブジェクト（{}）です。

nullや空オブジェクトが渡る前提で、メソッドの種類（申請・承認など）とlumpProcessFlag（一括処理フラグ）、autoProcessFlag（自動処理フラグ）を使って判定します。

詳細はアクション処理（プログラミングガイド）を参照してください。

独自の案件番号は申請系アクションの返却で設定する​

独自の案件番号を使う場合は、申請／再申請／申請（一時保存）／申請（未処理）アクションの返却オブジェクト（data）で設定します。

  • 申請（一時保存）は一時保存案件からの申請、申請（未処理）は未申請状態案件からの申請であり、一時保存アクションとは異なります。
  • 案件番号の設定は任意で、未設定（null）の場合は既存の案件番号が維持されます。
  • まだ案件番号がない申請では、IM-Workflow側で既定の番号が採番されます。

承認など申請系以外では、返却dataに値を指定しても案件番号は上書きされません。

詳細はアクション処理（プログラミングガイド）を参照してください。

注意

案件番号のデータ型は文字列で、最大20バイトです。文字数ではないことに注意してください。

API直呼びと画面操作では権限チェックの範囲が異なる​

画面上からの操作とは異なり、案件処理系API（Webサービスを含む）を直接利用して案件を処理する場合は、業務的なチェック（処理対象者への包含や代理の有効性など）をせずに処理が実行されます。 案件処理系APIと画面動作仕様の違い（プログラミングガイド）

ヒント

画面と同等にするなら、案件処理APIの実行前に処理権限判定APIなどを併せて利用します。

応用カスタマイズ​

「ワークフロー開発の流れ」の説明は、サンプルデータを例にした基礎的な内容に絞っています。

そのほかの、連続処理や、処理完了後の画面遷移、スマートフォン対応などの拡張は、カスタマイズ（プログラミングガイド）を参照してください。

次に読むドキュメント​