intra-mart Accel Platform 2015 Winter(Lydia) リリースノート 第2版 2016-01-08

intra-mart Accel Platform 2015 Winter(Lydia) リリースノート 第2版 2016-01-08

目次 ≪  8.4.1. IMBox 8.4.3. IM-Workflow (スマートフォン)  ≫

8.4.2. IM-Workflow

8.4.2.1. システムロケールの変更を行った場合に制約があります。

  • システムロケールを変更した後、そのまま運用を再開すると、マスタデータ・トランザクションデータともに不整合が発生します。
    これにより、案件を承認しようとしても正常に処理が行われず、データが壊れる可能性があります。

    ロケールを追加した場合に限り、次の対応でリカバリする事ができます（ロケールの削除は対象外です）。
    • マスタデータ
    追加したロケール分のデータを補完設定する必要があります。
    ・IM-Workflowのマスタについては「言語追加ガイド」を参照してください。
    ・IM-共通マスタとロールについては「国際化支援機能仕様書」を参照してください。
    「IM-共通マスタ／ロール国際化情報チェックジョブ」で、補完設定が必要な国際化情報をチェックできます。
    「IM-共通マスタ／ロール国際化情報補完ジョブ」で、補完設定が必要な国際化情報をテナントロケールのデータで補完できます。
    • トランザクションデータ
    追加前に申請した案件については、追加前のユーザロケールに切り替えて操作を行なってください。
    ロケール追加後に申請した案件についてはどのユーザロケールでも操作は可能です。

8.4.2.2. システムロケール毎にマスタデータが必要です。

  • IM-Workflowでは、システムロケール毎にマスタデータが必要となります。
    システムで3言語（日本語・英語・中国語（簡体字））が利用可能な状態に対して、
    マスタデータが日本語のみとして運用する事はできません。

    以下に対してロケール毎にマスタデータの登録が必要です。

    ・ロール情報

    ・IM-共通マスタ情報
    　1. ユーザ
    　2. 組織
    　3. 会社＋役職
    　4. パブリックグループ
    　5. パブリックグループ＋役割

    ・IM-Workflowマスタ情報
    　1. 案件プロパティ定義
    　2. ルール定義
    　3. メール定義
    　4. IMBOX定義
    　5. 一覧表示パターン定義
    　6. フローグループ定義
    　7. コンテンツ定義
    　8. ルート定義
    　9. フロー定義

8.4.2.3. ワークフローのマスタ設定に応じて Storage 領域のサイジングが必要です。

  • IM-Workflowでは、 Database 、Storage にデータを保存します。

    このため、データ数の増加により Storage のサーバリソースも必要とします。
    ※Storage に保存されるデータは“ノード数“および”処理済みノード数“に依存して増加します。

    また、差戻しや引戻しを実施した回数や言語の追加によりStorage に保存されるデータは増加します。お客様ご利用環境に合わせて、下記の例を参考に、Storage 領域のサイジングを行ってください。
    * ノード数 ： 5個([開始]→[申請]→[承認1]→[承認2]→[承認3]→[承認4]→[終了])
* [承認1]で処理待ち時  ⇒ 480KB
* [承認4]で処理待ち時  ⇒ 950KB
* 完了案件             ⇒ 180KB

* ノード数 ： 10個([開始]→[申請]→[承認1]→[承認2]→・・・・・→[承認8]→[承認9]→[終了])
* [承認1]で処理待ち時  ⇒ 850KB
* [承認9]で処理待ち時  ⇒ 3000KB
* 完了案件             ⇒ 300KB

  ※上記はファイルト以下の設定の場合の例です。
    ファイルトランザクションレベル(transaction-file-level)： １
    トランザクションファイル保存先(transaction-file-save-location)： １
    案件終了時のタスクアーカイブファイル作成省略設定(not-make-task-zip-file)： true

8.4.2.4. ワークフローのマスタ設定に応じてサーバの設定等を調整する必要があります。

  • [フロー参照]画面の「画像出力」機能およびAPI「WorkflowImageManager」は、フロー図（ルート図）のノード数に比例してメモリを消費します。
    そのため、ノードを多数配置した場合に“Out of memory”が発生する場合があります。この場合、サーバの設定等を見直し、適切な設定を行ってください。

8.4.2.5. ルート定義において設定するノード数に比例して処理時間が増加します。

  • 申請/承認処理において、下記のようなノードを設定する場合に、設定するノードの数に比例して処理時間が増加します。
    • [縦配置]
    • [横配置]
    • [動的承認]

8.4.2.6. ルート設定において設定する内容により対象者が解除されます。

  • 「ルート設定 - バージョン -編集」画面において、下記のような場合に対象者が解除されます。
    このような場合は、ノードを接続後に、対象者を設定してください。

    • [承認ノード]を配置し、対象者を設定した後に、申請／承認ノードをこのノードに接続した場合に、対象者が解除されます。

    • [申請／承認ノード]-[承認ノード]のようなルート（接続）があった場合に、
      [申請／承認ノード以外]-[承認ノード]のようにルート（接続）を変更した場合に、[承認ノード]の対象者が解除されます。
    • [[申請／承認ノード以外]-]-[承認ノード]のようなルート（接続）があった場合に、
      [申請／承認ノード]-[承認ノード]のようにルート（接続）を変更した場合に、[承認ノード]の対象者が解除されます。

8.4.2.7. 同期ノードを含むルート定義において案件操作を行う場合の注意点があります。

  • 同期ノードを含むルート定義において同期外から同期内へ案件操作で移動を行った場合に、
    同期内の全てのルートが同期結合ノードへ到達しても同期結合ノードで停止します。
    （この場合、同期結合ノードの次のノードには進みません）。

8.4.2.8. フロー参照の表示に注意があります。

  • [フロー参照]画面において、フロー図（ルートの図）が全て表示される前に「画像出力」ボタンを押下すると、
    フロー図（ルート図）が表示されません。

    上記の場合、下記の回避策があります。
    「最新情報」ボタンをクリックすることで、フロー図を再表示することが出来ます。

8.4.2.9. 代理先ユーザに処理依頼メールが2通送信される場合があります。

  • 代理設定において、代理先に設定されているユーザに処理権限がある場合に、処理依頼メールが2通送信されます。

8.4.2.10. 利用するメールサーバによって正常に送信されない場合があります。

  • メール定義において件名、本文を省略した場合、メールが送信されないことがあります。 この挙動はメールサーバに依存します。

8.4.2.11. ユーザプロファイルに設定されているメールアドレスをメール送信先として利用します。

  • メール送信機能において使用されるメールアドレスは、ユーザプロファイルに設定される「メールアドレス１」のみを使用します。

8.4.2.12. 申請後の案件操作-ノード編集画面で保存済ノード設定の反映が正しく動作しない場合があります。

  • 申請ノード、または承認ノードの直後にテンプレート置換ノード（テンプレート内の先頭ノード＝承認ノード）を配置した場合、
    案件申請後の案件操作-ノード編集画面で保存済ノード設定の反映が正しく動作しません。

8.4.2.13. 再展開前に処理された処理履歴の処理名は標準の処理名が表示されます。

  • 既に展開された横・縦配置ノードが再展開されるとノードIDが変更されるため、再展開前に処理された処理履歴の処理名は標準の処理名が表示されます。

8.4.2.14. 到達処理に再処理者自動承認が設定されたノードで自動承認が行われません。

  • 既に展開され処理された横・縦配置ノードが再展開されると、ノードIDが変更されるため、到達処理に再処理者自動承認が設定されたノードで自動承認が行われません。

8.4.2.15. ノード設定画面の前処理者系の処理対象プラグインの状況確認アイコンを押下するとHTTP500エラーとなる場合があります。

  • 展開された縦配置ノード・横配置ノードのノード設定画面において、「前処理者のXXX」といった前処理者に依存する処理対象が設定されている状態で、状況確認アイコンを押下した場合に、以下のエラー画面が表示されます。
    「HTTP 500 : サーバー内部でエラーが発生しました。」

8.4.2.16. 印影対象案件で処理期限自動処理バッチを実行した場合に自動処理に失敗します。

  • 印影機能を利用する際に、押印が必要な処理を処理期限自動処理バッチで行うと、システムユーザ(imw^system)と
    いうユーザで処理を実行する結果になるため、常用印が取得できず、アクション処理がエラーとなり、自動処理に失敗します。

    ※システムユーザ(imw^system)は、ユーザコードに IM-共通マスタの登録できない禁止文字(^)を使用しています。

8.4.2.17. 標準画面の処理の非同期のClientオブジェクトが使用できません。

  • 標準画面の処理の非同期を使用する場合、スクリプト開発モデルのアクション処理、到達処理においてClientオブジェクトが使用できません。
    HTTPオブジェクトの情報が必要な場合は、Javaの実装が必要となります。

8.4.2.18. コピーされたフロー定義にノード設定情報が残っているため、インポートを行うと『設定を解除しました。』というメッセージが表示されます。

  • コピーしたフロー定義、ルート定義、コンテンツ定義の編集を行った後、
    インポートを行うと『設定を解除しました。』というメッセージが表示されることがあります。
    【理由】
    編集によりノード設定情報が残る場合があり、これがインポートチェック条件に該当してしまうため発生します。
    （編集前の情報を復活できるようにするため、ノード設定情報を残しています。）
    【オペレーション】
    以下の様なオペレーションを行った場合、発生する可能性があります。
    1. コンテンツ定義_A、ルート定義_A、フロー定義_A、ルール定義_Aを作成します。
    2. コンテンツ定義、ルート定義、フロー定義を各バージョン編集画面にて各定義のコピーを作成します。
    3. ルール定義_Bを作成します。
    4. コンテンツ定義_Bに設定されているルール定義_Aを削除します。
    5. コンテンツ定義_Bに設定されているルール定義_Bを新規作成します。
    6. フロー定義_Bにルール定義_Bを新規作成に追加します。
    7. コンテンツ定義_B、ルート定義_B、フロー定義_B、ルール定義_Bのエクスポート処理を実行します。
    8. エクスポートされたデータをインポートします。
    【影響】
    内部情報がインポートチェック条件に該当してしまうのみのため、当該ケースではインポート処理に影響はありません。

8.4.2.19. 標準画面の処理の非同期に関する注意点があります。

  • 標準画面の処理の同期／非同期設定を非同期に設定した場合で、
    非同期処理中にサーバが停止した場合など、IM-Workflow の処理が正しく行われない可能性があります。
    中断されたIM-Workflowの処理が存在する場合、「非同期処理ステータス」画面に「非同期処理中」の情報が表示されます。
    この状態は案件をロックしている状態ですので、案件を処理（承認など）することができません。
    「非同期処理ステータス」画面に「非同期処理中」の情報を削除することで案件のロックは解除されます。
    サーバの再起動等を行う場合は IM-Worklfow の処理が完全に終了した状態で実施してください。
    運用上、ワークフロー処理中での再起動が避けられない場合は、ワークフローパラメータ [標準画面の処理の同期／非同期設定]と
    [案件終了処理、到達処理、メール送信処理、IMBox 送信処理の同期／非同期制御]の設定を同期に設定してください。

8.4.2.20. 標準画面の処理の非同期のアクション処理／到達処理でのHTTP系オブジェクトの参照について注意点があります。

  • 標準画面の処理の非同期は、IM-Worlflow の処理およびアクション処理／到達処理は別スレッドで実行されます。
    ユーザコンテンツでHTTPContextやHTTSessionなどのHTTP系オブジェクトに格納した情報は、別スレッドで実行されます。
    IM-Worlflow の処理およびアクション処理／到達処理で利用（参照）することはできません。
    アクション処理／到達処理はワークフローパラメータで値を引き渡す実装を行うことが推奨となります。
    アプリケーションの実装がHTTP系オブジェクトを利用されていることを考慮し、
    HTTP系オブジェクトをアクション処理／到達処理で参照できるような仕組みも提供されています。
    ただしこの実装は非推奨となるためワーニングログが出力されます。

8.4.2.21. 処理依頼メッセージは、処理を行ったユーザのロケールで配信されます。

  • 処理依頼メッセージは、承認等の処理後に、次ノードの処理対象者に送信されます。
    この際、題名や本文は処理（承認など）を行ったユーザのロケールで送信されます。

    当該仕様の対象は以下になります。
    1. メール
    2. IMBox （ApplicationBox）
    3. IM-Notice

8.4.2.22. 確認処理後、未確認状態で同じ案件が一覧に表示されます。

  • 標準画面の処理の非同期設定を行って確認を行うと確認処理後直ぐに画面が切り替わって一覧が表示されますが、
    確認処理が非同期で実行されるため、一覧表示の段階で確認処理が終了していない場合があります。

    この場合、未確認状態で同じ案件が一覧に表示されます。さらに再び確認処理を行うことができるため、
    結果的に２度確認処理を行うおそれがあります。

    【回避方法】
    確認を行った後は、非同期処理の処理状況を「処理済み」 - 「処理状況タブ」で確認処理の状況を参照して
    確認処理を複数回行わないようにしてください。

8.4.2.23. 画面種別が「申請」のユーザコンテンツをマイメニューに登録する際の注意点があります。

  • マイメニューに登録できるメニューアイテムは、原則としてサイトマップにあるメニューアイテムが対象です。
    例外として画面種別が「申請」のユーザコンテンツ画面はマイメニューへの登録が可能です。
    この場合、マイメニューが利用できるのは、標準の処理画面（IM-Workflowタグリブ「workflowOpenPage」を記述した画面）のみとなります。
    なお、画面種別が「申請」以外のユーザコンテンツ画面をマイメニューに登録した場合は、マイメニューからのアクセスは正常に動作しません。

8.4.2.24. 「案件終了処理・到達処理・メール送信」処理中にシステムエラーが発生した場合、メモリが解放されない場合があります。

  • IM-Workflowの「案件終了処理・到達処理・メール送信」処理では、処理中にコンテキスト情報をメモリに永続化し処理終了後にメモリを解放しています。
    「案件終了処理・到達処理・メール送信」処理中にシステムエラーが発生し処理が異常終了した場合、メモリが解放されない場合があります。
    このようなシステムエラーが繰り返されるとメモリが圧迫される場合があるため、Web Application Server を再起動しメモリを解放してください。

8.4.2.25. 標準処理画面の担当組織が初期表示されない場合があります。

  • ユーティリティメニューのカレント組織（一般ユーザ画面右上の所属組織）を変更した場合、標準処理画面の担当組織に初期表示する仕様が追加されました。
    上記の仕様において、標準処理画面の担当組織が初期表示されない場合があります。
    ・ユーティリティメニューのカレント組織と一致する組織が担当組織に存在しない場合は初期表示されません。
    　ユーティリティメニューのカレント組織はデフォルト組織セットのみ、IM-Workflowのフロー定義の標準組織にはデフォルト組織セット以外を
    　設定することが可能なためです。
    ・ユーティリティメニューのカレント組織で選択した組織の名称と異なった名称の組織を担当組織に初期表示する場合があります。
    　ユーティリティメニューのカレント組織はシステム日時点の名称となり、IM-Workflowは申請基準日の名称となります。
    　組織を期間化している場合はシステム日時点の名称と申請基準日時点の名称が異なる可能性があるためです。

8.4.2.26. 差戻し後引戻しにより復元されるノードでは、振替された処理対象者は振替前に戻ります。

  • 差戻し後引戻しにより復元されるノードの処理対象者について注意点があります。

    分岐内に複数のルートが存在する場合、あるルート上に存在するノードから分岐外への差戻しを実行後、差戻し後引戻しを行うと、
    他ルート上にあるノードの復元処理が実行されます。
    復元される処理待ちノードの処理対象者が振替されていた場合、処理対象者の復元は下記の挙動となります。

    ・復元される前の処理が「（振替先のユーザによる）保留」の場合、復元されたノードの処理対象者は保留したユーザのみとなります。
    　保留解除後も保留したユーザのみのままとなります。
    ・復元される前の処理が「引戻し」「差戻し後引戻し」以外の場合、復元されたノードの処理対象者は振替前の状態となります。

8.4.2.27. IM-Workflow は複数ブラウザ・複数タブでの操作、および、ブラウザバックはサポートしていません。

  • intra-mart Accel Platform の制限にある通り、IM-Workflowも、複数ブラウザ・複数タブでの操作、
    および、ブラウザバックはサポートしていません。

    以下の理由から、同一ユーザが複数ブラウザ・複数タブで操作することができません。

    ・添付ファイルの、一時アップロード先ディレクトリがユーザ単位であるため。
    ・操作パターンによっては、ユーザデータIDが重複してしまうため。

    ※事象が発生する操作パターン(例)は以下になります。
    a) パターン１
    ・複数ブラウザで同じ一時保存画面を開く。
    ・片方のブラウザで先に申請する。
    ・片方のブラウザで後に一時保存する。

    b) パターン2
    ・別PCにて同一ユーザIDでログイン操作する。

    c) パターン3
    ・一時保存から申請後、ブラウザバックで一時保存の画面に遷移して申請する。

    ユーザデータIDは、お客様アプリケーションで任意に設定できる項目として用意しております。
    設定の自由度を担保するため、ユーザデータIDと案件の紐付けは、１対１以外にも１対多を許容していません。
    そのため、案件に対してユーザデータIDが重複しているのが、不正な操作の結果であるか、
    現状のIM-Workflowでは業務的にチェックできません。

    ユーザデータIDの一意性を担保したい場合は、アクション処理等でユーザプログラムでチェックしてください。

8.4.2.28. 案件番号採番処理（DBシーケンス版)は SQLServer 2008 では利用できません。

  • SQLServer 2008 ではDBシーケンス機能が存在しません。
    このため、intramart Accel Platform 2013 Winter から提供されている、 案件番号採番処理（DBシーケンス版)は利用できません。

8.4.2.29. 動的処理対象者設定機能によって設定されたノードでは、ノード編集画面における「保存済み設定」機能を利用することはできません。

  • 動的処理対象者設定機能によって設定されたノードでは、ノード編集画面における「保存済み設定」機能を利用することはできません。
    これは、システムが決定した処理対象者や絞込み条件に対し、利用者が任意で設定した処理対象者で上書きしてしまうことを防ぐための制御です。

8.4.2.30. 動的処理対象者設定機能によって横配置ノード・縦配置ノードの設定を行う場合は、割当可能ノード数の最小・最大値を大きめに設定してください。

  • 動的処理対象者設定機能を横配置ノード・縦配置ノードに対して利用した場合、対象ノードの展開結果として、フロー定義で設定した割当可能ノード数の最小・最大値の範囲を超えたノード展開が行えます。
    この状態で展開された横配置ノード・縦配置ノードに対し、当機能を利用せずに標準処理画面からフロー設定を行う場合や、案件操作機能によるノード編集を行う場合は、フロー定義の設定で制御されるため、すでに展開済みのノード数を維持したまま再展開を行うことはできません。
    展開ノード数がフロー設定の制限を超えないよう、割当可能ノード数の最小・最大値を大きめに設定されることを推奨します。

8.4.2.31. 動的処理対象者設定機能で、criteria（暗黙条件）として「分類」を指定した場合、絞込み条件画面には何も表示されません。

  • 動的処理対象者設定機能で、criteria（暗黙条件）としてパラメータを指定した場合、通常は絞込み条件画面には「組織」や「役職」などのようにどのような条件で絞り込みが行われているかが表示されますが、以下の「分類」を指定した場合は、絞込み条件画面には何も表示されません。
    • 組織分類
    • パブリックグループ分類
    • ユーザ分類

8.4.2.32. 申請一覧ポートレット、および、未処理一覧ポートレットの縦幅を変更した場合、ポートレット内にある一覧の縦幅がリサイズされません。

  • 申請一覧ポートレット、および、未処理一覧ポートレットの縦幅を、ドラッグでサイズ変更した場合、ポートレット内にある一覧の縦幅はリサイズされません。
    一覧の縦幅は常に固定になり、変更することは出来ません。

8.4.2.33. IM-BISがインストールされている環境で特定の操作を行った場合、 IM-BIS の「ワークフロー」一覧画面に遷移します。

  • IM-BIS がインストールされている環境で、IM-Workflow メニューから以下の操作を行った場合、遷移先は IM-Workflow ではなく IM-BIS の「ワークフロー」一覧画面となります。

    ・ショートカットURLからコンテンツ画面に遷移後、一覧に戻る、もしくは処理を行った後の一覧遷移

    上記のケースにおいて、IM-BIS の画面を表示する権限がない場合、権限無しエラー画面に遷移します。

    IM-BIS がインストールされている環境では、IM-Workflow ではなく、IM-BIS の「ワークフロー」画面の利用を推奨します。
    IM-BIS の「ワークフロー」各画面における表示／実行権限をユーザに付与して利用してください。

8.4.2.34. FireFoxのポップアップブロックが有効な場合、処理対象者検索画面の表示でエラーが発生します。

  • FireFoxのメニュー[オプション] - [コンテンツ] のポップアップブロック設定にて、アクセス先のAccel Platformをポップアップ許可サイトに設定してください。

8.4.2.35. 一括処理対象者変更は変更対象のレコード数、変更先の処理対象者数に比例して処理時間がかかります。

  • 一括処理対象者変更は対象のレコード数、変更先の処理対象者数に比例して処理時間がかかります。また、「変更通知を送信」にチェックした場合は、メールサーバの性能も影響します。
    ユーザへの機能開放を行う場合、性能検証を実施してください。

    下記は弊社で実施した処理時間の参考値となります。

    コラム

    • 条件
      環境 - 同一筐体で実施
      Web Application Server ： Resin スタンドアロン
      データベース ： PostgreSQL
      単性能での検証
      変更先の処理対象者のユーザ数は100件

    • 結果
      ノード数 ： 100件
      変更通知を送信しない ： 20秒
      変更通知を送信する ： 25秒
      ノード数 ： 300件
      変更通知を送信しない ： 60秒
      変更通知を送信する ： 70秒
      ノード数 ： 500件
      変更通知を送信しない ： 105秒
      変更通知を送信する ： 120秒

      JVMのヒープ使用量は40Mから80Mで推移

目次 ≪  8.4.1. IMBox 8.4.3. IM-Workflow (スマートフォン)  ≫

Copyright © 2015 NTT DATA INTRAMART CORPORATION

⇄ Sidebar ↑Top