jp.co.intra_mart.foundation.workflow.application.process
クラス PullBackManager
java.lang.Object
jp.co.intra_mart.foundation.workflow.application.process.PullBackManager
public class PullBackManager
- extends Object
引戻しマネージャ。
引戻し処理や、特定のユーザが引き戻せる案件のノードリストを取得することもできます。
詳細は各メソッドの説明を参照してください。
引き戻し以外の処理を行うには、申請マネージャ「ApplyManager
」や処理マネージャ「ProcessManager
」を利用してください。
- 導入されたバージョン:
- 7.2
- 関連項目:
ApplyManager
,
ProcessManager
PullBackManager
public PullBackManager(String loginGroupId,
String localeId,
String systemMatterId)
- コンストラクタ
引数で指定したログイングループID、ロケールID、システム案件IDで引戻しマネージャを
新しく生成します。
- パラメータ:
loginGroupId
- ログイングループIDlocaleId
- ロケールIDsystemMatterId
- システム案件ID
getNodesToPullBack
public MatterNodeModel[] getNodesToPullBack(String executeUserCode)
throws WorkflowException
- 指定したユーザが引戻し可能なノード情報を取得します。
パラメータで指定した「executeUserCode 実行者コード」ユーザが、引き戻せるノード(=引戻し元ノード)関連情報を取得します。
引戻し元として指定可能なノードは、「imw_t_before_task」テーブルのデータを用いて取得します。
詳細な仕様は「IM-Workflow 仕様書」を参照してください。
引き戻せるノードが複数存在する場合は、処理時間の降順でソートされます。
検索の結果、特定ユーザが引き戻せるノードが存在しない場合は、サイズ0の空もオブジェクトを返却します。
本メソッドでは、返却データとして設定するノード情報は最新の「flow.xml」から取得します。
最新の「flow.xml」を取得するには、案件テーブル「imw_t_actv_matter」の最終処理ID「LAST_PROCESS_ID」に保存されている
値を用いて、トランザクションファイルディレクトリから取得します。
標準設定の場合、取得対象の「flow.xml」は下記に格納されています。
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/task/{%最終処理ID%}/flow.xml
XMLファイルからのデータ取得やデータベースの検索処理で失敗した場合には、例外「WorkflowException
」が発生します。
- パラメータ:
executeUserCode
- 実行者コード
- 戻り値:
- MatterNodeModel[] 案件ノード情報の配列
- 例外:
WorkflowException
- ワークフロー例外
pullBack
public void pullBack(PullBackParam pullBackParam,
Map<String,Object> userParam)
throws WorkflowException
- 引戻し処理を行います。
このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。
承認した処理の引戻しや、差戻し処理の引戻しを行うことができます。
「pullBackParam 引戻し用パラメータ情報」に設定されている内容での引戻し処理を行います。
「実行者コード」と「権限者コード」が異なる場合には、代理権限での引戻し処理になります。
引戻し先に指定可能なノード情報は「getNodesToPullBack(String)
」で取得できますが、
引戻し時に特にチェック処理は行なっていません。設定可能なノードの指定とは関係なく、処理できます。
引戻し処理では、処理待ち状態になっている引戻し元ノードを終了し、引戻し先ノードへの移動処理を行います。
ノードの移動処理では、引戻し元ノードのユーザアクション処理と引戻し先ノードの到達処理が実行されます。
下記の拡張ポイントのプラグイン処理を拡張することで、処理を追加することができます。
アクション処理:「jp.co.intra_mart.workflow.plugin.event.node.action.process」
到達処理:「jp.co.intra_mart.workflow.plugin.event.node.arrive.process」
アクション処理は引戻し元に設定されている処理が実行されます。
アクション処理の実行は、ノードの移動処理の前に実行されます。アクション処理では移動処理前の状態のデータが取得されます。
アクション処理にはパラメータで設定した「userParam ユーザパラメータ」がそのまま渡されます。
アクション処理に渡したいデータがある場合には、「ユーザパラメータ」を利用してください。
アクション処理で実行される外部プログルムのデータベースへの登録・更新処理等もこのメソッド内のノード移動処理と同じトランザクション内の処理になります。
アクション処理の実行や、ノード移動処理が全て正常に終了されない場合には、登録した全データがロールバックされて、「WorkflowException
」が発生します。
エラーが発生したタイミングによっては、データベース処理のみロールバックされて、作成したXMLファイル情報はそのまま残る場合もありますが、
再度処理を行う時に影響はありません。ゴミデータになります。
ノード移動処理は、IM-Workflowのエンジンのノード移動ロジックで、データの作成、更新、削除処理を行います。
ノードの移動処理については、承認処理「ProcessManager.approve(ApproveParam, Map)
」で行なっている処理と同じです。
「ProcessManager.approve(ApproveParam, Map)
」のノード移動処理関連の説明を参照してください。
ただし、引戻し処理では、引戻し先ノードから引戻し元ノードへの移動処理以外に、下記の処理を行います。
引戻し元ノードに関しては、引戻しステータスで完了した後に、再びキャンセル処理を行い、処理していない状態に戻します。
その後は、承認の引戻しか、差戻しの引き戻しかによって、処理が異なります。
承認の引戻し処理の場合は、引戻し元ノードから引戻し先ノードまでのルート上に存在するノードの処理ステータスをキャンセルに変更する処理を行います。
キャンセルされたノードは処理されてない状態と同じ状態とみなします。
差戻しの引き戻し処理の場合は、引戻し元ノードから引戻し先ノードまでのルート上に存在するノードの処理ステータスを差戻し時のキャンセルから、
前回に処理したステータスに復元する処理を行います。
引戻し元ノードから引戻し先ノードの間にあるノードのキャンセルや復元処理は、ノードの移動処理は1個ずつ繰り返して行います。
このノード移動処理中では、各ノードに対してユーザの展開処理やアクション処理、到達処理の実行を行なっていません。単純なノードの移動処理になります。
到達処理やユーザの展開処理が実行されるのは、最後の引戻し先ノードのみになります。
引戻し先ノードで行われるユーザ展開処理では、前回に処理したユーザのみが展開されます。
全ての処理が終了した後に、根回しメールの送信処理を行います。
メール送信は内部トランザクションを終了した後に実行します。送信処理でエラーになった場合でも、本メソッドの処理には影響ありません。
引戻し元ノードに確認ノードが繋がっている場合でも、本メソッドの処理により確認ノードは到達状態になりません。確認処理できない状態のままです。
確認処理ができるようにするには、引戻しではなく、承認処理「ProcessManager.approve(ApproveParam, Map)
」を行う必要があります。
- パラメータ:
pullBackParam
- 引戻し用パラメータ情報userParam
- ユーザパラメータマップ
- 例外:
WorkflowException
- ワークフロー例外
Copyright © 2000-2015 NTT DATA INTRAMART CO.,LTD.. All Rights Reserved.